Is there a way to load all functions from runtime loaded DLL? Current code:
hGetProcIDDLL = LoadLibrary(dll);
typedef int(*f_connection_a)(args);
typedef int(*f_connection_b)(args);
typedef int(*f_connection_c)(args);
f_connection_a connection_a = (f_connection_a)GetProcAddress(hGetProcIDDLL, "connection_a");
f_connection_b connection_b = (f_connection_b)GetProcAddress(hGetProcIDDLL, "connection_b");
f_connection_c connection_c = (f_connection_c)GetProcAddress(hGetProcIDDLL, "connection_c");
As you can see, this gets cumbersome quickly as you have to define every DLL function like this. Is there a way to load all DLL functions instead of having to list them?
Since here the "connection_*" are only a variables, there is no way to initialize them other than to run a code such as calling a function to get an address of a function. WinAPI doesn't have bulk method for binding functions at run time. This is limitation of WinAPI. The intention of this method was to check the presence of a functions individually and to delay loading library up to the point when it will actually be needed (or to avoid loading at all if it is not used).
But you can avoid such messy code by binding DLL at program loading stage using Import Table feature. In this case Windows loads executable image into memory, then loads all dependent DLLs and automatically binds the imported functions before launching executable code. For this you need:
Prepare *.def file for the library you need to load. The simplest method is to launch "impdef.exe my.dll" command on dll file. You may find tiny impdef.exe that doesn't need installation in TinyC package (see https://bellard.org/tcc/).
Then prepare corresponding *.lib file by launching "lib /def:my.def /out:my.lib"
After that link produced library with your project as regular library.
The drawback of this method is that if DLL is absent or corrupted, your executable file won't start at all. But this is a small payment for the convenience of importing functions.
Related
I have a C++ application that implements external user written "Apps" as DLLs. My plan to implement this is by loading dlls in a specific directory and starting a new thread for each DLL. Each DLL has its own "main" that is just an exported function __dllspec(dllexport).
I basically treat DLLs that use this API as a poormans executable (no virtual address space, less secure, its just a thread instead of a seperate process etc)
The main loader code basically calls the "main" function in the DLL while maintaining the list of loaded DLL handles.
Also I'd like these Apps to draw to a dedicated space provided by the main loader. I would provide this ability via a UI API provided by the loader exposed by requiring Apps to dllimport the required functionality.
My question is, is there another way to implement this app like functionality where "Apps" can be removed or added during runtime?
The question below is for educational purposes only and the discussed featured are not meant to alter registered DLLs or develop a malware but for learning and experiencing.
Recently I've been exploring few methods to load my own custom DLLs instead of an application's original DLLs.
One of the methods that came up was the <exe>.local method.
After experiencing with this method a little bit and after I removed the KnownDlls entry from the registry I managed to replace some system DLLs with my patched DLLs successfully.
These are the DLLs:
However, the DLLs are IN the local folder:
However, there are still some DLLs that insist loading from the system32 directory, although they are present in the local folder.
Is there any way I can force the DLL's to load from the local folder instead of the system32 folder?
This is not an answer so much as a rambling, unsourced, brain dump.
It does serve to explain why I am not surprised at your result. This boils down, for me, to the crucial difference between CreateProcess and LoadLibrary, and how Win32 processes work.
Normally, when using LoadLibrary, you are using it from within the process you want the dll to be loaded into. As such, it can take advantage of a whole bunch of in-process context information about activation contexts, dll search paths etc. including knowledge of things like the app.local flag.
All these values are specific to the current process and it is not the job of any other process (or even the Kernel) to track stuff like this.
But, if we look at CreateProcess we can see some problems. When it is initially called, it is called in the context of the launching, not destination, process, so it knows nothing of the destination processes activation context. In fact, the destination process does not exist yet.
The CreateProcess implementation needs to create a NT process, and execute some code in it asap to perform the process load as it doesn't make any sense to instantiate all that per process context stuff in the current process.
But, to do that, there needs to be at least some code in the destination process: The kernel code responsible for parsing the EXE files header, extracting the headers and building the activation contexts that will be used to load the remaining dlls.
This means that, unfortunately for you, kernel32.dll and some dependencies need to be mapped into a process long before that process is capable of building a dll search context, noticing the app.local flag etc.
You should look at how the Windows loader works. This is OS version dependent, but some of those DLLs load before your program and the loader always looks for them on a path provided by the system. Look at the sequence by starting your program with WinDbg.
I am currently writing an application and I want to make it as extensive as possible for me -> every component should be considered as an extension except core functionality.
Basically I provide abstract class which needs to be implemented (header file) and a static library. Also I provide .py file with abstract class and example of .component file which is basically .ini file - there user should declare what's the class_name, python_class_name and etc.
So in the end user need to create DLL, python script, .ini file. Then zip into an archive with extension package. Well that's the plan.
My application is supposed to look for .package file, unzip it, get from there .component file, read it, load class from DLL by name, create object and store it in global object register inside application. Then I create c++ and python bridge (knowing what interface is implemented by python class helps a lot) which allows to invoke python methods by name. That python script should be store into zip too.
I've got basically two questions:
1. Is it possible to load DLL from `.zip` in runtime? I believe its hardly possible without creating temporary unzipped file and then deleting it.
2. Is there other to load DLL except basic approach with `windows.h` header? I use `boost` library there and there, maybe there is some way to do it?
For zipping as far as I know there no better solution then using zlib so I am planning to use that.
It is possible to load DLL from zip/memory. Actually many exe packers/virus do load the dll manually.
It is actually the same question of the first question.
What LoadLibrary does?
Mapping or loading the DLL into memory.
Relocating offsets in the DLL using the relocating table of the DLL (if present).
Resolving the dependencies of the DLL, loading other DLLs needed by this DLL and resolving the offset of the needed functions.
Calling its entrypoint (if present) with the DLL_PROCESS_ATTACH parameter.
You could write your own code to load the library manually. However, if you do not load the dll the same way as LoadLibrary does, there could be some limitations.
refer: http://www.codeproject.com/Tips/430684/Loading-Win-DLLs-manually-without-LoadLibrary
You can load .dll library from memory, at least with trivial .dll without more dependency.
What you do is to emulate what LoadLibrary do. Parse the PE executable yourself, call VirtualAlloc, setup proper page attributes, copy the payload, do relocations, and lookup the symbols.
A quick search reveal a detail yet simple tutorial here.
Note that this may also upset certain virus scanner.
What I've seen so far, there can only be one plugin per .dll file, is that correct? The Browser calls NP_GetEntryPoints, NP_Initialize and NP_Shutdown only "once" per dll, right?
What I'm aiming for is to create multiple plugins in one dynamic library. Is that possible, and if, how?
What I've seen so far, there can only be one plugin per .dll file, is that correct?
No, you can have multiple plugins implemented in one DLL.
The Browser calls NP_GetEntryPoints, NP_Initialize and NP_Shutdown only "once" per dll, right?
Only once per process and loading (keep in mind that it will be unloaded while when no instance is alive anymore).
What I'm aiming for is to create multiple plugins in one dynamic library. Is that possible, and if, how?
It's possible. You just register the different mimetypes for the same dynamic library (e.g. on Windows several mimetype entries in the registry pointing to the same DLL).
NPP_New() gets a NPMIMEType as it's first parameter, which let's you identify which "plugin" was requested.
Also, NP_GetMIMEDescription() needs to be adjusted (used on Linux and Mac OS).
On Windows you should have the list of mimetypes, seperated by |, in the version info (entry MIMEType).
Sometimes, I read the source code, found that the module is loaded manually like below.
HMODULE hmodMscoree = LoadLibraryEx(L"mscoree.dll", NULL, 0);
typedef HRESULT (STDAPICALLTYPE *GETCORVERSION)(LPWSTR szBuffer, DWORD cchBuffer, DWORD* dwLength);
GETCORVERSION pfnGETCORVERSION = (GETCORVERSION)GetProcAddress(hmodMscoree, "GetCORVersion");
Why does it load the mscoree.dll at runtime?
Best Regards,
One advantage is that if you load a DLL dynamically, then the presence of a DLL (e.g. mscoree.dll), and the presence of a function in the DLL (e.g. GetCORVersion in mscoree.dll) will be checked only when the application tries to load the DLL and call the function, respectively. If the DLL is missing, or one of its function is missing because you only have an older version, then there won't be any problem in cases when the application does not use this functionality. On the contrary, if the DLL is statically linked, and it is missing, then the application simply won't start (you will get an error message).
Example: we have a complex industrial measurement software, which links wpcap.dll dynamically. In cases when the measurement does not include packet sniffing, we do not have to install WinPcap.
One reason for loading a module and using GetProcAddress is that the DLL may not be present on the computer. That way the application can run even if the DLL is not there. You would of course need to verify that both LoadLibrary and GetProcAddress were successful.