How to: Unlock the encryption of your /home if you don't know your lock code (Bruteforce)

I’m not sure if this is the proper category since there isn’t category for guides and howtos, but I’m sure the admins will move this if there is better category for this.

  1. I’m trusting you are using this only to only save data or fix software with permission from the owner of the device and not to do anything illegal!
  2. I don’t know much about cryptography or cryptanalysis by any means and I don’t hack things in my everyday life. Unless I really really have to and even then I suck at it.
  3. I’m writing this down so you don’t have to go through all the same pain I had to go through to figure all of this out (and save a ton of your time on the side).
  4. I’m also sure more skilled people will point out all the errors and possible shortcuts in this so remember check out the comments below for better practises.
  5. If you know your lock code, but managed to use all your unlock attempts to permanently lock your phone, use this trick instead of going through the rest of this guide: https://jolla.zendesk.com/hc/en-us/articles/360002996893#32

I had to learn all of this because of failed SFOS upgrade and I didn’t want to use the Factory Reset. I’m using Xperia 10 and it has had the encryption enabled since the day I flashed it with SFOS. The only thing was, I skipped the setting of the lock code and never set it later either. So when I had to get access to the /home to fix the failed upgrade, I had no idea what to use to unlock the encryption (just pressing Enter for empty password didn’t work).

To crack the encryption, I used software called hashcat (https://hashcat.net/hashcat/). On the hashcat website there are listed GPU Driver requirements, but you really don’t have to worry about downloading those, this will be fast even without those (assuming you didn’t go with maximum lenght lock code).

Because you are looking into bruteforcing the encryption, I assume your phone is in the state where you need to get your phone into Recovery Mode (How to: https://jolla.zendesk.com/hc/en-us/articles/360002996893) to be able to do anything.

From the Recovery Mode menu, choose either option 3) Shell or 5) Run sshd. If you choose option 3) you need SD-Card to move the file from the phone to the computer, but with option 5) you can use programs that can transfer files over SSH. If you chose option 5), SSH into the phone using any SSH client using the information shown in the telnet window.

In the recovery shell you need to take a snippet from the beginning of the encrypted partition containing the LUKS header information for hashcat to chew on. Using cryptsetup luksDump to dump just the header information might be enough, but I took more, because someone on the Internet said it works better if there is little bit more than just the header (and because it is in the Internet, it must be true :grinning: !):

dd if=/dev/sailfish/home of=extended-luks-header bs=1M count=5

This takes 5 MB piece from the start which is more than enough for our needs and is manageable size so you don’t run into any diskspace issues. I used the 5) Run sshd -option so I could use program called FileZilla to transfer the files off from the phone, but you can also for example mount SD-Card to the shell and use it to transfer the file.

I copied the extended-luks-header -file to the same directory with hashcat to save myself from having to play around with paths pointing to the header file. Next I created a Batch-file (hence the line with pause), but you can ommit this step and just use commandline of your choise (the example.dict -file was part of the hashcat download):

hashcat --hash-type 14600 --attack-mode 0 --outfile recovered_passphrase extended-luks-header example.dict
pause

And now wait for the hashcat to do the job (unless you had long lock code you probably won’t even have time to go get a coffee). The length of the lock code and the computing power of your GPU and CPU are the key factors on how long it takes to crack the encryption. If you know you have used long lock code, using proper GPU API like CUDA API will help a lot.

For me, in around 38 seconds with my not so powerful PC and without any CUDA API magic used, the program had ended and I opened the recovered_passphrase -file to find a single line:

extended-luks-header:00000

Congratulations, you now have your lock code!

And how to use it? Start your phone and unlock it of course. Or if you can’t boot your phone normally, for example like this (lock code is asked on the cryptsetup open -command):

cryptsetup open /dev/sailfish/home myHome
mount /dev/mapper/myHome /rootfs/home
chroot /rootfs

In hindsight using the dictionary attack isn’t the optimal way to crack this case, but it worked really fast anyway for lock code of this lenght.There are also options to limit what kind of and what lenght passwords hashcat tries to find and the lock code is all numbers and can be any length between 5 and 42, but I chose these (pretty generic) parameters because I hadn’t setup the lock code myself at all so I didn’t have any idea if it would follow these rules.

Hope this short guide saves someones phone from unneeded Factory Reset or reflash!

20 Likes

And that’s exactly why we repeatedly expressed our concern to Jolla over using the pin code directly as luks passphrase.
Not that I’m not happy that you could solve your problem, but you should not have been able to do that if we are talking about proper encryption instead of this toycryption implementation of Jolla.

8 Likes

avhakola said that a lock code was never set up on the concerning device.
The found lock code 00000 really looks like a default lock code (which is, in principle, known to all people trying to decrypt the partition)…

4 Likes

Well, you could try to set the code and see how long would it take to crack it. Sounds like not too long. In the reported case, 38 seconds. Maybe, it was the first code it tried - no idea regarding it. In this respect, would be great to test with non-trivial code.

