В компании работает старая программа. Она считает нужный показатель, выгружает данные или общается с оборудованием, но документация устарела, а исходников уже нет. Переписать всё с нуля рискованно: легко потерять незаметное правило, на котором держится процесс. Здесь интересен REA — Reverse Engineer Anything: проект, который подключает ИИ-агента к инструментам исследования программ. REA · project overview and local-analysis FAQ ↗
Его ценность для бизнеса — возможность быстрее перейти от непонятного приложения к проверяемому описанию конкретной функции. Однако «агент объяснил код» и «новая система правильно заменяет старую» — разные результаты. Разберём, что уже умеет REA, какие примеры опубликованы и как использовать эту идею с локальной AI-станцией. Материалы проверены 27 октября 2026 года; AI Office изучил документацию и исходники, но не устанавливал REA и не повторял демонстрации.
Что из новости подтвердилось
REA — открытый проект с MCP-сервером и командной строкой. MCP можно понимать как стандарт подключения инструментов к ИИ-помощнику: агент формулирует запрос к анализатору, получает структурированный результат и выбирает следующий шаг. В официальной настройке перечислены Claude Code, Codex, Cursor, Gemini CLI и другие клиенты. Установка добавляет сервер и инструкции работы, а не дообучает модель. REA · project overview and local-analysis FAQ ↗
Популярность тоже реальна, но цифры быстро меняются. На момент проверки GitHub API показывал 390 345 звёзд вместо 290 тысяч из пересказа. Репозиторий создан 14 апреля 2026 года. Это не опровергает возможный недавний всплеск интереса, но историю роста именно за две недели мы не проверяли. Счётчик звёзд полезен как сигнал внимания, а не как тест точности. GitHub API · REA repository metadata (checked 27 October 2026) ↗
Определение «просто мостик к Ghidra» уже слишком узкое. Для глубокого разбора нативного кода REA использует установленный анализатор, например Ghidra, Hopper или IDA. При этом статический разбор JavaScript/Electron и .NET у проекта есть и без такого движка. Нужный набор зависит от формата программы и задачи. REA · project overview and local-analysis FAQ ↗
Что агент получает вместо исходного проекта
Скомпилированная программа обычно не содержит прежний проект в исходном виде. В документации Ghidra-провайдера REA прямо разделены инструкции, псевдокод и исходный код: первые два представляют результат анализа, а не возвращённый оригинал. Неразрешённые вызовы и неполное покрытие должны оставаться неизвестными, а не превращаться в уверенную историю. REA · Ghidra provider semantics and analysis boundaries ↗
| Объект | Полезный результат | Что ещё нужно проверить |
|---|---|---|
| Нативная программа | Инструкции, псевдокод, вызовы, ссылки | Смысл алгоритма и поведение на входах |
| JavaScript / Electron | Модули, импорты, IPC и границы компонентов | Динамические маршруты и реальную сессию |
| Сборка .NET | Метаданные, CIL, различия членов сборок | Поведение при выполнении |
| Тестовый запуск процесса | Вывод, время жизни, выбранные изменения файлов | Полноту сценария и внешние эффекты |
Для JavaScript полезны связи модулей, импорты и границы Electron: какая часть отвечает за интерфейс, какая обращается к системным возможностям. Но динамически вычисляемый маршрут может остаться неразрешённым. Для .NET доступны метаданные и CIL — промежуточные инструкции; заявленный статический разбор не запускает сборку и не доказывает её поведение в работе. REA · JavaScript application workflows and graph limitations ↗ REA · static .NET metadata, CIL and build comparisons ↗
REA сохраняет Evidence: сведения об исследуемом артефакте, местоположениях, наблюдениях, выводах и ограничениях. В изученном коде результат анализа функции оформляется вместе с доказательными источниками. Это помогает спросить у агента: «На какой файл, адрес или наблюдение ты опираешься?» Сам факт наличия такого отчёта не делает любую интерпретацию верной. REA · CLI, retained Evidence, views and source locations ↗
Три публичных примера: что в них действительно проверили
В случае DX-Ball разобрана одна функция расчёта положения звука в стереопанораме. Исходный псевдокод декомпилятора не показывал всю формулу; реконструкция опиралась на инструкции, место вызова и прочитанные константы. В опубликованной записи указаны 3 205 сравнений с оригинальным x86-кодом и совпадение всех 63 байт скомпилированной функции после учёта проверенных перемещений адресов. REA · DX-Ball evidence, 3,205 cases and 63-byte validation scope ↗
Важно, что эти числа относятся к конкретной функции на закреплённой версии проекта реконструкции. Обновление страницы использовало сохранённые результаты и не повторяло весь вычислительный прогон. Для бизнеса здесь полезен образец приёмки: восстановленную формулу сравнивают с оригиналом на контрольных входах, а не принимают по убедительности объяснения. Это не свидетельство автоматического восстановления всей игры. REA · DX-Ball evidence, 3,205 cases and 63-byte validation scope ↗
В примере Notion исследовали цепочку буфера обмена: от API интерфейса через preload и межпроцессное взаимодействие к основной части Electron-приложения. Документация примера честно отмечает, что один статический граф не разрешил весь маршрут. Вывод дополнялся чтением обёрток и отдельно сохранённых модулей; единую живую сессию копирования для всех описанных частей не записывали. REA · Notion clipboard evidence and unresolved coverage ↗
Этот пример показывает, зачем нужен инженер рядом с агентом: найденный мост между процессами — ещё не полная карта функции. Можно использовать такой подход, чтобы разобраться в собственном настольном приложении, но сначала нужно согласовать, какие версии компонентов и какие действия реально проверены.
Третий пример — помощник расчёта направления снарядов в старой DOS-игре TH04. REA сопоставляет инструкции и адреса с разбором функции; исторические исходники и проверки компилятора принадлежат отдельному проекту реконструкции. Страница не утверждает, что свежий запуск REA самостоятельно восстановил все имена и смысл кода или доказал эквивалентность всей игры. REA · TH04 evidence and separate reconstruction provenance ↗
Это демонстрации, опубликованные проектом и участниками реконструкций. Мы не выдаём их за независимый общий бенчмарк. Их сильная сторона — конкретные границы результата, ссылки и проверки, которые можно изучить.
Где это может помочь компании
Первый сценарий — перенос одного расчёта из старой внутренней программы в новый сервис. Например, итоговая стоимость заказа зависит от округления, минимальной партии и порядка применения скидок. Задача исследования — найти соответствующий участок и составить спецификацию: входы, формула, исключения, допустимые расхождения.
Агент может подготовить гипотезу и небольшую реализацию, а специалист — сравнить их с разрешённым эталонным запуском на обезличенных примерах. Приёмка включает нулевые и граничные значения, повторные операции, неверные входы и округление. Только после этого обсуждают подключение к новой системе. Это предлагаемый бизнес-сценарий, не заявленное внедрение REA или AI Office.
Второй сценарий — подготовка замены старого компонента интеграции. У компании осталась разрешённая к исследованию утилита, которая принимает файл и формирует выгрузку для учётной системы. REA может помочь разобраться в структуре приложения и связях, а наблюдение за тестовым запуском — уточнить реальный формат. Целью становится совместимая новая реализация по проверенной спецификации.
Связка с 1С здесь возможна как отдельная разработка: исследовать старый экспорт, описать поля, написать преобразование и проверить его на тестовой базе. Из этого не следует, что REA уже умеет анализировать любой закрытый модуль 1С или самостоятельно проводить документы. Рабочие правила учёта, интерфейс интеграции и приёмка остаются отдельными задачами.
Третий сценарий — выяснить, что изменилось между двумя версиями собственного приложения. Для .NET документация предусматривает сравнение членов сборок, а для JavaScript — сравнение графов приложений. Это может дать разработчику список мест, с которых стоит начать расследование регрессии. Статическое отличие помогает сузить поиск, но не устанавливает причину сбоя само по себе. REA · static .NET metadata, CIL and build comparisons ↗ REA · JavaScript application workflows and graph limitations ↗
| Задача | Результат пилота | Критерий приёмки |
|---|---|---|
| Перенести старый расчёт | Спецификация и отдельная реализация | Сравнение с эталоном на согласованных входах |
| Заменить компонент экспорта | Описание формата и тестовый преобразователь | Совпадение полей, сумм, ошибок и повторных операций |
| Разобрать регрессию версии | Карта различий и проверяемая гипотеза | Воспроизведение сбоя и тест исправления |
Локальный инструмент и локальная модель — разные настройки
REA анализирует файлы на машине пользователя, но результат получает ваш агент. Если он использует облачную модель, части псевдокода, строк или отчёта могут попасть к её провайдеру. README прямо разделяет локальный анализ REA и политику обработки данных провайдера модели. Фраза «работает локально» не описывает всю цепочку. REA · project overview and local-analysis FAQ ↗
Для внутреннего исследования можно спроектировать вариант с локальным анализатором, локальным агентом и моделью на AI-станции. Понадобится проверить поддержку MCP в выбранном клиенте, качество вызова инструментов, размер выдачи и способность модели аккуратно сохранять неизвестные места. Открытая модель с большим контекстом сама по себе этих качеств не гарантирует.
Станция класса 96–128 ГБ может быть одной из рассматриваемых платформ. В исследованных материалах нет испытаний этой конфигурации AI Office с REA, поэтому обещать скорость, размер анализируемого приложения или равенство с облачной моделью нельзя. Движок анализа и модель используют разные ресурсы; длинные отчёты ещё расходуют контекст и время проверки.
Практичный путь — давать модели ограниченный участок и сохранять полный отчёт отдельно. В документации есть представления и выборки из уже полученного Evidence, чтобы не передавать агенту весь массив сразу. Это полезный принцип и для локального, и для облачного варианта: следующему шагу нужны относящиеся к нему данные. REA · CLI, retained Evidence, views and source locations ↗
Что означает «бесплатно» и как выглядит настройка
Собственный код REA распространяется по MIT. Это не включает лицензию на Hopper, IDA или другие коммерческие инструменты и не оплачивает модель. В бюджете проекта остаются оборудование, возможные API-вызовы, работа инженера, тесты и сопровождение. Лицензия REA также не переносит права на исследуемую программу или её материалы. REA · MIT licence ↗ REA · authorised analysis, output rights and external-tool terms ↗
На дату проверки npm публиковал rea-agents 6.8.0. Официальная команда настройки выглядит так: REA · published v6.8.0 release, 25 October 2026 ↗
npx rea-agents setup
Мастер предлагает выбрать агентов, показывает изменения конфигурации и запрашивает их подтверждение; документация описывает резервные копии настроек. Затем агент нужно перезапустить. Для нативного анализа понадобятся соответствующий движок и его зависимости; Ghidra и Java не устанавливаются этой командой автоматически. REA · setup, dependencies and release/main distinction ↗
Важно сверять опубликованный пакет и документацию ветки main: проект развивается быстро, и одинаковая строка версии в исходниках не доказывает совпадение всех файлов с npm-пакетом. Для пилота сохраняют точные версии REA, движка и модели и проверяют фактический список доступных инструментов. Приведённая команда — справка, а не сообщение об установке на нашем сервере. REA · setup, dependencies and release/main distinction ↗
Почему красивое объяснение нужно проверять
У исходного пересказа есть разумное предостережение: агент способен ошибаться. Но по изученным материалам нельзя назначить универсальную точность для «простого» и «сложного» кода. Даже в показательном DX-Ball нужная формула не была полностью видна в первоначальном псевдокоде. Требовалось сопоставить несколько наблюдений и проверить реконструкцию. REA · DX-Ball evidence, 3,205 cases and 63-byte validation scope ↗
Полезно требовать от отчёта три отдельных ответа: что непосредственно обнаружено, какой вывод из этого сделан и чем его проверили. «Вызов разрешён анализатором» не означает «все возможные вызовы найдены». Статический путь не доказывает, что он выполняется в нужном сценарии. Ghidra-провайдер прямо сохраняет такие ограничения. REA · Ghidra provider semantics and analysis boundaries ↗
Есть и разница между чтением файла и запуском программы. Process Capture исполняет выбранную команду с правами пользователя и унаследованным окружением; пути наблюдения не ограничивают доступ процесса. Политика безопасности REA отдельно говорит, что его мосты и временные проекты не являются песочницей. Для незнакомых приложений среду исследования и доступ к данным проектируют отдельно. REA · process capture permissions and host limitations ↗ REA · security boundary: bridges are not a sandbox ↗
Для корпоративного пилота выбирают собственное ПО или согласованный объект исследования, убирают производственные секреты из тестовой среды и отдельно разрешают запуск, сетевые обращения и изменения. Ограниченный анализ не должен незаметно превращаться в работу с реальными клиентскими данными. Документация самого проекта также отделяет разрешённое исследование от копирования защищённого кода и обхода ограничений. REA · authorised analysis, output rights and external-tool terms ↗
С чего начать без большого проекта
Выберите одну функцию, которую действительно нужно понять: расчёт, экспорт или границу между компонентами. Зафиксируйте версию и контрольную сумму программы, доступные входы и ожидаемый результат. Попросите агента подготовить карту источников, гипотезу и список неизвестного. Затем проверьте поведение на контрольной выборке и закажите отдельную реализацию с тестами.
Пользу оценивают по времени инженера до принятой спецификации, числу исправленных предположений и доле совпавших проверок. При этом не каждое унаследованное приложение стоит исследовать: доступная документация, исходники или согласованный интерфейс поставщика могут решить задачу быстрее.
REA интересен как способ связать ИИ с наблюдениями о реальной программе. В AI Office можно разобрать конкретный процесс, подобрать локальную модель и спроектировать небольшой пилот: от одного разрешённого объекта исследования до проверяемого результата. Начать лучше с функции, потеря которой сейчас мешает развитию вашей системы.
