Come fare reverse engineering di un'app con Claude Code

Il reverse engineering significa studiare un software finito per capire come funziona, di solito senza avere il suo codice sorgente originale o alcuno dei documenti di progettazione che lo hanno prodotto. Osservi cosa fa, come è costruito, e con cosa comunica, e da lì procedi a ritroso fino a un modello del suo comportamento.

Le persone lo fanno per motivi perlopiù poco affascinanti e perlopiù legittimi. I ricercatori di sicurezza fanno reverse engineering dei programmi per trovare una vulnerabilità prima che lo faccia qualcuno con intenzioni peggiori. Gli sviluppatori fanno reverse engineering di formati di file e protocolli di rete affinché un nuovo programma possa interoperare con uno vecchio che nessuno documenterà per loro. Archivisti e appassionati fanno reverse engineering di vecchi software per mantenerli funzionanti una volta che l'hardware originale e l'azienda dietro di esso sono entrambi spariti. E a volte il motivo è semplicemente che un programma da cui dipendi fa qualcosa di non documentato, e devi sapere cosa, prima di potertene fidare o di poterlo gestire.

Niente di tutto questo è nuovo. I ricercatori di sicurezza e gli archivisti di software lo fanno da decenni con disassemblatori e debugger, molto prima che esistesse un qualsiasi agente AI. Quello che è cambiato è la velocità: un agente può leggere un listato di disassemblaggio o un metodo decompilato e riassumerlo in pochi secondi, un lavoro che prima richiedeva ore a una persona esperta. Si tratta di un vero salto di capacità, ed è esattamente il motivo per cui il limite legale ed etico più avanti in questa guida conta di più ora, non di meno, poiché il collo di bottiglia che prima frenava le persone tra la curiosità e la copia è quasi del tutto scomparso.

Il resto di questa guida è specifico: ripercorre uno strumento, chiamato REA, che collega un agente come Claude Code a questo tipo di analisi, e le abitudini che vale la pena avere già in atto prima di puntarlo su qualcosa.

La distinzione che conta più di tutte qui è quella tra studiare come funziona qualcosa e copiarne l'espressione protetta. Fare reverse engineering per imparare un'interfaccia, un formato di file, o un comportamento è, legalmente, un atto diverso dal prelevare il codice o gli asset di qualcun altro per metterli in un prodotto tuo.

La prassi costruita attorno a questa distinzione si chiama clean-room design. Una persona o una sessione studia l'originale e scrive una specifica semplice di cosa fa: le sue interfacce, i suoi formati di dati, il suo comportamento, con parole proprie, senza alcun codice originale copiato nel documento. Una persona o una sessione separata, che non ha mai visto l'originale, costruisce poi una nuova implementazione partendo solo da quella specifica. Il punto è che il risultato finale può essere dimostrato come derivante da una descrizione scritta, non dall'opera originale stessa.

Due vecchie decisioni dei tribunali statunitensi vengono citate spesso su questo punto, e vale la pena conoscerle, anche se nessuna delle due è una licenza generale a fare reverse engineering di qualsiasi cosa. Sega Enterprises Ltd. v. Accolade, Inc., decisa dal Nono Circuito nel 1992, riguardava un'azienda che aveva fatto reverse engineering del sistema di blocco di una console da gioco affinché i propri giochi funzionassero su quella console. Il tribunale stabilì che la copia intermedia coinvolta in quel reverse engineering, fatta per raggiungere elementi funzionali non protetti necessari affinché i giochi funzionassero affatto sull'hardware, costituiva fair use sui fatti specifici di quel caso. Sony Computer Entertainment, Inc. v. Connectix Corp., decisa dallo stesso tribunale nel 2000, raggiunse una conclusione simile quando un'azienda fece reverse engineering del software di avvio di una console per costruire un emulatore per un tipo diverso di computer, trattando anche qui la copia lungo il percorso come fair use al servizio di un prodotto interoperabile scritto in modo indipendente.

Considera entrambe come contesto storico, non come un consiglio per la tua situazione. Sono due decisioni d'appello specifiche su fatti specifici, il fair use viene deciso caso per caso, altri paesi tracciano questi limiti in modo diverso, e leggi successive mirate a contrastare l'elusione delle protezioni dalla copia restringono considerevolmente questo spazio per il software legato a DRM. Chiunque intenda costruire su questo tipo di lavoro, specialmente qualcosa destinato a essere pubblicato o venduto, dovrebbe parlare con un vero avvocato prima di fare affidamento su qualsiasi parte di questo.

REA traccia il proprio limite indipendentemente da quello che un tribunale potrebbe eventualmente decidere su un caso particolare. Secondo il DISCLAIMER.md del progetto, REA non supporta e non aiuterà a eludere DRM, controlli di licenza, sistemi anti-cheat, o altre misure tecniche di protezione, né a copiare software proprietario o il suo codice e asset protetti, e il progetto afferma chiaramente che l'output dell'analisi non concede alcun diritto sul programma originale. La regola pratica che ne deriva: analizza solo software che possiedi, che hai scritto tu stesso, o che sei altrimenti autorizzato a esaminare.

La versione di Node.js conta qui. Il README di REA indica il suo requisito esattamente così: Node.js 22.x (>=22.23.4), 24.x (>=24.22.1), o 26.12.1+, più npm. Verifica questo con il README live prima di installare, poiché questo tipo di requisito cambia tra le varie release.

Il comando di setup è npx rea-agents setup. Secondo il README, ti guida nella scelta di quali agenti registrare con REA, ti mostra le modifiche che propone di fare prima che tu le approvi, e conserva i backup della tua configurazione esistente. Riavvia il tuo agente dopo, così recepisce il nuovo server MCP; le istruzioni di REA stesso lo dicono chiaramente.

Per un'installazione da riga di comando persistente invece di un'esecuzione npx una tantum, il README descrive npm install --global rea-agents, seguito da rea --help per vedere cosa è disponibile. Da un'installazione globale, rea update ti fa passare a una nuova versione secondo i tuoi tempi invece che automaticamente, e l'esecuzione successiva di npx rea-agents@latest setup aggiorna la registrazione dell'agente di conseguenza.

Prima di puntare REA su qualcosa che non possiedi completamente, provalo prima su una piccola applicazione che hai scritto tu stesso. Con REA configurato, chiedi a Claude Code di aprire quella piccola app e descrivere cosa vede, funzione per funzione, e confronta questo con quello che già sai di aver scritto. Questo singolo esercizio conferma che la configurazione ha effettivamente funzionato, e ti dà un'idea di come appaiono in pratica le prove di REA, un file, una funzione, una chiamata, prima di farci affidamento per qualcosa che conta davvero.

Metti in pratica l'idea di clean-room descritta prima, usando due sessioni separate di Claude Code. La prima è una sessione di specifica: punta REA sul software che sei autorizzato a studiare, e chiedi all'agente di scrivere una specifica in linguaggio semplice delle sue interfacce, dei suoi formati di dati, e del comportamento delle sue funzioni principali, interamente con parole proprie, senza alcun codice originale o pseudocodice copiato letteralmente nel documento.

La seconda è una sessione di build, avviata da zero, senza memoria della prima. Dalle solo il file di specifica, nient'altro: non il binario originale, non la trascrizione della prima sessione, non l'output grezzo di REA. Chiedile di costruire una nuova implementazione indipendente che soddisfi la specifica, e di dirti quando qualcosa in quella specifica è ambiguo invece di indovinare silenziosamente cosa deve aver fatto il programma originale.

Mantenere queste come sessioni genuinamente separate, non due fasi di una lunga conversazione unica, è la parte che conta. Una singola sessione che ha sia studiato l'originale che poi scritto la sostituzione ha sfumato esattamente il confine che il clean-room design esiste per mantenere netto, poiché non c'è modo di dimostrare, a posteriori, che la seconda metà non si sia appoggiata alla prima.

Sii lucido su cosa ti garantisce realmente questo approccio. Un flusso di lavoro disciplinato in due sessioni è una prassi che supporta un eventuale argomento clean-room se qualcuno dovesse mai chiedere come è stato costruito qualcosa. Non è di per sé una garanzia legale, e non sostituisce il far valutare da un vero avvocato qualsiasi cosa tu intenda pubblicare o vendere.