一种移动应用程序动态加载行为监控方法及装置与流程

本发明属于android应用程序监控技术领域，使用的主要方法是进程注入和inlinehook，特别涉及一种移动应用程序动态加载行为监控方法及装置。

背景技术：

近年来，移动设备在人们的工作和生活中变得越来越受欢迎，根据中国互联网络信息中心(cnnic)发布的第四十次《中国互联网络发展状况统计报告》显示，截至2017年6月，中国网民规模达到7.51亿，占全球网民总数的五分之一。其中，手机网民规模达7.24亿，较2016年底增加2830万人。网民中使用手机上网的比例由2016年底的95.1％提升至96.3％。而台式电脑、笔记本电脑的使用率均出现下降，手机不断挤占其他个人上网设备的使用。

随着移动设备和移动互联网的快速发展，google推出的android操作系统已然成为世界上最受欢迎的操作系统。数据显示，截止2017年底android在全球智能手机市场上的份额占到了86％。但是，伴随着android智能设备的广泛应用，诸多的安全风险也随之而来。移动设备包含用户的许多隐私数据，比如联系人信息、短信、电子邮件以及信用卡号等，同时通过移动设备还可以获取用户的地理位置，发送付费短信以及拨打电话等。另外，在线支付的功能也给人们带来了很多的便利，因此，手机更加成为人们生活中必不可少的工具，移动设备的安全问题也就更加重要。同时，由于android操作系统的普遍性和自身源码的开放性，其已成为犯罪分子针对移动设备进行恶意攻击的主要攻击目标。针对android平台的恶意应用程序数量也在飞速增加，目前已有超过一百万种的恶意应用程序是针对android设备的。

恶意应用程序是针对移动设备进行安全攻击的主要载体，它们伪装成正常和有用的应用程序，隐藏在后台执行的恶意操作，进而威胁用户的隐私及安全。恶意应用程序要实现恶意行为，就必须要通过调用android系统提供的应用程序编程接口(applicationprogramminginterface，api)来完成。native层和java层是通过java本地接口(javanativeinterface，jni)技术来进行相互通信的。通过对native层的api进行监控，不仅可以监控到应用程序在native层的行为，而且能监控到其在java层的行为。

android系统的快速发展，使android恶意应用程序也从简单变为复杂，从单纯的dex恶意应用程序转变为elf(linux系统上的可执行程序)恶意应用程序。目前，大多数的恶意应用程序都是通过将elf格式的文件注入系统进程来达到恶意攻击的目的，而so文件正是elf文件的一种。针对native层api进行监控，能够更全面的捕获应用程序的行为。例如，对于应用程序动态加载dex文件的行为，在java层和native层都能够监控到；而对于应用程序动态加载so文件的行为，在java层是无法监控到的，而在native层可以监控到。因此，针对native层api进行监控是必要的。

综上所述，基于native层api对android应用程序进行监控，对恶意应用程序的行为分析、避免用户的数据泄露及财产损失具有重要意义。

目前，针对android恶意应用程序的分析主要有两种方法：静态分析方法和动态分析方法。静态分析方法通过分析静态代码来检测android应用程序是否包含异常信息流或调用结构，是否和恶意代码的模式相匹配，是否请求获取额外的非必须的权限，或者是否调用恶意应用程序经常使用的api。但是，这些方法并不能总是精确地检测出恶意应用程序，因为控制流和数据流的动态变化并是静态方法能够决定的；而且不一定有些权限被申请或代码中进行系统api调用就一定为恶意应用程序，这些都要结合应用程序的上下文的api调用来决定的。此外，攻击者可以使用普遍存在的技术，比如代码混淆和代码变形来逃避静态模式匹配并欺骗检测器。由于静态分析方法自身的局限性，所以越来越多的研究人员开始进行android应用程序的动态分析研究。

