22f28644fe
* feat(artifacts): inventory and extract Deno compile executables Adds Deno standalone artifact support for Mach-O, ELF, and PE carriers, exposing virtual files, entry points, recorded options, and file digests without running the executable. Extraction uses the existing safe output tree, preserves symlink targets as metadata, and assigns indexed paths to unsafe or oversized names. Environment-file values and certificate bytes remain in local Evidence; npm snapshots are reported by length without decoding. The documentation describes supported layouts, parsing limits, and refusal behavior. * fix(artifacts): resolve nested Intel Deno carriers to the enclosing app The backward trailer search stopped at the first confirmed sentinel, so an Intel app storing another Intel Deno executable as a virtual file reported the inner app. Search to the slice start, drop sentinels inside a confirmed payload, and fail closed on side-by-side trailers that differ. Correct the docs on retained environment values and generated regions. * fix(artifacts): keep Deno coverage, remote paths and PE resources truthful Report unknown coverage when the virtual filesystem cannot be listed, keep resolved specifiers when another remote ID is missing, and percent-encode characters in remote paths that a Windows destination would refuse. Reject a directory at the PE resource language level, and correct the guide's description of colliding generated regions. * fix(artifacts): normalize Deno remote escapes so hex case cannot collide Uppercase every percent escape in a generated remote path, so specifiers that differ only in escape case reach the path registry as one name and the second gets an indexed path instead of colliding on a case-insensitive disk. * fix(artifacts): fail closed on truncated enclosing Deno trailers and encode reserved remote path characters The Intel trailer scan rejected an overlong sentinel before reading its marker, so a truncated enclosing app vanished and the nested app was reported. Read the marker first and fail closed when a confirmed overlong trailer encloses another trailer. encodeURIComponent leaves `*` alone and the sanitizer covered only part of the Windows reserved set. remoteDestination now encodes the whole set once as uppercase percent hex; source_path keeps the original. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01KuWHGvzJkrhCqjtEHUwqyH * fix(artifacts): defer truncated Intel Deno trailer failure until enclosing trailers resolve A damaged Intel asset stored before a valid one inside a valid app made the backward trailer search fail before it reached the outer trailer. Hold that failure until the search ends and drop it when a confirmed enclosing trailer holds the sentinel as data. * fix(pe): fail closed when a resource type branch is unreadable beside a found name namedResourceTargets skipped a type branch whose names directory, or a name entry whose string, could not be read. A duplicate RT_RCDATA entry pointing out of bounds therefore vanished once another branch matched, and locatePeResourcePayloads returned only the readable ranges while parsePeResources rejected the same tree. The walk now records unresolved branches. hasPeResourceName still reports false for a tree that never reaches the name, but once locatePeResourcePayloads finds the name it raises a format failure if any branch was left unresolved. * fix(artifacts): skip Intel Deno sentinels that a native segment maps A non-Deno x86_64 Mach-O that stores an Intel Deno executable in __DATA had the asset's trailer promoted to the root application, because the backward sentinel search never checked who owned the bytes it scanned. locateMachOSlice now records the file ranges of every segment other than __SUI and __LINKEDIT (libsui extends __LINKEDIT over the trailer), and the Intel search skips any sentinel inside one of them. A slice whose load commands do not frame stays with native inventory, since ownership cannot be shown there. * fix(artifacts): reject a universal Deno image with an unreadable sibling slice The universal Mach-O locator skipped any slice whose load commands could not be read or framed, and any slice with a FAT range issue. When another slice confirmed Deno, that slice was reported as the whole image, so a sibling declaring a different Deno application went unexamined. locateMachOSlice now reports why part of a slice was not examined (unreadable or unframed load commands, a truncated slice, or the Intel sentinel allowance). locateMachO collects those reasons for every declared and hidden slice and fails closed once any slice confirms a Deno section. With none confirmed, the image stays with native inventory as before. * fix(scripts): supervise the Deno verifier version check Run `deno --version` through the verifier command owner with a deadline instead of raw execFile, and close the owner when the version is refused. * fix(artifacts): keep unconfirmed Deno carriers native and fail truncated Intel trailers An ELF SUI note whose descriptor is too short for the full d3n0l4nd name now stays unconfirmed instead of failing closed; failures after the name matches still fail closed. Every marker-confirmed Intel trailer whose payload runs past the slice is now kept until the backward search ends and fails unless an enclosing payload contains it, so an Intel Deno app missing its last byte reports a Deno failure instead of native inventory. The Deno MCP boundary test now calls open_binary and inspect_artifact through artifactMcpCall, as docs/testing.md requires. * test(deno): drop source-text checks from verifier pin test Keep the wrong-version subprocess check, which covers the pinned release through behavior, and stop asserting on the verifier script's source spelling. * test(deno): close readers in finally in symlink and cancellation tests A failed assertion or read error in either test skipped reader.close(), leaving the file open while temp-directory cleanup ran. Both tests now close the reader in finally, as CONTRIBUTING.md requires. The closed-reader assertion in the symlink test stays after the finally. * docs(specs): add deno-standalone spec, plan and tasks Add docs/specs/artifacts/deno-standalone/ with spec.md, plan.md and tasks.md for the Deno compile executable reader, as AGENTS.md requires for a feature, and list them in the specifications index. * docs: list the Deno compile guide in the documentation sidebar * fix(deno): confirm the d3n0l4nd section before claiming Mach-O damage A __SUI segment alone no longer makes later load-command damage Deno's. A Mach-O whose __SUI segment holds only a differently named section now stays absent and keeps native inventory, while damage seen before or beside a confirmed d3n0l4nd section still fails closed. * fix(deno): keep a slice with an unparsed segment command unread A Mach-O segment command that frames but cannot be parsed may be the __SUI segment, so the slice is no longer treated as fully examined. A universal image whose other slice confirms Deno now fails closed instead of letting that sibling supply the whole inventory, and with no confirmed sibling the image still keeps native inventory. * fix(deno): confirm an ELF SUI note before rejecting its length A SUI note whose descsz runs past its note table was recorded as plain damage before its descriptor name was read, so a malformed Deno carrier fell back to native inventory. The owner and the d3n0l4nd name prefix are now read within the table apart from the claimed extent, and a confirmed note with an oversized extent fails closed. * fix(deno): confirm a truncated __SUI section record by its name A section record cut short after its 16-byte name was skipped, so a damaged Deno carrier fell back to native inventory. The name is now read apart from the rest of the record, and a truncated record that names d3n0l4nd fails closed. The range checks for a confirmed record move into their own helper. * fix(deno): reject nonzero bytes after the last ELF note When fewer than 12 bytes remained in a note table after its last note, the walk stopped without looking at them, so a Deno note was selected with complete coverage beside unaccounted data. The remainder is now read: zero padding is accepted, and nonzero bytes are recorded as damage, which fails closed once a SUI note is confirmed and otherwise leaves the ELF to native inventory, matching the native note parser. * fix(deno): validate FAT slice identity before choosing the search The locator took a universal slice's CPU type from its FAT row, so a row that called an x86_64 slice arm64 skipped that slice's Intel trailer and let the arm64 payload stand for the whole image. Each slice's header is now checked against its row with validateFatSliceIdentity. A mismatch leaves the slice unread, so a universal image whose other slice confirms Deno fails closed. The Intel fixture header now states CPU_SUBTYPE_X86_64_ALL so its FAT rows can match it exactly. * fix(deno): check the Intel trailer marker before judging its length A trailer length word of 2^53 or more was dropped before its d3n0l4nd marker was read, so an enclosing app with that length was skipped and a nested app's range stood for the whole image. The marker is now read first, and a marker-confirmed trailer whose length runs past the slice, safe or not, joins the deferred truncated candidates and fails closed unless an enclosing trailer holds it as data. * fix(deno): count short ELF note tables against the note allowance A note table shorter than one note header made a read of its trailing bytes but counted no note, so many distinct tiny tables could force one sequential read each past the 256-note allowance. Every nonempty table now counts at least one entry, both in the up-front estimate and while scanning, so an image past the allowance records the limit instead of reading every table. The trailing-byte check moves into its own helper. * fix(deno): fail closed on ELF extended section numbering beside a SUI note A zero e_shnum with a nonzero e_shoff moves the section count into section zero, so the section table was skipped and its SHT_NOTE tables were never compared. Record it as damage, as PN_XNUM already is, so a confirmed SUI note fails closed instead of reporting full coverage. * fix(deno): keep undersized Intel trailers until enclosing ownership is known A trailer length word below 8 was dropped before its d3n0l4nd marker was read, so an enclosing app with a length of 0 to 7 was skipped and a nested app's trailer was selected as the root. The marker is now read first, and a marker-confirmed trailer too short to hold it is kept as malformed and fails closed unless an enclosing trailer holds it as data. * fix(pe): treat non-directory RT_RCDATA branches as unresolved A duplicate typeId root entry whose target is a data entry was skipped without marking the walk unresolved, so locatePeResourcePayloads returned the readable named resource as complete. Route non-directory type branches through the same unresolved path as unreadable names directories so the Deno reader fails closed. * fix(deno): fail closed on a zero-fill d3n0l4nd Mach-O section denoSectionRange admitted the declared offset and size of a confirmed __SUI,d3n0l4nd record without checking its section type, so a S_ZEROFILL, S_GB_ZEROFILL or S_THREAD_LOCAL_ZEROFILL section could be read as a file payload while MachoImage reports it as not file backed. Reject zero-fill types with the shared isMachoZeroFillSection predicate before assigning a physical range. * fix(deno): bound the d3n0l4nd Mach-O section by its segment file extent denoSectionRange checked a confirmed __SUI,d3n0l4nd record only against the slice and file bounds, so a section reaching past its segment's fileoff/filesize was still read as a complete payload while MachoImage reports the same section as not file backed. Reject a section outside its enclosing segment's file extent before admitting the physical range. * style(deno): apply oxfmt to the DenoStandaloneLocation embedding union * fix(artifacts): preserve Deno carrier ownership * fix(artifacts): admit Deno parent segments * fix(deno): preserve native segment ownership * test(deno): cover mismatched Mach-O segment widths --------- Co-authored-by: Matt Van Horn <455140+mvanhorn@users.noreply.github.com> Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com> Co-authored-by: morluto <76467478+morluto@users.noreply.github.com>
44 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: Реверс-інжиніринг будь-чого
Один MCP для реверс-інжинірингу бінарних файлів, застосунків і поведінки під час виконання.
Побачили цікаву функцію? Зрозумійте, як вона працює, аж до рівня двійкового коду.
Швидкий старт · Як працює REA · Що можна аналізувати · Приклади · Створення RL-середовищ · Поширені запитання · Документація
npx rea-agents setup
Important
Офіційні джерела REA: morluto/rea, rea.tools, rea-agents (npm). Користуйтеся посиланнями на встановлення та випуски з цих офіційних джерел. Схожа назва репозиторію або скопійований README не підтверджують, що завантажуваний файл є офіційним.
Побачили в застосунку функцію, яку хочете додати до свого продукту? Попросіть агента дослідити її за допомогою REA. Він може перевірити застосунок без вихідного коду, пояснити роботу функції, показати підтвердження та створити реалізацію для вашого проєкту.
REA підключає вашого агента до інструментів дослідження нативних бінарних файлів, застосунків JavaScript і Electron, збірок .NET та сайтів. Ті самі інструменти можна використовувати з термінала. Аналіз виконується локально, а результати містять підтвердження й обмеження, на яких ґрунтується кожен висновок.
Налаштування реєструє REA в агенті та встановлює відповідні інструкції. Нативний аналіз використовує наявний Hopper, Ghidra, IDA або Kuna; Hopper можна встановити після схвалення. Статичний аналіз JavaScript не потребує нативного рушія.
Відвідайте сайт REA, щоб знайти інструкції налаштування, ілюстровані посібники та реальні дослідження.
Швидкий старт
У Linux для запуску Ghidra, JADX та інструментів прошивок, а також статичного аналізу JavaScript/Electron потрібен сумісний із procps ps у PATH REA для перевірки володіння процесами. Див. передумову для Linux.
Налаштуйте агента
Якщо Node.js і npm встановлено, виконайте:
npx rea-agents setup
Виберіть агентів, перевірте запропоновані зміни та схваліть їх. Налаштування додає MCP-сервер REA та відповідні інструкції робочих процесів, створюючи резервні копії наявної конфігурації. Після цього перезапустіть агента.
Налаштування підтримує Claude Code, Codex, Cursor, Gemini CLI, Grok Build та інших агентів. Конфігурацію провайдерів і ручну реєстрацію MCP описано в розділі встановлення й налаштування.
MCP типово використовує компактні вхідні схеми. Для повного опису полів і вкладеної перевірки задайте REA_MCP_INPUT_SCHEMA_PROFILE=full у реєстрації MCP. Обидва профілі зберігають усі інструменти й однакову канонічну перевірку сервера; див. посібник контрактів MCP.
Запитайте агента
Досліди, як працює пошук у застосунку Notes, покажи підтвердження й створи подібну функцію для мого проєкту.
Замініть Notes цільовим застосунком і вкажіть функцію, яку хочете зрозуміти.
Використовуйте термінал
Перевірте розпакований каталог застосунку JavaScript/Electron або файл ASAR:
npx -y rea-agents@latest analyze-javascript-application /absolute/path/to/app --json
Результат містить модулі, імпорти, межі Electron і підтвердження для них. Замініть шлях своїм, наприклад "D:/apps/example" у Windows.
Для регулярного використання встановіть команду rea:
npm install --global rea-agents
rea --help
Для нативного аналізу спочатку налаштуйте провайдера. Нативні команди, вибір провайдера, знімки та використання у скриптах описує посібник CLI та Evidence.
Оновіть REA
REA швидко розвивається, а нові випуски часто містять виправлення помилок. Підтримуйте встановлену версію актуальною.
Для CLI, встановленого через npm install --global / bun add --global:
rea update
rea --update — псевдонім rea update із тими самими глобальними параметрами виводу. Оновлення зберігає сумарно до 4 MiB stdout/stderr. Завеликі метадані відхиляються після завершення; докладне встановлення зберігає обмежену діагностику. Прогрес враховує зворотний тиск термінала й чекає завершення переданих записів.
Глобальні оновлення Bun потребують Bun 1.2.17 або новішого. Перед rea update вручну оновіть старішу версію Bun.
Щоб оновити реєстрації агентів і skill, виконайте команду налаштування, яку виведе оновлення.
Якщо використовуєте npx, оновіть налаштування агента командою:
npx rea-agents@latest setup
Перевірте зміни налаштувань і перезапустіть агента. Для разових команд CLI використовуйте npx rea-agents@latest, а потім потрібну команду.
З Bun використовуйте bunx rea-agents@latest замість npx rea-agents@latest.
Як працює REA
Агент викликає REA через MCP, щоб перевірити ціль і простежити пов'язаний код. REA повертає знахідки разом із підтвердженнями. Агент використовує їх для уточнювальних запитань, пояснення поведінки або написання й тестування реалізації. Команди CLI використовують ті самі робочі процеси.
Відкрити зображення в повному розмірі.
Що можна аналізувати
REA потребує Node.js 22.x (>=22.23.4), 24.x (>=24.22.1) або 26+ (>=26.12.1), а також npm. Додаткові інструменти й підтримувані системи залежать від цілі:
| Ціль | Що повертає REA | Вимоги й посібник |
|---|---|---|
| Нативні бінарні файли | Псевдокод, асемблерний код, рядки, символи, виклики й посилання | Hopper, Ghidra, IDA або Kuna; нативний аналіз |
| Структура ELF без запуску | Секції, сегменти, початкові символи/релокації та можливі захисні механізми за даними статичного аналізу | pwntools, наданий стороною, що викликає інструмент, у Linux x64; діагностика бінарних файлів |
| 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 |
| Байт-код EVM | Селектори диспетчеризації, зміщення байтів, виведені припущення про аргументи та змінюваність стану | Локальні необроблені байти або шістнадцяткове представлення у Linux x64; посібник EVM без запуску |
| 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 |
| Записані аварійні завершення в Linux | Необроблені записи note, регістри/сигнали кожного записаного потоку й необов'язкові кандидати зіставлення пам'яті | pwntools, наданий стороною, що викликає інструмент, у Linux x64; необов'язкові GDB/pwndbg; записані аварійні завершення |
| Встановлені настільні програми | Можливі середовища виконання, файли доказів, компоненти та наступні кроки | Обмежена перевірка каталогів і заголовків；Настільні програми |
| JavaScript / Electron | Модулі, імпорти, карти вихідного коду, маршрути, IPC і зв'язки з нативними доповненнями | Node.js і npm; аналіз застосунків; Linux: procps ps |
| Сайти | Структура сторінки, скрипти, мережеві спостереження й запитані знімки екрана | Браузер сімейства Chrome; аналіз браузера |
| Збережені мережеві захоплення | Запити, відповіді, доступні корисні дані та місця в джерелі | HAR / Fiddler Everywhere SAZ; mitmdump у Linux для захоплень у власному форматі mitmproxy; посібник мережевих захоплень |
| Захоплення пакетів | Кінцеві точки, DNS, TLS SNI, розподіл протоколів та HTTP-запити | Надані викликаючою стороною tshark та capinfos; підручник pcap |
| Збірки .NET | Метадані, інструкції CIL, оголошені нативні залежності й порівняння збірок | Статична перевірка; посібник керованого коду |
| PyInstaller | CArchive, PYZ, Python bytecode | Static inspection; Python packaged applications |
| Deno compile binaries | Virtual files, entry point, recorded options, npm snapshot length | Static inspection; Deno compile executables |
| Android APK | Оголошення маніфесту, класи, декомпільовані методи й посилання | JADX без графічного інтерфейсу й повний JDK у Linux/macOS/Windows x64; посібник Android |
| Пристрої Android | Пристрої, пакети, процеси, журнали, дампи, знімки екрана та передавання APK/файлів | adb, наданий викликаючою стороною (емулятор або пристрій); підручник ADB |
| Проєкти JEB | Єдиниці проєкту від рушія, дайджести артефактів і псевдокод типів/методів | Запущений викликаною стороною клієнт JEB з MCP, обирається через REA_JEB_MCP_URL; посібник JEB |
| Ресурси Android | Декодований маніфест, таблиці рядків, мови та відомості про версію | Засіб запуску Apktool, наданий викликаючою стороною; підручник ресурсів |
| Додатки Flutter | Хеш знімка Dart, дайджести бібліотек за ABI та походження збірки рушія | Не потрібні (статичний розбір APK); підручник Flutter |
| Прошивки | Області, результати видобування й передавання до нативного аналізу | Binwalk / Unblob у Linux; посібник прошивок |
| Записані пакети | Вибрані поля, повторювані значення, фільтри та правила декодування | Linux: TShark 4.x + prlimit; посібник із записів пакетів |
| Записані логічні сигнали | Анотації декодера, діапазони відліків і діагностика | Linux: sigrok-cli 0.7.2 + prlimit; посібник із сигналів |
| Пакети й ресурси | Переліки файлів, хеші, plist, структура пакетів Apple та видобуті ресурси | Посібник артефактів і JavaScript, застосунки Apple |
| Поведінка процесів | Вивід термінала, взаємодії, спостереження за завершенням і файловою системою та порівняння запусків | Linux/macOS із нативним PTY; захоплення процесів |
| Бінарні файли Go | Вбудована версія компілятора, модулі, заміни та налаштування збірки | Вбудований статичний аналіз ELF/PE/thin Mach-O; Встановлювати Go не потрібно |
| Бази SQLite | Таблиці, стовпці, індекси, подання, тригери та вибрані рядки звичайних таблиць | Локальний знімок БД/WAL; Node.js 24.x >=24.15 або 26+ із нативними обмеженнями SQLite |
| Об’єкти коду GPU | Цілі CUDA/HIP, параметри й ресурси вибраних ядер, збережений текст PTX | Вбудований статичний аналіз ELF/PE/fatbin/CUBIN/PTX; GPU |
| Файли моделей | Метадані GGUF / safetensors, оголошення тензорів і обчислені підсумки | Перевірка заголовків; повний хеш файлу за вибором; GGUF / safetensors |
| Метадані IL2CPP | Образи збірок Unity global-metadata.dat, імена типів/методів та діапазони індексів | Статичне декодування версій 24, 27, 29, 31, 39; Unity не потрібен |
| Godot PCK | Інвентар і видобування, оригінальні заголовки/каталоги та ідентичність вибраного вмісту | Статичні формати 2, 3, 4; Godot не потрібен |
| Артефакти WASM | Валідація, секції, точні WAT-форми імпорту/експорту та декодований WAT | Надає користувач WABT 1.0.42; inspect_wasm_artifact |
| Підписи APK | Підписувачі v1/v2/v3/v3.1, відбитки сертифікатів, ротація ключів і внутрішня узгодженість хешів | Вбудований статичний аналіз; inspect_apk_signature |
Статична перевірка JavaScript і .NET читає надані файли, не запускаючи застосунок. Захоплення під час виконання запускає вибрану ціль або взаємодіє з нею з правами вашого користувача; відповідні посібники описують його вплив.
Для автономного аналізу нативних бінарних файлів REA також підтримує GNU objdump і Rizin, які користувач надає самостійно. Посібник з інструментів зворотної розробки описує налаштування провайдерів, команди CLI та обмеження Evidence. REA не встановлює й не оновлює жодного з цих провайдерів.
Для великих файлів збільште час запуску через REA_GHIDRA_STARTUP_TIMEOUT_MS або REA_HOPPER_STARTUP_TIMEOUT_MS.
Нативні формати й підтримка систем відрізняються залежно від провайдера. Дивіться налаштування Hopper і Ghidra, посібник IDA, Kuna та експериментальну підтримку Ghidra у Windows. Ghidra також підтримує аналіз 16-бітного DOS. Для вибору провайдера дивіться посібник CLI. Для функцій, доданих після найновішої версії в npm, перевірте доступність у випусках.
Приклади
DX-Ball: відновлення розрахунку звукової панорами
Простежте звуковий виклик до допоміжної функції, що перетворює координату на панорамування, перевірте інструкції та перетворіть неповний псевдокод на C. Відновлена реалізація проходить 3 205 тестів з оригінальним x86-кодом і відтворює всі 63 байти скомпільованої функції.
Прочитати дослідження · Репозиторій реконструкції
Notion: відстеження мосту буфера обміну Electron
Знайдіть API буфера обміну в процесі рендерингу, простежте його через preload та IPC до головного процесу й перевірте формат буфера обміну з даними форматування.
TH04: відновлення розрахунку кільця куль у DOS
Перевірте 16-бітні інструкції оригінальної гри для PC-98, відновіть розрахунки фіксованих і прицільних кутів та порівняйте відновлений C++ із виводом тогочасного компілятора.
Прочитати дослідження · Репозиторій реконструкції
Створюйте RL-середовища з REA
Запишіть сеанс вебзастосунку, перетворіть його API на інструменти й експортуйте середовище для ШІ-агента. Запустіть його з AgentEnv, а потім додайте завдання та перевірки винагород для RL-навчання або оцінювання.
Посібник зі створення середовища · Дивитися демо в X
Якщо ви дослідили з REA щось цікаве, поділіться результатом. Створіть issue або pull request і вкажіть ціль, ваше запитання, як допоміг REA та що ви з'ясували.
Створення RL-середовищ
Створіть локальне середовище, де ШІ-агент може тренуватися виконувати завдання, як-от пошук issue або створення папки, без запуску початкового застосунку. Використовуйте його для навчання з підкріпленням (RL) або перевірки того, як агент виконує завдання.
REA перетворює записані API-запити й відповіді на інструменти, які може викликати агент. Середовище використовує записані дані й підтримує зміни лише тоді, коли запис підтверджує їхні ефекти.
Налаштуйте REA у своєму агенті та замініть URL і завдання з папками на власні:
За допомогою REA створи RL-середовище з мого тестового вебзастосунку:
http://127.0.0.1:3000
Охопи перегляд списку папок, створення, перейменування й видалення.
Можна створювати й видаляти тестові папки. Наявні дані не змінюй.
Збережи в папку my-env, перевір доступні операції та поясни, як запустити середовище.
Використати командний рядок
Ці команди підходять, якщо у вас уже є файл із записаними запитами й відповідями застосунку в браузері. Для запуску результату також потрібні AgentEnv і Docker.
rea environment-build ./session.har ./my-env --name my-env --json
agent-env run ./my-env
REA експортує готове до запуску середовище з базовим тестом запуску й відповідей. Підключіть його до свого RL-фреймворку, щоб задати цілі, додати перевірки винагород і запустити навчання.
Посібник зі створення середовища · Довідник середовищ · Дивитися демо в X
Поширені запитання
Які агенти можуть використовувати REA?
Будь-який агент, що підтримує локальні MCP-сервери. Налаштування конфігурує підтримуваних агентів; інші клієнти можуть використати ручну реєстрацію MCP.
Чи потрібні мені Hopper, Ghidra, IDA або Kuna?
Поглиблений нативний аналіз використовує один із цих інструментів. Статична перевірка JavaScript і .NET працює без рушія нативного аналізу. Налаштування може встановити Hopper після схвалення; Ghidra, IDA й Kuna використовують наявні встановлення. Дивіться налаштування провайдерів.
Чи потрібно спочатку запускати Hopper?
REA запускає Hopper, коли він потрібен для операції. У macOS під час першого запуску може з'явитися діалог вибору деморежиму або активації ліцензії. Дивіться запуск Hopper та усунення неполадок.
Що дає встановлення skill із skills.sh?
Skill надає агенту інструкції дослідження. Використовуйте npx rea-agents setup, щоб зареєструвати MCP-сервер REA та встановити відповідні інструкції, а потім перезапустіть агента. Дивіться встановлення лише skill.
Який код повертає REA?
Нативний аналіз повертає псевдокод і асемблерний код. Аналіз JavaScript/Electron відновлює модулі та їхні зв'язки. Агент використовує ці результати, щоб написати й протестувати реалізацію; приклади містять практичні дослідження.
Чи завантажує REA мій застосунок на сервер?
REA аналізує цілі локально. Ваш агент отримує результати інструментів, а постачальник його моделі має власну політику даних.
Що робити, якщо я зіткнувся з помилкою?
Спочатку оновіться: нещодавній випуск уже міг виправити помилку.
Для CLI, встановленого через npm:
rea update
Для налаштування агента через npx:
npx rea-agents@latest setup
Якщо використовуєте агента, завершіть оновлення налаштувань і перезапустіть його. Повторіть те саме завдання. Якщо проблема залишається, відкрийте issue із версією REA, типом цілі, кроками відтворення та виводом помилки.
Документація
Почніть із практичних посібників на сайті. Точні параметри, передумови й контракти результатів описано тут:
- Встановлення й налаштування: реєстрація агентів, конфігурація провайдерів, оновлення та видалення.
- Готовність та усунення неполадок: діагностика конкретного агента або рушія аналізу.
- CLI та Evidence: команди, вибір провайдера, знімки, імпорт/експорт і статуси завершення.
- Контракти MCP і промпти агентів: результати інструментів, сеанси й керовані дослідження.
- Каталог інструментів: створюваний під час збірки перелік інструментів, провайдерів і команд CLI.
- План розвитку: заплановані роботи й відстеження можливостей.
Повідомляйте про вразливості згідно з SECURITY.md.
Історія зірок
🎉 400 000 зірок на GitHub — дякуємо!
Дякуємо всім, хто використовує REA, повідомляє про помилки, пропонує нові функції, тестує збірки й допомагає з виправленнями.
Відмова від відповідальності
Рекомендації щодо відповідального використання наведено в DISCLAIMER.md.
REA призначений для законних досліджень, навчання, забезпечення сумісності, збереження програмного забезпечення й аналізу програм, якими ви володієте або які маєте дозвіл досліджувати.
The project's position on illegal or unauthorized use covers all REA versions, distribution channels, and platforms; each copy retains its applicable licenses.
Участь у проєкті
Будемо раді вашій допомозі з REA! Відкрийте issue, щоб повідомити про помилку чи запропонувати функцію, або надішліть pull request з поліпшеннями коду чи документації.
Налаштування середовища розробки й перевірки описано в CONTRIBUTING.md, шляхи верифікації — у посібнику тестування, а структуру проєкту — на схемі архітектури.
Ліцензія
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.