0、前言

最近在肝洛克王国嘿嘿嘿，忘记更新了，今天终于把图跑完了。有时间写文章了。

今天，就和大家分享一次从抓包受挫到逆向源码，最终通过 Hook 技术实现降维打击，成功挖掘支付漏洞的实战过程。

1、功能点分析

登录app很多功能需要充钱才能使用，那么主线任务就是查看是否有支付漏洞，不然app其他功能点也无法使用就没有挖掘的必要性了

支付界面有两个产品选择，随便选择，主要是抓取数据包分析

查看支付数据包，完蛋存在加密

面对密文，我们不能硬刚。根据经验，我们需要先提取数据包中的核心关键字，作为后续逆向分析的“路标”。提取出的关键字如下

/mta/build_alipay_ordebuild_alipay_ordedata

2、逆向源码寻找突破口

既然抓包走不通，我们就直接把 APK 拖进反编译工具（如 Jadx），通过刚才提取的关键字全局搜索，看看这串密文到底是怎么生成的。

运气不错，查看调用链，我们非常顺利地找到了拼接这串 URL 和参数的目标方法。代码如下：

public void m9426(String str, String str2, String str3, String str4, String str5, String str6, String str7) {    String str8 = Urls.URL_BUILD_ALIAY_ORDER + "?data=";    HashMap map = new HashMap();    map.put(DBDefinition.TITLE, str2);    map.put("pay_for_what", this.f8408);    map.put("pay_for_what_des", str3);    map.put("money", str4);    map.put("id", this.f8407 + "");    map.put("pay_count", SdkVersion.MINI_VERSION);    map.put("dead_time", str5);    map.put("combined_id", str);    map.put("diy1", str6);    map.put("user_id", str7);    PayBusUtils.post(2001, "开始生成支付订单...");    String str9 = f8406;    if (Spu.m11550(str9)) {        C4448.m9567(str9, "0.开始生成支付订单-->" + map);    }    String str10 = str8 + XMBSign.buildUrlData(map);    if (Spu.m11550(str9)) {        C4448.m9567(str9, "1.服务器生成订单:开始请求链接-->" + str10);    }    XMBOkHttp.doGet(str10, new C4393());}

3、核心思路转换：不解密，只劫持！

分析到这里，很多师傅可能会陷入一个误区：死磕 XMBSign.buildUrlData(map) 这个加密方法。

但是根据笔者的后续分析，这个加密的 Key 是动态生成的，如果非要把加密算法彻底还原并写出单独的 Python 脚本，不仅耗时耗力，而且很容易卡壳。

这个时候，我们需要转换思路：“借鸡生蛋”。

既然我们知道 m9426 这个方法接收的是明文参数（尤其是 str4 代表着 money），我们为什么不在这个方法执行之前，把它拦下来呢？

核心 Hook 攻击逻辑如下：

1. 确定 Hook 点： 锁定 m9426 这个方法。
2. 拦截与读取： 当用户在前端点击“购买”时，APP 会尝试调用 m9426 准备组装数据。此时，我们的 Hook 脚本（如 Frida 或 Xposed）介入，拦截这次调用，并读取传入的所有明文参数。
3. 恶意篡改： 我们在脚本中，将代表金额的 str4 参数（假设原本是 "99.00"）强行修改为 "0.01"。
4. 放行并回传（关键点）： 我们并不需要自己去计算后续的签名和加密。我们直接利用修改后的参数（"0.01"），主动调用 APP 自身的 m9426 方法。
5. 完成欺骗： APP 后续的代码会乖乖地拿着我们修改后的 "0.01"，塞进 HashMap，使用它自己合法的动态 Key 进行签名加密，最终向服务器发送一个完美伪装、且签名绝对正确的“0.01元”购买数据包。

这是笔者画的草图，大概就是如下的逻辑

4、漏洞利用与最终效果

基于上述思路，我编写了对应的 Hook 脚本（由于具有一定攻击性，具体代码暂不放出，大家理解思路即可）。

运行脚本后，我成功在控制台拦截到了真实的明文数据包：

接下来，开启我们的“篡改放行”逻辑：

最后，我们回到前端走完支付流程。果然，调起支付界面时，订单金额已经被成功篡改！我们最终以 0.01 元的代价，成功购买了该 APP 的终身会员。最后编写报告提交平台换证书。

总结

遇到加密数据包时，不要一味地死磕加密算法本身。“上游拦截，篡改放行” 的 Hook 思路往往能达到事半功倍的效果。

对于开发者的修复建议：

此类漏洞的本质是服务端缺乏校验。价格不应该由客户端计算或传递（哪怕你做了极其复杂的加密验证机制）。正确的做法是：客户端只传递产品 ID（如 item_id=1001），具体的金额必须由服务端通过查询数据库得出，并在服务端发起真正的支付请求

郑重免责声明

1. 研究与防御目的：本文所分享的所有技术原理、逆向思路及实战案例，仅严格用于网络安全技术讨论、防御机制研究及安全测试学习。旨在帮助广大开发者和安全从业者了解攻击手法，进而完善应用的安全防护体系。
2. 合法授权与脱敏：文中所涉及的漏洞挖掘与测试过程，均在已获得合法授权的自有/测试环境中进行，且相关敏感信息（如 APP 名称、真实接口、具体代码等）均已做过严格的脱敏处理。
3. 严禁非法利用：强烈呼吁广大读者严格遵守《中华人民共和国网络安全法》及相关法律法规。 请勿将本文涉及的任何技术手段（包括但不限于 Hook 技术、参数篡改、反编译等）用于任何未授权的非法渗透测试、破解牟利、破坏他人计算机信息系统或侵犯他人合法权益的行为。
4. 后果自负：读者若以本文内容为依托，在未经授权的情况下对任何系统、应用进行实际攻击或非法测试，所引发的一切直接或间接的法律后果及连带责任，均由具体操作者本人完全承担。本文作者及本公众号/平台对此概不负责，亦不承担任何连带法律责任。