L'Eta' E' Un Booleano

// Ticks All The Boxes

15 aprile 2026. Ursula von der Leyen pubblica un tweet con un render iPhone e quattro checkmark verdi: highest privacy standards in the world, works on any device, easy to use, fully open source. L'app europea di age verification, dice, spunta tutte le caselle. Sotto, un video di nove secondi che mostra una credenziale "Age Over 18 = true" dentro un wallet tutto azzurro e blu UE.

Dodici ore dopo, Paul Moore, security consultant dietro l'handle @Paul_Reviews, posta la risposta tecnica piu' lapidaria dell'anno. "Hacking the EU AgeVerification app in under 2 minutes". Rimuovi PinEnc e PinIv dalle shared_prefs, scegli un nuovo PIN, l'app ti presenta le credenziali create sotto il vecchio profilo come valide. Rate limiting? E' un contatore intero nello stesso file. Basta rimetterlo a zero. Biometria? Un booleano. Basta false. Paul chiude con una frase: "this product will be the catalyst for an enormous breach at some point. It's just a matter of time."

A questo punto avrei potuto farmi l'ennesimo thread su X. Ho fatto un'altra cosa. Ho clonato il repo ufficiale, acceso un emulatore Android, e ho speso un pomeriggio a verificare se Paul aveva ragione. L'ho verificato. E sotto quello che aveva trovato lui, ne ho trovati altri sei. Poi, mentre stavo finendo di scrivere questo pezzo, Paul ha pubblicato un secondo thread: "Bypassing EU AgeVerification using their own infrastructure. I've ported the Android app logic to a Chrome extension." Un'estensione Chrome che bypassa il sistema da dentro il browser. Ne parliamo in sezione 08, ma l'anticipo qui perche' cambia il quadro.

// Cosa Dovrebbe Fare L'App

Prima di smontare, serve capire cosa si sta smontando. L'AV Wallet e' un fork specializzato di EUDI Wallet, il portafoglio digitale UE. Il flusso nominale e' questo.

1. Apri l'app, imposti un PIN a 6 cifre, opzionalmente abiliti la biometria.
2. Fai enrollment: ti colleghi a un issuer fidato (un'autorita' nazionale), gli provi la tua eta' con un documento, lui ti emette una credenziale firmata. In realta' te ne emette 30 insieme, politica OneTimeUse, perche' ogni presentazione brucia una credenziale per non farsi tracciare.
3. Quando un sito vuole sapere se hai 18 anni, ti mostra un QR. Lo scansioni con l'app. L'app firma una presentazione OpenID4VP che contiene un solo dato: age_over_18 = true. Il sito verifica la firma. Fine.

Sulla carta e' un bel design. Zero-knowledge nell'intenzione: il sito scopre solo se hai l'eta', non quanti anni, non il nome, non il comune di nascita. In pratica il problema inizia subito: il mapping chi presenta → chi ha fatto l'enrollment non esiste. Il verifier sa solo che un'entita' qualsiasi ha firmato con una chiave che, un giorno, e' stata associata a un documento reale. Chi controlla quella chiave in questo momento, il verifier non lo sa. E come vedremo, nemmeno l'app lo sa.

I file interessanti stanno dentro l'app su un path prevedibile.

Dump delle shared_prefs su emulatore via adb shell run-as $PKG cat $PREFS. Scriveremo sullo stesso file di ritorno con adb push + run-as $PKG cp. Niente root. Il canale run-as esiste perche' la build e' debuggable, esattamente come la build che gli sviluppatori distribuiranno ai tester nazionali. L'ipotesi di attacco e' realistica: accesso fisico al telefono sbloccato per trenta secondi, oppure un malware locale con permessi ADB gia' concessi. Non e' sci-fi, e' un turista che ti lascia il telefono per caricare il charger.

// Il PIN Non Sblocca Niente

Paul_Reviews l'ha detto in un paragrafo. Spendo due minuti di piu' per il dettaglio, perche' qui si capisce l'intera filosofia del prodotto.

Il PIN e' cifrato. Davvero. Una chiave AES-256-GCM nell'Android Keystore, IV random, output base64. Il codice in PrefsPinStorageProvider.kt fa le cose bene. Il PIN cifrato finisce in due campi delle shared_prefs, PinEnc e PinIv.

Il problema non e' la cifratura. Il problema e' cosa succede quando quei due campi non ci sono piu'.

Se PinEnc manca, retrievePin() torna null, hasPin() torna false, l'app entra nel flusso di onboarding e ti chiede di impostare un PIN nuovo. Normale. Tranne che nessuno, in nessuna parte del codice, invalida il vault delle credenziali quando questo succede. Il database EudiWalletDocumentManager.db sta in no_backup/, non viene toccato, le 30 credenziali firmate restano la'. Il nuovo PIN le sblocca tutte come se fossero sempre state tue.

Tradotto in bash.

L'app si riapre mostrando la schermata di setup PIN. Imposti "111111", entri, le credenziali sono li'. Conto documenti prima della manovra: SELECT COUNT(*) FROM MzDocuments su dump SQLite. Conto documenti dopo: lo stesso. Nessuna invalidazione.

// Il Rate Limit E' Un File Di Testo

OK, diciamo che la rimozione del PIN ti spaventa perche' devi almeno riconfigurarlo. Allora lo brute-forzi. Sono sei cifre, un milione di combinazioni, su mobile in poche ore con un accelerometro di scripting ADB.

Il codice, in teoria, ha un rate limiting progressivo. Tre tentativi sbagliati e aspetti un minuto. Cinque e aspetti un'ora. Nove e aspetti otto ore. Lockout.

Dove lo memorizza il lockout? Nello stesso file. In chiaro. Due campi.

PinFailedAttempts e' un contatore. PinLockoutUntil e' un timestamp in millisecondi epoch. Nessuna cifratura, nessun HMAC, nessuna protezione d'integrita'. Lo modifichi con un sed e ritorni a zero tentativi. Ecco il blocco.

Fai un tentativo PIN sbagliato. Incrementa a 1. Reset a 0. Un altro. Reset. Un altro. Reset. Lo script te lo fa in loop. Un milione di combinazioni a due tentativi al secondo fanno cinque giorni. Ma la mediana si trova a mezzo milione, e chi ha un PIN "casuale" sta mentendo: la distribuzione dei PIN a sei cifre reali e' dominata da compleanni, date, sequenze. Spendi due ore con un dizionario DOB e copri il 40% degli utenti reali.

// La Biometria E' Un Booleano

Il device ha biometria attiva. L'utente l'ha abilitata per l'app. L'app mostra il FaceID invece del PIN, l'utente si fida. Tutto bene? No.

Lo stato "biometria attiva per questa app" e' memorizzato come.

Un attributo value="true". Nel solito file. Che sostituiamo con false. L'app al prossimo avvio si dimentica di essere configurata per usare il FaceID e torna alla schermata PIN. A cui applichi VULN-01 o VULN-02. Downgrade path pulitissimo.

Il codice che legge questo flag sta in PrefsBiometryStorageProvider.kt. Lo chiamo "codice" ma e' un sharedPreferences.getBoolean("UseBiometricsAuth", false) senza ulteriori controlli. Niente attestation della Keystore, niente binding al BiometricPrompt, niente chiave hardware-backed che richiede autenticazione utente per essere usata. Il BiometricPrompt Android esiste apposta per questo e l'app lo ignora.

// La Cifratura Che Non Cifra

Questa e' la parte divertente. Apri PrefsController.kt e leggi.

Commento: "Shared preferences are encrypted." C'e' persino il metodo .encrypt(). Che fa .encrypt()? Apri StringExtensions.kt. 27 righe.

Base64. Poi uno shuffle Fisher-Yates con seed hardcoded [1, 3, 5, 7, 9, 2, 4, 6, 8]. Nove byte costanti. Nel sorgente pubblico. Su GitHub.

E' banalmente reversibile. Cinque righe di Python.

Il valore che decifra piu' spesso e' CryptoAlias, ovvero il nome dell'alias dentro l'Android Keystore che contiene la chiave AES che cifra il PIN. Uno schema a cipolla: la vera cifratura esiste, ma il puntatore a quella cifratura sta dietro uno shuffle di Fisher-Yates dichiarato "cifratura" in un commento. Questo non e' un bug. E' un design che usa la parola encrypt in modo fraudolento.

// La Chiave Che Firma Senza Chiedere

Da qui in poi la cosa si sposta. Le precedenti sono sviste implementative, sporche ma risolvibili con una patch. Quella che segue e' un flag. Un singolo parametro booleano che riassume la filosofia dell'intero prodotto.

Le chiavi crittografiche che firmano le presentazioni delle credenziali vengono generate nell'Android Keystore con il flag userAuthenticationRequired a false. Tradotto: quando l'app chiede al sistema operativo di firmare una presentazione con la chiave privata di una credenziale, il sistema operativo non chiede all'utente nulla. Ne' PIN, ne' biometria, ne' lockscreen. Firma.

L'app, sopra quella chiave, ha messo un proprio livello di PIN applicativo (quello di VULN-01 e VULN-02). Ma quel livello sta nel processo dell'app. Qualsiasi altro processo con accesso al contesto dell'app (un malware locale, un debugger, un exploit che bypassa il sandbox) puo' usare la stessa API e firmare. Senza popup, senza interazione utente, senza traccia.

La conseguenza la capisci guardando il checkpoint nel presentation controller.

Il ramo "chiedi al sistema di autenticare l'utente" non viene mai preso, perche' il flag e' hardcoded a false nella configurazione sopra. Questo trasforma la credenziale in un token bearer: chiunque tiene la chiave firma.

// MITM Documentato Nel README

Due cose separate, stessa direzione.

Prima: il file network_security_config.xml dell'app. Una riga utile, cleartextTrafficPermitted="false". Nessun pin-set, nessun <certificates> limitato. Il client HTTP Ktor in NetworkModule.kt viene costruito con HttpClient(Android) senza custom TrustManager, senza CertificatePinner, senza HostnameVerifier. Tradotto: l'app si fida di qualsiasi CA valida per il dominio. Compresa una CA installata dall'utente. Compresa la CA del tuo mitmproxy, se il device e' in debug o su Android < 7.

Seconda: docs/how_to_build.md, la guida ufficiale per gli sviluppatori nazionali che implementeranno la loro versione. Riga 134 in poi.

Un trust manager che accetta ogni certificato e un hostname verifier che dice sempre true. Nella documentazione ufficiale. Con il disclaimer "solo per sviluppo locale". Sai come fa uno sviluppatore sotto deadline quando legge "per lo sviluppo locale"? Copia-incolla.

Il setup pratico del MITM e' quattro righe di bash.

Installi la CA di mitmproxy nel trust store utente dalle Settings, apri l'app, e vedi in chiaro i token OAuth, gli authorization code OIDC, le response di issuance con le credenziali firmate. Su una debug build e' tutto. Su una release build su device non rooted, con Android 7+, servirebbe una CA nello store di sistema, quindi un device compromesso. Ma la debug build e' quella che gli sviluppatori nazionali useranno per sei mesi prima del rilascio, e che i beta-tester installeranno sui loro telefoni personali.

// Le Credenziali Si Copiano

Il database delle credenziali. EudiWalletDocumentManager.db. SQLite standard, nessuna cifratura, nessun SQLCipher, nessun Android EncryptedFile. Vive in no_backup/, che e' il path Android corretto per "non finire nel backup utente", ma non protegge dal comando giusto.

La tabella MzDocuments contiene le credenziali come blob CBOR firmati dall'issuer. Dentro il blob trovi in chiaro le stringhe age_over_18, eu.europa.ec.av, eu.europa.ec.eudi.pid, la firma COSE, le chiavi EC2 curve P-256. La tabella MzAndroidKeystoreSecureArea contiene i metadata per usare le chiavi.

Adesso componi i pezzi.

• Le credenziali sono 30, pre-generate, OneTimeUse: ciascuna e' bruciabile una volta con un verifier diverso, stile Privacy Pass.
• La chiave privata per firmare ogni credenziale sta nel Keystore. Su emulatore o rooted device: estraibile. Su device fisico: resta nel TEE, ma userAuthenticationRequired=false significa che qualsiasi processo con contesto dell'app puo' farla firmare senza interazione utente.
• Il protocollo di presentazione e' OpenID4VP con DCQL. Pubblico. Documentato. Implementazioni open source disponibili.
• Il client_id scheme e' RedirectUri: il verifier si identifica via redirect URI, non via mutual TLS con certificato X.509. Non puo' provare crittograficamente chi e'.

Chiunque con accesso one-shot al device puo' estrarre il blob CBOR e, con la stessa chiave (disponibile perche' non richiede auth), firmare una presentazione valida da una app qualsiasi. Un'estensione Chrome che rileva il QR del verifier e risponde con una presentazione OpenID4VP firmata, riciclando le 30 credenziali estratte, e' un progetto da weekend.

