3dbrew - User contributions [en]

3DS Userland Flaws

2016-01-19T02:53:20Z

Thedax:

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 [[3DS_System_Flaws|system]] flaw(s).

=Non-system applications=
{| class="wikitable" border="1"
|-
! 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 [[Ninjhax|here]] regarding Ninjhax.
| None
| App: Initial version. System: [[10.3.0-28]].
| Ninjhax release
| July 2014
| [[User:smea|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: [https://github.com/yellows8/oot3dhax].
| None
| App: Initial version. System: [[10.4.0-29]].
| March 11, 2015
| Around October 22, 2012
| [[User:Yellows8|Yellows8]]
|-
| Super Smash Bros 3DS
| Buffer overflow in local-multiplayer beacon handling.
| See [[smashbroshax|here]].
| None
| See [[smashbroshax|here]]. System: [[10.3.0-28]].
| Time of exploit release.
| See [[smashbroshax|here]].
| [[User:Yellows8|Yellows8]]
|}

==Useless crashes / applications which were fuzzed==
* 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.

* [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.

=System applications=
{| class="wikitable" border="1"
|-
! 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
| [[User:Ichfly|Ichfly]]
|}

=System applets=
{| class="wikitable" border="1"
|-
! Summary
! Description
! Fixed in version
! Last version this flaw was checked for
! Timeframe this was discovered
! Discovered by
|-
| [[Home Menu]] [[System_SaveData|NAND-savedata]] Launcher.dat icons
| The homemenu code processing the titleid list @ launcherdat+8 copies those titleIDs to another buffer, where the offset relative to that buffer is calculated using the corresponding s8/s16 entries. Those two values are not range checked at all. Hence, one can use this to write u64(s) with arbitrary values to before/after this allocated output buffer. See [[Home_Menu|here]] regarding Launcher.dat structure.

This can be exploited(with Launcher.dat loading at startup at least) by using a s16 for the icon entry with value 0xFFEC(-20)(and perhaps more icons with similar s16 values to write multiple u64s). The result is that the u64 value is written to outbuf-0xA0, which overwrites object+0(vtable) and object+4(doesn't matter here) for an object that gets used a bit after the vulnerable function triggers. The low 32bits of the u64 can then be set to the address of controlled memory(either outbuf in regular heap or the entire launcherdat buffer in linearmem), for use as a fake vtable in order to get control of PC. From there one can begin ROP via vtable funcptrs to do a stack-pivot(r4=objectaddr at the time the above object gets used).

Originally this vuln could only be triggered via Launcher.dat at Home Menu startup, right after Launcher.dat gets loaded + memory gets allocated, once the file-format version code is finished running. Starting with v9.6 this can be triggered when loading layouts from SD extdata as well. The vuln itself triggers before the layout data is written to Launcher.dat, but it doesn't seem to be possible to overwrite anything which actually gets used before the function which writes Launcher.dat into the layout gets called.

Home Menu has some sort of fail-safe system(or at least on v9.7) when Home Menu crashes due to Launcher.dat(this also applies for other things with Home Menu): after crashing once, Home Menu resets Launcher.dat to a state where it no longer crashes anymore. However, note that any exploits using this which hang/etc without crashing will still brick the system. '''Hence, attempting anything with this on physnand without hw-nand-access isn't really recommended.'''
| None
| [[10.3.0-28|10.3.0-X]]
| May 14, 2015
| [[User:Yellows8|Yellows8]]
|-
| [[Home Menu]] theme-data decompression buffer overflow ([[menuhax|themehax]])
| The only func-call size parameter used by the theme decompression function is one for the compressed size, none for the decompressed size. The decompressed-size value from the LZ header is used by this function to check when to stop decompressing, but this function itself has nothing to verify the decompressed_size with. The code calling this function does not check or even use the decompressed size from the header either.

This function is separate from the rest of the Home Menu code: the function used for decompressing themes is *only* used for decompressing themes, nothing else. There's a separate decompression function in Home Menu used for decompressing everything else.

That other decompression function in Home Menu handles decompression size properly(decompressed size check for max buffer size is done by code calling the other function, not in the function itself). Unlike the other function, the theme function supports multiple LZ algorithms, but the one which actually gets used in official themes is the same one supported by the other function anyway.

See also [[menuhax|here]].

With [[10.2.0-28|10.2.0-X]] Home Menu, the only code change was that the following was added right after theme-load and before actual decompression: "if(<get_lzheader_decompressed_size>(compressed_buf) > 0x150000)<exit>;". This fixed the vuln.
| [[10.2.0-28|10.2.0-X]]
| [[10.2.0-28|10.2.0-X]]
| December 22, 2014
| [[User:Yellows8|Yellows8]], [[User:Myria|Myria]] independently (~spring 2015)
|-
| Webkit/web-browser bugs
| spider has had at least three different code-execution exploits. Majority of them are use-after-free issues. See also [[browserhax|here]].
|
|
| 2013?
| A lot of people.
|}

==Useless crashes==
Old3DS system web-browser:
* 2^32 characters long string(still affects latest spider version as of system-version v10.3): this is similar to the vulnerability fixed [http://git.chromium.org/gitweb/?p=external/Webkit.git;a=commitdiff;h=ec471f16fbd1f879cb631f9b022fd16acd75f4d4 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 [[CRO0|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.

* Trying to directly load a page via the browser "URL" option with [https://github.com/yellows8/3ds_browserhax_common webkitdebug] setup, causes a crash to trigger in oss.cro due to an use-after-free being caught with webkitdebug. This is presumably some sort of realloc() issue in the libcurl version used by the <={v10.2-v10.3} browser. This happens with *every* *single* *page* one tries to load via the "URL" option, but not when loading links on the current page, hence this is probably useless. A different use-after-free with realloc triggers with loading any page at all regardless of method too(libcurl probably).

* This WebKit build has ''a lot'' of crash-trigger bugs that only happen with [https://github.com/yellows8/3ds_browserhax_common webkitdebug] completely setup(addr accesses near 0x0), with ''just'' trying to load any page at all.

NWM Services

2015-10-20T05:59:40Z

Thedax: Added an error section with one error.

[[Category:Services]]

These NWM services are used for local-WLAN communications, NWM module handles regular wifi APs as well. These services are used for creating/connecting to networks, and for sending/receiving data over the network etc. NWM module uses the wifi SDIO hardware via the IO registers for this.

=NWM local-WLAN service "nwm::UDS"=
{| class="wikitable" border="1"
|-
! Command Header
! Available since system version
! Description
|-
| 0x00010442
|
| ?
|-
| 0x00020000
|
| ?
|-
| 0x00030000
|
| [[NWMUDS:Shutdown|Shutdown]]
|-
| 0x00040402
|
| ?
|-
| 0x00050040
|
| [[NWMUDS:EjectClient|EjectClient]]
|-
| 0x00060000
|
| ?
|-
| 0x00070080
|
| [[NWMUDS:UpdateNetworkAttribute|UpdateNetworkAttribute]]
|-
| 0x00080000
|
| [[NWMUDS:DestroyNetwork|DestroyNetwork]]
|-
| 0x00090442
|
| ?
|-
| 0x000A0000
|
| [[NWMUDS:DisconnectNetwork|DisconnectNetwork]]
|-
| 0x000B0000
|
| [[NWMUDS:GetConnectionStatus|GetConnectionStatus]]
|-
| 0x000C0000
|
| This writes two output u8 values to cmdreply[2] +0/+1.
|-
| 0x000D0040
|
| [[NWMUDS:GetNodeInformation|GetNodeInformation]]
|-
| 0x000E0006
|
| ?
|-
| 0x000F0404
|
| [[NWMUDS:RecvBeaconBroadcastData|RecvBeaconBroadcastData]]
|-
| 0x00100042
|
| [[NWMUDS:SetBeaconAdditionalData|SetBeaconAdditionalData]]
|-
| 0x00110040
|
| [[NWMUDS:GetApplicationData|GetApplicationData]]
|-
| 0x00120100
|
| [[NWMUDS:Bind|Bind]]
|-
| 0x00130040
|
| [[NWMUDS:Unbind|Unbind]]
|-
| 0x001400C0
|
| [[NWMUDS:RecvBroadcastDataFrame|RecvBroadcastDataFrame]]
|-
| 0x00150080
|
| (u32 unk0, u32 unk1) ?
|-
| 0x00160040
|
| (u8 inputval) ?
|-
| 0x00170182
|
| [[NWMUDS:SendTo|SendTo]]
|-
| 0x00180040
|
| (u16 inputval) ?
|-
| 0x001A0000
|
| [[NWMUDS:GetChannel|GetChannel]]
|-
| 0x001B0302
|
| [[NWMUDS:Initialize|Initialize]]
|-
| 0x001C0040
|
| (u8 inputval) ?
|-
| 0x001D0044
| Unknown, >[[2.0.0-2]]
| [[NWMUDS:BeginHostingNetwork|BeginHostingNetwork]] This appears to be a replacement for the original network-creation command(newer titles don't use the original one anymore).
|-
| 0x001E0084
| Unknown, >[[2.0.0-2]]
| [[NWMUDS:ConnectToNetwork|ConnectToNetwork]] This appears to be a replacement for the original network-connection command(newer titles don't use the original one anymore).
|-
| 0x001F0006
| Unknown, >[[2.0.0-2]]
| [[NWMUDS:DecryptBeaconData|DecryptBeaconData]]
|-
| 0x00200040
| Unknown, >[[2.0.0-2]]
| (u8 inputval) ?
|-
| 0x00210080
| Unknown, >[[2.0.0-2]]
| [[NWMUDS:SetProbeResponseParam|SetProbeResponseParam]]
|-
| 0x00220402
| Unknown, >[[2.0.0-2]]
| [[NWMUDS:ScanOnConnection|ScanOnConnection]]
|-
| 0x00230000
| Unknown, >[[2.0.0-2]]
| This writes an output u16 value to cmdreply[2].
|}

=NWM infrastructure service "nwm::INF"=
{| class="wikitable" border="1"
|-
! Command Header
! Description
|-
| 0x000603C4
| [[NWMINF:RecvBeaconBroadcastData|RecvBeaconBroadcastData]]
|-
| 0x00070742
| [[NWMINF:ConnectToEncryptedAP|ConnectToEncryptedAP]]
|-
| 0x0008....
| [[NWMINF:ConnectToAP|ConnectToAP]]
|}

=NWM socket service "nwm::SOC"=

=NWM service "nwm::SAP"=

=NWM local-WLAN [[StreetPass]] service "nwm::CEC"=
{| class="wikitable" border="1"
|-
! Command Header
! Description
|-
| 0x00060002
| Unknown, called by CECD module, cmdbuf[2] takes an event handle
|-
| 0x000D0082
| [[NWMCEC:SendProbeRequest|SendProbeRequest]]
|}

=NWM service "nwm::EXT"=
{| class="wikitable" border="1"
|-
! Command Header
! Available since system version
! Description
|-
| 0x0001....
| <=[[2.0.0-2]]
| ?
|-
| 0x0002....
| <=[[2.0.0-2]]
| ?
|-
| 0x0003....
| <=[[2.0.0-2]]
| ?
|-
| 0x0004....
| <=[[2.0.0-2]]
| ?
|-
| 0x0005....
| <=[[2.0.0-2]]
| ?
|-
| 0x0006....
| <=[[2.0.0-2]]
| ?
|-
| 0x00070000
| <=[[2.0.0-2]]
| This copies 0x1C-bytes from NWM-module state to the data starting at cmdreply[2].
|-
| 0x00080040
| <=[[2.0.0-2]]
| [[NWMEXT:ControlWirelessEnabled|ControlWirelessEnabled]]
|-
| 0x0009....
| <=[[2.0.0-2]]
| ?
|}

=NWM service "nwm::TST"=

=Local-WLAN=
UDS is used for 3DS<>3DS local-WLAN communications, and for 3DS<>Wii U communications. The latter is mainly only used for multi-player in games.

All UDS local-WLAN communications have the CCMP key for data encryption generated via NWM module. The CCMP key passed to nwm::CEC commands(stored in a 0x44-byte input structure) for [[StreetPass]] is generated by the CECD module. The input data used with [[Process_Services|EncryptDecryptAes]] with [[PSPXI:EncryptDecryptAes|keytype1]] is a MD5 hash over an input passphrase. This input passphrase is fixed for [[Download Play]], it's unique per local-WLAN protocol. The CTR is a MD5 hash over the below 0x10-byte structure. The output from encrypting that data with AES-CTR is the final CCMP key.

==Structure used for generating the CTR for CCMP key generation==
{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
|-
| 0x0
| 0x4
| Local-WLAN communication ID, normally this is: (user_process [[Title_list|uniqueID]] << 8) | val. Where val is 0x10 on retail([[Configuration_Memory|configmem]] UNITINFO bit0 set), 0x90 for devunit. For [[Download Play]], this is always 0x2810 on retail(0x2890 on devunit).
|-
| 0x4
| 0x4
| u32 networkID, randomly-generated when creating the network. The network SSID used when a client connects to the network is sprintf(out, "%08X", networkID).
|-
| 0x8
| 0x6
| Host MAC address.
|-
| 0xE
| 0x2
| ID, for [[Download Play]] this is 0x55.
|}

This data is stored as little-endian.

==CTR used for beacon tags crypto==
{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
|-
| 0x0
| 0x6
| Host MAC address
|-
| 0x6
| 0x4
| wlancommID
|-
| 0xA
| 0x1
| This ID is also stored at offset 0xE in the CTR-generation structure.
|-
| 0xB
| 0x1
| Padding, value zero.
|-
| 0xC
| 0x4
| This is the u32 from offset 0x18 in the network-struct.
|}

This data is stored as little-endian. All data here is all-zero except for the MAC address, when the u8 at offset 0x8 in the network-struct is 0.

==Network structure==
{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
|-
| 0x0
| 0x6
| This is the MAC address of the host. This is all-zero on the host, like with [[NWMUDS:BeginHostingNetwork]].
|-
| 0x8
| 0x1
| This is non-zero when at least one entry is stored in the array under the encrypted beacon data.
|-
| 0xC
| 0x3
| This is the OUI value for use with the beacon tags. Normally this is 001F32.
|-
| 0xF
| 0x1
| OUI type (21/0x15)
|-
| 0x10
| 0x4
| wlancommID
|-
| 0x14
| 0x1
| This ID is also stored at offset 0xE in the CTR-generation structure.
|-
| 0x1C
| 0x1
| ?
|-
| 0x1D
| 0x1
| This is the total number of entries stored under the array in the encrypted beacon data.
|-
| 0x1E
| 0x1
| ?
|-
| 0x1F
| 0x1
| ?
|-
| 0x3F
| 0x1
| Size of additional data. Normally zero.
|-
| 0x40
| 0xC8
| Additional data, if any. Size of the additional data is specified via the u8 at offset 0x3F. This data is not used when the size-field is zero.
|}

This 0x108-byte structure is used for [[NWMUDS:BeginHostingNetwork]], [[NWMUDS:ConnectToNetwork]], etc. This data is stored as big-endian.

== UDS Beacons ==
The UDS host broadcasts a beacon containing at least two Nintendo-vendor tags(tag number 0xDD, see above for the OUI), normally the data stored in these tags are static. The second tag contains the big-endian u32 networkID, used by the clients when connecting to the host and for the above CCMP key generation. The Nintendo-vendor tag(s) following the first two are unique to the process using UDS, these tags are used for broadcasting metadata regarding the host.

A tool for these beacons is available here: [https://github.com/yellows8/ctr-wlanbeacontool]

=== UDS Beacon Tags ===
The following is the structure of each tag, starting at the OUI. The order of the tags is the same as listed below. All data stored under these tags are stored as big-endian.

==== OUI Type 20 ====
{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
|-
| 0x0
| 0x3
| OUI, see above.
|-
| 0x3
| 0x1
| OUI type (20/0x14)
|-
| 0x4
| 0x3
| Sample data: 0a 00 00
|}

Normally the size of this tag(from the tag size field) is 0x07.

==== OUI Type 21 ====
{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
|-
| 0x0
| 0x1F
| This is the network structure starting at offset 0xC, with the first 0x1F-bytes from there.
|-
| 0x1F
| 0x14
| SHA1 hash. When doing the hashing, this hash is cleared to zero. The hash data starts at offset 0x0(OUI), and the size is 0x34 + <value of the u8 at offset 0x33>.
|-
| 0x33
| 0x1
| Size of additional data. Normally zero. When non-zero this additional data is located at offset 0x34.
|}

Normally the size of this tag(from the tag size field) is 0x34.

==== OUI Type 24 ====
{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
|-
| 0x0
| 0x3
| OUI, see above.
|-
| 0x3
| 0x1
| OUI type (24/0x18)
|-
| 0x4
| See below
| Encrypted data
|}

This is the tag0 used with [[NWMUDS:DecryptBeaconData]]. The size of data stored under this tag has a maximum size of 0xFA-bytes, however normally the size is smaller than that. Additional encrypted data, if any, is stored under the below tag1.

==== OUI Type 25 ====
{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
|-
| 0x0
| 0x3
| OUI, see above.
|-
| 0x3
| 0x1
| OUI type (25/0x19)
|-
| 0x4
| See above
| Encrypted data
|}

When this exists in the beacon, this is the tag1 used with [[NWMUDS:DecryptBeaconData]]. The data stored here is the 0xFA-bytes following the previous encrypted data in tag0, for more space for storing the encrypted data.

==== Encrypted beacon data ====
The following structure is for the plaintext version of the encrypted data.

This data is encrypted with AES-CTR, by NWM module in software. The AES key is stored in NWM module itself. See above for the CTR. The size of this encrypted data is 0x12 + (0x1E*val), where val is the u8 from networkstruct offset 0x1D(zero when the u8 at networkstruct offset 0x8 is value zero).

===== Structure =====
{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
|-
| 0x0
| 0x10
| MD5 over the rest of the data following this(plaintext).
|-
| 0x10
| 0x2
| ?
|-
| 0x12
| 0x1E * <total array entries>
| This is an array of entries for each of the devices on this network, the first entry is for the host and the rest is for the client(s).
|}

===== Array entry =====
{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
|-
| 0x0
| 0x18
| This is the first 0x18-bytes of the structure from [[NWMUDS:Initialize|here]].
|-
| 0x18
| 0x4
| ?
|-
| 0x1C
| 0x2
| ?
|}

=Errors=
{| class="wikitable" border="1"
|-
! Error code
! Description
|-
| 0xC8A06C0D
| The operation being performed is already done (e.g., if you run NWMEXT_ControlWirelessEnabled to turn wifi on when it's on already, you can't turn it on again).
|}