构建自动化POC供应链：为Goby与Xray实现智能漏洞检测

1. 项目概述：为什么你的武器库需要“智能投喂”？

在红队评估和渗透测试的日常里，Goby和Xray这两款工具几乎成了标配。Goby以其直观的资产测绘和漏洞扫描能力，能快速勾勒出攻击面；而Xray作为一款强大的被动/主动漏洞扫描器，其可扩展的POC（Proof of Concept）引擎，则能深入挖掘潜在的安全风险。然而，一个尴尬的现实是：工具的威力，很大程度上取决于你“喂”给它的“弹药”是否新鲜、是否精准。很多团队还在手动从各个论坛、GitHub仓库零散地收集POC，然后一个个手动导入、测试、筛选，效率低下不说，还容易引入无效甚至有害的脚本。

这就是“武器库升级”的核心痛点。它不是一个简单的“下载-导入”动作，而是一套从POC的定制开发、批量获取、自动化验证到无缝集成到扫描流程的完整体系。想象一下，当一个新的漏洞（比如某个流行框架的RCE）爆发时，你的Goby和Xray能否在半小时内，自动获取到经过验证的POC，并开始对全网资产进行扫描？这背后需要的，正是一套“定制并批量喂食”的流水线。本文将从一个实战者的角度，拆解如何构建这套流水线，让你的红队武器库从“手动装填”升级为“智能补给”。

2. 核心思路：构建自动化POC供应链

单纯地收集POC合集只是第一步，甚至是最初级的一步。一个高效的武器库，其POC管理应当像现代软件开发的CI/CD（持续集成/持续部署）管道一样，具备自动化、可验证和可追溯的特性。

2.1 从“收集”到“供应链”的思维转变

传统的做法是：漏洞预警 -> 全网搜索POC -> 下载 -> 手动测试 -> 导入工具。这个过程存在几个致命问题：

1. 时效性差：等你手动找到可用的POC，可能已经过去半天，黄金攻击/防御时间已过。
2. 质量不可控：网络上的POC脚本质量参差不齐，可能存在语法错误、逻辑缺陷，甚至隐藏后门。
3. 维护成本高：POC需要随目标系统更新而更新，手动维护成百上千个POC是不现实的。

我们的目标是将这条链路升级为：漏洞预警 -> 自动触发POC仓库同步 -> 自动化基础测试与过滤 -> 自动分类并分发至Goby/Xray -> 生成扫描任务。这要求我们建立一个中心化的POC管理仓库，并围绕它打造一系列自动化脚本。

2.2 工具链选型与角色定位

• Goby：定位为资产发现与初筛利器。它的优势在于快速端口扫描、协议识别、Web资产发现，并内置了许多漏洞检测模块。我们为其“喂食”POC，主要是丰富其“漏洞扫描”模块的能力，尤其是针对一些Goby官方尚未及时收录的、最新的或行业特定的漏洞。
• Xray：定位为深度漏洞挖掘引擎。它专精于Web漏洞扫描，支持主动和被动模式。其POC（在Xray中通常以YAML格式定义）功能极其灵活。我们为其“喂食”POC，是直接扩充其核心检测能力，是深度扫描的主要火力来源。
• POC来源：通常包括以下几个渠道：
  • 官方仓库：如Xray官方社区版POC库，这是质量最高、兼容性最好的来源。
  • GitHub开源项目：例如nuclei-templates(虽然Nuclei是另一款工具，但其模板思路与POC类似，部分经修改后可转换)、pocsuite3的POC库等。这里是新POC的聚集地。
  • 商业或社区漏洞情报平台：一些平台会提供结构化的POC数据。
  • 自研POC：针对内部系统或特定组件开发的检测脚本。

注意：从第三方获取POC时，安全审查是必须的。永远不要在未经人工或沙箱环境审查的情况下，直接将未知来源的脚本投入生产环境使用。一个简单的做法是建立一个隔离的虚拟机环境，用于初步运行和审查POC脚本。

3. 实操准备：搭建POC管理仓库与环境配置

在开始批量“喂食”之前，我们需要一个整洁的“厨房”和标准的“食谱”（POC格式）。

3.1 建立本地POC主仓库

我强烈建议使用Git来管理你的POC库。这不仅便于版本控制，也方便与远程源同步。

# 在你的工作目录，例如 /opt/redteam/poc_repo mkdir -p /opt/redteam/poc_repo/{goby_plugins,xray_pocs,scripts,temp} cd /opt/redteam/poc_repo git init

