Software protetto da dongle di reverse engineering
Ero giovane, Internet è appena iniziato e abbiamo potuto ottenere tonnellate di software gratuitamente. Era gratis perché qualcuno là fuori era” gentile ” abbastanza per rompere/patch il .exe.
Ho messo “kind” tra virgolette, perché questa era la vista che avevo quando ero un bambino. Ora sono un ingegnere del software e so quanto sforzo ci vuole per costruire software. Quindi, per favore, non scaricare software incrinato. Sostenere lo sviluppatore e acquistare una licenza!
Applicando una tale crepa, patchando l’exe, ho sempre voluto sapere come fare una cosa del genere. Si scopre che è necessario capire assembler, un linguaggio macchina che solo la CPU capisce (e alcuni altri nerd là fuori). Poiché era troppo difficile, non ho mai avuto modo di impararlo. Fino a poco tempo fa (come 20 anni dopo😊).
Un anno fa, ho comprato un software (con una licenza!) che ha bisogno di un dongle USB per funzionare. È davvero ingombrante avere quel dongle con te in ogni momento. Soprattutto quando sei in viaggio. Così ho cercato modi per aggirarlo. La prima cosa che mi sono imbattuto è stato questo emulatore chiave chiamato MultiKey. Scarica la memoria del dongle al registro di sistema e quindi emula il dongle leggendo dal registro di sistema. Ha funzionato BENE, fino a quando non ho voluto eseguirlo su Windows 10. Apparentemente, Microsoft non è un grande fan di MultiKey. In realtà non è un grande fan dei driver non firmati e MultiKey utilizza un driver non firmato. Quindi avevo bisogno di un’altra soluzione. È ora di tuffarsi in quella cosa chiamata codice assembly!
Ho sempre saputo che c’era uno strumento là fuori per il reverse engineering, chiamato IDA. E ‘ in grado di decompilare il vostro .file exe e mostrare cosa sta succedendo. Sfortunatamente, l’interfaccia è davvero difficile da capire. Sapevo anche di Oydbg. E ‘ un debugger. Un debugger consente di passare attraverso il codice assembler mentre il programma è in esecuzione! Significato, ad esempio, se si desidera eseguire il debug dell’applicazione calcolatrice, si potrebbe effettivamente vederlo gestire una pressione di un pulsante, facendo il calcolo e mostrando il risultato sullo schermo. L’inferno, si può anche pauze e cambiare la sua memoria rendendo la calcolatrice ritorno 5 quando si chiede che cosa 2 + 2 è!
Ma non sono qui per cambiare il calcolo (anche se sarebbe bello). Voglio essere libero del dongle. Così ho aperto la mia app con Oydbg.
È stato davvero travolgente. Non avevo idea di cosa significassero tutti questi codici. Figuriamoci sapere da dove cominciare. Così sono tornato al tavolo da disegno. Si scopre che c’è qualcosa chiamato RetDec, un decompilatore che cerca di rendere il codice C fuori dal codice macchina. Mi ci è voluto un po ‘ di tempo per configurarlo ed eseguire la decompilazione, ma lo sforzo pagato. Il risultato è stato un enorme .file c, oltre 2 milioni di righe di codice con codice semi-leggibile.
Infatti ho potuto trovare il codice leggendo i byte del dongle abbastanza facile:
Con queste informazioni, sono tornato al mio debugger. Nel frattempo, ho scoperto che Oydbg è davvero vecchio (dall’anno 2000) e non è stato aggiornato dal 2013. Così ho trovato questo nuovo debugger migliorato, chiamato x64dbg. È open source e ha una grande comunità di sviluppatori che ci lavorano.
Lettura del linguaggio macchina
Nel linguaggio macchina ogni istruzione ha un indirizzo di memoria. Quindi, con gli indirizzi trovati nel codice RetDec, mi sono rivolto a x64dbg ed ecco, il codice che legge il dongle:
Nel codice assembly, gli argomenti della funzione vengono caricati in memoria utilizzando lo stack pointer esp. Nel nostro codice, questo accade poco prima della chiamata alla funzione. (le 3 istruzioni mov indicano che la chiamata richiede 3 argomenti). Dopo la chiamata, il nostro puntatore dello stack viene resettato e viene eseguito un controllo (test) se la chiamata alla funzione ha avuto successo. In caso contrario, vediamo il codice fare un salto (jne). Questo salto punta a un pezzo di codice che indica che il dongle non è presente.
Come puoi vedere, c’è una chiamata a una funzione specifica per leggere il dongle. Ho cercato la guida di riferimento per scoprire cosa fa questa funzione:
La funzione legge un 2 byte di memoria (una parola) dal dongle. Come indovinato, la funzione prende 3 argomenti in cui l’ultimo argomento è un puntatore a 2 byte che conterrà alcuni dati dal dongle.
Nel codice assembly, gli argomenti vengono caricati in ordine inverso. Passando l’ultimo argomento è questo:
L’ultimo argomento punta a esi, il che significa che i dati del dongle verranno archiviati all’indirizzo di memoria a cui esi punta.
Infatti, quando la sospensione solo dopo la chiamata è stata fatta, si può vedere il risultato in memoria:
0x74. Questo è ciò che viene letto dal dongle e memorizzato nella memoria del programma principale.
Per saltare questa chiamata, ho solo bisogno di scrivere 0x74 in memoria dove sta puntando esi. Questo è semplice come sostituire le 7 linee sopra con:
Come puoi vedere, ho anche cancellato il resto delle istruzioni dell’assemblatore, incluso il test se la chiamata alla funzione era valida. Ciò significa che il salto non verrà preso e il programma continuerà a funzionare senza il controllo.
Dopo aver patchato tutte le chiamate che coinvolgono il dongle, ho salvato il nuovo .exe. Ho tirato fuori il dongle, ho eseguito la mia abitudine .exe e con mio grande stupore ha funzionato! Avevo rotto con successo un pezzo di software.
Un’altra cosa che ho attraversato della mia lista di bucket –
Ps: la maggior parte delle cose erano offuscate, come 0x74 e il nome dell’app. Questo non è quello di danneggiare gli sviluppatori che hanno creato questo software duro lavoro in alcun modo. Inoltre sono stato molto fortunato che il dongle ha restituito solo byte e non ha eseguito alcuna crittografia da solo.