{"id":125200,"date":"2021-08-10T16:00:54","date_gmt":"2021-08-10T16:00:54","guid":{"rendered":"https:\/\/developer.apple.com\/news\/?id=3st92oup"},"modified":"2021-08-10T16:00:54","modified_gmt":"2021-08-10T16:00:54","slug":"challenge-solution-to-memgraph-capture-the-flag","status":"publish","type":"post","link":"https:\/\/sickgaming.net\/blog\/2021\/08\/10\/challenge-solution-to-memgraph-capture-the-flag\/","title":{"rendered":"Challenge: Solution to \u201cMemgraph Capture The Flag\u201d"},"content":{"rendered":"
\"Flag<\/div>\n

The \u201cMemgraph Capture the Flag\u201d challenge invites you to learn and practice memory debugging and symbolication with command line tools. If you haven\u2019t yet attempted the challenge or otherwise don\u2019t want to be spoiled on the necessary steps to complete it, we recommend returning to the original challenge page. Otherwise, read on!<\/p>\n

Challenge: Memgraph Capture the Flag<\/a><\/p>\n

The challenge begins with the following: \u201cOne of our engineers has hidden a memory easter egg in our secret app. We’re trying to track it down but all we know is that it has format flag_<unknown_string_here>@WWDC<\/code>. You\u2019ll have to use the command line tools offered by macOS to investigate the memory issue, recover missing symbols, and and capture the rogue flag.\u201d<\/p>\n

The following solution is one of the possible paths to capture the flag. To start, the challenge article supplies you with a memgraph file and a dSYM, along with the following hint: \u201cMemgraph is a special binary plist. What can you find in its properties?\u201d<\/p>\n

To look at the properties of a Memgraph, use plutil<\/code>. In the output, you\u2019ll find more hints:<\/p>\n

$ plutil -p secret.memgraph\n... \"hint\" => \"the flag is hiding in a memory leak\"\n... \"one_more_hint\" => \"you might also want to explore the 'symbols' in the dSYM\u201d\n...<\/code><\/pre>\n
The hint invites you to investigate the memory leak, while one_more_hint<\/code> directly encourages you to use the symbols<\/code> CLI tool. In the WWDC21 session \u201cSymbolication: Beyond the basics,\u201d engineer Alejandro Lucena mentions that it\u2019s a good idea to specify the architecture with this tool. As such, you can use the memgraph to learn the \u201csecret\u201d app\u2019s architecture.<\/p>\n
You can try heap<\/code>, leaks<\/code> or vmmap<\/code>. When used with a memgraph, the first few lines are the same in the output of each of these tools. This is how you learn which architecture the \u201csecret” process uses: Code Type: X86-64<\/code>.<\/p>\n
As detailed in the WWDC21 session \u201cDetect and diagnose memory problems,\u201d you can use the vmmap command against memgraph files in addition to targeting the running process. Running it agaisnt this memgraph provides the following information: <\/p>\n
$ vmmap -summary secret.memgraph Process: secret [2901]\nPath: \/Users\/*\/secret\nLoad Address: 0x10d264000\nIdentifier: secret\nVersion: 0\nCode Type: X86-64\nPlatform: macOS\nParent Process: zsh [1438]\n...<\/code><\/pre>\n
Now you\u2019re ready to use the symbols<\/code> command. Use the -noSources<\/code> option to restrict the output to symbol names so you have less output to look through. Hidden amidst the symbols in the \u201csecret\u201d dSYM, you\u2019ll find another breadcrumb towards the solution:<\/p>\n
$ symbols -arch x86_64 -noSources secret.dSYM [macOS Monterey+, Xcode 13+]\nor\n$ symbols -arch x86_64 -noSources secret.dSYM\/Contents\/Resources\/DWARF\/secret [macOS before Monterey, Xcode before 13]\n...\nhint_find_the_secret_addresses_of_the_memory_leak\n...<\/code><\/pre>\n
The leaked memory in this memgraph is definitely starting to sound interesting \u2014 it\u2019s probably a specific leaked address. Let\u2019s see which secret addresses the hint is referring to. To determine if the \u201csecret\u201d app was leaking memory, you can check the memgraph for leaks with the leaks<\/code> command line tool.<\/p>\n
You\u2019ll want to pay attention to this portion of the output: <\/p>\n
$ leaks secret.memgraph\n...\nSTACK OF 5 INSTANCES OF 'ROOT LEAK: <CFArray<\/span>><\/span>':\n6 hint 0x7fff204edf3d how would you translate secret Addresses TO Symbols? + 1\n5 secret 0x10d267ee8 0x10d264000 + 16104\n4 secret 0x10d267dc5 0x10d264000 + 15813\n3 secret 0x10d267ccf 0x10d264000 + 15567\n2 com.apple.CoreFoundation 0x7fff2059576f __CFArrayCreateInit + 190\n1 com.apple.CoreFoundation 0x7fff2054df07 _CFRuntimeCreateInstance + 587\n0 libsystem_malloc.dylib 0x7fff20314071 _malloc_zone_malloc + 242 ...<\/code><\/pre>\n
In this output, you\u2019ll spot five leaks, all of which originated from the same place in code. They are united by the same call stack backtrace each time a CFArray<\/code> was allocated, but never freed. You\u2019ll find three secret addresses here \u2014 0x10d267ee8<\/code>, 0x10d267dc5<\/code> and 0x10d267ccf<\/code> \u2014 along with a new hint sporting some interesting capitalization. This clue hints that you should try and use atos<\/code> tool to symbolicate the secret addresses.<\/p>\n
To call atos<\/code>, you need several components: The DWARF binary in the dSYM, architecture, and addresses to symbolicate. You\u2019re missing the load address, however, and can find it for the \u201csecret\u201d binary image within the call stack of the leaks next to all three secret addresses: 0x10d264000<\/code>. You can also find it in the the process description and list of binary images portions of the leaks<\/code> output:<\/p>\n
$ leaks secret.memgraph\nProcess: secret [2901]\nPath: \/Users\/*\/secret\nLoad Address: 0x10d264000\n...\nBinary Images: 0x10d264000 - 0x10d267ff7 +secret (0) <6676D338-8C26-3019-B919-88C1CB4AA324> \/Users\/\/secret\n...<\/code><\/pre>\n
Now, you can use atos<\/code> to translate the secret addresses to symbols:<\/p>\n
$ atos -o secret.dSYM\/Contents\/Resources\/DWARF\/secret -arch x86_64 -l 0x10d264000 0x10d267ee8 0x10d267dc5 0x10d267ccf\nmain (in secret) (main.m:226)\nvery_nice_function (in secret) (main.m:205)\ngood_job_but_the_flag_is_inlined (in secret) (main.m:186)<\/code><\/pre>\n
You\u2019re getting close: The flag is inlined, so you need to add the -i<\/code> command line option while calling atos<\/code> to display the inlined functions too:<\/p>\n
$ atos -o secret.dSYM\/Contents\/Resources\/DWARF\/secret -arch x86_64 -l 0x10d264000 0x10d267ee8 0x10d267dc5 0x10d267ccf -i\nmain (in secret) (main.m:413) very_nice_function (in secret) (main.m:392) IGZsYWdfbWVNMHJ5VDBPTHNEZWJ1R0cxbmdQcjBAV1dEQyAg (in secret) (main.m:86)\nwhats_wrong_with_encoding (in secret) (main.m:204)\nomg_you_found_it (in secret) (main.m:333)\ngood_job_but_the_flag_is_inlined (in secret) (main.m:373)<\/code><\/pre>\n
Closer still! Run this command and you\u2019ll get a string of gibberish that looks like it might be base64-encoded. Run that decode and you get:<\/p>\n
$ echo \"IGZsYWdfbWVNMHJ5VDBPTHNEZWJ1R0cxbmdQcjBAV1dEQyAg\" | base64 -d flag_meM0ryT0OLsDebuGG1ngPr0@WWDC %<\/code><\/pre>\n
As a note: Make sure you also pass the -arch<\/code> flag to atos<\/code>, because atos<\/code> defaults to the architecture you’re actively using. For example, if you run this command from x86_64<\/code> (either on x86 hardware or in Rosetta 2), you won’t see any change. But if you run the tool from an Apple Silicon machine without the -arch<\/code> flag, you’ll get strings delivered for the wrong architecture: <\/p>\n
IOKdmuKWiOKVkOKVkOKWiOKdmiAg4p2a4paI4pWQ4pWQ4paI4p2a (in secret) (main.m:396)\nIOKWhyDiloUg4paIIOKWhSDilocg4paCIOKWgyDiloEg4paB (in secret) (main.m:381)<\/code><\/pre>\n
Convert those from their base64 encoding, and you’ll get some very pretty ASCII art weights. <\/p>\n
\u275a\u2588\u2550\u2550\u2588\u275a \u275a\u2588\u2550\u2550\u2588\u275a \u2587 \u2585 \u2588 \u2585 \u2587 \u2582 \u2583 \u2581 \u2581<\/code><\/pre>\n
While these might be helpful for filling the fitness rings on your Apple Watch, you need the -arch x86_64<\/code> parameter to capture this particular flag.<\/p>\n
One last tip: The secret.memgraph was generated when the \u201csecret\u201d process was running with MallocStackLogging<\/code> enabled; this allows you to see the call stack of the leak. Don\u2019t forget to enable MallocStackLogging<\/code> for your own app when generating memgraphs. This can be done in the scheme settings in Xcode (Run > Diagnostics > MallocStackLogging = Live Allocations Only) or with the environment variable when launching from a terminal:<\/p>\n
`$ MallocStackLogging=lite <command<\/span>><\/span>`<\/code><\/pre>\n
\n
This is just one path you can follow to get the flag using the command line tools built into macOS for memory debugging and symbolication. Check out the full repository of Coding and Design Challenges for other fun coding and design explorations, or dive deeper into debugging with our most recent WWDC21 videos.<\/p>\n
Resources<\/h3>\n
\n
\n
   <\/a> <\/section>\n
  <\/p>\n
Symbolication: Beyond the basics<\/h4>\n
 <\/a> <\/section>\n<\/section>\n<\/section>\n
\n
\n
   <\/a> <\/section>\n
  <\/p>\n
Detect and diagnose memory issues<\/h4>\n
 <\/a> <\/section>\n<\/section>\n<\/section>\n
Explore more coding & design challenges<\/a><\/p>\n","protected":false},"excerpt":{"rendered":"
The \u201cMemgraph Capture the Flag\u201d challenge invites you to learn and practice memory debugging and symbolication with command line tools. If you haven\u2019t yet attempted the challenge or otherwise don\u2019t want to be spoiled on the necessary steps to complete it, we recommend returning to the original challenge page. Otherwise, read on! Challenge: Memgraph Capture […]<\/p>\n","protected":false},"author":2,"featured_media":125201,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[55],"tags":[],"class_list":["post-125200","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-apple-developer-news"],"_links":{"self":[{"href":"https:\/\/sickgaming.net\/blog\/wp-json\/wp\/v2\/posts\/125200","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/sickgaming.net\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/sickgaming.net\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/sickgaming.net\/blog\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/sickgaming.net\/blog\/wp-json\/wp\/v2\/comments?post=125200"}],"version-history":[{"count":0,"href":"https:\/\/sickgaming.net\/blog\/wp-json\/wp\/v2\/posts\/125200\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/sickgaming.net\/blog\/wp-json\/wp\/v2\/media\/125201"}],"wp:attachment":[{"href":"https:\/\/sickgaming.net\/blog\/wp-json\/wp\/v2\/media?parent=125200"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/sickgaming.net\/blog\/wp-json\/wp\/v2\/categories?post=125200"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/sickgaming.net\/blog\/wp-json\/wp\/v2\/tags?post=125200"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}