4

I need some help regarding calls in assembly with Ollydbg. I'm messing around with a simple application. So far, so good, I created a codecave for myself to add some code.

But whenever I try to create a call to a function outside my debugged executable module to, for example, a kernel32 or msvcrt function, it messes everything up.

Let's look at some random call in the application:

0041D654     FF15 DC714200  CALL DWORD PTR DS:[<&KERNEL32.GetCommandLineA>]

When I double click it, it shows me CALL DWORD PTR DS:[4271DC] So, 4271DC seems to point to 76FB496D, which is, indeed:

76FB496D >-FF25 60070177    JMP DWORD PTR DS:[<&api-ms-win-core-processenvironment-l1-2-0.Get> ;KERNELBA.GetCommandLineA

Well, I just stole that from the application itself. Now I want to create a call to kernel32 myself. I assemble a line and enter CALL DWORD PTR DS:[Kernel32.GetCommandLineA] Now it's saying:

0041D654     FF15 6D49FB76  CALL DWORD PTR DS:[KERNEL32.GetCommandLineA]

Looking good!

Assemble the line CALL DWORD PTR DS:[76FB496D]. Giving this a run works fine ofcourse, but whenever I run it like this on another pc, all hell breaks loose.

My question is: How can I make such an pointer CALL DWORD PTR DS:[4271DC], so the code runs on all pc's?

I can of course use CALL DWORD PTR DS:[4271DC] in the application to call the function getcomandlineA whenever I want, but I don't know the (dynamic?) pointer to, let's say, kernel32.lstrcpy.

4

The address at 004271DC is resolved at the application start via the executable Imports. Those addresses are different for every executable. The address where the module and functions are loaded (here 76FB496D) is also not guaranteed to always stay the same so you shouldn't hardcode them.

A generic method to call a function in any executable is to dynamically import it with LoadLibrary and GetProcAddress as described here : https://stackoverflow.com/questions/8696653/dynamically-load-a-function-from-a-dll

3

If you just want to use a single CALL, you need to make sure that your target API function is statically imported. You can use a tool like IIDKing to add your target API function to your PE file's static imports.

2

Call to hard-coded addresses will not work for different reasons, the most obvious is ASLR, which randomizes the base address of every DLL, which means that the function address will be different at every boot.

Solving this issue is far from simple as the use of LoadLibrary and GetProcAddress, classically used by developers to dynamically import DLL will also have a dynamic address, so you can't use them to determine the address of your sought function.

To solve this issue you have to use shellcode techniques; in other words you will have to include assembly code that parse the PEB structure to determine the base address of Kernel32 address, search for your function in export table and finally use the it.

Another more advanced techniques for more complex usage is the use of reflective DLL injection, but it is a bit far from what you are looking for.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.