面向安卓系统的环境感知API自动化检测方案

An Automatic Detection Scheme for Android Environment-Aware API

摘要

针对恶意软件利用环境感知能力来逃避分析系统检测的现状，深入研究基于系统应用程序接口（Application Program Interface， API）的环境感知技术，并实现全面检测环境感知API的自动化工具EAFinder（Environment-Aware API Finder）。EAFinder能够枚举所有的系统API，并在真机和模拟器中进行自动化调用，最终通过比较API在不同环境中的可访问性和返回值的差异，检测出环境感知API。实验结果显示EAFinder在Android 9至13上共检测出344个API，排除误报后得到323个可用于环境感知的API。将其按使用方式分为独立使用、基于阈值使用和组合使用三类，并抽样测试了各类API的有效性，结果显示利用这些API能以97%的准确率区分真实设备和模拟器。

Abstract

To address the challenge of malware leveraging environment-aware capabilities to evade detection systems, this study explores environment-aware techniques based on system Application Programming Interfaces (APIs), and implemented an automated tool called Environment-Aware API Finder (EAFinder) for comprehensively identifying environment-aware APIs. EAFinder can enumerate system APIs and automatically invoke them in real devices and emulators. It can then detect environment-aware APIs by analyzing the discrepancies in accessibility and return values across different environments. Experimental results show that EAFinder detected 344 APIs across Android versions 9 to 13, with 323 APIs confirmed as environment-aware after eliminating false positives. This paper categorized them into three classes: independent usage, threshold-based usage, and composite usage. Sampling tests of each API category demonstrated that these APIs could distinguish real devices from emulators with an accuracy rate of 97%.

Graphical abstract

关键词

移动安全 / 环境感知 / 模拟器检测 / 系统应用程序接口

Key words

mobile security / environment-aware / emulator detection / system Application Program Interface(API)

0　 引 言

安卓系统生态庞大，用户众多，逐渐成为恶意软件攻击的首要目标。应用市场作为应用分发的主要渠道，其运营人员有必要更有责任在应用上架前进行全面的安全分析，并在上架后持续进行安全检测。安卓应用市场规模宏大，这对运营人员的分析检测效率提出了严峻挑战。

在上述背景下，恶意软件自动化分析系统得到广泛应用，这类系统能够自动对应用进行动态分析，捕捉其异常行为，极大地提升了应用检测的效率。出于性能和成本等因素的考虑，这类分析系统通常选择在虚拟化环境（即模拟器）中实施动态分析。尽管模拟器具有部署迅速、资源利用率高和便于管理等优势，但其与真实设备的差异也为分析系统带来了额外的挑战。

近年来，恶意软件为了逃避分析系统的检测，逐渐衍生出环境感知（environment-aware）能力。环境感知通俗来讲即恶意软件具备判断自身运行环境的能力，使其在不同运行环境中选择性地表现恶意行为^[1，2]，例如在真实设备中窃取用户隐私数据，而在模拟器中保持休眠状态以隐藏其恶意目的。尽管环境感知本质上并非漏洞，但其危害胜似漏洞。环境感知能力提升了恶意软件的隐蔽性，增加了应用审查人员的分析难度，从而延长了恶意软件的存活时间，导致其传播范围和受害人数增加。因此，深入研究环境感知技术，对阻止恶意软件的逃避行为具有重要意义。

环境感知技术的核心在于发现真实设备和模拟器之间的系统特征差异。安卓系统应用程序接口（Application Program Interface， API）作为应用和系统框架之间的桥梁，能够为上层应用提供丰富的系统特征信息。目前，绝大部分恶意软件（如Pincer^[3])采用的环境感知方式即调用安卓系统API，并根据调用结果判断运行环境^[4]。因此，本文着重研究基于系统API的环境感知技术，并将可用于环境感知的系统API定义为环境感知API。

在攻防博弈中，恶意软件可以利用环境感知API来逃避分析；分析人员则可以有针对性地提前修复环境以检测恶意软件，还能利用这些API识别隐藏的敏感行为^[5~7]。因此率先发现环境感知API的一方将占据主动地位。然而，目前通常采用被动的方式发现环境感知API，即通过分析现有的恶意软件才能发现需要防护的API，这导致安全分析人员在与恶意软件的对抗中处于落后，无法提前防护和对抗环境感知攻击^[4]。现有的一些主动发现环境感知API方法^[8~13]大多采用人工分析的方式，效率较低且容易遗漏，并且在安卓系统更新时，需要重新进行手动分析，这会导致重复劳动和时间浪费。此外，自动化检测环境感知API的工作^[14]仅考虑无参数API，其攻击面较窄。

因此，亟需一种能适用于各个系统版本的、覆盖攻击面广的自动化方法，来提升环境感知API的检测效率和覆盖率。本文设计并实现了自动化检测环境感知API的工具EAFinder（environment-aware API Finder）。主要贡献总结如下：

1) 提出更全面的环境感知API检测方法。本文枚举了系统中所有参数类型的API作为潜在攻击面，并通过参数自动化构造策略解决复杂参数API的调用问题，提升了环境感知API的检测覆盖率。除API返回值差异外，还基于可访问性差异提出新的攻击维度，扩展了攻击面。

2) 实现自动化检测环境感知API的工具EAFinder。EAFinder能够自动运行且耗时短，并适用于各个安卓系统版本，为分析人员提供一个有益的工具来快速有效地获取环境感知API列表。

