Sicurezza Mobile: Proteggere i Dispositivi Android dalle Minacce Emergenti

In un’era in cui i dispositivi mobili sono diventati parte integrante della nostra vita quotidiana, l’importanza della sicurezza mobile non può essere sottovalutata. Poiché i nostri smartphone e tablet diventano sempre più il repository di una quantità sempre maggiore di dati sensibili, la necessità di proteggere questi dispositivi dalle minacce emergenti è diventata fondamentale.

Per una migliore contestualizzazione del tema, si consiglia la lettura dell’articolo precedente “Sicurezza del Sistema Operativo Android“. I contenuti presentati sono stati estratti dal testo approfondimento sulla “Sicurezza Mobile” realizzato dal Professor Alessio Merlo, Ordinario di Sistemi di Elaborazione delle Informazioni presso il CASD – Centro Alti Studi per la Difesa di Roma.

Sicurezza delle applicazioni mobili

In questo estratto ci focalizzeremo sulle problematiche di sicurezza del livello applicativo. Per semplicità assumeremo che il sistema operativo Android sia completamente sicuro. In questo caso, le vulnerabilità che tratteremo saranno solo legate alle singole app; e i corrispondenti malware sfrutteranno soltanto vulnerabilità a livello applicativo tramite i canali previsti (e protetti dall’ASF), senza l’utilizzo di side channel.

Il Phishing

Prima di discutere di vulnerabilità di app, occorre chiarire come il malware possa raggiungere il dispositivo e quindi l’app da attaccare. L’idea alla base è circuire l’utente, che ha il potere di installare/rimuovere app, per farsi installare ed eseguire. L’attacco principale che porta a questo risultato è un attacco di phishing. Nella sostanza, l’idea è far abboccare il pesce (l’utente) a un amo costruito ad hoc dall’attaccante.

Un esempio semplice è il classico link inviato per posta, dove si invita l’utente a cliccare e provare una app. A questo link si trova l’APK del malware che l’utente installa non aspettandosi certo un contenuto dannoso.

Il caso precedente, però, è molto naif. Ormai la maggior parte degli utenti è consapevole dei rischi e non abbocca a questi “ami” molto semplici: potremmo dire che questo attacco ha una probabilità di successo molto bassa, così bassa che forse per l’attaccante non è nemmeno conveniente provarlo.

Tuttavia, il phishing rimane il mezzo più efficace per permettere ai malware di arrivare all’obiettivo; nel prossimo articolo mostreremo un esempio di come gli attacchi di phishing su Android oggi siano tanto sofisticati quanto efficaci e portino, spesso, l’utente ad “abboccare all’amo” senza accorgersene.

Dentro una vulnerabilità applicativa

Ad oggi si contano innumerevoli vulnerabilità scoperte in app di diverso tipo, anche ad alta sicurezza come quelle bancarie^[1]. L’esplorazione delle singole vulnerabilità sarebbe un mero esercizio tecnico per appassionati.

Da un punto di vista metodologico, è molto più importante capire il processo e i fattori che portano alla creazione, scoperta e risoluzione di una vulnerabilità applicativa. Per fare questo, ci metteremo nei panni dell’attaccante e vedremo come scoprire e attaccare una vulnerabilità specifica, che ci permetta inoltre di arrivare a conclusioni non comuni e, forse, inattese.

Partiamo direttamente dalle conclusioni:

1. vulnerabilità che portano al furto di credenziali utente possono NON essere ad alto rischio;
2. funzionalità introdotte in nuove versioni di Android possono aiutare a sfruttare vulnerabilità applicative e ad aumentarne il rischio;
3. una volta scoperta una vulnerabilità, la risoluzione potrebbe non essere possibile in tempi brevi.

Per dimostrare le tesi precedenti, prenderemo in esame un insieme di vulnerabilità che riguarda i password manager^[2] (d’ora in poi, PM) su Android.

I PM sono applicazioni dedicate alla gestione delle credenziali utente e nascono storicamente sul web. Ogni browser, oggi, ha un proprio PM che, ogni qual volta un utente visita un nuovo portale o servizio web, salva le credenziali inserite e le inserisce automaticamente qualora lo stesso utente torni a visitare il medesimo sito. Inoltre esiste un insieme consistente di PM generici, non legati ad alcun browser, di larga applicazione nel mondo aziendale: tra questi possiamo citare LastPass, Dashlane, KeepPassX, 1Password, Keeper, onSafe, myPassword, ma la lista è molto lunga.

