Wasting Crypto – Il tallone d’Achille

Nota per il lettore: questo post è stato recuperato da un backup polveroso ed è una traccia di un “me” di svariati anni fa…

Oggi diamo un’occhiata ad un programmino che ho avuto sottomano qualche giorno fa.

All’avvio chiede un seriale di registrazione. Male. Proviamo a lasciarlo in bianco: nulla. La finestra resta lì imperterrita. Dopo tre tentativi in bianco o errati, il programma termina senza nessun messaggio d’errore e senza neanche mostrare la finestra principale. E questo significa una sola cosa: trovare il punto del test è un’impresa quasi impossibile.

Forse è il caso di cercare di capire meglio come funziona il programma: passiamo a PEiD l’exe, quindi cerchiamo eventuali algoritmi crittografici codificati all’interno dell’applicazione.

Ecco che risultato sforna Kanal dopo 3,7s:

Confesso che mi spaventa un po’. Blowfish, DES, LockBox, MD5, Base64, Rijndael, SHA1… pur ammettendo una buona percentuale di falsi positivi, le potenzialità crittografiche di questo software restano molto molto elevate.

Niente seriale.

Tentiamo un approccio diverso: il programma controlla se è registrato PRIMA di caricare la finestra che chiede il codice, quindi dovrà pur caricare da qualche parte la stringa che identifica il nome di questa finestra. Quello sarà il ramo “negativo” dell’if “sono registrato?”.

Sulla scorta di questa supposizione, disassembliamo il programma e cerchiamo il titolo della form. Atterriamo qui:

0040DA63 mov eax, offset aRegistrazioneN ; "REGISTRAZIONE NON VALIDA ("

e risaliamo la corrente. Ecco il jump che referenzia la routine in cui ci troviamo:

0040DA2B loc_40DA2B: ; CODE XREF: sub_40D960+C1 j

Il jump è questo: 0040DA21 jnz short loc_40DA2B. Possiamo astrarre pensando che sia la chiamata a procedura MostraFormRegistrazione().

Subito sopra ci troviamo un bel 0040DA1E cmp edx, 3: ecco come fa il programma a permettere un massimo di tre tentativi. Un compare tra un registro caricato adeguatamente e il numero 3, il jump if not zero interrompe il ciclo, un inc edx piazzato più su completa l’opera. Ma non è ciò che ci interessa, infatti non è qui che viene effettuato il test rispetto a se registrare o no il programma.

Siamo però nel posto giusto. Poco più su troviamo l’unico altro test in tutta la subroutine corrente (piuttosto breve, comunque). Eccolo qui:

0040DA07 test cl, cl
0040DA09 jz loc_40DC5C

Basta uno sguardo per capire che ci siamo. Cambiamo il JZ in JMP in modo da assicurarci che il salto venga sempre eseguito e proviamo a lanciare il programma.

Neanche a dirsi funziona da registrato e non mostra neanche più l’odiosa form di richiesta del codice.

Traiamo qualche conclusione da questa indagine. Innanzitutto ci tengo a precisare che questo software mi è stato dato a titolo di test proprio per verificarne la sicurezza ed è per questo che non ne rivelo il nome (vi assicuro che non ne ricavereste granché comunque). La lezione è che non bisogna affidarsi stupidamente a sistemi crittografici complessi per realizzare codici seriali a prova di keygen per poi lasciare che il controllo si concentri in un solo punto. Sarebbe necessario come minimo verificare la correttezza della registrazione in più punti, magari a scadenza regolari con un evento timerizzato. Altrettanto opportuno sarebbe stato crittare/offuscare/comprimere il compilato con programmi quali ExeShield o ASProtect, in modo da rendere più difficile l’analisi del programma in questione (o almeno di nascondere con un velo pietoso la semplicità del controllo…).

Evitate spifferi del genere nelle vostre applicazioni!