Bpx detection, un primo approccio.

Con crackme esplicativo

Written by Evilcry.

Quest' oggi con la scusa di un crackme (Bpxchk), volglio dirvi qualche parola sul bpx detection.

-SoftICE (se proprio volete un approccio live)

www.google.it

Semplice crackme creato (non da me) allo scopo di illustrare i controlli bpx che potrebbero capitarvi.

Negli ultimi tempi, ho notato, che le software-house stanno mettendo appunto schemi di protezione che mirano ad attaccare il debugger. Nel senso che invece di creare algoritmi moolto difficili, si stanno concentrando sulle tecnicke Anti-debugging, per evitare che il nostro caro Sice, possa sventrare i loro "Pargoli" :). Le tecniche usate sono parecchie e di vario tipo, a tal proposito vi consiglio di dare uno sguardo al file "code.txt" presente nel FrogSice. Tra le protezioni più in voga troviamo il "MeltICE", che controlla la presenza del nostri dbg in memoria. Come riconoscerlo???, se andate ad analizzare le "String references", di due xref a "///SICE" e a "///NSICE", che sono abbinate ad una chiamate verso CreatefileA, dopo questa call sicuramente ci saranno dei salti condizionati (sapete cosa fare vero :-D). Un altro Trick anche se un pò vecchiotto, è quello delle chiamate a int 3 e int 68. Nella peggiore delle ipotesi troverete manomissioni della IDT, ed utilizzo massiccio dei registri DRx e del TR (Trap flag). Ora passiamo alle routine di checking dei bpx. Dovete sapere che quando inseriamo un BPX at Address, Sice sostituisce i bytes relativi all' indirizzo che abbiamo messo, con l' opcode 0xCC, che corrisponde ad un int 3. Infatti se dumpiamo un programma (con Icedump) nel quale c' è esempio un bpx 00401000, noteremo all' Offset corrispondente,un int 3 . Il funzionamento dei trick anti-BPX è molto semplice, di solito si inserisce una routine che controlla la presenza dei byte 0xCC, in un determinato Address-Range. Questa tecnica però, non è molto funzionale, pensate cosa succederebbe se ci trovassimo difronte a casi del genere:

mov eax,cch

xor ebx,cch

Come potete immaginare i casini sono immani :-D. Andiamo adesso a vedere un esempio concreto di ciò che vi ho detto, analizzando un crackme fatto da TSCube (tnx TSCube :)). Il crackme è molto semplice da capire, quindi vado direttamente alla routine di checking.

004011EB push 004040F4

Possible StringData Ref from Data Obj ->"Start of BPX detection"

004011F0 push 004040DC

004011F5 push ebx

004011F6 call esi ;Call a messagebox

004011F8 mov [ebp+08], 00000000

004011FF mov edi, 00401250 ;Dalla locazione 00401250

00401204 mov ecx, 004012F5 ;Alla locazione 004012f5

00401209 sub ecx, edi ;In ecx il numero di bytes del range EDI-ECX

0040120B mov al, CC ;Mette in AL l' opcode corispondente all' int 3

Referenced by a (U)nconditional or (C)onditional Jump at Address:

0040120D repnz ;Numero di bytes da controllare, (contenuto in ECX)

0040120E scasb ;Controlla se uguale all' opcode CC

0040120F jne 0040121D ;Se ne ha trovato qualcuno va alla Beggar Off

In fine colgo l' occasione per salutare chi mi conosce.

Vorrei ricordare che il software va comprato e non rubato, dovete registrare il vostro prodotto dopo il periodo di valutazione. Non mi ritengo responsabile per eventuali danni causati al vostro computer determinati dall'uso improprio di questo tutorial. Questo documento è stato scritto per invogliare il consumatore a registrare legalmente i propri programmi, e non a fargli fare uso dei tantissimi file crack presenti in rete, infatti tale documento aiuta a comprendere lo sforzo immane che ogni singolo programmatore ha dovuto portare avanti per fornire ai rispettivi consumatori i migliori prodotti possibili.

Noi reversiamo al solo scopo informativo e di miglioramento del linguaggio Assembly .

Capitoooooooo????? Bhè credo di si ;))))