Related
About 3 hours ago, I won a Desire Z (wheeey!) at the HTC London meetup. Naturally, I came straight here after the help I got in January rooting my Desire.
I used the Visionary method and obtained temp root status, and then attempted perm root, which seemed to work. All of the guides I have read include a bunch of steps after this, one of which included deleting Visionary, which I then did. I just turned the phone off, took the battery out for a bit and then turned it back on. I still have the Superuser icon and the Terminal Emulator indicates that I have root access... is that it then? It's that simple?
Please tell me if I've done anything wrong, as I don't want to flash Cyanogen and Clockwork Recovery if it's all going to go to hell on me. Any advice or confirmation on whether or not I've obtained perm root would be lovely.
Oh, my firmware version is 1.34.405... etc. Is this simply the last version which allows for such easy root?
Arconaught said:
About 3 hours ago, I won a Desire Z (wheeey!) at the HTC London meetup. Naturally, I came straight here after the help I got in January rooting my Desire.
I used the Visionary method and obtained temp root status, and then attempted perm root, which seemed to work. All of the guides I have read include a bunch of steps after this, one of which included deleting Visionary, which I then did. I just turned the phone off, took the battery out for a bit and then turned it back on. I still have the Superuser icon and the Terminal Emulator indicates that I have root access... is that it then? It's that simple?
Please tell me if I've done anything wrong, as I don't want to flash Cyanogen and Clockwork Recovery if it's all going to go to hell on me. Any advice or confirmation on whether or not I've obtained perm root would be lovely.
Oh, my firmware version is 1.34.405... etc. Is this simply the last version which allows for such easy root?
Click to expand...
Click to collapse
Having the SuperUser icon just means the app is installed, open up terminal and type 'su' to see if it throws up any errors
Sent from my HTC Vision using XDA App
I should have mentioned that I did that and got the # symbol, am I good to go?
Arconaught said:
I should have mentioned that I did that and got the # symbol, am I good to go?
Click to expand...
Click to collapse
In theory, yes; in practice, no. Visionary (with the G2/Desire Z, at least) is known to be a bit buggy. You shouldn't have any issues installing custom ROMs but, I would recommend using the wiki method to root.
Sent from my HTC Vision using XDA App
OriginalGabriel said:
In theory, yes; in practice, no. Visionary (with the G2/Desire Z, at least) is known to be a bit buggy. You shouldn't have any issues installing custom ROMs but, I would recommend using the wiki method to root.
Click to expand...
Click to collapse
My understanding, if he already used Visionary to root, and it worked than he should be good to go. Either it works, or it doesn't. The risk with Visionary is that it sometimes corrupts some partitions, which causes the phone to not boot. I haven't read any conclusive reports on Visionary causing long term issues (correct me if I'm wrong).
redpoint73 said:
My understanding, if he already used Visionary to root, and it worked than he should be good to go. Either it works, or it doesn't. The risk with Visionary is that it sometimes corrupts some partitions, which causes the phone to not boot. I haven't read any conclusive reports on Visionary causing long term issues (correct me if I'm wrong).
Click to expand...
Click to collapse
This is my understanding as well, though I'd probably still use GFREE to get S-OFF if I were OP.
That's my next question, I'm using this guide ( http://forum.xda-developers.com/wiki/index.php?title=HTC_Vision#Rooting_the_G2 ) to try and get S-Off to flash Cyanogen and I'm wondering what step to start on, assuming from your replies that I'm rooted already.
I know it's a bit of a dumb question, but I just don't wanna fudge my new phone.
Arconaught said:
That's my next question, I'm using this guide ( http://forum.xda-developers.com/wiki/index.php?title=HTC_Vision#Rooting_the_G2 ) to try and get S-Off to flash Cyanogen and I'm wondering what step to start on, assuming from your replies that I'm rooted already.
I know it's a bit of a dumb question, but I just don't wanna fudge my new phone.
Click to expand...
Click to collapse
I used the wiki method myself, those that used other methods (like Visionary) and were told to root via the wiki seem to have all just started at the beginning, from what I've read.
Sent from my HTC Vision using XDA App
Arconaught said:
That's my next question, I'm using this guide ( http://forum.xda-developers.com/wiki/index.php?title=HTC_Vision#Rooting_the_G2 ) to try and get S-Off to flash Cyanogen and I'm wondering what step to start on, assuming from your replies that I'm rooted already.
I know it's a bit of a dumb question, but I just don't wanna fudge my new phone.
Click to expand...
Click to collapse
Whoa the Wiki method is completely different, looks like it was rewritten on 04/01.
You can completely ignore the temp rooting steps and concentrate on the gfree steps
From the "Necessary Files" section you need gfree, flash_image and ClockWorkMod Recovery
I would use the latest ClockWorkMod recovery rather than the one listed on the Wiki:
http://mirrorbrain.cyanogenmod.com/cm/recoveries/recovery-clockwork-3.0.2.4-vision.img (of course it's only the latest as of the time of this writing)
From step 2 you need to use:
Code:
$ adb push gfree /data/local/tmp/
$ adb push flash_image /data/local/tmp/
From step 2.a you need to use:
Code:
$ adb push recovery-clockwork-3.0.2.4-vision.img /data/local/tmp/recovery.img
Again note that the file name for CWM will depend on the version of CWM you are using.
Skip to step 4.b you need to use:
Code:
# cd /data/local/tmp
# ./gfree -f
# ./flash_image recovery recovery.img
# sync
Continue on as normal from here.
I skipped the temp root and perm root sections as you are already perm root.
I also skipped the ENG HBOOT parts, since that's not strictly necessary and the most risky part of the whole process (one mistake can result in a brick). If you want to flash the ENG HBOOT you would need to follow steps 4.a instead of 4.b, (you would also need the necessary HBOOT of course) the only command you need to omit from 4.a or 4.b is "# ./root_psn" which is the script which establishes permanent root.
Thanks a lot so far man, but I'm still stuck. I have adb, when I open it in the SDK, it flows for a bit, then closes. This is right, right? I'm meant to do all of these prompts via the cmd window?
OK, I've now sorted adb, but I can't get anything to work past that. Nothing will transfer to my phone and I'm going to kill... somebody.
Arconaught said:
OK, I've now sorted adb, but I can't get anything to work past that. Nothing will transfer to my phone and I'm going to kill... somebody.
Click to expand...
Click to collapse
You say you've sorted adb, but can you be more specific please ? What works and what doesn't work exactly ?
Ah, yeah, sorry. I got to the point where when I type in "adb devices" in the command window, it shows me my phone, with the serial number and whatnot. However, whenever i try the command:
$ adb push gfree /data/local/tmp/
It just won't work. I have all the files together in my desktop at the moment, having moved them from the downloads folder on my laptop. Is there a specific place I should have the stuff I need to send to my phone?
There is a great write up here about getting adb working. It sounds like either you didn't set up a "path" to use those commands anywhere or if you don't want to do that make sure your files are in the same folder as your adb.
Sent from my HTC Vision using XDA App
Arconaught said:
Ah, yeah, sorry. I got to the point where when I type in "adb devices" in the command window, it shows me my phone, with the serial number and whatnot. However, whenever i try the command:
$ adb push gfree /data/local/tmp/
It just won't work. I have all the files together in my desktop at the moment, having moved them from the downloads folder on my laptop. Is there a specific place I should have the stuff I need to send to my phone?
Click to expand...
Click to collapse
You need to have the files (extracted from the ZIP files you downloaded) in the same folder you run the ADB commands, if your ADB is in your path you should be able to run ADB commands from any folder.
To summarize you need to extract all the zips you downloaded under necessary files, all to the same folder. The open a command prompt and CD to that folder before you start using your adb push commands.
shortlived said:
There is a great write up here about getting adb working.
Click to expand...
Click to collapse
Yeah, steviewevie wrote it:
http://forum.xda-developers.com/showthread.php?t=865685
But it looks like he is willing to give the OP some personalized help.
Right, thanks guys, I think I'm making some progress.
ADB is all set up, and as far as I'm aware, having:
program files > android sdk > platform tools
on my path should mean I can open adb from anywhere right? I have all of the extracted files in platform tools, where adb is, in my program files... is this right, or have I completely missed the point here?
I keep getting "cannot stat 'gfree':: No such file or directory"
Sorry, I seem really stupid concerning this whole thing, but I'm sure it's something equally obvious that I'm just not seeing.
New problem. I worked out what I'd done wrong there, and got everything onto my phone. However, when trying to change the directory to /data/local/tmp, I keep getting "The system cannot find the path specified"
Now what am I doing wrong?
Arconaught said:
New problem. I worked out what I'd done wrong there, and got everything onto my phone. However, when trying to change the directory to /data/local/tmp, I keep getting "The system cannot find the path specified"
Now what am I doing wrong?
Click to expand...
Click to collapse
Remember you are running those commands (everything in that section) from an ADB shell, not from the Windows command prompt.
Excuse my ignorance, but what exactly do you mean by that? What should I do?
Hi, I've got a noob question here: How do I properly remove Super User from my GSM Galaxy Nexus?
I used Wugs Root Toolkit and it applied some "permanent" superuser method. My question is, how can I go about deleting the files so that the APK is no longer on my phone? I don't mind rooting again if that's what is required to remove it.
I searched around and didn't find an answer--that said if this has already been answered somewhere before I apologize--maybe I just all around fail! I saw some posts that related to the Hero but yeah... pretty sure it doesn't apply to the GNex.
Thanks! Oh, and don't ask me why I want to do this, yeah yeah, I know I must be out of my mind. A follow-up question though, would be that if I decide to root again after this, is there a method of pushing superuser where it will be removed whenever the stock ROM is updated?
Thanks again!
Just use root explorer to delete it from system/ app
Sent from my Galaxy Nexus using Tapatalk 2
I was under the impression that, that would not completely work? Isn't there another file somewhere that has to be removed as well? Thanks for the response!
shadrage said:
Hi, I've got a noob question here: How do I properly remove Super User from my GSM Galaxy Nexus?
I used Wugs Root Toolkit and it applied some "permanent" superuser method. My question is, how can I go about deleting the files so that the APK is no longer on my phone? I don't mind rooting again if that's what is required to remove it.
I searched around and didn't find an answer--that said if this has already been answered somewhere before I apologize--maybe I just all around fail! I saw some posts that related to the Hero but yeah... pretty sure it doesn't apply to the GNex.
Thanks! Oh, and don't ask me why I want to do this, yeah yeah, I know I must be out of my mind. A follow-up question though, would be that if I decide to root again after this, is there a method of pushing superuser where it will be removed whenever the stock ROM is updated?
Thanks again!
Click to expand...
Click to collapse
This is another example of the pitfalls of trying to take shortcuts by using toolkits. Toolkits are fine to save time for those that understand what the toolkit is doing, but if you don't have that knowledege base, yo really should do things manually first, in order to learn. (In school, they don't let you use a calculator until you can add/sub/mult/div for a reason).
Take a look at this post, specifially method 2. See if you can figure out what those commands are actually doing.
I will help you out: you are essentially mounting the system partition as read-write, copying two files to the system, changing permission on the system, and then mounting the system as read-only.
So, in order to remove root, you need to mount the system as read-write, remove those two files (command is rm) and mount the system as read-only. [EDIT: depending on where the toolkit you used place su, it could be somewhere else than /system/bin, like /system/xbin or /system/sbin -- yet another reason not to use toolkits...]
Toolkits don't teach you that.
And for you follow-up question, the answer is no (if you are talking about updates). If you update using an OTA update, the update does not delete those two files, but it does change the permissions on them to disable root access.
Thanks Efrant! I'll try this out. Yeah, being lazy definitely didn't help me here
I used to flash my Vibrant all the time, but I got the Nexus so that hopefully I wouldn't need anything besides stock (for which I love the experience), so I'm just trying to stay as pure as possible
Thanks again, appreciate it!
shadrage said:
Thanks Efrant! I'll try this out. Yeah, being lazy definitely didn't help me here
I used to flash my Vibrant all the time, but I got the Nexus so that hopefully I wouldn't need anything besides stock (for which I love the experience), so I'm just trying to stay as pure as possible
Thanks again, appreciate it!
Click to expand...
Click to collapse
Give it a shot, and if you are having issues, post here and I'll guide you through it.
Appreciate it! I'll be fiddling around with it either tomorrow or the next day--pretty slammed this week.
Thanks again.
Let me know
shadrage, let me know what you figure out, and how you went about it, I'm stuck trying to figure out the same thing. If I figure it out, I'll give you instructions here.
nodnerb said:
shadrage, let me know what you figure out, and how you went about it, I'm stuck trying to figure out the same thing. If I figure it out, I'll give you instructions here.
Click to expand...
Click to collapse
It's very simple. If you still have root, just use root explorer and delete two files:
1) /system/app/Superuser.apk
2) the second file is su, and it could be in one of three places, depending on how you rooted:
/system/bin/su OR
/system/sbin/su OR
/system/xbin/su
That's it.
If you do not have root, go to the dev section and find an insecure boot image for the version of Android that you are running, download it, rename it to boot.img (if it isn't already), and place it in the same directory on your PC as you fastboot.exe and adb.exe files. Then boot into fastboot mode, plug your phone into your PC and type the following:
fastboot boot boot.img (wait for the device to boot)
adb remount
adb shell
rm /system/app/Superuser.apk
rm /system/bin/su
rm /system/sbin/su
rm /system/xbin/su
Done.
Now if you do not have root, and your bootloader is locked (and you are running 4.0.4), then you are out of luck. You will need to unlock your bootloader (which will wipe your data), and do the second method above/
Thanks
Thanks Efrant.
I'm trying to learn the ins and outs of adb, and it confuses me to no end. I'm slowing remembering playing with my dad's DOS computer when I was a kid, so command prompt and shell type work is coming back, but not easily.
efrant said:
This is another example of the pitfalls of trying to take shortcuts by using toolkits. Toolkits are fine to save time for those that understand what the toolkit is doing, but if you don't have that knowledege base, yo really should do things manually first, in order to learn. (In school, they don't let you use a calculator until you can add/sub/mult/div for a reason).
. . .
Click to expand...
Click to collapse
Exactly!
And how to only remove Superuser data?
I mean, I want Superuser to ask me again if I grant or not superuser-permision.
I need this because I have in Superuser 5 times Titanium Backup.
All has the same id but only one has the Titanium Backup icon and the other doesn't.
And if I try deleting the app from the list... the app just go to "Denied" but still there.
So, I want to delete the whole data so I get a clean list of apps.
Thanks!
settings >> apps >> all apps >> super user
clear cache, clear data
3rdstring said:
settings >> apps >> all apps >> super user
clear cache, clear data
Click to expand...
Click to collapse
Thanks man! I cannot believe I did not try that before.
Thanks!
efrant said:
If you do not have root, go to the dev section and find an insecure boot image for the version of Android that you are running, download it, rename it to boot.img (if it isn't already), and place it in the same directory on your PC as you fastboot.exe and adb.exe files. Then boot into fastboot mode, plug your phone into your PC and type the following:
fastboot boot boot.img (wait for the device to boot)
adb remount
adb shell
rm /system/app/Superuser.apk
rm /system/bin/su
rm /system/sbin/su
rm /system/xbin/su
Done.
Now if you do not have root, and your bootloader is locked (and you are running 4.0.4), then you are out of luck. You will need to unlock your bootloader (which will wipe your data), and do the second method above/
Click to expand...
Click to collapse
Having the same issue (I'm about to return the phone for a replacement so I want Superuser gone).
Can you maybe possibly kindly point me toward a good boot version of the file you're talking about? I'm running a Verizon Galaxy Nexus and I'm on version 4.0.4 Build IMM76K.
I found this link: http://forum.xda-developers.com/showthread.php?t=1631796 ...but I'm unsure what I should be downloading, renaming and throwing into my fastboot folder.
I understand I'll have to unlock the bootloader, but I'm going to wipe anyway since I'm sending it back. Any help with that part would be appreciated too.
Sorry if this is an unauthorized thread resurrection.
USA Prime Credit Peggy said:
Having the same issue (I'm about to return the phone for a replacement so I want Superuser gone).
Can you maybe possibly kindly point me toward a good boot version of the file you're talking about? I'm running a Verizon Galaxy Nexus and I'm on version 4.0.4 Build IMM76K.
I found this link: http://forum.xda-developers.com/showthread.php?t=1631796 ...but I'm unsure what I should be downloading, renaming and throwing into my fastboot folder.
I understand I'll have to unlock the bootloader, but I'm going to wipe anyway since I'm sending it back. Any help with that part would be appreciated too.
Sorry if this is an unauthorized thread resurrection.
Click to expand...
Click to collapse
Follow the instructions in this thread. It will take you back to stock, and there are instructions on re-locking the bootloader as well.
Had to restock my Nexus as well. but my USB didnt work so I decided to take my losses and just return it, rooted with Superuser.
I had spend 2 days trying to restock it. and then this Tech Guy from my Carrier Tells me...
O you have rooted your Phone. Well that might be a problem with the insurance... unless you got a Nexus Device.
I was like what do you mean.
wel with all nexus devices you are allowed to root your phone.
So I think this is the best Solution there is . just take it back and save yourself some time.
this really works!!!!
shadrage said:
Hi, I've got a noob question here: How do I properly remove Super User from my GSM Galaxy Nexus?
I used Wugs Root Toolkit and it applied some "permanent" superuser method. My question is, how can I go about deleting the files so that the APK is no longer on my phone? I don't mind rooting again if that's what is required to remove it.
I searched around and didn't find an answer--that said if this has already been answered somewhere before I apologize--maybe I just all around fail! I saw some posts that related to the Hero but yeah... pretty sure it doesn't apply to the GNex.
Thanks! Oh, and don't ask me why I want to do this, yeah yeah, I know I must be out of my mind. A follow-up question though, would be that if I decide to root again after this, is there a method of pushing superuser where it will be removed whenever the stock ROM is updated?
Thanks again!
Click to expand...
Click to collapse
1. after you have or have not unrooted, search up superuser on playstore
2. click uninstall, if it says uninstalling........, ignore that and go to home page
3. go to folder and delete cwm-root thingy(the zip file you copied to your folder when you rooted) and delete that(seriously, thats important)
4. make sure you have the root remover file in your external sd card
5. turn off device, reboot by holding power and down/left
6. select install zip from sd card and install the root remover file
7. reboot and superuser should be gone lol
keep in mind that i did this on my galaxy tab 2 10.1 so it will definitely work on that
should work with any device
hope this helped
lol
wow, old thread...
I have use root explorer to delete the Superuser.apk and system/bin/su
but once i restart my device, those two thing happen again and again.
Help!!!
[HOW-TO] [GSM & CDMA] How to root without unlocking bootloader (for ITL41D to JRO03O)
As of Oct 10, 2012: Google has patched this vulnerability starting with JRO03U. That is to say, this works on versions of ICS and JB from ITL41D to JRO03O inclusive. It will not work for JRO03U or newer. (My previous guide found here only worked on Android versions 4.0.1 and 4.0.2, i.e., ITL41D/F and ICL53F.
Once you have root, you can use segv11's BootUnlocker app to unlock your bootloader without wiping anything. Easy as pie!
Disclaimer: I take no credit for this exploit or the implementation of it. All credit goes to Bin4ry and his team. I just isolated the parts required for the GNex, modified it slightly and eliminated the script.
So, it looks like Bin4ry (with the help of a couple of others) has managed to find a way to exploit a timing difference in the "adb restore" command. See source here. (Although this may be old news to some, I hadn't seen it before a few days ago.) This is more for informational purposes, as having a Nexus device, we are able to backup our data, unlock the bootloader and restore the backup, so this is guide is not really that useful for most, but you still have those users who are scared to unlock their bootloader. It is useful however, for those with a broken power button, as it allows them to unlock their bootloader without the power button.
How this works
The way this works is as follows: the "adb restore" command needs to be able to write to /data to restore a backup. Because of this, we can find a way to write something to /data while this is being done. Now, Android parses a file called /data/local.prop on boot. If the following line exists in local.prop, it will boot your device in emulator mode with root shell access: ro.kernel.qemu=1. So, if we can place a file called local.prop with the aforementioned line in /data, once your device boots, it will boot in emulator mode and the shell user has root access, so we now can mount the system partition as r/w.
So what does this all mean:
You can now root any version of ICS and JB released to-date without having to unlock your bootloader (and without losing your data).
Moreover, you should now be able to root your device even if your hardware buttons are not working.
Additionally, this allows those who have not received an OTA update and want to apply it without having an unlocked bootloader or root to do so by copying the OTA update to /cache from /sdcard.
Notes:
1) Please read the entire post before attempting this.
2) This does not wipe any of your data, but I take no responsibility if something happens and you lose your data. Maybe consider doing a backup as per this thread before attempting this.
3) This assumes that you have USB Debugging enable on your device (Settings > Developer Options > Enable USB Debugging) and the drivers for your device installed on your computer. For the drivers, I would recommend you remove all old drivers and install these. If you don't know how to install them, or are having issues, look here.
4) This obviously needs to be done over ADB, as you cannot run adb in a terminal emulator on-device. If you do not have ADB, I've attached it in the zip (Windows and Linux versions). Unzip all files.
Step-by-step:
1) Download the attached files to your computer and unzip them;
2) Open a command prompt in that same directory;
3) Copy the root files to your device:
adb push su /data/local/tmp/su
adb push Superuser.apk /data/local/tmp/Superuser.apk
4) Restore the fake "backup": adb restore fakebackup.ab Note: do not click restore on your device. Just enter the command into the command prompt on your PC and press the enter key.
5) Run the "exploit": adb shell "while ! ln -s /data/local.prop /data/data/com.android.settings/a/file99; do :; done" Note: when you enter this command, you should see your adb window flooded with errors -- this is what is supposed to happen.
6) Now that the "exploit" is running, click restore on your device.
7) Once it finishes, reboot your device: adb reboot Note: Do not try and use your device when it reboots. Running this exploit will reboot your device into emulator mode, so it will be laggy and the screen will flicker -- this is normal.
8) Once it is rebooted, open a shell: adb shell
Note: Once you do step 8, your should have a root shell, i.e., your prompt should be #, not $. If not, it did not work. Start again from step 4. (It may take a few tries for it to work. Thanks segv11.)
Now we can copy su and Superuser.apk to the correct spots to give us root.
9) Mount the system partition as r/w: mount -o remount,rw -t ext4 /dev/block/mmcblk0p1 /system
10) Copy su to /system: cat /data/local/tmp/su > /system/bin/su
11) Change permissions on su: chmod 06755 /system/bin/su
12) Symlink su to /xbin/su: ln -s /system/bin/su /system/xbin/su
13) Copy Superuser.apk to /system: cat /data/local/tmp/Superuser.apk > /system/app/Superuser.apk
14) Change permissions on Superuser.apk: chmod 0644 /system/app/Superuser.apk
15) Delete the file that the exploit created: rm /data/local.prop
16) Exit the ADB shell: exit (May have to type exit twice to get back to your command prompt.)
17) Type the following (not sure if this is needed for the GNex, but it shouldn't matter): adb shell "sync; sync; sync;"
18) Reboot: adb reboot
19) Done. You now should have root without having to unlock your bootloader. If you want to unlock now, you can without wiping anything. See segv11's app linked at the beginning of this post.
Note: If you still do not have root access after doing these steps, redo them and add this step between 10 and 11:
10b) Change the owner of su: chown 0.0 /system/bin/su (Thanks maxrfon.)
I've done all. It installs supersuser app but the phone is not really rooted and apps that requires it doesn't work
Lorenzo_9 said:
I've done all. It installs supersuser app but the phone is not really rooted and apps that requires it doesn't work
Click to expand...
Click to collapse
Did you try opening the Superuser app?
What happens when you open an app that requires root? Do you get the request for su access?
You can open the app but whith apps that requires root there are no requestes and they don't... Even using root checker you see that you're not rooted
Lorenzo_9 said:
You can open the app but whith apps that requires root there are no requestes and they don't... Even using root checker you see that you're not rooted
Click to expand...
Click to collapse
Re-run the entire procedure again (including pushing the su and Superuser.apk files). When I had done it, I used the latest version of su and Superuser.apk, but when I uploaded the files in the attachment in post #1, I used the files that Bin4ry had in his package, which I assume are older. Regardless, re-download the attachment in the first post and try it again.
efrant said:
Re-run the entire procedure again (including pushing the su and Superuser.apk files). When I had done it, I used the latest version of su and Superuser.apk, but when I uploaded the files in the attachment in post #1, I used the files that Bin4ry had in his package, which I assume are older. Regardless, re-download the attachment in the first post and try it again.
Click to expand...
Click to collapse
Ok I'll do it and then I'll report you what happens. So now have you updated su and superuser.apk?
Lorenzo_9 said:
Ok I'll do it and then I'll report you what happens. So now have you updated su and superuser.apk?
Click to expand...
Click to collapse
Yes, I put the latest versions in the zip in the first post.
I can confirm that this works, and also that step 10b was not needed for me. This is the first time I have not used a toolkit so if I can do it, anyone can.
Running a Verizon Galaxy Nexus, this allowed me to update to the leaked Jelly Bean OTA with a locked bootloader. I first flashed stock 4.0.4 and locked the bootloader. I then used the exploit to gain root access, allowing me to apply IMM76Q and JRO03O OTA updates via stock recovery. (Rebooting between updates.) Thank you for creating a guide that this newb could easily understand and follow.
serty4011 said:
I can confirm that this works, and also that step 10b was not needed for me. This is the first time I have not used a toolkit so if I can do it, anyone can.
Running a Verizon Galaxy Nexus, this allowed me to update to the leaked Jelly Bean OTA with a locked bootloader. I first flashed stock 4.0.4 and locked the bootloader. I then used the exploit to gain root access, allowing me to apply IMM76Q and JRO03O OTA updates via stock recovery. (Rebooting between updates.) Thank you for creating a guide that this newb could easily understand and follow.
Click to expand...
Click to collapse
Thanks for confirming that step was not needed.
Thanks!
Bookmarked for future reference :good:
does it work on nexus 7 ?
dacc said:
does it work on nexus 7 ?
Click to expand...
Click to collapse
Yes, it should.
thans for quick response
Works fine for my GNex, big thanks! How about putting it into a script for non-advanced users here?
wictor1992 said:
Works fine for my GNex, big thanks! How about putting it into a script for non-advanced users here?
Click to expand...
Click to collapse
Glad you got it working!
As for putting it into a script, I could but I'd rather not. As with most of the guides that I have written up, I purposely do not put things into a script so that people would actually go through all the steps and, by doing so, maybe get an understanding of what they are actually doing, and hopefully learn something in the process. If I would have packaged it up into a script, a lot of the less experienced users would not even try to go through the steps -- they would just use the script, and no one learns anything yet again. See here for some discussion on one-click scripts. Granted, blindly following a step-by-step is not much better, but I have tried to put comments and explanations throughout to facilitate learning. It's about the journey...
P.S.: I would appreciate it if no one else posts a script in this thread.
efrant said:
P.S.: I would appreciate it if no one else posts a script in this thread.
Click to expand...
Click to collapse
can i make a script that just puts in big text "STOP USING TOOLKITS AND 1 CLICKS"
Zepius said:
can i make a script that just puts in big text "STOP USING TOOLKITS AND 1 CLICKS"
Click to expand...
Click to collapse
LOL! Yes, sure, that's one script I don't mind being posted. LOL!
Heh, fair enough. I think I'm learning a bit about adb
One question: I can't replace system APKs by installing them, it tells me that there is a signature conflict. How can I fix that? I thought it shouldn't happen after rooting. (I'm trying to install the "international" velvet.apk).
wictor1992 said:
Heh, fair enough. I think I'm learning a bit about adb
One question: I can't replace system APKs by installing them, it tells me that there is a signature conflict. How can I fix that? I thought it shouldn't happen after rooting. (I'm trying to install the "international" velvet.apk).
Click to expand...
Click to collapse
Let's try to keep this thread on-topic please.
But to answer your question, don't install the apk. Using a file explorer that has root access, copy it to /system/app (after making sure that system is r/w) and make sure the permissions are set to match the other apks in that directory.
when running adb after running the command where i tell it to restore fake restore and then while the "exploit" is running ikeep getting , in cmd, link failed, no such file or directory, and it just keep doing that. is this normal or did i do something wrong.
efrant said:
Let's try to keep this thread on-topic please.
But to answer your question, don't install the apk. Using a file explorer that has root access, copy it to /system/app (after making sure that system is r/w) and make sure the permissions are set to match the other apks in that directory.
Click to expand...
Click to collapse
One click root with impactor now works. Works on <4.3. No need for unlocked bootloader. Does not wipe data.
http://www.saurik.com/id/17
Copy over the superuser.apk and the such binary onto your phone, then use the MV command to move it to /system/app and /system/xbin respectively.
Beamed from my Grouper
Mach3.2 said:
Copy over the superuser.apk and the such binary onto your phone, then use the MV command to move it to /system/app and /system/xbin respectively.
Beamed from my Grouper
Click to expand...
Click to collapse
What should the permissions on each be?
EDIT: Can you alternatively only push the su binary and download superuser from gplay?
krackers said:
What should the permissions on each be?
EDIT: Can you alternatively only push the su binary and download superuser from gplay?
Click to expand...
Click to collapse
If the binary is wrong, the one from play store may not work.
Permission should be rw-r-r(0644) for the su.apk and rwsr-sr-x(0645) for the su binary.
Beamed from my Maguro.
I tried it myself and while it appears that commands do run, they don't appear to work. I think it might have to do with running as system vs running as root. Why else would saurik use an indirect method of gaining root (using ro.kernel.quemu) as opposed to directly pushing the su binaries.
krackers said:
I tried it myself and while it appears that commands do run, they don't appear to work. I think it might have to do with running as system vs running as root. Why else would saurik use an indirect method of gaining root (using ro.kernel.quemu) as opposed to directly pushing the su binaries.
Click to expand...
Click to collapse
This is correct: sometime in the Android 4.1 release cycle, they removed the ability to use /data/local.prop as an attack vector to go from system->root. The signature bug lets you modify the code of any APK, but the most powerful user an app can ever run as is system, not root.
However, in an update to Impactor today, I've added a system->root escalation. This allows one-click rooting, and even though the system->root I'm using has already been patched in AOSP (the idea was not to waste something to go along with a shell->system that is already long burned) it works on my 4.2.2 Nexus 4 (and so I'd imagine will also work fine on a Galaxy Nexus) as Android sucks at getting patches to real devices ;P.
Using Impactor on my Panasonic Eluga dl01 does somehow not work.
(Android 4.0.4)
I get following error message:
/data/local/tmp/impactor-6[3]: /data/local/tmp/impactor-4: Operation not permitted
I also tried and played around with the command line in Impactor.
"adb devices" won't list my phone
But when I use the adb from the current Android SDK I just installed, it will display my phone with "adb devices".
I also downloaded a ICS 4.04 root zip file with a script and adb files inside. When using that adb version, my phone won't be displayed too. Now when I run adb from the android SDK, it will say something like "server is outdated" then something like "kill and restart with new server" --> "adb devices" lists my phone correctly again.
May be the adb version used in Impactor is outdated and responsible for the error message?
I would really appreciate any help with this topic, because the Panasonic Eluga phone was never rooted until now and no known root method is available. I always kinda hoped that someone would use the masterkey thing to make a universal rooting tool
saurik said:
This is correct: sometime in the Android 4.1 release cycle, they removed the ability to use /data/local.prop as an attack vector to go from system->root. The signature bug lets you modify the code of any APK, but the most powerful user an app can ever run as is system, not root.
However, in an update to Impactor today, I've added a system->root escalation. This allows one-click rooting, and even though the system->root I'm using has already been patched in AOSP (the idea was not to waste something to go along with a shell->system that is already long burned) it works on my 4.2.2 Nexus 4 (and so I'd imagine will also work fine on a Galaxy Nexus) as Android sucks at getting patches to real devices ;P.
Click to expand...
Click to collapse
Do you need to have an unlocked bootloader for the root exploit to work? I am hoping to get root without having to wipe the device by unlocking.
To the poster above me: Try using a different computer and if that doesn't work, switch operating systems.
krackers said:
Do you need to have an unlocked bootloader for the root exploit to work? I am hoping to get root without having to wipe the device by unlocking.
Click to expand...
Click to collapse
That's the whole point in securing Android, not that people have easier ways instead of unlocking a device.
Tested and works great. I now have root. Yay!
Does it show any of the problems that chainfire's superSU 1.41 shows?
Sent from my Galaxy Nexus using xda app-developers app
The root exploit only places the su binary and sets the right permissions. You can use any root manager you want (I used clockworkmod's superuser app).
mercuriussan said:
Using Impactor on my Panasonic Eluga dl01 does somehow not work.
(Android 4.0.4)
Click to expand...
Click to collapse
The feature of installing su will not work on every device: a lot of emphasis is put on "rooting" Android devices, but on many devices even root can't do things like modify the files in /system; I'd use the term "jailbreak" as to being what people really want to do with their device, but Android people seem to have that term ;P. What this means is that you really need a kernel exploit, not just a shell->system->root escalation.
mercuriussan said:
I get following error message:
/data/local/tmp/impactor-6[3]: /data/local/tmp/impactor-4: Operation not permitted
Click to expand...
Click to collapse
This error message actually indicates that Impactor succeeded in obtaining root control over your phone. However, when it tried to then, as root, remount /system writable so it could copy the su binary in place, it wasn't allowed to do so. A future version of Impactor will make it easier to drop to a root shell so you can test things out manually, but this means that while you can run code as root, you won't be able to install su.
However, if you have the time to play with it, get a copy of busybox and use adb to push it to /data/local/tmp (this is also something Impactor should help you do, but does not yet). (You will also need to make it executable, don't forget: "chmod 755 /data/local/tmp/busybox".) Then run the suggested Impactor command involving telnetd. Finally, via a shell, run "/data/local/tmp/busybox telnet 127.0.0.1 8899": you are now root.
You can verify that you are root because you will now have a # as a prompt instead of a $. Then run "mount -o remount,rw '' /system" (<- note, that's two single quotation marks as an argument between remount,rw and /system). This is the command that should fail with the "Operation not permitted" message. You are, however, root, so maybe there's something you want to do on the device at that point ;P.
mercuriussan said:
I also tried and played around with the command line in Impactor.
"adb devices" won't list my phone
But when I use the adb from the current Android SDK I just installed, it will display my phone with "adb devices".
Click to expand...
Click to collapse
The "Open Shell" in Impactor connects you to the device via adb: if you run adb on the device and ask for a list of devices attached to the device--something I didn't even realize was possible until you pointed it out here ;P I tested it, though, and wow: that actually is possible--you will get a blank list. However, suffice it to say that if you were able to type that at all, it can see your device.
Thanks for the suggestion, I'll try my luck in finding some exploit I can use...
So since Google patched this in 4.3, does this mean almost all devices before 4.2.2 can be rooted with this method?
bmg1001 said:
So since Google patched this in 4.3, does this mean almost all devices before 4.2.2 can be rooted with this method?
Click to expand...
Click to collapse
Yup - assuming they haven't been patched against the methods used (most haven't been).
Very interesting read. Thanks saurik & OP.
Eluga DL1
Hi there,
this post is in some ways a duplicate but different people seem to follow this thread because it is directly involving sauriks impactor.
Is there anything available that i can throw at Elugas 4.0.4 kernel to get r/w on the system partition?
I will try everything that is suggested to me.
this thread will let you unlock your bootloader without htcdev,or let you change your hboot watermark from relocked or locked back to stock.
originally,we used a zip file flashable in recovery. i have found it to work on gsm devices with 1.44 hboot and CW recovery. it did not work with twrp. if the following is too scary,feel free to test the zip files. that thread,info,and downloads can be found here. since not all recoverys are working,these values can be changed with simple adb commands.
advantages
-no hassle with htcdev,tokens,or unlock codes
-no submitting your phones personal info to htc
-the ability to get back to 100% stock without any visual traces or records of having been s off or unlocking your bootloader.
you do NOT need to downgrade your hboot. this simple adb command works without any scary hboot downgrades.
*you must be s off.
*you must have superuser installed(see this thread if you need help installing superuser. use the keep bootloader locked directions)
read this:
this will not work if your s on. its not a way to magically unlock
the usual disclaimers:
use this info at your own risk. if it melts your phone into a little pile of aluminum goo,its not my fault.
credits
-beaups for giving me the echo comand,so yall didnt need to dump,edit with a hex editor,and copy back
-strace for originally discovering the location of the lock status flag(check out this thread for more info)
-kdj67f for fearlessly testing and putting up some screenshots in post 5. thanks!
IF you are an advanced user with adb/fastboot set up and some basic knowlede of the cmd window,you can skip to #2
1)set up adb
-download this file
-install drivers: if you have htc sync installed,you should allready have drivers. if not,you can install htc sync,or install these modified htc drivers from revolutionary (driver mirror)
-unzip your miniadb_v1031.zip file. this is native funtionality in windows 7. you otherwise may need a utility such as "7-zip" to extract,or unzip it. place the unzipped folder onto the root of your C drive on your PC. root means the top level,not inside any folders. so just copy and paste,or drag and drop the folder onto C with everything else that is there. you may want to rename it to "miniadb_m7" since youll be putting some device specific files in here.
-open a command window. on windows 7,click the start bubble in the lower left and type "command" in the search box. xp i believe is similar or the same. doing this should open a small black command window.
-change to your miniadb_m7 directory. type the following at the prompt in your cmd window:
cd c:\miniadb_m7
your command promt should change to "c:miniadb_m7>" provided you: 1)unzipped the miniadb_v1031 zip file,and 2)put the folder on your c drive,and 3)entered the name of the folder correctly ("miniadb_m7" in this case)
-now make sure usb debugging is checked in developer options(you will need to turn it on first),and plug your phone into your PC with a usb cable
-make sure your phone is being recognized- type:
adb devices
if your drivers are installed correctly,this should return your phones serial number. you should hear the "found device" noises when you plug your phone in. if it starts installing drivers,wait for it to finish before typing the adb devices command.
if you get your serial number back,then enter this command:
adb reboot bootloader
this should take your phone to the "fastboot" screen,wich is white with colored letters. this is one mode of your bootloaders interactive modes. at the top youll see fastboot devices as confirmation youre in fastboot.
now enter:
fastboot devices
again,this should return your phones serial number. you should hear the "found device" noises when you plug your phone in. if it starts installing drivers,wait for it to finish before typing the adb devices command.
if you get your serial number back,you can enter the following to boot back to the phones OS:
fastboot reboot
and now,youve installed adb/fastboot and tested youre phones drivers. if at either spot,you have trouble and dont get your serial number back,there is some sort of connection issue. use these steps to troubleshoot:
troubleshooting connectivity issues:
-try a reboot of the PC
-try different usb cables and ports
-dont use a usb hub
-dont use usb 3.0
-make sure nothing capable of comunicating with the phone is enabled and running. htc sync,pdanet,easy tether,and even itunes have all been known to cause issues.
-windows 8 has been known to have issues. try a windows 7 or older machine
failing the above,
-i use these drivers for fastboot and adb(donwload and run as admin): http://downloads.unrevoked.com/HTCDriver3.0.0.007.exe (mirror)
failing that,try manually updating the drivers in the following manner:
-put the phone in fastboot mode(select fastboot from the hboot menu)
-open device manager on the PC
-plug in phone,watch for it to pop up in device manager.
-update drivers with device manager,pointing the wizard to the extracted
driver download folder from above
note that you can check the connectivity of the phone,and make sure drivers are working by in the following manner:
-open cmd window. change to directory containing adb/fastboot utilities
-adb with the phone in the booted OS,usb debug enabled,enter:
adb devices in a cmd window
-fastboot with phone in fastboot,enter:
fastboot devices in cmd window
in either case,a properly connected phone with working drivers installed should report back the phones serial number.
Click to expand...
Click to collapse
this process,in your cmd window,should look something like this:
Code:
Microsoft Windows [Version 6.1.7601]
Copyright (c) 2009 Microsoft Corporation. All rights reserved.
C:\Users\Scott>[COLOR="red"]cd c:\miniadb_m7[/COLOR]
c:\miniadb_m7>adb devices
* daemon not running. starting it now on port 5037 *
* daemon started successfully *
List of devices attached
FAxxxxxxxxxx device
c:\miniadb_m7>[COLOR="red"]adb reboot bootloader[/COLOR]
c:\miniadb_m7>[COLOR="red"]fastboot devices[/COLOR]
FAxxxxxxxxxx fastboot
c:\miniadb_m7>[COLOR="red"]fastboot reboot[/COLOR]
rebooting...
finished. total time: 0.037s
c:\miniadb_m7>
2)reset your "lock status flag"
to LOCK your bootloader,enter the following:
adb devices
adb shell
su (if needed to get a # prompt)
echo -ne '\x00\x00\x00\x00' | dd of=/dev/block/mmcblk0p3 bs=1 seek=33796
(i would very strongly recomend you copy/paste this)
exit
(exit a second time if you need to to get back to a normal > prompt)
adb reboot bootloader
verify you are now locked
_____________________________________________________________________________________________
to UNLOCK your bootloader,enter the following:
adb devices
adb shell
su (if needed to get a # prompt)
echo -ne "HTCU" | dd of=/dev/block/mmcblk0p3 bs=1 seek=33796
(i would very strongly recomend you copy/paste this)
exit
(exit a second time if you need to to get back to a normal > prompt)
adb reboot bootloader
verify you are now unlocked
*i have tested this on my gsm htc one. if someone wants to test on vzw,ill add you to the credits
mine!
So, this will work with hboot 1.54? And are you sure the memory blocks are correct for Verizon? I will test...
I'm s-off, stock Rom, cwm recovery and rooted.
Sent from my HTC6500LVW using XDA Premium 4 mobile app
kdj67f said:
So, this will work with hboot 1.54? And are you sure the memory blocks are correct for Verizon? I will test...
I'm s-off, stock Rom, cwm recovery and rooted.
Sent from my HTC6500LVW using XDA Premium 4 mobile app
Click to expand...
Click to collapse
99% sure we can certainly dump p3 and have a look-see first,if you'd like. We woukd need a dump from someone whose unlocked or relocked
Sent from my HTC One using Tapatalk 2
99% is good enough for me haha! Phone just hut 50% charged, give me a minute. Will post back with pictures.
Sent from my HTC6500LVW using XDA Premium 4 mobile app
---------- Post added at 08:56 PM ---------- Previous post was at 08:41 PM ----------
Confirmed, code working. Flags set/reset. Phone even reboots and works will upload pics/screenshots.
Thanks!
Starting out unlocked:
Locking:
Locked:
Unlocking:
Re-unlocked:
Very good work!
Awesome! Thanks for confirming
Sent from my HTC One using Tapatalk 2
That was super easy... great write up! This will save so much time getting an unlocktoken and running through HTCdev. Many thanks!
scotty1223 said:
99% sure we can certainly dump p3 and have a look-see first,if you'd like. We woukd need a dump from someone whose unlocked or relocked
Click to expand...
Click to collapse
Verizon HTC One here, S-Off with SuperSU but otherwise stock, locked bootloader, hboot 1.54. I just did
Code:
dd if=/dev/block/mmcblk0p3 of=orig bs=1 seek=33796 count=4
and looked at the resulting dump and it has "PGFS" not nulls at that offset. I'm wondering if we should write "PGFS" back on Verizon/hboot 1.54 and not nulls?
bjorheden said:
Verizon HTC One here, S-Off with SuperSU but otherwise stock, locked bootloader, hboot 1.54. I just did
Code:
dd if=/dev/block/mmcblk0p3 of=orig bs=1 seek=33796 count=4
and looked at the resulting dump and it has "PGFS" not nulls at that offset. I'm wondering if we should write "PGFS" back on Verizon/hboot 1.54 and not nulls?
Click to expand...
Click to collapse
sounds like youre looking at offsets 00 01 02 03. every device ive looked at so far has the PGFS at that location. i havent looked ata vzw p3,but t mobile follows that. youll find the HTCU,HTCL,or nulls at 8404 8505 8406 8407.
im not sure your command is showing you the correct location. id dump and look at the whole thing.
dd if=/dev/block/mmcblk0p3 of=/sdcard/mmcblk0p3
Hey Scotty,
I can't thank you enough for this info. I really didn't want to unlock via htcdev and it's been getting tiring making zips for everything I want to flash. This solved my problem and is reversible without record. You are the man and thanks for putting in the time.
isdnmatt said:
Hey Scotty,
I can't thank you enough for this info. I really didn't want to unlock via htcdev and it's been getting tiring making zips for everything I want to flash. This solved my problem and is reversible without record. You are the man and thanks for putting in the time.
Click to expand...
Click to collapse
glad to help
Can someone explain the benefits to me of being able to change between locked/unlocked? If not.... That's cool.
Sent from my HTC6500LVW using Tapatalk now Free
BaBnkr said:
Can someone explain the benefits to me of being able to change between locked/unlocked? If not.... That's cool.
Sent from my HTC6500LVW using Tapatalk now Free
Click to expand...
Click to collapse
For this thread and most people's needs, unlocking this way after s-off saves time. Re-locking just proved it was reversible in case someone did want to be locked again. Another way to get back to stock for warranty purposes, etc...
Most importantly, to prove it can be done!
Sent from my HTC6500LVW using XDA Premium 4 mobile app
Fantastic, can this work for HTC One S too?
maybe needs finding correct blocks?
what it is unclear to me is that:
your method to unlock bootloader needs S-OFF, but S-OFF needs Unlocked bootloader and SuperCID, so maybe for HTC One S it's different
thanks for clarification
icest0rm said:
Fantastic, can this work for HTC One S too?
maybe needs finding correct blocks?
what it is unclear to me is that:
your method to unlock bootloader needs S-OFF, but S-OFF needs Unlocked bootloader and SuperCID, so maybe for HTC One S it's different
thanks for clarification
Click to expand...
Click to collapse
blocks are the same for one s.
method does indeed need s off. most common way to achieve s off for devices on the unlock program is via intial unlock thru htcdev to install root and recovery. at this point the commands are useful to get back to locked,and if one needs unlock after being locked for some reason. vzw is a bit different in that they cannot use htcdev,so a hack is needed to temproot,then s off. this does give them the luxury of being able to unlock without htcdev alltogether.
its also possible to s off via a java card,or be lucky enuff to find a user trial device that came that way. in this situation htcdev can be left out of the picture entirely.
hope that clarifes it
scotty1223 said:
blocks are the same for one s.
Click to expand...
Click to collapse
ok!
scotty1223 said:
method does indeed need s off. most common way to achieve s off for devices on the unlock program is via intial unlock thru htcdev to install root and recovery. at this point the commands are useful to get back to locked,and if one needs unlock after being locked for some reason.
Click to expand...
Click to collapse
ok...clear
scotty1223 said:
vzw is a bit different in that they cannot use htcdev,so a hack is needed to temproot,then s off. this does give them the luxury of being able to unlock without htcdev alltogether.
Click to expand...
Click to collapse
ehm...sorry...what is vzw?
its also possible to s off via a java card,or be lucky enuff to find a user trial device that came that way. in this situation htcdev can be left out of the picture entirely.
hope that clarifes it
Click to expand...
Click to collapse
thanks :good:
vzw=Verizon wireless
Sent from my HTC One VX using Tapatalk
scotty1223 said:
vzw=Verizon wireless
Sent from my HTC One VX using Tapatalk
Click to expand...
Click to collapse
ah ok...
but since they need a temproot to get unlock without htcdev, wouldn't this be possible for all htc one (s)?
why is it limited to vzw?
icest0rm said:
ah ok...
but since they need a temproot to get unlock without htcdev, wouldn't this be possible for all htc one (s)?
why is it limited to vzw?
Click to expand...
Click to collapse
technically,yes. you could use a temp root and make a tool for any other carriers device so you would not have to unlock.
however, temp root exploits are typically patched quickly. htcdev is a reliable means of root to make other tools/exploits work. its much,much easier to simply unlock and install root and recovery than to keep looking for softwate temp root exploits.
with verizon you have no choice,since they do not allow official unlock.
Hello, can you please tell me why do i get this error ?