We just updated JustDecompile, our free decompiler with an open source decompilation engine, with new search capabilities, making it faster and more powerful.
In the R1 2017 release, JustDecompile got results filtering added to its search functionality. This seemingly simple feature adds tremendous power to the search. In effect with this addition JustDecompile encroaches the realm of code analysis.
In the search window there is a new Filtration control.
This gives a chance to add an unlimited number of filters on the values of the columns of the search results grid.
One can do that while search is still running and filtering will be applied on the fly. Sorting the result view columns also works in combination with filtering.
One can filter the contents of any column in the search results grid. The filters can be grouped and combined with logical AND or OR. This gives immense power to the search. E.g., one can now be looking for strings starting with “A” contained in assembly which version is greater than 184.108.40.206. As a result, one can not only find these strings but count them. Or see how that count changes between two consecutive versions of the same assembly. The opportunities are unlimited.
It has to be mentioned that search in JustDecompile does not first perform actual decompilation of all the assemblies in the assembly list and then search in the decompiled code. While really powerful, this approach is also really slow. So JustDecompile searches in the raw MSIL, relying on some clever techniques to extrapolate decompilation results. However, some information simply cannot be obtained without full decompilation.
These are not part of the assembly metadata. They can be found in the PDB file, but a PDB is not always present. If no PDB is found JustDecompile would name the local variables itself. Names are chosen heuristically based on various decompilation parameters. Hence it takes full decompilation to get a list of these names so they are not available at the time a search is performed. What this means is one might be searching for a variable name one sees in a snippet of decompiled code and the search might not yield any results.
The language features listed above (the list is not complete) don’t have direct mapping to MSIL statements. Instead for each of these the compiler generates complex MSIL code snippets spread across a number of compiler generated classes. I.e., since MSIL does not support this functionality out of the box, the compiler generates boilerplate code in MSIL to perform what each of these language features does. Moreover, the boilerplate code does not reside where the language feature was originally used.
As mentioned before JustDecompile does not do full decompilation while searching and without doing that it is pretty hard to figure out what the compiler generated boilerplate code stands for. If the “Show compiler generated types and members” setting is on, JustDecompile will search through the compiler generated code and find any occurrences of the search string there. It will not, however, map it correctly to the code location of the respective language feature original usage. The results will be shown as residing in the compiler generated members and classes instead.
We hope you enjoy the latest updates to our free, open source decompilation engine. New to JustDecompile? Learn more here or download it for free today.
Tsviatko is the Lead Developer for JustDecompile and Fiddler.
Copyright © 2017, Progress Software Corporation and/or its subsidiaries or affiliates. All Rights Reserved.
Progress, Telerik, and certain product names used herein are trademarks or registered trademarks of Progress Software Corporation and/or one of its subsidiaries or affiliates in the U.S. and/or other countries. See Trademarks or appropriate markings.