Mag je het netwerkprotocol van een online game uitpluizen?

| AE 8580 | Security | 15 reacties

rink-springer-romdumpEen tijd geleden ontdekte ontwikkelaar Rink Springer het spel Runes of Magic. En zoals dat gaat bij hackers: je raakt op het spel zelf uitgekeken, dus dan ga je kijken hoe het op de achtergrond werkt. In dit geval door het netwerkprotocol van het spel uit elkaar te trekken en te documenteren. Hetgeen uiteindelijk leidde tot een lezing op de CCC vorig jaar. Eh, maar mag dat eigenlijk wel?

Runes of Magic is een free-to-play online MMORPG (oneerbiedig gezegd een World of Warcraft-kloon). Je speelt het op je eigen PC, waarbij het spel allerlei gegevens opstuurt naar de server om je zo met anderen mee te laten spelen. En dat is nou typisch het soort “onder de motorkap”-gebeuren waarvan je graag zou willen weten hoe het werkt.

Met een simpele netwerktool (tcpdump en tcpflow) slaagde Springer erin om het gebruikte protocol te achterhalen. Hij ontwikkelde zelfs een tool (romdump) dat het hem makkelijker maakte om gegevens te decoderen en vervolgens te herkennen. Zo kon hij onder meer de algemene structuur achterhalen van pakketjes informatie over rondlopende spelpersonages.

Vervolgens ontwikkelde hij een transparante proxy tussen de client en de officiële servers, die al het netwerkverkeer kon opnemen voor realtime analyse. Erg handig bij zulk nieuwsgierig speurwerk: zo kun je makkelijk kijken wat de juiste vraag/antwoord-scenario’s zijn (client stuurt pakketje X, is hij tevreden als ie pakketje Y terugkrijgt, etc).

Erg interessant, alleen: mag dat wel? Want reverse engineeren van software, dat was een dingetje onder de Auteurswet immers. En dat klopt. Alleen heeft Springer niet de software uit elkaar getrokken maar de netwerkcommunicatie. En dat mag. Netwerkcommunicatie is openbare data die je mag observeren, en je observaties mag je vervolgens gebruiken zoals je wilt.

Oké, niet helemaal: een nepserver bouwen om mensen op te lichten mag niet, de informatie gebruiken om vals te gaan spelen of jezelf valselijk dure spullen te geven ook niet. En zo zijn er nog wel een paar dingen die problematisch kunnen zijn. Maar dat is een categorie verder dan enkel een protocol uit elkaar halen en constateren: met dit pakketje loggen ze je in, met dat pakket springt je personage over een berg en met dat pakket krijg je een zwaard.

Mag je zomaar al die gegevens publiceren? Daarmee kunnen andere mensen wellicht wel die verboden dingen doen. Dat is een terecht punt, en dat speelt altijd bij responsible disclosure. Publiceer dus alleen neutrale technische informatie en let erop dat die niet triviaal kan worden misbruikt door anderen. Geen kant-en-klare exploits dus. Maar een wetenschappelijke analyse van een netwerkprotocol mag wel.

Het kan anders komen liggen als de leverancier van de software gebruik maakt van beveiliging. Dergelijke beveiligingen omzeilen kan worden gezien als het omzeilen van een softwarebescherming in de zin van de Auteurswet (art. 32a), en dat is onrechtmatig en strafbaar. Het protocol moet dan beveiligd zijn met bv. een sleutel of certificaat. Enkel xor’en van de data (zoals bij dit protocol) is niet genoeg daarvoor.

Bekijk vooral de lezing van Rink!

Arnoud

Deel dit artikel

  1. XOR is toch ook gewoon een encryptiemethode; afhankelijk van hoe lang de sleutel is en hoe deze gegenereerd wordt zelfs potentieel een onbreekbare vorm van encryptie. Bovendien is het toch voor 32a niet nodig dat het een effectieve vorm van versleuteling is? Bijna bij definitie lijkt me, als het effectief was geweest was je er niet in gekomen.

  2. Het hele idee van Responsible Disclosure is toch dat je juist bij problematische beveiliging (uiteindelijk) wel mag publiceren?

    Voorwaarde is dan dat je de fabrikant op de hoogte stelt, niet meer gedaan hebt dan nodig en hem de kans geeft om het op te lossen.

    Als de fabrikant dat dan niet doet, is er een moment dat je kan besluiten om toch te publiceren, in het kader van het beschermen van andere klanten.

    Ja, in principe werkt RD alleen als de fabrikant een RD policy heeft, maar we hebben nu een aantal zaken gezien waarbij het toch als maatstaf gebruikt wordt, ook als de fabrikant het niet heeft.

  3. Het kan anders komen liggen als de leverancier van de software gebruik maakt van beveiliging. Dergelijke beveiligingen omzeilen kan worden gezien als het omzeilen van een softwarebescherming in de zin van de Auteurswet (art. 32a), en dat is onrechtmatig en strafbaar. Het protocol moet dan beveiligd zijn met bv. een sleutel of certificaat. Enkel xor’en van de data (zoals bij dit protocol) is niet genoeg daarvoor.

    Art. 32a spreekt van het “verwijderen of ontwijken van een technische voorziening ter bescherming van een werk”. Ik denk daarbij aan voorzieningen zoals DRM die het onmogelijk maken om het programma op meerdere pc’s te installeren. De communicatie daarvoor (zoals het het ‘gesprek’ tussen een Windowsinstallatie en de activatieserver van Microsoft) mag je wellicht niet ontsleutelen (hoewel ook dan de vraag is of de ontsleuteling dient ter ‘verwijderen of ontwijken van een technische voorziening’). Ik zie niet waarom versleutelde communicatie tussen het spel en de gameserver hieronder zou vallen. Die versleuteling dient niet “ter bescherming van een werk”. Zelfs als je op basis van die communicatie een eigen cliënt maakt, is dat geen inbreuk op het auteursrecht op het oorspronkelijke spel, omdat de broncode van dat spel niet is gekopieerd.

    • Dat is een groot grijs gebied inderdaad. Je kan ook stellen dat de gameplay van het spel onderdeel is van het “werk” wat het spel omvat, en alle gameplay-gedrag wordt bij een MMORPG op de server afgehandeld. Zet je er een andere server achter, dan verander je die gameplay.

      In het verleden zijn er bijvoorbeeld private servers van World of Warcraft met juridische stappen uit de lucht gehaald op dat argument. Ik ben wel beneuwd of zo’n juridisch argument ook steek zou houden als je het protocol compleet zou analyseren en from scratch een nieuwe server zou maken die de originele server emuleert, zonder dat je daarvoor stukken van de originele server-broncode gebruikt.

    • Ik denk dat deze discussie staat of valt bij de vraag wat onder de “bescherming van het werk” (art. 32a Aw) verstaan wordt. Als we “het werk” slechts zien als een stuk client-software zien, dan is er geen probleem. Het lastige zit hem in het feit dat de game aan het internet gebonden is voor (een deel van) haar funktionaliteit. Een gamemaker kan dan beargumenteren dat “het werk” inclusief de gehele user experience is, en dus ook de online-communicatie. Daarmee wordt het netwerk-protocol, dwz. de communicatie tussen client en server, onderdeel van het beschermde werk.

      Dit alles past echter niet zo goed in het auteursrecht. We hebben het namelijk over het beïnvloeden van de functionaliteit, en iets wat je met een werk kunt doen past nu eenmaal niet in het auteursrecht: dat ik iemand kan slaan met een boek heeft met de auteur niets te maken.

      De andere kant is goed te beargumenteren. Als ik een zelfgebakken server maak (met behulp van de netwerkprotocolanalyse) heb ik het oorspronkelijke werk, dat wil zeggen het stuk software op de computer van de gamer, überhaupt nooit aangeraakt. Dat ik de gamer help om de werking van zijn (legitieme) kopie van de software te veranderen, lijkt me nou typisch iets wat niet binnen het auteursrecht valt.

Laat een reactie achter

Handige HTML: <a href=""> voor hyperlinks, <blockquote> om te citeren en <em> en <strong> voor italics en vet.

(verplicht)

Volg de reacties per RSS