MemMonitor95 Standard 4.0 and its ThunkConnect32 relations
(Half-crippled program / Unhiding an hidden window / Thunk vagaries)

by FootSteps

(24 November 1997, slightly edited by fravia+)
Courtesy of fravia's page of reverse engineering
Well, thunking (thunking up, thunking down, thunkconnect...) was about time to have a look at these thunks, don't you believe? Besides there is some 'intuition and luck' in this essay and, moreover, I like quite a lot little jewels like the following one:
bpx CreateWindowExA do "dd *((ss:esp)+8)

     With that, each CreateWindowExA hooked by Winnie will show us the second

     parameter we need : lpClassName in the data window.
This kind of info is, IMHO, what makes an essay valuable for us: the targets are completely irrelevant... but the knowledge... Ahh, the knowledge... I could carry on drinking more and more of it, sitting here and awaiting a slow dawn that still hides inside the heavy clouds of november...


MemMonitor95 Standard Edition 4.0  and its ThunkConnect32 relations 

Half-crippled program / Hidden window / Thunked.

================================================



You'll need :



MemMonitor 95 Standard Trial 4.0 from Prudens http://www.spywindows.com/

MemMonitor 95 Professional Trial from Prudens ibidem

Winnie 3.01 to 3.22 (everywhere on the web)

BRW 4.5 to 5.2      (everywhere on the web)

Winsight 5.x        (everywhere with BC++5)

WDasm32 8.x         (everywhere on the web, use 8.9)

IDA 3.7             (everywhere on the web, don't miss it)

Windoze95           (everywhere on your HD)



Once upon a time I was cracking some interesting tools of the trade, the 

Prudens's trial toolz, (see below for a quick easy reversing snippet about 

ExeSpy95 and ComSpy95), when I found in the third one, MemMonitor95, 

a different protection scheme from the two others.

I thought at first: "oh, no... back to trace", but I was happy: it was 

a good thing: I was beginning to bore myself without challenges.



Running the program, memmon95.exe, I was awaiting like with Exespy95 or

ComSpy95 a "sympathic" nag with something like 'Enter the drive where 

your registration key file is' (with these kind of nags sharewares you 

know immediately that the target is reversed! :-) but... here there was 

no sympathic nag.

Instead, a enormous bitmapped screen nag, with a irritating 'unregistered

user', and a very frustrating 'Not all hooks are available in this version'. 

Followed by a classic MessageBox with program presentation and bazaar.



In spite of my irritation, I played a little with memmon95.exe, you know 

we must always spy all the hints of the targets: where are placed on screen 

words like  'unregistered', when the NagMessageBoxes happen, what functions 

are disabled, etc...

This memmon95.exe is a nice tool, a little better than TechFacts to follow 

memory heap calls, because it show you these in real time (with TechFacts you 

must refresh).



I did not have to wait long in order to have my awaited nagscreen: I clicked 

on a Heap captured valor, and bingo! a nag with 

'This function is restricted to... etc, etc...'

I just thought: ha ha ha!, Gotcha! I will fire Winnie, put a classic

bpx MessageBoxA, press some F12 key, and land in a JZ opcode.



Yes, you can try. Fire Winnie. Bpx MessageBoxA. Click on the ListBox 

which makes the nag appear. 

You land obviously in User32!MessageboxA section.

But Press F12. Just once, go ahead.

You see where you land?

Yes, you land in the terrible Kernel32!ThunkConnect32!

Like quicksand! Aaargh!

You can continue to press the F12 key. But you will sink more and more!

Press it 12 times, and you'll land inside... nothing! The darkest codewoods!

Because we have lost hand of Winnie's trace and we sprang back to Windows' 

normal execution...



Well, I jumped on the Win32 SDK. 

What the hell is this ThunkConnect32 API anyway? 

You won't find it in the SDK. You'll find it in the help files:

Windows's developer guide (Borland C++) or in the Microsoft Programmer's

guide to Windows 95 (Borland C++ Builder, M$VC++, and others compilers...).

If you want more information, you've only got a ridiculous article on it 

in the M$ Knowledge Base, and a serious one inside the 'guru' Schulmann's 

book 'Unauthorized Windoze95'. My! You would never believe HOW MUCH 

undocumented is this whole windoze bazaar!



It was the first time I met this API following our paths. 

