Android逆向疑难：加载的SO文件未出现在/proc/PID/maps中

问题背景 #

APK运行时，应用通过Java loadLibrary API加载SO文件，加载流程确认成功且SO代码已执行，但分析进程的/proc/PID/maps文件时，未找到该SO的条目，且SO并未被卸载。已完成以下验证：

• Hook loadLibrary API确认加载完成
• 依赖该SO的功能可正常运行
• Frida无法Hook该SO的JNI函数，提示找不到SO文件

可能的原因解析 #

• SO加载后手动解除内存映射
  部分加固或恶意SO会在初始化代码执行完成后，调用munmap系统调用移除自身的内存映射。但由于JNI函数已经注册到Java虚拟机的函数表中，VM调用这些函数时直接使用注册时保存的函数指针，无需再访问SO的映射区域。这种情况下，/proc/PID/maps中不会显示该SO的条目，Frida也无法通过SO名称定位模块——因为模块的内存映射已被销毁。

• 以匿名映射方式加载SO
  常规loadLibrary会从文件系统加载SO并建立关联内存映射，但特殊实现会先将SO内容读取到内存，再通过mmap创建匿名映射（不关联文件描述符）加载代码。这类映射在/proc/PID/maps中只会显示anon标记，不会关联原始SO文件路径，Frida依赖模块的文件路径/名称识别，因此无法找到目标SO。

• Hook /proc/maps的读取流程
  部分加固框架或恶意应用会Hook/proc/PID/maps的读取逻辑，当外部工具（如cat、Frida）读取该文件时，篡改返回结果过滤掉目标SO的条目。可以尝试通过gdb附加进程直接查看内存映射，或通过底层系统调用读取内存映射信息来绕过Hook验证。

• SO代码注入到其他模块内存空间
  某些加固方案会将目标SO的代码合并到已加载的其他模块（如libart.so等系统库）的内存区域中，或多个SO共享同一内存映射。此时目标SO没有独立的映射条目，不会出现在maps文件中，但代码仍可正常执行。Frida只能识别独立模块，因此无法找到单独的SO名称。

内容的提问来源于stack exchange，提问作者ReverseQ