Recent changes to Home

Discussion for Home page

sunlight — Sun, 08 Nov 2020 16:09:41 -0000

Dear Guy,

Just wonder that can Guymager be booted from a USB flash memory stick or CD-ROM ?

In other words, can Guymager support on-line Forensics to collect digital evidence and pick up data, make image in the source computer's running state?

thanks

Home modified by Narayan

Narayan — Tue, 22 Jan 2019 13:19:40 -0000

--- v14
+++ v15
@@ -6,6 +6,6 @@
 Interesting pages:

 * [New features in Guymager 0.8.x](New features in Guymager 0.8.x)
-* [Denny's web user interface](guymager:wiki:Web Userinterface)
+

 Click [here for a list of all pages](http://sourceforge.net/p/guymager/wiki/browse_pages/) in the Guymager Wiki.

Discussion for Home page

guy — Thu, 13 Dec 2018 17:50:39 -0000

Eddy, I think you already found the solution yourself: "not technically empty".

I added the compression option "empty" for systems with poor CPU performance. For example, when imaging many PCs in a company, where I then use the PCs themselves for doing the images (booted from Linux live sticks). Those office PCs often are low cost systems with cheap Intel CPUs.

For "empty" to work there must be whole chunks filled with only zeroes. A chunk is the block size used in EWF, it very often is 32K. So, only if there is a block of 32K fully made up of zeroes then the "empty" compression jumps in and replaces that chunk by a precomputed z-compressed-zero-chunk.

Try this to see the effect:
1. Put your drive/stick into a Linux system and mount it
2. Open a shell, change the directory to the stick you just mounted and run
dd if=/dev/zero of=./big_and_zero bs=1M
3. Wait until dd returns with the "no more space" error.
4. Remove the file
rm ./big_and_zero
5. Unmount the device

Now, try to image that device again with compression set to "empty" and see what the resulting image size will be.

Of course, there is no sense in waiting a long time to fill the empty spaces with zeros before starting the image. It's just for showing the effect.

SSDs and Stick are generally problematic for the "empty" setting, as even brand new devices often are not initialised with zeros (unlike HDDs).

My recommendation: The setting "empty" is for HDDs images done on slow CPUs.

Discussion for Home page

Eddy Colloton — Thu, 13 Dec 2018 15:19:10 -0000

I've done a few tests compairing the size of ewf disk images with compression=empty vs compression=fast. I've been surprised that the 2 flash drives I have imaged with compression=empty have ended up equal size to a raw disk image (despite often having lots of empty space). See results below:

32gb flash drive:
EWFCompression=Fast: 23.2 GB, 00:49:43
EWFCompression=Empty: 32.1 GB, 00:49:40

4gb flash drive:
EWFCompression=Fast: 2.2 GB, 00:03:40
EWFCompression=Empty: 4 GB, 00:03:40

I had assumed that due to the space available on the 4 gb drive (about 2.8 gb avail) that the resulting empty compression ewf disk image would be around 2.2gb (like the fast is). This is clearly not the case. Is the "availbale" space on a drive not technically "empty"? Or is something else going on?

-Eddy

Discussion for Home page

ridgedale — Tue, 20 Nov 2018 09:48:17 -0000

Thanks, Guy. Much appreciated.

Discussion for Home page

ridgedale — Mon, 19 Nov 2018 14:45:05 -0000

Thanks for your reply, Guy.

I've learnt a lot over the past weekend. I re-ran the check using ewfverify as advised and the md5 checksum matches, which is good to know. I also ran some md5sum tests on some small text files and then compressed them using .7z that confirmed your point that the checksum of the "container" file will always be different from the source file.

As regards the xmount error, if I remember correctly, I was using the gui interface. Using the commandline resolved that issue. ;)

I'm beginning to realise it would be better going forward to run any forensic tools from the commandline to ensure control and integrity of the process being launched. I'll remember to use the CalcImageFileMD5=on switch in future.

My Mac is currently running Lion and Sierra which should support opening NTFS at least read-only out of the box. I'm not too bothered at this stage as I found a workround albeit convoluted by launching a Lubuntu VM. I'll be replacing the MacBookPro internal hard drive shortly, once I've imaged all the boot partitions and backed up the data to the server. So I'll check out mounting cross-platform volumes as soon as I have a vanilla OS installed.

Thanks again for your help and patience.

Discussion for Home page

guy — Thu, 15 Nov 2018 19:38:02 -0000

You wrote:

Neither of the md5 hashes for those .E01 files match the original md5 hash generated by Guymager at the time of the image completion.

and

It does not match the hash generated by Guymager upon completion of the imaging

The MD5 hash calculated by Guymager (and by any other imager that exists) is always the hash of the original source data packed into the E01 file. As the E01 file also includes its own EWF structures and some meta data it's just normal that the MD5 of the whole E01 file is different from the MD5 of the imaged data it contains.

In order to check the consistency and the imaged data hash of an EWF file you should use ewfverify.

You may instruct Guymager to not only compute the hash of the imaged data but also the hashes of the generated Exx files. AFAIK, that option is switched off by default in CAINE. To enable it you may run Guymager from the command line like this:
sudo guymager CalcImageFileMD5=on
You'll find the hashes computed that way in a table at the end of the info file, for every Exx file there's a hash.

I cannot tell you what your problems are on MacOS/Windows or why you would have to use Vmware. Guymager simply created a file on an NTFS drive. No matter what file Guymager or any other program wrote to that drive and no matter what it contains: A file is a file and can be copied. Nobody needs Vmware for copying files. Or else there must be a problem with the system that does the copy. Does your Mac support NTFS?

Concerning your xmount problem: On which system do you run it? What's the exact command line you're using?

Discussion for Home page

ridgedale — Thu, 15 Nov 2018 14:43:26 -0000

I must be doing something wrong. When I try to mount the .E01 file on another system I get the following error:

Unable to open input image file 'xmount': The specified input file(s) are not valid EWF files!

I made sure the write blocker tool had set the source internal drive of the computer was set to read only before I created the image and the target drive (4Tb USB3 G-Tech mobile external drive) was set to read/write. I used Guymager via a CAINE 10 bootable flash drive (*Note: I had to reformat the 4Tb drive to NTFS in order to get it be recognised)* to create the .E01 image file written directly to the 4Tb external drive. No bad sectors were encountered during the acquisition. The MD5 hash and MD5 hash verified image recorded in the .info file match exactly.

I've got 3 copies of the 1Tb image file inluding the original image file on the 4Tb external drive. I subsequently copied the the .E01 (single image file) and .info files to two other computers: MacOS Sierra (on external GTech 8Tb thunderbolt drive - FS = Mac OS Extended (Journaled)) and Windows 10 64-bit (internal hard drive - FS = NTFS). The only way I was able to transfer the file from the 4Tb drive to the 8Tb drive was to install Lubuntu under VMware Fusion. Neither of the md5 hashes for those .E01 files match the original md5 hash generated by Guymager at the time of the image completion.

The file sizes by getting the information from the file properties were 105,670,052,583 bytes (105.67 GB on disk - Mac (on 8Tb drive)), 98.4Gb (105,670,052,583 bytes) but showing as 103,193,411kb in Windows Explorer (on internal hard drive) - Windows 10. The size of the original file on the 4Tb drive matches the details of the file on the Windows 10 internal hard drive and matches the byte count of the file copied to the 8Tb external drive.

When I connect the 4Tb drive to the Windows 10 PC and run an md5 check against the original image file it matches the hashes of the both the copied files! It does not match the hash generated by Guymager upon completion of the imaging. The original file has not been touched other than being copied as detailed.

Any ideas what I have done wrong?

Discussion for Home page

Eddy Colloton — Fri, 21 Sep 2018 18:48:33 -0000

Thanks again Guy! Yeah, makes sense lots of imagers out there. I've used xmount a little, I'm more familiar with ewfmount from libewf. Both seem to work well!

Discussion for Home page

guy — Thu, 20 Sep 2018 21:46:49 -0000

I would guess: No, Guymager's EWF files won't be described separately.

I think there's no sense in doing so. Other imagers are missing as well - and Joachim surely has other things to do than re-running every imager with every version update ; )

BTW: if you need a tool for accessing EWF files under Linux then have a look at xmount.