Most attestation bypass tools patch what the real hardware returns. TEESimulator by JingMatrix goes fundamentally deeper — it intercepts the Binder IPC at the ioctl level inside Android's keystore2 process and builds the entire attestation certificate chain from scratch. No real TEE involvement, no patching of existing responses. Pure software simulation of hardware-backed key generation, signed by your keybox, producing certificates indistinguishable from genuine hardware — and replaces TrickyStore entirely.
Core Simulation Capabilities
A complete, stateful software TEE — generating entire key and certificate chains from scratch at the Binder IPC level, without involving real hardware at all.
Binder IPC Interception
Intercepts Binder IPC at the ioctl level inside the keystore2 process — the deepest accessible interception point in Android's key management stack. This is fundamentally different from patching outputs at the Java/framework layer.
Full Certificate Chain Generation
In Force Generation Mode, TEESimulator creates entire certificate chains from scratch — virtual keys, correct attestation extensions, and complete certificate chain — signed by your injected keybox. Apps receive certificates identical in structure to genuine hardware-generated keys.
Dual Operation Modes
Force Generation (!) — full software TEE simulation, no real hardware involvement. Force Leaf Hacking (?) — legacy mode where real TEE generates the key but certificate is intercepted and modified. Automatic (no symbol) — module chooses best mode per device and application.
Per-Package Keybox Control
Configure different keybox.xml files for different app groups using bracket notation ([demo_keybox.xml]). This allows using different signing identities for different apps — for example, a more conservative keybox for banking apps and a different one for gaming.
Configurable Patch Levels
Independently configure the osPatchLevel, vendorPatchLevel, and bootPatchLevel reported in attestation certificates — at both global and per-package levels. These affect only attestation data, not actual system properties.
v3.2 — Critical Fixes
v3.2 is a hotfix release addressing: GMS log flooding mitigation (severe battery drain and spam especially on WearOS and Nearby Share) by bypassing list hooks for GMS, and a critical Binder leak — a strong reference memory leak during Binder transaction interception that caused random crashes.
TEESimulator vs TrickyStore — A Fundamental Difference
The distinction between TEESimulator and TrickyStore is architectural, not just implementation detail. The README is explicit: "This is not TrickyStore. TEESimulator replaces TrickyStore and its forks entirely."
The real TEE generates a key. TrickyStore intercepts the resulting certificate and modifies it after the fact — patching the chain to insert a different signing certificate while leaving the key pair itself untouched.
TEESimulator intercepts at the Binder IPC level before any real TEE involvement and generates the entire virtual key pair and certificate chain from scratch — the real hardware never participates in the attestation at all.
Because TEESimulator generates complete virtual keys, it can also maintain stateful key consistency — the same virtual key is returned on repeated requests, unlike patching approaches that must generate fresh certificates each time. This is the foundation of the project's long-term "full stateful emulation" goal.
keybox.xml Configuration
TEESimulator is configured via keybox.xml files placed in /data/adb/tricky_store/ (compatible paths). The format follows the standard Android Attestation XML schema:
Specify different keybox files per app group using [filename.xml] bracket notation in your target.txt. Settings in the patch level config follow system=YYYY-MM-DD, vendor=device_default, boot=no syntax — global defaults with per-package overrides via [com.package.name] sections.
Frequently Asked Questions
keystore2 and generates the entire certificate chain from scratch — virtual keys, extensions, and all — without involving the real hardware TEE at all. This is a fundamentally more complete simulation approach.
!) creates a complete software-based virtual key — the full TEE simulation that generates the certificate chain entirely without touching real hardware. Force Leaf Hacking Mode (?) is the legacy approach where a real TEE key is generated but its attestation certificate is intercepted and modified. Without a symbol, Automatic Mode lets the module choose the best approach.