Android Lock Screen Bypass with ADB: What Still Works?

ADB cannot normally bypass the PIN, pattern, or password on a modern Android phone. The well-known method of deleting /data/system/gesture.key applies to much older Android versions and does not work as a general unlock method today.

This tutorial tests that legacy method on a rooted Android 10 Genymotion device, then explains how Gatekeeper, Weaver, and file-based encryption changed Android lock-screen security.

Android Debug Bridge (ADB) is Google's command-line tool for communicating with an Android device from a computer. It can open a shell, transfer files, install apps, and run debugging commands when the device allows that connection.

On a normal production phone, ADB is not a recovery method for a forgotten lock-screen PIN. USB debugging must already have been enabled, and the host computer normally needs to have been authorized while the device was unlocked. Genymotion provides root ADB access in this setup, which gives the shell much more access than ADB normally has on a locked production phone.

Can ADB bypass an Android PIN or pattern?

Usually not on a modern production Android phone. Modern Android no longer relies on a simple gesture.key file for lock-screen security. PINs, patterns, and passwords are tied into Android's secure credential-verification and encryption systems, which are explained later in this guide.

If you forgot the PIN on a current phone, Google's supported recovery path is normally to erase the device and set it up again. Google still documents account-based pattern reset only for Android 4.4 and older.

The commands below use a rooted Android 10 Genymotion device to test the old ADB claims directly. You will see that gesture.key does not even exist, and that deleting locksettings.db is unreliable and does not prove that encrypted user data has been recovered. The test shows why that method fails on this Android 10 image and why the same approach should not be treated as a general modern Android bypass.

Which Android Lock Screen Bypass Methods Still Work?

Genymotion gives ADB more privileges than a normal production phone. On a physical device, USB debugging must normally have been enabled beforehand, the computer must already be authorized, and root ADB is generally unavailable.

If you forgot the PIN on your own phone

For a current Android phone, Google's supported path is normally to erase the device through Find Hub or recovery mode and restore from backup. A factory reset removes local data rather than recovering the forgotten PIN, and Factory Reset Protection may require the previously associated Google account during setup. The detailed recovery notes are later in this article.

Why the Old gesture.key ADB Bypass Is Outdated

The legacy ADB method removes lock-related files under /data/system/:

1. Get a root shell over ADB
2. cd /data/system
3. Delete gesture.key, password.key, and sometimes locksettings.db*
4. Reboot and walk past the lock screen

This method comes from older Android lock-screen implementations, where pattern/password verification relied on files such as gesture.key and password.key. AOSP later moved enrollment toward Gatekeeper-backed handles and then toward synthetic-password and Weaver-backed designs.

On the Genymotion Android 10 guest used here, after a PIN was set:

• gesture.key, password.key, gatekeeper.password.key, and gatekeeper.pattern.key were missing under /data/system
• locksettings.db still existed and recorded a numeric PIN type
• Gatekeeper enrollment material lived under /data/misc/gatekeeper/ as small files named 0 and 100000
• No Weaver service was exposed

On this Android 10 image, gesture.key does not exist, so deleting it cannot change the lock state.

How Modern Android Protects the Lock Screen

Modern Android does not treat the PIN as just a hash stored in one removable file. The PIN, pattern, or password participates in a chain that verifies the credential and unlocks encryption keys.

Android documentation refers to the user's PIN, pattern, or password as a Lock Screen Knowledge Factor (LSKF). The framework uses it during enrollment and verification, then unlocks credential-bound storage and authentication-bound Keystore keys.

At a high level:

• LockSettingsService manages lock-screen settings and coordinates setting and verifying the credential
• Synthetic password is a randomly generated internal secret used by modern Android's lock system. The user's PIN/password helps unlock this secret, which Android can then use when protecting credential-encrypted data
• Gatekeeper / Weaver help Android verify the credential securely and slow down repeated incorrect guesses
• File-based encryption (FBE) separates Device Encrypted (DE) and Credential Encrypted (CE) storage

A Trusted Execution Environment (TEE) is an isolated part of the processor designed to handle sensitive operations separately from normal Android.

Android uses the lock-screen credential to help protect the synthetic password. It also needs a secure way to verify attempts and prevent unlimited guessing.

When supported, Weaver provides hardware-backed secret storage with rate limiting. Other devices use Gatekeeper for secure credential verification and throttling. The exact arrangement depends on the Android version and hardware.

File-based encryption and CE vs DE

Android 7 and later support FBE. Devices launching with Android 10 or higher must use it. Each user gets:

• Device Encrypted (DE) storage — data Android can access after the device boots, even before the user enters the PIN
• Credential Encrypted (CE) storage — private user data that normally becomes available only after the user successfully unlocks the device after boot

Apps should keep private user data in CE storage whenever possible. That is why "the lock UI disappeared" is not the same as "I recovered the owner's private app data."

The most important time is immediately after a reboot, before the PIN has been entered for the first time. Once the user has successfully unlocked the device, CE keys are normally loaded and CE data remains available while that Android session stays running, even if the screen is later locked again. This means root access obtained after the user has already unlocked the phone may expose more data than root access immediately after a reboot.

