Comment éviter la reverse engineering d'un fichier APK?

Question

Je développe une application de traitement payment pour Android et je souhaite empêcher un pirate d’accéder à des ressources, des ressources ou du code source à partir du fichier APK .

Si quelqu'un modifie l'extension .apk en .Zip, il peut le décompresser et accéder facilement à toutes les ressources et ressources de l'application. Il est également possible d'accéder au code source en utilisant dex2jar et un décompilateur Java. Il est très facile de procéder à une ingénierie inverse d'un fichier APK Android - pour plus de détails, voir Stack Overflow question Reverse engineering d'un fichier APK à un projet .

J'ai utilisé l'outil Proguard fourni avec le SDK Android. Lorsque j'ingénierie inverse d'un fichier APK généré à l'aide d'un magasin de clés signé et de Proguard, je reçois un code obfusqué.

Toutefois, les noms des composants Android restent inchangés et certains codes, tels que les valeurs-clés utilisées dans l'application, restent inchangés. Selon la documentation de Proguard, l'outil ne peut pas masquer les composants mentionnés dans le fichier Manifest.

Maintenant mes questions sont:

Comment puis-je empêcher complètement la rétro-ingénierie d'un APK Android? Est-ce possible?
Comment protéger toutes les ressources, les ressources et le code source de l'application afin que les pirates ne puissent en aucun cas pirater le fichier APK?
Existe-t-il un moyen de rendre le piratage informatique plus difficile, voire impossible? Que puis-je faire de plus pour protéger le code source de mon fichier APK?

Bhavesh Patadiya · Accepted Answer

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

Autant que je sache, il n’ya aucune astuce pour éviter complètement l’ingénierie inverse.

Et aussi très bien dit par @inazaruk: Quoi que vous fassiez pour votre code, un attaquant potentiel est capable de le changer de quelque façon que ce soit, il le trouve réalisable. En gros, vous ne pouvez pas protéger votre application contre les modifications. Et toute protection que vous mettez là-bas peut être désactivée/supprimée.

2. Comment puis-je protéger toutes les ressources, les ressources et le code source de l'application afin que les pirates ne puissent en aucun cas pirater le fichier APK?

Vous pouvez faire différentes astuces pour rendre le piratage plus difficile. Par exemple, utilisez l’obscurcissement (s’il s’agit de code Java). Cela ralentit généralement l’ingénierie inverse de manière significative.

3. Existe-t-il un moyen de rendre le piratage informatique plus difficile, voire impossible? Que puis-je faire de plus pour protéger le code source de 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 intégré, est ProGuard. Si vous avez la possibilité d'inclure bibliothèques partagées , vous pouvez inclure le code nécessaire en C++ pour vérifier la taille des fichiers, l'intégration, .__, etc. Si vous devez ajouter une bibliothèque native native au dossier de la bibliothèque de votre APK à chaque compilation, vous pouvez l’utiliser à l’aide de la suggestion ci-dessous.

Placez la bibliothèque dans le chemin de la bibliothèque native dont le nom par défaut est "libs" dans le dossier de votre projet. Si vous avez construit le code natif de 'armeabi' target, mettez-le Sous libs/armeabi . S'il a été construit avec armeabi-v7a , placez-le sous libs/armeabi-v7a.

<project>/libs/armeabi/libstuff.so

Raghav Sood · Answer

Autant que je sache, vous ne pouvez pas protéger davantage les fichiers du répertoire/res qu’ils ne le sont actuellement.

Cependant, vous pouvez prendre certaines mesures pour protéger votre code source, ou du moins ce qu’il fait si ce n’est pas tout.

