Hoe reverse-engineer je een app met Claude Code

Reverse engineering betekent het bestuderen van een afgewerkt stuk software om te begrijpen hoe het werkt, meestal zonder de originele broncode of de ontwerpdocumenten die er bij het maken aan ten grondslag lagen. Je kijkt naar wat het doet, hoe het is opgebouwd, en waarmee het communiceert, en je werkt van daaruit terug naar een model van het gedrag ervan.

Mensen doen dit meestal om redenen die weinig glamoureus maar wel legitiem zijn. Beveiligingsonderzoekers reverse-engineeren programma's om een kwetsbaarheid te vinden voordat iemand met slechtere bedoelingen dat doet. Developers reverse-engineren bestandsformaten en netwerkprotocollen zodat een nieuw programma kan samenwerken met een oud programma dat niemand voor hen zal documenteren. Archivarissen en hobbyisten reverse-engineren oude software om die te laten blijven draaien zodra zowel de originele hardware als het bedrijf erachter verdwenen zijn. En soms is de reden simpelweg dat een programma waarvan je afhankelijk bent iets ongedocumenteerds doet, en je moet weten wat, voordat je het kunt vertrouwen of er omheen kunt werken.

Niets hiervan is nieuw. Beveiligingsonderzoekers en softwarearchivarissen doen dit al tientallen jaren met disassemblers en debuggers, lang voordat er ooit een AI-agent bestond. Wat is veranderd, is de snelheid: een agent kan een disassembly-listing of een gedecompileerde methode lezen en in enkele seconden samenvatten, werk dat een vakbekwaam persoon vroeger uren kostte. Dat is een echte vooruitgang in capaciteit, en het is precies waarom de juridische en ethische grens later in deze gids er nu meer toe doet, niet minder, omdat de bottleneck die mensen vroeger vertraagde tussen nieuwsgierigheid en kopiëren grotendeels verdwenen is.

De rest van deze gids is specifiek: hij behandelt één tool, genaamd REA, die een agent zoals Claude Code verbindt met dit soort analyse, en de gewoontes die het waard zijn om op orde te hebben voordat je hem op iets richt.

Het onderscheid dat hier het meest telt, is dat tussen het bestuderen van hoe iets werkt en het kopiëren van de beschermde expressie ervan. Reverse engineering om een interface, een bestandsformaat, of een stukje gedrag te leren kennen is, juridisch gezien, een andere handeling dan het overnemen van iemand anders' code of assets in een eigen product.

De werkwijze die rond dat onderscheid is opgebouwd, heet clean-room design. Eén persoon of één sessie bestudeert het origineel en schrijft een duidelijke specificatie van wat het doet: zijn interfaces, zijn dataformaten, zijn gedrag, in eigen woorden, zonder originele code in het document te kopiëren. Een afzonderlijke persoon of sessie, die het origineel nooit heeft gezien, bouwt vervolgens een nieuwe implementatie op basis van alleen die specificatie. Het punt is dat van het eindresultaat aangetoond kan worden dat het voortkomt uit een geschreven beschrijving, en niet uit het originele werk zelf.

Twee oudere Amerikaanse rechterlijke uitspraken worden op dit punt vaak aangehaald en zijn het waard om te kennen, hoewel geen van beide een algemene vrijbrief is om zomaar iets te reverse-engineren. Sega Enterprises Ltd. v. Accolade, Inc., beslist door het Ninth Circuit in 1992, betrof een bedrijf dat het lockout-systeem van een gameconsole reverse-engineerde zodat zijn eigen games op die console zouden werken. De rechtbank oordeelde dat het tussentijdse kopiëren dat bij die reverse engineering betrokken was, gedaan om onbeschermde functionele elementen te bereiken die nodig waren om de games überhaupt op de hardware te laten werken, fair use was gezien de specifieke feiten van die zaak. Sony Computer Entertainment, Inc. v. Connectix Corp., beslist door dezelfde rechtbank in 2000, kwam tot een vergelijkbare conclusie toen een bedrijf de opstartsoftware van een console reverse-engineerde om een emulator te bouwen voor een ander type computer, waarbij het kopiëren onderweg eveneens als fair use werd behandeld, ten dienste van een onafhankelijk geschreven, interoperabel product.

