数字签名校验与反盗版：签名校验逻辑疑问及原理咨询

一、“修改APP任意字节会导致数字签名改变”的理解对吗？ #

不完全对。APK的数字签名不是绑定整个安装包的每一个字节，而是针对包内的核心内容（比如执行代码dex文件、图片/布局等资源文件）生成的：

• 开发者签名时，会先给这些核心文件生成唯一的哈希值（可理解为文件内容的“指纹”），再用自己的私钥加密这些哈希值得到签名，同时把验证用的公钥放到APK的META-INF文件夹里。
• 只有修改了这些被签名覆盖的核心内容，原签名才会失效；如果是替换META-INF里的签名文件，那属于换了个新签名，不是原有签名“改变”。
• 本质上，只要没经过开发者用私钥重新签名，改了APP内容后，原签名肯定过不了验证，不存在“签名跟着变”的情况——要么原签名失效，要么被换成新的。

二、为啥把签名存到APP变量里，还能通过校验？ #

你搞混了开发阶段和篡改已签名包的场景：

• 开发时把合法签名的哈希值写进代码，是在打包签名前做的。之后你用自己的私钥给整个APK（包括写了签名变量的代码）签名，这时候整个包的内容都符合签名要求。
• 运行时，PiracyChecker会读取当前APK的签名哈希值，和你预先写的变量对比，两者完全一致，当然能过校验。
• 如果有人篡改已签名APP里的这个变量，他们没有你的私钥，没法重新生成合法签名。这时候篡改后的包要么安装不了，要么运行时PiracyChecker读到的签名哈希值和被改的变量对不上，直接校验失败。

三、签名校验的工作原理 #

底层APK签名逻辑 #

1. 生成签名：开发者给APK里的核心文件逐个生成哈希值，把这些哈希值打包后用私钥加密，生成签名文件，同时把公钥放到APK的META-INF目录。
2. 系统验证：安装或运行APK时，系统用META-INF里的公钥解密签名，得到原始哈希值；再重新计算APK核心文件的哈希值，对比两者是否一致。一致就说明包没被篡改，签名合法。

PiracyChecker的校验逻辑 #

它在系统验证之上加了一层自定义校验：

1. 从当前运行的APK里提取签名的哈希值（一般是SHA-1或SHA-256格式）。
2. 把提取到的哈希值和开发者预先写在APP里的合法签名哈希值做对比。
3. 匹配就说明APP是原版；不匹配就判定是盗版或被篡改的包。

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