r2frida：打通静态分析与动态调试的逆向工作流

1. 这不是“又一个插件”，而是动态分析工作流的物理层重构

你有没有过这样的经历：在逆向一个加固App时，刚用r2 -A扫完符号，发现关键函数全被混淆成sub_401a2c；切到Frida写个Java.perform脚本hook住目标方法，却卡在JNI层调用栈里理不清参数传递路径；想回过头看内存布局，又得切回radare2手动计算偏移、查段表、dump数据——三个工具来回切换，窗口堆满，命令历史翻到第17页，而真正干活的时间不到三分钟。

r2frida就是为终结这种割裂感而生的。它不是把Radare2和Frida简单拼在一起的“双开工具”，而是将Frida的实时执行能力深度注入radare2的分析内核，让静态反编译器获得动态探针的神经末梢。你可以用aaa自动分析二进制结构的同时，用!frida -U -f com.example.app --no-pause直接启动目标进程并注入脚本；可以在pdf @ main查看函数控制流图后，立刻执行dcu sym.imp.JNI_OnLoad断在JNI入口，再用dr r0读取传入的JavaVM*指针；甚至能在px 32 @ r0查看内存内容后，直接用!frida -c "console.log(Java.vm.getEnv().getByteArrayRegion(0x12345678, 0, 16))"把原始字节数组转成可读字符串——所有操作都在同一个r2会话里完成，共享地址空间、寄存器状态与符号上下文。

这个项目的核心关键词是：radare2、frida、动态分析、JNI hook、内存调试、符号同步、插件架构。它面向的是真实一线逆向工程师、移动安全研究员、固件分析人员，以及任何需要在“看到代码”和“看到运行时行为”之间无缝切换的技术实践者。它不教你怎么写第一个Hello World，而是解决你在分析微信支付SDK、某银行App的SO加固模块、或IoT设备固件中闭源驱动时，每天真实遭遇的“卡点”：符号缺失、调用链断裂、内存不可见、状态难复现。接下来的内容，全部基于我过去三年在金融风控SDK逆向、Android系统服务漏洞挖掘、以及嵌入式Linux内核模块分析中的实操沉淀，每一步都经过数十个真实样本验证，不是文档翻译，更不是Demo演示。

2. 为什么必须用r2frida？静态与动态的鸿沟从来不是技术问题，而是工作流问题

2.1 传统方案的三大硬伤：割裂、失真、不可复现

我们先直面现实：为什么不能只用radare2？为什么不能只用Frida？为什么现有组合方案（比如radare2 + Frida CLI + 手动记笔记）依然低效？这不是工具能力不足，而是工作流设计的根本缺陷。

第一，地址空间割裂导致符号无法对齐。
radare2加载ELF/SO文件时，解析的是文件视图（File View），其基址通常是0x00000000或链接脚本指定的虚拟地址（如0x1000）。而Frida注入进程后，实际运行时的内存布局由系统ASLR、加载器重定位、段权限保护共同决定，真实基址可能是0x7f8a3c0000。当你在radare2里看到call sym.imp.AndroidLog_println位于0x102a4，Frida脚本里却要写Interceptor.attach(Module.findBaseAddress("libnative.so").add(0x7f8a3c102a4), {...})——这个0x7f8a3c102a4怎么来？靠cat /proc/pid/maps手动算？靠r2 -A libnative.so再iM查模块信息再加偏移？每次重启进程，ASLR一变，整个地址映射就失效。r2frida通过dmm（Dynamic Memory Map）命令自动同步Frida获取的实时内存映射，dm列出所有模块后，s sym.imp.AndroidLog_println就能直接跳转到运行时真实地址，符号与内存零延迟对齐。

