256-Bit Based Hardware Encryption on WD MyBook Essential

Western Digital’s refreshed My Book Essential external hard drive provides a simple, secure, and inexpensive home backup solution. With an enormous 2TB capacity, built-in WD SmartWare software, 256-bit built-in encryption with user password protection, there is very little not to like here. But, imagine what would happen if the hardware of the device is broken? For example, the PCB board of the hard drive is damaged by a power surge. Can data recovery engineer retrieve any user data by any conventional techniques? A test is being carried out on two 320GB WD MyBook Essential external hard drives for research purpose.

Two drives are initialized by factory default setting and there are no user password being used. Use a hex editor to view the sector 0 and sector 1 from these two drives (as shown in the figure below respectively). Sector 0 is a Master Boot Record. Sector 1 contains a patterning data where it should be zero in a conventional hard drive. The patterning data are unique and different on two drives (as shown in the table below).

Drive A 0x E6 89 D2 0F D3 62 4C F8 3A 2E 7B B7 6A 7A FC BF

Drive B 0x 3A 73 9F 10 1A 47 97 F2 9A 31 BB E5 CC 8F 97 50

Assume that both PCB boards are now damaged by users and the drives are not spinning up anymore.

A compatible PCB is borrowed from a donor drive (as shown in the figure below).

Direct replacement of WD PCB is not going to work. The adaptive ROM content on the donor PCB needs to be recreated by ROM overlay modules on the platter. This can be achieved by firmware manipulation tool, which is not introduced here. The reason of using a SATA interface PCB instead of USB interface on a donor drive, it is because the firmware repair utilities don’t support USB interface for firmware manipulation. Once the ROM is regenerated and the PCB is attached to the failed hard drives, both hard drives are spinning up again and recognized by computer correctly.

Use a hex editor to view the same sectors again after replacing the PCB, sector 0 contains some data, which look like have been encrypted, and sector 1 contains zeros. Obviously, the contents are totally different to what they were seen before the PCB was swapped.

Based on the test above, the original PCB utilizes an encryption feature where the decryption key is unique to a hard drive. Even the sectors are become accessible through a donor PCB, the user files are still not recoverable without the original PCB being fixed. The patterning data stored at sector 1 and some following sectors where they should contain zeros are the key parameter to the decryption process. But there is only the WD knows the decryption algorithm until someone else is able to disclose it by reverse engineering. Bear in mind that, the patterning data will be unknown without the original PCB is working. So, to find out the key parameter, the controller chip and/or the firmware modules have to be looked at.

Written by: Zijian Xie (R&D Manager, MSc,BEng)

Deleted Microsoft SQL Database Recovery Case Study

The video will show how we use the File Defragmentation Technique (FDT) to retrieve a accidentally deleted Microsoft SQL database (SQL2000, SQL2005, SQL2008). A comparison on the recovery performance between conventional DR method and FDT will be given too.

（Keyword: Forensic MDF Recovery, SQL Recovery, SQL Deletion Recovery)

Windows Dynamic Disks (LDM)

VBLK is the most important parameter in the LDM database. The best way to examine it is to use 'dmdiag.ext' which can be downloaded from the Windows website. It helps us to recreate the logical disk structure. I created a group of dynamics disks under Windows, consists of two physical drives. Volumes are:

1. Spanned (purple);

2. Stripped (green);

3. Simple (yellow);

Run the 'dmdiag.exe', we have:

#Record 48: type=0x0034 flags=0x0000 gen_flags=0x0004 size=156 #Blocks: 14 15 Disk: Disk2 rid=0.1030 updated=0.1094 assoc: diskid=a5820739-c02a-4ed9-9b13-009f5a4ff6a0 lastdevice=IDE\DISKWDC_WD800BB-00CAA1______________________17.07W17\4457572D414D4538363336303834_030_0_0_0_0 flags:

#Record 55: type=0x0034 flags=0x0000 gen_flags=0x0004 size=156 #Blocks: 6 9 Disk: Disk1 rid=0.1027 updated=0.1103 assoc: diskid=aab20507-ea67-4952-ac74-82d1a6abb42a lastdevice=IDE\DISKMAXTOR_6Y080L0__________________________YAR41BW0\3259513133444535202020202020202020202020 flags:

