HowTo: Me dumb cow, set a pattern password, then immediately forgot it!

[j-autuick]

I am gonna share this information in the chance that it can help someone else in the future.

Background: I was very tired, and as I often do before I fall asleep, I will read web pages on my phone, up til the moment that my eyes fall shut. I was reading about security, and had the hankering at that moment, to set a “pattern screen login.” So, I went to Settings, Security, and “swigged and swagged” my fingers in a matching pattern two times in a row. A felt good, I can sleep now. 30 seconds later, I wanted to check ‘one last thing,’ but could not for the life of me figure out what I had used as a pattern. =(

I am patient, I tried about 40-50+ times, each failure, leading to LONG periods of waiting, before I could try again.

Finally, it shook me, what had just happened!

I got up, and had to resolve this issue. I have 2FA setup on half a dozen account, half of which are REQUIRED work accounts. I didn’t panic, but had to get to my computer.

Searching around and dabbling around a little, I found out the following issues:

1. The situation is serious - likely leading to most people hard resetting (losing all their data)
2. There are some solutions for people that may have a google account associated with their phone, and/or only in some situations – not sure it even applies for current version FP2 android.
3. I didn’t work out the probability for determining the code, simply because the “wait times getting longer per failure.” One minute per attempt was already like an eternity, so going through until found it was not really an option.

Here is what I did.

Preconditions:

1. I have a FP2, open source phone. It is rooted (by default).
2. I had “USB Debug mode” set on my phone, before I ‘lost control of it.’ I am not sure if this can be set, but maybe it can.
3. I have access to all operating systems, at home, and feel most comfortable with Debian. I have the android command line tools already installed, via this command:
   sudo apt-get install android-tools-adb android-tools-fastboot
4. I connected the mobile phone via a USB cable to the computer. I have experienced, that many cables are ONLY good for charging, and thus you need to ensure data can be transferred to the device. In my case, more than half of the USB cables I have in my house will allow full charging and data transfer – I am not enough of a hardware guru to answer how come. But, just be aware, that if your phone doesn’t show up, and you meet all the above conditions, check the cable.

Step-by-step:
I am not super familiar with the adb commands, but the exact sequence should suffice for the uninitiated (like me).

<connect phone, launch command line window/terminal>

1. verify that your device is connected:
   adb devices
   It should show up in a list if it is.

2. get “into the device”
   adb shell

3. So, now, you can move around (cd), copy files (cp), and move (mv) files, just like any other command line – but now you are within the phone.

4. navigate to the relevant folder.
   cd /data/system

5. In some guides, it says delete the file “gesture.key” But, that is an older version of android. But, I knew something similar had to exist. I finally found the information in another forum:
   https://forum.xda-developers.com/showthread.php?t=1800799&page=3

You will want to delete three files (from within the /data/system/ directory):
rm locksettings.db
rm locksettings.db-wal
rm locksettings.db-shm

I just renamed them (cp locksetting.db locksetting.db.bak, etc), but you can delete them.

6. Reboot your machine. Enjoy. The security screen should be gone.

Hopefully this helps someone.

[Roboe]

Is this tested? ADB shouldn’t work with the screen locked. IIRC they fixed that hole years ago (like in Android 4.x or so). But, anyway, files in the /data folder/partition are only readable (not writable, thus not deletable) without root access.

So I don’t really think this works at all.

[j-autuick]

Hi Roboe,

Tested? It was DONE! On my phone.

Note: Preconditions – device WAS already rooted.

I have the Fairphone Open 19.02.1 installed, which is rooted.

I agree with you though, outside of my specific use case, with these preconditions, it won’t work.

[Roboe]

Oh, since you didn’t mentioned Fairphone Open OS directly, I missed that bit.

As I said, ADB shouldn’t work with the screen locked. But it’s true it works. I tested it on my Lineage OS for microG 15.1 on two different devices, a Fairphone 2 and not a Fairphone. So this is a serious security flaw. In LOS it can be mitigated if you only allow root access for apps in Developer options (not both apps and ADB).

IMO Fairphone Open should have this configuration too, and both LOS and FPOpen should forbid ADB usage with the screen locked. Shit.

[TobiasF]

@Roboe

As I said, ADB shouldn’t work with the screen locked. But it’s true it works. […] So this is a serious security flaw.

Don’t you have a confirmation dialog when you connect your phone for the first time to your computer? So you can only access from “whitelisted” computers onto locked phones, not from any computer.

[BeMiGro]

I can’t tell for ADB, but at least for Apps I (additionally) need to enable (first time) root access by approving it on the phone; if that’s the case, the security issue would not be there with standard settings!?
I also checked my developer settings and wondered if nit only USB debugging, but also ADB need to be activated as a precondition? ADB per standard seems nit to be activated:

Unfortunately I can’t test it right now.

[Johannes]

First time connecting over ADB should pop up an authorisation dialogue. If you want to test whether that is broken, try the ‘Revoke USB debugging authorizations’ option shown in the screenshot above and then try to connect when the screen is locked - it shouldn’t connect anymore.

The correct prerequisites for removing locks from a system where an on-device login does not work should therefore be:

• ADB is enabled and
• Root access is enabled for ADB and
• The device you’re using to connect to the phone has previously been authorised.

If the same code is also used for encryption, and the device is off, I don’t see a way of booting the system far enough to do this. I’m also not sure what the effect is of removing the screen lock files on an encrypted system - the code may still be required for decryption when you reboot.

[j-autuick]

@Roboe

So this is a serious security flaw.

I agree. This did cross my mind. If I can unlock my phone, so could any other “dumb cow” with patience and an internet connection. I was able to do it in about an hour, and I was dumb enough to “snooker myself,” so yeah that’s not good.

This is the argument, by Google, to not “root” your device – security reasons. For me, it’s a trade off, I am willing to make.

@Johannes

The correct prerequisites for removing locks from a system where an on-device login does not work should therefore be:

• ADB is enabled and
• Root access is enabled for ADB and
• The device you’re using to connect to the phone has previously been authorised.

Yes, correct, I should have stated that more clearly. As I mentioned, I had never really used ADB before, other than once before when I was updating the system, to try to solve a malfunctioning screen. It’s actually pretty cool =)

