# This file is distributed under the Berkeley 4-part license

Q: Why a new file format? What's wrong with block-by-block?

A: Raw image files take up a lot of space. In many cases this space
   can be dramatically reduced by using compression.
   Unfortunately, if you just use "gzip" or "bzip2" for compression,
   you need to uncompress the entire file in order to use it with a
   forensics program. That's because there is no easy way to "seek"
   within a compressed file.

   The proprietary EnCase file format supports seeking within a
   compressed file, but the specification for this file format is not
   publicly available. Also, EnCase does not allow the storage of
   arbitrary name/value pairs.


Q: Why not put meta information into log files?

A: In many cases it is advantageous to store meta information (such as
   case numbers, acquisition times, the name of the investigator,
   etc.) directly in the image file. For example, storing this
   information in a single file with the image makes it very unlikely
   that they will become separated, and perhaps the wrong log file
   being used with an image.

Q: Will AFF support hashes other than MD5 and SHA-1?

A: Yes. The MD5 hash is stored in a segment named "md5". The SHA-1
   hash is stored in a segment named "sha1". As support for other hash
   functions are added to the OpenSSL library, the "aconvert" and
   "aimage" programs will be updated to automatically calculate and
   store the other hashes in the AFF files.


Q: Are the images directly  mountable so that they can be used with 
   today's forensic tools, or must they be uncompressed for host-based tools to
   work with them?

A: If you have source code for a scanner, you can modify it to use
   af_open() and af_read() instead of fopen() and fread(). You can
   then read the AFF files directly. If you don't have source code,
   but have a scanner that can read from standard input, you can
   use the "affcat" program to copy the contents of an AFF file to
   standard output.

   Eventually, we plan to have a version of samba that is modified to
   transparently mount and serve an AFF file. This will allow
   off-the-shelf Windows executables to be used with AFF archives.


Q: How long do you think it will be before EnCase,
    ProDiscover, FTK, and the open source tools are able
    to process files in this format?

A: I'm currently modifying some of the Open Source tools to handle
   AFF and hope to have an announcement regarding this relatively
   soon. It's actually quite easy to modify an Open Source tool to work
   with AFF: you simply replace the fopen() call with af_open(), fseek()
   with af_seek(), and fclose() with af_close().  

   I've had no contact with the authors of EnCase, ProDiscover, and
   FTK. I imagine that if AFF becomes popular they will modify their
   tools to handle the format. But even if they don't, we plan to
   support those tools through the use of a samba loopback
   filesystem.


Q: Will it be possible to mount an AFF image as a "virtual file
   system" the way you can with EnCase. 

A: Yes, it is quite possible to create a device driver that would
   perform the necessary transformation.  That is how the AFFLIB
   af_read() and af_seek() function calls are implemented. 



Q: Wouldn't it be more efficient to have an index segment, rather than
   having to read through all of the individual AF Headers for each
   segment? 

A: We thought so as well! However, our initial experiments indicated
   that the overhead for doing a seek for every 16MB segment and
   reading a few bytes was quite minimal. The advantage of not having
   to maintain the index is significant. However, if the overhead
   becomes substantial, we can easily add an index segment type. The
   design of AFF allows for an index segment to be added to an
   existing AFF file without changing the contents of the segments
   that contain forensic information.


Q: Its very important for us to have a format which can be written
   into a pipe because that makes acquisition over the network much
   easier.

A: The "aimage" acquisition program currently under development allows
   for acquisition either from an ATA/USB/Firewire device or over a
   network. It allows for discontinuous segments of the disk to be
   acquired at different times and for data to be inserted into a
   single AFF file.