使用诸如Sothink SWF Decompiler等软件可以很容易反编译不加保护的Flash程序。如果Flash内使用了秘密的网络通信或引入了一段漏洞利用代码,编写者不会希望自己的劳动成果被轻易获取的。
doswf用于给Flash程序加壳,混淆变量、函数和类名,增加逆向的难度。最近拿到了一份使用Flash编写的exploit,想要分析当中触发代码,但Flash已经使用doswf做了处理,直接反编译查看代码行不通。
根据近一段时间的分析,doswf在加密Flash时做了以下三个工作:
- 在原始的Flash程序中加入花指令,混淆变量函数类名
- 使用ByteArray的压缩算法压缩原始Flash,并针对压缩后数组做逐字节的加密处理,并将加密后的ByteArray附到doswf生成的一个Flash程序中,doswf的Flash程序会动态解码释放原始Flash
- 在doswf生成的Flash程序中加入花指令,混淆变量函数类名
花指令主要用于对抗反编译引擎。
Flash中的ActionScript源码被编译成字节码,类似于C语言代码被编译成机器码。对于C语言编写的可执行程序,由于汇编指令长度可变,通过在机器码中加入花指令(je jne 的组合等)可以造成反汇编引擎错误的解释机器码。
对于Flash编译的字节码,由于指令长度固定为一个字节,无法通过加入花指令实现字节码级别的解析错误,但反编译引擎在尝试将包含花指令的字节码转化为ActionScript源码时会发生错乱,导致Sothink SWF Decompiler无法正常工作(程序停止响应)。
混淆变量函数和类型名是一种不可逆的过程,doswf直接修改了Flash的常数表,用一些特殊符号替代用户自定义的名称。不过名称的混淆对分析代码影响有限,毕竟ActionScript的运行时类、成员函数和成员变量的调用仍然保持了原有名字。
压缩与加密Flash虽然很靠静态处理很棘手,但考虑到Flash最后一定会被动态解码加载到内存中,处理它可以靠动态内存抓取。
综合上述的特性,下面通过实际的例子说明如何得到原始Flash的反编译结果。
其实整个问题的关键就是针对1和3中提到的花指令的去除,而且对于3和2,除非你对doswf的加解密算法感兴趣,不然使用动态抓取就很容易绕过了。
我使用debug版的flashplayer加载执行目标Flash程序,相比使用浏览器,干扰更少,内存更小,抓取速度和准确度都会快很多。在内存中搜索FWS和CWS(Flash的文件头部的magic word)字样可以找到疑似的Flash程序,根据Flash文件格式中标识长度的字段能够从内存中将它直接Dump出来。实现类似功能的有很多类似软件,比如SwfReader.jar。Dump结果可能有二三十个,文件过小过大都能迅速排除,再使用swfretools格式解析器观察每个SWF文件,如果解析正确,并且包含DoABC(Flash程序的代码段),则予以保留。
通过动态抓取可以得到加花后的原始Flash程序。我分析的这个由doswf处理的Flash程序并没有使用过于复杂多样的加花指令,仅是把
原始代码A
原始代码B
转化为
原始代码A
jmp [OFFSET]
一些奇怪的字节码
label: [OFFSET]
原始代码B
每隔几十行字节码就会出现一次这种插入,也正是它们导致Sothink Decompiler崩溃。
去掉它们的算法也很基本,对代码段中的所有ActionScript方法进行扫描,将原始代码A和B之间的字节码全部使用空指令代替(0x02)。我写了个一个Python脚本完成这个工作,使用时需要修改Python代码中的两个偏移值,指向method_bodies的开始和结尾。
处理后的Flash文件就可以用Sothink反编译了。上述方法不见得universal,也许只是我遇到的一个特殊情况,doswf如果引入多种花指令,去花更为繁琐。或者新版本的Sothink如果已经更为强大,能够自行避开花指令,分析Flash也就不需要这么折腾了。
如果能总结出一个通用的解密方式,就方便多了,现在的各种反编译软件都是弱不禁风。