Défi : Solution pour « Memgraph Capture The Flag » – Découvrir

Le défi « Memgraph Capture the Flag » vous invite à apprendre et à pratiquer le débogage et la symbolisation de la mémoire avec des outils en ligne de commande. Si vous n’avez pas encore essayé le défi ou si vous ne voulez pas être gâté dans les étapes nécessaires pour le relever, nous vous recommandons de revenir à la page du défi d’origine. Sinon, continuez à lire !

Défi : Memgraph capture le drapeau

Le défi commence par ce qui suit : « L’un de nos ingénieurs a caché un œuf de Pâques de la mémoire dans notre application secrète. Nous essayons de le suivre, mais tout ce que nous savons, c’est qu’il a un format flag_<unknown_string_here>@WWDC. Vous devrez utiliser les outils de ligne de commande fournis par macOS pour enquêter sur le problème de mémoire, récupérer les symboles manquants et capturer le drapeau malveillant. “

La solution suivante est l’une des manières possibles de capturer le drapeau. Pour commencer, l’article du défi fournit un memgraph et un fichier dSYM, ainsi que l’astuce suivante : « Memgraph est un plist binaire spécial. Que pouvez-vous trouver sur vos propriétés? “

Pour voir les propriétés d’un Memgraph, utilisez plutil. A la sortie, vous trouverez d’autres astuces :

$ plutil -p secret.memgraph
...
"hint" => "the flag is hiding in a memory leak"
...
"one_more_hint" => "you might also want to explore the 'symbols' in the dSYM”
...

L’indice vous invite à enquêter sur la fuite de mémoire, tandis que one_more_hint vous encourage directement à utiliser le symbols Outil CLI. Dans la session WWDC21 « Symbolisation : au-delà des bases », l’ingénieur Alejandro Lucena mentionne que c’est une bonne idée de spécifier l’architecture avec cet outil. Vous pouvez donc utiliser le memgraph pour connaître l’architecture « secrète » de l’application.

tu peux essayer heap, leaks ou alors vmmap. Lorsqu’il est utilisé avec un memgraph, les premières lignes sont les mêmes dans la sortie de chacun de ces outils. Voici comment vous apprenez quelle architecture le processus “secret” utilise : Code Type: X86-64.

Comme détaillé dans la section WWDC21 « Détecter et diagnostiquer les problèmes de mémoire », vous pouvez utiliser la commande vmmap sur les fichiers memgraph, en plus de diriger le processus en cours. L’exécuter sur ce memgraph fournit les informations suivantes :

$ vmmap -summary secret.memgraph 
Process:         secret [2901]
Path:            /Users/*/secret
Load Address:    0x10d264000
Identifier:      secret
Version:         0
Code Type:       X86-64
Platform:        macOS
Parent Process:  zsh [1438]
...

Vous êtes maintenant prêt à utiliser le symbols commander. Utilisez le -noSources option pour restreindre la sortie aux noms de symboles afin que vous ayez moins de sortie à examiner. Caché parmi les symboles du dSYM “secret”, vous trouverez un autre chemin vers la solution :

$ symbols -arch x86_64 -noSources secret.dSYM [macOS Monterey+, Xcode 13+]
or
$ symbols -arch x86_64 -noSources secret.dSYM/Contents/Resources/DWARF/secret [macOS before Monterey, Xcode before 13]
...
hint_find_the_secret_addresses_of_the_memory_leak
...

La mémoire divulguée dans ce memgraph commence définitivement à sembler intéressante – il s’agit probablement d’une adresse de fuite spécifique. Voyons à quelle adresse secrète le conseil fait référence. Pour déterminer si l’application “secrète” fuyait de la mémoire, vous pouvez vérifier le memgraph pour les fuites avec le leaks outil de ligne de commande.

Vous voudrez faire attention à cette partie de la sortie :

$ leaks secret.memgraph
...
STACK OF 5 INSTANCES OF 'ROOT LEAK: <CFArray>':
6   hint                               0x7fff204edf3d how would you translate secret Addresses TO Symbols? + 1
5   secret                                0x10d267ee8 0x10d264000 + 16104
4   secret                                0x10d267dc5 0x10d264000 + 15813
3   secret                                0x10d267ccf 0x10d264000 + 15567
2   com.apple.CoreFoundation           0x7fff2059576f __CFArrayCreateInit + 190
1   com.apple.CoreFoundation           0x7fff2054df07 _CFRuntimeCreateInstance + 587
0   libsystem_malloc.dylib             0x7fff20314071 _malloc_zone_malloc + 242 
...

Dans cette sortie, vous identifierez cinq fuites, toutes provenant du même endroit dans le code. Ils sont joints par la même trace de la pile d’appels à chaque fois qu’un CFArray a été alloué mais n’a jamais été publié. Vous trouverez ici trois adresses secrètes – 0x10d267ee8, 0x10d267dc5 et 0x10d267ccf – avec une nouvelle astuce avec quelques majuscules intéressantes. Cet indice suggère que vous devriez essayer d’utiliser atos outil pour symboliser les adresses secrètes.

Appeler atos, vous avez besoin de plusieurs composants : Le binaire DWARF en dSYM, l’architecture et les adresses à symboliser. Cependant, il vous manque l’adresse de chargement et vous pouvez la trouver pour l’image binaire “secrète” dans la pile d’appels de fuites à côté des trois adresses secrètes : 0x10d264000. Vous pouvez également le trouver dans la description du processus et dans la liste des portions d’images binaires du leaks sortir:

$ leaks secret.memgraph
Process:         secret [2901]
Path:            /Users/*/secret
Load Address:    0x10d264000
...
Binary Images:
       0x10d264000 -        0x10d267ff7 +secret (0) <6676D338-8C26-3019-B919-88C1CB4AA324> /Users//secret
