Un tutoriel pour inverser l'ingénierie de l'API privée de votre logiciel : pirater votre canapé

Voyager est ma passion et je suis un grand fan de Couchsurfing. Couchsurfing est une communauté mondiale de voyageurs, où vous pouvez trouver un logement ou partager votre propre maison avec d'autres voyageurs. En plus de cela, Couchsurfing vous aide à vivre une véritable expérience de voyage tout en interagissant avec les habitants. Je suis impliqué dans la communauté Couchsurfing depuis plus de 3 ans. J'ai d'abord assisté à des meetups, puis j'ai enfin pu héberger des gens. Quel voyage incroyable ce fut! J'ai rencontré tellement de gens incroyables du monde entier et je me suis fait beaucoup d'amis. Toute cette expérience a vraiment changé ma vie.

J'ai moi-même accueilli beaucoup de voyageurs, bien plus que je n'ai encore surfé. Alors que je vivais dans l'une des principales destinations touristiques de la Côte d'Azur, j'ai reçu énormément de demandes de canapés (jusqu'à 10 par jour en haute saison). En tant que développeur back-end indépendant, j'ai immédiatement remarqué que le problème avec le site Web couchsurfing.com est qu'il ne gère pas vraiment correctement ces cas de «charge élevée». Il n'y a aucune information sur la disponibilité de votre canapé - lorsque vous recevez une nouvelle demande de canapé, vous ne pouvez pas être sûr si vous hébergez déjà quelqu'un à ce moment-là. Il devrait y avoir une représentation visuelle de vos demandes acceptées et en attente, afin que vous puissiez mieux les gérer. De plus, si vous pouviez rendre publique la disponibilité de votre canapé, vous pourriez éviter les demandes de canapé inutiles. Pour mieux comprendre ce que j'ai en tête, jetez un œil au calendrier Airbnb.

De nombreuses entreprises sont connues pour ne pas écouter leurs utilisateurs. Connaissant l'histoire de Couchsurfing, je ne pouvais pas compter sur eux pour implémenter cette fonctionnalité de si tôt. Depuis que le site Web est devenu une entreprise à but lucratif, la communauté s'est détériorée. Pour mieux comprendre de quoi je parle, je vous propose de lire ces deux articles :

• http://www.nithincoca.com/2013/03/27/the-rise-and-fall-of-couchsurfing/
• http://mechanicalbrain.wordpress.com/2013/03/04/couchsurfing-a-sad-end-to-a-great-idea/

Je savais que beaucoup de membres de la communauté seraient heureux d'avoir cette fonctionnalité. J'ai donc décidé de créer une application pour résoudre ce problème. Il s'avère qu'il n'y a pas d'API Couchsurfing publique disponible. Voici la réponse que j'ai reçue de leur équipe d'assistance :

"Malheureusement, nous devons vous informer que notre API n'est pas réellement publique et qu'il n'est pas prévu pour le moment de la rendre publique."

Pénétrer dans mon canapé

Il était temps d'utiliser certaines de mes techniques d'ingénierie inverse logicielle préférées pour pénétrer Couchsurfing.com. J'ai supposé que leurs applications mobiles devaient utiliser une sorte d'API pour interroger le backend. J'ai donc dû intercepter les requêtes HTTP provenant d'une application mobile vers le backend. Pour cela, j'ai configuré un proxy dans le réseau local et y ai connecté mon iPhone pour intercepter les requêtes HTTP. De cette façon, j'ai pu trouver les points d'accès de leur API privée et comprendre leur format de charge utile JSON.

Enfin, j'ai créé un site Web qui sert à aider les gens à gérer leurs demandes de canapés et à montrer aux internautes un calendrier de disponibilité des canapés. J'ai publié un lien vers celui-ci sur les forums de la communauté (qui sont d'ailleurs assez segmentés à mon avis, et il est difficile d'y trouver des informations). L'accueil a été plutôt positif, même si certaines personnes n'aimaient pas l'idée que le site Web exige des informations d'identification de couchsurfing.com, ce qui était vraiment une question de confiance.

Le site Web fonctionnait comme ceci : vous vous connectez au site Web avec vos informations d'identification couchsurfing.com, et après quelques clics, vous obtenez le code html que vous pouvez intégrer à votre profil couchsurfing.com, et le tour est joué - vous avez un calendrier automatiquement mis à jour dans votre profil. Vous trouverez ci-dessous la capture d'écran du calendrier et voici les articles sur la façon dont je l'ai créé :

