Android Apk中的代码篡改检测

我对应用程序开发特别陌生，最近了解了apk的整个签名过程，为什么它是强制性的，以及防止未经授权和篡改应用程序的重要性。 著名的签名检查之一是使用PackageManager类进行签名验证。是否有其他方法检查apk本身的META-INF目录是否存在篡改或其他滥用行为，以验证应用程序未被篡改，且其原始签名完好无损？

此代码获取Classes.dex文件的CRC校验和，并将其与提供的文件进行比较。

---

最佳做法是服务器端篡改检测，无法修补

以下是如何：

使用Android。这就是安卓支付验证自身的方式

基本流程是：

• 服务器生成一个nonce，并将其发送到客户端应用程序
• 该应用程序通过Google Play服务发送带有nonce的验证请求
• SafetyNet验证本地设备是否未修改并通过了CTS
• 谷歌签名的响应（“认证”）将返回给你的应用程序，并带有通过/失败的结果以及关于你的应用程序的APK（哈希和签名证书）的信息
• 你的应用程序将认证发送到你的服务器
• 您的服务器验证nonce和APK签名，然后将认证提交给Google服务器进行验证。谷歌检查认证签名，并告诉你它是否真实

如果通过测试，您可以相当确信用户正在未经修改的系统上运行您的应用程序的正版。应用程序启动时应获得认证，并随每个交易请求一起发送到您的服务器

但请注意，这意味着：

• 在手机上设置根目录的用户将无法通过这些检查 安装了自定义或第三方ROM/固件/OS（如Cynogen）的用户将无法通过这些检查

• 无法访问Google Play服务（如亚马逊）的用户 中国的设备、人员）将无法通过这些检查

…因此将无法使用您的应用程序。您的公司需要就这些限制（以及随之而来的不安用户）是否可接受做出商业决策

最后，要意识到这不是一个完全密封的解决方案。通过root访问，或者xpose，可以修改SafetyNet库来欺骗谷歌的服务器，告诉他们“正确”的答案，以获得谷歌签署的验证通过结果。事实上，SafetyNet只是移动了球门柱，让恶意玩家更难进入。由于这些检查最终必须在您无法控制的设备上运行，因此设计一个完全安全的系统确实是不可能的

---

只有当存储在R.string.dex_crc中的值在xml文件中清晰可读时，这才可能是一个解决方案。无论是否加密，这都将失败，并且只能阻止少数没有经验的LAD。现在很容易克服这些把戏。是的。我想请你考虑一下Snapchat的应用程序，以列举最佳例子，你能列举出最佳实践的来源吗？

private void crcTest() throws IOException {
    boolean modified = false;
    // required dex crc value stored as a text string.
    // it could be any invisible layout element
    long dexCrc = Long.parseLong(Main.MyContext.getString(R.string.dex_crc));

    ZipFile zf = new ZipFile(Main.MyContext.getPackageCodePath());
    ZipEntry ze = zf.getEntry("classes.dex");

    if ( ze.getCrc() != dexCrc ) {
        // dex has been modified
        modified = true;
    }
    else {
        // dex not tampered with
        modified = false;
    }
}