android apktool - Come evitare il reverse engineering di un file APK?




15 Answers

1. Come posso evitare completamente il reverse engineering di un APK Android? È possibile?

AFAIK, non c'è alcun trucco per evitare completamente il reverse engineering.

E anche molto bene detto da @inazaruk: qualunque cosa tu faccia al tuo codice, un potenziale aggressore è in grado di cambiarlo in qualsiasi modo lei o lui lo trovi fattibile . Fondamentalmente non puoi proteggere la tua applicazione dall'essere modificata. E qualsiasi protezione che hai inserito può essere disabilitata / rimossa.

2. Come posso proteggere tutte le risorse, le risorse e il codice sorgente dell'app in modo che gli hacker non possano in alcun modo compromettere il file APK?

Puoi fare diversi trucchi per rendere l'hacking più difficile. Ad esempio, utilizzare l'offuscamento (se si tratta di codice Java). Questo di solito rallenta notevolmente il reverse engineering.

3. C'è un modo per rendere l'hacking più difficile o addirittura impossibile? Che altro posso fare per proteggere il codice sorgente nel mio file APK?

Come dicono tutti, e come probabilmente sapete, non esiste una sicurezza al 100%. Ma il punto di partenza per Android, che Google ha integrato, è ProGuard. Se hai la possibilità di includere le librerie condivise , puoi includere il codice necessario in C ++ per verificare le dimensioni dei file, l'integrazione, ecc. Se hai bisogno di aggiungere una libreria nativa esterna alla cartella della libreria dell'APK su ogni build, puoi usarla dal suggerimento qui sotto.

Metti la libreria nel percorso della libreria nativa che di default è "libs" nella cartella del tuo progetto. Se hai creato il codice nativo per il target "armeabi", mettilo sotto libs / armeabi . Se è stato costruito con armeabi-v7a, mettilo sotto libs / armeabi-v7a.

<project>/libs/armeabi/libstuff.so
latest download

Sto sviluppando un'app di elaborazione dei pagamenti per Android e voglio impedire a un hacker di accedere a risorse, risorse o codice sorgente dal file APK .

Se qualcuno cambia l'estensione .apk in .zip, può decomprimerlo e accedere facilmente a tutte le risorse e le risorse dell'app e, utilizzando dex2jar e un decompilatore Java, può anche accedere al codice sorgente. È molto semplice eseguire il reverse engineering di un file APK Android: per ulteriori dettagli, consultare la sezione . Reverse engineering da un file APK a un progetto .

Ho utilizzato lo strumento Proguard fornito con l'SDK di Android. Quando eseguo il reverse engineering di un file APK generato utilizzando un keystore firmato e Proguard, ottengo codice offuscato.

Tuttavia, i nomi dei componenti Android rimangono invariati e alcuni codici, come i valori-chiave utilizzati nell'app, rimangono invariati. Come da documentazione di Proguard, lo strumento non può offuscare le componenti menzionate nel file Manifest.

Ora le mie domande sono:

  1. Come posso evitare completamente il reverse engineering di un APK Android? È possibile?
  2. Come posso proteggere tutte le risorse, le risorse e il codice sorgente dell'app in modo che gli hacker non possano in alcun modo compromettere il file APK?
  3. C'è un modo per rendere l'hacking più difficile o addirittura impossibile? Che altro posso fare per proteggere il codice sorgente nel mio file APK?



In nessun punto della storia dell'informatica è mai stato possibile impedire il reverse engineering del software quando ne hai fornito una copia funzionante al tuo aggressore. Inoltre, nella maggior parte dei casi, non sarà mai possibile .

Con quello capito, c'è una soluzione ovvia: non dare i tuoi segreti al tuo aggressore. Anche se non puoi proteggere il contenuto dell'APK, ciò che puoi proteggere è tutto ciò che non distribuisci. In genere questo è un software lato server utilizzato per cose come l'attivazione, i pagamenti, l'applicazione delle regole e altri succosi bit di codice. Puoi proteggere risorse preziose non distribuendole nel tuo APK. Invece, configura un server che risponde alle richieste della tua app, "usa" le risorse (qualunque cosa ciò possa significare) e poi invia i risultati all'app. Se questo modello non funziona per le risorse che hai in mente, allora potresti voler ripensare alla tua strategia.

