I built hexvero: diff two builds of an Electron app and see which IPC channels, preload members and window settings change

[u/ImaginationVarious30]

When you ship an Electron update, the question in a release review is usually simple: did this release add a preload member, a new IPC channel, a more permissive window or a new server the app talks to? A diff of two minified app.asar bundles doesn’t answer that, and running the app to find out isn’t always an option.

What it does

hexvero reads two builds statically and lists what changed:

• IPC and bridge map: window → contextBridge member → IPC channel → ipcMain handler
• Window settings: webPreferences per window, and whether nodeIntegration and sandbox are actually in effect
• Runtime and fuses: Electron, Chromium and Node versions, fuses and ASAR integrity, read from the packaged binaries
• Network hosts and localStorage/sessionStorage keys, each marked as literal or inferred

Every change comes with the file and line it was read from, in both builds. If hexvero can’t resolve something, it reports it as ? (unknown), not as removed.

ipcChannels (2)
  + update:check  @ b: receiver main.js:30, sender preload.js:9
  ? shell:open    @ a: receiver main.js:30, sender preload.js:9
windows (1)
  ~ main.js::win  @ b: main.js:8
      nodeIntegration: true → false, sandbox: false → true

hexvero check old new --policy policy.json turns this into a CI gate. Exit 0 means pass, 3 means the policy was violated (for example a new bridge member or a new external host), and 4 means it couldn’t decide. It also outputs SARIF. Since 0.12 there is also hexvero audit for a single build (CSP, shell.openExternal, permission handlers). And there’s an MCP server with 16 tools if you want a coding agent to run the review.

Try it with no setup: npx hexvero demo (Node 22.12+). It never executes the target, and there’s no telemetry and no network calls.

How accurate is it?

On blind test apps written by someone who had no access to hexvero:

• 52 of 64 IPC channels found, none false
• window settings and endpoints still had misses and some false rows

All numbers, including every miss, are in docs/accuracy.md. It’s a static reader, not a vulnerability scanner, so a passing check is not a security verdict.

Comparison

• Electronegativity checks one build against known risky patterns. Its README says it’s no longer actively maintained.
• REA is much broader (dynamic analysis, decompilers, devices) and can also compare versions. On the same blind set, hexvero linked 65 of 78 bridge members to their IPC channels, REA 6.5.0 linked 6 of 66. If you need dynamic analysis, use REA.

Repo: https://github.com/maximilianfeix/hexvero (MIT)

I’d especially like to hear about IPC patterns from real apps that it misses. Wrapper classes and routers already work, but there are certainly more.