Resources

People often ask me "How did you learn how to hack?" The answer: by reading. This page is a collection of the blog posts and other articles that I have accumulated over the years of my journey. Enjoy!

On an Android phone, a PIN is used to unlock the screen. It has lots of secret controls: unlocking the screen, authorizing payments, enrolling/changing biometrics, and decrypting user data via credential encryption. The PIN is stored within the TrustZone TEE. This means that an attacker with kernel root access can't even access it.

Verification of the PIN in the secure world creates a new problem: an attacker could just flip the byte for access. So, the secure world returns an AuthToken with an HMAC for access. The provided HMAC key is shared between the Keymaster and every authenticator. TEE hosts a few components:

• Keymaster/Keystore: Manage keys that project CE.
• Gatekeeper: PIN verification + throttling.
• Fingerprint/Face TA: Biometric authentication.

The authors identified a key fact of the design: biometrics share the same key. This makes the gatekeeper, and every biometric TA the same failure domain. If any of the elements can be made to sign an attacker-controlled token, the PIN-authentication collapses. Biometric TAs have the ability to mint valid AuthTokens! From vendor to vendor, these TA's are not standardized for biometrics, and many phones included multiple of these framework. The complexity and sensivity makes it a great attack surface!

On Silead-based Samsung devices, there are five commands for fingerprint authentication. One of them, GET_AUTH_OBJ() takes in a buffer, and generates an HMAC for it. This is literally just a signing oracle! This doesn't give you the pin directly but does allow for offline brute forcing of the pin with requested data. They also found this exact issue on two other devices.

On some devices, there was a signing oracle but only with a particular hardcoded auth type. The Gatekeeper would check on First Unlock but wouldn't check the auth type afterwards. So, it's still a signing oracle but a little less powerful.

On Samsung Galaxy A05s, the fingerprint TA exposes the command validate_incoming_token() to check the HMAC of a token. When the comparison fails, the error handler dumps the key into the TEE log. Qualcomm encrypts the logs, but this is ALSO spilled into shared memory. On MediaTek, logs can be read from dmesg, leaking the key. This allows for arbitrary signing of any AuthToken, leading to an offline PIN brute force attack. This can be done because A) PIN is only 1M candidates, and B) the rate limiter on the Gatekeeper is removed via the ability to sign arbitrary data.

Biometric TA's are good targets for old-school memory corruption. They are large codebases with weak mitigations, and have their keys in memory. On Motorola Edge 40 Neo, they found a stack out of bounds read, via a memcpy without an upper bound. Second, there is a function with an arbitrary-address read via a provided address. By using the first bug to break ASLR, the second address can be used to read the key.

The post shows 8 pins recovered from various phones. Going forward, they have some advice. Don't have signing oracles. Validate the type of the keymaster. Never log secrets. Harden TA against memory corruption bugs. Overall, a fantastic post on identifying an interesting attack surface, and creating large impact from it.