简介本资源是一套面向网络安全初学者与渗透测试爱好者的Fiddler抓包实战教学包聚焦于移动端购物场景下的HTTP请求拦截与金额参数篡改实践帮助学习者理解Web通信原理及常见安全漏洞利用方式。压缩包共52个文件包含13个可执行工具exe、12个动态链接库dll支撑Fiddler插件运行、14个数据缓存文件dat记录抓包会话、4个音频提示wav辅助操作反馈以及教程文档txt、配置文件config、图标ico、JS脚本和PNG示意图等整体体积10.62MB结构完整、即开即用。已有9963人学习下载资源提供视频讲解图文文档实操工具三位一体内容涵盖夜神模拟器环境搭建、Fiddler2基础配置、商品价格字段定位与修改、支付请求重放验证等关键环节并附带发货图示与常见问题说明适合零基础入门并快速上手抓包调试。1. 为什么改金额总在 Fiddler 里卡住不是抓不到包而是改完就 400/500/签名失败/跳转登录页你下载了「完整版 fiddler抓包修改金额教程工具.rar」解压打开照着文档点开 Fiddler、勾上Decrypt HTTPS traffic、装证书、手机配代理——结果一提交订单金额刚改完接口直接返回{code:40012,msg:非法请求}或者干脆跳回登录页甚至 App 直接闪退。这不是你操作错了也不是 Fiddler 不行而是绝大多数“改金额”场景根本不是单纯改个 JSON 字段就能过验的。这个标题里的“完整版”真正值钱的不是那几个按钮截图和基础配置而是它背后隐含的三重校验逻辑服务端金额二次校验、请求体签名防篡改、支付通道级风控拦截。Fiddler 是把手术刀但没搞清病灶在哪就下刀只会让系统报错更狠。本篇不讲怎么点开 Fiddler只讲清楚什么时候能安全改金额、改哪几处才真正生效、哪些字段改了等于白改、以及为什么你改完立刻被干掉——全部基于真实电商、虚拟商品、小程序下单链路的逆向经验。适合已会基础抓包、但总在“改完提交就失败”环节反复碰壁的测试工程师、安全初学者和想验证业务逻辑边界的开发同学。2. 抓包前必须确认的 3 层前置条件绕过 SSL Pinning、处理证书信任、识别真实请求入口Fiddler 能否成功捕获目标请求不取决于你是否勾选了Decrypt HTTPS traffic而取决于目标 App 是否做了 SSL Pinning证书固定、系统是否信任 Fiddler 根证书、以及你是否抓到了真正承载金额参数的请求。这三步缺一不可且顺序不能乱。下面按实战顺序拆解。2.1 确认目标 App 是否启用 SSL Pinning先看现象再决定对策SSL Pinning 是 App 主动校验服务器证书指纹或公钥绕过系统证书信任链。一旦启用Fiddler 的中间人代理就会被直接拒绝表现为手机配好 Fiddler 代理后App 启动即崩溃或网络异常Fiddler 中看不到任何该 App 的 HTTPS 请求只有 CONNECT 隧道建立失败日志Wireshark 抓到 TLS 握手阶段Alert: fatal: unknown_ca。提示不要一上来就尝试安装 Fiddler 证书。先用adb logcat | grep -i ssl或 iOS 的 Console.app 查看 App 启动日志搜索TrustManager、pin、cert、X509等关键词。若出现javax.net.ssl.SSLHandshakeException或CertificatePinning相关堆栈基本可判定启用了 Pinning。常见应对路径按侵入性由低到高方案 A推荐使用 Frida Hook 绕过 Pinning需 root/jailbreak。执行frida -U -f com.xxx.app -l ssl-pinning-bypass.js --no-pause脚本核心是重写OkHttpClient或TrustManager的checkServerTrusted方法使其始终返回 true。方案 B改用支持自动绕过的抓包工具如 HttpCanary for Android无需 root 即可 Hook SSL但注意其证书机制与 Fiddler 冲突二者不可共存。方案 C仅限调试反编译 APK定位NetworkSecurityConfig或TrustManagerImpl调用点临时注释 Pinning 逻辑后重打包——此法仅适用于自研 App 或测试环境生产环境严禁。2.2 在设备端正确安装并信任 Fiddler 根证书Fiddler 默认生成的根证书DO_NOT_TRUST_FiddlerRoot必须被设备系统级信任否则 HTTPS 解密失败。关键细节常被忽略Android 7API 24系统默认不信任用户安装证书。必须在AndroidManifest.xml中添加android:networkSecurityConfigxml/network_security_config并在res/xml/network_security_config.xml中显式声明trust-anchors包含user类型证书。否则即使证书已安装App 仍走系统证书链Fiddler 无法解密。iOS 10.3证书安装后需进入设置 → 已下载描述文件 → 安装 → 设置 → 通用 → 关于本机 → 证书信任设置手动开启对DO_NOT_TRUST_FiddlerRoot的完全信任。缺这一步Safari 可抓但多数 App尤其 WebView 内嵌仍失败。Windows/macOS 桌面端浏览器需单独导入证书到“受信任的根证书颁发机构”。Chrome 基于系统证书库Edge 同理Firefox 使用独立证书库需在about:preferences#privacy → 证书 → 查看证书 → 证书机构 → 导入。验证是否生效在 Fiddler 中发起一个 HTTPS 请求如https://httpbin.org/get观察Inspectors → TextView是否显示明文响应体。若仍为乱码或显示Tunnel to...说明证书未生效。2.3 定位真正携带金额参数的请求别在登录页或首页瞎抓“修改金额”不是改任意一个带price字段的请求而是必须找到下单流程中最后一个、且服务端未做前端脱敏的支付确认请求。典型路径如下请求阶段常见 URL 特征是否含真实金额备注商品详情页/api/item/detail?id123❌通常返回originalPrice和currentPrice但非下单价前端可能二次计算优惠实际下单价以结算页为准购物车页/api/cart/list❌返回各商品单价但未聚合运费/优惠券金额未最终确定服务端不校验结算页预检/api/order/precheck?skuIds1,2⚠️可能返回totalAmount但仅为预估无签名此请求常被忽略却是关键校验入口支付确认提交/api/order/confirm或/api/pay/submit✅含payAmount、discountAmount、freightAmount等完整字段唯一可改且服务端强校验的请求必须抓此包实操技巧在 App 中点击“去结算”后立即在 Fiddler 中按CtrlR清空列表然后点击“提交订单”观察最后 2~3 条 POST 请求。重点筛选Content-Type: application/json且 Request Body 中含amount、price、fee、total等关键词的请求。右键 →Break on Request修改后再Run to Completion避免误改其他请求。3. 修改金额的 4 类核心字段及对应校验逻辑改哪里为什么改这里抓到真正的支付确认请求后不能盲目改amount字段。服务端校验是组合拳单点修改必然失败。以下按真实业务链路梳理必须同步调整的字段及其校验逻辑。3.1payAmount应付金额主校验字段但绝非唯一这是最直观的金额字段例如{ payAmount: 99.9, goodsAmount: 100.0, discountAmount: 0.1, freightAmount: 0.0 }表面看改payAmount即可但服务端必校验payAmount goodsAmount - discountAmount freightAmount数学一致性payAmount 0 payAmount goodsAmount * 1.2防负数、防超额若discountAmount 0还需校验优惠券 ID 是否有效、是否过期、是否限品类血泪经验曾有同事只改payAmount为0.01结果返回{code:40005,msg:优惠金额超出可用范围}。因为服务端发现discountAmount仍为0.1而0.01远低于goodsAmount - discountAmount触发风控规则。3.2sign或signature请求签名90% 失败的根源几乎所有正规电商系统都会对请求体做签名算法通常是sign MD5( JSON.stringify(sortedBody) secretKey ).toUpperCase()或更安全的HMAC-SHA256(sortedBodyString, secretKey)。Fiddler 修改请求体后原始sign值失效。若不重新计算服务端校验失败直接返回401 Unauthorized或403 Forbidden。关键点secretKey绝不会出现在请求中需逆向 App 获取常见位置so 库字符串、Java 层BuildConfig.API_KEY、JS Bundle 中硬编码排序规则必须严格匹配服务端如按 key 字典序升序忽略空格小写 key时间戳timestamp字段若存在必须同步更新误差超过 5 分钟视为无效。3.3orderSn或traceId订单唯一标识防重放攻击的隐形锁看似无关金额的字段实则关联风控。例如orderSn: ORD202405201530228877, traceId: a1b2c3d4e5f67890服务端会检查orderSn是否已存在防重复提交校验traceId是否在 5 分钟内被同一设备使用过防自动化脚本刷单若orderSn为时间戳生成修改金额后未同步更新orderSn可能导致orderSn早于当前时间被拒。3.4extInfo或bizData扩展数据藏在 Base64 里的校验密钥部分系统将关键校验参数加密后塞进extInfo字段例如extInfo: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJhbW91bnQiOjEwMC4wLCJjdXJyZW5jeSI6IlVTRCIsImRpc2NvdW50IjowLjF9.xYz...这是 JWT 结构解码后可能含{ amount: 100.0, currency: USD, discount: 0.1 }若只改外层payAmount不改 JWT 内部amount服务端解析 JWT 后比对两者不一致直接拦截。解密密钥需从 App 逆向获取常见于libcrypto.so或 JS 加密函数。4. 修改后必做的 3 项验证动作别急着点提交先看这三处改完字段、重算签名、更新时间戳后不要直接Run to Completion。必须人工验证三个关键点否则 100% 失败。4.1 在 Fiddler 中检查请求头完整性Content-Length和Host易被忽略修改 JSON Body 后Fiddler不会自动更新Content-Length头。若原请求Content-Length: 128你新增字段使 Body 变为 142 字节但头仍是128服务端读取不全解析 JSON 失败返回400 Bad Request。正确做法在Inspectors → Headers标签页手动将Content-Length改为实际字节数右键 Body →Copy as Text→ 粘贴到文本编辑器 →CtrlA → CtrlShiftC查看字符数注意 UTF-8 编码下中文占 3 字节检查Host头是否与目标域名一致如Host: api.xxx.com某些网关会校验 Host 与 SNI 一致性确认User-Agent是否被服务端识别为合法客户端如xxxApp/5.2.0 (iPhone; iOS 16.4; Scale/3.00)若为Fiddler或空值可能被限流。4.2 用 Fiddler 的 AutoResponder 模拟服务端响应提前暴露校验点与其反复提交看错误码不如用 AutoResponder 拦截请求返回预设成功响应验证前端逻辑是否走通在 Fiddler 中选中目标请求 → 右键 →Add Rule to AutoResponder在Rules列表中双击该规则 →Unmatched requests passthrough取消勾选Action选择Respond with a file指向一个本地 JSON 文件内容为{ code: 0, msg: success, data: { payUrl: https://pay.xxx.com?orderORD123, orderId: ORD123 } }若前端能正常跳转到支付页说明金额修改和签名逻辑正确若卡在“正在提交”说明前端 JS 仍有校验如if (payAmount 1) alert(金额错误)需进一步 Hook 前端逻辑。4.3 对比原始请求与修改请求的二进制差异揪出隐藏字段肉眼对比 JSON 容易遗漏空格、换行、大小写。用 Fiddler 的Compare功能精准定位选中原始请求 →Right-click → Compare with → Select another session选中修改后的请求 → 点击Compare在弹出窗口中Fiddler 以红绿高亮显示所有差异包括不可见字符。重点关注timestamp是否更新毫秒级sign字段是否全量重算长度、字符集是否匹配extInfo是否 Base64 编码后长度变化暗示内部 JSON 被修改是否意外删掉了version、channel等非金额字段某些系统校验全字段存在性。5. 修改金额失败的 5 类高频避坑指南每一条都来自真实翻车现场5.1 现象改完payAmount提交返回{code:40001,msg:参数错误}原因服务端校验payAmount必须为两位小数你填了99.9实际是99.90但 JSON 序列化后丢失末尾零变成99.9。服务端解析为浮点数99.9与期望的BigDecimal(99.90)不等。解决强制格式化为字符串payAmount: 99.90或使用toFixed(2)保证精度。5.2 现象签名重算后返回{code:40003,msg:签名错误}原因JSON 序列化时字段顺序与服务端不一致。例如你按{a:1,b:2}排序但服务端是{b:2,a:1}导致MD5值不同。解决用 Python 脚本模拟服务端排序逻辑import json, hashlib body {payAmount:99.90,goodsAmount:100.0,discountAmount:0.1} # 服务端排序规则key 小写字典序升序 sorted_body {k: body[k] for k in sorted(body.keys(), keystr.lower)} json_str json.dumps(sorted_body, separators(,, :), ensure_asciiFalse) sign hashlib.md5((json_str your_secret_key).encode()).hexdigest().upper() print(sign) # 确保与服务端一致5.3 现象手机抓包成功但 PC 端浏览器访问同一接口改金额却 403原因PC 浏览器请求头含Origin: https://www.xxx.com服务端校验跨域来源而手机 App 请求无Origin头或为null。解决在 Fiddler 中删除Origin头或将其改为与 App 一致的值如Origin: null或添加Referer: https://www.xxx.com/。5.4 现象改金额后能提交但支付时提示“订单金额异常请联系客服”原因支付通道如微信/支付宝在回调时会校验total_fee参数该参数由服务端生成与你修改的payAmount不一致。服务端未同步更新支付通道参数。解决此问题无法通过 Fiddler 解决需确认该场景是否允许前端控制金额。若为真实支付此行为本身违反支付规范仅限测试环境验证业务逻辑。5.5 现象Fiddler 显示请求成功200但 App 界面卡在“支付中”无后续响应原因App 前端监听的是 WebSocket 或长轮询响应而非 HTTP 请求结果。你修改的只是初始提交请求后续状态查询请求如/api/order/status?snORD123仍携带原始金额服务端比对不一致返回status: failed。解决在 Fiddler 中开启Filters → Show only the following hosts输入目标域名抓取后续所有请求找到状态查询接口同步修改其响应体中的金额字段或用 AutoResponder 固定返回status: success。6. 进阶技巧用 Fiddler Script 自动化签名重算与字段注入手动改字段、算签名、调Content-Length效率极低且易出错。Fiddler 内置 JScript.NET 脚本引擎可实现自动化。以下是一个生产环境验证过的OnBeforeRequest脚本片段专用于电商支付请求改造// Fiddler CustomRules.js - 放在 Fiddler 安装目录 \Scripts\CustomRules.js static function OnBeforeRequest(oSession: Session) { // 仅处理目标下单接口 if (oSession.hostname api.xxx.com oSession.uriContains(/api/order/confirm)) { // 1. 解析原始 JSON Body var body oSession.GetRequestBodyAsString(); var obj JSON.parse(body); // 2. 修改金额此处可接入外部配置 obj.payAmount 0.01; obj.goodsAmount 0.01; obj.discountAmount 0.0; // 3. 重算签名按服务端规则小写 key 排序 secret var sortedKeys Object.keys(obj).sort(function(a,b){return a.toLowerCase().localeCompare(b.toLowerCase());}); var sortedStr {; for (var i0; isortedKeys.length; i) { var k sortedKeys[i]; var v obj[k]; if (typeof v string) v v ; else v v.toString(); sortedStr k : v (i sortedKeys.length-1 ? , : ); } sortedStr }; var secret your_production_secret_key; var sign System.Security.Cryptography.MD5.Create().ComputeHash( System.Text.Encoding.UTF8.GetBytes(sortedStr secret) ); obj.sign System.BitConverter.ToString(sign).Replace(-, ).toLowerCase(); // 4. 更新 Body 和 Content-Length var newBody JSON.stringify(obj); oSession.utilSetResponseBody(newBody); oSession.oRequest.headers.HTTPResponse[Content-Length] newBody.length.toString(); // 5. 强制更新 Host 头防网关校验 oSession.oRequest.headers.HTTPRequest[Host] api.xxx.com; } }部署步骤打开 Fiddler →Rules → Customize Rules在OnBeforeRequest函数内粘贴上述代码修改hostname、uriContains、secret为实际值CtrlS保存Fiddler 自动编译底部状态栏提示CustomRules.js compiled successfully重启 Fiddler后续所有匹配请求自动完成改金额重签名。我的习惯从不依赖网上下载的“完整版工具.rar”因为其中的签名算法、secret、字段名都是硬编码换一个 App 全部失效。我坚持每次新项目都用 Frida Hook 出 App 的签名函数再用 Fiddler Script 复现逻辑——虽然多花 2 小时但换来的是 100% 可复用、可调试、可审计的修改流程。希望帮到你。本文还有配套的精品资源点击获取 Fiddler改金额失败原因与绕过签名校验实战指南
简介本资源是一套面向网络安全初学者与渗透测试爱好者的Fiddler抓包实战教学包聚焦于移动端购物场景下的HTTP请求拦截与金额参数篡改实践帮助学习者理解Web通信原理及常见安全漏洞利用方式。压缩包共52个文件包含13个可执行工具exe、12个动态链接库dll支撑Fiddler插件运行、14个数据缓存文件dat记录抓包会话、4个音频提示wav辅助操作反馈以及教程文档txt、配置文件config、图标ico、JS脚本和PNG示意图等整体体积10.62MB结构完整、即开即用。已有9963人学习下载资源提供视频讲解图文文档实操工具三位一体内容涵盖夜神模拟器环境搭建、Fiddler2基础配置、商品价格字段定位与修改、支付请求重放验证等关键环节并附带发货图示与常见问题说明适合零基础入门并快速上手抓包调试。1. 为什么改金额总在 Fiddler 里卡住不是抓不到包而是改完就 400/500/签名失败/跳转登录页你下载了「完整版 fiddler抓包修改金额教程工具.rar」解压打开照着文档点开 Fiddler、勾上Decrypt HTTPS traffic、装证书、手机配代理——结果一提交订单金额刚改完接口直接返回{code:40012,msg:非法请求}或者干脆跳回登录页甚至 App 直接闪退。这不是你操作错了也不是 Fiddler 不行而是绝大多数“改金额”场景根本不是单纯改个 JSON 字段就能过验的。这个标题里的“完整版”真正值钱的不是那几个按钮截图和基础配置而是它背后隐含的三重校验逻辑服务端金额二次校验、请求体签名防篡改、支付通道级风控拦截。Fiddler 是把手术刀但没搞清病灶在哪就下刀只会让系统报错更狠。本篇不讲怎么点开 Fiddler只讲清楚什么时候能安全改金额、改哪几处才真正生效、哪些字段改了等于白改、以及为什么你改完立刻被干掉——全部基于真实电商、虚拟商品、小程序下单链路的逆向经验。适合已会基础抓包、但总在“改完提交就失败”环节反复碰壁的测试工程师、安全初学者和想验证业务逻辑边界的开发同学。2. 抓包前必须确认的 3 层前置条件绕过 SSL Pinning、处理证书信任、识别真实请求入口Fiddler 能否成功捕获目标请求不取决于你是否勾选了Decrypt HTTPS traffic而取决于目标 App 是否做了 SSL Pinning证书固定、系统是否信任 Fiddler 根证书、以及你是否抓到了真正承载金额参数的请求。这三步缺一不可且顺序不能乱。下面按实战顺序拆解。2.1 确认目标 App 是否启用 SSL Pinning先看现象再决定对策SSL Pinning 是 App 主动校验服务器证书指纹或公钥绕过系统证书信任链。一旦启用Fiddler 的中间人代理就会被直接拒绝表现为手机配好 Fiddler 代理后App 启动即崩溃或网络异常Fiddler 中看不到任何该 App 的 HTTPS 请求只有 CONNECT 隧道建立失败日志Wireshark 抓到 TLS 握手阶段Alert: fatal: unknown_ca。提示不要一上来就尝试安装 Fiddler 证书。先用adb logcat | grep -i ssl或 iOS 的 Console.app 查看 App 启动日志搜索TrustManager、pin、cert、X509等关键词。若出现javax.net.ssl.SSLHandshakeException或CertificatePinning相关堆栈基本可判定启用了 Pinning。常见应对路径按侵入性由低到高方案 A推荐使用 Frida Hook 绕过 Pinning需 root/jailbreak。执行frida -U -f com.xxx.app -l ssl-pinning-bypass.js --no-pause脚本核心是重写OkHttpClient或TrustManager的checkServerTrusted方法使其始终返回 true。方案 B改用支持自动绕过的抓包工具如 HttpCanary for Android无需 root 即可 Hook SSL但注意其证书机制与 Fiddler 冲突二者不可共存。方案 C仅限调试反编译 APK定位NetworkSecurityConfig或TrustManagerImpl调用点临时注释 Pinning 逻辑后重打包——此法仅适用于自研 App 或测试环境生产环境严禁。2.2 在设备端正确安装并信任 Fiddler 根证书Fiddler 默认生成的根证书DO_NOT_TRUST_FiddlerRoot必须被设备系统级信任否则 HTTPS 解密失败。关键细节常被忽略Android 7API 24系统默认不信任用户安装证书。必须在AndroidManifest.xml中添加android:networkSecurityConfigxml/network_security_config并在res/xml/network_security_config.xml中显式声明trust-anchors包含user类型证书。否则即使证书已安装App 仍走系统证书链Fiddler 无法解密。iOS 10.3证书安装后需进入设置 → 已下载描述文件 → 安装 → 设置 → 通用 → 关于本机 → 证书信任设置手动开启对DO_NOT_TRUST_FiddlerRoot的完全信任。缺这一步Safari 可抓但多数 App尤其 WebView 内嵌仍失败。Windows/macOS 桌面端浏览器需单独导入证书到“受信任的根证书颁发机构”。Chrome 基于系统证书库Edge 同理Firefox 使用独立证书库需在about:preferences#privacy → 证书 → 查看证书 → 证书机构 → 导入。验证是否生效在 Fiddler 中发起一个 HTTPS 请求如https://httpbin.org/get观察Inspectors → TextView是否显示明文响应体。若仍为乱码或显示Tunnel to...说明证书未生效。2.3 定位真正携带金额参数的请求别在登录页或首页瞎抓“修改金额”不是改任意一个带price字段的请求而是必须找到下单流程中最后一个、且服务端未做前端脱敏的支付确认请求。典型路径如下请求阶段常见 URL 特征是否含真实金额备注商品详情页/api/item/detail?id123❌通常返回originalPrice和currentPrice但非下单价前端可能二次计算优惠实际下单价以结算页为准购物车页/api/cart/list❌返回各商品单价但未聚合运费/优惠券金额未最终确定服务端不校验结算页预检/api/order/precheck?skuIds1,2⚠️可能返回totalAmount但仅为预估无签名此请求常被忽略却是关键校验入口支付确认提交/api/order/confirm或/api/pay/submit✅含payAmount、discountAmount、freightAmount等完整字段唯一可改且服务端强校验的请求必须抓此包实操技巧在 App 中点击“去结算”后立即在 Fiddler 中按CtrlR清空列表然后点击“提交订单”观察最后 2~3 条 POST 请求。重点筛选Content-Type: application/json且 Request Body 中含amount、price、fee、total等关键词的请求。右键 →Break on Request修改后再Run to Completion避免误改其他请求。3. 修改金额的 4 类核心字段及对应校验逻辑改哪里为什么改这里抓到真正的支付确认请求后不能盲目改amount字段。服务端校验是组合拳单点修改必然失败。以下按真实业务链路梳理必须同步调整的字段及其校验逻辑。3.1payAmount应付金额主校验字段但绝非唯一这是最直观的金额字段例如{ payAmount: 99.9, goodsAmount: 100.0, discountAmount: 0.1, freightAmount: 0.0 }表面看改payAmount即可但服务端必校验payAmount goodsAmount - discountAmount freightAmount数学一致性payAmount 0 payAmount goodsAmount * 1.2防负数、防超额若discountAmount 0还需校验优惠券 ID 是否有效、是否过期、是否限品类血泪经验曾有同事只改payAmount为0.01结果返回{code:40005,msg:优惠金额超出可用范围}。因为服务端发现discountAmount仍为0.1而0.01远低于goodsAmount - discountAmount触发风控规则。3.2sign或signature请求签名90% 失败的根源几乎所有正规电商系统都会对请求体做签名算法通常是sign MD5( JSON.stringify(sortedBody) secretKey ).toUpperCase()或更安全的HMAC-SHA256(sortedBodyString, secretKey)。Fiddler 修改请求体后原始sign值失效。若不重新计算服务端校验失败直接返回401 Unauthorized或403 Forbidden。关键点secretKey绝不会出现在请求中需逆向 App 获取常见位置so 库字符串、Java 层BuildConfig.API_KEY、JS Bundle 中硬编码排序规则必须严格匹配服务端如按 key 字典序升序忽略空格小写 key时间戳timestamp字段若存在必须同步更新误差超过 5 分钟视为无效。3.3orderSn或traceId订单唯一标识防重放攻击的隐形锁看似无关金额的字段实则关联风控。例如orderSn: ORD202405201530228877, traceId: a1b2c3d4e5f67890服务端会检查orderSn是否已存在防重复提交校验traceId是否在 5 分钟内被同一设备使用过防自动化脚本刷单若orderSn为时间戳生成修改金额后未同步更新orderSn可能导致orderSn早于当前时间被拒。3.4extInfo或bizData扩展数据藏在 Base64 里的校验密钥部分系统将关键校验参数加密后塞进extInfo字段例如extInfo: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJhbW91bnQiOjEwMC4wLCJjdXJyZW5jeSI6IlVTRCIsImRpc2NvdW50IjowLjF9.xYz...这是 JWT 结构解码后可能含{ amount: 100.0, currency: USD, discount: 0.1 }若只改外层payAmount不改 JWT 内部amount服务端解析 JWT 后比对两者不一致直接拦截。解密密钥需从 App 逆向获取常见于libcrypto.so或 JS 加密函数。4. 修改后必做的 3 项验证动作别急着点提交先看这三处改完字段、重算签名、更新时间戳后不要直接Run to Completion。必须人工验证三个关键点否则 100% 失败。4.1 在 Fiddler 中检查请求头完整性Content-Length和Host易被忽略修改 JSON Body 后Fiddler不会自动更新Content-Length头。若原请求Content-Length: 128你新增字段使 Body 变为 142 字节但头仍是128服务端读取不全解析 JSON 失败返回400 Bad Request。正确做法在Inspectors → Headers标签页手动将Content-Length改为实际字节数右键 Body →Copy as Text→ 粘贴到文本编辑器 →CtrlA → CtrlShiftC查看字符数注意 UTF-8 编码下中文占 3 字节检查Host头是否与目标域名一致如Host: api.xxx.com某些网关会校验 Host 与 SNI 一致性确认User-Agent是否被服务端识别为合法客户端如xxxApp/5.2.0 (iPhone; iOS 16.4; Scale/3.00)若为Fiddler或空值可能被限流。4.2 用 Fiddler 的 AutoResponder 模拟服务端响应提前暴露校验点与其反复提交看错误码不如用 AutoResponder 拦截请求返回预设成功响应验证前端逻辑是否走通在 Fiddler 中选中目标请求 → 右键 →Add Rule to AutoResponder在Rules列表中双击该规则 →Unmatched requests passthrough取消勾选Action选择Respond with a file指向一个本地 JSON 文件内容为{ code: 0, msg: success, data: { payUrl: https://pay.xxx.com?orderORD123, orderId: ORD123 } }若前端能正常跳转到支付页说明金额修改和签名逻辑正确若卡在“正在提交”说明前端 JS 仍有校验如if (payAmount 1) alert(金额错误)需进一步 Hook 前端逻辑。4.3 对比原始请求与修改请求的二进制差异揪出隐藏字段肉眼对比 JSON 容易遗漏空格、换行、大小写。用 Fiddler 的Compare功能精准定位选中原始请求 →Right-click → Compare with → Select another session选中修改后的请求 → 点击Compare在弹出窗口中Fiddler 以红绿高亮显示所有差异包括不可见字符。重点关注timestamp是否更新毫秒级sign字段是否全量重算长度、字符集是否匹配extInfo是否 Base64 编码后长度变化暗示内部 JSON 被修改是否意外删掉了version、channel等非金额字段某些系统校验全字段存在性。5. 修改金额失败的 5 类高频避坑指南每一条都来自真实翻车现场5.1 现象改完payAmount提交返回{code:40001,msg:参数错误}原因服务端校验payAmount必须为两位小数你填了99.9实际是99.90但 JSON 序列化后丢失末尾零变成99.9。服务端解析为浮点数99.9与期望的BigDecimal(99.90)不等。解决强制格式化为字符串payAmount: 99.90或使用toFixed(2)保证精度。5.2 现象签名重算后返回{code:40003,msg:签名错误}原因JSON 序列化时字段顺序与服务端不一致。例如你按{a:1,b:2}排序但服务端是{b:2,a:1}导致MD5值不同。解决用 Python 脚本模拟服务端排序逻辑import json, hashlib body {payAmount:99.90,goodsAmount:100.0,discountAmount:0.1} # 服务端排序规则key 小写字典序升序 sorted_body {k: body[k] for k in sorted(body.keys(), keystr.lower)} json_str json.dumps(sorted_body, separators(,, :), ensure_asciiFalse) sign hashlib.md5((json_str your_secret_key).encode()).hexdigest().upper() print(sign) # 确保与服务端一致5.3 现象手机抓包成功但 PC 端浏览器访问同一接口改金额却 403原因PC 浏览器请求头含Origin: https://www.xxx.com服务端校验跨域来源而手机 App 请求无Origin头或为null。解决在 Fiddler 中删除Origin头或将其改为与 App 一致的值如Origin: null或添加Referer: https://www.xxx.com/。5.4 现象改金额后能提交但支付时提示“订单金额异常请联系客服”原因支付通道如微信/支付宝在回调时会校验total_fee参数该参数由服务端生成与你修改的payAmount不一致。服务端未同步更新支付通道参数。解决此问题无法通过 Fiddler 解决需确认该场景是否允许前端控制金额。若为真实支付此行为本身违反支付规范仅限测试环境验证业务逻辑。5.5 现象Fiddler 显示请求成功200但 App 界面卡在“支付中”无后续响应原因App 前端监听的是 WebSocket 或长轮询响应而非 HTTP 请求结果。你修改的只是初始提交请求后续状态查询请求如/api/order/status?snORD123仍携带原始金额服务端比对不一致返回status: failed。解决在 Fiddler 中开启Filters → Show only the following hosts输入目标域名抓取后续所有请求找到状态查询接口同步修改其响应体中的金额字段或用 AutoResponder 固定返回status: success。6. 进阶技巧用 Fiddler Script 自动化签名重算与字段注入手动改字段、算签名、调Content-Length效率极低且易出错。Fiddler 内置 JScript.NET 脚本引擎可实现自动化。以下是一个生产环境验证过的OnBeforeRequest脚本片段专用于电商支付请求改造// Fiddler CustomRules.js - 放在 Fiddler 安装目录 \Scripts\CustomRules.js static function OnBeforeRequest(oSession: Session) { // 仅处理目标下单接口 if (oSession.hostname api.xxx.com oSession.uriContains(/api/order/confirm)) { // 1. 解析原始 JSON Body var body oSession.GetRequestBodyAsString(); var obj JSON.parse(body); // 2. 修改金额此处可接入外部配置 obj.payAmount 0.01; obj.goodsAmount 0.01; obj.discountAmount 0.0; // 3. 重算签名按服务端规则小写 key 排序 secret var sortedKeys Object.keys(obj).sort(function(a,b){return a.toLowerCase().localeCompare(b.toLowerCase());}); var sortedStr {; for (var i0; isortedKeys.length; i) { var k sortedKeys[i]; var v obj[k]; if (typeof v string) v v ; else v v.toString(); sortedStr k : v (i sortedKeys.length-1 ? , : ); } sortedStr }; var secret your_production_secret_key; var sign System.Security.Cryptography.MD5.Create().ComputeHash( System.Text.Encoding.UTF8.GetBytes(sortedStr secret) ); obj.sign System.BitConverter.ToString(sign).Replace(-, ).toLowerCase(); // 4. 更新 Body 和 Content-Length var newBody JSON.stringify(obj); oSession.utilSetResponseBody(newBody); oSession.oRequest.headers.HTTPResponse[Content-Length] newBody.length.toString(); // 5. 强制更新 Host 头防网关校验 oSession.oRequest.headers.HTTPRequest[Host] api.xxx.com; } }部署步骤打开 Fiddler →Rules → Customize Rules在OnBeforeRequest函数内粘贴上述代码修改hostname、uriContains、secret为实际值CtrlS保存Fiddler 自动编译底部状态栏提示CustomRules.js compiled successfully重启 Fiddler后续所有匹配请求自动完成改金额重签名。我的习惯从不依赖网上下载的“完整版工具.rar”因为其中的签名算法、secret、字段名都是硬编码换一个 App 全部失效。我坚持每次新项目都用 Frida Hook 出 App 的签名函数再用 Fiddler Script 复现逻辑——虽然多花 2 小时但换来的是 100% 可复用、可调试、可审计的修改流程。希望帮到你。本文还有配套的精品资源点击获取