Skip to content

How It Works

Jump to bottom
OO edited this page May 29, 2026 · 2 revisions

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.

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. Unroot simply restores the stock boot image that LTBox backed up before rooting.

Anti-rollback 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.

LTBox handles it like this:

  1. Read the device value. It reads the Fastboot stored_rollback_index values and takes the highest non-stock one (max(v > 1)). If every reported value is still stock (0 / 1), the device has no non-stock index and no patch is needed.
  2. Compare and patch. It compares the firmware's rollback index with the device value. There are three modes (shown on the Confirm screen):
    • Modify — always update the target images to the device's index.
    • Auto — update only when the firmware index is lower than the device index (the case that would otherwise be rejected).
    • Ignore — leave the rollback index alone.
  3. Update. When a patch is needed, the chained images are re-signed (or given a fresh hash footer) with a rollback index that matches the device, so the bootloader no longer sees them as "older" builds.

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 gets the device into EDL from its current state — it reboots from ADB or Fastboot 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.

Clone this wiki locally