Utilisez des outils tels que ProGuard. Celles-ci obscurciront votre code et rendront la lecture plus difficile une fois décompilée, voire impossible.
Déplacez les parties les plus critiques du service hors de l'application et vers un service Web caché derrière un langage côté serveur tel que PHP. Par exemple, si vous avez un algorithme qui vous a pris un million de dollars pour écrire. De toute évidence, vous ne voulez pas que les gens la volent dans votre application. Déplacez l'algorithme et faites-le traiter les données sur un serveur distant, et utilisez simplement l'application pour lui fournir les données. Ou utilisez le NDK pour les écrire de manière native dans des fichiers .so, qui sont beaucoup moins susceptibles d’être décompilés que les fichiers apks. Je ne pense pas qu'un décompilateur pour les fichiers .so existe même à ce jour (et même si c'était le cas, il ne serait pas aussi bon que les décompilateurs Java). De plus, comme @nikolay l'a mentionné dans les commentaires, vous devez utiliser SSL pour interagir entre le serveur et le périphérique.
Lorsque vous stockez des valeurs sur le périphérique, ne les stockez pas au format brut. Par exemple, si vous avez un jeu et que vous stockez la quantité de monnaie de jeu de l'utilisateur dans SharedPreferences. Supposons que c'est 10000 pièces. Au lieu d'enregistrer directement 10000, enregistrez-le à l'aide d'un algorithme tel que ((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 devrez travailler pour trouver une équation qui ne perdra pas de la monnaie en raison d'erreurs d'arrondis, etc.
Vous pouvez faire la même chose pour les tâches côté serveur. Maintenant, pour un exemple, prenons réellement votre application de traitement de paiement. Disons que l'utilisateur doit effectuer un paiement de $200. Au lieu d’envoyer une valeur $200 brute au serveur, envoyez une série de valeurs plus petites et prédéfinies qui s’ajoutent à $200. Par exemple, disposez sur votre serveur d’un fichier ou d’une table qui associe des mots à des valeurs. Supposons donc que Charlie correspond à $47 et John à $3. Ainsi, au lieu d’envoyer $200, vous pouvez envoyer Charlie quatre fois et John quatre fois. Sur le serveur, interprétez ce qu'ils veulent dire et additionnez-le. Cela empêche un pirate d’envoyer des valeurs arbitraires à votre serveur car il ne sait pas à quoi correspond Word. En guise de mesure de sécurité supplémentaire, vous pouvez également utiliser une équation similaire au point 3 et modifier les mots-clés à chaque n nombre de jours.
Enfin, vous pouvez insérer un code source inutile et aléatoire dans votre application, afin que le pirate informatique recherche une aiguille dans une botte de foin. Insérez des classes aléatoires contenant des extraits d’Internet ou simplement des fonctions permettant de calculer des éléments aléatoires comme la séquence de Fibonacci. Assurez-vous que ces classes sont compilées, mais qu'elles ne sont pas utilisées par les fonctionnalités réelles de l'application. Ajoutez assez de ces fausses classes et le pirate informatique aurait du mal à trouver votre vrai code.

Dans l’ensemble, il n’ya aucun moyen de protéger votre application à 100%. Vous pouvez rendre la tâche plus difficile, mais pas impossible. Votre serveur Web pourrait être compromis, le pirate informatique pourrait déterminer vos mots clés en surveillant le montant de plusieurs transactions et les mots-clés que vous avez envoyés, le pirate informatique pourrait scrupuleusement parcourir la source et déterminer quel code est un mannequin.

Vous ne pouvez que vous battre, mais jamais gagner.

tylerl · Answer

À aucun moment dans l'histoire de l'informatique, il n'a jamais été possible d'empêcher le reverse engineering de logiciels lorsque vous en remettez une copie de travail à votre attaquant. De plus, il est fort probable que cela ne sera jamais possible .

Ceci compris, il existe une solution évidente: ne donnez pas vos secrets à votre attaquant. Vous ne pouvez pas protéger le contenu de votre APK, ce que vous pouvez protéger est tout ce que vous ne distribuez pas. Il s'agit généralement d'un logiciel côté serveur utilisé pour des opérations telles que l'activation, les paiements, l'application de règles et d'autres éléments de code juteux. Vous pouvez protéger des biens de valeur en et non en les distribuant dans votre APK. A la place, configurez un serveur qui répond aux demandes de votre application, "utilise" les actifs (quelle que soit sa signification), puis renvoie le résultat à l'application. Si ce modèle ne fonctionne pas pour les actifs que vous envisagez, vous voudrez peut-être repenser votre stratégie.

En outre, si votre objectif principal est d'empêcher le piratage d'applications : ne vous inquiétez même pas. Vous avez déjà consacré plus de temps et d’argent à ce problème qu’aucune mesure de lutte contre le piratage ne pourrait jamais vous sauver. Le retour sur investissement lié à la résolution de ce problème est tellement faible que même y penser n’a pas de sens.

KeithS · Answer

Première règle de sécurité de l'application: Toute machine à laquelle un attaquant obtient un accès physique ou électronique sans restriction appartient maintenant à votre attaquant, quel que soit son emplacement ou le prix que vous avez payé.

Deuxième règle de sécurité de l'application: Tout logiciel qui laisse les limites physiques à l'intérieur desquelles un attaquant ne peut pénétrer appartient maintenant à votre attaquant, quel que soit le temps que vous avez passé à le coder.

Troisième règle: Toute information laissant ces mêmes limites physiques qu’un attaquant ne peut pas pénétrer appartient maintenant à votre attaquant, quelle que soit sa valeur.

Les fondements de la sécurité des technologies de l’information reposent sur ces trois principes fondamentaux; Le seul ordinateur véritablement sécurisé est celui qui est enfermé dans un coffre-fort, dans une cage de Farraday, dans une cage en acier. Certains ordinateurs passent la majeure partie de leur vie en service dans cet état uniquement; une fois par an (ou moins), ils génèrent les clés privées pour les autorités de certification racine de confiance (devant un hôte de témoins avec des caméras enregistrant chaque pouce de la pièce dans laquelle ils se trouvent).

Maintenant, la plupart des ordinateurs ne sont pas utilisés dans ces types d’environnements; ils sont physiquement à l'air libre, connectés à Internet via un canal radio sans fil. En bref, ils sont vulnérables, tout comme leurs logiciels. Ils ne doivent donc pas faire 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 en faire assez pour causer des dommages (du moins pas des dommages permanents en dehors des limites de cette seule machine ).

Tu savais déjà tout ça; 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 compliqué par un humain, mais le programme doit encore être exécuté. cela signifie que le flux logique réel de l'application et les données qu'elle utilise ne sont pas affectés par l'obscurcissement. Avec un peu de ténacité, un attaquant peut tout simplement masquer le code, ce qui n'est même pas nécessaire dans certains cas où ce qu'il regarde ne peut être autre chose que ce qu'il recherche.

Vous devriez plutôt essayer de vous assurer qu'un attaquant ne peut rien faire avec votre code, même s'il est facile pour lui d'obtenir une copie claire de celui-ci. Cela signifie, pas de secrets codés en dur, car 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 entièrement supprimées du code source de l'application. Au lieu de cela, ils devraient être dans l'un des trois endroits; mémoire volatile sur le périphérique, ce qui est plus difficile (mais pas toujours impossible) à un attaquant pour obtenir une copie hors ligne de; en permanence sur le cluster de serveurs, auquel vous contrôlez l'accès avec un poing de fer; ou dans un deuxième magasin de données non lié à votre appareil ou à vos serveurs, tel qu'une carte physique ou dans la mémoire de votre utilisateur (ce qui signifie qu'il sera éventuellement en mémoire volatile, mais cela ne doit pas nécessairement durer longtemps).

