Skip to content
KitploitKITPLOIT
ИнструментыЭксплойтыБлог
Log in
Отправить
ИнструментыЭксплойтыБлог
Отправить

Инструменты для хакинга, пентеста и кибербезопасности — ваш арсенал защиты!

Kitploit — это каталог инструментов для хакинга, кибербезопасности и пентестинга. Находите последние обновления проектов для поиска уязвимостей, анализа систем, автоматизации тестирования и усиления вашей безопасности.

··Ленты·Контакты·Конфиденциальность·© 2026 Kitploit

Каталог инструментов

Категории

Все категории
Loading categories
VulnFanatic-NG — Плагин BianryNinja для выявления уязвимостей в декомпилированных бинарных файлах, сочетающий программные проверки и поддержку LLM. | Kitploit
Инструменты/GitHubGitHub/martyx00/vulnfanatic-ng
Статический анализ кода (SAST)Анализ уязвимостейАнализ КодаЭксплуатацияОбратная инженерияФаззингТестирование на ПроникновениеАппаратная БезопасностьАнализ Бинарных ФайловБезопасность Цепочки ПоставокОбучение и ОбразованиеОбратная Разработка с Помощью ИИ
141153 месяцев назадЕщё не проверено

Популярное

Смотреть все →

Откройте для себя самые используемые инструменты нашего сообщества.

Изучить все инструменты

Просмотрите нашу коллекцию инструментов

Смотреть все инструменты →
Поделиться
GitHubmartyx00/vulnfanatic-ng

VulnFanatic-NG

Плагин BianryNinja для выявления уязвимостей в декомпилированных бинарных файлах, сочетающий программные проверки и поддержку LLM.

Репозиторий

VulnFanatic-NG

LLM-assisted vulnerability research for Binary Ninja.

VulnFanatic-NG добавляет боковую панель, которая сканирует текущий бинарный файл и спрашивает LLM — по умолчанию локально размещённую модель, совместимую с OpenAI, или Anthropic Claude, Google Gemini, либо Azure OpenAI (см. Бэкенды LLM) — является ли подозрительный код действительно уязвимым. Она работает в основном с выходом декомпилятора (HLIL) Binary Ninja, переходя к ассемблеру при необходимости, и сообщает только о подтверждённых проблемах с кликабельными ссылками на код.


Как это работает

Сканирование выполняется максимум в три фазы (фаза 3 — опциональная и только онлайн):

Фаза 1 — вызовы опасных функций

