verbose: show process name and other human-level details

[williballenthin]

closes #1816

major parts:

• add DynamicFeatureExtractor.get_process_name() and DynamicFeatureExtractor.get_call_name()
• update DynamicLayout (result document and proto) to record processes/threads/calls used during matching.
• update verbose and vverbose renderers to show human readable process name and API call trace entry:

Checklist

• No CHANGELOG update needed

• No new tests needed

• No documentation update needed

[williballenthin]

the lines are getting to be pretty long, so interested to hear what you all think of the example above.

it might be possible to render this:

0000A65749F5902C4D82.exe[3052:2792][828] NtDuplicateObject(SourceProcessHandle=0xffffffff, SourceHandle=0xfffffffe, TargetProcessHandle=0xffffffff, TargetHandle=0x274, Options=0x2) -> 0x0, and 3 more...

as this:

0000A65749F5902C4D82.exe[3052:2792][828] 
  NtDuplicateObject(
    SourceProcessHandle=0xffffffff, 
    SourceHandle=0xfffffffe, 
    TargetProcessHandle=0xffffffff, 
    TargetHandle=0x274, 
    Options=0x2
  ) -> 0x0, and 3 more...

at the expense of more vertical real estate

[mr-tz]

really cool, some things to discuss inline

for later potentially: would be really cool to highlight the match part in the rendered call line (not worth the effort right now!)

[williballenthin]

putting args on their own line makes the output much more readable (imho) but also makes the output really long. keeping the full call information on a single line is harder to read (imho):

[williballenthin]

i find myself often wanting to see the full details of each matching call so that i can extract indicators. for example, seeing all the CreateFile calls to extract the filename parameter. but we only show a single example to prove the rule matched correctly. i think this suggests that maybe we want to explore how to use capa/dynamic to extract indicators, not just behaviors.

[williballenthin]

would be really cool to highlight the match part in the rendered call line

this is probably possible, though it requires us to record the full tuple (func name, [arguments], return value) for each call, rather than a single rendered string. and, handle things like human readable vs raw value of arguments. im hesitant to try to define these structures today, since we've only looked at CAPE and the data it provides. i think we should integrate another sandbox before we attempt to find the right abstraction.

[williballenthin]

API call rendered on its own lines, indented to help highlight the function name and differentiate the arguments. the whole block is muted (grey) so the rule logic can remain the focus of attention.

i dont really like the duplication of the event at the rule root and each of the features, but i haven't brainstormed on a better policy yet.

[williballenthin]

when in dynamic flavor and in call scope, only render the call at the top level of the rule output, and don't repeat it for each matching feature (which is necessarily a call-scope feature):

[mr-tz]

LGTM, I think we can fine tune this down the road, if needed. Thanks!

[yelhamer]

LGTM! Thanks!