破解“贪吃蛇大作战”的签名信息服务端验证机制

Android安全交流群：478084054

第一次尝试做一些简单的逆向分析，内容比较简单，高手们莫见笑。

“贪吃蛇大作战”这个游戏最近玩的人挺多，我也在玩。5分钟限时版，最好成绩也就3000多。

我分析的版本是v2.0.1：

经过修改，玩了一把5分钟限时赛：长度69224，击杀1456。

将原包重新签名，安装到手机上，一直提示网络无法连接，原包没有问题。这里很明显是将签名信息上传到了服务器端，在服务器端进行了签名校验，校验失败则断开与此客户端的连接。

写一个小程序进行注入（利用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。

因为它没有在运行时直接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包已经可以正常使用了。

其实破解签名校验之后，基本上是想改什么改什么了，因为原包没有做任何的加壳和混淆的工作。比如，看看下面这个类，应该知道怎么下手了吧（修改的时候注意一下，它里面好像有一些简单的数据合理性校验之类的东西，我没细看）。

最后，大家学习就好，别做什么破坏，也别释放出什么破解版之类的东西。初次尝试一点简单的逆向分析，大牛们绕过吧。

附：我认为现在so端最有用的加固措施是llvm混淆，因为普通加解密壳从机制上来说比较容易脱掉。dex端已经出现了解释器壳（伪vmp），纯粹的类抽取的话，通过自定义rom（定制dalvik或art，遍历class_def加载并初始化，然后dump…）也可以脱掉大部分的。

据我所知有下面两种方法：

1.截取网络封包进行分析，伪造服务端，架设本地服务端，修改host文件，将原软件验证服务器地址指向本机，进行欺骗验证。

2.调试程序，跳过验证。

3.利用hack技术，这个就不说了，如果有这种技术那问题就迎刃而解了。

以上的前方法一般只适用于只是进行联网验证（如用户名、密码或注册码等），软件算法存在软件中，如果算法存在远程服务器上，那就只能采用第三种方法。

---