There are a few cool things about Helix:

• As the title of this post indicates, this is a bootable, live linux CD. It is a heavily modified version of Knoppix.
• It is specifically for forensics and incident response. For this reason, such features as never using swap space are always on. This distro is also updated every 3 months to stay current.
• In addition to a bootable CD, it can also be used as a Windows application.

The quote below and much more can be found in their document, Helix for Beginners.


For the whole scoop:
http://www.e-fense.com/helix/index.php

Hope this helps,
Don

I've used Helix quite a bit and the way it logs every action your perform makes it most valuable. The only complaint I would have is that is that it will not automount usb sticks and often will not have the correct video drivers available when booting to linux.

Hell Yeah!!

You are a machine, my friend!

Don

Thats a good point, however automounting in read only mode would save somebody from making the mistake of mounting in write mode, which is more common then you would think.

I'm guessing you mean the opposite of what you wrote. Automounting in R/O saves a step and reduces errors, which is why so much of the initial info gathering and imaging in forensics is automated and scripted. It lends to repeatability and accuracy.


I'm not aware of linux writing to a drive mounted in r/o. Has that ever happened to you? I know it occurs on Windows, which is why most people running encase on windows use hardware write blockers.

To do anything with an image in Encase and Autopsy/Sleuthkit it has to be mounted. There's more to it obviously then just taking an image.

If you have the time, can you send me some links/papers that talk about Linux writing to a r/o mounted drive. I'm very interested in that, I would like to know in what specific circumstances that happens, as I have never had the md5 hashes not match when using helix or encase. I don't doubt it, obviously theres a big market for hardware write blockers, I just haven't seen it on Linux ever. I'm guessing then that its the hash of the entire image an not specific files/partitions?

Hi,
At a guess some journalled filesystems drivers may be replay the journal regardless of whether it's been mounted read-only. I would imagine that this would be considered a bug since it is so counter intuitive to the whole idea of mounting read-only.

On the other hand you may support the idea that for the sake on integrity the journal should be replayed regardless of how it is mounted. I'd consider this course of action faulty and I'd suprised if it happens. If it does, open source kernels such Linux as used by Helix could be 'fixed' for the purposes of forensic use.

Mounting any primary evidence media, even in read only mode, is really bad form in my book unless there is no other option available. In UNIX/Linux you should read an image from the raw device...

$ dd if=/dev/sda of=evidence_image

If windows can't do this without mounting the device then image the it on a *nix system and import the image file into EnCase, FTK etc. for analysis.

Jim

Again I'm making another guess but consider commands that act upon filesystems that are not mounted, the obvious one being fsck. You don't mount the filesystem but it potentially changes the raw data. Perhaps technologies such as LVM and software RAID are incapable of mounting a filesystem without modifiying the data on disk if not the files on the filesystem.

No answers, no references, just ideas at this stage. I'll do more digging.

Jim