« previous 1 2 3 4 next »

Tracking down test data

The fdisk -l command once again displays information about the current partitioning:

  Device  Boot	   Start	End	blocks	 Id  System
/dev/sda1		1	30400	244187968+   c	W95 FAT32 (LBA)
...
/dev/sdb1		1	30400	244187968+   c	W95 FAT32 (LBA)

So now we have two identical virtual hard disks with a Windows file system of 244187968 blocks each. The first block on the disk is the master boot record (MBR). The hexdump shows:

# dd if=/dev/sdb bs=1K count=1 | hexdump -C

00000000  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
000001b0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 01  |................|
000001c0  01 00 0c fe ff ff 3f 00  00 00 81 06 1c 1d 00 00  |......?.........|
000001d0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
000001f0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 55 aa  |..............U.|
00000200  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000400

Typical for an MBR without boot code: The large number of zeros, the partition table at offset 0x1be (in this case containing a single primary partition), and the two magic bytes 55 aa at 0x1fe.

To generate some data for testing, we fill a few blocks above block number 1000 with "cttestcttestcttest...":

# dd if=cttest.txt of=/dev/sdb bs=1K seek=1000

Now we need to find the encrypted partition on the physical medium. For this purpose, we remove the hard disk drive from the Raidon enclosure and connect it via SATA. It is likely that the data we're looking for is located behind the unencrypted part. We therefore start our read-out directly after the first partition. The compressed hexdump view shrinks any empty sectors, which conveniently highlights the ones that contain data:

# dd if=/dev/sda bs=1K skip=244187968 count=1M | hexdump -C

00000000  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
004adbb0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 80 00  |................|
004adbc0  00 80 7e 0b b5 37 bf 7a  00 00 05 93 8e 0e 00 00  |..~..7.z........|
004adbd0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
004adbf0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 76 49  |..............vI|
004adc00  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*

Success! The structure of the first data sequence we detect is identical to that of the MBR we're looking for. Its location, 0x4adbbe, also matches up, because it corresponds to 4790.5 empty blocks plus offset 0x1be; the same applies to the two magic bytes. But this would mean that the controller encrypts zero bytes to zero bytes! The structural similarities could, of course, be coincidental. If this was in fact our MBR, block 244193758 (244187968 + 4790 + 1000) would contain the encrypted version of our cttest block.

And sure enough:

# dd if=/dev/sda bs=1K skip=244193757 count=1K | hexdump -C

00000000  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000400  5c f0 d8 5c 5c f4 4c b3  d8 5c 5c f4 5c f0 de 12  |\..\\.L..\\.\...|
00000410  5c f4 5c f0 d8 5c 5c b3  5c f0 d8 5c 5c f4 4c b3  |\.\..\\.\..\\.L.|
00000420  d8 5c 5c f4 5c f0 de 12  5c f4 5c f0 d8 5c 5c b3  |.\\.\...\.\..\\.|
00000430  5c f0 d8 5c 5c f4 4c b3  d8 5c 5c f4 5c f0 de 12  |\..\\.L..\\.\...|
00000440  5c f4 5c f0 d8 5c 5c b3  5c f0 d8 5c 5c f4 4c b3  |\.\..\\.\..\\.L.|
00000450  d8 5c 5c f4 5c f0 de 12  5c f4 5c f0 d8 5c 5c b3  |.\\.\...\.\..\\.|
...

Behind the zero block 1000, block 1001, relative to the potential MBR candidate, contains a load of highly structured data with very little apparent random content. This is another sure sign of shoddy encryption. The data sequence 5c f0 d8 5c ... repeats every 24 bytes. Let's compare this to the plain text original:

00000000  63 74 74 65 73 74 63 74  74 65 73 74 63 74 74 65  |cttestcttestctte|
00000010  73 74 63 74 74 65 73 74  63 74 74 65 73 74 63 74  |stcttestcttestct|
00000020  74 65 73 74 63 74 74 65  73 74 63 74 74 65 73 74  |testcttestcttest|
...

Block 244187968 is indeed the encrypted MBR of the protected disk, and the encryption is indeed mapping zeroes to zeroes. However, if an encryption mechanism turns zeros into zeros, it isn't worth a penny and can probably be cracked in no time.

Next: Analysing the encryption

« previous 1 2 3 4 next »