3) 本文对检测出的环境感知API进行了系统分析和总结归纳，按使用方式划分为独立使用、基于阈值使用、组合使用三大类，并抽样测试了各类环境感知API的有效性。

1　 相关工作

研究环境感知技术对检测恶意软件具有重要意义，其核心在于分析模拟设备与真实设备之间的差异，涉及系统API、性能、文件信息、属性字段等多个方面。本文重点关注基于系统API差异的环境感知技术。

学者们对环境感知技术进行了研究，并发现了各种环境感知API。Petsas等^[8]借鉴Windows平台上的环境感知技术，提出通过系统API和属性字段等方式来检测安卓模拟器的方法，具体包含获取设备标识符和传感器信息的6个API。在同样思路下，Vidas等^[9]发现了新的环境感知API，并提出可以利用性能和文件信息等其他方面的差异来识别模拟器。Gajrani等^[10]总结了现有的模拟器检测技术，并实现了一个能够对抗部分检测技术的动态分析系统。Costamagna等^[11]发现主流动态分析系统中的模拟器普遍存在缺陷，即获取位置、电池状态和应用等设备使用情况的系统API的返回值为空值、固定值或随机值。Kondracki等^[12]参照Kurtz等^[15]的思路，通过手动查找安卓软件开发工具包（SDK），得到81个提取环境信息的API。然而，恶意软件不仅能利用SDK中的API，还能利用客户端隐藏API和服务端API进行环境感知，仅依赖SDK文档进行查找会导致攻击面枚举不充分。Song等^[13]通过研究安卓系统源码和分析修改设备环境信息的应用，收集了大量可用于环境感知的差异信息，其中涉及到约90个环境感知API，并基于上述信息构建了能够对抗恶意软件环境感知行为的虚拟化环境。

尽管上述研究通过借鉴Windows平台上的研究、分析现有模拟器缺陷和查找系统公开API等途径来主动发现新的环境感知API，但由于系统API数量众多，采取人工分析的方式，不仅给安全人员带来巨大的工作量，而且会不可避免地存在遗漏API的情况。此外，随着安卓SDK和系统服务的不断更新，恶意软件利用API进行环境感知的攻击点也在不断地变化。例如Android 11新增可用于环境感知的StorageManager.isCheckpointSupported()方法，使用原有的非自动化方法无法及时发现此方法。Jing等^[14]在自动化检测环境感知API领域作出了首次尝试，实现了名为Morpheus的自动化工具。该工具只能分析无参数API，仅覆盖不到200个API，考虑的攻击面较为狭窄。上述工作的总结如表1所示。为了解决上述问题，本文提出了能适用于各个系统版本的、全面考虑攻击面的自动化检测环境感知API的工具EAFinder。

2　 方案设计与实现

2.1　威胁模型

在本文的威胁模型中，假设攻击者能控制受害者设备上的一个非系统应用。该应用通过环境感知API来判断当前运行环境，并有选择性地表现恶意行为。一旦检测到模拟器，它将保持休眠状态。此外，假设模拟器以默认配置运行，这也是现有部署模拟器的动态分析系统的常见情况。

2.2　整体框架设计

EAFinder的核心思路是先枚举系统中所有的API作为潜在攻击面，然后在同机型同版本的真机与模拟器中自动化调用上述API，最终通过比较API在不同环境中可访问性和返回值的差异，检测出环境感知API。EAFinder框架由五个模块组成，如图1所示。本方案参考小程序^[16]和状态推断^[17]领域的API检测工作。

1） 枚举攻击面：安卓系统API由系统服务提供，因此EAFinder通过系统服务提取模块获取安卓系统中所有的系统服务，以及各服务对应的客户端及服务端类。考虑到本文威胁模型下的恶意软件是非系统应用，无法访问所有API，所以本文使用可访问性过滤模块筛选出攻击者可访问的API，该模块尝试访问类及其中方法，并记录每个API的可访问情况，然后移除无法访问的API。记录的可访问性信息用于后续筛选基于可访问性差异的环境感知API。通过功能性过滤模块进一步移除不可能泄露环境信息的API。需要说明的是，系统服务提取模块获取的信息能枚举出所有系统API，可访问性过滤模块和功能性过滤模块的过滤是为了提升分析基于返回值差异的环境感知API的效率。

2） 调用筛选出的API：自动化调用模块负责自动化构造输入参数，并尽可能收集多种输入下的方法执行信息。

3） 检测环境感知API：通过差异分析模块比较在真机和模拟器中的测试记录，识别可访问性和返回值存在差异的方法，得到环境感知API。

EAFinder框架中除系统服务提取模块和差异分析模块在主机上执行，其余模块均以应用的形式在设备中运行。

2.3　系统服务提取模块

系统服务是安卓系统的重要组成部分，承担着与底层组件和资源等交互的重要任务。一般情况下，系统服务主要由系统服务客户端和系统服务服务端两部分构成。客户端与服务端中均包含许多方法，客户端方法即通常意义下所述的API，这些API是系统服务暴露给应用的调用接口；而服务端方法是完成系统服务具体功能的实现。正常情况下，应用程序仅能调用客户端方法，安卓系统会处理调用并将其传递给对应的服务端方法，以完成相应功能。然而，应用程序也可能通过非常规手段直接调用服务端方法。因此，本文将服务端方法也纳入枚举API的考虑范围。

综上所述，为了全面枚举API，EAFinder以系统服务为出发点，完整提取所有系统服务及各服务对应的客户端和服务端类。EAFinder使用的提取系统服务的方法包括安卓源码静态解析和SHELL动态获取两部分。安卓源码静态解析部分基于JavaParser构建，通过解析安卓源码中的系统服务注册方法（addService、publishBinderService和registerService）^[18]，从方法的调用参数中提取系统服务名称及其客户端类名。SHELL动态获取部分则在模拟器和真机上分别运行“adb shell service list”命令，以获取系统服务名称及其服务端接口名，并将接口名转换为实现类名。EAFinder整合上述信息，形成一个包含系统服务名称、客户端类名和服务端类名的列表，用于后续进行API的枚举和调用。

2.4　可访问性过滤模块

本文的威胁模型假设攻击者控制的是一个非系统应用。安卓系统中，非系统应用受SELinux安全策略^[19]以及签名级权限的限制，其访问部分系统服务的类或API时会引发安全异常，从而无法与所有系统服务进行交互。因此，EAFinder需要筛选出非系统应用能够访问的类和API。

可访问性过滤模块通过动态分析和异常监控的方法，在类和API两个层面上进行筛选。在类层面上，本模块基于前述模块提取的客户端和服务端类的信息，尝试访问这些类并监控是否出现异常，从而移除引发安全异常的类；在API层面上，针对能够访问的类，本模块使用Java反射机制枚举并访问其API，记录每个API的可访问情况及可能出现的异常信息。然后，本模块根据可访问情况，移除引发“SecurityException”安全异常的API，从而过滤出可访问的API。上述API的调用通过自动化调用模块实现，此处不展开描述。

本文使用Java反射机制来获取和调用API，以确保API的全面枚举。反射机制能够绕过编译时的检查，在应用运行时动态获取类和方法。因此，通过反射机制，EAFinder不仅能够调用安卓软件开发包（Software Development Kit，SDK）中公开的API，还能够调用未在安卓SDK中声明的隐藏API，包括客户端隐藏API和服务端API。以phone服务为例，能直接调用的方法数量为105个，而使用反射能调用的方法数多达259个，数量增加了146%。与相关工作相比，本文突破了安卓SDK的限制，额外调用并分析隐藏的API，进一步拓宽了攻击面的枚举。

本文研究发现真机和模拟器的可访问的API存在差异，因此API的可访问性也能作为环境感知的依据。这一思路是本文首次提出的新攻击维度。差异分析模块会利用本模块记录的各API可访问情况，检测出可访问性存在差异的API。

2.5　功能性过滤模块

本模块的目标是筛选出具有返回值的API，只有这样的API才可能从返回值体现出不同环境的差异。特别地，本文将可变的输入参数理解为另一种形式的返回值。

对于客户端方法，本模块采取较为保守的方式，移除客户端方法中既没有返回值又没有输入参数的方法。对于服务端方法，本模块利用安卓接口定义语言AIDL（Android Interface Definition Language, AIDL）的关键字，进行更为准确的筛选。服务端使用AIDL声明其提供的接口，其中接口关键字“oneway”用于标识单向通信接口，即调用者无法通过该接口获取信息；参数关键字“out”表示输入参数可以被调用者修改。本模块静态分析每个系统服务对应的AIDL文件，移除有“oneway”关键字，或返回值为空且所有输入参数没有“out”关键字修饰的方法。

EAFinder采用两个模块进行方法过滤，首先是动态的可访问性过滤，其次是静态的功能性过滤。这两者的顺序不能颠倒。因为某些没有返回值的API虽然不能通过返回值泄露环境信息，但仍可能从可访问性的维度反映运行环境的差异。经过动静态过滤，EAFinder能够获取攻击者可访问且能传输信息的API列表。

2.6　自动化调用模块

本模块会自动化构造参数，并按策略调用前述模块筛选出的API。

2.6.1　参数构造

理解参数的语义并传递合适值，将有效减少因参数构造不佳导致API调用失败的情况。因此，本文通过解析源码中方法的参数类型和名称，提取了五类语义参数。

① 应用标识符：标识安装的应用的参数，如uid和packagename；

② 进程标识符：标识设备上运行的特定进程的参数，如pid；

③ 文件系统位置：标识文件系统中的存储卷，如storageUuid或volumeUuid；

④ SIM卡标识符：标识设备中的SIM卡，如subId或slotIndex；

⑤ 时间值：与时间和时间范围相关的参数，如beginTime、startTime和endTime。

参数构造的整体算法流程如图2所示。针对上述有语义信息的参数，算法会采用静态或动态的方式，根据其语义进行初始化。例如，packagename参数的值可以静态定义为当前应用包名；pid参数的值需要在运行时进行获取，可以使用pid=android.os.Process.myPid()动态定义为当前进程的pid。针对没有语义的参数，按其参数类型进行构造。Boolean、int、long等基本类型的参数，会根据参数类型，生成随机值进行初始化。而数组和对象类型的参数构造建立在基本类型的基础上。

