June 9, 2026
How a Biometric App Lock Was Reduced to a Single Callback $$$
I Bypassed a Biometric App Lock With a Frida Script
4bd0_m4g3d
3 min read
I Bypassed a Biometric App Lock With a Frida Script
Most users see a biometric lock screen and assume their data is protected.
A fingerprint prompt appears. The operating system asks for authentication. The app refuses to continue until the user verifies their identity.
Everything looks secure.
That's exactly what I thought when I started analyzing the App Lock feature of a financial application during a mobile security assessment.
A few hours later, I was staring at an unlocked application that had never received a fingerprint scan.
The Initial Assumption
The application offered an optional App Lock feature that could be enabled from the security settings.
Once enabled, reopening the application would display Android's biometric prompt before granting access.
From a user's perspective, everything behaved exactly as expected.
Close the app.
Open it again.
Authenticate with your fingerprint.
Continue using the app.
Nothing seemed unusual.
But security assessments are rarely about what happens when everything works correctly. They're about understanding what the application actually trusts.
So I opened JADX and started tracing the authentication flow.
The Line That Caught My Attention
Eventually I reached the code responsible for displaying the biometric prompt.
The implementation looked surprisingly simple:
BiometricPrompt biometricPrompt = new BiometricPrompt(
this,
mainExecutor,
new BiometricPromptAuthenticationCallback()
);
biometricPrompt.authenticate(promptInfo);BiometricPrompt biometricPrompt = new BiometricPrompt(
this,
mainExecutor,
new BiometricPromptAuthenticationCallback()
);
biometricPrompt.authenticate(promptInfo);At first glance, there was nothing obviously wrong.
The application was using Android's official BiometricPrompt API.
But one detail stood out.
There was no CryptoObject.
That may sound insignificant, but it completely changes the security model.
Applications that want strong biometric protection typically bind authentication to a cryptographic operation. In other words, even after biometric authentication succeeds, the application still needs proof in the form of a successful cryptographic action.
Here, none of that existed.
The application was simply asking Android to show a biometric prompt and then trusting whatever result came back.
That made me curious.
What exactly happened after authentication succeeded?
Following the Rabbit Hole
I continued tracing the code.
The flow was remarkably straightforward.
A successful authentication callback triggered a success result.
That success result was processed.
The lock screen closed.
The application unlocked.
No decryption.
No cryptographic verification.
No secure key usage.
Nothing.
The entire trust decision ultimately depended on a callback:
onAuthenticationSucceeded(...)onAuthenticationSucceeded(...)The moment I realized that, a question immediately came to mind.
What would happen if that callback were called manually?
Building a Quick Test
Rather than modifying the APK, I decided to use Frida.
My goal wasn't to bypass Android's biometric framework.
I simply wanted to see how much trust the application placed in its callback.
The idea was straightforward:
Intercept the biometric prompt.
Capture the authentication callback.
Trigger the success callback manually.
Observe the result.
The script wasn't particularly complicated.
When the application created its BiometricPrompt instance, I captured and retained the callback object.
capturedCb = Java.retain(cb);capturedCb = Java.retain(cb);Then I hooked the authentication method itself.
Whenever the application requested biometric authentication, instead of allowing the normal flow to continue, I triggered:
cb.onAuthenticationSucceeded(result);cb.onAuthenticationSucceeded(result);directly from Frida.
No fingerprint.
No face scan.
Just a callback invocation.
I honestly expected some additional validation step to fail.
Maybe a cryptographic check.
Maybe a secondary verification mechanism.
Maybe an exception somewhere deeper in the code.
Instead, something much simpler happened.
The application unlocked.
The Moment It Worked
There's always a moment during testing when a theory stops being a theory.
For me, that moment happened after launching the application with Frida attached.
I sent the application to the background.
Opened it again.
The biometric prompt appeared.
And then instantly disappeared.
The application unlocked itself.
No biometric interaction ever occurred.
No fingerprint sensor was touched.
The operating system never authenticated me.
Yet the application behaved exactly as if authentication had succeeded.
I repeated the test several times.
The result was identical every time.
At that point the issue was no longer hypothetical.
The App Lock feature could be bypassed because the application trusted the callback itself rather than a cryptographic proof of authentication.
Why the Bypass Worked
The root cause wasn't a bug in Android.
It wasn't a weakness in biometric authentication.
And it wasn't a vulnerability in the biometric framework.
The problem was much simpler.
The application treated:
onAuthenticationSucceeded(...)onAuthenticationSucceeded(...)as proof that authentication had happened.
But a callback is merely a notification.
It is not evidence.
If an attacker can trigger that notification manually, and the application performs no additional verification, then the callback effectively becomes the security boundary.
In this case, that boundary was surprisingly easy to cross.
Responsible Disclosure
After confirming the issue, I submitted a report describing how the biometric App Lock could be bypassed by directly triggering the authentication callback without any cryptographic verification.
The security team validated the finding and awarded a bounty for the report.
Impact
An attacker with the ability to instrument the application could completely bypass the biometric App Lock and gain access to information protected by the feature without providing a fingerprint or any legitimate biometric authentication.
The issue existed because the unlock decision trusted a callback rather than a cryptographic proof of authentication.
Conclusion
The biometric prompt itself was not vulnerable.
The problem was that the application treated a successful callback as proof of identity.
By triggering that callback directly, the entire App Lock mechanism could be bypassed.
A single missing CryptoObject turned a security control into a UI check.