Difference between pages "Encase image file format" and "AFF Development Task List"

From Forensics Wiki
(Difference between pages)
Jump to: navigation, search
 
(High Priority)
 
Line 1: Line 1:
[[EnCase]] uses a closed format for images which is reportedly based on [http://www.asrdata.com/SMART/whitepaper.html ASR Data's Expert Witness Compression Format]. The evidence files, or E01 files, contain a physical bitstream of an acquired disk, prefixed with a '"Case Info" header, interlaced with CRCs for every block of 64 x 512 byte sectors (32 KiB), and followed by a footer containing an MD5 hash for the entire bitstream.  Contained in the header are the date and time of acquisition, an examiner's name, notes on the acquisition, and an optional password; the header concludes with its own CRC.
+
== High Priority ==
  
EnCase can store media data into multiple evidence files, which are called segment files. Each segment file consist of multiple sections. Each section consist of a section start definition. This contains a section type.
+
* Create man pages and/or documentation for AFF toolkit. To wit:
  
Up to EnCase 5 the segment file were limited to 2 GiB, due to the internal 31-bit file offset representation. This limitation was lifted using a base offset work around in EnCase 6.
+
* [[aimage]]
 +
* [[ident]]
 +
* [[afcat]]
 +
* [[afcompare]]
 +
* [[afconvert]]
 +
* [[affix]]
 +
* [[affuse]]
 +
* [[afinfo]]
 +
* [[afstats]]
 +
* [[afxml]]
 +
* [[afsegment]]
  
At least from Encase 3 the case info header is contained in the "header" section, which is defined twice within the file and contain the same information.
+
* Add a usage description to [[afcat]]. When run with no arguments the output should say what the program does.
  
With Encase 4 an additional "header2" section was added. The "header" section now appears only once, but the new "header2" section twice.
+
* Create man pages and/or documentation for AFF library functions (e.g. ,<tt>af_open</tt>, <tt>af_get_imagesize</tt>)
  
Version 3 of The Encase F introduced an "error2" sections that it uses to record the location and number of bad sector chunks. The way it handles the sections it can't read is that those areas are filled with zero. Then Encase displays to the user the areas that could not be read when the image was acquired. The granularity of unreadable chunks appears to be 32K.
+
* Build library as a shared library using libtool. This will allow developers using the library to just link to the AFF. Without it, developers must link to the static library and the individual libraries necessary <em>on that machine</em>. There is no good way to determine those extra libraries.
  
Within Encase 5 the amount of sectors per block (chunk) can vary.
+
* Document that <tt>af_write</tt> may not be called without first setting the <tt>image_pagesize</tt> value inside of the <tt>AFFILE</tt> structure. Not doing so causes a divide by zero error. Perhaps we should 1. Check that <tt>image_pagesize</tt> is not zero and 2. Set <tt>image_pagesize</tt> to a known good default value when opening a new AFF file for writing.
  
Encase from at least in version 3 can hash the data of the media it acquires.
+
* Check aimage ability to write a file of 1,073,741,825 bytes ((2**30)+1). Correctly reported reading/writing a file that was a 1,073,741,824 random byte stream, but did not pick up the extra byte when it was added to the file. ls -la correctly shows the size with the extra byte. Also, added 42 additional bytes which were not apparently read or written.  UPDATE - With 511 bytes added, still didn't read/write full file, however, adding 512 bytes did cause the whole file (1,073,742,336 bytes) to be read/written.
It does this by calculating a MD5 hash of the original media data and adds a hash section
+
to the last of the segment files. Later versions of EnCase 6 also include a SHA1 hash.
+
  
== See Also ==
+
== Medium Priority ==
  
[[EnCase]]
+
* How about renaming the library to libaff? That would allow developers to link with <tt>-laff</tt> instead of <tt>-lafflib</tt>. To my knowledge, there is no existing library named AFF already.
 +
:: Response: The problem with doing this is that we have AFFLIB.ORG; AFF.ORG is the Arab Film Festival.
  
== External Links ==
+
* Is there a set of segment names that must be defined to have a ''valid'' AFF file?
  
* [https://downloads.sourceforge.net/project/libewf/documentation/EWF%20file%20format/Expert%20Witness%20Compression%20Format%20%28EWF%29.pdf Expert Witness Compression Format (EWF)].
+
* Document that <tt>af_open</tt> (when writing a file) does more than a standard <tt>fopen</tt> command. The command writes an AFF stub of some kind to the output file. Users should be cautioned not to use this function as a test, lest they overwrite data.
* [http://www.cfreds.nist.gov/v2/Basic_Mac_Image.html Sample image in EnCase, iLook, and dd format] - From the [[Computer Forensic Reference Data Sets]] Project
+
  
[[Category:Forensics File Format]]
+
* Does <tt>af_open</tt> refuse to open a file for writing if it already exists? If so, what kind of error does it return?
 +
 
 +
* Document how to programmatically enumerate all segments and values in a file. That is, explain how to get the output of <tt>$ afinfo -a</tt>.
 +
 
 +
== Low Priority ==
 +
 
 +
* Add library function to open standard input. Perhaps:
 +
 
 +
<pre>AFFILE * af_open_stdin(void);</pre>

Revision as of 09:39, 3 August 2007

High Priority

  • Create man pages and/or documentation for AFF toolkit. To wit:
* aimage
* ident
* afcat
* afcompare
* afconvert
* affix
* affuse
* afinfo
* afstats
* afxml
* afsegment
  • Add a usage description to afcat. When run with no arguments the output should say what the program does.
  • Create man pages and/or documentation for AFF library functions (e.g. ,af_open, af_get_imagesize)
  • Build library as a shared library using libtool. This will allow developers using the library to just link to the AFF. Without it, developers must link to the static library and the individual libraries necessary on that machine. There is no good way to determine those extra libraries.
  • Document that af_write may not be called without first setting the image_pagesize value inside of the AFFILE structure. Not doing so causes a divide by zero error. Perhaps we should 1. Check that image_pagesize is not zero and 2. Set image_pagesize to a known good default value when opening a new AFF file for writing.
  • Check aimage ability to write a file of 1,073,741,825 bytes ((2**30)+1). Correctly reported reading/writing a file that was a 1,073,741,824 random byte stream, but did not pick up the extra byte when it was added to the file. ls -la correctly shows the size with the extra byte. Also, added 42 additional bytes which were not apparently read or written. UPDATE - With 511 bytes added, still didn't read/write full file, however, adding 512 bytes did cause the whole file (1,073,742,336 bytes) to be read/written.

Medium Priority

  • How about renaming the library to libaff? That would allow developers to link with -laff instead of -lafflib. To my knowledge, there is no existing library named AFF already.
Response: The problem with doing this is that we have AFFLIB.ORG; AFF.ORG is the Arab Film Festival.
  • Is there a set of segment names that must be defined to have a valid AFF file?
  • Document that af_open (when writing a file) does more than a standard fopen command. The command writes an AFF stub of some kind to the output file. Users should be cautioned not to use this function as a test, lest they overwrite data.
  • Does af_open refuse to open a file for writing if it already exists? If so, what kind of error does it return?
  • Document how to programmatically enumerate all segments and values in a file. That is, explain how to get the output of $ afinfo -a.

Low Priority

  • Add library function to open standard input. Perhaps:
AFFILE * af_open_stdin(void);