Frida实战hook Flutter App：拦截Dart层加密通信
最近在逆向一个Flutter写的Android App，目标是把它的加密通信参数搞出来。Flutter的坑在于它把Dart代码全编译成native了，不像普通Java App那样能直接用jadx反编译，通信层的加密也不在Java层，得在so里面找。第一步是定位关键so。Flutter编译出来的libapp.so就是Dart业务逻辑编译后的产物，体积通常很大，这个App的有38MB。先用frida-trace跑了一遍SSL_write和SSL_read，发现它用的不是标准BoringSSL，加密函数被重命名过了，trace抓不到明文。
https://www.metk.cn/img/posts/frida_flutter_hook_01.jpg
换了个思路，直接hook了BoringSSL的底层函数。Flutter的加密通信走的还是底层的ssl_crypto_encrypt这个函数，在libflutter.so里面。写了个Frida脚本，hook这个函数打印入参buffer和长度，果然拿到了加密前的明文请求体。关键代码贴出来：
function hookSSL() {
var func = Module.findExportByName("libflutter.so", "ssl_crypto_encrypt");
Interceptor.attach(func, {
onEnter: function(args) {
console.log("plaintext:", args.readUtf8String());
}
});
}
有个细节要注意，不同Flutter版本里libflutter.so的导出符号名不一样，1.x的版本可能叫ssl3_encrypt，3.x的才叫ssl_crypto_encrypt。建议先用nm -D列一遍导出表确认名字。另外ARM64和ARM32的参数寄存器不一样，x0到x7传参，上面的代码是ARM64的写法。 这个角度之前没想过，受教了。 混淆只能提高门槛，不能真正阻止有心人。想请教下工具链是怎么配的？ 关键算法的定位比还原实现更耗时间。 如果是防护方视角，重点应该放在提升攻击成本上。 这类校验现在很多是服务端下发的，光改本地没用。 之前分析过类似的，混淆还原完逻辑其实不复杂。 实际做的时候最花时间的是环境搭建而不是分析本身。 如果只是学习目的，建议从开源项目练手，别碰线上。想请教下工具链是怎么配的？ 加固厂商之间差异挺大，同一套思路不一定通用。这套思路对其他 App 通用吗？