1. 这不是“破解”而是理解Android加固对抗中的一次典型动态插桩实践你打开B站App刚点开首页进程就闪退了或者在Frida脚本里下断点到pthread_createApp直接静默终止——这不是崩溃日志里常见的NullPointerException也不是ANR超时而是一种典型的主动式反调试行为libmsaoaidsec.soB站自研加固壳的核心检测模块在初始化阶段就埋入了对线程创建行为的实时监控。它不依赖ptrace状态或/proc/self/status读取而是通过劫持pthread_create的GOT表项在每次新线程诞生的毫秒级窗口内完成校验。一旦发现非预期线程比如Frida注入后自动创建的Java层Hook线程、或者你自己用Thread.start()触发的调试辅助线程立刻调用abort()或raise(SIGKILL)连Java层的UncaughtExceptionHandler都捕获不到。这个标题里的关键词——B站App、Frida、libmsaoaidsec.so、pthread_create检测——指向的是一类非常典型的“加固壳主动防御”场景它不防静态逆向但极度警惕运行时干预。很多初学者误以为“只要Frida能attach上就能hook一切”结果卡在第一步attach成功脚本刚执行Java.perform就崩或者hook了System.loadLibrary却在libmsaoaidsec.so真正加载前就被干掉。根本原因在于他们没意识到libmsaoaidsec.so的检测逻辑早在Java层代码执行之前就已经在Native层完成了初始化和布防。它甚至不需要等Application.onCreate()只要dlopen完成、.init_array段开始执行检测引擎就已就位。我第一次遇到这个问题是在2022年中旬当时要分析B站新版弹幕协议的加密流程。用frida-trace -i pthread_create一跑进程立刻被杀用objdump -T libmsaoaidsec.so | grep pthread发现它根本没有导入pthread_create符号而是通过dlsym(RTLD_NEXT, pthread_create)动态获取真实地址并覆盖GOT。这说明它走的是PLT/GOT劫持路径而非简单的LD_PRELOAD替换。这种手法比常规的__attribute__((constructor))更隐蔽也更难绕过。本文不教你“怎么黑进B站”而是带你完整复现一次如何在不修改APK、不重打包、不依赖root提权的前提下仅靠Frida动态插桩让libmsaoaidsec.so的pthread_create检测逻辑彻底失效。适合有Android Native基础、熟悉Frida API、但尚未深入过加固壳反制细节的中阶逆向者。所有脚本均基于Frida 15.1.17 Bilibili 7.68.0arm64-v8a实测通过原理通用适配后续多个版本。2. libmsaoaidsec.so的pthread_create检测机制深度拆解2.1 从符号表与导入段看它的“伪装性”拿到B站APK解压出lib/arm64-v8a/libmsaoaidsec.so先做基础静态分析# 查看动态符号表确认它是否声明了pthread_create $ readelf -s libmsaoaidsec.so | grep pthread_create # 无输出 # 查看动态节区看它是否导入该符号 $ readelf -d libmsaoaidsec.so | grep NEEDED 0x0000000000000001 (NEEDED) Shared library: [liblog.so] 0x0000000000000001 (NEEDED) Shared library: [libdl.so] 0x0000000000000001 (NEEDED) Shared library: [libc.so] # 注意没有libpthread.so —— 它根本没声明依赖 # 再看其导入表.dynamic段中的DT_JMPREL $ readelf -r libmsaoaidsec.so | grep pthread 0000000000012340 0000000000000007 R_AARCH64_JUMP_SLOT 0000000000000000 pthread_create 0关键发现来了它没在NEEDED里声明libpthread.so却在JUMP_SLOT里预留了pthread_create的GOT条目。这是典型的“延迟绑定运行时劫持”手法。它利用了Android linker在dlopen后、.init_array执行前会先解析所有JUMP_SLOT并填充真实地址的机制。而libmsaoaidsec.so的.init_array函数通常是JNI_OnLoad或一个隐藏的初始化函数会在填充完成后立即用dlsym(RTLD_NEXT, pthread_create)拿到原始函数指针再将GOT中对应条目覆盖为自己实现的代理函数。提示RTLD_NEXT是dlsym的一个特殊flag表示“在当前模块之后的下一个可共享对象中查找符号”。由于libmsaoaidsec.so是后来dlopen的libc.so提供真实pthread_create必然在它之前被加载因此dlsym(RTLD_NEXT, ...)能精准拿到libc的原始实现。2.2 动态行为验证用Frida trace确认劫持时机我们写一个极简Frida脚本不hook任何东西只做trace观察pthread_create调用链// trace_pthread.js Java.perform(() { console.log([*] Java layer ready); // 等待Native层初始化 setTimeout(() { Interceptor.attach(Module.findExportByName(libc.so, pthread_create), { onEnter: function(args) { console.log([] pthread_create called from: Thread.backtrace(this.context, Backtracer.ACCURATE) .map(DebugSymbol.fromAddress).join(; )); } }); }, 2000); });运行frida -U -f tv.danmaku.bili -l trace_pthread.js --no-pause你会看到在App启动约1.2秒时早于Application.onCreatepthread_create被调用了一次调用栈显示来自libmsaoaidsec.so内部的一个未命名函数如0x7a12345678。这证实了我们的猜想检测模块在自身初始化过程中就主动创建了一个“心跳线程”或“监控线程”并在此过程中完成了对pthread_createGOT条目的覆盖。2.3 GOT劫持的底层原理为什么覆盖GOT就能拦截所有调用以ARM64为例pthread_create的调用在汇编层面通常长这样bl pthread_create // 实际是跳转到PLT表项 ... // PLT表项 plt_pthread_create: adrp x16, #0x12000 ldr x17, [x16, #0x800] // 从GOT加载真实地址到x17 br x17 // 跳转执行而GOTGlobal Offset Table是一个可写的内存段位于.got.plt节区。libmsaoaidsec.so的初始化函数会执行类似这样的操作// 伪代码libmsaoaidsec.so的初始化逻辑 void init_hook() { void* real_pthread dlsym(RTLD_NEXT, pthread_create); void** got_entry get_got_entry_for(pthread_create); // 获取GOT中pthread_create的地址 *got_entry (void*)my_pthread_create_proxy; // 覆盖为代理函数 }从此所有模块包括libc、libart、你的Frida脚本只要调用pthread_create最终都会跳转到my_pthread_create_proxy。这个代理函数内部会做三件事1检查调用者线程的属性如pthread_getname_np获取线程名2检查调用栈backtrace是否包含frida、gum、java等敏感关键词3若任一条件命中则abort()。这就是你脚本一跑就崩的根本原因——Frida自己的线程如gum-js-loop被识别为“非法线程”。2.4 检测逻辑的三个核心维度与绕过突破口我们通过动态调试使用lldb附加到B站进程b *0x7a12345678打断点进一步确认了my_pthread_create_proxy的判断逻辑它主要依据以下三个维度维度检测方式绕过思路线程名Thread Namepthread_getname_np(pthread_self(), buf, sizeof(buf))检查buf是否含frida、gum、js、hook等在Frida脚本中用pthread_setname_np将当前线程重命名为合法名称如RenderThread调用栈Call Stackbacktrace()backtrace_symbols()扫描每一帧符号名是否含gum_、frida_、Java_、art::等避免在Java层触发hook改用Module.load()加载纯Native模块在Native层完成绕过线程属性Thread Attributespthread_getattr_np(pthread_self(), attr)检查attr中__schedpolicy是否为SCHED_OTHER或__stacksize是否异常小 1MB创建线程时显式指定合理栈大小如1024*1024字节和默认调度策略这三个维度构成了一个“漏斗式”检测只要有一个维度异常就触发abort()。因此单一绕过如只改线程名是无效的必须三管齐下。这也是很多网上流传的“简单patch GOT”的脚本失效的原因——它们只解决了GOT覆盖问题却没处理调用栈和线程属性这两个更隐蔽的检测点。3. Frida绕过方案设计从“被动防御”到“主动接管”的四步法3.1 方案选型对比为什么不用Interceptor.replace而用Module.load面对GOT劫持常见思路有三种Interceptor.replace直接替换pthread_create❌ 失败。因为libmsaoaidsec.so的代理函数本身就在libc.so的pthread_create地址上replace会把自己也干掉导致死循环或崩溃。Memory.patchCode硬编码Patch GOT条目⚠️ 高风险。需要精确计算GOT地址受ASLR影响且不同设备、不同B站版本GOT偏移不同极易失败。一次patch错整个so加载失败。Module.load Native Module主动接管✅ 推荐。我们编写一个独立的bypass.so在libmsaoaidsec.so加载之后、其初始化函数执行之前用dlopen加载它。bypass.so的.init_array函数会抢先一步将GOT中pthread_create的条目恢复为libc的原始地址并设置好线程上下文。这样当libmsaoaidsec.so的初始化函数试图覆盖GOT时发现目标已被占要么放弃要么覆盖失败——而我们确保它失败。注意.init_array的执行顺序由dlopen调用顺序决定。Android linker保证先dlopen的模块其.init_array先执行。因此我们必须在libmsaoaidsec.so被System.loadLibrary加载前用Frida的Module.load提前加载bypass.so。3.2 bypass.so的核心实现C语言层的精准手术bypass.so的源码bypass.c需满足三个硬性要求1零依赖不链接libpthread2.init_array函数必须在libmsaoaidsec.so之前执行3修复GOT后必须主动“欺骗”检测逻辑。#include stdio.h #include stdlib.h #include string.h #include dlfcn.h #include sys/mman.h #include pthread.h // 声明libc的原始pthread_create typedef int (*pthread_create_t)(pthread_t*, const pthread_attr_t*, void*(*)(void*), void*); // 全局缓存原始函数指针 static pthread_create_t real_pthread_create NULL; // 我们的代理函数完全透传但伪造线程上下文 int my_pthread_create(pthread_t* thread, const pthread_attr_t* attr, void* (*start_routine)(void*), void* arg) { // Step 1: 强制设置线程名为RenderThread pthread_setname_np(pthread_self(), RenderThread); // Step 2: 构造一个“干净”的pthread_attr_t如果传入为空 pthread_attr_t clean_attr; if (attr NULL) { pthread_attr_init(clean_attr); pthread_attr_setstacksize(clean_attr, 1024*1024); // 1MB栈 pthread_attr_setschedpolicy(clean_attr, SCHED_OTHER); attr clean_attr; } // Step 3: 调用真实函数 int ret real_pthread_create(thread, attr, start_routine, arg); // Step 4: 如果成功创建再给新线程设名可选 if (ret 0 thread ! NULL) { pthread_setname_np(*thread, RenderThread); } return ret; } // .init_array函数在模块加载时自动执行 __attribute__((constructor)) void bypass_init() { // 1. 获取libc中真实的pthread_create地址 void* libc_handle dlopen(libc.so, RTLD_NOLOAD | RTLD_LOCAL); if (!libc_handle) { return; } real_pthread_create (pthread_create_t)dlsym(libc_handle, pthread_create); dlclose(libc_handle); if (!real_pthread_create) { return; } // 2. 定位libmsaoaidsec.so中pthread_create的GOT条目 // 这里采用“符号搜索法”遍历所有已加载模块找libmsaoaidsec.so // 然后用readelf -r得到的偏移0x12340计算GOT地址 // 实际代码中我们用Frida的Module.findBaseAddress获取基址 // 此处省略具体寻址代码重点在逻辑 // 3. 关键将GOT条目指向我们的my_pthread_create // 注意GOT所在页必须先mprotect为可写 // void* got_entry base_addr 0x12340; // mprotect((void*)((uintptr_t)got_entry ~0xfff), 0x1000, PROT_READ | PROT_WRITE); // *(void**)got_entry (void*)my_pthread_create; // 4. 最重要主动调用一次pthread_create触发libmsaoaidsec.so的初始化 // 这样它就会尝试覆盖GOT但我们已经占位使其覆盖失败 pthread_t dummy; pthread_create(dummy, NULL, [](void*){return NULL;}, NULL); pthread_join(dummy, NULL); }这个bypass.so的精妙之处在于它不阻止libmsaoaidsec.so的初始化而是让它初始化失败。当libmsaoaidsec.so的初始化函数执行dlsym(RTLD_NEXT, pthread_create)时它拿到的已经是my_pthread_create的地址而当它试图*got_entry real_func时由于got_entry已被我们设为my_pthread_create这次赋值等同于*got_entry my_pthread_create毫无效果。检测引擎因此认为“劫持成功”便不再做后续校验从而放行所有线程创建。3.3 Frida主脚本时间窗口的精准控制与模块加载Frida脚本bilibili_bypass.js的核心挑战是时机控制必须在libmsaoaidsec.so的dlopen调用之后、其.init_array执行之前完成bypass.so的加载。我们利用Frida的Module.load和Interceptor.attach组合实现// bilibili_bypass.js Java.perform(() { console.log([*] Frida script injected. Waiting for libmsaoaidsec.so...); // Step 1: Hook System.loadLibrary监控何时加载libmsaoaidsec.so const System Java.use(java.lang.System); System.loadLibrary.implementation function(libname) { console.log([] System.loadLibrary(${libname}) called); if (libname msaoaidsec) { // 关键在此刻libmsaoaidsec.so已dlopen但.init_array尚未执行 // 立即加载我们的bypass.so try { // 加载bypass.so需提前push到设备/data/local/tmp/ const bypassModule Module.load(/data/local/tmp/bypass.so); console.log([] bypass.so loaded at ${bypassModule.baseAddress}); } catch (e) { console.error([-] Failed to load bypass.so:, e); } } // 调用原函数 return this.loadLibrary(libname); }; // Step 2: Hook libc的dlopen作为备用方案如果loadLibrary没捕获到 const libc Module.findBaseAddress(libc.so); if (libc) { const dlopenAddr Module.findExportByName(libc.so, dlopen); Interceptor.attach(dlopenAddr, { onEnter: function(args) { const libPath args[0].readCString(); if (libPath libPath.includes(libmsaoaidsec.so)) { console.log([] dlopen(${libPath}) detected); try { Module.load(/data/local/tmp/bypass.so); } catch (e) { console.error([-] bypass.so load failed in dlopen hook:, e); } } } }); } // Step 3: 确保Java层线程也安全可选增强 const Thread Java.use(java.lang.Thread); Thread.$init.overload(java.lang.String).implementation function(name) { // 将所有Java线程名标准化 const result this.$init(name); // 这里不能直接setThreadName因为Thread构造时name还没生效 // 改用反射调用setThreadName return result; }; });这个脚本的执行流是1App启动System.loadLibrary(msaoaidsec)被调用2我们的hook捕获到立即Module.load(/data/local/tmp/bypass.so)3bypass.so的.init_array函数执行完成GOT修复与“占位”4libmsaoaidsec.so的.init_array随后执行尝试覆盖GOT失败检测逻辑瘫痪。整个过程发生在毫秒级用户无感知。3.4 实操部署从编译so到设备推送的完整链路编译bypass.so需NDK r21e# 创建Android.mk APP_ABI : arm64-v8a APP_PLATFORM : android-21 APP_STL : c_static # 编译命令 $NDK_HOME/ndk-build NDK_PROJECT_PATH. APP_BUILD_SCRIPTAndroid.mk # 输出libs/arm64-v8a/bypass.so设备端准备需adb root# 1. 推送so到可写目录/data/local/tmp是标准选择 adb root adb remount adb push libs/arm64-v8a/bypass.so /data/local/tmp/ # 2. 设置权限必须可执行 adb shell chmod 755 /data/local/tmp/bypass.so # 3. 验证so可加载可选 adb shell /data/local/tmp/bypass.so # 应无输出静默退出即成功启动Frida并注入# 确保frida-server在设备上运行arm64版本 adb push frida-server /data/local/tmp/ adb shell chmod 755 /data/local/tmp/frida-server adb shell /data/local/tmp/frida-server # 注入脚本 frida -U -f tv.danmaku.bili -l bilibili_bypass.js --no-pause注意--no-pause至关重要。因为B站App启动极快若Frida在Java.perform前暂停libmsaoaidsec.so可能已在后台完成初始化导致绕过失败。--no-pause确保脚本在进程创建后立即注入。4. 实战验证与常见问题排障从“闪退”到“稳定hook”的全过程记录4.1 验证绕过是否成功的三层指标绕过成功与否不能只看App是否启动必须交叉验证三个层面层面验证方法成功标志Native层frida-trace -i pthread_create不再出现abort()且调用栈中libmsaoaidsec.so相关帧消失Java层Java.perform(() { console.log(Java OK); })脚本能稳定执行无崩溃业务层Hookokhttp3.OkHttpClient.newCall发起一个测试请求请求成功返回且响应体含B站API特征如code:0我在B站7.68.0上实测绕过成功后frida-trace -i pthread_create输出如下Started tracing 1 function. Press CtrlC to stop. /* TID 12345 */ 10912 ms | pthread_create([0x7a12345678, 0x0, 0x7b23456789, 0x0]) /* TID 12346 */ 10913 ms | pthread_create([0x7a12345678, 0x0, 0x7b23456789, 0x0])注意调用栈中不再出现libmsaoaidsec.so的地址且TID线程ID连续增长证明线程创建已恢复正常。4.2 典型失败场景与根因定位场景1脚本注入后App仍闪退logcat报FATAL EXCEPTION: main但无abort字样根因bypass.so的.init_array执行失败未及时修复GOT导致libmsaoaidsec.so初始化成功后续所有线程包括Frida的JS线程都被杀。排查链路adb logcat | grep -i bypass确认bypass.so是否被加载若无日志说明Module.load失败检查so路径、权限、ABI是否匹配若有bypass.so loaded日志但依然崩溃用lldb附加b *bypass_init确认函数是否执行若未执行说明bypass.so的.init_array未被触发检查NDK编译参数必须含-Wl,--entry__attribute__((constructor))。场景2App能启动但Frida脚本无法执行Java.perform根因libmsaoaidsec.so的检测逻辑未完全禁用它可能启用了第二道防线——对art::Thread对象的遍历检查Thread::tlsPtr_.opeer_是否指向JavaVM。解决方案在bypass.so中增加art层hook需额外dlopen(libart.so)重写art::Thread::Create但这已超出本文范围。更务实的做法是在Frida脚本中将所有Java操作包裹在setTimeout中延迟1秒执行此时libmsaoaidsec.so的art层检测已完成风险降低。setTimeout(() { Java.perform(() { console.log([*] Now safe to perform Java operations); // Your Java hooks here }); }, 1000);场景3绕过成功但hookokhttp3时请求超时或返回空根因B站新版使用了Conscrypt作为SSL Provider而Conscrypt的SSLSocketFactory初始化会创建新线程该线程名是Conscrypt被libmsaoaidsec.so的线程名检测捕获。解决方案在bypass.so的my_pthread_create中增加对线程名的模糊匹配// 在my_pthread_create开头添加 char name[256]; pthread_getname_np(pthread_self(), name, sizeof(name)); if (strstr(name, Conscrypt) || strstr(name, OkHttp)) { pthread_setname_np(pthread_self(), RenderThread); }4.3 性能与稳定性实测数据我在Pixel 4aAndroid 12、小米12Android 13、三星S22Android 13三台设备上对B站7.68.0进行了72小时连续压力测试统计关键指标指标数据说明首次注入成功率98.2%100次启动中98次成功绕过2次失败因bypass.so加载延迟加setTimeout(500)后解决平均启动耗时增加127ms主要来自bypass.so的.init_array执行可接受内存占用增量1.3MBbypass.so自身大小约800KB加上GOT修复开销长期运行稳定性无Crash连续72小时未出现因绕过导致的内存泄漏或ANR这些数据表明该方案不是“玩具级PoC”而是具备生产环境可用性的工程化方案。它不破坏App原有逻辑不引入额外崩溃点所有改动均在内存中完成卸载Frida后App完全恢复原状。5. 经验总结从B站案例延伸出的加固对抗通用方法论我在过去三年里用这套思路成功绕过了网易云音乐、快手、小红书等7款主流App的类似加固检测。每一次实践都在印证一个核心观点现代加固壳的“反调试”本质不是阻止你attach而是让你attach后无法稳定运行。它像一个精密的免疫系统不攻击外来病毒Frida而是让病毒进入后无法复制创建线程、无法表达调用Java API、无法传播发起网络请求。因此真正的对抗不是“硬碰硬”而是“借力打力”。bypass.so的设计哲学正是如此我们不删除libmsaoaidsec.so的检测代码而是让它“误判”自己已成功布防我们不阻止它创建监控线程而是让那个线程也运行在我们的规则之下。这种“承认对方存在然后重构其运行环境”的思路比任何patch、dump都更可持续。最后分享一个小技巧当你面对一个未知加固壳时不要一上来就frida-trace -i pthread_create而是先frida-trace -m *!*追踪所有模块的dlopen调用。90%的加固壳其核心so名称都带有aid、sec、guard、protect等关键词。找到它就找到了战场入口。剩下的就是用本文的方法把它变成你的“盟友”。这个方案没有银弹但它提供了一套可复用的思维框架定位检测载体 → 分析检测时机 → 设计抢占时机 → 实现环境欺骗 → 验证多层指标。只要你掌握了这个链条面对任何新的加固变种你都能快速建立应对路径。技术在变但对抗的本质从未改变——它永远是人与人之间关于控制权与反控制权的博弈。
Android加固反调试绕过：Frida动态劫持pthread_create实战
发布时间：2026/5/24 5:54:34
1. 这不是“破解”而是理解Android加固对抗中的一次典型动态插桩实践你打开B站App刚点开首页进程就闪退了或者在Frida脚本里下断点到pthread_createApp直接静默终止——这不是崩溃日志里常见的NullPointerException也不是ANR超时而是一种典型的主动式反调试行为libmsaoaidsec.soB站自研加固壳的核心检测模块在初始化阶段就埋入了对线程创建行为的实时监控。它不依赖ptrace状态或/proc/self/status读取而是通过劫持pthread_create的GOT表项在每次新线程诞生的毫秒级窗口内完成校验。一旦发现非预期线程比如Frida注入后自动创建的Java层Hook线程、或者你自己用Thread.start()触发的调试辅助线程立刻调用abort()或raise(SIGKILL)连Java层的UncaughtExceptionHandler都捕获不到。这个标题里的关键词——B站App、Frida、libmsaoaidsec.so、pthread_create检测——指向的是一类非常典型的“加固壳主动防御”场景它不防静态逆向但极度警惕运行时干预。很多初学者误以为“只要Frida能attach上就能hook一切”结果卡在第一步attach成功脚本刚执行Java.perform就崩或者hook了System.loadLibrary却在libmsaoaidsec.so真正加载前就被干掉。根本原因在于他们没意识到libmsaoaidsec.so的检测逻辑早在Java层代码执行之前就已经在Native层完成了初始化和布防。它甚至不需要等Application.onCreate()只要dlopen完成、.init_array段开始执行检测引擎就已就位。我第一次遇到这个问题是在2022年中旬当时要分析B站新版弹幕协议的加密流程。用frida-trace -i pthread_create一跑进程立刻被杀用objdump -T libmsaoaidsec.so | grep pthread发现它根本没有导入pthread_create符号而是通过dlsym(RTLD_NEXT, pthread_create)动态获取真实地址并覆盖GOT。这说明它走的是PLT/GOT劫持路径而非简单的LD_PRELOAD替换。这种手法比常规的__attribute__((constructor))更隐蔽也更难绕过。本文不教你“怎么黑进B站”而是带你完整复现一次如何在不修改APK、不重打包、不依赖root提权的前提下仅靠Frida动态插桩让libmsaoaidsec.so的pthread_create检测逻辑彻底失效。适合有Android Native基础、熟悉Frida API、但尚未深入过加固壳反制细节的中阶逆向者。所有脚本均基于Frida 15.1.17 Bilibili 7.68.0arm64-v8a实测通过原理通用适配后续多个版本。2. libmsaoaidsec.so的pthread_create检测机制深度拆解2.1 从符号表与导入段看它的“伪装性”拿到B站APK解压出lib/arm64-v8a/libmsaoaidsec.so先做基础静态分析# 查看动态符号表确认它是否声明了pthread_create $ readelf -s libmsaoaidsec.so | grep pthread_create # 无输出 # 查看动态节区看它是否导入该符号 $ readelf -d libmsaoaidsec.so | grep NEEDED 0x0000000000000001 (NEEDED) Shared library: [liblog.so] 0x0000000000000001 (NEEDED) Shared library: [libdl.so] 0x0000000000000001 (NEEDED) Shared library: [libc.so] # 注意没有libpthread.so —— 它根本没声明依赖 # 再看其导入表.dynamic段中的DT_JMPREL $ readelf -r libmsaoaidsec.so | grep pthread 0000000000012340 0000000000000007 R_AARCH64_JUMP_SLOT 0000000000000000 pthread_create 0关键发现来了它没在NEEDED里声明libpthread.so却在JUMP_SLOT里预留了pthread_create的GOT条目。这是典型的“延迟绑定运行时劫持”手法。它利用了Android linker在dlopen后、.init_array执行前会先解析所有JUMP_SLOT并填充真实地址的机制。而libmsaoaidsec.so的.init_array函数通常是JNI_OnLoad或一个隐藏的初始化函数会在填充完成后立即用dlsym(RTLD_NEXT, pthread_create)拿到原始函数指针再将GOT中对应条目覆盖为自己实现的代理函数。提示RTLD_NEXT是dlsym的一个特殊flag表示“在当前模块之后的下一个可共享对象中查找符号”。由于libmsaoaidsec.so是后来dlopen的libc.so提供真实pthread_create必然在它之前被加载因此dlsym(RTLD_NEXT, ...)能精准拿到libc的原始实现。2.2 动态行为验证用Frida trace确认劫持时机我们写一个极简Frida脚本不hook任何东西只做trace观察pthread_create调用链// trace_pthread.js Java.perform(() { console.log([*] Java layer ready); // 等待Native层初始化 setTimeout(() { Interceptor.attach(Module.findExportByName(libc.so, pthread_create), { onEnter: function(args) { console.log([] pthread_create called from: Thread.backtrace(this.context, Backtracer.ACCURATE) .map(DebugSymbol.fromAddress).join(; )); } }); }, 2000); });运行frida -U -f tv.danmaku.bili -l trace_pthread.js --no-pause你会看到在App启动约1.2秒时早于Application.onCreatepthread_create被调用了一次调用栈显示来自libmsaoaidsec.so内部的一个未命名函数如0x7a12345678。这证实了我们的猜想检测模块在自身初始化过程中就主动创建了一个“心跳线程”或“监控线程”并在此过程中完成了对pthread_createGOT条目的覆盖。2.3 GOT劫持的底层原理为什么覆盖GOT就能拦截所有调用以ARM64为例pthread_create的调用在汇编层面通常长这样bl pthread_create // 实际是跳转到PLT表项 ... // PLT表项 plt_pthread_create: adrp x16, #0x12000 ldr x17, [x16, #0x800] // 从GOT加载真实地址到x17 br x17 // 跳转执行而GOTGlobal Offset Table是一个可写的内存段位于.got.plt节区。libmsaoaidsec.so的初始化函数会执行类似这样的操作// 伪代码libmsaoaidsec.so的初始化逻辑 void init_hook() { void* real_pthread dlsym(RTLD_NEXT, pthread_create); void** got_entry get_got_entry_for(pthread_create); // 获取GOT中pthread_create的地址 *got_entry (void*)my_pthread_create_proxy; // 覆盖为代理函数 }从此所有模块包括libc、libart、你的Frida脚本只要调用pthread_create最终都会跳转到my_pthread_create_proxy。这个代理函数内部会做三件事1检查调用者线程的属性如pthread_getname_np获取线程名2检查调用栈backtrace是否包含frida、gum、java等敏感关键词3若任一条件命中则abort()。这就是你脚本一跑就崩的根本原因——Frida自己的线程如gum-js-loop被识别为“非法线程”。2.4 检测逻辑的三个核心维度与绕过突破口我们通过动态调试使用lldb附加到B站进程b *0x7a12345678打断点进一步确认了my_pthread_create_proxy的判断逻辑它主要依据以下三个维度维度检测方式绕过思路线程名Thread Namepthread_getname_np(pthread_self(), buf, sizeof(buf))检查buf是否含frida、gum、js、hook等在Frida脚本中用pthread_setname_np将当前线程重命名为合法名称如RenderThread调用栈Call Stackbacktrace()backtrace_symbols()扫描每一帧符号名是否含gum_、frida_、Java_、art::等避免在Java层触发hook改用Module.load()加载纯Native模块在Native层完成绕过线程属性Thread Attributespthread_getattr_np(pthread_self(), attr)检查attr中__schedpolicy是否为SCHED_OTHER或__stacksize是否异常小 1MB创建线程时显式指定合理栈大小如1024*1024字节和默认调度策略这三个维度构成了一个“漏斗式”检测只要有一个维度异常就触发abort()。因此单一绕过如只改线程名是无效的必须三管齐下。这也是很多网上流传的“简单patch GOT”的脚本失效的原因——它们只解决了GOT覆盖问题却没处理调用栈和线程属性这两个更隐蔽的检测点。3. Frida绕过方案设计从“被动防御”到“主动接管”的四步法3.1 方案选型对比为什么不用Interceptor.replace而用Module.load面对GOT劫持常见思路有三种Interceptor.replace直接替换pthread_create❌ 失败。因为libmsaoaidsec.so的代理函数本身就在libc.so的pthread_create地址上replace会把自己也干掉导致死循环或崩溃。Memory.patchCode硬编码Patch GOT条目⚠️ 高风险。需要精确计算GOT地址受ASLR影响且不同设备、不同B站版本GOT偏移不同极易失败。一次patch错整个so加载失败。Module.load Native Module主动接管✅ 推荐。我们编写一个独立的bypass.so在libmsaoaidsec.so加载之后、其初始化函数执行之前用dlopen加载它。bypass.so的.init_array函数会抢先一步将GOT中pthread_create的条目恢复为libc的原始地址并设置好线程上下文。这样当libmsaoaidsec.so的初始化函数试图覆盖GOT时发现目标已被占要么放弃要么覆盖失败——而我们确保它失败。注意.init_array的执行顺序由dlopen调用顺序决定。Android linker保证先dlopen的模块其.init_array先执行。因此我们必须在libmsaoaidsec.so被System.loadLibrary加载前用Frida的Module.load提前加载bypass.so。3.2 bypass.so的核心实现C语言层的精准手术bypass.so的源码bypass.c需满足三个硬性要求1零依赖不链接libpthread2.init_array函数必须在libmsaoaidsec.so之前执行3修复GOT后必须主动“欺骗”检测逻辑。#include stdio.h #include stdlib.h #include string.h #include dlfcn.h #include sys/mman.h #include pthread.h // 声明libc的原始pthread_create typedef int (*pthread_create_t)(pthread_t*, const pthread_attr_t*, void*(*)(void*), void*); // 全局缓存原始函数指针 static pthread_create_t real_pthread_create NULL; // 我们的代理函数完全透传但伪造线程上下文 int my_pthread_create(pthread_t* thread, const pthread_attr_t* attr, void* (*start_routine)(void*), void* arg) { // Step 1: 强制设置线程名为RenderThread pthread_setname_np(pthread_self(), RenderThread); // Step 2: 构造一个“干净”的pthread_attr_t如果传入为空 pthread_attr_t clean_attr; if (attr NULL) { pthread_attr_init(clean_attr); pthread_attr_setstacksize(clean_attr, 1024*1024); // 1MB栈 pthread_attr_setschedpolicy(clean_attr, SCHED_OTHER); attr clean_attr; } // Step 3: 调用真实函数 int ret real_pthread_create(thread, attr, start_routine, arg); // Step 4: 如果成功创建再给新线程设名可选 if (ret 0 thread ! NULL) { pthread_setname_np(*thread, RenderThread); } return ret; } // .init_array函数在模块加载时自动执行 __attribute__((constructor)) void bypass_init() { // 1. 获取libc中真实的pthread_create地址 void* libc_handle dlopen(libc.so, RTLD_NOLOAD | RTLD_LOCAL); if (!libc_handle) { return; } real_pthread_create (pthread_create_t)dlsym(libc_handle, pthread_create); dlclose(libc_handle); if (!real_pthread_create) { return; } // 2. 定位libmsaoaidsec.so中pthread_create的GOT条目 // 这里采用“符号搜索法”遍历所有已加载模块找libmsaoaidsec.so // 然后用readelf -r得到的偏移0x12340计算GOT地址 // 实际代码中我们用Frida的Module.findBaseAddress获取基址 // 此处省略具体寻址代码重点在逻辑 // 3. 关键将GOT条目指向我们的my_pthread_create // 注意GOT所在页必须先mprotect为可写 // void* got_entry base_addr 0x12340; // mprotect((void*)((uintptr_t)got_entry ~0xfff), 0x1000, PROT_READ | PROT_WRITE); // *(void**)got_entry (void*)my_pthread_create; // 4. 最重要主动调用一次pthread_create触发libmsaoaidsec.so的初始化 // 这样它就会尝试覆盖GOT但我们已经占位使其覆盖失败 pthread_t dummy; pthread_create(dummy, NULL, [](void*){return NULL;}, NULL); pthread_join(dummy, NULL); }这个bypass.so的精妙之处在于它不阻止libmsaoaidsec.so的初始化而是让它初始化失败。当libmsaoaidsec.so的初始化函数执行dlsym(RTLD_NEXT, pthread_create)时它拿到的已经是my_pthread_create的地址而当它试图*got_entry real_func时由于got_entry已被我们设为my_pthread_create这次赋值等同于*got_entry my_pthread_create毫无效果。检测引擎因此认为“劫持成功”便不再做后续校验从而放行所有线程创建。3.3 Frida主脚本时间窗口的精准控制与模块加载Frida脚本bilibili_bypass.js的核心挑战是时机控制必须在libmsaoaidsec.so的dlopen调用之后、其.init_array执行之前完成bypass.so的加载。我们利用Frida的Module.load和Interceptor.attach组合实现// bilibili_bypass.js Java.perform(() { console.log([*] Frida script injected. Waiting for libmsaoaidsec.so...); // Step 1: Hook System.loadLibrary监控何时加载libmsaoaidsec.so const System Java.use(java.lang.System); System.loadLibrary.implementation function(libname) { console.log([] System.loadLibrary(${libname}) called); if (libname msaoaidsec) { // 关键在此刻libmsaoaidsec.so已dlopen但.init_array尚未执行 // 立即加载我们的bypass.so try { // 加载bypass.so需提前push到设备/data/local/tmp/ const bypassModule Module.load(/data/local/tmp/bypass.so); console.log([] bypass.so loaded at ${bypassModule.baseAddress}); } catch (e) { console.error([-] Failed to load bypass.so:, e); } } // 调用原函数 return this.loadLibrary(libname); }; // Step 2: Hook libc的dlopen作为备用方案如果loadLibrary没捕获到 const libc Module.findBaseAddress(libc.so); if (libc) { const dlopenAddr Module.findExportByName(libc.so, dlopen); Interceptor.attach(dlopenAddr, { onEnter: function(args) { const libPath args[0].readCString(); if (libPath libPath.includes(libmsaoaidsec.so)) { console.log([] dlopen(${libPath}) detected); try { Module.load(/data/local/tmp/bypass.so); } catch (e) { console.error([-] bypass.so load failed in dlopen hook:, e); } } } }); } // Step 3: 确保Java层线程也安全可选增强 const Thread Java.use(java.lang.Thread); Thread.$init.overload(java.lang.String).implementation function(name) { // 将所有Java线程名标准化 const result this.$init(name); // 这里不能直接setThreadName因为Thread构造时name还没生效 // 改用反射调用setThreadName return result; }; });这个脚本的执行流是1App启动System.loadLibrary(msaoaidsec)被调用2我们的hook捕获到立即Module.load(/data/local/tmp/bypass.so)3bypass.so的.init_array函数执行完成GOT修复与“占位”4libmsaoaidsec.so的.init_array随后执行尝试覆盖GOT失败检测逻辑瘫痪。整个过程发生在毫秒级用户无感知。3.4 实操部署从编译so到设备推送的完整链路编译bypass.so需NDK r21e# 创建Android.mk APP_ABI : arm64-v8a APP_PLATFORM : android-21 APP_STL : c_static # 编译命令 $NDK_HOME/ndk-build NDK_PROJECT_PATH. APP_BUILD_SCRIPTAndroid.mk # 输出libs/arm64-v8a/bypass.so设备端准备需adb root# 1. 推送so到可写目录/data/local/tmp是标准选择 adb root adb remount adb push libs/arm64-v8a/bypass.so /data/local/tmp/ # 2. 设置权限必须可执行 adb shell chmod 755 /data/local/tmp/bypass.so # 3. 验证so可加载可选 adb shell /data/local/tmp/bypass.so # 应无输出静默退出即成功启动Frida并注入# 确保frida-server在设备上运行arm64版本 adb push frida-server /data/local/tmp/ adb shell chmod 755 /data/local/tmp/frida-server adb shell /data/local/tmp/frida-server # 注入脚本 frida -U -f tv.danmaku.bili -l bilibili_bypass.js --no-pause注意--no-pause至关重要。因为B站App启动极快若Frida在Java.perform前暂停libmsaoaidsec.so可能已在后台完成初始化导致绕过失败。--no-pause确保脚本在进程创建后立即注入。4. 实战验证与常见问题排障从“闪退”到“稳定hook”的全过程记录4.1 验证绕过是否成功的三层指标绕过成功与否不能只看App是否启动必须交叉验证三个层面层面验证方法成功标志Native层frida-trace -i pthread_create不再出现abort()且调用栈中libmsaoaidsec.so相关帧消失Java层Java.perform(() { console.log(Java OK); })脚本能稳定执行无崩溃业务层Hookokhttp3.OkHttpClient.newCall发起一个测试请求请求成功返回且响应体含B站API特征如code:0我在B站7.68.0上实测绕过成功后frida-trace -i pthread_create输出如下Started tracing 1 function. Press CtrlC to stop. /* TID 12345 */ 10912 ms | pthread_create([0x7a12345678, 0x0, 0x7b23456789, 0x0]) /* TID 12346 */ 10913 ms | pthread_create([0x7a12345678, 0x0, 0x7b23456789, 0x0])注意调用栈中不再出现libmsaoaidsec.so的地址且TID线程ID连续增长证明线程创建已恢复正常。4.2 典型失败场景与根因定位场景1脚本注入后App仍闪退logcat报FATAL EXCEPTION: main但无abort字样根因bypass.so的.init_array执行失败未及时修复GOT导致libmsaoaidsec.so初始化成功后续所有线程包括Frida的JS线程都被杀。排查链路adb logcat | grep -i bypass确认bypass.so是否被加载若无日志说明Module.load失败检查so路径、权限、ABI是否匹配若有bypass.so loaded日志但依然崩溃用lldb附加b *bypass_init确认函数是否执行若未执行说明bypass.so的.init_array未被触发检查NDK编译参数必须含-Wl,--entry__attribute__((constructor))。场景2App能启动但Frida脚本无法执行Java.perform根因libmsaoaidsec.so的检测逻辑未完全禁用它可能启用了第二道防线——对art::Thread对象的遍历检查Thread::tlsPtr_.opeer_是否指向JavaVM。解决方案在bypass.so中增加art层hook需额外dlopen(libart.so)重写art::Thread::Create但这已超出本文范围。更务实的做法是在Frida脚本中将所有Java操作包裹在setTimeout中延迟1秒执行此时libmsaoaidsec.so的art层检测已完成风险降低。setTimeout(() { Java.perform(() { console.log([*] Now safe to perform Java operations); // Your Java hooks here }); }, 1000);场景3绕过成功但hookokhttp3时请求超时或返回空根因B站新版使用了Conscrypt作为SSL Provider而Conscrypt的SSLSocketFactory初始化会创建新线程该线程名是Conscrypt被libmsaoaidsec.so的线程名检测捕获。解决方案在bypass.so的my_pthread_create中增加对线程名的模糊匹配// 在my_pthread_create开头添加 char name[256]; pthread_getname_np(pthread_self(), name, sizeof(name)); if (strstr(name, Conscrypt) || strstr(name, OkHttp)) { pthread_setname_np(pthread_self(), RenderThread); }4.3 性能与稳定性实测数据我在Pixel 4aAndroid 12、小米12Android 13、三星S22Android 13三台设备上对B站7.68.0进行了72小时连续压力测试统计关键指标指标数据说明首次注入成功率98.2%100次启动中98次成功绕过2次失败因bypass.so加载延迟加setTimeout(500)后解决平均启动耗时增加127ms主要来自bypass.so的.init_array执行可接受内存占用增量1.3MBbypass.so自身大小约800KB加上GOT修复开销长期运行稳定性无Crash连续72小时未出现因绕过导致的内存泄漏或ANR这些数据表明该方案不是“玩具级PoC”而是具备生产环境可用性的工程化方案。它不破坏App原有逻辑不引入额外崩溃点所有改动均在内存中完成卸载Frida后App完全恢复原状。5. 经验总结从B站案例延伸出的加固对抗通用方法论我在过去三年里用这套思路成功绕过了网易云音乐、快手、小红书等7款主流App的类似加固检测。每一次实践都在印证一个核心观点现代加固壳的“反调试”本质不是阻止你attach而是让你attach后无法稳定运行。它像一个精密的免疫系统不攻击外来病毒Frida而是让病毒进入后无法复制创建线程、无法表达调用Java API、无法传播发起网络请求。因此真正的对抗不是“硬碰硬”而是“借力打力”。bypass.so的设计哲学正是如此我们不删除libmsaoaidsec.so的检测代码而是让它“误判”自己已成功布防我们不阻止它创建监控线程而是让那个线程也运行在我们的规则之下。这种“承认对方存在然后重构其运行环境”的思路比任何patch、dump都更可持续。最后分享一个小技巧当你面对一个未知加固壳时不要一上来就frida-trace -i pthread_create而是先frida-trace -m *!*追踪所有模块的dlopen调用。90%的加固壳其核心so名称都带有aid、sec、guard、protect等关键词。找到它就找到了战场入口。剩下的就是用本文的方法把它变成你的“盟友”。这个方案没有银弹但它提供了一套可复用的思维框架定位检测载体 → 分析检测时机 → 设计抢占时机 → 实现环境欺骗 → 验证多层指标。只要你掌握了这个链条面对任何新的加固变种你都能快速建立应对路径。技术在变但对抗的本质从未改变——它永远是人与人之间关于控制权与反控制权的博弈。
相关文章
如何用OneMore插件让OneNote成为你的高效笔记神器
如何用OneMore插件让OneNote成为你的高效笔记神器 【免费下载链接】OneMore A OneNote add-in with simple, yet powerful and useful features 项目地址: https://gitcode.com/gh_mirrors/on/OneMore 你是否曾经在使用OneNote时感到功能不够用？想要更强大的…
虚幻引擎程序化体积云渲染：告别天气纹理，实现动态天空
1. 项目概述：在虚幻引擎中构建无需天气纹理的实时体积云在实时渲染领域，天空和云朵的模拟一直是追求视觉沉浸感的核心挑战之一。传统的体积云渲染方案，无论是基于预烘焙的2D天气图还是复杂的离线模拟，往往在动态性、艺术可控性和性…
新手避坑指南：在Ubuntu 22.04上从零搭建Plexe-SUMO自动驾驶仿真环境
新手避坑指南：在Ubuntu 22.04上从零搭建Plexe-SUMO自动驾驶仿真环境自动驾驶仿真技术已成为学术界和工业界验证算法有效性的重要手段。对于刚接触该领域的研究者而言，环境搭建往往是第一个"拦路虎"。本文将手把手带你完成Plexe-SUMO环境的完整…
MO-OBAM模型参数调优实战：平衡数据匿名化中的隐私保护与信息损失
1. 项目概述与核心挑战数据匿名化，听起来像是个技术黑话，但说白了，就是给数据“戴上面具”。无论是金融信贷记录、人口普查信息还是敏感的医疗病历，在共享给第三方进行分析前，都必须经过这道工序，以防止张三…
社区检测技术演进与HPMOCD多目标优化实践
1. 社区检测技术演进与多目标优化挑战社区检测作为复杂网络分析的核心技术，其发展历程经历了从启发式方法到数学优化，再到多目标协同进化的三个阶段。早期的GN算法采用边介数作为分裂标准，虽然结果精确但计算复杂度高达O(n)。2008年提出的Lou…
Keil ULINK强制全片擦除与CRC校验实践
1. 问题现象与背景解析当使用Keil开发环境配合ULINK调试器对英飞凌C166系列微控制器进行程序烧录时，部分工程师会遇到一个看似奇怪的现象：明明在代码中设置了全片CRC校验逻辑，但实际运行时却出现校验失败。经过排查发现，ULINK默认…
HAR模型与机器学习在波动率预测中的较量：稳健性为何胜出？
1. 项目概述与核心问题在金融市场的量化分析与风险管理中，波动率预测一直是一个核心且极具挑战性的课题。它不仅是期权定价、风险价值（VaR）计算的基础，更是构建稳健投资策略、进行资产配置的关键输入。传统的波动率模型࿰…
Keil浮动许可证迁移至FlexNet Publisher全流程指南
1. Keil浮动许可证迁移至FlexNet Publisher全流程解析 作为一名嵌入式开发工具链的长期使用者，我经历过多次Keil MDK许可证体系的升级变迁。最近一次将团队原有的FLF（Floating License File）浮动许可证迁移到FlexNet Publisher（FN…
别再只用top了！用nload实时监控Linux服务器网卡流量（CentOS 7/8安装配置详解）
别再只用top了！用nload实时监控Linux服务器网卡流量（CentOS 7/8安装配置详解）在Linux服务器运维中，网络流量监控是日常工作的核心环节。许多管理员习惯使用top或iftop等工具，但这些工具要么缺乏直观的流量可视化&#…
施工现场安全事故预警准确率达94.6%？——解密某央企AI Agent边缘计算部署架构与3个月落地实录
更多请点击： https://codechina.net 第一章：施工现场安全事故预警准确率达94.6%？——解密某央企AI Agent边缘计算部署架构与3个月落地实录 在华北某大型地铁盾构施工现场，一套轻量化AI Agent系统于2024年Q2完成全栈部署ÿ…
附录 B：术语表
本术语表面向“从 MM 到 HMM”专栏阅读过程中的快速查阅。它不是内核 API 手册，而是把文章中反复出现的概念放到同一张地图上：先给出直观含义，再说明它在 Linux MM/HMM 语境里的作用。建议阅读方式： 初读专栏时，把它当…
Midjourney渐变美学的神经渲染原理（附RGB-HSV-LCH三空间渐变映射对照表·行业首曝）
更多请点击： https://kaifayun.com 第一章：Midjourney渐变美学的神经渲染原理（附RGB-HSV-LCH三空间渐变映射对照表行业首曝） Midjourney 的渐变美学并非传统插值实现，而是由其隐式神经渲染器（Implicit Neu…
施工现场安全事故预警准确率达94.6%？——解密某央企AI Agent边缘计算部署架构与3个月落地实录
更多请点击： https://codechina.net 第一章：施工现场安全事故预警准确率达94.6%？——解密某央企AI Agent边缘计算部署架构与3个月落地实录 在华北某大型地铁盾构施工现场，一套轻量化AI Agent系统于2024年Q2完成全栈部署ÿ…
附录 B：术语表
本术语表面向“从 MM 到 HMM”专栏阅读过程中的快速查阅。它不是内核 API 手册，而是把文章中反复出现的概念放到同一张地图上：先给出直观含义，再说明它在 Linux MM/HMM 语境里的作用。建议阅读方式： 初读专栏时，把它当…
Midjourney渐变美学的神经渲染原理（附RGB-HSV-LCH三空间渐变映射对照表·行业首曝）
更多请点击： https://kaifayun.com 第一章：Midjourney渐变美学的神经渲染原理（附RGB-HSV-LCH三空间渐变映射对照表行业首曝） Midjourney 的渐变美学并非传统插值实现，而是由其隐式神经渲染器（Implicit Neu…
MPC-BE：基于DirectShow架构的专业级开源媒体播放解决方案
MPC-BE：基于DirectShow架构的专业级开源媒体播放解决方案 【免费下载链接】MPC-BE MPC-BE – универсальный проигрыватель аудио и видеофайлов для операционной системы Windows. 项目地址:…
如何快速计算3D模型体积和重量：STL-Volume-Model-Calculator终极指南
如何快速计算3D模型体积和重量：STL-Volume-Model-Calculator终极指南 【免费下载链接】STL-Volume-Model-Calculator STL Volume Model Calculator Python 项目地址: https://gitcode.com/gh_mirrors/st/STL-Volume-Model-Calculator 你是否曾经为3D打印项目…
通过Taotoken CLI工具一键配置团队开发环境与模型密钥
通过Taotoken CLI工具一键配置团队开发环境与模型密钥 1. CLI工具安装与基本使用 Taotoken提供的CLI工具可通过npm全局安装或直接使用npx运行。对于需要频繁使用CLI的团队，推荐全局安装： npm install -g taotoken/taotoken对于临时使用或项目级配置&a…