Tag: Reverse engineeren

About Reverse engineeren

Subscribe Feeds

Mag je het netwerkprotocol van een online game uitpluizen?

Geplaatst op in 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

Mag je software reverse engineeren om fouten te vinden?

Geplaatst op in Intellectuele rechten, Security, 31 reacties

Een lezer vroeg me:

Is reverse engineering legaal als het doel is om beveiligingslekken te vinden? Jij zei ooit van wel, maar in de wet staat volgens mij dat je alleen mag reverse engineeren om compatibiliteit te realiseren.

Oef, dat is lang geleden, maar inderdaad:

Alleen die vormen waarmee je compatibiliteit met zelfgeschreven software wilt bewerkstelligen, of waarmee je alleen de achterliggende ideeën, concepten en principes achterhaalt zijn legaal. Met name is het niet legaal om de informatie te gebruiken om een kloon van de software te maken.

Waar de vraagsteller naar refereert, is het wetsartikel dat het eerste deel van die zin onderbouwt:

Als inbreuk op het auteursrecht op [software], worden niet beschouwd het vervaardigen van een kopie van dat werk en het vertalen van de codevorm daarvan, indien deze handelingen onmisbaar zijn om de informatie te verkrijgen die nodig is om de interoperabiliteit van een onafhankelijk vervaardigd computerprogramma met andere computerprogramma’s tot stand te brengen, mits: (bla)

Dit is inderdaad beperkt tot reverse engineeren met als doel het maken van een interoperabel eigen programma. Soms is het daarvoor nodig dat je de broncode van andere software achterhaalt, omdat je anders onvoldoende informatie hebt over hoe je eigen software moet gaan werken. Het vinden van een fout in software is natuurlijk niet hetzelfde als “interoperabiliteit tot stand brengen”, tenzij je zegt “ik moet weten hoe die fout werkt want ook daarin moet ik compatibel zijn”.

Er is echter nog een ander artikel dat specifieker op fouten ziet:

De verveelvoudiging, als bedoeld in de eerste zin, die geschiedt in het kader van het laden, het in beeld brengen of het verbeteren van fouten, kan niet bij overeenkomst worden verboden.

Reverse engineeren is een vorm van verveelvoudigen. Dat is waarom deze actie in principe inbreuk op het auteursrecht maakt. Echter, dit artikel verklaart het verveelvoudigen ter herstel van fouten legaal (zelfs als in de EULA staat dat dat niet toegestaan is). Daarom zou dit volgens mij toch gewoon toegestaan zijn.

Dus ik geloof dat ik toch gelijk had, hoewel om een andere reden dan ik zei 🙂

Arnoud

De legaliteit van het uit elkaar halen van een stuk hardware

Geplaatst op in Security, 12 reacties

componenten-delen-onderdelen-partsEen lezer vroeg me:

Stel je hebt een bestaand apparaat (een versterker) en je gaat de elektronica reverse engineeren. Je haalt de printplaat uit het apparaat, neemt potlood, papier en datasheets en je begint uit te knobbelen hoe het apparaat precies werkt. Vervolgens digitaliseer je het zelf getekende schema en ga je het posten op een forum. Mag dat? Het voelt als iets waar vast een wet tegen zal zijn.

Als daar een wet tegen is, dan moet ik die nog tegenkomen. Als je een product koopt, mag je dit uit elkaar pluizen en anderen uitleggen hoe het werkt. Ook bij huur of leen, hoewel je dan wel “als een goed huisvader” moet zorgen voor het produc dus alleen uit elkaar halen wat je ook weer in elkaar kunt zetten.

Heb je het apparaat als demonstrator gekregen of een geheimhoudingscontract getekend) dan ligt dit moeilijker, maar in zulke situaties zou je ook op de hoogte gesteld moeten zijn van beperkingen.

Natuurlijk zijn er intellectuele-eigendomsrechten, zoals het auteursrecht of het octrooirecht. Een auteursrecht schenden met een technisch ontwerp is haast ondenkbaar, zeker als je dat zelf getekend hebt. Dat eigen ontwerp bevat alleen de feitelijke kennis over het origineel, en feiten kunnen niet onder het auteursrecht vallen.

Feitelijke kennis neergeslagen in een apparaat kan onder een octrooi (patent) vallen. Maar dat is pas aan de orde wanneer je het ontwerp gaat bouwen en verkopen. Ja, voor jezelf bouwen mag – octrooien schend je pas bij bedrijfsmatig gebruik van de uitvinding.