La crescita esponenziale di questo tipo di software mostra l’esistenza di un business fiorente e ormai consolidato intorno a questi servizi nel web: è lo specchio dei tempi ed è “colpa” della sicurezza informatica. Nello specifico, oggi siamo costretti a ricordare password diverse e complesse per ogni sito, oltre a doverle cambiare con una certa costanza, se vogliamo seguire le “buone maniere” della cybersecurity.

Pertanto, non possiamo ricordare tutto e dobbiamo affidarci a questi servizi. Nel web, essi sono sicuri perché prima di inserire le credenziali in un sito, gli stessi lo identificano tramite il suo certificato a chiave pubblica. Se il sito non è quello atteso, i PM non inseriscono le credenziali.

In questo modo, l’uso dei PM su web ha contrastato efficacemente lo spam (che è di fatto una forma di phishing), ovvero quelle email in cui veniva chiesto all’utente di aggiornare le proprie informazioni spacciandosi per un sito bancario, fornendo però un link a un sito fraudolento. Se tale sito fosse stato uguale a quello della banca dell’utente, lo stesso non avrebbe avuto i mezzi per riconoscere la frode; mentre i PM riescono a farlo verificando il certificato.

Tornando alle app, esse di fatto sono frontend di siti web che richiedono, almeno la prima volta, di identificarsi con le medesime credenziali usati sul corrispondente portale web: l’app di Facebook usa le stesse credenziali del sito di Facebook e ugualmente vale per PayPal, Instagram, le app bancarie e via dicendo. Pertanto, i PM sono parimenti utili su smartphone e a basso costo per i propri sviluppatori, in quanto utilizzano lo stesso database di credenziali collezionate per il web.

Tuttavia, per funzionare correttamente su mobile un PM dovrebbe poter ascoltare cosa accade su un’altra app per riconoscere la schermata di login, come avviene sui tab del browser. Un osservatore attento noterà però che la sandbox di Android non permette a un’app di controllare lo stato dell’interfaccia di un’altra app, che appartiene a un altro utente a livello kernel. Per questo motivo, per una decina di anni i PM non sono mai potuti approdare su Android.

La possibilità è arrivata con Android 8, anche su pressione degli stessi sviluppatori di PM, tramite un nuovo tipo di servizio, chiamato Credential Autofill, che permette agli sviluppatori di garantire ad altre app di controllare lo stato dei campi di inserimento della propria app. Qualora lo sviluppatore dell’app implementasse questo servizio, di fatto Android permetterebbe una eccezione alla sandbox, permettendo ai PM di inserire le credenziali nei campi di login e password. Pertanto, a partire da Android 8 i PM sono potuti approdare sugli smartphone.

Come detto, ciò che rende forti sul web i PM è la loro capacità di identificare con certezza il sito web prima di inserire le credenziali. Vale la stessa cosa sugli smartphone? Come fa un PM, data una certa app, a riconoscere a quale corrispondente dominio web appartiene (mapping), in modo da inviare in sicurezza le credenziali salvate?

In Android, ciò che identifica univocamente un’app sul dispositivo e su ogni app store è il package name, ovvero il nome dell’app. Essendo le app Android nate come applicazioni Java, il package name è della forma com.esempio.app1, come da formato standard di Java. Ad esempio, il nome dell’app ufficiale di Facebook è com.facebook.katana.

Come fanno i PM su mobile a definire il mapping tra il package name di un’app (com.facebook.katana) e il corrispondente sito web (www.facebook.com)? Come possono trovarlo?

Sorprenderà scoprire che questa attività è relativamente semplice nel mondo Android: basta prendere un insieme di PM dal Google Play Store, scaricarli, decompilarli e guardare dentro il codice.

L’analisi del codice di alcuni dei più famosi PM su Android (LastPass, Dashlane e Keeper) evidenzia come essi usino delle euristiche facendo assunzioni sul package name. A mero titolo di esempio, LastPass lo divide in sottostringhe divise dal punto (com.facebook.katana → “com”, “facebook”, “katana”) e prende le prime due in ordine inverso per decidere il mapping con il corrispondente dominio web di appartenenza. Pertanto, la schermata di login com.facebook.katana verrà completata dal PM con le corrispondenti credenziali utente per il dominio “facebook.com”.

