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

Create the doxygen-user_fr directory and translate : configuration, installation and performance pages

Browse Source
This commit is contained in:
Seb2lyon 2021-05-12 05:33:11 +02:00
parent 511e2f9d3c
commit f76469a435
600 changed files with 8969 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2366
docs/doxygen-user_fr/Doxyfile Normal file
View File

File diff suppressed because it is too large Load Diff

28
docs/doxygen-user_fr/EXIF_parser_page.dox Normal file
View File

@ -0,0 +1,28 @@
/*! \page EXIF_parser_page Picture Analyzer Module
[TOC]
\section exif_overview Overview
The Picture Analyzer module extracts EXIF (Exchangeable Image File Format) information from ingested pictures. This information can contain geolocation data for the picture, time, date, camera model and settings (exposure values, resolution, etc) and other information. The discovered attributes are added to the Blackboard. This can tell you where and when a picture was taken, and give clues to the camera that took it.
The module also converts HEIC/HEIF images to JPG while maintaining their EXIF information, which will be processed and saved as it would for normal JPG images.
\section exif_usage Using the Module
Select the checkbox in the Ingest Modules settings screen to enable the Picture Analyzer module.
\section exif_results Seeing Results
Results are shown in the Results tree.
\image html EXIF-tree.PNG
For HEIC files, the converted JPGs will appear in the data source tree as children of the original file.
\image html EXIF-heic.png
*/

4
docs/doxygen-user_fr/README.txt Normal file
View File

@ -0,0 +1,4 @@
To generate documentation, use doxygen.
Get the latest Doxygen source code from https://github.com/doxygen/doxygen
Command: doxygen DoxyFile
NOTE: Paths in the DoxyFile are relative to the PWD.

105
docs/doxygen-user_fr/adHocKeywordSearch.dox Normal file
View File

@ -0,0 +1,105 @@
/*! \page ad_hoc_keyword_search_page Ad Hoc Keyword Search
[TOC]
\section ad_hoc_kw_overview Overview
The ad hoc keyword search features allows you to run single keyword terms or lists of keywords against all images in a case. Both options are located in the top right of the main Autopsy window.
\image html keyword-search-ad-hoc.PNG
The \ref keyword_search_page must be selected during ingest before doing an ad hoc keyword search. If you don't want to search for any of the existing keyword lists, you can deselect everything to just index the files for later searching.
\section ad_hoc_kw_types_section Creating Keywords
The following sections will give a description of each keyword type, then will show some sample text and how various search terms would work against it.
## Exact match
Exact match should be used in cases where the search term is expected to always be surrounded by non-word characters (typically whitespace or punctuation). Spaces/punctuation are allowed in the search term, and capitalization is ignored.
> The quick reddish-brown fox jumps over the lazy dog.
- "quick", "brown", "dog" will match
- "FOX", "Fox", "fox" will all match
- "reddish-brown fox", "brown fox", "LAZY DOG" will match
- "rown" and "lazy do" will not match since they are not bounded by non-word characters in the text
## Substring match
Substring match should be used where the search term is just part of a word, or to allow for different word endings. Capitalization is ignored but spaces and other punctuation can not appear in the search term.
> The quick reddish-brown fox jumps over the lazy dog.
- "jump" will match "jumps", and would also match "jumping", "jumped", etc.
- "dog" will match
- "UMP", "oX" will match
- "y dog", "ish-brown" will not match
## Regex match
Regex match can be used to search for a specific pattern. Regular expressions are supported using Lucene Regex Syntax which is documented here: https://www.elastic.co/guide/en/elasticsearch/reference/1.6/query-dsl-regexp-query.html#regexp-syntax. Wildcards are automatically added to the beginning and end of the regular expressions to ensure all matches are found. Additionally, the resulting hits are split on common token separator boundaries (e.g. space, newline, colon, exclamation point etc.) to make the resulting keyword hit more amenable to highlighting. As of Autopsy 4.9, regex searches are no longer case sensitive. This includes literal characters and character classes.
<b>Note:</b> Since Autopsy 4.4, boundary characters ('^' and '$') no longer work as word boundaries. Previously a search for "^[0-9]{5}$" would return all five
digit strings surrounded by some type of non-word characters. For example, "The number 12345 is.." would contain a match, while "123456789 people" would not. This was because the regex
was compared against each "word" in the document. In newer versions, the text is not split into words internally so this type of search no longer works. To get similar results, replace the
boundary characters with the specific characters that should represent a word break. For example, "^[0-9]{5}$" could become "[ \.\-\,][0-9]{5}[ \.\-\,]".
There is some validation on the regex but it's best to test on a sample image to make sure your regexes are correct and working as expected. One simple way to test is by creating a sample text file that your expression should match, ingesting it as a \ref ds_log "Logical File Set" and then running the regex query.
> In the year 1885 in an article titled Current Notes, the quick brown fox first jumped over the lazy dog.
- "fox" and "FOX" will both match since the search is case-insensitive
- "qu.ck", "cu.*es" will match
- "[JLK]umped" will match "jumped"
- "[0-9]{4}" will match 1885. Character classes like "\d" are not supported. Backreferences are also not supported (but will not generate an error), so "Cu(.)\1ent" would not work to find "Current"
## Other notes
### Built-in keywords
The \ref keyword_search_page has several built-in searches that can not be edited. The ones that are most prone to false hits (IP Address and Phone Number) require that the matching text is surrounded by boundary characters, such as spaces or certain punctuation. For example:
- "Address 10.1.5.127 is unavailable" - The built-in IP Address search would find "10.1.5.127" because it is surrounded by whitespace
- "abc10.1.7.99xyz" - The built-in IP Address search would not find it because it is surrounded by letters
If you want to override this default behavior:
- Copy the existing regex. The easiest way to do this is to click on Keyword Lists, the list you want then the specific entry you want and hit control+c to copy. It will need a bit of cleanup afterward.
- Remove the boundary characters on the beginning and end of the regex
- Make a new keyword list containing the result and run it either during ingest or through the Keyword Lists button.
### Non-Latin text
In general all three types of keyword searches will work as expected but the feature has not been thoroughly tested with all character sets. For example, the searches may no longer be case-insensitive. As with regex above, we suggest testing on a sample file.
\section ad_hoc_kw_search Keyword Search
Individual keyword or regular expressions can quickly be searched using the search text box widget. You can select "Exact Match", "Substring Match" and "Regular Expression" match. See the earlier \ref ad_hoc_kw_types_section section for information on each keyword type. The search can be restricted to only certain data sources by selecting the checkbox near the bottom and then highlighting the data sources to search within. Multiple data sources can be selected used shift+left click or control+left click. The "Save search results" checkbox determines whether the search results will be saved to the case database.
\image html keyword-search-bar.PNG
Results will be opened in a separate Results Viewer for every search executed. If the "Save search results" checkbox was enabled, the results will also be saved in the Directory Tree as shown in the screenshot below.
\image html keyword-search-hits.PNG
\section ad_hoc_kw_lists Keyword Lists
In addition to being selected during ingest, keyword lists can also be run through the Keyword Lists button. For information on setting up these keyword lists, see the \ref keywordListsTab section of the ingest module documentation.
Lists created using the Keyword Search Configuration Dialog can be manually searched by the user by pressing on the 'Keyword Lists' button and selecting the check boxes corresponding to the lists to be searched. The search can be restricted to only certain data sources by selecting the checkbox near the bottom and then highlighting the data sources to search within. Multiple data sources can be selected used shift+left click or control+left click. Once everything has been configured, press "Search" to begin the search. The "Save search results" checkbox determines whether the search results will be saved to the case database.
\image html keyword-search-list.PNG
If the "Save search results" checkbox was enabled, the results of the keyword list search will be shown in the tree, as shown below.
\image html keyword-search-list-results.PNG
\section ad_hoc_during_ingest Doing ad hoc searches during ingest
Ad hoc searches are intended to be used after ingest completes, but can be used in a limited capacity while ingest is ongoing.
Manual \ref ad_hoc_kw_search for individual keywords or regular expressions can be executed while ingest is ongoing, using the current index. Note however, that you may miss some results if the entire index has not yet been populated. Autopsy enables you to perform the search on an incomplete index in order to retrieve some preliminary results in real-time.
During the ingest, the normal manual search using \ref ad_hoc_kw_lists behaves differently than after ingest is complete. A selected list can instead be added to the ingest process and it will be searched in the background instead.
Most keyword management features are disabled during ingest. You can not edit keyword lists but can create new lists (but not add to them) and copy and export existing lists.
*/

20
docs/doxygen-user_fr/aleapp.dox Normal file
View File

@ -0,0 +1,20 @@
/*! \page aleapp_page Android Analyzer (aLEAPP)
[TOC]
\section aleapp_overview Overview
The Android Analyzer ingest module runs aLEAPP (https://github.com/abrignoni/aLEAPP) and converts the results into results that can be viewed in Autopsy.
\section aleapp_config Using the Module
Select the checkbox in the Ingest Modules settings screen to enable the Android Analzyer (ALEAPP) module. The module will run on .tar/.zip files found in a \ref ds_log "logical files data source" or a \ref ds_img "disk image".
\section aleapp_results Seeing Results
Results from the Android Analyzer module will appear in the \ref tree_viewer_page under Results->Extracted Content.
\image html aleapp_main.jpg
*/

63
docs/doxygen-user_fr/android_analyzer.dox Normal file
View File

@ -0,0 +1,63 @@
/*! \page android_analyzer_page Android Analyzer Module
[TOC]
What Does It Do
========
The Android Analyzer module allows you to analyze SQLite and other files from an Android device. It works on Physical dumps from most Android devices (note that we do not provide an acquisition method). Autopsy will not support older Android devices that do not have a volume system. These devices will often have a single physical image file for them and there is no information in the image that describes the layout of the file systems. Autopsy will therefore not be able to detect what it is.
The module should be able to extract the following:
- Text messages / SMS / MMS
- Call Logs
- Contacts
- GPS from the browser and Google Maps
- GPS from cache.wifi and cache.cell files
The module may also extract data from the following apps:
- Facebook Messenger
- IMO
- Line
- Opera Browser
- Orux Maps
- S-Browser
- ShareIt
- Skype
- Tango
- TextNow
- Viber
- WhatsApp
- Words with Friends
- Xender
- Zapya
NOTE: These database formats vary by version of OS and different vendors can place the databases in different places. Autopsy may not support all versions and vendors.
NOTE: This module is not exhaustive with its support for Android. It was created as a starting point for others to contribute plug-ins for 3rd party apps. See the <a href="http://sleuthkit.org/autopsy/docs/api-docs/latest/mod_mobile_page.html">Developer docs</a> for information on writing modules.
Configuration
=======
There is no configuration required.
Using the Module
======
Simply add your physical images or file system dumps as data sources and enable the Android Analyzer module.
Ingest Settings
------
There are no runtime ingest settings required.
Seeing Results
------
The results show up in the tree under "Results", "Extracted Content". The exact data extracted will vary but can include contacts, call logs, messages, and GPS entries.
\image html android_analyzer_output.PNG
*/

47
docs/doxygen-user_fr/archive_extractor.dox Normal file
View File

@ -0,0 +1,47 @@
/*! \page embedded_file_extractor_page Embedded File Extraction Module
[TOC]
\section embedded_files_overview What Does It Do
The Embedded File Extractor module opens ZIP, RAR, other archive formats, Doc, Docx, PPT, PPTX, XLS, and XLSX and sends the derived files from those files back through the ingest pipeline for analysis.
This module expands archive files to enable Autopsy to analyze all files on the system. It enables keyword search and hash lookup to analyze files inside of archives
NOTE: Certain media content embedded inside Doc, Docx, PPT, PPTX, XLS, and XLSX might not be extracted.
\section embedded_files_config Configuration
There is no configuration required.
\section embedded_files_usage Using the Module
Select the checkbox in the Ingest Modules settings screen to enable the Archive Extractor.
\subsection embedded_files_settings Ingest Settings
There are no runtime ingest settings required.
\subsection embedded_files_results Seeing Results
Each file extracted shows up in the data source tree view as a child of the archive containing it,
\image html zipped_children_1.PNG
<br>
<br>
and as an archive under "Views", "File Types", "Archives".
\image html zipped_children_2.PNG
\subsection embedded_files_encryption Encrypted Archives
When the Embedded File Extractor module encounters an encrypted archive, it will generate a warning bubble in the bottom right of the main screen:
\image html zipped_encryption_detected.png
After ingest, you can attempt to decrypt these archives if you know the password. Find the archive (either in the \ref tree_viewer_page "tree view" or \ref result_viewer_page "result view") and right-click on it, then select "Unzip contents with password".
\image html zipped_context_menu.png
After entering the password, you can select which ingest modules to run on the newly extracted files. When finished, you can browse to the encrypted archive in the tree view to see the newly extracted files. If the archive was already open in the tree, you may have to close and open the case in order to see the new data.
\image html zipped_tree.png
*/

97
docs/doxygen-user_fr/auto_ingest.dox Normal file
View File

@ -0,0 +1,97 @@
/*! \page auto_ingest_page Automated Ingest
[TOC]
\section auto_ingest_overview Overview
Auto ingest allows one or many computers to process \ref ds_page "data sources" automatically with minimal support from a user. The resulting \ref multiuser_page "multi-user cases" can be opened and reviewed by analysts, using any of the normal functions in Autopsy.
The \ref experimental_page must be enabled to run use automated ingest.
There are three types of computers in an Automated Processing Deployment:
<ul>
<li><b>Automated Ingest Node:</b>
These computers are responsible for monitoring the Shared Images Folder and detecting when new images have been copied in. Each writes its results to the Shared Cases Folder.
<li><b>Examiner Node:</b> These computers can open a case during processing or after it has been analyzed by the Automated Ingest Node. They allow the examiner to review the results, tag files, and perform additional analysis as needed.
<li><b>Services/Storage Node:</b> These computers run the services needed for \ref multiuser_page "multi-user cases", hold the images to be processed and store the analyzed Autopsy cases.
</ul>
The general workflow is as follows:
<ol>
<li>Disk images or other types of data sources are added to the <b>shared images folder</b>. This folder will contain all the disk and phone images that are copied into the system. They must be copied into here before they can be analyzed. As more than one machine may need to access this folder across the network, use UNC paths (if possible) to refer to this folder.
<li>A \ref auto_ingest_manifest_creation "manifest file" is added for each data source that is to be processed.
<li>An auto ingest node finds that manifest file and begins processing the data source. It will make a case in the <b>shared cases folder</b> if there is not one there already. This folder will contain all of the analysis results after automated analysis has been performed on the images. This folder will not contain the images, those will stay in the Shared Images Folder. As more than one machine may need to access this folder across the network, use UNC paths (if possible) to refer to this folder.
<li>An analyst on an examiner node opens the case and starts their analysis. This can happen while an auto ingest node is processing data or afterwards.
</ol>
An Automated Processing Deployment could have an architecture, such as this:
\image html AutoIngest/overview_pic1.png
Another illustration, including the network infrastructure, is shown below:
\image html AutoIngest/overview_pic2.png
\section auto_ingest_setup_section Configuration
Configuring a group of computers for auto ingest is described on the \ref auto_ingest_setup_page page.
\section auto_ingest_ex_usage Examiner Node Usage
An examiner node in an auto ingest environment is generally the same as any normal Autopsy client set up for \ref multiuser_page "multi-user cases." Any number of examiner nodes can open cases that have been created by the auto ingest nodes. The cases do not need to be complete.
The examiner can open the auto ingest dashboard through the Tools menu. This allows the user to see what cases and data sources are scheduled, in progress, or done.
\image html AutoIngest/examiner_dashboard.png
\section auto_ingest_ain_usage Auto Ingest Node Usage
\subsection auto_ingest_manifest_creation Preparing Data for Auto Ingest
Users will manually copy images to the source images folder (using subfolders if desired) and schedule them to be ingested by creating one file in the folder alongside the image to be ingested. This file is a manifest file describing the image. This file's name must end in "_Manifest.xml."
\image html AutoIngest/manifest_file_in_file_explorer.png
The following is an example of an Autopsy manifest file. Line breaks/spaces are not required, but are shown here for better human readability.
\verbatim<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<AutopsyManifest>
<CaseName>XperiaCase</CaseName>
<DeviceId>50549</DeviceId>
<DataSource>mtd3_userdata.bin</DataSource>
</AutopsyManifest>\endverbatim
The following is a description of each required field:
<ul><li><b>CaseName</b>: Case name. Multiple data sources can belong to the same case.
<li><b>DeviceId</b>: (Optional) A globally unique ID representing device this data source came from. This can be an integer or a UUID.
<li><b>DataSource</b>: File name of the data source. Does not include the path.
</ul>
Any amount of additional data may be included in the XML file as long as the fields above are present.
Manifest files can be automatically generated by using the \ref manifest_tool_page.
\subsection auto_ingest_running Running an Auto Ingest Node
When auto ingest mode is enabled, Autopsy will open with a different UI than normal, allowing the user to see what cases are being processed, which are done, and which are next in the queue. You can also change the priority of cases and reprocess cases that may have had an error.
\image html AutoIngest/auto_ingest_in_progress.png
The user must press the "Start" button to begin the auto ingest process. Note that if the computer running Autopsy in auto ingest mode is restarted, someone must log into it to restart Autopsy. It does not start by itself. When "Start" is pressed, the node will scan through the Shared Images folder looking for manifest files. This scan happens periodically when ingest is running. It can also be started manually using the "Refresh" button.
The UI for the auto ingest node will display what images are scheduled for analysis, what is currently running, and what has been completed. If a newly added image should be the highest priority, then you can select it and choose "Prioritize Case". This will prioritize all images within the same case to be top priority. You may also prioritize only a single data source (job) using the "Prioritize Job" button in the same manner. If you have prioritized something by mistake, the "Deprioritize" buttons will undo it.
In the middle area, you can see the currently running jobs. You have the option of cancelling an entire image that is being analyzed or to cancel only the current module that is running. The latter is used when one of the modules has been running for too long and you think that the module is having trouble with the image and will never complete. If the auto ingest node loses connection to either the database or Solr services it will automatically cancel the currently running job and will pause processing. Once the connectivity issue has been resolved you must manually resume processing.
If an error occurs while processing a job, or if a job was set up incorrectly, the "Reprocess Job" button can be used to move a completed job back into the Pending Jobs table, where it can be prioritized if desired. No case data is deleted which may result in some duplication in the results.
"Delete Case" will remove a case from the list and remove all of its data. This will not remove the original image, manifest file, or anything else from the input directory. A case can not be deleted if it is currently open in any Examiner Node or if an auto ingest node is currently working on a job related to the case. Care should be used with the delete case button. Note that once a case is deleted the path to its data sources must be changed before they can be reprocessed (i.e., rename the base folder).
The "Auto Ingest Metrics" button displays processing data for all of the auto ingest nodes in the system from a user-entered starting date.
\image html AutoIngest/metrics.png
\section auto_ingest_administration_section Auto Ingest Node Administration
See the \ref auto_ingest_admin_page for information on how to enable administrator features.
*/

