jct052097
asked on
intercepting DLL
I want my program execute and application and
then intercept all DLL calls it sends/receives.
How can I do that?
then intercept all DLL calls it sends/receives.
How can I do that?
nope, neitod, you can.
Matt Pietrek wrote an article a long while back in the Microsoft Systems Journal about a program called APISPY32 that intercepts API calls. It's somewhere in the back issues of MSJ on MSDN, but I think it's in the 1995 issues.
Matt Pietrek wrote an article a long while back in the Microsoft Systems Journal about a program called APISPY32 that intercepts API calls. It's somewhere in the back issues of MSJ on MSDN, but I think it's in the 1995 issues.
The answer is yes and no.
If you are doing this in Win16, you can find out where the DLL is located using LoadLibrary() and for each exported function, overwrite the first 5 bytes of the function to a JMP xxxx where xxxx is your DLL's function, and this will work for every application because this is how Win16 works.
However, if you want this behavior in Win32, you basically can't. You can do it for a single application because you can write a debugger (as nietod suggested). This is basically what Matt's article is about. However, this may or may not be the behavior you're interested in.
If you really want to do this for every single application, you can write a replacement DLL and rename the OS's DLL and make sure your DLL has the same name. Then internally, you can use LoadLibrary to load the renamed OS's DLL and call that through GetProcAddress(). This is clunky and almost always require a reboot because there may already be an application using that DLL to begin with.
If you are doing this in Win16, you can find out where the DLL is located using LoadLibrary() and for each exported function, overwrite the first 5 bytes of the function to a JMP xxxx where xxxx is your DLL's function, and this will work for every application because this is how Win16 works.
However, if you want this behavior in Win32, you basically can't. You can do it for a single application because you can write a debugger (as nietod suggested). This is basically what Matt's article is about. However, this may or may not be the behavior you're interested in.
If you really want to do this for every single application, you can write a replacement DLL and rename the OS's DLL and make sure your DLL has the same name. Then internally, you can use LoadLibrary to load the renamed OS's DLL and call that through GetProcAddress(). This is clunky and almost always require a reboot because there may already be an application using that DLL to begin with.
ASKER
sorry!!!
I wanted to say DDE, not DLL.
I have two programs that communicate each other
by DDE (I think; is there any other way?).
And I would like to monitor them, and
if possible, change the info.
I wanted to say DDE, not DLL.
I have two programs that communicate each other
by DDE (I think; is there any other way?).
And I would like to monitor them, and
if possible, change the info.
Then that's easy. When you use DdeInitialize(), you can use the APPCLASS_MONITOR flag to specify that you want to monitor all DDE messages.
That explains your weird terminology. I though sending/receiving calls was a little unusual.
ASKER
thui,
Please, can you explain me it a little more?
I never have programmed DDE applications.
Just tell me how to start or give a simple example.
I'll grade you.
Please, can you explain me it a little more?
I never have programmed DDE applications.
Just tell me how to start or give a simple example.
I'll grade you.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
The only way I can see to do it would be to modify the EXE's import jump table. You would have to change each entry to point to a procedure of yours that does the monitoring and then jumps to the original procedure. The jump table is read only, however, you can get arround it somehow. (I know this because debugers get arround it somehow.)