I finished uploading a new version of the toolkit, we added several new features aswell as fixed some minor bugs. The new version now has a DD Image Concatination utility to combine all the segments of smaller images(from FTK imager) into one large image file to work with the program. Also the Carve Engine now has a hex toolbar to view the retrieved file in hex and ascii.
Thanks for all of the posts sofar.
the website is
Ryan Manley
But most importantly DD image concatenation working with MMachor we have found a way to make a forensically sound DD concatenation utility that verifies the data using SHA256.
I'm not sure I follow…if I acquire a dd image in 2GB segments, and then concatenate those segments together on Windows using the 'type' command, how is that not "forensically sound"? How about loading the image segments into FTK Imager, and 'acquiring' a full image?
As most utilities use MD5, how is the SHA256 hash more valuable?
Thanks.
Ah, I see. Its not that concatenating them using the type command would not be forensically sound, just that this is a way of showing that it is with a hash verification. While working in this field we did use FTK Imager to aquire a full image from pieces. The DD Concat feature of this works I'm sure on the same principal, but in much testing has been found to be much faster than FTK Imager. As far as the MD5 vs. SHA256, this is being done using a function in Visual Basic that buffers the information into a single hash from multiple files. It does not include this function for anything less than SHA256. I had originally tried to do this using MD5, but found that it was not possible. The idea behind this function is to provide a hash verification that shows that none of the data had been changed while the concat process was taking place. Something that could be presented as evidence of this.
As most utilities use MD5, how is the SHA256 hash more valuable?
Thanks.
Maybe not valuable to the forensic analyst but perhaps valuable to the organisation paying for the investigation. The widely published engineering of MD5 collisions and existence of MD5 rainbow tables could be used 'by the other side' to raise doubt in the minds of a jury. The likelihood of lack of integrity in MD5 hashing is immaterial in such situations. SHA hashing doesn't carry that risk.
Jonathan,
Maybe not valuable to the forensic analyst but perhaps valuable to the organisation paying for the investigation. The widely published engineering of MD5 collisions and existence of MD5 rainbow tables could be used 'by the other side' to raise doubt in the minds of a jury. The likelihood of lack of integrity in MD5 hashing is immaterial in such situations. SHA hashing doesn't carry that risk.
It's interesting that you raise this point…because we all know it's bunk.
MD5 collisions are going to affect the integrity of an acquired image…how? Are you suggesting that someone could take a 60GB image out of evidence, mount it, add CP images to it (or overwrite legit image files in the image with CP) in such a way as to create a hash collision for the entire image?
MD5 rainbow tables are going to affect the integrity of an acquired image…how? The fact is…they aren't. What are rainbow tables for? They're for attempting to brute force strings (i.e., passwords) that have been one-way hashed. That's hard enough to do with 8 - 12 characters/bytes…imagine how long that would take w/ a 20GB image. And what would be the point in the end?
I agree that raising these issues would cast doubt…but not in the way you think. Defense counsel raising these issues, particularly in the face of evidence handling procedures, would raise doubt in the minds of the jury and the court…as to the competence of the defense counsel.
Its not that concatenating them using the type command would not be forensically sound, just that this is a way of showing that it is with a hash verification. While working in this field we did use FTK Imager to aquire a full image from pieces. The DD Concat feature of this works I'm sure on the same principal, but in much testing has been found to be much faster than FTK Imager.
So, it's not an issue of being 'forensically sound', as much as one of simply being faster? Would that be correct?
As far as the MD5 vs. SHA256, this is being done using a function in Visual Basic that buffers the information into a single hash from multiple files. It does not include this function for anything less than SHA256. I had originally tried to do this using MD5, but found that it was not possible.
Okay, from this, my understanding is that SHA256 was chosen because that's what was supported by Visual Basic. Would that be correct?
I'm not saying that I think that there's anything wrong with that…I'm simply trying to understand the statements that've been made. After all, there are tools that use MD5, or MD5 in combination with SHA-1. You could also use Whirlpool, Tiger, or fuzzy hashing.
The idea behind this function is to provide a hash verification that shows that none of the data had been changed while the concat process was taking place. Something that could be presented as evidence of this.
Oh, I understand that, thanks. It's about verifying the integrity of the data.
Yes, its both the authentication that the hash values give and doing it faster than what I have otherwise seen.
The hash value is one that is hard to explain. I could have used any number of hash algorithms available. Anything from CRC32 to SHA, MD5, Tiger, Whirlpool, or any other. Here is where the issue is. Say you have a DD image that is in 1.5 GB pieces and totals oh lets say 132 pieces rather than creating 132 separate hashes. What I've done is created a way to generate a single hash value of all 132 pieces. This is done before any concatenation takes place. The idea is that I have now a single hash value, concatenate and take the same hash of the final concatenated image. Compare the two values, and if they match you have verified the integrity. The way to do a single hash of 132 files (or any number) required the usage of SHA256. Again I take no offense to the question, I had a feeling it would generate some questions as to why that particular hash had been used. It was the one that supported the ability to join multiple files into one hash value.
It doesn't take much to be faster than FTK Imager. It is not performance optimized in my testing. (
Cheers!
farmerdude
Get SMART
It doesn't take much to be faster than FTK Imager. It is not performance optimized in my testing. (
Cheers!
farmerdude
Get SMART
www.onlineforensictraining.com
www.forensicbootcd.com
D
Hey Thomas,
How the heck are you.
You are right, you have to love SMART. But even Andy has been looking at a new Windows based system. You might take a look at this tool. It is a nice package.
Len Drinkard
The Demonstration Version has been revised, many of the restrictions have changed to allow all features to be functional to an extent. Features that do not have these limitations are the Imaging functions, and the DD Concat. feature mentioned in earlier posts.
Restrictions
Every other line is Labeled Demonstration Version on many functions, Carving Engine only returns 1 out of every 4 or 5 lines and replaces others with "Demonstration"
Thumbnail Carving - Limited to 20 results
USB Write Blocker Disabled.
The demo can be downloaded again from the site
Thanks Len, How is class going?
Ryan Manley
Wise Forensics, LLC