[Alg] Anti-kraak beveiligingen *

[Verwijderd]

We kennen allemaal wel de vele illegale applicaties en spelletjes. Ze hebben allemaal verschillende beveiligingen maar allemaal worden ze toch "gebroken" en daarna kun je ze zonder veel problemen draaien.

Er is hier een uitzondering: het spelen van spelletjes online word onmogelijk gemaakt. Ik heb m'n gedachten er over heen laten gaan en dit gaat waarschijnlijk als volgt:
- gebruiker typt cd key in.
- gebruiker logt in in online spel
- spel verstuurt cd key naar autorisatie server
- autorisatie server kijkt naar cd key en ziet of het een geldige of ongeldige is
- spel stuurt crc checks van verschillende bestanden naar server
- server kijkt of crc checks nog kloppen
- als cd key en crc checks oke zijn dan kan de gebruiker beginnen met online spelen

Maar wat me raar lijkt is dat dit niet te breken is, je hoeft toch alleen maar de functie eruit te halen die de cd key en crc checks naar de server stuurt? Bijvoorbeeld:

function docdcheck(){
return cdkey_valid();
//verander je in return true
}

In de praktijk blijkt dit niet te werken. Mijn vraag is waarom werkt het niet als je de functie van de cd key en crc check eruit haalt?

Het is niet dat ik een spelletje online wil spelen, maar ik ben bezig met een applicatie die een online verbinding vereist, ik wilde een soort gelijk beveiligings routine implementeren als bij spellen die online gespeelt kunnen worden. Dan word dit een (bijna) niet te kraken applicatie en dan krijg ik meer inkomsten

[pagani]

1. Het is bij veel spellen al wel gelukt om dit systeem te kraken.
2. Als je een spel gaat hacken/cracken staat er geen c-achtige sourcecode maar assembly, dat leest ietwat lastiger.

Wat je moet implementeren:
Elke key moet je opslaan in een DB. Dus niet vrolijk alle keys die kloppen met een bepaalde check toelaten. Deze keys check je steeds met het gebruikte IP-adres. Als dit te vaak wisseld, niet meer toelaten. Als er meerdere keren tegelijk wordt ingelogd met 1 IP: niet doorlaten.

Die CRC checks heb je dan in principe alleen nog nodig als je gemodde clients wil voorkomen.

[ Voor 53% gewijzigd door pagani op 08-12-2003 10:43 ]

[Glimi]

Verwijderd schreef op 08 december 2003 @ 10:37:
Maar wat me raar lijkt is dat dit niet te breken is, je hoeft toch alleen maar de functie eruit te halen die de cd key en crc checks naar de server stuurt? Bijvoorbeeld:

function docdcheck(){
return cdkey_valid();
//verander je in return true
}

Het lijkt me eerder dat de server de CD-key vraagt aan de client en dan zelf gaat kijken of deze valid is en of deze al eerder geregistreerd en of op het moment in gebruik is.
Vervolgens een CRC op de bestanden lijkt me niet echt zinvol, alleen in het geval van cheat detection misschien. Echter ook deze check zal de server zelf doen. Regel één van webprogrammeren (en dat geldt hier ook) is "vertrouw de gebruiker nooit!"

[cimbom]

Server accepteert geen connectie zonder dat er eerst gechecked wordt?
Dus je kan wel aan client kant die check uithalen, maar server zegt nee zonder check.

[Janoz]

Primair zit het hem in de CD-key. Er is gewoon een database met verkochte cd's en elk heeft een unieke CD-key. Bij het instaleren werd er een checksum berekend om de juistheid te bepalen. Dit is makkelijk te kraken, of, mbv reverce engenering, makkelijk een keygen voor te maken. Doordat er online op de exacte key kan worden gecontroleerd helpen keygens niet. Ongeldige key = kick. Geldige key, maar die wordt 3x tegelijkgebruikt -> key ongeldig en orginele bezitter kan met bon nieuwe aanvragen.....

[djexplo]

Het probleem is dat als twee clients met de zelfde sleutel proberen in te loggen dit geregistreerd wordt op de server. Bij de meeste spellen is het zo dat als er meer dan 2 users te geleikertijd op een server inloggen deze key op alle andere officiele game servers en later via server upgrade software op andere game servers wordt geblokt.

Of te wel een key generator met veel keys is nodig voor online play mogelijkheden.

Verder is het zo dat bepaalde crc checks values via handshaking en tijds informatie over het internet worden uitgewisseld. Dus het faken van bepaalde crc pakketjes is moeilijk.

[Gomez12]

Het werkt niet als je dingen niet meer verstuurt, want dan krijgt de server geen antwoord meer. Het zou volgens mij theoretisch wel werken als jij een goede cd-key hardcode ( dan ook gelijk maar een kopie van deze versie maken, want bij 10.000 x zelfde cd-key weigert server weer )

En als jij de crc-checks ook hardcode. Het hardcoden van crc-checks is leuk, want als er dan om de dag een nieuwe patch verstuurt wordt over inet veranderen jouw crc-checks niet. En de officiele wel.

Denk dat het zo ongeveer zo werkt.

Plus dat ze op de server nog de mogelijkheid hebben om iedere cd-key te bannen en kleine updates uit te voeren ( denk aan : voeg iets toe aan een readme.txt en je crc-check is anders terwijl het spel niet verandert )

[Verwijderd]

je kan ook zorgen dat een deel van de source met de cdkey check op je server staat en dat daar ook een paar vars instaan of een ander stuk source dat nodig is om je applicatie te laten draaien zodat ze dat stuk niet (makkelijk) assembly kunnen kraken

[Verwijderd]

Bedankt voor de replies! ik begin het te begrijpen. Het zit hem dus in het volgende:
1. als meerdere gebruikers tegelijk online zitten met 1 cd key, dan ban je deze cd key, gebruikers die deze cd key gebruiken kunnen dan niet meer online.
2. als een slimme gebruiker er voor zorgt dat de cd key check "op 1 of andere manier" word omzeilt, accepteerd de server geen connectie van deze gebruiker omdat hij nog niet de cd key check heeft gedaan.
3. tussentijds (tijdens het spelen) word om de zoveel minuten een packetje met crc checks verstuurd om zo te detecteren of er met de exe of andere bestanden geknoeit is.

Nu even naar m'n applicatie, dit is een applicatie die geen constante verbinding vereist met een bepaalde server, bijvoorbeeld een ftp client die bij het opstarten online controleert of de cdkey e.d. nog goed zijn. Dit lijkt me een probleem als ik dezelfde beveiligings routine wil toepassen als bij online spelletjes, want punt 2. is dan niet mogelijk. En met punt 2. staat en valt heel de beveilingsroutine, want als een slimme gebruiker de cd key check er uit haalt, de tussentijds check eruit haalt, dan kan de gebruiker gewoon de applicatie gebruiken.

Ik zit ook te denken aan een verplichte dagelijkse/wekelijkse update die automatisch word gedownload. De beveiligingsroutine word dan als volgt:
- applicatie start op
- applicatie stuurt cd key + crc check van een aantal bestanden naar server
- server return "ja" of "nee", bij "nee" word de applicatie afgesloten
- tijdens het draaien van de applicatie worden er random crc checks online gedaan
- tijdens het draaien van de applicatie word er gekeken of er een update beschikbaar is, zo ja, dan word deze gedownload. De bestaande bestanden worden overschreven (inclusief misschien illegaal gewijzigde bestanden die de cd key + crc check verwijderen).

Alleen bedenk ik me tijdens het typen, dit is nog steeds te kraken, men kraakt de cdkey+crc check bij de startup en men haalt de automatische update check eruit. De eindgebruiker blijft dan wel zitten met een versie die niet geupdate kan worden en mag elke week een 100 mb downloaden en zoeken naar een illegaal bestand

Ik ben er eerlijk gezegd nog niet helemaal tevreden over, hoe zouden jullie deze beveiligingsroutine beter/slimmer maken?

[AtleX]

Registratie verplicht maken, CD-key via telefoon of fax aan de klant geven zodat je zeker weet of het wel een bestaande persoon is die de code wil hebben. De key samen met de gegevens van de klant opslaan en elke keer controleren of het een geregistreerde key betreft. Om te voorkomen dat de checks eruit gesloopt worden kan je ook nog bepaalde delen van de software op de server draaien. Dan moet er wel verbinding gemaakt worden.

[IceM]

Jij hebt het probleem dat je de serverkant (dus bijv. de ftp server) niet "beheerd". Dat wil zeggen, dat stukje software niet geschreven hebt.

Bij multiplayer games zit elke client op een door jou (bedrijf) geschreven server. Die 2 kunnen dus samenwerken mbt de beveiliging.

De client in jou geval heeft jou server die controleerd of de serial goed is helemaal niet nodig om goed met de (bijvoorbeeld) ftp server te communiceren.

En dus is het mogelijk om het hele gebeuren wat tussen jou controle server en de client gebeurd eruit te rippen en toch een goed functioneel programma over te houden.

Het is in jou geval dus niet mogelijk de applicatie optimaal te beveiligen, je kunt het alleen zo lastig mogelijk maken.

[Juup]

Het is natuurlijk i.h.a. zo dat een cracker erg rustig kan gaan zitten proberen/testen om de offline cd key te kraken. Maar als je steeds op de gameserver moet gaan checken of iets geaccepteerd wordt, dan wordt je vast een keer gesnapt. De admin kijkt effe in de logs en denkt: he die is raar bezig.

[Obliterator]

Er is nog een mogelijkheid bij deze manier:

- applicatie start op
- applicatie stuurt cd key + crc check van een aantal bestanden naar server
- server return "ja" of "nee", bij "nee" word de applicatie afgesloten


Server stuurt nee omdat de client verandert is, maar de veranderde client maakt hier voor het gemak ja van... De server moet de connectie niet toestaan als de crc niet klopt. En de client moet heel erg afhangen van diezelfde connectie.

[EfBe]

Verwijderd schreef op 08 december 2003 @ 10:37:
Maar wat me raar lijkt is dat dit niet te breken is, je hoeft toch alleen maar de functie eruit te halen die de cd key en crc checks naar de server stuurt? Bijvoorbeeld:

function docdcheck(){
return cdkey_valid();
//verander je in return true
}

In de praktijk blijkt dit niet te werken. Mijn vraag is waarom werkt het niet als je de functie van de cd key en crc check eruit haalt?

Omdat niet de client maar de server de key check doet. Dus de server krijgt een failure terug, en laat jou niet toe. Simpel

In de client het eruit halen is inderdaad simpel, vandaar dat het ook niet zo gedaan wordt.

[Tom-Eric]

Ik denk dat je het beste een gedeelte van de executable kan encrypten, en dan bij de verbinding van de client / server de server om een specifiek gedeelte van de hash te vragen, waarna hij een specifiek gedeelte terugstuurd en deze twee samen de executable decrypten. Op die manier is het niet een specifiek check die wat een cracker moet patchen.

Het probleem echter is dat je geen constante verbinding vereist, wat een cracker dan doet is de decrypte executable uit het geheugen inlezen en eventuele checks patchen. Je maakt het ze natuurlijk wel moeilijker, maar als je niet een constante verbinding vereist, lijkt het mij dat elke bescherming te kraken is.

[Woy]

De enige goede manier die je inderdaad hebt is als de client connect de serial op laten sturen de server laten controleren of deze geactiveerd is. Eventueel kun je nog de optie inbouwen dat er niet meerdere keren dezelfde serial mag inbouwen.
Wat ook een aantal keer gezegd wordt in deze thread is het oversturen van een crc check. Dat is natuurlijk ook eenvoudig te kraken. Stel je hebt origineel de volgende pseudo code

code:

function SendCRC()
{
    BerekenCRCCodeVanExe();
    StuurCRCCode();
}

Deze kan door een cracker natuurlijk makkelijk vervangen worden door

code:

function SendCRC()
{
    BerekenCRCCodeVanDeOrigneleExe();
    StuurCRCCode();
}

De grap hierin is dat de code natuurlijk gewoon veranderd kan worden zodat de crc check niet op het huidige bestand wordt gedaan maar op de originele versie van de exe. Het is voor de server dan niet te onderscheiden van de normale reactie.

