Join Us!

Notifications
Clear all

EnCase image format  

  RSS
dirk
 dirk
(@dirk)
Junior Member

Hi all.

I'm writing code to read EnCase image files. I found this site which seems to be out of date because the format they describe isn't what I'm seeing when I read the image file
http//www.asrdata.com/SMART/whitepaper.html

The real image format has new "disk" and "hash" sections which I would also like to read.

Is there any accurate documentation on this format?

Quote
Posted : 02/05/2006 8:37 am
JonN
 JonN
(@jonn)
Member

Dirk

I don't know in depth about EnCase evidence files, all I know is that there is a case info bit at the beginning, the acquired data in 64 sector chunks all with CRC values at the end, and then the MD5 value at the end of the image file.

The site you have been to, asrdata, is the site of Andy Rosen, who was the original author of Expert Witness, along with the guy who then went on to develop what we now know as EnCase. What you see on his site is the Expert Witness image format, which may differ from the present EnCase format.

I know when we went over to version 5 from version 4 that there were some issues with the image format, and there certainly were with the version 5 format and FTK at first.

I guess it may boil down to how clever you are, it must be reverse engineerable because FTK, Andy Rosen's SMART Linux and other forensic products can use the format.

HTH

Jon

ReplyQuote
Posted : 02/05/2006 1:31 pm
dirk
 dirk
(@dirk)
Junior Member

I don't know in depth about EnCase evidence files, all I know is that there is a case info bit at the beginning, the acquired data in 64 sector chunks all with CRC values at the end, and then the MD5 value at the end of the image file.

The case info part was easy, as most of that hasn't changed. New fields "av" (application version?) and "ov" (operating system version?) were added to that section, but it was easy to process because it's just tab-separated values, zlib-compressed.

As for 64-sector chunks, it seems to depend. There is a field that gives the number of sectors per chunk, and I've been using that instead of making assumptions. Allegedly, EnCase 5 changed the acquisition tool so that the number of sectors isn't necessarily 64 anymore.

The table sections are almost the same as what's described. However I've noticed that many sections are not compressed (easy to spot because they don't start with the zlib compression header.) The length of these chunks is always 32772 which is 64 sectors plus 4 bytes. I figure it's the sector data plus a checksum, but it isn't the same checksum that they use everywhere else because I tried that already.

Of course, I could read the entire file with no regard for integrity, and probably get all the data out okay. But I figure the integrity checks were put there for a reason, so I would be better off checking them.

ReplyQuote
Posted : 03/05/2006 5:21 am
dirk
 dirk
(@dirk)
Junior Member

Well, after enough buggering around, I eventually determined that everything that isn't compressed is actually using the Adler32 checksum (not a CRC), and in fact the other checksums are all Adler32 as well, which is convenient because Java already has that checksum in its standard library.

I'm still a bit baffled as to why the two sample files are so vastly different in their contents though.

ReplyQuote
Posted : 04/05/2006 6:49 am
Marat
(@marat)
Junior Member

dirk,
you can see some info in aff doc(afflib.org),also some info have pyflag
project web-site,and from pyflag you can download small cmd tool(win based)for convert encase image file to raw image.

ReplyQuote
Posted : 04/05/2006 2:48 pm
dirk
 dirk
(@dirk)
Junior Member

I was actually looking for PyFlag earlier. It seems the entire site is broken today; managed to get to the front page, but couldn't get in there to read the source code.

ReplyQuote
Posted : 05/05/2006 11:00 am
Share: