Разработка низкоуровневого софта и обратная разработка проприетарного кремния всегда держались на дотошности инженеров. Появление больших языковых моделей создало соблазн переложить рутину по декомпиляции на алгоритмы. Инженер пишет запрос, нейросеть мгновенно выдает код на Objective-C или C, тесты проходят, математика считается. Кажется, задача решена за минуты вместо месяцев упорного ковыряния ассемблера. Однако за гладким фасадом работающего прототипа часто скрывается критическая архитектурная ошибка.
Показательным примером стала недавняя попытка разобрать устройство закрытого фреймворка AppleNeuralEngine на macOS. Независимый исследователь Maderix вместе с моделью Claude попытались запустить вычисления напрямую на Apple Neural Engine (ANE), минуя стандартные высокоуровневые API. Задача требовала раскопать приватные интерфейсы операционной системы и понять реальный протокол взаимодействия с ускорителем.
Ловушка контекста и мнимый грааль
Модель добросовестно изучила список закрытых классов в системной библиотеке и быстро нашла заманчивое имя: класс `_ANEInMemoryModel`. Нейросеть сделала логичный по смыслу, но ложный по факту вывод: перед нами прямой путь исполнения графов прямо в оперативной памяти без лишних обращений к накопителю. В оригинальном отчете этот механизм даже назвали священным граалем для низкоуровневой работы с чипом. Сгенерированный код действительно компилировался и отдавал корректный результат умножения. Проблема вскрылась позже: алгоритм стабильно падал с ошибкой после примерно 119 итераций.
Языковая модель цепляется за удачное правдоподобное предположение и тащит его через все окно контекста, игнорируя технические противоречия.
«Нейросети хорошо умеют доставать слова из мешка... Однако они ошибаются — и, ошибившись единожды, будут тащить эту ошибку сквозь контекст, пока окно этого самого контекста не переполнится».
Если инструмент допустил базовую неточность в понимании архитектуры, он продолжит надстраивать вокруг нее новые костыли, маскируя сбои внешне корректным кодом.
Что показал ассемблер под капотом
Разбор реального бинарного кода фреймворка через декомпилятор iaito и отладчик LLDB показал совсем другую картину. Разработчик переписал вызовы на системном языке Rust, чтобы изолировать проблему с лимитом компиляций. Выяснилось, что никакого выполнения в памяти класс `_ANEInMemoryModel` не обеспечивает. Внутри метода `compileWithQoS:options:error:` скрывалась обычная обертка: библиотека тихо сохраняла временные файлы модели на диск через `saveModelFiles`, формировала локальный путь `localModelPath` и только потом отдавала их `_ANEClient`.
Чип физически не умел работать без записи промежуточных структур на накопитель в рамках этой ветки вызовов. Ограничение возникало при постоянном пересоздании временных файлов. Когда автор отбросил предположение нейросети, разобрал реальные параметры метода `_ANEClient compileModel` с опцией `kANEFModelMIL` и написал прямое обращение к низкоуровневому интерфейсу, код заработал в бесконечном цикле `loop` без единого сбоя.
Использование нейросетей в качестве ведущего аналитика при реверс-инжиниринге железа создает огромный скрытый технический долг, поскольку модель заменяет знание физических регистров и логики драйвера правдоподобными ассоциациями. Прототип может выдавать верный результат в демо-режиме, маскируя фатальные архитектурные ограничения, которые проявятся только под реальной нагрузкой. Без глубокого аудита микрокода и ассемблера человеком передача низкоуровневых R&D-задач генеративным моделям остается неоправданным риском для инженерной инфраструктуры.