SE 2.3.8.0目前已知的最大反調試手段就是anti斷點，主要是anti了硬件斷點和int3軟斷點，加殼后無法對被加殼的程序下斷，客觀上提高了脫殼的難度，所以第一步是要想辦法把anti斷點去掉。
我的思路
         int3軟斷點的anti必然是基于內存效驗的方法（int3軟斷點需要修改內存代碼），對殼代碼進行hash效驗保護，如若發現內存有被修改，則結束進程。如果要patch掉內存hash效驗，必須知道hash代碼的位置，由于SE的垃圾混淆代碼很多，更本不可能通過搜索的方式獲取，最好的辦法就是用硬件斷點下一個讀取斷，所以問題就是要先修復硬件斷點。
對于硬件斷點，SE采用的是先通過SetThreadContext設置四個DRx寄存器為1byte讀取特定地址的斷點，然后通過在虛擬機中構造讀取特定地址以產生異常，再用SEH handler處理異常，并檢測DRx寄存器的值。如果該產生異常的時候沒有產生異常，又或者DRx的值不為先前SetThreadContext設定的值，那么就退出進程。
         對于內存斷點反anti，暫時沒有思路，還需要繼續研究。
處理過程
先獲取SE對DRx設置的值。
1、先在KiUserExceptionDispatcher下斷
2、斷下兩次后記錄 

3、CPU窗口中顯示調試寄存器
         DR0 =00E57016
         DR1 =00E57000
         DR2 =00E57004
         DR3 = 00E57008
         DR7 = 33330555
Patch  Shadow_CreateThread
由于SE會產生數個線程來進行反調試檢測，內存完整性檢測等，為了減少干擾項，把SE創建的檢測線程先patch掉，不讓他啟動，可能會對后面的程序運行有副作用，但是便于我一開始的脫殼調試。
         PS: SE會把NTDLL.dll 和krenel32.dll中的一些代碼Shadow到一段自己分配的空間中，所以需要利用內存搜索的方法，搜索特定代碼找到這些被Shadow的API。

• 先在KiUserExceptionDispatcher下斷
• 第一次斷下后，搜索特征代碼

#8BFF558BECFF751CFF7518FF7514FF7510FF750CFF75086AFFE8????????5DC21800#
搜索到的代碼：
                           

• 修改函數開頭位置為ret1800D1FB55   8BFF        mov   edi, edi      ;改成 ret 18

Patch Shadow_GetThreadContext
         SE會調用Shadow_GetThreadContext來檢測是否存在調試軟件下的硬件斷點，如果有就會退出進程。

• 在剛才搜索到Shadow_CreateThread的內存段內搜索特征代碼：

#8BFF558BECFF750CFF7508FF15????????85C00F8C??????0033C0405DC208009090909090#
搜索到的代碼：

• 如果直接修改以上代碼會被SE檢測到，我的方法是inline hook 函數調用KiFastSystemCall之前的地址（殼另外加載了一塊內存）       

//我構造的代碼

殼總是會判斷這 TlsValue 是否等于 Dr0+Dr1+Dr2+Dr3 之 Total 值
我們在殼欲取得 Drx 的值時，將之清為 0，并設 TlsValue 為 0

至于 SetTlsValue 的 Index 應為多少才對, 很多方法可以得知.
例如斷 Shadow 的 SetTlsValue ,XP SP2 用的 Index 是 4 , XP SP3 則是 6

Hook ExecuteHandler2
         這里是重頭戲，反anti 硬件斷點必須從這里開始，由于殼會檢測異常信息中的DRx寄存器，所以我們必須在SE 的SEH handler被調用前，給_CONTEXT結構中的DRx賦予之前獲得的特定值。
_CONTEXT結構如下：
typedef struct _CONTEXT
{
    DWORD ContextFlags;
    DWORD   Dr0;
    DWORD   Dr1;
    DWORD   Dr2;
    DWORD   Dr3;
    DWORD   Dr6;
    DWORD   Dr7;
    FLOATING_SAVE_AREA FloatSave;
    DWORD   SegGs;
    DWORD   SegFs;
    DWORD   SegEs;
    DWORD   SegDs;
    DWORD   Edi;
    DWORD   Esi;
    DWORD   Ebx;
    DWORD   Edx;
    DWORD   Ecx;
    DWORD   Eax;
    DWORD   Ebp;
    DWORD   Eip;
    DWORD   SegCs;
    DWORD   EFlags;
    DWORD   Esp;
    DWORD   SegSs;
}CONTEXT;