Seppur possa non sembrare, questa è una vulnerabilità. Infatti, il lettore converrà che un attaccante che produca un malware sarebbe libero di dare allo stesso il package name che ritiene opportuno, purché unico. Quindi, se un malware avesse come package name “com.facebook.pippo”, LastPass gli fornirebbe le credenziali, come avviene in Figura 7.

È semplice capire che se il malware avesse anche la stessa interfaccia grafica di Facebook, qualora il PM lo completasse l’utente non si accorgerebbe di nulla e le credenziali verrebbero rubate. Si noti che la stessa cosa vale per qualunque app con credenziali come PayPal, Instagram e la maggior parte delle app bancarie o di trading.

Quanto è alto il rischio associato a questa vulnerabilità che permette di rubare le credenziali utente? Sorprendentemente, “solo” medio.

Come discusso, il rischio è il prodotto tra la probabilità e l’impatto. È evidente come l’impatto dello sfruttamento di queste vulnerabilità nei PM sia molto alto (furto di credenziali), tuttavia la probabilità di sfruttare questa vulnerabilità è un valore molto basso. Per capire, occorre immaginare il caso peggiore: un attaccante crea una copia perfetta dell’app bersaglio (e.g., PayPal) con la stessa interfaccia, chiamandola “com.paypal.pippo” in modo da farsi consegnare le credenziali da LastPass.

Tuttavia, per poter rubare le credenziali il malware deve essere installato ed eseguito; e per farlo deve spacciarsi per l’app di PayPal originale, convincendo l’utente a eliminare l’app già presente sul suo dispositivo per installare questa sconosciuta. Questo approccio rientra nel “phishing naif” di cui difficilmente un utente mobile odierno cade vittima, avendo già installate sul proprio dispositivo molte delle app bersaglio. Pertanto, la probabilità di successo è bassa e la vulnerabilità, seppur d’impatto, ha rischio medio: quindi esistono “vulnerabilità che portano al furto di credenziali utente e possono NON essere ad alto rischio (1)”.

Ma è possibile in qualche modo renderla più pericolosa, aumentando la probabilità di sfruttarla? Anche in questo caso ci viene in aiuto Android, con un’altra nuova funzionalità chiamata Instant App (IA)^[3].

Tale funzionalità permette a un utente che visiti un sito sul suo smartphone e per il quale esiste una corrispondente app, di essere notificato e di provare l’app senza installarla. Qualora l’utente accettasse, un codice eseguibile si scaricherebbe sul suo dispositivo e si eseguirebbe sullo stesso, come mostrato in Figura 8.

Ogni IA ha un package name quando viene eseguita, quindi i PM possono inviare anche ad esse le credenziali utente. Inoltre, l’interfaccia dell’IA è completamente controllata dallo sviluppatore (o dall’attaccante!) che ne decide il “look and feel”.

A questo punto, se il malware diventasse un’IA con nome “com.paypal.pippo” con una interfaccia identica all’app ufficiale di PayPal, riuscirebbe più facilmente a farsi consegnare le credenziali da LastPass senza dover essere installata sul dispositivo, tramite un attacco di phishing (come descritto in Figura 9).

Parte tutto da un link a una pagina finta, in questo caso di Medici Senza Frontiere. Supponiamo che l’utente navighi sulla pagina e decida di donare 2 euro: egli non fa altro che cliccare su “paga con Paypal” e mettersi in attesa dell’esecuzione della propria app di PayPal, regolarmente installata sul dispositivo.

Tuttavia il link non è un comando per l’app di PayPal installata, ma un url remoto da cui viene scaricata l’IA “com.paypal.pippo” (senza icona e con il nome “Apri con” per confondere l’utente). Una volta scaricata, l’IA si esegue e mostra all’utente la stessa interfaccia della sua app PayPal. In questo modo inganna sia l’utente – che la scambia per la sua app e non si preoccupa – sia, con il suo package name, l’euristica alla base di LastPass, di fatto facendosi consegnare le credenziali senza che nessuno noti nulla di insolito.

In questo modo la probabilità di sfruttare questa vulnerabilità aumenta considerevolmente, facendo diventare elevato il valore di rischio, essendo ora alti sia la probabilità che l’impatto.

Pertanto, abbiamo mostrato come “funzionalità introdotte in nuove versioni di Android possono aiutare a sfruttare vulnerabilità applicative e ad aumentarne il rischio (2)”.

