摘要
報告詳細描述了逆向工程 Windows 安全中心 (WSC) 服務 API 的技術過程與發現，目的是開發名為「defendnot」的工具，該工具設計用於程式化地停用 Windows Defender。基於先前專案「no-defender」遇到的挑戰，該專案依賴於將程式碼注入現有防毒軟體 (AV) 二進位檔案，此研究旨在通過直接從系統提供的程序與 WSC COM API 互動，實現更乾淨的實作。調查包含對 wscsvc.dll 服務進行除錯，辨識關鍵的程序驗證機制，並克服顯著的環境障礙。主要發現包括辨識出特定的 SID 檢查、提升權限要求、數位簽章驗證以及 WSC 執行的 DllCharacteristics 檢查，特別是聚焦於 ForceIntegrity 旗標。本報告分析了揭示這些檢查的程式碼片段，並描述了用於辨識能夠繞過這些驗證的適當系統程序 (Taskmgr.exe) 的方法，最終成功通過 WSC API 實現模擬防毒軟體的註冊與狀態更新。
1. 簡介
Windows 安全中心 (WSC) 在 Windows 作業系統中扮演關鍵角色，負責彙總並監控包括防毒軟體、防火牆和更新設定的安全元件的狀態。WSC 提供了一個 API，允許已註冊的安全廠商與系統互動，通知其存在和狀態。此功能的目的為提供合法的安全應用程式使用。
先前的專案「no-defender」展示了通過利用現有防毒軟體的程式碼，程式化地影響 WSC 以停用 Windows Defender 的可行性。然而，此方法面臨法律挑戰，導致收到 DMCA 移除通知。這促使開發新的、更乾淨的實作「defendnot」，該實作將直接與 WSC API 互動，而不依賴第三方防毒軟體的二進位檔案。
2. 背景：Windows 安全中心與先前工作
WSC 是管理 Windows 上安全通知和安全軟體狀態的核心元件。它使用 COM API 與安全廠商互動。合法的防毒軟體使用此 API 向 WSC 註冊，通知系統其存在，並可能影響內建安全功能（如 Windows Defender）的行為。
「no-defender」專案利用此機制，通過使用第三方防毒軟體程式碼在 WSC 中註冊模擬的防毒軟體。這導致 WSC 辨識出另一個防毒軟體的存在，從而改變或停用 Windows Defender 的主動掃描行為。雖然有效，但依賴受版權保護的第三方程式碼導致其被移除。「defendnot」的開發旨在通過直接實作必要的 WSC API 互動，創建功能相似的工具，從而避免使用外部防毒軟體程式碼。這需要了解 WSC 如何驗證 API 呼叫的合法性。
3. 方法
「defendnot」的開發依賴於逆向工程 WSC 服務 (wscsvc.dll)，以辨識並繞過其內部程序驗證檢查。此過程歷經數天，涉及特定的技術步驟並克服顯著的環境挑戰。
最初，從「no-defender」專案中使用的相同防毒軟體的 WSC 註冊程式碼中衍生出參考實作。在 ARM64 Windows 虛擬機環境中從任意程序嘗試使用此 COM API 互動時，出現了 "access denied" 錯誤 ，這確認了程序驗證機制的存在。
臨時解決方案涉及將程式碼注入合法防毒軟體程序本身，利用其與 WSC 的固有信任。這允許通過 COM 呼叫成功註冊和狀態更新。然而，目標是消除對防毒軟體二進位檔案的依賴。
後續嘗試涉及將程式碼注入系統提供的二進位檔案，如 cmd.exe 和後來的 Taskmgr.exe，從這些程序中執行 WSC COM 呼叫。這些嘗試也失敗了，促使更深入地研究 WSC 服務的實作。
必須對 wscsvc.dll 進行逆向工程。此任務因開發環境而變得複雜：在 ARM64 MacBook Pro 上工作，缺乏適當的 x86 Windows 模擬進行除錯。通過在不同國家的朋友的 x86 PC 上執行的虛擬機建立了遠端除錯設置，通過 Parsec 存取，延遲較高 (~210ms)。除錯因 wscsvc.dll 是由 svchost.exe 載入的 DLL 且受到 Protected Process Light (PPL) 保護而進一步複雜化。為附加除錯器，必須暫時移除 PPL 保護，這通過在虛擬機上啟用測試模式並使用客制化的 kernel-mode 驅動程式實現。延遲和遠端存取限制顯著阻礙了除錯體驗。轉而使用 shadow.tech 服務提供了更好的低延遲環境，以繼續除錯。
4. 技術發現：WSC 程序驗證
對 WSC 服務的除錯揭示了對呼叫程序執行的特定檢查。從任意程序呼叫 WSC COM API 時遇到的初始 "access denied" 錯誤被追蹤到一個名為 WscServiceUtils::CreateExternalBaseFromCaller 的函數。
4.1 初始 SID 檢查 ( WscServiceUtils::CreateExternalBaseFromCaller )
分析 WscServiceUtils::CreateExternalBaseFromCaller 的反編譯程式碼片段，揭示了涉及檢查呼叫程序 token 的特定 Security Identifier (SID) 的主要驗證步驟。
該片段顯示：
此程式碼執行以下動作：
- RpcImpersonateClient ：服務模擬呼叫 RPC 方法的客戶端。這允許後續檢查針對客戶端的安全環境（其程序 token）執行。
- SID 轉換 ：將 hardcoded 字串 L"S-1-5-80-1913148863-3492339771-4165695881-2087618961-4109116736" 使用 ConvertStringSidToSidW 轉換為 SID 結構。此特定 SID 對應於 WinDefend 程序。
- Token 成員檢查 ：呼叫 CheckTokenMembership 以確定模擬的客戶端 token 是否具有已辨識的 WinDefend SID。結果儲存在 IsMember 變數中。
- 條件分支 ：根據 IsMember 的值，程式碼沿著兩個不同路徑之一繼續。如果 IsMember 為真（呼叫者具有 WinDefend SID），則採取一個分支。如果 IsMember 為假，則執行另一個分支。
最初假設擁有 WinDefend SID 將允許成功註冊。嘗試模擬 WinDefend SID 並呼叫 API 時返回 STATUS_SUCCESS，但實際上未發生註冊。進一步調查顯示，雖然擁有 WinDefend SID 允許互動，但它將 API 呼叫導向管理 WSC 對 Windows Defender 本身 的內部表示，無法簡單通過這些 API 呼叫停用。因此，註冊 新 外部防毒軟體的關鍵路徑在於 IsMember 為假的 else 分支。
4.2 次要檢查（非 WinDefend SID 路徑）
對於不具有 WinDefend SID 的程序，沿著 else 分支，WSC 服務執行一組次要驗證檢查。此路徑通向另一個函數，辨識為 CSecurityVerificationManager::CreateExternalBaseFromPESettings。
在此函數中，服務驗證呼叫二進位檔案的若干屬性：
- 提升權限 ：程序必須以提升的權限執行。
- 簽章檢查 ：二進位檔案必須具有有效的數位簽章。原始程式碼片段顯示從 GetCertContext 開始的呼叫鏈，並使用 CryptHashPublicKeyInfo 處理憑證資訊。
-
DllCharacteristics
旗標檢查
：檢查 Portable Executable (PE) 標頭的 OptionalHeader.DllCharacteristics 欄位中的特定旗標。原始程式碼片段說明了該過程：
- 開啟二進位檔案 (CreateFileW)。
- 建立檔案映射物件 (CreateFileMappingW)。
- 將檔案視圖映射到記憶體 (MapViewOfFile)。
- 取出 NT 標頭 (ImageNtHeader)。
- 存取 OptionalHeader.DllCharacteristics 欄位。
- 檢查最高有效位元 (SLOBYTE(v14->OptionalHeader.DllCharacteristics) < 0) 是否設定。此位元對應於 IMAGE_DLLCHARACTERISTICS_FORCE_INTEGRITY (0x8000) 旗標。
- 取消映射視圖 (UnmapViewOfFile)。
驗證邏輯要求呼叫程序必須是提升權限、簽署過的，並在其二進位標頭中設定 IMAGE_DLLCHARACTERISTICS_FORCE_INTEGRITY 旗標。
4.3 辨識適當的程序
為找到滿足這些要求的系統程序，在第 4.2 節中辨識的檢查被重新建立在一個單獨的工具 (wsc-binary-check) 中。此工具用於測試位於 System32 目錄中的各種二進位檔案。最初的目標 cmd.exe 未能通過這些檢查。在測試後，辨識出 Taskmgr.exe（工作管理員）為適當的候選者，可能具有所需的高權限、簽章和 ForceIntegrity 特性。
4.4 解決 RPC 錯誤
將 cmd.exe 替換為 Taskmgr.exe 作為注入的目標程序並未立即解決所有問題；RPC 錯誤仍然存在。進一步除錯顯示，這些錯誤並非源於 WSC 驗證，而是與如何將設定資料傳遞給注入程式碼的問題相關。
「defendnot」的設計使用一個檔案 (ctx.bin) 來從載入器傳輸序列化的參數到注入的 DLL，這是從「no-defender」專案保留的遺留物。確定此 ctx.bin 檔案路徑的函數錯誤地使用了 主機 程序 (Taskmgr.exe) 的基底資料夾，而不是注入的 模組 (nodefend.dll)。這導致程式碼讀取不存在或無效的 ctx.bin，導致將空位元組作為防毒軟體名稱傳遞給 WSC API，從而引發 RPC 錯誤。修正邏輯以正確定位並解析 ctx.bin 檔案解決了問題，允許從 Taskmgr.exe 程序內成功註冊和狀態更新。
5. 額外開發：自動執行
為「defendnot」實作自動執行機制也帶來了挑戰。使用工作排程器建立任務是一種常見方法。然而，初始嘗試失敗，因為建立的任務設定了預設設定，這些設定在某些條件下阻止執行。具體來說，任務被設定為僅在電腦使用交流電源時執行。取消此設定以及與電源和網路可用性相關的類似預設旗標解決了自動執行問題。
6. 結論
逆向工程工作成功闡明了 Windows 安全中心 COM API 採用的程序驗證機制。主要發現包括辨識出對 WinDefend SID 的主要檢查以及要求 提升權限、有效數位簽章和 IMAGE_DLLCHARACTERISTICS_FORCE_INTEGRITY 旗標 的次要驗證路徑。通過辨識並利用滿足這些次要要求的系統程序 (Taskmgr.exe)，並解決注入程式碼內部的通訊問題，「defendnot」的開發實現了相較於其前身的更乾淨的 WSC 互動實作。此過程突顯了除錯受保護 Windows 服務的複雜性以及開發環境限制的影響。雖然本報告詳細描述了技術發現，但預計將單獨發布更全面的 WSC 內部技術文件。