fox-it
Add a path remapping option to LogLoader
This PR is a band-aid to address the issues discussed in https://github.com/fox-it/dissect.target/pull/399. When I have forensic artifacts without a target (e.g, when doing a ctf, or processing outputs from other tooling) I'd like to be able to invoke a plugin to parse it. While I agree with the discussion in #399 that it would be better to have a uniform API where every plugin specifies what paths they need to work (and then having an option to provide / extend these paths on the fly), it might take a while to implement that.
The change in this PR allows the user to 'remap' a given file / directory to a specific location in the virtual filesystem, so that plugins that do little more than parsing a (set of) file(s) will work. For example, a wtmp file could be parsed like this:
target-query "log://wtmp?path=/var/log/wtmp" -f wtmp
Or apache access logs like this:
target-query "log://apache_dir?path=/var/log/apache" -f apache.access
Of course, for a lot of plugins, this still won't be enough to make it work. For example, the commandhistory plugin requires the target to have users. Windows plugins doing anything with the registry are also not addressed by this (as also mentioned in https://github.com/fox-it/dissect.target/issues/411). Lastly, it still requires the user to know where a given forensic artifact is expected to be located to map it accordingly.
If you have something better in mind, feel free to just close this PR and implement that instead. Perhaps it's better to just extend the LOGS_DIRS dict, but that seemed to me like further hardcoding away the underlying problem.
Thanks for creating this pr! We are planning to enhance our plugin functionality so you can query plugins with just target-query. That is still some time away tho, so I think this is a nice temporary solution. This does mean that the logloader will be removed in the future.
We will look at it later, and could you maybe create an issue and attach it to this pr? That way we keep better track of whats going on
Hi, good to hear this was already on your radar! I made an issue (#789) and tried to describe the issue as a whole. Though if you've been planning something already you might have different views on it, feel free to change the issue.
Do note that given that the corresponding issue has been phrased more generally, merging this PR would not resolve said issue in its entirety ;)
Since the log loader will be deprecated soon and the long term plan is to separate the parser from the plugin (GitHub issue number still pending it seems), I'm closing this. If you need this functionality in the meantime, feel free to make a new PR based around the DirectLoader instead!
