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.
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?
Question concerns only Windows for now - other OS's are not so relevant right now.
Just by quick googling - it's possible to load native .dll from RAM, there are for example following libraries:
https://www.joachim-bauch.de/tutorials/loading-a-dll-from-memory/
=>
https://github.com/fancycode/MemoryModule
https://forum.nim-lang.org/t/7943
But all of them requires:
in-depth knowledge of PE file format
mostly those approaches are not debugger friendly.
What I have checked - windows's LoadLibraryA / LoadLibraryW are directed to ntdll.dll / LdrLoadDll - and best picture of how things works can be found from here: https://github.com/hlldz/RefleXXion
And even thus I don't have windows source code - I've checked same functionality from Wine:
LdrLoadDll: https://source.winehq.org/source/dlls/ntdll/loader.c#3169
load_dll: https://source.winehq.org/source/dlls/ntdll/loader.c#3083
load_native_dll:
https://source.winehq.org/source/dlls/ntdll/loader.c#2564
NtMapViewOfSection: https://source.winehq.org/source/dlls/ntdll/unix/virtual.c#4469
find_dll_file: https://source.winehq.org/source/dlls/ntdll/loader.c#3021
open_dll_file: https://source.winehq.org/source/dlls/ntdll/loader.c#2467
Suspect loading dll happens via following function calls:
NtOpenFile, NtQueryAttributesFile, NtCreateSection/NtOpenSection, NtMapViewOfSection (*)
(More information could be found in
https://github.com/Hagrid29/PELoader
https://gist.github.com/bats3c/59932dfa1f5bb23dd36071119b91af0f
https://www.octawian.ro/fisiere/situri/asor/build/html/_downloads/122f95f9a032396603a837c53b125bb8/Russinovich_M_WinInternals_part1_7th_ed.pdf
)
I was also thinking if I could just override NtOpenFile and just redirect file open (in
https://github.com/SegaraRai/PathRedirector manner)
to different path - but main question what is the alternative location where to store file?
I was thinking if NtOpenFile can open even device, then maybe just replace file
with some sort of named pipe (https://learn.microsoft.com/en-us/windows/win32/ipc/named-pipe-client) - but then in maps on how well this will work with NtMapViewOfSection.
Since I was not able to find any working example of such hook or operation (E.g. LoadLibary("\\.\pipe\mynamedpipe_as_dll")) - there is always a risk that such combination is not simply supported.
Is it possible to load native .dll purely from RAM:
Without using file system (not to store .dll e.g. in temporary folder)
Without involving custom drivers (like Dokan) ?
So loaded .dll would be still debugger friendly ?
Not tightly bound to PE file format structures (or use PE structures as less as possible)
If you miss bit more information, check also my own experiments with native dll loading (maybe can give some hints on solving the issue):
https://github.com/tapika/test_native_dll_loading
https://github.com/tapika/test_native_dll_loading/discussions/2
Distinguish between debug and release use cases. In debug, save the DLL in a temp file and load with LoadLibrary, which will enable debugging. In release, run from memory with no capability for debugging.
Here's another idea, from considering the linked Guthub issue. If the purpose is to let the users provide their own compression/decompression logic while building a ReadyToRun executable, let them provide that as a static library (object) as opposed to a DLL. The larger project is already about packaging stuff into a single executable, might do some linking while at it.
Yet another idea would be to let the users provide the codec in some kind of interpreted language and optionally plug in the interpreter that supports debugging. Windows comes with a built-in JavaScript interpreter, look up Active Scripting, and debugging those is a free bonus. The performance probably won't be on par with a native code implementation, though.
I think you could probably do something similar with Frida. Hook the functions LoadLibraryA / LoadLibraryW and reimplement them in Frida. but I don't believe this is something that would be stable for production.
For some reference
By analyzing existing approaches (like PE Loader https://github.com/Hagrid29/PELoader) and using minhook library - I've managed to load .dll from RAM.
I've created git repository with example code on github:
https://github.com/tapika/dllloader
Could you create a ramdisk to put your DLL there? What exactly is the use-case for this? There are a couple ways to spin up a file in RAM, C#'s MemoryMappedFile for example. I'm not sure if this would be debugger friendly.
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.
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.
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).