Page 310 - 《软件学报》2024年第6期
P. 310

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


                    现有方法的归纳和对比分析如表            2  所示. 本文研究工作的目标是从给定的           Android  应用  APK  文件中识别集
                 成的特定版本的第三方库, 并不进一步区分植入的第三方库是否为广告库或者恶意库. 现有的基于白名单的方法
                 和基于机器学习的方法可以达成与本文工作相同的目标. 然而, 基于白名单的方法和基于机器学习的方法除了可
                 以达成与本文研究工作相同的目标外, 还可以用于识别植入的广告库和恶意库. 以基于白名单的                               TPL  检测方法为
                 例, 可以通过在白名单中设定已知的广告库或者恶意库清单, 一旦识别到出现在清单上的第三方库, 则能在识别植
                 入的第三方库的同时给出诸如该第三方库是否为广告库或恶意库的标注信息. 从这个角度上来说, 基于白名单的
                 方法在给出白名单中每个库的标注信息前提下, 可以提供更丰富的功能. 因此, 表                         2  重点比较了基于相似性比较
                 的  TPL  检测方法. 表  2  中的比较项“表示形式”是一种       APK  或  TPL  的抽象表达, 刻画了有利于比较的        APK  或者第
                 三方库的变形; “采用的相似性度量”则表示基于特定的表示形式所设计的具体度量; “比较方式”刻画了所设计的
                 相似性度量的应用方法和过程. 现有的基于相似性比较的                   TPL  检测方法在上述     3  个比较项上做了精心设计以满
                 足检测需求. 这    3  个方面是有着紧密联系的. 表示形式往往影响着检测能力, 如类库区分能力、混淆对抗能力. 相
                 似性度量则依赖于表示形式, 而比较方式依赖于表示形式和相似性度量. 此外, 值得注意的是表中列出的不同方法
                 的检测效率和精度来自于对应文献, 并不是在统一的基准数据集上的实验结果, 鉴于方法评价实验中采用的混淆
                 测精度, 并利用包结构签名完成快速比对以识别候选
                 策略、数据集规模等上存在显著不同, 因此结果并不具备可比性. 这里, 检测效率是指给定一个待分析                                   APK
                 (以.apk  文件存在的  APP), 输出  APK  引入的  TPL  清单的时间开销. 基于白名单的方式, 时间开销是包名匹配时间.
                 基于机器学习的方式和基于相似性比较的方式, 时间开销有                   APK  特征抽取和匹配两阶段构成. 因为基于相似性比
                 较的方式建立在      TPL  本地库上, 而本地库规模大于基于机器学习方式建立的分类器或聚类个数, 所以需要更多的
                 时间开销.
                    与现有的工作相比, 本文的创新之处在于采用了基于包结构树的表示方式, 并提出包结构树整形方法来有效
                 应对标志符混淆和代码压缩, 并一定程度上缓解扁平化混淆带来的检测精度下降. 包结构树是刻画结构信息的一
                 种天然表示, 缺省的包结构树同一层上隶属于相同父节点的子包以字典序排序. 然而, 集成到应用程序中的                                  TPL
                 在应用正式发布前会进行混淆, 可能删除部分库中未被使用的子包、改变类的隶属关系, 以及混淆包名等, 这些混
                 淆操作会导致包结构树显著地不同于缺省包结构树, 导致基于包结构树相似性比较方式识别                                TPL  的方法准确性
                 低. 因此, 引入包结构树整形方法, 先改变子包排序方式, 取代字典序以子包重要性作为包排序方式, 包重要性越高
                 则在混淆阶段被移除的可能性更小, 将其放置在同一层上的更左侧位置, 而后对所有包名进行重命名, 进一步地借
                 助于包结构树签名匹配筛选可能引入的              TPL. 在包结构树签名生成阶段, 类似于          LibID, 本文同样考虑了基于依赖
                 关系的类签名方法, 主要动机在于类依赖关系是在混淆情形下仍能得以保持的稳定特性能提升类签名抗混淆能
                 力. 在类签名生成时考虑类的方法数量和类的依赖关系作为类重要性评价的两个因素计算类权重, 构建了基于加
                 权机制的类签名方法, 这与        LibPecker 中权重度量方法是不相同的. 此外, 与最为相近的工作              LibScout 和  LibPecker
                 相比, 还进行了效率和性能方面的改进和优化形成了新的解决方案                      LibPass. 针对检测效率低的问题, 设计主模块
                 识别和基于包结构的快速检测组件, 前者用于排除                APP  中开发人员自行开发的功能模块, 后者快速从大规模第三
                 方库本地库中筛选出候选第三方库, 经过验证显著提升了检测效率. 针对检测中的误检率和漏报率高的问题,
                 LibPass 提出了一种基于签名的两阶段检测方法, 即通过基于包结构树的快速检测和基于多级签名的细粒度检测
                 相结合的方法实现       TPL  检测. 前者利用包结构特征的稳定性来应对应用程序的混淆行为以提升混淆情形下的检
                                                          TPL, 同样达到降低成对比较次数、提升检测效率的目的; 后
                 者在前者涮选出的候选        TPL  中, 通过细粒度的多级签名相似性分析精确地识别第三方库及其对应的版本.

                  2   LibPass

                    给定任意的安卓应用        APK  文件和一组本地第三方库         TPLs 作为  TPL  检测方法的输入, 通过检测方法输出为
                 该  APP  中植入的带版本号的     TPL  清单, 且每个   TPL  保存为一个对应的     jar 文件. 对于采用成对比较思路的检测方
                 法而言, 给定一个待分析的        APK, 理论上需要与     TPL  本地库中每个    TPL  进行逐一比较, 进而确定该        APK  中引入
   305   306   307   308   309   310   311   312   313   314   315