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

doc updates

Browse Source
This commit is contained in:
adam-m 2012-07-05 12:51:40 -04:00
parent 8a60cd895b
commit 0b6dc8f6cf
2 changed files with 36 additions and 37 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

54
docs/doxygen/design.dox
View File

@ -4,9 +4,9 @@
This section outlines Autopsy design from the typical analysis work flow perspective.
A typical Autopsy work flow consists of the following steps:
- Wizards are used to create case and images (org.sleuthkit.autopsy.casemodule),
- Wizards are used to create a case and add images (org.sleuthkit.autopsy.casemodule),
- TSK database is created,
- Ingest modules are run (org.sleuthkit.autopsy.ingest),
- Ingest modules are executed (org.sleuthkit.autopsy.ingest),
- Ingest modules post results to the blackboard and ingest inbox,
- Directory tree displays blackboard contents,
- Data is encapsulated into nodes and passed to table and content viewers,
@ -32,57 +32,53 @@ For more information on the add image internals, refer to org.sleuthkit.autopsy.
\subsection design_overview_sub4 Running ingest modules
After image has been added to the case, user can select one or more ingest modules to be executed on the image.
Most ingest modules can be configured before the run using basic or advanced configuration panels (or both).
Most ingest modules can be configured before the run using simple or advanced configuration panels (or both).
The work of ingest services is performed in the background and ingest progress is indicated by progress bars.
Autopsy provides ingest module framework in the ingest package.
Autopsy provides ingest module framework in the ingest package and custom modules can be developed and added to Autopsy.
For more information refer to the org.sleuthkit.autopsy.ingest package documentation and ingest.dox
\subsection design_overview_sub5 Ingest modules posting results
Ingest services, when running, produce data and write the data to the blackboard
in form of blackboard artifacts and their associated blackboard attributes.
in form of blackboard artifacts and associated blackboard attributes.
The services then notify listeners of the availability of the data.
The services notify listeners of the availability of the data.
The default listener is the Autopsy directory tree UI component.
The component displays data currently saved in the blackboard and it also
refreshes the data view in real-time in response to service events.
Ingest service also post interesting messages about the incoming data to Ingest Inbox.
Ingest services post interesting messages about the incoming data to Ingest Inbox.
For more details on how to ingest modules post results, refer to ingest.dox
\subsection design_overview_sub6 Result viewers (directory tree, table viewers, content viewers)
The directory tree result viewer (in the left-hand panel of the Autopsy viewer) is the core results viewer for the results saved during the ingest process.
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 as an ingest message listener with the ingest manager.
When Autopsy starts, the viewer queries the blackboard data and populates the UI.
During ingest, the viewer responds to data events by refreshing the data nodes corresponding to the artifact type in the data event.
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.
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 data nodes.
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.
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).
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
and org.sleuthkit.autopsy.directorytree
Data is encapsulated in nodes org.openide.nodes.Node before it is displayed in the UI.
A node is an abstraction for a displayable data unit.
The nodes contain property sheets to store data and are organized in a parent-child hierarchy.
The hierarchy is used to visually represent the data and to trigger child view update whenever the parent node is selected by the user.
Node child factories are invoked by the Netbeans framework at the time of parent node selection to create or refresh the child node view.
Once a node is selected, its property sheet is rendered in the default table result viewer in the top-right part of the Autopsy UI.
Nodes containing content can be registered with content viewer (bottom-right part of the Autopsy UI).
Nodes use the node lookup infrastructure org.openide.util.Lookup to register their content viewer capabilities.
When a new node is selected, org.sleuthkit.autopsy.corecomponents.DataContentTopComponent queries registered data content viewers to determine support for the given node content.
The specific content viewers query the node lookup to determine the content capability match and return a number ranking the degree of the viewer support for the node type.
Based on return values of isSupported() and isPreferred() methods, the org.sleuthkit.autopsy.corecomponents.DataContentTopComponent enables or disables content viewers and selects a default active viewer for the node type.
\subsection design_overview_sub7 Report generation

19
docs/doxygen/ingest.dox
View File

@ -4,8 +4,9 @@
Autopsy provides ingest framework in org.sleuthkit.autopsy.ingest.
Ingest modules (also referred as ingest services) are designed to be pluggable and they can be added to the Autopsy ingest pipeline
as jar files and they will be automatically recognized next time Autopsy starts.
Ingest modules (also referred as ingest services) are designed to be pluggable.
New modules can be added to the Autopsy ingest pipeline by dropping jar files into build/cluster/modules
and they will be automatically recognized next time Autopsy starts.
This document outlines steps to implement a functional ingest module.
@ -108,12 +109,12 @@ org.sleuthkit.autopsy.ingest.IngestServiceAbstract.hasSimpleConfiguration()
org.sleuthkit.autopsy.ingest.IngestServiceAbstract.getSimpleConfiguration()
should then return javax.swing.JPanel instance.
There are method hooks defined in the ingest service interface that are used to hint the module when the configuration should be saved internally by the module.
There are method hooks defined in the ingest service interface that are used to hint when the configuration should be saved internally by the module.
For example, to save the simple configuration state, the module should implement
org.sleuthkit.autopsy.ingest.IngestServiceAbstract.saveSimpleConfiguration()
\subsection ingest_events Sending Service Events
\subsection ingest_events Sending Service Events and Posting Data
Service should notify listeners of new data available periodically by invoking org.sleuthkit.autopsy.ingest.IngestManagerProxy.fireServiceDataEvent() method.
The method accepts org.sleuthkit.autopsy.ingest.ServiceDataEvent parameter.
@ -131,11 +132,13 @@ Another possibility is to post data in fixed time-intervals (e.g. for a service
and for a service that maintains internal threads to perform work).
There exist a global update setting that specifies maximum time interval for the service to post data.
User may adjust the interval for more frequent, real-time updates. Services that post data in periodic intervals should post their data according to this setting.
The setting is retrieved by the module using getUpdateFrequency() method in org.sleuthkit.autopsy.ingest.IngestManagerProxy class.
The setting is retrieved by the module using org.sleuthkit.autopsy.ingest.IngestManagerProxy.getUpdateFrequency() method.
\subsection ingest_messages Inbox messages
In addition to data events, ingest services should send ingest messages about interesting events.
\subsection ingest_messages Posting Inbox Messages
Ingest services should send ingest messages about interesting events to the user.
Examples of such events include service status (started, stopped) or information about new data.
The messages include the source service, message subject, message details, unique message id (in the context of the originating service) and a uniqueness attribute, used to group similar messages together and to determine the overall importance priority) of the message.
A message group with a higher number of aggregate messages with the same uniqueness is considered a lower priority.
@ -146,7 +149,7 @@ The data messages contain encapsulated blackboard artifacts and attributes. The
Ingest message API is defined in org.sleuthkit.autopsy.ingest.IngestMessage class. The class also contains factory methods to create new messages.
Messages are posted using org.sleuthkit.autopsy.ingest.IngestManagerProxy.postMessage() method, which accepts a message object created using one of the factory methods.
The recipient of the ingest messages is the Ingest Inbox viewer widget component, from the org.sleuthkit.autopsy.ingest.IngestManager package.
The recipient of the ingest messages is org.sleuthkit.autopsy.ingest.IngestMessageTopComponent. The messages are relayed by the ingest manager.
*/