Three Ways To Inject Your Code Into Another Process

In general, an executable is composed of several sections, including a “.reloc” section.

When the linker creates an EXE or DLL file, it makes an assumption about where the file will be mapped into memory. That’s the so-called assumed/preferred load/base address. All the absolute addresses in the image are based on this linker assumed load address. If for whatever reason the image isn’t loaded at this address, the PE—portable executable—loader has to fix all the absolute addresses in the image. That is where the “.reloc” section comes in: It contains a list of all the places in the image, where the difference between the linker assumed load address and the actual load address needs to be factored in (anyway, note that most of the instructions produced by the compiler use some kind of relative addressing; as a result, there are not as many relocations as you might think). If, on the other side, the loader is able to load the image at the linkers preferred base address, the “.reloc” section is completely ignored.

But, how do kernel32.dll, user32.dll and their load addresses fit into the story?

Because every Win32 application needs kernel32.dll, and most of them need user32.dll, too, you can improve the load time of all executables by always mapping them (kernel32 and user32) to their preferred bases. Then the loader must never fix any (absolute) addresses in kernel32.dll and user32.dll.

Let’s close out this discussion with the following example:

Why? When creating a process, the loader on Win 2000, Win XP and Win 2003 checks if kernel32.dll and user32.dll (their names are hardcoded into the loader) are mapped at their preferred bases; if not, a hard error is raised. In WinNT 4 ole32.dll was also checked. In WinNT 3.51 and lower such checks were not present, so kernel32.dll and user32.dll could be anywhere. Anyway, the only module that is always at its base is ntdll.dll. The loader doesn’t check it, but if ntdll.dll is not at its base, the process just can’t be created.

To summarize, on WinNT 4 and higher:

• DLLs, that are always mapped to their bases: kernel32.dll, user32.dll and ntdll.dll.
• DLLs that are present in every Win32 application (+ csrss.exe): kernel32.dll and ntdll.dll.
• The only DLL that is present in every process, even in native applications: ntdll.dll.

When /GZ is turned on, the compiler will add some additional code to every function residing in the executable, including a function call (added at the very end of every function) that verifies the ESP stack pointer hasn’t changed through our function. But wait, a function call is added to ThreadFunc? That’s the road to disaster. Now the remote copy of ThreadFunc will call a function that doesn’t exist in the remote process (at least not at the same address).

const int cbCodeSize = ((LPBYTE) AfterThreadFunc

                      – (LPBYTE) ThreadFunc);

you will actually calculate the “distance” between the JMPs that point to ThreadFunc and AfterThreadFunc respectively (usually they will appear one right after the other; but don’t count on this). Now suppose our ThreadFunc is at address 004014C0 and the accompanying JMP instruction at 00401020.

:00401020   jmp  004014C0

 …

:004014C0   push EBP          ; real address of ThreadFunc

:004014C1   mov  EBP, ESP

 …

Then

WriteProcessMemory( .., &ThreadFunc, cbCodeSize, ..);

will copy the “JMP 004014C0” instruction (and all instructions in the range of cbCodeSize that follow it) to the remote process—not the real ThreadFunc. The first thing the remote thread will execute will be a “JMP 004014C0”. Well, it will also be among its last instructions—not only to the remote thread, but to the whole process.

void Dummy(void) {
   BYTE var[256];
   var[0]   = 0;
   var[1]   = 1;
   var[255] = 255;
}

could, for instance, compile into something like this:

:00401000   push ebp
:00401001   mov  ebp, esp
:00401003   sub  esp, 00000100     ; change ESP as storage for
                                   ; local variables is needed
:00401006   mov  byte ptr [esp], 00      ; var[0] = 0;
:0040100A   mov  byte ptr [esp+01], 01   ; var[1] = 1;
:0040100F   mov  byte ptr [esp+FF], FF   ; var[255] = 255;
:00401017   mov  esp, ebp          ; restore stack pointer
:00401019   pop  ebp
:0040101A   ret

Note how the stack pointer (ESP) was changed in the above example? But what is different if a function needs more than 4 Kb for its local variables? Well, then the stack pointer isn’t changed directly. Rather, another function (a stack probe) is called, which in turn changes it appropriately. But it’s exactly this additional function call that makes our ThreadFunc “corrupt,” because its remote copy would call something that’s not there.

Let’s see what the documentation says about stack probes and the /Gs compiler option:

