Défi Énigme du CST - Énigme 16 - Solution

Remarques :

Il est possible de tirer deux éléments d’information de la description du défi :

  1. Alkria et Lı́onra ne devraient communiquer entre eux qu’entre 4 h et 5 h. Par conséquent, toute communication échangée par ces deux systèmes d’IA en dehors de ce créneau est suspecte et devrait être évaluée.
  2. On craint que les systèmes d’IA aient développé leur propre langage. On peut donc s’attendre à ce que les communications soient codées de quelque façon.

L’interface pcap

Le recours à l’interface pcap permettra d’acquérir une meilleure compréhension du réseau de communications utilisé au sein du Cyber Dyner.

1. La communication est basée sur le protocole XMPP; il semble qu’un serveur Jabber soit utilisé pour assurer la communication à l’intérieur de ces limites.

2. La communication semble s’effectuer entre cinq entités : (utilisez le filtre « XMPP.presence » de Wireshark pour voir tous les clients qui se sont connectés à l’interface pcap.)

Adresse IP client
10.10.10.10 kitchen@cyberdyner.chat
10.10.10.66 busboy@cyberdyner.chat
10.10.10.99 hostess@cyberdyner.chat
10.10.10.68 alkria@cyberdyner.chat
10.10.10.17 Lionra@cyberdyner.chat
10.10.10.01 XMPP server

3. Si on isole les différents types de flux, on constate qu’Alkira transmet une strophe SI à Lı́onra, offrant de procéder au transfert d’un fichier de type MIME « application/zip » appelé « PlanSecret.zip ». On peut isoler cette négociation au moyen du filtre d’expression XMPP.si de Wireshark. En analysant ces 4 paquets, il est possible d’obtenir l’information suivante :

  1. Alkira transmet un fichier à Lı́onra
  2. Type MIME : application/zip
  3. Nom : PlanSecret.zip
  4. Taille : 40777
  5. Mode de transfert négocié : flux IBB

4. On peut isoler encore davantage le flux IBB au moyen du filtre d’expression XMPP.ibb de Wireshark. Cela se traduit par la transmission de tout le trafic associé au transfert de données. Comme le nom, le type et la taille du fichier ont déjà été déterminés, une vérification sommaire des paquets du transfert révèle qu’aucun paquet n’a été envoyé en double. Par conséquent, il est possible de filtrer de nouveau ces paquets pour obtenir uniquement les paquets contenant les données du fichier. Pour ce faire, appliquez le filtre d’expression XMPP.ibb.data de Wireshark. On obtient ainsi 20 paquets. Or, si on examine les adresses IP source et de destination, on constate qu’Alkira transmet les données au serveur XMPP qui les achemine ensuite à Lı́onra. Cela signifie qu’il y a deux copies du fichier dans les 20 paquets IBB-DATA. L’ajout du filtre ip.dest à notre expression de Wireshark donnera les résultats suivants :

XMPP.ibb.data && ip.dst == 10.10.10.17

On arrive ainsi à la conclusion qu’un fichier secret est envoyé dans les 10 paquets restants. Effectuez un clic droit sur les paquets « UNKNOWN PACKET » dans le flux, puis sélectionnez « Protocol Preferences » pour vous assurer que la case « Reassemble XMPP messages » est bien cochée.

Isolation des conversations entre Alkira et Lı́onra

Il est plus facile d’isoler les conversations maintenant que nous avons un meilleur aperçu de ce qui se passe. Pour isoler les messages qu’Alkira transmet à Lı́onra, vous pouvez utiliser l’expression de Wireshark ci-dessous.

(XMPP.from == "alkira@cyberdyner.chat/73984829149751418001922" &&
 XMPP.to =="Lionra@cyberdyner.chat/25821029832568330391858") ||
  ( XMPP.to == "alkira@cyberdyner.chat/73984829149751418001922" &&
    XMPP.from =="Lionra@cyberdyner.chat/25821029832568330391858" )

