企业官网建设流程全解析

1. 项目概述：当TikTok遇上小米8，抓包为何频频“失联”？

如果你是一名移动安全研究员、逆向工程师，或者只是一个对TikTok内部数据流感到好奇的开发者，那么“抓包”这个操作对你来说一定不陌生。无论是用Wireshark、Fiddler还是Charles，抓取App的网络请求数据，是分析其行为、调试接口、甚至研究其推荐算法的第一步。然而，当你信心满满地在小米8上配置好代理，打开TikTok，却发现抓包工具里一片寂静，或者全是看不懂的乱码时，那种挫败感我深有体会。这不仅仅是TikTok的问题，更是当前移动应用，特别是头部App，为对抗逆向分析与数据抓取而普遍采用的“组合拳”防御策略的体现。小米8作为一款曾经的热门机型，其系统环境与这些防御机制相互作用，使得抓包失败成了一个典型且棘手的问题。

简单来说，这个项目要解决的核心痛点就是：在小米8设备上，如何成功捕获并解密TikTok App发出的网络请求数据。这背后涉及到的技术对抗远比你想象的要复杂。TikTok这类应用通常会启用SSL Pinning（证书绑定）来防止中间人攻击（也就是我们的抓包行为），还可能检测代理设置、使用自定义的HTTP客户端或证书验证逻辑，甚至对网络库进行深度混淆。而小米8的MIUI系统，特别是较新的版本，自身也对网络权限、证书安装有着更严格的管理，这无形中又增加了一层障碍。

因此，单纯地安装一个抓包工具的CA证书到系统信任库，在几年前或许可行，但现在早已行不通。我们需要一套更底层、更主动的技术方案来“绕过”这些检测和限制。这就是Frida登场的时候。Frida是一个动态代码插桩框架，它允许我们在App运行时注入自己的JavaScript脚本，去修改其内存和行为。我们可以用它来“钩住”（Hook）关键的函数，比如证书验证的逻辑，让它总是返回“验证通过”；或者绕过代理检测，让App“以为”自己没有处于抓包环境。

接下来的内容，我将以一个实战者的角度，带你一步步拆解在小米8上抓包TikTok失败的各种可能原因，并手把手教你编写和部署Frida脚本来解决这些问题。无论你是想研究TikTok的API，还是将这套方法论应用到其他加固严密的App上，相信这篇详尽的记录都能给你提供清晰的路径和实用的工具。

2. 环境准备与核心工具链搭建

工欲善其事，必先利其器。在开始“手术”之前，我们必须把手术台——也就是我们的测试环境——搭建得稳固且高效。这个环境主要包括三部分：硬件设备（小米8）、抓包代理工具（Charles/Fiddler）、以及我们的核心武器Frida。每一环的配置都至关重要，一个细节出错就可能导致全盘失败。

2.1 小米8设备端配置要点

你的小米8是这场战斗的主战场。首先，确保你的手机已经解锁Bootloader并获取了Root权限。这对于后续将Frida-Server以高权限运行以及将抓包工具的CA证书安装到系统证书目录是必须的。对于小米8，解锁和Root的教程网上很丰富，这里不再赘述，但请注意备份数据，此过程会清空手机。

开发者选项与USB调试：在手机设置中连续点击“MIUI版本”打开开发者选项，然后开启“USB调试”和“USB调试（安全设置）”。连接电脑后，在手机弹出的授权对话框中点击“允许”。这是PC端工具（如ADB、Frida）与手机通信的基础。

网络代理配置：这是抓包的第一步，也是最容易出错的一步。假设你的电脑IP是192.168.1.100，抓包工具（如Charles）监听端口是8888。

1. 在手机连接的Wi-Fi设置中，找到“代理”选项，选择“手动”。
2. 主机名填写你的电脑IP192.168.1.100，端口填写8888。
3. 保存。此时，手机的所有HTTP流量理论上都会经过你的电脑。

注意：很多App（包括TikTok）会检测系统是否设置了代理。因此，这一步配置后，TikTok可能直接无法联网或行为异常。这正是我们需要用Frida去绕过的点之一。所以，如果配置代理后TikTok打不开，别慌，这恰恰说明我们的方向对了。

系统证书安装：要让手机信任抓包工具伪造的证书，必须将CA证书安装到系统信任区。在已Root的手机上，最简单的方法是使用ADB命令。

