Una forma continua a ripresentarsi nei miei progetti: qualcosa esiste, è utile e non ti dirà come funziona. Ho scritto un keygen per Balsamiq Mockups come esercizio di ricerca — uno studio in C# di come venivano derivate le sue chiavi di licenza, senza distribuire nulla. Ho costruito uno scraper che estrae statistiche sui paesi dalle infobox di Wikipedia, che codificano lo stesso dato in quindici modi diversi. Ho costruito un job serverless che fa il backup delle mie playlist di SoundCloud, il che ha significato strappare un client ID da una pagina perché non esisteva una via d'ingresso documentata. Tre progetti scollegati, una sola attività sotto: osservare cosa fa il sistema, formulare una teoria, verificarla, annotare ciò che si è imparato.
Parliamo di reverse engineering come se fosse roba da ricercatori di sicurezza e da gente che cracca i DRM. Ma se ti integri con qualcosa che non hai costruito tu, ne stai facendo una versione di continuo. La documentazione è vecchia. I messaggi di errore mentono. Il campo contrassegnato come obbligatorio è facoltativo e quello facoltativo è quello che regge tutto. Ogni integrazione è in parte archeologia, e quelle che vanno male sono di solito quelle in cui qualcuno ha dato per scontato che non lo sarebbe stata.
Il metodo non ha nulla di sofisticato. Cambi un input e guardi cosa si muove. Tieni aperto il pannello di rete e leggi ogni richiesta che fa la pagina, non solo quella che ti aspettavi. Salvi una risposta prima e dopo un'azione e le confronti. Quando un endpoint ti rifiuta, leggi il rifiuto come un dato: ti ha appena consegnato una regola che non conoscevi. Gran parte del lavoro è restringere il campo: questo campo conta, quello è decorativo, l'ordine di queste due chiamate regge tutto e nessuno l'ha scritto.
La parte che si tende a saltare è annotare mentre si procede. Una teoria che tieni in testa si degrada tra una sessione e l'altra; una teoria in un file di testo, accanto alla richiesta che l'ha dimostrata, sopravvive. Metà dei miei scraper sono in realtà quel file con del codice intorno: un elenco che cresce di «se ha questo aspetto, significa questo», accumulato una sorpresa alla volta. Quando il sistema di origine cambia sei mesi dopo, quel file è la differenza tra un pomeriggio e una riscrittura.
Impari anche dove fermarti. Non ti serve un modello completo del sistema, solo quanto basta per finire il compito che hai davanti e per accorgerti quando un'assunzione si rompe. Rincorrere la comprensione totale di qualcosa che toccherai una volta sola è una forma di spreco a sé.
Parte del lavoro in cui questo ha contato di più è lavoro che non posso esporre qui: fatto per altri, a condizioni che tengono privati i dettagli. La tecnica era la stessa di tutto quanto sopra; manca solo il resoconto.
Vale la pena farci affidamento perché è la via d'ingresso di chi viene da fuori. Non ti serve un permesso, una partnership o un contratto di assistenza: ti servono pazienza e tolleranza a sbagliare qualche volta prima di azzeccarci. Una volta che ci prendi la mano, un'intera categoria di «non possiamo, non hanno un'API» si trasforma silenziosamente in «dammi un pomeriggio».
C'è una linea, e nella pratica è raramente sfumata: studiare come funziona qualcosa — una copia con licenza sulla tua macchina, una risposta nel tuo browser — non è la stessa cosa che introdursi in un sistema che non hai il permesso di toccare, né che far girare ciò che hai costruito da quello che hai imparato. Io resto dal lato giusto. Tutto quanto sopra riguarda il rendere leggibile ciò che è permesso, non il rendere raggiungibile ciò che è vietato.
Le fondamenta sono gettate; ora si costruisce.