Hi everyone.

I'm trying to take a bit-stream image of a laptop harddisk using DD. The purpose of this is to take an undisturbed image for forensic purposes and then open the image using either X-ways Forensics or EnCase in windows. Here is the nature of my problem:

First and foremost, I'm using the Helix Forensic CD which boots into Linux. According to Helix, this is an edited of Knoppix that write protects the harddrive of the system you are on in order to not spoil evidence.

Now, I'm trying to use dd in order to transfer the contents of the harddrive onto an external hard drive. The Exy is formatted into three 32GB FAT32 partitions which Helix recognizes. Or, I guess it does, because it puts little images for sdb1 2 and 3 on the desktop.

I created a directory (or so I thought) in sdb1 called "images" with the mkdir command. I then used the following command (as a practice with a floppy disk drive connected to USB):

dd if=/dev/sda of=/media/sdb1/images/floppyimage

It came back and said that it had copied 1.5MB of info, and I confirmed with "ls" that the file floppyimage was on sdb1.

Here's the problem, when I rebooted to Windows and opened up the external harddrive, the folder images is not there. The file floppyimage is not there. In fact, X-ways forensic confirmed that not only was the file not written, but it isn't even referenced in the FAT tables.

I'm betting I did something wrong in Linux, so I wanted to ask for help from you guys. I understand that I just spewed a lot of not so concrete info, so if you need clarification on something, let me know.

Thanks

write protects the harddrive of the system you are on in order to not spoil evidence.
AFAIK if you don't run fsck on it, don't use automagical mounting and mount read-only you're safe to use any LiveCD.


The Exy is formatted into three 32GB FAT32 partitions which Helix recognizes. Or, I guess it does, because it puts little images for sdb1 2 and 3 on the desktop.
That's not a valid way to check! Open a terminal and issue a "mount". Check the drive for rw/ro flags.
If more proof is necessary just "touch" a file on the drive to write to. If the file exists the drive is writable.

The problem is (someone correct me on this if I am wrong), that Knoppix and its derivatives use a complicated `UnionFS' filesystem, in which you can edit files on what appears to be the write-protected CD. What is actually happening is that most files are hardlinked to files on the CD. Let's say I edit the file /etc/X11/xorg.conf. Now that file is no longer linked to the one on the CD, but to one on a ramdisk. The ramdisk is ephemeral, and therefore any changes made will be lost upon shutdown. This concept is ingenious (it lets you transparently use knoppix as if you were writing to writable media), but sometimes it gets in the way.

Here's what I think happened:
You mounted the drive read-only instead of read/write.
You tried to write to a file on the mountpoint.
Somehow, knoppix automagically detects when you try to write to a read-only mountpoint. Instead of complaining as a normal linux would, it happily writes to the ramdisk, and you think everything is ok. Then, when you turn off your computer, the ramdisk disappeared.

So, what you have to do is make sure you mounted read/write. Any kernel-level error messages are probably hidden by knoppix, but you can see the most recent ones with the dmesg command.

Btw, have you tried dd_rescue? There's also another command for forensic analysis of linux filesystems that I can't remember off the top of my head.