mstoeck3/autopsy-flatpak
1
0
Fork 0
mirror of https://github.com/overcuriousity/autopsy-flatpak.git synced 2025-07-06 21:00:22 +00:00
Code Issues Packages Projects Releases Wiki Activity

doc updates

Browse Source
This commit is contained in:
adam-m 2012-07-05 13:08:02 -04:00
parent 0b6dc8f6cf
commit d4989dde08
2 changed files with 19 additions and 16 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

22
Ingest/src/org/sleuthkit/autopsy/ingest/package.dox
View File

@ -3,12 +3,14 @@
*
* The package provides the ingest module framework; the framework defines how ingest modules should behave and provides the infrastructure to execute them.
*
* Different ingest modules module generally have its own specific role.
*
* The two main use cases for ingest modules are:
* - to extract information from the image and write result to blackboard,
* - to analyze data already in blackboard and add more information to it.
*
* Different ingest modules generally specialize in extracting or analyzing different type of data.
*
* There may also be special-purpose ingest modules that run early in the ingest pipe-line. Results posted by such modules can useful to subsequent modules.
* There may also be special-purpose core ingest modules that run early in the ingest pipe-line. Results posted by such modules can useful to subsequent modules.
* One example of such module is Hash DB module, which determines which files are known; known files are generally treated differently.
* For instance, processing of known files can be skipped by subsequent modules in the pipeline (if chosen so), for performance reasons.
*
@ -19,6 +21,8 @@
* org.sleuthkit.autopsy.ingest.IngestServiceImage services run each in a separate thread, in parallel with respect to other image services.
* File services execute within the same worker thread and they run in series; for every file in the image every file ingest service is invoked.
*
* Every ingest thread is presented with a progress bar and can be cancelled by a user, or by the framework, in case of a critical system event (such as Autopsy is terminating, or an unrecoverable system error).
*
* org.sleuthkit.autopsy.ingest.IngestServiceAbstractFile services are singleton instances
* and org.sleuthkit.autopsy.ingest.IngestServiceImage service are not singletons. There could be multiple instances of
* an image based service, because multiple images can be analyzed at the same time by multiple instances of the same image service class
@ -29,19 +33,17 @@
*
* The framework also contains classes:
* - org.sleuthkit.autopsy.ingest.IngestManager, the ingest manager, responsible for discovery of ingest modules, enqueuing work to the modules, starting and stopping the ingest pipeline,
* propagating messages sent from the ingest modules to other Autopsy components and is used to query ingest status.
* - org.sleuthkit.autopsy.ingest.IngestManagerProxy, a facility (IngestManager facade) used by the modules to communicate with the manager,
* propagating messages sent from the ingest modules to other Autopsy components, querying ingest status.
* - org.sleuthkit.autopsy.ingest.IngestManagerProxy, IngestManager facade used by the modules to communicate with the manager,
* - additional classes to support threading, sending messages, ingest monitoring, ingest cancellation, progress bars,
* - a user interface component (Ingest Inbox) used to display interesting messages posted by ingest modules to the user,
*
*
* Ingest modules run in background threads. There is a single background thread for file-level ingest modules, within which every file ingest module runs series for every file.
* Image ingest modules run each in their own thread and thus can run in parallel (TODO we will change this in the future for performance reasons, and support image ingest module dependencies).
* Every ingest thread is presented with a progress bar and can be cancelled by a user, or by the framework, in case of a critical event (such as Autopsy is terminating, or a system error).
*
* Ingest module can maintain internal threads for any special processing that can occur in parallel.
* However, the module is then responsible for creating, managing and tearing down the internal threads and to implement locking to protect critical sections internal to the module.
* An example of a module that maintains its own threads is the KeywordSearch module.
* However, the module is then responsible for creating, managing and tearing down the internal threads
* and to implement locking to protect critical sections internal to the module.
* An example of a module that maintains its own threads is the KeywordSearch module,
* which provides a periodic refresh of search results as data is being indexed by the main file ingest thread.
*
* org.sleuthkit.autopsy.ingest.IngestManager provides public API other modules can use to get ingest status updates.
* A handle to ingest manager singleton instance is obtained using org.sleuthkit.autopsy.ingest.IngestManager.getDefault().

13
docs/doxygen/design.dox
View File

@ -59,21 +59,22 @@ The directory tree (in the left-hand panel of the Autopsy viewer)
is the results viewer for the results saved in the database during ingest process.
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 bloackboard when Autopsy starts.
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 services
(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.
Data presented is encapsulated in node objects org.openide.nodes.Node before it is displayed in the UI.
Nodes contain property sheets to store data and are organized in a parent-child hierarchy with other nodes.
The hierarchy is used to visually represent the data and to trigger child node updates whenever the parent node is selected by the user.
Data presented is encapsulated in node objects (org.openide.nodes.Node) before it is displayed in the UI.
Nodes use property sheets to encapsulate data (blackboard attributes) and are modeled in a parent-child hierarchy with other nodes.
The hierarchy is used to visually represent the data and to trigger child node updates when the parent node is selected.
Node child factories are invoked by the Netbeans framework at the time of parent node selection to populate and refresh the child node view.
User normally initiates result navigation in the directory tree.
When a node is selected, it is passed in to the table result viewer (top-right).
When a node is selected in the table result viewer, it is passed in to the content viewers (bottom-right).
Multiple content viewers (such as strings, hex, extracted text, media) may support the node content (the node content support capabilities are registered in the node's Lookup).
Node content support capabilities are registered in the node's Lookup.
Multiple content viewers (such as strings, hex, extracted text, media) can support the node content.
If multiple content viewers are supported, a preferred (default) content viewer is chosen.
For more information refer to org.sleuthkit.autopsy.corecomponents, org.sleuthkit.autopsy.corecomponentsinterfaces
@ -82,7 +83,7 @@ and org.sleuthkit.autopsy.directorytree
\subsection design_overview_sub7 Report generation
After ingest is run, user can generate reports.
When ingest is complete, user can generate reports (user can generate reports also during ingest - such report might not contain all results).
There are several types of reports implemented as submodules that are shipped with Autopsy core: generic html, xml and Excel reports.
Each reporting submodule implements org.sleuthkit.autopsy.report.ReportModule interface and registers itself in layer.xml