1. 项目概述：当Frida遇上Bilibili的反调试

在移动安全研究和逆向工程领域，绕过应用的反调试机制是一个经典且充满挑战的课题。这次，我们把目光聚焦在国民级应用Bilibili的Android客户端7.26.1版本上。这个版本集成了多种反调试技术，旨在阻止分析者通过调试器或动态插桩工具（如Frida）窥探其内部逻辑，尤其是在涉及核心业务、风控算法或会员权益验证等敏感模块时。对于安全研究员、逆向爱好者，甚至是希望理解应用如何保护自身逻辑的开发者来说，成功绕过这些防护，意味着能够深入分析其网络协议、加解密流程或关键业务函数。

Frida，作为一款强大的动态代码插桩框架，是我们手中的“瑞士军刀”。它允许我们在目标进程运行时注入JavaScript代码，从而Hook（挂钩）Java/Native函数、修改内存、甚至动态执行自定义逻辑。然而，Bilibili这样的应用不会坐以待毙，它会检测Frida的存在，一旦发现，轻则功能异常，重则直接崩溃退出。因此，我们的实战目标非常明确：在Bilibili 7.26.1应用运行的环境中，成功加载并运行Frida，使其无法被应用自身的检测机制发现，从而为后续的Hook和分析铺平道路。

这个过程不仅仅是运行一个脚本那么简单。它涉及到对Android应用安全机制的深刻理解，包括对反调试常见手法的识别、对Frida自身特征的分析，以及如何通过精巧的对抗手段实现“隐身”。最终，我们将得到一个完整的、可复现的Frida绕过脚本，它不仅能用于Bilibili 7.26.1，其思路和方法也能迁移到其他具有类似防护的应用上。接下来，我们将从设计思路开始，一步步拆解这场“猫鼠游戏”。

2. 核心思路与对抗策略设计

要成功绕过反调试，我们不能盲目地尝试，必须先理解对手的“防御工事”是如何构建的。Bilibili 7.26.1的反调试机制是一个多层次、立体化的防御体系，我们的对抗策略也需要相应地分层设计。

2.1 Bilibili反调试机制常见手法分析

根据对类似版本和行业通用手法的分析，Bilibili可能集成了以下几类反调试技术，我们的绕过方案需要逐一应对：

1. Frida特征检测：这是最直接的检测。应用会扫描进程的内存映射（/proc/self/maps）、已加载的库（/proc/self/task/pid/maps）或已打开的文件描述符（/proc/self/fd），寻找包含“frida”字符串的库文件（如libfrida-gadget.so）或特定端口（默认27042）。此外，还会检查是否存在Frida特有的线程名或环境变量。

2. 调试器状态检测：通过android.os.Debug.isDebuggerConnected()、ptrace自身进程（PTRACE_TRACEME）或读取/proc/self/status中的TracerPid字段，来判断是否有调试器附加。如果TracerPid不为0，则说明进程正在被跟踪。

3. 运行时间/指令周期检测：在关键代码路径上插入计时逻辑。如果某段代码的执行时间远超出正常范围（因为被调试器单步执行或下了断点），则触发反制措施。这种检测在Native（C/C++）层更为常见。

4. 完整性校验：对自身的DEX文件、SO库或关键类进行哈希校验，如果发现内存中的代码被修改（例如被Frida Hook），则判定为异常。这可能通过Java层的MessageDigest或Native层的自定义校验函数实现。

5. 环境异常检测：检查设备是否处于模拟器、是否Root、是否安装了Xposed或Magisk等框架，因为这些环境常与逆向分析相伴。Bilibili可能会结合多种特征进行综合风险评估。

我们的绕过策略核心是“隐藏与欺骗”。不是去强行关闭或删除这些检测代码（那会触发完整性校验），而是让这些检测逻辑在运行时“看到”一个“干净”的、符合预期的环境。

2.2 Frida隐身方案选型与考量

针对上述检测，我们有多种技术路径可选，每种都有其优缺点和适用场景：

• 方案一：修改Frida Server/ Gadget：直接修改Frida的核心二进制文件（frida-server或libfrida-gadget.so），将其中的特征字符串（如“frida”、“gum-js-loop”、“gmain”等）替换为无意义的随机字符串。这是最根本的方法，但需要一定的二进制修补能力，且每次Frida版本更新都可能需要重新适配。

  • 优点：效果彻底，从根源上隐藏。
  • 缺点：操作稍复杂，需处理ELF文件，且有版本依赖。

• 方案二：使用第三方强化工具：借助如objection（patchapk命令）、frida-unpack等工具，或在启动时加载一些现成的反反调试脚本（如frida-scripts仓库中的相关脚本）。这些工具通常自动化完成了一些隐藏工作。

  • 优点：快捷方便，适合快速验证。
  • 缺点：可能不够灵活，无法应对定制化较强的检测，且工具本身可能被加入特征库。

• 方案三：动态Hook与内存擦除：这是我们本次实战采用的核心方案。思路是：先让Frida正常附着到目标进程，然后第一时间（在应用的反调试代码执行前）通过Frida自身的能力，去Hook那些执行检测的关键系统函数（如open、read、fgets用于文件检测；getenv用于环境变量检测），并篡改其返回值，使其返回“干净”的结果。同时，我们还需要在内存中遍历并抹去Frida库和线程的明显特征。

  • 优点：灵活性强，可以针对特定应用的检测点进行精准打击。无需修改Frida二进制文件，通用性较好。
  • 缺点：属于“亡羊补牢”，需要在检测发生前完成Hook，对脚本的注入时机和稳定性要求高。

综合考量通用性、灵活性和学习价值，我们选择方案三作为本次实战的主线。我们将编写一个Frida JavaScript脚本，该脚本在注入后立即执行一系列隐藏操作。同时，为了应对更底层的ptrace或TracerPid检测，我们可能需要结合方案一的一些思路，或者使用frida-gadget的配置模式进行更深入的隐藏。

注意：所有逆向工程行为应仅用于学习、研究或安全评估自己拥有合法权限的应用程序。未经授权对他人软件进行逆向分析可能违反法律法规和服务条款。

3. 环境准备与工具配置

工欲善其事，必先利其器。一个稳定、配置正确的环境是成功绕过反调试的基础。这里我会详细列出每个步骤，并解释其作用，确保你可以完全复现。

3.1 基础环境搭建

1. 测试设备/模拟器：

   • 推荐使用Root过的真实Android手机：这是最接近用户真实环境且功能完整的测试平台。确保已开启USB调试（开发者选项）。
   • 备选：Android模拟器：如Android Studio自带的AVD。部分模拟器（如雷电模拟器）可能自带Root，但需要注意其内核和文件系统可能与真机有差异，可能导致某些检测行为不同。对于Bilibili这类应用，模拟器本身可能就是检测目标。
   • 本次实战环境示例：一台Root后的Android 10手机，Magisk管理Root权限。

2. 目标应用：

   • 从可靠渠道获取Bilibili 7.26.1的APK安装包。你可以使用apkpure.com等网站的历史版本库，或自己备份的旧版本APK。
   • 安装到测试设备上：adb install bilibili_7.26.1.apk。

3. Frida环境部署：

   • PC端（攻击机）：

     # 安装Frida客户端和工具包 pip install frida-tools # 安装用于解包/重打包的常用工具（可选，但推荐） pip install objection

   • Android设备端（目标机）：
     • 首先确定设备的CPU架构：adb shell getprop ro.product.cpu.abi。常见结果为arm64-v8a（64位ARM）或armeabi-v7a（32位ARM）。
     • 前往Frida的GitHub Releases页面，下载对应架构的frida-server文件，例如frida-server-16.1.4-android-arm64.xz。
     • 解压后推送到设备并赋予执行权限：

     adb push frida-server-16.1.4-android-arm64 /data/local/tmp/ adb shell "chmod 755 /data/local/tmp/frida-server-16.1.4-android-arm64"

   • 运行Frida Server：

     # 进入adb shell并切换到root权限（如果设备已root） adb shell su # 在后台运行frida-server，并重定向输出到空设备 /data/local/tmp/frida-server-16.1.4-android-arm64 &

     保持这个shell窗口打开，或使用nohup命令让其持续运行。

4. 验证连接：在PC端新开一个终端，运行frida-ps -U，如果能看到设备上的进程列表，说明Frida环境搭建成功。

3.2 辅助分析工具

在编写绕过脚本前，我们需要先对目标应用进行一番“侦察”，了解它可能在哪里布下了检测点。

1. Jadx-GUI：用于静态反编译APK，查看Java/Kotlin代码。我们可以搜索关键词如isDebuggerConnected、TracerPid、frida、调试、trace、ptrace、/proc/self等，来定位潜在的检测代码位置。
2. IDA Pro / Ghidra：用于分析Native层（SO库）的反调试逻辑。搜索字符串frida、gadget、27042，或分析JNI_OnLoad、init_array等初始化函数，以及fork、ptrace、syscall等系统调用。
3. Frida-f参数：在应用启动时立即注入，可以观察最早期的崩溃或日志，帮助判断反调试触发的时机。命令如：frida -U -f com.bilibili.app.in --no-pause。

实操心得：在真机上测试时，建议先卸载所有其他修改版或插件版的Bilibili，安装最干净的官方原版7.26.1。同时，关闭其他可能干扰的调试工具（如Charles、mitmproxy），确保环境单一，便于问题排查。

4. 反调试检测点定位与Hook策略

在环境准备好后，我们并不急于编写完整的绕过脚本。更聪明的做法是，先让应用“裸奔”一次，观察它在Frida附着下的反应，从而精准定位检测点。

4.1 动态侦察与行为观察

1. 启动并附着进程：

   # 方法A：启动应用并立即附着 frida -U -f com.bilibili.app.in --no-pause # 方法B：附着到已运行的应用（如果应用启动后才检测） frida -U com.bilibili.app.in

   如果应用在Frida附着后立即崩溃或无响应，这很可能就是反调试在起作用。查看logcat日志（adb logcat | grep -iE \"debug|trace|frida|security|crash\"）可能会发现一些线索，比如SecurityException或来自Bilibili自身Native库的崩溃信息。

2. 关键系统调用监控：我们可以先编写一个简单的Frida脚本来监控一些关键函数，看看应用启动时读了哪些文件、获取了哪些环境变量。

   // scout.js - 侦察脚本 Interceptor.attach(Module.findExportByName(null, "open"), { onEnter: function(args) { this.path = args[0].readCString(); // 过滤只关心/proc/self下的文件 if (this.path && this.path.includes("/proc/self")) { console.log(`[open] ${this.path}`); } } }); Interceptor.attach(Module.findExportByName(null, "fgets"), { onEnter: function(args) { this.buf = args[0]; this.size = args[1].toInt32(); this.stream = args[2]; }, onLeave: function(retval) { if (retval != 0) { var content = retval.readCString(); // 过滤包含frida、tracerpid等关键信息的读取 if (content && (content.includes("frida") || content.includes("tracerpid"))) { console.log(`[fgets]读到内容: ${content}`); } } } }); Interceptor.attach(Module.findExportByName(null, "getenv"), { onEnter: function(args) { this.name = args[0].readCString(); console.log(`[getenv]查询: ${this.name}`); } });

   使用frida -U -f com.bilibili.app.in -l scout.js --no-pause运行此脚本。观察控制台输出，如果发现应用频繁读取/proc/self/maps、/proc/self/status，或者查询某些特定环境变量，这些就是我们需要重点关照的检测点。

4.2 关键Hook点分析与确定

通过静态分析和动态侦察，我们通常可以确定以下几个必须Hook的关键函数，并制定相应的欺骗策略：

1. 文件读取相关：

   • open/openat：当路径包含/proc/self（尤其是maps，status，fd）时，我们需要考虑是否要返回一个假的文件描述符，或者通过Hook后续的read函数来返回伪造的内容。
   • read/fgets/fscanf：这是返回内容的关键节点。当读取/proc/self/status时，我们需要确保返回的字符串中TracerPid:\t0。当读取/proc/self/maps时，需要过滤掉所有包含frida、gadget、gum等字样的行。
   • fopen/fdopen：同open，是文件流打开的入口。

2. 进程信息相关：

   • android.os.Debug.isDebuggerConnected()：这是一个Java方法。我们需要Hook它并使其始终返回false。
   • ptrace：这是底层调试接口。应用可能调用ptrace(PTRACE_TRACEME, 0, 0, 0)来检测是否可以被跟踪。我们需要Hookptrace，当第一个参数是PTRACE_TRACEME（值为0）时，直接返回-1并设置errno（模拟操作失败），或者以某种方式绕过。

3. 环境变量与库枚举：

   • getenv：用于获取环境变量。如果应用检查FRIDA_SERVER等变量，我们需要返回NULL。
   • dl_iterate_phdr或/proc/self/maps的替代分析：应用可能遍历已加载的共享库。更彻底的做法是在内存中修改libfrida-gadget.so的库名和路径名（在.dynstr节），但这属于二进制修补范畴。在我们的动态Hook方案中，主要通过在read/fgets时过滤maps内容来实现隐藏。

4. 时间检测：Hookclock_gettime、gettimeofday或syscall（用于nanosleep）可能比较棘手，因为需要维护一个“正常”的时间流。一个更简单的思路是：如果发现应用因为时间检测而崩溃，可以尝试定位到进行时间比较的Native函数，直接Hook该比较逻辑，使其永远返回“未超时”的结果。

策略核心：我们的脚本将重点放在第1、2、3类检测上，因为它们最常见且相对容易通过Hook系统API来绕过。我们将编写一个在Process.attach或Java.perform早期就执行的脚本，抢先一步布置好所有这些“陷阱”。

5. 完整Frida绕过脚本编写与详解

下面，我将呈现完整的绕过脚本，并逐段解释其原理和实现细节。这个脚本整合了上述的对抗策略。

