Использование AI систем типа Claude и ChatGPT для восстановления исходного кода

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

С чего все началось

Некоторое время назад на reddit появилась статья, как один из участников сообщества восстановил разработанную 27 лет назад игру. Этот файл был разработан на крайне старой, на сегодняшний день, версии Visual Basic 4.0. Это настолько старая версия языка, что даже наш декомпилятор VB Decompiler, который разрабатывается с 2005 года, ее не поддерживает. После начала чтения поста, который вы можете легко найти, поискав по заголовку статьи I Uploaded a 27-Year-Old EXE File to Claude 3.7 and What Happened Next Blew My Mind, может показаться, что будущее уже пришло к нам. Что теперь реально появилась возможность восстанавливать исходный код из машинного кода, просто общаясь с чат ботом и незначительно корректируя его ответы, направляя мысли AI модели в нужном ключе.

Реалии AI декомпиляции

К сожалению, после детального анализа поста автора, выясняются следующие детали: внутри его exe файла присутствовала текстовая справка, которая детально описывала работу игры. Также в программе присутствовало множество дополнительной текстовой информации: сообщения об ошибках, информационные сообщения и так далее. Как в дальнейшем выясняется - Claude не декомпилировал код, а лишь руководствуясь справкой и найденными в программе строками проанализировал, как данная программа "по идее" должна работать и написал аналог на Python. Говоря иначе - AI использовал найденные в программе текстовые строки как инструкцию для написания подобной программы заново, а вовсе ничего не декомпилировал.

Недостатки работы AI

В чем главный недостаток подобного подхода? Во первых, далеко не все программы (если не сказать единицы) содержат внутри себя текстовое описание работы кода. Даже если Ваша программа до компиляции содержала множество полезных комментариев, то они никогда не попадают в скомпилированный exe файл. Компилятор их удаляет на стадии компиляции. Единственный шанс той или иной документации попасть в exe файл - если вы ее самостоятельно разместите на той или иной форме (диалоговом окне) или выведете через консоль, если программа не имеет GUI интерфейса. Все это частные случаи, которые при исследованиях реальных файлов маловероятны.

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

Говоря еще проще, если вместо попыток такой "декомпиляции" вы составите текстовое описание своей программы, в котором расскажете, как она должна работать, а затем попросите ChatGPT или Claude написать нечто похожее на нужном Вам языке - результат может оказаться даже лучше. При этом, что в первом, что во втором случае Вы получите совершенно новый код, никак не похожий на Ваш. Этот код никак не будет использовать придуманные Вами алгоритмы, никак не будет основан на Ваших know how. Вы получите абсолютно новый код, хоть и делающий нечто похожее, что делала Ваша программа. И даже здесь, успешность будет возможна только в том случае, если AI модель изначально обучалась на подобных алгоритмах. Да, к сожалению все именно так. Если Ваш код содержал какие-либо проприетарные алгоритмы, которые представляют коммерческую тайну - AI модель никогда их не восстановит. Просто потому, что она не восстанавливает код, в привычном понимании. Она пишет его заново, пытаясь решить Вашу задачу используя свой (а не Ваш) опыт.

Особенности декомпиляции Visual Basic 5.0 и 6.0 приложений

В чем особенности более ранних версий Visual Basic под MS DOS и под ранние версии Windows 95? В них нет классов, нет разграничения области видимости функций. Формы (диалоговые окна), не поддерживают десятки тысяч сторонних ActiveX компонентов. И, что самое важное, нет всестороннего использования COM OLE модели работы с внешними библиотеками и компонентами.

У Visual Basic версий 5.0 и 6.0 (они очень похожи, хоть и используют разную версию Framework библиотеки, поэтому я буду писать далее о них как об одном языке и компиляторе) поддерживаются два типа компиляции - в интерпретируемый псевдокод (так называемый P-Code) и машинный код на x86 ассемблере (так называемый Native Code). Оба варианта генерируют exe файл. И внешне Вы никак не отличите P-Code от Native Code. Ровно до тех пор, пока не попытаетесь декомпилировать этот файл. VB Decompiler при открытии файла и после его анализа сразу показывает, как была скомпилирована программа. Поэтому вы можете использовать VB Decompiler, в том числе и для определения типа компиляции Вашего файла. Разница между типами компиляции колоссальна. В случае P-Code - используется интерпретируемый язык, содержащий до 1400 опкодов виртуальный машины. И это не примитивные команды математических или логических операций, которые потенциально можно восстановить, используя AI модель. В большинстве своем - это работа с COM объектами. Раннее и позднее связывание при создании объектов, доступ к полям и методам ранее созданных объектов. Доступ по имени, по ссылке, используя интерфейс виртуальной таблицы (VTable) и идентификаторы DispatchID. Все это помимо самого P-Code требует парсинга огромного количества таблиц различных метаданных. Таблиц, которые нигде не документированы. Таблиц, являющихся частью закрытого формата.

Что же с Native Code? В нем все и проще и гораздо сложнее одновременно. Проще в том, что вместо 1400 опкодов виртуальной машины мы имеем менее 700 переходников внутреннего API фреймворка MSVBVM60.DLL (ну или MSVBVM50.DLL в случае Visaul Basic 5.0). Сложнее - в том, что это не последовательность P-Code команд, которые можно пошагово интерпретировать и сворачивать. Это оптимизированный машинный код. И при разных опциях оптимизации код генерируется также по-разному. Более того, в отличие от P-Code мы никогда заранее не знаем, что по адресу памяти, с которым сейчас работает та или иная простая команда сложения, вычитания, или логическая операция. Это может быть как сдвиг по одномерному массиву, так и сдвиг по таблице виртуальных методов VTable. Может быть и выравнивание данных в стеке. Да что угодно. Для разбора Native Code в VB Decompiler потребовалось разработать статический эмулятор машинного кода, который пошагово, виртуально исполняет код функции и в каждый момент времени содержит срез содержимого всех регистров, стеков процессора и математического сопроцессора, переменных программы и т.д. Но даже это иногда дает осечки, особенно когда COM объекты создаются в одной функции, потом используются в другой и все это в рантайме по принципу позднего связывания. Над разработкой Native Code декомпилятора я работаю уже 20 лет и даже спустя столько времени она далека от завершения и сегодня процент восстановления кода из Native Code программ у VB Decompiler на уровне 75%.

Невозможность использования AI моделей для декомпиляции Visual Basic 5.0 и 6.0 приложений

Резюмирую вышесказанное. Если вы предоставите ассемблерный машинный код AI модели - она попытается его превратить в исходный код только в том случае, если этот код самодостаточен. Если он не ссылается на ранее созданные COM OLE объекты, не обращается к внешним подключаемым различным компонентам на формах (как визуальным, так и к контейнерам баз данных), не использует данные по адресам памяти, назначение которых заранее неизвестно и т.д. Иначе говоря, GPT модель может помочь только в случае очень узкоспециализированных алгоритмических задач. Такая модель абсолютно неприменима для декомпиляции программ на Visual Basic. Равно как и на любом другом объектно-ориентированном языке, содержащем львиную долю информации о коде в различных таблицах метаданных.

Выводы

Когда может помочь AI модель? В случаях, когда нужно решить задачу по программированию, при этом метод решения этой задачи не важен. Но тут, как уже писал ранее, эффективнее составить техническое задание для AI модели на нужный Вам код. Без ссылок на скомпилированные exe файлы старых программ. Так код получится и чище и современнее. Проще говоря, искусственный интеллект уже неплохо умеет писать новый код под Ваши задачи. Но он, к сожалению, пока совершенно не умеет восстанавливать псевдокод или машинный код в код исходный.

Когда нужен декомпилятор, подобный VB Decompiler? Во всех случаях, когда нужно проанализировать именно тот код, что внутри exe файла, а не похожий, додуманный AI моделью. Это и анализ вредоносных файлов на предмет их функционала в антивирусных лабораториях. И криминалистический анализ программ на предмет закладок, бэкдоров и скрытого функционала. И восстановление своих закрытых алгоритмов, представляющих know how. VB Decompiler не использует интернет, не использует внешние сервера больших данных. Он скрупулезно анализирует все встроенные в файл таблицы метаданных. Пошагово виртуально эмулирует код (без запуска на реальном железе) и пытается восстановить максимально возможное число кода. Да, восстановленный код будет выглядеть далеко не идеально, но он будет максимальным отражением изначальной логики исследуемой программы, заложенной ее автором. Там не будет выдуманного AI моделью кода, просто по причине того, что для составления полной картины модели не хватало данных. Код будет таким, какой реально присутствует в файле. И если та или иная строка не может быть корректно декомпилирована - вы увидите UnknownCall или нечто подобное, вместо фантазий AI. C точки зрения исследования алгоритмов - это наиболее честный и правильный подход.

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

(C) Сергей Чубченко, разработчик VB Decompiler