Bootable Imaging distros

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

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

Does hardware write blocker save your machine from execution of arbitrary code residing on evidentiary media? -) This happens on mostly all Ubuntu-based forensic Live CDs.

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

Does hardware write blocker save your machine from execution of arbitrary code residing on evidentiary media? -)

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

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

Does hardware write blocker save your machine from execution of arbitrary code residing on evidentiary media? -)

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

But I was talking about these tools -)

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

Does hardware write blocker save your machine from execution of arbitrary code residing on evidentiary media? -)

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

But I was talking about these tools -)

First, you should be working with a forensic image, not a live drive. Secondly, you can't execute Windows programs on a native *nix workstation using these *nix tools we are talking about. Third, if you're going to run Windows executables, use a virtualized environment.

First, you should be working with a forensic image, not a live drive. Secondly, you can't execute Windows programs on a native *nix workstation using these *nix tools we are talking about. Third, if you're going to run Windows executables, use a virtualized environment.

Ok, I'm using a Live CD to make a forensic image. In many cases I don't know what data is stored on a drive before I acquire it, so I can't be 100% sure that I'm going to work with a Windows system. What happens if a Live CD is automatically executing a binary (ELF) stored on an evidentiary drive during the boot?

First, you should be working with a forensic image, not a live drive. Secondly, you can't execute Windows programs on a native *nix workstation using these *nix tools we are talking about. Third, if you're going to run Windows executables, use a virtualized environment.

Ok, I'm using a Live CD to make a forensic image. In many cases I don't know what data is stored on a drive before I acquire it, so I can't be 100% sure that I'm going to work with a Windows system. What happens if a Live CD is automatically executing a binary (ELF) stored on an evidentiary drive during the boot?

If you are using a Live CD, it's READ ONLY. Secondly, you are using a HARDWARE WRITE BLOCKER, so the evidentiary drive is READ ONLY.

If you are using a Live CD, it's READ ONLY. Secondly, you are using a HARDWARE WRITE BLOCKER, so the evidentiary drive is READ ONLY.

1. What Live CDs are read-only? CAINE, DEFT Linux, PALADIN, SMART Linux? Do you think these are read-only? Can you name a forensic Live CD which is truly read-only by itself?
2. If you use a hardware write-blocker then code execution from evidentiary media still has negative impact on the method itself.

Sure. You can reproduce it by yourself
1. Boot Windows system installed on NTFS.
2. Power cut.
3. Boot DEFT Linux.
4. Examine "/var/log/capser.log".

You can also compare hash values for NTFS partition.

PS. If anyone has questions about this issue, I can provide small virtual machine (in OVA format for VirtualBox) to reproduce the NTFS journal wipe quickly.

Wow, is it really cleaning up the journal? I noticed that message too but I thought it was just resetting the NTFS dirty flag if the system wasn't shut down properly (not like that was any good either). Good thing I always try to image important evidences separately. Do you happen to know some other distros that don't have this issue? With ultrabooks, windows tablets, etc. where you can't simply remove the drive it can truly become a pretty big issue.

Wow, is it really cleaning up the journal? I noticed that message too but I thought it was just resetting the NTFS dirty flag if the system wasn't shut down properly (not like that was any good either). Good thing I always try to image important evidences separately. Do you happen to know some other distros that don't have this issue? With ultrabooks, windows tablets, etc. where you can't simply remove the drive it can truly become a pretty big issue.

Yes. If you dig into the ntfs-3g source code, you will see the following lines
if (!(flags & NTFS_MNT_RECOVER) || (errno == EPERM))
goto error_exit;
ntfs_log_info("The file system wasn't safely "
"closed on Windows. Fixing.\n");
if (ntfs_logfile_reset(vol))
goto error_exit;

And the ntfs_logfile_reset() is

/**
* ntfs_logfile_reset - "empty" $LogFile data attribute value
* @vol ntfs volume whose $LogFile we intend to reset.
*
* Fill the value of the $LogFile data attribute, i.e. the contents of
* the file, with 0xff's, thus marking the journal as empty.
*
* FIXME(?) We might need to zero the LSN field of every single mft
* record as well. (But, first try without doing that and see what
* happens, since chkdsk might pickup the pieces and do it for us…)
*
* On success return 0.
*
* On error return -1 with errno set to the error code.
*/