// bypass_bilibili_anti_debug_7.26.1.js // 作者：逆向老兵 // 描述：针对Bilibili 7.26.1 Android客户端的综合反调试绕过脚本 Java.perform(function () { console.log(\"[*] 脚本已注入，开始布置反反调试陷阱...\"); // ==================== 1. 绕过Java层调试检测 ==================== var Debug = Java.use(\"android.os.Debug\"); Debug.isDebuggerConnected.implementation = function () { console.log(\"[+] Hooked android.os.Debug.isDebuggerConnected()， 返回 false\"); return false; }; // ==================== 2. 关键Native函数Hook ==================== // 获取libc.so模块，大多数系统调用都在这里 var libc = Module.findBaseAddress(\"libc.so\"); if (libc) { console.log(\"[*] libc.so 基址: \" + libc); // --- Hook open/openat --- var openAddr = Module.findExportByName(\"libc.so\", \"open\"); var openatAddr = Module.findExportByName(\"libc.so\", \"openat\"); // 注意：Android 7.0以上，系统调用open可能被openat替代，最好都Hook if (openAddr) { Interceptor.attach(openAddr, { onEnter: function (args) { var pathPtr = args[0]; if (!pathPtr.isNull()) { var path = pathPtr.readCString(); this.path = path; // 如果路径是我们要隐藏的/proc/self下的关键文件 if (path && path.includes(\"/proc/self\")) { console.log(\"[!] 检测到打开敏感文件: \" + path); // 我们可以在这里做标记，但不在onEnter中阻止打开。 // 真正的篡改发生在read/fgets中。 } } }, onLeave: function (retval) { // 可以在这里记录文件描述符，但非必需 } }); console.log(\"[+] Hooked open()\"); } if (openatAddr) { Interceptor.attach(openatAddr, { // 实现逻辑与open类似，略 onEnter: function (args) { /* ... */ }, onLeave: function (retval) { /* ... */ } }); console.log(\"[+] Hooked openat()\"); } // --- Hook read --- var readAddr = Module.findExportByName(\"libc.so\", \"read\"); if (readAddr) { Interceptor.attach(readAddr, { onEnter: function (args) { this.fd = args[0].toInt32(); this.buf = args[1]; this.count = args[2].toInt32(); // 我们无法在此处知道fd对应什么文件，需要结合上下文。 // 更精准的做法是Hook fgets或监控特定的fd。 }, onLeave: function (retval) { // 通用的read篡改比较困难，优先使用fgets } }); } // --- Hook fgets --- 这是最关键的一环！ var fgetsAddr = Module.findExportByName(\"libc.so\", \"fgets\"); if (fgetsAddr) { Interceptor.attach(fgetsAddr, { onEnter: function (args) { this.buf = args[0]; this.size = args[1].toInt32(); this.stream = args[2]; }, onLeave: function (retval) { // retval是返回的指针，如果为NULL表示读取出错或EOF if (!retval.isNull()) { var originalContent = retval.readCString(); var newContent = originalContent; // 场景1：过滤/proc/self/maps中的Frida痕迹 if (originalContent && originalContent.includes(\"frida\")) { console.log(\"[!] 过滤maps中的frida行: \" + originalContent.trim()); newContent = \"\"; // 返回空行，相当于过滤掉这一行 retval.writeUtf8String(newContent + \"\\n\"); // 重写缓冲区 } // 场景2：篡改/proc/self/status中的TracerPid if (originalContent && originalContent.startsWith(\"TracerPid:\")) { console.log(\"[!] 篡改TracerPid为0，原内容: \" + originalContent.trim()); newContent = \"TracerPid:\\t0\"; retval.writeUtf8String(newContent + \"\\n\"); } // 可以添加更多过滤规则，如包含“gadget”、“gum-js-loop”等 if (originalContent && (originalContent.includes(\"gadget\") || originalContent.includes(\"gum-js-loop\"))) { console.log(\"[!] 过滤可疑库/线程行: \" + originalContent.trim()); newContent = \"\"; retval.writeUtf8String(newContent + \"\\n\"); } } } }); console.log(\"[+] Hooked fgets()， 已启用内容过滤\"); } // --- Hook getenv --- var getenvAddr = Module.findExportByName(\"libc.so\", \"getenv\"); if (getenvAddr) { Interceptor.attach(getenvAddr, { onEnter: function (args) { this.varName = args[0].readCString(); }, onLeave: function (retval) { if (this.varName && retval) { // 如果查询FRIDA相关的环境变量，返回NULL var name = this.varName.toLowerCase(); if (name.includes(\"frida\")) { console.log(\"[!] 拦截getenv查询: \" + this.varName + \"， 返回NULL\"); // 将返回值替换为NULL (0) return 0; // 注意：直接return 0会替换原返回值 } } } }); console.log(\"[+] Hooked getenv()\"); } // --- Hook ptrace --- var ptraceAddr = Module.findExportByName(\"libc.so\", \"ptrace\"); if (ptraceAddr) { Interceptor.attach(ptraceAddr, { onEnter: function (args) { this.request = args[0].toInt32(); // PTRACE_TRACEME 定义为0，表示进程请求被跟踪 if (this.request === 0) { // 通常定义为 PTRACE_TRACEME console.log(\"[!] 检测到 ptrace(PTRACE_TRACEME, ...)， 尝试绕过\"); // 一种方法是直接让调用失败，返回-1并设置errno // 但更隐蔽的做法是让它“成功”，但实际不做任何事情。 // 这里我们选择返回0（成功），但需要小心后续影响。 // 另一种思路是修改request参数，但更复杂。 // 我们先返回0，观察是否稳定。 } }, onLeave: function (retval) { // 如果request是PTRACE_TRACEME，强制返回0 if (this.request === 0) { // 注意：直接修改返回值 // retval在onLeave中是一个NativePointer，代表返回的long值 // 我们需要替换这个返回值。在Frida中，可以通过修改retval指向的内存吗？不行。 // 正确做法是在onEnter中替换参数或抛出异常？更常见的做法是让调用“失败”。 // 让我们换一种思路：在onEnter中直接返回，跳过原函数执行。 // 但Interceptor.attach的onEnter里不能直接return值。 // 因此，我们需要使用Interceptor.replace来完全替换函数。 // 由于篇幅，这里先注释，下文提供replace方案。 } } }); console.log(\"[+] Hooked ptrace()\"); } } else { console.log(\"[!] 警告：未找到libc.so，Native Hook可能部分失效\"); } // ==================== 3. 替换ptrace函数实现 ==================== // 由于ptrace的Hook需要更精细的控制，我们使用Interceptor.replace var ptraceAddr = Module.findExportByName(\"libc.so\", \"ptrace\"); if (ptraceAddr) { // 保存原始函数指针，如果需要调用原函数的话 var origPtrace = new NativeFunction(ptraceAddr, 'long', ['int', 'int', 'void*', 'void*']); // 替换实现 Interceptor.replace(ptraceAddr, new NativeCallback(function (request, pid, addr, data) { // 如果是PTRACE_TRACEME请求，直接返回“成功”(0)，但实际不执行任何操作 if (request === 0) { // PTRACE_TRACEME console.log(\"[+] 拦截并绕过 ptrace(PTRACE_TRACEME, ...)\"); return 0; // 返回0表示成功，但进程并未被真正跟踪 } // 对于其他ptrace请求，调用原始函数 console.log(`[*] ptrace 其他请求: request=${request}, pid=${pid}`); return origPtrace(request, pid, addr, data); }, 'long', ['int', 'int', 'pointer', 'pointer'])); console.log(\"[+] 已替换 ptrace() 实现\"); } // ==================== 4. 内存遍历与特征擦除（进阶） ==================== // 遍历所有已加载的模块，寻找并重命名Frida相关的模块（风险较高，仅供参考） // Process.enumerateModules({ // onMatch: function (module) { // var name = module.name; // if (name && name.toLowerCase().indexOf(\"frida\") !== -1) { // console.log(\"[*] 发现Frida相关模块: \" + name + \" @ \" + module.base); // // 注意：直接修改内存中的库名字符串可能不稳定，且需要处理字符串只读等问题。 // // 这是一个高风险操作，可能导致崩溃。通常更推荐用maps过滤的方式。 // } // }, // onComplete: function () { } // }); console.log(\"[*] 所有反反调试Hook布置完成！\"); console.log(\"[*] 现在可以尝试使用Frida进行常规操作了。\"); }); // 脚本加载后立即执行的代码（在Java.perform之外） console.log(\"[*] Bilibili 7.26.1 反调试绕过脚本加载完毕。\");

