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

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

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

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

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

Категории

Все категории
Loading categories
gobee — Пишите свои BPF-программы на Go, а не на C. gobee транспилирует подмножество Go в BPF C и генерирует типизированные привязки cilium/ebpf. | Kitploit
Инструменты/GitHubGitHub/boratanrikulu/gobee
Статический анализАнализ КодаСкриптинг и автоматизацияDevSecOpsУтилиты и фреймворкиАнализ Бинарных Файлов
GitHubboratanrikulu/gobee

gobee

Пишите свои BPF-программы на Go, а не на C. gobee транспилирует подмножество Go в BPF C и генерирует типизированные привязки cilium/ebpf.

Репозиторий
345414 месяцев назадПроверено Kitploit

Популярное

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

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

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

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

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

gobee

Пишите свои BPF-программы на Go, а не на C. gobee транслирует строгое подмножество Go в BPF C, генерирует типизированные Go-привязки для пользовательской стороны и проверяет загрузку на соответствие версии работающего ядра.

Экосистема Go имеет надежные пользовательские инструменты для BPF. Но сторона ядра всегда заканчивалась фразой «теперь напишите свою программу на C». Aya привнесла eBPF в Rust, написав новый бэкенд BPF в rustc. gobee добивается этого иначе: транслируя в C и используя зрелый бэкенд clang.

На входе Go-файл, на выходе BPF-программа

Точка трассировки, которая отправляет каждый execve в пользовательское пространство через ringbuf:

Ваш вход (Go)Что выдает gobee (BPF C)
root@kitploit:~
//go:build ignore

package main

import "github.com/boratanrikulu/gobee/bpf"

//bpf:license GPL

type Event struct {
    Pid  uint32
    Comm [16]byte
}

var Events = bpf.RingBuf[Event]{
    MaxEntries: 4096,
}

//bpf:section tracepoint/syscalls/sys_enter_execve
func OnExec(ctx *bpf.ExecveEnterCtx) bpf.TpReturn {
    e, ok := Events.Reserve()
    if !ok {
        return bpf.TpOk
    }
    e.Pid = bpf.GetCurrentPid()
    bpf.GetTaskComm(&e.Comm)
    Events.Submit(e)
    return bpf.TpOk
}

func main() {}
root@kitploit:~
// Code generated by gobee. DO NOT EDIT.

#include "vmlinux.h"
#include <bpf/bpf_helpers.h>
#include <bpf/bpf_core_read.h>

char _license[] SEC("license") = "GPL";

struct Event {
    __u32 Pid;
    __u8 Comm[16];
};

struct {
    __uint(type, BPF_MAP_TYPE_RINGBUF);
    __uint(max_entries, 4096);
} Events SEC(".maps");

SEC("tracepoint/syscalls/sys_enter_execve")
int OnExec(struct trace_event_raw_sys_enter *ctx) {
    struct Event *e = bpf_ringbuf_reserve(
        &Events, sizeof(struct Event), 0);
    if (!e) {
        return 0;
    }
    e->Pid = (__u32)(
        bpf_get_current_pid_tgid() >> 32);
    bpf_get_current_comm(&e->Comm, 16);
    bpf_ringbuf_submit(e, 0);
    return 0;
}

gobee translate --bindings-dir ./bpf ./bpf/src создает оба файла, а также sourcemap (events.bpf.c.map), чтобы ошибки проверяющего соответствовали строкам Go, и типизированный файл привязок (bpf/events_bindings.go), чтобы пользовательский драйвер писал objs.Events, objs.AttachOnExec() и декодировал полезные данные ringbuf напрямую в bpf.Event (ту же структуру, что приведена выше, переизданную в Go) вместо строковых поисков coll.Programs["..."].

C-код намеренно читаем. Если gobee выдает что-то странное, вы это видите. Пример объединения tracepoints + kprobes + XDP в один бинарник см. в example/sysmon/.

Сравнение

