Введение
Реверс‑инжиниринг — процесс, требующий высокой квалификации и колоссальных временных затрат. Поиск уязвимостей, анализ вредоносного ПО, восстановление алгоритмов из скомпилированного кода — всё это до недавнего времени оставалось уделом экспертов, годами оттачивавших навыки работы с дизассемблерами и отладчиками. Однако в 2025–2026 годах рынок увидел новый тренд: использование больших языковых моделей (LLM) для автоматизации рутинных задач реверс‑инжиниринга. Особый интерес вызывает запуск таких моделей локально — это решает проблемы конфиденциальности, задержек и зависимости от облачных сервисов.
Недавняя публикация на Хабре (источник: Habr) подробно описывает эксперимент по автоматизации реверс‑инжиниринга с помощью локальной LLM. Авторы делятся архитектурой решения, конкретными результатами и ограничениями, с которыми столкнулись. В этой статье мы разберём ключевые выводы и покажем, почему такой подход может стать стандартом для внутренних отделов безопасности и R&D‑лабораторий.
Почему локальная LLM, а не облачный API?
Основная причина — конфиденциальность. При анализе проприетарного firmware или вредоносного образца отправка бинарного кода в сторонние облачные сервисы (OpenAI, Google, Anthropic) может привести к утечке интеллектуальной собственности или индикаторов компрометации. Локальный запуск модели гарантирует, что данные не покидают периметр организации.
Второй фактор — стоимость. При интенсивном использовании (тысячи запросов в день) облачные API обходятся в десятки тысяч долларов ежемесячно. Локальная LLM, например, квантованная версия Code Llama 34B или DeepSeek Coder 33B, требует одноразовых инвестиций в GPU (от $3000 за NVIDIA RTX 4090 или $10 000 за A6000) и электричество, но в долгосрочной перспективе значительно дешевле.
Третий момент — автономность. Локальная модель не зависит от интернет-соединения и не подвержена изменениям API или политикам использования.
Архитектура решения, описанная в статье
Авторы статьи на Хабре построили систему на базе open‑source инструментов. В качестве LLM они использовали модель DeepSeek-Coder-V2-Lite-Instruct (16B) в квантованной версии Q4_K_M, запущенную через llama.cpp. Для взаимодействия с дизассемблером выбрали Ghidra с плагином, который экспортирует декомпилированный код в текстовый формат и отправляет запросы к локальному серверу LLM.
Паipeline выглядит так:
- Анализируемый бинарный файл (ELF/PE) загружается в Ghidra.
- Скрипт автоматически запускает декомпиляцию и извлекает функции с их псевдокодом на C.
- Для каждой функции формируется промпт: «Опиши, что делает эта функция, переименуй переменные и добавь комментарии». Дополнительно передаётся контекст — вызовы других функций, строки данных, адреса.
- Ответ LLM парсится и записывается обратно в проект Ghidra через API плагина.
- Инженер получает помеченный дизассемблер с осмысленными названиями функций и переменных.
Такой подход позволяет обрабатывать до 500 функций за час на одном GPU (RTX 4090). Без LLM та же работа заняла бы несколько дней ручного анализа.
Практические результаты и реальные кейсы
Восстановление алгоритмов шифрования
В статье приведён пример анализа утилиты для шифрования конфигурационных файлов промышленного контроллера. Исходный код был утерян, требовалось восстановить протокол. Локальная LLM успешно идентифицировала алгоритм как AES‑256‑CBC с ключом, полученным через PBKDF2. Модель не только назвала алгоритмы, но и предложила корректные названия для функций (например, aes_decrypt_buffer, pbkdf2_derive_key) — это сэкономило инженеру несколько часов поиска констант и таблиц.
Анализ вредоносной нагрузки
Другой кейс — анализ загрузчика трояна для Windows. LLM помогла восстановить логику расшифровки второй стадии: код оказался обфусцирован через простой XOR с динамическим ключом. Модель указала на цикл считывания байтов и операцию XOR, а также предложила возможное название переменной xor_key. Без автоматизации эта функция — 30 строк ассемблера — потребовала бы ручного построчного разбора.
Ограничения и проблемы
Авторы честно перечисляют узкие места:
| Проблема | Описание | Решение / Комментарий |
|---|---|---|
| Качество для коротких функций | Модель плохо справляется с функциями длиной менее 5 строк — часто выдаёт общие фразы. | Для коротких функций лучше пропускать их или использовать жёсткую эвристику. |
| Ошибки в названиях | Иногда LLM предлагает семантически неверные названия (например, decrypt для функции, которая на самом деле кодирует). |
Требуется ручная верификация — модель лишь ассистент, не замена. |
| Размер контекста | Для очень длинных функций (более 200 строк псевдокода) модель «забывает» начало. | Использовать разбиение на блоки с перекрытием. |
| Язык комментариев | Модель иногда смешивает русский и английский в комментариях. | Можно задать промпт на одном языке. |
Тем не менее, даже с этими ограничениями скорость анализа возрастает в 5–10 раз по сравнению с ручным методом.
Инструменты, которые можно использовать
Для воспроизведения эксперимента вам понадобятся:
- Ghidra — бесплатный фреймворк для обратной разработки от NSA.
- llama.cpp — лёгкий движок для инференса LLM на CPU/GPU.
- DeepSeek-Coder-V2-Lite-Instruct или Code Llama 34B — модель, заточенная под код.
- Плагин-мост (Ghidra Python Script) для RPC-взаимодействия.
Все компоненты с открытым исходным кодом, поэтому решение можно интегрировать в корпоративную инфраструктуру без лицензионных отчислений.
Заключение
Автоматизация реверс‑инжиниринга через локальную LLM — не фантастика, а рабочий инструмент 2026 года. Он не заменяет эксперта, но снимает с него рутинную нагрузку: переименование переменных, восстановление типов, распознавание стандартных алгоритмов. Особенно ценна возможность запуска модели на собственном железе — это решает вопросы безопасности и экономики.
Пока остаются ограничения по качеству для тривиальных функций и необходимость ручной проверки, но прогресс моделей (Code‑специализированные LLM растут в точности на 15–20% в год) позволяет прогнозировать, что к 2027–2028 такие системы станут стандартным компонентом SOC и лабораторий безопасности.
Для тех, кто хочет глубже разобраться в практическом применении LLM в безопасности, статья на Хабре — отличная отправная точка. Рекомендуем также изучить репозитории с конфигурациями промптов и плагинами для Ghidra, которые там упоминаются.
Источник: Автоматизация реверс‑инжиниринга через локальную LLM — Habr
Комментарии