Comment Apple sait-il que vous utilisez une API privée?

J'ai soumis un fichier binaire à Apple sans aucun code source.

Outre la vérification manuelle du code source, comment Apple sait-il ce qui a été utilisé et quelles API vous avez appelées?

Il y a 3 façons dont je sais. Ce ne sont que des spéculations, car je ne travaille pas dans l'équipe d'examen Apple.

1. otool -L

Cela répertorie toutes les bibliothèques auxquelles l'application est liée. Quelque chose de clair que vous ne devriez pas utiliser, comme IOKit et WebKit peut être détecté par cela.

2. nm -u

Cela listera tous les symboles liés. Cela peut détecter

• Fonctions C non documentées telles que _UIImageWithName;
• Classes Objective-C telles que UIProgressHUD
• Ivars tels que UITouch._phase(qui pourraient être la cause du rejet des applications basées sur Three20 ces derniers mois.)

3. Liste des sélecteurs Objective-C, ou strings

Les sélecteurs Objective-C sont stockés dans une région spéciale du binaire, et par conséquent Apple pourrait en extraire le contenu et vérifier si vous avez utilisé des méthodes Objective-C non documentées, telles que -[UIDevice setOrientation:].

Étant donné que les sélecteurs sont indépendants de la classe que vous envoyez, même si votre classe personnalisée définit comme -setOrientation:non pertinent pour UIDevice, il y aura une possibilité d'être rejeté.

Vous pouvez utiliser l'APIKit d'Erica Sadun pour détecter un rejet potentiel en raison de (fausses alarmes de) API privées.

(Si vous voulez vraiment vraiment contourner ces vérifications, vous pouvez utiliser des fonctionnalités d'exécution telles que

• dlopen, dlsym
• objc_getClass, sel_registerName, objc_msgSend
• -valueForKey:; object_getInstanceVariable, object_getIvar, etc.

pour obtenir ces bibliothèques privées, classes, méthodes et ivars. )

Vous pouvez lister les sélecteurs dans un programme Mach-O en utilisant le one-liner suivant dans Terminal:

otool -s __TEXT __objc_methname "$1" |expand -8 | cut -c17- | sed -n '3,$p' | perl -n -e 'print join("\n",split(/\x00/,scalar reverse (reverse unpack("(a4)*",pack("(H8)*",split(/\s/,$_))))))'

Supposons que vous souhaitiez utiliser une API privée; l'objectif C vous permet de construire n'importe quel SEL à partir d'une chaîne:

   SEL my_sel = NSSelectorFromString([NSString stringWithFormat:\
@"%@%@%@", "se","tOr","ientation:"]);
    [UIDevice performSelector:my_sel ...];

Comment un robot ou un scanner de bibliothèque pourrait-il détecter cela? Ils devraient attraper cela en utilisant un outil qui surveille les accès privés au moment de l'exécution. Même s'ils ont construit un tel outil d'exécution, il est difficile de l'attraper car cet appel peut être caché dans un chemin rarement utilisé.

J'imagine qu'ils regardent tous les symboles que votre binaire essaie d'importer (info sans doute facilement disponibles pour eux dans la table des symboles) et vous ding si l'un de ces symboles se trouve dans leur "liste API privée". Assez facile à automatiser, en fait.

Un exécutable n'est pas exactement une boîte noire. Si vous appelez une bibliothèque, c'est une chose facile à trouver. C'est pourquoi je déplore la perte des langages d'assemblage dans les formations CS modernes. =] Des outils comme ldd vous diront ce que vous avez lié, bien que je ne me souvienne pas de quelle incarnation de ldd a été intégrée au kit de développement Mac iPhone.

otool -L somebinary

en dehors de l'enquête sur les symboles ...

apple pourrait très facilement avoir une version du sdk qui vérifie chacune des piles de méthodes privées lorsqu'elle est appelée pour s'assurer qu'elle est entrée à partir de l'une des méthodes désignées.

Même si vous liez statiquement, au pire, ils pourraient prendre des échantillons du code des API privées de leur liste et rechercher votre binaire contre eux (également relativement facile à automatiser).

Connaissant Apple, je parierais qu'ils ont un système complet et automatisé, et toute incertitude est probablement soit niée, soit revue manuellement.

En fin de compte, je pense que cela ne vaut probablement pas la peine d'essayer de tromper Apple.

Cette application de bureau, App Scanner , peut analyser les fichiers .app pour une utilisation privée de l'API en séparant le fichier binaire Mach-O. Si c'est possible, Apple le peut aussi!

Il existe de nombreux outils de rétro-ingénierie qui permettent d'inspecter un code

• nm - répertorie les symboles des fichiers objets
• objdump - afficher les informations des fichiers objets.
• otool- afficher le contenu des exécutables Mach-O ^[About]
• strings - cela vous donnera toutes les cordes.

Vous pouvez trouver des exemples / représentation de l'utilisation de ces commandes dans gists pour Objective-C et Swift