Help with PEDEMO.ASM (section .idata)

Index > Windows > Help with PEDEMO.ASM (section .idata)

Author

Thread

uncle les

Joined: 12 Dec 2014
Posts: 3

uncle les 12 Dec 2014, 16:33

Hello,

I am trying to understand how the "Hello World" example for Win32 works (PEDEMO.ASM), but although I have some experience with assembly languages on other platforms, this seems to be a non-trivial task.

I must say that the asm code of the main section is quite straightforward. What puzzles me (and probably not only me) is the section .idata.
In .idata there is definitely some black magic "mumbo jumbo" going on, and unfortunately the author didn't add any comment to his code.

I will list my issues in the hope someone will clarify them

1)

Code:

section '.idata' import data readable writeable
  dd 0,0,0,RVA kernel_name,RVA kernel_table
  dd 0,0,0,RVA user_name,RVA user_table
  dd 0,0,0,0,0

- What are those three zeros in the beginning of each line? They must be there for a reason.

- Why this mysterious section is marked with the flag 'import'?

- Why do we need those strange RVA operators?

2a)

Code:

  kernel_table:
    ExitProcess dd RVA _ExitProcess
    dd 0
  user_table:
    MessageBoxA dd RVA _MessageBoxA
    dd 0

- What are those "dd 0" for? Again, they must be there for some reason, which I don't see.

2b)

Code:

 
  _ExitProcess dw 0
    db 'ExitProcess',0
  _MessageBoxA dw 0
    db 'MessageBoxA',0

- Same issue here. Now we have "dw 0" right before the strings.

3)

Code:

section '.reloc' fixups data readable discardable       ; needed for Win32s

- If I delete this line, the code runs perfectly (at least on my machine). Is this section really needed? It contains absolutely nothing (neither data nor code)...again some sort of "mumbo jumbo"?

4)
Last, but not least: I don't believe in black magic Smile

so I must assume that the author of PEDEMO.ASM was carefully following some specific documentation when writing the section .idata. Could anyone reveal what documentation should I refer to?

Thanks a lot!

12 Dec 2014, 16:33

sleepsleep

Joined: 05 Oct 2006
Posts: 12737
Location: ˛　　　　　　　　　　　　　　　　　　　　　　　　　　　　　⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣Posts: 0010456

sleepsleep 12 Dec 2014, 19:16

Microsoft PE and COFF Specification

Updated: February 6, 2013

http://msdn.microsoft.com/en-us/windows/hardware/gg463119.aspx

12 Dec 2014, 19:16

AsmGuru62

Joined: 28 Jan 2004
Posts: 1619
Location: Toronto, Canada

AsmGuru62 12 Dec 2014, 23:13

Or maybe here, so you do not need to download the whole PE Format:
http://sandsprite.com/CodeStuff/Understanding_imports.html

12 Dec 2014, 23:13

uncle les

Joined: 12 Dec 2014
Posts: 3

uncle les 13 Dec 2014, 10:38

Thanks a lot guys!

Now I really feel that everything starts to make sense. The Microsoft documentation was actually quite clear, though a but terse. It has a whole chapter devoted to the .idata section which basically answers all my questions.

Now I am just a bit confused about the RVA thing. I didn't quite get how those virtual addresses are generated by the OS.

13 Dec 2014, 10:38

baldr

Joined: 19 Mar 2008
Posts: 1651

baldr 13 Dec 2014, 22:46

uncle les,

They're relative to image base, i.e. entry point RVA 1000h corresponds to VA 401000h for module loaded at 400000h.

13 Dec 2014, 22:46

uncle les

Joined: 12 Dec 2014
Posts: 3

uncle les 14 Dec 2014, 16:00

Thanks baldr!
Your explanation was clear.
I just realized that I still have one doubt regarding addresses:

Is it so that in win32, each executable file, when launched, is stored in a virtual memory location, (usually 400000h) although it is physically stored at some "random" memory location, and not necessarily sequentially (the 4Gb flat memory model)?

If am correct, then the RVA should be always given by: current virtual address-400000h, making the RVA-directive imposed by Microsoft completely useless and redundant...unless the virtual location 400000h can change...but, can it change?

14 Dec 2014, 16:00

revolution
When all else fails, read the source

Joined: 24 Aug 2004
Posts: 20299
Location: In your JS exploiting you and your system

revolution 14 Dec 2014, 16:21

uncle les wrote:

If am correct, then the RVA should be always given by: current virtual address-400000h, making the RVA-directive imposed by Microsoft completely useless and redundant...unless the virtual location 400000h can change...but, can it change?

It can change. DLLs and EXEs can be relocated when you include the relocation table.

14 Dec 2014, 16:21

< Last Thread | Next Thread >

Forum Rules:

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum