English · 简体中文 · 日本語 · 한국어 · العربية

REA: Обратная разработка чего угодно

Обратная разработка чего угодно с помощью агентов: от поведения приложений до нативных бинарных файлов.

Видите интересную функцию. Поймите, как она работает, вплоть до бинарного уровня.

Быстрый старт · Текущий статус · Модель исследования · Каталог инструментов · Дорожная карта · Как это работает

npm install --global rea-agents && rea setup

---

Видите функцию в приложении, которую хотите добавить в свой продукт? Передайте приложение своему агенту — даже без исходного кода. С помощью REA агент может исследовать функцию, объяснить, как она работает, показать доказательства и создать версию, адаптированную под ваш стек и требования.

REA предоставляет агентам единый согласованный способ исследования программного обеспечения. Сегодня это включает глубокий нативный анализ и досье на функции через Hopper или собственную версию Ghidra на Linux, а также экспериментальную Windows x64 Ghidra P0 для одобренных нативных PE-приложений; триаж управляемых PE/CLI без выполнения; воспроизводимые записи Evidence v2; контролируемый захват процессов; пассивное наблюдение за сайтами, страницами Electron и V8 Inspector для Node/Electron; ограниченную реконструкцию JavaScript и source-map; а также версионированный граф доменов для связи слоёв JavaScript-приложений без смешения статического анализа с наблюдением времени выполнения. Долгосрочный инструментарий расширяет тот же агентский рабочий процесс на API, протоколы, мобильные артефакты, прошивки, более богатое поведение времени выполнения и различия между версиями.

Обратная разработка обычно заставляет оператора выбирать инструмент, изучать его API, переносить доказательства между программами и решать, что исследовать дальше. REA передаёт эту работу агенту через команды, навыки, структурированные результаты и повторяемые рабочие процессы исследования.

Просто спросите своего агента

Запустите настройку один раз. Интеграция с агентом устанавливает согласованную регистрацию MCP и встроенный навык маршрутизации вместе:

npx rea-agents setup

Затем спросите:

Understand how search works in the Notes app, show me the evidence, and build a
similar feature for my project.

Notes — лишь пример. Назовите любое приложение, которое хотите понять, или попросите агента начать с обзора.

Модель исследования

Декомпиляция Откройте приложение и восстановите читаемый код, строки, имена и другие подсказки о том, как оно работает.

Понимание Следуйте за кодом от одной части приложения к другой, пока агент не сможет объяснить, как функция на самом деле работает.

Воссоздание Превратите полученные агентом знания в функцию для вашего собственного продукта, адаптированную под ваш стек, интерфейс и требования.

REA показывает, как он пришёл к своим выводам. Он не утверждает, что восстанавливает исходный код или автоматически клонирует приложение.

Почему REA

Создан для агентов	Спросите, что делает приложение, и позвольте вашему агенту исследовать его, вместо того чтобы гадать.
CLI и MCP	Запускайте те же возможности обратной разработки из терминала или агента.
Сложность — на нас	REA устанавливает и управляет инструментами обратной разработки за кулисами.
От выводов к коду	Поймите функцию, затем создайте собственную версию в той же сессии кодирования.
Локально по дизайну	Анализ выполняется на вашем поддерживаемом локальном хосте. REA не загружает приложение в облачный сервис анализа.
Сохраняет контекст	Исследуйте несколько приложений, не начиная заново для каждого вопроса.

Быстрый старт

Запуск настройки — рекомендуется

npx --yes rea-agents@latest setup

Подсказка npm-пакета-запуска, когда она отображается, разрешает загрузку REA для данного вызова; она не разрешает никаких изменений в настройке. Мастер REA отдельно показывает свой полный план и спрашивает перед его применением. Настройка не обновляет Homebrew, Node.js или npm. Команда настройки начинается с описания работы, которую она включает: исследование локальных приложений из агента, восстановление доказательств через провайдера глубокого анализа и повторное использование управляемого рабочего процесса REA. Она суммирует обнаруженных агентов, затем спрашивает, какие возможности настроить: интеграцию с агентом (MCP плюс соответствующий управляемый рабочий процесс) и — при необходимости — провайдера Hopper. Ничего не выбрано по умолчанию. Выбор интеграции с агентом открывает второй пустой список для конкретных обнаруженных агентов, которые должны получить регистрацию.

@latest делает запрошенный релиз явным и запрашивает у npm релиз, опубликованный в данный момент под этим тегом. REA не заменяет молча версию пакета, выбранную npm. Преднамеренные откаты поэтому остаются доступными через точный запрос пакета.

REA сохраняет процесс интерактивным, чтобы его история оставалась в терминале. Выбор возможности не выбирает каждую обнаруженную цель и не авторизует изменение. Перед любыми изменениями REA проверяет существующую конфигурацию, выводит точные пути и внешние эффекты и запрашивает окончательное подтверждение с Нет в качестве значения по умолчанию. Экран держит доступные клавиши видимыми, пока вы выбираете; Ctrl-C и отказ оставляют систему неизменной.

REA обнаруживает Claude Code, Claude Desktop, Codex, Cursor, Gemini CLI, Windsurf и Devin. Он настраивает первые шесть при обнаружении; Devin сообщается, но оставляется без изменений, поскольку у него нет документированной локальной границы конфигурации MCP. Регистрации аддитивны, сначала создают резервные копии и считываются обратно после записи. Вы можете безопасно повторно запустить настройку.

Используйте rea setup --dry-run для просмотра плана, повторяйте --client для выбора точных агентов и --accessible для последовательных вертикальных подсказок. Машинный вывод остается доступным через --json; интерфейс подсказок и прогресс идут в stderr.

После успешной настройки REA сообщает о возможностях, готовых к использованию, и о конкретном следующем шаге, например, о перезапуске настроенного агента перед тем, как попросить его исследовать приложение. Он не заявляет, что интеграция или провайдер готовы, если только настройка и ее финальная диагностическая проверка не подтвердили это.

Необязательная оболочка curl устанавливает тот же пакет CLI и запускает настройку только при наличии терминала:

curl -fsSL https://raw.githubusercontent.com/morluto/rea/main/install.sh | bash

Передавайте параметры установщика после bash -s --, например --dry-run, --no-setup или --version 1.0.0. Оболочка curl никогда сама не устанавливает prerequisites и не настраивает интеграции. Смотрите Установка и настройка для точной границы изменений.

С агентом — рекомендуется

npx --yes rea-agents@latest setup

Выберите «Интеграция с агентом» в проверенном плане настройки. REA устанавливает закрепленную регистрацию MCP и соответствующий навык маршрутизации как одну транзакцию. После настройки перезапустите настроенный агент, чтобы он загрузил согласованную интеграцию.

Просмотрите план настройки, одобрите его, если это уместно, затем опишите приложение или функцию, которую вы хотите понять. Hopper может работать в бесплатном демонстрационном режиме; если он показывает подсказку первого запуска, выберите демо или введите существующую лицензию.

Из терминала — без установки

npx --yes rea-agents@latest setup
npx -y rea-agents@latest doctor
npx -y rea-agents@latest analyze /Applications/Notes.app

Просмотрите план настройки перед его подтверждением. Перезапустите настроенный агент, чтобы он загрузил REA.

Из терминала — установите команду rea

npm install --global rea-agents
rea setup
rea doctor
rea analyze /Applications/Notes.app

Обновите эту глобальную установку на месте:

rea upgrade

REA проверяет npm на наличие последнего релиза и проверяет, что запущенный пакет является глобальной установкой, которую он заменит. Копии из исходников, локальные и npx сообщают ручную команду npm install --global rea-agents@latest вместо обновления несвязанного глобального пакета.

Выберите либо команды без установки, либо глобальную установку. Вам не нужны обе.

npm install rea-agents без --global устанавливает rea только в node_modules/.bin текущего проекта; он не добавляет rea в ваш PATH оболочки. Используйте команды npx выше для разовых запусков или --global, когда вам нужна видимая в оболочке команда rea.

