一、背景

近年来随着智能手机和移动应用的飞速发展，移动安全也得到大众越来越多的关注，安全事件层出不穷，恶意样本肆意泛滥，窃取个人隐私、恶意消耗资费等安全问题时常发生。如何识别恶意样本并对其进行分析，对进一步规范移动互联网的发展、加强移动互联网的治理及提高整个移动生态的安全性都具有非常重要的意义。

目前业界主要通过反编译、网络抓包、动态插桩三种方法来分析恶意样本，随着越来越多的恶意样本使用了混淆加固、证书钢钉、反调试等“反侦察”技术手段，恶意样本分析的难度与成本也越来越高。为了能够做好针对恶意样本的分析，本文分享一种新型思路——私人订制，打造白帽子专用移动系统！

二、整体思路介绍

Android是开源的，我们可以方便的获取到AOSP的完整源代码，我们可以对AOSP源码进行修改，定制一款操作系统，从而打造一款白帽子专用的手机。所谓定制ROM我们可以理解为定制操作系统，若要定制Android操作系统，我们需要对Android系统架构有一定的了解。

如上图所示，Android系统架构自上至下包括应用层、应用框架层、系统运行库层、硬件抽象层和Linux内核层五层。其中，应用层是与用户直接交互的部分，包含了许多应用程序，既包括相机、闹钟、通话等系统应用，也包括微信、各手机银行等非系统应用，当然也包括我们自己开发的应用和要分析的恶意样本应用；应用框架层为上层应用的开发提供了相应的API，一般来说上层应用都是通过调用应用框架层的API来与系统进行交互，上层应用通过该层实现各种核心逻辑；系统运行库层是应用框架层的支撑，为Android系统中各个组件提供服务，包含系统运行的核心库以及Android运行时库；硬件抽象层负责定义硬件交互的“接口”，为兼顾开源协议和保护硬件厂商的知识产权而设计；对于Linux内核层，Android系统的底层就是基于Linux操作系统的，其负责内存管理、进程管理及保障系统的安全性。

Android系统的正常运作也是基于该架构的，例如Android系统的启动便是手机通电后引导加载内核，从内核层自底向上逐层启动，直到位于应用层的Launcher启动完成，整个Android系统也启动完成。对于函数的调用，则是从应用调用应用框架层提供的api开始自上至下进行调用，并从下至上返回结果。回顾一下前言提到的3种恶意样本采取的干扰分析的防护手段，无论是加固混淆、证书钢钉或是反调试都是出于保护应用本身的目的，而恶意样本位于Android系统架构的最上层，所以我们可以通过对应用框架层甚至更底层进行修改，从而无需考虑各种防护手段实现对恶意样本的分析。也就是说，我们只需要控制恶意脚本各种反制措施的下层就可以控制恶意样本，从而进行分析，而对于恶意样本的开发者来说一般只会涉及到应用层和应用框架层两层。

三、基于订制移动系统的恶意行为检测

恶意行为检测是恶意样本分析的一项重要内容，下面就以此为例介绍我们如何通过定制系统实现对应用恶意行为的深度检测。目前主要有两种检测方法：静态检测和基于动态插桩技术的动态检测，其中静态检测对占据市场绝大多数的加固、混淆后的恶意样本检测效果比较差，很难通过阅读代码获取到有效信息。而基于动态插桩技术的动态检测则会严重影响性能，甚至不少恶意样本采取了很多防护策略导致无法动态插桩。而本文提出的这种新方案，是通过对系统底层的相关api进行修改，增加检测相关的代码实现，既可实现动态分析弥补静态分析效果差，也不会影响应用性能，并且本质上与动态插桩不同，不会受到恶意样本相关防护手段的阻碍。

恶意行为梳理

如下图所示，国家反病毒联盟对各种恶意行为进行梳理汇总，主要包括系统破坏、隐私窃取、远程控制、恶意传播、恶意扣费、资费消耗、诱骗欺诈、流氓行为等八大恶意行为。

风险函数归纳

