DroidCrack:

Leveraging Android crypto to recover device unlock secrets

Description:

The Android full disk encryption subsystem reuses the screen-unlock secret, to protect the encryption key (with 2000 iterations of PBKDF2). It is the user's responsibility to choose a suitably strong password, to prevent a dictionary attack.

An offline attack against the encryption system is also possible, if the adversary can obtain an image of the device's encrypted storage. Physical storage acquisition techniques, such as JTAG and ``chip-off'', can be used to obtain such an image (see e.g., A. Hoog, Android Forensics [pp.266-284]). Logical acquisition techniques are possible on a rooted device, or perhaps by installing a custom recovery partition with root privileges.

The PBKDF2-protected volume key is contained in the encrypted volume's footer. A brute-force attack can be mounted to attempt to decrypt the volume key. When the correct screen-unlock secret is found, the resulting volume key will decrypt a valid filesystem.

The droidcrack tools were created to launch such a dictionary attack against an encrypted Android disk image. Running on a single core of a 3.4GHz Intel Core i7-2600, with Ubuntu 12.04 and the OpenSSL 1.0.0 library, it required 9 minutes and 2 seconds to test all 4 and 5 digit PINs (110,000 total).

Source Code:

droidcrack source code
MD5: 4eecddf1bdcc2593022487d316937c0c

Building:

Ensure you have the libssl-dev package installed

Run make to build all the tools

Usage:

Step 1: Construct the dictionary of candidate encryption keys from either PINs or a password file

$ mkdict <pin | pwd> <max_length | path_to_dictionary> <path_to_image>

Where:

<pin | pwd> chooses between PIN codes or a pre-created password dictionary file (e.g., from John the Ripper)
<max_len> is the maximum length to generate if PINs are being used
<path_to_dictionary> is the dictionary file if pwd is used
<path_to_image> is the location of the encrypted image

You will want to redirect stdout to a file for use in the next step. If you are creating keys from PINs, you must set the maximum length to generate (e.g., using max_length=5 will generate keys from all 4 and 5 digit PINs.

Step 2: Test the candidate keys against filesystem image

$ sudo dc <path_to_dictionary> <path_to_image>

Where:

<path_to_dictionary> is the location of the candidate key dictionary created in step 1
<path_to_image> is the location of the encrypted image

You will need root privileges, since dc uses the device-mapper and loopback block devices. If found, the correct device unlock secret (and associated disk encryption key) will be printed to the screen.

Step 3: Unlock the device or mount the image for forensic analysis

$ sudo cryptfsmount <passwd> <path_to_image> <mount_point> <pwd|key>

Where:

<pwd|key> chooses either password or key (keys are already PBKDF2 decrypted)
<passwd> is either the password or key as a string
<path_to_image> is the location of the encrypted image
<mount_point> is the path to which the image will be mounted

This will mount the image in a read-only state, and suppress meta-data changes (e.g., access-time).

Author:

Adam Skillen
CCSL - Carleton University
Homepage: https://www.ccsl.carleton.ca/~askillen/

Last Updated: 14-Jun-13