CN115827364A

CN115827364A - 安卓平台中Native内存监控方法

Info

Publication number: CN115827364A
Application number: CN202111102069.1A
Authority: CN
Inventors: 王一达
Original assignee: Shuhang Technology Beijing Co ltd
Current assignee: Shuhang Technology Beijing Co ltd
Priority date: 2021-09-18
Filing date: 2021-09-18
Publication date: 2023-03-21

Abstract

本发明提供一种安卓平台中Native内存监控方法，其特征在于，包括：获取ELF基地址的步骤；获取所述ELF的重定位信息的步骤；用钩子函数接管所述ELF调用内存分配函数的步骤。本发明还提供第二种安卓平台中Native内存监控方法，包括：创建函数数组的步骤，其中所述函数数组中的每个元素均为钩子函数；获取多个ELF基地址的步骤；获取每个所述ELF的重定位信息的步骤；用所述函数数组中的元素分别接管所述每个ELF调用内存分配函数的步骤。

Description

安卓平台中Native内存监控方法

技术领域

本发明提供一种内存监控方法，尤其涉及一种安卓平台中Native内存监控方法。

背景技术

安卓平台APP内存由java堆内存和native内存两部分组成，java对象的分配和回收发生在java堆内存中，该部分内存的回收由JVM垃圾收集器管理，内存泄露的问题尚不突出。而native内存分配由程序员调用C/C++中的malloc等函数分配，该部分内存不在堆内，因此不会被Java垃圾收集器释放，因此该部分内存泄露的问题较为突出。

要解决Native内存泄露问题，就需要先对Native内存的分配进行监控，才能追踪内存使用情况，定位内存泄露的原因。目前针对native内存监控一直缺乏高效、便捷的工具，仅有的malloc debug在性能和稳定性上难以满足需要，而且还存在版本兼容性差的问题。

发明内容

鉴于以上所述现有技术的缺点，本发明的目的在于提供一种安卓平台中Native内存监控方法，其特征在于，包括：获取ELF基地址的步骤；获取所述ELF的重定位信息的步骤；用钩子函数接管所述ELF调用内存分配函数的步骤。

优选地，上述安卓平台中Native内存监控方法中，所述获取ELF基地址通过调用dl_iterate_phdr获得。

优选地，上述安卓平台中Native内存监控方法中，通过解析/proc/self/maps文件，将其中offset为0的记录对应的地址作为所述ELF的基地址。

优选地，上述安卓平台中Native内存监控方法中，所述重定位信息包括.got，.plt，.rel.plt，.rel.dyn中的信息。

优选地，上述安卓平台中Native内存监控方法中，所述用钩子函数接管调用的步骤包括：将所述重定位信息所在内存属性修改成可写；将所述重定位信息所在内存赋值为所述钩子函数的地址。

优选地，上述安卓平台中Native内存监控方法中，所述用钩子函数接管调用的步骤还包括：复位所述重定位信息所在内存属性的步骤。

本发明还提供第二种安卓平台中Native内存监控方法，包括：创建函数数组的步骤，其中所述函数数组中的每个元素均为钩子函数；获取多个ELF基地址的步骤；获取每个所述ELF的重定位信息的步骤；用所述函数数组中的元素分别接管所述每个ELF调用内存分配函数的步骤。

优选地，上述安卓平台中Native内存监控方法中，所述函数数组中的每个钩子函数，每隔预设的时间T就将所述ELF内存调用的情况输出到CSV文件。

附图说明

图1是本发明的Native内存监控方法流程图；

图2是/proc/self/maps文件内容示意图。

具体实施方式

以下通过特定的具体实例说明本发明的实施方式，本领域技术人员可由本说明书所揭露的内容轻易地了解本发明的其他优点与功效。本发明还可以通过另外不同的具体实施方式加以实施或应用，本说明书中的各项细节也可以基于不同观点与应用，在没有背离本发明的精神下进行各种修饰或改变。