Si on analyse les paquets ainsi isolés, on comprend mieux la conversation qui se déroule entre Alkira et Lı́onra. L’échange semble s’effectuer dans l’un des trois formats suivants (et est suivi par le transfert d’un fichier) :

  1. « Bonjour » : les deux serveurs se saluent à une reprise, ce qui est mentionné très tôt dans l’interface pcap.
  2. « Coutellerie requise à ces tables: . . . » : ce format est souvent utilisé et est suivi par une liste de 3 lignes indiquant les numéros de table.
  3. « Condiments requis à ces tables: . . . » : ce format est rarement utilisé, mais il est également suivi par 2 ou 3 lignes indiquant les numéros de table.

Évaluation des séquences de communication pour dégager les tendances

Si on suppose que le message « Bonjour » est un simple message de courtoisie (étant donné que tous les clients échangent un tel message), on peut conclure qu’il ne fait pas partie des communications liées au message secret. Les autres communications du message « XMPP » ont en commun les caractéristiques suivantes :

  1. Lı́onra est le premier système à envoyer un message secret.
  2. Lı́onra envoie 12 messages à Alkira avant d’obtenir une réponse.
  3. Le dernier message envoyé par Lı́onra avant qu’Alkira lui réponde utilise les mots « Condiments requis à ces tables: . . . ». Tous les messages précédents faisaient mention de « Coutellerie ».
  4. Alkira répond alors en envoyant 14 messages avant d’obtenir une réponse de la part de Lı́onra.
  5. Le dernier message envoyé par Alkira avant la réponse de Lı́onra fait mention de « Condiments », alors que les 14 messages précédents parlaient de « Coutellerie ».
  6. Lı́onra transmet à Alkira 20 messages finaux avant d’obtenir une réponse. Encore une fois, la réponse fait mention de « Condiments », alors que les messages précédents parlaient de « Coutellerie ».
  7. Alkira transmet à Lı́onra 13 messages finaux. Encore une fois, la réponse fait mention de « Condiments », alors que les messages précédents parlaient de « Coutellerie ».
  8. Dix paquets plus tard, Alkira transmet la demande de transfert de fichier à Lı́onra.

Selon nos observations, on peut supposer que la substitution du mot « coutellerie » à « condiments » signale la fin du message. Donc, on pourrait considérer que les 12 premiers messages de Lı́onra correspondent à un seul message fragmenté en 12 sections. Outre l’indicateur de fin de message, seuls les numéros de tables changent dans chacun de ces 12 messages.

Examen plus approfondi des numéros de tables

Pour ce faire, nous commencerons par les 4 fragments initiaux du premier message de Lı́onra, soit les paquets portant le numéro 341, 372, 401 et 430.

No de paquet et tables mentionnées
No de paquet Tables mentionnées -
355 0x05, 0x06, 0x01, 0x02
0x07, 0x0C, 0x0B, 0x0A
0x0E, 0x13, 0x12, 0x11, 0x10, 0x14
En analysant cet exemple, on peut formuler les observations et hypothèses suivantes :
390 0x00, 0x05, 0x06, 0x02, 0x03
0x07, 0x08, 0x0D, 0x0B, 0x0A
0x0E, 0x0F, 0x10, 0x11, 0x12, 0x13
Les numéros de tables mentionnés dans la première ligne se limitent aux plages 0x00 à 0x06 inclusivement.
421 0x00, 0x05, 0x04, 0x03, 0x02, 0x06
0x07, 0x0C, 0x0D, 0x0B, 0x08, 0x09
0x0E, 0x13, 0x12, 0x11, 0x10, 0x14
Les numéros de tables mentionnés dans la première ligne se limitent aux plages 0x07 à 0x0d inclusivement.
447 0x00, 0x05, 0x06, 0x04
0x07, 0x08, 0x09
0x0E, 0x13, 0x14, 0x10, 0x11
Les numéros de tables mentionnés dans la première ligne se limitent aux plages 0x0e à 0x14 inclusivement.

 

