takattowo/bootloaderspoofer

★ 12JavaAudience · developerComplexity · 5/5Setup · hard

Mindmap

mindmap
  root((bootloaderspoofer))
    What it does
      Spoof locked bootloader
      Modify attestation cert
      Local checks only
    Two modes
      leaf hack TEE present
      cert generate no TEE
    Requirements
      Root access
      Hook framework
      Custom keybox optional
    Limitations
      Local attestation only
      No server-side bypass
      No online attestation

mindmap root((bootloaderspoofer)) What it does Spoof locked bootloader Modify attestation cert Local checks only Two modes leaf hack TEE present cert generate no TEE Requirements Root access Hook framework Custom keybox optional Limitations Local attestation only No server-side bypass No online attestation

Click or tap to explore — scroll the page freely

Things people build with this

USE CASE 1

Make locally-checked apps believe your unlocked Android device has a factory-locked bootloader.

USE CASE 2

Use cert_generate mode on devices where the hardware security module is broken or absent.

USE CASE 3

Supply your own keybox file to pass local attestation checks in apps that require verified device status.

Tech stack

JavaAndroidTEEkeybox

Getting it running

Difficulty · hard Time to first run · 1day+

Requires a rooted Android device with a compatible hook framework installed, the included test keybox will not pass any server-side attestation check.

In plain English

Android devices have a bootloader, which is the software that starts up before the operating system loads. When the bootloader is "locked," it means the device has not been modified from its factory state. Some apps check this status using a process called local attestation, where the device produces a certificate claiming whether it is in a verified or modified state. This module is designed to make that certificate report a locked bootloader, even if the device's bootloader is actually unlocked. The README is explicit about the scope: this only affects local attestation, which is a check the app performs on-device. If an app sends the certificate to a server for verification, this module does nothing useful and will not pass that check. The authors point to a different tool called TrickyStore for online attestation scenarios. There are two modes. The first, called leaf_hack, works on devices where the secure hardware (TEE) is functional. It lets the device generate a real certificate, then rewrites one specific field in it to claim the bootloader is locked, and re-signs the modified certificate using a keybox key. The second mode, cert_generate, is for devices where the secure hardware is broken or absent. It generates a fresh certificate entirely in software, bypassing the hardware keystore. This mode has limitations: apps that look up the key a second time through the standard Android API will find nothing, and the secure hardware status field is not altered. The module ships with a publicly known test keybox from Google that is not backed by real hardware and will not pass any server-side check against Google's official attestation roots. Users can supply their own keybox in a documented XML format if they have one. This is a technical Android module requiring root access and a compatible hook framework to install.

Copy-paste prompts

Prompt 1

I have a rooted Android device with an unlocked bootloader. Explain the difference between leaf_hack and cert_generate mode in bootloaderspoofer and which one to choose based on whether my TEE is functional.

Prompt 2

Walk me through the XML format for a custom keybox file that bootloaderspoofer accepts, what fields are required and what values do I put in each one?

Prompt 3

Help me write a minimal Android app that runs local key attestation and prints whether the certificate chain reports the bootloader as locked, so I can verify bootloaderspoofer is working.

Open on GitHub → Explain another repo

← takattowo on gitmyhub — every repo by this author, as a profile.

Verify against the repo before relying on details.