Hexana：JetBrains 官方下场做的 WebAssembly 二进制分析工具包

WebAssembly 这些年在语言层面（Component Model、GC、Threads）演进很快，但配套的”看清模块内部”的工具链一直相对滞后。做 WASM 插件系统、边缘运行时的团队，常常只能手撸十六进制。Hexana 是 JetBrains 官方推出的 WASM 与二进制分析工具包，恰好补上这块空白。本文基于其官方文档站，分析它到底覆盖了哪些能力、双端有何差异，以及官方对成熟度的自我定位。

一、背景：WASM 工具链的缺口

当 WASM 从”浏览器里跑一点 C++“走向组件模型（Component Model）、插件系统与边缘运行时，开发者的痛点从”能不能跑”变成了”这个 wasm 里到底打包了什么、为什么这么大、改了一版之后哪里变了”。普通的反汇编器要么不懂 WASM 的分节结构，要么不认识 Component Model。Koala 的点评一针见血：WASM 工具链长期落后于语言本身，Hexana 的价值就是帮做 WASM 插件系统和边缘运行时的团队省下逆向排错时间。

二、它是什么：两套外壳，一个内核

Hexana 同时发布两个产品形态，共用同一套 Kotlin Multiplatform 分析内核：

• IntelliJ 平台插件（当前 0.15）：完整的多标签 .wasm 编辑器，带可虚拟化编辑的 WAT 视图、WAT/WIT 语言支持、MCP Server、Java 侧补全（GraalWasm/Chicory）、JS/TS 的 WebAssembly.instantiate 类型推断、可切换反汇编后端（AOT 字节码或 Cranelift 原生）、.class/.jar/.war/.apk/.jit 查看器。支持 IntelliJ IDEA 2025.2+、RustRover、WebStorm、CLion、PyCharm、Rider、PhpStorm。
• VS Code 扩展（当前 0.8.0）：用 Compose-for-Web 做自定义编辑器，虚拟滚动 hex 视图、12 个结构化分析标签、按需启动的 MCP Server。支持 VS Code 1.102+、Cursor、VSCodium、Code OSS 等 Open VSX 系编辑器。

两者都能对接 Wasmtime / WAMR / GraalVM / wazero 运行时做运行与调试，并自动检测需要的 proposal flag。

三、技术机制：从魔数识别到分节剖析

共享内核的解析能力覆盖相当全。官方称其 WASM 解析器支持：Core Wasm、Component Model、GC、SIMD、Threads、Tail Call、Reference Types、Bulk Memory、Multi-Value 以及 Legacy Exception Handling。在分析层提供 imports/exports 目录、函数与类型目录、体积 profiling、死代码检测、monomorphisation（单态化）分析、自定义节检查（IntelliJ 版含 DWARF）。

上图的 diff 功能是它在工程上最实用的一环：两个 wasm 之间做分节级 diff，给出每一节、每一个函数的字节级增减，并支持选中函数后对比其 WAT。对做 wasm 体积优化、发布回归的人，这比肉眼对二进制高效得多。此外还有 Top size treemap（体积热力图）、Component Model 依赖图、选中字节的数据检查器等。

值得注意的是它的”原生二进制”路线：从魔数字节识别 ELF / Mach-O / PE，用与 WASM 相同的 hex + 结构布局来展示——也就是说同一个查看器能打开 .wasm、.elf、.exe、.jar。

四、双端如何选（官方对照表）

官方明确建议：“两个可以都装，互不冲突。”

五、官方承认的局限与口径偏差

必须把官方自己的定性单独拎出来，因为它直接关系到能否用于生产：

1. 整体仍是实验性 MVP：GitHub Issue tracker 页面白纸黑字写着——“Hexana is currently an experimental MVP developed with limited resources. Some features may be incomplete, change rapidly, or prioritize architectural exploration over polish.”（实验性 MVP、资源有限、功能可能不完整且快速变动）。这不是客套，而是 JetBrains 对它当前阶段的正式标注。
2. 调试器是实验性的：对照表把”调试器断点”标注为 experimental，不要期待成熟 IDE 调试体验。
3. 原生二进制支持是 experimental：ELF/Mach-O/PE 只是”从魔数识别 + 同款布局”，不是成熟的原生反汇编工具。
4. 双端版本号差距大：IntelliJ 版 0.15、VS Code 版 0.8.0，说明两端功能并未完全对齐，VS Code 侧仍在追赶。
5. 文档站专门暴露了 llms.txt 供 LLM 消费——这是个有趣的工程细节，但也侧面说明它的文档仍在结构化建设中。

六、适用 / 不适用场景

适合：

• 做 WASM 插件系统、Component Model 运行时、边缘 WASM 的团队；
• 需要排查”为什么这次构建出来的 wasm 变大了”（体积 profiling + diff）；
• 想在已有 JetBrains 或 VS Code 工作流里就地看 wasm，而不是开 Ghidra 这类重型工具；
• 需要 MCP 能力让 AI 助手直接查询 wasm 结构。

不适合：

• 期待成熟、稳定、文档完备的商业级逆向产品；
• 重度依赖原生 x86/ARM 反汇编与调试的场景（那应该用 Ghidra/IDA）；
• 对实验性功能稳定性有刚性要求的生产环境排障。

七、客观分析：优势与局限

优势：

1. 官方背书 + 双端覆盖：JetBrains 亲自下场，IntelliJ 与 VS Code 用户都能用，且一套内核保证一致性；
2. 聚焦 WASM 生态痛点：Component Model 依赖图、WAT/WIT 编辑、wasm diff、体积 treemap 都是这个细分领域稀缺的能力；
3. MCP 就绪：天然契合”AI 助手分析二进制”的新工作流；
4. 从 wasm 到 elf/pe 的统一查看体验，降低了切换工具的成本。

局限：

1. 成熟度早期：MVP + limited resources，功能可能随时变动；
2. 双端不对齐：VS Code 版版本号低，缺 Java 侧补全、Cranelift 后端、jar 查看器等；
3. 调试与原生反汇编都还实验性；
4. 对不做 WASM 的普通开发者，这是个高度垂直的专用工具，日常用不上。

八、它意味着什么

Hexana 的出现，说明 WASM 生态正在从”能跑就行”进入”可观测、可优化、可排错”的工程化阶段。JetBrains 把它做成双端插件、还内置 MCP，等于押注两件事：一是 WASM 会在插件系统与边缘运行时里持续增长，二是未来分析二进制这件事会越来越多地由 AI 助手借助工具完成。对目标用户（WASM 平台与运行时团队），它现在就能省不少逆向时间；但考虑到官方自认的 MVP 定位，建议把它当作”快速排错的辅助”而非”生产依赖的工具链”，并持续跟进 0.x 版本的演进。

参考来源

• Hexana 官方文档站
• Hexana GitHub 仓库
• Koala 项目库条目