问题目前仅涉及窗口 - 其他操作系统现在还不相关。
仅通过快速搜索 - 可以从RAM加载本机.dll，例如以下库：
https://www.joachim-bauch.de/tutorials/loading-a-dll-from-memory/
=＆gt;
https://github.com/fancycode/memorymorymodule
https://forum.nim-lang.org/t/7943 ，
但所有这些都需要：
- PE文件格式的信息知识
- 这些方法通常不友好。
我已经检查的内容 - Windows的 loadLibrarya / loadLibraryw 被定向到 ntdll.dll.dll/ldrloaddll - 以及从中可以从中找到工作方式的最佳图片这里： https://github.com/hlldz/reflexxion
，即使我也没有Windows Windows源代码 - 我已经从葡萄酒中检查了相同的功能：
ldrloaddll：
load_dll： https://source.winehq.org/source/dlls/dlls/ntdlls/loadll/loader.c#3083
load_native_dll：load_native_dll：
https://source.winehq.org/source/source/source/dlls/ntdll/ loader.c＃2564
ntmapviewofsection：
find_dll_file： https://source.winehq.org/source/dlls/dlls/ntdlls/loadls/loader.c#3021
open_dll_file： https://source.winehq.org/source/source/dlls/dlls/loadlls/loader.c#2467
怀疑加载dll发生通过以下函数调用：
ntopenfile ， ntqueryAttributesFile ， ntcreatEsection / ntopensection ， ntmapviewfofsection （*）
（更多信息可以在
https://github.com/hagrid29/peloader
//gist.github.com/bats3c/59932dfa1f5bb23dd36071119b9b91af0f“ rel =” nofollow noreferrer“ ：
//www.octawian.ro /fisiere/situri/asor/build/html/_downloads/122F95F9A032396603A837C53B125BBB8/RUSSINOVICH_M_WINININENTERT1_PART1_PART1_PART1_PART1_7TH_7TH_ED.PDF /situri/asor/build/html/_downloads/122F95F9A032396603A837C53B125BB8/ russinovich_m_wininternals_part1_7th_ed.pdf
）
我还在想我是否可以覆盖 ntopenfile ，然后重定向文件打开（在
https://github.com/segararai/patharai/pathrai/pathredirector 方式）
到不同的路径 - 但是主要问题是在哪里存储文件的替代位置？
我在想ntopenfile是否可以打开设备，也许只需替换文件
使用某种命名的管道（ https：// .microsoft.com/en-us/windows/winw32/ipc/命名 - pipe-client ） - 但随后在地图上，与Ntmapviewofsection一起使用。
由于我找不到此类钩或操作的任何工作示例（例如 loadlibary（“ \\。 。
是否可以纯粹是从RAM加载本机.dll：
- 不使用文件系统（不存储.dll，例如在临时文件夹中），
- 而无需涉及自定义驱动程序（例如Dokan）？
- 因此，装载.dll仍然很友好吗？
- 请不要与PE文件格式结构紧密绑定（或尽可能少地使用PE结构），
如果错过更多信息，
还要检查我自己的本机DLL加载的实验（也许可以给出解决问题的一些提示）： https://github.com/tapika/test_native_dlly_dll_loading
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
发布评论
评论（4）
区分调试和释放用例。在调试中，将DLL保存在临时文件中，然后加载加载LoadLibrary，这将启用调试。在发行中，从内存运行，没有调试功能。
这是考虑链接的Guthub问题的另一个想法。如果目的是让用户在构建ReadyTorun可执行文件时提供自己的压缩/减压逻辑，则将其提供为A static 库（对象）而不是DLL。较大的项目已经是将包装物品包装到一个可执行文件中，可能会在其中进行一些链接。
另一个想法是让用户以某种解释的语言提供编解码器，并选择插入支持调试的解释器。 Windows带有内置的JavaScript解释器，查找主动脚本，并调试这些脚本是免费的奖励。但是，性能可能不会与本机代码实现相提并论。
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.
我认为您可能会与Frida做类似的事情。将功能载荷LoadLibrarya / loadLibraryw钩住，然后在Frida中重新成真。但是我不认为这是生产稳定的东西。
以获取一些参考
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
通过分析现有方法（例如
pe loader）和使用minhook库 - 我已经设法从RAM加载.dll。我已经在github上使用示例代码创建了git存储库：
htttps://github.com/tapika/tapika/dllloader
By analyzing existing approaches (like
PE Loaderhttps://github.com/Hagrid29/PELoader) and usingminhooklibrary - I've managed to load.dllfrom RAM.I've created git repository with example code on github:
https://github.com/tapika/dllloader
您可以创建一个将您的DLL放在那里的Ramdisk吗？这到底是什么用例？例如，有几种方法可以在RAM中旋转文件，例如C＃的Memory映射文件。我不确定这是否会友好。
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.