@作者: ay @文章出處: cnss-ay的博客@Notice: 轉載請注明出處！若文章顯示不完整，可以到文章出處閱讀。
此文會涉及到一些普通堆的知識，這些內容可以參見我之前的文章 WINDBG的堆調試--了解HEAP組織
堆破壞
所謂的堆破壞，是說沒控制好自己的指針，把不屬于你分配的那塊內存給寫覆蓋了。這塊內存可能是你程序的數據，也可能是堆的管理結構。那么這個會導致怎樣的后果呢？可能的情況我們來yy下
- 把程序里的計算結果覆蓋了，這也許會讓你重復看了N次代碼，校驗了N次計算邏輯也搞不明白為何計算結果還是有問題
- 堆管理結構被破壞了，new/delete，或者malloc/free操作失敗
- 等等等等~
堆破壞較為理想的情況是被修改的數據會馬上導致程序crash，最差的情況是你的堆數據莫名其妙在今天被改了，但明天才crash。這個時候在去分析crash，就如我們的警察叔叔現在接手一樁10年前的案子一般----無從下手。老外稱之為heap corruption是很貼切的，有時候咱堆數據被意外篡改是無聲無息的，你也許沒法從界面甚至日志文件中看到它被篡改的一點跡象，當到某一個時刻，這種錯誤會暴露出來，然而這個時候查看堆信息也許會是毫無頭緒。所以對于堆破壞，咱的策略是盡早發現我們的堆被篡改了，最好能夠在堆數據被意外篡改的那一時刻誘發一個異常來提醒我們----兄弟，你的堆被腐蝕了。
微軟提供了一些方案，來幫助我們診斷堆破壞。一般來說，堆破壞往往都是寫數據越界造成的（yy的第二種情況，如果是第一種情況其實還簡單，下個內存斷點就好），所以微軟在堆分配上，給程序員門額外提供了2種堆分配模式--完全頁堆（full page heap），準頁堆(normal page heap)，用來檢測堆被寫越界的情況。
完全頁堆（full page heap）
檢測原理
完全頁堆的檢測基本思路是通過分配相鄰的一個頁，并將其設為不可訪問屬性，然后用戶數據塊會被分配到內存頁的最末端，從而實現越界訪問的檢測。當我們對堆中分配的內存讀寫越界后便會訪問到那個不可讀的頁，系統捕獲到改次異常后會試圖中斷執行并將該異常上報給debugger，或者崩潰。具體的內存組織結構如下圖
摘自《軟件調試》
與普通堆不同的是，內存塊前面的HEAP_ENTRY結構被DPH_BLOCK_INFORMATION結構取代，這個結構內部記錄了頁堆模式下這個內存塊的一些基本信息。如果用戶數據區前面的數據，也就是DPH_BLOCK_INFORMATION結構被破壞了，那么在釋放內存塊的時候系統會報錯，如果編程者對這塊內存塊讀寫越界了，當然，這里越界有幾種情況：
- 讀越界，但只是訪問了塊尾填充部分數據，那么系統不會報錯
- 寫越界，但只篡改了圖中塊尾填充的部分，那么在堆塊釋放的時候會報錯
- 讀越界，且超過了塊尾填充的部分，訪問到了柵欄頁，那么系統會立即拋出一個異常并中斷執行
- 寫越界，且超過了塊尾填充部分，寫到了柵欄頁，那么系統會立即拋出一個異常并中斷執行
這里需要注意的還是塊尾填充不一定存在，塊尾填充是因為要滿足堆內存的最小分配粒度，如果本身內存塊的分配粒度就已經是最小分配粒度的倍數了，那么塊尾填充就不存在了，比如堆內存分配粒度是是8 bytes，那么如果申請了14 bytes的話會有2 bytes的大徐小的塊尾填充塊，如果申請了24bytes，那么就沒有塊尾填充了，因為24正好是8的倍數。
示例
開啟全頁堆（用windbg目錄下的gflags或者裝一個appverifier都可以開啟），通過自己寫的一個heap.exe來看一下如何使用全頁堆檢測堆破壞情況heap.exe代碼如下：
#include "windows.h"
int main()
{
HANDLE heap_handle = HeapCreate( NULL , 1024 , 0 ) ;
char *temp = NULL ;
char *buffer = (char*)HeapAlloc(heap_handle , NULL , 128) ;
char *buffer1 = (char*)HeapAlloc(heap_handle , NULL , 121) ;
temp = buffer ;
for( int i = 0 ; i < 138 ; ++i )
{
*(temp++) = 'a' ;
}
HeapFree(heap_handle, 0 , buffer ) ;
HeapFree(heap_handle, 0 , buffer1 ) ;
HeapDestroy( heap_handle) ;
return 0 ;
}在第14行向buffer寫入138字節，這顯然越界了，然后在用windbg啟動heap.exe，直接運行，會發現報錯如下
0:000> g
(1f50.1f54): Access violation - code c0000005 (first chance)
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
eax=00000080 ebx=00000000 ecx=02596000 edx=02596000 esi=00000001 edi=00193374
eip=00191068 esp=0016fdc8 ebp=0016fddc iopl=0 nv up ei ng nz ac pe cy
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00010297
heap!main+0x68:
00191068 c60161 mov byte ptr [ecx],61h ds:0023:02596000=??
報了一個內存訪問錯誤，然后看一下調用堆棧
0:000> kb
ChildEBP RetAddr Args to Child
0016fddc 0019120f 00000001 023fbfd0 0239df48 heap!main+0x68 [d:\projects\heap\main.cpp @ 14]
0016fe20 765b1114 7ffd3000 0016fe6c 778eb429 heap!__tmainCRTStartup+0x10f [f:\dd\vctools\crt_bld\self_x86\crt\src\crtexe.c @ 582]
0016fe2c 778eb429 7ffd3000 757369d8 00000000 kernel32!BaseThreadInitThunk+0xe
0016fe6c 778eb3fc 00191357 7ffd3000 00000000 ntdll!__RtlUserThreadStart+0x70
0016fe84 00000000 00191357 7ffd3000 00000000 ntdll!_RtlUserThreadStart+0x1b
可以看到是第14行報的錯，但是14行的代碼運行了那么多次，我們再看一下這個時候變量i的值是多少
0:000> dv i
i = 0n128
顯然，在填充第128字節的時候，我們的temp指針訪問到了柵欄頁，從而報出了一個內存違規的異常。
這里順帶看一下如果我們分配的內存不是8 bytes的情況（一般堆內存分配粒度是8 bytes，所以申請128 bytes的內存時是不會有塊尾填充部分的）
那我們接下來看另外一段代碼
我們把第10行的temp = buffer改成temp = buffer1
因為buffer1申請了121 bytes，也就是說它有7 bytes的填充字節
0:000> g
(1ba0.1ba4): Access violation - code c0000005 (first chance)
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
eax=00000080 ebx=00000000 ecx=024c8000 edx=024c8000 esi=00000001 edi=00033374
eip=00031068 esp=002cfb80 ebp=002cfb94 iopl=0 nv up ei ng nz ac pe cy
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00010297
heap!main+0x68:
00031068 c60161 mov byte ptr [ecx],61h ds:0023:024c8000=??
0:000> dv i
i = 0n128
可以看到變量i還是128，也就是說我們還是在訪問到第128字節后才引發訪問異常，而不是我們期望的121字節后就引發異常。
這里也就是說如果我們的代碼中對申請的堆內存寫越界了，寫數據覆蓋塊尾填充部分的時候并不會引發異常！
但是，這并不代表我們的寫越界問題不會被發現。塊尾填充部分是會被填充上固定數據的，系統在適合的時機（比如銷毀堆的時候）會校驗塊尾填充塊，如果發現塊尾填充塊數據有變，那么便會報一個verifier異常，比如我們把代碼中的for循環次數改為124
for( int i = 0 ; i < 124 ; ++i )
那么windbg會中斷在第19行
HeapDestroy( heap_handle) ;
提示內容如下
=======================================
VERIFIER STOP 0000000F: pid 0x1E3C: Corrupted suffix pattern for heap block.
025A1000 : Heap handle used in the call.
025A7F80 : Heap block involved in the operation.
00000079 : Size of the heap block.
025A7FF9 : Corruption address.
=======================================
This verifier stop is not continuable. Process will be terminated
when you use the `go' debugger command.
=======================================
(1e3c.143c): Break instruction exception - code 80000003 (first chance)
eax=6c75e994 ebx=6c75cf58 ecx=00000002 edx=002bf461 esi=00000000 edi=000001ff
eip=6c753c38 esp=002bf6b4 ebp=002bf8b8 iopl=0 nv up ei pl nz na po nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000202
vrfcore!VerifierStopMessageEx+0x543:
6c753c38 cc int 3
提示說的很清楚了，appverifier指出了堆和具體的內存塊，我們這個時候查看buffer1的值是0x025a7f80 ，正好就是出問題的堆塊，出問題的地址是0x025a7ff79，正好就是buffer1內存塊的邊界，錯誤原因是Corrupted suffix pattern for heap block，也就是說咱塊尾填充部分（suffix pattern for heap block）被破壞（corrupted）了
結論：只要寫越界，系統都能夠檢測出來，只不過如果寫越界寫到了柵欄頁會理解觸發異常中斷，而寫越界只寫了塊尾填充部分，那么系統在適當時機（比如堆被銷毀，或者這塊內存被重新分配等時機）會對塊尾填充部分做完整性檢測，如果發現被破壞了，就會報錯。當然，你可以根據錯誤號（藍色字體部分）信息去appverifier的幫助文檔中查找更詳細的錯誤說明。
結構詳解
這次咱來倒敘，先從最基本的內存堆塊結構DPH_BLOCK_INFORMATION開始介紹，DPH_BLOCK_INFORMATION結構微軟也有對應文檔介紹
（摘自MSDN）
其中prefix start magic和prefix end magic是校驗塊，用來檢測DPH_BLOCK_INFORMATION是否被破壞，這些檢測部分屬于DPH_BLOCK_INFORMATION結構。我們先來用windbg探究下DPH_BLOCK_INFORMATION這個最基本的結構.再一次,我們打開windbg調試heap.exe.運行到第10行,這個時候變量的值是
0:000> dv heap_handle
heap_handle = 0x024a0000
0:000> dv buffer
buffer = 0x024a5f80 "???"
0:000> dv buffer1
buffer1 = 0x024a7f80 "???"
這里可以看到一個很有趣的現象,buffer1和buffer的地址正好相差8K,也就是兩個頁的大小.這當然是因為頁堆的原因啦,其實這兩塊內存分配是相鄰著的,虛擬內存結構如下圖所示
| buffer內存塊（4K） |
柵欄頁（4K） |
buffer1內存塊(4K) |
柵欄頁(4K) |
由于buffer和buffer1分配的大小是一樣的（buffer1加上尾部填充塊和buffer的大小相同），所以這兩塊內存正好相差8K
而DPH_BLOCK_INFORMATION就在我們申請的內存塊指針的前0x20字節處，用dt命令看的結果如下:
0:000> dt _DPH_BLOCK_INFORMATION 0x024a5f80-0x20
verifier!_DPH_BLOCK_INFORMATION
+0x000 StartStamp : 0xabcdbbbb
+0x004 Heap : 0x024a1000 Void
+0x008 RequestedSize : 0x80
+0x00c ActualSize : 0x1000
+0x010 Internal : _DPH_BLOCK_INTERNAL_INFORMATION
+0x018 StackTrace : 0x003d9854 Void
+0x01c EndStamp : 0xdcbabbbb
0x024a5f80-0x20就是DPH_BLOCK_INFORMATION結構的地址。DPH_BLOCK_INFORMATION結構在已分配和已釋放的狀態下，StartStamp和EndStamp（也就是MSDN圖中的prefix start magic和prefix end magic）是不同的，顯然dt輸出的結果看來，這個內存塊是已分配狀態。StackTrace記錄了分配這個內存塊時的調用棧，可以用dds來看一下這個內存塊被分配時候的調用棧
0:000> dds 0x003d9854
003d9854 00000000
003d9858 00004001
003d985c 00090000
003d9860 5b3b8e89 verifier!AVrfDebugPageHeapAllocate+0x229
003d9864 776d5c4e ntdll!RtlDebugAllocateHeap+0x30
003d9868 77697e5e ntdll!RtlpAllocateHeap+0xc4
003d986c 776634df ntdll!RtlAllocateHeap+0x23a
003d9870 003b1030 heap!main+0x30 [d:\projects\heap\main.cpp @ 8]
003d9874 003b120c heap!__tmainCRTStartup+0x10f [f:\dd\vctools\crt_bld\self_x86\crt\src\crtexe.c @ 582]
003d9878 76451114 kernel32!BaseThreadInitThunk+0xe
003d987c 7766b429 ntdll!__RtlUserThreadStart+0x70
003d9880 7766b3fc ntdll!_RtlUserThreadStart+0x1b
輸出結果我們可以看到這個內存塊是在main.cpp,也就是我們的示例代碼的第8行分配的，第8行是char *buffer = (char*)HeapAlloc(heap_handle , NULL , 128) 正好就是分配buffer內存的那條語句。這個結構的其它字段，顧名思義，ActualSize指明了實際分配字節數，0x1000 bytes也就是4K大小，Internal這個字段保存了個內部結構，用windbg也看不出這個結構信息。
當然為了防止內存塊前面的數據被沖刷掉，除了DPH_BLOCK_INFORMATION外，系統還通過DPH_HEAP_BLOCK保存了所分配內存塊的信息，
通過!heap –p –h [address] 可以查看到頁堆的信息
0:000> !heap -p -h 0x024a0000 //heap_handle的值
_DPH_HEAP_ROOT @ 24a1000
Freed and decommitted blocks
DPH_HEAP_BLOCK : VirtAddr VirtSize
Busy allocations
DPH_HEAP_BLOCK : UserAddr UserSize - VirtAddr VirtSize
024a1f6c : 024a5f80 00000080 - 024a5000 00002000
024a1f38 : 024a7f80 00000079 - 024a7000 00002000
可以看到，buffer內存塊對應的DPH_HEAP_BLOCK結構地址是024a1f6c
0:000> dt _DPH_HEAP_BLOCK 024a1f6c
verifier!_DPH_HEAP_BLOCK
+0x000 NextFullPageHeapDelayedNode : 0x024a1020 _DPH_HEAP_BLOCK
+0x004 DelayQueueEntry : _DPH_DELAY_FREE_QUEUE_ENTRY
+0x000 LookasideEntry : _LIST_ENTRY [ 0x24a1020 - 0x0 ]
+0x000 UnusedListEntry : _LIST_ENTRY [ 0x24a1020 - 0x0 ]
+0x000 VirtualListEntry : _LIST_ENTRY [ 0x24a1020 - 0x0 ]
+0x000 FreeListEntry : _LIST_ENTRY [ 0x24a1020 - 0x0 ]
+0x000 TableLinks : _RTL_BALANCED_LINKS
+0x010 pUserAllocation : 0x024a5f80 "???"
+0x014 pVirtualBlock : 0x024a5000 "???"
+0x018 nVirtualBlockSize : 0x2000
+0x01c Flags : _DPH_HEAP_BLOCK_FLAGS
+0x020 nUserRequestedSize : 0x80
+0x024 AdjacencyEntry : _LIST_ENTRY [ 0x24a1f5c - 0x24a1fc4 ]
+0x02c ThreadId : 0x3f4
+0x030 StackTrace : 0x003d9854 Void
從dt的數據看來，這個結構大小為0x34，buffer和buffer1的DPH_HEAP_BLOCK結構首地址正好也是相差0x34，說明這兩個結構是緊挨著的，下一步在讓我們來看看DPH_HEAP_BLOCK結構是如何組織的。
摘自《軟件調試》
這個是整個的頁堆結構圖，我們先來說說DPH_HEAP_BLOCK的組織吧，在圖中0x16d00000是頁堆的首地址，也就是頁堆的句柄，我們調試器中，頁堆首地址則是0x024a0000，為了數據統一，我還是拿0x024a0000作為堆句柄來講解。我們的DPH_HEAP_BLOCK其實就在堆塊節點池里邊，我們可以近似把這個節點池看成一個大型的DPH_HEAP_BLOCK數組，但有個地方在軟件調試中沒有提到，就是在win7下，運行時這些DPH_HEAP_BLOCK結構都是以二叉平衡數的結構來組織的，這個樹的結構的入口正是在TableLinks字段內，這么做的原因也大概是因為能夠在分配時更快的索。我們再看看DPH_HEAP_ROOT結構，這個結構儲存了整個頁堆的必要信息，它就相當于普通堆的_HEAP結構。
0:000> dt _dph_heap_root 24a1000
verifier!_DPH_HEAP_ROOT
+0x000 Signature : 0xffeeddcc
+0x004 HeapFlags : 0x1002
+0x008 HeapCritSect : 0x024a16cc _RTL_CRITICAL_SECTION
+0x00c NodesCount : 0x2c
+0x010 VirtualStorageList : _LIST_ENTRY [ 0x24a1fa0 - 0x24a1fa0 ]
+0x018 VirtualStorageCount : 1
+0x01c PoolReservedLimit : 0x024a5000 Void
+0x020 BusyNodesTable : _RTL_AVL_TABLE
+0x058 NodeToAllocate : (null)
+0x05c nBusyAllocations : 2
+0x060 nBusyAllocationBytesCommitted : 0x4000
+0x064 pFreeAllocationListHead : (null)
+0x068 FullPageHeapDelayedListTail : (null)
+0x06c DelayFreeQueueHead : (null)
+0x070 DelayFreeQueueTail : (null)
+0x074 DelayFreeCount : 0
+0x078 LookasideList : _LIST_ENTRY [ 0x24a1078 - 0x24a1078 ]
+0x080 LookasideCount : 0
+0x084 UnusedNodeList : _LIST_ENTRY [ 0x24a1ed0 - 0x24a16e4 ]
+0x08c UnusedNodeCount : 0x28
+0x090 nBusyAllocationBytesAccessible : 0x2000
+0x094 GeneralizedFreeList : _LIST_ENTRY [ 0x24a1f04 - 0x24a1f04 ]
+0x09c FreeCount : 1
+0x0a0 PoolCommitLimit : 0x024a2000 Void
+0x0a4 NextHeap : _LIST_ENTRY [ 0x5b3e9a58 - 0x23a10a4 ]
+0x0ac ExtraFlags : 3
+0x0b0 Seed : 0xfed6f13a
+0x0b4 NormalHeap : 0x027d0000 Void
+0x0b8 CreateStackTrace : 0x003d9824 _RTL_TRACE_BLOCK
+0x0bc ThreadInHeap : (null)
+0x0c0 BusyListHead : _LIST_ENTRY [ 0x24a10c0 - 0x24a10c0 ]
+0x0c8 SpecializedFreeList : [64] _LIST_ENTRY [ 0x24a10c8 - 0x24a10c8 ]
+0x2c8 DelayFreeListLookup : [257] (null)
+0x6cc HeapCritSectionStorage : _RTL_CRITICAL_SECTION
這里邊維護了很多運行時信息，比如說DPH_BLOCK_INFORMATION中的那個二叉樹入口其實就是保存在BusyNodesTable 字段，這里面記錄了所有被分配了的內存塊所對應的DPH_BLOCK_INFORMATION。當然，這里面一些信息軟件調試里面都有介紹，很多看名字也能夠猜到大概意思，看名字猜不到啥意思的字段，其實我也猜不到。。。-_-|||在創建頁堆后，所有內存分配都分配在頁堆中，通過分配的地址也能看得出來（我們分配的內存都是024a打頭），而非普通頁堆中，普通頁堆也僅僅只是保存一些系統內部使用的數據。一般來說，堆塊節點池加上DPH_HEAP_ROOT結構大小正好是4個內存頁，也就是16K。
優缺點
缺點：消耗大量虛擬內存，每塊內存的分配粒度是2個頁（8K），
優點：能夠立即捕獲越界讀寫操作，通過調用棧就可以追溯到問題源頭。能夠快速定位問題代碼。
使用建議：32位下不適宜跑配置文件結構比較復雜的軟件，讓我們來假設一個xml配置文件下有3000個節點，每個節點有5個字符串描述屬性，如果把這些配置文件信息轉化為stl結構來保存，那么每個節點則需要為此分配5*8K的空間，3000項配置則需要3000*5*8K=117MB虛擬內存，如果每個節點信息再多一些呢？這樣會導致虛擬內存耗盡從而出現一系列內存問題（比如，new失?。．斎?4位就不存在這種問題了7T的虛擬內存空間，現在看來應該是夠用了。
對于調試堆破壞來說，其實我們只要了解DPH_BLOCK_INFORMATION結構和DPH_HEAP_BLOCK中的基本字段就差不多了，這樣更方便我們定位出錯源頭。比如在appverifier報錯后（或者你程序自己莫名其妙崩潰或者數據被篡改后，要知道appverifier并不總是可信的），我們可以自己手動調試出錯的堆塊結構（DPH_BLOCK_INFORMATION，DPH_HEAP_BLOCK和DPH_HEAP_ROOT），檢測以下這些點：
- 檢測堆塊管理結構的校驗字段是否完整
- 是否塊尾填充部分有被修改過
- 檢測到未釋放或者重復釋放堆資源時，查看問題的堆塊被分配時的調用棧
其實頁堆還好，它有較強的實時性，所以并不需要太多手工調試的操作，越界讀寫都會立即觸發異常并且中斷，所以從這點看來，它是一些軟件用來檢測堆資源是否正確使用的必備良藥~ 但是相對于頁堆，準頁堆的調試則需要更好的去了解準頁堆工作原理了，因為它提供的堆塊檢測不是實時的，所以發現問題后，需要咱“精湛的調試內功“去找出源頭，關于準頁堆的東西，下回再說吧，敬請期待~