动态分析方法提供了检测android恶意应用程序的补充方法。动态分析主要就是通过android的日志系统来获取应用程序在运行过程中的动态行为特征及系统api调用情况等，进而判断应用程序是否具有恶意性。此外，近几年来，随着机器学习的兴起，许多研究人员也将机器学习的方法应用到了恶意应用程序的检测方面。目前，动态分析方法中专门针对native层api的监控并不多，存在对应用程序动态加载行为监控不全的问题，并且都是在较低的android系统版本上实现的，兼容性也不够好。

技术实现要素：

为了克服上述现有技术的缺点，本发明的目的在于提供一种移动应用程序动态加载行为监控方法及装置，一方面，本发明监控方法易部署，兼容性好，即不需要对android系统源码或应用程序进行修改，兼容android32位和64位应用程序；另一方面，本发明监控方法具有良好的完备性和实用性，克服了传统方法对应用程序的动态加载行为监控不全、过于陈旧、对新版android系统支持不好的缺点，支持android4.0以上的各个系统版本。

为了实现上述目的，本发明采用的技术方案是：

一种移动应用程序动态加载行为监控方法，包括：

在android设备开机后，执行初始化脚本，对系统关键函数进行拦截替换；

用户指定要监控的应用程序uid或其对应的pid进程，对相应的应用程序或pid进程的动态加载行为进行监控；

记录并输出监控日志；

对用户指定的应用程序或pid进程动态加载的文件进行备份。

所述执行初始化脚本，对系统关键函数进行拦截替换包括：

在android设备开机后，执行初始化脚本文件，通过进程追踪函数来向zygote进程和zygote64进程注入so文件，对特定系统关键函数进行拦截替换，完成应用程序动态加载行为监控的初始化工作。

其中，所述进程追踪函数包括但不限于ptrace函数。所述特定系统关键函数包括但不限于动态链接库文件加载函数、动态符号解析函数、native层dex文件加载函数。

用户指定要监控的应用程序uid或其对应的pid进程，对相应的应用程序或pid进程的动态加载行为进行监控包括：

支持用户以两种方式指定要监控的应用程序：

(1)在用户指定要监控的应用程序的uid后，启动相应的应用程序，对相应的应用程序的动态加载行为进行监控；

(2)在启动相应的应用程序后，用户指定要监控的应用程序对应的pid进程，对相应的pid进程及其子进程的动态加载行为进行监控。

所述监控的动态加载行为包括但不限于so动态共享库文件的加载、so动态共享库文件的调用、dex可执行文件的加载。

所述记录并输出监控日志包括：

在用户指定的应用程序运行时，会调用被拦截系统函数的监控函数，在监控函数中完成对用户指定应用程序或pid进程的监控，以特定格式记录监控日志。

所述监控日志包括但不限于以下内容：so文件全路径文件名、动态加载so文件的操作时间戳、从so文件中获取的函数或变量名称、动态符号解析的操作时间戳、dex文件全路径文件名、动态加载dex文件的操作时间戳。

所述对用户指定的应用程序或pid进程动态加载的文件进行备份包括：

在用户指定的应用程序运行时，会调用被拦截系统函数的监控函数，在监控函数中完成对动态加载文件的备份，将备份文件保存在特定的系统目录中。

所述动态加载文件的备份包括但不限于so文件、dex文件。

本发明还提供了一种移动应用程序动态加载行为监控装置，包括：

监控控制单元，用于在android设备开机后，执行初始化脚本，对系统关键函数进行拦截替换；

动态加载行为监控单元，用于用户指定要监控的应用程序或pid进程，对相应的应用程序或pid进程的动态加载行为进行监控；

监控日志生成及文件备份单元，用于记录并输出监控日志，同时对用户指定的应用程序或pid进程动态加载的文件进行备份。

所述监控控制单元具体用于：

