JUMP Table close to the end of the .text section

Question

I have wrote the following very simple program:

#include <Windows.h>
#include <stdio.h>

int wmain(void) {
    DWORD dwProcId = GetCurrentProcessId();
    HANDLE hProc = OpenProcess(0x0400, FALSE, dwProcId);
    wprintf(L"Process handle is %p\n.", hProc);

    return 0;
}

When I open this on x64dbg (or any other debugger), I can see that the IAT is at the start of the .rdata section, and it does include the functions I use, GetCurrentProcessId and OpenProcess, and others.

However, close to the end of the text section, I see this code, which also seems to be something like a jump table: What is this table?

I can see the functions that seem to be called being imported in IAT as well, but I can't find any reference to this table, in any of the PE Guides that I have read.

What is is this table and how can I reference it somehow programmatically, via PE sections or structures?

When I click/enter any of the jumps, I do get inside the `vcruntime140.dll` or inside the `ucrtbase.dll`. The compiler or the linker puts it there? Is there any way to reference it via PE sections, programmatically? — servo, Apr 19 '21 at 16:55

score 1 · Accepted Answer · answered Oct 15 '21 at 08:25

This table is indeed called jump table. Remember that when you compile your code, the compiler doesn't know anything about about the address of the external symbols (like GetCurrentProcessId) in memory. So the op-code of the call will be something like 0xE8 00000000 (E8 is the op-code of the call but you can see that the address is null). However, the compiler creates a symbol table in the object file which is very useful to the linker (e.g., Microsoft linker).

When you link your code, the linker reads the symbol table and reads all the external symbols (like the API calls) and then creates a jump table (like the one you have) often at the end of the .text section. The jump table is in a form of:

jmp dword ptr ds:[Address of the FirstThunk in IMAGE_IMPORT_DESCRIPTOR]

and then, the linker modifies all the call instructions in your code to call the corresponding entry in the jump table.

When you load the binary file into the memory, it's the responsibility of the loader (e.g., Windows loader) to fill the FirstThunk field with the appropriate value in your import table.

With this approach and the collaboration between the compiler, linker, and loader, you can successfully use the external APIs and functions. You can read this post to better understand the jump table.

how can I reference it somehow programmatically, via PE sections or structures?

I don't think you can. This table is part of the .text section and there is no information in the headers about it. However, in a normal PE file (not packed or obfuscated), you can disassemble the .text section (no need to even load the binary into the memory), and look for all the instructions in the form of 0xFF25XXXXXXXX where XXXXXXXX is one of the FirstThunks in your IMPORT_IMAGE_DESCRIPTOR.

If only I could upvote your answer :). I understood everything on what you said. Only instructions starting with FF25 are of interest? Why not other JMP or CALL opcodes? There are many listed here: https://c9x.me/x86/html/file_module_x86_id_26.html. Should I consider this for granted regarding jump opcodes to this jump table? — servo, Oct 16 '21 at 09:51

JUMP Table close to the end of the .text section

1 Answers1