E infatti qualcuno l'ha gia' fatto.

// L'Estensione Chrome Esiste

Mentre finivo di scrivere le sezioni precedenti, Paul Moore ha pubblicato un secondo thread. Questo, rispetto al primo, non e' piu' un bypass locale. E' il tipo di dimostrazione che fa ritirare un prodotto.

Traduco letteralmente, perche' questo thread va letto parola per parola.

Tutto quello che avevo descritto come fattibile in sezione 08 e' stato fatto da Paul Moore in poche ore. Scompongo quello che ha costruito in pezzi tecnici, perche' il punto non e' il suo script, e' che la logica dell'app lo permette.

Step 1: content script che ascolta il QR

Le estensioni Chrome sono JavaScript con permessi DOM. Un content script su verifier.ageverification.dev (o su qualsiasi sito che mostri un QR OpenID4VP, il protocollo e' lo stesso) intercetta il QR. Il QR, decodificato, contiene un'URL con i parametri OpenID4VP: client_id, redirect_uri, response_type=vp_token, presentation_definition. Pubblico, standard, una libreria JS di cinquanta kB lo parsa.

Step 2: payload crittograficamente identico

"Cryptographically identical" significa che il verifier non puo' distinguere il token generato dall'estensione da quello generato dall'app Android ufficiale. Perche' no? Perche' il verifier valida tre cose.

1. Firma dell'issuer sulla credenziale: COSE_Sign1 con la chiave privata dell'issuer, verificabile con la chiave pubblica dell'issuer. Se Paul ha fatto enrollment legittimo una volta, la firma e' valida. Punto.
2. Firma del wallet sulla presentazione: COSE_Sign1 con la chiave del wallet, verificabile con la chiave pubblica nel blob della credenziale. L'estensione genera la sua coppia di chiavi EC P-256, la registra con l'issuer durante l'enrollment, e firma le presentazioni con la sua privata. Crittograficamente indistinguibile da una chiave generata nell'Android Keystore.
3. Device attestation: sarebbe il punto di rottura, se l'app la richiedesse. Ma il flag userAuthenticationRequired=false e la configurazione ClientIdScheme.RedirectUri non impongono attestation binding al device. Paul lo dice: "without irrevocably tying a key to you personally". Il verifier non ha un modo crittografico di chiedere "provami che questa chiave sta su un Android Keystore hardware". Si fida della firma. Fine.

Step 3: la variante "hard-coded credentials"

Paul aggiunge un dettaglio che e' una coltellata. "I could skip the enrolment process entirely and hard-code the credentials into the extension... and the verifier would never know." Significa: prendi una credenziale emessa una volta dall'issuer (legittimamente o da un issuer compromesso), la compili dentro l'estensione, e chiunque la installi vale maggiorenne agli occhi dei verifier. Distribuzione via unpacked extension, via un sideload Firefox, via un fork di un'estensione open source rebrandizzata. Il verifier non ha come distinguere.

// Cosa Vede Il Verifier A Valle

Voglio essere preciso: quello che segue non e' una vulnerabilita' del test issuer, e' una proprieta' del framework. Il README del repo lo dice esplicitamente: "This white-label application is a reference implementation [...] any national-specific enrolment procedures must be implemented by the respective Member States or publishing parties." Il test issuer test.issuer.dev.ageverification.dev e' scaffolding per sviluppatori. E' pensato per non chiedere un passaporto vero, perche' sarebbe assurdo obbligare i dev a scannerizzarne uno ogni volta che testano la UI. Fin qui tutto corretto.

Quello che voglio mostrarti e' cosa significa il design del framework. Quando ho fatto l'enrollment sul test issuer, il flusso e' stato questo.

Adesso vengono le domande interessanti. La firma di quella credenziale e' crittograficamente valida. Il wallet la memorizza come qualsiasi altra. Il verifier, quando la riceve, verifica due cose: la firma (OK) e se la chiave pubblica dell'issuer e' nel suo trust store. Se si', la credenziale vale. Se no, la rifiuta.

La sicurezza dell'intero sistema si sposta quindi al livello trust store + policy degli issuer. E qui ci sono tre domande serie che il framework non risolve.

1. Quali issuer finiscono nei trust store dei verifier? Nel codice del repo, R.raw.av_issuer_ca01 viene caricato in configureReaderTrustStore(). Significa che l'app viene distribuita con una CA preconfigurata. Chi e' quella CA in produzione, chi la amministra, come si aggiungono e rimuovono issuer, con che revocation list, non e' normato dal framework tecnico. E' una decisione operativa delegata ai Member States.
2. Che policy di verifica applicano gli issuer reali? Ogni issuer nazionale definira' la propria. Un paese potrebbe chiedere passaporto biometrico + liveness. Un altro potrebbe accettare l'autodichiarazione su base SPID equivalente. Un terzo potrebbe lasciare che un Comune emetta credenziali a sportello. Il framework OpenID4VCI non impone un livello minimo di identity proofing. E' un contratto amministrativo, non crittografico.
3. Il verifier puo' distinguerli? No. Crittograficamente un verifier vede una firma valida da un issuer nel suo trust store. Non vede come quell'issuer ha emesso la credenziale. Se la "test QEAA issuer" o un suo equivalente debole in produzione finissero nel trust store, le credenziali che emette sarebbero indistinguibili da quelle emesse dopo un controllo passaporto serio.

In altri termini: il test issuer con il toggle e' un test, e questo e' legittimo. Ma il framework che lo ospita accetta per design che issuer diversi abbiano verifiche diverse, e il verifier a valle non ha nessuna finestra sulla forza dell'enrollment. Il "fully trusts" che Paul Moore cita nel suo tweet della Chrome extension e' esattamente questo: il verifier si fida perche' la firma e' valida e la chiave e' trusted, non perche' sappia che l'utente ha presentato un passaporto.

La cosa interessante del toggle non e' il toggle in se'. E' il fatto che dal punto di vista del verifier la credenziale firmata dopo il toggle e la credenziale firmata dopo un vero scan del passaporto sono byte per byte dello stesso schema, con la sola differenza della chiave privata che le ha firmate. Se le due chiavi sono entrambe nel trust store, la distinzione si perde nel protocollo.

// Il Difetto Che Nessuna Patch Sistema

Mettiamo per un secondo che il team Scytales patcha tutti e otto i VULN domani mattina. Release nuova, audit pulito, tutti contenti.

Rimane un buco che nessuna implementazione puo' chiudere. Il verifier riceve una presentazione firmata con questa struttura.

Due firme. La prima (issuer_signature) garantisce che un issuer fidato ha detto age_over_18 = true per la chiave pubblica del wallet. La seconda (wallet_proof) garantisce che chi sta presentando ha la chiave privata del wallet corrispondente. Matematicamente: due firme valide verificano il possesso. Non verificano:

1. Che la persona che presenta ora sia la persona che ha fatto enrollment tre mesi fa.
2. Che nessuno abbia bypassato il PIN applicativo prima della presentazione.
3. Che la credenziale non sia stata estratta e ripresentata da un device diverso.
4. Che la persona sia fisicamente davanti allo schermo mentre la presentazione avviene.

Il prima vs dopo, cosi' come lo vende Bruxelles, e'.

Stessa risposta. Ora con dati biometrici in un server nazionale, una device attestation in un backend nazionale, e una catena di fiducia che rimbalza su fornitori nazionali che nessuno ha auditato.

L'unico modo di risolvere davvero sarebbe legare la chiave di presentazione all'identita' biometrica in ogni transazione. Ma quello significa tracciabilita' cross-sito e fine della zero-knowledge premise. Se voglio non-trasferibilita' forte perdo la privacy promessa. Se tengo la privacy accetto la trasferibilita'. Non c'e' un punto nella curva in cui hai tutte e due.

L'app dice "ticks all the boxes". Alcune di quelle box non possono essere spuntate insieme. E' una scelta di teoria dell'informazione, non di implementazione.

// Il Fully Open Source Non Esiste

Torniamo al tweet. Checkmark numero quattro, fully open source. Tecnicamente non e' una bugia. Il repo eu-digital-identity-wallet/av-app-android-wallet-ui e' pubblico, licenza Apache 2.0, codice leggibile. Quello che ho smontato sta la'. E' l'unico motivo per cui questo articolo esiste: senza sorgente non avrei trovato lo shuffle con seed [1, 3, 5, 7, 9, 2, 4, 6, 8] in due secondi di ripgrep.

Il problema e' cosa intende Bruxelles con "l'app". Quello su GitHub e' il blueprint. Un kit. Il core module scritto da Scytales + EU Commission + partner tecnici. Mattoni. L'app che scaricherai dal Play Store italiano o tedesco o olandese sara' un'altra cosa: un fork del blueprint, integrato nel wallet nazionale di identita' digitale, con il backend del tuo ministero, con i fornitori che il tuo ministero ha scelto, con le modifiche che il tuo ministero ha ordinato. Nessuno garantisce che queste implementazioni nazionali saranno open source. Alcune lo saranno, altre no, altre lo saranno parzialmente.

Il kernel del problema e' che il backend conta piu' del frontend. Il frontend open source ti fa vedere che la UI non spedisce il tuo volto a un server. Il backend chiuso gestisce i log, le policy di retention, gli endpoint di auditing, le query ai database statali d'identita'. L'infrastruttura che sa chi sei. Quella parte, nelle implementazioni nazionali, puo' rimanere una scatola nera.

E c'e' un livello ulteriore. L'app chiede permessi. Camera (per scannare QR verifier), storage (per le credenziali), network (per l'issuer). Un fork nazionale puo' aggiungere permessi. Un fork nazionale puo' aggiungere SDK di analytics. Un fork nazionale puo' aggiungere logging server-side. Leggi l'Android Manifest della tua versione nazionale, non del blueprint. Quello e' il contratto reale.

