When a process from abc.cpp hooks a DLLMain, it executes the DLL_PROCESS_ATTACH. Can we pass any data or parameter to DLLMain, so that it can be used inside DLL_PROCESS_ATTACH.
As of now I am using SetProp and GetProp of window API to share data, while considering desktop window as the parent window. But I am not sure about the pros and cons of this approach.
Thanks in advance
As far as I know you can not pass a parameter when attaching. You can set an environment variable, use the registry...an INI file if you want to be old-fashioned :-)
Or, you can have a function in the DLL which is called after it is loaded, and pass the information by parameter.
If none of these solutions address your problem, please explain what you are trying to accomplish, so we can help you better.
Related
i am currently stuck in the process of trying to create a wrapper DLL for another DLL which i want to replace but then include in my own created DLL.
When the dll is getting attached by the main program i would load the original DLL and then setup a hook function that let's me decide what i want to send to the original DLL function.
I already have the basic structure to import the dll, but my problem is that i don't really know what the best way of doing it is, because i only want to hook one function and the others should still just work normally without me doing anything.
Is there an easier solution than defining every function and just redirecting it to the original DLL? And also how would i even make it that my DLL function is exactly the same as the original one? I got a basic prototype but i don't know if i need anything else:
typedef int(__cdecl *PROC_cef_parse_url)(
const cef_string_t* url,
cef_urlparts_t* parts
);
And i can call it probably like this:
PROC_cef_parse_url _cef_parse_url = (PROC_cef_parse_url) GetProcAddress(hModule, "cef_parse_url");
But because i actually have no idea if this works or not and have no experience in DLL creation and stuff like this, i wanted to ask if i need something else, or if someone can provide me with an easy example.
I want to install a hook (on Windows using the WinAPI and C++) to get key-input events that are sent to the WindowProc of a specific process/thread (known to my program by process ID). As far as I understood I have to put the hook procedure into a DLL. So far everything is fine for me. But the hook procedure needs to use data from the program that installed the hook. Now I don't know how to access this data from my hook procedure inside the DLL.
My first thoughts were to maintain a data struct inside the DLL itself and update it from outside by calls to another function placed inside the DLL. But I am not sure, how exactly to do that (for example: I assume this data struct would have to be shared data so that it is the same for all calls, no matter from which process/thread, but I am not sure about it).
I've looked at a few examples on how to implement hooks but these examples never used data from the original program that installed the hook (or any other 'user-code').
I would really appreciate it when somebody could explain this to me or even give me a brief outline on how to solve the problem described above (and whether my approach is right).
Many thanks in advance!
You may use Shared Data section
// dll.cpp
#pragma data_seg("myshared")
int iShared;
#pragma data_seg()
#pragma comment(linker, "/section:myshared,RWS")
Export a function from the DLL, allowing to pass the value(s) to be used for the variable(s) in the section. Call that function from your hooking EXE (before hooking). The instance DLL in the hooked process will see the value(s) set by the hooking EXE.
What you really are describing is inter-process communication(IPC): http://en.wikipedia.org/wiki/Inter-process_communication
Your options for windows are to create a socket, a pipe, or shared-memory and use mutexes, semaphores, or events for synchronisation.
Other than that, there is no way to call functions in a dll injected into another process.
You can view an example I posted here: Two separate processes sharing the same Camera feed OpenCv
Is there a way (in C++ & windows XP) to detect if one process spawns any other processes?
for example,
write.exe in system32 spawns wordpad.exe then disappears, is there a function that tells me if the process is about to do this?
for those interested i solved the problem using this section of msdn:
http://msdn.microsoft.com/en-us/library/aa390425(v=VS.85).aspx
Nothing in the Win32 API for this. However, it is supported through WMI with the Win32_ProcessStartTrace query. You'll find some C# code that demonstrates the query in my answer in this thread. Writing WMI code in C++ is fairly painful, you'll find a link to boilerplate code you have to write in the MSDN Library article.
Do beware that this isn't particularly fast. It isn't clear to me how much help the WMI provider gets from the kernel to generate the notification but given the speed it quacks like polling. In other words, the process is likely to be well on its way by the time you get the notification. This is otherwise par for the course on a multitasking operating system.
You can enumerate over the process tree, which identifies running processes and their parents. This is the inverse of what you want (you want to identify child processes, not parent processes). But of course by keeping track of parent process IDs while enumerating, you can identify which sub-processes a given process has spawned.
To do this, call CreateToolhelp32Snapshot and then use Process32First and Process32Next to enumerate the processes. The enumeration will fill in a PROCESSENTRY32 struct that contains a th32ParentProcessID member.
This is a polling method; there may be another way of actually hooking the CreateProcess function, but I don’t have any information about that.
I think you would need to make a global hook DLL that attaches itself to every running process. DLL then finds a place where a function call to CreateProcess is mapped to actual CreateProcess from kernel32, and change a table entry to redirect the call to it's own code to "detect" the call to CreateProcess. All this assuming that some user firewall will not prevent your global hook from executing.
I'd like to execute some code whenever a (any!) message box (as spawned by the MessageBox Function) is shown in another process. I didn't start the process I'm monitoring.
I can think of three approaches:
Install a global CBT Hook procedure which tells me whenever a window is created on the desktop. Then, check whether the window belongs to the process I'm monitoring and whether the class name is #32770 (which is the class name of dialogs according to the About Window Classes page at the MSDN). This would probably work, but it would pull the DLL which contains the hook procedure into virtually every process on the desktop, and the hook procedure gets called a lot. It smells like a potential perfomance problem.
Try to subclass the #32770 system window class (is this possible at all?) and look for WM_CREATE messages in my custom window procedure.
Intercept the MessageBox Function API call (even though the remote process is running already!) and call my code from the hook function.
So far, I only know that the first idea is feasible, but it seems really inefficient. Can anybody think of a simpler solution than that to this problem?
I can't think of any efficient solution that doesn't involve injecting code into the other process (this is basically what many types of hooks do by the way). But if you are willing to go down that path, you can intercept calls to MessageBox.
Spend some time stepping through into a call to MessageBox in the debugger in assembly language mode and you'll see that it's an indirect call through a lookup table (that's how exports work). so if you can get your code into the process, you can patch the table to jump to your code instead.
See http://www.codeproject.com/KB/threads/completeinject.aspx for code showing how to inject a dll into another process.
I think: Approach 2 is impossible. Approaches 1-3 require dll, that is loaded into all processes, and approach 3 is "more right". I suppose searching windows by timer is not suite by some reasons?
I would go with the first option. You should be able to get away with only installing the hook for the main UI thread of the app you're monitoring, but if that doesn't work, even global CBT hooks aren't terribly resource intensive in my experience. Of course, you'll want your hook DLL to contain as little as possible other than the hook logic itself. If you need anything bulky, link it dynamically only when you know you're in the right process.
I have a C++ Windows application myapp.exe which loads several plug-ins.
Plug-ins need to find the path to their DLLs. I can use GetModuleFileName for this, but it need the handle for the plug-in DLL. I don't know where to get this handle. GetModuleHandle(NULL) returns the handle to the executable.
One option is to use GetModuleHandle (GetModuleHandle("myplugin.dll") ) , but this requires the name of the plugin to be hardcoded which I want to avoid.
Any help is appreciated.
Paul
I don't know where to get this handle
It's passed as a parameter to your DLLMain() entry function.
If the plugin can't access its DLLMain() entry function, it can use the VirtualQuery function on a piece of its own memory and use the AllocationBase field of the filled-in MEMORY_BASIC_INFORMATION structure as its HMODULE.