Packer (informatica): differenze tra le versioni

Versione delle 23:20, 26 giu 2010

Versione delle 11:32, 8 ott 2010

Riga 1:

Un '''packer''' è uno strumento che permette di rendere difficile l'analisi di un file eseguibile o, semplicemente, di ridurne la sua dimensione.

I packer vengono solentesovente usati nelle versioni limitate di prodotti commerciali per impedire, o perlomeno scoraggiare, la creazione di [[crack]].

Essi usano delle tecniche anti-debug e anti-disassembly sempre più avanzate che, se non sono interpretate nella maniera giusta dal debugger/disassembler, fanno perdere molto tempo al cracker (o al reverser in generale).

Riga 10:

Le tecniche usate dai packer sono molteplici e, perlomeno quelle più conosciute, vengono rilevate e gestite correttamente dai più comuni disassembler.

In particolare, disassembler come [[IDA pro]] riescono a riconoscere la presenza di un packer e permettono un disassembling selettivo del codice (l'utente decide cosa disassemblare e cosa no).

Le tecniche si possono dividere in 2 macro categorie: tecniche anti-debug e tecniche anti-disassembly (anche se a volte la distinzione non è così netta).

Le tecniche anti-debug sono tecniche volte ad impedire il debug dell'applicativo tentando, ad esempio, di rilevare se un debug è in corso.

Le tecniche anti-disassembly sono tecniche volte a far perdere l'allineamento al disassembler per fare in modo di camuffare le istruzioni macchina derivanti da tale processo di decodifica.

===Junk Code===

Il junk code è una tecnica che consiste nel mischiare dati e codice insieme. Questa tecnica ha lo scopo di far perdere l'allineamento al disassembler, che tenterà di decodificare dei dati (e quindi non delle istruzioni). La tecnica usata dai disassembler più avanzati è quella di considerare "dati" tutto quello che, nel corso del programma, non verrà mai eseguito (anche se spesso non è molto facile determinarlo a priori a causa degli [[packer#Opaque predicates|opaque predicates]]).

Il junk code è facilmente identificabile anche da un essere umano, perché la sua decodifica di solito produce:

* errore, il codice non corrisponde a nessun opcode. In questo caso la presenza di junk code è palese.

Riga 34 ⟶ 35:

In questa porzione di codice viene chiamata la funzione func1 che incrementa l'indirizzo di ritorno di func1 per fare in modo che "DB ..." non venga eseguito.

Nell'analisi di questa porzione di codice con un debugger, è facile accorgersi che lo [[step-over]] della funzione "func1" non ha l'effetto sperato: l'esecuzione continua fino al termine del programma. Questo è dovuto al fatto che i più comuni strumenti di debugging, nell'eseguire lo step-over, impostano un [[breakpoint]] subito dopo la chiamata della funzione. Di conseguenza per un debugger una funzione non è terminata fin quando l'istruction[[instruction pointer]] non punta all'istruzione successiva alla CALL (evento che non accade mai nell'utilizzo di questa tecnica). Di conseguenza, il reverser è costretto a fare lo [[step-into]] di ogni funzione.

===Opaque predicates===

Riga 49 ⟶ 50:

===Virtual machine===

Questa tecnica è sicuramente una delle più difficili da gestire. Consiste nel simulare un microprocessore (con un set di istruzioni personalizzato). Tutti gli opcodes[[opcode]]s presenti nel programma dovranno quindi essere decodificatedecodificati dal processore virtuale e, a loro volta, da quello reale. Come è facile intuire questa tecnica introduce un leggero [[overhead]] (ridotto al minimo utilizzando istruzioni di virtualizzazione, ove presenti).

==[[Entropia (teoria dell'informazione)|Entropia]]==

L'entropia può essere usata per stabilire se è un file ha subito un processo di "packing".

Quest'approccio si basa sul fatto che normalmente i file eseguibili non packati possiedono al loro interno una certa sistematicità delle istruzioni, mentre invece un file packato si presenta comunemente come un insieme di dati casuali.

Alla luce di questo è possibile affermare che più l'entropia di un file si avvicina allo zero, più aumentano le probabilità che il file non sia packato.