0x00 Mona 2 前言 & 準備

---

Mona 2是一種非常有用的外掛，它由Corelan Team開發。起初是為Immunity Debugger寫的，現在它適用於WinDbg偵錯程式。

你將需要為WinDbg x86 和 WinDbg x64安裝一些工具：

安裝Python 2.7 (從這裡可下載到) 。

x86 和 x64版本的工具分別安裝在不同的目錄裡，如c:\python27(32) 和c:\python27。

從這裡下載正確的zip包（請下載pykd-0.2.0.29-python-2.7.zip這個壓縮包），接著提取並執行vcredist_x86.exe 和 vcredist_x64.exe。

從這裡下載兩個exe程式（x86版和x64版），接著執行它們。

從這裡下載windbglib.py和mona.py，並將它們放置到WinDbg.exe所在的目錄中。

配置符號搜尋路徑如下：

透過 File→Symbol File Path

輸入

SRV*C:\windbgsymbols*http://msdl.microsoft.com/download/symbols

3.儲存工作區(File→Save Workspace).

在WinDbg下執行mona.py

用WinDbg執行mona.py的範例:

1.使用如下命令載入pykd外掛

.load pykd.pyd

2.執行mona使用命令如下：

!py mona

更新mona 輸入如下：

!py mona update

0x01 配置

---

工作目錄

在mona的工作目錄裡，mona的多數函式將資料轉儲到已建立的檔案中。我們可以具體指定某個工作目錄，這取決於使用的格式說明符%p (process name) 和 %i (process id)指定的程式名和id。

例如，輸入：

workingfolder "C:\mona_files\%p_%i"

排除模組

你可以用如下操作排除指定模組:

!mona config -set excluded_modules "module1.dll,module2.dll"
!mona config -add excluded_modules "module3.dll,module4.dll"

作者

你也可以設定作者:

!mona config -set author Kiuhnm

當產生與metasploit相容的輸出內容時可以使用該資訊。

重點

如果WinDbg和mona都沒有出錯，那麼請試試以管理員身份執行WinDbg。

0x02 Mona的手冊

---

你可以在這裡找到更多關於Mona的資訊。

範例

該範例引用自Mona的手冊. 現在來說明如下程式碼中我們控制的ECX的值：

MOV   EAX, [ECX]
CALL   [EAX+58h]

我們想要使用那段程式碼以jmp到我們的shellcode(即我們注入到程式中的程式碼)，它的地址位於ESP+4，因此我們需要呼叫如上呼叫的一些指令，如“ADD ESP, 4 | RET“。上面的程式碼有許多間接的操作：

(ECX = p1) → p2
p2+58h → p3 → “ADD ESP,4 | RET”

首先我們需要找到p3:

!py mona config -set workingfolder c:\logs
!py mona stackpivot -distance 4,4

如上使用的命令可以讓你在stackpivots內的指定偏移範圍在mix~max之間找到等價於ADD ESP, X | RET程式碼的指標，透過選項-distance min,max來指定偏移範圍。

已發現指標/地址會被寫入到c:\logs\stackpivot.txt。

現在我們已經有我們的p3指標（許多p3指標！）了，我們還需找到p1:

!py mona find -type file -s "c:\logs\stackpivot.txt" -x * -offset 58 -level 2 -offsetlevel 2

下面來了解那些選項的含義：

使用“-x *”選項意味著你要 “accept addresses in pages with any access level” (正如另一個範例所示, 用 “-x X”選項說明我們僅在可執行頁中定位).

“-level 2”具體指定要間接操作的指令層級，它告知mona找出“a pointer (p1) to a pointer (p2)to a pointer (p3)”。 前兩個選項 (-type 和 -s)指定ps必須是指標，它被列出在檔案“c:\logs\stackpivot.txt“裡。

使用“-offsetlevel 2” 和 “-offset 58”選項告知mona用偏移58h來進行增值操作時，第二個指標(p2)必須指向第三個指標(p3)。

