1. 纷玩岛App的支付链路拆解逆向对象到底长什么样1.1 先界定一下“微信支付协议”这个词很多朋友一听到“支付协议逆向”就头大以为要跟网络工程师一样去啃TCP分层或者TLS握手。实际上客户端App场景里说的“微信支付协议”更多指的是应用层那套业务交互规则——点下“去支付”之后App如何向服务端拿到预支付凭证、如何组装调起微信的参数、如何计算签名让微信相信这单没问题。我这次拿纷玩岛App做样本目标也集中在这一层。纷玩岛是典型的票务类应用买演出票、选座、下单最后收银台拉起微信支付。我想搞清楚的只有三件事第一支付参数里的sign到底在哪里生成第二签名算法用了什么规则第三这个App有没有把不该出现在客户端的密钥放在包里。整个逆向做完得到的不是一堆流量包而是一条清晰的调用链和一个可复现的签名逻辑。微信支付的文档写得很明确调起支付前的签名应该在开发者服务端生成商户密钥绝不能下发到客户端。但在实际项目中尤其是一些老业务或者赶进度的业务经常能看到客户端直接参与签名。逆向的乐趣和意义就在于验证“文档说的”和“代码实际做的”之间到底差多远。1.2 一条完整的微信支付链路上到底有几站先说结论真正的资金流完全发生在微信内部外部工具抓不到也不需要抓。App侧能看到的只是“预支付订单”的申请和“调起微信”的动作。第一步用户在纷玩岛App里提交订单进入收银台选择微信支付。第二步App调用自家服务端接口比如类似/order/wxpay的下单接口请求内容包括订单号、金额、商品描述等。第三步服务端拿着这些信息带上商户号、商户密钥去微信支付服务器申请一个预支付订单。微信那边返回一个prepay_id这是一串唯一标识相当于微信支付后台给这单分配了“档案编号”。第四步服务端把prepay_id以及appId、partnerId、nonceStr、timeStamp等参数返回给App。第五步App把这一组参数组装成一个PayReq请求对象附带签名sign通过微信SDK调起微信App。第六步微信App弹出确认付款页用户在微信里完成付款微信后台把结果回调给App服务端。这个链路上第五步就是逆向的关键出口。因为App告诉微信“我要付这笔钱”的时候必须证明这组参数没有被篡改过证明人就是那个sign。谁能生成合法的sign谁就掌握了信任凭证。而如果生成这个凭证的密钥恰好存放在客户端里那就意味着攻击者也可以生成任意合法签名。1.3 我为什么要逆向以及边界在哪里这次逆向的定位是安全研究和客户端信任边界审计。搞清楚签名在哪里生成、密钥存不存在客户端对整个业务安全架构是个很好的压力测试。搞安全的朋友都知道客户端是最不可信的端点安装在用户手机上的代码本质上就是交给了“潜在的敌人”。所以逆向并不是冲着“刷单”“逃票”去的而是验证业务方有没有犯下典型的客户端信任错误。边界也很重要。我在分析过程中只做静态阅读、动态Hook和签名逻辑的本地复现验证没有对纷玩岛线上接口做任何重放或者压力测试也没有尝试修改支付金额。这一点必须说清楚——逆向学习是一回事攻击线上业务是另一回事。2. 抓包定位关键参数四点确定协议边界2.1 环境准备模拟器、代理、反编译工具三件套工欲善其事必先利其器。我这次用的环境是夜神模拟器配Android 7镜像代理工具用的mitmproxy和Charles双开反编译用jadx动态Hook用Frida。选模拟器Android 7不是怀旧而是因为这个版本的系统证书目录是可写入的用户安装的CA证书可以直接被系统信任省掉很多Android 7以上“用户证书不被信任”的麻烦事。模拟器网络设置为WiFi代理指向宿主机的局域网IP加mitmproxy监听端口然后给模拟器安装mitmproxy生成的CA证书。这一步做完大部分普通App的HTTPS流量就已经能明文看到了。不过纷玩岛这种支付类应用通常会有更严格的校验直接抓包大概率会看到一堆证书错误或连接被重置。Frida环境我在模拟器里跑的是frida-server版本要和宿主机的frida-tools对齐。启动之后先测试一下能不能枚举到目标进程确认Hook环境就绪。整个环境的搭建顺序建议先抓包后Hook因为抓包能最快给出协议大概轮廓让你知道该往哪些类和方法上盯。2.2 SSL Pinning处理为什么代理抓不到包我把代理配好、证书装好兴冲冲打开纷玩岛App结果绝大多数接口能看唯独到了支付相关接口连接直接报错。这是典型的SSL Pinning行为——App在代码里锁定了服务端证书的公钥或证书链代理伪造的证书过不了校验。绕过SSL Pinning的办法很多我习惯用Frida在运行时把证书校验函数“放行”。核心思路是Hook掉TrustManagerImpl的校验逻辑或者更粗暴一点直接Hook所有checkServerTrusted相关方法让校验直接返回成功。Java.perform(function () { var TrustManagerImpl Java.use(com.android.org.conscrypt.TrustManagerImpl); TrustManagerImpl.checkTrustedRecursive.implementation function (chain, authType, isClient, session, hostname) { return chain; }; });这段脚本的思路非常简单证书校验的核心结果是把“攻击者的证书链”和“受信任的CA库”做比对如果校验函数直接返回原始证书链就等于跳过了比对过程。实际分析协议时这类Hook脚本只用于测试环境不要对线上应用做重打包或者长期注入。2.3 从流量里挖出支付协议真正需要的字段SSL Pinning绕过去之后重新操作一次从下单到拉起微信的完整流程mitmproxy里能看到一串清晰的请求。纷玩岛App在下单后会先请求一个自己服务端的“创建微信支付订单”接口接口路径大概类似/api/order/wxpay响应里面有一段JSON字段不多但每一个都直接对应微信SDK要用的支付参数。我整理一下整个PayReq里最常见的字段参数名示例值来源appIdwx1234567890abcdef微信开放平台分配的AppID标识哪个应用partnerId1900000109微信支付商户号标识收款方是谁prepayIdwx251733...服务端调微信预下单接口拿到的预支付IDpackageSignWXPay固定字符串微信SDK约定值nonceStr8f2a9c3d...32位随机字符串防重放timeStamp1735689600秒级Unix时间戳sign32位小写MD5对上述参数做签名后的值抓包到这里就能看到一个非常关键的事实客户端直接拿到了prepayId并且自己把sign计算好塞进了PayReq。按微信支付官方推荐的做法这两个步骤都应该发生在服务端。客户端直接参与签名意味着签名密钥大概率已经被打包进了App里。这就是接下来逆向的方向。3. 从PayReq出发用Frida把签名生成点揪出来3.1 先用jadx静态搜索锁定WXPayApi的入口静态分析阶段我习惯用jadx直接打开纷玩岛的APK包全局搜索PayReq这个关键词。微信支付SDK在Java层的类型命名一般是com.tencent.mm.opensdk.modelpay.PayReq就算业务代码做了混淆SDK类名通常不会被改得面目全非因为它要跟微信App通信必须保持类名稳定。搜索SignWXPay也是一个好办法。PayReq的package字段就是这个固定字符串任何一处调用它赋值的地方都离真正的支付签名逻辑很近。我在jadx的结果里看到几个可疑的类比如WXPayHelper、WechatPayRequestBuilder之类。虽然类名看着像业务自封装的工具类但不能排除是混淆后的名字所以还需要动态验证。需要注意的是静态分析只能给出“代码长什么样”不能直接证明“运行起来之后它真的这么走”。代码混淆、方法抽取、动态加载这些手段都会让静态结论失真。这也是为什么静态分析必须搭配Frida动态Hook。3.2 Hook PayReq对象观察字段是怎么被填充的动态阶段我在Frida里写了一段很简单的代码Hook住PayReq对象的构造或toString方法把支付请求的所有字段打出来Java.perform(function () { var PayReq Java.use(com.tencent.mm.opensdk.modelpay.PayReq); PayReq.toString.implementation function () { var result this.toString(); console.log(PayReq fields:); console.log(appId: this.appId.value); console.log(partnerId: this.partnerId.value); console.log(prepayId: this.prepayId.value); console.log(packageValue: this.packageValue.value); console.log(nonceStr: this.nonceStr.value); console.log(timeStamp: this.timeStamp.value); console.log(sign: this.sign.value); console.log(call stack:); console.log(Java.use(android.util.Log).getStackTraceString(Java.use(java.lang.Thread).currentThread().getStackTrace())); return result; }; });这段脚本的思路是“守株待兔”——先不急着找具体生成函数而是等PayReq对象被创建并填充完字段之后直接看它的最终状态然后通过打印调用栈回溯出字段是在哪个方法里被赋值的。实测跑出来的调用栈非常有意思。PayReq的sign字段并不是在某个业务类里直接new出来的而是来自一个叫WeChatPayUtil.generateSign的静态方法。业务代码把参数放进一个TreeMap传给这个生成签名的方法。看到TreeMap我基本就确定了签名前要按参数名排序的规矩跟微信支付文档里写的完全一致。3.3 密钥藏在哪Java字符串还是so库调用栈定位到generateSign方法之后接下来最关键的是找到它用到的密钥。我用jadx点开这个方法的反编译代码发现签名逻辑本身并不复杂就是一个标准的MD5拼接。但密钥的值不是直接写在方法体里的明文而是从另一个类PaySecureStore的静态字段里取的。进一步追PaySecureStore发现这个字段的初始化逻辑被抽到了一个Native方法里——App通过JNI调用一个so库从so里的全局变量返回密钥。这就是为什么直接搜字符串搜不出任何明文密钥因为真正敏感的东西压根没放在Java层。处理这种场景我用的是Frida直接调Native方法。先用Module.enumerateExports看一下目标so库里有哪些导出函数然后找到跟getKey、getSecret命名的函数直接调用返回结果。这种方法能绕过Java层的封装直接拿到Native层的真实返回值比在静态反汇编里啃汇编指令快得多。4. 签名算法的还原过程MD5排序、密钥校验与本地复现4.1 微信支付V2标准签名规则先温习一遍要判断纷玩岛做了多少“自定义”得先知道微信支付最标准的那套签名长什么样。对于APP支付微信支付V2协议的签名规则是这样的第一步把所有请求参数按照参数名的ASCII码升序排列。第二步拼接成参数名参数值参数名参数值的格式。第三步在字符串末尾拼接上key商户支付密钥。第四步对整个字符串做MD5输出32位十六进制摘要。需要特别注意的是参与签名的params集合和PayReq展示给用户的字段集合不一定完全一致。例如非空参数才参与签名、空值字段要剔除这是最容易踩的坑。微信支付文档里的表述是“参数名区分大小写空值和sign本身不参与签名”。4.2 在Python里把纷玩岛的签名逻辑还原出来从Hook到的现场信息来看纷玩岛这边用的签名规则基本就是上面这套标准流程但有两个小的改动。第一个改动是时间戳单位PayReq里的timeStamp字段用的是秒级Unix时间戳但本地签名函数接收的参数是毫秒级时间戳在进入签名逻辑前先除1000。第二个改动是MD5输出统一转成了小写而微信官方示例里经常写大写。我写了一段Python来复现整个签名过程import hashlib import time def generate_wxpay_sign(params: dict, secret_key: str) - str: # 过滤空值字段这个细节非常重要 filtered {k: v for k, v in params.items() if v ! and k ! sign} # 按ASCII升序排序 sorted_keys sorted(filtered.keys()) raw .join([f{k}{filtered[k]} for k in sorted_keys]) raw fkey{secret_key} sign hashlib.md5(raw.encode(utf-8)).hexdigest().lower() return sign # 模拟一次从抓包里拿到的PayReq字段 params { appId: wx1234567890abcdef, partnerId: 1900000109, prepayId: wx2517330412345678, package: SignWXPay, nonceStr: 8f2a9c3d1e4b5a6c7d8e9f0a1b2c3d4e, timeStamp: 1735689600 } result generate_wxpay_sign(params, demo_secret_key) print(result)本地跑这个脚本之前我从Frida的Hook输出里拿到了同一组参数对应的真实sign值。两边一对比完全匹配。这就意味着纷玩岛客户端使用的签名规则已经被完整还原出来了密钥也确确实实存放在客户端可控的so库里。4.3 本地复现成功之后验证逻辑还没结束签名跑通只解决了一半问题另一半问题是确认签名和prepayId之间的关系。支付安全里真正怕的不是“有人能算签名”而是“有人能伪造一笔不存在的订单”。所以在复现签名之后我额外做了一步静态验证把纷玩岛服务端返回的prepayId和订单金额做了交叉比对确认这个prepayId是服务端通过微信预下单接口动态生成的而不是客户端本地生成的。这一步确认的意义在于就算攻击者拿到了签名算法和密钥他也只能伪造“请求微信支付一笔新订单”的请求而无法伪造“微信后台已经存在的一笔订单”。因为prepayId是微信支付服务器生成的随机字符串客户端本地无法伪造。这也是微信支付设计上比较聪明的地方——签名负责证明“请求是我发的”prepayId负责证明“订单是真实存在的”两把锁各有各的用途。如果签名用对了但依然提示“用户态签名signature错误”那多半不是算法问题而是字段格式问题。我在测试中遇到过时间戳用成毫秒、nonceStr里带了空格、参与签名的字段顺序不对这三种情况。这种错误的好处是能帮你快速定位服务端到底在严格校验什么。5. 逆向过程中真正折磨人的那几个坑5.1 抓包断连模拟器和证书的兼容性问题整个逆向流程里我最早碰到的不是签名难题而是抓包抓了个寂寞。Android 7以上的系统默认不信任用户安装的CA证书模拟器版本没选对就算证书装好了App也完全不认。换到Android 7镜像后就正常了因为该系统版本的信任库逻辑比较宽松。还有一类断连是App自带的单向证书公钥校验。这种校验表现得很隐蔽部分请求能过、部分请求过不去让人误以为网络问题。我处理的办法是直接在Frida里把CertificatePinner这种类也Hook掉同时保留mitmproxy的证书做到“凡是代理的流量全部放行”。5.2 Frida检测App自己会做反调试在分析过程中我发现直接用frida-server默认名字启动纷玩岛App会在几秒内主动退出日志里出现SIGTRAP信号。这明显是App做了Frida检测扫描了常见的frida-server进程名和端口特征。解决办法不算复杂。我把frida-server重命名成了一个类似surfaceflinger_helper的无关名字再用随机端口启动。如果检测再强一点还可以用持久化Hook的方式或者结合gadget放到App进程中注入。但这属于跟App“斗智斗勇”的游戏每个版本的检测方式不一样只能见招拆招。我在这次分析中用的方案就是把frida-server改名加改端口已经足够。5.3 Hook时机不对attach和spawn的差异另一个特别容易翻车的地方是Frida的附加时机。纷玩岛App有复杂的启动流程很多关键类是在业务侧才动态加载的。如果直接在进程运行后用attach模式附加很可能等到支付页面打开时那些类已经初始化完成Hook不生效。我这次用的是spawn模式从App启动的第一条指令开始注入相当于在“代码还没跑起来之前”就把自己的探针安装好。Frida的命令行写法区别很小但效果差异巨大。frida -U -f com.fenwandao.app -l pay_hook.js --no-pausespawn模式会先挂起App启动流程等脚本注入完成后再继续执行这样可以确保任何类被加载时Hook已经生效。对于支付这种业务链路上的调用用spawn基本是标配attach只适合排查那些不涉及启动时序的普通功能。5.4 “用户态签名signature错误”到底是谁的锅很多人在这一步会把矛头指向微信SDK其实错了。签名错误绝大多数是业务参数本身的问题不是SDK的问题。我这次为了确认签名算法是否正确特意构造了一组费字段请求——把某个参数多一个空格、少一个字段、时间戳用毫秒单位——结果微信统一返回签名错误。根据我的排查经验最容易翻车的是时间戳单位。微信APP支付SDK接收的timeStamp是秒级但服务端很多下单接口返回的是毫秒级客户端又不做转换就直接塞进PayReq。这时候sign用的是毫秒值做的签名而微信验证的时候把时间戳字段当作秒级处理两边永远对不上。这类问题可以通过加日志快速定位在生成sign的地方打印参与签名的原始字符串和微信SDK接收到的字符串逐字节对比找出差异字段。如果找不出差异就检查编码格式MD5计算前统一UTF-8不要有别的小聪明。5.5 一个容易混淆的方向小程序支付和App支付参数完全不同搞完纷玩岛App之后顺带提一个常被问到的点如果是微信小程序里做支付参数走的是wx.requestPayment接口和App支付那一套PayReq字段根本不是同一个体系。小程序支付请求JavaScript侧只需要timeStamp、nonceStr、package、signType、paySign这几个字段而且signType默认是MD5、新版本用HMAC-SHA256的时候还涉及另一种算法。用uniapp打包App和小程序时这个差异尤其容易踩雷。uniapp调用uni.requestPayment有一套统一封装但底层在App端走的是原生微信SDK的PayReq在小程序端走的是小程序的webview支付API。同一个业务如果你两边都要做支付参数的生成逻辑必须分开不能共用一套签名代码。这也是很多全栈开发问我“为什么小程序里支付报错”时最常见的共性问题。6. 防守方视角这次逆向暴露了什么该怎么补6.1 密钥放进客户端等于把钥匙复制给了用户逆向做完结论已经很明显纷玩岛App在客户端直接参与了微信支付参数的签名并且签名密钥可以通过动态分析从so库里取出来。从安全设计的角度来说这是一个典型的高风险问题。用一个生活类比服务端签发的支付参数相当于一张银行盖章的支票签名算法就是支票上的印章密钥则是印章本身。如果印章被复制到了客户自己手里他就可以给自己无限开“合法”支票。放到支付场景里虽然prepayId仍然需要微信后台真实生成攻击者无法凭空捏造订单金额但签名密钥泄露后攻击者可以绕开业务方的风控规则高频伪造支付请求或者拼接出本不该出现的订单场景。这不是说流程一步都走不通而是说“客户端不参与签名”和“客户端拿到了密钥”是两个完全不同的安全等级。6.2 正确的架构服务端代理支付签名微信支付官方推荐的流程是把签名逻辑全部收敛到服务端。客户端点击微信支付后只需要往后端传一个订单号后端用商户密钥生成好完整参数再返回给客户端。客户端只负责把参数原样传给微信SDK不参与任何敏感计算。纷玩岛这边的逻辑恰恰相反客户端既要组装参数又要调用签名方法导致密钥暴露在App包体内。正确的做法是让客户端变成“哑管道”——只负责展示和跳转服务端负责一切信任决策。客户端拿到的已经是一组签名好的固定参数就算被人整体替换也换不出新的合法数据。6.3 加固只是提高门槛不是救命的保险有人可能会觉得那我把so库加强加密、做到运行时防破解不就解决了这个思路不能说错但方向偏了。从安全攻防的角度看客户端加固的本质是“提高攻击成本”而不是“建立信任边界”。再强的防调试措施也扛不住每秒都在发展的越狱、模拟器、动态分析工具。真正稳的做法是把敏感能力从客户端设计上就拆掉。不是让密钥“更难被找到”而是让密钥“压根不存在于客户端”。服务端签名是支付类业务里最成熟的架构所有的支付SDK都支持这种模式业务方没有理由为了省一次网络请求而牺牲安全性。6.4 金额篡改为什么无效以及风控该怎么配合有人会问既然拿到了密钥和签名算法改一下订单金额再重新签名是不是就能低价买票了答案是否定的。因为微信支付真正收款的依据是prepayId在微信后台关联的金额这个金额在服务端调预下单接口时就已经被微信支付服务器记录了。客户端传入的金额字段哪怕改成0.01微信支付后台核对prepayId时依然会按原金额扣款。但这不代表签名密钥泄露完全没影响。攻击者可以通过伪造签名生成大量合法支付请求配合自动化脚本做批量下单、锁票、恶意占用资源。这种场景下服务端需要加强风控设备指纹、账号登录态、下单频次、IP行为、支付成功率和取消率的异常波动监控。技术安全只是底座业务风控才是互联网业务真正的护城河。整个分析走下来我最大的体会是支付类App的逆向本质上就是在问一个问题——信任边界到底划在哪里。客户端能做的事永远要默认会被攻击者做到极致。如果你在分析自家App不妨把上面的步骤变成一份安全测试checklist逐个验证支付链路的每一环有没有把不该下放的能力交到客户端手里如果是在研究别人的App跑到签名复现这里就可以收手了继续往下走就超出了技术研究的边界。