autopsy-flatpak/docs/doxygen/workflow.dox

/*! \page workflow_page General Workflow and Design 

\section design_overview Overview
This section outlines Autopsy design from the typical analysis work flow perspective.
This page is organized based on these phases:
- A Case is created.
- Images are added to the case and ingest modules are run.
- Results are manually reviewed and searched.
- Reports are generated.

\section design_case Creating a Case

The first step in Autopsy work flow is creating a case. This is done in the org.sleuthkit.autopsy.casemodule package (see \ref casemodule_overview for details).  This module contains the wizards needed and deals with how to store the information.  You should not need to do much modifications in this package.  But, you will want to use the org.sleuthkit.autopsy.casemodule.Case object to access all data related to this case.



\section design_image Adding an Image and Running Ingest Modules

After case is created, one or more disk images can be added to the case.  There is a wizard to guide that process and it is located in the org.sleuthkit.autopsy.casemodule package.  Refer to the package section \ref casemodule_add_image for more details on the wizard. Most developers will not need to touch this code though. 

After image has been added to the case, the user can select one or more ingest modules to be executed on the image.  Ingest modules focus on a specific type of analysis task and run in the background.  The results from the ingest module can be found in the results tree and in the ingest inbox.  

The org.sleuthkit.autopsy.ingest package provides the basic infrastructure for the ingest module management.

A list of standard ingest modules that come with Autopsy can be found in:
- org.sleuthkit.autopsy.keywordsearch
- org.sleuthkit.autopsy.recentactivity
- org.sleuthkit.autopsy.hashdatabase
- org.sleuthkit.autopsy.thunderbirdparser

See \ref mod_ingest_page for more details on making an ingest module.


\section design_view Viewing Results

The UI has three main areas.  The tree on the left-hand side, the result viewers in the upper right, and the content viewers in the lower right.  Data passes between these areas by encapsulating them in Netbeans Node objects (see org.openide.nodes.Node).  These allow Autopsy to generically handle all types of data.  The org.sleuthkit.autopsy.datamodel package details with wrapping the org.sleuthkit.datamodel objects as Netbeans Nodes. 
 


Nodes are modeled in a parent-child hierarchy with other nodes.  All data within a Case is represented in a hierarchy with the disk images being one level below the case and volumes and such below the image. 

The tree on the left hand-side shows the analysis results.  Its contents are populated from the central database.   This is where you can browse the file system contents and see the results from the blackboard (see \ref blackboard_page).  The tree is implemented in the org.sleuthkit.autopsy.directorytree package. 

The area in the upper right is the result viewer area.  When a node is selected from the tree, the node and its children are sent to this area.  This area is used to view a set of nodes.  The viewer is itself a framework with modules that display the data in different layouts.  For example, the standard version comes with a table viewer and a thumbnail viewer.  Refer to \ref mod_result_page for details on building a module. 

When an item is selected from the result viewer area, it is passed to the bottom right content viewers.  It too is a framework with many modules that know how to show information about a specific file in different ways.  For example, there are viewers that show the data in a hex dump format, extract the strings, and display pictures and movies.  
See  \ref mod_content_page for details on building new content viewers.



\section design_report Report generation

When ingest is complete, the user can generate reports.  There is a reporting framework to enable many different formats.  Autopsy currently comes with generic html, xml and Excel reports.  See the org.sleuthkit.autopsy.report package for details on the framework and
\ref report_making for details on building a new report module. 


<!--Each reporting submodule implements org.sleuthkit.autopsy.report.ReportModule interface and registers itself in layer.xml

Reporting submodule typically interacts with 3 components:
- org.sleuthkit.autopsy.report.ReportConfiguration - to read current reporting configuration set by the user,
- Blackboard API in org.sleuthkit.datamodel.SleuthkitCase class - to traverse and read blackboard artifacts and attributes,
- an API (possibly external/thirdparty API) to convert blackboard artifacts data structures to the desired reporting format.

Please refer to report.dox and org.sleuthkit.autopsy.report package API documentation for more details on how to implement a custom reporting submodule.
-->



<!-- @@@ MOVE THIS SOMEWHERE ELSE -- the directory tree package maybe??

The component is by default registered with the ingest manager as an ingest event listener.
The viewer first loads all the viewer-supported data currently in the blackboard when Autopsy starts.  
During the ingest process the viewer receives events from ingest modules
(relayed by ingest manager) and it selectively refreshes parts of the tree providing real-time updates to the user.
When ingest is completed, the viewer responds to the final ingest data event generated by the ingest manager, 
and performs a final refresh of all viewer-supported data in the blackboard.


Node content support capabilities are registered in the node's Lookup.
-->

<!-- This is too detailed for here, but maybe should be broken up and put into the sections on making a result viewer and such…

\section design_data_flow Data Flow

\subsection design_data_flow_create Creating Nodes in DataExplorer

Data flows between the UI zones using a NetBeans node. The DataExplorer modules create the NetBeans nodes. They query the SQLite database or do whatever they want to identify the set of files that are of interest. They create the NetBeans nodes based on Sleuthkit data model objects. See the org.sleuthkit.autopsy.datamodel package for more details on this. 

\subsection design_data_flow_toResult Getting Nodes to DataResult

Each DataExplorer TopComponent is responsible for creating its own DataResult TopComponent to display its results. It can choose to re-use the same TopComponent for multiple searches (as DirectoryTree does) or it can choose to make a new one each time (as FileSearch does). The setNode() method on the DataResult object is used to set the root node to display. A dummy root node must be created as the parent if a parent does not already exist. 

The DataExplorer is responsible for setting the double-click and right-click actions associated with the node.  The default single click action is to pass data to DataContent.  To override this, you must create a new DataResultViewer instance that overrides the propertyChange() method. The DataExplorer adds actions to wrapping the node in a FilterNode variant. The FilterNode then defines the actions for the node by overriding the getPreferredAction() and getActions() methods.  As an example, org.sleuthkit.autopsy.directorytree.DataResultFilterNode and org.sleuthkit.autopsy.directorytree.DataResultFilterChildren wraps the nodes that are passed over by the DirectoryTree DataExplorer.

DataResult can send data back to its DataExplorer by making a custom action that looks up it's instance (DataExplorer.getInstance()).

\subsection design_data_flow_toContent Getting Nodes to DataContent

A default DataContent viewer is created when a case is opened. To display the contents of a node, it must be passed to a DataContent instance.  The default single-click behavior of the DataResultViewers is to lookup the default DataContent TopComponent and pass the selected node to it.   See org.sleuthkit.autopsy.corecomponents.AbstractDataResultViewer.propertyChange(PropertyChangeEvent) for details. 

-->

*/