AddingADBRootToAnImage¶
- Table of contents
- AddingADBRootToAnImage
Introduction¶
This page explains how to enable adb root support by default without any authentication to an existing Replicant release, for instance to get very early logs or to get a shell very early in the boot process, in order to debug or fix boot issues.
That tutorial can also be used to do other things like:- Adding root support to a recovery image.
- Modifying some files in the initramfs (with some limitations)
Issues with zImages¶
Some devices (The Galaxy S (GT-I9000), Galaxy SII (GT-I9100), and Galaxy Note (GT-N7000) uses a zImage because the nonfree bootloader doesn't support the boot.img format. Because of that, this tutorial doesn't cover theses devices (yet).
Security risks¶
Keep in mind that once you add adb root support by default without authentication to a Replicant installation (by modifying the boot.img file), your device becomes potentially vulnerable to juice jacking .
So if you want to prevent any issues it might be best to put back the original boot.img once you don't need adb root support by default without any authentication anymore.
If you add adb root support by default without authentication to the recovery instead, the risk is much more limited as the device would probably need to be rebooted into the recovery to be exposed.
Also, we didn't investigate if any supported devices would be exposed during charge mode (when the device is off and you plug an USB cable).
Adding adb root support to an existing Replicant release.¶
In this tutorial we'll add adb root support to an existing Replicant release. This will gives you adb root during the boot of Replicant. If you want to add adb root to the Replicant 6 recovery, you will need to modify the recovery.img
instead of the boot.img
file. Like the replicant-*.zip file, the recovery.img
file is one of the images releases in the Replicant releases.
- Image: replicant-6.0-0004-rc1-maguro.zip
- Device: Galaxy Nexus (GT-I9250)
You also need to have unbootimg installed. In Parabola this is part of the fso-unbootimg package . It's also possible to compile that tool by hand or to other alternative tools that do exactly the same thing.
You'll need to adapt it slightly for other devices.
First extract the boot.img from the zip
$ mkdir temp $ cd temp $ unzip ../replicant-6.0-0004-rc1-maguro.zip $ file boot.img boot.img: Android bootimg, kernel, ramdisk, page size: 2048, cmdline (androidboot.hardware=tuna)
Then extract the kernel, and initramfs from the boot.img. Also save the infos such as the load address, etc in boot.txt:
$ unbootimg --kernel kernel.img --ramdisk ramdisk.cpio.gz -i boot.img | tee boot.txt total image size: 5619712 kernel size: 4604340 kernel load addr: 0x80008000 ramdisk size: 1009915 ramdisk load addr: 0x81000000 2nd boot size: 0 2nd boot load addr: 0x80f00000 kernel tags addr: 0x80000100 page size: 2048 board: `' cmdline: `androidboot.hardware=tuna' id: 9b90141066f527ecd3909d2ab8e383ebd995fd40000
Then uncompress the initramfs
$ gunzip ramdisk.cpio.gz $ file ramdisk.cpio ramdisk.cpio: ASCII cpio archive (SVR4 with no CRC)
Then edit the default.props, we use sed on the raw cpio image for simplicity (we don't have permissions and username to take care of this way):
$ sed 's#ro.adb.secure=1# #' -i ramdisk.cpio $ sed 's#ro.secure=1#ro.secure=0#' -i ramdisk.cpio $ sed 's#persist.sys.usb.config=none#persist.sys.usb.config=adb #' -i ramdisk.cpio
Then recompress the initramfs
$ gzip ramdisk.cpio
We then recreate the image with the infos we saved in boot.txt. Note that the base is 0x80000000. The kernel has an offset and will be in 0x80008000:
$ mkbootimg --cmdline="androidboot.hardware=tuna" --kernel kernel.img --ramdisk ramdisk.cpio.gz --base 0x80000000 -o boot_new.img
Verify that we got all the arguments right:
$ unbootimg -i boot_new.img | tee boot_new.txt $ diff -u boot.txt boot_new.txt $ --- boot.txt 2020-02-18 00:39:59.890285634 +0100 +++ boot_new.txt 2020-02-18 00:44:16.208897037 +0100 @@ -1,7 +1,7 @@ total image size: 5619712 kernel size: 4604340 kernel load addr: 0x80008000 -ramdisk size: 1009915 +ramdisk size: 1010280 ramdisk load addr: 0x81000000 2nd boot size: 0 2nd boot load addr: 0x80f00000 @@ -9,4 +9,4 @@ page size: 2048 board: `' cmdline: `androidboot.hardware=tuna' -id: 9b90141066f527ecd3909d2ab8e383ebd995fd40000 +id: dd37b2ae1e50be62fe5c94b81b85aa56ffea17be000
You can then reflash the boot.img image.
Don't forget to adjust the heimdall arguments for your device.
If in doubt, it's better to consult the Replicant installation instructions that have the good heimdall arguments, as wrong arguments can completely break your device, making it too complicated to repair (you'd have to un-solder and re-solder resistors that are hardly visible).
heimdall flash --boot boot.img --recovery boot.img
Then you can use adb:
$ adb logcat -b main
Example for the GT-I9300¶
This is valid for the following configuration:- Image: replicant-6.0-0004-rc1-i9300.zip
- Device: Galaxy SIII (GT-I9300)
For other devices like the GT-I9300, the boot.img (or recovery.img) have other parameters:
unbootimg -i boot.img total image size: 4239360 kernel size: 3391376 kernel load addr: 0x40008000 ramdisk size: 844653 ramdisk load addr: 0x41000000 2nd boot size: 0 2nd boot load addr: 0x40f00000 kernel tags addr: 0x40000100 page size: 2048 board: `' cmdline: `console=ttySAC2,115200' id: d34c0412b72d37a2287331e28d902a769c4a86e9000
So we need to adjust the --cmdline and the --base accordingly:
mkbootimg --cmdline="console=ttySAC2,115200" --kernel kernel.img --ramdisk ramdisk.cpio.gz --base 0x40000000 -o boot_new.img
Like with the Galaxy nexus, when we recreate the image with the infos we saved in boot.txt, we need to make sure that the base is right.
Here the base is 0x40000000, which results in the kernel offset (or load address) of 0x40008000.
Going further¶
The Linux kernel has more in depth documentation about initramfs in a file named ramfs-rootfs-initramfs.rst which document how to extract an initramfs and how to recreate one.
However we didn't test that yet. Tests and tutorials are welcome.
We also need to understand if something specific needs to be done for the file permissions when extracting, modifying and rebuilding an initramfs.
Updated by Denis 'GNUtoo' Carikli over 4 years ago · 17 revisions