Windows操作系统中有很多种种方式可以检验应用程序运行记录，例如预读取文件（*.pf）、Shimcache、RecentFileCache.bcf、Amcache.hev、跳转列表等等，这些已经有很多资料介绍了。今天给大家介绍一个我最近才注意到的程序运行痕迹的地方——RADAR。

我们在Windows注册表编辑器中展开“\HKLM\SOFTWARE\Microsoft\ RADAR\HeapLeakDetection\DiagnosedApplications\”，可以看到该键有很多以程序名命名的子键，每个应用程序子键有一个名为“LastDetectionTime”的项。这些就是注册表中的RADAR数据。

下面是我在自己工作电脑上的注册表截图，可以看到Belkasoft Acquisition Tool、取证大师、FTK Imager、UFED PA、X-Ways Forensics等取证软件的记录，当然还有我们自家的手机神探（LY.exe）和取证神探。

以上图FTK Imager.exe为例，LastDetectionTime值为“1d61e8076a3cb58”，将其复制到取证神探时间解码工具中，选择FileTime格式，或使用免费的解码工具DCode选择FileTime格式进行解码，得知时间值为2020-04-30 07:46:54。

RADAR最后记录时间还可以通过对应注册表键的最后修改时间得知。最简单的方法是右击注册表键，点击“导出”,在对话框保存类型中选择“文本文件”，保存后用记事本打开即可看到对应注册表键最后修改时间。

关于RADAR，网上可以查到的中文资料不多。通过Google总算找到了少量的相关信息。RADAR是始于Windows 7的一种内存泄漏检测技术，可以自动检测出应用程序的内存泄露情况并进行定位，打包成错误报告后通过某种方式反馈给微软团队或软件开发者。

根据RADAR的原理，并非每次程序运行都会在注册表中产生记录，但如果注册表RADAR键中存在某个应用的记录，则说明该应用在对应时间点肯定运行过。经过实测，在Windows7到windows10最新版（1909）系统中都可以发现RADAR相关记录。

大部分人画组织结构图，最常见的画法是用Word中的文本框加连接线慢慢画，效率非常低。对于Office办公软件用的溜的人，也可能会使用Microsoft Office中的SmartArt功能生成组织结构图。

数据量小、结构简单的时候，SmartArt画组织结构图简单便捷。但一旦数据量比较大，例如传销组织，层级结构图便需要使用I2等专业工具生成了。但I2等商业工具授权昂贵，学习门槛高。今天介绍一种使用Markdown编辑器快速生成传销组织层级结构图的方法，对于会员数千个一下的情况，高效、便捷，生成的层级结构图还可方便地搜索。

Markdown是一种轻量级标记语法，用户可以用纯文本写作，最后生成带有各种富文本格式的html。因为其轻量化及易写易读的特性，深受程序员、文字写作者的喜爱。

