Nintendo Switch Brew - User contributions [en]

System Version Title

2018-03-27T09:44:46Z

Riley: pretty sure this is what was intended.

The FS for the system-version title(TID 0100000000000809) contains "/file" (and, with [5.0.0+], "/digest"):

{| class=wikitable
! Offset
! Size
! Description
|-
| 0x0
| 0x1
| Major
|-
| 0x1
| 0x1
| Minor
|-
| 0x2
| 0x1
| Micro
|-
| 0x3
| 0x1
| Unknown/Build?
|-
| 0x4
| 0x1
| Revision Number
|-
| 0x5
| 0x3
| Normally all-zero. Padding?
|-
| 0x8
| 0x20
| Platform string ("NX" with zeros afterwards)
|-
| 0x28
| 0x40
| Hex ASCII string. 0x28-bytes(not including NUL-terminator) normally with zeros afterwards. The value of this string differs from [[2.0.0]] and [[2.1.0]].
|-
| 0x68
| 0x18
| System-version in string form with zeros afterwards. For example: "2.1.0". This is what is displayed in System settings.
|-
| 0x80
| 0x80
| ASCII string with zeros / padding afterwards. For example: "NintendoSDK Firmware for NX 2.0.0-15"
|}

== Known Versions ==
=== Retail Firmware Updates ===
{| class=wikitable
! Firmware
! Version String
! Hex ASCII String
! "/digest" contents
|-
| 1.0.0
| NintendoSDK Firmware for NX 1.0.0-15
| 84b8da475a02261c456e6472b403b31416480165
| N/A
|-
| 2.0.0
| NintendoSDK Firmware for NX 2.0.0-15
| 25233e518f580062b41f45fae7ce56bff261094a
| N/A
|-
| 2.1.0
| NintendoSDK Firmware for NX 2.1.0-0
| e548f82b0aaff5fd18cfd80e7b9bd9808eeb7c99
| N/A
|-
| 2.2.0
| NintendoSDK Firmware for NX 2.2.0-1
| c83b637205048e61e73c870f21271cc3c6364396
| N/A
|-
| 2.3.0
| NintendoSDK Firmware for NX 2.3.0-0
| 3ed3bbc8885b6362f4f244dcecd2b430fa27310e
| N/A
|-
| 3.0.0
| NintendoSDK Firmware for NX 3.0.0-10.0
| 7fbde2b0bba4d14107bf836e4643043d9f6c8e47
| N/A
|-
| 3.0.1
| NintendoSDK Firmware for NX 3.0.1-0.0
| a3363e086791370ed89dca69c697b4a8bc443d66
| N/A
|-
| 3.0.2
| NintendoSDK Firmware for NX 3.0.2-0.0
| 56bc7f71d0e13179ccb6543bbb33d7f537859e49
| N/A
|-
| 4.0.0
| NintendoSDK Firmware for NX 4.0.0-4.0
| 875be0f6edc29b23938b7aea50764421b9f217e5
| N/A
|-
| 4.0.1
| NintendoSDK Firmware for NX 4.0.1-0.0
| 826588c45cecab1672c46f5de87d83ea6008d583
| N/A
|-
| 4.1.0
| NintendoSDK Firmware for NX 4.1.0-0.0
| 314f9468b704e84e1ffed449dfa6108ba4be221d
| N/A
|-
| 5.0.0
| NintendoSDK Firmware for NX 5.0.0-3.0
| 66790aa646927601523df36a6750205cd944b3de
| gW93A#00050000#QRnTiv2kqQV-KO9DAn1Wzz4S2-SDH4Zd10y8Jx5KalI=
|-
| 5.0.1
| NintendoSDK Firmware for NX 5.0.1-0.0
| 4b51b56242cc388ef487e148048e2c80e25994ad
| gW93A#00050001#wBt05i54vmIPr7cs44Vvod3M9s5M2Yl2ZVd_pd036MY=
|}

=== Other ===
{| class=wikitable
! Firmware
! Version String
! Hex ASCII String
! Note
|-
| 2.0.0-2
| NintendoSDK Firmware for NX 2.0.0-2
| 665fafc03935d12eebba8060a135516b021ccbaa
| Revision of [[Factory Setup|factory firmware]].
|-
| 2.0.0-13
| NintendoSDK Firmware for NX 2.0.0-13
| 60b5fa391b0055f50fec362d29ac18395f387412
| Revision of [[Factory Setup|factory firmware]].
|-
| 3.0.0
| NintendoSDK Firmware for NX 3.0.0-10.0
| 83480e96a810a6c7cd3a8fb58dfb5b53961ac781
| Revision of [[Factory Setup|factory firmware]].
|-
|}

