Obfuscation du code des applications iPhone/iPad - Est-ce possible ? Cela en vaut-il la peine ?

Question

J'ai fait pas mal de recherches, à la fois sur SO et sur Google, mais je n'arrive pas à trouver une réponse directe concernant l'obscurcissement du code pour les applications iPhone/iPad écrites en Objective-C.

Mes questions sont les suivantes :

1. Existe-t-il un moyen de le faire ? Si oui, comment ?
2. Cela en vaut-il la peine ?
3. Apple l'autorise-t-il, ou y voit-il un problème, lorsque l'application lui est soumise ?

Answer 1

Il ne semble pas exister d'obfuscateur de code pour Objective-C. Mais supposons un instant qu'il en existe un.

Apple ne rejettera probablement pas une application obfusquée tant qu'elle ne plante pas. La question principale est : quel est le but de l'obfuscation ? Par exemple, si votre programme utilise un système de protection contre la copie, vous voulez le rendre plus difficile pour un pirate potentiel ou si vous utilisez un algorithme avancé, vous ne voulez pas que les concurrents commerciaux soient capables de le décompiler.

La protection contre la copie est déjà prise en charge sur iOS. Bien que le jailbreak permette de copier et d'exécuter une application normale, je dirais que le nombre réel d'utilisateurs qui le font est assez faible (en tout cas beaucoup plus faible que sur les ordinateurs "ordinaires" comme les PC et les Mac). Pensez-vous que le piratage soit un problème si important que vous ayez besoin de l'occulter ?

Si vous avez des connaissances importantes à protéger, l'obscurcissement peut être utile. L'obfuscation a ses inconvénients : vous ne pouvez plus déboguer votre application obfusquée. Les rapports de crash seront inutiles.

Vous pouvez également lire l'article Obfuscating Cocoa .

Revenons au fait qu'il ne semble pas y avoir d'obfuscateur : Ce que vous peut est cette astuce : disons que vous avez un en-tête comme celui-ci :

@interface MyClass : NSObject {
}

- (void)myMethod;

Vous pourriez faire un obscurcissement bon marché comme celui-ci :

#ifndef DEBUG
#define MyClass aqwe
#define myMethod oikl
#endif

@interface MyClass : NSObject {
}

- (void)myMethod;

De cette façon, vous pouvez toujours utiliser des symboles significatifs dans votre source, mais le compilateur les transforme en "déchets" lorsqu'il ne compile pas pour le débogage.

Answer 2

1. Oui, vous pouvez jeter un coup d'oeil à EnsureIT pour Apple iOS ou Protection du code Contaxiom
2. Cela dépend. La sécurité introduit normalement de la complexité, vous devez l'équilibrer avec la facilité d'utilisation.
3. Apple ne devrait pas avoir de problème avec cela. (Corrigez-moi si je me trompe)

Answer 3

Suite aux réponses précédentes, il existe maintenant plusieurs outils tiers qui offrent un certain degré d'obscurcissement et de protection de l'intégrité, notamment :-.

1. Arxan,
2. Métaforique,
3. Cryptanium

Leurs capacités varient et comprennent :-

1. Obfuscation du flux de contrôle : par exemple, les flux d'instructions ARM sont altérés par des instructions redondantes pour tenter de dissimuler l'objectif initial du code,
2. Renommage des classes et des méthodes - renomme vos méthodes et vos classes en noms insignifiants, mais il faut faire attention à l'endroit où cette fonction est utilisée car vous pouvez facilement casser votre application parce que le runtime Objective-C s'attend à trouver certains noms,
3. Cryptage des chaînes - toutes les chaînes statiques de l'application sont cryptées et un code est inséré pour décrypter les chaînes juste avant leur utilisation afin de rendre l'analyse statique plus difficile.
4. Anti-débogage - du code est inséré pour casser les débogueurs habituels (pas toujours avec succès),
5. Anti-tamper - construit généralement un réseau de sommes de contrôle qui protège le code binaire contre toute modification,
6. Protection de l'exécution d'Objective-C - vérifie généralement les implémentations des méthodes enregistrées dans Objective-C pour s'assurer qu'elles sont bien présentes dans l'application et qu'elles n'ont pas été "écrasées".

Tous ces outils sont très coûteux et ne sont pas sans poser de problèmes. Il faut donc une application qui exige un haut degré d'intégrité pour les envisager, par exemple dans le secteur bancaire ou lorsque la gestion des droits numériques est très importante.

Pour ces types d'applications, vous aurez également besoin de testeurs d'intrusion compétents pour vous assurer que votre application n'est pas exposée à d'autres risques. En effet, la qualité de ces outils dépend souvent de celle des personnes qui les utilisent et il existe toujours d'autres vulnérabilités du système d'exploitation qui doivent être atténuées et que les outils ne traitent pas.

Answer 4

L'exécutable d'une application est déjà crypté par Apple, et le segment de code exécutable de la sandbox de l'application n'est pas accessible en écriture, de sorte que vous ne pouvez pas effectuer de cryptage supplémentaire. Et le passage de l'optimiseur du compilateur Objective C/C crée déjà quelque chose de très différent du code source original. En utilisant plus de C et moins d'Objective C, vous révèlerez moins vos noms de fonctions, car les noms de méthodes sont intégrés dans le texte en clair visible, mais pas les noms de fonctions C. Ainsi, tout code de type secret commercial devrait probablement être codé en C brut, et compilé avec l'optimiseur à fond. Vous pourriez obscurcir le Javascript de votre UIWebView intégré dans le bundle de l'application, je suppose.

Answer 5

Probablement pas, car Objective-C compile en instructions processeur plutôt que d'être interprété ou compilé en byte code, donc la décompilation du code produira déjà des résultats assez obscurs. L'obscurcissement n'est généralement nécessaire que lorsque vous devez distribuer la source de votre code, comme dans les langages interprétés tels que JavaScript, pour qu'il puisse s'exécuter, même si vous souhaitez que le code reste secret.