Jump to content

Making sense of Android root

[$pagenav]

Revision on Android rooting

Root solutions

Magisk

The init process starts the system, it launches zygote processes. The entire point is that root level access is extremely restricted, init removes its own access after booting and zygote never allows it to begin with. Of course, certain stuff need root access, but this is effectively determined at boot and in your boot image.

In essence, magisk inserts itself in init, so that a special Magisk process is launched, which has full privileges, and everything else is then resumed. This is why you need to patch/flash boot.img, that is where the instruction for init are located.

KernelSU

It extends the linux kernel with additional features. Instead of creating a new process, everything works as normal, except that when apps launch syscalls to the kernel, something else could happen than normal.

You still need to patch/flash boot.img, since that is where the kernel resides, but in general, kernelsu is better hidden/hideable and more powerful.

Modules

Zygisk

In Android, all system and user processes (with the same ABI) are started by the "Zygote" process. zygisk (zygote - magisk) is inserted in the zygote process, which then allows you to fully control how new processes are handled. You can force them to execute custom code, you can change file access, etc.

SuSFS

Hides paths on the filesystem level at the kernel level.

XPosed

Allows you to insert ROM-level modules, without flashing a new ROM. So, changes which you'll normally need to make at the Android source-code level, which will be then compiled into a new ROM (version), can be made in-place without all that.

Google Play Integrity

To increase security, google implemented play integrity: a series of checks which happen on your device, which allows apps to verify whether you device has been tampered with in any way. The app requests an "integrity token", Google Play Services (not Android itself!) evaluates the device state, returns an encrypted token with the resultant device status and then the app (should) sends it back to the servers for decryption and decision making.

Basic Integrity

This checks for properties on your device. As you can imagine, it is not too difficult to circumvent, so every time it checks for bootloader unlock, for example, it returns false.

Device Integrity

This method is harder to pass and uses device fingerprinting. The device and user interactions are monitored and a unique ID is created. This is much harder to fix, and the solution is to essentially just use a working fingerprint. And to pass arbitrary fingerprints you need root.

Strong Integrity

This creates checks using your CPU's trusted execution environment. This environment knows something is up the moment you unlock your bootloader, so there is no way to spoof the check. Our only saving grace is that most devices do not support this feature, so there are modules which trick the system into thinking the device is older and to pass the check without really doing it.