第33课 classes.dex文件完整性校验

DEX文件打包在APK文件中，针对APK代码的篡改攻击就是针对该文件，比如使用apktool工具反编译文件，修改smali代码。以下就是通过检查classes.dex文件的CRC32值来判断文件是否被篡改。
其中R.string.str_code是存放在本地的crc加密后的值，string.xml文件是不在dex文件中的，所以修改string.xml文件是不会造成crc值的变化（亲测），其实也可以把这个值存放在后台，通过请求网络来获取。（感觉没必要，为什么，往下看哈）

private void checkCRC() {
        String orginalCrc = getString(R.string.str_code);
        ZipFile zf;
        try {
            zf = new ZipFile(getApplicationContext().getPackageCodePath());
            ZipEntry ze = zf.getEntry("classes.dex");
            String strCrc = String.valueOf(ze.getCrc());
            String MD5Crc = MD5Util.GetMD5Code(strCrc);
            Log.e("checkcrc", MD5Crc);
            if (!orginalCrc.equals(MD5Crc)) {
                //ActivityManagerUtil.getScreenManager().removeAllActivity();
                Process.killProcess(Process.myPid());
            }
        } catch (IOException e) {
            e.printStackTrace();
        }
    }

还有其它几种方法，比如校验APK包的完整性、对签名文件中classes.dex哈希值的校验等。其实都大同小异。
把这些手段用在了程序中，但是通过多次反编译，都很容易确认程序在什么地方做了这些处理（可全局搜索关键词），恶意破解的话直接将修改返回值true或false,或者修改接收这个函数的if-else语句条件取个反，直接就绕过了判断。

比较科学一点的办法就是放在NDK层去校验了，这种校验稍微安全点，毕竟能逆向 C 和 C++ 的少一点。这里就要借鉴大佬的博客了(→点我←)，里面有讲到如果在NDK层来做校验。

小礼物走一走，来简

作者：Leogh
链接：https://www.jianshu.com/p/917dada294d2
来源：
著作权归作者所有，任何形式的转载都请联系作者获得授权并注明出处。