Database Info

Simple (not one-click) root for stock ROM & kernel

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.

Can I get OTA updates with root or unrooting

I am thinking about rooting my Nexus S I love Stock google and I love how I can get OTA updates instead of waiting for carriers to update them then waiting ..... If I root my phone can I get the OTA updates still or can I reverse it so my phone is like it never had anything ever on it so I can update it fine as if Ive just bought it from a store.
thanks.

You can still receive OTAs with root as long as you're not on a custom rom that has the update script disabled (which most do). If youre on stock rom rooted then you will receive the update when it comes. Should you choose to update through the OTA, you will lose root. Most likely you could re-root it again thereafter.
Sent from my Nexus S using XDA App

aww thanks so lets say I root tommorow I can get updates aslong as i dont install something like Cyogen or what ever it is called is the clockwork recovery just something for restoring and doesnt involve updating?

Also updates always get incorporated into custom rims so if you're on one you don't really have to worry about it.

Rooting the version of android you have won't keep you from getting updates. If you change the recovery image the update will download, but the install will fail.
Rooting a Nexus is pretty easy if you have the android SDK installed.
Just type in the following commands (you'd have to download superuser.apk and su and place them in the platform-tools folder of the SDK)
adb remount
adb push su /system/bin/
adb push Superuser.apk /system/app/
adb shell chmod 6755 /system/bin/su
adb shell exit
adb reboot
If you type in adb remount and it fails to mount type in "adb root" then do the steps above.

hawaiian said:
Rooting the version of android you have won't keep you from getting updates. If you change the recovery image the update will download, but the install will fail.
Rooting a Nexus is pretty easy if you have the android SDK installed.
Just type in the following commands (you'd have to download superuser.apk and su and place them in the platform-tools folder of the SDK)
adb remount
adb push su /system/bin/
adb push Superuser.apk /system/app/
adb shell chmod 6755 /system/bin/su
adb shell exit
adb reboot
If you type in adb remount and it fails to mount type in "adb root" then do the steps above.
Click to expand...
Click to collapse
by recovery image is this the clockwork for example becuase that needs to be installed for root doesnt it :/

Rooting
Here's a great webpage on how to root the Nexus. You don't have to push the recovery image to the phone most people do so they can install custom roms. If you just want to root your stock rom you don't have to load the recovery image.
http://jaxov.com/2010/12/unlock-bootloader-root-nexus-s-on-android-2-3-gingerbread/

hawaiian said:
Here's a great webpage on how to root the Nexus. You don't have to push the recovery image to the phone most people do so they can install custom roms. If you just want to root your stock rom you don't have to load the recovery image.
http://jaxov.com/2010/12/unlock-bootloader-root-nexus-s-on-android-2-3-gingerbread/
Click to expand...
Click to collapse
Its also helpful to have a recovery image to maintain backups of your phone

Thanks for now id just like root adverts pee me off they kill phone speed. Id like to use other stuff too
Sent from my Nexus S using XDA App

Can I still got OTA if I use rom manager to flash recovery temporary or write something into /system/?
Coz I wanna use the Adblocker to remove ads but seems it will modify some file.

Recovery Disappears

I bought a phone (ZTE 2050) that has next to nothing as far as development goes. I have tried to install TWRP recovery but it had never actually worked. I have tried using various tools that port recovery to MTK devices. None of them have worked. I have been able to achieve root through Magisk. However, when I do, I no longer have the stock recovery either. There are several other problems that happen as well, but nothing I cannot work around. What could I be doing that is causing me to lose recovery? The chipset is MTK6771 and it is an ARM-V8 64 bit and it is running Android 9. Literally the only things I'm able to find online regarding this phone is the sites that I believe only copy and paste from other phones whether the root method actually works out not. Almost everything tells me to use MTK Tool but that definitely doesn't work. I have issues with Smart Phone Flash Tool working as well despite all drivers being installed correctly. The only way I have been able to achieve root is through unlocking the Bootloader and flashing. And even though I follow the instructions on commands, I still lose the stock recovery. Any help would be greatly appreciated.

Reflash phone's stock ROM.

xXx yYy said:
Reflash phone's stock ROM.
Click to expand...
Click to collapse
I have flashed the stock system at least 50 times by now. I have tried flashing everything in different orders as well. When I have root, it always removes the recovery. When I open my file manager, I use Solid Explorer, it tells me there is no root file system. I have tried other root file managers as well. They all tell me the same thing.

Android is rooted if su cmdlet is present in Android's filesystem

I've got a $100 Chinese MTK phone and the one redeeming feature is that once the bootloader is unlocked, you can fastboot over USB (bootstrap).
I used SP flash tool to backup the ROM and WwR_MTK to extract the partitions allowing me to make my own custom recovery to boot with fastboot. Briefly, I found a twrp recovery online for another MTK phone and just played around with zImage & initrd.
Shell commands, dmesg, cat /proc/partitions & blkid on the phone come in handy to track down in partition layout. No need to flash anything so don't get issues with /system/bin/install-recovery.sh

xXx yYy said:
Android is rooted if su cmdlet is present in Android's filesystem
Click to expand...
Click to collapse
I got it to hang on to the stock recovery. However, the bootloader remains unlocked. If I lock it again in fastboot, it will not allow me to boot the phone. When I try to flash vbmeta, it tells me there is no such file on the system.

xdabookam said:
I've got a $100 Chinese MTK phone and the one redeeming feature is that once the bootloader is unlocked, you can fastboot over USB (bootstrap).
I used SP flash tool to backup the ROM and WwR_MTK to extract the partitions allowing me to make my own custom recovery to boot with fastboot. Briefly, I found a twrp recovery online for another MTK phone and just played around with zImage & initrd.
Shell commands, dmesg, cat /proc/partitions & blkid on the phone come in handy to track down in partition layout. No need to flash anything so don't get issues with /system/bin/install-recovery.sh
Click to expand...
Click to collapse
I'll give that a shot. I just tried to open my root file system and it told me that BusyBox isn't installed. I thought I had read that BusyBox wasn't necessary with Magisk. Last time I tried to install a BusyBox, it screwed the whole system up. Is there one you would suggest? I've seriously messed with this phone 1000x's now and it's made me giggle shy to do anything to it at the moment.

Some devices have 'toolbox' or 'toybox' as a limited replacement for busybox (ls -al /bin/ls should reveal what binary the sym link points to).
I've used the ru.meefik.busybox app from the play store.
finnroth69 said:
the whole system up. Is there one you would suggest? I've seriously messed with this phone 1000x's now and it's made me giggle shy to do anything to it at the moment.
Click to expand...
Click to collapse

xdabookam said:
Some devices have 'toolbox' or 'toybox' as a limited replacement for busybox (ls -al /bin/ls should reveal what binary the sym link points to).
I've used the ru.meefik.busybox app from the play store.
Click to expand...
Click to collapse
xdabookam said:
Some devices have 'toolbox' or 'toybox' as a limited replacement for busybox (ls -al /bin/ls should reveal what binary the sym link points to).
I've used the ru.meefik.busybox app from the play store.
Click to expand...
Click to collapse
Ok, yeah I just checked it and it says toybox.

xdabookam said:
Some devices have 'toolbox' or 'toybox' as a limited replacement for busybox (ls -al /bin/ls should reveal what binary the sym link points to).
I've used the ru.meefik.busybox app from the play store.
Click to expand...
Click to collapse
I just installed the BusyBox and my whole system froze and started acting up.

xdabookam said:
Some devices have 'toolbox' or 'toybox' as a limited replacement for busybox (ls -al /bin/ls should reveal what binary the sym link points to).
I've used the ru.meefik.busybox app from the play store.
Click to expand...
Click to collapse
I rebooted and it started acting ok once again. When I tried to open my file manager to access to root file system, this is still the message I got even though I have not uninstalled the BusyBox.

xdabookam said:
Some devices have 'toolbox' or 'toybox' as a limited replacement for busybox (ls -al /bin/ls should reveal what binary the sym link points to).
I've used the ru.meefik.busybox app from the play store.
Click to expand...
Click to collapse
I just opened the BusyBox app and it says it isn't installed even though I have not uninstalled it either.

cm
xXx yYy said:
Android is rooted if su cmdlet is present in Android's filesystem
Click to expand...
Click to collapse
"cmdlet" not found. Yet Magisk is installed and I am able to access root.

If you can successfully apply su ( read: Switch User cmdlet ) then it got installed by whatever method.

finnroth69 said:
I just opened the BusyBox app and it says it isn't installed even though I have not uninstalled it either.
Click to expand...
Click to collapse
Busybox is just a tool / binary executable command to replace missing
linux commands. You don't need it installed on the phone, just access to the binary to run commands in the shell (copy it from /data/app/....) - its statically linked so should run without issue in the shell.

xXx yYy said:
If you can successfully apply su ( read: Switch User cmdlet ) then it got installed by whatever method.
Click to expand...
Click to collapse
Ok, I understand that. What I don't understand is why I am now being told that vbmeta cannot be found and installed and my bootloader must remain unlocked. Or why I cannot install recovery without losing recovery.

xdabookam said:
Busybox is just a tool / binary executable command to replace missing
linux commands. You don't need it installed on the phone, just access to the binary to run commands in the shell (copy it from /data/app/....) - its statically linked so should run without issue in the shell.
Click to expand...
Click to collapse
I can't copy it it. It won't allow me into the root file system.

xdabookam said:
Busybox is just a tool / binary executable command to replace missing
linux commands. You don't need it installed on the phone, just access to the binary to run commands in the shell (copy it from /data/app/....) - its statically linked so should run without issue in the shell.
Click to expand...
Click to collapse
I can't copy it it. It won't allow me into the root file system.
xdabookam said:
Busybox is just a tool / binary executable command to replace missing
linux commands. You don't need it installed on the phone, just access to the binary to run commands in the shell (copy it from /data/app/....) - its statically linked so should run without issue in the shell.
Click to expand...
Click to collapse
I just installed another BusyBox and the system is running fine afterwards, but this is the message I get when trying to open the root file system.

xdabookam said:
Busybox is just a tool / binary executable command to replace missing
linux commands. You don't need it installed on the phone, just access to the binary to run commands in the shell (copy it from /data/app/....) - its statically linked so should run without issue in the shell.
Click to expand...
Click to collapse
I pulled up the currently installed binary installed through shell.

How do I temporarily root a samsung device running android 9 without twrp recovery?

I have used magisk to patch the file and android platform tools (fastboot or stuff like that) but it does not work. I dont want to install twrp as i dont really trust custom recoveries as much and i dont want to use odin for the same reason. Is this impossible or is there a way but i am just doing it incorrectly. Please reply asap!

Never installed Magisk nor TWRP, why should I have done it?
To answer your question: A temporary root can get achieved by putting a suitable su into directory /data/local/tmp and making it executable.
https://forum.xda-developers.com/attachments/su-binaries-zip.5566949/

xXx yYy said:
Never installed Magisk nor TWRP, why should I have done it?
To answer your question: A temporary root can get achieved by putting a suitable su into directory /data/local/tmp and making it executable.
https://forum.xda-developers.com/attachments/su-binaries-zip.5566949/
Click to expand...
Click to collapse
The data partition is not accessible without having root first. How are they to place su in data partition to gain temp root without first gaining root to place su in data partition? How can they root the device by using a method that requires root in the first place to achieve what you are telling them?

I think the code
Code:
adb push <PATH-TO-SU-ON-PC> /data/local/tmp
always works , because this path ( /data/local/tmp ) is always present and writable on Android dev device and Emulator.
At least it always worked for me since I'm rooting Android this way.

xXx yYy said:
I think the code
Code:
adb push <PATH-TO-SU-ON-PC> /data/local/tmp
always works , because this path ( /data/local/tmp ) is always present and writable on Android dev device and Emulator.
At least it always worked for me since I'm rooting Android this way.
Click to expand...
Click to collapse
do i unroot my device by rebooting it?
p.s. will doing this solution create a possibility of bricking my device?

Technically seen you can't root / unroot a device, but only Android OS.
As with Android OS root ( sometimes called superuser ) is the same as Administrator with Windows OS. Simply adding an user with elevated privileges never will brick an Android device.
Become familiar what root is the world of Linux OS - take note that Android OS merely is a port of it.

xXx yYy said:
Technically seen you can't root / unroot a device, but only Android OS.
As with Android OS root ( sometimes called superuser ) is the same as Administrator with Windows OS. Simply adding an user with elevated privileges never will brick an Android device.
Become familiar what root is the world of Linux OS - take note that Android OS merely is a port of it.
Click to expand...
Click to collapse
so running that command will give me legit root privileges and i can do the things an admin can do without any malware or damage?

Droidriven said:
The data partition is not accessible without having root first. How are they to place su in data partition to gain temp root without first gaining root to place su in data partition? How can they root the device by using a method that requires root in the first place to achieve what you are telling them?
Click to expand...
Click to collapse
so should i really use magisk to root my device?

moutsu said:
so should i really use magisk to root my device?
Click to expand...
Click to collapse
No, try what was suggested by placing su in the data/local/tmp. If that doesn't work, try using magisk to root your device.

xXx yYy said:
I think the code
Code:
adb push <PATH-TO-SU-ON-PC> /data/local/tmp
always works , because this path ( /data/local/tmp ) is always present and writable on Android dev device and Emulator.
At least it always worked for me since I'm rooting Android this way.
Click to expand...
Click to collapse
I've never seen a device rooted by such simple means, in my experience, it has always required root to even access data partition, especially if trying to push/pull files to/from data via adb.
I mean, if it were really that easy, why would all these rooting tools snd methods that exist on XDA have ever been needed to be created?
What devices have you rooted using this method? Can you provide information that explains and confirms what you say?

Hmmmm...
Short checked on my SM-R860 Android 11...
Code:
freshbs:/ $ cd /data/local/tmp
freshbs:/data/local/tmp $ ls
freshbs:/data/local/tmp $ ls -a1l
total 6
drwxrwx--x 2 shell shell 3452 2022-03-25 01:20 .
drwxr-x--x 4 root root 3452 2022-03-25 01:20 ..
Need more time or drinks to place something here...
Waiting for other results...
Best Regards

@Droidriven
Fellow member @adfree has proven that even with Android 11 directory /data/local/tmp worlwide exists and is writeable.
Sometimes it really makes sense to understand what OP wants to achieve: He just wants to know how Android can be temporarily rooted.

xXx yYy said:
@Droidriven
Fellow member @adfree has proven that even with Android 11 directory /data/local/tmp worlwide exists and is writeable.
Sometimes it really makes sense to understand what OP wants to achieve: He just wants to know how Android can be temporarily rooted.
Click to expand...
Click to collapse
I do need to know how an android can be temporarily rooted so I can give certain apps on my phone root access to recover some stuff I accidentally deleted. However, I do need a bit of clarification on what su file I need to put into the directory as the filed you linked was a zip file.
I would also like a method on how to unroot my device.

Dear moutsu...
IMHO instead blabla... IMHO it makes sense to start from scratch with FULL infos.
I can see only bla bla Samsung Device...
Please give full details...
A
Model Name...
Example:
SM-G920F is Android 7 for instance...
B
Is Phone alive... then give full details about Firmware Version.
Easiest way for most infos...
Type:
*#1234#
Type or make Photo or Screenshot...
Best Regards

@xXx yYy
Thank you very much. But...
I clicked through your profile and find some more puzzle parts of your idea...
Learning to root my old Galaxy S4
I have an old Samsung Galaxy S4. It's been off the network for a while and its system clock has drifted. However, adb works and I can use the old phone as a sandbox environment to learn about low level Android fundamentals. I would like to learn...
forum.xda-developers.com
After this I was drunken enough to try few things with my SM-R860...
WITHOUT success...
Later I will add my ADB output... for better understanding...
IMHO I am not total Noob in Rooting something...
Also I have "some" experiences in recover halfdead devices to backup beloved data...
I am sure you have forgotten about Samsung additional Security check... like Knox crap etc...
So my conclusion...
Your method is good to know...
But chance for success in "newer" Samsung devices is not 100 %...
Maybe you can give Samsung model name... where this work?
I could check SM-G920F with Android 7 just for fun... if I have time...
Thanx in advance.
Best Regards

regardless it is writeable to adb shell only (uid 2000), chown is forbidden anyway. even if you set SUID bit that wouldn't make much sense in /data/local/tmp
furthermore, even if you could place su binary in /system (which requires unlocked bootloader + dm-verity patch) it still requires privileged daemon in background where su want connect apps (but not exist).
so this method never worked, except for some ancient android devices where remount /system was possible from adb root.
and we haven't spoke about selinux, yet
Magisk does all this, but requires* unlocked bootloader - which triggers factory reset. So unless you have some nice exploit like dirty-cow or mtk-su, temporary root is simply impossible.
edit: TWRP is not able to decrypt samsung encryption btw. So if you want have access to userdata partition on locked bootloader the only way would be (samsung signed) so called "combination ROM" (with same bootloader level) to be flashed from Odin via HOME_CSC or heimdall.
if your device is ancient old you might lucky bootloader is unlocked, userdata partition is not encrypted at all, and ROM is just signed with test keys. in that case you can flash anything on recovery partition. philz touch recovery even provided flashable zips that signed with test keys, these zips can be flashed straight from stock recovery without PC. I remember temporary zips exist, that only boot into custom recovery without actually installing it.
edit2: *except some Mediatek devices with AVBv1 where one can flash magisk patched boot.img on locked bootloader

My last 2 cents here ( I no longer participate this thread ):
The su ( read: switchuser ) command is used to run an Android system function as a different user. It is the easiest way to switch or change to the administrative account ( read: superuser ) in the current logged in session.
Most versions of Android disable the superuser ( mostly mistakenly called root user - take note that root user in Android is the user with ID 0 who is by default present on all Android versions, is the user of session when Android gets started ) account by default making the system more secure. But, this also restricts the Android user from running specific system related commands.
Using su to temporarily act as a superuser allows you to bypass this restriction and perform system related tasks with different users.
The synthax of su command is
Code:
su [options] [username [[arguments]]
If a username isn't specified, su defaults to the superuser. Now, the logged-in user can run all system commands. This will also change the home directory and path to executable files.
If the su is used to temporarily act the logged-in user as superuser then the su binary can be located anywhere in Android's filesystem, e.g. /data/local/tmp, /storage/emulated/0, etc.pp, it must not be located in Android's system partition.

xXx yYy said:
My last 2 cents here ( I no longer participate this thread ):
Click to expand...
Click to collapse
yes, that's maybe better. teach yourself about android first. android is not linux
What special privileges "/system/xbin/su" does have w.r.t. root access?
This answer says: Because of the way directory/file permissions are configured on Android, you need to have the su binary on your /system partition in order for it to work. Putting elsewhere...
android.stackexchange.com

what is your current bootloader level? combination ROM is available (haven't checked these download links)
https://www.samsungfirmwares.info/samsung-sm-j415gn-combination-firmware-file-rom
my expectation ro.debuggable=1 is enabled
adb root will work on eng build

aIecxs said:
yes, that's maybe better. teach yourself about android first. android is not linux
What special privileges "/system/xbin/su" does have w.r.t. root access?
This answer says: Because of the way directory/file permissions are configured on Android, you need to have the su binary on your /system partition in order for it to work. Putting elsewhere...
android.stackexchange.com
Click to expand...
Click to collapse
Yeah, I get where they were coming from but.....
Nah. It just doesn't work that way for everybody. Like all things android, it really just depends on what device you have and how crappy its hardware/software and security is. Lower end/cheap and old stuff doesn't have as much time invested in making them secure to save on development and distribution costs.
Unfortunately, Samsung just isn't one of those brands that are easily rooted these days, unless you buy specific models with specific firmware/binary combinations.

Question How to pull Build.Prop...

Here's where I'm at. I've got the system to give me the Mount /System option in recovery, now i just need assistance getting the build.prop pulled to my PC. What's the procedure for pulling the build.prop from the Android to PC via ADB while the system is mounted in recovery? Why am I getting one of these two ADB errors?
Error 1: Connect failed: closed.
error 2: Failed to get feature set: no devices or emulators
OR, am I approaching it wrong?
Thanks in advance,
K0mraid3

you dont need to be in recovery to do it via adb....
adb pull /system/build.prop
that will pull it to where evr you run the adb command
which would be
C;\adb more than likely
or you can choose a destination with
adb pull /system/build.prop c:\buildprop
if you create a folder called "buildprop" in the root directory of c:\
at least thats how i remember doing it many years ago, ive been away for a while at her majesties pleasure, so i cant try it currently as im not rooted

gav83collins said:
you dont need to be in recovery to do it via adb....
adb pull /system/build.prop
that will pull it to where evr you run the adb command
which would be
C;\adb more than likely
or you can choose a destination with
adb pull /system/build.prop c:\buildprop
if you create a folder called "buildprop" in the root directory of c:\
at least thats how i remember doing it many years ago, ive been away for a while at her majesties pleasure, so i cant try it currently as im not rooted
Click to expand...
Click to collapse
Thanks, so far, its still for some reason denying me permission when OS is booted. So i just cant quite figure out where im supposed to execute these commands, is my issue. I can boot directly to BL from recovery menu, but i can also mount system. i think maybe i need sto send command for r/w.. will try that now.

Another question, when i mount /system in recovery, does that carry over on boot?

no you can re mount system via adb though
Code:
$ adb shell
$ su
# mount -o rw,remount /system

gav83collins said:
no you can re mount system via adb though
Code:
$ adb shell
$ su
# mount -o rw,remount /system
Click to expand...
Click to collapse
1.Needs root for this command. If he have rooted device then why so much trouble needed. Simply use root explorer to copy
2.Since long Samsung have removed system from proc/mounts still magisk system_root can be used
3.Even with system in mounts you can't do system rw on S22 because of Samsung have implemented extra layer of protection. Even not with magisk system_root too
Indeed as of now there is no method available to make stock system/vendor/product/odm rw on S22 even with root access.
4.To copy file from system rw mount not needed, ro is fine

dr.ketan said:
1.Needs root for this command. If he have rooted device then why so much trouble needed. Simply use root explorer to copy
2.Since long Samsung have removed system from proc/mounts still magisk system_root can be used
3.Even with system in mounts you can't do system rw on S22 because of Samsung have implemented extra layer of protection. Even not with magisk system_root too
Indeed as of now there is no method available to make stock system/vendor/product/odm rw on S22 even with root access.
4.To copy file from system rw mount not needed, ro is fine
Click to expand...
Click to collapse
im yet to root my device so i cant test but what about
Code:
adb root
adb disable-verity
adb reboot
Then
Code:
adb root
adb remount

gav83collins said:
im yet to root my device so i cant test but what about
Code:
adb root
adb disable-verity
adb reboot
Then
Code:
adb root
adb remount
Click to expand...
Click to collapse
Do you got what I meant?
leave it.

dr.ketan said:
WTF
Do you got what I meant?
leave it.
Click to expand...
Click to collapse
look, there is no need for condescension and bad language, a simple "no" would have sufficed

Lol not meant to hurt you! but on which planet WTF is bad language
Here search WTF on xda

dr.ketan said:
1.Needs root for this command. If he have rooted device then why so much trouble needed. Simply use root explorer to copy
2.Since long Samsung have removed system from proc/mounts still magisk system_root can be used
3.Even with system in mounts you can't do system rw on S22 because of Samsung have implemented extra layer of protection. Even not with magisk system_root too
Indeed as of now there is no method available to make stock system/vendor/product/odm rw on S22 even with root access.
4.To copy file from system rw mount not needed, ro is fine
Click to expand...
Click to collapse
So my device is strange. It doesn't have root, but it indeed shows options in recovery to apply updates from ADB, SD Card aswell as boot directly to BL and to Mount /System, but when I'm booted, the OS is denying me permission to "Su" . I have verified that USB debugging is activated. So I'm trying to see if there's a way to pull the build.prop from Recovery since the Mount /System option is available, but my computer refuses to recognize the device in while in recovery, but easily finds it in Download, BL mode. No FRP lock. No accounts on device. But also no option to unlock bootloader. This device in particular is/was a development sample so I have no clue what the current state of the bootloader etc is in terms of being unlocked prior to me working on it.

It'd also worth noting that this device was loaded with Android 11 when I received it. I'm not kidding. So idk what's going on with this FrankenGalaxy

K0mraid3 said:
It'd also worth noting that this device was loaded with Android 11 when I received it. I'm not kidding. So idk what's going on with this FrankenGalaxy
Click to expand...
Click to collapse
K0mraid3 said:
So my device is strange. It doesn't have root, but it indeed shows options in recovery to apply updates from ADB, SD Card aswell as boot directly to BL and to Mount /System, but when I'm booted, the OS is denying me permission to "Su" . I have verified that USB debugging is activated. So I'm trying to see if there's a way to pull the build.prop from Recovery since the Mount /System option is available, but my computer refuses to recognize the device in while in recovery, but easily finds it in Download, BL mode. No FRP lock. No accounts on device. But also no option to unlock bootloader. This device in particular is/was a development sample so I have no clue what the current state of the bootloader etc is in terms of being unlocked prior to me working on it.
Click to expand...
Click to collapse
These options are normal in stock recovery and can be used only for flashing official zip (OTA), To have root access on your recovery, you needs custom one (TWRP) which is in development stage on S22
Without twrp, You needs to root device (must have oem unlock option in development option) to access system files while you are booted to android.
Android 11 on S22? Can you show me screenshot of settings - about phone - software info?

dr.ketan said:
These options are normal in stock recovery and can be used only for flashing official zip (OTA), To have root access on your recovery, you needs custom one (TWRP) which is in development stage on S22
Without twrp, You needs to root device (must have oem unlock option in development option) to access system files while you are booted to android.
Android 11 on S22? Can you show me screenshot of settings - about phone - software info?
Click to expand...
Click to collapse
Thanks for the clear answer, that's kind of what I'm working on is trying to gain root access, but like you said, I need oem unlocking, which isn't on this device. So I'm trying to find a backdoor/vulnerability that will take me even one step closer to atleast finding a way to set ro.secure. prop. Something VERY interesting I did find, is that if you put the device to Debug medium or high via device keystring activity, and play with the key combos, you can get booted into a mode called RDX, if you plug it into your dev system with the right drivers, it's treats the phone as if it were a Disk and shows a bunch of VZW upgrade software ment for PCs. I've installed it but haven't got it working quite yett.

No idea what you have shown in screenshot, I'd asked something else.

dr.ketan said:
No idea what you have shown in screenshot, I'd asked something else.
Click to expand...
Click to collapse
Maybe Heindall will give me better results. I just refuse to believe the manufacturers have outsmarted us all on this.