Should the tool compute hashes for decoded data?

[lfcnassif]

I would like to start this important discussion, in my opinion.

Currently, IPED computes hashes for regular files (allocated, deleted, carved, embedded in containers) and for some data blocks, like unallocated clusters and file fragments.

There are other 2 kinds of information the tool produces, we could call decoded data, usually produced by parsers when decoding some file (or a set of them).

Database records, examples:

• internet history entries extracted from browser databases
• instant messages extracted from chat apps
• call log entries from cellphones

Summary reports or previews, examples:

• conversation reports from the IM apps (putting IM messages together)
• windows registry reports
• email previews from PST/OST files (different from EML/MSG files)

The question is: Should the tool compute hashes for all information above or for some of them? Currently IPED does not compute hashes for database records. How should a hash be computed for an IM message? Concatenating sent date, from, to and text body? Changing the order of those fields would change the hash. That information can result from decoding different tables, making joins and even collecting info from different files. Today the tool doesn't compute hashes for that kind of info, but some users think the tool should, to filter duplicated entries by hash or to verify if the integrity of the decoded information is preserved through the chain of custody. But I don't know if it makes sense to compute hashes for database records, I think most tools don't do this.

About parsing reports or html previews created by the tool (from registry, IM conversations, PST emails) today IPED does compute hashes. But this kind of artifact isn't a regular file, it is a report produced by the tool with parsing results. Other tools would create different reports, with different hashes. Even different IPED versions could create different reports from the same information source, resulting in different hashes, just changing the report formatting style for example. I'm not sure if the tool should continue to hash those reports...

Opinions from users and developers are very welcome!

[rodrigohunk]

Database records: I agree with you, no hashes.
Reports and previews: If it remains easy to track its source, no hashes too.

[hauck-jvsh]

For database records, I also agree with you, no hashes, but for Reports and previews I think that the current behavior may be useful, for example when an user export the HTML file and want to know if it was intact it can compute its hash and compare with the hash in IPED report.

[lfcnassif]

But single database records could be also exported by user and put in case reports. A txt file with some fields concatenated is created. Would the same hash checking idea be valid in this scenario?

[hauck-jvsh]

I didn't know that database records could also be exported. I think the hash could be used for this too, but, in general, as it is a much smaller piece of information the user should export the entire database, not only the record.

[PsitGit]

Calculate for everything.
Then create another "alert" field that shows if that hash is from an "original/easily reproducible" or not. Call that field whatever you wanna, just put an good explanation on an help file item.

[paulobreim]

I think the hash should be calculated just under the regular files.

By the way, is the media hash calculation (dd) performed? If yes, where is it?

I ask this because I've had a situation, that when checking the hash of a HD that had been cloned 2 years ago, it wasn't the same. Then I calculated the hash of each file that was of interest and compared it to the original to make sure these files were valid.

[lfcnassif]

By the way, is the media hash calculation (dd) performed? If yes, where is it?

It isn't. Since all contained files are already hashed, it could increase the hashing time by 2x (or maybe by 3x or 4x if partitions and file systems are also hashed), so it was decided in the past to don't do this...