Difference between revisions of "3DS Userland Flaws"
Jump to navigation
Jump to search
(→Non-system applications: Besides the other changes, moved CN-vuln entry since that's newer.) |
|||
Line 25: | Line 25: | ||
| UTF-16 name string buffer overflow via unchecked u8 length field | | 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. | | 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: [https://github.com/yellows8/oot3dhax]. | 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: [https://github.com/yellows8/oot3dhax]. |
Revision as of 18:13, 15 March 2015
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.
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 |