De enige uitzondering hier zou kunnen zijn als hetgeen je uit elkaar haalt een kopieerbeveiliging voor muziek of films betreft. De Auteurswet verbiedt in art. 29a het omzeilen van doeltreffende kopieerbeveiligingen (en de DMCA doet in de VS iets vergelijkbaars). En omdat dat lastig te bewijzen/aan te pakken is, is er ook een “hulpmiddelen”-artikel toegevoegd in lid 3:

Degene die diensten verricht of inrichtingen, producten of onderdelen vervaardigt, invoert, distribueert, verkoopt, verhuurt, adverteert of voor commerciële doeleinden bezit die:<br/> a) aangeboden, aangeprezen of in de handel gebracht worden met het doel om de beschermende werking van doeltreffende technische voorzieningen te omzeilen, of<br/> b) slechts een commercieel beperkt doel of nut hebben anders dan het omzeilen van de beschermende werking van doeltreffende technische voorzieningen, of<br/> c) vooral ontworpen, vervaardigd of aangepast worden met het doel het omzeilen van de doeltreffende technische voorzieningen mogelijk of gemakkelijker te maken,<br/> handelt onrechtmatig.

Het enkel publiceren van informatie (dus een blauwdruk) wordt hier niet genoemd, en ook het publiceren an sich niet (hoewel dat “distribueren” zou kunnen zijn). Een stuk software aanbieden valt onder “inrichtingen, producten”, dus dan kom je wél in de problemen. Ik denk dus dat ook dit het probleem niet moet zijn, tenzij je er heel nadrukkelijk bij gaat zeggen dat je zo gratis betaalde films kunt kijken.

Arnoud

Wanneer is een API reverse engineeren computervredebreuk?

Geplaatst op in Security, 28 reacties

chip-paspoort.jpgEen lezer vroeg me:

Onlangs is de OV-Chipkaart app uitgekomen. Uit analyse blijkt dat de app per request een specifieke signature meestuurt, en zonder die signature komt er geen reactie vanuit de server van Trans Link Systems. De methode waarop de signature gemaakt wordt is te achterhalen met decompileren en daarna eenvoudig na te maken. Het is erg moeilijk te achterhalen door puur naar het verkeer te kijken. Mijn vraag is: als iemand API calls doet op basis van die kennis, is er dan sprake van computervredebreuk?

Als ik het goed begrijp, dan doet die app dus aanroepen op de server van TLS. Om te bewijzen dat de app echt de app is, wordt daarbij een signature/code gemaakt op basis van een sleutel die in de app aanwezig zit. Heb je de sleutel, dan kun je dus de code namaken en je eigen aanroepen als echt presenteren.

Van computervredebreuk is sprake als je binnendringt in andermans computer. Een ov-chipkaart is een computer, en die heb je te leen van TLS. Binnendringen daarin is dus mogelijk. Maar een app op je eigen telefoon, daar kun je niet in binnendringen. De app is geen ‘geautomatiseerd werk’, de telefoon wel maar die is van jezelf.

Binnendringen in de server van TLS is mogelijk en dat kan wel computervredebreuk zijn. Alleen, er moet dan sprake zijn van binnendringen zonder recht, wederrechtelijk dus. Je zegt dan, je mag inloggen met de app maar handmatig/eigen app inloggen mag niet. Ik twijfel of dat werkt. Als ik zeg “hier is de sleutel” en jij maakt een sleutel erbij, dan pleeg je geen huisvredebreuk als je met die extra sleutel binnengaat. Het gaat om de plek waar je mag zijn, niet het middel waarmee je daar komt. Een undocumented feature aanroepen door de API-URL te manipuleren (misschien doet &debug=1 iets leuks?) zou ik wel computervredebreuk noemen.

Auteursrechtelijk is het spannender. Je decompileert en achterhaalt de werking van de app. Als het doel dan is een kloon van de app te maken, dan botst dat met het auteursrecht op de app. Maar ‘kloon’ is een beperkt begrijp. En een nieuwe app die alleen dezelfde API calls doet, zou ik niet snel een ‘kloon’ noemen. De wet hanteert “computerprogramma, dat niet als een nieuw, oorspronkelijk werk kan worden aangemerkt” als criterium. Dus echt pure nabouw, dezelfde functionaliteit en layout.

