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
tgoop.com/llmsecurity/607
Create:
Last Update:
Last Update:
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 в реверсе пока рано, но потенциал помощи специалистам у них довольно велик.
BY llm security и каланы
Share with your friend now:
tgoop.com/llmsecurity/607