Oltre al classico UPX, dovresti dare un'occhiata a Burneye (con i suoi cracker, UNFburninhell e Burndump) e elfuck. Sono piuttosto vecchi, ma comunque interessanti.

Se sei interessato ai trucchi che possono essere usati, questa è una buona introduzione di aczid e ti consiglio anche Schemi di protezione binaria per una panoramica più completa.

Qualcuno ha anche presentato un CanSecWest, un packer chiamato Shiva che era rotto a Blackhat. Sfortunatamente, non ci sono fonti disponibili.

UPX è un programma di compressione open source che funziona su binari ELF.

Fare clic sui nomi degli strumenti per eseguire il download. Alcuni saranno solo codice sorgente, altri solo binario. Utilizzare a proprio rischio.

Ci sono 4 sezioni:

1. progetti sperimentali, che sono stati sviluppati per promuovere lo stato dell'arte nella protezione binaria ELF scopi di ricerca
2. strumenti derivanti da progetti personali o creati per divertimento / come hobby
3. protettori storicamente rilevanti, ora violati / deprecati
4. protettori moderni - quelli noti a il tempo di scrittura da utilizzare nel "mondo reale", per così dire (al di fuori del mondo accademico, ad esempio nel malware).

Sperimentale / Proof of Concept

• dacryfile (2001)

  articolo phrack: Armatura ELF: crittografia binaria sulla piattaforma UNIX

  Dacryfile è una raccolta di strumenti che implementano il concetto seguente. Il file host viene crittografato dall'inizio della sezione .text fino alla fine del segmento .text . Il file ora ha il suo codice oggetto e i suoi dati di sola lettura protetti dalla crittografia, mentre tutti i suoi dati e oggetti dinamici sono aperti all'ispezione. Il file host viene iniettato con un parassita che eseguirà la decrittografia a runtime. Questo parassita può avere dimensioni arbitrarie perché viene aggiunto alla fine del segmento .data .

  "Codice parassita" si riferisce al codice inserito nel file su disco o nell'immagine di processo in memoria per modificare il comportamento di runtime del programma. Diverse tecniche storicamente utilizzate per realizzare questo tipo di inserimento di codice sono discusse nell'articolo di Silvio Cesare Unix Viruses (1999)

  Il meccanismo con cui il codice parassita viene aggiunto al binario ELF contenente il codice crittografato realizzato viene indicato dal grugq come "collegamento dinamico sovversivo":

  Il parassita stesso è abbastanza semplice, utilizzando la dinamica sovversiva che collega la libreria Linux per accedere alle funzioni libc e rc4 per decrittografare l'host.

  Questa tecnica è stata descritta in dettaglio nel suo articolo Cheating the ELF, in cui il codice parassita scritto su un eseguibile collegato dinamicamente è in grado di effettuare chiamate alle funzioni di libreria essenzialmente cercando nel file proc / self / maps del processo il caricamento degli oggetti condivisi di glibc e scaricando funzioni per caricare le librerie di interesse.

• shiva 0.96 (2003) (solo binario (protetto))

  • Presentazione introduttiva

  • Defeat Presentation

    Implementa le seguenti funzionalità:

    • Livello di offuscamento esterno per contrastare l'analisi statica
    • Livello intermedio con crittografia AES e protetto da password
    • Livello interno crittografato costituito da blocchi crypt che possono essere mappati in memoria su richiesta
    • Rilevamento flag TRAP per prevenire passaggi singoli
    • fork e poi proc esses ptrace () a vicenda, il che impedisce a PTRACE_ATTACH
    • di saltare nel mezzo delle istruzioni
    • cattura SIGTRAP
    • controlli di temporizzazione
    • Sostituzione dell'istruzione INT3

    Al di fuori di queste presentazioni, è stato difficile trovare informazioni aggiuntive oltre ad alcune discussioni negli articoli phrack sulla crittografia runtime ELF / decrittazione. Non è disponibile alcun codice sorgente, solo il binario, che è protetto.