Come si risolve questa vulnerabilità? Esiste un modo sicuro per risolvere correttamente il mapping tra dominio web e app mobile, senza la necessità di ricorrere alle rischiose euristiche che abbiamo visto. Tale sistema prende il nome di Digital Asset Link (DAL) e, brevemente, mette la responsabilità sullo sviluppatore dell’app, il quale deve inserire dentro il proprio portale, in un percorso ben definito, un file JSON che contenga il package name dell’app ufficiale. In questo modo, i PM dovrebbero limitarsi ad interrogare il file nel dominio (autenticato come per i PM su web tramite certificato a chiave pubblica) per capire se l’app a cui stanno inviando le credenziali sia quella corretta.

Sfortunatamente, nel 2018 solo il 2% dei domini le cui app erano completate da PM utilizzava questa tecnologia; di fatto questo non permetteva ai PM di eliminare le euristiche, pena il poter completare solo il 2% delle app e risultare quindi inutili da un punto di vista pratico. Pertanto, la risoluzione di questo problema pesa sulle spalle degli sviluppatori: sta a loro applicare il DAL per alzare questa percentuale. Purtroppo, abbiamo in questo modo mostrato che “una volta scoperta una vulnerabilità, il fixing potrebbe non essere possibile in tempi brevi (3)”.

La protezione delle app

Se la natura open di Android è un vantaggio per produttori di smartphone e analisti di sicurezza, l’analisi della vulnerabilità precedente ha mostrato come la stessa possa essere un problema per lo sviluppatore, in quanto chiunque può scaricare, decompilare e analizzare il contenuto dell’app.

Questo ha tre dirette conseguenze:

1. le vulnerabilità sono esposte a chiunque voglia analizzarle, come per Android;
2. la logica dell’app è in chiaro (algoritmi usati, protocolli…);
3. è possibile per un attaccante prendere l’app, aggiungere qualche file malizioso, rifirmarla e ridistribuirla agli utenti^[4].

Come può lo sviluppatore contrastare questi tre problemi?

Riguardo il primo punto, è sua responsabilità rilasciare un’app (o una versione aggiornata di un’app) solo dopo aver provveduto a un’estesa analisi di sicurezza per la ricerca di vulnerabilità. In questo senso, esistono numerosi tool di analisi statica e dinamica (e.g., MobSF^[5], Quark^[6], Approver^[7]) per la ricerca e la valutazione del rischio di un’app. L’analisi di sicurezza, con il supporto di tali strumenti, andrebbe svolta sulla versione finale dell’app, pronta per essere rilasciata sullo store.

Riguardo i tool di analisi statica, questi si focalizzano sulla parte di Vulnerability Assessment (VA) e si occupano di analizzare il codice dell’app per ricercare pattern di vulnerabilità noti. L’output di questa fase è una serie di potenziali vulnerabilità a cui spesso viene associato un valore di rischio, perlopiù calcolato in funzione dell’impatto. Tali vulnerabilità sono potenziali perché potrebbero essere di fatto presenti ma non sfruttabili, poiché l’effettiva probabilità che durante l’esecuzione vengano raggiunte può essere molto bassa.

A titolo di esempio, se un pezzo di codice contiene una vulnerabilità ad alto impatto ma è altamente improbabile che quello specifico pezzo di codice venga eseguito, la probabilità è molto bassa e di fatto il rischio può essere estremamente contenuto. In casi estremi, quella parte di codice potrebbe non essere mai eseguita, pertanto quella vulnerabilità risulterebbe impossibile da sfruttare. Casi come questi si chiamano “falsi positivi” e costituiscono il limite dell’analisi statica, dove un certo numero delle potenziali vulnerabilità rilevate si rivelano di fatto falsi allarmi.

L’analisi dinamica permette di verificare l’output dell’analisi statica, cercando di sfruttare effettivamente le vulnerabilità trovate sull’app in esecuzione in un ambiente controllato. Di fatto, l’analisi dinamica simula l’attività di un attaccante (PT – Penetration Testing) che provi a trovare l’algoritmo per sfruttare una vulnerabilità mentre l’app si esegue. Lo scopo è riconoscere e rimuovere i “falsi positivi”, individuando un sottoinsieme delle vulnerabilità che sono effettivamente sfruttabili, fornendo un valore di rischio affidabile, calcolato in funzione della probabilità.