Требования

• macOS 12 или новее
• Ubuntu 24.04+, Fedora 41+ или 64-битный Arch Linux
• Windows x64 для экспериментальной, только Ghidra-границы нативного PE P0
• Node.js 22.19+ или 24.11+ (включая более новые релизы)
• npm; REA не требует и не устанавливает конкретную версию npm Глубокие бинарные операции используют Hopper — отдельное настольное приложение с собственной лицензией — или выбранный вызывающим кодом провайдер Ghidra. Ghidra предоставляет инвентарь только для чтения, метаданные функций, декомпиляцию, ассемблерный код, разрешённые вызовы, типизированные ссылки, перекрёстные ссылки, CFG и досье функций; состояние графического интерфейса и мутации через этого провайдера недоступны. Настройка повторно использует существующую установку Hopper или установку Ghidra, предоставленную оператором. Она никогда не загружает Ghidra и не устанавливает Java. Если ни один из провайдеров не готов, интерактивная настройка предлагает Hopper; автоматическая установка Hopper требует rea setup --yes --install-hopper.

Если что-то не работает, выполните:

npx -y rea-agents@latest doctor

rea doctor --json работает только на чтение и различает неподдерживаемые хосты, отсутствующие зависимости, отсутствующий локальный движок анализа, расхождение конфигурации и исправные проверки. Активация платной лицензии необязательна: на Linux REA запускает поддерживаемую демонстрационную сборку Hopper на приватном дисплее Xvfb и выбирает предлагаемый Hopper демонстрационный режим для каждого сеанса анализа.

Установка и устранение неполадок на Linux

На macOS одобренная настройка загружает официальный DMG-файл Hopper, проверяет его и устанавливает приложение в ~/Applications без Homebrew и прав администратора. Hopper может показать запрос демо-режима или лицензии при первом открытии; ручное перетаскивание не требуется.

На Ubuntu 24.04+, Fedora 41+ и 64-битной Arch Linux одобренная настройка загружает закреплённый официальный пакет Hopper 6.4.2, ограничивает загрузки только публичным источником Hopper, проверяет опубликованный размер и контрольную сумму и вызывает apt-get, dnf или pacman для установки Hopper и пакетов Xvfb, Python, X11 и XTEST, используемых демонстрационными сеансами. Когда REA уже не запущен от root, pkexec показывает системный запрос авторизации. REA никогда не вызывает sudo. Демонстрационные сеансы запускаются на изолированном дисплее Xvfb 1280×1024. REA проверяет точный поддерживаемый бинарный файл Hopper, его собственную родительскую цепочку процессов, ожидаемую геометрию диалога и состояние моста перед выбором Try the Demo; любое несоответствие приводит к отказу.

Обычный лаунчер Linux — /opt/hopper/bin/Hopper. Если Hopper установлен в другом месте:

export HOPPER_LAUNCHER_PATH=/absolute/path/to/Hopper
rea doctor --json

Если doctor сообщает об отсутствующем движке анализа, хотя файл существует, проверьте разрешение общих библиотек с помощью:

ldd /opt/hopper/bin/Hopper | grep 'not found'

Установите недостающие пакеты дистрибутива и повторно запустите rea setup. Автоматизация демо-режима на Linux требует Xvfb, Python 3, libX11.so.6 и libXtst.so.6; одобренная настройка устанавливает эти прямые зависимости времени выполнения и не взаимодействует с дисплеем рабочего стола пользователя. Бесплатное демо Hopper поддерживает анализ с ограничениями, определёнными поставщиком, а платная лицензия необязательна. Установщик curl размещает команду rea в ~/.local/bin на Linux; добавьте этот каталог в будущие значения PATH оболочки, если его там ещё нет.

REA по умолчанию устанавливает HOPPER_LAUNCHER_PATH в /Applications/Hopper Disassembler.app/Contents/MacOS/hopper на macOS и /opt/hopper/bin/Hopper на Linux. Явная конфигурация всегда имеет приоритет.

Провайдер анализа Ghidra только для чтения

Адаптер Ghidra поддерживает точно официальный выпуск Ghidra 12.1.2 с 64-битным полным JDK 21 на Linux x64. Он также предоставляет экспериментальный Windows x64 P0, ограниченный одобренными нативными приложениями PE x86-64. Загрузите и распакуйте эти проекты самостоятельно, затем настройте абсолютные пути:

export GHIDRA_INSTALL_DIR=/absolute/path/to/ghidra_12.1.2_PUBLIC
export JAVA_HOME=/absolute/path/to/jdk-21 # optional when java and javac resolve from PATH
rea doctor --json
rea setup
rea providers --json

Doctor различает отсутствующую конфигурацию, неправильный корень установки, неверную версию Ghidra или Java, JRE без javac, отсутствующий support/analyzeHeadless и неподдерживаемую платформу или архитектуру. Одобренная настройка только копирует проверенные несекретные пути в обнаруженные регистрации MCP; она не изменяет установку Ghidra и не устанавливает/загружает Ghidra или Java.

На Windows задайте те же переменные в PowerShell и запустите rea doctor --json; автоматизированные rea setup и установка Hopper остаются недоступными. Граница цели P0 отклоняет DLL, управляемые PE-файлы, образы не-x86-64, изменяемые/враждебные входные данные и форматы, отличные от PE. См. руководство по операциям Windows Ghidra P0 для регистрации, точных ограничений, доказательств CI и критериев приёмки. REA загружает свой упакованный Java HeadlessScript с -scriptPath, копирует и проверяет контрольную сумму целевого объекта во временной среде выполнения, включает -readOnly и -deleteProject, ограничивает автоматический анализ 300 секундами с двумя ЦП и кучей Java 2 ГиБ, и аутентифицирует каждый запрос. Linux использует Unix-сокет с режимом 0600. Windows P0 использует IPv4 loopback с токен-аутентификацией и запись конечной точки без токена, потому что IPC на основе пути Node не подключается к Java AF_UNIX-сокетам в Windows. Мост проверяет SHA-256 импортированных байтов Ghidra перед обслуживанием любой операции.

Адаптер Ghidra объявляет 19 прямых и расширенных операций. Его десять инвентарных операций: list_documents, list_procedures, list_strings, list_names, list_segments, address_name, procedure_address, resolve_containing_procedure, search_procedures и search_strings. Он также допускает procedure_info, procedure_pseudo_code, procedure_assembly, read_function_instructions, procedure_callers, procedure_callees, procedure_references, xrefs и analyze_function. read_function_instructions — это быстрый путь с постраничной разбивкой по смещениям для окон сырых инструкций: он не вызывает декомпилятор и не использует инвентаризацию имен/строк всей программы, а также доступен как rea instructions. Эти возможности обеспечивают общие рабочие процессы инвентаризации Swift/Objective-C, binary_overview, batch_decompile, get_call_graph, find_xrefs_to_name, trace_feature и полные досье функций. Адреса в пространстве по умолчанию — шестнадцатеричные в нижнем регистре с префиксом 0x. Другие пространства, включая EXTERNAL, используют <процентно-закодированное-пространство>:0x<hex>. Результаты по символам идентифицируют первичные, динамические, внешние, типовые и исходные факты; процедуры различают внешние функции и заглушки; строки идентифицируют кодировку, состояние отсутствующего терминатора, длину в байтах и усечение значения; концы блоков памяти эксклюзивны, а разрешения берутся напрямую из Ghidra.

Мост обслуживает операции только после завершения автоматического анализа. Каждая Program владеет одним постоянным DecompInterface; ограниченная FIFO-очередь на 32 запроса сериализует доступ к API Ghidra, и каждая декомпиляция имеет собственный 30-секундный дедлайн. Результаты ссылок сохраняют факты Ghidra о вызовах/переходах/данных/чтении/записи/косвенных/вычисляемых/внешних ссылках, в то время как неразрешённые потоки без цели остаются явно неизвестными. Синтетические ссылки на точки входа без действующих источников памяти опускаются. Псевдокод и ассемблер — это наблюдения, зависящие от провайдера, а не исходный код или текст, эквивалентный Hopper. Таймаут анализа, ограничение безопасности сканирования или инвентаризации, таймаут запроса или чрезмерно большой ответ завершаются явной ошибкой, а не возвращают частичный результат, помеченный как полный.

npm run verify:ghidra компилирует принадлежащие исходному коду фикстуры x86-64 debug и stripped ELF, AArch64 ELF, x86-64 PE и x86-64 Mach-O. Против реальной Ghidra 12.1.2 он проверяет каждую допущенную операцию, прямые и косвенные вызовы, импорт/экспорт/заглушки, типизированные ссылки, строки/перекрёстные ссылки, много-блочный CFG, отмену, дедлайны, конкурентность, некорректные входные данные и полную очистку процесса/проекта. Устанавливайте REA_CC, REA_CLANG или REA_LLD_LINK только если соответствующая команда компилятора отсутствует в PATH.

npm run verify:ghidra:windows использует детерминированное нативное x86-64 PE-приложение, принадлежащее исходному коду, и требует все 19 операций, связь дайджестов цели/снимка/импорта, аутентифицированный транспорт loopback и очистку на контролируемом раннере Windows x64 Ghidra 12.1.2. Это доказательство не устанавливает владение Job Object, частные DACL или безопасность, связанную с reparse-point.

Чтобы удалить только регистрации MCP, принадлежащие REA, и управляемый навык:

rea uninstall
rea uninstall --purge-data # also removes only ~/.rea/cache and ~/.rea/state

Удаление сохраняет Hopper, Node.js, доказательства, захваты, внешние корни доказательств, несвязанные навыки и другие MCP-серверы. Оно отказывается от некорректной клиентской конфигурации и никогда не следует по символическим ссылкам purge-data.

CLI или агент?

Если вы хотите…	Используйте
Попросить агента исследовать приложение и создать функцию	Установите навык, затем поговорите со своим агентом
Проверить или декомпилировать часть приложения из Терминала	rea analyze или rea decompile
Проверить, канонизировать или сравнить пакеты Evidence v2	rea evidence-import, rea evidence-export или rea compare
Запустить или возобновить постоянный анализ артефактов двух версий	rea investigate-versions
Картировать локальное JavaScript/Electron-приложение без его выполнения	rea analyze PATH --approved или rea analyze-javascript-application
Повторно использовать неизменяемые результаты анализа без перезапуска провайдера	Передайте --snapshot /approved/path/analysis.json команде глубокого анализа
Импортировать исходный код как исторический справочник	rea import-reference-source
Захватить или сравнить контролируемое поведение процесса	rea capture-process или rea compare-process-captures
Команды получения доказательств из файловой системы и файловые инструменты MCP отключены до тех пор, пока оператор не одобрит абсолютные корневые пути:

export REA_EVIDENCE_ROOTS_JSON='["/absolute/path/to/evidence"]'
export REA_INVESTIGATION_INPUT_ROOTS_JSON='["/absolute/path/to/releases"]'
rea evidence-import /absolute/path/to/evidence/bundle.json
rea evidence-export /absolute/path/to/evidence/bundle.json /absolute/path/to/evidence/canonical.json
rea compare /absolute/path/to/evidence/left.json /absolute/path/to/evidence/right.json
rea investigate-versions /absolute/path/to/releases/v1 /absolute/path/to/releases/v2 /absolute/path/to/evidence/releases.json --yes --workspace-name releases
rea analyze /absolute/path/to/releases/app.asar --approved --json
rea analyze-javascript-application /absolute/path/to/releases/app.asar --approved --json

Для каталога или .asar универсальная команда rea analyze автоматически выбирает провайдера статического JavaScript-приложения, когда не указаны ни --provider, ни --snapshot. Выделенная команда остаётся доступной для явного контроля формата и ограничения ресурсов. Оба пути требуют --approved и одобренный администратором корневой путь для входных данных расследования.

Если REA зарегистрирован в MCP-клиенте, выполните одобренную команду rea setup, пока задана явная переменная корневого пути расследования, затем перезапустите этот клиент. Setup копирует этот несекретный политический файл в управляемую регистрацию; изменение только переменных окружения shell не может обновить уже запущенный MCP-процесс.

investigate-versions составляет перечень обеих версий, создаёт контрольные точки их наблюдаемых Evidence, формирует сравнение артефактов и записывает отчёт об изменённом поведении. Оба входных пути должны разрешаться внутри REA_INVESTIGATION_INPUT_ROOTS_JSON; файлы рабочей области остаются независимо ограниченными через REA_EVIDENCE_ROOTS_JSON. Рабочая область использует детерминированные идентификаторы содержимого и монотонные ревизии, связанные с CAS, поэтому один и тот же запрос возобновляет прерванный запуск или повторно использует завершённый запуск, не заменяя более ранние расследования. В настоящее время сравнивается только статическая структура артефактов; ни одна из версий не выполняется, и в отчёте каждое различие помечено как кандидат на изменение поведения. См. Постоянные рабочие области расследований.

Импорт исторических исходников требует отдельного белого списка и никогда не рассматривает исходники как текущий авторитет поведения:

export REA_REFERENCE_ROOTS_JSON='["/absolute/path/to/source"]'
rea import-reference-source /absolute/path/to/source

Экспорт никогда не заменяет существующий файл, если явно не указан --overwrite. Импорт ограничен по размеру/глубине, проверяет каждый ID Evidence v2 и манифест и никогда не выполняет содержимое пакета.

Не зависящие от провайдера снимки анализа сохраняют успешные, неизменяемые вызовы REA и их записи Evidence v2. Это точные кэши, а не базы данных Hopper: REA повторно использует запись v2 только тогда, когда совпадают дайджест бинарника, вид, формат, архитектура, параметры операции, конкретная сборка провайдера и канонический дайджест профиля анализа. Настройки загрузчика Hopper по умолчанию и заданные переопределения нормализуются адаптером Hopper и фиксируются в этом профиле, поэтому переопределения занимают отдельный безопасный раздел кэша, а не отключают снимки. Снимок v1 не может доказать такую семантику и отклоняется с указанием необходимости повторного захвата. Зависимые от курсора и изменяющие состояние вызовы никогда не кэшируются. Файлы снимков могут содержать проприетарные результаты анализа и локальные пути, поэтому REA хранит их локально, записывает с правами только для владельца и требует отдельного одобренного корневого пути:

export REA_ANALYSIS_SNAPSHOT_ROOTS_JSON='["/absolute/path/to/analysis"]'
rea analyze /absolute/path/to/app --snapshot /absolute/path/to/analysis/app.json
# The same exact query can now be answered from the snapshot.
rea analyze /absolute/path/to/app --snapshot /absolute/path/to/analysis/app.json

Точные повторные воспроизведения CLI-доказательств выполняются до запуска любого процесса провайдера. В MCP-сессиях передайте snapshot_path в open_binary для атомарного импорта снимка при открытии соответствующей цели; MCP-провайдеры могут всё же запуститься до воспроизведения кэшированного вызова. Передайте snapshot_path и, при необходимости, overwrite: true в close_binary, чтобы сохранить атомарно до освобождения ресурсов Hopper. Если сохранение не удалось, REA намеренно оставляет сессию открытой.

Один запрос — полное расследование

Reverse engineer the Notes app. Find how offline search works, explain it,
and build a version for my project using TypeScript and SQLite.

REA даёт агенту чёткий путь от запроса до работающего кода:

