libgoblin

di' le parole giuste

Documentazione

https://docs.rs/goblin/

registro delle modifiche

Utilizzo

Goblin richiede rustc 1.85.0 (edizione Rust 2024).

Aggiungi al tuo Cargo.toml

[dependencies]
goblin = "0.10"

Caratteristiche

nome fantastico del crate
implementazione zero-copy, cross-platform, endian-aware per ELF64/32 - wow!
parser zero-copy, cross-platform, endian-aware per Mach-o 32/64 bit - zoiks!
parser PE 32/64 bit - bing!
un parser di archivi Unix e BSD (quest'ultimo grazie a @willglynn) - evviva!
molte opzioni cfg - ti farà girare la testa e ti farà arrabbiare quando leggi il sorgente!
fuzzed - "Sono felice di riferire che goblin ha resistito a 100 milioni di esecuzioni di fuzzing, 1 milione di esecuzioni per ogni seed da 1 a 100." - @sanxiyn
test

libgoblin mira a essere il tuo sportello unico per parsing, caricamento e analisi di binari.

Casi d'uso

Goblin supporta principalmente i seguenti casi d'uso importanti:

Strutture #[repr(C)] core, senza std, tempo di compilazione ridotto, 32/64 (o entrambi) a tuo piacimento.
Type punning. Definisci una funzione una volta su un tipo, ma falla funzionare su varianti a 32 o 64 bit - senza cambiare nulla, e niente macro! Vedi examples/automagic.rs per un esempio base.
Modalità std. Aggiunge implementazioni di lettura e scrittura tramite Pread e Pwrite, lettura da file, allocazioni di comodo, metodi extra, ecc. Questo è per client che possono allocare e vogliono leggere binari dal disco.
Endian_fd. Un nome davvero terribile 😆 questo è per analisi binaria come in panopticon o falcon che necessitano di leggere binari con endianness diversa, oppure come base per costruire binutils cross-platform per architetture straniere, ad es. cargo-sym e bingrep sono semplici esempi di questo, ma il cielo è il limite.

Ecco alcune cose che potresti fare con questo crate (o aiutare a implementare in modo che possano essere realizzate):

Scrivere un compilatore e usarlo per generare binari (tutte le strutture C grezze hanno Pwrite derivato).
Scrivere uno strumento di analisi binaria che carica, analizza e analizza vari formati binari, ad es., panopticon o falcon.
Scrivere un linker dinamico semi-funzionante.
Scrivere un kernel e caricare binari usando la configurazione no_std. Cioè, è essenzialmente solo definizioni di struct e const (come un header C) - nessun fd, nessun output, nessun std.
Scrivere uno strumento bin2json, perché i formati binari non dovrebbero essere in JSON?

Configurazioni

libgoblin è progettato per essere massicciamente configurabile. Le flag attuali sono:

elf64 - binari elf a 64 bit, definizioni di struct repr(C)
elf32 - binari elf a 32 bit, definizioni di struct repr(C)
mach64 - definizioni di struct repr(C) per mach-o a 64 bit
mach32 - definizioni di struct repr(C) per mach-o a 32 bit
pe32 - definizioni di struct repr(C) per PE a 32 bit
pe64 - definizioni di struct repr(C) per PE a 64 bit

te - definizioni di struct repr(C) per Terse Executable (TE)

archive - un parser di archivi Unix
endian_fd - analizza in base all'endianness nel binario
std - per permettere ambienti no_std

Manutentori

PE: @kkent030315
Elf: @m4b, aperto a candidature
Mach-o: @m4b, aperto a candidature

I manutentori sono i revisori di primo contatto per quel particolare backend. Vengono scelti in base ai contributi precedenti, all'attività, alla conoscenza di base e al comportamento amichevole e socievole :D

Attualmente, io (@m4b) ho solo diritti di merge per tutte le PR. In futuro è probabile che anche i manutentori di quel determinato backend avranno diritti di merge.

Infine, probabilmente darò comunque revisioni sommarie a tutte le PR, ma mi affiderò principalmente/in toto al manutentore per quel backend.

E ricorda sempre la saggezza di Bill e Ted: "Siate eccellenti gli uni con gli altri!"

Collaboratori

Grazie a tutti ❤️ !

In ordine lessicografico:

Contribuire

Salvo diversa indicazione esplicita, accetti che i tuoi contributi siano concessi in licenza come descritto nel file LICENSE allegato (MIT).

Per favore, prefissa i commit con il componente binario interessato; più specifico è meglio, ad es., se modifichi solo i relocation nel modulo elf, allora fai "elf.reloc: aggiunte nuove costanti per Z80"
I messaggi di commit devono spiegare la loro modifica, niente generici "changed" o "fix"; se invii commit del genere su una PR, sappi che @m4b o qualcun altro molto probabilmente li schiaccerà.
Se stai apportando una modifica importante a un modulo, per favore apri prima un issue e discutiamo; non voglio sprecare il tuo tempo se non è una buona direzione tecnica, o altro.
Se la tua PR non sta ottenendo attenzione, per favore rispondi a tutti i commenti pertinenti sollevati sulla PR, e se ancora nessuna risposta, pinga @m4b su github e sentiti libero di inviare una email a @m4b.
Per favore aggiungi test se stai aggiungendo una nuova funzionalità. Sentiti libero di aggiungere test anche se non lo stai facendo, i test sono fantastici e facili in Rust.

goblin

Più Popolari