AndroidLab

Il Laboratorio Italiano Android e Google Chrome

Ultimamente avrete sicuramente letto del nuovo sistema di licenza del Market Android messo a disposizione da Google per tutti gli sviluppatori. In primo momento è stato criticato da alcuni per la possibilità che offre agli sviluppatori di verificare su un server l’autenticità dell’applicazione installata , in secondo momento è stato fatto vedere che il sistema era comunque facilmente raggirabile. Ora cerchiamo di fare un po’ di chiarezza sul sistema e vediamo come uno sviluppatore potrebbe alzare ulteriori barricate per rendere la vita difficile (mai impossibile) ai cracker.

Prima di tutto illustriamo come funziona il sistema di licenza. Esso si basa tutto intorno alle librerie LVL (License Verification Library) cuore di tutto il sistema. Queste librerie così come vengono fornite da Google sono uno strumento in più per tutti gli sviluppatori del Market, soprattutto per chi non vuol perdere tempo a implementare un proprio sistema anticopia, si ritrova così un lavoro efficiente già pronto, da usare così com’è o da cui partire per farne uno ancora più sicuro.
Infatti la LVL così come sono proteggono solo da pirateria di tipo casuale, ovvero dalla copia degli apk da un dispositivo ad un altro. Quello che poi lo sviluppatore può fare per rendere la sua applicazione quantomeno tanto difficile da crackare che non ne vale la pena è impiegare delle tecniche per costruire dei muri intorno all’LVL, in modo da rendere difficile l’individuazione della porzione di codice contenente l’LVL dal programma decompilato. Le tecniche che si possono usare sono le seguenti:

  • Offuscare il codice dell’applicazione in modo da rendere difficile il reverse engineering.
  • Modificare il codice della LVL in modo da rendere difficile l’applicazione di tecniche di cracking conosciute.
  • Rendere l’applicazione resistente alle manomissioni.
  • Far si che la validazione della licenza avvenga su di un Trusted Server.

Tutto queste tecniche dovrebbero essere impiegate in modo differente da ogni sviluppatore, in modo che un pirata sia forzato a crackare ogni applicazione in modo individuale.
Alla fine dei conti sta sempre allo sviluppatore introdurre maggior complessità ed eterogeneità nella porzione di codice che controlla la licenza.

Andiamo ora a vedere nel dettaglio, ma sempre in modo generico lasciando agli sviluppatori il compito di approfondire, in cosa consistono le tecniche elencate per fortificare l’applicazione.

Offuscare il codice dell’applicazione in modo da rendere difficile il reverse engineering

Questo è il primo metodo, l’offuscazione del codice da solo questo non protegge totalmente, ma rende solo un po’ più difficile ai cracker, in termini di tempo, scrivere un attacco iniziale all’applicazione. Ma è facilmente implementabile da tutti gli sviluppatori, di conseguenza la sua accoppiata con l’LVL più che raccomandata, dovrebbe essere obbligatoria.

Quel che questa tecnica fa, non è altro che rinominare tutte le occorrenze di chiamate al codice originale che sono generalmente facilmente comprensibili, ad esempio si rinomina la chiamata di dontAlow() in a(). Questo perchè il bytecode della Dalvik VM contiene tutti questi riferimenti al codice originario, di conseguenza in un codice non offuscato un pirata potrà facilmente individuare la porzione contenente la verifica della licenza.

Naturalmente per offuscare il codice cono disponibili una miriade di tool per java, sia commerciale che open source e ognuno può ricercare la soluzione che preferisce.

Modificare il codice della LVL

Questa è la seconda linea di difesa, modificare direttamente la license verification library in modo tale che sia difficile per un cracker modificare il codice disassemblato e avere un riscontro positivo dalla verifica della licenza.

Così facendo si sarà protetti da due tipologie di attacco: da pirati che tentano di crackare l’applicazione, e da attacchi realizzati facendo il porting di altri tipi di attacchi che hanno come obbiettivo altre applicazioni o la LVL originaria stessa.
L’obiettivo finale è rendere la propria applicazione unica e aumentarne la complessità.

Rendere l’applicazione resistente alle manomissioni

Rimuovendo o disattivando l’LVL nella vostra applicazione, un hacker dovrà necessariamente modificare il codice. A meno che questo non viene effettuato con precisione chirurgica, voi potrete facilmente rilevare un’eventuale manomissione del codice dalla vostra applicazione.

Per far ciò basta usare semplicemente la consueta tecnica di una funzione di hash, costruire l’hash del codice della vostra applicazione e poi comparare questo valore di checksum con un altro valore conosciuto.

Semplice da implementare ed allo stesso tempo efficiente.

Far si che la validazione della licenza avvenga su di un Trusted Server

Se l’applicazione fa già affidamento ad un server online per ottenere dei dati, è buon uso usare questa connessione anche per verificare se la licenza dell’utente è valida e se non lo è, rifiutare di fornirgli i dati richiesti.

Finché il processo di verifica della licenza è interamente gestito da codice sul server (e sempre che il vostro server sia sicuro), nemmeno un cracker esperto potrà facilmente raggirare il meccanismo.

La verifica lato server però sarebbe buona norma impiegarla solamente se l’applicazione già usa dei dati on line nel suo funzionamento in modo che l’utente sia totalmente all’oscuro della verifica in corso (in caso di successo).
Obbligare un utente a connettersi (una tantum o periodicamente) solo per verificare la licenza, pur rendendo l’applicazione sicura, sarebbe un fastidio per molti, minando così l’eventuale successo dell’applicazione nel Market.

Concludendo, Google come sempre da un base solida agli sviluppatori da cui partire, ma non basta, il resto è lasciato a noi, seguendo queste linee guida si potrà scegliere fino a che livello rendere sicura l’applicazione dalla pirateria. Del resto più i vari sviluppatore differenziano le proprie tecniche, anche tra un aggiornamento e l’altro, più l’applicazione sarà sicura. Usare sempre lo stesso metodo un metodo che viene da altri, per quanto super sicuro, primo o poi verrà bypassato e bypassato uno si bypassa in tutte la applicazioni che lo usano così com’è senza personalizzarlo.

L’ultimo consiglio, ed a mio avviso il più importante, che Google ci da per difenderci dalla pirateria è forse il più importante: Ascoltare i propri utenti e mantenerli felici, la miglior di fesa contro la pirateria non è tecnica ma emozionale. Questa massima dovrebbe essere scritta sui muri di tante Software House, se l’utente è felice dell’applicazione e si sente coinvolto nel suo processo di miglioramento, diventa parte importante dell’applicazione e sarà felice di spendere un paio di euro per un applicazione che vale.

Ho cercato di tenermi più sul generico in modo che sia comprensibile a tutti quanto scritto e spero di esserci riuscito. Per chi fosse interessato ad approfondire più nel dettaglio a livello di sviluppo le tecniche citate, vi consiglio di leggere l’ottimo post originale sull’Android Developers Blog (Securing Android LVL Applications) da cui quest’articolo è in maggior parte tratto.

Michele Dipace

Admin di Androidlab e "Computer Addicted", ha cominciato la sua"carriera" nella metà degli anni 80 sui computer 8 bit Commodore e Sinclair passando poi al 16 bit Amiga, diventandone grande appassionato. Oggi Linux user, crede che Android sia il sistema operativo destinato ad emergere nel mercato della telefonia mobile.

More Posts - Website

Follow Me:
TwitterFacebookLinkedInPinterestGoogle PlusYouTube

Forum Android
Diventa un blogger, scrivi un articolo