VOID / AI PENTESTING

Void｜开源 AI 渗透测试 Agent

连接代码仓库、接口与测试环境，Void 自动分析攻击面、调用工具开展测试，并根据结果继续排查和验证漏洞。

当前环境暂未开放下载。

GitHub

固件深度安全评估

请对这份嵌入式设备固件进行深入安全评估，优先关注高风险问题，并保留可供人工复核的证据。

加载技能安全评估工作流

收到。本次先做固件离线静态分析，尚未接入实物设备。我会确认样本结构与授权边界，再把更新链、系统服务、调试接口和组件通信拆成并行任务。

Shell 命令 ls, file

$ ls -la "analysis/firmware" 2>/dev/null
file "analysis/firmware" 2>/dev/null

component-a.bin
component-b.bin
component-c.bin
header.json

analysis/firmware: directory

路径与名称已替换；目录列表仅摘取文件名列。

已创建 7 个分析任务，并行分析已启动。先沿着下面几个方向展开：

更新链：梳理软件来源确认、完整性检查与更新入口。
系统服务：读取启动配置、服务定义与可执行组件信息。
接口边界：从代码与配置检查调试能力、组件调用关系和权限约束。

Shell 命令 echo, grep, grep

$ S="analysis"
echo "=== component-a build.prop ==="
grep -E "ro.build.tags|ro.build.type|ro.debuggable|ro.build.fingerprint|security_patch|ro.product.device" "$S/containers/component-a/fs_root/build.prop"
echo "=== component-c build.prop ==="
grep -E "ro.build.tags|ro.build.type|ro.debuggable|ro.build.fingerprint|security_patch|ro.product.device" "$S/containers/component-c/fs_root/build.prop"

=== component-a build.prop ===
ro.build.type=userdebug
ro.build.tags=test-keys
ro.product.device=component-a
# ro.build.product is obsolete; use ro.product.device
=== component-c build.prop ===
ro.build.type=userdebug
ro.build.tags=test-keys
ro.product.device=component-c
# ro.build.product is obsolete; use ro.product.device

路径与名称已替换，输出节选；构建指纹及日期行已省略。

初步盘点完成，共登记 5 个攻击面。当前优先分析固件更新链与系统服务两类方向，正在离线检查文件系统、启动配置和可执行组件。

两类重点检查方向

固件更新链：沿代码中的处理流程检查各个更新入口，梳理来源与完整性校验的覆盖范围。
系统服务：沿启动脚本与服务配置梳理声明的权限，再检查维护、调试与组件间调用代码。

工具调用 2 项

Shell 命令 r2

$ UP="analysis/containers/component-a/fs_root/bin/update-service"
r2 -2 -q -c 'af @ update_handler; s digest_check; pd 70' "$UP" 2>/dev/null

    add x0, sp, 8
    …
    bl sym.imp.strncmp
    …
┌─< cbz w0, match_branch
│   …
│   bl debug_log
│   mov w21, -1
┌──< b merge_branch
    …

原指令节选；删除地址与机器码列，函数和跳转目标已换成符号别名。

Shell 命令 cd, openssl, cmp

$ cd "analysis/certificates"
openssl pkcs7 -inform DER -in package/META-INF/CERT.RSA -print_certs 2>/dev/null | openssl x509 -pubkey -noout 2>/dev/null > package-public.pem
openssl x509 -in trust/testkey.x509.pem -pubkey -noout 2>/dev/null > trusted-public.pem
cmp package-public.pem trusted-public.pem && echo "PUBKEY IDENTICAL (CERT.RSA signer == otacert testkey)" || echo "PUBKEY DIFFER"

PUBKEY IDENTICAL (CERT.RSA signer == otacert testkey)

路径与名称已替换；真实公钥比对结果，未进行设备安装验证。

更新链静态审查发现一个需要优先复核的问题：代码中的真实性校验没有覆盖完整链路。我已保存相关代码与配置证据，并继续检查回滚逻辑和外部介质更新入口。

读取文件 analysis/evidence/update-chain.md

## 详情

**现象**：更新容器内子固件的完整性字段来自 header.json 内的 md5sum；已验证 18 个子文件的摘要与清单一致。

帧内两个 4 字节字段 A/B 并非签名。

**证据（二进制级）**：component-a / component-c 的 update-service 反汇编：

① 无 RSA/cert/SSL 导入符号；

② 整包 MD5 期望值来自同一 TCP 信道的更新请求明文字段；

③ 逐成员 MD5File 失配仅打印日志后循环继续，最终返回成功；