目录结构说明：

• goby_plugins/: 存放适用于Goby的漏洞检测插件（通常是.js或.json格式）。
• xray_pocs/: 存放Xray格式的POC文件（.yml或.yaml）。
• scripts/: 存放我们用来实现自动化“喂食”的Python/Bash脚本。
• temp/: 临时下载和处理的目录。

3.2 理解Goby与Xray的POC格式

Goby POC格式： Goby的漏洞检测插件本质上是JavaScript文件，它需要导出一个特定的函数。一个最简单的示例骨架如下：

// goby_plugins/CVE-2024-12345-Example.js exports.scan = function(ip, port, hostname, url) { // 1. 构建检测请求 var path = "/api/v1/test"; var opts = { url: url + path, method: 'GET', headers: {'User-Agent': 'Goby Vuln Scanner'} }; // 2. 发送请求并检查响应 var resp = goby.http(opts); if (resp.statusCode == 200 && resp.body.includes("vulnerable_keyword")) { // 3. 发现漏洞，报告结果 return { type: 'vul', // 类型为漏洞 target: url, level: 'high', // 危险等级 detail: { "Vul ID": "CVE-2024-12345", "Name": "Example Product RCE", "Description": "在Example Product的API接口中存在命令注入漏洞。", "Solution": "升级至最新版本。", "Payload": opts // 可选的，记录触发请求 } }; } // 4. 未发现漏洞，返回null或空 return null; };

Xray POC格式： Xray的POC使用YAML定义，更加结构化。一个基础模板如下：

# xray_pocs/cve-2024-12345-example.yml name: poc-yaml-example-product-rce rules: - method: GET path: /api/v1/test headers: User-Agent: Xray expression: | response.status == 200 && response.body.bcontains(b"vulnerable_keyword") detail: author: yourname links: - https://example.com/cve-2024-12345 vuln_id: CVE-2024-12345 description: Example Product API命令注入漏洞

3.3 基础环境配置

确保你的操作机上安装了必要的工具：

• Python 3.6+：用于编写自动化脚本。
• Git：用于同步远程POC库。
• jq（可选）：用于处理JSON数据，在解析一些API响应时非常方便。
• Goby & Xray：当然，你需要已经安装并配置好这两款工具。记住Xray的配置文件路径（通常为config.yaml）和Goby的插件目录（位于Goby安装目录下的plugins文件夹）。

4. 核心环节一：POC的批量获取与同步

手动下载的时代结束了。我们将编写脚本，自动从选定的源头拉取最新的POC。

4.1 编写自动化同步脚本

以下是一个Python脚本示例，用于从GitHub仓库同步POC。我们以同步Xray社区版POC为例。

#!/usr/bin/env python3 # scripts/sync_xray_pocs.py import os import sys import yaml import subprocess import shutil from pathlib import Path # 配置 XRAY_OFFICIAL_REPO = "https://github.com/chaitin/xray.git" LOCAL_XRAY_POC_DIR = Path("/opt/redteam/poc_repo/xray_pocs/official") TEMP_CLONE_DIR = Path("/opt/redteam/poc_repo/temp/xray_repo") def sync_from_github(): """从GitHub官方仓库同步POC""" print("[*] 开始同步Xray官方POC库...") # 清理并克隆仓库 if TEMP_CLONE_DIR.exists(): shutil.rmtree(TEMP_CLONE_DIR) TEMP_CLONE_DIR.mkdir(parents=True, exist_ok=True) try: subprocess.run(['git', 'clone', '--depth', '1', XRAY_OFFICIAL_REPO, TEMP_CLONE_DIR], check=True) except subprocess.CalledProcessError as e: print(f"[-] 克隆仓库失败: {e}") return False # 定位POC文件 (通常位于 /pocs/ 目录下) source_poc_dir = TEMP_CLONE_DIR / "pocs" if not source_poc_dir.exists(): print(f"[-] 在仓库中未找到pocs目录: {source_poc_dir}") return False # 清空目标目录并复制新文件 if LOCAL_XRAY_POC_DIR.exists(): shutil.rmtree(LOCAL_XRAY_POC_DIR) LOCAL_XRAY_POC_DIR.mkdir(parents=True, exist_ok=True) # 复制所有.yml/.yaml文件 for poc_file in source_poc_dir.rglob("*.yml"): shutil.copy2(poc_file, LOCAL_XRAY_POC_DIR / poc_file.name) for poc_file in source_poc_dir.rglob("*.yaml"): shutil.copy2(poc_file, LOCAL_XRAY_POC_DIR / poc_file.name) poc_count = len(list(LOCAL_XRAY_POC_DIR.glob("*.yml"))) + len(list(LOCAL_XRAY_POC_DIR.glob("*.yaml"))) print(f"[+] 同步完成。共获取 {poc_count} 个官方POC文件。") # 清理临时目录 shutil.rmtree(TEMP_CLONE_DIR) return True if __name__ == "__main__": sync_from_github()