@Johannes

If the same code is also used for encryption, and the device is off, I don’t see a way of booting the system far enough to do this. I’m also not sure what the effect is of removing the screen lock files on an encrypted system - the code may still be required for decryption when you reboot.

Interesting scenario. I don’t know.

[AnotherElk]

@Johannes

If the same code is also used for encryption, and the device is off, I don’t see a way of booting the system far enough to do this. I’m also not sure what the effect is of removing the screen lock files on an encrypted system - the code may still be required for decryption when you reboot.

If the solution to the problem is just deleting some files, this could be done using the TWRP recovery.

I don’t know if TWRP has a pattern input UI for decrypting data, but if in doubt, a pattern can also be given as a number, see at the end of this FAQ part … TWRP Commandline Guide.

[Johannes]

@AnotherElk

a pattern can also be given as a number

This works if you know what the pattern is - but as the procedure in the first post was designed to gain access when the pattern is forgotten…
I’m just wondering what the connection between the screen lock password/pattern and the device decryption password is. If you remove the files, do you also remove the password for the decryption key? I’m thinking mainly of FDE:

Android 5.0 and above supports full-disk encryption. Full-disk encryption uses a single key—protected with the user’s device password—to protect the whole of a device’s userdata partition. Upon boot, the user must provide their credentials before any part of the disk is accessible.

(Source). From the link in the quote:

When the user sets the PIN/pass or password on the device, only the 128-bit key is re-encrypted and stored.

This suggests that when removing the screen lock files, the encryption master key will still require the screen lock pattern. There’s probably a way to re-encrypt the key from the command line, if that doesn’t require the original key then this should be done immediately after (or before) the deletion of the lock screen files (in any case before the reboot!).

Now with file-based encryption, the whole thing gets more complex, but there’s still a password-protected encryption key (but now at user level). You’ll be able to boot to the lockscreen if direct boot is supported, but if you don’t know the user pattern you’ll not get access to the user’s data.

[RSpliet]

HowTo: Me dumb cow, set a pattern password, then immediately forgot it!

Just popped by to tell you that making mistakes don’t make you a dumb cow. Everyone messes up some times, but you decided not to accept defeat and instead gone off to show your ingenuity and channel your curiousity to solve the issue to the most satisfying outcome possible. And then the kind soul that you are went out to share your experience with others in case someone runs into the same pickle.
I’ve been taught not to judge people by their mistakes, but rather by how they deal with them. And I see a fine specimen in you. So don’t judge yourself a “dumb cow” by the mistake, but give yourself a massive pat on the back for having the kindness of sharing your lesson… you’ve earned it!

[Roboe]

@AnotherElk

using the TWRP recovery.

Ok, I knew someone would say this eventualy,

Encrypt your phone storage!
Since FP2 comes with an unlocked bootloader, anyone can flash TWRP preserving user data, and then delete those pattern files without the prerequisites of root and enabled ADB. Just encrypt it, shit!

[BeMiGro]

@Roboe

anyone can flash TWRP

Why not even use TWRP without flashing it?

[Roboe]

Yeah, sure. The point I was doing was that there’s a security hole with the unlocked-by-default FP2’s bootloader with a non-encrypted system.