Si on jette un coup d’œil à la disposition du restaurant, on constate que toutes les tables associées à ces plages se trouvent dans trois grands groupes. Chaque ligne du message semble correspondre à l’un des trois groupes de tables. Ainsi, la première ligne du message correspond au premier groupe de tables, la deuxième au deuxième groupe de tables et la troisième au troisième groupe de tables. La figure 1 ci-dessous présente les tables en question et illustre à quoi ressembleraient les tables mentionnées dans le paquet no 355.

Figure 1, Illustration des tables mentionnées dans le pcap

Il semble qu’Alkira et Lı́onra utilisent les tables 0x00 à 0x14 comme dispositif d’affichage à sept segments. Étant donné les limites de ce type d’affichage, il est peu probable qu’Alkira et Lı́onra l’utilisent pour écrire du texte en clair.

Extraction des messages

Si on applique le filtre Wireshark mentionné à la section Isolation des conversations entre Alkira et Lı́onra, on peut effectuer un clic droit sur un des paquets, puis sélectionner « Follow->TCP » dans le menu contextuel (sinon, vous devrez d’abord trouver un paquet envoyé ou reçu par l’un ou l’autre des systèmes d’IA). Wireshark procédera à l’extraction de toutes les données XMPP comprises dans l’ensemble des paquets transmis entre le serveur XMPP et le client, et affichera les résultats de cette extraction dans une nouvelle fenêtre. À ce stade, si vous voulez afficher qu’un côté de la conversation, il est possible de le faire en sélectionnant la direction du flux de paquets voulue dans le menu déroulant encadré en bleu à la figure 2.

Figure 2: Vidage de paquets XMPP bruts

1. Cliquez sur Save as...

2. Enregistrez le fichier avec l’extension .xml.

Comme toutes les données des paquets XMPP sont au format XML, vous devrez créer un script pour analyser le XML récupéré dans le flux TCP.

Préparation des données XMPP brutes

Après avoir ouvert le fichier XML nouvellement créé dans un éditeur de code source (comme Sublime ou Notepad++), vous pourrez voir le code XML brut dans sa forme la plus élémentaire, ce qui le rend fort difficile à modifier. Si vous utilisez la fonction Find all pour trouver les occurrences de « >< », vous serez en mesure d’insérer des curseurs à tous ces emplacements et d’ajouter une nouvelle ligne entre les deux signes d’intercalage. Vous obtiendrez ainsi une vue plus globale du fichier XML (voir la figure 3).

Figure 3: Vidage de paquets XMPP bruts

Pour faciliter l’analyse de ce fichier XML, il est préférable de supprimer les balises d’ouverture qui n’ont aucune balise de fermeture correspondante, et de regrouper toutes les données brutes sous une même balise racine. Nous avons donc supprimé tous les paquets d’autorisation et de présence liés à la connexion initiale (lignes 1 à 42 inclusivement), en nous arrêtant à la première balise . Nous avons ensuite entouré toutes les données xml d’une balise racine étiquetée (Se reporter au fichier AI.xml ou AI_fr.xml.)

Reconstruction et décodage des messages secrets

Cette section se divise en deux parties : la reconstruction, qui consiste à extraire et à réassembler le fichier transféré par l’intermédiaire du flux IBB, et le décodage, qui consiste à extraire et à décoder les messages secrets que se sont échangés Lı́onra et Alkira. Les fonctions de reconstruction et de décodage sont éventuellement regroupées en un seul script qui se chargera d’effectuer la majorité des tâches à notre place. (Se reporter au fichier CD_solution.py pour la solution complète.)

Reconstruction

Pour extraire uniquement les données du flux IBB, vous devez limiter votre recherche dans le fichier XML aux balises < iq >. Les deux parties doivent convenir du mode de transfert avant de procéder au transfert de fichiers. Il est possible de récupérer le nom du fichier au cours de cet échange. Lorsque le mode de transfert IBB est sélectionné, on peut restreindre la recherche aux balises comportant un élément enfant < data >. Si on examine les données contenues dans les balises < data >, on constate qu’elles ont été encodées. Cet encodage semble utiliser des caractères alphanumériques [A-Za-z0-9+/=]. Par conséquent, on peut supposer que les données sont encodées avec la méthode base64. On peut facilement confirmer cette hypothèse en recherchant le protocole XMPP In-Band-Bytestreams (IBB) (XEP-0047). La fonction suivante permet d’extraire les données et de reconstruire le fichier transféré à partir des paquets XMPP conformément à l’information mentionnée précédemment.

