10
edits
Changes
Jump to navigation
Jump to search
mLine 47:
Line 47: − + − + Line 57:
Line 57: − + Line 85:
Line 85: − + − During the very first screen displayed by the game during boot("Loading..."), just seconds after title launch, the game loads CTPK from the [[BOSS_Services|stored]] SpotPass content. Hence, this game could be exploited via the vulnerable CTRSDK CTPK code ''if'' one could get custom SpotPass data into extdata somehow.+ − + − The two SpotPass URLs for this have always(?) returned HTTP 404 as of November 2016. It appears these were intended for use as textures for additional costumes(and never got used publicly), but this wasn't tested.+ Line 97:
Line 97: + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Line 108:
Line 254: − + − + Line 121:
Line 267: + + + + + + + + + + Line 145:
Line 301: + + + + + + + Line 181:
Line 344: + + + + + + + + + + + + + + + + + + + + Line 196:
Line 379: − + − After successfully loading [[Extended_Banner|extended-banner]] data(done when selecting an icon), Home Menu attempts to load [[CBMD]] data into a 0x100000-byte heap buffer from the [[BOSS_Services|stored]] SpotPass content. When successful and the magic-number is CBMD, Home Menu then decompresses the CGFX sections into another fixed-size heap buffer, without checking the outsize at all. The main CBMD CGFX code with ExeFS checks the size, but this code doesn't.+ − | None+ − +
→Useless crashes / applications which were fuzzed
| Pokemon Super Mystery Dungeon
| Pokemon Super Mystery Dungeon
| Heap overflow within linear memory via unchecked save file length
| Heap overflow within linear memory via unchecked save file length
| Pokemon Super Mystery Dungeon uses zlib compression for most of its save files, possibly due to the save files being larger than it's predecessor, Gates to Infinity. When a save file is being prepared to be loaded and read from, only a 0x32000 large buffer is allocated for file reading, and a 0x3e800-large buffer for decompression is also allocated before the file is read. However, the game does not limit the size of the file read to this allocation bound, allowing for the file to overflow into the linear memory heap and into the next allocation. Since Pokemon Super Mystery Dungeon stores allocation memchunks directly before the allocation, overwriting the next memchunk with a corrupted one allows for arbitrary writes of linear heap pointers when the next buffer is allocated or arbitrary writes of any pointer within writable memory when the corrupted buffer is freed.
| Pokemon Super Mystery Dungeon uses zlib compression for most of its save files, possibly due to the save files being larger than its predecessor, Gates to Infinity. When a save file is being prepared to be loaded and read from, only a 0x32000 large buffer is allocated for file reading, and a 0x3e800-large buffer for decompression is also allocated before the file is read. However, the game does not limit the size of the file read to this allocation bound, allowing for the file to overflow into the linear memory heap and into the next allocation. Since Pokemon Super Mystery Dungeon stores allocation memchunks directly before the allocation, overwriting the next memchunk with a corrupted one allows for arbitrary writes of linear heap pointers when the next buffer is allocated or arbitrary writes of any pointer within writable memory when the corrupted buffer is freed.
| None
| None
| [[10.7.0-32]].
| O3DS: [[11.3.0-36]]. N3DS: [[11.4.0-37]].
| Time of exploit release.
| Time of exploit release.
| April 14, 2016
| April 14, 2016
| Buffer overflow in XML save file array parsing
| Buffer overflow in XML save file array parsing
| VVVVVV utilizes several XML files (renamed with a .vvv extension) to store level save data, stats and settings. Within these XML files are several tags containing an array of data which, when parsed, is not properly checked to be of proper length for the tag being parsed from. This allows for an overflow of 16-bit array values from the location where the array is parsed. With unlock.vvv, XML data is parsed to the stack, and with level saves the heap. This allows for the pointer where the level save worldmap tag array should be parsed into to be overwritten with a stack address, allowing for ROP from within the XML array parsing function on the next level load.
| VVVVVV utilizes several XML files (renamed with a .vvv extension) to store level save data, stats and settings. Within these XML files are several tags containing an array of data which, when parsed, is not properly checked to be of proper length for the tag being parsed from. This allows for an overflow of 16-bit array values from the location where the array is parsed. With unlock.vvv, XML data is parsed to the stack, and with level saves the heap. This allows for the pointer where the level save worldmap tag array should be parsed into to be overwritten with a stack address, allowing for ROP from within the XML array parsing function on the next level load.
| None
| App: v1.1
| [[10.7.0-32]].
| [[10.7.0-32]].
| Time of exploit release.
| Time of exploit release.
| The Legend of Zelda: Tri Force Heroes
| The Legend of Zelda: Tri Force Heroes
| [[3DS_System_Flaws#General.2FCTRSDK|CTRSDK]] CTPK buffer overflow combined with game's usage of SpotPass
| [[3DS_System_Flaws#General.2FCTRSDK|CTRSDK]] CTPK buffer overflow combined with game's usage of SpotPass
| This isn't really useful due to [[BOSS_Services#Custom_SpotPass_content|this]].
| During the very first screen displayed by the game during boot("Loading..."), just seconds after title launch, the game loads CTPK from the [[BOSS_Services|stored]] SpotPass content. Hence, this game could be exploited via the vulnerable CTRSDK CTPK code ''if'' one could get custom SpotPass data into extdata somehow(ctr-httpwn >=v1.2 with bosshaxx allows this).
The code for this runs from a thread separate from the main-thread, with the stack in linearmem heap. This SpotPass handling triggers before the game ever opens the regular savedata archive. The extdata is opened at some point before this: it opens a file for checking if it exists, then immediately closes it.
The code for this runs from a thread separate from the main-thread, with the stack in linearmem heap.
The two SpotPass URLs for this have always(?) returned HTTP 404 as of November 2016. It appears these were intended for use as textures for additional costumes(and never got used publicly), but this wasn't tested.
This is used by [https://github.com/yellows8/ctpkpwn ctpkpwn_tfh].
| None
| None
| App: v2.1.0
| App: v2.1.0
| November 14, 2016
| November 14, 2016
| [[User:Yellows8|Yellows8]]
| [[User:Yellows8|Yellows8]]
|-
| Pixel Paint
| Buffer overflow via unchecked extdata file length
| Pixel Paint loads pictures saved by the user from extdatas. The file is read to a fixed size buffer but the file length remains unchecked, so with a large enough file, one can overwrite pointers in memory and gain control of the execution flow.
| None
| App: Initial version. System: [[11.2.0-35]].
| December 27, 2016
| November 5, 2016
| [[User:Nba_Yoh|MrNbaYoh]]
|-
| Steel Diver : Sub Wars
| Heap overflow / arbitrary memcpy
| Savefile datas are stored as key/value pairs, a large enough string key makes the game overwrite a memcpy source/destination addresses and size arguments. So one can actually memcpy a rop on the stack and gain control of the execution flow.
| None
| System: [[11.2.0-35]].
| December 27, 2016
| Around July 15, 2016
| [[User:Nba_Yoh|MrNbaYoh]], Vegaroxas
|-
| 1001 Spikes
| Buffer overflow via unchecked array-indexes in XML savefile parsing
| The savefiles are stored as renamed .xml files, which contain several tags with attributes like 'array-index="array-value"', where both of these are converted from ASCII strings to integers as signed-int32, and the array-value given blindly written to an array inside a structure using the (unchecked) index given. With several of these attributes, one can overwrite the stack starting from the stored lr of the function that does this parsing, and write a ROP chain there. Testing used the "LevelAttempts" tag which is the last such tag parsed in that function.
| None
| App: v1.2.0 (TMD v2096)
| December 27, 2016
| Around November 2, 2016
| [[User:Riley|Riley]]
|-
| Pokemon Omega Ruby/Alpha Sapphire
| Secret base team name heap overflow
| When the player wants to edit the team name, it is copied over the heap, however its length is not verified. So with a large enough team name one can overwrite some pointers and get two arbitrary jumps and then get control of the execution flow.
| None
| App: 1.4. System: [[11.2.0-35]].
| December 30, 2016
| June, 2016
| [[User:Nba_Yoh|MrNbaYoh]]
|-
| Swapdoodle
| Heap buffer overflow via unchecked size
| The letter file format used by doodlebomb is composed of multiple chunks. Each chunks is described in the header of the file where the name, size and CRC of each chunk are stored. Some chunks are meant to be headers, every header's size should be 0x80, however the length of the STAHED1 chunk remains unchecked and the game memcpy the chunk to a 0x80 byte buffer with the length provided in the file. This way one is able to overwrite some pointers and get control of the execution flow.
| App: > v1.1.1
| App: v1.1.1
| April 24, 2017
| February, 2017
| [[User:Nba_Yoh|MrNbaYoh]]
|-
| Pokemon Picross
| Arbitrary memcpy via unchecked size
| When reading the savefile, the game handles some lists of buffers that are copied to memory. These buffers should always be 0x14-bytes long but the game uses the size provided in the savefile to copy them. These buffers are copied in some structs and thus with a big enough length value, one can overwrite the next struct which contains a size and a destination address for a memcpy.
| None?
| App: ?
| May 29, 2017
| June, 2016
| [[User:Nba_Yoh|MrNbaYoh]]
|-
| RPG Maker Fes/Player
| Buffer overflow on .bss section
| When loading a project, the game copies multiple chunks over the BSS section. However the number of chunks to copy is not checked, thus a large amount of chunk result in a buffer overflow. There's multiple way to exploit this flaw to gain an arbitrary memcpy or an arbitrary jump.
| None?
| App: ?
| August 28, 2017
| August, 2017
| [[User:Nba_Yoh|MrNbaYoh]]
|-
| RPG Maker Fes/Player
| Buffer overflow via unchecked file size
| When loading a project, the game loads the file to a 0x200000 bytes long buffer. However the size remains unchecked, so with a big enough file one can overflow the buffer and overwrite a thread stack and then achieve ROP.
| None?
| App: ?
| August 29, 2017
| August, 2017
| [[User:Nba_Yoh|MrNbaYoh]]
|-
| Pokemon Omega Ruby/Alpha Sapphire
| PSS data heap/stack overflow
| When launching the game, multiple chunks from the save file are parsed and copied to a large heap buffer. When parsing PSS data (acquaintances, passerby) the game copies each entry to the heap buffer, the number of entries to copy is read from the end of the multiple pss data chunks and is not checked, leading to an overflow. The "PSS data - friends" chunk is vulnerable too, but the overflow occurs on the stack and unfortunately this isn't exploitable because of a 4 bytes uncontrolled value (in each entry) that gets written on sensitive data.
| None
| App: 1.4. System: [[11.6.0]].
| October 1, 2017
| June, 2016
| [[User:Nba_Yoh|MrNbaYoh]]
|-
| RPG Maker Fes/Player
| OOB write
| When handling events in a map, the indices of "buttons" are not checked. This results in an out of bound bit write, one can thus write a rop directly on the stack (bit by bit).
| None?
| App: ?
| August 5, 2018
|
| [[User:Nba_Yoh|MrNbaYoh]]
|-
| Unholy Heights
| Buffer overflow via unchecked string size
| The game stores some utf-16 messages in the savefile. Right before the message is the length(u32) for the string, the game uses this size to memcpy the message from the savefile to the stack without checking the length. This allows one to overwrite some function addresses on the stack and form a rop chain.
| None
| App: Initial Version
| September 13, 2018
| August, 2018
| Kartik
|}
==Flipnote Studio 3D==
{| class="wikitable" border="1"
|-
! Summary
! Description
! Fixed in app/system version
! Timeframe info related to this was added to wiki
! Flaw discovered by
|-
| KFH frame count overflow
| The KFH frame count field should not be >= 0x3E8, but it wasn't checked and so uncontrolled data were written over pointers, causing an unexploitable crash.
| System: 11.6
| September 20, 2017
| [[User:Nba_Yoh|MrNbaYoh]]
|-
| KMI paper color overflow
| Paper color field (and similar color fields) in KMI chunks was not checked, a too high value caused a jump to an uncontrolled location.
| System: 11.6
| September 20, 2017
| [[User:Nba_Yoh|MrNbaYoh]]
|-
| KSN BGM data size overflow
| The size of the BGM data in the KSN chunk was not checked, it was used in a memcpy so with a big enough size one could overwrite a thread stack on linear mem and achieve ROP (notehax v1).
| System: 11.6
| September 20, 2017
| [[User:Nba_Yoh|MrNbaYoh]]
|-
| KMC chunk unchecked
| The KMC chunk was not verified at all, the CRC32 and the size were not checked. A big enough size caused an integer overflow and made the game read the file backward.
| System: 11.6
| September 20, 2017
| [[User:Nba_Yoh|MrNbaYoh]]
|-
| KMI layer size unchecked
| The 3 layer size fields in KMI chunks were not checked, leading to some crashes in the editor.
| System: 11.6
| September 20, 2017
| [[User:Nba_Yoh|MrNbaYoh]]
|-
| Bad "queue" implementation
| When a KWZ was parsed, frames were copied in a kind of queue, bounds were not checked obviously, so with the KMI layer size flaw one was able to fill completely the queue, then write past the buffer and overwrite a heap chunk header (notehax v2). This is not possible anymore, the queue cannot be filled because layer sizes are checked. Moreover each time an element is removed from the queue, the whole content is memmoved *facepalm*.
| System: 11.6
| September 20, 2017
| [[User:Nba_Yoh|MrNbaYoh]]
|}
|}
* [https://github.com/yellows8/mm3d_re The Legend of Zelda: Majora's Mask 3D]
* [https://github.com/yellows8/mm3d_re The Legend of Zelda: Majora's Mask 3D]
* "The Legend of Zelda: A Link Between Worlds" and "The Legend of Zelda: Tri Force Heroes": these games don't crash at all when the entire save-file(minus constant header data) is overwritten with /dev/random output / 0xFF-bytes. All of the CRC32s were updated for this of course.
* "The Legend of Zelda: A Link Between Worlds" and "The Legend of Zelda: Tri Force Heroes": these games don't crash at all when the entire save-file(minus constant header data) is overwritten with /dev/random output / 0xFF-bytes. All of the CRC32s were updated for this of course. Note that this refers to the regular save file: Tri Force Heroes can be exploited via BOSS extdata - see above.
* Pokemon Mystery Dungeon: Gates to Infinity has the same unchecked file bounds as Pokemon Super Mystery Dungeon, however since save compression was introduced in Pokemon Super Mystery Dungeon, it only allocates one buffer within the application heap instead of several within the linear heap, resulting in nothing to corrupt or overwrite even if the file's length is extended past it's allocation.
* Pokemon Mystery Dungeon: Gates to Infinity has the same unchecked file bounds as Pokemon Super Mystery Dungeon, however since save compression was introduced in Pokemon Super Mystery Dungeon, it only allocates one buffer within the application heap instead of several within the linear heap, resulting in nothing to corrupt or overwrite even if the file's length is extended past its allocation.
* "Kid Icarus: Uprising": Overwriting the entire savedata results in various crashes, nothing useful.
* "Kid Icarus: Uprising": Overwriting the entire savedata results in various crashes, nothing useful.
* "Mutant Mudds": Overwriting the savefile with random data results in a crash
* "Mutant Mudds": Overwriting the savefile with random data results in a crash
* "Worcle Worlds": Overwriting the savefile with 0xFF results in a crash due to an out of bound read
* "Animal Crossing: New Leaf": Creating a QR code from random data results in a valid QR code and a random design. In some very rare cases(which aren't always reproducible?) a crash/etc may occur, but this isn't known to be useful.
* "Animal Crossing: New Leaf": Creating a QR code from random data results in a valid QR code and a random design. In some very rare cases(which aren't always reproducible?) a crash/etc may occur, but this isn't known to be useful.
* "Angry Birds Star Wars": Strings in the savefile are preceded by their lengths. These strings are never stored on the stack and are memcpy'd into heap memory. If the size is invalid the alloc will fail and thus the memcpy will operate on a nullptr resulting in a useless data abort.
* "Gem Smashers": Overwriting the savefile with random bytes results in useless crashes.
* "Luxor:" Strings/plaintext in the savefile are present and these's no checks. Overwriting the whole save (excluding the header), with /dev/random cause a useless crash.
* "Luv Me Buddies Wonderland:" Doesn't crash at all with the entire savedata overwritten. Overwriting some areas, points to useless nulls
==Crashes needing investigation==
==Crashes needing investigation==
| 2012
| 2012
| [[User:Ichfly|Ichfly]]
| [[User:Ichfly|Ichfly]]
|-
| [[Nintendo 3DS Sound]]
| When a .m4a is loaded, the song name is copied to a 256 byte buffer. When the song name begins with a Unicode BOM marker, it memcpy's the tag using the user-provided length. This gives an arbitrary write which can be used to achieve ROP.
| [[11.4.0-37]]
| [[11.4.0-37]]
| June/July 2016
| [[User:nedwill|nedwill]]
|}
|}
| November 2, 2015 (Exactly one week after the browser version pages were initially updated server-side)
| November 2, 2015 (Exactly one week after the browser version pages were initially updated server-side)
| [[User:Yellows8|Yellows8]]
| [[User:Yellows8|Yellows8]]
|-
| Skater - Bookmark OOB write
| Each bookmark has an id that should not exceed 0x63 (99), however ids are not checked, this results in an OOB write on the stack, but only the value 0x01 can be written.
|
| [[11.6.0-39|11.6.0-39]]
|
| May 21, 2018
| May 20, 2018
| [[User:Nba_Yoh|MrNbaYoh]]
|-
| MicroSD Management - malformed security blob causes stack buffer overflow (mhax)
| The MicroSD Management application's parsing of Windows NTLM security blobs in the SMB/CIFS protocol doesn't verify that the client's specified NT domain name is less than 32 UTF-16 characters. When it's longer, a stack buffer overrun occurs, leading to a ROP chain and complete control of the mcopy application.
The malformed security blob can be sent by an attacker within the SMB_COM_SESSION_SETUP_ANDX (0x73) packet.
| [[11.8.0-41|11.8.0-41]]
| [[11.8.0-41|11.8.0-41]]
| [[9.0.0-20|9.0.0-20]]
| August 12, 2018
| 2018
| smea
|}
|}
|-
|-
| bossbannerhax
| bossbannerhax
| This isn't really useful due to [[BOSS_Services#Custom_SpotPass_content|this]].
| After successfully loading [[Extended_Banner|extended-banner]] data(done when selecting an icon), Home Menu attempts to load "[[CBMD]]" data into a 0x100000-byte heap buffer from the [[BOSS_Services|stored]] SpotPass content. When successful and the magic-number is CBMD, Home Menu then decompresses the exbanner sections into another fixed-size heap buffer, without checking the outsize at all. The main CBMD CGFX code with ExeFS checks the size, but this code doesn't(however this is exbanner "CBMD", not a "normal" CBMD).
Used with menuhax as of v3.2.
| [[11.3.0-36|11.3.0-X]]
| [[11.2.0-35|11.2.0-X]]
|
| [[1.0.0-0|1.0.0-0]]
| [[1.0.0-0|1.0.0-0]]
| November 18, 2016
| November 18, 2016