In the course of a recent incident response engagement, I ran into a hard-to-track-down problem involving imaging a drive. I was using a forensically sound hardware ATA drive imager (the awesome DiskJockey Pro Forensic edition), and was attempting to make several copies of a 2.5" 250GB SATA Western Digital laptop drive that had a single Windows XP NTFS partition. The client had no similarly sized drives available, so our destination disks were brand new Western Digital Scorpio Blue 500GB 2.5" SATA drives. 250GB can be copied by the DiskJockey in under an hour, so we figured this was going to be a two or three hour process. Oh, how wrong we were...
So, I arrived on-site at the client's office, removed the source drive from the laptop, hooked everything up to the DiskJockey and hit start. Fifty minutes later our first copy was done. I switched in the second WD Scorpio Blue destination drive and hit start again. Fifty minutes later, our second copy was complete. With two copies in hand, we decided to plug one of the drives into an analysis laptop running Windows XP using a SATA-to-USB bridge and start poking around on the drive.
What happened next stunned us. Windows XP saw the new USB device, went through its process of enabling the device, and finally popped up the "your drive is ready for use" message. Except that the drive wasn't ready for use because it didn't show up in Windows Explorer!! We used the Safely Remove Hardware wizard to eject the device and replugged it into the computer. Still no 'E:' drive in Windows Explorer, but Microsoft Forefront was able to see an E: drive and begin an AV scan of it. Not believing what we were seeing, we opened up a command prompt, typed in 'e:' and, sure enough, there was the target drive. Within the command prompt we were able to traverse the drive and copy files using DOS commands. We even tried to trick Windows Explorer by typing "start ." in the root of the E: drive. That would normally bring up a Folder view of the E: drive. But Explorer just complained that there was no such path.
Puzzled, we plugged the drive into a Linux analysis laptop. Linux assigned the disk to the /dev/sdb device just like normal. 'fdisk -l /dev/sdb' showed the partition table just as expected. But trying 'mount -t ntfs /dev/sdb1 /mnt' failed with a message about no valid NTFS having been found. At this time, we plugged the second copy of the original disk into the DiskJockey as the source disk (so that the DiskJockey would act as a write-blocker), and, using the DiskJockey as a SATA-to-USB bridge, plugged it into the Linux laptop. Lo and behold, we were able to mount the /dev/sdb1 partition without an issue.
Thoroughly flummoxed at this point, we finally noticed a small box of text on the white label on the top of the drive indicating that the drive was an Advanced Format drive. Some quick Googling showed that these drives use 4096 byte (4kb) hardware sectors as opposed to the old standard of 512 bytes used for the last 30 years. Because of this new hardware sector size, there can be performance penalties for partitions that are not aligned on a 4kb boundary. Windows XP creates partitions that assume the 512 byte standard and that are misaligned (by a mere 512 bytes) for the new 4kb sectors. And, for some reason, Windows XP refuses to show such a misaligned partition in Windows Explorer.
But why were we able to see the drive while using the DiskJockey as a SATA-to-USB bridge, but not while using the other generic SATA-to-USB bridge? The answer: because the DiskJockey acts as a write-blocker, it is emulating a drive controller. The Linux machine was talking to this emulated drive controller, not the actual drive controller. And, as you might now be guessing, the drive controller emulated by the DiskJockey reports the disk as having 512 byte sectors!
The two odd results I took away from this episode:
- In Windows XP, Explorer and the Command Prompt access partitions differently, such that the Command Prompt will allow you to access a drive letter that Explorer thinks is bogus.
- Even if the md5sum of the source drive matches the destination drive up to the same LBA number, copying a 512 byte hardware sector drive to a 4kb hardware sector drive may prevent you from using the destination drive as if it were the source drive if the partitions are not aligned on a 4kb boundary.
Most new drives are now using the 4kb sector size. In short, you can image a 512 byte sector drive to a 4kb sector drive, and the image will be forensically accurate. But the disk will not behave the same!
So how do you tell if you are running into this problem? Run fdisk from Linux and you'll see the difference. Here is my source disk:
Disk /dev/sdb: 250.1 GB, 250059350016 bytes
255 heads, 63 sectors/track, 30401 cylinders, total 488397168 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x413d5878
Device Boot Start End Blocks Id System
/dev/sdb1 * 2048 488394751 244196352 7 HPFS/NTFS/exFAT
and now my target (Advanced Format) disk:
Disk /dev/sdb: 500.1 GB, 500107862016 bytes
255 heads, 63 sectors/track, 7600 cylinders, total 122096646 sectors
Units = sectors of 1 * 4096 = 4096 bytes
Sector size (logical/physical): 4096 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk identifier: 0x413d5878
Device Boot Start End Blocks Id System
/dev/sdb1 * 2048 488394751 1953570816 7 HPFS/NTFS/exFAT
You can see the latter has 4096 byte physical clusters (the part in bold text).