Een 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
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.
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.
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.
Petitie om de private World of Warcraft (legacy) server online te houden. Ik ben geen WoW-speler, maar ik ben wel van mening dat dit zou moeten mogen.
Het argument is dat je met je eigen client dan de beveiliging client-server omzeilt. Je kunt met je eigen client immers meer of andere dingen dan met de officiële. Daarmee wordt de beveiliging op de server aangetast.
Dat gaat voor een client op een officiële server natuurlijk op, omdat je dan oneigenlijk spelvoordeel haalt tegenover “betalende” spelers die items moeten kopen. Maar zou je dat argument ook kunnen maken voor private servers die met een officiële client draaien, om bijvoorbeeld het spel nog in de lucht te houden nadat de officiële servers zijn platgegaan?
Dat vind ik persoonlijk geen steek houden. Als de beveiliging er niet is op de server zelf dan is ‘ie er niet. Aangepaste client of niet, je kunt geen beveiliging aantasten die er niet is.
Misschien biedt art. 29a Aw uitkomst? Ik zit niet in deze materie, maar dat artikel zie ik bij een zoektocht vaak langskomen.
Artikel 29a gaat over ‘gewone’ werken, zoals muziek en films. Artikel 32a is specifiek voor software geschreven en gaat daarmee boven artikel 29a. Zie deze noot bij een vonnis Rb Den Haag over de vraag wanneer is software is of een ‘gewoon’ werk. Is een game niet gewoon een interactieve film?
Mijn mond valt open bij het lezen van die noot. Eerst wordt droogjes het business model van Nintendo beschreven (goedkope computers, dure games). So far so good: dit is gewoon een feitelijke beschrijving, die voor zover ik weet gewoon waar is. Wat ik vervolgens NIET zie is kritiek op dat business model; er wordt zelfs kritiekloos van uit gegaan dat dat business model beschermd dient te worden. Vervolgens blijkt de wet daar ook nog middelen voor te bevatten, en besluit de rechter om die middelen toe te passen.
Het mooiste vond ik nog dit fragment:
Kijk, dat is hoe het zou moeten gaan.Daarnaast wordt de dubieuze aanname gedaan dat de middelen voornamelijk gebruikt worden voor het ongeautoriseerd draaien van gekopieerde spellen. Nintendo-apparaten (vooral Gameboy’s) zijn erg populair in de 8-bit music-scene omdat ze zo makkelijk te modificeren zijn. Kortzichtig dus, op z’n minst.
Maar dat is toch net zo bij de thuiskopieheffing? Ik heb gewerkt bij een bedrijf dat ongeveer een miljoen cd’s per jaar brande hierop stond echter geen materiaal dat ze niet mochten dupliceren (gesproken boeken voor blinden en slechtzienden). Echter ook zei moesten deze heffing betalen, al met al toch een groot bedrag voor iets dat aantoonbaar niet wordt gedaan…
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.
Juist. Dit lijkt me de manier om een clean-room implementatie van de server te maken.