gobeeC + clang + bpf2goAya (Rust)bpftraceBCC
Язык для стороны ядраПодмножество GoCRustDSLC
Интеграция с пользовательским пространствомтипизированные Go-привязки + cilium/ebpfbpf2goaya-runtimeнетpython
CO-RE✅ через clang✅✅ через LLVM✅✅
Покрытие хелперов200 типизированных Go-обёртокполное (пишите на C)полноеограниченноеполное (пишите на C)
Ошибка верификатора → исходник✅ Go файл:строка:столбец❌ сырой C✅ Rust файл:строка❌частично
Шлюзование по версии ядра при загрузке✅ через bpfvetвручнуювручнуюн/пво время выполнения
Зависимости инструментовGo + clangclang + bpf2gorustc + LLVMbpftracepython + bcc
Создаваемый артефакт.bpf.o + Go-бинарник.bpf.o + Go-бинарник.bpf.o + Rust-бинарникJITJIT

Если вы уже используете рабочий процесс C / libbpf, gobee не пытается полностью его заменить. Он предназначен для случаев, когда вы хотите иметь сторону ядра, пользовательскую сторону и конвейер сборки в одном Go-модуле.

Что поддерживается сегодня

См. docs/status.md для полной матрицы (подмножество Go, операторы, выражения, каждый хелпер, каждый тип карты, каждая директива). Краткий обзор:

ПоверхностьПокрытие
Типы программ (8)XDP, tracepoint, kprobe / kretprobe, uprobe / uretprobe, sock_ops, TC, cgroup_skb, LSM
Типы карт (19)array, hash, lru_hash, варианты на CPU, bloom_filter, lpm_trie, ringbuf, perf_event_array, prog_array, queue, stack, sk/task/inode storage, devmap/cpumap/xskmap
Хелперы BPF~200 типизированных Go-заглушек, автоматически сгенерированных из заголовков libbpf v1.5.0. Те, что используются в example/helloworld/ и example/sysmon/, протестированы в CI на реальном ядре; остальные непроверены. Создайте issue, если заглушка не соответствует сигнатуре ядра
CO-RE✅ автоопределение. BPF_CORE_READ для полей внутренних структур ядра (task_struct, sock, inode); прямой ctx->field для UAPI-структур контекста BPF (xdp_md, __sk_buff, bpf_sock_ops). Протестировано на Linux 6.x (Ubuntu 24.04 CI); старые ядра пока не в матрице CI
BTF-готовый вывод✅ генерируемый C включает vmlinux.h и использует BPF_CORE_READ для чтения полей внутри ядра, так что BTF, создаваемый clang из clang -g, содержит правильные релокации. Сам clang остаётся вашей ответственностью (примеры Makefile показывают канонический вызов)
Пользовательские хелперы✅ функции Go верхнего уровня без //bpf:section генерируются как static __always_inline C-функции
Типизированные Go-привязки✅ Load<Stem>, Close, per-program Attach<Name>, AttachAll, а также типы структур и константы стороны ядра, переизданные в Go
Шлюзование по версии ядра✅ bpfvet выполняется во время загрузки. Быстро завершается с ошибкой вместо непонятного

Что делает gobee

  • Транслирует подмножество Go в BPF C (и сначала выполняет go/types над вашим входом, чтобы ошибки использования отображались с file:line:col).
  • Генерирует типизированный файл <Stem>_bindings.go рядом с .bpf.c: bpf.LoadCounter(spec), objs.PerIface.Lookup(...), objs.AttachAll(ifindex), а также типы структур и константы стороны ядра, переизданные в Go.
  • Автоматически аннотирует *ebpf.VerifierError от LoadAndAssign с позициями в Go-исходнике; ручной вызов gobee diagnose не требуется.
  • Запускает bpfvet внутри Load<Stem>, так что старые ядра быстро завершаются с bpf program needs kernel >= 5.8, host is 5.4.
  • Предоставляет ~200 типизированных Go-заглушек для набора хелперов libbpf v1.5.0, а также пользовательские функции-хелперы, генерируемые как static __always_inline.

Что gobee не будет делать

  • Заменять clang. Бэкенд BPF от clang даёт нам CO-RE, BTF и дружественную верификатору генерацию кода бесплатно. Перереализация этого стоит годы и не даёт преимуществ.
  • Заменять cilium/ebpf. Сгенерированные привязки работают поверх него.
  • Скрывать BPF. Подмножество Go отображается 1:1 на идиомы BPF C. Если вы знаете BPF, gobee — тонкий сахар. Если нет, руководство всё равно обязательно к прочтению.
  • Запускать clang за вас. Компиляция, встраивание и загрузка остаются в ваших руках. Та же схема, что и в bpf2go.

