Save config and plugin parameters

[gcmoreira]

I noticed that the plugin parameters are also saved when used --save-config. Is it a bug or a feature? What's the use case for saving them?

While improving the test case execution, I realized we could leverage the saved config for a given memory dump to speed up subsequent runs by avoiding redundant searches for DTB, KASLR shifts, etc. To optimize the first "save config" execution, we could also, for example, run pslist --pid 1 to quickly complete and save the configuration. However, since the plugin parameters are also saved, subsequent testcase runs for plugins which also accept the --pid will inherit the --pid 1 parameter, causing failures in the remaining testcase assertions.

The saved plugin parameters might support different types when saved compared to when the configuration is reused by the next plugin. For example, the plugin that saves the config could accept a PID list, but the plugin that reuses this configuration might only accept a single PID (int), potentially leading to unexpected behavior or crashes due to type mismatches.

Could we remove this if it's not serving a specific use case? I find it error-prone, as users could easily fall into this trap, which would be difficult to troubleshoot, especially for those with less experience.

[atcuno]

There is another ticket about --config here:

#1294

The issue is that --save-config was never meant to be used for speeding things up (as ikelos explains in the other ticket), but it was also never documented so we (me, MHL, Dave) thought it was a replacement for the performance options from Vol2. Obviously we need some mechanism to re-use the stuff we scan for as plugins are horribly slow otherwise, but by default you have to be careful with --config. You can just run windows.info or windows.pslist without --pid and then you get a config that works with everything but mftscan and yarascan. That is what I have been using for mass testing.

[ikelos]

Yeah, it's basically the means for the UI to talk to the plugin. The plugin says what it needs, and the UI populates it. It's then used by automagic to ensure that the plugin has all the things it needs (from address layers to symbol tables). The config should only ever be able to contain simple types (which are all therefore JSON serializable). It just so happened that we can speed things up because when the automagic creates everything it populates all the requirements within the tree, but those requirements can be optional (such as pid, etc). Hoepefully that explains the design. The uses we've put it to are because it tends to work for the purposes we need, without them specifically being the reason it was designed that way. It's entirely about comms between the plugin and the UI.

              |---<<<--- Requirements ---<<<---|
(asks user)   |                                |
    UI        |--->>>---    Config    --->>>---| Plugin
              |                                | (runs)
              |---<<<---   TreeGrid   ---<<<---|
(displays )   |                                |