A couple days ago my officemate had a computer blow up. The typical "oh I smell the ozone" sort of power supply death syndrome. No big deal, he's a good computer guy, yank the hard drives out, throw them into external enclosures, and bring them up on another machine to grab the desired data.
Unfortunately, the disk with the work data on it decided that it didn't like this tactic at all, and said no to mounting. He worked at it a little bit, and then handed it to me.
Now I'm sure all of you have been handed a reasonably big disk to deal with forensically, you copy the disk so you can work on a copy of the copy and have a copy to copy to start work on again when you totally bork the situation and want to start over from scratch (which is why you copy from the original to start off with, and why did you copy the copy? Cause an external Firewire or USB 2.0 isn't going to be as fast as an internal disk-to-disk copy of that same 200+GB.)
Hit it up with the usual tools, mmls to show me what the partition table looked like in the file, then fdisk to go in and look at it again:
The number of cylinders for this disk is set to 378602.
There is nothing wrong with that, but this is larger than 1024,
and could in certain setups cause problems with:
1) software that runs at boot time (e.g., old versions of LILO)
2) booting and partitioning software from other OSs
(e.g., DOS FDISK, OS/2 FDISK)
Command (m for help): p
Disk /dev/sdd: 250.0 GB, 250059350016 bytes
86 heads, 15 sectors/track, 378602 cylinders
Units = cylinders of 1290 * 512 = 660480 bytes
Device Boot Start End Blocks Id System
/dev/sdd1 * 1 208090 134217727+ 4 FAT16 <32M
After changing the partition type to 0x07 (NTFS), it was time to rip that partition out again, and mount it up. Start 'dcfldd if=image.dd of=image.c.img bs=512 skip=1 status=on' (this time it's not a forensics case I'm just trying to get some files for a friend so who cares about MD5 hashes). Sit back and wait, and wait, and wait.
I admit it, I'm not patient a lot of the time. When I start something like this I want it done, I don't want to have to wait, so I tend to keep fiddling with something while the long process is running. This time it definitely paid off.
I went looking for what the bits were that indicated the start of an NTFS filesystem, and found a little write-up ( http://www.ntfs.com/ntfs-partition-boot-sector.htm ) that told me precisely what I wanted to know. With a little bit of knowledge and knowing a few tools you can get into a lot of trouble :), I whipped out head, and hexdump, and less, and put together:
head -500k image.dd | hexdump -C | less
And started looking for the header, and found it 0x7e00 ... which with a little math one figures out is 32k bytes into the file. You'll also note that this is not where I started to cut the file apart with dd, you'll notice that I started at byte 512. Now that I've been letting the earlier dd run for most of the day while working on other things, I didn't really want to restart it at the new offset so I went looking for an alternative... and found it!
mount -t ntfs -o loop,ro,offset=0x7e00 image.dd /mnt
Yup, that's right, you can mount starting at an offset. If you happen to know where the filesystem header is, just point mount at it and let it figure it out. Having figured that out, and it worked great, the entire contents of the filesystem were there, and I started tarring off the files from it that my officemate wanted. But now I had a thought, if I can do a fix to the partition table of the original disk, then I can hand him the external disk in an enclosure and it gets even easier. A little trip into fdisk again, and I am able to again try to mount the actual drive... and it doesn't like me. I think it had something to do with that starting sector being set to 1. On a whim, I decided to try:
mount -t ntfs -o ro,offset=0x7e00 /dev/sdd /mnt
and discovered that it will do the same thing with hardware as with a loop interface. I don't think I'm fearless enough that I'm willing to try to mangle the partition table to point it at the right location. I'll let the tar finish, and give my officemate the tar so he can have the files he cares about back, and we can wipe the drive and start over entirely.
 mmls is part of The Sleuthkit, available at: http://www.sleuthkit.org/sleuthkit/index.php
dcfldd is an 'improved' dd, which includes things like status, and hashing of the data transfered. It's available at: http://dcfldd.sourceforge.net/