18

I have rooted several Samsung devices and the underlying "goal" so to speak seems to be to get the su binary in /system/xbinand install Superuser.apk.

My question is why does one have to jump through all of these hoops to root the phone (install custom recovery and flash pre-rooted ROM or exploit the current installation)? Couldn't one just download a precompiled su, move it to the SD card, and run it via adb? The thing that seems to make a ROM "pre-rooted" is that it has Superuser and the su binary in their respective system paths. I don't see why it is so important that it is ran from /system/xbin.

Improve this question

2 Answers 2

Reset to default
24

The su binary needs both the execution and the setuid permission bit set. The first is needed that the file can be executed and the second is that it automatically runs with the file owner's rights (set user id, or setuid. In this case the owner is root. Read more here).

Files on the external storage don't have the executable and setuid permission bits set and it cannot be granted without root rights. Note also that the SD card is mounted with the 'noexec' flag to prevent execution generally to boot:

shell@android:/sdcard $ ./su
/system/bin/sh: ./su: can't execute: Permission denied
126|shell@android:/sdcard $ chmod 4755 su
Unable to chmod su: Operation not permitted
10|shell@android:/sdcard $ mount | grep /mnt/sdcard
/dev/block/mmcblk0p1 /mnt/sdcard vfat [...],noexec,[...]

That's basically why you can't just copy su onto the SD card and then run it to grant yourself root.

Improve this answer
5
  • So that's the only thing that prevents rooting, the fact that /sdcard is not executable and you can't chmod? Once su is in the appropriate location where it can be chmodded executable your golden. I would think there would be a layer of security to prevent someone from simply running su. On my server and debian box I can't just run su as a normal user, I am prompted for a password. I guess the assumption is that if one can install su they can overwrite the shadow file to change the password?
    – user974896
    Commented Aug 9, 2012 at 17:47
  • 3
    @user974896: Well there's nowhere else for a non-system user to put it that it can be executed, and Android doesn't even have passwd or shadow files anyway. You quite literally need root to put su in an executable location, which is why rooting methods either involve a privilege escalation exploit or getting into a custom recovery (where all bets are basically off).
    – eldarerathis
    Commented Aug 9, 2012 at 17:54
  • Yes. This is the answer.
    – iOS Enthusiast
    Commented Aug 9, 2012 at 18:34
  • 3
    @user974896: in addition to the /sdcard being mounted noexec, the setuid system call can only be called when the suid permission bit is set in the executable, and chown and chmod system call will only allow root to set the setuid bit of a file owned by root (effectively, only root can create an executable that can runs with root privileges). Anyone can call su, but unless the caller is allowed to do so in Superuser's database (or in traditional Linux, in the passwd/shadow database), the call will not succeed. Only the Superuser app (and privileged processes) can modify Superuser's database.
    – Lie Ryan
    Commented Aug 10, 2012 at 6:56
  • 3
    @user974896: This, in addition to the normal security system in Android in which each dalvik application runs as its own user, means that applications that only application in Superuser's whitelist can escalate itself to root without prompt, everyone else will get refused (if it's in blacklist), or will cause Superuser to prompt the user for permission.
    – Lie Ryan
    Commented Aug 10, 2012 at 7:03
5

Rooting involves exploiting the weakness depending on the android version, hence "jump through all of the hoops to root the phone"

Its a chicken-and-egg!

In order to exploit root, you need a unsecured adb daemon (i.e. the capability to remount /system) on the handset, and in order to have an unsecured adb, you need root! AND also, you need a unlocked bootloader.

Have a look at one exploit called zergRush found on github; the function of interest is called do_fault() where an attempt is made to "break" the stack-frame of the vold's daemon by connecting to the pipe owned by it, and cause it to crash by over-writing the stack pointer to point to a copied version of the shell boomsh which then runs from /data/local/tmp.

After reading the source, you will now realize, why copying the su binary is not enough to have the handset "rooted" and why hoops must be jumped through. And also, as the executable bit on the file-system level for the SDcard is blocked, so no go there - that is there for obvious reasons! :)

Improve this answer
7
  • Thanks for the links I will be reading them over later. So even if the sdcard was chmodded 777 from the factory I still could not become root by simply downloading and executing it?
    – user974896
    Commented Aug 9, 2012 at 19:03
  • 1
    correct! No go! Does not make an iota of a difference and since the factory installed ROM will have that protected a lá you need root to achieve that chmod-ding the SDcard's permissions to do that! :)
    – t0mm13b
    Commented Aug 9, 2012 at 19:40
  • 1
    Well what makes su so special if it's in /system/xbin? If you enter adb shell (or run an app as a normal user) you are an unprivilaged user. Why does executing su when it's in /system/xbin make you root as opposed to running it in our theoretically chmod 777 /sdcard?
    – user974896
    Commented Aug 9, 2012 at 19:51
  • /system/xbin is the directory where the busybox utilities go into, and... in a rooted handset, issuing this echo $PATH will yield /sbin:/vendor/bin:/system/sbin:/system/bin:/system/xbin <- notice it! Its in the path! In order to have that in there, you need root hence a lot of chicken-and-eggs situations... :D
    – t0mm13b
    Commented Aug 9, 2012 at 20:07
  • Yes I know that's where it goes by default. What I mean is what is so special about running it there. Why would executing ./su in /sdcard/, /data/, or any non-root required directory not work assuming the factory shipped the ROM with the directory chmodded at 777. What I basically mean is the only thing that stops one from downloading and running ./su is the fact that the directories in which a nonroot user can do this in are non executable or is there a bigger picture.
    – user974896
    Commented Aug 9, 2012 at 20:23

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .