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

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…）也可以脱掉大部分的。

smali

Smali，Baksmali分别是指安卓系统里的Java虚拟机（Dalvik)所使用的一种.dex格式文件的汇编器，反汇编器。其语法是一种宽松式的Jasmin/dedexer语法，而且它实现了.dex格式所有功能（注解，调试信息，线路信息等）。

Smali，Baksmali分别是冰岛语中编译器，反编译器叫法。也许你会问为什么是冰岛语呢，因为Dalvik是一个冰岛渔村名字。

1、反编译=回编译后分别是smali目录 回编译为 classes.dex 文件　res目录 回编译为 resources.arsc 文件2、回编译顺序在回编译时，会先检查“源”即resources当你汉化文件，修改出错了（缺少一个符号也不行），那么回编译会自动跳过编译res文件夹，直接回编译smali 。所以，如果没有对smali（classes.dex）汉化，那么建议大家删掉这个文件夹，这要会大大加快回编译速度。1、反编译=回编译后分别是smali目录 回编译为 classes.dex 文件　res目录 回编译为 resources.arsc 文件2、回编译顺序在回编译时，会先检查“源”即resources当你汉化文件，修改出错了（缺少一个符号也不行），那么回编译会自动跳过编译res文件夹，直接回编译smali 。所以，如果没有对smali（classes.dex）汉化，那么建议大家删掉这个文件夹，这要会大大加快回编译速度。3、出错问题1在汉化时，往往会不小心删掉一些符号，如 "<" ">"符号等等。<string name="app_name">File Manager</string><string name="app_name">文件管理器/string><string name="app_name"文件管理器</string>这些小小的错误都会导致回编时译检查出错。所以汉化时，注意对校，然后再回编译。建议使用一些高级的文本编辑器，支持语法高亮视图的。4、出错问题2最近发现有些APK文件 反编译后，就算不汉化直接回编译，都会出错。有可能的原因1，反编译后XML文件语法中@符号 前面多了"\" （\@ ），用文本编辑工具 直接替换【\@】为【@】，应该可以解决。建议使用最新版本的反编译工具。5、建议大家使用新版本的APKTool工具，当然如果新的有问题也可以试试旧的一、系统文件汉化再次强调1、汉化Settings.apk(系统设置)、MMS.apk（信息）、Phone.apk（电话）、等等系统文件，一定要先 安装构架，具体看另个文件<关于APKTool工具反编译Settings.apk问题>。2、系统文件汉化完后不需要签名，直接替换汉化后的文件，就可以了。主要是，系统文件放在系统目录，无需再次读取签名获得权限，已经是高级了。二、打包说明1、通常汉化完回编译后，会自动生成所有APK内的文件，或者自动生成*.APK文件。但是建议大家不要直接使用该文件，进了使用替换法，替换掉你汉化后的文件，如：resources.arsc，如果修改过的图片，等等…2、很多人对于APK文件 解压缩或压缩 都用“WinRAR”或“好压”，这里不推荐。　 希望大家安装7-Zip这个压缩工具，对于zip格式的支持是最好的。而且很方便，不需要重新关联apk 直接右键打开就行了。替换直接拖拉进去，就OK了一、回编译出错问题(1.提示 strings.xml 最后一行错误，检查是否</string>符号错误；在汉化时，往往会不小心删掉一些符号，如 "<" ">"符号等等。<string name="app_name">File Manager</string><string name="app_name">文件管理器/string><string name="app_name"文件管理器</string>(2.提示 strings.xml 最顶部含中文代码首行错误，编码格式不对，转换成 UTF-8；(3.提示 public.xml 出错，检查改动过的 arrays.xml 是否代码有错误的地方；

---