I have a small problem. I have loaded DLL into the process (it's not mine) and I have to use function inside it. I have got offset to this function so only what I have to do is to get DLLs address and add to it the offset to get to the function. GetModuleHandle() returns HMODULE variable but actually I don't know what HMODULE is. Is it address of loaded DLL or some kind of other mark?
And if it's not address of place where DLL is loaded, how can I get this address? I hope I make myself clear.
The method that you propose will work fine.
It seems that you have injected a dll into a target process and wish to obtain the address of a function in that dll in the target process from the process that injected the dll.
I assume that you also have the dll loaded in the process that injected the dll into the target process and that you want to create a remote thread in the target process and get it to execute the target function in the target process.
Since the dll that you have injected may not be loaded at the same address in the target process as it is in the injecting process you cannot simply use the address that you would obtain from calling GetProcAddress on the function in the injecting process.
An HMODULE is just the DLL's base address (see this answer for details). So you can take the HMODULE of the dll in your injecting process and subtract it from the address returned by GetProcAddress on your function. You can then add the HMODULE of the injected dll in the target process to this offset to get the address of the target function in the injected dll in the target process. Assuming this function has the correct signature, pass it as the thread function to your call to create the remote thread and you are now running the target function in the target process.
I explain this in more detail in this answer.
Call GetProcAddress. The offset cancels out, as you'd have to both add it (to get to the function) and subtract it (to get the base address), so you might as well not bother.
It is similar to the void* returned by the POSIX dlopen() function (it might even be a typedef - but I don't know that for sure). You pass it to GetProcAddress as an argument. When you are done you also pass it to FreeLibrary to unload the DLL.
Related
x86 way of doing this is easy and straightforward - through GetExitCodeThread. Unfortunately it's limited to returning 32 bit values. As I understand it WinAPI provides no 64 bit alternative.
So the problem is - I have no trouble calling the injected function by finding its base address through CreateToolhelp32Snapshot module loop then running CreateRemoteThread using it, it does whatever I wrote in it as it should but how exactly do I retrieve its return value without GetExitCodeThread? As an example I want to retrieve a 64bit pointer or even a struct (or a 64bit pointer to one) as a result of this function. What would be a correct way of doing it? And if it's ReadProcessMemory - then which memory address/offset should I read for a return value?
Edit: additional info:
I'm calling a function inside an injected DLL. The function executes some stuff (e.g. collection of data from the process it's injected into, which is successful) - the problem is I want to retrieve one of those variables back into the calling process (the one that calls CreateRemoteThread). GetExitCodeThread is a no go because variables are 64 bit.
code snippet for reference (hExportThread function returns uint64_t in DLL):
// LLAddr = LoadLibraryA address, lpBaseAddr = dll path related argument
HANDLE hInjectionThread = CreateRemoteThread(hProc, NULL, NULL, LLAddr, lpBaseAddr, NULL, &idThread);
WaitForSingleObject(hInjectionThread, INFINITE);
dllBaseAddr = getDLLBaseAddr(); // gets base address of the injected DLL
dllExportOffset = getDLLExportOffset(dllExportName.c_str()); // opens the DLL in the local buffer and gets the correct offset
LPTHREAD_START_ROUTINE lpNewThread = LPTHREAD_START_ROUTINE(dllBaseAddr + dllExportOffset); // gets the correct address of the function in the injected dll
HANDLE hExportThread = CreateRemoteThread(hProc, NULL, NULL, lpNewThread, NULL, NULL, 0); // executes injected function
WaitForSingleObject(hExportThread, INFINITE);
I suggest that you use a shared memory region, have it open in both the injecting process and the injected DLL. When the injected library finishes you know that the memory should be ready.
Doing this, you aren't limited to 4 or 8 bytes, you can make the region of whatever size is needed to return the collected data.
One option would be, rather than asking the remote thread to execute the target DLL function directly, you can have the injector use VirtualAllocEx() to allocate a small block of executable memory in the remote process, and then use WriteProcessMemory() to fill that block with a minimum set of Assembly instructions needed to call the target DLL function and save its result to a memory location where the injector can then access the data from. That could be a block of shared memory, or a block of VirtualAllocEx-ed memory that you read with ReadProcessMemory().
Or, if you are allowed to change the signature of your target DLL function, then have it take a pointer to a local memory address where it can write its output to, and then the injector can VirtualAllocEx() a block of read/write memory and pass its address in the lpParameter parameter of CreateRemoteThread(), and then ReadProcessMemory()` from that address after the thread exits.
Otherwise, rather than setting all of this up manually at the call site where you launch the remote thread, it would be easier if you wrapped the target DLL function in another DLL function that did this work in plain C++ instead of in Assembly. And then you can have the remote thread call that wrapper function instead.
I have a DLL that I inject into another process but I want to be able to call the exports on that DLL from my application. I've read elsewhere that you have to the SendMessage API but I have no idea what to do. Is there any example code on how this is done?
While it is not possible to directly call a function in another process, you can do it indirectly pretty easily with a few steps and the Windows API.
Get the addresses of LoadLibrary and GetProcAddress from your own process. kernel32.dll should be loaded at the same address in every process, so you can rely on them being present in the process into which you are injecting
Create a struct that will hold all the arguments you want to pass to your function that will call the functions in the other process (because CreateRemoteThread can only pass one argument to a function, so we'll use it to pass a pointer to the structure) which at least contains member function pointers to hold the addresses of LoadLibrary and GetProcAddress
Allocate enough memory for a struct in the remote process via VirtualAllocEx, then fill it with the correct information with WriteProcessMemory
Write a function, taking a pointer to the struct you wrote, that uses LoadLibrary/GetProcAddress to call the function you want. Remember to use the pointers to those functions in the struct you are passing the function, not the names.
Allocate enough memory in the remote process to hold the function with VirtualAllocEx, making sure to pass VAX the PAGE_EXECUTE_READWRITE flag so that it can hold executable code
Read and write the function's code from your process to the other process via Read/WriteProcessMemory
Call the function in the remote process (which is at the address returned by the VirtualAllocEx) by using CreateRemoteThread.
Make sure that all the data you pass to the function is either stored inside the struct and/or resides in the remote process's address space (get it there with VirtualAllocEx/WriteProcessMemory.
It may look a little involved, but it's not really that complicated. If you need some help with it, feel free to ask in a comment.
You can't directly call functions in another process, in general. There are, however, some workarounds you can use.
First, if you know the address of the export (which isn't the case a lot of the time), and the function you call uses the __stdcall calling convention, takes a pointer-sized integer as an argument, and returns a DWORD, you can use CreateRemoteThread to execute it in a thread in the remote process. This is often used to run LoadLibrary to inject a DLL into a target process, since LoadLibrary is loaded in the same address on all processes on a given computer.
Otherwise, the DLL you inject will need to do some sort of RPC with the process that called it. For example, you could have your injected DLL spawn a thread in its DLL_PROCESS_ATTACH handler, which in turn connects to a named pipe, or connects over COM or something to the master process.
SendMessage would need a window handle (hidden or visible), and a message-pump associated with it, that can handle the custom message. As with UAC/Windows-7, the integrity levels of applications may prevent other applications to send/post messages from other processes having low integrity.
It is better to have another thread that waits for these custom messages. For this, you may use pipes (named or unnamed), sockets, mail-slots, shared memory (along with mutex/event for triggering). The another processes would send the message using same protocol.
But before implementing this custom messaging/protocol/IPC mechanism, I suggest you to first determine the exact need.
When you have a base class in your main executable and subclasses (say, plugins) defined in DLLs, what happens when you want to get a plugin?
I am looking for an article/answer that'd clarify what happens when you
load a DLL
call a DLL's function that returns a plugin* (it has virtual functions)
use that plugin in your main executable's code
delete, unload
I am thinking about the vtable and other C++ issues. For instance, if you unload the DLL stil having some plugins running... The "code" will be gone?
Since you are talking about plugins, you must be doing something like LoadLibrary. Assuming Windows:
Load a library. You would normally call LoadLibrary followed by GetProcAddress. The DLL is loaded into the process address space and you have the pointer to the function exposed.
Call a DLL's function that returns a plugin* (it has virtual functions). You would cast a the return value from GetProcAddress to the function pointer type, and call it. Everything should work as normal.
Use that plugin in your main executable's code. There is nothing special.
Delete the plugin. I assume you use a function in the DLL to do so, and it should be fine. Directly calling delete can be dangerous, as the DLL may have a separate memory manager (depending on what runtime you use).
Unload the DLL. You call FreeLibrary, and the code is gone. The pointers you previously get from GetProcAddress become invalid.
I am not aware specific vtable issues. If you unload the DLL while the code is still running, I would assume the program will crash at this point, as the code address space becomes invalid.
I have a DLL that I inject into another process but I want to be able to call the exports on that DLL from my application. I've read elsewhere that you have to the SendMessage API but I have no idea what to do. Is there any example code on how this is done?
While it is not possible to directly call a function in another process, you can do it indirectly pretty easily with a few steps and the Windows API.
Get the addresses of LoadLibrary and GetProcAddress from your own process. kernel32.dll should be loaded at the same address in every process, so you can rely on them being present in the process into which you are injecting
Create a struct that will hold all the arguments you want to pass to your function that will call the functions in the other process (because CreateRemoteThread can only pass one argument to a function, so we'll use it to pass a pointer to the structure) which at least contains member function pointers to hold the addresses of LoadLibrary and GetProcAddress
Allocate enough memory for a struct in the remote process via VirtualAllocEx, then fill it with the correct information with WriteProcessMemory
Write a function, taking a pointer to the struct you wrote, that uses LoadLibrary/GetProcAddress to call the function you want. Remember to use the pointers to those functions in the struct you are passing the function, not the names.
Allocate enough memory in the remote process to hold the function with VirtualAllocEx, making sure to pass VAX the PAGE_EXECUTE_READWRITE flag so that it can hold executable code
Read and write the function's code from your process to the other process via Read/WriteProcessMemory
Call the function in the remote process (which is at the address returned by the VirtualAllocEx) by using CreateRemoteThread.
Make sure that all the data you pass to the function is either stored inside the struct and/or resides in the remote process's address space (get it there with VirtualAllocEx/WriteProcessMemory.
It may look a little involved, but it's not really that complicated. If you need some help with it, feel free to ask in a comment.
You can't directly call functions in another process, in general. There are, however, some workarounds you can use.
First, if you know the address of the export (which isn't the case a lot of the time), and the function you call uses the __stdcall calling convention, takes a pointer-sized integer as an argument, and returns a DWORD, you can use CreateRemoteThread to execute it in a thread in the remote process. This is often used to run LoadLibrary to inject a DLL into a target process, since LoadLibrary is loaded in the same address on all processes on a given computer.
Otherwise, the DLL you inject will need to do some sort of RPC with the process that called it. For example, you could have your injected DLL spawn a thread in its DLL_PROCESS_ATTACH handler, which in turn connects to a named pipe, or connects over COM or something to the master process.
SendMessage would need a window handle (hidden or visible), and a message-pump associated with it, that can handle the custom message. As with UAC/Windows-7, the integrity levels of applications may prevent other applications to send/post messages from other processes having low integrity.
It is better to have another thread that waits for these custom messages. For this, you may use pipes (named or unnamed), sockets, mail-slots, shared memory (along with mutex/event for triggering). The another processes would send the message using same protocol.
But before implementing this custom messaging/protocol/IPC mechanism, I suggest you to first determine the exact need.
Alright, I'm injecting some code into another process using the CreateRemoteThread/LoadLibrary "trick".
I end up with a thread id, and a process with a DLL of my choice spinning up. At least in theory, the DLL does nothing at the moment so verifying this is a little tricky. For the time being I'm willing to accept it on faith alone. Besides, this question needs to be answered before I push to hard in this direction.
Basically, you can't block in DllMain. However, all I've got to communicate with the remote thread is its id. This practically begs for PostThreadMessage/GetMessage shenanigans which block. I could spin up another thread in DllMain, but I have no way of communicating its id back to the creating thread and no way of passing the another thread's id to the remote one.
In a nutshell, if I'm creating a remote thread in a process how should I be communicating with the original process?
Step zero; the injected DLL should have an entry point, lets call it Init() that takes a LPCWSTR as its single parameter and returns an int; i.e. the same signature as LoadLibrary() and therefore equally valid as a thread start function address...
Step one; inject using load library and a remote thread. Do nothing clever in the injected DLLs DLLMain(). Store the HMODULE that is returned as the exit code of the injecting thread, this is the HMODULE of the injected DLL and the return value of LoadLibrary().
Note that this is no longer a reliable approach on x64 if /DYNAMICBASE and ASLR (Address space layout randomisation) is enabled as the HMODULE on x64 is larger than the DWORD value returned from GetThreadExitCode() and the address space changes mean that it's no longer as likely that the HMODULE's value is small enough to fit into the DWORD. See the comments below and the linked question (here) for a work around using shared memory to communicate the HMODULE
Step two; load the injected DLL using LoadLibrary into the process that is doing the injecting. Then find the offset of your Init() entrypoint in your address space and subtract from it the HMODULE of your injected DLL in your address space. You now have the relative offset of the Init() function. Take the HMODULE of the injected DLL in the target process (i.e. the value you saved in step one) and add the relative address of Init() to it. You now have the address of Init() in your target process.
Step three; call Init() in the target process using the same 'remote thread' approach that you used to call LoadLibrary(). You can pass a string to the Init() call, this can be anything you fancy.
What I tend to do is pass a unique string key that I use as part of a named pipe name. The Injected DLL and the injecting process now both know the name of a named pipe and you can communicate between them. The Init() function isn't DLLMain() and doesn't suffer from the restrictions that affect DLLMain() (as it's not called from within LoadLibrary, etc) and so you can do normal stuff in it. Once the injected DLL and the injecting process are connected via a named pipe you can pass commands and data results back and forth as you like. Since you pass the Init() function a string you can make sure that the named pipe is unique for this particular instance of your injecting process and this particular injected DLL which means you can run multiple instances of the injecting process at the same time and each process can inject into multiple target processes and all of these communication channels are unique and controllable.
You don't have the thread id of a thread in the remote process, because the one you used to load the dll exited when your module was successfully loaded into the address space of your process.
You can easily use the normal interprocess communication methods like named sections/pipes/creating a named window/etc. to communicate with your 'injecting' process.