记一次 .NET某收银软件 非托管泄露分析

王常胜

一：背景

1. 讲故事

在我的分析之旅中，遇到过很多程序的故障和杀毒软件扯上了关系，有杀毒软件导致的程序卡死，有杀毒软件导致的程序崩溃，这一篇又出现了一个杀毒软件导致的程序非托管内存泄露，真的是分析多了什么鬼都能撞上。
前几天有位朋友找到过，我他们的程序内存在慢慢的泄露，最后程序会出现崩溃，不知道是什么导致的，让我帮忙看一下怎么回事，简单分析后发现是非托管泄露，让朋友开启了ust并在内存超出预期时抓了一个dump下来，接下来就是分析了。
二：WinDbg 分析

1. 到底是哪里的泄露

相信一直追这个系统的朋友应该知道怎么判断，很简单, 看下 MEM_COMMIT 和 HEAP 指标即可，使用 !address -summary 命令输出如下：

1. 0:000> !address -summary
3. --- Usage Summary ---------------- RgnCount ----------- Total Size -------- %ofBusy %ofTotal
4. Heap                                    678          93bd0000 (   2.308 GB)  65.39%   57.71%
5. <unknown>                              2610          3005d000 ( 768.363 MB)  21.26%   18.76%
6. Free                                    515          1e133000 ( 481.199 MB)           11.75%
7. Image                                  1526          118f8000 ( 280.969 MB)   7.77%    6.86%
8. Other                                    19           804e000 ( 128.305 MB)   3.55%    3.13%
9. Stack                                   390           4900000 (  73.000 MB)   2.02%    1.78%
10. TEB                                      73             49000 ( 292.000 kB)   0.01%    0.01%
11. PEB                                       1              1000 (   4.000 kB)   0.00%    0.00%
13. --- State Summary ---------------- RgnCount ----------- Total Size -------- %ofBusy %ofTotal
14. MEM_COMMIT                             4477          c51f9000 (   3.080 GB)  87.25%   77.00%
15. MEM_FREE                                515          1e133000 ( 481.199 MB)           11.75%
16. MEM_RESERVE                             820          1ccc4000 ( 460.766 MB)  12.75%   11.25%
19. --- Largest Region by Usage ----------- Base Address -------- Region Size ----------
20. Heap                                        38be0000            fd0000 (  15.812 MB)
21. <unknown>                                     cc6000           7fd9000 ( 127.848 MB)
22. Free                                        f7590000           88bf000 ( 136.746 MB)
23. Image                                       5ab2c000            e41000 (  14.254 MB)
24. Other                                        8cee000           7fb0000 ( 127.688 MB)
25. Stack                                       14610000             fd000 (1012.000 kB)
26. TEB                                         ffe51000              1000 (   4.000 kB)
27. PEB                                         fffde000              1000 (   4.000 kB)

复制代码

从卦中看，3G的提交内存，Heap 吃了 2.3G，也就表明是 NTHEAP 的泄露，这是一块非托管内存区域，一般都是 C/C++ 语言用 malloc 或者 new 分配的内存，接下来深挖下 NTHEAP 即可，使用 !heap -s 命令。

1. 0:000> !heap -s
2. SEGMENT HEAP ERROR: failed to initialize the extention
3. NtGlobalFlag enables following debugging aids for new heaps:
4.     stack back traces
5. LFH Key                   : 0x7c31b93c
6. Termination on corruption : DISABLED
7.   Heap     Flags   Reserv  Commit  Virt   Free  List   UCR  Virt  Lock  Fast
8.                     (k)     (k)    (k)     (k) length      blocks cont. heap
9. -----------------------------------------------------------------------------
10. 00200000 08000002  178304 138172 178304  42165  1747    56    0     34   LFH
11.     External fragmentation  30 % (1747 free blocks)
12. 006c0000 08001002    1088    224   1088     18     8     2    0      0   LFH
13. 00590000 08041002     256      4    256      2     1     1    0      0      
14. 006a0000 08001002    3136   1184   3136    153    82     3    0      0   LFH
15.     External fragmentation  12 % (82 free blocks)
16. 00570000 08001002    1088    224   1088     18     8     2    0      0   LFH
17. ...   
18. 15710000 08001002 2185152 2179432 2185152    442  1323   139    0      0   LFH
19. ...

