Performing the actions in this (and following) posts might damage your device. Do it at your own risk on a device that you own. You’ll also likely lose warranty, if the device is still covered. You have been warned.
Less destructive attempts
It might be weird to some, but I have actually never had to root an android phone before. I’m a long time LineageOS user, and it contains the
ADB Root developer option, which gives you root when you connect to the device over ADB. This has been enough to do safe (and unsafe) fiddling with device, extracting information from sysfs, debugfs and apps. Unfortunately Android does not let you run ADB as root. So we can’t even extract the device’s device tree located under
/proc/device-tree, because we lack permissions…
High Level Overview
The path I’ve chosen is a more-or-less standard path for attaining root on any android device, however, it might not work for you, especially if you bootloader can not be unlocked.
- unlock bootloader
- patch stock boot.img with magisk
- flash patched boot.img with fastboot
Android devices have a number of partitions, including boot, system, recovery. boot and recovery contains the kernel, dtb, initfs in a binary format recognized by mkbootimg and abootimg tools.
Linux boot process (and Android boot), work by bootloader providing initfs and dtb to kernel, then kernel proceeds to init hardware based on dtb, and unpack initfs and execute a file inside. Initfs’ task is to prepare the real root filesystem and finally chroot (i.e switch from the initfs root to the real system root).
Unlocking bootloader allows us to install stuff into those partition that is not cryptographically signed by device vendors. Otherwise we can only install updates provided by vendor.
boot.img is normally the file, that is flashed onto the boot partition. The unpacker extracted boot.img from the whole OTA update zip. It also extracted boot.img itself, into underlying kernel, initfs, dtb, cmdline, we’ll use those a bit later.
The way magisk works (at least at the moment of writing), is to take a boot.img (it might be stock or not), and patch (change) it in a way that modifies the initfs to setup root-providing hooks in the system partition. So when the device is operating from the system partition, there is the su binary, that asks for permission via a popup. The su binary and the permission popup code are added from the initfs, that magisk patched.
Important: You’d better update your phone first to latest official build, otherwise you’ll have to repeat the magisk section again after the update.
This will work on “hack friendly” manufacturers, like OnePlus, Oppo, Sony, Samsung,
Nokia, but double check for your particular device!
- become developer: Settings -> About Phone -> Build Number (click many times)
- enable unlocking: Settings -> System -> Developer Options -> enable USB Debugging, OEM Unlocking, Advanced Reboot
- reboot to fastboot: hold power button and choose bootloader, or adb reboot fastboot, then a weird menu appears, choose English -> Advanced -> Reboot to fastboot -> Reboot to fastboot (confirm)
- initiate unlock: run fastboot flashing unlock (might need sudo), confirm prompts on device. NOTE: This will WIPE YOUR DEVICE
- enjoy: after (re)booting the device will will wipe itself (i.e it will start like after a factory reset), and you’ll have an unlocked bootloader
I find it funny, that the whole unlock process talks about how dangerous this is, how it might render your device vulnerable, how the code you might put is less tested than the official code, but only in the last screen, third paragraph, second part it is mentioned that your device will be wiped away immediately. That shows how much Google and the vendors care about you and your data.
Patching boot.img with Magisk
I want to include a note here about rooting paths for android, and how the internet is littered with tutorials and tools with questionable origins. Preferably the tool you use should be open source, and it should be downloaded directly from the source, as any 3rd party websites and download sites might add unwanted/dangerous payload.
Please follow closely the magisk instructions, I’m providing the ones specific to the OnePlus Nord N100 here, but they might not work in the future or for another device:
- become developer (again)
- enable usb debugging (again)
- download magisk zip from github
- install the magisk app: adb install common/magisk.adb
- obtain boot.img (following last post)
- adb push boot.img /storage/self/primary
- click button in magisk app to start patch flow
- adb pull /storage/self/primary/xxxx.img ~/Downloads/boot_patched.img (replace xxxx.img with the actual name of the patched image — it should be displayed in magisk, or you can browse the folders and find it out yourself)
- reboot into fastboot (check previous section)
- fastboot flash boot ~/Downloads/boot_patched.img
- after rebooting, connect with adb, run
su -, confirm the prompt, and you’re root, enjoy
Extracting DT and dmesg
OK, now we can finally finish the data extraction that required permissions.
dmesg is easy, just make sure to do it soon after boot, otherwise the beginning might get lost (there is a finite buffer, and the downstream kernel likes to print a LOT):
### on the device $ su - # dmesg > /storage/self/primary/dmesg.log ### on computer $ adb pull /storage/self/primary/dmesg.log ~/Downloads/dmesg.log
Extracting the device tree is slightly more involved.
dtc (device tree compiler) supports to read from a fs (file system style tree, as provided by kernel), but you have to first move the files to your computer.
### on device # tar -cz -f /storage/self/primary/dt.tar.gz \ -C /sys/firmware/devicetree/base . ### on computer % adb pull /storage/self/primary/dt.tar.gz ~/Downloads % mkdir ~/Downloads/dt % tar -xzf ~/Downloads/dt.tar.gz -C ~/Downloads/dt % dtc -I fs -O dts -o ~/Downloads/dt.dts ~/Downloads/dt ### now you have readable dts in ~/Downloads/dt.dts
If you casually read this you might be thinking “wow, that’s pretty simple”. Well, it is simple for the most part, but but sometimes I try 5 things and only write here what worked (and skip what didn’t).
One thing that provided difficult is extracting the DT from the device. I don’t know what caused it, but for some reason tar wasn’t happy with the files starting with # in the root folder. I though the problem was with the tar that came installed on the android device, so I decided to upgrade to a known version of busybox. So I downloaded the armv8l from here, I put it in /storage/self/primary, but then I couldn’t execute it, because the filesystem is mounted with noexec flag. So I searched all filesystems (mount | grep -v noexec | grep rw) and found /mnt/vendor/persist, which is writable and also executable. There are others, but this seemed not too important to accidentally mess up. So putting busybox there worked. Now I also got less (which is oddly missing from the stock install).
In general, if you have root you can remount filesystems readwrite, or remove the noexec flag, but I guess finding one that works is less risk-prone.
Also, the system that came pre-installed with the phone was really weird. I’ll get into that into next post, but you’ll be better off upgrading to latest OEM version, before doing anything else. If you don’t you’ll have to root it again, and extract the data again (because it is different!).
Another thing I’d like to mention, is that OEM Unlocking option is NOT available (on the OnePlus Nord N100 at least) unless you connect your phone to WiFi (i.e if you just unboxed it, and skipped the WiFi/Cellular setup). So I guess the vendors are dead set on getting info on who is buying their gadgets, because the device phones home, and then when you enable OEM Unlocking, I’m pretty sure it phones home again. If you take your privacy to the extreme you might setup a wifi network behind a VPN, to complete this step.
2021.02.22 (thanks to Konrad):
- Nokia is not a friendly vendor, it looks like
- Sony apparently lets you unlock your bootloader without connecting the phone to the internet first. Go Sony!