94
docs/doxygen-user_fr/auto_ingest_administration.dox Normal file
View File

@ -0,0 +1,94 @@
/*! \page auto_ingest_admin_page Auto Ingest Administration
[TOC]
\section auto_ingest_admin_overview Overview
Examiner nodes in an \ref auto_ingest_page environment can be given a type of administrator access. This allows an admin to:
<ul><li>Access admin-only options on the Auto Ingest Jobs Panel, including:
<ul>
<li>Prioritizing jobs and cases
<li>Cancelling jobs
<li>Deleting and reprocessing jobs
</ul>
<li>Access the Auto Ingest Nodes Panel, which allows the user to:
<ul><li>View the currently active auto ingest nodes
<li>Pause/resume/shutdown the active auto ingest nodes
<li>View/enabled the health monitor
<li>View auto ingest metrics
</ul></ul>
\section auto_ingest_admin_setup Setup
The admin panel is enabled by creating the file "admin" in the user config directory. Note that the name must be exactly that with no extension. It also works to make a folder named "admin" instead of a file which can be easier on machines where the file extension is hidden. No restart is needed; simply reopen the Auto Ingest Dashboard after creating the file.
For an installed copy of Autopsy, the file will go under \c "C:\Users\<user name>\AppData\Roaming\Autopsy\config".
\image html AutoIngest/admin_file.png
\section auto_ingest_admin_jobs_panel Auto Ingest Jobs Panel
With the admin file in place, the user can right-click on jobs in each of the tables of the jobs panel to perform different actions. In the Pending Jobs table, the context menu allows cases and individual jobs to be prioritized.
\image html AutoIngest/admin_jobs_panel.png
In the Running Jobs tables, the ingest progress can be viewed and the current job can be cancelled. Note that cancellation can take some time.
\image html AutoIngest/admin_jobs_cancel.png
In the Completed Jobs table, the user can reprocess a job (generally useful when a job had errors), delete a case (if no other machines are using it) and view the case log.
\image html AutoIngest/admin_jobs_completed.png
\section auto_ingest_admin_nodes_panel Auto Ingest Nodes Panel
The Nodes panel displays the status of every online auto ingest node. Additionally, an admin can pause or resume a node, or shut down a node entirely (i.e., exit the Autopsy app).
\image html AutoIngest/admin_nodes_panel.png
\section auto_ingest_admin_cases_panel Cases Panel
The Cases panel shows information about each auto ingest case - the name, creation and last accessed times, the case directory, and flags for which parts of the case have been deleted.
\image html AutoIngest/cases_panel.png
If you right-click on a case, you can open it, see the log, delete the case, or view properties of the case.
\image html AutoIngest/cases_context_menu.png
Note that you can select multiple cases at once to delete. If you choose to delete a case (or cases), you'll see the following confirmation dialog:
\image html AutoIngest/case_delete_confirm.png
\section auto_ingest_admin_health_monitor Health Monitor
The health monitor shows timing stats and the general state of the system. The Health Monitor is accessed from the Auto Ingest Nodes panel. To enable health monitoring, click on the Health Monitor button to get the following screen and then press the "Enable monitor" button.
\image html AutoIngest/health_monitor_disabled.png
This will enable the health monitor metrics on every node (both auto ingest nodes and examiner nodes) that is using this PostgreSQL server. Once enabled, the monitor will display the collected metrics.
\image html AutoIngest/health_monitor.png
By default, the graphs will show all metrics collected in the last day.
The Timing Metrics area shows how long various tasks took to perform. There are several options in the Timing Metrics section:
<ul><li><b>Max days to display</b>: Choose to show the last day, week, two week, or month
<li><b>Filter by host</b>: Show only metrics that came from the selected host
<li><b>Show trend line</b>: Show or hide the red trend line
<li><b>Do not plot outliers</b>: Redraws the graph allowing very high metrics to go off the screen. Can be helpful with data where a couple of entries took an exceptionally long time.
</ul>
The User Metrics section shows open cases and logged on nodes. For the open cases section, the count is the number of distinct cases open. If ten nodes have the same case open, the count will be one. The logged in users section shows the total number of active nodes, with auto ingest nodes on the bottom in green and examiner nodes on top in blue. The User Metrics section only has one option:
<ul><li><b>Max days to display</b>: Choose to show the last day, week, two week, or month
</ul>
\section auto_ingest_admin_metrics Auto Ingest Metrics
The Auto Ingest Metrics can be accessed the Auto Ingest Nodes panel and shows data about the jobs completed in a selected time frame.
\image html AutoIngest/metrics.png
*/

112
docs/doxygen-user_fr/auto_ingest_setup.dox Normal file
View File

@ -0,0 +1,112 @@
/*! \page auto_ingest_setup_page Auto Ingest Configuration
[TOC]
\section auto_ingest_setup_overview Overview
A multi-user installation requires several network-based services, such as a central database and a messaging system, and automated ingest requires one or more auto ingest nodes. While you may run all of the external services on a single node, this is not likely to be ideal - spreading the services out across several machines can improve throughput. Keeping in mind that all the following machines need to be able to communicate with each other with network visibility to the shared drive, here is a description of a possible configuration:
<table>
<tr><th>Number of Machines</th><th>Services</th></tr>
<tr><td>One</td><td><ul><li><b>Solr</b> - Install Solr on the highest-powered machine; the more CPUs the better.</li>
<li>The <b>case output folders</b> can also be put on this machine.</li></ul></td></tr>
<tr><td>One</td><td><ul><li><b>ActiveMQ</b> - This service has minimal memory and disk requirements.</li>
<li><b>PostgreSQL</b> - This service has minimal memory and disk requirements.</li></ul></td></tr>
<tr><td>One</td><td><ul><li><b>Shared image folder</b> - This machine needs a large amount of disk space but doesn't need the fastest hardware.</li></ul></td></tr>
<tr><td>One or more</td><td><ul><li><b>Automated Ingest Node(s)</b> - These machines don't need much disk space but benefit from additional memory and processing power.</li></ul></td></tr>
<tr><td>One or more</td><td><ul><li><b>Examiner Node(s)</b> - See \ref installation_page for recommended system requirements.</li></ul></td></tr>
</table>
Solr is going to be a sizeable resource hog. A big performance increase will be seen if you put solid state drives (SSD) in the machine running Solr, and have that machine also host the large network drive on the SSDs as a place to store case output. The source images to can be on SAS drives (slower than SSD) with very little impact on performance. This idea here is to have the most resource-intensive operations on the fastest hardware. Using this strategy, there are actually two large network stores, one for input images and one for output cases.
\section auto_ingest_setup_services Installing Services and Configuring Autopsy
Follow the instructions on the \ref install_multiuser_page page to set up the necessary services and configure your Autopsy clients to use them. After this is complete, you should be able to \ref multiuser_page "create and use multi-user cases".
\section auto_ingest_setup_ain_config Auto Ingest Node Configuration
While Examiner nodes only require multi-user cases to be set up, the auto ingest nodes need additional configuration. To start, go to the "Auto Ingest" tab on the Options menu and select the "Auto Ingest mode" radio button. If you haven't saved your multi-user settings there will be a warning message displayed here - if you see it, go back to the "Multi-User" tab and make sure you've entered all the required fields and then hit the "Apply" button.
\image html AutoIngest/auto_ingest_mode_setup.png
\subsection auto_ingest_config_folders Folder Configuration
The first thing to do is to set two folder locations. The shared images folder is the base folder for all data that will be ingested through the auto ingest node. The shared cases folder is the base folder for the cases that will be created by the auto ingest node.
\subsection auto_ingest_config_ingest_settings Ingest Module Settings
The "Ingest Module Settings" button is used to configure the \ref ingest_page you want to run during auto-ingest. One note is that on auto-ingest nodes, we recommend that you configure the Keyword Search module to not perform periodic keyword searches. When a user is in front of the computer, this feature exists to provide frequent updates, but it is not needed on this node. To configure this, choose the Keyword Search item in the Options window. Select the "General" tab and choose the option for no periodic search.
\image html AutoIngest/no_periodic_searches.png
\subsection auto_ingest_advanced_settings Advanced Settings
The "Advanced Settings" button will bring up the automated ingest job settings. As expressed in the warning statement, care must be used when making changes on this panel.
\image html AutoIngest/advanced_settings.png
The Automated Ingest Job Settings section contains the following options:
<dl>
<dt>System synchronization wait time</dt>
<dd>A wait time used by auto ingest nodes to ensure proper synchronization of node operations in circumstances where delays may occur, e.g., a wait to compensate for network file system latency effects on the visibility of newly created shared directories and files.</dd>
<dt>External processes time out</dt>
<dd>Autopsy components that spawn potentially long-running processes have the option to use this setting, if it is enabled, to terminate those processes if the specified time out period has elapsed. Each component that uses this feature is responsible for implementing its own policy for the handling of incomplete processing when an external process time out occurs. Core components that use external process time outs include the \ref recent_activity_page and \ref photorec_carver_page ingest modules.</dd>
<dt>Interval between input scans</dt>
<dd>The interval between scans of the auto ingest input directories for manifest files. Note that the actual timing of input scans by each node depends on both this setting and node startup time.</dd>
<dt>Maximum job retries allowed</dt>
<dd>The maximum number of times a crashed auto ingest job will be automatically retried. No distinction is made between jobs that crash due to system error conditions such as power outages and jobs that crash due to input data source corruption. In general, input data source corruption should be handled gracefully by Autopsy, but this setting provides insurance against unforeseen issues with input data viability.</dd>
<dt>Target concurrent jobs per case</dt>
<dd>A soft limit on the number of concurrent jobs per case when multiple cases are processed simultaneously by a group of auto ingest nodes. This setting specifies a target rather than a hard limit because nodes are never idled if there are ingest jobs to do and nodes work cooperatively rather than rely on a centralized, load-balancing job scheduling service.</dd>
<dt>Number of threads to use for file ingest</dt>
<dd>The number of threads an auto ingest node dedicates to analyzing files from input data sources in parallel. Note that analysis of input data source files themselves is always single-threaded.</dd>
</dl>
\subsection auto_ingest_file_export File Export
The "File Export" button will bring up the \ref file_export_page settings. This allows certain types of files to be automatically exported during auto ingest. Setting up this feature requires knowledge of internal Autopsy data structures and can be ignored for users.
\subsection auto_ingest_shared_config Shared Configuration
When using multiple auto ingest nodes, configuration can be centralized and shared with any auto ingest node that desires to use it. This is called Shared Configuration. The general idea is that you will set up one node (the "master") and upload that configuration to a central location. Then the other auto ingest nodes (the "secondary" nodes) will download that configuration whenever they start a new job. This saves time because you only need to configure one node, and ensures consistency across the auto ingest nodes.
\subsubsection auto_ingest_shared_config_master Master Node
On the computer that is going to be the configuration master automated ingest node, follow the configuration steps described in above to configure the node.
If you would like every automated ingest node to share the configuration settings, check the first checkbox in the Shared Configuration section of the Auto Ingest settings panel. Next select a folder to store the shared configuration in. This folder must be a path to a network share that the other machines in the system will have access to. Use a UNC path if possible. Next, check the "Use this node as a master node that can upload settings" checkbox which should enable the "Save & Upload Config" button. If this does not happen, look for a red error message explaining what settings are missing.
\image html AutoIngest/master_node.png
After saving and uploading the configuration, hit the "Save" button to exit the Options panel.
\subsubsection auto_ingest_shared_config_secondary Secondary Node
Once one node has uploaded shared configuration data, the remaining nodes can be set up to download it, skipping over some of the configuration steps above.
To set up a secondary node, start by going through the \ref install_multiuser_page "multi-user configuration." Apply those changes, then switch to the Auto Ingest tab on the Options panel. Check the box to enable auto ingest, and then the box to enable shared configuration and enter the same folder used on the master node. The "Download Config" button should now be enabled and can be used to get the rest of the configuration automatically. Afterwards a dialog will likely appear telling you to restart Autopsy.
\subsubsection auto_ingest_shared_config_notes Notes
Some notes on shared configuration:
<ul><li>The \ref auto_ingest_error_suppression "error suppression registry edit" below will need to be done on each node
<li>After the initial setup, the current shared configuration data will be updated before each job (no need to manually download it again)
<li>A few options require a restart to take effect (for example, most of the multi-user settings). If these are downloaded automatically while automated ingest is running, they will not be used until the automated ingest node is restarted.
<li>There is currently a limitation on where hash databases can be saved. Each database will be downloaded to the same folder it was in on the master node, which will cause errors if that drive letter is not present or the folder is not writeable on every node.
<li>Shared copies of the hash databases are also not currently supported. Each node will download its own copy of each database.
</ul>
\subsection auto_ingest_test_button Testing
Once everything is configured, you can use the "Test" button near the bottom of the panel to test if everything is set up correctly. The button will test whether the services are available, whether a case can be created, and if the ingest settings are valid. If the test passes you'll see a green check. If it fails you'll see a message giving a short description of what error occurred. Depending on the error you may also see a pop-up message. You can check the logs for additional information (close the Options panel and click on "Help" then "Open Log Folder").
\image html AutoIngest/test_button_failure.png
\subsection auto_ingest_error_suppression Error Suppression
On an auto ingest node, we also strongly recommend that you configure the system to suppress error dialogs that Windows may display if an application crashes. Some of the modules that Autopsy runs have crashed on some test data in the past and if an error dialog is displayed all processing stops.
Disabling the error messages is done by setting the following registry key to "1", as shown in the screenshot below.
\verbatim HKCU\Software\Microsoft\Windows\Windows Error Reporting\DontShowUI\endverbatim
\image html AutoIngest/error_suppression.png
*/

56
docs/doxygen-user_fr/case_management.dox Normal file
View File

@ -0,0 +1,56 @@
/*! \page cases_page Cases
[TOC]
You need to create a case before you can analyze data in Autopsy. A case can contain one or more data sources (disk images, disk devices, logical files). The data sources can be from multiple drives in a single computer or from multiple computers. It's up to you.
Each case has its own directory that is named based on the case name. The directory will contain configuration files, a database, reports, and other files that modules generates. The main Autopsy case configuration file has an ".aut" extension.
\section case_create Creating a Case
\image html splashscreen.PNG
There are several ways to create a new case:
- The opening splash screen has a button to create a new case.
- The "Case", "Create New Case" menu item
The New Case wizard dialog will open and you will need to enter the case name and base directory. A directory for the case will be created inside of the "base directory". If the directory already exists, you will need to either delete the existing directory or choose a different combination of names.
\image html case-newcase.PNG
NOTE: You will only have the option of making a multi-user case if you have configured Autopsy with multi-user settings. See \ref install_multiuser_page for installation instructions and \ref creating_multi_user_cases for details on creating multi-user cases.
You will also be prompted for optional information as shown below:
\image html new_case_optional_info.png
All fields on this panel are optional. Additionally, the Organization section will only be active if the \ref central_repo_page "central repository" is enabled.
After you create the case, you will be prompted to add a data source, as described in \ref ds_add.
\section case_open Opening a Case
To open a case, either:
- Choose "Open Case" or "Open Recent Case" from the opening splash screen.
- Choose the "Case", "Open Case" menu item or "Case", "Open Recent Case"
"Open Recent Case" will always bring up a screen allowing you to select one of the recently opened cases. "Open Case" will do one of two things;
- If multi-user cases are not enabled, it will bring up a file chooser that can be used to browse to the ".aut" file in the case directory of the desired case
- If multi-user cases are enabled, it will bring up the multi-user case selection screen. This uses the coordination services to find a list of multi-user cases. If needed, the "Open Single-User Case" button can be used to bring up the normal file chooser. The multi-user case selection screen has a \ref ui_quick_search feature which can be used to quickly find a case in the table. The following shows the multi-user case selection screen:
\image html multi_user_case_select.png
\section case_properties Viewing Case Details and the Data Source Summary
You can view the case properties by going to the "Case" menu and clicking "Case Details".
\image html case_properties.png
Most of the case properties can be edited through the "Edit Details" button.
You can view the data source summary by going to the "Case" menu and clicking "Data Source Summary" or by selecting the data source in the \ref tree_viewer_page and then the "Summary" tab. More information can be found on the \ref data_source_summary_page page.
\image html ds_summary_window.png
*/

243
docs/doxygen-user_fr/central_repo.dox Normal file
View File

