How do I call a statically imported function from a Dll? call dword ptr ds <> not working

Question

Disclaimer: I am relatively new to this whole RE thing. So I successfully crammed some instructions into the end of an existing DLL and redirected a call.

Now I actually want to do things with a function argument before calling the original code and try to OutputDebugStringA it.

OutputDebugStringA is statically imported by my Dll, so I try to do the following:

call dword ptr ds:[<&OutputDebugStringA>]

This is an instruction I copy from a usage in the DLL itself.

So this works and is successfully called. But, when I patch the Dll with this instruction, on the next run the address is invalid which leads to an Access Violation and crash. (See red line in picture)

Why is that so? Shouldn't the IAT entry of the function be always at the same place, relative to where the Dll was loaded?

And how do I fix it?

Do I need complicated hacks to find the base address of my module?

Or is there some sort of relative far call instruction I am stupidly not aware of?

Thank you for your help.

---

I think I got it now. So I can't be sure that the IAT is always at the same address, not even relative to the ds segment (which makes it kinda useless in my opinion).

I can however be sure that the IAT address is always a fixed relative amount away from the code I want to run.

So I googled PIC techniques under x86 and ended up with this code that seems to work fine so far.

push ebp
mov ebp,esp
push eax
push ecx
push edx
push dword ptr ss:[ebp+C]
call <rcp-be-name.tmplbl>
pop ebx   ;@tmplbl
lea eax,dword ptr ds:[ebx+80F] ;the relative offset
call dword ptr ds:[eax-5] ;dunno why 5
pop edx
pop ecx
pop eax
push dword ptr ss:[ebp+C] ;the original arguments
push dword ptr ss:[ebp+8] ;  ...
call rcp-be-name.644A97D0 ;the original function
add esp,8
pop ebp
ret

Thanks a lot!

Answer 1

It appears you've already guessed what the actual issue is - your call instruction is using direct addressing and not relative addressing. This means that when a DLL changes it's location between executions you're still trying to execute the same absolute value, resulting in different types of errors depending on the content of the actual content in that address.

Specifically to your question - 0xFF 15 is an absolute, near, 4 byte immediate call. 0xFF is used for absolute calls, while 0x8E is used for relative calls (as you can see in your image, at the yellow highlighted line).

Replacing the single byte 0xFF will turn the instruction to a relative instruction, meaning the call will be to $+5e01d0e4 instead of to 0x5e01d0e4. The dollar sign ($) is a conventional representation of "the address of the next instruction".

Because how the x86 CPU (and many other CPUs) works, it is easier to first advance to the next instruction, and only then carry out any EIP modifying operations, thus having relative operations modify the EIP values of the following instruction.

Replacing the four last bytes with any signed integer will make the call instruction add that number (thus negative numbers are used to call a smaller address value) to the address of the next instruction. For example, the byte code FF 15 EA FF FF FF will be translated to a six byte long instruction call $-6, creating a call that calls itself, eventually faulting on a stack overflow.

A method simpler than manually editing instruction byte code could be using olly's assemble command with a $ sign to indicate a relative instruction.