安卓App完整性校验绕过：Play Integrity和签名和Dex校验
安卓 App 完整性校验是 Google Play 的安全机制。开发者可以检测 App 是否被篡改。逆向时需要绕过。一、Play Integrity API（原 SafetyNet）
Google 的设备完整性验证服务。App 调用 Play Integrity API，Google 服务器返回设备是否可信、App 是否被篡改的判断。
绕过方法：
[*]用 Frida hook 网络请求，伪造 Google 服务器返回的 JSON。需要知道完整的 response 格式
[*]用 Magisk 模块（如 Shamiko）隐藏 root 和 hook 痕迹
[*]在 Google Pixel 设备上用 LSPosed 隐藏 Xposed 痕迹
二、应用签名校验
App 在运行时调用 PackageManager 获取自身签名，跟预设值比对。
Frida 绕过：
Java.perform(function() {
var PM = Java.use("android.app.PackageManager");
PM.getPackageInfo.overload('java.lang.String', 'int').implementation = function(name, flags) {
var info = this.getPackageInfo(name, flags);
info.signatures.value = Java.array("android.content.pm.Signature", [
Java.use("android.content.pm.Signature").$new("原签名hex")
]);
return info;
};
});
三、Dex 完整性校验
App 运行时计算 classes.dex 的 hash，跟预设值比对。防止重打包。
绕过：找到校验代码（通常在 Application.onCreate 或 native 层），用 Frida hook 让 hash 比较返回 true。或者直接 patch smali 删除校验逻辑。
四、文件存在性检测
App 检查 /system/xbin/su、/sbin/.magisk 等路径是否存在，判断是否 root。
绕过：用 Magisk Hide 或 Shamiko 模块，让目标 App 看不到这些文件。
https://www.metk.cn/img/posts/app_integrity.jpg 占坑编辑ing 写得很细，尤其是中间那段，说到点上了。 静态分析搞不定的部分，动态跑一遍基本就清楚了。这套思路对其他 App 通用吗？ 关键算法的定位比还原实现更耗时间。这类分析一般要多久能出结果？ 混淆只能提高门槛，不能真正阻止有心人。想了解下有没有遇到反调试的坑？ 通信协议那层如果能抓到明文，能省掉大量逆向工作。 这类活很吃经验，工具只是辅助。 这类技术更新的频率很高，老教程参考价值有限。 整体思路对，不过细节上不同版本差异还是很大的。