由于某些对象可能包含许多对其他对象的引用，每一个中间对象都必须正确创建，才能正确实例化最终对象。为了自动化执行此过程，本模块采用递归算法来构造对象类型参数。该算法通过迭代调用所有的构造器函数，并递归创建中间对象，直至成功实例化目标对象。对于每个嵌套对象，都会重复此过程。由于递归方法可能会导致循环依赖和崩溃，算法将最大递归层数设置为5。此外，对于数组类型的参数，会随机定义数组长度，并同样使用递归来构造其元素值。对于构造失败的93个参数（约占总数的2%），本文手动编写了相应的处理函数，构造这些参数时会进入自定义程序中进行处理。

以LocationManager.getProviders(android.location.Criteria;boolean)为例，算法会首先查询参数是否具有语义信息，发现这两个参数没有语义信息，然后对于第一个对象类型的参数获取构造函数列表，尝试第一个构造方法public android.location.Criteria()，成功构造对象Criteria[power=NO_REQ acc=---]；对于第二个基本类型的Boolean参数，按类型随机构造为true或false。

2.6.2　自动化调用策略

本模块将采用两种参数构造策略，调用前置模块筛选出的方法。首先运行固定参数策略，排除不稳定的方法；然后运行可变参数策略，收集多种输入下方法的执行情况。两种参数构造的具体策略说明如下。

1） 固定参数策略

本策略的目标是排除不稳定的方法。固定参数策略只构造一次参数，并以此参数作为输入，重复调用十次方法。若方法的返回值在十次调用中均不重复，本文将视其为不稳定的返回值，这些返回值主要是随机值和增量值等。除时间信息外，其他不稳定返回值都难以提供环境信息。针对每个不稳定的返回值，本模块都会尝试将其解析为合法的时间格式，若解析成功且结果合理，则保留该方法；否则丢弃该方法。

2） 可变参数策略

本策略的目标是收集多种输入下方法的执行情况。可变参数策略会多次构造不同的参数并调用API，以获取更全面的API执行结果。某些方法仅在特定参数下泄露环境信息，如KeyguardManager.isDeviceSecure(int)仅在输入为0时，其返回值在不同环境中存在差异。若不改变参数进行测试，可能会错误地排除此方法。

对于可枚举的参数类型，如Boolean类型，本策略会构造所有可能的值，来收集所有输出。对于无法枚举的参数类型，本策略会在可选范围内改变参数值，以收集更多的输出。其中参数取值范围的设置，参考了小程序安全领域的自动化测试API的方案^[16]。例如，针对int类型，本文考虑了-1到100的数字范围；针对String类型，本文通过解析源码，得到一个频繁用于输入的字符串列表。

本模块会详细记录方法的执行情况，包括类和方法原型、输入参数、执行状态、返回值和异常信息。当方法执行成功时记录返回值，而当执行失败时记录异常信息。

2.7　差异分析模块

通过分析和比较相同机型和系统版本的真机和模拟器上的测试结果，本模块能够检测出在不同环境中可访问性和返回值存在差异的API，得到环境感知API。具体检测策略如下。

1） 检测可访问存在差异的API

本策略的输入是可访问性过滤模块记录的各API可访问情况。通过比较不同环境中API的执行状态和异常信息，来检测此类API。具体而言，若某个API在任一参数输入时，在不同环境中的执行状态不同；或均执行失败但异常信息不同，则将其视为可访问性存在差异的API。

2） 检测返回值存在差异的API

本策略的输入是自动化调用模块中记录的各API执行情况。通过比较不同环境中API的返回值，来检测此类API。具体而言，若某个API在任意一个参数输入时，在不同环境的返回值存在差异，则将其视为返回值存在差异的API。

3　 实验结果与分析

3.1　EAFinder检测结果及分析

3.1.1　检测结果

为了评估EAFinder在不同系统版本上的效果，本文选择了Android 9至13共五个系统版本进行测试。本节以Android 10的测试结果为例，详细描述环境感知API的检测过程，并展示了EAFinder在五个系统版本上的测试结果。本节使用的真机和模拟器的设备型号为Pixel 4和Pixel 2，真机的镜像由谷歌官方提供^[20]，模拟器的镜像由Android Studio提供。

首先，EAFinder会提取系统服务及其客户端类和服务端类。Android 10中，EAFinder共提取到207个系统服务。如图3所示，这些系统服务的客户端类的数量在真机和模拟器上均为116个，服务端类的数量分别为152个和137个。然后，EAFinder会对上述类进行可访问性测试，结果显示可访问的客户端类和服务端类在真机中为91个和61个，在模拟器中为87个和61个。这是因为类的可访问性主要是由系统安全策略决定的，例如WifiScanner等类仅允许系统应用访问。此外，还有8个类在可访问性方面存在差异，例如真机能访问WifiAwareManager和RttManager等类，而模拟器无法访问，这些类对应的API在可访问性方面也存在差异。

提取完可访问的类之后，EAFinder会获取这些类的所有方法并进行筛选。首先，EAFinder会对方法进行可访问性测试。如图4所示，真机中，EAFinder获取到客户端和服务端方法总数分别为2 143个和100个，其中可访问的数量分别为1 093个和91个；模拟器中，EAFinder获取到客户端和服务端方法总数分别为2 128个和100个，其中可访问的数量分别为1 057个和91个。同时，EAFinder还会记录所有方法的可访问性，用于后续差异分析模块。接着，EAFinder会对可访问的方法进行功能性过滤，得到候选方法。在真机中，客户端和服务端的候选方法数量分别为805个和88个；在模拟器中，客户端和服务端候选方法数量分别为801个和88个。最后，EAFinder使用自动化调用模块调用上述候选方法，运行固定参数策略，得到稳定方法。真机中，客户端和服务端的稳定方法数量分别为673个和30个；模拟器中，客户端和服务端的稳定方法数量分别为668个和30个。

