Нужна ли реверс-инжинирингу модель большего размера?

Что изменили более сильные модели

С августа 2026 года я изучаю, какой объем реверс-инжиниринга может провести агент, имея доступ к программе и способ проверки ее работы. Большая часть моего опыта связана с реконструкцией игр, особенно Touhou. Поскольку я менял модели, в репозиториях фиксировалось, что удалось восстановить в каждом сеансе.

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

Временным переменным требовалось перекрывающееся время жизни.

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

Запись сеанса GPT-6-Sol сообщила об этом несоответствии после тестирования нескольких обычных схем исходного кода. Когда GPT-6.1-Sol снова изучил проблему, он предложил полезную гипотезу о времени жизни этих временных переменных.

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

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

Меня интересует, как открытие и испытания поддержали друг друга. Гипотеза о времени жизни временных объектов дала агенту ИИ новое направление. Отзывы компилятора помогли усовершенствовать эту гипотезу и привести ее в соответствие с исходным кодом.

Другой граф потока управления

Вторая функция TH09 показывает, почему это новое направление может иметь значение. Здесь препятствием было то, как несколько филиалов делились своей итоговой работой. В более ранней работе GPT-6.1-Sol части функции совпадали, но ветви по-прежнему соединялись иначе, чем в оригинале.

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

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

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

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

Почему специализированная модель ИИ может преуспеть?

Touhou дает нам конкретную причину ожидать, что этот опыт поможет. Большая часть игрового кода принадлежит одному и тому же автору, ZUN, поэтому повторяющиеся привычки — разумное исходное предположение. Репозитории подтверждают это полезными примерами: связанные циклы и вспомогательные механизмы служат источником гипотез для разных игр.

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

Например, в TH095 даже имя локальной переменной может влиять на то, где VC7.1 ее хранит. Перемещение его декларации не решило проблему с расположением хранилища. Однако более ранняя фоновая функция выявила шаблон именования, который повлиял на выбор компилятора. Это предложило более многообещающую гипотезу для реконструкции Supervisor::LoadDat.

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

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

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

Полезные шаблоны должны сохранять свой контекст. TH08 использует более раннюю версию Visual C++, чем TH095 и TH09. TH04 использует другой компилятор эпохи DOS. Его реконструкция кода игрока требовала различных гипотез о шаблонах исходного кода и о том, как скомпилированный код связывается с исполняемым файлом. Наличие одного и того же автора дает нам первоначальное ожидание, но каждая цель говорит нам, применимо ли оно. Специализированная модель должна будет различать эти контексты.

Где следует хранить этот опыт?

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

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

При реконструкции функции TH09 по созданию врагов сеанс GPT-6-Luna-max взял гипотезу из соответствующего исходного кода TH08. Этот более ранний код предлагал, как организовать цикл и обрабатывать сбои внутри него. Собственные доказательства TH09 предоставили подробности, касающиеся конкретной игры. Перестройки из исходного кода подтвердили, что вся функция совпадает.

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

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

Изучаем следующий полезный эксперимент

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

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

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

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

Я бы хотел, чтобы модель научилась использовать обратную связь. Нейтральный результат — повод пересмотреть вариант; измененное несоответствие может указывать на другую причину. Когда локальные изменения перестают быть информативными, агент должен иметь возможность вернуться к исходному представлению или снова проверить доказательства.

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

Чем реверс-инжиниринг интересен для обучения с подкреплением

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

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

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

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

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

Когда программа проверки ошибается

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

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

Чтобы устранить этот пробел, более широкий аудит обнаружил неправильные константы в функциях, которые уже прошли проверку. В одном расчете в реконструированный исходный код добавлен 1.0f, тогда как в исходный добавлен 32.0f.

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

Функциональный тест может иметь аналогичное «слепое пятно». Исследование с использованием дифференциального фаззинга в декомпиляторах LLM выявило различия в поведении за пределами предоставленных тестов. Поэтому нам необходимо понимать прохождение теста с точки зрения случаев, в которых он проводится. Точно так же совпадение инструкций следует понимать с точки зрения байтов и данных, которые оно проверяет.

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

Улучшение модели и улучшение её проверяющего инструмента — части одной исследовательской задачи. Чем лучше модель оптимизирует получаемую обратную связь, тем важнее понимать саму эту связь.

Сравнение, которое стоит провести

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

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

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

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

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

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

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

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

О каком ИИ-агенте идет речь?

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

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

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

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

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