SafetyNet vs Play Integrity API: come superarlo con il root (2026)

L’API SafetyNet, che la community del root Android conosceva da un decennio, è stata ufficialmente ritirata da Google all’inizio del 2024 e sostituita da Play Integrity API. Ogni guida scritta prima del 2024 è ormai obsoleta e nei vecchi thread dei forum circolano ancora molte informazioni sbagliate. Questa guida è la procedura pratica e aggiornata al 2026: cosa è cambiato, cosa significano davvero i tre verdetti di Play Integrity, quali strumenti di bypass funzionano nel 2026 e le istruzioni passo per passo, compresi i comandi Magisk specifici. È pensata per utenti avanzati che hanno già un dispositivo con root e devono far funzionare le app bancarie e di pagamento.

Una breve storia: da SafetyNet a Play Integrity

SafetyNet (2014-2024) era l’API di attestazione dei dispositivi di Google. Restituiva due campi booleani: ctsProfileMatch (il dispositivo corrisponde a un profilo noto del Compatibility Test Suite?) e basicIntegrity (il dispositivo supera i controlli di integrità di base, come lo stato di bootloader bloccato?). Le app bancarie la chiamavano tramite Google Play Services, ricevevano i due booleani e si rifiutavano di funzionare se uno dei due era falso. I metodi di bypass si sono evoluti nel corso del decennio: prima MagiskHide, poi Zygisk + DenyList dopo il ritiro di MagiskHide in Magisk 24, poi Shamiko in aggiunta per un occultamento più efficace.

Play Integrity API (2023-oggi) è la sostituzione ufficiale. La cronologia del ritiro:

• Giugno 2023: Play Integrity API viene lanciata come sostituto preferito
• Da metà 2023 a inizio 2024: le app iniziano a migrare da SafetyNet a Play Integrity
• Gennaio 2024: SafetyNet viene ufficialmente deprecata; le nuove risposte dell’API non sono più garantite
• Entro metà 2026: quasi tutte le principali app bancarie e di pagamento usano ormai solo Play Integrity

Play Integrity restituisce tre verdetti invece di due booleani e usa l’attestazione hardware delle chiavi per il livello più rigoroso, il che la rende fondamentalmente più difficile da aggirare con metodi solo software.

I tre verdetti di Play Integrity spiegati

Ogni controllo di Play Integrity restituisce tre valori booleani:

MEETS_DEVICE_INTEGRITY

Il livello base. Significa che il dispositivo esegue Android non modificato, ha Google Play Services installato e supera i controlli di compatibilità di base. Aggirabile su dispositivi con root con gli strumenti attuali (Magisk + Zygisk + DenyList + Shamiko + modulo Play Integrity Fix). Circa il 60% delle app richiede questo verdetto per funzionare normalmente.

MEETS_BASIC_INTEGRITY

Un controllo più severo che include ulteriori verifiche dell’ambiente: integrità dei file di sistema, stato atteso di Google Play Services, alcuni controlli sullo stato di debug. Per lo più aggirabile su dispositivi con root, ma più sensibile alla configurazione dei moduli. Circa il 30% delle app richiede questo verdetto oltre a DEVICE_INTEGRITY. La maggior parte delle app bancarie richiede entrambi.

MEETS_STRONG_INTEGRITY

Il livello più rigoroso. Usa l’attestazione delle chiavi supportata dall’hardware: il TEE (Trusted Execution Environment) del dispositivo firma una risposta che può essere verificata fino al certificato radice del produttore. Funziona anche con il bootloader bloccato, perché le chiavi sono protette dal secure element. Non può essere aggirato con gli attuali metodi software su un dispositivo con bootloader sbloccato, perché lo sblocco rompe la catena di verified boot su cui si basano le chiavi del TEE.

Circa il 10-20% delle app richiede STRONG_INTEGRITY:

• Pagamenti contactless con Google Wallet in alcune regioni
• Diverse neobanche (Revolut, Wise, N26 in alcune regioni)
• Alcune app governative di identità (passaporti digitali, documento elettorale)
• App sanitarie con requisiti di conformità rigorosi
• Alcune app di lavoro fornite dal datore di lavoro e protette da MDM

Se le tue app essenziali richiedono STRONG_INTEGRITY, il root è incompatibile con queste app e nessun workaround attuale cambia le cose.

Strumenti di bypass: Magisk Hide, Shamiko e TrickyStore

Per aggirare Play Integrity nel 2026 su un dispositivo con root, tre strumenti principali lavorano insieme:

Passo per passo: superare Play Integrity per le app bancarie di base

Presuppone che tu abbia già:

• Bootloader sbloccato
• Magisk installato tramite boot.img patchato
• Root funzionante verificato in Magisk Manager

Se non hai ancora tutto questo, leggi prima la nostra guida allo sblocco del bootloader e il confronto Magisk vs KernelSU vs APatch.

Passaggio 1: abilita Zygisk in Magisk

Apri l’app Magisk → Settings (icona a forma di ingranaggio) → abilita l’interruttore Zygisk. Riavvia.

Dopo il riavvio, torna nelle Settings di Magisk e abilita Enforce DenyList.

Passaggio 2: installa Shamiko

Scarica l’ultimo zip di Shamiko dalle release ufficiali di LSPosed/LSPosed su GitHub. Nell’app Magisk → scheda Modules → tocca l’icona + → seleziona lo zip di Shamiko → installa. Riavvia.

Dopo il riavvio, verifica che Shamiko sia caricato: app Magisk → scheda Modules → Shamiko deve comparire nell’elenco e risultare abilitato.

Passaggio 3: installa il modulo Play Integrity Fix

Scarica l’ultimo zip di PIF dalle release GitHub di chiteroman/PlayIntegrityFork (o dal fork attualmente mantenuto: controlla i thread XDA dei Recognized Developer per le indicazioni aggiornate).

App Magisk → Modules → + → installa lo zip di PIF → riavvia.

Passaggio 4: aggiorna il fingerprint di PIF con uno funzionante

Il fingerprint dentro PIF deve corrispondere a un dispositivo noto che oggi supera Play Integrity. Il modulo PIF include uno script di aggiornamento automatico. Apri un’app terminale (va bene Termux) ed esegui:

su -c sh /data/adb/modules/playintegrityfix/action.sh

Scarica l’ultimo fingerprint funzionante mantenuto dalla community e lo applica. Riavvia.

Passaggio 5: configura la DenyList per le tue app

App Magisk → Configure DenyList → cerca ogni app bancaria, di pagamento o che controlla Play Integrity che ti serve usare. Tocca l’interruttore accanto a ciascuna app per abilitare l’occultamento. Le voci dei sottoprocessi di solito si attivano in automatico.

App comuni da aggiungere:

• La tua app bancaria principale (HDFC, SBI, Bank of America, Lloyds, ecc.)
• App di mobile money (bKash, GCash, M-Pesa, JazzCash)
• App di pagamento (Google Pay, PayPal, Venmo, Cash App)
• App di brokeraggio (Robinhood, Zerodha, Groww)
• App governative (DigiLocker, Aadhaar, app NHS)
• App di streaming con DRM (Netflix, Disney+, Amazon Prime: controllano Play Integrity per HD/4K)

Passaggio 6: verifica con Play Integrity API Checker

Installa Play Integrity API Checker dal Play Store (esistono più versioni: prova quella di gkkang o quella mantenuta dal team LSPosed).

Aprila. Tocca Check. Cerca:

• MEETS_DEVICE_INTEGRITY: dovrebbe essere true
• MEETS_BASIC_INTEGRITY: dovrebbe essere true
• MEETS_STRONG_INTEGRITY: sarà false su un dispositivo con bootloader sbloccato, ed è normale

Se DEVICE e BASIC restituiscono entrambi true, il bypass funziona a livello di verdetto. La maggior parte delle app bancarie e di pagamento ora funzionerà normalmente.

Passaggio 7: prova ogni app bancaria singolarmente

Apri le app una alla volta. Verifica che superino la schermata iniziale e ti lascino accedere. Se un’app non funziona:

1. Verifica che l’app sia abilitata nella DenyList
2. Riesegui il comando di aggiornamento automatico di PIF per aggiornare il fingerprint
3. Riavvia
4. Se continua a non funzionare, quell’app potrebbe usare ulteriori rilevamenti oltre a Play Integrity: prova TrickyStore come livello aggiuntivo, oppure accetta che l’app sia incompatibile con la tua configurazione root attuale

Quando le app non funzionano anche con il verdetto superato

Alcune app usano ulteriori vettori di rilevamento oltre alla Play Integrity API ufficiale:

• Scansione diretta dei file: cercano /system/bin/su, i percorsi dei binari di Magisk o i percorsi noti di installazione dei moduli. Soluzione: abilita l’occultamento dei file equivalente a MagiskHide di Magisk (integrato nelle versioni recenti).
• Ispezione del namespace dei processi: controllano /proc/self/status e simili per cercare firme degli hook di Zygisk. Soluzione: Shamiko gestisce la maggior parte dei casi.
• Sfide di attestazione TEE indipendenti da Play Integrity. Soluzione: TrickyStore per alcune app; impossibile per altre.
• Blocklist specifiche dell’app mantenute dallo sviluppatore, che includono nomi di pacchetto noti legati al root. Soluzione: rinomina l’app Magisk da Settings → Hide the Magisk app, dandole un nome che non somigli a Magisk.

App bancarie per regione: cosa funziona oggi su Android con root

Il comportamento delle app bancarie varia moltissimo da regione a regione, perché ogni banca sceglie il proprio livello di rigore nei controlli di integrità. In base alle segnalazioni dei clienti nei mercati BD/IN/PK/UK fino al 2026:

Bangladesh

• bKash: funziona con Magisk + Shamiko + PIF per la maggior parte degli utenti; ogni tanto serve aggiornare il fingerprint dopo gli aggiornamenti di Google
• Nagad: funziona con lo stesso stack; un po’ più sensibile alla freschezza del fingerprint
• Rocket (DBBL): funziona con lo stack standard
• App di City Bank, BRAC Bank, EBL, Dutch-Bangla Bank: la maggior parte funziona con lo stack standard; controlla dopo ogni aggiornamento di Play Integrity
• Pagamenti contactless specifici della banca: in genere richiedono STRONG_INTEGRITY; non aggirabili su dispositivi con root

India

• Google Pay (Tez): UPI funziona con lo stack standard; il pagamento contactless (nelle regioni supportate) richiede STRONG_INTEGRITY
• PhonePe, Paytm: UPI funziona con lo stack standard
• HDFC, ICICI, SBI YONO, Axis Mobile: la maggior parte funziona; HDFC e Axis sono un po’ più severe e per certe funzioni possono richiedere TrickyStore
• App di brokeraggio (Zerodha Kite, Groww, Upstox): funzionano con lo stack standard
• App mAadhaar di Aadhaar: funziona per la maggior parte delle funzioni; quelle biometriche possono richiedere una configurazione di occultamento aggiuntiva

Pakistan

• JazzCash, Easypaisa: entrambe funzionano con lo stack standard per la maggior parte degli utenti
• HBL Mobile, UBL Digital, Meezan Bank Mobile: la maggior parte funziona; Meezan è la più severa delle tre
• NayaPay, SadaPay (neobanche): variabile; controlla prima di affidarti al root per queste

Regno Unito e UE

• La maggior parte delle app delle banche tradizionali (Lloyds, Barclays, HSBC, Santander, NatWest): funzionano con lo stack standard a metà 2026
• Neobanche (Revolut, Wise, N26, Monzo): Revolut e Wise sono notoriamente severe e in alcuni flussi richiedono spesso STRONG_INTEGRITY; Monzo e Starling di solito sono più tolleranti
• Equivalenti Apple/Google per il pagamento contactless: richiedono STRONG_INTEGRITY; non aggirabili

