Package Contents

Overview

All data in a case will be stored in a single database and configuration file. A case must be open before analysis can occur. You will use a Case object to get access to the data being analyzed.

Case settings are stored in an XML file. See the XMLCaseManagement class for more details.

Currently, only one case can be opened at a time. To determine the open case, use the Case.getCurrentCase() method.

Do not cache the case handle object obtained from this method (for example, in member variables) unless you are sure your are acting within case context; It is safer to call the method more frequently to ensure the validity of the case handle object as new cases are opened.

Once you have the object for the currently open case, Case.getRootObjects() will return the top-level Sleuth Kit Content modules. You can then get their children to go down the tree of data types.

Case Events

To receive an event when cases are opened, closed, or changed, use the Case.addPropertyChangeListener(PropertyChangeListener) method to register your class as a PropertyChangeListener. This is most commonly required when developing a new module that needs to get data about the currently opened case.

Add Image Process

The sleuthkit library performs most the actual work of adding the image to the database and Autopsy provides the user interface, calls methods to set up and control and finalize the process.

Add image process is first invoked by AddImageAction. AddImageWizardIterator instantiates and manages the wizard panels.

A background worker thread is spawned in AddImgTask class. The work is delegated to org.sleuthkit.datamodel.AddImageProcess, which calls into native sleuthkit methods via SleuthkitJNI interface.

The entire process is enclosed within a database transaction and the transaction is not committed until user finalizes the process. User can also interrupt the ongoing add image process, which results in a special stop call in sleuthkit. The stop call sets a special stop flag internally in sleuthkit.

The flag is checked by the sleutkit code as it is processing the image and, if set, it will result in breaking out of any current processing loops and methods, and return from sleuthkit. The worker thread in Autopsy will terminate and revert will be called to back out of the current transaction. During add image process, sleuthkit library reads the image and populates the TSK SQLite database with the image meta-data.

Concurrency and locking

Autopsy is a multi-threaded application; besides threads associated with the GUI, event dispatching and Netbeans RCP framework, the application uses threads to support concurrent user-driven processes. For instance, user can add another image to the database while ingest is running on previously added images.

During the add image process, a database lock is acquired using org.sleuthkit.datamodel.SleuthkitCase.dbWriteLock() to ensure exclusive access to the database resource. Once the lock is acquired by the add image process, other Autopsy threads trying to access the database as acquire the lock (such as ingest modules) will block for the duration of add image process.

The database lock is implemented with SQLite database in mind, which does not support concurrent writes. The database lock is released with org.sleuthkit.datamodel.SleuthkitCase.dbWriteUnlock() when the add image process has ended. The database lock is used for all database access methods in org.sleuthkit.datamodel.SleuthkitCase.