3DS Userland Flaws

Revision as of 18:13, 15 March 2015 by Yellows8 (talk | contribs)

This page lists vulnerabilities / exploits for 3DS applications and applets. Exploiting these initially results in ROP.

Non-system applications

Application name Summary Description Fixed in version Last 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 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 March 11, 2015 Around October 22, 2012 Yellows8

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

System applets