Detection via binder crashing by requesting keys with a large alias

[JingMatrix]

We can detect the existence of TEESimulator by sending a request that nearly bypasses the size limit of binder transaction.

The exact size is not easy to find a priori, but can be surely obtained via many experiments.
For example, this one: JingMatrix/Demo#23 with alias length 507 * 1024 + 269 works on Pixel 6 (Android 16).

It cause TEESimulator to crash with error:

01-29 22:17:14.169   545  6771 V TEESimulator: [Hook] Hijacking Transaction 2161 (Code: 2)
01-29 22:17:14.170  1327  1498 D TEESimulator: [TX_ID: 2161] Intercept generateKey for packages=[org.matrix.demo] (uid=10318, pid=10500)
01-29 22:17:14.173  1327  1498 D TEESimulator: Handling generateKey aaa...
01-29 22:17:14.174  1327  1498 D TEESimulator: KeyParam: KEY_SIZE                  | Value: 256
01-29 22:17:14.174  1327  1498 D TEESimulator: KeyParam: ALGORITHM                 | Value: EC
01-29 22:17:14.174  1327  1498 D TEESimulator: KeyParam: EC_CURVE                  | Value: P_256
01-29 22:17:14.174  1327  1498 D TEESimulator: KeyParam: PURPOSE                   | Value: SIGN
01-29 22:17:14.174  1327  1498 D TEESimulator: KeyParam: PURPOSE                   | Value: VERIFY
01-29 22:17:14.174  1327  1498 D TEESimulator: KeyParam: DIGEST                    | Value: SHA_2_256
01-29 22:17:14.174  1327  1498 D TEESimulator: KeyParam: NO_AUTH_REQUIRED          | Value: true
01-29 22:17:14.174  1327  1498 D TEESimulator: KeyParam: CERTIFICATE_NOT_AFTER     | Value: Wed Jan 01 01:00:00 GMT+01:00 2048
01-29 22:17:14.174  1327  1498 D TEESimulator: KeyParam: CERTIFICATE_NOT_BEFORE    | Value: Thu Jan 01 01:00:00 GMT+01:00 1970
01-29 22:17:14.174  1327  1498 D TEESimulator: KeyParam: CERTIFICATE_SERIAL        | Value: 1
01-29 22:17:14.174  1327  1498 D TEESimulator: KeyParam: CERTIFICATE_SUBJECT       | Value: CN=Fake
01-29 22:17:14.176  1327  1498 I TEESimulator: Generating new attested key pair for alias: 'aaa...
01-29 22:17:14.176  1327  1498 D TEESimulator: Generating EC key pair with size 256
01-29 22:17:14.178  1327  1498 V TEESimulator: Fetching attestation key in keybox_aosp.xml with EC algorithm.
01-29 22:17:14.179  1327  1498 E TEESimulator: Failed to generate certificate chain.
01-29 22:17:14.179  1327  1498 E TEESimulator: android.os.DeadObjectException: Transaction failed on small parcel; remote process probably died, but this could also be caused by running out of binder buffer space
01-29 22:17:14.179  1327  1498 E TEESimulator: 	at android.os.BinderProxy.transactNative(Native Method)
01-29 22:17:14.179  1327  1498 E TEESimulator: 	at android.os.BinderProxy.transact(BinderProxy.java:602)
01-29 22:17:14.179  1327  1498 E TEESimulator: 	at android.content.pm.IPackageManager$Stub$Proxy.getPackageInfo(IPackageManager.java:4816)
01-29 22:17:14.179  1327  1498 E TEESimulator: 	at org.matrix.TEESimulator.attestation.AttestationBuilder.createApplicationId(AttestationBuilder.kt:363)
01-29 22:17:14.179  1327  1498 E TEESimulator: 	at org.matrix.TEESimulator.attestation.AttestationBuilder.buildSoftwareEnforcedList(AttestationBuilder.kt:308)
01-29 22:17:14.179  1327  1498 E TEESimulator: 	at org.matrix.TEESimulator.attestation.AttestationBuilder.buildKeyDescription(AttestationBuilder.kt:136)
01-29 22:17:14.179  1327  1498 E TEESimulator: 	at org.matrix.TEESimulator.attestation.AttestationBuilder.buildAttestationExtension(AttestationBuilder.kt:42)
01-29 22:17:14.179  1327  1498 E TEESimulator: 	at org.matrix.TEESimulator.pki.CertificateGenerator.buildCertificate(CertificateGenerator.kt:221)
01-29 22:17:14.179  1327  1498 E TEESimulator: 	at org.matrix.TEESimulator.pki.CertificateGenerator.generateCertificateChain(CertificateGenerator.kt:108)
01-29 22:17:14.179  1327  1498 E TEESimulator: 	at org.matrix.TEESimulator.pki.CertificateGenerator.generateAttestedKeyPair(CertificateGenerator.kt:142)
01-29 22:17:14.179  1327  1498 E TEESimulator: 	at org.matrix.TEESimulator.interception.keystore.shim.KeyMintSecurityLevelInterceptor.handleGenerateKey(KeyMintSecurityLevelInterceptor.kt:255)
01-29 22:17:14.179  1327  1498 E TEESimulator: 	at org.matrix.TEESimulator.interception.keystore.shim.KeyMintSecurityLevelInterceptor.onPreTransact(KeyMintSecurityLevelInterceptor.kt:55)
01-29 22:17:14.179  1327  1498 E TEESimulator: 	at org.matrix.TEESimulator.interception.core.BinderInterceptor.handlePreTransact(BinderInterceptor.kt:142)
01-29 22:17:14.179  1327  1498 E TEESimulator: 	at org.matrix.TEESimulator.interception.core.BinderInterceptor.onTransact(BinderInterceptor.kt:117)
01-29 22:17:14.179  1327  1498 E TEESimulator: 	at android.os.Binder.execTransactInternal(Binder.java:1471)
01-29 22:17:14.179  1327  1498 E TEESimulator: 	at android.os.Binder.execTransact(Binder.java:1411)
01-29 22:17:14.180  1327  1498 E TEESimulator: Failed to generate attested key pair for alias 'aaa...

