小米8抓包TikTok失败？Frida脚本绕过SSL Pinning与代理检测实战

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。在手机连接的Wi-Fi设置中找到“代理”选项选择“手动”。主机名填写你的电脑IP192.168.1.100端口填写8888。保存。此时手机的所有HTTP流量理论上都会经过你的电脑。注意很多App包括TikTok会检测系统是否设置了代理。因此这一步配置后TikTok可能直接无法联网或行为异常。这正是我们需要用Frida去绕过的点之一。所以如果配置代理后TikTok打不开别慌这恰恰说明我们的方向对了。系统证书安装要让手机信任抓包工具伪造的证书必须将CA证书安装到系统信任区。在已Root的手机上最简单的方法是使用ADB命令。在抓包工具如Charles中导出根证书通常保存为charles-ssl-proxying-certificate.pem。使用OpenSSL或在线工具将其转换为DER格式charles.der因为Android系统证书需要特定的文件名和格式。通过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流量的核心。进入Proxy - SSL Proxying Settings。在SSL Proxying标签页勾选Enable SSL Proxying。在Locations列表中添加一条规则Host 为*Port 为*。这意味着Charles会尝试代理并解密所有HTTPS流量。设备连接验证完成手机代理配置后在手机上用浏览器访问一个HTTP网站如http://neverssl.com。Charles应该会立即弹出连接请求点击“Allow”。如果能成功抓到浏览器的明文请求说明手机到Charles的网络通路是正常的。这是后续所有工作的基石。2.3 Frida环境部署从安装到第一个HookFrida分为两部分PC端的Frida客户端frida-tools和运行在手机端的Frida服务端frida-server。PC端安装非常简单使用Python的pip包管理器即可。建议在虚拟环境中操作。pip install frida-tools安装完成后命令行输入frida --version验证。手机端部署这是关键步骤需要对应你的手机架构。去Frida的GitHub Releases页面找到与PC端frida-tools版本匹配的frida-server。小米8是高通骁龙845处理器是64位ARM架构应下载frida-server-xx.x.x-android-arm64.xz。解压得到frida-server-xx.x.x-android-arm64文件。通过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运行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设置中手动配置了代理服务器它可能会采取以下行为之一拒绝向配置的代理服务器发送任何流量导致Charles什么都抓不到。切换到使用自己的原生Socket直连绕过系统的代理设置。触发风控逻辑返回错误或空白数据。检测代理的方法多种多样。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的CertificatePinnerJava.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); });如何使用脚本确保手机上的Frida-server正在运行。在电脑上启动Charles并配置好SSL代理。在手机上设置好Wi-Fi代理指向Charles。在电脑命令行使用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观察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。可能原因2TikTok使用了纯Native的网络请求。例如通过libcronet.so这样的原生库发起请求我们的Java层Hook完全无效。应对这需要用到Frida的Native HookInterceptor。你需要逆向分析so库找到SSL连接或证书验证的函数如SSL_CTX_set_cert_verify_callback。这难度极大属于高级逆向范畴。折中方案尝试抓取DNS请求或使用更底层的抓包工具如tcpdump需Root在手机上直接抓取原始流量但得到的是加密的数据包。可能原因3Charles的SSL代理设置问题。排查确保Charles的SSL Proxying Settings中已经为*:*启用了代理。尝试关闭并重新打开Charles的SSL代理功能。重启Charles和手机。5.3 抓到的请求数据不完整或仍是乱码现象能抓到请求但响应体是乱码或者被压缩了。可能原因内容编码或压缩。解决在Charles中右键点击请求选择Enable SSL Proxying确保解密。对于乱码查看响应头的Content-Encoding如果是gzip或brBrotliCharles通常会自动解压显示。如果没有可以尝试在请求上右键选择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的实战记录能为你打开移动应用安全分析的大门并提供一套可复现、可扩展的方法论。