如果這個範例並不能讓你對其內容有較好的理解，請你不要擔心。這個範例僅向你展示了WinDbg中利用Mona外掛可以實現的一些功能。當然，我也承認這個命令的語法不是非常易懂。

範例

使用findwild命令可以讓你找到帶有特殊形式的指令鏈。 細想如下範例：

!mona findwild -s "push r32 # * # pop eax # inc eax # * # retn"

選項”-s”指定鏈的形態:

用 ‘#‘將指令分隔開

r32 為任意32位暫存器

• 為任意指令序列

可選引數為:

• -depth <nr>: maximum length of the chain
• -b <address>: base address for the search
• -t <address>: top address for the search
• -all: returns also chains which contain “bad” instructions, i.e. instructions that might break the chain (jumps, calls, etc…)

ROP鏈

Mona可以找到ROP gadgets並利用它們構造ROP鏈，但是我將不在這部分講解這方面的相關內容，因為這裡我假設你並不知道ROP鏈的含義及關於ROP的概念。正如我曾說過的，如果這篇文章講述的內容讓你難以理解，那麼請不要擔心。儘管學習該系列的下一部分文章吧。

0x03 結構化異常處理（SEH）

---

異常處理器以一種單連結串列的形式存在，它和每個執行緒有關。一般說來，連結串列的節點被分配在棧上。某一位於TEB (Thread Environment Block)的起始位置的指標指向連結串列頭，因此當程式碼想要新增一個新的異常處理器時，某一新節點會被新增到連結串列頭並且在TEB裡的指標所指向的位置會被改變，進而指向新節點。

每個節點固有_EXCEPTION_REGISTRATION_RECORD型別並且會儲存處理器的地址及連結串列下個節點的一個指標。奇怪的是，連結串列上一節點的“next pointer”不是null但是它等價於0xffffffff。

確切的定義如下：

0:000> dt _EXCEPTION_REGISTRATION_RECORD
ntdll!_EXCEPTION_REGISTRATION_RECORD
   +0x000 Next             : Ptr32 _EXCEPTION_REGISTRATION_RECORD
   +0x004 Handler          : Ptr32     _EXCEPTION_DISPOSITION

TEB可被段選擇子fs訪問（始於 fs:[0]）, 因此通常可看到程式碼如下：

mov    eax, dword ptr fs:[00000000h]      ; retrieve the head
push   eax                                ; save the old head
lea    eax, [ebp-10h]
mov    dword ptr fs:[00000000h], eax      ; set the new head
.
.
.
mov    ecx, dword ptr [ebp-10h]           ; get the old head (NEXT field of the current head)
mov    dword ptr fs:[00000000h], ecx      ; restore the old head

編譯器通常會註冊單個全域性控制程式碼，它能意識到被程式執行過的區域（這依賴於某一全域性變數）並且當它被呼叫時會有根據地作出行為。

因為每個執行緒都有一個不同的TEB，因此作業系統會確保段被fs選擇，fs總會引用準確的TEB（即當前執行緒之一）。 透過讀取與TEB的Self區域相符的 fs:[18h]得到TEB的地址。

列出TEB的資訊如下：

0:000> !teb
TEB at 7efdd000
    ExceptionList:        003ef804          -----------------------
    StackBase:            003f0000
    StackLimit:           003ed000
    SubSystemTib:         00000000
    FiberData:            00001e00
    ArbitraryUserPointer: 00000000
    Self:                 7efdd000
    EnvironmentPointer:   00000000
    ClientId:             00001644 . 00000914
    RpcHandle:            00000000
    Tls Storage:          7efdd02c
    PEB Address:          7efde000
    LastErrorValue:       2
    LastStatusValue:      c0000034
    Count Owned Locks:    0
    HardErrorMode:        0

現在我們可以證實fs引用TEB：