在android设备开机后，执行初始化脚本文件，通过进程追踪函数来向zygote进程和zygote64进程注入so文件，对包括但不限于以下函数：动态链接库文件加载函数、动态符号解析函数、native层dex文件加载函数进行拦截替换，完成应用程序动态加载行为监控的初始化工作。

所述监控控制单元具体包括：

注入so模块：用于通过进程追踪函数来向zygote进程和zygote64进程注入so文件；

hook模块：用于对包括但不限于以下系统关键函数：动态链接库文件加载函数、动态符号解析函数、native层dex文件加载函数进行拦截替换。

所述注入so模块通过ptrace函数来附着进程，然后向宿主进程注入so文件，从而达到监控以及宿主进程关键函数挂钩的目的，具体包括以下步骤：

(11)使用ptrace函数attach上目标进程；

(12)使目标进程装载用来注入的libxxx.so文件；

(13)使目标进程的执行流程跳转到注入的代码块并执行，实现监控；

(14)使用ptrace函数的detach释放目标进程；

所述hook模块在注入so模块将so文件成功注入目标进程后，执行注入的so文件中的函数，实现监控，具体包括以下步骤：

(21)获取要监控的原系统函数的入口地址；

(22)保存原系统函数的若干条汇编指令；

(23)用跳转指令替换原系统函数头部的前若干条汇编指令，改变原系统函数执行流程，使原系统函数在执行时首先跳转到自定义的代理函数执行；

(24)对原系统函数使用到的寄存器值进行保存；

(25)执行自定义的代理函数，实现监控；

(26)恢复(24)中保存的寄存器值，并将(22)中保存的原系统函数前若干条指令写回；

(27)执行原系统函数的正常调用流程，保存函数返回值；

(28)重新用(23)中的跳转指令替换原系统函数的前若干条指令，使得该系统函数在下一次被调用时，依旧能够跳转到自定义的代理函数中去；

(29)代理函数返回(27)中保存的原系统函数返回值，目的是保证代理函数和原系统函数的执行效果相同，代理函数执行完毕。

所述动态加载行为监控单元具体用于：

在用户指定要监控的应用程序后，启动相应的应用程序，对相应的应用程序的动态加载行为进行监控；

在用户指定要监控的pid进程后，对相应的pid进程及其子进程的动态加载行为进行监控。

所述监控的动态加载行为包括但不限于so动态共享库文件的加载、so动态共享库文件的调用、dex可执行文件的加载。

所述动态加载行为监控单元具体包括：

动态加载so文件监控模块：用于对指定的应用程序或pid进程的so文件动态加载行为进行监控；

调用so文件监控模块：用于对指定的应用程序或pid进程的so文件调用行为进行监控；

动态加载dex文件监控模块：用于对指定的应用程序或pid进程的dex文件动态加载行为进行监控；

所述监控日志生成及文件备份单元具体用于：

在用户指定的应用程序或pid进程运行时，会调用被拦截系统函数的监控函数，在监控函数中完成对用户指定应用程序或pid进程的监控，以特定格式记录监控日志，同时完成对动态加载文件的备份。

所述监控日志包括但不限于以下内容：so文件全路径文件名、动态加载so文件的操作时间戳、从so文件中获取的函数或变量名称、动态符号解析的操作时间戳、dex文件全路径文件名、动态加载dex文件的操作时间戳。

所述动态加载文件的备份包括但不限于so文件、dex文件。

所述动态加载so文件监控模块用于监控应用程序动态加载的so文件的全路径文件名、操作时间戳以及操作进程的pid、uid，针对32位和64位的android应用程序分别采用不同的监控方法，具体包括以下步骤：

针对32位的android应用程序：

(31)执行dlopen函数；

(32)执行libhook_dlopen_32.so文件中的hook_dlopen；

(33)判断dlopen函数是arm格式还是thumb格式，如果是arm格式，则跳转到(34)；否则，跳转到(35)；

(34)执行arm格式对应的跳转指令，跳转到(36)；

