Skip to content
KitploitKITPLOIT
HerramientasBlog
Enviar
HerramientasBlog
Enviar

¡Herramientas de Hacking, PenTest y Ciberseguridad para tu Arsenal de Seguridad!

Kitploit es un directorio de herramientas de hacking, ciberseguridad y pentesting. Descubre las últimas actualizaciones de proyectos para encontrar vulnerabilidades, analizar sistemas, automatizar pruebas y fortalecer tu seguridad.

··Feeds·Contacto·Privacidad·© 2026 Kitploit

Directorio de Herramientas

Categorías

Ver todas las categorías
Loading categories
gobee — Escribe tus programas BPF en Go, no en C. gobee transpila un subconjunto de Go a C BPF y genera bindings tipados de cilium/ebpf. | Kitploit
Herramientas/GitHubGitHub/boratanrikulu/gobee
Análisis EstáticoAnálisis de CódigoScripting y AutomatizaciónDevSecOpsUtilidades y FrameworksAnálisis de Binarios
GitHubboratanrikulu/gobee

gobee

Escribe tus programas BPF en Go, no en C. gobee transpila un subconjunto de Go a C BPF y genera bindings tipados de cilium/ebpf.

Ver Repositorio
34541hace 4 mesesRevisado por Kitploit

Más Populares

Ver todos →

Descubre las herramientas más usadas por nuestra comunidad.

Explora todas las herramientas

Explora nuestra colección de herramientas

Ver todas las herramientas →
Compartir

gobee

Escribe tus programas BPF en Go, no en C. gobee transpila un subconjunto estricto de Go a C BPF, genera enlaces Go tipados para el lado de espacio de usuario y controla las cargas contra el kernel en ejecución.

El ecosistema Go tiene herramientas sólidas de espacio de usuario para BPF. El lado del kernel siempre terminaba con "ahora escribe tu programa en C". Aya llevó eBPF a Rust escribiendo un nuevo backend BPF en rustc. gobee llega de otra manera: transpilando a C y reutilizando el maduro backend de clang.

Un archivo Go de entrada, un programa BPF de salida

Un tracepoint que transmite cada execve al espacio de usuario a través de un ringbuf:

Tu entrada (Go)Lo que gobee emite (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 produce ambos archivos, además de un mapa de origen (events.bpf.c.map) para que los errores del verificador se asignen a líneas Go y un archivo de enlaces tipados (bpf/events_bindings.go) para que el controlador de espacio de usuario escriba objs.Events, objs.AttachOnExec() y decodifique las cargas útiles del ringbuf directamente en bpf.Event (la misma estructura que ves arriba, republicada en Go) en lugar de búsquedas coll.Programs["..."] basadas en cadenas.

El C es legible a propósito. Si gobee emite algo extraño, puedes verlo. Para tracepoints + kprobes + XDP combinados en un solo binario, consulta example/sysmon/.

Comparación

gobeeC + clang + bpf2goAya (Rust)bpftraceBCC
Lenguaje del kernelSubconjunto GoCRustDSLC
Integración con espacio de usuarioEnlaces Go tipados + cilium/ebpfbpf2goaya-runtimeningunopython
CO-RE✅ vía clang✅✅ vía LLVM✅✅
Cobertura de helpers200 wrappers Go tipadoscompleto (escribe C)completolimitadocompleto (escribe C)
Error de verificador → fuente✅ archivo Go:línea:col❌ C puro✅ archivo Rust:línea❌parcial
Control de versión del kernel en carga✅ vía bpfvetmanualmanualn/aruntime
Dependencias de herramientasGo + clangclang + bpf2gorustc + LLVMbpftracepython + bcc
Artefacto generado.bpf.o + binario Go.bpf.o + binario Go.bpf.o + binario RustJITJIT

Si ya estás en un flujo de trabajo C / libbpf, gobee no pretende reemplazarlo por completo. Es para casos en los que quieres el lado del kernel, el lado de espacio de usuario y la canalización de construcción, todo en un solo módulo Go.

Qué se soporta hoy

Consulta docs/status.md para la matriz completa (subconjunto Go, sentencias, expresiones, cada helper, cada tipo de mapa, cada directiva). Vista rápida:

SuperficieCobertura
Tipos de programa (8)XDP, tracepoint, kprobe / kretprobe, uprobe / uretprobe, sock_ops, TC, cgroup_skb, LSM
Tipos de mapa (19)array, hash, lru_hash, variantes por CPU, bloom_filter, lpm_trie, ringbuf, perf_event_array, prog_array, queue, stack, almacenamiento sk/task/inode, devmap/cpumap/xskmap
Helpers BPF~200 stubs Go tipados autogenerados de los encabezados libbpf v1.5.0. Los que se ejercitan en example/helloworld/ y example/sysmon/ se prueban en CI de kernel real; el resto no están verificados. Reporta un problema si un stub no coincide con la firma del kernel
CO-RE✅ detectado automáticamente. BPF_CORE_READ para campos de estructuras internas del kernel (task_struct, sock, inode); ctx->field directo para contextos BPF UAPI (xdp_md, __sk_buff, bpf_sock_ops). Probado en Linux 6.x (CI Ubuntu 24.04); kernels más antiguos aún no están en la matriz CI
Salida lista para BTF✅ el C emitido incluye vmlinux.h y usa BPF_CORE_READ para lecturas de campos internos del kernel, para que el BTF que clang genera de clang -g lleve las reubicaciones correctas. clang sigue siendo tu responsabilidad (los Makefiles de ejemplo muestran la invocación canónica)
Helpers definidos por el usuario✅ las funciones Go de nivel superior sin //bpf:section se emiten como funciones C static __always_inline
Enlaces Go tipados✅ Load<Stem>, Close, Attach<Name> por programa, AttachAll, además de tus tipos de estructura del kernel y constantes republicados en Go
Control de versión del kernel

Qué hace gobee

  • Transpila un subconjunto Go a C BPF (y ejecuta go/types sobre tu entrada primero, para que los usos incorrectos aparezcan en file:line:col).
  • Genera un <Stem>_bindings.go tipado junto al .bpf.c: bpf.LoadCounter(spec), objs.PerIface.Lookup(...), objs.AttachAll(ifindex), además de tus tipos de estructura del kernel y constantes republicados en Go.
  • Anota automáticamente *ebpf.VerifierError de LoadAndAssign con posiciones en el código fuente Go, sin necesidad de tubería manual gobee diagnose.
  • Ejecuta bpfvet dentro de Load<Stem> para que kernels antiguos fallen rápido con bpf program needs kernel >= 5.8, host is 5.4.
  • Expone ~200 stubs Go tipados para el conjunto de helpers de libbpf v1.5.0, además de funciones helper definidas por el usuario emitidas como static __always_inline.

Qué gobee no hará

  • Reemplazar clang. El backend BPF de clang nos da CO-RE, BTF y generación de código compatible con el verificador de forma gratuita. Reimplementarlo cuesta años y no gana nada.
  • Reemplazar cilium/ebpf. Los enlaces generados se sitúan sobre él.
  • Ocultar BPF. El subconjunto Go se asigna 1:1 a expresiones idiomáticas C BPF. Si conoces BPF, gobee es azúcar fino. Si no, el manual sigue siendo lectura obligatoria.
  • Ejecutar clang por ti. Compilar, incrustar y cargar siguen siendo responsabilidad del usuario. Mismo patrón que bpf2go.

Por qué transpilar, no generar BPF directamente

gc, el compilador Go, no tiene un backend BPF basado en LLVM. Agregar uno es un proyecto de compilador de varios años. rustc está construido sobre LLVM y por eso Aya funciona. Así que gobee emite C y reutiliza el backend BPF de clang, lo que nos da generación de código madura, BTF y reubicaciones CO-RE de forma gratuita.

Inicio rápido

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

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

Necesitarás clang con el objetivo BPF. En Linux es el paquete de la distribución; en macOS, brew install llvm. El transpilador en sí es Go puro y funciona en cualquier lugar.

Estructura típica del proyecto

root@kitploit:~
tuproyecto/
├── bpf/                      # Paquete Go, importable desde cualquier lugar de tu proyecto
│   ├── embed_amd64.go        # //go:embed bin/x86/tu.bpf.o
│   ├── embed_arm64.go
│   ├── tu_bindings.go        # generado por gobee
│   ├── bin/{x86,arm64}/tu.bpf.o
│   └── src/                  # No es un paquete Go; clang vive aquí
│       ├── tu.go             # //go:build ignore: fuente BPF
│       ├── tu.bpf.c          # generado
│       ├── Makefile          # clang por arquitectura
│       └── vmlinux.h         # volcado BTF incluido
├── main.go                   # importa tuproyecto/bpf
└── Makefile

La división mantiene bpf/ como un paquete Go limpio e importable (Go rechaza archivos .c en paquetes que no usan cgo). Las fuentes del kernel y los artefactos de clang viven un nivel más abajo en bpf/src/.

Ejemplos

  • example/helloworld/: el contador de paquetes XDP canónico, ~40 líneas BPF, ~80 líneas de espacio de usuario.
  • example/sysmon/: XDP, dos tracepoints y un kprobe en un solo binario, compartiendo un ringbuf para eventos. Demuestra contextos tipados por syscall, funciones helper definidas por el usuario y el atajo AttachAll.

CI

GitHub Actions ejecuta cuatro capas en cada push:

  1. go test, go vet, pruebas golden del transpilador
  2. Matriz de cobertura: cada tipo de mapa y tipo de //bpf:section tiene al menos un ejemplo
  3. Compilación con clang de cada ejemplo seleccionado, luego informe de portabilidad de bpfvet
  4. Aceptación del verificador del kernel real: ebpf.NewCollectionWithOptions en cada .bpf.o (ejecutor Ubuntu 24.04, kernel 6.x)

Documentación

  • docs/design.md: arquitectura y fundamentos
  • docs/go-subset.md: sintaxis Go aceptada en archivos fuente BPF
  • docs/directives.md: referencia de //bpf:*
  • docs/status.md: matriz de soporte (fuente única de verdad)

Herramientas

  • El binario gobee se compila en cualquier lugar (Go puro, sin CGO).
  • Compilar .bpf.o necesita clang con el objetivo BPF. El clang incluido de Apple no lo trae; en macOS usa brew install llvm o compila dentro de una máquina virtual Linux.
  • Ejecutar el artefacto necesita Linux en arm64 o amd64.

Inspiraciones

  • Solod: el transpilador Go-a-C que demostró que este patrón funciona.
  • Aya: el framework eBPF para Rust cuya ergonomía gobee persigue.

Licencia

MIT. Ver LICENSE.

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

Descargar herramienta
✅ bpfvet se ejecuta en tiempo de carga. Falla rápido con bpf program needs kernel >= 5.8, host is 5.4 en lugar de EINVAL opaco
Error de verificador → fuente Go✅ anotado automáticamente dentro de Load<Stem>. Sin tubería manual a gobee diagnose; *ebpf.VerifierError regresa con marcadores → counter.go:18:5
Archivo sidecar de mapa de origen✅ <stem>.bpf.c.map se escribe junto a cada .bpf.c para uso offline también con gobee diagnose
Multi-arquitectura✅ Linux arm64 + amd64