±Forensic Focus Partners
New Today: 5
New Yesterday: 9
· A guide to RegRipper and the art of timeline building
· Recovering Evidence from SSD Drives in 2014: Understanding TRIM, Garbage Collection and Exclusions
· FT Cyber Security Summit 2014 – Recap
· Why Offender Profiling is Changing Thanks to Mobile Forensics and Increasingly ‘Social’ Criminal Activity
· Understanding Cyber Bullying – Notes for Digital Forensics Examiners
· Investigating the Dark Web – The Challenges of Online Anonymity for Digital Forensics Examiners
· The Complete Workflow of Forensic Image and Video Analysis
· Browser Anti Forensics
· Coming apart at the SIEMs …
±Follow Forensic Focus
Write-Protection using Linux
The most obvious way is via fstab. Also autofs can be configured to mount devices read-only.
I am quite certain both ways (done properly *g*) are forensically sound. You may prove me wrong!
Are there any other ways write-protecting devices with Linux?
Only software-solutions please... no hardware ;).
- Senior Member
- a_kuiperThe most obvious way is via fstab. Also autofs can be configured to mount devices read-only.
There's an interesting paper called 'The Fallacy of Software Write Protection in Computer Forensics' by Mark Menz & Steve Bress -- you may want to read it (just Google for it).
Their conclusion is simple economy -- the cost saved will very probably be lost later when the case is prepared for court.
You also want to read Ernst Baca's report 'Knoppix Bootable CD Validation Study for Live Forensic Preview of Suspects Computer', in which the conclusion begins:
"It was quite startling to find that mounting EXT3 and reiserfs partitions read-only changed the state of the drive."
Things may have improved since.
>You may prove me wrong!
I don't think so -- it's more probably you who have to convince the court (or equivalent body) that the method you used is sound.
So how have you verified that the method you propose is sound? May we see your test method and protocols?
NIST has a 'Software Write Block Tool Specification & Test Plan' that you might be interested in. And very close to that report, they also have links to test reports for a few soft solutions for write blocking, though they all seem to be for DOS/Windows.
- Senior Member
If you want to forensically mount a file system then use "-o ro,loop" options - I never captured a write command passed through a read-only loopback device ("loop" is required even when mounting a block device, not a regular file (i. e. dd image), since it successfully blocks all writes sent by buggy file system drivers when using only "ro" option). Setting block devices to read-only mode ("blockdev --setro /dev/sda1", "hdparm -r1 /dev/sda1") is ineffective.
You can also look at several reports (sorry for bad English in them ):
I'm also aware of at least one forensic distribution that claims to mount devices in read-only mode, but actually sends tons of write commands when working "read-only" with some file system types, but the data remains unchanged, so it is probably overwriting data with the same data
Hi, those reports regards old releases of Caine, the version 2.0 is fully patched against any type of mounting, TheFuf gave me a special patch for avoiding the fake-casper problem too
In any case....if you boot by Caine, you can see that any device is mounted, so you can make a forensically sound image file directly using as source /dev/sdX.
Dr. Nanni Bassetti
From what I found out for instance the Linux-distribution grml uses blockdev and a dynamically generated fstab (rebuildfstab). Seemingly the fstab can be made to protect the filesystem but not other "actions" which could occur to a HDD (swapping, journalling - if supported...).
So working with a write-protected (via fstab) HDD could be a risky whilst simple acquisition might be fine. Obviously this is not forensically sound and with RAID-systems it is advisable to use a hardware write-blocker.
- Senior Member
I emailed their support regarding the above quoted paper and they told me the following :
The attack mentioned in the referenced paper was against an older version of Grml.
We discussed this issue with the author of the paper back those days and came up with different approaches to solve this issue.
This issue is no longer present in current versions of Grml and we even have additional protection methods built into Grml-Forensic (and are working on further features to make the system forensically sound for any possible situation).