#Record 36: type=0x0033 flags=0x0000 gen_flags=0x0004 size=51 #Blocks: 13 Subdisk: Disk1-01 rid=0.1076 updated=0.1077 info: disk=0.1027 offset=0 len=20480000 hidden=0 assoc: plex=0.1074 (column=0 offset=0) flags:

#Record 42: type=0x0033 flags=0x0000 gen_flags=0x0004 size=50 #Blocks: 16 Subdisk: Disk1-02 rid=0.1081 updated=0.1082 info: disk=0.1027 offset=20480000 len=10240000 hidden=0 assoc: plex=0.1074 (column=0 offset=20480000) flags:

#Record 51: type=0x0033 flags=0x0000 gen_flags=0x0004 size=51 #Blocks: 20 Subdisk: Disk1-03 rid=0.1091 updated=0.1094 info: disk=0.1027 offset=30720000 len=30720000 hidden=0 assoc: plex=0.1089 (column=0 offset=0) flags:

#Record 58: type=0x0033 flags=0x0000 gen_flags=0x0004 size=51 #Blocks: 22 Subdisk: Disk1-04 rid=0.1102 updated=0.1103 info: disk=0.1027 offset=61440000 len=98635377 hidden=0 assoc: plex=0.1100 (column=0 offset=0)

#Record 46: type=0x0033 flags=0x0000 gen_flags=0x0004 size=51 #Blocks: 17 Subdisk: Disk2-01 rid=0.1084 updated=0.1085 info: disk=0.1030 offset=0 len=20480000 hidden=0 assoc: plex=0.1074 (column=0 offset=30720000) flags:

#Record 52: type=0x0833 flags=0x0000 gen_flags=0x0004 size=53 #Blocks: 21 Subdisk: Disk2-02 rid=0.1093 updated=0.1094 info: disk=0.1030 offset=20480000 len=30720000 hidden=0 assoc: plex=0.1089 (column=1 offset=0) flags:

#Record 45: type=0x0032 flags=0x0000 gen_flags=0x0004 size=48 #Blocks: 12 Plex: Volume1-01 rid=0.1074 update=0.1085 type: layout=CONCAT state: state=ACTIVE assoc: vol=0.1072 flags:

#Record 50: type=0x1032 flags=0x0000 gen_flags=0x0004 size=52 #Blocks: 19 Plex: Stripe1-01 rid=0.1089 update=0.1094 type: layout=STRIPE columns=2 width=128 state: state=ACTIVE assoc: vol=0.1087 flags:

#Record 57: type=0x0032 flags=0x0000 gen_flags=0x0004 size=48 #Blocks: 18 Plex: Volume2-01 rid=0.1100 update=0.1103 type: layout=CONCAT state: state=ACTIVE assoc: vol=0.1098 flags:

#Record 44: type=0x0251 flags=0x0000 gen_flags=0x0004 size=84 #Blocks: 10 Volume: Volume1 rid=0.1072 update=0.1085 mountname=E: info: len=51200000 guid=9546148a-73bd-491a-8ba2-2e6e87c303a0 type: parttype=6 usetype=gen state: state=ACTIVE policies: read=SELECT flags: writeback

#Record 60: type=0x0251 flags=0x0000 gen_flags=0x0004 size=84 #Blocks: 8 Volume: Volume2 rid=0.1098 update=0.1105 mountname=G: info: len=98635377 guid=6f913350-77b3-4bed-99d6-96ef6da8cf2d type: parttype=6 usetype=gen state: state=ACTIVE policies: read=SELECT flags: writeback

#Record 54: type=0x0251 flags=0x0000 gen_flags=0x0004 size=84 #Blocks: 7 Volume: Stripe1 rid=0.1087 update=0.1096 mountname=F: info: len=61440000 guid=9f16eb7d-1f88-4405-aede-3928d2859cb3 type: parttype=6 usetype=gen state: state=ACTIVE policies: read=SELECT flags: writeback

