file inconsistencies while copying hiberfil.sys

[ghost]

I have encountered the following problem:

Scenario: Extracting hiberfil.sys from an EWF container (Win10)

Method 1: Mounting EWF container with target-mount and copying with rsync Method 2: Saving the file with target-shell Method 3 (as reference): Copying with FTK

All three methods return different file hashes, while method 1 and 2 return at least an identical file size, the file is much smaller in method 3 (saving with target-shell seems to truncate the 0 bytes present at the end of the file). I compared the files extracted by method 1 and 2 and the first difference occurs after 0x7F000 bytes. After that every byte differs.

Is this a known issue?

[Schamper]

Hi @ruukaku, not a known issue and of course highly concerning.

Can you provide some more details?

• What version of Dissect are you using? (pip freeze | grep dissect)
• Is the file size in method 1 & 2 larger or smaller than method 3?
  • If it is smaller than method 3, it can be attributed to FTK making a "full" (i.e. including slack space) dump of the file, whereas we only dump the "actual" file size amount of data
• Besides the file size being different, is the file difference at 0x7F000 present between method 1 & 3 and/or method 2 & 3?

Finally, is this a "public" EWF file (one that might be shared with us for debugging purposes)? Otherwise we'll try to replicate locally.

[ghost]

1. Dissect version:

   dissect==3.5
   dissect.cim==3.5
   dissect.clfs==1.4
   dissect.cstruct==3.6
   dissect.esedb==3.6
   dissect.etl==3.4
   dissect.eventlog==3.4
   dissect.evidence==3.4
   dissect.executable==1.2
   dissect.extfs==3.4
   dissect.fat==3.4
   dissect.ffs==3.4
   dissect.hypervisor==3.6
   dissect.ntfs==3.4
   dissect.ole==3.4
   dissect.regf==3.4
   dissect.shellitem==3.4
   dissect.sql==3.4
   dissect.squashfs==1.1
   dissect.target==3.8
   dissect.thumbcache==1.3
   dissect.util==3.7
   dissect.vmfs==3.4
   dissect.volume==3.4
   dissect.xfs==3.4

2. Yes, the file size is much larger with method 1 & 2 than method 3 (2GB to 400MB)

3. Between method 2 and 3 the files' sizes are different, however the beginning of the file extracted with method 2 is identical with the entire content of the smaller file extract with method 3.

I recreated the issue on my originally used VM (Debian 11) with an publicly available EWF image (https://belkasoft.com/ctf_march/) and got the same results. However, I could not observe this behavior on my macOS host machine (same image, same dissect version). Maybe this is some kind of weird Linux filesystem problem?

File hashes for the public image:

47219516a51ada45a9da42f7cf1d57f7dc3b2da0d50b532d7579305b0a34e770 hiberfil-mount.sys d2543ed346f87da34f42c2b1586f24fc099adb2fc2969ad6f01a4e59c69d51a0 hiberfil-shell.sys 69ead4dff6ee74f55efda9466336597844c6d4afb149bc488bbcbf7b7e9ac36d hiberfil-ftk.sys

[Schamper]

I'm able to reproduce the target-mount behavior with the public image and will investigate further.

However I'm unfortunately unable to reproduce the target-shell behavior. Both target-shell and target-fs give me a hash of 69ead4dff6ee74f55efda9466336597844c6d4afb149bc488bbcbf7b7e9ac36d and a file size of 2147012608 bytes.

I'll follow up shortly with results from the investigation into target-mount.

[Schamper]

Looks like it was a multithreading issue with fusepy. I've disabled threading for now and we can check in the future if we can make it properly thread safe.

The issue has automatically closed, however, if you are still experiencing issues with target-shell, please re-open!