Skip to content
KitploitKITPLOIT
OutilsBlog
Soumettre
OutilsBlog
Soumettre

Outils de Hacking, PenTest et Cybersécurité pour votre Arsenal de Sécurité !

Kitploit est un répertoire d'outils de hacking, de cybersécurité et de pentesting. Découvrez les dernières mises à jour des projets pour trouver des vulnérabilités, analyser des systèmes, automatiser les tests et renforcer votre sécurité.

··Flux·Contact·Confidentialité·© 2026 Kitploit

Répertoire d'outils

Catégories

Voir toutes les catégories
Loading categories
goblin — Un crate espiègle et multiplateforme pour l'analyse binaire, écrit en Rust | Kitploit
Outils/GitHubGitHub/m4b/goblin
Rétro-ingénierieFuzzingAnalyse de Binaires
GitHubm4b/goblin

goblin

Un crate espiègle et multiplateforme pour l'analyse binaire, écrit en Rust

Voir le dépôt
1.5k200il y a 2 moisVérifié par Kitploit

Populaires

Voir tout →

Découvrez les outils les plus utilisés par notre communauté.

Explorer tous les outils

Parcourez notre collection d'outils

Voir tous les outils →
Partager

libgoblin

Actions crates.io version

dites les mots justes

Documentation

https://docs.rs/goblin/

journal des modifications

Utilisation

Goblin nécessite rustc 1.85.0 (édition Rust 2024).

Ajoutez à votre Cargo.toml

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

Fonctionnalités

  • nom de crate génial
  • implémentation zero-copy, cross-platform, endian-aware, ELF64/32 - wow !
  • analyseur Mach-o zero-copy, cross-platform, endian-aware, 32/64 bits - zoiks !
  • analyseur PE 32/64 bits - bing !
  • un analyseur d'archives style Unix et BSD (ce dernier grâce à @willglynn) - huzzah !
  • de nombreuses options cfg - ça vous fera tourner la tête et vous rendra furieux en lisant le code source !
  • fuzzé - « Je suis heureux de rapporter que goblin a résisté à 100 millions de runs de fuzzing, 1 million de runs pour chaque graine 1~100. » - @sanxiyn
  • tests

libgoblin vise à être votre guichet unique pour l'analyse, le chargement et l'analyse binaire.

Cas d'utilisation

Goblin prend principalement en charge les cas d'utilisation importants suivants :

  1. Structures #[repr(C)] sans std, temps de compilation minuscule, 32/64 (ou les deux) à votre guise.

  2. Type punning. Définissez une fonction une fois sur un type, mais faites-la fonctionner sur des variantes 32 ou 64 bits - sans vraiment rien changer, et sans macros ! Voir examples/automagic.rs pour un exemple de base.

  3. Mode std. Cela ajoute des implémentations de lecture et écriture via Pread et Pwrite, la lecture depuis un fichier, des allocations pratiques, des méthodes supplémentaires, etc. Ceci est pour les clients qui peuvent allouer et veulent lire des binaires depuis le disque.

  4. Endian_fd. Un nom vraiment terrible 😆 ceci est pour l'analyse binaire comme dans panopticon ou falcon qui nécessite de lire des binaires d'endianness étrangère, ou comme base pour construire des binutils cross-platform d'architecture étrangère, par exemple cargo-sym et bingrep sont des exemples simples, mais le ciel est la limite.

Voici quelques choses que vous pourriez faire avec cette crate (ou aider à implémenter pour qu'elles puissent être faites) :

  1. Écrire un compilateur et l'utiliser pour générer des binaires (toutes les structures C brutes ont Pwrite dérivé).
  2. Écrire un outil d'analyse binaire qui charge, analyse et examine divers formats binaires, par ex. panopticon ou falcon.
  3. Écrire un éditeur de liens dynamique semi-fonctionnel.
  4. Écrire un noyau et charger des binaires en utilisant la configuration no_std. C'est-à-dire qu'il s'agit essentiellement de définitions de structs et de constantes (comme un en-tête C) - pas de fd, pas de sortie, pas de std.
  5. Écrire un outil bin2json, car pourquoi les formats binaires ne devraient-ils pas être en JSON ?

Cfgs

libgoblin est conçu pour être massivement configurable. Les drapeaux actuels sont :

  • elf64 - binaires elf 64 bits, définitions de structures repr(C)
  • elf32 - binaires elf 32 bits, définitions de structures repr(C)
  • mach64 - définitions de structures Mach-o 64 bits repr(C)
  • mach32 - définitions de structures Mach-o 32 bits repr(C)
  • pe32 - définitions de structures PE 32 bits repr(C)
  • pe64 - définitions de structures PE 64 bits repr(C)
  • te - Exécutable Terse (TE) définitions de structures repr(C)
  • archive - un analyseur d'archives Unix
  • endian_fd - analyse selon l'endianness dans le binaire
  • std - pour permettre les environnements no_std

Mainteneurs

  1. PE: @kkent030315
  2. Elf: @m4b, ouvert aux candidatures
  3. Mach-o: @m4b, ouvert aux candidatures

Les mainteneurs sont les premiers relecteurs pour ce backend particulier. Ils sont choisis en fonction des contributions antérieures, de l'activité, des connaissances de base et d'un comportement aimable et grégaire :D

Actuellement, je (@m4b) ai seul les droits de fusion pour toutes les PR. À l'avenir, il est probable que le(s) mainteneur(s) de ce backend donné auront également des droits de fusion.

Enfin, je donnerai probablement encore des revues superficielles à toutes les PR, mais je me référerai principalement/entièrement au mainteneur de ce backend.

Et souvenez-vous toujours de la sagesse de Bill et Ted : « Soyez excellents les uns envers les autres ! »

Contributeurs

Merci à tous ❤️ !

Dans l'ordre lexicographique :

  • @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

Contribuer

Sauf indication contraire explicite, vous acceptez que vos contributions soient licenciées comme décrit dans le fichier LICENSE accompagnant (MIT).

  1. Veuillez préfixer les commits avec le composant binaire concerné ; plus c'est spécifique, mieux c'est, par exemple, si vous modifiez uniquement les relocalisations dans le module elf, faites "elf.reloc: added new constants for Z80"
  2. Les messages de commit doivent expliquer leur changement, pas de "changed" ou "fix" génériques ; si vous poussez des commits comme ça sur une PR, sachez que @m4b ou quelqu'un les écrasera très probablement.
  3. Si vous apportez un changement important à un module, veuillez d'abord ouvrir une issue et discutons-en ; je ne veux pas vous faire perdre votre temps si ce n'est pas une bonne direction technique, etc.
  4. Si votre PR n'obtient pas d'attention, veuillez répondre à tous les commentaires pertinents soulevés sur la PR, et si toujours pas de réponse, ping @m4b sur github et n'hésitez pas à envoyer un email à @m4b.
  5. Veuillez ajouter des tests si vous ajoutez une nouvelle fonctionnalité. N'hésitez pas à ajouter des tests même si ce n'est pas le cas, les tests sont géniaux et faciles en rust.
Télécharger l’outil
@ivlzme
  • @jackcmay
  • @jan-auer
  • @Javagedes
  • @jessehui
  • @jdub
  • @Jhynjhiruu
  • @johannst
  • @JohnScience
  • @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