Why build a framework? The question could be, why develop a script at all? Frequently, we perform the same series of steps for a given piece of evidence. For example, we commonly prepare reports for LNK, prefetch, and jumplist files, examine registry keys, and establish external device and network activity to answer forensic questions. As we've seen, we can develop a script to parse these artifacts for us and display the data in a format that's conducive for rapid analysis. Why not write a series of scripts, each responsible for one artifact, and then control them with a singular script, to execute all at once and hence further automate our analysis?
A framework can be developed to run a series of scripts and parse multiple artifacts at once. The output of such a framework could be a series of analysis-ready spreadsheets. This allows the examiner to skip the same tedious series of steps and start answering meaningful questions about the evidence.
Frameworks typically have three main components:
- A main controller
- Plugins
- Writers
The main controller isn't very different from our main() functions and essentially calls a series of plugins on some input, which parse specific artifacts, store the returned results, and then send the results to a writer for output. Our plugins are scripts that perform a specific task, for example, a script that parses UserAssist artifacts. Writers, similar to our csv_writer() functions, take the output from our plugins and write it out to disk. While this seems like a fairly straightforward process, developing frameworks is more complex than developing a single script. This is because we have to worry about building a simple yet efficient structure and keeping data standardized between plugins.