前面几篇我们分别讲了信息收集、证书绕过、反编译脱壳、小程序逆向。单独看都是招式，实战里得把它们串成一条线。这一篇我用”对一个虚构电商 APP 做授权测试”的例子，把整套流程走一遍，给你一套能复用的移动端渗透工作流。
本文为教学示例，目标为虚构。所有手法仅用于你对自有或已授权的 APP 做安全评估，严禁对第三方 APP 未授权测试。
阶段零：明确范围与授权
动手前第一件事不是技术，是边界。确认清楚：测哪个 APP、哪个版本、哪些接口、能不能脱壳/重打包、报告给谁。没有书面授权的移动端测试，和入侵没有本质区别。这一步看似官僚，却是安全工程师和”搞破坏的人”的分水岭。
拿到授权后，建一个工作目录，准备工具链：MobSF（静态扫描）、jadx + apktool（反编译）、Frida + Objection（运行时 Hook）、Burp（抓包）、一台 root 的测试机或模拟器。
阶段一：静态信息收集（半小时体检）
先把 APK 丢进 MobSF，自动扫一轮：
# MobSF 起好后，网页上传 app.apk，等报告
# 重点看：权限、暴露组件、硬编码密钥、已知漏洞（CVE）报告里 MobSF 标红的几项先记下来：比如它发现 AndroidManifest 里有个 exported="true" 的 Activity，还发现代码里写了个 api_key。同时用 aapt 看权限，发现这电商 APP 申请了”读取短信”权限——一个购物 APP 要读短信干嘛？值得追。
阶段二：抓包看流量（先过证书关）
配好 Burp 代理，打开 APP，果然”网络错误”。按上一篇的办法，用 Objection 绕过证书绑定：
objection -g com.shop.demo explore
android sslpinning disable再点 APP，Burp 里涌出一堆请求。重点看登录、下单、个人中心这几个接口的响应——发现个人中心接口返回了一大坨数据，除了该用户自己的，还夹带了相邻用户的部分信息（靠改个 id 就能看到别人的昵称和头像）。这就是越权（IDOR）的苗头，先记下。
阶段三：反编译读逻辑（找签名与密钥）
抓包看到请求里有个 sign 参数，像是防篡改签名。想知道它怎么算的，就得看代码。jadx 打开 APP，搜 sign、md5、hmac：
# jadx 里搜索关键词，定位签名生成函数
# 发现类似：
# String sign = Md5.md5(params + "固定盐值123");好家伙，盐值写死在代码里。这意味着攻击者能完全复现签名算法，伪造任意请求——签名形同虚设。同时发现 api_key 确实是写死的第三方统计 SDK 密钥，泄露无大碍但仍是不良实践，记一笔。
阶段四：脱壳（遇到加固时）
假设这个 APP 做了梆梆加固，jadx 打开只有壳的 loader，业务代码不在。按脱壳篇的办法：
frida-dexdump -g com.shop.demo -d
# 得到多个 dump 的 dex，逐个用 jadx 打开在其中一个 dump 出的 dex 里找到了真正的业务类，确认了签名算法和盐值，和阶段三的推测吻合。脱壳这一步验证了我们的判断，也拿到了完整代码用于后续分析。
阶段五：构造与验证漏洞
把前面发现串起来验证：
- 越权（IDOR）：抓个人中心请求，把
user_id=1001改成1002，重放，确实返回了他人信息——确认高危越权。 - 签名可伪造：用脱壳得到的盐值，在 Burp 里用插件重算
sign，篡改订单金额参数后重新签名，服务器居然收下了——确认”服务端未校验签名/金额”，属于严重逻辑漏洞。 - 过度权限：读短信权限实际未使用，属隐私合规问题，建议移除。
每个发现都要”可复现、有证据”：截图请求响应、记录复现步骤、评估影响（能读到多少人信息、能改多少金额）。
阶段六：写报告与修复建议
渗透的产出是报告，不是”我进去了”。一份合格报告对每个问题写清：
- 标题与严重级：越权（高危）、签名可伪造（严重）、过度权限（低）。
- 复现步骤：从装 APP 到构造请求的具体操作。
- 证据：请求/响应截图、关键代码片段。
- 影响：能造成什么后果。
- 修复建议：越权加服务端鉴权；签名别用客户端盐值，关键校验放服务端；移除无用权限。
记住：你的目标是帮对方变安全，不是秀技术。报告越能帮开发改，价值越高。
一套可复用的工作流
把这次实战抽象成模板，以后照着走：
- 授权与范围确认 → 2. 静态收集（MobSF + aapt）→ 3. 抓包（过证书绑定）→ 4. 反编译/脱壳读逻辑 → 5. 构造验证漏洞 → 6. 报告与建议。
每步产出都往工作文档里记，别靠脑子。流程化能让你不漏项，也方便交接和复盘。
常见坑
- 只抓包不读码：流量看到异常却不懂为什么，容易误判；代码和流量对照才准。
- 验证不严谨：看到一次异常就下结论，结果换个账号不复现，报告可信度崩塌。务必多验证。
- 忽略合规项：只报”能打进去”的技术漏洞，漏掉隐私合规问题，报告不完整。
从一次实战到可复用的方法论
做过一次完整测试，最大的收获不该是”某个 APP 有洞”，而是”你形成了一套自己的方法论”。高手和新手的区别，不在于会不会用某个工具，而在于遇到陌生目标时，脑子里的流程是否清晰、是否不漏项。前面那套六步工作流，建议你每次都照着走，并在每次结束后复盘：哪步卡了、哪步发现了关键线索、哪步其实可以更早做。流程跑多了，它会从”清单”变成”肌肉记忆”，你上手新目标时自然就知道先摸哪、再看哪。
再说说练习环境。真刀真枪测商业 APP 既违规又危险，但练手的地方很多：自己写个故意留洞的 APP 测、参加移动安全 CTF、用各平台提供的官方靶场 APP、在模拟器里搭一套含漏洞的测试应用。这些环境明确授权你测试，你可以放心把整套流程跑熟，从信息收集一路打到写报告。等你在授权环境里把链路走通几十次，再去面对真实授权项目，才不会手忙脚乱。
最后提醒一个职业习惯：把每一步的证据留好。请求响应截图、关键代码位置、复现步骤，当时觉得记得住，过两周写报告时全得重新找。边测边记，报告是水到渠成的事；测完再补，往往漏掉最关键的那一笔。测试者的专业，一半在技术上，一半在能不能把发现清楚、可复现地交出去。
还有一个实战里极容易被忽视的环节:收尾时的”去敏”。你工作目录里攒了大量抓包记录、脱壳代码、可能含真实用户数据的响应截图,这些本身就是敏感材料。测试一结束,就该按约定清理或加密保管,别随手留在笔记本、云盘、聊天记录里。曾经有团队因为测试数据泄露,反而给客户造成二次风险。专业不仅体现在”打得多准”,也体现在”收得多干净”。把去敏当成流程的最后一步,和写报告同等重要。
这一篇你该记住的
- 实战 = 授权 → 静态收集 → 抓包 → 反编译/脱壳 → 验证 → 报告，六步走。
- MobSF 做第一轮体检，aapt 看权限，Burp 看流量，jadx/apktool 读逻辑。
- 证书绑定用 Objection/Frida 过，加壳用 frida-dexdump 脱。
- 每个漏洞要可复现、有证据、评影响；签名盐值写死是典型严重问题。
- 产出是报告不是”我进去了”，修复建议比炫技重要。
移动端讲完了，但现代 APP 背后几乎都挂着一套 API。下一篇我们跳出 APP 本身，看 API 这个更广阔的攻击面——先认识 API 都有哪些接口种类。