[HOW-TO] [GSM & CDMA] Root without Unlocking Bootloader via exploit (for 4.0.1/4.0.2)
Edit: This does not works on anything newer than ICL53F (i.e., 4.0.2). It works fine on ITL41D (4.0.1), ITL41F (4.0.1) and ICL53F (4.0.2)
Once you have got root, you can now 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 (but I will take credit for the step-by step ). Thanks to kendong2 for pointing it out to me here.
So, it looks like zx2c4 has found a local privilege escalation exploit. See source here, and saurik has managed to package it together for Android. See here. Although this may be old news to some, I hadn't seen it before.
So what does this all mean:
If you are running a 2.6.39 kernel (or above), which all Galaxy Nexus' are, you can now root your device 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) 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.
2) This needs to be done over ADB, as a terminal emulator on-device does not have the appropriate access. If you do not have ADB, I've attached it in the zip. Unzip all files.
3) Some users indicate that, once finished the procedure, they needed to open the Superuser app.
Step-by-step:
1) Download the attached files to your computer and unzip them in the same directory as your adb.exe file;
2) Open a command prompt in the same directory;
3) Copy the files to your device:
adb push mempodroid /data/local/tmp/mempodroid
adb push su /data/local/tmp/su
adb push Superuser.apk /data/local/tmp/Superuser.apk
4) Open a shell: adb shell
5) Change permission on mempodroid to allow it to run: chmod 777 /data/local/tmp/mempodroid
6) Run the exploit: ./data/local/tmp/mempodroid 0xd7f4 0xad4b sh
Note: Once you do step 6, your prompt should change from $ to #. If not, it did not work.
7) Mount the system partition as rw: mount -o remount,rw -t ext4 /dev/block/mmcblk0p1 /system
8) Copy su to /system: cat /data/local/tmp/su > /system/bin/su
9) Change permissions on su: chmod 06755 /system/bin/su
10) Copy Superuser.apk: cat /data/local/tmp/Superuser.apk > /system/app/Superuser.apk
11) Change permissions on Superuser.apk: chmod 0644 /system/app/Superuser.apk
12) Mount the system partition as r/o: mount -o remount,ro -t ext4 /dev/block/mmcblk0p1 /system
13) Rescind root: exit
14) Exit the ADB shell: exit
15) Done. You now should have root without having to unlock your bootloader.
Reserved
Reserved
This is the same as https://github.com/saurik/mempodroid
saurik ftw.
times_infinity said:
This is the same as https://github.com/saurik/mempodroid
saurik ftw.
Click to expand...
Click to collapse
Not sure what you are getting at? I mentioned saurik in the first post, and the link you posted is in the first post. And I mentioned that this may be old news, but I haven't seen it anywhere before today in the GN forums.
Yikes! This exploit works on any kernel from 2.6.39 and >. This could become a common root method for many devices. Linus Torvalds himself posted the fix commit! Nice work by zx2c4!
Sleuth255 said:
Yikes! This exploit works on any kernel from 2.6.39 and >. This could become a common root method for many devices. Linus Torvalds himself posted the fix commit! Nice work by zx2c4!
Click to expand...
Click to collapse
You need ics to have a vulnerable kernel version, so given the number of devices which currently have ics officially, I doubt it will be common. I'd also expect Google and vendors to correct this in next release.
Also many custom kernels don't have this flaw as they are at or over 3.0.18 or have patched it. This prevents gaining unnoticed root.
Sent from my Galaxy Nexus
Hmmm I thought 2.6.39 was found in GB builds. This exploit is almost a root fix for the Moto DX 4.5.621 fiasco. Unfortunately the kernel for that build is 2.6.32.9.
Sent from my Galaxy Nexus using xda premium
This was huge in the headlines a few weeks back. It's nice to see someone putting it to a good use!
Sent from my Galaxy Nexus using xda premium
Hi, been lurking awhile, registered to clear up somethings.
I did some research while attempting to access the /data/local/ -folder with terminal emulator and I found that it would be impossible to write or to find it while being unrooted. Rooting a phone through using an unrooted access root seems impossible.
Did I miss something or is there any other way to copy mempodroid to the data- folder? I sure would like to keep all my files.
Huxleysäl said:
Hi, been lurking awhile, registered to clear up somethings.
I did some research while attempting to access the /data/local/ -folder with terminal emulator and I found that it would be impossible to write or to find it while being unrooted. Rooting a phone through using an unrooted access root seems impossible.
Did I miss something or is there any other way to copy mempodroid to the data- folder? I sure would like to keep all my files.
Click to expand...
Click to collapse
I think you are mistaken. In a terminal emulator type: cd /data/local/tmp
Edit: Fixed a mistake made by auto correct...
Sent from my Galaxy Nexus using Tapatalk
efrant said:
I think you are mistaken. In a terminal emulator type: cd /data/local/temp
Sent from my Galaxy Nexus using Tapatalk
Click to expand...
Click to collapse
Just did. It says "No such file or directory."
Not the best source, but if you google it, people state what I state. Sorry, can't post links
try /data/local/tmp
Huxleysäl said:
Just did. It says "No such file or directory."
Not the best source, but if you google it, people state what I state. Sorry, can't post links
Click to expand...
Click to collapse
Sorry, damn auto correct. It should be: cd /data/local/tmp
Not "temp".
It works fine.
Edit: Sleuth255 beat me to it!
Sent from my Galaxy Nexus using Tapatalk
efrant said:
Sorry, damn auto correct. It should be: cd /data/local/tmp
Not "temp".
It works fine.
Edit: Sleuth255 beat me to it!
Sent from my Galaxy Nexus using Tapatalk
Click to expand...
Click to collapse
Sure, OK, it worked. But as I'm trying to replicate his instructions, copying mempodroid to data/local/tmp doesn't compute. I tried extracting the files, puting mempodroid in a new folder in ./sdcard/ (which I named Nex), and it still couldn't find it.
Wait, just had an idea. Brb
Huxleysäl said:
Sure, OK, it worked. But as I'm trying to replicate his instructions, copying mempodroid to data/local/tmp doesn't compute. I tried extracting the files, puting mempodroid in a new folder in ./sdcard/ (which I named Nex), and it still couldn't find it.
Wait, just had an idea. Brb
Click to expand...
Click to collapse
Hmm. Looks like you may be correct. In GB, we had write access to that directory, but it looks like we don't in ICS. I'll have another look tomorrow and try to figure something out.
Sent from my Galaxy Nexus using Tapatalk
OK, this is exactly what I did:
I downloaded the files, extracted them into the ./sdcard folder of my android. I opened the console, wrote exactly as stated. Reaction? Cannot create /data/local/tmp/mempodroid: Permission denied
So, what I'm thinking is this: I tried the cd ./sdcard/mempodroid, found it. So, logically, that should mean that since the permission is dennied, the problem lies not in where I put the mempodroid, but with my authority over my phone. So, here we are again. Could anybody smarter then me clarify?
efrant said:
Hmm. Looks like you may be correct. In GB, we had write access to that directory, but it looks like we don't in ICS. I'll have another look tomorrow and try to figure something out.
Sent from my Galaxy Nexus using Tapatalk
Click to expand...
Click to collapse
****, I was hoping I was wrong. I originally thought that the exploit was this. But alas.
Try finding an alternative write route to the /data/local/- folder. That should solve all problems, I guess. Big words, ey? This is for the simpletons like me, who stupidly forgot to bootload.
Might want to expand on the steps.
Like what program to use to copy the file.
How do you change permission.
How do you run the exploit.
How to mount rw.
How to copy su.
convolution said:
Might want to expand on the steps.
Like what program to use to copy the file.
How do you change permission.
How do you run the exploit.
How to mount rw.
How to copy su.
Click to expand...
Click to collapse
I hade my initial problems with that too. But as if this moment it doesn't really matter. Read above posts. Anyhow, to answer your question: you need to download a console emulator
Just search for it in the market. Also the commands go in this console
For example: cat /directory/filename > /newdirectory/samefilename means to copy or move from one place. To change permission you just write that line of code ending with 777 instead of cat and then the filename etc and etc.
I didn't know any of this 'till yesterday, so it is quite understandable.
cheers
Huxleysäl said:
F***, I was hoping I was wrong. I originally thought that the exploit was this. But alas.
Try finding an alternative write route to the /data/local/- folder. That should solve all problems, I guess. Big words, ey? This is for the simpletons like me, who stupidly forgot to bootload.
Click to expand...
Click to collapse
I've updated the first post. Give that a go and let me know how it turns out. (The guide may need some minor tweaking, but I am here to help you through it.)
It seems that ADB has rw access to /data/local/tmp but a terminal emulator on-device does not. So for now, you need to be plugged into your computer.
It may be possible to do this with ADB-over-Wi-Fi, but I haven't gotten there yet.
Related
I moved from an HD2 to the Evo this week (no more TMobile, woot!). I am very familiar with custom WMO ROMS, Hard SPL, blah blah...
I have nearly zero Android development, custom ROM knowledge, etc, however.
I'd like to flash a custom ROM based on the factory, without all the Sprint programs preloaded.
Clearly I need to root; I am on steady ground with that knowledge. After that? Not so clear. There doesn't seem to be a thread with the steps I need to proceed.
Any info would be invaluable, thanks!
(PS - side question: why does Android launch all sort of processes in the background seemingly at random?)
ifiweresolucky said:
I moved from an HD2 to the Evo this week (no more TMobile, woot!). I am very familiar with custom WMO ROMS, Hard SPL, blah blah...
I have nearly zero Android development, custom ROM knowledge, etc, however.
I'd like to flash a custom ROM based on the factory, without all the Sprint programs preloaded.
Clearly I need to root; I am on steady ground with that knowledge. After that? Not so clear. There doesn't seem to be a thread with the steps I need to proceed.
Any info would be invaluable, thanks!
(PS - side question: why does Android launch all sort of processes in the background seemingly at random?)
Click to expand...
Click to collapse
This should be in Q & A.. But unless someone creates a rom with the apps removed. Its easier to just do it yourself.
If you did toasts method of rooting. Boot into recovery and type this
adb remount
adb shell
cd /system/app
ls
This displays all apps on the phone. Do this to delete them.
rm NameOfApp.apk
rm NameOfApp.odex
It is caps sensitive and make sure you type the apk exactly as its written.
Jus10o said:
This should be in Q & A.. But unless someone creates a rom with the apps removed. Its easier to just do it yourself.
If you did toasts method of rooting. Boot into recovery and type this
adb remount
adb shell
cd /system/app
ls
This displays all apps on the phone. Do this to delete them.
rm NameOfApp.apk
rm NameOfApp.odex
It is caps sensitive and make sure you type the apk exactly as its written.
Click to expand...
Click to collapse
any reason adb remount isn't working for me? I do adb devices and my devices is there but when i type adb remount i get "remount faild: Invalid argument"
I started Toasts root directions, placing PC36IMG.zip on the base directory of the SD card. Shut down, loaded with the Vol Down and Power buttons. The bootloader checked the file on the SD card but then stopped on the white screen.
It seems it was supposed to proceed automatically? But I am dropped off with options on the white screen: FASTBOOT, RECOVERY, CLEAR STORAGE, SIMLOCK, and HBOOT USB.
Directions show Vol Up and Down for previous and next and Power for select.
Alright, I resolved this issue. I recopied the file to the SD card and made sure to eject drive before shutting the device down. Seemed to make all the difference! Proceeding with the remainder of Toast's directions now...
p-slim said:
any reason adb remount isn't working for me? I do adb devices and my devices is there but when i type adb remount i get "remount faild: Invalid argument"
Click to expand...
Click to collapse
I'm running in to the same issue...
rgordon3091 said:
I'm running in to the same issue...
Click to expand...
Click to collapse
i fixed it. you have to do this.
adb shell
mount /dev/block/mtdblock4 /system
cd /system/app
ls
Getting error trying to remove nascar..
Code:
rm Sprint_NASCAR.apk
rm failed for Sprint_NASCAR.apk, Directory not empty
Any ideas?
That's Linux trying to protect you. Essentially the rm command by default just removes one file at a time.
Try...
rm -r NameOfFolder
...to delete recursively.
Sent from my EVO 4G using Tapatalk
Go see the thread in the apps sub-forum about this. I have a post (#28, I believe) with the exact code to remove the bloatware. You can just copy any paste.
-------------
Sent from my HTC EVO 4G using Tapatalk Pro.
nick325i said:
Getting error trying to remove nascar..
Code:
rm Sprint_NASCAR.apk
rm failed for Sprint_NASCAR.apk, Directory not empty
Any ideas?
Click to expand...
Click to collapse
you shouldn't have a problem deleting the apk, because an apk is not a directory.
i deleted it without the same message.
p-slim said:
i fixed it. you have to do this.
adb shell
mount /dev/block/mtdblock4 /system
cd /system/app
ls
Click to expand...
Click to collapse
'
hmmm i put im adb shell then i got a "#" so i put in "mount /dev/block/mtdblock4 /system"
and i got mount:mounting /dev/block/mtdblock4 /system failed: No such file or directory
so what did i do wrong?
Found the issue. Thanks all
Jus10o said:
This should be in Q & A.. But unless someone creates a rom with the apps removed. Its easier to just do it yourself.
If you did toasts method of rooting. Boot into recovery and type this
adb remount
adb shell
cd /system/app
ls
This displays all apps on the phone. Do this to delete them.
rm NameOfApp.apk
rm NameOfApp.odex
It is caps sensitive and make sure you type the apk exactly as its written.
Click to expand...
Click to collapse
By the way, when I "cd /system/app" and then "ls" I see only NamesOfApps.apk. There are displayed no *.odex files. Is that normal?
thread dead?
IDK if this threads still monitored by anyone, but here's my question: I don't use adb, but I just rused root explorer to locate sprint crap, and added a .bak to the end of all of them to essentially 'disable' them. Is this a safe method? Will Android system waste energy looking for them anymore (they no longer show in app tray, but are they still using resources) ? Thanks much.
scottspa74 said:
IDK if this threads still monitored by anyone, but here's my question: I don't use adb, but I just rused root explorer to locate sprint crap, and added a .bak to the end of all of them to essentially 'disable' them. Is this a safe method? Will Android system waste energy looking for them anymore (they no longer show in app tray, but are they still using resources) ? Thanks much.
Click to expand...
Click to collapse
I was just about to say something similar. I had uninstalled Nascar using Titanium Backup, and the found out that I cant do the 2.2 OTA unless its there. TB didn't have the ability to restore it for some reason, so I got an APK from XDA, and put it in the system/app folder via Root Explorer. Then, I had to reset the permissions to match the other APK's, and it showed up and launched perfectly. Even did an update. Much easier than all that adb stuff, I think.
I used system app uninstaller for a buck on the market.. Easy and all there with the icons for easy to find and delete sprint and gapps.
Sent from my PC36100 using XDA App
scottspa74 said:
IDK if this threads still monitored by anyone, but here's my question: I don't use adb, but I just rused root explorer to locate sprint crap, and added a .bak to the end of all of them to essentially 'disable' them. Is this a safe method? Will Android system waste energy looking for them anymore (they no longer show in app tray, but are they still using resources) ? Thanks much.
Click to expand...
Click to collapse
Thats a good way.. If something goes wrong just have to rename.
Sent from my PC36100 using XDA App
Flash this zip and it should remove most of the Sprint apps. It will back them up to /sdx on your SD card so if anything is removed that you want, it will still be there. It's signed to work with RA.
http://grathwohl.me/uploads/android/evo/Sprint-Apps-Remover-signed.zip
I've seen a few people reference my post, but my post was really just trying to ask if anyone knew if, now that I've renamed them, and they don't run, they shouldn't be using up resources? Right, is that correct, or am I wrong in thinkin this?
And thanks cosine83, that's a really helpful post for a lot of people.
There's already a guide here for obtaining permanent root using VISIONary, but some folks in #G2ROOT are having issues with the way that VISIONary modifies parititons. Using rage directly is a bit cleaner, since you know exactly what it's going to touch at each step of the way. I did NOT come up with any of this on my own, I'm building completely off of work that others have done. Speaking of which-
None of this would be possible without the tireless work that scotty2 put in. He stayed with the project for well over a month, through lots of smashed hopes and dead ends, until the solution was finally found. Were it not for his work, as well as the help of a few other key folks- we wouldn't be here. He deserves our thanks and some donations! We're talking hundreds of hours of work here, a couple bucks is not too much for that. His paypal is:
[email protected]Send him some love! I'm not asking for anything myself, because I spent a half hour putting this together, and that doesn't deserve any donations!
[size=+2]G2 ROOT INSTRUCTIONS[/size]
=================================================
These are modified instructions based on the ones posted at http://bit.ly/g2root that use Visionary. A number of people have run into issues with the way that Visionary juggles around temporary partitions, and using the original root exploit is a much easier, and cleaner method for achieving permanent root. This tutorial will walk you through the rooting process by first achieving temporary root, and moving on to permanent root.
[size=+1]REQUIREMENTS[/size]
=================================================
Visionary disabled at boot or uninstalled completely
Android Terminal Emulator app
ADB
vision-combined-root.zip (Attached to this post, OR these two files: )
G2TempRoot.zip (http://forum.xda-developers.com/showthread.php?t=797042) NOTE: only download the files! Don't follow these instructions yet
vision-perm-root.zip (http://forum.xda-developers.com/showthread.php?t=833965) NOTE: again, just download the files from the thread.
In the commands to run below, $ or # represent the prompt and should NOT be entered as part of the commands.
[size=+2]VERY IMPORTANT![/size]Visionary has caused filesystem corruption for some users during the rooting process. Before attempting the instructions below, make sure that you have "auto run on boot" turned OFF, and reboot your system. Since you will not need visionary anyway after this, you might as well just uninstall visionary and reboot NOW before doing anything.
[size=+1]TEMP ROOT[/size]
=================================================
ON YOUR PC:
Unzip the G2TempRoot files to a folder. From a cmd window or terminal, navigate to that folder and execute these commands:
Code:
$ adb push su /sdcard/su
$ adb push Superuser.apk /sdcard/Superuser.apk
$ adb push rage /data/local/tmp/rage
$ adb push busybox /data/local/tmp/busybox
$ adb push root /data/local/tmp/root
$ adb shell chmod 0755 /data/local/tmp/*
ON YOUR PHONE:
Launch Terminal Emulator
/data/local/tmp/rage
Wait for the message: "Forked #### childs."
Menu > Reset Term - Terminal Emulator will exit.
Launch Terminal Emulator, it Force Closes. Launch a second time, and you'll have a root shell
**NOTE**: in the original directions from the XDA thread, you are instructed to run the /data/local/tmp/root script here. DON'T do this
just yet. Leave the terminal window open.
[size=+1]PERM ROOT[/size]
=================================================
ON YOUR PC:
unzip the vision-perm-root.zip and navigate to that folder. There will be four files. You will need to push two of these to your phone- hboot-eng.img, and one of the wpthis-[..].ko files.
If you HAVE applied the OTA update, push wpthis-OTA.ko.
If you HAVE NOT applied the OTA update, push wpthis-pre-OTA.ko.
Code:
$ adb push hboot-eng.img /data/local
$ adb push wpthis-OTA.ko /data/local
ON YOUR PHONE:
You should still have terminal emulator up, at a root prompt. Now run:
Code:
# insmod /data/local/wpthis-OTA.ko
You should see:
Code:
init_module 'wpthis-OTA.ko' failed (Function not implemented)
That means it worked. This next step is CRUCIAL. You must make sure that you are writing to the proper partition here or you could brick your phone. To be absolutely clear- the partition is mmcblk(zero)p(one)(eight)
Code:
dd if=/data/local/hboot-eng.img of=/dev/block/mmcblk0p18
You should see some messages indicating that it was written. Next, run:
Code:
# /data/local/tmp/root
This will lock in root, and give you 'su' access in the future. Next, run:
Code:
# sync
Now wait at least a minute, just to be safe. After waiting, reboot your phone using the power button. After it finishes starting up, launch the terminal emulator, and type 'su'. You should get the prompt asking you to grant permissions. If you got the prompt, congratulations! You have permanent root!
I used these instructions and they worked brilliantly.
Sounds like it's a little safer than using VISIONary, which some people in the thread are reporting can get confused and not let you root because it thinks you already have root, etc.
I love it when a plan comes together. Perma-root. thanks man, i never had much luck getting visonary to work so this was spot on. worked like a charm
*not smart enough*
*leaves thread*
I really try to leave ADB out of the equation since I'm not comfortable navigating it.... I suppose I could dedicate my time to learning it, but it's not worth it since I would only use it once every two years to root my phone. In 16 hours I'm sure there will probably be a one click perm root method out anyway.
It worked flawlessly!
I always get so stressed when I root my phones, especially without tutorial vids.
I first did my G1 and that worked perfectly fine.
My second attempt at rooting was with my MT3G and that resulted in a bricked device because one of the lines of code was incorrect in the thread.
This, however, was clearly and plainly spelled out exactly to what happened to my phone.
I give you my thanks.
Awesome- glad to hear it's working well for people. If anybody sees areas that I could improve in the description just let me know.
sinistersai4d4d said:
I really try to leave ADB out of the equation since I'm not comfortable navigating it....
Click to expand...
Click to collapse
ADB is worth it IMHO because it makes moving files around easy, whether you're rooted or not. You don't have to turn on SD card storage, you can just do adb pull/push etc to grab or put files when you need them. Worth the effort. The one click root should be out within the next couple days though, you are right about that one.
trigeek,
I already perm rooted earlier, but just wanted to say you gave a very nicely detailed explanation that anyone should be able to follow. Well done!
Great guide. I liked it a lot more than Unforgivens just because it doesn't rely on VisionARY which might mess things up.
Guide worked absolutely great, no problems. I did not try the visionary method first, but for some reason I just felt safer doing it in adb.
Thank you!
Sorry for the noob question...? but does this mean we have fully rooted to G2 and now we can load ROMS on it when they come out ????
Edit: Nevermind I didnt see the sticky
RaffieKol said:
Sorry for the noob question...? but does this mean we have fully rooted to G2 and now we can load ROMS on it when they come out ????
Click to expand...
Click to collapse
You got it!
RaffieKol said:
Sorry for the noob question...? but does this mean we have fully rooted to G2 and now we can load ROMS on it when they come out ????
Edit: Nevermind I didnt see the sticky
Click to expand...
Click to collapse
Custome ROMs, custom Recovery...the whole 9 yards
Thanks for posting this, it was so easy!
Thank you so very much it was a success
this is my first rooting on an android device... im freaking out... but here i go.... if something happens i will just report my phone lost and get a new one i guess ahahah still... im scared.
Issues
I was temp rooted before using rage and then thru Visionary. But I decided to go back to stock till we have permanent root. I perm rooted today using this method. But I'm having the following issues:
1) adb remount
- remount failed: Operation not permitted
2) when using Root Explorer in /system, toggling Mount R/W does not work
- the only way to mount it R/O is thru terminal/adb shell. Once mounted R/O, the only way to mount R/W again is thru a reboot. Issuing mount -o remount ro /system either in terminal or adb shell does not work.
i actually changed my mind... im going to wait for a one click untended root i guess.... to scary...
joackie27 said:
I was temp rooted before using rage and then thru Visionary. But I decided to go back to stock till we have permanent root. I perm rooted today using this method. But I'm having the following issues:
1) adb remount
- remount failed: Operation not permitted
2) when using Root Explorer in /system, toggling Mount R/W does not work
- the only way to mount it R/O is thru terminal/adb shell. Once mounted R/O, the only way to mount R/W again is thru a reboot. Issuing mount -o remount ro /system either in terminal or adb shell does not work.
Click to expand...
Click to collapse
make sure you have debugging enabled.
juanshop said:
i actually changed my mind... im going to wait for a one click untended root i guess.... to scary...
Click to expand...
Click to collapse
Not gonna happen.
then i guess.... im going to jump in it.... wish me luck...
Since my phone's usb is effed, I can't root it via usb. Now, I can install dropbox and put stuff in my phone like the the SU file and ROMS. Can I root using my phone only?
Edit: unrelated. Sorry
convolution said:
Since my phone's usb is effed, I can't root it via usb. Now, I can install dropbox and put stuff in my phone like the the SU file and ROMS. Can I root using my phone only?
Click to expand...
Click to collapse
Nope. How do you know your USB is broken? Sounds more like user error?
Sent from my Galaxy Nexus using xda premium
To my knowledge you need fastboot to unlock and root. That requires USB.
There might be some local privilege escalation vulnerabilities in ICS itself, but those tends to get patched and nobody really bothers to look for them on open devices like the Galaxy Nexus.
you can use mempodroid on 4.0.2 to get a root shell. not sure what you can or can't do from there with a locked bootloader tho.
kendong2 said:
you can use mempodroid on 4.0.2 to get a root shell. not sure what you can or can't do from there with a locked bootloader tho.
Click to expand...
Click to collapse
If you can get a rootshell, you can manually root the phone, just like many people do with the hacked/modified boot.img booted by fastboot. Basically take your temproot and make it a permroot.
1. push modified su-binary and Superuser.apk to phone's /sdcard/.
2. From the (temp) root-shell do approximately the following:
Code:
# mount -o remount,rw /system
# cat /sdcard/su >/system/xbin/su
# cat /sdcard/Superuser.apk /system/app/Superuser.apk
# chmod 06755 /system/xbin/su
# mount -o remount,ro /system
3. Done.
kendong2 said:
you can use mempodroid on 4.0.2 to get a root shell. not sure what you can or can't do from there with a locked bootloader tho.
Click to expand...
Click to collapse
Thanks for this. I was unaware that someone found local privilege escalation exploit for ICS.
I haven't tried it myself, but it would certainly helps those with locked bootloaders (and/or broken hardware buttons or USB ports).
I started a new thread here.
EDIT: It seems that you need to be connected over ADB to get this to work. However, it may work with ADB over Wi-Fi, but I haven't gotten there yet.
Oh thx!
Now, can I flash roms and have CWM without an unlocked bootloader as well?
[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.