Je kunt je ook afvragen of je wel de ‘werking’ van de app aan het achterhalen bent. Je wilt in feite alleen het algoritme voor het maken van de code achterhalen, en natuurlijk het element zelf dat daarvoor nodig is. Hoe de rest van de app werkt, is minder van belang.

Arnoud

Mag ik een API reverse engineeren voor mijn eigen app?

Geplaatst op in Intellectuele rechten, 43 reacties

zoeken-harde-schijf.jpgEen lezer vroeg me:

Steeds meer sites en platforms komen tegenwoordig met een eigen mobiele app, maar lang niet altijd zo handig als wel zou kunnen. Nu werken deze apps met op de achtergrond een API (application programming interface) die ik met mijn eigen app ook zou kunnen aanroepen. Maar mag ik hun app reverse engineeren om zo te achterhalen hoe die API van hen in elkaar steekt?

Reverse engineering, oftewel iets uit elkaar pluizen om te zien hoe het werkt, is in het algemeen toegestaan om principes en ideeën te achterhalen. De Auteurswet bevat een verbod op reverse engineering, maar dat gaat eigenlijk over decompileren: het reconstrueren van broncode uit een applicatie. Dat is aan meer regels gebonden. Je mag niet een applicatie decompileren om deze te klonen, maar wél om een compatibele app te maken.

Als je een app decompileert om zo de API te achterhalen, dan stap je in een grijs gebied. Enerzijds doe je dit om een eigen (met het platform) compatibele app te maken, maar anderzijds produceer je wel een soort van kloon van die “officiële” app, en dát mag dus niet. Gelukkig is het meestal genoeg om het dataverkeer te observeren en daaruit af te leiden hoe de API werkt. En dát mag altijd.

Een bijzonder geval ontstaat wanneer de API of het platform gericht is op het ontsluiten van een databank. Als zo’n databank beschermd is door een databankrecht, dan is jouw app mogelijk in strijd met dat recht, want hij biedt dan een middel voor de voorbehouden handeling van

het herhaald en systematisch opvragen of hergebruiken van in kwalitatief of in kwantitatief opzicht niet-substantiële delen van de inhoud van een databank, voorzover dit in strijd is met de normale exploitatie van die databank of ongerechtvaardigde schade toebrengt aan de rechtmatige belangen van de producent van de databank.

Ja, hele mond vol maar het is ook een draak van een wet. Even kijken: je app vraagt herhaald en systematisch data op, check. Per query is de inhoud niet substantieel (niet 90% van de databank), check. (En haal je wél substantieel de hele databank op dan ga je sowieso onderuit onder het databankenrecht.) Is het in strijd met de normale exploitatie of rechtmatige belangen van de producent? Ah, daar zit hem de kneep.

Ik zou zeggen dat wanneer de app hetzelfde soort functionaliteit biedt (maar dan handiger) als de officiële app, er niet snel strijd met normale exploitatie kan ontstaan. Als er een inkomstenstroom zit aan de officiële app (al zijn het maar advertenties) dan wordt het spannend want jouw app omzeilt die dan. En als je met jouw app iets gratis kunt opvragen dat normaal geld kost, dan zie ik ook wel een databankrechtelijk probleem.

Een app die iets heel nieuws doet op basis van een bestaande API, lijkt me in principe niet snel een probleem zolang er geen overlast komt door bv. onevenredig veel opvragingen. Stel je kunt op de Artis-site via een API de voedertijden opvragen, en jij maakt een app over apen (haha, hij zei apie en dat lijkt op API) die onder meer laat zien waar je in Amsterdam apen kunt bewonderen, inclusief de voedertijden van Artis, dan zie ik niet welk belang van Artis hier geschaad zou worden.

Dat zal rechthebbenden er echter niet van weerhouden met juridische dreigbrieven te komen. Of, iets praktischer, de opvragingen vanuit jouw app detecteren en blokkeren. En dat laatste mogen ze, ook als daar eigenlijk geen reden voor is. Het is hun server en willen ze jou niet faciliteren, dan houdt het op.

Arnoud

Mag Skype worden gereverse engineered?

Geplaatst op in Innovatie, Intellectuele rechten, 25 reacties

see-figure-one.pngEen beveiligingsonderzoeker heeft het gedrag van de VoIP-software Skype onderzocht. Op basis van die reverse engineering heeft hij een groot deel van de code achterhaald, meldde Webwereld vrijdag. Daarop, zo meldde Phoronix, vloog Skype meteen in de tegenaanval, met gestrekt been, Zidane-kopstoot én kruistrap:

This unauthorized use of our application for malicious activities like spamming/phishing infringes on Skype’s intellectual property. We are taking all necessary steps to prevent/defeat nefarious attempts to subvert Skype’s experience. Skype takes its users’ safety and security seriously and we work tirelessly to ensure each individual has the best possible experience.

Nu kun je natuurlijk “gatver wat een rotopmerking” zeggen, maar we zijn hier een keurig juridisch blog (niet lachen daar achterin), dus laten we eens kijken naar de achterliggende vraag: mag je Skype reverse engineeren en daarmee je eigen Voice-over-IP-client op de markt brengen?

Reverse engineeren is een algemene term voor het uit elkaar halen van een product (of software) om te zien hoe dit opgebouwd is. Specifiek voor software worden ook wel termen als disassembleren of decompileren gebruikt, maar algemeen gesproken komen ze op hetzelfde neer: de software wordt uit elkaar geplozen en geanalyseerd om te zien hoe deze werkt. Omdat hierbij een kopie van de software wordt gemaakt, valt dit in principe onder het auteursrecht.

De Auteurswet zegt dat software mag worden gereverse-engineerd om interoperabiliteit van zelf ontwikkelde software met andere software tot stand te brengen. Zo mag een ontwikkelaar een eigen driver maken om de (embedded) software in de grafische kaart te kunnen besturen. Hij mag daarvoor de bestaande driver pakken en deze disassembleren: de binaire code uit elkaar halen om zo in één keer te zien wat de driver allemaal voor commando’s kan versturen en ontvangen. Ook mag hij het communicatieprotocol observeren en daarmee achterhalen hoe zijn eigen software moet werken.

Een lastige beperking aan het recht om te reverse engineeren is dat het moet gaan om het interoperabel maken van eigen software. In veel gevallen is het doel van reverse engineering eerder het maken van eigen software die hetzelfde doet als de software die uit elkaar wordt gehaald. Het “klonen” van software via reverse engineering is echter expliciet verboden. Het voorbeeld van de driver hierboven is een grensgeval: weliswaar wordt de driver een soort van gekloond, maar het doel is om de eigen software met de software in de kaart te laten werken.

In de praktijk is dit lastig werkbaar: wie een driver disassembleert en dan een nieuwe driver maakt, zal al héél snel ” bewust of onbewust ” auteursrechtelijk beschermde delen overnemen. Als best practice geldt daarom het principe van de “Chinese muur”, waarbij twee teams samenwerken bij de ontwikkeling van software op basis van reverse engineering. Team A haalt de oorspronkelijke software uit elkaar en documenteert de functionaliteit. Team B ontvangt alleen deze documentatie en krijgt geen toegang tot de oorspronkelijke software. Daarmee kan team B zelf software maken zonder “besmet” te zijn met de gereverse-engineerde broncode.

Speciaal voor protocollen ligt het net weer anders: je mag netwerkverkeer observeren en daaruit achterhalen hoe een protocol werkt. Als je dan zonder andermans client of server te bekijken je eigen implementatie van dat protocol maakt, is er juridisch niets aan de hand. Dat reverse engineeren van een protocol is niet waar de Auteurswet op doelt. Maar in het Skype-geval is niet alleen netwerkverkeer geanalyseerd maar ook de client van Skype zelf.

Arnoud<br/> Afbeelding: Revealing Skype Traffic: When Randomness Plays with You, Dario Bonfiglio et al., SIGCOMM”07, August 27″31, 2007, Kyoto, Japan.

Mag reverse engineering bij EULA verboden worden?

Geplaatst op in Security, 8 reacties

multimeter2.jpgEen lezer vroeg zich af:

Is het rechtsgeldig in Nederland om in een EULA reverse engineering van een softwarepakketgeheel te verbieden, ook voor toepassingen als het maken van interoperable software?

Reverse engineering, in goed Nederlands decompilatie, is volgens artikel 6 van de Software-richtlijn een handeling die geen inbreuk op het auteursrecht oplevert.

