Skip to content
KitploitKITPLOIT
StrumentiExploitsBlog
Log in
Invia
StrumentiExploitsBlog
Invia

Strumenti di Hacking, PenTest e Cybersecurity per il tuo Arsenale di Sicurezza!

Kitploit è una directory di strumenti di hacking, cybersecurity e pentesting. Scopri gli ultimi aggiornamenti dei progetti per trovare vulnerabilità, analizzare sistemi, automatizzare i test e rafforzare la tua sicurezza.

FeedContattoPrivacy© 2026 Kitploit

Directory degli strumenti

Categorie

Vedi tutte le categorie
Loading categories
hexvero — 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. | Kitploit
Strumenti/GitHubGitHub/maximilianfeix/hexvero
Sicurezza AndroidAnalisi StaticaAnalisi delle VulnerabilitàAnalisi del CodicePentesting di App MobiliReverse EngineeringRaccolta InformazioniAnalisi MalwareDigital ForensicsUtilità e FrameworkAnalisi di Binari
3561 giorno faNon ancora revisionato

Più Popolari

Vedi tutti →

Scopri gli strumenti più utilizzati dalla nostra community.

Esplora tutti gli strumenti

Sfoglia la nostra collezione di strumenti

Vedi tutti gli strumenti →
Condividi
Sicurezza dell'IA
GitHubmaximilianfeix/hexvero

hexvero

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.

Vedi RepositorySito web
hexvero – il primo sguardo a un binario o a un bundle di app. Fatti statici con evidenze, dal solo Node.

CI npm Node License

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.

hexvero analizza un'app Electron nel terminale: risultati con file e riga, i punti di chiamata IPC di un canale e le impostazioni cambiate tra due build

Provalo

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.

A cosa serve

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 (?).

Scarica lo strumento