L’ANALISI
REA agents 6.7: Kuna, Windows ARM e analisi riusabili, con limiti espliciti
Analisi pratica di REA agents 6.7.0: provider Kuna, Windows ARM, raw m68k, fatti JavaScript e APK riusabili, breaking change delle Evidence e checklist di prova controllata.
In breve: REA agents 6.7.0 amplia concretamente ciò che un agente può ispezionare e riusare senza ripetere tutta l’analisi: aggiunge Kuna, più percorsi Ghidra e viste persistenti per JavaScript e risorse APK. Non è però un comando che ricrea automaticamente un prodotto: qualità, copertura e piattaforme dipendono dal provider, e la release richiede di rigenerare vecchie Evidence incompatibili.
Perché la versione da installare è la 6.7.0
Il checkpoint 6.6.0 conteneva la maggior parte delle nuove capacità, ma la release 6.7.0 chiarisce che quella versione non era stata pubblicata su npm. La 6.7.0 include quindi i cambiamenti e le note di migrazione precedenti, aggiungendo una correzione per le configurazioni client con chiavi duplicate.
Kuna diventa un provider statico selezionabile
REA può usare un eseguibile Kuna fornito dall’utente per inventario delle procedure, pseudocodice, assembly, relazioni di chiamata, riferimenti a indirizzi esatti e ricerche nelle stringhe. REA non scarica né installa Kuna: il percorso va configurato esplicitamente e la selezione resta ambigua se più provider compatibili sono disponibili senza una scelta.
Cache e riuso riducono il lavoro ripetuto
Le esportazioni Kuna vengono identificate dal digest del target, dell’eseguibile, dalla versione e dal numero di job. Richieste ripetute possono riusare un export verificato o risultati di singole funzioni, mentre query JavaScript selettive possono interrogare proprietà, percorsi e riferimenti già analizzati senza ripetere l’intero lavoro.
Più lingue APK in una sola decodifica
CLI e MCP possono richiedere più locale delle risorse Android nello stesso passaggio. Ogni tabella conserva stato e copertura, mentre i campi a locale singolo restano disponibili. È un miglioramento pratico per confrontare varianti linguistiche, non una garanzia che ogni risorsa qualificata sia selezionabile o completa.
Ghidra copre più target nativi
La release ammette applicazioni e DLL PE ARMNT, Thumb-2 e ARM64 su host Windows x64, e immagini raw m68k big-endian quando profilo e punto di ingresso sono dichiarati dal chiamante. La verifica pubblicata usa Ghidra 12.1.4, ma non copre ogni analizzatore, ARM64EC, ARM64X, host Windows on Arm o m68k su Linux.
Evidenze e cleanup diventano più robusti
REA conserva osservazioni completate, motivi esatti di cancellazione e fallimenti fisici originali durante la finalizzazione. Le risorse non rimosse mantengono un proprietario per il retry, evitando che un errore di cleanup cancelli o sostituisca l’esito principale dell’analisi.
La migrazione può rompere snapshot esistenti
Le Evidence e gli snapshot salvati richiedono ora campi espliciti per copertura delle relazioni e contraddizioni di integrità. I file precedenti non vengono migrati automaticamente: devono essere rigenerati, e i fatti mancanti non vengono ricostruiti per deduzione.
Cosa significa davvero per un test
La prova utile non è chiedere di copiare un’app intera. Conviene usare una piccola funzione di software proprio, produrre build con simboli, stripped e ottimizzata, quindi confrontare pseudocodice, reimplementazione compilata, stessi input, differenze di comportamento, tempi, interventi manuali ed errori.
Condizioni e limitazioni
Il supporto varia per provider e piattaforma: Kuna è verificato con la versione 1.833 su Linux ma non supporta Windows, PE o Mach-O universali; ARM64EC, ARM64X, host Windows on Arm e m68k su Linux restano non verificati o non supportati. REA restituisce pseudocodice, relazioni ed evidenze, ma non prova da solo la ricostruzione completa di un’applicazione. Questo run ha analizzato release e documentazione, senza eseguire un test end-to-end su software proprietario.
Checklist pratica
- Usare soltanto software proprio o per cui esiste un’autorizzazione esplicita all’analisi.
- Installare la 6.7.0 da una sorgente ufficiale e registrare versione Node.js, REA e provider.
- Eseguire `rea doctor` per il provider scelto e conservare limiti, target e host dichiarati.
- Per Kuna, configurare un percorso assoluto e verificare versione, cache, timeout e numero di job.
- Rigenerare Evidence e snapshot creati da versioni precedenti invece di riusarli come compatibili.
- Preparare una funzione proprietaria con build simbolica, stripped e ottimizzata e input deterministici.
- Confrontare il comportamento della reimplementazione compilata, non soltanto la somiglianza del pseudocodice.
- Registrare copertura sconosciuta, passaggi manuali, tempi, fallimenti e cleanup incompleti.