Windows 11 24H2

[jarroddavis68]

Hi, will this work in windows 24H2?

[EvanMcBroom]

Yes

[jarroddavis68]

ahh, ok, I wonder what I'm doing wrong with my library. It will refuse to work. I based from the libs you reference in the readme. It's a Delphi adaptation.
https://github.com/tinyBigGAMES/MemoryDLL

[EvanMcBroom]

Ah, interesting. I know the concepts themselves work for 24H2, but I just tested the library for this project and reproduced the issue you experienced. I'll troubleshoot this and work on a fix.

[EvanMcBroom]

Still need to troubleshoot why the normal manual mapping approach is not currently working in this library on 24H2. The concept still works so it must be an implementation issue. I did test and find that Module Doppelgänging does still work fine on 24H2 if that'd help your project. I'll update this issue once I have more information.

[jarroddavis68]

I see. I used the redirecting LoadLibrary approach, being the easier one to understand. I've been trying many things to get it working, but I just don't understand what is going wrong in 24H2.

I guess I need to try and understand Module Doppelganging. Also is it possible to have a C interface to your lib? and will it work from a DLL?

[EvanMcBroom]

I guess I need to try and understand Module Doppelgänging

If it helps, I believe the approach can be simplified down to this:

1. Hook NtOpenFile
2. In NtOpenFile, check if the requested path matches what you provided to LoadLibrary. If it does:
   1. Remove the hook
   2. Create a transaction and call RtlSetCurrentTransaction to have all file IO done on the current thread be done within the transaction
   3. Open the file with write access and overwrite the file with the bytes of your in-memory DLL. This write will occur within the transaction and will not affect the file as it exists on the file system
   4. Close that handle, reopen the file with read access, and return that handle as the output parameter for NtOpenFile
3. Once LoadLibrary completes, call RtlSetCurrentTransaction again to remove the transaction from your thread, call RollbackTransaction, and finally call CloseHandle on the transaction handle (which it appears I missed doing in this library)

Also is it possible to have a C interface to your lib?

I'd be happy to add this. I need to fix some things with the library (ex. making the manual mapping approach work on 24H2) so I can add this in with that work. Would this definition meet your needs?

/// <summary>
///     Loads the provided module bytes into the address space of the calling process.
///     The process of loading the module may cause other modules to be loaded.
/// </summary>
/// <param name='DllBase'>
///     The address to the bytes of the module to load.
/// </param>
/// <param name='DllSize'>
///     The size in bytes of the module to load.
/// </param>
/// <param name='Flags'>
///     The action to be taken when loading the module.
///     Refer to the LoadLibraryEx* documentation for a full list of accepted values.
/// </param>
/// <param name='FileName'>
///     Refer to the Pl::LoadLibrary documentation for detailed information.
///     If no value is supplied then an empty temporary file will be created and its path will be used.
/// </param>
/// <param name='PlFlags'>
///     The approach and post processing options for loading the module.
///     Refer to the Pl::LoadFlags documentation for a full list of accepted values.
/// </param>
/// <param name='ModListName'>
///     An optional name to use as the DLL name in the module list.
///     fileName will be used if nothing is specified.
///     Only valid when used with the Pl::UseTxf flag.
/// </param>
/// <returns>
///     If the function succeeds, the return value is a handle to the loaded module.
///     If the function fails, the return value is NULL. To get extended error information, call GetLastError.
/// </returns>
HMODULE LoadDllFromMemory([in] LPVOID DllBase, [in] SIZE_T DllSize, [in, optional] DWORD Flags, [in, optional] LPCWSTR FileName, [in, optional] DWORD PlFlags, [in, optional] LPCWSTR ModListName);

will it work from a DLL?

It should, yes.

[jarroddavis68]

thanks, that would be great.

I tried doing something similar, but it will just crash for me:

#ifdef __cplusplus
extern "C" {
#endif

// Define the C wrapper function
__declspec(dllexport) HMODULE LoadLibraryWrapper(
    const wchar_t* fileName,
    const uint8_t* bytes,
    size_t bytesSize,
    DWORD flags,
    const wchar_t* modListName,
    DWORD nativeFlags) {
    // Forward declare the original function
    HMODULE LoadLibrary(const std::wstring& fileName,
        const std::vector<std::byte>& bytes,
        DWORD flags,
        const std::wstring& modListName,
        DWORD nativeFlags);

    // Convert C types to C++ types
    std::wstring cppFileName(fileName);
    std::vector<std::byte> cppBytes(reinterpret_cast<const std::byte*>(bytes), reinterpret_cast<const std::byte*>(bytes) + bytesSize);
    std::wstring cppModListName(modListName);

    // Call the original function and return the result
    return Pl::LoadLibrary(cppFileName, cppBytes, flags, cppModListName, nativeFlags);
}


#ifdef __cplusplus
}
#endif

