Android Native禁止使用系统私有库详解-阿里云开发者社区

开发者社区> 万壑> 正文

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

简介: 解读Android Native对于系统私有库的限制,老版本的黑科技代码在N版本之后都可能导致APP崩溃。
+关注继续查看

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

从Android N开始(SDK >= 24),通过dlopen打开系统私有库,或者lib库中依赖系统私有库,都会产生异常,甚至可能导致app崩溃。具体可以阅读官方文档说明。

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

曾经的美好

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

比如,你想使用虚拟机中的一些内部符号,在N以下版本,你可以这么搞

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

这样你就能得到art::Thread::DumpJavaStack的函数指针,然后愉快地调用它了。

晴天霹雳

但是到了N以后,

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

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

这就很奇怪了,我们能够得到handle指针,就说明libart.so是找到了。但是为什么libart.so中却没有找到art::Thread::DumpJavaStack的符号呢?

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

7de5d4d000-7de5d4e000 r-xp 00000000 fe:00 774                            /system/fake-libs64/libart.so
7de5d4e000-7de5d4f000 r--p 00000000 fe:00 774                            /system/fake-libs64/libart.so
7de5d4f000-7de5d50000 rw-p 00001000 fe:00 774                            /system/fake-libs64/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

难怪,我们知道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" : ""));
    }
...
}

而这个/system/fake-libs64/libart.so的内容基本上的空的(art/libart_fake/fake.cc),所以在它里面当然什么符号都找不到啦~

霸王硬上弓

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

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

可是很遗憾,它报了一个错:

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

也就是说,你被允许访问的路径(包含ld_library_paths、default_library_paths、permitted_paths)只有

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

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

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

至此,我们算是知道了Google封杀在ndk中访问系统私有库的方法。本质是在linker中加入一系列校验机制来做限制。linker作为最基础的lib库链接器,所有链接行为都会被限制住。

缓兵之计

不过,在Android N,你可以指定APP的sdk为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的手段。

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


也可以来这里与我们共同讨论技术

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

相关文章
【转】Android下使用Properties文件保存程序设置
原文:http://jerrysun.blog.51cto.com/745955/804789 废话不说,直接上代码。    读取.properties文件中的配置:  String strValue = "";  Properties props = new Properties();  try {      props.
600 0
分布式系统架构中高可用方案技术选型:Hystrix 框架实现服务保护使用详解
本篇文章介绍了分布式系统架构下的经典的高可用框架Hsytrix实现的断路器,服务降级,服务熔断,服务隔离以及解决服务雪崩效应的问题。详细分析了基于Hystrix框架解决分布式系统中服务雪崩效应的几种机制,以及在项目中如何集成Hystrix框架并且在项目中使用Hystrix框架实现分布式系统中的服务治理。
281 0
Android Native禁止使用系统私有库详解
解读Android Native对于系统私有库的限制,老版本的黑科技代码在N版本之后都可能导致APP崩溃。
1780 0
Python数据分析之anaconda安装和使用
今天开始学习Python数据分析了,说到Python数据分析,大家都会推荐使用anaconda,但作为一个初学者,总是很多疑虑,但在实践中解决了一部分,先和大家分享分享。
991 0
iOS系统开发提升体验优化方案
随着Flutter等跨端框架的出现,业务开发同学经常需要在Android/IOS上跨端进行业务开发,问题定位等。新的不熟悉的环境的搭建总会遇到各种各样的问题,导致搭建失败,特别是IOS开发环境,是最复杂的,不仅环境搭建繁琐,而且切分支后的打包速度很慢,所以我们设计实现了两个工具,用于优化闲鱼IOS开发体验。
309 0
Android 禁止Viewpager左右滑动功能
首先自定义一个 继承自 ViewPager的自定义 类 package com.yourcompany; import android.content.Context; import android.
842 0
+关注
9
文章
2
问答
文章排行榜
最热
最新
相关电子书
更多
《2021云上架构与运维峰会演讲合集》
立即下载
《零基础CSS入门教程》
立即下载
《零基础HTML入门教程》
立即下载