Находит места вызовов опасных функций, определённых в rules/phase1_rules.json: strcpy, memcpy, sprintf/строки формата, system, alloca, scanf, API команд/exec, слабый ГПСЧ, семейство free/delete (use-after-free / double-free), чтение недоверенных входных данных в буферы фиксированного размера (recv/read/fread/ReadFile), SQL-инъекции (sqlite3_exec/mysql_query/PQexec), отключённую проверку сертификатов TLS (SSL_CTX_set_verify/curl), SSRF и некорректное управление привилегиями (setuid/setresgid), семейство memset/bzero и сравнения с длиной, контролируемой атакующим (memcmp/strncmp → обход аутентификации) для C/C++, Win32 и (в лучшем случае) Rust FFI. Покрытие включает укреплённые варианты _chk (FORTIFY) and Annex-K _s variants. Ограниченные функции форматированного вывода (snprintf и варианты) имеют собственное правило безопасности по умолчанию, так что корректный аргумент размера не сообщается как переполнение. Места вызовов находятся тремя способами: прямые вызовы именованных символов; вызовы через пересылающие заглушки / PLT-стабы (реальные вызывающие восстанавливаются, поэтому импорт, доступный только через стаб, не пропускается); и — если vulnfanatic.scanIndirectCalls не выключен — косвенные вызовы через указатель на функцию или vtable, которые Binary Ninja сопоставил с опасной функцией. Для каждого места вызова он строит межпроцедурный, ориентированный на декомпилятор контекст, в пределах лимита токенов (по умолчанию 100k):

  • выражение вызова и его аргументы,
  • объявленный прототип вызываемой функции (из информации о типах Binary Ninja, иначе из встроенной таблицы), чтобы модель правильно сопоставляла аргументы с параметрами — укреплённые варианты __*_chk и проверяющие границы *_s принимают дополнительные ведущие аргументы, сдвигая позицию формата/размера/назначения,
  • тип и размер в байтах каждого аргумента вызова (ёмкости буферов), выводимые из типа выражения HLIL аргумента, так что поле структуры, например s->buf, разрешается в реальный размер массива поля, а не в размер указателя s; определения структур в разделе типов также содержат размеры полей в байтах,
  • конкретное значение / диапазон каждого аргумента, определённые с помощью константного распространения и анализа множества значений Binary Ninja (например, длина, доказанно постоянная 0x40 или ограниченная [0, 0xff]), которые модель использует как эталон при сравнении размера с ёмкостью буфера вместо догадок,
  • раскладка стекового кадра вызывающей функции (смещения переменных и их размеры в байтах), когда она содержит буфер фиксированного размера, чтобы переполнение стека можно было оценивать относительно соседних переменных и сохранённого обратного адреса (vulnfanatic.includeStackLayout),
  • ограничения пути (условия if/циклов/switch, защищающие вызов),
  • сводка потока данных аргументов — где каждый аргумент вызова определяется и используется внутри функции,
  • разрешение параметров по вызывающим — когда опасный аргумент является параметром вызывающей функции, контекст сообщает, что фактически передаёт каждый вызывающий (например, «все вызывающие передают строковый литерал»), чтобы параметр формата/ размера, который всегда постоянен, не был принят за контролируемый атакующим,
  • полное декомпилированное тело вызывающей функции,
  • определения типов данных (struct/union/enum) для типов, на которые ссылаются цепочка вызовов и переменные аргументов, чтобы модель знала реальные размеры буферов/полей и ширину целых чисел,
  • декомпилированные тела функций, которые производят или используют переменные аргументов вызова (отслеживаемые через определение/использование HLIL), что и делает возможным анализ use-after-free / double-free и заражённых размеров,
  • пути вызовов от точек входа / экспортируемых функций до вызова,
  • декомпилированное тело каждой функции на этих путях вызовов (сначала ближайшей к опасному вызову), каждая с аннотацией места вызова и условий, защищающих следующий переход,
  • тела других функций, которые вызывают функции пути (например, для MAIN→ABCD→strcpy также функции, которые MAIN и ABCD вызывают в других местах), поскольку в них могут находиться проверки границ/валидации, управляющие опасным значением (vulnfanatic.includeCallPathSiblings, заполняется, пока позволяет бюджет), и
  • подсказки о заражённых источниках (входные функции, такие как recv/read/getenv, вызываемые в той же функции).

Этот контекст вместе со специальным для правила запросом отправляется модели, которая возвращает структурированный вердикт. Не-проблемы отбрасываются. Запросы настроены на сильную локальную модель кода (например, Qwen2.5-Coder) и предписывают ей проанализировать весь поток и выдать только JSON.

Рассуждения, черновик и уверенность

Модели предписано отдавать предпочтение полноте (recall) — сообщать о правдоподобных, значимых для безопасности проблемах и выражать неуверенность через Confidence, а не отбрасывать то, что она не может полностью доказать. Она показывает свою работу в черновике (scratchpad), который цитирует дословные фрагменты кода, на которые она опиралась (исходный источник, каждую защиту, размер/длину, соответствующий тип и приёмник), и который сохраняется в находке, чтобы вы могли проверить рассуждения.

Каждая находка несёт Confidence (high/medium/low): high = вся цепочка показана в контексте; medium = вероятно, с одной-двумя предполагаемыми связями; low = зацепка, заслуживающая ручной проверки. Это главный показатель (оценка серьёзности модели — вторичное поле). Установите vulnfanatic.minConfidence, чтобы отбрасывать всё ниже порога.

Настройка точности и полноты

По умолчанию VulnFanatic-NG отдаёт предпочтение полноте (выявлению реальных проблем). Если ложных срабатываний слишком много, ужесточите настройки любым из способов:

Скачать инструмент