From Forensics Wiki
Revision as of 06:44, 25 April 2009 by Scudette (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

LibAFF4 is an implementation of the AFF4 standard. It is still in a very early stage of development but it allows people to have a play with the new standard. This page documents it.

Obtaining LibAFF4

The source code is currently kept under version control on the main PyFlag server. It can be fetched using:

darcs get

Once the AFF4 directory is downloaded, a configure file needs to be created:

sh ./configure make install

The following libraries are mandatory:

  • openssl-dev
  • uuid-dev

The following are optional but recommended libraries:

  • libcurl4-openssl-dev
  • libfuse-dev

Taking an image

Probably the first step is to actually acquire the image. Right now there is no fancy interface or GUI - its just a simple commandline:

AFF4/tools$ sudo aff4imager -i -o /tmp/ /dev/sda1
Imaging Mode selected
Dumping segment urn:aff4:dd3102c1-370d-4b15-83e7-5a1991b5a9e1/00000000 (55425084 bytes)
Dumping segment urn:aff4:dd3102c1-370d-4b15-83e7-5a1991b5a9e1/00000001 (33314018 bytes)
Dumping segment urn:aff4:dd3102c1-370d-4b15-83e7-5a1991b5a9e1/00000002 (3011613 bytes)
Dumping segment urn:aff4:dd3102c1-370d-4b15-83e7-5a1991b5a9e1/00000003 (51756091 bytes)
Creating a link object 'default' for stream 'urn:aff4:dd3102c1-370d-4b15-83e7-5a1991b5a9e1'

We can see the imager dumping a new zip file with the default settings. By default bevies are 64Mb in size. The aff4imager tool reports each new bevy which is saved to disk and the size it ended up taking (after compression). Finally we see a link object is created to the new stream to make it easier to access it (so we dont need to remember the long URN for it).

Applying the Sleuthkit patch

There is a patch to sleuthkit for adding support to AFF4. The patch is against sleuthkit-3.0.1.

tar -xvzf sleuthkit-3.0.1.tgz
cd sleuthkit-3.0.1
patch -p1 < /path/to/AFF4/patches/sleuthkit-3.0.1.patch

## The following is needed to get the autoconf system to pick up the changes
libtoolize --force
aclocal -I config

## Now build it as normal
make install
Currently the Sluethkit patch does not work with autodetection - hence it must be specified explicitely using
-i aff4

AFF4 is a bit different since it refers not only to a volume, but to a stream within the volume. The convension is to specify the stream as the last parameter after the volumes. So for example, to open the stream created in the example above:

$ fls -i aff4 /tmp/ default
zip.c:51 - FileBackedObject_Con: Can't open file:///tmp/ (Not a directory)
libaff4.c:27 - open_volume: Loaded zip volume file:///tmp/
zip.c:51 - FileBackedObject_Con: Can't open file://default/__URN__ (No such file or directory)
zip.c:51 - FileBackedObject_Con: Can't open file://default (No such file or directory)
libaff4.c:100 - aff4_open: Trying to open stream default relative to all volumes
libaff4.c:107 - aff4_open: Trying urn:aff4:aeb9ed57-8dbe-4506-9fb8-e4106bf0767d/default
libaff4.c:122 - aff4_open: Using urn:aff4:dd3102c1-370d-4b15-83e7-5a1991b5a9e1 as the stream name
d/d 11:	lost+found
r/r 10043:
r/r 6025:	vmlinuz-2.6.22-14-generic
r/r 10041:	config-2.6.22-14-generic
r/r 10042:	abi-2.6.22-14-generic
r/r 13:	initrd.img-2.6.22-14-generic
d/c 44177:	grub
r/r 6029:	initrd.img-2.6.24-21-generic
r/r 12:	initrd.img-2.6.22-14-generic.bak

The debugging messages above are instructive to explain the log of how libaff4 opens the volumes. Since you can specify any number of volumes of the command line you can see that libaff4 first tries to open the volume as a directory volume, if that fails, it tries to open it as a zip file. The last element is assumed to be a volume name and if no such volume is found, its assumed to be a stream name. Then the stream name is searched in all the volumes specified. Finally the stream name is resolved (since its a link it returns the URN of the original stream).