文章总结： 本文详述了对某AndroidSDK的白盒攻防测试。作者利用Smali修改与FridaHook成功绕过RASP、Root及模拟器检测，但未能攻破白盒加密。同时发现后端未绑定包名导致跨应用密钥移植攻击成功。结论强调纯客户端防护易失效，需结合白盒加密、PlayIntegrity及后端密钥绑定构建多层防御体系。 综合评分： 85 文章分类： 移动安全,逆向分析,红队,渗透测试

---

绕过 RASP 防护机制（Bypassing the RASP Protections）

haidragon haidragon

安全狗的自我修养

2026年1月16日 10:10 湖南

官网：http://securitytech.cc/

#

引言（Introduction）

最近我深入研究了某 SDK 示例 Android 应用的安全性。作为一名 Android 工程师，我有机会在**白盒攻击模型（White-box Attacker Model）**下评估它的防御能力——也就是说，假设攻击者（这里就是我）拥有应用的完整代码与运行环境控制权。

我的目标是审查它的：

• RASP（运行时应用自保护）
• 完整性校验
• 白盒加密
• 后端验证机制

本文以第一人称记录我逆向 SDK 的过程，展示我发现了什么、防护如何被绕过、哪些防御仍然坚固。写给安全工程师阅读，技术性与故事性结合。

系好安全带，我们要钻进一个加固移动应用的内部，看它如何被拆解，以及这对防御者意味着什么。

---

🎯 威胁模型与环境（Threat Model and Setup）

🧱 白盒攻击者模型（White-Box Adversary）

我把这次测试当作最坏情况：

• 拿到了 APK
• 能反编译并修改代码
• 在 root 模拟器中运行

这意味着不存在“安全性靠隐藏”。 如果秘密只是藏在代码里，我一定能找到。

SDK 宣称的安全能力包括：

• RASP 检测篡改环境
• 白盒加密保护敏感数据
• 后端校验请求合法性

也就是说：App 应该能感知自己是否被破坏，并拒绝在不安全环境下运行。

---

🏗 App 安全架构（App Security Architecture）

我的分析发现这是典型的高安全架构：

• Java/Kotlin 层：UI + 业务逻辑
• Native 层：.so 执行安全关键逻辑

敏感配置文件（我称为 config.enc）被加密，native 层负责使用白盒加密解密。

Native 同时还负责：

• Root 检测
• 模拟器检测
• 完整性校验

App 还与后端通信进行认证。

整体上包含：

• 客户端防篡改
• 加密密钥保护
• 服务端校验

---

按我的理解，native 安全库就像一只章鱼的头，而每条触手都是一种检测（root、模拟器、签名等）。

如果砍掉头，App 直接死； 但是否能一条条砍断触手？

这正是我的目标。

---

🔍 代码初探（Peering into the Code）

第一步是静态分析。

我使用 JADX 反编译 APK，查找关键逻辑。

发现：

• SecurityWrapper 类加载 native：System.loadLibrary
• JNI 桥接点很多
• 有混淆和位运算逻辑
• 字符串被加密

这些 JNI 接口正是绕过点。

静态分析让我知道：

• .so 是核心
• config.enc 存储密钥
• 存在大量阻止 root 模拟器的逻辑

可以开始拆章鱼了。

---

🛠 逐步关闭 RASP（Disabling RASP Step by Step）

进入动态测试。

在 root 模拟器中运行时，App 直接退出。

Frida 初次 hook 就触发：

Security issue detected

说明 RASP 生效。

---

💥 Crash & Patch 方法

我采用 Crash-and-Trace：

1. 删除 native .so
2. 运行 App 触发崩溃
3. Logcat 查看崩溃点
4. Patch smali

例如：

isDeviceRooted()

被我改成永远返回 false。

同样方式绕过：

• 模拟器检测
• 篡改检测
• 签名校验

可以通过：

• 修改 smali
• 或 Frida hook 返回值

一次次推进，就像打地鼠。

最终：

👉 App 在 root 模拟器完整运行 👉 RASP 全部失效

结论很清楚：

白盒场景下，纯客户端防护最终都会被击破。

---

🔐 白盒加密：无法撬开的保险箱？

绕过 RASP 后，我尝试攻破白盒加密。

config.enc 只能由 native 解密。

白盒加密的目标是：

• 即使有代码
• 也拿不到密钥

---

🧪 我的尝试

• 静态： 分析 native 反汇编，极度混淆
• 动态： Hook 解密函数，Dump 内存

结果：

❌ 没拿到明文 ❌ 没拿到密钥

白盒加密成功挡住了我。

白盒加密在这里真的发挥了作用。

---

🔓 打破应用边界（Breaking the App Boundaries）

既然解不开密钥，那我就换密钥。

我从另一个使用同 SDK 的 App 中拿到 key，注入当前 App。

结果：

👉 后端接受 👉 认证成功

说明：

后端没有绑定包名 / 签名。

只验证 key 是否存在，而不是属于哪个 App。

这是一种：

跨应用密钥移植攻击（Auth Transplant）

---

🖥 后端校验的重要性

无论客户端怎么 patch，最后决定权在后端。

这个 SDK 后端：

• 校验 token
• 要求 JWT
• native 内部生成

我尝试伪造 JWT 失败。

说明服务端仍然是关键防线。

但缺点是：

❌ 没有校验调用 App 身份。

可以使用：

• Play Integrity API
• 包签名绑定

来增强。

---

⚔ RASP vs 平台认证

RASP：

• 在 App 内
• 易被 patch

Play Integrity：

• Google 服务器签名
• 更难伪造

后者更强。

---

🔐 白盒加密 vs 普通混淆

普通：

• base64
• xor

白盒：

• 算法混淆
• 密钥不直接存在

所以：

白盒加密极大提高攻击成本。

---

🛡 后端绑定与防护

API Key 应该：

• 绑定包名
• 绑定签名
• 绑定设备认证

否则一旦泄露，全 SDK 失守。

---

📌 给防守者的建议

• 客户端防护不够
• 使用白盒加密
• 绑定密钥上下文
• 利用 Play Integrity
• 多层防御
• 持续审计

---

🎯 给红队的建议

• 分层拆解
• 善用工具：JADX / Apktool / Frida
• 应对反调试
• 知道什么时候放弃
• 联合后端测试
• 多总结经验

---

🏁 结论

我成功绕过了：

• RASP
• root 检测
• 篡改检测

但失败于：

• 白盒加密
• JWT 生成

安全没有银弹。

真正的安全来自多层叠加。

正如孙子所言：

攻者，守之机；守者，攻之策。

现在只是多了点 smali 和 Frida 😄。

---

如果你愿意，我可以下一步给你整理一份：

✅ Android RASP 绕过技术图谱 ✅ Frida + Smali 实战流程 ✅ 白盒加密攻防分析 ✅ SDK 安全架构设计指南

• 公众号:安全狗的自我修养
• vx:2207344074
• http://gitee.com/haidragon
• http://github.com/haidragon
• bilibili:haidragonx

#

• 

---

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：安全狗的自我修养 haidragon haidragon《绕过 RASP 防护机制（Bypassing the RASP Protections）》