(35)执行thumb格式对应的跳转指令，跳转到(36)；

(36)执行my_dlopen；

(38)写回dlopen函数被替换掉的原本的前三条汇编指令；

(39)执行orig_dlopen，保存返回值；

(310)重新用相应的跳转指令替换dlopen函数的前三条汇编指令，使得下一次调用dlopen函数时，仍然执行相应的跳转指令，跳转到my_dlopen；

(311)返回orig_dlopen的返回值；

针对64位的android应用程序：

(41)执行libhook_dlopen_64.so文件中的hook_dlopen函数；

(42)执行arm64位对应的汇编跳转指令；

(43)执行my_dlopen并记录由参数pathname得到的so文件全路径文件名、操作时间戳、pid、uid到日志integrity_64.log，完成监控；

(44)写回dlopen函数被替换掉的原汇编指令；

(45)执行orig_dlopen，保存返回值；

(46)重新用相应的跳转指令替换dlopen函数的汇编指令，使得下一次调用dlopen函数时，仍然执行相应的跳转指令，跳转到my_dlopen；

所述调用so文件监控模块用于监控应用程序调用so文件时从so文件中获取的函数或变量名称、操作时间戳以及操作进程的pid、uid，针对32位和64位的android应用程序分别采用不同的监控方法，具体包括以下步骤：

针对32位的android应用程序：

(51)执行dlsym函数；

(52)执行libhook_dlsym_32.so文件中的hook_dlsym；

(53)判断dlsym函数是arm格式还是thumb格式，如果是arm格式，则跳转到(54)；否则，跳转到(55)；

(54)执行arm格式对应的跳转指令，跳转到(56)；

(55)执行thumb格式对应的跳转指令，跳转到(56)；

(56)执行my_dlsym；

(57)记录由参数symbol得到的so文件中的函数或变量名称、操作时间戳、pid、uid到日志integrity_32.log；

(58)写回dlsym函数被替换掉的原本的前三条汇编指令；

(59)执行orig_dlsym，保存返回值；

(510)重新用相应的跳转指令替换dlsym函数的前三条汇编指令，使得下一次调用dlsym函数时，仍然执行相应的跳转指令，跳转到my_dlsym；

(511)返回orig_dlsym的返回值；

针对64位的android应用程序：

(61)执行libhook_dlsym_64.so文件中的hook_dlsym函数；

(62)执行arm64位对应的汇编跳转指令；

(63)执行my_dlsym并记录由参数symbol得到的so文件中的函数或变量名称、操作时间戳、pid、uid到日志integrity_64.log，完成监控；

(64)写回dlsym函数被替换掉的原汇编指令；

(65)执行orig_dlsym，保存返回值；

(66)重新用相应的跳转指令替换dlsym函数的汇编指令，使得下一次调用dlsym函数时，仍然执行相应的跳转指令，跳转到my_dlsym；

所述动态加载dex文件监控模块用于监控动态加载的dex文件的全路径文件名、操作时间戳以及操作进程的pid与uid，针对32位和64位的android应用程序分别采用不同的监控方法，具体包括以下步骤：

针对32位的android应用程序：

(71)执行open函数；

(72)执行libhook_open_32.so文件中的hook_open；

(73)判断open是arm格式还是thumb格式，如果是arm格式，则跳转到(74)；否则，跳转到(75)；

(74)执行arm格式对应的跳转指令，跳转到(76)；

(75)执行thumb格式对应的跳转指令，跳转到(76)；

(76)执行my_open；

(77)打印函数调用栈，根据函数调用栈判断是否为classloader的两个子类(dexclassloader和pathclassloader)进行的open操作，如果是，则跳转到(78)；否则，跳转到(79)；

(78)记录由参数pathname得到的dex文件全路径文件名、操作时间戳、操作进程的pid与uid到integrity_32.log；

(79)写回open函数被替换掉的原汇编指令；

