64bit run_pe load 64bit payload not working on windows 11 24H2

[idigger]

Load 32bit payload ok.

64bit and 32bit are ok on before windows 11 24H2

[NotCapengeR]

Starting from Windows 11 24H2, Microsoft has implemented a new Control Flow Guard or CFG system, which should limit the places where the application can execute code. You can read more info on MSDN.

Hackers from the UnknownCheats forum analyzed the PE loader in Ntdll and found a function that initializes this mechanism for the PE image — RtlpInsertOrRemoveScpCfgFunctionTable. It seems like there is even a working code that patches RtlpInsertOrRemoveScpCfgFunctionTable function according to a hard-coded offset.

const auto NtdllBase = reinterpret_cast<PBYTE>(GetModuleHandleW(L"ntdll.dll"));
const BYTE Patch[4] =
{
    0x48, 0x31, 0xC0, // xor rax, rax
    0xC3 // ret
};
// Patching RtlpInsertOrRemoveScpCfgFunctionTable function of Ntdll using hard-coded offset
WriteProcessMemory(pi.hProcess, NtdllBase + 0x7BE0, Patch, sizeof(Patch), nullptr);

Original post — https://www.unknowncheats.me/forum/4239032-post15.html

Perhaps zeroing IMAGE_LOAD_CONFIG_DIRECTORY of the payload image before copying it to another process can also help.

[NotCapengeR]

So, I did get an Ntdll sample from Windows 11 24H2. The RtlpInsertOrRemoveScpCfgFunctionTable function is not exported, so patching it by offset is not a good idea, but I found something interesting in IDA...

NTSTATUS __stdcall RtlpInsertOrRemoveScpCfgFunctionTable(PVOID ImageBase, __int64 Reserved, bool insertOrRemove)
{
  NTSTATUS result; // eax
  char *pageBase; // rax
  __int64 offsetToRtlTable; // rcx
  ULONG_PTR ImageExtensionLength; // [rsp+30h] [rbp-38h] BYREF
  PVOID DynamicTable; // [rsp+38h] [rbp-30h] BYREF
  MEMORY_IMAGE_EXTENSION_INFORMATION info; // [rsp+40h] [rbp-28h] BYREF

  ImageExtensionLength = 0i64;
  memset(&info, 0, sizeof(info));
  result = ZwQueryVirtualMemory(
             (HANDLE)0xFFFFFFFFFFFFFFFFi64,
             ImageBase,
             MemoryImageExtensionInformation,
             &info,
             0x18ui64,
             &ImageExtensionLength);
  if ( result == -1073741637 )
    return 279;
  if ( result >= 0 )
  {
    if ( !info.PageSize )
      return 279;
    pageBase = (char *)ImageBase + *(_QWORD *)&info.PageOffset;
    offsetToRtlTable = *(unsigned int *)((char *)ImageBase + *(_QWORD *)&info.PageOffset + 20);
    if ( !(_DWORD)offsetToRtlTable )
      return 279;
    if ( insertOrRemove )
    {
      result = RtlAddGrowableFunctionTable(
                 &DynamicTable,
                 (PRUNTIME_FUNCTION)&pageBase[offsetToRtlTable],
                 1u,
                 1u,
                 (ULONG_PTR)ImageBase + *(_QWORD *)&info.PageOffset,
                 (ULONG_PTR)&pageBase[info.PageSize]);
      if ( result >= 0 )
        return 0;
    }
    else
    {
      RtlDeleteFunctionTable((PRUNTIME_FUNCTION)&pageBase[offsetToRtlTable]);
      return 0;
    }
  }
  return result;
}

RtlpInsertOrRemoveScpCfgFunctionTable is just a wrapper around RtlDeleteFunctionTable and RtlAddGrowableFunctionTable. We are lucky — both of these functions are exported and not used anywhere else, so we can safely patch them. Oh, and by the way: it turned out that another function requires a patch — NtManageHotPatch, it is also exported, so there are no problems for us.
Final code should be something like this:

#ifdef _WIN64 // Dynamic function tables is only for 64-bits images
	auto hNtdll = GetModuleHandleW(L"ntdll.dll"); // Found Ntdll base address
	if (hNtdll) {
		// Stub for functions
		const BYTE patch[4] =
		{
			0x48, 0x31, 0xC0, // xor rax, rax
			0xC3 // ret
		};

		FARPROC NtManageHotPatch = GetProcAddress(hNtdll, "NtManageHotPatch");
		FARPROC RtlAddGrowableFunctionTable = GetProcAddress(hNtdll, "RtlAddGrowableFunctionTable");
		FARPROC RtlDeleteFunctionTable = GetProcAddress(hNtdll, "RtlDeleteFunctionTable");
		
		if (NtManageHotPatch && RtlAddGrowableFunctionTable && RtlDeleteFunctionTable) {
			// Wanna some patches?
			WriteProcessMemory(pi.hProcess, NtManageHotPatch, patch, sizeof(patch), nullptr);
			WriteProcessMemory(pi.hProcess, RtlAddGrowableFunctionTable, patch, sizeof(patch), nullptr);
			WriteProcessMemory(pi.hProcess, RtlDeleteFunctionTable, patch, sizeof(patch), nullptr);
			
			// Apply changes to cache
			FlushInstructionCache(pi.hProcess, NtManageHotPatch, sizeof(patch));
			FlushInstructionCache(pi.hProcess, RtlAddGrowableFunctionTable, sizeof(patch));
			FlushInstructionCache(pi.hProcess, RtlDeleteFunctionTable, sizeof(patch));
		}
	}
#endif

I could do a pull request with this, but I don't have Windows 11 24H2 to test this code.

[hasherezade]

Thank you for finding all those details @NotCapengeR ! It is definitely very useful! I will try to get Windows 11 24H2 and test it whenever I get some free time.

[bytecode77]

@NotCapengeR I have, too, realized, that Windows 24H2 broke RunPE, so I stumbled upon your suggestion. I tried it (with VirtualProtectEx before WriteProcessMemory), but without success, yet. I will do my own research next, but may I ask, if any of you solved this rather new issue?

[NotCapengeR]

@NotCapengeR I have, too, realized, that Windows 24H2 broke RunPE, so I stumbled upon your suggestion. I tried it (with VirtualProtectEx before WriteProcessMemory), but without success, yet. I will do my own research next, but may I ask, if any of you solved this rather new issue?

As I said, I don't have Windows 11 24H2, so I cannot test my code. If it doesn't working, you need to debug and find a function that is causing the error (btw, what is this error?). But it seems to me that a patch of these functions is enough for everything to work, perhaps a few more functions need a patch too

[harunkocacaliskan]

Any updates for this issue, did anybody tried patch ntdll method? I have tried some other PE Loaders, some of them has same error.

[pmsjt]

RtlpInsertOrRemoveScpCfgFunctionTable has no effect on the enablement of CFG. The only thing it does is to add exception handlers to handle any exception happening in the CFG function, if they arise. If CFG is off, then CFG code will never run, never raise exceptions and, thus, its EHs will also never run.

My wild guess about what is happening, is that the program is unmapping a DLL legitimately loaded by Windows and then mapping it back, using this PE loader. When the DLL is unloaded, the SCP page is also unloaded. This PE loader does not know what an SCP is, so it won't reconstruct it. Any pointers to it - including dynamic function table pointers - are now pointing to NO_ACCESS memory.

Again, this is just a guess from reading the tea leaves. A PoC or even just a dump would be helpful in helping understand what is really amiss.

If the guess is right, there are some options: Either we disable SCPs for this process, or this loader starts to emulate the SCP construction... The latter is unlikely hard to maintain, but I am listing for the purpose of completeness.

[hasherezade]

Hi, finally I've got some time, and access to Windows 11 24H2, and started to check it.

First of all, in this variant of RunPE, there is no unmapping of the original module. The new module is loaded additionally, and the PEB is modified to point to it. So it does not seem to be what @pmsjt described.

I have two other loaders, that can be used as an alternative of RunPE - I checked them, and they both work on Windows 11 24H2, while the classic RunPE doesn't work. Check them out:

• https://github.com/hasherezade/transacted_hollowing
• https://github.com/hasherezade/process_overwriting ; video: https://youtu.be/sZ8tMwKfvXw

I am not sure yet, but it seems the problem is related to the fact that the PE to be loaded is in MEM_PRIVATE, because both of the alternative loaders that I mention work almost exactly the same as classic RunPE (the most similar is transacted_hollowing). The only difference is that they use MEM_IMAGE for the payload.
Process Overwriting disables CFG on the process, but Transacted Hollowing doesn't touch it.