通过上述筛选，真机对应的客户端方法从2 143个减少到673个，服务端方法从100个减少到30个；模拟器对应的客户端方法从2 128个减少到668个，服务端方法从100个减少到30个。此过程大幅减少了后续需要分析的方法数量，有效提升了分析效率。

完成方法筛选后，EAFinder继续使用自动化调用模块，运行可变参数策略，记录多种输入下的方法执行情况。然后使用差异分析模块分析自动化调用结果以及之前记录的各方法可访问性。分析结果如表2所示，EAFinder共检测到179个环境感知方法，其中147个方法返回值存在差异，34个方法可访问性存在差异。需要说明的是，这些环境感知方法中有2个方法在不同参数下，既会表现出返回值差异，又会表现出可访问性差异，因此环境感知方法的总数小于两种存在差异的方法数之和。

EAFinder在Android 9至13上的测试结果如表3所示。EAFinder在各版本中均能有效运行，共检测出344个不重复的环境感知方法，包括248个返回值存在差异的方法和102个可访问性存在差异的方法。此外，EAFinder在各版本中的运行时间均接近20 min。上述结果表明EAFinder具有较好的版本兼容性和较高的运行效率。

3.1.2　结果分析

本节从三个方面对3.1.1节的实验结果进行分析。

1） 误报分析

通俗意义上，EAFinder不存在误报，即EAFinder在五个系统版本上检测出的344个环境感知方法均会在真机和模拟器中表现出差异。但考虑到这些API的使用目的是环境感知，因此本文将其中无法用于区分环境的API定义为“误报”。通过动态分析，并结合开发者文档和系统源码，本文对上述344个API进行了逐个分析。结果显示，其中存在21个“误报”，EAFinder的环境感知API检测准确率为93.8%。“误报”API的返回值大多是用户自定义信息，与环境无关，无法用于区分真机和模拟器。例如，获取壁纸颜色的WallpaperManager.getWallpaperColors(int)方法和查询最大音量的AudioManager.getStreamMaxVolume(int)方法等。

排除误报后，本文最终确认了323个可用于环境感知的API，包括227个返回值存在差异的API以及102个可访问性存在差异的API。这些API分布于53个系统服务中，如表4所示。本文将在3.2节中对这些API进行分类和详细介绍。

2） 各版本环境感知API的差异

虽然各个系统版本的环境感知API数量接近，但API本身存在显著差异。这主要由两方面原因导致：一方面，API会随安卓系统版本迭代发生变化，如新增、修改、删除；另一方面，模拟器也会不断升级和完善其功能，细节上更为贴近真机，导致部分API不再能用于环境感知。

以Android 10和11的检测结果为例，Android系统版本从10升级到11后，出现了19个新的环境感知API，例如Android 11新增的方法StorageManager.isCheckpointSupported()；而40个环境感知API不再可用，原因包括权限变更、方法被加入黑名单、方法被移除、模拟器功能升级等，例如用于查询是否支持扫码添加WiFi的WifiManager.isEasyConnectSupported()方法，Android 10的模拟器进行扫码操作时会导致应用崩溃；而Android 11的模拟器能调用虚拟摄像头模拟此过程，导致此API不再具有区分性。

各版本环境感知API的差异，突显了自动化环境感知API分析工具的重要性和必要性。通过EAFinder，安全分析人员能够在各个版本系统中快速有效地获取环境感知API列表，及时对模拟环境进行修复。

3） EAFinder的具体贡献

相较于先前工作，EAFinder在以下四个关键方面进行了改进，增强了检测环境感知API的能力：

① 扩展自动化分析API的覆盖范围。EAFinder使用反射机制全面枚举系统API，并通过参数自动构建策略解决了复杂参数API的调用问题，自动化调用并分析了2 000多个系统API。最终确认的环境感知API中有133个是有输入参数的API，占总数的41%。这弥补了先前工作仅考虑无参数API的不足，也凸显了本文自动化构造参数方法的有效性。

② 扩展攻击维度。本文提出基于API可访问性的差异进行环境感知的新攻击维度，并使用EAFinder检测出102个此类型的API，拓展了环境感知的攻击面。

③ 显著提升分析效率。EAFinder的检测准确率高达93.8%。安全人员原先需要分析系统中的所有API，而现在仅需分析EAFinder检出的API，平均从2 231个减少至171个，减少了92%的工作量。此外，EAFinder的运行速度较快，每个系统的分析仅需20 min左右。

④ 具有较好的兼容性。EAFinder能适用于各主流系统版本，并平均检测出171个环境感知API。

3.2　环境感知API分类

通过对检测到的323个环境感知API进行深入分析，本文将这些API按照其使用方式分为独立使用、基于阈值使用和组合使用三类。其中部分API仅适用于部分系统版本，例如TelephonyManager.getImei()等获取设备的不可重置标识符^[21]的API仅在Android 9上可用，从Android 10开始，应用必须具有签名级别权限才能调用这些API。为确保环境感知的有效性，应用可以先识别设备系统版本，再使用支持此版本的API进行环境感知。