本发明的核心思想，是利用钩子程序(hook)接管应用程序对native内存分配函数的调用，从而在调用内存分配函数时，就对内存进行记录和监控，统计出各个动态库分配了多少内存、哪些内存一直被占用没有释放。传统的hook需要root权限才能拦截其它应用对malloc，calloc，realloc和free这些函数的调用，而仅仅为了监控内容泄露就让普通的应用获得root权限，不但是不经济的，很多时候也是做不到的。

考虑到安卓平台中，C/C++源代码进行编译和链接之后，生成的动态链接库或可执行文件都是ELF(Executable and Linkable Format)格式的，ELF是一种行业标准的二进制数据封装格式。ELF通过操作系统提供的动态链接器(linker)加载到内存。加载时是以segment为单位的。一个segment包含了一个或多个section，其中“.dynamic section”是一个十分重要和特殊的section，其中包含了ELF中其他各个section的内存位置等信息，动态链接器加载动态链接库或者可执行文件时，都需要先找到.dynamic section的内存位置，再进一步读取其他各项section的信息。

加载的大致步骤是：

(1).读ELF的PHT(program header table)，用mmap把所有类型为PT_LOAD的segment依次映射到内存中；

(2).从.dynamic segment中读取各信息项，主要是各个section的虚拟内存相对地址，然后计算并保存各个section的虚拟内存绝对地址；

(3).执行重定位操作(relocate)，重定位信息可能存在于下面的一个或多个secion中：.rel.plt,.rela.plt,.rel.dyn,.rela.dyn,.rel.android,.rela.android；动态链接器需要逐个处理这些.relxxx section中的重定位诉求。

基于ELF文件的特点和运行机制，本发明提出一种方法，在没有root权限的情况下，我利用钩子函数接管应用程序对malloc/realloc/calloc/free的调用，实现对应用程序使用native内存行为的监控。具体流程见图1，包括：

S1：获取ELF基地址的步骤。在进程的内存空间中，各种ELF被加载到哪个内存地址是随机的，只有在运行时才能拿到真正的加载地址，也就是基地址。前述的加载、重定位完成之后，ELF的基地址已经确定了，当其中的某个目标函数(本例中是malloc/realloc/calloc/free这些函数)被调用时，并不是该目标函数的原始函数地址被调用，而是先经过程序链接表(Procedure Link Table，PLT)，跳转至全局偏移表(Global Offset Table，GOT)获取目标函数函数的全局偏移，这时候就可以通过基址+偏移的方式定位真实的目标函数地址。获取基地址的一种方式是调用系统提供的dl_iterate_phdr函数，它能够查询到已加载的动态库信息，包括了基地址。

但一些安卓版本并不支持dl_iterate_phdr，可以通过解析/proc/self/maps文件获得基地址：maps返回的是指定进程的内存空间中mmap的映射信息，包括各种动态库、可执行文件(如：linker)，栈空间，堆空间。Maps文件内容如图2所示，通常每个进程在maps文件中的记录有3条，其中offset为0的记录，对应的地址就可以作为进程的基地址。图2的示例中，进程libc的基地址就是b6e42000-b6eb5000。

S2：获取重定位信息的步骤。根据基地址就能找到ELF中的重定位信息。如前所述，动态链接器执行重定位操作时，会处理.relxxx section中的重定位诉求。如果将这些.relxxx section中的内容替换成指定的函数，那么在ELF被调用时，实际被调用的就将是指定的函数，如果指定的是钩子函数(hook)，那么就实现了钩子函数接管ELF的调用。

本例中，需要获取的重定位信息包括以下几个section中的信息：.got，.plt，.rel.plt，.rel.dyn。钩子函数可以自行设计，一种实例是每隔时间T就将内存快照输出成日志文件，这样开发人员就能从日志文件中监控到目标ELF的native内存使用情况，判断是否存在泄露。

S3：用钩子函数接管调用的步骤。用钩子函数接管ELF调用的直观方式是直接将重定位信息的内容修改成钩子函数。但该重定位信息对应的内存区段，可能是写保护的，直接对这个内存区段赋值，会导致错误。一种解决方式是先利用系统提供的mprotect()，将该段内存属性修改成可写，然后再对该段内存进行赋值(也就是执行hook操作)。