4 Likes

It would be indeed interesting to see the time comparison between cracking 5 digit and 42 digit lock code if done with powerful PC and having hashcat properly trying only numeric 5-42 length passwords.

2 Likes

Unfortunately, nobody was teaching encryption in my Comp Sci degree.

So LUKS 1 is supposed to be 128 bit or 2^128 = ~10^38 (LUKS 2 = 2^256).

A five digit pin is a search space of 10^6 and an 8 digit is 10^9. So LUKS needs a 38 digit pin to properly be 128 bit?

And is ‘Data’ ordinarily readable on a sector by sector basis without the PIN?

Here is a short description on how LUKS works: https://askubuntu.com/a/805880

So yes, data is readable sector by sector without the PIN, but the data is “random garbage” without the master key. Normally it would be extremely difficult to brute-force guess the master key, but you can obtain the master key with the PIN (or any of the 8 passphrases if they are set). So the PIN is not directly used for encryption, but if you know that the PIN only contains digits and is maximum N long, then you can obtain the master key from 10^N guesses in the worst case, and by (10^N)/2 guesses on average.

6 Likes

So out of interest, I tried this on my own lockcode (which is more random and 6 digits long) using the following commands:

dd if=/dev/disk/by-id/dm-name-sailfish-home of=/home/defaultuser/hashcat.luks bs=512 count=4097

Then hashcat on my desktop:

hashcat -a 3 -m 14600 hashcat-xperia10.luks '?d?d?d?d?d?d'

(I.e. bruteforce luksheader with an input mask of 6 digits)

On my Linux desktop with a partially broken rocm install (so probably low performance), this took 6 minutes and 23 seconds:

hashcat-xperia10.luks:xxxxxx                                                                                                                       

Session..........: hashcat
Status...........: Cracked
Hash.Name........: LUKS
Hash.Target......: hashcat-xperia10.luks
Time.Started.....: Wed Sep 15 16:51:33 2021 (6 mins, 23 secs) 
Time.Estimated...: Wed Sep 15 16:57:56 2021 (0 secs)
Guess.Mask.......: ?d?d?d?d?d?d [6]
Guess.Queue......: 1/1 (100.00%) 
Speed.#1.........:     1044 H/s (1.96ms) @ Accel:128 Loops:32 Thr:64 Vec:1
Recovered........: 1/1 (100.00%) Digests
Progress.........: 400000/1000000 (40.00%) 
Rejected.........: 0/400000 (0.00%)
Restore.Point....: 0/100000 (0.00%) 
Restore.Sub.#1...: Salt:0 Amplifier:3-4 Iteration:1399936-1399966
Candidates.#1....: xxxxxx -> xxxxxx
Hardware.Mon.#1..: Temp: 76c Fan:  0% Core:1630MHz Mem: 945MHz Bus:16

                                                        
Started: Wed Sep 15 16:50:58 2021
Stopped: Wed Sep 15 16:57:57 2021

So yeah, it doesn’t take long.

8 Likes

Cool, now do it on a Sfos device :wink:

Nah, thank you. That would probably take 2 days or so and is not how an attacker would do it.

Jolla! We want alphanumeric lock codes! :face_with_monocle:

2 Likes

actually no, what we want is this:

The implementation is ready to be merged thanks to @rinigus

11 Likes

From my limited understanding, it only works if the attacker knows the ssh password. So as an attack scenario it is very limited. It only works if the attacker can keep the device for long enough (years) for vulnerabilities to be discovered in openssh. Or can someone correct me?

If I recall correctly, when you use Recovery Mode, you can use the Shell option without any credentials and the sshd option uses username and password from the recovery image (and these are known) instead of the phone’s Developer Mode password.

@moripeluka

No; ssh password has nothing to do with lock code. And the SSH password has no use if the phone is off.
The above clearly demonstrates that it takes mere minutes to brute-force a numerical lock code.

@avhakola

Pretty sure you have to give the lock code there too. Please try before claiming otherwise.
The security may be bad, but it is not a sham.

1 Like

The recovery should most definitely ask for the lock code if one was set beforehand, but I have no memory of such prompt, probably because I didn’t have lock code set at the time.

That would only be a minor inconvenience to an attacker and does not offer any real security, since you can simply boot a different recovery image, that does not ask for any code…

How do the supposed important Jolla customers (government, corporate) are expected to deal with this possible attack? Do they have access to expensive tools from Sony or Jolla to lock the bootloader?

The only sensible defense is to use a good lockcode (10 characters+ with an alphabet of at least 36)

1 Like

So i can be glad my daily used Sony XZ2 Compact with SFOS-Community-Port uses this:

Compared to the official encryption solution, this edition has way larger flexibility in LUKS passwords which has a major implication in the security. As it is, official encryption solution is vulnerable to brute force attack. Such attack can be rendered unfeasible using this community edition.

1 Like