This is about DLL injection.
Let's say P.exe depends on A.dll, B.dll and C.dll (implicit linking), they're private modules of P.exe.
Now I use CreateProcess with CREATE_SUSPENDED flag to launch P.exe, after that I use CreateRemoteThread to call LoadLibrary in target process to load Inject.dll, and in the same way call an initialize function of Inject.dll to do real work (things you can't do in DLLMain).
It works. But I found that calling to LoadLibrary makes A.dll, B.dll and C.dll load too - not just Inject.dll. From the Output of Visual Studio, they even load before Inject.dll, this is not what I want. You know, Inject.dll does not depend on any third-party DLLs, in fact it just depends on kernel32.dll and user32.dll.
In this case, how to load only Inject.dll ?
Related
It is now well known how to make interface call to a DLL-implemented COM object in the registration-free environment. The question is the opposite:
How to make interface call from a DLL to a COM object implemented in EXE? Which manifests and which manifest sections should be used?
EDIT: May be it was not quite clear, but I meant in-process call. I want to call an object in the same process, but implemented in EXE rather than in DLL.
EDIT2: OK, I see things goes complicated, so I must explain the original problem. A C++ application implements IApplication interface and keeps pointer to it as a member. This member is returned by a public method accessible from anywhere by means of AfxGetApp().
There is also a mechanism allowing any customer to add his own C# "plugin" DLLs to our application. For such DLLs the IApplication interface is a key access point to the application's features. But these DLLs have no access to the main application's object.
To solve the problem, I added an auxiliary "ICreateApplication" object, which returns the original IApplication pointer. Any "plugin" DLL may create this auxiliary object and obtain from it the required interface. I implemented this object in some arbitrarily chosen DLL, and equipped it with necessary manifests.
This solution works well, but this "arbitrary choice" bothers me. I wonder, is there a possibility to implement "ICreateApplication" in the application object?
I want to load special dll without execute dllmain function.
I think, set a breakpoint at dllmain can solve this problem.
But I don't know How can I do?
Also I want call dll's export function.
I have tried to use LoadLibraryEx with dont_resolve_dll_references, but it occurs error with dll's function call.
How can I solve this? Please give me your idea.
Thanks.
As explained in this question: Win32 API to enumerate dll export functions?
You can use LoadLibraryEx with the DONT_RESOLVE_DLL_REFERENCES flag, even though use of that flag is strongly discouraged.
If so you will likely have to free and reload the dll if you actually want to use it.
Well as explained here:
An optional entry point into a dynamic-link library (DLL). When the system starts or terminates a process or thread, it calls the entry-point function for each loaded DLL using the first thread of the process. The system also calls the entry-point function for a DLL when it is loaded or unloaded using the LoadLibrary and FreeLibrary functions.
calling the DllMain is an OS feature mandatory (although implementing that function is optional) if you use the standard way in loading and executing a dynamic library. So there is no official way in doing this.
I have a dll say "A.dll" which exports a function "int foo()". I have another dll say "B.dll" which consumes A.dll and uses the function foo() and also exports some other functions. Is it possible to export the function "int foo()" (imported from A.dll) from B.dll so that it can be consumed in a third dll "C.dll".
I want to know whether it is possible or not, I dont want workarounds like making A.dll available to the third dll. Also, I am not concerned if this is a bad design or not.
Thanks very much for your patience to read this through.
Kapil.
As soon as A.dll exports one function, this function will be available to any application (like B.dll uses it). C.dll will also be capable to import the exported functions from A.dll. Additionally, you might take the so called "Export Forwarding" (see URL) mechanism which enables one to export functions from B.dll and implemented these in A.dll (like \system32\sfc.dll exports functions that are forwarded to \system32\sfc_os.dll)
It can be used to run arbitary Dynamic Link Library in windows,
how can it possibly know the entry point of an arbitary dll?
The answer depends on how much details you need. Basically, it comes down to this:
A DLL can optionally specify an entry-point function. If present, the system calls the entry-point function whenever a process or thread loads or unloads the DLL.
[...] If you are providing your own entry-point, see the DllMain function. The name DllMain is a placeholder for a user-defined function. You must specify the actual name you use when you build your DLL.
(Taken from the MSDN article Dynamic-Link Library Entry-Point Function.)
So basically, the entry point can be specified inside the DLL, and the operating system's DLL loader knows how to look this up.
The IMAGE_OPTIONAL_HEADER (part of the portable executable's header on Windows machines) contains an RVA of the AddressOfEntryPoint that is called by programs looking for an entry point to call (e.g., the loader).
More information on the IMAGE_OPTIONAL_HEADER can be found here. And this paper is good for just general PE knowledge.
What do you mean by "run a DLL"? DLLs aren't normal programs, they are just a collection of functions. The entry point itself usually doesn't do much apart from initializing stuff required by other functions in the DLL. The entry point is automatically called when the DLL is loaded (you can use LoadLibrary to do this).
If you want to call a specific function after loading the DLL, you can use GetProcAddress to get a pointer to the function you want.
Is it possible for a function that is inside a DLL to unload the DLL? I need to do this so I can make sure the DLL is not in use, then write to the DLL's file.
As I understand it, it CAN be done and is MEANT to be done sometimes (for example in case of dll injection by CreateRemoteThread and other methods). So,
FreeLibraryAndExitThread(hModule, 0)
will do precisely that.
On the other hand, calling
FreeLibrary(hModule)
will not do here - from MSDN: "If they were to call FreeLibrary and ExitThread separately, a race condition would exist. The library could be unloaded before ExitThread is called." As a remark, ExitThread does some bookkeeping besides just returning from the thread function.
All this assumes that Your Dll obtained the hModule itself by calling LoadLibrary from inside the loaded Dll, or rather, by calling from inside the loaded Dll the following function:
GetModuleHandleEx
(
GET_MODULE_HANDLE_EX_FLAG_FROM_ADDRESS,
(LPCTSTR)DllMain,
&hModule
)
This increments the reference count of the Dll so You know that if You free the library later using that handle and if the library is really unloaded then You had the last reference to it.
If You instead skip incrementing the Dll's reference count and obtain the hModule just from the argument to DllMain during DLL_PROCESS_ATTACH then You should not call FreeLibraryAndExitThread since the code that loaded the Dll is still using it and this module handle really isn't Yours to manage.
Use this when the dll has done it job:
CreateThread(NULL, 0, (LPTHREAD_START_ROUTINE)FreeLibrary, &__ImageBase, 0, NULL);
// terminate if dll run in a separate thread ExitThread(0);
// or just return out the dll
And the __ImageBase is your dll's PE header structure:
EXTERN_C IMAGE_DOS_HEADER __ImageBase;
If your asking if you can safely unload/unmap a DLL loaded in a process from code in the DLL itself, the answer is no - there isn't really a safe way to do this.
Think about it this way: Unloading a DLL is done by decrementing it's reference count using FreeLibrary(). The problem of course is that once the reference count of the DLL hits zero, the module is unmapped. Which means that the code in the DLL that called FreeLibrary() is gone.
Even if you could do this, you'd still need to ensure that there are no other threads executing any exported functions from the DLL.
I don't think it will work. Calling FreeLibrary with a handle from the outside (LoadLibrary would have been called from an area outside the DLL) as the code runs in a memory location that will not be valid anymore.
Even if this is possible, it smells like a bad design. Maybe you want to make some updater or alike. Explain a bit more what is the result you expect. Unloading a DLL from within itself is not the way to go.