基于前面梳理的八大恶意行为，结合工作经验完善补充一些像JSON中携带敏感信息之类的其他隐性恶意行为，通过编写demo实现这些功能、查阅相关资料等对这些恶意行为所涉及到的相关api进行归纳。最终整理了162个相关api，划分成27个功能类别，涵盖命令执行、网络通信、硬件交互、文件操作等风险行为。

技术实现

录音窃取是现在全社会重点关注的问题，部分恶意APP通过窃听我们的录音实现广告的定向推送，导致出现“上午才说起，下午就看到广告”的情况，这里我们以检测恶意录音行为为例介绍定制系统下的技术实现方法。

应用通过调用应用框架层AudioRecord提供的startRecording和stop方法来实现开始录音与结束录音功能，录音功能的底层实现如上图所示，应用自上至下逐层调用系统提供的api，并从下往上将结果返回给应用层。对应用开发来说一般都是通过应用框架层提供的api来实现核心逻辑，所以本文主要通过对应用框架层的源码实现进行分析并对录音行为进行简单的记录。

关键类所在路径如下：

frameworks/base/media/java/android/media/AudioRecord.java 
frameworks/base/core/jni/android_media_AudioRecord.cpp 
frameworks/av/media/libmedia/AudioRecord.cpp

APP调用startRecording方法开始录音，startRecording方法定义如上图内容所示，先判断AudioRecord初始化状态，未初始化则抛出异常，否则调用native_start方法。判断native_start返回结果是否等于SUCCESS，是则设置录音状态。

native_start的定义如上图所示，我们可以看到修饰符native，在本案例中应用框架层包括两层，分别是Java Framework和Native Framework，二者通过JNI进行交互。JNI提供了一种特殊的数组类型JNINativeMethod，用它来记录Java和Native函数的映射关系。

如上所示native_start对应的native函数为android_media_AudioRecord_start，继续跟踪该方法的定义。

在android_media_AudioRecord_start函数中，首先获取一个AudioRecord的强指针，获取失败则返回一个错误码。调用Audio的start方法，并通过nativeToJavaStatus将返回的状态转成jint返回给Java层处理。

继续分析AudioRecord.cpp中start函数的逻辑实现，前面我们已经分析到该函数需要返回一个status，如上图红框标出，start函数需要调用mAudioRecord的start，那么mAudioRecord是什么？

继续分析mAudioRecord的start函数实现，其定义在IAudioRecord.cpp，具体实现如下图所示。

如上图源码所示，通过Binder机制调用remote()的transact实现与AudioServer进程的IPC。其实到这里所分析的内容已经足够实现对应用录音行为的检测了，对前面源码分析进行简短的回顾：应用调用AudioRecord.java的startRecording，通过JNI函数native_start调用android_media_AudioRecord_start函数，最终通过Binder机制访问AudioServer进程，并逐级返回结果交由应用进行处理。如何检测录音行为呢？其实从前面的分析，我们可以定位多个可以修改的函数，出于通用性和封装性等各方面的考虑，我们可以直接对startRecording进行修改，如下图所示。

通过前面的工作便可以对录音行为进行检测，当然startRecoring只是众多选择中的一个，也可以通过修改其他函数实现录音行为的检测。另外对于System类，相信大家都不陌生，System代表系统放置了很多系统级的变量和控制方法，所有的Java类都可以无需导入而使用该类，所以我们对此类进行拓展封装函数saveRecord来实现恶意行为的记录。最终我们可以检测录音行为，并对应用包名、调用栈、调用时间等信息进行记录，效果如下图所示。

四、总结与展望

由于Android开放的生态，一方面吸引了大批量的厂商和应用开发者，另一方面也导致恶意应用的滋生、蔓延。现在包括网络抓包、反编译等主流的几种分析方法，都受到恶意样本自身实现防护手段的一定干扰。现在各种恶意样本还是非常嚣张，采取各种反制措施来阻碍恶意样本分析，定制一款专用移动系统，可以突破恶意样本的“反侦察”技术手段，能够更好的进行恶意行为的分析。并且从Android系统架构来看大有向更底层发展的趋势。未来，恶意样本分析或许会面临更全面、更深层次的挑战。

参考链接

[1] https://blog.csdn.net/lzqustc/article/details/117197263