need help from a MFC programmer

[The Mad Poet]

Have any of you ever looked at the application hook code that microsoft has for download?

right now I'm going through this code and it looks like we will be able to use this to do some nifty things like get the pointer to the ReadProcessMemory function directly.

I figure we can hook this process with dummy code that just forwards the request on - what this will do however is allow us to actually call the ReadProcessMemory function from within the keyreader from the actuall function location instead of the call.

Why is this important you ask?

Well if, once you launch EQ, verant were to hook the ReadProcessMemory function they would in fact be hooking our dummy function and not the real one. As we have the 1st valid pointer to the real function this would let us continue to call the real function without fear that there is a hidden 'tattle tale' code being inserted into this API call.

Once you finish with EQ and close the app - you could then close the keysniffer which would reset the API call and viola - you have made sure that there is no way for Verant to hook the API and figure out what you are doing.

The issue I am stuck with - is I don't have documentation on the MFC API calls - and I would like to know if some kind MFC programmer could give me the actual function prototype for ReadProcessMemory....

Or point me in the right direction so I can find it myself - the code to hook the API requires that I know the API call - the .dll that it resides in - and the prototype of the function (so that when we hook it we don't screw up the way it operates).

[high_jeeves]

Take a look at msdn.microsoft.com

It has all of the MFC docs.

--Jeeves

[pinzmon]

BOOL ReadProcessMemory(
HANDLE hProcess,
LPCVOID lpBaseAddress,
LPVOID lpBuffer,
SIZE_T nSize,
SIZE_T* lpNumberOfBytesRead
);


In Kernel32.dll

[MisterSpock]

Hooking a process in User mode (which is where ReadProcessMemory lives) does not quite work that way. I know this is a bit aside from what you wrote -- I'm just building some background.

They cannot simply hook the API and re-direct it off into some additional routine that gives you bogus data and flags your account for an ass-kicking.

In order to hook the API in user mode, they would have to hook the API in YOUR application's memory. The hook does NOT exist in eqgame.exe. They could hook it there, but then all they would do is redirect their own ReadProcessMemory calls (if there even are any).

If they could not determine which process to hook, they would have to hook RPM (or whatever API) in ALL the processes running on your computer. This would require them to go back to scanning your tasklist, etc. In other words, we would have a very good idea exactly what they're doing if this were to pop up.

To complicate matters for them further, using this method, they have to decide WHEN they're going to look at the tasklist. If your keyripper is launched by a secondary service program, it wouldn't be likely to be in memory when they scanned the task list and thus would not be likely to get hooked.


Now to step aside for a moment and get back to your scenario -- we *do* have a notable advantage in this case. We *know* what the target process and memory space is. We don't have to guess. We can inject, hook, and detour to our hearts' content. Heck, MQ is all about this type of thing, so it is most certainly do-able. We just need to know what to hook and if it is really necessary.

[The Mad Poet]

do a search for detours on the Microsoft site - you *can* hook a API for systemwide useage - it works in NT also.

All you have to do is insert a few lines of code before the real API call ... this code would only need to match if the read call is checking the specific memory address EQ is storing it's file in - I almost have my sample code working and will post it later tonight or sunday (sat is busy) -

I *have* run some sample api hook code on my machine - I hooked the start process function to ask me (in a dialog) every time I started a new process if I really wanted to - and every program you try to open - it pops the dialog up - so I know system wide API call hooks seem to be working - unless I'm going off on a tangent I think our strat needs to be to make sure we *own* the api call and thus can call it protected from another program taking it over.