MemRelay/projects/280dd2a0-d23d-4a71-91e1-dce4353163be/MuMu x86_64 上 Frida 无法 hook libc syscall wrapper.md

title, type, permalink, stable_id, scope, memory_type, project_id, usage_profile_id, status, revision, request_id, created_at, updated_at, tags

title	type	permalink	stable_id	scope	memory_type	project_id	usage_profile_id	status	revision	request_id	created_at	updated_at	tags
MuMu x86_64 上 Frida 无法 hook libc syscall wrapper	experience	main/projects/280dd2a0-d23d-4a71-91e1-dce4353163be/mu-mu-x86-64-上-frida-无法-hook-libc-syscall-wrapper	52c0da1c-424b-4a77-8146-ed1190b4f20f	project	experience	280dd2a0-d23d-4a71-91e1-dce4353163be	0c9feb46-d06e-43cd-9ef0-c5813c84a998	active	1	rapdrama-exp-frida-libc-fail-20260925-0518	2026-09-24T21:30:23.821540+00:00	2026-09-24T21:30:23.821540+00:00	frida libc mumu x86_64 卡点

最终结论

在 MuMu 12 x86_64 模拟器上，Frida 17.18 的 Interceptor.attach 对 bionic libc 的短 syscall wrapper 函数（connect、read、write、send、recv、sendmsg、recvmsg、sendto、recvfrom）全部无法触发。甚至 Interceptor.replace 和对 libc 的 syscall() wrapper 的 hook 也不触发。但对 libflutter.so 内部的较大函数（如 SSL verify 偏移 0x8113ee）和 libc 的 getaddrinfo 能正常 hook。

原因推测：bionic libc 在 x86_64 上的 connect/read/write 实现只有几条指令，Frida 的 trampoline 无法安全插入。或者 MuMu 的虚拟化环境对内存写入保护有特殊处理。

libflutter.so 确实导入了 libc 的 connect，但 Dart VM 的网络调用不经过这些导入（可能是编译优化内联了 syscall，或者用了其他路径）。已确认 libflutter.so 中没有独立的 0f 05 syscall 指令。socket() 能被捕获，connect() 不能。

mitmproxy 透明模式在 Windows 上会启用 WinDivert 拦截宿主机所有流量，曾导致用户电脑网络断开，重启才恢复。绝对不要再用 mitmproxy transparent 模式。

而且即使 mitmproxy 在 Windows 上跑得起来，模拟器内部的 iptables DNAT 到宿主机后，Windows 上的 mitmproxy 拿不到 SO_ORIGINAL_DST（这是 Linux 内核特性），无法知道原始目标。

可行方案

剩下唯一可靠的方案是 reFlutter 重打包：patch libflutter.so 内置代理地址并禁用 SSL 验证，重签 APK 后安装。缺点：签名变化可能影响谷歌登录，每次 App 更新要重做。