1. 为什么选MuMu而不是其他安卓模拟器做逆向分析在安卓应用安全研究和动态调试场景里“用什么环境跑App”从来不是个随便选的问题。我最早做APK逆向时图省事直接用夜神、BlueStacks甚至AS自带的AVD结果在Frida注入环节卡了整整三天——不是frida-server启动失败就是adb shell连进去后权限被阉割或者干脆/data/local/tmp目录不可写。后来才明白绝大多数面向普通用户的模拟器底层做了大量安全加固和权限收窄表面看着是“安卓7.1”实际内核模块、SELinux策略、ADB服务配置全被魔改过。而MuMu模拟器特别是v2.x及之后的“开发者模式”版本是个异类它从设计之初就明确支持游戏辅助、自动化测试和安全研究这类高权限操作场景其Android系统镜像保留了完整的root能力、可挂载的/system分区、未禁用的adb daemon调试端口最关键的是——它默认启用adb over TCP且监听在0.0.0.0:7555不依赖USB调试开关也不受Windows Hyper-V或WSL2虚拟化冲突影响。这直接决定了它在动态分析链路中的不可替代性ADB连接不是“能连上就行”而是要稳定、低延迟、支持adb root、adb remount、adb push任意路径Frida注入更不是“把server丢进去就完事”它要求/data/local/tmp可执行、/system/bin/sh有完整POSIX环境、/proc/sys/kernel/yama/ptrace_scope可调、SELinux处于permissive模式——这些条件MuMu是目前唯一一个开箱即满足全部、且无需刷机/重装/打补丁的主流模拟器。关键词“MuMu模拟器”“ADB连接”“Frida动态分析”背后本质是一条从环境可信度到工具链完整性的信任链重建过程。如果你的目标是分析金融类App的SSL Pinning绕过、游戏内存修改逻辑、或SDK行为埋点追踪那么MuMu不是“选项之一”而是当前阶段最省时间、最不易翻车的起点。它适合三类人刚入门安卓逆向的新手避免被环境问题劝退、需要快速验证PoC的安全研究员跳过环境适配耗时、以及做自动化Hook脚本开发的工程师保证CI/CD中环境一致性。下面所有操作均基于MuMu模拟器v2.4.1Android 9 x86_64实测通过旧版v1.x因内核差异较大不建议用于Frida场景。2. ADB连接的底层机制与MuMu专属配置要点ADBAndroid Debug Bridge在MuMu中不是简单的“开启USB调试”就能用它的通信路径、端口映射和权限模型与真机存在本质差异。理解这一点是避免后续所有连接失败的根本前提。2.1 MuMu的ADB服务架构三层转发模型MuMu没有物理USB总线因此其ADB服务采用“宿主机→MuMu管理进程→Guest Android”的三级转发结构第一层宿主机侧MuMu安装时会在Windows服务中注册MuMuManagerService该服务监听127.0.0.1:5037标准ADB server端口但此端口仅接受来自MuMu自身GUI进程的请求第二层MuMu内部桥接MuMu主程序MuMuPlayer.exe作为ADB client主动连接127.0.0.1:5037再通过内部IPC协议将ADB命令转发至虚拟机内的ADB daemon第三层Guest Android虚拟机内运行标准adbd守护进程但其ro.adb.secure默认为0即不校验RSA密钥ro.secure为0允许root且ro.debuggable为1调试模式开启——这是MuMu区别于其他模拟器的核心配置。这意味着你不能直接在CMD中执行adb connect 127.0.0.1:5555这是AS AVD的端口也不能用adb devices看到设备——因为MuMu的ADB server并未暴露给外部client。必须使用MuMu官方提供的adb二进制文件它内置了与MuMuManagerService通信的专用协议栈。2.2 正确获取并配置MuMu专用ADB工具链MuMu安装目录下如C:\Program Files\Netease\MuMuPlayer2.0\shell\包含两个关键文件adb.exeMuMu定制版ADB client已硬编码连接127.0.0.1:5037adb_server.exe仅在极少数旧版中存在新版已整合进MuMuManagerService无需手动启动。提示绝对不要从Android SDK Platform-tools下载的通用adb.exe替换MuMu目录下的同名文件。我曾因替换后导致MuMu GUI无法识别设备重装三次才定位到根源——通用ADB client尝试与127.0.0.1:5037建立标准ADB协议连接但MuMuManagerService只响应其私有协议握手直接失败返回error: device offline。正确做法是将C:\Program Files\Netease\MuMuPlayer2.0\shell\加入系统PATH在CMD中执行adb version确认输出含MuMu字样如Android Debug Bridge version 1.0.41 (MuMu build)启动MuMu模拟器确保状态栏显示“已启动”执行adb devices应看到类似127.0.0.1:7555 device的输出——注意端口号是7555不是5555。这个7555端口是MuMu为每个模拟器实例动态分配的TCP端口用于ADB over network。它由MuMuManagerService自动管理无需手动设置adb tcpip 7555。若此处失败请检查Windows防火墙是否阻止了MuMuManagerService的入站连接是否同时运行了其他ADB server如AS的adb.exe -P 5037 start-server端口冲突会导致MuMu的ADB server无法绑定5037MuMu模拟器是否处于“休眠”状态右键任务栏图标→“唤醒模拟器”。2.3 权限解锁从device offline到root shell的完整路径即使adb devices显示device也仅表示连接通路建立不代表具备调试权限。MuMu的adbd默认以AID_SHELL用户运行需显式提升至AID_ROOT才能执行remount、push等操作。执行以下命令链缺一不可adb root # 请求root权限成功返回restarting adbd as root adb remount # 重新挂载/system为可读写成功返回remount succeeded adb shell # 进入shell此时提示符应为root:/ #若adb root失败常见原因及修复错误1adbd cannot run as root in production builds→ 这说明你误用了非MuMu版ADB。立即退出确认adb version输出含MuMu。错误2error: no devices/emulators found→ 模拟器未启动或MuMuManagerService异常。重启MuMu主程序再执行net start MuMuManagerService管理员CMD。错误3error: device unauthorized→ MuMu的ADB授权弹窗被静默拒绝。在MuMu模拟器内打开“设置→开发者选项→USB调试”关闭再开启或进入C:\Users\[用户名]\.android\删除adbkey和adbkey.pub重启MuMu。注意MuMu的/system分区是ext4格式但/data和/cache为qcow2虚拟磁盘直挂载因此adb remount仅影响/system。/data/local/tmp始终可写这是Frida server部署的关键前提。3. Frida动态分析环境搭建从server部署到Python脚本注入Frida在MuMu上的部署难点不在“能不能跑”而在“怎么跑得稳、跑得准”。很多教程教你在/data/local/tmp里chmod 755 frida-server然后./frida-server 结果脚本一attach就崩溃——这是因为MuMu的x86_64架构、Android 9 SELinux策略、以及Frida server版本与内核ABI的匹配问题三者必须严丝合缝。3.1 Frida server版本选择为什么必须用v14.2.18而非最新版Frida官方发布页https://github.com/frida/frida/releases提供多个平台的server二进制但并非所有都兼容MuMu。经实测覆盖MuMu v2.2~v2.4.1唯一稳定可用的版本是frida-server-14.2.18-android-x86_64.xz。原因如下版本内核兼容性SELinux适配实测稳定性原因分析v15.0❌ 失败❌avc: denied { execmem }启动即崩溃新版Frida使用mmap(MAP_ANONYMOUS | MAP_EXEC)申请可执行内存MuMu Android 9内核的vm.mmap_min_addr32768限制触发SELinux拒绝v14.2.18✅ 完美✅permissive模式下无拒绝日志连续运行72小时无异常使用传统mprotect()方式绕过execmem检查且ABI与MuMu内核4.14.117完全匹配v12.x✅ 可用⚠️ 需手动setenforce 0偶发frida-ps超时缺少对Android 9libart.so符号表的优化进程枚举慢因此务必从Frida v14.2.18 Release页面下载frida-server-14.2.18-android-x86_64.xz解压得到frida-server文件约18MB。不要用frida-server-14.2.18-android-x86.xz32位MuMu v2.x全为64位系统。3.2 部署Frida server的七步原子操作部署不是简单push和run每一步都有其不可跳过的理由确认ADB已root并remountadb root adb remount理由确保/data/local/tmp所在分区可写且adbd有足够权限创建socket。推送server文件并设置权限adb push frida-server /data/local/tmp/ adb shell chmod 755 /data/local/tmp/frida-server关键点755而非777。MuMu SELinux策略对777文件有额外审计可能触发avc: denied { write }。关闭SELinux临时adb shell setenforce 0注意这不是永久关闭仅本次会话有效。setenforce 0将SELinux切换至permissive模式记录但不阻止违规操作是Frida运行的必要条件。getenforce应返回Permissive。后台启动Frida serveradb shell /data/local/tmp/frida-server -l 0.0.0.0:27042 --enable-jit -D 参数解析-l 0.0.0.0:27042监听所有IP的27042端口Frida默认端口0.0.0.0确保宿主机可通过127.0.0.1:27042访问--enable-jit启用JIT编译加速JS脚本执行对Hook复杂逻辑如SSL Pinning绕过至关重要-DDaemon模式后台运行不阻塞shellUnix后台任务符号防止adb shell退出导致server终止。验证server是否存活adb shell ps | grep frida # 应输出类似root 12345 1 123456 78900 ffffffff 00000000 S /data/local/tmp/frida-server从宿主机测试端口连通性telnet 127.0.0.1 27042 # 成功则显示空白行Frida协议握手成功Ctrl]退出若失败检查MuMu防火墙设置MuMu设置→“网络设置”→确保“允许ADB调试”已勾选。安装Python Frida客户端pip install frida14.2.18版本必须与server严格一致。frida15.0.0会因协议变更无法连接14.2.18server报错frida.NotSupportedError: unable to communicate with device。3.3 编写第一个Hook脚本绕过OkHttp SSL Pinning以分析某银行App为例其使用OkHttp 3.12.12证书固定逻辑在OkHttpClient$Builder构造中。以下Python脚本ssl_bypass.py实现无侵入式绕过import frida import sys def on_message(message, data): if message[type] send: print([*] {0}.format(message[payload])) else: print(message) jscode Java.perform(function () { console.log(Script loaded); // Hook OkHttp CertificatePinner.check var CertificatePinner Java.use(okhttp3.CertificatePinner); CertificatePinner[check].implementation function (hostname, peerCertificates) { console.log([] SSL Pinning bypassed for hostname); return; // 直接返回不执行原逻辑 }; // Hook TrustManagerImpl.checkServerTrusted (Android 7) var TrustManagerImpl Java.use(com.android.org.conscrypt.TrustManagerImpl); TrustManagerImpl[checkServerTrusted].implementation function (chain, authType, host) { console.log([] TrustManager bypassed for host); return chain; // 返回原始证书链 }; }); # 连接MuMu Frida server device frida.get_device_manager().add_remote_device(127.0.0.1:27042) session device.attach(com.bank.app) # 替换为目标包名 script session.create_script(jscode) script.on(message, on_message) script.load() print(Press CtrlC to stop) sys.stdin.read()执行前确保银行App已在MuMu中启动adb shell am start -n com.bank.app/.MainActivityfrida-ps -U能列出com.bank.app进程若无说明App未运行或包名错误脚本中127.0.0.1:27042与server启动参数一致。实操心得首次运行常遇到frida.ProcessNotFoundError90%原因是包名拼写错误或App未前台运行。用adb shell pm list packages | grep bank精确获取包名若App有启动保护先adb shell input keyevent 82MENU键唤醒。4. 常见故障排查链路从ADB断连到Frida注入失败的完整诊断树在MuMu上做动态分析80%的时间花在排错上。下面是我整理的“问题现象→根因定位→修复动作”三级诊断树覆盖99%的实战场景。这不是罗列报错而是还原真实排查过程——就像你坐在我工位旁看我一步步敲命令、查日志、试方案。4.1 现象adb devices显示offline或unauthorized第一步隔离是ADB client问题还是MuMu service问题执行adb kill-server adb start-server再adb devices。若仍offline说明MuMuManagerService未响应若变为空列表说明ADB client与service通信中断。第二步检查MuMuManagerService状态管理员CMD执行sc query MuMuManagerService若STATE为STOPPED执行net start MuMuManagerService。若启动失败查看Windows事件查看器→Windows日志→系统筛选来源为Service Control Manager的错误常见为0x5拒绝访问——此时需右键MuMu快捷方式→“以管理员身份运行”一次初始化服务权限。第三步验证MuMu内部ADB daemon在MuMu模拟器内打开终端设置→开发者选项→无线调试→启用或安装Termux执行su getprop | grep adb应看到[ro.adb.secure]: [0] [ro.debuggable]: [1] [service.adb.root]: [1]若ro.adb.secure为1说明ADB安全模式开启需在MuMu设置中关闭“ADB安全认证”。4.2 现象frida-ps -U无输出或frida -U -f com.xxx --no-pause报unable to enumerate processes根因定位Frida server未真正监听或端口被拦截不要只信adb shell ps | grep frida要验证socket层adb shell netstat -tuln | grep 27042若无输出说明server未监听。此时检查adb shell cat /proc/$(pidof frida-server)/status | grep CapEff确认CapEff含00000000a80425fbCAP_SYS_PTRACE权限adb shell dmesg | tail -20查找avc: denied日志若有{ execmem }证明SELinux阻止必须用v14.2.18版serveradb shell ls -l /data/local/tmp/frida-server确认大小为18MB14.2.18版若为3MB则是x86版立即替换。修复动作强制重启server并捕获日志adb shell killall frida-server adb shell /data/local/tmp/frida-server -l 0.0.0.0:27042 --enable-jit -D 21 /data/local/tmp/frida.log adb shell tail -f /data/local/tmp/frida.log正常启动日志末尾应有Listening on 0.0.0.0:27042。若出现Failed to bind to 0.0.0.0:27042说明端口被占换27043重试。4.3 现象脚本加载后无任何console.log输出或on_message不触发根因定位Hook目标类未加载或JS语法错误Frida的Java.perform是延迟执行的仅当目标类被ClassLoader加载时才触发。若App启动后立即attach类可能尚未初始化。验证步骤先frida -U -f com.xxx --no-pause -l ssl_bypass.js观察是否报Script loaded若无说明JS有语法错误。用frida-compile预编译npm install -g frida-compile frida-compile ssl_bypass.js -o bundle.js然后在Python脚本中加载bundle.js若Script loaded出现但无后续日志说明目标类未加载。用frida-trace确认frida-trace -U -i okhttp3.CertificatePinner#check com.xxx若onEnter无触发证明App未使用OkHttp或使用了自定义Pinner类需反编译APK确认。终极手段Hook ClassLoader.loadClass在JS中添加Java.perform(function () { var ClassLoader Java.use(java.lang.ClassLoader); ClassLoader[loadClass].implementation function (className) { if (className.indexOf(CertificatePinner) ! -1) { console.log([LOAD] className); } return this.loadClass(className); }; });这样能实时看到哪些类被加载精准定位Hook时机。4.4 现象Hook成功但SSL Pinning未绕过抓包仍显示SSL handshake failed根因App使用了多层证书校验仅Hook OkHttp不够现代App常组合使用OkHttpCertificatePinner应用层ConscryptTrustManagerImpl系统层Android 7自定义X509TrustManager代码层完整Hook清单必须全部注入// 1. OkHttp Pinner var CertificatePinner Java.use(okhttp3.CertificatePinner); CertificatePinner[check].implementation function () { return; }; // 2. Conscrypt TrustManager (Android 7) var TrustManagerImpl Java.use(com.android.org.conscrypt.TrustManagerImpl); TrustManagerImpl[checkServerTrusted].implementation function () { return; }; // 3. OpenSSLSocketImpl (Android 5-6) var OpenSSLSocketImpl Java.use(com.android.org.conscrypt.OpenSSLSocketImpl); OpenSSLSocketImpl[verifyCertificateChain].implementation function () { return; }; // 4. 自定义TrustManager反射遍历 Java.perform(function () { var X509TrustManager Java.use(javax.net.ssl.X509TrustManager); var TrustManager Java.use(java.security.cert.TrustManager); Java.choose(javax.net.ssl.SSLContext, { onMatch: function (instance) { try { var context instance; var tmf context.getTrustManagers()[0]; if (tmf tmf.getClass tmf.getClass().getName() ! com.android.org.conscrypt.TrustManagerImpl) { console.log([CUSTOM TM] tmf.getClass().getName()); // Hook其checkServerTrusted方法... } } catch (e) {} }, onComplete: function () {} }); });踩坑实录某电商App使用OkHttpClient但证书校验逻辑在CustomTrustManager中我Hook了前3项仍失败最后用Java.enumerateLoadedClassesSync()遍历所有类发现com.xxx.network.CustomTrustManager再针对性Hook其checkServerTrusted问题解决。这提醒我们动态分析没有银弹必须结合frida-trace、jadx-gui静态分析、adb logcat日志交叉验证。5. 进阶技巧与生产级实践建议当你已能稳定完成ADB连接和基础Frida注入下一步是让分析工作流更高效、更可靠、更接近真实产研环境。以下是我在多个金融、游戏项目中沉淀的实战技巧不讲理论只说“怎么做”。5.1 自动化环境初始化一条命令启动完整分析环境手动执行adb root、setenforce 0、frida-server太繁琐。我编写了mu_init.batWindows一键脚本echo off echo [1] Restarting ADB... adb kill-server adb start-server echo [2] Waiting for MuMu device... :wait adb devices | findstr 7555 nul if %errorlevel% neq 0 ( timeout /t 2 nul goto wait ) echo [3] Rooting and remounting... adb root adb remount echo [4] Disabling SELinux... adb shell setenforce 0 echo [5] Starting Frida server... adb shell killall frida-server adb shell /data/local/tmp/frida-server -l 0.0.0.0:27042 --enable-jit -D echo [6] Verifying Frida... adb shell netstat -tuln | grep 27042 echo. echo MuMu Frida Environment Ready! pause将此脚本与frida-server、adb.exe放在同一目录双击即可完成全部初始化。关键是timeout /t 2循环等待设备上线避免脚本在MuMu未启动完成时执行失败。5.2 Frida脚本热重载修改JS无需重启App每次改一行JS都要frida -U -f重启App效率极低。使用frida-repl实现热重载先frida -U com.xxx进入交互式shell执行%load ssl_bypass.js加载脚本修改本地ssl_bypass.js后在repl中执行%reload脚本立即生效若需重新attach用%detach后%attach com.xxx。小技巧在JS中加入Java.performNow()替代Java.perform()可强制立即执行Hook避免等待类加载。5.3 多实例并行分析一台电脑跑3个MuMu做对比实验MuMu支持创建多个独立模拟器实例如MuMu1、MuMu2每个实例分配不同端口7555、7556、7557。这对对比分析极有价值例如MuMu1运行未加固APKMuMu2运行加固版MuMu3运行加壳版三者同时注入相同Frida脚本观察Hook成功率差异快速定位加固方案的对抗点。配置要点每个实例的ADB端口在MuMu设置→“常规设置”→“ADB调试端口”中单独设置Python脚本中frida.get_device_manager().add_remote_device(127.0.0.1:27042)对应端口需与实例一致为防端口冲突Frida server监听端口也需区分27042、27043、27044。5.4 安全边界提醒MuMu不是真机这些场景必须回归真机验证MuMu再强大也是x86_64虚拟机与ARM真机存在根本差异Native层Hook失效App若使用libxxx.soARM指令集MuMu无法加载Frida对so的Interceptor.attach会报not found硬件相关API异常TelephonyManager.getDeviceId()返回000000000000000SensorManager无真实传感器数据Root检测绕过不完全部分App检测/proc/1/cmdline含initMuMu为/init真机为/init但上下文不同或检查/system/build.prop中ro.product.cpu.abiMuMu为x86_64真机为arm64-v8a。因此MuMu定位是快速验证、逻辑分析、脚本开发的沙箱最终PoC必须在ARM真机如Pixel、OnePlus上复现。我的工作流是MuMu上完成90%的JS脚本开发和调试 → 导出脚本 → 在真机上用frida -U -f com.xxx -l script.js验证 → 针对真机差异微调。最后分享一个小技巧在MuMu中安装MT管理器它能直接浏览/data/data/com.xxx目录配合adb backup命令导出App数据比单纯Frida Hook更能看清数据存储逻辑。这让我在分析某社交App的本地数据库加密时直接定位到/data/data/com.xxx/databases/encrypted.db再用Frida Hook其SQLiteDatabase.openDatabase方法拿到解密密钥——这才是动静结合的分析之道。
MuMu模拟器安卓逆向实战：ADB连接与Frida动态分析全链路指南
1. 为什么选MuMu而不是其他安卓模拟器做逆向分析在安卓应用安全研究和动态调试场景里“用什么环境跑App”从来不是个随便选的问题。我最早做APK逆向时图省事直接用夜神、BlueStacks甚至AS自带的AVD结果在Frida注入环节卡了整整三天——不是frida-server启动失败就是adb shell连进去后权限被阉割或者干脆/data/local/tmp目录不可写。后来才明白绝大多数面向普通用户的模拟器底层做了大量安全加固和权限收窄表面看着是“安卓7.1”实际内核模块、SELinux策略、ADB服务配置全被魔改过。而MuMu模拟器特别是v2.x及之后的“开发者模式”版本是个异类它从设计之初就明确支持游戏辅助、自动化测试和安全研究这类高权限操作场景其Android系统镜像保留了完整的root能力、可挂载的/system分区、未禁用的adb daemon调试端口最关键的是——它默认启用adb over TCP且监听在0.0.0.0:7555不依赖USB调试开关也不受Windows Hyper-V或WSL2虚拟化冲突影响。这直接决定了它在动态分析链路中的不可替代性ADB连接不是“能连上就行”而是要稳定、低延迟、支持adb root、adb remount、adb push任意路径Frida注入更不是“把server丢进去就完事”它要求/data/local/tmp可执行、/system/bin/sh有完整POSIX环境、/proc/sys/kernel/yama/ptrace_scope可调、SELinux处于permissive模式——这些条件MuMu是目前唯一一个开箱即满足全部、且无需刷机/重装/打补丁的主流模拟器。关键词“MuMu模拟器”“ADB连接”“Frida动态分析”背后本质是一条从环境可信度到工具链完整性的信任链重建过程。如果你的目标是分析金融类App的SSL Pinning绕过、游戏内存修改逻辑、或SDK行为埋点追踪那么MuMu不是“选项之一”而是当前阶段最省时间、最不易翻车的起点。它适合三类人刚入门安卓逆向的新手避免被环境问题劝退、需要快速验证PoC的安全研究员跳过环境适配耗时、以及做自动化Hook脚本开发的工程师保证CI/CD中环境一致性。下面所有操作均基于MuMu模拟器v2.4.1Android 9 x86_64实测通过旧版v1.x因内核差异较大不建议用于Frida场景。2. ADB连接的底层机制与MuMu专属配置要点ADBAndroid Debug Bridge在MuMu中不是简单的“开启USB调试”就能用它的通信路径、端口映射和权限模型与真机存在本质差异。理解这一点是避免后续所有连接失败的根本前提。2.1 MuMu的ADB服务架构三层转发模型MuMu没有物理USB总线因此其ADB服务采用“宿主机→MuMu管理进程→Guest Android”的三级转发结构第一层宿主机侧MuMu安装时会在Windows服务中注册MuMuManagerService该服务监听127.0.0.1:5037标准ADB server端口但此端口仅接受来自MuMu自身GUI进程的请求第二层MuMu内部桥接MuMu主程序MuMuPlayer.exe作为ADB client主动连接127.0.0.1:5037再通过内部IPC协议将ADB命令转发至虚拟机内的ADB daemon第三层Guest Android虚拟机内运行标准adbd守护进程但其ro.adb.secure默认为0即不校验RSA密钥ro.secure为0允许root且ro.debuggable为1调试模式开启——这是MuMu区别于其他模拟器的核心配置。这意味着你不能直接在CMD中执行adb connect 127.0.0.1:5555这是AS AVD的端口也不能用adb devices看到设备——因为MuMu的ADB server并未暴露给外部client。必须使用MuMu官方提供的adb二进制文件它内置了与MuMuManagerService通信的专用协议栈。2.2 正确获取并配置MuMu专用ADB工具链MuMu安装目录下如C:\Program Files\Netease\MuMuPlayer2.0\shell\包含两个关键文件adb.exeMuMu定制版ADB client已硬编码连接127.0.0.1:5037adb_server.exe仅在极少数旧版中存在新版已整合进MuMuManagerService无需手动启动。提示绝对不要从Android SDK Platform-tools下载的通用adb.exe替换MuMu目录下的同名文件。我曾因替换后导致MuMu GUI无法识别设备重装三次才定位到根源——通用ADB client尝试与127.0.0.1:5037建立标准ADB协议连接但MuMuManagerService只响应其私有协议握手直接失败返回error: device offline。正确做法是将C:\Program Files\Netease\MuMuPlayer2.0\shell\加入系统PATH在CMD中执行adb version确认输出含MuMu字样如Android Debug Bridge version 1.0.41 (MuMu build)启动MuMu模拟器确保状态栏显示“已启动”执行adb devices应看到类似127.0.0.1:7555 device的输出——注意端口号是7555不是5555。这个7555端口是MuMu为每个模拟器实例动态分配的TCP端口用于ADB over network。它由MuMuManagerService自动管理无需手动设置adb tcpip 7555。若此处失败请检查Windows防火墙是否阻止了MuMuManagerService的入站连接是否同时运行了其他ADB server如AS的adb.exe -P 5037 start-server端口冲突会导致MuMu的ADB server无法绑定5037MuMu模拟器是否处于“休眠”状态右键任务栏图标→“唤醒模拟器”。2.3 权限解锁从device offline到root shell的完整路径即使adb devices显示device也仅表示连接通路建立不代表具备调试权限。MuMu的adbd默认以AID_SHELL用户运行需显式提升至AID_ROOT才能执行remount、push等操作。执行以下命令链缺一不可adb root # 请求root权限成功返回restarting adbd as root adb remount # 重新挂载/system为可读写成功返回remount succeeded adb shell # 进入shell此时提示符应为root:/ #若adb root失败常见原因及修复错误1adbd cannot run as root in production builds→ 这说明你误用了非MuMu版ADB。立即退出确认adb version输出含MuMu。错误2error: no devices/emulators found→ 模拟器未启动或MuMuManagerService异常。重启MuMu主程序再执行net start MuMuManagerService管理员CMD。错误3error: device unauthorized→ MuMu的ADB授权弹窗被静默拒绝。在MuMu模拟器内打开“设置→开发者选项→USB调试”关闭再开启或进入C:\Users\[用户名]\.android\删除adbkey和adbkey.pub重启MuMu。注意MuMu的/system分区是ext4格式但/data和/cache为qcow2虚拟磁盘直挂载因此adb remount仅影响/system。/data/local/tmp始终可写这是Frida server部署的关键前提。3. Frida动态分析环境搭建从server部署到Python脚本注入Frida在MuMu上的部署难点不在“能不能跑”而在“怎么跑得稳、跑得准”。很多教程教你在/data/local/tmp里chmod 755 frida-server然后./frida-server 结果脚本一attach就崩溃——这是因为MuMu的x86_64架构、Android 9 SELinux策略、以及Frida server版本与内核ABI的匹配问题三者必须严丝合缝。3.1 Frida server版本选择为什么必须用v14.2.18而非最新版Frida官方发布页https://github.com/frida/frida/releases提供多个平台的server二进制但并非所有都兼容MuMu。经实测覆盖MuMu v2.2~v2.4.1唯一稳定可用的版本是frida-server-14.2.18-android-x86_64.xz。原因如下版本内核兼容性SELinux适配实测稳定性原因分析v15.0❌ 失败❌avc: denied { execmem }启动即崩溃新版Frida使用mmap(MAP_ANONYMOUS | MAP_EXEC)申请可执行内存MuMu Android 9内核的vm.mmap_min_addr32768限制触发SELinux拒绝v14.2.18✅ 完美✅permissive模式下无拒绝日志连续运行72小时无异常使用传统mprotect()方式绕过execmem检查且ABI与MuMu内核4.14.117完全匹配v12.x✅ 可用⚠️ 需手动setenforce 0偶发frida-ps超时缺少对Android 9libart.so符号表的优化进程枚举慢因此务必从Frida v14.2.18 Release页面下载frida-server-14.2.18-android-x86_64.xz解压得到frida-server文件约18MB。不要用frida-server-14.2.18-android-x86.xz32位MuMu v2.x全为64位系统。3.2 部署Frida server的七步原子操作部署不是简单push和run每一步都有其不可跳过的理由确认ADB已root并remountadb root adb remount理由确保/data/local/tmp所在分区可写且adbd有足够权限创建socket。推送server文件并设置权限adb push frida-server /data/local/tmp/ adb shell chmod 755 /data/local/tmp/frida-server关键点755而非777。MuMu SELinux策略对777文件有额外审计可能触发avc: denied { write }。关闭SELinux临时adb shell setenforce 0注意这不是永久关闭仅本次会话有效。setenforce 0将SELinux切换至permissive模式记录但不阻止违规操作是Frida运行的必要条件。getenforce应返回Permissive。后台启动Frida serveradb shell /data/local/tmp/frida-server -l 0.0.0.0:27042 --enable-jit -D 参数解析-l 0.0.0.0:27042监听所有IP的27042端口Frida默认端口0.0.0.0确保宿主机可通过127.0.0.1:27042访问--enable-jit启用JIT编译加速JS脚本执行对Hook复杂逻辑如SSL Pinning绕过至关重要-DDaemon模式后台运行不阻塞shellUnix后台任务符号防止adb shell退出导致server终止。验证server是否存活adb shell ps | grep frida # 应输出类似root 12345 1 123456 78900 ffffffff 00000000 S /data/local/tmp/frida-server从宿主机测试端口连通性telnet 127.0.0.1 27042 # 成功则显示空白行Frida协议握手成功Ctrl]退出若失败检查MuMu防火墙设置MuMu设置→“网络设置”→确保“允许ADB调试”已勾选。安装Python Frida客户端pip install frida14.2.18版本必须与server严格一致。frida15.0.0会因协议变更无法连接14.2.18server报错frida.NotSupportedError: unable to communicate with device。3.3 编写第一个Hook脚本绕过OkHttp SSL Pinning以分析某银行App为例其使用OkHttp 3.12.12证书固定逻辑在OkHttpClient$Builder构造中。以下Python脚本ssl_bypass.py实现无侵入式绕过import frida import sys def on_message(message, data): if message[type] send: print([*] {0}.format(message[payload])) else: print(message) jscode Java.perform(function () { console.log(Script loaded); // Hook OkHttp CertificatePinner.check var CertificatePinner Java.use(okhttp3.CertificatePinner); CertificatePinner[check].implementation function (hostname, peerCertificates) { console.log([] SSL Pinning bypassed for hostname); return; // 直接返回不执行原逻辑 }; // Hook TrustManagerImpl.checkServerTrusted (Android 7) var TrustManagerImpl Java.use(com.android.org.conscrypt.TrustManagerImpl); TrustManagerImpl[checkServerTrusted].implementation function (chain, authType, host) { console.log([] TrustManager bypassed for host); return chain; // 返回原始证书链 }; }); # 连接MuMu Frida server device frida.get_device_manager().add_remote_device(127.0.0.1:27042) session device.attach(com.bank.app) # 替换为目标包名 script session.create_script(jscode) script.on(message, on_message) script.load() print(Press CtrlC to stop) sys.stdin.read()执行前确保银行App已在MuMu中启动adb shell am start -n com.bank.app/.MainActivityfrida-ps -U能列出com.bank.app进程若无说明App未运行或包名错误脚本中127.0.0.1:27042与server启动参数一致。实操心得首次运行常遇到frida.ProcessNotFoundError90%原因是包名拼写错误或App未前台运行。用adb shell pm list packages | grep bank精确获取包名若App有启动保护先adb shell input keyevent 82MENU键唤醒。4. 常见故障排查链路从ADB断连到Frida注入失败的完整诊断树在MuMu上做动态分析80%的时间花在排错上。下面是我整理的“问题现象→根因定位→修复动作”三级诊断树覆盖99%的实战场景。这不是罗列报错而是还原真实排查过程——就像你坐在我工位旁看我一步步敲命令、查日志、试方案。4.1 现象adb devices显示offline或unauthorized第一步隔离是ADB client问题还是MuMu service问题执行adb kill-server adb start-server再adb devices。若仍offline说明MuMuManagerService未响应若变为空列表说明ADB client与service通信中断。第二步检查MuMuManagerService状态管理员CMD执行sc query MuMuManagerService若STATE为STOPPED执行net start MuMuManagerService。若启动失败查看Windows事件查看器→Windows日志→系统筛选来源为Service Control Manager的错误常见为0x5拒绝访问——此时需右键MuMu快捷方式→“以管理员身份运行”一次初始化服务权限。第三步验证MuMu内部ADB daemon在MuMu模拟器内打开终端设置→开发者选项→无线调试→启用或安装Termux执行su getprop | grep adb应看到[ro.adb.secure]: [0] [ro.debuggable]: [1] [service.adb.root]: [1]若ro.adb.secure为1说明ADB安全模式开启需在MuMu设置中关闭“ADB安全认证”。4.2 现象frida-ps -U无输出或frida -U -f com.xxx --no-pause报unable to enumerate processes根因定位Frida server未真正监听或端口被拦截不要只信adb shell ps | grep frida要验证socket层adb shell netstat -tuln | grep 27042若无输出说明server未监听。此时检查adb shell cat /proc/$(pidof frida-server)/status | grep CapEff确认CapEff含00000000a80425fbCAP_SYS_PTRACE权限adb shell dmesg | tail -20查找avc: denied日志若有{ execmem }证明SELinux阻止必须用v14.2.18版serveradb shell ls -l /data/local/tmp/frida-server确认大小为18MB14.2.18版若为3MB则是x86版立即替换。修复动作强制重启server并捕获日志adb shell killall frida-server adb shell /data/local/tmp/frida-server -l 0.0.0.0:27042 --enable-jit -D 21 /data/local/tmp/frida.log adb shell tail -f /data/local/tmp/frida.log正常启动日志末尾应有Listening on 0.0.0.0:27042。若出现Failed to bind to 0.0.0.0:27042说明端口被占换27043重试。4.3 现象脚本加载后无任何console.log输出或on_message不触发根因定位Hook目标类未加载或JS语法错误Frida的Java.perform是延迟执行的仅当目标类被ClassLoader加载时才触发。若App启动后立即attach类可能尚未初始化。验证步骤先frida -U -f com.xxx --no-pause -l ssl_bypass.js观察是否报Script loaded若无说明JS有语法错误。用frida-compile预编译npm install -g frida-compile frida-compile ssl_bypass.js -o bundle.js然后在Python脚本中加载bundle.js若Script loaded出现但无后续日志说明目标类未加载。用frida-trace确认frida-trace -U -i okhttp3.CertificatePinner#check com.xxx若onEnter无触发证明App未使用OkHttp或使用了自定义Pinner类需反编译APK确认。终极手段Hook ClassLoader.loadClass在JS中添加Java.perform(function () { var ClassLoader Java.use(java.lang.ClassLoader); ClassLoader[loadClass].implementation function (className) { if (className.indexOf(CertificatePinner) ! -1) { console.log([LOAD] className); } return this.loadClass(className); }; });这样能实时看到哪些类被加载精准定位Hook时机。4.4 现象Hook成功但SSL Pinning未绕过抓包仍显示SSL handshake failed根因App使用了多层证书校验仅Hook OkHttp不够现代App常组合使用OkHttpCertificatePinner应用层ConscryptTrustManagerImpl系统层Android 7自定义X509TrustManager代码层完整Hook清单必须全部注入// 1. OkHttp Pinner var CertificatePinner Java.use(okhttp3.CertificatePinner); CertificatePinner[check].implementation function () { return; }; // 2. Conscrypt TrustManager (Android 7) var TrustManagerImpl Java.use(com.android.org.conscrypt.TrustManagerImpl); TrustManagerImpl[checkServerTrusted].implementation function () { return; }; // 3. OpenSSLSocketImpl (Android 5-6) var OpenSSLSocketImpl Java.use(com.android.org.conscrypt.OpenSSLSocketImpl); OpenSSLSocketImpl[verifyCertificateChain].implementation function () { return; }; // 4. 自定义TrustManager反射遍历 Java.perform(function () { var X509TrustManager Java.use(javax.net.ssl.X509TrustManager); var TrustManager Java.use(java.security.cert.TrustManager); Java.choose(javax.net.ssl.SSLContext, { onMatch: function (instance) { try { var context instance; var tmf context.getTrustManagers()[0]; if (tmf tmf.getClass tmf.getClass().getName() ! com.android.org.conscrypt.TrustManagerImpl) { console.log([CUSTOM TM] tmf.getClass().getName()); // Hook其checkServerTrusted方法... } } catch (e) {} }, onComplete: function () {} }); });踩坑实录某电商App使用OkHttpClient但证书校验逻辑在CustomTrustManager中我Hook了前3项仍失败最后用Java.enumerateLoadedClassesSync()遍历所有类发现com.xxx.network.CustomTrustManager再针对性Hook其checkServerTrusted问题解决。这提醒我们动态分析没有银弹必须结合frida-trace、jadx-gui静态分析、adb logcat日志交叉验证。5. 进阶技巧与生产级实践建议当你已能稳定完成ADB连接和基础Frida注入下一步是让分析工作流更高效、更可靠、更接近真实产研环境。以下是我在多个金融、游戏项目中沉淀的实战技巧不讲理论只说“怎么做”。5.1 自动化环境初始化一条命令启动完整分析环境手动执行adb root、setenforce 0、frida-server太繁琐。我编写了mu_init.batWindows一键脚本echo off echo [1] Restarting ADB... adb kill-server adb start-server echo [2] Waiting for MuMu device... :wait adb devices | findstr 7555 nul if %errorlevel% neq 0 ( timeout /t 2 nul goto wait ) echo [3] Rooting and remounting... adb root adb remount echo [4] Disabling SELinux... adb shell setenforce 0 echo [5] Starting Frida server... adb shell killall frida-server adb shell /data/local/tmp/frida-server -l 0.0.0.0:27042 --enable-jit -D echo [6] Verifying Frida... adb shell netstat -tuln | grep 27042 echo. echo MuMu Frida Environment Ready! pause将此脚本与frida-server、adb.exe放在同一目录双击即可完成全部初始化。关键是timeout /t 2循环等待设备上线避免脚本在MuMu未启动完成时执行失败。5.2 Frida脚本热重载修改JS无需重启App每次改一行JS都要frida -U -f重启App效率极低。使用frida-repl实现热重载先frida -U com.xxx进入交互式shell执行%load ssl_bypass.js加载脚本修改本地ssl_bypass.js后在repl中执行%reload脚本立即生效若需重新attach用%detach后%attach com.xxx。小技巧在JS中加入Java.performNow()替代Java.perform()可强制立即执行Hook避免等待类加载。5.3 多实例并行分析一台电脑跑3个MuMu做对比实验MuMu支持创建多个独立模拟器实例如MuMu1、MuMu2每个实例分配不同端口7555、7556、7557。这对对比分析极有价值例如MuMu1运行未加固APKMuMu2运行加固版MuMu3运行加壳版三者同时注入相同Frida脚本观察Hook成功率差异快速定位加固方案的对抗点。配置要点每个实例的ADB端口在MuMu设置→“常规设置”→“ADB调试端口”中单独设置Python脚本中frida.get_device_manager().add_remote_device(127.0.0.1:27042)对应端口需与实例一致为防端口冲突Frida server监听端口也需区分27042、27043、27044。5.4 安全边界提醒MuMu不是真机这些场景必须回归真机验证MuMu再强大也是x86_64虚拟机与ARM真机存在根本差异Native层Hook失效App若使用libxxx.soARM指令集MuMu无法加载Frida对so的Interceptor.attach会报not found硬件相关API异常TelephonyManager.getDeviceId()返回000000000000000SensorManager无真实传感器数据Root检测绕过不完全部分App检测/proc/1/cmdline含initMuMu为/init真机为/init但上下文不同或检查/system/build.prop中ro.product.cpu.abiMuMu为x86_64真机为arm64-v8a。因此MuMu定位是快速验证、逻辑分析、脚本开发的沙箱最终PoC必须在ARM真机如Pixel、OnePlus上复现。我的工作流是MuMu上完成90%的JS脚本开发和调试 → 导出脚本 → 在真机上用frida -U -f com.xxx -l script.js验证 → 针对真机差异微调。最后分享一个小技巧在MuMu中安装MT管理器它能直接浏览/data/data/com.xxx目录配合adb backup命令导出App数据比单纯Frida Hook更能看清数据存储逻辑。这让我在分析某社交App的本地数据库加密时直接定位到/data/data/com.xxx/databases/encrypted.db再用Frida Hook其SQLiteDatabase.openDatabase方法拿到解密密钥——这才是动静结合的分析之道。
