Feature : .Net CLR Inititlaiztion about memorymodulepp HOT 17 OPEN

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.

from memorymodulepp.

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.

from memorymodulepp.

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.

from memorymodulepp.

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

from memorymodulepp.

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

from memorymodulepp.

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.

from memorymodulepp.

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.

from memorymodulepp.

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?

from memorymodulepp.

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.

from memorymodulepp.

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

from memorymodulepp.

This bug has been fixed in the 41c1175 commit.

from memorymodulepp.

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!

from memorymodulepp.

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.

from memorymodulepp.

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

from memorymodulepp.

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?

from memorymodulepp.

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

from memorymodulepp.

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

from memorymodulepp.