对福昕pdf阅读器的一次"讨伐"——为何要这样？

　　0、引言

　　“讨伐”的背景是这样的，福昕pdf阅读器打开看着某某文档，然后其中有一段文字我想复制下，大概四五十个字吧，然后就莫名其妙的Crash了。由于之前工作的原因，我的注册表里一直挂着JIT，所以，Windbg就跳出来，静静的等着我来干点啥。分析之余，想不到为什么会有这样的“怪异写法”。

　　1、案发的第一现场

　　先来看下案发时，当时的上下文是什么样子的，如下图所示，根据经验，基本可判断是个0xC0000005异常了。

　　出bug的模块名为frdvpr_drv，出bug的函数据Windbg报告为DrvQueryDriverInfo，但这个肯定是不对的，函数内部偏移为0x2c681即181889，都快180K了，常规的函数不可能这么大。造成Windbg出错的原因是没有合适的PDB。好了，先看下frdvpr_drv这个模块的具体信息，如下：

　　根据时间戳来看，还挺新，版本也不是特别老。官网的最新版如下；

　　好了，现在可以确认下具体触发此次异常的原因了，执行如下指令：

　　0:007> .exr -1 ExceptionAddress: 00007ff87380cb21 (frdvpr_drv!DrvQueryDriverInfo+0x000000000002c681) ExceptionCode: c0000005 (Access violation) ExceptionFlags: 00000000 NumberParameters: 2 Parameter[0]: 0000000000000000 Parameter[1]: 00000000067e5044 Attempt to read from address 00000000067e5044

　　没错了，就是Access violation错误导致的此次惨状。看下00000000067e5044地址附近的数据：

　　看来这个page的状态是free或者reserved的。反正就是不可访问的，至于到底是哪种状态，下边来详谈。再来看下堆栈，看看哪里过来的。

　　貌似是新开的一个线程，刚开始干点事情就挂了。但有一个数据引起了我的注意，就是红框上边的这个数据，看看与之前错问题的Addr，貌似比较接近。你先不要着急，我知道x64下，函数的调用约定规定前四个参数是通过寄存器传递的，但不意味着就不能在home栈中备份一下某些数据，比如这里的数据。我们来看下这个地址附近的数据：

　　是个unicode串，也正是我复制的那一段话，原文如下：

　　好了，案发第一现场到此结束，下边开始溯源吧。

　　2、触发此bug的罪魁祸首

　　溯源之前，我们先来看下当前这一帧函数在干啥，根据异常地址，在Windbg的反汇编界面中往上稍微翻译下，可以找到该函数的开头，如下：

　　其实，看到这个函数sig，我基本可以确认这是个memcpy或者memmove之类的函数，因为之前遇到过类似的问题，看过这两个函数的源码，印象深刻。不知道也没关系，下边用IDA来打开下，因为IDA可以根据sig识别出库函数。

　　0:007> ?00007ff8`7380cb21-frdvpr_drv Evaluate expression: 314145 = 00000000`0004cb21

　　把0004cb21偏移加到Imagebase上即可跳转到对应的位置，如下：

　　颜色就已经出卖了这个函数，意味着它是一个库函数，旁边的注释表明它是一个memmove函数。翻到函数开头，如下：

　　有两个重要信息需要说明下：

　　1、r11中存储的是原始的rcx的值，即r11—->Dst;

　　2、rdx中存储的是rdx-rcx的值，可通过它找到Src的值;

　　另外，简单分析下就可知道，在该函数的下边，r11，rdx和r8三个寄存器都是作为只读寄存器存在的，没有被修改过。现在还原这三个寄存器的值，如下：

　　0:007> r r11,rdx,r8 r11=00007ff873cdea80 rdx=ffff800792b063c0 r8=0000000000000206 rdx的最初值为ffff800792b063c0+00007ff873cdea80=00000000`067e4e40 可得三个参数如下： Dst：00007ff873cdea80 Src：00000000`067e4e40 Size：0000000000000206

　　下边来看下，当前这两个内存区的数据：

