Files
reverse-engineering-anything/docs/readme/README_it.md
T
Matt Van HornandMatt Van Horn 645735fc0f feat(windows): inspect Shell Link (.lnk) shortcut files (#7859)
* feat(windows): inspect Shell Link (.lnk) shortcut files

Add inspect_windows_shortcut / inspect-windows-shortcut to read one
local Shell Link without resolving or executing the target. The report
keeps header flags and FILETIMEs, IDList items, LinkInfo volume and
network names, StringData, ExtraData including Tracker droid facts
labelled derived, and derived observations such as argument length
and a minimized ShowCommand.

* fix(windows): tighten Shell Link string reads and coverage

- Decode counted StringData over its full CountCharacters payload.
- Locate LinkInfo string terminators before charging max_string_bytes
  and before decoding; an unterminated string is a coverage issue.
- Mark an IDList without a TerminalID and an out-of-range
  LinkInfoHeaderSize as partial coverage.
- Report arguments_present and argument_length as null when
  HasArguments is set but the field could not be read.
- Derive target_extension from the joined base path and suffix.
- Keep ISO dates for FILETIME and UUIDv1 timestamps before 1970.
- Retain the completed file snapshot on parse failures.
- Reject an empty CLI path before normalization.
- Select the shortcut contract from its family in focused tests.
- Fixture StringData no longer writes a NUL into the counted payload.

* style: format docs index and Shell Link boundary type

Apply oxfmt to the two files format:check reports so Static checks passes.

* fix(windows): reject network share paths for Shell Link reads

inspect_windows_shortcut is advertised as offline, but the Windows path
schema admits UNC paths, and lstat on one can contact an SMB server and
offer the caller's credentials.

Reject UNC, extended UNC, and other host-prefixed device paths in the
provider before any filesystem call. Extended drive paths such as
\\?\C:\x stay allowed. A mapped network drive cannot be told from a
local drive by its path, and the docs say so.

* fix(windows): decode Unicode Shell Link file-entry names

File-entry items with bit 0x04 of the type byte, such as 0x36, store a
UTF-16LE name, but the parser always read it as Latin-1. The read stopped
at the first zero byte, so report.exe became r and an IDList-only
shortcut reported the wrong target_extension. Read those names as
UTF-16LE.

* fix(windows): read volume labels by exact Shell Link discriminator

VolumeLabelOffset 0x14 selects VolumeLabelOffsetUnicode and is not itself a
label offset, and that Unicode field exists for no other value. The parser
treated any offset of 0x14 or more as having both, so a Unicode-only label such
as "OS" also produced a false ANSI label "O", and an ANSI label stored past 0x14
had its own bytes read as a Unicode offset.

Branch on the exact value in parseVolume, the one place that interprets it, and
report a VolumeID too short to hold the selected field. The fixture wrote both
encodings for a Unicode volume, which hid the false label, so it now writes one.

* fix(windows): limit network share rejection to Windows hosts

POSIX hosts read repeated leading slashes as one local root, so an
accepted selection such as ///tmp/shortcut.lnk is a local file there.
Apply the host-prefixed path check only on Windows, and take the
platform through the provider constructor so the Windows path forms
stay covered on every test host.

* fix(windows): compare shortcut icons only against full paths

A stored IDList filename or relative path cannot show that an icon at a
full path is elsewhere, so the comparison reported a false difference.
Report null unless the icon and a recorded target are both full paths,
and assert the missing TerminalID issue by code and offset instead of
its message.

* fix(windows): keep unread ExtraData blocks unknown

A walk that stopped before or inside ExtraData still reported the blocks
that HasExpString and HasExpIcon expect as absent, though they were never
checked for. Report a block as absent only after the TerminalBlock shows the
section was read in full. Without one the block stays unknown and coverage
stays partial.

* fix(native): ignore LNK network provider type unless ValidNetType is set

CommonNetworkRelativeLink NetworkProviderType is only meaningful when the
ValidNetType flag (0x2) is set. Return null otherwise.

* fix(native): accept any ExtraData TerminalSize below 4 as the terminal

MS-SHLLINK requires TerminalSize to be less than 4, not exactly 0. Treat
1, 2 and 3 as the terminal block instead of a malformed block.

* fix(native): derive shortcut target facts from the stored environment target

Include the EnvironmentVariableDataBlock literal target among the target
candidates for target_extension and the icon comparison. Variables are not
expanded and the target is not opened.

* fix(windows-shortcut): keep unexpanded variable paths unresolved in icon comparison

A stored environment target such as C:\Users\%USERNAME%\app.exe could be
compared as different from C:\Users\Alice\app.exe. Variable-bearing paths
are never expanded, so the icon comparison now returns null unless a fixed
target matches the icon exactly.

* test: drop redundant ok assertion before typed error guard

The testing guide asks for the typed error to be thrown before asserting a
successful Result value, and says a preceding .ok assertion adds no coverage.

* fix(windows): point out-of-range LinkInfo offsets at their field

A LinkInfo, VolumeID or CommonNetworkRelativeLink offset that points
past its structure was reported at base + offset. With an offset such
as 0xffffffff that position exceeds uint32, so the report failed its
schema and the service discarded the whole partial result.

Report such issues at the offending offset field instead, which keeps
every issue offset and coverage.failing_offset inside the file. Cover
each LinkInfo offset field in the parser tests and the
LocalBasePathOffset case through the stable filesystem service.

* fix(windows): require RFC 4122 variant before deriving Tracker UUID facts

A version nibble of 1 alone does not identify a version-1 UUID. Also require the clock_seq_hi_and_reserved top bits to be 10, so other GUID layouts keep their raw value and derive no MAC or timestamp.

* fix(windows): ignore DeviceNameOffset fields unless ValidDevice is set

MS-SHLLINK 2.3.2 says DeviceNameOffset and DeviceNameOffsetUnicode are
ignored when the ValidDevice flag is clear. parseNetwork read both
regardless, so garbage in those fields became device-name facts or
malformed_structure issues. Read the flags once and only read the device
name fields when ValidDevice is set.

* fix(windows): keep unsupported Tracker headers as raw data

Check TrackerDataBlock Length (0x58) and Version (0) before decoding.
A block with any other header is retained as raw bytes with a
malformed_structure issue, so it no longer yields MAC and timestamp
facts under complete coverage.

* fix(windows): compare shortcut icon paths by normalized location

Collapse "." and ".." segments and repeated separators in the icon
comparison as text only, never opening a path. ".." stops at the drive
or UNC share root, and \\?\ and \\.\ paths stay verbatim.

Join LocalBasePath with CommonPathSuffix as the target and use the bare
base only when the suffix is empty, as the network share branch does.

Read the selected shortcut with lstat and open only, so a rejected
symlink's destination is never resolved.

* fix(windows): keep the UNC share in the root after repeated separators

normalizePath took the host and the next split part as the UNC root, so
\\server\\share\..\app.exe kept an empty share and let .. remove the
real share. Drop empty parts before picking the root so paths on
different shares stay different.

* fix(cli): parse windows shortcut limits as decimals

The four inspect-windows-shortcut limit options now go through
cliDecimalField like the other inspection commands, so values such as
0x10 are rejected and cliDecimalArguments.test.ts passes.

* fix(native): reject linked parents of windows shortcuts

A parent directory symlink or junction pointing at a UNC share was
followed by the first lstat, since the network check reads only the
path text and the symlink rejection covers only the final component.
On Windows, lstat each ancestor from the drive root down and reject
the path at the first link, before anything follows it.

* docs(native): move Windows shortcut guide and add its feature spec

Move the Shell Link guide to docs/guides/native/windows-shortcut.md and
list it under Native binaries in the site navigation, keeping the
/windows-shortcut public route. Update README, translated README, CLI
page and authored skill links to the new physical path.

Add docs/specs/native/windows-shortcut/ with spec.md, plan.md and
tasks.md, as required by docs/development/documentation.md.

* fix(native): admit the windows shortcut parent walk

On Windows the ancestor link walk ran before the provider's resource
admission, so close() could finish while the walk kept calling lstat.
Run the walk inside the same admission as the read, and check the
caller's signal before each ancestor lstat.

* fix(native): walk the effective parents of windows shortcuts

The ancestor link walk checked every prefix of the path as written, so
C:\alias\..\real\a.lnk was refused when C:\alias is a directory link,
although Windows removes alias\.. before opening the file. Walk the
ancestors left after removing . and .. components, keeping the
caller's spelling, never climbing above an absolute root, and leaving
\\?\ paths as written since Windows does not normalize them.

* test(native): assert the linked parent as a structured fact

The parent link regression matched the phrase "junction, which" in the
refusal message, so a wording edit would fail it. Report the linked
ancestor as observed.linked_ancestor on the input issue and assert that
fact instead of the explanatory text.

* test(native): bound the shortcut close gate and release it in finally

Race the parent walk lstat acknowledgement against inspection settling
with awaitAcknowledgement, then release the gate and join the inspect
and close work in finally so a failure reports its cause instead of
waiting for the Vitest timeout.

* fix(native): walk Windows shortcut parents lazily

windowsAncestors built and kept every parent prefix before the first
lstat, so a path with thousands of components allocated memory
quadratic in its length. It now keeps only the normalized components
and yields each parent from a running prefix as the walk reaches it.

---------

Co-authored-by: Matt Van Horn <455140+mvanhorn@users.noreply.github.com>
2026-11-09 20:19:44 +08:00

32 KiB
Raw Blame History

English · 简体中文 · 繁體中文 · 日本語 · 한국어 · Türkçe · Русский · Tiếng Việt · ไทย · Deutsch · Español · Français · Українська · Polski · Português (Brasil) · العربية · فارسی · Bahasa Indonesia · Italiano · Ελληνικά · മലയാളം · Roman Urdu · Română

REA: Reverse Engineer Anything

Un unico MCP per l'ingegneria inversa su binari, applicazioni e comportamento a runtime.

Vedi una funzionalità che ti piace. Capisci come funziona, fino al livello binario.

npm version MCP tool catalog Node.js requirements skills.sh MIT license Discord

morluto%2Frea | Trendshift

Sito web · Guide · Showcase

Unisciti alla community REA su Discord

Avvio rapido · Come funziona REA · Cosa puoi analizzare · Showcase · Creare ambienti RL · FAQ · Documentazione

npx rea-agents setup

Important

Fonti ufficiali di REA: morluto/rea, rea.tools, rea-agents (npm). Segui i link di installazione e delle versioni pubblicate da queste fonti ufficiali. Un nome di repository simile o un README copiato non dimostra che un download sia ufficiale.


REA che avvia il suo bridge di analisi dentro Hopper mentre ispeziona un binario nativo



Discord
Unisciti alla community di ingegneria inversa

Discord · Domande e risposte · Show and Tell


Hai visto una funzionalità in un'app che vorresti nel tuo prodotto? Chiedi al tuo agente di analizzarla con REA. Può ispezionare l'app senza il suo codice sorgente, spiegare come funziona la funzionalità, mostrare le prove e realizzare una versione per il tuo progetto.

REA collega il tuo agente a strumenti per ispezionare binari nativi, app JavaScript ed Electron, assembly .NET e siti web. Puoi usare gli stessi strumenti anche dal terminale. L'analisi viene eseguita localmente e i risultati includono le prove e i limiti dietro ogni conclusione.

La configurazione registra REA con il tuo agente e installa le istruzioni di workflow corrispondenti. L'analisi nativa può usare un'installazione esistente di Hopper, Ghidra, IDA o Kuna; la configurazione può installare opzionalmente Hopper previa approvazione. L'analisi statica JavaScript non richiede alcun motore di analisi nativo.

Visita il sito web di REA per istruzioni di configurazione, guide illustrate e veri casi studio.

Avvio rapido

Su Linux, l’avvio di Ghidra, JADX e strumenti firmware e l’analisi statica JavaScript/Electron richiedono un ps compatibile con procps nel PATH di REA per verificare la proprietà dei processi. Vedi il prerequisito Linux.

Configura il tuo agente

Con Node.js e npm installati, esegui:

npx rea-agents setup

Scegli i tuoi agenti, rivedi le modifiche proposte e approvale. La configurazione aggiunge il server MCP di REA e le istruzioni di workflow corrispondenti, con backup della configurazione esistente. Riavvia quindi il tuo agente.

La configurazione supporta Claude Code, Codex, Cursor, Gemini CLI, Grok Build e altri agenti. Vedi installazione e configurazione per la configurazione dei provider e la registrazione manuale MCP.

MCP usa schemi di input compatti per impostazione predefinita. Per tutte le indicazioni sui campi e la validazione annidata, imposta REA_MCP_INPUT_SCHEMA_PROFILE=full nella registrazione MCP. Entrambi i profili mantengono tutti gli strumenti e la stessa validazione canonica del server; vedi la guida ai contratti MCP.

Chiedi al tuo agente

Spiega come funziona la ricerca nell'app Note, mostrami le prove e realizza
una funzionalità simile per il mio progetto.

Sostituisci Note con la tua app di destinazione e la funzionalità che vuoi capire.

Usa il terminale

Ispeziona una directory di app JavaScript/Electron estratta o un ASAR:

npx -y rea-agents@latest analyze-javascript-application /absolute/path/to/app --json

Il risultato include moduli, import, confini Electron e le relative prove. Sostituisci il percorso con il tuo bersaglio, ad esempio "D:/apps/example" su Windows.

Per installare il comando rea per un uso regolare:

npm install --global rea-agents
rea --help

Per l'analisi nativa, configura prima un provider. Vedi la guida CLI ed Evidence per i comandi nativi, la selezione del provider, gli snapshot e lo scripting.

Aggiorna REA

REA cambia rapidamente e le nuove versioni includono correzioni di bug frequenti. Tieni aggiornata la tua installazione.

Per una CLI installata con npm install --global o bun add --global:

rea update

rea --update è un alias di rea update con le stesse opzioni globali di output. I comandi di aggiornamento conservano al massimo 4 MiB complessivi di stdout/stderr. I metadati troppo grandi sono rifiutati dopo l’uscita; le installazioni verbose mantengono diagnostica limitata. L’avanzamento rispetta la contropressione del terminale e attende le scritture inviate.

Gli aggiornamenti globali con Bun richiedono Bun 1.2.17 o versioni successive. Con una versione precedente di Bun, aggiorna Bun manualmente prima di eseguire rea update.

Per aggiornare le registrazioni del tuo agente e lo skill, esegui il comando di configurazione mostrato dall'aggiornamento.

Se usi npx, aggiorna la configurazione del tuo agente con:

npx rea-agents@latest setup

Rivedi le modifiche di configurazione e riavvia il tuo agente. Per comandi CLI singoli, usa npx rea-agents@latest seguito dal comando. Con Bun, usa bunx rea-agents@latest al posto di npx rea-agents@latest.

Come funziona REA

Il tuo agente chiama REA tramite MCP per ispezionare il bersaglio e tracciare il codice rilevante. REA restituisce i risultati con le relative prove. L'agente li usa per fare domande di approfondimento, spiegare il comportamento o scrivere e testare un'implementazione. Anche i comandi CLI usano gli stessi workflow.

Flusso di indagine REA: il tuo agente pone domande su un bersaglio locale, REA lo ispeziona e ne traccia il codice usando strumenti di analisi, e l'agente usa il codice, i riferimenti e gli elementi sconosciuti restituiti per spiegare, implementare e testare.

Apri la figura a dimensione intera.

Cosa puoi analizzare

REA richiede Node.js 22.x (>=22.23.4), 24.x (>=24.22.1) o 26+ (>=26.12.1), oltre a npm. Strumenti aggiuntivi e supporto host dipendono dal bersaglio:

Obiettivo Cosa restituisce REA Requisiti e guida
Binari nativi Pseudocodice, assembly, stringhe, simboli, chiamate e riferimenti Hopper, Ghidra, IDA o Kuna; analisi nativa
Layout ELF offline Sezioni, segmenti, simboli/relocazioni originali e candidati mitigazioni statiche pwntools fornito dal chiamante su Linux x64; diagnostica binaria
PE certificates Authenticode WIN_CERTIFICATE entries and PKCS#7 signer/X.509 identity fields Built-in static PE inspection; PE certificates
PE imports Import and delay-load DLL names, ordinals, IAT RVAs and pefile import hash Built-in static PE inspection; PE imports
Windows shortcuts Shell Link target, arguments, working dir, ExtraData and Tracker droid facts Built-in static LNK inspection; Windows shortcuts
Artefatto WASM Convalida, sezioni, forme WAT di import/export esatte e WAT decodificato WABT 1.0.42 fornito dal chiamante; inspect_wasm_artifact
Bytecode EVM Selettori di dispatch, offset dei byte, argomenti inferiti e mutabilità Carrier raw/hex locale su Linux x64; guida EVM offline
Rust binaries Embedded cargo-auditable dependency list Rust binaries
ELF notes PT_NOTE/SHT_NOTE owners, types, GNU build-id and ABI-tag fields Built-in static ELF inspection; ELF notes
Binary hardening PIE, NX, RELRO, CFG and related header flags for ELF, PE and Mach-O Built-in static header inspection; binary hardening
Linux kernel modules .modinfo keys, __versions CRCs, this_module presence, and signature trailer Built-in static ELF inspection; kernel modules
Erlang BEAM IFF chunks, atoms, exports, and tables Built-in static BEAM inspection; Erlang BEAM
Apple IPS crashes .ips metadata, threads, images, registers and crash classes Built-in static JSON inspection; Apple IPS
Crash Linux registrati Note grezze, registri/segnai di ogni thread registrato e candidati mapping opzionali pwntools fornito dal chiamante su Linux x64; GDB/pwndbg opzionale; crash registrati
Installazioni desktop Runtime candidati, file di supporto, componenti e passi successivi Ispezione limitata di directory e intestazioni;Applicazioni desktop
JavaScript / Electron Moduli, import, source map, route, IPC e relazioni con add-on nativi Node.js e npm; analisi delle applicazioni; Linux: procps ps
Siti web Struttura della pagina, script, osservazioni di rete e screenshot richiesti Un browser della famiglia Chrome; analisi browser
Acquisizioni di rete salvate Richieste, risposte, payload esposti e posizioni sorgente HAR / Fiddler Everywhere SAZ; mitmdump su Linux per acquisizioni mitmproxy native; guida alle acquisizioni
Captured di pacchetti Endpoint, DNS, TLS SNI, distribuzione dei protocolli e richieste HTTP tshark e capinfos forniti dal chiamante; guida pcap
Assembly .NET Metadati, istruzioni CIL, dipendenze native dichiarate e confronti di build Nessuno (solo statico); guida managed-code
PyInstaller CArchive, PYZ, Python bytecode Static inspection; Python packaged applications
APK Android Dichiarazioni manifest, classi, metodi decompilati e riferimenti JADX headless e un JDK completo su Linux/macOS/Windows x64; guida Android
Dispositivi Android Dispositivi, pacchetti, processi, log, dump, screenshot e trasferimenti APK/file adb fornito dal chiamante (emulatore o hardware); guida ADB
Progetti JEB Unità di progetto dal motore, digest degli artifact e pseudocodice di tipi/metodi Client JEB avviato dal chiamante via MCP, selezionato con REA_JEB_MCP_URL; guida JEB
Risorse Android Manifest decodificato, tabelle stringhe, lingue e dati di versione Launcher Apktool fornito dal chiamante; guida alle risorse
App Flutter Hash dello snapshot Dart, digest delle librerie per ABI e provenienza della build del motore Nessuno (analisi APK statica); guida Flutter
Firmware Regioni, risultati di estrazione e passaggi all'analisi nativa Binwalk / Unblob su Linux; guida firmware
Pacchetti registrati Campi selezionati, valori ripetuti, filtri e regole di decodifica Linux: TShark 4.x + prlimit; guida alle catture
Segnali logici registrati Annotazioni del decoder, intervalli di campioni e diagnostica Linux: sigrok-cli 0.7.2 + prlimit; guida ai segnali
Pacchetti e risorse Inventari file, digest, plist, anatomia dei bundle Apple e risorse estratte Guida artifact e JavaScript, Applicazioni Apple
Comportamento dei processi Output del terminale, interazioni, osservazioni su uscita e filesystem ed confronti di esecuzione Linux/macOS con un PTY nativo; cattura dei processi
Binari Go Versione del compilatore incorporata, moduli, sostituzioni e impostazioni di compilazione Ispezione statica integrata ELF/PE/thin Mach-O; Nessuna installazione di Go richiesta
Database SQLite Tabelle, colonne, indici, viste, trigger e righe selezionate di tabelle ordinarie Snapshot locale database/WAL; Node.js 24.x >=24.15 o 26+ con limiti SQLite nativi
Oggetti codice GPU Target CUDA/HIP, parametri e risorse dei kernel selezionati, testo PTX conservato Ispezione statica integrata ELF/PE/fatbin/CUBIN/PTX; GPU
File di modelli Metadati GGUF / safetensors, dichiarazioni dei tensori e totali derivati Ispezione degli header; hash completo facoltativo; GGUF / safetensors
Metadati IL2CPP Immagini assembly Unity global-metadata.dat, nomi di tipi/metodi e intervalli di indici Decodifica statica delle versioni 24, 27, 29, 31, 39; senza Unity
Godot PCK Inventario ed estrazione, header/directory originali e identità dei contenuti selezionati Formati statici 2, 3, 4; senza Godot
Firme APK Firmatari v1/v2/v3/v3.1, impronte dei certificati, rotazione delle chiavi e coerenza interna dei digest Ispezione statica integrata; inspect_apk_signature

L'ispezione statica di JavaScript e .NET legge i file forniti senza eseguire l'applicazione. La cattura a runtime esegue o interagisce con il bersaglio selezionato usando i tuoi permessi utente; ogni guida runtime descrive i suoi effetti.

Per ispezionare offline i binari nativi, REA supporta anche GNU objdump e Rizin, che devi fornire autonomamente. La guida agli strumenti di reverse engineering descrive la configurazione dei provider, i comandi CLI e i limiti di Evidence. REA non installa né aggiorna questi due provider.

I formati nativi e il supporto host variano in base al provider. Vedi la configurazione di Hopper e Ghidra, la guida IDA, Kuna e il supporto sperimentale Windows Ghidra. Ghidra supporta anche l'analisi DOS a 16 bit. Per binari di grandi dimensioni, aumenta il timeout di avvio con REA_GHIDRA_STARTUP_TIMEOUT_MS / REA_HOPPER_STARTUP_TIMEOUT_MS. Per la selezione del provider, vedi la guida CLI. Controlla la disponibilità delle release per le funzionalità aggiunte dall'ultima release npm.

Showcase

Illustrazioni degli showcase del sound-pan di DX-Ball, del clipboard-bridge di Notion e dell'anello di proiettili di TH04

DX-Ball: ricostruisci un calcolo sound-pan

Segui una chiamata sonora fino al suo helper posizione-to-pan, ispeziona le istruzioni e trasforma il pseudocodice incompleto in C. La ricostruzione supera 3.205 casi x86 originali e riproduce tutti i 63 byte di funzione compilati.

Leggi il case study · Repository di ricostruzione

Notion: traccia il clipboard bridge di Electron

Trova l'API clipboard del renderer, seguila attraverso preload e IPC fino al processo principale e ispeziona il formato rich clipboard.

Leggi il case study

TH04: recupera un calcolo dell'anello di proiettili DOS

Ispeziona le istruzioni a 16 bit del gioco PC-98 originale, recupera i calcoli dell'angolo fisso e mirato e confronta il C++ ricostruito con l'output del compilatore storico.

Leggi il case study · Repository di ricostruzione

Creare ambienti RL con REA

Registra una sessione di un’app web, trasforma la sua API in strumenti ed esporta un ambiente utilizzabile da un agente IA. Eseguilo con AgentEnv, poi aggiungi attività e controlli sulle ricompense per l’addestramento RL o la valutazione.

Guida alla creazione di un ambiente · Guarda la demo su X

Se hai usato REA su qualcosa di interessante, ci piacerebbe vederlo. Condividi il tuo caso in una issue o in una pull request, includendo il bersaglio, la tua domanda, come REA ti ha aiutato e cosa hai scoperto.

Creare ambienti RL

Crea un ambiente locale in cui un agente IA possa esercitarsi in attività come cercare una issue o creare una cartella, senza eseguire l’app originale. Usalo per l’apprendimento per rinforzo (RL) o per verificare come l’agente completa le attività.

REA trasforma le richieste e le risposte API registrate in strumenti che l’agente può chiamare. L’ambiente usa i dati registrati e supporta modifiche solo quando la registrazione ne conferma gli effetti.

Configura REA nel tuo agente, poi sostituisci l’URL e le attività sulle cartelle dell’esempio con i tuoi:

Usa REA per creare un ambiente RL dalla mia app web di prova su
http://127.0.0.1:3000.
Includi elenco, creazione, rinomina ed eliminazione delle cartelle. Puoi creare
e rimuovere cartelle di prova, ma non modificare i dati esistenti.
Salvalo in una cartella chiamata my-env, verifica le operazioni disponibili e spiegami come eseguirlo.
Usare la riga di comando

Usa questi comandi se hai già un file con le richieste e le risposte dell’app registrate nel browser. Per eseguire il risultato servono anche AgentEnv e Docker.

rea environment-build ./session.har ./my-env --name my-env --json
agent-env run ./my-env

REA esporta un ambiente eseguibile con un test di base che ne verifica l’avvio e le risposte. Usalo con il tuo framework RL per definire gli obiettivi, aggiungere controlli sulle ricompense ed eseguire l’addestramento.

Guida alla creazione di un ambiente · Riferimento degli ambienti · Guarda la demo su X

FAQ

Quali agenti possono usare REA?

Qualsiasi agente che supporti server MCP locali. La configurazione configura gli agenti supportati; altri client possono usare la registrazione MCP manuale.

Ho bisogno di Hopper, Ghidra, IDA o Kuna?

L'analisi nativa profonda ne usa uno. L'ispezione statica di JavaScript e .NET funziona senza un motore di analisi nativo. La configurazione può installare Hopper previa approvazione; Ghidra, IDA e Kuna usano le tue installazioni esistenti. Vedi configurazione provider.

Devo avviare Hopper per primo?

REA avvia Hopper quando un'operazione ne ha bisogno. Su macOS, una finestra di dialogo al primo avvio potrebbe chiederti di scegliere la modalità demo o di attivare la licenza. Vedi avvio di Hopper e risoluzione dei problemi.

Cosa fa l'installazione dello skill da skills.sh?

Lo skill fornisce istruzioni di indagine per il tuo agente. Usa npx rea-agents setup per registrare il server MCP di REA e installare le istruzioni corrispondenti, quindi riavvia il tuo agente. Vedi installazione solo skill.

Quale codice restituisce REA?

L'analisi nativa restituisce pseudocodice e assembly. L'analisi JavaScript/Electron recupera moduli e le loro relazioni. Il tuo agente usa questi risultati per scrivere e testare un'implementazione; gli showcase offrono esempi concreti.

REA carica la mia app da qualche parte?

REA analizza i bersagli localmente. Il tuo agente riceve i risultati degli strumenti e il suo provider di modello ha la propria politica sui dati.

Cosa devo fare se trovo un bug?

Aggiorna prima; una release recente potrebbe averlo già risolto.

Per una CLI installata con npm install --global o bun add --global:

rea update

Per la configurazione dell'agente tramite npx:

npx rea-agents@latest setup

Se stai usando un agente, completa l'aggiornamento della configurazione e riavvialo. Riprova lo stesso task. Se il problema persiste, apri un issue con la tua versione di REA, il tipo di bersaglio, i passaggi per riprodurlo e l'output di errore.

Documentazione

Inizia dalle guide pratiche del sito web. Per opzioni esatte, prerequisiti e contratti dei risultati:

Segnala vulnerabilità tramite SECURITY.md.

Cronologia delle stelle

🎉 400.000 stelle su GitHub — grazie!

Grazie a tutti coloro che usano REA, segnalano bug, propongono funzionalità, testano le build e contribuiscono con correzioni.

Cronologia stelle GitHub di REA

Disclaimer

Consulta DISCLAIMER.md per le indicazioni sull'uso responsabile.

REA è destinato alla ricerca, alla formazione, all’interoperabilità, alla conservazione del software e all’analisi di software di tua proprietà o che sei autorizzato a esaminare, nel rispetto della legge.

The project's position on illegal or unauthorized use covers all REA versions, distribution channels, and platforms; each copy retains its applicable licenses.

Contributing

Apprezzeremmo il tuo aiuto con REA! Apri un issue per segnalare un bug o suggerire una funzionalità, oppure invia una pull request per migliorare il codice o la documentazione.

Vedi CONTRIBUTING.md per la configurazione di sviluppo e i controlli, testing per le lane di verifica e la mappa dell'architettura per la struttura del progetto.

License

MIT

REA-authored code is licensed under MIT. Third-party material retains its own licenses and copyright notices; see Third-party notices for the dependency inventory, preserved license texts, and external-tool terms.

You must legally obtain and be authorized to use commercial tools, including IDA Pro / Hex-Rays decompilers, Hopper, and JEB, under their applicable licenses. REA grants no tool license, key, or activation entitlement. Trials and demos remain subject to vendor terms, including user, feature, automation, and output sharing restrictions. Cracked copies, stolen keys, unauthorized key sharing, and bypassing license restrictions are not authorized. This guidance does not amend MIT or third-party licenses.