Question

Android 中的每个应用都有一个唯一的签名，如果一个应用没有被签名是不允许安装到设备中的，一般在运行 debug 程序的时候也是有默认的签名文件的，只是 IDE 帮开发者做了签名工作，在应用发版的时候会用唯一的签名文件进行签名。那么在以往的破解中可以看到，有时候需要在反编译应用之后，重新签名再打包运行，这又给很多二次打包团队谋取利益提供了一种手段。就是反编译市场中的包，然后添加一些广告代码，最后使用自家的签名重新打包发布到市场中，因为签名在反编译之后是获取不到的，所以只能用自己的签名文件去签名，但是在已经安装了应用设备再去安装一个签名不一致的应用会导致安装失败，这样也有一个问题就是有些用户安装了这些二次打包的应用之后，无法再安装正规的应用了，只有卸载重装。根据这个原理可以利用应用的签名是唯一的特性做一层防护。

为了防止应用被二次打包，在程序入口处添加签名验证，如果发现应用的签名不正确就立即退出程序，可以在应用启动的时候获取应用的签名值，然后和正确的签名值作比对，如果不符合就直接退出程序。下面做一个简单的案例测试一下，如下所示：

这里定义一个简单的工具类用于比较应用的签名，只是简单处理，正常情况下这里应该比对签名的 MD5 值，为了简单就忽略了，然后在程序的入口处做一次比对，如果不正确就退出程序如下所示。

得到上面的 apk 之后，下面来反编译，重新签名安装（关于这里如何反编译和签名，不做解释了，使用 apktool 和 jarsigner 工具即可，签名文件是自己的），然后运行如下所示：

发现程序根本运行不起来，一点击就闪退，这就说明做到了防止应用被二次签名打包。

但是这也不是最安全的，因为既然有签名比对方法的地方，那么只需要反编译 apk 之后，修改 smali 语法，把这个方法调用的地方注释即可，如下所示：

只需要使用#把这行代码注释，然后回编译重新打包安装即可。这里的难点是如何找到这个检测签名方法的地方，比如有的程序在 native 层做的，但是不管在哪里，只要是在代码中，就可以找出来的。