What Exactly Is The...
 
Notifications
Clear all

What Exactly Is The EnCase 6.19 LEF Verification Hash?

6 Posts
4 Users
0 Likes
1,947 Views
(@nodecaf)
Posts: 5
Active Member
Topic starter
 

This is probably an exceedingly stupid question, but I'm not seeing any answers through Google or EnCase Help and I'd hate get on the stand and not have a good explanation for what it is since our office still actively uses this value to verify our L01s. Where exactly is EnCase deriving this single value from? It's my understanding that LEFs only store the hashes of its encapsulated file(s).

From the bit of testing I've done, it doesn't match the MD5 hash of the .L01 file itself and it doesn't look like it's pulled solely from the contents (at least without some manipulation or additional data rolled in); if I create an uncompressed .L01 in EnCase 7.12 with a single file in it, the verification hash doesn't match the MD5 value of the encapsulated file.

A little background on how we use it whenever our .L01 LEFs get copied from one storage medium to another, our office policy has been to throw the copied LEF into EnCase 6.19.7, let it verify, and save out the report that contains the MD5 "verification hash". If this matches the verification hash value of the source LEF that we generated right after its initial creation, we consider it a sound copy. This all has to be done in 6.19 because the verification hash value has vanished from versions 7 and 8, which makes me a bit suspicious about its validity.

 
Posted : 31/01/2018 3:05 pm
(@hommy0)
Posts: 98
Trusted Member
 

The verification hash for a Logical Evidence File, as far as I understand it, has different functionality to that for the actual evidence file.

Providing a simplified example for the evidence file The acquisition and verification hash for a E01 represent a calculation relating to a source piece of media from a given start sector to a given end sector (where the acquisition is calculated over the live media and the verification relates to the same content, but from within the evidence file)

The verification mechanisms within a LEF are slightly different, and are based on lets say an individual file placed into a LEF container.

As an entry is acquired and added to a LEF this can be MD5 hashed, this then becomes the verification of the individual file within the LEF. If the content of the file within the LEF subsequently changes, so will the MD5 hash of that given file.
EnCase indicates that this entry's hash has altered by placing an * before the MD5 hash of that given entry/file.

This check will occur if you perform verification of said LEF. This functionality I have checked with EnCase 8 (and I believe is the same as EnCase 6.19 - just haven't used that version for a while 😉 )

So to answer the actual question I don't know exactly what the verification hash is calculated over, but I hope this gives a little insight into what can be used to verify the integrity of files within a LEF - but I do not believe it has the same function as the E01

I suppose if you just hash the LEF (treating it as file) with a third party hashing tool, before you copy and then after - this should serve the purpose of verifying the file had not altered in transit.

 
Posted : 31/01/2018 6:41 pm
(@bntrotter)
Posts: 63
Trusted Member
 

I found this article that tries to explain LEFs and hashes.

http//www.forensickb.com/2012/08/encase-enscript-to-verify-lef-colleciton.html

So what is a LEF and how does it work? LEFs differ from an EnCase Evidence File (E01) in that the LEF format only preserves the specific items identified by ether an Examiner or EnScript. When digital evidence is preserved into a LEF, each individual item can be MD5 HASHed and recorded. To further confuse the audience, LEFs can not only preserve files, but can also preserve data from other EnCase sources such as Records and Snapshots. For example, EnCase eDiscovery will preserve E-Mail from an e-mail source (i.e. Exchange) into a "Records LEF."

However, there are some important things an examiner must understand about EnCase LEFs and their limitations. When EnCase preserves files into a LEF, only the allocated space of the selected files is preserved. This means the slack space or initialized space of the target files will be excluded from LEFs (possible with an EnScript?).

When EnCase verifies a LEF, it is validating the recorded MD5 HASH of each individual item with the items current HASH value, along with the CRC for each block in the LEF. There is no real HASH for the entire LEF, as we are used to seeing with full disk images. EnCase will report discrepancies through a dialog for CRC errors or by placing an astrik (*) next to the HASH in the entries pane for each item has a mismatched HASH.

Unfortunately, there is no report that an Examiner can export which explicitly says the items in a LEF passed verification and are valid. To assist with documenting the validity of of items preserved into LEFs, I've written an EnScript for verifying data collected in LEFs. The EnScript simply compares the MD5 hash of each individual file and records the results into a Date Stamped CSV file.

 
Posted : 31/01/2018 7:21 pm
(@randomaccess)
Posts: 385
Reputable Member
 

Just an FYI for LEFs

Dont put an E01 in there. I've had it screw up the E01 upon extraction. I can't remember what happened exactly, but I think it corrupted the L01 and I couldn't extract the image. Not to mention it's slow to extract.

Also, I'm not super keen on archiving to L01, and much prefer md5-ing all of the stored files and saving that hash list. Have had archiving media or the L01 containers fail themselves and there's not much you can do to recover the files. From memory we werent sure if any of the files after L0X were salvagable either - if your media fails and corrupts one of the first in a series of LEF files then you may be in trouble…

 
Posted : 01/02/2018 10:32 am
(@nodecaf)
Posts: 5
Active Member
Topic starter
 

Thank you all for the responses,

If the 6.19 LEF MD5 verification process includes both the file and internal CRC blocks, that would explain why in my testing, the LEF verification value didn't match the MD5 hash of the single file I had placed in it. That certainly seems like a valid way to verify the integrity of an L01 though, so maybe Guidance/OpenText felt it was either redundant or too ambiguous to include in later versions? Either way, I'm glad to have an explanation.

@randomaccess
Noted about your experience with L01s, unfortunately it's our office policy to encapsulate items like memory dumps and cell phone extractions into LEFs and existing policy is like gospel 'round here. I'd have better luck convincing them to physically move our building three feet to the left D .

 
Posted : 01/02/2018 3:05 pm
(@randomaccess)
Posts: 385
Reputable Member
 

@randomaccess
Noted about your experience with L01s, unfortunately it's our office policy to encapsulate items like memory dumps and cell phone extractions into LEFs and existing policy is like gospel 'round here. I'd have better luck convincing them to physically move our building three feet to the left D .

I feel you. Unfortunately it takes a disaster to show the issue.

That being said…maybe if i get bored i'll create an L01 and then modify part of it with a hexeditor and see how much info I lose. It's not a bad idea to use L01s to store stuff, but I'm thinking it's also a good idea to rack the original file as well just in case.

 
Posted : 02/02/2018 6:47 am
Share: