Reverse engineering dongle protected software
jag var ung, internet började precis och vi kunde få massor av programvara gratis. Det var gratis eftersom någon där ute var” snäll ” nog att knäcka / lappa .exe-fil.
jag har lagt ”snäll” mellan citat, för det var den uppfattning jag hade när jag var liten. Nu är jag en mjukvaruingenjör och jag vet hur mycket ansträngning det tar att bygga programvara. Så snälla, ladda inte ner sprucken programvara. Stöd utvecklaren och köp en licens!
applicera en sådan spricka, lappa exe, jag ville alltid veta hur man gör en sådan sak. Det visar sig att du måste förstå assembler, ett maskinspråk som bara din CPU förstår (och några andra nördar där ute). Eftersom det var för svårt kom jag aldrig runt för att lära mig det. Fram till nyligen(som 20 år senare 20 år senare).
för ett år sedan köpte jag programvara (med licens!) det behöver en USB-dongel för att fungera. Det är verkligen besvärligt att ha den dongeln med dig hela tiden. Särskilt när du är på väg. Så jag letade efter vägar runt det. Det första jag kom över var den här nyckelemulatorn som heter MultiKey. Det dumpar minnet av din dongle till registret och sedan emulerar din dongle genom att läsa från registret. Det fungerade OK, tills jag ville köra den på Windows 10. Tydligen är Microsoft inte så stort fan av MultiKey. I verkligheten är det inte ett stort fan av osignerade drivrutiner och MultiKey använder en osignerad drivrutin. Så jag behövde en annan lösning. Dags att dyka in i den där saken som heter assembly code!
jag visste alltid att det fanns ett verktyg där ute för omvänd teknik, kallad Ida. Det kan dekompilera din .exe-fil och visa vad som händer. Tyvärr är gränssnittet verkligen svårt att förstå. Jag visste också om OllyDbg. Det är en debugger. En debugger låter dig gå igenom assembler-koden medan programmet körs! Betydelse, till exempel, om du skulle felsöka kalkylatorprogrammet, kan du faktiskt se det hantera en knapptryckning, göra beräkningen och visa resultatet på skärmen. Helvete, du kan till och med pausa och ändra minnet så att räknaren returnerar 5 När du frågar Vad 2 + 2 är!
men jag är inte här för att ändra kalkyl (även om det skulle vara coolt). Jag vill vara fri från dongeln. Så jag öppnade min app med OllyDbg.
det var verkligen överväldigande. Jag hade ingen aning om vad alla dessa koder betydde. Än mindre vet var du ska börja. Så jag gick tillbaka till ritbordet. Det visar sig att det finns något som heter RetDec, en decompiler som försöker göra C-kod ut ur maskinkod. Det tog mig lite tid att ställa upp och köra dekompilering, men ansträngningen betalas av. Resultatet var en enorm .C-fil, över 2 miljoner rader kod med halvläsbar kod.
faktum är att jag kunde hitta koden som läser byte av dongeln ganska lätt:
med denna information vände jag mig tillbaka till min debugger. Under tiden fick jag reda på att OllyDbg är riktigt gammal (från år 2000) och inte har uppdaterats sedan 2013. Så jag hittade den här nya, förbättrade felsökaren, kallad x64dbg. Det är öppen källkod och har en stor gemenskap av utvecklare som arbetar med det.
läsning maskin språk
i maskin språk varje instruktion har en minnesadress. Så med adresserna som finns i RetDec-koden vände jag mig till x64dbg och se, koden som läser ut dongeln:
i monteringskod laddas funktionens argument i minnet med stackpekaren esp. I vår kod händer detta strax före samtalet till funktionen. (3 mov-instruktionerna indikerar att samtalet tar 3 argument). Efter samtalet återställs vår stackpekare och en kontroll (test) görs om samtalet till funktionen lyckades. Om inte, ser vi koden göra ett hopp (jne). Detta hopp pekar på en bit kod som indikerar att dongeln inte är närvarande.
som ni kan se, det ett samtal till en specifik funktion för att läsa upp dongeln. Jag tittade upp referensguiden för att ta reda på vad den här funktionen gör:
funktionen läser en 2 byte minne (ett ord) från dongeln. Som gissat tar funktionen 3 argument där det sista argumentet är en pekare till 2 byte som innehåller vissa data från dongeln.
i monteringskod laddas argumenten i omvänd ordning. Att passera i det sista argumentet är den här:
det sista argumentet pekar på esi vilket betyder att data från dongeln kommer att lagras på minnesadressen som esi pekar på.
när vi pausar strax efter att samtalet gjordes kan vi faktiskt se resultatet i minnet:
0x74. Det är vad som läses ut från dongeln och lagras i minnet av huvudprogrammet.
för att hoppa över det här samtalet behöver jag bara skriva 0x74 till minnet där esi pekar på. Detta är så enkelt som att ersätta de 7 linjerna ovan med:
som du kan se, jag också nop-ed resten av assembler instruktioner, inklusive testet om samtalet till funktionen var giltigt. Detta innebär att hoppet inte kommer att tas och programmet kommer att fortsätta att fungera utan kontrollen.
efter att ha lappat alla samtal med dongeln räddade jag det nya .exe. Jag drog ut dongeln, sprang min sed .exe och till min egen förvåning fungerade det! Jag hade framgångsrikt knäckt en mjukvara.
en annan sak som jag korsar av min hinklista bisexuell
Ps: de flesta sakerna var obfuscated, som 0x74 och appens namn. Detta är inte att skada hårt arbetande utvecklare som skapade denna programvara på något sätt. Jag hade också mycket tur att dongeln bara returnerade byte och gjorde ingen kryptering på egen hand.