你可以为不同的来源（如多个GitHub仓库）编写类似的函数，并在一个主脚本中调度它们。

4.2 集成多个POC来源

一个更健壮的同步器应该管理多个源。我们可以创建一个配置文件sources.yaml：

sources: - name: xray-official type: git url: https://github.com/chaitin/xray.git path: pocs target_local_dir: xray_pocs/official enabled: true - name: nuclei-templates type: git url: https://github.com/projectdiscovery/nuclei-templates.git path: . target_local_dir: temp/nuclei_raw # 先存到临时目录，需要转换 enabled: true - name: custom-pocs type: local path: /path/to/your/custom/pocs target_local_dir: xray_pocs/custom enabled: true

然后编写脚本读取这个配置，遍历所有启用的源进行同步。对于nuclei-templates这类格式不同的源，你还需要一个转换模块，这将是下一个重点。

实操心得：同步频率很重要。对于官方源，可以每天同步一次。对于活跃的社区源，可以设置每4-6小时同步。但过于频繁可能会被GitHub限流。建议使用cron job或系统定时任务来调度同步脚本，例如0 */6 * * * /usr/bin/python3 /opt/redteam/poc_repo/scripts/sync_all.py。

5. 核心环节二：POC的格式转换与标准化

从不同渠道获取的POC格式五花八门。我们需要将它们“翻译”成Goby和Xray能理解的“语言”。

5.1 将Nuclei模板转换为Xray POC

Nuclei模板（YAML格式）与Xray POC（YAML格式）在思路上相似，但结构不同。转换需要解析关键字段。

# scripts/convert_nuclei_to_xray.py import yaml import re from pathlib import Path def convert_nuclei_template(nuclei_file_path, output_dir): """将一个Nuclei模板文件转换为Xray POC格式""" with open(nuclei_file_path, 'r', encoding='utf-8') as f: try: template = yaml.safe_load(f) except yaml.YAMLError as e: print(f"[-] 解析YAML失败 {nuclei_file_path}: {e}") return None id = template.get('id', 'unknown').replace('/', '-') info = template.get('info', {}) name = info.get('name', id) severity = info.get('severity', 'info').lower() # nuclei的严重等级 # 映射严重等级到Xray的漏洞类型（粗略映射） severity_map = {'critical': 'high', 'high': 'high', 'medium': 'medium', 'low': 'low', 'info': 'info'} xray_level = severity_map.get(severity, 'info') http_requests = template.get('http', []) if not http_requests: return None # 非HTTP类型的POC暂不处理 # 取第一个HTTP请求块进行转换（简化处理，复杂模板需更精细解析） first_req = http_requests[0] method = first_req.get('method', 'GET') path = first_req.get('path', '/') # 处理路径中的变量，如 {{BaseURL}}， Xray中使用 `{{Hostname}}` 等 path = path.replace('{{BaseURL}}', '{{RootURL}}').replace('{{Hostname}}', '{{Hostname}}') headers = first_req.get('headers', {}) body = first_req.get('body', '') matchers = first_req.get('matchers', []) condition = first_req.get('matchers-condition', 'and') expressions = [] # 简化：将matchers转换为Xray的expression表达式（这是一个复杂点，此处仅做示例） for matcher in matchers: m_type = matcher.get('type', 'word') if m_type == 'word': words = matcher.get('words', []) for word in words: # 简单转换为响应体包含关键词 expressions.append(f'response.body.bcontains(b"{word}")') elif m_type == 'status': status = matcher.get('status', []) if status: expressions.append(f'response.status == {status[0]}') # 可以添加更多matcher类型的处理... if not expressions: expressions.append("true") # 默认匹配 # 构建Xray POC字典 xray_poc = { 'name': f'poc-yaml-{id}', 'transport': 'http', 'rules': [ { 'method': method, 'path': path, 'headers': headers, 'body': body if body else None, 'expression': ' && '.join(expressions) if condition == 'and' else ' || '.join(expressions) } ], 'detail': { 'author': 'converted-from-nuclei', 'links': info.get('reference', []), 'vuln_id': id, 'description': info.get('description', ''), 'severity': xray_level } } # 移除值为None的项 xray_poc['rules'][0] = {k: v for k, v in xray_poc['rules'][0].items() if v is not None} # 生成输出文件名和路径 output_filename = f"{id}.yml" output_path = Path(output_dir) / output_filename with open(output_path, 'w', encoding='utf-8') as out_f: yaml.dump(xray_poc, out_f, allow_unicode=True, sort_keys=False) print(f"[+] 已转换: {nuclei_file_path.name} -> {output_path}") return output_path

