Как реверс-инжинирить что угодно с помощью Opus 5.5 (Полный курс)

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

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

Этот курс из 11 шагов превратит Claude Opus 5.5 в машину по созданию open-source аналогов чего угодно.

Подписывайтесь на мой Substack, чтобы получать свежую AI-альфу:

movez.substack.com

Реверс-инжиниринг — это не про взлом. Это про то, чтобы понять вещь настолько хорошо, чтобы создать свою собственную.

7 октября 2026 года Амджад Масад (Amjad Masad), CEO Replit, опубликовал всего одну строку:

https://x.com/amasad/status/2107671204639465961

под ней разработчик под ником @morluto ответил пруфами: набором инструментов, которые позволяют агентам управлять Hopper и Ghidra и заходить очень далеко.

Этот проект называется REA, и за считанные дни он собрал 110 000 звезд на GitHub.

https://github.com/morluto/rea

И это не просто хайп. На той же неделе open-source проект WordCraft выпустил clean-room пересборку Microsoft и Adobe на чистом Rust:

https://getartcraft.com/apps

Его создали, наблюдая за поведением Word и Adobe и читая публичные спецификации форматов файлов, ни разу не заглядывая в их код.

Этот курс покажет тебе весь путь от закрытого бинарника до подобной пересборки, где всю тяжелую работу по чтению выполняет Opus 5.5.

01. Движок - как агент читает бинарник

Opus 5.5 не может запустить дизассемблер самостоятельно. Он читает текст и пишет текст.

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

Этот инструмент — REA, а под капотом у него работает Hopper, Ghidra или IDA.

Цикл прост и постоянно повторяется: модель просит REA изучить цель, REA возвращает результаты с точными доказательствами (адреса, байты, псевдокод, места вызовов), а модель использует эти данные, чтобы задать следующий вопрос или написать и протестировать реимплементацию.

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

**

02. Установка - rea-agents плюс один дизассемблер

Настройка регистрирует MCP-сервер REA в твоем агенте и устанавливает соответствующие инструкции для рабочего процесса.

Всё делается одной командой: она показывает каждое изменение до того, как что-то записать, и делает бэкап всего, к чему прикасается.

Дизассемблер ты выбираешь сам: Hopper на macOS — самый простой путь, Ghidra бесплатна и кроссплатформенна, а IDA подойдет, если она у тебя уже есть.

1# 1. Зарегистрируйте REA в вашем агенте (Claude Code, Codex, Cursor, Gemini CLI...)
2npx rea-agents setup            # показывает планируемые изменения, спрашивает перед записью
3
4# 2. Провайдер глубокого анализа. Hopper работает лучше всего на macOS;
5#    setup может установить его после вашего подтверждения. Ghidra и IDA нужно устанавливать самостоятельно.
6# 3. Установите CLI rea для работы в терминале и написания скриптов
7npm install --global rea-agents
8rea --help
9
10# 4. Перезапустите ваш агент, затем убедитесь, что инструменты работают
11claude
12> /mcp
13  rea: connected
14    open_binary, binary_overview, analyze_function, decompile,
15    list_procedures, search, xrefs, trace, inspect_artifact,
16    analyze_javascript_application, inspect_managed_artifact ...

Требования скромные: Node.js 22 или новее и npm. Для нативного анализа нужен один из трех движков; статический анализ JavaScript и .NET не требует движка вообще. Обновляйте REA, так как релизы выходят часто и содержат много исправлений.

1# Правила дома для реверс-инжиниринга ( CLAUDE.MD )
2
3## Полномочия
4- Анализируйте только те цели, которыми я владею или на изучение которых у меня есть разрешение. Обоснуйте это один раз.
5- Каждое утверждение должно иметь тег: observation (увидел), inference (вывел логически) или unknown (неизвестно).
6- Ссылайтесь на доказательства: адрес, байты, псевдокод или место вызова. Никаких голословных заявлений.
7
8## Рабочий процесс
9- Начинайте с самого краткого обзора, а не с полного дампа. Углубляйтесь только при наличии конкретного пробела.
10- Используйте открытую сессию повторно; никогда не запускайте идентичный анализ заново.
11- Отделяйте статические факты от рантайм-фактов. Никогда не делайте выводов о выполнении программы на основе статического чтения.
12
13## Реконструкция
14- Стройте на основе ПОВЕДЕНИЯ и публичных спецификаций, никогда — на основе скопированного кода или ресурсов.
15- Ведите реестр обязательств: каждое восстановленное поведение требует прохождения теста, прежде чем задача будет считаться "выполненной".

У Opus 5.5 есть пять уровней усилий (effort): low, medium, high, xhigh и max. Используй:

• Medium для изучения и навигации
• High для аннотирования обычных функций
• Max для обфусцированного кода и всего, где много сложной математики с указателями.

Уровень усилий — это главная ручка настройки качества во всем этом курсе.

03. Маршрутизатор - 20 типов целей, по одному инструменту на каждую

Первая ошибка новичков — хвататься за дизассемблер, когда цель представляет собой Electron-приложение, JavaScript которого лежит прямо на виду.

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

1Я хочу понять, как работает [ФУНКЦИЯ] в [ПРИЛОЖЕНИЕ], которое находится по пути [АБСОЛЮТНЫЙ ПУТЬ].
2
3Сначала скажи мне, что это за тип цели (native, Electron/JS, .NET, Go, APK, WASM)
4и выбери подходящий инструмент REA, чтобы её открыть. Пока не начинай глубокий анализ.
5
6Затем дай мне обзор в один абзац: на чем собрано приложение, какого оно размера и
7где бы ты в первую очередь искал [ФУНКЦИЯ]. Разделяй наблюдения, умозаключения и неизвестные факты,
8и приводи доказательства для любых своих утверждений.

Если направить REA на Electron-приложение, он за секунды вернет модули, импорты и границы IPC вообще без использования дизассемблера.

Если направить его на нативный Mach-O или ELF, он откроет базу данных Hopper и даст тебе более сложный, но глубокий нативный путь. Понимание того, с чем именно ты работаешь, экономит часы.

https://x.com/_vmlops/status/2106690704244420687

04. Разведка - обзор, строки и граф вызовов

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

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

1rea.open_binary        { path: "/Applications/Target.app/Contents/MacOS/Target" }
2rea.binary_overview    {}
3  arch:        arm64
4  functions:   1,284 identified
5  segments:    __TEXT __DATA __LINKEDIT
6  entry:       _main @ 0x1000051c0
7
8rea.search             { query: "http" }  # strings + code refs
9  0x10004a2c0  "https://api.target.app/v3/sync"
10  0x10004a300  "Authorization: Bearer "
11  0x10004a330  "offline cache miss, falling back"
12
13rea.xrefs              { address: "0x100012ab0" }  # who calls this?
14  147 references  ->  core config loader, called everywhere

REA также считает, сколько раз вызывается каждая функция (это число называется количеством перекрестных ссылок, или xrefs).

Функция, которую вызывают 147 раз — это сердце приложения, и она заслуживает твоих максимальных усилий. Та, что вызывается дважды — мелкий хелпер, о котором можно забыть, пока он не понадобится. Начинай с вершины этого списка и двигайся вниз.

05. Декомпиляция - одна функция в псевдокод

Теперь выбери одну из этих «занятых» функций и преврати её во что-то читаемое. Декомпилятор берет сырые машинные инструкции и переписывает их в код, близкий к C.

Выглядит грубовато: имена вроде var_28, запутанная логика, приведения типов повсюду. Но это можно читать, а читабельность — это всё, что нужно Opus 5.5.

Запускай его из командной строки, чтобы сохранить результат, или прямо из чата.

1# Декомпилируйте одну функцию по адресу в формате JSON, который можно передать через pipe или сохранить
2rea decompile /Applications/Target.app/.../Target 0x100012ab0 \
3  --provider hopper --json > fn_config_loader.json
4
5# Или найдите функцию по имени и пройдитесь по ссылкам
6rea function /path/to/Target parseConfig --provider hopper --json
7rea xrefs    /path/to/Target 0x100012ab0 --provider hopper --json
8rea trace    /path/to/Target "sync" --provider hopper --json

1// 0x100012ab0  xrefs: 147
2void sub_100012ab0(void* arg0) {
3    void* var_20 = objc_msgSend(cls_NSJSONSerialization,
4        sel_JSONObjectWithData_options_error, arg0, 0x0, 0x0);
5    if (var_20 != 0x0) {
6        void* var_28 = objc_msgSend(var_20, sel_objectForKey, @"endpoints");
7        void* var_30 = objc_msgSend(var_20, sel_objectForKey, @"auth_mode");
8        void* var_38 = objc_msgSend(var_20, sel_objectForKey, @"retry_count");
9        objc_msgSend(g_sharedConfig, sel_setEndpoints, var_28);
10        objc_msgSend(g_sharedConfig, sel_setAuthMode, var_30);
11        objc_msgSend(g_sharedConfig, sel_setRetryCount,
12            objc_msgSend(var_38, sel_intValue));
13    }
14}

В собственном шоукейсе REA отслеживает звуковой вызов в старой игре DX-Ball вплоть до хелпера, который определяет баланс звука между левым и правым каналами, а затем превращает недоделанный псевдокод в C.

Результат проходит все 3 205 оригинальных тестов и воспроизводит каждый из 63 скомпилированных байтов.

Полный разбор доступен на rea.tools/showcase.

06. Аннотация - заставь Opus назвать каждую переменную

Этот сырой код — только половина дела. Теперь передай его Opus 5.5 и попроси объяснить и привести в порядок.

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

Вставьте этот промпт в чат с Claude:

1Вот декомпилированный псевдокод функции со 147 перекрестными ссылками.
2
3Для этой функции:
41. Переименуй каждую переменную в осмысленное имя, основываясь на том, как она используется.
52. Опиши её назначение в одном предложении.
63. Перечисли структуры данных, которые она читает и записывает.
74. Назови паттерн (синглтон, фабрика, конечный автомат, наблюдатель...).
85. Перепиши её в виде чистого, идиоматичного Swift (или языка, на который указывают
9   соглашения о вызовах), с doc-комментариями.
106. Отметь любую отсутствующую обработку ошибок, валидацию ввода или проверку безопасности.
11
12Продумай всё на уровне усилий xhigh, прежде чем отвечать: разберись, чем является каждое
13значение, прежде чем давать имена. Помечай всё, в чем ты не уверен.
14
15[вставьте псевдокод]

Декомпиляция показывает, что делает код. Opus 5.5 объясняет, почему, и дает имена, необходимые для пересборки.

https://x.com/0x0SojalSec/status/2108389060192706674

https://x.com/0x0SojalSec/status/2108031166502896035

Не каждой цели нужен дизассемблер. В шоукейсе Notion от REA функция работы с буфером обмена находится в JavaScript приложения, прослеживается через слои Electron в главный процесс, и детально показывается, как создается rich clipboard — полная трассировка без единой строчки ассемблера. Смотри

07. Обфускация - бенчмарк Tigress

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

Это называется обфускацией, и это единственное место, где буксует даже лучшая модель. Elastic Security Labs измерили это, натравив Claude Opus на запутыватель Tigress в 20 задачах. Запомни эти цифры.

Из этих цифр следуют два практических урока.

• Во-первых, неудачная попытка стоит примерно вдвое дороже успешной, потому что модель пытается снова и снова, прежде чем сдаться. Поэтому установи лимит расходов на одну функцию и останавливай процесс раньше.
• Во-вторых, вычисти мусор из декомпилированного кода перед отправкой (бесплатный инструмент Caveman удаляет около 75% такого мусора), чтобы модель тратила внимание на реальную логику, а не на воду.

Пять приемов, с которыми ты реально столкнешься, и то, как они выглядят при открытии кода:

1Эта функция выглядит обфусцированной. Работай на уровне усилий max.
2
31. Определи присутствующие техники (уплощение потока управления, непрозрачные предикаты,
4   мертвый код, шифрование строк, разделение функций) и укажи, где именно каждая из них встречается
5   в этом конкретном коде.
62. Устрани их: удали мертвые ветки, вычисли непрозрачные предикаты, разверни уплощенный
7   диспетчер, расшифруй встроенные строки, если ключ можно восстановить.
83. Покажи чистую функцию, которая осталась.
94. Оцени свою уверенность от 1 до 10. Если ниже 6, скажи мне точно, какие части вызывают сомнения
10   и какой соседний контекст помог бы их разрешить. Не гадай молча.
11
12[вставьте обфусцированный псевдокод]

08. Рой - контроллер, управляющий воркерами

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

Решение — небольшая команда: один чат-контроллер, который раздает задачи, и несколько чатов-воркеров, каждый из которых берет одну функцию.

Контроллер держит в голове общую картину и сшивает кусочки обратно воедино.

Для этого не нужно собирать ничего особенного — два промпта ниже и есть вся настройка.

1Ты — контроллер для реверс-инжиниринга. Карта функций находится в functions.json
2(адрес, имя, размер, xref_count).
3
41. Сгруппируй функции по близости в графе вызовов; отсортируй кластеры по количеству xref.
52. Распредели каждый кластер между воркерами. Никогда не анализируй функции самостоятельно.
63. Внедряй уже распознанные структуры в бриф каждого воркера, чтобы имена оставались согласованными.
74. Если воркер возвращает уверенность ниже 6, поставь в очередь второй проход с контекстом
8   от его распознанных соседей.
95. Отслеживай суммарный расход токенов и сообщай о нем после каждого кластера.

1Ты — воркер. Ты получаешь одну декомпилированную функцию и структуры, распознанные на данный момент.
2Верни строго: адрес, назначение, уверенность (1-10), structs_used, structs_new,
3clean_source, flags. Используй существующие имена структур; никогда не придумывай второе имя для
4структуры, которую контроллер тебе уже дал. Только одна функция. Останавливайся, когда закончишь.

https://x.com/victor_explore/status/2109466356454510612

09. Чистая комната - четыре правила, чтобы оставаться в рамках закона

Пересборка методом «чистой комнаты» означает, что ты копируешь то, что делает приложение, но никогда — код внутри него. Сделаешь всё правильно — и выпущенный продукт будет полностью твоим. Ошибешься — и будешь тащить на себе чужие авторские права.

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

1. Наблюдай, но не копируй. Запускай цель как черный ящик, смотри, что она делает, делай скриншоты только её собственного окна. Никогда не читай, не дизассемблируй и не вставляй её код. Никогда не копируй формулировки дальше простых названий функций.
2. Спецификации, а не исходники. Форматы файлов берутся из публичных стандартов (OOXML — это ECMA-376 / ISO 29500, плюс опубликованные спецификации RTF и ODF), а не из чтения парсера конкурента или любого кода под GPL/LGPL.
3. Только оригинальные ресурсы. Каждая иконка, шрифт, шаблон и звук либо нарисованы кодом, либо находятся в общественном достоянии, либо имеют открытую лицензию с указанием в файле атрибуции. Иначе CI-проверка завалит сборку.
4. Разделяй две задачи. Один агент восстанавливает поведение и пишет спецификацию. Другой контекст реализует код исключительно по спецификации, никогда не заглядывая в исходный анализ. Это разделение и есть граница «чистой комнаты».

1На основе завершенного анализа напиши спецификацию "чистой комнаты" для реимплементации.
2
3Описывай ТОЛЬКО ПОВЕДЕНИЕ. Включи: каждый публичный интерфейс, модель данных, каждую
4видимую пользователю функцию в виде тестируемого требования, форматы файлов для чтения и записи
5(по наблюдаемому поведению и публичной спецификации), а также поведение при обработке ошибок.
6
7НЕ включай: адреса или смещения, имена переменных из декомпиляции, ассемблерный код
8или что-либо скопированное из оригинала. Разработчик, который никогда не видел бинарник, должен
9смочь реализовать совместимую версию, опираясь только на этот документ.
10
11Выведи markdown с разделами: Architecture, Data Model, Public API, File Formats,
12Test Cases.

Работа по описанию — это не только юридическая страховка. Она позволяет принимать правильные решения для твоего языка и твоих задач, вместо того чтобы наследовать решения, принятые оригинальным автором десятилетия назад.

WordCraft местами работает быстрее Word именно потому, что не копировал внутренности Word.

10. Создание приложений - двенадцать pro-инструментов, один метод

WordCraft — не исключение. Это лишь одно из двенадцати приложений на полке команды ArtCraft, каждое из которых представляет собой clean-room пересборку инструмента, за который ты уже платишь. Все они написаны с нуля на Rust и выложены бесплатно и открыто на GitHub.

Их собственный слоган — «Twelve apps. One craft» (Двенадцать приложений. Одно мастерство), и это мастерство — метод из шага 9: наблюдай за оригиналом, читай публичные спецификации, собирай свежую версию исключительно на основе поведения.

Выгода от этого общего метода везде одинакова. Никакого Electron: каждое приложение нативно для macOS, Windows и Linux, и все, кроме FilmCraft, также работают во вкладке браузера через WebAssembly.

А поскольку каждое действие внутри них — это именованная команда, всеми двенадцатью приложениями AI-агент может управлять сразу из коробки.

Каждое приложение Craft построено одинаково, и эту архитектуру стоит копировать. Каждое состоит из слоев, где каждый слой использует только тот, что находится под ним: от базовых измерений внизу до окна на экране наверху.

Вот слои WordCraft:

И каждое действие — это просто именованная команда, поэтому клик мышью, сочетание клавиш и AI-агент вызывают абсолютно одно и то же. Именно это позволяет любому из них управляться агентом.

1drive WordCraft over MCP
2
3# Headless document automation
4claude mcp add wordcraft -- wordcraft-cli mcp
5
6# Or drive the running desktop app
7wordcraft --control 7981 &
8claude mcp add wordcraft-app -- wordcraft-cli mcp --connect 127.0.0.1:7981
9
10# Tools: list_commands, execute, batch, type_text, select_text,
11#        inspect_document, render_page, save_document (+ screenshot/click/key live)
12> Open report.docx, make every heading 14pt bold, export to PDF
13  ✓ select.all-headings -> 12 selected
14  ✓ format.font-size 14 · format.bold
15  ✓ export report.pdf (selectable text, bookmarks kept)

https://x.com/yuhasbeentaken/status/2109235513102057828

11. Проверка и релиз - докажи идентичность, раскрой MCP

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

Вместо этого сравнивай поведение: дай и оригиналу, и своей пересборке одинаковые входные данные и проверь, совпадает ли результат.

1Создай тестовый стенд для проверки поведения, сравнивающий оригинальный бинарник и мою пересборку.
2
3Сгенерируй 50 входных данных: 30 нормальных, 10 граничных (пустые, максимальный размер, unicode, спецсимволы),
410 ошибочных (поврежденные, с отсутствующими полями, битые). Прогони каждый через оба варианта. Сравни вывод
5побайтово там, где это возможно, и семантически в остальных случаях. Сообщи процент совпадений, список
6расхождений и степень серьезности каждого (косметическое / поведенческое / критическое). Сохрани в report.md.

Это также самое убедительное доказательство, которое ты можешь кому-либо показать (RE-слот в самом начале статьи).

Затем выпусти свою пересборку так же, как это сделали REA и WordCraft: в виде MCP-сервера, чтобы агент следующего человека мог управлять ей так же, как ты управлял REA.

Дай каждой функции понятное имя и описание, оберни её в простой консольный инструмент и сделай установку в одну строку.

https://x.com/0xMovez/status/2108884063515746410

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

Шесть ошибок, которые убьют выходные

1. Открывать дизассемблер для Electron-приложения. Если JavaScript лежит прямо перед тобой, маршрутизируй задачу в analyze_javascript_application и полностью пропусти нативный путь.
2. Дампить всё подряд до того, как что-то прочитал. Сначала попроси REA сделать сводку. Вытягивание всего приложения разом хоронит реальную логику под горой шума и раздувает твой счет.
3. Читать функции в порядке их расположения в файле. Сортируй по количеству перекрестных ссылок. Функция со 147 xrefs — это архитектура; хелпер с 2 xrefs может подождать.
4. Биться головой о третью стадию обфускации. Бенчмарк решает 0% многоуровневой обфускации. Установи бюджет, сохрани контекст от соседних функций и вернись позже.
5. Позволять модели копировать код в твою пересборку. Это нарушает принцип «чистой комнаты». Сначала спецификация в одном контексте, затем реализация по спецификации в другом.
6. Релизить без отчета о соответствии. «Я думаю, что оно совпадает» — не доказательство. 50 поведенческих тестов и процент совпадений — доказательство.

Заключение:

Установи REA. Прочитай бинарник. Пересобери его как свой собственный.

Маршрутизируй цель, составь карту её поверхности, декомпилируй горячие функции, позволь Opus 5.5 дать всему имена, сломай ту обфускацию, которую стоит ломать, масштабируй процесс с помощью роя, затем чисто опиши спецификацию и выпусти пересборку через MCP.

Одиннадцать шагов. Одна модель. Ноль скопированного кода.