 Bien bonjour à tous d'Axtra, le prochain talk s'appelle It's not safe on the streets, especially for your 3DS, c'est dangereux sur la rue, surtout pour ta 3DS. NBIO va nous parler des 3DS et de cet acte dessus. Applaudissement pour NBIO. Bonjour à tous, je suis NBIO et aujourd'hui je vais vous parler de hacking sur 3DS et en particulier des protocoles non documentés sur lesquels nous allons voir quelques attaques notamment de l'execution code à distance sur une 3DS. Alors avant de voir comment ça marche, je voudrais récapituler un petit peu l'état du hacking sur les 3DS en 2019. Parce qu'on a eu beaucoup d'exploits en username, beaucoup de vulnérabilités dans le kernel qui ont été corrigées et il y a beaucoup de documentation en ligne sur le système. Mais ces dernières années, les gens ont beaucoup travaillé dessus et ils ont réussi notamment à damper la rome de démarrage. Donc tout le monde a la boutre-homme maintenant et avec la boutre-homme on peut dériver toutes les clés secrets du système. Un bonus de ça, c'est qu'on a pu trouver des exploits dans la boutre-homme qui sont permanents et non patchables. Donc vous posez la question, qu'est-ce qu'il reste à faire sur ce système ? Et une des questions que je me suis posé moi, c'est est-ce que ce sera possible de les sécler pour attaquer des fonctionnalités qui jusqu'à présent étaient protégées par du chiffrement. Et c'est pour ça que je vais parler de StreetPass. D'abord je vais vous expliquer un petit peu ce qu'est StreetPass et à quoi ça sert. Et ensuite on va voir comment l'exploiter et qu'est-ce qui est possible de faire une fois qu'on peut exécuter du code là-dedans. Donc qu'est-ce que c'est StreetPass ? C'est une facilité de communication locale sans fil. Donc les gens prennent leur 3DS avec eux, ils se baladent dans la rue et automatiquement la 3DS va communiquer avec les systèmes d'autres personnes. L'idée était de partager des données entre des applications, des jeux comme par exemple des niveaux personnalisés ou des messages, des personnages, des avatars, ce genre de choses. Donc c'est une fonctionnalité très intéressante pour les joueurs mais aussi pour les hackers. Et donc ça c'est le point de vue de l'utilisateur. Vous pouvez envoyer des messages aux autres utilisateurs qui pourront les recevoir par proximité simplement. Mais du point de vue d'un attaquant, on voudra remplacer du coup le système qui émet les messages par un PC, idéalement. Et puis ce serait pas mal si on veut aussi envoyer du code au lieu d'un simple message et idéalement d'exécuter du code sur les 3DS. Mais pour faire ça, il faut qu'on sache bien sûr comment marche StreetPass. Et ce n'est pas très compliqué, ça marche comme une boîte mail. Donc on a un module de système qui gère toutes les fonctionnalités StreetPass. Donc les applications ont une boîte de réception, une boîte d'envoi associé sur le système de fichier de la 3DS. Et ils peuvent écrire et lire des messages dans ces boîtes de réception et d'envoi à travers des IPC. Les messages qui sont dans ces boîtes de réception et d'envoi sont utilisés pour créer des paquets qui sont envoyés par le Protocol StreetPass. Et on peut voir déjà sur ce diagramme, une partie qu'on pourrait essayer d'attaquer. La première partie, c'est les applications elles-mêmes. Parce que c'est très probable qu'on pourra trouver un jeu ou une application qui a un parceur avec des vulnérabilités dedans. Donc on pourrait sûrement exister du code au sein de l'application. Mais ce qui est plus intéressant, ce serait de pouvoir attaquer à CCD le module qui gère StreetPass. Et ça se donnerait une execution de code au niveau du système, dans un module système et ça ce serait pas mal. Mais avant de faire ça, il faut qu'on comprenne comment marche le Protocol StreetPass. Et personne ne sait vraiment comment il marche. Il y a un peu de documentation en ligne sur comment l'association, le pairing, se fait. Comment est-ce qu'un système dit, je suis là ce que tu veux me parler. Mais ça n'a jamais été vraiment reproduit, en tout cas, publiquement. On sait que ça utilise un Protocol du chiffrement inconnu. Et alors on va essayer de le reverter engineer. Alors on va essayer de commencer par verser le pairing. Alors ça c'est simple à comprendre. Donc on a deux pairs, donc le mettre, le client. Donc avec un edit console et puis une adresse Mac. Alors le client envoie un certain nombre de requêtes de broadcast. Donc avec une liste de lieux où le StreetPass est activé. Ensuite le maître reçoit ces requêtes de broadcast. Il vérifie qu'il y a une application sur le client qui a le StreetPass et qui match son application à lui. Et dans ce cas-là il envoie une réponse à la requête. Et le client fait la même chose. Et donc une fois qu'ils sont d'accord qu'ils peuvent échanger de la donnée, ils commencent à communiquer et à dériver une clé commune. Répliquer l'apparemment, c'est pas très très compliqué. Si on sait quels sont les outils à utiliser. Donc ça c'est compliqué parce qu'il faut s'occuper de tout un tas de frames. Donc j'ai utilisé NL811 qui a un certain nombre de callbacks pour différentes sortes de paquets. Et ensuite tout est géré par le driver de cartwifi. Et voilà après on a une 3DS qui commence à envoyer des données chiffrées. Alors on va commencer à regarder un peu le chiffrement. Donc ça se fait en deux fois. Donc d'abord on a hmax-a1 sur les deux adresses mac et console. Et donc cette passe se fait un compteur d'entrée pour un EECTR. Et la sortie de tout ça, c'est une clé de session pour la communication. Donc à NL811, on peut enregistrer des clés CCMP. Ça permet de facilement recevoir des paquets chiffrés. Maintenant on va essayer de réverser et gérer le protocole. Donc on commence par signifier quelques paquets. Donc là voici quelques paquets que j'ai réussi à recevoir. D'abord on a un en tête et ensuite des données. Et là vous pouvez voir quelques valeurs magiques. C'est facile de les voir parce que le CECD utilise vraiment des valeurs magiques très reconnaissables. Mais moque-té répété deux fois. Ensuite en regardant un peu la structure des paquets, on peut comprendre qu'en fait il y a deux protocoles. D'abord le premier c'est le SPTCP. Donc c'est un peu l'équivalent de TCP mais pour une communication locale. Donc c'est ce qui est fait pour la fiabilité et qui gère la segmentation des données. Et ensuite on a SPMTP qui on va des paquets par-dessus SPTCP. Et qui permet de changer des données semi-structurées et des messages street pass. Donc là on va commencer à examiner les deux. Donc d'abord SPTCP. En fait il n'y a pas grand chose à dire. Donc pour ça il faut comprendre la structure de l'entête. Donc d'abord on a le nom magique puis quelques constantes genre dead beef. Et ensuite il y a quelques flags pour les types de paquets. Ce qui permet de comprendre la signification du paquet qu'on en voit qu'on reçoit. En fait heureusement ils utilisent essentiellement les mêmes flags que TCP. Et donc une fois qu'on a compris ça c'est assez facile. Alors à propos de la sécurité de SPTCP, bon ça a l'air pas si mal. J'ai pas trouvé de bug. On peut essayer de manipuler le header mais bon. Voilà on va peut-être regarder SPMTP qui est peut-être plus intéressant. On va regarder un petit peu la structure des paquets SPMTP. En fait on observe qu'il y a deux types de paquets. Le premier c'est les paquets d'information. Donc c'est utilisé pour le handshake initial. Pour changer d'information entre deux machines. Et ensuite il y a les paquets de boîtes à messages. Qui changent vraiment les données d'application. Et à l'intérieur on retrouve les octets magiques des messages CECD. Une fois qu'on a compris que SPMTP marche on peut implémenter le protocole. On va regarder les paquets d'information. Il y a pas mal de données dedans. Donc pour trouver des codes d'amines, d'adresse MAC, des... Et ensuite il y a des données de taille variable. Qui sont beaucoup plus intéressantes. Donc une liste d'applications, une liste de métadonnées. Donc c'est beaucoup plus intéressant parce que peut-être qu'on peut trouver des problèmes dans le parceur. Et peut-être quelques vulnérabilités ici. Alors on va les explorer un peu. Alors regardons un de ces parceurs. Voici une fonction qui traite des listes de métadonnées. Donc il y a essentiellement ici une boucle fort. Et ça prend du coup une liste d'entrée. Ça les place du coup sur la stack. C'est destiné. Et ça ne check pas le nombre d'entrées dans la liste. Donc ça c'est très clairement un buffer overflow. La question est est-ce que c'est exploitable. Donc on va regarder avec un diagramme. Ce sera plus clair. Donc voilà quoi ressemble le buffer de paquet ici. Et on a du coup pour chaque entrée des données qui vont être ajoutées. Et jusque-là tout va bien. Mais si on continue d'ajouter des entrées, on va avoir des entrées qui vont être écrites sur la stack qui vont écraser diverses autres informations. Alors on a un problème ici qui est le buffer de paquet n'est pas assez grand pour atteindre, pour qu'on atteigne l'adresse de retour sur la stack. Donc on ne peut pas vraiment écrire sur des données non contrôlées. Donc c'est dommage. On ne peut rien faire avec ça, mais peut-être qu'on peut regarder le buffer à côté de notre paquet de buffer et peut-être qu'il y a des contrôles là-dedans. Et bien justement, oui, c'est ce buffer juste à côté du buffer de paquet qui est dédié à une liste qu'on a vue juste avant. Donc en fait on peut écraser l'adresse de retour. Alors comme on l'a exploité, sur la 3DS on a donc le bit NX qui est activé, mais on n'a pas de stack cookie, on n'a pas d'ASLR. Donc c'est assez simple. On a juste besoin de faire une rob chain, pas très long d'ailleurs. Et on a juste besoin d'en envoyer une dans la boxlist, une autre dans un paquet, et on a juste besoin de pivoter sur la deuxième chaine. Et bam, on a une execution de code dans COCD. Donc ça c'était un peu facile. Regardons l'optime de paquet, les paquets message box. Ça c'est des paquets qui, c'est, on va envoyer des listes de messages street pass pour une application donnée. Donc ils sont stockés dans des fichiers temporaires, ce qui permet d'éviter, enfin d'être tolérant au télet. Et ensuite ils sont parcés, bien sûr. Donc regardons le parcer à nouveau. Voici la fonction qui charge un de ces fichiers temporaires et qui du coup le charge dans une structure associée sur ma sur la stack. Et ils n'ont pas non plus vérifié le nombre de messages dans la boîte ici. Donc c'est un autre buffer overflow. Ici on a un overflow sur le pointeur de l'arrêt de messages et l'arrêt des tailles de messages. Donc ici à droite on a le fichier temporaire et à gauche la stack. Et on peut voir ici qu'on a une structure sur la stack. On peut voir qu'on écrit le pointeur de messages dedans avec des pointeurs qui pointent vers le buffer du fichier temporaire et on a une liste de tailles pour les messages, la taille de chaque message. Et si on a d'autres façons d'écrire plus de données dans un fichier temporaire on peut voir qu'on écrase d'autres arrêts et qu'on peut écraser partie de la stack. Alors le problème ici c'est qu'on écrit des données potentiellement non contrôlées sur la stack et on ne peut pas forcément contrôler entièrement la taille des messages. Il faudra envoyer des messages de plusieurs gigas pour pouvoir écrire un pointeur à la place de la taille d'un message. Donc ce n'est pas très pratique. Alors qu'est-ce qu'on peut faire à la place ? Ce qu'on peut voir ici c'est qu'on peut mettre la taille du dernier message. Elle est complètement arbitraire parce qu'il y a une vérification qui est que le message qui est en train d'être parcé est-ce qu'il est à l'intérieur du fichier temporaire et si le pointeur sort du buffer, on sort de la boucle sans retourner d'erreur. Donc ça nous permet de déclarer un message extrêmement large pour le dernier message et avec une fin qui est hors du buffer et ça nous permet d'écrire une valeur de 32 bits quelque part sur la stack. Donc il faut qu'on décide quoi écrire maintenant. Alors malheureusement, on ne peut pas juste écraser l'adresse de retour parce qu'on est en train d'écrire surtout des données non contrôlées et atteindre l'adresse de retour, il faudrait écraser une stack frame entière avec des non contrôlées. Donc la seule chose que j'ai pu faire moi, la seule chose que je pouvais écraser sans cracher le système, ça a été cette variable en particulier, cette un pointeur sur une section critique qui est utilisée pour la synchronisation comme un mutex. Et vous pouvez voir qu'il est utilisé après que le fichier temporaire ait été parcé. Donc peut-être qu'on peut faire quelque chose avec ça. Donc voilà la section critique qui est appelée à la fin de cette itération de parsing du fichier. Et on peut voir ici qu'on utilise un pointeur pour décrementer un compteur. Donc c'est tout simplement le nombre de threads qui sont en train d'utiliser cette section critique et on peut écraser ce pointeur. Donc ça nous permet de décrémenter une valeur arbitraire en mémoire. Mais bon il faut qu'on trouve quand même quelque chose à décrémenter qui nous donnera plus de contrôle dans la mémoire et de contrôler du coup le flow d'exécution. Donc j'ai cherché des valeurs intéressantes à modifier et j'ai trouvé quelque chose d'intéressant dans la fonction qui initialise la structure associée avec le fichier temporaire associé au fichier temporaire. Donc voilà la fonction avec qui utilise cette structure d'initialisation. Et on peut voir ici cette variable. Alors on a quelque chose comme un mode d'allocation. Et si ce mode est égal à mode pointeur pointeur mode, on ne va pas essayer de free l'arrêt. Mais si ce n'est pas en mode pointeur mode, on va free appeler free sur tous les messages de l'arrêt. Cette valeur devrait toujours être mise à pointeur mode mais en utilisant cette vulnérabilité qu'on a vu avant, on peut changer cette valeur et on peut donc avoir des pointeurs qui vont être libérés alors qu'ils ne devraient pas l'être. Et puis qu'on contrôle ce qui est à l'emplacement vers lequel pointe ces pointeurs qui vont être free. On peut écrire des faux informations sur le heap. Et c'est plutôt intéressant. Mais il y a un autre problème parce que le mode d'allocation est recette à chaque fois que le bloc est parcé. Donc il nous faut trouver une solution à ça. Ce qu'on peut faire du coup, c'est faire en sorte que cette fonction retourne tôt avant de restaurer le mode d'allocation. Alors ça, ça implique de retourner un code d'erreur invalid. Mais ce n'est pas vraiment un problème puisqu'il ne regarde pas la valeur de retour de cette fonction. Il n'y a rien qui check la valeur de retour de cette fonction. Donc, qu'est-ce qu'on peut faire avec ça ? On peut mettre une première boîte temporaire qui va réécrire le loc sur la stack pour décrémenter le mode d'allocation. Et ensuite on peut envoyer une deuxième boîte temporaire invalid et le parceur va se terminer plus tôt et le pointeur de message, le tableau de pointeur de message ne va pas être recette. Et donc cet arrêt en particulier va être free. Puisque le pointeur de message n'est pas updéter, il pointe toujours vers le premier buffal de fichier temporaire qui a été free mais ce n'est pas un problème si on envoie une deuxième boîte temporaire avec la même taille puisque le buffer va être réalloué pour le deuxième fichier temporaire et au bout d'un moment le free va être appelé dessus et ça va donner le contrôle de ce buffer, appeler sur ce buffer qu'on contrôle. Alors qu'est-ce qu'on peut faire ensuite ? On peut essayer de créer des faux blocs sur le tas qui vont être libérés. Alors le tas de la 3DS est assez peu sûr. Donc on peut obtenir une écriture arbitraire pour chaque chunk qu'on libère. Donc ce n'est pas très compliqué à écraser. Donc il suffit pour ça de décraser le pointeur de tête de la free list du tas avec un pointeur vers ce qu'on veut, par exemple un pointeur vers la pile et donc ensuite le prochain malloc va renvoyer un pointeur vers la pile et on peut s'en servir pour y stocker le troisième fichier temporaire. Alors je vais vous montrer avec ce diagramme. Donc là c'est le premier fichier temporaire, donc il est parcé. La structure associée est écrite sur la pile et elle écrase le pointeur vers le lock pour pointer vers le lock mode en mémoire. Et donc à la fin on appelle la fonction Live Critical Section et du coup ça libère le bloc temporaire et on décrémente la variable. Ensuite la deuxième boîte, le deuxième fichier temporaire charge en mémoire. Donc le premier fichier est réalloué et le dernier pointeur pointe toujours vers la donnée contrôlée. Donc quand le deuxième fichier temporaire est chargé et parcé, tous les blocs sont libérés et ensuite on change la free list pour pointer vers la pile et ensuite quand le troisième fichier temporaire est élu, il va être lu sur la pile et là on peut enfin écraser la adresse de Retro et donc ça lui donne une deuxième execution de code à distance dans le CECD. Et bon, celui-là a été quand même vachement plus compliqué. Alors qu'est-ce qu'on fait ensuite ? Alors une autre, encore. Donc en fait, il y a une autre vulnérabilité dans le parceur de message. Alors c'est une fonction du SDK. Donc toutes les applications qui utilisent StreetPass sont vulnérables. Pas seulement CECD, en fait toutes les applications qui utilisent StreetPass sont censées passer de là. Bon je vais pas en parler ou tout expliquer, je vous laisse essayer d'exploiter. Donc ça c'est la troisième execution de code à distance dans CECD. En fait on peut obtenir une execution de code dans n'importe quel application qu'utilise StreetPass et c'est une backdoor persistante dans CECD parce qu'en fait d'habitude il lit tous les messages dans les boîtes d'envoi au démarrage et donc on peut déclencher avec une vulnérabilité dès le démarrage du système. Donc on a trouvé des execution de code à distance dans CECD. Mais qu'est-ce qu'on peut faire maintenant ? En fait ce CECD a pas vraiment beaucoup de privilèges. Et donc il est plutôt bien sandboxé. Donc si on veut plus de privilèges il faut réussir à prendre le contrôle d'autre chose. Et donc la meilleure chance serait de réussir à prendre le contrôle du noyau ARM 11 parce que ça ça donnerait contrôle total sur ce processeur. Et pour avoir le contrôle total du système il faudrait aussi avoir le processeur de sécurité ARM 9 parce qu'il s'occupe de tout le chiffrement, des signatures, etc. Et on pourra voir ça après. On va d'abord commencer par essayer de prendre le contrôle du noyau ARM 11. Alors d'abord je vais vous parler des IPC et donc d'abord les buffers statiques. Alors quand vous faites de l'IPC il faut parfois envoyer des données donc d'un process qui en va, un process qui reçoit. Et sur la 3DS, vous pouvez faire ça de plusieurs façons. Donc la première, c'est pour envoyer des gros buffers normaux. Et dans ce cas là on map des parties de la mémoire de l'envoyeur sur le récepteur. Mais ensuite il y a un système des buffers statiques. Et si on veut envoyer des petits buffers, le récepteur peut enregistrer des buffers statiques. Et dans ce cas là c'est le noyau ARM 11 qui fait la copie pour vous. Et donc parfois on a aussi besoin d'envoyer des buffers au processeur ARM 9. Et donc dans ce cas là le noyau ARM 11 a besoin d'écrire des paires d'adresses physiques et tailles dans les buffers statiques. Parce que le ARM 9 n'a pas de MMU en fait. Donc il a besoin de l'adresse physique. Et donc ensuite la copie des données est faite par process 9 qui tourne du côté ARM 9. Alors maintenant on va parler d'une vulnérabilité, donc elle s'appelle LazyPixie. Donc elle a été trouvée par TUC5H, je sais pas moi. Alors comment le noyau gère le cas des buffers PXI ? Parce que ça a l'air un peu compliqué. Donc d'abord on check l'alignement du buffer statique de destination, ensuite on vérifie sa taille. Ensuite on vérifie les permissions du buffer source. Ensuite on fait des opérations de cache, on copie des metadonnées, genre l'adresse physique, la taille du buffer statique à la destination. Et ensuite la copie est faite par le parti ARM 9. Mais il y a quelque chose qui manque ici. Puisque en fait on ne vérifie pas les permissions du buffer de destination. Et donc ce que vous pouvez faire c'est utiliser une adresse physique arbitraire comme destination. Et comme ça on peut écraser le MMU et rendre le noyau read write execution. Ce qui est suffisant pour en prendre le contrôle. Donc à ce moment là on a réussi à faire tomber le noyau ARM 11. Donc on a tout le contrôle sur ce processeur. Mais on aimerait avoir un petit peu plus de privilège. Parce que pourquoi pas. On voudrait avoir le contrôle complet sur le système. Alors on prend la route maintenant au contrôle total du système. Et pourquoi attaquer CECD était la meilleure idée du monde. Et donc maintenant on va parler un peu de safe hacks. Donc quelques uns d'entre vous savent peut-être ce que c'est. Donc c'est une très vieille vulnérabilité. Donc c'est une réscondition dans le parceur de l'entête du firmware. Qui permet de prendre le contrôle du côté ARM 9. Une fois qu'on a le contrôle du noyau ARM 11. Elle aurait été corrigée dans la version 9.5 pour le firmware natif. Mais en fait elle n'est pas corrigée dans le firmware safe mode celui de récupération. Alors les gens ont exploité à la fois dans le 9.5 et dans le safe mode. Et il y a des mitigations dans les versions 11.3 et 11.4. Donc ça marche plus. Mais il a été mitigé, pas vraiment patché en fait. Alors qu'est-ce que c'est que cette mitigation ? Alors c'est comme on l'appelle la mitigation. Donc en fait c'est un boulet global qui a été ajouté du côté ARM 9. Et une fois qu'il est mis à 1, le système panique quand on essaie de lancer le firmware en safe mode. Et donc il est mis à 1 dès qu'on essaie de lancer une application. Donc c'est la façon standard de l'exploiter. Donc on a lancé un menu custom et puis on prenait le contrôle du noyau et on a lancé un safe axe. Et donc il mettait le flag à 1 dès qu'on essaie de lancer une application sauf certaines. Parce que le firmware de récupération a besoin de quelques applications pour se lancer. Donc il y a une exception pour le menu de démarrage et quelques menus de système. Et en fait on avait une exécution de code dans CECD qui est un menu de système. Et sans lancer une application et du coup le flag est pas mis à 1. Et on a un exploit du noyau ARM 11 qui permet de répliquer l'exploit safe axe de départ. Donc à la fin on a contrôle total, exécution de code à distance, sans interaction utilisateur. Puisque StreetPass fait tout le boulot en arrière-plan et sur n'importe quelle version de firmware. En tout cas au moment où ceci a été développé puisqu'il y avait un patch dans les versions 11.12. Bon alors maintenant c'est le moment de faire une petite démo. Je vais pas le faire en direct parce que je vais pas faire des exploits sur les ondes mais j'ai une petite vidéo. Alors je lance l'exploit sur mon laptop. Vous voyez la LED est allumée pour montrer que l'exploit est en train de se lancer dans CECD. Et là il lance l'exploit kernel et on peut le démarrer sur l'exploit par exemple. Merci. Donc quelque chose à retenir de tout ça. Déjà on va vérifier, il faudrait leur retour. Parce que la deuxième vune aurait juste pas du tout eu lieu, ou aurait été très difficile à exploiter si les valeurs d'outour avaient été vérifiées correctement. Et ça ne sert pas à quelque chose de se cacher derrière la crypto. Parce qu'un jour votre crypto va être cassé et votre crypto va peut-être casser plus rapidement que ce que vous pensez. Il y avait tout un tas d'erreurs bêtes qui ont été faites qu'on conduit à casser la crypto. Avoir des fonctionnalités difficiles à accéder ça peut être très difficile de les exploiter ou de les comprendre. C'est difficile de comprendre comment répliquer les fonctionnalités du CECD, de comprendre les protocoles impliqués. Mais avec un peu de persistance on peut finir par arriver à des résultats vraiment très intéressants, comme ça par exemple. Et je dis aussi, patcher vos vulnérabilités mettez pas en place des mitigations comme celle de CFAX. On voit que ça marche pas. Il y a toujours du potentiel dans les 3DS, je pense que j'ai pu montrer ça aujourd'hui. C'est un système vraiment intéressant sur lequel travailler, sur lequel développer des choses. Et il y a toujours des choses à documenter à reverse ingénierie. Il y a toujours des choses à faire. Le wiki open source a toujours besoin de contribution donc venez contribuer. J'aimerais aussi remercier TX 5H pour son travail sur ses vulnérabilités, sur cette vulnérabilité. Et Gabriel Mide d'atteindre cette chaîne complète pour exploiter le système complet. Et Hedgeberg qui m'a beaucoup aidé sur énormément de choses. Si vous avez des questions, allez-y. Merci beaucoup. Alors on est à l'heure donc vous pouvez poser des questions. Allez au micro s'il vous plaît. Pas de questions. Ah internet à des questions. Alors on a 2 questions. La première, quels sont les outils et environnement utilisés pour cette recherche ? Par exemple, comment vous avez obtenu tout le cas de source ? Alors tout le système de la 3DS est à source fermé donc c'est que du reverse engineering. J'ai utilisé AIDA et J-Hydra pour reverse ingénierie les binaire de CECD. Et bah c'est tout. Alors merci. On a une deuxième question. Est-ce qu'il y a une procédure pour la Nintendo Switch qui serait compatible avec tout ce que vous avez fait ? Vous pouvez repérer la question ? Tout ce que vous avez fait là, tout le code, est-ce qu'il y a quelque chose de similaire pour la Switch ? Je crois pas qu'il y ait quelque chose de similaire sur la Switch. Il y a une fonctionnalité qui ressemble à StreetPass sur la Switch mais je ne sais pas comment ça marche. J'ai pas travaillé sur la Switch, j'ai uniquement travaillé sur la 3DS. Une première question de la salle. Merci pour le talk, c'est super. Alors est-ce que vous avez besoin des 3 exploits et lequel vous avez utilisé pour... Est-ce que vous pouvez répéter la question ? Alors est-ce que vous avez besoin des 3 exploits ? Ou alors est-ce que vous pourriez juste utiliser le plus facile ? Alors non, on a pas besoin des 3 exploits. Vous pouvez prendre le contrôle COCD avec juste le premier et ça vous donne l'exécution arbitraire de code à distance. Mais je trouvais ça cool d'en utiliser, d'en montrer plusieurs et de montrer toute la chaîne d'exploit ensemble. Alors est-ce que les messages StreetPass sont passés à l'application pendant qu'elles le tournent ? Est-ce que vous pouvez parler un peu plus fort ? Alors est-ce que les applications parsent les messages même quand elles sont pas en train de tourner ? Ou alors est-ce que c'est géré en arrière-plan par l'OS même quand ça tourne pas ? Par exemple si on a une application faite avec le SDK, est-ce qu'elle va automatiquement parser tous les messages ? Je suis pas sûr de comprendre la question, est-ce que vous pouvez reformuler... En fait dans vos 3 méthodes d'explore, donc il y en avait une qui mentionnait que le SDK a été cassé. Si vous avez une application compiler avec ce SDK, est-ce qu'elle va parser les messages qu'on pue même quand elle est pas en train de tourner ? Par exemple si le système était patché mais pas l'application est-ce que ça marcherait ? Alors toutes les applications qu'utilise le SDK doivent être mises à jour pour résoudre cette vulné. Mais l'exploit est déclenché quand l'application lit le message. Donc il faut que l'application soit lancée pour pouvoir l'exploiter. CECD a été patché donc il n'y a plus d'exécution de code d'assistance dans CECD en lui-même. Il n'y a plus de backdoor permanente dans CECD qui se lance à chaque démarrage du système. Mais vous pouvez probablement toujours exploiter des jeux, des applications qu'utilise une vieille version du SDK. Très probable. Une question par-là ? Oui. Est-ce que vous pouvez revenir au slide ou vous montrer tout le chiffrement ? Le chiffrement ? Si le seul truc qu'on change c'est le compteur qui rentre dans les constantes des clés et le CTR. Alors en fait on est presque en train de xorer un bloc connu avec le HMAC. Donc pourquoi on a besoin d'une clé ici ? Alors le compteur change à chaque nouvelle communication StreetPass. Parce que les CID sont aléatoires et l'adresse MAC est ausso aléatoire. Donc il est rendu aléatoire avant chaque communication. Oui alors ce que je veux dire c'est pourquoi on a besoin de la clé. Parce que si on avait un CECD avec un HMAC connu, une fois qu'on le XOR on a le certif final. Si on sait avec quoi la valeur est xorée on peut connaître la valeur qui a été chiffrée par cette clé, cette clé est constante et ça ne permettrait d'extraire la clé probablement. La réponse je ne suis pas super à jour sur les détails de cette crypto mais ça m'intéresse bien m'en parler après le talk. Ce que je voulais juste montrer ici avec ce slide c'était que les gens peuvent reproduire l'attaque comme moi je l'ai faite puisqu'ils ont accès aux clés, puisqu'ils ont déjà été générés et dumpés. Merci à tous.