(710)执行orig_open，保存返回值；

(711)重新用相应的跳转指令替换open函数的前若干条汇编指令，使得下一次调用open函数时，仍然执行相应的跳转指令，跳转到my_open；

(712)返回orig_open的返回值。

针对64位的android应用程序：

(81)执行libhook_open_64.so文件中的hook_open函数；

(82)执行arm64位对应的汇编跳转指令；

(83)执行my_open；

(84)打印函数调用栈，根据函数调用栈判断是否为classloader的两个子类(dexclassloader和pathclassloader)进行的open操作，如果是，则跳转到(88)；否则，跳转到(89)；

(85)执行my_open并记录由参数pathname得到的dex文件全路径文件名、操作时间戳、操作进程的pid与uid到日志integrity_64.log，完成监控；

(86)写回open函数被替换掉的原汇编指令；写回open函数被替换掉的原汇编指令；

(87)执行orig_open，保存返回值；

(88)重新用相应的跳转指令替换open函数的前若干条汇编指令，使得下一次调用open函数时，仍然执行相应的跳转指令，跳转到my_open。

所述监控日志生成及文件备份单元将所有监控的系统函数调用的动态行为信息以特定的格式输出到日志文件，针对32位和64位的android应用程序分别将监控信息记录到不同的日志文件中，具体包括以下步骤：

(91)开始执行代理函数；

(92)执行相应的监控代码；

(93)将监控信息输出到相应的日志文件，32位应用程序的监控信息输出到integrity_32.log中，64位应用程序的监控信息输出到integrity_64.log中；

(94)代理函数执行结束，完成监控日志的输出。

与现有技术相比，本发明的有益效果是：

1、兼容性：本发明支持android4.0以上的各个版本的android系统，支持对32位和64位的应用程序进行监控。

2、可扩展性：本发明提出的监控方法具有良好的扩展性，针对不同的系统函数，只要稍作修改，就可进行相应的监控。因此，本发明的方法基本上能够用来监控native层的任意函数。

3、完备性：本发明提出的监控方法特别是，能够对应用程序的动态加载行为进行全面的、无遗漏的监控。

4、易部署性：在不修改android系统源码和被监控的应用程序源码的情况下进行监控。

附图说明

图1为本发明方法整体结构图。

图2为本发明监控控制中的注入so模块流程图。

图3为本发明监控控制中的hook模块流程图。

图4为本发明动态加载行为监控中针对32位应用程序的动态加载so文件监控模块流程图。

图5为本发明动态加载行为监控中针对64位应用程序的动态加载so文件监控模块流程图。

图6为本发明动态加载行为监控中针对32位应用程序的调用so文件监控模块流程图。

图7为本发明动态加载行为监控中针对64位应用程序的调用so文件监控模块流程图。

图8为本发明动态加载行为监控中针对32位应用程序的动态加载dex文件监控模块流程图。

图9为本发明动态加载行为监控中针对64位应用程序的动态加载dex文件监控模块流程图。

图10为本发明监控日志生成流程图。

具体实施方式

为使本发明实施例的目的、技术方案和优点更加清楚，下面结合附图和实施例详细说明本发明的实施方式。

如图1所示，本发明基于native层api的移动应用程序动态加载行为监控方法，由三个部分组成，分别是监控控制，动态加载行为监控和监控日志生成。该方法的输入是用户指定的应用程序或pid进程。

本发明中各个的详细介绍如下：

1、监控控制

由于android系统使用了进程沙箱隔离机制，普通用户程序的进程空间都是独立的，程序的运行彼此间都不受干扰，所以如果要在别的进程中执行自定义的代码，就需要进行跨进程操作。对于跨进程操作，在android系统中一般是通过ptrace函数来附着进程，然后向宿主进程注入so文件，从而达到监控以及宿主进程关键函数挂钩的目的。

