Исследователи смогли с помощью ИИ разобрать и частично воспроизвести Slack и Finder, а также собрать функциональную копию вредоносного ПО Turla. ИИ-реверс-инжиниринг заметно снижает порог входа в работу, для которой раньше требовались знание ассемблера, недели ручного анализа и очень терпеливые аналитики. Для российских разработчиков и команд ИБ это не повод срочно шифровать всё подряд, но вполне конкретный сигнал: опубликованный клиентский код и бинарники стали гораздо более удобным сырьём для анализа.
Эксперимент провели специалисты Intezer, сообщает Dark Reading. Они взяли три принципиально разных цели: клиент Slack, файловый менеджер Apple Finder и Turla — семейство вредоносного ПО, которое давно интересует исследователей угроз. Задача была не в том, чтобы получить исходники один к одному, а в том, чтобы восстановить логику работы программ, связи между компонентами и ключевые функции. В случае Turla исследователи собрали реплику с рабочим конвейером: она принимала и исполняла команды, а также поддерживала передачу файлов.
Здесь важна не магия «нейросеть написала программу», а организация процесса. Для каждой цели команда строила отдельную обвязку — набор инструментов, правил и агентов вокруг языковых моделей. Управляющий агент делил бинарный файл на функции с помощью средств статического анализа, включая Binary Ninja; другие агенты реконструировали фрагменты и проверяли результат. Для работы с вредоносным ПО схему усложнили: детерминированный управляющий слой на Python связали с компилятором, виртуальной машиной, инструментами статического анализа и несколькими LLM. Это позволяет исследовать образец, не запуская его без необходимости на основной машине.
Разница между целями оказалась показательной. Finder удалось приблизить к оригиналу по пользовательским сценариям — файловым операциям и локальному поиску, — но не по точной внутренней архитектуре. У приложения слишком много зависимостей от сервисов macOS и облачной инфраструктуры, которые не видны извне. Slack оказался удобнее для разбора: его клиентская часть опирается на JavaScript, который можно исследовать значительно проще, чем нативный скомпилированный код. Исследователи воспроизвели клиент, но не смогли с такой же точностью восстановить серверную часть: нужной информации у пользователя приложения просто нет.
Это важная граница для компаний, которые думают о защите интеллектуальной собственности. ИИ-реверс-инжиниринг способен быстро восстановить поведение клиента, алгоритмы обработки данных и интересные атакующему участки кода. Но он не достаёт из десктопного приложения инфраструктуру, которая никогда не поставлялась на устройство: серверные сервисы, внутренние данные, ключи и бизнес-логику, оставшуюся на бэкенде. Поэтому архитектурное решение «что выполняется у клиента, а что на сервере» становится ещё и решением по защите кода, а не только вопросом масштабирования и задержек.
У угрозы есть и наступательная сторона. В материале упоминается отчёт Anthropic от 10 сентября: по его данным, связанная с Россией группировка Midnight Blizzard использовала Claude при разборе похищенного проприетарного SDK для системы компьютерного зрения дронов. На это ушло несколько дней. В другом описанном эпизоде злоумышленники из китайской кампании применяли модель в параллельных рабочих потоках, в том числе для анализа защитных продуктов в поиске уязвимостей. Речь не о том, что модель самостоятельно взламывает компанию, а о том, что она ускоряет рутину: чтение декомпилированного кода, разметку функций, построение гипотез и подготовку тестов.
Для защитников это, впрочем, такой же усилитель. Аналитику больше не обязательно вручную продираться через каждый участок большого бинарника, чтобы понять цепочку команд, протокол связи или механизм закрепления. Особенно полезен ИИ-реверс-инжиниринг при триаже: он помогает быстрее выделить подозрительные функции, сопоставить варианты вредоноса и подготовить понятное описание для команды реагирования. Но результат требует проверки. Модель может убедительно объяснить несуществующую связь между функциями или неверно восстановить смысл кода, а ошибка в анализе malware быстро превращается в плохое правило детектирования.
Разработчикам стоит пересмотреть не абстрактную «защиту от ИИ», а конкретные поверхности раскрытия. В клиент не следует помещать секреты, серверные ключи и критичную бизнес-логику, рассчитывая на обфускацию как на сейф. Обфускация, шифрование и механизмы защиты от анализа по-прежнему могут увеличить стоимость атаки — как и античит-системы в играх, — однако они лишь покупают время. Командам AppSec полезно регулярно проверять собственные сборки глазами реверс-инженера: какие API, конфигурации, токены, отладочные символы и лишние функции доступны из поставляемого артефакта.
Следующий вопрос уже не в том, сможет ли небольшая команда разобрать чужое приложение с помощью моделей, а в том, как быстро такие конвейеры станут обычным инструментом аудита и атак. Победят не те, кто попытается спрятать весь код, а те, кто заранее отделит доступную клиенту функциональность от действительно чувствительных систем и научится применять автоматизированный анализ раньше противника. Подробнее об эксперименте можно прочитать у .
