Page 320 - 《软件学报》2024年第6期

2896 软件学报 2024 年第 35 卷第 6 期

negative ratio, FNR) 等 4 个指标来评估第三方库检测方法性能, 度量方法分别如公式 (14)–公式 (17) 所示:
number_of_true_positives
recall = (14)
number_of_pairs_in_the_ground_truth
number_o f_true_positives
precision = (15)
number_of_detected_pairs
number_o f_detected_pairs−number_o f_true_positives
FPR = (16)
number_of_detected_pairs
number_of_pairs_in_ground_truth−number_of_true_positives
FNR = (17)
number_of_pairs_in_ground_truth
其中, true_positives 指正确识别的 < apk,lrp > 对的个数, detected_pairs 指检测方法识别的所有的 < apk,lrp > 对的
个数; pairs_in_the_ground_truth 指基准中 < apk,lrp > 对的个数 . 此外, 实验中采用运行时间来度量检测方法及其
关键组件的效率.
3.4 结果与分析
3.4.1 主模块识别性能和效率分析
本节对 LibPass 的主模块识别组件进行评价, 先评估主模块识别的性能和效率, 而后评估主模块识别组件对
于 LibPass 解决方案的贡献.
首先, 评估主模块识别的性能和效率. 鉴于在 3 个基准数据集中仅 GTB-2 支持对主模块识别性能进行评估,
实验中以 GTB-2 作为实验对象, 通过人工分析项目的依赖文件的方式得到了每个项目包含的模块以及主模块, 共
计有 16 387 个模块, 其中 1 000 个为主模块. 随机选取 30% 的项目为其配置 ProGuard 作为混淆器, 采用默认配置
确保对标识符进行混淆, 得到上述项目对应的 APK 文件. 将本文提出的主模块识别方法应用于这些 APK, 实验重
复 10 次, 实验结果取平均值, 如表 5 所示. 从表中可以看出: 1) 模块解析的准确率 98.91%, 存在约 1% 的误检, 对
于误检的模块进行人工分析发现, 误检主要原因是代码复用, 即开发者会将其他 TPL 整合到自己开发的 TPL 中.
2) 模块解析方法是抗标识符混淆的, 在 30% APK 混淆情形下, 模块解析和主模块识别的准确率高达 99.2%. 3) 仅
的主模块, 仅通
考虑元信息的情形下, 主模块识别方法准确率为 1 000
70%, 但表明该方法准确识别了所有非混淆
APK
过分析 Android manifest 文件即可实现兼具高效性, 平均运行时间为 17.7 ms. 4) 仅考虑依赖关系的情形下, 主模块
识别识别方法准确率为 98.7%, 显著高于基于元信息的方法, 但该方法所需的时间开销是基于元信息的方法的约
49 倍. 5) 融合了元信息和依赖关系的主模块识别方法的准确率较纯粹基于依赖关系的方法有提升, 总的时间开销
降低了 29.2%. 上述实验结果表明, 本文提出的融合元信息和依赖关系的识别方法具有较高的主模块识别准确率,
并能降低时间开销.

表 5 模块解析和主模块识别实验结果

类型 方法 模块数目 正确的模块数 准确率 (%) 平均时间 (ms)
模块解析 PDG 16 387 16 209 98.91 865.6
元信息识别 1 000 700 70.00 17.7
主模块识别 依赖关系识别 987 98.70 866.8
两种方法结合 1 000 992 99.20 613.6

其次, 评估主模块识别组件对于 LibPass 解决方案的贡献. 实验中考虑了是否在 LibPass 中集成主模块识别组
件, 实验结果如表 6 所示. 可以看出 recall 和 FPR 在是否启用主模块识别功能两种情形下没有变化, 而平均检测
时间有较大变化. 具体地, 应用主模块识别组件后平均检测时间从 23.68 s 减少到 15.47 s, 节省 28.4% 的检测时间,
这表明主模块识别组件的引入对效率提升有积极影响, 但对性能没有影响. LibPass 检测过程中将主模块排除在外
是检测效率提升的一个可能原因. 为了验证这一点, 对数据集中每个 APK 主模块的包分布情况进行了统计, 大于
10 个包的占比 24.2%, 大于 5 个包的占比 37.8%, 多于非主模块包数.