VB Decompiler

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

This screenshot shows a demo in operation that has a VB dll initialising correctly in response to being loaded by a non-VB caller, in this case a PowerBasic client (sorry, I have no C!)

The VB dll, operating without a ThunderRt6Main window, has to show the Form modally, but by using secondary threads the client is still free to do pretty much whatever it wants, run its own GUI, etc, as demonstrated.

A ScreenShot is provided here, but I'll zip and attach the actual EXE and DLL used here, you should be able to run them as is, as long as they are in the same folder (it works fine on Win 2000 and my laptop XP/SP6), and has no external dependencies.

I'll describe the method a bit more in the next post...

Hope it's of some interest ..

Cheers

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

In the screenshot above, a process viewer window is included that shows the modules and windows of the process. Our VB is entry number 10, dmProject1.dll (17000000)

About the DLL

Apart from switching the DLL's entry point, and ensuring that nominated VB functions are exported, no other DLL customisations are involved. All the VB6 dll is VB6.

The dll does not require an explicit initialisation call, when loaded it will automatically detect the caller is not VB and adjust the startup procedure accordingly.

The goal of the initialisation is the same for any type of client, only the method has to be varied.

The aim in all cases is to achieve the goal by engineering a call to the DLL's own DllGetClassObject function, passing it an IClassFactory interface reference.

No object is actually instanced by this process, however the DLL will have been initialised sufficiently to enable it to create VB forms and controls.

The DLL shows a form with 2 buttons. Pressing one updates a time display on the form, pressing the other makes a call back to a nominated function in the PowerBasic client.

The ScreenShot

The window on the right has the focus, that's the PB client's window. PB calls an exported function, ShowForm, in the DLL, passing it the address of a function for VB to call when a Click Event happens on that button.

The user has just clicked on that "Client Callback" button, and the DLL has called the PB callback function which has displayed the message box seen.

Note that PB's message box is modeless by default, which is why I was able to give focus back to the client's main window.

A second press on the same button would produce a second message window.

One Form At A Time
As stated, this simple model can show only 1 Form at a time, but that might well be sufficient, and it can be rendered effectively modeless with respect to the client by th use of secondary threads, so it does have some useful functionality.

How does it stay up at all without anybody providing a message pump? Clearly it can't, and we can safely deduce without looking that the VB "Modal Show" method has its own independent message disptach loop, which keeps it supplied, and also provides the "modal" effects of blocking access to other top-level windows in the app. I will not exit until the form is hidden or closed.

So we can show a VB Form from a non-VB client without a ThunderRt6Main window, if we show it modally.

The dll is thus restricted, in this simple model, to showing one Form at a time.

Client Application

This simple model is implemented by simply delegating all the client's own processing, its window creation and message dispatch loop, to a background thread, where it will have its own message queue and not interfere with the main thread's message loop.

Here's its "Main" logic:

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

The EXE and DLL used in this demo ....

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

My Gosh! I think I've just found the true Grail of this particular quest - the real thing in other words - multiply instanced modeless VB forms for the same client!

This thread could have a short shelf life indeed ... I think it's redundant already

Following thorough verification (and dinner), I hope to present a much improved screen shot

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

It's real! A new report will be required, but the new screen shot should show what I mean. We are back to simple single-threading, which is nice, too.

The same PB client will now request a new Form Instance every time the space bar is pressed. The form has lightweight controls and you can see they are working properly, as both Label and Image Click events are being correctly triggered

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

When the Form's button is pressed, it changes to a new backgnd coloyr.

When the label control is clicked, it reports how many times this has occurred since the Form was instanced.

When the Image control is clicked, a similar report is made, also using the Label caption.

_aLfa_ · Posted: Sun Sep 05, 2004 8:43 am Post subject:

Although I'll never use this, it seems a very nice piece of code
_________________
One thing only I know, and that is that I know nothing. (Socrates)

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

It's of little direct use to the reverse-engineering community, I'd have to agree

... but it's an example of the good things that can come out of sharing information.

I said elsewhere the structure information was critical in this DLL initialisation technique - actually now that I've refined it to this level, the structure info is no longer involved .....

But I'd never have got here without it! Not this easily, at any rate!

_aLfa_ · Posted: Sun Sep 05, 2004 1:35 pm Post subject:

I'm more than happy to know that
_________________
One thing only I know, and that is that I know nothing. (Socrates)