[EfBe]

Als je voor functionaliteit niet naar een server hoeft, is een beveiliging met zo'n server altijd te kraken. Effectief is dus voor functionaliteit naar de server te moeten, bv voor het downloaden van een deel van de app, elke keer

[Woy]

EfBe schreef op 08 december 2003 @ 15:36:
Als je voor functionaliteit niet naar een server hoeft, is een beveiliging met zo'n server altijd te kraken. Effectief is dus voor functionaliteit naar de server te moeten, bv voor het downloaden van een deel van de app, elke keer

Dan is het natuurlijk nog wel belangrijk dat er in dat deel van de app telkens iets veranderd wat door de server te controleren is. Anders kan iemand met een juiste key het deel van de app downloaden en alsnog verspreiden als soort van Crack.

[jvdmeer]

Let er ook op dat de data client->server afhankelijk is van tijd. Andres w3ordt een hack erg makkelijk:

• Start sniffer
• Start app met geldige code
• Stop sniffer

• Schrijf eigen server-app die zelfde reactie geeft op de client verzoeken.
• Klaar is Kees

[Verwijderd]

lees dit ook even door

[Verwijderd]

Verwijderd schreef op 08 december 2003 @ 20:32:
lees dit ook even door

Dank je voor de link, die zal ik zo eens gaan doorlezen!

Overigens zoals door andere aangegeven in deze thread is bijna elke clientside beveiliging te kraken, dat is erg jammer...

[ Voor 21% gewijzigd door Verwijderd op 09-12-2003 09:51 ]

[AaroN]

Aan de andere kant kun je gewoon client functies cracken, zodat deze altijd een goed antwoord geven. Dit gebeurt bijvoorbeeld bij Counterstrike hacks, waarbij dus de VAC functies gehookt worden en overschreven in RAM. Deze functies voeren dan gewoon niets uit als ze door de server aangeroepen worden om te checken of alles OK is.

Die serial key registratie is _NIET_ te hacken, daar ze domweg alle bestaande keys in een db hebben en deze worden gecheckt door de Server (die onaantastbaar is voor de client). Dus stuurt de client zijn serial naar de server en dan wordt ie pas gechecked of hij klopt. Zodoende kan je niet illegaal spelen, tenzij je de server hackt.

Uit ervaring kan ik vertellen dat er best een hoop server worden gekraakt om met illegale versies op te spelen

[Verwijderd]

Cd-key based spellen zijn onkraakbaar in de manier waarop jij wilt.

Wat je wel kan doen is, het programma dermate aanpassen dat je bijv de authenticatie op de master server omzeilt en dan automatisch naar een gekraakte server redirect.

zo kan je toch spelen MITS de server gekraakt is en de andere spelers ook over gekraakte versies beschikken.

[Verwijderd]

Wat betreft die ftp client.

Denk aan het volgende.

Maar de applicatie afhankelijk van variabele die niet bij het pakket meegelevert worden.

Wanneer je contact maakt met de server laat je doormiddel van een authenticatie (cd key) de variabele ophalen door de ftp client en gebruiken in de applicatie.

De methode is echter ook te kraken.

Het is wel ene lastige, maar werkt wel redelijk

[Woy]

Verwijderd schreef op 09 december 2003 @ 17:01:
Wat betreft die ftp client.

Denk aan het volgende.

Maar de applicatie afhankelijk van variabele die niet bij het pakket meegelevert worden.

Wanneer je contact maakt met de server laat je doormiddel van een authenticatie (cd key) de variabele ophalen door de ftp client en gebruiken in de applicatie.

De methode is echter ook te kraken.

Het is wel ene lastige, maar werkt wel redelijk

Dat lijkt me nou niet echt een moeilijke beveiliging om te kraken. Men neemt een geregistreerde versie en download de gegevens. Verwerkt deze in de gecrackte exe en klaar is kees.

[Verwijderd]

oja, als je dus via je server gaat kijken of een key goed is zet het ip dan hardcode in je app ipv je domein want anders kan je heel makkelijk via hosts het domein naar een andere server laten linken.