Si noti però che l’utilizzo della sola analisi dinamica non è sufficiente: mentre l’analisi statica è completa (analizza tutto il codice) e rischia di trovare un soprainsieme delle effettive vulnerabilità, l’analisi dinamica soffre del problema opposto e ha il limite di non riuscire a individuare, da sola, tutte le reali vulnerabilità esistenti. Questo avviene perché l’analisi dinamica non può essere, come anche il testing, esaustiva: non si possono provare tutte le infinite combinazioni di input e le interazioni possibili con l’app. Pertanto l’analisi dinamica genera “falsi negativi”, ovvero app che la stessa etichetta come sicure in realtà contengono vulnerabilità che non è riuscita a scoprire.

Dato il set di vulnerabilità trovate (VA) e provate (PT), lo sviluppatore dovrebbe provvedere a risolverle prima rilasciare l’app. Tuttavia, anche in questo caso c’è una scelta di compromesso tra il ritardare l’uscita (anche di un singolo aggiornamento dell’app) risolvendo più vulnerabilità possibili e il rilasciare un’app vulnerabile ma in tempi ragionevoli. In generale, lo sviluppatore dovrebbe risolvere almeno le vulnerabilità a rischio più elevato prima del rilascio.

Offuscamento

Qualora lo sviluppatore volesse proteggere la propria logica di programma (come nel caso delle euristiche dei PM), l’unica possibilità è rendere il proprio codice difficilmente interpretabile da un umano che lo decompili e lo analizzi. Una simile considerazione potrebbe valere per nascondere vulnerabilità potenziali o già trovate e non risolte, attraverso un approccio “security-through-obscurity” che però va considerata come una soluzione di compromesso anche in questo caso: la storia della cybersecurity ha dimostrato che questo approccio non è molto spesso vincente come ci si aspetterebbe.

La soluzione per rendere il codice di più difficile interpretazione è l’offuscamento (obfuscation). L’offuscamento fa riferimento a un insieme di tecniche per la modifica sintattica del codice sorgente, che non modificano però la semantica (ovvero, il codice trasformato fa esattamente le stesse cose di quello originale).

Gli esempi in Figura 10 forniscono un’idea di cosa sia l’offuscamento. Nel primo caso, la modifica è una mera sostituzione dei nomi di variabili e metodi con variabili non intelligibili; nel secondo caso, l’offuscamento ha portato a modificare anche la struttura del codice, riscrivendolo in uno più lungo ed equivalente.

Questo secondo caso suggerisce come l’offuscamento possa impattare negativamente sulle performance dell’app, a seconda della tecnica scelta: in questo caso, il codice offuscato ha più istruzioni. Tuttavia, normalmente l’impatto è abbastanza trascurabile.

Esistono diversi tool commerciali come ProGuard^[8], Zymperium^[9] e DashO^[10] che permettono di offuscare il codice sorgente; e altri non commerciali ed estensibili come Obfuscapk^[11] che esegue un offuscamento blackbox, ovvero direttamente sul codice compilato contenuto nell’APK.

Repackaging e Anti-Repackaging

Ipotizziamo un caso ideale: uno sviluppatore rilascia l’app perfetta (senza alcuna vulnerabilità) o perfettamente offuscata (non c’è modo di trovare eventuali vulnerabilità) sul Google Play Store.

Può stare tranquillo dal punto di vista della sicurezza? In un contesto diverso dal mobile, la risposta sarebbe sì. Purtroppo nel mondo mobile la risposta è necessariamente no, poiché qui esiste un fenomeno unico, quello dell’app repackaging, il cui threat model è rappresentato in Figura 11.

In un contesto ideale, lo sviluppatore produce l’app (Step 1) e invia l’APK all’app store (Step 3). L’utente cerca l’app (Step 4), la scarica e installa (Step 5) e la esegue (Step 6). Purtroppo, anche un attaccante può cercare l’app (specie se è “di successo”), scaricarla, aggiungere del codice malevolo (Step 10), generare un nuovo APK, firmarlo e testarlo (Step 11) e, qualora funzionasse, inviarlo come una nuova app sullo store o in giro tramite web o email (Step 12), sperando che l’utente scarichi la versione repackaged anziché quella originale.

Molte app sono vittima di repackaging – WhatsApp, Telegram, Poste Italiane nonché varie banche, per citarne solo alcune – e hanno più versioni disponibili sul Google Play Store, di cui una soltanto è quella ufficiale.

Per contrastare il fenomeno, sono state proposte negli anni diverse tecniche di anti-repackaging. Seppur con qualche differenza, il principio alla base è l’inserimento nel codice di controlli di integrità nascosti tramite cifratura, per cui, se il codice dell’app viene modificato, l’esecuzione di tali controlli e la mancata verifica dell’integrità portino l’app a interrompere il suo funzionamento. Tali controlli sono inseriti dallo sviluppatore tramite tool automatici come AppIS^[12], BombDroid^[13] e ARMANDroid^[14], prima della creazione dell’APK (Step 2).

L’attaccante a questo punto non può limitarsi ad aggiungere codice, ma deve prima vedere se l’app è protetta (Step 7) cercando, in questo caso, nel codice esistente tutti i controlli di anti-repackaging (Step 8) e disattivarli (Step 9). Ovviamente la ricerca difficilmente è esaustiva, pertanto l’attaccante deve testare il funzionamento dell’app (Step 11) dopo aver aggiunto il proprio codice. Se l’app funziona, dopo un po’ viene ridistribuita; altrimenti l’attaccante deve ricominciare a cercare altri controlli di anti-repackaging fino a quando non ne ha disattivato almeno la maggioranza.

L’obiettivo delle tecniche di anti-repackaging è di scoraggiare l’attaccante in modo che, non riuscendo a disattivare tutti i controlli, abbandoni il progetto di inserire il proprio codice dentro l’app.

L’inserimento dei controlli porta ad aggiungere righe di codice da eseguire, come per l’offuscamento; mentre, a differenza di tale tecnica, se il numero di controlli inserito è alto la dimensione dell’app può incrementare e le sue performance in esecuzione possono ridursi. Pertanto, anche in questo caso occorre arrivare a un compromesso tra il numero di controlli inseriti e le prestazioni dell’app.

Va infine detto che alcuni controlli di anti-repackaging basati sull’analisi delle similitudini tra i codici di app diverse sono implementate nel Google Play Store, finora con risultati non incoraggianti in termine di riconoscimento delle app repackaged.

L’utilizzo del VA/PT, dell’offuscamento e dell’anti-repackaging massimizzano la protezione dell’app da malware, attaccanti e curiosi. Il processo che dovrebbe essere applicato ad ogni rilascio di un’app, dal primo agli aggiornamenti successivi, è rappresentato in Figura 12.

Note

^[1] Talos Security. Report di sicurezza su app bancarie: https://talos-sec.com/blog/2017/10/12/report-mobile-banking-app/

^[2] S. Aonzo, A. Merlo, G. Tavella, and Y. Fratantonio (2018). Phishing Attacks on Modern Android. In Proc. of the 2018 ACM SIGSAC Conference on Computer and Communications Security (CCS ’18). Association for Computing Machinery, New York, NY, USA, 1788–1801. https://doi.org/10.1145/3243734.3243778

^[3] https://developer.android.com/topic/google-play-instant/overview

^[4] Ricordiamo che in Android un’app è valida se firmata e integra, ma non richiede l’autenticazione dello sviluppatore tramite certificato a chiave pubblica.

^[5] https://mobsf.live/

^[6] https://github.com/quark-engine/quark-engine

^[7] https://www.talos-sec.com/products/approver/

^[8] https://www.guardsquare.com/proguard

^[9] https://www.zimperium.com/

^[10] https://www.preemptive.com/solutions/android-obfuscation/

^[11] Aonzo, S., Georgiu, G. C., Verderame, L., & Merlo, A. (2020). Obfuscapk: An open-source black-box obfuscation tool for Android apps. SoftwareX.

^[12] Song, L., Tang, Z., Li, Z., Gong, X., Chen, X., Fang, D., & Wang, Z. (2017). AppIS: Protect Android Apps Against Runtime Repackaging Attacks. Proc. of 2017 International Conference on Parallel and Distributed Systems (ICPADS). Shenzhen, China: IEEE.

^[13] Zeng, Q., Luo, L., Qian, Z., Du, X., & Li, Z. (2018). Resilient decentralized Android application repackaging detection using logic bombs. Proc. of the 2018 International Symposium on Code Generation and Optimization. Wien, Austria: ACM.

^[14] Merlo, A., Ruggia, A., Sciolla, L., & Verderame, L. (2021). ARMAND: Anti-Repackaging through Multi-pattern Anti-tampering based on Native Detection. Pervasive and Mobile Computing.

 

Questo articolo è stato estratto dal white paper “Mobile Security – Nozioni e Riflessioni” disponibile in maniera libera e gratuita al seguente link: https://www.ictsecuritymagazine.com/pubblicazioni/mobile-security-nozioni-e-riflessioni/

 

Articolo a cura di Alessio Merlo