考虑到.got和.data的section类型是PROGBITS，也就是执行代码，处理器可能会对这部分数据做缓存，为了消除缓存的影响，完成前述的内存修改后，执行一个处理器指令缓存清除操作，让处理器重新从内存中读入指令。

更优选地，在完成内存修改后，将内存的属性复位，即将该内存的属性改回到步骤S3之前的读写属性，避免给系统或者其它的应用程序带来影响。

以上是对一个应用中的一个native内存分配行为监控的方法。但实践中，native内存区是由多个应用程序共享的，每个应用都可能调用native内存分配函数，或者应用是多进程并发的，仅利用上述的方式就不能有效避免内存泄露。

一种改良的方式是创建一个钩子函数的数组hookstub，每个数组元素存储钩子函数的地址。而数组的首地址较为容易获得，且数组中每个元素的地址连续，因此只要获得数组首地址，就能容易地计算出数组中每个钩子函数的地址。这样，数组中的每个元素都能用于接管一个内存分配函数，整个数组就能接管多个应用或者一个应用中的多个内存分配行为，实现更全面的监控。

更优选地，数组hookstub中的每个元素(即每个钩子函数)，设置成将所接管的进程ID连同该进程的内存占用情况一起输出到csv文件，这样利用csv文件中的结构化数据，更方便日志信息的自动化处理、快速定位问题。

如无特别说明，上述的本发明缓存清理装置提到的“装置”、“模块”属于逻辑功能部件，实践中既可以通过硬件实现，也可以通过软件实现；附图中各模块的从属关系、连接线仅代理各模块之间逻辑上的联系，并不构成对研发的限制，尤其不构成对软件开发中类的继承、模块划分等等开发方式的限制。使用本发明的native内存监控方法，实现简单，且能根据需求灵活定制监控输出的日志内容和格式，从而有效发现内存泄露的原因，因此具有较高使用价值。

Claims

1.一种安卓平台中Native内存监控方法，其特征在于，包括：

获取ELF基地址的步骤；

获取所述ELF的重定位信息的步骤；

用钩子函数接管所述ELF调用内存分配函数的步骤。

2.根据权利要求1所述的安卓平台中Native内存监控方法，其特征在于，所述获取ELF基地址通过调用dl_iterate_phdr获得。

3.根据权利要求1所述的安卓平台中Native内存监控方法，其特征在于，通过解析/proc/self/maps文件，将其中offset为0的记录对应的地址作为所述ELF的基地址。

4.根据权利要求1所述的安卓平台中Native内存监控方法，其特征在于，所述重定位信息包括.got，.plt，.rel.plt，.rel.dyn中的信息。

5.根据权利要求1所述的安卓平台中Native内存监控方法，其特征在于，所述用钩子函数接管调用的步骤包括：

将所述重定位信息所在内存属性修改成可写；

将所述重定位信息所在内存赋值为所述钩子函数的地址。

6.根据权利要求5所述的安卓平台中Native内存监控方法，其特征在于，所述用钩子函数接管调用的步骤还包括：复位所述重定位信息所在内存属性的步骤。

7.一种安卓平台中Native内存监控方法，其特征在于，包括：

创建函数数组的步骤，其中所述函数数组中的每个元素均为钩子函数；

获取多个ELF基地址的步骤；

获取每个所述ELF的重定位信息的步骤；

用所述函数数组中的元素分别接管所述每个ELF调用内存分配函数的步骤。

8.根据权利要求7所述的安卓平台中Native内存监控方法，其特征在于，所述函数数组中的每个钩子函数，每隔预设的时间T就将所述ELF内存调用的情况输出到CSV文件。

9.根据权利要求7所述的安卓平台中Native内存监控方法，其特征在于，通过解析/proc/self/maps文件，将其中offset为0的记录对应的地址作为所述ELF的基地址。