Reverse engineering dongle protected software
ik was jong, het internet is net begonnen en we konden tonnen software gratis krijgen. Het was gratis omdat iemand die er was “vriendelijk” genoeg om te kraken / patch de .exe file.
ik heb “soort” tussen aanhalingstekens gezet, omdat dit de weergave was die ik had toen ik een kind was. Nu ben ik een software engineer en ik weet hoeveel moeite het kost om software te bouwen. Dus alsjeblieft, niet gebarsten software te downloaden. Steun de ontwikkelaar en koop een licentie!
het toepassen van zo ‘ n crack, het patchen van de exe, wilde ik altijd al weten hoe ik zoiets moest doen. Het blijkt dat je assembler moet begrijpen, een machinetaal die alleen je CPU begrijpt (en enkele andere nerds die er zijn). Omdat het te moeilijk was, heb ik het nooit geleerd. Tot voor kort (zoals 20 jaar later😊).
een jaar geleden kocht ik software (met een licentie!) die een USB-dongle nodig heeft om te werken. Het is echt omslachtig om die dongle altijd bij je te hebben. Vooral als je onderweg bent. Dus zocht ik naar manieren om er omheen te gaan. Het eerste wat ik tegenkwam was deze key emulator genaamd MultiKey. Het dumpt het geheugen van uw dongle naar uw register en dan emuleert uw dongle door het lezen van uw register. Dat werkte OK, totdat ik wilde draaien op Windows 10. Blijkbaar, Microsoft is niet zo ‘ n grote fan van MultiKey. In werkelijkheid is het niet een grote fan van unsigned drivers en MultiKey maakt gebruik van een unsigned driver. Dus ik had een andere oplossing nodig. Tijd om te duiken in dat ding genaamd assemblage code!
ik heb altijd geweten dat er een tool was voor reverse engineering, genaamd IDA. Het kan je decompileren .exe file en laat zien wat er aan de hand is. Helaas, de interface is echt moeilijk te begrijpen. Ik wist ook van OllyDbg. Het is een debugger. Een debugger laat je door de assembler code stappen terwijl het programma draait! Wat betekent dat, bijvoorbeeld, als je de calculator applicatie zou debuggen, je eigenlijk kon zien dat het omgaan met een druk op de knop, het doen van de berekening en het resultaat op het scherm te tonen. Hell, je kunt zelfs pauze en veranderen het geheugen waardoor de calculator return 5 wanneer u vraagt wat 2 + 2 is!
maar ik ben hier niet om calculus te veranderen (hoewel dat cool zou zijn). Ik wil vrij zijn van de dongle. Dus ik opende mijn app met OllyDbg.
dat was echt overweldigend. Ik had geen idee wat al die codes betekenden. Laat staan weten waar te beginnen. Dus ging ik terug naar de tekentafel. Het blijkt dat er iets is dat RetDec heet, een decompiler die C-code probeert te maken uit machinecode. Het kostte me wat tijd om het op te zetten en de decompilatie uit te voeren, maar de moeite betaald. Het resultaat was enorm .C Bestand, meer dan 2 miljoen regels code met semi-leesbare code.
in feite kon ik de code die de bytes van de dongle leest vrij gemakkelijk vinden:
met deze informatie keerde ik terug naar mijn debugger. Ondertussen kwam ik erachter dat OllyDbg echt oud is (uit het jaar 2000) en sinds 2013 niet meer is bijgewerkt. Dus vond ik deze nieuwe, verbeterde debugger, genaamd x64dbg. Het is open source en heeft een grote gemeenschap van ontwikkelaars die eraan werken.
Reading machinetaal
In machinetaal heeft elke instructie een geheugenadres. Dus met de adressen gevonden in de RetDec code, draaide ik me naar x64dbg en zie, de code die de dongle leest:
in assembly code worden de argumenten van de functie in het geheugen geladen met behulp van de stack pointer esp. In onze code gebeurt dit vlak voor de aanroep van de functie. (de 3 mov instructies geven aan dat de aanroep 3 argumenten neemt). Na de aanroep wordt onze stack pointer gereset en wordt een controle (test) gedaan of de aanroep naar de functie succesvol was. Zo niet, dan zien we de code een sprong maken (jne). Deze sprong wijst naar een stukje code dat aangeeft dat de dongle niet aanwezig is.
zoals u kunt zien, is er een aanroep naar een specifieke functie om de dongle voor te lezen. Ik heb de Referentiegids opgezocht om erachter te komen wat deze functie doet:
de functie leest een 2 bytes geheugen (een woord) van de dongle. Zoals geraden, heeft de functie 3 argumenten waarbij het laatste argument een pointer is naar 2 bytes die wat gegevens van de dongle zal bevatten.
in assemblagecode worden de argumenten in omgekeerde volgorde geladen. Het laatste argument is dit.:
het laatste argument wijst naar esi, wat betekent dat de gegevens van de dongle worden opgeslagen op het geheugenadres waarnaar esi verwijst.
inderdaad, bij het pauzeren net nadat de oproep werd gedaan, kunnen we het resultaat in het geheugen zien:
0x74. Dat is wat wordt voorgelezen uit de dongle en opgeslagen in het geheugen van het hoofdprogramma.
om deze aanroep over te slaan, hoef ik alleen maar 0x74 naar het geheugen te schrijven waar esi naar wijst. Dit is zo eenvoudig als het vervangen van de 7 regels hierboven met:
zoals je kunt zien, heb ik ook de rest van de assembler instructies, inclusief de test of de call to function geldig was, nop-ed. Dit betekent dat de sprong niet zal worden genomen en het programma zal blijven werken zonder de check.
na het patchen van alle oproepen met de dongle, heb ik de nieuwe opgeslagen .executable. Ik trok de dongle eruit, deed mijn gewoonte.exe en tot mijn eigen verbazing werkte het! Ik had met succes een stuk software gekraakt.
een ander ding dat ik kruist van mijn bucket list 😊
Ps: de meeste dingen waren verduisterd, zoals 0x74 en de naam van de app. Dit is niet om de hardwerkende ontwikkelaars die deze software gemaakt op enigerlei wijze schaden. Ook ik had veel geluk dat de dongle Alleen terug bytes en deed geen encryptie op zijn eigen.