Windows: update vadyarascan to use generic yarascan requirements

[eve-mem]

Hello 👋

This PR updates the windows vadyarascan plugin to change how it's requirements are created as per #1047.

Here is an example of running the vadyarascan plugin directly using rules the crypto_signatures.yar rules

$ python vol.py -f win-xp-laptop-2005-06-25.img windows.vadyarascan --yara-file crypto_signatures.yar 
Volatility 3 Framework 2.5.2
Progress:  100.00               PDB scanning finished
Offset  PID     Rule    Component       Value

0x7b247a        504     Big_Numbers0    $c0     37 37 37 37 37 37 37 37 37 37 37 37 37 37 37 37 37 38 35 37
0xb5144b        504     Big_Numbers0    $c0     30 30 30 30 30 30 30 30 30 30 30 36 36 36 36 36 36 36 46 36
0x75f288f4      504     Advapi_Hash_API $advapi32       41 44 56 41 50 49 33 32 2e 64 6c 6c
0x75f29986      504     Advapi_Hash_API $CryptCreateHash        43 72 79 70 74 43 72 65 61 74 65 48 61 73 68
0x75f29998      504     Advapi_Hash_API $CryptHashData  43 72 79 70 74 48 61 73 68 44 61 74 61
0x75f299a8      504     Advapi_Hash_API $CryptAcquireContext    43 72 79 70 74 41 63 71 75 69 72 65 43 6f 6e 74 65 78 74
0x77dd312a      504     Advapi_Hash_API $advapi32       41 44 56 41 50 49 33 32 2e 64 6c 6c
0x77dd3e27      504     Advapi_Hash_API $CryptCreateHash        43 72 79 70 74 43 72 65 61 74 65 48 61 73 68
0x77dd3f9f      504     Advapi_Hash_API $CryptHashData  43 72 79 70 74 48 61 73 68 44 61 74 61
0x77dd3dea      504     Advapi_Hash_API $CryptAcquireContext    43 72 79 70 74 41 63 71 75 69 72 65 43 6f 6e 74 65 78 74
0x77dd3dff      504     Advapi_Hash_API $CryptAcquireContext    43 72 79 70 74 41 63 71 75 69 72 65 43 6f 6e 74 65 78 74
0x77de76e4      504     MD5_Constants   $c4     01 23 45 67
0x77de76eb      504     MD5_Constants   $c5     89 ab cd ef
0x77de76f2      504     MD5_Constants   $c6     fe dc ba 98
0x77de76f9      504     MD5_Constants   $c7     76 54 32 10
0x77de789f      504     MD5_Constants   $c9     78 a4 6a d7
0x7c81d73c      504     Advapi_Hash_API $advapi32       41 00 44 00 56 00 41 00 50 00 49 00 33 00 32 00 2e 00 44 00 4c 00 4c 00
0x7c81d2ac      504     Advapi_Hash_API $CryptCreateHash        43 72 79 70 74 43 72 65 61 74 65 48 61 73 68
0x7c81d254      504     Advapi_Hash_API $CryptHashData  43 72 79 70 74 48 61 73 68 44 61 74 61
0x7c81d2bc      504     Advapi_Hash_API $CryptAcquireContext    43 72 79 70 74 41 63 71 75 69 72 65 43 6f 6e 74 65 78 74
0x1010a6f       528     VC6_Random      $c0     a1 bc 1a 07 01 69 c0 fd 43 03 00 05 c3 9e 26 00 a3 bc 1a 07 01 c1 f8 10 25 ff 7f 00 00 c3
0x77c371d3      528     VC8_Random      $c0     e8 4d 2d 00 00 8b 48 14 69 c9 fd 43 03 00 81 c1 c3 9e 26 00 89 48 14 8b c1 c1 e8 10 25 ff 7f 00 00 c3
0x77c8df20      528     CRC32_poly_Constant     $c0     20 83 b8 ed
<SNIP>

The windows svcscan plugin uses vadyarascan, and this also works as before with no changes needed to svcscan. I'm hopeful that means any other plugins out there that use vadyarascan therefore won't be affected either.

$ python vol.py -f win-xp-laptop-2005-06-25.img windows.svcscan
Volatility 3 Framework 2.5.2
Progress:  100.00               PDB scanning finished
Offset  Order   PID     Start   State   Type    Name    Display Binary

