Pyhton

当前时间: 2026-07-20 17:56:12 开始分析 初步尝试 刚开始使用Ai自动静态分析pyc文件 但是效果不怎么好，于是我就准备动态调试使用ida和动态插桩，但是他有反调试，我目前无法绕过，于是我在游戏运行时dump出来了SO，随后开始分析so文件，我找到了python虚拟机尝试使用ai分析虚拟机的分发逻辑以此进行建立一个映射表，进而修改pyc文件，但是ai的上下文有限并且很费token，于是只能自己分析了。 寻找 我找到一个低版本的国际服，随后就针对于这个包体进行研究，然后发现她没有apk的签名校验，so也没有校验，于是我就直接静态修改汇编逻辑以此实现静态加动态的分析，但是修改一次耗时耗力，测试有可能闪退，比较麻烦 发现 某天在网上刷视频时偶然发现了和我一样逆向在蛋仔派对的UP，但是他是针对于PC对进行逆向，我看他已经把源码还原了，发私信想问一下实现方法，但没有回我，他的GitHub有一个仓库是对于网易蛋仔派对的逆向分析，有网易的自定义虚拟机的dll并且写好了调用的exe，我运行调用发现他生成的字节码和我的这个游戏中提取的一模一样，于是我就从逆行so转到dll逆向，好在dll的符号没有剥离于是我准备逆向他的虚拟机主循环， 找出问题 我在将由一个源码编译的两份pyc字节码进行对照的时候，发现了之前为什么搜索数量对不上的原因了。 原先是这样的融合指令是 :B3 00 00 83 00 00 ↓ 然后我分析出来的映射是 :64 00 00 84 00 00 因为他是83和B3融合到一起了，在虚拟机中，遇到B3后会执行两个指令的操作然后直接跳过下一条指令。 于是我就在魔改的pyc中去搜索B3在标准的这边搜索84然后手动手动挑出前面是64的指令。 将这两个数量进行对比，然后我发现直接这样对比是错误的，在魔改那边没有问题，但是在标准这边，虽然64后面是84是对的，但是在魔改的虚拟机中他是顺序去读的并不是直接搜索替换，所以64前面有可能是另一条融合指令，84后面也有可能是另一条指令。 魔改:B0 00 00 83 00 00 86 00 00 83 00 00 标准:64 00 00 64 00 00 84 00 00 5A 00 00 B083对应6464,8683对应845A 这样就导致融合指令少了一条，融合指令他把前面的融合和后面的就没有条件融合了，发现这个问题之后，我就开始迅速的一条一条对比，由于我可以使用引擎生成魔改的pyc和标准的对比，这一块就比较方便，花了三天时间把全部的映射表都写出来了。 开始写脚本 基本的指令替换插入 映射表写好了就要写修复脚本了，由于之前被ai坑过很多次，所以我这次自己写 提取出co_code后就开始循环进行替换，我将所有的操作码分为这几组: 有参指令 魔改 标准 普通有参指令: A2 > 64 融合有参指令: A8 > 83,01 特殊有参指令: AD > 7C,64 无参指令 普通无参指令: 2B > 3F 融合无参指令: 2D > 52,53 特殊无参指令: 2A > 01,01,01 融合指令 普通融合指令 : B3 > 64,84 7字节融合指令: 63,83 > 64,64,36 跳转融合指令 : 60,83 > 6B,72 跳转指令 相对跳转: 9D > 5D 绝对跳转: BE > 71 修复跳转指令参数 写完之后就要考虑修复跳转指令，我在原先函数的融合指令处理分支中将插入的指令的偏移量和插入的字节写入了一个字典里面，我还在遇到跳转指令的时候不执行替换操作而是先记录位置到一个集合里。 ...