• cryptexec (2005)

  articolo phrack: cryptexec: crittografia binaria runtime di prossima generazione che utilizza l'estrazione di funzioni su richiesta. Il codice sorgente è incluso alla fine.

  Qui la decrittografia del runtime viene eseguita tramite una combinazione di una funzione di tracciamento che utilizza uno stack privato, un disassemblatore e l'emulazione del codice per leggere i blocchi di 24 byte vengono letti, decrittati, disassemblati e quindi emulati. Ciò garantisce che non più di 24 byte di codice di programma non crittografato risiedano in memoria durante la decrittografia e l'esecuzione del codice protetto.

  La routine di traccia mantiene due contesti: il contesto tracciato e il proprio contesto. Il contesto è costituito da 8 registri e flag per uso generico a 32 bit. Gli altri registri non vengono modificati dalla routine. Entrambi i contesti sono contenuti nello stack privato (che viene utilizzato anche per chiamare C).

  L'idea è di recuperare, una alla volta, le istruzioni dal programma tracciato ed eseguirle in modo nativo. Il set di istruzioni Intel ha una codifica piuttosto irregolare, quindi il motore di disassemblaggio XDE [5] viene utilizzato per trovare sia il codice operativo reale che la lunghezza totale dell'istruzione. Durante gli esperimenti su FreeBSD (che utilizza l'istruzione MOV con prefisso LOCK nel suo caricatore dinamico) ho scoperto un bug in XDE che è descritto e risolto di seguito.

  Manteniamo il nostro EIP in traced_eip, arrotondandolo al successivo limite inferiore di 8 byte e quindi decrittografare 24 byte nel nostro buffer. Quindi avviene lo smontaggio e il controllo viene trasferito alle routine di emulazione tramite la tabella di controllo del codice operativo. Tutte le istruzioni, ad eccezione del trasferimento del controllo, vengono eseguite in modo nativo (in un contesto tracciato che viene ripristinato al momento opportuno). Dopo l'esecuzione di una singola istruzione, il controllo viene restituito alla nostra routine di traccia.

• CSPIM (2010)

  Sviluppato anche da Vrba (il progettista del suddetto cryptexec ) e presentato nel documento Program Obfuscation by Strong Cryptography (il documento è protetto da paywall ma il codice è su GitHub e sul sito di Vrba):

  ... presentiamo un metodo di offuscamento del programma basato sulla combinazione di una forte crittografia di codice e dati e un simulatore di CPU (CSPIM) che implementa il set di istruzioni MIPS I. Il nostro metodo è diverso dai metodi esistenti in quanto solo una singola parola (32 bit) del codice o dei dati protetti è presente come testo normale nella memoria principale. Inoltre, il nostro metodo consente la possibilità di fornire esternamente la chiave di decrittazione al simulatore.

  

  Il diagramma sopra è tratto da Miglioramenti a un codificatore di codice basato su macchina virtuale (nessun codice disponibile per questo documento per quanto ne so).

Progetti personali

• cryptelf (2003) di SLACKo

  Modifica binario aggiungendo codice per gestire la decrittografia a runtime, cambiando il punto di ingresso del programma e cambiando il . nota segmento in LOAD . Crittografa la sezione .text XORing i suoi byte con una chiave.

• ELF Encrypter - Ultimo aggiornamento : 2013-03-12

  Sembra fare affidamento sulla classica iniezione di codice runtime o tecniche di codice parassita per eseguire la decrittografia a runtime.

  Il file crittografato (generato dal crypt-7lib ) verrà decifrato in fase di esecuzione da una libreria condivisa, direttamente collegata al binario o elencata in LD_PRELOAD , durante la sua routine di inizializzazione. La suite contiene anche programmi per iniettare codice semplice e crittografato nei binari ELF.

  ELF-Encrypter 0.12

  • ha cambiato la tecnica di infezione del segmento di dati
  • aggiunta il codice per correggere gli offset della tabella delle sezioni

• ps2-packer (2013)

  Basato su UPX.

  Proprio come UPX, questo strumento è progettato per aiutarti a creare ELF impacchettato da eseguire su PS2. Ha un design modulare, quindi chiunque può farlo scrivere qualsiasi tipo di modulo su di esso. In realtà ha un modulo zlib, un modulo lzo, tre moduli ucl (n2b, n2d e n2e) e un modulo null, solo a scopo dimostrativo.

• midgetpack (2014)

  Midgetpack contiene due modalità di funzionamento: password e scambio di chiavi curve25519.

  Il curve25519 è il vero vantaggio del midgetpack. In questa modalità, non fornisci alcuna password o chiave. Al contrario, un file chiave viene generato al momento del confezionamento. Questo file chiave deve essere utilizzato ogni volta che si desidera utilizzare il binario. Quando avvii il binario, darà una sfida e si aspetterà una risposta. Copia / incolla la sfida nell'input dello strumento mpkex e ricevi una risposta contenente la chiave crittografata al binario. Questo scambio di chiavi è protetto dallo scambio di chiavi Curve25519, la chiave è crittografata con aes-128 e l'intero scambio è autenticato con HMAC-SHA256 per evitare attacchi generici man-in-the-middle.

• oplzkwp (2015)

  oplzkwp è una libreria per l'offuscamento ELF. Utilizza PRESENT e blake244 per crittografare il tuo payload al volo. Solo le funzioni attualmente eseguite vengono decrittografate in memoria. Sono supportati sia Linux (x86) che Android (ARM).

• pocrypt (2015)

  Prova di codice per dimostrare come criptare parti di un binario. Il binario modificato viene esteso con una piccola funzione che decrittografa le parti protette del file in fase di esecuzione per consentirne l'esecuzione.

• ELF-Packer (2017)

  Strumento semplice sviluppato come compito a casa. Utilizza il codice parassita inserito in una caverna del codice per eseguire l'offuscamento o l'annullamento XOR di runtime della sezione .text di un binario di destinazione. I dettagli sono discussi in Simple Polymorphic x86-64 Runtime Code Segment Crpytor.

• ELFcrypt (2018)

  Semplice crypter ELF. Utilizza la crittografia RC4.

• Esperimenti di Ryan O'Neill (@ryan_elfmaster). Questi possono avere valore di ricerca:
  • ELF Packer v0.3 (2009)
  • sherlocked (2014)
  • davinci (2015)
  • saruman (2018)

Historical

• burneye (v1) del gruppo Teso (2002)

  Il seguente riepilogo è fornito in cryptexec: Crittografia binaria runtime di nuova generazione che utilizza l'estrazione di funzioni su richiesta (ulteriori informazioni sono incluse nella documentazione di burneye):

  Analogamente a Shiva, ha tre livelli: 1) offuscamento, 2) crittografia basata su password utilizzando RC4 e SHA1 (per generare la chiave dalla passphrase) e 3) il livello di impronte digitali.

  Il livello di fingerprinting è quello più interessante: i dati sul sistema di destinazione vengono raccolti (es. quantità di memoria, ecc.) e trasformati in una "impronta digitale". L'eseguibile viene crittografato tenendo conto dell'impronta digitale in modo che il binario risultante possa essere eseguito solo sull'host con l'impronta digitale data. Sono disponibili due opzioni di fingerprinting:

  • È possibile specificare la tolleranza dell'impronta digitale in modo che siano consentite piccole deviazioni. In questo modo, ad esempio, la memoria può essere aggiornata sul sistema di destinazione e l'eseguibile continuerà a funzionare. Se il numero di differenze nell'impronta digitale è troppo grande, il programma non funzionerà.

  • Sigillo: il programma prodotto con questa opzione funzionerà su qualsiasi sistema. Tuttavia, la prima volta che viene eseguito, crea un'impronta digitale del file host e "sigilla" se stesso a tale host. Il binario del sigillo originale viene eliminato in modo sicuro in seguito.

  Il binario crittografato può anche essere fatto per eliminare se stesso quando una determinata variabile di ambiente viene impostata durante l'esecuzione del programma.

