无x86原生库的Android应用可调用原生方法逆向问题咨询
问题1解答
Android 11及以上版本的x86架构模拟器内置了Intel Houdini二进制转译层，可以在运行时将ARM指令动态转译为x86指令执行，因此仅含ARM架构so的应用也可以正常运行。
Houdini加载ARM so的逻辑不经过Android系统原生linker，不会将so注册到系统的已加载共享库列表中，因此你通过常规的进程模块枚举手段看不到对应库文件。你看到的.odex文件是ART虚拟机对Java代码的提前优化产物，和原生库转译逻辑无关。
问题2解答
frida的Process.loadModule()本质是调用系统linker的dlopen()接口加载共享库，你的运行环境是x86架构，应用内没有对应x86版本的so，系统linker无法识别ARM架构的so文件，自然会返回dlopen错误。
如果需要枚举Houdini加载的ARM so，需要手动解析Houdini进程空间内的私有加载记录，无法使用frida默认的模块枚举接口。
问题3解答
不能直接重新编译。
Ghidra反编译输出的是伪C代码，仅能还原代码逻辑的大致结构，会丢失大量原始编译信息：包括硬编码地址的符号映射、寄存器操作对应的变量定义、编译选项、链接依赖等，甚至存在大量反编译错误，无法直接通过编译器生成可用的x86 so。如果要得到x86版本的库，需要你基于反编译结果手动重写全部逻辑，再针对x86架构编译。
问题4解答
正常情况下会抛出UnsatisfiedLinkError错误。
如果你调用原生方法没有报错，只有两种可能：
- 原生方法已经通过
JNI_OnLoad或者动态注册接口完成了注册，只是对应的so被Houdini加载，你没有枚举到 - 该原生方法的实现被其他hook框架（比如应用自带的热修复框架、Xposed等）替换，不需要依赖原生so的导出符号即可执行。
补充问题解答
frida-trace默认基于系统linker导出的共享库符号表匹配函数地址，Houdini转译后的ARM原生函数没有注册到系统符号表中，转译生成的x86指令地址是Houdini动态分配的，和原ARM so的导出符号没有绑定关系，因此你无法通过常规的库名+函数名的方式hook。
如果需要拦截对应原生方法，可以直接在ART的JNI调用入口处hook，匹配对应方法的签名即可拦截调用，不需要找到原生so的加载地址。
内容的提问来源于stack exchange，提问作者ahmed mani
