The Italian CRaCKiNG Encyclopedia vol. 2
-------------------------------
-------------------------
More about CRaCKiNG
---------------
---------
---
Scritto da
---==: ALoR :==---
---==> Proud member of NEURO ZONE 2 <==---
Maggio 1998
Target = ***, ****
(*=Lamer, **=Novizio, ***=Apprendista, ****=Esperto, *****=CrackMaster)
==============================================================================
Table of context :
1.0 Disclaimer.
2.0 I tools necessari.
3.0 Pensare come un cracker
4.0 La tecnica Jungle
5.0 File Packing/Unpacking
6.0 Il problema degli INT 3 & INT 1
Appendice -A- Usare WDASM (DLLs)
7.0 Conclusioni
==============================================================================
-----------------
1.0 DISCLAIMER
-----------------
Every reference to facts, things or persons (virtual, real or esoteric) are
purely casual and involuntary. Any trademark nominated here is registered or
copyright of their respective owners. The author of this manual does not
assume any responsability on the content or the use of informations retriven
from here; he makes no guarantee of correctness, accuracy, reliability, safety
or performance. This manual is provided "AS IS" without warranty of any kind.
You alone are fully responsible for determining if this page is safe for use
in your environment and for everything you are doing with it!
E' in inglese lo so... ma vi avevo detto di aggionrnarvi nel primo manuale,
o sbaglio.... beh, se non l'avete ancora fatto sbrigatevi... il tempo vola!!!
Ok. e dopo questa menata totalmente inutile, ma che serve a me per pararmi il
culo, possiamo iniziare con il secondo volume.
------------------------
2.0 I TOOLS NECESSARI
------------------------
I tools necessari per crackare li abbiamo gi� visti nel primo volume. Comunque
� meglio ricordarli.
* Un disassemblatore (Es.: WDasm 8.9 or higher)
* Un editor esadecimale (Es.: UltraEdit)
* Un manuale di Assembly
* Un manuale delle API.
In oltre d'ora in poi comincer� a parlare anche di debugger in realtime,
quindi � necessario che iniziate a procurarvi
* Soft-Ice 3.2 or higher (il miglior debugger per win)
Vi consiglio anche di scaricare i vari patch di soft-ice, che servono per
bypassare le protezioni dei programmi che riprogrammano gli INT 3 (poi vi
spiego meglio).
------------------------------
3.0 PENSARE COME UN CRACKER
------------------------------
A volte pu� capitare che patchando la funzione di registrazione ci venga detto
che il programma � registrato, quando per� lo carichiamo il programma risulta
NON registrato. La soluzione � molto semplice, ma richiede che voi pensiate
come un cracker.
I programmatori seguono la logica secondo la quale se una serie di istruzioni
va ripetuta pi� di una volta, si deve creare una funzione, che si richiama
ogni volta che si deve effettuare quel tipo di istruzioni. Molti programmi
checkano il serial # almeno due volte, quando immetti il codice e quando il
programma viene eseguito. Per questo motivo il programmatore crea una
funzione, e la richiama ogni volta che checka il codice.
Se voi patchate la funzione, questa restituir� un codice valido ogni volta che
questa sar� richiamata.
Facciamo un esempio. Fate attenzione alle istruzioni assembly qui riportate.
* Referenced by a (U)nconditional or (C)onditional Jump at Address:
|
|:00440A99(C)
|
* Possible Reference to String Resource ID=00141: "Unregistered"
:00440B3C 688D000000 push 0000008D
:00440B41 8BCF mov ecx, edi
:00440B43 E8CD110600 call 004A1D15
:00440B48 53 push ebx
:00440B49 53 push ebx
* Possible StringData Ref from Data Obj >"Registration unsuccessful". Please
>"verify that you have entered the"
>"information exactly as shown on"
>"your registration letter."
:00440B4A 6800544F00 push 004F5400
:00440B4F 899E78010000 mov dword ptr [esi+00000178], ebx
:00440B55 E8CC940600 call 004AA026
Avrete notato che questa parte di codice � richiamata da un salto condizionata
all'indirizzo 00440A99. Scorrendo in su WDasm troveremo queste istruzioni:
:00440A87 50 push eax
:00440A88 51 push ecx
:00440A89 898678010000 mov dword ptr [esi+00000178], eax
:00440A8F E85CF1FEFF call 0042FBF0
:00440A94 83C408 add esp, 00000008
:00440A97 85C0 test eax, eax
:00440A99 0F849D000000 je 00440B3C
Ora dobbiamo applicare quello che abbiamo imparato prima. Se ci limitiamo a
NOPpare il je 00440B3C o a trasformarlo in jne 00440B3C, il programma ci dir�
di essere stato registrato quando immettete il codice. Quando, per�, fate
ripartire il programma continuer� a dirvi "Unregistered". Vi ricordate la
questione delle funzioni richiamate pi� volte? Questo � quello che l'autore
del programma ha fatto. Andiamo quindi a vedere cosa si trova all'indirizzo
della call 0042FBF0.
* Referenced by a CALL at Addresses:
|:0040443B , :004048B8 , :004057FA , :0042E80E , :0042E886
|:00439F74 , :0043D7CA , :0043E060 , :0043ECDA , :004409F5
|:00440A8F , :0044234C , :00442CDD , :004543F9 , :004545CB
|:004BA403
|
:0042FBF0 64A100000000 mov eax, dword ptr fs:[00000000]
Ognuno di questi indirizzi � una chiamata alla funzione "CodiceValido()" che
controlla se il programma � registrato.
"La domanda sorge spontanea..." (citazio) Come facciamo per patchare la
funzione?
Diamo uno sguardo alla sezione di codice che richiama la funzione ed in
particolar modo all jump verso 00440B3C. Il jump sar� effettuato se EAX = 0.
Cos�, il modo migliore per patcharlo � scrivere 1 nel EAX. Quindi
modificheremo il mov eax, dword ptr fs:[00000000] con [00000001] in modo che
la funzione restituisca sempre 1. In questo modo il programma penser� di
essere registrato.
Questa tecnica pu� essere usata non sono per i programmi con il serial #, ma
anche per altri tipi di protezione (per esempio i controlli sulle date o i nag
screen sono messe in una funzione).
------------------------
4.0 LA TECNICA JUNGLE
------------------------
I programmatori pi� esperti cercano in ogni modo di impedire che i loro
programmi vengano crackati. Per questo inventano numerose tecniche. Una delle
pi� semplici � la tecnica "Jungle". Viene spesso usata, poich� � di facile
realizzazione, e poich� spinge il cracker ad arrendersi. Ma noi abbiamo i
controcoglioni... e non ci arrenderemo... :-)
Questa tecnica, non � mirata ad impedire di crackare il programma, pi� che
altro cerca di far desistere il cracker facendolo impazzire in una "giungla"
(da qui il nome) di call e jump. Praticamente, il programma pu� richiamare
anche 15-16 call in 4-5 DLL differenti (vedi appendice -A-) prima di arrivare
al punto in cui compare la protezione.
L'unico modo per superare questo ostacolo � avere un mucchio di pazienza, un
blocchetto di appunti su cui scrivere i NUMEROSI indirizzi che ci servono e
magari un Martini o un pacchetto di sigarette (se fumate) :-)
-----------------------------
5.0 FILE PACKING/UNPACKING
-----------------------------
Un altro modo per proteggere i programmi � il file packing/crypting.
Esistono vari programmi che compattano i file eseguibili (Pklite, WWpack,
diet, ecc..). Ma possono essere facilmente decompattati per ritornare al
file eseguibile originale. Le versioni commerciali di questi prg. forniscono
la possibilit� di renderli "unextractable", criptando il file. Esistono anche
molti altri prg (non sto qui ad elencarli tutti... sono tantissimi) che
cryptano i file rendendoli inestraibili, oppure indebuggabili.
Vediamo ora come funzionano e che problemi creano al cracker.
Innanzi tutto diamo una rapida occhiata a come sono organizzati i file
eseguibili.
------------------
| HEADER |
|------------------|
| TEXT SEGMENT |
|------------------|
| DATA SEGMENT |
|------------------|
| RELOCATION TABLE |
|------------------|
| SYMBOL TABLE |
|------------------|
| BEGUG CODE |
------------------
Questo � lo schema di come si presenta un file eseguibile appena compilato, e
molto facile da debuggare e decompilare... :-)
Sfortunatamente per noi i packer/crypter rendono le cose pi� complicate.
Per prima cosa un packer elimina la "SYMBOL TABLE" e il "DEBUG CODE" che come
dice il nome � pieno di informazioni utili in fase di debug. Eliminata questa
parte, che non serve per il corretto funzionamento dell'eseguibile, il packer
compatta le stringhe che si trovano nel "TEXT SEGMENT". Infine se si �
selezionata l'opzione per renderli inestraibili, il packer crypta
l'HEADER e/o la RELOCATION TABLE.
Per poter reperire le informazioni cos� compattate e cryptate, il packer
appende parte di codice al programma che deve essere eseguito prima di ogni
altra cosa.
Dopo l'azione del packer il nostro file eseguibile si presenta cos�:
-------------------
| HEADER DEL PACKER |
|-------------------|
| HDR */ BGD/(%D"�$ | <--- Header del prg. cryptato
|-------------------|
| TXT SGM | <--- Text segment compattato
|------------------ |
| DTA SGM / Yf"(^�� | <--- Data segment compattato / cryptato
|------------------ |
| RLCT &"�%$784gUrg | <--- Relocation Table cryptata
------------------
Il nostro file quindi si presenta come un ammasso di byte insignificanti per
qualsiasi debugger. Infatti provando a disassemblare un file di questo tipo,
si otterr� solo un mucchio di codici senza senso.
Vediamo allora come fa il sistema operativo ad interpretare i comandi dell'
eseguibile. Quando lanciamo il programma, viene letto l'HEADER DEL PACKER e
viene richiamata la routine di decrypt. Una volta decryptati i dati in
memoria, la parte di codice del packer passa il controllo ai dati appena
decompattati, ed esegue il vero codice dell'eseguibile.
In oltre alcuni packer inseriscono una parte di codice dedicata alla
rilevazione/inibizione dei debugger.
Fortunatamente essendo algoritmi di crittazzione a due vie (crypt/decrypt),
esistono programmi che decryptano questi file :-), riportandolo al suo stato
naturale.
Per impedire ci� sono stati inventati altri programmi per cryptare
ulteriormente gli header dei prg. Ma anche qui essendo crypt a due vie, c'�
sempre il modo di tornare indietro... basta solo scoprire l'algoritmo... :-)
NON esiste il crypter SICURO !! Se per ora nessuno ha trovato la chiave,
state certi che prima o poi qualcuno la trover� :-)
Ormai io ritengo che questo tipo di protezione serve solamente contro i LAMER
che potrebbero, con un qualsiasi editor esadecimale, editare le stringhe del
TEXT SEGMENT, e cambiare il copyright o simili...
I programmi pi� recenti e pi� BASTARDI, integrano nel codice algoritmi che
rilevano i debugger o che li depistano riprogrammando gli INT (vedi 5.0).
--------------------------------------
6.0 IL PROBLEMA DEGLI INT 3 & INT 1
--------------------------------------
Il problema degli INT 3 riguarda il Tracing con i debugger in realtime.
A volte, quando inizi a crackare, il tuo "instruction pointer" potr� non
seguire un tracing sequenziale, ma sembra seguire un andamento disordinato o,
addirittura, far terminare il programma in modo anomalo.
Questo comportamento � dovuto al codice del programma che si sta analizzando.
Infatti esistono molti modi per impedire che un programma venga tracciato.
Vediamo allora per prima cosa come funziona un debugger. Ed � qui che entrano
in gioco gli INT 3 e INT 1. Questi sono i "breakpoint" e i "single stepping"
interrupts rispettivamente.
Cosa succede quando settiamo un breakpoint? Il debugger legge all'indirizzo
che specificate, un byte e lo mette da qualche parte in memoria. Questo byte
fa parte dell'intera istruzione che si trova a quell'indirizzo. Per esempio:
se l'istruzione a quell'indirizzo � "INT 13", che corrisponde in linguaggio
macchina a CD13h. Il debug legger� il primo byte, CDh, e lo salva in memoria.
Il CDh sar� sostituito con un INT 3 (CCh). Cos� il codice apparir� CC13h. In
questo modo il disassemblato sar� un INT 3 seguito da una parte di istruzione.
Quando la CPU arriva a questo indirizzo, incontra un INT 3 e restituisce il
controllo al debugger. Il debugger sostituir� CCh con il CDh salvato in
precedenza.
Con il "single stepping" accade lo stesso. Il debug inserisce un INT 3 dopo
l'istruzione che sta per eseguire.
Il problema dunque sorge quando in programma usa gli INT 3. Infatti gli int 3
possono essere riprogrammati per richiamare gli INT 21 o qualsiasi altro INT.
E quindi nasce un conflitto tra il programma e il debugger che vuole usare gli
INT 3 per i suoi breakpoint. Ed un "single step" pu� causare un errore di
protezione generale o una terminazione anomala del programma.
Per evitare che la riprogrammazione dia i sui frutti, esistono numerosi patch
per Soft-Ice che impediscono ai programmi di interferire con esso.
-----------------------------------
Appendice -A- USARE WDASM (DLLs)
-----------------------------------
Abbiamo gi� imparato a disassemblare i programmi nel vol. 1. Ora ci occuperemo
delle Librerie Dinamiche (DLL). Infatti molto spesso la tecnica jungle ci
costringe ad addentrarci in numerose dll. Una dll pu� essere disassemblata
esattamente come un file eseguibile. L'unica differenza � che non la si pu�
debuggare singolarmente, ha bisogno di essere appesa al file che la richiama.
Quindi per prima cosa disassembliamo il programma che la richiama.
Lo carichiamo in memoria ^Debug^ Load process (ctrl+L). E dalla finestra dell'
EIP (quella di sinistra) cerchiamo la nostra dll nella lista "Active DLLs".
Doppio-click sulla dll. Et voil�... la dll � disassemblata e pronta per essere
debuggata. Se la dll richiama altre dll, ripetere la procedura.
Nel prossimo volume vedremo cosa sono e come interpretare i riquadri "Regs" e
"Source For Data".
------------------
7.0 CONCLUSIONI
------------------
Eccoci giunti alla fine del secondo volume della "The Italian Cracking
Encyclopedia". E' gi� in cantiere un terzo volume (probabilmente su SoftIce),
quindi... Stay tuned for update !!
In fin dei conti il cracking � un'arte in continua evoluzione...
Per avere eventuali future release di questo manuale scrivete a: [email protected]
oppure visitate il sito http://Alor.home.ml.org
"If you give a man a crack he'll be hungry again
tomorrow, but if you teach him how to crack, he'll
never be hungry again"
+ORC
.-. .-.
/ \ .-. .-. / \
/ \ / \ .-. .-. / \ / \
---/-------\-------/-----\-----/---\---/---\-----/-----\-------/-------\---
/ \ / \ / `-' \ / \ / \
/ \ / `-' `-' \ / \
/ `-' `-' \
Greetings to: LordKasKo (my cracking teacher...)
The other NEURO ZONE 2 members (10t8or, DK2DEnd, LordKasKo,
MaPHas, Ob1, TurboSnail, XXXX)
All the Cracker on the NET from whom I have learned something.
==============================================================================
.________ ._
/ .__ ) / / .________ ._____
/ (___) / / / / .__ ) / ._ ) ..: . . . .
/ .___ / / / / / ) / / / /_/ .. : : . .
/ / / / / /____ / /___/ / / / :: .:: . . . .
(__/ (__/ (________)(_________/ (__/ .:. : . : . . .
--==> ALoR <==---------------------- - - -
ICQ: 10666678 In IRC: WhiteFly
e-mail: [email protected] www: http://ALoR.home.ml.org/
==============================================================================