Apk检测项
编码规范检测¶
URL硬编码风险检测¶
URL硬编码是指将URL地址信息以硬编码的方式写在应用代码中。攻击者反编译应用包后,可以获取应用包中的URL地址信息,并攻击其所在服务器。如果服务器的安全防范能力薄弱,攻击者可以破解服务器的安全防护措施,从而获取服务器上存储的敏感信息。
硬编码安全¶
本地存储密钥或服务器url被硬编码在代码中容易被黑客窃取并利用,给攻击者渗透入侵带来了方便,增加了服务器被入侵的风险。
恶意程序检测¶
恶意程序
未使用编译器堆栈保护技术¶
攻击者利用堆栈溢出漏洞时,通常会破坏当前的函数栈。在所有函数调用时向栈帧内插入一个称为canary的随机数,这种技术称为Canaries探测技术。若发生缓冲区溢出,则返回地址被覆盖之前canary值会首先被覆盖。在函数返回前,系统会执行canary是否被修改的安全验证操作。如果canary值被修改,则发生了栈溢出,此时程序会跳转到__stack_chk_fail输出错误消息,然后中止执行。在不使用Canaries栈保护技术情况下,当发生栈溢出时系统不会中止程序的执行,从而引发栈溢出攻击。
权限冗余检查¶
开发人员为了方便,在程序主配文件AndroidManifest.xml申请了大量权限,而在程序运行逻辑中并未使用到,导致出现权限冗余的情况。恶意应用在本身没有申请相应权限的情况下,可利用含有权限冗余且存在漏洞的应用,达到盗取用户隐私的目的。

未使用地址空间随机化技术¶
PIE是Position Independent Executables的简称,是一种地址空间随机化技术。当应用程序中的so文件被加载时,在内存里的地址是随机分配的。如果不使用PIE,会降低攻击者的攻击难度,增加敏感信息泄漏的风险。
资源文件中包含APK检测¶
应用的资源文件中包含的APK文件可能会携带恶意程序或造成其他不可预知的风险。
初始化IvParameterSpec函数错误¶
应用程序在代码中初始化IvParmeterSpec类时,使用硬编码来初始化向量,导致密码文本可预测性变高,容易受到字典攻击,以下是常见错误/不安全配置
// ❌ 错误:IV 长度不对(AES 需要 16 字节)
new IvParameterSpec(new byte[8]); // → InvalidAlgorithmParameterException
// ❌ 错误:IV 为 null
new IvParameterSpec(null); // → NullPointerException
// ❌ 错误:使用固定 IV
new IvParameterSpec(new byte[16]); // 全 0 IV,极度不安全!

发布规范检测¶
连接外部站点¶
本地存储的外部访问地址被硬编码在代码中,容易被黑客窃取并利用,给攻击者渗透入侵带来了方便,增加了服务器被入侵的风险。
Debug模式未关闭¶
APP 软件 AndroidManifest.xml 中的属性值 android:debuggable 如果为 true,那么 APP 可以被 Java 调试工具例如 JDB 等进行调试。当 APP 被调试工具进行调试后可以获取和篡改用户敏感信息,甚至可以分析然后修改代码以实现恶意的业务逻辑,我们经常使用 android.util.Log 来打印日志,而 APP 发布后调试日志能被其他开发者看到,APP 就容易被反编译破解。

或者使用drozer模块来找出所有开启了debug的app

