Mag je software reverse engineeren om fouten te vinden?

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

31 reacties

  1. Uit de parlementaire geschiedenis bij art. 45j Aw:

    Met het woord ‘noodzakelijk’ wordt tot uitdrukking gebracht dat de desbetreffende handeling technisch absoluut vereist zijn om het programma te kunnen gebruiken overeenkomstig het beoogde doel
    Daarnaast moet noodzakelijk beperkt worden uitgelegd. Ik denk daarom juist niet dat het vinden van beveiligingslekken is toegestaan, omdat de meeste programma’s volledig functioneel zijn ondanks een lek.

    1. Mooie vondst. Ik zou alleen anno 2015 wel durven verdedigen dat het fixen van beveiligingslekken/datalekken een absoluut maatschappelijk vereiste is. Een bug is tegenwoordig niet meer een “oh hij doet het niet, even herstarten” maar “oh er staan nu 20.000 klantgegevens bloot aan misbruik” of “oh ik ben deel van een botnet”. Dat fixen lijkt me belangrijker dan handhaving auteursrecht.

      1. Ook dat kun je weer van meerdere kanten bekijken. Is de software voor iedereen toegankelijk of alleen voor medewerkers? Is het generieke software waarbij de kans enorm groot is dat het lek wordt gevonden, of ben je een klein bedrijf met custom software? Daarnaast is er denk ik nog wel onderscheid te maken tussen het zoeken naar bugs en het repareren ervan. Ik zou ook wel willen verdedigen dat het eerste niet onder de uitzondering valt, en dat je zoiets met de fabrikant overeen moet komen. Het kan toch niet zo zijn dat elke eenmanszaak het recht heeft om Windows te reverse engineeren als hij zijn website met IIS serveert?

          1. Je koopt slechts een licentie op de gecompileerde code en niet op de codevorm. Zonder wettelijke uitzondering maak je inbreuk op het auteursrecht als je toch de codevorm achterhaalt: hoewel de werking van een programma niet auteursrechtelijk beschermd kan worden, wordt met een directe vertaling van de machine-instructies naar de codevorm toch wel de creatieve inspanning van de maker gereproduceerd (even daargelaten hoe slecht decompilers in de praktijk werken).

            De vraag is dus of dit zo’n uitzondering is. Ik denk van niet. Die laatste zin van mij was geen argument, maar opent wel de discussie. Het lijkt mij onwenselijk als elke afnemer van een programma dat uit elkaar kan trekken om naar fouten te zoeken, omdat zoiets beter contractueel vastgelegd kan worden, zodat een fabrikant waarborgen kan inbouwen over wat er met gevonden fouten gebeurt.

            1. Ik weet niet of het onderscheid compiled/codevorm steun vindt in de wet. Bovendien zou ik het wat raar vinden dat reverse engineering niet zou mogen tenzij je een broncodelicentie hebt: als je die hebt, hoef je niet meer te reverse engineeren. Volgens mij is het doel van die uitzondering juist om wél in de code te kunnen als het (soms) nodig is, en dat is gewoonlijk zo bij compiled code.

              Gezien de praktijk waarin fouten onder het tapijt komen bij leveranciers terwijl ze grote impact op de maatschappij hebben vind ik het juist wél wenselijk als de afnemer fouten mag zoeken en het recht heeft dat te fixen.

            2. Beetje vreemde redenatie. Alle informatie is gecodeerd opgeslagen. Een DVD bevat een hele reeks codes, die bedoeld zijn om op een monitor de illusie van bewegend beeld op te brengen; deze vertaling is wat normaal gesproken een DVD speler icm met de monitor voor je doet. Een programma is gecodeerde binaire machine instructies; een disassembler is in deze functioneel gelijkwaardig aan een DVD speler, en toont de instructies in leesbaar formaat op een scherm; een extra transformatie op die assembly kan de structuren nog wat inzichtelijker maken (net zoals een DVD speler de ondertiteling kan combineren met het beeld en geluid). Voor beide is niet meer dan een transitionele kopie in werkgeheugen nodig. Waarom zou je in het ene geval de getransformeerde weergave willen verbieden, en het andere niet, hoe kwalificeer je sommige weergaves als legaal en andere niet, en waar leg je de grenzen?

        1. Ik zag het onderscheid tussen het “vinden van” en het “verbeteren van” fouten ook meteen toen ik die wetstekst lag. Het vinden hoeft niets met verbeteren te maken te hebben. Een (whitehat) hacker hoopt natuurlijk dat de maker iets met de tip doet.

          Ik kan me voorstellen dat een rechter het vinden onder het verbeteren zal schuiven. Maar ik zou die gok niet durven nemen (ben banger voor gevolgen van ‘auteursrechtinbreuk’ dan een andere overtreding)…

          1. edit: Die zin kan je dus op twee manieren lezen. Gaat het om het in beeld brengen of het inbeeldbrengen van fouten?

            Hoe dan ook, zelfs alos je de fouten in de software zelf niet kan verbeteren, kan je ze met een verbandje vebeteren:

            In beeld brengen kan heel belangrijk zijn. Als jij een fout vindt in online toegankelijk software, waarbij bepaalde invoer tot problemen leidt, zou je een filter kunnen tussenschakelen als je het probleem in de software zelf niet kan oplossen. Of de toegang vanaf buiten helemaal blokkeren als er geen goede oplossing is.

  2. 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.

    De vraag is of je naar fouten mag zoeken. Dat is echt iets anders dan fouten herstellen.

    Fouten zoeken kan je ook doen om bijvoorbeeld malware te maken.

      1. Ik denk niet dat je enkel daarmee een reden hebt om software te gaan reverse engineeren. Als er zich een fout voordoet die je niet kunt verklaren zonder de software te reverseengineeeren kan die zorgplicht inderdaad een reden zijn om die fout op die manier te onderzoeken maar ‘preventief’ alle software die je hebt te gaan reverse engineeren om te gaan vissen naar lekken lijkt me niet te kunnen onder het mom van een zorgplicht.

        Je gaat toch ook niet preventief proberen sites van klanten of leveranciers proberen te hacken om te kijken of er lekken kunnen zijn?

        1. Dat laatste doe je niet, maar dat is niet omdat je het auteursrecht dan overtreed, maar omdat je dan computervredebreuk pleegt.

          En dat kan voor sommige bedrijven inderdaad een reden zijn om niet extern af te nemen, maar zelf te hosten.

        2. Je gaat toch ook niet preventief proberen sites van klanten of leveranciers proberen te hacken om te kijken of er lekken kunnen zijn?

          Er valt wel wat voor te zeggen om dat juist wel te doen. En natuurlijk alleen leveranciers uitkiezen die hier cool mee zijn.

  3. Mag je eigenlijk wel reverse engineren om zo een uitbreiding aan de software toe te kunnen voegen? Bijvoorbeeld een soort plug-in?

    En mag je deze dan vervolgens doorverkopen, ook al ondersteunt de software standaard geen plug-ins?

    Er zijn diverse methodes om bestaande software met extra functionaliteit uit te breiden en veel software heeft daar een speciale API voor. Maar via API hooks en DLL injection is het ook mogelijk om gewoon aan te haken bij bestaande software zonder dat er een specifieke API voor is. Dit kan legitieme doeleinden hebben maar vaak zitten hier duistere bedoelingen achter, zoals het toevoegen van een cheat aan spelletjes of om de beveiliging van de software te omzeilen. Je gaat de bestaande software dus niet vervangen of kopieren, alleen analyseren op aansluitpunten voor je eigen plugin om deze software dus uit te breiden met je eigen software. Je maakt dan eigenlijk gebruik van een beveiligingslek maar met het doel om deze te misbruiken en niet om deze te rapporteren.

      1. Tja, cheat-codes toevoegen aan een MMORPG game is iets waar ik dan aan denk. Een auto-fire plug-in maken voor Eve Online zorgt ervoor dat ik automatisch vijandige piloten uit de ruimte knal. Handig, maar wel vals spel, natuurlijk. Ik breek daarmee de regels van het spel maar niet de wet.

        Een andere toepassing is b.v. een applicatie die vereist dat ik inlog met een bijbehorende usb-dongle. Maar ja, mijn PC heeft 4 USB-poorten die alle vier bezet zijn dus wil ik een plugin gebruiken die deze USB dongle gewoon nabootst. Ik heb dan een legale versie, alleen omzeil ik de beveiliging omdat ik geen andere keuze heb. (Ja, een USB-hub, maar da’s niet mooi.)

    1. vaak zitten hier duistere bedoelingen achter, zoals het toevoegen van een cheat aan spelletjes of om de beveiliging van de software te omzeilen.

      Hoezo zijn dat duistere bedoelingen? Zolang de software op je eigen computer draait, moet de hoofdregel gelden: wat je met en op jouw eigendom (je computer) doet is jouw eigen zaak, en daar heeft niemand anders iets mee te maken.

      Als je acties op jouw computer gevolgen hebben voor anderen (bijv. deelnemers aan een online spel), dan wordt de situatie mogelijk anders. Maar dan denk ik: de beveiliging van persoon A zou nooit afhankelijk moeten zijn van wat voor software persoon B gebruikt; als dat wel zo is, dan is je systeem qua beveiliging gewoon verkeerd ontworpen. Een online game zou bijv. de spelregels server-side moeten handhaven, of bij voorkeur zelfs client-side door elke belanghebbende.

        1. Kopieer-beveiliging: ik blijf erbij dat dat iets is dat op je eigen computer gebeurt, en dat anderen er dus niets mee te maken hebben. Maar goed, mijn opvatting botst hier met het auteursrecht.

          Keylogger: OK, dat is een “duistere” toepassing. Maar: er zijn nog wel meer manieren om een keylogger te installeren, bijv. gewoon een hardware keylogger installeren, eventueel verstopt in de computer-kast; voor dat laatste heb je een schroevendraaier nodig. Ik denk dat hier gewoon blijkt dat elke tool wel duistere toepassingen kent; ik zie duistere toepassingen dan ook niet als een goed argument om bepaalde tools te verbieden.

          1. Maar een keylogger met een DLL-hook of andere methode die in specifieke applicaties aanhaakt maakt het mogelijk om doelgericht gegevens te verzamelen. Denk hierbij ook aan een stiekeme browser-plugin die je op de PC’s van je collega’s installeert. De plugin voor kopieerbeveiliging kun je doorgeven of verkopen aan anderen zodat illegaal gebruik van software mogelijk wordt. Binnen een bedrijf zou zo 1 pakket aangeschaft kunnen worden om deze vervolgens door 40 medewerkers te laten gebruiken. Overigens kun je naast een keylogger ook andere data laten registreren via een dergelijke plugin. Dit is eigenlijk een probleem wat je kunt tegenkomen bij Android en iOS Apps, waar sommige Apps dusdanig veel rechten opvragen waardoor het lijkt alsof de makers ervan alles van jou wil weten. (En vaak is dat ook zo!) Maar ja, dat kun je weigeren. Een plugin die bij alle medewerkers wordt geinstalleerd om te controleren dat ze niet de gehele tijd op Facebook zitten is ook een optie. Of om te kijken wat ze allemaal uitspoken. In principe is dit de basis van malware maar het kan ook gewoon een bedrijfsmatig middel zijn om medewerkers mee te controleren. En dan zijn er mogelijk spellen waar je echt geld mee kunt verdienen zoals online Pokeren. Als je daar mee vals kunt spelen dan ben je aan het frauderen. En dat is al enige maken voorgekomen. In SecondLife is het b.v. mogelijk om met een speciale SL-Browser de objecten van andere spelers te kopieren zodat jijzelf de maker ervan bent. Je kunt dan het werk van anderen doorverkopen alsof jijzelf dit hebt gemaakt! En SecondLife draait om echt geld dus dan praat je over frauderen.

    2. Zie in deze bijvoorbeeld: Nintendo vs. Game Genie. Nintendo hield vol dat een spel met Game Genie unlimited lives hacks een derivatief werk was en inbreuk maakte op haar auteursrechten. De rechter oordeelde echter dat de Game Genie te vergelijken is met het overslaan van een hoofdstuk in een boek, wat compleet eigen keuze dient te zijn: “Having paid Nintendo a fair return, the consumer may experiment with the product and create new variations of play, for personal enjoyment, without creating a derivative work.”

      Anderzijds dien je natuurlijk rekening te houden met de oorspronkelijke licentie. Zie in deze WordPress vs. Thesis, waar WordPress (GPL) bezwaar aantekende tegen Thesis (commerciele licentie). Thesis moest ook haar code (en wijzigingen in WordPress code) openbaren, omdat het geen op-zichzelf-staand product was.

      Nederlandse zaken zijn mij niet bekend.

  4. Is er in de wet nog een verschil tussen reverse engineeren en decompileren?

    In de comments lijken veel mensen het over het laatste te hebben, en als je fouten in software zoekt dan kun je inderdaad beter decompileren. Het verschil is enigszins subtiel (en misschien ook persoonlijk). Voor mij in ieder geval is het verschil dat je met reverse engineeren probeert de functionaliteit en het gedrag van software (of hardware) zo volledig mogelijk te achterhalen. Je brengt hiermee de werking van iets zoveel mogelijk in kaart en zou daarmee een functioneel identiek maar mogelijk op een andere manier vervaardigde ‘kopie’ kunnen fabriceren. Een methode om dit te doen is een Clean room implementatie. Er zijn goede redenen aan te dragen om dit te doen, maar foutopsporing is daar niet een van.

    Bij decompilatie krijg je broncode die, alhoewel die niet identiek hoeft te zijn aan de oorspronkelijke broncode, bij her-compilatie dezelfde binairy zou moeten genereren. In de broncode kunnen fouten makkelijker worden opgespoord dan in de compileerde code, dus een goede reden om dit te doen. En bij sommige talen die gebruik maken van een bytecode of intermediate language (o.a. Java en .Net) vrij gemakkelijk (triviaal met de bestaande tools, tenzij geobfusceerd (obfuscated in het Nederlands, anyone?)).

    Je zou natuurlijk kunnen stellen dat decompileren een vorm van of een hulpmiddel bij het reverse engineeren is, in het geval van software (een auto kun je niet decompileren maar wel reverse engineeren). Voor mijn gevoel kom je door te decompileren echter veel dichter bij auteursrechtwetgeving terecht.

    1. Waarom de auteurswet? Wat de auteurswet betreft denk ik dat de gedecompileerde code een kopie is van de gecompileerde code; weliswaar een getransformeerde kopie, maar dat doet er denk ik niet toe. Als die kopie alleen voor persoonlijk gebruik is (dus alleen voor jouw reverse engineering activiteiten), dan is dat qua auteurswet toch toegestaan?

      1. Als die kopie alleen voor persoonlijk gebruik is (dus alleen voor jouw reverse engineering activiteiten), dan is dat qua auteurswet toch toegestaan?
        Ja, daar ga ik wel vanuit. Ik zie hier ook geen enkel probleem in. Veel reverse-engineering-activiteiten zullen denk ik niet voor eigen gebruik zijn maar juist professioneel. Dan is het heel gevaarlijk om een (getransformeerde) kopie van de broncode in je hand te hebben omdat het gevaar bestaat dat je (onbewust) gedeelten van de broncode overneemt. Zie bijvoorbeeld dit artikel over de java implementatie van Google. Een volledige clean-room-implementatie heeft dit probleem niet omdat je dan nooit de broncode (al dan niet herleid middels decompilatie) in hand hebt gehad.

  5. 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.

    Een softwarebakker mag de verveelvoudiging echter wel technisch onmogelijk maken, door middel het toepassen van “effectieve kopieerbeveiliging” op de firmware zelf, nietwaar? Daarmee zou het onderzoeken van de software niet mogen, want het omzeilen van kopieerbeveiliging is verboden.

Geef een reactie

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