• Articles
• admin

jeg var ung, internett nettopp startet, og vi kunne få tonnevis av programvare gratis. Det var gratis fordi noen der ute var» snill » nok til a knekke / lappe den .exe-fil.

jeg har satt «kind» mellom sitater, fordi dette var utsikten jeg hadde da jeg var barn. Nå er jeg en programvareingeniør, og jeg vet hvor mye arbeid det tar å bygge programvare. Så vær så snill, ikke laste ned sprakk programvare. Støtt utvikleren og kjøp en lisens!

Bruk av en slik sprekk, patching exe, jeg har alltid ønsket å vite hvordan du gjør en slik ting. Det viser seg at du må forstå assembler, et maskinspråk bare DIN CPU forstår (og noen andre nerds der ute). Som det var for vanskelig, kom jeg aldri rundt for å lære det. Inntil nylig(som 20 år senere 😊).

for et år siden kjøpte jeg programvare(med lisens!) som trenger EN USB dongle til å fungere . Det er veldig tungvint å ha den donglen med deg hele tiden. Spesielt når du er på veien. Så jeg lette etter måter rundt det. Det første jeg kom over var denne nøkkelemulatoren kalt MultiKey. Det dumper minnet om dongle til registeret og deretter emulerer dongle ved å lese fra registeret. Det fungerte OK, til jeg ønsket Å kjøre Den På Windows 10. Tilsynelatende Er Microsoft ikke så stor fan av MultiKey. I virkeligheten er det ikke en stor fan av usignerte drivere Og MultiKey bruker en usignert driver. Så jeg trengte en annen løsning. Tid til å dykke inn i det som kalles assembly code!

jeg visste alltid at DET var et verktøy der ute for omvendt engineering, KALT IDA. Det er i stand til å dekompilere din .exe fil og vise hva som skjer. Dessverre er grensesnittet veldig vanskelig å forstå. Jeg visste også Om OllyDbg. Det er en debugger. En debugger lar deg gå gjennom assembler koden mens programmet kjører! Betydning, for eksempel hvis du vil feilsøke kalkulatorprogrammet, kan du faktisk se det håndtere et knappetrykk, gjør beregningen og viser resultatet på skjermen. Helvete, du kan til og med pauze og endre minnet som gjør kalkulatoren tilbake 5 når du spør hva 2 + 2 er!

Men Jeg er ikke her for å endre kalkulator (selv om det ville være kult). Jeg ønsker å være fri fra dongle. Så jeg åpnet appen Min Med OllyDbg.

Det var veldig overveldende. Jeg hadde ingen anelse om hva alle disse kodene betydde. La alene vet hvor du skal begynne. Så jeg gikk tilbake til tegnebrettet. Det viser seg at Det er Noe som heter RetDec, en dekompiler som prøver Å lage C-kode ut maskinkode. Det tok meg litt tid å sette den opp og kjøre dekompilering, men innsatsen betalt av. Resultatet var en stor .c-fil, over 2 millioner linjer med kode med semi-lesbar kode.

faktisk kunne jeg finne koden som leser byte av donglen ganske enkelt:

med denne informasjonen vendte jeg tilbake til min debugger. I mellomtiden fant jeg Ut At OllyDbg er veldig gammel (fra år 2000) og har ikke blitt oppdatert siden 2013. Så jeg fant denne nye, forbedrede debuggeren, kalt x64dbg. Det er åpen kildekode og har et stort fellesskap av utviklere som jobber med det.

Lese maskinspråk

i maskinspråk har hver instruksjon en minneadresse. Så med adressene som ble funnet I RetDec-koden, vendte jeg meg til x64dbg og se, koden som leser ut donglen:

i samlingskode lastes funksjonens argumenter inn i minnet ved hjelp av stakkpekeren esp. I vår kode skjer dette like før anropet til funksjonen. (3 mov-instruksjonene angir at samtalen tar 3 argumenter). Etter anropet tilbakestilles stakkpekeren og en sjekk (test) gjøres hvis anropet til funksjonen var vellykket. Hvis ikke, ser vi koden som gjør et hopp (jne). Dette hoppet peker på et stykke kode som indikerer at donglen ikke er til stede.

som du kan se, er det et kall til en bestemt funksjon for å lese ut donglen. Jeg så opp referanseguiden for å finne ut hva denne funksjonen gjør:

funksjonen leser en 2 byte minne (et ord) fra donglen. Som gjettet tar funksjonen 3 argumenter der det siste argumentet er en peker til 2 byte som vil inneholde noen data fra donglen.

i samlingskode lastes argumentene i omvendt rekkefølge. Passerer i det siste argumentet er dette:

det siste argumentet peker på esi, noe som betyr at dataene fra donglen vil bli lagret på minneadressen esi peker på.

Faktisk, når du stopper like etter at samtalen ble gjort, kan vi se resultatet i minnet:

0x74. Det er det som leses ut fra donglen og lagres i minnet til hovedprogrammet.

for å hoppe over dette anropet, trenger jeg bare å skrive 0x74 til minne der esi peker på. Dette er så enkelt som å erstatte de 7 linjene ovenfor med:

Som du kan se, jeg også nop-ed resten av assembler instruksjoner, inkludert test hvis samtalen til funksjonen var gyldig. Dette betyr at hoppet ikke vil bli tatt, og programmet vil fortsette å fungere uten sjekken.

etter patching alle samtaler som involverer donglen, lagret jeg den nye .exe. Jeg trakk ut donglen, kjørte min skikk .exe og til min egen forbauselse fungerte det! Jeg hadde lykkes sprakk et stykke programvare.

En annen ting jeg krysser på min bøtte liste 😊

Ps: de fleste av tingene var uklar, som 0x74 og navnet på appen. Dette er ikke å skade hardt arbeidende utviklere som skapte denne programvaren på noen måte. Også jeg var veldig heldig at donglen bare returnerte byte og ikke gjorde noen kryptering alene.