反調試技術：檢測特定函數是否被下 CC 斷點 (0xCC)

原理說明

軟體斷點 (Software Breakpoint) 在 x86 架構下實際上是將目標指令的第一個位元組替換為 0xCC (INT 3 指令)。當執行流程命中該位置時，CPU 觸發中斷，調試器接管控制權。反調試邏輯即掃描目標函數入口處的機器碼，若發現 0xCC 則判定被下斷點。

實作代碼分析

[cpp]
DWORD WINAPI ThreadProc(LPVOID lpParam)
{
    // 取得 GetDlgItemText 在當前模組的實際位址
    typedef UINT (__stdcall * pGetDlgItemText)(HWND, INT, LPTSTR, INT);
    PBYTE pByte = (PBYTE)(pGetDlgItemText)::GetDlgItemText;

    // 掃描前 5 位元組 (典型熱補丁區域大小)
    for (int i = 0; i < 5; i++) {
        // 檢測是否為 0xCC：利用 XOR 性質，x ^ 0xCC == 0 當 x == 0xCC
        if (0 == (*pByte++ ^ 0xCC)) {
            MessageBox(NULL, "Find debugger!", NULL, MB_OK);
            // 實際場景可改為：終止進程、回報伺服器、執行混淆流程等
        }
    }
    return 0;
}

void CAntiCCFuncsDlg::OnOK()
{
    // 建立獨立執行緒週期性檢測，避免阻塞主 UI 執行緒
    CreateThread(NULL, 0, ThreadProc, NULL, 0, NULL);
}

關鍵技術點

1. 函數指標轉型：(PBYTE)(pGetDlgItemText)::GetDlgItemText 取得函數進入點位址。
2. 熱補丁區域：Windows API 函數入口通常預留 5 位元組 (MOV EDI, EDI + PUSH EBP...) 供熱補丁使用，也是斷點最常被植入的位置。
3. XOR 檢測技巧：byte ^ 0xCC == 0 等價於 byte == 0xCC，可略過分支預測副作用 (雖然現代編譯器優化後差異極小)。
4. 獨立執行緒輪詢：避免在主流程中同步檢測導致時序可被預測；實務上常搭配隨機延遲、多處交叉驗證。

局限性與繞過手段

• 硬體斷點 (DR0-DR3) 不修改代碼，掃描不到 0xCC。
• 頁面保護異常 (PAGE_GUARD) 實現隱形斷點。
• 動態二進制插桩 (如 Pin, DynamoRIO) 在翻譯層插入斷點。
• 攻擊者可 Hook CreateThread 或直接 NOP 掉檢測邏輯。

工程化建議

1. 將檢測目標擴展至關鍵業務函數、加解密入口、授權驗證點。
2. 檢測到斷點時不要彈窗 (如範例 MessageBox)，改為靜默記錄、延遲觸發保護邏輯 (如資料銷毀、功能降級)，增加逆向分析成本。
3. 結合校驗碼 (Checksum) 完整性驗證，防範代碼被修改而非單純下斷點。
4. 考慮使用 IsDebuggerPresent、CheckRemoteDebuggerPresent、NtGlobalFlag、Heap Flags 等多重反調試手段疊加。