I’m sure one or another wondered about the above statement: “…a stack probe reaches benignly into memory…”. Those compiler options (their descriptions!) are sometimes really irritating, at least until you look under the hood and see what’s going on. If, for instance, a function needs 12 Kb storage for its local variables, the memory on the stack would be “allocated” (more precisely: committed) this way:

sub    esp, 0x1000    ; “allocate” first 4 Kb

test  [esp], eax      ; touches memory in order to commit a

                      ; new page (if not already committed)

sub    esp, 0x1000    ; “allocate” second 4 Kb

test  [esp], eax      ; …

sub    esp, 0x1000

test  [esp], eax

Note how the stack pointer is changed in 4 Kb steps now and, more importantly, how the bottom of the stack is “touched” (via test) after each step. This ensures the page containing the bottom of the stack is being committed, before “allocating” (committing) another page.

After reading ..

… it should also be clear why the documentation about /Gs says that you get with stack probes a carefully tuned interaction between your application and the Windows NT virtual-memory manager.

int Dummy( int arg1 )

{

   int ret = 0;

   switch( arg1 ) {

   case 1: ret = 1; break;

   case 2: ret = 2; break;

   case 3: ret = 3; break;

   case 4: ret = 0xA0B0; break;

   }

   return ret;

}

It would compile into something like this:

 Address  OpCode&Params    Decoded instruction

————————————————–

                                            ; arg1 -> ECX

:00401000 8B4C2404         mov ecx, dword ptr [esp+04]

:00401004 33C0             xor eax, eax     ; EAX = 0

:00401006 49               dec ecx          ; ECX —

:00401007 83F903           cmp ecx, 00000003

:0040100A 771E             ja 0040102A

; JMP to one of the addresses in table ***

; note that ECX contains the offset

:0040100C FF248D2C104000   jmp dword ptr [4*ecx+0040102C]
; case 1: eax = 1;

:00401013 B801000000       mov eax, 00000001

:00401018 C3               ret
; case 2: eax = 2;

:00401019 B802000000       mov eax, 00000002

:0040101E C3               ret
; case 3: eax = 3;

:0040101F B803000000       mov eax, 00000003

:00401024 C3               ret
; case 4: eax = 0xA0B0;

:00401025 B8B0A00000       mov eax, 0000A0B0
:0040102A C3               ret

:0040102B 90               nop
; Address table ***

:0040102C 13104000         DWORD 00401013   ; jump to case 1

:00401030 19104000         DWORD 00401019   ; jump to case 2

:00401034 1F104000         DWORD 0040101F   ; jump to case 3

:00401038 25104000         DWORD 00401025   ; jump to case 4

Note how the switch-case was implemented?
Rather than examining every single case statement separately, an address table is created. Then, we jump to the right case by simply calculating the offset into the address table. If you think for a moment, this really is an improvement. Imagine you had a switch with 50 case statements. Without the above trick, you had to execute 50 CMP and JMP instructions to get to the last case. With the address table, on the contrary, you can jump to any case by a single table look-up. In terms of computer algorithms and time complexity: We replace an O(2n) algorithm by an O(5) one, where:

1. O denotes the worst-case time complexity.
2. We assume five instructions are neccessary to calculate the offset, do the table look-up, and finally jump to the appropriate address.

Now, one might think the above was possible only because the case constants were carefully chosen to be consecutive (1,2,3,4). Fortunately, it turns out the same solution can be applied to most real-world examples, only the offset calculation becomes somewhat more complicated. But there are two exceptions, though:

• if there are three or fewer case statements or
• if the case constants are completely unrelated to each other (i.e. “case 1”, “case 13”, “case 50”, and “case 1000”)

then the resulting code does it the long way by examining every single case constant separately, with the CMP and JMP instructions. In other words, then the resulting code is essentially the same as if you had an ordinary if-else if sequence.

Point of interest: If you ever wondered for what reason only a constant-expression can accompany a case statement, then you know why by now. In order to create the address table, this value obviously has to be known at compile time.

Now back to the problem!
Notice the JMP instruction at address 0040100C? Let’s see what Intel’s documentation says about the hex opcode FF:

Opcode    Instruction    Description
FF /4     JMP r/m32      Jump near, absolute indirect,
                         address given in r/m32

Oops, the debatable JMP uses some kind of absolute addressing? In other words, one of its operands (0040102C in our case) represents an absolute address. Need I say more? Now, the remote ThreadFunc would blindly think the address table for its switch is at 0040102C, JMP to a wrong place, and thus effectively crash the remote process.