Considérez le schéma suivant. L'utilisateur entre ses informations d'identification pour l'application à partir de la mémoire dans l'appareil. Malheureusement, vous devez avoir l'assurance que le dispositif de l'utilisateur n'est pas déjà compromis par un enregistreur de frappe ou un cheval de Troie. Le mieux que vous puissiez faire à cet égard consiste à mettre en œuvre une sécurité multifactorielle en mémorisant des informations d'identification difficiles à simuler concernant les périphériques utilisés par l'utilisateur (MAC/IP, IMEI, etc.), et en fournissant au moins un canal supplémentaire. lequel une tentative de connexion sur un périphérique inconnu peut être vérifié.

Les informations d'identification, une fois entrées, sont masquées par le logiciel client (à l'aide d'un hachage sécurisé) et les informations d'identification en texte brut sont ignorées. ils ont servi leur but. Les informations d'identification masquées sont envoyées via un canal sécurisé au serveur authentifié par certificat, qui les hache again pour produire les données utilisées pour vérifier la validité de la connexion. De cette manière, le client ne sait jamais ce qui est réellement comparé à la valeur de la base de données, le serveur d'applications ne sait jamais les informations d'identification en texte clair sous-tendant ce qu'il reçoit pour validation, le serveur de données ne sait jamais comment les données qu'il stocke pour validation sont générées le milieu ne voit que du charabia même si le canal sécurisé était compromis.Une fois vérifié, le serveur renvoie un jeton sur le canal. Le jeton n’est utile que dans la session sécurisée, est composé d’un bruit aléatoire ou d’une copie chiffrée (et donc vérifiable) des identificateurs de session, et l’application cliente doit envoyer ce jeton sur le même canal au serveur dans le cadre de toute demande. faire quelque chose. L'application client le fera plusieurs fois, car elle ne peut rien faire avec de l'argent, des données sensibles ou quoi que ce soit qui pourrait être dommageable en soi; il doit plutôt demander au serveur de faire cette tâche. L'application cliente n'écrira jamais d'informations sensibles dans la mémoire persistante du périphérique, du moins pas en texte brut. le client peut demander au serveur via le canal sécurisé une clé symétrique pour chiffrer les données locales, dont le serveur se souviendra; lors d'une session ultérieure, le client peut demander au serveur la même clé pour déchiffrer les données à utiliser dans la mémoire volatile. Ces données ne seront pas la seule copie non plus; tout ce que le client stocke doit également être transmis au serveur sous une forme ou une autre.

