3DS Userland Flaws

This page lists vulnerabilities / exploits for 3DS applications and applets. Exploiting these initially results in ROP, from that ROP one can then for example try exploiting system flaw(s).

Non-system applications

Application name	Summary	Description	Fixed in app/system version	Last app/system version this flaw was checked for	Timeframe info related to this was added to wiki	Timeframe this vuln was discovered	Vuln discovered by
Cubic Ninja	Map-data stack smash	See here regarding Ninjhax.	None	App: Initial version. System: 9.7.0-25.	Ninjhax release	July 2014	smea
The Legend of Zelda: Ocarina of Time 3D	UTF-16 name string buffer overflow via unchecked u8 length field	The u8 at offset 0x2C in the savefile is the character-length of the UTF-16 string at offset 0x1C. When copying this string, it's essentially a memory-copy with lenval*2, not a string-copy. This can be used to trigger buffer overflows at various locations depending on the string length. When value is >=0x6E it crashes when saving the saveslot, this causes a stack-smash however it normally crashes before it returns from the function which had the stack-frame overwritten. With value >=0x9A, it crashes via stack-smash in-game once any dialogs are opened(touching buttons on the touch-screen can trigger it too). Length value>=0xCD causes a crash while loading the saveslot, via a heap buffer overflow. This buf-overflow overwrites a heap memchunk following the allocated buffer. When the first 16-bits overwriting that heap memchunk is not the memchunk magic-number(0x7373), the mem-alloc code will just return a NULL ptr which later results in a crash. When the magic-number is valid, the mem-alloc code will continue to attempt to parse the memchunk, which may crash depending on the data which overwrote the memchunk. This heap code is separate from the CTRSDK heap code. Exploiting this doesn't seem to be possible: since the heap code actually verifies that the magic-number for the next/prev memchunk ptrs are correct(unlike CTRSDK), it's not possible to change those ptrs to useful arbitrary addresses outside of savedata(like with triggering a write to a c++ object ptr which later is used with a vtable func-call, this is what one would do with CTRSDK heap here). On March 11, 2015, an exploit using this vuln was released, that one was intended for warez/etc. The following exploit wasn't released before then mainly because doing so would (presumably) result in the vuln being fixed. The following old exploit was released on March 14, 2015: [1].	None	App: Initial version. System: 9.7.0-25.	March 11, 2015	Around October 22, 2012	Yellows8

Useless crashes

• Pushmo (3DSWare), QR codes: level name is properly limited to 16 characters, game doesn't crash with a longer name. The only possible crashes are triggered by out-of-bounds array index values, these crashes are not exploitable due to the index value being 8bit.

• Pyramids (3DSWare), QR codes: no strings. Only crashes are from out-of-bounds values (like background ID) and are not exploitable.

System applications

Summary	Description	Fixed in version	Last version this flaw was checked for	Timeframe this was discovered	Discovered by
3DS System Settings DS profile string stack-smash	Too long or corrupted strings (01Ah 2 Nickname length in characters 050h 2 Message length in characters) in the NVRAM DS user settings (System Settings->Other Settings->Profile->Nintendo DS Profile) cause it to crash in 3DS-mode due to a stack-smash. The DSi is not vulnerable to this, DSi launcher(menu) and DSi System Settings will reset the NVRAM user-settings if the length field values are too long(same result as when the CRCs are invalid). TWL_FIRM also resets the NVRAM user-settings when the string-length(s) are too long.	7.0.0-13	7.0.0-13	2012	Ichfly
Webkit bugs	spider has had at least three different code-execution exploits. Majority of them are use-after-free issues.			2013?	A lot of people.

System applets

Useless crashes

• 3DS browser, 2^32 characters long string: this is similar to the vulnerability fixed here, concat-large-strings-crash2.html triggers a crash which is about the same as the one triggered by a 2^32 string. Most of the time this vulnerability will cause a memory page permissions fault, since the WebKit code attempts to copy the string text data to the output buffer located in read-only CRO heap memory. The only difference between a crash triggered by a 2^32 string and the concat-large-strings-crash2.html crash is at the former copies the string data using the original string length(like 1 text character for "x", 4 for "xxxx") while the latter attempts to copy >12MB. In some very rare cases a thread separate from the string data-copy thread will crash, this might be exploitable. However, this is mostly useless since it rarely crashes this way.