Comment éviter l'ingénierie inverse d'un fichier APK?

Question

Je suis en train d'élaborer un traitement de paiement app pour Android, et je veux empêcher un pirate d'accéder à toutes les ressources, les actifs ou le code source du APK fichier.

Si quelqu'un change la donne .apk extension .zip, puis ils peuvent décompresser et accéder facilement à tout ce que l'application des ressources et actifs, et à l'aide de dex2jar et Java decompiler, ils peuvent aussi avoir accès au code source. Il est très facile de désosser un Android APK fichier - pour plus de détails, voir Débordement de Pile question de l'ingénierie Inverse à partir d'un fichier APK sur un projet.

J'ai utilisé le Proguard outil fourni avec le SDK Android. Quand j'ai désosser un APK fichier généré à l'aide d'un signé de magasin de clés et Proguard, je reçois de l'obfuscation de code. Toutefois, les noms de Android composants restent inchangés et un peu de code, comme les valeurs-clés utilisés dans l'application, reste inchangé. Comme par Proguard la documentation de l'outil ne peut pas occulter les composants mentionnés dans le fichier Manifeste.

Maintenant mes questions sont les suivantes:

1. Comment puis-je éviter complètement l'ingénierie inverse d'un Android APK? Est-ce possible?
2. Comment puis-je protéger tout ce que l'application de ses ressources, de biens et de code source, de sorte que les pirates ne peuvent pas pirater le fichier APK?
3. Est-il un moyen de rendre le piratage plus difficile, voire impossible? Ce que je peux faire de plus pour protéger le code source dans mon fichier APK?

Answer 1

1. Comment puis-je éviter complètement l'ingénierie inverse d'un Android APK? Est-ce possible?

Autant que je sache, il n'y a aucune astuce pour terminer l'évitement de l'ingénierie inverse.

Et aussi très bien dit par @inazaruk: ce que vous faites dans votre code, un attaquant potentiel est en mesure de le modifier de quelque façon qu'elle ou il trouve que c'est faisable. Fondamentalement, vous ne pouvez pas protéger votre application d'être modifiés. Et toute la protection que vous mettez dans, il peut être désactivé/supprimé.

2. Comment puis-je protéger tout ce que l'application de ses ressources, de biens et de code source, de sorte que les pirates ne peuvent pas pirater le fichier APK?

