I wonder if anyone can help.
Recently I have received SafeBack images on DDS3 & 4 tapes. I have restored the image to a drive. The verification CRC32 matched that on the original tape.
I then acquired the image using EnCase v5.03 Stating the number of sectors reported to me by SafeBack.
The problem I now face is that encase Acquisition/ verification hash is in a different format, is there any way hashing the original or the encase acquired version to ensure that the transportation from SafeBack to EnCase was Correct.
It is of note that I Have mounted the new image in PDE and viewed in X-Ways Forensics, which reported a different CRC32 Hash.
Is there a reconised method for doing this - the upsot is I have SafeBack Images and want to use encase to carry out analysis (I like EnCase, it gives me a warm and Glowy feeling) 😆 , but I need to verify the imaging process.
Thanks in Advance.
😛
When you say different format do you mean sha vs. md5? When you mount evidence files with PDE (and similar applications) you are mounting the logical volume rather than the physical disk. This could account for the different hash. It's also possible that the cache that must be created for dealing with a virtual volume is being hashed as well.
Yes, I should have been clearer in my explanation, correct me if I'm wrong but I beleive that the EnCase hash is MD5 and the SafeBack is CRC32 not SHA. (in the version I have - example being 2ad0e5c6)
On the mounting of the disk, it was the physical disk that had been mounted. An additional test undertaken was to the whole disk that held the restored SafeBack image (not just the Sectors I was interested in) this gave me an Encase image of the entire disk including the slack (if thats the correct term) after the restored Safe Back image.
Using X-Ways Forensics I added the new Encase image file, the physical media of PDE mounted drive.
The MD5 of all three - Acquisition in EnCase, Added image in X-ways and the mounted PDE matched, which I beleive proves that there is no issue with the hash from encase and a further hash of the mounted PDE.
The problem being the CRC32 hash (example above) is the only verification I have of the original Acquisition, I need some way to prove that my translation from SafeBack to Encase has not corrupted the evidence. 😕
Forgive me for sounding like a newbie (afterall, I am) but this is the first time I've come accross this problem.
Thanks for you time and effort.
I'm no expert, but I'm pretty sure that you can't convert CRC32 hashes to MD5, do Guidance Software not provide some kind of update to their software that would allow the use of alternative verification hashes? I'm not a registered user so I couldn't post the question on their boards.
I am currently awaiting a reply from Encase to see if they can suggest a work around, I thought it might be a common problem with a simple answer - how wrong could I be.
🙄
Do you know what version of Safeback was used? A Safeback image should have been accompanied by a sb_audit file which will cantain all that information and it uses SHA256 for the hash in the newest version.
Unknown, we do not pocess the original audit files (we have requested them). Judgeing by the CRC (32 bit) its an old version.
The Problem being Encase, produces an MD5 hash (when acquired from DAT tapes), thus I can not directly compare with the CRC32 I have from the original SafeBack image.
Does anybody know what the CRC of SHAH hash is of that is reported by SafeBack.
Is it of the iamge content (ie all files including Unalloc) or does it take into account the details of the case entered at the original acquisition.
You could send you question off to [email protected] Which is NTI and they distribute Safeback.
For those who run across this post, EnCase now allows users to compute a SHA and MD5 hash of their images. I think this has been the case for several months now.