 Bonjour à tous et bienvenue pour cette présentation. Comment battre la cryptographie de Notpetya par Sébastien Heitschweiler? Bonjour à tous, je veux parler de comment j'ai pu défaire la cryptographie de Notpetya dans Montfaraille. Alors, il y en a qui disent que Notpetya c'est un peu le fléau de l'Ukraine. Si vous ne savez pas ce que c'est qu'un fléau, la personne qui a dit ça ne savait pas non plus. Alors, est-ce que vous savez ce que c'est que ce film? Dans la scène après celle-ci, il y a Johnny Depp qui entre. Johnny Depp vous connaissez? C'est un film par Jim Jarmisch. Le son est par Neil Young. Ah, voilà, il y en a qui savent. Très bon film. Si vous voulez savoir ce que c'est qu'un fléau, vous pouvez regarder ce film. Alors, commençons cette présentation. Ça c'est ce que le compte officiel sur Twitter de l'Ukraine a tweeté en juin 2017. Il y a eu le début d'une épidémie d'un malheur, d'un hostile malveillant, que tout le monde n'a pas forcément vu, mais par contre en Ukraine ça a été très sévère. Énormément d'utilisateurs et aussi des comptes des gens. Gros entreprises ont été affectées par ça. Les dommages se chiffrent dans les milliards de dollars. Le problème là, c'est que ce n'est pas une menace que vous pouvez rencontrer tous les jours. Je vais vous donner un aperçu de l'univers NotPetya et de comment j'ai pu déchiffrer tous ces trucs qui étaient chiffrés par ce ransomware. Alors, pour commencer, je vais expliquer la différence dans l'univers NotPetya. Il y a beaucoup de choses qu'on retrouve sous ce label. Je vais parler uniquement d'une petite partie de cet univers et je veux distinguer ce dont je vais parler et ce dont je ne vais pas parler. Moi, je suis quelqu'un qui se présente par la cryptographie et je suis intéressé aussi en particulier par la cryptographie de NotPetya. Et du coup, je vais parler de comment les étudiateurs se sont retrouvés infectés et de ce qu'ils n'ont plus su bien. Alors, qu'est-ce que c'est que tout cette chose ? L'infection a commencé, comme j'ai dit, en juin 2017. Ça a commencé par une fausse mise à jour, une mise à jour malicieuse, malveillante d'un logiciel. C'est un des logiciels que à peu près toutes les entreprises en Ukraine ont installé pour gérer leur compte et aussi beaucoup de particuliers. C'est donc cette mise à jour qui a été échargée et installée, ce fichier perfidata, qui est compris de plusieurs parties. Certaines parties sont plus dangereuses ou malveillantes que d'autres. La partie NotPetya, c'est une partie qui, quand elle s'exécutait, commençait à chiffrer les fichiers en fonction de leur niveau d'accès. Alors, ça ne disait que les accès que l'utilisateur avait sur la machine. Alors, comme je n'ai pas vraiment le nom pour ça, c'est la partie que moi j'ai appelé Misha et non pas NotPetya. C'est pas forcément un nom génial, mais bon, c'est le don que je lui ai donné. La deuxième partie, très intéressante, c'est la partie que j'ai appelé Spreader, le Repander. Alors, ça, c'est basé sur les exploits, Eternal Blue et Eternal Romance, qui ont été liquées et fichiles. Dans ce taux, je ne peux pas parler de ça non plus, c'est une autre partie de l'univers autour de NotPetya. Dans ce taux, je vais parler vraiment à part de NotPetya en lui-même. Et c'est ça que je vais vous montrer dans les prochaines diapos. Alors, quand l'utilisateur redémarre la machine, il verra quelque chose comme ça. Si les accès administrateurs sont déjà accessibles sur certains moteurs, le virus va infecter le système via le Master Boot Record, les secteurs de démarrage du disque, et va redémarrer le système après un temps prédéfinie, généralement à peu près à 10 minutes. C'est à ce moment-là que le composant NotPetya va se mettre en action. Dans ce Bootloader, on peut voir cet écran qui n'est qu'un écran de fumée au final. En arrière-plan, le virus NotPetya est en train de travailler pour chiffrer tous les fichiers sur le disque. Alors, ce qu'on peut comprendre à partir de Slice, c'est déjà que c'est du code 16-bit. C'est-à-dire qu'il n'y a pas de file-système, il n'y a pas de codon 64-bit, il n'y a pas d'API Windows. Alors, pour débloquer quelque chose comme ça, c'est un boulot important, c'est un boulot significatif. Et du code comme ça, c'est du code qui s'execute vraiment au niveau du BIOS, c'est du code extrêmement basique. Il faut travailler directement avec des interruptions systèmes, interruptions matérielles. Du coup, pour programmer quelque chose comme ça et débugger quelque chose comme ça, c'est un travail important. Heureusement, il y a un plugin très très bien dans le debugger AIDA, IDEA, qui m'a beaucoup aidé. Alors, on va analyser les choses un petit peu plus et on va parler de crypto. Pourquoi analyser la crypto de virus ? C'est quelque chose difficile. Je voudrais parler de la théorie qu'il y a derrière, du chiffrement Salsa20 et ensuite en pratique, comment s'est utilisé dans notre PTIA. Salsa20, c'est un système de chiffrement par stream, par flux. Vous avez des données en entrée sous forme d'un flux, ensuite il y avait un générateur de nombre aléatoire, donc pseudo aléatoire, et des désopérations qui sont en exercice dessus et ça, ça vous donne le texte chiffré. Mais il y a aussi quelques variables, quelques entrées dans ce système. On va parler dans un petit moment. Alors, vous avez une clé de chiffrement, vous avez un nom, et vous avez ces deux choses intéressantes qu'on appelle des compteurs. Ce qui est intéressant à propos de ces choses, c'est que si vous streamer des données chiffrées par Salsa20, vous pouvez perdre de l'entropie et vous pouvez utiliser, vous pouvez perdre la marque où vous êtes dans votre flux, et vous utilisez ce compteur pour retrouver la position dans le flux où vous vous trouviez, et c'est ce qui vous permet de reprendre une lecture ou un chiffrement en courant, c'est une fonctionnalité assez intéressante. Ce compteur est défini sur 64 bits et la fonctionnalité de hachage qui est utilisée, c'est une sortie sur 64 octaves qui peut utiliser comme input pour ce compteur. Si vous voulez plus de détails à propos de ce chiffrement en Salsa20, l'avanteur de ce chiffrement est probablement dans cette pièce, ou en tout cas dans le congrès, donc il peut probablement le trouver et lui poser toutes les questions que vous avez sur ce chiffrement. En tout cas, c'est un très très bon chiffrement, vraiment très bien. J'aurais dû commencer par ça, c'est un peu plus sympa. Alors une chose importante à savoir, c'est qu'à chaque fois que vous faites une opération de chiffrement avec Notpetya, vous avez trois voies de ces entrées qui devraient être des constantes. Notpetya pendant l'infection utiliseraient toujours les mêmes clés, les mêmes nonnes et les mêmes constantes. Et le compteur seulement en changerait entre ces différentes idérations. Alors la question intéressante, la première question intéressante, c'est quelle est la longueur de la clé ? Dans cette implémentation, enfin dans la théorie, c'est très clair, on a 64 bits ici, on a 64 octaves de sortie, donc ça fait à peu près 2 puissances 70 sur la perricée de la clé d'à peu près 2 puissances 70. Quelque chose de différent de la théorie dans l'implémentation utilisée dans Notpetya, c'est que les constantes ici ont été changés pour un stream qui lit des données invalides, et c'est une des failles de cette implémentation. Alors le premier problème que j'ai trouvé dans Notpetya, c'était quelque chose de genre. Alors je pense que je peux passer là-dessus, ça devrait être évident pour tout le monde qu'il y a une erreur ici, qui voit l'erreur là-dedans, il y a des mains levées ? Non, aucune, bon je vais l'expliquer quand même. Non je ne suis pas content, je ne m'attendais pas à ce que vous compreniez tout ça. Alors je rappelle, on est dans du code 16 bits, on a ici une opération de décalage minère à gauche, shift left qui décale un registre par un certain nombre d'octaves ou de bits. Le registre ici n'a que 16 bits et là on le décale de 16 bits à gauche. Donc ça, normalement ça devrait mettre le registre à zéro, et on a la même chose ici, on a carrément un registre de 8 bits qui on décale de 16 bits à gauche. Ce n'est pas quelque chose qu'on s'attend à voir dans une implémentation d'une opération cartographique. Alors moi je me demandais vraiment pourquoi il y avait ça, parce que ça n'a pas de sens que quelque chose dans le code source face à ça. Est-ce que les auteurs de notre pétia avaient fait ça volontairement ? Alors j'ai regardé l'implémentation de Salsa 20 dans notre pétia et en fait avec une simple recherche sur Google, je suis tombé sur un site web qui avait une implementation de Salsa 20 et là dedans on peut voir ce code-ci. Ce que vous voyez ici, c'est dans l'implémentation de l'Indiennes, de l'Indiennes. Et on peut voir ici qu'on décale ces registres en convertissant les différentes portions de ce registre dans ce type de WinFace 16. Alors il faut savoir une autre chose pour comprendre ce qu'il se passe là-dedans. Il y a deux choses importantes qui font que cette implementation est cassée ici. Les deux choses à savoir, c'est qu'il faut compiler ce code en 16 bits et il faut voir aussi ce que Visual Studio fait à partir de ces types d'affichiers, de ces définitions de type. Donc le code ici en dessous vient de Visual Studio directement. Et dans cette implementation, on peut voir que ces types-là sont traités comme simplement des anti-non signés, des unsignés. Et si on compile pour 16 bits, ce type aura une longueur de 16 bits. Et quand on voit ça, les choses commencent à faire sens. Ce qu'on peut voir, c'est que les auteurs de NotPetya n'ont pas spécialement fait attention à la taille de leur type quand ils ont utilisé ce code sur une plateforme 16 bits. Et que l'auteur de ce code n'avait pas prévu que son code serait un jour compilé pour du 16 bits. Et du coup, il a fait cette erreur, c'est le cinéma du coin. Alors, sur ce site, on peut voir deux bugs de l'implémentation SAS-20 de NotPetya. Et je vais les expliquer toutes les deux rapidement parce qu'elles sont assez importantes quand même. Alors, ces deux bugs sont à propos de la variable counter, du compteur qui est rentré qu'on passe à l'algorithme d'entrée. La première erreur, vous... ici on lit un secteur qui est indexé par son numéro de secteur depuis le disque en mémoire. Donc, cette fonction ici s'occupe des aspects de la niveau du disque dur parce que dans le BIOS, c'est normal de voir certains secteurs de disque. On les charge à... ils ont tous une tifix de 502 bits, 502 octaves, pardon. Et du coup, quand on veut les lire, on donne la position en secteur et ça salit un secteur de 512 octaves. Et ça, ce n'est pas du tout l'offset dans le stream. Et c'est ça le problème parce qu'on peut voir en dessous que cette même variable est utilisée pour chiffrer ou déchiffrer. Et ça, c'est quelque chose qui n'a pas vraiment de sens dans cette implémentation. Si on l'analysait, ce que ça donne sur le stream de deux secteurs, le premier commencerait avec FF et ensuite continue avec des données. Et le prochain secteur aurait presque tous les octets identiques. Et ça, c'est un gros problème. C'est vraiment un gros bug dans cette implémentation. C'est une grosse déviation de l'implémentation par rapport à la théorie. Parce que ça transforme notre clé dans une clé chirurgie d'une seule fois. À un menu tempale, une clé qu'on réutilise encore et encore et encore. Alors la clé pour comprendre ce bug, elle vient de ce mot clé ici large. Parce que rappelez-vous, on est dans un monde 16 bits. Et ce mot clé large, on pourrait penser que ça correspond à 64 bits en général quand on progresse ça. Mais ici dans un monde 16 bits, ça indique uniquement une variable de 32 bits. Donc ces deux bugs, c'est un problème assez important dans cette implémentation de Salsa 20. Alors sur cette diapo, j'ai deux dumps en exame. Ces ex dumps, ils viennent de cette expanse qui est de la fonction. Et ça nous donne deux aperçus de snapshots. Le premier, c'est avant cette conversion d'NNS. Et le deuxième, c'est après cette conversion d'NNS, la fonction qu'on a montré tout à l'heure. Alors ici, vous pouvez voir, c'est très propre. Vous voyez les différentes variables qui sont mises dans cette clé. Donc ça c'est le premier bloc qui nous donne des idées de secteur, des index de secteur qui sont invalides. Et on peut voir la clé qui est découpée en deux moitié. Ici vous pouvez voir le dance. Et cette partie qu'on peut voir, c'est ces zéro là. Parce que les bits hauts de cette variable 64 bits n'est pas initialisé. Elle n'est même pas remplie de quoi que ce soit. Donc ça c'est le premier problème. Et après la conversion d'NNS, vous pouvez voir que c'est pas simplement une conversion d'NNS. C'est une modification carrément désothèque. Donc le résultat, c'est que ces 64 bits à l'origine, c'est seulement 16 bits à la sortie. Ce que je disais au début, c'est que dans l'implémentation d'Oagine, on doit avoir 2 puissances 70 bits dans la tête de la clé. Et là on a 16 bits x 64 octets et seulement 26 bits de taille de clé. A la place de quelque chose comme 4 MHz de clé. Donc ça c'est une observation extrêmement intéressante. Et ce bug rend possible de déchiffrer les données qui ont été un chiffré par cette clé réutilisée. Et ça ça rend notre pétilla extrêmement facile à casser. Donc pour résumer rapidement ce parti de la présentation, on a un keystream qui est très très court au lieu d'un 4 MHz. Il se répète énormément puisque à chaque secteur, quand on avance, on a un progrès d'un octet dans la clé. Du coup il ne reste que 26 bits de l'ancien progrès de clé. Et du coup au lieu d'avoir un one-time pad, on a un mini-time pad. C'est une propriété qui est très intéressante et très pratique à analyser. Alors je vais me permettre une petite blague à cette implementation de Salsa 20. Je vais l'appeler Lalsa 20. Ce n'est pas une blague très rigolote mais je vais la faire quand même. Alors moi je ne suis pas un expert en chiffrement et comme je suis le seul genre d'attaque que je connais, moi ce serait de chercher à dériver la clé en chiffrant quelque chose de connu. Ce qu'on appelle une non plaintexte attack, une attaque dans les textes en clair et connu. Alors voyons maintenant à quel point ces attaques marchent et à quel point on peut récupérer le texte déchiffré après une infection avec notre pétia. La façon dont fonctionne notre pétia marche quelque chose à peu près comme ça. Ce que vous voyez à gauche ici, c'est comment ça marche en gros. Si vous n'êtes pas familier avec une fichier NTFS, vous pouvez regarder à droite. C'est une application assez simple. Pour faire simple, dans toute partition NTFS, il y a quelque chose qu'on appelle la master factible MFT. Et cette MFT contient des métadonnées à propos de chaque fichier, comme par exemple le nom, la taille et si le fichier est suffisamment petit, on peut même garder le contenu du fichier directement dans cet enregistrement. Alors comme je disais MFT c'est juste une liste d'enregistrements, une liste de structures. Et c'est le fichier plus gros que cette taille-là. La MFT contient un pointeur vers un cluster de segments sur le disque qui lui contient réellement le fichier. Alors une entrée dans la MFT, c'est un kilopterre. Et regardons du coup à plus haut niveau comment cette implementation est utilisée dans notre PTIA. Notre PTIA simplement itère sur la MFT et regarde si cette entrée pointe vers un fichier, alors on chiffre le premier kilopterre du fichier et ensuite on chiffre l'entrée dans la MFT elle-même. Cette implementation elle a des problèmes, elle est bien pour certaines raisons. La première c'est qu'elle est très rapide puisqu'elle a besoin de chiffrer que le premier kilopterre du fichier. C'est très peu d'informations. Mais ça va corrompre généralement les aideurs par exemple dans ces fichiers qui sont compressés. Généralement il y a plein d'informations très importants dans le premier kilopterre. Une raison pour laquelle c'est utile c'est que la plupart des outils de récupération de données se basent sur ces premiers octets pour reconnaître les fichiers. Et en plus la MFT elle-même est chiffrée et la MFT on peut considérer comme une table des matières. Si on n'a pas la MFT on n'a pas de métal donné, on n'a pas de pointeur vers les fichiers. Ça rend les choses beaucoup plus difficiles quand on veut récupérer des données puisqu'on ne sait pas où elles sont. Donc d'un point de vue implementation c'est plutôt pas mal. C'est rapide et sans chiffrer absolument tout c'est quand même plutôt efficace. Les entrées dans la MFT sont plutôt importantes. Donc moi ma première idée c'était de récupérer ces données là en premier et à partir de là de voir ce qu'on pouvait trouver et ensuite de chercher à récupérer les fichiers eux-mêmes parce qu'il semblait logique que les métal données soient les plus importantes. Alors moi je suis quelqu'un de plutôt visuel. Du coup ici vous pouvez voir j'ai pris des dumps dans des disques sur lesquels je faisais des tests. Donc j'ai pris un système qui était dans un état 9, je l'ai fait avec notre pétière. Et on peut voir à gauche c'est mon disque avant chiffrement et à droite mon disque après chiffrement. Ça peut vous donner une image un peu plus claire de ce qui se passe. Et à gauche ici vous pouvez voir après cette magnifique animation PowerPoint un indicateur tous sont les différences. Ça vous dit à chaque position dans le fichier combien de données sont différentes. Et vous pouvez voir qu'une grosse partie du disque quand même est chiffrée. Cependant vous pouvez voir vers la fin, à ce qu'on peut voir en bas, vous avez du rouge un peu plus foncé. Et ça c'est la MFT. Avec MTFS la MFT en général ou parfois se retrouve à la fin du disque. Voilà ce qu'on a, on a la MFT qui est chiffrée et on a les fichiers qui sont chiffrés. Donc moi je vais d'abord regarder la MFT, deviner la clé à partir de ça. Et une fois que j'ai récupéré cette clé je vais pouvoir prendre la clé, la mettre dans cette petite boîte ici et déchiffrer la MFT. Et à partir de ça j'aurai une MFT déchiffrée. Et avec cette même clé je serai capable de déchiffrer chacun. Avec la MFT je pourrais trouver chacun des fichiers chiffrés et avec la clé je pourrais les déchiffrer à part un. Ça c'était mon approche initiale. Et donc commençons par comment déchiffrer la MFT. Donc les attaques à plein texte connu. Dans la MFT vous avez quelque chose comme ceci, les premiers registrements MFT et sur les colonnes. Vous avez les octets qui sont utilisés comme clé pour encrypter. Rappelez-vous que l'opération, l'opération des clés et du texte c'est une opération XOR. Donc vous avez la clé et vous avez le texte et puis vous pouvez aller de l'un à l'autre entre le texte non chiffré et le texte chiffré. Et puis faire un XOR. Ce que vous voyez pour le premier segment, vous avez très peu d'exemples, très peu d'échantillons. Mais plus vous avancez dans l'analyse, plus vous avez d'échantillons que vous collectez. Et cela donne plus d'efficacité et de confiance dans la connaissance de la clé. Donc est-ce que la MFT a suffisamment de texte, de texte d'encripté ? Donc regardons la spécification, le MFT a deux champs. Il y a l'information standard qui est bien définie, c'est une structure définie et puis il y a les attributs qui est une structure dynamique. Et c'est plus difficile de voir le plaintexte. Donc je me suis concentré sur la première partie et c'est assez constant comme structure pour la plupart des entrées de la MFT. Donc ça commence par file, il y a des chiffres XADCMO et puis dans la partie basse. J'avais un niveau de sûreté de confiance, c'était mon niveau de confiance dans le niveau dans la connaissance de la clé. Donc au début nous avons une sûreté mais une confiance assez faible, considérant qu'il y a 512 octets par sèquement et que MFT et un octet, une entrée MFT est un octet, donc le stream avance de deux octets et pour l'entrée 100, pour 100 entrées, je me suis concentré sur la première partie. J'aurais une confiance de 4 puisque je vais dire que ces deux bytes de texte, de texte simple, me donnent cette sécurité. Le problème c'était vers la fin parce que j'avais beaucoup d'entrées inconnues parce que je me concentrais sur la première partie, sur le hador, donc le reste de la clé. Je n'ai pas pu l'analyser et le décrypter de la même façon, donc j'ai pensé à autre chose. J'ai un espèce d'histogramme docté, donc pour chaque offset de l'entrée MFT, je calculerai un histogramme et je regardais combien d'octets il y a de texte simples. Donc je n'avais pas besoin de texte. Donc pour chaque offset, pour chaque décalage, pour chaque shift, pour chaque entrée, donc la question c'était comment avoir beaucoup d'entrée de MFT. Donc j'ai demandé à des collègues de me donner des échantillons, donc le résultat est assez bien pour les premiers essais. Il n'y a pas grand chose à faire, les premières entrées ont très peu d'échantillons mais lorsque l'on progresse, ça change vraiment sensiblement. Donc je pouvais augmenter mon niveau de confiance dans mon résultat et après avoir fait ce tableau qui sort de nulle part, j'ai comparé ces deux types d'attaques. Donc, lisons ceci de droite à gauche. Donc à droite, j'ai pour la première approche, 90% du MRT qui a été récupéré, 98%. Donc j'ai une drive qui n'est pas encryptée et puis je l'ai après l'infection. Vous pouvez en comparant les deux, différencier l'efficacité, essayer différentes paires de clés, valeur. Donc c'est une approche académique intéressante. Donc j'ai pu exactement mettre le doigt sur combien de ces entrées ont été récupérées parfaitement. Donc pour l'histogramme docté, j'ai pu décrypter tous les dossiers, toutes les entrées. Donc ce qui est très bien puisque nous avons un MFT de bonne qualité, ce qui est bien aussi, c'est que nous avons 0 byte de clés longs. Donc j'ai pu récupérer 3% du flux de clés, j'ai pu récupérer 50 kilomètres des dossiers. En fait c'est ce que je me demande. J'ai fait un autre diagramme, ça c'est le MFT dans le keystream. Donc le keystream est juste rempli dans des échantillons de domégocte et la question est, est-ce qu'il y a beaucoup de dossiers qui sont encryptés dans ce segment ou pas ? Donc j'ai analysé où peuvent être les dossiers dans ce stream. Combien de dossiers il y a dans le stream qui est encrypté ? Donc on voit que le keystream est utilisé partout. Donc il est utilisé plus, il est utilisé moins. Oui car on sait que le keystream n'en encrypte que l'MFT et le premier byte en fait. Donc ceci dans un scénario parfait, ça pourrait être un oracle qui n'est pas plate-texte et qui pourrait être récupéré à 100%. Mais cependant c'est un peu un problème ici. Et dans la prochaine partie de la conférence je vais vous expliquer comment j'ai pu résoudre ce problème également. Quand le système d'exploitation est encrypté par notre pétière, il a l'air de ça. Vous avez le MFT, vous avez des pointeurs qui pointent vers les fichiers. Lorsqu'il termine le premier stage d'infection, le MFT est 100%. Une fois qu'on a récupéré, on peut récupérer presque 100% de la MFT. Donc maintenant on peut utiliser les métadonnées pour analyser ce qui reste des dossiers, ce qui reste de l'encryption. Avec la MFT qui est décryptée, et puis pour les dossiers ensuite, on utilise le premier qui est encrypté. Et le reste du dossier, parce que évidemment la plupart des dossiers font plus qu'un méga octet. Donc le reste n'est pas encrypté. Vous avez plein plein de données et de métadonnées qui servent à collecter les informations qui n'est pas en texte, qui n'est pas en texte simple. Donc j'ai réfléchi à trois différents angles pour attaquer ce problème. Quels genres de fichiers différents y a-t-il ? Quelles types de fichiers ? Vous avez les extensions et les extensions vous donnent le type de fichier. Vous avez des fichiers structurés et des fichiers non structurés. Le code source ce n'est pas structuré. Et puis je calculer l'histogramme, ce qui me donne la prévalence de la structure des paétes, des octets. Donc je devine s'il y a eu une attaque plein texte ou pas. Donc pour les fichiers structurés, c'est la même approche que pour les entrées MFT. Je regarde sur les offset et je vois tout de suite combien de bytes de différence d'offset il y a, de shift il y a. Et donc la dernière approche, c'est quelque chose sur les metadata. Donc là, c'est les données des fichiers. Je vais vous l'expliquer maintenant. Ce que j'ai, cette petite portion du fichier est ancréptée et le reste du fichier n'est pas ancrépté, ce qui est très bien. Et ce que j'ai aussi, c'est le nom du fichier et la taille du fichier. Ce que je fais, je crée des... J'ai créé une base de données des fichiers connus qu'on retrouve sur des systèmes Windows. Il y a des tas de fichiers qu'on retrouve couramment sur des systèmes partout. Il y a énormément de ces fichiers d'ailleurs si on cherche un peu. Et il y a trois différentes façons de retrouver, de distinguer ces fichiers. Parfois il y a quelques versions des fichiers, mais du coup on peut trouver des façons de faire le nom du fichier, la taille du fichier et le hache de la partie anclaire du fichier. Avec ces trois critères, c'est les trois matchs, c'est la chose que j'ai dans ma base de données. Je considère que c'est le même fichier et du coup je peux fournir le plein texte correspondant à ce fichier. Alors il y a quand même quelques collisions, mais globalement c'est comme une approche simple et il y a tendance à marcher. L'idée initiale de commencer par déchiffrer l'AMST, ce qui rendrait ça plus simple de déchiffrer les fichiers. Il a fallu le changer un petit peu, donc j'ai ajouté cette base de données des fichiers connues ici, comme une autre composante de l'analyse dans cette panneau, jolie boîte ici. Et ça permet à cette autre juvie de boîte ici de déchiffrer les fichiers. Ce sont un peu de sciences et vérifions si cette approche fonctionne et si elle vaut le coup de la tenter dans un scénario réel. Si Science 4 peut faire sa science, ça je parle. Alors ce qu'on fait ici, c'est qu'on a créé une base de fichiers qui correspond aux installations par défaut de Windows, qui m'a donné 340 000 fichiers unique et je l'ai calculé les histogrammes pour les types de fichiers dont j'ai parlé avant. J'ai préparé mon structure pour tester avec des fichiers différents. Ce que vous auriez fait c'est que ces fichiers que j'ai mis dessus ne faisaient pas partie de ma base de données des fichiers connues. Je lesai introduits après. Ensuite j'infectais la machine, je laisse notre pétia chiffrer les données sur le disque et ensuite je fais la récupération de données. Et voilà les résultats. Alors j'ai fait ça en 4 passes avec 4 approches, j'ai essayé toutes les approches séparément et ensuite j'ai combiné les 3 approches. Alors les résultats c'est quelque chose comme ça. Alors avec l'approche de l'histogramme générique, je n'ai récupéré que 2 fichiers avec 7. Avec l'approche de l'histogramme localisé, je récupérais à peu près 8 % et avec l'approche difficile et connue, je récupérais 90 %. Et en combinant ces 3 approches, je peux récupérer presque tous les fichiers. Voilà pour la partie académique. Si vous appliquez ces méthodes dans le monde réel, ça ne se passera peut-être pas aussi bien que ça. Le monde réel c'est un peu plus difficile à propos de ça par exemple. On va avoir des systèmes qui ont eu plein de mises à jour ou des traductions différentes. Et ça ce sera très intéressant de regarder à ça. On va regarder ce que commence à se passer en pratique. Dans le monde réel, il y a d'autres programmes qu'on peut analyser pour trouver d'autres fichiers connus. Par exemple, les librairies.net ou les installations de Java avec le JDK. En particulier le JDK, ça donnerait des dizaines de milliers de fichiers HTML qu'on pourrait ajouter à la base de données. Donc ça c'est quelque chose de très intéressant. Alors le petit bémol que je peux ajouter à ça quand même, c'est qu'il y avait tellement de données que mes premières tentatives là-dessus ont échoué lamentablement parce que ça utilisait juste trop de RAM. Et dans mes essais, je demandais à mes administrateurs des besoins dans mon système de mener plus de RAM, plus de RAM, plus de RAM pour mes machines digituelles. Et j'en suis arrivé à avoir des devn de tests qui avaient des dizaines de gigadrammes. Également dans la MFT, j'avais beaucoup trop d'entrée à cause de tous ces fichiers de tests que je devais installer. Dans mes fichiers de tests, j'avais fait près de 26 Mb de MFT. Mais dans un système du monde réel, il y aura en général au moins 500 Mb de MFT. Mais ça, ça veut dire beaucoup plus de texte en clair à utiliser. Et rien qu'avec la MFT, on pourrait récupérer l'intégralité des 4 Mhz du fût de clé. Ça veut dire que le déchiffrement d'un disque chiffre par notre Pétia, c'est possible. Quand je regardais des systèmes fichiers ou des disques durs qui étaient chiffrés, une fois que j'ai pu passer outre ces premiers bugs, j'étais capable de récupérer l'intégralité des fichiers sur ces systèmes. Donc il y a une bonne chance que vos photos de vacances ont pu se les récupérer aussi. Donc voilà, ça c'est la conclusion de ma présentation. En conclusion, pour résumer, notre Pétia souffre de pas mal de bugs dans l'applémentation de Salsa 20 que j'appelle le Salsa 20. On va regarder plus profondément dans ce qui se passe dans cette fonction par Expankey. Il y a d'autres problèmes, d'autres erreurs qui ont été faites dans l'applémentation de Salsa 20 là-dedans. Et si il y en a un parmi vous qui sont nos meilleurs chercheurs en université, ça peut être quelque chose d'intéressant à donner à vos étudiants de faire une crypte-analyse plus poussée de cette applémentation. Vous pouvez le savoir quand même, ce que j'ai dit là sur notre Pétia, c'est pas que notre Pétia. C'est des problèmes qu'on trouve dans toutes les versions de Pétia. Donc tous les disques qui ont été chiffrés, on peut les déchiffrer et sauver les necks qui sont dessus. Enfin en conclusion, si vous avez été victime dans le sommoir, je vous dis, gardez vos visques durs. Mettez-les dans un tiroir et gardez-les aussi longtemps que nécessaire. Et attendez que quelqu'un comme moi fasse une présentation comme celle-ci et vous donne la solution et peut-être que vous pourrez déchiffrer vos disques et récupérer vos photos de vacances. Voilà, c'est tout. Merci pour votre attention. Si vous avez des questions sur le stream, vous pouvez les poser sur hier. C'est au Signal Angel, on en avait une. Première question. Merci beaucoup d'avoir partagé vos vidéos d'art avec nous. Moi je viens de Rotterdam, le plus grand port de Europe. Et on a été frappés par Pétia. Deux terminaux entiers ont été hors ligne pendant plusieurs jours, 1 milliard d'euros de dommages. En pratique, si vous aviez été là cet été avec vos trouvailles, est-ce que vous auriez pu nous aider et déchiffrer ces fichiers et permettre à ces entreprises de marcher encore ou est-ce que c'est juste anniversaire académique ? Non, c'est une approche pratique. Je travaille pour Crosstrack et nous avons eu des occasions où nous avons pu aider des clients. C'est une application pratique. J'ai essayé d'insinuer ceci avec cet slide. Je parlais de la réalité dans ce scénario. Donc j'ai vu 50 disques durs en crypte avec notre Pétia et j'ai pu quasiment les décrypter tous. Et ceux que je n'ai pas pu décrypter, ils étaient à un niveau où il y avait des erreurs. Vous avez trouvé des choses aussi à propos de... Non, je ne l'ai pas fait. Au début, vous avez dit que l'actualité est raccourcée d'un fin de ciseau que tout seulement. Et du coup, à partir de là, est-ce que l'attaque par force brute n'aurait pas été plus rapide et plus fière ? Ah non, non, attention. La longueur du stream, c'est 2 à la puissance 26. Donc c'était 4 megabytes de stream. Donc on ne peut pas faire une attaque brute force là-dessus. Vous comprenez, le nombre de bytes était 4 méga octets. Donc on ne peut pas faire une brute force là-dessus. Oui, mais au début, cette clé était quand même raccourcée à un maximum de plus en statistiques. Oui, mais je comprends ce que vous dites. Je comprends tout à fait ce que vous dites. Mais vous oubliez un élément important. C'est la longueur de la clé. Ce n'est pas l'espace de la clé, c'est la longueur de la clé qui est de puissance 26. Donc si vous convertissez en décimale, c'est quelque chose... C'est énorme, ici, quelqu'un qui fait des maths, de puissance 26. Combien de bits ? Énormément, énormément. Donc c'est vraiment 4 megabytes de longueur de clé. Et on ne peut pas juste faire une attaque brute force là-dessus, parce que chacun de ces 4 megabytes, il faudrait faire une attaque brute force sur chacun des méga octets. Donc ce n'est pas la clé qui est de puissance 26, mais la longueur de la clé. Vous voyez la différence ? Donc l'espace que la clé est plus grand que la Bible. Donc vous ne pouvez pas faire une attaque brute force sur le texte de la Bible. Ok, si vous avez suffisamment de temps, etc. Mais vous connaissez l'histoire des singes avec les machines à écrire. On peut en reparler plus tard, mais je crois que vous confondez 2 grosseurs là. Est-ce que le chiffrement de la MFT marche de la même façon pour pétière et pour notre pétière ? Oui, ce sont les mêmes mécanismes sous-jacents. La cryptographie est différente, selon vous, de telle façon que les constants, les nombreux constants sont différents. Donc ce petit élément là est différent. Ce serait ex-pand-key, quelque chose, quelque chose, et là, c'est invalid sect ID. Donc c'est des constants différents. Mais l'incruption de la MFT, l'algorithme, c'est le même. D'autres questions ? Eh bien, donc merci d'applaudir Sébastien. Merci beaucoup. Merci, merci.