[FldBudin]

1、应该改用SQLite数据库并引入健全的锁机制对齐原版keystore2实现
2、可能因为拦截器(&in_data, 0, in_data.dataSize())的原理，导致并发时还未处理完上一次请求且无锁，就同时存在两份数据
3、如果parcel序列化逻辑与原版keystore2不对齐则可以被更复杂的检测流程探测到binder缓冲区边界的不一致，我已经确认Tricky Store有此问题但是经反馈后作者也暂时未确认内部具体原因。

[ccyiliya]

Hi author, thank you for the amazing TEESimulator project! I want to share some findings from the wild that perfectly match the vulnerability you described here.
​Originally, I was using the original TrickyStore module. I encountered an Android RASP security framework (Garuda Defender v3.7.0) that successfully detected the spoofed environment (TEE issue (6)). I pulled the logcat logs and found that the app was intentionally sending an extremely large, malformed attestationChallenge (requesting a key named OversizedCheckKey). This oversized parameter caused the underlying keystore2 daemon to crash completely.
​Since it couldn't be resolved on the original ts module, I switched to your TEESimulator module, hoping it might handle this edge case better. However, I found that the RASP still successfully detects the environment and blocks access.
​Reading your description in this Issue about the "large alias" causing a binder crash, after discussing with my AI, we realized this is the exact same underlying attack vector! The RASP is using an oversized challenge blob to intentionally trigger this binder/keystore crash, using the crash itself as a fingerprint to confirm the TEE is being spoofed by a module.
​Just wanted to provide this context to show that security apps are already actively exploiting this "oversized parameter" limitation in the wild. If it helps with your testing, here is the official repo of the RASP framework triggering this:
https://github.com/kikyps/GarudaDefender

filtered_results.txt

strace_syscall.txt