Root access controls the normal Android operating system, but it does not automatically give access to secrets protected inside the TEE or Secure Element. Wiping a SQLite metadata file does not mean you recovered an unknown PIN.

This Genymotion guest reported ro.crypto.type=file and ro.crypto.state=encrypted. Emulator cryptography is still not a substitute for OEM TEE/Weaver deployments on physical hardware.

Build the Rooted Genymotion Lab

Use a disposable emulator. Finish the Genymotion Android pentest lab first so Kali can reach the guest over the host-only adapter. The commands below use Genymotion Android 10 / API 29 with root ADB at 192.168.56.104:5555.

Confirm ADB sees the guest:

adb connect 192.168.56.104:5555

connected to 192.168.56.104:5555

Confirm that ADB lists the emulator with the status device, which means the connection is ready:

adb devices -l

List of devices attached
192.168.56.104:5555    device product:vbox86p model:Phone device:vbox86p transport_id:3

If your guest uses another host-only address, substitute that IP. Check the Android version, API level, and encryption state:

adb -s 192.168.56.104:5555 shell getprop ro.build.version.release
adb -s 192.168.56.104:5555 shell getprop ro.build.version.sdk
adb -s 192.168.56.104:5555 shell getprop ro.crypto.type
adb -s 192.168.56.104:5555 shell getprop ro.crypto.state

10
29
file
encrypted

Android 10 maps to API 29. file and encrypted mean the guest reports file-based encryption.

Genymotion returns uid=0 for adb shell in this setup, meaning the shell already has root privileges. That root access allows the shell to modify files that would normally be inaccessible through ADB on a production phone.

Inspect the PIN and Lock State with ADB

Set a known lab PIN with the locksettings tool. Use a disposable value such as 2468, never a personal PIN:

adb -s 192.168.56.104:5555 shell locksettings set-pin 2468

Pin set to '2468'

Inspect Android's current lock-settings state:

adb -s 192.168.56.104:5555 shell dumpsys lock_settings

Current lock settings service state:
SP Enabled = false
    User 0
        SP Handle = 3e3a66d9915f1151
        SID = c141c2d871b98a99

The exact fields vary by Android build. The important point here is that Android created lock-related state after the PIN was set; it did not create the old gesture.key or password.key files.

Confirm wrong and right credentials:

adb -s 192.168.56.104:5555 shell locksettings verify --old 9999

Old password '9999' didn't match

Verify the PIN you just set:

adb -s 192.168.56.104:5555 shell locksettings verify --old 2468

Lock credential verified successfully

The successful and failed verification results confirm that the emulator is enforcing the PIN. Next, look for the legacy key files named by the old bypass method:

adb -s 192.168.56.104:5555 shell ls -la /data/system/gesture.key /data/system/password.key /data/system/gatekeeper.password.key /data/system/gatekeeper.pattern.key

ls: /data/system/gesture.key: No such file or directory
ls: /data/system/password.key: No such file or directory
ls: /data/system/gatekeeper.password.key: No such file or directory
ls: /data/system/gatekeeper.pattern.key: No such file or directory

Inspect the database and Gatekeeper directory that did exist:

adb -s 192.168.56.104:5555 shell ls -la /data/system/locksettings.db*

-rw-rw---- 1 system system 20480 2026-09-13 10:26 /data/system/locksettings.db
-rw-rw---- 1 system system 32768 2026-09-13 10:27 /data/system/locksettings.db-shm
-rw-rw---- 1 system system 41232 2026-09-13 10:27 /data/system/locksettings.db-wal

The Gatekeeper directory contains numeric enrollment files rather than the legacy gesture.key file:

adb -s 192.168.56.104:5555 shell ls -la /data/misc/gatekeeper/

total 36
drwx------  2 system system 4096 2026-09-13 10:27 .
drwxrwx--t 45 system misc   4096 2026-09-13 10:24 ..
-rw-------  1 system root      0 2026-09-13 10:25 .coldboot
-rw-------  1 system root      8 2026-09-13 10:27 0
-rw-------  1 system root      8 2026-09-13 10:27 100000

Query the framework database for the password type and synthetic-password handle fields:

adb -s 192.168.56.104:5555 shell "sqlite3 /data/system/locksettings.db \"SELECT name,value FROM locksettings WHERE name IN ('lockscreen.password_type','sp-handle');\""

lockscreen.password_type|131072
sp-handle|4484009463633613137

lockscreen.password_type identifies the configured credential type, while sp-handle is lock-framework state associated with Android's newer synthetic-password design. Neither value contains the PIN itself.

Check which lock-related Android services are running:

adb -s 192.168.56.104:5555 shell service list | grep -iE 'lock_settings|gatekeeper|weaver'

80	lock_settings: [com.android.internal.widget.ILockSettings]
145	android.service.gatekeeper.IGateKeeperService: [android.service.gatekeeper.IGateKeeperService]

Gatekeeper was present. Weaver was not. Genymotion is useful for demonstrating the Android framework, but it does not reproduce every hardware security feature found in a physical phone.