复制代码

从卦中信息看， 15710000 吃了2.18G，也就表明它是吃内存的主力，这里简单说一下，00200000 是默认的进程堆，除了这个之外都是用非托管代码调用 Win32API 的 HeapCreate 方法创建出来的，接下来就得看下是什么代码创建的。
2. 到底是谁创建的

要想知道是谁创建的，一定要在注册表中开启 ust 选项，大家可以了解下 gflags.exe 工具，参考如下：

1. PS C:\Users\Administrator\Desktop> gflags /i Example_17_1_7.exe +ust
2. Current Registry Settings for Example_17_1_7.exe executable are: 00001000
3.     ust - Create user mode stack trace database

复制代码

开启之后 win32api 的 HeapAlloc 方法的内部中会到注册表中看一下是否有 ust 值，如果有就会记录分配的调用栈，这样就知道是谁创建的，抓取dump后可以用windbg的 !gflag 命令看下是否开启成功，参考输出如下：

1. 0:000> !gflag
2. Current NtGlobalFlag contents: 0x00001000
3.     ust - Create user mode stack trace database

复制代码

接下来对 Heap=15710000 进行一个 block 分组，看下是否有一些有价值的信息。

1. 0:000> !heap -stat -h 15710000
2. heap @ 15710000
3. group-by: TOTSIZE max-display: 20
4.     size     #blocks     total     ( %) (percent of total busy bytes)
5.     2cb dea4 - 26dd40c  (9.58)
6.     2d7 c778 - 23675c8  (8.72)
7.     d0 26d64 - 1f8e140  (7.78)
8.     7c5 2c50 - 1584990  (5.30)
9.     cb 14449 - 10125e3  (3.96)
10.     83c 16c2 - bb6578  (2.89)
11.     cf9 bc4 - 98a1a4  (2.35)
12.     1f51 3da - 789dfa  (1.86)
13.     ...

复制代码

从卦中数据看没有哪个size占用的特别高，接下来就依次从高往低看，发现都是和 prthook 有关，参考输出如下：

1. 0:000> !heap -flt s 2cb
2.     _HEAP @ 15710000
3.       HEAP_ENTRY Size Prev Flags    UserPtr UserSize - state
4.         1571f948 005d 0000  [00]   1571f960    002cb - (busy)
5.         15649d70 005d 005d  [00]   15649d88    002cb - (busy)
6.         ...
7.         3ec4b900 005d 005d  [00]   3ec4b918    002cb - (busy)
8.         3ec4bbe8 005d 005d  [00]   3ec4bc00    002cb - (busy)
9.         3ec4bed0 005d 005d  [00]   3ec4bee8    002cb - (busy)
10.         3ec4c1b8 005d 005d  [00]   3ec4c1d0    002cb - (busy)
11.         ...
13. 0:000> !heap -flt s 2d7
14.       HEAP_ENTRY Size Prev Flags    UserPtr UserSize - state
15.         15665550 005e 0000  [00]   15665568    002d7 - (busy)
16.         1566b930 005e 005e  [00]   1566b948    002d7 - (busy)
17.         1566df98 005e 005e  [00]   1566dfb0    002d7 - (busy)
18.         1566e288 005e 005e  [00]   1566e2a0    002d7 - (busy)
19.         ...
20.         39e3acc8 0061 0061  [00]   39e3ace0    002d7 - (busy)
21.         39e3c508 0061 0061  [00]   39e3c520    002d7 - (busy)
22.         39e3c810 0061 0061  [00]   39e3c828    002d7 - (busy)
23.         39e3cb18 0061 0061  [00]   39e3cb30    002d7 - (busy)
24.         39e3ce20 0061 0061  [00]   39e3ce38    002d7 - (busy)
26. 0:000> !heap -p -a 3ec4c1b8
27.     address 3ec4c1b8 found in
28.     _HEAP @ 15710000
29.       HEAP_ENTRY Size Prev Flags    UserPtr UserSize - state
30.         3ec4c1b8 005d 0000  [00]   3ec4c1d0    002cb - (busy)
31.         771dd969 ntdll!RtlAllocateHeap+0x00000274
32.         153e7439 prthook!MyShowWindow+0x0001d1f9
33.         153e543c prthook!MyShowWindow+0x0001b1fc
34.         153476ab prthook+0x000276ab
36. 0:000> !heap -p -a 39e3ce20
37.     address 39e3ce20 found in
38.     _HEAP @ 15710000
39.       HEAP_ENTRY Size Prev Flags    UserPtr UserSize - state
40.         39e3ce20 0061 0000  [00]   39e3ce38    002d7 - (busy)
41.         771dd969 ntdll!RtlAllocateHeap+0x00000274
42.         153e7439 prthook!MyShowWindow+0x0001d1f9
43.         153e543c prthook!MyShowWindow+0x0001b1fc
44.         153476ab prthook+0x000276ab

