G.O.S.S.I.P 阅读推荐 2023-05-15 PyFET

下周我们就要迎来2023年的IEEE S&P安全会议啦，所以最近会给大家介绍更多今年Oakland的论文。今天我们要介绍的这篇论文 PYFET: Forensically Equivalent Transformation for Python Binary Decompilation 是一篇非常实战派的研究论文，想了解Python代码的编译和反编译对抗的读者一定不能错过！

我们千万不要被论文标题里面什么“Forensically Equivalent Transformation”这种字眼吓唬住了，这篇论文讨论的问题很简单，就是很多用Python开发的恶意代码为了逃避分析，不光要编译成bytecode，还要加入各种反分析手段，让相关的decompiler不能好好工作。作者从恶意代码分析的角度出发，得出了这么一个结论：在逆向分析的时候并不一定追求精确还原代码（即保证反编译结果的语义正确性），所以我们完全可以做一些妥协，把一些不好处理的地方简化掉或者修改掉，使得decompiler能够工作下去。

有了这个思路，作者基于自己丰富的实战经验，为大家介绍了如何对付那些“难搞”的Python代码（字节码）

经验1：有些关键字不重要

作者认为，有一些关键字（例如await, async这种），写代码的时候蛮重要的，但是你分析的时候如果不是特别强迫症，把它们拿掉并不会对语义改变太多。

经验2：有些tricky的代码结构不重要

作者认为，Python代码里面一些灵活的语法（糖）其实在分析的时候并没有那么重要（能用就好），完全可以为了简洁（or简单）把它们改写成更为直接易处理的模式，如下表所示：

还有一个问题——如果反编译器报错，那么我们还能够见招拆招去修复错误，但是如果反编译器没报错，而是自以为是地输出了一些错误的结果呢（怎么感觉在影射某GPT）？在这里，作者引入了一个同样很经验化的方法：

1. 首先总结一系列的（潜在）源代码错误模式

2. 在反编译得到的代码中搜索上述模式

3. 基于相关规则将存在上述模式的代码进行纠正，得到一份新的代码，然后重新编译得到字节码

4. 检查重新编译得到的字节码和原始的字节码之间的一致性：如果一致，说明反编译结果错了！

其实这个思路让我们想起了G.O.S.S.I.P在2020年拿到SANER 2020最佳论文奖的研究工作 SmartShield: Automatic Smart Contract Protection Made Easy，和上面这个想法有异曲同工之妙。本文中总结出来的易错模式如下表所示（感觉像考试小抄一样要收藏起来）：

把这些技术都合起来，作者设计实现了名为PyFET的反编译增强工具，为恶意代码分析之类对代码恢复的精确性不是那么敏感的工作（其实就是背后有大量人工投入嘛~）添砖加瓦。

下表总结了一系列在PyFET的实现中用到的典型规则：

论文还有一个蛮有意思的部分就是Section 5.4，关于现实中抓到的Python代码混淆的实例。其中有一个是DropBox自带的opcode remapping混淆技术（关于这个技术，也可以参考我们在2014年发表的论文 Android App Protection via Interpretation Obfuscation），另一个是PjOrion这个常见的Python代码混淆器，采取了类似于以前x86时代插入花指令的方式来干扰反编译器。作者分析了它们，并且用PyFET来解决了问题！

---

论文：https://www.computer.org/csdl/proceedings-article/sp/2023/933600a800/1Js0DmsXjQQ
项目：https://github.com/pyfet-pyc/src

原文始发于微信公众号（安全研究GoSSIP）：G.O.S.S.I.P 阅读推荐 2023-05-15 PyFET