Come indurire un'app per iPhone / Android, quindi è difficile decodificarlo?

10

Questi sono i seguenti obiettivi che ho in mente:

  1. Rendi l'app difficile da decifrare, poiché il file binario contiene alcuni token segreti.
  2. Se può ancora essere rotto, c'è un modo in cui l'app può dire a qualcuno o a se stessa che è stata violata (come controllare contro un checksum o un certificato o il sistema operativo che lo fa per l'app) e intraprendere qualche azione? Il binario dell'app può essere infettato o il codice errato può essere iniettato mentre il programma è in memoria, quindi i metodi suggeriti dovrebbero essere in grado di gestire entrambi questi casi.

Sto utilizzando queste piattaforme:

  • iPhone [OS: iOS, lingua: Objective-C]
  • Android [SO: Android, lingua: Java]

Non tenere conto dei costi e dei tempi di sviluppo, in quanto questa è un'app fondamentale per il suo pubblico. Sarà fantastico se riesco a ottenere risposte alle domande per entrambe le piattaforme. Grazie per il tuo tempo e attenzione già.

Modifica 1 : le queste ProtectionClasses non documentate? Non vedo alcuna documentazione sotto i documenti Apple. Qualcuno ha qualche idea se questi sono di qualche utilità?

Modifica 2 : il codesign per Mac OS X è venuto con un'opzione -o kill per firmare i binari in modo tale che ogni volta che un binario non corrisponde al suo checksum nel certificato, il sistema operativo lo ucciderebbe. Dettagliato qui [Ctrl-F 'opzione bandiere ']. C'è qualcosa di simile per iOS?

Modifica 3 : sto pensando di utilizzare una combinazione di queste idee. Quindi, se qualcuno viene a guardare qui, questo potrebbe aiutare. Funzione unidirezionale & Trasferimento dimentico .

    
posta kumar 01.02.2012 - 22:56
fonte

4 risposte

8

Fondamentalmente l'obiettivo "1" non funzionerà; il reverse engineering funziona semplicemente troppo bene. Sarà particolarmente facile con la versione Android, perché Java è molto semplice da decompilare (su Android, viene utilizzato un formato bytecode specifico perché l'implementazione Java è Dalvik , non il" vero "Java, ma il principio rimane). Tuttavia, non sarà nemmeno così difficile con la versione per iPhone (Objective-C compilato in codice ARM, non è la cosa più difficile da smontare e capire).

Anche l'obiettivo "2" non funzionerà. Prima di tutto, il reverse engineering e l'estrazione dei dati sono solo passivi, quindi l'applicazione è inalterata - quindi, non c'è nulla che l'applicazione possa fare per rilevare che tale reverse engineering ha avuto luogo. Inoltre, è facile modificare alcuni codici dell'applicazione per evitare qualsiasi test interno; questa è la tecnica di cracking numero 1 utilizzata per aggirare la protezione della copia dei giochi dai primi anni '80 (almeno).

Il meglio che puoi sperare è dividere gli utenti in due categorie: quelli che hanno il jailbreak del telefono e quelli che non lo hanno fatto. Su un iPhone non jailbroken, solo le app approvate doverosamente da Apple possono essere installate ed eseguite, quindi questo impedisce l'installazione di un'app modificata, non ufficiale che userebbe i tuoi "token segreti" in un modo che non vuoi. Ma il jailbreak è esattamente ciò che le persone fanno per installare app non approvate, e sembra essere relativamente facile.

Puoi anche provare a rendere la vita più difficile agli aggressori rinnovando molto spesso i token segreti e pubblicando costantemente nuove versioni della tua app. Ecco cosa fanno i produttori di console di gioco, con costanti nuove "versioni firmware" che gli utenti devono scaricare per poter giocare con i giochi più recenti, visualizzare i film più recenti o connettersi a una rete di giocatori. Ciò infastidisce anche gli utenti, quindi non è esattamente economico da fare.

Le cose sarebbero molto più semplici per te se potessi fare in modo che i "token segreti" fossero specifici per l'utente: in questo modo, se un valore di token viene indebitamente estratto, puoi ancora inserirlo nel server (presumo che la tua app utilizza i token per connettersi a un server da qualche parte).