复制代码

3. prthook 到底为何方神圣

从前一节的卦中数据看，貌似 prthook 在不断的弹框，在弹框中用 ntdll!RtlAllocateHeap 分配了非托管内存，那 prthook 到底是个啥呢？可以用 lmvm 看下。

1. 0:000> lmvm prthook
2. Browse full module list
3. start    end        module name
4. 15320000 155dc000   prthook    (export symbols)       prthook.dll
5.     Loaded symbol image file: prthook.dll
6.     Image path: C:\Windows\SysWOW64\prthook.dll
7.     Image name: prthook.dll
8.     Browse all global symbols  functions  data
9.     Timestamp:        Thu Jun 22 17:16:53 2017 (594B8B05)
10.     CheckSum:         001F4972
11.     ImageSize:        002BC000
12.     File version:     16.17.6.22
13.     Product version:  16.17.6.22
14.     File flags:       0 (Mask 3F)
15.     File OS:          40004 NT Win32
16.     File type:        2.0 Dll
17.     File date:        00000000.00000000
18.     Translations:     0804.04b0
19.     Information from resource tables:
20.         CompanyName:      Beijing VRV Software Co.,Ltd
21.         ProductName:      edp
22.         InternalName:     prthook
23.         OriginalFilename: prthook.dll_DB
24.         ProductVersion:   16, 17, 6, 22
25.         FileVersion:      16, 17, 6, 22
26.         FileDescription:  prthook_DB
27.         LegalCopyright:   Copyright (C) 2016 Beijing VRV Software Co.,Ltd
28.         Comments:         中英文版

复制代码

从卦中数据看，prthook.dll 所属公司为 Beijing VRV Software Co.,Ltd，无语的是把这个第三方的dll放在Windows的系统目录 C:\Windows\SysWOW64 下，容易让人觉得有点 鸠占鹊巢，接下来查一下百度，发现是 北信源 的，截图如下：

有了这些信息，告诉朋友让客户把这个安全软件卸载掉就可以了。
三：总结

程序的故障如果不是我们的代码造成的，你想通过排查代码找出问题是不可能的事情，追过这个系列的朋友应该深有体会，常见的外在因素有：

• 杀毒软件
  
• 电磁辐射
  
• 显卡问题
  

来源:https://www.cnblogs.com/huangxincheng/Undeclared/17947054
免责声明：由于采集信息均来自互联网，如果侵犯了您的权益，请联系我们【E-Mail:cb@itdo.tech】 我们会及时删除侵权内容，谢谢合作！