// Il Tabellone

• VULN-01 // PIN non legato al vaultRimuovendo PinEnc/PinIv si resetta il PIN, le credenziali restano accessibili. Fix richiede KDF dal PIN alla chiave del vault.
• VULN-02 // Rate limit client-sidePinFailedAttempts e PinLockoutUntil in chiaro nelle shared_prefs. Reset a zero = brute force senza limiti.
• VULN-03 // Biometria booleanaUseBiometricsAuth e' un bool editabile. Fix richiede binding hardware al BiometricPrompt.
• VULN-04 // Falsa cifraturaFisher-Yates shuffle con seed [1,3,5,7,9,2,4,6,8] documentato come "encryption" nel sorgente.
• VULN-05 // userAuthenticationRequired=falseLe chiavi di presentazione firmano senza interazione utente. Critica: trasforma la credenziale in token bearer.
• VULN-06 // MITM pattern nei docsTrustAllX509TrustManager e HostnameVerifier { true } nel how_to_build.md ufficiale.
• VULN-07 // DB credenziali in chiaroSQLite standard, nessun SQLCipher, estraibile con un cat e run-as.
• VULN-08 // Replay / portabilita'Combinazione di 05+07+RedirectUri abilita una chrome extension che firma presentazioni fuori dall'app.
• DESIGN // Il booleano firmatoIl verifier riceve age_over_18 = true. Non puo' distinguere presentazione legittima da replay o credenziale emessa senza verifica reale. Non risolvibile senza rompere la privacy promise.

