TitanHide is a Windows kernel driver that hooks Nt* functions via SSDT table hooks to hide debuggers from anti-debug checks, intended for reverse engineering in isolated lab VMs.

TitanHide is a kernel-mode driver from mrexodia — the author behind the x64dbg ecosystem — that solves a problem every reverse engineer eventually hits: protected binaries detecting the debugger and refusing to behave. Rather than patching the target process in user mode, TitanHide operates one layer down, hooking various Nt* kernel functions through SSDT table hooks and rewriting the return values those functions produce. When a packed sample calls NtQueryInformationProcess to ask whether a debug port exists, the hook intervenes and serves up a sanitized answer. The repo carries roughly 2.9k stars, is written in C, ships under an MIT license, and openly self-describes with the rootkit topic tag — which is technically accurate, since SSDT hooking is classic rootkit territory repurposed here as an analysis aid.

The control model is deliberately minimal. To hide a process you pass a small structure containing a ProcessID and a bitmask of hiding options to the driver, and the driver applies only the requested deceptions to that process. This per-PID scoping matters for analysis hygiene: you conceal your debugger relationship with one target, not the entire system's semantics. The README emphasizes that the internal API is designed so additional hooks can be added with little effort, meaning the feature list is an extensible framework rather than a fixed bag of tricks. For a researcher studying a new protector, that extensibility is the difference between adapting the tool and fighting it.

The feature list reads like a checklist of the classic Windows anti-debug canon. Three of the covered checks ride on NtQueryInformationProcess: ProcessDebugFlags, ProcessDebugPort, and ProcessDebugObjectHandle, which are the standard queries protectors use to sniff an attached debugger. There is also coverage of DebugObject via NtObject, SystemKernelDebuggerInformation via NtQuerySystemInformation, and NtSystemDebugControl. Two entries are particularly practitioner-relevant: the NtClose hook neutralizes the invalid-handle probe, where a target deliberately closes a bogus handle and watches whether STATUS_INVALID_HANDLE or STATUS_HANDLE_NOT_CLOSABLE exceptions surface only under a debugger, and the DRx protection strips hardware breakpoint registers out of NtGetContextThread/NtSetContextThread so hardware breakpoints in DR0–DR3 stay invisible.

Compatibility is broad by kernel-driver standards. The README lists test environments spanning Windows 10, Windows 8.1, and Windows 7 in both x64 and x86 flavors, plus Windows XP x86 SP3 and x64 SP1. That legacy reach matters because a significant slice of malware analysis still happens on older images, and most modern hide drivers abandon anything pre-Windows 10. The build path is conventional for WDK work: install Visual Studio 2022, install the appropriate WDK10, WDK8, or WDK7 for your target era, open TitanHide.sln, and compile. The fact that the solution supports three WDK generations tells you the codebase is structured around per-platform compatibility rather than targeting only the newest kernel.

The operational burden is where this tool separates casual users from serious ones. The README states plainly that you must disable both PatchGuard and driver signing enforcement (DSE) before the driver will function on x64 systems, and the author's opening paragraph is an unusually blunt warning: do not file issues about installation problems, CRITICAL_STRUCTURE_CORRUPTION bug check 0x109, or how to disable PatchGuard — if you need to ask, the recommendation is to use ScyllaHide, the user-mode alternative, instead. That stance is worth internalizing. 0x109 is precisely what PatchGuard throws when it detects tampered kernel structures like a hooked SSDT, so encountering it means the prerequisites were not met, not that the tool is broken.

For loading, the README offers the test-signing route with bcdedit /set testsigning on, and points to several third-party PatchGuard-disabling projects (EfiGuard, SandboxBootkit, Shark, and the archived UPGDSED) without endorsing any particular one. We will not walk through that chain here; it is documented in the repo for those with legitimate lab setups, and every one of those steps materially weakens the security posture of the machine it runs on. The analysis point is that the requirement itself defines the deployment boundary: any system running TitanHide is a system whose kernel integrity guarantees have been deliberately switched off, which is only acceptable in a disposable analysis VM.

Installation follows the classic kernel-service pattern: copy TitanHide.sys to %systemroot%\system32\drivers, then use sc create with type= kernel followed by sc start and sc query to manage the service. Diagnostics are refreshingly transparent — the driver logs to C:\TitanHide.log and emits debug output visible in DebugView, so verifying that hooks are actually engaging is straightforward. For x64dbg users there is a dedicated plugin available on the download page, which handles the driver communication from the debugger side and toggles hiding options per debugged process without manual DeviceIoControl calls.

One detail in the README doubles as a small case study in the arms race between protectors and hide tools. For VMProtect 3.9.4 and above, the protector checks for a service literally named TitanHide, so the documented workaround is creating the service under a different name and configuring the plugin with the TitanHideName command in x64dbg. This is signature-based detection at its crudest — scanning for a known string rather than detecting the hooking behavior — and it illustrates why defenders should not rely on name-based IOCs when auditing for kernel tampering.

From a defensive perspective, TitanHide is valuable to understand precisely because its techniques overlap with those of real malicious rootkits. A blue team hunting this class of activity has several concrete angles: PatchGuard itself firing 0x109 on x64, the presence of test-signing boot configuration, kernel services whose binaries live in the standard drivers directory but lack valid signatures, and unexpected SSDT divergence relative to the on-disk ntoskrnl.exe. EDR products that monitor driver loads and service creation events will catch the setup phase even when the hooking phase is quiet. The C:\TitanHide.log artifact is also a giveaway if defaults are unchanged.

It is worth situating TitanHide against ScyllaHide, which the author himself recommends as the gentler alternative. ScyllaHide works largely in user mode and handles the majority of commercial protectors without kernel involvement; TitanHide exists for the harder cases where user-mode hooks get detected or bypassed. The trade is capability versus blast radius — a kernel driver that can defeat deeper checks, at the cost of PatchGuard conflicts, signing requirements, and a genuine blue-screen risk on misconfiguration. Choosing between them is a per-engagement decision based on how aggressive the target's anti-debug layer actually is.

The final remark in the README deserves emphasis because it is the whole governance model in one sentence: never run this driver on a production system, always use a VM. TitanHide deliberately corrupts the assumptions the Windows kernel makes about its own syscall table, and it does so with MIT-licensed, readable source. Used inside a snapshot-managed lab for authorized malware analysis, software protection research, or interdiction of packed threats, it is a legitimate and well-engineered instrument; pointed at production infrastructure, it is functionally a rootkit. The repo's own topics list says both things at once, and that honesty is part of why it has earned its standing in the reverse engineering community.

Educational analysis for authorized security professionals. Use only in controlled, authorized environments.

Related coverage

• Inside PPLwindow: how a win32k syscall mishandle breaks Windows protected process boundaries


• Inside QuickAssist_UAC_Bypass: how a UIAccess binary defeats always-notify UAC


• Automating AI-assisted code audits with seclab-taskflow-agent