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

AFAIK, vous ne pouvez pas protéger les fichiers dans le répertoire /res plus qu'ils ne sont protégés en ce moment.

cependant, il y a des mesures que vous pouvez prendre pour protéger votre code source, ou du moins ce qu'il fait sinon tout.

1. utiliser des outils comme ProGuard. Celles-ci brouilleront votre code, et le rendront plus difficile à lire en cas de décompilation, voire impossible.
2. déplacer les parties les plus critiques du service hors 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 a pris un million de dollars à écrire. Vous ne voulez évidemment pas que les gens le volent 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 utilisez le NDK pour les écrire nativement .donc les fichiers, qui sont beaucoup moins susceptibles d'être décomposés que les APK. Je ne pense pas qu'un décompilateur pour .donc même les fichiers existe dès maintenant (et même s'il existait, il ne serait pas aussi bon que les java decompilers). De plus, comme @nikolay l'a mentionné dans les commentaires, vous devriez utiliser SSL lorsque vous interagissez entre le serveur et l'appareil.
3. lorsque vous stockez des valeurs sur l'appareil, ne les stockez pas dans un format brut. Par exemple, si vous avez un jeu, et vous stockez le montant de dans la devise du jeu que l'Utilisateur a en SharedPreferences. Supposons que ce soit des pièces de 10000 . Au lieu de sauver 10000 directement, enregistrez-le en utilisant un algorithme comme ((currency*2)+1)/13 . Ainsi, au lieu de 10000 , vous sauvegardez 1538.53846154 dans les références partagées. Cependant, l'exemple ci-dessus n'est pas parfait, et vous devrez travailler pour trouver une équation qui ne perdra pas la monnaie à des erreurs d'arrondi, etc.
4. vous pouvez faire une chose similaire pour les tâches côté serveur. Maintenant, pour un exemple, prenons en fait votre application de traitement de paiement. Disons que l'utilisateur doit faire un paiement de 0 . Plutôt envoyer une valeur brute 0 au serveur, envoyer une série de plus petites valeurs prédéfinies qui totalisent 0 . Par exemple, avoir un fichier ou une table sur votre serveur qui égalise des mots avec des valeurs. Alors disons que Charlie correspond à , et John à . Donc au lieu d'envoyer 0 , 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 de envoyer des valeurs arbitraires à votre serveur, car ils ne savent pas quel mot correspond à quelle valeur. Comme mesure supplémentaire de sécurité, vous pourriez avoir une équation similaire au point 3 pour ceci aussi bien, et changer les mots clés chaque n nombre de jours.
5. enfin, vous pouvez insérer du code source inutile et aléatoire dans votre application, de sorte que le hacker est à la recherche d'une aiguille dans une botte de foin. Insérez des classes aléatoires contenant des extraits de l'internet, ou juste des fonctions pour calculer des choses aléatoires comme la séquence de Fibonacci. Assurez-vous que ces classes compilent, mais ne sont pas utilisées par les fonctionnalités réelles de l'application. Ajoutez assez de ces fausses classes, et le hacker aurait du mal à trouver votre vrai code.

en somme, il n'y a aucun moyen de protéger votre application à 100%. Tu peux rendre ça plus difficile, mais pas impossible. Votre serveur web pourrait être compromis, le hacker pourrait comprendre vos mots-clés en surveillant les transactions multiples les quantités et les mots-clés que vous envoyez pour elle, le hacker pourrait laborieusement passer par la source et de comprendre quel code est un mannequin.

vous ne pouvez riposter, mais jamais gagner.

À 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. En outre, dans la plupart des probabilités, il ne sera jamais possible .

avec cela compris, il y a une solution évidente: ne donnez pas vos secrets à votre attaquant. tant que vous ne pouvez pas protéger le contenu de votre APK, ce que vous peut protéger est-ce que vous n'avez pas de distribuer. Généralement, il s'agit de logiciels Côté Serveur utilisés pour des choses comme l'activation, les paiements, l'application des règles, et d'autres morceaux juteux de code. Vous pouvez protéger les biens de valeur en et non en les distribuant dans votre APK. Au lieu de cela, mettez en place un serveur qui répond aux requêtes de votre application, "utilise" les ressources (peu importe ce que cela pourrait signifier) et envoie ensuite le résultat à 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 objectif principal est de prévenir le piratage de l'application : ne vous embêtez même pas. Vous avez déjà dépensé plus de temps et d'argent sur ce problème que n'importe quelle mesure anti-piratage pourrait espérer vous sauver. Le retour sur investissement pour résoudre ce problème est si faible qu'il n'est pas logique d'y penser.

première règle de sécurité app: toute machine à laquelle un attaquant obtient un accès physique ou électronique illimité appartient maintenant à votre attaquant, indépendamment de l'endroit où il est réellement ou ce que vous avez payé pour elle.

deuxième règle de sécurité de l'application: tout logiciel qui quitte les limites physiques à l'intérieur desquelles un attaquant ne peut pas pénétrer appartient maintenant à votre attaquant, indépendamment de combien de temps vous passé de codage.

troisième règle: toute information qui laisse ces mêmes limites physiques qu'un attaquant ne peut pas franchir appartient maintenant à votre attaquant, peu importe sa valeur pour vous.

les fondements de la sécurité des technologies de l'information reposent sur ces trois principes fondamentaux; le seul ordinateur vraiment sûr est celui qui est enfermé dans un coffre-fort, à l'intérieur d'une cage de Farraday, à l'intérieur d'une cage d'acier. Y sont des ordinateurs qui passent la plus grande partie de leur vie utile dans cet état; une fois par année (ou moins), ils produisent les clés privées pour les autorités de certification racine de confiance (devant une foule de témoins avec des caméras enregistrant chaque pouce de la salle dans laquelle ils sont situés).

Aujourd'hui, la plupart des ordinateurs ne sont pas utilisés dans ce type d'environnement; ils sont physiquement à l'air libre, connectés à Internet par un canal radio sans fil. En bref, ils sont vulnérables, comme est 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 utiles, mais il faut veiller à ce qu'ils ne puissent jamais savoir ou faire assez pour causer des dommages (du moins pas de dommages permanents en dehors des limites de cette seule machine).

vous saviez déjà tout cela; c'est pourquoi vous essayez de protéger le code de votre application. Mais c'est là que réside le premier problème; les outils d'obscurcissement 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 désamorcer le code, et ce n'est même pas nécessaire dans certains cas où ce qu'il regarde ne peut pas être autre chose que ce qu'il cherche.

au lieu de cela, vous devriez essayer de vous assurer qu'un attaquant ne peut rien faire avec votre le code, aussi facile soit-il pour lui d'en obtenir une copie claire. Ça veut dire, pas de secrets codés, parce que ces secrets ne sont pas Secrets dès que le code quitte le bâtiment dans lequel vous l'avez développé.

ces valeurs clés que vous avez codées en dur doivent être retirées du code source de l'application. Au lieu de cela, ils devraient être à l'un des trois endroits; mémoire volatile sur le périphérique, ce qui est plus difficile (mais pas impossible) pour un attaquant d'obtenir une copie hors ligne de; en permanence sur le cluster de serveurs, auquel vous contrôlez l'accès avec une main de fer; ou dans un deuxième stockage de données sans rapport avec votre appareil ou vos serveurs, comme une carte physique ou dans les mémoires de votre utilisateur (ce qui signifie qu'il sera éventuellement dans la mémoire volatile, mais il ne doit pas être pour longtemps).

envisager 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à compromis par un keylogger ou un cheval de Troie; le mieux que vous pouvez faire à cet égard est de mettre en œuvre la sécurité multi-facteurs, en se rappelant des informations d'identification difficiles à truquer sur les appareils que l'Utilisateur a utilisés (MAC/IP, IMEI, etc), et en fournissant au moins un canal supplémentaire par lequel une tentative de connexion sur un appareil inconnu peut être vérifiée.

les justificatifs d'identité, une fois entrés, sont masqués par le logiciel client (en utilisant un hachage sécurisé), et les justificatifs d'identité en clair sont rejetés; ils ont servi leur but. Les justificatifs d'identité brouillés sont envoyés via un canal sécurisé vers le serveur authentifié par certificat, qui les à 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 comparé à la valeur de la base de données, le serveur d'applications ne connaît jamais les références en clair derrière ce qu'il reçoit pour la validation, le serveur de données ne sait jamais comment les données qu'il stocke pour la validation sont produites, et un homme au milieu ne voit que du charabia, même si la voie de communication était compromise.

une fois vérifié, le serveur renvoie un token sur le canal. Le token n'est utile qu'au sein de la session sécurisée, il est composé soit de bruits aléatoires, soit d'une copie chiffrée (et donc vérifiable) des identificateurs de session, et l'application client doit envoyer ce token sur le même canal au serveur dans le cadre de toute demande de faire quelque chose. L'application client le fera souvent, parce qu'il ne peut rien faire impliquant de l'argent, des données sensibles, ou quoi que ce soit d'autre qui pourrait être dommageable par lui-même; il doit plutôt demander au serveur de faire cette tâche. L'application client n'écrira jamais aucune information sensible à la mémoire persistante sur le périphérique lui-même, du moins pas en texte simple; le client peut demander au serveur sur le canal sécurisé pour une clé symétrique pour crypter toutes les données locales, dont le serveur se souviendra; dans une session ultérieure le client peut demander au serveur pour la même clé pour décrypter les données pour une utilisation en mémoire volatile. Ces données ne seront pas la seule copie, non plus; Tout ce que le client stocke doit également être transmis sous une forme quelconque au serveur.

évidemment, cela rend votre application fortement dépendante de l'accès à Internet; le périphérique client ne peut pas effectuer n'importe laquelle de ses fonctions de base sans connexion appropriée et authentification par le serveur. Pas différent de Facebook, vraiment.

Maintenant, l'ordinateur qui l'attaquant veut est votre serveur, parce qu'il et non le client app/périphérique est la chose qui peut lui faire de l'argent ou causer la douleur d'autres personnes pour son plaisir. C'est OK; vous obtenez beaucoup plus bang pour votre argent dépenser de l'argent et l'effort pour sécuriser le serveur que dans essayer de sécuriser tous les clients. Le serveur peut être derrière toutes sortes de pare-feu et d'autres sécurité électronique, et en outre peut être physiquement sécurisé derrière l'acier, béton, Accès clavier/broche, et 24 heures de surveillance vidéo. Votre l'attaquant devrait être très sophistiqué en effet pour obtenir tout type d'accès au serveur directement, et vous (devrait) savoir à ce sujet immédiatement.

le mieux qu'un attaquant puisse faire est de voler le téléphone et les justificatifs d'identité d'un utilisateur et de se connecter au serveur avec les droits limités du client. Si cela se produit, tout comme la perte d'une carte de crédit, l'utilisateur légitime devrait être instruit d'appeler un numéro 800 (de préférence facile à se rappeler, et pas sur le dos d'une carte qu'ils auraient portez dans leur sac à main, portefeuille ou mallette qui pourrait être volé à côté de l'appareil mobile) à partir de tout téléphone qu'ils peuvent accéder qui les relie directement à votre service à la clientèle. Ils déclarent que leur téléphone a été volé, fournissent un identificateur unique de base, et le compte est verrouillé, toutes les transactions que l'attaquant a pu traiter sont retranchées, et l'attaquant est de retour à la case départ.

1. Comment puis-je éviter complètement la rétro-ingénierie D'un APK Android? Est-ce possible?

C'est impossible

2. Comment puis-je protéger toutes les ressources, les ressources et le code source de l'application pour que les pirates ne puissent pas pirater le fichier APK de quelque manière que ce soit?

quand quelqu'un change A.apk extension .zip, puis, après décompression, quelqu'un peut facilement obtenez toutes les ressources (sauf le Manifeste ).xml ), mais avec APKtool on peut obtenir le contenu réel du fichier manifeste aussi. Encore une fois, un pas.

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

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

• télécharger une ressource à partir du Web et faire un peu de chiffrement
• utiliser une bibliothèque native pré-compilée (C, C++, JNI, NDK)
• toujours effectuer un certain hachage ( MD5 / SHA clés ou toute autre logique)

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

100% évitement de rétro-ingénierie de L'apk Android N'est pas possible, mais vous pouvez utiliser ces moyens pour éviter d'extraire plus de données, comme le code source, les actifs de votre APK, et des ressources:

1. utilisez ProGuard pour masquer le code d'application

2. Utiliser NDK à l'aide C et C++ mettre votre application de base et de sécuriser une partie de code dans la section .so fichiers

3. pour sécuriser les ressources, n'incluez pas toutes les ressources importantes dans le dossier ACTIFS avec APK. Téléchargez ces ressources au moment de la première demande.

les développeurs peuvent prendre les mesures suivantes pour empêcher un APK de voler d'une manière ou d'une autre,

• le moyen le plus simple est d'utiliser des outils comme ProGuard pour brouiller leur code, mais jusqu'à présent, il a été assez difficile d'empêcher complètement quelqu'un de décomposer une application.

• aussi j'ai entendu parler d'un outil HoseDex2Jar . Il arrête Dex2Jar en insérant un code inoffensif dans un APK Android qui confond et désactive Dex2Jar et protège le code de la décompilation. Cela pourrait empêcher les hackers de décomposer un APK en code java lisible.

• utilisez une application côté serveur pour communiquer avec l'application seulement quand il est nécessaire. Il pourrait aider à prévenir les données importantes.

du tout, vous ne pouvez pas protéger complètement votre code contre les pirates potentiels. D'une façon ou d'une autre, vous pourriez rendre la tâche difficile et un peu frustrante pour eux de décompiler votre code. L'un des moyens les plus efficaces est d'écrire en code natif(C/C++) et de le stocker sous forme de bibliothèques compilées.

1. Comment puis-je éviter complètement la rétro-ingénierie D'un APK Android? Est-ce possible?

C'est impossible

2. Comment puis-je protéger toutes les ressources, les ressources et le code source de l'application pour que les pirates ne puissent pas pirater le fichier APK de quelque manière que ce soit?

les développeurs peuvent prendre des mesures telles que l'utilisation D'outils comme ProGuard pour obscurcir leur code, mais jusqu'à maintenant, il a été assez difficile de prévenir quelqu'un de décompiler une application.

c'est un outil vraiment génial et peut augmenter la difficulté d '"inverser" votre code tout en réduisant l'empreinte de votre code.

: ProGuard est désormais emballé avec les outils SDK. Les développeurs peuvent maintenant masquer leur code en tant que partie intégrée d'une construction de version.

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

en faisant des recherches, j'ai appris au sujet de HoseDex2Jar . Cet outil protégera votre code de la décomposition, mais il ne semble pas possible de le protéger complètement.

quelques liens utiles, vous pouvez vous y référer.

• Proguard, Android, et le serveur de licence
• Securing Android LVL Applications
• Stack Overflow question Est-il vraiment impossible de protéger les applications Android de l'ingénierie inverse?
• Stack Overflow question Comment prévenir l'ingénierie inverse d'un Android APK fichier de code sécurisé?

1. Comment puis-je éviter complètement la rétro-ingénierie D'un APK Android? Est-ce possible?

Impossible

2. Comment puis-je protéger toutes les ressources, les ressources et le code source de l'application pour que les pirates ne puissent pas pirater le fichier APK de quelque manière que ce soit?

Impossible

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

Plus dure possible, mais en fait, il sera plus difficile surtout pour l'utilisateur moyen, qui est juste googler pour le piratage des guides. Si quelqu'un veut vraiment pirater votre application - il sera piraté, tôt ou tard.

Voici quelques méthodes que vous pouvez essayer:

1. Utiliser obfuscation et des outils comme les ProGuard .
2. chiffrez une partie de la source et des données.
3. utilisez un checksum propriétaire intégré dans l'application pour détecter la falsification.
4. introduire du code pour éviter de charger dans un débogueur, c'est-à-dire laisser l'application avoir la capacité de détecter le débogueur et sortir / tuer le débogueur.
5. séparer l'authentification comme un service en ligne.
6. Utiliser "1519180920 application de" la diversité
7. utiliser la technique d'impression au doigt pour, par exemple, les signatures matérielles des dispositifs de différents sous-systèmes avant d'authentifier le dispositif.

la question principale ici est que les fichiers dex peuvent être décomposés et la réponse est qu'ils peuvent être "en quelque sorte". Il existe des désassembleurs comme dedexer et smali .

ProGuard, correctement configuré, brouillera votre code. DexGuard qui est une version étendue commerciale de ProGuard, peut aider un peu plus. Cependant, votre code peut encore être converti en smali et les développeurs avec de l'expérience en rétroingénierie seront en mesure de comprendre ce que vous faites de la smali.

peut-être choisir une bonne licence et l'appliquer par la loi de la meilleure façon possible.

Votre client devrait embaucher quelqu'un qui sait ce qu'ils font, qui peut prendre les bonnes décisions et peut mentor.

parler ci - dessus de votre capacité à changer le système de traitement des transactions sur le backend est absurde-vous ne devriez pas être autorisé à faire de tels changements d'architecture, alors ne vous attendez pas à être en mesure de le faire.

Mon raisonnement sur ce point:

puisque votre domaine est le traitement de paiement, il est sûr de supposer que le DSS PCI et/ou le DSS PA (et le droit potentiel de l'État / fédéral) sera important pour votre entreprise - pour être conforme, vous devez montrer que vous êtes en sécurité. Pour être peu sûr puis découvrir (via des tests) que vous n'êtes pas sûr, puis réparer, retester, etc jusqu'à ce que la sécurité peut être vérifiée à un niveau approprié = coûteux, lent, moyen à haut risque de succès. Pour faire la bonne chose, penser dur à l'avance, engager le talent expérimenté pour le travail, développer d'une manière sûre, puis tester, fixer (moins), etcetera (moins) jusqu'à ce que la sécurité peut être vérifiée à un niveau approprié = moyen peu coûteux, rapide et à faible risque de réussir.

L'autre upvoted ici les réponses sont correctes. Je veux juste fournir une autre option.

pour certaines fonctionnalités que vous jugez importantes, vous pouvez héberger le contrôle WebView dans votre application. La fonctionnalité serait alors implémentée sur votre serveur web. Il aura l'air d'être dans votre application.

si nous voulons rendre la rétro-ingénierie (presque) impossible, nous pouvons mettre l'application sur une puce hautement inviolable, qui exécute toutes les choses sensibles en interne, et communique avec un certain protocole pour rendre le contrôle GUI possible sur l'hôte. Même les puces inviolables ne sont pas 100% à l'épreuve des fissures; elles placent la barre beaucoup plus haut que les méthodes logicielles. Bien sûr, c'est un inconvénient: l'application nécessite une petite verrue USB qui contient la puce à insérer dans appareil.

la question ne révèle pas la motivation pour vouloir protéger cette application si jalousement.

si le but est d'améliorer la sécurité du mode de paiement en dissimulant les failles de sécurité que la demande peut avoir (connues ou non), elle est complètement erronée. Les bits sensibles du point de vue de la sécurité devraient en fait être de source ouverte, si cela est faisable. Vous devez rendre la tâche aussi facile que possible pour tout chercheur en sécurité qui: examine votre application pour trouver ces bits et scruter leur fonctionnement, et de vous contacter. Les demandes de paiement ne doivent pas contenir de certificats intégrés. C'est-à-dire qu'il ne devrait y avoir aucune application serveur qui fait confiance à un périphérique simplement parce qu'il a un certificat fixe de l'usine. Une transaction de paiement doit être effectuée uniquement sur les justificatifs d'identité de l'utilisateur, en utilisant un protocole d'authentification de bout en bout correctement conçu qui empêche de faire confiance à l'application, à la plate-forme ou à la réseau, etc.

si le but est d'empêcher le clonage, à moins de cette puce inviolable, il n'y a rien que vous puissiez faire pour protéger le programme contre la rétro-ingénierie et la copie, de sorte que quelqu'un intègre une méthode de paiement compatible dans leur propre application, donnant naissance à des"clients non autorisés". Il y a des façons de rendre difficile le développement de clients non autorisés. L'une serait de créer sommes basés sur les instantanés de l'etat: l'etat variables, pour tout. GUI, logique, peu importe. Un programme de clones n'aura pas exactement le même état interne. Bien sûr, c'est une machine d'état qui a des transitions d'état similaires extérieurement visibles (comme on peut l'observer par les entrées et sorties), mais à peine le même état interne. Une application serveur peut interroger le programme: Quel Est votre état détaillé? (i.e. donnez-moi un checksum sur toutes vos variables d'état internes). Ceci peut être comparé avec le code client fictif qui s'exécute sur le serveur en parallèle, passant par les véritables transitions d'état. Un clone tiers devra reproduire tous les changements d'état pertinents du programme genuine afin de donner les réponses correctes, ce qui entravera son développement.

en tant que quelqu'un qui a travaillé intensivement sur les plates-formes de paiement, y compris une application de paiements mobiles (MyCheck), je dirais que vous devez déléguer ce comportement au serveur, aucun nom d'utilisateur ou mot de passe pour le processeur de paiement (quel qu'il soit) devrait être stocké ou codé en dur dans l'application mobile, c'est la dernière chose que vous voulez, parce que la source peut être compris même si vous obscurcissez le code.

aussi, vous ne devriez pas stocker des cartes de crédit ou jetons de paiement sur l'application, tout devrait être, encore une fois, délégué à un service que vous avez construit, il vous permettra également plus tard, être conforme à la PCI plus facilement, et les sociétés de cartes de crédit ne sera pas descendre votre cou (comme ils l'ont fait pour nous).

je vous suggère de regarder protéger les Applications logicielles contre les attaques . C'est un service commercial, mais la compagnie de mon ami l'a utilisé et ils sont heureux de l'utiliser.

APK schéma de signature v2 Android N

la classe PackageManager supporte maintenant la vérification des applications en utilisant le schéma de signature APK v2. Le schéma de signature APK v2 est un schéma de signature de fichier entier qui améliore considérablement la vitesse de vérification et renforce les garanties d'intégrité en détectant toute modification non autorisée des fichiers APK.

pour maintenir la rétrocompatibilité, une APK doit être signée avec la signature v1 signature (JAR signature scheme) avant d'être signé avec le v2 signature scheme. Avec le schéma de signature v2, la vérification échoue si vous signez L'APK avec un certificat supplémentaire après avoir signé avec le schéma v2.

APK schéma de signature v2 de soutien seront disponibles plus tard dans le N Developer Preview.

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

ce n'est pas possible. Il ne sera jamais possible. Cependant, il ya de l'espoir. Vous pouvez utiliser un obfuscator pour le rendre si certaines attaques communes sont beaucoup plus difficiles à effectuer, y compris des choses comme:

1. renommer les méthodes / classes (donc dans le décompilateur vous obtenez des types comme a.a )
2. brouillage du flux de contrôle (donc dans le décompilateur le code est très difficile à lire)
3. chiffrement les chaînes et, éventuellement, des ressources

je suis sûr qu'il y en a d'autres, mais ce sont les principales. Je travaille pour une société appelée PreEmptive Solutions sur un .NET obfuscator. Ils ont également un Java obfuscator qui fonctionne pour Android ainsi que celui appelé DashO .

L'obscurcissement a toujours un prix. Notamment, la performance est généralement pire, et il faut un certain temps supplémentaire autour des versions généralement. Toutefois, si votre propriété intellectuelle est extrêmement importante pour vous, elle en vaut généralement la peine.

sinon, votre seul choix est de faire en sorte que votre application Android passe juste par un serveur qui héberge toute la logique réelle de votre application. Cela a son propre lot de problèmes, car il signifie que les utilisateurs doivent être connectés à Internet pour utiliser votre application.

aussi, ce N'est pas seulement Android qui a ce problème. C'est un problème sur chaque app store. C'est juste une question de la difficulté d'accéder au fichier package (Par exemple, Je ne crois pas que ce soit très facile sur les iPhones, mais c'est encore possible).

il N'est pas possible d'éviter complètement RE mais en les rendant plus complexes à l'intérieur, vous mettez rendre plus difficile pour les attaquants de voir le fonctionnement clair de l'application, ce qui peut réduire le nombre de vecteurs d'attaque.

si l'application traite des données hautement sensibles, diverses techniques existent qui peuvent augmenter la complexité de la rétroingénierie de votre code. Une technique consiste à utiliser C/C++ pour limiter la manipulation facile du runtime par l'attaquant. Il y a suffisamment de C et les bibliothèques C++ qui sont très matures et faciles à intégrer avec Android offre JNI. Un attaquant doit d'abord contourner les restrictions de débogage afin d'attaquer l'application sur un bas niveau. Cela ajoute encore plus de complexité à une attaque. Les applications Android devraient avoir android: debuggable= "false" défini dans le manifeste de l'application pour empêcher la manipulation du temps d'exécution facile par un attaquant ou malware.

Trace Checking - une application peut déterminez si elle est actuellement tracée par un débogueur ou un autre outil de débogage. Si elle est tracée, l'application peut effectuer n'importe quel nombre d'actions possibles de réponse d'attaque, telles que le rejet des clés de cryptage pour protéger les données d'utilisateur, la notification d'un administrateur de serveur, ou d'autres réponses de type dans une tentative de se défendre. Ceci peut être déterminé en vérifiant les indicateurs d'état du processus ou en utilisant d'autres techniques comme comparer la valeur de retour de ptrace attach, vérifier le processus parent, liste noire des débogueurs dans la liste des processus ou comparaison des horodateurs sur différents lieux du programme.

optimisations - pour cacher des calculs mathématiques avancés et d'autres types de logique complexe, en utilisant des optimisations de compilateur peut aider obscurcir le code objet de sorte qu'il ne peut pas être facilement démonté par un attaquant, ce qui rend plus difficile pour un attaquant d'acquérir une compréhension du code particulier. Dans Android ceci peut être réalisé plus facilement en utilisant des bibliothèques compilées nativement avec le NDK. En outre, l'utilisation d'un Obfuscator LLVM ou d'un SDK protecteur fournira une meilleure obfuscation du code machine.

Stripping binaires – Stripping binaires natifs est un moyen efficace d'augmenter le temps et le niveau de compétence requis d'un attaquant afin de visualiser la composition des fonctions de bas niveau de votre application. En enlevant un binaire, la table de symboles de le binaire est dépouillé, de sorte qu'un attaquant ne peut pas facilement déboguer ou inverser une application.Vous pouvez vous référer aux techniques utilisées sur les systèmes GNU/Linux comme le striping ou L'utilisation D'UPX.

et enfin vous devez être conscient de l'obscurcissement et des outils comme ProGuard.

il n'y a aucun moyen d'éviter complètement la rétro-ingénierie D'un APK. Pour protéger les actifs d'application, les ressources, vous pouvez utiliser le cryptage.

• le chiffrement rendra son utilisation plus difficile sans décryptage.le choix d'un algorithme de cryptage fort rendra le craquage plus difficile.
• ajouter du code spoof dans votre logique principale pour rendre plus difficile la fissuration.
• si vous pouvez écrire votre logique critique dans n'importe quel natif langue et que sûrement rendre plus difficile pour décompiler.
• utilisant des cadres de sécurité de tiers comme Quixxi

D'accord avec @Muhammad Saqib ici: https://stackoverflow.com/a/46183706/2496464

et @Mumair donnent un bon départ: https://stackoverflow.com/a/35411378/474330

il est toujours sûr de supposer que tout ce que vous distribuez à l'appareil de votre utilisateur, appartiennent à l'utilisateur. La plaine et simple. Vous pouvez être en mesure d'utiliser les derniers outils et procédure de crypter vos propriétés intellectuelles mais il n'y a aucun moyen d'empêcher une personne déterminée d'étudier votre système. Et même si la technologie actuelle peut rendre difficile pour eux d'obtenir un accès non désiré, il pourrait y avoir un moyen facile demain, ou même juste la prochaine heure!

voici donc l'équation:

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

même aussi simple qu'une économie en jeu. (Surtout dans les jeux! Il y a des utilisateurs plus "sophistiqués" là-bas et des failles se propagent en quelques secondes!)

Comment rester en sécurité?

la plupart, si ce n'est la totalité, de nos systèmes de traitement de clés (et de notre base de données bien sûr) situés du côté du serveur. Et entre le client et le serveur, se trouve des communications cryptées, validations, etc. C'est l'idée de client léger.

les puces TPM (Trusted Platform Module) ne sont-elles pas censées gérer le code protégé pour vous ? Ils sont de plus en plus répandus sur les PC (en particulier ceux D'Apple) et ils peuvent déjà exister dans les puces de smartphone d'aujourd'hui. Malheureusement, il n'y a pas encore D'API OS pour l'utiliser. Si tout va bien Android va ajouter le soutien pour ce jour. C'est aussi la clé pour nettoyer le contenu DRM (sur lequel Google travaille pour WebM).

rien n'est sûr lorsque vous le mettez sur la main des utilisateurs finaux, mais une pratique courante peut rendre cela plus difficile pour l'attaquant de voler des données.

• mettez votre logique principale (algorithmes) du côté du serveur.
• communiquer avec le serveur et le client; s'assurer que la communication B/w serveur et le client est sécurisé via SSL ou HTTPS; ou utiliser d'autres techniques de génération de paire de clés algorithmes (ECC, RSA). S'assurer que les informations sensibles c'est de rester de bout en Bout chiffré.
• utiliser des sessions et les expirer après un intervalle de temps spécifique.
• chiffrez les ressources et récupérez-les du serveur à la demande.
• ou vous pouvez faire application hybride qui accéder au système via webview protéger la ressource + code sur le serveur

plusieurs approches; c'est évident que vous devez sacrifier parmi performance et sécurité

Comment puis-je protéger toutes les ressources, les ressources et le code source de l'application pour que les pirates ne puissent pas pirater le fichier APK de quelque manière que ce soit?

un fichier APK est protégé par l'algorithme SHA-1 . Vous pouvez voir certains fichiers dans le dossier META-INF D'APK. Si vous extrayez un fichier APK et en modifiez le contenu et le zip à nouveau et que vous lancez ce nouveau fichier APK sur une machine Android, il ne fonctionnera pas., parce que les Hash SHA-1 ne correspondront jamais.

bien que je sois d'accord qu'il n'y a pas de solution à 100% qui va protéger votre code, v3 de HoseDex2Jar est maintenant disponible si vous voulez essayer.

si votre application est aussi sensible, alors vous devriez considérer la partie de traitement de paiement côté serveur. Essayez de changer vos algorithmes de traitement des paiements. Utilisez l'application android uniquement pour la collecte et l'affichage des informations utilisateur (I. e solde du compte) et plutôt que de traiter des paiements à l'intérieur de codes java, envoyez cette tâche à votre serveur en utilisant un protocole SSL sécurisé avec des paramètres chiffrés. Créez une API entièrement cryptée et sécurisée pour communiquer avec votre serveur.

de bien sûr, il peut également être piraté aussi et il n'a rien à voir avec la protection des codes source, mais considérez-le une autre couche de sécurité pour le rendre plus difficile pour les pirates de tromper votre application.

quand ils ont de l'application sur leur téléphone, ils ont plein accès à la mémoire. donc si vous voulez l'empêcher d'être piraté, vous pouvez essayer de le faire de sorte que vous ne puissiez pas obtenir l'adresse mémoire statique directement en utilisant un débogueur. ils peuvent faire un débordement de tampon de pile s'ils ont un endroit pour écrire et ils ont une limite. alors essayez de le faire quand ils écrivent quelque chose, si u doit avoir une limite, s'ils envoient plus de caractères que limite, si (input > limit) alors ignorez, donc ils ne peuvent pas mettre code d'assemblage ici.

Outil: utiliser Proguard dans votre application il peut être limité à la rétroingénierie votre application

je peux voir cette bonne réponse dans ce fil . En plus de vous pouvez utiliser facebook redex pour optimiser le code. Redex travaille au niveau .dex où proguard travaille au niveau .class .

juste un ajout à déjà de bonnes réponses ci-dessus.

une autre astuce que je connais est de stocker des codes de valeur comme bibliothèque Java. Puis définissez cette bibliothèque pour être votre projet Android. Ce serait aussi bien que C. donc file mais Android Lib ferait l'affaire.

de cette façon, ces codes précieux stockés sur la bibliothèque Android ne seront pas visibles après la décomposition.