脚本详解与注意事项：

1. 执行顺序：脚本被注入后，首先执行最外层的console.log，然后进入Java.perform确保在Java运行时环境中执行。我们首先Hook Java层的isDebuggerConnected，因为这是最常见的检测，且必须在任何Java代码调用它之前完成Hook。

2. Native Hook的时机：在Java.perform内部进行Native Hook是安全的。我们通过Module.findBaseAddress(\"libc.so\")获取libc的基址，然后查找各个导出函数。

3. fgetsHook的精髓：这是绕过/proc/self/maps和/proc/self/status检测的核心。我们并不阻止应用打开这些文件，而是在它读取每一行内容时进行“实时过滤”。当发现包含frida、TracerPid:等关键词的行时，我们直接修改read函数返回的缓冲区内容。对于maps，我们将包含frida的行清空（返回空行）；对于status，我们将TracerPid:后面的值改为0。

4. getenvHook：直接判断查询的变量名是否包含frida（不区分大小写），如果是，则让函数返回NULL（即0）。注意，在onLeave回调中，我们使用return 0;来覆盖原始返回值。这要求回调函数声明了返回值类型（这里Frida的Interceptor会自动处理）。

5. ptrace的完全替换：简单的Interceptor.attach难以完美处理ptrace的返回值覆盖。我们使用Interceptor.replace配合NativeCallback，完全自定义ptrace函数的行为。当请求是PTRACE_TRACEME（值为0）时，直接返回0（成功），但实际不执行任何跟踪操作，从而骗过检测。对于其他ptrace请求，则调用原始函数，避免影响系统其他正常功能。

6. 内存擦除（注释部分）：遍历模块并修改库名是更激进的做法，但操作不当极易导致崩溃，因为涉及对只读内存段的修改。对于大多数情况，通过fgets过滤maps已经足够。因此这部分代码被注释，仅作为高级思路展示。

重要提示：这个脚本是一个综合性的“盾牌”，可能无法应对所有变种或未来版本的反调试。实际使用时，可能需要根据logcat报错或崩溃点，动态调整和增加Hook点。例如，如果应用使用了fopen+fread组合，你可能需要额外Hookfread。如果应用直接使用syscall进行读取，你可能需要Hooksyscall函数本身。

6. 脚本使用、测试与问题排查

编写完脚本后，真正的挑战在于如何让它稳定工作，并验证绕过是否成功。

6.1 脚本的使用方法

1. 保存脚本：将上述完整脚本保存为bypass_bilibili.js。

2. 启动Frida Server：确保设备上的frida-server正在运行（见3.1节）。

3. 注入脚本：

   • 方法一：在应用启动时注入（推荐，能捕获最早期的检测）

     frida -U -f com.bilibili.app.in -l bypass_bilibili.js --no-pause

     -f表示启动应用，-l表示加载脚本，--no-pause表示立即启动主线程。
   • 方法二：附加到已运行的应用

     # 先启动Bilibili应用 # 然后附加 frida -U com.bilibili.app.in -l bypass_bilibili.js

4. 验证与后续操作：如果脚本注入成功，你将在Frida CLI中看到[*] 所有反反调试Hook布置完成！的提示，并且应用没有崩溃。此时，你可以尝试执行其他Frida命令或脚本，例如枚举类、Hook业务函数等，来验证Frida的功能是否正常。

6.2 测试绕过是否成功

仅仅应用不崩溃还不够，我们需要一些正向的证据表明反调试已被绕过。

1. 主动调用检测函数：在Frida交互模式下，尝试主动调用一些检测函数，看返回值是否被我们成功篡改。

   // 在Frida CLI中执行 Java.perform(function() { var isDebugged = Java.use(\"android.os.Debug\").isDebuggerConnected(); console.log(\"isDebuggerConnected() 返回: \" + isDebugged); // 应该输出 false });

2. 监控关键文件读取：可以稍微修改我们的绕过脚本，在过滤的同时，打印出应用读取/proc/self/status和/proc/self/maps的“净化后”的内容，确认TracerPid为0且没有Frida库。

   // 在fgets的onLeave回调中添加调试输出 onLeave: function(retval) { if (!retval.isNull()) { var content = retval.readCString(); if (content && content.includes(\"TracerPid\")) { console.log(\"[DEBUG] 返回的status行: \" + content); } // ... 原有的过滤逻辑 } }

3. 进行正常的逆向操作：尝试Hook一个简单的、无伤大雅的函数，比如java.lang.String.toString()，看是否能成功打印日志。这是最终极的测试。

6.3 常见问题与排查实录

在实际操作中，你可能会遇到各种问题。以下是我踩过的一些坑和解决方案：

• 问题一：注入脚本后应用立即崩溃

  • 可能原因1：Hook的函数不对或参数处理错误。比如在getenv的onLeave中错误地操作了返回值。排查：逐一注释掉脚本中的Hook块（从ptrace开始），采用二分法定位导致崩溃的Hook点。
  • 可能原因2：脚本注入时机太晚。反调试代码可能在JNI_OnLoad或很早的Native初始化中就执行了。解决：尝试将脚本编译成frida-gadget，并嵌入到APK中，实现更早的加载（这是更高级的用法）。或者使用frida -U -f --no-pause尽早注入。
  • 可能原因3：应用有完整性校验。我们的Hook修改了内存或行为，触发了校验。排查：观察崩溃栈，看是否发生在某个校验函数中。可能需要绕过校验逻辑，这通常更复杂。

• 问题二：应用没有崩溃，但Frida一执行其他命令（如Java.choose）就崩溃

  • 可能原因：反调试可能是延迟触发的，或者存在于某个特定的线程中。我们的通用Hook可能没有覆盖到所有检测路径。解决：使用frida-trace跟踪所有文件打开和读取操作，观察崩溃前应用最后读取了哪个敏感文件或调用了哪个敏感函数，然后针对性加强Hook。

• 问题三：fgetsHook似乎没有生效

  • 可能原因1：应用使用了read、fscanf或直接syscall来读取文件，而不是fgets。解决：补充Hookread和__read_chk等函数。在read的onLeave中，我们需要知道当前的文件描述符fd对应什么文件，这可以通过监控open的返回值和fd的对应关系来实现（建立一个fd->path的映射表），逻辑会更复杂。
  • 可能原因2：/proc/self/maps的内容被缓存了。应用可能只读一次然后缓存起来。解决：尝试在应用启动后，强制刷新其缓存（比如发送特定信号或触发特定功能），或者寻找更底层的读取点。

• 问题四：绕过后，应用部分功能异常（如无法登录、播放卡顿）

  • 可能原因：我们的Hook过于激进，影响到了应用正常的文件或系统调用。例如，我们过滤了所有包含“frida”的行，但如果应用自身某个非敏感库的路径凑巧包含“frida”字样（极罕见），就会被误伤。解决：精细化过滤规则，确保只过滤绝对确定的威胁路径（如/data/local/tmp/frida、/data/app/.../libfrida等）。

一个实用的调试技巧：在脚本开头加入console.log(\"[*] PID: \" + Process.id);，并同时使用adb logcat | grep -A 10 -B 10 <PID>来监控目标进程的所有日志，这能帮助你发现应用内部打印的崩溃或警告信息，是定位问题的宝贵线索。

7. 脚本的优化与扩展思路

基础的绕过脚本工作后，我们可以考虑让它更健壮、更隐蔽。

1. 精细化maps过滤：不要简单地清空整行。可以解析maps的每一行，只修改“库文件路径”那一列，将其中的frida替换为随机字符串，同时保持内存地址区间和权限不变，这样更不容易被基于格式的检测发现。

2. 对抗内存扫描：除了文件检测，高级反调试可能会直接扫描进程内存空间寻找Frida代码的特征字节序列。对抗方法包括：修改frida-gadget的二进制文件，改变其特征码；或者使用Frida的Stalker功能动态混淆代码。

3. 定时检测与恢复：反调试可能不是一次性的，而是定时循环检测。我们的脚本可以设置一个定时器（setInterval），定期检查关键检测函数是否被恢复（例如通过Debug.isDebuggerConnected的implementation属性），如果被恢复则重新Hook。

4. 针对特定SO库的Hook：Bilibili的反调试逻辑很可能封装在自家的某个SO库中（名字可能包含security、shield、protect等）。使用IDA或Ghidra静态分析这些库，找到它们内部的检测函数（如anti_debug_check、detect_frida），直接Hook这些自定义函数，往往比Hook广泛的libc函数更精准、更高效。

5. 使用frida-gadget的嵌入模式：将libfrida-gadget.so重命名为libxxx.so，并修改其DT_SONAME，然后通过修改APK的AndroidManifest.xml或libmain.so的初始化数组，使其在应用启动时自动加载。这种方式加载的Frida，其进程名、端口等特征都可以自定义，隐蔽性极高。但这涉及到APK的重打包和签名绕过，是另一个层面的对抗。

绕过反调试是一场持续的攻防战。Bilibili等大型应用的安全团队会不断更新其检测方案。今天有效的脚本，明天可能就会失效。因此，理解原理比记住脚本更重要。掌握静态分析定位检测点、动态调试验证猜想、编写精准Hook脚本的能力，才能在这个领域保持“战斗力”。希望这篇详尽的实战记录，能为你打开Android逆向中反调试对抗的大门。记住，保持好奇心，耐心分析，大胆实践，但始终在法律和道德的边界内进行。