🔐Spoof locked bootloader | "Bypass" TEE check

Search This thread


New member
May 28, 2023
Hide root, do you have Shamiko module?
Yes i have shamiko module, what do you mean by hiding root ?
i use configure deny list and checked the app and didn't force
and i have these modules installed



Senior Member
Apr 19, 2012
Is this module still working for CIB app?
Does it have any workaround to work with OnePlus devices?
Does it have any new updates? The GitHub page seems down.


Senior Member
BootloaderSpoofer + KeyAttestation 1.3.4 bootloader shown as locked

BootloaderSpoofer + KeyAttestation 1.4.1 bootloader shown as unlocked

What could be the reason for this?


  • Screenshot_20230608_193850~2.jpg
    184.9 KB · Views: 75
  • Screenshot_20230608_194200~2.jpg
    186.4 KB · Views: 72
  • Wow
Reactions: chiteroman

Top Liked Posts

  • There are no posts matching your filters.
  • 4
    thanks a lot for the effort my guy but i dont understand why if the app sends the certificate chain to a server the app is unpassable?
    Clue in OP:
    Modify the root of trust in local attestations.
    This module modify the byte array obtained from certificate extensions (link) to spoof a fake root of trust, so we get a fake attestation with a locked bootloader.
    ... In other words, this module injects fake certificate extension data (ie. root of trust data which is real, but with needed bytes altered) into listed apps (/processes)... It can do this (with root privileges) for "local attestations", ie where calls and verification of certificates are done in the Android framework and not on a server.

    This information:
    shows that where hardware-backed key pairs are called and verified remotely (requested by a server directly), there is no opportunity for local interception/tampering key values...

    As the linked Key Attestation sample readme (for use of a parser to extract the attestation certificate extension data) says:
    Android Key Attestation Library
    This library uses the Bouncy Castle ASN.1 parser to extract information from an Android attestation data structure to verify that a key pair has been generated in a hardware-protected environment of an Android device...

    This repository contains a server sample code that shows how to validate an Android attestation certificate chain outside the Android framework. This is the recommended best practice, since if the Android device is rooted or otherwise compromised, on-device validation of the attestation may be inaccurate.

    So although apps can test the certificate and extensions directly on a device, it is safer to run these checks on a separate trusted server. 👀 PW
    will the PINE hook module be easily detected? I haven't tried it out, but I have tested that I can just let the app to not load the play service package dynamically in framework.jar, so it will just use conscrypt classes instead, but apps require play service class to work may fail. But this looks fine to me already.

    BTW, it took me days to just find out that I need to delete '/system/framework/arm', '/system/framework/arm64' and '/system/framework/oat' to make it work after overlaying the framework.jar....
    i dont understand how the attestation work exactly and i also dont understand this

    the app im working on sends the certificate chain in a post request to the server so there is a way to intercept and modify the cert chain?

    and from the code i read the module hooks and modifys system methods to insert the certificate extention data without modifying the target app so if the unmodified target app that does the attestation verification locally verifies and accepts the cert chain why wouldnt the server do as well?
    Good questions, and you probably understand the technical/practical side better than my understanding of the theory, which is only based on reading Google docs. 😜

    However, I understand that it's not actually the attestation certificate chain the app has that gets modified; it's only the validation data that is intercepted and returned with spoofed extension data replacing the attestation certificate data...

    That's why the "server sample" for validating an Android attestation certificate chain outside the Android framework is provided. "This is the recommended best practice, since if the Android device is rooted or otherwise compromised, on-device validation of the attestation may be inaccurate"...

    Where 'local attestation' is used to extract the attestation extension data from the attestation certificate and verify (and print) data elements from the attestation extension (ie. done within the Android framework), the tested certificate and extension data cannot be guaranteed/trusted.

    A server based setup utilising an ASN.1 parser (eg. from Bouncy Castle) will extract the same attestation certificate extension data, but without risk or interception or manipulation...

    Hope it helps...

    @chiteroman may be able to add to/clarify this further. 😜 PW
    If the app checks for the presence of Pine package name yes, but you can modify it.
    I haven't figured it out how to integrate Pine into the framework, but I managed to put your code into framework.jar, I don't find any impacts on other apps for now but finally I can now bypass local key attestation and pass CTS profile without any runtime code injection, just plain kernel su, overlayfs module and hiding overlayfs in kernel. So I think that's enough for me ATM, gotta take some rest.
    And of course, kudos to your code, much appreciated👍
  • 10

    Modify the root of trust in local attestations.

    This module modify the byte array obtained from certificate extensions (link) to spoof a fake root of trust, so we get a fake attestation with a locked bootloader.


    More info about certificate extensions:

    - This module doesn't work with devices which TEE is broken, like OnePlus.
    - You won't pass MEETS_STRONG_INTEGRITY using this.

    Source code and download:

    Apps detecting a locked bootloader:

    - Key Attestation Demo (WORKING)
    - CIB Egypt Mobile Banking (WORKING)
    - Bet365 Authenticator (NOT WORKING)

    Finally Pine Injector works, now we can hook like LSPosed but without using it.

    I will try to bypass that app protection.
    Not exactly what I was hoping for but thanks for your answer nonetheless
    I tried it before but with Magisk magic and it worked! But I will need to study how to implement this in better way. I just throw an exception in engineGetCertificateChain, Momo don't detect it due it's not injection.
    It's a first step 🙃
    I found that only conscrypt.jar works but not framework.jar
    Yep, you must make your super.img partitions read-write and modify it from recovery. You can modify it unpacking the .img or using systemRW script from here link this:

    In TWRP after reboot use:

    adb shell mount -w -v /system_root

    adb push modifiedFramework.jar /system_root/system/framework/framework.jar

    adb shell umount -v /system_root

    In some roms framework directory is an overlay so you must modify it from recovery, also check group and permission to be the same or system won't boot. Also zipalign to 4 bytes the framework.jar always.

    Now you can modify framework.jar and include hooks like mine (POCO X3 Pro MIUI 14.0.3 Indonesian stock rom):

    My source code of es.chiteroman.Hooks:

    You must implement Pine:

    And remember to move libpine.so to /system/lib64 (check your CPU arch)

    Now you can hook any class :)