How to reverse engineer a Windows 95 target
REVERSE ENGINEERING EXERCISES FOR THE MASSES - (2a)
Version 0.01
by fravia+ (MSRE), August 1997
Part A: Introduction to filemon - 01 August 1997
Courtesy of Fravia's page of reverse engineering
Well, a very interesting essay... I wrote it myself! :-)
This essay will be divided in
four (or more) parts:A = Introduction to filemon
B = reverse engineering without source code
C = Filemon reversed
D = Back to Main
E = VXD vagaries and mysteries
Although already disponible, this essay is still under construction
and will be modified and ameliorated until the wording below will disappear (I reckon
until mid-september)
UNDER CONSTRUCTION
REVERSE ENGINEERING EXERCISES FOR THE MASSES - (2a)
How to reverse engineer a Windows 95 program
~
Part A: Introduction to filemon.exe
(c) Fravia (MSRE), 1997. All rights reserved
Print as html document, else use courier 8
Sorry for the language, I'm not a native English speaker.
Sorry for the "rough" version, it's still under construction... I am publishing this essay in its incomplete form, only because so many have insisted. The complete version will not be ready before mid-September and will contain many changes and improvements .
This essay is a "quick and dirty" introduction to Windows 95 reverse
engineering, it requires almost NO knowledge of windows programming, and a
low to
moderate knowledge of assembler coding. If you are already a good
software reverse engineer this essay may disappoint you, being a little
too much on the elementary side, yet I believe that a good comprehension of the basic of this trade is the main secret for advanced reverse
engineering.
Introduction
You may have already read the short essay (divided in two parts) that
I published one year ago, reverse engineering Filemanager for Windows 3.1. Since we
are all now dealing mostly with Windows 95 programs (it's not our choice
- alas - but a Micro$oft's imposition that everybody accepts, against
any sound logic :-) it suits us well to examine the "deep" structure
of filemon.exe, Version 2.0, by By Mark Russinovich
and Bryce Cogswell, a pretty useful program, released with its c source code at
the beginning of the year. You may want to download also the LAST version of this
good tool (version 3.0), released in July, at http://www.ntinternals.com,
where you'll find also its companion utility regmon.exe and the Windows NT versions
of both tools with complete c++ source code. Yet for this essay download from
my site version 2 of filemon.exe with its source code, this is all what you'll need.
As usual, when you start a cracking session, first of all run the program, try all its options (there are not many options inside this target) and, last
but not least,
print the complete
C source code (15 "A4" sheets).
Since we have already the C source code of this program this lesson
will be a "false" reverse engineering exercise: we are not going to
find anything hidden or new, nor many secret tricks in here... yet I
believe that many of you will find pretty useful our work
below, since analogous structures will more or less be present inside
UNKNOWN code, inside other targets, that you'll try to reverse engineer on your
own.
Another (very) interesting point in this program is its use of a virtual
device driver (VXD) for the filtering of all file system accesses... VXD reverse
engineering is a branch in its own rights, as you will see.
Here you go: all
the files you'll find inside filsrc.zip:Searching ZIP: FILSRC.ZIP
Length Method Size Ratio Date Time CRC-32 Attr Name
------ ------ ----- ----- ---- ---- -------- ---- ----
0 Stored 0 0% 07-03-97 13:16 00000000 --wD GUI/
0 Stored 0 0% 07-03-97 13:16 00000000 --wD VXD/
766 DeflatN 350 55% 28-03-96 08:55 cc319149 --w- GUI/APPICON.ICO
16015 DeflatN 7090 56% 16-03-97 20:47 ce4c6ba6 --w- GUI/FILEVXD.VXD
58368 DeflatN 4905 92% 16-03-97 20:49 75a1fd27 --w- GUI/FILEMON.NCB
0 Stored 0 0% 07-03-97 13:16 00000000 --wD GUI/RELEASE/
38912 DeflatN 1764 96% 16-03-97 20:49 266898dd --w- GUI/FILEMON.MDP
7176 DeflatN 1522 79% 27-11-96 14:34 4ccc82e0 --w- GUI/FILEMON.MAK
4786 DeflatN 1396 71% 16-03-97 20:48 54b79e51 --w- GUI/FILEMON.RC
2312 DeflatN 623 74% 16-03-97 20:13 fea19b03 --w- GUI/RESOURCE.H
22356 DeflatN 6422 72% 16-03-97 20:22 58b0c5ab --w- GUI/FILEMON.C
16015 DeflatN 7090 56% 16-03-97 20:47 ce4c6ba6 --w- GUI/RELEASE/FILEVXD.VXD
38912 DeflatN 18466 53% 16-03-97 20:48 4d4d1cee --w- GUI/RELEASE/FILEMON.EXE
420 DeflatN 255 40% 24-11-96 21:09 bd0b63d3 --w- VXD/MAKEFILE
1199 DeflatN 259 79% 16-03-97 20:47 1c1c6d4c --w- VXD/FILEVXD.DEF
1620 DeflatN 961 41% 16-03-97 20:47 20fd9fad --w- VXD/FILEVXD.SYM
1480 DeflatN 373 75% 16-03-97 20:47 031f6484 --w- VXD/FILEVXD.EXP
16015 DeflatN 7090 56% 16-03-97 20:47 ce4c6ba6 --w- VXD/FILEVXD.VXD
6212 DeflatN 1699 73% 16-03-97 20:47 ce4845f1 --w- VXD/FILEVXD.MAP
15675 DeflatN 6009 62% 16-03-97 20:47 7702cbad --w- VXD/FILEMON.OBJ
1384 DeflatN 364 74% 16-03-97 20:47 1ec43719 --w- VXD/FILEVXD.LIB
313 DeflatN 194 39% 05-12-95 02:01 317f17cc --w- VXD/FILEVXD.VRC
452 DeflatN 283 38% 23-11-96 18:36 0ea560c5 --w- VXD/FILEVXD.RES
82944 DeflatN 5012 94% 16-03-97 20:47 f7db1ed0 --w- VXD/FILEVXD.PDB
84457 DeflatN 12255 86% 24-11-96 04:47 6f9a8ab8 --w- VXD/TEST.FIL
35430 DeflatN 7703 79% 16-03-97 20:45 2fc85672 --w- VXD/FILEMON.C
1139 DeflatN 509 56% 16-03-97 20:24 e642c40b --w- VXD/IOCTLCMD.H
1557 DeflatN 582 63% 16-03-97 20:25 395d7317 --w- VXD/FILEMON.H
------ ------ --- -------
455915 93176 80% 28
We'll reverse engineer two files: filemon.exe and filevxd.vxd. We'll begin with filemon.exe. The reverse engineering of this program will be COMPLETE, since its various parts will be useful -for you- in order to learn some of the different aspects and techniques (and tricks) of our trade. Be patient and wade slowly through the code of this target, I'll keep you on the right path.
'Dead listing' reverse engineering, as +ORC calls it, is a slow "puzzle solving" process: the intellectual challenge can be extremely interesting, btw.
We will NEVER use Winice in this essay, as it is NOT NECESSARY to use our powerful debugger to understand EVERYTHING a target does, as you'll see reading this essay.
Elementary must know, the SaveFile approach
Some elementary MUST KNOW that you should head before starting a cracking session:
At the beginning there are no names... only a sea of numbers, hundred of
different locations... that's your target "in the wild", roaming around with unnamed procedures, before you tame it to clarity.
Soon some little islands will appear... their form still indeterminate... slowly you'll understand what some procedures of your target (should) do... for instance here
in filemon (as in almost all programs you'll disassemble) it's pretty easy to
individuate the "FileSaving" function, using simple search masks inside the
dead listing.
Searching you'll quickly get to this part of your dead listing:
:00401CF3 C744244804824000 mov [esp + 48], 00408204 ;"Save File Info..."
:00401CFB C7442454FC814000 mov [esp + 54], 004081FC ;"*.fil"
Now just dead list "back", to the beginning of this function:
:00401C20 81EC7C060000 sub esp, 0000067C ;correct stack
Since this function starts at :00401C20, we can at once substitute (search and replace) any "call 00401C20"
(which is not a very useful tag for our dead listing perusing) with a much
more meaningful tag: "call
00401C20=savefile".
Note how our substitution did NOT eliminate the location number, you better
keep always such number locations together with your new tags, because during your cracking sessions you will necessarily
commit quite
a lot of mistakes, that you'll correct later. Keeping the original location
numbers together with your new assigned 'provisory' names will help you a lot
when needed.
Inside
filemon's dead listing we will find only two occurrences of a call to our "FileSaving" routine but working
on your own targets, later, you'll soon discover how abstruse (and puzzling)
code
snippets will suddenly be comprehensible thank to these - very simple -
substitutions
Let's have a look at the relevant filemon's code:
This snippet of code calls twice the SaveFile function of our target...
by the way, since this kind of routines are typically called from the main menu
of the main window ("Save" and "Saveas" inside the "File" main menu option), this snippet will be very probably inside
a WM_COMMAND structure... more about this later)... here is the part of code calling
SaveFile::
:00401569 6A00 push 00000000 ;BOOLEAN FALSE
:0040156B A1B8964000 mov eax, [004096B8] ;get second par
:00401570 8BB42458010000 mov esi, [esp + 00000158] ;get HWND hWnd
:00401577 50 push eax ;push second par
:00401578 56 push esi ;push HWND hWnd
:00401579 E8A2060000 call 00401C20=savefile
:0040157E 83C40C add esp, 0000000C
:00401581 E97E010000 jmp 00401704
:00401586 6A01 push 00000001 ;BOOLEAN TRUE
:00401588 A1B8964000 mov eax, [004096B8] ;get second par
:0040158D 8BB42458010000 mov esi, [esp + 00000158] ;get HWND hWnd
:00401594 50 push eax ;push second par
:00401595 56 push esi ;push HWND hWnd
:00401596 E885060000 call 00401C20=savefile
:0040159B 83C40C add esp, 0000000C
:0040159E E961010000 jmp 00401704
You notice that I have already transformed "call 00401C20" in "call 00401C20=savefile".
You may use the same "search and replace" technique also for memory
locations you have understood the significance of. Usually you'll be lucky every
time that a KNOWN return value of a KNOWN windows function will be stored
in a specific memory location. This will allow you to prepare easily an immediate
"search and replace" of the same location in the whole dead listing, whereby you'll
substitute awkward number-locations with your tags, explaining
their exact meaning
Yet you'll be able to clear the meaning of quite a lot of
code even
if you DO NOT KNOW the exact meaning of a value stored inside a memory
location... the important thing is that you know where that value is
used... let's make an example, look at the code above once more.
This small code snippet let us understand
that the "homemade" function SaveFile
of our target accepts THREE parameters (note the three pushes before each
call).
One of the three parameters is, clearly, a boolean parameter, either 0 or 1...
can you guess what this could be... in a "save
file" operation? It's the "saveas" parameter in alternative to "save",
a typical boolean
parameter for saving operations... we don't even need the confirmation
of the c code...
Nice... and the other two parameters? The first one (in the C
call, the last one in assembly) is HWND hWnd, of course, and the other
one, the "middle" one? We know, from the C source, that's HWND ListBox,
but we could ALREADY
have searched and replaced all memory locations "[004096B8]" -
in the whole dead
listing - with something like "[004096B8]=SaveFileSecondPar", and believe
me, this would have made quite a BIG difference in a huge 7-8 megabytes
dead listing where you don't even understand what the hell the programmer
was trying to do, nor where have been hidden, inside the huge codewoods, the
snippets of the target's code you are looking for.
OK, we have finished our quick examination of the small snippet above... would
you like to
know what it was exactly? It correspond to the following 6 lines of "c" code,
placed inside the main "switch" tree (for WM_COMMAND) of the MainWndProc:
case IDM_SAVE:
SaveFile( hWnd, hWndList, FALSE );
return 0;
case IDM_SAVEAS:
SaveFile( hWnd, hWndList, TRUE );
return 0;
Let's start cracking: the first function
Now let's start together anew, take your sheets with the C source code have
a general look, prepare your favourite cocktail (may I suggest a
traitor?) and then jump with me inside the disassembled
target...
If you just read the disassembled code that follows, with my comments, you'll
notice pretty easily how the c source code has been "translated" in assembler.
The first windows' function in the C source code is ABORT, let's examine first of all its "C" code:
/********************************************************************
* FUNCTION: Abort:
* PURPOSE: Handles emergency exit conditions.
*********************************************************************/
void Abort( HWND hWnd, TCHAR * Msg )
{ MessageBox( hWnd, Msg, "filemon", MB_OK );
PostQuitMessage( 1 );
}
Note the 4 parameters of the Messagebox function: from left to right:
hWnd, Msg, "progname", MB_OK... as you'll now see, in assembly they will be pushed in
REVERSE ORDER: MB_OK, "progname", Msg, hWnd,
And here is the code of our target
//********************** Start of Code in Object .text **************
Program Entry Point = 004024E0 (Filemon.exe File Offset:000018E0)
:00401000 8B442408 mov eax, [esp + 08] ;get msg in eax
:00401004 6A00 push 0 ;push right parameter: MB_OK (=0)
:00401006 8B4C2408 mov ecx, [esp + 08] ;get hWnd in ecx
:0040100A 68C0804000 push 004080C0 ;push StringData "filemon"
:0040100F 50 push eax ;push msg
:00401010 51 push ecx ;push hWnd
:00401011 FF1590B24400 Call dword ptr [0044B290] ;call USER32.MessageBoxA
:00401017 6A01 push 1 ;push 1 for PostQuit
:00401019 FF1588B24400 Call dword ptr [0044B288] ;call USER32.PostQuitMessage
:0040101F C3 ret ;finis
What does this little introductory example mean from a reverse engineering point
of view?
It means, for a start, that EVERY TIME you find a "call USER32.MessageBoxA"
function, in
your disassembled listing you may substitute IMMEDIATELY the 4 pushes preceding
it
with:
First push: whatever MessageBoxStyle has been called (Here 0 = MB_0K)... see below
the complete list
Second push: Title of the MsgBox
Third push: Msg
Fourth push: hWnd
You dig it?
It's the same old story we already (should) know from dos reverse
engineering actually:
All it happens when passing parameters to a C++ function is that you push the
rightmost parameter first, then the next rightmost parameter, and so on, until
the leftmost parameter has been pushed. Then the function is called... say you
call the C library function strcpy to copy SourceString to
DestString... in c++ you would type:
strcpy (DestString, SourceString);
The same call in assembler works like this
lea ax,SourceString ;rightmost parameter
lea bx,DestString ;leftmost parameter
push ax ;push rightmost first
push bx ;push next one
call _strcpy ;copy the string using pre-made code
add sp,4 ;DISCARD used parameters
Everything depends from the CALLING CONVENTION!
The C calling convention pushes rightmost first
and discards parameters from stack;
The Pascal calling convention pushes leftmost
first and the called program
discards the parameter from the stack.
It's therefore quite important to understand first of all wich convention uses your
target, which is pretty easy, since you just need to have a look to a known windows
function.
The old good MessageBox function
But we are not yet finished with our messagebox function,, I'll use this very
function in order to explain you "in the deep" a single Windows' function, it's
up to you, obviously, to learn as much as you can about the more important
windows' functions...
I know, I know, it's an awful operating system, yet we MUST STUDY IT, unfortunately,
in order to reverse it whenever we feel like it. In the following example, regarding
MessageBox, you'll find a description useful for reverse engineering purposes,
the descriptions you'll find inside the WinAPI references of the main languages
compilers are similar, but they are aimed at programmers that usually DO NOT
need to know how to disassemble their program effectively and therefore are
not always useful, nor complete. In fact the basical
syntax for messagebox is the following:
int MessageBox(hwndParent, lpszText, lpszTitle, fuStyle)
HWND hwndParent; /* handle of parent window */
LPCSTR lpszText; /* address of text in message box */
LPCSTR lpszTitle; /* address of title of message box */
UINT fuStyle; /* style of message box */
The MessageBox function creates, displays, and operates a message-box window.
The message box contains an application-defined message and title, plus any
combination of the predefined icons and push buttons described in the fuStyle
parameter.
Parameter Description
hwndParent Identifies the parent window of the message box to be created.
If this parameter is NULL, the message box will have no parent
window.
LpszText Points to a null-terminated string containing the message to
be displayed.
LpszTitle Points to a null-terminated string to be used for the dialog
box title. If this parameter is NULL, the default title Error
is used.
fuStyle Specifies the contents and behavior of the dialog box.
This parameter can be a combination of the following values:
Value Meaning
MB_ABORTRETRYIGNORE The message box contains three push buttons:
Abort, Retry, and Ignore.
This value is 0x00000002L
MB_APPLMODAL The user must respond to the message box before
continuing work in the window identified by the
hwndParent parameter. However, the user can move
to the windows of other applications and work in
those windows. MB_APPLMODAL is the default if
neither MB_SYSTEMMODAL nor MB_TASKMODAL is
specified.
This value is 0x00000000L
MB_DEFBUTTON1 The first button is the default. Note that the
first button is always the default unless MB_DEFBUTTON2
or MB_DEFBUTTON3 is specified.
This value is 0x00000000L
MB_DEFBUTTON2 The second button is the default.
This value is 0x00000100L
MB_DEFBUTTON3 The third button is the default.
This value is 0x00000200L
MB_ICONASTERISK Same as MB_ICONINFORMATION.
This value is 0x00000040L
MB_ICONEXCLAMATION An exclamation-point icon appears in the message box.
This value is 0x00000030L
MB_ICONHAND Same as MB_ICONSTOP.
This value is 0x00000010L
MB_ICONINFORMATION An icon consisting of a lowercase letter "I" in a
circle appears in the message box.
This value is 0x00000040L
MB_ICONQUESTION A question-mark icon appears in the message box.
This value is 0x00000020L
MB_ICONSTOP A stop-sign icon appears in the message box.
This value is 0x00000010L
MB_OK The message box contains one push button: OK.
This value is 0x00000000L
MB_OKCANCEL The message box contains two push buttons: OK and Cancel.
This value is 0x00000001L
MB_RETRYCANCEL The message box contains two push buttons: Retry and Cancel.
This value is 0x00000005L
MB_SYSTEMMODAL All applications are suspended until the user responds to
the message box. Unless the application specifies MB_ICONHAND,
the message box does not become modal until after it is
created; consequently, the parent window and other windows
continue to receive messages resulting from its activation.
System-modal message boxes are used to notify the user of
serious, potentially damaging errors that require immediate
attention (for example, running out of memory).
This value is 0x00001000L
MB_TASKMODAL Same as MB_APPLMODAL except that all the top-level windows
belonging to the current task are disabled if the hwndParent
parameter is NULL. This flag should be used when the calling
application or library does not have a window handle available
but still needs to prevent input to other windows in the
current application without suspending other applications.
This value is 0x00002000L
MB_YESNO The message box contains two push buttons: Yes and No.
This value is 0x00000004L
MB_YESNOCANCEL The message box contains three push buttons: Yes, No, and
Cancel.
This value is 0x00000003L
As you can see, the possible values are 0,1,2,3,4,5,10,20,30,40,100,200,100, 2000
(there are also other values, more rare: F, FO, F00, 3000, 8000, C000, 20000... you'll
find them out either experimenting a little or reverse engineering a lot :-)
Returns
The return value is zero if there is not enough memory to create the message box.
Otherwise, it is one of the following menu-item values returned by the dialog box:
Value Real value Meaning
ERROR (0) fcked
IDOK (1) OK button was selected.
IDCANCEL (2) Cancel button was selected.
IDABORT (3) Abort button was selected.
IDRETRY (4) Retry button was selected.
IDIGNORE (5) Ignore button was selected.
IDYES (6) Yes button was selected.
IDNO (7) No button was selected.
If a message box has a Cancel button, the IDCANCEL value will be returned
if either the ESC key is pressed or the Cancel button is selected. If the
message box has no Cancel button, pressing ESC has no effect.
Comments
When a system-modal message box is created to indicate that the system is
low on memory, the strings pointed to by the lpszText and lpszTitle
parameters should not be taken from a resource file, because an attempt
to load the resource may fail.
When an application calls the MessageBox function and specifies the
MB_ICONHAND and MB_SYSTEMMODAL flags for the fuStyle parameter, Windows
displays the resulting message box regardless of available memory.
When these flags are specified, Windows limits the length of the
message-box text to three lines. Windows does not automatically break
the lines to fit in the message box, however, so the message string
must contain carriage returns to break the lines at the appropriate
places.
If a message box is created while a dialog box is present, use the
handle of the dialog box as the hwndParent parameter. The hwndParent
parameter should not identify a child window, such as a control in
a dialog box.
See Also
FlashWindow, MessageBeep
OK, we have seen "in the deep" a single Windows' function, you would be well
advised to prepare yourself some "information sheets", like the above one, for your
own use, about the most important and more frequent windows functions, WITH the
values of the constants that windows uses... you'll see how easy it is to
understand what an unknown part of a program is doing just examining how it handles
the DIFFERENT possible return values...
This is obviously not the case here...
remember what we are doing, we are just examining an "ABORT" error function, an
anormal function that will show the user only a short error message and offer him
the OK button to click onto... you could modify the code at
:00401004 6A00 push 0 ;push right parameter: MB_OK (=0)
into::00401004 6A01 push 1 ;push right parameter: MB_OKCANCEL (=1)
Yet modifying this code would not make much sense: you would see two push buttons: OK and Cancel, only in the event of an error (a
pretty futile reverse engineering exercise :-)
The InitApplication function of filemon
Now that we have seen the ABORT function of filemon, let's work on the next
routines of our target... be patient and follow me: if you read carefully
this short essay you'll master the rudiments of windows reverse engineering.
The following function, inside our C source code, is WinMain... since WinMAin is a KNOWN function (which usually calls InitInstance and InitApp before entering a ghetmaessage loop), WinMain will be one of the LAST code snippets that
we'll reverse, we'll see first a lot of other, more or less "home-made" procedures that we'll "solve" first (once more: we have the c
source code of this target, yet my aim is to teach you how to reverse engineer targets you
DO NOT have the source code of, we'll soon operate AS IF we did not have any source code at all, bear with me :-)
We'll pass to the next procedure, the one after Winmain. This is a standard InitApp procedure (as you'll see in the FOURTH) part of this lesson) here is its C source code:
/****************************************************************************
* FUNCTION: InitApplication(HANDLE)
* PURPOSE: Initializes window data and registers window class
****************************************************************************/
BOOL InitApplication( HANDLE hInstance )
{ WNDCLASS wc;
// Fill in window class structure with parameters that describe the
// main (statistics) window.
wc.style = 0;
wc.lpfnWndProc = (WNDPROC)MainWndProc; !!!!
wc.cbClsExtra = 0;
wc.cbWndExtra = 0;
wc.hInstance = hInstance;
wc.hIcon = LoadIcon( hInstance, "ICON" );
wc.hCursor = LoadCursor( NULL, IDC_ARROW );
wc.hbrBackground = GetStockObject( LTGRAY_BRUSH );
wc.lpszMenuName = "LISTMENU";
wc.lpszClassName = "filemonClass";
if ( ! RegisterClass( &wc ) )
return FALSE;
return TRUE;
}
FUNCTION: InitApplication(HANDLE)
* Referenced by a CALL at Address:0040102B
BOOL InitApplication( HANDLE hInstance)
This function fills in the window class structure with parameters that describe the
main (statistics) window of our target... it's one of the main "initializing" functions of our target
:004010B0 8B442404 mov eax, [esp + 04] ;get hInstance
:004010B4 83EC28 sub esp, 00000028
:004010B7 C744240000000000 mov [esp], 00000000
:004010BF 89442410 mov [esp + 10], eax
:004010C3 56 push esi ;save esi
:004010C4 C744240890114000 mov [esp + 08], 00401190 ;See below what is this
:004010CC C744240C00000000 mov [esp + 0C], 00000000
:004010D4 C744241000000000 mov [esp + 10], 00000000
:004010DC 68E4804000 push 004080E4 ;StringData "ICON"
:004010E1 50 push eax ;push hInstance
:004010E2 FF15F4B24400 Call dword ptr [0044B2F4] ;USER32.LoadIconA
:004010E8 89442418 mov [esp + 18], eax ;save return value
:004010EC 68007F0000 push 00007F00 ;7F=IDC_ARROW
:004010F1 6A00 push 00000000 ;NULL
:004010F3 FF15F8B24400 Call dword ptr [0044B2F8] ;USER32.LoadCursorA
:004010F9 8944241C mov [esp + 1C], eax ;save return value
:004010FD 6A01 push 1 ;1=LTGRAY_BRUSH
:004010FF FF15CCB14400 Call dword ptr [0044B1CC] ;GDI32.GetStockObject
:00401105 C7442424D8804000 mov [esp + 24], 004080D8 ;StringData "LISTMENU"
:0040110D C7442428C8804000 mov [esp + 28], 004080C8 ;StringData "filemonClass"
:00401115 89442420 mov [esp + 20], eax ;save return in esp+20
:00401119 8D442404 lea eax, [esp + 04] ;get WNDCLASS wc
if ( ! RegisterClass( &wc ) )
return FALSE;
return TRUE
:0040111D 50 push eax ;push WNDCLASS wc
:0040111E FF15FCB24400 Call dword ptr [0044B2FC] ;USER32.RegisterClassA
:00401124 663D0100 cmp ax, 0001 ;did we get it through?
:00401128 5E pop esi
:00401129 1BC0 sbb eax, eax ;if zero return false
:0040112B 83C428 add esp, 00000028
:0040112E 40 inc eax ;else return true
:0040112F C3 ret
Well, let's see what happens when we get back from this procedure:
:WinMain of filemon calls InitApplication
:00401020 83EC1C sub esp, 0000001C
:00401023 53 push ebx
:00401024 56 push esi
:00401025 8B742428 mov esi, [esp + 28]
:00401029 57 push edi
:0040102A 56 push esi
:0040102B E880000000 call 004010B0 ;call InitApplication(HANDLE)
:00401030 83C404 add esp, 4 ;correct esp
:00401033 85C0 test eax, eax ;was it zero?
:00401035 750B jne 00401042 ; if InitApplication(hInstance) OK
; continue WinMain
:00401037 33C0 xor eax, eax ;else return FALSE
:00401039 5F pop edi
:0040103A 5E pop esi
:0040103B 5B pop ebx
:0040103C 83C41C add esp, 1C
:0040103F C21000 ret 10
Therefore the above snippet is:
if (! InitApplication(hInstance))
return FALSE;
Which is a part of WinMain, btw.
The trick for finding MainWndProc
God, I realize now that I should begin to explain the whole WNDCLASS structure...
please
study it yourself... if you bought (as you should have done) the COMPLETE Borland
C++ Version
4.52 for less than 4 UK pounds (see here), you'll have
all
important specs at your fingertips from the huge API helpfiles (7 million bytes
for Win32 and 3 million
bytes for Win31).
I'll explain here only part of the API calls... The most
important element here, for us, is that WNDCLASS' member lpfnWndProc
POINTS TO THE CALLBACK WINDOW PROCEDURE!
Let's approach the above code (of InitApplication) slowly... What was the value "401190" at 10C4?
:004010C4 C744240890114000 mov [esp + 08], 00401190
That is the location of the MainWndProc!
Windows is so kind to tell us, in
many
occasions, WHERE the "obligatory" functions of an unknown program start!
If
Peter
Urbanik, the author of Wdasm, would listen to us, instead of uselessly updating
his program every
couple of weeks, he would work on this to get a spectacular tool for reverse
engineering!
OK, every single WNDCLASS call of a windows program carries
inside itself
the location of the caller... in this case (as in most initialization parts of code)
WNDCLASS is called at initialization by a little initialization routine (here in
filemon called InitInstance) which is in turn called by the main "homemade"
procedure of our target, here in filemon called MainWndProc... nice to know,
isn't it?
There is more: since WNDCLASS has a parameter lpszClassName, which
points to a null-terminated string that specifies the name of the window class
(in the case of filemon
"filemonClass"), it's pretty easy to find all occurrences of WNDCLASS inside any
unknown target just examining its strings (and you can use good old Frattaroli's strings.zipto do it) ... nice isn't it?
What have we more up there? Let's see
:004010EC 68007F0000 push 00007F00 ;IDC_ARROW
hCursor Identifies the class cursor. This member must be a handle to a cursor
resource. There are many resources of each type, for the joy of a good reverse
engineer...
Here you go! experiment a little (change it with Hexworkshop inside filemon.exe, play
with your targets! In this specific case you wont see much, though, because this
is the "ghost" "loaded" cursor of filemon... you should change the SetCursor
function's parameter to change the cursor of an application)
32512 (0x7F00) = IDC_ARROW ;that's what we have
32513 (0x7F01) = IDC_IBEAM ;Text I-beam cursor.
32514 (0x7F02) = IDC_WAIT ;that's the hourglass
...
32560 = IDC_APPSTARTING
Another parameter:
:004010FD 6A01 push 00000001 ;LTGRAY_BRUSH
Since GRAY BRUSH is 2 and DARKGRAY BRUSH is 3, you may experiment as well with
some colors... If you substitute :004010FD 6A01 with :004010FD 6A03 you'll indeed
see (for a moment) your DKGRAY_BRUSH "behind" the filling of the main window of
filemon, once more this is the "initializing" routine, which is called at the
beginning of our target's life, many parameter will be "reconfirmed" later on.
What's more up there? Yes: RegisterWindowClass... once created, the WNDCLASS data
must be "registered" in order to pass to the subsequent CreateWindow function...
Let's have a look at the code of WinMain that will be performed if the InitApplication
routine returns successful...
:WinMain after InitApplication
:00401042 8B442438 mov eax, [esp + 38]
:00401046 50 push eax
:00401047 56 push esi
:00401048 E8E3000000 call 00401130=InitInstance
:0040104D 83C408 add esp, 00000008
:00401050 85C0 test eax, eax
:00401052 750B jne 0040105F ;if InitInstance successful
;continue WinMain
:00401054 33C0 xor eax, eax ;else return FALSE
:00401056 5F pop edi
:00401057 5E pop esi
:00401058 5B pop ebx
:00401059 83C41C add esp, 0000001C
:0040105C C21000 ret 0010
A Windows is born
This huge operating system
will now perform its most characteristic work: create a Window. Prepare yourself
another
cocktail, this will take quite a while...
/****************************************************************************
* FUNCTION: InitInstance(HANDLE, int)
* PURPOSE: Saves instance handle and creates main window
****************************************************************************/
HWND InitInstance( HANDLE hInstance, int nCmdShow )
{ HWND hWndMain;
hInst = hInstance;
hWndMain = CreateWindow(
"filemonClass", "Win95 File Monitor", WS_OVERLAPPEDWINDOW,
CW_USEDEFAULT, CW_USEDEFAULT, CW_USEDEFAULT, CW_USEDEFAULT,
NULL, NULL, hInstance, NULL );
// if window could not be created, return "failure"
if (! hWndMain)
return NULL;
// make the window visible; update its client area; and return "success"
ShowWindow(hWndMain, nCmdShow);
UpdateWindow(hWndMain);
return hWndMain;
}
This HWND "hWndMain" translates to: CreateWindow (...)
:00401130 8B442404 mov eax, [esp + 04] ;get hInstance
:00401134 56 push esi ;save esi
:00401135 6A00 push 00000000 ;last NULL lpvparameter
:00401137 A3E8994000 mov [004099E8], eax ;save hInstance (HEY! A memory loc!)
:0040113C 50 push eax ;push hInstance
:0040113D 6A00 push 00000000 ; NULL hmenu
:0040113F 6A00 push 00000000 ; NULL hwndparent
:00401141 6800000080 push 80000000 ; CW_USEDEFAULT
:00401146 6800000080 push 80000000 ; CW_USEDEFAULT
:0040114B 6800000080 push 80000000 ; CW_USEDEFAULT
:00401150 6800000080 push 80000000 ; CW_USEDEFAULT
:00401155 680000CF00 push 00CF0000 ; WS_OVERLAPPEDWINDOW
:0040115A 68EC804000 push 004080EC ; "Win95 File Monitor"
:0040115F 68C8804000 push 004080C8 ; "filemonClass"
:00401164 6A00 push 00000000
:00401166 FF15E8B24400 Call dword ptr [0044B2E8]; USER32.CreateWindowExA, Ord:55h
:0040116C 8BF0 mov esi, eax ;get the handle to the new window in esi
:0040116E 85F6 test esi, esi ;test it
:00401170 7504 jne 00401176 ;if created OK, continue to showwindow
:00401172 33C0 xor eax, eax ;else return NULL (i.e. FALSE)
:00401174 5E pop esi
:00401175 C3 ret
Ok, let's have a look at this important function:
HWND CreateWindow(lpszClassName, lpszWindowName, dwStyle, x, y, nWidth, nHeight,
hwndParent, hmenu, hinst, lpvParam)
LPCSTR lpszClassName; /* address of registered class name */
LPCSTR lpszWindowName; /* address of window text */
DWORD dwStyle; /* window style */
int x; /* horizontal position of window */
int y; /* vertical position of window */
int nWidth; /* window width */
int nHeight; /* window height */
HWND hwndParent; /* handle of parent window */
HMENU hmenu; /* handle of menu or child-window identifier */
HINSTANCE hinst; /* handle of application instance */
void FAR* lpvParam; /* address of window-creation data */
lpszClassName is "filemonClass" (what we have registered)
lpszWindowName is "Win95 File Monitor" (what you see in the main window of
filemon)
dwStyle is WS_OVERLAPPEDWINDOW = 00CF0000 (which creates an overlapped
window having the WS_OVERLAPPED, WS_CAPTION, WS_SYSMENU,
WS_THICKFRAME, WS_MINIMIZEBOX, and WS_MAXIMIZEBOX styles)
int x is CW_USEDEFAULT
This value specifies the initial x-position of the window. For an overlapped or pop-up
window, the x parameter is the initial x-coordinate of the window's upper-left corner,
in screen coordinates. For a child window, x is the x-coordinate of the upper-left
corner of the window in the client area of its parent window. If, like here in filemon,
this value is CW_USEDEFAULT, Windows selects the default position for the window's
upper-left corner and ignores the y parameter. CW_USEDEFAULT is valid only for
overlapped windows... if you firmly believe that Mark Russinovich and Bryce
Cogswell should have let their program appear in the top left corner of the
screen instead of using the default position then go ahead! Modify whatever
you want!Int y is CW_USEDEFAULT, as above for the y-position
nWidth is CW_USEDEFAULT
This value specifies the width, in device units, of the window. For overlapped windows,
the nWidth parameter is either the window's width (in screen coordinates) or
CW_USEDEFAULT. If nWidth is CW_USEDEFAULT, like here in filemon, Windows selects
a default width and height for the window (the default width extends from the
initial x-position to the right edge of the screen, and the default height extends
from the initial y-position to the top of the icon area). CW_USEDEFAULT is valid only
for overlapped windows.nHeight is CW_USEDEFAULT, as above for the
height
hwndParent is NULL. This value identifies the parent or owner window of the
window being created. Overlapped windows must NOT have a parent
(hParent must be NULL)
hMenu is NULL, handle of menu identifier
hInstance is the value in eax, and identifies the instance of the module to
be associated with the window.
LpvParam is the WM_CREATE param
Well, what returns CreateWindow? The return value is the handle of the new window if
the function is successful. Otherwise, it is NULL. Everything is OK with old good
filemon, let's continue...
A window has been "made" it's name is hWndMain let's show it to the world
:ShowWindow(hWndMain, nCmdShow); make the window visible & update its client area
:00401176 8B44240C mov eax, [esp + 0C] ;get nCmdShow
:0040117A 50 push eax ; nCmdShow
:0040117B 56 push esi ; hWndMain (handle was in esi)
:0040117C FF15ECB24400 Call dword ptr [0044B2EC] ;USER32.ShowWindow, Ord:022Ch
UpdateWindow(hWndMain);
:00401182 56 push esi ; hWndMain (handle was in esi)
:00401183 FF15F0B24400 Call dword ptr [0044B2F0] ;USER32.UpdateWindow, Ord:024Fh
:00401189 8BC6 mov eax, esi ;return to WinMain with hWndMain in eax
:0040118B 5E pop esi ;let's have the old esi back
:0040118C C3 ret
If you never programmed before, you could legitimately ask yourself why the hell we
have to show and update a window we have created a minute ago... see: ShowWindow
specifies how the window is to be shown... hide=0, normal=1, otherzoom=2,
maximize=3, otherunzoom=4, show=5 etc... therefore the value in esp+0C determines HOW
the windows will appear, and it has been already determined calling WinMain, which
has following parameters: int APIENTRY WinMain(HINSTANCE hInstance, HINSTANCE
hPrevInstance, LPSTR lpCmdLine, int nCmdShow), the last "int" one being the
nCmdShow... have a look in the code following the program entry point for this.
Once show, the window must be updated. The UpdateWindow function updates the client
area of our window by sending a WM_PAINT message to the window if the update region
for the window is not empty. The function sends a WM_PAINT message directly to the
window procedure, bypassing the application queue. If the update region is empty,
no message is sent.
We are now finished with the InitInstance procedure, have our nice main window,
must move on: back to WinMain!
:WinMain continued
:0040105F 8D44240C lea eax, [esp + 0C] ;
:00401063 6A00 push 00000000
:00401065 6A00 push 00000000
:00401067 8B3500B34400 mov esi, [0044B300]
:0040106D 6A00 push 00000000
:0040106F 50 push eax
:00401070 FFD6 call esi
:00401072 85C0 test eax, eax
:00401074 742B je 004010A1
:00401076 8B3D94B24400 mov edi, [0044B294]
:0040107C 8B1D8CB24400 mov ebx, [0044B28C]
Well, we'll continue with another lesson, we have almost 50.000 bytes here!
(c) fravia+ 1997. All rights reserved.
You are deep inside fravia's page of reverse engineering,
choose your way out:
filemon2
filemon3
filemon4
filemon5
homepage
links
anonymity
+ORC
students' essays
tools cocktails
antismut
search_forms
mailFraVia
is reverse engineering legal?