Packer (informatica): differenze tra le versioni
Contenuto cancellato Contenuto aggiunto
m Bot: passaggio degli url da HTTP a HTTPS |
fix /migliorata leggibilità wikitesto |
||
| (6 versioni intermedie di 4 utenti non mostrate) | |||
Riga 1:
Un '''packer''' è uno strumento che permette di rendere difficile l'analisi di un file eseguibile o, semplicemente, di ridurne la
I packer vengono sovente usati nelle versioni limitate di prodotti commerciali per impedire, o perlomeno scoraggiare, la creazione di [[crack (informatica)|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).
== Struttura ==
Un packer, una volta elaborato un file eseguibile, produce un nuovo file eseguibile (comunemente detto "packato") la cui struttura consta di un "loader"
Il loader, una volta eseguito, eseguirà quindi le operazioni necessarie a ripristinare il codice originale e gli cederà il controllo.
== Tecniche usate dai packer ==
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).
Riga 14:
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 21 ⟶ 22:
* salti a porzioni di codice visibilmente fuori dal programma. Questo avviene se il codice del junk code corrisponde ad un'istruzione di salto (condizionato o no).
Il junk code può essere usato anche per altri scopi.
Ad esempio, si consideri questa porzione di codice:
call func1
Riga 34 ⟶ 36:
ret
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
=== Opaque predicates ===
Gli "opaque predicates" sono porzioni di codice che restituiscono un valore [[Booleano (informatica)|booleano]] predeterminato che, per qualche ragione, necessita di essere calcolato a run-time.
Si consideri quest'esempio:
mov eax,1
Riga 49 ⟶ 51:
Questa tecnica, in congiunzione a quella del junk code, può bastare per confondere i disassembler più semplici facendo perdere loro l'allineamento (il disassembler non è in grado di predire quale "ramo" verrà eseguito e quale no).
=== Virtual machine ===
Questa tecnica è sicuramente una delle più difficili da gestire. Consiste nel simulare un microprocessore (con un set di istruzioni personalizzato). Tutti gli [[opcode]]s presenti nel programma dovranno quindi essere decodificati 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).
==
L'[[Entropia (teoria dell'informazione)|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.
Riga 60 ⟶ 62:
== Lista di packer ==
Per eseguibili in formato [[Portable Executable]] (Windows):
{{
* ASPack
* ASPR (ASProtect)
Riga 73 ⟶ 75:
* eXPressor
* Enigma Protector Win32 / Win64
* Enigma Virtual BOX – [[
* MPRESS –
* FSG (Fast Small Good)
* HASP Envelope
* kkrunchy – [[
* MEW – development stopped
* NeoLite
Riga 90 ⟶ 91:
* Privilege Shell
* RLPack
* Sentinel CodeCover (Sentinel Shell)
* Shrinker32
Riga 98:
* Themida
* UniKey Enveloper
* Upack (software) – [[
* [[UPX]] – [[free software]]
* VMProtect
* WWPack
* BoxedApp Packer
* XComp/XPack –
{{
Per
* PackWin
* WinLite
Riga 132:
* XE
Per eseguibili [[Executable and
* gzexe
* HASP Envelope
* [[UPX]]
Per eseguibili [[
* .NETZ
* NsPack
Riga 146:
* [https://web.archive.org/web/20110122015225/http://site.yvansoftware.be/dotpacker1_0 DotProtect]: Commercial protector/packer for.net and mono. Features on-line verifications and "industry standard encryption".
Per eseguibili [[Mach-
* HASP Envelope
* [[UPX]]
Per eseguibili [[Piattaforma Java
* HASP Envelope
* pack200
Per eseguibili
* HASP Envelope
== Collegamenti esterni ==
*{{cita web|http://upx.sourceforge.net/|UPX packer open-source}}
*{{cita web|http://www.aspack.com/|ASProtect packer commerciale}}
| |||