Questo elenco riflette la situazione al momento della stesura e cambia con regolarità. Prova sempre le tue app specifiche prima di affidarti al root per un uso finanziario urgente.

Cosa comporta davvero STRONG_INTEGRITY a livello TEE

Un rapido contesto tecnico per utenti avanzati su perché STRONG_INTEGRITY è fondamentalmente non aggirabile su dispositivi con bootloader sbloccato.

I dispositivi Android moderni includono un Trusted Execution Environment (TEE): un processore sicuro separato, con memoria e sistema operativo propri, isolato dal sistema Android principale. Il TEE contiene chiavi crittografiche uniche del dispositivo, provisionate in fabbrica e firmate dall’autorità di certificazione radice del produttore.

Quando un’app richiede STRONG_INTEGRITY, la richiesta passa dal TEE, che firma una risposta usando queste chiavi provisionate in fabbrica. La risposta include lo stato corrente di verified boot: una catena di hash che dimostra che il bootloader è bloccato e che le partizioni boot, system e vendor corrispondono a quanto firmato dal produttore.

Quando sblocchi il bootloader, il TEE aggiorna il proprio stato di verified boot in “yellow” (chiavi installate dall’utente) o “orange” (nessun verified boot). Il TEE continuerà a firmare le risposte STRONG_INTEGRITY, ma la risposta includerà esplicitamente lo stato sbloccato. Le app che richiedono STRONG_INTEGRITY controllano questo campo e si rifiutano di funzionare quando lo stato è diverso da green (bootloader bloccato, catena di boot firmata dal produttore).

Un bypass software non può falsificare tutto questo, perché il TEE firma con chiavi a cui il sistema operativo principale non ha accesso. TrickyStore può intercettare la chiamata al keystore prima che raggiunga il TEE e sostituire una risposta “buona” registrata in precedenza da un dispositivo simile, cosa che funziona per alcune app che non convalidano correttamente l’origine hardware della risposta, ma le app che la convalidano (quelle più severe) rileveranno la sostituzione.

Gli unici modi affidabili per superare STRONG_INTEGRITY:

• Eseguire un boot.img del firmware stock con il bootloader di nuovo bloccato. Alcuni dispositivi (Pixel, certi modelli OnePlus) permettono di ribloccare il bootloader dopo aver flashato immagini firmate dal produttore. Questo ripristina STRONG_INTEGRITY, ma si perde il root.
• Usare un secondo dispositivo senza root per il piccolo numero di app che richiedono STRONG_INTEGRITY.

Non esiste una terza opzione nascosta. Il TEE è progettato proprio per impedirla.

Cosa non consigliamo mai

• Eseguire più moduli di bypass di Play Integrity contemporaneamente senza un motivo preciso: spesso entrano in conflitto e rompono più app di quante ne sistemino.
• Usare fork casuali di PIF da fonti sconosciute. Attieniti al fork principale mantenuto e controlla i thread XDA per l’indicazione attuale.
• Affidarti al bypass per transazioni finanziarie di alto valore. Usa un dispositivo di riserva senza root per importi che non puoi permetterti di perdere e leggi i termini di servizio della tua banca sulla responsabilità per le frodi con dispositivi con root.
• Abilitare il root per il Play Store stesso. Il Play Store non deve stare nella DenyList: farlo può rompere funzioni del Play Store senza alcun vantaggio.

Quando rivolgersi a un professionista

Se una specifica app bancaria non funziona più dopo l’installazione del root e hai già provato lo stack standard, scrivici su WhatsApp o Telegram. Abbiamo configurazioni già verificate e funzionanti per la maggior parte delle banche principali nei mercati BD, IN, PK, UK, US e UE e di solito riusciamo a far funzionare un’app in una sessione remota di 30-60 minuti. Vedi il nostro servizio di rooting Android per cosa è incluso.

Per i dettagli a livello di modulo dietro DenyList e Shamiko, la nostra guida ai moduli Magisk copre lo stack attuale di occultamento di Play Integrity e quali fork sono ancora mantenuti.