1. 这不是“秒破”广告而是真实项目里能立刻用上的So层Hook能力在安卓逆向和安全分析一线干了十多年我见过太多人把Frida当“万能胶水”——装上就跑、hook就完事结果一碰.so文件就卡死要么脚本根本加载不进去要么函数地址算错直接崩溃要么hook住却拿不到参数最后只能对着logcat发呆。其实问题根本不在于Frida本身而在于绝大多数教程跳过了最关键的一环So层Hook不是JavaScript写个onCreate就能搞定的它是一场CPU指令、内存布局、符号表解析和调用约定的协同作战。这篇讲的“5分钟搞定”指的是从环境准备完毕、目标so确认可加载、到成功捕获关键函数入参并修改返回值的完整闭环时间——我上周在客户现场实测从打开Termux到看到log输出计时器停在4分38秒。核心关键词是Frida、安卓So层Hook、ARM64指令集、JNI函数定位、符号表解析、dlopen/dlsym模拟、寄存器传参还原。它适合三类人做App加固对抗的安全研究员、需要绕过本地校验的测试工程师、以及正在调试自研NDK模块的Android开发。你不需要会写汇编但得愿意看懂r0-r3在ARM64里怎么传参你不用精通ELF格式但得知道.dynsym节里藏着什么你甚至可以没编译过so但必须理解System.loadLibrary(xxx)背后发生了什么。下面所有内容都来自我过去三年在27个不同厂商App覆盖高通/联发科/紫光展锐平台上反复验证过的路径。2. 为什么90%的So Hook失败根源都在这四个认知断层2.1 断层一混淆了“Java层Hook”和“So层Hook”的底层执行模型很多人以为Java.perform(() { Java.use(xxx).method.implementation ... })这套逻辑能平移过来给Module.load(/data/app/xxx/lib/arm64/libnative.so)之后直接findExportByName(func_name)就行。这是致命误解。Java层运行在ART虚拟机里方法调用走的是JIT编译后的字节码解释器而.so里的函数是原生机器码直接由CPU执行没有“方法名”这个概念——只有符号表里的一串字符串对应内存偏移。Frida的findExportByName本质是遍历目标so的动态符号表.dynsym匹配字符串后计算出该符号在内存中的绝对地址。如果so被strip过生产环境99%都会strip.dynsym里只剩__libc_init这类系统符号你的业务函数名全没了。这时候findExportByName(login_check)返回null不是Frida的bug是你面对的是一个“无名战士”。我试过最狠的案例某金融App的libsec.so被OLLVM混淆符号全删段名重命名最后靠Memory.scanSync扫特征码Instruction.parse反汇编跳转指令才定位到核心校验函数。2.2 断层二忽略了ARM64调用约定对参数还原的硬性约束安卓64位So默认用ARM64 ABI参数传递严格遵循AAPCS64标准前8个整型参数依次放x0-x7寄存器浮点参数放d0-d7超过8个才压栈。但Frida的Interceptor.attach回调里args数组默认只映射了x0-x7即args[0]到args[7]它不会自动帮你把栈上参数拼进来。比如一个函数原型是int verify(char* data, int len, char* key, int key_len, int mode, int timeout, char* salt, int salt_len, void* ctx)前8个参数在寄存器里第9个ctx在栈上。如果你只读args[0]到args[7]ctx就永远拿不到。更坑的是某些厂商会手动改调用约定——比如把第3个参数故意放栈上规避检测。我踩过最深的坑是在某社交App里decrypt_data函数的密钥指针被放在sp0x28处args[2]实际是0必须用ptr(this.context.sp).add(0x28).readPointer()才能取到。这不是Frida的问题是ARM64硬件规则决定的你得亲手去寄存器和栈里“挖”。2.3 断层三误判了So加载时机与内存基址的动态性很多人写脚本时直接硬编码base Module.findBaseAddress(libnative.so)然后base.add(0x12345)去hook。这在模拟器或特定ROM上可能成功但在真机上必崩。原因有三一是ASLR地址空间布局随机化会让每次加载基址都变比如上次是0x7f8a120000这次可能是0x7f9b340000二是某些App用dlopen手动加载so且加载后立即dlclose导致Module对象瞬间失效三是部分加固方案如腾讯Legu会在dlopen返回前把so内存页设为PROT_NONE你拿到的基址指向的是不可读区域。我处理过的典型场景某电商App的libpay.so在Application.onCreate里通过System.loadLibrary(pay)加载但真正的业务函数do_payment只在用户点击支付按钮时才由另一个so通过dlsym动态获取并调用。这时候Module.findBaseAddress查到的基址可能在hook前就被释放了。解决方案不是死磕基址而是用Interceptor.attach配合Module.enumerateExports实时监听函数调用或者用Memory.scanSync在内存里持续扫描特征码。2.4 断层四低估了符号表缺失时的函数定位成本当findExportByName返回null新手第一反应是“so被加固了”然后放弃。其实还有三条路路径A用Module.enumerateSymbols遍历所有符号——但它只返回.symtab静态符号表而生产so通常strip掉.symtab只留.dynsym所以大概率为空路径B用Module.enumerateExports遍历动态导出符号——这是正解但要注意它返回的是{name, address, type}对象name字段在strip后可能为空字符串此时得靠address结合Memory.readCString读取附近字符串来猜函数名路径C用Memory.scanSync扫特征码——比如找BL __aeabi_memcmp指令序列定位校验函数或扫AES_encrypt字符串定位加密入口。我在某游戏SDK里遇到过.dynsym全空的情况最后靠扫描sub sp, sp, #0x40分配栈帧ldp x29, x30, [sp, #0x30]恢复fp/lr这两条指令的组合模式锁定了所有JNI函数的起始地址。这不是玄学是ARM64指令编码的确定性带来的必然结果。3. 从零开始的So Hook五步法每一步都附可验证的原理和避坑点3.1 第一步确认目标So是否可加载及基础信息探测别急着写hook先用adb确认环境adb shell su -c cat /proc/$(pidof com.xxx.app)/maps | grep libnative.so这条命令输出类似7f8a120000-7f8a140000 r-xp 00000000 fd:00 123456 /data/app/com.xxx.app-abc123/lib/arm64/libnative.so关键看三列r-xp表示可读可执行缺r说明被mprotect保护、7f8a120000是当前加载基址、/data/app/...是文件路径。如果这里没输出说明so还没加载或被隐藏。此时要抓包看App启动日志或用strace -p $(pidof com.xxx.app) -e traceopenat,open,readlink监控文件操作。接着用Frida探测基础信息// frida -U -f com.xxx.app -l step1.js --no-pause Java.perform(() { console.log([] App process started); const lib Module.findBaseAddress(libnative.so); if (lib) { console.log([] libnative.so base: ${lib}); console.log([] .text section: ${lib.add(0x1000)}); // 粗略估计.text起始 const exports Module.enumerateExports(libnative.so); console.log([] Total exports: ${exports.length}); exports.slice(0, 5).forEach(exp { console.log( - ${exp.name || no name} ${exp.address}); }); } else { console.log([-] libnative.so not found in memory); } });提示Module.enumerateExports比findExportByName更可靠因为它不依赖符号名存在而是解析.dynsym节的原始数据结构。即使name为空address依然有效你可以用Memory.readUtf8String(exp.address)尝试读取函数开头的字符串常量比如错误提示来辅助判断。3.2 第二步定位目标函数的三种实战策略及选择逻辑假设我们要hook的函数是int check_license(const char* sig, int len)但findExportByName(check_license)返回null。这时按优先级采用以下策略策略1符号表模糊匹配最快成功率约60%const exports Module.enumerateExports(libnative.so); const target exports.find(exp exp.name (exp.name.includes(license) || exp.name.includes(check)) exp.type function ); if (target) { console.log([] Found by fuzzy match: ${target.name} ${target.address}); }原理很多加固工具只删函数名但保留license、verify等子串在符号里。我统计过32个主流加固方案其中21个会保留这类敏感词。策略2JNI函数名推导针对JNI_OnLoad注册的函数成功率85%安卓JNI函数名有固定格式Java_com_xxx_yyy_ZZZ_methodName。用正则扫const jniFuncs exports.filter(exp exp.name /^Java_/.test(exp.name) ); jniFuncs.forEach(func { if (func.name.includes(license) || func.name.includes(check)) { console.log([] JNI candidate: ${func.name}); } });注意JNI_OnLoad里注册的函数其符号名一定是Java_开头这是JNI规范强制的加固工具无法删除否则Java层调用会直接crash。策略3特征码扫描终极方案成功率100%但需逆向基础用Ghidra或IDA打开so找到check_license函数复制前16字节机器码ARM64下每条指令4字节共4条。例如0x0000000000012340 a9bf7bfd stp x29, x30, [sp, #-0x10]! 0x0000000000012344 910003fd mov x29, sp 0x0000000000012348 b9400040 ldr w0, [x2] 0x000000000001234c 7100041f cmp w0, #0x1对应字节序列fd 7b bf a9 fd 03 00 91 40 00 40 b9 1f 04 00 71。Frida脚本const base Module.findBaseAddress(libnative.so); if (base) { const results Memory.scanSync(base, base.size, fd 7b bf a9 fd 03 00 91 40 00 40 b9 1f 04 00 71); if (results.length 0) { console.log([] Found by pattern: ${results[0].address}); } }注意特征码要选函数开头的稳定指令避免用mov x0, #0这类易被优化的指令。我习惯选stp x29,x30,[sp,#-0x10]!保存fp/lr作为锚点因为所有函数序言几乎都包含它。3.3 第三步正确还原ARM64参数并安全读取内存定位到函数地址后Interceptor.attach的回调里args数组只映射x0-x7。对于check_license(const char* sig, int len)sig在x0len在x1直接可用Interceptor.attach(target.address, { onEnter: function(args) { this.sigPtr args[0]; this.len parseInt(args[1]); console.log([] check_license called: sig${this.sigPtr}, len${this.len}); if (this.sigPtr this.len 0) { try { // 安全读取字符串加try-catch防空指针崩溃 this.sigStr Memory.readUtf8String(this.sigPtr) || empty; console.log([] sig content: ${this.sigStr.substring(0, 50)}); } catch (e) { console.log([-] Failed to read sig: ${e.message}); this.sigStr unreadable; } } }, onLeave: function(retval) { console.log([] Original return: ${retval}); // 修改返回值让校验永远通过 retval.replace(ptr(1)); } });但这里有两个致命细节细节1Memory.readUtf8String可能触发SIGSEGV。因为sig指针可能指向已释放内存或受保护区域。必须用try/catch包裹且最好先用Memory.protect临时放开权限if (this.sigPtr) { const page ptr(this.sigPtr).and(~0xfff); // 对齐到页首 try { Memory.protect(page, 0x1000, rwx); // 临时可读可写可执行 this.sigStr Memory.readUtf8String(this.sigPtr) || empty; } catch (e) { this.sigStr protected; } finally { Memory.protect(page, 0x1000, r-x); // 恢复只读执行 } }细节2retval.replace(ptr(1))不能直接写1。因为ARM64返回值存放在x0寄存器ptr(1)是64位地址而x0是整型寄存器。正确写法是retval.replace(1)传数字或retval.replace(ptr(0x1))传地址但后者会把x0设为地址0x1而非值1。我踩过的坑某次误写retval.replace(ptr(1))导致返回值变成0x0000000000000001而函数期望返回int类型1结果高位清零后变成0校验失败。3.4 第四步绕过常见加固陷阱的三个硬核技巧技巧1对抗mprotect内存保护某些加固会把关键函数所在内存页设为PROT_NONE导致Interceptor.attach失败。解决方案是先用Memory.protect恢复可执行权限const funcAddr target.address; const page funcAddr.and(~0xfff); Memory.protect(page, 0x1000, rwx); // 关键必须在attach前执行 Interceptor.attach(funcAddr, { /* ... */ });技巧2应对dlopen延迟加载如果so是dlopen动态加载的Module.findBaseAddress可能查不到。改用Process.enumerateModules()轮询setInterval(() { const modules Process.enumerateModules(); const lib modules.find(m m.name libnative.so); if (lib lib.base) { console.log([] libnative.so loaded at ${lib.base}); // 执行hook逻辑 clearInterval(this.intervalId); } }, 500);技巧3处理fork进程隔离某些App在支付等敏感流程会fork子进程执行so主进程的Frida脚本无法注入子进程。此时要用frida -U -f com.xxx.app --spawn-on-fork参数并在脚本里监听Process.setExceptionHandler捕获子进程异常Process.setExceptionHandler((details) { if (details.threadId ! Process.getCurrentThreadId()) { console.log([] New thread detected: ${details.threadId}); // 在新线程里重新执行hook } });注意--spawn-on-fork是Frida 15.1.17才支持的参数旧版本需用frida-ps -U查子进程pid再手动attach。3.5 第五步完整可运行脚本及各环节验证点以下是经过27个App实测的完整脚本已去除所有敏感信息保留核心逻辑// so_hook_complete.js // Frida 15.1.17 tested on Android 12 ARM64 // Usage: frida -U -f com.xxx.app -l so_hook_complete.js --no-pause --spawn-on-fork Java.perform(() { console.log([*] Frida script injected into com.xxx.app); // Step 1: Wait for libnative.so to load let libBase null; const waitForLib setInterval(() { libBase Module.findBaseAddress(libnative.so); if (libBase) { console.log([] libnative.so base address: ${libBase}); clearInterval(waitForLib); doHook(libBase); } }, 300); function doHook(base) { // Step 2: Enumerate exports and find target const exports Module.enumerateExports(libnative.so); console.log([] Found ${exports.length} exports); let targetFunc null; // Try exact match first targetFunc exports.find(e e.name check_license); if (!targetFunc) { // Fallback to fuzzy match targetFunc exports.find(e e.name (e.name.includes(license) || e.name.includes(check)) e.type function ); } if (!targetFunc) { // Last resort: scan for JNI function const jniFuncs exports.filter(e e.name /^Java_/.test(e.name)); targetFunc jniFuncs.find(e e.name.includes(license)); } if (!targetFunc) { console.log([-] Failed to locate target function); return; } console.log([] Target function: ${targetFunc.name} ${targetFunc.address}); // Step 3: Hook with parameter safety Interceptor.attach(targetFunc.address, { onEnter: function(args) { console.log([] Entering ${targetFunc.name}); this.sig args[0]; this.len parseInt(args[1]); // Safe string read with protection if (this.sig this.len 0) { try { const page this.sig.and(~0xfff); Memory.protect(page, 0x1000, rwx); this.sigStr Memory.readUtf8String(this.sig) || empty; console.log([] sig: ${this.sigStr.substring(0, 32)}); } catch (e) { console.log([-] Cant read sig: ${e.message}); this.sigStr error; } finally { Memory.protect(page, 0x1000, r-x); } } }, onLeave: function(retval) { console.log([] Leaving ${targetFunc.name}, original ret${retval}); // Bypass license check retval.replace(1); console.log([] Return value forced to 1); } }); console.log([] Hook installed successfully); } });验证点清单执行脚本后逐项检查验证点预期输出失败原因[] libnative.so base address显示十六进制地址So未加载或名称错误[] Target function: check_license 0x7f...显示函数名和地址符号表全空需切特征码扫描[] Entering check_license函数调用时打印Hook未触发检查调用时机[] sig: xxx显示截断的字符串内容内存不可读检查Memory.protect[] Return value forced to 1返回值被修改retval.replace写错参数类型4. 真实项目中的五个高频问题与我的解决路径4.1 问题Hook后App直接闪退logcat显示signal 11 (SIGSEGV), code 1 (SEGV_MAPERR)这是最常见的崩溃90%源于在onEnter里读取了非法内存地址。比如args[0]是0x0空指针或0xdeadbeef已被释放的地址直接Memory.readUtf8String(args[0])就会触发段错误。我的解决路径先用ptr(args[0]).isNull()判断是否空指针再用Memory.readByteArray(args[0], 1)尝试读1字节捕获异常如果异常用DebugSymbol.fromAddress(args[0])查符号上下文确认是否是合法地址最终fallback到打印args[0].toString()的原始值而不是强行读取。实操心得我在某银行App里发现sig参数在debug版是有效指针release版被替换成0x1作为占位符此时读取必然崩溃。解决方案是加一层判断if (args[0].equals(ptr(1))) { this.sigStr placeholder; }。4.2 问题Hook成功但onLeave里retval始终是0无法修改这通常是因为函数返回值类型不是int。比如check_license实际返回jboolean即unsigned char而retval.replace(1)会把整个x0寄存器设为0x0000000000000001但函数只取低8位结果还是1但如果返回long longretval.replace(1)就只改了低32位高位仍是0导致返回值错误。我的解决路径用objdump -d libnative.so | grep -A 20 check_license查反汇编看ret指令前的mov x0, #1还是mov w0, #1w0是x0低32位根据返回类型选择retval.replace(1)int/long或retval.replace(ptr(1))指针最保险的方式是用this.context.x0 1直接写寄存器绕过Frida的类型封装。注意this.context是ARM64寄存器快照对象x0到x30都可直接赋值这是最底层的控制方式。4.3 问题同一台手机上A App能HookB App死活不行这往往不是Frida问题而是SELinux策略差异。某些厂商ROM如小米HyperOS对/data/app/目录下的so文件有额外限制dlopen时会检查调用者UID是否匹配。我的解决路径adb shell su -c getenforce确认SELinux是否为Enforcingadb shell su -c ls -Z /data/app/com.xxx.app-*/lib/arm64/libnative.so查文件安全上下文如果上下文是u:object_r:app_data_file:s0:c512,c768而Frida进程的上下文是u:r:shell:s0则权限不足解决方案用adb shell su -c chcon u:object_r:app_data_file:s0:c512,c768 /data/app/com.xxx.app-*/lib/arm64/libnative.so临时修改或换用Magisk模块Frida Server它以u:r:magisk:s0运行权限更高。血泪教训我在某国产平板上折腾3小时最后发现是SELinux阻止了内存映射chcon一行命令解决。4.4 问题Hook后功能正常但App检测到被注入并退出这是典型的反调试/反注入检测。很多加固SDK会调用ptrace(PTRACE_TRACEME, 0, 0, 0)检测是否被trace或读/proc/self/status查TracerPid。我的解决路径用frida-trace -U -i ptrace com.xxx.app监控ptrace调用发现ptrace(PTRACE_TRACEME)后立即Interceptor.replace它返回0同时hookopenat拦截对/proc/self/status的读取伪造TracerPid: 0最彻底的方案用frida-gum编写Native插件在_start阶段直接patchptrace调用点。提示frida-trace比手动写hook更快定位检测点它是Frida内置的动态跟踪工具无需写JS代码。4.5 问题So里有多个同名函数Hook错了目标比如libcrypto.so里有AES_encrypt、AES_decrypt、AES_set_encrypt_key等多个AES_*函数findExportByName(AES_encrypt)可能返回第一个但你要hook的是第二个。我的解决路径用Module.enumerateExports(libcrypto.so)获取所有AES_*函数地址用Memory.readByteArray(addr, 32)读每个函数开头32字节对比特征码AES_encrypt开头通常是stp x29,x30,[sp,#-0x20]!而AES_decrypt可能是stp x29,x30,[sp,#-0x30]!栈帧更大或用DebugSymbol.fromAddress(addr)查函数名有些so即使strip了也会在.comment节留调试信息。经验我建了一个常用函数特征码库比如memcpy的ARM64特征是0x910003e0mov x0, sp0xb4000080cbz x0, ...遇到新so直接匹配效率提升5倍。5. 我的So Hook工作流从接到需求到交付报告的标准化动作接到一个So Hook需求比如“绕过某App的设备绑定校验”我不会直接开Frida而是执行一套标准化动作确保5分钟内能复现结果5.1 动作1环境预检2分钟adb shell getprop ro.build.version.release确认Android版本影响ABIadb shell cat /proc/cpuinfo | grep CPU architecture确认是ARM64还是ARMv7adb shell su -c ls -l /data/app/com.xxx.app-*/lib/*/查so架构目录arm64-v8aorarmeabi-v7aadb shell su -c dumpsys package com.xxx.app | grep versionName\|versionCode记录App版本方便后续复现。这2分钟省掉后续80%的兼容性问题。我曾因忽略armeabi-v7a目录用ARM64 Frida Server去hook结果Module.findBaseAddress永远返回null。5.2 动作2So提取与静态分析1分钟adb shell su -c cp /data/app/com.xxx.app-*/lib/arm64-v8a/libnative.so /data/local/tmp/adb pull /data/local/tmp/libnative.so ./下载到本地file libnative.so确认是ELF 64-bit LSB shared object, ARM aarch64readelf -d libnative.so | grep NEEDED查依赖库确认是否依赖libssl.so等nm -D libnative.so | grep T 列出所有导出函数T表示text段即函数。nm -D比objdump -T更快它直接解析.dynsym适合快速筛查。5.3 动作3动态行为观测30秒frida-trace -U -i dlopen -i dlsym com.xxx.app启动App看so加载时机frida-trace -U -i openat -i read com.xxx.app监控文件IO找配置文件读取frida -U -f com.xxx.app -l dump_modules.js --no-pause脚本只打印Module.enumerateModules()确认so是否在进程里。frida-trace是Frida的瑞士军刀它比写完整脚本快10倍专治“不知道从哪下手”。5.4 动作4最小化Hook验证1分钟写最简脚本只做三件事console.log(Script loaded)Module.findBaseAddress(libnative.so)并打印Interceptor.attach(Module.findExportByName(libnative.so, check_license), {onEnter: console.log})。如果这三步都成功说明环境OK可以加复杂逻辑如果失败就聚焦解决这三步不盲目堆代码。我的黄金法则任何复杂脚本都必须能拆解成可独立验证的原子步骤。一个步骤失败就停在那里不往下走。5.5 动作5交付物打包30秒不是只给一个js文件而是打包so_hook_report.md含环境信息、so版本、Hook函数地址、验证截图so_hook.js最终脚本带详细注释so_features.txt特征码列表用于后续同类App复用adb_commands.txt所有用到的adb命令方便客户复现。客户要的不是技术是结果。一份清晰的交付物比100行炫技代码更有价值。我在实际使用中发现这套流程最大的价值不是“快”而是可预测性——无论面对什么App、什么加固、什么So只要按这五步走结果误差不超过±30秒。技术可以迭代但标准化动作带来的确定性才是资深从业者最硬的护城河。
