volatilityfoundation
Adding --output-filename command line option like in Vol2.
With this option, Vol3 can produce by itself an output file. It can be useful in some cases, especially when Vol3 is launched by other tools which don't support output redirection operator ">". Usable with --output=<json|csv|text> to set the output format.
Hello @nathan-out - thank you for spending time on this and raising a PR!
I was going to suggest just using the --log option that already exists but it only includes log messages and not the text output - so that's a no go.
One thing that might be useful to consider is checks around being able to write to the file given on the command line, at the moment it'll crash vol. Have a look at how the --save-config option is doing that here: https://github.com/volatilityfoundation/volatility3/blob/8f0d1b37cc2f88646b5858509e1bc0d5bf4941e0/volatility3/cli/init.py#L442-L455
A very minor point is the (like in Volatility2). part of the help feels a bit ugly to me. I'd probably just leave it at ``Write output in this file. Default is stdout.`. That's maybe just personal preference.
Thanks again, keep them coming!
🦊 Just a random internet vol user
Hello @eve-mem thanks for your feedback ! I just improved the help : Write output in this file. Default is stdout. and add a check on the output file, like you described.
Do you know if volatility integrates pull requests into its core branch? It's my very first PR so I don't know how it works.
Yup, once a core dev takes a look and thinks the way it's done etc is good. I'd imagine it'll be @ikelos to look over this one.
Assuming it's all approved it'll be merged into the develop branch, and then a few times a year develop is merged into main. Although frankly i always just use develop :)
It might be that this isn't merged in, because it doesn't fit well or it's already there in some way, or there is a better way to do the way thing. If that's the case don't be disheartened, there are plenty of ways to get involved and everything helps. :)
Great! Thanks for the information, I'll be stopping by regularly to see what the core developers have to say :)
Hello @ikelos thanks for your comments. My first attempt was not optimal, as I duplicated code. It's now fixed by adding a new attribute to the CLIRenderer class; outfd (output file descriptor). Its value is set in __init.py__ line 484.
One word regarding your note : My usecase was to automate Vol3 with KAPE tool. In a nutshell, KAPE is an orchestrator tool used in DFIR. It does not support redirection operator '>' and most of the embeded tools inside KAPE produces output files. To me, it was weird that Vol3 was not able to produce an output file on its own. (To be precise, KAPE can handle this kind of problem but not in the same way). The use case can be useful when you want to automate the tool.
Thanks for that explanation. If you're getting an external tool to run volatility, then you could get it to run a script that pipes the output somewhere? It also occurs to me that this will cause confusion since there's now an output filename, and an output folder, which can be different?
It also seems as though this problem isn't unique to volatility. So much so that there's an option in KAPE to save the output of the tool as a result: https://ericzimmerman.github.io/KapeDocs/#!Pages\2.2-Modules.md#exportfile ?
The plugins were designed to make it easy to redirect their output, but this PR feels like it's been done quickly to solve a single problem rather than thinking through the use cases and designing something that will be possible to add to in the future. Also, given the suggested use case already had a solution, I'm going to reject this one for now I'm afraid.
If you really want to work up redirection, then focus on building out the RendererOptions so that they're generic and could be useful for lots of different features. I'll be happy to take a look at another attempt if you come up with one and have kept these comments in mind...
this PR feels like it's been done quickly to solve a single problem
Absolutely @ikelos, which is why I've tried to make my code cleaner after your initial comments.
For the use case, maybe you're right, the idea was also to provide the same options as what volatility2 had. Thanks for your feedback.