return structure from process_file() is inconsistent in ordering and layout.

[emf]

The ordering of items in the returned structure from process_file() changes often, as a result of seemingly innocuous parsing changes. Consumers of these results are then required to hunt for output they may not entirely know the formatting of. Furthermore, while each tuple in the returned list is of the general format (Action, Value, Description); the important actions are not always "Execute Command", and the "Description" values are generally what function resulted in the call, which -- again -- not easily predictable.

It would be great if the returned structure had a definitive list of every shell command run, regardless of how it got called.

Also; the "pretty printed" human readable output is quite possibly the most pessimal output format. One cannot copy-paste values out of this printed table without an extreme amount of work, and the user has much better luck searching in the logging.INFO output instead, but improving the return structure layout just prior to the pretty printed output is the important part.

(If I had my choice, i'd have it return a dictionary or json structure, instead of a list of unmarked tuples, with one of the dictionary keys giving an ordered list of every emitted commandline. )

[decalage2]

I agree, this is something I would like to change in the API. In most of my tools, process_file is only meant to be used when launching the tool from the command line. When we need an actual python API to integrate the tool into a python application, we should use the more object-oriented classes, not process_file. In the end, process_file should be simply calling other classes, and format the output for the console. The issue with the current ViperMonkey, is that several important steps of the processing have been added to process_file, instead of the ViperMonkey class. That's exactly what I would like to refactor, to obtain a better API. I was just too busy maintaining oletools, and could not do it yet for ViperMonkey.