C#非托管泄漏中HEAP_ENTRY的Size對不上解析
一：背景
1. 講故事
前段時間有位朋友在分析他的非托管泄漏時，發(fā)現(xiàn)NT堆的_HEAP_ENTRY 的 Size 和 !heap 命令中的 Size 對不上，來咨詢是怎么回事？ 比如下面這段輸出：
0:000> !heap 0000000000550000 -a
Index Address Name Debugging options enabled
1: 00550000
Heap entries for Segment00 in Heap 0000000000550000
address: psize . size flags state (requested size)
0000000000550000: 00000 . 00740 [101] - busy (73f)
0000000000550740: 00740 . 00110 [101] - busy (108)
0:000> dt nt!_HEAP_ENTRY 0000000000550740
ntdll!_HEAP_ENTRY
+0x000 UnpackedEntry : _HEAP_UNPACKED_ENTRY
+0x000 PreviousBlockPrivateData : (null)
+0x008 Size : 0xa6a7
+0x00a Flags : 0x33 '3'
+0x00b SmallTagIndex : 0x75 'u'
...
從輸出中可以看到，用 !heap 命令的顯示 0000000000550740 的 size=0x00110 ，而 dt 顯示的 size=0xa6a7，那為什么這兩個 size 不一樣呢？ 毫無疑問 !heap 命令中顯示的 0x00110 是對的，而 0xa6a7 是錯的，那為什么會錯呢？ 很顯然 Windows 團隊并不想讓你能輕松的從 ntheap 上把當前的 entry 給挖出來，所以給了你各種假數(shù)據，言外之意就是 size 已經編碼了。
原因給大家解釋清楚了，那我能不能對抗一下，硬從NtHeap上將正確的size給推導出來呢？ 辦法肯定是有辦法的，這篇我們就試著聊一聊。
二：如何正確推導
1. 原理是什么？
其實原理很簡單，_HEAP_ENTRY 中的 Size 已經和 _HEAP 下的 Encoding 做了異或處理。
0:004> dt nt!_HEAP? ntdll!_HEAP ? ?... ? ?+0x07c EncodeFlagMask ? : Uint4B ? ?+0x080 Encoding ? ? ? ? : _HEAP_ENTRY ? ?...
那如何驗證這句話是否正確呢？接下來啟動 WinDbg 來驗證下，為了方便說明，先上一段測試代碼。
int main()
{
for (size_t i = 0; i < 10000; i++)
{
int* ptr =(int*) malloc(sizeof(int) * 1000);
printf("i=%d \n",i+1);
Sleep(1);
}
getchar();
}
既然代碼中會用到 Encoding 字段來編解碼size，那我是不是可以用 ba 在這個內存地址中下一個硬件條件，如果命中了，就可以通過匯編代碼觀察編解碼邏輯，對吧？ 有了思路就可以開干了。
2. 通過匯編觀察編解碼邏輯
因為 malloc 默認是分配在進程堆上，所以用 !heap -s 找到進程堆句柄進而獲取 Encoding 的內存地址。
0:004> !heap -s
************************************************************************************************************************
NT HEAP STATS BELOW
************************************************************************************************************************
LFH Key : 0x64ffdd9683678f7e
Termination on corruption : ENABLED
Heap Flags Reserv Commit Virt Free List UCR Virt Lock Fast
(k) (k) (k) (k) length blocks cont. heap
-------------------------------------------------------------------------------------
00000000004a0000 00000002 2432 1544 2040 50 12 2 0 0 LFH
0000000000010000 00008000 64 4 64 2 1 1 0 0
-------------------------------------------------------------------------------------
0:004> dt nt!_HEAP 00000000004a0000
ntdll!_HEAP
+0x000 Segment : _HEAP_SEGMENT
...
+0x07c EncodeFlagMask : 0x100000
+0x080 Encoding : _HEAP_ENTRY
...
0:004> dx -r1 (*((ntdll!_HEAP_ENTRY *)0x4a0080))
(*((ntdll!_HEAP_ENTRY *)0x4a0080)) [Type: _HEAP_ENTRY]
[+0x000] UnpackedEntry [Type: _HEAP_UNPACKED_ENTRY]
[+0x000] PreviousBlockPrivateData : 0x0 [Type: void *]
[+0x008] Size : 0x8d69 [Type: unsigned short]
[+0x00a] Flags : 0xfd [Type: unsigned char]
...
0:004> dp 00000000004a0000+0x80 L4
00000000`004a0080 00000000`00000000 000076a1`cefd8d69
00000000`004a0090 0000ff00`00000000 00000000`eeffeeff
可以看到 Encoding 中的 Size 偏移是 +0x008，所以我們硬件條件斷點的偏移值是 0x88 ，命令為 ba r4 00000000004a0000+0x88 ，設置好之后就可以繼續(xù) go 啦。
從圖中可以看到在 ntdll!RtlpAllocateHeap+0x55c 方法處成功命中，從匯編中可以看到。
- eax: 這是 Encoding ，即我們硬件斷點。
- edi: 某個 heap_entry 的 size 掩碼值。
最后就是做一個 xor 異或操作，也就是正確的 size 值。
0:000> r eax,edi
eax=cefd8d69 edi=18fd8ab8
0:000> ? eax ^ edi
Evaluate expression: 3590326225 = 00000000`d60007d1
0:000> ? 07d1 * 0x10
Evaluate expression: 32016 = 00000000`00007d10
可以看到最后的size=7d10, 這里為什么乘 0x10，過一會再說，接下來我們找一下 edi 所屬的堆塊。
3. 尋找 edi 所屬的堆塊
要想找到所屬堆塊，可以用內存搜索的方式，再用 !heap -x 觀察即可。
0:000> s-d 0 L?0xffffffffffffffff 18fd8ab8 00000000`005922b8 18fd8ab8 000056a0 004a0150 00000000 .....V..P.J..... 0:000> !heap -x 00000000`005922b8 Entry User Heap Segment Size PrevSize Unused Flags ------------------------------------------------------------------------------------------------------------- 00000000005922b0 00000000005922c0 00000000004a0000 00000000004a0000 7d10 20010 0 free 0:000> dt nt!_HEAP_ENTRY 00000000005922c0 ntdll!_HEAP_ENTRY +0x008 Size : 0x4020 +0x00a Flags : 0xa3 '' ...
有了這些信息就可以純手工推導了。
- 獲取 Encoding 值。
0:000> dp 00000000004a0000+0x88 L4 00000000`004a0088 000076a1`cefd8d69 0000ff00`00000000 00000000`004a0098 00000000`eeffeeff 00000000`00400000
- 獲取 size 值。
0:000> dp 00000000005922b0+0x8 L4 00000000`005922b8 000056a0`18fd8ab8 00000000`004a0150 00000000`005922c8 00000000`00a34020 00000000`00000000
- 異或 size 和 Encoding
0:000> ? 000076a1`cefd8d69 ^ 000056a0`18fd8ab8 Evaluate expression: 35192257382353 = 00002001`d60007d1 0:000> ? 07d1 * 0x10 Evaluate expression: 32016 = 00000000`00007d10
怎么樣，最后的size 也是size=7d10, 這和剛才匯編代碼中計算的是一致的，這里要乘 0x10 是因為 entry 的粒度按 16byte 計算的，可以用 !heap -h 00000000004a0000 ;觀察下方的 Granularity 字段即可。
0:000> !heap -h 00000000004a0000
Index Address Name Debugging options enabled
1: 004a0000
Segment at 00000000004a0000 to 000000000059f000 (000fa000 bytes committed)
Segment at 0000000000970000 to 0000000000a6f000 (000c9000 bytes committed)
Segment at 0000000000a70000 to 0000000000c6f000 (00087000 bytes committed)
Flags: 00000002
ForceFlags: 00000000
Granularity: 16 bytes
總結
這就是解答異或的完整推導邏輯，總的來說思路很重要，這些知識也是我們調試 dump 的必備功底，了解的越深，解決的問題域會越大。
以上就是C#非托管泄漏中HEAP_ENTRY的Size對不上解析的詳細內容，更多關于C# HEAP_ENTRY Size的資料請關注腳本之家其它相關文章！
相關文章
這篇文章主要介紹了C#中Invoke的用法講解,本篇文章通過簡要的案例,講解了該項技術的了解與使用,以下就是詳細內容,需要的朋友可以參考下2021-07-07
這篇文章主要介紹了C# DataTable中查詢指定字段名稱的數(shù)據,本文直接給出實例代碼,簡單易懂,需要的朋友可以參考下2015-06-06
Microsoft?Message?Queuing?(MSMQ)?是在多個不同的應用之間實現(xiàn)相互通信的一種異步傳輸模式,本文主要介紹了C#如何使用Microsoft消息隊列,需要的可以了解下2024-01-01
適配器模式：將一個類的接口轉換成客戶希望的另一個接口，Adapter使原本由于接口不兼容而不能一起工作的那些類可以一起工作2012-10-10
在本篇文章里小編給大家?guī)硪黄P于C# 服務器發(fā)送郵件失敗實例內容，需要的朋友們可以學習下。2020-03-03
這篇文章介紹了C#基于NPOI操作Excel的方法，文中通過示例代碼介紹的非常詳細。對大家的學習或工作具有一定的參考借鑒價值，需要的朋友可以參考下2022-04-04
這篇文章主要介紹了C# WebApi 異常處理解決方案,小編覺得挺不錯的，現(xiàn)在分享給大家，也給大家做個參考。一起跟隨小編過來看看吧2018-07-07
這篇文章主要介紹了C# Rx的主要接口深入理解的相關資料,需要的朋友可以參考下2017-03-03
本文主要介紹了在C#中使用NModbus4庫進行Modbus通信,文中通過示例代碼介紹的非常詳細,對大家的學習或者工作具有一定的參考學習價值,需要的朋友們下面隨著小編來一起學習學習吧2025-01-01
這篇文章主要為大家詳細介紹了C#如何利用Linq實現(xiàn)操作Xml文件，文中的示例代碼講解詳細，對我們學習C#有一定的幫助，感興趣的小伙伴可以跟隨小編一起了解一下2022-12-12