Windows: Add --name option to pslist plugin
#1077
Conversation
Add the capability to filter by name the windows.pslist output, where users can define the name of the process they would like to filter out in the process list. The behavior of the filter is described below: - Filter is case-sensitive, e.g. Input `--name Foo` will not return a process named foo. - Filters full match only, e.g Input `--name foo`: return all processes named foo, it would not return foobaz. - Input `--name foo bar`: return all processes named foo and bar. Described below the semantics when `--pid` filter is defined with `--name`: - Input `--name foo --pid 123`: return all processes named foo and all processes with pid 123, if these intersect, meaning the process 123 is also named foo, it will return only that one process. If these cases dont exist return the empty list. - Input `--name foo bar --pid 123 456`: return all processes named foo and bar and all processes with pid 123 and 456. The semantics are the same as previous point but for multiple names and pids. All cases mentioned above were tested manually.
|
Without having done a review, I'm wondering why this can't be completed with a tool such as grep? There really doesn't seem to be a significant use case and there's been no justification for why it should be so restrictive (full match only, case-senstive). There have been a number of these filtration flag requests recently and instead of having them dotted across different plugins added one at a time, I'd prefer to a) get them in sync with each other and b) know why they're necessary in volatility rather than piping the volatility output through another tool that can do the filtration better (and wouldn't then require us to look after them)? |
|
Sorry I haven't had time to get back to this, but I owe you a better explanation of the questions I put to you. My concern is that the basic task we're trying to accomplish is to filter the output data of the plugin, which actually doesn't need to be something the plugin knows or cares about at all. This proposed solution does that by adding a flag to the plugin explicitly to filter a single column. What that could lead to is fifty more plugins all defining their own flags for filtering results, and some even potentially making a flag for each column to filter ( So if it's something the plugin needs to know (because maybe it could speed up the scans) then it can be a plugin flag, but if it's something that applies to outputting the data, that lives with UI (so it can be applied to all plugins and different UIs can decide to do it differently and the number of parameters for each plugin stay managable). So I won't be taking this PR as is, but I'm happy to help work on a solution for the CLI to do filtering, something similar to #1085 perhaps? It'll need a bit of design and planning, but once it's done it should be a simple and effective way to filter results without requiring each plugin to write its own code to do essentially the same thing. If there are specific cases where the plugin could significantly change its behaviour (reducing the time required to scan, or processing the data to carry out the filtering) then we could still add those as parameters as well as the generic UI filtering mechanism. We should also look at #1072, it might be that could be better achieved by a simple output filter, or whether it's quicker for the plugin to know which things it needs to dive into and which it doesn't. You might also want to consider how the functionality could be added to Volumetric, it would be very cool to have live/editable filters of the ? I hope that explains my earlier questions and gives you some insight into the thinking behind the call, sorry I was so abrupt first time around, there were a deluge of new pull requests that all needed my attention but that's not a good excuse for my response. |
|
No problem at all @ikelos and thank you for your clear explanation. I was probably missing the bigger picture since I am getting familiar with the project. I followed the pattern of |
|
This should now be superseded by #1098, please test that branch and see if it resolves the same problem this was trying to resolve, and if so this PR can be closed. |
|
Sounds good! Will test #1098 to check out the feature, once in |
|
No problem, #1098 has now landed in develop, please take a look to see how I imagined implementing it (and feel free to offer suggestions/improvements, there's a list of things that could do with improving attached to the PR). 5:) |
Add the capability to filter by name the windows.pslist output, where users can define the name of the process they would like to filter out in the process list.
The behavior of the filter is described below:
--name Foowill not return a process named foo.--name foo: return all processes named foo, it would not return foobaz.--name foo bar: return all processes named foo and bar.Described below the semantics when
--pidfilter is defined with--name:--name foo --pid 123: return all processes named foo and all processes with pid 123, if these intersect, meaning the process 123 is also named foo, it will return only that one process. If these cases dont exist return the empty list.--name foo bar --pid 123 456: return all processes named foo and bar and all processes with pid 123 and 456. The semantics are the same as previous point but for multiple names and pids.All cases mentioned above were tested manually.