Android9.0中在activity的onCreate之前hook dlopen函数，如果需要返回值(即修改了LR寄存器)，那么会触发：E/libEGL: EGL_ANDROID_blob_cache advertised, but unable to get eglSetBlobCacheFuncsANDROID。不会crash，但是界面不会绘制出来。

是因为dlopen(libEGL_adreno.so, 2)、dlopen(libGLESv2_adreno.so, 2)返回都是null。理论上其他任何hook框架也都存在这个问题，测试了几个也确实都存在。

dlopen函数实现在libdl.so，

这里把LR寄存器当作第三个参数传递给.__loader_dlopen，而我们hook时为了能拿到返回值是修改了LR寄存器的，这是不可避免的。如果不修改LR寄存器，除非我们知道函数结尾，在函数结尾修改LR寄存器或者跳到shellcode/hook函数，但是通常是不现实的，函数开头容易确认，函数结尾很难自动化确认。

__builtin_return_address函数应该是gcc内部函数，0获取的是被调用函数返回后执行的指令地址，至于1之后的数字是否能获取到函数调用栈待测试。已测试：
1、0获取的就是进入函LR寄存器的值。
2、1获取的是r7(thumb)/r12(arm)，即ip寄存器的值，所以能不能获取到正确的值取决于上层是否使用了ip寄存器暂存sp，且ip寄存器之后(栈上)就是在栈上存储的LR寄存器的值。所以不满足这些条件的函数是获取不到的甚至是错误的。

.__loader_dlopen就是一个跳板

导入loader_dlopen函数，实现在linker/64，所以从libdl.so的got表中可以获取loader_dlopen函数的绝对地址。

dlopen_ext函数被loader_dlopen函数内联了，所以loader_dlopen函数足够被inline hook了。

首先为了验证是不是因为LR寄存器导致的问题，使用dump函数"(dump((void*)dlopen, onPreCallBack, NULL, "dlopen");)"，只在函数之前打印下参数寄存器，之后调用原函数，发现可以正常运行了。

使用导入表/导出表hook dlopen也出现该问题。

hook __loader_dlopen代替dlopen，发现dump、replace都可以正常运行，至此可以确定确实是修改了LR寄存器的问题。

而loader_dlopen函数导出在linker，通过dlsym(RTLD_DEFAULT, "loader_dlopen")是获取不到的，linker不是动态库，这里采用

通过第三个参数确定libEGL_adreno.so是被libGLESv2_adreno.so内的函数dlopen；libGLESv2_adreno.so应该是被libadreno_utils.so内的函数dlopen；依此类推libgrallocutils.so、libadreno_utils.so、libboost.so、libgui.so。可能有误，因为这个其实不关键，我也不关心gui流程，有谁关心这个的可以分析整个流程。

因为传入的p(LR寄存器的值)导致返回null,即使不为null，后面对应的android_namespace_t肯定也不一致。

最终结果就是已加载的so是其他命名空间、classloader加载的，所以查找不到最终返回null。看到这发现和7.0之后的限制私有api是一回事。那么即然是根据第三个参数判断的，那么hook __loader_dlopen函数传入一个符合的地址是不是就可以绕过了。

进行测试：

看到日志linker: library "/system/lib/libnativehelper.so" ("/system/lib/libnativehelper.so") needed or dlopened by可以确定就是android7.0开始采用的命名空间限制私有api调用。

对其进行过滤，把LR寄存器的值改为符合地址范围的，这里我使用dlerror的地址，只要符合即可。通过日志可以看到成功了。

所以这就是我早期针对Android7.0限制私有api的一种绕过方式，比起自己加载系统so，自己解析再通过偏移值确定地址好些。。。，通过这还可以延伸出我动态注入时做的一件事情全局绕过私有api限制。以前frida是没有这么做过的，没看最近的代码，不确定是否现在也采用这样的方法了没有。

所以对于hook dlopen可以这么划分：
1、低于7.0的版本只hook dlopen即可。
2、8.0以上最好hook __loader_dlopen或者do_dlopen。或者hook dlopen过滤发现是系统so(限制的私有so)不取返回值(即不修改LR寄存器)，或者自行解析、重组dlopen的指令传入原来的LR寄存器(不推荐)。
3、7.0-7.1的hook do_dlopen，因为没有采用libdl.so做中转。
4、全局关闭命名空间限制使用私有api，不是特别推荐吧，但其实我是这么做的。
5、更投机取巧的方法，即然只要LR寄存器合乎规则即可，那么可以针对dlopen、dlsym从BL指令转成先设置LR寄存器为一个libc等so里面的一个不常用的函数c(常用的也不是不行，但是对效率可能有影响)，之后使用B指令跳转到备份/修复的dlopen原函数执行。c函数进行hook，使用一样的跳板，只是shellcode有些不一样。因为dlopen等函数执行完会跳回c函数，那么LR寄存器就是c函数的地址，只要c函数不是一个递归函数，那么就可以通过判断LR寄存器区别出是dlopen等函数的返回还是其他函数正常调用的c函数。当是dlopen函数返回时再跳回dlopen的shellcode处完成返回。

未解决的疑问：
我记得梆梆也hook了dlopen、dlsym，arm使用的是Cydia Substrate框架，在高版本上应该也存在这个问题的，但是以前没仔细看，我记得应该没特殊处理的，奇怪。抽时间再逆下，除非他改了生成的shellcode，非自己要hook的so就过滤掉，不修改LR寄存器。

已解决：后来抽时间看下，原来也是解析了loader_dlopen、dl__Z9do_dlopenPKciPK17android_dlextinfoPKv等，

所以也是参照上面的3来做的。不过看其定位了一些安卓源码中没有的符号，所以也存在兼容性问题？看来也是存在风险的。毕竟不是标准c/c++ api，确实有可能被魔改。

dlsym等其他几个函数也是类似的处理，甚至如果只是为了调用系统的私有api，只hook loader_dlsym即可，使用dlsym(RTLD_DEFAULT, "xx")即可，把loader_dlsym的第三个参数改为合法的地址。

[注意]传递专业知识、拓宽行业人脉——看雪讲师团队等你加入！