You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
Host: x64dbg on Windows 10
Plugin: scyllahide v1.4.760-a727ac3
Test program:
Steps:
EXCEPTION_ACCESS_VIOLATION
.The crash occurs in
DestroyMappedNtApi
at this line:if (*(PDWORD)pMappedApi != 0xB8D18B4C)
. ThepMappedApi
points to unallocated memory becausepMapping
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 assumesNtOpenFile
will always be followed byNtCreateSection
for the same file handle, which apparently is not true. Possible solutions: (a) hookingNtClose
and resettinghNtdllFile
if it gets closed, or (b) inHookedNtCreateSection
: checking the path associated with theFileHandle
(rather than comparing againsthNtdllFile
).As a workaround, simply skipping over the call to
NtOpenFile
in "apphelp.dll" seems to be effective.The text was updated successfully, but these errors were encountered: