A new evolution stage in decompiling .NET code and VB6 native code - VB Decompiler v10.4
I am happy to present the new version of VB Decompiler that contains tons of improvements and innovations. The main improvement that has had a profound effect on everything, is substantial optimization, refactoring, and runtime performance boost. In version 10.4, you will find a 5-fold increase in the speed of decompilation of applications built in Visual Basic 6.0 with the "native code" option, and a 7-fold increase in the speed of decompilation of .NET applications! In addition to that, assembly code tracing (in VB Decompiler versions that support Tracing features) runs as smoothly as possible thanks to the 5-fold increase in the refresh rate for each step. All these things are the results of the deep optimization!
Let's take a look at the innovations that make it easier to analyze code and improve the results.
Unlike in P-Code, exception handling in Native Code is based on SEH exception tables. The tables have a specific format that doesn't even remotely resemble that of the C++ or other compilers to machine code. Having deeply analyzed all kinds of exceptions and address tables, we added support for the three types of exceptions that you can find in VB6:
Before version 10.4, when analyzing COM objects in applications' Native Code, we mostly focused on GUI calls in a forms. Starting from the new version, the decompiler correctly processes class method calls if they are done by the same class. Because of the peculiarities of the COM architecture, these calls are also done by using an object's UUID, checking if the object has been created, and using the virtual method table (VTable). If you used the earlier versions of our decompiler, in such cases you would at best see UnkVCall[X], or the object would be decoded incorrectly. The new version supports Native Code classes like never before!
We did a deep refactoring of the decompiler code. Then we optimized the detection of global variables of an object (a form or a class), as well as the distinguishing between calls to them and calls to a method of the class or form. We significantly improved the analyzing of objects and call chains, which practically eliminates a false detection of objects and their global variables.
We also implemented support for many rarely-used functions, which are used when accessing object properties or methods (VarLateMemLdRfVar, VarLateMemLdVar, VarLateMemCallLdVar, IStDargCopy, ILdRfDarg, ILdDarg, ILdUI, ILdR8, ILdAd, and ILdFPR4).
The code for .NET processing had not evolved for quite a long time. Until recently, it was practically the same as that in the decompiler version of 2007. In version 10.4, we have completely redone that code. We fixed a lot of rare bugs and greatly increased the disassembling speed. We also eliminated various annoying things that had originated from the Visual Basic 6.0 limitations. Yes, the .NET decompiler was initially developed in VB6, which does not have any Unsigned Integer data types, and that required a lot of extra efforts on our part to process structures and code. However, it provided a great advantage from the very beginning: VB Decompiler did not use the .NET Framework at all. That is, you could use VB Decompiler 8.4 or the earlier versions (developed in VB6) in Windows 9x to decompile .NET code. Starting from version 9.0, the decompiler was fully rewritten and built using a state-of-the-art compiler. As a result, now you can do many things in the .NET decompiler much faster and much better. You will definitely see the changes in the new version of our product!
We've been tackling this problem for a long time, and finally we succeeded. I can proudly announce that, presenting the new version of VB Decompiler. Anyone who have ever encountered local variables in .NET knows that they are not just standard types like Integer, Byte, String, etc. They can be multidimensional arrays, generics, value types, and many other things, including different modifiers and class arrays. All of that is now supported in VB Decompiler. Moreover, calls to such variables through TypeSpec are supported, too. Just like before, only VB Decompiler provides information on the address of the local variables block in the file, as well as the address of each line of code.
Now the form decompiler correctly declares external ActiveX components, and also decompiles the built-in container of properties of such controls. Thanks to that, you can decompile icons and pictures in an ImageList and the properties of such controls as TreeView, SSTab, etc. We also fixed various bugs in the form parser, so now it almost perfectly decompiles the GUI part of .frm and .frx files, as well as of UserControl.
In the new version, we have changed the Procedure Analyzer and Optimizer (which you can turn on by checking the respective checkbox in the application's main window). Now, when analyzing Native Code, it will also filter duplicate calls if the function's result is used through the eax register instead of through a temporary variable. The decompiler will also try to decompile files with an unknown filename extension or without any extension at all if you drag and drop them from Explorer. Virus analysts who often have to handle files that do not have extensions like .exe, .dll, or .ocx, will love this feature. We also remembered about P-Code: In version 10.4, we added support for some rarely-used commands for handling objects' methods and properties: SetVarVarFunc, LateIdCallSt, VarLateMemLdRfVar, IStDargCopy, CRefVarAry, and ILdDarg. As you can see, this version is practically a major update with massive advantages. We keep in mind many other things to be improved, which we will certainly do in the forthcoming versions. Stay tuned for changes!
If you have an active subscription for updates and support, you can download the new version of VB Decompiler for free. If you have learned about our product just now, we'll be happy to see you among our clients!
Let's take a look at the innovations that make it easier to analyze code and improve the results.
Decompiling error handlers (SEH) in Visual Basic 6.0 Native Code
Unlike in P-Code, exception handling in Native Code is based on SEH exception tables. The tables have a specific format that doesn't even remotely resemble that of the C++ or other compilers to machine code. Having deeply analyzed all kinds of exceptions and address tables, we added support for the three types of exceptions that you can find in VB6:
- "On Error Resume Next": The code is split into blocks. If an error occurs, the control is transfered to the next block.
- "On Error GoTo XXX": If an error occurs, the control is transfered to the specified address. Because there may be multiple GoTo's, the format of exception tables may differ greatly, so we need to be able to process all formats.
- "On Error GoTo 0": Exception handling is disabled.
Decompiling internal procedure calls in Native Code classes
Before version 10.4, when analyzing COM objects in applications' Native Code, we mostly focused on GUI calls in a forms. Starting from the new version, the decompiler correctly processes class method calls if they are done by the same class. Because of the peculiarities of the COM architecture, these calls are also done by using an object's UUID, checking if the object has been created, and using the virtual method table (VTable). If you used the earlier versions of our decompiler, in such cases you would at best see UnkVCall[X], or the object would be decoded incorrectly. The new version supports Native Code classes like never before!
Objects and local variables in Native Code
We did a deep refactoring of the decompiler code. Then we optimized the detection of global variables of an object (a form or a class), as well as the distinguishing between calls to them and calls to a method of the class or form. We significantly improved the analyzing of objects and call chains, which practically eliminates a false detection of objects and their global variables.
We also implemented support for many rarely-used functions, which are used when accessing object properties or methods (VarLateMemLdRfVar, VarLateMemLdVar, VarLateMemCallLdVar, IStDargCopy, ILdRfDarg, ILdDarg, ILdUI, ILdR8, ILdAd, and ILdFPR4).
Many improvements in the disassembler of .NET applications
The code for .NET processing had not evolved for quite a long time. Until recently, it was practically the same as that in the decompiler version of 2007. In version 10.4, we have completely redone that code. We fixed a lot of rare bugs and greatly increased the disassembling speed. We also eliminated various annoying things that had originated from the Visual Basic 6.0 limitations. Yes, the .NET decompiler was initially developed in VB6, which does not have any Unsigned Integer data types, and that required a lot of extra efforts on our part to process structures and code. However, it provided a great advantage from the very beginning: VB Decompiler did not use the .NET Framework at all. That is, you could use VB Decompiler 8.4 or the earlier versions (developed in VB6) in Windows 9x to decompile .NET code. Starting from version 9.0, the decompiler was fully rewritten and built using a state-of-the-art compiler. As a result, now you can do many things in the .NET decompiler much faster and much better. You will definitely see the changes in the new version of our product!
Support for local variables in .NET
We've been tackling this problem for a long time, and finally we succeeded. I can proudly announce that, presenting the new version of VB Decompiler. Anyone who have ever encountered local variables in .NET knows that they are not just standard types like Integer, Byte, String, etc. They can be multidimensional arrays, generics, value types, and many other things, including different modifiers and class arrays. All of that is now supported in VB Decompiler. Moreover, calls to such variables through TypeSpec are supported, too. Just like before, only VB Decompiler provides information on the address of the local variables block in the file, as well as the address of each line of code.
Massive improvements in the Visual Basic 6.0 form decompiler
Now the form decompiler correctly declares external ActiveX components, and also decompiles the built-in container of properties of such controls. Thanks to that, you can decompile icons and pictures in an ImageList and the properties of such controls as TreeView, SSTab, etc. We also fixed various bugs in the form parser, so now it almost perfectly decompiles the GUI part of .frm and .frx files, as well as of UserControl.
Other improvements
In the new version, we have changed the Procedure Analyzer and Optimizer (which you can turn on by checking the respective checkbox in the application's main window). Now, when analyzing Native Code, it will also filter duplicate calls if the function's result is used through the eax register instead of through a temporary variable. The decompiler will also try to decompile files with an unknown filename extension or without any extension at all if you drag and drop them from Explorer. Virus analysts who often have to handle files that do not have extensions like .exe, .dll, or .ocx, will love this feature. We also remembered about P-Code: In version 10.4, we added support for some rarely-used commands for handling objects' methods and properties: SetVarVarFunc, LateIdCallSt, VarLateMemLdRfVar, IStDargCopy, CRefVarAry, and ILdDarg. As you can see, this version is practically a major update with massive advantages. We keep in mind many other things to be improved, which we will certainly do in the forthcoming versions. Stay tuned for changes!
If you have an active subscription for updates and support, you can download the new version of VB Decompiler for free. If you have learned about our product just now, we'll be happy to see you among our clients!
April 17, 2016
(C) Sergey Chubchenko, VB Decompiler's main developer