Markdown语法中，对于代码段的处理非常简单，代码段前后各加三个“\`”（英文输入状态TAB键上面的键）即可。如果需要指明代码语言，直接在首行“\`\`\`”后面添加一个空格，然后写上语言即可，例如“\`\`\` php”即表示接下来是php代码。

绝大多数Markdown编辑器只支持常规的代码语言并在渲染成html页面的时候进行代码高亮的美化。标准的Markdown语法中是不支持例如流程图、数学公式等图书图像的，但也有不少Markdown编辑器额外增加了支持，例如马克飞象、CMD Markdown，甚至印象笔记、有道云笔记。

要画组织结构图，在Markdown代码开始标记“\```”后面添加“graph”即可，如果要指定方向，可在graph后添加“LR”或“TD”。“graphLR”表示父节点在左，子节点在右；“graphTD”表示父节点在上，子节点在下。层级机构格式为“A --> B”，表示B的父节点是A，每行一个关系表达式，各关系表达式之间不分先后顺序。

例如A的子节点为B和C，C的子节点为D，B的子节点为E、F。Markdown语法如下：

\``` graph
A --> B
A --> C
C --> D
B --> E
B --> F
\```

效果图如下：

下面针对传销组织人员数据库进行简单的示例操作。假设人员信息表如下表所示：

复制name、panme两列到记事本等文本编辑器中，pname在左，name在右。

公孙愉    习秋华
习秋华    晋丹
习秋华    代惜玉
习秋华    侍运诚
代惜玉    戴同
晋丹    商弘毅
侍运诚    张建国
商弘毅    仵旋
商弘毅    洛白容
张建国    运芮静
仵旋    蒋雪巧
仵旋    林运凡
运芮静    邰雪帆

使用文本编辑器的替换功能，用“ --> ”批量替换制表键，并在第一列添加“\`\`\` graphTD”,最后一列添加“\`\`\`”。

\``` graphTD
公孙愉 --> 习秋华
习秋华 --> 晋丹
习秋华 --> 代惜玉
习秋华 --> 侍运诚
代惜玉 --> 戴同
晋丹 --> 商弘毅
侍运诚 --> 张建国
商弘毅 --> 仵旋
商弘毅 --> 洛白容
张建国 --> 运芮静
仵旋 --> 蒋雪巧
仵旋 --> 林运凡
运芮静 --> 邰雪帆
\```

复制以上代码粘贴到支持流程图的Markdown编辑器中，即可自动生成组织层级结构图。下图是我在马克飞象中生成的。

Markdown是一个非常优美的语言，个人从学生时代就开始用，博客、邮件、工作笔记，基本全部在使用Markdown。Markdown语法支持加粗、斜体、段落、链接、图片、表格、引用等各种格式，不少Markdown编辑器还增加了待办清单等更多功能。

本文也是用Markdwon编辑器完成编写。

MAC地址是网卡的唯一标识符，在取证中非常重要。

开机取证

Windows
对于Windows操作系统，在命令提示符或Powershell中执行以下命令查看计算机的MAC地址：

ipconfig /all

macOS
对于macOS，在终端中输入并执行一下命令即可查看本机MAC地址

ifconfig /a
其中eth0表示以太网卡

Linux
按Ctrl+Alt+T快捷键打开终端，输入并执行以下命令即可查看网卡MAC地址

ifconfig

离线取证

根据SANS Windows Forensics Poster，对于Windows 7/8/8.1/10，注册表以下位置存在网卡信息

SOFTWARE\Microsoft\Windows NT\CurrentVersion\NetworkList\Signatures\Unmanaged
SOFTWARE\Microsoft\Windows NT\CurrentVersion\NetworkList\Signatures\Managed
SOFTWARE\Microsoft\Windows NT\CurrentVersion\NetworkList\Nla\Cache

这几天处理的一个案例中需要对浏览器缓存信息进行提取，中途遇到一点小插曲，和大家分享一下分析解决过程。检材镜像中安装了Windows 7 SP1旗舰版操作系统，取证软件为取证大师专业版，版本为V5.3.49418RTM。

使用取证大师执行自动取证解析得到IE浏览器缓存信息25条，点击取证结果“上网记录”→“Internet Explorer”→“缓存记录”节点左边的遍历按钮（多边形方框），然后在右边列表视图右击，选择“导出”→“导出勾选缓存关联文件”。

图1 导出IE浏览器缓存文件

按照预期，导出的应该是完整的25个文件，但实际结果却并不是这样——仅导出了15个文件，少了10个。

<图2 IE浏览器缓存文件导出结果>

按照同样的方法继续导出解析到的“Google Chrome”缓存信息。

图3 导出Google Chrome缓存文件

导出的结果同样让人疑惑，总共151个缓存记录，只导出了140个，少了10个。

图4 Google Chrome缓存文件导出结果

IE浏览器、Goolge Chrome同样出现这样的问题，让忙的团团转的我心头火上浇油，眼看着还有一大堆检材同样需要提取浏览器缓存，取证过程再出问题，很有可能无法按预定计划完成工作了。

急归急，出现问题还是要找原因并想办法解决的。

回头仔细看了一下Google Chrome缓存文件列表，终于发现了端倪。将列表按照文件大小排序一下可能比较明显。

图5 Google Chrome缓存文件列表

没错，有10个大小为零的文件。检查一下导出的文件，果然少掉的正好是这些文件。至此，Google Chrome缓存文件数量终于对上了。

莫非IE浏览器也是这个原因？赶紧回头看看。

图6 IE浏览器缓存文件列表

而然并非想象中那么简单。大小为零的记录确实存在，但数量并非预期的10，而是3。进一步查看导出的数据，有两个大小为零的文件竟然导出来了。越来越疑惑了！

图7 导出的IE浏览器缓存文件

回头继续看IE浏览器缓存文件列表及导出文件，发现IE浏览器缓存文件中，2017年的记录正好是10条。继续比对缓存数据列表和实际导出的文件，确定正好也是2017年的那10条记录没有对应的导出文件。难道是取证软件的BUG，导致导出的时候正好漏掉了2017年这个节点下的数据？根据个人经验，软件一般不会出现这种类型的BUG。

继续从其他地方思考吧！

检查IE浏览器和Goolge Chrome缓存信息的详细解析结果。

图8 IE浏览器缓存信息

图9 Google Chrome缓存信息

经过仔细观察对比，发现了一些有意思的地方。与Google Chrome相比，IE缓存信息中，每条记录都未解析出文件偏移。Google Chrome中，缓存记录的源文件集中在“分区1_本地磁盘[C]:\Users\Administrator.PC-20180317MHHL\AppData\Local\2345Explorer\User Data\Default\Cache\”目录下的data_1、data_2、data_3及f_000001、f_000002、……、f_000014、f_00000a、……、f_00000f等文件。IE浏览器，除了十条记录并没有源文件，其余的记录每个都有各自的源文件。没有源文件的记录正好是没有导出的那10个。由于路径太长，截图中未体现完整的路径。

至此，问题的答案呼之欲出。

我们继续一探究竟。取证大师取证结果中，每条记录右击，都可以选择“跳转到原文件”，跳转到解析出此条记录的文件。

对于IE浏览器，2018年的缓存记录跳转到原文件，一律是“对分区1_本地磁盘[C]:\Users\Administrator.PC-20180317MHHL\AppData\Local\Microsoft\Windows\WebCache\WebCacheV01.dat”，2017年的缓存记录原文件是“分区1_本地磁盘[C]:\Users\Default\AppData\Local\Microsoft\Windows\WebCache\WebCacheV01.dat”。

对于Google Chrome，大部分文件的原文件都是“分区1_本地磁盘[C]:\Users\Administrator.PC-20180317MHHL\AppData\Local\2345Explorer\User Data\Default\Cache\”目录下的data_1、data_2或data_3，"f_0000"开头的文件对应的原文件则是“分区1_本地磁盘[C]:\Users\Administrator.PC-20180317MHHL\AppData\Local\2345Explorer\User Data\Default\Cache\index”。

图10 IE浏览器缓存数据

图11 Chrome 缓存数据

看到这里，大家可能和我一样终于明白了过来：Google Chrome的缓存信息记录保存在“data_”开头文件的及index文件中，缓存的文件则保存在“data_”开头的文件及“f_0000”开头的文件中；IE浏览器缓存信息记录保存在WebCacheV01.dat文件中，缓存的文件则直接保存在IE浏览器的缓存目录下（文件夹名称一般都是“Content.IE5”），如果路径为空或者缓存文件已经不存在了，则无法导出文件。Google Chrome的缓存文件，导出到本地时，需要先到“data_”开头的文件及“f_0000”开头的文件中提取然后导出。

至此，这个案例中关于浏览器浏览器缓存文件导出数据与列表中的数据不一致的问题终于完全弄清楚了。其实，这个问题倒也算不上多复杂的取证问题，更多的是解决问题的思路。取证，绝不是简单地使用取证软件进行自动解析这么简单，取证软件仅仅是手段，用来辅助工作提高效率。调查员应该有自己的判断和思考，根据自己的经验和知识对取证软件给出的结果进行甄别。

再例如，取证大师显示的Google Chrome节点中，这些数据真的都是Google Chrome浏览器产生的吗？其实并不是，本案例中Google Chrome节点下的数据是由2345浏览器产生的，这一点从缓存信息对应的文件路径中也可以看出端倪。除了主流的浏览器取证大师会各自单独归到一个节点，其他基于Chromium开发的浏览器解析到的数据全都放到了“Google Chrome”节点下。这样做，不能说取证软件错了，而是调查人员应该主动去理解取证软件的处理逻辑。对于同一件事情，不同的取证厂商会根据自己的理解做出不同的处理方案。

软件只是外在，思维才是灵魂！