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
goblin — Un travieso crate de parseo binario multiplataforma, escrito en Rust. | Kitploit
Herramientas/GitHubGitHub/m4b/goblin
Ingeniería InversaFuzzingAnálisis de Binarios
GitHubm4b/goblin

goblin

Un travieso crate de parseo binario multiplataforma, escrito en Rust.

Ver Repositorio
1.5k200hace 2 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

libgoblin

Actions crates.io version

di las palabras correctas

Documentación

https://docs.rs/goblin/

registro de cambios

Uso

Goblin requiere rustc 1.85.0 (Rust edición 2024).

Añade a tu Cargo.toml

root@kitploit:~
[dependencies]
goblin = "0.10"

Características

  • nombre increíble del crate
  • implementación zero-copy, multiplataforma, consciente de endianness, ELF64/32 - ¡wow!
  • analizador zero-copy, multiplataforma, consciente de endianness, Mach-o de 32/64 bits - ¡zoiks!
  • analizador PE de 32/64 bits - ¡bing!
  • un analizador de archivos estilo Unix y BSD (este último cortesía de @willglynn) - ¡hurra!
  • muchas opciones de cfg - ¡te hará dar vueltas la cabeza y enfadarte al leer el código fuente!
  • fuzzeado - "Me complace informar que goblin resistió 100 millones de ejecuciones de fuzzing, 1 millón de ejecuciones cada una para la semilla 1~100." - @sanxiyn
  • pruebas

libgoblin pretende ser tu tienda única para análisis, carga y análisis de binarios.

Casos de uso

Goblin soporta principalmente los siguientes casos de uso importantes:

  1. Estructuras #[repr(C)] centrales, sin std, tiempo de compilación mínimo, 32/64 (o ambas) a tu gusto.

  2. Type punning. Define una función una vez en un tipo, pero haz que funcione en variantes de 32 o 64 bits - sin cambiar realmente nada, ¡y sin macros! Consulta examples/automagic.rs para un ejemplo básico.

  3. Modo std. Esto añade implementaciones de lectura y escritura mediante Pread y Pwrite, lectura desde archivo, asignaciones convenientes, métodos adicionales, etc. Esto es para clientes que pueden asignar memoria y quieren leer binarios desde el disco.

  4. Endian_fd. Un nombre realmente terrible 😆 esto es para análisis de binarios como en panopticon o falcon que necesita leer binarios de endianness foránea, o como base para construir binutils de arquitectura foránea multiplataforma, por ejemplo cargo-sym y bingrep son ejemplos simples de esto, pero el cielo es el límite.

Aquí hay algunas cosas que podrías hacer con este crate (o ayudar a implementar para que se puedan hacer):

  • Escribe un compilador y úsalo para generar binarios (todas las estructuras C sin procesar tienen Pwrite derivado).
  • Escribe una herramienta de análisis de binarios que cargue, analice y examine varios formatos binarios, por ejemplo, panopticon o falcon.
  • Escribe un enlazador dinámico semi-funcional.
  • Escribe un kernel y carga binarios usando cfg no_std. Es decir, es esencialmente solo definiciones de struct y constantes (como un encabezado C) - sin fd, sin salida, sin std.
  • Escribe una herramienta bin2json, porque ¿por qué los formatos binarios no deberían estar en JSON?

Configuraciones (Cfgs)

libgoblin está diseñado para ser masivamente configurable. Las banderas actuales son:

  • elf64 - binarios elf de 64 bits, definiciones de struct repr(C)
  • elf32 - binarios elf de 32 bits, definiciones de struct repr(C)
  • mach64 - definiciones de struct repr(C) de mach-o de 64 bits
  • mach32 - definiciones de struct repr(C) de mach-o de 32 bits
  • pe32 - definiciones de struct repr(C) de PE de 32 bits
  • pe64 - definiciones de struct repr(C) de PE de 64 bits
  • te - definiciones de struct repr(C) de Terse Executable (TE)
  • archive - un analizador de archivos Unix
  • endian_fd - analiza según la endianness en el binario
  • std - para permitir entornos no_std

Mantenedores

  1. PE: @kkent030315
  2. Elf: @m4b, abierto a solicitudes
  3. Mach-o: @m4b, abierto a solicitudes