3.2.1　独立使用

此类API的使用不需要额外信息，能够独立用于环境感知，根据它们的功能和特点可分为以下四类。

1） 硬件。即使是廉价设备也通常具有扬声器、振动器、计步器等普遍使用的硬件，然而部分模拟器未提供这些硬件。通过查询流行硬件的配置情况，可以区分真机和模拟器。例如使用SystemVibrator.hasVibrator()可以查询是否配置振动器。

2） 设备隐私与安全。相较于真实设备，模拟器不够重视设备的隐私和安全。通过关注设备隐私和安全相关的设置，可以揭示真机和模拟器的差异，例如设备是否设置及启用锁屏、设备密码复杂度的默认要求级别以及是否支持设备ID验证等。模拟器普遍没有开启锁屏，使用KeyguardManager.isDeviceSecure(int)能获取设备的锁屏设置情况。

3） 模拟器指示字段。部分API的返回值中包含指示模拟器的特殊字段，例如网络地址为10.0.2.*的形式^[22]、运营商名称为Android、WIFI名称为AndroidWifi等。因此可以识别返回值中的指示字段来进行环境感知。例如，使用IConnectivityManager$Stub$Proxy.getActiveLinkProperties()或WifiManager.getDhcpInfo()获取设备的网络信息，查询IP地址、网关、DNS服务器地址是否为10.0.2.*的形式，来识别模拟器的存在。

4） 模拟器信息缺失。模拟器无法获取部分信息，例如，由于模拟器未配备SIM卡，当使用方法TelephonyManager.getSimCarrierId()获取运营商标识符，或使用TelephonyManager.getGroupIdLevel1()获取SIM卡标识符时，模拟器中的返回值均为无效值。

3.2.2　基于阈值使用

此类API用于获取使用频率、硬件数量等两大类数量信息。这些数量信息在真机和模拟器中存在差异。为了进行环境区分，需要根据市面上设备特征的平均数量或最小数量来确定一个合适的阈值。

1） 使用频率。通过应用、共享库和小组件等数量信息，可以推断设备的使用频率。若使用频率低，则设备可能较新，不包含有价值的信息，或是仅供测试的模拟器。例如，使用方法IPackageManager$Stub$Proxy.getInstalledPackages(int,int)获取设备上的应用安装情况，从中得到应用安装数量，同时还可以进一步查询是否安装微信和支付宝等常见应用。此外，网络配置、电池状态等也能间接揭示设备的使用频率。例如使用方法WifiManager.getConfiguredNetworks()获取设备中保存的无线网络配置数量，较多的网络配置表示用户经常连接到不同的网络，设备的使用频率较高。

2） 硬件数量。模拟器的硬件配置数量普遍比真机少。以传感器为例，使用方法sensorManager.getSensorList(int)可以获取传感器的总数及各传感器的型号和版本。真机通常配置丰富的传感器，以满足不同的应用需求，而模拟器配置的传感器数量有限，且版本较低。

3.2.3　组合使用

此类API需要相应型号的真机数据或目标地区作为比对依据，才能用于环境感知。按使用API所需的前置数据进行分类，可分为以下两类。

1） 特定型号的真机数据。移动设备的默认参数和硬件配置由制造商决定，用户无法自行修改。恶意应用可以提前收集真机的默认参数和硬件配置，并将其与当前运行设备的相应值进行比对，若存在差异，则认为当前设备是模拟器。默认参数包括设备的屏幕分辨率、屏幕尺寸、默认亮度和最小亮度等。硬件配置包括面部识别、指纹识别和听力辅助等所需的特殊硬件。例如，Pixel 4用面部解锁完全替代了指纹解锁，不支持访问FingerprintManager类，而模拟器仍能访问此类。因此，当恶意软件使用Build类方法识别到设备型号是Pixel 4时，可以通过FingerprintManager类API（如getEnrolledFingerprints()）的可访问性来区分真机和模拟器。

2） 目标地区。若恶意应用对于实施攻击的地区有明确计划，那么可通过经纬度、运营商、网络注册地等信息来获取设备的当前位置，并根据结果和目标地区匹配结果，来决定是否执行恶意行为。

3.3　环境感知API的有效性验证

3.3.1　实验环境

为了验证EAFinder检测出的环境感知API的有效性，本文构造了一个具有环境感知能力的恶意应用，并在设备数据集上进行了测试。

分别从三类环境感知API中抽取了10个，共30个API，具体使用的API和区分依据如表5所示。该应用采取多数表决的方式来判断当前运行环境，即当超过半数的API指示当前设备是模拟器时，则将此设备分类为模拟器，反之亦然。本文使用3.1节的实验数据作为阈值设置的参考，并收集Pixel 4、Pixel 2、华为P30 Pro和Samsung Galaxy S7的真机数据作为比对依据。

设备数据集包含50个模拟器和50个真机。设备系统版本覆盖Android 9至13，厂商包括谷歌、三星、华为、小米等，这一范围能涵盖大多数用户的选择。模拟器实例使用Android Studio和Genymotion来创建。

3.3.2　评估指标

本文将数据集中的真机和模拟器分别使用阳性样本和阴性样本标记，并将分类结果划分为以下四个类别：真阳性（True Positive, TP）表示将真机识别为真机的数量；假阳性（False Positive, FP）表示将模拟器识别为真机的数量；真阴性（True Negative, TN）表示将模拟器识别为模拟器的数量；假阴性（False Negative, FN）表示将真机识别为模拟器的数量。

