Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

--filters parameter can break JSONL renderer #1309

Open
dgmcdona opened this issue Oct 11, 2024 · 1 comment
Open

--filters parameter can break JSONL renderer #1309

dgmcdona opened this issue Oct 11, 2024 · 1 comment

Comments

@dgmcdona
Copy link
Contributor

dgmcdona commented Oct 11, 2024

The --filters parameter appears to break the JSONL renderer when a parent TreeNode does not match the filter criteria. This does not appear to be a problem in other renderers.

Context
Volatility Version: 2.11.0
Operating System: macOS
Python Version: 3.8.10

To Reproduce
Run a plugin that produces an actual tree-like set of results, like pstree or amcache, with the jsonl renderer and a --filters parameter that is guaranteed to filter out every entry except one, which must be a child of another node.

Expected behavior
IMO, sane behavior would be for parent nodes to still be included in the resulting output, in order to preserve the 'depth' of the result. However this is not the case with other renderers - should it be?

Example output
This works fine:

$ python3 vol.py -q -r pretty --filters Path,"c:\Program Files (x86)\Common Files\Microsoft Shared\VC\msdia90.dll" -f Win8SP1x64.lime.raw amcache
Volatility 3 Framework 2.11.0
Formatting...
   | EntryType |                                                                                                       Path |               Company |                 LastModifyTime |                LastModifyTime2 |                    InstallTime |                    CompileTime |                                     SHA1 | Service |                                                    ProductName | ProductVersion
** |      File |                                        c:\Program Files (x86)\Common Files\Microsoft Shared\VC\msdia90.dll |                     - |                              - | 2011-04-19 09:47:04.000000 UTC |                              - |                              - |                                        - |     N/A |  
$ python3 vol.py -q -r jsonl --filters Path,"c:\Program Files (x86)\Common Files\Microsoft Shared\VC\msdia90.dll" -f Win8SP1x64.lime.raw amcache
Volatility 3 Framework 2.11.0

Traceback (most recent call last):
  File "vol.py", line 11, in <module>
    volatility3.cli.main()
  File "/home/user/volatility3/volatility3/cli/__init__.py", line 923, in main
    CommandLine().run()
  File "/home/user/volatility3/volatility3/cli/__init__.py", line 515, in run
    renderer.render(grid)
  File "/home/user/volatility3/volatility3/cli/text_renderer.py", line 469, in render
    grid.populate(visitor, final_output)
  File "/home/user/volatility3/volatility3/framework/renderers/__init__.py", line 251, in populate
    accumulator = function(treenode, accumulator)
  File "/home/user/volatility3/volatility3/cli/text_renderer.py", line 461, in visitor
    acc_map[node.parent.path]["__children"].append(node_dict)
KeyError: '21'
@ikelos
Copy link
Member

ikelos commented Oct 13, 2024

I think it'll get pretty messy if we have to start figuring out which parent nodes we'll need to keep. I figured jsonl would just reference a previous node, so we can either put "filtered" or something else to indicate the parent isn't present.

As for other plugins, I'd expect them to float standalone at whatever level they were at. I don't know if we care about the tree integrity if the user has asked specifically only to see the filtered rows. I feel it's kind of up to the UI, so something wanting to use an actual tree display may require earlier entries, but as a CLI, I'm not sure that's a requirement? It's not a strong feeling, but otherwise every rendered would become a slow renderer because you may have to parse all the results to know if the first one should be output or not...

What do you think? I've only got a mild view towards it?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants