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-ассистентами).
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 в реверсе пока рано, но потенциал помощи специалистам у них довольно велик.
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 в реверсе пока рано, но потенциал помощи специалистам у них довольно велик.
🦄3
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-бинари. Станет ли кибербезопасность уделом тех, у кого много видеокарт? Все возможно, но лишними пара видеокарт точно не будет.
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-бинари. Станет ли кибербезопасность уделом тех, у кого много видеокарт? Все возможно, но лишними пара видеокарт точно не будет.
👍7