Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Crash when loading "acgenral.dll" #172

Open
bipface opened this issue Mar 5, 2025 · 0 comments
Open

Crash when loading "acgenral.dll" #172

bipface opened this issue Mar 5, 2025 · 0 comments

Comments

@bipface
Copy link

bipface commented Mar 5, 2025

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant