对福昕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过大了，下边简单看下后边的那块内存的属性。如下：

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