简介：这份资源面向希望了解移动端抓包与请求篡改原理的学习者，围绕 Fiddler 抓包工具在购物支付场景中的应用展开，通过视频演示与配套文档讲解如何借助抓包工具观察并修改商品价格相关请求，帮助读者理解 HTTP/HTTPS 抓包分析的基本流程与常见调试思路，适合具备一定网络基础、想入门抓包调试的开发者与安全爱好者参考。压缩包共 52 个文件，约 10.62MB，包含 exe 工具与模拟器安装程序、dll 运行库、dat 数据文件、wav 音频、txt 说明文档及 config 配置、ico 图标、js 脚本等，工具、教程与素材相对齐全，解压后可按说明逐步对照操作。目前已有 9966 人学习下载，热度较高。资源提供视频教程与文字说明相结合的形式，便于读者边看边练，快速建立对抓包工具配置、请求拦截与参数修改的整体认识，并积累实际调试中的排错经验。

1. 抓包改价这件事，先看清工具边界再动手

电商结算页面上那个数字，从 199 变成 1.99，中间隔着的不是一行代码，而是一整套请求链路。Fiddler 这类 HTTP 调试代理干的活，就是把客户端和服务端之间的明文流量摊开给你看，看懂了才有资格谈修改。这份资源包的核心价值不在于「改金额」这个噱头，而在于它把 Fiddler 的证书配置、断点拦截、会话篡改、重放验证串成了一条能跑通的链路，适合已经会装软件但卡在「抓不到包」「改了没生效」「HTTPS 一片红」这三道坎上的移动端和后端联调人员。需要先把话说死：改价只在你自己搭建的测试环境或明确授权的靶场里有意义，真实业务系统里篡改交易金额属于违法行为，工具无罪，用错地方就是另一回事了。下面按「装好能抓 → 抓到能改 → 改完能验 → 验完知道哪里会翻车」的顺序拆。

2. Fiddler 抓包链路搭建：从证书到 HTTPS 解密

2.1 为什么 HTTPS 抓不到包，根子在证书信任链

Fiddler 的工作模型是中间人代理：客户端以为自己在跟服务器握手，实际上握手对象是 Fiddler，Fiddler 再用自己的证书跟真实服务器建连。HTTP 流量天然明文，装上就能看；HTTPS 流量要解密，就必须让客户端信任 Fiddler 自签的根证书，否则客户端会直接拒绝握手，你在会话列表里只能看到一串 CONNECT 隧道，状态码 200 但内容全是加密的二进制。

常见翻车现场是 PC 端浏览器能抓、手机 App 抓不到，原因几乎都出在证书没装进系统信任区。Android 7 以后，用户证书默认不被 App 信任，只有系统证书才生效，这是很多人卡住的第一道墙。iOS 相对简单，装完描述文件还要去「关于本机 → 证书信任设置」里手动打开开关，少这一步等于没装。

2.2 PC 端配置：端口、解密开关、证书导出

先确认 Fiddler 的监听端口和允许远程连接。默认 8888，只监听本机，手机要连必须放开。

# Fiddler 菜单路径（不是命令行，这里用注释标出操作位置） # Tools -> Options -> Connections # Fiddler listens on port: 8888 # Allow remote computers to connect: 勾选 # 改完必须重启 Fiddler 才生效

端口选 8888 是惯例，冲突了换成 8899 也行，但后面手机代理要同步改。勾选「Allow remote computers to connect」之后，Fiddler 会弹一次防火墙授权，必须点允许，否则手机连过来会被系统防火墙静默丢弃，表现为手机设置完代理后所有请求超时。

接着开 HTTPS 解密：Tools → Options → HTTPS，勾选「Capture HTTPS CONNECTs」和「Decrypt HTTPS traffic」，弹窗问是否信任根证书时点 Yes。这一步会在系统证书存储里写入 Fiddler 的根证书，PC 端浏览器从此能正常解密。

导出证书给手机用：Actions → Export Root Certificate to Desktop，得到一个.cer文件。这个文件就是后面手机端要装的信任凭证，别搞丢。

2.3 手机端代理与证书安装：Android 与 iOS 的差异

手机和电脑必须在同一局域网。查电脑内网 IP：

# Windows ipconfig | findstr IPv4 # macOS / Linux ifconfig | grep "inet "

拿到类似192.168.1.23的地址后，手机 Wi-Fi 设置里把代理改成手动，主机名填这个 IP，端口填 8888。改完打开浏览器访问任意 HTTP 站点，Fiddler 会话列表应该开始刷记录，说明链路通了。

证书安装分平台：

Android 高版本的坑后面单独讲，这里先记住：用户证书装完，浏览器能抓，但目标 App 大概率还是加密的。

2.4 验证链路：用一条明文请求确认代理生效

别急着抓目标 App，先用一个简单的 HTTP 接口验证整条链路。手机浏览器访问http://httpbin.org/get，Fiddler 里应该出现一条完整请求，右侧 Inspectors 能看到请求头和响应体。

# 如果手边有 curl，也可以在电脑上验证代理是否工作 curl -x 127.0.0.1:8888 http://httpbin.org/get -v # -x 指定代理地址，-v 打印握手细节 # 输出里出现 "Connected to 127.0.0.1" 且返回 JSON 即代理正常

-x参数指定代理，-v打开详细日志，能看到 CONNECT 和 GET 的完整往返。这一步过了，说明 Fiddler 本身没问题，后面抓不到就是目标 App 的证书校验或双向认证在拦。

3. 断点拦截与金额篡改：会话编辑的三种手法

3.1 全局断点 vs 单条会话断点，选哪个

Fiddler 改请求有两条路：全局断点（Rules → Automatic Breakpoints → Before Requests）会在每个请求发出前暂停，适合摸清一个页面到底发了哪些接口；单条会话断点是在会话列表里右键某条请求 → Break on Request，只拦这一条，适合已经定位到目标接口后的精确修改。

新手常犯的错是一上来开全局断点，结果页面加载几十个请求全部卡住，Fiddler 里一片红色暂停图标，不知道该放行哪个。正确顺序是：先不开断点，正常操作一遍结算流程，在会话列表里按 URL 关键词过滤出疑似改价的接口，再对那一条下断点。

过滤技巧：会话列表上方有 Filter 输入框，输入price、amount、total、order这类关键词，能快速缩小范围。金额字段在请求体里的命名五花八门，常见的有price、amount、payAmount、totalFee、goodsPrice，响应体里则常见finalPrice、actualAmount。

3.2 请求体篡改：JSON 字段定位与替换

定位到目标请求后，右侧 Inspectors → TextView 或 WebForms 能看到请求体。JSON 格式的请求体直接改字段值即可。

{ "goodsId": "10086", "quantity": 1, "price": 199.00, "couponId": "", "payChannel": "balance" }

把price从199.00改成1.99，点右侧绿色的 Run to Completion 放行。这里有个关键认知：客户端提交的价格只是「声称」，服务端是否采信取决于它有没有做二次校验。绝大多数正规系统会在服务端根据 goodsId 重新查价，客户端传的 price 只用于展示比对，改了也不影响实际扣款——这正是这类教程在真实系统里失效的根本原因，也是它只能在靶场里演示的原因。

如果请求体是表单格式（Content-Type: application/x-www-form-urlencoded），在 WebForms 视图里直接改对应字段的值，效果一样。

3.3 响应体篡改：改返回值骗过前端展示

请求改不动的时候，换个思路改响应。比如服务端返回的订单详情里带payAmount，前端拿这个字段渲染支付按钮上的数字，那就在 Response 断点里把它改小。

{ "orderId": "ORD20240101001", "status": "UNPAID", "payAmount": 199.00, "currency": "CNY" }

把payAmount改成1.99，前端页面刷新后按钮显示 1.99。但要注意：这只改了「显示」，真正发起支付时前端通常会再请求一次支付接口，那个接口返回的金额才是最终扣款依据。所以响应篡改只能验证前端有没有对金额做二次确认，不能真正改变交易结果。

3.4 自动响应与重放：把修改固化成规则

手动改一次不过瘾，Fiddler 支持 AutoResponder 把某个请求的响应固定成本地文件。操作：会话列表右键目标请求 → Save → Response → Response Body，存成文件；再到 AutoResponder 标签页，勾选 Enable rules，把该请求拖进去，指定刚存的响应文件。之后每次命中这个 URL，都返回你改过的内容。

# AutoResponder 规则示例（界面操作，此处示意匹配逻辑） # 匹配规则：EXACT:https://api.example.com/order/detail # 响应动作：选择本地文件 order_detail_modified.json # 勾选 "Unmatched requests passthrough" 让其他请求正常走网络

EXACT:前缀表示精确匹配 URL，也可以用REGEX:做正则匹配。最后那个 passthrough 选项一定要勾，否则所有没匹配上的请求都会被 Fiddler 拦下返回 404，页面直接白屏。

重放则是选中一条历史会话，右键 Replay → Reissue Requests，Fiddler 会原样再发一次。改完参数后重放，能快速验证服务端对不同金额的处理逻辑，不用每次从头走一遍页面流程。

4. 抓不到、改不动的排查清单

4.1 现象：手机连上代理后所有请求超时

原因通常是电脑防火墙拦了 8888 端口，或者手机和电脑不在同一网段（比如一个连 5G 一个连 Wi-Fi）。解决：Windows 防火墙入站规则里给 Fiddler 放行，或者临时关掉防火墙验证；确认两边 IP 前三段一致，用ping测一下通不通。

4.2 现象：HTTPS 请求全是 CONNECT 隧道，看不到明文

证书没装或没被信任。Android 先确认证书装进了「用户」还是「系统」；iOS 确认「证书信任设置」开关打开了。还有一个隐蔽原因：Fiddler 的 HTTPS 解密开关被关了，Tools → Options → HTTPS 里重新勾选即可。

4.3 现象：浏览器能抓，目标 App 抓不到

Android 7 以上的 App 默认只信任系统证书，用户证书对它无效。常见做法是把 Fiddler 根证书装进系统证书区（需要 root 或改包），或者在测试包上配置 network security config 允许用户证书。这一步涉及改包，只在自有测试包上做，别碰别人的应用。

4.4 现象：改了金额，支付页面还是原价

服务端做了二次校验，客户端传的价格不被采信。这不是工具问题，是设计如此。验证方法：看支付接口的请求体里金额字段是不是服务端下发的，如果是，改客户端请求无效；如果支付接口压根不带金额字段，说明金额完全由服务端决定，客户端改什么都白搭。

4.5 现象：AutoResponder 开了之后页面白屏

没勾「Unmatched requests passthrough」，所有未匹配请求被拦截。勾上即可。另外规则里的 URL 要跟实际请求完全一致，带 query 参数的要把参数也写进去，否则匹配不上。

5. 从改价到接口契约验证：把工具用回正途

改金额这个动作本身价值有限，真正值得带走的是它背后的验证思路：一个接口到底信任客户端到什么程度。我一般会把 Fiddler 当成接口契约的探针来用，具体做法是固定一套「篡改矩阵」，对每个涉及金额、数量、优惠券的接口跑一遍，看服务端哪些字段采信、哪些字段重算。

跑完这张表，哪些接口是「客户端说了算」一目了然。这套方法在自有系统上线前的安全自测里很实用，比看代码猜信任边界快得多。

还有一个容易被忽略的技巧：Fiddler 的会话可以导出成.saz文件，把整条链路的请求响应打包存档。排查线上问题时，让用户或测试同学导一份.saz发过来，比截图描述准确得多。导出路径 File → Save → All Sessions，打开时直接拖进 Fiddler 即可回放。

# .saz 本质是 zip，想看里面结构可以解压 unzip session.saz -d session_dump # 解压后 raw/ 目录下是按序号存的请求和响应原文 # 适合写脚本批量分析，比如统计某个接口的平均响应时间

unzip解出来的raw目录里，每个请求对应一组文件，请求头、请求体、响应头、响应体分开存放，写个 Python 脚本遍历统计就能做接口性能基线。这个用法比手动一条条看高效得多，也是我把 Fiddler 从「抓包玩具」变成日常工具的分水岭。

最后说句实在的：这类改价教程最大的坑不在技术，在于让人误以为线上系统也这么脆弱。我见过太多人拿着靶场的成功截图去推测真实系统，结果一测全是服务端重算。从那以后我每次拿到一个抓包改值的案例，都先问一句「服务端有没有二次校验」，没有这个前提，改出来的数字只是自嗨。希望帮到你。

本文还有配套的精品资源，点击获取