According to the information displayed above, the four layers Windows LDM structure can be recreated as:

Based on the this four-layered LDM structure, volumes can be recreated virtually using data recovery software.

RAID5 Parity Detection

Today I am going to show you a new algorithm we just implemented to detect the parity location on each member drive of a RAID5.

It doesn't reply on the file system of the RAID5. It can be used for Windows RAIDs, Linux RAIDs, MAC RAIDs and UNIX RAIDs. Even though the algorithm is not giving you a complete RAID configuration, the result generated by the application will indicate the strip size and the drives' sequence. The drives' sequence is different to drives' order. For example, a RAID5 has a drives' sequence of 3-2-0-1, the drives' order can be 2-0-1-3, 0-1-3-2, 1-0-2-3, etc. It depends on which drive is the first drive and the rotation direction of the RAID5.

The example given in the video is a 4-disks Windows RAID5. According to the result, we worked out the strip size is 256 sectors and the drives' sequence is 4-3-2-1.

This algorithm becomes extremely useful to work out the RAID configuration (strip size, drives' order, header size and rotation direction)when dealing with a RAID5 created by an unknown or a strange file system. We will discuss this further on our blog in the near future.

(Designed by Zijian Xie, R&D Manager, MSc, BEng)

Data Structure of Non-Standard Sector

Today, details in identification of a non-standard sectored device will be introduced.

In conventional storage systems, they are normally using a standard 512Byte sector unit to store user data. In order to achieve a lower BER (Bit Error Rate), addition CRC checksum is added after each 512Byte user data in high level storage systems. These addition bytes will ONLY be recognized by its RAID controller where the storage media is operating with. The RAID controller will eliminate the addition bytes before it passes the raw data to the operating system (Windows OS/Linux/etc.) from a non-standard sectored storage media. In another word, device users will not be able to tell if a non-standard sector scheme has been used or not in their systems. So as for data recovery companies, file systems will not be recognized by any recovery application if the hard drives from a non-standard sectored RAID controller are raw mounted under aliened computer.

As the figure shown below, 8 byte CRC checksum are attached to the end of each 512 byte user data, which results in data shifting after the sector 0. The DBR (DOS Boot Record) of NTFS file system (as content show beginning with “EB 52 90”) will be shifted to address offset 8 (as shown on the right in this example) instead of offset 0 where it is supposed to be (as shown on the left). As you can imagine, all the remaining content will be shifted accordingly. The shifting cycle is 64 times (=512/8). It means that you will see a standard sector of data without shifting every 64 blocks of 520 sectors.

Written by: Zijian Xie (R&D Manager, BEng, MSc)

Winhex Template for Compound Document File Header

I created a Winhex template for the Compound Document File header. Used the repaired Excel spreadsheet in the last article as an example, the template will look like:

Written by: Zijian Xie (R&D Manager, BEng, MSc)

Microsoft Excel Document Repair

Having read the paper of ‘MS Compound Document File Format’ again, I created a sector map to demonstrate the parameters in the file header.

The green and blue parameters are the standard values. They are generic values except the revision number and the version number (which are normally not important at all). The red and yellow parameters are the critical ones which are used to construct the actual content in a spreadsheet.

• SAT Size (sec) : The number of sectors that used by the Sector Allocation Table (SAT).

• First SecID of DIR : The SecID of the first sector that stores the Directory table (DIR).

• First SecID of SSAT : The SecID of the first sector that stores the Short Sector Allocation Table (SSAT).

• Size of SSAT(sec) : The number of sectors that used by the SSAT.

• First SecID of MSAT : The SecID of the first sector that stores the Master Sector Allocation Table (MSAT).

• Size of MSAT : The number of sectors that used by the MSAT.

• SecIDs of MSAT : The SecID chain that stores all the SecIDs used by the MSAT.

Only the first 109 SecIDs of MSAT will be stored in the sector of file header. It will be padded by ‘0xFFFF’ if it has less than 109 SecIDs.

(Note: If you need more explanations, please refer to http://sc.openoffice.org/compdocfileformat.pdf) )

Based on the concepts above, I am trying to repair a corrupted spreadsheet document manually, instead of using repair software. Open the file, it shows the content are corrupted:

Use Winhex to view the file (beginning), it shows:

Not saying the rest of the file, it is quite obvious that the file header (Page 1) is damage completely. As we know, the standard sector size of OLE2 document is 512 bytes. We can interpret the file as a hard disk, which makes it easier to examine the data structure. In Winhex, this file starts from sector 0 to sector 2327. This sector number is different to ‘SecID’ described in OLE2 document specification. They have a relationship as the table below:

OLE2	Header	SecID 0	SecID 1	Sec 2	SecID 3	…	SecID N
Physical	Sector 0	Sector 1	Sector 2	Sector 3	Sector 4	…	SecID N+1

To repair the sector 0 (Header), we can copy the content of sector 0 from a working .xls file to replace the current damage one. This action will repair the standard values. Obviously, the critical parameters mentioned above need to be adjusted or recalculated. Thus, the places where need changing are:

1. SAT Size (sec) : offset 0x2C to 0x2F

2. First SecID of DIR : offset 0x30 to 0x33

3. First SecID of SSAT : offset 0x3C to 0x3F

4. Size of SSAT(sec) : offset 0x40 to 0x43

5. First SecID of MSAT : offset 0x44 to 0x47

6. Size of MSAT : offset 0x48 to 0x4B

7. SecIDs of MSAT : offset 0x4C to 0x1FF

If the file size is not bigger than 6.8MB, the content of place 5 and place 6 do not need changed. This is because 109 double words pointers will be enough to store the whole SAT. Place 5 will be ‘0xFEFFFFFF’ (-2) and place 6 will be ‘0x00000000’.

Let’s start to repair the critical parameters by finding the SAT first. SAT is very similar to FAT tables in FAT32 file system. It contains a multiple chains of sector pointers. Also, this is usually stored at the beginning area. Looking at sector 1, this is a sector used by the SAT obviously. The first double word of ‘0xFDFFFFFF’ indicates the current sector is used to store the SAT. There are another two ‘0xFDFFFFFF’ at this sector, which indicate SecID5 and SecID6 are also used by SAT.

At SecID6 (sector 7), we found another two pointers have a value of ‘0xFDFFFFFF’. They are SecID 308 and SecID 309 respectively.

After a continuous searching, the SecIDs used by SAT are

SecID	Physical Sector
0	1
5	6
6	7
308	309
309	310
613	614
614	615
615	616
917	918
918	919
1221	1222
1222	1223
1524	1525
1525	1526
1526	1527
1830	1831
1831	1832
2164	2165
2187	2188

There are 19 sectors used by the SAT. Thus, Size of SAT and First SecID of SAT can be modified to:

Size of SAT = 19 (0x13000000)

First SecID of SAT = 0x00000000

Also, the field of SecIDs of SAT can be changed according to the table above. There are less than 109 SecIDs being used by SAT, thus:

First SecID of MSAT = 0xFEFFFFFF

Size of MSAT = 0x00000000

Directory table is always started with ‘ROOT ENTRY’. We search for a string of ‘ROOT ENTRY’ in UNICODE, and found sector 2 is used to store the DIR. Thus the First SecID of DIR is 0x01000000.

Regarding the SSAT, it will have a similar data structure as the SAT. But normally, it will have a shorter size in the length of the table. Checking through the first few sectors of the file, I found sector 3 should be the first sector of SSAT.

Thus, the First SecID of SSAT is 0x02000000. To check the next SecID from the SAT, we found a value of 0xFEFFFFFF at the offset of SecID 2, which indicates that the current SecID is the end of the current SID chain. In another word, the Size of SSAT is just a single sector, which has a value of 0x01000000.

To replace the recalculated values in the file header, it will look like this:

Try to open the file and it is readable now.

After manually recovered the file, I was interested to see if the recovery software can do anything or not. I tried a demo version of Excel Recovery software. Finally, the preview shows nothing apart from the sheet names.

Written by: Zijian Xie (R&D Manager, BEng, MSc)