OWASP MASTG 实战：在非 Root 安卓设备上进行动态分析（Frida Gadget 注入全流程指南）-开发者社区

文档
教程
网络安全

【免费下载链接】mastg

The OWASP Mobile Application Security Testing Guide (MASTG) is a comprehensive manual for mobile app security testing and reverse engineering. It describes technical processes for verifying the OWASP Mobile Security Weakness Enumeration (MASWE) weaknesses, which are in alignment with the OWASP MASVS.

项目地址：https://gitcode.com/gh_mirrors/ow/mastg

点击查看免费下载

导读

本文基于 OWASP MASTG（Mobile Application Security Testing Guide）的 MASTG-TECH-0026 技术条目，系统讲解在没有 Root 权限的 Android 真机上开展动态安全分析的完整方案：通过补丁重打包 APK、注入 Frida Gadget 动态库，从而在非 Root 设备上驱动 Frida 与 objection 进行运行时测试。读完本文，你将掌握从获取 APK、注入动态库、重新签名到安装部署的完整链路，并理解每条命令背后的 Android 平台机制（签名校验、Zygote 启动流程、库加载原理）。

一、背景：为什么非 Root 设备也能做动态分析

在移动应用安全测试中，Root/Jailbreak 设备是首选——它们可以自由附加 Frida Server、访问应用沙箱数据、hook 系统调用。但在实际项目中，你可能只有一台未 Root 的普通设备，甚至目标应用包含 root 检测，在 Root 设备上根本无法正常运行。

此时可行的思路是：对目标 APK 进行补丁和重打包，让它在启动时加载一个动态库（例如 Frida Gadget），从而在不依赖 Root 的情况下获得与 Frida 同等能力的注入式动态测试环境。

MASTG 明确指出，这一方案在 Android 上之所以可行，关键原因在于平台差异：

Android 应用没有 iOS 那样的 FairPlay 加密，你可以直接从设备上提取 APK（无需 Root），也可以从第三方应用商店下载原始 APK；
补丁后的 APK 只需使用标准调试证书重新签名即可安装，不需要开发者账号或特殊证书；
Frida 提供两种运行模式，其中Injected 模式需要目标设备上运行 Frida Server（通常需要 Root），而Gadget 模式将 Frida 运行时以动态库形式内嵌进应用进程，天然适合非 Root 场景。

这正是 MASTG-TECH-0041（Library Injection）所描述的核心思想：通过库注入，可以把可复用的注入库打进不同应用，让它们"行为改变"而无需修改原始源码——这与 Windows 的 DLL 注入、Linux 的LD_PRELOAD、macOS 的DYLD_INSERT_LIBRARIES属于同一族技术。

库注入的典型应用场景

根据 MASTG-TECH-0041，库注入在安全测试中的价值覆盖以下场景：

进程内省：枚举类、追踪方法调用、监控文件访问与网络访问、直接读写内存；
替换现有代码：例如替换随机数生成函数，验证应用对弱随机数的依赖；
为既有应用引入新能力：动态加载自定义模块；
调试无源码的疑难运行时 bug；
在非 Root 设备上启用动态测试（例如搭配 Frida）。

二、路线选择：Android 模拟器 vs 非 Root 真机

在动手之前，先明确两条路线，它们的操作复杂度差异巨大。

2.1 Android 模拟器：最简单快捷的起点

MASTG-TECH-0026 特别强调：对于研究者和学习者，Android Emulator 往往是最简单的切入点。模拟器中运行的应用不受物理设备硬件级限制的约束，你可以：

直接使用frida -U附加进程，无需注入 Frida Gadget；
无需补丁 APK，也无需重新签名；
非常适合实验、脚本编写和动态分析技术的学习演练。

但必须清醒认识模拟器的局限——它无法完美复现真实设备行为，尤其以下方面：

TEE/StrongBox 等硬件支持的密钥存储；
生物识别（指纹、人脸）等硬件相关能力；
部分硬件标识符；
反模拟器检测与 root 检测逻辑（部分应用在模拟器中根本无法正常运行）。

因此，模拟器适合"练技术"，真实设备才适合"验结论"。下文 3~6 节的四步流程，针对的是真实非 Root 设备。

2.2 非 Root 真机：四步标准流程

对于真实设备，标准流程分为四步，每一步都有对应的 MASTG 技术条目：

步骤	目标	对应技术条目
Step 1	获取目标应用 APK	MASTG-TECH-0003
Step 2	补丁 APK 并注入 Frida Gadget	MASTG-TECH-0041 / MASTG-TECH-0004
Step 3	重新签名补丁后的 APK	MASTG-TECH-0039
Step 4	安装重签名 APK 并开始动态测试	MASTG-TECH-0005

下面逐一展开。

三、Step 1：获取 APK

获取 APK 有多种途径，选择哪种取决于目标应用是公开应用还是私有应用。详细方法见 MASTG-TECH-0003。

3.1 替代应用商店下载（公开应用）

最简单的方式是从镜像 Google Play 公开应用的网站下载 APK。需要注意：这些站点并非官方渠道，无法保证应用未被重打包或植入恶意代码。MASTG 提到 APKMirror、APKPure 等站点相对可信，会列出应用的 SHA-1/SHA-256 校验和，但仍然强调"你无法控制这些站点，也无法保证它们未来的行为，仅在别无选择时使用"。

此外，部分替代商店提供的是XAPK 格式（一种将 APK 与附加数据文件打包在一起的 ZIP 归档），可参考 MASTG-TECH-0145 学习如何解包处理。

3.2 命令行工具下载（适合自动化）

MASTG-TECH-0003 提供了两条适合脚本化的下载路径：

gplaycli（MASTG-TOOL-0016）——通过指定 AppID 下载 APK，-p显示进度条、-v输出详细信息：

$ gplaycli -p -v -d com.google.android.keep [INFO] GPlayCli version 3.26 [Python3.7.4] [INFO] Configuration file is ~/.config/gplaycli/gplaycli.conf [INFO] Device is bacon [INFO] Using cached token. [INFO] Using auto retrieved token to connect to API [INFO] 1 / 1 com.google.android.keep [################################] 15.78MB/15.78MB - 00:00:02 6.57MB/s/s [INFO] Download complete

执行后当前目录下会出现com.google.android.keep.apk。gplaycli 支持使用你自己的 Google Play 凭据或 token（默认使用其内置提供的 fallback token）。

apkeep（MASTG-TOOL-0148）——按包名下载最新版本：

apkeep -a com.google.android.keep .

apkeep 还支持下载指定版本与拆分 APK：

# 下载指定版本 apkeep -a com.google.android.keep@5.21.361.03 . # 下载 App Bundle 对应的全部拆分 APK apkeep -a com.google.android.keep -d .

apkeep 对自动化场景尤其友好，下载免费应用时无需认证。

3.3 从设备直接提取（推荐，可保证来源纯净）

MASTG 推荐使用设备提取法，因为可以保证应用未被第三方篡改。无论设备是否 Root，都可以用 adb 完成：

# 1. 列出设备上所有已安装应用的包名 adb shell pm list packages # 2. 查询目标应用 APK 在设备上的完整路径 adb shell pm path <package name> # 3. 将 APK 拉取到本地工作目录 adb pull <apk path>

此外，还有不需要 Root、甚至无需连接电脑的图形化工具（如 APK Extractor），可以直接将提取的 APK 通过分享功能传出，适合不方便连接设备或配置网络传输的场景。

四、Step 2：注入 Frida Gadget（补丁 APK）

这是整个流程的技术核心。根据 MASTG-TECH-0041，Android 上的库注入主要有三条技术路线，Frida Gadget 的注入是它们的典型应用。

4.1 路线 A：补丁 Smali 代码，调用 System.loadLibrary

将应用反编译后的 smali 代码补丁，插入一段调用System.loadLibrary的指令，使其加载名为libinject.so的库：

const-string v0, "inject" invoke-static {v0}, Ljava/lang/System;->loadLibrary(Ljava/lang/String;)V

实操要点（来自 MASTG-TECH-0041）：

这段代码越早插入越好，理想位置是应用生命周期的早期方法（例如 Activity 的onCreate），确保应用启动时即完成注入；
必须把libinject.so放入 APK 的lib目录下对应架构的子目录（armeabi-v7a、arm64-v8a、x86等）；
补丁完成后需要重新签名才能安装使用。

一个知名的应用案例正是本文的主角：在非 Root 设备上向应用加载 Frida Gadget——这本质上就是 objection 的patchapk命令所做的事。

4.2 路线 B：补丁原生库依赖（借助 LIEF）

很多 Android 应用使用原生（native）代码，以 ELF 共享库形式存在。ELF 文件头中记录了可执行文件依赖的共享库列表，修改这份列表即可向进程注入额外的库。手工修改 ELF 结构繁琐易错，但借助 LIEF（MASTG-TOOL-0034）只需几行 Python：

import lief libnative = lief.parse("libnative.so") libnative.add_library("libinject.so") # 注入！ libnative.write("libnative.so")

上述示例把libinject.so注入为应用默认加载的libnative.so的依赖项。与路线 A 相同，仍需把库放入 APK 对应架构的lib目录并重新签名。

4.3 路线 C：LD_PRELOAD 符号预加载

前两条路线都需要修改应用代码；第三条路线则利用操作系统加载器的能力。Android 基于 Linux，可以通过设置LD_PRELOAD环境变量额外加载库，且按 ld.so 的规则，通过LD_PRELOAD加载的库中的符号总是优先解析，从而"覆盖"原始符号实现——典型用途是包装（wrap）libc 函数（如fopen、read、write、strcmp）来记录输入参数，尤其适合理解混淆程序的行为。

但 Android 上设置LD_PRELOAD与普通 Linux 分发版略有不同：Android 的每个应用进程都从Zygotefork 而来，而 Zygote 在系统启动极早期就已运行，无法对 Zygote 直接设置LD_PRELOAD。MASTG 给出的变通方案是使用setprop设置系统属性（注意包名前缀wrap.）：

setprop wrap.com.foo.bar LD_PRELOAD=/data/local/tmp/libpreload.so

⚠️SELinux 限制：若待预加载的库没有被分配 SELinux context，从 Android 5.0（API level 21）起，需要关闭 SELinux 才能让LD_PRELOAD生效，而关闭 SELinux 通常需要 Root——这与本文"非 Root"前提相悖，因此该路线在非 Root 设备上使用受限，前两条注入路线才是主力。

4.4 实操：用 objection 一键补丁（推荐）

如果不想手工编辑 smali 或 ELF，MASTG-TECH-0004 提供了更省力的做法：在电脑上参照 objection 官方的 "Patching Android Applications" 流程，然后直接调用 objection 命令：

objection patchapk --source app-release.apk

objection（MASTG-TOOL-0038）自称是"由 Frida 驱动的运行时移动探索工具包"，其核心目标就是让安全测试可以在非 Root 设备上进行。它通过重打包把 Frida Gadget 注入应用，再以 sideload 方式部署到非 Root/非越狱设备，并提供 REPL 交互界面，能执行应用自身能执行的任何操作。其平台无关特性包括：

访问应用存储（下载/上传文件）；
执行自定义 Frida 脚本；
内存搜索、替换与导出；
任务控制（卸载 hook 与脚本）；
内联交互 SQLite 数据库；
支持自定义插件。

安装方式：

pip3 install objection

五、Step 3：重新签名

重打包会破坏原有签名，必须重新签名才能安装。MASTG-TECH-0039 给出了完整流程。

5.1 准备签名证书

如果你用 Android Studio 构建过项目，IDE 已在$HOME/.android/debug.keystore生成了调试密钥库与证书，其默认密码为android，密钥名为androiddebugkey。也可以使用 JDK 自带的keytool自建证书并加入调试密钥库：

keytool -genkey -v -keystore ~/.android/debug.keystore -alias signkey -keyalg RSA -keysize 2048 -validity 20000

5.2 用 apksigner 签名

确保apksigner在 PATH 中（它位于 Android SDK 的[SDK-Path]/build-tools/[version]目录，zipalign也在同目录），并在重打包 APK 所在目录下执行：

apksigner sign --ks ~/.android/debug.keystore --ks-key-alias signkey UnCrackable-Repackaged.apk

💡 标准 Android 调试密钥库即可满足需求，无需开发者账号或特殊证书——这是整个非 Root 方案可行性的重要基础。

5.3 备选：jarsigner

如果apksigner出现 JRE 兼容性问题，可改用jarsigner。注意此时zipalign必须在签名之后执行（与 apksigner 流程相反）：

jarsigner -verbose -keystore ~/.android/debug.keystore ../UnCrackable-Repackaged.apk signkey zipalign -v 4 dist/UnCrackable-Level1.apk ../UnCrackable-Repackaged.apk

5.4 重打包与对齐（apktool）

如果需要用 apktool 手工重打包（例如在 smali 补丁之后），MASTG-TECH-0039 给出了对应的构建与对齐命令：

cd UnCrackable-Level1 apktool b zipalign -v 4 dist/UnCrackable-Level1.apk ../UnCrackable-Repackaged.apk

六、Step 4：安装重签名后的应用

6.1 基本安装命令

使用 adb 安装（MASTG-TECH-0005）：

adb install ./myApp.apk

多设备场景下可指定目标设备：

# 安装到连接的物理设备 adb -d install ./myApp.apk # 安装到模拟器 adb -e install ./myApp.apk # 列出所有设备（含序列号） adb devices # 指定序列号安装 adb -s 37081JEHN05882 install ./myApp.apk

-g参数可在安装时自动授予所有运行时权限：

adb install -g ./myApp.apk

6.2 关键陷阱：签名变更导致安装失败

这是非 Root 方案最常见的坑：如果设备上已安装同包名的原版应用，Android 会比较新旧签名。签名不同（重打包必然改变签名）时安装会失败，报错形如：

adb install ./myRepackagedApp.apk adb: failed to install myRepackagedApp.apk: Failure [INSTALL_FAILED_UPDATE_INCOMPATIBLE: Existing package org.owasp.mastestapp signatures do not match newer version; ignoring!]

解决办法是先卸载原应用再安装：

# 按包名卸载原应用 adb uninstall org.owasp.mastestapp # 正常安装重签名版本 adb install ./myRepackagedApp.apk

6.3 进阶安装场景

MASTG-TECH-0005 还覆盖了两种进阶安装方式，在真实测试中同样有价值：

安装到特定用户 profile——需要先把 APK push 到设备（注意 push 到/sdcard/可能有权限问题，建议用/data/local/tmp），再用pm install --user指定用户：

# 查看可用 profile adb shell pm list users Users: UserInfo{0:Owner:c13} running UserInfo{11:Sample Managed Profile:1030} running # Push 到 /data/local/tmp/ adb push ./myApp.apk /data/local/tmp/ # 指定用户安装 adb shell pm install --user 11 /data/local/tmp/myRepackagedApp.apk

安装拆分 APK（split APK）——YouTube 等应用以拆分包形式分发，可用install-multiple安装：

adb shell pm path com.google.android.youtube # 输出 base.apk 及各 split_config.*.apk 路径 # 逐一拉取各组成部分 adb pull /data/app/~~ZLX3UNTF7R2oebU_viP7mw==/com.google.android.youtube-Rhm4GURIQ4twNvR6wxqc6w==/base.apk adb pull /data/app/~~ZLX3UNTF7R2oebU_viP7mw==/com.google.android.youtube-Rhm4GURIQ4twNvR6wxqc6w==/split_config.arm64_v8a.apk # ...（其余 split_config 文件同理） # 安装全部拆分 APK adb install-multiple base.apk split_config.arm64_v8a.apk split_config.en.apk split_config.xxhdpi.apk

6.4 安装后的动态测试

安装完成后，即可通过 objection 的 REPL 或自定义 Frida 脚本与注入的 Gadget 交互。得益于 Gadget 是应用进程的一部分，你可以在没有 Root 的情况下完成：Hook 任意 Java/原生方法、枚举类与 Activity、读写应用私有存储、绕过证书校验观察网络流量、动态修改返回值等，配合 objection 的存储访问、内存搜索与 SQLite 交互能力，几乎覆盖常规动态测试需求。

七、原理延伸：这条链路背后的 Android 机制

为便于排查问题，最后梳理一下整条链路上涉及的 Android 平台机制（均可从上述 MASTG 技术条目中找到对应论述）：

APK 提取无需 Root：Android 的pm（Package Manager）通过pm path可查询任意已安装应用的存储路径，配合adb pull即可完整导出，这是 Step 1 可行性的来源；
签名校验决定能否覆盖安装：Android 安装器强制校验签名一致性，签名变更触发INSTALL_FAILED_UPDATE_INCOMPATIBLE，必须卸载原应用（Step 4 的坑源自此）；
Zygote 与进程模型：所有应用进程 fork 自 Zygote，导致LD_PRELOAD在 Android 上必须借助wrap.属性变通实现（Step 2 路线 C 的原理）；
动态库加载机制：无论是 smali 层System.loadLibrary、ELF 依赖注入（LIEF）还是符号预加载，最终都归结为让注入库随应用进程启动而加载——这正是 Frida Gadget 能在非 Root 环境下工作的根本原因。

八、小结

MASTG-TECH-0026 给出了一个完整的、可落地的非 Root Android 动态分析路线：获取 APK（MASTG-TECH-0003）→ 注入 Frida Gadget（MASTG-TECH-0041/0004）→ 重新签名（MASTG-TECH-0039）→ 安装（MASTG-TECH-0005），全程仅需一台电脑、一台非 Root 设备与 adb/Frida/objection 等常规工具。模拟器则提供了零补丁的快速上手路径。这套方法在 MASTG 中与 iOS 侧的动态分析条目互为对照，共同构成了"无越狱/无 Root 环境下的动态测试"完整方法论，也是后续开展反逆向韧性测试时绕过 root 检测、Hook 关键逻辑的基础能力。