Движок протокольного фаззинга на базе Peach Fuzzer Professional v4, открытый Offensive Security (GitLab) в 2021 году под лицензией MIT. Позволяет строить определения протоколов (PIT-файлы на XML) и автоматически генерировать мутированные пакеты для поиска уязвимостей в сетевых службах, файловых парсерах и встроенных устройствах. Поддерживает publisher-ы для TCP, UDP, HTTP, файловых систем и COM. Использовался командами Offensive Security для обнаружения 0-day в проприетарных протоколах.
git clone https://gitlab.com/gitlab-org/security-products/protocol-fuzzer-ce cd protocol-fuzzer-ce # Требует .NET 6 / Mono dotnet build # Запуск фаззинга по PIT-файлу (описание протокола) ./peach --pit samples/HelloWorld.xml # Документация # https://gitlab.com/gitlab-org/security-products/protocol-fuzzer-ce/-/wikis
Этот проект основан на Peach Fuzzer Professional v4, который был приобретён GitLab в 2020 году. Некоторые функции Peach Fuzzer Professional были удалены и будут доступны в составе GitLab в будущем. Этот проект заменяет проекты Peach Fuzzer Community, ранее размещённые на GitLab и также на Source Forge.
Поскольку этот код был первоначально разработан Peach Tech, в репозитории могут встречаться ссылки на персонал, адреса электронной почты, веб-сайты или функции, специфичные для Peach Tech. Со временем они будут обновлены для ссылки на GitLab. Если вы обнаружите такую ссылку, не стесняйтесь создать MR для уточнения и/или её обновления.
Пожалуйста, следуйте инструкциям по сборке, пока не станут доступны бинарные файлы.
build — Скрипты сборки для компиляции репозитория.
Сюда входят waf (система сборки, используемая peach),
шаблоны asciidoctor и различные скрипты, используемые Jenkins
для интеграционных сборок.
core — Общие классы и интерфейсы между открытым и закрытым исходным кодом Peach.
docs — Вся документация для руководства пользователя, руководства разработчика и пробных руководств.
packer — Шаблон и скрипты, используемые packer (https://packer.io) для генерации
размещённого пробного AMI и локального пробного OVA.
pro — Исходный код для Peach Professional и сопутствующих приложений и тестов.
tools — Скрипты, необходимые для сборки (запускатель nunit и генератор *.exe.config).
Скрипты сборки требуют, чтобы все сообщения коммитов соответствовали набору правил.
Сообщения ОБЯЗАНЫ начинаться с одного из следующих префиксов:
new: chg: fix: dev:.
Слияния коммитов не допускаются, и рекомендуется, чтобы все PR
были объединены в один коммит.
Первая строка сообщения коммита используется для автоматической генерации журнала изменений для клиентов.
Последующие строки сообщения коммита могут содержать любую информацию и игнорируются при генерации журнала изменений.
Если сообщение коммита начинается с dev:, коммит будет опущен из журнала изменений.
Остальные коммиты классифицируются как новые, изменённые или исправленные.
Peach поддерживает компиляцию на компьютерах с Windows, Linux и OSX. Peach использует waf (https://waf.io/) в качестве системы сборки. Waf поддерживает концепцию 'вариантов сборки', которая используется для компиляции Peach для различных платформ и архитектур.
Peach использует 11 различных вариантов сборки:
Windows — win_x86_debug win_x86_release win_x64_debug win_x64_release
Linux — linux_x86_debug linux_x86_release linux_x86_64_debug linux_x86_64_release
OSX — osx_debug osx_release
Документация — doc
Waf выполняет сборку вне дерева исходного кода, то есть промежуточные файлы и выходные
бинарные файлы размещаются в отдельном каталоге от исходного кода.
Для сборки peach промежуточные файлы размещаются в каталоге slag/
и устанавливаются в каталог output/.
Waf ищет файлы wscript_build во всех подкаталогах корневого каталога
и выполняет содержащуюся в них информацию. Для большинства файлов wscript_build верхнего уровня
они обычно содержат только следующий список подкаталогов для рекурсивного обхода.
Добавьте следующие две записи реестра через PowerShell:
Минимальные команды, необходимые для компиляции peach, показаны ниже:
waf configure
waf build
waf install
waf configure — Это первый шаг, который необходимо выполнить для компиляции peach.
Этот шаг аналогичен фазе autoconf при компиляции библиотек в Linux. +
+
Waf попытается найти все зависимости для сборки и сохранит их пути.
Если зависимость для сборки не может быть найдена для определённого варианта,
вариант сборки будет помечен как неподдерживаемый.
Это может быть полезно, если вы хотите собирать только для linux_x86_64, но не хотите собирать документацию. +
+
Фаза конфигурации запустит программу packt (https://fsprojects.github.io/Paket/) и загрузит
все сторонние зависимости из nuget, используя требования, перечисленные в paket/paket.depenencies. +
+
ПРИМЕЧАНИЕ: waf configure нужно запускать только один раз.
Для обычного рабочего процесса разработчика, который изменяет исходный код Peach, вам не нужно
запускать эту команду. Однако, если вы внесете изменения в скрипты сборки
(находятся в каталоге build), или вы изменили установленный набор инструментов сборки,
вам нужно будет перезапустить эту команду, чтобы обновленные пути инструментов могли быть определены. +
+
СОВЕТ: Если возникает ошибка, потому что не удается найти необходимый инструмент, попробуйте
перезапустить с увеличенной детализацией. waf configure -v будет отображать
каждую зависимость, которая находится, а также полный путь, по которому она обнаружена. +
+
Фаза конфигурации также используется для установки номера версии в интеграционной сборке.
Запуск waf configure --buildtag=4.3.100 приведет к тому, что все собранные артефакты будут
помечены указанным тегом сборки. Если параметр не указан, тег сборки
по умолчанию равен 0.0.0.
waf build — Эта команда скомпилирует все файлы в репозитории.
Компиляция включает генерацию файлов с меткой версии,
запуск любого преобразования исходного кода,
компиляцию исходного кода и связывание результатов. +
+
Эта команда аналогична запуску make в Linux. +
+
Все артефакты из фазы сборки окажутся в каталоге slag/.
waf install — Эта команда устанавливает выходные файлы программы, а также все зависимости библиотек, в каталог output/. +
+
Эта команда аналогична запуску make install в Linux. +
+
Обычный рабочий процесс разработчика для linux заключается в запуске waf install --variant=linux_x86_64_debug
а затем запуске ./output/linux_x86_64_debug/bin/peach.
waf pkg — Генерирует zip-файлы установщиков.
Для peach есть два zip-файла, один для внутреннего использования (запуск тестов модулей/интеграционных тестов)
и один для внешнего использования (загрузка на сайт загрузок).
Два zip-файла попадают в папку output//pkg.
Наконец, эта команда waf создаст zip-файл локального сервера лицензий.
waf test — Запускает все тесты модулей. Чтобы запустить тесты модулей для варианта Windows x64 debug, вы можете запустить
waf test --variant=win_x64_debug.
waf msvs2017 — Создает все файлы .csproj и файл Peach.sln для использования с Visual Studio 2017.
waf zip — Упаковывает все выходные данные из фазы установки в один артефакт.
Использование waf следует синтаксису: waf [команда] [параметры]
Для всех команд детализацию можно увеличить, добавив один или более аргументов -v.
Для всех команд, кроме configure, поддерживаются следующие параметры:
--variant=xxx фильтрует команду по вариантам, содержащим 'xxx' в имени.
Это означает, что --variant=4_d будет соответствовать вариантам linux_x86_64_debug и win_x64_debug.-j1 управляет параллелизацией задач waf так, чтобы только одна задача выполнялась одновременно.
По умолчанию waf будет выполнять N задач одновременно, где N соответствует количеству ядер процессора на хосте.
Выполнение только одной задачи за раз иногда может помочь в устранении ошибок сборки.waf --help отображает полный список поддерживаемых команд и параметров.Руководящие принципы
. Тесты модулей должны предоставляться с pull request. . Правильное использование журналирования. . Все запросы на слияние будут проходить через рецензирование исходного кода.
Убедитесь, что команда Peach и, в частности, @mikeeddington осведомлены о каких-либо сроках для принятия запросов на слияние. Не редкость, когда запросы на слияние занимают несколько месяцев для принятия в противном случае.
Peach использует NLog для журналирования отладочных/трассировочных сообщений.
Отладка (Debug) — Отладочные сообщения следует использовать экономно. Клиенты используют --debug для выявления проблем в своих pits. Важно поддерживать этот вывод лаконичным, отображая только информацию, необходимую конечному пользователю.
Трассировка (Trace) — Это уровень журналирования, который следует использовать для вывода, который в основном нужен разработчикам Peach или при диагностировании возможной проблемы, но не то, что клиент хотел бы видеть всегда.
Все pull request должны содержать тесты модулей, обеспечивающие разумное покрытие всех функций. NUnit — это наша среда тестирования модулей. Перед отправкой pull request убедитесь, что все тесты модулей Peach проходят успешно.
Все функции поставляемого кода требуют документации по продукту. Это может быть новая документация для добавляемого исправления или аналогичного обновления, или обновление существующей документации.