Cela rend évidemment votre application très dépendante de l’accès à Internet; le périphérique client ne peut exécuter aucune de ses fonctions de base sans une connexion et une authentification correctes au serveur. Pas différent de Facebook, vraiment.

Désormais, l’ordinateur que l’attaquant veut, c’est votre serveur, car c’est ce qui peut lui rapporter de l’argent ou faire souffrir d’autres personnes pour son plaisir, et non l’application/le périphérique client. C'est bon; vous en avez beaucoup plus pour votre argent, en dépensant de l'argent et en efforts pour sécuriser le serveur qu'en essayant de sécuriser tous les clients. Le serveur peut être placé derrière tous les types de pare-feu et autres systèmes de sécurité électroniques. Il peut également être sécurisé physiquement derrière des accès en acier, en béton, en accès par carte magnétique/par code confidentiel et par une surveillance vidéo 24h/24. Votre attaquant devrait en effet être très sophistiqué pour pouvoir accéder directement au serveur, quel que soit son type, et vous devriez (devriez) le savoir immédiatement.

Le mieux qu’un attaquant puisse faire est de voler le téléphone et les informations d’identité de l’utilisateur, puis de se connecter au serveur avec les droits limités du client. Si cela se produisait, tout comme pour une carte de crédit, l'utilisateur légitime devrait être invité à appeler un numéro 800 (de préférence facile à retenir, et non au verso d'une carte qu'il aurait dans son sac à main, son portefeuille ou son porte-documents volés à côté de l'appareil mobile) depuis n'importe quel téléphone auquel ils peuvent accéder et qui les connecte directement à votre service clientèle. Ils déclarent que leur téléphone a été volé, fournissent un identifiant unique de base, le compte est verrouillé, toutes les transactions que l'attaquant a pu traiter sont annulées et l'attaquant revient à la case départ.

The best an attacker can do is steal a user's phone and credentials and log in to the server with the limited rights of the client. Should this happen, just like losing a credit card, the legitimate user should be instructed to call an 800 number (preferably easy to remember, and not on the back of a card they'd carry in their purse, wallet or briefcase which could be stolen alongside the mobile device) from any phone they can access that connects them directly to your customer service. They state their phone was stolen, provide some basic unique identifier, and the account is locked, any transactions the attacker may have been able to process are rolled back, and the attacker is back to square one.

Azhar Shaikh · Answer

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

Ce n'est pas possible

2. Comment puis-je protéger toutes les ressources, les ressources et le code source de l'application afin que les pirates ne puissent en aucun cas pirater le fichier APK?

Quand quelqu'un change une extension .apk en .Zip, après décompression, quelqu'un peut facilement obtenir toutes les ressources (sauf Manifest.xml), mais avec APKtool , on peut obtenir le réel contenu du fichier manifeste aussi. Encore une fois, un non.

3. Existe-t-il un moyen de rendre le piratage informatique 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 empêcher jusqu'à un certain niveau, c'est-à-dire

Téléchargez une ressource sur le Web et effectuez un processus de cryptage
Utiliser une bibliothèque native pré-compilée (C, C++, JNI, NDK)
Toujours effectuer des opérations de hachage ( MD5 / SHA touches ou toute autre logique)

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

ρяσѕρєя K · Answer

Il n'est pas possible d'éviter totalement l'ingénierie inverse de l'APK Android, mais vous pouvez utiliser ces moyens pour éviter d'extraire plus de données, telles que le code source, les actifs de votre APK et les ressources suivantes:

Utilisez ProGuard pour masquer le code d'application
UtilisezNDKusing C et C++ pour mettre le noyau de votre application et sécuriser une partie du code dans des fichiers .so
Pour sécuriser les ressources, n'incluez pas toutes les ressources importantes dans le dossier des ressources avec APK. Téléchargez ces ressources au moment du premier démarrage de l'application.

Sahil Mahajan Mj · Answer

Les développeurs peuvent prendre les mesures suivantes pour empêcher le vol d’un APK en quelque sorte,