@ -0,0 +1,243 @@
/*! \page central_repo_page Central Repository
[TOC]
\section cr_overview Overview
The central repository allows a user to find matching artifacts both across cases and across data sources in the same case.
It is a combination of an ingest module that extracts, stores, and compares properties against lists of notable
properties, a database that stores these properties, and an additional panel in Autopsy to display other instances of each
property. The central repository database can either be SQLite or PostgreSQL.
The following are some use cases for the central repository:
- <b>Finding Other Instances of a Property</b>
- If you navigate to a file or Autopsy artifact (such as a Web History item), there is a content viewer in the bottom right that will show you other instances of this property across the data stored in the central repository.
- <b>Alerting When Previously Notable Properties Occur</b>
- You can use the central repository to record which properties were associated with files and artifacts that were evidence (or notable). Once these properties have been tagged as notable they will be added to the Interesting Items section of the tree when seen again in any future cases.
- <b>Storing Hash Sets</b>
- You can create and import hash sets into the central repository instead of using local copies in the \ref hash_db_page "Hash Lookup module". These hash sets are functionally equivalent to local hash sets but can be shared among multiple analysts (when using a PostgreSQL central repository).
\section cr_terms Terms and Concepts
- <b>Central Repository</b> - The Autopsy feature containing the central repository database and Central Repository Ingest Module. Also responsible for displaying correlated properties to the user
- <b>Central Repository Database</b> - the SQLite or PostgreSQL database that holds all the data
- <b>Central Repository Ingest Module</b> - The ingest module responsible for adding new properties to the database and comparing these properties against existing notable properties
- <b>Property</b> - The data being stored/correlated. These can be file paths/MD5 hashes, email addresses, phone numbers, etc.
\section cr_setup Setup
The central repository settings are found on the main options panel (Tools->Options) on the "Central Repository" tab.
\image html central_repo_options.png
\subsection cr_db_setup Database Configuration
There are two types of central repository databases:
- <b>SQLite</b> - This type of database is stored in a file. It should only be used when a single client will be accessing the database. You can not use this option with \ref multiuser_page "multi-user cases".
- <b>PostgreSQL</b> - This type of database is stored on a server running either on the user's host or a remote server. This option must be used if multiple users will be using the same database.
\subsubsection cr_db_setup_auto Automatic Database Configuration
Starting with Autopsy 4.15, when you load Autopsy and the central repository is not enabled you will be
asked if you want to enable it. Doing so will create a SQLite database in your Autopsy user folder (on Windows this will be in AppData). You will only be prompted to do this once. Whichever option you select, you can change your central repository settings later as described below.
Since a SQLite database can't be used for multi-user cases, you are also given the option to switch to a PostgreSQL database when you \ref multiuser_install_clients "enable multi-user cases". If you are currently using a SQLite database, when you enable multi-user cases you will be asked if you want to switch to a PostgreSQL database on the same server. Note that the contents of your SQLite database will not be copied over.
\subsubsection cr_db_setup_manual Manual Database Configuration
On the central repository options panel, check the 'Use a Central Repository' option and then click the Configure button to set up a database. There are three options here:
- <b>SQLite</b> - This option stores the database in a file. It should only be used when a single client will be accessing the database.
- <b>PostgreSQL using multi-user settings</b> - This option uses a central repository on the same PostgreSQL server that has been configured for \ref multiuser_page "multi-user cases". This option can not be selected if multi-user cases are not enabled. This is one of the options if multiple users will be using the same database.
- <b>Custom PostgreSQL</b> - This option uses a database server running either on the user's host or a remote server, where the server is specified in the central repository settings. This is one of the options if multiple users will be using the same database.
Once a database has been configured, the lower two buttons on the main panel will be enabled, which will be described below.
<b>Setting up a PostgreSQL deployment using the multi-user settings</b>
See the \ref install_multiuser_page page for instructions on configuring a multi-user environment. Once done, you can select the "PostgreSQL using multi-user settings" option to create/use a central repository on that PostgreSQL server.
<b>Setting up a custom PostgreSQL deployment</b>
If needed, see the \ref install_postgresql_page page for help setting up your PostgreSQL server.
For PostgreSQL all values are required, but some defaults are provided for convenience.
\image html central_repo_postgres.png
- Host Name/IP is the hostname or IP of your PostgreSQL server.
- Port is the port that the PostgreSQL server is listening on; default is 5432.
- User Name is a PostgreSQL user that can create and modify databases
- User Password is the password for the user.
If the database does not exist, you wll be prompted to create it.
<b>Setting Up SQLite Deployment</b>
Select SQLite in the Database Type to set up a SQLite database. SQLite databases should not be used if more than one client will be accessing the central repository.
\image html central_repo_sqlite.png
Enter or browse to a folder for the database. If the database file does not exist in that folder, you will be prompted to create it.
\subsection cr_manage_properties Manage Correlation Properties
The Central Repository ingest module can save different types of properties to the database. By default all properties are recorded, but
this setting can be changed on the options panel through the Manage Correlation Properties button. Note that these settings
are saved to the database, so in a multi-user setting any changes will affect all users.
\image html central_repo_types.png
Descriptions of the property types:
- <b>Files</b>
- Files are correlated based on MD5 hash and file path and name. The \ref hash_db_page must be enabled.
- <b>Domains</b>
- Domains are extracted from the various web artifacts, which primarily come from the \ref recent_activity_page.
- <b>Email Addresses</b>
- Email addresses are created by modules such as the \ref email_parser_page.
- <b>Phone Numbers</b>
- Phone numbers are currently only extracted from call logs, contact lists and message, which come from the \ref android_analyzer_page.
- <b>USB Devices</b>
- USB device properties come from the registry parsing in the \ref recent_activity_page.
- <b>Wireless Networks</b>
- Wireless networks are correlated on SSIDs, and come from the registry parsing in the \ref recent_activity_page.
- <b>MAC Addresses</b>
- MAC address properties are currently only created by custom Autopsy modules.
- <b>IMEI Number</b>
- IMEIs properties are currently only created by custom Autopsy modules.
- <b>IMSI Number</b>
- IMSI properties are currently only created by custom Autopsy modules.
- <b>ICCID Number</b>
- ICCID properties are currently only created by custom Autopsy modules.
- <b>Credit Card</b>
- Credid Card properties are created by the \ref keyword_search_page.
- <b> App-specific Accounts (Facebook, Twitter, etc)</b>
- These properties primarily come from the \ref android_analyzer_page.
\subsection cr_manage_orgs Manage Organizations
Organizations are stored in the central repository and contain contact information for the given organization. Organizations are used for Hash Sets saved in the central repository, and can also be associated with Autopsy cases.
\image html central_repo_orgs.png
One default org, "Not Specified" will always be present in the list. New organizations can be created, edited, and deleted through the appropriate buttons. Note that any organization that is currently in use by a case or hash set can not be deleted. All fields apart from the organization name are optional.
\image html central_repo_new_org.png
\subsection cr_show_cases Manage Cases
Displays a list of all cases that are in the central repository database and details about each case.
\image html central_repo_details.png
\section cr_using_repo Using the Central Repository
\subsection cr_ingest_module Central Repository Module
The Central Repository ingest module is responsible for adding properties to the database and comparing each property
against the list of notable properties. It is best to run all ingest modules to get the most out of the Correlation
Engine. For example, if Hash Lookup is not run then the Central Repository module will not put any files into the
database. If the Central Repository module is not run on a particular case but a central repository is enabled,
there will still be some limited functionality. The Content Viewer will still display matching properties from
other cases/data sources where the Central Repository was run.
\image html central_repo_ingest_settings.png
There are three settings for the Central Repository ingest module:
<ul>
<li><b>Save items to the Central Repository</b> - This should only be unselected in the rare case that you don't want to add any properties from the current data source to the central repository, but still want to flag past occurrences.
<li><b>Flag items previously tagged as notable</b> - Enabling this causes Interesting Item/File artifacts to be created when properties matching those previously flagged are found. See the next section \ref cr_tagging for details.
<li><b>Flag previously seen devices</b> - When this is enabled, an Interesting Item artifact will be created if any device-related property (USB, MAC Address, IMSI, IMEI, ICCID) is found that is already in the central repository, regardless of whether they have been flagged.
</li>
\subsection cr_tagging Tagging Files and Artifacts
Tagging a file or artifact with a "notable" tag will change its associated property in the central repository to notable as well.
By default, there will be a tag named "Notable Item" that can be used for this purpose. See the \ref tagging_page "Tagging page" for more information on creating additional tags with notable status.
Any future data source ingest (where this module is enabled)
will use those notable properties in a similar manner as a Known Bad hash set, causing matching files and artifacts from that
ingest to be added to the Interesting Items list in that currently open case.
\image html central_repo_tag_file.png
If a tag is accidentally added to a file or artifact, it can be removed though the context menu. This will remove its property's
notable status in the central repository.
If you would like to prevent the Interesting Items from being created in a particular case, you can disable the flagging
through the run time ingest properties. Note that this only disables the Interesting Item results - all properties
are still added to the central repository.
\image html central_repo_ingest_settings.png
\section cr_viewing_results Viewing Results
Results from enabling a central repository and running the Central Repository Ingest Module can be seen in two places:
- The Content Viewer for each file or artifact will display all matching properties from other cases/data sources
- The Interesting Files node of the result tree will contain any files or results that matched properties previously marked as notable
\subsection cr_content_viewer Content Viewer
The \ref content_viewer_page panel is where previous instances of properties are displayed. Without a central repository enabled,
this "Other Occurrences" panel will show files with hashes matching the selected file within the current case. Enabling a central
repository allows this panel to also display matching properties stored in the database, and adds some functionality to the row.
Note that the Central Repository Ingest Module does not have to have been run on the current data source to see correlated
properties from the central repository. If the selected file or artifact is associated by one of the supported Correlation Types,
to one or more properties in the database, the associated properties will be displayed. Note: the Content
Viewer will display ALL associated properties available in the database. It ignores the user's enabled/disabled Correlation Properties.
The other occurrences are grouped by case and then data source. Selecting one of the results brings up information on it in the right column. If a file or artifact was previously marked as notable, you will see "notable" in red next to "Known Status".
\image html central_repo_content_viewer.png
The user can click on any column heading to sort by the values in that column.
If the user selects an entry in the third column and then right-clicks, a menu will be displayed.
This menu has several options.
-# Export All Other Occurrences to CSV
-# Show Case Details
-# Show Frequency
<b>Export All Other Occurrences to CSV</b>
This option will save every other occurrence in the Content Viewer table to a CSV file.
By default, the CSV file is saved into the Export directory inside the currently open Autopsy case,
but the user is free to select a different location.
<b>Show Case Details</b>
This option will open a dialog that displays all of the relevant details for the selected case. The
details will include:
- Case UUID
- Case Name
- Case Creation Date
- Case Examiner contact information
- Case Examiner's notes
These details would have been entered by the examiner of the selected case, when creating the case or later by visiting
the Case -> Case Properties menu.
<b>Show Frequency</b>
This shows how common the selected file is. The value is the percentage of case/data source tuples that have the selected property.
\subsection cr_interesting_items Interesting Items
In the Results tree of an open case is an entry called Interesting Items. When this module is enabled, all of the enabled
Correlatable Properties will cause matching files and artifacts to be added to this Interesting Items tree during ingest.
\image html central_repo_interesting_items.png
As an example, suppose the Files Correlatable Property is enabled and the ingest is currently processing a file "badfile.exe", and the MD5 hash
for that file already exists in the database as a notable file property. In this case an entry in the Interesting Items tree will be added for
the current instance of "badfile.exe" in the data source currently being ingested.
The same type of thing will happen for each enabled Correlatable Property.
In the case of the phone number correlatable type, the Interesting Items tree will start a sub-tree for each phone number. The sub-tree will
then contain each instance of that notable phone number.
*/

208
docs/doxygen-user_fr/command_line_ingest.dox Normal file
View File

@ -0,0 +1,208 @@
/*! \page command_line_ingest_page Command Line Ingest
[TOC]
\section command_line_ingest_overview Overview
The Command Line Ingest feature allows you to run many of Autopsy's functions from the command line. You can add data sources to cases, choose which ingest modules to run, and automatically generate a report. When complete, these cases can be opened as normal or you can simply use the reports and other output without opening Autopsy.
\section command_line_ingest_config Configuration
To configure command line ingest, go to Tools->Options and then select the "Command Line Ingest" tab. If you would like to create or open multi-user cases, you'll need to \ref install_multiuser_page "configure the multi-user settings".
\image html command_line_ingest_options.png
\subsection command_line_ingest_profile Configuring Ingest Profiles
From the options panel you can configure the default ingest profile. This is the same as normal \ref ingest_page "ingest module" configuration - choose a file filter then enable or disable the individual ingest modules, changing their settings if desired. Press "OK" to save your settings.
Currently custom ingest profiles can not be configured on the command line ingest options panel but they can be created through the \ref ingest_page "ingest options panel" and then used on the command line. Here we've created an ingest profile that will only process image file types and will only run certain ingest modules.
\image html command_line_ingest_profile.png
See the section on \ref command_line_ds "running ingest" below for instructions on specifying an ingest profile on the command line.
\subsection command_line_report_profile Configuring Report Profiles
You can set up report profiles to use with command line ingest. You'll start with a "default" profile and can create additional profiles. Each profile will allow you to generate one type of report. Configuration is generally the same as normal \ref reporting_page "report generation" with some slight differences. This is mainly seen in places where your options are dependent on the open case, such as choosing \ref tagging_page "tags" to report on or \ref interesting_files_identifier_page "interesting file" set names to include. For example, the HTML report normally allows you to choose specific tags to include but for command line ingest it will only have the option to include all tags.
If you wish to create additional report profiles, select "Make new profile" in the drop-down menu and then click the "Configure" button. You'll be prompted to name your new report profile and then will go through the normal report configuration. Having multiple report profiles will allow you to easily generate different report types from the command line. For example, you might have an "htmlReport" report profile that creates the HTML report and another report profile to generate KML reports. See the \ref command_line_report "report generation" section below for directions on how to specifiy a report profile on the command line.
\section command_line_ingest_commands Command Options
In a command prompt, navigate to the Autopsy bin folder. This is normally located at "C:\Program Files\Autopsy-version\bin".
\image html command_line_ingest_bin_dir.png
The table below shows a summary of the command line operations. You can run one or more at a time, though you must always either create a case or open an existing case.
<br>
<table>
<tr><th>Operation</th><th>Command(s)</th><th>Parameter(s)</th><th>Example</th></tr>
<tr><td><b>Create New Case</b><td><pre>--createCase</pre></td><td><pre>--caseName
--caseBaseDir
--caseType (optional)</pre></td><td><pre>--createCase --caseName="test5" --caseBaseDir="C:\work\cases"
--createCase --caseName="test_multi" --caseBaseDir="\\WIN-2913\work\cases" --caseType="multi"</pre></td></tr>
<tr><td><b>Open Existing Case</b></td><td>&nbsp;</td><td><pre>--caseDir</pre></td><td><pre>--caseDir="C:\work\Cases\test5_2019_09_20_11_01_29"</pre></td></tr>
<tr><td><b>Add a Data Source</b></td><td><pre>--addDataSource
--runIngest (optional)
--runIngest=(ingest profile name) (optional)</pre></td><td><pre>--dataSourcePath</pre></td><td><pre>--addDataSource --dataSourcePath="R:\work\images\small2.img" --runIngest</pre></td></tr>
<tr><td><b>Run Ingest on Existing Data Source</b><td><pre>--runIngest
--runIngest=(ingest profile name)</pre></td><td><pre>--dataSourceObjectId</pre></td><td><pre>--runIngest --dataSourceObjectId=1
--runIngest="imageAnalysis" --dataSourceObjectId=1</pre></td></tr>
<tr><td><b>Generate Reports</b></td><td><pre>--generateReports
--generateReports=(report profile name)</pre></td><td>&nbsp;</td><td><pre>--generateReports
--generateReports="kmlReport"</pre></td></tr>
<tr><td><b>Create List of Data Sources</b></td><td><pre>--listAllDataSources</pre></td><td>&nbsp;</td><td></td><pre>--listAllDataSources</pre></tr>
</table>
More details on each operation along with additional examples are given below.
\subsection command_line_cases Creating and Opening Cases
You will always need to either create a case or give the path to an existing case. When creating a case, the current timestamp will be added to the case name. For example, running this command:
\verbatim
autopsy64.exe --createCase --caseName="test5" --caseBaseDir="C:\work\cases"
\endverbatim
could create a case folder "test5_2019_09_20_11_01_29". Note that even though a timestamp is added to the name, the --caseName field must be unique for each run.
\image html command_line_ingest_case_folder.png
By default all cases will be single user. If you would like to create a multi-user case you'll need the -caseType field. You should also use the network path to your case folder so the services can access it:
\verbatim
autopsy64.exe --createCase --caseName="test_multi" --caseBaseDir="\\WIN-2913\work\cases" --caseType="multi"
\endverbatim
Once a case is created you will need to use the full path to the case instead of the case name and base folder. For example, if we created the empty case "test5" as above, we could use the following command to add a data source to it:
\verbatim
autopsy64.exe --caseDir="C:\work\Cases\test5_2019_09_20_11_01_29" --addDataSource
--dataSourcePath="R:\work\images\small2.img"
\endverbatim
The case type (single or multi-user) does not have to be specified when opening a case.
\subsection command_line_ds Adding a New Data Source and Running Ingest
You can add a data source to a new case or an existing case using the --addDataSource option and then giving the path to the data source. If you use the --runIngest option, the ingest modules you selected in the \ref command_line_ingest_config "configuration step" will be run on the data source. Both \ref ds_img "disk images" and \ref ds_log "logical files" are supported. You can only add one data source at a time.
In this example, we'll create a new case named "test6" and add the data source "blue_images.img".
\verbatim
autopsy64.exe --createCase --caseName="test6" --caseBaseDir="C:\work\cases" --addDataSource
--dataSourcePath="R:\work\images\blue_images.img"
\endverbatim
And here we'll add another data source ("green_images.img") to the case we just made and run ingest on it. Note that ingest will only run on the new data source ("green_images.img"), not the one already in the case ("blue_images.img").
\verbatim
autopsy64.exe --caseDir="C:\work\cases\test6_2019_09_20_13_00_51" --addDataSource --runIngest
--dataSourcePath="R:\work\images\green_images.img"
\endverbatim
Next we'll add a third data source ("red_images.img") to the case and run ingest using a custom ingest profile "imageAnalysis" created as described in the \ref command_line_ingest_profile "Configuring Ingest Profiles" section above.
\verbatim
autopsy64.exe --caseDir="C:\work\cases\test6_2019_09_20_13_00_51" --addDataSource --runIngest="imageAnalysis"
--dataSourcePath="R:\work\images\red_images.img"
\endverbatim
Finally we'll add a folder ("Test files") as a logical file set to a new case ("test9").
\verbatim
autopsy64.exe --createCase --caseName="test9" --caseBaseDir="C:\work\Cases" --addDataSource
--dataSourcePath="R:\work\images\Test files" --runIngest
\endverbatim
\subsection command_line_existing_ds Running Ingest on an Existing Data Source
You can run ingest on a data source already in the case if you know its object ID. To find this, go to the case folder and open the "Command Output" folder.
\image html command_line_ingest_output_folder.png
If you've run with the --listAllDataSources option, there will be at least one file starting "listAllDataSources". Open the most recent one - the format will be similar to this:
\verbatim
{
"@dataSourceName" : "blue_images.img",
"@dataSourceObjectId" : "1"
} {
"@dataSourceName" : "green_images.img",
"@dataSourceObjectId" : "84"
}
\endverbatim
You can also look through the addDataSource files to find the one corresponding to the file you want to ingest. The format will be the same. Once you know the data source object ID, you can use the --dataSourceObjectId option to specify it. For example, this will run ingest on "blue_images.img":
\verbatim
autopsy64.exe --caseDir="C:\work\cases\test6_2019_09_20_13_00_51" --runIngest --dataSourceObjectId=1
\endverbatim
\subsection command_line_report Generating Reports
You can generate a report on the case using the --generateReports option. You can select which report type to export through the Autopsy options panel (see the \ref command_line_ingest_config "configuration section"). This option can be run alone or at the same time as you're processing a data source. In this example we're adding a new data source ("small2.img") and generating a report.
\verbatim
autopsy64.exe --caseDir="C:\work\cases\test6_2019_09_20_13_00_51" --addDataSource
--dataSourcePath="R:\work\images\small2.img" --runIngest --generateReports
\endverbatim
The example above uses the default report profile. If you set up a custom report profile as described in the \ref command_line_report_profile "Configuring Ingest Profiles section" above, you can specify that profile after the --generateReports option.
\verbatim
autopsy64.exe --caseDir="C:\work\cases\test6_2019_09_20_13_00_51" --generateReports="html"
\endverbatim
\subsection command_line_listds Listing All Data Sources
You can add the --listAllDataSources at any time to output a list of all data sources currently in the case along with their object IDs, to be used when \ref command_line_existing_ds "running on an existing data source". This command can even be run alone with just the path to the case.
\verbatim
autopsy64.exe --caseDir="C:\work\cases\test6_2019_09_20_13_00_51" --listAllDataSources
\endverbatim
\section command_line_ingest_run Running Autopsy
Once you determine which parameters you need, it's time to run Autopsy. In the example below we're creating a new case ("xpCase"), adding a data source to it ("xp-sp3-v4.001"), running ingest and generating a report. The report type was \ref command_line_ingest_config "configured" earlier to be an HTML report.
\image html command_line_ingest_command_entry.png
If you've entered everything correctly, Autopsy will load and you'll see this dialog in the middle of the screen:
\image html command_line_ingest_dialog.png
If you entered something incorrectly you will likely see an error in the output. You'll want to compare what you ran with the descriptions and examples above to try to fix the error.
If everything works correctly, you'll see a log of the processing being done and Autopsy will close when finished.
\image html command_line_ingest_console_output.png
\section command_line_ingest_results Viewing Results
You can open the case you created directly from the command line by specifying either the case folder or the path to the ".aut" file. Remember that the folder name will have a timestamp appended to your case name.
\verbatim
autopsy64.exe "C:\work\cases\xpCase_2019_09_20_14_39_25"
autopsy64.exe "C:\work\cases\xpCase_2019_09_20_14_39_25\xpCase.aut"
\endverbatim
You can also open the case normally through Autopsy. Simply go to "Open Case" and then browse to the output folder you set up in the \ref command_line_ingest_config section and look for the folder starting with your case name. It will have a timestamp appended to the name you specified.
\image html command_line_ingest_open_case.png
If you are only interested in the reports then you don't need to open Autopsy. You can just browse to the "Reports" folder in the case and access the reports directly.
\image html command_line_ingest_report.png
*/

