RFC: Exploit Artifact Storage

[terrorbyte]

Problem

Currently there's no formalized way to store exploit artifacts in a consistent way, and has been handled by either just printing extracted data into Success log level or by manually writing a temporary file based on the output. This has worked fine until we have needed a storage mechanism that is a bit more consistent.

Solutions

• Use the db - Now that #156 Initial implementation of sqlite3 integration #177 is merged and we have a proper DB wrapper we could use what we've got and store artifacts in the database. This will require another table and a bit of schema stitching, which shouldn't be a problem. There's also other potentially useful things with this as the primary preferred way, such as keeping time based snapshots of the artifacts (ie logs captured over time from a target). One thing to keep in mind would be that sometimes accessing sqlite artifacts might not be the most ergonomic so maybe we could write some basic tooling around extracting the files based on exploit runs.
• Add a basic handler for file writes to go-exploit - Currently we have been using a very simple write to temp file based on context, we could just easily port this to go-exploit and make it a public function for writing the files.
• Both! - It could be possible to just have the artifact store function handle both cases and have a setting to toggle based on if db is enabled or not.

Other notes

Naming is always hard. loot isn't really very explicit but also pirates are neat. I am using artifacts in this based on prior verbiage, but could easily be switched up

[wvu]

loots

[terrorbyte]

Artifact is the right term imo based on NIST Glossary but I know was contentious, maybe "evidence"?