it's probably that code, I'm, not a c/c++ programmer. I know enough to try and adapt for Dephi.

And I will look over those steps you outlined, many thanks.

[EvanMcBroom]

Hey @jarroddavis68, I added a C API for the project which is exposed by the pl.dll build artifact. Apologies for the delay on that. Here's a short example for using it that I believe will work for your project on 24H2:

#include "perfect_loader.h"

int wmain(int argc, wchar_t** argv) {
    // snippet ...
    HMODULE library = LoadDllFromMemory(dllBytes, dllSize, 0, fileName, PL_LOAD_FLAGS_USETXF, L"");
    // snippet ...
}

The fileName value will ultimately be passed as the first argument to LoadLibrary but it does not have to be a valid DLL. It just needs to be a valid path that LoadLibrary can resolve (ex. C:\Windows\Temp\example.txt) and it must be a file that your current user has permissions to write to. Although your user will need permissions to write to the file, the file's contents will only be modified in memory (in a temporary file transaction) which will not affect the file on disk.

The library's other technique for reflectively loading a library (manually mapping a DLL in memory then redirecting LoadLibrary via a hook to use that mapping) does still work on 24H2, but there are some implementation issues specific to this library that I'll need to fix which currently cause the library to fail for that Windows release. It'll be a little longer before I'll be able to implement the fixes for those, but I'll keep this ticket open in the meantime until that's resolved.

I hope this helps your work, and thank you for noticing the failure on 24H2 and filling the issue! 🙂

[jarroddavis68]

Hey @jarroddavis68, I added a C API for the project which is exposed by the pl.dll build artifact. Apologies for the delay on that. Here's a short example for using it that I believe will work for your project on 24H2:

Many Thanks!

The library's other technique for reflectively loading a library (manually mapping a DLL in memory then redirecting LoadLibrary via a hook to use that mapping) does still work on 24H2, but there are some implementation issues specific to this library that I'll need to fix which currently cause the library to fail for that Windows release. It'll be a little longer before I'll be able to implement the fixes for those, but I'll keep this ticket open in the meantime until that's resolved.

The concept continued to work for me too, the hooks would fire, but when LoadLibrary returns, it will always be NULL.

I hope this helps your work, and thank you for noticing the failure on 24H2 and filling the issue! 🙂

I will check this out, again, thank you!

[EvanMcBroom]

Sure thing! For the issue regarding manual mapping, at some point Microsoft introduced logic in the loader such that the loader will reattempt mapping the section one additional time when our library returns STATUS_IMAGE_NOT_AT_BASE in its NtMapViewOfSection hook. I have tested having the library maintain its hook on NtMapViewOfSection for that one additional reattempt the loader does which appears to work well on 24H2. So that should be the root cause of the issue and the fix, but just want to clean up the new code for that fix before adding it in.

[jarroddavis68]

here is my hooked NtMapViewOfSection code, how can I adapt it to what you described above. It never seems to get called again.

function HookNtMapViewOfSection(
  ASectionHandle: THandle;
  AProcessHandle: THandle;
  ABaseAddress: PPVOID;
  AZeroBits: ULONG_PTR;
  ACommitSize: SIZE_T;
  ASectionOffset: PLARGEINTEGER;
  AViewSize: PSIZE_T;
  AInheritDisposition: ULONG;
  AAllocationType: ULONG;
  AWin32Protect: ULONG
): NTSTATUS; stdcall;
var
  LOldNtMapViewOfSection: TNtMapViewOfSection; // Original NtMapViewOfSection function
begin
  // Stop the current hook to prevent recursion
  NtMapViewOfSectionHook.Stop();

  if DllData = nil then
  begin
    // Retrieve the original NtMapViewOfSection function pointer
    LOldNtMapViewOfSection := TNtMapViewOfSection(NtMapViewOfSectionHook.GetOldFunction());
    // Call the original NtMapViewOfSection function with provided parameters
    Result := LOldNtMapViewOfSection(
      ASectionHandle,
      AProcessHandle,
      ABaseAddress^,
      AZeroBits,
      ACommitSize,
      ASectionOffset,
      AViewSize^,
      AInheritDisposition,
      AAllocationType,
      AWin32Protect
    );
    Exit;
  end;

  // Map the DLL into memory
  HookMapDll(DllData, ABaseAddress^, AViewSize^);
  DllData := nil; // Clear DLL data after mapping

  // Return a custom NTSTATUS code indicating successful mapping
  Result := $40000003;
end;

