
La prima occhiata a un binario o a un app bundle: analisi statica, senza esecuzione, con evidenze. CLI, server MCP con 15 strumenti e interfaccia web locale, solo Node.
English · Deutsch · Español · Français · Português (Brasil) · Русский · 中文 · 日本語 · 한국어
Provalo · Casi d'uso · Installazione · Cosa legge · CLI · Web UI · Per agenti AI · Motori · Limiti · Confronto con REA · Come funziona · Contribuire · FAQ
Un primo sguardo rapido, locale e supportato da evidenze al software, per sviluppatori e agenti AI.
hexvero legge eseguibili, app Electron, APK, archivi, database e catture di rete senza eseguirli. Ti dice cosa contiene il software, cosa espone, dove è stato letto ogni fatto, quanto è sicuro e cosa non è riuscito a stabilire. Una CLI, un server MCP per agenti di coding, una web UI locale. Nulla lascia la tua macchina.

npx hexvero analyze ./MyApp.app/Contents/Resources/app.asar
Node.js 22.12 o versione successiva è tutto ciò che serve. Da una cache npm vuota il primo risultato ha richiesto un solo comando e circa nove secondi su un laptop, download incluso. Un'esecuzione reale sulla piccola app Electron 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)
Un punto pieno è un fatto letto dal file, un punto vuoto un'inferenza da un pattern; @ main.js:14 è dove è stato letto. Le impostazioni sono riportate come scritte, mai come presunti default di Electron. ${…} contrassegna la parte di un indirizzo che viene calcolata a run time. La collezione windows mette nodeIntegration, contextIsolation e sandbox di ciascuna finestra fianco a fianco come true, false, computed o not written e dice cosa ne consegue insieme; un valore che si basa sul default di Electron per la versione in package.json è contrassegnato default on / default off. Le regole e le loro fonti sono in docs/electron-findings.md. Il risultato IPC è un punto pieno solo quando ogni chiamata in forma IPC ha potuto essere tracciata; altrimenti le limitazioni nominano le chiamate che non hanno potuto esserlo, con file e riga.
1. Comprendere un'applicazione sconosciuta. Hai scaricato un binario, un'app Electron o un APK. hexvero dice cos'è, cosa espone e dove si trova l'evidenza, e suggerisce cosa guardare dopo. Su un programma nativo nomina l'hardening e le import degne di uno sguardo:
$ 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. Confronta due versioni. Cosa è cambiato tra due build, lista per lista, con l'elemento come prova. Il codice che è solo stato spostato non viene segnalato come modificato.
$ 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
Nulla viene ignorato per impostazione predefinita; il codice che si è semplicemente spostato in un binario nativo viene conteggiato come relocated. Le finestre vengono abbinate in base alla variabile a cui sono assegnate (win), quindi l'aggiunta di una finestra non accoppia erroneamente le altre. Un elemento trovato solo su un lato è added o removed solo se l'altro lato ha letto il file in cui si trova; altrimenti è unknown (?).