• https://github.com/nderkach/couchsurfing-python

J'ai créé une super fonctionnalité pour Couchsurfing, et j'ai naturellement supposé qu'ils apprécieraient mon travail - peut-être même m'offriraient un poste dans leur équipe de développement. J'ai envoyé un e-mail à jobs(at)couchsurfing.com avec un lien vers le site Web, mon CV et une référence. Un mot de remerciement laissé par un de mes invités couchsurfing :

Quelques jours plus tard, ils ont suivi mes efforts de rétro-ingénierie. Dans la réponse, il était clair que la seule chose qui les préoccupait était leur propre sécurité, alors ils m'ont demandé de supprimer les articles de blog que j'ai écrits sur l'API, et éventuellement le site Web. J'ai supprimé les messages immédiatement, car mon intention n'était pas de violer les conditions d'utilisation et de pêcher les informations d'identification des utilisateurs, mais plutôt d'aider la communauté couchsurfing. J'avais l'impression d'être traité comme un criminel et l'entreprise s'est concentrée uniquement sur le fait que mon site Web nécessite des informations d'identification de l'utilisateur.

J'ai proposé de leur donner mon application gratuitement. Ils pourraient l'héberger sur leur environnement et le connecter via l'authentification Facebook. Après tout, c'est une excellente fonctionnalité, et la communauté en avait besoin. Voici la résolution finale que j'ai reçue :

«Nous reprenons le rythme des choses ici après les vacances et nous voulions faire un suivi.

Nous avons eu des discussions internes sur votre application et sur la manière dont nous pourrions à la fois honorer la créativité et l'initiative dont elle fait preuve tout en ne compromettant pas potentiellement la confidentialité et la sécurité des données des utilisateurs de Couchsurfing lorsqu'ils saisissent leurs informations d'identification sur un site tiers.

Le calendrier comble clairement un trou de fonctionnalité sur notre site, une fonctionnalité qui fait partie d'un projet plus vaste sur lequel nous travaillons actuellement.

Mais la question de la collecte des noms d'utilisateur et des mots de passe demeure. Nous ne pouvions pas trouver un moyen simple de le configurer afin que nous puissions l'héberger ou le prendre en charge de notre côté sans vous permettre d'accéder à ces données ou que votre site soit considéré comme notre produit de travail.

L'API actuellement disponible sera bientôt remplacée par une version qui nécessitera une authentification/autorisation des applications qui y accèdent.

Aujourd'hui, alors que j'écris ce tutoriel sur le logiciel de rétro-ingénierie (un an après les événements), la fonctionnalité de calendrier n'est toujours pas implémentée sur Couchsurfing.

Retour à l'innocence - Hacking My Couch, Again

Il y a quelques semaines, j'ai été inspiré pour écrire un article sur les techniques de rétro-ingénierie des API privées. Naturellement, j'ai décidé de résumer les articles précédents que j'ai écrits sur ce sujet, et d'ajouter quelques détails supplémentaires. Lorsque j'ai commencé à écrire le nouvel article, je voulais présenter le processus d'ingénierie inverse avec une API à jour et prendre un autre stub dans le piratage d'API. Sur la base de mon expérience précédente et du fait que Couchsurfing a récemment annoncé un tout nouveau site Web et une application mobile http://blog.couchsurfing.com/the-future-of-couchsurfing-is-on-the-way/, j'ai décidé de pirater à nouveau leur API.

Pourquoi est-ce que je fais ce processus d'ingénierie inverse ? Eh bien, tout d'abord, c'est très amusant de désosser un logiciel en général. Ce que j'aime particulièrement, c'est qu'il ne s'agit pas seulement de votre compétence technique, mais aussi de votre intuition. Parfois, la meilleure façon de comprendre les choses est de faire une supposition éclairée - cela vous fera gagner beaucoup de temps par rapport à la force brute. Récemment, j'ai entendu une histoire d'une entreprise qui devait travailler avec des API propriétaires et peu ou pas de documentation. Ils avaient du mal à déchiffrer la charge utile de la réponse de l'API dans un format inconnu pendant des jours, puis quelqu'un a décidé d'essayer ?decode=true à la fin de l'URL et ils avaient un JSON approprié. Parfois, si vous avez de la chance, tout ce que vous avez à faire est d'embellir la réponse JSON.

Une autre raison pour laquelle je fais ce tutoriel est qu'il faut des années à certaines entreprises pour adopter une fonctionnalité particulière demandée par leurs utilisateurs. Plutôt que d'attendre qu'il soit implémenté, vous pouvez exploiter la puissance de leur API privée et le construire vous-même.

Ainsi, avec la nouvelle API couchsurfing.com, j'ai commencé avec une approche similaire et j'ai installé leur dernière application iOS.

Tout d'abord, vous devez configurer un proxy dans votre réseau local pour falsifier les requêtes HTTP provenant de l'application vers l'API en effectuant une attaque de l'homme du milieu (MITM).

Pour les connexions non chiffrées, l'attaque est assez simple - un client se connecte au proxy et vous relayez les demandes entrantes vers le serveur de destination dans les deux sens. Vous pouvez éventuellement modifier la charge utile, si nécessaire. Dans un WLAN public, il est assez facile d'effectuer cela sous un déguisement en se faisant passer pour le routeur WiFi.

Pour les connexions chiffrées, il existe une différence mineure : toutes les requêtes sont chiffrées de bout en bout. il n'est pas possible pour l'attaquant de déchiffrer le message, à moins qu'il n'obtienne d'une manière ou d'une autre l'accès à la clé privée (qui bien sûr n'est pas envoyée lors de ces interactions). Cela dit, même si le canal de communication de l'API est sécurisé, les points de terminaison - en particulier le client - ne sont pas si sûrs.

Les conditions suivantes doivent être remplies pour que SSL fonctionne correctement :

• Le certificat du serveur doit être signé avec une autorité de certification (CA) de confiance
• Le nom commun du serveur, dans le certificat, doit correspondre au nom de domaine du serveur

Pour surmonter le cryptage lors d'une attaque MITM, notre proxy doit agir en tant qu'autorité de certification (CA) et générer des certificats à la volée. Par exemple, si un client essaie de se connecter à www.google.com, le proxy crée dynamiquement un certificat pour www.google.com et le signe. Maintenant, le client pense que le proxy est en fait www.google.com

Pour implémenter un proxy reniflant utilisé pour désosser l'API privée, j'utiliserai un outil appelé mitmproxy. Vous pouvez utiliser n'importe quel autre proxy HTTPS transparent. Charles est un autre exemple avec une belle interface graphique. Pour que cela fonctionne, nous devons configurer les éléments suivants :

Configurez la passerelle par défaut de la connexion WiFi de votre téléphone pour qu'elle soit le proxy (afin que le proxy soit au milieu et que tous les paquets passent) Installez le certificat du proxy sur le téléphone (afin que le client ait la clé publique du proxy dans son magasin de confiance)

Consultez la documentation de votre proxy sur l'installation du certificat. Voici les instructions pour mitmproxy. Et voici le fichier PEM de certificat pour iOS.

Pour surveiller les requêtes HTTP interceptées, il vous suffit de lancer mitmproxy et de vous y connecter depuis votre téléphone mobile (le port par défaut est 8080).

Ouvrez un site Web dans votre navigateur mobile. À ce stade, vous devriez pouvoir voir le trafic dans mitmproxy.

Une fois que vous vous êtes assuré que tout fonctionne comme prévu, il est temps de commencer à explorer l'API privée de votre choix. Fondamentalement, à ce stade, vous pouvez simplement ouvrir l'application, jouer avec et avoir une idée des points de terminaison de l'API et de la structure de la demande.

Il n'y a pas d'algorithme strict sur la façon de désosser une API logicielle - la plupart du temps, vous vous fiez à votre intuition et faites des hypothèses.

Mon approche consiste à répliquer les appels d'API et à jouer avec différentes options. Un bon début consiste à rejouer une requête que vous avez interceptée dans mitmproxy et à voir si cela fonctionne (appuyez sur 'r' pour rejouer une requête). La première étape consiste à déterminer quels en-têtes sont obligatoires. C'est assez pratique pour jouer avec les en-têtes avec mitmproxy : appuyez sur 'e' pour passer en mode édition, puis sur 'h' pour modifier les en-têtes. Avec les raccourcis qu'ils utilisent, les toxicomanes vim se sentiraient comme chez eux. Vous pouvez également utiliser des extensions de navigateur comme Postman pour tester l'API, mais elles ont tendance à ajouter des en-têtes inutiles, je vous suggère donc de vous en tenir à mitmproxy ou curl.