Шаг	Что делает агент	Инструменты REA
1	Открывает и идентифицирует бинарник	open_binary, binary_overview
2	Находит вероятные подсказки для офлайн-поиска	search_strings, search_procedures, list_names
3	Связывает эти подсказки с исполняемым кодом	find_xrefs_to_name, xrefs, procedure_callers
4	Реконструирует релевантный поток управления	get_call_graph, procedure_callees, procedure_info
5	Декомпилирует релевантные процедуры	procedure_pseudo_code, procedure_assembly, batch_decompile
6	Создаёт функцию в вашем проекте	код, адаптированный под ваш стек, продукт и требования

REA выполняет анализ приложения на шагах 1–5. Агент выполняет шаг 6 своими обычными инструментами редактирования и тестирования, используя то, что узнал о приложении.

Что могут делать агенты

• Изучите понравившуюся функцию и создайте версию, адаптированную под ваш собственный продукт.
• Объясните, как работает функция, когда исходный код недоступен.
• Восстановите поток аутентификации, хранения, обновления или сетевого взаимодействия приложения.
• Восстановите достаточную структуру, чтобы задокументировать недокументированный формат или интерфейс.
• Проследите подозрительное поведение от строки или символа до кода, который его реализует.
• Запускайте, создавайте контрольные точки, возобновляйте и повторно используйте исследование артефакта с адресацией по содержимому в двух версиях.
• Превращайте восстановленное поведение в функции продукта, тесты, заметки о миграции, порты или взаимозаменяемые замены.
• Анализируйте метаданные Swift и Objective-C без ручного распутывания каждого изменённого символа.
• Оставляйте имена, комментарии и закладки в Hopper, чтобы анализ человека и агента усиливали друг друга.

Каталог инструментов для исследования

Семейство инструментов	Кол-во	Примеры
Нативная инспекция	36	процедуры, псевдокод, ассемблер, строки, имена, сегменты, вызывающие, вызываемые, перекрёстные ссылки, аннотации, ограниченные чтения байтов, преобразование смещений файлов
Рабочие процессы исследования	13	binary_overview, analyze_function, inspect_native_api, batch_decompile, trace_feature, поиск точной строки по коду, ограниченные пути вызовов, графы вызовов, обнаружение Swift и Objective-C
Нативные утилиты macOS	5	метаданные Mach-O, подписи кода, plist, архитектуры, деманглинг Swift; без Hopper и с указанием происхождения
Граф артефактов	3	ограниченная провайдер-нейтральная инспекция, детерминированная инвентаризация каталогов/ZIP/APK/IPA/MSIX/AppX/ASAR и явно выбранное извлечение в отсутствующее принадлежащее дерево
Управляемые PE/CLI	8	идентичность PE/CLI, члены метаданных, хэши CIL, объявления и проверка P/Invoke/нативной границы, проекция графа приложения, импорт реконструкции декомпилятора, повторное сопоставление токенов, планы корреляции времени выполнения и сравнение версий
Наблюдение за браузером	9	пассивный захват CDP точного происхождения, анализ пакетов и исходных карт, обнаружение WebMCP, временные шкалы сеансов, различие захватов, визуальные доказательства и ограниченные сценарии Playwright
Анализ Electron	5	пассивное наблюдение с ограничением корня, ограниченное статическое сопоставление приложения, сверка статики/времени выполнения на основе доказательств и отдельно одобренные сценарии щелчков/ожидания, принадлежащие провайдеру
Среда выполнения JavaScript	2	одобренное обнаружение целей Node/Electron Inspector только с присоединением, плюс ограниченное наблюдение за скриптами и контекстами выполнения без оценки или инструментирования
Рабочие процессы приложения	12	ограниченные сквозные трассы, сопоставление версий только по уникальным элементам, сопоставление исторических исходников с пакетами, статическое сравнение форм возвращаемых значений, одобренный повтор проигрывания извлечённого модуля в изолированной среде Linux, характеристика управляемой среды выполнения, замыкание покрытия реконструкции, детерминированные реестры обязательств и сквозное соответствие готовности
Рабочая область и наблюдение	23	жизненный цикл цели, снимки пакета Evidence v2, выпуск сохранённого пакета, агрегированный контекст навигации/адреса, прямая оценка конечной машины повторного проигрывания, сравнение процессов/артефактов/функций, жизненный цикл остаточных неизвестных, связанных с доказательствами
Публичный интерфейс описывает то, что агент пытается изучить. Провайдеры решают, как отвечать. Утилиты macOS обрабатывают общую семантическую инспекцию без запуска Hopper; Hopper занимается более глубоким нативным анализом; процессный харнесс реализует контролируемый сбор поведенческих данных.

Текущий статус

REA уже полезен для исследования нативных приложений, браузеров и Electron на поддерживаемых хостах macOS и Linux, а также для ограниченного Windows-режима Ghidra P0, описанного выше:

• Открывает Mach-O, ELF, PE, .app, ZIP, APK, IPA, ASAR, plist, JavaScript, source-map и универсальные цели баз данных анализа; Hopper остается единственным адаптером, который принимает устаревшие базы .hop.
• Обнаруживает кандидатов для глубокого анализа без их запуска, выбирает детерминированно и сохраняет одну неизменяемую привязку провайдера/профиля до явного переключения или закрытия; сбои провайдера никогда не вызывают прозрачный фолбэк.
• Подключается к принадлежащему пользователю браузеру семейства Chrome через настроенную loopback-конечную точку CDP; захватывает веб-структуру точного происхождения, безопасные метаданные, одобренные формы полезной нагрузки без значений, свидетельства бандлов/source-map, декларации WebMCP, таймлайны действий пользователя, диффы захвата и явно одобренные скриншоты без навигации или выполнения JavaScript.
• Инспектирует страницы рендерера Electron file:// через отдельную границу разрешений канонического корня без вызова API Electron; содержимое скриптов остается отдельно одобренным и ограниченным по байтам.
• Подключается к одной точно одобренной цели V8 Inspector Node или Electron и сохраняет ограниченные метаданные scriptParsed и жизненного цикла контекста выполнения без оценки, точек останова, возобновления, чтения исходников или инструментирования. Рёбра require/import, активность EventEmitter, IPC Electron, идентичность PID и идентичность ролей остаются неизвестными. См. пассивное наблюдение за рантаймом Node и Electron.
• Проверяет и канонически сериализует нейтральный к провайдеру JavaScript Application Graph v1, охватывающий пакеты, записи ASAR, роли Electron, сущности JavaScript/source-map, экземпляры браузера/рантайма, IPC, конечные точки, хранилище и нативные аддоны. Этот опубликованный доменный контракт сам по себе не выполняет извлечение или ввод-вывод.
• Реконструирует ограниченную статическую структуру пакета, точки входа, модулей Webpack/Rspack, импортов, воркеров, конечных точек, хранилища, source-map, BrowserWindow, preload, contextBridge, IPC, служебных процессов и нативных аддонов из одобренной локальной директории или ASAR через analyze_javascript_application или rea analyze-javascript-application. Сервис приложений, работающий только с AST, никогда не выполняет код загрузчика, связывает только уникальные точные литеральные IPC-каналы и сообщает о динамических или неоднозначных каналах как о неразрешенных.
• Согласует этот статический граф с существующими пассивными веб- или Electron-доказательствами через reconcile_javascript_runtime или rea reconcile-javascript-runtime. Точные захваченные байты имеют приоритет над объявленными вызывающим сопоставлениями файл/URL; неоднозначность цели, фрейма, скрипта, воркера, кэша и ассета остается явной, полномочия source-map остаются раздельными, и модуль, находящийся в наблюдаемом бандле, никогда не сообщается как выполненный. См. согласование статики/рантайма JavaScript.
• Прослеживает литеральный маршрут, строку, API, IPC-канал, модуль или нативный экспорт через аутентифицированные доказательства приложения с явными границами обхода, затем передает точные дайджесты нативных артефактов и запрошенные экспорты в сохраненные доказательства Ghidra или Hopper без автоматического переключения провайдера. Сравнивает версии приложений, используя уникальные только дайджесты, source-map, структурные и семантические уровни; сопоставляет зафиксированную историческую инвентаризацию исходников с узлами бандла с явными оценками дайджеста и пути; сравнивает статические формы возврата одного точного экспорта JavaScript через уникальные литеральные дискриминанты и ограниченные изменения JSON Pointer. Дублирующиеся, динамические, неполные, неоднозначные и усеченные факты остаются неизвестными. См. кросс-слойные рабочие процессы приложений JavaScript.
• Классифицируйте управляемые артефакты PE/CLI с помощью inspect_managed_artifact / rea inspect-managed-artifact, проверяйте ограниченные элементы метаданных, сигнатуры, необработанные хеши CIL, ограниченные хеши v1 декодированных кортежей инструкций, отдельно сообщаемые области исключений, рёбра вызовов и привязки доступа к полям с помощью inspect_managed_members / rea inspect-managed-members, инвентаризируйте объявленные ModuleRef/ImplMap/PInvoke и индикаторы границ не-IL методов с помощью inspect_managed_native_boundaries / rea inspect-managed-native-boundaries, затем сравните два аутентифицированных наблюдения членов с помощью compare_managed_members / rea compare-managed-members. verify_managed_native_boundaries / rea verify-managed-native-boundaries проверяет объявления управляемого P/Invoke на соответствие аутентифицированным нативным экспортам или Evidence функций, сохраняя при этом проверенные, выведенные, противоречивые и неразрешённые состояния раздельными. Сравнение рассматривает токены, локальные для сборки, как локальные для сборки и использует уникальные декодированные CIL/сигнатуры и структурные уровни формы методов, а не только имена; хеш кортежа v1 сам по себе не разрешает токены и не полностью фиксирует поток управления. project_managed_application_graph / rea project-managed-application-graph проецирует аутентифицированные Evidence управляемых артефактов/членов/нативных границ в существующий граф приложения для межслойного трассирования функций. import_managed_reconstruction / rea import-managed-reconstruction принимает предоставленный пользователем C#/IL/псевдокод декомпилятора только как аналитический вывод после точного соответствия SHA-256 артефакта, MVID, сигнатуры и поставляемого обязательства v1 декодированного IL. Отдельно plan_managed_runtime_correlation / rea plan-managed-runtime-correlation может допустить план корреляции времени выполнения, отключённый по умолчанию и ограниченный разрешениями, привязанный к тем же строительным Evidence. Эти пути никогда не загружают сборку, не разрешают зависимости CLR, не выполняют целевой код, не запускают декомпилятор и не переводят управляемые токены в нативные адреса; полная семантика v2 нормализованного CIL, сопоставление мостов нативных тел и фактический исполнитель времени выполнения остаются будущими контрактами управляемого кода.
• Настройте REA_ILSPY_CMD_PATH=/absolute/path/to/ilspycmd только когда вы хотите, чтобы doctor и verify:managed проверяли предоставленную вами команду ILSpy как реальный оракул реконструкции. REA не устанавливает ILSpy и не рассматривает текст декомпилятора как каноническое наблюдение метаданных или CIL.
• Обходите графы артефактов с адресацией по содержимому без извлечения; на macOS обход доступной только для чтения DMG дополнительно требует native_mount_approved: true и REA_ARTIFACT_NATIVE_MOUNT_ENABLED=true. Материализуйте только одобренные вхождения в отсутствующие корневые каталоги вывода.
• Создавайте ограниченные досье функций с псевдокодом, ассемблером, рёбрами CFG, комментариями, вызовами, ссылками, строками и именами.
• Ищите и трассируйте функции по символам, строкам, метаданным, ссылкам и путям вызовов.
• Записывайте каждый успешный результат как детерминированное Evidence v2 с идентичностью артефакта и провайдера, уверенностью, авторитетом, ограничениями и местоположениями.
• Экспортируйте и импортируйте пакеты Evidence между сеансами.
• Сохраняйте автоматические межверсионные прогоны артефактов как канонические рабочие области, защищённые блокировками, с обязательствами по ревизиям, защищёнными от несанкционированного вмешательства.
• Захватывайте одобренные сценарии PTY как Evidence Process Capture v4, включая зафиксированные манифесты запуска, необработанные и отрисованные кадры терминала, скриптовые взаимодействия, завершение дочерних процессов, именованные контрольные точки файловой системы, детерминированные прокладки команд и обмены через loopback HTTP/WebSocket.
• Проверяйте конечные машины воспроизведения без запуска цели с помощью run_replay_machine или rea run-replay-machine; упорядоченные события возвращают типизированные решения, действия, захваченные псевдонимы, журналы переходов, конечное состояние и точное использование лимитов без повторения запроса или захваченных значений.
• Сравнивайте полные инвентаризации артефактов по стабильному пути, содержимому, метаданным и связям; неполное Evidence никогда не подразумевает эквивалентность.
• Сравнивайте явные досье функций по тексту, вызовам, ссылкам, строкам и нормализованной по адресам топологии CFG с неизвестными по аспектам.
• Сравнивайте канонические пакеты Evidence по точному членству, явным парам наблюдений и остаточным неизвестным историям, не превращая пропуски в поведенческое отсутствие.
• Агрегируйте сравнения времени выполнения в наблюдаемые изменения поведения, сохраняя при этом статические различия артефактов/функций как кандидаты.
• Стройте ограниченные прямые пути вызовов, цитируемые Evidence, по точному адресу, не рассматривая отсутствующие досье как листья графа.
• Соотносите точные статические/динамические находки через явные гипотезы, не заявляя о причинно-следственной связи на основе совместных изменений.
• Проверяйте конечные спецификации поведенческой и структурной реконструкции, сохраняя различие между «пройдено», «не пройдено» и «неизвестно».
• Отслеживайте остаточные неизвестные через неизменяемые CAS-ревизии, разрешение с подтверждением доказательств, противоречия, пробы и проверенные зависимости.
• С явным unknown_registry_approved: true автоматически фиксируйте ограниченные остатки трассировок/захватов, недоступность типизированных провайдеров и разногласия при захвате.
• Запускайте шесть управляемых MCP-процедур с живым завершением, учитывающим контекст сессии, для документов, процедур, провайдеров, доказательств, захватов, идентификаторов артефактов и активных неизвестных.

Hopper — первый провайдер, но не граница проекта. Некоторые текущие процедуры по-прежнему требуют Hopper и macOS; каждая запись о доказательстве указывает провайдера и ограничения, стоящие за её результатом.

Наблюдение за веб-сайтом через CDP

REA может проверять уже запущенный браузер семейства Chrome, которым вы владеете. Наблюдение за браузером отключено по умолчанию и требует буквального адреса CDP loopback, а также точных одобренных источников страниц:

export REA_BROWSER_OBSERVE_ENABLED=true
export REA_BROWSER_CDP_ENDPOINTS_JSON='["http://127.0.0.1:9222"]'
export REA_BROWSER_ALLOWED_ORIGINS_JSON='["http://127.0.0.1:3000"]'

rea list-browser-targets http://127.0.0.1:9222 --approved --json
rea inspect-web-page http://127.0.0.1:9222 TARGET_ID --approved --json

Все восемь браузерных инструментов предоставляют одинаковые контракты Evidence v2 через CLI и MCP. Проверка пассивна: REA не выполняет JavaScript на странице, не переходит по ссылкам, не кликает, не закрывает страницу и не закрывает браузер. Значения запросов, учётные данные, cookie, заголовки авторизации, значения хранилища и исходные значения JSON или WebSocket никогда не сохраняются. Отдельно одобренные захваты могут сохранять ограниченные, отредактированные примитивы консоли, структуры JSON/WebSocket без значений, исходники скриптов, текст для доступности или пиксели скриншотов. Активность, существовавшая до подключения, явно недоступна. См. раздел Наблюдение за веб-сайтом через CDP о запуске браузера, схемах, ограничениях и модели угроз.

Контролируемые сценарии браузера

