Reasons for Rooting Android

A stock Android device is locked down, by default. Rooting is the process of getting access to the root user (think: installing su). This article lists several advantages of a rooted device.

NTPsync

The Android system has a 'automatic date & time' setting ('use network-provided time') that is enabled, by default. Unfortunately, Android doesn't use the internet (think: NTP) for this but the GSM network. The time synchronisation methods provided by mobile operators are notorious for delivering the wrong time (German press coverage: 2015, 2016)). Your author nearly missed a train because of such incorrect time data.

Accessing a NTP server from an Android app isn't a challenge, but the system doesn't allow to set the system time from an app. This makes sense for the obvious security implications, but the system doesn't even provide a special permission an app could request.

Thus, root is required to sync the device time with an NTP server. The NTPSync app is an open-source app that is able to display the remote time (doesn't require root) and to set the system time. It requests root permissions for that and thus requires a rooted device for this feature.

Create USB Mass Storage devices

What is better than a collection of USB sticks you have to carry around for different purposes? Yes, your Smartphone emulating of bunch of USB sticks. After all, you already carry around your Smartphone all the time, anyways.

Stock Android doesn't provide this functionality. But it still has enough Linux infrastructure included to easily configure emulated mass storage devices - if and only if you have root access on your device.

The USB mountr app provides a simple GUI for temporarily turning your phone into a USB mass storage device. When the emulation is active, plugging the phone to an USB port looks like attaching a USB stick - from the computer point of view. And the phone is even able to charge itself during the emulation.

Simple Backups

Backing up important data from an android device to a connected computer can be a hassle. Some apps provide sync-into-a-cloud support, but not all and perhaps you don't want to put your data into some proprietary cloud you don't trust.

Android apps are able to store data under two different locations. Under a public location (i.e. under /sdcard/) and in a private directory under /data/data/. The public location can be accessed without root-permissions, e.g. via adb pull or via a Termux session. A normal user cannot access the private directory, though.

There is a adb backup command for backing up the private app data but there are two caveats. This functionality regularly breaks with different Android/adb version. The resulting archive is encrypted if your Android is encrypted. As always, the encrypted archive doesn't use some standard format that you could decrypt using standard tools. Instead, it's in some legacy format such that you can't easily extract the included XML preference files and SQLite database files on your computer.

On a rooted device doing a backup is as simple as starting an sshd in a Termux session, telling rsync to su and rsync some directories.

Example:

$ rsync -ai --rsync-path=/data/data/com.termux/files/home/sursync \
    phone.example.org:/data/data/org.example.app /mnt/backup/phone

where the sursync helper script looks like this:

#!/data/data/com.termux/files/usr/bin/bash
exec su -c "rsync $*" -- - --

Separate Disk Encryption Password

Android supports disk encryption since version 4.4 (improved architecture since 5). Conceptually, the disk encryption works similarly to luks-cryptsetup (i.e. the user password just encrypts the real key - one that this randomly generated - and can be easily changed with having to re-encrypt everything). But Android being Android, a new format and new tools were developed.

By default, Android uses the same password for disk encryption as for the lock screen and there is no GUI for changing them independently. As-is, this is unfortunate - because you naturally want to use a strong password for disk encryption and a weaker (think: shorter) one for the lock screen.

Thus, using a strong password for both is impractical due to the number of unlock operations during the day and using a weak password for both enables trivial brute-forcing (e.g. when somebody steals your phone).

One some Android devices the situation is improved with additional hardware. There, the user password is signed with a private key that presumably can't leave a trusted hardware environment (a.k.a. TEE, TrustZone). The signature then is used to encrypt the real disk encryption key. This helps against brute forcing if and only if the trusted environment really is secure, implements some kind of rate limiting and/or automatic lock-down in case of to many authentication failures.

In any case, with root permissions it is easily possible to independently set a filesystem encryption password.

With that it is sufficient that just the lock-screen implements some effective rate-limiting which could even escalate to unmounting the encrypted filesystem - e.g. via a shutdown. And at that point the attacker has to deal with the stronger disk encryption password.

Example:

Change the disk encryption password on Lineage 14.1:

$ adb shell
$ su
# vdc cryptfs verifypw $currentpw
# echo returns a 3-tuple, last component 0 -> success, 1 -> failure
# vdc cryptfs changepw password $oldpw $newpw
# vdc cryptfs verifypw $newpw

The vdc syntax varies between different Android versions.

Side Note: Rooting vs. Unlocking vs. Flashing

Perhaps not all of this isn't directly obvious:

  • Unlocking the bootloader doesn't automatically root your phone.
  • After unlocking the bootloader and flashing an alternative recovery image like TWRP, booting into the recovery image allows you to connect via adb shell and that session then has root permissions.
  • The device isn't rooted by default after flashing an alternate system image like Lineageos. With stock Lineageos the device is still unrooted. Lineageos provides a su addon.
  • The sandboxing of apps using Linux mechanisms like SELinux is still active after the device is rooted.
  • Rooting results in the availability of a su command.
  • After rooting, the su command can directly be executed from an adb shell session.
  • The Lineageos su addon installs su such that it is integrated into the permission system. That means that an app trying to get root (via su) needs the root-permission. With Lineageos' Privacy Guard the default for this permission is always-ask.