C’è un momento in cui un progetto di reverse engineering smette di essere un progetto e diventa un tarlo. YI Home, per me, è stato esattamente questo.

Nel 2019 avevo provato a capire come l’app delle telecamere parlasse con il cloud. Avevo intercettato il traffico HTTPS, individuato l’endpoint di login, capito che la password non era semplicemente hashata ma passava per un HMAC-SHA256 con un segreto. Poi mi ero fermato. Quel segreto non si trovava, il protocollo era più intricato del previsto e il tempo necessario per andare avanti non era compatibile con un hobby. La serie di post si chiudeva con una battuta: “Qualcuno ha qualche PetaFLOP da prestarmi?”

Qualche anno dopo la situazione era peggiorata: l’app funzionava, ma era diventata un condominio di SDK pubblicitari. Avevo ricominciato a guardarla con l’idea di sostituirla, senza però ricadere nella trappola di un progetto infinito.

Cos’è REA

Negli ultimi mesi REA è circolato molto. Di solito, quando uno strumento fa questo rumore, mi viene il sospetto che sia più spettacolare che utile. Stavolta ho voluto verificare sul campo.

REA, Reverse Engineer Anything, è un MCP: in pratica dà al coding agent una cassetta di attrezzi per guardare dentro un programma. Non si limita a generare codice intorno a un’idea, ma legge l’artefatto, segue le chiamate, recupera funzioni e dati, e restituisce all’agente il materiale su cui ragionare. È il tipo di strumento che cambia il modo in cui poni le domande: non “scrivimi un’app”, ma “come funziona questo pezzo?” e poi “ricostruiscilo”.

Il punto di partenza era ovvio: https://rea.tools/.

La prova

Ho preso l’APK di YI Home 6.9.9 e l’ho messo davanti all’agente. Non è un’app Java con un paio di REST: è un runtime ibrido con dieci DEX, un modulo Flutter compilato, un bundle H5 e lo stack nativo TUTK per il P2P. JADX ha tirato fuori circa 31.864 classi, con 385 errori di decompilazione: non esattamente il terreno ideale per un lavoretto serale.

Ed è qui che REA ha fatto la differenza. L’agente ha potuto seguire il flusso di login, ricostruire la firma delle richieste e individuare la chiave hardcoded usata per l’HMAC della password. La password è un HMAC-SHA256, le chiamate sono firmate con HMAC-SHA1 su token e token_secret, e i media degli eventi sono cifrati. Dettagli che, messi insieme, spiegano perché il tentativo manuale di anni prima si fosse arenato.

Il bello è che non ho dovuto chiedere tutto in un colpo. Ho lavorato a piccoli passi: prima la struttura dell’artefatto, poi il login, poi la lista camere, poi gli eventi. Ogni risposta diventava la base per la domanda successiva. È un modo di lavorare molto più simile a un’indagine che a un prompt unico.

Cosa è uscito

In circa due ore è nato un MVP funzionante: una web app Angular che usa lo stesso account e lo stesso backend dell’app Android.

  • login reale e selezione della regione;
  • lista camere, dettaglio e stato online;
  • timeline eventi con thumbnail;
  • riproduzione dei video evento tramite proxy HLS;
  • profilo e impostazioni principali;
  • nessuna pubblicità, nessun billing, nessun paywall aggiunto lato client.

Ho fatto la prova sul mio account, senza toccare impostazioni, senza eliminare camere e senza modificare nulla. Sono state rilevate quattro telecamere, circa 116 eventi negli ultimi trenta giorni, e i video degli eventi sono stati riprodotti correttamente. La sezione Cloud, per il mio account, restituiva zero clip: non un errore del client, semplicemente il backend non aveva registrazioni da mostrare.

La prima messa online è finita in un 503 per un path sbagliato nel reverse proxy. Corretto il path, la web app è andata su senza altre sorprese. Per ora vive qui: https://yiweb.b0sh.net/

I numeri

Alla fine il conto era questo:

  • circa due ore di lavoro;
  • 332 milioni di token;
  • circa 3 dollari di costo.

Il dato sui token fa più scena che altro: è il volume complessivo della sessione, non la quantità di codice scritto. Buona parte è contesto riletto mentre il lavoro andava avanti. Il costo è quello che ho visto io, con il provider che uso; non è un preventivo universale.

Cosa non è

Non è un clone completo dell’app. Il live P2P TUTK/Kami non è replicabile da browser senza un bridge nativo, quindi la web app è una console cloud, non un sostituto totale dell’app mobile. Non ho implementato binding delle camere, firmware, push, acquisti o abbonamenti. Sono limiti espliciti, non finte implementazioni.

E non è nemmeno magia. REA non “capisce” l’app al posto tuo: dà all’agente gli occhi per guardarla. La parte di verifica resta fondamentale. Ho controllato le risposte, provato il login, guardato i video e sistemato il deploy. Lo strumento accorcia il percorso, non elimina il giudizio.

La lezione

Per me la lezione non è “l’AI fa il reverse engineering”. È che il costo di ingresso per certi progetti è crollato.

Prima YI Home era un progetto che richiedeva giorni o settimane per ottenere una singola risposta, e quindi restava archiviato. Oggi ho potuto riaprirlo, capire abbastanza per costruire qualcosa di utile e metterlo online in una sera. Non è poco.

Non so se REA sostituirà il reverse engineering tradizionale. Per me ha già fatto una cosa più interessante: ha reso di nuovo affrontabile un progetto che avevo smesso di considerare tale.