Test the Old ADB Lock-Screen Bypass

Now test the two legacy file-deletion methods against the Android 10 emulator.

Test 1 — Delete gesture.key

The legacy gesture.key method starts by deleting:

adb -s 192.168.56.104:5555 shell rm -v /data/system/gesture.key

rm: /data/system/gesture.key: No such file or directory

The command fails because /data/system/gesture.key does not exist on this Android 10 image.

Test 2 — Remove locksettings.db on a disposable emulator

A more destructive variant removes the locksettings.db database files and then reboots. Treat that as a disposable-emulator experiment only, and take a Genymotion snapshot first. Do not run it on a phone with real data.

On this Android 10 image, removing locksettings.db, locksettings.db-shm, and locksettings.db-wal, then rebooting, produced two outcomes in controlled testing:

• One run cleared the emulator lock UI (locksettings verify reported that the user had no password) while Gatekeeper files under /data/misc/gatekeeper/ were still present
• A later factory-reset retest left the guest stuck on Genymotion's Starting screen with ADB unreachable until another factory reset

The result was inconsistent across emulator runs, which is enough reason not to treat database deletion as a reliable bypass. A UI clear is a misleading emulator outcome, not PIN recovery and not proof for physical phones. A hung boot shows how fragile the experiment is even on a lab VM.

Do not delete /data/misc/gatekeeper/*. Removing those enrollment files and rebooting previously left this image unreachable and required recovery from the Genymotion host.

Test 3 — locksettings clear with the known lab PIN

In this rooted emulator, locksettings clear provides a cleaner way to remove a known lab PIN without manually deleting lock-related database files:

adb -s 192.168.56.104:5555 shell locksettings clear --old 2468

Lock credential cleared

After that clear, verification reported that the user had no password and ADB stayed healthy:

adb -s 192.168.56.104:5555 shell locksettings verify --old 2468

Old password provided but user has no password

This command successfully removes the lab PIN because the existing PIN (2468) was supplied. It therefore demonstrates authorized credential clearing, not bypass of an unknown PIN.

Why Root ADB Does Not Mean You Know the PIN

Root ADB gives the shell very high privileges inside Android. It can read or modify many files and control processes. That still does not mean the shell knows the user's PIN or can automatically unlock credential-encrypted data.

Those are different capabilities:

• Root can read many DE-accessible files and tamper with incorrectly protected app data
• Root can delete or corrupt lock metadata and brick a device
• Root does not automatically reveal the lock-screen PIN, pattern, or password
• Root does not automatically unwrap CE storage until the user successfully unlocks the device on a correctly implemented system

After first unlock in a running session, CE data may already be available to a privileged shell even while the screen is locked again. This is still different from recovering an unknown PIN from a freshly rebooted, locked phone.

Tools such as Andriller still depend on what ADB can reach. They do not turn a locked modern handset into plaintext by deleting a missing legacy file.

Why a Physical Android Phone Is Different

The Genymotion results show why file-deletion behavior on a rooted emulator should not be generalized to physical Android phones.

What to Check on Newer Android Versions

On a newer Genymotion or AVD image in an authorized lab, inspect rather than wipe:

1. Set a disposable PIN with locksettings set-pin.
2. Check whether gesture.key or password.key exist rather than assuming the legacy files are present.
3. List /data/system, /data/system_de/<user>/spblob, and any Weaver-related paths your build exposes.
4. Run service list and look for Weaver as well as Gatekeeper.
5. Compare what you see with current AOSP Gatekeeper, Weaver, and FBE documentation.

Do not assume deleting locksettings.db is meaningful on newer versions merely because an emulator lets you modify the file.

Recover Your Own Android Device If You Forgot the PIN

If you forgot the PIN on your own Android device, the practical recovery options are:

• Erase the device through Google's Find Hub when available, then restore from backup
• Use the manufacturer's documented account-recovery or recovery-mode reset process
• Restore data from Google or OEM backups that were created before the lockout
• Authorized service centers when hardware failure is involved
• For enterprise devices, MDM wipe and re-enrollment playbooks

A factory reset removes the lock by erasing local data. It does not recover the forgotten PIN. Factory Reset Protection may still require the previously associated Google account during setup.

Summary

The legacy ADB method of deleting /data/system/gesture.key is not a reliable way to bypass a modern Android lock screen. On the Android 10 Genymotion image used here, the file did not exist after a PIN was set, while Gatekeeper-related enrollment data was stored elsewhere.

Deleting locksettings.db was also unreliable, while locksettings clear --old succeeded only when the existing PIN was supplied.

For a forgotten PIN on a current phone, the normal recovery path is erase and restore rather than deleting Android lock files through ADB.

The main distinction is simple: modern Android lock security depends on credential verification and encryption mechanisms that cannot be replaced by deleting one legacy file.

References

• Android Gatekeeper (AOSP)
• Android Weaver (AOSP)
• File-based encryption (AOSP)
• Android Debug Bridge (adb)
• Unlock your Android device if you forgot PIN, pattern or password (Google Support)
• Genymotion Desktop documentation