VB Decompiler

Dr Memory · Expert Joined: 16 Aug 2004 Posts: 147 Location: Surrey, UK

In this adjacent thread ....
[url:1ye4rs86]http://www.vb-decompiler.com/viewtopic.php?p=2542#2542[/url:1ye4rs86]

.... some of the pitfalls of customising VB6 dll's are brought to mind, so perhaps a few advisory notes might be useful. Take them with all the salt you wish, but I believe them to be reasonable:

don't build VB dll's with other people's tools! Not unless you know EXACTLY what the tool does, and how it does it. [/*:m:1ye4rs86]

avoid techniques that interfere with your base application code in any way, or tweak the EXE afterwards, or need external DLL's, or have overly-fancy add-in GUI windows. [/*:m:1ye4rs86]

DO study John Chamberlain's CC paper and samples religiously. It's chief significance is that it was the first to explains something about how VB6 produces compiled exe's and dll's, something quite "enabling".

The simple operation of the CreateProcess hook and ability to "subclass" each module's C2 compilation, and most importantly, the LINK, are the nuggets in this particular bowl of gravy (cheers JC et al)[/*:m:1ye4rs86]

Don't get too carried away with the the experiments you'll find in JC's original work that deal with modifying the program's code from the assembler listings, although you will of course be greatly interested in them - the work you have to do to be able to re-assemble it is not worth it, IMHO. Remember the article is quite old (how I wish I'd seen it at the time!)[/*:m:1ye4rs86]

DLLMAIN

If you substitute one of your VB routines as the DLL entry point at the LINK stage, be aware that your DLL will therefore bypass some important initialisation calls. The impact will vary according to how the DLL has been loaded (static, loadlib?), whether is being loaded by an API call, or from COM dispatch, or even a VTable interface, all these things require different aspects of initialisation, and are all affected to various degrees by side-stepping the standard startup code.[/*:m:1ye4rs86]

Total Control?

Controlling the compile process is great stuff, and in fact mandatory for any progress in this field, I'd say, but it is by no means the complete picture.

I speak of COM, of course - C2 and LINK are used to compile all your source code, it's true, but that is just your client code, standard Win32 relocatable linker-produced PE code.

All the code and data that comprises your application's private COM server (for your "VB" class library) is also in there - that is produced automatically, possibly directly by VB6.exe. It passes data to the C2 compiler via intermediate files for each module being compiled. At the LINK step, there is an extra OBJ file, with the project name, and that's where all the COM interface kit is.[/*:m:1ye4rs86]

Hope some of this helps, if I think of anything more, I'll add to it ....

Cheers

ionescu007 · Sometimes here Joined: 21 Aug 2004 Posts: 33

The COM stuff is generated by VBA6.dll which contains the internal VB compiler. As soon as I'm done reversing the VB runtime I'll try reversing the compiler...I've already found the main routines that generate some of the stuff...it's not easy and it's a horrible mess.

And well, since I do make a VB DLL Add-In, and just want to point out that it's safe to use and doesn't insert anything dangerous in your dll. Of course all I can offer is my word...

Best regards,
Alex Ionescu
Kernel Developer, ReactOS
President, Relsoft Technologies