• objobf aka burneye2 (2003 )

  Legge un file oggetto riposizionabile ELF e produce un file di output equivalente funzionale, che è una versione offuscata del file di input. Per fare ciò, objobf suddivide tutte le funzioni nel file al livello di blocco di base. Questa rappresentazione viene utilizzata per modificare il codice mantenendolo semanticamente equivalente. Ciò implica l'analisi del flusso di dati e le trasformazioni di blocco di base. Successivamente, la rappresentazione del blocco di base come grafico del flusso di controllo viene linearizzata in un nuovo file oggetto, che viene creato da zero.

• elfuck

  Implementa la compressione eseguibile e la crittografia. Basato su UPX e burneye.

  • ELFuck utilizza l'eccellente Markus F.X.J. Algoritmo di compressione di Oberhumer, NRV2E che trasporta un'ottima compressione con un piccolo decompressore (circa 128 byte!). Questa famiglia di algoritmi viene rubata da UPX, con la differenza che la decompressione viene eseguita in tempo reale; ELFuck decomprimerà ELF direttamente nel segmento .text / .data ed eseguirà un'immagine ELF autentica da lì, d'altra parte, UPX crea ELF originale in / tmp e lo esegue (), in modo da non aver bisogno di alcun filesystem scrivibile.

  • Poiché ELFuck è basato al 100% su idee rubate, ho implementato anche questo di BurnEye. Qualcuno potrebbe voler impedire ad altri utenti di usare / analizzare il tuo binario (shell pubbliche, home utente di navigazione root). L'algoritmo è piuttosto semplice, ma sembra essere piuttosto efficace: selezioneremo alcune password; espanderlo usando sha1 a 160 bit key. con questa chiave crittograferemo, usando l'algoritmo RC4, l'intero binario (tranne lo stub di decrittografia, ovviamente). Manterremo anche gli ultimi 32 bit di sha1 rispetto al binario originale, al fine di controllare la password. Quando qualcuno eseguirà tale binario protetto; lo stub chiederà la password, ne farà un hash e proverà a decrittografare il file binario usando questa chiave. Quindi creeremo un hash di binario potenzialmente decrittografato, lo confronteremo con il valore che abbiamo salvato durante la creazione e, se corrisponde, il binario viene decrittografato correttamente (= password corretta) e lo lasceremo funzionare.

