I've written a C++ exe that binds my DLL to Windows Hooks, which entails injecting an instance of the DLL into each process. So you have 1 exe, and 1 or more DLL instances at any time.
I know in a DLL you can use #pragma data_seg(...) and a linker comment to share data between DLLs but the caveat is that you may not share pointers this way for obvious reasons (dynamic memory addresses, pointer offsets etc)
However, might I go in the opposite direction? That is, have a callback function in the exe that the DLLs can invoke? The theory being that if I can define this function location as 'fixed' in memory in the exe, it should be safe for any DLL instance to call it?
Is this possible? I'm worried that the exe is too low level for such an approach.
If not, is there any mechanism I can use to share a single callback function between multiple DLL instances?
Many thanks
No, you cannot put a function pointer into the shared segment. You would still be accessing a process-local memory address across process boundaries, and that is not good.
What you can do instead is have the EXE put an HWND it owns into the shared segment. An HWND can be shared across process boundaries. That way, multiple instances of the DLL can send a message to that HWND when needed, and the EXE can process those messages as it sees fit to do.
Related
There is a graphical library which is used in a dll, loaded into a process. It seems the library leaks (during loading/unloading several times GDI handle count in the Process Explorer property dialog constantly grows for the whole process).
Is there a way to store all GDI handles created by the dll in a process to delete them all after the dll is unloaded? Say, hook CreateBitmap() and so on? But how to determine whether the resource is being created by our dll, not the process itself?
Regards,
Is there a way to store all GDI handles created by the dll in a process to delete them all after the dll is unloaded? Say, hook CreateBitmap() and so on? But how to determine whether the resource is being created by our dll, not the process itself?
No. You are going to need to fix this problem at source. If the DLL really is leaking handles, you have to fix the DLL.
A way to close all handles open by the DLL and release all resources is in usage of a separate process which loads the DLL and terminates after the DLL is unloaded. So you can evaluate which effort is larger: to fix the DLL, to find another DLL (which doesn't leak and perhaps doesn't have many other pitfalls), or to implement inter-process communication to release the handles and still use the DLL. If you choose the latter way, you could transfer the bitmaps drawn between the processes using a block of shared memory, synchronize using named events, etc. .
To determine the caller you have to get stack trace for each call, look at RtlCaptureStackBackTrace.
Another way I would try to do is to modify this DLL (I assume that you have a DLL binary only, not source code: otherwise you could fix the leaks) to make it use say GDI33.DLL instead of GDI32.dll. Then you create GDI33.DLL that exports those functions that are used by that dll. GDI33.DLL forwards calls to GDI32.dll and collects GDI object handles.
I have a target process which loads a DLL before its main code gets called. It accomplishes this through a DLL whose name was added to the file's ImportsTable (using StudPE). My goal is to create a hook DLL that will be injected into this process and intercept its calls before it loads its imports. So the target process will load my hook dll before its security DLL. I tried using the conventional method but I hadn't success because the security DLL always gets called before my hook DLL's DllMain is called. Can anybody tell me a method to solve this issue?
You can create the target process suspended and use CreateRemoteThread() for injection, but mind the following limitations:
You should copy the thread main routine for the remote thread to the address space of the target process.
This code cannot contain any external references (e.g. CRTL or direct WinApi calls). I would usually limit this code to loading of the DLL and either executing function from it, or relying on the DllMain to do the job you need. In order to call LoadLibrary and GetProcAddress methods, I obtain their addresses and copy structure containing this information to the target process and pass the address of the remote structure as an argument for the thread main routine in CreateRemoteThread(). You can use VirtualAllocEx() to allocate memory in the remote process.
Remote thread in this situation will be executed before main thread, including process and some Win32/64 initialization. Therefore, not every Win32 API is safe to call in this condition.
If the target process is spawned by someone else, you have to intercept its creation before it is initialized. There are some ways to do that, all of them are undocumented and therefore not future proof.
The DLL are loaded sequentially in the same order as the imports entries in the PE header. Most PE editors will let you reorder the imports. You should also note that if another DLL X has dependencies on the security DLL, then it will be loaded at the same time as DLL X. Also, if security DLL is using static loading, hooking by modifying the import tables at runtime should still be effective even if your DLL is loaded later, though you will miss the calls done in the meantime (but there shouldn't be any).
My question is really above, I will give more information on this below however:
I have a program which first takes my "false" d3d9.dll, this DLL is then loaded into the game I am reverse engineering. After the some time and the .dll is loaded, along with all the other games dependencies I want to inject my DLL which will do all the dirty work of the reverse engineering.
I think I can load this DLL into the program using LoadLibrary, however when I'm using the DLL I injected to run the main reverse engineered code. Is there a function I can use to call something from the d3d9.dll?
This is because I still need access to the d3d9 library to render things I may want to add on the screen with my injected .dll. I also don't want to just use the d3d9.dll as this will cause problems with loading times, and the point at which memory is changed.
I also don't plan on using DllMain in the DLL, this means I will also need to call a remote function from the d3d9.dll to the injected DLL in order to ensure a safe process start.
Sorry if this is a stupid question, however thanks for any answers.
Back in the old days we use to CreateRemoteThread and use LoadLibraryA as the address for lpStartAddress (This address happens to be the same in all processes). The trick was to allocate the DLL name you are injecting using VirtualAllocEx and use that as lpParameter. Effectively your thread calls LoadLibraryA with the DLL name you want to inject. When the Dll loads Dllmain gets called and you can run code in Dllmain during a time that the dll is being attached (DLL_PROCESS_ATTACH).
This link has some very good information on doing just that. However this technique relies on a Dllmain function. If you can use Dllmain then this mechanism may work. A summary of the steps from that article gives an overview:
Now, we can summarize this technique in the following steps:
Retrieve a HANDLE to the remote process (OpenProces).
Allocate memory in the remote process's address space for injected data (VirtualAllocEx).
Write a copy of the initialised INJDATA structure to the allocated memory (WriteProcessMemory).
Allocate memory in the remote process's address space for injected code.
Write a copy of ThreadFunc to the allocated memory.
Start the remote copy of ThreadFunc via CreateRemoteThread.
Wait until the remote thread terminates (WaitForSingleObject).
Retrieve the result from the remote process (ReadProcessMemory or GetExitCodeThread).
Free the memory allocated in Steps #2 and #4 (VirtualFreeEx).
Close the handles retrieved in Steps #6 and #1 (CloseHandle).
I saw your comment about too much information. Not sure I quite understand. However Dllmain has some restrictions like most Win32 API calls can't be used. There are some exceptions and one being CreateThread. Had you considered spinning off a thread to do work? If you use CreateThread in a Dllmain it effectively gets blocked until Dllmain exits. So once Dllmain returns the Thread will execute.
My question is really above, I will give more information on this below however:
I have a program which first takes my "false" d3d9.dll, this DLL is then loaded into the game I am reverse engineering. After the some time and the .dll is loaded, along with all the other games dependencies I want to inject my DLL which will do all the dirty work of the reverse engineering.
I think I can load this DLL into the program using LoadLibrary, however when I'm using the DLL I injected to run the main reverse engineered code. Is there a function I can use to call something from the d3d9.dll?
This is because I still need access to the d3d9 library to render things I may want to add on the screen with my injected .dll. I also don't want to just use the d3d9.dll as this will cause problems with loading times, and the point at which memory is changed.
I also don't plan on using DllMain in the DLL, this means I will also need to call a remote function from the d3d9.dll to the injected DLL in order to ensure a safe process start.
Sorry if this is a stupid question, however thanks for any answers.
Back in the old days we use to CreateRemoteThread and use LoadLibraryA as the address for lpStartAddress (This address happens to be the same in all processes). The trick was to allocate the DLL name you are injecting using VirtualAllocEx and use that as lpParameter. Effectively your thread calls LoadLibraryA with the DLL name you want to inject. When the Dll loads Dllmain gets called and you can run code in Dllmain during a time that the dll is being attached (DLL_PROCESS_ATTACH).
This link has some very good information on doing just that. However this technique relies on a Dllmain function. If you can use Dllmain then this mechanism may work. A summary of the steps from that article gives an overview:
Now, we can summarize this technique in the following steps:
Retrieve a HANDLE to the remote process (OpenProces).
Allocate memory in the remote process's address space for injected data (VirtualAllocEx).
Write a copy of the initialised INJDATA structure to the allocated memory (WriteProcessMemory).
Allocate memory in the remote process's address space for injected code.
Write a copy of ThreadFunc to the allocated memory.
Start the remote copy of ThreadFunc via CreateRemoteThread.
Wait until the remote thread terminates (WaitForSingleObject).
Retrieve the result from the remote process (ReadProcessMemory or GetExitCodeThread).
Free the memory allocated in Steps #2 and #4 (VirtualFreeEx).
Close the handles retrieved in Steps #6 and #1 (CloseHandle).
I saw your comment about too much information. Not sure I quite understand. However Dllmain has some restrictions like most Win32 API calls can't be used. There are some exceptions and one being CreateThread. Had you considered spinning off a thread to do work? If you use CreateThread in a Dllmain it effectively gets blocked until Dllmain exits. So once Dllmain returns the Thread will execute.
I have a DLL which invokes an application running underneath. This DLL is loaded by several other applications/processes simultaneously.
So, Basically Architecture is:
My Problem is if Application(s) using DLL is crashed, I want to execute an exit sequence in my Base Application and Exit it.
How can I detect that this DLL is no longer used by any application?
Is there any thing like Load Count of DLL which I can keep track of?
Another glitch is I may have to monitor this via a C# application but that is a further thing.
If you can shell an external program to do the check, you can use this:
http://technet.microsoft.com/en-us/sysinternals/bb896656
Your image is not a good model for what really happens in Windows. Every process gets its own copy of the DLL. The code inside the DLL is shared in RAM but not its data. There are ways to share data as well but that's not otherwise common, a memory mapped file is the far more typical approach.
Windows doesn't give cheap way to find out if a DLL is loaded into a process. There is no notification mechanism either. Whatever you do, it has to start with the processes first. That works in C# too, you could use the Process.Modules property.
Just keeping track of the processes you know that load the DLL is probably sufficient, when the process no longer runs then you can safely assume it doesn't have the DLL loaded anymore either. Use the Process.Exited event or use WMI as shown in this answer.
You could host the DLL in the Base Application either and implement your own ref count using shared sections, easy, and often used. As already mentioned, one possibility would be to implemented your ref counting inside your DLL entry point and detect DLL_PROCESS_DETACH, DLL_THREAD_DETACH, DLL_PROCESS_DETACH, etc according to you specifications.