Schatz Forensic

As a part of the AFF4 work I have been involved in, I recently created a set of java bindings for libewf. If you want read access to the block content or metadataof EnCase compatible forensic images from the java programming language then this is for you.

They are currently tested on the windows platform (x86). UNIX and x64 support should be trivial.

They are now included in the libewf repository as libewf-java.

Thanks to Joachim Metz for libewf and David Collett for his python bindings (on which I based my code).

Harlan recently posted a small reference to mounting EWF’s on windows machines using freely available utilities. David Loveall has produced a script called proxy_ewf.py which will do the heavy lifting of mounting EWF’s via imdisk.

It is not straightforward to get working so I have copied the instructions originally provided by David Loveall and further expanded on them below.

1. Extract the Windows mount_ewf files into a directory.  I used the current mount_ewf_windows-20091123.zip file found in the downloads area of libewf. Download from the same place the proxy_ewf.py file and place it in the same directory (I used c:\opt\proxy_ewf\).

2. Download and install the Visual Studio runtime files, if you don’t already have them. Don’t bother as they are now included in the mount_ewf windows distribution.

3. Download and install ImDisk. Be careful about driver loading if you are on Vista and above.

4: Install python for windows. I used python 2.5 (x86) but 2.6 should work as well.

5. If you are on an x64 system, move imdisk.exe from the c:\Windows\system32 directory into the same directory as the mount_ewf and proxy_ewf.py files. The proxy_ewf script wont be able to run imdisk.exe due to the WOW64 file virtualisation features otherwise.

6. Run proxy_ewf:

c:\python25\python c:\opt\proxy_ewf\proxy_ewf-20091123.py c:\evidence\foo.e01

If you get a "Version number mismatch" error, it is likely that the _ctypes.pyd file in the mount_ewf distribution is incompatible with the one in your just installed python distribution. I deleted the one in the mount_ewf directory and things worked fine.

At this point, you should see a new drive letter (or letters) appear in windows explorer.

Last week I had the pleasure of being interviewed alongside Lionel Rattenbury and Julia Jasper, both defence lawyers and members of the Australian Defence Lawyers Alliance (ADLA).

The subject of the interview is fallibility of digital evidence.

This video contains Jason R. Baron, the Director of Litigation of the National Archives and Records Administration (USA) discussing the general problem of electronic discovery, and in particular, the problems of information retrieval in the context of search over billions of documents.

If you are in any way involved in searching for information in a legal context, it is fascinating stuff. 

