Hey Guys, me again ...

Since I've had some spare time I've been trying to understand about memory mapped files, because I want to find out the entry point of executables. To do so I want to extract the Info from the IMAGE_OPTIONAL_HEADER ...

My problem is that I am fairly unexperienced and can't really check if what I did does the job right. I added a MsgBox to output the result, but its not quiet what i expected or what I can compare to the output of LordPE


my code :

.386
.model flat, stdcall
option casemap: none

include \masm32\include\windows.inc
include \masm32\include\user32.inc
include \masm32\include\kernel32.inc
include \masm32\include\masm32.inc
includelib \masm32\lib\user32.lib
includelib \masm32\lib\kernel32.lib
includelib \masm32\lib\masm32.lib

inv equ invoke
.data

dateiname db "hallo.exe" ,0
FHandle DWORD 0
FSize DWORD 0
ofstruct OFSTRUCT <>
MapObjectHandle DWORD 0
MappedFile DWORD 0
caption db "Address of EP : ",0
result DWORD ?
.code

start:
    inv OpenFile, addr dateiname, addr ofstruct, OF_READWRITE
    mov FHandle, eax
    inv GetFileSize, FHandle, NULL
    mov FSize, eax
    inv CreateFileMapping , FHandle, NULL, PAGE_READWRITE, 0, 0, NULL
    mov MapObjectHandle, eax
    inv MapViewOfFile, MapObjectHandle, FILE_MAP_ALL_ACCESS, 0, 0, FSize
    mov MappedFile, eax
    assume fs : nothing
    mov edi, MappedFile
    assume edi:ptr IMAGE_OPTIONAL_HEADER
    push eax
    xor eax, eax
    mov eax, .AddressOfEntryPoint
    add result, eax
    inv htodw, addr result
    mov result, eax
    pop eax
    inv MessageBox, NULL, addr result, addr caption , MB_OK

ende:
    inv UnmapViewOfFile, MapObjectHandle
    inv CloseHandle , FHandle
    inv ExitProcess , NULL
   
end start


According to LordPE the entrypoint is at 1048, whereas my program only outputs a square :(
As you can see, I used the masm32 function htodw because I hoped it would make the output easier to read
Without it, I just see a comma :(

So my question is, did I get the right data about the entrypoint and just made a mistake in displaying it, or is my whole  code useless ?

Thx in advance for helping me out !
Attachments:
Posted on 2007-03-17 17:19:34 by mindmanipulation
You are forgetting to step over the MZ header to the PE header.

change...
assume fs : nothing
mov edi, MappedFile
assume edi:ptr IMAGE_OPTIONAL_HEADER


to...
assume fs : nothing
mov edi, MappedFile
add edi, ; step over MZ header to the PE header.
assume edi:ptr IMAGE_OPTIONAL_HEADER


Also to fix the box problem. First, why are you using add result, eax when it should probably be mov result, eax (being as 'result' is a random uninitialized value). Second, htodw converts a string to a dword, you need to convert a dword into a string. The dwtoah function can do this for you, we use the dwtoah version because we are displaying addresses and addresses are generally represented in hex format. To obtain a decimal representation we could have used dwtoa.

buffer db 15 dup(0) ; must be at least 10 bytes long
...
inv dwtoah, result, addr buffer
inv MessageBox, NULL, addr buffer, addr caption, MB_OK


So my question is, did I get the right data about the entrypoint and just made a mistake in displaying it, or is my whole  code useless ?


You had the right basic idea, you just need to read up a little more on the format of executables. Other than that you just made a few minor mistakes.

Regards,
Bryant Keller
Posted on 2007-03-17 19:07:27 by Synfire
Hi there !

I was just about to submit another question , but on my last try it finally worked :D
Thank you very much for clarifying some stuff !
I can even correct you : add edi,   only points to e_lfanew , maybe you mixed that up though  :P
I'm using the function dw2hex to convert data types now

But I have an additional question HEHE :



    mov edi, MappedFile
    assume edi: ptr IMAGE_DOS_HEADER
    mov eax, .e_lfanew
    mov lfanew, eax
    ;inv dw2hex, lfanew, addr buffer2 ; <------- convert lfanew into a hex value
    add edi, lfanew    ;skip over dos header
    add edi, 24        ; skip over file header
    ;inv MessageBox, NULL, addr lfanew, addr caption, MB_OK ; <------- 1st msgbox
    assume edi: ptr IMAGE_OPTIONAL_HEADER
    mov eax, .AddressOfEntryPoint
    mov result, eax
    inv dw2hex, result, addr buffer
    inv MessageBox, NULL, addr buffer, addr caption, MB_OK ; <------- 2nd msgbox


This is how my new (working) code looks like.
If i uncomment those 2 lines of code marked with the arrow, the program crashes after the first MsgBox and I cant really explain to myself why...
WHY OH WHY ?

Posted on 2007-03-17 21:51:34 by mindmanipulation
This is a very good example case for logical debugging.
We can see that the EDI register is being referenced, both before and after the 'suspicious calls' to the dw2hex function.
Without those calls, the code works.
With them, it fails.

The obvious conclusion that we can deduce from this scenario?
EDI is legal before a call to dw2hex, and contains JUNK afterwards... it appears that function is TRASHING the EDI register.
We can verify this quite quickly, and find a suitable solution.

You'll notice that some of us seem to draw terms from a magical private lexicon, such as TRASH, KLUDGE, CLOBBER and so forth.
I don't think terminology is as important as the concepts that they convey, and so I accept this unofficial jargon as legal terminology.
Posted on 2007-03-18 00:13:23 by Homer

I can even correct you : add edi,   only points to e_lfanew

What it does is replace this code

    mov eax, .e_lfanew
    mov lfanew, eax
    add edi, lfanew

Think of it as

    add edi,.e_lfanew



;inv MessageBox, NULL, addr lfanew, addr caption, MB_OK ; <------- 1st msgbox

Maybe "addr lfanew" is stuffing things up...it should be the address of a string


EDI is legal before a call to dw2hex, and contains JUNK afterwards... it appears that function is TRASHING the EDI register.

Looking at the MASM32 library, it only uses ESI.
Posted on 2007-03-18 00:52:24 by sinsi
Be careful when using the m32lib, and check out the routines yourself. dw2hex is old junky code (and amazing that hutch still hasn't removed it from m32lib, I asked him to purge anything I had contributed) - it doesn't clobber registers it shouldn't, though.

sinsi is right in that you want to output "addr buffer" in your messagebox, not lfanew.
Posted on 2007-03-18 11:07:21 by f0dder