首先，在android设备开机之后监控系统立即执行注入so模块，即通过ptrace函数附着到目标进程上，然后利用mmap函数，在目的进程中为注入的so动态库文件分配内存，调用dlopen函数对注入的so动态库文件进行加载，完成so文件的注入。如图2所示，具体包括如下步骤：

(1)ptrace_attach，指定要附着的宿主进程的pid，开始进行so文件的注入；

(2)ptrace_getregs，获取要附着的宿主进程的寄存器值，并保存现场；

(3)get_remote_addr，获取要附着的宿主进程的mmap函数地址，以便为要注入的so文件分配内存；

(4)ptrace_call_wrapper，调用宿主进程中的mmap函数，为要注入的so文件分配内存；

(5)依次获取linker中dlopen、dlsym、dlclose和dlerror函数的地址；

(6)依次调用dlopen和dlsym函数来完成对so文件的注入以及对so文件中监控函数的调用；

(7)ptrace_detach，恢复(2)中保存的现场，并释放宿主进程。

然后监控系统执行hook模块，即执行注入的so文件中的函数，实现相应函数的监控，具体流程如图3所示。值得注意的是arm32位处理器支持两种指令集：arm指令集和thumb指令集。判断要进行监控的系统函数被编译成哪种指令集的方法是，判断系统函数的地址最后两位是否全为0。如果是，则使用的是arm指令集，否则使用的是thumb指令集。

针对arm指令集，进行hook，替换原系统函数汇编指令的方法是：首先，将这两个函数地址全部保存下来，然后用自定义的汇编跳转指令替换原系统函数的前三条汇编指令，最后刷新缓存，使得替换的指令生效。

针对thumb指令集进行hook，替换原系统函数汇编指令的方法在整体流程上同arm指令集的hook方法是一致的，只是汇编跳转指令换成了thumb指令集的指令，并且替换的是原系统函数的前十条汇编指令。

此外，arm64位处理器支持的指令集为armv8指令集，在这种情况下，对系统函数进行hook，替换原系统函数汇编指令的方法，在大致思路上，和arm32位处理器支持的arm指令集情况是一致的。这里替换的是原系统函数的前四条汇编指令。

2、动态加载行为监控

主要功能是对应用程序的动态加载行为进行监控。

恶意应用程序伪装成正常应用程序，想要进行恶意操作，最简单且普遍的做法是在后台动态加载带有恶意代码的第三方共享库文件(so文件)或dex文件。而动态加载这些文件，就需要调用androidnative层中的函数。所以，本发明在此处重点探讨了应用程序在native层的动态加载行为，即对动态加载so文件和dex文件行为的监控。本发明在此处虽然只针对这两种动态加载行为进行探讨，但是所提出的监控方法具有良好的扩展性，只要稍作修改，基本上能够用来监控native层的任意函数。

首先，动态加载so文件监控模块对应用程序动态加载的so文件的全路径文件名、操作时间戳以及操作进程的pid、uid进行监控。实际上监控的系统函数是void*dlopen(constchar*pathname,intmode)，具体流程如图4和图5所示。

其次，调用so文件监控模块对应用程序调用so文件时从so文件中获取的函数或变量名称、操作时间戳以及操作进程的pid、uid进行监控。实际上监控的系统函数是void*dlsym(void*handle,constchar*symbol)，具体流程如图6和图7所示。

最后，动态加载dex文件监控模块对应用程序动态加载的dex文件的全路径文件名、操作时间戳以及操作进程的pid与uid。实际上监控的系统函数是intopen(constchar*pathname,intflags,...)，具体流程如图8和图9所示。

3、监控日志生成

主要功能是根据各个代理函数的监控结果，输出所有的监控信息到指定的日志文件中，完成对用户指定应用程序的监控。其中arm32位的行为监控日志输出到“/data/local/tmp/integrity_32.log”，arm64位的行为监控日志输出到“/data/local/tmp/integrity_64.log”，具体流程如图10所示。