Switch System Flaws: Difference between revisions

(10 intermediate revisions by 3 users not shown)

Line 1:

This page is a list of publicly known Switch flaws.

This page is a list of publicly known Switch / Switch 2 (S2) flaws.

= Hardware =

Line 1,116:

| May 4, 2025

| [[User:Yellows8|yellows8]]

|-

| [[SSL_services|ssl]] Certificate verification bypass

| The ssl sysmodule keeps a list of trusted certificates, that are imported by an app with ImportServerPki. During certificate verification, if the certificate that is provided by the server has the same subject key id as a trusted certificate, the certificate is accepted, even if self-signed. A blog post about this vulnerability can be found [https://reversing.live/sslbypass.html here].

| Man-in-the-middle for any connection that uses ImportServerPki.

| [[20.2.0]]

| June 6, 2025

| August 8, 2025

| [https://github.com/kinnay Yannik]

|-

| [[LDN_services|ldn]] AdvertiseData OOB-memcpy with EncryptionType3 (AES-128-GCM) actionframes (ldnhax)

Line 1,140:

Line 1,149:

[21.0.0+] Arrayindex=0 is now used when the input is invalid.

|

| Likely useless, even if reachable?

| [[21.0.0]]

| June 3, 2024 (possibly eariler(?))

| November 14, 2025

| [[User:Yellows8|yellows8]]

|-

| [[Bluetooth_Driver_services|bluetooth]] BSA allowed ATT MTU is too large

| GATT-handler stack buffer overflows with a large input size are only possible if the payload_size (MTU) field in state is large enough. gatt_client_handle_server_rsp/gatt_server_handle_client_req will drop messages where the size is >= payload_size (though unless the request opcode matches certain values it will also send an error-response for invalid-PDU). Both of these handle updating this field when needed, however that's handled properly.

With bluetooth-classic via L2CAP, a hard-coded MTU of 0x205 is sent in the configure request. However the code handling received configure requests will set payload_size to 0x2A0 if no MTU is specified, or the input MTU if it's within range 0x30..0x2A0. Hence, sending data large enough for buffer overflows requires bluetooth-classic via L2CAP + manually sending large ACL data.

[15.0.0+] gatt_l2cif_config_ind_cback which handles the received configure-requests with bluetooth-classic mentioned above, now uses MTU range 0x30..0x205 with the default MTU being 0x205. It is therefore no longer possible to trigger the previously mentioned buffer-overflows with bluetooth-classic.

| Stack buffer overflows in bluetooth-sysmodule due to the allowed MTU for ATT being larger than the stack data.

| [[15.0.0]]

| [[20.0.0]]

| November 2021?

| November 26, 2025

| [[User:Yellows8|yellows8]]

|-

| [[Bluetooth_Driver_services|bluetooth]] BSA gatt_process_prep_write_rsp stack buffer overflow

| BSA gatt_process_prep_write_rsp memcpys to stack without size validation (the input len param which is subtracted to determine the copy-size is also unvalidated). Triggering this is only possible if the system sent ATT_PREPARE_WRITE_REQ, and then received ATT_PREPARE_WRITE_RSP with a large size.

The size used with memcpy is (u16)(insize-4), so when insize is less than 4 the copy size will be {negative value masked to u16}. This will therefore eventually crash when the stacktop is reached during memcpy.

[15.0.0+] Paritially fixed due to corrected MTU handling (doesn't apply to negative-copysize). [21.0.0+] Fully fixed with proper size validation.

| Stack buffer overflow in bluetooth-sysmodule when the required ATT messages are sent/received.

| [[21.0.0]]

| November 2021?

| January 19, 2026

| [[User:Yellows8|yellows8]]

|-

| [[NFC_services|nfc]] Initialize buffer overflow

| All Initialize* cmds for nn::nfc::detail::IUser (nfc:user), nn::nfc::detail::ISystem (nfc:sys), nn::nfp::detail::IUser (nfp:user), nn::nfp::detail::ISystem (nfp:sys), nn::nfp::detail::IDebug (nfp:dbg), nn::nfc::mifare::detail::IUser (nfc:mf:u): these copy the input array into _this, without validating the array count.

The data is copied to obj_impl+0x8+0x28, with each entry being 0x20-bytes. The event handle returned by AttachAvailabilityChangeEvent is at obj_impl+0x8+0xB8+0x14 (Same with nfc/nfp interfaces). This therefore means +0xA4 in the input buffer will overwrite the handle returned by that cmd, allowing one to leak any handle with the specified value. This can be done with count=0x6. The object is large enough that this count will only overwrite data within the current object. However during the dtor it will use ptrs which were corrupted with this (located before the event), so one must avoid closing the session unless the input data included valid ptrs.

This can be exploited by just using a 0xC0-byte (array_count=0x6) input buffer with Initialize where each u32 is the target nfc handle value, then using cmd GetAvailabilityChangeEventHandle to leak the handle.

[22.0.0+] This was fixed by clamping the count to a maximum of 0x4.

| OOB datacopy into object state. Allows leaking arbitary [[NFC_services|handles]], including on [S2] (such as process-handle, sm, fsp-srv (remaining services can also be used via sm)).

| [[22.0.0]]

| November 2021

| March 17, 2026

| [[User:Yellows8|yellows8]]

|}

Line 1,272:

Line 1,321:

| December 31, 2020

| [[User:Yellows8|yellows8]]

|}

=== NEX ===

This section documents client-side vulnerabilities for [https://github.com/Kinnay/NintendoClients/wiki/NEX-Overview-(Game-Servers) NEX].

{| class="wikitable" border="1"

|-

! Summary

! Description

! Successful exploitation result

! Fixed in version

! Timeframe this was discovered

! Public disclosure timeframe

! Discovered by

|-

| Buffer overflow in StringConversion::T2Char8

| StringConversion::T2Char8 is used to convert IP addresses from a platform-specific encoding to UTF-8. On the 3DS and Switch, the implementation is simply a strcpy. By sending a long IP address string, a buffer overflow can be triggered on the stack. The vulnerability can be triggered through the NAT traversal protocol. A blog post about this vulnerable can be found [https://reversing.live/hacking-hundreds-of-wii-us-at-once.html here].

| Stack overflow in any game that uses NEX for matchmaking

| Fixed server-side

| December, 2022

| May, 2024

| [https://github.com/kinnay Yannik]

|}

Line 1,452:

Line 1,523:

| Early April 2022

| November 16, 2022

| [[User:Rambo6Glaz|Rambo6Glaz]], ~~Kinnay~~ (massive RE help)

| [[User:Rambo6Glaz|Rambo6Glaz]], [https://github.com/kinnay Yannik] (massive RE help)

|}

There's another one more interesting but it will have to wait a bit :)

== Games ==

{| class="wikitable" border="1"

|-

! Game

! Summary

! Description

! Impact

! Fixed in version

! Timeframe this was discovered

! Public disclosure timeframe

! Discovered by

|-

| Mario Kart World

| ASLR leak in application data

| A memory address can be leaked by changing your username to something short, and hosting a network session in LAN mode (press L + R + Left Stick on the main menu to enable this). The memory address can be found in bytes 12 - 19 of the application data that is transmitted in response to a browse request.

'''Note:''' there is more uninitialized data in the packet, but the memory address is probably the most interesting part. The vulnerability was fixed by clearing the application data with zeros, before filling in the information.

[https://hackerone.com/reports/3463719 HackerOne report]

This stack infoleak was also present in the [[LDN_services|ldn]] AdvertiseData.

| A memory address can leaked (this is a requirement for many types of attacks).

| 1.5.0

| December 12, 2025

| February 19, 2026

| [https://github.com/kinnay Yannik], yellows8 (ldn)

|-

| Splatoon 3

| Anticheat Seed Randomization Weakness

| This oversight of seed generation would allow an attacker to quickly compute all code hashes, and modify game code, while still producing a valid ch1 hash.

[https://hackerone.com/reports/3042475 HackerOne report]

| Allows an attacker to bypass the ch1 anti-cheat hashing mechanism.

| 10.0.0

| March 17, 2025

| February 19, 2026

| hana2736

|}

@@ Line 1: / Line 1: @@
-This page is a list of publicly known Switch flaws.
+This page is a list of publicly known Switch / Switch 2 (S2) flaws.
 = Hardware =
@@ Line 1,116: / Line 1,116: @@
 | May 4, 2025
 | [[User:Yellows8|yellows8]]
+|-
+| [[SSL_services|ssl]] Certificate verification bypass
+| The ssl sysmodule keeps a list of trusted certificates, that are imported by an app with ImportServerPki. During certificate verification, if the certificate that is provided by the server has the same subject key id as a trusted certificate, the certificate is accepted, even if self-signed. A blog post about this vulnerability can be found [https://reversing.live/sslbypass.html here].
+| Man-in-the-middle for any connection that uses ImportServerPki.
+| [[20.2.0]]
+| [[20.2.0]]
+| June 6, 2025
+| August 8, 2025
+| [https://github.com/kinnay Yannik]
 |-
 | [[LDN_services|ldn]] AdvertiseData OOB-memcpy with EncryptionType3 (AES-128-GCM) actionframes (ldnhax)
@@ Line 1,140: / Line 1,149: @@
 [21.0.0+] Arrayindex=0 is now used when the input is invalid.
-|
+| Likely useless, even if reachable?
 | [[21.0.0]]
 | [[21.0.0]]
 | June 3, 2024 (possibly eariler(?))
 | November 14, 2025
+| [[User:Yellows8|yellows8]]
+|-
+| [[Bluetooth_Driver_services|bluetooth]] BSA allowed ATT MTU is too large
+| GATT-handler stack buffer overflows with a large input size are only possible if the payload_size (MTU) field in state is large enough. gatt_client_handle_server_rsp/gatt_server_handle_client_req will drop messages where the size is >= payload_size (though unless the request opcode matches certain values it will also send an error-response for invalid-PDU). Both of these handle updating this field when needed, however that's handled properly.
+With bluetooth-classic via L2CAP, a hard-coded MTU of 0x205 is sent in the configure request. However the code handling received configure requests will set payload_size to 0x2A0 if no MTU is specified, or the input MTU if it's within range 0x30..0x2A0. Hence, sending data large enough for buffer overflows requires bluetooth-classic via L2CAP + manually sending large ACL data.
+[15.0.0+] gatt_l2cif_config_ind_cback which handles the received configure-requests with bluetooth-classic mentioned above, now uses MTU range 0x30..0x205 with the default MTU being 0x205. It is therefore no longer possible to trigger the previously mentioned buffer-overflows with bluetooth-classic.
+| Stack buffer overflows in bluetooth-sysmodule due to the allowed MTU for ATT being larger than the stack data.
+| [[15.0.0]]
+| [[20.0.0]]
+| November 2021?
+| November 26, 2025
+| [[User:Yellows8|yellows8]]
+|-
+| [[Bluetooth_Driver_services|bluetooth]] BSA gatt_process_prep_write_rsp stack buffer overflow
+| BSA gatt_process_prep_write_rsp memcpys to stack without size validation (the input len param which is subtracted to determine the copy-size is also unvalidated). Triggering this is only possible if the system sent ATT_PREPARE_WRITE_REQ, and then received ATT_PREPARE_WRITE_RSP with a large size.
+The size used with memcpy is (u16)(insize-4), so when insize is less than 4 the copy size will be {negative value masked to u16}. This will therefore eventually crash when the stacktop is reached during memcpy.
+[15.0.0+] Paritially fixed due to corrected MTU handling (doesn't apply to negative-copysize). [21.0.0+] Fully fixed with proper size validation.
+| Stack buffer overflow in bluetooth-sysmodule when the required ATT messages are sent/received.
+| [[21.0.0]]
+| [[21.0.0]]
+| November 2021?
+| January 19, 2026
+| [[User:Yellows8|yellows8]]
+|-
+| [[NFC_services|nfc]] Initialize buffer overflow
+| All Initialize* cmds for nn::nfc::detail::IUser (nfc:user), nn::nfc::detail::ISystem (nfc:sys), nn::nfp::detail::IUser (nfp:user), nn::nfp::detail::ISystem (nfp:sys), nn::nfp::detail::IDebug (nfp:dbg), nn::nfc::mifare::detail::IUser (nfc:mf:u): these copy the input array into _this, without validating the array count.
+The data is copied to obj_impl+0x8+0x28, with each entry being 0x20-bytes. The event handle returned by AttachAvailabilityChangeEvent is at obj_impl+0x8+0xB8+0x14 (Same with nfc/nfp interfaces). This therefore means +0xA4 in the input buffer will overwrite the handle returned by that cmd, allowing one to leak any handle with the specified value. This can be done with count=0x6. The object is large enough that this count will only overwrite data within the current object. However during the dtor it will use ptrs which were corrupted with this (located before the event), so one must avoid closing the session unless the input data included valid ptrs.
+This can be exploited by just using a 0xC0-byte (array_count=0x6) input buffer with Initialize where each u32 is the target nfc handle value, then using cmd GetAvailabilityChangeEventHandle to leak the handle.
+[22.0.0+] This was fixed by clamping the count to a maximum of 0x4.
+| OOB datacopy into object state. Allows leaking arbitary [[NFC_services|handles]], including on [S2] (such as process-handle, sm, fsp-srv (remaining services can also be used via sm)).
+| [[22.0.0]]
+| [[22.0.0]]
+| November 2021
+| March 17, 2026
 | [[User:Yellows8|yellows8]]
 |}
@@ Line 1,272: / Line 1,321: @@
 | December 31, 2020
 | [[User:Yellows8|yellows8]]
+|}
+=== NEX ===
+This section documents client-side vulnerabilities for [https://github.com/Kinnay/NintendoClients/wiki/NEX-Overview-(Game-Servers) NEX].
+{| class="wikitable" border="1"
+|-
+!  Summary
+!  Description
+!  Successful exploitation result
+!  Fixed in version
+!  Timeframe this was discovered
+!  Public disclosure timeframe
+!  Discovered by
+|-
+| Buffer overflow in StringConversion::T2Char8
+| StringConversion::T2Char8 is used to convert IP addresses from a platform-specific encoding to UTF-8. On the 3DS and Switch, the implementation is simply a strcpy. By sending a long IP address string, a buffer overflow can be triggered on the stack. The vulnerability can be triggered through the NAT traversal protocol. A blog post about this vulnerable can be found [https://reversing.live/hacking-hundreds-of-wii-us-at-once.html here].
+| Stack overflow in any game that uses NEX for matchmaking
+| Fixed server-side
+| December, 2022
+| May, 2024
+| [https://github.com/kinnay Yannik]
 |}
@@ Line 1,452: / Line 1,523: @@
 | Early April 2022
 | November 16, 2022
-| [[User:Rambo6Glaz|Rambo6Glaz]], Kinnay (massive RE help)
+| [[User:Rambo6Glaz|Rambo6Glaz]], [https://github.com/kinnay Yannik] (massive RE help)
 |}
 There's another one more interesting but it will have to wait a bit :)
+== Games ==
+{| class="wikitable" border="1"
+|-
+! Game
+!  Summary
+!  Description
+!  Impact
+!  Fixed in version
+!  Timeframe this was discovered
+!  Public disclosure timeframe
+!  Discovered by
+|-
+| Mario Kart World
+| ASLR leak in application data
+| A memory address can be leaked by changing your username to something short, and hosting a network session in LAN mode (press L + R + Left Stick on the main menu to enable this). The memory address can be found in bytes 12 - 19 of the application data that is transmitted in response to a browse request.
+'''Note:''' there is more uninitialized data in the packet, but the memory address is probably the most interesting part. The vulnerability was fixed by clearing the application data with zeros, before filling in the information.
+[https://hackerone.com/reports/3463719 HackerOne report]
+This stack infoleak was also present in the [[LDN_services|ldn]] AdvertiseData.
+| A memory address can leaked (this is a requirement for many types of attacks).
+| 1.5.0
+| December 12, 2025
+| February 19, 2026
+| [https://github.com/kinnay Yannik], yellows8 (ldn)
+|-
+| Splatoon 3
+| Anticheat Seed Randomization Weakness
+| This oversight of seed generation would allow an attacker to quickly compute all code hashes, and modify game code, while still producing a valid ch1 hash.
+[https://hackerone.com/reports/3042475 HackerOne report]
+| Allows an attacker to bypass the ch1 anti-cheat hashing mechanism.
+| 10.0.0
+| March 17, 2025
+| February 19, 2026
+| hana2736
+|}