hexvero

---

A fast, local, evidence-backed first look at software, for developers and AI agents.

hexvero reads executables, Electron apps, APKs, archives, databases and network captures without running them. It tells you what the software contains, what it exposes, where each fact was read, how sure it is, and what it could not establish. One CLI, one MCP server for coding agents, one local web UI. Nothing leaves your machine.

Try it

npx hexvero analyze ./MyApp.app/Contents/Resources/app.asar

Node.js 22.12 or newer is all it needs. From an empty npm cache the first result took one command and about nine seconds on a laptop, download included. A real run on the small Electron app in examples/:

$ hexvero analyze examples/notesdesk-1.4.0.asar
Summary
  Electron ASAR: 4 JavaScript modules, 6 IPC channels

Findings
  ○ nodeIntegration: true in a BrowserWindow  @ main.js:14
      contextIsolation is on for the same window, so page scripts do not get require(). Node integration keeps the renderer out of the Chromium sandbox.
  ○ sandbox: false in a BrowserWindow  @ main.js:15
      The renderer process runs without the Chromium sandbox.
  ● 6 IPC channels  @ main.js:25
      app:quit, notes:list, notes:save, settings:get, settings:set, shell:open (collections ipcChannels, ipc)
  ● 6 members exposed to pages as window.notesdesk  @ preload.js:4
      getSetting, setSetting, listNotes, saveNote, quit, openInShell (collection contextBridge)
  ○ 2 network endpoints read from the code  @ renderer/app.bundle.js:11
      ${…}/notes/sync, https://telemetry.notesdesk.example/collect (collection endpoints)
  ● 1 storage key read from the code  @ renderer/app.bundle.js:10
      notesdesk.token (collection storage)
  … (preload script, list of collections)

Next
  Which IPC channels can a page reach, and who handles them?
    hexvero collection examples/notesdesk-1.4.0.asar ipcChannels
  What does the preload script expose to web content?
    hexvero collection examples/notesdesk-1.4.0.asar contextBridge
  … (two more)

A filled dot is a fact read from the file, a hollow dot an inference from a pattern; @ main.js:14 is where it was read. Settings are reported as written, never as assumed Electron defaults. ${…} marks the part of an address that is computed at run time. The windows collection puts each window's nodeIntegration, contextIsolation and sandbox side by side as true, false, computed or not written and says what follows from them together; a value that rests on Electron's default for the version in package.json is marked default on / default off. The rules and their sources are in docs/electron-findings.md. The IPC finding is a filled dot only when every IPC-shaped call could be traced; otherwise the limitations name the calls that could not, with file and line.

What people use it for

1. Understand an unfamiliar application. You downloaded a binary, an Electron app or an APK. hexvero says what it is, what it exposes and where the evidence is, and suggests what to look at next. On a native program it names the hardening and the imports worth a look:

$ cc -O2 -o demo examples/native/demo-v2.c && hexvero analyze demo
Findings
  ● Imports functions that start other programs or a shell: system
      Read from the import table. Whether and with what input they are called is not established by static reading; a call graph (hexvero calls) shows who calls them. (collection imports)
  ● Hardening: PIE yes, stack canary no, ARC no, code signature yes, stripped yes

$ hexvero calls demo radare2 main --goal system      # with radare2, rizin or Ghidra installed
radare2 path main → sym.imp.system · found
main
  └ sym._run_tool
    └ sym.imp.system

2. Compare two versions. What changed between two builds, list by list, with the item as evidence. Code that only moved is not reported as changed.

$ hexvero compare examples/notesdesk-1.4.0.asar examples/notesdesk-1.5.0.asar webPreferences
webPreferences: 0 added, 0 removed, 2 changed, 2 unchanged · matched by file+windowName+key
  ~ main.js::win::nodeIntegration  value: true → false
  ~ main.js::win::sandbox  value: false → true

$ hexvero compare examples/notesdesk-1.4.0.asar examples/notesdesk-1.5.0.asar windows
windows: 0 added, 0 removed, 1 changed, 0 unchanged · matched by file+windowName
  ~ main.js::win  nodeIntegration: true → false, nodeIntegrationInEffect: "on" → "off", sandbox: false → true, sandboxInEffect: "off" → "on"

$ hexvero compare examples/notesdesk-1.4.0.asar examples/notesdesk-1.5.0.asar contextBridge
contextBridge: 1 added, 1 removed, 0 changed, 5 unchanged · matched by api+member
  + notesdesk::checkUpdate
  - notesdesk::openInShell

Nothing is ignored by default; code that only moved in a native binary is counted as relocated. Windows are matched by the variable they are assigned to (win), so adding a window does not mis-pair the others. An item found on one side only is added or removed only if the other side read the file it sits in; otherwise it is unknown (?).