Vous pouvez faire différentes astuces pour rendre le piratage plus difficile. Par exemple, l'utilisation de la dissimulation de l' (si c'est du code Java). Généralement, cela ralentit l'ingénierie inverse de manière significative.

3. Est-il un moyen de rendre le piratage plus difficile, voire impossible? Ce que je peux faire de plus pour protéger le code source dans mon fichier APK?

Comme tout le monde le dit, et comme vous le savez probablement, il n'y a pas de sécurité à 100%. Mais le point de départ pour Android, que Google a construit dans, est ProGuard. Si vous avez la possibilité d'inclure les bibliothèques partagées, vous pouvez inclure le besoin de code en C++ pour vérifier la taille des fichiers, de l'intégration,de etc. Si vous avez besoin d'ajouter un externe à la bibliothèque native de votre APK de la bibliothèque du dossier sur chaque génération, ensuite, vous pouvez l'utiliser par la suggestion ci-dessous.

Mettre de la bibliothèque dans la bibliothèque native chemin d'accès par défaut pour "libs" votre dossier de projet. Si vous avez construit le code natif pour le 'armeabi' cible, puis la mettre en vertu de libs/armeabi. Si elle a été construite avec armeabi-v7a puis le mettre sous libs/armeabi-v7a.

<project>/libs/armeabi/libstuff.so

Answer 2

Autant que je sache, vous ne pouvez pas protéger les fichiers dans le répertoire res plus qu'ils sont protégés dès maintenant.

Cependant, il ya des étapes que vous pouvez prendre pour protéger votre code source, ou du moins de ce qu'il ne si pas tout.

1. Utiliser des outils comme ProGuard. Ces dissimuler votre code, et de le rendre plus difficile à lire quand décompilé, si ce n'est impossible.
2. Déplacer des composants les plus importants du service de l'application, et dans un webservice, caché derrière un langage côté serveur comme PHP. Par exemple, si vous avez un algorithme qui vous est pris d'un million de dollars à écrire. Manifestement, vous ne voulez pas de se la faire voler hors de votre application. Déplacer l'algorithme et de l'avoir traiter les données sur un serveur distant, et utiliser l'application pour simplement lui fournir les données. Ou utiliser le NDK à les écrire en natif dans la .donc les fichiers, qui sont beaucoup moins susceptibles d'être décompilé que les apk. Je ne pense pas qu'un décompilateur .si les fichiers de même qu'il existe dès maintenant (et même si elle l'était, elle ne serait pas aussi bon que le Java décompilation). En outre, comme @nikolay mentionné dans les commentaires, vous devez utiliser SSL lors de l'interaction entre le serveur et l'appareil.
3. Lors du stockage des valeurs sur l'appareil, ne pas les stocker dans un format brut. Par exemple, si vous avez un jeu, et vous êtes à la mémorisation de la quantité de monnaie du jeu, l'utilisateur a en SharedPreferences. Imaginons qu'il l' 10000 des pièces de monnaie. Au lieu de sauver 10000 directement, l'enregistrer en utilisant un algorithme de type ((currency*2)+1)/13. Ainsi, au lieu de 10000, vous enregistrez 1538.53846154 dans les SharedPreferences. Cependant, l'exemple ci-dessus n'est pas parfait, et vous aurez à travailler à trouver une équation qui ne perdra pas de monnaie à des erreurs d'arrondi etc.
4. Vous pouvez faire quelque chose de similaire pour le côté serveur de tâches. Maintenant pour l'exemple, nous allons réellement prendre votre traitement de paiement app. Disons que l'utilisateur doit faire un paiement de $200. Au lieu d'envoyer un raw $200 de la valeur au serveur d'envoyer une série de plus petits, les prédéfinis, les valeurs qui s'ajoutent à l' $200. Par exemple, avoir une table ou un fichier sur votre serveur et qui équivaut en termes de valeurs. Donc, disons que Charlie correspond $47, et John de $3. Ainsi, au lieu de l'envoi d' $200, vous pouvez envoyer Charlie quatre fois et John quatre fois. Sur le serveur, d'interpréter ce qu'ils signifient et l'ajouter. Cela empêche un pirate d'envoyer des valeurs arbitraires à votre serveur, car ils ne savent pas ce mot correspond à la valeur. Par mesure de sécurité, vous pourriez avoir une équation similaire pour le point 3, ainsi, et de modifier les mots clés de chaque n nombre de jours.
5. Enfin, vous pouvez insérer aléatoire inutiles code source de votre application, de sorte que le pirate est à la recherche d'une aiguille dans une botte de foin. Insertion aléatoire de classes contenant des extraits de l'internet, ou tout simplement des fonctions pour le calcul aléatoire des choses comme la suite de Fibonacci. Assurez-vous que ces classes compiler, mais ne sont pas utilisés par la fonctionnalité réelle de l'application. Ajouter assez de ces faux classes, et le hacker aurait un moment difficile de trouver votre code réel.

Dans l'ensemble, il n'y a aucun moyen de protéger votre application 100%. Vous pouvez le rendre plus dur, mais pas impossible. Votre serveur web pourrait être compromise, le pirate pourrait comprendre des mots-clés de la surveillance de plusieurs montants des transactions et les mots clés que vous envoyez pour cela, le pirate pourrait soigneusement de passer par la source et le chiffre de code est un mannequin.

Vous pouvez seulement de lutter, mais ne gagne jamais.

Answer 3

À aucun moment dans l'histoire de l'informatique a jamais été possible d'empêcher la rétro-ingénierie du logiciel, lorsque vous donnez une copie de travail de votre attaquant. Aussi, dans la plupart probabilité, il ne sera jamais possible.

Avec ce compris, il y a une solution évidente: ne donnez pas vos secrets à votre attaquant. Si vous ne pouvez pas protéger le contenu de votre APK, ce que vous pouvez protéger est quelque chose que vous n'avez pas de distribuer. Il s'agit généralement d'un logiciel côté serveur utilisé pour des choses comme l'activation, les paiements, la règle d'application, et d'autres juteux morceaux de code. Vous pouvez protéger les actifs de valeur par pas de les distribuer dans votre APK. Au lieu de cela, mettre en place un serveur qui répond à la demande à partir de votre application, "utilise" les actifs (quoi que cela puisse signifier), puis envoie le résultat de l'application. Si ce modèle ne fonctionne pas pour les actifs que vous avez en tête, alors vous pouvez repenser votre stratégie.

Aussi, si votre principal objectif est d'empêcher l'application de la piraterie: ne même pas la peine. Vous avez déjà brûlé plus de temps et d'argent sur ce problème que toute mesure anti-piratage pourrait jamais espérer pour vous sauver. Le retour sur investissement de la solution de ce problème est tellement faible qu'il n'a pas de sens même d'y penser.

Answer 4

Première règle de sécurité des applications: Toute machine à laquelle un attaquant sans restriction physique ou électronique d'accès appartient maintenant à votre attaquant, indépendamment de l'endroit où il est réellement ou ce que vous avez payé pour cela.

Deuxième règle d'application de la sécurité: Tout logiciel qui laisse les limites physiques à l'intérieur de laquelle un attaquant ne peut pas pénétrer appartient désormais à votre agresseur, peu importe combien de temps vous avez passé à coder ça.

Troisième règle: Toute information qui laisse ces mêmes limites physiques qu'un attaquant ne peut pas pénétrer appartient désormais à votre agresseur, peu importe combien il est utile de vous.

Les fondements de la technologie de l'information de sécurité sont basées sur ces trois principes fondamentaux; la seule véritable sécurité de l'ordinateur est le seul enfermé dans un coffre, à l'intérieur d'une cage de Farraday, à l'intérieur d'une cage en acier. Il y a des ordinateurs qui passent la plupart de leur durée de vie soit juste cet état; une fois par an (ou moins), ils génèrent les clés privées des autorités de certification racine approuvées (devant une foule de témoins, avec des caméras d'enregistrement pour chaque pouce de la pièce dans laquelle ils se trouvent).

Maintenant, la plupart des ordinateurs ne sont pas utilisés dans ces types de milieux; ils sont physiquement dehors dans l'ouvert, connecté à Internet sur un réseau sans fil station de radio. En bref, ils sont vulnérables, de même que leur logiciel. Ils sont, par conséquent, de ne pas être digne de confiance. Il y a certaines choses que les ordinateurs et leurs logiciels doivent savoir ou faire pour être utile, mais des précautions doivent être prises pour s'assurer qu'ils ne peuvent jamais savoir ou faire assez pour causer des dommages (au moins pas de dommages permanents à l'extérieur des limites de la machine seule).

Vous saviez déjà tout cela; c'est pourquoi vous êtes en essayant de protéger le code de votre application. Mais, c'est là le premier problème; l'obscurcissement outils peuvent rendre le code un gâchis pour un humain pour essayer de creuser à travers, mais le programme reste à exécuter; que le cheminement logique de l'application et les données qu'il utilise ne sont pas affectés par l'obscurcissement. Avec un peu de ténacité, un attaquant peut simplement des nations unies-obfusquer le code, et qui n'est même pas nécessaire, dans certains cas, où ce qu'il cherche à ne peut pas être autre chose que ce qu'il cherche.

Au lieu de cela, vous devriez être en essayant de faire en sorte qu'un attaquant ne peut pas faire n'importe quoi avec votre code, peu importe combien il est facile pour lui d'obtenir une copie claire de. Cela signifie que, pas codé en dur secrets, parce que ces secrets ne sont pas un secret dès que le code des feuilles de l'immeuble dans lequel vous l'avez développée.

Ces valeurs-clés que vous avez codé en dur doit être supprimé de l'application du code source entièrement. Au lieu de cela, ils doivent être dans l'un des trois endroits; volatile de la mémoire sur l'appareil, ce qui est plus difficile (mais pas impossible) pour un attaquant d'obtenir une copie hors connexion de; de manière permanente sur le serveur de cluster, à qui vous contrôle d'accès avec un poing de fer, ou dans un deuxième magasin de données sans rapport avec votre appareil ou des serveurs, comme une carte physique ou de l'utilisateur de votre souvenirs (ce qui signifie qu'il sera finalement dans une mémoire volatile, mais il n'a pas à être pour longtemps).

Considérons le schéma suivant. L'utilisateur saisit ses informations d'identification pour l'application de la mémoire dans l'appareil. Vous devez, malheureusement, la confiance que l'appareil de l'utilisateur n'est pas déjà compromise par un keylogger ou un cheval de Troie; le meilleur que vous pouvez faire à cet égard est la mise en œuvre multi-facteur de sécurité, en se souvenant de dur-à-faux des informations d'identification concernant les appareils que l'utilisateur a utilisé (MAC/IP, IMEI, etc), et de fournir au moins un canal supplémentaire par lequel une tentative de connexion sur un nouveau périphérique peut être vérifiée.

Les informations d'identification, une fois entré, camouflés par le logiciel client (à l'aide d'un hachage sécurisé), et la plaine de texte les informations d'identification rejetés; ils ont servi leur but. L'obfuscation les informations d'identification sont transmises sur un canal sécurisé pour le certificat de serveur authentifié, qui hachages eux à nouveau pour produire les données utilisées pour vérifier la validité de la connexion. De cette façon, le client ne sait jamais ce qui est réellement par rapport à la valeur de base de données, le serveur d'application ne sait jamais le texte en clair des informations d'identification derrière ce qu'il reçoit pour la validation, le serveur de données ne sait jamais comment les données qu'elle stocke de la validation est produite, et un homme dans le milieu ne voit que du charabia, même si le canal sécurisé a été compromise.

Une fois cette vérification effectuée, le serveur transmet en retour un jeton sur le canal. Le jeton n'est utile que dans la session sécurisée, se compose de bruit aléatoire ou chiffré (et donc vérifiables) copie des identifiants de session, et l'application client doit envoyer ce jeton sur le même canal sur le serveur dans le cadre de toute demande de faire quelque chose. L'application cliente de faire de nombreuses fois, car il ne peut pas faire quelque chose impliquant de l'argent, des données sensibles, ou toute autre chose qui pourrait être préjudiciable par lui-même; il doit, au contraire, demandez au serveur pour effectuer cette tâche. L'application cliente de ne jamais écrire toute information à caractère sensible de la persistance de la mémoire sur l'appareil lui-même, du moins pas dans le texte; le client peut demander au serveur à travers le canal sécurisé par une clé symétrique pour chiffrer des données locales, dont le serveur n'oubliez pas que dans une session ultérieure, le client peut demander au serveur pour la même clé pour déchiffrer les données pour les utiliser dans la mémoire volatile. Que les données ne seront pas la seule copie, soit; tout ce que le client stocke doivent également être transmises sous une certaine forme, le serveur.

De toute évidence, ce qui rend votre application dépend fortement de l'accès Internet, le client périphérique ne peut pas accomplir l'une de ses fonctions de base, sans une bonne connexion et l'authentification par le serveur. Pas différent de Facebook, vraiment.

Maintenant, l'ordinateur que l'attaquant veut, c'est votre serveur, parce que c'et pas de l'application client/de l'appareil est la chose qui peut lui faire de l'argent ou de provoquer d'autres personnes de la douleur pour sa jouissance. C'est OK, vous obtenez beaucoup plus pour votre argent dépenser de l'argent et des efforts pour sécuriser le serveur que pour essayer de garantir que tous les clients. Le serveur peut être derrière tous les types de pare-feux et autres moyens électroniques de sécurité, et de plus, ils peuvent être physiquement sécurisés au moyen de l'acier, du béton, de keycard/pin d'accès et de surveillance vidéo 24 heures. L'attaquant aurait besoin d'être très sophistiqué en effet d'acquérir tout type d'accès à directement sur le serveur, et vous ne le sais tout de suite.

Le meilleur, un attaquant peut faire est de voler le téléphone de l'utilisateur et les informations d'identification et de vous connecter sur le serveur avec les droits limités du client. Si cela se produit, tout comme la perte d'une carte de crédit, le légitime utilisateur doit être instruit pour appeler un numéro 800 (de préférence facile à retenir, et pas sur le dos d'une carte qu'ils allaient l'emporter dans leur sac à main, un portefeuille ou un porte-documents qui pourraient être volés aux côtés de l'appareil mobile) à partir de n'importe quel téléphone, ils peuvent accéder à qui les relie directement à votre service à la clientèle. Ils déclarent leur téléphone a été volé, de fournir quelques éléments de base d'un identifiant unique, et le compte est verrouillé, toutes les transactions à l'attaquant peut avoir été en mesure de traiter sont annulées, et de l'attaquant est de retour à la case départ.

Answer 5

1. Comment puis-je éviter complètement l'ingénierie inverse d'un Android APK? Est-ce possible?

Ce n'est pas possible

2. Comment puis-je protéger tout ce que l'application de ses ressources, de biens et de code source, de sorte que les pirates ne peuvent pas pirater le fichier APK?

Quand quelqu'un changement un .apk extension .zip, puis, après décompression, quelqu'un peut facilement obtenir toutes les ressources (à l'exception de Manifest.xml), mais avec APKtool l'on peut obtenir le contenu réel du fichier manifeste. Encore une fois, un pas.

3. Est-il un moyen de rendre le piratage plus difficile, voire impossible? Ce que je peux faire de plus pour protéger le code source dans mon fichier APK?

Encore une fois, non, mais vous pouvez éviter jusqu'à un certain niveau, c'est,

• Télécharger une ressource sur le Web et faire un peu de processus de chiffrement
• Utiliser un pré-compilé à la bibliothèque native (C, C++, JNI, NDK)
• Toujours effectuer certaines de hachage (MD5/SHA clés ou tout autre logique)

Même avec Smali, les gens peuvent jouer avec votre code. Dans l'ensemble, il n'est pas POSSIBLE.