[?] Calling a procedure by its address

[?] Calling a procedure by its address - Printable Version

-Shoutbox (https://shoutbox.menthix.net)
+-- Forum: MsgHelp Archive (/forumdisplay.php?fid=58)
+--- Forum: Messenger Plus! for Live Messenger (/forumdisplay.php?fid=4)
+---- Forum: Scripting (/forumdisplay.php?fid=39)
+----- Thread: [?] Calling a procedure by its address (/showthread.php?tid=97503)

[?] Calling a procedure by its address by SmokingCookie on 05-01-2011 at 04:00 PM

I've got a big secret project that I'm working on, but I'm kinda stuck. The thing is: I know the address of a certain procedure in a process - let's say CreateWindowExW() - and I want to call the function by its address, rather than through Interop.Call(). Can this be done?

Obviously, if there's something like a CallProcedure() function in a Windows DLL I have to use Interop.Call(), but I don't want to call CreateWindowExW directly - if ya take my meaning

RE: [?] Calling a procedure by its address by CookieRevised on 05-01-2011 at 05:40 PM

If it is another Windows API you wanna call, then there is absolutely no reason to not directly call it by its exported name using Interop.Call.

If it is not a Windows API, but some internal non-exported procedure in the process then you can (ab)use the Windows API CallWindowProc.

Although not 'officially' supported, it is the function which is (ab)used to call procedures by address.

If you examine its parameters you'll notice that it actually does exactly that; calling a procedure by address. This because a window handle has in fact always the same value as the address of the WinProc procedure for that window (the procedure which is responsible for handling the recieved Windows Messages etc). So, the API does nothing more than instructing the computer to call the procedure at address hWnd. The rest of the 4 parameters are simply input parameters for that procedure.

However, there are some big risks involved in (ab)using that. For starters you need to know exactly what the procedure you're calling does and where it gets its parameters from, how they are handled, etc. You also need to know if it is safe to call that procedure just out of the blue. This is by no means a straithforward thing to do and requires reverse engineering to get that knowledge. Even getting one small thing wrong might BSOD Windows.

Also note that this API is actually mostly (ab)used to call injected assembler code (so yes, you can use this API to run assembler code from within _any_ language which allows you to call this Windows API, like for example Plus! scripting).

RE: [?] Calling a procedure by its address by SmokingCookie on 05-01-2011 at 05:48 PM

Now that's a useful thing!

But there's a snake in the grass: CallWindowProc() allows up to four parameters. So I'd think that this will only work for procedures that take exactly four parameters. However, please do correct me if I'm wrong

Edit: ain't this exactly what SendMessage() does?

RE: [?] Calling a procedure by its address by CookieRevised on 05-02-2011 at 07:26 AM

quote:
Originally posted by SmokingCookie
But there's a snake in the grass: CallWindowProc() allows up to four parameters. So I'd think that this will only work for procedures that take exactly four parameters. However, please do correct me if I'm wrong

Yes and no. It highly depends on how that procedure reads its input data. For all you know the first input 'parameter' of that procedure can actually be a pointer to an array of data (aka parameters). So, in that case you would only need to use 1 parameter of the CallWindowProc API (the rest is simply ignored).

In real assembler code (which is essentially what you call with this API), parameters as you know it from the common programming languages don't even exist. Input and output data is handled via registers and the stack.

Also, you can call your own small assembler stub/snippet instead, which will take the first parameter of CallWindowProc, interpret it as a pointer to the other input data, read in and manipulate that data, and put it into the proper registers and stacks and call the procedure you wanted to call in the first place, on its turn (which can then use those registers/stack). This is what "injecting code" often means when you read it somewhere. So, no, there are no limits in what you can do with this.

Bleh, maybe someone with true assembler knowledge can explain it way better. But the point is that if you don't know how much 'parameters' the procedure uses, or you don't know how or where it gets its data from, then you shouldn't be attempting to use the CallWindowProc API for something like this though, because you will screw things up (bsod and the likes). This is one of those rare things you can not solve with simple trial and error; you need to know exactly what you're doing and know exactly how the procedure works before attempting to call it (reverse engeneering).

quote:
Originally posted by SmokingCookie
Edit: ain't this exactly what SendMessage() does?

Nope, not at all. The SendMessage API places a value in a window's Message queue which is a special dedicated array so to speak. The SendMessage API is like the array.push() method in JScript (sort of, in a very remote and oversimplified way). It has absolutely nothing to do with calling procedures.

EDIT:
here is an example of using the CallWindowProc API to call an ASM routine:
Call ASM routine from your script (with example)