获取APK中第三方库信息的工具

前言

最近想尝试开发一个Android安全性检测平台，在尝试获取APK第三方SDK的信息的时候出现了一些问题，直接使用androguard是不能获取SDK的信息的，且现在第三方提供的SDK大多都经过了混淆或者重命名处理等保护SDK安全性的方法，就造成了我们很难准确地获取APK中存在哪些SDK。这时候就需要另(yong)辟(xian)蹊(cheng)径(de)，在网上能够收集到的只有16年北大的LibRadar、reddr开源的LibScout和基于LibScout开发的apkLibDetect。

工具的分析

LibRadar

为了避免手动做很多重复性的信息收集工作，我决定尝试使用多个工具。提取我所需的信息，现在想得到个SDK信息都需要了解机器学习，是我太菜了。下面我大概地讲讲LibRadar这个工具，详情可看LibRadar的相关论文。

LibRadar使用了多级聚类技术识别第三方库（因为第三方库调用的次数多，再加上第三方库一般不会修改，根据这两个特点判断是否为第三方库），使用机器学习对第三方库的功能进行准确分类（应该是使用了分类算法）。但是这个工具不能实现我想判断这个第三方库安全与否的功能，且因工具年代久远，团队不再对该工具进行维护。不过要是能将这个工具在python3的环境下修改和调试，应该能减少获取第三方SDK的工作量，且避免了在python更新之后不能正常使用的情况。但是我还没有研究过，这只能作为一个可行的方案之一。

搭建环境

• Ubuntu 18.04
• Python 2.7.6

下面就先在Ubuntu上搭建好Python2的使用环境

# 准备好编译Python的环境
$ sudo apt-get install zlib1g-dev
$ sudo apt-get install gcc
# 获取Python 2.7.6的安装包
$ wget http://www.python.org/ftp/python/2.7.6/Python-2.7.6.tar.xz
$ tar xvf Python-2.7.6.tar.xz
$ cd Python-2.7.6
$ ./configure
# 编译、安装
$ make & make install

接下来就准备好LibRadar的使用环境

# 下载LiteRadar
$ git clone https://github.com/pkumza/LiteRadar
# 下载SDK特征文件
$ wget https://raw.githubusercontent.com/pkumza/Data_for_LibRadar/master/lite_dataset_10.csv
$ mv lite_dataset_10.csv LiteRadar/LiteRadar/Data
# 获取aaa.apk中的第三方SDK信息
$ python LiteRadar/LiteRadar/literadar.py aaa.apk

获取到的结果如下：

但是处理multi-dex的APK会出现如下报错：

但是换了内存稍大一点的VPS就能正常解决，而且显示的结果与LibScout比起来感觉更加符合我们的基础需求，能获取更多中国的第三方库：

LibScout

因为apkLibDetect是基于LibScout的，所以就不另外分出模块讲解apkLibDetect了。在操作过程中如果遇到了问题，可以参考文章的末尾，有我遇到的问题及其处理方式。

搭建环境

• Ubuntu 18.04
• openjdk 11.0.5
• Android Studio

这里先提供了自己编译LibScout.jar的方法，如果不想自己编译LibScout.jar文件，可以直接用apt install libscout，详细的介绍后面有。

2
3
4
5
6
7
# 下载LibScout
$ git clone https://github.com/reddr/LibScout.git
# 下载SDK检测的样本文件
$ git clone https://github.com/reddr/LibScout-Profiles.git
$ cd LibScout
# 生成LibScout.jar
$ ./gradlew build

除了我们自己编译之外，我们还可以使用apt直接安装libscout的方式使用LibScout。

$ apt update && apt upgrade
$ apt install libscout

在下好Android Studio环境下找到Android/Sdk/platforms/android-28目录下的android.jar文件，并在LibScout目录下新建sdk文件夹，将android.jar文件放到该目录下。

$ mkdir sdk
$ mv [path of android.jar]/android.jar sdk/android.jar
$ cd ..
# 使用自己编译的LibScout.jar获取第三方SDK信息
$ java -jar ./LibScout/build/libs/LibScout.jar -o match -p ./LibScout-Profiles -c ./LibScout/config/LibScout.toml -a ./LibScout/sdk/android-28.jar aaa.apk
# 使用apt安装的libscout获取第三方SDK信息并输出到LibScout/result目录下
$ libscout -o match -p ./LibScout-Profiles -c ./LibScout/config/LibScout.toml -j ./LibScout/result -a ./LibScout/sdk/android-28.jar test22.apk

执行命令获取SDK信息，并直接输出到屏幕。-o参数指定相关操作，match是获取该APK中存在的SDK信息，-p参数指向我们之前下载的第三方SDK检测的样本文件，-a参数指向我们之前获取的android.jar，这个参数能将SDK与APK区分开来。如果有其它需求，比如将检测结果输入为json文件，可以添加一个-j参数指定输出结果存放的目录。

根据应用的包名，进入./LibScout/result/cn/ninegame/gamemanager目录下，会发现有一个json文件，该文件储存了第三方SDK信息。下面是格式化过的json文件：

在LibScout平级路径下获取SDK信息出现报错，报错如下：

	
03:59:32.160 [main] ERROR de.infsec.tpl.TplCLI - Error: Could not parse config option logging.log4j_config_file : No valid file: ~/LibScout/config/logback.xml

上面的报错修改了LibScout.toml中logback.xml的路径为./LibScout/config/logback.xml就不会报错了。

在获取SDK信息的过程中遇到了运行Java代码时堆空间过小的报错：

上面的报错同样是可以通过换大内存的VPS或增加虚拟机的内存解决。

其实LibScout也是存在着不足的，但是它有一个优点就是当遇到multi-dex的APK的时候，它会将多个dex文件整合到一起，再进行检测。同时，LibScout还能结合工具判断第三方库是否足够安全，当然这个安全与否是基于是否有漏洞爆出和第三方库的版本的。LibScout的不足还有两个，一是是它需要的较大的内存，二是LibScout能检测的第三方库虽还是存在一些检测不出来的情况，

结尾

比较一下LibRadar和LibScout，会感觉如果不考虑获取第三方库的安全性和检测第三方库的工具的可维护性，LibRadar会更加符合我的需求。但是要考虑到第三方库安全与否，与检测结果是否可延展，可延展指的是可以通过检测结果结合现有的漏洞库信息获取更多我们需要的信息，还是使用LibScout更加合适。