1. 引言
随着移动市场的快速增长和Android操作系统的不断完善，Android操作系统的活跃设备数达到了20亿 [1] ，已经成为全球最受欢迎的移动操作系统。Android应用的数量也迅速增长。根据AppBrain [2] 统计：到2018年3月21日为止，GooglePlay上的应用程序数量已经达到了3,624,700，同比2017年3月，GooglePlay上应用程序数量增加了21%。
针对用户快速更新的需要以及同类应用竞争的压力。现在主流的Android应用广泛使用了动态代码加载(DCL)技术。DCL技术允许应用加载或者执行外部的二进制文件，可以从本地加载，也可以从网络下载，其主要目的是为了达到让用户不重新安装应用就能升级应用。根据Zhengyang Qu [3] 的调查，在他收集的Google市场了58,739种应用程序中，69.60%的应用使用了DCL。DCL技术确实为应用的更新和维护带来了方便。
然而DCL技术也产生了一些安全问题。通过使用DCL，应用程序开发者可以在运行时加载没有经过审查的代码片段。Zhengyang Qu [3] 等人实现了一个示例程序，通过DCL技术绕过Google市场的安全检查。除了绕过审查，不当使用DCL也会产生安全问题。Sebastian Poeplau [4] 等人分析了1632个流行应用，发现151个应用易受DCL相关的代码注入攻击。越来越多的研究发现DCL易被恶意利用且不当使用会带来一些安全隐患。
所以本文旨在进一步分析DCL相关的安全问题。我们的目标是第三方市场，我们想要研究：1) 与审查严格的Google市场相比，第三方市场使用DCL情况是不是更为频繁？是不是更容易产生安全问题？2) 哪一类型的应用更容易产生安全问题，需要引起监管者重视？为了调查DCL的使用情况以及安全问题，我们分析设计并实现了一个DCL分析工具，我们选择应用宝市场，分析应用宝市场中应用的DCL使用信息。我们的贡献主要如下：
a) 设计并实现SLDroid工具：自动检测和分析应用使用DCL技术的情况。
b) 分析应用宝市场使用DCL技术的情况，与前人分析Google市场DCL使用情况进行对比研究。
2. 相关工作
作为全球最受欢迎的移动操作系统，Android引入了动态代码加载机制(DCL)技术。用于代码更新和功能扩展。但是同时也带来了新的安全风险。前人针对DCL技术做了细致的研究，如Darell JJ Tan [6] 经过研究认为使用了DCL的应用有可能存在安全问题。Yury Zhauniarovich [5] 调查了应用中DCL使用情况，发现动态加载的代码很多没有进行完整性验证。
针对恶意行为的检测，Martina Lindorfer* [8] ，Igor S [10] 通过提取特征的方式检测恶意软件，T Book [9] Michael Grace [7] 通过建立白名单库进行恶意软件分析。J Sahs [11] , K Allix [12] 通过机器学习检测和评估恶意软件。而由于DCL只有在特定条件下才会触发加载，DCL相关检测与传统的恶意行为检测不同，需要应用运行时才能捕捉到相关行为，前人的通用性检测不适合。
遗憾的是针对DCL的研究相对比较少。Zhengyang Qu [3] 等人通过重打包的方式修复DCL可能存在的问题。Sebastian Poeplau! [4] 希望通过修改系统框架的方式进行检测和修复DCL相关问题。Luca Falsina [13] 则提出了一套DCL相关规范API，指导安全使用DCL。我们认为修改系统不具有普遍性，反编译应用也改变了应用原本的签名，安全性难以保证。DCL使用规范很难得到推广，都存在着一定的局限性。
所以在本文中，我们在Zhengyang Qu [3] 等人研究的基础上，研究第三方市场DCL相关的安全问题，回答1与审查严格的Google市场相比，第三方市场使用DCL情况是不是更为频繁？是不是更容易产生安全问题？2哪一类型的应用更容易产生安全问题，需要引起监管者重视？为了回答这两个问题，我们设计并实现了SLDdroid工具，分析应用宝市场应用使用DCL的相关问题。。
3. 背景知识
动态代码加载：通过在运行时加载外部代码，改变应用程序行为的技术。由于Java的类加载机制，通过Classloader可以延迟加载java字节码文件(动态加载)。如图1所示，Android继承于java的特性，通过虚拟机Dalvik/ART动态加载各类资源文件。同时Android为我们提供了用于动态加载的类加载器DexClassloader：可以在应用运行时加载jar、apk和dex等Android相关的资源文件。
越来越多的应用开发者选择使用DCL技术，DCL技术有以下好处：
1) 减少应用安装包的体积。当应用程序包较为庞大时，而部份资源只有满足某些触发条件才会加载进内存，可以选择使用DCL技术，当满足触发条件时，从远程下载，动态加载可执行模块。
2) 便于升级和维护，将主要功能模块存储在外部可执行代码中，在功能更新时，替换或者修改外部可执行代码模块。在用户不需要重新安装应用甚至无感知的情况下，完成对于应用功能模块的升级和维护工作。
3) 功能独立。使用了DCL技术的应用。只需要针对外部功能模块进行维护和更新。可以方便的添加和减少功能模块，这对于功能越来越臃肿的应用带来了巨大的收益。
然而使用DCL技术产生了安全问题：
风险1：根据Google Play的开发者政策 [16] ：明确禁止从Google Play以外的其他来源下载可执行代码(例如dex文件或本机代码)的应用或SDK。有研究证明 [4] 从网络不可靠来源下载可执行代码确实存在一定的风险。遗憾的是第三方应用市场如应用宝并没有这样的规定。
风险2：动态加载的资源存储在可以被其他应用读写的目录中，如Sdcard中，并且应用本身也没有对加载的资源进行完整性验证，恶意攻击者可以轻易通过替换加载资源对应用本身进行恶意攻击。
我们设计SLDroid就是针对DCL存在的相关风险做对应的分析。
4. 设计
为了调查DCL，我们设计了SLDroid工具(见图2)。首先我们获取到应用市场的网页地址，分析应用市场网页特征，这一步由人工分析。应用市场网页的特征相对明显，一段时间固定不会改变，我们抓取我们所需的一个app的初步信息，包括ApkName，二进制文件和其他基本信息。其中二进制文件用于静态分析和动态分析。静态分析主要作为是否使用了DCL技术的依据。同时分析应用是否在使用DCL中违反了内容策略。动态分析主要通过代码注入以及日志分析检查DCL实际的使用情况，同时辅助环境伪装进行测试可能的DCL远程下载。根据系统前面分析的结果，生成详细的DCL相关报告，包含应用的基本信息，触发条件，分析结果以及潜在风险或者建议。
Figure 2. The detection process of SLDroid
图2. SLDroid检测过程
4.1. WebSite Analysis
为了获取应用信息，包括ApkName：用于唯一标志一个应用，二进制文件：用于静态分析和动态分析的安装包。基本信息：包括下载量，分类，评价，用于结果的分析。我们需要对应用市场网页进行分析。
Classification：应用市场把应用分为20项，categoryId范围从101到120，代表一个应类(见图3)。我们也以categoryId作为下载应用的分类标志，同时应用下载量和评价信息也存在于应用详情网页的固定位置，我们可以方便获取到。
Information Grab：应用市场都会采取措施针对非人工抓取信息，因为我们抓取的应用数量不大，所以我们选择通过自动打开市场页面的方式，模拟人工手动下载应用。
Download：在获取到包括下载链接等信息以后，我们下载应用的二进制文件，我们控制文件下载速度，检查文件大小和格式是否正确。
通过Website Analysis，我们通过categoryId对应用进行分类，获取应用下载量和评价，以应用包名标志应用，下载二进制文件。
4.2. Static Analysis
DCL Use：应用是否使用了DCL是我们静态分析首要解决的问题。DCL在java层和native层动态加载代码是不同的，在java层加载代码需要通过类DexClassLoader [15] ：加载未安装代码的jar或者apk文件。DexClassLoader只有一种初始化方式，所以我们只需要检测代码中是否存在DexClassLoader初始化。Native层加载代码需要在初始化阶段通过System.load()加载，我们只需要检测是否有加载就可以确定是否在native层存在DCL的操作。
Application Filter：使用了DCL并不一定存在风险，我们想要进一步过滤应用，减少Dynamic Analysis成本。根据风险触发条件：如果可执行代码存储在其他应用的读写目录，如外部存储区。如果想要存储和加载外部存储区的可执行代码，在4.4以上的版本需要在配置文件中申明
以及
。当然在4.4及4.4以下的版本不需要申明权限。在6.0以上的版本需要动态申请权限。从版本兼容的角度考虑，我们认为如果使用的DCL存在风险，则必然申请了
以及
。
Policy Check：根据Google Play的开发者政策 [16] ：明确禁止从Google Play以外的其他来源下载可执行代码(例如dex文件或本机代码)的应用或SDK。我们了解应用宝市场并没有明确的政策规定不允许从不可靠来源下载可执行代码，但是我们认为如果从不可靠来源加载代码是非常危险的。关于策略的检查，首先应用必须申请了网络权限且存在DCL相关特征，其次我们认为如果从不可靠来源下载代码，会存在一条路径，从网络下载到代码加载的一条路径。
DCL User：为了了解是应用还是第三方库使用了DCL，我们记录使用了DCL所在的类的全路径，我们过滤了诸如com、android，org等等会影响结果的关键字.，将过滤后的全路径与L LI [18] 收集的1130个功能库好240个广告库进行相似度对比。在无法找到对应第三方库时，与应用包名进行相似度对比，我们认为高于50%的匹配度就是匹配成功，如果无法匹配，我们将进行手动分析。
4.3. Dynamic Analysis
考虑到通用性，我们实现了一个应用层的容器，不需要修改Android框架层，实现针对应用中DCL功能的Dynamic Analysis(见图4)。借助SLDroid实现了针对环境的伪装，通过代码实现环境改变，测试DCL触发点。SLDroid主要由俩部分组成：Environment Trigger和DCLRisk Check。通过环境伪装触发DCL，捕获DCL，进行对应的DCL风险检查，保存检查结果，转发对应请求。
Figure 4. Frame structure of Dynamic Analysis
图4. Dynamic Analysis框架
Environment Trigger：为了逃避审查，DCL的下载或者加载都是有一定的触发条件：或是检测到真机(存在Mac地址，DeviceId)，或是打开了Wifi，存在真实的位置信息。为了触发DCL，我们在容器中对应用这些信息的请求都做了处理，一旦应用请求这些信息，我们对数据进行合理的伪装，返回给应用需要的信息，通过伪装触发可能的DCL相关的操作。节省人工手动设置的时间和判断误差。
DCLRisk Check：我们对DCL相关操作进行拦截，获取DCL相关信息。检查可能存在的风险。风险1：从不可靠来源下载可执行代码。在静态分析阶段我们已经分析了可能存在不可靠来源下载的代码，我们记录了代码的调用链，当应用加载外部代码时，我们将调用链与堆栈信息进行对比。如果吻合，则证明该应用确实存在风险1。风险2：动态加载的DEX文件存储在被其他应用读写的目录中，通过检查DexPath是否是外部存储路径或者其他应用可读写的目录。而在native层代码，我们检查加载的路径外部存储路径或者其他应用可读写的目录。我们对风险检查的结果进行保存，同时当检查完毕，执行正常操作，不影响应用的使用。
4.4. Analysis Result
我们对应用中使用DCL相关信息进行详细的记录。以包名作为唯一标识，记录应用的基本信息，DCL使用信息，分析过程，风险以及建议等四项。作为我们的实验数据。
5. 实现
我们使用Selenium [14] 编写了一个自动抓取应用宝信息并且下载应用的脚本，结合androguard [19] 和flowdroid [17] 实现我们对应用的静态分析.我们对工具Virtualapp [20] 进行改进，对环境相关的方法进行拦截，如getdeviceid()，getLatitude()，.getLongitude()等等方法，同时针对DCL相关方法进行拦截。我们将结果信息写入数据库，通过数据库进行查询。
6. 实验结果
我们使用SLDroid收集了2018年6月16日应用宝市场20分类的数据集。每类应用只收集下载次数前100的应用。以下是实验结果。
6.1. 检测结果
我们对应用宝市场20类应用进行分析，每类应用收集下载次数前100的应用。由于部分分类应用不足100，所以总共对应用宝市场1934款应用进行了分析，我们将结果分为Website Analysis，Static Analysis以及Dynamic Analysis阶段分别展示，如表1所示。
加固：在我们分析的1934款应用中，16款应用我们不能进行反编译分析，我们手动检查了这些应用，发现这些应用使用了加固技术。
DCL使用情况：1454 (75.18%)的应用在使用了DCL技术。这项数据远远高于Zhengyang Qu [3] 针对Google市场的69.60%应用使用DCL技术的实验数据，因此第三方市场应用使用DCL技术更为频繁。同时我们也发现视频和新闻类的应用使用DCL非常常见，可能由于视频和新闻类应用体积较大，且功能模块比较多，需要使用DCL技术降低应用体积。市场审查者需要重视新闻类和视频类应用的审查。
DCL使用者：我们总共分析了1918款应用(加固无法分析)，如图5所示：996 (51.93%)款应用自身使用了DCL技术，1152 (60.06%)款应用引入的第三方库使用了DCL技术，74 (3.86%)款应用引入的Google官方库中使用了DCL代码。Google市场 [3] DCL使用的主体是第三方库，应用开发者很少使用DCL技术。而在第三方应用市场，应用开发者和第三方库都是使用DCL技术的主体，出现这种不一致性的原因可能是由于第三方市场对于DCL使用的审查不够严格有关系。
6.2. 风险结果
Risk 1：根据Google Play的开发者政策 [16] ：明确禁止从Google Play以外的其他来源下载可执行代码(例如dex文件或本机代码)的应用或SDK。Sebastian Poeplau等人 [4] 证实经过研究认为从网络不可靠来源下载可执行代码确实存在一定的风险。
如表2所示我们一共发现23款应用存在风险1，其中 8款应用由于应用开发者引起，15款应用由于第三方库产生了安全风险。同时我们也希望引入百度SDK的应用进行检查，在第三方库产生风险的15款应用中，10款应用由于引入了百度SDK产生了风险(见表3)。
Table 3. Result of third-party library generating risk1
表3. 第三方库产生风险1的情况
Risk 2 Result：动态加载的资源存储在可以被其他应用读写的目录中，如Sdcard中，并且应用本身也没有对加载的资源进行完整性验证，恶意攻击者可以轻易通过替换加载资源对应用本身进行恶意攻击。
如表4所示我们一共发现7款应用存在风险2，其中2款应用由于程序开发者引起，5款应用由于第三方库产生了安全风险。
7. 结论
Android引入了动态代码加载机制(DCL)技术。用于代码更新和功能扩展。越来越多的Android应用使用DCL技术。然而应用市场并没有严格审查DCL使用情况，特别是第三方市场。我们设计并实现了一个自动化工具SLDroid：检测第三方市场DCL使用情况及风险。我们的实验结果表明，与Google市场相比，第三方市场应用使用DCL技术更频繁，新闻类和视频类应用使用DCL技术较多。同时由于没有严格限制DCL技术使用，相比Google市场，程序开发者也频繁使用DCL技术，更容易产生安全风险。
基金项目
国家自然科学基金项目(U1536121, 61370195)。