72
docs/doxygen-user_fr/common_files.dox Normal file
View File

@ -0,0 +1,72 @@
/*! \page common_properties_page Common Properties Search
[TOC]
\section common_properties_overview Overview
The Common Properties Search feature allows you to search for multiple copies of a property within the current case or within the \ref central_repo_page.
To start a search, go to Tools->Find Common Properties to bring up the main dialog. Searching requires at least one of the following to be true:
<ul>
<li> The current case has more than one data source
<li> The Central Repository contains at least two cases
</ul>
If both conditions are false, then the menu item will be disabled. If only one is false then part of the search dialog will be disabled.
\section common_properties_search_types Common Properties Search Scope
Different parameters are needed for setting up the two types of searches. These will be described below.
\subsection common_properties_intra_case Scope - between data sources in the current case
This type of search looks for files that are in multiple data sources within the current case. It does not require the Central Repository to be enabled, and currently only searches for common files. You must run the \ref hash_db_page to compute MD5 hashes on each data source prior to performing the search. The search results will not include any files that have been marked as "known" by the hash module (ex: files that are in the NSRL).
\image html common_properties_intra_case.png
By default, the search will find matching files in any data sources. If desired, you can change the search to only show matches where one of the files is in a certain data source by selecting it from the list:
\image html common_properties_select_ds.png
You can also choose to show any type of matching files or restrict the search to pictures and videos and/or documents.
Finally, if you have the Central Repository enabled you can choose to hide matches that appear with a high frequency in the Central Repository.
\subsection common_properties_central_repo Scope - between current case and cases in the Central Repository
This type of search looks for files that contain common properties between the current case and other cases in the Central Repository. You must run the Central Repository ingest module on each case with the property you want to search for enabled, along with the ingest modules that produce that property type (see \ref cr_manage_properties).
\image html common_properties_cr.png
You can restrict the search to only include results where at least one of the matches was in a specific case.
\image html common_properties_cr_case_select.png
In the example above, any matching properties would have to exist in the current case and in Case 2. Note that matches in other cases will also be included in the results, as long as the property exists in the current case and selected case.
You can select the type of property to search for in the menu below:
\image html common_properties_cr_property.png
Restricting a file search to only return images or documents is currently disabled.
You can choose to hide matches that appear with a high frequency in the Central Repository. Finally you can choose how to display the results, which will be described below.
\section common_properties_results Search Results
Each search displays its results in a new tab. The title of the tab will include the search parameters.
\subsection common_properties_sort_by_count Sort by number of data sources
\image html common_properties_result.png
This is how all results from searches within the current case are displayed, and an option for displaying the results of a search between the current case and the Central Repository. The top tree level of the results shows the number of matching properties. The results are grouped by how many matching properties were found and then grouped by the property itself.
\subsection common_properties_sort_by_case Sort by case
This option is only available when searching between the current case and the Central Repository. The top level shows each case with matching properties, then you can select which data source to view. Every matching property will be displayed under the data source.
\image html common_properties_result_case_sort.png
*/

83
docs/doxygen-user_fr/communications.dox Normal file
View File

@ -0,0 +1,83 @@
/*! \page communications_page Communications Visualization Tool
[TOC]
\section cvt_overview Overview
The Communications Visualization Tool gives a consolidated view of all communication events for the case. This allows an analyst to quickly view communications data such as:
<ul>
<li> The most commonly used accounts
<li> Communications within a specific time frame
</ul>
\section cvt_usage Usage
The Communications Visualization Tool is loaded through the Tools->Communications menu item.
\image html cvt_main.png
From the left hand column, you can choose which devices to display, which types of data to display, and optionally select a time range. You can also choose to limit the display to only the most recent communications. After any changes to the filters, use the Apply button to update the tables. You can hide this column by clicking the left arrow at the top of the column.
The middle column displays each account, its device and type, and the number of associated messages (emails, call logs, etc.). By default it will be sorted in descending order of frequency. The middle column and the right hand column both have a \ref ui_quick_search feature which can be used to quickly find a visible item in their section's table.
Selecting an account in the middle column will bring up the data for that account in the right hand column. There are four tabs that show information about the selected account.
<ul>
<li> The <b>Summary</b> tab displays counts of how many times the account has appeared in different data types in the top section. In the middle it displays the files this account was found in. If the \ref central_repo_page is enabled, you can see if any \ref personas_page "personas" are associated with this account and whether any other cases that contained this account.
\image html cvt_summary_tab.png
<li> The <b>Messages</b> tab displays any messages or call logs associated with the account. The Messages will either be in a thread, or listed under a node called "Unthreaded". Clicking on the "Unthreaded" node will show all the messages that are not "Threaded".
\image html cvt_messages_threaded.png
You can use the "All Messages" button at the bottom of the panel to show all messages. Clicking on a threaded message will show you all messages in that thread. You can click on an individual message to view it in the lower panel. Click the "Threads" button to return to the original screen.
\image html cvt_message_email.png
If the message has attachments, you can view them on the Attachments tab. If you select an attachment you can choose to open it in a new window, or you can look at it in the Thumbnails tab.
\image html cvt_message_attach.png
<li> The <b>Call Logs</b> tab shows all call log entries involving the selected account.
\image html cvt_call_log.png
<li> The <b>Contacts</b> tab shows any information on this account that was found in a contacts file.
\image html cvt_contacts.png
<li> The <b>Media Attachments</b> tab shows thumbnails of any media files in messages for that account. If you click on one, it will show the message the media file came from.
\image html cvt_media.png
</ul>
\section cvt_viz Visualization
The Visualize tab in the middle panel will show a graph of one or more accounts selected in the Browse tab.
To start, right click the first account you want to view.
\image html cvt_select_account.png
There are two options, which are equivalent when no accounts have previously been selected:
<ul>
<li>Add Selected Account to Visualization - Adds this account and its connections to the graph
<li>Visualize Only Selected Account - Clears the graph and only displays the connections for this account
</ul>
After selecting either option, the middle tab will switch to the Visualize view and the graph will be displayed.
\image html cvt_visualize.png
The options at the top allow you to clear the graph and resize the graph. The nodes in the graph can be dragged around and nodes and edges can be selected to display their messages or relationships in the right side tab. For example, in the image below only one node has been selected so the Messages viewer is displaying only messages involving that email address.
\image html cvt_links.png
If you click the "Snapshot Report" button, you can generate a report similar to the HTML \ref reporting_page "report module". Select a name for your report, which will be saved to the "Reports" folder in the current case. The Snapshot Report will contain two pages. The first will have a summary of the case, and second will contain the current graph along with your filter settings.
\image html cvt_snapshot.png
*/

61
docs/doxygen-user_fr/configuration.dox Normal file
View File

@ -0,0 +1,61 @@
/*! \page config_page Configuration générale
[TOC]
\section config_overview Aperçu
Vous pouvez configurer Autopsy via le panneau d'options principal. Ce dernier est accessible en allant dans Tools->Options. A cet endroit, vous pouvez modifier la façon dont les cas sont affichés, configurer le fonctionnement d’Autopsy, créer des ensembles de hachage, des listes de mots-clés, etc...
Le panneau d'options comporte différents onglets pour chaque fonction. Ces options sont documentées sur les pages principales de chaque fonctionnalité. Par exemple, l'onglet \ref keyword_search_configuration_dialog "Keyword Search" est décrit sur la page principale du \ref keyword_search_page. Les onglets qui ne correspondent pas à une fonctionnalité documentée ailleurs seront décrits ici.
\section config_app Application
Le premier onglet du panneau d'options concerne les paramètres généraux de l'application.
\image html options_application.png
La section supérieure vous permet d'ajuster la quantité de mémoire utilisée par Autopsy et le nombre de fichiers journaux à conserver. En général, chaque session d’Autopsy génère un fichier journal, bien qu’elle puisse en générer davantage si le fichier journal devient trop volumineux. Vous pouvez également spécifier un emplacement personnalisé dans lequel écrire des captures de tas ("heap dump").
La section suivante vous permet de spécifier où Autopsy doit stocker les fichiers temporaires. Ces fichiers seront supprimés lors de la clôture d'un dossier. Il existe trois options:
<ul>
<li>Local temp directory - Utilise le dossier temporaire du système (Sur Windows, typiquement C:\\Users\\(nom de l'utilisateur)\\AppData\\Local\\Temp\\Autopsy)
<li>Temp folder in case directory - Place les fichiers temporaires dans le répertoire "temp" situé dans le dossier de cas
<li>Custom - Utilisera le dossier donné par l'utilisateur comme base pour les fichiers temporaires
</ul>
La dernière section vous permet de définir un logo personnalisé.
\image html options_logo.png
Ce logo sera affiché dans tous les \ref report_html "rapports HTML" générés.
\image html options_logo_report.jpg
La section suivante répertorie les instructions sur la façon de modifier la mise à l'échelle pour les systèmes Windows à PPP élevé.
\section config_view View
Consultez la page \ref view_options_page pour une description de la façon dont vous pouvez personnaliser les données affichées dans Autopsy.
\section config_ext_viewer External Viewers
L'onglet "External Viewer" vous permet d'ajouter des associations de fichiers et de sélectionner un éditeur hexadécimal.
\image html options_ext_viewer.jpg
La section supérieure vous permet de saisir des associations de fichiers personnalisées par extension ou par type MIME. Dans l'image ci-dessus, nous avons associé des fichiers .xml à l'application Bloc-notes. Il est maintenant possible de faire un clic droit sur un fichier .xml dans la visionneuse de résultats et de choisir "Open in External Viewer" pour ouvrir ce fichier .xml dans le Bloc-notes.
\image html options_ext_viewer_context_menu.jpg
La section inférieure vous permet de spécifier un éditeur hexadécimal. HxD a été testé et est la valeur par défaut, mais d'autres éditeurs hexadécimaux fonctionneront également. L'éditeur hexadécimal sélectionné sera lancé en cliquant sur le bouton "Launch in HxD" dans l'onglet «Hex» de la \ref content_viewer_page.
\section config_general General
L'onglet "General" vous permet de configurer les paramètres du proxy.
\image html proxySettings.PNG
*/

117
docs/doxygen-user_fr/content_viewer.dox Normal file
View File

@ -0,0 +1,117 @@
/*! \page content_viewer_page Content Viewer
[TOC]
The Content Viewer lives in the lower right-hand side of the Autopsy main screen and shows pictures, video, hex, text, extracted strings, metadata, etc. The Content Viewer is populated when you select an entry in the \ref ui_results.
The Content Viewer is context-aware, meaning different tabs will be enabled depending on the type of content selected and which ingest modules have been run. It will default to what it considers the "most specific" tab. For example, selecting a JPG will cause the Content Viewer to automatically select the "Application" tab and will display the image there. If you instead would like the Content Viewer to stay on the previously selected tab when you change to a different content object, go to the \ref view_options_page panel through Tools->Options->Application Tab and select the "Stay on the same file viewer" option.
\image html content_viewer_options_panel.png
When a result item is selected in the Result Viewer (as opposed to a file), most of the tabs will correspond to the file associated with the result and not the result itself. For example, when selecting a keyword hit, the "Hex", "Strings", and "File Metadata" tabs will show data from the file where the keyword was found. The descriptions below will generally assume a file has been selected, but most also apply when we have a file associated with a selected result.
\section cv_hex Hex
The Hex tab is nearly always available and shows you the raw and exact contents of a file. In this tab, the data of the file is represented as hexadecimal values grouped in 2 groups of 8 bytes, followed by one group of 16 ASCII characters which are derived from each pair of hex values (each byte). Non-printable ASCII characters and characters that would take more than one character space are typically represented by a dot (".") in the following ASCII field.
\image html content_viewer_hex.png
If desired, you can open the file in an external hex editor. This is configured through the \ref config_ext_viewer tab on the options panel. HxD has been verified to work with Autopsy, but alternate hex editors may also be compatible.
Note that this process saves the file to disk before launching the hex editor. A progress indicator will be displayed in the lower right corner of the application. If you wish to cancel the file export, click the 'X' to the right of the progress bar.
\image html content_viewer_hxd_progress.png
\section cv_text Text
The Text tab has three sub tabs for displaying the text contained in the selected item.
\subsection cv_strings Strings
The Strings tab shows all text strings found in the file for the given script selected in the upper right. By default Latin text is used.
\image html content_viewer_strings_latin.png
Different scripts can be chosen from the drop-down menu to display results for non-Latin alphabets.
\image html content_viewer_strings_cyrillic.png
\subsection cv_indexed_text Indexed Text
The Indexed Text tab shows the text that has been indexed by the \ref keyword_search_page. You can switch the "Text Source" field to "Result Text" to see the text that has been indexed for the results associated with a file.
\image html content_viewer_indexed_text.png
\subsection cv_translation Translation
If you have a translation service enabled, the Translation tab allows you to translate the text. See the \ref machine_translation_page page for more information.
\section cv_app Application
For certain file types, the Application tab can display the contents in a user friendly format. The following screenshots show some examples of what the Application tab will display.
It will display most image types, which can be scaled and rotated:
\image html content_viewer_app_image.png
It displays video files, allowing you to move play/pause, move forward or backward 30 seconds, adjust the volume, and change the playback speed.
\image html content_viewer_video.png
It also allows you to browse SQLite tables and export their contents as CSV:
\image html content_viewer_app_sqlite.png
And plist file data will be shown and can be exported:
\image html content_viewer_app_plist.png
HTML files can be displayed closer to their original form:
\image html content_viewer_html.png
Registry hive files can be viewed in a format similar to a registry editor.
\image html content_viewer_registry.png
\section cv_metadata File Metadata
The File Metadata tab displays basic information about the file, such as type, size, and hash. It also displays the output of the Sleuth Kit istat tool.
\image html content_viewer_metadata.png
\section cv_os_account OS Accounts
The OS Accounts tab displays information on the OS account associated with a given result, if present. It is also used to give details on accounts listed under the OS Accounts node in the tree.
\image html content_viewer_os_account.png
\section cv_results Results
The Results tab is active when selecting items with associated results such as keyword hits, call logs, and messages. The exact fields displayed depend on the type of result. The two images below show the Results tab for a call log and a web bookmark.
\image html content_viewer_results_call.png
<br>
\image html content_viewer_results_bookmark.png
\section cv_context Context
The Context tab shows information on where a file came from and allows you to navigate to the original result. For example, it can show the the URL for downloaded files and the email message a file was attached to. In the image below you can see the context for an image that was sent as an email attachment.
\image html content_viewer_context.png
\section cv_annotations Annotations
The Annotations tab shows information added by an analyst about a file or result. It displays any tags and comments associated with the file or result, and if the \ref central_repo_page is enabled it will also display any comments saved to the Central Repository.
\image html content_viewer_annotations.png
\section cv_other_occurrences Other Occurrences
The Other Occurrences tab shows other instances of this file or result. Enabling the \ref central_repo_page adds additional functionality to this tab. See the \ref cr_content_viewer section for more information.
\image html content_viewer_other_occurrences.png
*/

54
docs/doxygen-user_fr/data_source_integrity.dox Normal file
View File

@ -0,0 +1,54 @@
/*! \page data_source_integrity_page Data Source Integrity Module
[TOC]
\section data_source_integrity_overview Overview
The Data Source Integrity module has two purposes:
<ul>
<li>If the data source has any hashes associated with it (either user-entered or contained in an E01 file), it will verify these hashes
<li>If the data source has no associated hashes, it will calculate the hashes and store them in the database
</ul>
\section data_source_integrity_running Running the module
If you wish to verify hashes, the first step is to enter hashes for your disk image (unless you have an E01 file - the hash is included in the data source).
You can do this in the Add Data Source wizard where you select your disk image.
\image html data_source_integrity_add_ds.png
You can enter any combination of hashes to be verified.
You'll next need to configure the ingest module.
\image html data_source_integrity_ingest_settings.png
Note that this is simply enabling one or both behaviors, not choosing which one to run (compute vs. verify). That is determined solely by whether the data source
has associated hashes. Unchecking both boxes but leaving the module enabled will lead to an ingest module startup error
\section data_source_integrity_results Viewing results
\subsection data_source_integrity_verification Hash verification
When verifying, if the check succeeds you'll see an inbox message confirming it. If you open the message you'll see the stored and computed hash values.
\image html data_source_integrity_pass1.png
<br>
\image html data_source_integrity_pass2.png
If the verification fails, you'll see an inbox message in yellow and the same message in a pop-up warning bubble.
\image html data_source_integrity_failed_inbox.png
The inbox messages will disappear after the case is closed, so the module also adds a "Verification Failed" artifact added to the case.
\image html data_source_integrity_failed_artifact.png
\subsection data_source_integrity_computation Hash computation
To view the calculated hashes, select "Data Sources" in the tree, select your data source in the result viewer, and then open the "File Metadata" tab. If you're in "Group by data source" mode (see \ref view_options_page), select "Data Source Files" under the data source you want to examine.
\image html data_source_integrity_metadata.png
*/

