[Alg] Safe code

[whoami]

Ik ontdekte net dit artikel op de site van Microsoft:

http://msdn.microsoft.com...SecurityTips/default.mspx

Misschien zijn er mensen die nog security-tips hebben om uw code te 'beveiligen', (of opmerkingen hebben op de tips die hier door MS aangedragen worden).

Ik ben het artikel nog aan het doorlezen, maar heb alvast een opmerking over dit punt:

5. Watch that Crypto Code!
Now let's look at something near and dear to our hearts. I would say that more than 30 percent of the security code we review contains security mistakes. Probably the most common mistake is homegrown encryption code, which is typically quite fragile and easy to break. Never create your own encryption code; you won't get it right. Don't think that just because you've created your own cryptographic algorithm people won't figure it out. Attackers have access to debuggers, and they have both the time and the knowledge to determine exactly how these systems work—and often break them in a matter of hours. Rather, you should use the CryptoAPI for Win32® applications, and the System.Security.Cryptography namespace has a wealth of well-written and well-tested cryptographic algorithms.

Ik vind dat MS hier gewoon reclame maakt. Als een 'home-made' encryptie-algoritme te kraken is, is dat algoritme uit die CryptoAPI ook te kraken, zij het moeilijker...

[Glimi]

Commentaar heb ik wel:
Punt 1 t/m 4 zijn voor mij allemaal gelijk. Ook crossscripting en input die je in query's verwerkt moet je controleren. Da's ook userinput: NOOIT vertrouwen.

Punt 5 heb ik nog nooit iemand zien toepassen Maar ik vermoed dat dit ook te maken heeft met security-trough-obscurity princiepe in het algemeen en niet puur qua cryptografie.

De rest van de punten spreken me wel aan.

[whoami]

Glimi schreef op 13 augustus 2002 @ 14:36:
Commentaar heb ik wel:
Punt 1 t/m 4 zijn voor mij allemaal gelijk. Ook crossscripting en input die je in query's verwerkt moet je controleren. Da's ook userinput: NOOIT vertrouwen.

Hier heb ik dezelfde mening... 't Zal zijn omdat ze geen 3 andere puntjes konden bedenken vermoed ik.

[Zoijar]

whoami schreef op 13 augustus 2002 @ 14:30:
Ik vind dat MS hier gewoon reclame maakt. Als een 'home-made' encryptie-algoritme te kraken is, is dat algoritme uit die CryptoAPI ook te kraken, zij het moeilijker...

Waar slaat dat nou weer op

Bestaande crypto algoritmes(n?) zijn vaak jaren lang van alle kanten door wiskundige aangevallen, en hebben die test doorstaan. Iets "home-made" bevat zeer waarschijnlijk loopholes. Zo denken heel veel mensen bv dat het veiliger wordt als je vaker encrypt oid (2x rsa over elkaar) waar het dus juist minder veilig van wordt. Of dat hun eigen gemaakte XOR encryptie onkraakbaar is (muv one-time pad dat ook echt onkraakbaar is), terwijl je dat weer heel makkelijk kan analyseren met karakter frequentie tabellen.

[whoami]

Zoijar schreef op 13 augustus 2002 @ 14:52:
[...]

Waar slaat dat nou weer op

Bestaande crypto algoritmes(n?) zijn vaak jaren lang van alle kanten door wiskundige aangevallen, en hebben die test doorstaan. Iets "home-made" bevat zeer waarschijnlijk loopholes. Zo denken heel veel mensen bv dat het veiliger wordt als je vaker encrypt oid (2x rsa over elkaar) waar het dus juist minder veilig van wordt. Of dat hun eigen gemaakte XOR encryptie onkraakbaar is (muv one-time pad dat ook echt onkraakbaar is), terwijl je dat weer heel makkelijk kan analyseren met karakter frequentie tabellen.

Ja, idd. Dat wou ik ook vermelden in m'n post (dat die bestaande algoritmes moeilijker te kraken zijn), maar het kwam blijkbaar niet goed over.
Ik wou gewoon zeggen dat die crypto algoritmes ook wel te kraken zijn, maar dat het idd meer moeite zal kosten om die te kraken dan een 'home-made' te kraken.

[Zoijar]

Nou... ik zou niet willen zeggen dat bv RSA of 3DES echt te kraken zijn. Theoretisch natuurlijk wel, dan is alles te kraken zolang je key kleiner is dan je plaintext (!)
Maar... om nou te stellen dat het alleen "iets meer moeite" zal kosten...ik heb bv nog nooit gehoord dat er internet bankieren is gekraakt, of een pinpas

[Verwijderd]

Misschien een leuke uitdaging?

• Ik schrijf een "homegrown" crypto-algoritme, gebaseerd op simpele transformaties zoals XOR en caesar.
• Ik versleutel een jullie onbekende nederlandse tekst en post die hier.
• Jullie leveren me binnen een paar uur de originele tekst.

[Glimi]

Zoijar schreef op 13 augustus 2002 @ 14:52:
[...]

Waar slaat dat nou weer op

Bestaande crypto algoritmes(n?) zijn vaak jaren lang van alle kanten door wiskundige aangevallen, en hebben die test doorstaan. Iets "home-made" bevat zeer waarschijnlijk loopholes. Zo denken heel veel mensen bv dat het veiliger wordt als je vaker encrypt oid (2x rsa over elkaar) waar het dus juist minder veilig van wordt.

Och, 2 of zelfs 6 voudige encryptie kan juist! de boel extra sterk maken, je moet alleen weten waarneer. Bijv Enigma was een 6 voudige encryptie van een substitutie alfabet. Later is er zelfs 8 van gemaakt, en het is alleen! gekraakt omdat men mechanische mankamenten van de machine gevonden heeft ( de startpositie van de enigmawheels werdt voor een groot deel versleutelt dmv één wheel, dit is later gefixt door de wheel meer inkepingen te geven )

Of dat hun eigen gemaakte XOR encryptie onkraakbaar is (muv one-time pad dat ook echt onkraakbaar is), terwijl je dat weer heel makkelijk kan analyseren met karakter frequentie tabellen.

Karakter analyse is echt uitermate zwak, vooral omdat je normaal gesproken werkt dmv blokcyphers. Stel je neemt een block van 3 letters, dan kan je "THE" nog erop gaan matchen (en heb je een flinke kans) maar matchen op 8 letters ( 8x8 = 64 bits == 3DES dacht ik) wordt al nagenoeg onmogelijk.

Echter je punt blijft helemaal overeind staan. Natuurlijk zijn de algoritmes die getest zijn beter dan die home made zut. Echter wat nog veel enger is mensen die dingen ongecodeerd in het registery dumpen of bijv in een gare directory zut dumpen die geheim moet blijven

[whoami]

Zoijar schreef op 13 augustus 2002 @ 15:00:
Nou... ik zou niet willen zeggen dat bv RSA of 3DES echt te kraken zijn. Theoretisch natuurlijk wel, dan is alles te kraken zolang je key kleiner is dan je plaintext (!)
Maar... om nou te stellen dat het alleen "iets meer moeite" zal kosten...ik heb bv nog nooit gehoord dat er internet bankieren is gekraakt, of een pinpas

Ik heb onlangs toch op Canvas een reportage gezien waar toch wel rare dingen met Bancontact etc... aan het licht zijn gekomen, terwijl de mensen van Bancontact zelf beweren dat hun systeem onkraakbaar is.

[Alarmnummer]

Er stond laatst een heel leuk stop ergens op het internet. Ze maakten gebruik van bacterieen om hele krachtige berekeningen te doen. De kracht van bacterieen zit hem in zijn aantal (en voorplantingsvermogen), en als je dat goed weet te gebruiken dan kan bv zeer grote priemgetallen bepalen.

Als iemand dus nog schimmels moet hebben, dan heb ik er nog wel een paar op mijn buro staan in een beker

[Glimi]

Verwijderd schreef op 13 augustus 2002 @ 15:00:
Misschien een leuke uitdaging?

• Ik schrijf een "homegrown" crypto-algoritme, gebaseerd op simpele transformaties zoals XOR en caesar.
• Ik versleutel een jullie onbekende nederlandse tekst en post die hier.
• Jullie leveren me binnen een paar uur de originele tekst.

Als ik gewoon een binary heb, dan zou het met de debugger eraan nog langer duren dan een dag. Ga je gewoon ceasar met wat handigheidjes doen (bijv PlayFair oid) dan kan ik ook nog vrolijk cryptoanalystisch gaan aanvallen, maar het belangrijkste is dat men weet (of er achter kan komen) welk algoritme gebruikt is (en dat moet lukken met de debugger)

[whoami]

Verwijderd schreef op 13 augustus 2002 @ 15:00:
Misschien een leuke uitdaging?

• Ik schrijf een "homegrown" crypto-algoritme, gebaseerd op simpele transformaties zoals XOR en caesar.
• Ik versleutel een jullie onbekende nederlandse tekst en post die hier.
• Jullie leveren me binnen een paar uur de originele tekst.

Ik wil ook wel een versleutelde tekst hier posten. Ik wil zelfs een linkje posten naar het crypt-programmatje waarmee de string versleuteld is dat m'n home-made algoritme bevat.

[Sponge]

Hmm, ik heb ooit eens wat dingen neergezet op een forum voor multiplayer programming. Deze regels gelden eigenlijk voor client-Server dus. Maar aangezien dat de toekomst is (volgens MS), zal ik ze hier alsnog posten. Misschien redelijk offtopic, en ook niet helemaal relevant, maar toch interessant om rekening mee te houden. Stel je een multiplayer game voor waar je met een simpele geheugen editor gewoon je ammo/health mee kunt 'locken'? Met zo een soort programma heb ik al vaak dingen uitgehaald die 'volgens de wet van een programma' niet mochten(, niet in online games hoor )

-Packets encrypten
-(belangrijke) variabelen ALTIJD coderen (bijv simpele xor)
-Server bepaald alles(!)
-CRC32 op belangrijke/kritische databestanden
-Eventueel nog variabelen op andere posities (pointers) alloceren, dan de vorige keer, als het programma starten.

minstens de helft van programma's die nu bestaan kan je direct manipuleren met een 'geheugen editor'

[Verwijderd]

Glimi schreef op 13 augustus 2002 @ 15:05:
Als ik gewoon een binary heb, dan zou het met de debugger eraan nog langer duren dan een dag.

Als je gewoon de binary hebt, dan haal je de gecodeerde tekst door die binary en heb je gewonnen, ik ga geen public-key systeem in elkaar flansen

Ga je gewoon ceasar met wat handigheidjes doen (bijv PlayFair oid) dan kan ik ook nog vrolijk cryptoanalystisch gaan aanvallen

Caesars met variable skips zijn best lastig te attacken, omdat je niks hebt aan frequentieverdelingen. Gooi daar een variabele XOR-mask over die niet op byte-grenzen ophoudt, en het is al een behoorlijk karwei.

[whoami]

41.6C.6D.61.72 schreef op 13 augustus 2002 @ 15:11:
Hmm, ik heb ooit eens wat dingen neergezet op een forum voor multiplayer programming. Deze regels gelden eigenlijk voor client-Server dus. Maar aangezien dat de toekomst is (volgens MS), zal ik ze hier alsnog posten. Misschien redelijk offtopic, en ook niet helemaal relevant, maar toch interessant om rekening mee te houden. Stel je een multiplayer game voor waar je met een simpele geheugen editor gewoon je ammo/health mee kunt 'locken'? Met zo een soort programma heb ik al vaak dingen uitgehaald die 'volgens de wet van een programma' niet mochten(, niet in online games hoor )


minstens de helft van programma's die nu bestaan kan je direct manipuleren met een 'geheugen editor'

Idd, ik heb ook nog m'n Warcraft save-games ge-edit zodat ik m'n hout en goud inventarissen kon opkrikken.

[weerdo]

Moeten jullie het puntje wat wordt aangehaald wel goed lezen:

Never create your own encryption code; you won't get it right. Don't think that just because you've created your own cryptographic algorithm people won't figure it out. Attackers have access to debuggers, and they have both the time and the knowledge to determine exactly how these systems work—and often break them in a matter of hours.

Oftwel, home grown code om gegevens te coderen zijn vaak in no time te reverse engineren.

Kenmerk van een goede encryptie-code is dat de teksten die deze code uitspuwt moeilijk te kraken blijft, ook al is de sourcecode van de procedure om van plain text naar encrypted tekst te gaan bekend.

[Verwijderd]

Ik heb thuis een boek over encryptie.

Het is op zich wel te doen, maar er van uitgaande dat de tegenpartij enorm ervaren mensen zijn, is het beter om een bestaande te nemen.

Maar als je veel vrije tijd hebt. Go for it!

[Glimi]

Verwijderd schreef op 13 augustus 2002 @ 15:11:
Als je gewoon de binary hebt, dan haal je de gecodeerde tekst door die binary en heb je gewonnen, ik ga geen public-key systeem in elkaar flansen

Ik bedoel eerder proggies die ww versleutelen met hun eigen algoritme

Caesars met variable skips zijn best lastig te attacken, omdat je niks hebt aan frequentieverdelingen. Gooi daar een variabele XOR-mask over die niet op byte-grenzen ophoudt, en het is al een behoorlijk karwei.

Variabele skips? Je bedoelt als het ware een 'boek' versleuteling? Of bedoel je caesars met gewoon om de letter een x aantal waardes positions verder waarbij X random is?

Boekversleutelingen zijn aan te pakken door te gaan matchen op trigrammen (THE, THA ed. ) die veel voorkomen
Random skips zijn naar, bijna net zo naar als enigma, en dan zul je moeten gaan aanvallen op je code ipv je algoritme.

[LuCarD]

Verwijderd schreef op 13 augustus 2002 @ 15:00:
Misschien een leuke uitdaging?

• Ik schrijf een "homegrown" crypto-algoritme, gebaseerd op simpele transformaties zoals XOR en caesar.
• Ik versleutel een jullie onbekende nederlandse tekst en post die hier.
• Jullie leveren me binnen een paar uur de originele tekst.

Ik denk dat iedereen wel eens op een blauwe maandag een encryptie decryptie methode heeft gemaakt....

[Zoijar]

Ik probeerde niet te zeggen dat home-made encryptie altijd kraakbaar is, alleen dat de kans veel groter is. En dat bedoelde de schrijver van het MSDN artikel ook. Natuurlijk is 3DES ook "gewoon" een combinatie van transpositie en substitutie.
Het gaat erom dat er toch vaak loopholes in homde-made zitten, dus dat je kan decoderen op een andere manier dan je zou verwachten. Iedereen dacht ook dat DES erg veilig was vroeger. Merkle-Hellman was ook gebaseerd op een NP hard probleem (knapsacks), maar bleek toch kraakbaar.
En zoals altijd gaat het erom hoe veilig je data moet zijn. De save games van een spel kan je best wel met een home-made transpositie/substitutie cypher doen. Maar zou je dat ook doen bij het missile control system van een nuclear sub? Toch wel eng. Stel dat ik de cyphertext nog 234581 keer encrypt, en er dan toevallig weer precies de plaintext uit komt rollen Of iets heel anders, je seed je randomizer op je klok elke keer als je een key genereert, en zo kan je met de file timestamp op je key de search space dusdanig verkleinen dat het kraakbaar wordt. Dat soort dingen gaat het om.

Dat van die bacterien is wel interesting... misschien toch is stofzuigen

[Woy]

Zoijar schreef op 13 augustus 2002 @ 15:22:
Dat van die bacterien is wel interesting... misschien toch is stofzuigen

Hehe ja inderdaad een goed idee anders beginnen er mischien wel een aantal bacterien op je kamer zelfstandig je encryptie te breken

[Verwijderd]

Glimi schreef op 13 augustus 2002 @ 15:20:
Variabele skips? Je bedoelt als het ware een 'boek' versleuteling? Of bedoel je caesars met gewoon om de letter een x aantal waardes positions verder waarbij X random is?

Ik bedoel geen boekversleuteling, maar dat de skip voor elk te coderen symbool opnieuw bepaald wordt adhv. een pseudo Random Number Generator.

Random skips zijn naar, bijna net zo naar als enigma, en dan zul je moeten gaan aanvallen op je code ipv je algoritme.

Exact, als je dus zeker weet dat de tegenpartij je algoritme niet in handen krijgt en het alleen moet doen met de cyphertext, een eenvoudig algoritme toch voor een hoop hoofdbrekers kan zorgen.

[Glimi]

Verwijderd schreef op 13 augustus 2002 @ 16:14:
Exact, als je dus zeker weet dat de tegenpartij je algoritme niet in handen krijgt en het alleen moet doen met de cyphertext, een eenvoudig algoritme toch voor een hoop hoofdbrekers kan zorgen.

Dat geloof ik graag, maar daaraan mag je een algoritme niet afmeten! Je kan het pas veilig verklaren als het zich houdt als men het algoritme weet en ook cipherteksten heeft (grote hoeveelheden!)

Nu ligt het natuurlijk helemaal aan het soort gebruik ( e-mailen van de string bijv, of het algoritme te gebruiken voor een versleuteling van een pass in een ini ) maar men kan echt BIJNA altijd aan het algortime komen door jouw progje gewoon in debug mode te draaien.

[edit] In dit geval zou ik trouwens eens gaan kijken naar de pseudo random generator. Als mensen die zelf gaan schrijven gaat het echt fout denk ik

[LuCarD]

Verwijderd schreef op 13 augustus 2002 @ 16:14:
[...]


Ik bedoel geen boekversleuteling, maar dat de skip voor elk te coderen symbool opnieuw bepaald wordt adhv. een pseudo Random Number Generator.

* LuCarD heeft het nu zo dat een logische volgorde word gebruikt, die elke keer verschilt aan de hand van het wachtwoord.

Echt random maakt de code meestal simpeler om te kraken.

Exact, als je dus zeker weet dat de tegenpartij je algoritme niet in handen krijgt en het alleen moet doen met de cyphertext, een eenvoudig algoritme toch voor een hoop hoofdbrekers kan zorgen.

Maar als een algoritme eenmaal gevonden is kan je gelijk je beveiliging weg gooien. Nee de encryptie moet zo zijn, dat zelfs als je het algoritme hebt. Je de orginele tekst niet zo simpel kan terug krijgen (zonder password natuurlijk )

[ Voor 0% gewijzigd door LuCarD op 13-08-2002 16:22 . Reden: Woorden toegevoegd ]

[Glimi]

LuCarD schreef op 13 augustus 2002 @ 16:21:
* LuCarD heeft het nu zo dat een logische volgorde word gebruikt, die elke keer verschilt aan de hand van het wachtwoord.

Echt random maakt de code meestal simpeler om te kraken.

Nee! aan de hand van een wachtwoord zeg je! Dat zorgt ervoor dat men grote stukken ciphercode kan ontvangen in depth! En dat maakt het nog veel enger. Random maakt juist de versleuteling ontzettend sterk/onkraakbaar omdat de key even groot is als de tekst

[LuCarD]

Glimi schreef op 13 augustus 2002 @ 16:24:
[...]

Nee! aan de hand van een wachtwoord zeg je! Dat zorgt ervoor dat men grote stukken ciphercode kan ontvangen in depth! En dat maakt het nog veel enger. Random maakt juist de versleuteling ontzettend sterk/onkraakbaar omdat de key even groot is als de tekst

Ben ik het niet mee eens, random waardes kan je er zo uit filteren door encryptie meerdere malen te herhalen. Dat geeft weer te veel info over de orginele tekst.

[Glimi]

LuCarD schreef op 13 augustus 2002 @ 16:30:
Ben ik het niet mee eens, random waardes kan je er zo uit filteren door encryptie meerdere malen te herhalen. Dat geeft weer te veel info over de orginele tekst.

Hoe voer je die encryptie nog maals uit dan als jij niet die waardes hebt

[.oisyn]

41.6C.6D.61.72 schreef op 13 augustus 2002 @ 15:11:
Hmm, ik heb ooit eens wat dingen neergezet op een forum voor multiplayer programming. Deze regels gelden eigenlijk voor client-Server dus. Maar aangezien dat de toekomst is (volgens MS), zal ik ze hier alsnog posten. Misschien redelijk offtopic, en ook niet helemaal relevant, maar toch interessant om rekening mee te houden. Stel je een multiplayer game voor waar je met een simpele geheugen editor gewoon je ammo/health mee kunt 'locken'? Met zo een soort programma heb ik al vaak dingen uitgehaald die 'volgens de wet van een programma' niet mochten(, niet in online games hoor )

-Packets encrypten
-(belangrijke) variabelen ALTIJD coderen (bijv simpele xor)
-Server bepaald alles(!)
-CRC32 op belangrijke/kritische databestanden
-Eventueel nog variabelen op andere posities (pointers) alloceren, dan de vorige keer, als het programma starten.

minstens de helft van programma's die nu bestaan kan je direct manipuleren met een 'geheugen editor'

Dat zijn spellen waarbij de taak veel te veel bij de client ligt (zie het oude counter strike). Als je de client laat bepalen of je ammo op is tijdens het schieten is het ook simpel om dat te patchen zodat je ammo nooit op raakt.
Als je echter gewoon de client tegen de server laat zeggen 'schietknop is ingedrukt' (zie bijvoorbeeld quake) dan valt er niets meer (op die manier) te cheaten, aangezien de server alles regelt (wat ie ook hoort te doen)

De enige cheatmogelijkheden bij een goed ontworpen multiplayer spel zijn visualisatie en reactie cheats, waar in principe niets tegen te doen is aangezien dat altijd uit code bestaat die op de client uitgevoerd moet worden (of je moet een terminal sessie gaan draaien )

[Reptile209]

(Leuk draadje zo!)
Ik heb inderdaad ooit eens een password encryptie geschreven dat bedoeld is om het password te controleren met de hash van het origineel. Dit is de functie: (TurboPascal 7.0 for DOS )

code:

const CodeLength = 8;

FUNCTION EncodePassword (Tekst : string): string;
VAR
  Uit    : string[CodeLength];
  n      : integer;
  Factor : integer;
begin
  for n := 1 to CodeLength do
  begin
    Factor := length(Tekst)-n;
    {
    Bij ieder teken in Tekst wordt zijn positie in de string (n) opgeteld.
    Dit getal wordt dan ge-XOR-d met de Tekstlengte - huidige positie (n),
    samen Factor.
    Als er geen nieuwe tekens meer in de string zijn, maar CodeLength is nog
    niet bereikt, dan worden de eerste tekens opnieuw gebruikt.
    }
    IF n <= length(Tekst) then
      uit[n] := chr( (ord(Tekst[n]) + n) xor Factor)
    else
      uit[n] := chr( (ord( Tekst[ (n mod length(tekst))+1 ] ) +n) xor Factor);
  end;

  uit[0] := chr(CodeLength);
  EncodePassword := uit;
end;

('t zal geen hele nette code zijn, maar het werkt...)
Hoe "veilig" is zo iets nou volgens jullie? Ofwel: kan je uit een hash het originele password weer terughalen opbasis van deze info en de hash?

edit:
Er komt dus een code uit met lengte CodeLength, ongeacht de lengte van de invoer

[Verwijderd]

Quote from article : ".... Never create your own encryption code; you won't get it right ..."

ja. . zeg. . .dit is goed voor mijn ego . . .alsof ik zelf niks kan, en alsof M$ alles kan . .ondertussen is gebleken dat je vaak NIET de code van M$ moet hebben, maar dat je beter zelf iets kunt maken . ..

[LuCarD]

Glimi schreef op 13 augustus 2002 @ 16:34:
[...]

Hoe voer je die encryptie nog maals uit dan als jij niet die waardes hebt

Ik ga er van uit de persoon het algoritme heeft of de applicatie waarmee geencrypt tot zijn beschikking heeft.


Maar zie dit topic... (eentje uit de oude doos van mij)
Home-made encryptie kraken?/

[Glimi]

LuCarD schreef op 13 augustus 2002 @ 16:47:
Ik ga er van uit de persoon het algoritme heeft of de applicatie waarmee geencrypt tot zijn beschikking heeft.

Maar de key is telkens anders, dus ik kom er nog steeds niet helemaal uit wat je bedoelt

[edit]Maar ik ben dan ook niet zo'n ster met dit soort dingen

[LuCarD]

Glimi schreef op 13 augustus 2002 @ 16:49:
[...]
Maar de key is telkens anders, dus ik kom er nog steeds niet helemaal uit wat je bedoelt

[edit]Maar ik ben dan ook niet zo'n ster met dit soort dingen

Ik ook niet.. maar dat maakt het niet minder leuk.....

Maar lees dit maar eens... dusty in "Home-made encryptie kraken?"

[weerdo]

Reptile209 schreef op 13 augustus 2002 @ 16:43:
Hoe "veilig" is zo iets nou volgens jullie? Ofwel: kan je uit een hash het originele password weer terughalen opbasis van deze info en de hash?

edit:
Er komt dus een code uit met lengte CodeLength, ongeacht de lengte van de invoer

Jouw algoritme is het efficientst als je CodeLength kort is en het wachtwoord lang is.

Als het wachtwoord korter of gelijk is aan de CodeLength kan het wachtwoord volledig teruggehaald worden. Kwestie van de bewerking omgekeerd uitvoeren.

Wanneer het wachtwoord langer is dan de CodeLength, kan je een aanval uitproberen waarbij telkens op langere wachtwoorden wordt gezocht.

[weerdo]

Verwijderd schreef op 13 augustus 2002 @ 16:45:
ja. . zeg. . .dit is goed voor mijn ego . . .alsof ik zelf niks kan, en alsof M$ alles kan . .ondertussen is gebleken dat je vaak NIET de code van M$ moet hebben, maar dat je beter zelf iets kunt maken . ..

Niet alleen Microsoft predikt het gebruik van standaard encryptie algoritmes. In de Open Source wereld word je afgemaakt als je gebruik maakt van eigen encryptie-algoritmes.

Lees anders http://www.interhack.net/people/cmcurtin/snake-oil-faq.html eens door.

[Zoijar]

.oisyn schreef op 13 augustus 2002 @ 16:37:
De enige cheatmogelijkheden bij een goed ontworpen multiplayer spel zijn visualisatie en reactie cheats, waar in principe niets tegen te doen is aangezien dat altijd uit code bestaat die op de client uitgevoerd moet worden (of je moet een terminal sessie gaan draaien )

Je kan er wel wat dingen tegen doen. Bijvoorbeeld dat de server simpel bepaalt of iemand anders mogelijk zichtbaar is voor jou of niet (in een 16 player CS is dit nog wel te doen) en als dat niet zo is je geen info van die speler sturen.

Je encryptie op je packets kan altijd gekraakt worden, dat is een probleem. Maar je kan wel wat leuke truckjes uithalen door bv sequence numbers te checken op je packets. Als die niet matchen dan krijgt de client geen fout oid, maar weet de server dat er gecheat wordt. Dan kan iemand ineens op magische wijzen gedisconnect worden, bv 10min later. Dat soort checks in een multi threaded environment zijn zo lastig om te reverse engineeren

[styno]

weerdo schreef op 13 augustus 2002 @ 17:04:

Niet alleen Microsoft predikt het gebruik van standaard encryptie algoritmes. In de Open Source wereld word je afgemaakt als je gebruik maakt van eigen encryptie-algoritmes.

Lees anders http://www.interhack.net/people/cmcurtin/snake-oil-faq.html eens door.

Zoals al eerder werd opgemerkt; het is gewoon leuk om zelf een encryptie algoritme te bedenken. En ik durf (IHMO) te beweren dat er best vrij simpele manieren zijn om een krachtige encryptie te krijgen.

Zelf heb ik ook een keer een encryptie methode geschreven. Deze maakt gebruik van bestanden (bijv mp3'tjes of executables etc.) om een bericht te encrypten. Als dan degene, naar wie het bericht opgestuurd wordt, dit wil decrypten moet hij/zij alleen het juiste mp3 bestand hebben. Zonder het mp3'tje is het origineel niet terug te krijgen, zelfs als de source code van de encryptie/decryptie software bekend is.

Een paar maanden geleden zijn een paar wetenschappers in het nieuws gekomen die eenzelfde soort encryptie hadden bedacht. Het enige verschil is dat zij van satteliet signalen gebruik maken om een bericht te encrypten.

Ik wil de source wel mailen aan iedereen die belangstelling heeft...

[martinvw]

Styno schreef op 13 augustus 2002 @ 17:31:
[...]


Zoals al eerder werd opgemerkt; het is gewoon leuk om zelf een encryptie algoritme te bedenken. En ik durf (IHMO) te beweren dat er best vrij simpele manieren zijn om een krachtige encryptie te krijgen.

Zelf heb ik ook een keer een encryptie methode geschreven. Deze maakt gebruik van bestanden (bijv mp3'tjes of executables etc.) om een bericht te encrypten. Als dan degene, naar wie het bericht opgestuurd wordt, dit wil decrypten moet hij/zij alleen het juiste mp3 bestand hebben. Zonder het mp3'tje is het origineel niet terug te krijgen, zelfs als de source code van de encryptie/decryptie software bekend is.

Een paar maanden geleden zijn een paar wetenschappers in het nieuws gekomen die eenzelfde soort encryptie hadden bedacht. Het enige verschil is dat zij van satteliet signalen gebruik maken om een bericht te encrypten.

Ik wil de source wel mailen aan iedereen die belangstelling heeft...

Klinkt leuk, gooi maar op de mail
mvwinger at yahoo.com

[.oisyn]

dat lijkt me idd een goede (en vrijwel onkraakbare) manier, puur omdat je een enorm grote key hebt. Maar je moet wel de goede bestanden gebruiken, er moet namelijk geen patroon oid in zitten

[Zoijar]

Ja, je kan gewoon je bit string XOR-en met de bits van een MP3tje. Dat is onkraakbaar als er geen rare patronen in de mp3 zitten (maar dat zitten er iha wel, bv stiltes aan het begin/eind etc)

Deze link is ook wel leuk trouwens: Hier

[styno]

Zoijar schreef op 13 augustus 2002 @ 17:39:
Ja, je kan gewoon je bit string XOR-en met de bits van een MP3tje. Dat is onkraakbaar als er geen rare patronen in de mp3 zitten (maar dat zitten er iha wel, bv stiltes aan het begin/eind etc)

De methode bestaat uit het vervangen van characters uit het te versleutelen bericht met overeenkomende characters uit een mp3tje. Dit doe je natuurlijk niet lekkerlijk, maar door offsets tussen de characters uit het mp3'tje op te geven. In het versleutelde bericht staan dus alleen maar getallen die te maken hebben met afstanden in een bepaald mp3'tje. Zonder het mp3'tje heb je daar helemaal niks aan.

Aan het einde van het mp3'tje wordt gewoon weer verder getelt vanaf het begin, hierdoor onstaat zo nu en dan een grotere offset doordat het begin en eind van een mp3'tje uit een heleboel dezelfde characters bestaan, maar omdat het dus offsets zijn heb je daar nog steeds niks aan, behalve dan dat je kunt concluderen dat het bestand waarmee het bericht encrypted is een mp3 bestand is. Ik weet niet of je die conclusie zomaar mag trekken en zo ja dan heb je daar in mijn ogen nog niet zoveel aan lijkt mij.

[styno]

M4rt1nvW schreef op 13 augustus 2002 @ 17:34:
Klinkt leuk, gooi maar op de mail
mvwinger at yahoo.com

hmmm, source ligt thuis en thuis heb ik geen internet (nou ja via een modem dan, maar dat telt niet ), zal het morgen wel ff op de mail zetten. Tis trouwens een beetje kale code in C, was van plan er een plugin voor te maken voor Outlook ofzo. Maar dan moet je wel weten hoe je een plugin moet maken...

Iemand een ideetje of een link??

[weerdo]

Styno schreef op 13 augustus 2002 @ 17:31:
Zoals al eerder werd opgemerkt; het is gewoon leuk om zelf een encryptie algoritme te bedenken. En ik durf (IHMO) te beweren dat er best vrij simpele manieren zijn om een krachtige encryptie te krijgen.

Mijn reactie was op iemand gericht die het zo nodig vond om de naam van een softwareleverancier creatief te spellen.

Zelf heb ik ook een keer een encryptie methode geschreven. Deze maakt gebruik van bestanden (bijv mp3'tjes of executables etc.) om een bericht te encrypten. Als dan degene, naar wie het bericht opgestuurd wordt, dit wil decrypten moet hij/zij alleen het juiste mp3 bestand hebben. Zonder het mp3'tje is het origineel niet terug te krijgen, zelfs als de source code van de encryptie/decryptie software bekend is.

Principe is interessant.

Moet je ook nog een aanvullend wachtwoord intikken voordat de feitelijke encryptie begint of is het alleen het bezit van het bestand noodzakelijk?

[styno]

weerdo schreef op 13 augustus 2002 @ 18:15:
Principe is interessant.

thanx

Moet je ook nog een aanvullend wachtwoord intikken voordat de feitelijke encryptie begint of is het alleen het bezit van het bestand noodzakelijk?

Nope, geen wachtwoord nodig. Alleen het goeie referentie bestand opgeven, anders komt er rotzooi uit.

Ik zat te denken dat je een lijstje aanmaakt waarin je opgeeft welk persoon aan welk bestand koppelt. Daar zou dan wel weer een wachtwoord op kunnen, maar dat soort UI dingen kun je op een heleboel verschillenden manieren oplossen.

[weerdo]

Styno schreef op 13 augustus 2002 @ 18:21:
Nope, geen wachtwoord nodig. Alleen het goeie referentie bestand opgeven, anders komt er rotzooi uit.

Dus op het moment dat ik toegang heb tot al jouw gegevens, heb ik een gerede kans om door bruut alle data-gegevens uit te proberen jouw bestand te kraken..

Ik zat te denken dat je een lijstje aanmaakt waarin je opgeeft welk persoon aan welk bestand koppelt. Daar zou dan wel weer een wachtwoord op kunnen, maar dat soort UI dingen kun je op een heleboel verschillenden manieren oplossen.

Dat is in mijn ogen NIET de juiste oplossing. Op het moment dat ik de UI passeer (aangezien je de source ook hebt) ben je weer kwetsbaar.

Je encryptie-algoritme is gebaseerd op bezit van het mp3'tje. Ik zou zeker overwegen om een kennisdeel in overweging te nemen. Als je de mp3 eerst met een door de gebruiker gekozen wachtwoord/passphrase hasht, en deze gebruikt om het doelbestand te coderen heb ik als buitenstaander aan het mp3tje niet meer voldoende.

Dan wordt het heel wat lastiger om bestanden welke met jouw algoritme gecodeerd zijn te kraken..

[styno]

weerdo schreef op 13 augustus 2002 @ 18:31:

Dus op het moment dat ik toegang heb tot al jouw gegevens, heb ik een gerede kans om door bruut alle data-gegevens uit te proberen jouw bestand te kraken..

Zo werkt dat toch bijna altijd? Ik weet niet hoe bijvoorbeeld PGP de private key bewaard maar als ik ingebroken heb op de computer waar deze key is opgeslagen dan kan ik toch ook alle gecodeerde berichten kraken? Bovendien moet je (met mijn methode) dan wel alle (60 GB+ aan mp3'tjes, executables, films en alle andere binaire bestanden) door de decoder trekken... Dat wordt decoderen, controlleren of de output leesbaar is en dat elke keer voor elk mogelijk bestand. Das een boel werk, want je wordt niet gewaarschuwd wanneer de sleutel goed blijkt te zijn, dus je zult elke keer het resultaat moeten beoordelen (misschien iets voor een statistische tool??).

Je encryptie-algoritme is gebaseerd op bezit van het mp3'tje. Ik zou zeker overwegen om een kennisdeel in overweging te nemen. Als je de mp3 eerst met een door de gebruiker gekozen wachtwoord/passphrase hasht, en deze gebruikt om het doelbestand te coderen heb ik als buitenstaander aan het mp3tje niet meer voldoende.

Deze sleutel wordt toch meestal ook weer ergens opgeslagen? Of onthou je elk wachtwoord of, ik noem maar wat, 64bits sleutel?

De mogelijkheid om het bericht te kraken als je volledige toegang hebt tot de pc wordt idd erg groot, maar ik vermoed dat in de praktijk blijkt dat dat met praktisch elke encryptie methode zo is.

[pjonk]

Ik kreeg laatst een mailtje over software protectie, daar stonden onder andere de volgende punten in:

Mark's famous 14 protector's commandments
1 Never use meaningful file or procedure names such as IsValidSerialNum (duh.) If you do use functions for checking purposes, place at least some required code that your program really needs, in such a function. When the cracker disables the function, the program will produce incorrect results.

2 Don't warn the user right after a violation is made. Wait later, maybe until the next day or two (crackers hate that).

3 Use checksums in DLL's and in the EXE. Have them check each other. Not perfect but it just makes it harder to crack.

4 Pause a second or two after a password entry to make brute force cracking unfeasible. Simple to do, but rarely done.

5 Self-heal your software. You know, error correction like modems and hard drives use. The technology has been around for years, and no one uses it on their software? The best thing about this is that if the cracker used a decompiler, they may be looking at a listing that is no longer valid.

6 Patch your own software. Change your code to call different validation routines each time. Beat us at our own game.

7 Store serial numbers in unlikely places, like as a property of a database field.

8 Store serial numbers in several places

9 Don't rely on the system date. Get the date of several files, like SYSTEM.DAT, SYSTEM,DA0 and BOOTLOG.TXT and compare them to the system date. Require that the time be greater than the last run.

A Don't use literal strings that tell the user that their time is expired. These are the first things to look for. Build strings dynamically or use encryption.

B Flood the cracker with bogus calls and hard-coded strings. Decoys are fun.

C Don't use a validation function. Every time you validate the user, write your validation code inline with the current process. That just makes more cracking for the cracker.

D When using hard-coded keys or passwords, make them look like program code or function calls (i.e., "73AF" or "GetWindowText"). This actually works very well and confuses some decompilers.

E Finally, never reveal your best protection secrets :-)

[styno]

JonkieXL schreef op 13 augustus 2002 @ 19:06:
E Finally, never reveal your best protection secrets :-)

HA! die is pas goed.

[Sponge]

Ja, ik wou ook nog toevoegen dat runtimes funest zijn (zoals bij VB)

Ik heb bijvoorbeeld wat sites die ik gezien heb die over "hackign vb" gaan. (Ik post de URL's dan hier ook niet ,hoe informatief ze dan ook zijn, want eigenlijk zou je kunnen zeggen dat het illegaal is om te doen, maar niet om te lezen.. (om m'n eigen programs te beveiligen) twijfel geval!)..

In vb heb je bijvoorbeeld dus die calls naar de runtime, vbaStrCompare volgens mij, voor string compare. Met een decompiler schijnt het dat je die calls gewoon opzoekt, even kijkt wat er ervoor gebeurd in de registers, en veranderen maar!

[styno]

41.6C.6D.61.72 schreef op 13 augustus 2002 @ 19:21:
In vb heb je bijvoorbeeld dus die calls naar de runtime, vbaStrCompare volgens mij, voor string compare. Met een decompiler schijnt het dat je die calls gewoon opzoekt, even kijkt wat er ervoor gebeurd in de registers, en veranderen maar!

Tja, dat wordt dus zelf een string compare functietje bouwen....

[Woy]

Inderdaad door runtimes is het veel makkelijker om dingen te cracken. Java en C# enzo zijn zeer makkelijk te decompilen. Het enige wat hiermee zo'n beetje verloren gaat zijn een aantal variable namen.

[.oisyn]

rwb schreef op 13 augustus 2002 @ 19:25:
Inderdaad door runtimes is het veel makkelijker om dingen te cracken. Java en C# enzo zijn zeer makkelijk te decompilen. Het enige wat hiermee zo'n beetje verloren gaat zijn een aantal variable namen.

dat Java en C# makkelijk te decompilen zijn heeft niets te maken met runtimes, maar puur omdat de bytecode (java) en de intermediate language (.NET) bijna een 1-op-1 vertaling is van de code, in tegenstelling tot machinecode gegenereerd bij C(++), Delphi en VB proggies (en dan bedoel ik de native versie van VB, niet de P-Code )

Plus alle klasse, methode en variabele-namen blijven bewaard (behalve lokale vars)

[Sponge]

bij VB.NET is/was het helmaal erg. Ik kreeg van iemand o peen forum de decompiled versie, en kon op 1 a 2 regels na alles in elkaar zetten zonder dat ik zelfs VB.NET ooit gebruikt heb. Ik hoop dat dit wel tegen te gaan is op een of andere manier.. helaas is de forum provider verdwenen en zijn die posts getrashed op dit moment..

[weerdo]

Styno schreef op 13 augustus 2002 @ 18:51:
Zo werkt dat toch bijna altijd? Ik weet niet hoe bijvoorbeeld PGP de private key bewaard maar als ik ingebroken heb op de computer waar deze key is opgeslagen dan kan ik toch ook alle gecodeerde berichten kraken?

De gebruiker van PGP dient nog bij elk gebruik zijn passphrase in te tikken om berichten te decoderen PGP cached wachtwoorden tijdens een sessie, maar wordt niet op disk opgeslagen.

Als je de private key hebt, kan je de tijd tot het kraken van een document aanzienlijk inkorten aangezien je wel een behoorlijk deel van de puzzel hebt. Maar desondanks kan het kraken van het privatekey-wachtwoord dagen duren..

Het gaat om de combinatie van kennis (passphrase) en bezit (private key). En jouw algoritme voorziet alleen in dat laatste.

[styno]

Hmmm, het ziet er naar uit dat je daar een sterk punt hebt. Moet ik nog maar eens ff naar gaan kijken.... Thanx

[Infinitive]

Een bitwise XOR van data met een echte random key is niet te kraken zonder die key. In de code-tekst is namelijk geen enkele relatie met de source-text aanwezig. Zelfs brute-force keys uitproberen heeft geen zin want er is geen mogelijkheid om te controleren of je de originele source-tekst wel terug hebt. Dit is alleen een kip en ei probleem want hoe krijg je die key (die net zo groot is als je bericht) veilig bij de ontvanger?

Vandaar dat bij bekende encryptie methoden bepaalde verbanden in de code-tekst toegestaan worden, met de gedachte in het achterhoofd dat het vinden van die verbanden enorm veel tijd kost. Ik heb nog ergens wel een linkje waarin de bekende encryptiemethoden heel opervlakkig worden besproken, maar kan deze helaas niet meer vinden.

Aan de andere kant moet je niet je doel uit het oog verliezen: is de data wel encryptie waard? Is het waarschijnlijk dat jouw data door een expert gekraakt worden en is dat heel erg? Stel dat je wat bedrijfsgegevens XOR'ed met een kleine key die zo in de executable is gebakken. Denk je dan echt dat van dat handjevol werknemers er eentje dat programma mee naar huis neemt om zo'n zoontje van drie het te laten kraken om er zo achter te komen dat zijn collega's een euro meer verdienen?

Wat spelletjes betreft heeft encryptie niet veel zin (zeker wat performace en foutcorrectie betreft). Zoals eerder vermeld is het wel belangrijk dat de server de touwtjes in handen heeft. Maar i.v.m. performance is dat niet altijd even makkelijk te realiseren.

[.oisyn]

Infinitive schreef op 13 augustus 2002 @ 22:58:
Wat spelletjes betreft heeft encryptie niet veel zin (zeker wat performace en foutcorrectie betreft). Zoals eerder vermeld is het wel belangrijk dat de server de touwtjes in handen heeft. Maar i.v.m. performance is dat niet altijd even makkelijk te realiseren.

hier wil ik even op inhaken door te zeggen dat het met goede client-side prediction niet echt een probleem is.

41.6C.6D.61.72 kwam met deze situatie:

code:

user -> client: knop ingedrukt
client: checkt ammo, draait geweer rond
client -> server: schiet kogel van A naar B

dat zou natuurlijk in een veilige situatie moeten zijn

code:

user -> client: knop ingedrukt
client -> server: schietknop ingedrukt
server: checkt ammo, draait geweer rond, schiet nieuwe kogel af
server -> client: geweer draait rond
server -> client: nieuwe bullethole op positie X

maar dit genereert veel dataverkeer (client moet constant op de hoogte worden gebracht van veranderingen in de entities) en het wordt bij een hoge ping slecht speelbaar

Wat veel beter zou zijn is als je de server en client code goed op elkaar instelt, zonder dat je teveel verantwoordelijkheden bij de client legt:

code:

user -> client: knop ingedrukt
client: draait geweer rond, checkt ammo, schiet kogels
client -> server: schietknop ingedrukt
server: schiet kogels, kijkt wie er geraakt worden (op de server
    is er geen ronddraaiend geweer; dat is een visueel element die
    totaal niet relevant is voor de server)
server -> client: eventueel vertellen wie er dood zijn gegaan

Nu kun je in de client code gaan hacken om te zorgen dat de client denkt dat je kogels nog niet op zijn... je schiet er echter niets mee op, want terwijl jij vrolijk door schiet gaat er niemand meer dood omdat de server de kogels niet afschiet.
Bovendien heb je nu heel weinig dataverkeer en blijft het goed speelbaar met een hoge ping

[Zoijar]

Infinitive schreef op 13 augustus 2002 @ 22:58:
Wat spelletjes betreft heeft encryptie niet veel zin (zeker wat performace en foutcorrectie betreft). Zoals eerder vermeld is het wel belangrijk dat de server de touwtjes in handen heeft. Maar i.v.m. performance is dat niet altijd even makkelijk te realiseren.

Encryptie is ook gewenst bij client-server spellen. Zonder dat kan je namelijk te makkelijk er een packet sniffer opzetten en zo allemaal data in handen krijgen die je eigenlijk niet mag weten (6th sense in asherons call bv)
Ook kan je dan zelf packets gaan sturen, en kan je zonder ook maar een regel client code te veranderen een aim-bot maken. Je checked inkomende packets op speler posities, past automatisch direct je eigen positie aan, berekend je aim, en schiet.
Het probleem is dat die encryptie altijd kraakbaar is omdat de code op de client draait. Maar in ieder geval moet je client dan reverse engineered worden. Wat ik eerder al zei is het een goeie truck om bepaalde onduidelijke structuur in je packets op te nemen. Bijvoorbeeld een CRC van een deel code. Zelfs als je de encryptie dan kraakt, en vrolijk aim-bot packets gaat sturen gaat het nog steeds mis. Omdat de server kan zien dat het geen valid packet is. Als hacker is het vrij lastig om dit soort dingen dan te ontdekken. Maar uiteraard altijd mogelijk, aangezien ze in theorie je client van de grond af aan opnieuw kunnen bouwen.
In dit geval heeft encryptie dus het nut van "maak het zo moeilijk en vervelend mogelijk". En uiteraard wijzig je bij elke patch/update je encryptie algoritmen, en hidden packet info.

[Glimi]

Om maar een andere richting in te gaan van 'safe code' is het checken op input, zelfs binnen classes. Neem nou dit

code:

public class Pipo implements Clown {

    private int     _engheidsFactor;

    public Pipo( int engheidsFactor ) {

        setEngheidsFactor( engheidsFactor );
    }

    /**
      * Method to set the Engheidsfactor from Pipo
      * @param engheidsFactor The grade how scary Pipo is
      */
    public void setEngheidsFactor( int engheidsFactor ) {

        switch( engheidsFactor ) {

            Clown.HEEL_ENG:
            Clown.NIET_ENG:
                
                _engheidsFactor = engheidsFactor;
                break;

            Default:
                throw new IllegalArgumentException( "Engheidsfactor is not one of the constants defined in the Clown Interface" );
        }

    }
    
    public int getEngheidsFactor( ) {

        return _engheidsFactor;
    
    }

}

Hiermee beveilig ik het object voor 'illegal values' voor bijv als de programmeur verkeerde waardes koppelt aan een checkbox. Maw, checken jullie ook op ' programmeer fouten' (null waardes, illegal input qua constantes ed.) . Zoja welke gevolgen laat je daar aan hangen?

[.oisyn]

mmja, maar voor enumerations is het beter als je instanties gebruikt van klassen die je zelf niet kunt instantieren (snap je het nog? even een voorbeeldje:)

code:

public class EngheidsFactor
{
    public final static EngheidsFactor HEEL_ENG = new EngheidsFactor ();
    public final static EngheidsFactor NIET_ENG = new EngheidsFactor ();

    private EngheidsFactor () { }
}

nu kun je nooit andere 'waarden' dan HEEL_ENG en NIET_ENG geven (behalve null dan )

zelf gebruik ik meestal asserts... die worden niet meegecompiled in release builds, maar tijdens testen (debug builds) komen de fouten dan wel naar boven

[Glimi]

.oisyn schreef op 14 augustus 2002 @ 00:21:
mmja, maar voor enumerations is het beter als je instanties gebruikt van klassen die je zelf niet kunt instantieren (snap je het nog? even een voorbeeldje:)

Begrijp je helemaal, en nu herrinder ik me ook weer dat Alarmnummer me dat ook al us vertelt heeft. Heeft iemand een donker hoekje vrij om je in te schamen?

zelf gebruik ik meestal asserts... die worden niet meegecompiled in release builds, maar tijdens testen (debug builds) komen de fouten dan wel naar boven

Asserts bieden je alleen veiligheid voor programmeer fouten, niet tegen foute input van users, een check doet beide. Echter het is een keuze die je moet maken, aangezien checks de code gaan vertragen. Ik heb eigenlijk geen idee hoe je netjes kan bepalen wat nou het beste is, wat gebruikt men hier meestal?

[ Voor 0% gewijzigd door Glimi op 14-08-2002 00:44 . Reden: typo + toevoeging ]

[Verwijderd]

Glimi schreef op 14 augustus 2002 @ 00:09:
Om maar een andere richting in te gaan van 'safe code' is het checken op input, zelfs binnen classes. Neem nou dit

code:

...

Hiermee beveilig ik het object voor 'illegal values' voor bijv als de programmeur verkeerde waardes koppelt aan een checkbox. Maw, checken jullie ook op ' programmeer fouten' (null waardes, illegal input qua constantes ed.) . Zoja welke gevolgen laat je daar aan hangen?

Een assert zou hier voldoende moeten wezen. Evt userinput handel je buiten deze functie om..

[Alarmnummer]

Verwijderd schreef op 14 augustus 2002 @ 01:38:
[...]


Een assert zou hier voldoende moeten wezen. Evt userinput handel je buiten deze functie om..

assert statements mogen niet in publiekelijke of protected methodes gebruikt worden. Omdat het assert statement ook door de client uitgezet kan worden, kan het voorkomen dat een api niet meer doet wat het hoort te doen (dus verder gaan als foutmelding opgeworpen had moeten worden). Checks de specs maar eens.

[Verwijderd]

Alarmnummer schreef op 14 augustus 2002 @ 01:41:
[...]

assert statements mogen niet in publiekelijke of protected methodes gebruikt worden. Omdat het assert statement ook door de client uitgezet kan worden, kan het voorkomen dat een api niet meer doet wat het hoort te doen (dus verder gaan als foutmelding opgeworpen had moeten worden). Checks de specs maar eens.

Functie heeft pre en post condities. Als de programmeur zich daar niet aan houdt is dat zijn probleem. De GUI code is verantwoordelijk voor goede input.

Trouwens, je kunt altijd als de input niet goed is, het in een default state zetten..

[.oisyn]

Alarmnummer schreef op 14 augustus 2002 @ 01:41:
[...]

assert statements mogen niet in publiekelijke of protected methodes gebruikt worden. Omdat het assert statement ook door de client uitgezet kan worden, kan het voorkomen dat een api niet meer doet wat het hoort te doen (dus verder gaan als foutmelding opgeworpen had moeten worden). Checks de specs maar eens.

welke specs?
anyway, assert statements (en dan heb ik het niet alleen over java) zijn sowieso niet bedoeld voor foutmeldingen naar de user toe, maar om de bugs uit je code te halen tijdens development/testing. Imho hoort er in een release build geen enkele assert meer in de code te staan (niet meegecompiled bedoel ik dan)

Zou wat zijn als een gebruiker ineens een popup boxje op z'n scherm te zien kreeg:

Assertion failed

numPlanes < 4 in ConvexHull::intersect ()

Abort, Retry, Ignore

[Sponge]

[b][message=14751407,noline].oisyn schreef op 13 augustus 2002 @ 23:20

code:

user -> client: knop ingedrukt
client: draait geweer rond, checkt ammo, schiet kogels
client -> server: schietknop ingedrukt
server: schiet kogels, kijkt wie er geraakt worden (op de server
    is er geen ronddraaiend geweer; dat is een visueel element die
    totaal niet relevant is voor de server)
server -> client: eventueel vertellen wie er dood zijn gegaan

Nu kun je in de client code gaan hacken om te zorgen dat de client denkt dat je kogels nog niet op zijn... je schiet er echter niets mee op, want terwijl jij vrolijk door schiet gaat er niemand meer dood omdat de server de kogels niet afschiet.
Bovendien heb je nu heel weinig dataverkeer en blijft het goed speelbaar met een hoge ping

Heel netjes

Wat encryptie betreft voor spellen, dit vind ik dus van dusdanig belang, dat ik het ook zeker in mijn spel heb zitten.. anders krijg je dat het heel makkelijk is om aimbots te gebruiken/data te onderscheppen, en meteen te begrijpen wat voor type packet het is is. Nu kan dat niet (uiteraard, alles kan..) omdat de packet eerst gedecrypt moet worden om te zien wat het is. Sowieso gebruik ik ook verschillende packet id's, de ene keer kan schieten een id van 112 hebben, de andere keer 34...
Ik weet eigenlijkniet of games zoals UT/Quake dit doen.. maar die versturen ook zulke hoeveelheden bandbreedte dat eht uiteindelijk teveel cycles gaat kosten om te encrypten (meestal 70 packets up en down..)

[Woy]

.oisyn schreef op 14 augustus 2002 @ 04:02:

[...]


welke specs?
anyway, assert statements (en dan heb ik het niet alleen over java) zijn sowieso niet bedoeld voor foutmeldingen naar de user toe, maar om de bugs uit je code te halen tijdens development/testing. Imho hoort er in een release build geen enkele assert meer in de code te staan (niet meegecompiled bedoel ik dan)

Zou wat zijn als een gebruiker ineens een popup boxje op z'n scherm te zien kreeg:

[...]

Microsoft denkt hier natuurlijk weer anders over. In c# heb je namelijk 2 verschillende asserts. Debug.assert() die verdwijnt bij de release en Trace.assert() die niet verdwijnt. Ik vind het zelf ook een lelelijk oplossing als er dan toch gechecked moet worden doe dat dan gewoon zelf en throw een passende exceptie ofzo.

[Glimi]

Verwijderd schreef op 14 augustus 2002 @ 01:58:
Functie heeft pre en post condities. Als de programmeur zich daar niet aan houdt is dat zijn probleem. De GUI code is verantwoordelijk voor goede input.

Trouwens, je kunt altijd als de input niet goed is, het in een default state zetten..

Dat vind ik echt zwaar ranzig, zo'n slappe syntax afdwingen. Is het gewoon fout, dan moet men dat weten! Whoppa, niet 'er maar het beste van maken', daar hebben we met HTML genoeg shit mee gehad.

Plus dat je er dan nooooit achterkomt dat dat het is als er iets fout gaat.

Ook is de GUI imho absoluut niet verantwoordelijk voor geldige input. De enige die weet dat leeftijd niet < 0 mag zijn is de Persoonclass zelf! Deze moet dan ook z'n input gaan checken en daarop meldingen mocht dit fout zijn. De GUI is hier puur een visualisatie van en mag (qua MVC) zelfs helemaal niet checken.

Tzou wat worden, alle controle logica in een GUI. Dan is deze toch ook niet meer generiek?

[Alarmnummer]

Verwijderd schreef op 14 augustus 2002 @ 01:58:
[...]
Functie heeft pre en post condities. Als de programmeur zich daar niet aan houdt is dat zijn probleem. De GUI code is verantwoordelijk voor goede input.

Ik ben blij dat je niet in mijn team zit Waarom zou je in godsnaam pre en postcondities erin zetten als je weet dat je nooit fouten maakt? Design by Contract is gemaakt om dit soort dingen te verhelpen. Het zorgt er voor dat onderdelen zich aan hun contract houden.

Trouwens, je kunt altijd als de input niet goed is, het in een default state zetten..

Ik ben zeker blij dat je niet in mijn team zit, want dit is echt not done! Niemand heeft dus in de gaten dat er iets fout is gegaan.

[Woy]

Verwijderd schreef op 14 augustus 2002 @ 01:58:
[...]


Functie heeft pre en post condities. Als de programmeur zich daar niet aan houdt is dat zijn probleem. De GUI code is verantwoordelijk voor goede input.

Trouwens, je kunt altijd als de input niet goed is, het in een default state zetten..

Dit is inderdaad wel heel ranzig. Natuurlijk controleer je ook een klein beetje op invoer in de gui maar dan bedoel ik meer controleren of het wel een getal is wat ingevoerd is ofzo. Zeker niet of het een geldige waarde is die is ingevoerd want de gui hoort niks over de applicatie logica te weten

[Alarmnummer]

.oisyn schreef op 14 augustus 2002 @ 04:02:

[...]


welke specs?

die van Sun: http://java.sun.com/j2se/1.4.1/docs/guide/lang/assert.html

anyway, assert statements (en dan heb ik het niet alleen over java) zijn sowieso niet bedoeld voor foutmeldingen naar de user toe, maar om de bugs uit je code te halen tijdens development/testing. Imho hoort er in een release build geen enkele assert meer in de code te staan (niet meegecompiled bedoel ik dan)

Ik heb het ook niet gehad over gui. Met client bedoel ik een programmeur de een gebruiker: client is van een api. Hij moet op de hoogte gestelt worden door een exception. En verder compileerd java de asserts wel mee, maar als je tegen een lib zegt dat hij niet mag asserten dan doet hij dit ook netjes (en kost het je dus nagenoeg geen extra tijd)

Daarom mogen publieke en protected methodes het assert commando ook niet gebruiken voor precondities. Stel dat je het volgende hebt:

code:

public void setLeeftijd(int leeftijd){
    assert leeftijd>=0:"leeftijd moet >=0";
    this.leeftijd = leeftijd;
}

Dan zou deze foutmelding niet gepakt meer worden als je hem uitzet, en zou een object onopgemerkt in een inconsistente toestand terecht kunnen komen.

op preconditie gebied is het assert commando vooral handig om in je eigen api ontwerp te zorgen voor controles die uiteindelijk verwijderd kunnen worden als de api lang genoeg getest is.

Trouwens ik test alles nu met JUnit en ik ben bezig met Nice, en ik hoef dus echt bijna niets meer te testen door het krachtige type systeem van Nice en ik heb het volste vertrouwen door JUnit.

Zou wat zijn als een gebruiker ineens een popup boxje op z'n scherm te zien kreeg:

inferior user error

[Woy]

Alarmnummer schreef op 14 augustus 2002 @ 09:50:
[...]inferior user error

please replace user.....
press any key to continue.....

[Bobco]

Glimi schreef op 14 augustus 2002 @ 09:29:
[...]
Ook is de GUI imho absoluut niet verantwoordelijk voor geldige input. De enige die weet dat leeftijd niet < 0 mag zijn is de Persoonclass zelf! Deze moet dan ook z'n input gaan checken en daarop meldingen mocht dit fout zijn. De GUI is hier puur een visualisatie van en mag (qua MVC) zelfs helemaal niet checken. T zou wat worden, alle controle logica in een GUI. Dan is deze toch ook niet meer generiek?

Op zich heb je gelijk, maar in verband met het potentieel grote aantal calls dat dan heen en weer gaat tussen de verschillende objecten kan het handig zijn om de view alvast een beetje te laten helpen.

Een web-frontend mag van mij best wat validatie-logica bevatten, al is het alleen maar om de gebruiker te behoeden voor het insturen van waarden die echt nooit kunnen. Een simpel stukje JavaScript dat controleert of waarden wel in het toegestane domein vallen vind ik zelf wel prettig. Natuurlijk controleert het Model nog altijd of de aangeboden waarden wel mogen, maar die controle zal dan over het algemeen geen afkeuringen meer opleveren.

het draait in deze discussie volgens mij om het vinden van een balans tussen performance, veiligheid en herbruikbaarheid. Kies er twee!

[.oisyn]

rwb schreef op 14 augustus 2002 @ 09:27:
[...]


Microsoft denkt hier natuurlijk weer anders over. In c# heb je namelijk 2 verschillende asserts. Debug.assert() die verdwijnt bij de release en Trace.assert() die niet verdwijnt. Ik vind het zelf ook een lelelijk oplossing als er dan toch gechecked moet worden doe dat dan gewoon zelf en throw een passende exceptie ofzo.

maar de Trace class is wel bedoeld voor debugging doeleinden. Ongeveer hetzelfde als je code peperen met output functies Niet voor release builds dus

uit de MSDN:

Trace Class
Provides a set of methods and properties that help you trace the execution of your code

Alarmnummer schreef op 14 augustus 2002 @ 09:50:

Ik heb het ook niet gehad over gui. Met client bedoel ik een programmeur de een gebruiker: client is van een api. Hij moet op de hoogte gestelt worden door een exception. En verder compileerd java de asserts wel mee, maar als je tegen een lib zegt dat hij niet mag asserten dan doet hij dit ook netjes (en kost het je dus nagenoeg geen extra tijd)

volgens mij bedoelen we hetzelfde maar praten we langs elkaar heen (dat over die gebruiker die een assertion error kreeg was bedoeld als grapje apart )
Wat ik bedoelde is dat asserts juist niet bedoeld zijn voor checks voor parameters die 'uit de grote wijde wereld komen'. Maar wel om interne consistentie te testen (en dat zijn idd meestal private methoden, hoewel protected/public imho ook wel kan, maar dan niet om de parameters te testen, maar bijvoorbeeld om te controleren of een bepaalde buffer wel gealloceerd is)

Echter vind ik het wel toegestaan als snelheid van belang is, vooropgesteld dat je uitvoerig beschrijft wat de pre en post condities zijn. In mijn 3d engine bijvoorbeeld (om het even te relativeren ) bestaan alle checks uit asserts... Beetje loos dat je vanalles moet controleren (wat tijd kost) omdat de programmeur die gebruik maakt van mijn lib z'n pointertjes niet goed heeft staan oid. Tijdens testen (debug build) komen deze fouten wel naar boven, alleen in release builds kan het gruwelijk fout gaan. Maar dan heb je het niet meer over een potentieel 'domme' client die je code gebruikt... enig expertise van het systeem is dan gewoon vereist

[Alarmnummer]

We hebben het inderdaad over precies hetzelfde En ik gebruik ook asserts 'debug' checks uit te voeren die in een normale versie alles onnodig zouden vertragen, maar je wel extreem helpen bij het schrijven

[offtopic]
Ik hou me eerlijk gezegd totaal niet bezig met snelheid. Ik ben op dit moment bezig met Nice en daarin zitten een aantal features die vrij veel runtime snelheid kosten, maar aangezien het geen tig keer per seconde hoeft te draaien en ik gebruik kan maken van deze handige technieken vind ik het wel best. Snelheid is leuk, maar zonder reden laat ik snelheid nooit een goed design in gevaar brengen (dit betekend trouwens niet dat ik totaal niet erop let)

[Woy]

.oisyn schreef op 14 augustus 2002 @ 14:33:

[...]


maar de Trace class is wel bedoeld voor debugging doeleinden. Ongeveer hetzelfde als je code peperen met output functies Niet voor release builds dus

uit de MSDN:

ook uit de MSDN:

Note that calls to the Debug.Assert method disappear when you create a Release version of your code. That means that the call that checks the balance will disappear in the Release version. To solve this problem, you should replace Debug.Assert with Trace.Assert, which does not disappear in the Release version:

Nou is het wel mogelijk om de trace optie uit te zetten bij de release build maar in visual studio staat het standaard aan in de release build

[Verwijderd]

We zijn er dus achter dat er twee soorten schendingen van de pre/post-condities zijn:
• logic errors van de programmeur(s)
• user input errors

Logic errors vang je tijdens de debug-fase op met asserts, in een release-build zitten (hopelijk) geen logic errors meer, dus kunnen de asserts verdwijnen in een release-build.

User input errors kunnen altijd plaatsvinden, en er moet dus altijd op getest worden. User errors zijn van een totaal andere categorie dan logic errors, want ze beinvloeden de correcte werking van het programma niet (garbage in, garbage out).

User errors dienen dus anders behandeld te worden dan logic errors, bij een logic error is het beter het programma zo snel mogelijk te beeindigen; het programma werkt immers niet correct. User errors moeten "gracefuly" afgehandeld worden, dwz. met een voor gebruikers begrijpbare foutmelding en evt. het verzoek het nog eens in te voeren.

[Sponge]

rwb schreef op 14 augustus 2002 @ 14:48:
[...]


Nou is het wel mogelijk om de trace optie uit te zetten bij de release build maar in visual studio staat het standaard aan in de release build

Met Visual Basic blijven de calls er echter instaan.

Als je bijvoorbeeld gewoon ergens iets hebt staan zoals:

Debug.Print DoIetsOnzinnig

en DoIetsOnzinnig bevat bijvoorbeeld:
For I = 0 to 100000
x = x +i
Next I

dan wordt die loop echt aangeroepen, zelfs in de exe!

[TheOneLLama]

.oisyn schreef op 13 augustus 2002 @ 23:20:

Wat veel beter zou zijn is als je de server en client code goed op elkaar instelt, zonder dat je teveel verantwoordelijkheden bij de client legt:

code:

user -> client: knop ingedrukt
client: draait geweer rond, checkt ammo, schiet kogels
client -> server: schietknop ingedrukt
server: schiet kogels, kijkt wie er geraakt worden (op de server
    is er geen ronddraaiend geweer; dat is een visueel element die
    totaal niet relevant is voor de server)
server -> client: eventueel vertellen wie er dood zijn gegaan

edit: zie onder ik had het verkeerd begrepen

Die draaing is natuurlijk (mogelijk) wel belangrijk voor de server voor het bepalen van het gezichtsveld van de client, en welke entiteiten er zichtbaar zijn. In dit model krijgt de server de draai pas door met het schot. Het kan dus zijn dat ik bv. een aimbot gebruik die in 1 klap iemand neerschiet die 180 graden achter me staat. Ook kan het potentieel veel bandwith besparen (als achter je opeens 100 man op je afkomen hoeft de server dat mooi niet door te sturen). Terwijl aan de andere kant het creeen en verwijderen van entiteiten weer *meer* bandwith kan kosten. (en het bereken van het gezichtsveld ook meer CPU kost, maar tegelijkertijd ook wallhacks ed. tegengaat).

En iedereen die met prediction gewerkt heeft weet dat het nog stukken moeilijker wordt als de client gaat rondlopen ed. Wie bepaalt immers waar de client is?
Stel de client wil naar voren lopen: op de client loop je dan naar voren zodra je de toets indrukt.
Geef je enkel aan de server op dat je de naar voren toets indrukt dan is tegen de tijd dat dat de server bereikt heeft de situatie daar misschien weer anders. Je bent in ieder geval niet waar je denkt dat je bent.. begin je dan ook nog eens te schieten op een ander moment dan je denkt, dan krijg je het irritante effect dat je op jou scherm iemand helemaal verot schiet terwijl je op de server 1 meter verderop langs diegene heen staat te schieten. Dat los je natuurlijk weer op door correcties naar de client te sturen maar doe je dat teveel en dan vallen alle voordelen van prediction weer weg (en ga je ook nog eens schokkerig bewegen). Of je kan het oplossen door de client aan de server te laten vertellen waar hij is (maar kun je dat vertouwen? nee dus). Of je kan de client het tijdstip laten vertellen wanneer die toets is ingedrukt, wat je ook niet kan vertrouwen. Dan kun je daar weer iets op bedenken als tick-synchronisatie wat zo weer z'n eigen nadelen heeft zoals bij Out-Of-Order packet delivery (en het terugrekenen van dat soort acties in je model is ook niet de meest simpele taak).

Aan een prediction model zitten (naast de voordelen) dus of (onzichtbaar voor de user, dus nogal irritante) nadelen voor speelbaarheid of nadelen voor security. Toch komt het soms neer op een combinatie van deze 2 (waar dus wat security word ingelevert voor speelbaarheid). Zolang protocol en client gesloten zijn valt er nog mee te leven, maar als je dit soort dingen in een opensource project met een open protocol doet kan het problemen opleveren.

Nu kun je in de client code gaan hacken om te zorgen dat de client denkt dat je kogels nog niet op zijn... je schiet er echter niets mee op, want terwijl jij vrolijk door schiet gaat er niemand meer dood omdat de server de kogels niet afschiet.
Bovendien heb je nu heel weinig dataverkeer en blijft het goed speelbaar met een hoge ping

[.oisyn]

rwb schreef op 14 augustus 2002 @ 14:48:
[...]


ook uit de MSDN:

[...]

Nou is het wel mogelijk om de trace optie uit te zetten bij de release build maar in visual studio staat het standaard aan in de release build

daar gaat het helemaal niet om, je gaat gewoon geen Trace.Assert () aanroepen in je release-code zetten

[Woy]

.oisyn schreef op 14 augustus 2002 @ 21:28:

[...]



daar gaat het helemaal niet om, je gaat gewoon geen Trace.Assert () aanroepen in je release-code zetten

Nee natuurlijk niet. Maar ik wou even laten zien dat microsoft vindt dat dat wel gewoon moet bij het voorbeeld gebruiken ze het zelfs om te controleren of het saldo van een bankrekening wel genoeg is

[Sponge]

TheOneLLama schreef op 14 augustus 2002 @ 18:14:
[...]

En iedereen die met prediction gewerkt heeft weet dat het nog stukken moeilijker wordt als de client gaat rondlopen ed. Wie bepaalt immers waar de client is?
Stel de client wil naar voren lopen: op de client loop je dan naar voren zodra je de toets indrukt.
Geef je enkel aan de server op dat je de naar voren toets indrukt dan is tegen de tijd dat dat de server bereikt heeft de situatie daar misschien weer anders. Je bent in ieder geval niet waar je denkt dat je bent.. begin je dan ook nog eens te schieten op een ander moment dan je denkt, dan krijg je het irritante effect dat je op jou scherm iemand helemaal verot schiet terwijl je op de server 1 meter verderop langs diegene heen staat te schieten.

Tsja.. maar in theorie is alles wat op de server binnenkomt al verouderd..Met een goede interpolatie/tijd synchronisatie merk je er echter niet zoveel onder de ~200ms

-user begint met lopen op tijd 1000ms, (constante snelheid is het meestal), richting x
-packetje komt aan op server; tijd = 1050ms
-Server inter- (extra) poleert de nieuwe positie en gaat daar van uit.

Je zal altijd een aantal dingen moeten aannemen..als je steeds minder data gaat/wilt versturen.

[Verwijderd]

http://msdn.microsoft.com...SecurityTips/default.aspx werkt beter

[Gerco]

TheOneLLama schreef op 14 augustus 2002 @ 18:14:
Die draaing is natuurlijk (mogelijk) wel belangrijk voor de server voor het bepalen van het gezichtsveld van de client, en welke entiteiten er zichtbaar zijn. In dit model krijgt de server de draai pas door met het schot. Het kan dus zijn dat ik bv. een aimbot gebruik die in 1 klap iemand neerschiet die 180 graden achter me staat.

De draaing die hier bedoeld is, is het draaien van bijvoorbeeld een minigun of revolver in de hand van de speler. Niet een verandering van orientatie. Een pure client-side animatie om het spel mooier te maken, het heeft helemaal NIETS met het verloop van het spel te maken.

[TheOneLLama]

Gerco schreef op 15 augustus 2002 @ 12:08:
[...]

De draaing die hier bedoeld is, is het draaien van bijvoorbeeld een minigun of revolver in de hand van de speler. Niet een verandering van orientatie. Een pure client-side animatie om het spel mooier te maken, het heeft helemaal NIETS met het verloop van het spel te maken.

Ik had het idd verkeerd begrepen.. ik dacht dat de richting veranderen bedoeld was.. OOPS

[TheOneLLama]

41.6C.6D.61.72 schreef op 15 augustus 2002 @ 11:34:
[...]


Tsja.. maar in theorie is alles wat op de server binnenkomt al verouderd..Met een goede interpolatie/tijd synchronisatie merk je er echter niet zoveel onder de ~200ms

-user begint met lopen op tijd 1000ms, (constante snelheid is het meestal), richting x
-packetje komt aan op server; tijd = 1050ms
-Server inter- (extra) poleert de nieuwe positie en gaat daar van uit.

Je zal altijd een aantal dingen moeten aannemen..als je steeds minder data gaat/wilt versturen.

Precies, het probleem met prediction is dat bij de user je vanaf 1000ms bent gaan lopen terwijl dat op de server bij 200ms lag pas om 1100ms is. De server kan dan weer de echte tijd waarop je echt bent gaan lopen terugsturen en op de client kun je dat weer terug inpassen. Ik heb echter ook voor een keer een model gemaakt waarin de client simpelweg de tijd waarop hij gaat bewegen meestuurt, en de server bij het versturen van eniteiten naar de client hetzelfde doet (en de server natuurlijk nog altijd de positie+richting+tijdstip van de client mag forceren).

Met (gesimuleerde) lag speelde het nog best aardig dan.. je eigen bewegingen worden perfect gevolgd, de posities van de andere spelers zijn de posities waarop ze ook daadwerkelijk zijn mits ze geen beweging gemaakt hebben in de tijd van jou+zijn lag opgeteld. Bovendien is het gebalanceerd: iemand met hoge lag ziet de bewegingen van anderen later, en die anderen zien zijn bewegingen later. Verder kost het maar heel weinig bandwidth. Het is echter totaal niet secure, en moeilijk in te passen met dingen als collision detection tussen bewegende onderdelen.

[Zoijar]

De volgende articles vond ik wel interessant.

Anti cheat 1
Anti cheat 2

dead reckoning

Je moet trouwens erg uitkijken tegenwoordig met dead reckoning, zoals je zelf al zei bij jouw voorbeeld "het is echter niet totaal secure". Er worden heel veel "speedhacks" gebruikt om te cheaten. Bv Gear was bij asherons call een groot probleem.

edit:
De punten uit het ene artikel (hey lijkt op het msdn artikel Ik denk dat veel punten ook voor webscripting gelden, niet alleen games.

Rule #1: If you build it, they will come -- to hack and cheat.
Rule #2: hacking attempts increase with the success of your game.
Rule #3: cheaters actively try to keep developers from learning their cheats.
Rule #4: Your game, along with everything on the cheater's computer, is not secure. The files are not secure. Memory is not secure. Services and drivers are not secure.
Rule #5: Obscurity is not security.
Rule #6: Any communication over an open line is vulnerable to interception, analysis, and modification.
Rule #7: There is no such thing as a harmless cheat or exploit. Cheaters are incredibly inventive at figuring out how to get the most out of any loophole or exploit.
Rule #8: Trust in the server is everything in a client-server game.
Rule #9: Honest players would love for a game to tip them off to possible cheating. Cheaters want the opposite.

[TheOneLLama]

Zoijar schreef op 15 augustus 2002 @ 14:43:

Je moet trouwens erg uitkijken tegenwoordig met dead reckoning, zoals je zelf al zei bij jouw voorbeeld "het is echter niet totaal secure". Er worden heel veel "speedhacks" gebruikt om te cheaten. Bv Gear was bij asherons call een groot probleem.

Precies wat ik bedoelde.. die game die ik voor school moest maken heette officieel een "simulatie" dus dan mag het iets minder secure van mij

Vooral die regel: "Rule #8: Trust in the server is everything in a client-server game" gaat natuurlijk op in games. En iedere game developer weet dat. In de praktijk zie je echter dat dat vaak toch genegeerd voor meer snelheid en speelbaarheid. Anders zit iedereen de hele dag te zeuren over hoe slechtde netcode toch is.

[Zoijar]

Ik vind zelf "Rule #5: Obscurity is not security." heel belangrijk ook in veel andere contexten.

En ja...het blijft idd een afweging tussen performance en security. Het liefst zou je natuurlijk bv elke muis beweging naar de server willen sturen, maar dat gaat gewoon niet. Zelfs niet met een toch wel minimale ping van 30ms.

[.oisyn]

rwb schreef op 15 augustus 2002 @ 11:27:
[...]


Nee natuurlijk niet. Maar ik wou even laten zien dat microsoft vindt dat dat wel gewoon moet bij het voorbeeld gebruiken ze het zelfs om te controleren of het saldo van een bankrekening wel genoeg is

serieus? aargh das wel heel lomp ja

[.oisyn]

[nohtml]

TheOneLLama schreef op 14 augustus 2002 @ 18:14:
[...]


edit: zie onder ik had het verkeerd begrepen

Die draaing is natuurlijk (mogelijk) wel belangrijk voor de server voor het bepalen van het gezichtsveld van de client, en welke entiteiten er zichtbaar zijn. In dit model krijgt de server de draai pas door met het schot. Het kan dus zijn dat ik bv. een aimbot gebruik die in 1 klap iemand neerschiet die 180 graden achter me staat. Ook kan het potentieel veel bandwith besparen (als achter je opeens 100 man op je afkomen hoeft de server dat mooi niet door te sturen). Terwijl aan de andere kant het creeen en verwijderen van entiteiten weer *meer* bandwith kan kosten. (en het bereken van het gezichtsveld ook meer CPU kost, maar tegelijkertijd ook wallhacks ed. tegengaat).

Dat is idd zoals ze het in quake1 ook doen (en dus ook in 2 en 3 neem ik aan).
(en met draaiing bedoelde ik dus het geweer... ik ging even uit van een chaingun achtig iets )

En iedereen die met prediction gewerkt heeft weet dat het nog stukken moeilijker wordt als de client gaat rondlopen ed. Wie bepaalt immers waar de client is?
Stel de client wil naar voren lopen: op de client loop je dan naar voren zodra je de toets indrukt.
Geef je enkel aan de server op dat je de naar voren toets indrukt dan is tegen de tijd dat dat de server bereikt heeft de situatie daar misschien weer anders. Je bent in ieder geval niet waar je denkt dat je bent.. begin je dan ook nog eens te schieten op een ander moment dan je denkt, dan krijg je het irritante effect dat je op jou scherm iemand helemaal verot schiet terwijl je op de server 1 meter verderop langs diegene heen staat te schieten. Dat los je natuurlijk weer op door correcties naar de client te sturen maar doe je dat teveel en dan vallen alle voordelen van prediction weer weg (en ga je ook nog eens schokkerig bewegen).

correcties moet je alleen sturen als dat nodig is. Een stilstaande player heeft bijvoorbeeld helemaal geen correcties nodig. Iemand die alleen recht vooruit loopt heeft maar 1 correctie nodig: vlak na het moment dat ie de toets heeft ingedrukt.
In principe moet je alleen een correctie sturen als er een onverwachte verandering in de beweging optreedt.

Stel je schiet een granaat de lucht in. De client spawnt voor zichzelf al een granaat en schiet die in de richting waarop je kijkt, en de server doet dat ook. Dan stuurt de server even een correctie waarin de echte oorsprong, richting en tijdstip staat. De client past z'n gegevens aan en vanaf nu zouden ze keurig synchroon moeten lopen. Na een stuiter tegen een muur hoeft er geen correctie uitgevoerd te worden aangezien de client dit zelf ook wel kan berekenen. Stuitert ie echter tegen een medespeler aan (vooropgesteld dat ie dan niet ontploft ) dan moet er wel een correctie gestuurd worden omdat de bewegingen van die medespeler onvoorspelbaar zijn.
Dat hele verhaal is natuurlijk vooropgesteld dat er zich vrijwel geen afrondingsfouten voordoen. In quake3 bijvoorbeeld, waar alle floats worden geconverteerd naar ints omdat dat betere packet compressie geeft, krijg je de nare eigenschap dat iemand met een framerate van 125 verder en hoger kan springen dan iemand met een fps van bijvoorbeeld 80.

Of je kan de client het tijdstip laten vertellen wanneer die toets is ingedrukt, wat je ook niet kan vertrouwen.

Dat kun je dus vrijwel wel vertrouwen. Okee, er moeten wel wat checks gedaan worden zodat de client niet kan zeggen dat ie die knop een uur geleden al heeft ingedrukt. De tijd kan gewoon niet langer geleden zijn dan de halve ping tijd (dus de tijd dat een pakketje erover doet om van de ene peer naar de andere te rijzen)

.edit: hmm zo te zien sprak ik voor mijn beurt... voortaan de rest van de draad ook lezen

[Sponge]

Zoijar schreef op 15 augustus 2002 @ 14:43:

Je moet trouwens erg uitkijken tegenwoordig met dead reckoning, zoals je zelf al zei bij jouw voorbeeld "het is echter niet totaal secure". Er worden heel veel "speedhacks" gebruikt om te cheaten. Bv Gear was bij asherons call een groot probleem.

Interessante discussie nu!

Ik ken die gamasutra docs, en heb ze ook helemaal uitgeprint en wel hier naast m'n PC liggen.
Op gamedev heb ik ook eens een discussie hierover gestart:

Gamedev.net MP forum

Vooral die regel: "Rule #8: Trust in the server is everything in a client-server game" gaat natuurlijk op in games. En iedere game developer weet dat. In de praktijk zie je echter dat dat vaak toch genegeerd voor meer snelheid en speelbaarheid. Anders zit iedereen de hele dag te zeuren over hoe slechtde netcode toch is.

Tsja, maar er is hier een reden voor. Ik weet bijvoorbeeld dat bij Subspace niet alles so client-server is als het lijkt.. het schijnt zelf dat het vernietigen van een schip zelfs op de client gebeurd. Waarom? Nou, nu kan iedereen met een redelijke lag alsnog spelen, en vernietigen .

Nog zo een ding: Ultima Online vs Everquest (regelmatige discussie op gamedev hieroveR). De ene stuurt eerst "hier wil ik naar toe, mag dat,? Zo ja, move me daar naar toe". De andere zegt "Ja verplaats me hiernaartoe, check of het mag. Zo niet, dan zet je me maar weer terug"

Die laatste methode heeft wat cheaters opgelevert die even kunstmatig voorbij een onbegaanbare plaatsen gingen door gewoon rechtdoor te lopen!

_{(ik wil er eigenlijk nog verder op in, maar heb nu niet echt de tijd )}

Trouwens die 9 regels gelden zeker voor normale apps! Een aantal komen er ook in terug.

[TheOneLLama]

.oisyn schreef op 15 augustus 2002 @ 16:45:
[nohtml]
[...]

Dat is idd zoals ze het in quake1 ook doen (en dus ook in 2 en 3 neem ik aan).
(en met draaiing bedoelde ik dus het geweer... ik ging even uit van een chaingun achtig iets )

[...]

correcties moet je alleen sturen als dat nodig is. Een stilstaande player heeft bijvoorbeeld helemaal geen correcties nodig. Iemand die alleen recht vooruit loopt heeft maar 1 correctie nodig: vlak na het moment dat ie de toets heeft ingedrukt.
In principe moet je alleen een correctie sturen als er een onverwachte verandering in de beweging optreedt.

Als je dit zo gaat bekijken met het perspectief "vertrouw enkel de server", dan krijg je de volgende situatie: stel ik heb 500ms lag. Ik ga vooruitlopen. 250ms later berijkt dit de server. De server stuurt direct een correctie: je bent pas 250ms later met lopen begonnen. Deze correctie komt 250ms later weer aan bij mij (de client) en ik word 500ms nadat ik naar voren ben gaan lopen opeens naar achteren geworpen: weg voordeel van de prediction.

Je kan dit oplossen door de client z'n woord te nemen op wanneer deze begon te lopen, maar dat is onveilig! Je kan ook aan andere oplossingen denken, de server laten proberen de latency te verwerken (maar lag is niet constant en zeker niet betrouwbaar), proberen via mechanismes de integriteit van het tijdstip wat de client opgeeft te verhogen (zoals het al zegt: verhogen.. je kan dit niet nou eenmaal niet waarborgen, dat wordt nooit 100% veilig).

Een andere oplossing is, laat die client maar lekker doorlopen, hij denkt dan wel dat ie een beetje ergens anders loopt maar ach. Dan krijg je natuurlijk een probleem als die client ergens op gaat schieten, de client denkt dat ie iets raakt (en ziet bloed in het rond vliegen), terwijl ie op de server mis schiet.

De oplossing ligt vaak in het midden. Maar het probleem is dat als je hier de oplossing in het midden legt, is dat die ergens tussen security en speelbaarheid in ligt.

Stel je schiet een granaat de lucht in. De client spawnt voor zichzelf al een granaat en schiet die in de richting waarop je kijkt, en de server doet dat ook. Dan stuurt de server even een correctie waarin de echte oorsprong, richting en tijdstip staat.

De client past z'n gegevens aan en vanaf nu zouden ze keurig synchroon moeten lopen.

Dat de client zelf al een granaat spawned is dus zinloos hier, want na de roundtrip moet ie dat ding weer verplaatsen naar waar ie werkelijk vandaan komt.

Na een stuiter tegen een muur hoeft er geen correctie uitgevoerd te worden aangezien de client dit zelf ook wel kan berekenen. Stuitert ie echter tegen een medespeler aan (vooropgesteld dat ie dan niet ontploft ) dan moet er wel een correctie gestuurd worden omdat de bewegingen van die medespeler onvoorspelbaar zijn.

Alleen als de prediction van de stuiter tegen de medespeler op een tijdstip plaatsvind waarover nadat de prediction is uitgevoerd nog updates komen moet er een correctie plaatsvinden. Die kan de client echter zelf doen mbv. de nieuwe gegevens.

Dat hele verhaal is natuurlijk vooropgesteld dat er zich vrijwel geen afrondingsfouten voordoen.

En daarmee werp je ons mooi van theorie de praktijk in
Ik heb een keer zelf een posting gelezen van iemand die een engine gemaakt had op zo'n manier die beweerde dat AMD's en Intel's niet bij alle FP berekening dezelfde uitkomst gaven.

In quake3 bijvoorbeeld, waar alle floats worden geconverteerd naar ints omdat dat betere packet compressie geeft, krijg je de nare eigenschap dat iemand met een framerate van 125 verder en hoger kan springen dan iemand met een fps van bijvoorbeeld 80.

Wat gelijk mooi aangeeft dat Quake 1, 2 en dus ook 3 kennelijk security opofferen voor speelbaarheid door de client (een deel van) z'n positie te laten berekenen.

Dat kun je dus vrijwel wel vertrouwen.

De enige garantie die je hebt om dit te vertrouwen is de obscurity van je protcol en je excecutable. Vele game designers vertrouwden daar vrijwel op met als gevolg dat er in vele games mensen met 400 KM/u voorbij komen wandelen.

Okee, er moeten wel wat checks gedaan worden zodat de client niet kan zeggen dat ie die knop een uur geleden al heeft ingedrukt. De tijd kan gewoon niet langer geleden zijn dan de halve ping tijd (dus de tijd dat een pakketje erover doet om van de ene peer naar de andere te rijzen)

De "Ping" is er ontbetrouwbaar.. het enige wat je weet is namelijk de roundtrip, de heenweg kan erg in tijd schelen met de terugweg, zeker als de upstream en downstream verschillen (kabel/ADSL is dat meestal nog zo ook), of de hoeveelheid data die daarover heen gaat op dat moment. Dan heb je nog dingen als lagspikes en Out Of Order delivery (zeker als je UDP gebruikt, wat de meeste games toch wel doen gezien de traagheid van TCP), die ook nog eens allemaal gefaked moeten worden. Het is dus moeilijk om aan de hand hiervan te werken, het is moeilijk verschil te maken tussen wie wel cheat en wie niet (zeker als de latency hoger is), en je wilt toch echt niemand straffen die niet cheat!.
Het kleinste misbruik al irritant kan zijn, stel jij schiet een raket op me af en ik spring opeens 2 keer zo snel weg, of jij nou ziet dat ik dat doe of niet, het is niet eerlijk. (Sterker nog cheats die je niet kan zien zijn zo mogelijk nog irritanter).

[Sponge]

De enige garantie die je hebt om dit te vertrouwen is de obscurity van je protcol en je excecutable. Vele game designers vertrouwden daar vrijwel op met als gevolg dat er in vele games mensen met 400 KM/u voorbij komen wandelen.

Zelf hebi k eens geklooid met iemand anders in zijn multiplayer spel. (ook in de ruimte ). Kan geen namen noemen helaas, maar het kwam er op neer dat de snelheid in absolute waarde rechtsboven stond, als deel van de interface.

* Sponge start geheugen waarde-op-zoek-programma, en begint te zoeken, gaat iets harder, opnieuws zoeken, etc.

Nou, na een minuut had ik dus de geheugen locatie van die snelheidsvariabele. 10000 [enter], en de planeten gingen zowat in strepen voorbij!!

_{(Ga zo weer verder, maar praag is er weer op het nieuws.., brb!)}

[Zoijar]

Visibility is een ander groot cheat probleem. Als de client data krijgt over alle speler posities (wat heel vaak zo is) dan kan je heel makkelijk bv in een wireframe world spelen en iedereen zien. Ik zou dus als regel nog iets van "Rule #10: Provide the client only with the absolute minimum of state/data needed to function correctly" toevoegen. Dit is wederom weer een algemeen security begrip. Het klassieke voorbeeld is de foutmelding combinatie "wrong username" en "wrong password", waarbij je op geldige usernames kan scannen.

[Zoijar]

41.6C.6D.61.72 schreef op 15 augustus 2002 @ 18:04:
[...]


Nou, na een minuut had ik dus de geheugen locatie van die snelheidsvariabele. 10000 [enter], en de planeten gingen zowat in strepen voorbij!!

Goed voorbeeld. Een secure client/server app zou dus niet de snelheid op de client opslaan, maar het alleen mogelijk maken om de server een packet te sturen met "ik versnel, of ik vertraag" en de server zegt dan "ok dat kan(niet), je snelheid is nu"

[TheOneLLama]

Zoijar schreef op 15 augustus 2002 @ 18:15:
Visibility is een ander groot cheat probleem. Als de client data krijgt over alle speler posities (wat heel vaak zo is) dan kan je heel makkelijk bv in een wireframe world spelen en iedereen zien. Ik zou dus als regel nog iets van "Rule #10: Provide the client only with the absolute minimum of state/data needed to function correctly" toevoegen. Dit is wederom weer een algemeen security begrip. Het klassieke voorbeeld is de foutmelding combinatie "wrong username" en "wrong password", waarbij je op geldige usernames kan scannen.

En wederom komt het "playability vs. security" onderwerp boven. Ik noemde eerder al het voorbeeld van iemand die achter je staat (die je niet hoort te kunnen zien) waarvan je wel de positie weet. De reden hierachter is natuurlijk dat als je een snelle 180 graden draai maakt je wel wilt kunnen zien wie er achter je staan zonder op de server te wachten voor het creeeren van nieuwe entiteiten. Hetzelfde voor iemand die door een deuropening naar je toe komt ofzo.. de server moet dus een soort berekening maken van wie er allemaal binnen jou latency in je gezichtveld zou kunnen komen, etc. In een 3D FPS kan dat best moeilijk zijn.
Echter is het heel vaak ook mogelijk bij bv. een RTS (units in de fog of war zien), terwijl juist daar het makkelijker zou moeten zijn. Een ander probleem bij RTS spellen is trouwens vaak dat je ook de server niet kunt vertrouwen aangezien die vaak op 1 van de clients draait

[Sponge]

Ja, het moet wel kunnen, maar het belangrijkste is dat je dus de waarde of NIET laat zien, of je het codeerd (staat ook in een van de gamasutra artikelen dacht ik)

bijv door een simpele Xor operatie.

De beste manier om dingen te zien is dat de server 'screenshots' ziet hoe de speler het moet zien. Uiteraard is het met het huide internet geen optie, al heb ik een keer uitgerekend dat het moet kunnen op 640x480 met een lage fps, in png/jpg

Oh ja over de roundtrip tijd:

Als je de tijd synchroniseert (kan binnen ~<10ms), kun je de tijd wel bepalen door wat eigen "ping packets te versturen:

Client zet 1000 in packet
Server zet aankomst tijd in packet (erbij), 1200
Packet komt weer aan bij client op 1300

server tijd - eerste zend tijd = 200ms heen
aankomst tijd bij client - server tijd = 100ms terug

Synchronizing network clocks

(sowieso een goede aanrader: http://www.codewhore.com, onderaan!)

[Sponge]

TheOneLLama schreef op 15 augustus 2002 @ 19:11:
[...]


En wederom komt het "playability vs. security" onderwerp boven. Ik noemde eerder al het voorbeeld van iemand die achter je staat (die je niet hoort te kunnen zien) waarvan je wel de positie weet. De reden hierachter is natuurlijk dat als je een snelle 180 graden draai maakt je wel wilt kunnen zien wie er achter je staan zonder op de server te wachten voor het creeeren van nieuwe entiteiten. Hetzelfde voor iemand die door een deuropening naar je toe komt ofzo.. de server moet dus een soort berekening maken van wie er allemaal binnen jou latency in je gezichtveld zou kunnen komen, etc. In een 3D FPS kan dat best moeilijk zijn.
Echter is het heel vaak ook mogelijk bij bv. een RTS (units in de fog of war zien), terwijl juist daar het makkelijker zou moeten zijn. Een ander probleem bij RTS spellen is trouwens vaak dat je ook de server niet kunt vertrouwen aangezien die vaak op 1 van de clients draait

Tsja, maar neem nou Unreal Tournament. Heb je bijvoorbeeld een map genaamd "Ancient Arena". Er zijn wat vreemde plaatsen i ndie map dat je opeens een heel ander stuk ziet! of Liandri Central Core. Een grote gat in het midden, wat een (dodelijke) teleport is naar boven. Schiet je er door heen, dan zie je je eigen wapen van boven komen . Dat geld dus ook voor de 'bots' van de spelers. hard to tell, voor de server.

sowieso als de user opeens teleport naar een andere plaats, dan moet er alsnog de posities van de bots weer toegezonden worden, wat dus altijd later is, dus de client ziet eerst niets. online programmeren blijft altijd interessant

[.oisyn]

[nohtml]

TheOneLLama schreef op 15 augustus 2002 @ 17:48:
[...]


Als je dit zo gaat bekijken met het perspectief "vertrouw enkel de server", dan krijg je de volgende situatie: stel ik heb 500ms lag. Ik ga vooruitlopen. 250ms later berijkt dit de server. De server stuurt direct een correctie: je bent pas 250ms later met lopen begonnen. Deze correctie komt 250ms later weer aan bij mij (de client) en ik word 500ms nadat ik naar voren ben gaan lopen opeens naar achteren geworpen: weg voordeel van de prediction.

dat klopt, daarom moet je de tijd waarop een knop is ingedrukt ook meesturen
(let wel dat 500 ms over het algemeen niet geldt als speelbare ping... zeker niet met zo'n algoritme)

Je kan dit oplossen door de client z'n woord te nemen op wanneer deze begon te lopen, maar dat is onveilig!

Je kan ook gewoon, in plaats van de client blindelings op z'n woord te vertrouwen, kijken of die tijd enigzins consistent is met de rest

proberen via mechanismes de integriteit van het tijdstip wat de client opgeeft te verhogen (zoals het al zegt: verhogen.. je kan dit niet nou eenmaal niet waarborgen, dat wordt nooit 100% veilig).

dat zeg ik
je zult altijd een trade-off moeten maken, daar ontkom je gewoon niet aan. Maar je kunt wel zorgen dat het zo kloppend mogelijk is.
Natuurlijk is het dan niet 100% veilig tegen cheaten, maar zeg nou zelf, hoeveel ruimte voor cheaten blijft er over? Dat een client opgeeft dat een knop 25ms eerder is ingedrukt dan werkelijk?

Een andere oplossing is, laat die client maar lekker doorlopen, hij denkt dan wel dat ie een beetje ergens anders loopt maar ach. Dan krijg je natuurlijk een probleem als die client ergens op gaat schieten, de client denkt dat ie iets raakt (en ziet bloed in het rond vliegen), terwijl ie op de server mis schiet.

zoals je zelf al aangeeft is dat niet echt een optie

De oplossing ligt vaak in het midden. Maar het probleem is dat als je hier de oplossing in het midden legt, is dat die ergens tussen security en speelbaarheid in ligt.

zoals ik al zei, dat hou je toch wel

Dat de client zelf al een granaat spawned is dus zinloos hier, want na de roundtrip moet ie dat ding weer verplaatsen naar waar ie werkelijk vandaan komt.

een spawn bestaat meer dan alleen een positie, richting en tijdstip, en gespawned worden moet er toch wel. Kun je net zo goed gelijk doen (ook al is het onzichtbaar) zodat je op bericht van de server gelijk de entitiet kan toewijzen

Alleen als de prediction van de stuiter tegen de medespeler op een tijdstip plaatsvind waarover nadat de prediction is uitgevoerd nog updates komen moet er een correctie plaatsvinden. Die kan de client echter zelf doen mbv. de nieuwe gegevens.

klopt idd

En daarmee werp je ons mooi van theorie de praktijk in
Ik heb een keer zelf een posting gelezen van iemand die een engine gemaakt had op zo'n manier die beweerde dat AMD's en Intel's niet bij alle FP berekening dezelfde uitkomst gaven.

tenzij je een heel complex collision model hebt zijn floating point afwijkingen niet zo heel erg belangrijk en vrijwel niet zichtbaar voor het blote oog en de hersenen. (zo van: heej dat klopt niet, die rocket was eigenlijk 0.001 units naar rechts zodat ie net wel tegen de muur kwam ipv ernaast. CHEATERS!)

Wat gelijk mooi aangeeft dat Quake 1, 2 en dus ook 3 kennelijk security opofferen voor speelbaarheid door de client (een deel van) z'n positie te laten berekenen.

nee, je moet alleen zorgen dat de server op 125 fps draait

De enige garantie die je hebt om dit te vertrouwen is de obscurity van je protcol en je excecutable. Vele game designers vertrouwden daar vrijwel op met als gevolg dat er in vele games mensen met 400 KM/u voorbij komen wandelen.

uiteraard, daarom stond het stukje wat daarna kwam er ook bij

De "Ping" is er ontbetrouwbaar.. het enige wat je weet is namelijk de roundtrip, de heenweg kan erg in tijd schelen met de terugweg, zeker als de upstream en downstream verschillen (kabel/ADSL is dat meestal nog zo ook), of de hoeveelheid data die daarover heen gaat op dat moment. Dan heb je nog dingen als lagspikes en Out Of Order delivery (zeker als je UDP gebruikt, wat de meeste games toch wel doen gezien de traagheid van TCP), die ook nog eens allemaal gefaked moeten worden. Het is dus moeilijk om aan de hand hiervan te werken, het is moeilijk verschil te maken tussen wie wel cheat en wie niet (zeker als de latency hoger is), en je wilt toch echt niemand straffen die niet cheat!.
Het kleinste misbruik al irritant kan zijn, stel jij schiet een raket op me af en ik spring opeens 2 keer zo snel weg, of jij nou ziet dat ik dat doe of niet, het is niet eerlijk. (Sterker nog cheats die je niet kan zien zijn zo mogelijk nog irritanter).

Halve ping was misschien een slecht voorbeeld idd, maar ook niet meer dan als dat bedoeld: een voorbeeld. Maar als iemand een knop indrukt en het pakketje doet er meer dan een seconde over kun je je ook gewoon afvragen of het sowieso wel zinnig is om zo'n persoon in de game te laten... ook al is ie eerlijk. Want zeg nou zelf, wil jij spelen met een ping van 2 ms?

Zelfde geldt voor package loss. Als de client een pakketje verstuurt met een commando erin en die raakt zoek, dan klopt het ook niet meer. Imho is het de taak van de client dat te detecteren (de server acknowledged dat pakketje niet), en zich aan te passen aan de nieuwe situatie (positie van de speler enz. opnieuw opvragen). Okee, dit kan resulteren in een schok. Je kunt daar moeilijk over gaan doen, of gewoon accepteren dat je netwerk niet voldoet aan de eisen van het spel (package loss is toch al iets wat weinig voorkomt, zeker met de apparatuur van tegenwoordig. Als je er last van hebt dan is het meestal ook niet maar 1 pakketje maar gewoon 50% van alle packets, omdat er problemen zijn met een router in het netwerk. Compenseren hiervoor zou nutteloos zijn imho)

[ Voor 0% gewijzigd door .oisyn op 15-08-2002 19:43 . Reden: typo ]