How It Works

This page explains the technology behind LTBox in more detail. You do not need to read it to use the tool, but it helps to understand what happens during each operation.

The core idea: a trusted test key

Android Verified Boot (AVB) protects the boot chain. Each signed image (such as vbmeta, boot, or vendor_boot) carries a signature, and the bootloader only runs an image when that signature matches a public key it trusts. On a locked device this normally stops you from flashing modified images.

The affected Lenovo tablets ship a bootloader (ABL) that trusts the AOSP test key as its AVB root of trust. That key pair is not secret — the matching private key is published in the public AOSP source tree (external/avb/test/data/testkey_rsa4096.pem). Because the private key is public, anyone can sign an image that the locked bootloader still accepts as authentic.

LTBox builds on this single fact. After it changes an image, it rebuilds the AVB metadata so the locked bootloader still trusts the result: vbmeta and signed boot images are signed again with the AOSP test key, and hash-only images (like vendor_boot) get a fresh AVB hash footer. LTBox uses the embedded test-key specifications from avbtool-rs (testkey_rsa2048 / testkey_rsa4096), so no external key file is needed.

Region conversion

Lenovo sells the same hardware as a China (PRC) model and a Global (ROW) model. The two builds differ in a region marker stored inside vendor_boot.img.

LTBox converts between regions like this:

  1. Find the markers. It scans vendor_boot.img for the region tags .PRC / IPRC (China) or .ROW / IROW (Global) and detects the image's current region. If it already matches the target region, nothing is changed.
  2. Patch the bytes. It swaps the markers to the target region (for example .PRC → .ROW).
  3. Recompute the vendor_boot hash. Changing the bytes breaks the original AVB hash, so LTBox recomputes the AVB hash footer for the patched image.
  4. Rebuild vbmeta. vbmeta.img stores hashes of the other partitions, so it must be rebuilt too. LTBox keeps the descriptors from the original vbmeta and replaces the one for vendor_boot with the value from the patched image, then re-signs vbmeta with the test key.

The result is a matched vendor_boot.img + vbmeta.img pair for the new region that the bootloader still accepts.

Since v3.1.4, this also works when the target firmware has already fixed the test-key ABL vulnerability but the device's currently installed firmware has not. LTBox backs up the device's current abl, converts the region, re-signs only the needed AVB chain partitions with the AOSP test key, flashes the firmware, then overlays the re-signed partitions and restores the backed-up abl. The device keeps its test-key-trusting bootloader, so the converted firmware can still boot on a locked device.

Rooting

Rooting injects a root provider into the boot image and re-signs it. LTBox picks the right image and method for each provider:

  • KernelSU / KernelSU Next / SukiSU / ReSukiSU — these use the LKM (loadable kernel module) approach. LTBox patches init_boot.img: it replaces the init binary in the ramdisk with the KernelSU bootstrap and stages the kernelsu.ko module so the stock kernel loads it at boot.
  • Magisk (and forks) — LTBox extracts the patch payload from the Magisk APK and applies it to init_boot.img, the same way the Magisk app patches a boot image on the device.
  • APatch / FolkPatch — these patch the kernel itself. LTBox extracts the kernel from boot.img, patches it with kptools (adding a superkey and any kernel patch modules), and repacks it.

For the KernelSU family there is also an optional GKI mode: instead of the LKM ramdisk path, LTBox replaces the kernel in boot.img using a kernel package (an AnyKernel3 zip) that you supply.

After patching, the image is repacked and re-signed with the AVB test key. The device boots the modified image because the bootloader trusts that signature. The Unroot Device action simply restores the stock boot image that LTBox backed up before rooting.

Rollback Protection Bypass

AVB also has a rollback index: a number that only goes up. The bootloader refuses to boot an image whose rollback index is lower than the value the device has already committed. This is what normally blocks downgrades.

Rollback indices are recorded against two partitions, so LTBox tracks a separate floor for boot and for vbmeta_system instead of one device-wide number, and each image is judged against the floor for its own location. It handles the bypass like this:

  1. Read the device floors. Where they come from depends on how the flash started:

    • Starting in EDL, LTBox dumps boot and vbmeta_system from both slots and takes the highest index for each location — the two slots can hold different images.
    • In Bootloader mode, LTBox reads and classifies the stored_rollback_index:N entries. Of the two relevant locations, the lower one is vbmeta_system and the higher one is boot.

    When nothing non-stock is committed, the device has no floor and no patch is needed.

  2. Compare and patch. Each image's rollback index is compared with the floor for its own location. There are three modes (shown on the Confirm screen):

    • On — always update the target images to the device's floor.
    • Auto — update only when the image's index is lower than its floor (the case that would otherwise be rejected).
    • Off — leave the rollback index alone.
  3. Update. When a patch is needed, the image is re-signed (or given a fresh hash footer) with the floor for its location, so the bootloader no longer sees it as an "older" build.

The flashing pipeline

All writes to the device go through Qualcomm EDL (Emergency Download, also called 9008) mode. A full flash uses these steps:

  1. Enter EDL. LTBox detects whether the device is already in EDL or connected through ADB or Bootloader mode. It leaves an EDL device as is, reboots the other two modes into EDL, or waits for you to enter EDL manually.
  2. Upload the programmer. In EDL the device speaks the Qualcomm Sahara protocol. LTBox uploads the firmware's programmer (the xbl_s_devprg/prog_firehose loader) into device memory.
  3. Read and write partitions. The programmer then speaks the Firehose protocol, which LTBox drives to erase, write, and read partitions by name or by LUN.
  4. Reset. When the flash finishes, LTBox resets the device so it boots into the new firmware.

Because LTBox rebuilds the AVB metadata — recomputing hash footers and signing vbmeta with the trusted test key — the device boots normally even though its partitions were changed on a locked bootloader.