4.3 逆向与漏洞管理

4.3 逆向与漏洞管理

本节摘要：SOURCE 4.4–4.5：逆向用于理解逻辑与提取硬编码 secret；漏洞管理要求分级、SLA、复测与发布阻断。本节给 jadx→Frida→报告→Jira 的闭环，合并原 4.4/4.5 内容。

阅读收获

1. 用 jadx/apktool 定位硬编码与证书校验逻辑
2. 按 CVSS 或 DREAD 给移动漏洞定级
3. 定义 Critical 24h / High 7d 修复 SLA

一、逆向分析流程

apktool d app-release.apk -o out
jadx -d jadx-out app-release.apk
# 搜索：password, secret, AES, TrustManager, addJavascriptInterface
​

关注点：

• strings.xml / BuildConfig 泄露 endpoint
• 自定义 X509TrustManager 空实现
• Native .so 中密钥（用 Ghidra/IDA 辅助）

逆向分析流水线

逆向分析流水线

二、Frida 示例（自有 App 验证）

// hook SharedPreferences putString — 看是否写 token
Java.perform(function () {
  var SP = Java.use("android.app.SharedPreferences$Editor");
  SP.putString.implementation = function (k, v) {
    console.log("putString", k, v);
    return this.putString(k, v);
  };
});
​

三、漏洞管理

流程：发现 → 确认 → 分配 → 修复 → 复测 → 关闭。复测必须附 MobSF/Burp 截图或自动化用例 PASS。

四、合规与披露

• 内部：安全邮箱 + responsible disclosure 政策
• 监管：个保法要求 breach 通知时限
• 商店：Google Play / App Store 安全表单更新

⚠️ 常见坑：漏洞修在服务端，客户端老版本仍泄露 — 需最低版本强制升级。

💡 关键直觉：逆向不是为了破解竞品，是为了验证自己的攻击面。

要点串联

• jadx + Frida 是移动逆向标配
• 漏洞需 SLA 与复测证据才能关单
• Critical 应能触发发版阻断
• 老版本客户端是长期 tail risk

第 5 章：Android/iOS 平台机制与 SDLC 合规。

深化：逆向定位与漏洞定级

逆向的价值在于验证攻击面：密钥是否在包里、证书校验能否绕过、业务逻辑是否被篡改。流程上 jadx 看 Java 层逻辑与字符串，Frida 动态验证运行时行为，Native 层才需要 Ghidra。先静态定位候选点，再动态确认，避免大海捞针。

// Frida：验证密钥是否运行时暴露（自有 App）
Java.perform(function () {
  var Cipher = Java.use("javax.crypto.Cipher");
  Cipher.init.overload('int', 'java.security.Key').implementation = function (mode, key) {
    console.log("Cipher.init", mode, key.getAlgorithm());
    return this.init(mode, key);
  };
});
​

漏洞定级用 CVSS 或简化矩阵：利用难度、是否远程、影响范围、是否需要用户交互。移动场景特别注意「设备丢失、越狱后」这类本地威胁，与远程可利用的漏洞分开定级。定级决定 SLA：Critical 24 小时响应、热修复发版；High 7 天内修进下个版本。复测必须附证据才能关单。

逆向分析的合规边界

逆向只用于自有或书面授权的 App，这是红线。合法的逆向用途包括：验证自己的密钥是否暴露、检查第三方 SDK 实际行为、审计发布包与源码一致性。分析过程中的产出（反编译源码、hook 脚本、密钥样本）要妥善保管，不公开、不外传。很多移动安全的恶性事件恰恰是「研究者的逆向成果被拿去打黑产」，守住授权与保管两条线，是这一行的职业底线。

漏洞管理的闭环指标

漏洞管理要有闭环指标，而不是「开了单就完事」。建议跟踪：Critical/High 的关闭时长、复测通过率、回归漏洞数量（上一版本修复过又出现的）、按模块统计的漏洞密度。指标的意义在于发现问题：某个模块漏洞密度长期偏高，说明该模块需要架构级改进而不是逐个打补丁；回归漏洞多，说明测试覆盖不足。每月复盘一次指标，把「修漏洞」升级成「消除漏洞产生的条件」，才算是真正的闭环。

白帽与责任

移动安全研究者的价值在于帮助厂商提前发现并修复漏洞，这依赖负责任的披露。发现漏洞后：先在自有或授权范围内确认，再通过厂商安全邮箱或披露渠道报告，给厂商合理的修复时间，到期才考虑公开。公开披露时只给必要信息，避免给出可被利用的攻击细节。守住这个流程，逆向分析才站在防御一方，这也是本教程反复强调授权的根本原因。

最低版本强制升级

移动特有的收尾手段是最低版本强制升级：服务端修复后，老版本客户端仍可能是泄露通道。策略是服务端记录客户端版本，低于安全基线时拒绝高风险接口并提示升级。强制升级要考虑用户流失与兼容成本，通常分级推进：先高危接口强制，再逐步扩大范围。这个机制要把「版本号 → 风险等级」的映射维护好，作为漏洞关闭的最后一道闸。