...

Vous pouvez maintenant utiliser atos pour traduire des adresses secrètes en symboles :

$ atos -o secret.dSYM/Contents/Resources/DWARF/secret -arch x86_64 -l 0x10d264000 0x10d267ee8 0x10d267dc5 0x10d267ccf
main (in secret) (main.m:226)
very_nice_function (in secret) (main.m:205)
good_job_but_the_flag_is_inlined (in secret) (main.m:186)

Vous vous en approchez : le drapeau est intégré, vous devez donc ajouter le -i option de ligne de commande à l’appel atos pour afficher également les fonctions intégrées :

$ atos -o secret.dSYM/Contents/Resources/DWARF/secret -arch x86_64 -l 0x10d264000 0x10d267ee8 0x10d267dc5 0x10d267ccf -i
main (in secret) (main.m:413)

very_nice_function (in secret) (main.m:392)

IGZsYWdfbWVNMHJ5VDBPTHNEZWJ1R0cxbmdQcjBAV1dEQyAg (in secret) (main.m:86)
whats_wrong_with_encoding (in secret) (main.m:204)
omg_you_found_it (in secret) (main.m:333)
good_job_but_the_flag_is_inlined (in secret) (main.m:373)

Plus près encore ! Exécutez cette commande et vous obtiendrez une chaîne sans signification qui semble être encodée en base64. Exécutez ce décodage et vous obtiendrez :

$ echo "IGZsYWdfbWVNMHJ5VDBPTHNEZWJ1R0cxbmdQcjBAV1dEQyAg" | base64 -d
 flag_meM0ryT0OLsDebuGG1ngPr0@WWDC  %

Remarque : assurez-vous également de passer le -arch drapeau pour atos, Pourquoi atos la valeur par défaut est l’architecture que vous utilisez activement. Par exemple, si vous exécutez cette commande depuis x86_64 (sur le matériel x86 ou Rosetta 2), vous ne verrez aucun changement. Mais si vous exécutez l’outil sur une machine Apple Silicon sans le -arch flag, vous obtiendrez des chaînes livrées à la mauvaise architecture :

IOKdmuKWiOKVkOKVkOKWiOKdmiAg4p2a4paI4pWQ4pWQ4paI4p2a (in secret) (main.m:396)
IOKWhyDiloUg4paIIOKWhSDilocg4paCIOKWgyDiloEg4paB (in secret) (main.m:381)

Convertissez-les à partir de votre encodage base64 et vous obtiendrez de très bons poids d’art ASCII.

❚█══█❚ ❚█══█❚

▇ ▅ █ ▅ ▇ ▂ ▃ ▁ ▁

Bien qu’ils puissent être utiles pour remplir les anneaux de conditionnement de votre Apple Watch, vous avez besoin du -arch x86_64 paramètre pour capturer ce drapeau spécifique.

Un dernier conseil : le secret.memgraph a été généré lors de l’exécution du processus “secret” avec MallocStackLogging activé ; cela vous permet de voir la pile d’appels de la fuite. N’oubliez pas d’activer MallocStackLogging pour votre propre application lors de la génération de memgraphs. Cela peut être fait dans les paramètres du schéma dans Xcode (Run > Diagnostics > MallocStackLogging = Live Allocations Only) ou avec la variable d’environnement lors du démarrage à partir d’un terminal :

`$ MallocStackLogging=lite <command>`

Ce n’est qu’une façon d’obtenir le drapeau à l’aide des outils de ligne de commande intégrés à macOS pour le débogage et la symbolisation de la mémoire. Consultez le référentiel complet des défis de codage et de conception pour d’autres explorations amusantes de codage et de conception, ou approfondissez le débogage avec nos dernières vidéos WWDC21.

Ressources

Explorez plus de défis de codage et de conception