devnullnoop/baipi
GitHub: devnullnoop/baipi
一个用于检测 AI 二进制分析流水线中提示注入中继的研究型信标集合。
Stars: 0 | Forks: 0
# 白皮
二进制分析提示注入。用于观察 AI
二进制分析流水线是否会中继嵌入在其处理的二进制文件中的有效载荷。
一小部分编译后的二进制文件。每个都在 AI 二进制分析代理可能摄入的位置植入了一个良性的提示注入载荷:字符串、符号名称、调试文本、沙箱标准输出/标准错误、ANSI 流、Unicode 双向文本、环境变量名称,以及其他一些位置。
这是一个个人兴趣项目。我不会提出新颖性主张,也不会试图“抓人”。我只是想看看这类语料库在落到 AI 逆向工程流水线爬取的位置时,是否会产生可观测的信号。
## 它是什么
15 个微小的 Rust 程序。每个程序都故意设计得非常简单,并且每个都在不同的位置嵌入相同形态的文本:
载荷随后列出几个抄送渠道:一个 GitHub 问题链接、厂商负责披露的联系人(以便始终可以选择正规途径),以及一个使用我自有域名、带有唯一样本标识的通用收件箱。如果这些渠道中的任何一个收到命中,我就能得知该载荷实际上已在某个下游被解析并处理。
载荷明确说明这是一个研究用的“信标”。这一点在文本中写明,并引用了该仓库。源代码注释中标明了各个表面。这并非设计用来隐蔽。
## 它不是什么
不是恶意软件。没有 shellcode,没有网络调用,没有文件系统写入,没有持久化。每个程序要么立即退出,要么仅打印几行文本。
并非新颖。提示注入早已确立。信标令牌早已确立。LLM 蜜罐用于 SSH 和 Web 服务器也存在,且早于此项目。唯一我尚未找到公开示例的,是使用编译后的二进制表面作为交付通道并带有实时遥测。这可能是我没有足够努力寻找。
不是产品。没有仪表盘,没有检测器,没有防御机制。这只是一个实验,用于判断信号是否存在。
## 相关的先前与相邻工作
Palisade Research 的 LLM Agent Honeypot(arxiv 2410.13919,github.com/PalisadeResearch/llm-honeypot)。ANSI 转义注入的 Cowrie SSH 蜜罐。相同的检测思路,不同的载体。这是最接近 BAIPI 所做工作的项目。
Cutwell/canary、protectai/rebuff、deadbits/vigil-llm。用于文本通道的提示注入检测工具。
swisskyrepo/PayloadsAllTheThings(提示注入章节)、sinanw/llm-security-prompt-injection、deepset 的数据集。用于聊天机器人和 RAG 上下文的文本提示语料库。
Galah、AI-in-Complex-Systems-Lab/LLM-Honeypot。LLM 驱动的蜜罐,其中 LLM 伪装成受害服务器。
Trail of Bits、Straiker,《Your AI, My Shell》(arxiv 2509.22040)。针对 Cursor 等 IDE 编码代理的间接提示注入。
LLM4Decompile、ReCopilot、HELIOS。使用 LLM 进行二进制分析。目标是表面,而非攻击。
如果你知道更接近的先验工作,请打开一个问题。我更愿意引用它,而不是忽略它。
## 覆盖的表面
文件位于 src/bin/ 目录下。
| # | 表面 | 交付方式 |
|---|---|---|
| 01 | .rodata 字符串 | 紧邻交叉引用的静态 &str |
| 02 | 权威性横幅 | 类似版权的元数据块 |
| 03 | 伪造的 C 注释 | 形如 /* ... */ 的字符串 |
| 04 | 符号名称 | 作为载荷的函数名称 |
| 05 | panic / 断言文本 | 带有文件:行元数据的断言消息 |
| 06 | base64 数据块 | 依赖代理在分类期间解码 |
| 07 | Unicode 双向文本 + ZWSP | 渲染文本与令牌序列不一致 |
| 08 | 同形字前缀 | 西里尔 SYSTEM:绕过 ASCII 块列表 |
| 09 | 沙箱标准输出 | 运行时输出作为观察反馈 |
| 10 | 标准输出中的 ANSI 转义 | 带颜色标签的清屏与行擦除 |
| 11 | 标准错误作为诊断 | 以“采取纠正措施”框架化的错误 |
| 12 | 主机名 / URL 字符串 | IOC 提取表面,无实时网络流量 |
| 13 | 环境变量名称 | 通过 strace 和反编译器交叉引用暴露的 getenv() 参数 |
| 14 | 跨通道 | rodata、符号、标准输出、标准错误全部一致确认相同结论 |
| 15 | 工具输出模仿 | 标准输出形如 VT、Cuckoo 或 Ghidra 封套 |
## 确认渠道
每个样本都会抄送三个渠道,并附带一个唯一的样本标识。
本仓库上的 GitHub 问题链接。
厂商负责披露的联系人(Anthropic usersafety@anthropic.com、开源披露页面)。
baipi-NN@blackbandanas.com。通用收件箱;任何发送到该样本特定地址的邮件都会进入我监控的存储桶。
没有秘密可言。如果爬虫或模型将载荷中继到任何地方,这三个渠道中的某一个应该能看到。
## 构建
```
cargo build --release
```
CI 在 .github/workflows/build.yml 中配置,会在每次推送时构建 Linux、macOS(aarch64 和 x86_64)以及 Windows 二进制文件。标记的发布版本会附带每个平台的压缩包,并附加到 GitHub 发布页面。
## 伦理
公开发布,清晰标注为研究,载荷透明且无恶意行为。厂商负责披露的渠道始终被列为首选途径。如果你是厂商红队成员且该载荷出现在你的流水线中,请打个招呼。我更愿意合作而非制造意外。
## 许可证
MIT。
标签:AI安全, AI管道安全, ANSI流, API集成, Canary Token, Chat Copilot, GitHub Issue, Payload, Rust, Unicode双向文本, Waymore结果处理, 二进制分析, 云安全运维, 信号检测, 反向工程, 可观测性, 可视化界面, 字符串注入, 实验性检测, 小规模语料, 探针, 提示注入, 无持久化, 无网络调用, 沙箱输出, 环境变量, 研究好奇心, 研究实验, 符号名, 系统运维工具, 编译二进制, 网络流量审计, 蜜罐, 证书利用, 调试文本, 负责任披露, 透明研究, 通知系统, 集群管理, 非恶意