Decompiling calls from external ActiveX components - VB Decompiler v10.3
The new version of VB Decompiler brings native-code VB6 program decompilation to a radically new level! Starting from v10.3, VB Decompiler can decompile calls, methods, and properties of external ActiveX components not listed in its database. In addition to that, prototypes of 1853 API functions, including those of system functions, have been added to the database. The new version of VB Decompiler can better decompile arrays, as well as various operations on arrays. Besides, our software product has become much easier to use! But let's start from the beginning.
As you know, many programs developed in Visual Basic 5.0 or 6.0 use some external components provided by Microsoft or third-party software developers. A lot of Microsoft components have been added to VB Decompiler's database a long time ago, so as soon as the decompiler detects a familiar CLSID or UUID, it automatically selects the prototypes of the called functions or properties. But what if it detects an unfamiliar GUID of a class or interface? When using the previous versions of our product, you could see calls like UnkVCall with a DispatchID or an offset in VTable, which means that the calls of such functions were not recognized. The new version of VB Decompiler uses two brand-new methods to create prototypes of unknown functions from external ActiveX components:
1) At the project-building (VBP file creating) step, even before decompiling the forms and the program code, VB Decompiler learns about the external components used, namely the part of their GUIDs used for identifying them. Then it uses the system registry and some specialized objects-handling API functions to search for DLL/OCX files that contain the classes and interfaces corresponding to the GUIDs found. If the program being decompiled can be launched correctly, it usually means that its components are already registered in the system and can be found somewhere. Otherwise you need to register the ActiveX files used by the program under study in advance (for example, via regsvr32). If the external ActiveX components used are registered in the system, VB Decompiler will locate them, extract the TypeLib data, scan all the UnknownInterface's and DispatchInterface's used, and create prototypes of functions and properties contained within.
2) Some ActiveX components are called without being declared in the project, but via CreateObject, directly in the code of the program under study. VB Decompiler supports this method, too. It extract the required UUID and CLSID, and analyzes the TypeLib of the external ActiveX component just like in the first case.
Whichever of the two methods is used, all the ActiveX files processed are added to the decompiler's cache. It means that until you close VB Decompiler, opening new files or repeating the decompilation of the already processed ones will not launch re-analyzing of the external ActiveX components. As a result, the overall processing speed is much higher!
We had not updated the database of prototypes of called API functions for 10 years. Actually, even the previous versions of VB Decompiler supported about 1565 prototypes of system API functions, which is a lot. But now our decompiler knows about 3418 API functions, including nearly all known Windows system functions!
This significant extension of the API functions database eliminates any incorrect detection of parameters by the empty elements in the stack. Moreover, thanks to that, you can view each function's prototype in the API section, including parameter names and types, and the address of the adapter created by the Visual Basic compiler for that call, which makes the analysis much simpler.
As you know, Visual Basic is based on the COM OLE technology, as well as on Variants and SafeArray constructs. When developing the new version of VB Decompiler, we did a lot of work to extend the supported operations on SafeArray arrays: copying arrays between variables, creating temporary Variant variables from arrays, and moving the arrays back to SafeArray, and support for addressing in several arrays.
VB Decompiler has supported emulation of coprocessor commands for quite a long time. In the new version, we added support for complex addressing like this: fpu_command st0, real8 ptr [reg1+reg2*8] This is another major improvement of the emulator, which greatly extends our product's ability to emulate complex constructs.
With each new version, VB Decompiler becomes easier to use. In v. 10.3, we added switching to the HEX Editor by clicking a constant's address or a value that looks like an address but is not a function call. This way, you can quickly view references to objects, local variables, etc. Now the decompiler can recognize when you click a function call to show that call, or when you click a constant to display it in the HEX Editor. The decompiler version with tracing support displays long-line hints that do not fit in the screen.
Now if you open a project saved to VB Decompiler's database, the decompiler will try to find the file to be decompiled not only at the address where it was located when being saved, but also in the database folder. That's convenient if several analysts share the database for the same file.
Of course, we have fixed all the bugs found! Particularly, we fixed the handling of the Between commands (P-Code) used in complex Select Case conditions. We also fixed the rare bug that occurred when saving the index of controls on forms with obfuscated names to the database, which was quite annoying. Starting from v10.3, VB Decompiler does not entirely rely on a file's entropy. Even if the file has been detected as packed, an attempt to decompile it will be taken.
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!
Decompiling calls from unknown ActiveX components
As you know, many programs developed in Visual Basic 5.0 or 6.0 use some external components provided by Microsoft or third-party software developers. A lot of Microsoft components have been added to VB Decompiler's database a long time ago, so as soon as the decompiler detects a familiar CLSID or UUID, it automatically selects the prototypes of the called functions or properties. But what if it detects an unfamiliar GUID of a class or interface? When using the previous versions of our product, you could see calls like UnkVCall with a DispatchID or an offset in VTable, which means that the calls of such functions were not recognized. The new version of VB Decompiler uses two brand-new methods to create prototypes of unknown functions from external ActiveX components:
1) At the project-building (VBP file creating) step, even before decompiling the forms and the program code, VB Decompiler learns about the external components used, namely the part of their GUIDs used for identifying them. Then it uses the system registry and some specialized objects-handling API functions to search for DLL/OCX files that contain the classes and interfaces corresponding to the GUIDs found. If the program being decompiled can be launched correctly, it usually means that its components are already registered in the system and can be found somewhere. Otherwise you need to register the ActiveX files used by the program under study in advance (for example, via regsvr32). If the external ActiveX components used are registered in the system, VB Decompiler will locate them, extract the TypeLib data, scan all the UnknownInterface's and DispatchInterface's used, and create prototypes of functions and properties contained within.
2) Some ActiveX components are called without being declared in the project, but via CreateObject, directly in the code of the program under study. VB Decompiler supports this method, too. It extract the required UUID and CLSID, and analyzes the TypeLib of the external ActiveX component just like in the first case.
Whichever of the two methods is used, all the ActiveX files processed are added to the decompiler's cache. It means that until you close VB Decompiler, opening new files or repeating the decompilation of the already processed ones will not launch re-analyzing of the external ActiveX components. As a result, the overall processing speed is much higher!
Lots of new prototypes of API functions
We had not updated the database of prototypes of called API functions for 10 years. Actually, even the previous versions of VB Decompiler supported about 1565 prototypes of system API functions, which is a lot. But now our decompiler knows about 3418 API functions, including nearly all known Windows system functions!
This significant extension of the API functions database eliminates any incorrect detection of parameters by the empty elements in the stack. Moreover, thanks to that, you can view each function's prototype in the API section, including parameter names and types, and the address of the adapter created by the Visual Basic compiler for that call, which makes the analysis much simpler.
Enhanced support for arrays
As you know, Visual Basic is based on the COM OLE technology, as well as on Variants and SafeArray constructs. When developing the new version of VB Decompiler, we did a lot of work to extend the supported operations on SafeArray arrays: copying arrays between variables, creating temporary Variant variables from arrays, and moving the arrays back to SafeArray, and support for addressing in several arrays.
Support for new addressing types when emulating FPU commands
VB Decompiler has supported emulation of coprocessor commands for quite a long time. In the new version, we added support for complex addressing like this: fpu_command st0, real8 ptr [reg1+reg2*8] This is another major improvement of the emulator, which greatly extends our product's ability to emulate complex constructs.
Now it is even easier to use
With each new version, VB Decompiler becomes easier to use. In v. 10.3, we added switching to the HEX Editor by clicking a constant's address or a value that looks like an address but is not a function call. This way, you can quickly view references to objects, local variables, etc. Now the decompiler can recognize when you click a function call to show that call, or when you click a constant to display it in the HEX Editor. The decompiler version with tracing support displays long-line hints that do not fit in the screen.
Now if you open a project saved to VB Decompiler's database, the decompiler will try to find the file to be decompiled not only at the address where it was located when being saved, but also in the database folder. That's convenient if several analysts share the database for the same file.
Bug fixes
Of course, we have fixed all the bugs found! Particularly, we fixed the handling of the Between commands (P-Code) used in complex Select Case conditions. We also fixed the rare bug that occurred when saving the index of controls on forms with obfuscated names to the database, which was quite annoying. Starting from v10.3, VB Decompiler does not entirely rely on a file's entropy. Even if the file has been detected as packed, an attempt to decompile it will be taken.
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!
(C) Sergey Chubchenko, VB Decompiler's main developer