initterm crash when loading unreal engine binaries

[maximegmd]

Using the sample loader project on an Unreal Engine 4 compiled binary crashes with a null access within the initterm call in __scrt_common_main_seh.

So far I haven't been able to locate the cause of this, I have tried disabling reloc but had no success.

Note that the function called by initterm uses TLS, I am thinking that maybe run_tls_callbacks may not work correctly or that some additional TLS code is required.

[hasherezade]

Hi! The best would be if you could share the binary, so that I can have a look at it. You can send it to my e-mail: hasherezade-at-pm.me

Is it 32 or 64 bit?
You are right that there may be something wrong with how TLS callbacks are executed, but I also suspect it may be related to exceptions handler.
During the manual load (as libPEconv does) the exception handlers are not installed - so they also need to be set up manually. I implemented it for 64-bit targets (although it is not enabled in the default loader). You can see it in this sample code:

libpeconv/tests/test_exceptions.cpp

Line 25 in 93fe6ef

if (!peconv::setup_exceptions(loaded_pe, v_size)) {

Which is a part of a testcase 18:

libpeconv/tests/main.cpp

Line 49 in 93fe6ef

case 18: return tests::test_load_with_exception_table(test_arg);

For the 32-bit targets I didn't implement it yet (it is very different than in 64-bit, the same APIs are not available).

But if your application is 64bit we can make a test, and check if running it with exceptions table installed could help.
Just compile libPEConv along with test cases, and then run:

tests.exe 18 {your_app.exe}

This will load your app via loader with exceptions table set up.
Please let me know what is the result.

[NotCapengeR]

Using the sample loader project on an Unreal Engine 4 compiled binary crashes with a null access within the initterm call in __scrt_common_main_seh.

So far I haven't been able to locate the cause of this, I have tried disabling reloc but had no success.

Note that the function called by initterm uses TLS, I am thinking that maybe run_tls_callbacks may not work correctly or that some additional TLS code is required.

I'm late with my answer, but better late than never. "Some additional TLS code" is called LdrpHandleTlsData function from Ntdll.
It has the following signature and is not exported because it has Ldrp prefix (p - private)

NTSTATUS __stdcall LdrpHandleTlsData(PLDR_DATA_TABLE_ENTRY Module); // below Windows 8.1
NTSTATUS __thiscall LdrpHandleTlsData(PLDR_DATA_TABLE_ENTRY Module); // Windows 8.1+

In fact, most custom PE loaders try to find the address of this function via pattern scan in order to subsequently pass PLDR_DATA_TABLE_ENTRY with initialized DllBase and SizeOfImage fields to it (this function does not seem to read other fields).
I also found a manual implementation of this function in MemoryModulePP, but, as mentioned in repo's README, it's unstable. I think that using manual loading for PE files is unstable by default, so you should use other methods to execute PE in memory