tony102741/firmware_project

GitHub: tony102741/firmware_project

面向编排密集型嵌入式固件的辅助逆向分析工具,通过六层编排模型重构固件管理平面的信任边界与变更路径。

Stars: 1 | Forks: 0

# 固件编排分析 ### 用于逆向工程编排密集型嵌入式固件的辅助分析师工具 ![状态](https://img.shields.io/badge/status-active%20research-0a7ea4) ![重点](https://img.shields.io/badge/focus-embedded%20firmware%20orchestration-2f6f3e) ![方法](https://img.shields.io/badge/method-analyst--assisted%20RE-6b4fa1) ![发布](https://img.shields.io/badge/release-src--focused-444) 本仓库包含用于逆向工程编排密集型嵌入式固件辅助分析师工作流的源代码,旨在重构嵌入式固件管理平面中的编排结构。 本项目的重点不在于漏洞利用生成,而在于还原真实的固件中请求、helper 脚本、原生组件、staging 边界、编排扇出以及下游变更路径是如何相互配合的。 ## 为什么会有这个项目 许多固件分析工作流往往在遇到明显的 sink(如 `system()`、`uci commit` 或 shell 命令字符串)时就停止了。 对于编排密集型系统而言,这通常过于浅显。 在实际应用中,管理操作在持久化或激活之前,可能会跨越多个边界: - 入口处理程序 - helper 脚本 - 原生 staging 逻辑 - ubus 或 RPC 扇出 - 下游变更与保存路径 本项目的存在是为了帮助分析师以可复现的方式还原这种更大的架构。 ## 本项目的重点 | 领域 | 重点 | |---|---| | 分析风格 | 架构优先的逆向工程 | | 主要视角 | 信任边界重构 | | 跨目标逻辑 | 语义递归,而非单纯的克隆匹配 | | 工具设计 | 保守、标记证据、辅助分析师 | | 主要用例 | 编排密集型嵌入式固件 | ## 核心理念 - **六层编排模型** 入口、helper 中介、staging、放大、下游规范化和持久化被视为不同的分析角色。 - **校验位移** 尽管信任在早期就已经分发,但更强的校验往往出现在 sink 附近的后段。 - **函数级证据** 只要有可能,我们更倾向于使用结构化的函数级笔记,而不是模糊的叙述性总结。 - **语义递归** 相似性是通过架构角色和信任边界行为来评判的,而不仅仅是通过共享的字符串或克隆的代码。 ## 当前工具 当前公开的代码库以编排图辅助和结构化逆向分析支持为核心。 关键模块: - `src/research_tools/orchestration_graph_mvp.py` - `src/research_tools/orchestration_note_drafter.py` - `src/research_tools/orch_graph_normalization.py` 当前功能: - 从固件二进制文件中提取与编排相关的信号 - 分析师笔记的导入与完善 - 支持 markdown 到笔记的草稿生成 - 支持 helper、staging、重放、投影以及感知 sink 的规范化 - 生成保守的图,并保留证据与警告 - 用于图类型行为的轻量级回归测试 ## 仓库结构 这个公开仓库是有意以源码为核心的。 ``` src/ research_tools/ Orchestration graph tooling and research helpers core/ Supporting analysis components batch/ Batch execution helpers corpus_tools/ Corpus and input organization utilities review/ Review and triage support code tests/ Lightweight regression tests ``` 大型的本地语料库、Ghidra 工作区、解包的固件目标以及私有研究产物对于理解发布的源码树来说不是必需的,因此可能不会包含在公开上传的内容中。 ## 公开范围 面向公众的仓库旨在优先提供可复用的源代码,而不是私有或庞大的研究状态文件。 这通常意味着: - 将 `src/` 作为主要的发布面 - 在能够阐明预期行为时保留轻量级的测试 - 排除本地固件语料库、解包的根文件系统、Ghidra 工作区以及研究档案 如果公开上传的代码中缺少某个目录,通常应将其视为发布范围的决定,而不是缺少方法论上下文。 ## 研究背景 本项目的动力来源于对编排密集型固件生态系统的研究案例,包括对以下内容的研究: - TP-Link OneMesh 组件,如 `meshd`、`sync-server` 和 `client_mgmt` - GL.iNet GL-X3000 组件,如 `modem.so` 和 `gl_modem` 这些研究为工具设计提供了参考,但本仓库应主要被视作一个方法论和工具的发布,而不是所有底层研究资产的公开堆砌。 ## 本仓库不包含的内容 这**不是**: - 一个漏洞利用仓库 - 一个批量 CVE 收割工具 - 一个声称能自动发现漏洞的基准测试 - 一个取代分析师判断的最终图生成器 它**不**声称: - 具有普遍的可利用性 - 仅凭静态证据就能完全重构 runtime - 在所有固件家族中实现精确的架构等价 - 能够在无需审查的情况下自动做出递归决策 ## 方法论哲学 这里最安全的默认做法是保守解释。 这意味着: - 保留原始证据 - 将已确认的发现与推断分开 - 允许提出警告,而不是强行得出结论 - 避免将弱信号提升为强大的架构声明 目标不是完全自动化逆向工程。目标是使具备编排意识的逆向工程更加结构化、更具可复现性,并且不再短视于 sink。 ## 未来方向 计划的方向包括: - 更好的函数级笔记导出工作流 - 对 staging 密集型和 sink 密集型组件类提供更强的支持 - 改进的跨家族递归比较 - 为未来的研究发表提供更清晰的公开评估产物 ## 致首次访问者 如果您是从公开代码发布开始了解本项目的: 1. 查看 `src/research_tools/orchestration_graph_mvp.py` 2. 阅读其旁边的笔记草拟和规范化模块 3. 运行 `src/tests/research_tools/` 下的回归测试 4. 将这些工具视为对分析师的支持,而不是一个一键获取答案的引擎
标签:云安全监控, 云资产清单, 嵌入式固件, 情报收集, 漏洞研究, 逆向工具, 逆向工程, 静态分析