APK签名替换检测

APK二次打包的危害

APK二次打包是Android应用安全风险中的一部分， 一般是通过反编译工具向应用中插入广告代码与相关配置，再在第三方应用市场、论坛发布。打包党对移动App带来的危害有以下几种：

1. 插入自己广告或者删除原来广告；
2. 恶意代码, 恶意扣费、木马等；
3. 修改原来支付逻辑；

上述恶意行为危害了APK出品方和用户的利益，同时也影响企业口碑。

APK的签名机制

Google设计APK的签名机制就是防止两个问题：

• 不让别人修改APK包，防止反编译后二次打包；
  怎么做到不让别人二次打包呢？Android系统在安装APK时，会先去确认是否有签名、签名是否能对上；
• Android系统在安装APK包时，不允许安装同一个包名但是签名不一样的APK；

下面开始分析APK打签名的流程：

需要了解的背景知识

自行去百度，了解概念即可；

• 数据摘要（数据指纹）、MD5SHA-1对称加密算法
• 非对称加密算法
• 数字签名、数字证书
• 手动签名APK包

1.查看META-INF文件

将.apk包修改后缀成.zip，解压之后打开该文件夹，找到META-INF目录。

签名就是围绕这三个文件开始的。

2.先看第一个文件MANIFEST.MF

这个文件里面包括了APK文件中所有文件的数据摘要值。相当于对每个单独（除了这三个）的文件都做了数据指纹。

3.在看第二个文件CERT.SF

和MANIFEST.MF文件差不多，唯一的差别在于，多了一行SHA1-Digest-Manifest: KDerPmANkkB5mxceo/t5oXRGApg=，这行就是MANIFEST.MF的数据摘要。

4.最后看第三个文件CERT.SF

把之前的CERT.SF文件用私钥计算出一个加密值，这个加密值称为签名，所以这个文件包含了签名和公钥；

如果是在Windows系统下，推荐使用cmder.exe软件使用如下命令。

证书内容概况：

用来管理私钥仓库的命令：

总结

APK生成后签名不能更改，因为没有私钥。但能替换签名，因为Android系统在安装APK的时候只校验签名的正确性。

一个apk文件，通过使用AndroidKiller二次编译，我对比了原APK和编译后的APK的./META-INF/CERT.RSA文件，发现确实是被替换了。

签名的过程可以想象成发件人和收件人的处理流程，也是一个双向的动作，可以大致理解成下图流程：

可以把上图的客户1替换成打包APK的过程，把服务器替换成Android手机安装APK的过程，当系统拿着CERT.RSA里面的公钥和apk原文解密出的Hash值和CERT.SF文件里面的Hash值不一致时，就不会去安装。

检测是否能替换签名

二次打包成功的前提是能替换签名，并且APK没做签名校验。而签名验证的方式有三种：

• APK包没有做签名校验
  直接替换签名即可，下面将介绍替换签名的步骤；
• APK包做了签名校验
  • java代码校验
    难点在于找到校验的JAVA代码，注释掉即可；
  • .so文件校验
    难点在于看懂汇编，找到校验的C代码，注释掉即可；
  • 加壳
    难点在于得先脱壳；

替换签名步骤

工具：
AndroidKiller_v1.3.1 （下载地址：https://www.52pojie.cn/thread-319641-1-1.html）

步骤：
使用AndroidKiller_v1.3.1工具，里面有个编译功能，就能做到二次打包，原理就是替换签名值。

执行步骤中有报错，建议看我之前的文章：https://www.cnblogs.com/mysticbinary/p/11609825.html

我一般修改版本号来证明能二次打包：
反编译后在AndroidManifest.xml 里直接修改版本号，如果在AndroidManifest.xml文件中无法看到 versionCode和versionName字段，则在apktool.yml文件中打开找到，对应修改versionName字段的数字大小即可。

修复方式

1. SO层校验签名
2. 网络校验签名
3. APK加固

文章出处：APK签名替换检测