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

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

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

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

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

Категории

Все категории
Loading categories
code-shield — Конвейер устранения уязвимостей C/C++ на основе фактических данных + тематическое исследование http-parser (класс CVE-2024-22019). Ядро на Python, консоль React 19, набор из 17 проверочных тестов. | Kitploit
Инструменты/GitHubGitHub/kos2001/code-shield
Оборонительные ИнструментыСтатический анализАнализ уязвимостейАнализ КодаФаззингАнализ Бинарных Файлов
GitHubkos2001/code-shield

code-shield

Конвейер устранения уязвимостей C/C++ на основе фактических данных + тематическое исследование http-parser (класс CVE-2024-22019). Ядро на Python, консоль React 19, набор из 17 проверочных тестов.

Репозиторий
27 дней назадЕщё не проверено

Популярное

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

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

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

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

Смотреть все инструменты →
Поделиться

protocol-remediator

Это MVP, который нормализует findings об уязвимостях в коде C/C++ protocol·platform в воспроизводимые доказательства и проверяет кандидатные патчи в изолированной копии. code-shield — рабочее название, для которого подтверждён риск конфликта имён, поэтому в публичном пакете и CLI используется нейтральное внутреннее имя.

В центре текущей реализации — не модель генерации патчей, а приведённый ниже замкнутый цикл верификации.

root@kitploit:~
sanitizer 또는 SARIF
  -> Finding + EvidenceBundle
  -> source context
  -> manual/external-agent patch
  -> 원본 재현
  -> build
  -> patched reproducer
  -> tests
  -> static rescan
  -> bounded refuzz
  -> protocol oracle
  -> verified report

Реализованные возможности

  • версионированные JSON-модели Finding, EvidenceBundle, PatchProposal, VerificationReport
  • переходы состояний detected → reproducible → contextualized → proposed → plausible → verified
  • сбор отчётов AddressSanitizer, MemorySanitizer, UndefinedBehaviorSanitizer
  • сбор findings SARIF 2.1
  • экспорт нормализованных findings в SARIF 2.1
  • генерация аудируемого JSON-контекста вокруг source location
  • конфигурация target/build/gate на основе TOML
  • Docker-исполнитель с network-off, capability-drop и resource-limit
  • локальный исполнитель, требующий явного opt-in
  • воспроизведение finding в копии исходного target и проверка патча в отдельной копии
  • проверка patch checksum, reproducer checksum, path escape, symlink и ограничений по файлам и строкам
  • отклонение патчей для защищённых путей: test, fuzz harness, reproducer
  • адаптер внешней команды patch agent
  • сохранение exit code, stdout/stderr, времени и результатов gate для каждой команды

Требования

  • Python 3.11 или новее
  • Git для проверки патчей
  • Docker для изолированного запуска по умолчанию
  • Clang для запуска примеров

Рантайм-зависимостей Python нет.

Установка и тестирование

root@kitploit:~
python3 -m venv .venv
.venv/bin/pip install -e .
.venv/bin/python -m unittest discover -s tests -v

Запуск без установки:

root@kitploit:~
PYTHONPATH=src python3 -m protocol_remediator --help
PYTHONPATH=src python3 -m unittest discover -s tests -v

Динамический end-to-end suite — это матрица C/C++ fixture из examples. С помощью Clang ASan/UBSan реально воспроизводятся CWE-121, CWE-190, CWE-416, CWE-787, CWE-476, после чего для патча, восстанавливающего каждый invariant, выполняются все шесть gate. Входные данные и объём проверки для каждой fixture описаны в examples/README.md.

Чтобы запустить только саму матрицу без unit-test framework:

root@kitploit:~
PYTHONPATH=src python3 examples/run_fixture_matrix.py

Чтобы автоматически сгенерировать и запустить больше вариантов примеров C/C++:

root@kitploit:~
PYTHONPATH=src python3 examples/run_generated_corpus.py --count 50

Этот runner не использует unittest и прогоняет каждый сгенерированный проект через один и тот же VerificationPipeline. Сводка результатов по умолчанию сохраняется в artifacts/generated-corpus-summary.json.

Консоль Frontend

Фронтенд на Vite + React + TypeScript, позволяющий наблюдать текущее состояние реализации в виде операционного дашборда, находится в frontend. Эта консоль объединяет на одном экране матрицу fixture, сгенерированный корпус, состояние подключения к Hermes API server, gate верификации и evidence safety invariant.

root@kitploit:~
cd frontend
npm install
npm run dev

Сервер разработки по умолчанию — http://127.0.0.1:5173. Production-сборка проверяется следующей командой:

root@kitploit:~
cd frontend
npm run build

CLI

Сбор findings санитайзера

root@kitploit:~
protocol-remediator ingest-sanitizer \
  --log asan.log \
  --reproducer crash.input \
  --target-name parser \
  --revision 0123456789abcdef \
  --variant asan-x86_64 \
  --output intake/parser-crash

Вывод:

root@kitploit:~
intake/parser-crash/finding.json
intake/parser-crash/evidence.json

Сбор SARIF

root@kitploit:~
protocol-remediator ingest-sarif \
  --sarif results.sarif \
  --output intake/sarif

Экспорт SARIF

root@kitploit:~
protocol-remediator export-sarif \
  --finding intake/parser-crash/finding.json \
  --finding intake/another/finding.json \
  --output artifacts/findings.sarif

Создание нейтрального к модели контекста

root@kitploit:~
protocol-remediator context \
  --finding intake/parser-crash/finding.json \
  --evidence intake/parser-crash/evidence.json \
  --target-root /path/to/target \
  --output intake/parser-crash/context.json

Проверка существующего патча

