SDAC：使用基于语义距离的 API 集群进行 Android 恶意软件检测的慢老化解决方案
摘要
提出了一种名为SDAC的新型缓慢老化解决方案，用于解决
Android恶意软件检测中的模型老化问题，该问题是由于在恶意软件检测过程中未能适应Android规范的变化所致。与现有解决方案中的检测模型定期重新训练不同，SDAC通过评估新API对恶意软件检测的贡献以及现有API的贡献来有效地进化。在SDAC中，通过API调用序列的上下文来评估API的贡献，这些序列是从Android应用程序中提取的。应用神经网络在序列上为API分配向量，其中API向量的差异被视为语义距离。然后，SDAC根据它们的语义距离对所有API进行聚类，以在训练阶段创建特征集，并在检测阶段扩展特征集以包括所有新API。SDAC无需通过任何新的实际标记的应用程序集进行训练，就可以通过简单地识别检测阶段出现的新API来适应Android规范的变化。在2011年至2016年的数据集上进行的广泛实验中，与维持对API变化有弹性的最先进的Android恶意软件检测解决方案MaMaDroid相比，SDAC实现了显著更高的准确率和显著更慢的老化速度。
引言
大多数Android恶意软件检测模型迅速老化。根据Zhu和Dumitras的研究[1]，一个在2012年生成的Android恶意软件检测模型未能检测到Gappusin家族的任何恶意软件，而2014年的模型则能检测到其中的大多数。在百度的Wang的另一项研究中[2]，一个在百度开发的Android恶意软件检测模型的召回率在前六个月下降了7.6%。最近的研究发现，模型老化的主要原因是Android规范中API随时间变化[1]，[3]。显然，利用新添加的API执行恶意行为的恶意软件样本可能会逃避老化模型的检测。解决Android恶意软件检测模型老化的常见方法是更新基于签名的恶意软件检测的签名数据库，或者使用具有真实标签（即恶意软件和良性软件）的新Android应用更新恶意软件检测模型。然而，这个过程通常既耗时又昂贵，可能涉及许多领域专家在样本标记和跨多个组织的数据共享上的努力。此外，新收集的应用的真实标签可能不便于或及时获得，甚至在现实生活中可能会出错。例如，我们分别在2017年7月和2018年7月从VirusTotal1下载了42808个应用的报告。在这些应用中，大约11%（4717/42808）的应用在2017年7月被所有的杀毒引擎标记为“良性”，但在2018年7月至少有一个杀毒引擎将其标记为“危险”，表明标签可能长时间错误。因此，迫切需要开发一种缓慢老化的解决方案，该方案在更长时间内保持恶意软件检测的准确性，并且可以在不依赖新应用的真实标签的情况下更新。
虽然Android API的变化已被确认为导致Android恶意软件检测模型老化的主要问题[1]，[3]，但在缓慢老化解决方案的设计中尚未严格解决对API变化的适应。最近的一个名为PikaDroid的解决方案[4]通过利用恶意软件检测中敏感API的上下文信息解决了老化问题。然而，由于PikaDroid的特征集在其设计中保持不变，它不适应Android规范的变化。另一种方法，MaMaDroid[5]提出了一种对Android规范变化具有弹性的检测方法。特别是，MaMaDroid首先将应用程序编程接口（API）抽象为API执行路径中的相应包（或包家族）。然后，它将所有抽象路径总结为一个马尔可夫模型，并将马尔可夫模型转换为每个应用的特征向量，用于模型训练和测试。通过将API抽象为包，MaMaDroid对现有包中新添加的API具有弹性，并且在Android恶意软件检测中的表现显著优于其他解决方案，如DroidAPIMiner。然而，MaMaDroid没有解决任何新包对恶意软件检测的贡献问题，因为马尔可夫模型中由任何新包引起的转换不会转换为MaMaDroid中的特征。根据Android开发者文档[6]，与前一个API级别相比，平均每个API级别增加了大约340个新API和4个新包。这些新包和新API是导致Android恶意软件检测模型老化的重要因素。如果不更新模型，现有的恶意软件检测模型的性能，包括MaMaDroid，可能会随着越来越多的新包和API被添加到Android规范中并用于Android应用开发而显著下降。在本文中，我们开发了一种基于学习的、缓慢老化的Android恶意软件检测解决方案。我们的缓慢老化解决方案名为SDAC，代表基于语义距离的API聚类。SDAC根据API的上下文确定API对恶意行为的贡献，这指的是在应用执行的API调用序列中，API周围固定大小窗口内的API。特别是，在具有真实标签的应用训练集的基础上，SDAC从应用中提取API调用序列。基于提取的API序列，SDAC应用两层神经网络将API嵌入到API向量中，并将这些向量排列到一个向量空间中。在向量空间中，共享常见API上下文的API彼此靠近。根据API向量聚类形成特征集，其中每个特征定义为所有API的集合，其对应的API向量在同一聚类中。对于训练集中的每个应用，通过从特征集到特征的一对一映射生成二进制特征向量。如果应用没有使用映射特征中的任何API，则应用的特征向量中的元素被赋值为零，否则为一。任何分类模型都可以基于从训练应用及其相应标签派生的特征向量构建。为了使SDAC缓慢老化，识别新API对恶意软件检测的贡献是很重要的，而不需要知道使用这些API的新应用的真实标签。在SDAC中执行此类识别的关键技术是特征扩展。在这一步中，测试集应用中出现的每个新API都被添加到根据API向量空间中测量的距离最接近的特征中。一个新API对恶意软件检测的贡献被建模为等同于同一特征中其他API的贡献。由于所有“旧”API的贡献已在训练阶段评估过，因此在测试阶段不需要重新训练训练过的分类模型。在一系列测试集上随时间进行恶意软件检测时，SDAC可以以两种主要模式执行，SDAC-FEO和SDAC-FMU。SDAC-FEO是“SDAC-Feature Extension Only”的简称，在这种模式下，每次使用新的测试集进行特征扩展，而训练过的分类模型始终保持不变。SDAC-FMU是“SDAC-Feature and Model Updating”的简称，它与新的测试集一起更新分类模型和特征集。尽管在某些情况下分类器会发生变化，但SDAC-FEO和SDAC-FMU都不需要在连续时间段内使用任何标记的新样本，同时仍然可以保持高准确性，因此整个解决方案SDAC被视为缓慢老化。SDAC-FEO和SDAC-FMU都需要当前测试集在特征扩展中完全可用，以收集新API的上下文。为了放宽这一限制，我们为在线检测单个应用设计了SDAC-FEO-OL和SDAC-FMU-OL，而不必等待整个测试集可用。特别是，它们使用现有的分类模型进行单个应用的在线检测，不进行特征扩展，而在整个测试集可用后，它们转向其离线版本进行更新。我们使用2011年至2016年的70142个Android应用样本评估了SDAC在不同模式和版本中的性能。为简单起见，我们将2011年的样本用于训练和5折交叉验证的场景称为我们的“默认设置”，而2012年至2016年的样本用于测试。在默认设置中的评估结果显示，SDAC-FEO的F分数从2011年到2016年平均每年下降4.81%，而MaMaDroid平均每年下降7.67%。SDAC-FEO在这些测试集上的平均F分数为87.23%，高于同一情况下MaMaDroid的59.03%，提高了28.2%。与SDAC-FEO相比，SDAC-FMU进一步将老化速度从平均每年4.81%降低到0.10%，并将平均F分数从87.23%提高到97.09%。虽然在线版本在对每个应用进行在线分类时更有效，但它们的准确性略低，老化速度略高于相应的非在线版本。
基础SDAC
一个Android应用可以被视为一组操作路径，其中每个操作路径是在特定条件下可以在Android平台上执行的一系列操作。在SDAC的设计中，我们关注Android应用通过API调用操作访问Android系统服务和资源的情况。一个Android应用可能使用在其开发时Android规范中提供的任何API。随着时间的推移，Android规范从API级别1发展到API级别27，不断增加了许多新的API。当然，一个Android应用不能使用在其开发时尚不存在的新API。
假设：SDAC使用一组与真实标签（包括恶意软件和良性软件）相关联的Android应用进行训练，训练集中的应用是在同一时间段开发的。训练后，SDAC用于对其他时间段的测试集中的所有应用进行分类。假设在使用SDAC时，测试集中的应用没有可用的真实标签。首先开发基础SDAC来对一个测试集中的应用进行分类，该测试集是在训练集之后的一个时间段内开发的。然后，它在不同的模式和版本中扩展，以对在连续后来的时间段内开发的多个测试集中的应用进行分类。
![[2022.03.SDAC：使用基于语义距离的 API 集群进行 Android 恶意软件检测的慢老化解决方案_image-1.png]]
结构：基础SDAC的结构如图1所示。它包括两个阶段，一个训练阶段，SDAC在此阶段使用训练集进行训练；一个检测阶段，SDAC在此阶段用于在测试集中检测恶意软件。在这两个阶段中，基础SDAC都经历四个步骤，其中前两个步骤，包括API路径提取和API向量嵌入，在两个阶段中都有。最后两个步骤是在训练阶段生成API聚类和训练分类模型，在检测阶段扩展API聚类和测试分类模型。
2.1 API路径提取
SDAC的第一步是从每个应用程序中提取一组API调用路径。可以利用适当的静态分析工具，例如FlowDroid [7]，将每个应用程序从字节码转换为适当的表示形式（例如，Jimple代码），并提取其程序方法之间的有向调用图。从调用图中，SDAC为每个方法提取一个调用图片段，并排除任何是另一个调用图片段的子图的调用图片段。目标方法的调用图片段包括调用图中所有方法及其之间的所有有向链接。在一个调用图片段中，所有方法最多距离目标方法d个链接，在调用图中，指向不使用API的方法的链接不计入片段中。SDAC然后从每个调用图片段中派生所有API调用路径。附录A中展示了API调用路径提取的一个真实世界示例，可以在计算机学会数字图书馆http://doi.ieeecomputersociety.org/10.1109/TDSC.2020.3005088找到。如果d足够大，SDAC将为每个应用输出所有可能的API调用路径，这是一个与程序大小成正比的难以处理的数字[8]。为了使SDAC实用，参数d被选择为相对较小，等于下一小节中提到的窗口大小S。
2.2 API向量嵌入
![[2022.03.SDAC：使用基于语义距离的 API 集群进行 Android 恶意软件检测的慢老化解决方案_image-2.png]]
此步骤的目标是将每个API嵌入到一个n维实值向量中，该向量的范围在[0, 1]之间，根据API在一组应用中的上下文。一组应用中API的上下文被定义为在所有从应用集中提取的API调用路径中，包含该API的固定大小窗口内所有邻近API的集合。具有相似上下文的不同API在向量空间中被映射得很接近。API向量嵌入过程在图2中进行了说明。基于在“API路径提取”步骤中提取的API调用路径，SDAC构建了一个API词汇表，其中包含这些路径中的所有唯一API。对于API词汇表中的每个目标API以及每个提取的API路径，SDAC派生出所有最多距离目标API S个API的邻近API，其中S称为窗口大小。然后，SDAC将每个目标API与其每个邻近API配对，并使用所有这些配对来训练Skip-Gram模型，这是一个具有输入层、隐藏层和输出层的神经网络[9]。在模型中，一个实值输入-隐藏矩阵WV用于将输入向量转换为隐藏输入向量，一个实值隐藏-输出矩阵W’用于进一步将隐藏输入向量转换为输出向量，其中V是API词汇表大小，K是API向量大小。在训练过程中，目标API及其所有配对API被视为Skip-Gram模型的输入和目标输出。对于一个目标API，Skip-Gram模型的输入是一个大小为V的独热编码向量，其中目标API对应的索引指向一，所有其他索引指向零。类似地，对于一个配对API，目标输出是一个大小为V的独热编码向量，其中配对API对应的索引指向一，所有其他索引指向零。对于每个目标API，Skip-Gram模型通过使用输入-隐藏矩阵、隐藏-输出矩阵和softmax函数（即标准化指数函数）依次转换输入向量来计算输出向量。然后，Skip-Gram模型使用反向传播更新这两个矩阵中的元素，这是神经网络监督学习的常见优化步骤，以最小化计算输出和目标输出之间的总误差。在用所有API对训练完Skip-Gram模型后，SDAC为每个API输出一个API向量。在图2中，APIT的向量是输入-隐藏矩阵中的第T行，其中T是APIT在API词汇表中的索引。一个API的向量嵌入了API的上下文，这代表了在目标输出中编码的所有邻近API。如果两个不同的API被嵌入到相似的API向量中，因此它们具有相似的上下文，因为在模型训练中优化计算输出以逼近它们的目标输出。
2.3 API簇生成与扩展
基础SDAC的第三步是在训练阶段进行API簇的生成，在检测阶段进行API簇的扩展。此步骤的目的是根据API之间的语义距离将API词汇表中的API分组成若干簇，其中语义距离定义为API向量空间中的欧几里得距离。此步骤的输出是一组API簇，将用作下一步为每个应用生成特征向量的特征集。
API簇生成
在训练阶段，SDAC应用来自[10]的同大小k均值聚类算法于从训练集计算得出的API向量。该算法将API向量划分为k个簇，每个API向量属于最近均值的簇，所有簇的大小差异最多为一。使用这些簇，通过簇到特征的一对一映射定义了一个初始特征集，每个特征包括所有在同一簇中出现的API的API向量。同一特征中的API由于API向量的接近性，共享相似的上下文，并因此在我们的模型中对恶意软件检测作出类似的贡献。选择同大小k均值算法是因为它可以有效避免偏斜的聚类结果，从而最大化良性应用和恶意应用的特征向量之间的差异。有关我们选择的同大小k均值聚类算法的详细信息，请参阅在线补充材料中的附录B。
API簇扩展
在检测阶段，SDAC输出从上一步的测试集中派生的一组API向量。现在，它扩展初始特征集以包括出现在测试集的API词汇表中但不在训练集的API词汇表中的所有新API。这一步也被称为特征扩展，因为每个簇被视为特征集中的一个特征。通常，如果新APIY与特征X中的API相比，在所有特征中具有最小的平均语义距离，则SDAC将特征X扩展以包括新APIY，其中语义距离通过从测试集派生的API向量来测量。在一个特征中，如果一个API在测试集的任何应用中都不存在，除非该特征中没有API存在于测试集中，在这种情况下，使用从训练集派生的相应API向量进行语义距离计算，否则SDAC将其从平均语义距离计算中排除。在所有新API被包括在特征扩展后，从初始特征集定义了一个扩展特征集。
![[2022.03.SDAC：使用基于语义距离的 API 集群进行 Android 恶意软件检测的慢老化解决方案_image-3.png]]
图3展示了一个特征扩展的玩具示例。在图3中，从训练集生成的向量空间中形成了两个簇，包括包含APIA、APIB和APIC的特征P，以及包含APID、APIE和APIF的特征Q。现在考虑一个在从测试集生成的向量空间中的新API APIY，计算APIY与特征P和特征Q的每个簇的平均语义距离。由于特征Q与APIY的平均距离最小，因此它被扩展以包括APIY进行特征扩展。之后，特征Q将包含四个API：APID、APIE、APIF和APIY，而特征P保持不变。注意，APIB在测试集中没有出现，因此在向量空间中没有代表性的API向量，所以在计算中简单地被排除。生成扩展特征集的目的是使用现有API的贡献来模拟新API对恶意软件检测的贡献，因为由于测试集中缺乏真实标签，后者不能直接通过分类模型测量。
2.4 分类模型训练与测试特征向量生成
给定一个特征集，无论是训练阶段的初始特征集还是检测阶段的扩展特征集，SDAC都会为每个应用生成一个二进制特征向量，通过特征集的一对一映射实现。如果应用没有使用其映射特征中的任何API，则应用的特征向量中的元素为零，否则为一。
分类模型训练
在训练阶段，SDAC为训练集中的每个应用生成一个特征向量，并将特征向量与应用的真实标签关联。然后，SDAC使用所有特征向量和关联的标签训练一个分类模型。
分类模型测试
在检测阶段，SDAC为测试集中的每个应用生成一个特征向量。然后，SDAC使用训练好的分类模型根据其特征向量作为模型输入输出每个应用的预测标签。
2.5 模型投票
在SDAC中，特征集中的一个特征可能包含多个API。有可能一些API被良性应用使用，而另一些则被恶意应用使用。单一特征难以区分良性和恶意应用。因此，利用特征集中的所有特征进行恶意软件检测会更好。为了进一步提高其准确性，SDAC利用多个特征集的区分能力而不是单一特征集。特别是，SDAC在其第三步执行聚类算法m次（m ≥ 1），从而生成m个初始特征集和m个扩展特征集。在训练阶段，每个初始特征集上训练一个分类模型，然后在检测阶段在相应的扩展特征集上进行测试。总共m个分类模型，如果至少t个（t ≤ m）分类模型同意某个标签，则SDAC输出应用的预测标签为“恶意软件”，否则输出为“良性软件”。在我们的实验中，我们发现使用多重投票的SDAC的F分数提高了大约3到10个百分点。关于调整t和m的细节在第4节中解释。
3 SDAC的两种模式和在线版本
虽然基础SDAC只关注处理一个测试集，但它可以通过两种不同的模式扩展，SDAC-FEO和SDAC-FMU，来处理多个测试集T1、T2、…、TN，其中应用是在不同时间段开发的，包含一些新的API。SDAC-FEO和SDAC-FMU之间的区别在于，在检测阶段，SDAC-FEO只进行特征扩展，而SDAC-FMU还进行特征和模型更新。
3.1 SDAC-FEO
在训练阶段，SDAC-FEO接受一个训练集作为输入，并以与基础SDAC相同的方式输出m个初始特征集和m个分类模型。在将其应用于测试集T1时的检测阶段，每个初始特征集被扩展为“T1的扩展特征集”。然后，T1中的每个应用根据m个“T1的扩展特征集”转换为m个特征向量。最后，使用m个分类模型通过模型投票根据其特征向量预测每个应用的标签。当SDAC-FEO应用于测试集TN（N ≥ 2）时，每个“TN-1的扩展特征集”被视为“TN的初始特征集”，然后以与基础SDAC中的“特征扩展”步骤相同的方式扩展为“TN的扩展特征集”。之后，TN中的每个应用根据m个“TN的扩展特征集”转换为m个特征向量。与之前相同的m个分类模型用于根据其特征向量预测每个应用的标签。图4显示了SDAC-FEO的结构，包括一个训练集（2011年的应用）和三个测试集（2012年、2013年和2014年的应用）。在此图中，2011年的应用集用于生成初始特征集和训练分类模型。在应用于2012年和2013年的应用后，使用相同的分类模型对2014年的应用进行分类。2014年应用的扩展特征集是通过三次顺序扩展2011年应用的初始特征集生成的。
![[2022.03.SDAC：使用基于语义距离的 API 集群进行 Android 恶意软件检测的慢老化解决方案_image-4.png]]
3.2 SDAC-FMU
SDAC-FMU在其训练阶段与SDAC-FEO相同，在应用于测试集T1的检测阶段也相同。当它应用于其他测试集T2; …;TN时，它执行额外的特征和模型更新步骤。现在假设SDAC-FMU已经应用于测试集T1; …;TN-1，为这些集合中的每个应用产生了一个预测标签（即伪标签）。当SDAC-FMU应用于测试集TN时，它首先从训练集和T1; …;TN-1的联合中生成m个“TN的初始特征集”（与基础SDAC生成初始特征集的方式相同）。我们称这个过程为特征更新。注意，这与SDAC-FEO不同，SDAC-FEO中的初始特征集从未改变。
然后，SDAC-FMU从头开始为TN训练m个分类模型，使用（i）训练集中带有真实标签的应用，以及（ii）T1; …;TN-1中带有伪标签的应用，其中每个应用根据m个“TN的初始特征集”转换为m个特征向量。我们称这个过程为模型更新。注意，在我们的假设中，测试集中的应用没有真实标签；因此，SDAC-FMU使用T1; …;TN-1中的应用的伪标签进行模型更新。
模型更新后，SDAC-FMU将每个“TN的初始特征集”扩展为“TN的扩展特征集”（与基础SDAC扩展初始特征集的方式相同）。然后，TN中的每个应用根据m个“TN的扩展特征集”转换为m个特征向量。最后，用于TN的经过模型更新训练的分类模型用于根据其特征向量预测TN中每个应用的标签。
![[2022.03.SDAC：使用基于语义距离的 API 集群进行 Android 恶意软件检测的慢老化解决方案_image-5.png]]
图5显示了SDAC-FMU的结构，包括一个训练集（2011年的应用）和三个测试集（2012年、2013年和2014年的应用）。当SDAC-FMU在用2011年的应用训练并应用于2012年和2013年的应用后，应用于2014年的应用时，它首先从2011年、2012年和2013年的应用的联合中为2014年的应用生成初始特征集。然后，SDAC-FMU为联合中的每个应用生成特征向量，并使用（i）带有真实标签的2011年应用，以及（ii）带有伪标签的2012年和2013年应用，为2014年的应用训练分类模型，其中每个应用根据其特征向量进行模型训练。最后，SDAC-FMU扩展2014年应用的初始特征集，根据扩展的特征集将每个2014年的应用转换为特征向量，并使用2014年应用的分类模型根据其特征向量对每个2014年的应用进行分类。
3.3 在线版本
SDAC-FEO和SDAC-FMU都要求当前的测试集TN在执行特征扩展之前可用，然后才能应用于对该测试集中的每个应用进行分类。为了克服这一限制，我们开发了它们的在线版本，SDAC-FEO-OL和SDAC-FMU-OL，在这些版本中跳过了特征扩展步骤，可以在不等待整个测试集可用的情况下及时对单个应用进行分类。
SDAC-FEO-OL
SDAC-FEO-OL在训练阶段与SDAC-FEO相同，生成m个初始特征集和m个分类模型。当SDAC-FEO-OL用于对T1中的每个应用进行分类时，它根据m个初始特征集将应用转换为m个特征向量。然后，它使用已经训练好的m个分类模型根据其特征向量输出每个应用的预测标签。在T1中的所有应用被分类后，SDAC-FEO-OL以与SDAC-FEO相同的方式为T1生成m个扩展特征集。
当SDAC-FEO-OL用于对TN中的每个应用进行分类时（N ≥ 2），它根据TN-1的m个扩展特征集将应用转换为m个特征向量。然后，它使用相同的已经训练好的分类模型通过其特征向量为TN中的每个应用输出预测标签。
在TN中的所有应用被处理后，SDAC-FEO-OL转而使用SDAC-FEO再次处理TN，生成TN的m个扩展特征集。这是为了为下一个时间段检测应用做准备。
SDAC-FMU-OL
SDAC-FMU-OL在训练阶段与SDAC-FMU相同，为T1生成m个初始特征集和T1的m个分类模型。当SDAC-FMU-OL应用于根据T1的m个初始特征集使用T1的m个分类模型对T1中的每个应用进行分类时，与SDAC-FEO-OL相同。
在T1中的所有应用被处理后，SDAC-FMU-OL转而使用SDAC-FMU再次处理T1，生成T2的m个初始特征集和T2的m个分类模型。
当SDAC-FMU-OL应用于测试集TN时（N ≥ 2），它根据TN的m个初始特征集将每个应用转换为m个特征向量。然后，它使用TN的m个分类模型根据其特征向量为TN中的每个应用预测标签。在TN中的所有应用被处理后，SDAC-FMU-OL以与SDAC-FMU相同的方式执行特征和模型更新。
注释
当在线检测单个应用时，首先根据它使用的API集将应用转换为m个特征向量，然后由m个分类模型进行分类。SDAC的前三个步骤（API路径提取、API向量嵌入和API簇生成与扩展）在此过程中不执行，这使得在线版本比离线版本快得多。
SDAC-FEO-OL和SDAC-FMU-OL与在线机器学习在恶意软件检测中的直接应用不同[11]，因为我们的在线版本不需要使用真实标签进行模型更新，而在线机器学习则需要[12]。
![[2022.03.SDAC：使用基于语义距离的 API 集群进行 Android 恶意软件检测的慢老化解决方案_image-6.png]]
4 评估 SDAC 数据集
SDAC 通过一个包含约 36k 个良性软件样本和 35k 个恶意软件样本的数据集进行评估，这些样本是从一个开放的 Android 应用程序集合项目中随机选择的 [13]。表1 展示了我们的数据集概览，该数据集包含从 2011 年到 2016 年六年间开发的良性软件样本和恶意软件样本。每个应用的时间定义为其 APK 文件打包的时间，这可以在其 APK 中的 .dex 文件里找到 [14]。我们的数据集中样本的标签是根据我们在 2018 年 7 月获取的 VirusTotal [15] 的报告来决定的。基于这些报告，我们将结果为零的应用标记为“良性”，将报告中包含超过阈值 Tmal 的正面结果的应用标记为“恶意”。
在恶意软件检测的文献中，用于标记“恶意”应用的 Tmal 值有不同的设定。根据 Roy 等人的研究，从 VirusTotal 只收到一个正面报告的恶意软件样本被认为是“低质量”，而从 54 个扫描器中收到超过十个正面结果的被认为是“高质量” [3]。Arp 等人则标记任何从一组选定的扫描器中收到至少 20% 正面结果的应用为恶意 [16]。Alex 等人进行了一个大规模研究，汇总了 Virustotal 的扫描器结果，并认为如果来自 34 个不同扫描器中的 4 个或更多的正面扫描结果，则可以信任恶意标签 [17]。在我们的实验中，我们在分别用 Tmal = 4、9 和 15 标记的三个不同数据集上评估 SDAC，这些数据集来自 Virustotal2 的总共 63 个扫描器。我们在默认情况下设置 Tmal = 15，并在第 4.5 节展示了 Tmal = 4 和 Tmal = 9 的结果。表1 显示了标记为 Tmal = 15 的数据集中不同年份的独特新 API 数量和所有 API 的数量。如果一个 API 在我们数据集中之前开发的应用中未被使用，则该年被认为是新的。
工具和参数选择
我们选择以下工具和参数来评估 SDAC。在 API 路径提取步骤中，我们选择 FlowDroid 来从每个应用中提取程序类之间的有向调用图 [7]。用于 API 路径提取的参数 d 被设置为与 API 向量嵌入的窗口大小相同。在 API 向量嵌入步骤中，我们依赖 gensim 工具包 [18] 来实现 Skip-Gram 模型，并从一组应用中派生 API 向量，其中我们选择窗口大小 S = 5 和 API 向量大小 K = 200（即 API 向量空间的维度）。在 API 簇生成和扩展步骤中，我们选择来自开源数据挖掘框架 ELKI [10] 的同大小 k-means 簇算法，并设置簇的数量 k = 1000。在分类模型训练和测试步骤中，我们选择线性 SVM 模型作为我们的分类模型，并设置分类模型的数量 m = 9，以及模型投票中的阈值 t = 3。我们调整这些参数，以及其他参数（例如，API 向量嵌入的迭代次数和学习率），以在使用相同训练集（2011 年的应用）的交叉验证中产生最佳结果，同时受到我们计算资源（一台具有 3.3 GHz CPU 和 12GB 内存的桌面计算机）的限制。这些参数在各种测试集上评估 SDAC 的所有实验中使用。
参数选择：k、m 和 t
参数 k（如在 k-means 聚类算法中）、m（即 SDAC 使用的分类模型数量）和 t（即模型投票中使用的阈值）被调整以在训练集上的交叉验证中获得 SDAC 的最佳性能，这个训练集在我们的实验中是 2011 年的数据集。
![[2022.03.SDAC：使用基于语义距离的 API 集群进行 Android 恶意软件检测的慢老化解决方案_image-8.png]]
图6 显示了 SDAC 在不同 k 值的交叉验证中的性能。SDAC 的 F 分数从 k = 50 快速增加到 k = 500，并在 k = 1000 之后保持稳定。由于更高的 k 值会增加模型训练和测试的时间，我们在实验中选择 k = 1000。
![[2022.03.SDAC：使用基于语义距离的 API 集群进行 Android 恶意软件检测的慢老化解决方案_image-7.png]]
图7 显示了如何决定分类模型的数量 m 和阈值 t。在交叉验证实验中，当 m>7 且 t=m 约为 30 到 40 百分比时，SDAC 达到了最高的 F 分数（超过 97%）。由于 SDAC 的开销与 m 成正比，我们选择 m = 9 和 t = 3，这在最小的 m 下达到了最高的 F 分数。
4.1 SDAC-FEO的评估
进行了三组实验来评估 SDAC-FEO。第一组实验是为了评估 SDAC-FEO 在使用同一时间段开发的样本集进行交叉验证时的准确性。第二组实验是为了评估 SDAC-FEO 在一个时间段的样本集上训练，并在后来时间段开发的其他样本集上测试时的老化速度。第三组实验是为了比较 SDAC-FEO 与 MaMaDroid [5] 的准确性和老化速度。
恶意软件检测模型的准确性可以通过在恶意软件和良性软件集上的 F 分数来衡量。F 分数是精确度和召回率的调和平均值，其中精确度为 Precision = ∣ T P ∣ ∣ T P ∣ + ∣ F P ∣ \text{Precision} = \frac{|TP|}{|TP| + |FP|} Precision=∣TP∣+∣FP∣∣TP∣，召回率为 Recall = ∣ T P ∣ ∣ T P ∣ + ∣ F N ∣ \text{Recall} = \frac{|TP|}{|TP| + |FN|} Recall=∣TP∣+∣FN∣∣TP∣。我们使用 TP（即真正例）表示正确检测为恶意软件的恶意软件集，FP（即假正例）表示错误检测为恶意软件的良性软件集，FN（即假负例）表示错误检测为良性软件的恶意软件集，TN（即真负例）表示正确检测为良性软件的良性软件集。
SDAC-FEO 首先在使用同一时间段开发的样本进行 5 折交叉验证中评估其准确性。表2 显示了 SDAC-FEO 在不同应用集上的精确度、召回率和 F 分数，这些应用集由应用开发的时间段表示。SDAC-FEO 的平均 F 分数为 98.25%，这为随时间评估 SDAC-FEO 提供了一个良好的起点。
SDAC-FEO 随时间的性能
SDAC-FEO 的老化属性通过一系列实验评估，在这些实验中，SDAC-FEO 在一个时间段的样本集上训练，并在后来时间段开发的其他样本集上测试。图9 显示了 SDAC-FEO 随时间检测的 F 分数。当 SDAC-FEO 在比训练集新一年的测试集上评估时，其平均 F 分数为 97.49%，比其在交叉验证中的平均 F 分数（98.52%）下降了 1.03%。当 SDAC-FEO 在比训练集新两年、三年、四年和五年的测试集上评估时，其 F 分数分别下降到 95.02%、88.48%、78.22% 和 73.72%。SDAC-FEO 在这些实验中的平均老化速度为每年 F 分数下降 4.96%。
API 簇扩展分析
API 簇扩展是 SDAC 中的一个关键步骤。在此步骤中，初始特征集通过添加新的 API 来创建扩展特征集。这使 SDAC 能够评估新 API 对于使用已训练的分类模型（这些模型是用没有使用新 API 的标记应用集训练的）的恶意软件检测的贡献。在附录 C 中描述了将新 API 添加到现有 API 簇的几个案例研究，这些材料可在在线补充材料中找到。
为了进一步了解 API 簇扩展如何有助于减缓 SDAC-FEO 的老化，在本节中，我们计算了测试集应用的特征向量在有无特征扩展的情况下的变化，并提取每个特征在线性 SVM 模型中的权重，以了解这种变化将如何影响检测结果。
具体来说，在 SDAC-FEO 使用的 SVM 模型中，应用的特征向量与线性 SVM 模型的权重向量之间的内积是 SVM 模型中应用的特征向量的输出分数 [16]，这代表了 SVM 模型对将应用分类为恶意软件（如果输出分数为正）或良性软件（如果输出分数为负）的信心。SVM 模型的信心与输出分数的绝对值成正比。
对于测试集中的每个应用，我们根据初始特征集和扩展特征集分别为每个 SVM 模型转换两个特征向量。应用的输出分数差异定义为从扩展特征集派生的特征向量的输出分数减去从初始特征集派生的特征向量的输出分数。应用在 SVM 模型中的输出分数差异代表了由于 API 簇扩展引起的对应用的信心变化。正（或负）的输出分数差异意味着在将应用分类为恶意软件（或良性软件）时更有信心。
然后，我们检查测试集中所有恶意软件样本的平均输出分数差异，以及 SDAC-FEO 使用的所有分类模型的平均输出分数差异。我们还检查同一测试集中所有良性软件样本的平均输出分数差异。每个实验中（包括一个训练集和一个测试集）API 簇扩展的可区分性定义为所有恶意软件样本的平均输出分数差异减去所有良性软件样本的平均输出分数差异。如果 API 簇扩展的可区分性为正，则 API 簇扩展对恶意软件检测做出了积极贡献，从而有助于减缓 SDAC-FEO 的老化。
图8 显示了我们实验中 API 簇扩展带来的可区分性。API 簇扩展对恶意软件检测的贡献在我们的所有实验中都是积极的，这表明特征扩展确实将有助于提高 SDAC 的准确性。
4.2 SDAC-FMU的评估：比SDAC-FEO和MaMaDroid老化更慢
与 SDAC-FEO 相比，SDAC-FMU 采取了额外的特征更新和模型更新步骤以获得更好的性能。图10 显示其性能显著且持续优于 SDAC-FEO。在所有实验中，SDAC-FMU（97.39%）的平均 F 分数比 SDAC-FEO（92.89%）高出 4.50%。在老化速度方面，SDAC-FMU 的 F 分数平均每年下降 0.25%，而 SDAC-FEO 在同样情况下下降 4.96%。
由于 SDAC-FMU 使用伪标签更新其分类模型，我们也使用伪标签更新 MaMaDroid 分类模型以进行公平比较。图10 还显示，使用伪标签更新后的 MaMaDroid 性能几乎与之前相同。一个可能的原因是 MaMaDroid 在生成这些伪标签时忽略了新包的 API，更新过程因此加剧了由于忽略这些新 API 而在 MaMaDroid 模型中造成的错误。
假阳性分析
我们检查了 SDAC-FMU 在 2011 年数据集上训练并在 2012 至 2016 年的五个测试集上评估时的误分类结果。为了理解为什么会发生假阳性误分类，我们计算了一个 API 的权重，方法是在 SDAC-FMU 应用于每个测试集时，平均所有 SVM 模型中包含此 API 的特征的权重。API 的权重可以用来衡量其对 SDAC-FMU 在分类应用时的信心贡献。我们为每个测试集按照它们的权重对所有 API 进行排序。我们选择每个排序列表中贡献最大的前 p 和后 p 的 API，分别是在将应用分类为恶意软件和良性软件时对 SDAC-FMU 信心贡献最大的 API。
对于一组应用，我们定义一个 API 的比例为该集合中使用此 API 的应用的百分比。我们进一步定义 top-p 比例（分别为 bottom-p 比例）为 top p API（分别为 bottom p API）的 API 比例的平均值。一组应用的 top-p 比例减去 bottom-p 比例意味着 SDAC-FMU 将该集合分类为恶意软件的信心。
图11 显示了真阳性（TP）、假阳性（FP）、假阴性（FN）和真阴性（TN）的典型 top-p 比例减去 bottom-p 比例值，其中 p = 1%。与 TN 相比，SDAC 在将 FP 分类为恶意软件时更有信心，而在将 TP 分类为恶意软件时信心最强。
在权重最高的 API 列表中，我们发现了一些如 getConfiguration() 和 getDeviceId() 等在之前研究中被认为是“危险”的 API [5]，[16]。使用这些 API 的良性应用更有可能被 SDAC 错误地检测为恶意软件。例如，40%（126/315）的假阳性和超过一半的真阳性（3310/5890）使用了 API getConfiguration()，而只有 23%（1289/5555）的真阴性使用了它。另一个例子，66%（208/315）的假阳性和 96%（5633/5890）的真阳性包含了 TelephonyManager 类中的 API getDeviceId()，而只有 22%（1245/5555）的真阴性使用了它。关于 1% 权重最高的 API 对假阳性结果的贡献，请参阅在线补充材料中的附录 E。
假阴性分析
我们还检查了 SDAC-FMU 在 2011 年数据集上训练并在 2012 至 2016 年的五个测试集上评估时的假阴性。在所有测试集生成的 1076 个假阴性样本中，约 69%（638/931）被至少一个 VirusTotal 扫描器分类为“阳性：广告软件”。根据 TrendMicro [22] 的说法，广告软件可能来自于使用第三方广告库重新打包的良性应用；SDAC-FMU 很难将它们与真正的良性应用区分开来。
此外，约 8.5%（79/931）的假阴性样本被分类为“阳性：风险软件”，约 17.4%（162/931）被分类为“阳性：非病毒”至少由一个 VirusTotal 扫描器。根据卡巴斯基实验室 [23] 的解释，风险软件指的是容易被恶意攻击者利用的合法程序，非病毒与广告软件和风险软件有关。
图11 还显示，与 TP 相比，SDAC 在将 FN 分类为良性软件时更有信心，而在将 TN 分类为良性软件时信心最强。
4.3 SDAC-FEO-OL 和 SDAC-FMU-OL 的评估
SDAC-FEO-OL 和 SDAC-FMU-OL 的性能在默认情况下进行评估，即使用最小的训练集（2011年的应用）和最长的测试集时间跨度（2012-2016年）进行实验。图12 显示 SDAC-FMU-OL 的表现与 SDAC-FMU 非常接近，而 SDAC-FEO-OL 与 SDAC-FEO 之间的性能差距更为明显。与 SDAC-FMU 相比，SDAC-FMU-OL 的 F 分数平均下降了 0.41%，最小下降为 -0.29%（2014年测试集），最大下降为 0.85%（2012年测试集）。与 SDAC-FEO 相比，SDAC-FEO-OL 的 F 分数平均下降了 3.45%，最小下降为 -0.30%（2013年测试集），最大下降为 7.97%（2014年测试集）。尽管如此，SDAC-FMU-OL 和 SDAC-FEO-OL 的表现仍显著优于 MaMaDroid。
4.4 运行时性能
SDAC 的运行时性能在一台装有 Intel® i5-4590 3.3 GHz CPU 和 12 GB 物理内存的桌面电脑上进行评估，操作系统为 Ubuntu 14.04 (LTS)。表3 显示了 SDAC 在所有四个步骤中的运行时性能：(i) API 路径提取，(ii) API 向量嵌入，(iii) API 簇生成和扩展，以及 (iv) 分类模型训练和测试。
SDAC-FEO-OL 和 SDAC-FMU-OL 在检测阶段的运行时间
SDAC-FEO-OL 可以在线检测单个应用，无需等待整个测试集可用。在线检测一个应用的平均时间成本为 0.20 秒。一旦整个测试集可用，SDAC-FEO-OL 将以与 SDAC-FEO 相同的方式扩展其特征集。这一额外的时间成本与 SDAC-FEO 在其检测阶段相似。
SDAC-FMU-OL 检测一个应用在线的时间成本与 SDAC-FEO-OL 相同。一旦整个测试集可用，SDAC-FMU-OL 将以与 SDAC-FMU 相同的方式进行特征和模型更新，因此额外的时间成本也与 SDAC-FMU 相同。
MaMaDroid 的运行时间
MaMaDroid 在训练阶段和检测阶段都进行了三个主要步骤：(i) 利用 FlowDroid 从一个应用中提取一组 API 路径，(ii) 从一组 API 路径形成一个马尔可夫模型，然后用它来组成一个特征向量，以及 (iii) 从（在训练阶段）或应用到（在检测阶段）一组应用的分类模型进行训练。在我们的实现中，MaMaDroid 的训练阶段在第一步平均花费 37.29 秒，在第二步平均花费 0.41 秒，在第三步处理 11,033 个应用（分别为 58,360 个应用）的时间为 16.3 秒（分别为 785.29 秒）。在其检测阶段，MaMaDroid 在第三步平均花费 0.0036 秒来分类单个应用，而前两步所需时间与训练阶段相同。
运行时性能比较
在训练阶段，SDAC 的时间花费（平均每个应用 54.17 秒）比 MaMaDroid（平均每个应用 37.70 秒）更长，用于将反编译代码转换为特征向量。在下一步分类模型训练中，即 SDAC-FEO 的模型训练或 SDAC-FMU 的模型更新，时间成本从包含 11,033 个应用的最小训练集的 9.77 秒到包含 58,033 个应用的最大训练集的约 0.47 小时不等，用于训练每个分类模型。由于 SDAC 使用了 9 个分类模型，因此这一步骤的总时间成本从 87.93 秒到约 4.2 小时不等。相比之下，MaMaDroid 在模型训练步骤中在不同训练集上花费 16.3 秒到约 13.1 分钟不等。在检测阶段，SDAC 检测每个应用的平均时间为 8.90e-4 秒，MaMaDroid 为 3.6e-3 秒。
尽管 SDAC 的训练时间比 MaMaDroid 长，但如第 4.1 至 4.3 节所示，它实现了更高的准确性和更慢的老化速度。尽管实验是在普通桌面电脑上进行的（即 i5-4590@3.3GHz CPU 和 12GB 内存），SDAC 的运行时性能在所有实验中都是可接受的。
注释
对于 SDAC-FMU 和 SDAC-FMU-OL，特征和模型更新的时间成本随着其输入数据的大小增加而增加，输入数据是其训练集和所有过去测试集的并集。随着时间的推移，处理和累积更多测试集后，输入数据的大小持续增加。为了解决这个问题，我们建议对输入数据应用一个验证窗口，该窗口覆盖从最后一个所有应用的真实标签可用的测试集开始的所有过去测试集。这个验证窗口的大小是有限的，因此特征和模型更新的时间成本也是有限的。
形成测试集的时间粒度主要由每个时间粒度内收集的应用数量决定，每个测试集应足够大，以便从中提取准确的 API 上下文信息。我们建议根据我们对 SDAC 的经验，选择每个测试集的大小超过 5500 个应用。
4.5 使用不同 T m a l T_{mal} Tmal 评估 SDAC
SDAC-FEO 和 SDAC-FMU 的性能也在使用不同正面阈值 T m a l = 4 T_{mal} = 4 Tmal=4 和 T m a l = 9 T_{mal} = 9 Tmal=9 的数据集上进行了评估，这些数据集的标签来自 VirusTotal 报告。我们还在这些数据集上运行 MaMaDroid 以进行性能比较。
图13 显示了当 T m a l = 4 T_{mal} = 4 Tmal=4 和 T m a l = 9 T_{mal} = 9 Tmal=9 时，SDAC 的 F 测量值。在两种情况下，2011 年的应用集被用作训练集，2012至2016年的数据集被用作测试集。在 T m a l = 4 T_{mal} = 4 Tmal=4 的情况下，SDAC-FEO 的 F 分数下降了 4.89%，SDAC-FMU 下降了 0.40% 每年，而 MaMaDroid 平均每年下降 6.12%。SDAC-FEO 和 SDAC-FMU 分别在 F 分数上平均比 MaMaDroid 高出 14.85% 和 22.55%。当 T m a l = 9 T_{mal} = 9 Tmal=9 时，F 分数的平均老化速度为 SDAC-FEO 3.94%，SDAC-FMU 0.44%，MaMaDroid 5.95%。SDAC-FEO 和 SDAC-FMU 分别在 F 分数上平均比 MaMaDroid 高出 19.22% 和 25.22%。
4.6 使用不平衡数据集评估 SDAC
在我们的平衡数据集上，SDAC 显著优于 MaMaDroid。然而，根据最近的一个研究项目，平衡数据集可能导致恶意软件检测的结果偏差，因为在实际环境中，恶意软件通常是少数类（与良性软件相比）。据报道，在现实世界设置中，恶意软件的比例约为 10% [24]。为了估计 SDAC 在这种情况下的表现，我们将恶意软件下采样，使其比例为所有应用的 10%，并在我们的评估中形成新的数据集。图14 显示了 SDAC 在这些数据集上的表现，展示了 SDAC 和 MaMaDroid 之间更大的差异，以及与我们之前评估显示的类似趋势。
5 讨论
5.1 SDAC 对抗混淆
代码混淆工具，如 DroidChameleon [25] 或 [26]，经常被用来混淆恶意应用以避免检测。由于 SDAC 基于 Android API 进行检测，混淆方法主要可以分为三类，根据它们对应用中使用的 API 的影响：类别 I：应用使用的 API 集在混淆中没有改变（例如，加密本地漏洞或有效载荷，重命名标识符或包），类别 II：应用使用的 API 集在混淆中扩大以包括新的 API（例如，重新打包或插入垃圾代码），类别 III：应用使用的 API 集在混淆中减少（例如，隐藏方法调用或反射 [27], [28]）。
SDAC 对类别 I 混淆方法自然具有鲁棒性，因为它仅基于应用使用的 API 集来检测应用。类别 II 混淆方法，如“插入垃圾代码”和“将恶意软件重新打包为良性软件”，可能会扩大应用使用的 API 集，从而避免被 SDAC 检测。为了测试 SDAC 对类别 II 方法的鲁棒性，我们为每个测试集生成了 10,000 个 API 集的集合。该集合中的每个 API 集是从测试集中随机选择的一个良性样本和一个真阳性恶意软件样本的 API 集的并集。然后将 SDAC 应用于这些虚拟的恶意应用，以检查其在不同测试集上的召回率。表4 显示，SDAC 在所有模式下的召回率在前两年高于 65%，表明它们仍然可以检测到大多数这种情况下的混淆恶意软件。
类别 III 混淆方法主要通过在运行时加载某些恶意代码来实现，这在静态分析中是不可见的。通常，没有静态分析能对抗类别 III 混淆方法的鲁棒。尽管如此，SDAC 可能在动态分析中应用，因为在动态分析中捕获的 API 调用序列可以直接用作 SDAC 中 API 嵌入步骤的输入。未来测试 SDAC 在动态分析中对抗类别 III 混淆方法的鲁棒性仍然是一个有趣的课题。通过应用打包进行混淆。打包技术也是一种有效的应用混淆方法，用于隐藏它们的代码。各种打包技术被恶意软件开发者广泛采用，如 [29] 所报道。这些机制保护打包的恶意软件免受反向分析，从而阻碍路径提取和特征向量生成 in SDAC。然而，将 SDAC 与动态分析工具或 Android 解包器 [29], [30], [31] 结合使用仍有可能对抗打包的恶意软件。
5.2 API 语义提取
除了 SDAC 从中提取 API 语义的顺序 API 外，数据依赖是分析 API 关系并提取其语义的另一种方式。这种方法已在之前的研究中使用，如 DarkHazard [32]。SDAC 目前专注于基于顺序 API 分析的恶意软件检测，这与数据依赖分析是互补的。一些 API 可能彼此之间有直接的数据依赖关系，但没有任何顺序关系。另一方面，数据依赖分析可能会错过恶意软件检测中的一些 API 关系。例如，在 Wang 等人在 [33] 中提出的 Android 恶意软件检测解决方案中，发现数据依赖信息在自定义方法中丢失，因此可能导致恶意行为未被检测。而在 SDAC 中，这些自定义方法与其调用方法和被调用方法一起收集，然后用于生成 API 序列。将 SDAC 扩展到在语义提取中涵盖数据依赖关系将是未来工作中的一个有趣课题。
5.3 限制
在我们的实验中，我们在 SDAC 的第一步中使用 FlowDroid 从 Android 应用中提取 API 路径。我们观察到，在我们最初收集的所有应用中，有 2.89%（1053/36490）的良性样本和 1.74%（610/35106）的恶意样本未能被 FlowDroid 处理，这些样本在我们的实验中被排除。一些失败是由于在提取过程中超出了内存限制（即在我们的实验中，使用 Soot 工具进行 API 路径提取的内存限制为 4 GB）。为了解决这个问题，可以使用具有更大内存的更强大的计算机，或依赖于其他静态分析工具如 Amandroid [34] 和 Androguard [35] 来提取 API 路径。我们实验的另一个限制是 FlowDroid 不涵盖 HTML5 代码、本地代码或在运行时加载的代码。将 SDAC 扩展以通过执行动态分析来覆盖此类代码是未来的一个方向。
6 相关工作
Android 框架的演变
Android 应用依赖 Android API 来执行其功能，随着时间的推移，许多 API 被添加或弃用。API 演变对应用可用性的影响最近已被研究。例如，McDonnell、Ray 和 Kim 调查了 Android 应用开发者如何随时间跟随并采纳 Android API 变化 [36]。Linares-Vásquez 等人研究了 API 变化与故障倾向之间的关系，并评估其对 Android 应用成功的威胁 [37]。Brito 等人研究了 API 弃用消息的采纳及其对软件演化的影响 [38]。最近，Wu 等人关注在 Android 应用中声明的 Android API 框架版本与实际使用的版本之间的不一致 [39]。虽然此领域的大多数先前研究都集中在应用的可用性上，但尚未对 Android 框架演变对恶意软件检测的影响进行严格研究。
Android 恶意软件检测
Android 恶意软件检测可以分为静态分析和动态分析（例如，[40]，[41]，[42]，[43]，[44]，[45]）。SDAC 属于静态分析，尽管其方法未来可以扩展到动态分析。静态分析根据从应用 APK 文件中提取的信息来检测 Android 恶意软件。它可以进一步分为基于签名的解决方案（例如，[46]，[47]，[48]）和基于学习的解决方案。我们简要总结了一些与 SDAC 更密切相关的基于学习的解决方案。例如，Arp 等人设计了 Drebin 来从清单文件和反汇编代码中提取八类特征（例如，网络地址、组件名称、权限和 API 调用）。Avdiienko 等人检查了恶意软件和良性软件之间敏感数据流的差异 [49]。Yang 等人设计了 DroidMiner 来从 API 和框架资源中提取恶意行为模式 [50]。在另一项工作中，Ke、Li 和 Deng 设计了 ICCDetector 来从应用组件中提取组件间通信特征 [51]。此外，由 Aafer、Du 和 Yin 提出的 DroidAPIMiner 提取了一组包括关键 API 调用频率、框架类和 API 参数的 API 级特征 [52]。Zhang 等人提出的 DroidSIFT 从应用中提取基于敏感 API 的加权上下文 API 依赖图 [53]。Chakradeo 等人提出的 MAST 检查了应用功能声明指标（例如，权限、意图过滤器和本地代码的存在）之间的强关系 [54]。许多其他类型的特征也用于基于学习的解决方案（例如，[55]，[56]，[57]，[58]，[59]，[60]）。大多数基于学习的解决方案中特征集的一个共同特点是它们是“静态”的，没有跟上 Android 框架的演变。因此，这些解决方案的准确性可能会随时间显著下降（即模型老化），这在最近的工业界（例如，[2]）和学术界（例如，[1]，[3]）中都有观察到。虽然 MaMaDroid 能够抵抗在 Android 规范中向现有包添加新 API 的问题 [5]，但在此之前，模型老化问题基本上未解决，因为 Android 框架中不断添加许多新包。
7 结论
在本文中，我们设计了一个名为 SDAC 的新型减缓老化解决方案，用于 Android 恶意软件检测。实现 SDAC 减缓老化的关键驱动因素包括：(i) 基于 API 之间的语义距离对 API 进行聚类，(ii) 使用现有 API 的基础上评估新 API 对恶意软件检测的贡献，以及 (iii) 基于具有真实标签的训练数据和具有伪标签的测试数据更新 API 簇和分类模型。SDAC 的最佳版本在我们的实验中实现了高准确性，平均 F 分数为 97.49%，并且老化速度慢，平均 F 分数每年下降 0.11%。其他版本对计算资源的要求较低。
标签：SDAC,检测,恶意软件,API,应用,FEO,模型 From： https://blog.csdn.net/qq_25177949/article/details/144606533