trying to add clrtjit.dll into my C#
modz2014 opened this issue · 8 comments
hi im trying to add clrjit.dll into my C# to run in memory but it doesnt seem to work properly
The library probably uses TLS memory.
The Windows TLS memory model is currently NOT supported by MemoryModule.NET, as well as the original MemoryModule project (although binaries compiled using MinGW and uses the POSIX thread model may work on MemoryModule.NET).
Why do you want to run a clrjit.dll on top of .NET anyway? Isn't it easier to directly load a managed assembly?
well it uses it to execute but if the User doesnt have the net frame installed in should still run in memory right or isnt that possible
You should try using a .NET Self contained application instead.
Or, look at some forks of the original MemoryModule (the C library) that actually supports Windows TLS. These forks uses really dirty tricks that I don't understand myself, and makes your code really unstable.
Because, if you don't have a .NET runtime to load MemoryModule.NET.dll in the first place, then how would you even use my library?
so its not possible then
im trying to run this without installing netframe work stuff https://github.com/cg10036/Themida-Unpacker-for-.NET
I have an unmanaged application packaged as a DLL that loads the CLR.
Below is the WinDbg output of the application crash. This happens during the process of the unmanaged DLL application trying to load the CLR.
ModLoad: 00007ffc`0f520000 00007ffc`0f54c000 C:\WINDOWS\SYSTEM32\wldp.dll
ModLoad: 00007ffb`f9590000 00007ffb`f95a9000 C:\WINDOWS\SYSTEM32\amsi.dll
ModLoad: 00007ffc`0f9b0000 00007ffc`0f9de000 C:\WINDOWS\SYSTEM32\USERENV.dll
ModLoad: 00007ffc`0f9f0000 00007ffc`0fa0f000 C:\WINDOWS\SYSTEM32\profapi.dll
ModLoad: 00007ffb`f9510000 00007ffb`f9589000 C:\ProgramData\Microsoft\Windows Defender\Platform\4.18.2106.6-0\MpOav.dll
ModLoad: 00007ffc`01320000 00007ffc`0141c000 C:\ProgramData\Microsoft\Windows Defender\Platform\4.18.2106.6-0\MPCLIENT.DLL
ModLoad: 00007ffc`0e390000 00007ffc`0e3b3000 C:\WINDOWS\SYSTEM32\gpapi.dll
(1838.1dd4): C++ EH exception - code e06d7363 (first chance)
(1838.1dd4): C++ EH exception - code e06d7363 (first chance)
(1838.1dd4): C++ EH exception - code e06d7363 (first chance)
(1838.1dd4): C++ EH exception - code e06d7363 (first chance)
(1838.1dd4): C++ EH exception - code e06d7363 (first chance)
(1838.1dd4): CLR exception - code e0434352 (first chance)
(1838.1dd4): CLR exception - code e0434352 (first chance)
(1838.1dd4): Unknown exception - code c0000028 (first chance)
(1838.1dd4): Unknown exception - code c0000028 (!!! second chance !!!)
ntdll!RtlRaiseStatus+0x36:
00007ffc`12472406 65488b0c2560000000 mov rcx,qword ptr gs:[60h] gs:00000000`00000060=????????????????
When NOT using this library, my application succeeds and gets past this point to load clrjit.dll, which is what I believe is causing this kind of crash:
ModLoad: 00007ffc`0e390000 00007ffc`0e3b3000 C:\WINDOWS\SYSTEM32\gpapi.dll
(2818.564): C++ EH exception - code e06d7363 (first chance)
(2818.564): C++ EH exception - code e06d7363 (first chance)
(2818.564): C++ EH exception - code e06d7363 (first chance)
(2818.564): C++ EH exception - code e06d7363 (first chance)
(2818.564): C++ EH exception - code e06d7363 (first chance)
(2818.564): CLR exception - code e0434352 (first chance)
(2818.564): CLR exception - code e0434352 (first chance)
ModLoad: 00007ffb`ca320000 00007ffb`ca46f000 C:\Windows\Microsoft.NET\Framework64\v4.0.30319\clrjit.dll
This is a little weird since using this library to load a DLL that loads the CLR seems unintuitive, but I'm wondering if there's any way to make this work.
00007ffc`12472406 65488b0c2560000000 mov rcx,qword ptr gs:[60h] gs:00000000`00000060=????????????????
The problem is displayed clearly in this line.
MemoryModule.NET has a limitation of not being able to handle Windows TLS slots properly. The same thing applies to the original MemoryModule.
As the TLS index is not initialized properly, any attempts to access thread-local storage will result in a segmentation fault.
The CLR is a complex application so I'm not surprised if it uses thread-local variables somewhere.
Related: #34
I'm keeping this open as there might be other blockers in the future other than TLS.