👨‍🚀 🐩 🦖 Wright dans l'ombre 💕 🎏 ⚫️

Il s'agit d'une histoire sur l'une des tâches que nous avons préparées pour la phase de qualification CTFZone , qui s'est tenue fin novembre. Vous pouvez en savoir plus sur le processus de préparation à la qualification ici .

Vous commencez avec deux fichiers: decrypt_flag.py et ntfs_volume.raw. Jetons un coup d'œil au script. Il ouvre un fichier nommé key.bin, puis, à l'aide d'une boucle, il essaie de prendre une chaîne binaire de 34 octets à partir de chaque décalage à l'intérieur du fichier, qui est ensuite utilisée comme entrée pour la fonction PBKDF2. Chaque clé retournée est utilisée comme clé XOR pour déchiffrer la chaîne chiffrée cousue dans le code. Si son hachage MD5 déchiffré correspond à la valeur prédéterminée sous une forme déchiffrée, le script utilise les données reçues pour générer et imprimer le drapeau.

Vous devez donc trouver le fichier key.bin. Il est impossible de trier simplement tous les décalages à l'intérieur du fichier image (ntfs_volume.raw), car le processus de recherche de la clé sera trop lent. Ce n'est pas interdit par les règles, mais vous n'aurez certainement pas le temps avant la fin du CTF.

Le fichier image contient une table de partition MBR à partition unique. Son décalage est de 2048 secteurs de 512 octets, et il contient le système de fichiers NTFS, mais le fichier key.bin n'est pas là:

$ fls -o 2048 -r -p ntfs_volume.raw | grep -F key.bin | wc –l
0

NTFS stocke les noms de fichiers codés UTF-16LE. Essayons de chercher dedans!

Résultats de la recherche pour les enregistrements de fichiers

Après avoir étudié les résultats de la recherche, nous nous concentrons sur les enregistrements de fichiers qui commencent par la signature FILE [1]. Voici la seule entrée de ce type:

Record trouvé

L'objectif est déjà proche! Nous avons un dossier, mais nous avons besoin de données. Dans NTFS, ils sont stockés dans l'attribut $ DATA, qui peut être résident ou non-résident [2]. Pour l'enregistrement que nous avons trouvé, cet attribut commence à l'offset 0 × 3AADD00 et indique des données non résidentes (cela signifie que les informations sont stockées en dehors de l'enregistrement de fichier).

Alors, où sont exactement les données du fichier souhaité? Pour répondre à cette question, il est nécessaire de décoder les soi-disant paires de mappage, ou séries de données (paires «longueur de bloc - décalage de bloc») [3]. Les exécutions de données du fichier souhaité sont les suivantes (notez le décalage 0 × 3AADD40): 22 53 01 A0 4E 21 05 31 C1 11 38 30 00. Ou, si nous les réorganisons:

1.	22 53 01 A0 4E
2.	21 05 31 C1
3.	11 38 30 00

Le fichier se compose de trois fragments, la taille du premier est de 339 clusters, et il commence par le cluster # 20128. Pour notre code utilisant PBKDF2, cet extrait est volumineux. Comme indiqué dans l'en-tête du système de fichiers, la taille d'un cluster est de 4096 octets:

$ fsstat -o 2048 ntfs_volume.raw | grep 'Cluster Size'
Cluster Size: 4096

Jetons un coup d'œil aux données pour ce décalage (en octets):
2048 * 512 + 20128 * 4096 = 83492864. Nous allons extraire toute quantité importante d'informations (par exemple, 128 octets) d'ici, l'insérer dans un nouveau fichier, que nous appellerons key.bin, exécuter le script ... Rien n'a réussi.

Peut-être que le fichier n'était pas stocké dans la version actuelle, mais dans la version précédente du système de fichiers (formatage précédent) - n'oubliez pas que nous n'avons pas vu l'enregistrement du fichier supprimé du même nom. Quelle était la taille du cluster auparavant? Cherchons l'en-tête du système de fichiers avec la signature NTFS [4]. Peut-être que nous avons de la chance et que nous trouvons vraiment l'en-tête du formatage précédent.

Résultats de la recherche pour l'en-tête du système de fichiers

Les première et dernière positions dans les résultats de la recherche se réfèrent au système de fichiers actuel, mais les en-têtes du système de fichiers situés entre eux semblent appartenir à la mise en forme précédente. Et ils ont une taille de cluster différente!

En-tête du système de fichiers de la version précédente.

Une telle taille de secteur est écrite avec un décalage de 0 × 4554800B: 00 02 ou 512. Mais une telle taille de cluster est enregistrée avec un décalage de 0 × 0x4554800D: F7 ou 247.

Donc, nous avons la taille du cluster (en octets) 512 * 247 = 126464. Une sorte de non-sens! Si vous croyez l'analyseur NTFS [5], une telle valeur doit avoir un signe et être traitée d'une manière spéciale, donc la taille réelle du cluster (en secteurs) est 1 << - (- 9) = 512. Ou, si en octets, 512 * 512 = 262144 Semble maintenant plus crédible.

Les données commencent ici à ce décalage (en octets):
2048 * 512 + 20128 * 262144 = 5277483008. Essayons à nouveau de faire la même astuce avec les informations qui y sont stockées ... Encore une fois, un échec! Qu'est-ce qui ne va pas? Nous avons le FCT ici, cela signifie «pas si» que tout peut être.

La tâche sur laquelle nous nous battons s'appelle In the Shadows. Il est possible que cela ait quelque chose à voir avec les clichés instantanés du volume. Nous avons donc un fichier du système de fichiers qui existait auparavant dans ce volume. Malheureusement, nous ne pouvons tout simplement pas prendre et monter son cliché instantané, mais nous connaissons le décalage exact auquel les données commencent! Il s'agit de 5277483008 ou, à l'intérieur de la section, 5277483008 - 2048 * 512 = 5276434432.

Selon les spécifications du format VSS [6], les blocs de données redirigés sont décrits dans la structure du descripteur de bloc contenant un champ 64 bits dans lequel le décalage d'origine (à l'intérieur du volume) est stocké, et également un champ de 64 bits décrivant le décalage du bloc cible (à l'intérieur du volume). Cherchons 5276434432 comme un petit nombre endian 64 bits.

Il n'y a que deux résultats dans les résultats, et un seul d'entre eux est situé à un décalage pair.

Descripteur de bloc trouvé

Décalage du bloc cible: 00 00 9B 03 00 00 00 00, ou simplement 60489728. Décalage final: 60489728 + 2048 * 512 = 61538304. À partir d'ici, exportez une certaine quantité de données vers un nouveau fichier nommé key.bin, et ...

$ ./decrypt_flag.py
ctfzone{my_c0ngr4t5_t0_u,w311_d0n3_31337}

Terminé!

Wright dans l'ombre

Références

More articles: