Crackere har det for nemt!

Programmører beskytter deres sharewareprogrammer alt for dårligt. En programmør giver her gode råd om, hvordan man beskytter sine programmer bedre og tilbyder at teste dine programmer gratis.

Efter i et stykke tid at have kigget på programmer på www.danish-shareware.dk, besluttede jeg at skrive denne artikel. Jeg skriver denne artikel fordi jeg synes programmører er for dårlige til at beskytte deres programmer. Hvorfor dette er tilfældet, ved jeg ikke, men jeg kunne godt ha' programmørerne mistænkt for at være for godtroende, forstået på den måde at de ikke tror nogen vil (kan?) cracke deres program. Ikke desto mindre er det ofte tilfældet, at man i løbet af ganske kort tid efter at en ny version er udkommet, kan downloade en crack der låser programmet op. Dette er selvfølgelig ulovligt - det skal der ikke herske nogen tvivl om.

Men hvad er cracking? Ja, der er sikkert nogen der ikke ved, hvad dette begreb indeholder. Ja der er sågar nogen, der forveksler begrebet med hacking. Cracking of hacking er to vidt forskellige emner, og det er kun begrebet cracking der vil blive dækket i denne artikel.

Nå, men hvad går det så ud på? Jo, jeg vil i denne artikel forsøge at hjælpe programmører til at forstå, hvad der foregår i hovedet på en cracker, samt hjælpe interesserede med at beskytte deres programmer bedst muligt.

Da jeg selv hovedsagelig er Delphi-programmør, vil eksempler mm. bliver vist i dette sprog.

Jeg vil forsøge at komme ind på følgende emner:

Hvilke typer beskyttelser findes der?
Hvordan finder man ud af hvilken beskyttelse man skal vælge?
Hints til at gøre det endnu sværere for crackere at cracke ens programmer!
Hvordan beskytter jeg mine filer?
Eksempler på programmer der har gjort et godt forsøg.
Afsluttende kommentar på dette emne.
Extra: Hvordan finder jeg ud af om mine programmer er blevet cracket?

Jeg håber I vil synes at artiklen er interessant og evt. komme med tilbagemeldinger på mine synspunkter mm.

1) Hvilke typer beskyttelser findes der?

Der er tre overordnede typer af beskyttelse:

- Navn/registreringskode
- Keyfile
- Dongle

Den mest brugte type er klart Navn/registreringskode. Dette skyldes, at det klart er den letteste at kode og at implementere i sit program. Denne type kan, hvis man finder den rigtige algoritme og implementerer den ordenlig, være den sværeste af metoderne. Efter at have kigget www.danish-shareware.dk igennem, fandt jeg ud af at dette også er den mest udbredte på denne side. Derfor vil jeg gøre extra meget ud af denne type.

Den værste måde at benytte denne type på, er ved at hardcode registreringskoden i programmet. Dvs. at man simpelhen skriver den rigtige registreringskode i programmet (for at kunne sammenligne med det brugeren senere indtaster). Derved gør man faktisk "navn" overflødigt, da programmet kan registreres med et hvilket som helst navn, bare registreringskoden er rigtig. Hvis man gør det på den måde, vil enhver cracker kunne finde registreringskoden på under 2 minutter. Det første en cracker gør, er nemlig at kigge på Streng-Referencer i programmet (det er her alle strenge står). Der vil registreringskoden også være, og programmets beskyttelse er spildt og kunne lige så godt have været undladt.

En anden måde er at man tager navnet, og derudfra beregner en registreringskode. Denne kode vil derfor blive forskellig fra navn til navn, og er derfor sværere at cracke. Dog skal man ikke føle sig sikker, da måden man implementerer denne type på, betyder MEGET. Det kan godt være, at man har en utrolig svær algoritme til at generere registreringskoden, men hvis man sammenligner på en forkert måde, vil koden stå i den debugger crackeren bruger, og vil derfor være i clear-text og læselig - lige til at skrive ned.

Et eksempel på hvordan man IKKE skal gøre kunne se således ud:

NavneInput := NavneInputFelt.text;
RegKodeInput := RegKodeInputFelt.text;
// Kode der genererer den rigtige registreringskode ud fra navnet.
if RigtigeRegKode = RegKodeInput then
// Dialog der fortæller at registreringskoden er RIGTIG!

Det der foregår, er at brugeren indtaster et navn og en registreringskode. Der bliver nu genereret en RIGTIG registreringskode udfra navnet, som bliver sammenlignet med det brugeren indtastede i registreringskodefeltet. "Hvad er der galt i det?", spørger I så måske. Ja. For det første må man ALDRIG sammenligne registreringskoderne på den måde. Det er SÅ let at finde registreringskoden, hvis det bliver gjort på den måde. Det man kunne gøre er at man OGSÅ kører registreringskoden igennem en algoritme og SÅ sammenligner dem bagefter.

Et eksempel på hvordan man KUNNE gøre:

var NavnK, RegKodeK : String;
NavneInput := NavneInputFelt.text;
RegKodeInput := RegKodeInputFelt.text;
NavnK := FunktionDerGenerererEnRegistreringsKode(NavneInput);
RegKodeK := FunktionDerGenerererEnRegistreringsKode(RegKodeInput);
if NavnK = RegKodeK then
// Dialog der fortæller at registreringskoden er RIGTIG!

Som det ses, er dette kun en skabelon til hvordan man kan gøre. Ved at gøre det på denne måde kan crackeren ikke bare læse registreringskoden direkte i hukommelsen. Crackeren vil nu skulle til at reverse registreringskoden, og det er her vi kan gøre det svært for ham. Hvis algoritmen er stærk nok, vil det praktisk talt være umuligt at lave en rigtig registreringskode. Hvis man vil være (næsten) sikker på at der ikke kommer nogen crackede registreringskoder, skal man bruge RSA eller SHA med mindst 768 bit.

En anden ting man burde benytte sig af er checks. Hvorfor er der så få programmører, der kun checker deres registreringskode én gang? Det er for LET at cracke!! Lav MANGE check på registreringskoden. Check om den indeholder "-", " " eller andre tegn. Check om den er lang nok (hehe..). Check om den er for kort. Bare check. Jo flere check jo sværere er det at cracke. Det gør ikke noget, at I har så mange checks, at det tager 1-2 sekunder at registrere. Det er jo noget, der kun skal gøres én gang (forhåbenligt), så hvad gør det om brugeren skal vente 1-2 sekunder? Brug svære algoritmer og check et utal af gange på registreringskoden. Husk desuden at gemme den flere steder. Ikke bare én gang i en .ini file hvor der står: Reg=12345 (dette vender jeg tilbage til senere).

Når det nu er sagt, kan man så føle sig sikker? Nej! Selvom en cracker ikke kan finde en rigtigt registreringskode, er man IKKE sikker. Det er stadig muligt at cracke exe-filen, så den accepterer ALLE koder. Derfor skal man også tænkte på kryptering og komprimering af sine filer. Dette bliver beskrevet nærmere i punkt 6.

2) Hvordan finder man ud af hvilken beskyttelse man skal vælge?

Tja, dette er faktisk et temmelig svært spørgsmål. Det kan selvfølgelig være man ikke har så meget at vælge imellem pga. ens økonomiske situation, eller pga. ens manglende kunnen. Der er mange programmører der er utrolig gode til at lave programmer, og virkelig forstår hvad de laver, men alligevel er de ikke i stand til at kode en registreringsfunktion der er (næsten) sikker. Der er også nogen, der bevidst fravælger at udvikle en svær registreringsfunktion, Det afhænger selvfølgelig af hvad man går op i, men hvorfor så ikke ofre de penge det nu engang koster at få beskyttet sit program? Svaret er simpelt: Det kan ikke lade sig gøre at beskytte et program 100%, og mange vil derfor føle sig snydt.

"Hvad man skal vælge, afhænger også af hvor stort programmet er." Tja, det er så ét synspunkt. Personligt synes jeg ikke det argument holder. Jeg ser ofte store programmer a la AutoCAD, SolidWorks, Geomagic og mange flere, som tror de er sikre når de bruger dongle. (Dongle er en fysisk enhed, man skal indsætte i parallel-/serielporten, før programmet kan starte). Det skal hertil siges, at en dongle KUN er sikker, hvis man forstår at bruge den ordenligt. Det er der dog tilsyneladende ikke nogen der gør. Alle ovennævnte virksomheder forstår det i hvert fald ikke, og de har da trods alt økonomien til det. Men hvad så? Det lader ikke rigtig til at der er meget at stille op. Men rolig nu. Det ER der! Jeg vil sige: "Kod det du er bedst til og kod det ORDENLIGT". Hvis man er god til algoritmer mm. og virkelig har styr på Assembly eller lignende, så brug det. Lav en ordenlig algoritme, eller hent en gratis på nettet. Der findes mange Open Source algoritmer, som man frit kan benytte. Derfor er det også muligt for den gennemsnitlige programmør at beskytte sit program.

Hvad man skal vælge, afhænger også af hvor udbredt ens program er. Er det bare et lille program, som kun har en lille målgruppe, eller er det et udbredt program, som ligger nr 1 på adskillige TOP10 download lister? Hører man til den første gruppe, er det måske nok kun at bruge et par timer på registreringsfunktionen, hvorimod hvis man hører til den sidste gruppe, bruger 5 eller 10 timer på det. Eller måske endda uger?

Der findes ikke ét endegyldigt svar på hvad man skal vælge. Det hele afhænger af hvad man er god til, og hvad man føler er bedst for ens program og ens brugere. (Der vil senere blive nævnt eksempler på programmer, som har gjort det godt).

3) Hints til at gøre det endnu sværere for crackere at cracke ens programmer!

Checks. Kodeordet er "checks". Det er gratis at checke på om programmet er registreret korrekt, så benyt dig af det. Hvis man benytter "name/serial" så check MANGE gange. Også andre steder i programmet. Fx. når en bruger forsøger at gemme et dokument, eller når der bliver printet. Der kan sagtens være små usynlige checks mange steder. En anden ting man skal huske på her er IKKE at bruge let genkendelige navne. Brug ALDRIG "OnDialogRegistreringClick", eller andre navne der på nogen måde kan henvise til registreringen. "CheckRegistrering()" er BANDLYST. Det er SÅ utrolig let at finde beskyttelsen, hvis der er ledetråde i koden. Dette betyder naturligvis ikke, at hvis man benytter kryptiske funktioner, så er man sikker. Man kan dog forsinke en crackers arbejde betydeligt ved at bruge "skumle" funktionsnavne.

Bruger man Keyfile metoden bør man gribe det lidt anderledes an. Her står registreringskoden bl.a. i en registreringsfil. Jeg skriver bl.a. fordi den IKKE KUN skal ligge i den fil. Hvad med at gemme den i registreringsdatabasen eller andre steder? GØR DET! Husk også at man ikke kun checker en keyfile én gang. Her skal man passe på, at man ikke checker på udsatte steder. Lad derfor være med at checke, når man gemmer eller åbner dokumenter eller printer. Check evt. ved hjælp af en timer hvert 20. minut? Eller sæt en extra timer på, som checker hver 2. dag. Sæt også et check ind i funktioner, som ikke bliver brugt så ofte. En online-update funktion måske? Vær kreativ.

Ved min gennemgang af programmer på denne side fandt jeg flere programmer, der har en UTROLIG svag keyfile beskyttelse.
Her er et eksempel på hvordan man IKKE skal gøre:

[Inifil]
Regnavn=Danish-Shareware

Ja...nogen vil måske sige, at der da mangler noget...en registreringskode f.eks. Men nej...jeg har set programmer, som bliver 100% registrerede, bare ved at sætte den linie i en .ini fil. Dette er klart en dum måde, som jeg ikke vil kommentere nærmere. I som har brugt denne metode, ved hvem I er.

Der findes så en anden og lidt sværere variant, som ser således ud:

[Inifil]
Regnavn=Danish-Shareware
Regkode=12345

Det er også godt nok, men så alligevel ikke. Det er stadig ikke nok. Hvis dette er det eneste sted registreringskoden står, er det i hvert fald for lidt. SKal man absolut kun have ét check til registreringskoden, og skal den absolut kun stå ét sted, så gør det i stil med det her:

[Inifil]
Regnavn=Danish-Shareware
Regkode1=12345
Regkode2=67890

Brug 2 registreringskoder. (Eller flere...mange flere måske?) Brug så de to koder og navnet til at checke om programmet er registreret. Der findes selvfølgelig flere varianter af denne metode, og de kan da sagtens være sværere. Se den her f.eks.:

[Inifil]
Regnavn=HDSFOSDFIGBSDF
Regkode1=12345
Regkode2=67890

Her er "Regnavn" krypteret. Dette gør det endnu sværere at cracke, da man først skal i gang med at dekryptere navnet. Denne måde er dog heller ikke 100% sikker, men man kommer ikke meget tættere på 100%.

Brug fantasien til at gøre det mere sikkert. Lav evt. en helt separat registreringsfil, som indeholder en lang krypteret nøgle. Dem der så registrerer, får den fil tilsendt, og det har derfor ingen betydning, om der er 10, 20, 500 eller 1000 tegn i den fil.

Dongle er klart den dyreste metode, og er ikke noget man skal bruge, med mindre man har penge til det. Der er mange der siger "en dongle kan ikke crackes. Du har jo ikke den ting, der SKAL være der, så du kan godt glemme at cracke den." Pjat. En dongle der er brugt forkert, kan SAGTENS crackes. Faktisk kan det være MEGET lettere end alle andre beskyttelser, hvis der kun er et enkelt check på om donglen sidder i porten. Hvis der ikke ligger nogen vigtige funktioner på donglen, kan man lige så godt lade være med at bruge den. Der er mange der checker, om donglen sidder der, og så tror de det er nok. Det er det IKKE. Man kan sagtens gå ind og emulere, at der sidder en dongle i porten.

Derimod kan det være meget svært at cracke den dongle. Grunden til at det kan være svært, er at man kan gemme kode på den. Tag og gem de vigtige funktioner på selve donglen, så programmet SKAL bruge den. Hvis den ikke sidder der, kan programmet jo ikke udføre visse funktioner, da de simpelthen ikke er der. Det skal dog siges, at man godt kan kopiere kode fra en dongle og putte ind i programmet, men det forudsætter naturligvis at man HAR den dongle, og det er de færeste crackere der har det :-)

Den sidste beskyttelse jeg lige vil nævne er CRIPPLEWARE. CRIPPLEWARE betyder at der mangler kode i programmet. Det er ofte i forbindelse med DEMO'er af programmer. Men men men....der er alligevel nogen der ikke helt forstår begrebet. Der findes utrolig mange programmører der, selvom det er crippleware, lader koden være i programmet. Programmet ser nu ud til at være en DEMO, men rent faktisk ER det en fuld version, som bare skal registreres. Gør ALDRIG sådan! Hvis et program er CRIPPLEWARE, så LAD VÆRE med at putte koden i. Det er SÅ dumt.

4) Hvordan beskytter jeg mine filer?

Dette er faktisk svært at besvare. Og dog. Der findes programmer på nettet, som kan gøre en stor del af arbejdet. Jeg vil ikke komme ind på, hvordan man manuelt kan beskytte sine filer. Med mindre man er utrolig god til kryptering og kompression vil jeg anbefale at lade være. Det er alt for let at dekryptere en fil, som ikke er beskyttet ordenligt, i forhold til hvor lang tid det tager at beskytte den.

Hvis man er indstillet på at beskytte sit program på en god måde, og man er villig til at betale lidt for det, vil jeg klart anbefale at man køber et beskyttelsesprogram. Der er specielt ét program jeg tænker på: AsProtect. Den nyeste version af dette program får MANGE crackere til at give op. Mig bekendt er programmet udviklet af en tidligere cracker, og vedkommende har derfor insider viden om kryptering. Jeg har set adskillige crackere give op over for dette program. Det skal dog siges, at det SKAL være den nyeste version, eftersom de ældre versioner er blevet cracket. Det lyder ikke lovende for de nye versioner, hva'? Hehe...det er som man ta'r det, men dette program er klart det førende på markedet, og tilmed temmelig billigt.

Hvis du ikke ønsker at ofre penge på software, der kan beskytte dine programmer, så HUSK: Check MANGE GANGE!! Det kan ikke siges nok. Hvis man har en utrolig stærk algoritme, blandet sammen med MANGE checks, kan men være sikker på at MANGE crackere giver op.

5) Eksempler på programmer der har gjort et godt forsøg

Som oftest er det programmer, der er udviklet af tidligere crackere, der er de sværeste at cracke. Et program som jeg VED mange har haft problemer med er FlashFXP (www.flashfxp.com). Dette program benytter RSA768 og en temmelig god exe-fils beskyttelse. Der er MANGE, der har givet op over for dette program, eller også har de lavet cracks, som fik programmet til at crashe af og til. Dette program blev dog også cracket. Det skyldes at exe-filen IKKE var beskyttet godt nok. Det blev udelukkende cracket, fordi det var muligt at ændre en værdi i programmet, der gjorde at RSA768 blev til noget i stil med RSA50. For dem der ikke ved hvad det betyder, kan jeg fortælle at ved at ændre 768 til 50 blev det SÅ UTROLIG meget lettere at cracke det, og der blev endda lavet en key generator. Hvis dette program havde brugt en exefils beskyttelse, var det nok ikke blevet cracket (i hvert fald ikke så hurtigt...der var nok gået adskillige måneder eller måske endda år).

Et andet program som mange havde problemer med, var CuteFTP. Dette program kender de fleste nok. Der blev lavet MANGE cracks til programmet, som fik det til at crashe. Der var MANGE crackere der gav op. Ikke desto mindre var dette program heller ikke beskyttet af en god exefils beskytter, så der blev også lavet en key generator. Dette programs beskyttelse udmærkede sig i de utal af checks det havde - og stadig har. Men når man først har en rigtig registreringskode, har checks ikke noget at sige. Dette program kunne ha' været bedre beskyttet, hvis der var brugt en bedre algoritme. Programmøren af dette program brugte for mange ressourcer på checks, og glemte at algoritmen også skulle være stærk.

Jeg vil nu tage et lille sidespring, da jeg synes det er vigtigt for forståelsen af beskyttelser. Det drejer sig om spil. Der findes mange store virksomheder, der producerer spil, og som virkelig har økonomi til at beskytte deres spil. Selvom de har et utal af ressourcer at trække på, har jeg endnu ikke set et spil, der ikke er blevet cracket. Der findes ellers mange måder at beskytte sine spil på. Bl.a. udvikler Sony et system, der skulle være sikkert. Det er det IKKE. Beskyttelsen er ikke sikker, men alligevel ofrer MANGE spilproducenter mange penge på at benytte metoden. Hvorfor? Fordi de ikke kan teste om beskyttelsen er god nok, før de benytter den. Det er der selvfølgelig ikke mange der kan. (Jo, gode crackere selvfølgelig). Dette irriterer mig en smule :-)

Derfor vil jeg nu sige (både i spil- og applicationssammenhæng):
Skulle du sidde der ude og tro, at du har en sikker beskyttelse, så er jeg mere end villig til at teste den for dig. Dette er 100% gratis og jeg ønsker ikke at blive nævnt eller få credit på andre måder. Hvorfor gør jeg det? Fordi jeg er træt af at se amatøragtige beskyttelser. Lav en test-application med beskyttelsen, og lad mig teste, om du er på rette spor. Jeg vil så (hvis jeg kan cracke det) skrive en lille tekst om hvordan jeg har gjort, og om hvordan du kunne gøre det bedre.

6) Afsluttende kommentar på dette emne

Afslutningsvis vil jeg godt sige, at jeg håber I kan bruge en lille del af denne artikel. Kan I det, er jeg glad. Husk også at INTET er 100% cracker-sikret. ALT kan crackes. Uanset om der bliver brugt 1000^1000 timer på at beskytte det. De klogeste programmører er crackere. Sådan er det.

Jeg håber I får gavn af denne artikel, da jeg selv synes jeg forklarer en del emner. Skulle jeg få flere idéer eller synes du der mangler noget (sig blot til), vil jeg overveje at skrive lidt mere.

7) Extra: Hvordan finder jeg ud af om mine programmer er blevet cracket?

En god indgangsvinkel til at se, om ens programmer er blevet cracket, er at bruge søgemaskiner. Her tænker jeg specielt på én:

astalavista.box.sk

Dette er en "crack" database, og hvis der findes en crack til et program, kan man (næsten) helt sikkert finde den her. Jeg vil dog anbefale, at man bruger flere søgemaskiner. www.astalavista.com, www.google.com og hvad man ellers kender til. Søg efter: +"program navn" +crack, og se om der bliver fundet noget.

En anden måde er at tilmelde sig nyhedsgrupper. "alt.cracks" eller lignende er gode at starte med. Spørg om en crack til et program, og du kan være (næsten) sikker på, at hvis der findes en crack, og der er nogen der har den, så bliver den uploaded til nyhedsgruppen.

Den sidste mulighed, som dog kun kan benyttes, hvis man er cracker eller har insider viden i warez scenen, er den mest sikre. Der findes ftp'er hvor man kan søge efter cracks etc. Da dette ikke er noget alle har, eller kan få adgang til, vil jeg godt tilbyde at gøre det for jer. Det I skal gøre, hvis I gerne vil have jeg skal checke, er at kontakte mig via emailen nederst (til Finn Ekberg). I emailen skal der stå det FULDE programnavn og version. Et eksempel på det kunne være følgende:

Program Navn, version x.xx

I er selvfølgelig velkommen til at skrive flere programmer på én gang på listen.

Regler:

Denne tekst er copyrightet. Den må IKKE kopieres eller bruges på NOGEN form for medie/hjemmeside uden min tilladelse. Hvis jeg ser denne tekst på andre sider, som jeg ikke har givet tilladelse til, vil jeg gøre hvad der er i min magt for at få fjernet den og/eller lukket siden.

Jeg vil KUN kunne kontaktes ved at skrive til ejeren af denne side. Dette er den ENESTE måde at kontakte mig på, da jeg vil være 99.9% anonym. Derfor vil jeg også frabede mig at I, hvis I vil i kontakt med mig, spørger om min email, icq, hjemmeside, whatever mm. Jeg gør dette frivilligt og ønsker at blive respekteret, når jeg siger jeg vil være anonym.

Nå..men jeg smutter....ZZZZZZZZZZzzzzzzzzzzzzzzzzzzzzz

Forfatteren er undertegnede bekendt, og han har givet tilladelse til at bringe artiklen her.
Kommentarer mv. til forfatteren af artiklen kan sendes til mig (Finn), så vil jeg sende dem videre.

Reaktioner på artiklen

Jeg har læst artiklen og jeg fandt den meget interessant. Mht. afsnit 3 "Hints til at gøre det endnu sværere for crackere at cracke ens programmer!", syntes jeg at der mangler et tip.

Der står i artiklen at man ikke skal bruge genkendelige navne sådan som "OnDialogRegistreringClick" og så videre. Men man kan godt lægge funktioner som har navne som dette ind i sit program, som enten ikke gør noget, eller i hvert fald ikke har noget med registreringssystemet at gøre. Dette må gøre det sværere for en cracker at finde frem til den rigtige funktion, og i det mindste gøre det meget mere besværligt for crackeren at bruge programbeskyttelsen.

Venlig hilsen
Anders Mørk Hansen.
PublicWare.dk