TitanHide: a kernel driver that hides debuggers from the process being debugged

What TitanHide hides, and from whom

TitanHide is a Windows kernel driver whose job is to make a debugger invisible to the process being debugged. The README states the driver "hooks various Nt* kernel functions (using SSDT table hooks) and modifies the return values of the original functions." A process that queries the kernel about its own debug state normally gets a truthful answer. With TitanHide loaded and configured for that process ID, it gets the answer the driver decides to return instead.

The documented feature list names the specific surfaces it covers: ProcessDebugFlags, ProcessDebugPort and ProcessDebugObjectHandle through NtQueryInformationProcess; DebugObject through NtQueryObject; SystemKernelDebuggerInformation through NtQuerySystemInformation; SystemDebugControl through NtSystemDebugControl; ThreadHideFromDebugger through NtSetInformationThread; and hardware breakpoint protection through NtGetContextThread and NtSetContextThread. There is also an NtClose entry, which the README describes as covering STATUS_INVALID_HANDLE and STATUS_HANDLE_NOT_CLOSABLE exceptions.

That list is the real scope of the project. It is not a general anti-anti-debug framework and it does not hide the debugger from the operating system itself. It edits what the kernel reports back to a chosen process. The audience is narrow: reverse engineers and malware analysts running a debugger against code that checks for one, inside a disposable VM they control.

SSDT hooks, a ProcessID, and a flag structure

The mechanism is a service descriptor table hook. On Windows, system calls from user mode land in kernel routines through the SSDT, and TitanHide replaces the entries for the Nt* functions it cares about with its own handlers. Each handler calls through to the original routine and then rewrites the result before returning it to the caller. Because the hook sits in the kernel, the target process cannot inspect the modified value before it arrives.

Activation is per process. The README says that "to hide a process, you must pass a simple structure with a ProcessID and the hiding option(s) to enable, to the driver." So the driver is not a global switch that hides everything from everything. You tell it which process to protect and which of the documented options to turn on. That granularity matters: enabling every option for a process that never asks those questions is wasted surface area, and enabling the wrong subset leaves obvious checks unanswered.

The README also notes that "the internal API is designed to add hooks with little effort, which means adding features is really easy." That is a design claim about the codebase rather than a user-facing feature, but it explains the repository layout: the top level contains a hooks/ directory and separate integration folders for x64dbg, OllyDbg, TitanEngine, plus a GUI and a test project. The driver core lives in TitanHide/, and the integrations are what most users actually touch.

Installing TitanHide and loading the driver

The README is blunt about prerequisites: "You need to disable PatchGuard and driver signing enforcement (DSE) before using this driver." It lists EfiGuard, SandboxBootkit, Shark and UPGDSED as projects that may help with PatchGuard, and notes that UPGDSED was archived in 2019. It does not walk through any of them. For signing, the documented route is test signing:

bcdedit /set testsigning on

After a reboot with test signing active, the installation is four steps. Copy TitanHide.sys into the drivers directory, create a kernel service pointing at it, start the service, then query it. The README gives these commands verbatim:

sc create TitanHide binPath= %systemroot%\system32\drivers\TitanHide.sys type= kernel
sc start TitanHide
sc query TitanHide

The first command registers the driver as a kernel service. The second loads it. The third reports whether the service is running. To confirm the driver is working rather than merely registered, the README points at DebugView or the log file C:\TitanHide.log.

For x64dbg users there is a plugin on the download page, which is the practical way to drive the driver. One documented wrinkle: for VMProtect 3.9.4 and above, the README says you must change the service name, for example to NotTitanHide, to bypass what it calls their latest detection. After renaming the service, the plugin needs to be told the new name from the x64dbg command line:

TitanHideName NotTitanHide

Note the shape of that instruction. The service name is not obfuscated by the driver; it is a string the target can read, so the workaround is cosmetic and version-specific.

PatchGuard, bug check 0x109, and the support boundary

