企业官网建设流程全解析

1. 为什么安卓App的代理检测越来越“反人类”

抓包总失败？这句话我听太多次了——不是Wireshark抓不到流量，就是Fiddler一开就闪退，Charles刚配好证书，App直接弹窗“检测到异常网络环境”，甚至有些App连启动页都过不去，直接白屏退出。关键词：安卓App、代理检测、抓包失败、HTTPS拦截、SSL Pinning、网络环境校验。这不是你工具用得不对，也不是手机没root，而是你正面对一套越来越成熟的客户端防御体系：它不拦HTTP，专杀HTTPS；不防Wi-Fi，专查代理；不靠服务器端，全在App本地跑。

我做过近30个主流金融、电商、社交类App的逆向分析，发现2023年之后上架的新版本中，92%以上都集成了至少两种代理检测机制，其中76%同时启用SSL Pinning + 代理IP特征扫描，41%还叠加了系统代理设置API调用痕迹检测。这不是“加个证书就能过”的年代了。很多同行还在反复重装CA证书、换端口、关防火墙，结果越折腾越迷糊——因为问题根本不在你的电脑或代理工具，而在App启动时那几毫秒内完成的十几项本地校验。

这类检测的核心逻辑其实很朴素：App把自己当成一个“安全哨兵”，在联网前先扫一遍“周围有没有可疑人员”。它会检查系统是否启用了全局代理（哪怕你只在Chrome里开了），会读取当前WiFi网关的IP是否匹配常见代理工具默认网关（比如127.0.0.1:8080、192.168.1.100:8888），会比对TLS握手阶段服务端返回的证书链是否被中间人篡改，更狠的是，它还会调用ConnectivityManager.getActiveNetworkInfo()和ProxyInfo.getProxyHost()这类系统API，直接读取Android框架层记录的代理配置。一旦任一条件命中，立刻触发降级策略：跳过关键接口、返回空数据、弹窗警告，甚至直接System.exit(0)强制杀进程。

所以，“抓包失败”从来不是技术故障，而是一场客户端与调试者之间的实时博弈。你开代理，它查代理；你换证书，它验证书；你绕过一层，它补上三层。这篇文章不讲“怎么装Fiddler”，而是带你拆解这堵墙是怎么砌起来的、每块砖在哪、哪块砖敲下去最省力、哪块砖后面藏着后门。接下来四章，我会从检测原理、绕过路径、实操步骤、避坑细节四个维度，把这套机制掰开揉碎——你不需要会写Smali，也不用天天啃JADX反编译日志，只要理解清楚每个检测点的触发条件和绕过边界，就能在90%的场景下稳稳抓到明文HTTPS流量。

2. 四类主流代理检测机制的底层原理与触发边界

安卓App的代理检测不是铁板一块，而是由多个松耦合模块拼接而成。不同团队、不同SDK、不同安全厂商提供的方案差异很大，但归结起来，逃不出以下四类核心检测逻辑。每一类都有其明确的触发条件、可验证的绕过方式，以及极易被忽略的“伪阴性”陷阱。下面我用真实逆向案例说明，不堆代码，只讲原理和边界。

2.1 系统代理配置API轮询检测

这是最基础也最容易被绕过的检测方式。App通过调用Android SDK提供的标准API获取当前网络代理状态，典型代码如下：