89
docs/doxygen-user_fr/data_source_summary.dox Normal file
View File

@ -0,0 +1,89 @@
/*! \page data_source_summary_page Data Source Summary
[TOC]
\section ds_summary_overview Overview
The Data Source Summary viewer allows you to see an overview of file types, results, and other information for a particular data source.
\section ds_summary_opening Opening the Data Source Summary
There are two ways to view the data source summary. The first is to go to Case->Data Source Summary. This will open the summary in a new window.
\image html ds_summary_window.png
The second way to view the summary is to select the data source in the \ref tree_viewer_page and then select the "Summary" tab in the \ref result_viewer_page.
\image html ds_summary_result_viewer.png
\section ds_summary_main Sections
Each tab of the data source summary displays different types of information about the selected data source. If ingest is ongoing, the summary will be updated periodically as new data is available.
If the ingest module(s) required for a data type have not been run, you will see a note about why there is no data. For example, "Recent Programs" results are created by the \ref recent_activity_page, so you will see a message about running that module if you have not.
\image html DataSourceSummary/ds_summary_noRA.png
\subsection ds_summary_types Types
The Types tab shows counts of different file types found in the data source.
\image html ds_summary_types.png
\subsection ds_summary_user_activity User Activity
The User Activity tab shows the most recent results found in the data source. You can right click on a row to navigate directly to the corresponding result.
\image html ds_summary_user_activity.png
\subsection ds_summary_analysis Analysis
The Analysis tab shows the sets with the most results from the \ref hash_db_page, the \ref keyword_search_page, and the \ref interesting_files_identifier_page.
\image html ds_summary_analysis.png
\subsection ds_summary_recent_files Recent Files
The Recent Files tab shows information on the most recent files opened and downloaded. You can right click on a row to navigate directly to the corresponding file or result.
\image html ds_summary_recent_files.png
\subsection ds_summary_past_cases Past Cases
The Past Cases tab shows which cases had results or notable files in common with the current data source. This is based on the results in the "Interesting Items" section of the Results section in the \ref tree_viewer_page. The \ref central_repo_page ingest module must have been run with the options to "Flag items previously tagged as notable" and "Flag devices previously seen in other cases" enabled.
\image html ds_summary_past_cases.png
Note that because these entries are based on the Interesting Items results created during ingest and not querying the central repository, they will not reflect any matches in cases processed after this case. For example, suppose we create Case A and ingest a data source with Device Z. If we make a new case Case B afterward and ingest a data source that also has Device Z, we would see Case A listed in this tab for Case B, but if we reopened Case A we would not see Case B listed unless ingest was run again.
\subsection ds_summary_geo Geolocation
The Geolocation tab uses the coordinates from geolocation results to find the nearest city for each and displays the most recent cities and most common cities. If the location is more than 150 km from a city then it will be displayed as "Unknown". The "View in Map" button under the recent cities table will open the \ref geolocation_page "Geolocation window" showing all waypoints for this data source with timestamps in the last 30 days. The "View in Map" button under the most common cities will show all waypoints for this data source.
\image html ds_summary_geo.png
\subsection ds_summary_timeline Timeline
The Timeline tab shows a simplified version of the \ref timeline_page "Timeline Viewer" for the selected data source. It will show events for the last 30 days of activity in the data source and give the first and last dates of activity. "File events" represent file creation, modification, access, and change. "Result events" represent the results from running ingest, such as the time a message was sent or when a URL was accessed. The "View in Timeline" button will open the main \ref timeline_page "Timeline Viewer".
\image html ds_summary_timeline.png
\subsection ds_summary_ingest_history Ingest History
The Ingest History tab shows which ingest modules have been run on the data source and the version of each module.
\image html ds_summary_ingest.png
\subsection ds_summary_container Container
The Container tab displays information on the data source itself, such as the size and image paths.
\image html ds_summary_container.png
\subsection ds_summary_export Export
The Export tab allows you to export the contents of the other data source summary tabs to an Excel-formatted file.
\image html ds_summary_export.png
*/

154
docs/doxygen-user_fr/data_sources.dox Normal file
View File

@ -0,0 +1,154 @@
/*! \page ds_page Data Sources
[TOC]
A data source is the thing you want to analyze. It can be a disk image, some logical files, a local disk, etc. You must open a case prior to adding a data source to Autopsy.
Autopsy supports multiple types of data sources:
- Disk Image or VM File: A file (or set of files) that is a byte-for-byte copy of a hard drive or media card, or a virtual machine image. (see \ref ds_img)
- Local Disk: Local storage device (local drive, USB-attached drive, etc.). (see \ref ds_local)
- Logical Files: Local files or folders. (see \ref ds_log)
- Unallocated Space Image Files: Any type of file that does not contain a file system but you want to run through ingest (see \ref ds_unalloc)
- Autopsy Logical Imager Results: The results from running the logical imager. (see \ref ds_logical_imager)
- XRY Text Export: The results from exporting text files from XRY. (see \ref ds_xry)
\section ds_add Adding a Data Source
You can add a data source in several ways:
- After you create a case, it automatically prompts you to add a data source.
- There is a toolbar item to add a Data Source when a case is open.
- The "Case", "Add Data Source" menu item when a case is open.
The data source must remain accessible for the duration of the analysis because the case contains a reference to the data source. It does <b>not</b> copy the data source into the case folder.
Regardless of the type of data source, there are some common steps in the process:
<ol>
<li> You will choose the host for the data source you are going to add. See the \ref host_page "hosts page" for more information about hosts.
\image html data_source_host_select.png
There are three options:
<ul>
<li> <b>Generate new host based on data source name</b> - this will typically create a host with a name similar to your data source with the ID used in the database appended for uniqueness.
<li> <b>Specify new host name</b> - this allows you to enter a host name.
<li> <b>Use existing host</b> - this allows you to choose a host name already in use in the current case.
</ul>
<li> You will select the type of data source.
\image html select-data-source-type.PNG
<li> You will be prompted to specify the data source to add. This screen varies based on the data source type. Details on adding each type of data source are provided below.
NOTE: If you are adding a data source to a multi-user case, ensure that all Autopsy clients will have access to the data source at the same path. We recommend using UNC paths to ensure this consistent mapping.
<li> Next you will be prompted with a list of ingest modules to enable. If one or more ingest profiles have been saved, there will be a screen before this asking whether to use one of the saved profiles or do a custom setup. See \ref ingest_page for more information on setting up ingest profiles.
\image html select-ingest-modules.PNG
<li> You will need to wait while Autopsy performs a basic examination of the data source and populates an embedded database with an entry for each file in the data source.
\image html data-source-progress-bar.PNG
<li> After the basic examination of the data source is complete, the ingest modules will likely still be running but you can start browsing through the files in your data source.
</ol>
Data sources can be removed from cases created with Autopsy 4.14.0 and later. See the section \ref data_source_deletion "below".
\section ds_img Adding a Disk Image
Autopsy supports disk images in the following formats:
- Raw Single (*.img, *.dd, *.raw, *.bin)
- Raw Split (*.001, *.aa)
- EnCase (*.e01)
- Virtual Machine Disk (*.vmdk)
- Virtual Hard Disk (*.vhd)
\image html data_source_disk_image.png
To add a disk image:
<ol>
<li>Choose "Disk Image or VM File" from the data source types.
<li>Browse to the first file in the disk image. You need to specify only the first file and Autopsy will find the rest. <li>Choose to perform orphan file finding on FAT file systems. This can be a time intensive process because it will require that Autopsy look at each sector in the device.
<li>Choose the timezone that the disk image came from. This is most important for when adding FAT file systems because it does not store timezone information and Autopsy will not know how to normalize to UTC.
<li>Optionally choose the sector size. The Auto Detect mode will work correctly on the majority of images, but if adding the data source fails you may want to try the other sector sizes.
<li>Optionally enter one or more hashes for the image. These will be saved under the image metadata and can be verified using the \ref data_source_integrity_page.
</ol>
\section ds_local Adding a Local Disk
Autopsy can analyze a local disk without needing to first make an image copy of it. This is most useful when analyzing a USB-attached device through a write blocker.
Note that if you are analyzing a local disk that is being updated, then Autopsy will not see files that are added after you add it as a data source.
You will need to be running Autopsy as an Administrator to view all devices.
There is an option to make a copy of the local disk as a VHD during analysis. This VHD can be loaded in Windows or analyzed through Autopsy. There is an additional option to update the image path in the case database to this newly created file. Enabling this option will allow you to browse the case data normally even after the local disk is removed. Note that at least one ingest module must successfully run in order to generate the complete image copy.
\image html local-disk-data-source.PNG
To add a local drive:
-# Choose "Local Disk" from the data source types.
-# Use the "Select Disk" button to open a dialog showing the local disks. This may take a minute to load. Then select the device from the list.
-# Choose to perform orphan file finding. See comment in \ref ds_img about this setting.
-# Choose whether to create a VHD copy of the local disk and whether to update the image path.
-# Optionally choose the sector size. The Auto Detect mode will work correctly on the majority of images, but if adding the data source fails you may want to try the other sector sizes.
\section ds_log Adding a Logical File
You can add files or folders that are on your local computer (or on a shared drive) without putting them into a disk image. This is useful if you have only a collection of files that you want to analyze.
Some things to note when doing this:
- Autopsy ignores the time stamps on files that it adds this way because they could be the timestamps when they were copied onto your examination device.
- If you have a USB-attached device that you are analyzing and you choose to add the device's contents using this method, then note that it will not look at unallocated space or deleted files. Autopsy will only be able to see the allocated files. You should add the device as a "Logical Drive" to analyze the unallocated space.
- You can modify the name of the Logical File Set from the default LogicalFileSet# by clicking the "Change" button as shown in the screenshot below:
\image html change_logical_file_set_display_name.PNG
To add logical files:
-# Choose "Logical Files" from the data source types.
-# Leave the top combo box on "Local files and folders"
-# Press the "Add" button and navigate to a folder or file to add. Choosing a folder will cause all of its contents (including sub-folders) to be added.
-# Continue to press "Add" until all files and folders have been selected.
All of the files that you added in the panel will be grouped together into a single data source, called "LogicalFileSet" in the main UI.
There is also limited support for logical evidence (L01) files. To add one as a data source, select "Logical evidence file (L01)" in the top combo box and then browse to your file.
\section ds_unalloc Adding an Unallocated Space Image File
\image html unallocated_space_options.PNG
To add unallocated space image files:
-# Choose "Unallocated Space Image File" from the data source types.
-# Browse to the file.
-# Choose whether to break the image up into chunks. Breaking the image up will give better performance since the chunks can be processed in parallel, but there is a chance that keywords or carved files that span chunk boundaries will be missed.
\section ds_logical_imager Adding an Autopsy Logical Imager Result
This option allows you to add the results of a logical imager collection. See the \ref logical_imager_page page for details.
\section ds_xry Adding XRY Text Export Data
An XRY text export folder is expected to look similar to this:
\image html xry_folder.png
To add exported text files:
-# Choose "XRY Text Export" from the data source types.
-# Browse to the folder containing the text files.
\image html xry_dsp.png
\section data_source_deletion Deleting Data Sources
As of Autopsy 4.14.0, data sources can be removed from cases. Removing a data source will delete all files associate with the data source, as well as all results from running ingest modules, tags, and timeline data. \ref reporting_page "Reports" will not be deleted, as most are not associated with a specific data source. If a new data source was created while processing another (from the \ref vm_extractor_page for example), this new data source will also be deleted if its parent is deleted.
To delete a data source, right click it in either the \ref tree_viewer_page or the \ref result_viewer_page and select "Remove Data Source". If the case was originally created with a version of Autopsy earlier than 4.14.0 then this option will be disabled. After a confirmation dialog, the case will close and then reopen after the data source has been removed.
\image html data_source_delete.png
*/

35
docs/doxygen-user_fr/drone.dox Normal file
View File

@ -0,0 +1,35 @@
/*! \page drone_page DJI Drone Analyzer
[TOC]
\section drone_overview Overview
The DJI Drone Analyzer module allows you to analyze files from a drone.
Currently, the DJI Drone Analyzer module works on images obtained from the internal SD card found in the following DJI drone models:
- Phantom 3
- Phantom 4
- Phantom 4 Pro
- Inspire 1
- Inspire 2
- Mavic Pro
- Mavic Air
The module will find DAT files and process them using DatCon (https://datfile.net/DatCon/intro.html).
\section drone_config Running the Module
To enable the DJI Drone Analyzer ingest module select the checkbox in the \ref ingest_configure "Ingest Modules configuration screen".
\section drone_results Viewing Results
Results are show in the Results tree under "Extracted Content".
\image html gps_track_artifact.png
GPS results can also be seen in the \ref geolocation_page window and the KML Report.
\image html geolocation_drone_path.png
*/

39
docs/doxygen-user_fr/email_parser.dox Normal file
View File

@ -0,0 +1,39 @@
/*! \page email_parser_page Email Parser Module
[TOC]
What Does It Do
========
The Email Parser module identifies MBOX, EML and PST format files based on file signatures, extracting the e-mails from them, adding the results to the Blackboard. This module skips known files and creates a Blackboard artifact for each message. It adds email attachments as derived files.
This allows the user to identify email-based communications from the system being analyzed.
Configuration
=======
There is no configuration required.
Using the Module
======
Explore the "Results", "E-Mail Messages" portion of the tree to review the results of this module.
Ingest Settings
------
There are no runtime ingest settings required.
Seeing Results
------
The results of this show up in the "Results", "E-Mail Messages" portion of the \ref tree_viewer_page.
\image html email_results.PNG
If an e-email has an attachment, the "Attachments" tab in the \ref content_viewer_page will be active.
\image html email_attachments.png
You can right click and select "View File in Directory" to navigate to the attached file. You can also switch to the "Thumbnails" tab to see a preview of any image attachments.
*/

43
docs/doxygen-user_fr/encryption_detection.dox Normal file
View File

@ -0,0 +1,43 @@
/*! \page encryption_page Encryption Detection Module
[TOC]
\section encrypt_overview Overview
The Encryption Detection Module searches for files that could be encrypted using both a general entropy calculation and more specialized tests for certain file types.
\section encrypt_running Running the module
The module's settings can be configured at runtime. These settings only effect the tests that are based on entropy.
\image html encrypt_module.png
Minimum entropy can be set higher or lower, depending on how many false hits are being produced. There is also an option to only run the test on files whose size is a multiple of 512, which is useful for finding certain encryption algorithms.
The module looks for the following types of encryption:
<ul>
<li> Any file that has an entropy equal to or greater than the threshold in the module settings and that fits the file size constraints
<li> Password protected Office files, PDF files, and Access database files
<li> BitLocker volumes
<li> SQLCipher (uses the minimum entropy from the module settings)
<li> VeraCrypt (uses the minimum entropy from the module settings)
</ul>
\section encrypt_results Viewing results
Files that pass the tests are shown in the Results tree under "Encryption Detected" or "Encryption Suspected". Generally, if the test used involved looking for a
specific header/file structure, the result will be "Encryption Detected" and the type of encryption will be displayed in the Comment field. If the test was based on the entropy of the file,
the result will be "Encryption Suspected" and the calculated entropy will be displayed in the Comment field.
\image html encrypt_tree.png
Each hit also generates an inbox message. These are viewed through the warning triangle near the top of the screen.
\image html encrypt_inbox.png
Selecting one of the encryption detection hits displays the calculated entropy of the file.
\image html encrypt_entropy.png
*/

16
docs/doxygen-user_fr/experimental.dox Normal file
View File

@ -0,0 +1,16 @@
/*! \page experimental_page Experimental Module
[TOC]
\section exp_overview Overview
The Experimental module, as the name implies, contains code that is not yet part of the official Autopsy release. These experimental features can be used but may be less polished than other features and will have less documentation. These modules may be changed at any time.
\section exp_setup Enabling the Experimental Module
To start, go to Tools->Plugins and select the "Installed" tab, then check the box next to "Experimental" and click "Activate" and go through the next couple of screens. A restart should not be required.
\image html experimental_plugins_menu.png
*/

42
docs/doxygen-user_fr/extension_mismatch.dox Normal file
View File

@ -0,0 +1,42 @@
/*! \page extension_mismatch_detector_page Extension Mismatch Detector Module
[TOC]
What Does It Do
========
Extension Mismatch Detector module uses the results from the File Type Identification and flags files that have an extension not traditionally associated with the file's detected type. It ignores 'known' (NSRL) files. You can customize the MIME types and file extensions per MIME type in "Tools", "Options", "File Extension Mismatch".
This detects files that someone may be trying to hide.
Configuration
=======
One can add and remove MIME types in the "Tools", "Options", "File Extension Mismatch" dialog box, as well as add and remove extensions to particular MIME types.
<br>
\image html extension-mismatch-detected-configuration.PNG
<br>
If you'd like to contribute your changes back to the community, then you'll need to upload your updated %APPDATA%\\autopsy\\dev\\config\\mismatch_config.xml file by either:
- Make a fork of the Github Autopsy repository, copy the new file into the src\\org\\sleuthkit\\autopsy\\fileextmismatch folder and submit a pull request
- Attach the entire mismatch_config.xml file to a github issue.
Using the Module
======
Note that you can get a lot of false positives with this module. You can add your own rules to Autopsy to reduce unwanted hits.
Ingest Settings
------
In the ingest settings, the user can choose whether to run on all files, all files except text files, or only multimedia or executable files. Additionally, the user can choose to skip all files without an extension, and to skip any known files identified by the hash lookup module, if it is enabled.
\image html extension-mismatch-detected-ingest-settings.PNG
Seeing Results
------
Results are shown in the Results tree under "Extension Mismatch Detected".
\image html extension-mismatch-detected.PNG
*/

236
docs/doxygen-user_fr/file_discovery.dox Normal file
View File

