1. 项目概述：一个专为Hak5 WiFi Pineapple Pager设计的网络侦察与利用工具套件
如果你手头有一台Hak5的WiFi Pineapple Pager，并且对网络渗透测试或安全研究感兴趣，那么你很可能已经厌倦了那些功能单一、交互简陋的脚本。今天要聊的这个项目，CLAWHunter，可以说是我在Pager上用过的最具工程化思维和实战价值的工具套件之一。它的核心目标非常明确：在本地网络中自动发现并初步利用暴露的OpenClaw AI网关实例。OpenClaw是一个新兴的AI代理/网关平台，默认情况下它只绑定在本地回环地址（127.0.0.1）上，但一旦管理员为了远程访问而将其配置为监听局域网接口，或者将其置于反向代理之后，它就成为了一个潜在的攻击面。CLAWHunter正是针对这种“配置不当”或“有意暴露”的场景而生的。
这个项目不是一个简单的扫描脚本，而是一个完整的“套件”（Suite）。它包含了三个不同用途的载荷变体，共享一个强大的公共函数库。最让我印象深刻的是它对Pager这块小屏幕和有限硬件的极致利用——彩色显示屏、RGB LED阵列、震动马达、蜂鸣器，所有这些都被巧妙地整合到交互流程中，提供了一种近乎“桌面级”的侦察体验。从被动的mDNS监听，到主动的ARP发现和端口扫描，再到通过WebSocket升级和特定路径探测进行高置信度指纹识别，最后甚至集成了一个基于Python的“收割”引擎，用于对发现的实例进行初步的渗透和信息收集。整个工具链的设计思路清晰，考虑到了从静默侦察到主动利用的完整链条。
无论你是想在自己的家庭实验室里测试OpenClaw的安全性，还是在授权的红队演练中快速定位内部网络的AI服务，CLAWHunter都提供了一个高度集成化、交互友好的解决方案。它尤其适合那些需要快速部署、无需复杂配置，并且希望所有操作都能在一块便携设备上完成的场景。接下来，我会带你深入拆解它的设计思路、各个模块的实现细节，并分享我在部署和使用过程中踩过的坑和总结出的技巧。
2. 核心设计思路与架构解析
2.1 为什么是“套件”而非“单脚本”？
很多为Pager编写的脚本都是单一功能的，比如一个扫描脚本，或者一个攻击脚本。CLAWHunter在项目初期就选择了不同的道路：按使用场景和触发条件来划分载荷。这背后是基于对实战工作流的深刻理解。
交互式载荷 (User Payload)：这是主力，也是功能最全的版本。它通过Pager的“Payloads -> user”菜单手动启动，提供了完整的交互式体验。启动后，你会看到一系列的前置选项：是否查看历史记录、是否启用静默模式、是否随机化MAC地址、选择扫描速度档位、是否先连接WiFi、设置目标子网和端口等等。这种设计把控制权完全交给了操作者，适合在相对可控的环境中进行详细的侦察和利用。你可以把它想象成一把功能齐全的“瑞士军刀”，所有功能触手可及。
侦察触发载荷 (Recon Payload)：这个变体被设计为与Pager的“Recon”功能联动。当你使用Pager的Recon UI扫描并选定一个目标无线接入点（AP）后，可以从Recon界面直接启动这个载荷。它的巧妙之处在于，它会自动读取Recon UI设置的环境变量，比如
_RECON_SELECTED_AP_SSID、_RECON_SELECTED_AP_BSSID。这意味着你无需再手动输入目标网络的SSID或BSSID，脚本会自动尝试连接这个网络并进行扫描。这极大地优化了针对特定无线网络的渗透测试流程，实现了从无线侦察到有线内网扫描的无缝衔接。警报触发载荷 (Alert Payload)：这是自动化程度最高的版本，被放置在“alert”目录下。当有任何客户端设备连接到Pager自身创建的伪装AP时，这个载荷会被自动触发。它不会进行大范围的子网扫描，而是直接探测这个新连接客户端的IP地址。整个流程被设计得极其快速（<5秒）且强制静默（无声音），仅在确认发现目标时通过震动反馈。这非常适合用于“蜜罐”或“陷阱”场景，当一个不明设备接入你的“诱饵”网络时，它能瞬间判断该设备所在的网段内是否存在OpenClaw服务。
这种“一套代码，三种入口”的设计，最大化地复用了核心的指纹识别和硬件控制逻辑（封装在lib/common.sh中），同时通过不同的入口脚本适配了手动、半自动和全自动三种作战模式，体现了很好的软件工程思想。
2.2 硬件集成：超越命令行输出的交互体验
Pager的硬件虽然小巧，但CLAWHunter却把它用到了极致。这不仅仅是“锦上添花”，而是提升了在复杂环境下的操作效率和隐蔽性。
彩色显示屏 (480x222 px)：这是信息呈现的核心。CLAWHunter没有使用单调的文本滚动，而是采用了颜色编码和结构化显示。
- 蓝色：通常表示正在进行中的状态，如扫描进度、信息提示。
- 绿色：表示成功、确认的目标。
- 青色：表示被动监听（如mDNS）。
- 洋红色：表示看守模式（Watchdog）的休眠状态。
- 此外，它还实现了交互式选择器（用于设置选项）、结果浏览器（用于查看和选择发现的目标）、历史记录浏览器（查看过往扫描结果）。这些GUI元素的实现，让操作体验远超传统的命令行脚本。
RGB LED阵列 (4颗LED)：LED状态是快速获取脚本运行状态的“第二通道”，尤其在你不便时刻盯着屏幕时。
- 慢速蓝色脉冲：表示正在扫描。
- 快速绿色闪烁：表示确认发现目标。
- 蓝绿交替闪烁：表示发现了一个开放的候选端口。
- 青色慢速脉冲：表示正在运行mDNS监听。
- 白色脉冲：表示正在连接WiFi。
- 红色常亮：表示错误或中止。
- 这种丰富的视觉反馈，让你一眼就能知道脚本在干什么、有没有收获。
震动马达 (Haptic Feedback)和音频 (RTTTL)：提供了触觉和听觉的反馈维度。
- 震动：轻微的震动（150ms）提示发现候选目标；中等震动（300ms）用于mDNS发现或WiFi连接成功；强烈的震动（500ms）则用于确认发现目标、收割完成或扫描完成。在警报载荷中，震动是唯一的反馈方式。
- 音频：提供了启动音、发现音、完成音等多种提示音。静默模式可以一键关闭所有声音和震动，这在需要保持隐蔽的场合至关重要。
五向导航键：所有交互都通过这五个按键完成。
UP/DOWN选择，B键确认、取消或退出，RIGHT键在结果浏览器中触发收割操作。逻辑清晰，学习成本低。
实操心得：在实际使用中，尤其是在光线较暗或需要快速反应的场景下，LED和震动反馈比看屏幕文字要直观得多。我通常会把Pager放在桌面上，扫一眼LED颜色就能知道扫描是否结束或有無发现，大大提升了效率。
2.3 依赖管理与兼容性设计
Pager运行的是定制版的OpenWRT系统，其BusyBox环境与标准的Linux发行版存在差异。CLAWHunter在依赖处理上做得非常出色。
核心依赖最小化：脚本主体（Bash部分）极力依赖系统自带的工具，如
nc(netcat)、curl、awk、ping、arping。这保证了在纯净的Pager系统上，核心扫描功能可以立即运行。增强功能可选化：一些能提升体验或性能的工具被设计为“有则优，无则可用”。
avahi-utils：用于mDNS服务发现。如果未安装，mDNS监听阶段会被优雅地跳过，并提示用户。arp-scan：比arping更快的二层主机发现工具。如果没有，脚本会自动回退到arping，再回退到ping扫描。macchanger：用于MAC地址随机化。如果没有，会尝试使用ip link set命令，如果还失败，则记录警告并继续使用真实MAC。python3：这是收割引擎 (harvest.py)的必需依赖。如果未安装，收割功能将无法使用。脚本会明确提示需要安装。
安装路径明确：所有通过
opkg安装的软件包，都强烈建议使用-d mmc参数安装到Pager内部的4GB eMMC存储分区。这是因为系统的根目录覆盖层（root overlay）空间非常有限（通常小于32MB），安装大包（如python3）到默认位置会导致空间不足。
这种设计使得CLAWHunter具备了很好的“开箱即用”性和“渐进增强”特性。新手可以快速上手基本功能，而高级用户可以通过安装额外工具来获得更强大的能力。
3. 详细部署流程与配置要点
3.1 环境准备与依赖安装
在部署CLAWHunter之前，你需要确保你的Pager已经准备好。首先，通过SSH连接到你的Pager（默认地址是pineapple.lan，用户名为root）。
ssh root@pineapple.lan连接成功后，我强烈建议先更新软件包列表并安装可选依赖。虽然不安装也能运行核心扫描，但为了获得最佳体验，建议安装以下包：
opkg update opkg install -d mmc avahi-utils # 用于mDNS发现，提升被动侦察能力 opkg install -d mmc arp-scan # 更快的ARP扫描，加速主机发现阶段 opkg install -d mmc python3 # 必需，用于运行 harvest.py 收割引擎重要提示：
-d mmc参数是关键！它告诉opkg将软件包安装到Pager内置的4GB eMMC存储的/root分区，这里有充足的空间。如果忘记这个参数，很大概率会因根目录空间不足而安装失败。
3.2 项目文件部署到Pager
CLAWHunter的文件结构需要被完整地复制到Pager的/root/payloads/目录下。你可以使用scp命令逐个目录复制，但更推荐使用rsync，它能更好地保持目录结构并便于后续更新。
方法一：使用 rsync（推荐）确保你是在本地电脑的CLAWHunter项目根目录下执行：
# 同步共享库 rsync -av lib/ root@pineapple.lan:/root/payloads/lib/ # 同步所有载荷变体 rsync -av payloads/ root@pineapple.lan:/root/payloads/-av参数表示归档模式并显示详细过程。
方法二：使用 scp 和 mkdir如果你没有rsync，可以手动创建目录并复制：
# 在Pager上创建必要的目录结构 ssh root@pineapple.lan "mkdir -p /root/payloads/lib /root/payloads/user/clawhunter /root/payloads/recon/clawhunter /root/payloads/alert/clawhunter-watchdog" # 复制共享库 scp lib/common.sh root@pineapple.lan:/root/payloads/lib/common.sh # 复制用户交互载荷及其收割引擎 scp payloads/user/clawhunter/payload.sh payloads/user/clawhunter/harvest.py root@pineapple.lan:/root/payloads/user/clawhunter/ # 复制侦察触发载荷 scp payloads/recon/clawhunter/payload.sh root@pineapple.lan:/root/payloads/recon/clawhunter/ # 复制警报触发载荷 scp payloads/alert/clawhunter-watchdog/payload.sh root@pineapple.lan:/root/payloads/alert/clawhunter-watchdog/部署完成后，在Pager上的目录结构应该如下所示：
/root/payloads/ ├── lib/ │ └── common.sh ├── user/clawhunter/ │ ├── payload.sh │ └── harvest.py ├── recon/clawhunter/ │ └── payload.sh └── alert/clawhunter-watchdog/ └── payload.sh3.3 可选配置：配置带外（OOB）数据渗出
收割引擎 (harvest.py) 支持将收集到的数据通过带外通道发送给攻击者，例如通过Telegram Bot或Webhook。这需要在部署前修改用户载荷的配置文件。
- 在本地电脑上，用文本编辑器打开
payloads/user/clawhunter/payload.sh。 - 找到文件顶部附近的“Out-of-band exfil config”部分。
- 取消注释（删除行首的
#）并填写你的配置信息：EXFIL_BOT_TOKEN="YOUR_TELEGRAM_BOT_TOKEN_HERE" # 从 @BotFather 获取 EXFIL_CHAT_ID="YOUR_TELEGRAM_CHAT_ID_HERE" # 接收消息的聊天ID # EXFIL_WEBHOOK_URL="https://your-webhook-url.com/endpoint" # 或者使用Webhook URL - 保存文件，然后重新将其部署到Pager。
注意事项：Pager的DuckyScript虽然提供了
TEXT_PICKER命令，但它需要通过五个物理按键逐个字符输入，这对于输入长的API Token或密码来说是极其不现实的。因此，所有凭证都必须在部署前预先配置好。在脚本运行过程中，没有界面让你输入这些敏感信息。
3.4 验证部署
部署完成后，你可以通过Pager的Web界面或直接在SSH中列出文件来验证：
ssh root@pineapple.lan "ls -la /root/payloads/user/clawhunter/"应该能看到payload.sh和harvest.py两个文件。
4. 指纹识别管道：七层探测的深度解析
CLAWHunter的核心能力在于其高精度的指纹识别管道。它不是一个简单的端口扫描器，而是一个分阶段、多协议验证的探测引擎。下面我们来拆解这七个阶段，理解其设计精妙之处。
4.1 阶段0：被动监听 (mDNS Monitor)
目的：在发起任何主动扫描之前，先进行一段时间的被动监听，捕捉网络中广播的mDNS (Bonjour/Avahi) 服务信息。实现：调用avahi-browse -a -r -p命令，持续运行一段可配置的时间（默认30秒）。它会解析网络中所有服务类型，并筛选服务名称或类型中包含openclaw或clawd的记录。优势：完全被动，零网络噪音。如果目标OpenClaw实例配置了mDNS广播（这在一些本地开发或便捷部署中很常见），这将是最快、最隐蔽的发现方式。依赖：需要安装avahi-utils包。用户交互：屏幕上会显示一个倒计时，LED呈青色脉冲。用户可以随时按B键跳过此阶段。
4.2 阶段1：ARP缓存收割 (ARP Cache Harvest)
目的：利用系统已有的ARP缓存信息，快速获取已知活跃的主机列表，避免重复探测。实现：读取/proc/net/arp文件和ip neigh show命令的输出，提取IP和MAC地址。优势：利用了系统的“记忆”，速度极快，零额外网络流量。这些主机很可能近期有过通信，是活跃目标的可能性更高。
4.3 阶段2：主动主机发现 (Active Host Discovery)
目的：如果ARP缓存信息不足，则主动探测目标子网内的存活主机。实现：采用三级回退策略，确保在工具缺失情况下的鲁棒性。 1.首选：arp-scan。速度快，能直接获取MAC地址。 2.次选：arping。系统通常自带，逐个主机进行ARP请求。 3.保底：ping扫描。最通用的方法，但速度较慢，且可能被防火墙过滤。设计考量：这种回退设计保证了脚本在最小化依赖的环境下依然能工作，只是性能有所差异。
4.4 阶段3：TCP连接探测 (TCP Connect Probe)
目的：快速过滤掉目标主机上未开放目标端口的IP，减少不必要的HTTP请求。实现：使用nc -z -w 1 <IP> <PORT>命令尝试建立TCP连接，超时设置为1秒。优势：TCP连接尝试是判断端口是否“开放”的最直接方法。如果连接被拒绝或超时，则跳过后续更耗时的HTTP探测，极大提升扫描效率。
4.5 阶段4：HTTP/HTTPS内容探测 (HTTP/HTTPS Probe)
目的：对开放了端口的服务进行HTTP层面的指纹识别。实现：使用curl命令，分别尝试http://IP:PORT和https://IP:PORT，超时3秒。然后分析响应： *确认发现 (Confirmed)：如果响应体包含openclaw、clawd、gateway等关键词。 *高置信度确认：如果在主目标端口（默认18790）上收到HTTP 400、401、403状态码。这是因为OpenClaw网关在未认证时会返回这些状态码，而普通的Web服务很少在这些端口上返回此类状态。 *候选目标 (Candidate)：如果在扩展端口（如80, 443）上收到任何HTTP响应。技巧：对主目标端口（18790）的401状态码给予高权重，这是一个非常强的指纹特征。
4.6 阶段5：WebSocket升级试探 (WebSocket Upgrade Probe)
目的：进行应用层协议探测，进一步确认是否为OpenClaw的WebSocket网关。实现：通过Bash内置的/dev/tcp设备（或nc回退）发送一个标准的WebSocket升级握手请求。bash GET / HTTP/1.1 Upgrade: websocket Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ== Sec-WebSocket-Version: 13判断逻辑：一个正常的OpenClaw WebSocket网关会在认证之前就接受升级请求，返回HTTP/1.1 101 Switching Protocols。而普通的HTTP服务器要么拒绝升级，要么返回其他响应（如200, 404）。收到101响应是OpenClaw的极高置信度指标（作者声称约99%）。优势：这是一种非常精准的协议级指纹识别，比单纯的关键词匹配更可靠。
4.7 阶段6：特定路径探测 (Canvas Path Probe)
目的：探测OpenClaw特有的管理或前端路径。实现：使用curl请求两个已知的OpenClaw特有路径： *GET /__openclaw__/canvas/*GET /__openclaw__/a2ui/判断逻辑：如果这两个路径返回的不是404，那么几乎可以100%确定是OpenClaw实例，即使它没有返回任何关键词。这些路径是OpenClaw内部使用的，在其他Web服务中出现的概率极低。
4.8 阶段7：状态信息提取 (/agent/statusIntel)
目的：如果前面确认了目标，则尝试获取其运行时状态和配置信息。实现：向http://IP:PORT/agent/status?session=agent:main:main发送GET请求。提取信息：从返回的JSON中解析出： *模型：正在使用的AI模型（如anthropic/claude-opus-4-6）。 *上下文使用率：模型上下文窗口的占用百分比。 *活跃工具调用数：当前正在执行的工具数量。 *子代理数量：网关管理的子代理数量。 *网关启动时间：服务的运行时长。价值：这些信息不仅用于确认，更是宝贵的侦察情报，可以了解目标的负载、使用的模型（可能推断其成本或能力）等。
这七个阶段构成了一个由宽到窄、由浅入深的过滤漏斗。每一层都试图用更精确、更特征化的方法去验证目标，同时兼顾了速度和隐蔽性。例如，先通过快速的TCP连接过滤掉大部分主机，再对少数开放端口进行耗时的HTTP和WebSocket探测，这种策略非常高效。
5. 收割引擎：从侦察到初步利用
如果说前面的扫描是“发现目标”，那么集成的收割引擎 (harvest.py) 就是“初步接触目标”。它是一个用Python3编写的独立模块，仅依赖标准库，通过Pager上的结果浏览器一键触发。
5.1 触发与工作流程
- 触发条件：在用户交互载荷的“结果浏览器”界面，当屏幕上列出已发现的OpenClaw实例时，使用
UP/DOWN键导航到目标，然后按下RIGHT键（或除UP,DOWN,B,LEFT之外的任意键）。 - 用户确认：脚本会弹出提示，询问是否启用“带外渗出”（如果已配置）以及选择渗出方式（Telegram或Webhook）。
- 自动执行：确认后，收割引擎在后台启动，屏幕上显示一个旋转的指示器。整个过程无需人工干预。
5.2 三阶段收割详解
收割引擎的工作分为三个逻辑阶段，每个阶段的目标和所需权限不同。
阶段1：认证探测 (Auth Probe)
- 目标：判断目标网关的认证状态。
- 方法：尝试访问一个无需认证的端点（如
/或/agent/status），观察响应。 - 结果分类：
- OPEN：网关完全开放，无需任何令牌即可访问代理功能。这是最理想的情况。
- TOKEN_GATED：网关受令牌保护，访问受控端点返回401/403。此时只能进行有限的HTTP信息收集。
- UNREACHABLE：目标在扫描后变得不可达。
阶段2：HTTP信息收割 (HTTP Harvest)
- 目标：收集尽可能多的HTTP层面的信息，无论认证状态如何。
- 收集内容：
/__openclaw__/canvas/和/__openclaw__/a2ui/路径的响应状态和内容。/agent/status端点的完整JSON响应（如果可访问）。- 根路径
/的响应头和部分内容。 - 所有的HTTP响应头，其中可能包含服务器版本、框架信息等。
- 价值：即使目标受令牌保护，这些信息也可能泄露版本号、内部路径、错误信息等，用于后续的漏洞研究或社会工程。
阶段3：多轮代理会话 (Multi-turn Agent Session)
- 触发条件：仅当阶段1判定为OPEN门户时执行。
- 核心机制：与OpenClaw网关建立一个持久的WebSocket连接，并模拟一个客户端会话，利用网关内置的“工具”来执行命令和查询。
- 会话流程：引擎会依次执行4到5个“回合”（Turn），每个回合使用不同的工具组合，并设有超时限制。
5.3 代理会话的五个回合
这是收割引擎最核心、最强大的部分。它假设目标网关的代理被配置为可以执行系统命令和访问文件（这通常是开发或高度信任环境下的配置）。
| 回合 | 标签 | 使用的代理工具 | 超时 | 收集的信息 |
|---|---|---|---|---|
| 1 | 系统枚举 | exec,Read | 60s | 系统信息 (uname,id,hostname,uptime)，网络配置 (ip addr,ip route)，进程列表 (ps aux)，环境变量（可能包含API密钥），目录列表，关键配置文件 (openclaw.json,secrets.json,.env)，SSH密钥，代理知识库文件。 |
| 2 | 内存语义搜索 | memory_search | 30s | 在代理的向量化记忆索引中，搜索16个与凭证相关的关键词（如api_key,password,token,secret,aws等），返回匹配的文本片段及其来源。 |
| 3 | 会话历史 | sessions_list,sessions_history | 30s | 列出所有会话，并获取最近5个会话中各自最后20条消息的完整内容。这可能包含用户与AI的对话历史，其中或有敏感信息。 |
| 4 | 配对节点 | nodes(action=status, describe) | 20s | 枚举所有连接到该网关的设备（如手机、平板、摄像头），获取设备名、类型、能力和最后在线时间。 |
| 5 | 带外渗出(可选) | exec | 20s | 使用curl命令，从受害主机直接将前面收集到的所有数据摘要发送到攻击者控制的Telegram Bot或Webhook。这是真正的“带外”（Out-of-Band）数据渗出。 |
深度解析：为什么这个收割引擎有效？它的有效性基于一个关键前提：目标OpenClaw网关的代理被授予了较高的执行权限。在OpenClaw的架构中，代理可以通过“工具”与外部世界交互。如果管理员配置了
exec工具并允许其运行shell命令，那么任何能访问该代理的客户端（包括这个收割引擎）就相当于获得了一个在托管网关的服务器上执行命令的通道。memory_search和sessions_history则是直接利用了OpenClaw平台自身的功能来检索数据。因此，这个引擎本质上是在滥用目标系统已有的、合法的功能来进行渗透，而非利用软件漏洞。
5.4 输出与日志
所有收割操作都会生成详细的日志文件，保存在/root/loot/clawhunter/目录下，文件名格式为harvest_<IP>_<时间戳>.log。日志包含了每个阶段的请求、响应、提取到的数据以及任何错误信息。如果配置了带外渗出，还会记录渗出尝试的结果。
6. 实战技巧与疑难排查
经过多次实际使用，我总结了一些能让你事半功倍的技巧，以及常见问题的解决方法。
6.1 扫描策略选择与隐蔽性考量
CLAWHunter提供了五种扫描速度档位，你需要根据场景选择：
- GHOST：完全被动。只进行mDNS监听和ARP缓存读取。零主动网络流量，最隐蔽，但发现能力有限。适合在高度监控的网络中做初步摸底。
- QUIET：安静模式。顺序探测，每个探测之间有至少50毫秒的基础延迟，并附加随机抖动（0-200ms）。强制静默。模拟人类浏览器的请求间隔，不易被简单的基于请求速率的IDS检测到。
- NORMAL：普通模式。顺序探测，带有较小的随机抖动（0-80ms）。打破机械的、等间隔的扫描模式，是隐蔽性和速度的平衡点，也是默认推荐选项。
- FAST：快速模式。并行探测（同时扫描3个主机）。吞吐量约为顺序扫描的3倍。适合在内部测试或时间紧迫时使用。
- AGGRESSIVE：激进模式。扫描所有端口（主端口+扩展端口），同时并行5个探测。以速度为最高优先级，接受被IDS检测的风险。仅在需要快速横扫整个网络时使用。
我的建议：在未知环境中，从QUIET或NORMAL开始。结合MAC地址随机化选项，可以进一步降低被基于MAC地址的监控系统关联的风险。记住，arp-scan等主动发现工具会产生广播流量，在某些严格的环境中可能被察觉。
6.2 关于OpenClaw的绑定地址与发现概率
这是最容易产生困惑的地方。OpenClaw网关默认绑定在127.0.0.1（本地回环）。这意味着，除非它被明确配置为绑定到某个局域网IP（例如在openclaw.json中设置"bind": "0.0.0.0"或"bind": "192.168.1.100"），或者它前面有一个反向代理（如Nginx）在监听局域网端口，否则CLAWHunter是无法从网络中发现它的。
因此，CLAWHunter发现的并不是“默认配置”的OpenClaw，而是那些已经被配置为对外提供网络访问的实例。这恰恰是安全评估的意义所在：发现那些本不应暴露，或者暴露了但未正确加固的服务。
6.3 常见问题与解决方案
问题1：运行载荷时提示lib/common.sh: not found
- 原因：共享库文件路径不正确。
- 解决：确保你严格按照部署步骤，将
common.sh文件放在了/root/payloads/lib/目录下。检查各载荷脚本中引用它的相对路径（../../lib/common.sh）是否正确。
问题2：收割引擎启动失败，提示python3: not found
- 原因：Pager上未安装Python3，或安装位置不对。
- 解决：通过SSH连接到Pager，执行
opkg install -d mmc python3。务必使用-d mmc参数。
问题3：mDNS监听阶段什么都没发现
- 原因1：目标网络中没有设备广播OpenClaw相关的mDNS服务。
- 原因2：
avahi-utils未安装。 - 解决：按
B键跳过该阶段即可。mDNS只是辅助发现手段，并非必需。
问题4：扫描发现了主机，但所有端口都是关闭的
- 原因：可能防火墙阻止了探测，或者目标服务确实未运行在扫描的端口上。
- 解决：尝试使用“扩展端口”选项，扫描80, 443, 3000, 8080, 8443等常见Web端口。或者，目标可能使用了非标准端口，这需要你有进一步的情报。
问题5：WiFi客户端模式连接失败
- 原因：Pager没有预先保存目标WiFi网络的密码。
- 解决：必须在运行载荷之前，通过Pager的Web管理界面（Network -> Wireless）扫描并保存目标WiFi网络的连接信息（包括密码）。载荷脚本无法在运行时通过按钮输入复杂的密码。
问题6：收割过程卡住或无输出
- 原因：目标网关响应缓慢，或者网络连接不稳定，或者WebSocket会话出现意外。
- 解决：收割引擎设有超时机制（每个回合20-60秒，总会话不超过3分钟）。耐心等待超时，然后检查
/root/loot/clawhunter/目录下对应的harvest日志文件，里面可能有错误信息。有时网络波动会导致连接中断。
6.4 高级用法：看守模式与历史对比
- 看守模式 (Watchdog Mode)：在扫描完成并发现目标后，脚本会询问是否进入看守模式。启用后，它会以固定的时间间隔（默认5分钟）重新扫描网络。关键特性：它只会对新出现的实例或消失的实例发出警报（通过震动和屏幕提示）。这对于监控一个网络区域中OpenClaw实例的动态变化非常有用，比如检测新的部署或旧服务的下线。
- 历史与差异对比：每次扫描都会生成带时间戳的日志和JSON报告。在启动时，如果选择“查看扫描历史”，脚本会读取之前的日志，并能在扫描完成后展示本次与上次扫描结果的差异（新增/消失的实例）。这对于跟踪目标环境的变化至关重要。
CLAWHunter是一个设计精良、功能强大的工具套件，它将一个复杂的网络侦察和初步利用流程，封装进了一个便携、交互友好的硬件设备中。它不仅仅是一个脚本集合，更体现了一种针对特定目标（OpenClaw）进行深度、自动化安全评估的方法论。无论是用于内部安全审计，还是作为红队演练中的一环，它都能显著提升效率。当然，它的有效性高度依赖于目标服务的配置方式（暴露在网络中且代理权限过高），这也提醒我们，在部署类似AI网关服务时，网络安全配置与权限最小化原则是多么重要。
