Loading Strategies

The way you load data into Truxton mostly depends on the amount of data you have to load. If you're one of those kinds of people that likes to type, you can use the command line. From Windows File Explorer, you can right button on a file or folder and load it into Truxton. You can even script the load.

Single Media

When you have just a few pieces of media to load, you can use the Desktop Gui or Windows Explorer (right-button Load...). Manually starting a load is for single-user environments where everything is on a single machine. The amount of data is a couple of hard drives, half a dozen phones, etc.

You can also load from the command line.

"C:\Program Files\Truxton\Loader\Load.exe" WinXP.E01

A Walk Through

1. You seize a device
2. You make an image of it
3. You load that disk image into Truxton
4. You examine the Truxton output using the Analyst Desktop
5. Once Truxton's exploitation is finished, read the generated reports
6. Arrest scumbag

Several Media

When you get to the point where you have more than several hard drives to process at a time, a dedicated loader machine is used. At this level, overloading the machine becomes a problem. There's too much data to load and not enough time to sit and watch the loaders. Using a Load List will allow you to specify the media to load and how many simultaneous load processes to use. This allows you to balance the resources of your machine with the amount of data to load.

A Walk Through

1. You seize several devices
2. You make an images of all of them
3. You create a load list
4. You load the list file just like any other file into Truxton
5. You examine the Truxton output using the Analyst Desktop
6. Once Truxton's exploitation is finished, read the generated reports
7. Arrest scumbags

Hundreds of Media

When you have a never ending stream of incoming media, you need something even more automatic than load lists. Multiple machines dedicated to loading are pressed into service. Like other ETL processes, the loader has its own message queue that loading tasks can be sent to. When a load process on one of those machines finishes, it will grab another load task from the message queue. One way of dealing with the volume is to use a tool for automating workflows such as NiFi. If you have a no-human-in-the-loop architecture, you can automate the publishing of freshly loaded media.

Quality Controlled

In this strategy, you have broken the exploitation process into separate loading and publishing phases. Data is loaded into a separate system, checked by a human for any errors or misconfiguration. There is a separate server that the investigators use to analyze the Truxton output. If the freshly loaded data looks good, the human will publish the freshly loaded media from the loader machine to the investigation server. Often times, the loader machine is reset to an initial state before loading the next media. When using this strategy, depot storage is concern. You don't want to move the depots if you don't have to. A shared storage solution is usually best where the loader machines and analysis server have the same view of storage. The analysis Truxton has no knowledge of the depot files from the loader machines until the media has been published to the analysis server. This allows the quality control technicians to freely delete depot files from bad loads without interfering with analysts.

Field Exploitation

Sometimes you may have a one-person office far away from a server room. In this case, data is loaded in the field. The user will export the media without the depots and send the archive file (tmpf) to a central office. This file is tiny compared to the size of the exploited media. Analysts at the central office import the data into a Truxton database instance of theirs and review the data. They will not have any file contents but they will be able to see everything else (artifacts, tags, file meta data, etc). The fielded system can be configured to automatically generate this archive.

This strategy is useful when you have limited bandwidth between offices or sites. Sometimes it is better to push exploitation to the edge and send back the results rather than raw data. The raw data and depots can be forwarded later (via FedEx or when you get to a broadband connection).