Bypass Biometric Authentication (Android)

Method 1 – Bypassing with No Crypto Object Usage

The focus here is on the onAuthenticationSucceeded callback, which is crucial in the authentication process. Researchers at WithSecure developed a Frida script, enabling the bypass of the NULL CryptoObject in onAuthenticationSucceeded(…). The script forces an automatic bypass of the fingerprint authentication upon the method’s invocation. Below is a simplified snippet demonstrating the bypass in an Android Fingerprint context, with the full application available on GitHub.^[3]

biometricPrompt = new BiometricPrompt(this, executor, new BiometricPrompt.AuthenticationCallback() {
            @Override
            public void onAuthenticationSucceeded(@NonNull BiometricPrompt.AuthenticationResult result) {
                Toast.makeText(MainActivity.this,"Success",Toast.LENGTH_LONG).show();
            }
});

Command to run the Frida script:

frida -U -f com.generic.insecurebankingfingerprint --no-pause -l fingerprint-bypass.js

Method 2 – Exception Handling Approach

Another Frida script by WithSecure addresses bypassing insecure crypto object usage. The script invokes onAuthenticationSucceeded with a CryptoObject that hasn’t been authorized by a fingerprint. If the application tries to use a different cipher object, it will trigger an exception. The script prepares to invoke onAuthenticationSucceeded and handle the javax.crypto.IllegalBlockSizeException in the Cipher class, ensuring subsequent objects used by the application are encrypted with the new key.^[3]

Command to run the Frida script:

frida -U -f com.generic.insecurebankingfingerprint --no-pause -l fingerprint-bypass-via-exception-handling.js

Upon reaching the fingerprint screen and the initiation of authenticate(), type bypass() in the Frida console to activate the bypass:

Spawning com.generic.insecurebankingfingerprint...
[Android Emulator 5554::com.generic.insecurebankingfingerprint]-> Hooking BiometricPrompt.authenticate()...
Hooking BiometricPrompt.authenticate2()...
Hooking FingerprintManager.authenticate()...
[Android Emulator 5554::com.generic.insecurebankingfingerprint]-> bypass()

Method 3 – Instrumentation Frameworks

Instrumentation frameworks like Xposed or Frida can be used to hook into application methods at runtime. For fingerprint authentication, these frameworks can:

Mock the Authentication Callbacks: By hooking into the onAuthenticationSucceeded, onAuthenticationFailed, or onAuthenticationError methods of the BiometricPrompt.AuthenticationCallback, you can control the outcome of the fingerprint authentication process.
Inspect adjacent network controls: SSL-pinning bypass is not itself a biometric bypass, but traffic instrumentation may reveal whether the backend treats the local callback as sufficient authorization or independently authorizes the sensitive action.

Example command for Frida:

frida -U -l script-to-bypass-authentication.js --no-pause -f com.generic.in

Method 4 – Reverse Engineering & Code Modification

Reverse engineering tools like APKTool, dex2jar, and JD-GUI can be used to decompile an Android application, read its source code, and understand its authentication mechanism. The steps generally include:

Decompiling the APK: Convert the APK file to a more human-readable format (like Java code).
Analyzing the Code: Look for the implementation of fingerprint authentication and identify potential weaknesses (like fallback mechanisms or improper validation checks).
Recompiling the APK: After modifying the code to bypass fingerprint authentication, the application is recompiled, signed, and installed on the device for testing.

Method 5 – Using Custom Authentication Tools

There are specialized tools and scripts designed to test and bypass authentication mechanisms. For instance:

MAGISK Modules: MAGISK is a tool for Android that allows users to root their devices and add modules that can modify or spoof hardware-level information, including fingerprints.
Custom-built Scripts: Scripts can be written to interact with the Android Debug Bridge (ADB) or directly with the application’s backend to simulate or bypass fingerprint authentication.

Method 6 – Universal Frida Hook for `BiometricPrompt` (API 28-34)

In 2023 a community Frida script branded Universal-Android-Biometric-Bypass appeared on CodeShare. The script hooks every overload of BiometricPrompt.authenticate() as well as legacy FingerprintManager.authenticate() and directly triggers onAuthenticationSucceeded() with a fabricated AuthenticationResult containing a null CryptoObject. Because it adapts dynamically to API levels, it still works on Android 14 (API 34) if the target app performs no cryptographic checks on the returned CryptoObject.^[1]

# Install the script from CodeShare and run it against the target package
frida -U -f com.target.app --no-pause -l universal-android-biometric-bypass.js

Key ideas

The hook runs in the app’s user-space process and needs no kernel exploit. On a typical production device, injecting Frida still requires a rooted/debuggable environment or an app repackaged with Frida Gadget; “user space” does not mean the test works on every unmodified, non-rooted device.
The attack remains fully silent to the UI: the system biometric dialog never appears.
Mitigation: always verify result.cryptoObject and its cipher/signature before unlocking sensitive features.

Method 7 – Downgrade / Fallback Manipulation

Starting with Android 11, developers can specify which authenticators are acceptable via setAllowedAuthenticators() (or the older setDeviceCredentialAllowed()). A runtime hooking attack can force the allowedAuthenticators bit-field to the weaker BIOMETRIC_WEAK | DEVICE_CREDENTIAL value:

// Frida one-liner – replace strong-only policy with weak/device-credential
var PromptInfoBuilder = Java.use('androidx.biometric.BiometricPrompt$PromptInfo$Builder');
PromptInfoBuilder.setAllowedAuthenticators.implementation = function(flags){
    return this.setAllowedAuthenticators(0x00FF | 0x8000); // BIOMETRIC_WEAK | DEVICE_CREDENTIAL
};

If the app does not cryptographically bind the result to the sensitive operation, the modified prompt may expose the device-credential fallback or accept a weak biometric. This only helps an attacker who can satisfy that fallback or enroll a biometric using the required device credentials.

Method 8 – Vendor / Kernel-level CVEs

Keep an eye on Android and vendor security bulletins for framework, fingerprint-sensor (FPS), HAL, and kernel flaws. Do not infer a lock-screen or in-app biometric bypass from an EoP classification alone; confirm the affected component, prerequisites, and impact in the vendor advisory.

CVE-2023-20995 appears in the March 2023 bulletin as a moderate Android 13 System EoP. The bulletin does not attribute it to CustomizedSensor.cpp, Pixel 8, or a biometric unlock bypass, so those claims should not be assumed.^[4]
CVE-2024-53835 / CVE-2024-53840 are listed as high-severity EoP issues in the Pixel fingerprint-sensor (FPS) component and were addressed at the December 2024 Pixel patch level. Their public bulletin entries do not disclose enough detail to claim a universal biometric bypass.^[2]

Although these vulnerabilities target the lock-screen, a rooted tester may chain them with app-level flaws to bypass in-app biometrics as well.

Hardening Checklist for Developers (Quick Pentester Notes)

Enforce setUserAuthenticationRequired(true) and appropriate setUserAuthenticationParameters(...) values when generating Keystore keys. Use setInvalidatedByBiometricEnrollment(true) where enrollment changes should invalidate biometric-only keys.^[5]
Reject a CryptoObject with null or unexpected cipher / signature; treat this as a fatal authentication error.
When using BiometricPrompt, prefer BIOMETRIC_STRONG and never fall back to BIOMETRIC_WEAK or DEVICE_CREDENTIAL for high-risk actions.
Keep androidx.biometric maintained, but do not rely on a library upgrade to validate application policy. The app must pass an auth-per-use CryptoObject, use the resulting authorized cipher/signature/MAC for the protected data, and enforce authorization again on the backend where applicable.^[5]