N0xis

从活动进程中的硬件观察点，到改变该值的精确反编译语句。

内存扫描器找到的是地址。反编译器解释的是代码。N0xis 将两者连接起来。

$ n0x provenance trace --pid 9348 --addr 0x7ff68bef3010 --kind write

"function_va": "0x7ff68bef1580",          // containing function, auto-resolved
"decompiled_context": [
  "rax.2 = (*(uint32_t*)(0x7ff68bef3010) - 0x1);",
  "*(uint32_t*)(0x7ff68bef3010) = rax.2;"  // ← the statement that moved your value
]

这就是源码中的 hp -= 1;，从一个正在运行的进程中恢复出来——被观察的地址 出现在该语句中。已在 Windows 和 Linux 上验证。

“查找谁访问了这里”的扫描通常止步于一行原始反汇编，而反编译器通常 根本没有实时观察点输入。这里把两半拼在了一起：观察点命中通过 反编译该文件的同一条 SSA 流水线解析出来。

安装

适用于 Linux 和 Windows 的预编译二进制文件——最新发布。

curl -LO https://github.com/Structio-labs/N0xis/releases/latest/download/n0xis-linux-x86_64
chmod +x n0xis-linux-x86_64 && ./n0xis-linux-x86_64 --version

或者自行构建：cargo build --workspace --release（Windows 和 Linux；无需 MSVC Build Tools ——rust-toolchain.toml 固定了 gnu host）。

快速开始

每条命令都打印一个 JSON 对象——参数错误也不例外：{"ok":true,"data":…,"meta":…} 或 {"ok":false,"error":…}。加上 --pretty 以便阅读；失败时退出码非零。

n0x doctor                                                    # environment check
n0x profile --file game.exe                                   # triage: sections, exports, engine hints
n0x function discover --file game.exe --pdata                 # exact .pdata discovery
n0x decomp pseudo --file game.exe --addr 0x140012a00 --style ssa --pretty
n0x provenance trace --pid 4821 --addr 0x1a2b3c40 --kind write --pretty

同样的命令可以作用于活动 --pid、静态 --file、捕获的 --snapshot，或通过 SSH 连接的 远程进程。这就是普通的 Unix 管道—— n0x function discover --file game.exe --pdata | jq -r '.data.functions[].va' 会喂给下一条 命令。n0x guide 列出全部 113 条命令，由二进制文件生成，因此永不漂移——并且有一个测试 会在此数字不一致时让构建失败。

从 agent 使用： 将任意 MCP 客户端指向 n0xis-mcp——25 个工具返回完全相同的 {ok,data,meta} 信封，基于 stdio 的 JSON-RPC。

{ "mcpServers": { "n0xis": { "command": "/path/to/n0xis-mcp" } } }

它能做什么

• 反编译——一个优化型 SSA 反编译器（Memory-SSA、phi-web 变量合并、 完整的 SSA 销毁、精确的分支条件），其优化器会报告它所做的每一次重写 （--explain：哪个子 pass 在哪个地址改了什么），而不是黑盒答案。
• 扫描活动内存——值/指针/AOB 扫描，配合基于快照的收窄、冻结、 code-cave 钩子。完整的扫描 → 收窄 → 冻结 → 修补循环。
• 观察并解释——软件/硬件/条件断点，以及真正的跨进程 展开调用栈；这是 provenance 所依赖的原材料。
• 恢复名称——在两种 ABI 上从 RTTI 恢复 C++ 类（MSVC 的 .rdata 链和 Itanium 的 _ZTV 符号）、.NET NativeAOT 的 RVA ↔ Namespace.Type.Method、LuaJIT、Bitsquid、IL2CPP—— 这样被剥离符号的映像读起来就像源码，而不是 sub_XXXX。
• 持久化与差异比较——.n0xt 表、带版本的注解、内容寻址缓存、 函数/版本差异比较。

Windows 和 Linux，PE 和 ELF，同一条流水线——静态文件、活动进程、快照 和远程目标都流经相同的 pass 和相同的带版本 JSON。

核心中永远没有 ML 的不确定性。桌面 GUI 位于单独的仓库： n0xis-gui。

状态