le moyen le plus simple consiste à utiliser des outils tels que ProGuard pour masquer leur code, mais jusqu'à présent, il était assez difficile d'empêcher complètement quelqu'un de décompiler une application.
J'ai aussi entendu parler d'un outil HoseDex2Jar . Il arrête Dex2Jar en insérant du code inoffensif dans un APK Android qui confond et désactive Dex2Jar et protège le code de la décompilation. Cela pourrait en quelque sorte empêcher les pirates de décompiler un fichier APK en code Java lisible.
Utilisez une application côté serveur pour communiquer avec l'application uniquement lorsque cela est nécessaire. Cela pourrait aider à prévenir les données importantes.

Du tout, vous ne pouvez pas protéger complètement votre code des pirates potentiels. En quelque sorte, 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 consiste à écrire en code natif (C/C++) et à le stocker sous forme de bibliothèques compilées.

RobinHood · Answer

1. Comment puis-je éviter complètement l'ingénierie inverse 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 afin que les pirates ne puissent en aucun cas pirater le fichier APK?

Les développeurs peuvent utiliser des outils tels que ProGuard pour masquer leur code, mais jusqu'à présent, il était assez difficile d'empêcher complètement quelqu'un de décompiler une application.

C'est un outil vraiment formidable qui peut augmenter la difficulté "d'inverser" votre code tout en réduisant l'empreinte de votre code.

Prise en charge intégrée de ProGuard: ProGuard est maintenant fourni avec les outils du SDK. Les développeurs peuvent désormais obscurcir leur code en tant que partie intégrante d'une version validée.

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

Lors de mes recherches, j'ai appris à connaître HoseDex2Jar . Cet outil protégera votre code de la décompilation, mais il ne semble pas possible de protéger complètement votre code.

Certains des liens utiles, vous pouvez vous y référer.

Shan · Answer

Voici quelques méthodes que vous pouvez essayer:

Utilisez obfuscation et des outils tels que ProGuard .
Crypter une partie de la source et des données.
Utilisez une somme de contrôle incorporée exclusive dans l'application pour détecter la falsification.
Introduisez du code pour éviter le chargement dans un débogueur, c’est-à-dire que l’application aura la possibilité de détecter le débogueur et de le quitter/le tuer.
Séparez l'authentification en tant que service en ligne.
Utilisation diversité des applications
Utilisez la technique d'empreinte digitale, par exemple, pour les signatures matérielles des périphériques de différents sous-systèmes avant l'authentification du périphérique.

Abhishek Sabbarwal · Answer

La principale question ici est que les fichiers dex peuvent être décompilé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é, obscurcira votre code. DexGuard, qui est une version commerciale étendue de ProGuard, pourrait aider un peu plus. Cependant, votre code peut toujours être converti en smali et les développeurs ayant une expérience en reverse engineering seront en mesure de comprendre ce que vous faites à partir de smali.

Peut-être choisir une bonne licence et la faire respecter par la loi de la meilleure façon possible.

janot · Answer

1. Comment puis-je éviter complètement l'ingénierie inverse 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 afin que les pirates ne puissent en aucun cas pirater le fichier APK?

Impossible

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

Plus difficile - possible, mais en réalité, ce sera plus difficile pour l'utilisateur moyen, qui recherche simplement des guides de piratage. Si quelqu'un veut vraiment pirater votre application, celle-ci le sera tôt ou tard.

straya · Answer

Votre client devrait embaucher quelqu'un qui sait ce qu'il fait, qui peut prendre les bonnes décisions et qui peut vous encadrer.

Il est absurde de parler de votre capacité à modifier le système de traitement des transactions sur le backend - vous ne devriez pas être autorisé à faire de tels changements architecturaux, alors ne vous attendez pas à pouvoir le faire.

Mon raisonnement à ce sujet:

Étant donné que votre domaine est le traitement des paiements, il est raisonnable de supposer que les normes PCI DSS et/ou PA DSS (et les lois fédérales/nationales potentielles) auront une incidence significative sur votre entreprise. Pour être conforme, vous devez montrer que vous êtes garantir. Pour être sûr de votre sécurité, découvrez ensuite (via des tests) que vous n'êtes pas sécurisé, puis corrigez-le, testez à nouveau, etc. jusqu'à ce que la sécurité soit vérifiée à un niveau approprié = coût élevé, lent, risque élevé. Pour faire le bon choix, réfléchir sérieusement, engager des talents expérimentés, développer de manière sécurisée, puis tester, réparer (moins), etc. (moins) jusqu'à ce que la sécurité puisse être vérifiée à un niveau approprié = peu coûteux, rapide, moyen à faible risque de succès.

Itai Sagi · Answer

En tant que personne qui a beaucoup travaillé sur les plateformes de paiement, y compris une application de paiement mobile (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) ne doit être enregistré ou sauvegardé. codé en dur dans l'application mobile, c'est la dernière chose que vous voulez, parce que la source peut être comprise même lorsque vous obscurcissez le code.

En outre, vous ne devriez pas stocker de cartes de crédit ou de jetons de paiement sur l'application, tout devrait être, là encore, délégué à un service que vous avez créé, il vous permettra également, plus tard, de se conformer à la norme PCI et aux sociétés de cartes de crédit gagnées. ne souffle pas dans ton cou (comme ils l’ont fait pour nous).

Kaz · Answer

Si nous voulons rendre (presque) impossible l’ingénierie inverse, nous pouvons placer l’application sur une puce hautement inviolable, qui exécute tous les éléments sensibles en interne et communique avec un protocole permettant de contrôler l’interface graphique sur l’hôte. Même les puces inviolables ne résistent pas à 100% aux fissures; ils ont juste placé la barre beaucoup plus haute que les méthodes logicielles. Bien sûr, cela n’est pas pratique: l’application nécessite une petite verrue USB qui maintient la puce à insérer dans l’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 moyen de paiement en dissimulant les failles de sécurité éventuelles (connues ou non) de l’application, il est totalement erroné. Les éléments sensibles à la sécurité doivent en fait être à source ouverte, si cela est réalisable. Vous devez simplifier au maximum la tâche de tout chercheur en sécurité qui examine votre application pour trouver ces éléments, examine leur fonctionnement et vous contacte. Les applications de paiement ne doivent contenir aucun certificat intégré. C'est-à-dire qu'il ne devrait y avoir aucune application serveur qui fait confiance à un périphérique simplement parce qu'il possède un certificat fixe d'usine. Une transaction de paiement doit être effectuée uniquement sur les informations d'identification de l'utilisateur, à l'aide d'un protocole d'authentification de bout en bout correctement conçu, empêchant de faire confiance à l'application, à la plate-forme, au réseau, etc.

