Update: One click root has been using this "simple" method since version 2.2.7. If you're rooting your phone for the first time, please try that first. Consider this thread to be purely informational for those who want step-by-step details of how the process works.
I've been suspicious of the joeykrim root method since it was first posted at SDX. I finally got my Epic yesterday and confirmed that is, indeed unnecessary. I don't fault joeykrim though, he ported the working root method from the Moment to the Epic without actually having access to an Epic himself.
Anyways, the joeykrim root method is unnecessarilly complex becuase it works around an RFS permissions bug which loses the setuid bit on the Moment. It appears the Galaxy S phones have this bug fixed, which is why the root methods on the I9000, Vibrant, Captivate, Fascinate, etc., are much simpler.
So, for the simple root:
First, make sure joeykrim root is not installed.
Upgrade to DI18 (not strictly necessary, but you'll want to do it).
Setup a working adb from the Android SDK and whatever drivers are necessary for your platform.
Download rageagainstthecage-arm5.bin from the C skills blog (link removed due to my newbieness) or from any of the one-click root packages.
Download su-2.3.6.1-ef-signed.zip and extract "system/bin/su" and "system/app/Superuser.apk" to a temporary directory you'll be working from.
Enable USB debugging on your phone and connect it to your computer.
Now, open a command prompt/shell on your computer and cd to the appropriate temporary directory. Run:
Code:
adb push rageagainstthecage-arm5.bin /data/local/tmp
adb shell chmod 755 /data/local/tmp/rageagainstthecage-arm5.bin
adb shell /data/local/tmp/rageagainstthecage-arm5.bin
and confirm you have a working root shell. Then continue with:
Code:
adb push su /system/xbin
adb shell chmod 4755 /system/xbin/su
adb install Superuser.apk
That's it! You should have a working root via su & the Superuser package. At least, I did.
Note that the preceeding steps installs Superuser.apk to /data, which is what I prefer to do. This means if you do a "Factory data reset" su will be temporarilly broken until you reinstall the Superuser.apk package. Since installing the package itself doesn't require root, this is easily done after a /data reset.
Also note that I did not perform a /system remount-rw anywhere. At least on my Epic, /system appears to always be mounted read-write so it's an unnecessary step. It's actually the "joeykrim-root.sh" script that remounts /system read-only during the boot process, which is why folks who don't use root kernels have run into this problem before. I'm not sure why joeykrim's script does that, I guess he probably assumed /system is mounted read-only by default. There's arguments that /system should be read-only, but I didn't touch it in case some Samsung stuff depends on it being read-write.
Finally, if you're already rooted via joeykrim or are running a root kernel, there's nothing really to be gained by doing this. I'm just throwing this out there as I perfer to make the minimum invasive changes possible to obtain root.
Wow, that was really informative. To check for Super user you:
Type: adb shell
then type: SU
You should get a # sign if you have root. Correct?
In the original Noobln post method would the Epic keep root even after a wipe therefore not needing to re-apply the superuser apk again? That might be a reason why folks would want to go the more invasive route (considering rooters seems to change ROMS fairly often which requires wipes sometimes). Either way, keeping a copy of the apk file on your SD card is no big deal.
mkasick said:
Also note that I did not perform a /system remount-rw anywhere. At least on my Epic, /system appears to always be mounted read-write so it's an unnecessary step. It's actually the "joeykrim-root.sh" script that remounts /system read-only during the boot process, which is why folks who don't use root kernels have run into this problem before. I'm not sure why joeykrim's script does that, I guess he probably assumed /system is mounted read-only by default. There's arguments that /system should be read-only, but I didn't touch it in case some Samsung stuff depends on it being read-write.
Click to expand...
Click to collapse
This explains a lot of problems! thanks
EDIT- another noob question- why do you prefer to have superuser installed to /system/data- why not put it in /system/app? Also if I want to install busybox where is the best location to put it?
ZenInsight said:
Wow, that was really informative. To check for Super user you:
Type: adb shell
then type: SU
You should get a # sign if you have root. Correct?
Click to expand...
Click to collapse
Once you run rageagainstthecage-arm5.bin, you should get a root-shell automatically every time you run "adb shell" after until you reboot the phone. Yes, you can tell it's a root shell since it uses the "#" prompt. This is the important part to check, since if the exploit doesn't work, you'll have to run it again. But I haven't seen it not work.
After su is installed and you reboot, your steps are correct: run "adb shell", run "su", then you'll be prompted on the phone scren to authorize access and once you allow it you'll end up with a "#" prompt.
ZenInsight said:
In the original Noobln post method would the Epic keep root even after a wipe therefore not needing to re-apply the superuser apk again?
Click to expand...
Click to collapse
noobnl installs Superuser.apk to /system, you can do that here too. Just replace the "adb install Superuser.apk" step with "adb push Superuser.apk /system/app". It's independent of the joeykrim scripts.
With my captivate we have many update.zip root methods to choose from. Any chance this will be coming to the epic? Have a friend with an epic and command lines would be too much and one click didn't work.
Sent from my SAMSUNG-SGH-I897 using XDA App
jimmyz said:
why do you prefer to have superuser installed to /system/data- why not put it in /system/app?
Click to expand...
Click to collapse
I prefer to keep consistent with the idea that user-installed applications go in /data, and stock-installed-and-unmodified applications remain in /system/app. This way, upgrading Superuser.apk doesn't require a root-shell/root-explorer, you can remove it or upgrade it the way you do with any user installed application--adb install, side-loading via an sdcard, or downloading it from the market.
Plus, in general I prefer to keep my /system as untouched as possible. For example, I don't remove stock apps either. The "su" binary has to be installed in /system to persist after a /data wipe, and busybox is best installed to /system so it's in PATH (haven't looked into modifying the default PATH yet). Otherwise I try to keep /system alone.
jimmyz said:
Also if I want to install busybox where is the best location to put it?
Click to expand...
Click to collapse
Android's default PATH provides four places for busybox to be installed: /sbin, /system/bin, /system/sbin, and /system/xbin. /sbin is part of the initramfs, in other words it's controlled by the kernel you're running. You can install busybox to any of the three /system/*bin directories, but I prefer /system/xbin.
In the traditional Unix conventions, "/usr/bin" is for user-runnable stock-installed programs, and "/usr/sbin" is for root-requiring (superuser-runnable) stock-installed programs. "xbin" isn't part of the standard convention, but I'd guess it's intended for "extra binaries" that are not part of the stock installation (much like /usr/local/bin), thus it seems like an appropriate location for a user-added "su" and "busybox" programs.
The second reason is that "xbin" is relatively empty, so if you want to create the applet symlinks (i.e., so that you can call "cp" instead of "buybox cp") it won't overwrite the stock toolbox symlinks. Also, since "xbin" is last on the default PATH, any programs provided by both toolbox and busybox will default to the toolbox version--which would be important for stock system scripts that might run into compatibility issues if they were to use the busybox versions instead.
To install busybox, grab a copy of the binary from somewhere (one click packages, a copy of stericson.busybox.apk, etc.). Then, once rooted run:
Code:
adb push busybox /data/local/tmp
adb shell
su # Authorize on phone screen
cat /data/local/tmp/busybox > /system/xbin/busybox
chown root.shell /system/xbin/busybox
chmod 755 /system/xbin/busybox
rm /data/local/tmp/busybox
/system/xbin/busybox --install -s /system/xbin
jhnstn00 said:
With my captivate we have many update.zip root methods to choose from. Any chance this will be coming to the epic?
Click to expand...
Click to collapse
I don't believe so. The I9000/Vibrant/Captivate have recoveries that don't check the signature of update.zip (as I understand, or maybe they do but only require test keys) which makes rooting-via-recovery possible. Unfortuntaely the Epic and Fascinate do perform signature checks, so we can't enable root via stock-recovery.
That said, the Fascinate one-click methods should also work on the Epic. Although depending on why your friend couldn't get the Epic one-click to work, the Fascinate one may not work either.
mkasick said:
I prefer to keep consistent with the idea that user-installed applications go in /data, and stock-installed-and-unmodified applications remain in /system/app. This way, upgrading Superuser.apk doesn't require a root-shell/root-explorer, you can remove it or upgrade it the way you do with any user installed application--adb install, side-loading via an sdcard, or downloading it from the market.
Plus, in general I prefer to keep my /system as untouched as possible. For example, I don't remove stock apps either. The "su" binary has to be installed in /system to persist after a /data wipe, and busybox is best installed to /system so it's in PATH (haven't looked into modifying the default PATH yet). Otherwise I try to keep /system alone.
Android's default PATH provides four places for busybox to be installed: /sbin, /system/bin, /system/sbin, and /system/xbin. /sbin is part of the initramfs, in other words it's controlled by the kernel you're running. You can install busybox to any of the three /system/*bin directories, but I prefer /system/xbin.
In the traditional Unix conventions, "/usr/bin" is for user-runnable stock-installed programs, and "/usr/sbin" is for root-requiring (superuser-runnable) stock-installed programs. "xbin" isn't part of the standard convention, but I'd guess it's intended for "extra binaries" that are not part of the stock installation (much like /usr/local/bin), thus it seems like an appropriate location for a user-added "su" and "busybox" programs.
The second reason is that "xbin" is relatively empty, so if you want to create the applet symlinks (i.e., so that you can call "cp" instead of "buybox cp") it won't overwrite the stock toolbox symlinks. Also, since "xbin" is last on the default PATH, any programs provided by both toolbox and busybox will default to the toolbox version--which would be important for stock system scripts that might run into compatibility issues if they were to use the busybox versions instead.
To install busybox, grab a copy of the binary from somewhere (one click packages, a copy of stericson.busybox.apk, etc.). Then, once rooted run:
Code:
adb push busybox /data/local/tmp
adb shell
su # Authorize on phone screen
cat /data/local/tmp/busybox > /system/xbin/busybox
chown root.shell /system/xbin/busybox
chmod 755 /system/xbin/busybox
rm /data/local/tmp/busybox
/system/xbin/busybox --install -s /system/xbin
Click to expand...
Click to collapse
You sir are a true gentleman! Thank you for the informative answers- its great to have you over here! I have one more question- why can't I usually push directly to /system ?
jimmyz said:
why can't I usually push directly to /system ?
Click to expand...
Click to collapse
Pushing directly to /system requires running the adb service on the phone as the root user, so that it has permissions to write to that directory. Usually adb runs on the phone unprivileged, so you can only push to world-writable directories.
Running rageagainstthecage-arm5.bin actually changes this. The exploit forces the adb service to run as the root user, which is why "adb shell" gives you a root shell and "adb push" to /system does work, until the phone is restarted.
Interesting enough, the adb service also runs as root by default in the Android emulator. So there's probably a configuration setting, somewhere, to make it do that. In general it's safer to run adb unprivileged though, and "su" to move files to /system once uploaded elsewhere on the phoe.
mkasick said:
Pushing directly to /system requires running the adb service on the phone as the root user, so that it has permissions to write to that directory. Usually adb runs on the phone unprivileged, so you can only push to world-writable directories.
Running rageagainstthecage-arm5.bin actually changes this. The exploit forces the adb service to run as the root user, which is why "adb shell" gives you a root shell and "adb push" to /system does work, until the phone is restarted.
Interesting enough, the adb service also runs as root by default in the Android emulator. So there's probably a configuration setting, somewhere, to make it do that. In general it's safer to run adb unprivileged though, and "su" to move files to /system once uploaded elsewhere on the phoe.
Click to expand...
Click to collapse
I am learning a lot!!! Could you take a look at koush's kernel here, with it I noticed that when using adb I got the # prompt right away and was able to push to /system- maybe he was able to figure out the config settings? Once again thanks!!!
one more ? (feel free to ignore this one) what actually happens when you do
Code:
adb shell /data/local/tmp/rageagainstthecage-arm5.bin
and how does that give you permanent root?
mkasick said:
Pushing directly to /system requires running the adb service on the phone as the root user, so that it has permissions to write to that directory. Usually adb runs on the phone unprivileged, so you can only push to world-writable directories.
Running rageagainstthecage-arm5.bin actually changes this. The exploit forces the adb service to run as the root user, which is why "adb shell" gives you a root shell and "adb push" to /system does work, until the phone is restarted.
Interesting enough, the adb service also runs as root by default in the Android emulator. So there's probably a configuration setting, somewhere, to make it do that. In general it's safer to run adb unprivileged though, and "su" to move files to /system once uploaded elsewhere on the phoe.
Click to expand...
Click to collapse
It is indeed a config option in default.prop. However, this is in the initramfs and you can't change it on the fly, so you need to rebuild the kernel to change it. With some work you can modify the stock kernel to do it, but I personally haven't tried it.
Sent from my Epic 4G using XDA App
Thank you, this worked perfectly for me, running stock DI18 ROM that I flashed tonight!!! I confirmed by installing the wireless tethering pre-9 apk, and successfully ran the wireless tethering without any errors.
Quick question: do we need to do this after root or is it not needed?
NEEDED?? ===> SuperUser App to help with Security Concerns for the Epic - h**p://forum.sdx-developers.com/epic-development/superuser-app-to-help-with-security-concerns/
Also, Titanium Backup failed to work - it gave an error of denied root access, and said busybox was not installed. What needs to be done to make it work? Do I need to install clockwork mod (not exactly sure what it does though) or a custom ROM?
AndroidSPCS said:
Quick question: do we need to do this after root or is it not needed?
Click to expand...
Click to collapse
Not sure exactly what you're asking. This is an alternative to the joeykrim-based one-click roots and rooted kernels. If you already have one of those this isn't really necessary.
AndroidSPCS said:
NEEDED?? ===> SuperUser App
Click to expand...
Click to collapse
Yes, the su binary used here requires the Supruser appto be installed to authorize su requests. Otherwise they'll always be denied. Other su binaries might not require it, but then all apps have root access which isn't really a good thing.
AndroidSPCS said:
Also, Titanium Backup failed to work - it gave an error of denied root access, and said busybox was not installed. What needs to be done to make it work?
Click to expand...
Click to collapse
Did you authorize Titanium Backup when the Superuser prompt came up (requies the Superuser app to be instald too)?
Titanium Backup has an option to download and install it's preferred version of busybox. Follow the prompts to do that.
mkasick said:
Not sure exactly what you're asking. This is an alternative to the joeykrim-based one-click roots and rooted kernels. If you already have one of those this isn't really necessary.
Click to expand...
Click to collapse
Thanks, actually this was referring to the thread where the instructions for going to adb shell or terminal and typing in the following commands:
adb shell
su
mount -t rfs -o remount,rw /dev/block/stl9 /system
cp /system/bin/su /system/bin/jk-su
exit
Yes, the su binary used here requires the Supruser appto be installed to authorize su requests. Otherwise they'll always be denied. Other su binaries might not require it, but then all apps have root access which isn't really a good thing.
Click to expand...
Click to collapse
Yes same as above, the question is not whether we need SU app (I know we do), but whether we needed to type the additional commands:
adb shell
su
mount -t rfs -o remount,rw /dev/block/stl9 /system
cp /system/bin/su /system/bin/jk-su
exit
What do these commands do? It seems to me my Superuser app is working fine with wifi tether - popping up with allow / disable permission boxes, etc. Do these commands add something else to Superuser?
Did you authorize Titanium Backup when the Superuser prompt came up (requies the Superuser app to be instald too)?
Titanium Backup has an option to download and install it's preferred version of busybox. Follow the prompts to do that.
Click to expand...
Click to collapse
There was no Superuser prompt during the install of the app, nor anytime when it said it had a failure with root access. However there is an option to install BusyBox, which I have not done yet, because I am not sure what busybox is, or what it does. I'd like to find out why I need it and what it does, so I can feel comfortable with installing it.
Thanks again.
echo "root::0:0:root:/data/local:/system/bin/sh" > /etc/passwd
echo "root::0:" > /etc/group
you need to do that in a shell to make sure su works properly.
I'm updating the one click root right now to be less silly.
http://forum.xda-developers.com/showpost.php?p=8543226&postcount=455
I just cleaned up the one click root to not do many of the silly things joeykrim's root does. It also means your system will be mounted as rw after a reboot and it won't overwrite your su with jk-su every boot (no more modified playlogo).
Cleaned up all the old stuff from the root so it should work fine even if you were using one of the older one clicks. I made sure su works, incl titanium backup.
I'm still installing superuser.apk to /system/app because I think it belongs there.
Thanks for doing the footwork, mkasick!
Firon said:
http://forum.xda-developers.com/showpost.php?p=8543226&postcount=455
I just cleaned up the one click root to not do many of the silly things joeykrim's root does. It also means your system will be mounted as rw after a reboot and it won't overwrite your su with jk-su every boot (no more modified playlogo).
Cleaned up all the old stuff from the root so it should work fine even if you were using one of the older one clicks. I made sure su works, incl titanium backup.
I'm still installing superuser.apk to /system/app because I think it belongs there.
Thanks for doing the footwork, mkasick!
Click to expand...
Click to collapse
Firon- why are these lines still needed?
Code:
adb push playlogo /system/bin/playlogo
what is playlogo? Does this just put the stock one back in case you used the joeykrim method in the past?
Code:
adb push remount /system/xbin/remount
Are the remount scripts still needed?
Code:
adb shell ln -s /system/xbin/su /system/bin/su
why is this link needed? why cant su just be in xbin
thanks in advance!
Code:
jimmyz said:
Firon- why are these lines still needed?
Code:
adb push playlogo /system/bin/playlogo
what is playlogo? Does this just put the stock one back in case you used the joeykrim method in the past?
Click to expand...
Click to collapse
This is just pushing the stock playlogo, since joeykrim's method overwrites it with some custom script.
Code:
adb push remount /system/xbin/remount
Are the remount scripts still needed?
Click to expand...
Click to collapse
The script allows you to easily remount system as ro or rw at will. Why not?
Code:
adb shell ln -s /system/xbin/su /system/bin/su
why is this link needed? why cant su just be in xbin
Click to expand...
Click to collapse
I don't know if any apps depend on it being in a particular location. It is in xbin, but I'm also linking it to /system/bin to be safe.
AndroidSPCS said:
What do these commands do? It seems to me my Superuser app is working fine with wifi tether - popping up with allow / disable permission boxes, etc. Do these commands add something else to Superuser?
Click to expand...
Click to collapse
These commands were necessary to get Superuser working with the old joeykrim root method. They're not necessary with this method (or the newly released one-click). In other words, if wifi-tethering is already working for you, nothing further is needed to be done.
AndroidSPCS said:
There was no Superuser prompt during the install of the app, nor anytime when it said it had a failure with root access.
Click to expand...
Click to collapse
I don't actually use TitaniumBackup. I'm not sure why its superuser-requirements would be different from other apps, but I guess it is. The new one-click appears to address this.
AndroidSPCS said:
However there is an option to install BusyBox, which I have not done yet, because I am not sure what busybox is, or what it does. I'd like to find out why I need it and what it does, so I can feel comfortable with installing it.
Click to expand...
Click to collapse
Busybox is a suite of "familar" Unix command-line utilites (things like cp (copy), mv (move), ls (list), etc.). It targets embedded platforms by being very featureful, yet relatively small. It's installed and used on a wide variety of embedded devices including wireless routers, print servers, phones, even televisions.
Oddly enough, Android does not include busybox by default. Instead it comes with it's own utility-programs-package called "toolbox" that isn't nearly as featureful, and quickly becomes a pain to use. Some programs, like TitaniumBackup depend on busybox programs/features, and thus require it's installation. It's safe.
The only problem with busybox is that there's not one single version of it. There's multiple builds of it from the same source code with different sets of features turned on and off. In the past, some folks had a version of busybox installed that didn't contain all the features necessary to support TitaniumBackup, so they added the option to install their own version. It's installed in a separate location, so it won't overwrite any version you do have installed, and it's safe to do. But if you've already installed another version of busybox that does work, then it may be unnecessary.
I did the Jokeyrim method a few days ago. I installed a new kernal and now a new ROM. All seems ok, but ow when I do the "whoami" command in adb shell I get whoami not found. I don't think I'm really rooted anymore. Any attempt to reinstall the Jokeyrim root script results in failure (mostly "device not found" errors). When in adb shell, most commands I type now are either "not found" or "permission denied", so I'm not confident that I'm really rooted now.
Since I have / had Jokeyrim installed, how can I "uninstall" it so that I can use this method of rooting instead? BTW, the newest Clockworkmod is installed and working.
Do I need to flash to stock first? Sorry, but I'm a VERY STOOPID NOOB.
I understand there are other threads about this however I do feel my situation is either unique or I've missed something in the other threads.
I've got an HTC Merge through US Cellular. I upgraded to Gingerbread 2.3.4 as soon as it was released through USC's website. Now I'd like to root and all that other stuff.
1.: I didn't S-off before the update. Does anyone know how to properly S-off 2.3.4 Gingerbread on a USC HTC Merge?
2.: I've never rooted a phone before, but I'm pretty sure I've read about it plenty and I'm ready to give it a shot. What's the best way to do this on my current phone?
3.: What are some good modded ROMs available for this device, if any exist at all? I've been interesting in Cyanogen Mod but as far as I've seen it's not supported on the Merge yet.
If anyone can assist me I'd appreciate it greatly. Thanks in advance. =)
if you have adb set up and working,and have some knowledge of it,you can use drellisdees directions in this post,along with the new zergRush temp root tool from alpharev/unrevoked. donate to them both if it works for you.
download the zergRush tool from this post:http://forum.xda-developers.com/showthread.php?t=1296916 and place the file thats inside the .zip into the same folder as your other exploits(tools or platform-tools in ost cases)
below is his post,modified slightly,with the zergRush directions(bold) in place of the originaly froyo directions.
i also removed the parts about downloading your carriers RUU,and backing up your system for vzw since you said you were USC.
assuming you want to remain on rooted GB,just use the same RUU that you used to upgrade at the end where it says to run your carriers RUU.
drellisdee said:
Well, ask and you shall receive!!!
I got s-off on vzw merge. However, altell or USC ones it will require supercid or a goldcard to flash ruu from another carrier.
Tested and working CWM recovery I made for merge and latest radio hboot zips after s-off.
You must verify all Md5sums after downloading to computer (don't even think about downloading on phone) before flashing or risk a brick!!!!! Windows users can get one here & linux users can just type md5sum (name of file) into terminal.
Md5's
8cd1ca796e755b6b72f35e5686dc973a PD42IMG_cw_recovery_gnm.zip
97e35ecc802081b67e27d6cc8323cf81 PD42IMG_radio_1.08.00.320.zip
cc2e7c077fddd017d7b0db614661c535 PD42IMG_1.49.605.1_no_system.zip
4fe37c64b21d1d4542a801779fad5c57 misc-downgrade.img
6d37a0f3526295ebb779f4465a328c96 rom.zip (leaked 1.23.605.1)
http://www.mediafire.com/file/6b2jatt0445h41g/PD42IMG_cw_recovery_gnm.zip
http://www.mediafire.com/file/gbayon7dkmaq98i/PD42IMG_radio_1.08.00.320.zip
I am exploring a goldcard method that will allow flashing of the vzw ruu 1.23.605.1 that can be s-off'ed to allow other carriers merge's to be able to downgrade to s-off.
How to on s-off will be coming soon .... stay posted
Ok how to guide for s-off.
Files needed:
MISCIMG Downgrade http://www.mediafire.com/file/f7c3boee7ixa3i9/misc-downgrade.img
VZW leak 1.23.605.1 ruu.zip http://forum.xda-developers.com/showpost.php?p=8237592&postcount=2
Exploits http://www.mediafire.com/file/e9w92clv6l71el3/exp.zip
HEADS UP: This guide will reflash your phone and cause loss of all non-backed up data
Goldcard is required for ALL NON-VZW phones
Read how to make one here : http://www.mikesouthby.co.uk/2010/0...yo-official-ota-for-network-branded-handsets/
I used the app goldcard helper from market and if you use it skip right to the step of "Go to this page and enter this new number into the SD Card Serial (CID) field" and enter the output of the sdcard cid for mmc2 into the goldcard generator site.
After goldcard is made via directions in link above or if on vzw branded device you can skip the goldcard part. Next rename the vzw leak ruu.zip to PD42IMG.zip and place it on root of sdcard.
Next from dir you downloaded stuff to unzip the exp.zip and copy the exp folder to your android sdk platform-tools dir (if using windows) linux users should have adb in path so this shouldn't be needed just open terminal from download dir. Make sure the phone is in usb mode charge-only from this point on with usb-debugging turned on (settings/applications/development).
Code:
[B]adb push zergRush /data/local/
adb shell[/B] [I]this will change your promt to a $[/I]
[B]chmod 755 /data/local/zergRush
/data/local/zergRush[/B]
Next we backup our existing misc partition.
Code:
adb shell
dd if=/dev/block/mmcblk0p17 of=/sdcard/misc-stock.img bs=4096
/data/local/busybox md5sum /sdcard/misc-stock.img
/data/local/busybox md5sum /dev/block/mmcblk0p17
Make sure the md5sum of the misc-stock.img matches the one from /dev/block/mmcblk0p17
Next we use temp root to flash a misc.img that I hex edited to allow downgrading FW. misc-downgrade.img needs to be in platform-tools dir for windows users.
Code:
adb push misc-downgrade.img /sdcard/
adb shell
dd if=/sdcard/misc-downgrade.img of=/dev/block/mmcblk0p17
sync
Next power off your phone and boot it holding vol_dn + power.
Let the PD42IMG.zip complete ( will do hboot + radio then self reboot and restart to finish the rest)
Once rebooted into the 1.23.605.1 firmware
Code:
adb push exp /data/local
adb shell
chmod 0755 /data/local/psneuter
chmod 0755 /data/local/wpthis
chmod 0755 /data/local/gfree
/data/local/psneuter (to get temp root again)
adb shell
/data/local/wpthis (to disable emmc write protect)
/data/local/gfree -f (this will supercid, simunlock, and s-off phone)
rm /sdcard/PD42IMG.zip (remove/delete the leaked FW so hboot wont load it again)
Reboot into bootloader and verify you have s-off
If so reboot into android and use your carrier's RUU to replace your FW. You will not lose s-off. If on vzw unzip the PD42IMG_1.49.605.1_no_system.zip and add your system.img from your memory card we dumped earlier to the zip. Rezip and rename to PD42IMG.zip and place on root of sdcard and reboot into hboot to flash it just like we did earlier. This will restore the shipped 1.49.605.1 hboot, radio, boot.img, stock recovery.img, and system.img.
After you have upgraded backup you can use the clockwork recovery.img I made and rename it to PD42IMG.zip (make sure to delete the old PD42IMG.zip on your sdcard) and place it on root of sdcard and flash via hboot just like the other PD42IMG.zip's. Then you will have s-off and a custom recovery. Remember to remove/rename/move the PD42IMG.zips when done as they will flash if you enter hboot. Recovery can be entered via bootloader by picking recovery or via "adb reboot recovery".
Flashing this zip via clockwork recovery will install root (su & superuser.apk), busybox & symlink applets, flash & dump image. signed_merge_su_eng_toolkit.zip
After you have root on your release firmware:
The following commands will restore your stock misc.img
from a root # shell: (will need to type su after adb shell and accept superuser pop-up)
Code:
adb shell
dd if=/sdcard/misc-stock.img of=/dev/block/mmcblk0p17
sync
Special thanks to Scotty2 & Tmzt who wrote and developed the wpthis & gfree exploits for the G2 without these s-off for lexikon wouldn't have been possible for me.
My donation link is below if anyone wants to toss me a donation. Took me about a week to port RA recovery to merge only to fail as it had issues then to setup the board files for lexikon for cm7 to do a clockwork recovery and not to mention dumping partitons and working on the s-off stuff and goldcard.
Click to expand...
Click to collapse
I got as far as the /data/local/zergRush and got this error:
[-] Cannot copy boomsh. : Permission denied.
adb push zergRush /data/local/
adb shell this will change your promt to a $
chmod 755 /data/local/zergRush
/data/local/zergRush
Any ideas?
Thanks
kclive said:
I got as far as the /data/local/zergRush and got this error:
[-] Cannot copy boomsh. : Permission denied.
adb push zergRush /data/local/
adb shell this will change your promt to a $
chmod 755 /data/local/zergRush
/data/local/zergRush
Any ideas?
Thanks
Click to expand...
Click to collapse
that error comes from running zergrush twice. http://androidforums.com/merge-all-...simunlock-supercid-htc-merge.html#post3522248
pls how can i run this commands with miniadb, i dont hav access to the whole android sdk tool...and besides, the zergrush binary link above aint workin..any other alternative dload link pls??
akins47 said:
pls how can i run this commands with miniadb, i dont hav access to the whole android sdk tool...and besides, the zergrush binary link above aint workin..any other alternative dload link pls??
Click to expand...
Click to collapse
zergrush is broken with newer builds. fre3vo worked for some. i would recomend you htcdev unlock in order to gain root access for downgrade.
follow directions here to htcdev unlock:
http://androidforums.com/merge-all-things-root/635459-unlock-htcdev.html
then follow directions here:
http://androidforums.com/merge-all-things-root/434029-root-s-off-simunlock-supercid-htc-merge.html
using the "htcdev" step 5 in post#2
Saurik's mempodroid exploit needs offsets of "exit" and "setresuid" functions calls in order to work.
Here's a tool that may find this two offsets while running on your ICS device and give you the mempodroid command line to run for gaining a temporary root shell.
This tool doesn't add any capability to Saurik's exploit.
Please let me know if you have any idea for improvement.
Feel free to use this tool, at your own risks.
1- download and unzip
2- push the two binaries to /data/local/tmp with adb
3- chmod 755
4- run n95-offsets
5- copy / paste the command line given by the tool
If the trick works, you will see the $ prompt change to a # one.
Hope it will help.
Hi,
don't work on HTC One X with 4.0.3.
cheers
starbase64
Already too old
Hi,
Mempodipper / mempodroid exploit uses a serious security hole in Linux kernels 2.6.39 and higher, making some noise in Linux' world. A patch has been given by Linus Torvalds himself late january.
It always take some times to deploy patched kernels but by now, most of them are probably mempodroid-resistants.
Wait for the next...
I just updated my samsung galaxy nexus from 4.0.2 to 4.0.4. Before that, I could root it using the command line provided by saurik:
Galaxy Nexus 4.0.2: 0xd7f4 0xad4b
Click to expand...
Click to collapse
source: https://github.com/saurik/mempodroid
After the update, I did not manage to root it so I came to this topic after some research on xda
Unfortunately, it looks the 4.0.4 update patches this hole on the galaxy nexus (or the n95-offsets tool does not work, which is probably not the case). Here for the record is what is returned by the tool:
[email protected]:/data/local/tmp $ ./n95-offsets
n95-offsets by Nesquick95
Gets requiered offsets for mempodroid exploit
./mempodroid 0xd7cc 0xad27 sh
1|[email protected]:/data/local/tmp $ ./mempodroid 0xd7cc 0xad27 sh
1|[email protected]:/data/local/tmp $
Click to expand...
Click to collapse
No root shell given. Any proof on the vulnerability beeing patched with 4.0.3 or 4.0.4?
No proof but...
Hi,
I've also lost mempodroid rooting capacity when upgrading my Galaxy Nexus from 4.0.2 to 4.0.4.
The tool can be wrong but I mainly think that the hole has been patched. But you're right, no proof of it until now
Nesquick95 said:
Hi,
I've also lost mempodroid rooting capacity when upgrading my Galaxy Nexus from 4.0.2 to 4.0.4.
The tool can be wrong but I mainly think that the hole has been patched. But you're right, no proof of it until now
Click to expand...
Click to collapse
Yes, I think that too. How did you managed to get the 4.0.4 rooted then? Did you unlock the bootloader or did you use another root exploit?
Unlocked
I've rooted 4.0.4 by unlocking the bootloader, flashing ClockworkMod recovery then an update.zip containing only the su binary.
I'd prefered keeping stock booloader locked but there is not so much kernels exploits around here for now and I ain't got time for testing other devices (Acer, Sony,...) specifics exploits on the Gnex...
If you're interested, you can take a look at Dan Rosenberg's works, in addition to all the great things already done here at XDA :
http://vulnfactory.org/blog/
Nesquick95 said:
Saurik's mempodroid exploit needs offsets of "exit" and "setresuid" functions calls in order to work.
Here's a tool that may find this two offsets while running on your ICS device and give you the mempodroid command line to run for gaining a temporary root shell.
This tool doesn't add any capability to Saurik's exploit.
Please let me know if you have any idea for improvement.
Feel free to use this tool, at your own risks.
1- download and unzip
2- push the two binaries to /data/local/tmp with adb
3- chmod 755
4- run n95-offsets
5- copy / paste the command line given by the tool
If the trick works, you will see the $ prompt change to a # one.
Hope it will help.
Click to expand...
Click to collapse
Hi Nesquick. I need to compile this source and mempodroid for a MIPS tablet (4.0.3 ICS and 3.0.8 kernel), since it seems that it cannot be rooted. Can't adb root or su. Do you think that it could be used or you can help generating the binaries for MIPS?
Thanks in advance
Hi,
Hard to say if it will work or not... Your 3.0.8 kernel may be a good candidate as long as it hasn't be mempodroid-patched by the tablet's provider.
I have Google NDK r7 installed, it offers only x86 and ARM support. It seems that MIPS support comes with r8 :
http://developer.android.com/sdk/ndk/index.html
You'll find the perl script used to compile my C programs attached (thanks to the author, Andrew Ross). I think t won't be to hard to adapt it to NDK r8 / MIPS platform...
the offsets of "exit" is wrong
Nesquick95 said:
Saurik's mempodroid exploit needs offsets of "exit" and "setresuid" functions calls in order to work.
Here's a tool that may find this two offsets while running on your ICS device and give you the mempodroid command line to run for gaining a temporary root shell.
This tool doesn't add any capability to Saurik's exploit.
Please let me know if you have any idea for improvement.
Feel free to use this tool, at your own risks.
1- download and unzip
2- push the two binaries to /data/local/tmp with adb
3- chmod 755
4- run n95-offsets
5- copy / paste the command line given by the tool
If the trick works, you will see the $ prompt change to a # one.
Hope it will help.
Click to expand...
Click to collapse
this is ok, great!!!
n95-offsets can work
olive360 said:
Hi, I get the offsets with n95-offsets
the offsets of "exit" is wrong
offsets of "setresuid" is right
my cell offsets is 0xd524 0xab8f
the offsets obtained with n95-offsets is 0x8003 0xab8f
Click to expand...
Click to collapse
sorry, i make a mistake, n95-offsets can work, i have rooted use it.
Thanks!!! It works with my Yifang / Mediacom MD 860 S2 (Generic ICS 4.0.4 tablet on a Cortex A9 platform)
Hi, I've Mediacom 715i (new one with 4.0.4), I've used n95-offsets to find the two offset, then I've executed mempodroid, but it doesn't work. still have '$' prompt. Any Idea?