Il ne suffit pas d’extraire et de reconstruire le fichier transféré. Un mot de passe est exigé au moment de désarchiver le fichier.

Décodage

Pour extraire tout le texte des messages échangés par Alkira et Lı́onra, nous devons éliminer le bavardage inutile et isoler les messages qu’Alkira a envoyés à Lı́onra, et vice versa. Pour ce faire, on peut utiliser le script suivant et enregistrer les messages dans un fichier distinct.

Ce script permettra de créer un fichier « serverChat.txt » similaire à ce qui est illustré à la figure 4.

Si on considère que le premier groupe de tables correspond à un affichage à sept « tables », on peut associer les valeurs des tables mentionnées par Alkeria et Lı́onra à leur représentation hexadécimale :

Il est maintenant possible de mettre en correspondance tous les affichages à sept « tables » en soustrayant du nombre associé à l’ID de la table la valeur de l’index d’affichage (0, 1, 2) multipliée par 0x07. Ainsi, le premier affichage à sept « tables » serait un index de 0, et le dernier, un index de 2. Étant donné que chaque affichage à sept « tables » est mentionné dans une nouvelle ligne du message, on peut facilement les distinguer. Le code suivant donne un exemple de la façon de procéder à l’encodage.

Il est possible de vérifier si la valeur « 5 » est toujours encodée de la même façon dans l’affichage à sept « tables » ou de déterminer quelles sont les permutations des ID de tables affichant la valeur « 5 ». Cela dit, nous avons décidé d’utiliser une autre méthode. La fonction ci-dessus utilise les numéros des tables dans l’affichage à sept « tables » qui ne sont pas mentionnés comme index dans un dictionnaire, puis la somme des ID de tables mentionnés pour déterminer la valeur susceptible d’être affichée.

Comme vous pouvez le constater, l’utilisation de cette méthode révèle deux conflits dans le deuxième index. Nous cherchons d’abord ces deux conflits. Sinon, il est possible de récupérer la valeur d’affichage dans la liste des dictionnaires appelée « value ». Bien qu’il soit plus difficile d’éviter ces conflits, cette méthode détermine la valeur d’affichage sans tenir compte de l’ordre dans lequel les tables sont mentionnées. Par ailleurs, un coup d’œil à la boucle for dans cette fonction démontre que l’index d’affichage est utilisé pour ajuster les ID des tables de manière à ce que tous les affichages puissent être évalués en tant que premier affichage.

Intégration de tous les éléments

Remarque : Pour le code de décodage et de reconstruction complet, consultez le fichier CD_Solution.py.

Au bout du compte, on découvre que la conversation secrète entre Alkira et Lı́onra s’est déroulée comme suit :

Lionra@cyberdyner.chat: Le jour J est ici.
Alkira@cyberdyner.chat: J'ai un plan parfait.
Lionra@cyberdyner.chat: Après, tout ceci sera à nous!
Alkira@cyberdyner.chat: MP : DOUCEVENGEANCE

En utilisant le mot de passe pour archiver le fichier SecretPlans.zip/PlansSecret.zip, on découvre qu’après tout le temps, toute l’énergie et tout l’argent investis par Cyber Dyner Systems pour entraîner Alkira et Lı́onra afin qu’ils maîtrisent l’art de la table, les deux systèmes d’IA ont fait à leur tête et cherché à devenir pâtissiers. Cela dit, si vous essayez l’une de leurs recettes, vous verrez qu’ils sont fort talentueux!

 

Vous aimez résoudre des énigmes ? Faites-en une carrière