Si l'objectif est d'empêcher le clonage, hormis cette puce inviolable, vous ne pouvez rien faire pour empêcher le programme d'être inversé et copié, de sorte que quelqu'un incorpore un mode de paiement compatible dans sa propre application, en donnant monter à "clients non autorisés". Il existe des moyens de rendre difficile le développement de clients non autorisés. L'une serait de créer des sommes de contrôle basées sur des instantanés de l'état complet du programme: toutes les variables d'état, pour tout. Interface graphique, logique, peu importe. Un programme de clonage n'aura pas exactement le même état interne. Bien sûr, il s'agit d'une machine à états qui présente des transitions d'état similaires visibles de l'extérieur (comme on peut l'observer par les entrées et les sorties), mais à peine le même état interne. Une application serveur peut interroger le programme: quel est votre état détaillé? (c’est-à-dire donnez-moi une somme de contrôle sur toutes vos variables d’état internes). Ceci peut être comparé au code client factice qui s'exécute sur le serveur en parallèle, en passant par les transitions d'état authentiques. Un clone tiers devra répliquer tous les changements d’état pertinents du programme authentique afin de donner les réponses correctes, ce qui entravera son développement.

Sarel Botha · Answer

Les autres réponses positives ici 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 semblera que cela fonctionne dans votre application.

Talha · Answer

Je vous suggère de regarder Protégez les applications logicielles contre les attaques . C'est un service commercial, mais la société de mon ami l'a utilisé et il est heureux de l'utiliser.

thiagolr · Answer

Schéma de signature APK v2 sous Android N

La classe PackageManager prend désormais en charge la vérification des applications à l'aide du 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 conserver la compatibilité ascendante, un fichier APK doit être signé avec le schéma de signature v1 (schéma de signature JAR) avant d'être signé avec le schéma de signature v2. 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.

La prise en charge du schéma de signature APK v2 sera disponible ultérieurement dans la N Developer Preview.

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

Sanket Prabhu · Answer

Il n'est pas possible d'éviter complètement les ER, mais en les rendant plus complexes en interne, il est 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 peuvent augmenter la complexité du reverse engineering de votre code. Une technique consiste à utiliser C/C++ pour limiter les manipulations d'exécution faciles par l'attaquant. Il existe de nombreuses bibliothèques C et C++ très matures et faciles à intégrer aux offres Android JNI. Un attaquant doit d'abord contourner les restrictions de débogage afin d'attaquer l'application à un niveau bas. Cela ajoute une complexité supplémentaire à une attaque. Les applications Android doivent avoir Android: debuggable = "false" défini dans le manifeste de l'application pour empêcher toute manipulation aisée par un attaquant ou un logiciel malveillant au moment de l'exécution.

Vérification des traces - Une application peut déterminer si elle est actuellement suivie par un débogueur ou un autre outil de débogage. Si elle est suivie, l’application peut exécuter un nombre illimité d’actions de réponse aux attaques, telles que la suppression des clés de cryptage pour protéger les données de l’utilisateur, la notification à un administrateur de serveur ou d’autres types de réponses de ce type pour se défendre. Cela peut être déterminé en vérifiant les indicateurs d'état du processus ou en utilisant d'autres techniques telles que la comparaison de la valeur de retour de ptrace attach, la vérification du processus parent, les débogueurs de liste noire dans la liste des processus ou la comparaison des horodatages à différents endroits du programme.

Optimisations - Pour masquer les calculs mathématiques avancés et d’autres types de logique complexe, l’optimisation du compilateur peut aider obfuscate le code de l’objet de sorte qu’il ne puisse pas facilement être désassemblé par un attaquant, ce qui le rend plus difficile à comprendre le code en question. Sous Android, cela peut être plus facilement réalisé en utilisant des bibliothèques natives compilées avec le NDK. De plus, l’utilisation d’un obfuscateur LLVM ou de tout SDK protecteur offrira une meilleure obfuscation du code machine.

Suppression des fichiers binaires - La suppression des fichiers 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 supprimant un binaire, la table des symboles du binaire est supprimée, de sorte qu'un attaquant ne peut pas facilement déboguer ou désosser une application. Vous pouvez faire référence à des techniques utilisées sur des systèmes GNU/Linux telles que sstriping ou utilisant UPX.

Et enfin, vous devez être conscient de l'obfuscation et des outils comme ProGuard.

Zennichimaro · Answer

Convenu avec @Muhammad Saqib ici: https://stackoverflow.com/a/46183706/2496464

Et @Mumair donne un bon point de départ: https://stackoverflow.com/a/35411378/474330

Il est toujours prudent de supposer que tout ce que vous distribuez sur le périphérique de votre utilisateur appartient à l'utilisateur. Clair et simple. Vous pourrez peut-être utiliser les derniers outils et procédures pour chiffrer vos propriétés intellectuelles, mais il n’ya 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 leur accès indésirable, il y aura peut-être un moyen facile demain, ou même juste la prochaine heure!

Ainsi, voici l'équation:

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

Même dans une économie aussi simple que celle du jeu. (Surtout dans les jeux! Il y a plus d'utilisateurs "sophistiqués" et des échappatoires se propagent en quelques secondes!)

Comment rester en sécurité?

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

immutable · Answer

Il n'y a aucun moyen d'éviter complètement l'ingénierie inverse d'un APK. Pour protéger les actifs des applications, les ressources, vous pouvez utiliser le cryptage.

Le chiffrement rendra son utilisation plus difficile sans déchiffrement. Choisir un algorithme de chiffrement fort rendra la répression plus difficile.
Ajouter du code d'usurpation dans votre logique principale pour rendre plus difficile la résolution des problèmes.
Si vous pouvez écrire votre logique critique dans n’importe quelle langue maternelle et que cela rendra certainement plus difficile la décompilation.
Utilisation de structures de sécurité tierces telles que Quixxi

Earlz · Answer

En gros ce n'est pas possible. Ce ne sera jamais possible. Cependant, il y a de l'espoir. Vous pouvez utiliser un obfuscator pour rendre certaines attaques courantes beaucoup plus difficiles à réaliser, notamment:

Renommer des méthodes/classes (ainsi dans le décompilateur vous obtenez des types comme a.a)
Obscurcissement du flux de contrôle (dans le décompilateur, le code est donc très difficile à lire)
Crypter des chaînes et éventuellement des ressources

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

L'obfuscation a toujours un prix, cependant. En particulier, les performances sont généralement moins bonnes et nécessitent généralement un peu plus de temps autour des versions. 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 simplement par un serveur hébergeant toute la logique de votre application. Cela a son lot de problèmes, car cela signifie que les utilisateurs doivent être connectés à Internet pour utiliser votre application.

En outre, ce n'est pas seulement Android qui a ce problème. C'est un problème sur chaque app store. Cela dépend simplement de la difficulté d'accéder au fichier de paquet (par exemple, je ne crois pas que ce soit très facile sur iPhone, mais c'est toujours possible).

robUx4 · Answer

Les puces TPM (Trusted Platform Module) ne sont-elles pas supposées gérer le code protégé pour vous? Ils deviennent courants sur les PC (en particulier ceux d’Apple) et existent peut-être déjà dans les puces de smartphone. Malheureusement, il n’existe pas encore d’API de système d’exploitation. Espérons que Android ajoutera un support pour cette journée. C'est également la clé pour nettoyer le contenu DRM (sur lequel Google travaille pour WebM).

mumair · Answer

Rien n’est sécurisé lorsque vous le mettez à la main des utilisateurs finaux, mais certaines pratiques courantes peuvent rendre la tâche plus difficile aux attaquants pour voler des données.

Mettez votre logique principale (algorithmes) côté serveur.
Communiquer avec le serveur et le client; assurez-vous que la communication serveur/client n/b est sécurisée via SSL ou HTTPS; ou utilisez d'autres techniques d'algorithmes de génération de paires de clés (ECC, RSA). Assurez-vous que les informations sensibles restent chiffrées de bout en bout.
Utilisez des sessions et expirez-les après un intervalle de temps spécifique.
Cryptez les ressources et récupérez-les du serveur à la demande.
Ou vous pouvez créer une application hybride qui accède au système via webview protéger la ressource + le code sur le serveur

Approches multiples; il est évident que vous devez sacrifier entre performance et sécurité

Muhammad Saqib · Answer

Si votre application est aussi sensible, vous devriez envisager la partie relative au traitement des paiements côté serveur. Essayez de changer vos algorithmes de traitement des paiements. Utilisez l'application Android uniquement pour collecter et afficher les informations de l'utilisateur (solde du compte) et, au lieu de traiter des paiements au moyen de codes Java, envoyez cette tâche à votre serveur à l'aide d'un protocole SSL sécurisé avec des paramètres cryptés. Créez une API entièrement cryptée et sécurisée pour communiquer avec votre serveur.

Bien sûr, il peut également être piraté et cela n'a rien à voir avec la protection des codes source, mais considérez-le comme une couche de sécurité supplémentaire pour empêcher les pirates informatiques de duper votre application.

Jeegar Patel · Answer

Comment protéger toutes les ressources, les ressources et le code source de l'application afin que les pirates ne puissent en aucun cas pirater le fichier APK?

Un fichier APK est protégé avec l'algorithme SHA-1 . Vous pouvez voir certains fichiers dans le dossier META-INF de APK. Si vous extrayez un fichier APK et modifiez son contenu, que vous le zippez à nouveau et que vous exécutez ce nouveau fichier APK sur une machine Android, cela ne fonctionnera pas car les hachages SHA-1 ne correspondront jamais.

Godfrey Nolan · Answer

Bien que je sois d’accord qu’il n’ya pas de solution à 100% pour protéger votre code, la v3 de HoseDex2Jar est maintenant disponible si vous voulez essayer.

Rajiv Ranjan · Answer

La sécurité à 100% du code source et des ressources n'est pas possible sous Android. Mais, vous pouvez faire un peu difficile pour l'ingénieur de reverse. Vous pouvez trouver plus de détails à ce sujet dans les liens ci-dessous:

Visiter Sauvegarder des valeurs constantes en toute sécurité et https://www.agicent.com/blog/mobile-app-security-best-practices/

user3742860 · Answer

quand ils ont l'application sur leur téléphone, ils ont un accès complet à la mémoire de celle-ci. Donc, si vous voulez empêcher le piratage, vous pouvez essayer de le faire de sorte que vous ne puissiez pas obtenir l'adresse de mémoire statique directement à l'aide d'un débogueur. ils pourraient provoquer un débordement de tampon de pile s’ils ont un endroit où écrire et qu’ils ont une limite. essayez donc de faire en sorte qu’ils écrivent quelque chose, s’ils doivent avoir une limite, s’ils envoient plus de caractères que la limite, si (entrée> limite) puis ignore, ils ne peuvent donc pas y insérer de code Assembly.

Mayank Nema · Answer

Outil: L'utilisation de Proguard dans votre application permet de limiter le reverse engineering de votre application

Asthme · Answer

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