@ -0,0 +1,236 @@
/*! \page discovery_page Discovery
[TOC]
\section file_disc_overview Overview
The discovery tool shows images, videos, documents, or domains that match a set of filters configured by the user. You can choose how to group and order your results in order to see the most relevant data first.
\section file_disc_prereq Prerequisites
We suggest running all \ref ingest_page "ingest modules" before launching discovery, but if time is a factor the following are the modules that are the most important. You will see a warning if you open discovery without running the \ref file_type_identification_page, the \ref hash_db_page, and the \ref EXIF_parser_page.
Required ingest modules:
<ul>
<li>\ref file_type_identification_page for image, video, and document searches
<li>\ref recent_activity_page or one of the mobile parsers (\ref android_analyzer_page, \ref ileapp_page, \ref aleapp_page) for domain searches
</ul>
Optional ingest modules:
<ul>
<li>\ref cr_ingest_module - Needed to use the \ref file_disc_occur_filter
<li> \ref EXIF_parser_page - Needed to use the \ref file_disc_user_filter
<li>\ref hash_db_page - Needed to use the \ref file_disc_hash_filter and to de-duplicate files
<li>\ref interesting_files_identifier_page - Needed to use the \ref file_disc_int_filter
<li>\ref object_detection_page - Needed to use the \ref file_disc_obj_filter
<li>\ref keyword_search_page - Improves document summaries
<li>\ref embedded_file_extractor_page - Allows display of an image contained in a document
</ul>
\section file_disc_run Running Discovery
To launch discovery, either click the "Discovery" icon near the top of the Autopsy UI or go to "Tools", "Discovery". There are three steps when setting up discovery, which flow from the top of the panel to the bottom:
<ol>
<li>\ref file_disc_type "Choose the result type"
<li>\ref file_disc_filtering "Set up filters"
<li>\ref file_disc_grouping "Choose how to group and sort the results
</ol>
\image html FileDiscovery/fd_setup.png
Once everything is set up, use the "Search" button at the bottom right to display your results.
\image html FileDiscovery/fd_main.png
\subsection file_disc_type Result Type
The first step is choosing whether you want to display images, videos, documents, or domains. The first three (images, videos, and documents) will return file results of the given type. The file type is determined by the MIME type of the file, which is why the \ref file_type_identification_page must be run to see any results. Switching between the result types will reset the filters.
\image html FileDiscovery/fd_fileType.png
\subsection file_disc_filtering Filtering
The second step is to select and configure your filters. The available filters will vary depending on the result type. For most filters, you enable them using the checkbox on the left and then select the checkboxes next to the options you want to be enabled. The "Check All" and "Uncheck All" buttons can be used to check or uncheck all options in the list. Results must pass all enabled filters to be displayed.
\subsubsection file_disc_size_filter File Size Filter
The file size filter lets you restrict the size of your results. The options are different for the different file types - an extra small image might be under 16 KB while an extra small video is anything under 500 KB.
\image html FileDiscovery/fd_fileSizeFilter.png
\subsubsection file_disc_ds_filter Data Source Filter
The data source filter lets you restrict which data sources in your case to include in the results.
\image html FileDiscovery/fd_dataSourceFilter.png
\subsubsection file_disc_occur_filter Past Occurrences Filter
The past occurrences filter uses the \ref central_repo_page "central repository" and \ref hash_db_page "known hash sets" (for file type searches) to restrict how commom/rare an entry must be to be included in the results. For file type searches the "Known Files" option is disabled by default, meaning that any file matching the NSRL or other white-listed hash set will not be displayed.
\image html FileDiscovery/fd_pastOccur.png
The counts for the rest of the options are based on how many data sources in your central repository contain a copy of this file (based on hash) or domain. If a result only appears in one data source in the current case, then it will match "Unique(1)". If it has only been seen in a few other data source, it will match "Rare(2-10)". Note that it doesn't matter how many times a result appears in each data source - a result could have twenty copies in one data source and still be "unique".
\subsubsection file_disc_user_filter Possibly User Created
The possibly user created filter restricts the results to files that suspected to be raw images or videos.
\image html FileDiscovery/fd_userCreatedFilter.png
This means the file must have a "User Content Suspected" result associated with it. These primarily come from the \ref EXIF_parser_page.
\image html FileDiscovery/fd_userContentArtifact.png
\subsubsection file_disc_hash_filter Hash Set Filter
The hash set filter restricts the results to files found in the selected hash sets. Only notable hash sets that have hits in the current case are listed. See the \ref hash_db_page page for more information on creating and using hash sets.
\image html FileDiscovery/fd_hashSetFilter.png
\subsubsection file_disc_int_filter Interesting Item Filter
The interesting item filter restricts the results to files found in the selected interesting item rule sets. Only interesting file rule sets that have results in the current case are listed. See the \ref interesting_files_identifier_page page for more information on creating and using interesting item rule sets.
\image html FileDiscovery/fd_interestingItemsFilter.png
\subsubsection file_disc_obj_filter Object Detected Filter
The object detected filter restricts the results to files that matched the selected classifiers. Only classifiers that have results in the current case are listed. Note that currently the built-in \ref object_detection_page ingest module only works on images, so you should generally not use this filter with videos. See the \ref object_detection_page page for more information on setting up classifiers.
\image html FileDiscovery/fd_objectFilter.png
\subsubsection file_disc_parent_filter Parent Folder Filter
The parent folder filter either restricts the path the files can be on. This filter works differently than the others in that the individual options do not have to be selected - every rule that has been entered will be applied.
\image html FileDiscovery/fd_parentFilter.png
You can enter paths that should be included and paths that should be ignored. For both you then specify whether the path string you entered is a full path or a substring. For full path matches you'll need to include the leading and trailing slashes. Full path matches are also case-sensitive.
The default options, shown above, will exclude any file that has a "Windows" folder or a "Program Files" folder in its path. It would exclude files like "/Windows/System32/image1.jpg" but would not exclude "/My Pictures/Bay Windows/image2.jpg" because the slashes around "Windows" force it to match the exact folder name.
Here is another example. This rule was created with "Full" and "Include" selected.
\image html FileDiscovery/fd_parentEx2.png
This matches the file "/LogicalFileSet2/File Discovery/bird1.tif" but not any images in subfolders under "File Discovery".
When there are multiple path options in the filter, they will be applied as follows:
<ul>
<li>The file path must match every "exclude" rule to pass
<li>If any "include" rules exist, the file path must match at least one "include" rule to pass
</ul>
This allows you to, for example, make rules to include both the "My Documents" and the "My Pictures" folders.
\subsubsection file_disc_prev_notable_filter Previously Notable Filter
The previously notable filter is for domain searches only and is used to restrict results to only those domains that have previously been marked as "Notable" in the \ref central_repo_page.
\image html FileDiscovery/fd_notableFilter.png
\subsubsection file_disc_known_account_filter Known Account Type Filter
The known account type filter is for domain searches only and is used to restrict results to only those domains that have a known account type.
\image html FileDiscovery/fd_knownAccountFilter.png
\subsubsection file_disc_result_filter Result Type Filter
The result type filter is for domain searches only and can be used to restrict which types of web results the domains can come from.
\image html FileDiscovery/fd_domainResultFilter.png
\subsubsection file_disc_date_filter Date Filter
The date filter is for domain searches only and restricts the search to domains that were accessed within a given time frame. This time frame can either be the last N days (relative to the current date) or have a specific start and/or end date.
\image html FileDiscovery/fd_dateFilter.png
\subsection file_disc_grouping Grouping and Sorting
The final options are for how you want to group and sort your results.
\image html FileDiscovery/fd_grouping.png
The first option lets you choose the top level grouping for your results and the second option lets you choose how to sort them. The groups appear in the left column of the results window. Note that some of the grouping options may not always appear - for example, grouping by past occurrences will only be present if the \ref central_repo_page is enabled, and grouping by hash set will only be present if there are hash set hits in your current case. The example below shows the groups created using the default options (Image search, group by file size, order groups by group name):
\image html FileDiscovery/fd_groupingSize.png
In the case of file size and past occurrences, ordering by group name is based on the natural ordering of the group (largest to smallest or most rare to most common). For the other groups it will be alphabetical. Ordering groups by size will sort them based on how many files each group contains, going largest to smallest. For example, here we've grouped by interesting item set and ordered the groups by their size.
\image html FileDiscovery/fd_groupingInt.png
The interesting items filter was not enabled so most images ended up in the "None" group, meaning they have no interesting file result associated with them. The final group in the list contains a file that matched both interesting item rule sets.
The last grouping and sorting option is choosing how to sort the results within a group. This is the order of the results on the right side of the results window after selecting a group from the left column. Note that due to the merging of results with the same hash in that panel, ordering by file name, path, or data source can vary. See the \ref file_disc_dedupe section below for more information.
\section file_disc_results Viewing Results
\subsection file_disc_results_overview Overview
Once you select your options and click "Search", you'll see a new window with the list of groups on the left side. Selecting one of these groups will display the results from that group on the right side. Selecting a result will cause a panel to rise showing more details about each instance of that result. You can manually raise and lower this panel using the large arrows on the right side of the divider.
If your results are images, you'll see thumbnails for each image in the top area of the right panel.
\image html FileDiscovery/fd_resultGroups.png
If your results are videos, each result will display four thumbnails from the video.
\image html FileDiscovery/fd_videos.png
If your results are documents, you'll see part of the document text. If the \ref embedded_file_extractor_page found any images in the document you'll see a thumbnail of the largest of them displayed on the right side along with a count of how many images were extracted from the document.
\image html FileDiscovery/fd_documents.png
If your results are domains, you'll see information about each domain. If there is an image associated with that domain it will be displayed on the right.
\image html FileDiscovery/fd_domains.png
For image, video, and document searches, when you select a result from the top of the right panel, you'll see the path to the corresponding file(s) in the "Instances" panel below the thumbnails. There may be more than one file instance associated with a result - see the \ref file_disc_dedupe section below. You can right-click on files in the instances panel to use most of options available in the normal \ref result_viewer_page.
\image html FileDiscovery/fd_instanceContext.png
The bottom section of the panel is identical to the standard \ref content_viewer_page and displays data corresponding to the file instance selected in the middle of the panel.
For domain searches, when you select a domain in the top of the right panel you'll see a details area that is a variation on the \ref content_viewer_page. The first tab on details panel displays a simple timeline - selecting a date will show all the results from that date in the center of the panel, with details for the selected result on the right. The other tabs (Web Bookmarks, Web Cookies, etc.) display results of the selected type with a list of results on the left and more details on the right. You can right-click on results to use most of options available in the normal \ref result_viewer_page.
\image html FileDiscovery/fd_domainDetails.png
\subsection file_disc_dedupe De-duplication
This section only applies to image, video and document searches.
Assuming the \ref hash_db_page module has been run, all files in a result group with the same hash will be merged together under a single instance. The file path to one of the instances will be displayed along with a note such as "and 1 more" indicating how many duplicates were found. Selecting the file will display each instance in the middle section of the panel.
\image html FileDiscovery/fd_dupeEx.png
Clicking on a particular instance will load data for that file in the content viewer area at the bottom.
Note that files in different groups will not be merged together or appear under the instances list of each other. For example, if you choose to group by parent folder and have two instances of a file with the same hash but in different folders, each will appear once under its parent folder. Grouping by file size (the default) will always merge every instance of the same file.
\subsection file_disc_icons Status Icons
This section only applies to image, video and document searches.
A number of icons may be displayed in the bottom right of the thumbnails to help point out notable results. Hovering over the icon will display a message explaining why the icon is present. In the image below, the yellow icon is present because the file is associated with an interesting item set.
\image html FileDiscovery/fd_icon.png
Most of the icons match what would be displayed in the "S" column of the normal \ref result_viewer_page.
| Icon | Usage |
|-------|------|
\image html FileDiscovery/yellow-circle-yield.png "" | \ref interesting_files_identifier_page "Interesting file set match" or normal \ref tagging_page "file tag"
\image html FileDiscovery/red-circle-exclamation.png "" | Notable \ref hash_db_page "hash set hit" or notable \ref tagging_page "file tag"
\image html FileDiscovery/file-icon-deleted.png "" | Deleted file (every instance is deleted)
\subsection file_disc_paging Paging
If the group you select has many results, the results will be split up into pages. You can use the left and right arrows to move between pages or type in the page number you wish to go to. You can adjust the number of results per page using the drop down box in the upper right.
\image html FileDiscovery/fd_paging.png
*/

72
docs/doxygen-user_fr/file_export.dox Normal file
View File

@ -0,0 +1,72 @@
/*! \page file_export_page File Export
[TOC]
\section file_export_overview Overview
If enabled, the File Exporter will run after each \ref auto_ingest_page job and export any files from that data source that match the supplied rules. Most users will not need to use this feature - analysts can open the auto ingest cases in an examiner node and look through the data there.
\section file_export_setup Configuration
After enabling the file exporter, the first thing to do is set two output folders. The "Files Folder" is the base directory for all exported files, and the "Reports Folder" is the base directory for reports (lists of every file exported for each data source). If possible, it is best to use UNC paths.
\image html AutoIngest/file_exporter_main.png
Next you'll make rules for the files you want to export. Each rule must have a name and at least one condition set. If more than one condition is set, then all conditions must be true to export the file. When you're done setting up your rule, press the "Save" button to save it. You'll see the new rule in the list on the left side.
All of the saved rules will be run against each data source. There's no way to set a rule as inactive, so if you make a rule and don't want it to run you'll have to use the "Delete Rule" button to remove it.
You'll need to run at the \ref hash_db_page and \ref file_type_identification_page to use the file exporter. You may need to run additional modules based on any attributes in your rules.
\subsection file_exporter_mime MIME Type
The first condition is based on MIME type. To enable it, check the box before "MIME Type", then select a MIME type from the list and choose whether you want to match it or not match it. Multiple MIME types can not be selected at this time. The following shows a rule that will match all PNG images.
\image html AutoIngest/file_export_png.png
\subsection file_exporter_size File Size
The second condition is based on file size. You can choose a file size (using the list on the right to change the units) and then select whether files should be larger, smaller, equal to, or not equal to that size. The following shows a rule that will match plain text files that are over 1kB.
\image html AutoIngest/file_export_size.png
\subsection file_exporter_attributes Attributes
The third condition is based on blackboard artifacts and attributes, which is how Autopsy stores most of its analysis results. A file will be exported if it is linked to a matching attribute. Using this type of condition will require some familiarity with exactly how these attributes are being created and what data we expect to see in them. There's some information to get started in the <a href="http://sleuthkit.org/sleuthkit/docs/jni-docs/4.6.0/mod_bbpage.html">Sleuthkit documentation</a>. You will most likely also have to open an Autopsy database file to verify the exact attribute types being used to hold the data you're interested in.
To make an attribute condition, select the artifact type and then the attribute type that you are interested in. On the next line you can enter a value and set what relation you want the attribute to have to it (equals, not equals, greater/less than). Not all options will make sense with all data types. Then use the "Add Attribute" button to add it to the attribute list. If you make a mistake, use the "Delete Attribute" button to erase it. The following shows a rule that will export any files that had a keyword hit for the word "bomb" in them.
\image html AutoIngest/file_export_keyword.png
It's possible to do more general matching on the artifacts. Suppose you wanted to export all files that the \ref encryption_page flagged as "Encryption Suspected". These files will have a TSK_ENCRYPTION_SUSPECTED artifact with a single "TSK_COMMENT" attribute that contains the entropy calculated for the file. In this case we can use the "not equals" operator on a string that we wouldn't expect to see in the TSK_COMMENT field to effectively change the condition to "has an associated TSK_ENCRYPTION_SUSPECTED artifact."
\image html AutoIngest/file_export_encrypton.png
\section file_export_output Output
The exported files are found under the files folder that was specified in the \ref file_export_setup step and then organized at the top layer by the device ID of the data source.
\image html AutoIngest/file_export_dir_structure.png
Exported files are named with their hash and stored in subfolders based on parts of that hash, to prevent any single folder from becoming very large.
\image html AutoIngest/file_export_file_loc.png
The report files are also found in subfolders under the device ID and then the rule name.
\image html AutoIngest/file_export_json_loc.png
This json file will contain information about the file, and any associated artifact that was part of the rule's conditions.
\verbatim
{"7C89F280C337AB3E997D20527B8EC6F8":{"Filename":"\\\\WIN-4913\\AutopsyData\\FileExportFiles\\37567\\text-plain\\7C\\89\\F2\\80\\7C89F280C337AB3E997D20527B8EC6F8",
"Type":"text/plain","MD5":"7C89F280C337AB3E997D20527B8EC6F8","File data":{"Modified":["0000-00-00 00:00:00"],"Changed":["0000-00-0000:00:00"],
"Accessed":["0000-00-00 00:00:00"],"Created":["0000-00-00 00:00:00"],"Extension":["txt"],"Filename":["File about explosions.txt"],"Size":["54"],
"Source Path":["/kwTest_2019_03_14_12_53_33//File about explosions.txt"],"Flags (Dir)":["Allocated"],"Flags (Meta)":["Allocated"],
"Mode":["r---------"],"User ID":["0"],"Group ID":["0"],"Meta Addr":["0"],"Attr Addr":["1-0"],"Dir Type":["r"],"MetaType":["r"],
"Known":["unknown"]},"TSK_KEYWORD_HIT":{"TSK_KEYWORD":["bomb"]},
"TSK_KEYWORD_HIT":{"TSK_KEYWORD_PREVIEW":["keyword search for the word bomb in this file.\n\n\n------"]},
"TSK_KEYWORD_HIT":{"TSK_SET_NAME":["bomb"]},"TSK_KEYWORD_HIT":{"TSK_KEYWORD_SEARCH_TYPE":["0"]}}}
\endverbatim
*/

44
docs/doxygen-user_fr/file_search.dox Normal file
View File

@ -0,0 +1,44 @@
/*! \page file_search_page File Search
[TOC]
\section about_file_search About File Search
The File Search tool can be accessed either from the Tools menu or by right-clicking on a data source node in the Data Explorer / Directory Tree. By using File Search, you can specify, filter, and show the directories and files that you want to see from the images in the currently opened case. The File Search results will be populated in a brand new Table Result viewer on the right-hand side.
Note: Currently File Search doesn't support regular expressions. The Keyword Search feature of Autopsy does support regular expressions and can be used for to search for files and/or directories by name.
\section how_to_open_file_search How To Open File Search
To open the File Search, you can do one of the following thing:
Right-click a data source and choose "Open File Search by Attributes".
\image html open-file-search-component-1.PNG
or select the "Tools", "File Search by Attributes".
\image html open-file-search-component-2.PNG
\section how_to_use_file_search How To Use File Search
There are several categories that you can use to filter and show the directories and files within the images in the current opened case.
The categories are:
\li Name:
Search for all files and directory whose name contains the pattern given.
Note: it doesn't support regular expression and keyword matching.
\li Size:
Search for all files and directory whose size matches the pattern given. The pattern can be "equal to", "greater than", and "less than". The unit for the size can be "Byte(s)", "KB", "MB", "GB", and "TB".
\li MIME Type:
Search for all files with the selected MIME type. Multiple types can be used by holding SHIFT or CTRL while selecting.
\li MD5:
Search for all files with the given MD5 hash.
\li Date:
Search for all files and directory whose "date property" is within the date range given. The "date properties" are "Modified Date", "Accessed Date", "Changed Date", and "Created Date". You must also specify the timezone for the date given.
\li Known Status:
Search for all files and directory whose known status is recognized as either Unknown, Known, or Known Bad. For more on Known Status, see the \ref hash_db_page.
To use any of these filters, check the box next to the category and click "Search" button to start the search process. The result will show up in the "Result Viewer".
\li Data Source:
Search only within the specified data source instead of the entire case. Note that multiple data sources can be selected by holding SHIFT or CTRL while selecting.
Here's a contrived example where we try to get all the directories and files whose name contains "hello", has a size greater than 1000 Bytes, is in JPEG format, was created between 06/01/2018 and
06/08/2017 (in GMT-5 timezone), is an unknown file, has a hash of 1127F348BD4303A4C3D1D587C807B49F, and appears in data source "image3.vhd":
\image html example-of-file-search.PNG
*/

