web-dev-qa-db-fra.com

Obfuscation de code d'application iPhone / iPad - est-ce possible? Ça vaut le coup?

J'ai fait beaucoup de recherches, à la fois sur SO, ainsi que sur Google partout, mais je n'arrive pas à trouver une réponse simple en ce qui concerne l'obfuscation de code pour les applications iPhone/iPad écrites en Objective-C .

Mes questions sont les suivantes:

  1. Y a-t-il un moyen de le faire? Si c'est le cas, comment?
  2. Est-ce que ça vaut le coup?
  3. Apple le permet-il, ou a-t-il un problème avec lui, lorsque l'application leur est soumise?
iphoneipadobfuscationstore
66
bpatrick100

Il ne semble pas y avoir d'obscurcisseur de code pour Objective-C. Mais supposons un instant qu'il existe.

Apple ne rejettera probablement pas une application masquée tant qu'elle ne plante pas. La question principale est: quel est l'intérêt de l'obscurcissement? Normalement, vous voulez brouiller le code pour protéger vos connaissances, par exemple si votre programme utilise une 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 capable de le décompiler.

La protection contre la copie est déjà prise en charge sur iOS. Bien que grâce au jailbreak, une application normale puisse être copiée et exécutée, je dirais que le nombre réel d'utilisateurs qui le font est assez faible (au moins beaucoup plus bas que sur des ordinateurs "ordinaires" comme PC et Mac). Pensez-vous que le piratage est un si gros problème que vous devez masquer?

Si vous avez des connaissances importantes à protéger, l'obscurcissement peut valoir la peine. L'obfuscation a ses inconvénients: vous ne pouvez plus déboguer votre application obscurcie. Les rapports de plantage seront inutiles.

Vous pouvez également lire l'article Obfuscating Cocoa .

Retour au fait qu'il ne semble pas y avoir d'obscurcisseur: ce que vous pouvez faire est cette astuce: disons que vous avez un en-tête comme celui-ci:

@interface MyClass : NSObject {
}

- (void)myMethod;

Vous pouvez faire un brouillage 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 le transformerait en "ordure" lorsqu'il ne compile pas pour le débogage.

58
DarkDust
  1. Oui, vous pouvez jeter un œil à EnsureIT pour Apple iOS ou Contaxiom Code Protection
  2. Ça dépend. La sécurité introduit normalement de la complexité, vous devez l'équilibre entre la convivialité.
  3. Apple ne devrait pas avoir de problème avec cela (corrigez-moi si je me trompe), et j'ai personnellement quelques applications qui utilisent l'obfuscateur de code.
33
Andy

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. Metaforic,
  3. Cryptanium

Ils varient en capacités et comprennent: -

  1. Contrôler l'obfuscation du flux, par ex. ARM les flux d'instructions sont mutilés avec des instructions redondantes pour essayer de masquer l'objectif initial du code,
  2. Renommage de classe et de méthode - renommez vos méthodes et classes en noms dénués de sens, bien que vous deviez faire attention où cela est utilisé car vous pouvez facilement casser votre application car 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 du code est inséré pour décrypter les chaînes juste avant l'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-falsification - construit généralement un réseau de sommes de contrôle qui protègent le code binaire des modifications,
  6. Protection runtime Objective-C - vérifie généralement les implémentations de méthodes enregistrées obj-c pour s'assurer qu'elles sont dans l'application et n'ont pas été "accélérées".

Tous ces outils sont très chers et non sans problèmes, vous avez donc vraiment besoin d'une application qui nécessite un haut degré d'intégrité pour les prendre en compte, par exemple. bancaire ou où le DRM est très important.

Pour ces types d'applications, vous aurez également besoin de testeurs de pénétration qualifiés pour vous assurer que votre application n'est pas exposée d'autres manières, car ces outils sont souvent aussi bons que ceux qui les utilisent et il existe encore d'autres vulnérabilités du système d'exploitation qui devront atténuer le fait que les outils ne vous adressez pas.

13
Andrew

L'exécutable d'une application est déjà crypté par Apple et le segment de code exécutable du sandbox de l'application n'est pas accessible en écriture, vous ne pouvez donc pas effectuer de cryptage supplémentaire qui nécessite une modification du code d'armement d'exécution. Et la passe d'optimisation du compilateur Objective C/C crée déjà quelque chose de très différent du code source d'origine. Utiliser plus de C et moins d'Objective C révélera moins de vos noms de fonction, car les noms de méthode sont intégrés dans du texte brut visible, mais pas les noms de fonction C. Donc, tout code de type secret commercial devrait probablement être codé en C simple et compilé avec l'optimiseur complètement tourné vers le haut. Vous pouvez obscurcir tout Javascript WebKit intégré dans le bundle d'application, ou tout autre code VM VM intégré (tant que le code interprété n'est pas téléchargé).

3
hotpaw2