typedef struct _FLOATING_SAVE_AREA
{
    ULONG ControlWord;
    ULONG StatusWord;
    ULONG TagWord;
    ULONG ErrorOffset;
    ULONG ErrorSelector;
    ULONG DataOffset;
    ULONG DataSelector;
    UCHAR RegisterArea[80];
    ULONG Cr0NpxState;
} FLOATING_SAVE_AREA, *PFLOATING_SAVE_AREA;

• 在NTDLL.dll的CODE段中搜索特征碼

#558BECFF750C5264FF350000000064892500000000FF7514FF7510FF750CFF75#
搜索到的代碼:

• 構造inline hook 代碼

E8 00 00 00 00 5B 83 EB 05 81 EB 00 0600 00 3B 8B FC 0F 00 00 75 02 8B CB 33 DB FF D1 64 8B 2500 00 00 00 64 8F 05 00 00 00 00 8B E55D C2 14 

60 E8 00 00 00 00 5B 83 EB 06 81 C3 0008 00 00 8B FB 8B 74 24 24 B9 06 00 00 00 F3 A5 8B FB 83 C7 30 8B 74 24 2C B9 18 00 00 00 F3 A58B 83 90 00 00 00 8D 8B A0 00 00 00 C1 E0 02 03 C8 8B 7424 24 8B 46 0C 89 01 FF 83 90 00 00 008D 7B 30 8B 83 E8 07 00 00 89 47 04 8B 83 EC 07 00 00 8947 08 8B 83 F0 07 00 00 89 47 0C 8B 83F4 07 00 00 89 47 10 8B 83 F8 07 00 00 89 47 18 8B 44 2430 8B 4C 24 28 8D 7B 30 50 57 51 53 8B8B FC 07 00 00 33 C0 33 DB 33 FF 33 F6 FF D1 61 C3 00 00

• Inline Hook ExecuteHandler2Hook在這里.text:7C9232A6                 call    ecx   改成Jmp to // hook executehandler2 

Patch vm:ds[imm]
         這個地址是前面已經找到的，由于暫時還沒找到HASH檢測的代碼位置，所以不能直接改代碼，我的方法是，用腳本在這個位置上設置一個硬件執行斷點在，當腳本斷下后，腳本自動修改代碼跳轉到我們自己分配的空間內執行一段代碼，在代碼的開頭立即修復之前被腳本改掉的代碼，然后產生一個single step異常給系統，再執行之前由于改成跳轉沒有執行到的程序源碼后跳轉到原程序下一行繼續。
         這個方法是確定是要被占用一個硬件斷點。
以下是我構造的代碼：

Patch Shadow_SetThreadContext
  為了防止硬件斷點被覆蓋，這個Shadow函數必須Patch掉，當然，如果前面的部分沒有Patch 而直接來改這個函數，SE就不會獲得需要檢測的異常，造成程序的退出。
1、搜索代碼
通過之前patch Shadow_GetThreadContext獲得的調用KiFastSystemCall前代碼區域，查找調用服務號為0D5 的調用，

• 修改代碼只需要把跳入KiFastSystemCall的位置直接nop掉就行

FFE2            jmp     edx// 這里是跳入KiFastSystemCall，直接nop 

Patch掉HASH 計算
         通過上面幾步，現在我可以下硬件斷點了，能斷下來的第一件事，當然是找HASH效驗代碼。

• 在前面vm:ds[imm]的位置后面幾行下個硬件讀取斷點斷下之后：

• Run Trace 后獲得整個循環體，直接找到跳出循環的位置來到這里：

• 重新加載幾次之后，發現HASH計算的參數和結果是不變的，我只能說，呵呵

檢測開始位置：0E7C91D
檢測大小：       0093F9F
返回EAX：    F4E889ED
         

• 偷懶直接patch 掉

//------ Fix HASH------