{"id":20,"date":"2023-08-10T04:40:25","date_gmt":"2023-08-10T04:40:25","guid":{"rendered":"https:\/\/nocoffei.com\/?p=20"},"modified":"2023-09-17T16:41:40","modified_gmt":"2023-09-17T16:41:40","slug":"a-ctf-challenge-using-the-nintendo-3ds-unique-features","status":"publish","type":"post","link":"https:\/\/nocoffei.com\/?p=20","title":{"rendered":"A CTF Challenge using the Nintendo 3DS\u2019 unique features"},"content":{"rendered":"\n

Or, how to make your CTF challenge much<\/em> harder than intended. This long-form article describes an unusual challenge I wrote last year.<\/p>\n\n\n\n

This blog post was originally written for ReSwitched Weekly Reboot<\/a>, but that site didn\u2019t take off.<\/p>\n\n\n\n

If you attended a certain hackathon late last year, you might have noticed a challenge listed like this:<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

You\u2019re given an ELF file and a mysterious \u201cfile.bin\u201d. What wonders lie within?<\/p>\n\n\n\n

Apparently, it\u2019s a stripped 32-bit ARM binary. Let\u2019s open it up in our favorite decompiler and\u2026<\/p>\n\n\n\n

\"An<\/figure>\n\n\n\n

First Steps<\/h2>\n\n\n\n

Let\u2019s revisit those hints:<\/p>\n\n\n\n

> Looks like he left some logs at key intersections... Installing devkitARM may prove beneficial.<\/code><\/pre>\n\n\n\n
The challenges target platform has already been spoiled by the title, but if one looked it up they\u2019d find that devkitARM is a complete toolchain for Nintendo handheld consoles, including the GBA, DS, and 3DS.<\/p>\n\n\n\n
As for those logs\u2026 It\u2019s probably meant that \u201ckey intersections\u201d means critical sections of the program flow. For the first of these, we can immediately see that \u201cromfs:\/file.bin\u201d is an argument to a function. That means it\u2019s fopen<\/code>, and that the return value is a file pointer\u2026 We\u2019ll come back to that shortly.<\/p>\n\n\n\n
GX_DisplayTransfer<\/code> sounds like the name of the previous function. Plug that into our search engine and we get linked directly to some documentation<\/a>. Looks like the function is from libctru, which is the user-mode library for writing useful homebrew on the 3DS<\/a>. Now what\u2019s that function do\u2026?<\/p>\n\n\n\n
> Initiates a display transfer.<\/code><\/p>\n\n\n\n
Well, that\u2019s not very helpful, but this is a \u201ckey intersection\u201d, so it\u2019s probably really important to understand this function.<\/p>\n\n\n\n
By finding an example<\/a> online (I\u2019m linking to one I found randomly), and searching 3dbrew<\/a>, a knowledge base of 3DS reverse engineering, then reading between the lines, one can determine that this is a DMA copy function.<\/p>\n\n\n\n
DMA on the 3DS<\/h2>\n\n\n\n
Those familiar with computer architecture will know that a DMA engine is, in brief terms, an auxiliary device that can transfer large amounts of data without the CPUs involvement, freeing it up to perform more useful work. On the 3DS, the DMA engine is treated as part of the GPU, and is commonly used to upload textures to VRAM quickly.<\/p>\n\n\n\n
With that in mind, we can revisit the documentation and example, and this \u201ckey intersection\u201d makes a little more sense. The code leading up to this block opens romfs:\/file.bin, which we can safely assume is the same file.bin we were provided. We can see that a value is read out of the file object, passed into another function, then that value is passed into another function twice. The results of those functions are then the input and output addresses of the DMA transfer, implying that everything just mentioned was memory allocation. Let\u2019s make some changes to the decompiled function with that in mind\u2026<\/p>\n\n\n\n