Abstract:

This blog post recounts the author's challenging experience reverse engineering Windows Security Center (WSC) to create defendnot, a tool designed to disable Windows Defender by legitimately registering itself as an antivirus. Undertaken during a vacation without ideal technical resources, the project involved analyzing WSC's COM API and discovering its stringent validation mechanisms, including checks for Protected Process Light (PPL), specific Security Identifiers (SIDs), binary signatures, and DLL characteristics flags. The author details the difficulties of debugging in a high-latency remote environment and the iterative process of identifying a suitable system process (Taskmgr.exe) for code injection after overcoming initial impersonation failures and configuration reading errors. The successful implementation highlights the complexities of interacting with protected Windows services and the dedication required to navigate such technical hurdles under adverse conditions.

The Challenging Journey to Disable Windows Defender via WSC Reverse Engineering

• Context (Before Day 1): Following a DMCA takedown of his previous no-defender project (which used third-party AV code), the author aimed to build defendnot, a "clean" tool to disable Windows Defender by registering with Windows Security Center (WSC). This effort began during a vacation in Seoul, significantly complicated by the lack of a local x86 machine and reliance on remote access.
• Day 1: Initial Research & Access Denied: Began investigating WSC's COM API, using a previous legitimate antivirus implementation as a reference. Direct calls to register failed with "access denied," leading to the hypothesis that WSC validates the calling process. Successfully registered an AV status by injecting code into a process already authorized by WSC (from the reference AV).
• Day 1: Discovering PPL Checks: Attempted to inject code into cmd.exe, but calls failed. Reverse engineering wscsvc.dll revealed that WSC checks if the caller process is Protected Process Light (PPL), which cmd.exe was not.
• Day 2: Establishing a Difficult Debugging Environment: Faced significant challenges debugging wscsvc.dll remotely due to high latency (~210ms) between the author's ARM Mac (via Anydesk) and a friend's PC running a debugging VM (via Parsec), severely hindering progress.
• Day 2: Uncovering SID Checks and Impersonation Failure: Used a kernel driver (in test mode) to remove PPL protection on the VM, allowing debugger attachment. Found that WSC's primary validation (WscServiceUtils::CreateExternalBaseFromCaller) checks for a specific WinDefend SID on the caller's token. An attempt to impersonate WinDefend failed, as this access path was not for standard AV registration.
• Day 3: Identifying Signature and DllCharacteristics Checks: Analyzed the alternative validation path used when the WinDefend SID check fails. Discovered it requires the caller process to be elevated and passes checks in CSecurityVerificationManager::CreateExternalBaseFromPESettings, which verifies the binary's signature and specifically the ForceIntegrity flag in its DllCharacteristics.
• Day 3: Selecting Taskmgr & Overcoming Configuration Error: Created a tool to test System32 binaries against the discovered checks; Taskmgr.exe was found to be suitable. Attempted injection into Taskmgr.exe, but RPC calls still failed. Due to persistent debugging difficulties on the friend's VM, the author switched to a paid Shadow.tech VM ($30), which offered a better environment. Discovered the failure was caused by an invalid AV name being passed due to faulty logic for reading a configuration file (ctx.bin) when injected into Taskmgr. Fixing the path logic allowed successful AV registration via injection into Taskmgr.exe.
• Day 4: Resolving Autorun Task Issues: The final step involved implementing autorun using Task Scheduler, which initially failed. The issue was traced to default task settings requiring AC power and a network connection. Unsetting these flags resolved the problem and completed the project.
• Overall Takeaway: The author successfully implemented defendnot to disable Windows Defender by interacting with WSC via injecting into Taskmgr.exe, navigating complex validation rules (PPL, SID, Signature, DllCharacteristics) and overcoming extreme debugging environment limitations. The experience, though successful, was marked by significant technical challenges.