Carver 2.0 Planning Page

From ForensicsWiki
Revision as of 17:58, 28 October 2008 by RB (Talk | contribs)

Jump to: navigation, search

This page is for planning Carver 2.0.

License

BSD (afflib is BSD-4, Sleuthkit has various sublicenses RB)

OS

Linux/FreeBSD/MacOS (shouldn't this just match what the underlying afflib & sleuthkit cover? RB)

Requirements

  • AFF and EWF file images supported from scratch.
  • File system aware layer.
    • By default, files are not carved. (clarify: only identified? RB)
  • Plug-in architecture for identification/validation.
    • Can handle config files,like Revit07, to enter different file formats used by the carver.
  • Ship with validators for:
    • JPEG
    • PNG
    • GIF
    • MSOLE
    • ZIP
    • TAR (gz/bz2)
  • Simple fragment recovery carving using gap carving.
  • Recovering of individual ZIP sections and JPEG icons that are not sector aligned.
  • Autonomous operation (some mode of operation should be completely non-interactive, requiring no human intervention to complete RB)
  • Tested on 500GB-sized images. Should be able to carve a 500GB image in roughly 50% longer than it takes to read the image.
    • Perhaps allocate a percentage budget per-validator (i.e. each validator adds N% to the carving time)
  • Parallelizable.
  • Configuration:
    • Capability to parse some existing carvers' configuration files, either on-the-fly or as a one-way converter.
    • Disengage internal configuration structure from configuration files, create parsers that present the expected structure
    • Either extend Scalpel/Foremost syntaxes for extended features or use a tertiary syntax
  • Can output audit.txt file.
  • Easy integration into ascription software.

Ideas

  • Use as much TSK if possible. Don't carry your own FS implementation the way photorec does.
  • Extracting/carving data from Thumbs.db? I've used foremost for it with some success. Vinetto has some critical bugs :( .FUF 19:18, 28 October 2008 (UTC)
  • Carving data structures. For example, extract all TCP headers from image by defining TCP header structure and some fields (e.g. source port > 1024, dest port = 80). This will extract all data matching the pattern and write a file with other fields. Another example is carving INFO2 structures and URL activity records from index.dat
    • This has the opportunity to be extended to the concept of "point at blob FOO and interpret it as BAR"

.FUF opined: The main idea is to allow users to define structures, for example (in pascal-like form):

Field1: Byte = 123;
SomeTextLength: DWORD;
SomeText: string[SomeTextLength];
Field4: Char = 'r';
...

This will produce something like this:

Field1 = 123
SomeTextLength = 5
SomeText = 'abcd1'
Field4 = 'r'

(In text or raw forms.)

Opinions?

.FUF 20:51, 28 October 2008 (UTC)

Opinion: Simple pattern identification like that may not suffice, I think Simson's original intent was not only to identify but to allow for validation routines (plugins, as the original wording was). As such, the format syntax would need to implement a large chunk of some programming language in order to be sufficiently flexible. RB

Supported File Systems

Build a large list of supported filesystems. File carving programs ignore the filesystem, but this doesn't mean that they support all of them. Do we support Reiser4 with tail packing? Or exFAT? Or NTFS with compression? Document this. .FUF 19:18, 28 October 2008 (UTC)

  • As noted above, TSK should be utilized as much as possible, particularly the filesystem-aware portion. If we want to identify filesystems outside of its supported set, it would be more worth our time to work on implementing them there than in the carver itself. RB