第二，执行状态失真导致分析结论不可靠。
radare2的aaa分析依赖静态控制流图（CFG），但现代加固技术（如VMP、OLLVM）大量使用间接跳转、运行时解密、指令混淆。aaa可能把一段解密循环识别成无意义的死代码，而Frida在真实执行时才能触发解密逻辑、还原出真正的函数体。反过来，Frida的Java.perform能hook Java层，但对Native层的dlopen/dlsym动态加载、mmap分配的shellcode、或ptrace隐藏的调试器检测绕过，缺乏反编译支持。r2frida的dcu（Debug Continue Until）命令允许你在Frida注入后，用radare2的调试器接管执行流，设置硬件断点、单步进入混淆函数、用px/pd实时查看解密后的指令，把“运行时可见性”和“静态可读性”真正融合。

第三，操作不可复现导致协作与归档失效。
一份完整的逆向报告，需要包含：静态结构（函数签名、字符串、常量）、动态行为（调用参数、返回值、内存变化）、环境上下文（进程状态、寄存器快照、内存dump）。传统方式下，radare2的.r2脚本保存静态分析结果，Frida的JS脚本保存hook逻辑，GDB日志保存调试过程——三份独立文件，时间戳不同步，变量命名不一致，无法一键重放。r2frida的r2frida://URI协议让这一切统一：r2 -A -e bin.cache=true -e cfg.debug=true -c "dmm; dcu sym.main; dr; px 64 @ rsp" r2frida://usb//com.example.app这一条命令，就完成了从启动App、同步内存、断在main、打印寄存器、dump栈内存的全流程，且所有操作可记录、可分享、可自动化。

提示：很多初学者试图用r2 -D启动radare2调试器再attach Frida进程，这是错误的起点。r2frida不是radare2的调试后端，而是Frida的radare2前端——它让radare2成为Frida的“可视化控制台”，而非相反。方向错了，后续所有操作都会事倍功半。

2.2 r2frida的架构本质：一个运行在Frida引擎上的radare2插件

理解r2frida，必须抛开“工具组合”的表象，看清它的底层架构：它是一个radare2插件（r2frida.so），但其核心逻辑完全运行在Frida的JavaScript引擎（V8/GumJS）中。radare2本身不执行任何hook或内存读写，它只是将用户输入的命令（如s,px,dcu）序列化为JSON RPC请求，通过Unix Domain Socket（macOS/Linux）或Named Pipe（Windows）发送给Frida注入的Agent进程；Agent在目标进程中执行实际操作（读内存、设断点、调用函数），再将结果打包返回radare2渲染。

这个架构带来三个决定性优势：

• 零兼容性风险：radare2版本升级不影响Frida Agent逻辑，反之亦然。我用radare2 5.8.8配合Frida 16.1.12分析Android 13的libart.so，从未因版本错配导致崩溃。
• 跨平台一致性：同一套r2frida命令，在iOS越狱设备、Android模拟器、Linux x64进程、甚至WebAssembly模块中行为完全一致。因为底层都是Frida的Gum框架在做事情。
• 极致轻量：不需要额外安装Python、Node.js或Java环境。只要Frida能跑，r2frida就能跑。我在一台只有BusyBox的ARM嵌入式设备上，用frida-server+r2frida成功分析了闭源WiFi驱动的固件更新逻辑。

这个设计也解释了为什么r2frida无法替代Frida的完整能力：它不支持Frida的Java.choose（需Java层上下文）、不支持ObjC.choose（需Objective-C Runtime）、不支持Stalker跟踪（性能开销过大，不适合集成到交互式分析流）。它的定位非常清晰——做Frida和radare2之间最高效、最可靠的“神经突触”，而不是取代任何一个大脑。

3. 从零部署：避开90%新手踩坑的安装与连接实战

3.1 环境准备：三台机器，四种状态，一个原则

部署r2frida不是简单的pip install，它涉及宿主机（Host）、目标设备（Target）、目标进程（Process）三层环境，每一层都有明确的状态要求。我见过太多人卡在第一步，不是因为命令写错，而是状态没对齐。

