移动端渗透测试不同于传统Web测试，它需要同时关注客户端二进制、本地存储、进程间通信以及客户端与服务端的交互。测试者不仅要能抓取网络流量，还要具备一定的逆向分析能力，才能发现隐藏在应用逻辑深处的缺陷。
一、移动端渗透测试环境与基础工具链
在开始测试之前，需要准备一台已root的Android设备或模拟器，以及一台可越狱的iOS设备用于全量测试。如果条件有限，Android模拟器配合Frida也能完成大部分动态分析工作。抓包工具推荐Burp Suite或Charles，移动端需要安装对应证书，并将Wi-Fi代理指向主机。设置代理后，只有HTTP流量能被直接观察，HTTPS流量则需要额外处理证书信任问题。
除了抓包，逆向分析工具同样重要。jadx用于将APK反编译为Java源码，apktool负责解码资源并产出smali代码，Ghidra或IDA则用于分析原生so库。动态插桩工具Frida可以绕过证书校验、Hook关键函数、追踪加密逻辑，是移动端渗透测试的核心武器。搭配Objection使用可以大幅提高测试效率，例如自动枚举导出组件或关闭SSL Pinning。
下面演示通过adb设置全局代理并转发端口的命令：
adb shell settings put global http_proxy 192.168.1.100:8080 adb reverse tcp:8080 tcp:8080
设置全局代理后，App的HTTP请求会经过Burp Suite。但如果应用启用了SSL Pinning，HTTPS请求会因证书不匹配而失败，此时需要配合Frida脚本解除证书固定。以OkHttp为例，可以使用如下脚本让应用信任任意证书。
Java.perform(function() {
var TrustManager = Java.use("javax.net.ssl.X509TrustManager");
var SSLContext = Java.use("javax.net.ssl.SSLContext");
var TrustManagerImpl = Java.registerClass({
name: "com.custom.TrustManagerImpl",
implements: [TrustManager],
methods: {
checkClientTrusted: function(chain, authType) {},
checkServerTrusted: function(chain, authType) {},
getAcceptedIssuers: function() { return []; }
}
});
SSLContext.init.implementation = function(km, tm, sr) {
this.init(km, [TrustManagerImpl.$new()], sr);
};
});
这段脚本通过Java.registerClass注册了一个自定义的X509TrustManager，并在SSLContext初始化时替换掉原本的信任管理器，从而忽略证书校验错误。实际测试中还可以使用Objection的一键命令，极大降低操作门槛。完成代理与证书配置后，测试者就可以像测试Web应用一样分析移动端的API请求。
二、Android应用常见漏洞与实战利用
Android应用的攻击面主要集中在四大组件：Activity、Service、BroadcastReceiver和ContentProvider。如果开发者在AndroidManifest.xml中把组件声明为android:exported=true且未做权限校验，攻击者就可以通过adb或恶意应用直接调用这些组件。导出的Activity可以被外部启动，从而绕过正常的登录流程或访问内部功能页面。
以导出Activity为例，假设目标应用存在一个用于调试的Activity，攻击者可以执行以下命令直接启动它，绕过正常的身份验证。
adb shell am start -n com.victim.app/.DebugActivity
若组件为ContentProvider，则可能被越权读取或修改数据。查询导出的ContentProvider时，可以使用content命令直接访问其URI，获取敏感数据或修改后端数据库。
adb shell content query --uri content://com.victim.provider/users
除了组件暴露，本地存储缺陷也是高频问题。许多应用将用户令牌、密码或隐私信息明文写入SharedPreferences、SQLite数据库或外部存储文件中。攻击者只需在已root设备上进入/data/data/包名目录即可查看。常见的检测命令如下：
adb shell run-as com.victim.app cat /data/data/com.victim.app/shared_prefs/login.xml
这段命令使用run-as以应用自身身份读取私有目录，前提是应用开启了android:debuggable属性。更通用的方式是获取root权限后直接访问所有应用沙箱。WebView漏洞也不容忽视，如果启用了JavaScript接口且未限制加载内容，攻击者可以通过恶意网页调用Java层方法，导致远程代码执行或数据泄露。例如，若WebView设置了addJavascriptInterface且允许加载任意URL，攻击者只需诱导用户访问一个恶意页面即可触发漏洞。
三、iOS端测试要点与跨平台防御策略
iOS端测试与Android有相似之处，但生态更封闭。越狱后可以通过OpenSSH连接设备，使用iproxy转发端口，再配合Frida进行动态分析。iOS的App Transport Security（ATS）默认要求HTTPS，但开发者经常为了调试而关闭ATS，导致明文流量暴露。检查Info.plist中的NSAppTransportSecurity配置是静态分析的必做项。
iOS的SSL Pinning绕过通常使用Frida脚本或Objection。以下Objection命令可以快速禁用证书锁定，让Burp Suite能够解密HTTPS流量：
objection -g com.example.app explore ios sslpinning disable
针对iOS Keychain存储，需要检查数据是否使用了合适的保护属性，如kSecAttrAccessibleAfterFirstUnlock等。Android与iOS共同的安全问题包括：未加密的日志输出、弱加密算法、硬编码密钥、越权第三方SDK等。测试时还应当关注应用在模拟器或越狱环境中的运行状态，因为很多防护逻辑只在真实设备上启用。
从防御角度看，移动应用应当实施证书固定、双向证书校验、数据加密存储、运行时完整性检查，并对导出的组件做严格的权限控制。开发团队应避免在客户端存储敏感信息，所有关键逻辑尽量放在服务端并做好认证与鉴权。测试人员在完成渗透测试后，应输出包含风险等级、复现步骤和修复建议的完整报告，帮助开发团队从源头收敛攻击面，而不是仅仅修复某个被利用的端点。