🔐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
    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👍
    As I said, this generally means OEM messed up... And I've never heard of post production fixes for this...

    I believe even China hardware/firmware should support AVB/key attestation correctly even when Google APIs are not used...

    So you could complain/enquire of Xiaomi but doubtful if they can/will help...

    Or continue using rooted with root fixes supporting broken keymaster, but when/if banks start enforcing strongIntegrity you would be able to restore that by locking...

    There is a slim chance you've messed up /persist as Poco users (notably) experienced, but Symptoms look different to me... You have L1 and other stuff working it seems... Please say if you have issues with SIM, BT, WiFi, seeing IMEI and S/N etc (normally /persist corruption signs, even if stock/locked)...

    🙃 PW
    As I said even I locked bootloader still tee broken and can't restore strongintegrity so I will continue using device with root and ignore this bank app cause everything is working good no issues faced.
  • 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 :)