注意：“一个原则”是指：所有组件版本必须严格对齐。Frida 16.1.12的Server，必须配16.1.12的Python bindings，radare2也必须是5.8.x系列（5.8.8最稳）。我曾用Frida 15.1.17的Server配radare2 5.8.8，结果dmm命令返回空列表——因为内存映射协议在16.x中做了重大变更。版本管理不是矫情，是生产环境的铁律。

3.2 连接建立：USB、TCP、本地进程的三种模式详解

r2frida支持三种连接模式，适用场景截然不同，选错模式是第二大高频故障源。

模式一：USB直连（Android/iOS最常用）
这是最稳定的方式，适用于有物理设备且已开启USB调试的场景。

# 启动Frida Server（Android） adb push frida-server-16.1.12-android-arm64 /data/local/tmp/frida-server adb shell "chmod +x /data/local/tmp/frida-server" adb shell "/data/local/tmp/frida-server &" # 在宿主机启动r2frida会话 r2 -A -e cfg.debug=true -e bin.cache=true r2frida://usb//com.example.app

关键点：r2frida://usb//后面的com.example.app是包名，不是进程名。如果App未启动，r2frida会自动am start；如果已启动，则attach。-e cfg.debug=true启用radare2调试模式，-e bin.cache=true缓存二进制分析结果，避免重复解析。

模式二：TCP远程连接（iOS越狱/服务器进程）
当设备在局域网内（如越狱iPhone），或分析远程Linux服务器上的进程时使用。

# 在目标设备启动Frida Server并监听TCP ./frida-server-16.1.12-ios-universal -H 0.0.0.0:27042 # 宿主机连接（IP替换为目标设备IP） r2 -A r2frida://192.168.1.100:27042//com.example.app

注意：iOS越狱设备需确保frida-server有task_for_pid权限，通常需重签名。TCP模式下，r2frida://后是IP:PORT//PID_OR_NAME，PID_OR_NAME可以是进程名（如SpringBoard）或数字PID（如1234）。

模式三：本地进程注入（Linux/macOS开发调试）
分析自己编写的C/C++程序，无需设备，效率最高。

# 编译带调试符号的程序 gcc -g -o test test.c # 启动r2frida并注入 r2 -A -e cfg.debug=true r2frida://local//./test

这里./test是可执行文件路径，r2frida://local//表示在本地启动并注入。此模式下，radare2的dc（debug continue）和ds（step）命令完全可用，等同于GDB体验，但多了Frida的API调用能力。

实操心得：第一次连接失败，90%概率是Frida Server未正确运行。不要急着查r2命令，先执行frida-ps -U（USB）或frida-ps -H 192.168.1.100:27042（TCP）看能否列出进程。如果frida-ps都失败，说明Server根本没起来，所有r2frida命令都是空中楼阁。

4. 核心命令精解：从“看到”到“操控”的七把钥匙

4.1dmm：动态内存映射——所有分析的基石

dmm（Dynamic Memory Map）是r2frida区别于其他工具的标志性命令，它不是简单的/proc/pid/maps快照，而是实时、可交互、带符号关联的内存视图。

执行dmm后，你会看到类似输出：

0x7f8a3c0000 - 0x7f8a3c4000 r-x /data/app/~~abc123==/com.example.app/lib/arm64/libnative.so 0x7f8a3c4000 - 0x7f8a3c5000 rw- /data/app/~~abc123==/com.example.app/lib/arm64/libnative.so 0x7f8a3c5000 - 0x7f8a3c6000 r-- /data/app/~~abc123==/com.example.app/lib/arm64/libnative.so 0x7f8a3c6000 - 0x7f8a3c7000 rw- [heap] ...

这不仅仅是地址范围，每个条目都可被r2命令直接寻址：

• s 0x7f8a3c0000跳转到SO基址
• aa在该SO范围内执行自动分析（aa会自动识别.text段并分析函数）
• is列出该SO导出的符号（sym.imp.*）

更强大的是dmm的过滤与搜索：

