Hello,

I am working out the first example of iczelion's tutorials.
I put Exitprocess,0 in the source,
when i disassemble it using wdasm, i get this output :

:00401000 6A00 push 00000000
:00401002 E801000000 call 00401008
:00401007 CC int 03
:00401008 FF2500204000 jmp dword ptr [00402000]

I expected exitprocess in de source instead of jmp dword ptr[00402000]

can sombody explain what the compiler did to Exitprocess?

thanks
Posted on 2002-02-27 08:19:25 by Jurgen
never mind, i found it

It's a jump to an attached DLL to notify that the process is being ended.
Posted on 2002-02-27 08:41:30 by Jurgen
another question about exitprocess :

Is de code converted into a jump because kernel32.dll is always loaded ?
Posted on 2002-02-27 08:48:34 by Jurgen
the linker will look up all the functions you're using in your
source... a section called the "import-section" is created in
your executable... there is also a table which contains all
the api memory-bases (these bases are created at runtime
by the loader)... if you make use of some api it isn't in your
executable, it is stored in a dynamic link library... the loader
will scan through the import-sec and build a system-
independent IAT (import_adr_table)...

masm generates something like this:

call dword ptr ; jump to the IAT and Push ip

xx:jmp dword ptr ;jump to the specified dll function
...

yy:dd zz ;adr. base of ... say ExitProcess (points into kernel32)

zz: ;dll function... this memory location should be in your
... ;addres-space...
...
...
ret ;return to host
Posted on 2002-02-27 09:11:51 by mob
quote : there is also a table which contains all
the api memory-bases

is this why there are so many empty zeros after the code ?
is this the table ?
the 3820 (see below) is that a number for exitprocess or something ?

:00401000 6A00 push 00000000
:00401002 E801000000 call 00401008
:00401007 CC int 03
:00401008 FF2500204000 jmp dword ptr [00402000]
:0040100E 00000000000000000000 BYTE 10 DUP(0)
:00401018 00000000000000000000 BYTE 10 DUP(0)
:00401022 00000000000000000000 BYTE 10 DUP(0)
:0040102C 00000000000000000000 BYTE 10 DUP(0)
:00401036 00000000000000000000 BYTE 10 DUP(0)
:00401040 00000000000000000000 BYTE 10 DUP(0)
:0040104A 00000000000000000000 BYTE 10 DUP(0)
:00401054 00000000000000000000 BYTE 10 DUP(0)
:0040105E 00000000000000000000 BYTE 10 DUP(0)
:00401068 00000000000000000000 BYTE 10 DUP(0)
:00401072 00000000000000000000 BYTE 10 DUP(0)
:0040107C 00000000000000000000 BYTE 10 DUP(0)
:00401086 00000000000000000000 BYTE 10 DUP(0)
:00401090 00000000000000000000 BYTE 10 DUP(0)
:0040109A 00000000000000000000 BYTE 10 DUP(0)
:004010A4 00000000000000000000 BYTE 10 DUP(0)
:004010AE 00000000000000000000 BYTE 10 DUP(0)
:004010B8 00000000000000000000 BYTE 10 DUP(0)
:004010C2 00000000000000000000 BYTE 10 DUP(0)
:004010CC 00000000000000000000 BYTE 10 DUP(0)
:004010D6 00000000000000000000 BYTE 10 DUP(0)
:004010E0 00000000000000000000 BYTE 10 DUP(0)
:004010EA 00000000000000000000 BYTE 10 DUP(0)
:004010F4 00000000000000000000 BYTE 10 DUP(0)
:004010FE 00000000000000000000 BYTE 10 DUP(0)
:00401108 00000000000000000000 BYTE 10 DUP(0)
:00401112 00000000000000000000 BYTE 10 DUP(0)
:0040111C 00000000000000000000 BYTE 10 DUP(0)
:00401126 00000000000000000000 BYTE 10 DUP(0)
:00401130 00000000000000000000 BYTE 10 DUP(0)
:0040113A 00000000000000000000 BYTE 10 DUP(0)
:00401144 00000000000000000000 BYTE 10 DUP(0)
:0040114E 00000000000000000000 BYTE 10 DUP(0)
:00401158 00000000000000000000 BYTE 10 DUP(0)
:00401162 00000000000000000000 BYTE 10 DUP(0)
:0040116C 00000000000000000000 BYTE 10 DUP(0)
:00401176 00000000000000000000 BYTE 10 DUP(0)
:00401180 00000000000000000000 BYTE 10 DUP(0)
:0040118A 00000000000000000000 BYTE 10 DUP(0)
:00401194 00000000000000000000 BYTE 10 DUP(0)
:0040119E 00000000000000000000 BYTE 10 DUP(0)
:004011A8 00000000000000000000 BYTE 10 DUP(0)
:004011B2 00000000000000000000 BYTE 10 DUP(0)
:004011BC 00000000000000000000 BYTE 10 DUP(0)
:004011C6 00000000000000000000 BYTE 10 DUP(0)
:004011D0 00000000000000000000 BYTE 10 DUP(0)
:004011DA 00000000000000000000 BYTE 10 DUP(0)
:004011E4 00000000000000000000 BYTE 10 DUP(0)
:004011EE 00000000000000000000 BYTE 10 DUP(0)
:004011F8 00000000000000003820 BYTE 10 DUP(0)
Posted on 2002-02-27 09:36:50 by Jurgen
Just to add to what mob said:

the reason why dll function calls are put in a table is for convenience. You might have 25 calls to MessageBoxA in your app, when windows loads that dll at run time and fixes up your app, it is far easier to change the address of the function stored in the IAT than to scan through your app and change it 25 times (everytime it encounters that MessageBoxA call).
Posted on 2002-02-27 09:41:35 by sluggy
No the reason for the zeros is padding.

The PE file format has sections, each of which will be a multiple of 512 bytes. Some linkers default to higher section alignments (for performance reasons), but the minimum section size that all versions of windows will work with is the 0.5k.

Mirno
Posted on 2002-02-27 09:43:13 by Mirno
I see,

thanks alot guys
Posted on 2002-02-27 09:50:16 by Jurgen