Behandel beide als historische context, niet als advies voor jouw situatie. Het zijn twee specifieke hogerberoepsuitspraken over specifieke feiten, fair use wordt per geval beoordeeld, andere landen trekken deze grenzen anders, en latere wetten gericht op het omzeilen van kopieerbeveiliging beperken dit aanzienlijk voor software die aan DRM gekoppeld is. Iedereen die van plan is om op dit soort werk verder te bouwen, vooral iets dat bedoeld is om uitgebracht of verkocht te worden, moet praten met een echte advocaat voordat ze hierop vertrouwen.

REA trekt zijn eigen grens, onafhankelijk van wat een rechtbank uiteindelijk zou kunnen beslissen over een bepaalde zaak. Volgens het DISCLAIMER.md van het project ondersteunt REA niet en zal het niet helpen bij het omzeilen van DRM, licentiecontroles, anti-cheatsystemen, of andere technische beschermingsmaatregelen, of bij het kopiëren van proprietary software of de beschermde code en assets ervan, en het project stelt duidelijk dat de analyseoutput geen enkel recht verleent op het originele programma. De praktische regel die daaruit volgt: analyseer alleen software die je zelf bezit, zelf hebt geschreven, of waarvoor je anderszins bevoegd bent om te onderzoeken.

De Node.js-versie is hier belangrijk. REA's eigen README geeft de vereiste exact aan als: Node.js 22.x (>=22.23.4), 24.x (>=24.22.1), of 26.12.1+, plus npm. Controleer dit tegen de actuele README voordat je installeert, omdat dit soort vereisten tussen releases kan veranderen.

Het setupcommando is npx rea-agents setup. Volgens de README leidt dit je door de keuze van welke agents je REA wilt registreren, laat het je de wijzigingen zien die het voorstelt voordat je ze goedkeurt, en bewaart het backups van je bestaande configuratie. Herstart je agent daarna zodat die de nieuwe MCP-server herkent; REA's eigen instructies zeggen dit expliciet.

Voor een blijvende command-line-installatie in plaats van een eenmalige npx-run beschrijft de README npm install --global rea-agents, gevolgd door rea --help om te zien wat er beschikbaar is. Vanuit een globale installatie brengt rea update je op jouw eigen moment naar een nieuwe versie, in plaats van automatisch, en door daarna npx rea-agents@latest setup uit te voeren wordt de agentregistratie hierop afgestemd.

Voordat je REA richt op iets wat je niet volledig zelf bezit, probeer het eerst uit op een kleine applicatie die je zelf hebt geschreven. Met REA ingesteld, vraag je Claude Code om die kleine app te openen en te beschrijven wat het ziet, functie voor functie, en vergelijk dat met wat je al weet dat je hebt geschreven. Die ene oefening bevestigt of de opzet daadwerkelijk werkt, en het geeft je een gevoel voor hoe REA's bewijs, een bestand, een functie, een aanroep, in de praktijk aanvoelt voordat je erop vertrouwt voor iets dat echt telt.

Geef het clean-room-idee van eerder een concrete vorm met twee afzonderlijke Claude Code-sessies. De eerste is een specificatiesessie: richt REA op de software waarvoor je bevoegd bent deze te bestuderen, en vraag de agent een specificatie in begrijpelijke taal te schrijven van de interfaces, de dataformaten, en het gedrag van de belangrijkste functies, volledig in zijn eigen woorden, zonder originele code of pseudocode letterlijk in het document te kopiëren.

De tweede is een bouwsessie, vers gestart, zonder enige herinnering aan de eerste. Geef deze alleen het specificatiebestand, niets anders: niet de originele binary, niet het transcript van de eerste sessie, niet de ruwe output van REA. Vraag de sessie om een nieuwe, onafhankelijke implementatie te bouwen die aan de specificatie voldoet, en om te melden wanneer iets in die specificatie onduidelijk is, in plaats van stilletjes te raden wat het originele programma moet hebben gedaan.

Het echt gescheiden houden van deze sessies, niet als twee fasen van één lang gesprek, is het deel dat telt. Een enkele sessie die zowel het origineel heeft bestudeerd als daarna de vervanging heeft geschreven, heeft precies de grens vertroebeld die clean-room design juist scherp wil houden, omdat er achteraf geen manier is om aan te tonen dat de tweede helft niet op de eerste heeft geleund.

Wees helder over wat dit je oplevert. Een gedisciplineerde workflow met twee sessies is een werkwijze die een latere clean-room-argumentatie ondersteunt als iemand ooit vraagt hoe iets gebouwd is. Het is op zichzelf geen juridische garantie, en het vervangt niet het laten bekijken door een echte advocaat van alles wat je van plan bent uit te brengen of te verkopen.