ConnectivityManager cm = (ConnectivityManager) context.getSystemService(Context.CONNECTIVITY_SERVICE); NetworkInfo activeNetwork = cm.getActiveNetworkInfo(); if (activeNetwork != null && activeNetwork.isConnected()) { ProxyInfo proxyInfo = cm.getDefaultProxy(); if (proxyInfo != null) { String host = proxyInfo.getHost(); int port = proxyInfo.getPort(); Log.e("ProxyCheck", "Detected proxy: " + host + ":" + port); // 触发告警 } }

原理本质：Android系统在ConnectivityManager中维护了一个全局代理缓存，无论你用的是Fiddler、Charles还是mitmproxy，只要在系统设置里开启了“手动代理”，这个API就会返回非空ProxyInfo对象。App只需判断proxyInfo != null即可确认“存在代理”。

触发边界非常清晰：

• ✅ 触发：系统设置 → WLAN → 长按当前WiFi → 修改网络 → 高级选项 → 代理 → 手动 → 输入主机/端口
• ❌ 不触发：仅在Fiddler/Charles中开启监听，但未在Android系统设置中配置代理（即“仅本机生效”模式）
• ⚠️ 伪阴性陷阱：某些定制ROM（如小米MIUI 14）或Android 12+设备，在开启系统代理后，getDefaultProxy()可能返回null，但getProxyHost()仍可读取。必须同时检查两个API。

绕过成本：极低。只需不走系统代理设置，改用“仅本机代理”模式（Fiddler默认即此模式），或使用ADB命令临时注入代理（见第4章）。但注意：这种方式无法捕获WebView内嵌H5页面的流量，因为WebView默认读取系统代理设置。

2.2 网关IP与DNS污染特征检测

比API调用更隐蔽的是网络层特征扫描。这类检测不依赖系统API，而是直接发起探测请求，通过分析响应特征反推代理存在。典型手法有两类：

第一类：直连网关探测
App启动时，会向当前WiFi网关IP（如192.168.1.1）发起一个HTTP HEAD请求，或尝试建立TCP连接。如果网关IP是常见代理工具默认监听地址（如127.0.0.1、192.168.1.100、10.0.2.2），且该IP在端口8080/8888上响应了HTTP 200或建立了TCP连接，则判定为代理环境。

第二类：DNS污染诱导检测
App内置一个“可信域名列表”（如api.example.com），先通过系统DNS解析该域名，再用自定义DNS（如8.8.8.8）再次解析。若两次结果不一致（例如系统DNS返回192.168.1.100，而8.8.8.8返回203.208.60.1），则认为DNS被劫持，进而推断存在代理或中间人。

原理本质：这类检测不关心你是否配置了代理，只关心“网络出口是否被篡改”。它把代理工具当成一个“不可信的网关”，用最原始的网络连通性测试来打脸。

绕过关键点：必须切断App与“可疑IP”的任何接触。

• 不要将代理工具监听地址设为127.0.0.1（手机无法直连本机）
• 不要将代理工具部署在手机同局域网的PC上（如192.168.1.100），改用USB网络共享或ADB reverse（见第4章）
• 在抓包前，用adb shell getprop net.dns1确认手机DNS未被篡改，必要时用adb shell setprop net.dns1 8.8.8.8重置

提示：某银行App曾因检测到192.168.1.100:8080响应了HTTP 200而闪退，但实际该IP是用户NAS的Web管理界面。这说明检测逻辑过于粗糙——它不验证响应内容，只认IP+端口组合。绕过思路很简单：换一个冷门端口（如9999），或让NAS关闭8080端口。

2.3 SSL Pinning（证书固定）与TLS握手校验

这是HTTPS抓包失败的头号原因，也是最常被误解的环节。很多人以为“装了CA证书就万事大吉”，却不知App早已在代码里硬编码了服务端证书的公钥哈希值（pin），TLS握手时直接比对，不匹配就断连。

典型实现方式有三种：

• OkHttp内置Pinning：通过CertificatePinner类配置，如new CertificatePinner.Builder().add("api.example.com", "sha256/AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA=")
• TrustManager自定义校验：重写checkServerTrusted()方法，手动比对证书链中叶子证书的SHA-256指纹
• JNI层校验：将证书指纹写死在so库中，Java层仅调用校验接口，增加动态分析难度

原理本质：SSL Pinning不是防“没证书”，而是防“证书被替换”。它假设：只要服务端证书指纹不变，中间人就无法伪造合法链。因此，即使你用Charles生成了*.example.com的证书，只要指纹和App预埋的不一致，连接必然失败。

绕过前提：必须能修改App运行时的证书校验逻辑。Root手机+JustTrustMe插件是最常用方案，但2024年新版本App普遍增加了反调试+反Xposed+so层校验三重防护。此时，单纯靠插件已失效。

关键认知刷新：SSL Pinning本身不是问题，问题是App是否“只校验服务端证书”。很多App（如某外卖平台）的Pinning规则只针对pay.example.com，而api.example.com完全没做校验——这意味着你根本不需要绕过Pinning，只要抓api域名的流量即可满足大部分调试需求。务必先用apktool d app.apk -s反编译，搜索CertificatePinner、setHostnameVerifier、checkServerTrusted等关键词，确认Pinning范围，再决定是否投入精力绕过。

2.4 进程行为与网络栈特征检测

这是最高阶的检测，已脱离“查配置”层面，进入“看行为”阶段。App不再依赖静态配置，而是通过监控自身网络行为的异常来反推代理存在。典型手法包括：

• TCP连接超时统计：App向多个已知稳定IP（如8.8.8.8、1.1.1.1）发起并发TCP连接，统计平均耗时。若超时率>30%或平均延迟>300ms，则判定网络栈被代理工具劫持（因中间人需额外处理TLS握手）
• TLS ClientHello字段分析：解析自己发出的ClientHello报文，检查Cipher Suites字段是否包含非标准套件（如TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256），或ALPN协议是否被篡改（如强制插入h2）
• Socket选项校验：调用socket.getSoTimeout()、socket.getKeepAlive()等方法，比对返回值与预设安全阈值。代理工具为提升性能常修改这些参数，导致校验失败

原理本质：这类检测把代理工具当成一个“网络性能劣化器”，通过量化自身网络行为的偏差来触发防御。它不关心你装没装证书，只关心“我的连接是不是变慢/变怪了”。

绕过难点：无法通过配置解决，必须从代理工具侧适配。例如：

• Fiddler需关闭“Decrypt HTTPS traffic”功能，改用纯HTTP代理模式（牺牲HTTPS解密）
• mitmproxy需在config.yaml中禁用alpn_protocols，并设置timeout参数模拟原生连接行为
• 最稳妥方案：放弃全局代理，改用ADB reverse将特定端口流量定向到PC（见第4章），完全规避网络栈干预

注意：某短视频App曾因检测到ClientHello中supported_groups扩展字段缺失而拒绝启动。该字段是TLS 1.3特性，而Fiddler默认不支持TLS 1.3中间人，导致所有连接被拒。解决方案不是升级Fiddler，而是用adb shell settings put global http_proxy :0清空系统代理，再用ADB reverse单独转发目标端口。

3. 三套实操路径：从零配置到深度绕过，按需选择

知道了检测原理，下一步就是落地。我不会推荐“万能方案”，因为不存在。不同App的防护强度、你的设备权限（是否Root）、调试目标（只需看接口参数？还是必须解密HTTPS？）、时间成本（能否接受半小时配置？）都决定了最优路径。下面三套方案，覆盖从“小白友好”到“硬核可控”的完整光谱，每套我都附上了真实耗时、成功率和适用场景。

3.1 路径一：ADB Reverse + 本地代理（零Root，5分钟搞定，成功率65%）

这是最轻量、最安全、最推荐给新手的方案。它不碰系统代理设置，不装任何插件，完全利用Android Debug Bridge（ADB）的端口转发能力，把App发往某个IP:Port的流量，原封不动地“镜像”到你的PC上。整个过程App毫无感知，所有检测机制全部失效。

实操步骤（Windows/macOS通用）：

1. 开启USB调试：手机设置 → 关于手机 → 连续点击“版本号”7次 → 返回上一级 → 开启“开发者选项” → 开启“USB调试”
2. 连接PC并授权：用USB线连接手机与PC，在PC终端执行adb devices，手机弹出授权框，勾选“始终允许”，点击确定
3. 启动代理工具：打开Fiddler/Charles/mitmproxy，确保监听端口为8888（或其他你指定的端口，如9999）
4. 执行ADB reverse：在终端输入

   adb reverse tcp:8888 tcp:8888

   这条命令的意思是：“把手机上所有发往127.0.0.1:8888的TCP请求，转发到PC的127.0.0.1:8888”。注意：两端端口必须一致。
5. App内配置代理：打开App的网络设置（如有），将代理地址设为127.0.0.1:8888；若App无手动代理入口，则跳过此步，直接进入第6步
6. 启动App并抓包：此时App所有发往127.0.0.1:8888的流量都会被Fiddler捕获。若App默认连接api.example.com:443，你需要在App代码或配置中，将该域名的请求地址临时改为127.0.0.1:8888（可通过Hook或配置文件修改，见第4章技巧）

为什么这套方案能绕过所有检测？

• ✅ 绕过系统API检测：ConnectivityManager.getDefaultProxy()返回null，因未配置系统代理
• ✅ 绕过网关探测：App连接的是127.0.0.1，而非PC局域网IP，网关扫描无意义
• ✅ 绕过SSL Pinning：此方案不涉及HTTPS中间人，所有TLS握手均直连服务端，证书指纹完全匹配
• ✅ 绕过行为检测：无额外TLS处理，网络延迟与原生一致

适用场景：

• App提供手动代理配置入口（如企业内部App、测试版App）
• 你能修改App的请求URL（如通过修改buildConfigField、strings.xml或SharedPreference）
• 你只需要抓取特定接口（如登录、支付），而非全量流量
• 你没有Root权限，或不想承担Root风险

真实数据：在我测试的47款App中，此方案在21款（44.7%）中可直接成功；在剩余26款中，15款需配合第4章的“URL Hook”技巧（成功率提升至65%）；其余11款因强绑定域名且无配置入口，需升级到路径二。

3.2 路径二：JustTrustMe + Magisk模块（需Root，15分钟，成功率88%）

当路径一失效，说明App做了深度加固：它不接受任何外部代理配置，所有网络请求均由内置SDK（如OkHttp、Retrofit）封装，且强制校验证书。此时，必须在运行时劫持证书校验逻辑。JustTrustMe（Xposed模块）曾是黄金标准，但2023年后，Xposed在Android 10+设备上兼容性极差。现在更可靠的是Magisk + TrustMeAlready模块（JustTrustMe的Magisk化版本）。

实操步骤（以Android 12 Pixel为例）：

1. Root设备：刷入Magisk v26.1+，确保Magisk Manager中显示“Installed”且SafetyNet状态为“Basic Integrity Pass”（部分App不检查SafetyNet，可跳过）
2. 安装TrustMeAlready：在Magisk Manager → 模块 → 从本地安装 → 选择TrustMeAlready-v1.2.1.zip（GitHub最新版）→ 重启
3. 配置模块作用域：重启后打开Magisk Manager → 模块 → TrustMeAlready → 设置图标 → 勾选“Force enable for all apps” → 保存
4. 关闭系统代理：adb shell settings put global http_proxy :0，确保无残留代理干扰
5. 启动App并抓包：打开Fiddler/Charles，安装CA证书（手机浏览器访问http://chls.pro/ssl），启动App，此时HTTPS流量应正常解密

核心原理：TrustMeAlready是一个Magisk模块，它在Zygote进程启动时，通过LD_PRELOAD注入libtrustme.so，劫持X509TrustManager.checkServerTrusted()和OkHttpClient.CertificatePinner等关键方法，将其校验逻辑替换为“永远返回true”。与Xposed不同，它不依赖Hook框架，而是直接修改内存中的函数指针，兼容性更强。

为什么成功率高达88%？

• ✅ 绕过所有Java层SSL Pinning：无论App用OkHttp、Volley还是自定义TrustManager，均被统一拦截
• ✅ 兼容Android 10~14：基于Magisk底层机制，不受SELinux策略限制
• ✅ 无反调试冲突：模块本身不启动调试端口，不触发App的Debug.isDebuggerConnected()检测

避坑重点：

• 某些App（如某支付SDK）会校验libtrustme.so的文件签名，此时需用magiskhide隐藏模块（Magisk Manager → 设置 → MagiskHide → 勾选App）
• 若Fiddler仍无法解密，大概率是App使用了Conscrypt或BoringSSL等非标准TLS库，需额外安装ConscryptFix模块
• TrustMeAlready不处理JNI层校验，若App的so库中硬编码了证书指纹，此方案无效，需升级到路径三

实测案例：某证券App在路径一中完全无响应，启用TrustMeAlready后，HTTPS流量100%解密，且App无任何异常日志。但某社交App在启用模块后，首页图片加载变慢——这是因为模块劫持了所有SSL校验，包括CDN图片的HTTPS请求，导致额外CPU开销。解决方案：在模块设置中，取消勾选该App，改用路径三的“精准Hook”。

3.3 路径三：Frida Hook + 动态脚本（Root/Non-Root均可，30分钟，成功率99%）

这是终极方案，适用于所有场景，包括：

• App做了JNI层SSL Pinning（so库中校验）
• App检测并屏蔽了TrustMeAlready模块
• 你只想解密特定域名（如只抓pay.example.com，放过cdn.example.com）
• 你没有Root，但手机支持Frida Gadget（Android 7+基本都支持）

Frida是一个动态插桩工具，它能在App运行时，将JavaScript脚本注入到目标进程中，直接修改内存中的函数逻辑。与TrustMeAlready的“全局覆盖”不同，Frida可以做到“精准打击”。

实操步骤（以Non-Root模式为例）：

1. 准备Frida Gadget：下载frida-gadget-15.1.17-android-arm64.so（根据手机CPU架构选择arm64/arm/x86）
2. 重打包App：
   • apktool d app.apk -s -o app_decoded
   • 将frida-gadget.so复制到app_decoded/lib/arm64-v8a/目录下（若无此目录，新建）
   • 修改app_decoded/AndroidManifest.xml，在<application>标签内添加

     <meta-data android:name="frida-gadget" android:value="true" />

   • apktool b app_decoded -o app_patched.apk
   • jarsigner -verbose -sigalg SHA1withRSA -digestalg SHA1 -keystore mykey.keystore app_patched.apk alias_name
3. 编写Hook脚本（ssl-pinning-bypass.js）：

   Java.perform(function () { // Hook OkHttp CertificatePinner var CertificatePinner = Java.use("okhttp3.CertificatePinner"); CertificatePinner.check$okhttp.call = function (hostname, peerCertificates) { console.log("[+] Bypassed OkHttp CertificatePinner for " + hostname); return; }; // Hook TrustManager checkServerTrusted var X509TrustManager = Java.use("javax.net.ssl.X509TrustManager"); X509TrustManager.checkServerTrusted.overload('[Ljava.security.cert.X509Certificate;', 'java.lang.String').implementation = function (chain, authType) { console.log("[+] Bypassed X509TrustManager for " + authType); return; }; // Hook JNI层SSL校验（示例：某App的native_check_cert函数） var nativeLib = Module.findBaseAddress("libssl.so"); if (nativeLib) { Interceptor.attach(nativeLib.add(0x12345), { // 地址需用IDA Pro或Ghidra动态获取 onEnter: function (args) { console.log("[+] Bypassed JNI SSL check"); }, onLeave: function (retval) { retval.replace(ptr("0x0")); // 返回0表示校验通过 } }); } });

4. 启动Frida Server并注入：
   • 手机端：adb push frida-server /data/local/tmp/ && adb shell chmod 755 /data/local/tmp/frida-server
   • PC端：frida -U -f com.example.app -l ssl-pinning-bypass.js --no-pause

为什么这是99%成功率的方案？

• ✅ 可Hook任意Java方法：包括反射调用、匿名内部类，无死角
• ✅ 可Hook JNI函数：只要知道so库中校验函数的地址，就能精准绕过
• ✅ 可Conditional Hook：脚本中加入if (hostname.includes("pay."))，只解密支付域名
• ✅ Non-Root可用：通过重打包注入Gadget，无需Root权限

学习成本提示：

• Frida语法简单，但定位JNI函数地址需要逆向基础。建议先用objdump -d libssl.so | grep -A5 "check_cert"快速定位
• 某电商App的JNI校验函数名为Java_com_example_security_SslUtil_verifyCert，地址在libsecurity.so偏移0x8A3C，Hook后解密成功率100%
• 若你不想重打包，可尝试frida -U -f com.example.app -l script.js --no-pause，但成功率下降至70%，因部分App会检测Frida注入

4. 八个血泪教训：那些文档里绝不会写的避坑细节

上面三套路径，理论上能解决99%的问题。但实际操作中，有80%的失败并非方案不行，而是栽在这些“文档里绝不会写”的细节上。这些是我踩过至少三次坑、翻过上百份崩溃日志、对比过数十个APK反编译结果后，总结出的最痛教训。它们不炫技，但句句救命。

4.1 证书安装顺序错一位，抓包成功率归零

很多人以为“装了CA证书就完事了”，却不知Android对用户证书的存储位置、信任链、别名有严格要求。2023年之后，Android 11+设备强制要求：用户CA证书必须安装在“用户证书”目录，且必须命名为*.crt或.pem，不能是.cer或.der。更致命的是，证书链必须完整。

真实翻车现场：

• 我用Charles生成的证书是charles-proxy-ca.crt，但导出时误选了“DER格式”，文件后缀为.cer。手机安装后，系统识别为“私钥证书”，不加入信任链，导致所有HTTPS请求返回SSLHandshakeException。
• 某App的后端使用Let's Encrypt多级证书链（Root → Intermediate → Leaf），而Charles默认只导出Leaf证书。手机安装后，校验时无法构建完整链，判定为“证书不可信”。

正确操作清单：

• ✅ 用浏览器访问http://chls.pro/ssl，直接下载官方证书（已处理好格式和链）
• ✅ 若需自签证书，用OpenSSL生成时，必须包含Intermediate证书：

  openssl x509 -in leaf.crt -text -noout | grep "Issuer" # 确认Issuer是Intermediate cat leaf.crt intermediate.crt > fullchain.pem # 合并为完整链

• ✅ 安装后，进入手机设置 → 安全 → 加密与凭据 → 用户证书，确认证书名称显示为“Charles Proxy CA”而非乱码，且状态为“已启用”

提示：某金融App在证书安装后，仍报“证书不受信任”，最终发现是手机系统时间误差超过3分钟。Android校验证书时，会严格比对Not Before/After时间戳。用adb shell date -s "20240520.120000"同步时间后，问题消失。

4.2 抓包工具监听地址选错，等于白忙活两小时

Fiddler/Charles默认监听127.0.0.1:8888，这个地址在PC上没问题，但在手机上，127.0.0.1指向的是手机自身，而非PC。这是新手最常犯的错误，也是“为什么我配好了却抓不到包”的头号原因。

监听地址选择指南：

验证方法：

• PC端启动Fiddler后，在浏览器访问http://127.0.0.1:8888，应看到Fiddler欢迎页
• 手机浏览器访问http://[PC局域网IP]:8888（如http://192.168.1.100:8888），若能看到欢迎页，说明监听配置正确；若超时，检查PC防火墙是否放行8888端口

血泪教训：我曾为某教育App调试，反复重装证书、换端口、关防火墙，耗时3小时。最后发现Fiddler监听地址是127.0.0.1:8888，而手机连的是192.168.1.100:8888——手机根本连不上PC。改成0.0.0.0:8888后，5秒解决。

4.3 App的“网络诊断”功能，是代理检测的放大器

很多App（尤其是运营商、银行类）内置“网络诊断”按钮，点击后会自动执行一整套网络健康检查：测DNS、测Ping、测HTTPS握手、查代理设置。这个功能本意是帮用户排障，但对抓包者来说，它是检测逻辑的“主动触发器”。

典型行为：

• 点击“网络诊断”后，App立即调用ConnectivityManager.getDefaultProxy()，若返回非空，则后续所有请求均走降级逻辑
• 诊断过程中，App会向127.0.0.1:8080发起HTTP请求，若响应成功，则标记“代理环境”，后续启动即闪退
• 某App的诊断逻辑写在NetworkDiagService.java中，且被@Keep注解保留，ProGuard无法混淆，极易被Hook

应对策略：

• ✅ 抓包前，绝对不要点击任何“网络诊断”、“修复网络”、“一键检测”类按钮
• ✅ 若App启动即弹诊断框，用Frida Hook掉NetworkDiagService.startDiag()方法，直接return
• ✅ 在adb logcat | grep -i "diag\|network"中监控诊断日志，提前预判检测时机

4.4 Android 12+的Private DNS，是HTTPS抓包的隐形杀手

Android 9引入Private DNS（DNS over TLS），默认开启。它会强制所有DNS查询走加密通道（如dns.google），绕过本地hosts和代理工具的DNS劫持。这导致一个诡异现象：Fiddler能抓到HTTP请求，但HTTPS请求始终显示“Failed to decrypt”，因为DNS解析失败，TCP连接根本建不起来。

验证方法：

• 手机设置 → 网络与互联网 → 私人DNS → 查看是否为“自动”或填写了dns.google
• adb shell getprop net.dns1，若返回空或127.0.0.1，则Private DNS已生效

解决方案：

• ✅ 临时关闭：设置 → 私人DNS → 选择“关闭”
• ✅ 永久关闭（需ADB）：adb shell settings put global private_dns_mode off
• ✅ 若必须开启Private DNS，改用dnscrypt-proxy在PC上搭建本地DoT服务器，将net.dns1指向PC IP

注意：某视频App在Private DNS开启时，api.example.com解析为CDN IP，而Fiddler证书是为api.example.com签发的，导致SNI不匹配，TLS握手失败。关闭Private DNS后，DNS走本地，解析为源站IP，问题解决。

4.5 抓包不是目的，读懂流量才是关键

最后一点，也是最重要的一点：抓到明文HTTPS流量，不等于完成了调试。很多新手拿到一堆JSON就以为大功告成，却忽略了三个致命问题：

• 参数加密：{"data":"aGVsbG8=","sign":"xxxx"}中的data是Base64，但解码后仍是密文。真正的加密在App层（AES/RSA），需逆向CryptoUtil.encrypt()方法
• 时间戳校验：{"ts":"1716230400","nonce":"abc123"}，ts是秒级时间戳，服务端校验±300秒，抓包重放必失败
• 设备指纹绑定：{"device_id":"xxx","fingerprint":"yyy"}，fingerprint由IMEI、MAC、Android ID等生成，每次启动变化，重放请求会被拒绝

高效调试心法：

• 第一步：用grep -r "encrypt\|decrypt\|sign\|verify" app_decoded/smali/定位加解密入口
• 第二步：在Frida脚本中，Hook这些方法，打印出入参，建立“明文→密文”映射表
• 第三步：用Postman重放时，调用App的JS Bundle或Java方法生成合法sign和fingerprint

我曾为某电商App抓到完整的下单请求，但重放时始终返回“非法请求”。最终发现sign是用HmacSHA256对timestamp+nonce+body计算，而body是JSON字符串化后的结果（非对象）。少了一个JSON.stringify()，就全军覆没。

4.6 代理工具的“HTTPS解密”开关，不是万能钥匙

Fiddler/Charles的“Decrypt HTTPS traffic”功能，本质是启动一个本地HTTPS代理服务器，冒充服务端与App握手。但它有硬性限制：只能解密TLS 1.2及以下版本，且不支持ECC证书、不支持TLS 1.3的0-RTT。

典型失败场景：

• App强制使用TLS 1.3（如某即时通讯App），Fiddler握手失败，返回ERR_SSL_VERSION_OR_CIPHER_MISMATCH
• 服务端证书使用ECDSA签名（ECC证书），Fiddler默认不支持，握手卡在CertificateVerify阶段
• App启用TLS 1.3 0-RTT，首次连接即发送加密应用数据，Fiddler来不及解密

解决方案：

• ✅ Fiddler：Tools → Options →