Note
debug=false通常对frida hook无影响,frida在设备Root/非Root下都可以使用
敏感信息文件和字符串泄漏¶
检查移动客户端 APP 私有目录下的文件及 APP 自身代码中是否存在敏感信息泄露的情况,如果有该类情况,则可能泄露 APP 自身中的服务端接口信息以及用户信息(如密码、私钥)等。
先检查 APP 源码中是否直接硬编码了敏感信息(如账号密码、IP 地址、邮箱等)。再检查 /data/data/APP包名 路径下的文件以及 SD 中包含 APP 名称的目录中的文件,检查其中是否存在敏感信息(如密码、私钥等)、敏感信息是否加密以及是否能通过修改 SD 卡文件影响 APP 正常运行。
- apkleaks
# install apkleaks
pip install apkleaks
# or install in docker
docker pull dwisiswant0/apkleaks:latest
使用apkleaks查看apk中存在的密钥、敏感信息
该工具默认使用的匹配规则为:apkleaks/config/regexes.json at master · dwisiswant0/apkleaks
我们可以在config/regexes.json文件中增加自已的规则,实现规则的扩展
apkleaks底层是使用的jadx对apk进行反编译
{
"package": "gait.app",
"results": [
{
"name": "IP_Address",
"matches": [
"1.0.0.0",
"1.9.9.8",
"192.168.2.1",
"4.5.4.1",
"4.5.4.2"
]
},
{
"name": "LinkFinder",
"matches": [
......
]
},
......
}
- mobsf

也在mobsf静态扫描面板处可以看到扫描到的password等
应用数据任意备份风险¶
主配文件AndroidManifest.xml中application标签的allowBackup属性没有设置或者设置为true时,就可通过 adb backup 和 adb restore 来进行备份和恢复应用程序数据,这样是可能获取到明文存储的用户敏感信息。对于金融类应用来说,攻击者可以利用此漏洞来实施资金盗取等恶意行为。
# 导出app备份数据
adb backup -f backup.ab com.example.app
# 解包,工具地址: https://github.com/nelenkov/android-backup-extractor
java -jar abe.jar unpack backup.ab backup.tar
tar -xvf backup.tarS

也可以使用drozer来枚举出可导出的所有package

具有API KEY的包一般都存在对第三方服务的依赖,如com.google.android.apps.photos需要依赖谷歌服务同步本地图片到服务器,如果是不需要外部服务的本地实现的app,则一般不具有API KEY
Note
需要注意的是,API KEY也算敏感信息
签名校验¶
Android 目前支持以下四种应用签名方案:
- v1 方案:基于 JAR 签名。
- v2 方案:APK 签名方案 v2(在 Android 7.0 中引入)
- v3 方案:APK 签名方案 v3(在 Android 9 中引入)
- v4 方案:APK 签名方案 v4(在 Android 11 中引入)
应用程序发布前未包含签名校验功能或指存在v1版本签名,就存在被二次打包的风险。

签名校验原理说明¶
正常情况(私钥未泄露):
- 原始 App 由开发者用 私钥 A 签名(v1+v2+v3)
- 攻击者**没有私钥 A**
- 攻击者修改 APK 后,只能用自己的 私钥 B 重签名
- 用户设备安装时:
- 如果是**首次安装**:可以安装(因为系统只校验“签名是否有效”,不校验“是否是原开发者”)
- 如果是**覆盖安装**:安装失败!(Android 要求新 APK 的签名必须与已安装版本**完全一致**)
这就是 v2/v3 签名防范二次打包的核心机制:阻止非授权覆盖安装
当然如果攻击者窃取了开发者的签名私钥,那么完全可以进行覆盖安装
如果app运行时存在签名校验机制,那么也可以防止首次安装成功,示例代码如下:
// 示例:校验签名是否为官方值
private boolean isOfficialSignature() {
try {
Signature[] sigs = context.getPackageManager()
.getPackageInfo(context.getPackageName(), PackageManager.GET_SIGNING_CERTIFICATES)
.signingInfo.getApkContentsSigners();
return sigs[0].toByteArray().equals(OFFICIAL_SIGNATURE_BYTES);
} catch (Exception e) {
return false;
}
}
| 攻击场景 | v2/v3 能否防护? | 说明 |
|---|---|---|
| 覆盖安装(已装官方版) | ✅ 能 | 系统强制签名一致 |
| 首次安装恶意包 | ❌ 不能 | 需依赖运行时签名校验 |
| 私钥泄露 | ❌ 不能 | 非机制问题,是密钥管理问题 |
那么我们在想一个问题,如果攻击者窃取了开发者签名密钥,能否将自已的经恶意伪造过的app发布到google play、app store等手机应用商店,从而将恶意app更新到用户手机上呢?
| 问题 | Google Play (Android) | App Store (iOS) |
|---|---|---|
| 窃取开发者私钥后能否发布更新? | ✅ 能(通过 Upload Key 提交,Google 重签名分发) | ❌ 不能(需账号 + Apple 审核) |
| 能否覆盖用户设备上的正版 App? | ✅ 能(用户收到“官方更新”) | ❌ 不能 |
| 核心风险点 | Upload Key 泄露 + 无 2FA | Apple ID 凭据泄露(比私钥更关键) |
事实上,应用商店上架的app必须经过审核且签名密钥并不使用开发者的签名密钥,所以利用难度极高
参考文章:
我们再看看官方更新与攻击者覆盖安装的对比
| 行为 | 官方开发者 | 攻击者(无私钥) |
|---|---|---|
| 修改 APK 内容 | ✅ 可以 | ✅ 可以 |
| 用原始私钥重签名 | ✅ 可以 | ❌ 无法做到 |
| 生成有效 v2/v3 签名 | ✅ 可以 | ❌ 只能用自己的密钥签 |
| 通过系统签名校验 | ✅ 新旧签名一致 | ❌ 新旧签名不一致 → 安装失败 |
使用调试证书发布应用风险¶
签名证书是验证应用开发者身份的关键标识,可用于判断App是否是由合法开发者发布的正版应用,并且App常使用签名校验作为防止App被二次打包的措施。使用调试证书发布应用,可能导致App无法在应用市场上架,并且debug证书的有效期仅有一年使用;使用debug证书发布的应用可能会出现各个版本的签名证书不一致的情况,这样会导致App应用无法成功升级;同时,证书的不一致性可能造成App使用的签名校验措施频繁改动或者被迫取消,最终导致应用被二次打包。
残留账号密码信息检测¶
APK中如果存在残留的手机号信息,如可能会被盗取并恶意利用在正式服务器上进行攻击如重放攻击,或者攻击安全薄弱的测试服务器以获取安全漏洞或者逻辑漏洞等。
代码安全检测¶
源代码反编译风险¶
源代码暴露可能导致应用程序运行逻辑被破解、业务逻辑被绕过,造成经营资金损失、影响公司声誉等风险。


反编译后代码若不存在混淆,攻击者能较容易分析出代码的逻辑
加固壳检测¶
针对Android平台应用所面临的反编译和二次打包问题,对应用进行加固是目前最有效的解决方案。由于通用加固方案的加固强度较低、加固方式较为普遍,无法有效防止反编译工具的破解,或者容易被脱壳并且反编译,因此,建议采用企业级定制化加固方案,有效地保护源代码安全和防止篡改及二次打包风险。

使用MT管理器可以看到app的加壳情况
So保护检测¶
So文件为Apk中包含的动态链接库文件,Android利用NDK技术将C/C++语言实现的核心代码编译为so库供Java层调用。So被破解可能导致核心功能的汇编代码甚至源代码泄露,不仅损害开发者的知识产权,并且可能暴露了客户端的核心功能逻辑,攻击者可以利用这些信息窃取客户端的敏感数据,包括手机号、密码;截获与服务器之间的通信数据;绕过业务安全认证流程,直接篡改用户账号信息;对服务器接口发起攻击等。
应用签名算法不安全风险检测¶
在签署数字证书时,签名算法的完整性是决定证书安全性的关键因素。签名算法的弱点可能导致攻击者在某些情况下能够获得伪造的证书。其中,普遍使用的SHA-1已经过时因而不再推荐使用,基于MD5的签名的支持也在2012年初停止。

使用jadx查看签名证书,该应用证书使用SHA256withRSA算法
混淆配置检测¶
应用程序源代码未进行混淆,攻击者可以根据代码的命名方式来猜测程序运行的逻辑,降低了逆向分析程序的难度。
仅使用Java代码风险检测¶
在Android开发本地代码时,有两种方式,一种是使用javah生成头文件,然后编辑源代码,另一种不用生成头文件,直接编辑代码后,使用RegisterNatives方法进行注册,是运行在JVM外的Native代码。针对第一种方式,使用javah生成头文件,枚举java声明的native方法,可以查到对应的函数,使用工具可轻易获取源码,造成代码泄露。
资源文件泄露风险¶
资源文件被明文存储易导致程序功能逻辑泄露,进而被篡改,植入恶意代码或钓鱼页面,泄露用户敏感信息。
环境安全审计检测¶
模拟器¶
应用程序可运行在模拟器环境中,攻击者在模拟器中有root权限,可以随意分析应用数据,增加敏感信息泄露的风险。
C层代码动态调试漏洞¶
如果App存在C层代码动态调试的风险,攻击者可以利用GDB、IDA、Strace等调试器跟踪运行的目标程序,查看、修改内存中的代码和数据,分析并篡改程序的业务逻辑,对客户关键数据或者服务器进行恶意攻击,例如修改客户端业务操作数据,如转账账号、金额等,造成用户经济损失。
Root设备运行风险¶
应用未对终端是否Root进行检测及采取保护措施。应用在 Root终端上运行具有极高的安全风险,容易导致数据泄露。
Java代码反调试保护¶
java代码中未启用反调试保护机制,攻击者可以通过动态调试来窥探客户端的数据流和工作流,增加程序核心逻辑被破解的风险。
内存访问和修改检测¶
通过对移动客户端 APP 内存进行访问,木马程序将有可能会得到保存在内存中的敏感信息(如账号、密码等)。如果内存中存在敏感信息,攻击者可从 APP 内存中获取到用户的敏感信息。
- adb导出内存

App Summary
Pss(KB)
------
Java Heap: 29140 //java 堆所占用的物理内存
Native Heap: 455468 //native 堆所占用的物理内存
Code: 138068
Stack: 3844
Graphics: 152964
Private Other: 96928
System: 9739
//app进程中占有物理内存(等于uss+按比列的共享库物理内存)
TOTAL: 886151 TOTAL SWAP PSS: 39
Objects // 进程中关键对象情况 ,activity \binder 个数,可看内存泄漏
Views: 166 ViewRootImpl: 2
AppContexts: 5 Activities: 4
Assets: 7 AssetManagers: 4
Local Binders: 71 Proxy Binders: 40
Parcel memory: 40 Parcel count: 155
Death Recipients: 2 OpenSSL Sockets: 8
SQL
MEMORY_USED: 1092
PAGECACHE_OVERFLOW: 342 MALLOC_SIZE: 79
DATABASES //进程中数据库db 打开情况
Asset Allocations //进程中asset 打开情况
# dump app内存(建议保存到/data/local/tmp目录,其他目录不一定有权限)
adb shell am dumpheap <package_name> <save_path>/xx.hprof
# adb shell am dumpheap gait.app /data/local/tmp/gait_app_dump.hprof

生成的hprof文件我们可以使用MAT打开
MAT(Memory Analyzer Tool)工具是eclipse的一个插件(MAT也可以单独使用),使用起来非常方便,尤其是在分析大内存的dump文件时,可以非常直观的看到各个对象在堆空间中所占用的内存大小、类实例数量、对象引用关系、利用OQL对象查询,以及可以很方便的找出对象GC Roots的相关信息,当然最吸引人的还是能够快速为开发人员生成内存泄露报表,方便定位问题和分析问题

打开报错,这是由于adb dump的内存文件和MAT识别的标准hprof格式存在不同,我们需要使用sdk自带的hprof-conv(platform-tools文件夹下) 工具进行转换
# 转换mat标准文件
hprof-conv -z <src> <dst>
# hprof-conv -z gait_app_dump.hprof gait_app_dump_mat.hprof

此时能正常打开文件
- Objection

操作app执行登陆操作

搜索到明文和密文的密码


找到与该应用有关的so文件,基址为0x7520c6b000,加上偏移量0x12dccc80之后为0x7533A37C80
之后用16进制编辑器打开查看即可
Note
使用内存偏移量dump的方式的难点在于要找到与目标应用相关的so文件,有时候一个应用有很多的so文件,所以还是建议直接search
组件安全检测¶
攻击面枚举¶

会列出有多少组件可导出,由于组件漏洞基本上都是由于可导出造成的,该模块可以快速获取组件攻击面
Broadcast Receiver风险¶
广播接收器 (Broadcast Recevier) 是一个专注于接收广播通知信息,并做出对应处理的组件。很多广播都是源自于系统代码,例如:电池电量低、通知时区改变、拍摄了一张照片或者用户改变了语言选项等等。当然应用程序也可以进行广播,例如,应用程序通知其它应用程序下载完成一些数据并处于可用状态。应用程序可以拥有任意数量的广播接收器以对所有它感兴趣的通知信息予以响应,所有的接收器均继承自 BroadcastReceiver 基类。广播接收器是没有用户界面的,但是它们可以启动一个 activity 来响应它们收到的信息,或者用 NotificationManager 来通知用户。如果 Broadcast Recevier 存在问题则可能被系统或者第三方的应用程序直接调出并使用。
组件导出可能导致登录界面被绕过、信息泄露、数据库 SQL 注入、DOS、恶意调用等风险。
检查 AndroidManifest.xml 文件中注册的 Broadcast Receiver,查找静态 Broadcast Receiver,反编译后检索 registerReceiver() 或者使用 drozer 命令 run app.broadcast.info -a APP包名 -i 来查找动态 Broadcast Receiver。注意检索 setPackage 方法与 receiverPermission 变量,查找发送广播内的信息检索 sendBroadcast 与 sendOrderedBroadcast,查看 onReceive 方法,检测是否存在信息泄露或拒绝服务的问题。
dz> run app.broadcast.info -a com.packagename
dz> run app.broadcast.info -a gait.app -i
dz> run app.broadcast.send --component com.packagename --action xxx.xxx.xxx
# 我遇到的 onReceive 方法中使用 getSerializableExtra 时缺少异常处理机制,存在拒绝服务风险
dz> run app.broadcast.send --action xxx.xxx.push.PenddingIntent

程序目录权限检查¶
/data目录¶
在 Android 系统中,/data 目录是一个非常重要的目录,用于存储系统和应用程序的私有数据。它的权限设置和访问限制非常严格,以保护用户数据的安全性和隐私。
/data 目录的权限设置¶
- 目录权限:
/data目录通常的权限是drwx------,即只有root用户和system组有读、写和执行权限。-
其他用户(包括普通用户)没有任何权限访问该目录。
-
目录所有者:
/data目录的所有者通常是root用户,所属组通常是root或system。
普通用户能否读取 /data 目录¶
普通用户(非 root 用户)通常**无法读取** /data 目录中的内容。原因如下:
- 权限限制:
/data目录的权限设置为drwx------,只有root用户和system组有权限访问。-
普通用户没有权限进入该目录,更无法读取其中的内容。
-
安全机制:
- Android 系统通过用户 ID(UID)和组 ID(GID)来管理权限。每个应用程序都有一个唯一的 UID,应用程序的数据存储在
/data/data/<package_name>目录下,只有该应用程序的 UID 有权限访问。 - 普通用户(如用户安装的应用程序)无法访问其他应用程序的数据目录,以防止数据泄露和隐私问题。
特殊情况¶
- Root 权限:
-
如果设备被 Root(即获得了超级用户权限),普通用户可以通过获取
root权限来访问/data目录。但 Root 设备会带来安全风险,不建议在生产环境中使用。 -
开发者选项:
- 在某些情况下,开发者可以通过启用开发者选项并使用特定的调试工具(如 ADB)来访问
/data目录。但这通常需要设备处于调试模式,并且用户具有一定的技术背景。
Note
普通用户:无法读取 /data 目录,因为权限限制和安全机制。
Root 用户:可以通过 Root 权限访问 /data 目录,但存在安全风险。
开发者:可以通过开发者选项和调试工具(如 ADB)在特定条件下访问 /data 目录。
/data/data目录¶
在 Android 系统中,/data/data 是一个非常重要的目录,用于存储应用的私有数据。以下是关于该目录的功能和权限控制的详细说明:
/data/data 目录的功能¶
- 应用独立存储:
- 每个应用都有一个独立的子目录,路径为
/data/data/<package_name>/,其中<package_name>是应用的唯一标识(如com.example.app)。 -
这些子目录用于存储应用的各类数据,包括数据库、配置文件、缓存文件等。
-
目录结构:
-
/data/data/<package_name>/下常见的子目录包括:databases/:存储 SQLite 数据库文件。shared_prefs/:存储 SharedPreferences 文件,用于轻量级配置数据。files/:存储应用生成的文件,如图片、视频等。cache/:存储临时缓存数据。
-
生命周期管理:
- 应用卸载时,其对应的
/data/data/<package_name>/目录会被系统自动删除。
权限控制¶
-
访问限制:
-
/data/data目录及其子目录是应用私有的,只有对应的应用和系统本身才有权限访问。 -
其他应用无法直接访问
/data/data下的数据,以防止数据泄露和隐私问题。 -
普通用户访问:
-
普通用户(非
root用户)无法直接访问/data/data目录,需要设备被 Root 或通过特定的调试工具(如 ADB)。 -
在 Android 11 及更高版本中,谷歌引入了文件沙盒存储模式,进一步限制了第三方应用对
/data/data目录的访问权限。 -
调试访问:
-
开发者可以通过 Android Studio 的 Device File Explorer 工具查看
/data/data目录。 -
使用 ADB 命令(如
adb shell)也可以访问该目录,但需要设备开启 USB 调试模式。 -
修改权限:
-
如果设备被 Root,可以通过 ADB 命令修改
/data/data目录的权限。例如: -
但这种操作可能会带来安全风险,不建议在生产环境中使用。
检查移动客户端 APP 私有目录下的文件权限是否设置正确,非 root 账户是否可以读,写,执行私有目录下的文件。如果权限设置不正确,则可能导致恶意 APP 窃取目录下用户信息。
# 首先需要安装busybox
run tools.setup.busybox
# 查询公共读文件
run scanner.misc.readablefiles /data/data/<package_name>
# 查询公共写文件
run scanner.misc.writablefiles /data/data/<package_name>
检查 /data/data/APP包名 路径下除 lib 目录以外的文件权限,检查其他人是否能够读,写该路径下的目录,是否能够读,写,执行该路径下的文件。
cd /data/data/<package_name>
# 公共读文件
find .-type f -perm -o+r
# 公共写文件
find . -type f -perm -o+w
# 公共读写文件
find . -type f -perm -o+r -perm -o+w
# 公共可读或可写文件
find . -type f \( -perm -o+r -o -perm -o+w \)

自定义权限滥用¶
自定义权限的保护级别过低,导致任意应用程序都可以使用此权限,无法起到保护作用。
PendingIntent错误使用Intent风险¶
PendingIntent提供了一种特殊的异步处理机制,App可创建一个待处理的Intent给其他应用,并且允许这个应用以与自己相同的权限来执行这个Intent。即使创建Intent的原始App应用已经被关闭,其他应用在获取PendingIntent之后,仍可能对Intent进行修改,并以原始应用的权限与ID来执行修改后的恶意行为。这样可能导致原始App获取的系统权限和用户数据泄露,例如系统被恶意关闭,短信劫持,系统数据删除,甚至应用中涉及的用户数据被恶意篡改,或者执行恶意操作如转账、发送信息等。
Activity风险¶
Android 中的每个程序都是由基本组件如 Activity、Service、content Provider 和 Broadcast Receiver 等所组成,而作为实现应用程序的主体的 Activity 承担着大量的显示和交互工作,甚至我们可以理解为一个「界面」就是一个 Activity。既然 Activity 这么重要,如果 Activity 组件存在问题那么就可能会被系统或者第三方的应用程序直接调出并使用。而组件导出可能导致登录界面被绕过、信息泄露、数据库 SQL 注入、DOS、恶意调用等风险。
检查 AndroidManifest.xml 文件中注册的 Activity(MobSF),查看 exported 属性是否被设置为 true,若是则根据业务判断风险。

经检查io.dcloud.PandoraEntry设置exported为true

dz> run app.activity.start --component gait.com io.dcloud.PandoraEntry
# 后面的参数一个是 APP 的 packagename,一个是上图列出的具体内容,调用每一个组件,检查组件是否存在问题
使用dz直接调用组件

在登陆页面点击回退

可以回退到用户主页面,本来应该是直接退出应用回到系统桌面的
Content Provider风险¶
内容泄露漏洞¶
许多应用程序使用内容供应器来存储和查询应用程序中的数据或来自电话的数据。 除非已经定义了内容提供者可以使用权限来访问,否则任何其他应用都可以使用应用所定义的内容供应器,来访问应用的数据。 所有内容供应器具有唯一的统一资源标识符(URI)以便被识别和查询。 内容提供者的 URI 的命名标准惯例是以content://开始。
如果 Android API 版本低于 17,则内容供应器的默认属性是始终导出。 这意味着除非开发人员指定权限,否则任何应用程序都可以使用应用程序的内容供应器,来访问和查询数据。 所有内容供应器都需要在AndroidManifest.xml中注册。 因此,我们可以对应用程序使用 Apktool,并通过查看AndroidManifest.xml文件检查内容供应器。

随后访问content,看是否能够访问

提示权限错误,表明无内容泄露漏洞,若是访问成功,说明存在漏洞
文件遍历漏洞¶
Android 中 Content Provider 可能存在文件目录遍历安全漏洞,该漏洞源于对外暴露 Content Provider 组件的应用没有对 Content Provider 组件的访问进行权限控制和对访问的目标文件的 Content Query Uri 进行有效判断,攻击者利用该应用暴露的 Content Provider 的 openFile() 接口进行文件目录遍历以达到访问任意可读文件的目的。在使用 Content Provider 时,将组件导出提供了 query 接口,由于 query 接口传入的参数直接或间接由接口调用者传入,攻击者构造 SQL Injection 语句,造成信息的泄漏甚至是应用私有数据的恶意改写和删除。攻击者利用文件目录遍历访问任意可读文件、查看本地数据库内容等。
检查 AndroidManifest.xml 文件中注册的 Content Provider(MobSF),Content Provider 组件在 API-17(android4.2) 及以上版本由以前的 exported 属性默认 ture 改为默认 false。


Intent组件隐式调用风险¶
Intent有两种调用方式,分别为显式调用和隐式调用。当使用隐式的Intent调用时,并未对intent消息接收端进行限制,因此可能存在该消息被未知的第三方应用劫持的风险。Intent消息被劫持,可能导致用户的敏感数据泄露,或者恶意程序执行等风险。
Service风险¶
检查 AndroidManifest.xml 文件中注册的 Service(MobSF),查看有没有 export 的 Service,查看 Service 类, 重点关注 onCreate/onStarCommand/onHandleIntent 方法,检测有没有处理不当的方法
检索所有类中 startService/bindService 方法及其传递的数据,检测是否有数据泄露的可能
dz> run app.service.info -a gait.app
dz> run app.service.start --component com.package xxx.xxx.xxx

数据安全检测¶
输入监听风险¶
应用程序中的敏感信息通常主要来源于使用者的直接输入,如果用户的输入数据被监听或者按键位置被记录,很可能导致用户的输入数据被获取,其中的账号、密码等隐私信息泄露。而Android系统的默认输入键盘中通常都面临数据监听的风险。
键盘劫持测试¶
检查移动客户端 APP 在输入密码等敏感信息时是否使用了自定义软键盘。Android 应用中的输入框默认使用系统软键盘,如果目标手机被安装了木马,木马可以通过替换系统软键盘,记录应用的敏感信息输入。
推荐keylogger工具,下载链接:Download Keylogger latest 27 Android APK

安装后提示打开无障碍模式,打开后就能够抓取到app的键盘记录

当用户在app输入时,能够抓取到对应的键盘记录(但在这里没有抓取到密码)
系统底层击键记录¶
拥有 root 权限后,安卓木马可以通过读取系统文件/dev/input/eventN 得到键盘码,从而获得用户输入。注意:目前很多 android 系统不再向 event 文件输出键盘码,如需测试需先确定键盘输入对应的 event 文件是否存在

在 Linux 系统中,所有输入设备(如键盘、鼠标、触摸屏、游戏手柄等)的底层交互都通过
/dev/input/event*系列设备文件实现。这些文件是内核与用户空间之间传递输入事件的“桥梁”,提供了对原始输入数据的直接访问。
我们可以通过查看/proc/bus/input/devices查看每个已注册的输入设备信息

若要将event解析为可读形式,可以使用evtest工具
WebView储存安全¶
在进行WebView存储时,没有显示设置WebView.getSettings().setSavePassword(false),默认情况下,该值为true。在用户输入密码时,会弹出提示框:询问用户是否保存密码;
如果选择”是”,密码会被明文保到 /data/data/com.package.name/databases/webview.db 中,这样就有被盗取密码的危险
界面切换保护¶
检查移动客户端 APP 在切换到后台或其他应用时,是否能正确响应(如清除表单或退出会话等),防止用户敏感信息泄露。如果没有设置则可能造成用户敏感信息泄露。
主要测试两个方面:
- 输入登录密码后,切换到其他应用,再切换回来,查看是否会将用户输入的密码等敏感信息清空。
- 登录之后,切换到其它应用,过一段时间切换回来,查看当前会话是否会退出。
经测试,输入登陆密码后,切换到其他应用,在切换回来,应用并没有将用户输入的密码等敏感信息清空
验证码类型¶
检查移动客户端 APP 使用的验证码的安全性是否够强,如图片验证码在客户端验证,或图片验证码可被其他程序识别等,这些都会造成验证码失效。
使用 pytesser 编写脚本尝试进行验证码识别,检查验证码是否可被程序轻易识别,还要检查验证码是否存在其他失效的方式。
下图数据包中验证码就是在客户端验证,可以抓包重放验证码,这样就可以对密码进行爆破从而绕过验证码的限制了。
验证码识别爆破工具:f0ng/captcha-killer-modified: captcha-killer的修改版,支持关键词识别base64编码的图片,添加免费ocr库,用于验证码爆破,适配新版Burpsuite
UI 敏感信息泄露¶
检查移动客户端 APP 的各种功能否存在敏感信息泄露问题,如果有则可能造成用户的敏感信息泄露。
查看 APP 的各界面是否对用户的真实姓名、身份证号、银行卡号、手机号等用户个人敏感信息进行适当遮掩处理。
主流 APP 都是以部分敏感信息星号进行显示。
手势密码修改策略¶
检查移动客户端 APP 在取消手势密码时是否会验证之前设置的手势密码,是否存在其他导致手势密码取消的逻辑问题,如果存在则可能会导致手势密码被非法修改。
测试方法和密码修改的类似可以参考,主要还是看手势密码修改时是否有对旧手势进行验证,以及设置新手势密码的安全性,有一点还需要注意的就是查看手势密码在数据包中存在的形式,看是否存在规律或者可以破解等。
手势密码锁定策略¶
检查移动客户端 APP 是否存在手势密码多次输入错误被锁定的安全策略,以防止木马使用穷举法暴力破解用户密码。因为手势密码的存储容量非常小,一共只有 9! = 362880 种不同手势,若手势密码不存在锁定策略,可以轻易跑出手势密码结果,手势密码在输入时通常以 a[3][3] 这种 4*4 的二维数组方式保存,在进行移动客户端 APP 同服务器的数据交互时通常将此二维数组中数字转化为类似手机数字键盘的 b[15] 这种一维形式,之后再进行一系列的处理进行发送,如果没有设置手势密码的锁定策略,那么攻击者可通过穷举方式破解手势密码。
抓取手势密码的数据包,查看手势密码发送的形式,根据手势密码的参数看是否可以进行爆破,如果可以爆破则通过穷举方式破解手势密码。
手势密码绕过风险¶
剪切板敏感信息泄露风险检测¶
Android剪切板在后台可以暂存数据。如果把敏感数据(如密码)存放在剪贴板中是不安全的,因为所有的应用都可以访问剪切板中的数据,并且可以进行任意修改。如果用户复制的是明文敏感数据,那么其它应用通过访问剪贴板就可以获取到该明文数据了,甚至可以通过监听剪切板中的内容来获取信息。
检测方法:复制密码手机号等敏感信息,打开剪贴板查看是否有记录
HTTP数据传输风险¶
使用http协议通信,通信数据容易被恶意攻击者拦截并利用,导致用户敏感数据泄漏。
VPN连接建立风险¶
发送与接收的数据会通过VPN服务提供商的机器,用户的账号、密码、信用卡信息等有被VPN服务提供商看到的风险。
Internal Storage数据全局可读写风险检测¶
Internal Storage作为Android系统的本地数据存储方式之一,可将应用数据直接存储于设备的内部存储器中。当使用Internal Storage方式在创建本地存储文件时,如果使用了MODE_WORLD_READABLE模式,或者使用了MODE_WORLD_WRITEABLE模式,或者配置了“android:sharedUserId”属性值时,可能导致储存于Internal Storage文件中的敏感信息被其他程序读写,导致应用内明文存储的个人身份信息、密码以及token等重要敏感信息泄露,或者存储的用户信息、历史数据被篡改,诱导用户误操作等。
检测方法:检查/data/data/
cd /data/data/<package_name>
# 公共读文件
find .-type f -perm -o+r
# 公共写文件
find . -type f -perm -o+w
# 公共读写文件
find . -type f -perm -o+r -perm -o+w
# 公共可读或可写文件
find . -type f \( -perm -o+r -o -perm -o+w \)
StrandHogg漏洞¶
StrandHogg是一个存在于Android多任务系统中的应用漏洞。此漏洞利用APP清单文件AndroidManifest.xml中android:taskAffinity的属性设置,使安装在Android设备上的恶意应用可以伪装成该设备上的任意其他应用程序,包括需要特权的任意系统应用程序。当用户点击正常应用图标时,恶意程序可以拦截劫持这个任务,并伪装成正常应用程序的界面,从而窃取用户的敏感数据。同时恶意应用程序还可以冒充正常应用向用户请求权限,包括SMS、照片、麦克风和GPS等,从而允许攻击者访问短信和通讯录、查看相册、窃听并跟踪受害者等。
检测方法:
目标应用的启动模式¶
- 目标应用的
launchMode必须是standard或singleTop,因为只有这两种模式的 Activity 才可能被劫持。 - 如果目标应用的 Activity 使用了
singleTask或singleInstance启动模式,恶意应用无法通过 StrandHogg 漏洞将其 Activity 注入到目标应用的任务栈中。
恶意应用的配置¶
- 恶意应用需要在其
AndroidManifest.xml文件中配置特定的属性: taskAffinity:恶意 Activity 的taskAffinity属性需要设置为目标应用的包名。allowTaskReparenting:恶意 Activity 的allowTaskReparenting属性需要设置为true,以便在目标应用的任务栈被带到前台时,恶意 Activity 可以被重新分配到目标应用的任务栈中。

AES/DES弱加密风险¶
应用程序在使用AES/DES加密算法时采用了ECB模式。此种加密逻辑较弱,容易被破解,增加敏感信息泄露的风险。
SSL 证书有效性检测¶
验证移动客户端 APP 和服务器之间是否存在双向验证机制,同时还需要确认此验证机制是否完善,是否能被绕过,服务器是否以白名单的方式对发包者的身份进行验证。如果手机中存在恶意程序,就可能会劫持数据,造成信息泄漏等风险。
使用抓包软件如 BurpSuite 进行代理抓包,检查抓包软件能否正常解密 HTTPS 的通信数据,如果能则说明 APP 未验证证书有效性。
将 BurpSuite 根证书导入手机,再使用 BurpSuite 进行代理抓包,检查抓包软件能否正常解密 HTTPS 的通信数据,若能则说明 APP 信任当前设备根证书。
Https双向校验漏洞¶
程序未使用https双向签名校验(未使用签名校验或者使用单向签名校验),通信数据容易被恶意攻击者截取并利用,导致用户敏感数据泄漏。
SQLite加密存储安全¶
应用程序把用户的敏感信息(如帐号、密码等)以明文或者弱加密的形式保存到SQLite数据库中,容易被攻击者获取并利用,导致敏感信息泄露。
# sqlite数据库通常位于/data/data/<package_name>/databases/
adb pull /data/data/<package_name>/databases/ <物理机目录>
随后使用图形化工具查看即可

SharedPreferences读写安全¶
应用程序在SharedPreference文件夹中创建数据存储文件时,设置为全局可读或可写,导致任意第三方应用都可以进行文件读写操作,增加了用户敏感信息泄漏的风险。
截屏攻击风险¶
截屏攻击是指对App应用运行中的界面进行截图或者录制。截图攻击的主要对象是Android应用中的身份认证、登录界面和资金操作界面。而在Android5.0中新增了屏幕录制接口,无需特殊权限,使用系统API (MediaProjection)即可实现屏幕录制,并且攻击程序可以通过自定义的字符覆盖掉系统的录屏提示,诱导用户在不知情的情况下启动屏幕录制功能。当恶意程序获取到应用截图或者屏幕录像后,将其发送给攻击者,攻击者便能直接查看或者还原手机界面的操作情况,从而轻而易举获取用户QQ、微信等应用的用户名及密码,甚至银行客户端中输入的银行账号及支付密码,导致用户的资金损失。
检测方法:在输入密码等敏感信息的页面尝试截屏,看是否允许截屏
SharedPreferences加密存储安全¶
SharedPreferences文件夹主要用于存储程序数据,当敏感信息(帐号、密码等)被明文保存,容易被攻击者获取并利用。
通常该文件路径为/data/data/<your_app_package_name>/shared_prefs/,虽然该文件夹为app的私有文件,但root用户是可以访问的
调试日志函数泄漏敏感数据漏洞¶
应用程序在运行过程中把用户的敏感数据以Log(日志)的形式输出,容易被第三方恶意应用获取并利用。
为了精确获取目标应用的日志,我们需要先找到应用名

随后通过应用名获取pid

pid为4324
adb logcat -d
# 抓取所有应用的日志
adb logcat -d --pid=4324
# 抓取pid为4324应用的日志
adb logcat -d --pid=4324 > gait_app.log
# 保存为特定文件
随后app执行敏感操作(登陆,注册等),看是否日志中记录了密码等

RSA弱加密风险¶
使用RSA加密算法时使用“RSA/NONE/NoPadding”模式或者密钥长度小于1024bit可能会造成RSA算法的攻击。
SharedUserId属性设置风险检测¶
SharedPreferences作为Android系统的本地数据存储方式之一,可将应用数据以键值对(key-value)的存储形式永久保存于App应用中。当使用SharedPreferences方式在创建本地存储文件时,如果使用了MODE_WORLD_READABLE模式,或者使用了MODE_WORLD_WRITEABLE模式并且配置了“android:sharedUserId”属性值时,可能导致储存于SharedPreferences文件中的敏感信息被其他程序读写,导致应用内明文存储的个人身份信息、密码以及token等重要敏感信息泄露,或者存储的用户信息、历史数据被篡改,诱导用户误操作等。
使用ls查看其目录权限即可

getDir数据全局可读写漏洞¶
Context.getDir(String name , int mode)是访问Android系统的Internal Storage的一个重要方式,用于在应用程序的数据文件夹下获取或者创建一个存放应用程序自定义文件的文件夹。当该函数的第二参数使用了MODE_WORLD_READABLE模式,或者使用了MODE_WORLD_WRITEABLE模式,或者配置了“android:sharedUserId”属性值时,可能导致储存于该文件夹中的敏感信息被其他程序读写,导致应用内明文存储的个人身份信息、密码以及token等重要敏感信息泄露,或者存储的用户信息、历史数据被篡改,诱导用户误操作等。更为严重的是具备root权限的程序或用户可对所有应用程序通过任意模式(包括MODE_PRIVATE)创建的文件夹进行读写操作。
SDCard数据安全¶
外部存储的访问权限¶
从 Android 6.0(API 级别 23)开始,外部存储(包括 SDCard)的访问需要动态申请权限。应用需要在 AndroidManifest.xml 中声明以下权限:
android.permission.READ_EXTERNAL_STORAGE:用于读取外部存储中的文件。android.permission.WRITE_EXTERNAL_STORAGE:用于写入外部存储中的文件。

在运行时,应用需要通过 ActivityCompat.requestPermissions() 方法动态请求这些权限。
文件权限的默认设置¶
在 SDCard 中创建的文件,默认的权限通常是:
- 文件所有者(通常是创建文件的应用)具有读写权限。
- 其他用户(其他应用或系统用户)可能具有读权限,但不一定有写权限。
例如,一个应用在 SDCard 上创建的文件,默认权限可能是:
rw-:文件所有者具有读写权限。r--:其他用户具有只读权限。
应用程序把用户的敏感信息(如帐号、密码等)以明文或者弱加密的形式保存到SD卡中,容易被恶意攻击者获取并利用,导致敏感数据泄露。
检测方法:
通信数据安全¶
敏感通信数据(如银行卡号、密码等)明文或者弱加密后传输,容易被恶意攻击者拦截并利用,导致敏感信息泄露。
明文数字证书风险¶
明文存储的数字证书存在被篡改的风险,容易导致客户端与服务端之间的传输数据被截获,造成用户敏感信息泄露。
应用内部存储文件安全¶
应用程序在创建应用内部存储文件时,设置为全局可读或可写,导致任意第三方应用都可以进行文件读写操作,增加了用户敏感信息泄漏的风险。
SQLite读写安全¶
应用程序在创建SQLite数据库文件时,设置为全局可读或可写,导致任意第三方应用都可以进行文件读写操作,增加了用户敏感信息泄漏的风险。
安全漏洞检测¶
so包含执行命令函数风险¶
在native程序中,有时需要执行系统命令,在接收外部传入的参数执行命令时没有做过滤或检验。攻击者传入任意命令,导致恶意命令的执行。
“寄生推”云控漏洞¶
“寄生推”SDK预留的“后门”,可以通过云端控制的方式对目标用户动态更新下发包含恶意功能的代码包,Root用户手机,植入恶意应用到用户设备系统目录,进行恶意广告行为和应用推广,以达到牟取灰色收益的目的。
WebView远程代码执行安全¶
在Android4.2版本以前,由于没有正确限制使用WebView.addJavascriptInterface方法,攻击者可通过使用Java 反射调用机制远程执行任意Java代码。攻击者利用该漏洞可控制客户端,对客户端进行远程操控、获取敏感数据、增加/删除数据等。
访问控制¶
检查移动客户端 APP 访问的 URL 是否只能通过手机移动客户端访问。是否能够绕过登录限制直接访问到登录后才能访问的页面,对需要二次验证的页面如密码验证、私密问题验证等,能否绕过这些验证。如果允许 PC 端访问则会降低漏洞利用难度,如果能绕过限制条件则可能造成敏感信息泄露和数据被篡改的风险。
检测方法:抓取移动客户端 APP 的数据包,并使用 PC 去访问移动端 URL,查看是否能使用 PC 正常访问获取数据。
本地拒绝服务攻击¶
应用程序在编写过程中没有对Intent.getXXXExtra()这类方法调用进行异常的捕获,攻击者可以通过发送空数据、异常数据或畸形数据使程序崩溃,从而造成拒绝服务攻击。
动态注册广播暴露风险¶
应用程序使用registerReceiver动态注册的广播默认对外暴露,暴露的广播容易出现拒绝服务、数据泄漏或越权调用等漏洞。
随机数使用不当风险¶
下面两种情况会导致随机数漏洞(影响Andorid4.2以下版本)1.在调用SecureRandom类时采用SecureRandom(byte[] seed)进行构造2.生成随机数之前调用setSeed(long seed)或者setSeed(byte[] seed)该漏洞会造成后续随机数容易被猜测,即随机数不再随机,从而导致使用该随机数的加密逻辑不再安全。
不安全的浏览器调用漏洞¶
Chrome V8引擎3.20至4.2版本中存在远程代码执行漏洞(CNNVD-201608-414)。该漏洞是由于源代码中“observe_accept_invalid”异常类型被误写为“observe_invalid_accept”,造成kMessages关键对象信息泄露,从而可利用该漏洞执行任意代码。远程攻击者可通过诱使用户扫描二维码或者诱使用户点击恶意链接对应用进行攻击,可能导致用户隐私泄露,如通讯录,短信,录音,录像等;用户财产损失,如窃取支付密码、钱包密码等;远程控制手机等。
未移除有风险的webview系统隐藏接口¶
Android WebView组件包含3个隐藏的系统接口:searchBoxJavaBridge_, accessibilityTraversal以及accessibility,恶意程序可以利用它们实现远程代码执行。
Intent scheme url漏洞¶
Intent Scheme URL是一种特殊的URL格式,用来通过Web页面启动已安装应用的Activity组件,大多数主流浏览器都支持此功能。当对Intent URL的处理不当时,会引起拒绝服务,甚至可能演变为提权漏洞。
临时文件未删除风险¶
移动应用程序创建临时文件默认为私有,但是为保证安全性推荐删除。
动态加载so文件风险¶
出于节省Apk包大小,或者动态升级so文件的原因,App程序可能将部分so文件存储或者下载于sdcard上,然后进行动态加载。为成功动态加载so文件,App首先将so文件读取到应用私有目录下,再使用system.load函数加载该目录下的so文件,并且该目录是应用私有目录(/data/data/\<packagename>/)下的非默认lib库文件夹。该过程中APP动态加载了存储在sdcard上的so文件,如果存储的so文件被存在恶意行为的so文件替换,将会导致恶意代码执行。常见的恶意代码,可能导致登录账号、密码、支付密码被窃取,恶意扣费,病毒注入等风险。
Zip文件目录遍历漏洞¶
由于zip压缩包文件中允许存在“../”的字符串,攻击者可以利用多个“../”在解压时改变zip包中某个文件的存放位置,覆盖掉应用原有的文件。如被覆盖掉的文件是动态链接so、dex文件,可能造成任意代码执行等危害用户的设备安全和信息安全的漏洞。
FFmpeg文件读取漏洞¶
FFmpeg是一个用来记录、转换数字音频、视频,并能将其转化为流的开源库,在FFmpeg的某些版本中存在本地文件读取漏洞,可以通过构造恶意文件获取本地文件内容。
HTTPS关闭主机验证¶
应用程序在数据通信时,使用了信任任意主机名的参数ALLOW_ALL_HOSTNAME_VERIFIER,即对任意主机均不进行证书校验,容易被中间人攻击,增加敏感信息泄漏的风险。
Socket端口开放风险¶
移动客户端 APP 通常使用 PF_UNIX、PF_INET、PF_NETLINK 等不同 domain 的 socket 来进行本地 IPC 或者远程网络通信,这些暴露的 socket 暴露出了潜在的本地或远程攻击面,历史上也出现过不少利用 socket 进行拒绝服务、root 提权或者远程命令执行的案例。特别是 PF_INET 类型的网络 socket,可以通过网络与 Android 应用通信,其原本是用于 Linux 环境下开放网络服务,由于缺乏对网络调用者身份或者本地调用者 id、permission 等细粒度的安全检查机制,如果实现不当,就可以突破 Android 的沙箱限制,使用被攻击应用的权限执行命令,出现比较严重的漏洞。
在 Android 系统中输入以下命令查看本地端口开放情况,是否开启了危险的服务。

Webview file域同源策略绕过漏洞¶
恶意应用利用该漏洞,可在无特殊权限的情况下盗取应用的任意私有文件,尤其是浏览器,可利用该漏洞,获取到浏览器所保存的密码、Cookie、收藏夹以及历史记录等敏感信息,造成敏感信息泄露。
应用克隆¶
Android WebView(网络视图)是安卓平台上用来显示html文本内容的控件。 Android WebView存在跨域访问漏洞。该漏洞产生的原因是由于Android应用WebView开启了file域访问,且允许file域访问http域,未对file域的路径做严格限制所致。攻击者可以利用漏洞,远程获取APP中的所有本地敏感数据。
UnityGhost漏洞¶
使用了被篡改的Unity开发工具,导致开发的应用被嵌入了恶意代码,造成用户信息被盗取。
WebView组件忽略SSL证书验证错误漏洞¶
Android WebView组件加载网页发生证书认证错误时,会调用WebViewClient.onReceivedSslError方法,如果该方法调用了handler.proceed()来忽略该证书错误,容易受到中间人攻击,导致隐私泄露。
libupnp栈溢出¶
应用程序使用低于1.6.18版本的libupnp库,易构造恶意数据包造成缓冲区溢出。
下载任意apk¶
具有下载apk功能的组件存在导出漏洞,攻击者可以利用该漏洞下载任意apk文件,用户会被诱导安装恶意软件,导致隐私泄露、资产受损等风险。
Android数据库注入¶
攻击者将恶意SQL命令注入后台数据库,如果程序对攻击者输入的数据未做判断,将导致用户隐私泄露或数据丢失,甚至导致拒绝服务及主机被远程控制。
私有函数调用风险检测¶
Android系统级API中包含大量的类,这些底层类共有的API可以直接被调用。调用系统未开放的私有API需要突破系统的限制,使用反射调用能够做到。Google之所以将有些API隐藏,可能是因为这些API属于内部逻辑,不能对外暴露;也有可能是API接口还未最终确定下来。所以在低版本Android系统上的隐藏API不一定能在高版本的Android上使用,也就说隐藏API的兼容性比较差,调用私有函数可能导致应用兼容性、稳定性方面的问题。
Fragment注入漏洞¶
应用程序在调用PreferenceActivity子类时,数据没有正确处理或未经目标应用的验证,导致出现Fragment注入漏洞。恶意第三方应用可以通过该漏洞加载目标应用的任意类,危害极大。
Janus漏洞¶
攻击者利用Android加载执行代码只认文件头和安装验证签名只认文件尾的机制,构造apk,改造或者替换攻击者想要执行的dex文件,利用漏洞覆盖安装原官方应用。
动态加载DEX文件风险¶
应用程序在代码中调用DexClassLoader加载外部的 apk、jar 或 dex文件,当外部文件的来源无法控制或是被篡改时,无法保证加载文件的安全性。
Android 系统提供的一种类加载器 DexClassLoader 可以在运行时动态加载并解释执行包含在 JAR 或 APK 文件内的 DEX 文件。外部动态加载DEX文件的安全风险源于:Anroid4.1 之前的系统版本容许 Android 应用将动态加载的 DEX 文件存储在被其他应用任意读写的目录中(如 sdcard),因此不能够保护应用免遭恶意代码的注入;所加载的 DEX 易被恶意应用所替换或者代码注入,如果没有对外部所加载的 DEX 文件做完整性校验,应用将会被恶意代码注入,从而执行的是恶意代码。
- dalvik.system
| BaseDexClassLoader | 基类,用于实现各种基于dex的 ClassLoader实现之间的通用功能。 |
|---|---|
| DexClassLoader | 从 .jar和 .apk文件中加载包含 classes.dex条目的类的类加载器。 |
| DexFile | 操作DEX文件。 |
| PathClassLoader | 提供一个简单的 ClassLoader实现,该实现对本地文件系统中的文件和目录列表进行操作,但不尝试从网络加载类 |
查看 AndroidManifest.xml 包 package 值对应路径下的文件中是否含有 DexClassLoader() 函数调用。

在jadx中使用全局搜索DexClassLoader
阿里云OSS凭证泄露¶
阿里云对象存储服务(OSS),是阿里云对外提供的海量、安全和高可靠的云存储服务,APP未根据官方建议对访问控制策略进行设置将导致该漏洞。攻击者利用该漏洞可获得APP OSS的控制权,进而远程获取云存储数据,并拥有创建、删除、上传、下载等操作权限,对APP服务运营方构成较为严重的信息泄露和运行安全风险。