Inoltre, se il tuo obiettivo principale è prevenire la pirateria delle app : non preoccuparti nemmeno. Hai già bruciato più tempo e denaro per questo problema di quanto qualsiasi misura antipirateria possa mai sperare di salvarti. Il ritorno sull'investimento per risolvere questo problema è così basso che non ha senso nemmeno pensarci.




1. Come posso evitare completamente il reverse engineering di un APK Android? È possibile?

Questo non è possibile

2. Come posso proteggere tutte le risorse, le risorse e il codice sorgente dell'app in modo che gli hacker non possano in alcun modo compromettere il file APK?

Quando qualcuno cambia un'estensione .apk in .zip, dopo la decompressione, qualcuno può facilmente ottenere tutte le risorse (eccetto Manifest.xml ), ma con APKtool si può ottenere anche il contenuto reale del file manifest. Di nuovo, un no.

3. C'è un modo per rendere l'hacking più difficile o addirittura impossibile? Che altro posso fare per proteggere il codice sorgente nel mio file APK?

Di nuovo, no, ma puoi prevenire fino ad un certo livello, cioè,

  • Scarica una risorsa dal Web e fai qualche processo di crittografia
  • Utilizzare una libreria nativa precompilata (C, C ++, JNI, NDK)
  • Eseguire sempre un hashing (chiavi MD5 / SHA o qualsiasi altra logica)

Anche con Smali , le persone possono giocare con il tuo codice. Tutto sommato, non è POSSIBILE.




Gli sviluppatori possono prendere le seguenti misure per prevenire un APK dal furto in qualche modo,

  • il modo più semplice è usare strumenti come ProGuard per offuscare il loro codice, ma fino ad ora, è stato abbastanza difficile impedire completamente a qualcuno di decompilare un'app.

  • Inoltre ho sentito parlare di uno strumento HoseDex2Jar . Dex2Jar inserendo codice innocuo in un APK Android che confonde e disabilita Dex2Jar e protegge il codice dalla decompilazione. In qualche modo potrebbe impedire agli hacker di decompilare un APK in un codice java leggibile.

  • Utilizzare alcune applicazioni lato server per comunicare con l'applicazione solo quando è necessario. Potrebbe aiutare a prevenire i dati importanti.

Non è possibile proteggere completamente il codice dai potenziali hacker. In qualche modo, potresti rendere difficile e un po 'frustrante il compito di decompilare il tuo codice. Uno dei modi più efficienti è scrivere in codice nativo (C / C ++) e memorizzarlo come librerie compilate.




1. Come posso evitare completamente il reverse engineering di un APK Android? È possibile?

Impossibile

2. Come posso proteggere tutte le risorse, le risorse e il codice sorgente dell'app in modo che gli hacker non possano in alcun modo compromettere il file APK?

Impossibile

3. C'è un modo per rendere l'hacking più difficile o addirittura impossibile? Che altro posso fare per proteggere il codice sorgente nel mio file APK?

Più difficile - possibile, ma in realtà sarà più difficile soprattutto per l'utente medio, che è solo googling per le guide di hacking. Se qualcuno vuole davvero hackerare la tua app, verrà hackerata, prima o poi.




La domanda principale qui è che i file dex possono essere decompilati e la risposta è che possono essere "un po '". Ci sono disassemblatori come dedexer e smali .

ProGuard, correttamente configurato, offuscherà il tuo codice. DexGuard, che è una versione estesa commerciale di ProGuard, può aiutare un po 'di più. Tuttavia, il tuo codice può ancora essere convertito in smali e gli sviluppatori con esperienza di reverse engineering saranno in grado di capire cosa stai facendo da smali.