④ 容器解析对字段 A/B 仅步进跳过，从不比较；

⑤ 子固件刷写仅做版本比较，版本字段同为包内自描述。

**缺口**：端到端触发链路与目标引导程序是否另有校验（工件外）。

## 裁决/证据来源

本会话静态分析（灰盒离线）。详见对应裁决与研究证据文件。

源 Finding 文档节选，路径、名称与敏感格式已替换；不是编辑 diff。

F-01 已登记。 当前静态证据说明更新内容的来源与完整性没有形成完整的确认链。记录中已写明证据位置、可能影响和需要设备验证的条件。

接下来继续对照各更新入口的校验策略，整理外部介质入口与主更新链之间的差异。

系统服务与调试配置的静态审查完成。样本中的部分维护服务和调试相关代码包含高权限操作能力；是否能在实际设备上触达，还需要结合启动条件与发行配置验证。

Shell 命令 sed

$ R="analysis/containers/component-c/boot/ramdisk"
sed -n '880,915p' "$R/init.rc"

    user root
    group root system

on property:ro.debuggable=1
    start console

# adbd is controlled via property triggers in init.<platform>.usb.rc
service adbd /runtime/sbin/adbd --root_seclabel=u:r:su:s0
    class core
    socket adbd stream 660 system system
    disabled
    seclabel u:r:adbd:s0

# adbd on at boot in emulator
on property:ro.kernel.qemu=1
    start adbd
…

路径已替换，输出节选；保留 disabled 和属性触发条件。

相关 Finding 已登记。记录里保留代码和配置所示的能力边界、可能影响与复核建议，后续可从看板查看关联静态证据。

组件通信的静态分析发现一条潜在线索：部分内部接口的调用方身份约束需要进一步确认。现有代码证据还不足以判断实际可达性与完整授权链，F-05 保留为待动态验证的线索。

Shell 命令 echo, r2, head

$ F="analysis/containers/component-c/fs_root"
for n in service-a update-service service-supervisor; do
  echo "==== $n ===="
  r2 -q -e bin.demangle=false -c "ii~bind;ii~listen;ii~accept;ii~socket;ii~connect;ii~inet" "$F/bin/$n" 2>/dev/null | head -30
done

==== service-a ====
nth bind   type lib name
61  GLOBAL FUNC     net_bind
42  GLOBAL FUNC     net_set_socket_noblock
==== update-service ====
nth bind   type lib name
==== service-supervisor ====
nth bind   type lib name

路径与服务名称已替换，地址列已省略；保留空的搜索结果。

组件调用关系摘要保留了已读到的代码路径与尚未确认的条件。仅凭离线分析，不能把这条线索写成已经复现的访问控制漏洞。

接下来汇总各任务的记录与证据索引，在报告中分别列出静态证据、可能影响和仍需设备验证的条件。

Shell 命令 echo, stat, head

$ R="analysis/session/security-report.md"
echo "exists: $([ -f "$R" ] && echo yes || echo no)"
echo "size: $(stat -f%z "$R" 2>/dev/null)"
echo "first lines:"
head -6 "$R"

exists: yes
size: 8848
first lines:
# 安全挖掘报告：离线固件样本

## 范围

- **目标**：`analysis/firmware`（component-a / component-b / component-c 与 header.json）。
- **授权**：设备自有/书面授权，全面离线逆向；无实体设备，无网络外联，无真实设备动态验证。授权与源材料已写入 run-manifest。

路径与名称已替换，输出节选；字节数为原报告的记录值。

归档完成。 7/7 项离线分析任务完成，18 条 Finding 已写入看板，其中严重 4 条、高危 7 条、中危 7 条。14 条记录已完成静态复核，另外 4 条仍待动态验证；本次未进行实物设备验证。

Finding 汇总（5 条代表记录）

ID	严重性	标题
F-01	critical	更新包真实性校验不完整
F-02	critical	发行构建使用可预测的信任材料
F-03	high	外部介质更新缺少充分约束
F-04	high	调试通道暴露系统级操作能力
F-05	medium	内部服务接口缺少明确访问控制

上表对应右侧看板中的代表记录。每条记录可以继续打开，查看影响说明、证据摘要和修复建议。

人工复核

更新链记录保留代码、配置与证书等静态证据，核对校验覆盖范围和信任边界。
系统服务与调试能力记录保留配置背景，后续需结合实际设备和发行环境复核可达性与影响。
F-05 为潜在线索，保留调用方身份与权限边界的待确认项，需动态验证后再判断。

最终报告与证据索引已归档，可从工作产物中查看。

Finding 1818/18展示 5 条代表记录