Alpha。 以下每一项声明都是针对工具之外的来源进行的测量——内核、 映像自身的表，或目标进程本身。在没有此类来源的地方，会明确说明， 因为已实现和已验证不是同一种声明。

活动内存，针对一个植入已知值的一次性目标：

• Linux——31 条命令中有 29 条针对 /proc/<pid>/mem 进行了测量，一条错误并已修复。 另外 两条是 Windows 专属的，并会明确说明这一点而拒绝执行。那一条错误的是 scan dissect，它 在字段的对齐之前就选定了字段宽度，因此从它的第一个错误开始，读取结构体时就偏移了四个字节： 针对从其自身源码已知的布局，六个字段中只有一个正确，修复后六个中五个正确。
• Windows 11——23 项检查中测量了 21 项，0 项错误，以目标本身作为判定基准。 ui focus 在控制台目标上正确地找不到窗口；stack backtrace 是 Linux 专属的——这是 Linux 适配器领先的唯一一处。

解码器，针对一个独立的反汇编器——这是其他一切所立足的基础， 而在此之前仅由构建于其上的 pass 检查过，而这些 pass 读取的都是同一条流：

• x86：指令边界与 objdump 比较。三种专门构造的形状完全精确， 一个共享库的 20 000 条指令和一个 32 位系统 DLL 的 20 000 条指令，零 分歧，且双方各自单独发现的边界也为零。扩大到一个 334 MB 剥离符号的浏览器二进制的 60 000 条 指令：2 处分歧，均位于嵌入 .text 的 ASCII 字符串内部，在那里参考实现自身也解码为 (bad)——那不是代码，且两种读法都不正确。
• AArch64：助记符与 llvm-objdump 比较（定宽编码使边界问题变得无意义）。见下方 ARM64 一行。
• AArch64，是编码空间而非编译器输出：600 个确定性字由 llvm-mc --mattr=+all 和 n0xis 判定。241 个双方都判定为指令，304 个双方都拒绝—— 而 48 个（8.0%）是保留编码，n0xis 却将其读作指令，另有 7 个（1.2%）是真实 指令却被它拒绝（主要是 LSE 原子操作）。那 48 个中有三个经手工解码，确实是 UNALLOCATED。这一差距由一个在它扩大时就会失败的界限所约束，并在此处 说明而非略去：一个被读作指令的保留字会把数据变成一段看似合理的程序。

函数范围，针对映像自身的展开表和链接器的导出列表：

• 来自 objdump --dwarf=frames 的每个 FDE 的 start..end 都等于恢复出的范围—— 在本机上比较了 3 787 个（10 + libc 的 3 777），起点和终点，精确；另外 在两个大型库上分别测得 15 467 和 14 355。
• 函数列表未遗漏任何导出入口点：在判定基准形状上 10 个中 10 个， 在 libc 的扫描窗口内 2 323 个中 2 323 个。

交叉引用和调用图，针对一个并非本工具的来源的反汇编：

• 在一个系统 C 库的六个最繁忙目标上共 4 733 个引用——无一遗漏，无一虚构，双向皆然。 call、尾调用 jmp 和 RIP 相对数据引用各自按 kind 标注， 且每一项都与 objdump 所显示的内容进行了比较。
• 跨 100 个函数的 304 个调用点——无一遗漏，无一虚构，每个 函数的范围取自展开表而非符号边界，且尾调用（包括条件尾调用）被计为 它本来的调用。
• 跨 100 个函数的 464 个分支目标，每一个都是基本块的开头。 拆分器遗漏的目标会让两个块融合，于是程序中存在的边 在图中不存在——而它之上的任何东西都无法察觉。

恢复的结构体字段，针对布局该结构体的编译器：

• gcc -g 声明了每个成员的偏移；跨 10 个函数恢复了 15 个字段偏移， 每一个都是真实成员——无一虚构。 有意为之的单向性：优化器会折叠 并丢弃字段访问，因此从未出现的成员是编译器所为，而非遗漏。

静态分析，针对映像所声明的范围和表：