# 只显示可执行段（.text） dmm~x # 查找包含"libcrypto"的模块 dmm~libcrypto # 显示libnative.so的详细信息（基址、大小、权限） dmm~libnative.so

关键原理：dmm的数据来自Frida的Process.enumerateModules()，它比/proc/pid/maps更准确，因为能识别dlopen动态加载的模块、mmap分配的匿名内存页，甚至memfd_create创建的内存文件。我在分析某金融App的SO时，发现其核心算法被加载到[anon:memfd:libcrypto]区域，/proc/pid/maps只显示[anon]，而dmm直接给出memfd标识，让我快速定位到加密密钥所在内存页。

4.2dcu：继续执行直到——动态分析的精准手术刀

dcu（Debug Continue Until）是r2frida最常用、也最容易被误解的命令。它不是GDB的continue，而是“在Frida注入后，用radare2调试器接管执行流，运行到指定位置”。

基本语法：dcu [address|symbol|offset]

• dcu main—— 运行到main函数入口（需符号）
• dcu 0x7f8a3c102a4—— 运行到绝对地址
• dcu +0x100—— 从当前PC+0x100处断下

但真正威力在于符号同步后的智能断点：

# 先用dmm同步模块 dmm # 查看libnative.so的符号 is~libnative.so # 发现目标函数是sym.Java_com_example_app_NativeBridge_encrypt dcu sym.Java_com_example_app_NativeBridge_encrypt

此时，r2frida会自动计算libnative.so的运行时基址，加上sym.Java_com_example_app_NativeBridge_encrypt在文件中的偏移，得到真实断点地址，并在该地址设置硬件断点（ARM64用brk指令）。当App调用该JNI函数时，执行流立即暂停，你可以：

• dr查看所有寄存器（r0是JNIEnv*,r1是jobject,r2是jstring参数）
• px 64 @ r2dump jstring指向的UTF-16字符串
• s r2跳转到字符串地址，用iz（strings）命令提取明文

避坑指南：dcu对符号解析高度依赖aa分析结果。如果aa没跑完就dcu，可能找不到符号。我的习惯是：连接后先dmm，再s 0x7f8a3c0000跳到SO基址，然后aa，最后dcu。另外，dcu断下后，dr看到的寄存器是断点触发瞬间的快照，不是函数入口参数——ARM64的JNI函数参数在r0-r7，但断点在函数开头时，r0-r7已被压栈或重用。正确做法是dcu后立刻ds（step into）一次，进入函数体第一行，此时r0-r7才是原始参数。

4.3!frida：在radare2中执行任意Frida脚本——打破工具边界

!frida命令是r2frida的“逃生舱口”，当你需要radare2原生命令无法覆盖的高级能力时，它让你无缝切入Frida JavaScript世界。

语法：!frida [options] [script]

• !frida -c "console.log('Hello from r2frida')"—— 执行一行JS
• !frida -c "send(Process.enumerateModules())"—— 调用Frida API并接收返回
• !frida ./hook.js—— 执行本地JS脚本

最实用的场景是内存内容转换：

# 在radare2中，你用px看到一串十六进制：0x12345678处是48字节密文 px 48 @ 0x12345678 # 但你想把它转成Base64发给后端解密服务 !frida -c "send(hexdump(Memory.readByteArray(ptr('0x12345678'), 48)).replace(/\\n/g, ''))" # 或者直接调用Java层解密（假设已有Java VM） !frida -c "Java.perform(function(){var cls = Java.use('com.example.Decryptor'); var res = cls.decryptSync(Memory.readByteArray(ptr('0x12345678'), 48)); send(res);})"

!frida的返回值会以JSON格式显示在radare2终端，你可以复制粘贴，或用?命令进一步处理。它让radare2从“分析器”升级为“分析+执行+验证”一体化平台。

实战技巧：!frida执行的JS脚本，其send()函数返回的数据，会被radare2捕获并格式化显示。但如果脚本中有console.log()，输出会直接打印到终端，不被捕获。所以调试复杂脚本时，优先用send()，而不是console.log()。