The single largest constraint is stated in the first line of the README, in a warning that the maintainer will permanently ban people from the issue tracker for opening issues about installation problems, crashes with bug check 0x109: CRITICAL_STRUCTURE_CORRUPTION, or questions on how to disable PatchGuard. Read that as a support boundary rather than rudeness. SSDT hooking modifies kernel structures that PatchGuard is designed to watch, so on a system where PatchGuard is active the driver is not a supported configuration at all. The failure mode is a bug check, not a graceful refusal.

That has two consequences. First, the driver is unusable on a normal, fully protected Windows install. Second, the burden of making the environment suitable sits entirely with the user. The README names PatchGuard-bypass projects but takes no position on which works on which Windows build, and the test environment list ends at Windows 10. Windows 11 is not listed among the test environments, so anyone on Windows 11 is outside what the README documents.

The README also says plainly: "NEVER RUN THIS DRIVER ON A PRODUCTION SYSTEM, ALWAYS USE A VM!" Combined with the DSE and PatchGuard requirements, the intended deployment is a throwaway analysis VM, not a workstation and not a server. If your target only checks for a debugger through a user-mode API, or if you can patch the check in the binary instead, this driver is heavier than the problem requires. The README itself redirects people who cannot install it properly to ScyllaHide.

ScyllaHide and the difference in approach

The README's own recommendation for people who do not know how to install TitanHide is ScyllaHide, and the two take different routes to a similar goal. TitanHide is a kernel driver: it hooks Nt* functions in the SSDT and rewrites return values before they reach user mode, which is why it needs PatchGuard disabled and a service installed. ScyllaHide is the anti-anti-debug plugin family associated with x64dbg, and the related searches show people looking for it in x32dbg and IDA Pro contexts. It works from the debugger side, hooking the target's user-mode API calls rather than the kernel's.

That difference decides which one you want. A user-mode hook cannot be bypassed by a check that issues a raw system call, because nothing in user mode sits between the target and the kernel. A kernel SSDT hook can answer those calls, at the cost of an environment where PatchGuard and driver signing are disabled. Conversely, a kernel driver is far more invasive to set up, and a bug in it takes the machine down rather than the debugging session.

EfiGuard appears in both the README's PatchGuard list and the related searches, and it is worth being clear that it is not an alternative to TitanHide. It is one of the tools people use to reach the state TitanHide requires. The same applies to SandboxBootkit and Shark.

Licence, build, and what upgrades cost

TitanHide is MIT licensed. For a kernel driver that modifies kernel structures, the practical implication is that you may read, modify and redistribute the source, including commercially, provided the licence text travels with it. The MIT terms say nothing about the legal status of disabling PatchGuard or driver signing enforcement on a machine you do not own, and nothing here is legal advice; that question is separate from the licence and depends on where and on whose hardware you run it.

Building from source is documented in three steps: install Visual Studio 2022, install a WDK (the README links WDK10, WDK8 and WDK7), then open TitanHide.sln and compile. The repository also carries install.bat and release.bat at the top level, plus a TitanHideTest project, so there is a scripted path in addition to the manual sc commands.

Upgrade cost is where this project asks the most of its users. The last release is v0019, dated 2025-06-01, following v0018 in February 2025 and v0017 in January 2025. The last push to the repository was on 2026-07-18, so the codebase is not dormant, but each Windows build can change the kernel structures the hooks depend on, and the documented test matrix stops at Windows 10. There is no documented rollback procedure for the driver: the README covers sc create, sc start and sc query, but not how to cleanly remove the service or what happens if the driver is loaded when PatchGuard is later re-enabled. Anyone adopting it should assume they own that problem.

Editorial conclusion

TitanHide is for people who already run a Windows VM with PatchGuard and driver signing enforcement disabled and who need to hide a debugger from a specific process, usually through the x64dbg plugin. It is not for anyone on a production machine, and not for anyone unwilling to work around bug check 0x109 or rename the service to get past VMProtect 3.9.4 and above. Before adopting it, confirm your test environment matches the documented list (Windows XP through Windows 10, x86 and x64), decide how you will disable PatchGuard, and check C:\TitanHide.log or DebugView after sc start TitanHide to confirm the driver actually loaded.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. mrexodia/TitanHide on GitHub
4. README
5. Releases