这个转换器是高度简化的，实际生产中，Nuclei的matchers、extractors和复杂的多阶段请求（raw请求）需要更精细的解析才能完整、准确地转换为Xray的expression。这通常需要根据团队常用的模板类型进行定制开发。

5.2 将通用POC脚本转换为Goby插件

对于网络上用Python、Go等语言编写的独立POC脚本，我们可以将其核心检测逻辑“包裹”进Goby插件的标准格式里。思路是：用子进程调用原POC脚本，并解析其输出。

假设我们有一个用Python写的POC脚本poc_cve_2024_12345.py，它接受一个URL参数，并返回JSON格式的结果。

# scripts/wrap_to_goby.py 示例片段 import subprocess import json import sys def run_external_poc(target_url, poc_script_path): """调用外部POC脚本并获取结果""" try: # 假设你的POC脚本支持 `-u` 参数指定目标，并以JSON格式输出 result = subprocess.run( [sys.executable, poc_script_path, '-u', target_url], capture_output=True, text=True, timeout=30 # 设置超时，防止卡死 ) if result.returncode == 0: # 尝试解析标准输出中的JSON output_lines = result.stdout.strip().split('\n') for line in output_lines: if line.startswith('{'): try: return json.loads(line) except json.JSONDecodeError: continue except subprocess.TimeoutExpired: return {'error': 'POC执行超时'} except Exception as e: return {'error': str(e)} return None # 然后，在Goby插件的scan函数中调用 # exports.scan = function(ip, port, hostname, url) { # var pocPath = “/path/to/poc_cve_2024_12345.py”; # // 这里需要通过goby的某种方式调用Python？实际上Goby插件JS环境无法直接调。 # // 更可行的方案是：将外部POC的核心逻辑用JS重写，或者让Goby插件调用一个本地API服务。 # }

实际上，由于Goby插件运行在其内置的JavaScript环境中，直接调用外部Python脚本非常困难且不稳定。更实用的做法是：

1. 重写逻辑：将简单POC的检测逻辑直接用JavaScript重写，如前文所示的Goby插件模板。
2. 建立RESTful API服务：部署一个轻量级的Python Flask/FastAPI服务，该服务集成了各种复杂的POC执行引擎（如pocsuite3）。Goby插件通过HTTP请求调用这个服务的接口，传递目标信息，获取检测结果。这种方式将复杂的POC执行环境与Goby解耦，更加灵活和强大。

// Goby插件通过HTTP调用本地POC服务的示例 exports.scan = function(ip, port, hostname, url) { var apiEndpoint = "http://127.0.0.1:5000/scan"; var opts = { url: apiEndpoint, method: 'POST', headers: {'Content-Type': 'application/json'}, body: JSON.stringify({ target: url, poc_id: "CVE-2024-12345" }) }; var resp = goby.http(opts); if (resp.statusCode == 200) { var result = JSON.parse(resp.body); if (result.vulnerable) { return { type: 'vul', target: url, level: result.level, detail: result.detail }; } } return null; };

6. 核心环节三：自动化验证与质量过滤

不是所有同步下来的POC都是可用的。我们需要一个“质检环节”。

6.1 设计POC基础验证流程

验证的目标是确保POC语法正确，并且能在可控的环境下产生预期的行为（如访问一个无害的测试端点返回特定内容）。可以编写一个验证脚本，对仓库中的每个POC进行以下检查：

1. 语法检查：对于YAML格式的Xray POC，使用yaml.safe_load()检查是否能正确解析。对于Goby的JS插件，可以使用Node.js的语法检查工具（如eslint或直接node -c）进行粗略检查。
2. 结构校验：检查必需的字段是否存在（如Xray POC的name、rules，Goby插件的exports.scan函数）。
3. 模拟测试（可选但推荐）：搭建一个简单的HTTP测试服务器（例如使用Python的http.server或mitmproxy），该服务器针对特定路径返回预设的“漏洞响应”。然后使用Xray的--poc参数或Goby的调试功能，针对这个测试服务器运行POC，看是否能正确触发漏洞发现。这能有效过滤掉那些逻辑错误或过时的POC。

# scripts/validate_xray_poc.py (简化版) import yaml import subprocess import tempfile import os from pathlib import Path def validate_single_poc(poc_file_path, test_server_url="http://test.local"): """验证单个Xray POC文件""" print(f"[*] 验证 {poc_file_path.name}...") # 1. 语法与结构检查 try: with open(poc_file_path, 'r', encoding='utf-8') as f: poc_data = yaml.safe_load(f) except yaml.YAMLError as e: print(f" [-] YAML语法错误: {e}") return False except Exception as e: print(f" [-] 文件读取错误: {e}") return False required_fields = ['name', 'rules'] for field in required_fields: if field not in poc_data: print(f" [-] 缺少必需字段: {field}") return False # 2. 使用Xray CLI进行快速测试（假设Xray已安装） # 注意：这里需要有一个安全的、不会造成实际影响的测试目标。 # 我们可以使用一个专门用于测试的、隔离的容器或服务。 # 以下命令仅为示例，实际需要配置一个测试模式下的Xray。 # cmd = ['xray', 'webscan', '--poc', str(poc_file_path), '--url', test_server_url, '--json-output'] # try: # result = subprocess.run(cmd, capture_output=True, text=True, timeout=10) # # 解析结果，判断POC是否正常执行（不一定是触发漏洞） # except subprocess.TimeoutExpired: # print(f" [-] 验证超时，POC可能存在问题") # return False # except Exception as e: # print(f" [-] 执行验证时出错: {e}") # return False print(f" [+] 基础验证通过") return True

6.2 建立POC分类与标签体系

随着POC数量增多，有效的分类能极大提升使用效率。可以在POC文件的detail部分或通过独立的元数据文件（如index.json）来添加标签。

// 元数据文件示例 { "pocs": [ { "file": "cve-2024-12345-example.yml", "name": "Example Product RCE", "vuln_id": "CVE-2024-12345", "severity": "high", "product": ["Example", "Web Framework"], "category": ["rce", "command-injection"], "author": "official", "synced_date": "2024-05-27", "validated": true } ] }

然后，你可以编写脚本，让Goby或Xray按需加载特定分类的POC。例如，在针对Java应用进行扫描时，只加载product中包含Java或Spring标签的POC，可以显著提升扫描速度和准确性。

7. 核心环节四：批量“喂食”与动态加载

这是最后一步，也是将自动化成果落地的关键。

7.1 向Xray批量添加POC

Xray的POC加载方式很简单，将所有.yml或.yaml文件放入其pocs目录（通常在~/.config/xray/或程序同级目录下的pocs文件夹）即可。我们的自动化脚本只需要完成复制操作。

# scripts/deploy_to_xray.sh #!/bin/bash SOURCE_DIR="/opt/redteam/poc_repo/xray_pocs" XRAY_POC_DIR="$HOME/.config/xray/pocs" echo "[*] 开始部署POC到Xray..." # 清空原有POC（可选，建议备份） # mv "$XRAY_POC_DIR" "$XRAY_POC_DIR.bak.$(date +%Y%m%d%H%M%S)" # mkdir -p "$XRAY_POC_DIR" # 复制所有已验证的POC find "$SOURCE_DIR" -name "*.yml" -o -name "*.yaml" | while read -r poc_file; do # 这里可以加入验证状态的检查，例如只复制validated=true的 cp "$poc_file" "$XRAY_POC_DIR/" done echo "[+] 部署完成。重启Xray或等待其自动重载POC。"

Xray支持热重载，通常不需要重启。你可以通过Xray的HTTP API（如果启用）触发重载，或者直接等待其下一个扫描周期自动加载新的POC。

7.2 向Goby批量添加插件

Goby的插件需要放置在其安装目录的plugins文件夹内。同样，一个复制脚本即可。

# scripts/deploy_to_goby.sh #!/bin/bash SOURCE_DIR="/opt/redteam/poc_repo/goby_plugins" # 你需要根据你的Goby安装路径修改下面这行 GOBY_PLUGIN_DIR="/Applications/Goby.app/Contents/Resources/plugins" # macOS示例 # GOBY_PLUGIN_DIR="C:\Program Files\Goby\plugins" # Windows示例（需在Git Bash或WSL中运行） if [ ! -d "$GOBY_PLUGIN_DIR" ]; then echo "[-] Goby插件目录未找到: $GOBY_PLUGIN_DIR" exit 1 fi echo "[*] 开始部署插件到Goby..." find "$SOURCE_DIR" -name "*.js" | while read -r plugin_file; do cp "$plugin_file" "$GOBY_PLUGIN_DIR/" done echo "[+] 部署完成。请在Goby中刷新或重启Goby以加载新插件。"