NSO0

2018-01-22T18:24:54Z

Riley: bit 3-5, not 4-6

NSO is the main executable format.

It starts with the "NSO" header and mainly describes .text, .rodata, and .data segments (like a short-form of ELF program headers):

= NSO Header =
{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
|-
| 0x0
| 4
| Magic "NSO0"
|-
| 0x4
| 4
|
|-
| 0x8
| 4
|
|-
| 0xC
| 4
| Flags, bit 0-2: section is compressed, bit 3-5: check section hash when loading
|-
| 0x10
| 0x10 * 3
| SegmentHeader[3]
|-
| 0x40
| 0x20
| Value of "build id" from ELF's GNU .note section. Contains variable sized digest, up to 32bytes.
|-
| 0x60
| 0x4 * 3
| CompressedSize[3]
|-
| 0x6c
| 0x24
| Padding
|-
| 0x90
| 8
| .rodata-relative extents of .dynstr
|-
| 0x98
| 8
| .rodata-relative extents of .dynsym
|-
| 0xA0
| 0x20 * 3
| SHA256 hashes over the decompressed sections using the above byte-sizes: .text, .rodata, and .data.
|-
| 0x100
|
| Compressed sections
|}

Most data in Switch binaries are standard ELF structures, however some are custom.
For example, the MOD header is essentially a replacement for a PT_DYNAMIC program header.

== SegmentHeader ==
{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
|-
| 0x0
| 4
| FileOffset
|-
| 0x4
| 4
| MemoryOffset
|-
| 0x8
| 4
| DecompressedSize
|-
| 0xC
| 4
| UnkOffset/UnkSize/BssSize
|}

== .rodata-relative extent ==
{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
|-
| 0x0
| 4
| RegionRoDataOffset
|-
| 0x4
| 4
| RegionSize
|}

== MOD ==
All offsets are signed 32bit values relative to the magic field.
The 32bits at image base + 4 must point to the magic field.
The MOD structure is designed such that it can be placed at image base and point to itself.
The 2 fields preceding the magic field get copied around with the structure, even if it is relocated to somewhere besides the image base. If MOD is not located at image base, the value at offset 4 must still point to the MOD magic. In the case of .text being at image base, this implies that the first instruction can only be an unconditional branch over the offset literal.
{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
|-
| 0x00
| 4
| ZeroPadding
|-
| 0x04
| 4
| MagicOffset. Always 8 (so it works when MOD is at image_base + 0).
|-
| 0x08
| 4
| Magic "MOD0"
|-
| 0x0C
| 4
| .dynamic offset
|-
| 0x10
| 4
| .bss start offset
|-
| 0x14
| 4
| .bss end offset
|-
| 0x18
| 4
| .eh_frame_hdr start offset
|-
| 0x1C
| 4
| .eh_frame_hdr end offset
|-
| 0x20
| 4
| offset to runtime-generated module object. typically equal to .bss base.
|}

