0x00 序
第一次尝试做一些简单的逆向分析，内容比较简单，高手们莫见笑。
“贪吃蛇大作战”这个游戏最近玩的人挺多，我也在玩。5分钟限时版，最好成绩也就3000多。
我分析的版本是v2.0.1：


经过修改，玩了一把5分钟限时赛：长度69224，击杀1456。
0x01 反调试和签名校验
将原包重新签名，安装到手机上，一直提示网络无法连接，原包没有问题。这里很明显是将签名信息上传到了服务器端，在服务器端进行了签名校验，校验失败则断开与此客户端的连接。
写一个小程序进行注入（利用ptrace），对一些关键函数进行hook，比如libc.so的fopen函数。


在hook_entry中，对libc.so的fopen作inline hook，监测一下程序都打开了哪些文件。
我本意是想看看，它是否会在运行时直接去读取apk包，自己解析其中的与签名信息相关的文件。结果是没有，但发现它一直在读cmdline文件，猜测可能是在作反调试（未去证实，因为后面的分析和修改并未借助动态调试）。
这里说一下，假设它是自己打开apk文件，从中读取与签名相关的文件，提取签名信息。那么我们可以在某个位置放一个原包，然后hook关键函数，将其读取的文件路径修改为原包位置，即可绕过这种签名校验。
举一反三，这种方式也可以绕过大部分反调试措施。比如常见的检测traceid是否非0的反调方式，我们可以hook fopen/open，然后在它要读取该文件之前先读取该文件，并将其traceid重新修改为0，并将其写到sd卡某个目录下，再将打开文件的位置重定向到该文件，那它就检测不到ptrace了。
还有一些anti-hook机制，大概思路是校验本地文件的数据和加载到内存中的数据是否一致。通过类似方式也可以轻松绕过，一句话，因为我们可以先注入，先完成hook，先做各种Anti-anti。
0x02 破解签名校验
因为它没有在运行时直接fopen/open apk文件，所以考虑应该还是通过调用系统api读取的签名信息。
将原包解压，发现只有两个so，其中libweibosdkcore.so看起来是微博sdk。将另一个libJustATest.so拖到IDA中看一下，没加壳，并且只看到xxx_getATestString这么一个有用的导出函数，从名字上看，很可能就是获取上传到服务器端的校验字符串。


跳转到该方法，f5，进行一些简单的参数名和参数类型以及函数调用的修正。发现它里面进行了一大通的各种字符串的拼接，最后将该字符串返回（根据之前的猜测，该字符串可能就是发送给服务端的校验字符串）。


发现里面调用了java层com.wepie.snake.helper.update.QiniuEtagUtil类的getSignString函数。用AndroidKiller反编译一下APK包（该APK没有作任何防反编译的措施，dex也没加壳），找到getSignString函数。


没错，就是在这里调用系统API获取的签名（其实，我们可以一开始就全局搜索某些关键API，来定位获取签名的位置）。
借助xposed hook getSignString方法，将正确的签名字符串通过日志打印出来。


正确的签名字符串是（作了MD5计算后的结果）：678a930b9829b54a44f92a840916f7d1
剩下的工作就简单了，修改smali，将getSignString的返回结果固定为上面的这个正确的签名字符串。


重新编译、打包、签名、安装，发现用新签名的APK包已经可以正常使用了。
0x03 后序
其实破解签名校验之后，基本上是想改什么改什么了，因为原包没有做任何的加壳和混淆的工作。比如，看看下面这个类，应该知道怎么下手了吧（修改的时候注意一下，它里面好像有一些简单的数据合理性校验之类的东西，我没细看）。


最后，大家学习就好，别做什么破坏，也别释放出什么破解版之类的东西。初次尝试一点简单的逆向分析，大牛们绕过吧。
附：我认为现在so端最有用的加固措施是llvm混淆，因为普通加解密壳从机制上来说比较容易脱掉。dex端已经出现了解释器壳（伪vmp），纯粹的类抽取的话，通过自定义rom（定制dalvik或art，遍历class_def加载并初始化，然后dump…）也可以脱掉大部分的。

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