update system DLL range logic for 64-bit OSes

[jdu2600]

Hey Detours folks,

Just a couple of suggestions for choosing the trampoline location.

The X86 range reserved for system DLLs is not up to date.

The X64 "not +/- 1GB of target" heuristic to avoid the range used by system DLLs is not entirely robust. Instead we could replace this with a "not 1GB after ntdll" heuristic.

[Mauler125]

This breaks support for Windows 7, DetourAllocateRegionWithinJumpBounds emits the message "Couldn't find available memory region!\n".

[jdu2600]

@Mauler125 Was this Windows 7 x86?
The x86 logic was updated to account for Windows 8 kernel changes - but I didn't consider backwards compatibility with EOL versions at time.

Detours/src/detours.cpp

Lines 78 to 84 in 4ed81f1

	// On X86 the range was originally 0x70000000..0x80000000
	// However, since Windows 8, the range is now 0x50000000..0x78000000
	// Reference: Windows Internals, 7th Edition, page 368
	// We just exclude both ranges.
	static PVOID s_pSystemRegionUpperBound = (PVOID)((ULONG_PTR)0x80000000);
	static PVOID s_pSystemRegionLowerBound = (PVOID)((ULONG_PTR)0x50000000 - 0x100000);
	static SIZE_T s_pSystemRegionSize = (ULONG_PTR)s_pSystemRegionUpperBound - (ULONG_PTR)s_pSystemRegionLowerBound; // 769MB

[Mauler125]

@jdu2600 This was on the latest version of Windows 7 x64 (SP1 with all updates), I think the ranges are different on Windows 7, and changed in Windows 8 as you mentioned. I hadn't had the chance to debug this myself yet. Some of our users host a game server on Windows 7 x64 which is where this was being reported from.

These changes however do seem to work perfectly on Windows 10 and Windows 11 for the 2 months we have it implemented and tested; not a single issue has been encountered from it yet.

[RatinCN]

@jdu2600 This was on the latest version of Windows 7 x64 (SP1 with all updates), I think the ranges are different on Windows 7, and changed in Windows 8 as you mentioned. I hadn't had the chance to debug this myself yet. Some of our users host a game server on Windows 7 x64 which is where this was being reported from.

These changes however do seem to work perfectly on Windows 10 and Windows 11 for the 2 months we have it implemented and tested; not a single issue has been encountered from it yet.

Weird, I've checked "Windows Internals 6th" (corresponding to Win7) and analyzed ntoskrnl.exe!MiInitializeRelocations, the results show the region is the same SINCE NT6.0:
32-bit process：[0x50000000 ... 0x78000000), a total of 640MB
64-bit process：[0x00007FF7FFFF0000 ... 0x00007FFFFFFF0000), a total of 32GB
(Personal conclusions, please let me know if there is any error)

[RatinCN]

In Vista and Win7 (NT6.0 and NT6.1), ASLR can be turned off by registry:

HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management, MoveImages (REG_DWORD)

I think there's a chance this could be causing this issue.

[Mauler125]

In Win7, ASLR can be turned off by registry:

HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management, MoveImages (REG_DWORD)

I think there's a chance this could be causing this issue.

Sorry for my later responce. Today I did some research again on this issue and it was indeed caused by having ASLR disabled system-wide using the mentioned registry value.

Your recent changes on KNSoft's SlimDetours does fix the issue as far as I've been able to test it. I will continue testing it and report any issues if I encounter them.

[RatinCN]

In Win7, ASLR can be turned off by registry:

HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management, MoveImages (REG_DWORD)

I think there's a chance this could be causing this issue.

Sorry for my later responce. Today I did some research again on this issue and it was indeed caused by having ASLR disabled system-wide using the mentioned registry value.

Your recent changes on KNSoft's SlimDetours does fix the issue as far as I've been able to test it. I will continue testing it and report any issues if I encounter them.

Thanks, if still encounter the same problem, try to remove this block, I don't have 100% confidence in this.