REA может составить карту локального JavaScript- или Electron-приложения по файлам, которые вам разрешено проверять, даже если у вас нет дерева исходного кода. Полезный результат — цепочка доказательств для одного поведения: какой модуль его предоставляет, где вызов пересекает границу процесса и какие части требуют отдельной проверки. В этом руководстве используется актуальная документация проекта REA, проверенная 14 октября 2026 года. BIG CHANGE не запускал REA на каком-либо приложении.

Главное изменение

  • Что изменилось: REA предоставляет агенту для программирования структурированную карту модулей, импортов, карт исходного кода, маршрутов и Electron IPC по заданному каталогу приложения или архиву ASAR. Каждый результат может указывать на файлы, которые послужили его основанием.
  • Почему это важно: Разработчик, исследующий одну функцию, может проследить именованный API или канал IPC в упакованном приложении и затем решить, что проверять вручную. Вопрос становится конкретнее, а доказательства проще проверить.
  • На что обратить внимание: Статические пути в коде — это возможные варианты, а не доказательство того, что приложение использует их во время работы. Утверждение о конкретном поведении всё равно требует независимого наблюдения или теста на разрешённой цели.

Перед началом

Это руководство предназначено для разработчика, который владеет локальным JavaScript- или Electron-приложением либо имеет разрешение его проверять. Вам понадобится извлечённый каталог приложения или его app.asar файл и абсолютный путь к нему. В манифесте пакета REA указана rea-agents версия 6.4.0 и требуются Node.js 22.19 или новее в ветке 22.x, 24.11 или новее в ветке 24.x либо версия 26 и выше. Также нужен npm. В Linux для статического анализа JavaScript/Electron средствами REA требуется совместимый с procps ps в REA PATH для проверки владельца процесса, как указано в руководстве по установке. Это требования к хосту REA; они отличаются от требований к запуску целевого приложения.

Для статического анализа JavaScript не нужны Hopper, Ghidra, IDA, браузер или запущенный процесс Electron. Эти инструменты относятся к другим сценариям REA. Убедитесь, что вам разрешено проверять цель, и сохраните копию исходных файлов, чтобы точно определить, какой артефакт дал результат. Для установки используйте официальный morluto/rea репозиторий или связанный с ним npm-пакет; похожее название репозитория само по себе не подтверждает происхождение.

1. Настройте REA или используйте CLI для одного запуска

Для подключённого агента для программирования используется документированная команда настройки:

Terminal
npx rea-agents setup

Просмотрите предлагаемые изменения конфигурации агента, одобрите нужные и перезапустите агента. Если нужен только анализ из терминала, приведённая ниже документированная команда запускает пакет для одного такого запуска. @latest выбирает версию, актуальную на момент запуска; запишите фактически выбранную версию вместе с доказательствами, поскольку детали вывода могут меняться. Версия 6.4.0 выше — та, что была указана в манифесте проекта при проверке этой статьи 14 октября.

2. Проанализируйте предоставленные файлы

Замените пример абсолютным путём к разрешённой для проверки папке приложения или архиву ASAR:

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

Руководство по CLI предупреждает, что полный Evidence может быть очень большим. Сохраните его в файл, а затем изучите сводку или представление выбранного модуля. Не вставляйте весь результат в запрос. При сбое команды сохраните ошибку и путь к цели для диагностики: нулевой код завершения всё ещё может сопровождаться неполным покрытием, предупреждениями или нерешёнными находками. В README для Windows приведён путь, например "D:/apps/example".

Справочник по реконструкции артефактов указывает, что операция читает выбранные файлы как данные, не запуская приложение. Она составляет перечень путей артефактов и их дайджестов, анализирует доступный JavaScript и TypeScript, а также сообщает о возможных точках входа, импортах, картах исходного кода, маршрутах, сетевых конечных точках, связях Electron preload и renderer, contextBridge API, вызовах и обработчиках IPC, а также запросах к нативным дополнениям. Ожидаемый результат — запись Evidence с графом, статической сводкой Electron, охватом и ограничениями. Обнаруженная .node связь — это отношение для проверки, а не декодирование этого нативного модуля.

3. Проследите одну конкретную функцию

Выберите функцию с известным названием, например действие меню или открытый API-метод. Запишите название, которое видит пользователь, и найдите в результатах REA соответствующий модуль, буквальный канал IPC или маршрут. Последовательно пройдите по указанным исходным позициям: вызов renderer или страницы, мост preload, передача IPC, соответствующий обработчик главного процесса, затем файл или операцию сервиса, которую он вызывает. Пример REA с Electron CSV показывает этот шаблон с notes.exportCsv(), notes:export канал и запись в главном процессе. Эти имена относятся к примеру, а в вашей цели будут другими.

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

4. Независимо проверьте поведение

Сформулируйте одно опровержимое утверждение по статической цепочке, например: «это действие вызывает этот канал, а обработчик записывает файл такого типа». Затем в одобренной тестовой среде выполните только это действие и непосредственно наблюдайте результат: созданный файл, изменённое состояние или трассировку, собранную в рамках ваших полномочий. Запишите версию приложения, дайджест артефакта, шаги теста и наблюдаемый результат. Если запуск приложения выходит за пределы ваших полномочий, ограничьте утверждение статическим путём в коде. В примере REA прямо сказано, что предполагаемый путь можно проверить записью во время выполнения; одна статическая схема не показывает, какая ветвь сработала.

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

Если результат неполный

Сначала проверьте, что путь ведёт к полностью извлечённому каталогу или архиву ASAR и что на месте все необходимые дополнительные .asar.unpacked файлы. Изучите охват и диагностику REA: отсутствующий или неудачно обработанный источник означает, что результат неизвестен, а не отрицателен. Для большого приложения справочник описывает точный выбор --source-path файлов, однако неизбранные файлы останутся за пределами анализа. Если буквальное совпадение IPC неоднозначно или канал вычисляется, изучите указанные файлы и сузьте вопрос. Если неоднозначность останется, укажите её в итоговых примечаниях.

Код REA распространяется по лицензии MIT, однако у целевого ПО и внешнего механизма анализа свои лицензии и условия. Статический анализ обрабатывает файлы цели локально. Если передать результаты REA агенту для программирования, будет действовать политика данных поставщика модели; не отправляйте секреты или закрытые результаты без разрешения организации. До использования проверьте условия и стоимость агента и любых дополнительных механизмов. Процедура и версия пакета проверены 14 октября 2026 года и основаны на документации.