morluto
5c53bcaed8
* test(mcp): check advertised schemas against a portable dialect in every profile * fix(mcp): re-emit advertised patterns in a portable regex grammar * fix(mcp): present discover_tools input through the selected profile The hot-cold catalog registered discover_tools directly with the SDK, so the default compact input profile still advertised its canonical schema, including page-size defaults clients apply on their own (#5322). Route every listed input schema, transport discovery included, through one server-owned presentation, and pass the selected presentation to the deferred server, which serves recorded tool schemas but not discovery. * fix(mcp): keep the Evidence union on described borrowed inputs borrowEvidenceInput installed its advertised projection on one schema instance. A call site's .describe() rebuilds the schema from its definition, so match_native_functions advertised left and right as unconstrained values in every input profile. Install the projection in the borrowed parser's constructor so derived schemas keep it, for both borrowed inputs and borrowed arrays. * fix(mcp): validate advertised dialect by selected profile * fix(mcp): preserve schema widening through references * feat(mcp): project compact input schemas into the portable advertised dialect One projection (advertisedDialectProjection.ts) owns the compact input advertisement: one type per node, items on every array, string literals as enums, oneOf widened to anyOf, allOf merged, tuples as element unions, exclusive bounds made inclusive, and every keyword outside the dialect dropped. Each rewrite is exact or widening; server validation is unchanged. The root description and sentences for dropped cross-field constraints move to the tool description, which Codex and Zed keep. The compact baseline falls to nullable values only (29), which the dialect cannot express without narrowing an input. The gateway shape repairs (typeArrayItemUnions, hasGatewayIncompatibleShape), the second dependentRequired-to-prose copy and the strict-gateway test denylist are removed; the dialect checker gates the inline presentation instead. * feat(mcp): omit output schemas from tools/list by default No surveyed model API reads an output schema, MCP client validators repeat REA's own result validation, and complete output schemas were about 92% of the default tools/list. REA_MCP_OUTPUT_SCHEMA_PROFILE now resolves to off through one owner (resolveMcpOutputSchemaProfile); compact and full remain selectable. structuredContent is still delivered, and the deferred server serves both off and full from the recorded catalog with the matching recorded identity. Tests and artifact verifiers that validate results against complete advertised output contracts select full explicitly. * docs: describe omitted output schemas as the default in README translations * fix(mcp): select schemas in verification workflows * fix(mcp): refuse zero-padded repeat bounds and record host-specific path patterns * fix(mcp): keep projected schemas permissive * fix(mcp): keep references valid when presentation widens their targets * fix(mcp): keep a single union branch's closure scoped to its properties * fix(mcp): select complete output schemas in the Electron verifier * fix(mcp): select complete output schemas in standalone verifier probes * fix(mcp): keep an allOf member's tuple tail with its own positions * fix(mcp): relax references into negations and conditionals presentation may remove * refactor(contracts): declare root discriminators as typed schema annotations * test(mcp): select the borrowed Evidence contract from its family * fix(mcp): keep astral literals and dynamic references widening in every mode * fix(mcp): omit astral literals and relax untracked references when presentation widens * fix(mcp): select complete output schemas in every verifier transport * fix(mcp): read reference pointers by schema position, not segment spelling * fix(mcp): protect references into collapsing boolean unions and keep referencing branches out of the collapse * fix(mcp): keep reduced schemas open when their root admits names by pattern * test(mcp): keep the reduced-schema pattern case outside the size-limited block * fix(mcp): omit patterns whose classes name astral characters * fix(mcp): decide union collapse and pointer protection from canonical branches * docs(mcp): document non-u astral matching and pin BMP agreement across V8 modes * fix(mcp): keep prototype-named properties as own properties in the dialect projection * test(mcp): select full output schemas in packet and signal schema checks * test(mcp): expect the advertised base64 schema to omit the unbounded pad-bit probe * fix(mcp): protect references into unevaluated keywords lost evaluation removes * fix(mcp): validate the doctor probe reply against the canonical output contract (#10655) * fix(mcp): validate the doctor probe reply against the canonical output contract * test(mcp): replay doctor probe validation under every output profile * test(mcp): accept typed-branch nullable unions in the advertised dialect (#10649) * test(mcp): select full output schemas in HTTP session workflows * fix(mcp): emit stack-safe classes with non-ASCII members and protect draft-07 reference siblings * fix(mcp): protect references into literal siblings of relaxed draft-07 references * feat(mcp): omit output schemas from tools/list by default (#10646) * feat(mcp): omit output schemas from tools/list by default No surveyed model API reads an output schema, MCP client validators repeat REA's own result validation, and complete output schemas were about 92% of the default tools/list. REA_MCP_OUTPUT_SCHEMA_PROFILE now resolves to off through one owner (resolveMcpOutputSchemaProfile); compact and full remain selectable. structuredContent is still delivered, and the deferred server serves both off and full from the recorded catalog with the matching recorded identity. Tests and artifact verifiers that validate results against complete advertised output contracts select full explicitly. * fix(mcp): select schemas in verification workflows * fix(mcp): select complete output schemas in the Electron verifier * fix(mcp): select complete output schemas in standalone verifier probes * fix(mcp): select complete output schemas in every verifier transport * test(mcp): select full output schemas in packet and signal schema checks * fix(mcp): validate the doctor probe reply against the canonical output contract (#10655) * fix(mcp): validate the doctor probe reply against the canonical output contract * test(mcp): replay doctor probe validation under every output profile * test(mcp): accept typed-branch nullable unions in the advertised dialect (#10649) * test(mcp): select full output schemas in HTTP session workflows * fix(mcp): keep the Evidence union on described borrowed inputs (#10597) * fix(mcp): keep the Evidence union on described borrowed inputs borrowEvidenceInput installed its advertised projection on one schema instance. A call site's .describe() rebuilds the schema from its definition, so match_native_functions advertised left and right as unconstrained values in every input profile. Install the projection in the borrowed parser's constructor so derived schemas keep it, for both borrowed inputs and borrowed arrays. * test(mcp): select the borrowed Evidence contract from its family * docs(mcp): admit baseline growth only for restored contract declarations * fix(mcp): state reduced multi-type properties as typed branches, not type lists The reduced fallback derived a property's types and emitted them as a type list, which Gemini, Moonshot and Ark reject. A property whose canonical schema is anyOf string and number therefore traded a typed union for a rejected construct when the inline projection fell back. Emit one type, or anyOf typed branches, so [T, null] becomes the dialect's nullable union. * feat(mcp)!: retire the full schema profiles and declare complete observations as a typed annotation (#10718) * refactor(mcp): declare complete observations as a typed annotation applied only on the wire * test(mcp): compare complete-observation declarations with their owning text * refactor(schema): couple Zod checks with their JSON Schema constraint keywords (#10725) * refactor(schema): couple Zod checks with their JSON Schema constraint keywords * refactor(schema): declare pattern approximations and object output roots as typed annotations (#10754) * refactor(schema): declare pattern approximations and object output roots as typed annotations * fix(schema): refuse pattern declarations JSON Schema cannot state * test(schema): select guided_workflows from its contract family * feat(mcp)!: retire the full input and output schema profiles (#10841) * feat(mcp)!: retire the full input and output schema profiles The compact input presentation is now the only advertised input schema, and output schemas are either omitted (`off`, the default) or bounded (`compact`). Catalog identity, the build-recorded digests and the recorded startup catalog collapse to those presentations: two digest profiles instead of six, one recorded catalog instead of two, and no input dialect baseline. Tests and verifiers that validated replies against listed full output schemas now validate against the canonical output contract, which REA already enforces server-side; tests that asserted canonical input restrictions read the canonical input schema instead of a full listing. BREAKING CHANGE: `REA_MCP_INPUT_SCHEMA_PROFILE=full` and `REA_MCP_OUTPUT_SCHEMA_PROFILE=full` are refused at startup and by `rea setup` with a configuration error naming the setting. Remove the setting from the client registration (or rerun setup with `REA_MCP_INPUT_SCHEMA_PROFILE=compact` / `REA_MCP_OUTPUT_SCHEMA_PROFILE=compact`). `REA_MCP_INPUT_SCHEMA_PROFILE` still accepts `compact`. Server-side validation is unchanged. * test(mcp): validate replies against canonical output contracts at every listed-schema reader tools/list omits output schemas by default, so fixtures, verifiers and the Android analysis runners that read a listed outputSchema now bind the canonical contract instead. connectLocalToolsMcp and advertisedMcpToolSchemas hand the SDK a definition carrying the canonical output schema, so the SDK client and caller-supplied validators check every successful reply. * test(mcp): resolve Android runners' output contracts from the selected repository The Android efficiency runners imported the canonical output-schema helper from the harness checkout while --repository selects the revision under test. Import it from the selected repository, as the runners already do for the SDK and Ajv. * test(mcp): let Android runners compare revisions before the canonical output helper A selected revision without scripts/lib/canonical-output-schema.mjs could not start the Android runners. Choose the output contracts in one harness helper: the selected revision's canonical contracts when it has them, otherwise its listed schemas under the full output profile it still supports. * fix(scripts): keep caller launch settings when the real Hopper verifier builds its server environment The verifier deleted REA_VERIFY_SERVER_COMMAND and REA_VERIFY_SERVER_ARGS_JSON from process.env itself before reading them, so a caller selecting an installed REA command silently ran the checkout's dist/main.js. Copy the environment, as main does, so only the child's environment changes. * test(mcp): validate whole replies against canonical output contracts wherever a listed definition is held tools/list omits output schemas by default and the full output profile is gone, so tests that handed the SDK a listed definition no longer checked complete replies. Attach the canonical output schema with withCanonicalOutputSchema at every held REA tool definition. Environment-served tools (not REA contracts), and the deferred-runtime and doctor tests that exercise per-profile listings, keep their listed definitions. * test(mcp): record the advertised catalog summary without the retired full profiles Retiring the full input and output profiles leaves only the compact input and compact output listings, so the summary drops the full-profile digests and every pattern only the full listings carried. Regenerated with npm run verify:advertised-schemas -- --update-summary.
37 KiB
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 singur server MCP pentru inginerie inversă: fișiere binare, aplicații și comportament în timpul execuției.
Ai găsit o funcționalitate care îți place? Înțelege cum funcționează, până la nivel de cod binar.
Site web · Ghiduri · Studii de caz
Pornire rapidă · Cum funcționează REA · Ce poți analiza · Studii de caz · Construiește medii RL · Întrebări frecvente · Documentație
npx rea-agents setup
Important
Descarcă REA din morluto/rea, de pe rea.tools sau prin pachetul npm rea-agents. Urmează linkurile de instalare și către versiunile publicate oferite de aceste surse oficiale. Un nume de repository asemănător sau un README copiat nu dovedește că descărcarea provine dintr-o sursă oficială.
 Alătură-te comunității de inginerie inversă Discord · Întrebări și răspunsuri · Prezentări și demonstrații |
Ai văzut într-o aplicație o funcționalitate pe care ai vrea să o incluzi în propriul produs? Cere-i agentului tău să o investigheze cu REA. Poate inspecta aplicația fără codul ei sursă, poate explica modul în care funcționează acea funcționalitate, poate prezenta dovezile și poate construi o variantă pentru proiectul tău.
REA conectează agentul tău la unelte pentru inspectarea fișierelor binare native, a aplicațiilor JavaScript și Electron, a ansamblurilor .NET și a site-urilor web. Poți folosi aceleași unelte și din terminal. Analiza rulează local, iar rezultatele includ dovezile și limitările care stau la baza fiecărei concluzii.
Programul de configurare înregistrează REA în agentul tău și instalează instrucțiunile corespunzătoare pentru fluxul de lucru. Analiza nativă poate folosi o instalare existentă de Hopper, Ghidra, IDA sau Kuna; programul de configurare poate instala opțional Hopper, cu aprobarea ta. Analiza statică JavaScript nu necesită un motor de analiză nativă.
Vizitează site-ul REA pentru instrucțiuni de configurare, ghiduri ilustrate și studii de caz reale.
Pornire rapidă
Pe Linux, pornirea Ghidra, JADX și a uneltelor pentru firmware, precum și analiza
statică JavaScript/Electron necesită un ps compatibil cu procps în PATH-ul REA,
pentru a verifica dacă procesele îi aparțin. Pașii de remediere sunt în
docs/getting-started/installation.md, la secțiunea „Linux owned-process prerequisite”.
Configurează agentul
Cu Node.js și npm instalate, rulează:
npx rea-agents setup
Alege agenții, verifică modificările propuse și aprobă-le. Configurarea adaugă serverul MCP REA și instrucțiunile corespunzătoare pentru fluxul de lucru, creând copii de siguranță ale configurației existente. Repornește apoi agentul.
Programul de configurare acceptă Claude Code, Codex, Cursor, Gemini CLI, Grok Build și alți agenți. Consultă instalarea și configurarea pentru configurarea motoarelor de analiză și înregistrarea manuală a serverului MCP.
MCP anunță scheme de intrare compacte, pentru a reduce spațiul ocupat în context; îndrumările omise de o schemă compactă urmează descrierea uneltei. Toate uneltele și validarea canonică a serverului rămân neschimbate. Consultă secțiunea „Compact input schema profile” din ghidul contractelor MCP.
Configurarea înregistrează direct mediul de execuție ales și scriptul de intrare REA. Dacă folosești un executor de pachete, păstrează intrarea sa din cache și mediul de execuție; obține pachetul dintr-un director de încredere din afara proiectului țintă. Consultă ghidul de instalare.
Schemele de ieșire sunt omise implicit din tools/list: niciun API de model nu le citește, iar REA validează singur fiecare rezultat. Setează REA_MCP_OUTPUT_SCHEMA_PROFILE=compact în înregistrarea MCP pentru a anunța fiecare schemă de ieșire în limita a 4096 de octeți. În toate setările, validarea serverului și rezultatele structurate rămân complete. Consultă „Output schemas” din ghidul contractelor MCP.
Cere-i agentului
Înțelege cum funcționează căutarea în aplicația Notes, arată-mi dovezile și
construiește o funcționalitate similară pentru proiectul meu.
Înlocuiește Notes cu aplicația vizată și precizează funcționalitatea pe care vrei să o înțelegi.
Folosește terminalul
Inspectează directorul extras al unei aplicații JavaScript/Electron sau o arhivă ASAR:
npx -y rea-agents@latest analyze-javascript-application /absolute/path/to/app --json
Rezultatul include modulele, importurile, delimitările dintre componentele Electron
și dovezile aferente. Înlocuiește calea cu cea a aplicației vizate, de exemplu
"D:/apps/example" pe Windows.
Pentru a instala comanda rea și a o folosi în mod curent:
npm install --global rea-agents
rea --help
Pentru analiza nativă, configurează mai întâi un motor de analiză. Consultă ghidul CLI și Evidence pentru comenzile de analiză nativă, selectarea motorului, instantanee și utilizarea în scripturi.
Actualizează REA
REA evoluează rapid, iar versiunile noi includ frecvent corecții de erori. Menține instalarea la zi.
Pentru o interfață CLI instalată cu npm install --global sau bun add --global:
rea update
rea --update este un alias pentru acest flux de actualizare verificat și acceptă
aceleași opțiuni globale de ieșire. Folosește rea update când îl combini cu alte
opțiuni de control al comenzii.
Comenzile de actualizare păstrează cel mult 4 MiB în total din stdout și stderr. Răspunsurile cu metadate prea mari sunt respinse după încheierea comenzii; instalările cu ieșire detaliată continuă cu un volum limitat de date de diagnostic. Afișarea progresului în terminal ține cont de ritmul în care acesta poate primi date și așteaptă finalizarea operațiilor de scriere deja trimise.
Actualizările instalărilor globale cu Bun necesită Bun 1.2.17 sau o versiune mai nouă.
Dacă ai o versiune mai veche, actualizează Bun manual înainte de a rula rea update.
Pentru a actualiza înregistrările agenților și skill-ul, rulează comanda de configurare afișată de programul de actualizare.
Dacă folosești npx, actualizează configurarea agentului cu:
npx rea-agents@latest setup
Verifică modificările de configurare și repornește agentul. Pentru comenzi CLI
ocazionale, folosește npx rea-agents@latest urmat de comandă. Cu Bun, folosește
bunx rea-agents@latest în loc de npx rea-agents@latest.
Cum funcționează REA
Agentul tău apelează REA prin MCP pentru a inspecta ținta și a urmări codul relevant. REA returnează constatările împreună cu dovezile aferente. Agentul le folosește pentru a pune întrebări suplimentare, a explica comportamentul sau a scrie și testa o implementare. Comenzile CLI folosesc aceleași fluxuri de lucru.
Deschide figura la dimensiunea originală.
Ce poți analiza
REA necesită Node.js 22.x (>=22.23.4), 24.x (>=24.22.1) sau 26.12.1+, plus npm. Uneltele suplimentare și platformele acceptate depind de ținta analizată:
| Țintă | Ce returnează REA | Cerințe și ghid |
|---|---|---|
| Aplicații desktop instalate | Componente de execuție candidate, fișiere auxiliare, indicii despre componente și următoarele verificări | Inspectare integrată a directoarelor și antetelor, cu limite de resurse; aplicații desktop |
| Fișiere binare native | Pseudocod, cod de asamblare, șiruri de caractere, simboluri, apeluri și referințe | Hopper, Ghidra, IDA sau Kuna; analiză nativă |
| Structura ELF, offline | Secțiuni, segmente, simboluri și relocări originale, precum și indicii statice despre mecanismele de protecție | pwntools furnizat de utilizator, pe Linux x64; diagnosticarea binarelor |
| Fișiere binare Go | Versiunea compilatorului încorporată în fișier, modulele, înlocuirile și setările de compilare | Inspectare statică integrată a fișierelor ELF/PE/Mach-O cu o singură arhitectură; nu necesită instalarea Go |
| Obiecte de cod GPU | Ținte CUDA/HIP, parametri și resurse selectate ale kernelurilor GPU, textul PTX păstrat | Inspectare statică integrată a fișierelor ELF/PE/fatbin/CUBIN/PTX; obiecte de cod GPU |
| Fișiere de model | Metadate GGUF / safetensors, declarații de tensori și totaluri calculate din acestea | Inspectare integrată a antetelor; opțional, hash al întregului fișier; fișiere de model |
| Metadate IL2CPP | Imagini de ansambluri din global-metadata.dat al Unity, nume de tipuri și metode și intervale de indici | Decodare statică integrată a versiunilor 24, 27, 29, 31 și 39; nu necesită Unity |
| Godot PCK | Inventarul și extragerea arhivei, informații originale din antet și director și identificatori ai conținutului selectat | Suport static integrat pentru formatele 2, 3 și 4; nu necesită Godot |
| Fișiere binare Rust | Nume, versiuni, surse și relații de dependență ale pachetelor crate încorporate prin cargo-auditable | Inspectare statică integrată a fișierelor ELF/PE/Mach-O cu o singură arhitectură; binare Rust |
| Certificate PE | Intrări Authenticode WIN_CERTIFICATE și câmpuri de identitate ale semnatarilor PKCS#7 și certificatelor X.509 | Inspectare statică integrată a fișierelor PE; certificate PE |
| Importuri PE | Numele DLL-urilor importate și încărcate întârziat, ordinale, RVA-uri ale IAT și hash-ul importurilor calculat de pefile | Inspectare statică integrată a fișierelor PE; importuri PE |
| Scurtături Windows | Țintă Shell Link, argumente, director de lucru, ExtraData și identificatori Tracker | Inspectare statică integrată a fișierelor LNK; scurtături Windows |
| Note ELF | Proprietari și tipuri PT_NOTE/SHT_NOTE, câmpuri GNU build-id și ABI-tag | Inspectare statică integrată a fișierelor ELF; note ELF |
| Întărire binară | PIE, NX, RELRO, CFG și indicatori de antet pentru ELF, PE și Mach-O | Inspecție statică integrată a antetelor; întărire binară |
| Rapoarte Apple IPS de eroare fatală | Metadate .ips, fire de execuție, imagini binare, registre și clase documentate de erori fatale | Inspectare statică integrată a datelor JSON; Apple IPS |
| Module de kernel Linux | Chei .modinfo, CRC-uri din __versions, prezența this_module și structura semnăturii de la sfârșitul fișierului | Inspectare statică integrată a fișierelor ELF; module de kernel |
| Erlang BEAM | Blocuri IFF, atomi, exporturi, importuri, funcții lambda și antetul Code | Inspectare statică integrată a fișierelor BEAM; Erlang BEAM |
| Fișiere WASM | Validare, secțiuni, forme WAT exacte ale importurilor și exporturilor și cod WAT decodat | WABT 1.0.42 furnizat de utilizator; inspect_wasm_artifact |
| Bytecode EVM | Selectori de apel, poziții în octeți, argumente și mutabilitate deduse | Fișier local în format brut sau hexazecimal, pe Linux x64; ghid EVM offline |
| Baze de date SQLite | Tabele, coloane, indecși, vizualizări, declanșatoare și rânduri selectate din tabele obișnuite | Instantaneu local al bazei de date/WAL; Node.js 24.x >=24.15 sau 26+, cu limite SQLite native |
| Erori fatale Linux înregistrate | Note brute, registrele și semnalele fiecărui fir înregistrat și, opțional, corespondențe candidate pentru mapările de memorie | pwntools furnizat de utilizator, pe Linux x64; opțional GDB/pwndbg; erori fatale înregistrate |
| JavaScript / Electron | Module, importuri, hărți de cod sursă, rute, IPC și relații cu extensiile native | Node.js și npm; pe Linux: ps compatibil cu procps; analiza aplicațiilor |
| Site-uri web | Structura paginilor, scripturi, observații de rețea și capturi de ecran solicitate | Un browser din familia Chrome; analiză în browser |
| Capturi de rețea salvate | Cereri, răspunsuri, conținuturi expuse ale mesajelor și pozițiile lor în sursă | HAR sau SAZ din Fiddler Everywhere; mitmdump pe Linux pentru formatul nativ mitmproxy; ghidul capturilor |
| Ansambluri .NET | Metadate, instrucțiuni CIL, dependențe native declarate și comparații între compilări | Fără cerințe suplimentare (doar analiză statică); ghidul codului gestionat |
| APK-uri Android | Declarații din manifest, clase, metode decompilate și referințe | JADX fără interfață grafică și un JDK complet, pe Linux/macOS/Windows x64; ghidul Android |
| Semnături APK | Semnatari v1/v2/v3/v3.1, amprente ale certificatelor, rotația cheilor și consistența internă a hash-urilor | Fără cerințe suplimentare (doar analiză statică); inspect_apk_signature |
| Dispozitive Android | Dispozitive, pachete, procese, jurnale, dumpuri, capturi de ecran și transferuri de APK-uri și fișiere | adb furnizat de utilizator (emulator sau dispozitiv fizic); ghidul ADB |
| Proiecte JEB | Unități de proiect analizate prin motor, hash-uri ale artefactelor și pseudocod pentru tipuri și metode | Un client JEB pornit de utilizator, care oferă un server MCP și este selectat prin REA_JEB_MCP_URL; ghidul JEB |
| Resurse Android | Manifest decodat, tabele de șiruri de caractere, localizări și informații despre versiune | Program de lansare Apktool furnizat de utilizator; ghidul resurselor |
| Aplicații Flutter | Hash-ul instantaneului Dart, hash-uri ale bibliotecilor pentru fiecare ABI și proveniența compilării motorului | Fără cerințe suplimentare (parsare statică a APK-ului); ghidul Flutter |
| Firmware | Regiuni, rezultate ale extragerii și transferul către analiza nativă | Binwalk / Unblob pe Linux; ghidul firmware |
| Pachete de rețea înregistrate | Câmpuri selectate, valori repetate, filtre și reguli decode-as | Linux: TShark 4.x + prlimit; ghidul capturilor |
| Rezumate ale traficului de rețea | Puncte terminale, DNS, TLS SNI, distribuția protocoalelor și cereri HTTP | tshark și capinfos furnizate de utilizator (verificate pe Linux); ghidul pcap |
| Semnale logice înregistrate | Adnotări ale decodorului, intervale de eșantioane și date de diagnostic | Linux: sigrok-cli 0.7.2 + prlimit; înregistrări de semnale |
| Pachete și resurse | Inventare de fișiere, hash-uri, fișiere plist, structura pachetelor de aplicație Apple și resurse extrase | Ghidul artefactelor și JavaScript, aplicații Apple |
| Comportamentul proceselor | Ieșirea în terminal, interacțiuni, observații despre terminarea proceselor și sistemul de fișiere și comparații între rulări | Linux/macOS cu un PTY nativ; capturarea proceselor |
| Executabile PyInstaller | Membri CArchive, versiunea Python, scripturi de intrare și bytecode extras | Fără cerințe suplimentare (doar analiză statică); aplicații Python împachetate |
| Deno compile binaries | Virtual files, entry point, recorded options, npm snapshot length | Static inspection; Deno compile executables |
Inspectarea statică JavaScript și .NET citește fișierele furnizate fără a rula aplicația. Capturarea în timpul execuției rulează ținta selectată sau interacționează cu aceasta folosind permisiunile contului tău; fiecare ghid de capturare descrie efectele acestor operații.
Pentru inspectarea offline a binarelor native, REA acceptă și GNU objdump și Rizin, furnizate de utilizator. Consultă ghidul uneltelor de inginerie inversă pentru configurare, comenzi CLI și limitările obiectelor Evidence. REA nu instalează și nu actualizează niciunul dintre aceste două instrumente.
Formatele native și platformele acceptate diferă în funcție de motorul de analiză.
Consultă configurarea Hopper și Ghidra,
ghidul IDA (inclusiv o componentă opțională de legătură MCP nativă),
ghidul decompilatorului Kuna și
suportul experimental Ghidra pe Windows.
Ghidra acceptă și analiza DOS pe 16 biți.
Pentru binare mari, mărește timpul maxim de pornire al motorului cu
REA_GHIDRA_STARTUP_TIMEOUT_MS sau REA_HOPPER_STARTUP_TIMEOUT_MS.
Pentru selectarea motorului, consultă ghidul CLI.
Verifică disponibilitatea în versiunile publicate
pentru funcționalitățile adăugate după cea mai recentă versiune npm.
Studii de caz
DX-Ball: reconstruiește calculul panoramării sunetului
Urmărește un apel audio până la funcția auxiliară care transformă poziția în panoramare stereo, inspectează instrucțiunile și transformă pseudocodul incomplet în C. Reconstrucția trece 3.205 cazuri de test comparate cu originalul x86 și reproduce toți cei 63 de octeți ai funcției compilate.
Citește studiul de caz · Repository-ul reconstrucției
Notion: urmărește legătura Electron cu clipboardul
Găsește API-ul pentru clipboard din procesul de randare, urmărește-l prin preload și IPC până în procesul principal și inspectează formatul datelor cu formatare din clipboard.
TH04: recuperează calculul unui inel de proiectile DOS
Inspectează instrucțiunile pe 16 biți ale jocului original pentru PC-98, recuperează calculele unghiurilor fixe și ale celor orientate spre țintă și compară codul C++ reconstruit cu rezultatul compilatorului folosit la acea vreme.
Citește studiul de caz · Repository-ul reconstrucției
Construiește medii RL cu REA
Înregistrează o sesiune de aplicație web, transformă API-ul în instrumente și exportă un mediu pe care un agent AI îl poate folosi. Rulează cu AgentEnv, apoi adaugă sarcini și verificări de recompensă pentru antrenare RL sau evaluare.
Ghid pentru construirea unui mediu · Vezi demonstrația pe X
Dacă ai folosit REA pentru ceva interesant, ne-ar plăcea să vedem rezultatul. Prezintă cazul într-un issue sau într-un pull request, menționând ținta analizată, întrebarea ta, cum te-a ajutat REA și ce ai descoperit.
Construiește medii RL
Creează un mediu local în care un agent AI să exerseze sarcini precum găsirea unui issue sau crearea unui dosar, fără a rula aplicația originală. Folosește-l pentru învățare prin recompensă (RL) sau pentru a testa cât de bine îndeplinește agentul sarcinile.
REA transformă cererile și răspunsurile API înregistrate în instrumente pe care agentul le poate apela. Mediul folosește datele înregistrate și permite modificări doar când înregistrarea le confirmă efectele.
După ce configurezi REA în agent, înlocuiește URL-ul și sarcinile pentru dosare din exemplu cu ale tale:
Folosește REA pentru a crea un mediu RL din aplicația mea web de test de la
http://127.0.0.1:3000.
Include listarea, crearea, redenumirea și ștergerea dosarelor. Poți crea și elimina
dosare de test, dar nu modifica datele existente.
Salvează într-un dosar numit my-env, verifică operațiile disponibile și spune-mi cum îl rulez.
Folosește linia de comandă
Folosește aceste comenzi dacă ai deja un fișier cu cererile și răspunsurile aplicației înregistrate în browser. Pentru a rula rezultatul ai nevoie și de AgentEnv și Docker.
rea environment-build ./session.har ./my-env --name my-env --json
agent-env run ./my-env
REA exportă un mediu executabil cu un test de bază care verifică pornirea și răspunsurile. Conectează-l la frameworkul RL pentru a defini obiectivele, a adăuga verificări de recompensă și a rula antrenarea.
Ghid pentru construirea unui mediu · Referință pentru medii · Vezi demonstrația pe X
Medii pentru aplicații desktop
REA poate crea și un mediu pentru o aplicație desktop Linux, pe care un agent o folosește prin capturi de ecran, mouse și tastatură. Dintr-o cerere de un rând, precum „Creează-mi un mediu Gnote în care agentul adaugă ulei de măsline în notița cu lista de cumpărături”, agentul tău instalează aplicația pe un computer de build local, scrie sarcina, exportă mediul și verifică sarcina pe un computer nou. Mașina care îl creează are nevoie de Linux pe amd64 sau arm64, Docker și versiunea frameworkului agentenv fixată de ghid.
Configurează mediile pentru aplicații desktop
Întrebări frecvente
Ce agenți pot folosi REA?
Orice agent care acceptă servere MCP locale. Programul de configurare pregătește agenții acceptați; pentru ceilalți clienți poți folosi înregistrarea manuală MCP.
Am nevoie de Hopper, Ghidra, IDA sau Kuna?
Analiza nativă aprofundată folosește unul dintre aceste instrumente. Inspectarea statică JavaScript și .NET funcționează fără un motor de analiză nativă. Programul de configurare poate instala Hopper după aprobare; pentru Ghidra, IDA și Kuna folosește instalările existente. Consultă configurarea motoarelor de analiză.
Trebuie să pornesc mai întâi Hopper?
REA pornește Hopper când o operație are nevoie de el. Pe macOS, un dialog afișat la prima pornire îți poate cere să alegi modul demonstrativ sau să activezi licența. Finalizează acel pas în aceeași sesiune de utilizator înainte de prima operație CLI/MCP sau de prima sarcină nesupravegheată. Deschide Hopper manual dacă este nevoie. Consultă pornirea Hopper și depanarea.
Ce face instalarea skill-ului de pe skills.sh?
Skill-ul oferă agentului instrucțiuni de investigare. Folosește npx rea-agents setup
pentru a înregistra serverul MCP REA și a instala instrucțiunile corespunzătoare,
apoi repornește agentul. Consultă instalarea doar a skill-ului.
Ce cod returnează REA?
Analiza nativă returnează pseudocod și cod de asamblare. Analiza JavaScript/Electron recuperează modulele și relațiile dintre ele. Agentul tău folosește aceste constatări pentru a scrie și testa o implementare; studiile de caz oferă exemple detaliate.
REA îmi încarcă aplicația pe un server?
REA analizează țintele local. Agentul tău primește rezultatele uneltelor, iar furnizorul modelului său are propria politică privind datele.
Ce fac dacă întâlnesc o eroare?
Actualizează mai întâi; o versiune recentă ar putea să o fi remediat deja.
Pentru o interfață CLI instalată cu npm install --global sau bun add --global:
rea update
Pentru configurarea agentului prin npx:
npx rea-agents@latest setup
Dacă folosești un agent, finalizează actualizarea configurării și repornește-l. Reîncearcă aceeași sarcină. Dacă problema persistă, deschide un issue și include versiunea REA, tipul țintei analizate, pașii de reproducere și mesajele de eroare.
Documentație
Începe cu ghidurile practice de pe site. Pentru opțiunile exacte, cerințele preliminare și contractele rezultatelor:
- Instalare și configurare: înregistrarea agenților, configurarea motoarelor de analiză, actualizări și dezinstalare.
- Verificarea pregătirii și depanare: diagnosticarea unui agent sau motor de analiză.
- CLI și Evidence: comenzi, selectarea motorului, instantanee, import/export și coduri de ieșire.
- Contracte MCP și prompturi pentru agenți: rezultatele uneltelor, sesiuni și investigații ghidate.
- Catalogul uneltelor: inventarul generat al uneltelor, motoarelor de analiză și comenzilor CLI.
- Plan de dezvoltare: lucrări planificate și urmărirea progresului funcționalităților.
Raportează vulnerabilitățile conform SECURITY.md.
Istoricul stelelor
🎉 400.000 de stele pe GitHub — vă mulțumim!
Mulțumim tuturor celor care folosesc REA, raportează erori, propun funcționalități, testează versiuni și contribuie cu remedieri.
Precizări privind utilizarea
Consultă DISCLAIMER.md pentru îndrumări privind utilizarea responsabilă.
Poziția proiectului față de utilizarea ilegală sau neautorizată se aplică tuturor versiunilor REA, canalelor de distribuție și platformelor; fiecare copie își păstrează licențele aplicabile.
REA este destinat cercetării legale, educației, interoperabilității, conservării software-ului și analizei programelor pe care le deții sau pe care ai autorizarea să le examinezi.
Contribuții
Ne-ar bucura să contribui la REA! Deschide un issue pentru a raporta o eroare sau a propune o funcționalitate ori trimite un pull request pentru a îmbunătăți codul sau documentația.
Consultă CONTRIBUTING.md pentru pregătirea mediului de dezvoltare și verificări, ghidul de testare pentru categoriile de verificări și diagrama arhitecturii pentru anumite straturi și relații de dependență.
Licență
Codul scris în cadrul REA este licențiat sub MIT. Materialele terților își păstrează propriile licențe și mențiuni privind drepturile de autor; consultă mențiunile privind terții pentru inventarul dependențelor, textele licențelor păstrate și condițiile aplicabile uneltelor externe.
Trebuie să obții legal uneltele comerciale și să ai dreptul să le folosești, inclusiv decompilatoarele IDA Pro / Hex-Rays, Hopper și JEB, în condițiile licențelor aplicabile. REA nu îți acordă nicio licență, cheie sau drept de activare pentru aceste unelte. Versiunile de evaluare și demonstrative rămân supuse condițiilor furnizorilor, inclusiv restricțiilor privind utilizatorii, funcționalitățile, automatizarea și partajarea rezultatelor. Nu sunt autorizate copiile piratate, cheile furate, partajarea neautorizată a cheilor sau ocolirea restricțiilor de licențiere. Aceste îndrumări nu modifică licența MIT sau licențele terților.