Los mantenedores son los revisores de primer contacto para ese backend en particular. Son elegidos según contribuciones previas, actividad, conocimiento base y comportamiento amigable y gregario :D

Actualmente, yo (@m4b) solo tengo derechos de fusión para todos los PRs. En el futuro es probable que el/los mantenedor(es) de ese backend dado también tengan derechos de fusión.

Por último, probablemente seguiré dando revisiones superficiales a todos los PRs, pero delegaré mayormente/completamente al mantenedor de ese backend.

Y recuerda siempre la sabiduría de Bill y Ted: "¡Sed excelentes los unos con los otros!"

Contribuidores

¡Gracias a todos ❤️!

En orden lexicográfico:

  • @000lbh
  • @2vg
  • @5225225
  • @alessandrod
  • @amanieu
  • @anfedotoff
  • @apalm
  • @baloo
  • @BinFlip
  • @burjui
  • @CalebFenton
  • @chf0x
  • @connorkuehl
  • @dancrossnyc
  • @DreydenGys
  • @dureuill
  • @Evian-Zhang
  • @ExPixel
  • @flanfly
  • @glandium
  • @glslang
  • @Gelbpunkt
  • @gunbux
  • @h33p
  • @hannahfluch
  • @Hexorg
  • @ibabushkin
  • @ideeockus

Contribuir

A menos que se indique explícitamente lo contrario, aceptas que tus contribuciones tienen la licencia descrita en el archivo LICENSE adjunto (MIT).

  1. Por favor, prefija los commits con el componente binario afectado; cuanto más específico mejor, p.ej., si solo modificas reubicaciones en el módulo elf, entonces haz "elf.reloc: added new constants for Z80"
  2. Los mensajes de commit deben explicar su cambio, sin "cambiado" o "arreglo" genéricos; si envías commits así en un PR, ten en cuenta que @m4b o alguien probablemente los aplastará.
  3. Si estás haciendo un cambio grande en un módulo, por favor abre un issue primero y discutamos; no quiero desperdiciar tu tiempo si no es una buena dirección técnica, etc.
  4. Si tu PR no recibe atención, por favor responde a todos los comentarios relevantes planteados en el PR, y si aún no hay respuesta, menciona a @m4b en github y también siéntete libre de enviar un correo electrónico a @m4b.
  5. Por favor, añade pruebas si estás agregando una nueva característica. Siéntete libre de añadir pruebas incluso si no lo estás, las pruebas son geniales y fáciles en rust.
Descargar herramienta
@ivlzme
  • @jackcmay
  • @jan-auer
  • @Javagedes
  • @jessehui
  • @jdub
  • @Jhynjhiruu
  • @JohnScience
  • @johannst
  • @joschock
  • @jrmuizel
  • @jsgf
  • @Jvlegod
  • @keith
  • @kjempelodott
  • @kkent030315
  • @ko1n
  • @le-jzr
  • @Lichtso
  • @lion128
  • @lissyx
  • @llogiq
  • @lumag
  • @lzutao
  • @lzybkr
  • @m-hilgendorf
  • @makubacki
  • @mmaekr
  • @m4b
  • @messense
  • @mitsuhiko
  • @mkroening
  • @mre
  • @Mrmaxmeier
  • n01e0
  • nathaniel-daniel
  • @nick96
  • @nico-abram
  • @npmccallum
  • @pchickey
  • @philipc
  • @PJB3005
  • @prettyroseslover
  • @Pzixel
  • @quake
  • @raindev
  • @RaitoBezarius
  • @ReturnRei
  • @rocallahan
  • @sanxiyn
  • @SAY-5
  • @skdltmxn
  • @sollyucko
  • @supervacuus
  • @Swatinem
  • @SweetVishnya
  • @SquareMan
  • @tathanhdinh
  • @Techno-coder
  • @tiann
  • @ticki
  • @Timmmm
  • @Tiwalun
  • @track-5
  • @tux3
  • @wickerwacka
  • @willglynn
  • @woodruffw
  • @wyxloading
  • @xcoldhandsx
  • @x0rb3l
  • @x64k