ninjhax is the name I gave to the solution I released back in November 2014 to allow users to run homebrew software on their 3DS/2DS/New 3DS with the (at the time) latest firmware version. Because the 9.3 firmware update patched a critical exploit used in this solution and Gateway recently made available a warez-ready solution exploiting the other critical vulnerability used by ninjhax, I’ve decided now’s as good a time as any to share the technical details.
The full source code can be found here.
Let’s get started. ninjhax works in 4 stages and almost as many exploits : we first get ROP execution, then we get code execution proper, then we get access to new services by launching and taking over another process, and then we get higher privileges by exploiting a system module.
Stage 1 : Getting ROP under Cubic Ninja (aka ninjhax proper)
Description : Cubic Ninja (a game published by Ubisoft) contains a level editor. User-made levels can be saved to the gamecard’s save partition and shared with other users through QR codes (and, in the japanese version, streetpass). Once the encryption and compression (blowfish and some lz variant, respectively) schemes are understood, it is possible to generate your own custom level QR codes which the game will read.
Problem : the format that the levels are stored in contains variable-length elements. When parsed, those elements are routinely loaded to fixed-size buffers located on the stack, with the length of the elements in question left unchecked. Of course, this leads to a trivially-exploitable stack smash, which gives us ROP capabilities. It should be noted that the entire level file is loaded to the heap beforehand and that there is no limit to level file size, making it extremely convenient. Worse still, it is possible to trigger the exact same crash with a forged QR code.
Limitations : this gives us ROP capabilities, not code execution, as the 3DS’s OS strictly enforces NX (ie executable memory pages are never writable).Additionally, QR codes can’t have an unlimited size, and the stack isn’t huge either. We overcome the first limitation with stage 2 and the second one by downloading a secondary payload through the http:C service, and then saving that payload to the savegame. Another thing to take into account is that Cubic Ninja does not have either SDMC or ldr:ro access (see stage 4 for why the latter matters).
Fix : fixing this with the game’s source code should be trivial; just add a few well placed size checks. Fixing it without the source code (which might be necessary given how the studio went under ?) would be more difficult. It shouldn’t be hard to write a piece of code that will scan the savegame to check that the .map files located under the /edit/ directory are sane; however, that would not be enough as the QR code reading would still be exploitable. With that in mind, it might be possible to hack up the game’s compiled code to prevent the crash, though the solution won’t be pretty.
To be more precise, the problem seems to lie mainly with the function located at 0x001F5F38 (in EU/US version, haven’t checked JPN). This function seems designed to copy data a packed structure to some external buffer. It takes as arguments a pointer to the source-data struct (R0), a pointer to the destination buffer (R1) and the size of the destination buffer (R2); it fails if the input data is bigger than the output buffer. This makes it seem safe ! However, it includes a “backdoor” : when R2 is 0, there are no checks made on the input data size. Unfortunately, this R2 = 0 backdoor is used throughout the game’s code, often with stack buffers, making it very unsafe. The good news is that it’s possible that by patching the code to specify a proper R2, the crash will be fixed. Unfortunately the code usually does not seem to check for errors output by function 0x001F5F38, so that might not quite be enough, but it’d be a start.
Relevant snippet : https://gist.github.com/smealum/008e24537ddde7db528c
Stage 2 : Getting code execution through unsafe GPU DMA (aka gspwn, gpuhax)
Description : the 3DS’s GPU is capable of accessing certain sections of memory with reading and writing capabilities. These regions include VRAM and parts of FCRAM. This is used for a number of things, including commands which let us use the GPU to copy data across memory regions through the GSP module, reading texture/vertex object data, or writing to the framebuffer when rendering.
Problem : while the GPU having access to these regions of memory isn’t necessarily an issue, the fact that GSP doesn’t do *any* checks on input/output addresses for GPU commands it processes definitely is. The GPU has read/write access to the entire 0×20000000-0×26800000 memory range (on old 3DS; iirc the new 3DS range is 0×20000000-0x2D000000 which basically gives the same results), and it is therefore possible to access those regions by using GX commands 2, 3 and 4. This “thankfully” leaves out the BASE memory region at the end of FCRAM (intentional ?), but still opens the door to easily obtainable code execution as well as other types of attacks (time of use/time of check comes to mind).
Limitations : while this lets us execute native code by overwriting the currently running application’s .text region, it doesn’t immediately let us do much more. Every other currently running application has its .text hidden away in the 0×26800000+ memory region, including home menu.
Fix : the fix for this is, interestingly enough, both trivial and fairly elaborate. The thing to see here is that there are (at least) three ways of exploiting this :
- GX commands : this is the easiest one to fix; it can be done by simply adding checks to the handlers for commands 2, 3 and 4. I’m not entirely sure if the kernel provides an easy way to validate that an address is within a given process’s LINEAR heap, but if not something for that should be added.
- WriteHWRegs/WriteHWRegsWithMask : it’s possible to manually mimick the sequence of register reads/writes used by GX command handlers from a usermode application. This means that the above fixes can be bypassed fairly easily. Therefore, similar fixes should be added to the handlers for those service commands when writing to certain registers.
- Rendering : this is the tricky one. The first time I exploited this vulnerability, I did so by rendering a scene with the framebuffer set to output to my application’s .text region. To prevent this, it would be necessary to scan GPU command buffers sent with GX commands 1 and 5 for framebuffer setting GPU commands. This can be tricky to do for a number of reasons I won’t be going into here.
Relevant snippet :
;copy code to GSP heap (for VA -> PA translation and dcache flushing) .word 0x001bbeb8 ; pop {r3, pc} .word 0x002c9628 ; r3 (pop {r0, pc}) .word 0x00106eb8 ; pop {r4, lr} | bx r3 .word 0xDEADC0DE ; r4 (garbage) .word 0x002c9628 ; lr (pop {r0, pc}) ;equivalent to .word 0x002c9628 ; pop {r0, pc} .word CN_CODELOCATIONGSP ; r0 (dst) .word 0x00226734 ; pop {r1, pc} .word CN_CODELOCATIONVA ; r1 (src) .word 0x0020b8e8 ; pop {r2, r3, r4, pc} .word codePatchEnd-codePatch ; r2 (size) .word 0xDEADC0DE ; r3 (garbage) .word 0xDEADC0DE ; r4 (garbage) .word 0x00224FB0 ; memcpy (ends in BX LR) ;flush data cache ;equivalent to .word 0x002c9628 ; pop {r0, pc} .word CN_GSPHANDLE_ADR ; r0 (handle ptr) .word 0x00226734 ; pop {r1, pc} .word 0xFFFF8001 ; r1 (kprocess handle) .word 0x0020b8e8 ; pop {r2, r3, r4, pc} .word CN_CODELOCATIONGSP ; r2 (address) .word 0x00010000 ; r3 (size) .word 0xDEADC0DE ; r4 (garbage) .word CN_GSPGPU_FlushDataCache_ADR+4 ; GSPGPU_FlushDataCache (ends in LDMFD SP!, {R4-R6,PC}) .word 0xDEADC0DE ; r4 (garbage) .word 0xDEADC0DE ; r5 (garbage) .word 0xDEADC0DE ; r6 (garbage) ;send GX command .word 0x002c9628 ; pop {r0, pc} .word 0x356208+0x58 ; r0 .word 0x00226734 ; pop {r1, pc} .word CN_HEAPPAYLOADADR+gxCommand-ROP ; r1 (cmd addr) .word CN_nn__gxlow__CTR__CmdReqQueueTx__TryEnqueue+4 ; nn__gxlow__CTR__CmdReqQueueTx__TryEnqueue (ends in LDMFD SP!, {R4-R8,PC}) ; got this method name from symbols left over in a game btw, i do not have the SDK .word 0xDEADC0DE ; r4 (garbage) .word 0xDEADC0DE ; r5 (garbage) .word 0xDEADC0DE ; r6 (garbage) .word 0xDEADC0DE ; r7 (garbage) .word 0xDEADC0DE ; r8 (garbage) ;sleep for a second and jump to code .word 0x00226734 ; pop {r3, pc} .word 0x002c9628 ; r1 (pop {r0, pc}) .word 0x0012ec64 ; pop {r4, lr} | bx r1 .word 0xDEADC0DE ; r4 (garbage) .word 0x002c9628 ; lr (pop {r0, pc}) ;equivalent to .word 0x002c9628 ; pop {r0, pc} .word 0x3B9ACA00 ; r0 = 1 second .word 0x00226734 ; pop {r1, pc} .word 0x00000000 ; r1 .word 0x00293D14 ; svcSleepThread (ends in BX LR) ;equivalent to .word 0x002c9628 ; pop {r0, pc} .word 0x00000000 ; r0 (time_low) .word 0x00226734 ; pop {r1, pc} .word 0x00000000 ; r1 (time_high) .word 0x002D9700 ;jump to code .word 0xBEEF0000 endROP: .align 4 gxCommand: .word 0x00000004 ; SetTextureCopy .word CN_CODELOCATIONGSP ; source .word CN_GSPHEAP+CN_TEXTPAOFFSET+0x001D9700 ; destination .word 0x00010000 ; size .word 0xFFFFFFFF ; dim in .word 0xFFFFFFFF ; dim out .word 0x00000008 ; flags .word 0x00000000 ; unused .align 4 codePatch: .incbin "cn_initial/cn_initial.bin" ; our initial code .word 0xDEADDEAD .word 0xDEADDEAD .word 0xDEADDEAD .word 0xDEADDEAD codePatchEnd:
Stage 3 : getting access to more services and SDMC by taking over spider/SKATER (aka spiderto/SKATERto)
Description : the 3DS runs a fully multitasking OS which is able to execute applets simultaneously to the main application. These applets include the home menu and the web browser (aka spider on the 3DS, and SKATER on the New 3DS). It is possible to launch such an applet from any usermode app through APT commands.
Problem : while system applets such as spider usually keep their .text in the 0×26800000+ region, they use a heap to store information, including stacks for secondary threads. This heap is below the cutoff for FCRAM GPU DMA access. This allows us to takeover that thread using GPU DMA and some neat timing tricks. From there we can takeover spider’s main thread, and use that to run the next stage, all through ROP. From there, we use NS:SendParameter to give Cubic Ninja spider’s ro and fs session handles.
Limitations : this only gives us ROP execution under spider/SKATER, not actual code execution.
Fix : N/A
Relevant snippet :
// we use GSP access rights as a synchronization method // we know home menu will wait until it has the rights to do anything, so we first release the rights // BUT we also know that spider will do the same, so we get in line to grab the rights right afterwards // this way, we'll have spider hanging at a known point in code and we can take it over more easily _GSPGPU_ReleaseRight(*gspHandle); //disable GSP module access _aptOpenSession(); ret=_APT_PrepareToStartSystemApplet(aptuHandle, APPID_WEB); _aptCloseSession(); drawTitleScreen("running exploit... 000%"); _aptOpenSession(); ret=_APT_StartSystemApplet(aptuHandle, APPID_WEB, &buf, 0, 0); _aptCloseSession(); drawTitleScreen("running exploit... 020%"); svc_sleepThread(100000000); //sleep just long enough for menu to grab rights _GSPGPU_AcquireRight(*gspHandle, 0x0); //get in line for gsp rights //need to sleep longer on 4.x ? svc_sleepThread(1000000000); //sleep long enough for spider to startup //read spider memory { _GSPGPU_FlushDataCache(gspHandle, 0xFFFF8001, (u32*)0x14100000, 0x00000200); doGspwn((u32*)(SPIDER_HOOKROP_PADR-0x0C000000), (u32*)0x14100000, 0x00000200); } svc_sleepThread(1000000); //sleep long enough for memory to be read //patch memdump and write it { ((u8*)0x14100000)[0x14]=0xFF; memcpy(((u8*)(0x14100000+SPIDER_HOOKROP_OFFSET)), spider_hook_rop_bin, 0xC); _GSPGPU_FlushDataCache(gspHandle, 0xFFFF8001, (u32*)0x14100000, 0x00000200); doGspwn((u32*)0x14100000, (u32*)(SPIDER_HOOKROP_PADR-0x0C000000), 0x00000200); } svc_sleepThread(100000000); { memset((u8*)0x14100000, 0x00, 0x2000); memcpy((u8*)0x14100000, spider_initial_rop_bin, spider_initial_rop_bin_size); _GSPGPU_FlushDataCache(gspHandle, 0xFFFF8001, (u32*)0x14100000, 0x1000); doGspwn((u32*)0x14100000, (u32*)(SPIDER_INITIALROP_PADR-0x0C000000), 0x1000); } svc_sleepThread(100000000); { memset((u8*)0x14100000, 0x00, 0x2000); memcpy((u8*)0x14100000, spider_thread0_rop_bin, spider_thread0_rop_bin_size); _GSPGPU_FlushDataCache(gspHandle, 0xFFFF8001, (u32*)0x14100000, 0x2000); doGspwn((u32*)0x14100000, (u32*)(SPIDER_THREAD0ROP_PADR-0x0C000000), 0x2000); } svc_sleepThread(100000000);//sleep long enough for memory to be written _aptOpenSession(); _APT_CancelParameter(aptuHandle, APPID_WEB); _aptCloseSession(); (...) drawTitleScreen("running exploit... 040%"); _GSPGPU_ReleaseRight(*gspHandle); //disable GSP module access svc_sleepThread(100000000); //sleep just long enough for spider to grab rights _GSPGPU_AcquireRight(*gspHandle, 0x0); //get in line for gsp rights drawTitleScreen("running exploit... 070%"); //getting rights means spiderto was successful
Stage 4 : getting access to privileged syscalls by taking over ro, a sysmodule, from spider/SKATER (aka rohax)
Description : the 3DS runs a system module named “ro” (for relocatable object probably ?) which allows users to load and run dynamically linked code (“CROs”). These CROs are most commonly stored directly in romfs and are checked with a central CRR file which is signed and contains hashes for each CRO file in the application. The CRR’s signature is checked once when that file is loaded, and then each CRO’s integrity is checked by comparing it against the corresponding hash stored in the CRR file. CRO files contain a list of patches which must be applied to the code being loaded so that it can be relocated. The ro system module has access to a number of high-privilege system calls which, among other things, allow it to give regions of memory executable status within its own virtual memory space as well as other processes’.
Problem : using GPU DMA, we are able to modify the loaded CRR file’s hash list *after* the signature check has occured. This, in turn, lets us load arbitrary unsigned CRO files. It is then possible for us to manufacture a custom CRO which will use the relocation patch list to patch ro’s stack, give us ROP capabilities within ro and use that to get ro code execution using SVC 0×70. This is not supposed to be possible as relocation patches can only be within CRO segments, and CRO segments are checked to be within CRO memory when first parsed, which is great. However, what we can do is extend one of the CRO segments to include the CRO segment table (which is within the CRO itself, not copied elsewhere for actual use), then use our first relocation patch to extend a CRO segment to include the stack, and then use subsequent CRO patches to write our ROP chain to the stack.
Limitations : getting code execution in ro is great because it gives us access to svcControlProcessMemory, which lets us map memory as executable within other processes. It also allows us to modify other processes’ memory using svcMapProcessMemory. That being said, we can’t do that with just any other process (like, ideally, loader…) as we need a handle for that other process, and ro does not have access to svcOpenProcess. Therefore, we only use our code execution capabilities within ro to remap memory within Cubic Ninja.
Fix : this was fixed in 9.3 by adding a bunch of (apparently) proper bound checks to ro’s various commands. I haven’t looked into it myself but I’ve been assured it’s pretty much airtight.
Summary
- ninjhax => Cubic Ninja ROP
- Cubic Ninja ROP => gpuhax => Cubic Ninja code execution
- Cubic Ninja code execution => gpuhax => spiderto => spider ROP
- spider ROP => rohax => ro code execution (ro becomes “hb” custom service handler)
- ro code execution => spider code execution => Cubic Ninja code execution with memory remapping and basic cache management capabilities, as well as access to sdmc and a bunch of new services