Forse scegliere una buona licenza e farla rispettare dalla legge nel miglior modo possibile.




Le altre risposte in aumento qui sono corrette. Voglio solo fornire un'altra opzione.

Per alcune funzionalità che ritieni importanti, puoi ospitare il controllo WebView nella tua app. La funzionalità sarebbe quindi implementata sul tuo server web. Sembrerà che sia in esecuzione nella tua applicazione.




Come qualcuno che ha lavorato a lungo sulle piattaforme di pagamento, inclusa una applicazione per i pagamenti mobili (MyCheck), direi che è necessario delegare questo comportamento al server, nessun nome utente o password per il processore di pagamento (qualunque esso sia) deve essere archiviato o hardcoded nell'applicazione mobile, questa è l'ultima cosa che vuoi, perché la sorgente può essere compresa anche se offuscassi il codice.

Inoltre, non è necessario conservare le carte di credito oi token di pagamento sull'applicazione, tutto dovrebbe essere nuovamente delegato a un servizio che hai creato, ti consentirà in seguito di essere compatibile con PCI più facilmente e le società della Carta di credito hanno vinto Respira il tuo collo (come hanno fatto per noi).




Schema di firma APK v2 in Android N

La classe PackageManager ora supporta la verifica delle app utilizzando lo schema di firma APK v2. Lo schema di firma APK v2 è uno schema di firma di intero file che migliora significativamente la velocità di verifica e rafforza le garanzie di integrità rilevando eventuali modifiche non autorizzate ai file APK.

Per mantenere la compatibilità con le versioni precedenti, è necessario firmare un APK con lo schema di firma v1 (schema di firma JAR) prima di firmare con lo schema di firma v2. Con lo schema di firma v2, la verifica fallisce se si firma l'APK con un certificato aggiuntivo dopo aver firmato con lo schema v2.

Il supporto per lo schema di firma APK v2 sarà disponibile successivamente nell'N Developer Preview.

http://developer.android.com/preview/api-overview.html#apk_signature_v2




Non è possibile evitare completamente l'IR ma rendendoli più complessi internamente, rendete più difficile per gli attaccanti vedere l'operazione chiara dell'app, che può ridurre il numero di vettori di attacco.

Se l'applicazione gestisce dati altamente sensibili, esistono varie tecniche che possono aumentare la complessità del reverse engineering del codice. Una tecnica consiste nell'utilizzare C / C ++ per limitare la facile manipolazione in fase di esecuzione da parte dell'utente malintenzionato. Ci sono ampie librerie C e C ++ che sono molto mature e facili da integrare con le offerte Android JNI. Un utente malintenzionato deve prima eludere le restrizioni di debug per attaccare l'applicazione a un livello basso. Ciò aggiunge ulteriore complessità a un attacco. Le applicazioni Android dovrebbero avere Android: debuggable = "false" impostato nel manifest dell'applicazione per impedire una facile manipolazione del tempo di esecuzione da parte di un utente malintenzionato o malware.

Trace Checking - Un'applicazione può determinare se è attualmente tracciata da un debugger o da un altro strumento di debug. Se viene tracciata, l'applicazione può eseguire qualsiasi numero di possibili azioni di risposta agli attacchi, come scartare le chiavi di crittografia per proteggere i dati dell'utente, notificare un amministratore del server o altre risposte di questo tipo nel tentativo di difendersi. Questo può essere determinato controllando i flag di stato del processo o usando altre tecniche come confrontare il valore di ritorno di ptrace attach, controllare il processo genitore, i programmi di debug della lista nera nella lista dei processi o confrontare i timestamp in diversi punti del programma.

Ottimizzazioni - Per nascondere i calcoli matematici avanzati e altri tipi di logica complessa, l'utilizzo delle ottimizzazioni del compilatore può aiutare a nascondere il codice dell'oggetto in modo che non possa essere facilmente disassemblato da un utente malintenzionato, rendendo più difficile per un utente malintenzionato acquisire una comprensione del particolare codice. In Android questo può essere ottenuto più facilmente utilizzando librerie compilate in modo nativo con NDK. Inoltre, l'utilizzo di un Obfuscator LLVM o di un altro SDK di protezione fornirà una migliore offuscazione del codice macchina.

