-
Notifications
You must be signed in to change notification settings - Fork 45
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Extracted files seem to be corrupted #230
Comments
which version of libewf are you using? stable or experimental? |
Hi Joachim, Thanks for the reply. I was using libewf-experimental-20170703, and I just tried with libewf-20140608, but the hash is still different. Could you point me to where I can download other stable builds (your google drive link seems to be down)? |
At the moment I don't distribute binary builds; source package can be found here https://github.com/libyal/legacy I'll have a look when time permits if I can reproduce the behavior. Do you have the br.py somewhere you can share? |
Yes, you can download it at https://www.dropbox.com/s/q2fm0mqd5vwx6j3/br.py?dl=0
|
Downloaded: pc.E01, pc.E02, pc.E03, pc.E04 from https://www.cfreds.nist.gov/data_leakage_case/data-leakage-case.html
Side note: 20140801 is the latest stable 20140608 found here https://github.com/libyal/libewf-legacy ran: ewfmount and sleuthkit icat
Result dfVFS recursive hasher with TSK
libfsntfs
mount.ntfs (ntfs3 fuse)
Downloaded: pc.7z.001, pc.7z.002, pc.7z.003 from https://www.cfreds.nist.gov/data_leakage_case/data-leakage-case.html
SHA1 of image not the same between raw and E01, hashes of individual compressed segments do match
So MD5 of for SOFTWARE extracted from raw and E01 the same mount.ntfs (ntfs3 fuse)
|
Current summary:
MD5 of p2\Windows\System32\config\SOFTWARE remains the same across implementations. |
Used FTK imager on both the raw and E01
|
Looks that the last segment (data run) is the one that differs |
Booted a Windows 10 VM and attached the image:
|
@Silv3rHorn what it looks like, it that FTK and XWays are the ones interpreting NTFS differently than the Windows OS. |
I'm closing this issue, since libewf (stable), libtsk and dfvfs seem to do the right thing. Informed AccessData and X-Ways by mail. |
According to X-Ways they include the data stored after the
From a UX perspective IMHO this should be verbose in UI (can only judge FTK on this) |
For context: https://www.osr.com/nt-insider/2015-issue1/logical-physical-file-sizes-windows/ Section: Valid Data Length
The TL;DR is that the behavior of data beyond |
Thanks. Really appreciate your time and effort in clarifying this issue. |
For completeness AccessData has indicated to work on changes to FTKImager to have it behave like Windows and expose the "invalid data" as slack. |
Hi,
I have written (mostly copied) a python script (br.txt) using dfvfs to automate the extraction of SOFTWARE registry hive from a forensic image (including volume shadow copies). However, the hive extracted differs in hash (MD5) from the ones extracted using X-Ways and AD FTK Imager.
I have tried using different forensic images, latest 2 versions of dfvfs, python 2 & 3, but I still encounter this issue.
Steps to reproduce the issue:
python br.py <downloaded cfreds image> <output directory>
Would appreciate your assistance in resolving the issue, pls.
Regards.
The text was updated successfully, but these errors were encountered: