最近报出的flash 0day，自己闲暇之余，看看究竟。拿到sample以后，上FFDEC，看看decompiled code，简单看一下，发现又是TVSDK，看来后面TVSDK还是会有不少洞的。

先从code层面整理逻辑，class_2可以看做入口函数，通过DRMManager初始化DRM object，来触发漏洞（后面的调试，可以看出这是一个UAF）。
通过计时器来检查DRM object的a1是不是被修改了，如果已经被修改，则去做利用的部分，思路是ByteArray占位，以及修改ByteArray的Length，获取全地址访问的权限。

在触发漏洞之前，DRM object的内存布局

漏洞触发的时候，可以发现相应的a1已经被设置为0，继续跟进call stack，可以发现前几个function大致是这样的：delete script_object --> script_object destructor --> memset

占位以后，ByteArray object的内存布局以及对应的size，可以看到正好是512字节（0x200）

修改Lengh以后，对应的内存布局，如下：

相应修改Length的汇编指令以及action script位置，正好可以对应decompiled code中的class_2/flash25

后面就是常用的绕过手法，利用获取的全地址读写来leak flash module基址，然后是kernel32的地址，然后，是VirutualProtect和CreateProcess。shellcode的触发是利用修改Method对象的虚表函数（apply和call），一个用于修改shellcode的保护属性，一个是用于触发shellcode执行。

备注：时间仓促，不免会有遗漏和错误之处，如有不足，请多指教。

原文出处：
https://github.com/michaelpdu/michaelpdu.github.io/blob/master/md/CVE-2018-4878.md

[招生]科锐逆向工程师培训(2024年11月15日实地，远程教学同时开班, 第51期)