Yesterday I somehow forgot the Android security pattern on my phone. Due to muscle memory I sort of know what it was, but can't figure out the true pattern. Therefore I'm attempting to brute force it to allow me to unlock the phone again.
Decrypt with pattern
Since I've TWRP recovery installed, I'm able to use the
twrp decrypt 'passphrase' command for decryption attempts. I'm using a 4x4 pattern (OnePlus5, LineageOS, Android 8.1, TWRP clockworkx 3.2.3-1) for which each dot in the grid translates to a different character, you should concatenate to build your passphrase. I believe the 4x4 grid looks like this:
1 2 3 4 5 6 7 8 9 : ; < = > ? @
Having a line pattern from the top left to the bottom right would give a passphrase of
16;@, allowing you to decrypt your phone in TWRP using
adb shell twrp decrypt '16;@'. (via)
Brute force attempt
Through this method I've attempted all possible patterns I believe could be it, but I didn't succeed decrypting it. The command always returns
Attempting to decrypt data partition via command line. to
stdout, and nothing else. I'm rapidly attempting each pattern one after the other with no delay, detecting whether any command output differs from the expected output (which hasn't happened yet).
Because I didn't succeed yet, I'm wondering if my implementation is correct. I don't have a phone to test with, so I have a few questions:
- Does the
twrp decryptcommand output something else when decryption succeeds?
- Does successfully decrypting create a block device at
/dev/block/dm-0, which I can probe for?
- Should I wait a few seconds after each attempt before probing for success?
- Is there some sort of hidden timeout (required to wait 30 seconds after attempt)?
- Is there another method I can use to probe for success?
Brute force tool
I did build the following tool for this brute force attempt, if that's relevant for what implementation I've used: apbf
I don't understand what is wrong with this implementation. It does not seems to properly decrypt the phone, making me wonder if the key could be corrupted.
I'm currently rebooting recovery after reach attempt, but that takes a lot of time for 1400 possible patterns. I'd like to be sure the attempt isn't useless.
Since I do know the approximate pattern length, am certain only the two right columns are used, and know that the dots in the pattern never have a distance greater than 1, I can greatly reduce the pattern search space and limit the possibilities.
Encryption is enabled on the phone, I believe it's file-based. When in TWRP, the
/sdcard directory seems to list encrypted file names.