Ability to change how byte results are displayed

[Kmasa-cysec]

Yarascan(windows.vadyarascan) of volatility3(beta) only shows hexdump of search string.

A sample run would look like the following:

>python3 vol.py -f sample.mem windows.vadyarascan.VadYaraScan --yara-rules="gmail"
Volatility 3 Framework 1.1.0-beta.1
Progress:    0.00       Scanning primary2 using PdbSignatureScanner
Offset  Pid Rule    Component   Value

0x2222060f52f   68  r1  $a  67 6d 61 69 6c
0x2222071132f   68  r1  $a  67 6d 61 69 6c
0x22220884a6f   68  r1  $a  67 6d 61 69 6c
0x259a52339da   568 r1  $a  67 6d 61 69 6c
0x247a4291d64   1624    r1  $a  67 6d 61 69 6c
0x247a4532db4   1624    r1  $a  67 6d 61 69 6c
0x247a4534840   1624    r1  $a  67 6d 61 69 6c
---snip---

By the way, in volatility2.6, it is displayed as follows.

>python vol.py -f sample.mem --profile="Win10x64_18362" yarascan --yara-rules="gmail" -s 64
Volatility Foundation Volatility Framework 2.6.1
Rule: r1
Owner: Process Registry Pid 68
0x2222060f52f  67 6d 61 69 6c 2e 63 6f 6d a0 ff ff ff 6e 6b 20   gmail.com....nk.
0x2222060f53f  00 85 6e 43 95 83 77 d6 01 02 00 00 00 c8 e4 f3   ..nC..w.........
0x2222060f54f  03 00 00 00 00 00 00 00 00 ff ff ff ff ff ff ff   ................
0x2222060f55f  ff 01 00 00 00 d0 e8 34 01 e0 6d 33 01 ff ff ff   .......4..m3....
Rule: r1
Owner: Process Registry Pid 68
0x22220884a6f  67 6d 61 69 6c 2e 63 6f 6d f8 ff ff ff 30 45 00   gmail.com....0E.
0x22220884a7f  00 80 ff ff ff 6e 6b 20 00 ed f4 3c c5 83 77 d6   .....nk....<..w.
0x22220884a8f  01 02 00 00 00 60 2e 00 00 00 00 00 00 00 00 00   .....`..........
0x22220884a9f  00 ff ff ff ff ff ff ff ff 01 00 00 00 c0 8f 05   ................
Rule: r1
Owner: Process Registry Pid 68
0x2222071132f  67 6d 61 69 6c 2e 63 6f 6d f0 ff ff ff 6c 68 01   gmail.com....lh.
0x2222071133f  00 c8 02 03 00 f4 3d f4 b6 e0 ff ff ff 76 6b 08   ......=......vk.
0x2222071134f  00 16 00 00 00 68 03 03 00 01 00 00 00 01 00 00   .....h..........
0x2222071135f  00 4b 65 79 77 6f 72 64 73 e0 ff ff ff 41 00 73   .Keywords....A.s
---snip---

[ikelos]

In volatility 3 we return the field as bytes (and potentially provide a hint as to how to display it). We don't really have the luxury of multi-line output in the CLI, and we figured that given how long the blocks are, providing the hex output was the most consistent way to communicate the information provided. We're hoping now that vol3 can be used as a library that richer clients can be written that will offer the options and scope to display the output in different ways at the user's choice, but the CLI is rather packed from an options perspective. There is scope for renderer options (to allow choices over how things like byte stream are displayed), but that's quite far down the roadmap...

[swepeba]

Maybe a luxury thing, but I must say I am really missing the extra information of process name and PID associated with each search hit. Wouldn't it be great to see that in one or two extra columns? It is must easier to visually correlate output information from different modules if the PID is available.

@ikelos: I suppose these richer clients you mention are not available at the moment and might even first appear as commercial products?

[ikelos]

@swepeba The extra information you're after is available if you use the vadyarascan which is windows specific and is able to understand what a process is and that the information lives within a process's memory space. The standard yarascan plugin is OS agnostic and will work with memory images for mac, linux and windows, on any intel layer that volatility 3 can construct. The question that was posted is about the hexdump in particular...

There aren't many rich clients out there, but there are already developers starting to work with volatility 3. To my knowledge none of them are commercial. At the moment there's a toy web-based gui, called Volumetric, that the foundation built which is under the same license as volatility 3, and I believe there's also Orochi which I believe is not commercial either.

The main drive of this project is to produce a library that can be used for whatever purpose would be helpful, and the CLI which everyone is familiar with is just one example interface towards that end. If you suitably improve the CLI to produce appropriate output, or wish to modify the CLI (by producing a new CLIRenderer) then we'd be happy to review it and consider it for inclusion. You might also be interested in the renderer-options branch which would allow configuration of specific renderers (but at the cost of exploding the number of options that CLI has to support).

I hope that provides you a bit more information on how you can access the information you're after, and why the library and CLI have been designed the way they have... 5:)

[swepeba]

@ikelos Thanks for the tip and extra information about the project! vadyarascan works perfect for my need. I will take a look on the rich clients you mention as well.