Initial git repo

[tapika]

1. Problem statement

I would like to document so far what I have found, just in case someone else continues this work or invents alternative approach.

Discussion started from this ticket: dotnet/runtime#61073

(Cross posted question to stackoverflow: https://stackoverflow.com/questions/72248319/load-native-c-dll-from-ram-in-debugger-friendly-manner - just to give some hints if there are alternative approaches)

And main problem as I understand it - is to be able to load native (C++) dll's into ram without using file system for this purpose.

Why to avoid file system - I guess there could be several reasons behind it - and one of most commonly known problem is different set of antiviruses making native dll loading more complex. Antivirus might detect any dll as virus itself (false alarm) and prevent whole application from launching.

Like also mentioned in the ticket - there already exists multiple ways to load .dll into ram, but most of them involve PE manual file parsing:

https://www.joachim-bauch.de/tutorials/loading-a-dll-from-memory/
=> https://github.com/fancycode/MemoryModule
https://forum.nim-lang.org/t/7943

That method even thus it would work - is not possible to use with debugging and requires a lot of internal knowledge on PE file format. Even thus Microsoft itself could figure out the details further and add debugging support of such .dll's - loading logic is different than what is happening currently in LoadLibrary and subsequent calls in Windows kernel.

How native .dll loading happens in all details - that is not known to me, but there are various articles, forum messages, tools which are more or less relate to the problem of .dll loading in one way or another. I'll try to collect all relevant links in here as well.

[tapika]

2. How LoadLibrary works ?

If you would like to understand how native .dll loading works - maybe best way to check documentation in
https://github.com/hlldz/RefleXXion

or same via Wine Source codes:

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
NtCreateSection: https://source.winehq.org/source/dlls/ntdll/unix/sync.c#1940
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

With Wine - the main problem is that it's Windows emulator for Linux, and not actual windows code. You can check the code, but it does not necessarily reflect on how dll loading works.

[tapika]

3. LoadLibrary: how to get new .dll entries ?

Using minhook library I have intercepted some of loading library function calls, like LdrLoadDll, NtOpenFile, NtCreateSection, NtMapViewOfSection.

When .dll loading does occurs - all of these functions gets called.

But if we embedd .dll into .exe - where to keep .dll binary ?

One approach is just clue it inside .exe. In theory we could just append .dll to .exe and load .dll from certain .exe's offset.

So by thinking this through - I've quickly coded tool inject_exe.

Then - the next question is how to "load" .dll so it would be seen as separate .dll entry (e.g. in process hacker), but not as main executable ?

We need to have some filename to invoke LoadLibrary("somename"). I've decided to try to hack somehow so I would be just have one dummy dll (dllstub) which eventually would be just copied as such somewhere in temp folder, and loaded to get new dll name differently.

In theory if we just create following copy sequence:

dllstub.dll  --> 1.dll
dllstub.dll  --> 2.dll

and then:

LoadLibrary("1.dll")
LoadLibrary("2.dll")

This however requires dllstub.dll presence in file system, which in a turn can be bitten by anti-virus. But if dll is simple (like dllstub.dll) - then there is less probability that antivirus will bite.

Also to avoid .dll loading completely - maybe it makes sense to have load dll from named pipe for example (https://docs.microsoft.com/en-us/windows/win32/ipc/named-pipe-client, A'la LoadLibary("\\.\pipe\mynamedpipe.dll")) - but this in a turn requires to check that LoadLibrary will work with devices instead of file system, or override necessary functions to help with that one.

My idea was - maybe just copying dllstub would be simpler approach.

[tapika]

4. Get loadable .dll contents into address space

First of all - I've got curious whether I can load .exe as .dll itself. So I just added a call LoadLibrary("...my.exe") - and that one worked out of box - but as a side effect NtOpenFile was not called at all. I've realized that .exe is loaded as a .dll already - so second call to LoadLibrary would in a turn just return .exe's handle. So now next - I needed to just clue .dll into .exe.

After merging .dll into .exe - first it was just .dll append to end of .exe file - I've noticed that .dll itself does not get loaded by exe.

.exe specified in a PE header how bit that one is , and everything I just appended at the end of executable - became just an overlay - garbage data which is ignored.

I've decided that maybe with PE files I need to work as PE file - meaning attach .dll to PE as a new data section.

I've used PeNet library and just appended .dll as a section instead.

See https://github.com/secana/PeNet.

That worked out well - in NtMapViewOfSection_detour (function which maps file to ram memory) - I was able to see .dll content at specific offset in ram (measured from .exe base address).

So I've just remapped .dll instead of .exe file. (See NtMapViewOfSection_detour)

After that LoadLibrary started to fail with error code: 0x1e7:
ERROR_INVALID_ADDRESS : Attempt to access invalid address.

One approach which I have tried as well - is to try to step out from NtMapViewOfSection_detour function and go a little bit deeper in assembly.

Most of ntdll.dll / kernel calls return NTSTATUS, which should have highest bit 0x80000000 bit set to indicate an error - otherwise it's just a "status code".

You can just put into watch window rax windows register and assume it will be NTSTATUS after some call operation.

And basically after call LdrpRelocateImage, rax would get value 0xc0000018 which according to documentation:

https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-erref/596a1078-e883-4972-9bbc-49e60bebca55

is some sort of conflicting address.

0xC0000018
STATUS_CONFLICTING_ADDRESSES

That is as far as I could go.

Without having ntdll source codes it's difficult to say what and why does not work.

I saw some logging code in ntdll - but have no clue on how to activate it. Maybe it could give more insight what is happening on loader level.

[tapika]

4.2 Get loadable .dll contents via CreateFileMapping

via CreateFileMapping it's possible to create shared memory, see global tryMemoryMapping in code - but using Global\MyFileMappingObject requires elevated rights to create such memory.

From kernel side it can be mapped via NtOpenFile_detour, but immediately after that in NtCreateSection_detour results in error STATUS_OBJECT_TYPE_MISMATCH / 0xc0000024.

Difficult so say whether NtOpenFile with NtOpenSection is a safe approach.

[tapika]

Tried also dump dll image after memory mapping function call (NtMapViewOfSection_detour) - and it looks like .dll's base address is modified at least (In my case it was as offset 0x132-0x135) - also section loading was performed already.

[tapika]

Some of PELoader functions use NtCreateSection manually to load specific dll. ULONG AllocationAttributes attributes of that function call can specify either SEC_COMMIT or SEC_IMAGE - and in case of SEC_IMAGE - NtCreateSection function itself modifies loaded .dll, according to this twit: https://twitter.com/therealwover/status/1193284444687392768?lang=en

[tapika]

By analyzing in depth https://github.com/Hagrid29/PELoader - I've started to search all examples SEC_IMAGE attribute, and find out that there exists a way to create empty invisible file by using CreateTransaction / CreateFileTransactedW.

Those API apparently is used to prepare installation of multiple files. Once transaction is creates and file is written - it's valid as a file, but does not exists physically anywhere (not even in temp folder).

This creates interesting opportunity to create file, and pass it's handle to be returned from NtOpenFile.

I've re-coded a working demo into it's own demo git repository: https://github.com/tapika/dllloader

Interesting thing is that debugging works out of box - apparently native .dll specifies absolute .pdb path, which is loaded in a turn by visual studio debugger out of box.

One thing which remains puzzling to me - what if I'll recompile same .dll over and over again, what will happen to debugger in this case ?
Maybe dll name could be also changed all the time, but how it will work with .pdb files ?

Something to research later on...

[tapika]

Btw - according to this link: https://www.blackhat.com/docs/eu-17/materials/eu-17-Liberman-Lost-In-Transaction-Process-Doppelganging.pdf, slide 35.

NTFS Transactions is somehow obsoleted feature ("Still used today (almost 11 years later)") - but it still looks like working and kicking even today. (Tested in windows 7 & 10)

[tapika]

5. Alternative approach: Just merge .dll and .exe on PE file level

This is something I have tried to reconsider afterwards - maybe I could just clue .exe and .dll on section level, so .dll sections would be immediately loaded once .exe gets loaded.

By quickly googling for such solutions - I was able to find from here:

pefrmdllembed

https://stackoverflow.com/a/45476609/2338477
=>
https://osdn.net/projects/pefrm-units/

Unfortunately that one turned to be quite complex piece of code (involving generation of code) - also supporting only 32-bit executables, but not 64-bit.

I've created ticket for this as well: secana/PeNet#243

Which was apparently closed immediately by it's author.

I do understand however the complexity behind PE merge functionality - based on 32-bit support produced by pefrmdllembed tool.

Btw, similar tool does exists for .net and it's named as ilmerge. Unfortunately it does not help with native code.

[tapika]

According to this web page:

https://pefrm-units.osdn.jp/pefrmdllembed.html#compatibility

pefrmdllembed should support 64-bit compilation, but need to drag dependencies, like asmjit, asmjitshared, peframework to compile everything.

[tapika]

Newer compilation is available in here: https://github.com/hdbeefup/dll2exe

Missing files from this compilation: (can pick dll2exe.exe release if necessary)
https://svn.osdn.net/svnroot/eirasmjit/eirasmjit/

But that tool does not work at least what I have tried on quickly.

[tapika]

Referenced documentation:

There are multiple sources which I have read through, and some of them sounds more interesting than others - quite often they relate to viruses, vulnerabilities and exploits.

• https://www.secforce.com/blog/dll-hollowing-a-deep-dive-into-a-stealthier-memory-allocation-variant/
• https://github.com/Hagrid29/PELoader
• https://github.com/SegaraRai/PathRedirector
• Lost in Transaction: Process Doppelgänging
  https://www.blackhat.com/docs/eu-17/materials/eu-17-Liberman-Lost-In-Transaction-Process-Doppelganging.pdf
  (How antiviruses tries to protect against various malwares)

[tapika]

Short summary so far:

Comparing to managed code (ilmerge, etc tools) - native .dll's is much more complex to load purely into ram. Also lack of original source codes (e.g. windows kernel) makes things also more complex.

• If someone has some idea on how to drive either my code or some 3rd party library and in which direction - let me know.
• If you encounter some other way, possibility, alternative way / approach - please let me know.

[goldli]

any update? I will continue to follow.

[tapika]

Not analyzing any deeper. I've created follow up git repo, see: https://github.com/tapika/dllloader
It's capable of loading native .dll and c++/cli dll to ram.

Haven't tested in whole extent with real projects, but sample demo projects seems to work.

If you want to ask some question or make suggestion, please go ahead.

[goldli]

well , it's a good news. i will test it to see if it works fine or not.