Зачем транслировать, а не генерировать BPF напрямую

gc, компилятор Go, не имеет бэкенда BPF на основе LLVM. Добавление такого бэкенда — многолетний проект компилятора. rustc построен на LLVM, поэтому Aya работает. Итак, gobee генерирует C и использует бэкенд BPF от clang, что даёт нам зрелую генерацию кода, BTF и релокации CO-RE бесплатно.

Быстрый старт

root@kitploit:~
go install github.com/boratanrikulu/gobee/cmd/gobee@latest

cd example/helloworld
make build                     # gobee translate, clang, go build
sudo ./helloworld eth0

Вам понадобится clang с поддержкой BPF. В Linux это пакет дистрибутива; на macOS — brew install llvm. Сам трансплятор написан на чистом Go и работает везде.

Структура проекта (типичная)

root@kitploit:~
yourproject/
├── bpf/                      # Go-пакет, импортируемый из любой части проекта
│   ├── embed_amd64.go        # //go:embed bin/x86/your.bpf.o
│   ├── embed_arm64.go
│   ├── your_bindings.go      # сгенерировано gobee
│   ├── bin/{x86,arm64}/your.bpf.o
│   └── src/                  # не Go-пакет; здесь живёт clang
│       ├── your.go           # //go:build ignore: BPF исходник
│       ├── your.bpf.c        # сгенерировано
│       ├── Makefile          # clang для каждой архитектуры
│       └── vmlinux.h         # приложенный BTF-дамп
├── main.go                   # импортирует yourproject/bpf
└── Makefile

Такое разделение оставляет bpf/ чистым импортируемым Go-пакетом (Go отвергает .c-файлы в пакетах без cgo). Исходники для ядра и артефакты clang находятся уровнем ниже в bpf/src/.

Примеры

  • example/helloworld/: канонический XDP-счётчик пакетов, ~40 строк BPF, ~80 строк пользовательского кода.
  • example/sysmon/: XDP, две точки трассировки и один kprobe в одном бинарнике, совместно использующие ringbuf для событий. Демонстрирует типизированные контексты для каждого системного вызова, пользовательские функции-хелперы и сокращение AttachAll.

CI

GitHub Actions запускает четыре слоя при каждом push:

  1. go test, go vet, золотые тесты трансплятора
  2. Матрица покрытия: каждый тип карты и вид //bpf:section имеет хотя бы один пример
  3. Компиляция clang каждого курируемого примера, затем отчёт о переносимости bpfvet
  4. Приёмка верификатором на реальном ядре: ebpf.NewCollectionWithOptions для каждого .bpf.o (раннер Ubuntu 24.04, ядро 6.x)

Документация

  • docs/design.md: архитектура и обоснование
  • docs/go-subset.md: принимаемый синтаксис Go в BPF-исходниках
  • docs/directives.md: справка по //bpf:*
  • docs/status.md: матрица поддержки (единый источник истины)

Инструментарий

  • Бинарник gobee собирается везде (чистый Go, без CGO).
  • Для компиляции .bpf.o требуется clang с поддержкой BPF. Встроенный в macOS clang не содержит этой поддержки; на macOS используйте brew install llvm или собирайте внутри Linux-виртуалки.
  • Для запуска артефакта требуется Linux на arm64 или amd64.

Вдохновение

  • Solod: трансплятор Go в C, доказавший, что эта схема работает.
  • Aya: фреймворк eBPF на Rust, за эргономикой которого gobee гонится.

Лицензия

MIT. См. LICENSE.

Copyright (c) 2026 Bora Tanrikulu <[email protected]>

Скачать инструмент
bpf program needs kernel >= 5.8, host is 5.4
EINVAL
Ошибка верификатора → Go-исходник✅ автоматически аннотируется внутри Load<Stem>. Без ручного вызова gobee diagnose; *ebpf.VerifierError возвращается с маркерами → counter.go:18:5
Файл sourcemap✅ <stem>.bpf.c.map записывается рядом с каждым .bpf.c для офлайн-использования также через gobee diagnose
Кроссплатформенность✅ Linux arm64 + amd64