l'idea di questo articoletto mi è nata da qualche post letto da predator mimmuz e lethalman.. cosi rispolverando a fondo antiche conoscenze di reversing ho messo su questo scritto..

non me ne frega nulla dei problemi legali della questione per cui arrivo al punto direttamente.. cosa vi serve per crackare un programma?.. la prima cosa che bisogna fare è capire di cosa si tratta.. con che linguaggio è stato scritto quale protezione è stata applicata e i cambiamenti che avvengono nel sistema quando questo viene installato.. tutte queste cose possono essere scoperte con dei tools appositi che ogni cracker sicuramente ha.. cominciamo dagli scanner.. difficilmente un semplice utente sapra cosa è uno scanner binario.. solitamente con la parola scanner si intende un tool di rete.. ma questo invece serve a capire con che linguaggio è stato scritto un dato programma.. solitamente basterebbe un semplice editor esadecimale ma non tutti hanno l'esperienza necessaria.. cominciamo a capire come lavorano i compilatori.. allora.. i compilatori solitamente marcano con delle sequenze di caratteri delle precise locazioni poste all'inizio del programma.. ad esempio il compressore UPX crea 2 sezioni ben distinguibili chiamate UPX0 ed UPX1 riconoscibili nell'header del programma.. ma se nn riusciamo a riconoscerle in tempi brevi ci aiutano dei tools che fanno una scansione binariarilevando il linguaggio e/o il compressore utilizzato.. secondo me il migliore e facile è GetTyp oppure sotto DOS WComp.. entrambi riescono a farci capire cosa abbiamo di fronte.. perchè è importante sapere ste cose? prima di tutto perchè esistono linguaggi come clipper o VB3 o ancora Java e i nuovi .NET che nn producono programmi compilati ma del bytecode.. quindi qualcosa che si presta ad essere decompilato ed in grado di fornire “cose buone dal code” per un cracker o addirittura il sorgente dell'applicazione in alcuni casi.. un programma come Rescue per clipper o Jad per java sono in grado di darci otime soddisfazioni rendendo vano qualsiasi algoritmo messo a protezione del codice.. nello stesso modo il delphy puo essere letto con DeDe o Mripper che probabilmente nn vi riportera al sorgente ma sicuramente alla struttura dell'applicazione.. il processo di cracking si complica appena se il programma è stato compresso.. questo vuol dire che il programma presente nel sistema non è direttamente il codice da eseguire ma un insieme di dati che devono essere prima decompressi e poi eseguiti.. per cui il numero di passaggi per crackarlo è leggermente maggiore.. per cui ci serve un programma di decompressione in grado di fornire un eseguibile adatto ad essere usato da un disassembler o un debugger.. nel caso non avessimo un compressore specifico esistono validissime alternative fra i generici.. ProcDump è in grado di riportare un eseguibile simile all'originale.. solitamente questa tecnica funziona ma esistono casi in cui si possono avere dei problemi.. se il compressore non è noto o se è una derivazione di altri come cloni di upx che viene rilasciato in codice sorgente.. qualunque programmatore potrebbe mettere mano a tale codice creandosi una sua versione del compressore..il programmatore potrebbe benissimo partire da un prodotto del genere ed aggiungere alla routine di compressione una sucessiva codifica in modo da ottenere qualcosa di “non noto” che difficilmente un decompressore o uno scanner standard saranno in grado di rilevare.. ma questo nn è detto che sia a prova di decompressore generico.. per questo è sempre bene verificare se durante la fase di decompressione dell'eseguibile è attivo in memoria uno dei maggioridecompressori genericidato che nn è che ne esistano poi tantissimi.. un altro intervento che puo rendere la vita difficile ad un cracker è l'aggiunta di un controllo sul CRC del programma in modo da bloccare o modificare l'esecuzione quando questo valore non collima col reale valore dell'applicazione o ancora l'utilizzo di risorse non standard accodate al programma in modo binario magari con un semplice “copy /b”.. un altra cosa da considerare è poi l'uso di protezioni basate sul programma di installazione.. alcuni tra i piu noti installer sono in grado di installare il programma completo o una demo secondo la password immessa al setup.. questa protezione è il sogno di ogni cracker.. piu l'installatore è famoso e piu sono presenti in rete decompilatori/decompressori in grado di estrarre tutti i dati contenuti e permettere in ogni caso l'installazione..prendete ad esempio E_Wise il decompilatore di Wise o I5comp il decompressore di install Shield vi permetteranno cose carine sul programma .. stesso discorso per le protezioni da CDROM come SafeDisc o SecurROM o ancora LaserLock.. pressoche inutili.. esistono tools come Daemon Tools in grado di eseguire una iso di cdrom originali emulandone totalmente la protezione software rendendola cosi inefficace.. la cosa da fare dopo questo è monitorare.. analizzare cosa fa il programma durante l'installazione.. come è logico da nessuna parte queste informazioni vengono fornite all'utente per cui sta a noi scoprirle.. come?.. esistono dei monitor adatti allo scopo.. FileMon e RegMon sono i piu famosi ed utilizzati e svolgono ottimamente lo scopo.. ma è meglio smunirsi anche di prodotti come Ethereal dato che molti programmi vengono validati tramite internet.. allora.. questo trio di programmi ci permette di capire cosa succede nel sistema quando un programma viene installato.. ma il problema sta nella notorietà di questo trio.. alcuni programmatori infatti conoscendo le potenzialita di questi programmi si sono fatti furbi e chiudono automaticamente i processi di RegMon o FileMon in modo da rendere il lavoro piu complicato.. o piu interessante .. anche nel casi si debba validare tramite internet stanno tendendo ad utilizzare comunicazioni criptate in modo che non vi sia possibilità di leggere i dati inviati..ma una volta identificato analizzato e decompresso il nostro programma ha bisogno di essere preso e dato in pasto ad un debugger per seguire passo passo l'applicazione all'interno dell'assembler permettendo l'analisi di qualsiasi algoritmo venga utilizzato.. ne esistono molti di debugger in circolazione.. SoftIce che è stata la fortuna di NuMega e Wdasm.. che nn mi piacciono molto.. ma ci sta anche OllyDbg che secondo me è il migliore in questo momento sulla scena cracker mondiale.. perchè ho scelto questo?.. per il semplice fatto che Wdasm dicono sia un debugger ma sembra piu un disassembler.. mentre SoftIce funziona bene solo coi driver .. direi che è il migliore per quello scopo ma OllyDbg è stato creato per gli eseguibili e viene collocato a pieno merito tra i tools di attacco.. è in grado di disassemblare il codice mentre lo si modifica di riportare le modifiche applicate alla memoria direttamente nell'eseguibile che le ha generate e di mantenere traccia delle versioni sucessive che si stanno realizzando.. di interpretare i parametri nello stack e farci vedere le chiamate alle maggiori funzioni di sistema.. questo ovviamente è solo una breve anticipazione a quello che fa questo programma le altre le scoprirete usandolo.. ovviamente dovrete avere pazienza col debugger dato che nn state trattando del sorgente ma del codice compilato ed ottimizzato per un certo processore.. ma vediamo altri tools che ci danno una vera mano durante un cracking.. un disassembler/hex editor.. ci offre la possibilita di un attacco indiretto al codice.. è comodo quando nn si vuole solo capire come funziona una parte del programma ma si vuole avere una visione totale dello stesso.. serve per la analisi del codice o quando si vuole decompilare un file.. che anche se nn è un eseguibile viene utilizzato da un altro programma.. per questo un programma come Hiew funziona ottimamente.. io utilizzo ancora la versione freeware dato che alcuni anni fa ha avuto la malaugurata udea di divenire un shareware o altrimenti potreste passare a Biew che funziona benissimo o il famosissimo Wdasm che purtroppo anche lui è commerciale anche se molti cracker ne hanno migliorato le caratteristiche aggiungendo modifiche e migliorandone l'eseguibile.. per fortuna nn esistono delle vere difese per questo tipo di tools.. dato che sono solamente strumenti di analisi di file exe o binari.. l'unica difesa potrebbe essere quella di scrivere o leggere i dati in forma criptata o compressa in modo da nn rendere direttamente usabile un file presente nel sistema.. ma un cracker nn viene fregato ne tantomeno fermato da questo.. e quando nn riesce a decomplimere un file con un tool standard inizia ad utilizzare dei tools che permettono di seguire passo passo il programma da crackare e scrivere su disco l'immagine della memoria che era in esecuzione in un dato momento.. uno di questi tools è ProcDump ma ci sta anche LordPe e CodeSnippet.. vi consiglio quest'ultimo che consente anche di aggiungere nuove “import Function” ad un eseguibile.. indispensabile quando dovete fare del code injection.... ma un grosso consiglio è di andarvi a guardare siti come SAC e Protools ma per prima cosa scaricatevi un manuale in assembler e tenetelo a portata di mano.. vi tornera sempre utile.. detto questo penso di avere concluso.. spero che queste info possano servirvi

lordream

Copyright © by Raulken.it All Right Reserved.

Pubblicato su: 2004-07-26 (13183 letture)