• x64 ELF 和 PE：函数范围精确，在 92 001 条边上 0 次 CFG 不变量违规。
• ARM64——解码器和 CFG 已验证，反编译器未验证。 2 381 个函数范围中有 2 381 个完全 等于符号表，在 46 757 条 CFG 边上 0 次违规。解码器现在针对LLVM 自身的 AArch64 反汇编器 在为此目的构建的编译器输出上进行了检查（oracle/arm64.c 以 -O2 编译）：147 条指令，147 个共享地址，0 次解码失败， 且全部 28 处名称差异都是已记录的架构别名（mov/orr、 cmp/subs、b.hs/b.cs……），每一处都在测试中列出，而非笼统地宽恕。AArch64 的 lift/SSA 仍未构建，因此 decomp pseudo 报告 quality: 0.0 并回退 到 asm 节点。优化型反编译器仅支持 x64。
• 32 位 PE：发现 422 个导出入口点中的 422 个，在 34 149 条边上 0 次违规。 在一个完全没有异常表的 32 位映像上，针对一个独立解析器从中读出的 3 889 个 .eh_frame FDE 进行了检查：0 遗漏，每个范围都精确，0 个条目位于已知函数内部。 该规则是针对 x64 异常表编写的，却在一个没有异常表的 架构上成立。

恢复的签名，针对在此处编译、其答案在提问之前就已知的目标（oracle/）：

• 在两种 x86-64 ABI 上均为 12 个中 12 个——参数数量、每个参数 到达哪个寄存器文件，以及返回类别，包括混合整数/浮点签名的两种顺序 （System V 和 Win64 按不同规则计算它们的两个参数寄存器文件）。
• 32 位 cdecl 在返回时不声明参数个数，也不通过寄存器传递任何东西，因此 参数列表读作 ()——C 语言中表示未指定——而非 (void)，后者会是一个 声称没有参数的断言。此 lift 未建模的 x87 返回读作 /*unknown*/，而非 void。 两处缺口都连同其原因记录在 oracle/expect.json 中，且测试会在其中一处 悄然闭合时失败，因此已记录的限制不会腐烂成民间传说。

恢复的 C++ 类，针对映像自身的类型描述符字符串：

• 在一个 32 位 C++ 运行时上有 93 个 vtable（此前为 0），在两个 64 位运行时上分别为 97 和 152，在一个 通过 Itanium 路径的 ELF 上有 269 个——且每个恢复出的名称都存在于映像自身的 字符串中，因此无一虚构。两种 MSVC 方言都有植入的回归夹具 （oracle/rtti32.c、oracle/rtti64.S），因为此处没有编译器会生成 MSVC RTTI。

未验证，且未声称： il2cpp import / symbols 需要外部 dumper 的索引； il2cpp obj / classes 需要一个活动的托管进程。带版本的 JSON 契约尚未经过 外部用户的实际检验——预计其形状会变动。

文档

• docs/CLI_COMMANDS.md——每条命令（清单由二进制文件生成）、 其输出的 schema id，以及每项声明背后的注意事项。参数位于 n0x guide 和 --help 中，它们也是生成的。
• oracle/README.md——答案在提问之前就已知的目标语料库、 来源的排名方式，以及如何添加一个形状。
• docs/VERIFICATION.md——验证台账：每项检查及其 来源层级和用例数量，以及哪些已证明、开放或未声称——全部集中在一处。
• CONCEPT.md——架构：适配器、pass、接缝。
• ROADMAP.md——构建历史和仍缺失的分析能力。
• MAP.md——15 个 crate 的工作区布局。
• docs/COMMUNITY_ROADMAP.md · docs/PRODUCT_POLICY.md · CONTRIBUTING.md

许可证

N0xis 是源码可用软件，以 Structio 名义开发。

• 非商业用途免费——个人项目、研究、教育、CTF、业余逆向 工程，以及非商业组织使用，依据 PolyForm Noncommercial License 1.0.0。
• 商业用途需要付费许可证——见 COMMERCIAL.md。

截至并包括 0.2.1 的版本曾依据 AGPL-3.0 发布，并仍可按 那些条款获取。本许可证适用于 0.3.0 及更高版本。

不确定你的用例是否属于商业用途？开一个 issue 或发邮件至 [email protected]—— 我宁愿回答问题，也不愿追究违规。