EH-Net

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 (http://www.e-fense.com/helix/Docs/Helix-for-Beginners.pdf).


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

Hope this helps,
Don

It's also worth pointing out that as well as being a bootable Linux CD, it also provides tools for forensics on a Live windows system. A top notch contribution to the digital forensic world.

Along with all the tools are plenty of documentation, and it's very focused on preserving evidence and chain of custody. This is built for LEOs to collect data you can present in court (insert all the relevant caveats here). I keep a copy in my jacket for special occasions ;)

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.

any interest in a tutorial on this?  i have some content around here somewhere...

Hell Yeah!!

You are a machine, my friend!

Don

I wouldn't consider using a distro for forensic purposes if it would automount anything. A system has no way to differentiate between an USB Stick that I want to image from another one that I'd like to use as a storage medium, so I think it's the right way to do that by hand.

I think it is a strong pro for that distro that automount is disabled in Helix.

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.

If you want to image a drive you don't have to mount it anyway, so I think that shouldn't be a problem even for not so skilled people (or these that are possibly too lazy to take care of what they are doing)

BTW, even when you mount a drive read-only sometimes that may change the content that way that a hash before and after mounting will not match any more. It depends on what filesystem is on the drive, if it's some kind of journaling file system parts of the journal can change without writing to the drive.

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.

I mean exactly what I said.

To image a drive you don't have to mount it. Neither with encase nor any other tool like dd or others you need to mount a drive to get an image from it, so no write blocker is needed.

Yes, I saw that. After having read somewhere that it could happen I tried it with an USB pendrive with ext3 filesystem on it. The content of the filesystem as such is not altered, but obviously some changes in the journal (don't exactly know what, perhaps some update of timestamps in the journal) happens so that the hash does not match any more. It's not a problem for the data but you would have to explain what has happened in case that you have to present it in court.

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?

I think there is a misunderstanding. To work with an already taken image in Autopsy/Sleuthkit you have to mount the image, that's right. But in that case there is no problem, it's sufficient to set the image file read only to prevent any change.

But to get the image - and that's what I was talking about - there is no need to mount the original drive (the source) so the source is under no circumstances altered by the process of taking the image.

Thats two completely different things, prevent the source from being altered by the imaging process and on the other hand taking care that the image which has already been taken will not be altered by the analysis.

An in Encase you do not mount the image, you just add it to a case. Encase takes care that the image is not altered by the analysis, so that way it is even not necessary to set the image file read only (though it does not hurt).

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

yes, I was only referring to mounting the image not the original device. In most cases you can never work on the original drive it has to be sealed and locked away, unless its has to stay in production.

When you add an image to a case file in case, that is the same effect as mounting it as r/o. It makes the file system accessible to encase in read only fashion.

Which fs use journaling like what you referred to? My experience is limited to only ext/ntfs. I really want to learn more about this, in case I run into it.

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

You are right, it's the journal that can change the hash. Read this (http://www.linux-magazine.com/issue/35/Sleuthkit.pdf)

But I wouldn't call that a bug, it's intended behaviour. If it wouldn't be implemented like that the journal could not guarantee the integrity of the filesystem after a crash.

And under normal circumstances this is fine. However if it changes the hash on an evidence device image it will potentially render the evidence inadmissable. If you're working on an image and you accidentally alter the hash expect to have to repeat any analysis carried out on the image just to demonstrate due dilligence. I'm probably preaching to the choir but any change to the perceived integrity of the image can invalidate your work if the scenario involves lawyers.

Regards,
Jim

Did some research on this, slide 53 suggest that the Journaled File system tracks the number of times the file system is mounted and that accounts for the changes in hashes.
http://www.blackhat.com/presentations/bh-usa-03/bh-us-03-willis-c/bh-us-03-willis.pdf#search=%22forensics%20ext3%20journaling%20hashes%22

 (http://www.blackhat.com/presentations/bh-usa-03/bh-us-03-willis-c/bh-us-03-willis.pdf#search=%22forensics%20ext3%20journaling%20hashes%22)

I would say that this is a bug with the linux loopback driver, which is why that  sleuthkit article suggest modding it. Of course, the patch is only for the 2.4 kernel. Its funny because I discussed this possibility with two other forensics guys and they both agreed that this was impossible and none of us had ever seen it. So would you agree then, it would be best practices if using a host linux system and mounting either reiserfs or ext3 image to either use a hardware write blocker or burn the image to DVD to be on the safe side? Also, does this apply only to the mounting of the original device(because then it wouldn't really apply) or the image copy(which is what I'm concerned with).

It applies only to the handling of the original device.

Sure it could happen to the image too, but to prevent that in addition to loopback-mount the image read-only set the image-file read-only (r--r--r--) before mounting it so you can be sure that nothing will be altered.

Furthermore the best you can do is to never do any analysis on the original image, use a copy of it and you're safe anyway...

I guess I completely misunderstood you then. I was thinking that your were suggesting that the image hashes would be changed. Thats what got me thinking about it. When I say image, I'm always refering to a copy, not original file system. I wasn't really worried about the original device because we never use that, unless its to determine if there is an actual incident worth investigating. Wow I really wasted a few hours researching this, but I least I know a little bit more about journaling now.

Just to prevent another misunderstanding: when I say "copy of the original image" I really mean a copy of the aquired image.

original device -> aquire an image from it -> duplicate the aquired image to get a copy to work with and store the original device and the initial image (it may seem a bit redundant, but at least you really risk nothing)

Most of the confusion seems to be around the term 'mount'. Tools like Encase do not mount forensic images as you would a loopback file system for example. Forensic tools analyse a file system in the same way as you would analyse any other binary file i.e.  it reads it and understands the structure but does not access it in the way it you natively would.

Another example of the difference between mounting and analysing could be drawn between file systems and MS Office documents. If you open a document in Word, the way you would normally, you risk altering the file. Tools exist to access the content of the document in a safe manner, or you can simply work on a copy (of a copy) of the evidence.

Good practice is to work on a copy of any image you have taken. This reduces the risk that you will need to re-image a device which can only act to increase the risk of compromising your evidence.

Jim