J'ai créé un script qui lit le fichier de vidage mitmproxy et génère une chaîne curl - https://gist.github.com/nderkach/bdb31b04fb1e69fa5346

Commençons par la requête envoyée lors de la connexion.

 POST https://hapi.couchsurfing.com/api/v2/sessions ← 200 application/json 

La première chose que j'ai remarquée est que chaque requête contient un en-tête obligatoire X-CS-Url-Signature qui est différent à chaque fois. J'ai également essayé de rejouer une requête après un certain temps pour vérifier s'il y a un contrôle d'horodatage sur le serveur, et il n'y en a pas. La prochaine chose à faire est de comprendre comment cette signature est calculée.

À ce stade, j'ai décidé de désosser le binaire et de comprendre l'algorithme. Naturellement, ayant de l'expérience dans le développement pour iPhone et ayant un iPhone à ma disposition, j'ai décidé de commencer par l'iPhone ipa (application iPhone livrable). Il s'avère que pour en décrypter un, j'ai besoin d'un téléphone jailbreaké. Arrêter! Temps de marteau.

Ensuite, j'ai rappelé qu'ils avaient aussi une application Android. J'étais un peu hésitant à essayer cette approche, car je ne connais rien à Android ou Java. J'ai alors pensé que ce serait une bonne occasion d'apprendre quelque chose de nouveau. Il s'est avéré plus facile d'obtenir un quasi-code source lisible par l'homme en décompilant le bytecode Java que le code machine iphone fortement optimisé.

Apk (application livrable pour Android) est essentiellement un fichier zip. Vous pouvez utiliser n'importe quel extracteur de zip pour décompresser son contenu. Vous trouverez un fichier appelé classes.dex, qui est un bytecode Dalvik. Dalvik est une machine virtuelle utilisée pour exécuter le bytecode Java traduit sur Android.

Pour décompiler le fichier .dex en code source .java, j'ai utilisé l'outil appelé dex2jar. La sortie de cet outil est un fichier jar, que vous pouvez décompiler avec une variété d'outils. Vous pouvez même ouvrir un bocal dans Eclipse ou IntelliJ IDEA et il fera tout le travail pour vous. La plupart de ces outils produisent un résultat similaire. Nous ne nous soucions pas vraiment de pouvoir le compiler pour l'exécuter, nous l'utilisons simplement pour analyser le code source.

Voici une liste d'outils que j'ai essayés :