capture_browser_scenario — это отдельная, явно изменяющая состояние граница браузера. Она выполняет только фиксированный, версионированный словарь сценариев через Playwright и возвращает Evidence с индексацией по шагам для скриншотов, DOM, доступности, URL/истории, хранилища, консоли/ошибок, сети, WebSockets, фреймов, воркеров, всплывающих окон и отменённых загрузок. Отсутствующие или усечённые разделы никогда не могут поддерживать утверждения о равенстве.

export REA_BROWSER_SCENARIO_ENABLED=true
export REA_BROWSER_SCENARIO_EXECUTABLE_ROOTS_JSON='["/usr/bin"]'
export REA_BROWSER_SCENARIO_CDP_ENDPOINTS_JSON='["http://127.0.0.1:9222"]'
export REA_BROWSER_SCENARIO_ALLOWED_ORIGINS_JSON='["http://127.0.0.1:3000"]'
export REA_BROWSER_SCENARIO_ALLOWED_ENV_JSON='["REA_TEST_PASSWORD"]'

rea capture-browser-scenario ./scenario.json --json

Режим запуска владеет временным профилем браузера и удаляет его после завершения запущенного браузера. Режим подключения принимает одну точную цель CDP loopback и отключается, не закрывая внешний браузер. Автоматизация не имеет разрешений по умолчанию: используйте общую политику проекта/сессии или установите REA_BROWSER_SCENARIO_AUTO_GRANT=true только для доверенной автоматизированной среды без присмотра. JSON сценария содержит ссылки на секреты и имена переменных окружения, но никогда сами секретные значения. См. контракт сценария браузера.

Наблюдение за V8 Inspector в Node и Electron

Наблюдение за рантаймом JavaScript только через подключение отдельно отключено по умолчанию:

export REA_V8_INSPECTOR_OBSERVE_ENABLED=true
export REA_V8_INSPECTOR_ENDPOINTS_JSON='["http://127.0.0.1:9229"]'
export REA_V8_INSPECTOR_FILE_ROOTS_JSON='["/absolute/path/to/app"]'
export REA_V8_INSPECTOR_ALLOWED_ORIGINS_JSON='[]'

rea list-javascript-runtime-targets http://127.0.0.1:9229 --approved --json
rea observe-javascript-runtime http://127.0.0.1:9229 TARGET_ID \
  --runtime-kind node --approved --json

REA отправляет только Runtime.enable и Debugger.enable. Он сохраняет ограниченные расположения скриптов и события жизненного цикла контекста выполнения, авторизованные по области; рёбра require/import, активность EventEmitter, IPC Electron, идентичность PID и роль Electron остаются явными неизвестными. См. пассивное наблюдение за рантаймом Node и Electron.

Точные факты о пакетах, семействах инструментов, провайдерах, клиентах настройки, публичных версиях схем и CLI генерируются из исходного кода в docs/product-catalog.json. CI PR проверяет этот каталог, повествовательную документацию, сгенерированные схемы и чистую компиляцию TypeDoc.

Дорожная карта

REA развивается в набор инструментов для понимания программного обеспечения через статические артефакты и наблюдаемое поведение. Текущий статус выше — это выпущенная базовая версия; пункты ниже — запланированная работа.

Сейчас

1. Поддержание правдивых метаданных продукта — расширение выпущенного канонического каталога и проверок расхождений при любых изменениях версий, инструментов, провайдеров, схем, клиентов настройки или возможностей CLI.
2. Рост соответствия между провайдерами — добавление архитектур с исходным кодом и сложных косвенных/трамплинных случаев с сохранением семантического сравнения и границ текста, специфичных для провайдера.

Далее

1. Контролируемый рост соответствия воспроизведения — расширение поставляемого Linux-модуля песочницы для извлеченных модулей дополнительными враждебными фикстурами, принадлежащими исходному коду, и кросс-ядерным соответствием; сценарии браузера и Electron остаются отдельно авторизованными полномочиями.
2. Более широкая доказательная база графа приложений — расширение аутентифицированных кросс-слойных трасс дополнительными статическими экстракторами и отдельно утвержденными рантайм-полномочиями.
3. Профессиональный анализ управляемого кода — расширение поставляемой триажной обработки PE/CLI, доказательств CIL, инвентаризации управляемых/нативных объявлений, конформности, принадлежащей исходному коду, и сравнений, устойчивых к обфускации, в направлении проверенной композиции нативных провайдеров в рамках принятой границы управляемого кода.
4. Детерминированные поведенческие стенды — расширение владения процессами, фикстур протоколов, наблюдения за файловой системой, переподключений и кросс-версионного сравнения поведения.

Позднее

1. Более широкое контролируемое взаимодействие с приложениями — расширение отдельно авторизованных поверхностей сценариев браузера и Electron за пределы текущих ограниченных действий кликов/ожидания без расширения пассивного наблюдения или полномочий на воспроизведение извлеченных модулей.
2. Наблюдение за нативным рантаймом — LLDB, Frida, системные журналы, наблюдатели процессов/файловой системы и трассировка нативных API с разрешения.
3. Дополнительные провайдеры и цели — оценка IDA/Hex-Rays, Binary Ninja, Rizin, LIEF, нативных провайдеров Windows, мобильных артефактов, прошивок, форматов документов и других программно-определяемых систем.

Новые провайдеры должны предоставлять те же доказательства и метаданные безопасности, что и существующие возможности, прежде чем они станут частью публичного рабочего процесса. После того как у REA появится несколько опциональных инструментальных цепочек, настройка может стать селективной по возможностям; правила согласия для этой будущей работы задокументированы в дорожной карте установки.

См. оценку провайдеров статического анализа для поставляемой границы функционального анализа Ghidra, оставшихся шлюзов допуска и матрицы сравнения провайдеров; ADR-0001 для решений по привязке, выбору, профилям, снимкам и совместимости; руководство по контролируемому воспроизведению плюс ADR-0002 для поставляемой границы воспроизведения JavaScript; и ADR-0003 для доказательств управляемого кода и дизайна провайдеров.

Использование REA с другими агентами

Установка обнаруживает Claude Code, Claude Desktop, Codex, Cursor, Gemini CLI, Windsurf и Devin. Она автоматически настраивает первые шесть при их наличии; обнаруженные установки Devin регистрируются, но остаются без изменений. Любой агент, поддерживающий локальные MCP-серверы, может использовать REA с приведенной ниже конфигурацией.

Ручная конфигурация MCP

{
  "mcpServers": {
    "rea": {
      "command": "npx",
      "args": ["-y", "rea-agents@3.1.0", "mcp"]
    }
  }
}

Постоянные регистрации должны использовать одну точную версию пакета. rea setup поддерживает эту фиксацию, обновляет встроенный скилл одновременно и дает Codex 30-секундный стартовый бюджет для холодного запуска пакетного раннера. Интерактивное rea upgrade открывает обновленный план установки после установки нового исполняемого файла; структурированные или неинтерактивные обновления сообщают вам о необходимости выполнить эту синхронизацию явно. Перезапустите клиенты, чья одобренная регистрация изменилась.

MCP-клиенты, поддерживающие промпты, также могут обнаружить шесть упорядоченных следственных рабочих процессов через prompts/list. Их опциональные аргументы-идентификаторы используют текущую сессию для ограниченных предложений completion/complete; см. Управляемые MCP-промпты и дополнение.

Как это работает

flowchart LR
Agent["Agent"] --> REA["REA<br/>CLI + MCP"]
    Terminal --> REA
REA --> Workspace["Investigation workspace<br/>evidence + artifacts + captures"]
    REA --> Session["Target-bound session router"]
Session --> Registry["Deep-provider registry<br/>deterministic selection"]
    Registry --> Hopper["Hopper provider"]
Registry --> Ghidra["Ghidra provider<br/>read-only inventory + function analysis"]
Hopper --> Runtime["Owned provider runtime<br/>deadline + bounded diagnostics + cleanup"]
    Ghidra --> Runtime
    Session --> Native["Native macOS provider"]
    Session --> Artifact["Artifact graph provider"]
    REA --> Browser["Browser CDP provider"]
    REA --> Process["Process capture provider"]
    Runtime --> Target["Target software"]
    Process --> Target
    Native --> Target
    Artifact --> Target

CLI и MCP-сервер используют одни и те же прикладные рабочие процессы и контракты доказательств. Провайдер объявляет, какие возможности он поддерживает и какие побочные эффекты эти возможности могут иметь. Терминальные команды кратковременны; MCP-сессия может сохранять активную цель и реестр доказательств на протяжении всего расследования. Одобренные постоянные рабочие области сохраняют канонические доказательства и возобновляемые контрольные точки выполнения как во времени жизни процесса, так и во времени жизни сессии.

CLI

Описанный выше агентский workflow — это самый простой способ использования REA. Для разового обзора из Терминала:

npx -y rea-agents@latest analyze /Applications/Notes.app
npx -y rea-agents@latest inspect /Applications/Notes.app
npx -y rea-agents@latest inspect /Applications/Notes.app --detail detailed --limit 20
npx -y rea-agents@latest search /Applications/Notes.app "offline"
npx -y rea-agents@latest function /Applications/Notes.app 0x1000
npx -y rea-agents@latest xrefs /Applications/Notes.app 0x1000
npx -y rea-agents@latest trace /Applications/Notes.app "offline"
npx -y rea-agents@latest compare /absolute/path/to/left-evidence.json /absolute/path/to/right-evidence.json
npx -y rea-agents@latest investigate-versions /path/to/v1 /path/to/v2 /absolute/path/to/evidence/releases.json --yes
npx -y rea-agents@latest capabilities
npx -y rea-agents@latest providers

Запустите npx -y rea-agents@latest --help для прямой декомпиляции, ограниченного поиска и других опций. analyze и inspect используют один и тот же обзорный workflow; function, xrefs и trace возвращают те же конверты Evidence v2, что и MCP.

Или установите команду rea глобально:

npm install --global rea-agents
rea --help
rea upgrade
rea mcp

REA принимает папку Mac .app напрямую. Если агент не может найти приложение по имени, укажите ему, где установлено приложение.

Выбор провайдера глубокого анализа

Каждое открытие для глубокого анализа разрешает провайдера перед созданием своего клиента. Тот же селектор и приоритет применяются к CLI, MCP и конфигурации запуска:

rea providers --json
rea analyze /absolute/path/to/program --provider hopper
REA_ANALYSIS_PROVIDER=hopper rea decompile /absolute/path/to/program 0x1000

Для MCP передайте необязательный селектор в open_binary:

{
  "path": "/absolute/path/to/program",
  "provider_id": "hopper"
}

provider_id на уровне запроса или --provider имеет приоритет над REA_ANALYSIS_PROVIDER; все принимают идентификатор провайдера или auto. Автоматический выбор привязывает единственного пригодного кандидата для глубокого анализа, сообщает ambiguous, когда доступно несколько, и может оставить цель только с артефактами непривязанной, чтобы её операции с разрозненными артефактами продолжали работать. Явный неизвестный, недоступный или неподдерживаемый провайдер завершается ошибкой с идентификаторами кандидатов, стабильными кодами отклонения и практической локальной диагностикой. binary_session, rea providers и rea capabilities раскрывают авторитетные поля analysis_provider_candidates и analysis_provider_binding. Каждая открытая цель также имеет analysis_run.run_id, выделенный до запуска провайдера. Когда динамические провайдеры запускаются, analysis_run.process_lineage меняется с not_observed на snapshots и сохраняет одно наблюдение, приписываемое провайдеру и проверенное токеном, для каждого запущенного провайдера. Каждое наблюдение несёт observed_at и остаётся unavailable или verified; проверенный пустой список потомков отличается от обоих. Снимки описывают ограниченные наблюдения, а не текущее живое состояние или историческое отсутствие. Для провайдеров с последовательной работой analysis_activity различает idle, busy и timed_out_busy, а также сообщает активную операцию, затраченное время, состояние вызывающего, таймаут и количество запросов в очереди. Таким образом, таймаут вызывающего не подразумевает ложно, что поток Python Hopper доступен. close_binary очищает сеанс REA, но возвращает cleanup_incomplete, когда аутентифицированное завершение документа, очистка собственных процессов или удаление приватной среды выполнения не могут быть проверены. Повторное открытие той же цели без селектора сохраняет её привязку; сбой во время выполнения никогда не выбирает другого провайдера молча. Ghidra может появиться как доступный, совместимый с целью кандидат после того, как doctor проверит его точную установку. Его список возможностей содержит 19 разрешённых операций инвентаризации только для чтения и анализа функций; выбор его по-прежнему не делает операции GUI или мутации, доступные только в Hopper, и никогда не вызывает тихий откат.

Статус выхода CLI

Статус	Значение
0	Запрошенная операция завершена. Правдивые неизвестные, предупреждения и ограниченные или усечённые доказательства остаются успешными результатами.
1	Аргументы, политика, разрешения, анализ провайдера, проверка целостности, отмена, таймаут, настройка, диагностика, обновление, удаление, кодирование вывода или запись вывода предотвратили завершение. Структурированный вывод идентифицирует категорию сбоя, когда REA может её закодировать.
128 + N	Процесс завершился из-за сигнала N, где оболочка или среда выполнения сохраняет обычный статус, производный от сигнала.

setup возвращает 1 для planned, needs_confirmation или needs_human, поскольку конфигурация не готова; повторите его после одобрения или исправления. doctor возвращает 1, когда любая проверка нездорова. Формат вывода, полные конверты, фильтры и элементы управления токенами никогда не меняют статус операции.

Когда REA передает данные в конвейер оболочки, включите pipefail, чтобы последующий форматировщик не мог скрыть свой сбой:

set -o pipefail
rea inventory-artifact ./app.asar --json | jq . > inventory.json

Текущий провайдер Hopper

REA запускает Hopper при необходимости; Hopper не должен быть запущен заранее. Загрузчик Hopper внутренне активирует приложение, поэтому открытие цели может вывести Hopper на передний план. REA просит macOS запускать Hopper скрытым и в фоновом режиме, когда это возможно, но не может гарантировать, что он останется позади текущего приложения.

REA формирует явные аргументы формата и архитектуры, чтобы предотвратить типичные диалоги выбора FAT и ARM. Другие диалоги Hopper или macOS могут по-прежнему требовать участия человека. REA сообщает о тайм-аутах и способах устранения через CLI или результаты MCP, вместо того чтобы пытаться отвечать на подсказки пользовательского интерфейса.

Вызовы моста Hopper проходят через ограниченную последовательную очередь FIFO, поскольку Python API Hopper выполняется в одном выделенном потоке. Время ожидания в очереди учитывается в дедлайне вызывающей стороны; тайм-аут завершает вызывающую сторону, но не освобождает слот канала, пока Hopper фактически не ответит. binary_session.analysis_activity отображает эту отвязанную работу, а прогресс MCP сообщает о прошедшем времени. Успешный текст декомпиляции кэшируется для каждого документа и процедуры, используется совместно запросами псевдокода и досье и аннулируется после переименования или изменения комментариев.

Синхронные публичные вызовы Python Hopper не могут передавать частичный ответ после дедлайна вызывающей стороны. Используйте read_function_instructions или rea instructions, когда достаточно ориентации на сырые инструкции: этот путь не декомпилирует и не сканирует инвентаризацию имен/строк всей программы. Если досье уже вышло по тайм-ауту, проверьте analysis_activity; не предполагайте, что сырой запрос может войти в последовательный мост, пока эта отвязанная операция Hopper фактически не вернется.

Закрытие сеанса REA завершает его мост и удаляет его приватный каталог сокетов. Это не завершает приложение Hopper, которое может использовать пользователь. Если завершение или очистку невозможно проверить, close_binary возвращает cleanup_incomplete с затронутыми локальными ресурсами.

Расширенная настройка захвата процессов

Захват процессов отключен по умолчанию. Его включение требует REA_PROCESS_CAPTURE_ENABLED=true, одобренных корней исполняемых файлов и рабочих каталогов в REA_PROCESS_EXECUTABLE_ROOTS_JSON и REA_PROCESS_WORKING_ROOTS_JSON, а также разрешенного списка переменных окружения в REA_PROCESS_ALLOWED_ENV_JSON. Поскольку текущий адаптер PTY использует сеть хоста, также требуется REA_PROCESS_ALLOW_EXTERNAL_NETWORK=true.

Установите REA_PROCESS_CAPTURE_AUTO_GRANT=false, чтобы настроить эти лимиты захвата процессов как потолок, не предоставляя их неявно. Этот режим остается закрытым при сбое, пока не установлено более узкое разрешение.

Захватите сценарий или сравните две сохраненные записи Evidence версии 4 Process Capture:

rea capture-process ./scenario.json > authority.json
rea capture-process ./reconstruction.json > reconstruction.json
rea compare-process-captures authority.json reconstruction.json

Сравнение сообщает о каждом наблюдаемом измерении отдельно и определяет первое расхождение в терминале, взаимодействии, завершении, файловой системе, протоколе, процессе или шем-слое. См. Process Capture v4 для получения информации о полях сценария, воспроизведении через шем для команд, триггерах контрольных точек, лимитах и поведении безопасности.

REA устанавливает предварительно собранный PTY-бэкенд для поддерживаемых архитектур macOS, Linux и Windows. Если проверка возможностей сообщает, что бэкенд недоступен, переустановите REA для текущей платформы и архитектуры.

Инвентаризация ASAR проверяет метаданные целостности Electron как для записей архива, так и для сопутствующих файлов .asar.unpacked. Сбои целостности определяют логический путь, заявленные и вычисленные значения SHA-256, а также то, был ли элемент распакован; REA не принимает молча несоответствующий артефакт. Если предоставленный ASAR объявляет распакованные сопутствующие байты, которые отсутствуют в локальном наборе артефактов, REA сохраняет это вхождение как unavailable и продолжает анализировать встроенный JavaScript, вместо того чтобы считать отсутствующие байты нативных/ресурсов подтвержденными или отсутствующими.

Модель безопасности

REA не предоставляет хостируемый сервис анализа. Связь моста Hopper и Linux Ghidra использует аутентифицированные приватные локальные сокеты. Windows Ghidra P0 использует аутентифицированный IPv4 loopback, но не заявляет об изоляции через DACL именованных каналов или защите от враждебных локальных пользователей. Динамические возможности отключены по умолчанию и требуют как политики оператора, так и явного одобрения каждого вызова. Поставляемые провайдеры, пассивные наблюдатели и Process Capture не являются песочницами безопасности: провайдеры и запущенные цели работают с правами текущего пользователя. Извлеченный JavaScript-повтор — это отдельная возможность только для Linux, которая закрывается при сбое, если недоступны пространства имен Bubblewrap, seccomp с проверкой архитектуры, приватные монтирования времени выполнения и делегированные ограничения cgroup; она никогда не наследует полномочия браузера, Electron или Process Capture. См. ADR-0002. Сообщайте об уязвимостях через приватный процесс, описанный в SECURITY.md.

FAQ

Нужно ли запускать Hopper до начала работы REA?

Нет. REA запускает Hopper, когда операция требует его. Также поддерживается уже запущенное приложение Hopper.

Почему Hopper появился поверх моих других окон?

Загрузчик Hopper внутренне активирует приложение. REA запрашивает фоновый запуск, но macOS и Hopper могут все равно вывести окно или диалог на передний план. См. Поведение приложения Hopper.

Включает ли REA Hopper?

Нет. Установщик может установить Hopper за вас, но Hopper остается отдельным программным обеспечением с собственной лицензией. REA предоставляет CLI, MCP-сервер и рабочие процессы, которые делают его пригодным для использования агентами.

Устанавливает или включает ли REA Ghidra или Java?

Нет. Поддержка Ghidra — это «принеси свой собственный». REA поставляет только исходный код своего Java-моста, проверяет точную поддерживаемую установку Ghidra 12.1.2 и 64-битного JDK 21 и загружает этот мост через внешний путь скриптов Ghidra после того, как одобрение установки зафиксирует пути.

Загружает ли REA приложение?

У REA нет хостируемого сервиса анализа. Текущие провайдеры анализируют артефакты и записывают поведение локально. У вашего агента или провайдера модели может быть собственная политика обработки данных, поэтому изучите её отдельно.

Может ли REA восстановить исходный код?

Ни один декомпилятор не может гарантировать исходный код. REA предоставляет агенту псевдокод, ассемблер, символы, строки, метаданные и связи, которые он может использовать для объяснения или совместимого воссоздания наблюдаемого поведения.

Какие агенты могут использовать REA?

Любой агент, который может запустить локальный MCP-сервер, может использовать ручную настройку. Установщик обнаруживает Claude Code, Claude Desktop, Codex, Cursor, Gemini CLI, Windsurf и Devin; он автоматически настраивает первые шесть, если они присутствуют, и сообщает о Devin без его изменения.

Разработка

См. CONTRIBUTING.md для инструкций по настройке, архитектуре и выпуску, а также docs/testing.md для описания глубины поведенческого тестирования, сфокусированных команд разработчика, порогов покрытия и доказательств CI. CI для PR публикует сгенерированную документацию API как артефакт рабочего процесса api-docs.

npm run verify:agent запускает «брендless» нативные, JavaScript-приложения, управляемые и браузерные промпты через реальный локальный Codex CLI. Его JSON-отчет измеряет естественное использование MCP, маршрутизацию первого инструмента, повторные вызовы, фактическое использование токенов Codex, качество завершения и явную обработку полномочий и неизвестного.

npm run evidence:generate регенерирует управляемый манифест соответствия и реестр завершений Evidence v2 из живого вывода верификатора. npm run evidence:check повторно запускает верификатор и завершается ошибкой, если артефакты, сценарии, провайдеры, схемы, количество утверждений, идентификаторы Evidence или встроенный навык «дрейфовали». Неподдерживаемые утверждения остаются явными и никогда не засчитываются как пройденные. JSON-отчеты верификатора включают эфемерный UUID verifier_run, выделяемый до начала работы верификатора и наследуемый его дочерними процессами через REA_PROCESS_RUN_ID. Итоговый отчет включает PIDs верификатора и родительского процесса. плюс process_lineage и его ISO-временную метку observed_at: POSIX-верификаторы сообщают о проверенном по токену, привязанном к моменту времени процессе-запускателе и живых дочерних процессах, в то время как платформы без собственного примитива родословной сообщают status: "unavailable" и причину. Пустой список проверенных потомков означает, что ни один дочерний процесс не был жив во время последнего наблюдения; это не означает, что верификатор не запускал дочерних процессов ранее. Вложенные точки входа верификатора в том же процессе повторно используют его UUID; каждый новый процесс верификатора заменяет любой унаследованный родительский токен новым идентификатором выполнения. Создаваемые обязательства по завершению намеренно исключают этот идентификатор для каждого выполнения, поэтому режим проверки остается детерминированным, а живые отчеты остаются атрибутируемыми.

Собственные журналы завершения Hopper сохраняют PID запускателя, ID группы процессов, статус очистки и то, требовался ли проверенный сигнал группы. Они опускают токен выполнения и текст непредвиденного исключения. Верификатор реального Hopper также запускает несвязанный sentinel с именем Hopper в отдельной группе процессов и завершается с ошибкой, если этот процесс не переживает каждое закрытие сессии; sentinel удаляется только верификатором после проверки выживания.

Ссылки на проект

npm · Issues · Security · Contributing · Hopper · Ghidra

Лицензия

MIT