[via Ralph Losey's e-Discovery Team blog]

I posted earlier about a new forensic container format being created by myself, Michael Cohen, and Simson Garfinkel. A paper describing the work was presented at DFRWS 2009 by Michael.

Michael and I have recently extended and refined the container format to support describing the provenance of information and data, and more accurate description of evidence characteristics. A paper describing this work, titled “Refining the AFF4 evidence container for provenance and accurate data representation”, has been accepted for presentation at the 6th Annual IFIP WG 11.9 conference on Digital Forensics.

The abstract follows:

It is well acknowledged that there is a pressing need for a general solution to the problem of storage of digital evidence, both in terms of copied bit-stream images and general information which describes the images  and  surrounding  context  of  the  case.  In  a  prior  paper,  the  authors  introduced  the  AFF4 evidence container format, focusing in particular on the description of the efficient and layered bitstream storage  architecture,  a  general  approach  to  representing  arbitrary  information,  and  a  compositional approach  to  managing  and  sharing  evidence.  In  this  paper  we  describe  our  work  refining  the representation  schemes  embodied  in  the  new  format,  addressing  the  accurate  representation  of discontiguous data and description of the provenance of both data and information. 

The following video shows an experimental interactive memory debugger and visualiser called ICU64, running against the  Frodo C64 emulator. 

The video below shows an interactive exploration of the memory space of the emulated C64 while it runs the game “Cataball”, pointing out correspondences between the raw memory and the on-screen action.

Hex editor authors and forensic tool manufacturers should take note of the zoomable memory map.

[via Root Labs Rdist]

In late June I wrote about the forged email that had been at the heart of a political scandal. Mr Godwin Grech at the time claimed he had received an email from the office of the Prime Minister of Australia pushing for preferential treatment of a friend of the PM. The Australian Federal Police raided Mr. Grech’s home and found the email in question, deleted, on his home computer. They pronounced it a fake.

Today, The Australian is reporting that Mr. Grech last night admitted to having faked the email.  Mr. Grech claims that he recollected receiving an original email similar to the one in question. Unable to find the original, he concocted the fake one in order to substantiate verbal claims he had made about the matter.

An excellent visual summary of computer hardware connectors. The original is sonic840’s Computer Hardware Poster.

[via Hack a Day]

It has been a few months since I last looked at Kowari. My motivations currently are in using a persistent OWL implementation, or at least a persistent RDF store. Kowari’s graph traversal ITQL operations are particularly of interest and look promising, and Paul Gearon, one of the core developers, seems to be working hard on the OWL implementation.

Last time I looked at Kowari, which was a few months ago, it was a tedious process getting it to run inside of Eclipse. I have become accustomed to simply pointing the Eclipse source path at the /src directory in any particular source distribution, and importing all of the jars in the /lib directory, and it all simply working. Not in this case.

The Kowari source code is organised over upwards of 30 separate source folders. When I simply imported all of these folders into eclipse there were serious shadowing problems. For some reason, (which I suspect are an artifact of having a couple of copeting implementations in the source tree, which were configured buy the ant build) there were a number of classes with the same name and package in multiple folders.

Happily, things have improved for the better. Digging into the scr/jar and src/war folder heirarchies reveals folders called “java” which can be imported as eclipse source paths without issue. The only real gotcha here is that a number of source files are generated, and not packaged with the source distro. Running the ant build in situ fixes that. At this point one can add obj/jar/config/java and obj/jar/itql/java to the build path.

At this point the eclipse should be able to build all of the most base parts, as long as you import all of the libraries in lib. A number of errors will be visible due to missing 3rd party libraries.

Running Kowari was a little more tricky. Here is how to do it.

Created a reate a run configuration with main class org.kowari.server.EmbeddedKowariServer. For the command line, I appended the following (adjust the path to suit):

-c file:///D:/mysrc/kowari-1.1/conf/kowari-config.xml

The following are needed VM arguments (again, adjust the path to suit):

-Djava.security.policy=file:///D:/mysrc/kowari-1.1/conf/kowari-rmi.policy
-Dorg.kowari.xml.ResourceDocumentBuilderFactory=org.apache.xerces.jaxp.DocumentBuilderFactoryImpl
-Djava.naming.factory.initial=com.sun.jndi.rmi.registry.RegistryContextFactory
-Djava.naming.provider.url=rmi://localhost
-Dlog4j.configuration=file:///D:/mysrc/kowari-1.1/log4j-conf.xml

The final trick is to copy the conf directory into whatever your eclipse build directory is (my default is kowari-1.1/classes). This is typically the /bin directory.

My next try was to get the org.kowari.itql.ItqlSession unit test to run. Most of it currently runs without issue, although I am getting failures on testSelect7, and all of hte testLoadAPI, testBaskup, testLoadBackup, and testRestore unit tests. I havent looked into the reasons for this in any detail. In order to get this to run, you will need the VM argument

-Dcvs.root=D:/mysrc/kowari-1.1

The ITQL interpreter, org.kowari.itql.ItqlSession seems to run without any commmand line or VM arguments, although I havent yet tested actually using it. I will update this when I have.

Getting the MP3 demo application required me to run the ant build target

>ant demo-mp3-config-generate

And then adding the obj/jar/demo-mp3/java to the source folders. The MP3 applicatoin is run from the class org.kowari.demo.mp3.swing.Mp3Application with the argument the relative path to the config file: conf\mp3-config.xml. This should be in your classes/conf dir.

The mp3-config.xml file needs to be edited as below

type =”http://tucana.org/tucana#Model”>

Finally I had to copy the icons in the images directory of demo-mp3 into the /classes directory.