　　0:007> du 00007ff873cdea80 00007ff8`73cdea80 "所有的组合电路都是不..可信的。是的，往往有很多的毛刺啊，或者中" 00007ff8`73cdeac0 "间过程啊不可避免的出现，这" 0:007> du 00000000`067e4e40 00000000`067e4e40 "所有的组合电路都是不..可信的。是的，往往有很多的毛刺啊，或者中" 00000000`067e4e80 "间过程啊不可避免的出现，这"

　　当前已经复制的长度如下：

　　0:007> ?rcx-r11 Evaluate expression: 516 = 00000000`00000204

　　而触发Crash的那个内存地址相对于Src的地址的偏移如下：

　　00007ff8`7380cb21 mov ax,word ptr [rdx+rcx] ds:00000000`067e5044=???? 0:007> ?00000000`067e5044-00000000`067e4e40 Evaluate expression: 516 = 00000000`00000204

　　这两个是吻合的上的，现在看来，导致Crash的原因可能如下：

　　1、Size有问题，即传入的Size超过了Src的那块内存区的大小了，访问了后边不该访问的虚拟内存；

　　2、Size没问题，待访问的那块虚拟内存某些区间被释放掉了；

　　要知道这个答案，就需要溯源到上一级，因为memmove这个库函数出问题的几率实在太低了。溯源到上一级有两种方法，栈回溯或者IDA的交叉引用。我喜欢栈回溯，因为他“一锤定音”，不存在多个可能。根据上一小节的栈回溯可知，caller的返回地址为：00007ff8`737d1c83，其汇编代码如下：

　　0:007> ub 00007ff8`737d1c83 frdvpr_drv+0x11c5d: 00007ff8`737d1c5d je frdvpr_drv+0x11c8c (00007ff8`737d1c8c) 00007ff8`737d1c5f call qword ptr [frdvpr_drv!DrvQueryDriverInfo+0x2dc158 (00007ff8`73abc5f8)] 00007ff8`737d1c65 mov rcx,rbx 00007ff8`737d1c68 call qword ptr [frdvpr_drv!DrvQueryDriverInfo+0x2dc130 (00007ff8`73abc5d0)] 00007ff8`737d1c6e lea rcx,[frdvpr_drv!DrvQueryDriverInfo+0x4fe5e0 (00007ff8`73cdea80)] 00007ff8`737d1c75 mov r8d,206h 00007ff8`737d1c7b mov rdx,rax 00007ff8`737d1c7e call frdvpr_drv!DrvQueryDriverInfo+0x2c4b0 (00007ff8`7380c950) ;memmove(0x00007ff8`73cdea80,rax,0x206)

　　上边这段代码翻译完就是memmove(0x00007ff8`73cdea80,rax,0x206)；我第一眼看到就感觉好奇怪，为啥把这个Size写死了，为啥要硬编码？带着疑问我们在往上翻一下，看看这个rax的值哪来的。

　　1，2，3号函数分别如下：

　　即：

　　1—->调用的是hClipboard = USER32!GetClipboardData()，而且传入的 uFormat参数由图可知是0x0D,即CF_UNICODETEXT;

　　2—->调用的是KERNEL32!GetLastErrorStub();

　　3—->调用的是lpMem = KERNEL32!GlobalLock(hClipboard);

　　4—–>memmove(0x00007ff8`73cdea80,lpMem,0x206)

　　都清楚了，原来是从剪贴板中读取UNICODE字符串，然后硬编码的Size为0x206；下边我们去IDA中看下，是不是这个逻辑，如下图：

　　完全一样，好了，看一下unk_18051EA80这个全局变量，它的大小估计也是在0x206附近，确认下，如下图：

　　现在可以完全推导出当时这个源码了，应该是这样的：

　　unk_18051EA80[0x208]={0}; memmove(unk_18051EA80,lpMem,sizeof(unk_18051EA80)-sizeof(WCHAR));

　　3、定因

　　在第2节中提出来的两个原因，基本可以确定为Size过大了，下边简单看下后边的那块内存的属性。如下：

　　到此，便结束了。实在是不该出现这样的问题。