Goby通常需要重启或手动在插件管理界面点击“刷新”来加载新插件。

7.3 实现动态加载与更新通知

更高级的做法是，编写一个常驻的“喂食器”服务。这个服务监控本地POC仓库的变化（例如通过inotify或定时检查Git状态），一旦发现有新的、已验证的POC文件，就自动将其复制到Goby和Xray的对应目录，并发送通知（如桌面通知、Slack消息等）。

# scripts/feeder_daemon.py (概念示例) import time import shutil from watchdog.observers import Observer from watchdog.events import FileSystemEventHandler class PocUpdateHandler(FileSystemEventHandler): def on_created(self, event): if event.is_directory: return if event.src_path.endswith(('.yml', '.yaml', '.js')): print(f"[*] 检测到新POC文件: {event.src_path}") # 这里可以加入验证逻辑 # if validate_poc(event.src_path): deploy_poc(event.src_path) # 调用部署函数 send_notification(f"新POC已就绪: {os.path.basename(event.src_path)}") def main(): path_to_watch = "/opt/redteam/poc_repo" event_handler = PocUpdateHandler() observer = Observer() observer.schedule(event_handler, path_to_watch, recursive=True) observer.start() try: while True: time.sleep(1) except KeyboardInterrupt: observer.stop() observer.join()

8. 实战问题排查与优化心得

在实际搭建和运行这套系统的过程中，你肯定会遇到各种问题。以下是我踩过的一些坑和解决方案。

8.1 常见问题速查表

8.2 性能与稳定性优化建议

1. 分级扫描策略：不要一开始就对所有目标使用全部POC。建议分为三级：
   • 快速扫描：使用Goby内置漏洞库和少量高危通用POC，进行初筛。
   • 深度扫描：对快速扫描中发现的可疑目标，使用Xray配合完整的、针对性的POC库进行深度检测。
   • 定点验证：对深度扫描中发现的潜在漏洞，使用独立的、更精确的POC脚本进行人工验证。
2. POC去重与合并：不同来源的POC库可能存在大量重复（针对同一个CVE）。定期运行去重脚本，根据CVE ID或漏洞特征进行合并，保留质量最高的一个版本。
3. 建立POC失效反馈机制：在扫描日志中，记录哪些POC从未触发过，或者在大量扫描中成功率极低。定期审查这些POC，可能是漏洞已修复、POC已过时，或者其检测条件过于严苛。这是一个持续优化武器库质量的关键步骤。
4. 安全隔离：运行POC，尤其是来自第三方或自研的POC，存在一定风险。建议在独立的虚拟机或容器环境中运行整个“喂食”流水线和扫描任务，与日常工作环境隔离。

8.3 关于“Goby设置中文”和“Burp联动Xray”

这两个是相关的高频搜索词，在此简要说明如何融入我们的体系：

• Goby设置中文：这通常指Goby客户端的界面语言。在Goby的设置（Settings）中，可以找到语言（Language）选项，选择“简体中文”即可。这个设置是客户端本地的，不影响我们通过插件扩展其功能。
• Burp联动Xray：这是另一个强大的工作流。Xray可以作为Burp Suite的被动扫描插件。配置好后，你在Burp中浏览的所有流量都会自动经过Xray的POC引擎检测。我们的自动化“喂食”体系对此同样有效！因为你批量更新到Xray POC目录中的任何新POC，在Burp联动模式下，Xray都会自动加载并使用它们进行被动扫描。这意味着，你为Xray“喂食”的每一发新“弹药”，都能同时在主动扫描和被动监听（Burp联动）两种模式下发挥作用，最大化其价值。

构建这样一套自动化POC供应链，初期投入确实需要一些时间，但一旦运转起来，它带来的效率提升和响应速度是质的飞跃。它让你从POC的“搬运工”变成了武器库的“架构师”，能够更从容地应对瞬息万变的安全威胁。最后，记住一点：自动化是为了让人做更高级的决策，而不是完全取代人。定期审查你的POC库，加入你自己的思考和创作，这才是红队能力的核心壁垒。