Forensics at journaling filesystems

Computer Forensics - The Basics

What is computer forensics?
Principles of computer forensics
Hard disk drives - the basics
Linux 'dd' basics
Computer Forensics work placement

Source
Original device

1. adquire an image from it 
2. duplicate the aquired image to get a copy to work with 
3. and store the original device and the initial image

(it may seem a bit redundant, but at least you really risk nothing)
------------

Backtrack 4 pre release is ready, get it here here.
More about offensive-security, creators of backtrack:
http://www.offensive-security.com/

Off course Protech and BackTrack (the Rolls of pentesting distro) are not considered as forensic live CD but as pentesting live CD.
Pentesting distro are intended for network and system auditing, and they can be used bycybercriminals to gain access on a host, or by the sysadmin. or the pentester consultant in order to audit the line defense.
Unlike forensic live cds which are devoted mostly for static analysis, and data acquisition; pentesting live cd are mostly intended for offensive taks like port scan, os finguerprint, sniffing, exploit attempts etc.
But some live cd can also be used simply as a read only OS for connecting in hot spot as i use to do with Protech (now i use another one).
------------

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).

----------

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.

----------------

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.

----------------

It's the journal that can change the hash. Read this
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.

----------------

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
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...

------------------

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.