Desondanks zie je regelmatig in EULAs een tekst als “reverse engineering is forbidden”, maar dat heeft geen juridische waarde. Artikel 9 lid 1 van diezelfde Richtlijn bepaalt dat “elk contractueel beding dat strijdig is met artikel 6” nietig is. Oftewel, de rechthebbende kan zich op zo’n beding niet beroepen, en doet hij het toch dan hoef je alleen maar naar deze artikelen uit de richtlijn te verwijzen.

Een goed geschreven EULA of softwarelicentie bevat dan ook een tekst als “reverse engineering is verboden voor zover dat juridisch toegestaan is”. Niet alle vormen van reverse engineering zijn namelijk toegestaan onder de Richtlijn. Alleen die vormen waarmee je compatibiliteit met zelfgeschreven software wilt bewerkstelligen, of waarmee je alleen de achterliggende ideeën, concepten en principes achterhaalt zijn legaal. Met name is het niet legaal om de informatie te gebruiken om een kloon van de software te maken.

Arnoud

iPhone jailbreaken, mag dat nou toch?

Geplaatst op in Security, 14 reacties

iphone-unlock-jailbreak.pngMag je je iPhone nou wel of niet unlocken? Over die vraag is veel speculatie, maar Apple heeft zich er altijd over in stilzwijgen gehuld. Althans, tot vorig jaar december toen Apple een commentaar op de DMCA indiende bij het US Copyright Office. De oplettende lezers bij de EFF spotten daarin deze opmerking:

Current jailbreak techniques now in widespread use utilize unauthorized modifications to the copyrighted bootloader and OS, resulting in infringement of the copyrights in those programs. … Jailbreaking () involves infringing uses of the bootloader and OS, the copyrighted works that are protected by the TPMs being circumvented. Unauthorized derivative versions of the bootloader and OS have been created. Copies of those infringing works have been stored on web sites, and infringing reproductions of those works are created each time they are downloaded through Pwnage Tool and loaded onto the iPhone.

Op zich heeft Apple daar een punt. Bij jailbreaks moet de firmware aangepast worden. Hiervoor moet je deze uit de iPhone vissen, door een tooltje halen en in aangepaste vorm terugzetten. Ik begrijp niet helemaal waar Apple de stelling op baseert dat mensen die firmware op internet zet, maar het lijkt me duidelijk dat dat niet toegestaan is. Andermans software verspreiden vereist een licentie, en die is er niet voor software.

Maar mag je voor jezelf de firmware uit apparaten aanpassen? De EFF vindt van wel, en kwam met dit briljante argument:

But the courts have long recognized that copying software while reverse engineering is a fair use when done for purposes of fostering interoperability with independently created software, a body of law that Apple conveniently fails to mention.

Een recht dat wij in Nederland kennen in artikel 45m Auteurswet. Het maken van een kopie van een stuk software en het “vertalen van de codevorm daarvan” (ik vermoed dat men compileren bedoelt) is toegestaan als

deze handelingen onmisbaar zijn om de informatie te verkrijgen die nodig is om de interoperabiliteit van een onafhankelijk vervaardigd computerprogramma met andere computerprogramma’s tot stand te brengen

In de Richtlijn waar dit wetsartikel uit komt, staat dat “deze uitzondering onder meer ten doel heeft het mogelijk te maken alle componenten van een computersysteem, ook die van verschillende fabrikanten, aan elkaar te koppelen, zodat die systemen samen kunnen functioneren”.

En laat dat nou precies het doel zijn van jailbreaken: applicaties te laten werken op het OS van Apple, ook als ze niet door Apple zijn goedgekeurd.

Slim gevonden, nietwaar?

Arnoud<br/> Foto via Crunchgear.

De legaliteit van reverse engineeren – hardware en drivers

Geplaatst op in Intellectuele rechten, Security, 5 reacties

multimeter2.jpgHet is toegestaan om te achterhalen hoe dingen werken. Heb je een mooie grafische kaart gekocht, en wil je weten welke signalen deze afgeeft, dan mag je gerust met je multimeter aan de slag. Wil je zien hoe je televisie er van binnen uitziet, veel plezier met de schroevendraaier. De garantie vervalt natuurlijk wel, maar dat terzijde.

Wil je met die informatie een eigen product bouwen, dan mag dat ook. Ideeën en technische principes zijn vrij. Daar is één uitzondering op: je kunt tegen octrooien aanlopen natuurlijk. Voor een octrooi maakt het niet uit of je het product zelf gemaakt hebt of hebt afgekeken: als het doet wat in het octrooi staat, pleeg je inbreuk.

Afgezien van octrooien is het reverse engineeren van de werking van hardware dus legaal. Dat is erg handig voor bijvoorbeeld open source zoals Linux, waarvoor minder aanstuursoftware (drivers) voor hardware beschikbaar is dan bij Windows. Een open source-ontwikkelaar mag dus kijken welke commando’s er van de driver op de PC naar een hardwarekaart (of terug) gestuurd worden en welk effect dat heeft. Hij kan daarmee zijn eigen driver maken die op het juiste moment de juiste commando’s stuurt. Dit mag: artikel 45l Auteurswet bepaalt dat een licentienemer van de software mag achterhalen hoe de software werkt “teneinde de daaraan ten grondslag liggende ideeën en beginselen te achterhalen.” Daaronder valt ook het achterhalen van de communicatie tussen de driversoftware en de hardware.

Een nadeel van deze aanpak is dat je dan niet zeker weet dat je alle situaties gehad hebt. Misschien is er wel een commando dat alleen gestuurd wordt als de kaart erg warm wordt, of wanneer iemand een resolutie van 1194×768 pixels gebruikt en een 3D-bal wil laten stuiteren als screensaver.

Een betere oplossing is dan ook de bestaande driver pakken en deze disassembleren: de binaire code uit elkaar halen om zo in één keer te zien wat de driver allemaal voor commando’s kan versturen en ontvangen. Daarmee is dan een nieuwe driver te maken die hetzelfde doet, maar dan voor Linux.

Deze oplossing ligt juridisch iets lastiger. Software is beschermd door auteursrecht. Bij reverse engineeren moet je de software uitvoeren om te kunnen zien wat hij doet. Dat is normaal inbreuk op het auteursrecht. Maar voor deze vorm van reverse engineering is er artikel 45m.

Dit artikel zegt dat je mag reverse engineeren om interoperabiliteit van je eigen software met andere software tot stand te brengen. Bijvoorbeeld dus je eigen driver maken om de (embedded) software in de grafische kaart te kunnen besturen. Het recht is in zoverre beperkt dat je alleen datgene mag reverse engineeren wat je nodig hebt om je eigen driver te kunnen maken.

Dit artikel is natuurlijk ook relevant voor andere soorten software, zoals de vele open source alternatieven voor gesloten software zoals Microsoft Office. Daar kom ik binnenkort op terug, want de situatie is daar iets minder rooskleurig dan bij drivers.

Hoe dan ook, je mag dus een driver reverse engineeren en met de gevonden informatie je eigen driver maken. Wat niet mag, is stukken van de oorspronkelijke driver overnemen in je eigen driver. Dan pleeg je inbreuk op het auteursrecht. Je mag alleen achterhalen wat de driver doet, en vervolgens moet je je eigen software schrijven die dezelfde activiteiten verricht. Zonder te kijken op welke slimme manier de oorspronkelijke software dit doet.

Dat zal bij drivers gelukkig niet altijd een groot probleem zijn. De implementatie van een driver is namelijk voor een groot deel bepaald door de hardware. Er moet nu eenmaal code 0x31337 gestuurd worden om een bepaald beeld op het scherm te tonen, en als de printer de code 0xDEADBEEF stuurt, dan is het papier op en moet het printen tijdelijk ophouden. Daardoor zit er weinig creatieve ruimte voor programmeurs bij het schrijven van drivers. Hoewel dus een nieuwe driver voor een deel zal lijken op het origineel, komt dat door die technisch bepaalde factoren. En iets dat hetzelfde is vanwege een technische eis, is geen inbreuk op het auteursrecht.

Bij dit soort activiteiten wordt wel de bewijslast omgekeerd: als beide drivers hetzelfde doen, moet de maker van de nieuwe driver bewijzen dat hij geen code heeft overgenomen van de oorspronkelijke driver. Vandaar de clean-room praktijk: laat de ene persoon achterhalen en documenteren wat de driver doet, en laat een andere persoon op basis van die documentatie een nieuwe driver schrijven. De andere persoon kan dan geen code hebben overgenomen, want daar had hij geen toegang toe. En de eerste persoon heeft geen code geschreven, en heeft dus ook geen inbreuk gepleegd.

Deze bepalingen zijn dwingend recht. Dat betekent dat dit recht niet in een softwarelicentie (EULA) verboden kan worden. Staat het toch in een EULA, dan zal de rechter die clausule negeren.

Arnoud