REA Investigated: How AI-Assisted Reverse Engineering Works

Какво е 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-асистираният анализ произведе Python версия на GNOME Calculator. Наред с видимите реконструкции като тази, по-тесни проекти сравняват преустроена калкулация директно с оригиналната.

Публична демонстрация — докладвана втора ръка
Реконструкцията приличаше на GNOME Calculator и съвпада с основен резултат от аритметика. Докладваните проблеми с преоразмеряване разкриха видимо несъответствие, което успешна проверка на аритметика не би уловила.

Реконструкция на функция, докладвана от проект
DX-Ball витрината докладва 3,205 случая на сравнение original-x86 за една функция за преобразуване позиция-в-звук, плюс съответстващи компилирани байтове, използвайки исторически компилатор.

Калкулаторът демонстрира видима реконструкция; DX-Ball документира проверки на специфична калкулация. Всеки резултат отговаря на различен въпрос.

За DX-Ball сравненията обхванаха позиции на екрана и няколко силни страни на панирането. Те провериха върнатите стойности на C функцията срещу тези от изпълнението на оригиналните инструкции. Компилирането на този C с исторически компилатор също възпроизведе байтовете на функцията. Това са две различни проверки: съгласие на тестваните резултати и съгласие на компилираната функция, без да се изисква оригиналният текст на програмиста.

GNOME Calculator също има разширени, финансови и програмни възможности. Простото сравнение на аритметика оставя тези функции неоценени, вместо да показва дали работят или се провалят в реконструкцията. Неговият източник е публичен, така че преглед на източника може да бъде по-преки начало, когато отговаря на вашия въпрос за поддръжка. Полезната прогресия е от визуално сходство към избрани проверки на поведение, след това систематични сравнения за поведението, което ви трябва.

Където обещанието за “всичко” достига своите граници

Липсата на контекст на източника може да направи компонента трудна за интерпретация. Оптимизацията може да скрие логиката му, докато обфускацията умишлено затруднява разбирането на кода. Външни зависимости създават още един пропуск: някои пътища на изпълнение имат нужда от входни данни, услуги или условия, недостъпни по време на разследване. Дори внимателният анализ може да остави неразрешени граничните случаи, когато функция разчита на поведение извън проверения компонент.

Независимо противотегло идва от докладът на Ishank Choudhary от 14 октомври 2026, обхващащ REA 6.4.0. Той намери полезна структура на Electron приложението, но пропусна preload връзките: кодът на моста, свързващ Electron страница със възможности на страната на десктопа. Той тества статични инструменти без агент или собствени двигатели за анализ; откритията се отнасят до това издание и работния процес, не до всяка текуща версия.

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

Усилието започва с настройка на двигателя за анализ и осигуряване на необходимата му изчислителна мощност и памет. Използването на модел носи свои съображения: контекстът определя колко материал може да разгледа наведнъж, докато токените са единиците текст, които обработва. Повторени заявки добавят усилие, последвано от тестване и човешки поправки след първия резултат. Действителните сметки, нужди на хардуера и времена за завършване зависят от целта и въпроса. Измерването на собственото допринесение на REA към скорост или качество би изискало контролирано сравнение.

Полезни приложения отвъд копирането на приложение

За разработчици, self-hosters и екипи за миграция, стойността често се крие в отговора на конкретен въпрос за поддръжка или съвместимост. Следните сценарии са илюстративни, а не тестирани внедрения или резултати от този издател.

🛠️ Разработчик / поддържащ

Поддържащ, който сравнява две разрешени версии на наследено приложение, може да попита защо резултатът от импортиране се е променил. REA може да помогне да се намери логиката на анализиране и да се ръководи регресионни проверки. Ако пълният изходен код вече отговаря на този въпрос, започнете от там; в противен случай валидирайте предполагаемата причина спрямо променилото се поведение.

🏠 Self-hoster

Self-hoster, работещ със стар локален формат на файл, може да използва REA, за да разбере неговите полета. Тези находки могат да помогнат при дефиниране на независимо внедрен мост за съвместимост. Законно, drop-in заместител на собственическата зависимост все още ще изисква тестване на недокументирани случаи и проверка на приложимите права.

💼 Бизнес / екип за миграция

Екип за миграция може да трябва да знае дали необходимото поведение при експортиране може да бъде поддържано преди да поръча внедрението. REA може да помогне да се установи техническа осъществимост и да се уточни какво трябва да бъде построено. Това намиране може да информира решение за инвестиция, докато оценките на доставката, ангажименти за поддръжка и пълна съвместимост изискват допълнителна оценка.

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

Техническият достъп не решава авторизацията, поверителността или доверието

Разрешението за проверка на файл може да се различава от разрешението да го изпълните, наблюдавате неговия трафик, публикувате находки или преизползвате защитен материал. Правата зависят от приложимото законодателство и договори: условните права на взаимодействие, включително тези в САЩ, не са световни правила, а притежаването на копие не упълномощава всяка операция.

MIT лицензът на REA обхваща кода, написан от REA, а не целевите приложения, защитени активи или автоматично генериран резултат. Търговските двигатели за анализ имат нужда от собствени лицензи. Отказът от отговорност за отговорна употреба определя предвидените употреби и границите на поддръжката на общността без изменение на MIT; възстановеният код не автоматично става с отворен код или преразпределяем.

⚠️ Предупреждение: Рискове за поверителност и изпълнение

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

Използвайте официални пакетни и актуализационни източници, но също така преглеждайте зависимостите, генериран резултат, собственост на поддръжката и как пристигат поправките. Приложете същата проверка на софтуера на доставчика, проекти с отворен код и AI-генерирани алтернативи: официално произход, цена, наличност на код или изграждане от код не могат да заменят ясна проследяемост и история на преглед.

Какво означава 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

Граница на видимост, не пълна граница на сигурност: ресурсите на браузъра и отговорите могат да бъдат проверени; кодът на backend обикновено остава отдалечен. Разкритите данни и други проблеми със сигурността остават възможни.

Тези API отговори—данни, обменени със услугата—могат да разкрият достатъчно за поведението на функция, за да информират нова реализация. Този маршрут разчита на наблюдаеми входове и изходи, а не на достъп до кода на backend. Поддържането на кода отдалечено също не елиминира грешки, разкрити данни или възможността за упълномощено разследване.

С SaaS, софтуер като услуга, продавач управлява приложението.

• Самостоятелното хостване на упълномощено приложение ви дава повече контрол над разгръщането. Тогава вие поемате отговорност за закърпяване и управление на достъпа.
• Резервните копия, мониторингът и възстановяването също стават част от поддържането на това приложение в работно състояние.

AlexHost Ubuntu VPS е една опция за инфраструктура за преглеждано приложение или мост за съвместимост. Пълният root достъп ви дава контрол над гостната операционна система. Това не защитава приложението автоматично и не прави външната обработка на модели частна.

Основният извод: по-лесно разследване, не автоматично възстановяване

Разпознаваемо прозорче на калкулатор може да бъде обещаващ първи резултат. Следващите въпроси са дали поведението, което ви трябва, е проверено и кой ще го поддържа. REA помага при разследването на това поведение; внедряването, проверката и надеждната работа остават отделна работа.

За по-задълбочено четене, започнете с официалния REA проект и неговата демонстрация DX-Ball. Фокусирайте се на един малък, одобрен въпрос и доказателствата зад отговора. Това е по-полезна отправна точка, отколкото да питате дали AI може да копира цял продукт.