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

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


                 TPL, 同样达到降低成对比较次数、提升检测效率的目的; 后者在前者涮选出的候选                         TPL  中, 通过细粒度的多级签
                 名相似性分析精确地识别第三方库及其对应的版本. 为了验证方法的性能和效率, 构建了                            3  个基准数据集, 并在这
                 些基准数据集上开展了实验验证, 从检测方法的性能、效率和抗混淆性等方面对                           LibPass 进行了评价. LibPass 公
                 开发布在   GitHub  社区  (https://github.com/njustbdag/LibPass) 供研究人员使用.
                    本文第   1  节阐述  Android  平台第三方库检测所需的背景知识以及领域工作现状. 第                2  节详细阐述提出的基于
                 包结构树和签名的检测方法. 第          3  节在基准数据集上进行充分的实验验证, 并与领域先进方法进行的比较分析, 验
                 证本文提出方法的有效性, 并对值得进一步关注的问题进行初步探讨. 最后总结全文.

                  1   背景知识和相关工作

                  1.1   常用混淆策略
                    混淆是增加逆向工程难度的最为常用的技术手段之一, Android                 应用领域广泛采用这一技术保护知识产权, 对
                 抗恶意第三方. 常用的混淆器主要有            ProGuard  [17] , Allatori [18] 和  DashO [19] , 其中  ProGuard  集成在谷歌的  Android
                 现
                 Studio  开发平台, 是最为常用的混淆器. 按照是否改变编译后的              APP  字节码, 可以将混淆技术分为两类         [20] : 平凡混
                 淆和非平凡混淆. 鉴于本文采用的常用混淆器都仅支持非平凡混淆, 故仅描述这些非平凡的混淆技术以及与混淆
                 器的对应关系, 如表      1  所示. 标识符混淆   (identifier renaming, IDR) 是将  APP  中包名、类名、方法名和属性名变形
                 为无意义的字符串, 变形后的签名与原来的签名相比产生很大变化, 使得基于标志符或签名匹配的检测方式失效.
                 字符串加密    (string encryption, SE) 是对  APP  编译打包后的  classes.dex  中的字符串采用特定的加密算法进行加密,
                 并且在添加进解密算法用于运行时解密. 优化操作                 (optimization operation, OO) 通过改变代码顺序、添加额外的
                 流程控制条件和迭代条件改变方法的控制流和数据流等, 使得基于控制流、数据流等进行特征抽取而后采用学习
                 方式进行分析的检测方法失效. 压缩操作             (shrinkage operation, SP) 通过移除  TPL  中没有在  APP  中使用的包、类、
                 方法和属性来降低代码量, 导致          APP  中引入的  TPL  代码结构与原先的不同, 使得基于结构签名、成员成对比较方
                 式的检测方法失效. 类重组        (class repackaging, CR) 通过将编译后的类移动到指定的包中实现重组, 导致包结构发
                 生巨大变化, 使得基于包结构的检测方式失效.

                                               表 1    Android  应用混淆器特征比较

                               混淆器           IDR         SE        OO         SP         CR
                                   [17]
                             ProGuard         √          ×          √          √          √
                                   [18]
                              Allatori        √          √          √          √          ×
                                  [19]
                              DashO           √          √          √          √          ×

                  1.2   APP  开发和发布行为
                    APP  发布前通常应用混淆技术增强逆向工程难度, 同时也显著增加了                      TPL  检测和分析难度. 这里简单回顾
                 APP  的代码组织结构、引入       TPL  的开发行为和混淆过程, 如图        1  所示. 一般说来, Android 应用和   TPL  采用  Java
                 语言编写的, 都以应用程序包         (application package, AP) 的形式组织代码. 按照代码来源划分, APP    中的包要么隶属
                 于主模块, 要么隶属于非主模块, 其中非主模块是开发者植入的、供主模块调用的                          TPLs, 而主模块则是开发者实
                   APP  业务功能的代码部分. 所以, 非主模块与第三方库的关系是非主模块包含了                       1  个或多个第三方库. 按照组
                 织逻辑划分, 主模块和非主模块中的           AP  均可以划分为多个独立的逻辑单元, 分别称之为应用程序根包                   (application
                 root package, ARP) 和库根包  (library root package, LRP). 相应地, 隶属于  ARP  和  LRP  的  AP, 称之为应用程序子包
                 (application subpackage, ASP) 和库子包  LSP (library subpackage). 根包和子包的定义将在第  2.1  节给出.
                    在  APP  开发和发布过程中, 存在      3  种行为: 导入、混淆和优化, 其中混淆和优化是通过混淆器实现的. 具体地,
                 关于导入, 存在完整导入和定制导入两种情形, 其中完整导入是指                    TPL  的所有  LRP  都出现在  APP  中, 定制导入是
                 指  TPL  的部分  LRP、部分  LSP, 甚至是部分类出现在       APP  中, 又或者部分类中的方法和属性被改变. 将             TPL  导
   301   302   303   304   305   306   307   308   309   310   311