1. 在抓包工具（如Charles）中，导出根证书，通常保存为charles-ssl-proxying-certificate.pem。
2. 使用OpenSSL或在线工具将其转换为DER格式（charles.der），因为Android系统证书需要特定的文件名和格式。
3. 通过ADB将证书推送到系统证书目录，并修改权限：

   adb push charles.der /sdcard/ adb shell su mount -o remount,rw /system cp /sdcard/charles.der /system/etc/security/cacerts/ # 证书文件名必须为其哈希值.0，使用openssl计算 # 在电脑上执行：openssl x509 -inform DER -in charles.der -subject_hash_old -noout # 假设得到哈希值 `a0b1c2d3` mv /system/etc/security/cacerts/charles.der /system/etc/security/cacerts/a0b1c2d3.0 chmod 644 /system/etc/security/cacerts/a0b1c2d3.0 mount -o remount,ro /system reboot

   重启后，证书就应该在“设置->安全->加密与凭据->信任的凭据->系统”中看到了。

2.2 抓包工具的选择与基础配置

Charles和Fiddler是两大主流选择，功能类似。我个人更习惯用Charles，界面更直观。这里以Charles为例说明关键配置。

基础代理设置：打开Charles，确保Proxy -> Proxy Settings中，HTTP代理的端口（如8888）已开启。同时，务必勾选Enable transparent HTTP proxying。

SSL代理配置：这是解密HTTPS流量的核心。

1. 进入Proxy -> SSL Proxying Settings。
2. 在SSL Proxying标签页，勾选Enable SSL Proxying。
3. 在Locations列表中添加一条规则：Host 为*，Port 为*。这意味着Charles会尝试代理并解密所有HTTPS流量。

设备连接验证：完成手机代理配置后，在手机上用浏览器访问一个HTTP网站（如http://neverssl.com）。Charles应该会立即弹出连接请求，点击“Allow”。如果能成功抓到浏览器的明文请求，说明手机到Charles的网络通路是正常的。这是后续所有工作的基石。

2.3 Frida环境部署：从安装到第一个Hook

Frida分为两部分：PC端的Frida客户端（frida-tools）和运行在手机端的Frida服务端（frida-server）。

PC端安装：非常简单，使用Python的pip包管理器即可。建议在虚拟环境中操作。

pip install frida-tools

安装完成后，命令行输入frida --version验证。

手机端部署：这是关键步骤，需要对应你的手机架构。

1. 去Frida的GitHub Releases页面，找到与PC端frida-tools版本匹配的frida-server。小米8是高通骁龙845处理器，是64位ARM架构，应下载frida-server-xx.x.x-android-arm64.xz。
2. 解压得到frida-server-xx.x.x-android-arm64文件。
3. 通过ADB将其推送到手机，并赋予执行权限：

   adb push frida-server-xx.x.x-android-arm64 /data/local/tmp/frida-server adb shell su cd /data/local/tmp chmod 755 frida-server

4. 运行Frida服务端：

   ./frida-server &

   保持这个shell窗口打开，或者使用nohup让它在后台运行。

验证连接：新开一个命令行窗口，执行：

frida-ps -U

如果能看到手机当前运行的进程列表，恭喜你，Frida环境搭建成功。-U参数代表连接到USB设备。

第一个Hook脚本体验：为了建立信心，我们可以先写一个简单的脚本来验证Frida能正常工作。创建一个名为test.js的文件：

