1. 项目概述与核心价值

如果你是一名移动安全研究员、渗透测试工程师，或者是一名对Android应用安全充满好奇的开发者，那么“InsecureBankv2”这个名字你一定不陌生。它不是一个真实的银行应用，而是一个由安全专家精心设计的、故意包含大量安全漏洞的Android应用。它的唯一目的，就是成为我们学习和练习移动应用安全测试的“活靶场”。今天，我们不谈枯燥的理论，直接上手，从零开始，带你完成InsecureBankv2的完整安装、部署、配置，并深入其内部，剖析那些经典的漏洞场景。这不仅仅是一个教程，更像是一次完整的实战演练笔记，我会把过程中每一个可能卡住你的细节、每一个工具背后的原理，以及我踩过的那些坑，都毫无保留地分享出来。

为什么是InsecureBankv2？因为在移动安全测试领域，理论知识和实战能力之间往往隔着一道鸿沟。你或许知道OWASP Top 10，但面对一个真实的APK文件，从哪里入手？如何搭建测试环境？如何触发一个SQL注入漏洞？如何利用不安全的组件通信？InsecureBankv2将这些抽象的概念具象化，它模拟了一个银行应用的典型功能——登录、转账、查看余额、修改资料，但每一步都暗藏玄机。通过亲手“攻破”它，你能获得的不仅仅是几个漏洞利用的技巧，更是一套完整的、可复用的Android应用安全测试方法论。无论你是想入门移动安全，还是想巩固自己的实战技能，这个“靶场”都是绝佳的起点。

2. 测试环境全栈搭建与原理剖析

工欲善其事，必先利其器。一个稳定、高效的测试环境是后续所有操作的基础。这里我们不追求最炫酷的配置，而是追求最稳定、兼容性最好的方案，确保你能一次成功，把精力集中在漏洞挖掘本身。

2.1 核心工具选型与安装策略

我们的环境将围绕三个核心展开：Android应用运行环境、动态测试工具和静态分析工具。

1. Android运行环境：物理设备 vs. 虚拟机/模拟器

这是一个首要决策点。我强烈推荐使用Android Studio自带的官方模拟器（AVD），而不是Genymotion等第三方模拟器或物理手机。原因有三：第一，兼容性最佳，尤其是对于需要与ADB深度交互、安装各种Frida/Gadget等复杂操作，官方模拟器几乎不会出现诡异问题；第二，快照功能无敌，你可以随时保存一个干净的、配置好代理和工具的系统状态，测试完一键恢复，效率极高；第三，性能可控，我们可以为其分配足够的CPU和内存资源。

当然，物理手机（需Root）有其优势，比如可以测试一些依赖特定传感器或硬件的漏洞，但对于InsecureBankv2的学习而言，模拟器完全足够，且避免了真机变砖或数据泄露的风险。

注意：如果你坚持使用物理手机，请务必使用专门的测试机，并备份所有数据。Root操作有风险，且不同手机型号、系统版本的Root方法和ADB兼容性千差万别，会引入大量不必要的环境问题。

2. 动态测试瑞士军刀：ADB（Android Debug Bridge）

ADB是连接你的电脑和Android设备的桥梁，是后续所有操作的“总开关”。安装它最简单的方式就是通过Android Studio的SDK Manager。安装后，请务必将ADB所在目录（通常是[你的SDK路径]/platform-tools/）添加到系统的PATH环境变量中。这样，你才能在任意命令行窗口直接使用adb命令。

验证安装：打开命令行（Windows的CMD或PowerShell，Mac/Linux的Terminal），输入adb version。如果能看到版本号，恭喜你，第一步成功了。

3. 静态分析利器：反编译工具链

对于InsecureBankv2，我们主要使用以下工具进行静态代码审计：

• Apktool：用于反编译APK资源文件（如图片、布局XML、字符串等），得到近乎原始的res和AndroidManifest.xml文件。这对于快速分析应用结构、寻找暴露的组件（Activity、Service等）至关重要。
• dex2jar + JD-GUI或JADX：用于将APK中的Dex字节码文件转换为可读的Java源代码。我个人更推荐JADX，它是一个集成的GUI工具，可以直接打开APK文件，将反编译、代码查看、搜索功能融为一体，对新手极其友好，效率也更高。

安装这些工具只需从它们的GitHub发布页面下载最新版本，解压到某个目录，并将该目录加入PATH即可。对于JADX，甚至提供了开箱即用的图形化程序。

2.2 Android模拟器（AVD）的精细化配置

打开Android Studio，进入“Device Manager”，点击“Create device”。在选择系统镜像时，我建议选择 x86_64 架构的镜像，例如 “Tiramisu”（Android 13）或 “Pie”（Android 9）。x86_64架构在电脑上运行效率远高于ARM架构，因为你的电脑CPU本身就是x86_64的，无需指令转换。

在创建AVD的最后一页，点击“Show Advanced Settings”，进行几项关键配置：

1. 内存与存储：将RAM设置为至少2048MB，内部存储（Internal Storage）设置为2048MB以上。这能保证应用运行流畅，并有空间安装其他测试工具。
2. 网络代理：暂时留空。我们后续会使用像Burp Suite这样的抓包工具，届时需要在模拟器系统设置中手动配置代理，而不是在这里写死，这样更灵活。
3. 启动选项：在“Additional command line options”中，可以添加-writable-system参数（可能需要通过编辑AVD的config.ini文件实现），这有时对于需要挂载系统分区为可写以安装Frida等工具的场景有帮助，但对于基础测试非必需。

创建完成后，启动模拟器。第一次启动可能较慢，请耐心等待。启动后，你应该能看到一个纯净的Android系统界面。

2.3 建立ADB连接与基础验证

启动模拟器后，回到命令行，输入adb devices。你应该能看到一个设备列表，其中包含你的模拟器，状态为device。这表示连接成功。

如果显示unauthorized，你需要在模拟器屏幕上弹出的“允许USB调试吗？”对话框中点击“允许”。如果什么都没显示，尝试重启ADB服务：adb kill-server然后adb start-server。

连接成功后，我们可以进行一些基础操作来验证环境：

• adb shell：进入设备的Linux Shell环境。输入ls -la看看目录，输入exit退出。
• adb install [apk路径]：这是我们后续安装InsecureBankv2的命令。
• adb logcat：实时查看设备日志，这是动态测试中观察应用行为、寻找崩溃信息和调试输出的重要窗口。你可以用adb logcat | grep -i insecurebank来过滤只与该应用相关的日志。

至此，一个坚实的测试地基已经打好。这个环境不仅能用于InsecureBankv2，也将是你未来进行任何Android应用安全测试的起点。

3. InsecureBankv2的获取、安装与初步探索

有了环境，接下来就是请我们的“主角”登场。

3.1 获取靶场应用与版本确认

InsecureBankv2是一个开源项目，托管在GitHub上。最直接的方式是访问其项目仓库（例如搜索“dineshshetty/InsecureBankv2”），在Release页面下载最新编译好的APK文件。通常文件名类似InsecureBankv2.apk。

下载后，我建议你使用adb install命令安装前，先用adb install -r尝试安装。-r参数代表替换安装，如果设备上已有旧版本，可以覆盖。但更稳妥的做法是，先使用adb uninstall com.android.insecurebankv2卸载旧版（如果存在），再安装新版。

安装命令：adb install /你的路径/InsecureBankv2.apk安装成功后，命令行会显示Success。在模拟器的主屏幕或应用列表里，你应该能找到名为“InsecureBankv2”的应用图标。

3.2 应用首次启动与基础功能走查

点击图标启动应用。你会看到一个登录界面。应用内置了测试账户：

• 用户名：jack
• 密码：Jack@123$

输入后登录。成功进入后，花几分钟时间浏览一下应用的主要功能模块，这有助于你理解后续测试的上下文：

1. 主页：显示欢迎信息和用户余额（一个虚假的数字）。
2. 转账（Transfer）：模拟向其他用户转账的功能，这里有潜在的输入点。
3. 查看交易记录（View Statements）：可能涉及数据库查询。
4. 修改密码（Change Password）：另一个重要的输入和逻辑验证点。
5. 退出登录（Logout）。

这个走查过程非常重要。在安全测试中，理解应用的正常业务流（Happy Path）是发现异常流（攻击路径）的前提。同时，留意应用的界面和交互，思考哪些地方可能接收用户输入，哪些操作会与后端（虽然这个应用的后端可能是本地的）或本地存储交互。

3.3 静态分析第一瞥：AndroidManifest.xml

在开始动态测试前，先进行快速的静态分析，这能为我们指明方向。使用Apktool反编译APK：apktool d InsecureBankv2.apk -o insecurebank_output解压后，在insecurebank_output目录下，找到并打开AndroidManifest.xml文件。这个文件是应用的“配置总纲”，我们需要重点关注以下几点：

1. 应用的包名（package）：确认是com.android.insecurebankv2，这与我们卸载时用的包名一致。
2. 导出的组件（Exported Components）：查找android:exported="true"的 Activity、Service、BroadcastReceiver 和 ContentProvider。导出的组件意味着可以被系统内或其他应用调用，这是组件安全测试的重中之重。你很快会发现，这个应用的很多组件都被故意设置为导出状态。
3. 权限声明（uses-permission）：看看应用申请了哪些权限，如网络、读写存储等。这暗示了应用可能的功能和攻击面。
4. 调试标志（android:debuggable）：虽然正式版APK通常为false，但作为测试靶场，它可能被设为true，这允许我们进行动态调试。

用文本编辑器或IDE打开这个XML文件，粗略浏览一遍。你会对应用的结构有一个宏观的认识，并记下那些“可疑”的导出组件名称，比如PostLogin、ViewStatement等，这些都将是我们后续攻击的入口点。

4. 动态安全测试实战：漏洞挖掘与利用

静态分析给了我们地图，动态测试则是真正的探险。我们将使用工具，与运行中的应用实时交互，触发并验证漏洞。

4.1 网络流量抓取与分析（Burp Suite代理配置）

很多漏洞，如认证绕过、敏感信息传输、参数篡改，都发生在网络层面。我们需要捕获应用发出的所有HTTP/HTTPS请求。

1. 配置Burp Suite代理：启动Burp Suite（社区版或专业版），在Proxy -> Options中，确保代理监听在127.0.0.1:8080（默认）。记住这个地址和端口。

2. 配置模拟器代理：在运行的模拟器中，进入系统设置 -> 网络和互联网 -> 高级 -> 代理 -> 手动。

• 代理主机名：10.0.2.2（这是Android模拟器访问主机环回地址127.0.0.1的特殊别名）。
• 代理端口：8080保存设置。

3. 安装Burp的CA证书：这是为了拦截HTTPS流量所必需的。在模拟器的浏览器中访问http://burp或http://10.0.2.2:8080，点击“CA Certificate”下载证书文件（通常为cacert.der）。 下载后，进入系统设置 -> 安全 -> 加密与凭据 -> 从存储设备安装证书（或类似路径）。找到下载的证书文件，为其命名（如“PortSwigger CA”）并安装。

4. 测试抓包：打开InsecureBankv2，进行登录操作。回到Burp Suite，确保Proxy -> Intercept是“Intercept is on”状态。你应该能看到登录请求被捕获。查看请求中的参数，如用户名、密码。你可以尝试修改这些参数（比如把密码改成错误的），再转发（Forward），观察应用的响应。这本身就是一种最简单的测试——参数篡改。

实操心得：有时候应用可能使用了证书绑定（Certificate Pinning），导致即使安装了CA证书，HTTPS流量也无法解密。对于InsecureBankv2，它可能故意关闭了证书验证以方便测试。如果遇到其他应用无法抓包的情况，就需要使用Frida、Objection等工具来绕过证书绑定。

4.2 不安全的组件通信漏洞利用

还记得我们之前在AndroidManifest.xml里看到的那些导出的Activity吗？现在我们来利用它们。

案例：直接调用受保护的Activity绕过登录假设我们发现一个名为com.android.insecurebankv2.PostLogin的Activity被导出。正常流程下，用户需要先登录才能看到这个界面。但由于它被导出，我们可以通过ADB命令，直接启动它，绕过登录检查。

adb shell am start -n com.android.insecurebankv2/.PostLogin

执行这条命令后，观察模拟器，你很可能会直接跳转到登录后的主界面，而无需输入任何凭证。这就是一个典型的认证绕过漏洞。攻击者如果开发一个恶意应用，在内部调用这个Intent，就可以在用户无感知的情况下打开目标应用的敏感界面。

深入利用：通过Intent传递恶意参数更进一步，许多导出的Activity会接收Intent附带的Extra数据。我们可以通过静态分析（阅读反编译后的PostLogin代码）或动态测试（尝试传递参数看应用如何反应）来发现这一点。 例如，如果发现该Activity会读取一个名为username的Extra来显示用户信息，我们可以尝试传递一个不同的用户名：adb shell am start -n com.android.insecurebankv2/.PostLogin --es username “admin”

如果应用未经验证就使用了这个传入的username，就可能造成数据篡改或权限提升。

4.3 输入验证漏洞：SQL注入与XSS

InsecureBankv2的许多输入点都可能存在漏洞。

1. 本地SQL注入：在“查看交易记录”或“搜索”功能中，应用可能会将用户输入直接拼接到SQL查询语句中。我们可以通过Burp Suite拦截相关请求，修改查询参数为经典的SQL注入Payload，例如： 将search_term参数修改为：' OR '1'='1观察响应。如果返回了所有交易记录，而不是空结果或错误，那么就证实了SQL注入漏洞的存在。你甚至可以尝试更复杂的Payload来探测数据库结构。

2. WebView中的XSS（跨站脚本）：如果应用内有使用WebView显示内容的模块（例如显示一些HTML格式的通知），并且该内容来源于用户可控的输入（如转账备注），那么就可能存在XSS。 测试方法：在可能存在输入的地方，尝试输入简单的HTML或JavaScript标签，如<script>alert(‘XSS’)</script>。提交后，观察当这个内容在应用内被渲染时，是否会弹出警告框。如果会，说明WebView没有正确过滤输入，存在XSS风险，可能导致Cookie窃取或本地文件泄露。

4.4 不安全的本地数据存储

Android应用常将数据存储在本地，如SharedPreferences、SQLite数据库或内部存储文件中。如果这些数据未加密或权限设置不当，就可能被恶意应用读取。

使用ADB Shell探查数据：

1. 进入ADB Shell：adb shell
2. 切换到应用数据目录：cd /data/data/com.android.insecurebankv2/
3. 查看目录内容：ls -la
4. 重点查看shared_prefs/目录（存放SharedPreferences XML文件）和databases/目录（存放SQLite数据库文件）。
5. 尝试读取这些文件：cat shared_prefs/MyPrefs.xml或使用sqlite3命令查看数据库内容。

如果你能直接看到明文存储的用户名、密码、会话令牌等敏感信息，那么就发现了不安全的本地存储漏洞。在真实测试中，你需要检查应用是否使用了Android提供的加密API（如EncryptedSharedPreferences）来保护这些数据。

5. 进阶测试：工具链集成与自动化探索

基础漏洞手动验证后，我们可以引入更强大的工具，提升测试的深度和效率。

5.1 使用Frida进行运行时动态插桩

Frida是一个动态代码插桩工具，它允许你在应用运行时注入JavaScript代码，来Hook（钩子）Java/Native函数，修改参数、返回值，甚至改变程序逻辑。这对于绕过逻辑检查、解密数据、跟踪敏感API调用非常有效。

1. 环境搭建：

• 在电脑上安装Frida：pip install frida-tools
• 根据模拟器架构（x86_64）下载对应的Frida-server：从Frida的GitHub Release页面下载frida-server-x.x.x-android-x86_64.xz。
• 解压得到frida-server文件，通过ADB推送到模拟器：adb push frida-server /data/local/tmp/
• 在ADB Shell中，赋予可执行权限并运行：adb shellcd /data/local/tmpchmod 755 frida-server./frida-server &

2. 基础Hook示例：假设我们想监控登录时的密码验证函数。首先需要知道函数名。通过JADX反编译，在代码中搜索“password”、“check”、“validate”等关键词，找到疑似函数，例如com.android.insecurebankv2.LoginActivity.verifyPassword。 编写一个JavaScript脚本（hook.js）：

Java.perform(function() { var LoginActivity = Java.use(‘com.android.insecurebankv2.LoginActivity’); LoginActivity.verifyPassword.implementation = function(inputPassword) { console.log(“[+] verifyPassword called with: “ + inputPassword); var result = this.verifyPassword(inputPassword); // 调用原函数 console.log(“[+] verifyPassword returned: “ + result); return result; // 可以修改返回值，比如永远返回true }; });

在电脑上执行：frida -U -f com.android.insecurebankv2 -l hook.js --no-pause这将启动应用并注入脚本。当你尝试登录时，就能在控制台看到输入的密码和验证结果。你甚至可以修改脚本，让verifyPassword始终返回true，从而实现任意密码登录的漏洞验证。

5.2 使用MobSF进行自动化安全评估

MobSF（Mobile Security Framework）是一个自动化的一体化移动应用安全测试框架，支持静态和动态分析。它可以快速给出一个安全评分和问题列表，是一个很好的辅助和初筛工具。

1. 本地部署MobSF：最简单的方式是使用Docker：docker run -it -p 8000:8000 opensecurity/mobile-security-framework-mobsf:latest然后在浏览器访问http://localhost:8000。

2. 上传并分析APK：在MobSF界面中，上传InsecureBankv2的APK文件。MobSF会自动进行：

• 静态分析：反编译、提取组件信息、权限分析、代码扫描（查找硬编码密钥、不安全的API调用等）。
• 动态分析（需配置模拟器和代理）：自动安装应用、进行基础交互、监控API调用、文件操作和网络流量。

几分钟后，你会得到一份详细的HTML报告，里面列出了它发现的所有安全问题，如导出的组件、不安全的权限、潜在的代码漏洞等。这份报告可以和你手动测试的结果相互印证，也能帮你发现一些可能忽略的细节。

6. 测试问题排查与经验沉淀

在实际操作中，你一定会遇到各种各样的问题。这里我总结了一些常见坑点和解决思路。

6.1 环境与连接类问题

问题1：adb devices列表为空。

• 排查：首先确认模拟器已完全启动（看到锁屏或主界面）。尝试adb kill-server && adb start-server。检查是否有多个ADB进程冲突。在Android Studio的Device Manager中查看模拟器状态是否正常。
• 解决：有时需要指定ADB端口连接，例如对于Android Studio默认的模拟器，可以尝试adb connect 127.0.0.1:5555。

问题2：Burp Suite抓不到HTTPS流量。

• 排查：确认模拟器代理设置正确（主机：10.0.2.2，端口：8080）。确认Burp代理监听在所有接口（0.0.0.0:8080）。确认CA证书已正确安装并受信任（在系统凭据的“用户”或“系统”标签页查看）。
• 解决：尝试在模拟器浏览器访问http://burp，确保能下载证书。对于新版Android，可能需要将CA证书同时安装到“系统”凭据中（这通常需要Root）。对于InsecureBankv2，检查其代码是否自定义了网络栈或关闭了证书验证（可能是为了教学故意为之）。

问题3：Frida连接失败或脚本不生效。

• 排查：执行frida-ps -U查看是否能列出设备进程。确认frida-server进程在设备上正常运行（ps | grep frida）。确认电脑和模拟器在同一网络（对于USB连接的物理设备）或端口转发正确。
• 解决：确保下载的frida-server版本与电脑端frida-tools版本兼容。对于模拟器，有时需要关闭Android Studio的即时运行（Instant Run）功能。尝试以root权限运行frida-server（在已root的设备上）。

6.2 应用与漏洞利用类问题

问题1：导出的Activity无法通过ADB启动，或启动后闪退。

• 排查：使用adb logcat | grep -i insecurebank或adb logcat | grep -i fatal查看崩溃日志。很可能是因为该Activity需要特定的Intent Flag或Extra数据，直接启动导致空指针异常。
• 解决：仔细阅读该Activity的onCreate方法反编译代码，看它尝试获取哪些Intent参数。在am start命令中通过--es,--ei,--ez等参数提供必要的字符串、整型或布尔值Extra。

问题2：SQL注入Payload没有效果。

• 排查：首先确认你拦截的是正确的请求和参数。查看服务器响应，是返回了错误信息、空白还是正常数据？使用更通用的探测Payload，如单引号‘，看是否引发错误（这本身就是注入点证明）。可能应用使用了参数化查询，从而免疫注入。
• 解决：尝试不同的注入点（不同功能模块）。尝试时间盲注Payload，如' AND (SELECT sleep(5)) --，观察响应是否延迟5秒。

问题3：静态分析代码时，JADX反编译出的代码逻辑混乱或缺少方法体。

• 排查：应用可能经过了混淆（Proguard）。虽然InsecureBankv2可能未混淆，但这是真实测试中的常见情况。
• 解决：结合动态分析。使用Frida去Hook关键方法，打印参数和返回值来理解逻辑。使用adb logcat查看运行时打印的日志信息，其中可能包含类名和方法名线索。对于混淆代码，关注其“行为”而非“名称”，比如它调用了哪些敏感的API（如executeSql,getWritableDatabase,sendTextMessage等）。

6.3 测试思维与报告撰写心得

1. 测试不是“乱点”：每一个测试用例都应有其目的。例如，测试SQL注入是为了验证“用户输入是否被安全地传递给数据库查询”。带着假设去测试，并根据结果修正你的应用威胁模型。

2. 关注漏洞链：单个中低危漏洞可能不足为惧，但组合起来就可能很危险。例如，一个导出的Content Provider（信息泄露）结合一个可预测的Intent组件（权限提升），可能形成完整的攻击链。

3. 记录与复现：务必详细记录每一个成功的漏洞利用步骤：使用的工具、命令、Payload、以及应用的响应。截图和日志非常重要。这不仅能用于编写报告，也能在复现时节省大量时间。

4. 报告要清晰：一份好的安全测试报告应包括：漏洞标题、风险等级、影响的组件/功能、详细的复现步骤（像本教程一样）、漏洞原理简述、修复建议。修复建议应具体可行，例如“对username参数进行强类型验证和长度限制”，而不是简单的“进行输入验证”。

通过这个从环境搭建到漏洞挖掘，再到问题排查的完整流程，你不仅学会了如何“玩转”InsecureBankv2这个靶场，更重要的是掌握了一套适用于大多数Android应用的安全测试基础流程和思维方法。记住，工具和技术会迭代，但这种主动探索、假设验证、层层深入的分析思维，才是安全工程师最核心的能力。接下来，你可以尝试用同样的方法去测试其他开源的有漏洞应用，或者在自己的个人开发项目中有意识地去避免这些常见问题，这才是学习的最终目的。