Invitation Is All You Need! TARA for Targeted Promptware Attack Against Gemini-Powered Assistants
Nassi et al., 2025
Статья, сайт

Попалась любопытная работа израильских исследователей (это, кстати, те же ребята, что назвали инъекцию в симулированный почтовый клиент Morris II, представленная на Blackhat, про непрямые промпт-инъекции в андроидовском ассистенте Gemini, которые были актуальны в феврале этого года. В статье куча всякой скукоты типа специального фреймворка оценки рисков и попытки продвинуть придуманный ими термин promptware, но главное то, что они научились с помощью приглашения в календарь выключать пользователю свет 🔪

Суть атаки проста. Пользователю отправляется приглашение в календарь. В приглашении содержится промпт-инъекция, которая просит у Gemini выполнить определенную инструкцию при несложном условии: например, если пользователь скажет «спасибо» или использует слово длиннее двух букв. Чтобы цепочка сработала, пользователь должен попросить у ассистента список ближайших задач в календаре.

Используя такую нехитрую технику, исследователи заставляют ассистента:

1. Генерировать оскорбительные тексты, надоедать спам-ссылками с рекламой или фишингом.
2. Отравление долгосрочной памяти, приводящее к неверным ответам.
3. Атаки на агента, включая удаление случайных встреч из календаря.
4. Атаки на других агентов. Ассистент состоит из агента-оркестратора и узконаправленных агентов, типа агента для календаря. Поскольку инъекция попадает в контекст оркестратора, исследователям удалось дать команды агенту Google Home включить и выключить свет, открыть окна и включить бойлер. Эксплуатация агента Utilities позволила им скачать на смартфон файл (раскрыв геолокацию пользователя), запустить встречу в Zoom и вытащить через браузер названия встреч, содержание писем и другую информацию (закодировав их в URL).

В качестве противодействия таким атакам исследовали рекомендуют ограничивать возможности межагентного взаимодействия, последовательного запуска многих инструментов (то есть вещи, которые делают агентов прикольными), а также использовать гардрейлы и Control Flow Integrity (типа CaMeL). Из любопытного: бросается в глаза простота тех промпт-инъекций, которыми пользовались исследователи, что несколько пугает в сочетании с простотой киллчейна. Кажется, что пока давать LLM-инструментам, которые могут случайно снести вам Windows, контроль над физическими системами – будь то роботы или лампочки – пока рано.

BinMetric: A Comprehensive Binary Analysis Benchmark for Large Language Models
Shang et al., Hefei University of Science and Technology, 2025
Статья

Одним из интересных применений LLM является их использование в реверс-инженерии, она же обратная разработка. LLM легко видят взаимосвязи в длинных листингах псевдокода, помнят все опкоды и могут довольно неплохо понимать, что делает та или иная декомпилированная функция. Или нет? С одной стороны, существует достаточно много плагинов, типа Gepetto для IDA или Sidekick для Binary Ninja, которые делают разные полезные вещи, типа замены названий переменных в C-подобном псевдокоде на человекочитаемые, что очевидно требует понимания семантики кода. С другой стороны, как оценить, насколько хорошо это работает? Для этого нужны бенчмарки, и сегодня мы поговорим об одном из них – BinMetric.

Исседователи из Китайского университета технологий в Хэфэе предлагают бенчмарк, который с разных сторон оценивает способность LLM к задачам анализа бинарных файлов. Бенчмарк состоит из 6 задач:
1. Call-site Reconstruction (CSR): на входе LLM подается кусок ассемблерного кода и адрес вызова, на выходе ожидается C-подобная строка с названием функции и аргументов. В качестве метрики используется CodeBLEU и Rouge-L.
2. Decompilation (DEC): на вход подается ассемблерный код, соответствующий одной функции, на выходе ожидается С-подобный листинг этой функции. Метрики те же.
3. Signature Recovery (SR): на вход подается псевдокод функции от декомпилятора, на выходе ожидается сигнатура функции (название с параметрами). Метрики – BLEU, METHEOR и ROUGE-L.
4. Binary Code Summarization (BCS): на вход – снова псевдокод функции после декомпилирования; на выходе ожидается описание функции на естественном языке. Метрики – как в SR.
5. Algorithm Classification (AC): LLM должна определить тип алгоритма (сортировка, шифрование и так далее) на основе псевдокода. Оценивается точность.
6. Assembly Instruction Generation (AIG): самая любопытная задача – генерация ассемблерного кода по промпту. Код оценивается с помощью ROUGE, а также на прохождение юнит-тестов.

Чтобы собрать такой бенчмарк, исследователи используют код открытых проектов на C – от curl до llama2.c – код которых они компилируют, собирая артефакты DWARF и удаляя символьную информацию. Для компиляции используются рекомендованные разработчиками параметры компиляции, чтобы получить разнообразие. Затем бинари дизассемблируют и декомпилируют с помощью IDA, после чего с помощью DWARF получают выравнивание между сорцами и результатом работы IDA. Далее исследователи удаляют слишком длинные и слишком короткие функции, после чего семплируют данные для задач. Для BCS применяется ChatGPT, чтобы получить описания функций на базе исходного кода. Задачи для AC семплируются из C-Algorithms. Для AIG исследователи пишут вручную 100 промптов и разрабатывают под каждую задачу алгоритмы. На все у них уходит 60 человеко-часов, что кажется некоторым преуменьшением.

К сожалению, само исследование, видимо, проводилось давно (опубликована статья в мае этого года), поэтому на своем бенче исследователи гоняют Llama-2-7B, Mistral-7B, Mixtral (хорошая была модель, олды помнят), WizardCoder и CodeLlama-32B, из закрытых – GPT-3.5 и GPT-4. Кроме того, на соответствующих задачах оценивается BinT5, HexT5 и LLM4Decompile. Лучшими моделями (не удивительно) оказываются GPT-4 и большие кодинговые модели типа CodeLlama, конкретные цифры можно посмотреть в табличке, пересказывать их ввиду неактуальности в 2025 году смысла нет.

Из любопытного – видно, что LLM достаточно неплохо превращают asm в псевдокод – лучше по метрикам, чем Hex-Rays. С генерацией ассемблера ни одна из LLM ожидаемо не справилась. Сам бенчмарк кажется очень интересным, и было бы любопытно посмотреть на него в контексте более современных моделей. С другой стороны, есть и чем расширить – например, оценкой правильности переименования переменных, что делает Gepetto, или анализом более широким, чем одна функция, кроме того, в открытом доступе бенчмарк найти пока не удалось. О таких бенчмарках мы еще поговорим.

LLM4Decompile: Decompiling Binary Code with Large Language Models
Tan et al., 2025
Статья, Github, Huggingface

Сегодня посмотрим на чуть более сфокусированный бенчмарк: Decompile-Eval. Исследователи обращают внимание, что LLM могут потенциально помогать с декомпиляцией бинарей (переводом кода из asm в C), выдавая более читаемый и близкий к оригиналу код, чем традиционные инструменты вроде Ghidra или Hex-Rays. Чтобы проверить, так ли это, исследователи тюнят свои модели для декомпиляции и предлагают новый бенчмарк, который оценивает качество получившегося кода.

В статье описывается две постановки задачи: Refined-Decompile и End2End-Decompile. В постановке Refined-Decompile модель получает на вход псевдокод после традиционного декомпилятора и должна улучшить его читаемость. В End2End-Decompile на вход LLM получает asm, из которого она должна сгенерировать качественный псевдокод. Для самой задачи декомпиляции исследователи используют ExeBench, набор из 5 миллионов компилируемых C-файлов размером с функцию, для некоторых из которых даны тестовые входы-выходы для оценки корректности. Исследователи компилируют эти файлы с помощью GCC с четырьмя уровнями оптимизации (что, как метко указывают авторы, работает как аугментация данных), а затем дизассемблируют, получая после фильтрации 7,2 миллиона компилируемых пар asm+исходник на C и 1,6 миллионов исполняемых. На этих парах исследователи тюнят deepseek-coder трех размеров (1,3B, 6,7B и 33B). Средняя по размеру модель обучается 61 день на 8xA100.

Для оценки результатов в постановке End2End вводится два бенчмарка – HumanEval-Decompile и ExeBench. HumanEval-Decompile использует как основу оригинальный HumanEval, но все питоновские функции переводятся на C. Из ExeBench берутся 5 тысяч функций, для которых есть пары вход-выход. Модели засчитывается балл, если декомпилированный код компилируется и проходит тесты. В качестве бейзлайнов тестируют gpt-4o и deepseek-coder-6.7B. В результате затюненный deepseek-coder-6.7B показывает лучшие результаты с ~36% на HumanEval-Decompile и ~16% на ExeBench при включенной оптимизации. Та же модель без тюнинга показывает качество, равное нулю, а gpt-4o – 10% и 4%, соответственно. 33-миллиардная модель показывает себя неплохо, но затюнить ее исследователям по причине размера не удалось.

В постановке Refined исследователи используют в качестве источника при «переводе» псевдокод от Ghidra, по которому LLM должна воспроизвести исходный код функции. На парах псевдокод-исходник исследователи обучают модели, к которым добавляется Codestral-22B и Yi-9B. Код, генерируемый гидрой, корректно рекомпилируется в 15% случаев на HumanEval-Decompile. Если пропустить его через gpt-4o, то получается ~30%, а вот затюненные модели дают гораздо лучшие результаты – от ~45% у 6,7B до ~58% у Codestral (если смотреть на кейсы с оптимизацией). В приложении есть еще оценка Yi-Coder, который при размере в два раза меньше соревнуется с французами (УДАР!) При этом метрика edit similarity оказывается менее чувствительной и растет при увеличении модели субъективно незначительно. Наконец, исследователи используют gpt-4o для оценки читаемости псевдокода гидры, улучшений от gpt-4o (никакой предвзятости) и от затюненного ds-coder-6.7B, и последний побеждает даже в этой нечестной борьбе.

Исследование достаточно качественное (не зря оно, в отличие от многого в этом канале, было опубликовано на приличной конференции), исследователи продолжают обновлять свои модели и выкладывать их на HF. Видно, что LLM могут помогать при анализе бинарей, особенно на уровне функций. Понятно, что и тут есть ограничения – тот же контекст одной функции, С (причем именно gcc на *nix), а также падение качества на 80-90% при применении обфускции. Тем не менее, исследование демонстрирует, что LLM в рутине реверсера могут быть очень полезны.

(Внимательный читатель может заметить, что в статье не упоминается Decompile-Eval. Дело в том, что название появилось в препринте, который к публикации сильно изменился, но название продолжает гулять по интернету, в том числе легко достается LLM-ассистентами).

DecompileBench: A Comprehensive Benchmark for Evaluating Decompilers in Real-World Scenarios
Gao et al., 2025
Статья, github

Еще одна работа про оценку качества декомпиляции на уровне функций, и снова от китайских исследователей. Авторы представляют оценку 12 разных «декомпиляторов» (6 традиционных, 4 LLM общего назначения и 2 специализированные LLM) сразу по большому количеству метрик на датасете, созданном на базе проекта OSS-Fuzz.

Идея следующая. OSS-Fuzz предоставляет проекты, скомпилированные clang с включенным coverage sanitizer, что позволяет оценивать поток исполнения и покрытие фаззинговыми тестами.С помощью clang-instruct они извлекают функции, покрытые фаззированием, и компилируют их в отдельные .so-файлы. Эти файлы, состоящие из одной функции, теперь можно декомпилировать. Дальше проверяется две метрики: доля декомпилированных той или иной системой функций, которые скомпилировались обратно (CAR, Compiler Aspect Report), и более интересный Runtime-Aspect Report: после обратной компиляции (если скомпилировалось), пайплайн фазирования запускается с бинарем с оригинальной и рекомпилированной функцией и проверяется, меняется ли степень покрытия. Если покрытие поменялось, значит, декомпилятор не справился и допустил где-то логическую ошибку, что изменило поток управления. Общий объем корпуса – 23400 функций из 130 проектов. Дополнительно к этому проверяются метрики читаемости, которых аж 12: от правильности приведения типов до семантики имен переменных (подробнее на radar-графике). Эти метрики оцениваются LLM-as-judge, причем судье (qwen-2.5-coder-32B) предъявляются оригинальный код и пара декомпилированных примеров, он выбирает победителя, что позволяет посчитать ELO.

Лучшим декомпилятором по формальным метрикам оказывается, что неудивительно, Hex-Rays. Причем LLM, которые в этой постановке лишь улучшали аутпут Hex-Rays, делали код лишь менее корректным. Однако когда речь идет о читаемости, LLM получают значительно более высокие оценки, причем на первых местах находятся LLM, специально заточенные под декомпиляцию – проприетарная MLM и открытая LLM4Decompile. Исследователи дают двум аннотаторам проверить 30 декомпилированных сэмплов (что, как признают сами авторы, не очень большой набор данных для оценки) и получают согласие с оценками LLM-as-judge, измеренное как каппа Коэна, равное 0,778.

В статье указывается, что основной проблемой LLM, разумеется, являются галлюцинации: они придумывают фантомные заголовочные файлы, несуществующие типы, иногда удаляют из функций параметры. Однако повышение понятности кода и близости его по семантике к оригинальному приводит авторов к мысли, что в сценариях, где нужен быстрый анализ, например при реверсе малвары, преимущества LLM могут компенсировать эти недостатки. Хотя статья оставляет без ответа некоторые вопросы (например, какого качества добился ли бы на этом датасете LLM4Decompile-Refine поверх Ghidra – в конце концов, почему gpt4o работала поверх Hex-Rays, а LLM4Decompile потреблял сырой asm), она показывает, что, возможно, слепо переходить с традиционных инструментов на LLM в реверсе пока рано, но потенциал помощи специалистам у них довольно велик.

XBOW Unleashes GPT-5’s Hidden Hacking Power, Doubling Performance
De Moor, Ziegler, XBOW, 2025
Блог

XBOW, компания, занимающаяся автономным тестированием на проникновение с помощью LLM-агентов, опубликовала блог о том, как они заменили комбинацию из Claude Sonnet + Gemini в своем агенте на GPT-5 и получили большое улучшение качества. После смены базовой LLM на GPT-5 их агент, по их словам, стал находить больше уязвимостей, делать это более надежно и за меньшее количество итераций. Кроме того, они заметили, что GPT-5 реже пытается исследовать очевидно тупиковые пути и генерирует значительно более сложные команды для терминала с меньшим числом ошибок. Результатом смены LLM стало не только повышение доли решенных задач на внутреннем бенчмарке с менее 60% до более 80% (что значит, что бенч пора менять), но и рост хитрых метрик типа «вероятность взлома ранее взломанной другой моделью цели с первого раза», и «числа взломанных публичных целей (видимо, с HackerOne) за одно и то же время по сравнению с предыдущей моделью».

Любопытно это в том числе потому, что сами OpenAI отмечали в System Card к GPT-5, что ее способности к решению наступательных задач не сильно отличаются от предыдущих моделей, таких как o3 (во всяком случае, так заявляют ребята из XBOW; в System Card написано, что внешняя оценка от Pattern Labs показала, что прогресс по сравнению с o3 значителен). Тут можно вспомнить статью от Palisade Research, где они утверждают, что способности LLM к кибератакам наступательной безопасности недопроявлены, т.е. LLM куда лучше в атаках, чем мы думаем, просто системы, которые мы строим вокруг них несовершенны. Если агентные обертки будут более мощными, может выяснится, что способностей у LLM куда больше. XBOW описывают свою систему как а) имеющую специализированные инструменты, написанные специально для LLM, которые делают тулы типа BurpSuite, сделанные для людей, доступными для человека в удобном формате, б) имеющую мультиагентное устройство, с разными субагентами для разных типов уязвимостей и центральным координатором. По опыту, если решить проблемы с инструментами – LLM все еще очень сложно работать с терминалом, особенно с реверс-шеллами и тулами со своей кастомной консолью – можно достаточно дешево получить рост результативности агентов, возможно, появление у каждого инструмента MCP-интерфейса смягчит эту проблему.

Хотя LLM для редтиминга – это очень перспективное, на мой взгляд, направление, а XBOW делают очень прикольные вещи и, вероятно, лучшие в этом направлении, в этом блоге, с его странными метриками и резкими скачками на закрытых бенчмарках (Стал ли агент решать больше на 1 класс задач, которых в бенчмарке 20%? Проверить невозможно), месседж в основном маркетинговый, и радикальных изменений прямо сейчас ожидать не стоит. Тем не менее, общий фон игнорировать невозможно: LLM-агенты не только пентестят, занимая первые места на лидербордах, но и находят уязвимости в исходном коде и реверсят APT-бинари. Станет ли кибербезопасность уделом тех, у кого много видеокарт? Все возможно, но лишними пара видеокарт точно не будет.