最近报出的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执行。

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

原文出处：
009K9s2c8@1M7s2y4Q4x3@1q4Q4x3V1k6Q4x3V1k6Y4K9i4c8Z5N6h3u0Q4x3X3g2U0L8$3#2Q4x3V1k6E0K9h3y4Z5j5h3g2D9M7r3c8#2i4K6u0r3L8h3W2U0K9r3q4W2L8s2m8V1N6g2)9J5k6h3N6A6N6r3S2#2j5W2)9J5k6h3W2G2i4K6u0r3j5X3I4G2j5W2)9J5c8X3#2S2M7%4c8W2M7W2)9J5c8X3#2V1i4K6u0r3b7#2k6q4i4K6u0V1x3U0l9I4z5q4)9J5k6o6b7^5y4K6S2Q4x3X3g2E0k6l9`.`.

[培训]科锐逆向工程师培训第53期2025年7月8日开班！