Moderno

La maggior parte dei binari ELF moderni sono protetti usando UPX o una sua variante. ^1,2

• La variante più semplice del packer UPX usato in natura è il packer 'LSD', in cui la stringa "UPX" viene modificato in "LSD". Un esempio di ciò è stato un minatore di monete XMR scritto in Go che prende di mira i sistemi che eseguono Jenkins.

• mumblehard protezione personalizzata - non basata su UPX

  L'intero packer consiste in realtà di circa 200 istruzioni di montaggio. Un'altra osservazione degna di nota: le chiamate di sistema vengono effettuate direttamente utilizzando le istruzioni int 80h . Un altro suggerimento che è stato scritto in assembly è che le funzioni non hanno il solito prologo per gestire lo stack. Facendo chiamate di sistema con interrupt, i binari ELF di Mumblehard evitano qualsiasi dipendenza esterna. Inoltre, il packer funziona sia su sistemi Linux che BSD. ¹

  samples:

  • 20b567084bcc6bd5ac47b2ab450bbe838ec88fc726070eb6e61032753734d233
  • 7d897d08e35207d60e08d08e35121 78c19897d08e35127d60e08d87e07d60e08e08e07d60e15bf08e08e07d60e011
  • 84dfe2ac489ba41dfb25166a983ee2d664022bbcc01058c56a1b1de82f785a43
  • 747d985d4bd302e974474dc9ab44cb1f60cb06206f3639c5d603db94395b877b
  • 9512cd72e901d7df95ddbcdfc42cdb16141ff155e0cb0f8321069212e0cd67a8
  • a5915c3060f5891242514b7899975393ef3d3cb87b33b6a767cffce4feac215f

• una variante di tiny XMR mooner utilizza un packer personalizzato secondo la presentazione di r2con 2018 Unpacking the Non-Unpackable.

  • 8a0d9c84cfb86dd1f8c9acab87738d2cb82106aee0d88396f6fa86265ff252dd

  • md5sum dalla presentazione: 4f1fdacaee8e3c612c9p>

    bbe162042 Il file è stato oggetto del malware cryptominer Linux "Tiny XMR mooner" (la somma sha256 è identica) ma in questa analisi non viene fatta alcuna menzione di impacchettamento o qualsiasi altra forma di protezione binaria.

• Linux/Tsunami con packer personalizzato
  • Malshare sample
  • f22ffc07e0cc907f00fd6a4ecee09fe8411225badb2289c1bffa867a2a3bd863 (Virustotal)
  • una volta era disponibile un'analisi su pwning.fun ma sembra che sia stato rimosso.

Informazioni aggiuntive

Una tassonomia del sé -modifying code for obfuscation (2011) riassume concisamente alcuni di questi strumenti e discute una varietà di tecniche di offuscamento.

Riferimenti

1. Comprensione del malware Linux

2. Modern Linux Malware Exposed

3. Unboxing di Linux / Mumblehard (2015) - ESET