一个读异常

具体到点这不能写,大概就是一个Type1的字体文件再build之后渲染的时候出了问题

问题相关的模块是CoolType

期间遇到的问题

我感觉比较大的一个问题就是之前没接触过过Adobe PDF Reader这东西,所以一来得先了解下,其中,调试的时候发现Reader会有两个进程,询问得知一个是渲染沙箱,一个是普通进程,渲染沙箱的进程可以在设置中关掉就没有了。

还有个问题就是Adobe没有符号的问题,但是好像大家们都比较会玩,用下面的方法可以通过手动,或者对比的方式得到一部分符号,对静态分析的帮助还是很大的。

参考文章1

参考文章2

反正也不知道是运气还是咋的反正是给我恢复了一些符号

内存挖坑攻击

这个应该就是堆喷吧,反正他们是这么给我说的。因为造成异常的是一个读异常,读了一个堆的地址,堆块大小为400,按理说就可以堆喷

按照他们的说法,不用担心成功的问题,反正用堆喷都有个概率

+------------------------+
|                        |
|           坑           |
+------------------------+
|                        |
|                        |
|                        |
|                        |
|                        |
|                        |
|                        |
+------------------------+
|                        |
|            坑          |
+------------------------+
|                        |
|                        |
|                        |
|                        |
|                        |
|                        |
|                        |
|                        |
+------------------------+

按照我的理解就是长这样的按照一定的长度释放间隔的堆块,然后造成他临近的堆块都是我们自己想要的值,这样异常读的时候读的就可能是我们需要的值了


所以这样一来按照理论上说我就控制了那个异常读的DWORD,这个DWORD会作为一个Offset与后续的一个Ptr相加得到一个新的New_Ptr,而这个新的指向的就是一串switch的control code,所以按照我的想法,那堆喷控制了New_Ptr之后我就可以控制switch了

真香,马上验证下

导致我失败的原因猜测

然而事实总和我的理论相悖,嵌入PDF的js代码执行了
但是貌似js的执行和pdf的渲染构建是同时进行的,大佬们给我说的一定有个先后顺序,但是我感觉就是应该先启动的js解析引擎然后再启动的渲染引擎,但是应该不是同一个线程

我将Math.sin(0.0)放在堆喷循环前就成功断下来了,但是如果放在堆喷挖坑之后就断不下来,会先触发漏洞的断点(真是让人摸不着头脑)

所以当时得出的结论是,js引擎和渲染引擎应该不是在同一个线程里面运行的,也不知道对不对