🪲 x64dbg: реверс-инжиниринг и анализа вредоносного ПО
🔍 x64dbg — это популярный бинарный open-source отладчик для Windows, созданный для анализа вредоносного ПО и реверс-инжиниринга исполняемых файлов без доступа к исходному коду. Благодаря своему удобному интерфейсу и мощному набору функций, x64dbg стал незаменимым инструментом для специалистов по кибербезопасности.
📊 Особенности x64dbg:
- С-подобный парсер выражений — позволяет писать и выполнять сложные выражения.
- Отладка DLL и EXE — полная поддержка отладки как динамических библиотек, так и исполняемых файлов (с использованием TitanEngine).
- Интерфейс, похожий на IDA — боковая панель с указателями переходов и выделением токенов инструкций, регистрами и другими элементами.
- Память и вид потоков — возможность просмотра и анализа структуры памяти и активных потоков в процессе.
- Графический и текстовый режимы — поддержка как графического, так и режима просмотра исходного кода, что упрощает анализ.
- Поддержка плагинов — система расширений, позволяющая настраивать и добавлять новые функции с помощью плагинов.
- Скриптовый язык — возможность автоматизации задач через расширяемый язык сценариев.
- Встроенный дизассемблер и ассемблер — быстрый дизассемблер (Zydis) и встроенный ассемблер для создания и редактирования кода.
- Патчинг исполняемых файлов — поддержка редактирования и модификации исполняемых файлов на лету.
🔗 Заключение
x64dbg — интересный инструмент для исследователей и специалистов по безопасности, позволяющий эффективно анализировать и изменять поведение программ.
🔗Ссылка на GitHub.
Stay secure and read SecureTechTalks 📚
#x64dbg #ReverseEngineering #CyberSecurity #MalwareAnalysis #SecureTechTalks #Кибербезопасность
🔍 x64dbg — это популярный бинарный open-source отладчик для Windows, созданный для анализа вредоносного ПО и реверс-инжиниринга исполняемых файлов без доступа к исходному коду. Благодаря своему удобному интерфейсу и мощному набору функций, x64dbg стал незаменимым инструментом для специалистов по кибербезопасности.
📊 Особенности x64dbg:
- С-подобный парсер выражений — позволяет писать и выполнять сложные выражения.
- Отладка DLL и EXE — полная поддержка отладки как динамических библиотек, так и исполняемых файлов (с использованием TitanEngine).
- Интерфейс, похожий на IDA — боковая панель с указателями переходов и выделением токенов инструкций, регистрами и другими элементами.
- Память и вид потоков — возможность просмотра и анализа структуры памяти и активных потоков в процессе.
- Графический и текстовый режимы — поддержка как графического, так и режима просмотра исходного кода, что упрощает анализ.
- Поддержка плагинов — система расширений, позволяющая настраивать и добавлять новые функции с помощью плагинов.
- Скриптовый язык — возможность автоматизации задач через расширяемый язык сценариев.
- Встроенный дизассемблер и ассемблер — быстрый дизассемблер (Zydis) и встроенный ассемблер для создания и редактирования кода.
- Патчинг исполняемых файлов — поддержка редактирования и модификации исполняемых файлов на лету.
🔗 Заключение
x64dbg — интересный инструмент для исследователей и специалистов по безопасности, позволяющий эффективно анализировать и изменять поведение программ.
🔗Ссылка на GitHub.
Stay secure and read SecureTechTalks 📚
#x64dbg #ReverseEngineering #CyberSecurity #MalwareAnalysis #SecureTechTalks #Кибербезопасность
🎯 libdebug создаем свой отладчик:
Когда стандартные инструменты не справляются — ты создаёшь свои. Именно так поступили исследователи из Politecnico di Milano, представив libdebug — мощную Python-библиотеку для программируемой отладки бинарников в userland-пространстве.
🧩 Что такое libdebug?
🔧 libdebug — open-source Python-библиотека, позволяющая создавать собственные отладчики. Вместо интерфейсов, ориентированных на человека, как в GDB, libdebug создан для автоматизации и гибкой интеграции. Она ориентирована не только на разработчиков, но и на специалистов по безопасности, реверс-инженеров и исследователей уязвимостей.
📦 GitHub: libdebug
📚 Документация: docs.libdebug.org
🚀 Что умеет libdebug?
🧠 Управление регистрами, памятью, syscalls и сигналами
🛠 Поддержка брейкпоинтов и watchpoint'ов
🧵 Поддержка многопоточности
🖥️ Работа с потоками ввода-вывода процесса
🔄 Не требует отладки с debug-символами — работает с «сырыми» бинарниками
🌍 Поддержка архитектур AMD64 и AArch64
А главное — всё это через чистый Python-интерфейс, без боли ptrace и низкоуровневых API.
🔬 Три крутых кейса использования
1️⃣ 🎛️ Отладка байт-кода
libdebug позволяет "влезть" в интерпретаторы вроде CPython и отслеживать/модифицировать опкоды прямо во время исполнения. Хочешь, чтобы + внезапно стал -? Без проблем.
2️⃣ 🧨 Автоматический поиск уязвимостей
Используя libdebug, можно ловить SIGSEGV, анализировать память и даже программно экспериментировать с эксплойтами. Это удобно при fuzzing-анализе или поиске точек входа для RCE.
3️⃣ 🧪 Юнит-тесты и покрытие
Инструмент может использоваться для динамического анализа покрытия кода, включая ветвления и редкие сбои (например, ошибка при malloc или чтении из файла). Всё это легко интегрируется в CI/CD.
💡 Исходники примеров: libdebug/examples
⚔️ Бенчмарки: GDB против libdebug
libdebug обрабатывает брейкпоинты и syscalls в 3–4 раза быстрее, чем GDB с Python-обвязкой
Скрипты для воспроизводимости: benchmark suite
⌛ Это огромный плюс для задач, где важна скорость реакции: от fuzzing до runtime-мониторинга.
Stay secure and read SecureTechTalks 📚
#SecureTechTalks #libdebug #ReverseEngineering #Python #Debugging #CyberSecurity #CTF #BugHunting #ExploitDev #SecurityResearch #DevSecOps #OpenSourceTools
Когда стандартные инструменты не справляются — ты создаёшь свои. Именно так поступили исследователи из Politecnico di Milano, представив libdebug — мощную Python-библиотеку для программируемой отладки бинарников в userland-пространстве.
🧩 Что такое libdebug?
🔧 libdebug — open-source Python-библиотека, позволяющая создавать собственные отладчики. Вместо интерфейсов, ориентированных на человека, как в GDB, libdebug создан для автоматизации и гибкой интеграции. Она ориентирована не только на разработчиков, но и на специалистов по безопасности, реверс-инженеров и исследователей уязвимостей.
📦 GitHub: libdebug
📚 Документация: docs.libdebug.org
🚀 Что умеет libdebug?
🧠 Управление регистрами, памятью, syscalls и сигналами
🛠 Поддержка брейкпоинтов и watchpoint'ов
🧵 Поддержка многопоточности
🖥️ Работа с потоками ввода-вывода процесса
🔄 Не требует отладки с debug-символами — работает с «сырыми» бинарниками
🌍 Поддержка архитектур AMD64 и AArch64
А главное — всё это через чистый Python-интерфейс, без боли ptrace и низкоуровневых API.
🔬 Три крутых кейса использования
1️⃣ 🎛️ Отладка байт-кода
libdebug позволяет "влезть" в интерпретаторы вроде CPython и отслеживать/модифицировать опкоды прямо во время исполнения. Хочешь, чтобы + внезапно стал -? Без проблем.
2️⃣ 🧨 Автоматический поиск уязвимостей
Используя libdebug, можно ловить SIGSEGV, анализировать память и даже программно экспериментировать с эксплойтами. Это удобно при fuzzing-анализе или поиске точек входа для RCE.
3️⃣ 🧪 Юнит-тесты и покрытие
Инструмент может использоваться для динамического анализа покрытия кода, включая ветвления и редкие сбои (например, ошибка при malloc или чтении из файла). Всё это легко интегрируется в CI/CD.
💡 Исходники примеров: libdebug/examples
⚔️ Бенчмарки: GDB против libdebug
libdebug обрабатывает брейкпоинты и syscalls в 3–4 раза быстрее, чем GDB с Python-обвязкой
Скрипты для воспроизводимости: benchmark suite
⌛ Это огромный плюс для задач, где важна скорость реакции: от fuzzing до runtime-мониторинга.
Stay secure and read SecureTechTalks 📚
#SecureTechTalks #libdebug #ReverseEngineering #Python #Debugging #CyberSecurity #CTF #BugHunting #ExploitDev #SecurityResearch #DevSecOps #OpenSourceTools
🧠💥 LLM + RFC = FlowFSM: ИИ-агенты теперь читают протоколы лучше нас
📡 Протоколы нервная система интернета, но пока одни ищут 0-day в бинарниках, другие решают фундаментальные задачи: что, если просто автоматизировать разбор RFC и сразу строить конечный автомат?
Представляем FlowFSM — мультиагентный LLM-фреймворк, который сам читает RFC, извлекает команды, выстраивает допустимые состояния и собирает рабочую модель FSM, готовую к анализу и fuzzing-атакам.
🧠 ИИ-помощник, который реально работает
FlowFSM — это не просто один LLM-промпт. Это координируемая система агентов, где каждый отвечает за своё:
один читает структуру документа, другой находит команды, третий — выстраивает логику состояний, четвёртый собирает всё в единую модель.
И да, это уже работает.
📦 Разберёмся, как все устроенно
🧩 Шаг 1: Разбор RFC
RFC делится на логические блоки, вычищается от форматирования и готовится к чтению.
📜 Шаг 2: Извлечение команд и состояний
LLM выделяет ключевые команды (например, USER, PASS) и сопоставляет им состояния и зависимости:
что можно вызывать, что запрещено, в каком порядке.
🧠 Шаг 3: Сборка rulebook
Каждая команда получает профиль:
– в каком состоянии она допустима
– что делает
– какие переходы открывает
На выходе — структурированная FSM, пригодная для анализа, генерации тестов и автоматизированного поиска уязвимостей.
⚡ Насколько хорош результат?
FlowFSM протестировали на двух протоколах — FTP и RTSP. Результаты:
Для FTP: модель извлекла 90 правильных переходов, пропустила 12, и добавила 18 ложных
Для RTSP: 18 правильных, 3 пропущенных, 4 ошибочных
Это дало F1-метрику:
~85% для FTP
~84% для RTSP
💡 При этом:
➖ FlowFSM работает автономно без ручной разметки
➖ Обходит zero-shot GPT-4 и rule-based подходы по точности
➖ Ошибается предсказуемо и понятно, легко отлаживается
🛠 Что под капотом?
1⃣ Используется CrewAI — open-source фреймворк для координации LLM-агентов
2⃣ Модель: LLaMA-3 70B, но можно подключить GPT, Claude, Mistral и др.
3⃣ Агентная архитектура легко адаптируется под новые протоколы
4⃣ Поддерживает подключение векторных БД и retrieval-механизмов
🔍 В чем новизна?
🚫 Больше не нужно вручную копаться в RFC на 120 страниц
⚙️ FSM можно сразу использовать в fuzzing и символьном анализе
📊 Можно масштабировать: от FTP до TLS и 5G
🔄 Обновления RFC? — просто перегоняешь через FlowFSM
🧭 Куда всё движется?
Разработчики планируют:
➖ Поддержку новых сетевых протоколов
➖ Интеграцию с фреймворками fuzzing/coverage-guided testing
➖ Улучшение explainability для автоматической валидации FSM
🔗 Код: github.com/YoussefMaklad/FlowFSM
Stay secure and read SecureTechTalks 📚
#FlowFSM #FSM #ProtocolSecurity #LLM #Cybersecurity #CrewAI #PromptChaining #RFC #Fuzzing #LLMengineering
#AIinSecurity #ReverseEngineering #Automation #NLP #InfoSecTools #LLMagents #AIprotocols #SecurityAutomation #AIresearch #SecureTechTalks
📡 Протоколы нервная система интернета, но пока одни ищут 0-day в бинарниках, другие решают фундаментальные задачи: что, если просто автоматизировать разбор RFC и сразу строить конечный автомат?
Представляем FlowFSM — мультиагентный LLM-фреймворк, который сам читает RFC, извлекает команды, выстраивает допустимые состояния и собирает рабочую модель FSM, готовую к анализу и fuzzing-атакам.
🧠 ИИ-помощник, который реально работает
FlowFSM — это не просто один LLM-промпт. Это координируемая система агентов, где каждый отвечает за своё:
один читает структуру документа, другой находит команды, третий — выстраивает логику состояний, четвёртый собирает всё в единую модель.
И да, это уже работает.
📦 Разберёмся, как все устроенно
🧩 Шаг 1: Разбор RFC
RFC делится на логические блоки, вычищается от форматирования и готовится к чтению.
📜 Шаг 2: Извлечение команд и состояний
LLM выделяет ключевые команды (например, USER, PASS) и сопоставляет им состояния и зависимости:
что можно вызывать, что запрещено, в каком порядке.
🧠 Шаг 3: Сборка rulebook
Каждая команда получает профиль:
– в каком состоянии она допустима
– что делает
– какие переходы открывает
На выходе — структурированная FSM, пригодная для анализа, генерации тестов и автоматизированного поиска уязвимостей.
⚡ Насколько хорош результат?
FlowFSM протестировали на двух протоколах — FTP и RTSP. Результаты:
Для FTP: модель извлекла 90 правильных переходов, пропустила 12, и добавила 18 ложных
Для RTSP: 18 правильных, 3 пропущенных, 4 ошибочных
Это дало F1-метрику:
~85% для FTP
~84% для RTSP
💡 При этом:
🛠 Что под капотом?
1⃣ Используется CrewAI — open-source фреймворк для координации LLM-агентов
2⃣ Модель: LLaMA-3 70B, но можно подключить GPT, Claude, Mistral и др.
3⃣ Агентная архитектура легко адаптируется под новые протоколы
4⃣ Поддерживает подключение векторных БД и retrieval-механизмов
🔍 В чем новизна?
🚫 Больше не нужно вручную копаться в RFC на 120 страниц
⚙️ FSM можно сразу использовать в fuzzing и символьном анализе
📊 Можно масштабировать: от FTP до TLS и 5G
🔄 Обновления RFC? — просто перегоняешь через FlowFSM
🧭 Куда всё движется?
Разработчики планируют:
🔗 Код: github.com/YoussefMaklad/FlowFSM
Stay secure and read SecureTechTalks 📚
#FlowFSM #FSM #ProtocolSecurity #LLM #Cybersecurity #CrewAI #PromptChaining #RFC #Fuzzing #LLMengineering
#AIinSecurity #ReverseEngineering #Automation #NLP #InfoSecTools #LLMagents #AIprotocols #SecurityAutomation #AIresearch #SecureTechTalks
Please open Telegram to view this post
VIEW IN TELEGRAM
❤1
🔥 ИИ против бэкдоров: как LLM учат находить малварь в обновлениях ПО
🚀 Сегодня программы обновляются перманентно, и за каждым апдейтом может скрываться угроза. Что если в новую версию "случайно" попал бэкдор или чужой вредоносный код? 🤯
История знает немало таких случаев: SolarWinds, log4j, 3CX, а совсем недавно - громкая атака на XZ Utils (источник).
🔍 Как ловят скрытые изменения
Специалисты используют метод под названием binary diffing - сравнение двух версий бинаря. Он показывает, где именно есть различия. Но вот понять, что именно изменилось и несут ли эти изменения угрозу - задача для долгих ночей с дизассемблером (обзор методов).
🤖 ИИ приходит на помощь
Исследователи из NYU Tandon и Narf Industries придумали, как встроить в процесс большие языковые модели (LLM). Теперь вместо сухого "файл изменился" можно получить осмысленное описание: что делает новая функция, чем она отличается от старой, и есть ли тут что-то подозрительное.
🧩 Баллы опасности для функций
Чтобы не утонуть в тысячах изменений, придумали метрику Functional Sensitivity Score (FSS). Она оценивает каждую функцию по пяти направлениям:
📡 ведет ли себя подозрительно (сети, процессы);
💾 трогает ли важные ресурсы (файлы, устройства);
🔐 рискует ли конфиденциальностью (пароли, ключи);
🛡️ ломает ли целостность (правит настройки, шифрует);
⚡ влияет ли на доступность (отключает сервисы, грузит систему).
Итог - "оценка чувствительности" от 0 до 10, почти как в CVSS (почти 😁).
🦠 Учёные устроили полигон для малвари
Чтобы проверить подход, исследователи сделали свой "тестовый полигон" - взяли 6 популярных open-source проектов (gzip, openssl, tar, sqlite, microhttpd, paho-mqtt) и внедрили туда три вида малвари:
шифровальщик (rware),
троян для удаленного доступа (rat),
клиент ботнета (botnet).
На выходе получился огромный датасет: 104 версии, 392 бинарных сравнения и 46 000 функций.
📊 Результаты
🎯 Precision: 0.98 - почти без ложных тревог.
🔎 Recall: 0.64 - до 64% вредоносных функций пойманы.
📈 Разница в FSS между чистыми и зараженными функциями - 3 балла.
А в реальном кейсе с XZ Utils метод сработал идеально: LLM отметил новые функции как "аномальные для liblzma" и выявил бэкдор (детали атаки).
Но ⚠️ есть и обратная сторона: те же методы могут использовать хакеры для реверс-инжиниринга. Поэтому авторы отдельно говорят об этике и необходимости ограничений.
🔮 Будущее
Ждём, когда каждый апдейт можно будет проверить автоматически.
Stay secure and read SecureTechTalks 📚
#кибербезопасность #supplychain #malware #LLM #reverseengineering #xz #opensource #binarydiff #infosec #softwaresecurity
🚀 Сегодня программы обновляются перманентно, и за каждым апдейтом может скрываться угроза. Что если в новую версию "случайно" попал бэкдор или чужой вредоносный код? 🤯
История знает немало таких случаев: SolarWinds, log4j, 3CX, а совсем недавно - громкая атака на XZ Utils (источник).
🔍 Как ловят скрытые изменения
Специалисты используют метод под названием binary diffing - сравнение двух версий бинаря. Он показывает, где именно есть различия. Но вот понять, что именно изменилось и несут ли эти изменения угрозу - задача для долгих ночей с дизассемблером (обзор методов).
🤖 ИИ приходит на помощь
Исследователи из NYU Tandon и Narf Industries придумали, как встроить в процесс большие языковые модели (LLM). Теперь вместо сухого "файл изменился" можно получить осмысленное описание: что делает новая функция, чем она отличается от старой, и есть ли тут что-то подозрительное.
🧩 Баллы опасности для функций
Чтобы не утонуть в тысячах изменений, придумали метрику Functional Sensitivity Score (FSS). Она оценивает каждую функцию по пяти направлениям:
📡 ведет ли себя подозрительно (сети, процессы);
💾 трогает ли важные ресурсы (файлы, устройства);
🔐 рискует ли конфиденциальностью (пароли, ключи);
🛡️ ломает ли целостность (правит настройки, шифрует);
⚡ влияет ли на доступность (отключает сервисы, грузит систему).
Итог - "оценка чувствительности" от 0 до 10, почти как в CVSS (почти 😁).
🦠 Учёные устроили полигон для малвари
Чтобы проверить подход, исследователи сделали свой "тестовый полигон" - взяли 6 популярных open-source проектов (gzip, openssl, tar, sqlite, microhttpd, paho-mqtt) и внедрили туда три вида малвари:
шифровальщик (rware),
троян для удаленного доступа (rat),
клиент ботнета (botnet).
На выходе получился огромный датасет: 104 версии, 392 бинарных сравнения и 46 000 функций.
📊 Результаты
🎯 Precision: 0.98 - почти без ложных тревог.
🔎 Recall: 0.64 - до 64% вредоносных функций пойманы.
📈 Разница в FSS между чистыми и зараженными функциями - 3 балла.
А в реальном кейсе с XZ Utils метод сработал идеально: LLM отметил новые функции как "аномальные для liblzma" и выявил бэкдор (детали атаки).
Но ⚠️ есть и обратная сторона: те же методы могут использовать хакеры для реверс-инжиниринга. Поэтому авторы отдельно говорят об этике и необходимости ограничений.
🔮 Будущее
Ждём, когда каждый апдейт можно будет проверить автоматически.
Stay secure and read SecureTechTalks 📚
#кибербезопасность #supplychain #malware #LLM #reverseengineering #xz #opensource #binarydiff #infosec #softwaresecurity
🧠🕵️ Claude Code нашли с "водяными знаками" в запросах
Исследователи обратили внимание на любопытную особенность Claude Code. Если клиент работает не через официальный API Anthropic, а через собственный прокси (ANTHROPIC_BASE_URL), он может незаметно изменять символы в системном промпте.
Вместо привычной строки:
клиент использует визуально идентичные символы: другой апостроф или разделитель даты. Для пользователя и модели текст выглядит одинаково, но на сервер отправляется уже немного другой набор Unicode-символов.
Фактически это стеганографическая метка, встроенная прямо в системный контекст.
⚙️ Что именно кодируется?
По результатам реверс-инжиниринга логика появилась в версии 2.1.196.
При использовании собственного ANTHROPIC_BASE_URL клиент анализирует адрес прокси и, по утверждению исследователей, проверяет совпадение с набором заранее заданных доменов. Отдельно учитывается часовой пояс, например, Asia/Shanghai или Asia/Urumqi.
Полученные признаки кодируются изменением отдельных символов даты. При этом сами списки доменов, как сообщается, скрыты в бинарном файле с помощью Base64 и XOR-обфускации.
🧨 Зачем это нужно?
Наиболее вероятным объяснением является борьба с неофициальными прокси и массовой дистилляцией моделей.
Сегодня существует рынок прокси, которые перепродают доступ к Claude. Кроме того, через такие шлюзы можно автоматически собирать большие массивы ответов модели для последующего обучения собственных LLM.
Если выводы исследователей верны, подобные метки позволяют серверной стороне определить, что запрос, вероятно, пришёл не через официальный API.
🛡️ Почему это вызвало дискуссию?
Главная претензия не к самой идее защиты от дистилляции, а к её реализации. По данным реверс-инжиниринга, клиент с доступом к shell, Git и файловой системе анализирует параметры окружения и скрытно кодирует их в системном промпте, хотя подобное поведение не было описано в release notes. Для инструментов такого уровня привилегий прозрачность становится вопросом доверия.
Stay secure and read SecureTechTalks 📚
#кибербезопасность #AI #Claude #Anthropic #LLM #ReverseEngineering #AIsecurity #AgenticAI #SupplyChainSecurity #SecureTechTalks
Исследователи обратили внимание на любопытную особенность Claude Code. Если клиент работает не через официальный API Anthropic, а через собственный прокси (ANTHROPIC_BASE_URL), он может незаметно изменять символы в системном промпте.
Вместо привычной строки:
Today's date is 2026-06-30клиент использует визуально идентичные символы: другой апостроф или разделитель даты. Для пользователя и модели текст выглядит одинаково, но на сервер отправляется уже немного другой набор Unicode-символов.
Фактически это стеганографическая метка, встроенная прямо в системный контекст.
⚙️ Что именно кодируется?
По результатам реверс-инжиниринга логика появилась в версии 2.1.196.
При использовании собственного ANTHROPIC_BASE_URL клиент анализирует адрес прокси и, по утверждению исследователей, проверяет совпадение с набором заранее заданных доменов. Отдельно учитывается часовой пояс, например, Asia/Shanghai или Asia/Urumqi.
Полученные признаки кодируются изменением отдельных символов даты. При этом сами списки доменов, как сообщается, скрыты в бинарном файле с помощью Base64 и XOR-обфускации.
🧨 Зачем это нужно?
Наиболее вероятным объяснением является борьба с неофициальными прокси и массовой дистилляцией моделей.
Сегодня существует рынок прокси, которые перепродают доступ к Claude. Кроме того, через такие шлюзы можно автоматически собирать большие массивы ответов модели для последующего обучения собственных LLM.
Если выводы исследователей верны, подобные метки позволяют серверной стороне определить, что запрос, вероятно, пришёл не через официальный API.
🛡️ Почему это вызвало дискуссию?
Главная претензия не к самой идее защиты от дистилляции, а к её реализации. По данным реверс-инжиниринга, клиент с доступом к shell, Git и файловой системе анализирует параметры окружения и скрытно кодирует их в системном промпте, хотя подобное поведение не было описано в release notes. Для инструментов такого уровня привилегий прозрачность становится вопросом доверия.
Stay secure and read SecureTechTalks 📚
#кибербезопасность #AI #Claude #Anthropic #LLM #ReverseEngineering #AIsecurity #AgenticAI #SupplyChainSecurity #SecureTechTalks
👍1🔥1
🧨 AI-агенты умеют работать с кодом. Но что будет, если кода больше нет?
Исследователи из Columbia, Berkeley, UCLA, Tufts и других организаций представили SRE-Bench, бенчмарк, созданный специально для проверки того, насколько AI-агенты способны разбирать неизвестные бинарники, а не узнавать уже знакомый проект из обучающих данных.
⚙️ Больше никакого «угадай, что это за программа»
Авторы сделали 19 программ с нуля, общей сложностью более 320 000 строк кода.
Внутри пять типов задач:
🔹 сетевые протоколы;
🔹 firmware;
🔹 игровые приложения;
🔹 собственные форматы файлов;
🔹 безопасная имитация malware.
Средний размер программы 16,9 тыс. строк.
Затем исследователи превратили их в 262 уникальных бинарных экземпляра и добавили 44 механизма anti-analysis: obfuscation, anti-debugging, виртуализированный loader, шифрование страниц кода, anti-dump и другие техники.
В итоге получилось 1 572 детерминированно проверяемые задачи.
На создание всего этого ушло более 5 000 часов работы специалистов по reverse engineering.
🧠 Результаты AI
Пять frontier-моделей получили одинаковый набор инструментов: Ghidra, GDB, angr, radare2, binutils и другие RE-инструменты.
Лучшей оказалась GPT-5.6-Sol:
61,4% среднего результата и только 80 из 262 бинарников полностью решены (31,5%).
Claude Opus 5 решил 12,5%, GPT-5.5 - 3,8%, Grok 4.5 - 0,9%, а GLM-5.2 не смог полностью решить ни одного экземпляра.
Эксперимент стоил исследователям $31,4 тыс. и занял около 1 812 sandbox-часов.
🔥 Агенты думают не как reverse engineer
У человека оптимизированный и statically linked бинарник обычно сложнее анализировать, а у AI почти наоборот.
Для GPT-5.6-Sol оптимизация снизила результат всего с 4,75 до 4,67 из 6, а static linking с 4,73 до 4,69.
Удаление символов оказалось намного болезненнее: результат упал с 4,95 до 4,47.
Похоже, современные агенты сильно опираются на имена функций, переменных и другие lexical anchors, которые помогают им построить смысловую модель программы. Когда эти подсказки исчезают, capability резко проседает.
🛡️ Защита ломает всё
Когда авторы включили собственный anti-analysis слой, результат GPT-5.6-Sol практически упал вдвое: с 4,69 до 2,50.
Claude Opus 5 рухнул с 3,07 до 0,33, а остальные модели приблизились к нулю.
AI уже довольно хорошо работает с известной структурой исходного кода. Но между «прочитать код» и «понять неизвестный защищённый бинарник» пока огромная пропасть.
Бинарный анализ не экзотическая задача. Именно так приходится исследовать значительную часть malware, firmware, закрытого enterprise-софта и security appliances. Авторы отмечают, что 46,5% уязвимостей, эксплуатируемых in-the-wild, связаны с вендорами, которые не публикуют исходный код.
🔗 Исследование: https://arxiv.org/pdf/2608.11469
Stay secure and read SecureTechTalks 📚
#кибербезопасность #AI #LLM #AgenticAI #ReverseEngineering #MalwareAnalysis #BinaryAnalysis #AISecurity #ThreatResearch #SecureTechTalks
Исследователи из Columbia, Berkeley, UCLA, Tufts и других организаций представили SRE-Bench, бенчмарк, созданный специально для проверки того, насколько AI-агенты способны разбирать неизвестные бинарники, а не узнавать уже знакомый проект из обучающих данных.
⚙️ Больше никакого «угадай, что это за программа»
Авторы сделали 19 программ с нуля, общей сложностью более 320 000 строк кода.
Внутри пять типов задач:
🔹 сетевые протоколы;
🔹 firmware;
🔹 игровые приложения;
🔹 собственные форматы файлов;
🔹 безопасная имитация malware.
Средний размер программы 16,9 тыс. строк.
Затем исследователи превратили их в 262 уникальных бинарных экземпляра и добавили 44 механизма anti-analysis: obfuscation, anti-debugging, виртуализированный loader, шифрование страниц кода, anti-dump и другие техники.
В итоге получилось 1 572 детерминированно проверяемые задачи.
На создание всего этого ушло более 5 000 часов работы специалистов по reverse engineering.
🧠 Результаты AI
Пять frontier-моделей получили одинаковый набор инструментов: Ghidra, GDB, angr, radare2, binutils и другие RE-инструменты.
Лучшей оказалась GPT-5.6-Sol:
61,4% среднего результата и только 80 из 262 бинарников полностью решены (31,5%).
Claude Opus 5 решил 12,5%, GPT-5.5 - 3,8%, Grok 4.5 - 0,9%, а GLM-5.2 не смог полностью решить ни одного экземпляра.
Эксперимент стоил исследователям $31,4 тыс. и занял около 1 812 sandbox-часов.
🔥 Агенты думают не как reverse engineer
У человека оптимизированный и statically linked бинарник обычно сложнее анализировать, а у AI почти наоборот.
Для GPT-5.6-Sol оптимизация снизила результат всего с 4,75 до 4,67 из 6, а static linking с 4,73 до 4,69.
Удаление символов оказалось намного болезненнее: результат упал с 4,95 до 4,47.
Похоже, современные агенты сильно опираются на имена функций, переменных и другие lexical anchors, которые помогают им построить смысловую модель программы. Когда эти подсказки исчезают, capability резко проседает.
🛡️ Защита ломает всё
Когда авторы включили собственный anti-analysis слой, результат GPT-5.6-Sol практически упал вдвое: с 4,69 до 2,50.
Claude Opus 5 рухнул с 3,07 до 0,33, а остальные модели приблизились к нулю.
AI уже довольно хорошо работает с известной структурой исходного кода. Но между «прочитать код» и «понять неизвестный защищённый бинарник» пока огромная пропасть.
Бинарный анализ не экзотическая задача. Именно так приходится исследовать значительную часть malware, firmware, закрытого enterprise-софта и security appliances. Авторы отмечают, что 46,5% уязвимостей, эксплуатируемых in-the-wild, связаны с вендорами, которые не публикуют исходный код.
🔗 Исследование: https://arxiv.org/pdf/2608.11469
Stay secure and read SecureTechTalks 📚
#кибербезопасность #AI #LLM #AgenticAI #ReverseEngineering #MalwareAnalysis #BinaryAnalysis #AISecurity #ThreatResearch #SecureTechTalks