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
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
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 :

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

Well, the Pro version provides a view/log window? 
And what about the hidden window which lurk when we run the standard 
I then immediately wanted to un-hide this window. 
But it is not possible to change attributes when an application is 
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?