企业官网建设流程全解析

• 文档
• 教程
• 网络安全

导读：Finstergram 是 OWASP MASTG 收录的一款 Android 安全教学应用，外形是一个需要密码才能打开的"照片保险库"，内部却埋设了多处常见漏洞。本文以 MASTG-APP-0016.md 描述的挑战设定为主线，结合 MASTG 仓库中的测试用例、自动化规则与工具链，系统讲解在非 root 手机上仅凭静态分析、广播与 Intent 攻击面突破应用密码、进入 secret gallery 的完整方法论。读完本文，你将掌握从 AndroidManifest 审计、密码校验逻辑定位到广播接收器与组件间通信利用的实战套路。

Finstergram：为教学而生的"伪安全"照片保险库

Finstergram 是一款刻意内置安全漏洞的 Android 应用，其定位与 OWASP MASVS（Mobile Application Security Verification Standard）的安全测试体系直接呼应。按 apps/index.md 的说明，MASTG 所列参考应用可作为训练材料，其中 MASTG apps 与 Crackmes 由 MAS 项目负责测试与维护，Finstergram 正是其中之一。

从功能上看，Finstergram 扮演着"照片保险库"（photo vault）的角色：用户需要输入密码才能打开其中的秘密相册（secret gallery），表面上防止手机上的其他使用者查看照片。然而正如文档所提示的，这套安全机制并不像看起来那么可靠——它的存在价值恰恰是暴露"本地密码保护"这类方案的常见实现缺陷。

挑战设定与攻击前提

官方挑战给出了一个非常贴近真实威胁模型的场景：

• 你拥有一台未 root的手机，且手机上已安装 Finstergram；
• 你可以正常解锁手机（知道锁屏密码），但不知道应用内的密码；
• 目标：通过分析 Finstergram 的代码找出漏洞，从而绕过密码访问 secret gallery。

文档同时给出了四条官方提示的初始攻击思路，这也是本文展开的四个核心攻击面：

1. 检查 AndroidManifest 文件；
2. 理解密码是如何被校验的；
3. 调查广播（broadcast）机制；
4. 探索如何利用 Intent。

非 root 前提意味着无法直接读取/data/data/<package>下的私有目录，因此攻击重心应放在应用自身暴露的组件、错误的密码实现逻辑以及可被外部触发的 IPC 通道上——这些恰恰是 Android 应用最常见的高危缺陷。

起步：构建应用并搭好分析工具链

文档建议直接使用 Android Studio 打开并构建项目。构建产物是一个可安装的 APK，后续所有分析都围绕这个 APK 展开。建议在动手前先备齐三件套工具：

其中 MASTG-TOOL-0018（jadx-gui）是静态分析阶段的主力：把 APK 拖入即可浏览反编译出的 Java 代码与 manifest 信息，适合追踪密码校验函数与广播接收器的实现：

提示：MASTG 工具目录（tools/android、tools/generic）对每个工具都提供了独立的安装与用法说明，实战前可按需查阅。

攻击面一：先读 AndroidManifest.xml，绘制组件攻击面地图

AndroidManifest.xml 是应用对外暴露能力的"地图"。文档的第一条提示即指向它——因为所有可被外部应用触达的入口都必须在这里声明。对应 MASTG 的测试体系，这一步主要落在 MASTG-TEST-0029.md（IPC 组件测试）与 MASTG-TEST-0024.md（权限测试）上。

审计清单

在 manifest 中重点查找以下模式：

• android:exported="true"的组件：Activity、Service、Receiver 一旦导出，其他应用即可直接调用。即使未显式声明，只要组件内定义了<intent-filter>，exported也会被系统默认置为true——这是最容易被忽视的导出方式（详见 MASTG-TEST-0029.md）；
• <intent-filter>与自定义 action/scheme：这决定了外部应用可以构造什么样的 Intent 来触发目标组件；
• android:permission缺失：导出组件若不声明权限，等于向全设备应用敞开大门；
• android:debuggable="true"：可调试应用允许通过run-as访问私有数据目录；
• android:allowBackup="true"：允许通过 adb backup 提取应用数据，是非 root 设备上绕过文件系统沙箱的经典路径；
• 自定义权限与危险权限声明：权限声明过宽同样扩大攻击面（参见 MASTG-TEST-0024.md）。

MASTG 测试文档给出了一段典型的脆弱广播接收器声明（取自 MASTG 测试套件中的 Android Insecure Bank 示例，模式可直接对照 Finstergram 的 manifest 检查）：

<receiver android:exported="true" android:name="com.android.insecurebankv2.MyBroadCastReceiver"> <intent-filter> <action android:name="theBroadcast" /> </intent-filter> </receiver>

这类exported="true"+<intent-filter>的组合意味着任何应用都能向该 receiver 发送匹配的广播。

用自动化规则辅助扫描

MASTG 仓库的 rules 目录维护了一批 YAML 格式的静态扫描规则，可直接把上述审计点脚本化：

• mastg-android-deeplink-autoverify-missing.yml 与 mastg-android-deeplink-unvalidated-parameter.yml：深链参数未校验；
• mastg-android-implicit-intent-internal-communication.yml 与 mastg-android-implicit-intent-leaking-extras.yml：隐式 Intent 泄漏数据；
• mastg-android-content-provider-exported.yml：Content Provider 被导出；
• mastg-android-debuggable-flag.yml 与 mastg-android-backup-manifest.yml：可调试与备份开关。

这些规则对应的正是 Finstergram 这类教学应用最容易埋雷的位置，可以作为静态分析阶段的自动化校验清单。

攻击面二：定位密码校验逻辑——"保险库密码"从哪里来、怎么比

文档的第二条提示是理解密码如何被校验。这一步要把 manifest 中发现的入口与代码逻辑串起来：

1. 用 jadx-gui 打开 APK，先看 manifest 中声明的入口 Activity（通常就是启动页面）；
2. 追踪密码输入框对应的 Activity/View 与点击事件处理函数；
3. 顺着校验函数向下找：密码是硬编码在代码里，还是存在SharedPreferences、SQLite 数据库，或者被某个加密/哈希算法加工后比较；
4. 重点观察比较方式：明文equals、硬编码哈希值、还是依赖某个可被绕过的辅助函数。

常见的教学级漏洞模式包括：密码以明文常量写死在 smali/Java 代码中；密码存于可备份的SharedPreferences；校验逻辑虽然做了加密，但密钥与密文一起打包在 APK 内——反编译后密钥唾手可得。这些模式分别对应 MASTG 的存储与密码学测试章节：tests/android/MASVS-STORAGE 与 tests/android/MASVS-CRYPTO。

注意：Finstergram 的具体校验实现细节不在本仓库内，上述是 MASTG 方法论层面的排查路径；最终结论必须以你反编译得到的实际代码为准。

攻击面三：广播接收器——向"保险库"发送一条伪造广播

文档的第三条提示是调查广播机制。广播是 Android IPC 中最容易被忽略的攻击面：一个exported的 receiver 可以被任何应用触发，如果 receiver 的onReceive内部还执行了敏感操作（解锁、改密码、发短信、读写数据），就等于给了攻击者一条远程指令通道。

按照 MASTG-TEST-0029.md 的广播测试方法，排查分三步：

1. 看 manifest：找出所有<receiver>元素，检查android:exported与<intent-filter>中的 action；
2. 搜源码：搜索sendBroadcast、sendOrderedBroadcast、sendStickyBroadcast以及registerReceiver（动态注册的 receiver 同样危险），确认广播中是否携带敏感数据；
3. 动态验证：用外部应用或 adb 工具向目标 receiver 发送构造好的广播，观察onReceive是否被执行了危险逻辑。

该测试文档中的示例展示了 receiver 内部读取SharedPreferences、解密密码并向外发送短信的典型脆弱实现——这与"照片保险库"场景高度相似：一个导出 receiver 如果承担了"解锁/重置密码"职责，那么一条广播即可完成绕过。

防御侧（同样适用于你在审计其他应用时的评判标准）：应用内自用的广播应改用LocalBroadcastManager限制接收范围；sendBroadcast时应指定 receiver 权限或显式包名，避免广播被第三方应用接收或伪造。

攻击面四：利用 Intent 驱动导出组件

文档的第四条提示是探索 Intent 的利用方式。Intent 是 Android 组件间通信的载体，攻击者可以从自己的恶意应用中构造 Intent，显式或隐式地启动目标应用的导出组件：

• 显式 Intent：直接指定组件类名，若该组件exported="true"，即可被外部启动；
• 隐式 Intent：通过action/data/scheme匹配<intent-filter>，这一层与Deep Link高度重合——详见 MASTG-TEST-0028.md（深链测试）；
• Extra 传递：通过putExtra向目标组件传递参数，若组件未校验输入，可能触发未授权操作（对应规则 mastg-android-implicit-intent-leaking-extras.yml）。

实操中建议配合 MASTG-TOOL-0035（IPC 组件枚举工具，见 MASTG-TOOL-0035.md）一次性列出所有导出的 Activity / Service / Receiver / Provider，然后逐个尝试：哪些组件可以不经过密码直接进入相册界面？哪些组件接收外部参数并做出危险响应？adb shell am start -n <package>/<component>与am broadcast是快速触达这些组件的最短路径。

攻击面五：别忘了内容提供者与其他 IPC

除 Activity 与 Receiver 外，导出的 Content Provider也是非 root 设备上的高价值目标。若 Finstergram 将照片元数据或密码信息存放在 Provider 中且exported="true"，攻击者即可通过content://URI 直接读写，甚至触发目录遍历读取沙箱内文件——详见 MASTG-TEST-0007.md（IPC 数据暴露测试）与规则 mastg-android-content-provider-exported.yml。

攻击路线图：从静态到动态的系统化推进

综合上述攻击面，针对 Finstergram 的完整进攻路线可以归纳为五步：

1. 清单化：用 MASTG-TOOL-0035 枚举导出组件，结合 manifest 绘制攻击面清单；
2. 静态深挖：用 jadx-gui 定位密码校验、receiver、intent 处理逻辑，找出可疑入口与硬编码凭证；
3. 动态验证：在非 root 手机上通过am start/am broadcast或自写恶意伴生应用，逐个触发候选入口，观察是否能绕过密码进入 secret gallery；
4. 数据侧路：若应用开启了备份，尝试adb backup提取并解析应用数据（对应 mastg-android-backup-manifest.yml）；
5. 收尾利用：将可行的触发方式固化为可复现的利用步骤，验证确实能展示 secret gallery 内容。

总结：从 Finstergram 到真实的 Android 安全测试

Finstergram 的价值在于它把"本地密码保护"这一常见需求中几乎所有的错误实现方式浓缩到了一个应用里：导出的组件、可伪造的广播、可被逆向的校验逻辑、可被外部 Intent 驱动的入口。完成挑战的关键不是某一个"魔法漏洞"，而是把 manifest 当作地图、把 IPC 当作通道、把密码实现当作最终目标的系统化思路。

这套思路可以直接迁移到真实世界的 Android 安全评估中：审计任何应用时，先画导出组件地图，再追敏感逻辑，最后用动态手段验证——MASTG 的 tests/android 测试套件与 rules 自动化规则正是为这一流程准备的。若想继续练手，仓库中的 Crackmes 系列（如 Crackmes/Android 下的分级关卡）提供了难度递进的同类挑战。

延伸阅读：本文涉及的测试方法细节，可深入阅读 MASTG-TEST-0029.md、MASTG-TEST-0028.md 与 MASTG-TEST-0007.md；工具安装与用法见 MASTG-TOOL-0018.md 与 MASTG-TOOL-0035.md。

• 文档
• 教程
• 网络安全