function HookNtMapViewOfSection(
  ASectionHandle: THandle;
  AProcessHandle: THandle;
  ABaseAddress: PPVOID;
  AZeroBits: ULONG_PTR;
  ACommitSize: SIZE_T;
  ASectionOffset: PLARGEINTEGER;
  AViewSize: PSIZE_T;
  AInheritDisposition: ULONG;
  AAllocationType: ULONG;
  AWin32Protect: ULONG
): NTSTATUS; stdcall;
var
  LOldNtMapViewOfSection: TNtMapViewOfSection;
begin
  // Stop the current hook to prevent recursion
  NtMapViewOfSectionHook.Stop();

  try
    // Retrieve the original NtMapViewOfSection function pointer
    LOldNtMapViewOfSection := TNtMapViewOfSection(NtMapViewOfSectionHook.GetOldFunction());

    // Perform manual mapping if DllData is set
    if DllData <> nil then
    begin
      HookMapDll(DllData, ABaseAddress^, AViewSize^);
      DllData := nil; // Clear DLL data after mapping
      Result := $40000003; // Indicate successful mapping
      Exit;
    end;

    // Call the original NtMapViewOfSection function
    Result := LOldNtMapViewOfSection(
      ASectionHandle,
      AProcessHandle,
      ABaseAddress^,
      AZeroBits,
      ACommitSize,
      ASectionOffset,
      AViewSize^,
      AInheritDisposition,
      AAllocationType,
      AWin32Protect
    );

    // Handle retry for STATUS_IMAGE_NOT_AT_BASE
    if Result = STATUS_IMAGE_NOT_AT_BASE then
    begin
      // Retry mapping logic for Windows 11 24H2 compatibility
      NtMapViewOfSectionHook.Start('ntdll.dll', 'NtMapViewOfSection', FARPROC(@HookNtMapViewOfSection));
      Result := LOldNtMapViewOfSection(
        ASectionHandle,
        AProcessHandle,
        ABaseAddress^,
        AZeroBits,
        ACommitSize,
        ASectionOffset,
        AViewSize^,
        AInheritDisposition,
        AAllocationType,
        AWin32Protect
      );
    end;

  finally
    // Restart the hook to ensure future calls are handled
    NtMapViewOfSectionHook.Start('ntdll.dll', 'NtMapViewOfSection', FARPROC(@HookNtMapViewOfSection));
  end;
end;

function HookNtOpenFile(
  AFileHandle: PHANDLE;
  ADesiredAccess: ACCESS_MASK;
  AObjectAttributes: POBJECT_ATTRIBUTES;
  AIoStatusBlock: PIO_STATUS_BLOCK;
  AShareAccess: ULONG;
  AOpenOptions: ULONG
): NTSTATUS; stdcall;
var
  LResultStatus: NTSTATUS;            // Result status from the original NtOpenFile
  LOldNtOpenFile: TNtOpenFile;        // Original NtOpenFile function
begin
  // Temporarily suspend the NtOpenFile hook to avoid recursion
  NtOpenFileHook.Suspended();

  // Retrieve the original NtOpenFile function pointer
  LOldNtOpenFile := TNtOpenFile(NtOpenFileHook.GetOldFunction());

  // Call the original NtOpenFile function with provided parameters
  LResultStatus := LOldNtOpenFile(
    AFileHandle,
    ADesiredAccess,
    AObjectAttributes,
    AIoStatusBlock,
    AShareAccess,
    AOpenOptions
  );

  // Check if the ObjectName contains the hook reference DLL name
  if wcsstr(AObjectAttributes^.ObjectName^.Buffer, HOOK_REFERENCE_DLL) <> nil then
  begin
    // Stop the NtOpenFile hook and start the NtMapViewOfSection hook
    NtOpenFileHook.Stop();
    NtMapViewOfSectionHook.Start('ntdll.dll', 'NtMapViewOfSection', FARPROC(@HookNtMapViewOfSection));
    Exit(LResultStatus); // Return the original result status
  end;

  // Restore the NtOpenFile hook before returning
  NtOpenFileHook.Restore;
  Result := LResultStatus;
end;

function MemoryLoadLibrary(const AData: Pointer): THandle;
begin
  // Enter critical section to ensure thread-safe operations
  CriticalSection.Enter();
  try
    // Start hooking the NtOpenFile function in ntdll.dll with HookNtOpenFile as the replacement
    NtOpenFileHook.Start('ntdll.dll', 'NtOpenFile', @HookNtOpenFile);
    DllData := AData; // Store the DLL data pointer
    Result := LoadLibraryW(HOOK_REFERENCE_DLL); // Load the reference DLL using wide-character API
  finally
    // Leave the critical section after operations are complete
    CriticalSection.Leave();
  end;
end;

[EvanMcBroom]

Hey @jarroddavis68, I have never written Pascal code before and as such I'm not equipped to help troubleshoot your code. I wish I could provide better help with that and I'm sorry I can't 😕

By chance, did you attempt using the C interface that was added for your request to see if it'd solve your need?