I'm having a bit of a problem with trying out this concept. The concept is as follows:
According to this website, http://www.codeproject.com/system/hooksys.asp (search for the text "Proxy DLL (Trojan DLL)"), an easy way to hook an API function call by a program is to create a 'proxy' DLL. The proxy DLL exports a function with the same name as the target API function, and the compiled DLL takes on the same name as the host DLL for the targeted API function. Supposedly, when this proxy DLL is located in the same directory as the target application (which is calling the target API function), the proxy DLL is loaded instead of the standard Windows DLL, at which points the proxy DLL can do it's work, and optionally call the original API function.
I've created a DLL that exports a MessageBoxA function. The function reads in the parameters passed to it, appends certain text to the text which is to be displayed in the messagebox, then calls the original MessageBoxA function with the edited data. I've created a test program that calls the MessageBoxA function (when my proxy DLL is located in the same working directory), but the original function is being called, not the function in my proxy DLL. If I rename my proxy DLL from "user32.dll" to "myuser32.dll", for example, then use LoadLibrary ("myuser32.dll") and GetProcAddress in my test program and call the pointer to MessageBoxA, everything works as I'd like it to... my proxy DLL was loaded, my proxy function called, and a messagebox pops up with edited text.
So then, what am I missing? If my DLL and it's exported function works are loaded and work successfully when specifically targeted, why does my DLL not get loaded when not specifically targeted, as I'm lead to believe it should, as per the web page mentioned above? The same notion is described near the top of the web site, http://www.internals.com/articles/apispy/apispy.htm, where I quote:
"This can be easily accomplished by creating a proxy DLL, which contains a stub for each of the functions exported from the Winsock library. If the proxy DLL is named exactly like the original Winsock library (i.e. wsock32.dll) and placed in the same directory where the target email application resides, then the interception occurs automatically. When the target application attempts to load the original Winsock library, the proxy DLL is loaded instead. All the calls made to Winsock's functions are routed to the exported stubs in the proxy. After performing the necessary processing, the proxy DLL simply routes the calls to Winsock and returns control back to its caller."
I appologize for the lengthy post, but I wanted to be very clear in what I was attempting to accomplish.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The reason why you had to manually load it was because your DLL was not called "user32.dll". Do not rename your proxy dll to user32.dll. User happens to compromise approximately 1/3rd of the entire winblows operating system. Replacing with your proxy dll that only exports one function out of the hundreds that are necessary will, no doubt, fuck your installation.
What you probably want to do is just hook a specific exported routine without replacing it entirely, along with everything else. I saw a tutorial on this a while ago, but don't remember where.
Kip
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Sorry Kip, I think you mis-understood two important things. First, I DID originally name my DLL "user32.dll" (which didn't work in catching API calls to functions generally provided by the original user32.dll file). And if you'll notice, I certainly was not attempting to replace the original user32.dll file (located in "%SystemRoot%\system32"), and doing so really wouldn't be API hooking anyway. As I said, and as both web sites I refered to mention, the hook DLL is placed in the same (working) directory as the target application that you want to intercept an API function call from. Once the hook DLL intercepts an API call, it does what it needs to do, then calls the original API function in the original user32.dll file, which hasn't moved.
As a side note, I dide make stubs in my DLL for ALL user32.dll remaining exported functions (in the form of "<function name> = user32.<function name>" in a REF file). The exception of course is the MessageBoxA function, which just shows up in the REF file as "MessageBoxA".
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'm having a bit of a problem with trying out this concept. The concept is as follows:
According to this website, http://www.codeproject.com/system/hooksys.asp (search for the text "Proxy DLL (Trojan DLL)"), an easy way to hook an API function call by a program is to create a 'proxy' DLL. The proxy DLL exports a function with the same name as the target API function, and the compiled DLL takes on the same name as the host DLL for the targeted API function. Supposedly, when this proxy DLL is located in the same directory as the target application (which is calling the target API function), the proxy DLL is loaded instead of the standard Windows DLL, at which points the proxy DLL can do it's work, and optionally call the original API function.
I've created a DLL that exports a MessageBoxA function. The function reads in the parameters passed to it, appends certain text to the text which is to be displayed in the messagebox, then calls the original MessageBoxA function with the edited data. I've created a test program that calls the MessageBoxA function (when my proxy DLL is located in the same working directory), but the original function is being called, not the function in my proxy DLL. If I rename my proxy DLL from "user32.dll" to "myuser32.dll", for example, then use LoadLibrary ("myuser32.dll") and GetProcAddress in my test program and call the pointer to MessageBoxA, everything works as I'd like it to... my proxy DLL was loaded, my proxy function called, and a messagebox pops up with edited text.
So then, what am I missing? If my DLL and it's exported function works are loaded and work successfully when specifically targeted, why does my DLL not get loaded when not specifically targeted, as I'm lead to believe it should, as per the web page mentioned above? The same notion is described near the top of the web site, http://www.internals.com/articles/apispy/apispy.htm, where I quote:
"This can be easily accomplished by creating a proxy DLL, which contains a stub for each of the functions exported from the Winsock library. If the proxy DLL is named exactly like the original Winsock library (i.e. wsock32.dll) and placed in the same directory where the target email application resides, then the interception occurs automatically. When the target application attempts to load the original Winsock library, the proxy DLL is loaded instead. All the calls made to Winsock's functions are routed to the exported stubs in the proxy. After performing the necessary processing, the proxy DLL simply routes the calls to Winsock and returns control back to its caller."
I appologize for the lengthy post, but I wanted to be very clear in what I was attempting to accomplish.
Hey man,
The reason why you had to manually load it was because your DLL was not called "user32.dll". Do not rename your proxy dll to user32.dll. User happens to compromise approximately 1/3rd of the entire winblows operating system. Replacing with your proxy dll that only exports one function out of the hundreds that are necessary will, no doubt, fuck your installation.
What you probably want to do is just hook a specific exported routine without replacing it entirely, along with everything else. I saw a tutorial on this a while ago, but don't remember where.
Kip
Sorry Kip, I think you mis-understood two important things. First, I DID originally name my DLL "user32.dll" (which didn't work in catching API calls to functions generally provided by the original user32.dll file). And if you'll notice, I certainly was not attempting to replace the original user32.dll file (located in "%SystemRoot%\system32"), and doing so really wouldn't be API hooking anyway. As I said, and as both web sites I refered to mention, the hook DLL is placed in the same (working) directory as the target application that you want to intercept an API function call from. Once the hook DLL intercepts an API call, it does what it needs to do, then calls the original API function in the original user32.dll file, which hasn't moved.
As a side note, I dide make stubs in my DLL for ALL user32.dll remaining exported functions (in the form of "<function name> = user32.<function name>" in a REF file). The exception of course is the MessageBoxA function, which just shows up in the REF file as "MessageBoxA".