0x6e1e90        1       N/A     SERVICE_DISABLED        SERVICE_STOPPED SERVICE_KERNEL_DRIVER   Abiosdsk        Abiosdsk        N/A
0x6e1f20        2       N/A     SERVICE_DISABLED        SERVICE_STOPPED SERVICE_KERNEL_DRIVER   abp480n5        abp480n5        N/A
0x6e1fb0        3       N/A     SERVICE_BOOT_START      SERVICE_RUNNING SERVICE_KERNEL_DRIVER   ACPI    Microsoft ACPI Driver   \Driver\ACPI
0x6e2038        4       N/A     SERVICE_DISABLED        SERVICE_STOPPED SERVICE_KERNEL_DRIVER   ACPIEC  ACPIEC  N/A
0x6e20c8        5       N/A     SERVICE_DISABLED        SERVICE_STOPPED SERVICE_KERNEL_DRIVER   adpu160m        adpu160m        N/A
0x6e2158        6       N/A     SERVICE_DEMAND_START    SERVICE_STOPPED SERVICE_KERNEL_DRIVER   aec     Microsoft Kernel Acoustic Echo Canceller        N/A      
0x6e21e0        7       N/A     SERVICE_SYSTEM_START    SERVICE_RUNNING SERVICE_KERNEL_DRIVER   AFD     AFD Networking Support Environment      \Driver\AFD      
0x6e2268        8       N/A     SERVICE_BOOT_START      SERVICE_RUNNING SERVICE_KERNEL_DRIVER   agp440  Intel AGP Bus Filter    \Driver\agp440
0x6e22f8        9       N/A     SERVICE_DISABLED        SERVICE_STOPPED SERVICE_KERNEL_DRIVER   Aha154x Aha154x N/A
0x6e2388        10      N/A     SERVICE_DISABLED        SERVICE_STOPPED SERVICE_KERNEL_DRIVER   aic78u2 aic78u2 N/A
0x6e2418        11      N/A     SERVICE_DISABLED        SERVICE_STOPPED SERVICE_KERNEL_DRIVER   aic78xx aic78xx N/A
0x6e24a8        12      N/A     SERVICE_DISABLED        SERVICE_STOPPED SERVICE_WIN32_SHARE_PROCESS     Alerter Alerter N/A
0x6e2538        13      2868    SERVICE_DEMAND_START    SERVICE_RUNNING SERVICE_WIN32_OWN_PROCESS       ALG     Application Layer Gateway Service       C:\WINDOWS\System32\alg.exe
<SNIP>

[ikelos]

This should be fine, but we just need to keep an eye on the requirements matching the functionality. For instance, there was previously no insensitive flag, and now there is. Since it inherits heavily, this should be fine but just something to keep an eye on...

[eve-mem]

Good spot @ikelos - I'm hopeful that shouldn't be an issue. It probably means that the version number for the plugin needs to go to 1.1.0? As it's an actually additive change - Feels a little silly for me to make a PR for that but very happy to if you think it's the right thing to do. I'm just thinking if this breaks something subtle in the future knowing the difference between 1.0.0 and 1.1.0 might help?

[ikelos]

It's a bit of a tricky one, the API number is for plugin to use to verify other plugins. I don't think we've included the external/requirements in that, because they can be probed by the plugin at runtime (although most people will make assumptions). You did change the version to 1.0.1, so we could determine the change if necessary and critically, the config options the plugins accept shouldn't be used by other code, they should only be used by the UI. Other plugins should be directly calling the API methods, which haven't changed (and already accepted that setting).

Ugh, that does raise a sticky situation though, and one which we should resolve... The yarascan plugin now takes a config dictionary, and exposes that as the API. That's pretty bad form because you've no idea what keys get accepted, which get acted upon. Really each flag that's needed should be specified precisely (which then leads to each plugin needing to have those config items because it needs to pass them through the API). 5:\ Well, this is a bit messy, I'll need to go back and check any notes around when the process_yara_options method was merged... 5:\

[ikelos]

Oh dear, looks like I missed it way the way back in 2020. 5:S It's kind of ok, since the rules returned are what the plugin actually uses, but it's keeping the requirements and the processing in sync that's the issue (ie, making sure the options used match the rules object generated). Perhaps we could just beef up option checking a little? The other option would be to parameterize the process_yara_options to take each individual option? We could then pass in **conf, and that should have the same effect? That would be a major version bump to yarascan, but it might be the best way to resolve the issue? What do you think?

[ikelos]

It also doesn't look like the insensitive flag is actually used at all?!? 5:S

[eve-mem]

😬 - ahhh sorry about the headache.

I'm not sure I'm qualified to give you a useful opinion, but it sounds to me like fixing it process_yara_options with parameters rather than the "config.get if/elif/elif" block makes sense to me and I'd understand how to make that change.

Is it worth making a separate issue?

[ikelos]

Yeah, probably best so we don't lose track of it, if you don't mind? Thanks!