刚刚改完毕业论文提交了，byd本科论文格式真操蛋；赛后把这题复现了一下，终于有空就整理了一下这题的方案

题目有数字命名从0开始到13612共13613个文件夹

每个文件夹里有一个名为beatme的64位elf可执行文件和若干个so

beatme中会加载so文件，并调用so的导出函数

so只有一个导出函数，并且有可能加载别的so并调用别的so的导出函数

每个beatme的代码都非常相似，都是encrypt(input, key)==secret?的问题；解题过程就是提取key，secret，实现encrypt的逆，然后反求input；最后各个beatme解出来的input按顺序组成一个jpeg文件

解题方向应该是自动化分析这些题目；或者因为encrypt都一样，只需实现decrypt，然后自动化提取key和secret（本文的解决方案，参考了大神Q7的解决方案），其中需要去除 表达式分散在so里 的混淆

如上所述so只有一个导出函数

so有两种类型，第一种是"直接型"，比如output\0\AmiOWZLBXmVOGVXC.so的导出函数，直接是一条表达式：

第二种是"间接型"，比如output\0\AOinIPkXvMtrtbha.so的导出函数，调用了别的so的导出函数：

从而呈现出一条：间接型so 调用 间接型so 调用 间接型so...最后调用直接型so的调用关系单向链

一个小细节是，不是所有so都会被使用到（包括直接型，有的也根本就没被执行过）

beatme的main函数首先读取8字节的输入

然后加载so并获取导出函数的地址，反编译出来的代码非常有规律，有些被调用过，ida会识别出类型为函数，有些没被调用ida会当成64位整型：

最后多次调用一个加密函数（调用次数不是固定的），然后和目标进行对比

这是加密函数调用次数大于3次的ida反汇编：

但加密函数调用次数小于等于3次时，反编译结果有所不一样（猜测是编译优化把循环展开了，也可能是出题人故意的）

如果是使用ida的反编译，次数小于等于3次时，最后几个加载so获取导出函数的规律也有所变化

这是加密函数调用次数为1次的ida反汇编（前40个中，3、5、28都是这种情况）：

这是加密函数调用次数为2次的ida反汇编（前40个中，8、12、36都是这种情况）：

这是加密函数调用次数为3次的ida反汇编（前60个中，只有51是这种情况）：

原本长这个样子：

将qword_xxxx都替换成前面so文件分析中所说的直接型so里面的代码，去掉混淆

分析去掉混淆后的代码发现，key会被修改，然后是16*2=32轮tea，对比不同beatme的加密函数

只有修改key那四句代码里的8个常数会变：

单线程情况下完整分析一个beatme大概19~20s；如果已经生成好i64并输出了反编译C代码，分析一个beatme只需要0.5~0.8s

多进程（python multiprocessing，processes=8；笔记本R7 4800H 8核16线程）分析一个beatme大概24~34s

考虑最坏情况34s一个，开32核，4小时解完全部：13613*34/32/3600=4h

主要时间花在ida批处理反编译上了

Igor’s tip of the week #08: Batch mode under the hood – Hex Rays (hex-rays.com)

用ida批处理模式可以输出指定函数的反编译到文件：

但是有个很奇怪的问题，如果没有i64文件的情况下，第一次指定反编译main函数反编译结果会为空，似乎是反编译没有被执行，需要再重新指定反编译main一次

获取so文件的调用单向链，遍历所有so文件：

根据是否导入dlopen和dlsym判断是否为"间接型"的so；

记录"间接型"so导入的so名和调用的导出函数名：

导入的so的名称和调用的导出函数的名称是相邻的，可通过正则匹配二进制内容找出。

反编译beatme的main函数（ida批处理反编译）得到main.c；

获取main函数中变量对应的加载的so和导出函数（正则匹配main.c内容）

获取main函数中调用加密函数相关信息（正则匹配main.c内容）：

加密函数的名称（反编译加密函数时用于通过名称指定函数）；

加密函数调用轮次；

原始key；

secret；

注意：前面分析调用轮次有4种情况，每种情况都做一个正则的规则。

处理beatme的加密函数，反编译与去掉混淆得到sub_xxxx.c：

反编译beatme的加密函数（ida批处理反编译，通过函数名指定）得到sub_xxxx.c；

[注意]传递专业知识、拓宽行业人脉——看雪讲师团队等你加入！