Feature : .Net CLR Inititlaiztion

[CycloneRing]

This library is the best pe loader I've found thanks for your contribution, I was just thinking it would be great if you add .net support, I have not so much information but I know before loading .net dlls with export clr.dll gets initialized, It should be possible to add it to the MMPP, It will be great if you can implement it.

Thanks

[bb107]

I don't think I understand why you use MMPP to load .NET assemblies from memory. On the one hand, C++/CLI supports loading assemblies from memory (as shown in Figure 1); on the other hand, if you don’t use C++/CLI, I don’t understand how to call managed code from native code. I have adjusted the loader so that it can load .NET assemblies (as shown in Figure 2), but it can only be loaded in 32-bit programs, because as far as I know, almost all .NET assemblies have 32-bit PE headers . But Win32 API LoadLibrary can load the .NET assembly correctly even if it is a 64-bit program.

[CycloneRing]

Hello, No, there are 64bit assemblies. You need to set the project completely to x64, then use DllExport package to export functions from managed dll.

Here's a sample x64 managed dll which works fine with LoadLibraryW It has one exported function :

typedef void(*ManagedExportFuncType)(const char* str);

It shows the text parameter in a message box. ManagedLib_x64.zip

[bb107]

Hello, thank you for your explanation. When the export function is called for the first time, the initialization function of mscoreei.dll will be called first, and the assembly file version will be checked in it and the cli environment will be loaded. Therefore, to execute the export method in .net correctly, the assembly file must be stored on the hard disk, and its location must be specified when calling LdrLoadDllMemoryExW.

[CycloneRing]

Nice!, since we are already using detours, can't it be virtualized by hooking some functions?

[bb107]

Thank you for your reply. During mscoreei.dll initialization, clr.dll will be loaded and CorDllMainForThunk will be called. This function will remap the assembly we want to execute. Therefore, it is not feasible for us to deal with it by hooking.

[bb107]

Anyway, I found the necessary functions through disassembly and dynamic debugging and hooked them:

CreateFileW
GetFileInformationByHandle
GetFileAttributesExW
CreateFileMappingW
MapViewOfFileEx
UnmapViewOfFile
CloseHandle
GetFileVersion

Then a simple .NET assembly was successfully loaded and called. Due to the complexity of .NET, our hooks cannot guarantee the correct execution of complex assemblies and cross-version compatibility of the .NET framework.

[CycloneRing]

Good job!

I cloned HandleTlsData and tried a very basic .net dll (the one I sent above) and it didn't work throw a error :

Microsoft C++ exception: HRException at memory location 0x000000852EEFF838.

Is there any extra step I should do?

[bb107]

Hi. You need to specify the LOAD_FLAGS_HOOK_DOT_NET flag when calling LdrLoadDllMemoryExW. When I was debugging this issue, I found that MmpTls made false assertions when processing some threads created by the kernel that the user could not perceive.

[CycloneRing]

If you don't mind, can you upload a sample solution?

[bb107]

This bug has been fixed in the 41c1175 commit.

[CycloneRing]

I still can't make it working on a simple hello world dll, It throw HResult error. Can you push a example for .net to the branch? Thanks!

[bb107]

What is your version of Windows? I tested it on a Windows 7 virtual machine and it also threw an exception, but it worked correctly on another Windows 10 version. Because different versions of clr.dll have different implementations of remapping, it is difficult for us to be compatible with all versions by being compatible with one version.

[CycloneRing]

Hi there, I have Win 10 21H1 (1904)

[bb107]

Hello, I just updated the code. I think it can work correctly for you. If it still throws an exception, please tell me your .net framework version and clr.dll file version.

[CycloneRing]

Hello @bb107 and thanks! The sample you uploaded works with the dll nice! But when I use the same in my LdrLoadDll dll gets loaded but just after that it throws Unhandled Exception: OutOfMemoryException. any idea?

UPDATE 1 : After some digging I found out it's caused by GetProcAddressForCaller because native .net loads another .net native dll and it calls the function using GetProcAddressForCaller, Should we hook it too?

[bb107]

Hi. I cannot reproduce this exception. Please upload a sample that can trigger this exception.

[CycloneRing]

Sure, I'll upload a sample repo in the first chance i've got. Thanks for your time and work!