APK文件签名的目的是什么？如何防范篡改后重签分发的风险？

一、阻止篡改后重签名的实用手段 #

• 内置签名校验逻辑：在APP代码里加几处签名校验逻辑——比如获取当前APK的签名哈希值，和提前硬编码的合法签名哈希做对比。一旦不匹配，直接让APP停止运行。为了防止被反编译修改，建议把校验逻辑分散到多个代码路径，甚至用Native层代码实现。
• 使用专业加固工具：市面上的APP加固工具会对DEX文件、资源文件做加密混淆，同时套一层“壳”。篡改后的APK过不了壳的校验，根本没法正常解密运行；而且加固工具通常会自带多层防篡改检测，比如校验签名、APK完整性，一旦发现异常就直接崩溃。
• 启用Google Play应用签名服务：如果你的APP在Google Play发布，开启官方的App Signing功能后，Google会托管你的原始签名密钥，用户下载的APK是用Google的分发密钥签名的。攻击者拿不到这个分发密钥，就算篡改后重签名，也没法伪装成原APP在Play商店更新，分发范围会被大幅限制。
• 远程校验APK完整性：计算合法APK的SHA-256哈希值，存到自己的远程服务器。APP启动时通过HTTPS请求这个哈希值，和本地APK的哈希对比。如果不一致，说明APK被篡改，直接禁止运行。这种方式能避免攻击者只修改APP本地的校验逻辑就绕过检测。

二、安全保障的核心原理 #

1. 原生APK签名的防篡改逻辑 #

APK签名时，会对包里所有文件计算哈希值，再用开发者的私钥对这些哈希值签名，生成META-INF目录下的签名文件。系统安装APK时，会用公钥验证这些签名：

• 如果APK里的文件被篡改，对应的哈希值就会变，验证失败，系统直接拒绝安装。
• 但如果攻击者替换所有文件后用自己的私钥重新签名，系统会认为这是一个合法的新APP——因为系统只认签名的合法性，不管签名是谁的。这就是原生签名只能防“未签名篡改”，防不了重签名的原因。

2. 额外防护手段的原理 #

• 内置签名校验：攻击者就算用自己的密钥重签名，APP内部的校验逻辑会识别出签名和预设的不匹配，直接让APP没法正常使用，篡改后的APK等于废了。
• 加固工具：通过加密核心代码和资源，篡改后的APK无法正确解密运行；同时加固壳的多层校验会检测签名、APK完整性甚至自身代码的完整性，只要有篡改就触发崩溃。
• Google Play应用签名：用户手里的APK用的是Google的分发密钥签名，攻击者没有这个密钥，重签名后的APK没法被Play商店认可，也没法冒充原APP做更新，很难大规模分发。
• 远程完整性校验：合法哈希存在服务器，攻击者篡改APK后哈希值必然变化，APP对比后发现异常就停止运行。就算攻击者改了APP本地的校验逻辑，还得攻破服务器才能伪造合法哈希，难度极高。

内容的提问来源于stack exchange，提问作者Mikhail Ivanov