Project

General

Profile

Actions

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.

This is valid for the following configuration:
  • 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 10 months ago · 17 revisions

Also available in: PDF HTML TXT