volatilityfoundation
Framework: Add 'Data' type to base types
This adds a Data base type, which will provide the information
(layer_name and offset) required to view variable amounts of data
both before and after that offset, instead of handing fixed-sized
chunks of data back.
This will allow plugin consumers to flexibly determine how much data to render/extract without having to re-run the plugin with different parameter values.
This PR is the first step in the outline proposed as part of the discussion surrounding #1287 - subsequent PRs will follow that implement rendering of this new data type in the CLI and configuration of default parameters, and the conversion of existing plugins to return this new data type where appropriate (yarascan, vadyarascan, vmayarascan).
@ikelos this PR is very minimal, so please let me know if I'm missing something here - hopefully it's enough to start discussion and get the ball rolling on the next steps.
I think we probably also want to include an expected minimal length. The UI/user can override it, but the plugin will probably know about how much data it expects people to get, and we should include that in the return value.
I'm quite remote at the moment so I'll try to give it a look when I can but it may be next week before I get a chance to look it over.
Thanks for mocking up the discussed solution!
On Fri, 11 Oct 2024, 22:53 David McDonald, @.***> wrote:
@ikelos https://github.com/ikelos this PR is very minimal, so please let me know if I'm missing something here - hopefully it's enough to start discussion and get the ball rolling on the next steps.
— Reply to this email directly, view it on GitHub https://github.com/volatilityfoundation/volatility3/pull/1310#issuecomment-2408167083, or unsubscribe https://github.com/notifications/unsubscribe-auth/AALIZVL4QZNK7OV7MLV3DLDZ3BCGZAVCNFSM6AAAAABPZWLTMCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIMBYGE3DOMBYGM . You are receiving this because you were mentioned.Message ID: @.***>
Looks good, probably best if we included (at least a basic) display mechanism (so the render method that will display these). It should be off in its own method (the existing ones are all kinda lambda functions except maybe the dissembly one) and (for now) it should just pull out the length bytes and display them as a hex dump, I think? Then (in a separate PR) we can figure out how to weave the output options through to the renderers (that code was never developed but there should be a pathway to feed options through to the renderers and we really should develop it properly, even if just a basic version).
So that should allow plugins to start making use of the new type and we should get roughly identical results to what we have now where the actual data is returned, only handled by the UI rather than the plugin. Then step two will be to let the UI tinker with how it's displayed...