Android Native禁止使用系统私有库详解

系统私有库指的是，存放在android系统目录 /system/lib/ 和 /vendor/lib 下面，但是Android NDK中没有公开API的lib库。

从Android N开始（SDK >= 24），通过dlopen打开系统私有库，或者lib库中依赖系统私有库，都会产生异常，甚至可能导致APP崩溃。

这个变更会有怎样的影响呢？

曾经的美好

在以前，在NDK层面，我们是可以使用一些hack的手段得到系统的私有API的。

比如，想使用虚拟机中的一些内部符号，在Android M及以下版本，可以这么搞：

void *handle = dlopen("libart.so", RTLD_NOW);
    
void *originFunc = dlsym(handle, "_ZNK3art6Thread13DumpJavaStackERNSt3__113basic_ostreamIcNS1_11char_traitsIcEEEE");

这样你就能得到art虚拟机的内部函数art::Thread::DumpJavaStack的地址，然后愉快地调用它了。

晴天霹雳

但是到了Android N以后，

void *handle = dlopen("libart.so", RTLD_NOW);
//  没问题，返回了handle指针。

void *originFunc = dlsym(handle, "_ZNK3art6Thread13DumpJavaStackERNSt3__113basic_ostreamIcNS1_11char_traitsIcEEEE");
// 失败！得到的originFunc为空！

这就很奇怪了。我们既然能够得到handle指针，就说明libart.so是找到了，并且这个函数也是确实在libart.so之中。但是为什么libart.so中却没有找到art::Thread::DumpJavaStack的符号呢？

看一下内存映射表，我们发现了一个有趣的东西：

7de5d4d000-7de5d4e000 r-xp  /system/fake-libs64/libart.so
7de5d4e000-7de5d4f000 r--p  /system/fake-libs64/libart.so
7de5d4f000-7de5d50000 rw-p  /system/fake-libs64/libart.so
... ...
7de6a04000-7de6feb000 r-xp  /system/lib64/libart.so
7de6feb000-7de6ffa000 r--p  /system/lib64/libart.so
7de6ffa000-7de6ffd000 rw-p  /system/lib64/libart.so

这样看起来，是当dlopen参数为libart.so的话，系统会先找到/system/fake-libs64/libart.so，而不是/system/lib64/libart.so。

而/system/fake-libs64/libart.so又是什么鬼？从名字上看，就知道他是个假的libart。在系统源码文件art/libart_fake/README.md中，我们找到了对他的解释，

A fake libart made to satisfy some misbehaving apps that will attempt to link
against libart.so.

这就是为了以防你们这些图谋不轨（misbehaving）的APP们做一些奇怪的事而专门设的套啊！

只要你自己的lib库依赖了libart.so或者试图打开libart.so，在linker查找libart.so时，因为fake-libs路径被设置在了查找路径表的靠前处，就会先找到/system/fake-libs64/libart.so，而不是真正的/system/lib64/libart.so。

设置fake-libs代码:

@ frameworks/base/core/java/android/app/LoadedApk.java

public static void makePaths(...) {
...
    // Add fake libs into the library search path if we target prior to N.
    if (aInfo.targetSdkVersion <= 23) {
        outLibPaths.add("/system/fake-libs" +
            (VMRuntime.is64BitAbi(aInfo.primaryCpuAbi) ? "64" : ""));
    }
...
}

因为在N之前没有这个限制，因此在targetSdkVersion <= 23下就搞一个假的来应付那些hack的代码，这个/system/fake-libs64/libart.so的内容基本上的空的（art/libart_fake/fake.cc），所以在它里面当然什么符号都找不到啦~

霸王硬上弓

既然如此，那我们在dlopen中直接指定lib的绝对路径总行了吧？像这样：

void *handle = dlopen("/system/lib64/libart.so", RTLD_NOW);

可是很遗憾，它报了一个错：

E/linker: library "/system/lib64/libart.so" ("/system/lib64/libart.so")
    needed or dlopened by "/data/app/com.test.demo-1/lib/arm64/libbcpatch.so"
    is not accessible for the namespace:
[ name="classloader-namespace", ld_library_paths="",
  default_library_paths="/data/app/com.test.demo-1/lib/arm64:/system/fake-libs64:/data/app/com.test.demo-1/base.apk!/lib/arm64-v8a",
  permitted_paths="/data:/mnt/expand:/data/data/com.test.demo"]

也就是说，被允许访问的路径（包含ld_library_paths、default_library_paths、permitted_paths）只有：

/data/app/com.test.demo-1/lib/arm64
/system/fake-libs64
/data/app/com.test.demo-1/base.apk!/lib/arm64-v8a
/data
/mnt/expand
/data/data/com.test.demo

所以，试图访问/system/lib64/下的libart.so当然是不行的。

真是魔高一尺道高一丈啊。

至此，我们算是知道了Google封杀在ndk中访问系统私有库的方法。本质是在linker中加入一系列校验机制来做限制。linker作为最基础的lib库链接器，所有链接行为，包括动态运行时打开和静态编译期依赖，都会被限制住。

缓兵之计

不过，在Android N，你可以指定APP的targetSdkVersion为API级别23或更低。那么，对于以下灰名单中的lib，仍然可以正常使用：

// TODO(dimitry): The grey-list is a workaround for http://b/26394120 ---
// gradually remove libraries from this list until it is gone.
static bool is_greylisted(const char* name, const soinfo* needed_by) {
  static const char* const kLibraryGreyList[] = {
    "libandroid_runtime.so",
    "libbinder.so",
    "libcrypto.so",
    "libcutils.so",
    "libexpat.so",
    "libgui.so",
    "libmedia.so",
    "libnativehelper.so",
    "libskia.so",
    "libssl.so",
    "libstagefright.so",
    "libsqlite.so",
    "libui.so",
    "libutils.so",
    "libvorbisidec.so",
    nullptr
  };

这样的话，每次使用dlopen或者链接上述lib都会打印出一个警告，然后仍然正常执行原有功能。

同时Google也声明了，在将来的版本会将这些lib的支持也一并移除。因此，这只是提供了一个让你尽快在代码中去除相关依赖的过渡期。

可见，不久的将来就无法愉快地使用系统的非公开符号了。

突出重围

那我们真的就没办法了吗？

也不是绝对的，Android限制的只是dlopen这个途径，而我们访问内存是随心所欲的:）

方法就是，通过内存映射表找到libart.so的真实起始位置：

7de6a04000-7de6feb000 r-xp 00000000 fe:00 1414                           /system/lib64/libart.so
7de6feb000-7de6ffa000 r--p 005e6000 fe:00 1414                           /system/lib64/libart.so
7de6ffa000-7de6ffd000 rw-p 005f5000 fe:00 1414                           /system/lib64/libart.so

然后在加载地址起始位置手动解析libart.so的elf格式，提取出所需符号的位置信息。相当于你自己实现linker原本的查找解析逻辑。

当然，这种遍历内存解析elf的实现是比较复杂的。因此，这一次Google算是封死了一大波底层hack的手段，影响最大的自然是众多热修复和加固厂商的黑科技。关于这一限制的具体说明，可以点击本文最下方阅读原文来查看官方文档。

不过，网上仍然有很多绕过这个限制的方式，大家有兴趣的可以自己发掘一下。

---

 长按关注「安卓尖端技术研究」

带给你不同安卓技术开发视角

---

 往期推荐      

---