Airgorah IPC协议深度剖析：WiFi安全审计工具的4字节长度前缀JSON帧与SO

Airgorah IPC协议深度剖析：WiFi安全审计工具的4字节长度前缀JSON帧与SO_PEERCRED身份验证完整指南

【免费下载链接】airgorahA WiFi security auditing software项目地址: https://gitcode.com/gh_mirrors/ai/airgorah

Airgorah是一款用 Rust 编写的 LinuxWiFi 安全审计工具（抓包、发现客户端、去认证攻击、捕获握手、破解密码）。它的 GUI 以普通用户运行，特权操作则交给 root 权限的airgorah-agent完成——两者之间的桥梁，正是本文要剖析的IPC 协议：一套基于 Unix 套接字的4 字节长度前缀 JSON 帧，配合内核级的SO_PEERCRED 身份验证。理解这套设计，你也能给自己的多进程安全工具装上"信任之锁"。

为什么安全审计工具必须拆成两个进程？

把 root 权限交给整个 GUI 是很危险的：一旦界面进程出 bug 或被利用，攻击者就直接拿到了 root。Airgorah 的解决方案是权限最小化：

进程	权限	职责	入口
`airgorah`（GUI）	普通用户	界面、扫描结果展示、无特权操作	crates/gui/src/main.rs
`airgorah-agent`	root（经 polkit 提权）	监听模式切换、扫描、去认证攻击、抓包读写	crates/agent/src/main.rs

GUI 只在用户真正点击"开始扫描"这类操作时，才通过pkexec拉起 agent（见 client.rs 中的ensure_agent）。整条链路只有一个提权点，而连接建立后的信任判定，就交给了下面这套 IPC 协议。

线格式解析：4字节长度前缀 JSON 帧是怎么工作的？

完整的协议契约定义在一个文件里：crates/common/src/ipc.rs，它被 GUI 和 agent 两侧共享，确保双方对"字节流如何切分成消息"理解完全一致。

一帧消息长什么样？

帧结构极其简单，只有两部分：

4 字节大端序长度前缀（u32::to_be_bytes）——声明后面 JSON 负载有多少字节
JSON 负载——序列化后的Request（GUI→agent）或Response（agent→GUI）

发送端在 write_msg 中完成："序列化 → 检查超限 → 写 4 字节长度 → 写负载 → flush"；接收端在 read_msg 中镜像操作："先read_exact读满 4 字节长度 → 按声明长度读满负载 → JSON 反序列化"。

💡 为什么选"长度前缀 + JSON"？二进制协议（如 protobuf）更紧凑，但 JSON 帧可用 nc、tcpdump 等手段人工抓读，调试排障时一目了然；长度前缀则解决了 TCP/Unix 流式套接字没有"消息边界"的根本问题。

64MB 上限：防止"假长度前缀"的护城河

恶意或损坏的连接可能伪造一个天大的长度值，诱导接收端分配巨量内存。Airgorah 在读写两端都设置了硬上限MAX_MSG_LEN = 64 MiB（见 ipc.rs#L14-L15），超限直接拒绝。这是长度前缀协议的标准安全实践，一行常量挡住了一整类拒绝服务攻击。

请求与响应：一份自描述的"接口合同"

协议的两个枚举就是全部 API 表面：

Request（GUI 发出）：Hello、EnableMonitor、StartScan、StartDeauth、GetCaptureChunk、Shutdown等 15 种指令
Response（agent 回复）：Ok、Error、Setup（依赖检查结果）、ScanData（扫描快照）、CaptureChunk（抓包分片）等

得益于 Rust 的枚举 + serde，新增一条指令只需改一处枚举，编译期就强制两边同步，不会出现"GUI 发了 agent 不认识的命令"这种运行时事故。一个有趣的细节是GetCaptureChunk { offset }：root 的 agent 不能替用户写文件，于是抓包数据被切成有界分片、由 GUI 以用户身份落盘——数据越权与文件权限问题在此一并解决（见 client.rs#L433-L469）。

SO_PEERCRED 身份验证：用内核当裁判

光有"能连上 socket"还不够——socket 文件在/run/airgorah/下，如果本地其他用户也能连进来，root 权限就等于开了后门。Airgorah 用了三层防线：

第一层：文件系统权限

agent 绑定 socket 后，立即把权限收紧为0o600并chown给启动者用户（secure_socket）。路径本身也包含用户 uid：/run/airgorah/{uid}-{pid}.sock，每个 GUI 实例独占一条通道，多开实例互不干扰。

第二层：SO_PEERCRED 内核凭证核验（核心）

文件权限终究是"软防线"。真正硬核的一招在 server.rs#L24-L42：每次accept()之后，agent 通过getsockopt(SO_PEERCRED)向内核索要对端的 uid/gid/pid。这些数据由内核直接从连接发起进程的凭证填充，用户态无法伪造。agent 把它与启动时记录的"目标 uid"比对，不匹配就拒绝服务并记日志。

agent 的目标 uid 从哪来？pkexec提权时会导出PKEXEC_UID环境变量，指明"是哪个普通用户请求的提权"（见 resolve_target_uid）。这就形成闭环：谁能触发提权，谁就拿到 socket 归属权，内核再当面核验每次连接的真实身份。

第三层：参数再验证——"GUI 是低信任调用方"

即便身份核验通过，agent 依然把 GUI 当低信任方：凡是会变成命令行参数的字段，都要再过一遍白名单验证（validate.rs）——网卡名限 15 字符且只能含字母数字和_.-，MAC 必须是标准 6 组十六进制。这是防止命令注入的关键一步：权限边界存在的那一刻，边界另一侧的任何输入都不可信。

Hello 握手：第一条消息就验版本、查依赖

连接建立的第一个往返值得单独说（server.rs#L80-L98）：

GUI 发送Hello { version }，携带自己的协议版本号
agent 比对版本，不一致立即返回Error（避免新旧二进制混用的诡异行为）
版本一致则回复Setup { missing_dependencies }，一次性报告 agent 侧缺失的外部工具（如 airodump-ng 依赖），GUI 据此在启动时就给用户明确提示

这套"版本协商 + 依赖自检"把环境问题从"第一次扫描时才炸"提前到"连接时就说清楚"，用户体验差异巨大。

一对一连接与自动清理：不留后患的设计

最后两个工程细节让整个 IPC 通道"闭环"：

单客户端模型：agent 只accept()一次，只服务拉起它的那个 GUI。连接断开（read_msg收到UnexpectedEof，见 handle_connection）即触发清理——网卡不会残留在监听模式，扫描进程不会成为孤儿。
双通道退出：GUI 优雅退出时先发Shutdown指令；若进程被强杀，socket EOF 与 SIGINT 信号处理器（main.rs#L60-L67）兜底清理特权现场。

小结：这套 IPC 设计有哪些可借鉴点？

设计点	解决的问题
4 字节大端长度前缀 + JSON 帧	流式套接字的消息边界；可读性好、易调试
64MB 帧长硬上限	防伪造长度前缀导致的内存滥用
`SO_PEERCRED`内核凭证核验	用户态无法伪造的真实身份验证
socket 路径含`uid-pid`+`0o600`	实例隔离与最小可达面
Hello 版本协商 + 依赖自检	二进制版本漂移与缺失依赖的早失败
特权侧参数白名单再验证	跨权限边界的命令注入防御
断连即清理（EOF / Shutdown / 信号三路兜底）	特权状态不留孤儿