REA Investigated: Як працює зворотна інженерія з допомогою AI

Що таке REA—і чому люди звертають на це увагу?

Ви можете використовувати додаток щодня, не знаючи, як його функції працюють під поверхнею. REA дає AI асистентам спосіб дослідити цю поведінку—навіть коли вихідний код недоступний.

REA (Reverse Engineer Anything) — це проект з відкритим вихідним кодом на morluto/rea, який підключає AI агентів до робочих процесів аналізу програмного забезпечення. Він надає доступ до операцій аналізу через інтерфейс командного рядка—типізовані команди терміналу—та сервер інструментів для сумісних AI додатків. Агент — це AI додаток, який може використовувати інструменти в багатокроковому завданні. REA надає доступ до інструментів аналізу, а не до базової AI моделі.

Це розрізнення важливе: дослідження готового додатку, написання подібної реалізації та відновлення його вихідного коду — це різні досягнення. Корисність REA залежить від зібраних доказів, застосованих перевірок та залишених відповідальностей. “Anything” — це назва проекту, а не гарантія того, що кожен продукт можна вірно відтворити.

Зворотна інженерія: навчання на основі готової програми

Зворотна інженерія означає вивчення того, як щось працює, шляхом дослідження готового результату. Подумайте про машину без її оригінальних креслень: огляд її частин і поведінки може підтримати новий дизайн, але не дає вам оригінальних креслень конструктора. Аналогічно, розуміння поведінки програмного забезпечення не відновлює вихідний код, який написали його розробники.

Для нативного виконуваного файлу, форми програми, готової до процесора, компілятор перекладає вихідний код у машинні інструкції. Це операції, які розуміє процесор. Компіляція також може оптимізувати програму, переставляючи або комбінуючи роботу, зберігаючи її призначену поведінку. Результат — виконуване програмне забезпечення, а не стиснений архів вихідного проекту.

Дизасемблювання представляє машинні інструкції як читаємий асемблер. Декомпіляція йде далі, виводячи логіку вищого рівня, подібну до вихідного коду, яка називається псевдокодом. Такі інструменти як Ghidra надають обидва представлення:

1) Forward production path:
Original source
       ↓
Compile / optimize
       ↓
Native executable

2) Separate analysis path:
Native executable
       ↓
Disassembly / decompilation
       ↓
Assembly / inferred pseudocode
  Original names, comments and structure may be missing
       ↓
Behavior to verify

Випадок нативного коду: компіляція створює виконуваний файл; аналіз виводить читаємий вигляд і поведінку для перевірки. Немає гарантованого зворотного шляху до оригінальних вихідних файлів.

Втрата інформації нерівномірна. Коментарі та багато імен можуть зникнути, тоді як текстові рядки, деякі імена та описові метадані залишаються. Оптимізація може зробити знайомі структури вихідного коду важко впізнаваними. Різні реалізації вихідного коду також можуть створювати подібну машинну поведінку, тому правдоподібна реконструкція не повинна відповідати оригінальному виразу програміста.

Не кожна програма — це нативний машинний код. Упакований JavaScript може містити читаємий вихідний код або мініфікований код, скорочений для розповсюдження. Читання матеріалу, подібного до вихідного коду, який уже присутній у пакеті, відрізняється від виведення псевдокоду з машинних інструкцій. Те, що залишається, визначає, на які питання аналіз може відповісти.

Як REA перетворює запитання на цикл доказів

Дослідження DX-Ball проекту почалося з практичного запитання: як горизонтальна позиція цегли на екрані визначає панорамування звуку, баланс між лівим і правим аудіо? Перший вигляд декомпілятора показав виклик, який перетворював число, але опустив вхідні дані та розрахунок за ним. Цього було недостатньо, щоб пояснити позицію звуку.

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

Результатом було конкретне правило: при звичайному масштабі центр екрана відповідає центрованому панорамуванню, тоді як позиції з обох боків зміщують баланс вліво або вправо. Проект реконструкції міг тоді написати це правило на C і порівняти його з оригінальною функцією.