0:000> dg fs
                                  P Si Gr Pr Lo
Sel    Base     Limit     Type    l ze an es ng Flags
---- -------- -------- ---------- - -- -- -- -- --------
0053 7efdd000 00000fff Data RW Ac 3 Bg By P  Nl 000004f3

正如我們在之前講述過的， fs:18h含有TEB的地址:

0:000> ? poi(fs:[18])
Evaluate expression: 2130563072 = 7efdd000

記住：poi會對某一指標進行解引用操作並且使用‘?’來對某一表示式進行求值操作。 我們看看ExceptionList 指向的結構體名：

0:000> dt nt!_NT_TIB ExceptionList
ntdll!_NT_TIB
   +0x000 ExceptionList : Ptr32 _EXCEPTION_REGISTRATION_RECORD

正如我們已經說過的那樣，這意味著每個節點會是_EXCEPTION_REGISTRATION_RECORD的某一例項。使用!slist命令展示出整個連結串列的資訊：

0:000> !slist $teb _EXCEPTION_REGISTRATION_RECORD
SLIST HEADER:
   +0x000 Alignment          : 3f0000003ef804
   +0x000 Next               : 3ef804
   +0x004 Depth              : 0
   +0x006 Sequence           : 3f

SLIST CONTENTS:
003ef804
   +0x000 Next             : 0x003ef850 _EXCEPTION_REGISTRATION_RECORD
   +0x004 Handler          : 0x6d5da0d5     _EXCEPTION_DISPOSITION  MSVCR120!_except_handler4+0
003ef850
   +0x000 Next             : 0x003ef89c _EXCEPTION_REGISTRATION_RECORD
   +0x004 Handler          : 0x00271709     _EXCEPTION_DISPOSITION  +0
003ef89c
   +0x000 Next             : 0xffffffff _EXCEPTION_REGISTRATION_RECORD
   +0x004 Handler          : 0x77e21985     _EXCEPTION_DISPOSITION  ntdll!_except_handler4+0
ffffffff
   +0x000 Next             : ???? 
   +0x004 Handler          : ???? 
Can't read memory at ffffffff, error 0

記住$teb表示的是TEB的地址.

以下使用了一種更簡潔的方法來展示異常處理鏈的資訊：

0:000> !exchain
003ef804: MSVCR120!_except_handler4+0 (6d5da0d5)
  CRT scope  0, func:   MSVCR120!doexit+116 (6d613b3b)
003ef850: exploitme3+1709 (00271709)
003ef89c: ntdll!_except_handler4+0 (77e21985)
  CRT scope  0, filter: ntdll!__RtlUserThreadStart+2e (77e21c78)
                func:   ntdll!__RtlUserThreadStart+63 (77e238cb)
We can also examine the exception handler chain manually:
0:000> dt 003ef804 _EXCEPTION_REGISTRATION_RECORD
MSVCR120!_EXCEPTION_REGISTRATION_RECORD
   +0x000 Next             : 0x003ef850 _EXCEPTION_REGISTRATION_RECORD
   +0x004 Handler          : 0x6d5da0d5     _EXCEPTION_DISPOSITION  MSVCR120!_except_handler4+0
0:000> dt 0x003ef850 _EXCEPTION_REGISTRATION_RECORD
MSVCR120!_EXCEPTION_REGISTRATION_RECORD
   +0x000 Next             : 0x003ef89c _EXCEPTION_REGISTRATION_RECORD
   +0x004 Handler          : 0x00271709     _EXCEPTION_DISPOSITION  +0
0:000> dt 0x003ef89c _EXCEPTION_REGISTRATION_RECORD
MSVCR120!_EXCEPTION_REGISTRATION_RECORD
   +0x000 Next             : 0xffffffff _EXCEPTION_REGISTRATION_RECORD
   +0x004 Handler          : 0x77e21985     _EXCEPTION_DISPOSITION  ntdll!_except_handler4+0