Si noti che mantenere i dati segreti in un'applicazione distribuita o, in mancanza di ciò, rilevare in modo affidabile l'utilizzo fraudolento di tali dati, è il Santo Graal di tutti gli editori di videogiochi e gli editori cinematografici di tutto il mondo. L'ultima volta che ho sentito, i grandi giocatori come Sony e Warner non l'hanno ancora trovato, e non per mancanza di tentativi.

    
risposta data 01.02.2012 - 23:48
fonte
5

How to harden an iPhone/Android app so its tough to reverse-engineer it?

Prevenire il reverse engineering del software è un problema difficile.

Prevenire il reverse engineering del software applicativo su una piattaforma informatica generica con assistenza hardware debole (PC, iPhone o telefono Android) per un periodo di tempo significativo (mesi) è un problema eccezionalmente difficile.

Generalmente invece di proteggere l'intera applicazione un'alternativa comune consiste nel tentare di proteggere i dati critici utilizzati dall'applicazione e rinunciare a proteggere l'intera applicazione.

[1] Make the app hard to crack, as the binary will hold some secret tokens.

Il tuo però qui espone il concetto di 'proteggere i dati'. Quello che vuoi veramente che l'applicazione protegga sono alcuni pezzi di dati critici: i token segreti.

Come proteggi i dati quando l'applicazione non è in grado di proteggersi?

Passa la responsabilità al sistema operativo. Esistono due tipi di protezione che i sistemi operativi possono offrire: controllo dell'accesso e crittografia. La maggior parte delle protezioni che utilizziamo quando consentiamo o neghiamo la lettura di dati o l'esecuzione di un'azione specifica sono i controlli di accesso.

Un controllo di accesso assume come input un'azione e un identificatore di chi vuole eseguire l'azione. Il suo output può approvare o negare il permesso di eseguire l'azione. Un controllo di accesso utilizza un set o regole o una tabella per determinare se un identificatore deve essere autorizzato a eseguire un'azione.

Ad esempio: Alice ha un gioco FunGame su un computer. Il controllo degli accessi del computer ha una regola che solo Alice può eseguire FunGame. Bob si siede al computer e tenta di eseguire FunGame. Il controllo degli accessi del computer prende come input 'run FunGame' e 'Bob'. In base alla regola 'solo Alice può eseguire FunGame' l'output del controllo di accesso è negato.

Il controllo degli accessi fornisce un modo diretto e generale per prendere decisioni su consentire o negare, mentre la crittografia fornisce un metodo più indiretto di consentire o negare. Con la crittografia e la decifratura possiamo trasformare i dati in modo che i dati abbiano senso o non abbiano senso.

La crittografia e la decrittografia richiedono almeno una chiave crittografica. Il valore della chiave diventa un controllo di accesso con le due regole 'consentire a chiunque abbia la chiave di prendere dati comprensibili e renderlo incomprensibile' e 'consentire a chiunque abbia la chiave di prendere dati incomprensibili e renderli comprensibili'. Rendere incomprensibili i dati protegge solo i dati da comprendere. Un individuo può ancora essere in grado di leggere i dati, ma non sarà in una forma che comprendono.

Si noti che la chiave anziché l'identificatore di un attore diventa il componente critico. Chiunque abbia la chiave, indipendentemente dal modo in cui lo ottiene, può accedere ai dati. Ciò rende la memorizzazione della chiave un problema. Se memorizzi la chiave sullo stesso sistema dei dati che stai fornendo a chiunque con i mezzi per accedere ai tuoi dati. Questo è il motivo per cui le passphrase richiedono la memorizzazione. Memorizzando una passphrase memorizza la chiave (passphrase) nella tua testa invece che nel sistema.

Quindi, per proteggere i token puoi usare i controlli di accesso del sistema operativo, oppure puoi crittografare i token, o entrambi. Se qualcuno ha un sistema operativo che non impone i propri controlli di accesso (iPhone jailbroken o telefono Android rooted), non è possibile fare affidamento sui controlli di accesso del sistema operativo. Tuttavia, finché la chiave utilizzata per crittografare i token non risiede nello stesso sistema dei token crittografati, i token saranno comunque protetti anche se il sistema operativo è compromesso.

Tuttavia, tenere la chiave fuori dal sistema in questione è un altro problema difficile chiamato gestione delle chiavi.

[2] If it still can be cracked, is there any way the app can tell someone or its own self that it has been cracked(like checking against some checksum or certificate or the OS doing it for the app) and take some action?

The app binary can get infected or bad code can get injected while the program is in memory as well, so suggested methods should be able to deal with both these cases

Il concetto di esaminare un pezzo di dati per vedere se è inalterato dall'ultima ispezione è chiamato controllo dell'integrità. Un modo efficace per valutare lo stato di una porzione di dati è chiamato hashing crittografico. Per eseguire il controllo dell'integrità, è necessario innanzitutto calcolare l'hash crittografico di un pezzo di dati e quindi proteggere il valore hash risultante. In un secondo momento ricalcolare l'hash crittografico sullo stesso pezzo di dati. Confrontare il valore hash ricalcolato con il valore hash protetto. Se i due valori sono identici, i dati non vengono modificati. Se i due valori di hash sono diversi, i dati sono stati modificati.

È possibile trattare il binario dell'applicazione in memoria come parte di dati ed eseguirne il controllo di integrità. Si può anche trattare il binario dell'applicazione in memoria come un pezzo di dati ed eseguire il controllo di integrità su di esso.

Il concetto di esaminare un programma in esecuzione per vedere se sta elaborando come progettato è chiamato attestazione. Il controllo di tutta la memoria utilizzata dal codice in esecuzione è tipicamente impossibile, quindi l'attestazione di solito verifica qualcosa di più semplice, come i valori di alcuni set di dati o lo stato del programma in esecuzione e la sua transizione tra stati. L'attestato è difficile da raggiungere, quindi non è ampiamente utilizzato nel software commerciale.

    
risposta data 02.02.2012 - 03:06
fonte
4

Mentre sono alcuni metodi di codice auto-modificanti (es. imballaggio) e autocontrollo per Obj-C, Java / Dalvik, IPA, JAR e APK - sono convinto che siano tutti così facili come sovvertito come i loro cugini ASM, C, C ++, PE ed ELF. Le capacità degli ingegneri inversi non sono mondane nell'anno 2012.

Il mio suggerimento è di mantenere tutte le proprietà intellettuali sul lato server e di autenticare e autorizzare accuratamente ogni azione o inazione, in modo simile a come i MMORPG non rootkit catturano i cheaters (ad esempio qualcosa come, ma non abbastanza, PunkBuster).

Le app per dispositivi mobili dovrebbero essere eccessivamente semplici e non dovrebbero MAI avere fiducia nell'utente, proprio come ogni app lato client.

    
risposta data 02.02.2012 - 03:46
fonte
3

Potrebbe sembrare uno sforzo infruttuoso per cercare di prevenire veramente il reverse engineering, ma penso che la nozione qui sia di rendere più difficile il fatto che sarebbero degli attaccanti. Di seguito sono riportate alcune precauzioni che puoi adottare come sviluppatore per difendere meglio dalla decompilazione su Android:

  1. Scrivi alcune delle funzioni principali nel codice nativo (Android NDK)
  2. Utilizza la crittografia
  3. Sposta la logica sul lato server
  4. Impiegare varie forme di offuscamento (dividere le variabili, promuovere gli scalari agli oggetti, modificare le durate variabili, modificare la codifica, riordinare le variabili di istanza, identificatori di scramble, dividere / piegare / unire matrici, modificare le relazioni di ereditarietà) sono solo esempi di offuscamento dei dati. Dai un'occhiata alle confusioni di controllo. Noterai che questi metodi promuovono il codice sciatto e aumentano il sovraccarico con la manutenzione: le persone che invertono la tua app ti odieranno comunque.

Questi sono solo alcuni esempi, ti incoraggerei vivamente a leggere questo articolo sulle tecniche di offuscamento di Java. Le tecniche possono essere adattate a qualsiasi lingua. Buona fortuna.

1 ‘‘A Taxonomy of Obfuscating Transformations,’’ Computer Science Technical Reports 148 (1997), https://researchspace.auckland.ac.nz/handle/2292/3491.
    
risposta data 06.10.2012 - 04:16
fonte

Leggi altre domande sui tag