46
docs/doxygen-user_fr/filetype.dox Normal file
View File

@ -0,0 +1,46 @@
/*! \page file_type_identification_page File Type Identification Module
[TOC]
What Does It Do
========
The File Type ID module identifies files based on their internal signatures and does not rely on file extensions. Autopsy uses the <a href="http://tika.apache.org/">Tika</a> library to do its primary file ID detection and that can be customized with user-defined rules.
You should enable this module because many other modules depend on its results to determine if they should analyze a file. Some examples include:
- \subpage extension_mismatch_detector_page
- \subpage keyword_search_page
Configuration
=======
You do not need to configure anything with this module unless you want to define your own types. To define your own types, go to "Tools", "Options", "File Type Id" panel.
From there, you can define rules based on the offset of the signature and if the signature is a byte sequence of an ASCII string.
\image html filetype.PNG
Using the Module
======
Ingest Settings
------
There are no run-time settings for this module when you run it on
a data source. All user-defined and Tika rules are always applied.
Seeing Results
------
The results can be seen in the views area of the tree, under Views->File Types->By MIME Type.
\image html mime-type-tree.PNG
Note that only user-defined MIME types of the form (media type)/(media subtype) will be displayed in the tree.
To see the file type of an individual file, view the "Results" tab in the lower right when you navigate to the file. You should see a page in there that mentions the file type.
*/

7
docs/doxygen-user_fr/footer.html Normal file
View File

@ -0,0 +1,7 @@
<hr/>
<p><i>Copyright &#169; 2012-2021 Basis Technology. Generated on $date<br/>
This work is licensed under a
<a rel="license" href="http://creativecommons.org/licenses/by-sa/3.0/us/">Creative Commons Attribution-Share Alike 3.0 United States License</a>.
</i></p>
</body>
</html>

152
docs/doxygen-user_fr/geolocation.dox Normal file
View File

@ -0,0 +1,152 @@
/*! \page geolocation_page Geolocation
[TOC]
\section geo_overview Overview
The Geolocation window shows artifacts that have longitude and latitude attributes as waypoints on a map. In the field, when access to online map tile servers may not be available, the Geolocation window provides support for offline map tile data sources.
\image html geo_main.png
\section geo_usage Usage
To open the Geolocation window, click on the "Geolocation" button near the top of the main window, or go to "Tools" and then select "Geolocation".
\subsection geo_navigation General Usage
You can move the map by clicking and dragging, and zoom using either the mouse wheel or the slider in the bottom left of the map. If a map tile is not available, the tile will appear grey but the waypoints will still be displayed. This is more likely to happen when changing the default \ref geo_map_options. Different types of waypoint will be displayed in different colors. You can use the key in the lower left to easily identify the type of each waypoint. Some types will also use different icons on the map. For example, individual track points will be displayed as smaller circles. The entire track will be highlighted when selecting an individual track point.
\image html geo_track_points.png
You can left click on a waypoint to highlight that waypoint and show a details pop-up in the upper right corner of the map. The details pop-up will be updated as you click on different waypoints. The data displayed will vary depending on the type of waypoint. For example, this is a GPS bookmark:
\image html geo_details_bookmark.png
While this is an image with GPS coordinates found by the \ref EXIF_parser_page :
\image html geo_details.png
You can also right click on a waypoint to bring up a similar menu to what you'd see in the \ref result_viewer_page.
\image html geo_context_menu.png
\subsection geo_filter Filtering
The filters are displayed on the left side of the screen. The top filter lets you filter the waypoints based on timestamp. If enabled, you will only see waypoints with a timestamp within N days of the most recent waypoint (not the current date). When using this filter, you can also choose whether you want to see waypoints with no timestamp.
\image html geo_filter_time.png
The second filter allows you to show waypoints only for the selected data sources. Note that only data sources that contain geolocation data are displayed here.
\image html geo_filter_datasource.png
The last filter allows you to only show certain types of waypoints. The number next to the type indicates how many waypoint of that type are in your case.
\image html geo_filter_type.png
Once you are done setting up your filters, click the "Apply" button at the top of the filter panel.
If desired, the filter panel can be hidden by clicking on the vertical "Filters" tab on the top right edge of the filter panel. Clicking on that tab a second time will restore the filters panel.
\subsection geo_report Generating a Report
You can generate a KML report using the "KML Report" button in the bottom right corner of the window. The report will include only the currently visible waypoints and can be found in the "Reports" folder of your case.
\image html geo_report.png
As with other \ref reporting_page "report modules", the generated report will appear under "Reports" in the \ref tree_viewer_page. Note that you can also use the \ref report_kml report module to generate a report containing all geolocation data in the case.
\section geo_map_options Map Tile Options
<p>The Autopsy Geolocation window supports several map tile data source options. The map tile data source can be changed
on the Geolocation panel in the Options dialog. There are four options for geolocation tile data, two of which can be used offline.
<ul>
<li><b>Default online tile server</b>
<ul>
<li>The default Geolocation window tile data source is the Microsoft Virtual Earth server https://www.bing.com/maps.
</ul>
<li><b>OpenStreetMap server</b>
<ul>
<li>You can specify the address of an OSM tile server. A list of online tile servers can be found here: https://wiki.openstreetmap.org/wiki/Tile_servers.
Tile servers may have restrictions on them that prevent Autopsy from accessing their tiles. If the tiles URL is something of the form "http://tiles.example.org/${z}/${x}/${y}.png",
then you'll need to enter "http://tiles.example.org" in the options panel.
\image html geo_openstreetmap.png
</ul>
<li><b>OpenStreetMap zip file</b>
<ul>
<li>Allows offline use of a zip file of OSM tile images
<li>Details on how to generate tile zip files are \ref geo_generate_zip "below".
</ul>
<li><b>MBTiles file</b>
<ul>
<li>Allows offline use of MBTiles file containing raster tiles.
<li>MBTiles raster tiles files can be downloaded from <a href="https://openmaptiles.com/downloads/planet/">OpenMapTiles</a>.
<li>OpenMapTiles provides downloads of MBTile files for areas as large as the whole planet to as small as regions of countries.
<li>For each of these regions there are at least four MBTiles available for download, please be sure to download one of the "Raster Tile" files,
not the "Vector Tiles".
</ul>
</ul>
\subsection geo_generate_zip Using Maperative to Generate Tile Image Zip Files
Maperative is a tool for drawing maps, however it can also be used to create tile images. Maperative downloads and documentations can be found at http://maperitive.net/ .
By default Maperative uses an online tile server to generate the map. For offline use, users can supply an OpenStreetMap raw data extract.
\subsubsection geo_generate_tile_image Generating tile image zip files using any map data source:
<ol>
<li>Download and run Maperative.
<li>Center and zoom in on an area of interest. The larger the area, the more tiles that will be generated. Tiles will be generated for the area visible in the map panel.
<li>Choose whether you want to use the default zoom levels or custom ones. Zoom levels in Mapertive start at 1. As the zoom level increases, so will the quantity of tiles generated as well as the detail of each tile. Generating tiles, especially for heavily populated areas, may take time. Please be patient with either method.
<ul>
<li>To generate tiles using the default zoom levels, select Tools->Generate Tiles
\image html geo_gen_tiles.png
Maperative will generate tiles for zoom levels depending on the area of interest and the zoom level. For example, if you start all the way zoomed out, you will likely see levels 1 through 10 generated. If you start zoomed in, you might see levels 10 through 14.
<li>Maperative provides a command interface which allows you to generate tiles for specific zoom levels. Commands can be run in the Command prompt text field at the bottom of the Maperative window. For a full list of commands see the Maperative documentation or <a href="http://maperitive.net/docs/">http://maperitive.net/docs/</a>. The <tt>generate-tiles</tt> command can be used to generate tiles for the area visible in the map panel area. For full details on <tt>generate-tiles</tt> see the documentation included with Maperative or <a href="http://maperitive.net/docs/Commands/GenerateTiles.html">http://maperitive.net/docs/Commands/GenerateTiles.html</a>. The following is a sample command to generate tiles for zoom levels 2 to 3 into the folder Tiles:
\verbatim generate-tiles minzoom=2 maxzoom=3 tilesdir=C:\Tiles \endverbatim
\image html geo_command_line.png
</ul>
<li>For use in autopsy, the generated tile images need to be in a zip file. To create a zip of tiles for use in Autopsy, zip up all of the folders in the tile file output directory. Do not include the parent directory, just the numbered folders contained within. If you use the menu bar option or did not specify a folder in your command, the generated tiles will be located in &lt;Maperative Install Location&gt;\\Tiles.
\image html geo_tile_folder.png
Be sure to zip only the contents of the folder, not the top level folder.
</ol>
\subsubsection geo_add_ds Adding a data source to Maperative
Maperative can be used to generate tiles using raw data extracts from OpenStreetMaps. Data extracts (*.osm or *.osm.pbf) files can be downloaded from various locations. See https://wiki.openstreetmap.org/wiki/Planet.osm for a list of locations. Geofabrik's free download server has open OpenStreetMap data extracts for many regions. When using OSM raw data extracts in Maperative, the recommendation is to use smaller (.osm) files.
To add a data source to Maperative:
<ol>
<li>Select from the menu bar File->Open Map Source...
\image html geo_add_ds.png
<li>The new data source will appear in the bottom right corner of the window in the "Map Sources" list.
<li>To disable a Map Source, select the Map Source from the list and click the X button.
</ol>
\subsubsection geo_merge_osm Merging OSM raw data extracts
For ease of use, users may want to merge OSM raw data extracts. OSMConvert is a tool that can be used to merge OSM raw data extracts.
To merge two OSM raw data extracts country1.osm.pbf and country2.osm.pbf use the following commands. Note that this assumes that osmcovert and the files are in the same directory; if they are not, be sure to use full paths.
\verbatim
osmconvert country1.osm.pbf -o=country1.o5m
osmconvert country2.osm.pbf -o=country2.o5m
osmconvert country1.o5m country2.o5m -o=together.o5m
osmconvert together.o5m -o=together.osm.pbf
\endverbatim
*/

52
docs/doxygen-user_fr/gpx.dox Normal file
View File

@ -0,0 +1,52 @@
/*! \page gpx_page GPX Analyzer
[TOC]
\section gpx_overview Overview
The GPX Analyzer modules allows you to import GPS data from a GPX file. Information on the GPX format can be found <a href="https://www.topografix.com/gpx.asp">here</a>. The following is a short sample of a GPX file:
\verbatim
<?xml version="1.0" encoding="UTF-8" standalone="no" ?>
<gpx xmlns="http://www.topografix.com/GPX/1/1" xmlns:gpxx="http://www.garmin.com/xmlschemas/GpxExtensions/v3" xmlns:gpxtpx="http://www.garmin.com/xmlschemas/TrackPointExtension/v1" creator="Oregon 400t" version="1.1" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.topografix.com/GPX/1/1 http://www.topografix.com/GPX/1/1/gpx.xsd http://www.garmin.com/xmlschemas/GpxExtensions/v3 http://www.garmin.com/xmlschemas/GpxExtensionsv3.xsd http://www.garmin.com/xmlschemas/TrackPointExtension/v1 http://www.garmin.com/xmlschemas/TrackPointExtensionv1.xsd">
<metadata>
<link href="http://www.garmin.com">
<text>Garmin International</text>
</link>
<time>2009-10-17T22:58:43Z</time>
</metadata>
<trk>
<name>Example GPX Document</name>
<trkseg>
<trkpt lat="47.644548" lon="-122.326897">
<ele>4.46</ele>
<time>2009-10-17T18:37:26Z</time>
</trkpt>
<trkpt lat="47.644548" lon="-122.326897">
<ele>4.94</ele>
<time>2009-10-17T18:37:31Z</time>
</trkpt>
<trkpt lat="47.644548" lon="-122.326897">
<ele>6.87</ele>
<time>2009-10-17T18:37:34Z</time>
</trkpt>
</trkseg>
</trk>
</gpx>
\endverbatim
\section gpx_config Running the Module
To enable the GPX Analyzer ingest module select the checkbox in the \ref ingest_configure "Ingest Modules configuration screen".
\section gpx_results Viewing Results
Results are show in the Results tree under "Extracted Content". The GPX data types "wptType", "rteType", and "trkType" produce results of type GPS Bookmark, GPS Route, and GPS Track, respectively.
\image html gpx_results.png
GPS results can also be seen in the \ref geolocation_page window and the KML Report.
*/

112
docs/doxygen-user_fr/hashdb_lookup.dox Normal file
View File

@ -0,0 +1,112 @@
/*! \page hash_db_page Hash Lookup Module
[TOC]
What Does It Do
========
The Hash Lookup Module calculates MD5 hash values for files and looks up hash values in a database to determine if the file is notable, known (in general), included in a specific set of files, or unknown. SHA-256 hashes are also calculated, though these will not be used in hash set lookups.
Configuration
=======
The Hash Sets tab on the Options panel is where you can set and update your hash set information. Hash sets are used to identify files that are 'known', 'notable', or 'no change'.
\li Known good files are those that can be safely ignored. This set of files frequently includes standard OS and application files. Ignoring such uninteresting-to-the-investigator files, can greatly reduce image analysis time.
\li Notable (or known bad) files are those that should raise awareness. This set will vary depending on the type of investigation, but common examples include contraband images and malware.
\li No change files are files that can reveal information about the system but are not notable. For example, knowning an image contains many files known to be maps of London could be interesting to an investigator, but the maps themselves are not notable.
\section adding_hashsets Importing Hash Sets
To import an existing hash set, use the "Import Database" button on the Hash Sets options panel. This will bring up a dialog to import the file.
\image html hash_import.png
<b>Database Path</b> - The path to the hash set you are importing. Autopsy supports the following formats:
\li Text: One hash starting each line. For example, the output from running the md5, md5sum, or md5deep program on a set of files (*.txt)
\li Index only: Generated by Sleuth Kit/Autopsy. The NSRL is available in this format for use with Autopsy (\ref using_hashsets "see below") (*.idx)
\li Sleuth Kit/Autopsy format database: SQLite hash sets created by Autopsy (*.kdb)
\li EnCase: An EnCase hash set file (*.hash)
\li HashKeeper: Hash set file conforming to the HashKeeper standard (*.hsh)
<b>Destination</b> - The Destination field refers to where the hash set will be stored.
\li Local: The hash set file will be used from original the location on disk
\li Remote: The hash set will be copied into the \ref central_repo_page "central repository". When using a PostgreSQL central repository, this allows multiple users to easily share the same hash sets.
<b>Name</b> - Display name of the hash set. One will be suggested based on the file name, but this can be changed.
<b>Version</b> - The version of the hash set can only be entered when importing the hash set into the central repository. Additionally, no version can be entered if the hash set is not read-only.
<b>Source Organization</b> - The organization can only be entered when importing the hash set into the central repository. See the section on \ref cr_manage_orgs "managing organizations" for more information.
<b>Type of database</b> - All entries in the hash set should either be "known" (can be safely ignored), "notable" (could be indicators of suspicious behavior), or "no change" (known to be a certain type of file).
<b>Make database read-only</b> - The read-only setting is only active when importing the hash set into the central repository. A read-only database can not have new hashes added to it through either the Hash Sets options panel or the context menu. For locally imported hash sets, whether they can be written to is dependent on the type of hash set. Autopsy format databases (*.kdb) can be edited, but all other types will be read-only.
<b>Send ingest inbox message for each hit</b> - Determines whether a message is sent for each matching file. This can not be enabled for a "known" hash set.
<b>Copy hash set into user configuration folder</b> - Makes a copy of the hash set instead of using the existing one. This is intended to be used with a \ref live_triage_page drive.
\subsection hashset_indexing Indexing
After importing the hash set, you may have to index it before it can be used. For most hash set types, Autopsy needs an index of the hash set to actually use a hash set. It can create the index if you import only the hash set. Any hash sets that require an index will be displayed in red, and their "Index Status" will indicate that an index needs to be created. This is done simply by using the Index button.
\image html hash_indexing.png
Autopsy uses the hash set management system from The Sleuth Kit. You can manually create an index using the 'hfind' command line tool or you can use Autopsy. If you attempt proceed without indexing a hash set, Autopsy will offer to automatically produce an index for you.
You can also specify only the index file and not use the full hash set - the index file is sufficient to identify known files. This can save space. To do this, specify the .idx file from the Hash Sets option panel.
\section creating_hashsets Creating Hash Sets
New hash sets can be created using the "New Hash Set" button. The fields are mostly the same as the \ref adding_hashsets "import dialog" described above.
\image html hash_new_db.png
In this case, the Database Path is where the new database will be stored. If the central repository is being used then this field is not needed.
\section hash_adding_hashes Adding Hashes to a Hash Set
Once you've created a hash set you'll need to add hashes two it. The first way to do this is using the "Add Hashes to Hash Set" button on the options panel. Each hash should be on its own line, and can optionally be followed by a comma and then a comment about the file that hash corresponds to. Here we are creating a "no change" hash set corresponding to cat images:
\image html hash_add.png
The other way to add an entry to a hash set is through the context menu. Highlight the file you want to add to a hash set in the result viewer and right-click, then select "Add file to hash set" and finally the set you want to add it to. Note that this does not automatically add the file to the list of hash set hits for the current case - you will have to re-run the Hash Lookup ingest module to see it appear there.
\image html hash_add_context.png
\section using_hashsets Using Hash Sets
There is an \ref ingest_page "ingest module" that will hash the files and look them up in the hash sets. It will flag files that were in the notable hash set and those results will be shown in the Results tree of the \ref tree_viewer_page.
Other ingest modules are able to use the known status of a file to decide if they should ignore the file or process it.
You can also see the results in the \ref how_to_open_file_search "File Search" window. There is an option to choose the 'known status'. From here, you can do a search to see all 'notable' files. From here, you can also choose to ignore all 'known' files that were found in the NSRL. You can also see the status of the file in a column when the file is listed.
<br>
NIST NSRL
------
Autopsy can use the <A HREF="http://www.nsrl.nist.gov">NIST NSRL</A> to detect 'known files'. The NSRL contains hashes of 'known files' that may be good or bad depending on your perspective and investigation type. For example, the existence of a piece of financial software may be interesting to your investigation and that software could be in the NSRL. Therefore, Autopsy treats files that are found in the NSRL as simply 'known' and does not specify good or bad. Ingest modules have the option of ignoring files that were found in the NSRL.
To use the NSRL, you may download a pre-made index from <A HREF="http://sourceforge.net/projects/autopsy/files/NSRL/">http://sourceforge.net/projects/autopsy/files/NSRL</A>. Download the <b>NSRL-XYZm-autopsy.zip </b> (where 'XYZ' is the version number. As of this writing, it is 247) and unzip the file. Use the "Tools", "Options" menu and select the "Hash Sets" tab. Click "Import Database" and browse to the location of the unzipped NSRL file. You can change the Hash Set Name if desired. Select the type of database desired, choosing "Send ingest inbox message for each hit" if desired, and then click "OK".
<br>
\image html nsrl_import_process.PNG
<br>
Using the Module
======
Ingest Settings
------
When hash sets are configured, the user can select the hash sets to use during the ingest process.
\image html hash-lookup.PNG
Seeing Results
------
Results show up in the tree as "Hashset Hits", grouped by the name of the hash set. If the hash set hits had associated comments, you will see them in the "Comment" column in the result viewer along with the file hash.
\image html hashset-hits.PNG
You can also view the comments on the "Annotation" tab of the content viewer.
*/

