您好,登錄后才能下訂單哦!
本篇內容介紹了“C#非托管泄漏中HEAP_ENTRY的Size為什么會對不上”的有關知識,在實際案例的操作過程中,不少人都會遇到這樣的困境,接下來就讓小編帶領大家學習一下如何處理這些情況吧!希望大家仔細閱讀,能夠學有所成!
前段時間有位朋友在分析他的非托管泄漏時,發現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 給挖出來,所以給了你各種假數據,言外之意就是 size
已經編碼了。
原因給大家解釋清楚了,那我能不能對抗一下,硬從NtHeap上將正確的size給推導出來呢? 辦法肯定是有辦法的,這篇我們就試著聊一聊。
其實原理很簡單,_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
在這個內存地址中下一個硬件條件,如果命中了,就可以通過匯編代碼觀察編解碼邏輯,對吧? 有了思路就可以開干了。
因為 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
,設置好之后就可以繼續 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
所屬的堆塊。
要想找到所屬堆塊,可以用內存搜索的方式,再用 !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
“C#非托管泄漏中HEAP_ENTRY的Size為什么會對不上”的內容就介紹到這里了,感謝大家的閱讀。如果想了解更多行業相關的知識可以關注億速云網站,小編將為大家輸出更多高質量的實用文章!
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。