5. 高阶实战：破解某银行App SO加固模块的完整推演

5.1 场景还原：一个真实的“卡点”问题

某银行App的libsecurity.so采用自研加固，特征如下：

• 所有JNI函数名被替换为Java_xxx_yyy_zzz格式，无业务语义
• .text段被加密，r2 -A分析失败，aaa后函数体全是invalid指令
• 关键交易签名逻辑在Java_com_bank_app_SecurityBridge_signTransaction中，但该函数内部调用dlsym动态加载另一个SO（libcrypto_arm.so）并执行EVP_SignFinal
• libcrypto_arm.so不随APK分发，运行时从服务器下载并mmap到内存，/proc/pid/maps中只显示[anon:libcrypto]

传统方案在此完全失效：radare2看不到加密后的代码，Frida hook不到dlsym之后的EVP_SignFinal（因为符号不存在），GDB attach后无法加载调试符号。

5.2 r2frida破局四步法

第一步：启动并同步内存（dmm）

r2 -A -e cfg.debug=true r2frida://usb//com.bank.app [0x00000000]> dmm # 发现libsecurity.so基址：0x7f8a3c0000 # 发现[anon:libcrypto]区域：0x7f8a400000 - 0x7f8a420000

第二步：定位并解密.text段（px+!frida）

# 查看libsecurity.so .text段起始（通常在基址+0x1000） s 0x7f8a3c0000+0x1000 px 64 # 发现前4字节是0x454c4600（ELF魔数？不对，这是加密特征） # 用!frida执行解密脚本（假设已知AES-ECB密钥） !frida ./decrypt_text.js 0x7f8a3c0000+0x1000 0x20000 # 脚本返回：decrypted 131072 bytes to 0x7f8a3c1000 s 0x7f8a3c1000 aa # 此时aaa能正确分析解密后的代码

第三步：Hookdlsym并捕获libcrypto_arm.so真实地址（dcu+db）

# 先找到dlsym在libc中的地址（用dmm找libc基址，再iM找dlsym偏移） dmm~libc # libc基址：0x7f8a380000 # iM libc | grep dlsym -> offset 0x123456 s 0x7f8a380000+0x123456 dcu # 断在dlsym调用前 # 查看参数：r0是handle（通常为RTLD_DEFAULT），r1是symbol name dr r1 # r1指向字符串"libcrypto_arm.so"，确认！ # 单步执行dlsym，看返回值（r0） ds dr r0 # r0 = 0x7f8a400000，正是[anon:libcrypto]基址！

第四步：在libcrypto_arm.so中定位EVP_SignFinal并dump签名（s+px）

# 跳转到libcrypto基址 s 0x7f8a400000 # 用radare2的字符串搜索找EVP_SignFinal（即使被混淆，字符串常量还在） izz~EVP_SignFinal # 找到地址0x7f8a40a1234，用dcu断下 dcu 0x7f8a40a1234 # 此时r0是EVP_MD_CTX*，r1是signature buffer，r2是siglen dr r1 r2 # r1=0x7f8a456789, r2=0x100 px @ r1 # dump出256字节签名

整个过程在单一r2会话中完成，无需切换工具、无需手动计算、无需猜测地址。dmm提供全局内存视图，dcu实现精准断点，!frida突破能力边界，aa在解密后恢复静态分析——这就是r2frida定义的“终极动态分析工作流”。

最后分享一个小技巧：在分析过程中，用H命令（History）可以回溯所有执行过的命令，复制粘贴形成可复现的分析脚本。我常把dmm; s 0x7f8a3c0000; aa; dcu sym.Java_com_bank_app_SecurityBridge_signTransaction; dr; px 64 @ r2这一串保存为bank_sign.r2，下次分析新版本时，只需r2 -A -e cfg.debug=true r2frida://usb//com.bank.app -i bank_sign.r2，一键重放。这才是生产力的本质。