// Conclusione

Von der Leyen ha fatto un tweet. Paul Moore le ha risposto con due minuti di adb push e poi con un'estensione Chrome che bypassa la verifica da dentro il browser. Io ho passato un pomeriggio a verificare che avesse ragione su tutto, e sotto i suoi tre punti ne ho trovati altri cinque.

Il punto non e' che l'AV Wallet e' scritto male. Il punto e' che e' scritto come un'app di esempio per un talk a una conferenza Kotlin, e poi viene venduto come l'infrastruttura di verifica dell'eta' per mezzo miliardo di persone. La distanza tra i due e' quello che trovi aprendo StringExtensions.kt e leggendo il commento "Shared preferences are encrypted.".

Il codice e' aperto. Chiunque puo' verificare. E' l'unica cosa che funziona davvero qui: il fatto di poter scrivere questo articolo. Paul l'ha fatto in due minuti di PIN bypass, poi in poche ore di Chrome extension, io in un pomeriggio di report. Uno sviluppatore di un'autorita' nazionale che lo prende e lo fork-a farebbe bene a leggere anche i commenti. E a guardare il video di Paul prima di firmare il contratto di deployment.

// Lab

Tutti gli script PoC + il security report completo su GitHub. Clickando un file qui sotto si apre il viewer GitHub con syntax highlighting. Prerequisiti: emulatore Android API 30, app com.scytales.av.dev installata, adb + sqlite3 nel PATH.

Ogni script fa backup delle SharedPreferences prima di modificarle e ripristina lo stato originale alla fine.