• Articles
• admin

eram tânăr, internetul tocmai a început și am putea obține tone de software gratuit. A fost gratuit pentru că cineva acolo a fost „un fel” suficient pentru a sparge/patch-uri .fișier exe.

am pus „bun” între ghilimele, pentru că acesta a fost punctul de vedere pe care l-am avut când eram copil. Acum sunt inginer software și știu cât de mult efort este nevoie pentru a construi software. Deci, vă rog, nu descărcați software-ul de cracare. Sprijiniți dezvoltatorul și cumpărați o licență!

aplicând o astfel de fisură, patching exe, am vrut întotdeauna să știu cum să fac un astfel de lucru. Se pare că trebuie să înțelegeți assembler, un limbaj de mașină pe care doar procesorul dvs. îl înțelege (și alți tocilari de acolo). Deoarece a fost prea dificil, nu am ajuns niciodată să-l învăț. Până de curând (cum ar fi 20 de ani mai târziu, în secolul al XIX-lea).

acum un an, am cumpărat software (cu licență!) care are nevoie de un dongle USB pentru a funcționa. Este foarte greoi să ai acel dongle cu tine în orice moment. Mai ales când ești pe drum. Așa că am căutat căi în jurul ei. Primul lucru pe care l-am întâlnit a fost acest emulator cheie numit MultiKey. Se aruncă memoria dongle-ul la registru și apoi emulează dongle-ul prin citirea din registru. Asta a funcționat bine, până când am vrut să o rulez pe Windows 10. Aparent, Microsoft nu este un mare fan al MultiKey. În realitate, nu este un mare fan al driverelor nesemnate, iar MultiKey folosește un driver nesemnat. Aveam nevoie de o altă soluție. E timpul să te scufunzi în chestia aia numită codul de asamblare!

întotdeauna am știut că există un instrument acolo pentru inginerie inversă, numit IDA. Este capabil de a decompila dumneavoastră .exe fișier și arată ce se întâmplă. Din păcate, interfața este foarte greu de înțeles. Știam și despre OllyDbg. Este un depanator. Un depanator vă permite să treceți prin codul de asamblare în timp ce programul rulează! Adică, de exemplu, dacă ați depana aplicația calculator, ați putea vedea de fapt că manipulează o apăsare de buton, făcând calculul și afișând rezultatul pe ecran. La naiba, puteți chiar pauze și schimba memoria făcând calculatorul să se întoarcă 5 atunci când întrebați ce este 2 + 2!

dar nu sunt aici pentru a schimba calculul (deși ar fi cool). Vreau să fiu liber de dongle. Așa că am deschis aplicația mea cu OllyDbg.

a fost cu adevărat copleșitor. Nu știam ce înseamnă toate aceste coduri. Să nu mai vorbim de unde să începem. Așa că m-am întors la planșa de desen. Se pare că există ceva numit RetDec, un decompiler care încearcă să facă codul C din codul mașinii. Mi-a luat ceva timp să-l înființeze și a alerga decompilarea, dar efortul plătit de. Rezultatul a fost un imens .fișier c, peste 2 milioane de linii de cod cu cod semi-lizibil.

de fapt, am putut găsi codul de lectură octeți de dongle destul de ușor:

cu aceste informații, m-am întors la depanatorul meu. Între timp, am aflat că OllyDbg este într-adevăr vechi (din anul 2000) și nu a fost actualizat din 2013. Așa că am găsit acest depanator nou, îmbunătățit, numit x64dbg. Este open source și are o comunitate mare de dezvoltatori care lucrează la el.

citirea limbajului mașinii

în limbajul mașinii, fiecare instrucțiune are o adresă de memorie. Deci, cu adresele găsite în codul RetDec, m-am întors la x64dbg și iată, codul care citește dongle-ul:

în codul de asamblare, argumentele funcției sunt încărcate în memorie folosind indicatorul stivă esp. În codul nostru, acest lucru se întâmplă chiar înainte de apelul la funcție. (cele 3 instrucțiuni mov indică apelul ia 3 argumente). După apel, indicatorul nostru de stivă este resetat și se face o verificare (test) dacă apelul către funcție a avut succes. Dacă nu, vedem codul făcând un salt (jne). Acest salt indică o bucată de cod care indică faptul că dongle-ul nu este prezent.

după cum puteți vedea, există un apel la o funcție specifică pentru a citi dongle. M-am uitat în sus ghidul de referință pentru a afla ce face această funcție:

funcția citește 2 octeți de memorie (un cuvânt) din dongle. După cum s-a ghicit, funcția are 3 argumente în care ultimul argument este un pointer la 2 octeți care vor conține unele date din dongle.

în codul de asamblare, argumentele sunt încărcate în ordine inversă. Trecerea în ultimul argument este aceasta:

ultimul argument indică esi, ceea ce înseamnă că datele din dongle vor fi stocate la adresa de memorie pe care esi o indică.

într-adevăr, când ne oprim imediat după efectuarea apelului, putem vedea rezultatul în memorie:

0x74. Asta este ceea ce este citit din dongle și stocat în memoria programului principal.

pentru a sări peste acest apel, trebuie doar să scriu 0x74 în memoria unde indică esi. Acest lucru este la fel de simplu ca înlocuirea celor 7 linii de mai sus cu:

după cum puteți vedea, am nop-ed și restul instrucțiunilor de asamblare, inclusiv testul dacă apelul la funcție a fost valid. Aceasta înseamnă că saltul nu va fi luat și programul va continua să funcționeze fără verificare.

După Patch-uri toate apelurile care implică dongle, am salvat noi .exe. Am scos dongle-ul, mi-am verificat obiceiul .exe și spre uimirea mea a funcționat! Am spart cu succes o bucată de software.

un alt lucru pe care îl traversez din lista mea de găleți

Ps: majoritatea lucrurilor au fost ascunse, cum ar fi 0x74 și numele aplicației. Acest lucru nu este de a dăuna dezvoltatorii greu de lucru care au creat acest software în nici un fel. De asemenea, am fost foarte norocos că dongle-ul a returnat doar octeți și nu a făcut nicio criptare pe cont propriu.