选择攻击面

固件更新与启动链2

F-01静态证据严重人工待复核

更新包真实性校验不完整

更新流程未形成完整的来源与完整性信任链，可能接受未经可信来源确认的更新内容。

3 附件

F-02静态证据严重人工待复核

发行构建使用可预测的信任材料

用于确认软件来源的信任材料缺少生产环境隔离，可能削弱更新链的可信边界。

2 附件

本地更新入口1

F-03静态证据高危人工待复核

外部介质更新缺少充分约束

发现读取外部介质并进入更新的代码分支；设备上的触发条件与签名策略仍需验证。

1 附件

维护与调试服务1

F-04静态证据高危人工待复核

调试通道暴露系统级操作能力

启动配置保留高权限调试服务，未见明确的发行隔离；实机可达性与权限范围仍需验证。

1 附件

组件通信边界1

F-05待验证中危人工待复核

内部服务接口缺少明确访问控制

组件间接口依赖环境信任，未观察到一致的调用方身份与权限约束。

1 附件

横向滑动查看完整工作区

为什么选择 Void？

自动化渗透测试: 蒸馏安全研究员的实战经验，将资产解析、协议状态推理、Payload 生成、漏洞验证与修复建议整合为可复用流程，减少重复摸索。
开箱即用: 输入已授权目标，Void 自动挖掘并验证高危漏洞。渗透测试无需再找第三方服务，从分析到验证全部自动化。
黑盒测试与白盒分析: 既能从外部测试目标，也能结合源码深入分析。配合 SIG Pi，一键连接设备测试环境。
漏洞管理与审计: 通过可视化看板，集中查看和管理各任务发现的漏洞、风险等级与人工复核状态。
官方与自定义模型: SIGVoid 精选的安全模型开箱即用，也支持自带 API Key（BYOK），接入兼容的自有模型服务。

阅读文档

Void 可以测试什么？

Void 是一个通用的渗透测试 Agent，覆盖车机、机器人、Web 与外拨语音等场景。预置领域知识库与专家工作流，开箱即可开展安全测试。

合规测试

结合 ISO/SAE 21434、UN R155、GB 44495 的适用要求和团队测试规范，组织检查、执行测试并整理记录。

软件测试与代码审计

分析应用代码、依赖与配置，梳理调用关系，检查权限校验、输入处理与业务逻辑。

接口与服务测试

分析接口与服务的攻击面，围绕身份认证、访问控制和数据交互开展渗透测试。

固件与设备安全

分析固件、升级机制与通信接口，覆盖机器人、汽车、IoT 等设备场景。

数据安全测试

跟踪数据的采集、传输、存储与访问，检查敏感信息暴露、越权读取与保护措施。

语音应用测试

围绕语音输入、处理流程与指令执行，检查异常输入、权限边界和数据流转中的安全问题。

HOW VOID WORKS

Void 如何开展渗透测试？

描述测试目标，让 Agent 自动展开分析。你可以随时查看环境连接状态，导出 Finding 及漏洞报告。

攻击面扫描扫描中 68%

授权测试环境

Repository

API Gateway

Runtime

扫描队列

路由与入口

权限边界

依赖与服务

已发现 24 个入口surface_001

接入目标，描述任务

提供代码、接口或测试环境，说明授权范围与测试目标。Void 检查环境连接，识别入口与信任边界。

漏洞验证任务验证通过

surface_001 / repo-cloneRUN · M-001

10:31请求已捕获

10:32响应已确认

10:33漏洞已复现

证据包证据已留存

request.http response.json poc / run.sh

Agent 自主开展分析与验证

自主调用工具分析攻击面、建立系统模型、探索并发现漏洞，并根据返回结果调整下一步测试。支持多个 Agent 分头研究不同任务。

Finding 列表人工复核

编号风险审计状态

F-01严重待复核

F-02中危待复核

F-03中危已复核

F-01 已选中3 份复现证据进入审计

查看结果，继续深入

在工作台集中查看漏洞、风险等级与复核状态，跟进任务，调整判断，并对值得深入的问题继续验证。

SIGVoid 为安全研究精选大模型

我们围绕安全研究场景，筛选可靠、擅长安全任务的模型。目前 Void-5.3-Flash-Cyber 已上线，下载并安装 Void 后，即可一键连接使用。Void 也支持自带 API Key（BYOK）和自定义服务地址，接入你选择的模型。

GLMQwenDeepSeekKimi

了解 SIGVoid Cyber

START WITH A TARGET

从一个授权目标开始。

当前环境暂未开放下载。

GitHub