Decrypting Android Full Disk Encryption

This document was written to provide some methods around decrypting Android Full Disk Encryption. The document assumes that you do not have adb, nor root access to the phone, rather, that you are trying to decrypt a file system which was retrieved by getting a physical dump from the phone (via a physical acquisition, JTAG, chip-off, etc).

Decrypting LG and other Android Full Disk Encryption (FDE)

oclHashcat includes support for decrypting PBKDF2-HMAC-SHA1 + CBC-ESSIV-AES encyption using brute force. The current version at the time of this writing is oclHashcat v1.3.0 which includes GPU accelerated 4-digit PIN brute forcing. See:

https://hashcat.net/hashcat/

Decrypting Samsung Full Disk Encryption (FDE)

At the time of this writing, Samsung "does things different" than other Android vendors. This may change with later releases of the Android OS releases. For specifics on how Samsung does things different, see the DerbyCon 2013 talk given by LÃ¡szlÃ³ TÃ³th and Ferenc Spala which covers the technical details. Without their research and effort this document would not be possible!

The process for decrypting Samsung FDE is as follows:

Acquire a physical acquisition of the device (not covered within the scope of this document).
Extract the encryption key from the device image.
Convert the encryption key to John The Ripper format.
Brute force the John The Ripper format encrpytion key using a dictionary.

Getting Started

You will need the following tools before you get started:

Linux (Debian GNU/Linux jessie was used in this case)
Sandy source code (https://github.com/donctl/sandy)
John the Ripper jumbo community-edition source code (http://www.openwall.com/john/)
Python 2.7 (https://www.python.org/downloads/)

Optional:

crunch (https://sourceforge.net/projects/crunch-wordlist/)

Locating the Encryption Key

Depending on the model of phone and Android version on the device, the location of the password key (or password footer as it's referred to in some cases) varies. According to the research by TÃ³th and Spala, in some versions of Android the key is located in the last 16K of the encrypted userdata partition. In other Android versions the key is located in /efs/metadata. For these cases, their 'sandy' framework can locate your key quite effectively.

In the case of the testing below, the phone was a Samsung SII SGH-T989D running Android 4.1.2 (with an encryption passphrase of 'test123'). The key in this case was not located in the userdata partition nor /efs/metadata so we manually searched for the ASCII string 'aes-cbc-essiv:sha256' using grep (or the tool of your choice) to locate it. The 'DumpData.bin' is a single 16GB raw image which was acquired from the device.

dk@anubis:~/Samsung_SII_SGHT989D$ strings -t d DumpData.bin | grep aes-cbc-essiv:sha256 402653220 aes-cbc-essiv:sha256 663743397 aes-cbc-essiv:sha256

Let's check the first hit, is that the key? It is! You can tell as the key area we need starts with 0xC5B1B5D0, contains some "whitespace", then the 'aes-cbc-essiv:sha256', followed by more "whitespace", and finally the encryption key or encrypted footer which starts with 0xF1DA84CF in our case and is 80 bytes in length. Ultimately, these 80 bytes are all that we want to extract and brute force with JtR. If you want to skip ahead slightly, at this point you could select those 80 hex bytes, save them to a file in JtF format, and start brute forcing with JtR. These steps are covered in more detail below.

Note: The starting 0xC5B1B5D0 bytes were noted to vary slightly between different Android dumps however the variations were minor. Just note that a search for '0xC5B1B5D0' will not always work hence why we search for 'aes-cbc-essiv:sha256'.

In this example we are using 'dd' to extract 512 bytes around the area where our ASCII string was located. In order to show the entire match including the 0xC5B1B5D0 starting point, I am skipping back 36 bytes before the ASCII string hit. 36 is an arbitrary number which is enough in this case to show the starting 0xC5B1B5D0 which is indicative of the start of the area which contains the encryption key.

dk@anubis:~/Samsung_SII_SGHT989D$ dd bs=1 skip=$((402653220-36)) count=512 if=DumpData.bin | hexdump -C 00000000 c5 b1 b5 d0 01 00 00 00 d8 00 00 00 00 00 00 00 |................| 00000010 20 00 00 00 00 00 00 00 00 10 40 00 00 00 00 00 | .........@.....| 00000020 00 00 00 00 61 65 73 2d 63 62 63 2d 65 73 73 69 |....aes-cbc-essi| 00000030 76 3a 73 68 61 32 35 36 00 00 00 00 00 00 00 00 |v:sha256........| 00000040 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| * 00000060 00 00 00 00 b1 e4 01 10 02 00 00 00 00 00 00 00 |................| 00000070 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000080 00 00 00 00 f1 da 84 cf 0f 82 30 b9 a7 bc 16 d4 |..........0.....| 00000090 bc ed 22 20 43 6d 7c b7 50 aa a3 f2 6f 41 d3 28 |.." Cm|.P...oA.(| 000000a0 48 cc 63 0d 10 30 ae 35 b6 e3 73 b2 5c 1c 61 dd |H.c..0.5..s.\.a.| 000000b0 34 80 07 89 67 34 2e 47 23 68 20 ac df cf 41 3a |4...g4.G#h ...A:| 000000c0 10 0c 2d f4 18 9e 50 a0 47 09 ca 5c 90 1d 42 84 |..-...P.G..\..B.| 000000d0 8a 48 62 7c 00 00 00 00 00 00 00 00 00 00 00 00 |.Hb|............| 000000e0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| * 00000200 512+0 records in 512+0 records out 512 bytes (512 B) copied, 0.00276768 s, 185 kB/s

For fun, let's check the second hit from our previous strings + grep search. You can see that this is not the key as expected so we can ignore this hit.

Now, using the forensic tool of your choice, extract 16384 bytes starting from the 0xC5B1B5D0 hex and save that out as a new file. You don't necessarily need to take all 16384 bytes but for the purpose of this document, let's take 16384 bytes as that number emulates pulling out the last 16K of the encrypted userdata partition.

dk@anubis:~/Samsung_SII_SGHT989D$ dd bs=1 skip=$((402653220-36)) count=16384 if=DumpData.bin of=encryption_footer 16384+0 records in 16384+0 records out 16384 bytes (16 kB) copied, 0.0167546 s, 978 kB/s

Your extracted chunk containing the encryption key should look as follows:

dk@anubis:~/Samsung_SII_SGHT989D$ hexdump -C encryption_footer 00000000 c5 b1 b5 d0 01 00 00 00 d8 00 00 00 00 00 00 00 |................| 00000010 20 00 00 00 00 00 00 00 00 10 40 00 00 00 00 00 | .........@.....| 00000020 00 00 00 00 61 65 73 2d 63 62 63 2d 65 73 73 69 |....aes-cbc-essi| 00000030 76 3a 73 68 61 32 35 36 00 00 00 00 00 00 00 00 |v:sha256........| 00000040 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| * 00000060 00 00 00 00 b1 e4 01 10 02 00 00 00 00 00 00 00 |................| 00000070 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000080 00 00 00 00 f1 da 84 cf 0f 82 30 b9 a7 bc 16 d4 |..........0.....| 00000090 bc ed 22 20 43 6d 7c b7 50 aa a3 f2 6f 41 d3 28 |.." Cm|.P...oA.(| 000000a0 48 cc 63 0d 10 30 ae 35 b6 e3 73 b2 5c 1c 61 dd |H.c..0.5..s.\.a.| 000000b0 34 80 07 89 67 34 2e 47 23 68 20 ac df cf 41 3a |4...g4.G#h ...A:| 000000c0 10 0c 2d f4 18 9e 50 a0 47 09 ca 5c 90 1d 42 84 |..-...P.G..\..B.| 000000d0 8a 48 62 7c 00 00 00 00 00 00 00 00 00 00 00 00 |.Hb|............| 000000e0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| * 00001000 4b 44 4f 00 00 00 00 00 00 00 00 00 00 00 00 00 |KDO.............| 00001010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| * 00004000

Finally, let's further extract just the encryption key and save it out in JtR format. This can either be done with the Sandy framework, a hex editor, dd, xxd, etc. Let's do it with xxd in this case. Note: We are seeking 132 bytes (jumping 132 bytes) into our file for the purpose that we want to grab the 80 bytes starting at 0xF1DA84CF. You can do this manually using the forensic tool of your choice as well. Just make sure you save those 80 bytes to a flat text file like the file we create below.

dk@anubis:~/Samsung_SII_SGHT989D$ xxd -seek 132 -len 80 -c 128 -p encryption_footer f1da84cf0f8230b9a7bc16d4bced2220436d7cb750aaa3f26f41d32848cc630d1030ae35b6e373b25c1c61dd3480078967342e47236820acdfcf413a100c2df4189e50a04709ca5c901d42848a48627c

You can see we have extracted just the key. Let's repeat that and write it out to a file.

dk@anubis:~/Samsung_SII_SGHT989D$ xxd -seek 132 -len 80 -c 128 -p encryption_footer > encryption_footer.jtr dk@anubis:~/Samsung_SII_SGHT989D$ cat encryption_footer.jtr f1da84cf0f8230b9a7bc16d4bced2220436d7cb750aaa3f26f41d32848cc630d1030ae35b6e373b25c1c61dd3480078967342e47236820acdfcf413a100c2df4189e50a04709ca5c901d42848a48627c

That's it! This .jtr file will later be fed into JtR for our brute force attempt.

Installing Sandy

Installing Sandy involves cloning the 'sandy' repository from github. After cloning the repository you will have a 'sandy' directory which contains the Python application.

dk@anubis:/sc/git-ext$ git clone https://github.com/donctl/sandy Cloning into 'sandy'... remote: Counting objects: 95, done. remote: Total 95 (delta 0), reused 0 (delta 0) Unpacking objects: 100% (95/95), done. Checking connectivity... done.

On supported devices, 'sandy' can be used to extract the encrypted key and convert it to JtR format however as noted previously this did not work in our case. If you are interested in playing with 'sandy', you can start it as follows:

dk@anubis:/sc/git-ext$ cd sandy dk@anubis:~/sc/git-ext/sandy$ python main.py -p sandy

Compiling John The Ripper (JtR) Jumbo with the sandcrypt plugin

Start by exploding your JtR jumbo source code and copying the sandcrypt plugin (from the 'sandy' installation) into the 'src' tree of JtR. After that you can start your compilation:

dk@anubis:~/src$ tar -zxf john-1.7.9-jumbo-7.tar.gz dk@anubis:~/src$ cd john-1.7.9-jumbo-7/src/ dk@anubis:~/src/john-1.7.9-jumbo-7/src$ cp ~/sc/git-ext/sandy/jtr_plugin/sandcrypt_fmt_plug.c . dk@anubis:~/src/john-1.7.9-jumbo-7/src$ make linux-x86-64-native

Note: If you receive an error about '\<openssl/HMAC.h>' when JtR is compiling 'sandcrypt_fmt_plug.c', please ensure you have pulled the latest version of 'sandy' from github. An issue previously existed which was corrected in the latest revision.

Brute forcing the Samsung Android FDE

The first thing you will need is a wordlist file. For the purpose of this document, my sample wordlist file is as follows. If you would like to generate a wordlist you can use the tool of your choice or use 'crunch' which is optionally included at the bottom of this document. When generating your wordlist please keep in mind that Samsung FDE specifically requires 6 characters including 1 digit. Note: The wordlist is likely the most important part of the decryption and should be crafted with care.

dk@anubis:~/Samsung_SII_SGHT989D$ cat wordlist.txt this5215 is23123 a000000 test10101 test123 test321 test2test bleck2bleck end2end

Once the compilation of 'john' has completed you can change into the 'run' directory which is where the 'john' binary is located. Now you can run 'john', provide it your wordlist, the sandcrypt plugin, and the Samsung FDE .jtr you created earlier.

dk@anubis:~/src/john-1.7.9-jumbo-7/run$ ./john --wordlist=/home/dk/Samsung_SII_SGHT989D/wordlist.txt --format=sandcrypt /home/dk/Samsung_SII_SGHT989D/encryption_footer.jtr Loaded 1 password hash (Samsung phone encryption [32/64]) test123 (?) guesses: 1 time: 0:00:00:00 DONE (Mon Sep 22 14:23:52 2014) c/s: 71.42 trying: test123 Use the "--show" option to display all of the cracked passwords reliably

Success! JtR identified 'test123' as the decryption password.

Note: If you run 'john' a second time you will notice that it doesn't crack any passwords! The reason being is that 'john' is smart enough to keep track of passwords it has already processed and it stores these in a 'john.pot' file. If you delete the 'john.pot' file then 'john' will reattempt cracking the passwords again.

dk@anubis:~/src/john-1.7.9-jumbo-7/run$ ./john --wordlist=/home/dk/Samsung_SII_SGHT989D/wordlist.txt --format=sandcrypt /home/dk/Samsung_SII_SGHT989D/encryption_footer.jtr Loaded 1 password hash (Samsung phone encryption [32/64]) No password hashes left to crack (see FAQ) dk@anubis:~/src/john-1.7.9-jumbo-7/run$ cat john.pot f1da84cf0f8230b9a7bc16d4bced2220436d7cb750aaa3f26f41d32848cc630d1030ae35b6e373b25c1c61dd3480078967342e47236820acdfcf413a100c2df4189e50a04709ca5c901d42848a48627c:test123 dk@anubis:~/src/john-1.7.9-jumbo-7/run$ rm john.pot dk@anubis:~/src/john-1.7.9-jumbo-7/run$ ./john --wordlist=/home/dk/Samsung_SII_SGHT989D/wordlist.txt --format=sandcrypt /home/dk/Samsung_SII_SGHT989D/encryption_footer.jtr Loaded 1 password hash (Samsung phone encryption [32/64]) test123 (?) guesses: 1 time: 0:00:00:00 DONE (Tue Sep 23 13:39:45 2014) c/s: 83.33 trying: test123 Use the "--show" option to display all of the cracked passwords reliably

Optional: Wordlist generation

You can use 'crunch' to generate a '6 character including 1 digit' wordlist or bigger wordlist. Start by extracting the crunch source code and compiling it as follows:

dk@anubis:~/src$ tar -zxf crunch-3.6.tgz dk@anubis:~/src$ cd crunch-3.6/ dk@anubis:~/src/crunch-3.6$ make Building binary... /usr/bin/gcc -pthread -Wall -pedantic -std=c99 crunch.c -lm -o crunch

Now, as an example, let's generate a wordlist that is 6 -> 8 characters in length which is just comprised of digits.

dk@anubis:~/src/crunch-3.6$ ./crunch 6 8 -f charset.lst numeric -o wordlist.txt Crunch will now generate the following amount of data: 987000000 bytes 941 MB 0 GB 0 TB 0 PB Crunch will now generate the following number of lines: 111000000 `crunch: 22% completed generating output` crunch: 43% completed generating output `crunch: 65% completed generating output` crunch: 86% completed generating output `crunch: 100% completed generating output`

Here is what our wordlist.txt looks like:

dk@anubis:~/src/crunch-3.6$ head wordlist.txt 000000 000001 000002 000003 000004 000005 000006 000007 000008 000009

You can now use this wordlist for your JtR attempt to crack the FDE.