1

I'm demonstrating an exploit for an old app.

On Windows XP SP3 32bit (EN), the address of SetProcessDEPPolicy() is usually 0x7C8622A4. I have that version of Windows (in English as well) and I've successfully built a ROP chain that brings me to exactly that place in memory with my return address to my shellcode and a 0 arguments neatly and correctly sitting on the stack.

But when trying to execute at that point I get debugged program was unable to process exception in my debbuger or a DEP exception when triggering the exploit outside of the debugger.

I'm wondering if it may be because of my patch level (I have the very latest patches). Has the address of SetProcessDEPPolicy() changed?

How can I manually find the address of that API function myself?

If the address of SetProcessDEPPolicy() hasn't changed, why am I getting an exception?

The screenshot below shows the situation where I get the exception, as far as I can tell I've got everything where it should be and should be able to disable DEP instead of getting an error. There's comments on the screenshot and you can get a better resolution by right-click->view image.

enter image description here

Juicy
  • 1,407
  • 4
  • 16
  • 31
  • If you're using a different language version then the address can be different. Each language version is compiled separately, and the position in the DLL can be different (doesn't have to be). I only ask since you mention *"I have that version in English as well"* Although you don't mention which version of Windows is not working. – RoraΖ Jan 26 '15 at 17:40
  • @raz Sorry I didn't express myself correctly, no I'm definitely running Windows XP SP3 English myself. The position in the DLL should be correct unless it's changed in one of the latest patches. – Juicy Jan 26 '15 at 18:05
  • Depends on when you last tried it. XP was end of lifed in April. So if you tried it some significant time before then it's possible that kernel32 changed in an update. – RoraΖ Jan 26 '15 at 18:12

1 Answers1

1

Finding functions come in two flavors:

  1. Exported - Super easy.

In Windows use 

HANDLE kernel32 = GetModuleHandle(L"kernel32");
FARPROC funcAddr = (FARPROC *) GetProcAddress(kernel32, "SetProcessDEPPolicy");

This will return the address of the function if it's exported by the module, in this case the module is kernel32.

  1. Non-exported - Annoying

The first step is to manually find it first through some sort of reverse engineering. This can be rough. If you know of certain constant error types it might return you can narrow down the search to a handful of procedures. Windows loves using constants, and they document their use in the MSDN. Sometimes unexported functions are documented by other researchers, or if you're lucky enough to be doing this on an open source project you can look for the constants there. But really you have to find the function through good old fashion RE.

You can take it a step further to make this easier on yourself in the future. Find a unique byte stream to the function. Then write your own function that can search a given image for that unique sequence, and calculate the offset to the beginning of the function. Boom you have an address.

Of course using this dynamic searching is not guaranteed from version to version. Maybe the compiler took a different optimization on SP1 than SP2? The unique stream then becomes invalid. But that's really the best option you have for unexported functions.

RoraΖ
  • 12,317
  • 4
  • 51
  • 83
  • Thanks! The address was indeed the problem, I managed to get the actual address of `SetProcessDEPPolicy` on my system. – Juicy Jan 26 '15 at 22:46