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.
The source code is currently kept under version control on the main PyFlag server. It can be fetched using:
darcs get http://www.pyflag.net/AFF4/
Once the AFF4 directory is downloaded, a configure file needs to be created:
The following libraries are mandatory:
The following are optional but recommended libraries:
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/test.zip /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 autoheader automake autoconf ## Now build it as normal ./configure make installCurrently the Sluethkit patch does not work with autodetection - hence it must be specified explicitely using
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/test.zip default zip.c:51 - FileBackedObject_Con: Can't open file:///tmp/test.zip/__URN__ (Not a directory) libaff4.c:27 - open_volume: Loaded zip volume file:///tmp/test.zip 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: System.map-2.6.22-14-generic 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).