Generates x86, x64, or AMD64+x86 position-independent shellcode that loads .NET Assemblies, PE files, and other Windows payloads from memory and runs them with parameters
The code responsible for TLS handling is referencing the decoy module headers, not the original PE headers, when using a decoy module and header overwriting. In my specific testing scenario, this manifested in a crash on Windows Server 2019 but things working fine on Windows 10. The loader was treating the decoy module's PE checksum value as the RVA for the TLS directory, which happened to be a valid address pointing to null data with the Windows 10 version of the DLL, so the check at line 490 in inmem_pe.c prevented a crash in that instance.
This should be a quick fix in inmem_pe.c by changing line 478 to the following, so the original PE headers (ntc) are referenced instead of the decoy module headers (ntnew):
The code responsible for TLS handling is referencing the decoy module headers, not the original PE headers, when using a decoy module and header overwriting. In my specific testing scenario, this manifested in a crash on Windows Server 2019 but things working fine on Windows 10. The loader was treating the decoy module's PE checksum value as the RVA for the TLS directory, which happened to be a valid address pointing to null data with the Windows 10 version of the DLL, so the check at line 490 in
inmem_pe.cprevented a crash in that instance.This should be a quick fix in
inmem_pe.cby changing line 478 to the following, so the original PE headers (ntc) are referenced instead of the decoy module headers (ntnew):rva = ntc.OptionalHeader.DataDirectory[IMAGE_DIRECTORY_ENTRY_TLS].VirtualAddress;Thanks for everything!