简介：这份资源面向对HTTP抓包与请求篡改感兴趣的安全初学者、测试人员及Web开发学习者，围绕Fiddler这一经典抓包工具，演示如何拦截并修改购物场景中的商品金额参数，从而理解客户端与服务器之间的数据交互过程与潜在风险。压缩包共收录52个文件，整体约10.62MB，以exe可执行程序、dll动态库和dat数据文件为主，辅以wav音频、txt说明、config配置、ico图标及js脚本等，涵盖工具运行、环境配置与操作演示所需的多类素材。目前已有9963人学习下载，热度较高。资源内含视频讲解与文档说明，并配套夜神模拟器、Fiddler2等工具，可帮助读者搭建抓包环境、观察请求参数、理解金额字段的修改逻辑与支付流程中的校验环节，适合作为抓包入门与请求篡改原理的实践参考。
1. 抓包改价这件事，到底在改什么
电商 App 里把 199 元的商品改成 0.01 元下单，这种视频你可能刷到过。多数人看完只记住一个结论：抓包能改金额。但真到自己动手，Fiddler 装完、证书配完、代理设完，请求列表刷出来一堆 HTTPS 流量，却不知道该点哪一条、改哪个字段、改完为什么服务端不认。这份《完整版 fiddler抓包修改金额教程+工具.rar》解决的正是这个断层——它把「抓包环境搭建 → 定位下单请求 → 篡改金额参数 → 观察服务端响应」这条链路完整串起来，配套工具省去到处找安装包的麻烦。适合做接口测试、安全学习、前后端联调的人，也适合想搞明白「客户端传什么、服务端信什么」的开发者。下面按我实际拆包的顺序讲，重点放在参数怎么改、为什么改完没效果、哪些坑必踩。
2. Fiddler 抓包环境搭建：证书、代理与 HTTPS 解密
2.1 为什么必须过 HTTPS 解密这一关
现在的 App 和网站几乎全走 HTTPS，Fiddler 默认只能看到 CONNECT 隧道，看不到明文请求体。要改金额，前提是能读到POST /order/create里的amount字段。Fiddler 的解密原理是中间人：它自己生成一张根证书，你把它装到系统或设备信任列表里，之后 Fiddler 用这张证书给每个 HTTPS 站点动态签一张子证书，浏览器/App 以为在跟服务器通信，实际是在跟 Fiddler 通信。这一步不过，后面全是盲抓。
常见做法是先在 PC 上装 Fiddler Classic，开启Tools → Options → HTTPS → Decrypt HTTPS traffic，勾选Ignore server certificate errors。然后导出根证书：Actions → Export Root Certificate to Desktop，得到FiddlerRoot.cer。PC 端直接双击安装到「受信任的根证书颁发机构」。手机端则要把代理指向 PC 的 IP 和 Fiddler 端口（默认 8888），再用手机浏览器访问http://<PC_IP>:8888下载证书安装。Android 7 以上系统证书和用户证书分离，很多 App 只信系统证书，这时候要么用模拟器（如某安卓模拟器）的 root 权限把证书塞进系统目录，要么用低版本 Android 真机。这是第一个大坑，后面避坑章会细说。
2.2 代理配置与抓包范围收窄
环境通了之后，Fiddler 会抓到海量请求，直接找金额字段等于大海捞针。我一般先做两件事收窄范围：
第一，用 Filters 过滤目标域名。在Filters标签勾选Use Filters，Hosts填*.target-domain.com，只留目标站点的流量。第二，抓包前先清空会话列表（Ctrl+X），然后在 App 里只做「加入购物车 → 结算 → 提交订单」这一条动作链，这样列表里新增的请求就是下单相关。
# 手机端设置代理的通用命令（以某安卓模拟器为例，adb 方式） adb shell settings put global http_proxy 192.168.1.100:8888 # 抓完后务必清除，否则手机会一直走代理导致断网 adb shell settings put global http_proxy :0上面两条命令是模拟器里改全局代理的常用方式，192.168.1.100换成你 PC 的局域网 IP，8888是 Fiddler 默认监听端口。注意http_proxy只对部分流量生效，有些 App 走自己的网络库会绕过系统代理，这时候需要在 Fiddler 里看有没有对应请求，没有就说明该 App 做了代理检测或用了证书绑定。
2.3 定位下单请求的关键字段
下单请求通常是POST，Content-Type多为application/json或application/x-www-form-urlencoded。在 Fiddler 左侧会话列表点开目标请求，右侧Inspectors → TextView看请求体。要找的字段名不一定是amount，常见变体有price、totalFee、payAmount、orderAmount、goodsPrice。有些系统传的是「分」为单位，199 元传19900，你改成1就是 0.01 元。还有的传商品 ID 和数量，金额由服务端算，这种客户端改金额无效，属于服务端校验到位的场景。
{ "goodsId": "10086", "quantity": 1, "amount": 19900, "couponId": "", "addressId": "2233" }上面是一个典型的下单请求体示例。amount字段就是客户端提交的金额，单位是分。改包时在 Fiddler 里用FiddlerScript或AutoResponder做替换，也可以直接右键请求Replay → Reissue and Edit手动改完再发。手动改适合单次验证，批量测试要用脚本。
3. 修改金额的三种实操路径与参数说明
3.1 手动 Reissue 改包：最快验证服务端是否校验
最直接的方式：在会话列表选中下单请求，右键Replay → Reissue and Edit，Fiddler 会弹出一个可编辑的请求窗口，把amount从19900改成1，点Run to Completion。然后看右侧Inspectors → TextView的响应。如果返回success且订单金额变成 0.01，说明服务端完全信任客户端传的金额，这是最严重的安全问题。如果返回「金额校验失败」「参数异常」「订单金额不一致」，说明服务端有二次校验，客户端改包无效。
这一步的价值不在于「薅羊毛」，而在于快速判断一个系统的金额校验是在前端还是后端。做接口测试时，这是必测项。参数上要注意：改完amount后，有些系统还会校验sign签名字段，签名是根据请求体算出来的，你改了金额但没重算签名，服务端验签直接失败。这种情况手动改包必失败，需要拿到签名算法或密钥才能构造合法请求，属于更高阶的测试范畴。
3.2 FiddlerScript 自动替换：批量与可复现
手动改几次就烦了，而且容易漏。FiddlerScript 可以在请求发出前自动替换指定字段，适合反复测试同一接口。打开Rules → Customize Rules，找到OnBeforeRequest函数，加入替换逻辑：
// FiddlerScript: 在请求发出前把 amount 字段替换为指定值 static function OnBeforeRequest(oSession: Session) { // 只处理目标下单接口 if (oSession.uriContains("/order/create") && oSession.HTTPMethodIs("POST")) { // 读取请求体 var body = oSession.GetRequestBodyAsString(); // 正则替换 amount 的值，19900 换成 1 body = body.replace(/"amount"\s*:\s*\d+/g, '"amount":1'); // 写回请求体 oSession.utilSetRequestBody(body); // 打印日志便于确认 FiddlerObject.log("amount replaced: " + body); } }这段脚本的逻辑是：拦截 URI 包含/order/create的 POST 请求，把请求体里"amount":数字的部分统一替换成"amount":1，然后写回。uriContains是模糊匹配，实际用的时候换成你抓到的真实路径。utilSetRequestBody会同时更新Content-Length，不用手动改长度。FiddlerObject.log输出到 Fiddler 的 Log 标签，方便确认替换是否生效。注意正则里的\d+只匹配整数，如果金额带小数要改成[\d.]+。另外如果请求体是 form 格式（amount=19900&...），正则要相应调整。
3.3 AutoResponder 伪造响应：验证前端展示逻辑
有时候你想看的不是服务端认不认，而是前端拿到不同金额后怎么展示。这时候用AutoResponder更合适：把下单请求的响应替换成你自己构造的 JSON，观察 App 页面变化。在 Fiddler 右侧AutoResponder标签，勾选Enable rules和Unmatched requests passthrough，添加一条规则，请求匹配下单接口，响应选Create New Response，填入：
{ "code": 0, "message": "success", "data": { "orderId": "TEST123456", "payAmount": 1, "status": "WAIT_PAY" } }这样 App 收到的就是伪造的成功响应，页面会跳到支付页显示 0.01 元。但注意，这只能骗前端展示，真正支付时支付网关会跟服务端核对订单金额，对不上照样失败。AutoResponder 的正确用途是前端联调时后端接口没准备好，或者测试前端对各种响应码的处理逻辑，不是用来「白嫖」的。参数上，code字段各系统定义不同，有的用0表示成功，有的用200，要按目标系统的实际约定来。
4. 避坑与排查：改包没效果时先看这五条
4.1 现象：Fiddler 里看不到目标 App 的任何请求
原因通常是三种：一是 App 走了非 HTTP 协议（如自定义 TCP 长连接、gRPC），Fiddler 抓不到；二是 App 做了代理检测，发现系统代理被设置就拒绝联网或走直连；三是 Android 7+ 的用户证书不被信任，HTTPS 握手直接失败，Fiddler 里只看到 CONNECT 没有后续。
解决：先确认 App 是否走 HTTP。用adb shell dumpsys或看 Fiddler 的 CONNECT 记录。如果是证书问题，把 Fiddler 根证书装到系统证书目录（需要 root），或用低版本 Android。代理检测的话，部分 App 可以通过 Fiddler 的Gateway模式或透明代理绕过，但操作复杂，一般测试环境直接用模拟器更省事。
4.2 现象：请求能抓到，但请求体是乱码或加密的
原因：App 对请求体做了加密（如 AES、RSA），Fiddler 看到的是密文。或者用了 protobuf 等二进制格式，TextView 显示乱码。
解决：加密的情况需要拿到密钥和算法，属于逆向范畴，不在抓包工具能解决的范围内。protobuf 的话，Fiddler 有插件可以解析，或者把请求体保存成二进制文件用protoc解码。如果只是学习抓包流程，换一个没有加密的 Demo 站点练手更实际。
4.3 现象：改了 amount 字段，服务端返回「签名错误」
原因：请求体里有一个sign或signature字段，是根据所有参数（含金额）按特定顺序拼接后做 MD5/HMAC 得到的。你改了金额没重算签名，服务端验签失败。
解决：需要知道签名算法。常见做法是抓一个正常请求，把参数按字母序排列，拼接上密钥做 MD5，对比sign值验证算法。拿到算法后，在 FiddlerScript 里改完金额后重新计算签名并替换。这一步是分水岭：能过签名校验，说明测试深度到位；过不了，说明系统有基本的防篡改机制。
4.4 现象：服务端返回成功，但支付时金额还是原价
原因：下单接口的金额只是「展示用」，真正扣款金额由支付网关根据订单号从服务端数据库读取。你改了下单请求的金额，订单表里存的还是原价，支付时以数据库为准。
解决：这种属于服务端校验到位的设计，客户端改包无法影响实际支付。测试结论应记录为「下单接口金额参数未做服务端校验，但支付环节有二次核对」，而不是「可以改价支付」。区分「展示篡改」和「实际篡改」是写测试报告的基本功。
4.5 现象：Fiddler 抓包正常，但手机连不上网了
原因：手机代理指向 PC 后，PC 的 Fiddler 没开或 IP 变了，流量转发不出去。或者抓完包忘了关代理。
解决：抓包结束后执行adb shell settings put global http_proxy :0清除代理。如果是真机，在 WiFi 设置里把代理改回「无」。养成习惯：抓包前设代理，抓完立刻清，否则第二天手机莫名其妙断网，排查半天才想起来是代理没关，这种血泪经验一次就够。
5. 从改金额到接口安全测试：一套可复用的验证习惯
改金额只是抓包改包的一个切面，真正有价值的是把这套流程抽象成接口安全测试的通用方法。我现在的习惯是，拿到任何一个有下单、支付、积分兑换功能的系统，先按下面这张表过一遍，基本能覆盖大部分客户端信任问题。
| 测试项 | 改什么字段 | 预期安全表现 | 常见缺陷 |
|---|---|---|---|
| 金额篡改 | amount / price / totalFee | 服务端拒绝或按数据库价 | 直接信任客户端金额 |
| 数量篡改 | quantity / num | 服务端校验库存与单价乘积 | 数量改负数或超大值 |
| 商品 ID 篡改 | goodsId / skuId | 服务端校验商品存在与上架状态 | 用低价商品 ID 买高价商品 |
| 优惠券重复使用 | couponId / couponCode | 服务端标记已使用 | 同一券多次提交 |
| 用户身份篡改 | userId / token | 服务端从会话取用户 | 客户端传 userId 直接信任 |
这张表的用法是：每测一项，用 FiddlerScript 做一次自动替换，观察响应。重点不是「能不能改成功」，而是「服务端在哪一层做了校验」。如果所有字段服务端都校验，说明这个系统在客户端信任问题上做得不错；如果金额能改成功，那就要看支付环节有没有兜底。
还有一个进阶技巧：用 Fiddler 的Breakpoints功能做请求拦截。在Rules → Automatic Breakpoints → Before Requests开启后，每个请求都会暂停，你可以逐个检查参数再决定放行还是修改。这比事后 Reissue 更接近「实时篡改」的场景，适合演示和深度测试。但注意，开启全局断点后请求量大会很卡，建议配合 Filters 只断目标域名。
最后说一个我踩过的坑：有次测试一个系统，改金额一直返回签名错误，我花了两个小时试图逆向签名算法，最后发现签名密钥就硬编码在 App 的某个 JS 文件里，用 Fiddler 抓静态资源时直接看到了。从那以后我每次遇到签名问题，都先翻一遍 App 加载的 JS 和配置文件，再考虑逆向。希望帮到你。
本文还有配套的精品资源，点击获取
