7

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).

Questions
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:

  1. Does the twrp decrypt command output something else when decryption succeeds?
  2. Does successfully decrypting create a block device at /dev/block/dm-0, which I can probe for?
  3. Should I wait a few seconds after each attempt before probing for success?
  4. Is there some sort of hidden timeout (required to wait 30 seconds after attempt)?
  5. 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 /data/data and /sdcard directory seems to list encrypted file names.

  • Your doing something pointless... – Gadget Guru May 9 at 11:01
  • Wipe the DATA of the Lock Screen application and your done. – Gadget Guru May 9 at 11:01
  • @Zillinium sadly that doesn't work, it seems the encryption key for /data is protected by the passphrase. It worked back in the day, but not anymore. Correct me if I'm wrong. – Tim Visee May 9 at 11:18
  • 1
    Not sure actually... It sounds like part of the Oreo Forced Encryption... – Gadget Guru May 9 at 14:00
5

After a while I figured out what the problem was, with a freshly flashed phone. Here I'll be answering my own question.


  1. Does the twrp decrypt command output something else when decryption succeeds?

    Yes, it outputs something like:

    Attempting to decrypt data partition via command line.
    Data successfully decrypted
    Updating partition details...
    ...done
    
  2. Does successfully decrypting create a block device at /dev/block/dm-0, which I can probe for?

    No.

  3. Should I wait a few seconds after each attempt before probing for success?

    -

  4. Is there some sort of hidden timeout (required to wait 30 seconds after attempt)?

    Yes, very important! About 10 seconds. Consecutive attempts within that time frame fail with no warning whatsoever.

  5. Is there another method I can use to probe for success?

    -


So, consecutive attempts to invoke twrp decrypt must have at least 10 seconds between them or else they will fail. So, the only thing that was wrong with the developed tool, is that I didn't implement this timeout.

  • 1
    interesting workaround! did you successful decrypt your previous data? – alecxs May 9 at 21:16
  • Sadly, no. Because I had already been attempting for many hours I just wiped my phone, and tested the tool afterwards with a pattern I knew was right. That's when I discovered the timeout. If I'd known this before, I would have been able to decrypt the previous data, yes. – Tim Visee May 9 at 22:46

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.