In fact 'Thunking' is the relation between 32bits and 16bits applications, 

either executables or DLL.

And WindoZ95 makes indeed an overbloated use of that, especially with the 

User32 to the old User interface... You know, W95 swap all time from 32 

to 16bits, from 16bits to 32... Seems sometimes that Windows95 is in fact 

the worse monstrous shareware ever programmed... :-)



So, why could we not get the hand back to Winnie, after this thunk? Who knows?

First, probably because of the MeMonitor95 hooks. You see, MemMonitor hooks

when running some 16/32bits API like GlobalAlloc and GlobalRealloc for example,

ensuring to catch some old WindoZ31 applications, then calls ThunkConnect to

switch from 32bits OS to 16bits.

Second, probably too, because after the nagscreen, and after the ThunkConnect32

Kernel section, the system goes back in the WndProc of the program, more

exactly inside the switch(message) loop. 

Then, we intercept one, which displayed the nag, and the program is now waiting 

some other ones (for example, when you click on some functions of the program). 

Like it is waiting, and not running.

Winnie sleeps. Try, after landing in Kernel!ThunkConnect32, to press F12 a

little times: you will not land inside User32... you'll dwell inside the 'old' 

16bits User!WaitMessage boring loops.



Since I couldn't trace anymore, I disassembled memmon95.exe with W32Dasm.

Well, I found quickly the right MessageBoxA references looking for

'this function is restricted...'. 

Yes, actually several references.

And looking closer to the dead-listing, it seems that that nag happens when

you click on some interesting function : A nag when you want to print, a nag 

when you want to heap process click, a nag when you want to save...

When you want to save? Hey, that isn't at all inside the buttons of 

the trial version!

It was time for a deeper examination of this thunked executable with BRW.



I fired therefore the heavy artillery: Borland Resource Workshop. 

More exactly, with version 5, run your compiler and open memmon95.exe using 

edit resources as a viewer.

And a lot of interesting things should appear in front of your child'eyes:

The enormous bitmap which serves as nag intro.

A registration window.

A registration window?? Well, then...

But wait... you better wait before crying victory. 

Something was terribly wrong.

Yes, I know something was wrong because I already spyed the OTHER 

executable (cracked below), ExeSpy95. 

And ExeSpy95 got TWO NagBitmapScreens.

And the file we study, memmon95.exe, has only ONE NagBitmapScreen. 

A big one with  the sad message 'No hooks are available' printed on it.

ExeSpy95 had the same, AND another one, without any inscriptions, the 

good one, the one we want: the registered one.

Perhaps memmon95 could then paint over these words with a FillRect() or 

some other graphic tricks in order to cover the bitmap when registered? 

No, Let's not be ridiculous... :-)



At this point, I had big doubts about cracking this target. 

Seems that it was a "really crippled" trial version... and that 

there were nothing to do.

But I continued a little. You know, for the fun, never give up!

And I fired Winsight, the window spy utility of the Borland C++.

And looked closer, once more, to my "MEMMON95" DialogBox.

Mmm, I verified all of my target, all the buttons, the ListBoxes, the

EditBoxes...

Suddenly, I jumped! 

In the Winsight detail, a second main window "MEMMON95" appeared!

Open it : you can remark all other child windows: a StatusBar one, a TBar one,

a Client one...

But all have the "hidden" attribute. This is why we just see the DialogBox.

I got an idea and looked at the readme.1st file that come with this appz 

(This is what I should have done from the beginning...)

There are two version of MemMonitor : the standard (we're studying)

and the Professional. I read :



STANDARD vs PROFESSIONAL (for Windows 95)

=========================================

The Professional Edition provides some advanced features:

  1. a view/log window is provided that displays captured calls

     - you can print the log

     - you can save the log to a file

  2. a setting window is provided that you can disable those APIs you are not

     interested



Well, the Pro version provides a view/log window? 

And what about the hidden window which lurk when we run the standard 

MemMonitor?

I then immediately wanted to un-hide this window. 

But it is not possible to change attributes when an application is 

running.

By the way, (
(c) FootSteps All rights reversed
You are deep inside fravia's page of reverse engineering, choose your way out:

redhomepage redlinks redanonymity +ORC redstudents' essays redacademy database
redtools redcocktails redantismut CGI-scripts redsearch_forms redmail_fravia
redIs reverse engineering legal?