Java.perform(function() { console.log("[*] Frida脚本注入成功！"); // 尝试Hook一个常见的类，比如StringBuilder的toString方法 var StringBuilder = Java.use('java.lang.StringBuilder'); StringBuilder.toString.implementation = function() { var result = this.toString(); console.log("[*] StringBuilder.toString() 被调用，结果: " + result); return result; }; });

然后在命令行使用Frida加载这个脚本到某个系统进程（如com.android.settings设置）：

frida -U -l test.js -f com.android.settings --no-pause

如果能看到控制台输出注入成功的日志以及一些toString调用，说明你的Frida已经整装待发，可以开始真正的挑战了。

3. TikTok抓包防御机制深度拆解

在动手写绕过脚本之前，我们必须像侦探一样，先搞清楚“对手”TikTok究竟用了哪些手段来阻止我们抓包。盲目地Hook就像在黑暗中开枪，效率低下。通过静态分析（查看反编译的代码）和动态行为观察，我总结出TikTok（尤其是国际版）常用的几层防御，理解这些是设计有效Frida脚本的前提。

3.1 SSL Pinning（证书绑定）：最坚固的第一道门

这是导致Charles/Fiddler显示TikTok流量为unknown或TLS handshake failure的最常见原因。SSL Pinning的原理是，App在代码中“硬编码”了它信任的服务端证书或公钥哈希。当建立TLS连接时，App不仅会验证证书链是否由系统信任的CA签发（这一步我们的假证书已经能通过），还会额外比对服务端返回的证书是否与它“记忆中”的那个特定证书匹配。如果不匹配，即使系统说证书有效，App也会主动断开连接。

TikTok的实现通常非常隐蔽。它可能将证书信息加密后存放在资源文件里，或者在运行时从服务器动态获取Pin列表。常见的实现方式是通过OkHttp的CertificatePinner类，或者更底层的X509TrustManager接口的自定义实现。我们的目标就是找到这些验证点，并让它们“失效”。

3.2 代理检测与绕过：切断流量转发路径

即使我们绕过了证书绑定，如果App检测到自己正在使用代理（Wi-Fi设置中手动配置了代理服务器），它可能会采取以下行为之一：

1. 拒绝向配置的代理服务器发送任何流量，导致Charles什么都抓不到。
2. 切换到使用自己的原生Socket直连，绕过系统的代理设置。
3. 触发风控逻辑，返回错误或空白数据。

检测代理的方法多种多样。App可以读取系统属性（如System.getProperty(“http.proxyHost”)），检查网络连接信息（ConnectivityManager/Network相关API），或者直接尝试连接一个已知的“代理检测”端点。我们的Frida脚本需要Hook这些检测点，让它们返回“无代理”的状态。

3.3 自定义网络栈与证书验证：藏在深处的校验

一些大型App，为了追求极致的性能或控制力，会使用自己编译的网络库（如Cronet，基于Chromium的网络栈）或者深度定制OkHttp/HttpURLConnection。它们可能：

• 实现自己的TrustManager，包含额外的校验逻辑。
• 使用SSLSocketFactory创建自定义的SSL Socket。
• 在Native层（C/C++）进行证书验证，这比Java层更难追踪和Hook。

对于这种情况，我们需要进行更广泛的搜索和尝试。可能需要Hook多个可能的类和方法，甚至需要用到Frida的Native Hook功能（Interceptor）来对付so库中的函数。

3.4 反调试与反Hook：矛与盾的较量

TikTok很可能集成了商业的加固方案或自研的反调试机制。它们会检测Frida等调试工具的存在。常见手段包括：

• 检查进程名、映射的内存区域中是否有frida相关字符串。
• 检测ptrace跟踪，防止进程被附加。
• 定时检查关键函数是否被Hook（通过比较函数头部的字节码）。 如果被检测到，App可能会崩溃、退出或进入“沙盒模式”返回假数据。

因此，一个成熟的绕过方案，有时还需要先“隐藏”自己。这涉及到与反调试机制的对抗，是一个更深的领域。对于初步抓包，我们可以尝试先不触发这些机制，或者使用一些现成的反反调试Frida脚本。

4. Frida脚本实战：逐层击破防御

理论分析完毕，现在进入最激动人心的实战环节。我们将编写一个综合性的Frida脚本，尝试逐层剥离TikTok的防御。请注意，TikTok的代码会频繁更新，具体的类名和方法名可能会变化，这里的代码更侧重于提供思路和模式，你可能需要根据实际情况进行调整。

4.1 通用型SSL Pinning绕过脚本

我们的策略是“广撒网”，Hook那些可能用于证书验证的关键类。创建一个名为bypass_ssl_pinning.js的文件。

策略一：禁用OkHttp的CertificatePinner

Java.perform(function() { console.log("[*] 开始尝试绕过SSL Pinning..."); // 1. 尝试Hook OkHttp3的CertificatePinner try { var CertificatePinner = Java.use('okhttp3.CertificatePinner'); CertificatePinner.check.overload('java.lang.String', '[Ljava.security.cert.Certificate;').implementation = function(pin, certs) { console.log("[+] 成功绕过OkHttp CertificatePinner.check()"); // 直接跳过检查，什么也不做 }; console.log("[*] OkHttp3 CertificatePinner Hook 已设置。"); } catch (e) { console.log("[-] 未找到OkHttp3 CertificatePinner类: " + e.message); } // 2. 尝试Hook Apache HttpClient的TrustManager (较老版本可能使用) try { var TrustManager = Java.use('org.apache.http.conn.ssl.TrustManager'); TrustManager.checkServerTrusted.implementation = function(chain, authType) { console.log("[+] 绕过Apache HttpClient TrustManager检查"); return; }; console.log("[*] Apache HttpClient TrustManager Hook 已设置。"); } catch (e) { // 忽略，很多App已不用 } });

这个脚本尝试了两种常见的库。但TikTok可能使用自定义的TrustManager。

策略二：Hook全局的TrustManager（更暴力通用）这是更底层、更有效的方法，目标是Android系统用于验证证书的X509TrustManager接口。

Java.perform(function() { // 获取所有已加载的类 Java.enumerateLoadedClasses({ onMatch: function(className) { // 寻找可能是TrustManager的类 if (className.includes('X509TrustManager') || className.includes('TrustManager')) { console.log("[*] 发现可能的TrustManager类: " + className); try { var TrustManagerClass = Java.use(className); // Hook checkServerTrusted 方法，它有多种重载 var overloads = TrustManagerClass.checkServerTrusted.overloads; for (var i = 0; i < overloads.length; i++) { overloads[i].implementation = function() { console.log("[+] 绕过TrustManager检查: " + className); // 直接返回，表示信任所有证书 return; }; } } catch (e) { console.log("[-] Hook " + className + " 失败: " + e); } } }, onComplete: function() { console.log("[*] TrustManager类枚举完成。"); } }); });

这个脚本会枚举所有已加载的类，找到名字里带TrustManager的，并Hook其checkServerTrusted方法。这是一种“宁可错杀，不可放过”的策略，通常能有效绕过大部分证书绑定。

4.2 代理检测屏蔽脚本

接下来，我们让TikTok“看不见”代理。创建bypass_proxy_detection.js。

Java.perform(function() { console.log("[*] 开始尝试屏蔽代理检测..."); // 1. Hook System.getProperty，当查询代理相关属性时返回空 var System = Java.use('java.lang.System'); System.getProperty.overload('java.lang.String').implementation = function(key) { var originalResult = this.getProperty(key); if (key && (key.toLowerCase().contains('proxy') || key === 'http.proxyHost' || key === 'https.proxyHost')) { console.log("[+] 拦截代理系统属性查询: " + key + "，返回null"); return null; // 或者返回空字符串 "" } return originalResult; }; // 2. Hook 网络相关类，修改代理信息 (针对更高版本的API) try { var Proxy = Java.use('java.net.Proxy'); var ProxyType = Java.use('java.net.Proxy$Type'); // 可以尝试Hook ProxySelector，但更直接的方法是Hook建立连接的地方 // 3. Hook ConnectivityManager 或 Network 相关方法 (API 21+) // 这里以获取活动网络信息为例，更复杂的检测可能需要Hook更多点 var ConnectivityManager = Java.use('android.net.ConnectivityManager'); ConnectivityManager.getActiveNetworkInfo.implementation = function() { var result = this.getActiveNetworkInfo(); if (result != null) { // 可以在这里打印或修改网络信息，但直接返回原对象通常即可 console.log("[*] getActiveNetworkInfo被调用"); } return result; }; console.log("[*] 代理检测相关Hook已设置。"); } catch (e) { console.log("[-] 部分代理检测Hook失败: " + e.message); } // 4. 针对特定库的代理检测，如OkHttp的ProxySelector try { var OkHttpClientBuilder = Java.use('okhttp3.OkHttpClient$Builder'); OkHttpClientBuilder.proxySelector.implementation = function(selector) { console.log("[+] 拦截OkHttpClient Builder.proxySelector设置，将其置为null"); return this.proxySelector(null); // 传入null表示不使用代理选择器 }; } catch (e) { // 忽略 } });

这个脚本从系统属性、网络信息、HTTP客户端配置等多个层面尝试欺骗App，使其认为没有配置代理。

4.3 整合与注入脚本

我们将上述两个脚本的核心功能整合到一个主脚本tiktok_bypass_all.js中，并增加一些实用功能。

Java.perform(function() { console.log("\n========== TikTok抓包绕过脚本启动 ==========\n"); // ------- 第一部分：绕过SSL Pinning ------- console.log("[*] 阶段1: 尝试绕过SSL Pinning"); // 使用上述“策略二：Hook全局TrustManager”的代码块，此处省略重复... // 将其完整复制到这里 // ------- 第二部分：屏蔽代理检测 ------- console.log("\n[*] 阶段2: 尝试屏蔽代理检测"); // 使用上述 `bypass_proxy_detection.js` 的核心代码块，此处省略重复... // 将其完整复制到这里 // ------- 第三部分：额外加固绕过尝试 (可选) ------- console.log("\n[*] 阶段3: 尝试绕过简单反调试"); // 例如，Hook一些常见的检测点 try { // 检测调试器连接的常见方法 var Debug = Java.use('android.os.Debug'); Debug.isDebuggerConnected.implementation = function() { console.log("[+] 绕过 isDebuggerConnected 检测，返回false"); return false; }; } catch (e) {} // ------- 第四部分：监听网络请求 (辅助验证) ------- console.log("\n[*] 阶段4: 监听关键网络请求"); // Hook URL.openConnection 来观察请求（对于非高级网络库可能有效） try { var URL = Java.use('java.net.URL'); URL.openConnection.overload().implementation = function() { var result = this.openConnection(); console.log("[*] URL.openConnection: " + this.toString()); return result; }; URL.openConnection.overload('java.net.Proxy').implementation = function(p) { var result = this.openConnection(p); console.log("[*] URL.openConnection(Proxy): " + this.toString()); return result; }; } catch (e) { console.log("[-] URL.openConnection Hook失败: " + e.message); } console.log("\n========== 脚本注入完成，开始抓包尝试 ==========\n"); });

如何使用脚本：

1. 确保手机上的Frida-server正在运行。
2. 在电脑上，启动Charles并配置好SSL代理。
3. 在手机上设置好Wi-Fi代理（指向Charles）。
4. 在电脑命令行，使用Frida将脚本附加到正在运行的TikTok进程上：

   # 先找出TikTok的进程名或PID frida-ps -U | grep tiktok # 假设进程名是 com.zhiliaoapp.musically (国际版包名) frida -U -l tiktok_bypass_all.js -f com.zhiliaoapp.musically --no-pause

   或者，如果TikTok已经在运行，使用-F参数附加：

   frida -U -l tiktok_bypass_all.js -F --no-pause

5. 观察Frida控制台输出，如果看到大量的[+] 绕过TrustManager检查等成功日志，同时Charles不再报TLS错误，并且开始出现TikTok的域名（如*.tiktokv.com,*.byteoversea.com）的请求，那么恭喜你，抓包成功了！

5. 高级技巧与疑难问题排查

即使按照上述步骤操作，你可能依然会遇到各种问题。这里分享一些我踩过坑后总结的高级技巧和排查思路。

5.1 脚本注入失败或App崩溃

现象：运行Frida命令后，TikTok立刻闪退，或者Frida提示无法附加/注入失败。

• 可能原因1：反Frida检测。TikTok在启动时检测到Frida并主动崩溃。
  • 应对：尝试使用Frida的-f参数在App启动时即注入（spawn模式），而不是等它运行后再附加。或者使用更隐蔽的注入方式，如修改Frida-server文件名、使用frida-gadget等。
  • 命令：frida -U -l script.js -f com.zhiliaoapp.musically --no-pause。
• 可能原因2：脚本Hook了不兼容的方法。某些Hook可能导致内存错误或类型转换异常。
  • 应对：注释掉脚本中部分Hook，采用“二分法”定位导致崩溃的代码块。特别是那些枚举所有类进行Hook的代码，可能Hook了不该Hook的类。增加更精确的类名过滤条件。
• 可能原因3：权限不足。虽然手机已Root，但某些进程（如zygote）或环境可能受限。
  • 应对：确保以su身份运行frida-server。尝试重启手机和frida-server。

5.2 Charles仍显示TLS错误或Unknown

现象：Frida脚本成功运行并有绕过日志，但Charles中TikTok的请求仍是TLS Handshake Failure或Unknown。

• 可能原因1：证书未正确安装到系统区。即使安装了，某些App（或系统WebView）可能只信任系统证书库中特定格式或位置的证书。
  • 排查：在手机系统设置的“信任的凭据”中，确认你的Charles证书确实在“系统”标签页下，而不是“用户”标签页。尝试将证书同时安装到用户区和系统区。
  • 终极方案：使用Magisk模块（如MoveCertificates）将用户证书移动到系统区，或使用BurpSuite的CA Certificates模块（需Magisk）。
• 可能原因2：TikTok使用了纯Native的网络请求。例如，通过libcronet.so这样的原生库发起请求，我们的Java层Hook完全无效。
  • 应对：这需要用到Frida的Native Hook（Interceptor）。你需要逆向分析so库，找到SSL连接或证书验证的函数（如SSL_CTX_set_cert_verify_callback）。这难度极大，属于高级逆向范畴。
  • 折中方案：尝试抓取DNS请求或使用更底层的抓包工具，如tcpdump（需Root）在手机上直接抓取原始流量，但得到的是加密的数据包。
• 可能原因3：Charles的SSL代理设置问题。
  • 排查：确保Charles的SSL Proxying Settings中已经为*:*启用了代理。尝试关闭并重新打开Charles的SSL代理功能。重启Charles和手机。

5.3 抓到的请求数据不完整或仍是乱码

现象：能抓到请求，但响应体是乱码或者被压缩了。

• 可能原因：内容编码或压缩。
  • 解决：在Charles中，右键点击请求，选择Enable SSL Proxying确保解密。对于乱码，查看响应头的Content-Encoding，如果是gzip或br（Brotli），Charles通常会自动解压显示。如果没有，可以尝试在请求上右键选择Repeat并在Edit Request中手动添加Accept-Encoding: identity请求头（告诉服务器不要压缩），但这可能被服务器忽略。

5.4 性能与稳定性优化

问题：注入脚本后，TikTok运行变卡顿，或者使用一段时间后脚本失效。

• 优化1：精确Hook，避免枚举所有类。前面提供的“广撒网”脚本性能损耗大。一旦你通过逆向分析找到了TikTok确切的证书验证类（例如com.bytedance.okhttp3.internal.tls.CustomTrustManager），就应该替换为精确Hook，大幅提升性能和稳定性。
• 优化2：使用setImmediate或延迟Hook。有些类可能在脚本注入时还未被加载。可以将Hook代码包裹在setImmediate中，或者监听类加载事件。

  Java.perform(function() { // 等待类加载 Java.choose('com.bytedance.specific.TrustManager', { onMatch: function(instance) { console.log("[*] 找到目标TrustManager实例，开始Hook..."); // 在这里进行具体的Hook操作 }, onComplete: function() {} }); });

• 优化3：脚本容错。在每个try-catch块中记录更详细的错误信息，便于排查。避免因为一个Hook失败导致整个脚本停止运行。

6. 实战记录与效果验证

经过上述一系列配置和脚本注入，我在一台已Root、系统为MIUI 12的小米8上进行了实测。过程并非一帆风顺。

第一次尝试：仅配置代理和安装用户证书。结果：TikTok打开后无法刷新内容，Charles中看到少量TikTok域名请求，但全部是TLS Handshake Failure。结论：SSL Pinning生效。

第二次尝试：注入基础的SSL Pinning绕过脚本（仅Hook OkHttp的CertificatePinner）。结果：TikTok可以打开，但Charles里依然没有解密流量，且出现了更多unknown的TLS连接。结论：TikTok可能使用了自定义的TrustManager或Native库，基础的OkHttp Hook无效。

第三次尝试：注入“Hook全局TrustManager”的脚本。结果：Frida控制台刷出大量来自不同类（包括系统类和TikTok自身类）的[+] 绕过TrustManager检查日志。同时，Charles中开始出现大量可解密的TikTok请求，域名清晰可见（如api16-normal-c-useast1a.tiktokv.com）。成功！

验证数据：成功抓取到的请求包括视频流列表API、点赞、评论、用户信息等。响应体为清晰的JSON格式，可以分析其数据结构。这表明我们的脚本成功绕过了最主要的证书绑定机制。

后续问题：在滑动浏览一段时间后，偶尔会出现网络请求失败。推测可能是触发了基于行为的风控，或者是代理检测机制在后台周期性检查后生效。此时，结合注入“代理检测屏蔽脚本”，情况有所改善，但并未完全根除。这提示我们，对于像TikTok这样拥有强大安全团队的App，抓包与分析是一个持续的对抗过程，可能需要结合更动态的Hook策略、模拟真实用户行为等多种手段。

最后，我必须强调，所有技术都应用于合法合规的学习与研究目的，尊重软件的用户协议与版权，切勿用于侵犯他人隐私、破解商业软件或进行任何非法活动。抓包工具和Frida是安全研究人员和开发者的利器，正确使用它们可以帮助我们更好地理解应用工作原理、调试接口、提升安全意识。希望这篇基于小米8和TikTok的实战记录，能为你打开移动应用安全分析的大门，并提供一套可复现、可扩展的方法论。