Binari di stripping : la rimozione di binari nativi è un modo efficace per aumentare la quantità di tempo e il livello di abilità richiesti da un utente malintenzionato per visualizzare il trucco delle funzioni di basso livello dell'applicazione. Eliminando un binario, la tabella dei simboli del binario viene eliminata, in modo che un utente malintenzionato non possa facilmente eseguire il debug o il reverse engineering di un'applicazione. È possibile riferirsi a tecniche utilizzate su sistemi GNU / Linux come lo sstriping o l'uso di UPX.

E alla fine devi essere consapevole dell'offuscamento e degli strumenti come ProGuard.




D'accordo con @Muhammad Saqib qui: https://.com/a/46183706/2496464

E @Mumair fornisce una buona procedura iniziale: https://.com/a/35411378/474330

È sempre sicuro presumere che tutto ciò che si distribuisce al dispositivo dell'utente appartenga all'utente. Chiaro e semplice.Potresti essere in grado di utilizzare gli strumenti e la procedura più recenti per crittografare le tue proprietà intellettuali, ma non c'è modo di impedire a una determinata persona di "studiare" il tuo sistema. E anche se la tecnologia attuale potrebbe rendere difficile l'accesso indesiderato, potrebbe esserci un modo semplice domani o anche solo l'ora successiva!

Quindi, ecco che arriva l'equazione:

When it comes to money, we always assume that client is untrusted.

Anche in una semplice economia di gioco. (Soprattutto nei giochi! Ci sono più utenti "sofisticati" e le scappatoie si diffondono in pochi secondi!)

Come possiamo stare al sicuro?

La maggior parte, se non tutti, dei nostri sistemi di elaborazione delle chiavi (e ovviamente del database) situati sul lato server. E tra client e server, si trovano comunicazioni crittografate, convalide, ecc. Questa è l'idea del thin client.




Nulla è sicuro quando lo metti in mano agli utenti finali, ma alcune pratiche comuni potrebbero rendere più difficile per l'attaccante rubare dati.

  • Metti la tua logica principale (algoritmi) sul lato server.
  • Comunicare con server e client; assicurarsi che la comunicazione b / n server e client sia protetta tramite SSL o HTTPS; o utilizzare altre tecniche algoritmi di generazione della coppia di chiavi (ECC, RSA). Assicurarsi che le informazioni sensibili rimangano crittografate End-to-End.
  • Utilizzare le sessioni e scadere dopo un intervallo di tempo specifico.
  • Criptare le risorse e recuperarle dal server su richiesta.
  • Oppure puoi rendere l'app Hybrid quale sistema di accesso tramite webviewprotezione + codice risorsa sul server

Approcci multipli; questo è ovvio che devi sacrificare tra prestazioni e sicurezza




Mentre sono d'accordo che non esiste una soluzione al 100% che protegga il tuo codice, la v3 di HoseDex2Jar è ora disponibile se vuoi fare un tentativo.




quando hanno l'app sul telefono, hanno pieno accesso alla memoria di esso. quindi se vuoi impedire che venga violato, puoi provare a farlo in modo che tu non possa ottenere direttamente l'indirizzo di memoria statica usando un debugger. potrebbero fare un overflow del buffer dello stack se hanno un posto dove scrivere e hanno un limite. quindi prova a farlo in modo che quando scrivono qualcosa, se devi avere un limite, se inviano più caratteri che limiti, se (input> limit) allora ignorano, quindi non possono inserire il codice assembly lì.




Posso vedere quella buona risposta in questa discussione. Oltre a poter utilizzare Facebook redexper ottimizzare il codice. Redex funziona a .dexlivello in cui proguard funziona come .classlivello.




Related

android security proguard reverse-engineering