XML in Forensics: DEX

In their 2009 paper 'DEX: Digital evidence provenance supporting reproducibility and comparison', Levine and Liberatore refer to Alink, Garfinkel and Turner's past works (as also documented here, here and here) in attempting to develop a file format suitable for presenting as evidence in forensic cases.

They initially criticise the fact that the tools that provide the greatest amount of support (and by inference are commercial and closed-source) are the same tools that require the end user to trust the tools blindly, with no easy way of verifying that the output is valid. Therefore, they propose (as both Garfinkel and Turner before them already did) a format that is independant of the forensic tool itself: DEX, or Digital Evidence Exchange.

"A DEX description of evidence is sufficient for a third party using an independently developed tool to quickly extract the same evidence and verify that the reproduction is correct according to a known specification."

(p. S49)

They also note the importance of the work that preceeded their own:

"The description by Garfinkel et al. of AFF ... provides a good survey of many other image formats, including EnCase, FTK, ILook, and more."

(p. S50)

An advantage of the file format is that the data stored within it need not come from a single source (unlike a situation where the data is an image file and additional metadata, as is the case with many other tools). A key result of this is that is therefore possible to append further data to an existing DEX file.

Unlike the DEB format, DEX does not require a log of alterations to the file and/or examinations of the evidence; it also keeps no information on the individual who processed the evidence. Although this might be seen by some as a disadvantage, the DEX file itself contains enough information to allow its content to be verified against the original evidence anyway. Any logging can therefore be done via access to the source data - the physical drives, for example - which can be handled through normal law enforcement procedures.

The format is also explictly designed to allow files to be processed through multiple disparate tools to provide analysis that one tool alone may not be capable of. It is this that makes it ideal as a native format for VeRa's data:

• For input, allow the user to specify a DEX file alongside images and/or filesystems.
• The initial analysis tools can parse the data in the images and add them to the existing DEX data (or create a new DEX file).
  
• The visualisation tool can then display the data from the DEX file, allow it to be narrowed down to the relevant data (e.g. only files handled between specific dates), and then output to a new DEX file.

It also means that, at least in theory, any tools that can manipulate or visualise DEX data can be integrated directly into VeRa, as long as they can be adapted to run within the .NET runtime.

See: Levine, B; Liberatore, M (2009). DEX: Digital evidence provenance supporting reproducibility and comparison. Digital Investigation, Volume 6 (2009), p.S48-S56