=Arguments=
Loader maps memory and writes the [[Loader_services#AddProcessToLaunchQueue|arguments]] to {end of rwdata section specified by last SegmentHeader}. Official processes use argdata_addr = {page-aligned _end}. svcQueryMemory is used by official sw to verify that argdata_addr is mapped RW, since this memory is only mapped when arguments are specified via that command. Afterwards, official sw aligns the argdata_addr to 4-bytes. Structure located at argdata_addr:

{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
|-
| 0x0 || 0x4 || This is the total allocated space relative to argdata_addr, used for calculating the max size of the argv ptr array. Normally 0x9000?
|-
| 0x4 || 0x4 || This is the total_bytesize of the actual argdata string.
|-
| 0x8 || 0x18 || Unused by official sw.
|-
| 0x20 || See above || Actual argdata string.
|}

* The copy of the args used with the argv array is written by official processes to actual_argdata_string+actual_argdata_size.
* argv_ptrarray written by official processes is at (args_copy+actual_argdata_size) + 0x9 & ~0x7.

NSO0

2018-01-22T18:18:46Z

Riley: document structure element at offset 0xC

NSO is the main executable format.

It starts with the "NSO" header and mainly describes .text, .rodata, and .data segments (like a short-form of ELF program headers):

= NSO Header =
{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
|-
| 0x0
| 4
| Magic "NSO0"
|-
| 0x4
| 4
|
|-
| 0x8
| 4
|
|-
| 0xC
| 4
| Flags, bit 0-2: section is compressed, bit 4-6: check section hash when loading
|-
| 0x10
| 0x10 * 3
| SegmentHeader[3]
|-
| 0x40
| 0x20
| Value of "build id" from ELF's GNU .note section. Contains variable sized digest, up to 32bytes.
|-
| 0x60
| 0x4 * 3
| CompressedSize[3]
|-
| 0x6c
| 0x24
| Padding
|-
| 0x90
| 8
| .rodata-relative extents of .dynstr
|-
| 0x98
| 8
| .rodata-relative extents of .dynsym
|-
| 0xA0
| 0x20 * 3
| SHA256 hashes over the decompressed sections using the above byte-sizes: .text, .rodata, and .data.
|-
| 0x100
|
| Compressed sections
|}

Most data in Switch binaries are standard ELF structures, however some are custom.
For example, the MOD header is essentially a replacement for a PT_DYNAMIC program header.

== SegmentHeader ==
{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
|-
| 0x0
| 4
| FileOffset
|-
| 0x4
| 4
| MemoryOffset
|-
| 0x8
| 4
| DecompressedSize
|-
| 0xC
| 4
| UnkOffset/UnkSize/BssSize
|}

== .rodata-relative extent ==
{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
|-
| 0x0
| 4
| RegionRoDataOffset
|-
| 0x4
| 4
| RegionSize
|}

== MOD ==
All offsets are signed 32bit values relative to the magic field.
The 32bits at image base + 4 must point to the magic field.
The MOD structure is designed such that it can be placed at image base and point to itself.
The 2 fields preceding the magic field get copied around with the structure, even if it is relocated to somewhere besides the image base. If MOD is not located at image base, the value at offset 4 must still point to the MOD magic. In the case of .text being at image base, this implies that the first instruction can only be an unconditional branch over the offset literal.
{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
|-
| 0x00
| 4
| ZeroPadding
|-
| 0x04
| 4
| MagicOffset. Always 8 (so it works when MOD is at image_base + 0).
|-
| 0x08
| 4
| Magic "MOD0"
|-
| 0x0C
| 4
| .dynamic offset
|-
| 0x10
| 4
| .bss start offset
|-
| 0x14
| 4
| .bss end offset
|-
| 0x18
| 4
| .eh_frame_hdr start offset
|-
| 0x1C
| 4
| .eh_frame_hdr end offset
|-
| 0x20
| 4
| offset to runtime-generated module object. typically equal to .bss base.
|}

=Arguments=
Loader maps memory and writes the [[Loader_services#AddProcessToLaunchQueue|arguments]] to {end of rwdata section specified by last SegmentHeader}. Official processes use argdata_addr = {page-aligned _end}. svcQueryMemory is used by official sw to verify that argdata_addr is mapped RW, since this memory is only mapped when arguments are specified via that command. Afterwards, official sw aligns the argdata_addr to 4-bytes. Structure located at argdata_addr:

{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
|-
| 0x0 || 0x4 || This is the total allocated space relative to argdata_addr, used for calculating the max size of the argv ptr array. Normally 0x9000?
|-
| 0x4 || 0x4 || This is the total_bytesize of the actual argdata string.
|-
| 0x8 || 0x18 || Unused by official sw.
|-
| 0x20 || See above || Actual argdata string.
|}

* The copy of the args used with the argv array is written by official processes to actual_argdata_string+actual_argdata_size.
* argv_ptrarray written by official processes is at (args_copy+actual_argdata_size) + 0x9 & ~0x7.

Switch System Flaws

2018-01-20T15:42:52Z

Riley:

System Flaws are used to execute unofficial code (homebrew) on the Nintendo Switch. This page is a list of known and public Switch System Flaws.

=List of Switch System Flaws=

== Hardware ==
{| class="wikitable" border="1"
! Summary
! Description
! Fixed with hardware model/revision
! Newest hardware model/revision this flaw was checked for
! Timeframe this was discovered
! Public disclosure timeframe
! Discovered by
|-
| GMMU DMA attack
| The Switch's GPU includes a separate MMU (GMMU) that is allowed to bypass the system's IOMMU (SMMU). By accessing the GPU's MMIO region and manipulating the page table entries in the GMMU, an attacker can read/write any portion of the DRAM (except memory carveouts).
| None
| HAC-001
| Summer 2017
| December 28, 2017
| [[User:hexkyz|hexkyz]], [[User:SciresM|SciresM]] and [[User:qlutoo|qlutoo]]
|-
| Weak Security Engine context validation
| The Tegra X1 supports a "deep sleep" feature, where everything but DRAM and the PMC registers lose their content (and the SoC loses power). Upon awaking, the bootrom re-executes, restoring system state. Among these stored states is the Security Engine's saved state, which uses AES-128-CBC with a random key and all-zeroes IV. However, the bootrom doesn't perform a MAC on this data, and only validates the last block. This allows one to control most of security engine's state upon wakeup, if one has a way to modify the encrypted state buffer.

With a way to modify the encrypted state buffer, one can thus dump keys from "write-only" keyslots, etc.
| None
| HAC-001
| December 2017
| January 20, 2018
| [[User:SciresM|SciresM]] and [[User:motezazer|motezazer]]
|}

== System software ==

=== Stage 1 Bootloader ===
{| class="wikitable" border="1"
|-
! Summary
! Description
! Successful exploitation result
! Fixed in system version
! Last system version this flaw was checked for
! Timeframe this was discovered
! Public disclosure timeframe
! Discovered by
|-
| Null-dereference in panic()
| The Switch's stage 1 bootloader, on panic(), clears the stack and then attempts to clear the Security Engine. However, it does so by dereferencing a pointer to the SE in .bss (initially NULL), and this pointer doesn't get initialized until partway into the bootloader's main() after several functions that might panic() are called. Thus, a panic() caused prior to SE initialization would result in the SE pointer still being NULL when dereferenced. This would cause a data abort, causing the bootloader to clear the stack and then try to clear the security engine...dereferencing NULL again, over and over in a loop.

In 3.0.0, this was fixed by moving the security engine initialization earlier in main(), before the first function that could potentially panic().
| Infinite clear-the-stack-then-data-abort loop very early in boot, before SBK/other keyslots are cleared. Probably useless for anything more interesting.
| [[3.0.0]]
| [[3.0.0]]
| Early July, 2017
| July 30, 2017
| Everyone who diff'd 2.3.0 and 3.0.0 Package1
|-
| FUSE_DIS_PGM not written by package1
| The switch's hardware fuse driver contains a write-once bit in a register called "FUSE_DIS_PGM", which disables burning fuses until the next reboot. While Nintendo's bootloader code for waking up from sleep writes this on all firmware, the actual package1 initial bootloader forgets to write to it on cold reboot.

This isn't too big of a problem because another fuse is burnt on retail devices (production mode), which prevents burning *all* fuses other than ODM_RESERVED ones in hardware.

This was fixed in 3.0.0 by writing to the register on cold boot (although the write happens in TZ instead of package1 where it should take place, possibly to obfuscate the fact that they made this mistake).
| Burning arbitrary ODM reserved fuses with TZ code execution, which should never be possible for non-bootloader code.

Warning: one could irreparably brick one's console by playing with this.
| [[3.0.0]]
| [[3.0.0]]
| Late summer/early fall 2017
| December 31, 2017
| [[User:SciresM|SciresM]], [[User:motezazer|motezazer]]
|-
|}

=== TrustZone ===
{| class="wikitable" border="1"
|-
! Summary
! Description
! Successful exploitation result
! Fixed in system version
! Last system version this flaw was checked for
! Timeframe this was discovered
! Public disclosure timeframe
! Discovered by
|-
| Non-atomic mutexes
| When an [[SMC]] is called, TrustZone sets a global variable to mark that an SMC is in progress, so that two SMCs using shared resources (like the security engine) do not trample on one another. On 1.0.0, this global variable was written using non-atomic writes, and thus a race condition is possible.

However, the SMC handler enforces that all SMCs must be called from core #3, unless the top-level handler ID is 1 (SMCs internal to the kernel). Thus, the only SMCs that can be run side-by-side are [any userland smc] and smcGetRandomBytesForKernel, and this turns out to not really be abusable.
| Mostly useless. Maybe some oob-write into unused (and thus useless) memory if running smcGetRandomBytesForKernel and smcGetRandomBytesForUser at the same time.
| [[2.0.0]]
| [[2.0.0]]
| December 2017 (Probably earlier by others)
| January 18, 2018
| [[User:SciresM|SciresM]], probably others.
|-
| jamais vu (non-secure world access to PMC MMIO and pre-deep sleep firmware)
| On [[1.0.0]], one could map in the PMC registers in userland. In addition, [[AM_services|am]] ran a little-kernel based firmware on the BPMP at runtime. With code execution under am, one could modify the BPMP's little-kernel firmware to hook deep sleep entry, and modify TrustZone/Security engine state.

This was fixed in [[2.0.0]] by making the PMC secure-world only, blacklisting the BPMP's exception vectors from being mapped, and thoroughly checking for malicious behavior on deep sleep entry.
| Arbitrary TrustZone code execution.
| [[2.0.0]]
| [[2.0.0]]
| December, 2017
| January 20, 2018
| [[User:SciresM|SciresM]] and [[User:motezazer|motezazer]]
|-
|}

=== Kernel ===
{| class="wikitable" border="1"
|-
! Summary
! Description
! Successful exploitation result
! Fixed in system version
! Last system version this flaw was checked for
! Timeframe this was discovered
! Public disclosure timeframe
! Discovered by
|-
| Syscall Infoleaks
| Many syscalls leaked kernel pointers on sad paths (for example svcSetHeapSize and svcQueryMemory), until they landed a bunch of fixes in 2.0.0.
| Nothing really.
| 2.0.0
| 2.0.0
|
|
| ?
|-
| GetLastThreadInfo UAF
| GetLastThreadInfo syscall gets last-scheduled-KThread pointer from KScheduler object. This pointer is not reference counted, and can be pointing to a freed KThread.
| Nothing. There is a theoretical race that might leak from a KThread from a different process, but it's impossible to trigger practically.
| Unfixed
|
| 15 October
| 17 October
| [[User:qlutoo|qlutoo]]
|-
| Bad irq_id check in CreateInterruptEvent
| CreateInterruptEvent syscall is designed to work only for irq_id >= 32. All irq_ids < 32 are "per-core" and reserved for kernel use (watchdog/scheduling/core communications).
On 1.0.0 you could supply irq_id < 32 and it would write outside the SharedIrqs table.
| You can register irq's in the Core3Irqs table, and thus register per-core irqs for core3, that are normally reserved for kernel. Useless.
| 2.0.0
| 2.0.0
| ~October
| 17 October
| [[User:qlutoo|qlutoo]]
|-
| Kernel .text mapped executable in usermode
| Prior to [[3.0.2]] the kernel .text was [[Memory_layout|mapped]] in usermode as executable. This can be used for usermode ROP for bypassing ASLR, but SVCs/IPC are not usable by running kernel .text in usermode.
| Executing kernel .text in usermode
| [[3.0.2]]
| [[3.0.2]]
|
| 34c3 (December 28, 2017)
| [[User:qlutoo|qlutoo]]
|-
| Memory Controller not properly secured
| The Switch OS originally had the memory controller not set to be accessible only by the secure-world, which was problematic because insecure access can compromise the kernel.

This was fixed partially in [[2.0.0]] by blacklisting the memory controller from being mapped by user-processes, and was fixed entirely in [[4.0.0]] by making the memory controller TZ-only and making all kernel accesses go through [[SMC|smcReadWriteRegister]].
| With some way to access the memory controller MMIO, arbitrary kernel code execution.
| [[4.0.0]]
| [[4.0.0]]
| January 2018
| January 2018
| [[User:SciresM|SciresM]], [[User:Yellows8|yellows8]]
|-
|}

=== FIRM-package System Modules ===
{| class="wikitable" border="1"
|-
! Summary
! Description
! Successful exploitation result
! Fixed in system version
! Last system version this flaw was checked for
! Timeframe this was discovered
! Public disclosure timeframe
! Discovered by
|-
| Service access control bypass (sm:h, smhax, probably other names)
| Prior to [[3.0.1]], the ''service manager'' (sm) built-in system module treats a user as though it has full permissions if the user creates a new "sm:" port session but bypasses [[Services_API#Initialize|initialization]]. This is due to the other sm commands skipping the service ACL check for Pids <= 7 (i.e. all kernel bundled modules) and that skipping the initialization command leaves the Pid field uninitialized.
In [[3.0.1]], sm returns error code 0x415 if [[Services_API#Initialize|Initialize]] has not been called yet.
| Acquiring, registering, and unregistering arbitrary services
| [[3.0.1]]
| [[3.0.1]]
| May 2017
| August 17, 2017
| Everyone
|-
| Overly permissive SPL service
| The concept behind the switch's [[SMC|Secure Monitor]] is that all cryptographic keydata is located in userspace, but stored as "access keys" encrypted with "keks" that never leave TrustZone. The [[SPL services|spl]] ("security processor liaison"?) service serves as an interface between the rest of the system and the secure monitor. Prior to [[4.0.0]], spl exposed only a single service "spl:", which provided all TrustZone wrapper functions to all sysmodules with access to it. Thus anyone with access to the spl: service (via smhax or by pwning a sysmodule with access) could do crypto with any access keys they knew.

This was fixed in [[4.0.0]] by splitting spl: into spl:, spl:mig, spl:ssl, spl:es, and spl:fs.
| Arbitrary spl: crypto with any access keys one knows. For example, one could use the SSL module's access keys to decrypt their console's SSL certificate private key without having to pwn the SSL sysmodule.
| [[4.0.0]]
| [[4.0.0]]
| Summer 2017 (after smhax was discovered).
| December 23, 2017
| Everyone
|-
| Single session services not really single session
| Several "critical" services (like fsp-ldr, fsp-pr, sm:m, etc) are meant to only ever hold a single session with a specific sysmodule. However, when a sysmodule dies, all its service session handles are released -- and thus killing the holder of a single session handle would allow one (via sm:hax etc) to get access to that service.

This was fixed in [[4.0.0]] by adding a semaphore to these critical single-session services, so that even if one gets access to them an error code will be returned when attempting to use any of their commands.
| With some way to access these services and kill their session holders: dumping sysmodule code, arbitrary service access, elevated filesystem permissions, etc.
| [[4.0.0]]
| [[4.0.0]]
| May/June 2017 (basically immediately after smhax was discovered)
| December 30, 2017
| Everyone
|-
|}

=== System Modules ===
{| class="wikitable" border="1"
|-
! Summary
! Description
! Successful exploitation result
! Fixed in system version
! Last system version this flaw was checked for
! Timeframe this was discovered
! Public disclosure timeframe
! Discovered by
|-
| Out-of-bounds array read for [[BCAT_Content_Container]] secret-data index
| The [[BCAT_Content_Container]] secret-data index is not validated at all. This is handled before the RSA-signature(?) is ever used. Since the field is an u8, a total of 0x800-bytes relative to the array start can be accessed.
This is not useful since the string loaded from this array is only involved with key-generation.
|
| Unknown
| [[2.0.0]]
| August 4, 2017
| August 6, 2017
| [[User: shinyquagsire23|Shiny Quagsire]], [[User:Yellows8|yellows8]] (independently)
|-
| OOB Read in NS system module (pl:utoohax, pl:utonium, maybe other names)
| Prior to [[3.0.0]], pl:u (Shared Font services implemented in the NS sysmodule) service commands 1,2,3 took in a signed 32-bit index and returned that index of an array but did not check that index at all. This allowed for an arbitrary read within a 34-bit range (33-bit signed) from NS .bss. In [[3.0.0]], sending out of range indexes causes error code 0x60A to be returned.
| Dumping full NS .text, .rodata and .data, infoleak, etc
| [[3.0.0]]
| [[3.0.0]]
| April 2017
| On exploit's fix in [[3.0.0]]
| [[User:qlutoo|qlutoo]], Reswitched team (independently)
|-
| Unchecked domain ID in common IPC code
| Prior to [[2.0.0]], object IDs in [[IPC_Marshalling#Domain_message|domain messages]] are not bounds checked. This out-of-bounds read could be exploited to brute-force ASLR and get PC control in some services that support domain messages.
|
| 2.0.0
| 2.0.0
| ~July 2017
| 20 July 2017‎
| [[User:hthh|hthh]]
|}