[GUIDE] Access locked AXON 7: How to clear the lockscreen security settings

Oki

Senior Member
Jul 6, 2006
1,009
1,858
0
East Coast
I have been experimenting with flashing, etc. and somehow the lockscreen were corrupted and the pattern I was using was not longer valid. I had the fingerprint already setup so I could enter using the rear sensor, but having a corrupted lockscreen is annoying. THis method requires TWRP custom recovery. It is compatible with locked bootloaders and doesn't modify the stock boot or system. It is also compatible with all the AAXON 7 models.

If you have the stock ROM and need TWRP and ADB interface:
A. Setup ADB interface in your PC and device drivers. and connect your terminal to the PC.
B. Setup axon7tool in your computer. Enter into EDL mode by running the command "adb reboot edl" in the command prompt. The terminal will seen to be off.
C. Disable the antivirus and then backup your recovery image using axon7tool running "axon7tool -r recovery". Save the created file in a safe place.
D. Flash tenfar's signed TWRP as a new recovery using axon7tool. It will reboot to system again.
E. Open the command prompt and run:
Code:
adb devices
adb reboot recovery
1. In TWRP , and with the ADB interface properly installed run these the commands from your computer:
Code:
adb devices
adb shell mv /data/system/locksettings.db locksettings.db.old
adb reboot
Now the system will allow you to pass lockscreen without security. In that case you do not need to apply the rest of the steps. Should you continue experimenting issues with the lockscreen, then you should apply the full procedure. Just add the following 2 steps:
2. Open the command prompt and run:
Code:
adb devices
adb reboot recovery
3. When TWRP had fully loaded, run in the command prompt the following commands:
Code:
adb devices
adb shell mv /data/system/gatekeeper.pattern.key gatekeeper.pattern.key.old
adb shell mv /data/system/locksettings.db locksettings.db.old
adb shell mv /data/system/gatekeeper.password.key gatekeeper.password.key.old
adb shell mv /data/system/locksettings.db-shm locksettings.db-shm.old
adb shell mv /data/system/locksettings.db-wal locksettings.db-wal.old
adb reboot
If you want to restore the stock recovery, you just need to rename the recovery-backup.bin file created in step C back to recovery.bin and run the command "axon7tool -w recovery". after that you can enable your antivirus software again. axon7tool can't connect with some antivirus software. I will be editing this OP with links to the procedures required for each step. All of them are in this forums.

Enjoy
 
Last edited:

Oki

Senior Member
Jul 6, 2006
1,009
1,858
0
East Coast
@Oki
To fix either " Wrong Pattern " , " Wrong Pin " users only need to delete " /data/system/locksettings.db " from either Terminal/File Explorer with root or TWRP File explorer then Reboot and you'll be good to go .
Sure! but this guide is intended for people with the stock, unrooted, blocked bootloader who want to remain with a pure stock experience. Usually people without experience rooting devices. This is why I will edit the guide to add all the details to every step.
 
Last edited:

twilighttony

Senior Member
Dec 14, 2014
178
340
0
Could I do this with a pin as well? I restored a backup and it corrupted my password and I have to use the fingerprint on the back to get in.
 

Oki

Senior Member
Jul 6, 2006
1,009
1,858
0
East Coast
Could I do this with a pin as well? I restored a backup and it corrupted my password and I have to use the fingerprint on the back to get in.
Yes, the procedure deletes everything. If you have problems just do the same also with:

gatekeeper.password.key
locksettings.db-shm
locksettings.db-wal

I have updated the OP just to describe the full procedure.
 
Last edited:

Masterjuggler

Senior Member
Dec 3, 2013
246
228
0
New Jersey
I had this problem earlier today of having the PIN corrupted, but I have it set to require the pin on the first boot.

I fixed it by removing all files ending in ".key" in /system. Not really sure how this compares to removing locksettings.db. Afterward, I put my password back using Google's device manager.

Of course, I am rooted with twrp, so this comes after setting that up.
 

Oki

Senior Member
Jul 6, 2006
1,009
1,858
0
East Coast
I had this problem earlier today of having the PIN corrupted, but I have it set to require the pin on the first boot.

I fixed it by removing all files ending in ".key" in /system. Not really sure how this compares to removing locksettings.db. Afterward, I put my password back using Google's device manager.

Of course, I am rooted with twrp, so this comes after setting that up.
The problem of this method is that it only works if the bootloader is unlocked and the phone has the No-verify patch installed.
 

Masterjuggler

Senior Member
Dec 3, 2013
246
228
0
New Jersey
When you say "No-verify patch," are you talking about removing Google license verification from apps (via an app such as lucky-patcher for instance)? AFAIK that is on a per-app basis and wouldn't affect something like the lockscreen password.

So if the phone has those prerequisites (unlocked, No-verify, TWRP), is there a difference between removing the ".key" files and the locksettings.db? I am not entirely sure what the different files contain, and don't seem to be able to find this information through Google, though I may just not be searching the right set of keywords.
 

Oki

Senior Member
Jul 6, 2006
1,009
1,858
0
East Coast
When you say "No-verify patch," are you talking about removing Google license verification from apps (via an app such as lucky-patcher for instance)? AFAIK that is on a per-app basis and wouldn't affect something like the lockscreen password.

So if the phone has those prerequisites (unlocked, No-verify, TWRP), is there a difference between removing the ".key" files and the locksettings.db? I am not entirely sure what the different files contain, and don't seem to be able to find this information through Google, though I may just not be searching the right set of keywords.
No-Verify is an additional security system implementend in the kernel. When No-Verify is active, it checks for the signature of the system partition. If the system was modified, then the system won't boot. This is why after unlocking the bootloader you have to apply No-Verify Patch or any package with the integrated patch such as SuperSU. As you can see, it has nothing to do with the app signature or the lockscreen at all.

The method presented in the OP is valid for most Android phones, and the only prerequisite is to have TWRP installed. It is safe and a lot more recommended than patching the system partition. Patching system or kernel should always be your last resort. usually deleting locksettings.db is enough, and it is a general method that works for almost any locking method.
 
Last edited: