Ручной анализ вредоносного файла как наведение порядка в квартире: можно справиться за пару часов или же застрять с этой задачей на несколько недель. Всё зависит от сложности семпла, степени обфускации и других факторов.
Однажды я разбирал вредонос с тестового стенда целую неделю и в итоге справился лишь наполовину — до анализа протокола взаимодействия с С2 дело так и не дошло. Тогда я задался вопросом: а можно ли ускорить такую работу с помощью LLM и не потерять в качестве анализа. Оказалось, что можно и даже нужно.
Под катом расскажу, как мы реализовали связку популярной среды для реверс-инжиниринга IDA Pro и LLM на практике, что получилось по итогам тестирования нескольких семплов, каковы плюсы и минусы подобной схемы.
В статье вы найдете и краткую инструкцию по настройкам. Мы не предлагаем универсальный пошаговый гайд, как повысить эффективность реверс-инжиниринга с помощью ИИ, а делимся нашим кейсом такой оптимизации.
Итак, поехали!
MCP как мостик между IDA Pro и LLM
Для начала минутка занудства теории о том, как в принципе подружить между собой языковую модель и IDA Pro.
Сконнектить LLM с внешними системами можно, например, при помощи специализированных API или прямых запросов к базам данных. Это тот еще квест: приходится адаптировать модель под новые программные интерфейсы или структуры БД. Поэтому я решил использовать более простой, универсальный и изящный подход — стандарт MCP (Model Context Protocol), разработанный компанией Anthropic. Стандарт описывает, как большие языковые модели (LLM) получают доступ к сторонним данным и инструментам.
В основе MCP лежит клиент-серверная архитектура из трех компонентов.
Хост — это приложение, которое использует LLM и инициирует работу MCP-клиента. В нашем случае в качестве хоста применяется Claude Code CLI. Как отмечают эксперты, эта модель демонстрирует высокую эффективность при работе с кодом. Хотя можно использовать любую другую LLM, но к этому вернемся чуть позже.
MCP-клиент — интегрирован в хост и управляет сетевыми соединениями с MCP-серверами.
MCP-сервер — предоставляет нейронке доступ к конкретным данным или функциям. В нашем случае применяется ida-pro-mcp — плагин для клиента Claude Code, который и является MCP-сервером.
Как работает связка между IDA Pro и LLM и как обрабатывается запрос
Перейдем от теории к практике и посмотрим, как всё это работает в нашем тандеме нейронки и IDA Pro. Весь процесс делится на несколько ключевых шагов.
Шаг 1. Я загружаю промпт с задачей по реверс-инжинирингу в MCP-клиент. Подробнее про сам промпт расскажу чуть позже, когда перейдем к тестированию, а пока пойдем дальше по процессу.
Получив промпт, MCP-клиент передает информацию в MCP-сервер через стандартный поток выводов (Standard Input/Output) и сразу же запрашивает список доступных инструментов. Условно говоря, клиент выступает в роли API между сервером и моделью и показывает, какие функции доступны для получения или изменения данных из IDA Pro. Можно запросить имя файла, что-то выделить, переименовать функции, то есть заменить их непонятные названия на более прозрачные (например, sub_0012A4B0 — на encrypt_files, то есть «шифровать файлы»).
Шаг 2. MCP-клиент формирует для LLM контекст, который включает системную инструкцию (грубо говоря, заданные по умолчанию «правила игры» для LLM, которые помогают ей корректно понять задачу и взаимодействовать с IDA Pro), полученный от сервера список доступных инструментов, текущий запрос пользователя. Заодно предоставляется история переписки и все предыдущие промпты по задаче, если такие были, и требуются дополнительные действия (например, переименовать оставшиеся функции).
На основе всей этой структурированной информации LLM принимает решение, нужно ли ей обращаться к IDA Pro.
Разумеется, IDA Pro больше не понадобится, если запрос не касается разбора файлов и реверс-инжиниринга. Скажем, вы поймали музу за хвост и просите нейронку написать стихотворение (бывает и такое) или, возвращаясь к вирусной аналитике, предоставить информацию о структуре PE-файла.
Если же запрос так или иначе связан с разбором бинарного файла, то обращение к IDA Pro необходимо. В таком случае весь анализ строится вокруг данных, загруженных в среду для реверс-инжиниринга.
Шаг 3. MCP-сервер направляет POST-запрос в IDA Pro. При этом сервер использует возможности idalib: открывает файл в среде реверс-инжиниринга (в режиме без gui) с помощью ее библиотеки, потом выполняет определенную функцию, например, get_input_file_path(). Сформированный ответ на запрос возвращается в формате JSON на MCP-сервер.
Шаг 4. MCP-сервер форматирует полученный результат как ответ для нейронки и отправляет его MCP-клиенту, а тот передает данные обратно в LLM. Модель формирует отчет, пишет YARA-правила и т. д.
Подчеркну, что в нашей схеме MCP-клиент и MCP-сервер работают на одной машине, то есть локально. Обмен данными на каждом этапе идет через стандартный поток выводов. При этом MCP-сервер запускается как дочерний процесс, а хост передает ему JSON-RPC-запросы через stdin/stdout.
Описанный цикл может повторяться несколько раз за один запрос пользователя, пока модель не соберет всю необходимую для финального ответа информацию. Оформление вызова инструмента зависит от реализации конкретного клиента и, по сути, не влияет на мою работу.
Получить же итоговый результат можно либо прямо в IDA Pro в виде комментариев и переименованных функций, либо отдельным отчетом или текстом от модели. Это зависит от требований, которые аналитик пропишет в запросе.
Преимущества подхода
Существенный плюс такой схемы — возможность использовать любую модель и поддерживающий ее MCP-клиент. Неизменной остается лишь серверная часть — та самая ida-pro-mcp.
Другое преимущество — минимальная нагрузка на «железо». Обработка запросов моделью выполняется на стороне провайдера LLM. В данном случае — на серверах Anthropic, где локализуется применяемый нами Claude Code. Пользователю потребуются лишь ресурсы, необходимые для запуска и работы самой IDA Pro.
Установка и настройка
С принципами взаимодействия LLM и IDA Pro через MCP-протокол и преимуществами подхода в общих чертах разобрались. А что насчет настроек? Ловите пошаговую инструкцию, как развернуть MCP-сервер и клиент.
Сразу оговорюсь, что это не такая уж легкая прогулка для специалиста, погруженного исключительно в вирусную аналитику и далекого от системного администрирования или разработки. Придется поработать со скриптами, командной строкой и Python-окружением. Однако разобраться во всем вполне реально — и оно того стоит.
Устанавливаем Claude Code и uv.
claude - irmhttps://claude.ai/install.ps1| iex uv - powershell -ExecutionPolicy ByPass -c "irmhttps://astral.sh/uv/install.ps1| iex"Перезапускаем PowerShell, чтобы обновились переменные окружения.
Включаем на компьютере прокси и перенаправляем через него трафик Claude, прописав такое условие в конфигурации claude:
(C:\Users\<USER_NAME>\.claude\settings.json):json{"env": {"HTTP_PROXY": "http://127.0.0.1:10808","HTTPS_PROXY": "http://127.0.0.1:10808"}}Устанавливаем плагин ida-pro-mcp в Claude Code:
powershellclaude plugin marketplace add mrexodia/claude-marketplaceclaude plugin install ida-pro-mcp@mrexodia
Активируем idalib:
powershelluv run "C:\Program Files\IDA Professional 9.3\idalib\python\py-activate-idalib.py"Проверяем работу MCP. Для этого заходим в папку с файлом, который собираемся проанализировать с IDA Pro, открываем powershell, запускаем Claude командой
claude. Далее вводим запрос:Using ida pro mcp write file metadata.
Если в выводе Сlaude нет ошибок и выводятся метаданные, то всё работает корректно.
Ограничения автоматизации
Впрочем, прежде чем браться за настройки, важно трезво осознать возможности автоматизации. На первый взгляд кажется, будто весь анализ можно переложить на модель. Увы, это лишь в теории — на практике возникает ряд нюансов.
Во-первых, модель плохо разбирает обфусцированный код, поэтому реверс-инженеры могут не спешить менять профессию. Получившуюся связку LLM и IDA Pro стоит рассматривать как инструмент для ускорения первичного анализа, а не тотальную замену живому специалисту.
Во-вторых, неясно, насколько модель покрывает матрицу MITRE ATT&CK в своих отчетах. LLM перечисляет техники атак на основе того, что смогла разобрать из имеющихся данных по итогам анализа, но это не гарантирует исчерпывающий список возможных методов использования вредоноса.
В-третьих, декомпилировать программу и преобразовывать машинный код в более читаемый вид всё равно приходится вручную. Еще требуется подтверждать операции в диалоговых окнах в IDA Pro, которые появляются при работе с моделью. Claude Code по умолчанию запрашивает разрешение на каждое действие в среде для реверс-инжиниринга, хотя такую проверку, вероятно, можно отключить в настройках. Если вы знаете, как это сделать, напишите об этом в комментариях.
Словом, запустить анализ вредоноса, уйти на прогулку и по возвращении получить полностью готовый результат вряд ли получится. Но это в любом случае намного удобнее и быстрее, чем всё делать вручную.
Тестирование: два семпла — три прогона
Перефразируя известную поговорку, «ограничений автоматизации бояться — в вирусную аналитику не ходить». И всё же я решил как следует протестировать получившуюся связку, прежде чем внедрять ее в постоянную работу и выполнять боевые задачи.
Я взял два семпла разной сложности. В первом образце использовал string.exe — простую утилиту из пакета Sysinternals. Во втором — полезную нагрузку ValleyRAT. Этот семпл заметно сложнее, так как в нем больше кода, а импортируемые функции скрыты обфускацией.
Для анализа применялся готовый и давно обкатанный другими пользователями плагина промпт из официального репозитория ida-pro-mcp на GitHub. В оригинале этот шаблон включает пять пунктов и рассчитан на реверс произвольного приложения без привязки к вирусной аналитике. Я дописал еще один пункт под названием Malware Detection — непосредственно с задачами анализа вредоносного ПО. В нем я поручил модели написать YARA-правила для детектирования файла и зафиксировать техники MITRE ATT&CK на русском языке. Отдельно уточнил, что модель должна напрямую указать в выводах, является ли исследуемый файл вредоносным.
Результаты тестирования
В общей сложности было выполнено три прогона. Забегая вперед, результаты получились хорошие, удовлетворительные и отличные соответственно. Рассмотрим каждый из них.
Первый прогон: string.exe отработал, но не впечатлил
На простом примере со string.exe мой промпт отработал без замечаний с первого раза. Модель выявила и переименовала функции последовательности действий. Еще LLM добавила уточняющие комментарии к разобранным функциям (хотя и не ко всем) и составила подробный отчет с описанием потока выполнения и выводом о легитимности файла. Нейронка также перечислила техники MITRE ATT&CK и написала YARA-правило, детектирующее файл. Задачу можно считать выполненной в достаточном объеме. Приемлемо, но без «вау-эффекта».
Второй и третий прогоны: ValleyRAT без подготовки и с обфускацией
Во втором прогоне я запустил тот же промпт без изменений, чтобы проверить поведение модели при анализе более сложного файла. К сожалению, LLM не справилась с обфускацией импортируемых функций и переименовала только 5% из них.
На всякий случай поясню, что в самой IDA Pro по умолчанию присутствуют описания для основных, часто встречающихся функций. Однако определить их назначение должен уже реверс-инженер. Следовательно, у меня была возможность использовать IDA в качестве дополнительного источника информации и сверяться с её подсказками.
Возвращаясь к результатам прогона, модель не смогла восстановить основной поток выполнения программы. Инициализация классов объектов, анализ их внутренних методов и функций — всё это осталось за рамками теста.
Всё же отчет получился достаточно точным. Модель верно определила файл как троян, составила краткий список техник MITRE ATT&CK на основе разобранных функций и написала рабочие YARA-правила. LLM даже предложила отдельное правило, как выявлять использование утилитой протокола KCP. Итог можно считать удовлетворительным. Полного разбора файла не получилось, но для написания правил детектирования данных оказалось достаточно.
Я решил не останавливаться на достигнутом и выжать максимум из теста с ValleyRAT. Для третьего прогона я вручную снял обфускацию и определил все импортируемые функции, после чего заново запустил тот же промпт. Затем попросил модель вернуться к оставшимся неразобранным функциям и прокомментировать их.
Бинго! В этот раз модель восстановила весь основной поток выполнения программы, разобрала ключевые классы объектов и их методы и, самое главное, проанализировала протокол взаимодействия с C2.
Результат получился выше всех похвал. Модель смогла проанализировать вредоносное ПО так же глубоко, как живой специалист, а по некоторым аспектам даже лучше.
Выводы и планы
Повторюсь, что связка IDA Pro и LLM через MCP не заменяет реверс-инженера, но заметно снижает рутину и ускоряет процесс, особенно при разборе простых семплов без обфускации. В более сложных случаях модель требует подключения аналитика на этапе снятия обфускации. Но и в таких кейсах автоматизация экономит часы, а порой и дни работы при анализе логики и написании правил детектирования.
Если вручную я успел разобрать похожий семпл лишь на 50% за неделю, то при втором прогоне связки IDA Pro и LLM на ValleyRAT даже больший объем работ был сделан всего за два часа. Правда, мне всё же пришлось самому снять обфускацию и выполнить ряд других действий.
Оптимизация оптимизацией, но не стоит забывать о требованиях конфиденциальности и безопасности данных. Здесь в LLM улетают не сами исполняемые файлы, а текстовые данные из IDA Pro (разобранный код, имена функций, метаданные). Такая информация не кажется «тайной за семью печатями», которую не следует отправлять на внешние серверы. Хотя окончательный вердикт о допустимости подобного использования LLM зависит от политики безопасности конкретной компании.
Теперь коротко о последних тестах и эволюции подхода. Во-первых, со временем мне пришлось отказаться от модели Claude и перейти на Codex. Первая начала распознавать вирусы в тестируемых файлах и отказывается проводить анализ. Во-вторых, я стал анализировать часть файлов с помощью Ghidra, так как IDA Pro почему-то не открывает базы с некоторыми exe (в чем причина — пока непонятно, но я планирую это выяснить).
Еще мне удалось получить интересные результаты по итогам анализа вируса Vidar. У этого стиллера есть главный загрузчик, который скачивает из интернета много дополнительных вредоносных исполняемых файлов. Они, в свою очередь, содержат зашифрованную с помощью xor полезную нагрузку в data-секции, а также динамически подключаемые библиотеки, которые ищутся по хэшам имен. Эти два момента уже являются обфускацией. После перехода на Codex такая обфускация обходится и разбирается самой LLM, а вредонос и полезная нагрузка анализируются в полном объеме.
Впрочем, в описанном случае мы имеем дело с базовой обфускацией. Пока что неясно, справиться ли модель с анализом более сложного обфусцированного кода. Большинство обфускаций по-прежнему снимается динамическим анализом в дебагере. Но, как оказалось, к нему тоже можно подключить LLM. Только это уже тема для отдельной статьи.
И напоследок пару слов о планах. Задача на ближайшую перспективу — доработка промпта: его дополнение конкретными данными и недостающими инструкциями по результатам тестов.
Более глобальная цель на будущее — развитие автоматизации. Например, можно написать скрипт для автоматической загрузки семплов в IDA Pro, чтобы такая задача решалась без участия аналитика.
А вы уже пробовали подключать LLM к инструментам анализа? Не стесняйтесь и делитесь своим опытом в комментариях.
