Les achats "In App" sur iPhone et leurs implications sur le piratage

I

l y a un certain temps déjà, Sid m'a demandé si je serais d'accord d'écrire un article invité pour son blog. Bien qu'intéressé, je ne savais pas trop quoi écrire qui soit à la fois intéressant et non soumis à la confidentialité.

À l'époque, j'étais responsable d'une équipe technique de lutte contre le piratage de la télévision à péage, pour des opérateurs comme CanalSat. Aujourd'hui, je me suis mis temporairement au développement de jeux sur iPhone, un rêve de gamin qui se réalise en quelque sorte. J'ai à ce jour développé le jeu de gestion de trafic AutoTrafego.

Comme beaucoup d'entre vous le savent sûrement, les développeurs iPhone sont confrontés à des sérieux problèmes de piratage dont Apple peine à s'occuper. J'ai eu l'occasion d'écrire un article et un billet à ce sujet en Anglais, dont je vais synthétiser le contenu ici d'une façon moins ciblée vers les connaisseurs du développement sur iPhone.

Commençons par expliquer en bref le DRM et la déprotection des applications iPhone. Les applications sont chiffrées et signées et le "bundle" contient un fichier de metadata comportant des informations sur la transaction d'achat. La plupart des applications peuvent être crackées par le commun des kiddies en un click avec un iPhone jailbreaké et un simple script shell ou application spécifique facile à obtenir. Plus techniquement, le script place un breakpoint au point d'entrée de l'application (avec gdb) et dump ensuite le contenu en clair depuis la mémoire de l'appareil. Quelques autres modifications sont apportées au "bundle" afin que l'OS accepte d'exécuter l'application non-chiffrée et non signée.

Le SDK de Apple ne fournit malheureusement aucune API qui permettrait aux développeurs de vérifier si leurs applications ont été piratées. Heureusement, plusieurs techniques ont été découvertes. Il est par exemple possible de vérifier si l'exécutable est chiffré, ou si le fichier metadata de transaction est présent et de prendre des mesures dans le cas contraire. Bien sûr, comme dans le monde du PC (ou Mac), les crackers peuvent désassembler le code et patcher ces protections.

Pour les applications PC et iPhone hors ligne (ne nécessitant pas de connexion à un serveur spécifique du développeur), les exemplaires piratés sont potentiellement du revenu perdu mais dans tous les cas ne coûtent pas d'argent au producteur. Il existe par contre une différence très notable entre le PC et l'iPhone concernant les applications en ligne. En effet, la plupart des applications ou services en ligne pour PC nécessitent un code de licence fourni lors de l'achat ou un abonnement lié à une carte de crédit (comme pour World of Warcraft par exemple). Ces services ne peuvent en principe pas être piratés.

La situation est totalement différente sur iPhone. En effet, les développeurs d'applications en ligne, une fois leurs protections crackées, n'ont aucun moyen de vérifier si les utilisateurs sont des pirates ou non. De ce fait, produire des applications en ligne pour iPhone n'est de loin pas une solution au piratage. Au contraire, en tenant compte que le piratage peut atteindre un taux de 90%, et que les applications sur iPhone sont en général bon marché, le piratage des applications en ligne peut coûter très cher aux développeurs (bande passante, serveurs, maintenance, etc.).

Après tout ce blabla d'introduction, j'en arrive enfin au point qui m'a fait écrire cet article :-D

Apple à récemment publié une API permettant les "In App Purchase" (IAP), c'est-à-dire les achats par micro-transaction à l'intérieur d'une application. Ce qui m'a fait bondir, c'est cette remarque dans le communiqué de presse d'Apple : "L'utilisation des In App Purchase peut vous aider à combattre certains problèmes de piratage". Je suis très loin d'être convaincu, mais on verra si le futur me donne raison.

Une chose est vraie : les applications en ligne peuvent désormais vérifier de façon sûre les transactions d'achat IAP et ainsi éviter une bonne partie du piratage dans ce cas de figure. Mais plusieurs problèmes subsistent. Premièrement, cela ne résoud en aucun cas le problème des applications qui n'utilisent pas les IAP. Deuxièmement, sur iPhone, un achat n'est jamais lié à un appareil particulier, mais à un compte particulier. Je peux en effet utiliser un jeu que j'ai acheté sans problème sur mon iPod et mes deux iPhones. L'API ne semble pas du tout offrir de moyen pour vérifier qu'une transaction d'achat (exécutée avec une carte de crédit volée par exemple) n'est pas simplement loguée, puis distribuée sur Internet et utilisée par des centaines de pirates.

Pour les applications hors ligne, je suis même d'avis que les IAP pourraient faciliter le piratage et ce pour plusieurs raisons. Tout d'abord, l'API ne contient aucun moyen cryptographique pour vérifier les transactions ; elle offre juste une fonction de vérification qui retourne comme résultat si la transaction passée en paramètre est valide. Et comme sur iPhone il est très facile de hooker une fonction, je doute qu'il faille longtemps avant qu'un outil pirate se charge de modifier l'API pour toujours retourner que les transactions ont réussi et sont valides. Ensuite, l'API ne dit pas comment les développeurs doivent sauvegarder la liste des achats effectués (par exemple, le fait que j'ai acheté "l'épée de la mort qui tue"). Un programmeur naïf pourrait simplement stocker l'information dans un fichier de configuration facilement éditable par un pirate.

En conclusion, bien que je n'aie pas pu tester toutes mes hypothèses, je pense que les promesses d'Apple sur la sécurité des In App Purchase sont largement exagérées.

Reversity