Чотири ролі роблять це дослідження можливим.

• Ви встановлюєте авторизоване запитання.
• Агент вибирає подальші кроки та інтерпретує результати.
• REA надає доступ до інструментів і повертає докази.
• Механізм аналізу або парсер перевіряє цільовий артефакт — файл або пакет, який досліджується.

Вбудовані механізми включають Ghidra, Hopper та IDA.

З’єднання використовує Model Context Protocol (MCP), стандартний спосіб для AI-додатків досягти зовнішніх інструментів і систем. MCP-сервер REA — це програмне забезпечення, яке розкриває ці операції, а не машина, яку ви повинні орендувати. Навичка надає інструкції дослідження для агента; сервер надає доступ до самих операцій. Основний обмін виглядає так:

Your feature question
         ↓
Agent
         ↕ MCP
REA tool server
         ↕
Analysis engine / parser
         ↕
Target software

Запити рухаються до цілі; докази повертаються до агента, який використовує їх для вибору наступного запитання. Обмін повторюється в міру розвитку дослідження.

Агент координує ці подальші кроки та з’єднує повернений код і посилання в пояснення. Записи доказів визначають місцезнаходження файлу та коду, розділяючи спостереження від висновків і невирішених результатів. Рецензент тому може простежити пояснення назад до його підтримуючого матеріалу. Агент також може розробити кандидатський код і тести як окремий крок від встановлення того, що робить оригінал.

Для будь-якої цілі розрізняйте статичну перевірку, яка читає артефакти без запуску програми, від спостереження під час виконання або взаємодії, яка досліджує її під час запуску. Місце, де відбувається ця перевірка, також відокремлено від місця, де модель обробляє свої результати. Якщо агент використовує розміщену модель, повернені результати можуть залишити машину аналізу.

Які види програмного забезпечення може інспектувати REA?

Видимість залежить від цілі. Electron упаковує настільне програмне забезпечення за допомогою веб-технологій, тоді як .NET та Android представляють окремі сімейства застосунків з різними шляхами аналізу. Кожна розкриває різну інформацію, як показує таблиця:

REA документує ширше охоплення артефактів за межами цих категорій. Перевірте офіційний огляд цілей та поточну документацію: вимоги різняться залежно від механізму, платформи хостингу, цілі та випуску. Вони описують доступні робочі процеси інспекції, а не перевірені реконструкції кожної цілі.

Переконливе демо — це не перевірена реконструкція

Публічні демонстрації дають більш конкретне уявлення про те, що може робити REA. В одній демонстрації калькулятора, поділеній в інтернеті, AI-асистований аналіз створив версію GNOME Calculator на Python. Поряд з видимими реконструкціями, як ця, вужчі проекти порівнюють перебудований розрахунок безпосередньо з оригіналом.

Публічна демонстрація — повідомлено з другої руки
Реконструкція нагадувала GNOME Calculator і збігалася з результатом базової арифметики. Повідомлені проблеми зі зміною розміру виявили видиму невідповідність, яку успішна перевірка арифметики не виявила б.

Реконструкція функції, повідомлена проектом
Демонстрація DX-Ball повідомляє про 3,205 випадків порівняння оригінального x86 для однієї функції перетворення позиції на звуковий панораму, плюс збіг скомпільованих байтів за допомогою історичного компілятора.

Калькулятор демонструє видиму реконструкцію; DX-Ball документує перевірки конкретного розрахунку. Кожен результат відповідає на різне питання.

Для DX-Ball порівняння охоплювали позиції екрана та кілька сил панорами. Вони перевіряли значення, що повертаються функцією C, порівнюючи їх з результатами виконання оригінальних інструкцій. Компіляція цього C з історичним компілятором також відтворила байти функції. Це дві окремі перевірки: збіг на протестованих виходах і збіг на скомпільованій функції, без необхідності в оригінальному вихідному тексті програміста.