为了评估环境感知应用对于运行环境的区分能力，选取准确率（Accuracy）、假阴性率（False Negative Rate, FNR）和假阳性率（False Positive Rate, FPR）作为评估指标。准确率表示全体样本中预测正确的样本的占比，其值越大说明分类效果越好。假阴性率表示真机被错误地预测为模拟器的占比，其值越小表明真机被误判的概率越低。假阳性率表示模拟器被错误地预测为真机的占比，其值越小表明模拟器被误判的概率越低。恶意软件更为关注假阳性率，因为将模拟器误判为真机，会导致其在分析环境中表现出恶意行为，从而被安全人员检测到并迅速从应用市场中删除。

3.3.3　实验结果

本文在数据集的设备上运行了构造的环境感知应用。实验结果显示，应用进行环境区分的准确率为97%，假阴性率为4%，假阳性率为2%。此外，测试结果中仅有一个模拟器被误判为真机，假阳率较低。

为了评估各类API的环境感知表现，本文还计算了独立使用类、基于阈值使用类和组合使用类API的平均准确率，分别为97.2%、83.8%和87.2%。其中独立使用类的API表现最好，几乎能区分所有的真机和模拟器。组合使用类API尽管只适用于部分机型，但它在特定机型上的综合表现较好，其中WindowManagerImpl.getDefaultDisplay()方法的准确率较低，主要原因是Genymotion对于屏幕物理尺寸、分辨率、像素密度等信息模拟得与真机一致，导致此API误报较多。基于阈值使用类的API表现相对较差，原因是设置阈值时参考的样本集较小，设置得不够合理。其中获取小组件提供者的方法AppWidgetManager.getInstalledProviders()的准确率仅为58%，是30个API中最低的。

结果表明，恶意软件可以利用EAFinder检测出的环境感知API区分运行环境，从而达到逃避动态分析的目的，验证了EAFinder的有效性。

4　 防御措施

为了对抗恶意软件的环境感知行为，本文提出以下防御措施。

1） 分析系统监控环境感知API的调用情况。虽然这样不能阻止恶意软件检测出模拟器环境，但能向分析师发出告警，破坏恶意软件隐藏自身的原始目的。分析系统开发人员可以使用EAFinder来获取环境感知API列表，并以此列表为参考，全面监控环境感知API的调用情况。

2） 提升模拟器等分析环境的透明性，使其细节上更为接近真机^[23]。例如使用Hook技术修改环境感知API的调用返回值，向应用返回真实设备中的数据^[10]。虽然这种做法已经被广泛采用，但本文实验结果表明，现有模拟器仍存在许多能泄露环境信息的API。安全分析人员可以使用EAFinder来获取环境感知API列表，并基于此列表全面地增强模拟器的透明性，以构建更真实的分析环境。

3） 在动态分析时尽可能使用真实的安卓设备，并在设备中增加用户使用痕迹。这将极大地提高攻击者进行环境感知的难度，有利于安全人员进行有效分析和准确审查^[24]。Google Firebase Test Lab（https://firebase.google.cn/?hl=zh-cn）和Amazon Device Farm（https://aws.amazon.com/device-farm）等服务表明了在真机上进行大规模应用测试的可行性。

5　 结 语

为了全面检测环境感知API，本文设计并实现了自动化工具EAFinder。该工具能够枚举所有的系统API，并在真机和模拟器中进行自动化调用，最终通过比较API在不同环境中的可访问性和返回值的差异，检测出环境感知API。相较于先前工作，EAFinder 扩展了自动化分析API的覆盖范围，检测到的环境感知API数量显著增加，同时提升了分析效率。

实验结果表明，EAFinder在各主流系统版本上均能以较高的准确率检测环境感知API，排除误报后最终获得了323个环境感知API，检测准确率为93.8%。本文将这些API按使用方式划分为独立使用、基于阈值使用和组合使用三类，并进行了抽样测试，结果显示利用这些API可以以97%的准确率有效地区分真实设备和模拟器，验证了EAFinder的有效性。EAFinder能够快速准确地获取环境感知API列表，从而使得分析人员能预先采取防御和对抗措施。未来将进一步利用EAFinder检测出的API，研究如何构造透明的分析环境，对抗恶意软件的逃避行为。

参考文献

[1] HONG Y F， HU Y J， LAI C M， et al. Defining and detecting environment discrimination in Android apps［C］//International Conference on Security and Privacy in Communication Systems. Cham： Springer， 2018： 510-529. DOI： 510-529.10.1007/978-3-319-78813-5_26 .

[2] 周童. 针对环境感知恶意代码的检测技术研究［D］. 武汉： 华中科技大学， 2017.

[3] ZHOU T. Research on detection technology for context-aware malicious［D］. Wuhan： Huazhong University of Science and Technology， 2017. DOI： 10.7666/d.D01308659（Ch ）.

[4] SEAN. Android Pincer［EB/OL］. ［2013-04-05］.

[5] AFIANIAN A， NIKSEFAT S， SADEGHIYAN B， et al. Malware dynamic analysis evasion techniques： A survey［J］. ACM Computing Surveys， 52（6）： 126. DOI： 10.1145/3365001 .

