Bootable Imaging distros

Do you happen to know some other distros that don't have this issue?

Try daily grml builds (http//grml.org/daily/), grml is the first Live CD whose developers included a software write blocking kernel patch, which mitigates such issues (this patch will be included in the next stable version). You can also try ALT Linux Rescue (http//en.altlinux.org/Rescue), which is protected against such issues, but doesn't have write blocking patch included.

I just gave a look at some images I recently took with DEFT and the journal file seems to be fine. Maybe as the message suggested it happens only if the machine was not shut down properly, e.g. it was found turned on and the plug was pulled?

Try daily grml builds (http//grml.org/daily/), grml is the first Live CD whose developers included a software write blocking kernel patch, which mitigates such issues (this patch will be included in the next stable version). You can also try ALT Linux Rescue (http//en.altlinux.org/Rescue), which is protected against such issues, but doesn't have write blocking patch included.

Thanks, I'll keep those in mind (I already used grml a couple of times but I really prefer having GUI and Guymager around). Can't wait until the patch ends up in other distros though.

I just gave a look at some images I recently took with DEFT and the journal file seems to be fine. Maybe as the message suggested it happens only if the machine was not shut down properly, e.g. it was found turned on and the plug was pulled?

Yes, this happens only if a volume was mounted in Windows and was not unmounted properly. This won't happen even if a volume was mounted "read-write" in Linux, because of differences in NTFS drivers between Windows and Linux. Perhaps I need to clarify my first message in this thread. Anyway, if conditions mentioned before are met, the changes are imminent.

Also note, that a volume with NTFS will be mounted "read-write" during the boot for less than a second. You can also expect access time updates in rare cases, since ntfs-3g and Linux force "relatime" option for mounts by default (documented in this paper, see the "Helix3 Pro" section, it describes exactly what we discuss here, although authors didn't try to determine the root cause of data alteration correctly).

But the NTFS thing is not the only problem with forensic Live CDs. There are other issues of data alteration as well, most of them were posted on ForensicsWiki for years. Most forensic Live CDs are based on initramfs code that was not designed to meet computer forensics requirements and can be easily tricked to run the code from a connected HDD automatically during the boot (with root privileges, of course). Some guys are really worried about vulnerabilities in forensic tools in respect to the Daubert standard, but here we got a design flaw (actually, a huge design hole), not even a vulnerability. Actually, the primary cause of Ext3/Ext4/NTFS alterations discovered is that flawed initramfs code.

Thanks, I'll keep those in mind (I already used grml a couple of times but I really prefer having GUI and Guymager around). Can't wait until the patch ends up in other distros though.

I didn't submit the patch to the LKML, so don't expect to see it being introduced everywhere )

Dealt with plenty of "dirty" NTFS volumes in my time. The secret is to use a hardware write blocker. You're trying to come up with a better mousetrap which has an inherently larger risk. You're not reading properly - the live cd is read only (you can't write to it). The evidentiary disk is read only (you can't write to it) when using a hardware write blocker. You can't have a trojan program if the file system isn't even mounted, as it's not even on the same layer on the OSI model. And what would it execute? There is nothing to execute on, as the only writable medium is the collection disk, which is already wiped. This argument is invalid on its face value.

And for those playing at home, a USB 3.0 flash drive with a hardware write protect switch to really tamper-proof your bootable acquisition software

http//www.amazon.com/FlashBlu30-Physical-Write-Protect-Switch/dp/B00JJIEHJE/ref=sr_1_2?ie=UTF8&qid=1412377788&sr=8-2&keywords=usb+write+protect

You're not reading properly - the live cd is read only (you can't write to it). The evidentiary disk is read only (you can't write to it) when using a hardware write blocker. You can't have a trojan program if the file system isn't even mounted, as it's not even on the same layer on the OSI model. And what would it execute? There is nothing to execute on, as the only writable medium is the collection disk, which is already wiped. This argument is invalid on its face value.

I understood your position. However, I have to disagree with you
1. It is a common practice to keep several disk images on one target drive (for the purpose of adequate space utilization). What can a trojan program do with such data on a target drive? It can delete these disk images, alter them or even add some false evidence. But I don't think that such possibility is more than a theory. Let's just skip ahead.
2. What else can a trojan program do? Perhaps, it can alter the process of acquisition, thus affecting the results of a subsequent forensic examination. If examiner trusts his tools, it's unlikely that he will examine the original evidence in order to find the differences in a verified copy (a verified forensic image) in each particular case, so alteration is very likely to remain unnoticed. Is there a technical possibility to do so in case of Ubuntu-based forensic Live CDs? Yes. Such Live CDs, as I said before, are based on code that was not designed with computer forensics in mind. But is this another theoretical attack? May be.
3. Many computers don't have CD drives nowadays. So we should expand the judgements to Live USBs, which are, in general, writable.
4. Quite often Live CDs and Live USBs are used to preview a suspect computer or a drive on a site (usually without a hardware write blocker). At this point, many conclusions from this paper come into play.
5. Finally, the most practical implication of arbitrary code execution in Live CDs and Live USBs, is that a plaintiff/defendant can demonstrate (in practice, not in demagogy) that your method of creating a forensic image or your method of conducting the examination using <your tool here> is flawed (based on argument #2), and then convince the court that your results cannot be trusted. In some jurisdictions regulators state that forensic methods, not only the tools or particular results of their usage in a case, should be verified.

Using a bootable distro on a USB thumb drive or CD/ DVD can destroy the stored bitlocker key (if used) in the TPM chip. Better to drag the HDD out and use it on a write blocker.
If a notebook, like a mac book pro with bus connected SSD is the suspicious PC you need to use a bootable distro.

And that's why we all use hardware right blockers. 😯

They are surely better than hardware wrong blockers. roll wink

And that's why we all use *nix tools to perform forensic examinations of Windows computers. roll

I guess that noone then uses WinFE. 😯

jaclaz

I guess that noone then uses WinFE. 😯

I'd love to make a WinFE disc but I'm afraid that would likely cause more trouble in court than a widely-used solution like DEFT/CAINE/PALADIN/etc would. Plus driver nightmares that would basically halve the cases where I could use it (e.g. older machines with SCSI/custom RAID controllers from hell). Does Automount set to 0 truly prevents any write to the drives?

Does Automount set to 0 truly prevents any write to the drives?

Of course not.
There is something more than just Automount set to 0 (which actually is NoAutoMount set to 1).

But Troy Larsson, Colin Ramsden, Brett Shavers (to name the main three people among the originators/supporters of WinFE) are not widely known for playing pranks on digital forensic investigators 😯 and should be granted, based on their curricula/good reputation, at least the benefit of doubt ) .

Tests made independently have shown no signs of writing to the disks using a properly created WinFE, though of course everyone should validate the tool and the specific build he/she makes.

The fact that the community of professional digital forensic investigators is IMHO very "passive" about this and that most of the published tests and tests results - otherwise missing - were carried by "amateurs" like Misty
http//mistype.reboot.pro/documents/WinFE/winfe.htm
http//reboot.pro/topic/19687-winfe-sanpolicy-and-noautomount-combinations/
and to a much lesser extent by yours truly, could represent an opportunity for the pro's to actually prove a point (whatever the point is).

jaclaz