50
docs/doxygen-user_fr/hosts.dox Normal file
View File

@ -0,0 +1,50 @@
/*! \page host_page Hosts
[TOC]
\section host_use Using Hosts
\subsection host_wizard Associating a Data Source With a Host
Every data source must be associated with a host. The first step in the \ref ds_add "add data source process" is to select a host for the data source you are about to add to the case. This host can be auto-generated, entered by the user, or selected from the list of hosts already present in the case.
\image html data_source_host_select.png
\subsection host_view Viewing Hosts
Hosts are displayed in the \ref tree_viewer_page. Depending on the \ref view_options_page selected, hosts may be grouped together under persons.
\image html ui_tree_top_ds.png
\subsection host_os_accounts OS Accounts
OS accounts can be viewed in the OS Accounts node under Results. Each OS account is associated with a host, and the host information is displayed in the OS Account tab of the content viewer.
\image html host_os_accounts.png
\section host_management Managing Hosts
\subsection host_menu Manage Hosts Menu
Go to Case->Manage Hosts to open the host management panel.
\image html manage_hosts.png
Here you can see all hosts in the case, add new hosts, change the name of an existing host, and delete hosts that are not in use.
\subsection host_merge Merging Hosts
Over the course of processing a case, it may become clear that two (or more) hosts should be combined. Merging one host into another will move all data sources from the source host into the destination host and move or combine any OS accounts found.
To merge hosts, right-click on the host you want to merge into another host.
\image html host_merge.png
A confirmation dialog will display stating that this can not be undone. After proceeding, the hosts will be merged together and the tree viewer node will update showing the combined data.
\image html host_merge_result.png
*/

20
docs/doxygen-user_fr/ileapp.dox Normal file
View File

@ -0,0 +1,20 @@
/*! \page ileapp_page iOS Analyzer (iLEAPP)
[TOC]
\section ileapp_overview Overview
The iOS Analyzer ingest module runs iLEAPP (https://github.com/abrignoni/iLEAPP) and converts the results into results that can be viewed in Autopsy.
\section ileapp_config Using the Module
Select the checkbox in the Ingest Modules settings screen to enable the IOS Analzyer (iLEAPP) module. The module will run on .tar/.zip files found in a \ref ds_log "logical files data source" or a \ref ds_img "disk image".
\section ileapp_results Seeing Results
Results from the iOS Analyzer module will appear in the \ref tree_viewer_page under Results->Extracted Content.
\image html ileapp_main.jpg
*/

125
docs/doxygen-user_fr/image_gallery.dox Normal file
View File

@ -0,0 +1,125 @@
/*! \page image_gallery_page Image Gallery Module
[TOC]
Overview
========
This document outlines the use of the Image Gallery feature of Autopsy. This feature was funded by DHS S&T to help provide free and open source digital forensics tools to law enforcement.
The Image Gallery feature has been designed specifically with child-exploitation cases in mind, but can be used for a variety of other investigation types that involve images and videos. It offers the following features beyond the traditional long list of thumbnails that Autopsy and other tools currently provide.
- Groups images by folder (and other attributes) to help examiner break the large set of images into smaller groups and to help focus on areas with images of interest.
- Allows examiner to start viewing images immediately upon adding them to the case. As images are hashed, they are updated in the interface. You do not need to wait until the entire image is ingested.
This document assumes basic familiarity with Autopsy.
Quick Start
===========
1. The Image Gallery tool can be configured to collect data about images/videos as ingest runs or all at once after ingest. To change this setting go to "Tools", "Options", "Image /Video Gallery". This setting is saved per case, but cannot be changed during ingest. See the Options window for more details
2. Create a case as normal and add a disk image (or folder of files) as a data source. Ensure that you have the hash lookup module enabled with NSRL and known bad hashsets, the Picture Analyzer module enabled, and the File Type module enabled.
3. Click the "View Images/Videos" button or select "View Images/Videos" in the "Tools" menu. This will open the Autopsy Image/Video Analysis tool in a new window.
4. Groups of images will be presented as they are analyzed by the background ingest modules. You can later resort and regroup, but it is required to keep it grouped by folder while ingest is still ongoing.
5. As each group is reviewed, the next highest priority group is presented, according to a sorting criteria (the default is the density of hash set hits).
6. Images that were hits from hashsets, will have a dashed border around them.
7. You can use the menu bar on the top of the group to categorize the entire group.
8. You can right click on an image to categorize or tag the individual image.
9. Tag files with customizable tags. A ‘Follow Up’ tag is already built into the tool and integrated into the filter options. Tags can be applied in addition to categorization. An image can only have one categorization, but can have many tags to support your work-flow.
10. Create a report containing the details of every tagged and/or categorized file, via the standard Autopsy report generation feature.
Use Case Details
===============
In addition to the basic ideas presented in the previous section, here are some hints on use cases that were designed into the tool.
- When you are viewing the groups, they are presented in an order based on density of hash hits(by default). If you find a group that has lots of interesting files and you want to see what is in the parent folder or nearby folders, use the navigation tree on the left.
- At any time, you can use the list on the left-hand side to see the groups with the largest hashset hits.
- To see which folders have the most images in them, sort the groups by group size (descending).
- Files that have hashset hits are not automatically tagged or categorized. You need to do that after reviewing them. The easiest way to do that is to wait until ingest is over and then group by hashsets. You can then review each group and categorize the entire group at a time using the group header.
Categories
==========
The tool has been designed specifically with child-exploitation cases in mind and has a notion of categorizes. We will be changing this in the future to be more flexible with custom category names, but currently it is hard coded to use the names that Project Vic (and other international groups) use. We have assigned colors to each category to highlight each image.
Name|Description|Color
----|-----------------|------
CAT-0|Uncategorized|![gray](ImageGallery/gray.PNG)
CAT-1|Child Abuse Material |![red](ImageGallery/red.PNG)
CAT-2|Child Exploitative / Age Difficult|![orange](ImageGallery/orange.PNG)
CAT-3|CGI / Animation|![yellow](ImageGallery/yellow.PNG)
CAT-4|Comparison Images |![bisque](ImageGallery/bisque.PNG)
CAT-5|Non-pertinent|![green](ImageGallery/green.PNG)
GUI controls
=================
You can do your entire investigation using the mouse, but many examiners like to use keyboard shortcuts to quickly process large amounts of images.
Keyboard Shortcuts
-----------------
shortcut | action
-----------|------
digits 0-5 | assign the correspondingly numbered category to the selected file(s)
alt + 0-5 | assign the correspondingly numbered category to all files in the focused group
arrows | select the next file in the direction pressed
page up/down | scroll the list of files
Additional Mouse Controls
-------------------------
mouse gesture| action
----------|----------
ctrl + left click|toggle selection of clicked file, select multiple files
right click on file|bring up context menu allowing per file actions (tag, categorize, extract to local file, view in external viewer, view in Autopsy content viewer, add file to HashDB)
right click empty space of group|bring up context menu allowing per group actions (tag, categorize, extract to local file(s), add file(s) to HashDB)
double click on file|open selected file in slide show mode
UI Details
==========
Group Display Area
-------------------
The central display area contains the list of files in the current group. Images in the group can be displayed in either thumbnail mode or slide show mode. Slide show mode provides larger images and playback of video files. At the right of the group header is a toggle for changing the viewing mode of the group (tiles vs slide-show ).
Image/Video Tiles
-----------------
Each file is represented in the main display area via a small tile. The tile shows:
- Thumbnail of the image/video
- Name of the file
- Indicators of other important details:
| image | description | meaning|
|----|----|-----|
| | solid colored border | file’s assigned category.|
| ![](ImageGallery/purpledash.PNG) "" | purple dashed border | file has a known bad hashset hit, but has not yet been categorized. |
| ![](ImageGallery/hashset_hits.PNG) ""|pushpin | file has a known bad hashset hit|
| ![](ImageGallery/video-file.PNG) ""| clapboard on document | video file|
| ![](ImageGallery/flag_red.PNG) ""| a red flag | file has been 'flagged' as with the follow up tag|
Slide Show Mode
---------------
In slide show mode a group shows only one file at a time at an increased size. Per file tag/category controls above the top right corner of the image, and large left and right buttons allow cycling through the files in the group. If the active file is an Autopsy supported video format, video playback controls appear below the video.
Table/Tree of contents
----------------------
The section in the top left with tabs labelled “Contents” and “Hash Hits” provides an overview of the groups of files in the case. It changes to reflect the current Group By setting: for hierarchical groupings (path) it shows a tree of folders (folders containing images/videos (groups) are marked with a distinctive icon ), and for other groupings it shows only a flat list.
Each group shows the number of files that hit against configured Hash DBs during ingest (hash hits) and the total number of image/video files as a ratio (hash hits / total) after its name. By selecting groups in the tree/list you can navigate directly to them in the main display area. If the Hash Hits tab is selected only groups containing files that have hash hits are shown.
Listening for Changes
======================
The Image Gallery maintains its own database, which needs to be updated as files are analyzed by Autopsy. For example, it needs to know when a file has been hashed or had EXIF data extracted. By default, the Image Gallery is always listening in single-user cases for these changes and keeps its database up to date. If this is causing a performance impact, you can disable this feature in the Options panel.
You can turn the listening off for the current case and you can change the default behavior for future cases.
Multi-User Cases
=================
If a case was created in a multi-user environment, then it becomes much harder to keep the Image Gallery database in sync because many other examiners could be analyzing data from that case. Therefore, Image Gallery has different update behaviors in a multi-user case than it does for a single-user case. Notably:
- If your system is running ingest on the data source, then you will continue to get real-time updates just like in a single-user case. So, as soon as a folder of files has been hashed and had EXIF data extracted, it will be possible for you to view it.
- If another system in the cluster is running ingest on a data source, you may not see its results until the ingest has completed. You will not get real-time updates and instead you will get updates only after you have closed Image Gallery and opened it again.
- Each time you open Image Gallery, it will check the local database to see if it is in sync with the case database. If it is not, it will ask you to rebuild it. This is because additional data may have been added to the case database by another system and your Image Gallery database is no longer accurate.
You also have the option to see groups (or folders) that are new to you or new to everyone. When you press “Show Next Unseen Group”, the default behavior is to show you the highest priority group that you have not seen yet. But, you can also choose to see groups that no one else has seen. This choice can be made using the check box next to the “Show Next Unseen Group” button.
*/

BIN
docs/doxygen-user_fr/images/AutoIngest/admin_file.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 31 KiB

BIN
docs/doxygen-user_fr/images/AutoIngest/admin_jobs_cancel.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 8.1 KiB

BIN
docs/doxygen-user_fr/images/AutoIngest/admin_jobs_completed.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 10 KiB

BIN
docs/doxygen-user_fr/images/AutoIngest/admin_jobs_panel.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 13 KiB

BIN
docs/doxygen-user_fr/images/AutoIngest/admin_nodes_panel.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 12 KiB

BIN
docs/doxygen-user_fr/images/AutoIngest/advanced_settings.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 28 KiB

BIN
docs/doxygen-user_fr/images/AutoIngest/auto_ingest_in_progress.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 51 KiB

BIN
docs/doxygen-user_fr/images/AutoIngest/auto_ingest_mode_setup.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 45 KiB

BIN
docs/doxygen-user_fr/images/AutoIngest/case_delete_confirm.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 12 KiB

BIN
docs/doxygen-user_fr/images/AutoIngest/cases_context_menu.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 12 KiB

BIN
docs/doxygen-user_fr/images/AutoIngest/cases_panel.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 54 KiB

BIN
docs/doxygen-user_fr/images/AutoIngest/error_suppression.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 77 KiB

BIN
docs/doxygen-user_fr/images/AutoIngest/examiner_dashboard.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 66 KiB

BIN
docs/doxygen-user_fr/images/AutoIngest/file_export_dir_structure.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 16 KiB

BIN
docs/doxygen-user_fr/images/AutoIngest/file_export_encrypton.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 18 KiB

BIN
docs/doxygen-user_fr/images/AutoIngest/file_export_file_loc.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 8.5 KiB

BIN
docs/doxygen-user_fr/images/AutoIngest/file_export_json_loc.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 9.1 KiB

BIN
docs/doxygen-user_fr/images/AutoIngest/file_export_keyword.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 16 KiB

BIN
docs/doxygen-user_fr/images/AutoIngest/file_export_png.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 16 KiB

BIN
docs/doxygen-user_fr/images/AutoIngest/file_export_size.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 16 KiB

BIN
docs/doxygen-user_fr/images/AutoIngest/file_exporter_main.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 41 KiB

BIN
docs/doxygen-user_fr/images/AutoIngest/health_monitor.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 159 KiB

BIN
docs/doxygen-user_fr/images/AutoIngest/health_monitor_disabled.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 7.4 KiB

BIN
docs/doxygen-user_fr/images/AutoIngest/manifest_file_in_file_explorer.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 8.2 KiB

BIN
docs/doxygen-user_fr/images/AutoIngest/manifest_tool_root_folder.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 20 KiB

BIN
docs/doxygen-user_fr/images/AutoIngest/manifest_tool_ui.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 18 KiB

BIN
docs/doxygen-user_fr/images/AutoIngest/master_node.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 16 KiB

BIN
docs/doxygen-user_fr/images/AutoIngest/metrics.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 11 KiB

BIN
docs/doxygen-user_fr/images/AutoIngest/no_periodic_searches.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 46 KiB

BIN
docs/doxygen-user_fr/images/AutoIngest/overview_pic1.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 80 KiB

BIN
docs/doxygen-user_fr/images/AutoIngest/overview_pic2.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 169 KiB

BIN
docs/doxygen-user_fr/images/AutoIngest/test_button_failure.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 4.5 KiB

BIN
docs/doxygen-user_fr/images/DataSourceSummary/ds_summary_analysis.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 16 KiB

BIN
docs/doxygen-user_fr/images/DataSourceSummary/ds_summary_container.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 24 KiB

BIN
docs/doxygen-user_fr/images/DataSourceSummary/ds_summary_export.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 6.6 KiB

BIN
docs/doxygen-user_fr/images/DataSourceSummary/ds_summary_geo.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 29 KiB

BIN
docs/doxygen-user_fr/images/DataSourceSummary/ds_summary_ingest.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 32 KiB

BIN
docs/doxygen-user_fr/images/DataSourceSummary/ds_summary_noRA.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 4.8 KiB

BIN
docs/doxygen-user_fr/images/DataSourceSummary/ds_summary_past_cases.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 17 KiB

BIN
docs/doxygen-user_fr/images/DataSourceSummary/ds_summary_recent_files.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 32 KiB

BIN
docs/doxygen-user_fr/images/DataSourceSummary/ds_summary_result_viewer.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 75 KiB

BIN
docs/doxygen-user_fr/images/DataSourceSummary/ds_summary_timeline.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 18 KiB

BIN
docs/doxygen-user_fr/images/DataSourceSummary/ds_summary_types.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 48 KiB

BIN
docs/doxygen-user_fr/images/DataSourceSummary/ds_summary_user_activity.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 28 KiB

BIN
docs/doxygen-user_fr/images/DataSourceSummary/ds_summary_window.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 56 KiB

BIN
docs/doxygen-user_fr/images/EXIF-heic.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 213 KiB

BIN
docs/doxygen-user_fr/images/EXIF-tree.PNG Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 48 KiB

BIN
docs/doxygen-user_fr/images/FileDiscovery/fd_dataSourceFilter.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 4.8 KiB

BIN
docs/doxygen-user_fr/images/FileDiscovery/fd_dateFilter.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 7.4 KiB

BIN
docs/doxygen-user_fr/images/FileDiscovery/fd_documents.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 93 KiB

BIN
docs/doxygen-user_fr/images/FileDiscovery/fd_domainDetails.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 50 KiB

BIN
docs/doxygen-user_fr/images/FileDiscovery/fd_domainResultFilter.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 7.3 KiB

BIN
docs/doxygen-user_fr/images/FileDiscovery/fd_domains.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 78 KiB

BIN
docs/doxygen-user_fr/images/FileDiscovery/fd_dupeEx.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 194 KiB

BIN
docs/doxygen-user_fr/images/FileDiscovery/fd_fileSizeFilter.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 6.3 KiB

BIN
docs/doxygen-user_fr/images/FileDiscovery/fd_fileType.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 9.5 KiB

BIN
docs/doxygen-user_fr/images/FileDiscovery/fd_grouping.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 11 KiB

BIN
docs/doxygen-user_fr/images/FileDiscovery/fd_groupingInt.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 2.1 KiB

BIN
docs/doxygen-user_fr/images/FileDiscovery/fd_groupingSize.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 3.0 KiB

BIN
docs/doxygen-user_fr/images/FileDiscovery/fd_hashSetFilter.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 2.9 KiB

BIN
docs/doxygen-user_fr/images/FileDiscovery/fd_icon.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 158 KiB

BIN
docs/doxygen-user_fr/images/FileDiscovery/fd_instanceContext.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 78 KiB

BIN
docs/doxygen-user_fr/images/FileDiscovery/fd_interestingItemsFilter.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 3.4 KiB

BIN
docs/doxygen-user_fr/images/FileDiscovery/fd_knownAccountFilter.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 2.0 KiB

Some files were not shown because too many files have changed in this diff Show More