1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
|
# 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.
|
