Initial draft of complete-vad vadyarascan

volatilityfoundation / volatility3

Volatility 3.0 development

http://volatilityfoundation.org/

Other

2.72k stars 463 forks source link

Initial draft of complete-vad vadyarascan #1193

Closed ikelos closed 4 months ago

ikelos commented 4 months ago

Ok, here's an initial version of a change to vadyarascan that should scan a vad in its entirety when doing yara scanning.

Essentially it ignores the scanning framework, because we've already got the process layer to make the vads contiguous so we don't need any of the rebuilding/paging that the scanning framework does. It's a little bit duplicative in places, but not a huge amount and we use the option/rule creation code from yarascan, so this should be ok. Please could people test it for me...

Closes #1189. Closes #1155.

eve-mem commented 4 months ago

Lgtm. I'll do a touch more testing but it seems good.

Should we also make some changes to the generic yarascan plugin at the same time? Mayne leave that for another PR

dadokkio commented 4 months ago

Speaking about yarascan I was testing yara-x instead of yara-python for matching since it should be faster (even not so much for initial testing), maintained and easier to use.
I've created a fork for this trying to keep the same output rendering and it's working also with depending plugins like vadyarascan.

Some considerations:

there is no function to obtain matched value so I took that slicing original data
the compiled yara-python rule is not similar to the one yara-x serialize into file, so you cannot use old compiled rule with this approach. More info here

Not sure if this could be interesting or not, if needed I can make a pull request.

ikelos commented 4 months ago

Thanks, that looks interesting! I'm not sure how easy to get yara-x installed as a package on various systems would be, but it might be possible to integrate it as an alternative to yara all within the same plugin?

We could use it as the opportunity to change yara_rules to yara_string as you've done, we'd need to leave in support for the older yara implementations return values.

It looks like you've already done the bulk of the work, it would just be a case of checking which module exists in priority order (yara-x, then yara-python) and using that one (with maybe an implementation adaptor class in between)?