Zoom Icon

Soluzione guelter2

From UIC Archive

Guelter2 Crackme Contest 2011

Contents


Soluzione guelter2
Author: Walter1945
Email: [email protected]ibero.it
Website: -
Date: 28/09/2011 (dd/mm/yyyy)
Level: Major skills are required
Language: Italian Flag Italian.gif
Comments: medio



Introduzione

Risolviamo il crackme guelter2 [Crackme Contest 2011]



Tools & Files

  • hexeditor
  • Ollydbg
  • ImpREC 1.7c



URL o FTP del programma

  • CM99 alias Guelter 2


Essay

Iniziamo con un dump

Apriamo il programma con Olly e vediamo cosa contiene:

1Immagine1.JPG


Dalla prima schermata si intuisce che il file è packed, allora come al solito lasciamogli eseguire tutta la routine fino ad arrivare qui:

1Immagine2.JPG


Facciamo uno STEP e dovremmo essere arrivati a quello che sembra l’EntryPoint:

Immagine3.JPG


Beh, ora proviamo a fare un dump, lo sistemiamo con ImpREC, lo avviamo e… non funziona per niente, ci deve essere sfuggito qualcosa, allora ricarichiamo il programma in Olly, andiamo avanti ad analizzare e ci accorgiamo che il programma crea un processo e subito dopo si mette a lavorare di WriteProcessMemory, allora riavviamo, settiamo un “bp CreateProcessA”, cerchiamo il programma in memoria (basta anche solo cercare “MZ”) e al secondo risultato lo troviamo:

Immagine5.JPG


capiamo che è questo il programma dal nome delle sezioni

Immagine4.JPG


Dumpiamo tutta la sezione, poi la editiamo con l’hexeditor cancellando la parte sovrastante “MZ”, la salviamo (è completamente funzionante), la carichiamo in Olly e ci troviamo in una situazione simile a quella iniziale, eseguiamo tutta la routine fino a” jmp 004011FC”, eseguiamo uno STEP e finalmente ci troviamo all’EntryPoint corretto, dumpiamo e sistemiamo con ImpREC, avviamolo e proviamo a premere su “Verify”, azz.. il crackme crasha, vediamo di capire il perche caricandolo in Olly, uhm qui il crackme funziona perfettamente, da qui si intuisce che il crackme se è debuggato esegue o meno certe operazioni, infatti se lo si analizza con “VB Decompiler Lite” si nota qualcosa di utile:

Immagine7.JPG

Troviamo la routine della nag screen

Avviamo il programma,cerchiamo la frase “This is the nag screen you have to kill”, la troviamo all’indirizzo 00402904, mettiamo un bph on access,e vediamo dove la utilizza,avviamo ancora il crackme clicchiamo su “Verify” e Olly si ferma, facciamo un po’ di ALT+F9 e ci troviamo qui:

Immagine6.JPG


Questa è la routine che ci interessa. Quindi ora settiamo un “bp CheckRemoteDebuggerPresent” , steppiamo fino al RETURN e vediamo che la nostra funzione ritorna un valore 1 o 0 in base che sia sotto debugger o meno, basta noppare dove carica il risultato e procediamo.

Immagine8.JPG


Ora mettiamo un “bp 00402BD0” (che è dove inizia la routine di prima), clicchiamo su “Verify” e vediamo dei cambiamenti,

Immagine9.JPG


Questo significa che qualcosa ha modificato le CALL ma le ha modificate male,prima abbiamo visto che tra le API utilizzate c’era “WriteProcessMemory”, settiamo quindi un bp se di essa, avviamo,dopo che Olly si è fermato facciamo un ALT+F9 e ci troviamo in questa routine che fa esattamente quello che avevamo pensato:

Immagine10.JPG


(come vedete va a riscrivere tutte le istruzioni per la nag screen)

Rimuoviamo la protezione

Quindi modifichiamo quello che ci interessa:

Immagine11.JPG


(ho cambiato gli indirizzi con 00404C29, voi potete fare diversamente)

Ora che non annulla più le nostre modifiche torniamo alla routine della nag screen e togliamo la Call che la genera:

Immagine12.JPG

Salviamo tutto, proviamo ad aprirlo normalmente e...

Immagine13.JPG


Perfetto funziona.



Note Finali

Ringrazio Predator per il bel crackme e tutta la UIC.



Disclaimer

I documenti qui pubblicati sono da considerarsi pubblici e liberamente distribuibili, a patto che se ne citi la fonte di provenienza. Tutti i documenti presenti su queste pagine sono stati scritti esclusivamente a scopo di ricerca, nessuna di queste analisi è stata fatta per fini commerciali, o dietro alcun tipo di compenso. I documenti pubblicati presentano delle analisi puramente teoriche della struttura di un programma, in nessun caso il software è stato realmente disassemblato o modificato; ogni corrispondenza presente tra i documenti pubblicati e le istruzioni del software oggetto dell'analisi, è da ritenersi puramente casuale. Tutti i documenti vengono inviati in forma anonima ed automaticamente pubblicati, i diritti di tali opere appartengono esclusivamente al firmatario del documento (se presente), in nessun caso il gestore di questo sito, o del server su cui risiede, può essere ritenuto responsabile dei contenuti qui presenti, oltretutto il gestore del sito non è in grado di risalire all'identità del mittente dei documenti. Tutti i documenti ed i file di questo sito non presentano alcun tipo di garanzia, pertanto ne è sconsigliata a tutti la lettura o l'esecuzione, lo staff non si assume alcuna responsabilità per quanto riguarda l'uso improprio di tali documenti e/o file, è doveroso aggiungere che ogni riferimento a fatti cose o persone è da considerarsi PURAMENTE casuale. Tutti coloro che potrebbero ritenersi moralmente offesi dai contenuti di queste pagine, sono tenuti ad uscire immediatamente da questo sito.

Vogliamo inoltre ricordare che il Reverse Engineering è uno strumento tecnologico di grande potenza ed importanza, senza di esso non sarebbe possibile creare antivirus, scoprire funzioni malevole e non dichiarate all'interno di un programma di pubblico utilizzo. Non sarebbe possibile scoprire, in assenza di un sistema sicuro per il controllo dell'integrità, se il "tal" programma è realmente quello che l'utente ha scelto di installare ed eseguire, né sarebbe possibile continuare lo sviluppo di quei programmi (o l'utilizzo di quelle periferiche) ritenuti obsoleti e non più supportati dalle fonti ufficiali.