Description
Host: x64dbg on Windows 10
Plugin: scyllahide v1.4.760-a727ac3
Test program:
#include <windows.h>
#include <winternl.h>
int wmain() {
UNICODE_STRING ntdllPath;
RtlInitUnicodeString(&ntdllPath, L"\\??\\c:\\windows\\system32\\ntdll.dll");
HANDLE h;
OBJECT_ATTRIBUTES objAttrs = {
.Length = sizeof(OBJECT_ATTRIBUTES),
.RootDirectory = NULL,
.ObjectName = &ntdllPath,
.Attributes = 0x40,
};
IO_STATUS_BLOCK ioStatus;
NtOpenFile(&h,
/* access: */ 0x20000,
&objAttrs,
&ioStatus,
/* shareAccess: */ 5,
/* openOptions: */ 0);
NtClose(h);
LoadLibraryW(L"acgenral.dll");
return 0;
}
Steps:
- Set ScyllaHide profile to 'basic'.
- Start debugging the test program.
- Run.
EXCEPTION_ACCESS_VIOLATION
.
The crash occurs in DestroyMappedNtApi
at this line: if (*(PDWORD)pMappedApi != 0xB8D18B4C)
. The pMappedApi
points to unallocated memory because pMapping
is a section of the other DLL.
I'm not sure whether you must load "acgenral.dll" specifically, but I tried a few other DLLs and couldn't trigger the crash.
In the real-world scenario where this occurs, the NtOpenFile
+NtClose
combo is done by "apphelp.dll", which is loaded during Direct3D 10 initialisation where AMD libraries are loaded (e.g. "atidxx64.dll").
The problem stems from not clearing hNtdllFile
when the handle is closed – scyllahide assumes NtOpenFile
will always be followed by NtCreateSection
for the same file handle, which apparently is not true. Possible solutions: (a) hooking NtClose
and resetting hNtdllFile
if it gets closed, or (b) in HookedNtCreateSection
: checking the path associated with the FileHandle
(rather than comparing against hNtdllFile
).
As a workaround, simply skipping over the call to NtOpenFile
in "apphelp.dll" seems to be effective.
Activity