GNOME Calculator також має розширені, фінансові та програмістські можливості. Просте порівняння арифметики залишає ці функції неоціненими, замість того щоб показати, працюють вони чи ні в реконструкції. Його вихідний код є публічним, тому огляд вихідного коду може бути більш прямим початком, коли він відповідає на ваше питання про обслуговування. Корисна послідовність — від зовнішньої схожості до перевірок вибраної поведінки, потім систематичні порівняння для поведінки, яка вам потрібна.

Де обіцянка “всього” досягає своїх меж

Відсутність контексту джерела може ускладнити інтерпретацію компонента. Оптимізація може затьмарити його логіку, тоді як обфускація навмисне ускладнює розуміння коду. Зовнішні залежності створюють ще один розрив: деякі шляхи виконання потребують входів, сервісів або умов, недоступних під час дослідження. Навіть ретельний аналіз може залишити граничні випадки невирішеними, коли функція залежить від поведінки поза межами досліджуваного компонента.

Незалежний противага походить від звіту Ішанка Чоудхарі від 14 жовтня 2026 року, що охоплює REA 6.4.0. Він знайшов корисну структуру Electron додатку, але пропустив preload з’єднання: код мосту, що пов’язує сторінку Electron з можливостями на стороні desktop. Він тестував статичні інструменти без агента або рідних механізмів аналізу; висновки стосуються цього випуску та робочого процесу, а не кожної поточної версії.

Звіт також описав відносини, опущені з резюме додатку через бюджети результатів—обмеження на збережений вихід. Деякі факти залишилися на рівні файлу без того, щоб їхні з’єднання з’явилися в резюме. Завершене сканування без збігу тому означало, що збережений аналіз не знайшов відносину, а не те, що функція була відсутня. Його обмеження охоплення пояснили пропуск.

Зусилля починаються з налаштування механізму аналізу та забезпечення обчислювальної потужності та пам’яті, які йому потрібні. Використання моделі несе свої міркування: контекст визначає, скільки матеріалу вона може розглянути одночасно, тоді як токени — це одиниці тексту, який вона обробляє. Повторні запити додають зусилля, за якими слідує тестування та людські виправлення після першого виходу. Фактичні рахунки, потреби в обладнанні та часи завершення залежать від цілі та питання. Вимірювання власного внеску REA в швидкість або якість потребувало б контрольованого порівняння.

Корисні застосування за межами копіювання додатка

Для розробників, самохостерів та команд міграції цінність часто полягає у відповіді на конкретне питання обслуговування або сумісності. Наступні сценарії є ілюстративними, а не перевіреними розгортаннями або результатами від цього видавця.

🛠️ Розробник / супроводжувач

Супроводжувач, який порівнює дві авторизовані версії застарілої утиліти, може запитати, чому змінився результат імпорту. REA може допомогти знайти логіку парсингу та керувати перевірками регресії. Якщо повний вихідний код вже відповідає на це питання, почніть звідти; інакше перевірте передбачену причину проти змінено поведінки.

🏠 Самохостер

Самохостер, який працює зі старим локальним форматом файлу, може використовувати REA для розуміння його полів. Ці висновки можуть допомогти визначити незалежно реалізований міст сумісності. Законний, готовий до використання замінник власної залежності все ще потребуватиме тестування недокументованих випадків та перевірки застосовних прав.

💼 Бізнес / команда міграції

Команді міграції може знадобитися дізнатися, чи можна підтримати необхідну поведінку експорту перед замовленням реалізації. REA може допомогти встановити технічну здійсненність та уточнити, що потрібно будувати. Цей висновок може інформувати інвестиційне рішення, тоді як оцінки доставки, зобов’язання щодо підтримки та повна сумісність потребують подальшої оцінки.

Освіта та авторизовані дослідження безпеки можуть використовувати той самий підхід. Перш ніж переходити від пояснення до подальших дій, визначте, що може бути перевірено, запущено або поділено. Цей обсяг керує розслідуванням навіть коли технічне питання здається простим.

Технічний доступ не вирішує авторизацію, конфіденційність або довіру

Дозвіл на перевірку файлу може відрізнятися від дозволу на його запуск, спостереження за його трафіком, публікацію результатів або повторне використання захищеного матеріалу. Права залежать від чинного законодавства та контрактів: умовні права на взаємодію, включаючи ті, що існують у США, не є світовими правилами, а володіння копією не дозволяє кожну операцію.

MIT ліцензія REA охоплює код, написаний REA, а не цільові додатки, захищені активи або автоматично згенеровані результати. Комерційні механізми аналізу потребують власних ліцензій. Відмова від відповідальності щодо відповідального використання визначає передбачені способи використання та межі підтримки спільноти без змін MIT; відновлений вихідний код не автоматично стає відкритим кодом або придатним для розповсюдження.

⚠️ Попередження: ризики конфіденційності та виконання

Локальний аналіз може надсилати результати — включаючи код, облікові дані або персональні дані — постачальнику моделі агента. Перевірте вихідні дані та умови постачальника перед аналізом конфіденційних цілей. REA не є пісочницею: статичний аналіз може виявити вразливості інструменту, тоді як запуск або взаємодія з цілями можуть змінити файли або вплинути на облікові записи та сервіси. Перегляньте фактичні операції та ізоляцію, а не лише те, де запускаються інструменти.

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

Що REA означає для власності програмного забезпечення та хмари

Реконструювання програмного забезпечення один раз не фінансує його майбутнє. Хтось повинен постійно виправляти вразливості та зберігати сумісність. Підтримка користувачів та розвиток продукту також вимагають постійної роботи. Більш доступне дослідження може доповнювати експертну роботу; ці приклади не показують, що розробники або платне програмне забезпечення стають застарілими. Надійні оновлення та відповідальна підтримка залишаються причинами для вибору продукту, навіть коли його реалізація стає легшою для розуміння.

Постачальники могли б відповісти, перемістивши більше функціональності на віддалену доставку, але наведені тут докази не встановлюють тенденцію, керовану REA. Технічна різниця полягає в клієнті та сервері: браузер отримує код інтерфейсу та відповіді, тоді як реалізація на стороні сервера зазвичай залишається у оператора.

Browser / client: delivered UI and scripts
Inspectable to the extent delivered / authorized
                   ↕
           Requests / responses
                   ↕
Server: application logic and database
Behavior observed ≠ exact private source revealed

Межа видимості, а не повна межа безпеки: ресурси браузера та відповіді можна перевірити; код бекенду зазвичай залишається віддаленим. Виявлення даних та інші проблеми безпеки залишаються можливими.

Ці відповіді API—дані, обмінені з сервісом—можуть розкрити достатньо про поведінку функції, щоб інформувати нову реалізацію. Цей маршрут спирається на спостережувані входи та виходи, а не на доступ до коду бекенду. Збереження коду віддаленим також не усуває помилки, виявлення даних або можливість авторизованого дослідження.

З SaaS, програмним забезпеченням як послугою, постачальник керує програмою.

• Самостійне розміщення авторизованої програми дає вам більше контролю над розгортанням. Тоді ви беретеся на себе відповідальність за виправлення та управління доступом.
• Резервні копії, моніторинг та відновлення також стають частиною утримання цієї програми в роботі.

AlexHost Ubuntu VPS є одним варіантом інфраструктури для перевіреної програми або мосту сумісності. Повний доступ root дає вам контроль над гостьовою операційною системою. Це не забезпечує програму автоматично та не робить зовнішню обробку моделей приватною.

Висновок: легша розслідування, а не автоматичне відновлення

Впізнаване вікно калькулятора може бути обіцяючим першим результатом. Наступні питання полягають у тому, чи була перевірена необхідна вам поведінка та хто її підтримуватиме. REA допомагає розслідувати цю поведінку; реалізація, перевірка та надійна робота залишаються окремою роботою.

Для глибшого вивчення почніть з офіційного проекту REA та його демонстрації DX-Ball. Зосередьтеся на одному невеликому, авторизованому питанні та доказах, що стоять за відповіддю. Це більш корисна відправна точка, ніж запитання про те, чи може штучний інтелект скопіювати весь продукт.