• FernFlower (maintenant partie d'IntelliJ IDEA)
• CFR
• JD-GUI
• Krakatau
• Procyon

CFR et FernFlower ont fonctionné le mieux pour moi. JD-GUI était incapable de décompiler certaines parties critiques du code et était inutile, tandis que les autres étaient à peu près de la même qualité. Heureusement, il semble que le code Java n'ait pas été obscurci, mais il existe des outils comme ProGuard http://developer.android.com/tools/help/proguard.html pour vous aider à désobscurcir le code.

La décompilation Java n'est pas vraiment la portée de ce didacticiel de rétro-ingénierie - il y a beaucoup d'écrits sur ce sujet, alors supposons que vous avez réussi à décompiler et désobscurcir votre code Java.

J'ai combiné tout le code pertinent utilisé pour calculer X-CS-Url-Signature dans l'essentiel suivant : https://gist.github.com/nderkach/d11540e9af322f1c1c74

Tout d'abord, j'ai recherché des mentions de X-CS-Url-Signature , que j'ai trouvées dans RetrofitHttpClient . Un appel particulier semblait intéressant - au module EncUtils . En creusant dedans, j'ai réalisé qu'ils utilisaient HMAC SHA1. HMAC est un code d'authentification de message qui utilise une fonction cryptographique (SHA1 dans ce cas) pour calculer un hachage d'un message. Il est utilisé pour assurer l'intégrité (c'est-à-dire pour empêcher un homme du milieu de modifier la requête) et l'authentification.

Nous avons besoin de deux choses pour calculer la X-CS-Url-Signature : la clé privée et le message codé (probablement une variation de la charge utile de la requête HTTP et de l'URL).

 final String a2 = EncUtils.a(EncUtils.a(a, s)); final ArrayList<Header> list = new ArrayList<Header>(request.getHeaders()); list.add(new Header("X-CS-Url-Signature", a2));

Dans le code, a est un message et s est la clé utilisée pour calculer l'en-tête a2 (le double appel à EncUtils calcule simplement un résumé hexadécimal HMAC SHA1).

Trouver la clé n'était pas un problème - elle était stockée en texte brut dans ApiModule et était utilisée pour initialiser le deuxième paramètre de RetrofitHttpClient.

 RetrofitHttpClient a(OkHttpClient okHttpClient) { return new RetrofitHttpClient(okHttpClient, "v3#!R3v44y3ZsJykkb$E@CG#XreXeGCh"); }

Si nous regardons l'appel à EncUtils , nous pouvons voir que le littéral de chaîne ci-dessus est utilisé textuellement comme clé pour calculer le HMAC, sauf dans le cas où this.b est défini. Dans ce dernier cas, this.b est ajouté avec un point.

 String s; if (this.b == null) { s = this.a; } else { s = this.a + "." + this.b; }

Maintenant, rien qu'en regardant le code, il ne m'était pas clair où et comment this.b est initialisé (la seule chose que j'ai pu découvrir est qu'il est appelé dans une méthode avec une signature this.a(String b) , mais je n'ai pas pu trouver un appel à lui n'importe où dans le code).

 public void a(final String b) { this.b = b; }

Je vous encourage à le décompiler et à le découvrir par vous-même :)

Comprendre le message était assez simple - dans le code, vous pouvez voir qu'il s'agit d'une concaténation du chemin de l'URL, c'est-à-dire /api/v2/sessions et une chaîne avec la charge utile JSON (le cas échéant).

 final byte[] b = this.b(request.getUrl()); byte[] a; if (request.getBody() != null && request.getBody() instanceof JsonTypedOutput) { System.out.println("body"); // this.a(x, y) concatenates byte arrays a = this.a(b, ((JsonTypedOutput)request.getBody()).a); } else { a = b; }

Rien qu'en regardant le code, il était difficile de comprendre l'algorithme exact pour le calcul HMAC. J'ai donc décidé de reconstruire l'application avec des symboles de débogage pour comprendre exactement comment l'application fonctionne. J'ai utilisé un outil appelé apktool https://code.google.com/p/android-apktool/ pour désassembler le bytecode Dalvik en utilisant smali https://code.google.com/p/smali/. J'ai suivi le guide sur https://code.google.com/p/android-apktool/wiki/SmaliDebugging

Après avoir créé l'apk, vous devez le signer et l'installer sur votre appareil. Comme je n'avais pas d'appareil Android, j'ai utilisé l'émulateur fourni avec le SDK Android. Avec un peu d'alimentation à la cuillère, voici comment procéder :

 jarsigner -verbose -keystore ~/.android/debug.keystore -storepass android -keypass android <path_to_your_built_apk> androiddebugkey jarsigner -verify -verbose -certs <path_to_your_built_apk> zipalign -v 4 <path_to_your_built_apk> <path_to_your_output_signed_apk>

J'ai utilisé un émulateur Android intégré fourni avec le sdk et une image virtuelle Atom x86 avec HAXM activé pour garantir son bon fonctionnement.

 tools/emulator -avd mydroid -no-boot-anim -cpu-delay 0

Voici un bon guide sur la façon de configurer une image virtuelle : http://jolicode.com/blog/speed-up-your-android-emulator

Assurez-vous que la ligne HAX fonctionne et que l'émulateur s'exécute en mode virt rapide au démarrage de l'émulateur pour vous assurer que HAXM est activé.

Ensuite, j'ai installé l'apk dans l'émulateur et exécuté l'application. En suivant le guide apktool, j'ai utilisé le débogueur distant IntelliJ IDEA pour me connecter à l'émulateur et définir des points d'arrêt de ligne :

En jouant un peu avec l'application, j'ai pu comprendre que la clé privée utilisée pour initialiser RetrofitHttpClient est utilisée pour calculer le HMAC d'une signature de demande de connexion. Dans la réponse au POST de connexion, vous recevez un ID utilisateur et un accessToken ( X-Access-Token ). Le jeton d'accès est utilisé pour autoriser toutes les requêtes suivantes. Le HMAC pour toutes les demandes de post-connexion est construit de la même manière que la demande de connexion, sauf que la clé est composée en ajoutant .<user_id> à la clé privée d'origine.

Une fois que vous êtes autorisé, l'application envoie la requête suivante :

 POST https://hapi.couchsurfing.com/api/v2/users/1003669205/registerDevice ← 200 application/json

Comme j'ai pu le déduire empiriquement, cette requête est facultative pour l'authentification. Des points bonus si vous comprenez à quoi il sert !

Une fois authentifié, vous pouvez envoyer une demande pour récupérer votre profil utilisateur (ou celui de quelqu'un d'autre), comme ceci :

 GET https://hapi.couchsurfing.com/api/v2/users/1003669205 ← 200 application/json 

Je ne suis pas entré dans les détails, mais j'ai remarqué qu'un profil est mis à jour avec une requête PUT. Juste pour le plaisir, j'ai essayé de mettre à jour un autre profil avec la même requête - ce n'était pas autorisé, donc apparemment les bases de la sécurité sont implémentées.

J'ai écrit un simple script Python pour vous connecter à l'aide de vos identifiants couchsurfing.com et obtenir votre profil utilisateur : https://gist.github.com/nderkach/899281d7e6dd0d497533. Voici le wrapper Python pour l'API : https://github.com/nderkach/couchsurfing-python avec un package disponible dans le référentiel pypi (pip install couchsurfing).

Prochaines étapes

Je ne sais pas exactement ce que je vais faire avec l'API cette fois. Le code HTML dans les profils utilisateur n'est plus autorisé, je vais donc devoir proposer une approche différente à l'ancien problème. Je continuerai à développer et à améliorer le wrapper de l'API python, s'il y a une demande, et en supposant que couchsurfing.com ne causera pas trop de problèmes. Je n'ai pas trop exploré l'API, et je l'ai juste testée pour quelques vulnérabilités de base. Cela semble assez sécurisé, mais il serait intéressant de savoir si vous pouvez accéder aux données qui ne sont pas disponibles via le site Web. Quoi qu'il en soit, vous pouvez maintenant utiliser mon ingénierie logicielle inversée pour créer un client alternatif pour Windows Phone, Pebble ou votre canapé intelligent.

Conclusion avec une question

Il y a une discussion que j'aimerais ouvrir - pourquoi ne pas publier votre API et la rendre publique ? Même si je n'arrivais pas à pirater l'API, il serait toujours possible de scraper le site. Ce serait plus lent et plus difficile à maintenir, mais ils préféreraient sûrement que les consommateurs utilisent une API plutôt qu'un grattoir Web. La disponibilité des API permettrait aux développeurs tiers d'améliorer le produit de l'entreprise et de créer un service à valeur ajoutée autour de celui-ci. On peut faire valoir qu'il serait plus coûteux de maintenir l'API publique plutôt qu'une API privée ; mais encore une fois, les avantages de vos services de construction de communauté en plus de votre produit l'emporteraient sur les coûts de maintenance de l'API.

Est-il possible d'empêcher complètement l'utilisation d'une API privée par des clients tiers ? Je ne pense pas. L'utilisation de l'épinglage SSL empêcherait de renifler les demandes d'API à l'aide d'une simple technique de proxy transparent, comme décrit précédemment. En fin de compte, même si vous obscurcissez le binaire, un pirate motivé disposant de quelques ressources et de temps sera toujours en mesure de désosser le binaire de l'application et d'obtenir la clé/le certificat privé. Je pense que l'hypothèse selon laquelle le point de terminaison client est sécurisé est intrinsèquement fausse. Un client API est un point faible.

En gardant une API privée, une entreprise transmet essentiellement un message de méfiance à ses utilisateurs. Vous pouvez sûrement essayer de protéger encore plus votre API privée. Cependant, ne préféreriez-vous pas implémenter une sécurité de base pour l'API afin d'empêcher toute utilisation malveillante ? et plutôt concentrer vos ressources sur l'amélioration du logiciel pour offrir une meilleure expérience utilisateur ?

Couchsurfing, jolie s'il vous plaît, avec du sucre en plus, ouvrez l'API.