I will keep investigating where the problem actually occurs, and will let you know. In the meantime, I recommend you to use one of the alternatives that I mentioned.

[pmsjt]

The ecosystem folks sent me a PoC and, in n that one ntdll.dll was being unmapped. That is even more radical than unmapping another binary because because binaries within the jump displacement vicinity of ntdll.dll use ntdll.dll's SCP page for optimal cache usage reasons.

[NotCapengeR]

Hi, finally I've got some time, and access to Windows 11 24H2, and started to check it.

First of all, in this variant of RunPE, there is no unmapping of the original module. The new module is loaded additionally, and the PEB is modified to point to it. So it does not seem to be what @pmsjt described.

I have two other loaders, that can be used as an alternative of RunPE - I checked them, and they both work on Windows 11 24H2, while the classic RunPE doesn't work. Check them out:

• https://github.com/hasherezade/transacted_hollowing
• https://github.com/hasherezade/process_overwriting ; video: https://youtu.be/sZ8tMwKfvXw

I am not sure yet, but it seems the problem is related to the fact that the PE to be loaded is in MEM_PRIVATE, because both of the alternative loaders that I mention work almost exactly the same as classic RunPE (the most similar is transacted_hollowing). The only difference is that they use MEM_IMAGE for the payload. Process Overwriting disables CFG on the process, but Transacted Hollowing doesn't touch it.

I will keep investigating where the problem actually occurs, and will let you know. In the meantime, I recommend you to use one of the alternatives that I mentioned.

My friend said that in the Windows 11 24H2 kernel, a new check appeared inside the NtMapViewOfSection function, which returns STATUS_INVALID_IMAGE_FORMAT if the section was not mapped from the disk (SEC_IMAGE attribute).
It looks like there is a similar memory region attribute check inside the x64 PE loader, which is why SCP CFG patches don't work...

[NotCapengeR]

RtlpInsertOrRemoveScpCfgFunctionTable has no effect on the enablement of CFG. The only thing it does is to add exception handlers to handle any exception happening in the CFG function, if they arise. If CFG is off, then CFG code will never run, never raise exceptions and, thus, its EHs will also never run.

My wild guess about what is happening, is that the program is unmapping a DLL legitimately loaded by Windows and then mapping it back, using this PE loader. When the DLL is unloaded, the SCP page is also unloaded. This PE loader does not know what an SCP is, so it won't reconstruct it. Any pointers to it - including dynamic function table pointers - are now pointing to NO_ACCESS memory.

Again, this is just a guess from reading the tea leaves. A PoC or even just a dump would be helpful in helping understand what is really amiss.

If the guess is right, there are some options: Either we disable SCPs for this process, or this loader starts to emulate the SCP construction... The latter is unlikely hard to maintain, but I am listing for the purpose of completeness.

I even tried to zeroing the IMAGE_LOAD_CONFIG fields responsible for CFG - it didn’t help. It looks like it breaks for other reasons than CFG (or not just CFG).

[hasherezade]

Ok, I see where exactly it happens. Those are the subsequent functions called:

• LdrpInitializeProcess
  • LdrpProcessMappedModule
    • RtlpInsertOfRemoveScpCfgFunctionTable
      • ZwQueryVirtualMemory

The problem lies indeed in the fact that the payload is not mapped as MEM_IMAGE.
The function ZwQueryVirtualMemory is called with a new argument MemoryImageExtensionInformation.

ZwQueryVirtualMemory(NtCurrentProcess(), implanted_pe, MemoryImageExtensionInformation, out_buf, out_buf_size, &out_size);

If the supplied region is not MEM_IMAGE, it returns 0xC0000141 (STATUS_INVALID_ADDRESS), and it further leads to termination of the loader. If we hook ZwQueryVirtualMemory and make it return 0 (STATUS_SUCCESS) for our payload, it will continue to load correctly. I already tested it, and it worked.

[pmsjt]

Great work. Glad you have a working.

Better than STATUS_SUCCESS, you should make it return STATUS_NOT_SUPPORTED. This will be taken as a benign return status, whilst preventing the rest of the function from parsing bogus uninitialized data from the ZwQueryVirtualMemory 4th param buffer.