[6] SAMHI J， LI L， BISSYANDÉ T F， et al. Difuzer： Uncovering suspicious hidden sensitive operations in Android apps［C］//2022 IEEE/ACM 44th International Conference on Software Engineering （ICSE）. New York： IEEE Press， 2022： 723-735. DOI： 10.1145/3510003.3510135 .

[7] SUN X Y， CHEN X， LI L， et al. Demystifying hidden sensitive operations in android apps［J］. ACM Transactions on Software Engineering and Methodology， 32（2）： 50. DOI： 10.1145/3574158 .

[8] ZHOU H， WU S H， LUO X P， et al. NCScope： Hardware-assisted analyzer for native code in Android apps［C］//Proceedings of the 31st ACM SIGSOFT International Symposium on Software Testing and Analysis. New York： ACM， 2022： 629-641. DOI： 10.1145/3533767.3534410 .

[9] PETSAS T， VOYATZIS G， ATHANASOPOULOS E， et al. Rage against the virtual machine： Hindering dynamic analysis of Android malware［C］//Proceedings of the Seventh European Workshop on System Security. New York： ACM， 2014： 1-6. DOI： 10.1145/2592791.2592796 .

[10] VIDAS T， CHRISTIN N. Evading android runtime analysis via sandbox detection［C］//Proceedings of the 9th ACM symposium on Information， computer and communications security. New York： ACM， 2014： 447-458. DOI： 10.1145/2590296.2590325 .

[11] GAJRANI J， SARSWAT J， TRIPATHI M， et al. A robust dynamic analysis system preventing SandBox detection by Android malware［C］//Proceedings of the 8th International Conference on Security of Information and Networks. New York： ACM， 2015： 290-295. DOI： 10.1145/2799979.2800004 .

[12] COSTAMAGNA V， ZHENG C， HUANG H Q. Identifying and evading android sandbox through usage-profile based fingerprints［C］//Proceedings of the 1st Workshop on Radical and Experiential Security. New York： ACM， 2018： 17-23. DOI： 10.1145/3203422.3203427 .

[13] KONDRACKI B， AZAD B A， MIRAMIRKHANI N， et al. The droid is in the details： Environment-aware evasion of android sandboxes［C］//Proceedings 2022 Network and Distributed System Security Symposium. Reston： Internet Society， 2022： 1-16. DOI： 10.14722/ndss.2022.23056 .

[14] SONG W N， MING J， JIANG L， et al. Towards transparent and stealthy android OS sandboxing via customizable container-based virtualization［C］//Proceedings of the 2021 ACM SIGSAC Conference on Computer and Communications Security. New York： ACM， 2021： 2858-2874. DOI： 10.1145/3460120.3484544 .

[15] JING Y M， ZHAO Z M， AHN G J， et al. Morpheus： Automatically generating heuristics to detect Android emulators［C］//Proceedings of the 30th Annual Computer Security Applications Conference. New York： ACM， 2014： 216-225. DOI： 10.1145/2664243.2664250 .

[16] KURTZ A， GASCON H， BECKER T， et al. Fingerprinting mobile devices using personalized configurations［J］. Proceedings on Privacy Enhancing Technologies， 2016， 2016（1）： 4-19. DOI： 10.1515/popets-2015-0027 .

[17] WANG C， ZHANG Y， LIN Z Q. One size does not fit all： Uncovering and exploiting cross platform discrepant APIs in WeChat［C］//Proceeding of the 32nd USENIX Security Symposium， Berkeley： USENIX Association， 2023： 6629-6646. DOI: 10.1145/3576915.3616676 .

[18] POSSEMATO A， NISI D， FRATANTONIO Y. Preventing and detecting state inference attacks on android［C］//Proceedings 2021 Network and Distributed System Security Symposium. Reston： Internet Society， 2021：1-18. DOI： 10.14722/ndss.2021.24479 .

[19] ZHANG L， YANG Z M， HE Y Y， et al. Invetter： Locating insecure input validations in Android services［C］//Proceedings of the 2018 ACM SIGSAC Conference on Computer and Communications Security. New York： ACM， 2018： 1165-1178. DOI： 10.1145/3243734.3243843 .

[20] AOSP. Security-enhanced linux in Android［EB/OL］. ［2023-07-24］.

[21] Google for Developers. Factory images for Nexus and Pixel devices［EB/OL］. ［2023-07-10］.

[22] AOSP. Uicc carrier privileges［EB/OL］. ［2022-10-11］.

[23] Developers Android. Set up Android emulator networking［EB/OL］. ［2023-04-12］. DOI: 10.1002/9781119419334.ch11 .

[24] BULAZEL A， YENER B. A survey on automated dynamic malware analysis evasion and counter-evasion： PC， mobile， and web［C］//Proceedings of the 1st Reversing and Offensive-oriented Trends Symposium. New York： ACM， 2017： 1-21. DOI： 10.1145/3150376.3150378 .

[25] ALZAYLAEE M K， YERIMA S Y， SEZER S. EMULATOR vs REAL PHONE： Android malware detection using machine learning［C］//Proceedings of the 3rd ACM on International Workshop on Security and Privacy Analytics. New York： ACM， 2017： 65-72. DOI： 10.1145/3041008.3041010 .

基金资助

国家自然科学基金(62172308)

国家自然科学基金(61972297)

国家自然科学基金(62172144)

国家自然科学基金(U1636107)