Windows: Add --base to modscan and modules

[brandon-barnacle]

In volatility2, the windows.moddump plugin allows you to extract a single module using a base address.
This PR adds the same functionality to volatility3 in the windows.modscan and windows.modules plugins.

The base address is passed in using --base=BASE where the module with base address BASE will be extracted.
The matching volatility2 functionality can be found here:
https://github.com/volatilityfoundation/volatility/blob/2.6.1/volatility/plugins/moddump.py#L71

Manual testing was performed on windows memory images across different windows versions to verify the expected output.

[eve-mem]

Hey @brandon-barnacle - nice to see another PR from you - I had a question about the description for --base.

It says Extract a single module with BASE address(hex) - does that mean the value provided by the user needs to be in hex? I had thought that the int requirement forces the values to be actual base 10 integers. Turns out that you can use hex for int requirements which is really nice and I didn't know that!

I'm still thinking that the description can probably just be Extract a single module with BASE address. As it doesn't need to be hex? What do you think?

🦊 Just a random internet vol user

[brandon-barnacle]

Hi @eve-mem - I think you are totally right here, so I'm gonna push a small change where i take out the "(hex)" from the description.

[ikelos]

For some reason I thought I'd commented on this already, but now I can't find it? I'd expect the --base flag to reduce the results to a single line, and then for --dump to dump it if needed? Instead, base always dumps, and disables the --dump flag? It seems odd to me that we'd introduce a second flag that partially shares functionality, almost fights over it, in the plugin, rather than letting the dedicated flag act as it's supposed to (choosing between dumping and not) and letting the first flag do the filtering. This method of filtering doesn't really make a great deal of sense, because it happens after the generation of all the possible modules, so it won't save any time, it literally just avoids dumping multiple files.

If a specific base has been provided, can I suggest attempting to instantiate a module at the address, checking it passes that tests that modules need to pass for the modscan to succeed, and then outputs that rather than running through the generated list, at the very least for the modscan plugin? That would provide a speed boost, and valuable functionality, and the --dump flag could still be used to actually get the file out at the end?

I'm not out to produce exactly the same output in the same way as volatility 2, just to provide the same functionality so that people don't turn to volatility 2 because they can't do something in volatility 3. As such, we don't have to duplicate the flags, and we should ensure that our flags make sense and are as simple and straightforward to understand as they can be, volatility 2 aside.

[brandon-barnacle]

Hi @ikelos, I think what you said here makes a lot of sense and was something that I thought about after I made the PR, so I think it is a good thing that you brought it up. I am going to work on making this change and see how it performs.