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目录。

APK签名替换检测

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

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签名替换检测

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

总结

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

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

APK签名替换检测

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

APK签名替换检测

可以把上图的客户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签名替换检测