root@kitploit:~
protocol-remediator verify \
  --config /path/to/target/target.toml \
  --finding intake/parser-crash/finding.json \
  --evidence intake/parser-crash/evidence.json \
  --patch candidate.patch \
  --artifacts artifacts

Код выхода: 0 при verified, 1 при неудачной проверке, 2 при ошибке конфигурации или входных данных.

Hermes agent API server

Запуск Hermes API server позволяет remediate запрашивать патчи через HTTP API вместо локальной команды. Endpoint по умолчанию — POST /v1/patches: он принимает finding/evidence/context и архив target workspace и возвращает unified diff.

Пример запуска сервера:

root@kitploit:~
PYTHONPATH=src python3 -m protocol_remediator.hermes_server \
  --host 127.0.0.1 \
  --port 8765

После установки можно использовать и console script.

root@kitploit:~
hermes-agent-server --host 127.0.0.1 --port 8765

Чтобы подключить рабочую backend command, указывайте --backend-command по одному аргументу за раз. Поддерживаются плейсхолдеры {context}, {workspace}, {patch_output}.

root@kitploit:~
hermes-agent-server \
  --backend-command my-patch-agent \
  --backend-command --context \
  --backend-command {context} \
  --backend-command --workspace \
  --backend-command {workspace} \
  --backend-command --output \
  --backend-command {patch_output}

В target.toml режим Hermes задаётся следующим образом:

root@kitploit:~
[agent]
mode = "hermes"
url = "http://127.0.0.1:8765"
timeout_seconds = 30

Затем используйте существующую команду remediate как есть.

root@kitploit:~
protocol-remediator remediate \
  --config examples/length-prefixed-parser/target.hermes.toml \
  --finding artifacts/hermes-cli-input/finding.json \
  --evidence artifacts/hermes-cli-input/evidence.json \
  --artifacts artifacts/hermes-cli

Для end-to-end проверки в процессе разработки используется следующий runner. Он поднимает временный Hermes server, получает патч через API client и доводит замкнутый цикл верификации до конца.

root@kitploit:~
PYTHONPATH=src python3 examples/run_hermes_demo.py

Создание и проверка внешнего command agent

Чтобы вызывать локальную команду напрямую, без Hermes, укажите agent command в target.toml в виде массива строк.

root@kitploit:~
[agent]
mode = "command"
command = [
  "my-patch-agent",
  "--context",
  "{context}",
  "--workspace",
  "{workspace}",
  "--output",
  "{patch_output}",
]
timeout_seconds = 900

Затем выполните следующую команду.

root@kitploit:~
protocol-remediator remediate \
  --config /path/to/target/target.toml \
  --finding intake/parser-crash/finding.json \
  --evidence intake/parser-crash/evidence.json \
  --artifacts artifacts

Ядро не вызывает напрямую API конкретной LLM. Контракт таков: Hermes backend или внешняя команда читает context и формирует unified diff. Работа агента выполняется во временной копии, а не в исходном target.

Конфигурация target

Полный пример приведён в target.toml.

root@kitploit:~
[project]
name = "my-protocol"
language = "c++"
root = "."

[executor]
mode = "docker"
image = "my-frozen-toolchain@sha256:..."
timeout_seconds = 300
network = false

[reproduction]
failure_regex = "AddressSanitizer|heap-buffer-overflow"

[verification]
required_gates = [
  "build",
  "reproducer",
  "tests",
  "rescan",
  "refuzz",
  "protocol",
]

[gates]
build = [["cmake", "-S", ".", "-B", "build"], ["cmake", "--build", "build"]]
reproducer = [["./build/fuzz_target", "{reproducer}"]]
tests = [["ctest", "--test-dir", "build", "--output-on-failure"]]
rescan = [["./tools/run-sast", "--fail-on-new"]]
refuzz = [["./tools/refuzz", "--seconds", "60"]]
protocol = [["./tools/protocol-oracle"]]

Каждая команда — это массив аргументов, а не shell-строка. Поддерживаемые плейсхолдеры:

  • {workspace}: путь к временному target, видимый из executor
  • {reproducer}: путь к reproducer, скопированному во временный target после проверки checksum

build и reproducer требуются всегда. Политика по умолчанию делает все шесть gate обязательными. Если какой-то gate неприменим из-за особенностей target, его необходимо явно скорректировать в required_gates; это останется в отчёте.

Артефакты

Каждый запуск верификации сохраняет следующее:

root@kitploit:~
artifacts/run_<id>/
  candidate.patch
  context.json
  evidence.input.json
  finding.input.json
  finding.final.json
  patch-proposal.json
  patch-stats.json
  verification-report.json

verification-report.json включает вывод как baseline, так и patched command. Поскольку PoC и логи могут содержать секреты, к хранилищу артефактов следует применять отдельную политику доступа и хранения.

Границы безопасности

  • Базовая рекомендация — pinned Docker image и network=false.
  • local executor должен явно объявлять allow_local=true; его нельзя использовать с недоверенными target.
  • Политику данных для исходящих LLM-команд определяет оператор. Ядро не выполняет автоматическую загрузку.
  • plausible — состояние, в котором пройдены только build и исходный reproducer.
  • verified также не является доказательством program equivalence и не заменяет одобрение человеком.
  • Автоматический merge не реализован.

Приоритеты следующей реализации

  1. адаптер target для реальных ProFuzzBench/AFLNet
  2. коллектор protocol message sequence и state trace
  3. опциональный адаптер CodeQL и эмиттер source/sink моделей для C/C++
  4. запуск матрицы ASan/UBSan/MSan и архитектур
  5. differential protocol oracle на основе нормального корпуса
  6. runner AutoPatchBench и количественный benchmark-отчёт

Обоснование исследований и проектные решения собраны в docs/research.

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