Промышленная революция в области реверс-инжиниринга.

Что изменилось в августе 2026 года

До этой работы я много занимался обратным проектированием вручную. Я проверял функцию до тех пор, пока не находил объяснение, а затем тестировал это объяснение в программе. Продвигаясь дальше, я тратил больше своего времени на следующую функцию. Это также означало, что я держал в голове все более объемную картину.

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

В августе 2026 года я начал серьезно изучать RE, управляемый агентами. Я хотел посмотреть, как далеко может продвинуться агент, имея доступ к программе и обычным инструментам разработки. Touhou reconstruction предоставила мне значительный проект, в котором я мог это выяснить.

Первые результаты были поразительными. Расследование могло бы продолжаться без моего участия в выборе каждого отдельного шага. Неудачное сравнение могло бы отправить агента к другому абоненту. Можно было бы написать небольшую диагностику и использовать результат, чтобы решить, что делать дальше. Предоставление этой свободы изменило ситуацию к лучшему: я смог уделять больше внимания направлению проекта и тому, заслуживают ли доверия его проверки.

В первую очередь мое внимание привлек темп. Затем я начал задумываться о том, что останется после текущего проекта. Будет ли в следующей игре полезно все, что мы только что узнали?

TH08 : опора на человеческий труд

TH08 , "Вечная ночь", начинался как продолжение реконструкции GensokyoClub. Их открытый источник дал мне существенную основу. Это пришло вместе со знанием конструкции и историей вклада, которую я сохранил в продолжении.

Импортированная история заканчивается на общедоступной контрольной точке 10 августа. Мое самостоятельное продолжение началось 13 августа. К 19 августа в журнале были зарегистрированы исходные данные для всех 1107 идентифицированных игровых функций.

Играбельный порт реконструкции Linux был выпущен 24 августа, примерно через одиннадцать дней после начала работы над продолжением. Затем была выпущена веб-версия. 64-разрядная версия Linux для собственной версии вышла 30 августа.

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

Это сделало проверку ссылок центральной в работе. Я называю их проверочными ссылками (оракулами). Сравнение кода может сказать нам, воспроизводит ли восстановленная функция исходные инструкции. Проверка во время выполнения может сказать нам, достигает ли реализованный маршрут ожидаемого состояния. Агент предлагает объяснение и проверяет его; несоответствие дает ему возможность исследовать что-то конкретное.

Точное совпадение с неправильной константой

Ссылка для проверки (oracle) - это программное обеспечение, которое кто-то написал. TH08 дал мне четкое напоминание о том, как много может зависеть от этого программного обеспечения.

В сентябре ошибка, о которой сообщил порт коммутатора, снова привела к автоматическому сбору предметов. В восстановленном источнике мощность проигрывателя была проверена на уровне 0.0. В оригинале использовалось значение 128.0 - порог максимальной мощности.

Нормальная мощность неотрицательна, поэтому проверка восстановленной мощности фактически всегда выполнялась. Выше линии сбора игра могла привлекать предметы, не требуя максимальной мощности. Другие исключения из условия были верными. Эта константа изменила поведение.

Тем не менее, функция уже прошла точное сравнение.

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

Это оставило пробел в проверке. Это могло привести к тому, что восстановленная команда указывала на исходное значение 128.0, в то время как в источнике по-прежнему указывалось 0.0. Байты инструкции совпали. Источник имел в виду что-то другое.

Исправление, выпущенное 2 сентября, исправило исходный код и заставило при сравнении проверять фактические байты константы, на которую ссылается ссылка. Затем был проведен более широкий аудит, в ходе которого было проанализировано 1548 ссылок на константы с плавающей запятой. Было обнаружено еще двенадцать неправильных ссылок в пяти принятых функциях.

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

Ссылка для проверки (oracle) также нуждалась в восстановлении. Ее исправление было частью обновления игры.

Это важно, когда команда состоит в основном из одного человека, работающего с агентами. Я не могу лично проверять каждую строку, которую они создают, поэтому во многом я доверяю их проверкам. "Слепое пятно" в системе общего контроля (oracle) может повлиять на многие расследования, прежде чем я его замечу. Я должен понять, что на самом деле проверяет средство проверки, и протестировать его на предмет случаев, которые должны завершиться неудачей.

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

Успешный запуск пакета позволил нам восстановить код и улучшить среду для следующего пакета.

Две разные идеи реконструкции

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

Рост числа мошенников (декомпиляторов и портаторов искусственного интеллекта) в этой области, основанный на нашей работе, создает плохую картину для будущих усилий по декомпиляции…

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

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

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

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

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

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

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

Источник: Уведомление GensokyoClub на README, проверенное 10 октября 2026 года, и его политика в отношении взносов. Цитата является сокращенной выдержкой. Титры и происхождение TH08 указывают на границу продолжения.

TH095 : опыт начинает накапливаться

TH095, Shoot the Bullet, значительно упростил восприятие этого опыта. 29 августа началось его обновление с нулевыми подтвержденными игровыми функциями в реестре. Нам все еще предстояло изучить игру. Но мы уже знали гораздо больше о том, как начать реконструкцию и как поддерживать ее в рабочем состоянии.

К 7 сентября все 697 идентифицированных игровых функций имели исходный код. К 8 сентября 696 были приняты в качестве точных сравнений. 9 сентября вся программа была подключена. Реконструкция Windows i386 была отмечена как играбельная 10 сентября, примерно через двенадцать дней после инициализации.

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

Например, TH08 научил нас обращать внимание на собранную программу с самого начала. Если несколько восстановленных функций зависят от одного и того же состояния, их изолированное сравнение оставляет открытым важный вопрос. Нам нужно увидеть, как они работают вместе. Этот урок помог нам сформулировать подход к построению всей программы TH095.

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

Ошибка, связанная с константой с плавающей запятой, также относится к этой памяти. Это объясняет, почему проверка ссылки также требует проверки данных, которые за ней стоят. Сохранение этого исправления в коде помогает последующим проектам избежать "слепого пятна" старой проверки.

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

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

TH04 : рабочий процесс функционирует в соответствии с другой архитектурой

TH04, разработчик Lotus Land Story, перенес эту работу в эпоху PC-98 для DOS. Теперь целью была 16-разрядная среда с четырьмя взаимодействующими программами. Для понимания поведения аппаратного обеспечения требовались другие данные, полученные из игр Windows. Существующая работа по ReC98 также дала нам ценные знания и исходные материалы.

Восстановление DOS теперь работает. В ходе моего ручного тестирования я воспроизвел все обычные маршруты до их окончаний и проверил сохранения. В настоящее время используется собственный 64-разрядный порт. При установке рабочей версии DOS сначала указывается ссылка на этот порт.

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

Рассмотрим переход от игрового процесса к завершению. Нам нужно знать, какое состояние переходит через эту границу и какая программа за это отвечает. Это то, что мы можем исследовать на примере продукта DOS. Как только доказательства и чеки будут доступны, агент сможет проработать вопрос во многом так же, как это было с заголовком Windows.

Вот почему TH04 важен для нашего аргумента. Существенное изменение платформы не заставило нас начать все сначала с нового способа работы. Архитектура определила проблему; рабочий процесс по-прежнему давал нам возможность ее решить.

Что касается 64-разрядного порта, то теперь мы можем сравнить новую реализацию с поведением, уже восстановленным в DOS. Знания, полученные в результате реконструкции, дают порту основу для дальнейшего развития.

Состояние проекта на 10 октября 2026 года: реконструкция DOS и ручное тестирование · 64-разрядный порт. Порт находится в разработке.

От точного кода к читаемому коду

Как только реконструкция завершится, я хочу, чтобы кто-то еще смог это понять.

Для меня ассемблер и необработанные смещения кажутся старыми друзьями. Я понимаю, что это несколько необычное определение слова “читаемый”. Большинство людей предпочли бы следовать логике игры, не держа в голове расположение исполняемого файла в памяти.

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

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

Порядок, который я сейчас использую, таков:

1. Восстановите точную базовую линию. Скомпилируйте восстановленные фрагменты с помощью исторического компилятора. Сравните соответствующий код и данные с исходным исполняемым файлом. Запишите неразрешенные различия, чтобы у следующего этапа была четкая отправная точка.
2. Создайте и играйте в нее на оригинальной платформе. Объедините эти фрагменты в реальную программу, используя оригинальную архитектуру и компилятор. Используйте важные элементы геймплея. Именно здесь мы можем обнаружить проблемы с общим состоянием или инициализацией, которые были пропущены при сравнении изолированных функций.
3. Реконструируйте семантику в соответствии с обеими ссылками. Выделите одну связную часть игры за раз и выясните, что означает восстановленный источник. Улучшите ее представление, сохранив точные сравнения и воспроизводимую историческую структуру.
4. Создайте современный порт. Перенесите устоявшееся поведение в новую среду, например, в собственную 64-разрядную сборку. Реконструированная игра на оригинальной платформе остается эталоном для сравнения поведения порта.

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

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

Название само по себе требует подтверждения. Точное сравнение не может сказать нам, действительно ли поле означает “время неуязвимости”. Мы должны установить это по тому, как игра его записывает и использует. Если значение остается неопределенным, нейтральное название будет более полезным для следующего читателя, чем уверенное предположение.

Мы изучили этот порядок в ходе работы над проектами. У TH08 уже были доступные для воспроизведения порты до некоторых более поздних проверок исторических платформ. Это затрудняло выявление некоторых дефектов. Текущий рабочий процесс фабрики ставит сборку исходной платформы на первое место, поэтому semantic work может использовать ее в качестве справочного материала перед началом переноса.

Точная реконструкция дает нам ссылку. Семантическая реконструкция позволяет использовать восстановленные знания. Затем порт может использовать и то, и другое.

Что делает это промышленным сдвигом

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

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

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

REA предоставляет агенту доступ к инструментам анализа. Вопрос о вызывающем объекте функции может привести непосредственно к проверке этого вызывающего объекта. Проект реконструкции предоставляет компилятор и свои собственные проверки ссылок. Агент может использовать их, чтобы протестировать предлагаемый им источник и посмотреть, соответствует ли его объяснение действительности.

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

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

Мы находимся на ранней стадии этого промышленного сдвига. Большая часть инфраструктуры все еще находится в стадии разработки. Агенты могут работать быстрее, чем это предусмотрено нашими чеками, поэтому процесс должен развиваться параллельно с ними. Когда мы обнаруживаем дефект в общем инструменте, мы должны устранить его и пересмотреть результаты, на которые он повлиял. Следующий проект может унаследовать более мощный инструмент.

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

Проект Touhou Reconstruction Factory вырос из этой потребности. Он дает проектам возможность совместно проводить проверки и извлекать уроки. Работа над одной игрой может улучшить стартовые условия для другой.

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

Проекты, которые мы теперь можем рассмотреть

Темп важен, потому что он меняет решение о начале работы. Игра может быть увлекательной для реинжиниринга и все равно требовать от меня больше внимания, чем я мог бы ей уделить. Многие проекты так и останутся идеями.

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

Теперь я смотрю на незнакомую программу и спрашиваю: какой доступ, обратная связь и накопленные знания позволили бы агенту надежно работать с ней?

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

Дополнительные статьи · Ознакомьтесь с исследованием TH04