https://www.3dbrew.org/w/api.php?action=feedcontributions&user=Mrrraou&feedformat=atom3dbrew - User contributions [en]2024-03-28T19:35:58ZUser contributionsMediaWiki 1.35.8https://www.3dbrew.org/w/index.php?title=Camera_Applet&diff=19605Camera Applet2017-02-12T10:02:18Z<p>Mrrraou: removed irrelevant info</p>
<hr />
<div>'''Quick Camera''' is a shortcut on HOME Menu of the 3DS software. It is activated with the L and R buttons, and can access both the outer and inner camera.<br />
<br />
This shortcut can also function as a QR code scanner, opening the web browser with the link contained in the QR code.</div>Mrrraouhttps://www.3dbrew.org/w/index.php?title=CONFIG11_Registers&diff=19560CONFIG11 Registers2017-02-09T19:50:49Z<p>Mrrraou: better fix</p>
<hr />
<div>= Registers =<br />
{| class="wikitable" border="1"<br />
! Old3DS<br />
! Name<br />
! Address<br />
! Width<br />
! Used by<br />
|-<br />
| style="background: green" | Yes<br />
| [[#CFG11_SHAREDWRAM_32K_DATA|CFG11_SHAREDWRAM_32K_DATA]]<0-7><br />
| 0x10140000<br />
| 1*8<br />
| Boot11, Process9, [[DSP Services]]<br />
|-<br />
| style="background: green" | Yes<br />
| [[#CFG11_SHAREDWRAM_32K_CODE|CFG11_SHAREDWRAM_32K_CODE]]<0-7><br />
| 0x10140008<br />
| 1*8<br />
| Boot11, Process9, [[DSP Services]]<br />
|-<br />
| style="background: green" | Yes<br />
| ?<br />
| 0x10140100<br />
| 2<br />
|<br />
|-<br />
| style="background: green" | Yes<br />
| ?<br />
| 0x10140102<br />
| 2<br />
|<br />
|-<br />
| style="background: green" | Yes<br />
| [[#CFG11_FIQ_CNT|CFG11_FIQ_CNT]]<br />
| 0x10140104<br />
| 1<br />
| Kernel11.<br />
|-<br />
| style="background: green" | Yes<br />
| ?<br />
| 0x10140105<br />
| 1<br />
| Kernel11.<br />
|-<br />
| style="background: green" | Yes<br />
| Related to [[HID_Registers|HID_?]]<br />
| 0x10140108<br />
| 2<br />
| TwlBg<br />
|-<br />
| style="background: green" | Yes<br />
| Related to [[HID_Registers|HID_?]]<br />
| 0x1014010C<br />
| 2<br />
| TwlBg<br />
|-<br />
| style="background: green" | Yes<br />
| [[#CFG11_GPUPROT|CFG11_GPUPROT]]<br />
| 0x10140140<br />
| 4<br />
| Kernel11<br />
|-<br />
| style="background: green" | Yes<br />
| [[#CFG11_WIFICNT|CFG11_WIFICNT]]<br />
| 0x10140180<br />
| 1<br />
| TwlBg, [[NWM Services]]<br />
|-<br />
| style="background: green" | Yes<br />
| [[#CFG11_SPI_CNT|CFG11_SPI_CNT]]<br />
| 0x101401C0<br />
| 4<br />
| [[SPI Services]], TwlBg<br />
|-<br />
| style="background: green" | Yes<br />
| ?<br />
| 0x10140200<br />
| 4<br />
|<br />
|-style="border-top: double"<br />
| style="background: red" | No<br />
| Clock related?<br />
| 0x10140400<br />
| 1<br />
| NewKernel11<br />
|-<br />
| style="background: red" | No<br />
| Clock related?<br />
| 0x10140410<br />
| 4<br />
| NewKernel11<br />
|-<br />
| style="background: red" | No<br />
| [[#CFG11_BOOTROM_OVERLAY_CNT|CFG11_BOOTROM_OVERLAY_CNT]]<br />
| 0x10140420<br />
| 1<br />
| NewKernel11<br />
|-<br />
| style="background: red" | No<br />
| [[#CFG11_BOOTROM_OVERLAY_VAL|CFG11_BOOTROM_OVERLAY_VAL]]<br />
| 0x10140424<br />
| 4<br />
| NewKernel11<br />
|-<br />
| style="background: red" | No<br />
| ?<br />
| 0x10140428<br />
| 4<br />
|<br />
|-style="border-top: double"<br />
| style="background: green" | Yes<br />
| [[#CFG11_SOCINFO|CFG11_SOCINFO]]<br />
| 0x10140FFC<br />
| 2<br />
| Boot11, Kernel11<br />
|-style="border-top: double"<br />
| style="background: green" | Yes<br />
| CFG11_GPU_STATUS?<br />
| 0x10141000<br />
| 4<br />
| Kernel11, TwlBg<br />
|-<br />
| style="background: green" | Yes<br />
| CFG11_PTM_0<br />
| 0x10141008<br />
| 4<br />
| [[PTM Services]], [[PDN Services]]<br />
|-<br />
| style="background: green" | Yes<br />
| CFG11_PTM_1<br />
| 0x1014100C<br />
| 4<br />
| [[PTM Services]], TwlBg, [[PDN Services]]<br />
|-style="border-top: double"<br />
| style="background: green" | Yes<br />
| [[#CFG11_TWLMODE_0|CFG11_TWLMODE_0]]<br />
| 0x10141100<br />
| 2<br />
| TwlProcess9, TwlBg<br />
|-<br />
| style="background: green" | Yes<br />
| [[#CFG11_TWLMODE_1|CFG11_TWLMODE_1]]<br />
| 0x10141104<br />
| 2<br />
| TwlBg<br />
|-<br />
| style="background: green" | Yes<br />
| [[#CFG11_TWLMODE_2|CFG11_TWLMODE_2]]<br />
| 0x10141108<br />
| 2<br />
| TwlBg<br />
|-<br />
| style="background: green" | Yes<br />
| [[#CFG11_TWLMODE_HID|CFG11_TWLMODE_HID]]<br />
| 0x1014110A<br />
| 2<br />
| TwlBg<br />
|-<br />
| style="background: green" | Yes<br />
| [[#CFG11_WIFIUNK|CFG11_WIFIUNK]]<br />
| 0x1014110C<br />
| 1<br />
| [[NWM Services]]<br />
|-<br />
| style="background: green" | Yes<br />
| ?<br />
| 0x10141110<br />
| 2<br />
| TwlBg<br />
|-<br />
| style="background: green" | Yes<br />
| ?<br />
| 0x10141112<br />
| 2<br />
| TwlBg<br />
|-<br />
| style="background: green" | Yes<br />
| [[#CFG11_CODEC|CFG11_CODEC_0]]<br />
| 0x10141114<br />
| 2<br />
| [[Codec Services]], TwlBg<br />
|-<br />
| style="background: green" | Yes<br />
| [[#CFG11_CODEC|CFG11_CODEC_1]]<br />
| 0x10141116<br />
| 2<br />
| [[Codec Services]], TwlBg<br />
|-<br />
| style="background: green" | Yes<br />
| ?<br />
| 0x10141118<br />
| 1<br />
| TwlBg<br />
|-<br />
| style="background: green" | Yes<br />
| ?<br />
| 0x10141119<br />
| 1<br />
| TwlBg<br />
|-<br />
| style="background: green" | Yes<br />
| ?<br />
| 0x10141120<br />
| 1<br />
| TwlBg<br />
|-<br />
|-style="border-top: double"<br />
| style="background: green" | Yes<br />
| [[#CFG11_GPU_CNT|CFG11_GPU_CNT]]<br />
| 0x10141200<br />
| 4<br />
| Boot11, Kernel11, [[PDN Services]]<br />
|-<br />
| style="background: green" | Yes<br />
| [[#CFG11_GPU_CNT2|CFG11_GPU_CNT2]]<br />
| 0x10141204<br />
| 4<br />
| Boot11, Kernel11<br />
|-<br />
| style="background: green" | Yes<br />
| CFG11_GPU_CNT3<br />
| 0x10141210<br />
| 2<br />
| Kernel11, TwlBg<br />
|-<br />
| style="background: green" | Yes<br />
| [[#CFG11_CODEC_CNT|CFG11_CODEC_CNT]]<br />
| 0x10141220<br />
| 1<br />
| Boot11, TwlBg, [[PDN Services]]<br />
|-<br />
| style="background: green" | Yes<br />
| [[#CFG11_CAMERA_CNT|CFG11_CAMERA_CNT]]<br />
| 0x10141224<br />
| 1<br />
| [[PDN Services]]<br />
|-<br />
| style="background: green" | Yes<br />
| CFG11_DSP_CNT<br />
| 0x10141230<br />
| 1<br />
| Process9, [[PDN Services]]<br />
|-style="border-top: double"<br />
| style="background: red" | No<br />
| [[#CFG11_MPCORE_CLKCNT|CFG11_MPCORE_CLKCNT]]<br />
| 0x10141300<br />
| 2<br />
| NewKernel11<br />
|-<br />
| style="background: red" | No<br />
| [[#CFG11_MPCORE_CNT|CFG11_MPCORE_CNT]]<br />
| 0x10141304<br />
| 2<br />
| NewKernel11<br />
|-<br />
| style="background: red" | No<br />
| [[#CFG11_MPCORE_BOOTCNT<0-3>|CFG11_MPCORE_BOOTCNT]]<0-3><br />
| 0x10141310<br />
| 1*4<br />
| NewKernel11<br />
|}<br />
<br />
== CFG11_SHAREDWRAM_32K_DATA ==<br />
Used for mapping 32K chunks of shared WRAM for DSP data.<br />
<br />
{| class="wikitable" border="1"<br />
! Bits<br />
! Description<br />
|-<br />
| 0-1<br />
| Master (0=ARM9?, 1=ARM11?, 2 or 3=DSP/data)<br />
|-<br />
| 2-4<br />
| Offset (0..7) (slot 0..7) (LSB of address in 32Kbyte units)<br />
|-<br />
| 5-6<br />
| Not used (0)<br />
|-<br />
| 7<br />
| Enable (0=Disable, 1=Enable)<br />
|}<br />
<br />
== CFG11_SHAREDWRAM_32K_CODE ==<br />
Used for mapping 32K chunks of shared WRAM for DSP data.<br />
<br />
{| class="wikitable" border="1"<br />
! Bits<br />
! Description<br />
|-<br />
| 0-1<br />
| Master (0=ARM9?, 1=ARM11?, 2 or 3=DSP/code)<br />
|-<br />
| 2-4<br />
| Offset (0..7) (slot 0..7) (LSB of address in 32Kbyte units)<br />
|-<br />
| 5-6<br />
| Not used (0)<br />
|-<br />
| 7<br />
| Enable (0=Disable, 1=Enable)<br />
|}<br />
<br />
== CFG11_FIQ_CNT ==<br />
Writing bit1 to this register disables FIQ interrupts.<br />
<br />
This bit is set upon receipt of a FIQ interrupt and when [[SVC|svcUnbindInterrupt]] is called on the FIQ-abstraction [[ARM11_Interrupts#Private_Interrupts|software interrupt]] for the current core.<br />
It is cleared when binding that software interrupt to an event and just before that event is signaled.<br />
<br />
== CFG11_SPI_CNT ==<br />
When the corresponding bit is 0, the bus has to be accessed using the DS SPI registers. Otherwise it has to be accessed using the 3DS SPI registers.<br />
{| class="wikitable" border="1"<br />
! Bit<br />
! Description<br />
|-<br />
| 0<br />
| Enable [[SPI Registers]] 0x10160000.<br />
|-<br />
| 1<br />
| Enable [[SPI Registers]] 0x10142000.<br />
|-<br />
| 2<br />
| Enable [[SPI Registers]] 0x10143000.<br />
|}<br />
<br />
== CFG11_BOOTROM_OVERLAY_CNT ==<br />
Bit0: Enable bootrom overlay functionality.<br />
<br />
== CFG11_BOOTROM_OVERLAY_VAL ==<br />
The 32-bit value to overlay data-reads to bootrom with. See [[#CFG11_MPCORE_BOOTCNT|CFG11_MPCORE_BOOTCNT]].<br />
<br />
== CFG11_SOCINFO ==<br />
Read-only register.<br />
<br />
{| class="wikitable" border="1"<br />
! Bits<br />
! Description<br />
! Used by<br />
|-<br />
| 0<br />
| 1 on both Old3DS and New3DS.<br />
| Boot11<br />
|-<br />
| 1<br />
| 1 on New3DS.<br />
| Kernel11<br />
|-<br />
| 2<br />
| Clock modifier: if set, use a 3x multiplier, otherwise 2x<br />
| Kernel11<br />
|}<br />
<br />
== CFG11_MPCORE_CLKCNT ==<br />
This is used for configuring the New3DS ARM11 CPU clock-rate. This register is New3DS-only: reading from here on Old3DS always returns all-zeros even when one tried writing data here prior to the read.<br />
<br />
{| class="wikitable" border="1"<br />
! Bits<br />
! Description<br />
|-<br />
| 0<br />
| Enable clock multiplier? This must be set to 1 before writing a non-zero value to bit1-2, otherwise freeze.<br />
|-<br />
| 1-2<br />
| Clock multiplier (0=1x, 1=2x, 2=3x, 3=hang)<br />
|-<br />
| 15<br />
| Busy<br />
|}<br />
<br />
[[SVC#KernelSetState|svcKernelSetState]] type10, only implemented on New3DS, uses this register. That code writes the following values to this register, depending on the input Param0 bit0 state, and the state of CFG11_MPCORE_CFG:<br />
{| class="wikitable" border="1"<br />
! Register value<br />
! Higher-clockrate bit set in svcKernelSetState Param0<br />
! CFG11_MPCORE_CFG bit2 set<br />
! MPCore timer/watchdog prescaler value, prior to subtracting it by 0x1 when writing it into hw/state<br />
! Clock-rate multiplier<br />
! Description<br />
|-<br />
| 0x01<br />
| No<br />
| Yes<br />
| 0x01<br />
| 1x<br />
| 268MHz<br />
|-<br />
| 0x02<br />
| No<br />
| No<br />
| 0x01<br />
| 1x<br />
| 268MHz<br />
|-<br />
| 0x05<br />
| Yes<br />
| Yes<br />
| 0x03<br />
| 3x<br />
| 804MHz<br />
|-<br />
| 0x03<br />
| Yes<br />
| No<br />
| 0x02<br />
| 2x<br />
| 536MHz (tested on New3DS)<br />
|}<br />
<br />
Note that the above CFG11_MPCORE_CFG bit is 1 on New3DS, and 0 on Old3DS. Since this SVC is only available with the New3DS ARM11-kernel, the only additional available clock-rate is 804MHz when running on New3DS(with official kernel code).<br />
<br />
The following register value(s) were tested on New3DS by patching the kernel:<br />
* 0x00: Entire system hangs.<br />
* 0x02: Entire system hangs.<br />
* 0x03: ARM11 runs at 536MHz.<br />
* 0x04: Entire system hangs.<br />
* 0x06: Entire system hangs.<br />
* 0x07: Same result as 0x05.<br />
* 0x08: Entire system hangs.<br />
* 0x09: Entire system hangs.<br />
* 0x0A: Entire system hangs.<br />
* 0x0B: Same result as 0x03.<br />
* 0x0C: Entire system hangs.<br />
* 0x0D: Same result as 0x05.<br />
* 0x0E: Entire system hangs.<br />
* 0x0F: Same result as 0x05.<br />
* 0x1F, 0x2F, 0x4F, 0x8F, 0xFF: Same result as 0x05.<br />
<br />
== CFG11_MPCORE_CNT ==<br />
{| class="wikitable" border="1"<br />
! Bits<br />
! Description<br />
|-<br />
| 0<br />
| Power on 3rd ARM11 MPCore maybe?<br />
|-<br />
| 8<br />
| Power on 4th ARM11 MPCore maybe?<br />
|}<br />
<br />
== CFG11_MPCORE_BOOTCNT<0-3> ==<br />
{| class="wikitable" border="1"<br />
! Bits<br />
! Description<br />
|-<br />
| 0<br />
| Enable bootrom instruction overlay, maybe? This bit is only writable for core2 and core3.<br />
|-<br />
| 1<br />
| Enable bootrom data overlay. This bit is only writable for core2 and core3.<br />
|-<br />
| 4<br />
| Has core booted maybe?<br />
|-<br />
| 5<br />
| Always 1?<br />
|}<br />
<br />
The normal ARM11 bootrom checks cpuid and hangs if cpuid >= 2. This is a problem when booting the 2 additional New3DS ARM11 MPCores. NewKernel11 solves this by using a hardware feature to overlay the bootrom with a configurable branch to a kernel function. This overlay feature was added with the New3DS.<br />
<br />
Bit1 in register above enables a bootrom data-override for physical addresses 0xFFFF0000-0xFFFF1000 and 0x10000-0x11000. All _data reads_ made to those regions now read the 32-bit value provided in [[#CFG11_BOOTROM_OVERLAY_VAL|CFG11_BOOTROM_OVERLAY_VAL]].<br />
<br />
Bit0 enables a bootrom instruction-overlay which means that _instruction reads_ made to the bootrom region are overridden. We have not been able to dump what instructions are actually placed at bootrom by this switch (because reading the area only yields data-reads). Jumping randomly into the 0xFFFF0000-0xFFFF1000 region works fine and jumps to the value provided by the data overlay [[#CFG11_BOOTROM_OVERLAY_VAL|CFG11_BOOTROM_OVERLAY_VAL]]. Thus we may predict that the entire bootrom region is filled by:<br />
ldr pc, [pc]<br />
<br />
Or equivalent. However, jumping to some high addresses such as 0xFFFF0FF0+ will crash the core. This may be explained by prefetching in the ARM pipeline, and might help us identify what instructions are placed by the instruction-overlay.<br />
<br />
==CFG11_GPUPROT==<br />
{| class="wikitable" border="1"<br />
! Old3DS<br />
! Bits<br />
! Description<br />
|-<br />
| style="background: green" | Yes<br />
| 3-0<br />
| Old FCRAM DMA cutoff size, 0 = no protection.<br />
|-<br />
| style="background: red" | No<br />
| 7-4<br />
| New FCRAM DMA cutoff size, 0 = no protection.<br />
|-<br />
| style="background: green" | Yes<br />
| 8<br />
| AXIWRAM protection, 0 = accessible.<br />
|-<br />
| style="background: red" | No<br />
| 10-9<br />
| QTM DMA cutoff size<br />
|-<br />
| style="background: green" | Yes<br />
| 31-11<br />
| Zeroes<br />
|}<br />
<br />
For the old FCRAM DMA cutoff, it protects starting from 0x28000000-(0x800000*x) until end of FCRAM. There is no way to protect the first 0x800000-bytes.<br />
<br />
For the new FCRAM DMA cutoff, it protects starting from 0x30000000-(0x800000*x) until end of FCRAM. When the old FCRAM cutoff is set to non-zero, the first 0x800000-bytes bytes of new FCRAM are protected.<br />
<br />
On New3DS the old+new FCRAM cutoff can be used at the same time, however this isn't done officially.<br />
<br />
For the QTM DMA cutoff, it protects starting from 0x1F400000-(0x100000*x) until end of QTM mem.<br />
<br />
On cold boot this reg is set to 0.<br />
<br />
When this register is set to value 0, the GPU can access the entire FCRAM, AXIWRAM, and on New3DS all QTM-mem.<br />
<br />
[[SVC|Initialized]] during kernel boot, and used with [[SVC]] 0x59 which was implemented with [[11.3.0-36|v11.3]].<br />
<br />
==CFG11_WIFICNT==<br />
{| class="wikitable" border="1"<br />
! Old3DS<br />
! Bits<br />
! Description<br />
|-<br />
| style="background: green" | Yes<br />
| 0<br />
| Enable wifi subsystem<br />
|}<br />
<br />
==CFG11_TWLMODE_0==<br />
Observed 0x8001 when running under TWL_ and AGB_FIRM, 0 NATIVE_FIRM.<br />
<br />
This address is poked from ARM7 to signal that it has booted and begun executing code. The ARM7-mode address for this register is 0x4700000.<br />
<br />
The very last 3DS-mode register poke the [[FIRM|TWL_FIRM]] Process9 does before it gets switched into TWL-mode, is writing 0x8000 to this register. Before writing this register, TWL Process9 waits for ARM7 to change the value of this register. The Process9 code for this runs from ITCM, since switching into TWL-mode includes remapping all ARM9 physical memory.<br />
<br />
Writing 0x8000 to here from the ARM9 with NATIVE_FIRM running doesn't seem to do anything, other reg-pokes likely need done first.<br />
<br />
==CFG11_TWLMODE_1==<br />
Observed 0x8000 when running under TWL_FIRM, 0 NATIVE_FIRM.<br />
<br />
==CFG11_TWLMODE_2==<br />
Bitfield.<br />
<br />
==CFG11_TWLMODE_HID==<br />
The value of this register is copied to [[HID_Registers|HID_?]] under certain conditions.<br />
<br />
==CFG11_WIFIUNK==<br />
{| class="wikitable" border="1"<br />
! Old3DS<br />
! Bits<br />
! Description<br />
|-<br />
| style="background: green" | Yes<br />
| 4<br />
| Wifi-related? Set to 1 very early in NWM-module.<br />
|}<br />
<br />
==CFG11_GPU_CNT==<br />
This one seems to control the LCD/GPU/Backlight.<br />
<br />
Bit0: Enable GPU registers at 0x10400000+.<br />
Bit16: Turn on LCD backlight.<br />
<br />
==CFG11_GPU_CNT2==<br />
Bit0: Power on GPU?<br />
<br />
==CFG11_GPU_CNT3==<br />
Bit1: FCRAM access from ARM11? Clearing this bit in 3DS-mode causes the ARM11 and ARM9 to hang/crash.<br />
<br />
==CFG11_CODEC==<br />
The following is the only time the ARM11 CODEC module uses any 0x1EC41XXX registers. In one case CODEC module clears bit1 in register 0x1EC41114, in the other case CODEC module sets bit1 in registers 0x1EC41114 and 0x1EC41116.<br />
<br />
==CFG11_CODEC_CNT==<br />
This is the power register used for the [[CFG11_Services|PDN]] CODEC service.<br />
<br />
bit0 = unknown, bit1 = turn on/off DSP, rest = always 0.<br />
<br />
==CFG11_CAMERA_CNT==<br />
This is the power register used for the [[CFG11_Services|PDN]] camera service.<br />
<br />
bit0 = unknown, bit1 = turn on/off cameras, rest = always 0.</div>Mrrraouhttps://www.3dbrew.org/w/index.php?title=GPU/External_Registers&diff=19405GPU/External Registers2017-01-23T20:23:58Z<p>Mrrraou: /* LCD Source Framebuffer Setup */</p>
<hr />
<div>This page describes the address range accessible from the ARM11, used to configure the basic GPU functionality. For information about the internal registers used for 3D rendering, see [[GPU/Internal Registers]].<br />
<br />
== Map ==<br />
{| class="wikitable" border="1"<br />
! User VA<br />
! PA<br />
! Length<br />
! Name<br />
! Comments<br />
|-<br />
| 0x1EF00004<br />
| 0x10400004<br />
| 4<br />
| ?<br />
|<br />
|-<br />
| 0x1EF00010<br />
| 0x10400010<br />
| 16<br />
| [[#Memory Fill|Memory Fill1]] "PSC0"<br />
| GX command 2<br />
|-<br />
| 0x1EF00020<br />
| 0x10400020<br />
| 16<br />
| [[#Memory Fill|Memory Fill2]] "PSC1"<br />
| GX command 2<br />
|-<br />
| 0x1EF00030<br />
| 0x10400030<br />
| 4<br />
| ?<br />
|<br />
|-<br />
| 0x1EF00034<br />
| 0x10400034<br />
| 4<br />
| GPU Busy<br />
| Bit31 = cmd-list busy, bit27 = PSC0 busy, bit26 = PSC1 busy.<br />
|-<br />
| 0x1EF00050<br />
| 0x10400050<br />
| 4<br />
| ?<br />
| Writes 0x22221200 on GPU init.<br />
|-<br />
| 0x1EF00054<br />
| 0x10400054<br />
| 4<br />
| ?<br />
| Writes 0xFF2 on GPU init.<br />
|-<br />
| 0x1EF000C0<br />
| 0x104000C0<br />
| 4<br />
| Backlight control<br />
| Writes 0x0 to allow backlights to turn off, 0x20000000 to force them always on.<br />
|-<br />
| 0x1EF00400<br />
| 0x10400400<br />
| 0x100<br />
| [[#LCD Source Framebuffer Setup|Framebuffer Setup]] "PDC0" (top screen)<br />
|<br />
|-<br />
| 0x1EF00500<br />
| 0x10400500<br />
| 0x100<br />
| [[#LCD Source Framebuffer Setup|Framebuffer Setup]] "PDC1" (bottom)<br />
|<br />
|-<br />
| 0x1EF00C00<br />
| 0x10400C00<br />
| ?<br />
| [[#Transfer_Engine|Transfer Engine]] "DMA"<br />
|<br />
|-<br />
| 0x1EF01000<br />
| 0x10401000<br />
| 0x4<br />
| ?<br />
| Writes 0 on GPU init and before the Command List is used<br />
|-<br />
| 0x1EF01080<br />
| 0x10401080<br />
| 0x4<br />
| ?<br />
| Writes 0x12345678 on GPU init.<br />
|-<br />
| 0x1EF010C0<br />
| 0x104010C0<br />
| 0x4<br />
| ?<br />
| Writes 0xFFFFFFF0 on GPU init.<br />
|-<br />
| 0x1EF010D0<br />
| 0x104010D0<br />
| 0x4<br />
| ?<br />
| Writes 1 on GPU init.<br />
|-<br />
| 0x1EF014??<br />
| 0x104014??<br />
| 0x14<br />
| "PPF" ?<br />
|<br />
|-<br />
| 0x1EF018E0<br />
| 0x104018E0<br />
| 0x14<br />
| [[#Command_List|Command List]] "P3D"<br />
|<br />
|}<br />
<br />
== Memory Fill ==<br />
{| class="wikitable" border="1"<br />
! User VA<br />
! Description<br />
|-<br />
| 0x1EF000X0<br />
| Buffer start physaddr >> 3<br />
|-<br />
| 0x1EF000X4<br />
| Buffer end physaddr >> 3<br />
|-<br />
| 0x1EF000X8<br />
| Fill value<br />
|-<br />
| 0x1EF000XC<br />
| Control. bit0: start/busy, bit1: finished, bit8-9: fill-width (0=16bit, 1=3=24bit, 2=32bit)<br />
|}<br />
<br />
Memory fills are used to initialize buffers in memory with a given value, similar to memset. A memory fill is triggered by setting bit0 in the control register. Doing so aborts any running memory fills on that filling unit. Upon completion, the hardware unsets bit0 and sets bit1 and fires interrupt PSC0.<br />
<br />
These registers are used by [[GSP Shared Memory#GX SetMemoryFill|GX SetMemoryFill]].<br />
<br />
== LCD Source Framebuffer Setup ==<br />
{| class="wikitable" border="1"<br />
! Offset<br />
! Length<br />
! Name<br />
! Comments<br />
|-<br />
| 0x5C<br />
| 4<br />
| Framebuffer width & height<br />
| Lower 16 bits: width, upper 16 bits: height<br />
|-<br />
| 0x68<br />
| 4<br />
| Framebuffer A first address<br />
| For top screen, this is the left eye 3D framebuffer.<br />
|-<br />
| 0x6C<br />
| 4<br />
| Framebuffer A second address<br />
| For top screen, this is the left eye 3D framebuffer.<br />
|-<br />
| 0x70<br />
| 4<br />
| Framebuffer format<br />
| Bit0-15: framebuffer format, bit16-31: unknown<br />
|-<br />
| 0x78<br />
| 4<br />
| Framebuffer select<br />
| Bit0: which framebuffer to display, bit1-7: unknown<br />
|-<br />
| 0x84<br />
| 4<br />
| Color adjustment register<br />
| Each poke changes the color blended over the screens content randomly.<br />
|-<br />
| 0x90<br />
| 4<br />
| Framebuffer stride<br />
| Distance in bytes between the start of two framebuffer rows (must be a multiple of 8).<br />
|-<br />
| 0x94<br />
| 4<br />
| Framebuffer B first address<br />
| For top screen, this is the right eye 3D framebuffer. Unused for bottom screen.<br />
|-<br />
| 0x98<br />
| 4<br />
| Framebuffer B second address<br />
| For top screen, this is the right eye 3D framebuffer. Unused for bottom screen.<br />
|}<br />
<br />
=== Framebuffer format ===<br />
{| class="wikitable" border="1"<br />
|-<br />
! Bit<br />
! Description<br />
|-<br />
| 2-0<br />
| Color format<br />
|-<br />
| 3<br />
| ?<br />
|-<br />
| 4<br />
| Unused?<br />
|-<br />
| 5<br />
| Enable parallax barrier (i.e. 3D).<br />
|-<br />
| 6<br />
| 1 = main screen, 0 = sub screen. However if bit5 is set, this bit is cleared.<br />
|-<br />
| 7<br />
| ?<br />
|-<br />
| 9-8<br />
| Value 1 = unknown: get rid of rainbow strip on top of screen, 3 = unknown: black screen.<br />
|-<br />
| 15-10<br />
| Unused?<br />
|}<br />
<br />
GSP module only allows the LCD stereoscopy to be enabled when bit5=1 and bit6=0 here. When GSP module updates this register, GSP module will automatically disable the stereoscopy if those bits are not set for enabling stereoscopy.<br />
<br />
=== Framebuffer color formats ===<br />
{| class="wikitable" border="1"<br />
|-<br />
! Value<br />
! Description<br />
|-<br />
| 0<br />
| GL_RGBA8_OES<br />
|-<br />
| 1<br />
| GL_RGB8_OES<br />
|-<br />
| 2<br />
| GL_RGB565_OES<br />
|-<br />
| 3<br />
| GL_RGB5_A1_OES<br />
|-<br />
| 4<br />
| GL_RGBA4_OES<br />
|}<br />
Color components are laid out in reverse byte order, with the most significant bits used first (i.e. non-24-bit pixels are stored as a little-endian values). For instance, a raw data stream of two GL_RGB565_OES pixels looks like GGGBBBBB RRRRRGGG GGGBBBBB RRRRRGGG.<br />
<br />
== Transfer Engine ==<br />
{| class="wikitable" border="1"<br />
! Register address<br />
! Description<br />
|-<br />
| 0x1EF00C00<br />
| Input physical address >> 3<br />
|-<br />
| 0x1EF00C04<br />
| Output physical address >> 3<br />
|-<br />
| 0x1EF00C08<br />
| DisplayTransfer output width (bits 0-15) and height (bits 16-31).<br />
|-<br />
| 0x1EF00C0C<br />
| DisplayTransfer input width and height.<br />
|-<br />
| 0x1EF00C10<br />
| Transfer flags. (See below)<br />
|-<br />
| 0x1EF00C14<br />
| GSP module writes value 0 here prior to writing to 0x1EF00C18, for cmd3.<br />
|-<br />
| 0x1EF00C18<br />
| Setting bit0 starts the transfer. Upon completion, bit0 is unset and bit8 is set.<br />
|-<br />
| 0x1EF00C20<br />
| TextureCopy total amount of data to copy, in bytes.<br />
|-<br />
| 0x1EF00C24<br />
| TextureCopy input line width (bits 0-15) and gap (bits 16-31), in bytes.<br />
|-<br />
| 0x1EF00C28<br />
| TextureCopy output line width and gap.<br />
|}<br />
<br />
These registers are used by [[GSP_Shared_Memory|GX command]] 3 and 4. For cmd4, *0x1EF00C18 |= 1 is used instead of just writing value 1. The DisplayTransfer registers are only used if bit 3 of the flags is unset and ignored otherwise. The TextureCopy registers are likewise only used if bit 3 is set, and ignored otherwise.<br />
<br />
==== Flags Register - 0x1EF00C10 ====<br />
{| class="wikitable" border="1"<br />
! Bit<br />
! Description<br />
|-<br />
| 0<br />
| When set, the framebuffer data is flipped vertically.<br />
|-<br />
| 1<br />
| When set, the input framebuffer is treated as linear and converted to tiled in the output, converts tiled->linear when unset.<br />
|-<br />
| 2<br />
| This bit is required when the output width is less than the input width for the hardware to properly crop the lines, otherwise the output will be mis-aligned.<br />
|-<br />
| 3<br />
| Uses a TextureCopy mode transfer. See below for details.<br />
|-<br />
| 4<br />
| Not writable<br />
|-<br />
| 5<br />
| Don't perform tiled-linear conversion. Incompatible with bit 1, so only tiled-tiled transfers can be done, not linear-linear.<br />
|-<br />
| 7-6<br />
| Not writable<br />
|-<br />
| 10-8<br />
| Input framebuffer color format, value0 and value1 are the same as the [[GPU Registers#Framebuffer_color_formats|LCD Source Framebuffer Formats]] (usually zero)<br />
|-<br />
| 11<br />
| Not writable<br />
|-<br />
| 14-12<br />
| Output framebuffer color format<br />
|-<br />
| 15<br />
| Not writable<br />
|-<br />
| 16<br />
| Use 32x32 block tiling mode, instead of the usual 8x8 one. Output dimensions must be multiples of 32, even if cropping with bit 2 set above.<br />
|-<br />
| 17-23<br />
| Not writable<br />
|-<br />
| 24-25<br />
| Scale down the input image using a box filter. 0 = No downscale, 1 = 2x1 downscale. 2 = 2x2 downscale, 3 = invalid<br />
|-<br />
| 31-26<br />
| Not writable<br />
|}<br />
<br />
=== TextureCopy ===<br />
<br />
When bit 3 of the control register is set, the hardware performs a TextureCopy-mode transfer. In this mode, all other bits of the control register (except for bit 2, which still needs to be set correctly) and the regular dimension registers are ignored, and no format conversions are done. Instead, it performs a raw data copy from the source to the destination, but with a configurable gap between lines. The total amount of bytes to copy is specified in the size register, and the hardware loops reading lines from the input and writing them to the output until this amount is copied. The "gap" specified in the input/output dimension register is the number of bytes to skip after each "width" bytes of the input/output, and is NOT counted towards the total size of the transfer.<br />
<br />
By correctly calculating the input and output gap sizes it is possible to use this functionality to copy arbitrary sub-rectangles between differently-sized framebuffers or textures, which is one of its main uses over a regular no-conversion DisplayTransfer. When copying tiled textures/framebuffers it's important to remember that the contents of a tile are laid out sequentially in memory, and so this should be taken into account when calculating the transfer parameters.<br />
<br />
Specifying invalid/junk values for the TextureCopy dimensions can result in the GPU hanging while attempting to process this TextureCopy.<br />
<br />
== Command List ==<br />
{| class="wikitable" border="1"<br />
! Register address<br />
! Description<br />
|-<br />
| 0x1EF018E0<br />
| Buffer size in bytes >> 3<br />
|-<br />
| 0x1EF018E8<br />
| Buffer physical address >> 3<br />
|-<br />
| 0x1EF018F0<br />
| Setting bit0 to 1 enables processing GPU command execution. Upon completion, bit0 seems to be reset to 0.<br />
|}<br />
<br />
These 3 registers are used by [[GSP_Shared_Memory|GX command]] 1. This is used for [[GPU/Internal_Registers|GPU commands]].<br />
<br />
== Framebuffers ==<br />
These LCD framebuffers normally contain the last rendered frames from the GPU. The framebuffers are drawn from left-to-right, instead of top-to-bottom.(Thus the beginning of the framebuffer is drawn starting at the left side of the screen)<br />
<br />
Both of the 3D screen left/right framebuffers are displayed regardless of the 3D slider's state, however when the 3D slider is set to "off" the 3D effect is disabled. Normally when the 3D slider's state is set to "off" the left/right framebuffer addresses are set to the same physical address. When the 3D effect is disabled and the left/right framebuffers are set to separate addresses, the LCD seems to alternate between displaying the left/right framebuffer each frame.<br />
<br />
==== Init Values from nngxInitialize for Top Screen ====<br />
* 0x1EF00400 = 0x1C2<br />
* 0x1EF00404 = 0xD1<br />
* 0x1EF00408 = 0x1C1<br />
* 0x1EF0040C = 0x1C1<br />
* 0x1EF00410 = 0<br />
* 0x1EF00414 = 0xCF<br />
* 0x1EF00418 = 0xD1<br />
* 0x1EF0041C = 0x1C501C1<br />
* 0x1EF00420 = 0x10000<br />
* 0x1EF00424 = 0x19D<br />
* 0x1EF00428 = 2<br />
* 0x1EF0042C = 0x1C2<br />
* 0x1EF00430 = 0x1C2<br />
* 0x1EF00434 = 0x1C2<br />
* 0x1EF00438 = 1<br />
* 0x1EF0043C = 2<br />
* 0x1EF00440 = 0x1960192<br />
* 0x1EF00444 = 0<br />
* 0x1EF00448 = 0<br />
* 0x1EF0045C = 0x19000F0<br />
* 0x1EF00460 = 0x1c100d1<br />
* 0x1EF00464 = 0x1920002<br />
* 0x1EF00470 = 0x80340<br />
* 0x1EF0049C = 0<br />
<br />
==== More Init Values from nngxInitialize for Top Screen ====<br />
* 0x1EF00468 = 0x18300000, later changed by GSP module when updating state, framebuffer<br />
* 0x1EF0046C = 0x18300000, later changed by GSP module when updating state, framebuffer<br />
* 0x1EF00494 = 0x18300000<br />
* 0x1EF00498 = 0x18300000<br />
* 0x1EF00478 = 1, doesn't stay 1, read as 0<br />
* 0x1EF00474 = 0x10501<br />
<br />
[[Category:GPU]]</div>Mrrraouhttps://www.3dbrew.org/w/index.php?title=3DS_System_Flaws&diff=191253DS System Flaws2017-01-02T18:21:17Z<p>Mrrraou: more info</p>
<hr />
<div>Exploits are used to execute unofficial code (homebrew) on the Nintendo 3DS. This page is a list of publicly known system flaws, for userland applications/applets flaws see [[3DS_Userland_Flaws|here]].<br />
<br />
=Stale / Rejected Efforts=<br />
* Neimod has been working on a RAM dumping setup for a little while now. He's de-soldered the 3DS's RAM chip and hooked it and the RAM pinouts on the 3DS' PCB up to a custom RAM dumping setup. A while ago he published photos showing his setup to be working quite well, with the 3DS successfully booting up. However, his flickr stream is now private along with most of his work.<br />
<br />
* Someone (who will remain unnamed) has released CFW and CIA installers, all of which is copied from the work of others, or copyrighted material.<br />
<br />
==Tips and info==<br />
The 3DS uses the XN feature of the ARM11 processor. There's no official way from applications to enable executable permission for memory containing arbitrary unsigned code(there's a [[SVC]] for this, but only [[RO_Services|RO-module]] has access to it). A usable userland exploit would still be useful: you could only do return-oriented-programming with it initially. From ROP one could then exploit system flaw(s), see below.<br />
<br />
SD card [[extdata]] and SD savegames can be attacked, for consoles where the console-unique [[Nand/private/movable.sed|movable.sed]] was dumped(accessing SD data is far easier by running code on the target 3DS however).<br />
<br />
=System flaws=<br />
== Hardware ==<br />
{| class="wikitable" border="1"<br />
! Summary<br />
! Description<br />
! Fixed with hardware model/revision<br />
! Newest hardware model/revision this flaw was checked for<br />
! Timeframe this was discovered<br />
! Discovered by<br />
|-<br />
| ARM9/ARM11 bootrom vectors point at uninitialized RAM<br />
| ARM9's and ARM11's exception vectors are hardcoded to point at the CPU's internal memory (0x08000000 region for ARM9, AXIWRAM for ARM11). While the bootrom does set them up to point to an endless loop at some point during boot, it does not do so immediately. As such, a carefully-timed fault injection (via hardware) to trigger an exception (such as an invalid instruction) will cause execution to fall into ARM9 RAM. <br />
Since RAM isn't cleared on boot (see below), one can immediately start execution of their own code here to dump bootrom, OTP, etc.<br />
The ARM9 bootrom does the following at reset: reset vector branches to another instruction, then branches to bootrom+0x8000. Hence, there's no way to know for certain when exactly the ARM9 exception-vector data stored in memory gets initialized.<br />
<br />
This requires *very* *precise* timing for triggering the hardware fault.<br />
<br />
It has been exploited by derrek to dump the ARM9 bootrom as of Summer 2015.<br />
| None: all available 3DS models at the time of writing have the exact same ARM9/ARM11 bootrom for the unprotected areas.<br />
| New3DS<br />
| End of February 2014<br />
| [[User:Derrek|derrek]], WulfyStylez (May 2015) independently<br />
|-<br />
| Missing AES key clearing<br />
| The hardware AES engine does not clear keys when doing a hard reset/reboot.<br />
| None<br />
| New3DS<br />
| August 2014<br />
| Mathieulh/Others<br />
|-<br />
| No RAM clearing on reboots<br />
| On an MCU-triggered reboot all RAM including FCRAM/ARM9 memory/AXIWRAM/VRAM keeps its contents.<br />
| None<br />
| New3DS<br />
| March 2014<br />
| [[User:Derrek|derrek]]<br />
|-<br />
| 32bits of actual console-unique TWLNAND keydata<br />
| On retail the 8-bytes at ARM9 address [[Memory_layout|0x01FFB808]] are XORed with hard-coded data, to generate the TWL console-unique keys, including TWLNAND. On Old3DS the high u32 is always 0x0, while on New3DS that u32 is always 0x2. On top of this, the lower u32's highest bit is always ORed. only 31 bits of the TWL console-unique keydata / TWL consoleID are actually console-unique.<br />
This allows one to easily bruteforce the TWL console-unique keydata with *just* data from TWLNAND. On DSi the actual console-unique data for key generation is 8-bytes(all bytes actually set).<br />
| None<br />
| New3DS<br />
| 2012?<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| DSi / 3DS-TWL key-generator<br />
| After using the key generator to generate the normal-key, you could overwrite parts of the normal-key with your own data and then recover the key-generator output by comparing the new crypto output with the original crypto output. From the normal-key outputs, you could deduce the TWL key-generator function.<br />
This applies to the keyX/keyY too.<br />
<br />
This attack does not work for the 3DS key-generator because keyslots 0-3 are only for TWL keys.<br />
| None<br />
| New3DS<br />
| 2011<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| 3DS key-generator<br />
| The algorithm for generating the normal-keys for keyslots is cryptographically weak. As a result, it is easily susceptible to differential cryptanalysis if the normal-key corresponding to any scrambler-generated keyslot is discovered.<br />
<br />
Several such pairs of matching normal-keys and KeyY values were found, leading to deducing the key-generator function.<br />
| None<br />
| New3DS<br />
| February 2015<br />
| [[User:Yellows8|Yellows8]], [[User:Plutooo|plutoo]]<br />
|-<br />
| FIRM partitions known-plaintext<br />
| The [[Flash_Filesystem|FIRM partitions]] are encrypted with AES-CTR without a MAC. Since this works by XOR'ing data with a static (per-console in this case) keystream, one can deduce the keystream of a portion of each FIRM partition if they have the actual FIRM binary stored in it.<br />
<br />
This can be paired with many exploits. For example, it allows minor FIRM downgrades (i.e. 10.4 to 9.6 or 9.5 to 9.4, but not 9.6 to 9.5).<br />
<br />
This can be somewhat addressed by having a FIRM header skip over previously used section offsets, but this would just air-gap newer FIRMs without fixing the core bug. This can also only be done a limited number of times due to the size of FIRM versus the size of the partitions.<br />
| None<br />
| New3DS<br />
| <br />
| Everyone<br />
|}<br />
<br />
== ARM9 software ==<br />
<br />
=== arm9loader ===<br />
{| class="wikitable" border="1"<br />
|-<br />
! Summary<br />
! Description<br />
! Successful exploitation result<br />
! Fixed in [[FIRM]] system version<br />
! Last [[FIRM]] system version this flaw was checked for<br />
! Timeframe this was discovered<br />
! Public disclosure timeframe<br />
! Discovered by<br />
|-<br />
| Rearrangable keys in the NAND keystore<br />
| Due to the keystore being encrypted with AES-ECB, one can rearrange blocks and still have the NAND keystore decrypt in a deterministic way. <br />
<br />
Using 10.0 FIRM it is possible to rearrange keys such that ARM9 memory is executed. As such using existing ARM9 execution 10.0 FIRM can be written to NAND and a payload written to memory, with the payload to be executed post-K9L using an MCU reboot.<br />
| arm9loaderhax given existing ARM9 code execution<br />
| None<br />
| [[11.2.0-35|11.2.0-X]]<br />
| Early 2016<br />
| 27 September 2016<br />
| Myria, [[User:Dark samus|dark_samus]]; mathieulh (independently); [[User:Plutooo|plutoo]] (independently) + others<br />
|-<br />
| Uncleared OTP hash keydata in console-unique 0x11 key-generation<br />
| Kernel9Loader does not clear the [[SHA_Registers#SHA_HASH|SHA_HASH register]] after use. As a result, the data stored here as K9L hands over to Kernel9 is the hash of [[OTP_Registers|OTP data]] used to seed the [[FIRM#New_3DS_FIRM|console-unique NAND keystore decryption key]] set on keyslot 0x11.<br />
<br />
Retrieving this keydata and the [[Flash_Filesystem#0x12C00|NAND keystore]] of the same device allows calculating the decrypted New3DS NAND keystore (non-unique, common to all New3DS units), which contains AES normal keys, also set on keyslot 0x11, which are then used to derive all current [[AES_Registers#Keyslots|New3DS-only AES keyXs]] including the newer batch introduced in [[9.6.0-24#arm9loader|9.6.0-X]]. From there, it is trivial to perform the same key derivation in order to initialize those keys on any system version, and even on Old3DS.<br />
<br />
This can be performed by exploiting the "arm9loaderhax" vulnerability to obtain post-K9L code execution after an MCU reboot (the bootrom section-loading fail is not relevant here, this attack was performed without OTP data by brute-forcing keys), and using this to dump the SHA_HASH register. This attack works on any FIRM version shipping a vulnerable version of K9L, whereas OTP dumping required a boot of <[[3.0.0-6|3.0.0-X]].<br />
<br />
This attack results in obtaining the entire (0x200-bytes) NAND keystore - it was confirmed at a later date that this keystore is encrypted with the same key (by comparing the decrypted data from multiple units), and therefore using another key in this store will not remedy the issue as all keys are known (i.e. later, unused keys decrypt to the same 0x200-bytes constant with the same OTP hash). Later keys could have been encrypted differently but this is not the case. As a result of this, it is not possible for Nintendo to use K9L again in its current format for its intended purpose, though this was not news from the moment people dumped a New3DS OTP.<br />
| Derivation of all New3DS keys generated via the NAND keystore (0x1B "Secure4" etc.)<br />
| None<br />
| [[11.2.0-35|11.2.0-X]]<br />
| ~April 2015, implemented in May 2015<br />
| 13 January 2016<br />
| [[User:WulfyStylez|WulfyStylez]], [[User:Dazzozo|Dazzozo]], [[User:Shinyquagsire23|shinyquagsire23]] (complimentary + implemented), [[User:Plutooo|plutoo]], Normmatt (discovered independently)<br />
|-<br />
| enhanced-arm9loaderhax<br />
| See the 32c3 3ds talk.<br />
Since this is a combination of a trick with the arm9-bootrom + arm9loaderhax, and since you have to manually write FIRM to the firm0/firm1 NAND partitions, this can't be completely fixed. Any system with existing ARM9 code execution and an OTP/OTP hash dump can exploit this. Additionally, by using the FIRM partition known-plaintext bug and bruteforcing the second entry in the keystore, this can currently be exploited on all New3DS systems without any other prerequisite hacks.<br />
| arm9loaderhax which automatically occurs at hard-boot.<br />
| See arm9loaderhax / description.<br />
| See arm9loaderhax / description.<br />
| Theorized around mid July, 2015. Later implemented+tested by [[User:Plutooo|plutoo]] and [[User:Derrek|derrek]].<br />
| 32c3 3ds talk (December 27, 2015)<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| Missing verification-block for the 9.6 keys (arm9loaderhax)<br />
| Starting with [[9.6.0-24|9.6.0-X]] a new set of NAND-based keys were introduced. However, no verification block was added to verify that the new key read from NAND is correct. This was technically an issue from [[9.5.0-22|9.5.0-X]] with the original sector+0 keydata, however the below is only possible with [[9.6.0-24|9.6.0-X]] since keyslots 0x15 and 0x16 are generated from different 0x11 keyXs.<br />
<br />
Writing an incorrect key to NAND will cause arm9loader to decrypt the ARM9 kernel as garbage and then jump to it.<br />
<br />
This allows an hardware-based attack where you can boot into an older exploited firmware, fill all memory with NOP sleds/jump-instructions, and then reboot into executing garbage. By automating this process with various input keydata, eventually you'll find some garbage that jumps to your code.<br />
<br />
This gives very early ARM9 code execution (pre-ARM9 kernel). As such, it is possible to dump RSA keyslots with this and calculate the 6.x [[Savegames#6.0.0-11_Savegame_keyY|save]], and 7.x [[NCCH]] keys. This cannot be used to recover keys initialized by arm9loader itself. This is due to it wiping the area used for its stack during NAND sector decryption and keyslot init. <br />
<br />
Due to FIRMs on both Old and New 3DS using the same RSA data, this can be exploited on Old3DS as well, but only if one already has the actual plaintext normalkey from New3DS NAND sector 0x96 offset-0 and has dumped the OTP area of the Old3DS.<br />
| Recovery of 6.x [[Savegames#6.0.0-11_Savegame_keyY|save key]]/7.x [[NCCH]] key, access to uncleared OTP hash keydata<br />
| None<br />
| [[11.2.0-35|11.2.0-X]]<br />
| March, 2015<br />
| <br />
| [[User:Plutooo|plutoo]]<br />
|-<br />
| Uncleared New3DS keyslot 0x11<br />
| Originally the New3DS [[FIRM]] arm9bin loader only cleared keyslot 0x11 when it gets executed at firmlaunch. This was fixed with [[9.5.0-22|9.5.0-X]] by completely clearing keyslot 0x11 immediately after the loader finishes using keyslot 0x11.<br />
This means that any ARM9 code that can execute before the loader clears the keyslot at firmlaunch(including firmlaunch-hax) can get access to the uncleared keyslot 0x11, which then allows one to generate all <=v9.5 New3DS keyXs which are generated by keyslot 0x11.<br />
<br />
Therefore, to completely fix this the loader would have to generate more keys using different keyslot 0x11 keydata. This was done with [[9.6.0-24|9.6.0-X]].<br />
| New3DS keyXs generation<br />
| Mostly fixed with [[9.5.0-22|9.5.0-X]], completely fixed with new keys with [[9.6.0-24|9.6.0-X]].<br />
| <br />
| February 3, 2015 (one day after [[9.5.0-22|9.5.0-X]] release)<br />
| <br />
| [[User:Yellows8|Yellows8]]<br />
|}<br />
<br />
=== Process9 ===<br />
{| class="wikitable" border="1"<br />
|-<br />
! Summary<br />
! Description<br />
! Successful exploitation result<br />
! Fixed in [[FIRM]] system version<br />
! Last [[FIRM]] system version this flaw was checked for<br />
! Timeframe this was discovered<br />
! Public disclosure timeframe<br />
! Discovered by<br />
|-<br />
| Leak of normal-key matching a key-scrambler key<br />
| New 3DS firmware versions [[8.1.0-0 New3DS|8.1.0]] through [[9.2.0-20|9.2.0]] set the encryption key for [[Amiibo]] data using a hardcoded normal-key in Process9. In firmware [[9.3.0-21|9.3.0]], Nintendo "fixed" this by using the key scrambler instead, by calculating the keyY value for keyslot 0x39 that results in the same normal-key, then hardcoding that keyY into Process9.<br />
<br />
Nintendo's fix is actually the problem: Nintendo revealed the normal-key matching an unknown keyX and a known keyY. Combined with the key scrambler using an insecure scrambling algorithm (see "Hardware" above), the key scrambler function could be deduced.<br />
| Deducing the keyX for keyslot 0x39 and the key scrambler algorithm<br />
| New 3DS [[9.3.0-21|9.3.0-X]], sort of<br />
| [[10.0.0-27|10.0.0-X]]<br />
| Sometime in 2015 after the hardware key-generator was broken.<br />
| 32c3 3ds talk (December 27, 2015)<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| Leak of normal-key matching a key-generator key<br />
| During the 3DS' development (June/July 2010) Nintendo added support installing encrypted content ([[CIA]]). Common-key index1 was intended to be a [[AES|hardware generated key]]. However while they added code to generate the key in hardware, they forgot to remove the normal-key for index1 (used elsewhere, likely old debug code). Nintendo later removed the normal key sometime before the first non-prototype firmware release.<br />
<br />
<br />
Knowing the keyY and the normal-key for common-key index1, the devkit key-generator algorithm can be deduced (see "Hardware" above). Additionally the remaining devkit common-keys can be generated once the common-key keyX is recovered.<br />
<br />
Note the devkit key-generator was discovered to be the same as the retail key-generator.<br />
| Deducing the keyX for keyslot 0x3D and hardware key-generator algorithm. Generate remaining devkit common-keys.<br />
| pre-[[1.0.0-0|1.0.0-X]]<br />
| <br />
| Shortly after the key-generator was revealed to be flawed at the 32c3 3ds talk<br />
| January 20, 2016<br />
| [[User:Jakcron|jakcron]]<br />
|-<br />
| safefirmhax<br />
| SAFE_MODE_FIRM is almost never updated(even when NATIVE_FIRM is updated for vuln fixes), this can be noticed by ''just'' checking 3dbrew/ninupdates title-listings.<br />
<br />
The fix for firmlaunchhax was only applied to NATIVE_FIRM in [[9.5.0-22|9.5.0-X]], leaving SAFE_FIRM exploitable. With ARM11-kernel execution, one can trigger FIRM-launch in to SAFE_FIRM, do Kernel9 <=> Kernel11 sync, PXI sync and then repeat the original attack on SAFE_FIRM instead.<br />
| ARM9 code execution<br />
| None<br />
| <br />
| <br />
| <br />
| Everyone<br />
|-<br />
| ntrcardhax<br />
| <br />
| ARM9 code execution<br />
| 10.4.0-29<br />
| <br />
| March 2015<br />
| 32c3 3ds talk (December 27, 2015)<br />
| [[User:Plutooo|plutoo]]<br />
|-<br />
| Title downgrading via [[Application_Manager_Services|AM]]([[Application_Manager_Services_PXI|PXI]])<br />
| When a title is *already* installed, Process9 will compare the installed title-version with the title-version being installed. When the one being installed is older, Process9 would return an error.<br />
<br />
However, this can be bypassed by just deleting the title first via the service command(s) for that: with the title removed from the [[Title_Database]], Process9 can't compare the input title-version with anything. Hence, titles can be downgraded this way.<br />
<br />
[[11.0.0-33|11.0.0-X]] fixed this for key system titles (MSET, Home Menu, spider, ErrDisp, SKATER, NATIVE_FIRM, and every retail system module), by checking the version of the title to install against a hard-coded list of (titleID, minimumVersionRequired) pairs.<br />
| Bypassing title version check at installation, which then allows downgrading any title.<br />
| [[11.0.0-33|11.0.0-X]], for key system titles.<br />
| NATIVE_FIRM / AM-sysmodule [[11.0.0-33|11.0.0-X]]<br />
| ?<br />
| <br />
| ?<br />
|-<br />
| FAT FS code null-deref<br />
| When FSFile:Read is used with a file which is corrupted on a FAT filesystem(in particular SD), Process9 can crash. This particular crash is caused by a function returning NULL instead of an actual ptr due to an error. The caller of that function doesn't check for NULL which then triggers a read based at NULL.<br />
<br />
Sample "fsck.vfat -n -v -V <fat image backup>" output for the above crash:<br />
<br />
<pre>...<br />
Starting check/repair pass.<br />
<FilePath0> and<br />
<FilePath1><br />
share clusters.<br />
Truncating second to 3375104 bytes.<br />
<FilePath1><br />
File size is 2787392 bytes, cluster chain length is 16384 bytes.<br />
Truncating file to 16384 bytes.<br />
Checking for unused clusters.<br />
Reclaimed 1 unused cluster (16384 bytes).<br />
Checking free cluster summary.<br />
Free cluster summary wrong (1404490 vs. really 1404491)<br />
Auto-correcting.<br />
Starting verification pass.<br />
Checking for unused clusters.<br />
Leaving filesystem unchanged.</pre><br />
| Useless null-based-read<br />
| None<br />
| [[9.6.0-24|9.6.0-X]]<br />
| July 8-9, 2015<br />
| <br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| RSA signature padding checks<br />
| The TWL_FIRM RSA sig padding check code used for all TWL RSA sig-checks has issues, see [[FIRM|here]].<br />
The main 3DS RSA padding check code(non-certificate, including NATIVE_FIRM) uses the function used with the above to extract more padding + the actual hash from the additional padding. This isn't really a problem here because there's proper padding check code which is executed prior to this.<br />
| <br />
| None<br />
| [[9.5.0-22|9.5.0-X]]<br />
| March 2015<br />
| <br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[AMPXI:ValidateDSiWareSectionMAC]] [[AES_Registers|AES]] keyslot reuse<br />
| When the input DSiWare section index is higher than <max number of DSiWare sections supported by this FIRM>, Process9 uses keyid 0x40 for calculating the AESMAC, which translates to keyslot 0x40. The result is that the keyslot is left at whatever was already selected before, since the AES selectkeyslot code will immediately return when keyslot is >=0x40. However, actually exploiting this is difficult: the calculated AESMAC is never returned, this command just compares the calculated AESMAC with the input AESMAC(result-code depends on whether the AESMACs match). It's unknown whether a timing attack would work with this.<br />
This is basically a different form of the pxips9 keyslot vuln, except with AESMAC etc.<br />
| See description.<br />
| None<br />
| [[11.2.0-35|11.2.0-X]]<br />
| March 15, 2015<br />
| December 29, 2015<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| pxips9 [[AES_Registers|AES]] keyslot reuse<br />
| This requires access to the [[Process_Services|ps:ps]]/pxi:ps9 services. One way to get access to this would be snshax on system-version <=10.1.0-X(see 32c3 3ds talk).<br />
When an invalid key-type value is passed to any of the PS commands, Process9 will try to select keyslot 0x40. That aesengine_setkeyslot() code will then immediately return due to the invalid keyslot value. Since that function doesn't return any errors, Process9 will just continue to do crypto with whatever AES keyslot was selected before the PS command was sent.<br />
| Reusing the previously used keyslot, for crypto with PS.<br />
| None<br />
| [[11.2.0-35|11.2.0-X]]<br />
| Roughly the same time(same day?) as firmlaunch-hax.<br />
| December 29, 2015<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| firmlaunch-hax: FIRM header ToCToU<br />
| This can't be exploited from ARM11 userland.<br />
During [[FIRM]] launch, the only FIRM header the ARM9 uses at all is stored in FCRAM, this is 0x200-bytes(the actual used FIRM RSA signature is read to the Process9 stack however). The ARM9 doesn't expect "anything" besides the ARM9 to access this data.<br />
With [[9.5.0-22]] the address of this FIRM header was changed from a FCRAM address, to ARM9-only address 0x01fffc00.<br />
| ARM9 code execution<br />
| [[9.5.0-22]]<br />
| <br />
| 2012, 3 days after [[User:Yellows8|Yellows8]] started Process9 code RE.<br />
| <br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| Uninitialized data output for (PXI) command replies<br />
| PXI commands for various services(including some [[Filesystem_services_PXI|here]] and many others) can write uninitialized data (like from ARM registers) to the command reply. This happens with stubbed commands, but this can also occur with certain commands when returning an error.<br />
Certain ARM11 service commands have this same issue as well.<br />
| <br />
| None<br />
| [[9.3.0-21|9.3.0-X]]<br />
| ?<br />
| <br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[Filesystem_services_PXI|FSPXI]] OpenArchive SD permissions<br />
| Process9 does not use the exheader ARM9 access-mount permission flag for SD at all.<br />
This would mean ARM11-kernelmode code / fs-module itself could directly use FSPXI to access SD card without ARM9 checking for SD access, but this is rather useless since a process is usually running with SD access(Home Menu for example) anyway.<br />
| <br />
| None<br />
| [[9.3.0-21|9.3.0-X]]<br />
| 2012<br />
| <br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[AMPXI:ExportDSiWare]] export path<br />
| Process9 allocates memory on Process9 heap for the export path then verifies that the actual allocated size matches the input size. Then Process9 copies the input path from FCRAM to this buffer, and uses it with the Process9 FS openfile code, which use paths in the form of "<mountpoint>:/<path>".<br />
Process9 does not check the contents of this path at all before passing it to the FS code, besides writing a NUL-terminator to the end of the buffer.<br />
| Exporting of DSiWare to arbitrary Process9 file-paths, such as "nand:/<path>" etc. This isn't really useful since the data which gets written can't be controlled.<br />
| None<br />
| [[9.5.0-22]]<br />
| April 2013<br />
| <br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[DSiWare_Exports]] [[CTCert]] verification<br />
| Just like DSi originally did, 3DS verifies the APCert for DSiWare on SD with the CTCert also in the DSiWare .bin. On DSi this was fixed with with system-version 1.4.2 by verifying with the actual console-unique cert instead(stored in NAND), while on 3DS it's still not(?) fixed.<br />
On 3DS however this is rather useless, due to the entire DSiWare .bin being encrypted with the console-unique movable.sed keyY.<br />
| When the movable.sed keyY for the target 3DS is known and the target 3DS CTCert private-key is unknown, importing of modified DSiWare SD .bin files.<br />
| Unknown, probably none.<br />
| ?<br />
| April 2013<br />
| <br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[Gamecard_Services_PXI]] unchecked REG_CTRCARDCNT transfer-size<br />
| The u8 REG_CTRCARDCNT transfer-size parameter for the [[Gamecard_Services_PXI]] read/write CTRCARD commands is used as an index for an array of u16 values. Before [[5.0.0-11|5.0.0-X]] this u8 value wasn't checked, thus out-of-bounds reads could be triggered(which is rather useless in this case).<br />
| Out-of-bounds read for a value which gets written to a register.<br />
| [[5.0.0-11|5.0.0-X]]<br />
| <br />
| 2013?<br />
| <br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[PXI_Registers|PXI]] cmdbuf buffer overrun<br />
| The Process9 code responsible [[PXI_Registers|PXI]] communications didn't verify the size of the incoming command before writing it to a C++ member variable. <br />
| Probably ARM9 code execution<br />
| [[5.0.0-11|5.0.0-11]]<br />
| <br />
| March 2015, original timeframe if any unknown<br />
| <br />
| [[User:Plutooo|plutoo]]/[[User:Yellows8|Yellows8]]/maybe others(?)<br />
|-<br />
| [[Application_Manager_Services_PXI|PXIAM]] command 0x003D0108(See also [[Application_Manager_Services|this]])<br />
| When handling this command, Process9 allocates a 0x2800-byte heap buffer, then copies the 4 FCRAM input buffers to this heap buffer without checking the sizes at all(only the buffers with non-zero sizes are copied). Starting with [[5.0.0-11|5.0.0-X]], the total combined size of the input data must be <=0x2800.<br />
| ARM9 code execution<br />
| [[5.0.0-11|5.0.0-X]]<br />
| <br />
| May 2013<br />
| <br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[Process_Services_PXI|PS RSA]] commands buffer overflows<br />
| pxips9 cmd1(not accessible via ps:ps) and VerifyRsaSha256: unchecked copy to a buffer in Process9's .bss, from the input FCRAM buffer. The buffer is located before the pxi cmdhandler threads' stacks. SignRsaSha256 also has a buf overflow, but this isn't exploitable.<br />
The buffer for this is the buffer for the signature data. With v5.0, the signature buffer was moved to stack, with a check for the signature data size. When the signature data size is too large, Process9 uses [[SVC|svcBreak]].<br />
| ARM9 code execution<br />
| [[5.0.0-11|5.0.0-X]]<br />
| <br />
| 2012<br />
| <br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[PXI_Registers|PXI]] pxi_id bad check<br />
| The Process9 code responsible for [[PXI_Registers|PXI]] communications read pxi_id as a signed char. There were two flaws:<br />
* They used it as index to a lookup-table without checking the value at all.<br />
* Another function verified that pxi_id < 7, allowing negative values to pass the check. This would also cause an out-of-range table-lookup.<br />
| Maybe ARM9 code execution<br />
| [[3.0.0-5|3.0.0-5]]<br />
|<br />
| March 2015, originally 2012 for the first issue at least<br />
| <br />
| [[User:Plutooo|plutoo]], [[User:Yellows8|Yellows8]], maybe others(?)<br />
|}<br />
<br />
=== Kernel9 ===<br />
{| class="wikitable" border="1"<br />
|-<br />
! Summary<br />
! Description<br />
! Successful exploitation result<br />
! Fixed in [[FIRM]] system version<br />
! Last [[FIRM]] system version this flaw was checked for<br />
! Timeframe this was discovered<br />
! Discovered by<br />
|-<br />
| [[CONFIG Registers#CFG_SYSPROT9|CFG_SYSPROT9]] bit1 not set by Kernel9<br />
| Old versions of Kernel9 never set bit1 of [[CONFIG Registers#CFG_SYSPROT9|CFG_SYSPROT9]]. This leaves the [[OTP Registers|0x10012000]]-region unprotected (this region should be locked early during boot!). Since it's never locked, you can dump it once you get ARM9 code execution.<br />
<br />
From [[3.0.0-5|3.0.0-X]] this was fixed by setting the bit in Kernel9 after poking some registers in that region. On New3DS arm9loader sets this bit instead of Kernel9, which is exploitable through a hardware + software vulnerability (see arm9loaderhax / description).<br />
<br />
This flaw resurged when it gained a new practical use: retrieving the OTP data for a New3DS console in order to decrypt the key data used in arm9loader (see enhanced-arm9loaderhax / description). This was performed by downgrading to a vulnerable system version. By accounting for differences in CTR-NAND crypto (0x05 -> 0x04, see partition encryption types [[Flash_Filesystem#NAND_structure|here]]), it is possible to boot a New3DS using Old3DS firmware 1.0-2.X and an Old3DS [[NCSD#NCSD_header|NCSD Header]] to retrieve the required OTP data using this flaw.<br />
| Dumping of the [[OTP Registers|OTP]] area<br />
| [[3.0.0-5|3.0.0-X]]<br />
|<br />
| February 2015<br />
| [[User:Plutooo|plutoo]], Normmatt independently<br />
|}<br />
<br />
== ARM11 software ==<br />
=== Kernel11 ===<br />
{| class="wikitable" border="1"<br />
|-<br />
! Summary<br />
! Description<br />
! Successful exploitation result<br />
! Fixed in [[FIRM]] system version<br />
! Last [[FIRM]] system version this flaw was checked for<br />
! Timeframe this was discovered<br />
! Discovered by<br />
|-<br />
| [[SVC]] table too small<br />
| The table of function pointers for SVC's only contains entries up to 0x7D, but the biggest allowed SVC for the table is 0x7F. Thus, executing SVC7E or SVC7F would make the SVC-handler read after the buffer, and interpret some ARM instructions as function pointers.<br />
<br />
However, this would require patching the kernel .text or modifying SVC-access-control. Even if you could get these to execute, they would still jump to memory that isn't mapped as executable.<br />
| <br />
| None<br />
| [[11.2.0-35|11.2.0-X]]<br />
| 2012<br />
| Everyone<br />
|-<br />
| [[SVC|svcBackdoor (0x7B)]]<br />
| This backdoor allows executing SVC-mode code at the user-specified code-address. This is used by Process9, using this on the ARM11 (with NATIVE_FIRM) required patching the kernel .text or modifying SVC-access-control.<br />
| See description<br />
| [[11.0.0-33|11.0.0-X]] (deleted)<br />
| <br />
|<br />
| Everyone<br />
|-<br />
| veryslowpidhax<br />
| '''This is completely different from the kernelmode-code-execution vuln described in the below separate entry.'''<br />
<br />
When updating the kernel global PID counter under [[SVC|svcCreateProcess]] the kernel does not check for wraparound to 0x0(the PID for the very first process). This only matters because [[Services|SM-module]] allows processes with PID value less than <total ARM11 FIRM modules> to access ''all'' services, without checking exheader service-access-control; and because Kernel11 checks for the PID to be 1 (loader) to use the input mem-region value on ControlMemory. This alone does not affect access the [[SVC|SVCs]] access table at all.<br />
<br />
Inlined ldrex+strex code is used for updating the above counter. [[11.2.0-35|11.2.0-X]] had changes for similar code, but it was only for dedicated ldrex+strex functions(mainly for kernel objects) and hence this PID code was not affected.<br />
<br />
With launching+terminating a sysmodule repeatedly with this via ns:s, it would take weeks to finish(if not at least about a month?).<br />
| Access to all [[Services_API|services]], ControlMemory on any given mem-region.<br />
| None<br />
| [[11.2.0-35|11.2.0-X]]<br />
| 2012 maybe?<br />
| <br />
|-<br />
| slowhax/waithax<br />
| svcWaitSynchronizationN does not decrement the references to valid handles in an array before returning an error when it encounters an invalid handle. This allows one to (slowly) overflow the reference count for a handle object to zero.<br />
| ARM11 kernel-mode code execution<br />
| [[11.2.0-35|11.2.0-X]]<br />
| [[11.2.0-35|11.2.0-X]]<br />
| 2016<br />
| nedwill, [[User:Derrek|derrek]]<br />
|-<br />
| [[Memory_layout#ARM11_Detailed_virtual_memory_map|0xEFF00000]] / 0xDFF00000 ARM11 kernel virtual-memory<br />
| The ARM11 kernel-mode 0xEFF00000/0xDFF00000 virtual-memory(size 0x100000) is mapped to phys-mem 0x1FF00000(entire DSP-mem + entire AXIWRAM), with permissions RW-. This is used during ARM11 kernel startup for loading the FIRM-modules from the FIRM section located in DSP-mem, this never seems to be used after that, however. This is never unmapped either.<br />
| <br />
| None<br />
| [[11.2.0-35|11.2.0-X]]<br />
| <br />
| <br />
|-<br />
| memchunkhax2.1<br />
| Nintendo's fix for memchunkhax2 in [[10.4.0-29|10.4.0-X]] did not fix the GPU case: one may cause the requisite ToCToU race using gspwn, bypassing the new validation.<br />
derrek's original 32c3 presentation for memchunkhax2 commented that a GPU-based attack was possible, but would be difficult. However, memchunkhax2.1 showed that it was possible to do fairly reliably.<br />
| ARM11 kernel code execution<br />
| [[11.0.0-33|11.0.0-X]], via the new [[Memory_Management#MemoryBlockHeader|memchunkhdr]] MAC which prevents modifying memchunkhdr data with DMA.<br />
| [[11.0.0-33|11.0.0-X]]<br />
|<br />
| [[User:Derrek|derrek]], aliaspider<br />
|-<br />
| memchunkhax2<br />
| When allocating a block of memory, the "next" pointer of the [[Memory_Management#MemoryBlockHeader|memchunkhdr]] is accessed without being checked after being mapped to userland.<br />
This allows a race condition, where the process can change the next pointer just before it's accessed. By pointing the next pointer to a crafted memchunckhdr in the kernel SlabHeap, some of the SlabHeap is allocated to the calling process, allowing to change vtables of kernel objects. <br />
| ARM11 kernel code execution<br />
| [[10.4.0-29|10.4.0-X]] (partially, see memchunkhax2.1)<br />
| [[10.4.0-29|10.4.0-X]]<br />
|<br />
| [[User:Derrek|derrek]]<br />
|-<br />
| heaphax<br />
| Can change the size of free memchunk structures stored in FCRAM using DMA, which leads to the ability to allocate memory chunks over already-allocated memory. This can be used in the SYSTEM region to allocate RW memory over any part of the NS system module, which is enough to take it over.<br />
| Code execution with access to all of NS's privileges. (including downgrading) Code execution within any applet.<br />
| [[11.0.0-33|11.0.0-X]], via the new [[Memory_Management#MemoryBlockHeader|memchunkhdr]] MAC which prevents modifying memchunkhdr data with DMA.<br />
| [[11.0.0-33|11.0.0-X]]<br />
| April 2015 ?<br />
| smea<br />
|-<br />
| snshax<br />
| Can force creation of Safe NS process into gspwn-able memory, allowing for takeover.<br />
| Code execution with access to all of NS's privileges. (including downgrading)<br />
| [[10.1.0-27|10.1.0-X]]<br />
| [[10.1.0-27|10.1.0-X]]<br />
| April 2015 ?<br />
| smea<br />
|-<br />
| AffinityMask/processorid validation<br />
| With [[10.0.0-27|10.0.0-X]] the following functions were updated: svcGetThreadAffinityMask, svcGetProcessAffinityMask, svcSetProcessAffinityMask, and svcCreateThread. The code changes for all but svcCreateThread are identical.<br />
The original code with the first 3 did the following: <br />
* if(u32_processorcount > ~0x80000001)return 0xe0e01bfd;<br />
* if(s32_processorcount > <total_cores>)return 0xd8e007fd;<br />
The following code replaced the above:<br />
* if(u32_processorcount >= <total_cores+1>)return 0xd8e007fd;<br />
In theory the latter should catch everything that the former did, so it's unknown if this was really a security issue.<br />
<br />
The svcCreateThread changes with [[10.0.0-27|10.0.0-X]] definitely did fix a security issue.<br />
* Original code: "if(s32_processorid > <total_cores>)return 0xd8e007fd;"<br />
* New code: "if(s32_processorid >= <total_cores> || s32_processorid <= -4)return 0xd8e007fd;"<br />
This fixed an off-by-one issue: if one would use processorid=total_cores, which isn't actually a valid value, svcCreateThread would accept that value on <[[10.0.0-27|10.0.0-X]]. This results in data being written out-of-bounds(baseaddr = arrayaddr + entrysize*processorid), which has the following result:<br />
* Old3DS: Useless kernel-mode crash due to accessing unmapped memory.<br />
* New3DS: uncontrolled data write into a kernel-mode L1 MMU-table. This isn't really useful: the data can't be controlled, and the data which gets overwritten is all-zero anyway(this isn't anywhere near MMU L1 entries for actually mapped memory).<br />
The previous version also allowed large negative s32_processorid values(negative processorid values are special values not actual procids), but it appears using values like that won't actually do anything(meaning no crash) besides the thread not running / thread not running for a while(besides triggering a kernelpanic with certain s32_processorid value(s)).<br />
| Nothing useful<br />
| [[10.0.0-27|10.0.0-X]]<br />
| [[10.0.0-27|10.0.0-X]]<br />
| svcCreateThread issue: May 31, 2015. The rest: September 8, 2015, via v9.6->v10.0 ARM11-kernel code-diff.<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| memchunkhax<br />
| The kernel originally did not validate the data stored in the FCRAM kernel heap [[Memchunkhdr|memchunk-headers]] for free-memory at all. Exploiting this requires raw R/W access to these memchunk-headers, like physical-memory access with gspwn.<br />
<br />
There are ''multiple'' ways to exploit this, but the end-result for most of these is the same: overwrite code in AXIWRAM via the 0xEFF00000/0xDFF00000 kernel virtual-memory mapping.<br />
<br />
This was fixed in [[9.3.0-21|9.3.0-X]] by checking that the memchunk(including size, next, and prev ptrs) is located within the currently used heap memory. The kernel may also check that the next/prev ptrs are valid compared to other memchunk-headers basically. When any of these checks fail, kernelpanic() is called.<br />
| When combined with other flaws: ARM11-kernelmode code execution<br />
| [[9.3.0-21|9.3.0-21]]<br />
| <br />
| February 2014<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| Multiple [[KLinkedListNode|KLinkedListNode]] SlabHeap use after free bugs<br />
| The ARM11-kernel did access the 'key' field of [[KLinkedListNode|KLinkedListNode]] objects, which are located on the SlabHeap, after freeing them. Thus, triggering an allocation of a new [[KLinkedListNode|KLinkedListNode]] object at the right time could result in a type-confusion. Pseudo-code:<br />
SlabHeap_free(KLinkedListNode);<br />
KObject *obj = KLinkedListNode->key; // the object there might have changed!<br />
This bug appeared all over the place.<br />
| ARM11-kernelmode code exec maybe<br />
| [[8.0.0-18|8.0.0-18]]<br />
| <br />
| April 2015<br />
| [[User:Derrek|derrek]]<br />
|-<br />
| PXI [[RPC_Command_Structure|Command]] input/output buffer permissions<br />
| Originally the ARM11-kernel didn't check permissions for PXI input/output buffers for commands. Starting with [[6.0.0-11|6.0.0]] PXI input/output buffers must have RW permissions, otherwise kernelpanic is triggered.<br />
| <br />
| [[6.0.0-11|6.0.0-11]]<br />
| <br />
| 2012<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[SVC|svcStartInterProcessDma]]<br />
| For svcStartInterProcessDma, the kernel code had the following flaws:<br />
<br />
* Originally the ARM11-kernel read the input DmaConfig structure directly in kernel-mode(ldr(b/h) instructions), without checking whether the DmaConfig address is readable under userland. This was fixed by copying that structure to the SVC-mode stack, using the ldrbt instruction.<br />
<br />
* Integer overflows for srcaddr+size and dstaddr+size are now checked(with [[6.0.0-11]]), which were not checked before.<br />
<br />
* The kernel now also checks whether the srcaddr/dstaddr (+size) is within userland memory (0x20000000), the kernel now (with [[6.0.0-11]]) returns an error when the address is beyond userland memory. Using an address >=0x20000000 would result in the kernel reading from the process L1 MMU table, beyond the memory allocated for that MMU table(for vaddr->physaddr conversion). <br />
| <br />
| [[6.0.0-11]]<br />
| <br />
| DmaConfig issue: unknown. The rest: 2014<br />
| [[User:Plutooo|plutoo]], [[User:Yellows8|Yellows8]] independently<br />
|-<br />
| [[SVC|svcControlMemory]] Parameter checks<br />
| For svcControlMemory the parameter check had these two flaws:<br />
<br />
* The allowed range for addr0, addr1, size parameters depends on which MemoryOperation is being specified. The limitation for GSP heap was only checked if op=(u32)0x10003. By setting a random bit in op that has no meaning (like bit17?), op would instead be (u32)0x30003, and the range-check would be less strict and not accurate. However, the kernel doesn't actually use the input address for LINEAR memory-mapping at all besides the range-checks, so this isn't actually useful. This was fixed in the kernel by just checking for the LINEAR bit, instead of comparing the entire MemoryOperation value with 0x10003.<br />
<br />
* Integer overflows on (addr0+size) are now checked that previously weren't (this also applies to most other address checks elsewhere in the kernel).<br />
<br />
| <br />
| [[5.0.0-11]]<br />
| <br />
|<br />
| [[User:Plutooo|plutoo]]<br />
|-<br />
| [[RPC_Command_Structure|Command]] request/response buffer overflow<br />
| Originally the kernel did not check the word-values from the command-header. Starting with [[5.0.0-11]], the kernel will trigger a kernelpanic() when the total word-size of the entire command(including the cmd-header) is larger than 0x40-words (0x100-bytes). This allows overwriting threadlocalstorage+0x180 in the destination thread. However, since the data written there would be translate parameters (such as header-words + buffer addresses), exploiting this would likely be very difficult, if possible at all.<br />
<br />
If the two words at threadlocalstorage+0x180 could be overwritten with controlled data this way, one could then use a command with a buffer-header of <nowiki>((size<<14) | 2)</nowiki> to write arbitrary memory to any RW userland memory in the destination process.<br />
| <br />
| [[5.0.0-11]]<br />
| <br />
| v4.1 FIRM -> v5.0 code diff<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[SVC|SVC stack allocation overflows]]<br />
| <br />
* Syscalls that allocate a variable-length array on stack, only checked bit31 before multiplying by 4/16 (when calculating how much memory to allocate). If a large integer was passed as input to one of these syscalls, an integer overflow would occur, and too little memory would have been allocated on stack resulting in a buffer overrun. <br />
* The alignment (size+7)&~7 calculation before allocation was not checked for integer overflow.<br />
<br />
This might allow for ARM11 kernel code-execution.<br />
<br />
(Applies to svcSetResourceLimitValues, svcGetThreadList, svcGetProcessList, svcReplyAndReceive, svcWaitSynchronizationN.)<br />
| <br />
| [[5.0.0-11]]<br />
| <br />
| v4.1 FIRM -> v5.0 code diff<br />
| [[User:Plutooo|plutoo]], [[User:Yellows8|Yellows8]] complementary<br />
|-<br />
| [[SVC|svcControlMemory]] MemoryOperation MAP memory-permissions<br />
| svcControlMemory with MemoryOperation=MAP allows mapping the already-mapped process virtual-mem at addr1, to addr0. The lowest address permitted for addr1 is 0x00100000. Originally the ARM11 kernel didn't check memory permissions for addr1. Therefore .text as addr1 could be mapped elsewhere as RW- memory, which allowed ARM11 userland code-execution.<br />
| <br />
| [[4.1.0-8]]<br />
| <br />
| 2012<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[RPC_Command_Structure|Command]] input/output buffer permissions<br />
| Originally the ARM11 kernel didn't check memory permissions for the input/output buffers for commands. Starting with [[4.0.0-7]] the ARM11 kernel will trigger a kernelpanic() if the input/output buffers don't have the required memory permissions. For example, this allowed a FSUSER file-read to .text, which therefore allowed ARM11-userland code execution.<br />
| <br />
| [[4.0.0-7]]<br />
| <br />
| 2012<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[SVC|svcReadProcessMemory/svcWriteProcessMemory memory]] permissions<br />
| Originally the kernel only checked the first page(0x1000-bytes) of the src/dst buffers, for svcReadProcessMemory and svcWriteProcessMemory. There is no known retail processes which have access to these SVCs.<br />
| <br />
| [[4.0.0-7]]<br />
| <br />
| 2012?<br />
| [[User:Yellows8|Yellows8]]<br />
|}<br />
<br />
=== [[FIRM]] Sysmodules ===<br />
{| class="wikitable" border="1"<br />
|-<br />
! Summary<br />
! Description<br />
! Successful exploitation result<br />
! Fixed in [[FIRM]] system version<br />
! Last [[FIRM]] system version this flaw was checked for<br />
! Timeframe this was discovered<br />
! Discovered by<br />
|-<br />
| [[Services|"srv:pm"]] process registration<br />
| Originally any process had access to the port "srv:pm". The PID's used for the (un)registration commands are not checked either. This allowed any process to re-register itself with "srv:pm", and therefore allowed the process to give itself access to any service, bypassing the exheader service-access-control list.<br />
<br />
This was fixed in [[7.0.0-13]]: starting with [[7.0.0-13]] "srv:pm" is now a service instead of a globally accessible port. Only processes with PID's less than 6 (in other words: fs, ldr, sm, pm, pxi modules) have access to it. With [[7.0.0-13]] there can only be one session for "srv:pm" open at a time(this is used by pm module), svcBreak will be executed if more sessions are opened by the processes which can access this.<br />
<br />
This flaw was needed for exploiting the <=v4.x Process9 PXI vulnerabilities from ARM11 userland ROP, since most applications don't have access to those service(s).<br />
| Access to arbitrary services<br />
| [[7.0.0-13]]<br />
| <br />
| 2012<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| FSDIR null-deref<br />
| [[Filesystem_services|FS]]-module may crash in some cases when handling directory reading. The trigger seems to be due to using [[FSDir:Close]] without closing the dir-handle afterwards?(Perhaps this is caused by out-of-memory?) This seems to be useless since it's just a null-deref.<br />
| <br />
| None<br />
| [[9.6.0-24|9.6.0-X]]<br />
| May 19(?)-20, 2015<br />
| [[User:Yellows8|Yellows8]]<br />
|}<br />
<br />
=== Standalone Sysmodules ===<br />
{| class="wikitable" border="1"<br />
|-<br />
! Summary<br />
! Description<br />
! Successful exploitation result<br />
! Fixed in system-module system-version<br />
! Last system-module system-version this flaw was checked for<br />
! Timeframe this was discovered<br />
! Timeframe this was added to wiki<br />
! Discovered by<br />
|-<br />
| AM stack/.bss infoleak via [[AM:ReadTwlBackupInfo]]([[AM:ReadTwlBackupInfoEx|Ex]])<br />
| After writing the output-info structure to stack, it then copies that structure to the output buffer ptr using the size from the command. The size is not checked. This could be used to read data from the AM-service-thread stack handling the command + .bss.<br />
<br />
'''This was not tested on hardware.'''<br />
| Stack/.bss reading<br />
| None<br />
| [[10.0.0-27]](AM v9217)<br />
| Roughly October 17, 2016<br />
| October 25, 2016<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[MVD_Services|MVD]]: Stack buffer overflow with [[MVDSTD:SetupOutputBuffers]].<br />
| The input total_entries is not validated when initially processing the input entry-list. This fixed-size input entry-list is copied to stack from the command request. The loop for processing this initializes a global table, the converted linearmem->physaddrs used there are also copied to stack(0x8-bytes of physaddrs per entry).<br />
<br />
If total_entries is too large, MVD-sysmodule will crash due to reading unmapped memory following the stack(0x10000000). Afterwards if the out-of-bounds total_entries is smaller than that, it will crash due accessing address 0x0, hence this useless.<br />
| MVD-sysmodule crash.<br />
| None<br />
| [[9.0.0-20]]<br />
| April 22, 2016 (Tested on the 25th)<br />
| April 25, 2016<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[NWM_Services|NWM]]: Using CTRSDK heap with UDS sharedmem from the user-process.<br />
| See the HTTP-sysmodule section below.<br />
<br />
CTRSDK heap is used with the sharedmem from [[NWMUDS:InitializeWithVersion]]. Buffers are allocated/freed under this heap using [[NWMUDS:Bind]] and [[NWMUDS:Unbind]].<br />
<br />
Hence, overwriting sharedmem with gspwn then using [[NWMUDS:Unbind]] results in the usual controlled CTRSDK memchunk-header write, similar to HTTP-sysmodule.<br />
<br />
This could be done by creating an UDS network, without any other nodes on the network.<br />
<br />
Besides CTRSDK memchunk-headers, there are no addresses stored under this sharedmem.<br />
| ROP under NWM-module.<br />
| None<br />
| [[9.0.0-20|9.0.0-X]]<br />
| April 10, 2016<br />
| April 16, 2016<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[DLP_Services|DLP]]: Out-of-bounds memory access during spectator [[Download_Play|data-frame]] checksum calculation<br />
| DLP doesn't validate the frame_size when receiving spectator data-frames at all, unlike non-spectator data-frames. The actual spectator data-frame parsing code doesn't use that field either. However, the data-frame checksum calculation code called during checksum verification does use the frame_size for loading the size of the framebuf.<br />
<br />
Hence, using a large frame_size like 0xFFFF will result in the checksum calculation code reading data out-of-bounds. This isn't really useful, you could trigger a remote local-WLAN DLP-sysmodule crash while a 3DS system is scanning for DLP networks(due to accessing unmapped memory), but that's about all(trying to infoleak with this likely isn't useful either).<br />
| DLP-sysmodule crash, handled by dlplay system-application by a "connection interrupted" error eventually then a fatal-error via ErrDisp.<br />
| None<br />
| [[10.0.0-27|10.0.0-X]]<br />
| April 8, 2016 (Tested on the 10th)<br />
| April 10, 2016<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[DLP_Services|DLP]]: Out-of-bounds output data writing during spectator sysupdate titlelist [[Download_Play|data-frame]] handling<br />
| The total_entries and out_entryindex fields for the titlelist DLP spectator data-frames are not validated. This is parsed during DLP network scanning. Hence, the specified titlelist data can be written out-of-bounds using the specified out_entryindex and total_entries. A crash will occur while reading the input data-frame titlelist if total_entries is larger than 0x27A, due to accessing unmapped memory.<br />
<br />
There's not much non-zero data to overwrite following the output buffer(located in sharedmem), any ptrs are located in sharedmem. Overwriting certain ptr(s) are only known to cause a crash when attempting to use the DLP-client shutdown service-command.<br />
<br />
There's no known way to exploit the above crash, since the linked-list code involves writes zeros(with a controlled start ptr).<br />
| <br />
| None<br />
| [[10.0.0-27|10.0.0-X]]<br />
| April 8-9, 2016<br />
| April 10, 2016<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[IR_Services|IR]]: Stack buffer overflow with custom hardware<br />
| Originally IR sysmodule used the read value from the I2C-IR registers TXLVL and RXLVL without validating them at all. See [[10.6.0-31|here]] for the fix. This is the size used for reading the data-recv FIFO, etc. The output buffer for reading is located on the stack.<br />
<br />
This should be exploitable if one could successfully setup the custom hardware for this and if the entire intended sizes actually get read from I2C.<br />
| ROP under IR sysmodule.<br />
| [[10.6.0-31|10.6.0-31]]<br />
| <br />
| February 23, 2016 (Unknown if it was noticed before then)<br />
| February 23, 2016<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[HTTP_Services|HTTP]]: Using CTRSDK heap with sharedmem from the user-process.<br />
| The data from httpcAddPostDataAscii and other commands is stored under a CTRSDK heap. That heap is the sharedmem specified by the user-process via the HTTPC Initialize command.<br />
Normally this sharedmem isn't accessible to the user-process once the sysmodule maps it, hence using it is supposed to be "safe".<br />
<br />
This isn't the case due to gspwn however. Since CTRSDK heap code is so insecure in general, one can use gspwn to locate the HTTPC sharedmem + read/write it, then trigger a mem-write under the sysmodule. This can then be used to get ROP going under HTTP-sysmodule.<br />
<br />
This is exploited by [https://github.com/yellows8/ctr-httpwn/ctr-httpwn ctr-httpwn].<br />
| ROP under HTTP sysmdule.<br />
| None<br />
| [[9.6.0-24|9.6.0-X]] (Latest sysmodule version as of [[10.7.0-32|10.7.0-32]])<br />
| Late 2015<br />
| March 22, 2016<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[NIM_Services|NIM]]: Downloading old title-versions from eShop<br />
| Multiple NIM service commands(such as [[NIMS:StartDownload]]) use a title-version value specified by the user-process, NIM does not validate that this input version matches the latest version available via SOAP. Therefore, when combined with AM(PXI) [[#Process9|title-downgrading]] via deleting the target eShop title with System Settings Data Management(if the title was already installed), this allows downloading+installing any title-version from eShop ''if'' it's still available from CDN.<br />
The easiest way to exploit this is to just patch the eShop system-application code using these NIM commands(ideally the code which loads the title-version).<br />
<br />
Originally this was tested with a debugging-system via modded-FIRM, eventually smea implemented it in HANS for the 32c3 release.<br />
| Downloading old title-versions from eShop<br />
| None<br />
| [[10.0.0-27|10.0.0-X]]<br />
| October 24, 2015 (Unknown when exactly the first eShop title downgrade was actually tested, maybe November)<br />
| January 7, 2016 (Same day Ironfall v1.0 was removed from CDN via the main-CXI files)<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[SPI_Services|SPI]] service out-of-bounds write<br />
| cmd1 has out-of-bounds write allowing overwrite of some static variables in .data.<br />
| <br />
| None<br />
| [[9.5.0-22]]<br />
| March 2015<br />
| <br />
| [[User:Plutooo|plutoo]]<br />
|-<br />
| [[NFC_Services|NFC]] module service command buf-overflows<br />
| NFC module copies data with certain commands, from command input buffers to stack without checking the size. These commands include the following, it's unknown if there's more commands with similar issues: "nfc:dev" <0x000C....> and "nfc:s" <0x0037....>.<br />
Since both of these commands are stubbed in the Old3DS NFC module from the very first version(those just return an error), these issues only affect the New3DS NFC module.<br />
<br />
There's no known retail titles which have access to either of these services.<br />
| ROP under NFC module.<br />
| New3DS: None<br />
| New3DS: [[9.5.0-22]]<br />
| December 2014?<br />
| <br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[News_Services|NEWSS]] service command notificationID validation failure<br />
| This module does not validate the input notificationID for <nowiki>"news:s"</nowiki> service commands. This is an out-of-bounds array index bug. For example, [[NEWSS:SetNotificationHeader]] could be used to exploit news module: this copies the input data(size is properly checked) to: out = newsdb_savedata+0x10 + (someu32array[notificationID]*0x70).<br />
| ROP under news module.<br />
| None<br />
| [[9.7.0-25|9.7.0-X]]<br />
| December 2014<br />
| <br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[NWMUDS:DecryptBeaconData]] heap buffer overflow<br />
| input_size = 0x1E * <value the u8 from input_[[NWM_Services|networkstruct]]+0x1D>. Then input_tag0 is copied to a heap buffer. When input_size is larger than 0xFA-bytes, it will then copy input_tag1 to <end_address_of_previous_outbuf>, with size=input_size-0xFA.<br />
<br />
This can be triggered by either using this command directly, or by boadcasting a wifi beacon which triggers it while a 3DS system running the target process is in range, when the process is scanning for hosts to connect to. Processes will only pass tag data to this command when the wlancommID and other thing(s) match the values for the process.<br />
<br />
There's no known way to actually exploit this for getting ROP under NWM-module, at the time of originally adding this to the wiki. This is because the data which gets copied out-of-bounds *and* actually causes crash(es), can't be controlled it seems(with just broadcasting a beacon at least). It's unknown whether this could be exploited from just using NWMUDS service-cmd(s) directly.<br />
| Without any actual way to exploit this: NWM-module DoS, resulting in process termination(process crash). This breaks *everything* involving wifi comms, a reboot is required to recover from this.<br />
| None<br />
| [[9.0.0-20]]<br />
| ~September 23, 2014(see the [[NWMUDS:DecryptBeaconData]] page history)<br />
| August 3, 2015<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[HID_Services|HID]] module shared-mem<br />
| HID module does not validate the index values in [[HID_Shared_Memory|sharedmem]](just changes index to 0 when index == maxval when updating), therefore large values will result in HID module writing HID data to arbitrary addresses.<br />
| ROP under HID module, but this is *very* unlikely to be exploitable since the data written is HID data.<br />
| None<br />
| [[9.3.0-21]]<br />
| 2014?<br />
| <br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| gspwn<br />
| GSP module does not validate addresses given to the GPU. This allows a user-mode application/applet to read/write to a large part of physical FCRAM using GPU DMA. From this, you can overwrite the .text segment of the application you're running under, and gain real code-execution from a ROP-chain. Normally applets' .text([[Home Menu]], [[Internet Browser]], etc) is located beyond the area accessible by the GPU, except for [[RO_Services|CROs]] used by applets([[Internet Browser]] for example).<br />
<br />
FCRAM is gpu-accessible up to physaddr 0x26800000 on Old3DS, and 0x2DC00000 on New3DS. This is BASE_memregion_start(aka SYSTEM_memregion_end)-0x400000 with the default memory-layout on Old3DS/New3DS.<br />
| User-mode code execution.<br />
| None<br />
| [[9.6.0-24|9.6.0-X]]<br />
| Early 2014<br />
| <br />
| smea, [[User:Yellows8|Yellows8]]/others before then<br />
|-<br />
| rohax<br />
| Using gspwn, it is possible to overwrite a loaded [[CRO0]]/[[CRR0]] after its RSA-signature has been validated. Badly validated [[CRO0]] header leads to arbitrary read/write of memory in the ro-process. This gives code-execution in the ro module, who has access to [[SVC|syscalls]] 0x70-0x72, 0x7D.<br />
<br />
This was fixed after [[ninjhax]] release by adding checks on [[CRO0]]-based pointers before writing to them.<br />
| Memory-mapping syscalls.<br />
| [[9.3.0-21]]<br />
| [[9.4.0-21]]<br />
| <br />
| <br />
| smea, [[User:Plutooo|plutoo]] joint effort<br />
|-<br />
| Region free<br />
| Only [[Home Menu]] itself checks gamecards' region when launching them. Therefore, any application launch that is done directly with [[NS]] without signaling Home Menu to launch the app, will result in region checks being bypassed.<br />
This essentially means launching the gamecard with the [[NS_and_APT_Services|"ns:s"]] service. The main way to exploit this is to trigger a FIRM launch with an application specified, either with a normal FIRM launch or a hardware [[NSS:RebootSystem|reboot]].<br />
| Launching gamecards from any region + bypassing Home Menu gamecard-sysupdate installation<br />
| None<br />
| Last tested with [[10.1.0-27|10.1.0-X]].<br />
| June(?) 2014<br />
| <br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[NWM_Services|NWM]] service-cmd state null-ptr deref<br />
| The NWMUDS service command code loads a ptr from .data, adds an offset to that, then passes that as the state address for the actual command-handler function. The value of the ptr loaded from .data is not checked, therefore this will cause crashes due to that being 0x0 when NWMUDS was not properly initialized.<br />
It's unknown whether any NWM services besides NWMUDS have this issue.<br />
| This is rather useless since it's only a crash caused by a state ptr based at 0x0.<br />
| None<br />
| [[9.0.0-20]]<br />
| 2013?<br />
| <br />
| [[User:Yellows8|Yellows8]]<br />
|}<br />
<br />
=== General/CTRSDK ===<br />
{| class="wikitable" border="1"<br />
|-<br />
! Summary<br />
! Description<br />
! Successful exploitation result<br />
! Fixed in version<br />
! Last version this flaw was checked for<br />
! Timeframe this was discovered<br />
! Discovered by<br />
|-<br />
| [[NWM_Services|UDS]] beacon additional-data buffer overflow<br />
| Originally CTRSDK did not validate the UDS additional-data size before using that size to copy the additional-data to a [[NWM_Services|networkstruct]]. This was eventually fixed.<br />
This was discovered while doing code RE with an old dlp-module version. It's unknown in what specific CTRSDK version this was fixed, or even what system-version updated titles with a fixed version.<br />
<br />
It's unknown if there's any titles using a vulnerable CTRSDK version which are also exploitable with this(dlp module can't be exploited with this).<br />
<br />
The maximum number of bytes that can be written beyond the end of the outbuf is 0x37-bytes, with additionaldata_size=0xFF.<br />
| Perhaps ROP, very difficult if possible with anything at all<br />
| ?<br />
| <br />
| September(?) 2014<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| CTPK buffer overflow<br />
| At offset 0x20 in CTPK is an array for each texture, each entry is 0x20-bytes. This contains a wordindex(entry+0x18) for some srcdata relative to CTPK+0, and an u8 wordsize(entry+0x14) for this data. The CTRSDK function handling this doesn't validate the size, when copying srcdata using this size to the output buffer. Applications usually have the output buffer on the stack, hence stack buffer overflow.<br />
<br />
While CTPK(*.ctpk) are normally only loaded from RomFS, some application(s) load from elsewhere too.<br />
| ROP under the target application.<br />
| None?<br />
| "[SDK+NINTENDO:CTR_SDK-11_4_0_200_none]"<br />
| November 14, 2016<br />
| [[User:Yellows8|Yellows8]]<br />
|}</div>Mrrraouhttps://www.3dbrew.org/w/index.php?title=Services_API&diff=19108Services API2016-12-31T14:36:16Z<p>Mrrraou: </p>
<hr />
<div>Nintendo provides application developers with an API, which communicate with certain services. Services, in this sense, are [[Title_list#00040130_-_System_Modules|system processes running in the background]] which wait for incoming requests. When a process wants to communicate with a service, it first needs to get a handle to the named service, and then it can communicate with the service via interprocess communication. Each service has a name up to 8 characters, for example "nim:u".<br />
<br />
Handles for services are retrieved from the [[Services|service manager port]], "srv:". Services are an abstraction of ports, they operate the same way except regular ports can have their handles retrieved directly from a SVC.<br />
<br />
For a description of how commands and arguments are passed to services, see [[IPC Command Structure]].<br />
<br />
List of services (grouped by the process which provides them):<br />
{| class="wikitable" border="1"<br />
|-<br />
! Old3ds<br />
! Services<br />
! Service names<br />
! scope="col" width="200" | Notes<br />
|-<br />
| style="background: green" | Yes<br />
| [[Filesystem services]]<br />
| fs:USER, fs:LDR, fs:REG<br />
| USER: normal applications and system modules, LDR: loader, REG: register<br />
|-<br />
| style="background: green" | Yes<br />
| [[Process Services]]<br />
| ps:ps<br />
|<br />
|-<br />
| style="background: green" | Yes<br />
| [[PXI Services]]<br />
| PxiFS0, PxiFS1, PxiFSB, PxiFSR, PxiPM, pxi:am9, pxi:dev, pxi:mc, pxi:ps9<br />
|<br />
|-<br />
| style="background: green" | Yes<br />
| [[Application Manager Services]]<br />
| am:app, am:net, am:u, am:sys, am:pipe<br />
| app: am for applications, net: network installation ([[NIM_Services|nim]]), u: local installation, sys: am for system titles, pipe: not an actual port (internally used to represent the [[Application_Manager_Services#File_service|FSFile-like interface]])<br />
|-<br />
| style="background: green" | Yes<br />
| [[Process Manager Services]]<br />
| pm:app, pm:dbg<br />
| app: launching titles, dbg: launching titles with debugging enabled<br />
|-<br />
| style="background: green" | Yes<br />
| [[NIM Services]]<br />
| nim:aoc, nim:ndm, nim:s, nim:u<br />
| aoc: DLC, ndm: for [[NDM Services|ndm]], s: for eShop, u: for updater<br />
|-<br />
| style="background: green" | Yes<br />
| [[Config Services]]<br />
| cfg:u, cfg:s, cfg:i, cfg:nor<br />
| u: for user, s: for system, i: for initialization/formatting, nor: accesses wifi SPI flash<br />
|-<br />
| style="background: green" | Yes<br />
| [[NS|NS and APT Services]]<br />
| ns:s, ns:p, ns:c, APT:A, APT:S, APT:U<br />
| ns:s: for system, ns:p: power (shutdown/reboot), ns:c: ?, APT:A: application, APT:S: system, APT:U: user<br />
|-<br />
| style="background: green" | Yes<br />
| [[RO Services]]<br />
| ldr:ro<br />
|<br />
|-<br />
| style="background: green" | Yes<br />
| [[NDM Services]]<br />
| ndm:u<br />
|<br />
|-<br />
| style="background: green" | Yes<br />
| [[CSND Services]]<br />
| csnd:SND<br />
|<br />
|-<br />
| style="background: green" | Yes<br />
| [[Camera Services]]<br />
| cam:u, y2r:u, cam:s, cam:c, cam:q (New3DS only)<br />
| <br />
|-<br />
| style="background: green" | Yes<br />
| [[Codec Services]]<br />
| cdc:HID, cdc:MIC, cdc:CSN, cdc:DSP, cdc:LGY, cdc:CHK<br />
| HID: human interface device, MIC: microphone, CSN: for [[CSND_Services|csnd]]?, DSP: for [[DSP_Services|dsp]]?, LGY: legacy (some kind of backwards compat?), CHK: ?<br />
|-<br />
| style="background: green" | Yes<br />
| [[DLP Services]]<br />
| dlp:CLNT, dlp:FKCL, dlp:SRVR<br />
| CLNT: client, FKCL: fake client, SRVR: server<br />
|-<br />
| style="background: green" | Yes<br />
| [[DSP Services]]<br />
| dsp::DSP<br />
|<br />
|-<br />
| style="background: green" | Yes<br />
| [[GSP Services]]<br />
| gsp::Lcd, gsp::Gpu<br />
| Lcd: LCD control, Gpu: GPU control<br />
|-<br />
| style="background: green" | Yes<br />
| [[BOSS Services]]<br />
| boss:U, boss:P, boss:M<br />
| U: user, P: privileged, M: for [[NDM Services|ndm]]<br />
|-<br />
| style="background: green" | Yes<br />
| [[CECD Services]]<br />
| cecd:u, cecd:s, cecd:ndm<br />
| u: user, s: system, ndm: for [[NDM Services|ndm]]<br />
|-<br />
| style="background: green" | Yes<br />
| [[IR Services]]<br />
| ir:u, ir:USER, ir:rst<br />
|<br />
|-<br />
| style="background: green" | Yes<br />
| [[I2C Services]]<br />
| i2c::MCU, i2c::CAM, i2c::LCD, i2c::DEB, i2c::HID, i2c::IR, i2c::EEP, i2c::NFC, i2c::QTM<br />
| <br />
|-<br />
| style="background: green" | Yes<br />
| [[GPIO Services]]<br />
| gpio:CDC, gpio:MCU, gpio:HID, gpio:NWM, gpio:IR, gpio:NFC, gpio:QTM<br />
| <br />
|-<br />
| style="background: green" | Yes<br />
| [[HID Services]]<br />
| hid:NFC, hid:QTM, hid:SPVR, hid:USER <br />
| NFC: near-field communication (amiibo), QTM: head tracking device (related to [[QTM_Services|QTM Services]])?, SPVR: system privileged?<br />
|-<br />
| style="background: green" | Yes<br />
| [[PTM Services]]<br />
| ptm:gets, ptm:play, ptm:s, ptm:sets, ptm:sysm, ptm:u<br />
| gets: get system time, play: play history, s: system, sets: set system time, sysm: system menu (homemenu/testmenu), u: user<br />
|-<br />
| style="background: green" | Yes<br />
| [[NWM Services]]<br />
| nwm::CEC, nwm::EXT, nwm::INF, nwm::SAP, nwm::SOC, nwm::TST, nwm::UDS<br />
| CEC: streetpass, EXT: ?, INF: infrastructure, SAP: ?, SOC: socket, UDS: local WLAN, TST: ?<br />
|-<br />
| style="background: green" | Yes<br />
| [[HTTP Services]]<br />
| http:C<br />
| C: connection<br />
|-<br />
| style="background: green" | Yes<br />
| [[SSL Services]]<br />
| ssl:C<br />
| C: connection<br />
|-<br />
| style="background: green" | Yes<br />
| [[Socket Services]]<br />
| soc:P, soc:U<br />
| P: privileged, U: user<br />
|-<br />
| style="background: green" | Yes<br />
| [[AC Services]]<br />
| ac:i, ac:u<br />
| i: internal, u: user<br />
|-<br />
| style="background: green" | Yes<br />
| [[Friend Services]]<br />
| frd:a, frd:n, frd:u<br />
| a: admin, n: for [[NDM Services|ndm]], u: user<br />
|-<br />
| style="background: green" | Yes<br />
| [[News Services]]<br />
| news:s, news:u<br />
| s: system, u:user<br />
|-<br />
| style="background: green" | Yes<br />
| [[PDN Services]]<br />
| pdn:s, pdn:d, pdn:i, pdn:g, pdn:c<br />
| <br />
|-<br />
| style="background: green" | Yes<br />
| [[SPI Services]]<br />
| SPI::NOR, SPI::CD2, SPI::CS2, SPI::CS3, SPI::DEF<br />
|<br />
|-<br />
| style="background: green" | Yes<br />
| [[Loader Services]]<br />
| Loader<br />
|<br />
|-<br />
| style="background: green" | Yes<br />
| [[MCU Services]]<br />
| mcu::CAM, mcu::GPU, mcu::HID, mcu::RTC, mcu::SND, mcu::NWM, mcu::HWC, mcu::PLS, mcu::CDC<br />
|<br />
|-<br />
| style="background: green" | Yes<br />
| [[MIC Services]]<br />
| mic:u<br />
|<br />
|-<br />
| style="background: green" | Yes<br />
| [[ACT Services]]<br />
| act:a, act:u<br />
| a: admin, u: user<br />
|-<br />
| style="background: green" | Yes<br />
| [[NFC Services]]<br />
| nfc:dev, nfc:m, nfc:p, nfc:r, nfc:s, nfc:u<br />
| dev: developer, m: ? p: passthrough?, r: raw?, s: system, u: user<br />
|-<br />
| style="background: red" | No<br />
| [[MVD Services]]<br />
| <br />
|<br />
|-<br />
| style="background: red" | No<br />
| [[QTM Services]]<br />
| <br />
|<br />
|}<br />
<br />
List of PXI services:<br />
* [[Filesystem services PXI]]<br />
* [[Process Services PXI]]<br />
* [[Application Manager Services PXI]]<br />
* [[Process Manager Services PXI]]<br />
* [[Development Services PXI]]<br />
* [[Gamecard Services PXI]]<br />
* [[Legacy FIRM PXI]] (TWL_FIRM/AGB_FIRM)<br />
<br />
List of ports:<br />
* [[ErrDisp]]<br />
* [[Services]]<br />
<br />
<br />
See [[Error codes]].</div>Mrrraouhttps://www.3dbrew.org/w/index.php?title=Homebrew_Exploits&diff=19071Homebrew Exploits2016-12-29T12:05:12Z<p>Mrrraou: fix markup typo</p>
<hr />
<div>==Payload==<br />
{| class="wikitable" border="1"<br />
|-<br />
! Works on latest fw<br />
! Name<br />
! Description<br />
! Supported firmwares<br />
|-<br />
| style="background: lightgreen" | Yes<br />
| [https://smealum.github.io/3ds/ *hax payload]<br />
| Booted by all of the below non-sysmodule exploits.<br />
| From '''9.0.0-7''' up to and including '''11.2.0-35'''.<br />
|}<br />
<br />
For the rest of this page, "Supported firmwares" refers to the exploit ''itself'', not whether *hax payload supports it.<br />
<br />
==Standalone Homebrew Launcher Exploits==<br />
The following homebrew exploits can be executed on a previously un-exploited system. ''Please'' see the above Payload section regarding what "Supported firmwares" indicates ''exactly''.<br />
<br />
{| class="wikitable" border="1"<br />
|-<br />
! Works on latest fw<br />
! Name<br />
! Supported firmwares<br />
! Requirements<br />
! Author<br />
! Install<br />
|-<br />
| style="background: salmon" | No<br />
| [[ninjhax|Ninjhax 1.1b]]<br />
| From '''4.0.0-7''' up to and including '''9.2.0-20'''.<br />
| A cartridge or eShop version (JPN-only) of "Cubic Ninja".<br />
| smea<br />
| [http://smealum.net/ninjhax/ Install]<br />
|-<br />
| style="background: lightgreen" | Yes<br />
| [[ninjhax|Ninjhax 2.x]]<br />
| From '''9.0.0-7''' up to and including '''11.2.0-35'''.<br />
| A cartridge or eShop version (JPN-only, not available anymore for purchase) of "Cubic Ninja".<br />
| smea<br />
| [https://smealum.github.io/ninjhax2/ Install]<br />
|-<br />
| style="background: lightgreen" | Yes<br />
| [http://plutooo.github.io/freakyhax/ freakyhax]<br />
| From '''9.0.0-7''' up to and including '''11.2.0-35'''.<br />
| A cartridge or eShop version (USA/EUR/JAP, not available anymore for purchase) of "Freakyform Deluxe".<br />
| plutoo<br />
| [http://plutooo.github.io/freakyhax/ Install]<br />
|-<br />
| style="background: salmon" | No<br />
| [http://plutooo.github.io/smilehax/ smilehax]<br />
| From '''9.0.0-7''' up to and including '''11.0.0-33'''<br />
| SmileBASIC (JPN all versions up to 3.32 excluded, USA 3.31 only)<br />
| plutoo<br />
| [http://plutooo.github.io/smilehax/ Install]<br />
|-<br />
| style="background: salmon" | No<br />
| [http://mrnbayoh.github.io/basicsploit/ BASICSploit]<br />
| From '''9.0.0-7''' up to and including '''11.0.0-33'''<br />
| SmileBASIC (USA all versions)<br />
| MrNbaYoh<br />
| [http://mrnbayoh.github.io/basicsploit/ Install]<br />
|-<br />
| style="background: lightgreen" | Yes<br />
| [[smashbroshax|smashbroshax]] (beaconhax)<br />
| (New 3DS only) From '''9.0.0-X''' up to and including '''11.2.0-35'''.<br />
| Super Smash Bros 3DS (full-game) and a way to broadcast raw wifi beacons. The demo (prior to the updated November 2015 [https://github.com/yellows8/3ds_smashbroshax version]) isn't usable with the *hax payloads. Game-version v1.1.3 fixed the vuln used with this, see the repo for a workaround for that.<br />
| [[User:Yellows8|Yellows8]]<br />
| [https://github.com/yellows8/3ds_smashbroshax Install]<br />
|-<br />
| style="background: salmon" | No<br />
| [[browserhax]]<br />
| From '''9.0.0-2''' to '''11.0.0-33'''<br />
Note that the browser-version-check bypass is only usable prior to [[10.7.0-32]].<br />
| A USA, EUR, JPN, or KOR system.<br />
| [[User:Yellows8|Yellows8]]<br />
| [http://yls8.mtheall.com/3dsbrowserhax.php Install]<br />
|-<br />
| style="background: lightgreen" | Yes<br />
| [https://github.com/svanheulen/genhax genhax]<br />
| (New 3DS only) From '''9.9.0-X''' up to and including '''11.2.0-X'''.<br />
| A gamecard or eShop-install of Monster Hunter X (JPN only), and the DLC encryption key (see installer instructions).<br />
| svanheulen<br />
| [https://github.com/svanheulen/genhax_installer Install]<br />
|-<br />
| style="background: lightgreen" | Yes<br />
| [https://github.com/nedwill/soundhax soundhax]<br />
| From '''9.0.0-X''' to '''11.2.0-X''' for EUR and USA, '''10.6.0-X''' to '''11.2.0-X''' for JPN<br />
| A USA, EUR or JPN system.<br />
| nedwill<br />
| [https://github.com/nedwill/soundhax/ Install]<br />
|}<br />
<br />
Note that ninjhax 1.x is still not obsolete. Even though ninjhax 2.x can be run on 9.3+, this was made possible (amongst other things) by sacrificing the memory remapping exploit used in ninjhax 1.x (rohax). Therefore, things like JIT engines for emulators can only be supported on ninjhax 1.x. Furthermore, ninjhax 2.x does not run on system versions below 9.0.0-X, while ninjhax 1.x does.<br />
<br />
==Secondary Exploits==<br />
Installation of these exploits requires a previously exploited system to install. After installation, they can be used on their own. ''Please'' see the above Payload section regarding what "Supported firmwares" indicates ''exactly''.<br />
<br />
{| class="wikitable" border="1"<br />
! Works on latest fw<br />
! Name<br />
! Supported firmwares<br />
! Requirements<br />
! Author<br />
! Install<br />
|-<br />
| style="background: salmon" | No<br />
| [[ironhax]]<br />
| From '''9.5.0-X''' up to and including '''10.3.0-X''', for '''X''' up to and including 28.<br />
| A copy of "Ironfall: Invasion" downloaded from eShop before August 11th, 2015. Note the updated version that was released on October 13th, 2015 is not supported.<br />
| smea<br />
| [http://smealum.github.io/3ds/ Install]<br />
|-<br />
| style="background: lightgreen" | Yes<br />
| [http://vegaroxas.github.io/ steelhax]<br />
| From '''9.0.0-X''' up to and including '''11.2.0-X''', for '''X''' up to and including 35.<br />
| A copy of Steel Diver: Sub Wars<br />
| Vegaroxas<br />
| [https://github.com/VegaRoXas/vegaroxas.github.io/raw/master/files/steelhax-installer.zip Install]<br />
|-<br />
| style="background: lightgreen" | Yes<br />
| [https://github.com/yellows8/oot3dhax oot3dhax]<br />
| From '''9.0.0-X''' up to and including '''11.2.0-X''', for '''X''' up to and including 35.<br />
| A gamecard or eShop-install of Legend of Zelda: Ocarina of Time 3D. Besides using the installer app, writing raw saveimages with a save dongle for example is another option. Before compression was introduced in the 2016-7-18 release, the size of the *hax payload meant the exploit can't coexist with regular saves on a physical version of the game.<br />
| Yellows8 / smea et al.<br />
| See [https://smealum.github.io/3ds/ here].<br />
|-<br />
| style="background: salmon" | No<br />
| [[menuhax]]<br />
| JPN/USA/EUR: From '''9.0.0-X''' up to and including '''11.0.0-X'''.<br />
KOR: From '''9.6.0-X''' up to and including '''11.0.0-X'''.<br />
| JPN/USA/EUR: Having created [[Home_Menu#Home_Menu_Theme_SD_ExtData|theme extdata]] through opening the official theme selector at least once.<br />
| [[User:Yellows8|Yellows8]]<br />
| [https://github.com/yellows8/3ds_homemenuhax/releases Download]<br />
|-<br />
| style="background: lightgreen" | Yes<br />
| [https://github.com/shinyquagsire23/supermysterychunkhax supermysterychunkhax]<br />
| From '''9.9.0-X''' (USA/JPN) / '''10.2.0-X''' (EUR) up to and including '''11.1.0-X''', for '''X''' up to and including 34.<br />
| A gamecard or eShop-install of Pokémon Super Mystery Dungeon.<br />
| Shiny Quagsire / SALT team<br />
| [https://smd.salthax.org/ Install].<br />
|-<br />
| style="background: salmon" | No<br />
| [https://github.com/shinyquagsire23/v_hax (v*)hax]<br />
| From '''9.0.0-X''' up to and including '''11.0.0-X''', for '''X''' up to and including 33.<br />
Note that '''9.0.0-X''' is only required for the Homebrew Launcher - the game itself only requires '''2.1.0-X''' for primitive userland code execution.<br />
| A copy of VVVVVV downloaded after March 2012 (v1). v1.1 patches out the overflow vulnerability used by (v*)hax.<br />
| Shiny Quagsire / SALT team<br />
| [https://vvvvvv.salthax.org/ Install].<br />
|-<br />
| style="background: lightgreen" | Yes<br />
| [https://github.com/Dazzozo/humblehax humblehax]<br />
| From '''9.0.0-X''' (USA/EUR) up to and including '''11.2.0-X''', for '''X''' up to and including 35.<br />
| An eShop-install of Citizens of Earth (either v1 or v2), featured in the Humble "Friends of Nintendo" Bundle.<br />
| Dazzozo / SALT team<br />
| [https://citizens.salthax.org/ Install].<br />
|-<br />
| style="background: salmon" | No<br />
| [http://mrnbayoh.github.io/basehaxx/ basehaxx]<br />
| From '''9.0.0-X''' up to and including '''11.1.0-X''', for '''X''' up to and including 34.<br />
| A gamecard or eShop-install of Pokémon Omega Ruby / Alpha Sapphire.<br />
| MrNbaYoh<br />
| [http://mrnbayoh.github.io/basehaxx/ install]<br />
|-<br />
| style="background: lightgreen" | Yes<br />
| [https://github.com/yellows8/stickerhax stickerhax]<br />
| From '''9.0.0-X''' up to and including '''11.2.0-X'''.<br />
| A gamecard or eShop-install of Paper Mario: Sticker Star.<br />
| [[User:Yellows8|Yellows8]]<br />
| [https://github.com/yellows8/stickerhax Here]<br />
|-<br />
| style="background: lightgreen" | Yes<br />
| [https://github.com/svanheulen/genhax genhax]<br />
| (New 3DS only) From '''9.9.0-X'''(JPN) or '''10.3.0-X'''(EUR/USA) up to and including '''11.2.0-X'''.<br />
| A gamecard or eShop-install of Monster Hunter Generations, and an internet connection during installation.<br />
| svanheulen<br />
| [https://github.com/svanheulen/genhax_installer Install]<br />
|-<br />
| style="background: lightgreen" | Yes<br />
| [https://github.com/MrNbaYoh/painthax painthax]<br />
| From '''9.0.0-X''' up to and including '''11.2.0-X'''.<br />
| An eShop-install of PixelPaint.<br />
| MrNbaYoh<br />
| [https://github.com/MrNbaYoh/painthax/releases/latest install]<br />
|}<br />
<br />
==Exploits without Homebrew Launcher (Not recommended)==<br />
<br />
<u>'''Warning:'''</u> The following exploits can run code, but are missing a 3DSX launcher. They cannot launch any homebrew in the 3DSX format.<br />
<br />
{| class="wikitable" border="1"<br />
|-<br />
! Works on latest fw<br />
! Name<br />
! Supported firmwares<br />
! Requirements<br />
! Author<br />
! Install<br />
|-<br />
| style="background: salmon" | No<br />
| [[browserhax]] (Without the loader in the 3ds_browserhax_common repo)<br />
| (Old3DS) From '''5.0.0-2''' to '''11.0.0-33''' (Pre-v5.0 is supported for some versions if you manually modify the source)<br />
<br />
(New3DS) From '''9.0.0-20''' to '''11.0.0-33'''<br />
<br />
Note that the browser-version-check bypass is only usable prior to [[10.7.0-32]].<br />
| An USA, EUR, or JPN system.<br />
| [[User:Yellows8|Yellows8]]<br />
| [[browserhax|Install]]<br />
|-<br />
| style="background: salmon" | No<br />
| Ninjhax (with specialized payloads)<br />
| Up to '''9.2.0-20'''?<br />
| <br />
| smea + independent developers<br />
| N/A<br />
|}<br />
<br />
==Previous Exploits==<br />
<u>'''Warning:'''</u> These exploits '''do not work'''. They are exploits which no longer function at all, regardless of software or firmware revision.<br />
{| class="wikitable" border="1"<br />
! Works on latest fw<br />
! Name<br />
! Supported firmwares<br />
! Requirements<br />
! Author<br />
! Install<br />
|-<br />
| style="background: salmon" | No<br />
| [[tubehax|Tubehax]]<br />
| None. '''Was''': From '''9.0.0-X''' up to and including '''10.1.0-X''', for '''X''' up to and including 27.<br />
| The YouTube application and an Internet connection. As of October 15, 2015, this is no longer usable due to an update being released which fixes the vuln used by tubehax + app update being forced (see [[YouTube|here]]).<br />
| smea<br />
| [http://smealum.github.io/3ds/ Install]<br />
|}<br />
<br />
==Other Homebrew Loaders==<br />
The [https://github.com/yellows8/hblauncher_loader hblauncher_loader] title can be used when running under modded-FIRM which allows running unsigned titles, to boot the *hax payloads.<br />
<br />
==Sysmodule Exploits==<br />
This section is for system-module exploits, which can be run from the *hax payloads.<br />
<br />
{| class="wikitable" border="1"<br />
! Works on latest fw<br />
! Name<br />
! Supported firmwares<br />
! Requirements<br />
! Author<br />
|-<br />
| style="background: lightgreen" | Yes, that's not the intended default use however.<br />
| [https://github.com/yellows8/ctr-httpwn/releases ctr-httpwn]<br />
| From '''9.6.0-X''' up to and including '''11.2.0-X'''.<br />
| None<br />
| [[User:Yellows8|Yellows8]]<br />
|}<br />
<br />
==WebKit vuln testing==<br />
See [https://github.com/yellows8/3ds_browserhax_common/issues/28 here].</div>Mrrraouhttps://www.3dbrew.org/w/index.php?title=Homebrew_Exploits&diff=19070Homebrew Exploits2016-12-29T12:03:50Z<p>Mrrraou: /* Standalone Homebrew Launcher Exploits */</p>
<hr />
<div>==Payload==<br />
{| class="wikitable" border="1"<br />
|-<br />
! Works on latest fw<br />
! Name<br />
! Description<br />
! Supported firmwares<br />
|-<br />
| style="background: lightgreen" | Yes<br />
| [https://smealum.github.io/3ds/ *hax payload]<br />
| Booted by all of the below non-sysmodule exploits.<br />
| From '''9.0.0-7''' up to and including '''11.2.0-35'''.<br />
|}<br />
<br />
For the rest of this page, "Supported firmwares" refers to the exploit ''itself'', not whether *hax payload supports it.<br />
<br />
==Standalone Homebrew Launcher Exploits==<br />
The following homebrew exploits can be executed on a previously un-exploited system. ''Please'' see the above Payload section regarding what "Supported firmwares" indicates ''exactly''.<br />
<br />
{| class="wikitable" border="1"<br />
|-<br />
! Works on latest fw<br />
! Name<br />
! Supported firmwares<br />
! Requirements<br />
! Author<br />
! Install<br />
|-<br />
| style="background: salmon" | No<br />
| [[ninjhax|Ninjhax 1.1b]]<br />
| From '''4.0.0-7''' up to and including '''9.2.0-20'''.<br />
| A cartridge or eShop version (JPN-only) of "Cubic Ninja".<br />
| smea<br />
| [http://smealum.net/ninjhax/ Install]<br />
|-<br />
| style="background: lightgreen" | Yes<br />
| [[ninjhax|Ninjhax 2.x]]<br />
| From '''9.0.0-7''' up to and including '''11.2.0-35'''.<br />
| A cartridge or eShop version (JPN-only, not available anymore for purchase) of "Cubic Ninja".<br />
| smea<br />
| [https://smealum.github.io/ninjhax2/ Install]<br />
|-<br />
| style="background: lightgreen" | Yes<br />
| [http://plutooo.github.io/freakyhax/ freakyhax]<br />
| From '''9.0.0-7''' up to and including '''11.2.0-35'''.<br />
| A cartridge or eShop version (USA/EUR/JAP, not available anymore for purchase) of "Freakyform Deluxe".<br />
| plutoo<br />
| [http://plutooo.github.io/freakyhax/ Install]<br />
|-<br />
| style="background: salmon" | No<br />
| [http://plutooo.github.io/smilehax/ smilehax]<br />
| From '''9.0.0-7''' up to and including '''11.0.0-33'''<br />
| SmileBASIC (JPN all versions up to 3.32 excluded, USA 3.31 only)<br />
| plutoo<br />
| [http://plutooo.github.io/smilehax/ Install]<br />
|-<br />
| style="background: salmon" | No<br />
| [http://mrnbayoh.github.io/basicsploit/ BASICSploit]<br />
| From '''9.0.0-7''' up to and including '''11.0.0-33'''<br />
| SmileBASIC (USA all versions)<br />
| MrNbaYoh<br />
| [http://mrnbayoh.github.io/basicsploit/ Install]<br />
|-<br />
| style="background: lightgreen" | Yes<br />
| [[smashbroshax|smashbroshax]] (beaconhax)<br />
| (New 3DS only) From '''9.0.0-X''' up to and including '''11.2.0-35'''.<br />
| Super Smash Bros 3DS (full-game) and a way to broadcast raw wifi beacons. The demo (prior to the updated November 2015 [https://github.com/yellows8/3ds_smashbroshax version]) isn't usable with the *hax payloads. Game-version v1.1.3 fixed the vuln used with this, see the repo for a workaround for that.<br />
| [[User:Yellows8|Yellows8]]<br />
| [https://github.com/yellows8/3ds_smashbroshax Install]<br />
|-<br />
| style="background: salmon" | No<br />
| [[browserhax]]<br />
| From '''9.0.0-2''' to '''11.0.0-33'''<br />
Note that the browser-version-check bypass is only usable prior to [[10.7.0-32]].<br />
| A USA, EUR, JPN, or KOR system.<br />
| [[User:Yellows8|Yellows8]]<br />
| [http://yls8.mtheall.com/3dsbrowserhax.php Install]<br />
|-<br />
| style="background: lightgreen" | Yes<br />
| [https://github.com/svanheulen/genhax genhax]<br />
| (New 3DS only) From '''9.9.0-X''' up to and including '''11.2.0-X'''.<br />
| A gamecard or eShop-install of Monster Hunter X (JPN only), and the DLC encryption key (see installer instructions).<br />
| svanheulen<br />
| [https://github.com/svanheulen/genhax_installer Install]<br />
|-<br />
| style="background: lightgreen" | Yes<br />
| [https://github.com/nedwill/soundhax soundhax]<br />
| From '''9.0.0-X''' to '''11.2.0-X' for EUR and USA, '''10.6.0-X''' to '''11.2.0-X''' for JPN<br />
| A USA, EUR or JPN system.<br />
| nedwill<br />
| [https://github.com/nedwill/soundhax/ Install]<br />
|}<br />
<br />
Note that ninjhax 1.x is still not obsolete. Even though ninjhax 2.x can be run on 9.3+, this was made possible (amongst other things) by sacrificing the memory remapping exploit used in ninjhax 1.x (rohax). Therefore, things like JIT engines for emulators can only be supported on ninjhax 1.x. Furthermore, ninjhax 2.x does not run on system versions below 9.0.0-X, while ninjhax 1.x does.<br />
<br />
==Secondary Exploits==<br />
Installation of these exploits requires a previously exploited system to install. After installation, they can be used on their own. ''Please'' see the above Payload section regarding what "Supported firmwares" indicates ''exactly''.<br />
<br />
{| class="wikitable" border="1"<br />
! Works on latest fw<br />
! Name<br />
! Supported firmwares<br />
! Requirements<br />
! Author<br />
! Install<br />
|-<br />
| style="background: salmon" | No<br />
| [[ironhax]]<br />
| From '''9.5.0-X''' up to and including '''10.3.0-X''', for '''X''' up to and including 28.<br />
| A copy of "Ironfall: Invasion" downloaded from eShop before August 11th, 2015. Note the updated version that was released on October 13th, 2015 is not supported.<br />
| smea<br />
| [http://smealum.github.io/3ds/ Install]<br />
|-<br />
| style="background: lightgreen" | Yes<br />
| [http://vegaroxas.github.io/ steelhax]<br />
| From '''9.0.0-X''' up to and including '''11.2.0-X''', for '''X''' up to and including 35.<br />
| A copy of Steel Diver: Sub Wars<br />
| Vegaroxas<br />
| [https://github.com/VegaRoXas/vegaroxas.github.io/raw/master/files/steelhax-installer.zip Install]<br />
|-<br />
| style="background: lightgreen" | Yes<br />
| [https://github.com/yellows8/oot3dhax oot3dhax]<br />
| From '''9.0.0-X''' up to and including '''11.2.0-X''', for '''X''' up to and including 35.<br />
| A gamecard or eShop-install of Legend of Zelda: Ocarina of Time 3D. Besides using the installer app, writing raw saveimages with a save dongle for example is another option. Before compression was introduced in the 2016-7-18 release, the size of the *hax payload meant the exploit can't coexist with regular saves on a physical version of the game.<br />
| Yellows8 / smea et al.<br />
| See [https://smealum.github.io/3ds/ here].<br />
|-<br />
| style="background: salmon" | No<br />
| [[menuhax]]<br />
| JPN/USA/EUR: From '''9.0.0-X''' up to and including '''11.0.0-X'''.<br />
KOR: From '''9.6.0-X''' up to and including '''11.0.0-X'''.<br />
| JPN/USA/EUR: Having created [[Home_Menu#Home_Menu_Theme_SD_ExtData|theme extdata]] through opening the official theme selector at least once.<br />
| [[User:Yellows8|Yellows8]]<br />
| [https://github.com/yellows8/3ds_homemenuhax/releases Download]<br />
|-<br />
| style="background: lightgreen" | Yes<br />
| [https://github.com/shinyquagsire23/supermysterychunkhax supermysterychunkhax]<br />
| From '''9.9.0-X''' (USA/JPN) / '''10.2.0-X''' (EUR) up to and including '''11.1.0-X''', for '''X''' up to and including 34.<br />
| A gamecard or eShop-install of Pokémon Super Mystery Dungeon.<br />
| Shiny Quagsire / SALT team<br />
| [https://smd.salthax.org/ Install].<br />
|-<br />
| style="background: salmon" | No<br />
| [https://github.com/shinyquagsire23/v_hax (v*)hax]<br />
| From '''9.0.0-X''' up to and including '''11.0.0-X''', for '''X''' up to and including 33.<br />
Note that '''9.0.0-X''' is only required for the Homebrew Launcher - the game itself only requires '''2.1.0-X''' for primitive userland code execution.<br />
| A copy of VVVVVV downloaded after March 2012 (v1). v1.1 patches out the overflow vulnerability used by (v*)hax.<br />
| Shiny Quagsire / SALT team<br />
| [https://vvvvvv.salthax.org/ Install].<br />
|-<br />
| style="background: lightgreen" | Yes<br />
| [https://github.com/Dazzozo/humblehax humblehax]<br />
| From '''9.0.0-X''' (USA/EUR) up to and including '''11.2.0-X''', for '''X''' up to and including 35.<br />
| An eShop-install of Citizens of Earth (either v1 or v2), featured in the Humble "Friends of Nintendo" Bundle.<br />
| Dazzozo / SALT team<br />
| [https://citizens.salthax.org/ Install].<br />
|-<br />
| style="background: salmon" | No<br />
| [http://mrnbayoh.github.io/basehaxx/ basehaxx]<br />
| From '''9.0.0-X''' up to and including '''11.1.0-X''', for '''X''' up to and including 34.<br />
| A gamecard or eShop-install of Pokémon Omega Ruby / Alpha Sapphire.<br />
| MrNbaYoh<br />
| [http://mrnbayoh.github.io/basehaxx/ install]<br />
|-<br />
| style="background: lightgreen" | Yes<br />
| [https://github.com/yellows8/stickerhax stickerhax]<br />
| From '''9.0.0-X''' up to and including '''11.2.0-X'''.<br />
| A gamecard or eShop-install of Paper Mario: Sticker Star.<br />
| [[User:Yellows8|Yellows8]]<br />
| [https://github.com/yellows8/stickerhax Here]<br />
|-<br />
| style="background: lightgreen" | Yes<br />
| [https://github.com/svanheulen/genhax genhax]<br />
| (New 3DS only) From '''9.9.0-X'''(JPN) or '''10.3.0-X'''(EUR/USA) up to and including '''11.2.0-X'''.<br />
| A gamecard or eShop-install of Monster Hunter Generations, and an internet connection during installation.<br />
| svanheulen<br />
| [https://github.com/svanheulen/genhax_installer Install]<br />
|-<br />
| style="background: lightgreen" | Yes<br />
| [https://github.com/MrNbaYoh/painthax painthax]<br />
| From '''9.0.0-X''' up to and including '''11.2.0-X'''.<br />
| An eShop-install of PixelPaint.<br />
| MrNbaYoh<br />
| [https://github.com/MrNbaYoh/painthax/releases/latest install]<br />
|}<br />
<br />
==Exploits without Homebrew Launcher (Not recommended)==<br />
<br />
<u>'''Warning:'''</u> The following exploits can run code, but are missing a 3DSX launcher. They cannot launch any homebrew in the 3DSX format.<br />
<br />
{| class="wikitable" border="1"<br />
|-<br />
! Works on latest fw<br />
! Name<br />
! Supported firmwares<br />
! Requirements<br />
! Author<br />
! Install<br />
|-<br />
| style="background: salmon" | No<br />
| [[browserhax]] (Without the loader in the 3ds_browserhax_common repo)<br />
| (Old3DS) From '''5.0.0-2''' to '''11.0.0-33''' (Pre-v5.0 is supported for some versions if you manually modify the source)<br />
<br />
(New3DS) From '''9.0.0-20''' to '''11.0.0-33'''<br />
<br />
Note that the browser-version-check bypass is only usable prior to [[10.7.0-32]].<br />
| An USA, EUR, or JPN system.<br />
| [[User:Yellows8|Yellows8]]<br />
| [[browserhax|Install]]<br />
|-<br />
| style="background: salmon" | No<br />
| Ninjhax (with specialized payloads)<br />
| Up to '''9.2.0-20'''?<br />
| <br />
| smea + independent developers<br />
| N/A<br />
|}<br />
<br />
==Previous Exploits==<br />
<u>'''Warning:'''</u> These exploits '''do not work'''. They are exploits which no longer function at all, regardless of software or firmware revision.<br />
{| class="wikitable" border="1"<br />
! Works on latest fw<br />
! Name<br />
! Supported firmwares<br />
! Requirements<br />
! Author<br />
! Install<br />
|-<br />
| style="background: salmon" | No<br />
| [[tubehax|Tubehax]]<br />
| None. '''Was''': From '''9.0.0-X''' up to and including '''10.1.0-X''', for '''X''' up to and including 27.<br />
| The YouTube application and an Internet connection. As of October 15, 2015, this is no longer usable due to an update being released which fixes the vuln used by tubehax + app update being forced (see [[YouTube|here]]).<br />
| smea<br />
| [http://smealum.github.io/3ds/ Install]<br />
|}<br />
<br />
==Other Homebrew Loaders==<br />
The [https://github.com/yellows8/hblauncher_loader hblauncher_loader] title can be used when running under modded-FIRM which allows running unsigned titles, to boot the *hax payloads.<br />
<br />
==Sysmodule Exploits==<br />
This section is for system-module exploits, which can be run from the *hax payloads.<br />
<br />
{| class="wikitable" border="1"<br />
! Works on latest fw<br />
! Name<br />
! Supported firmwares<br />
! Requirements<br />
! Author<br />
|-<br />
| style="background: lightgreen" | Yes, that's not the intended default use however.<br />
| [https://github.com/yellows8/ctr-httpwn/releases ctr-httpwn]<br />
| From '''9.6.0-X''' up to and including '''11.2.0-X'''.<br />
| None<br />
| [[User:Yellows8|Yellows8]]<br />
|}<br />
<br />
==WebKit vuln testing==<br />
See [https://github.com/yellows8/3ds_browserhax_common/issues/28 here].</div>Mrrraouhttps://www.3dbrew.org/w/index.php?title=3DS_System_Flaws&diff=189303DS System Flaws2016-12-19T09:46:12Z<p>Mrrraou: /* Kernel11 */</p>
<hr />
<div>Exploits are used to execute unofficial code (homebrew) on the Nintendo 3DS. This page is a list of publicly known system flaws, for userland applications/applets flaws see [[3DS_Userland_Flaws|here]].<br />
<br />
=Stale / Rejected Efforts=<br />
* Neimod has been working on a RAM dumping setup for a little while now. He's de-soldered the 3DS's RAM chip and hooked it and the RAM pinouts on the 3DS' PCB up to a custom RAM dumping setup. A while ago he published photos showing his setup to be working quite well, with the 3DS successfully booting up. However, his flickr stream is now private along with most of his work.<br />
<br />
* Someone (who will remain unnamed) has released CFW and CIA installers, all of which is copied from the work of others, or copyrighted material.<br />
<br />
==Tips and info==<br />
The 3DS uses the XN feature of the ARM11 processor. There's no official way from applications to enable executable permission for memory containing arbitrary unsigned code(there's a [[SVC]] for this, but only [[RO_Services|RO-module]] has access to it). A usable userland exploit would still be useful: you could only do return-oriented-programming with it initially. From ROP one could then exploit system flaw(s), see below.<br />
<br />
SD card [[extdata]] and SD savegames can be attacked, for consoles where the console-unique [[Nand/private/movable.sed|movable.sed]] was dumped(accessing SD data is far easier by running code on the target 3DS however).<br />
<br />
=System flaws=<br />
== Hardware ==<br />
{| class="wikitable" border="1"<br />
! Summary<br />
! Description<br />
! Fixed with hardware model/revision<br />
! Newest hardware model/revision this flaw was checked for<br />
! Timeframe this was discovered<br />
! Discovered by<br />
|-<br />
| ARM9/ARM11 bootrom vectors point at unitialized RAM<br />
| ARM9's and ARM11's exception vectors are hardcoded to point at the CPU's internal memory (0x08000000 region for ARM9, AXIWRAM for ARM11). While the bootrom does set them up to point to an endless loop at some point during boot, it does not do so immediately. As such, a carefully-timed fault injection (via hardware) to trigger an exception (such as an invalid instruction) will cause execution to fall into ARM9 RAM. <br />
Since RAM isn't cleared on boot (see below), one can immediately start execution of their own code here to dump bootrom, OTP, etc.<br />
The ARM9 bootrom does the following at reset: reset vector branches to another instruction, then branches to bootrom+0x8000. Hence, there's no way to know for certain when exactly the ARM9 exception-vector data stored in memory gets initialized.<br />
<br />
This requires *very* *precise* timing for triggering the hardware fault: it's unknown if anyone actually exploited this successfully at the time of writing(the one who attempted+discovered it *originally* as listed in this wiki section hasn't).<br />
| None: all available 3DS models at the time of writing have the exact same ARM9/ARM11 bootrom for the unprotected areas.<br />
| New3DS<br />
| End of February 2014<br />
| [[User:Derrek|derrek]], WulfyStylez (May 2015) independently<br />
|-<br />
| Missing AES key clearing<br />
| The hardware AES engine does not clear keys when doing a hard reset/reboot.<br />
| None<br />
| New3DS<br />
| August 2014<br />
| Mathieulh/Others<br />
|-<br />
| No RAM clearing on reboots<br />
| On an MCU-triggered reboot all RAM including FCRAM/ARM9 memory/AXIWRAM/VRAM keeps its contents.<br />
| None<br />
| New3DS<br />
| March 2014<br />
| [[User:Derrek|derrek]]<br />
|-<br />
| 32bits of actual console-unique TWLNAND keydata<br />
| On retail the 8-bytes at ARM9 address [[Memory_layout|0x01FFB808]] are XORed with hard-coded data, to generate the TWL console-unique keys, including TWLNAND. On Old3DS the high u32 is always 0x0, while on New3DS that u32 is always 0x2. On top of this, the lower u32's highest bit is always ORed. only 31 bits of the TWL console-unique keydata / TWL consoleID are actually console-unique.<br />
This allows one to easily bruteforce the TWL console-unique keydata with *just* data from TWLNAND. On DSi the actual console-unique data for key generation is 8-bytes(all bytes actually set).<br />
| None<br />
| New3DS<br />
| 2012?<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| DSi / 3DS-TWL key-generator<br />
| After using the key generator to generate the normal-key, you could overwrite parts of the normal-key with your own data and then recover the key-generator output by comparing the new crypto output with the original crypto output. From the normal-key outputs, you could deduce the TWL key-generator function.<br />
This applies to the keyX/keyY too.<br />
<br />
This attack does not work for the 3DS key-generator because keyslots 0-3 are only for TWL keys.<br />
| None<br />
| New3DS<br />
| 2011<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| 3DS key-generator<br />
| The algorithm for generating the normal-keys for keyslots is cryptographically weak. As a result, it is easily susceptible to differential cryptanalysis if the normal-key corresponding to any scrambler-generated keyslot is discovered.<br />
<br />
Several such pairs of matching normal-keys and KeyY values were found, leading to deducing the key-generator function.<br />
| None<br />
| New3DS<br />
| February 2015<br />
| [[User:Yellows8|Yellows8]], [[User:Plutooo|plutoo]]<br />
|-<br />
| FIRM partitions known-plaintext<br />
| The [[Flash_Filesystem|FIRM partitions]] are encrypted with AES-CTR without a MAC. Since this works by XOR'ing data with a static (per-console in this case) keystream, one can deduce the keystream of a portion of each FIRM partition if they have the actual FIRM binary stored in it.<br />
<br />
This can be paired with many exploits. For example, it allows minor FIRM downgrades (i.e. 10.4 to 9.6 or 9.5 to 9.4, but not 9.6 to 9.5).<br />
<br />
This can be somewhat addressed by having a FIRM header skip over previously used section offsets, but this would just air-gap newer FIRMs without fixing the core bug. This can also only be done a limited number of times due to the size of FIRM versus the size of the partitions.<br />
| None<br />
| New3DS<br />
| <br />
| Everyone<br />
|}<br />
<br />
== ARM9 software ==<br />
=== arm9loader ===<br />
{| class="wikitable" border="1"<br />
|-<br />
! Summary<br />
! Description<br />
! Successful exploitation result<br />
! Fixed in [[FIRM]] system version<br />
! Last [[FIRM]] system version this flaw was checked for<br />
! Timeframe this was discovered<br />
! Public disclosure timeframe<br />
! Discovered by<br />
|-<br />
| Rearrangable keys in the NAND keystore<br />
| Due to the keystore being encrypted with AES-ECB, one can rearrange blocks and still have the NAND keystore decrypt in a deterministic way. <br />
<br />
Using 10.0 FIRM it is possible to rearrange keys such that ARM9 memory is executed. As such using existing ARM9 execution 10.0 FIRM can be written to NAND and a payload written to memory, with the payload to be executed post-K9L using an MCU reboot.<br />
| arm9loaderhax given existing ARM9 code execution<br />
| None<br />
| [[11.2.0-35|11.2.0-X]]<br />
| Early 2016<br />
| 27 September 2016<br />
| Myria, [[User:Dark samus|dark_samus]]; mathieulh (independently); [[User:Plutooo|plutoo]] (independently) + others<br />
|-<br />
| Uncleared OTP hash keydata in console-unique 0x11 key-generation<br />
| Kernel9Loader does not clear the [[SHA_Registers#SHA_HASH|SHA_HASH register]] after use. As a result, the data stored here as K9L hands over to Kernel9 is the hash of [[OTP_Registers|OTP data]] used to seed the [[FIRM#New_3DS_FIRM|console-unique NAND keystore decryption key]] set on keyslot 0x11.<br />
<br />
Retrieving this keydata and the [[Flash_Filesystem#0x12C00|NAND keystore]] of the same device allows calculating the decrypted New3DS NAND keystore (non-unique, common to all New3DS units), which contains AES normal keys, also set on keyslot 0x11, which are then used to derive all current [[AES_Registers#Keyslots|New3DS-only AES keyXs]] including the newer batch introduced in [[9.6.0-24#arm9loader|9.6.0-X]]. From there, it is trivial to perform the same key derivation in order to initialize those keys on any system version, and even on Old3DS.<br />
<br />
This can be performed by exploiting the "arm9loaderhax" vulnerability to obtain post-K9L code execution after an MCU reboot (the bootrom section-loading fail is not relevant here, this attack was performed without OTP data by brute-forcing keys), and using this to dump the SHA_HASH register. This attack works on any FIRM version shipping a vulnerable version of K9L, whereas OTP dumping required a boot of <[[3.0.0-6|3.0.0-X]].<br />
<br />
This attack results in obtaining the entire (0x200-bytes) NAND keystore - it was confirmed at a later date that this keystore is encrypted with the same key (by comparing the decrypted data from multiple units), and therefore using another key in this store will not remedy the issue as all keys are known (i.e. later, unused keys decrypt to the same 0x200-bytes constant with the same OTP hash). Later keys could have been encrypted differently but this is not the case. As a result of this, it is not possible for Nintendo to use K9L again in its current format for its intended purpose, though this was not news from the moment people dumped a New3DS OTP.<br />
| Derivation of all New3DS keys generated via the NAND keystore (0x1B "Secure4" etc.)<br />
| None<br />
| [[11.2.0-35|11.2.0-X]]<br />
| ~April 2015, implemented in May 2015<br />
| 13 January 2016<br />
| [[User:WulfyStylez|WulfyStylez]], [[User:Dazzozo|Dazzozo]], [[User:Shinyquagsire23|shinyquagsire23]] (complimentary + implemented), [[User:Plutooo|plutoo]], Normmatt (discovered independently)<br />
|-<br />
| enhanced-arm9loaderhax<br />
| See the 32c3 3ds talk.<br />
Since this is a combination of a trick with the arm9-bootrom + arm9loaderhax, and since you have to manually write FIRM to the firm0/firm1 NAND partitions, this can't be completely fixed. Any system with existing ARM9 code execution and an OTP/OTP hash dump can exploit this. Additionally, by using the FIRM partition known-plaintext bug and bruteforcing the second entry in the keystore, this can currently be exploited on all New3DS systems without any other prerequisite hacks.<br />
| arm9loaderhax which automatically occurs at hard-boot.<br />
| See arm9loaderhax / description.<br />
| See arm9loaderhax / description.<br />
| Theorized around mid July, 2015. Later implemented+tested by [[User:Plutooo|plutoo]] and [[User:Derrek|derrek]].<br />
| 32c3 3ds talk (December 27, 2015)<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| Missing verification-block for the 9.6 keys (arm9loaderhax)<br />
| Starting with [[9.6.0-24|9.6.0-X]] a new set of NAND-based keys were introduced. However, no verification block was added to verify that the new key read from NAND is correct. This was technically an issue from [[9.5.0-22|9.5.0-X]] with the original sector+0 keydata, however the below is only possible with [[9.6.0-24|9.6.0-X]] since keyslots 0x15 and 0x16 are generated from different 0x11 keyXs.<br />
<br />
Writing an incorrect key to NAND will cause arm9loader to decrypt the ARM9 kernel as garbage and then jump to it.<br />
<br />
This allows an hardware-based attack where you can boot into an older exploited firmware, fill all memory with NOP sleds/jump-instructions, and then reboot into executing garbage. By automating this process with various input keydata, eventually you'll find some garbage that jumps to your code.<br />
<br />
This gives very early ARM9 code execution (pre-ARM9 kernel). As such, it is possible to dump RSA keyslots with this and calculate the 6.x [[Savegames#6.0.0-11_Savegame_keyY|save]], and 7.x [[NCCH]] keys. This cannot be used to recover keys initialized by arm9loader itself. This is due to it wiping the area used for its stack during NAND sector decryption and keyslot init. <br />
<br />
Due to FIRMs on both Old and New 3DS using the same RSA data, this can be exploited on Old3DS as well, but only if one already has the actual plaintext normalkey from New3DS NAND sector 0x96 offset-0 and has dumped the OTP area of the Old3DS.<br />
| Recovery of 6.x [[Savegames#6.0.0-11_Savegame_keyY|save key]]/7.x [[NCCH]] key, access to uncleared OTP hash keydata<br />
| None<br />
| [[11.2.0-35|11.2.0-X]]<br />
| March, 2015<br />
| <br />
| [[User:Plutooo|plutoo]]<br />
|-<br />
| Uncleared New3DS keyslot 0x11<br />
| Originally the New3DS [[FIRM]] arm9bin loader only cleared keyslot 0x11 when it gets executed at firmlaunch. This was fixed with [[9.5.0-22|9.5.0-X]] by completely clearing keyslot 0x11 immediately after the loader finishes using keyslot 0x11.<br />
This means that any ARM9 code that can execute before the loader clears the keyslot at firmlaunch(including firmlaunch-hax) can get access to the uncleared keyslot 0x11, which then allows one to generate all <=v9.5 New3DS keyXs which are generated by keyslot 0x11.<br />
<br />
Therefore, to completely fix this the loader would have to generate more keys using different keyslot 0x11 keydata. This was done with [[9.6.0-24|9.6.0-X]].<br />
| New3DS keyXs generation<br />
| Mostly fixed with [[9.5.0-22|9.5.0-X]], completely fixed with new keys with [[9.6.0-24|9.6.0-X]].<br />
| <br />
| February 3, 2015 (one day after [[9.5.0-22|9.5.0-X]] release)<br />
| <br />
| [[User:Yellows8|Yellows8]]<br />
|}<br />
<br />
=== Process9 ===<br />
{| class="wikitable" border="1"<br />
|-<br />
! Summary<br />
! Description<br />
! Successful exploitation result<br />
! Fixed in [[FIRM]] system version<br />
! Last [[FIRM]] system version this flaw was checked for<br />
! Timeframe this was discovered<br />
! Public disclosure timeframe<br />
! Discovered by<br />
|-<br />
| Leak of normal-key matching a key-scrambler key<br />
| New 3DS firmware versions [[8.1.0-0 New3DS|8.1.0]] through [[9.2.0-20|9.2.0]] set the encryption key for [[Amiibo]] data using a hardcoded normal-key in Process9. In firmware [[9.3.0-21|9.3.0]], Nintendo "fixed" this by using the key scrambler instead, by calculating the keyY value for keyslot 0x39 that results in the same normal-key, then hardcoding that keyY into Process9.<br />
<br />
Nintendo's fix is actually the problem: Nintendo revealed the normal-key matching an unknown keyX and a known keyY. Combined with the key scrambler using an insecure scrambling algorithm (see "Hardware" above), the key scrambler function could be deduced.<br />
| Deducing the keyX for keyslot 0x39 and the key scrambler algorithm<br />
| New 3DS [[9.3.0-21|9.3.0-X]], sort of<br />
| [[10.0.0-27|10.0.0-X]]<br />
| Sometime in 2015 after the hardware key-generator was broken.<br />
| 32c3 3ds talk (December 27, 2015)<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| Leak of normal-key matching a key-generator key<br />
| During the 3DS' development (June/July 2010) Nintendo added support installing encrypted content ([[CIA]]). Common-key index1 was intended to be a [[AES|hardware generated key]]. However while they added code to generate the key in hardware, they forgot to remove the normal-key for index1 (used elsewhere, likely old debug code). Nintendo later removed the normal key sometime before the first non-prototype firmware release.<br />
<br />
<br />
Knowing the keyY and the normal-key for common-key index1, the devkit key-generator algorithm can be deduced (see "Hardware" above). Additionally the remaining devkit common-keys can be generated once the common-key keyX is recovered.<br />
<br />
Note the devkit key-generator was discovered to be the same as the retail key-generator.<br />
| Deducing the keyX for keyslot 0x3D and hardware key-generator algorithm. Generate remaining devkit common-keys.<br />
| pre-[[1.0.0-0|1.0.0-X]]<br />
| <br />
| Shortly after the key-generator was revealed to be flawed at the 32c3 3ds talk<br />
| January 20, 2016<br />
| [[User:Jakcron|jakcron]]<br />
|-<br />
| ntrcardhax<br />
| <br />
| ARM9 code execution<br />
| 10.4.0-29<br />
| <br />
| March 2015<br />
| 32c3 3ds talk (December 27, 2015)<br />
| [[User:Plutooo|plutoo]]<br />
|-<br />
| Title downgrading via [[Application_Manager_Services|AM]]([[Application_Manager_Services_PXI|PXI]])<br />
| When a title is *already* installed, Process9 will compare the installed title-version with the title-version being installed. When the one being installed is older, Process9 would return an error.<br />
<br />
However, this can be bypassed by just deleting the title first via the service command(s) for that: with the title removed from the [[Title_Database]], Process9 can't compare the input title-version with anything. Hence, titles can be downgraded this way.<br />
<br />
[[11.0.0-33|11.0.0-X]] fixed this for key system titles (MSET, Home Menu, spider, ErrDisp, SKATER, NATIVE_FIRM, and every retail system module), by checking the version of the title to install against a hard-coded list of (titleID, minimumVersionRequired) pairs.<br />
| Bypassing title version check at installation, which then allows downgrading any title.<br />
| [[11.0.0-33|11.0.0-X]], for key system titles.<br />
| NATIVE_FIRM / AM-sysmodule [[11.0.0-33|11.0.0-X]]<br />
| ?<br />
| <br />
| ?<br />
|-<br />
| FAT FS code null-deref<br />
| When FSFile:Read is used with a file which is corrupted on a FAT filesystem(in particular SD), Process9 can crash. This particular crash is caused by a function returning NULL instead of an actual ptr due to an error. The caller of that function doesn't check for NULL which then triggers a read based at NULL.<br />
<br />
Sample "fsck.vfat -n -v -V <fat image backup>" output for the above crash:<br />
<br />
<pre>...<br />
Starting check/repair pass.<br />
<FilePath0> and<br />
<FilePath1><br />
share clusters.<br />
Truncating second to 3375104 bytes.<br />
<FilePath1><br />
File size is 2787392 bytes, cluster chain length is 16384 bytes.<br />
Truncating file to 16384 bytes.<br />
Checking for unused clusters.<br />
Reclaimed 1 unused cluster (16384 bytes).<br />
Checking free cluster summary.<br />
Free cluster summary wrong (1404490 vs. really 1404491)<br />
Auto-correcting.<br />
Starting verification pass.<br />
Checking for unused clusters.<br />
Leaving filesystem unchanged.</pre><br />
| Useless null-based-read<br />
| None<br />
| [[9.6.0-24|9.6.0-X]]<br />
| July 8-9, 2015<br />
| <br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| RSA signature padding checks<br />
| The TWL_FIRM RSA sig padding check code used for all TWL RSA sig-checks has issues, see [[FIRM|here]].<br />
The main 3DS RSA padding check code(non-certificate, including NATIVE_FIRM) uses the function used with the above to extract more padding + the actual hash from the additional padding. This isn't really a problem here because there's proper padding check code which is executed prior to this.<br />
| <br />
| None<br />
| [[9.5.0-22|9.5.0-X]]<br />
| March 2015<br />
| <br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[AMPXI:ValidateDSiWareSectionMAC]] [[AES_Registers|AES]] keyslot reuse<br />
| When the input DSiWare section index is higher than <max number of DSiWare sections supported by this FIRM>, Process9 uses keyid 0x40 for calculating the AESMAC, which translates to keyslot 0x40. The result is that the keyslot is left at whatever was already selected before, since the AES selectkeyslot code will immediately return when keyslot is >=0x40. However, actually exploiting this is difficult: the calculated AESMAC is never returned, this command just compares the calculated AESMAC with the input AESMAC(result-code depends on whether the AESMACs match). It's unknown whether a timing attack would work with this.<br />
This is basically a different form of the pxips9 keyslot vuln, except with AESMAC etc.<br />
| See description.<br />
| None<br />
| [[11.2.0-35|11.2.0-X]]<br />
| March 15, 2015<br />
| December 29, 2015<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| pxips9 [[AES_Registers|AES]] keyslot reuse<br />
| This requires access to the [[Process_Services|ps:ps]]/pxi:ps9 services. One way to get access to this would be snshax on system-version <=10.1.0-X(see 32c3 3ds talk).<br />
When an invalid key-type value is passed to any of the PS commands, Process9 will try to select keyslot 0x40. That aesengine_setkeyslot() code will then immediately return due to the invalid keyslot value. Since that function doesn't return any errors, Process9 will just continue to do crypto with whatever AES keyslot was selected before the PS command was sent.<br />
| Reusing the previously used keyslot, for crypto with PS.<br />
| None<br />
| [[11.2.0-35|11.2.0-X]]<br />
| Roughly the same time(same day?) as firmlaunch-hax.<br />
| December 29, 2015<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| firmlaunch-hax: FIRM header ToCToU<br />
| This can't be exploited from ARM11 userland.<br />
During [[FIRM]] launch, the only FIRM header the ARM9 uses at all is stored in FCRAM, this is 0x200-bytes(the actual used FIRM RSA signature is read to the Process9 stack however). The ARM9 doesn't expect "anything" besides the ARM9 to access this data.<br />
With [[9.5.0-22]] the address of this FIRM header was changed from a FCRAM address, to ARM9-only address 0x01fffc00.<br />
| ARM9 code execution<br />
| [[9.5.0-22]]<br />
| <br />
| 2012, 3 days after [[User:Yellows8|Yellows8]] started Process9 code RE.<br />
| <br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| Uninitialized data output for (PXI) command replies<br />
| PXI commands for various services(including some [[Filesystem_services_PXI|here]] and many others) can write uninitialized data (like from ARM registers) to the command reply. This happens with stubbed commands, but this can also occur with certain commands when returning an error.<br />
Certain ARM11 service commands have this same issue as well.<br />
| <br />
| None<br />
| [[9.3.0-21|9.3.0-X]]<br />
| ?<br />
| <br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[Filesystem_services_PXI|FSPXI]] OpenArchive SD permissions<br />
| Process9 does not use the exheader ARM9 access-mount permission flag for SD at all.<br />
This would mean ARM11-kernelmode code / fs-module itself could directly use FSPXI to access SD card without ARM9 checking for SD access, but this is rather useless since a process is usually running with SD access(Home Menu for example) anyway.<br />
| <br />
| None<br />
| [[9.3.0-21|9.3.0-X]]<br />
| 2012<br />
| <br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[AMPXI:ExportDSiWare]] export path<br />
| Process9 allocates memory on Process9 heap for the export path then verifies that the actual allocated size matches the input size. Then Process9 copies the input path from FCRAM to this buffer, and uses it with the Process9 FS openfile code, which use paths in the form of "<mountpoint>:/<path>".<br />
Process9 does not check the contents of this path at all before passing it to the FS code, besides writing a NUL-terminator to the end of the buffer.<br />
| Exporting of DSiWare to arbitrary Process9 file-paths, such as "nand:/<path>" etc. This isn't really useful since the data which gets written can't be controlled.<br />
| None<br />
| [[9.5.0-22]]<br />
| April 2013<br />
| <br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[DSiWare_Exports]] [[CTCert]] verification<br />
| Just like DSi originally did, 3DS verifies the APCert for DSiWare on SD with the CTCert also in the DSiWare .bin. On DSi this was fixed with with system-version 1.4.2 by verifying with the actual console-unique cert instead(stored in NAND), while on 3DS it's still not(?) fixed.<br />
On 3DS however this is rather useless, due to the entire DSiWare .bin being encrypted with the console-unique movable.sed keyY.<br />
| When the movable.sed keyY for the target 3DS is known and the target 3DS CTCert private-key is unknown, importing of modified DSiWare SD .bin files.<br />
| Unknown, probably none.<br />
| ?<br />
| April 2013<br />
| <br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[Gamecard_Services_PXI]] unchecked REG_CTRCARDCNT transfer-size<br />
| The u8 REG_CTRCARDCNT transfer-size parameter for the [[Gamecard_Services_PXI]] read/write CTRCARD commands is used as an index for an array of u16 values. Before [[5.0.0-11|5.0.0-X]] this u8 value wasn't checked, thus out-of-bounds reads could be triggered(which is rather useless in this case).<br />
| Out-of-bounds read for a value which gets written to a register.<br />
| [[5.0.0-11|5.0.0-X]]<br />
| <br />
| 2013?<br />
| <br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[PXI_Registers|PXI]] cmdbuf buffer overrun<br />
| The Process9 code responsible [[PXI_Registers|PXI]] communications didn't verify the size of the incoming command before writing it to a C++ member variable. <br />
| Probably ARM9 code execution<br />
| [[5.0.0-11|5.0.0-11]]<br />
| <br />
| March 2015, original timeframe if any unknown<br />
| <br />
| [[User:Plutooo|plutoo]]/[[User:Yellows8|Yellows8]]/maybe others(?)<br />
|-<br />
| [[Application_Manager_Services_PXI|PXIAM]] command 0x003D0108(See also [[Application_Manager_Services|this]])<br />
| When handling this command, Process9 allocates a 0x2800-byte heap buffer, then copies the 4 FCRAM input buffers to this heap buffer without checking the sizes at all(only the buffers with non-zero sizes are copied). Starting with [[5.0.0-11|5.0.0-X]], the total combined size of the input data must be <=0x2800.<br />
| ARM9 code execution<br />
| [[5.0.0-11|5.0.0-X]]<br />
| <br />
| May 2013<br />
| <br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[Process_Services_PXI|PS RSA]] commands buffer overflows<br />
| pxips9 cmd1(not accessible via ps:ps) and VerifyRsaSha256: unchecked copy to a buffer in Process9's .bss, from the input FCRAM buffer. The buffer is located before the pxi cmdhandler threads' stacks. SignRsaSha256 also has a buf overflow, but this isn't exploitable.<br />
The buffer for this is the buffer for the signature data. With v5.0, the signature buffer was moved to stack, with a check for the signature data size. When the signature data size is too large, Process9 uses [[SVC|svcBreak]].<br />
| ARM9 code execution<br />
| [[5.0.0-11|5.0.0-X]]<br />
| <br />
| 2012<br />
| <br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[PXI_Registers|PXI]] pxi_id bad check<br />
| The Process9 code responsible for [[PXI_Registers|PXI]] communications read pxi_id as a signed char. There were two flaws:<br />
* They used it as index to a lookup-table without checking the value at all.<br />
* Another function verified that pxi_id < 7, allowing negative values to pass the check. This would also cause an out-of-range table-lookup.<br />
| Maybe ARM9 code execution<br />
| [[3.0.0-5|3.0.0-5]]<br />
|<br />
| March 2015, originally 2012 for the first issue at least<br />
| <br />
| [[User:Plutooo|plutoo]], [[User:Yellows8|Yellows8]], maybe others(?)<br />
|}<br />
<br />
=== Kernel9 ===<br />
{| class="wikitable" border="1"<br />
|-<br />
! Summary<br />
! Description<br />
! Successful exploitation result<br />
! Fixed in [[FIRM]] system version<br />
! Last [[FIRM]] system version this flaw was checked for<br />
! Timeframe this was discovered<br />
! Discovered by<br />
|-<br />
| [[CONFIG Registers#CFG_SYSPROT9|CFG_SYSPROT9]] bit1 not set by Kernel9<br />
| Old versions of Kernel9 never set bit1 of [[CONFIG Registers#CFG_SYSPROT9|CFG_SYSPROT9]]. This leaves the [[OTP Registers|0x10012000]]-region unprotected (this region should be locked early during boot!). Since it's never locked, you can dump it once you get ARM9 code execution.<br />
<br />
From [[3.0.0-5|3.0.0-X]] this was fixed by setting the bit in Kernel9 after poking some registers in that region. On New3DS arm9loader sets this bit instead of Kernel9, which is exploitable through a hardware + software vulnerability (see arm9loaderhax / description).<br />
<br />
This flaw resurged when it gained a new practical use: retrieving the OTP data for a New3DS console in order to decrypt the key data used in arm9loader (see enhanced-arm9loaderhax / description). This was performed by downgrading to a vulnerable system version. By accounting for differences in CTR-NAND crypto (0x05 -> 0x04, see partition encryption types [[Flash_Filesystem#NAND_structure|here]]), it is possible to boot a New3DS using Old3DS firmware 1.0-2.X and an Old3DS [[NCSD#NCSD_header|NCSD Header]] to retrieve the required OTP data using this flaw.<br />
| Dumping of the [[OTP Registers|OTP]] area<br />
| [[3.0.0-5|3.0.0-X]]<br />
|<br />
| February 2015<br />
| [[User:Plutooo|plutoo]], Normmatt independently<br />
|}<br />
<br />
== ARM11 software ==<br />
=== Kernel11 ===<br />
{| class="wikitable" border="1"<br />
|-<br />
! Summary<br />
! Description<br />
! Successful exploitation result<br />
! Fixed in [[FIRM]] system version<br />
! Last [[FIRM]] system version this flaw was checked for<br />
! Timeframe this was discovered<br />
! Discovered by<br />
|-<br />
| [[SVC]] table too small<br />
| The table of function pointers for SVC's only contains entries up to 0x7D, but the biggest allowed SVC for the table is 0x7F. Thus, executing SVC7E or SVC7F would make the SVC-handler read after the buffer, and interpret some ARM instructions as function pointers.<br />
<br />
However, this would require patching the kernel .text or modifying SVC-access-control. Even if you could get these to execute, they would still jump to memory that isn't mapped as executable.<br />
| <br />
| None<br />
| [[11.2.0-35|11.2.0-X]]<br />
| 2012<br />
| Everyone<br />
|-<br />
| [[SVC|svcBackdoor (0x7B)]]<br />
| This backdoor allows executing SVC-mode code at the user-specified code-address. This is used by Process9, using this on the ARM11 (with NATIVE_FIRM) required patching the kernel .text or modifying SVC-access-control.<br />
| See description<br />
| [[11.0.0-33|11.0.0-X]] (deleted)<br />
| <br />
|<br />
| Everyone<br />
|-<br />
| veryslowpidhax<br />
| '''This is completely different from the kernelmode-code-execution vuln described in the below separate entry.'''<br />
<br />
When updating the kernel global PID counter under [[SVC|svcCreateProcess]] the kernel does not check for wraparound to 0x0(the PID for the very first process). This only matters because [[Services|SM-module]] allows processes with PID value less than <total ARM11 FIRM modules> to access ''all'' services, without checking exheader service-access-control; and because Kernel11 checks for the PID to be 1 (loader) to use the input mem-region value on ControlMemory. This alone does not affect access the [[SVC|SVCs]] access table at all.<br />
<br />
Inlined ldrex+strex code is used for updating the above counter. [[11.2.0-35|11.2.0-X]] had changes for similar code, but it was only for dedicated ldrex+strex functions(mainly for kernel objects) and hence this PID code was not affected.<br />
<br />
With launching+terminating a sysmodule repeatedly with this via ns:s, it would take weeks to finish(if not at least about a month?).<br />
| Access to all [[Services_API|services]], ControlMemory on any given mem-region.<br />
| None<br />
| [[11.2.0-35|11.2.0-X]]<br />
| 2012 maybe?<br />
| <br />
|-<br />
| slowhax/waithax<br />
| svcWaitSynchronizationN does not decrement the references to valid handles in an array before returning an error when it encounters an invalid handle. This allows one to (slowly) overflow the reference count for a handle object to zero.<br />
| ARM11 kernel-mode code execution<br />
| [[11.2.0-35|11.2.0-X]]<br />
| [[11.2.0-35|11.2.0-X]]<br />
| 2016<br />
| nedwill, [[User:Derrek|derrek]], others?<br />
|-<br />
| [[Memory_layout#ARM11_Detailed_virtual_memory_map|0xEFF00000]] / 0xDFF00000 ARM11 kernel virtual-memory<br />
| The ARM11 kernel-mode 0xEFF00000/0xDFF00000 virtual-memory(size 0x100000) is mapped to phys-mem 0x1FF00000(entire DSP-mem + entire AXIWRAM), with permissions RW-. This is used during ARM11 kernel startup for loading the FIRM-modules from the FIRM section located in DSP-mem, this never seems to be used after that, however. This is never unmapped either.<br />
| <br />
| None<br />
| [[11.2.0-35|11.2.0-X]]<br />
| <br />
| <br />
|-<br />
| memchunkhax2.1<br />
| Nintendo's fix for memchunkhax2 in [[10.4.0-29|10.4.0-X]] did not fix the GPU case: one may cause the requisite ToCToU race using gspwn, bypassing the new validation.<br />
derrek's original 32c3 presentation for memchunkhax2 commented that a GPU-based attack was possible, but would be difficult. However, memchunkhax2.1 showed that it was possible to do fairly reliably.<br />
| ARM11 kernel code execution<br />
| [[11.0.0-33|11.0.0-X]], via the new [[Memory_Management#MemoryBlockHeader|memchunkhdr]] MAC which prevents modifying memchunkhdr data with DMA.<br />
| [[11.0.0-33|11.0.0-X]]<br />
|<br />
| [[User:Derrek|derrek]], aliaspider<br />
|-<br />
| memchunkhax2<br />
| When allocating a block of memory, the "next" pointer of the [[Memory_Management#MemoryBlockHeader|memchunkhdr]] is accessed without being checked after being mapped to userland.<br />
This allows a race condition, where the process can change the next pointer just before it's accessed. By pointing the next pointer to a crafted memchunckhdr in the kernel SlabHeap, some of the SlabHeap is allocated to the calling process, allowing to change vtables of kernel objects. <br />
| ARM11 kernel code execution<br />
| [[10.4.0-29|10.4.0-X]] (partially, see memchunkhax2.1)<br />
| [[10.4.0-29|10.4.0-X]]<br />
|<br />
| [[User:Derrek|derrek]]<br />
|-<br />
| heaphax<br />
| Can change the size of free memchunk structures stored in FCRAM using DMA, which leads to the ability to allocate memory chunks over already-allocated memory. This can be used in the SYSTEM region to allocate RW memory over any part of the NS system module, which is enough to take it over.<br />
| Code execution with access to all of NS's privileges. (including downgrading) Code execution within any applet.<br />
| [[11.0.0-33|11.0.0-X]], via the new [[Memory_Management#MemoryBlockHeader|memchunkhdr]] MAC which prevents modifying memchunkhdr data with DMA.<br />
| [[11.0.0-33|11.0.0-X]]<br />
| April 2015 ?<br />
| smea<br />
|-<br />
| snshax<br />
| Can force creation of Safe NS process into gspwn-able memory, allowing for takeover.<br />
| Code execution with access to all of NS's privileges. (including downgrading)<br />
| [[10.1.0-27|10.1.0-X]]<br />
| [[10.1.0-27|10.1.0-X]]<br />
| April 2015 ?<br />
| smea<br />
|-<br />
| AffinityMask/processorid validation<br />
| With [[10.0.0-27|10.0.0-X]] the following functions were updated: svcGetThreadAffinityMask, svcGetProcessAffinityMask, svcSetProcessAffinityMask, and svcCreateThread. The code changes for all but svcCreateThread are identical.<br />
The original code with the first 3 did the following: <br />
* if(u32_processorcount > ~0x80000001)return 0xe0e01bfd;<br />
* if(s32_processorcount > <total_cores>)return 0xd8e007fd;<br />
The following code replaced the above:<br />
* if(u32_processorcount >= <total_cores+1>)return 0xd8e007fd;<br />
In theory the latter should catch everything that the former did, so it's unknown if this was really a security issue.<br />
<br />
The svcCreateThread changes with [[10.0.0-27|10.0.0-X]] definitely did fix a security issue.<br />
* Original code: "if(s32_processorid > <total_cores>)return 0xd8e007fd;"<br />
* New code: "if(s32_processorid >= <total_cores> || s32_processorid <= -4)return 0xd8e007fd;"<br />
This fixed an off-by-one issue: if one would use processorid=total_cores, which isn't actually a valid value, svcCreateThread would accept that value on <[[10.0.0-27|10.0.0-X]]. This results in data being written out-of-bounds(baseaddr = arrayaddr + entrysize*processorid), which has the following result:<br />
* Old3DS: Useless kernel-mode crash due to accessing unmapped memory.<br />
* New3DS: uncontrolled data write into a kernel-mode L1 MMU-table. This isn't really useful: the data can't be controlled, and the data which gets overwritten is all-zero anyway(this isn't anywhere near MMU L1 entries for actually mapped memory).<br />
The previous version also allowed large negative s32_processorid values(negative processorid values are special values not actual procids), but it appears using values like that won't actually do anything(meaning no crash) besides the thread not running / thread not running for a while(besides triggering a kernelpanic with certain s32_processorid value(s)).<br />
| Nothing useful<br />
| [[10.0.0-27|10.0.0-X]]<br />
| [[10.0.0-27|10.0.0-X]]<br />
| svcCreateThread issue: May 31, 2015. The rest: September 8, 2015, via v9.6->v10.0 ARM11-kernel code-diff.<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| memchunkhax<br />
| The kernel originally did not validate the data stored in the FCRAM kernel heap [[Memchunkhdr|memchunk-headers]] for free-memory at all. Exploiting this requires raw R/W access to these memchunk-headers, like physical-memory access with gspwn.<br />
<br />
There are ''multiple'' ways to exploit this, but the end-result for most of these is the same: overwrite code in AXIWRAM via the 0xEFF00000/0xDFF00000 kernel virtual-memory mapping.<br />
<br />
This was fixed in [[9.3.0-21|9.3.0-X]] by checking that the memchunk(including size, next, and prev ptrs) is located within the currently used heap memory. The kernel may also check that the next/prev ptrs are valid compared to other memchunk-headers basically. When any of these checks fail, kernelpanic() is called.<br />
| When combined with other flaws: ARM11-kernelmode code execution<br />
| [[9.3.0-21|9.3.0-21]]<br />
| <br />
| February 2014<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| Multiple [[KLinkedListNode|KLinkedListNode]] SlabHeap use after free bugs<br />
| The ARM11-kernel did access the 'key' field of [[KLinkedListNode|KLinkedListNode]] objects, which are located on the SlabHeap, after freeing them. Thus, triggering an allocation of a new [[KLinkedListNode|KLinkedListNode]] object at the right time could result in a type-confusion. Pseudo-code:<br />
SlabHeap_free(KLinkedListNode);<br />
KObject *obj = KLinkedListNode->key; // the object there might have changed!<br />
This bug appeared all over the place.<br />
| ARM11-kernelmode code exec maybe<br />
| [[8.0.0-18|8.0.0-18]]<br />
| <br />
| April 2015<br />
| [[User:Derrek|derrek]]<br />
|-<br />
| PXI [[RPC_Command_Structure|Command]] input/output buffer permissions<br />
| Originally the ARM11-kernel didn't check permissions for PXI input/output buffers for commands. Starting with [[6.0.0-11|6.0.0]] PXI input/output buffers must have RW permissions, otherwise kernelpanic is triggered.<br />
| <br />
| [[6.0.0-11|6.0.0-11]]<br />
| <br />
| 2012<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[SVC|svcStartInterProcessDma]]<br />
| For svcStartInterProcessDma, the kernel code had the following flaws:<br />
<br />
* Originally the ARM11-kernel read the input DmaConfig structure directly in kernel-mode(ldr(b/h) instructions), without checking whether the DmaConfig address is readable under userland. This was fixed by copying that structure to the SVC-mode stack, using the ldrbt instruction.<br />
<br />
* Integer overflows for srcaddr+size and dstaddr+size are now checked(with [[6.0.0-11]]), which were not checked before.<br />
<br />
* The kernel now also checks whether the srcaddr/dstaddr (+size) is within userland memory (0x20000000), the kernel now (with [[6.0.0-11]]) returns an error when the address is beyond userland memory. Using an address >=0x20000000 would result in the kernel reading from the process L1 MMU table, beyond the memory allocated for that MMU table(for vaddr->physaddr conversion). <br />
| <br />
| [[6.0.0-11]]<br />
| <br />
| DmaConfig issue: unknown. The rest: 2014<br />
| [[User:Plutooo|plutoo]], [[User:Yellows8|Yellows8]] independently<br />
|-<br />
| [[SVC|svcControlMemory]] Parameter checks<br />
| For svcControlMemory the parameter check had these two flaws:<br />
<br />
* The allowed range for addr0, addr1, size parameters depends on which MemoryOperation is being specified. The limitation for GSP heap was only checked if op=(u32)0x10003. By setting a random bit in op that has no meaning (like bit17?), op would instead be (u32)0x30003, and the range-check would be less strict and not accurate. However, the kernel doesn't actually use the input address for LINEAR memory-mapping at all besides the range-checks, so this isn't actually useful. This was fixed in the kernel by just checking for the LINEAR bit, instead of comparing the entire MemoryOperation value with 0x10003.<br />
<br />
* Integer overflows on (addr0+size) are now checked that previously weren't (this also applies to most other address checks elsewhere in the kernel).<br />
<br />
| <br />
| [[5.0.0-11]]<br />
| <br />
|<br />
| [[User:Plutooo|plutoo]]<br />
|-<br />
| [[RPC_Command_Structure|Command]] request/response buffer overflow<br />
| Originally the kernel did not check the word-values from the command-header. Starting with [[5.0.0-11]], the kernel will trigger a kernelpanic() when the total word-size of the entire command(including the cmd-header) is larger than 0x40-words (0x100-bytes). This allows overwriting threadlocalstorage+0x180 in the destination thread. However, since the data written there would be translate parameters (such as header-words + buffer addresses), exploiting this would likely be very difficult, if possible at all.<br />
<br />
If the two words at threadlocalstorage+0x180 could be overwritten with controlled data this way, one could then use a command with a buffer-header of <nowiki>((size<<14) | 2)</nowiki> to write arbitrary memory to any RW userland memory in the destination process.<br />
| <br />
| [[5.0.0-11]]<br />
| <br />
| v4.1 FIRM -> v5.0 code diff<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[SVC|SVC stack allocation overflows]]<br />
| <br />
* Syscalls that allocate a variable-length array on stack, only checked bit31 before multiplying by 4/16 (when calculating how much memory to allocate). If a large integer was passed as input to one of these syscalls, an integer overflow would occur, and too little memory would have been allocated on stack resulting in a buffer overrun. <br />
* The alignment (size+7)&~7 calculation before allocation was not checked for integer overflow.<br />
<br />
This might allow for ARM11 kernel code-execution.<br />
<br />
(Applies to svcSetResourceLimitValues, svcGetThreadList, svcGetProcessList, svcReplyAndReceive, svcWaitSynchronizationN.)<br />
| <br />
| [[5.0.0-11]]<br />
| <br />
| v4.1 FIRM -> v5.0 code diff<br />
| [[User:Plutooo|plutoo]], [[User:Yellows8|Yellows8]] complementary<br />
|-<br />
| [[SVC|svcControlMemory]] MemoryOperation MAP memory-permissions<br />
| svcControlMemory with MemoryOperation=MAP allows mapping the already-mapped process virtual-mem at addr1, to addr0. The lowest address permitted for addr1 is 0x00100000. Originally the ARM11 kernel didn't check memory permissions for addr1. Therefore .text as addr1 could be mapped elsewhere as RW- memory, which allowed ARM11 userland code-execution.<br />
| <br />
| [[4.1.0-8]]<br />
| <br />
| 2012<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[RPC_Command_Structure|Command]] input/output buffer permissions<br />
| Originally the ARM11 kernel didn't check memory permissions for the input/output buffers for commands. Starting with [[4.0.0-7]] the ARM11 kernel will trigger a kernelpanic() if the input/output buffers don't have the required memory permissions. For example, this allowed a FSUSER file-read to .text, which therefore allowed ARM11-userland code execution.<br />
| <br />
| [[4.0.0-7]]<br />
| <br />
| 2012<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[SVC|svcReadProcessMemory/svcWriteProcessMemory memory]] permissions<br />
| Originally the kernel only checked the first page(0x1000-bytes) of the src/dst buffers, for svcReadProcessMemory and svcWriteProcessMemory. There is no known retail processes which have access to these SVCs.<br />
| <br />
| [[4.0.0-7]]<br />
| <br />
| 2012?<br />
| [[User:Yellows8|Yellows8]]<br />
|}<br />
<br />
=== [[FIRM]] Sysmodules ===<br />
{| class="wikitable" border="1"<br />
|-<br />
! Summary<br />
! Description<br />
! Successful exploitation result<br />
! Fixed in [[FIRM]] system version<br />
! Last [[FIRM]] system version this flaw was checked for<br />
! Timeframe this was discovered<br />
! Discovered by<br />
|-<br />
| [[Services|"srv:pm"]] process registration<br />
| Originally any process had access to the port "srv:pm". The PID's used for the (un)registration commands are not checked either. This allowed any process to re-register itself with "srv:pm", and therefore allowed the process to give itself access to any service, bypassing the exheader service-access-control list.<br />
<br />
This was fixed in [[7.0.0-13]]: starting with [[7.0.0-13]] "srv:pm" is now a service instead of a globally accessible port. Only processes with PID's less than 6 (in other words: fs, ldr, sm, pm, pxi modules) have access to it. With [[7.0.0-13]] there can only be one session for "srv:pm" open at a time(this is used by pm module), svcBreak will be executed if more sessions are opened by the processes which can access this.<br />
<br />
This flaw was needed for exploiting the <=v4.x Process9 PXI vulnerabilities from ARM11 userland ROP, since most applications don't have access to those service(s).<br />
| Access to arbitrary services<br />
| [[7.0.0-13]]<br />
| <br />
| 2012<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| FSDIR null-deref<br />
| [[Filesystem_services|FS]]-module may crash in some cases when handling directory reading. The trigger seems to be due to using [[FSDir:Close]] without closing the dir-handle afterwards?(Perhaps this is caused by out-of-memory?) This seems to be useless since it's just a null-deref.<br />
| <br />
| None<br />
| [[9.6.0-24|9.6.0-X]]<br />
| May 19(?)-20, 2015<br />
| [[User:Yellows8|Yellows8]]<br />
|}<br />
<br />
=== Standalone Sysmodules ===<br />
{| class="wikitable" border="1"<br />
|-<br />
! Summary<br />
! Description<br />
! Successful exploitation result<br />
! Fixed in system-module system-version<br />
! Last system-module system-version this flaw was checked for<br />
! Timeframe this was discovered<br />
! Timeframe this was added to wiki<br />
! Discovered by<br />
|-<br />
| AM stack/.bss infoleak via [[AM:ReadTwlBackupInfo]]([[AM:ReadTwlBackupInfoEx|Ex]])<br />
| After writing the output-info structure to stack, it then copies that structure to the output buffer ptr using the size from the command. The size is not checked. This could be used to read data from the AM-service-thread stack handling the command + .bss.<br />
<br />
'''This was not tested on hardware.'''<br />
| Stack/.bss reading<br />
| None<br />
| [[10.0.0-27]](AM v9217)<br />
| Roughly October 17, 2016<br />
| October 25, 2016<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[MVD_Services|MVD]]: Stack buffer overflow with [[MVDSTD:SetupOutputBuffers]].<br />
| The input total_entries is not validated when initially processing the input entry-list. This fixed-size input entry-list is copied to stack from the command request. The loop for processing this initializes a global table, the converted linearmem->physaddrs used there are also copied to stack(0x8-bytes of physaddrs per entry).<br />
<br />
If total_entries is too large, MVD-sysmodule will crash due to reading unmapped memory following the stack(0x10000000). Afterwards if the out-of-bounds total_entries is smaller than that, it will crash due accessing address 0x0, hence this useless.<br />
| MVD-sysmodule crash.<br />
| None<br />
| [[9.0.0-20]]<br />
| April 22, 2016 (Tested on the 25th)<br />
| April 25, 2016<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[NWM_Services|NWM]]: Using CTRSDK heap with UDS sharedmem from the user-process.<br />
| See the HTTP-sysmodule section below.<br />
<br />
CTRSDK heap is used with the sharedmem from [[NWMUDS:InitializeWithVersion]]. Buffers are allocated/freed under this heap using [[NWMUDS:Bind]] and [[NWMUDS:Unbind]].<br />
<br />
Hence, overwriting sharedmem with gspwn then using [[NWMUDS:Unbind]] results in the usual controlled CTRSDK memchunk-header write, similar to HTTP-sysmodule.<br />
<br />
This could be done by creating an UDS network, without any other nodes on the network.<br />
<br />
Besides CTRSDK memchunk-headers, there are no addresses stored under this sharedmem.<br />
| ROP under NWM-module.<br />
| None<br />
| [[9.0.0-20|9.0.0-X]]<br />
| April 10, 2016<br />
| April 16, 2016<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[DLP_Services|DLP]]: Out-of-bounds memory access during spectator [[Download_Play|data-frame]] checksum calculation<br />
| DLP doesn't validate the frame_size when receiving spectator data-frames at all, unlike non-spectator data-frames. The actual spectator data-frame parsing code doesn't use that field either. However, the data-frame checksum calculation code called during checksum verification does use the frame_size for loading the size of the framebuf.<br />
<br />
Hence, using a large frame_size like 0xFFFF will result in the checksum calculation code reading data out-of-bounds. This isn't really useful, you could trigger a remote local-WLAN DLP-sysmodule crash while a 3DS system is scanning for DLP networks(due to accessing unmapped memory), but that's about all(trying to infoleak with this likely isn't useful either).<br />
| DLP-sysmodule crash, handled by dlplay system-application by a "connection interrupted" error eventually then a fatal-error via ErrDisp.<br />
| None<br />
| [[10.0.0-27|10.0.0-X]]<br />
| April 8, 2016 (Tested on the 10th)<br />
| April 10, 2016<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[DLP_Services|DLP]]: Out-of-bounds output data writing during spectator sysupdate titlelist [[Download_Play|data-frame]] handling<br />
| The total_entries and out_entryindex fields for the titlelist DLP spectator data-frames are not validated. This is parsed during DLP network scanning. Hence, the specified titlelist data can be written out-of-bounds using the specified out_entryindex and total_entries. A crash will occur while reading the input data-frame titlelist if total_entries is larger than 0x27A, due to accessing unmapped memory.<br />
<br />
There's not much non-zero data to overwrite following the output buffer(located in sharedmem), any ptrs are located in sharedmem. Overwriting certain ptr(s) are only known to cause a crash when attempting to use the DLP-client shutdown service-command.<br />
<br />
There's no known way to exploit the above crash, since the linked-list code involves writes zeros(with a controlled start ptr).<br />
| <br />
| None<br />
| [[10.0.0-27|10.0.0-X]]<br />
| April 8-9, 2016<br />
| April 10, 2016<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[IR_Services|IR]]: Stack buffer overflow with custom hardware<br />
| Originally IR sysmodule used the read value from the I2C-IR registers TXLVL and RXLVL without validating them at all. See [[10.6.0-31|here]] for the fix. This is the size used for reading the data-recv FIFO, etc. The output buffer for reading is located on the stack.<br />
<br />
This should be exploitable if one could successfully setup the custom hardware for this and if the entire intended sizes actually get read from I2C.<br />
| ROP under IR sysmodule.<br />
| [[10.6.0-31|10.6.0-31]]<br />
| <br />
| February 23, 2016 (Unknown if it was noticed before then)<br />
| February 23, 2016<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[HTTP_Services|HTTP]]: Using CTRSDK heap with sharedmem from the user-process.<br />
| The data from httpcAddPostDataAscii and other commands is stored under a CTRSDK heap. That heap is the sharedmem specified by the user-process via the HTTPC Initialize command.<br />
Normally this sharedmem isn't accessible to the user-process once the sysmodule maps it, hence using it is supposed to be "safe".<br />
<br />
This isn't the case due to gspwn however. Since CTRSDK heap code is so insecure in general, one can use gspwn to locate the HTTPC sharedmem + read/write it, then trigger a mem-write under the sysmodule. This can then be used to get ROP going under HTTP-sysmodule.<br />
<br />
This is exploited by [https://github.com/yellows8/ctr-httpwn/ctr-httpwn ctr-httpwn].<br />
| ROP under HTTP sysmdule.<br />
| None<br />
| [[9.6.0-24|9.6.0-X]] (Latest sysmodule version as of [[10.7.0-32|10.7.0-32]])<br />
| Late 2015<br />
| March 22, 2016<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[NIM_Services|NIM]]: Downloading old title-versions from eShop<br />
| Multiple NIM service commands(such as [[NIMS:StartDownload]]) use a title-version value specified by the user-process, NIM does not validate that this input version matches the latest version available via SOAP. Therefore, when combined with AM(PXI) [[#Process9|title-downgrading]] via deleting the target eShop title with System Settings Data Management(if the title was already installed), this allows downloading+installing any title-version from eShop ''if'' it's still available from CDN.<br />
The easiest way to exploit this is to just patch the eShop system-application code using these NIM commands(ideally the code which loads the title-version).<br />
<br />
Originally this was tested with a debugging-system via modded-FIRM, eventually smea implemented it in HANS for the 32c3 release.<br />
| Downloading old title-versions from eShop<br />
| None<br />
| [[10.0.0-27|10.0.0-X]]<br />
| October 24, 2015 (Unknown when exactly the first eShop title downgrade was actually tested, maybe November)<br />
| January 7, 2016 (Same day Ironfall v1.0 was removed from CDN via the main-CXI files)<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[SPI_Services|SPI]] service out-of-bounds write<br />
| cmd1 has out-of-bounds write allowing overwrite of some static variables in .data.<br />
| <br />
| None<br />
| [[9.5.0-22]]<br />
| March 2015<br />
| <br />
| [[User:Plutooo|plutoo]]<br />
|-<br />
| [[NFC_Services|NFC]] module service command buf-overflows<br />
| NFC module copies data with certain commands, from command input buffers to stack without checking the size. These commands include the following, it's unknown if there's more commands with similar issues: "nfc:dev" <0x000C....> and "nfc:s" <0x0037....>.<br />
Since both of these commands are stubbed in the Old3DS NFC module from the very first version(those just return an error), these issues only affect the New3DS NFC module.<br />
<br />
There's no known retail titles which have access to either of these services.<br />
| ROP under NFC module.<br />
| New3DS: None<br />
| New3DS: [[9.5.0-22]]<br />
| December 2014?<br />
| <br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[News_Services|NEWSS]] service command notificationID validation failure<br />
| This module does not validate the input notificationID for <nowiki>"news:s"</nowiki> service commands. This is an out-of-bounds array index bug. For example, [[NEWSS:SetNotificationHeader]] could be used to exploit news module: this copies the input data(size is properly checked) to: out = newsdb_savedata+0x10 + (someu32array[notificationID]*0x70).<br />
| ROP under news module.<br />
| None<br />
| [[9.7.0-25|9.7.0-X]]<br />
| December 2014<br />
| <br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[NWMUDS:DecryptBeaconData]] heap buffer overflow<br />
| input_size = 0x1E * <value the u8 from input_[[NWM_Services|networkstruct]]+0x1D>. Then input_tag0 is copied to a heap buffer. When input_size is larger than 0xFA-bytes, it will then copy input_tag1 to <end_address_of_previous_outbuf>, with size=input_size-0xFA.<br />
<br />
This can be triggered by either using this command directly, or by boadcasting a wifi beacon which triggers it while a 3DS system running the target process is in range, when the process is scanning for hosts to connect to. Processes will only pass tag data to this command when the wlancommID and other thing(s) match the values for the process.<br />
<br />
There's no known way to actually exploit this for getting ROP under NWM-module, at the time of originally adding this to the wiki. This is because the data which gets copied out-of-bounds *and* actually causes crash(es), can't be controlled it seems(with just broadcasting a beacon at least). It's unknown whether this could be exploited from just using NWMUDS service-cmd(s) directly.<br />
| Without any actual way to exploit this: NWM-module DoS, resulting in process termination(process crash). This breaks *everything* involving wifi comms, a reboot is required to recover from this.<br />
| None<br />
| [[9.0.0-20]]<br />
| ~September 23, 2014(see the [[NWMUDS:DecryptBeaconData]] page history)<br />
| August 3, 2015<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[HID_Services|HID]] module shared-mem<br />
| HID module does not validate the index values in [[HID_Shared_Memory|sharedmem]](just changes index to 0 when index == maxval when updating), therefore large values will result in HID module writing HID data to arbitrary addresses.<br />
| ROP under HID module, but this is *very* unlikely to be exploitable since the data written is HID data.<br />
| None<br />
| [[9.3.0-21]]<br />
| 2014?<br />
| <br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| gspwn<br />
| GSP module does not validate addresses given to the GPU. This allows a user-mode application/applet to read/write to a large part of physical FCRAM using GPU DMA. From this, you can overwrite the .text segment of the application you're running under, and gain real code-execution from a ROP-chain. Normally applets' .text([[Home Menu]], [[Internet Browser]], etc) is located beyond the area accessible by the GPU, except for [[RO_Services|CROs]] used by applets([[Internet Browser]] for example).<br />
<br />
FCRAM is gpu-accessible up to physaddr 0x26800000 on Old3DS, and 0x2DC00000 on New3DS. This is BASE_memregion_start(aka SYSTEM_memregion_end)-0x400000 with the default memory-layout on Old3DS/New3DS.<br />
| User-mode code execution.<br />
| None<br />
| [[9.6.0-24|9.6.0-X]]<br />
| Early 2014<br />
| <br />
| smea, [[User:Yellows8|Yellows8]]/others before then<br />
|-<br />
| rohax<br />
| Using gspwn, it is possible to overwrite a loaded [[CRO0]]/[[CRR0]] after its RSA-signature has been validated. Badly validated [[CRO0]] header leads to arbitrary read/write of memory in the ro-process. This gives code-execution in the ro module, who has access to [[SVC|syscalls]] 0x70-0x72, 0x7D.<br />
<br />
This was fixed after [[ninjhax]] release by adding checks on [[CRO0]]-based pointers before writing to them.<br />
| Memory-mapping syscalls.<br />
| [[9.3.0-21]]<br />
| [[9.4.0-21]]<br />
| <br />
| <br />
| smea, [[User:Plutooo|plutoo]] joint effort<br />
|-<br />
| Region free<br />
| Only [[Home Menu]] itself checks gamecards' region when launching them. Therefore, any application launch that is done directly with [[NS]] without signaling Home Menu to launch the app, will result in region checks being bypassed.<br />
This essentially means launching the gamecard with the [[NS_and_APT_Services|"ns:s"]] service. The main way to exploit this is to trigger a FIRM launch with an application specified, either with a normal FIRM launch or a hardware [[NSS:RebootSystem|reboot]].<br />
| Launching gamecards from any region + bypassing Home Menu gamecard-sysupdate installation<br />
| None<br />
| Last tested with [[10.1.0-27|10.1.0-X]].<br />
| June(?) 2014<br />
| <br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[NWM_Services|NWM]] service-cmd state null-ptr deref<br />
| The NWMUDS service command code loads a ptr from .data, adds an offset to that, then passes that as the state address for the actual command-handler function. The value of the ptr loaded from .data is not checked, therefore this will cause crashes due to that being 0x0 when NWMUDS was not properly initialized.<br />
It's unknown whether any NWM services besides NWMUDS have this issue.<br />
| This is rather useless since it's only a crash caused by a state ptr based at 0x0.<br />
| None<br />
| [[9.0.0-20]]<br />
| 2013?<br />
| <br />
| [[User:Yellows8|Yellows8]]<br />
|}<br />
<br />
=== General/CTRSDK ===<br />
{| class="wikitable" border="1"<br />
|-<br />
! Summary<br />
! Description<br />
! Successful exploitation result<br />
! Fixed in version<br />
! Last version this flaw was checked for<br />
! Timeframe this was discovered<br />
! Discovered by<br />
|-<br />
| [[NWM_Services|UDS]] beacon additional-data buffer overflow<br />
| Originally CTRSDK did not validate the UDS additional-data size before using that size to copy the additional-data to a [[NWM_Services|networkstruct]]. This was eventually fixed.<br />
This was discovered while doing code RE with an old dlp-module version. It's unknown in what specific CTRSDK version this was fixed, or even what system-version updated titles with a fixed version.<br />
<br />
It's unknown if there's any titles using a vulnerable CTRSDK version which are also exploitable with this(dlp module can't be exploited with this).<br />
<br />
The maximum number of bytes that can be written beyond the end of the outbuf is 0x37-bytes, with additionaldata_size=0xFF.<br />
| Perhaps ROP, very difficult if possible with anything at all<br />
| ?<br />
| <br />
| September(?) 2014<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| CTPK buffer overflow<br />
| At offset 0x20 in CTPK is an array for each texture, each entry is 0x20-bytes. This contains a wordindex(entry+0x18) for some srcdata relative to CTPK+0, and an u8 wordsize(entry+0x14) for this data. The CTRSDK function handling this doesn't validate the size, when copying srcdata using this size to the output buffer. Applications usually have the output buffer on the stack, hence stack buffer overflow.<br />
<br />
While CTPK(*.ctpk) are normally only loaded from RomFS, some application(s) load from elsewhere too.<br />
| ROP under the target application.<br />
| None?<br />
| "[SDK+NINTENDO:CTR_SDK-11_4_0_200_none]"<br />
| November 14, 2016<br />
| [[User:Yellows8|Yellows8]]<br />
|}</div>Mrrraouhttps://www.3dbrew.org/w/index.php?title=Setting_up_Development_Environment&diff=18887Setting up Development Environment2016-12-13T17:10:15Z<p>Mrrraou: Fixing ninja edit.</p>
<hr />
<div>= Setup =<br />
* Install [http://devkitpro.org/ devkitARM]. If it's already installed, update it.<br />
** On Windows, there's a [http://sourceforge.net/projects/devkitpro/files/Automated%20Installer/ graphical installer].<br />
** On Unix-like platforms such as Linux/macOS, there's a [http://sourceforge.net/projects/devkitpro/files/Automated%20Installer/devkitARMupdate.pl/download Perl script]. Make sure you also select libctru and the 3ds examples when installing.<br />
* Depending on the kind of homebrew you want to develop, you may be interested in installing and using additional libraries and tools which don't ship alongside devkitARM/libctru. A list of them can be found in [[Homebrew Libraries and Tools]].<br />
<br />
==Windows==<br />
devkitPro provides Win32-native precompiled versions of devkitARM which can be run directly on Windows.<br />
* [http://sourceforge.net/projects/devkitpro/files/Automated%20Installer/ download the latest version of the graphical installer] from SourceForge and run it, following the instructions as you go.<br />
* An Internet connection is required.<br />
* You will want to make sure devkitARM is selected during the installation process to develop for the 3DS (and also the DS and GBA) - you can also install devkitPPC (for GameCube/Wii development) and devkitPSP (for PlayStation Portable development) if you wish.<br />
* Once the installer has finished, launch MSYS from:<br />
** Windows 7 and earlier: Start -> All Programs -> devkitPro -> MSYS<br />
** Windows 8 and 8.1: Right click on the Start screen and select 'All Apps'. You should find MSYS there.<br />
** Windows 10 (pre-Anniversary Update): Start -> All Apps -> devkitPro -> MSYS<br />
** Windows 10 (post-Anniversary Update): Start -> devkitPro -> MSYS<br />
<br />
Alternatively starting with Windows 10 Anniversary Update (Version 1607), the [https://msdn.microsoft.com/en-us/commandline/wsl/install_guide Windows Subsystem for Linux (WSL)] may also be used to run the Linux version of devkitARM. Unless you have some particular need for WSL it's recommended that you stick to a more standard environment. <br />
<br />
==Unix-like platforms==<br />
Currently devkitPro provides precompiled versions of devkitARM for the following Unix-like platforms: Linux (x86/x64), macOS (universal binary). Note that Linux x64 binaries are usable under WSL.<br />
<br />
* First, you need to install curl so the installer can download the devkitARM packages, and you should also install Git - you'll need it to update libctru or share your code on GitHub, among many other things.<br />
<br />
* Find your way into a shell (eg. by opening a Terminal window), and follow the instructions for your OS:<br />
** Debian/Ubuntu/Linux Mint/WSL: <code>sudo apt-get install git curl</code><br />
** Fedora/CentOS/RHEL: <code>sudo yum install git curl</code><br />
** openSUSE: <code>sudo zypper install git curl</code><br />
** macOS: Download Git from [http://git-scm.com/download/mac] and install it. Curl is included with the OS.<br />
<br />
* Next, we need to download, make executable and run the devkitARM updater (don't worry, the updater is also the installer.)<br />
<pre><br />
curl -L https://raw.githubusercontent.com/devkitPro/installer/master/perl/devkitARMupdate.pl -o devkitARMupdate.pl<br />
chmod +x ./devkitARMupdate.pl<br />
sudo ./devkitARMupdate.pl /opt/devkitpro<br />
</pre><br />
<br />
* Finally, we need to tell your shell where to find the devkitARM binaries.<br />
<pre><br />
echo "export DEVKITPRO=/opt/devkitpro" >> ~/.bashrc<br />
echo "export DEVKITARM=/opt/devkitpro/devkitARM" >> ~/.bashrc<br />
echo "export PATH=$PATH:/opt/devkitpro/devkitARM/bin" >> ~/.bashrc<br />
source ~/.bashrc<br />
</pre><br />
<br />
= Building the examples =<br />
3DS examples are still being created; however, there are a growing number of examples available from the [https://github.com/devkitPro/3ds-examples devkitPro/3ds-examples GitHub repository].<br />
There are now too many to list here in detail, so go ahead and browse them.<br />
<br />
* To download these, if you installed Git (as you will have if you followed the above instructions), simply type <code>git clone https://github.com/devkitPro/3ds-examples.git</code> into your shell in the directory you wish to store the 3ds-examples folder in.<br />
<br />
These can be built from the command line.<br />
<br />
To start a new homebrew project from the <code>bash</code> shell, simply type the following (replacing <code>'''~/projects/my3dsproject'''</code> with the place you would like your project to be stored, with <code>~</code> meaning your HOME directory):<br />
cp -r $DEVKITPRO/examples/3ds/templates/application '''~/projects/my3dsproject'''<br />
cd '''~/projects/my3dsproject'''<br />
<br />
The standard Makefile will use the folder as the name of the 3dsx that will be built. You can keep that behaviour or simply change the <code>TARGET := $(notdir $(CURDIR))</code> line in the Makefile to explicitly name your project.<br />
<br />
To compile it, type <code>make</code> in the project directory.<br />
To run it on your 3DS, start the Homebrew Launcher, press Y to open the network loader, then on your PC type: <code>$DEVKITARM/bin/3dslink '''my3dsproject'''.3dsx</code>, replacing '''my3dsproject''' with the name of the 3dsx file you want to run.)<br />
</code>.<br />
<br />
If all goes well, you'll soon see your application running on your 3DS.<br />
<br />
==Building the examples on Linux with Netbeans==<br />
* Go to File->New Project...<br />
* Select C/C++ Project with existing code<br />
* Navigate to the examples directory and select the folder for the project you want to build; eg. /home/vtsingaras/3ds/examples/app_launch<br />
* Leave Configuration Mode to 'Automatic' and click 'Finish'.<br />
* It will fail to build. Now edit Makefile and insert these two lines, adjusting for your devkitpro path, at the top:<br />
<pre>export DEVKITPRO=/opt/devkitpro<br />
export DEVKITARM=/opt/devkitpro/devkitARM</pre><br />
* Right-click the project and go to Properties->Code Assistance and click C Compiler.<br />
* In include directories enter <br />
<pre>/opt/devkitpro/devkitARM/include;/opt/devkitpro/libctru/include</pre><br />
adjusting again for your devkitPro path.<br />
* Do the same for 'C++ Compiler'.<br />
* Go to 'Run' and click 'Clean and Build Project'.<br />
* Now right-click on the project and select Code Assistance->Reparse Project.<br />
<br />
Now you can use Netbeans' code completion feature and build your project from the Run menu.<br />
<br />
= Building homebrew for distribution =<br />
To build your homebrew, open a Bash shell as described above, browse to the folder of the homebrew you wish to compile, and run <code>make</code>.<br />
<br />
* This will build a .elf file and a .3dsx file (the homebrew executable itself).<br />
** The Homebrew Launcher can only run homebrew in the 3DSX format.<br />
<br />
* To build a CCI (.3ds) file, you need to strip the .elf file and use makerom on it (with the provided RSF file):<br />
arm-none-eabi-strip '''[ELF file]'''<br />
makerom -f cci -o '''[.3ds file]''' -rsf '''[RSF file]''' -target t -exefslogo -elf '''[ELF file]''' -icon '''[icon file]''' -banner '''[banner file]'''<br />
<br />
= Troubleshooting =<br />
'''I get the "Please set DEVKITARM in your environment." error.'''<br />
<br />
Use the following command before installing [http://askubuntu.com/questions/573070/problem-setting-up-environment-for-make-command-execution]:<br />
sudo chown $USER /opt/devkitpro/ -R<br />
echo "export DEVKITPRO="/opt/devkitpro/" >> ~/.profile<br />
echo "export DEVKITARM="/opt/devkitpro/devkitARM/" >> ~/.profile<br />
source ~/.profile<br />
<br />
For WSL users, you need to close the Bash shell, then reopen it for WSL to reload all of the variables from a clean state.</div>Mrrraouhttps://www.3dbrew.org/w/index.php?title=Setting_up_Development_Environment&diff=18886Setting up Development Environment2016-12-13T17:09:12Z<p>Mrrraou: Stop trying to cause edit wars. Thanks. There is a reason for this to be here, even if you do not like it.</p>
<hr />
<div>= Setup =<br />
* Install [http://devkitpro.org/ devkitARM]. If it's already installed, update it.<br />
** On Windows, there's a [http://sourceforge.net/projects/devkitpro/files/Automated%20Installer/ graphical installer].<br />
** On Unix-like platforms such as Linux/macOS, there's a [http://sourceforge.net/projects/devkitpro/files/Automated%20Installer/devkitARMupdate.pl/download Perl script]. Make sure you also select libctru and the 3ds examples when installing.<br />
* Depending on the kind of homebrew you want to develop, you may be interested in installing and using additional libraries and tools which don't ship alongside devkitARM/libctru. A list of them can be found in [[Homebrew Libraries and Tools]].<br />
<br />
==Windows==<br />
devkitPro provides Win32-native precompiled versions of devkitARM which can be run directly on Windows.<br />
* [http://sourceforge.net/projects/devkitpro/files/Automated%20Installer/ download the latest version of the graphical installer] from SourceForge and run it, following the instructions as you go.<br />
* An Internet connection is required.<br />
* You will want to make sure devkitARM is selected during the installation process to develop for the 3DS (and also the DS and GBA) - you can also install devkitPPC (for GameCube/Wii development) and devkitPSP (for PlayStation Portable development) if you wish.<br />
* Once the installer has finished, launch MSYS from:<br />
** Windows 7 and earlier: Start -> All Programs -> devkitPro -> MSYS<br />
** Windows 8 and 8.1: Right click on the Start screen and select 'All Apps'. You should find MSYS there.<br />
** Windows 10 (pre-Anniversary Update): Start -> All Apps -> devkitPro -> MSYS<br />
** Windows 10 (post-Anniversary Update): Start -> devkitPro -> MSYS<br />
<br />
Alternatively starting with Windows 10 Anniversary Update (Version 1607), the [https://msdn.microsoft.com/en-us/commandline/wsl/install_guide Windows Subsystem for Linux (WSL)] may also be used to run the Linux version of devkitARM. Unless you have some particular need for WSL it's recommended that you stick to a more standard environment. <br />
<br />
==Unix-like platforms==<br />
Currently devkitPro provides precompiled versions of devkitARM for the following Unix-like platforms: Linux (x86/x64), macOS (universal binary). Note that Linux x64 binaries are usable under WSL.<br />
<br />
* First, you need to install curl so the installer can download the devkitARM packages, and you should also install Git - you'll need it to update libctru or share your code on GitHub, among many other things.<br />
<br />
* Find your way into a shell (eg. by opening a Terminal window), and follow the instructions for your OS:<br />
** Debian/Ubuntu/Linux Mint/WSL: <code>sudo apt-get install git curl</code><br />
** Fedora/CentOS/RHEL: <code>sudo yum install git curl</code><br />
** openSUSE: <code>sudo zypper install git curl</code><br />
** macOS: Download Git from [http://git-scm.com/download/mac] and install it. Curl is included with the OS.<br />
<br />
* Next, we need to download, make executable and run the devkitARM updater (don't worry, the updater is also the installer.)<br />
<pre><br />
curl -L https://raw.githubusercontent.com/devkitPro/installer/master/perl/devkitARMupdate.pl -o devkitARMupdate.pl<br />
chmod +x ./devkitARMupdate.pl<br />
sudo ./devkitARMupdate.pl /opt/devkitpro<br />
</pre><br />
<br />
* Finally, we need to tell your shell where to find the devkitARM binaries.<br />
<pre><br />
echo "export DEVKITPRO=/opt/devkitpro" >> ~/.bashrc<br />
echo "export DEVKITARM=/opt/devkitpro/devkitARM" >> ~/.bashrc<br />
echo "export PATH=$PATH:/opt/devkitpro/devkitARM/bin" >> ~/.bashrc<br />
source ~/.bashrc<br />
</pre><br />
<br />
= Building the examples =<br />
3DS examples are still being created; however, there are a growing number of examples available from the [https://github.com/devkitPro/3ds-examples devkitPro/3ds-examples GitHub repository].<br />
There are now too many to list here in detail, so go ahead and browse them.<br />
<br />
* To download these, if you installed Git (as you will have if you followed the above instructions), simply type <code>git clone https://github.com/devkitPro/3ds-examples.git</code> into your shell in the directory you wish to store the 3ds-examples folder in.<br />
<br />
These can be built from the command line.<br />
<br />
To start a new homebrew project from the <code>bash</code> shell, simply type the following (replacing <code>'''~/projects/my3dsproject'''</code> with the place you would like your project to be stored, with <code>~</code> meaning your HOME directory):<br />
cp -r $DEVKITPRO/examples/3ds/templates/application '''~/projects/my3dsproject'''<br />
cd '''~/projects/my3dsproject'''<br />
<br />
The standard Makefile will use the folder as the name of the 3dsx that will be built. You can keep that behaviour or simply change the <code>TARGET := $(notdir $(CURDIR))</code> line in the Makefile to explicitly name your project.<br />
<br />
To compile it, type <code>make</code> in the project directory.<br />
To run it on your 3DS, start the Homebrew Launcher, press Y to open the network loader, then on your PC type: <code>$DEVKITARM/bin/3dslink '''my3dsproject'''.3dsx</code>, replacing '''my3dsproject''' with the name of the 3dsx file you want to run.)<br />
</code>.<br />
<br />
If all goes well, you'll soon see your application running on your 3DS.<br />
<br />
==Building the examples on Linux with Netbeans==<br />
* Go to File->New Project...<br />
* Select C/C++ Project with existing code<br />
* Navigate to the examples directory and select the folder for the project you want to build; eg. /home/vtsingaras/3ds/examples/app_launch<br />
* Leave Configuration Mode to 'Automatic' and click 'Finish'.<br />
* It will fail to build. Now edit Makefile and insert these two lines, adjusting for your devkitpro path, at the top:<br />
<pre>export DEVKITPRO=/opt/devkitpro<br />
export DEVKITARM=/opt/devkitpro/devkitARM</pre><br />
* Right-click the project and go to Properties->Code Assistance and click C Compiler.<br />
* In include directories enter <br />
<pre>/opt/devkitpro/devkitARM/include;/opt/devkitpro/libctru/include</pre><br />
adjusting again for your devkitPro path.<br />
* Do the same for 'C++ Compiler'.<br />
* Go to 'Run' and click 'Clean and Build Project'.<br />
* Now right-click on the project and select Code Assistance->Reparse Project.<br />
<br />
Now you can use Netbeans' code completion feature and build your project from the Run menu.<br />
<br />
= Building homebrew for distribution =<br />
To build your homebrew, open a Bash shell as described above, browse to the folder of the homebrew you wish to compile, and run <code>make</code>.<br />
<br />
* This will build a .elf file and a .3dsx file (the homebrew executable itself) together with a .smdh file (the icon).<br />
** The Homebrew Launcher can only run homebrew in the 3DSX format, and can only display SMDH icons.<br />
<br />
* To build a CCI (.3ds) file, you need to strip the .elf file and use makerom on it (with the provided RSF file):<br />
arm-none-eabi-strip '''[ELF file]'''<br />
makerom -f cci -o '''[.3ds file]''' -rsf '''[RSF file]''' -target t -exefslogo -elf '''[ELF file]''' -icon '''[icon file]''' -banner '''[banner file]'''<br />
<br />
= Troubleshooting =<br />
'''I get the "Please set DEVKITARM in your environment." error.'''<br />
<br />
Use the following command before installing [http://askubuntu.com/questions/573070/problem-setting-up-environment-for-make-command-execution]:<br />
sudo chown $USER /opt/devkitpro/ -R<br />
echo "export DEVKITPRO="/opt/devkitpro/" >> ~/.profile<br />
echo "export DEVKITARM="/opt/devkitpro/devkitARM/" >> ~/.profile<br />
source ~/.profile<br />
<br />
For WSL users, you need to close the Bash shell, then reopen it for WSL to reload all of the variables from a clean state.</div>Mrrraouhttps://www.3dbrew.org/w/index.php?title=Setting_up_Development_Environment&diff=18883Setting up Development Environment2016-12-13T15:25:35Z<p>Mrrraou: Readding useful help that was removed for no real reason. Undo revision 18882 by WinterMute (talk)</p>
<hr />
<div>= Setup =<br />
* Install [http://devkitpro.org/ devkitARM]. If it's already installed, update it.<br />
** On Windows, there's a [http://sourceforge.net/projects/devkitpro/files/Automated%20Installer/ graphical installer].<br />
** On Unix-like platforms such as Linux/macOS, there's a [http://sourceforge.net/projects/devkitpro/files/Automated%20Installer/devkitARMupdate.pl/download Perl script]. Make sure you also select libctru and the 3ds examples when installing.<br />
* Depending on the kind of homebrew you want to develop, you may be interested in installing and using additional libraries and tools which don't ship alongside devkitARM/libctru. A list of them can be found in [[Homebrew Libraries and Tools]].<br />
<br />
==Windows==<br />
devkitPro provides Win32-native precompiled versions of devkitARM which can be run directly on Windows.<br />
* [http://sourceforge.net/projects/devkitpro/files/Automated%20Installer/ download the latest version of the graphical installer] from SourceForge and run it, following the instructions as you go.<br />
* An Internet connection is required.<br />
* You will want to make sure devkitARM is selected during the installation process to develop for the 3DS (and also the DS and GBA) - you can also install devkitPPC (for GameCube/Wii development) and devkitPSP (for PlayStation Portable development) if you wish.<br />
* Once the installer has finished, launch MSYS from:<br />
** Windows 7 and earlier: Start -> All Programs -> devkitPro -> MSYS<br />
** Windows 8 and 8.1: Right click on the Start screen and select 'All Apps'. You should find MSYS there.<br />
** Windows 10 (pre-Anniversary Update): Start -> All Apps -> devkitPro -> MSYS<br />
** Windows 10 (post-Anniversary Update): Start -> devkitPro -> MSYS<br />
<br />
Alternatively starting with Windows 10 Anniversary Update (Version 1607), the [https://msdn.microsoft.com/en-us/commandline/wsl/install_guide Windows Subsystem for Linux (WSL)] may also be used to run the Linux version of devkitARM. Due to the fact that GCC was originally designed for Unix-like platforms its use may yield performance and convenience improvements. For instructions on how to set up devkitARM under WSL refer to the ''Unix-like platforms'' section. For WSL installation instructions, see the linked MSDN page.<br />
<br />
==Unix-like platforms==<br />
Currently devkitPro provides precompiled versions of devkitARM for the following Unix-like platforms: Linux (x86/x64), macOS (universal binary). Note that Linux x64 binaries are usable under WSL.<br />
<br />
* First, you need to install curl so the installer can download the devkitARM packages, and you should also install Git - you'll need it to update ctrulib or share your code on GitHub, among many other things.<br />
<br />
* Find your way into a shell (eg. by opening a Terminal window), and follow the instructions for your OS:<br />
** Debian/Ubuntu/Linux Mint/WSL: <code>sudo apt-get install git curl</code><br />
** Fedora/CentOS/RHEL: <code>sudo yum install git curl</code><br />
** openSUSE: <code>sudo zypper install git curl</code><br />
** macOS: Download Git from [http://git-scm.com/download/mac] and install it. Curl is included with the OS.<br />
<br />
* Next, we need to download, make executable and run the devkitARM updater (don't worry, the updater is also the installer.)<br />
<pre><br />
curl -L https://raw.githubusercontent.com/devkitPro/installer/master/perl/devkitARMupdate.pl -o devkitARMupdate.pl<br />
chmod +x ./devkitARMupdate.pl<br />
sudo ./devkitARMupdate.pl /opt/devkitpro<br />
</pre><br />
<br />
* Finally, we need to tell your shell where to find the devkitARM binaries.<br />
<pre><br />
echo "export DEVKITPRO=/opt/devkitpro" >> ~/.bashrc<br />
echo "export DEVKITARM=/opt/devkitpro/devkitARM" >> ~/.bashrc<br />
echo "export PATH=$PATH:/opt/devkitpro/devkitARM/bin" >> ~/.bashrc<br />
source ~/.bashrc<br />
</pre><br />
<br />
= Building the examples =<br />
3DS examples are still being created; however, there are a growing number of examples available from the [https://github.com/devkitPro/3ds-examples devkitPro/3ds-examples GitHub repository].<br />
There are now too many to list here in detail, so go ahead and browse them.<br />
<br />
* To download these, if you installed Git (as you will have if you followed the above instructions), simply type <code>git clone https://github.com/devkitPro/3ds-examples.git</code> into your shell in the directory you wish to store the 3ds-examples folder in.<br />
** To overwrite the (almost certainly outdated) examples installed by the devkitPro updater, type <code>git clone https://github.com/devkitPro/3ds-examples.git $DEVKITPRO/examples/3ds</code>.<br />
<br />
These can be built from the command line.<br />
<br />
To start a new homebrew project from the <code>bash</code> shell, simply type the following (replacing <code>'''~/projects/my3dsproject'''</code> with the place you would like your project to be stored, with <code>~</code> meaning your HOME directory):<br />
cp -r $DEVKITPRO/examples/3ds/templates/application '''~/projects/my3dsproject'''<br />
cd '''~/projects/my3dsproject'''<br />
<br />
To compile it, type <code>make</code> in the project directory.<br />
To run it on your 3DS, start the Homebrew Launcher, press Y to open the network loader, then on your PC type: <code>$DEVKITARM/bin/3dslink -a '''192.168.X.X''' '''my3dsproject'''.3dsx</code>, replacing '''192.168.X.X''' with your 3DS's IP address (displayed in the network loader screen) and '''my3dsproject''' with the name of the folder your project is in (ie. the folder you have the source folder in and the README file.)<br />
Don't type the full path, just the last segment - eg. for <code>C:\a\b\'''verygood3dsapp'''</code>, you would type <code>'''verygood3dsapp'''.3dsx</code>.<br />
<br />
If all goes well, you'll soon see your application running on your 3DS.<br />
<br />
==Building the examples on Linux with Netbeans==<br />
* Go to File->New Project...<br />
* Select C/C++ Project with existing code<br />
* Navigate to the examples directory and select the folder for the project you want to build; eg. /home/vtsingaras/3ds/examples/app_launch<br />
* Leave Configuration Mode to 'Automatic' and click 'Finish'.<br />
* It will fail to build. Now edit Makefile and insert these two lines, adjusting for your devkitpro path, at the top:<br />
<pre>export DEVKITPRO=/opt/devkitpro<br />
export DEVKITARM=/opt/devkitpro/devkitARM</pre><br />
* Right-click the project and go to Properties->Code Assistance and click C Compiler.<br />
* In include directories enter <br />
<pre>/opt/devkitpro/devkitARM/include;/opt/devkitpro/ctrulib/libctru/include</pre><br />
adjusting again for your devkitPro path.<br />
* Do the same for 'C++ Compiler'.<br />
* Go to 'Run' and click 'Clean and Build Project'.<br />
* Now right-click on the project and select Code Assistance->Reparse Project.<br />
<br />
Now you can use Netbeans' code completion feature and build your project from the Run menu.<br />
<br />
= Building homebrew for distribution =<br />
To build your homebrew, open a Bash shell as described above, browse to the folder of the homebrew you wish to compile, and run <code>make</code>.<br />
<br />
* This will build a .elf file and a .3dsx file (the homebrew executable itself) together with a .smdh file (the icon).<br />
** The Homebrew Launcher can only run homebrew in the 3DSX format, and can only display SMDH icons.<br />
<br />
* To build a CCI (.3ds) file, you need to strip the .elf file and use makerom on it (with the provided RSF file):<br />
arm-none-eabi-strip '''[ELF file]'''<br />
makerom -f cci -o '''[.3ds file]''' -rsf '''[RSF file]''' -target t -exefslogo -elf '''[ELF file]''' -icon '''[icon file]''' -banner '''[banner file]'''<br />
<br />
= Troubleshooting =<br />
'''I get the "Please set DEVKITARM in your environment." error.'''<br />
<br />
Use the following command before installing [http://askubuntu.com/questions/573070/problem-setting-up-environment-for-make-command-execution]:<br />
sudo chown $USER /opt/devkitpro/ -R<br />
echo "export DEVKITPRO="/opt/devkitpro/" >> ~/.profile<br />
echo "export DEVKITARM="/opt/devkitpro/devkitARM/" >> ~/.profile<br />
source ~/.profile<br />
For WSL users, you need to close the Bash shell, then reopen it for WSL to reload all of the variables from a clean state.<br />
<br />
'''Unable to load source code when debugging using the provided GDB. It says, "No source files available".'''<br />
<br />
When after loading your ELF file, make sure to set a breakpoint at main(), then continue. The GDB will refresh with your source code.</div>Mrrraouhttps://www.3dbrew.org/w/index.php?title=Filesystem_services&diff=18426Filesystem services2016-10-17T17:02:24Z<p>Mrrraou: Undo revision 18425 by Neobrain (talk): this makes no sense, that's not how it works</p>
<hr />
<div>[[Category:Services]]<br />
<br />
= Services =<br />
== Filesystem service "fs:USER" ==<br />
You can at most have 32 FS archive handles.<br />
<br />
{| class="wikitable" border="1"<br />
|-<br />
! Command Header<br />
! Available since system version <br />
! Description<br />
! scope="col" width="400" | Required [[NCCH/Extended_Header|exheader]] access info bitmask<br />
|-<br />
| 0x000100C6<br />
|?<br />
| [[FS:Dummy1|Dummy1]]<br />
| None<br />
|-<br />
| 0x040100C4<br />
|?<br />
| [[FS:Control|Control]]<br />
| None<br />
|-<br />
| 0x08010002<br />
|?<br />
| [[FS:Initialize|Initialize]]<br />
| None<br />
|-<br />
| 0x080201C2<br />
|?<br />
| [[FS:OpenFile|OpenFile]]<br />
| None<br />
|-<br />
| 0x08030204<br />
|?<br />
| [[FS:OpenFileDirectly|OpenFileDirectly]]<br />
| None<br />
|-<br />
| 0x08040142<br />
|?<br />
| [[FS:DeleteFile|DeleteFile]]<br />
| None<br />
|-<br />
| 0x08050244<br />
|?<br />
| [[FS:RenameFile|RenameFile]]<br />
| None<br />
|-<br />
| 0x08060142<br />
|?<br />
| [[FS:DeleteDirectory|DeleteDirectory]]<br />
| None<br />
|-<br />
| 0x08070142<br />
|?<br />
| [[FS:DeleteDirectoryRecursively|DeleteDirectoryRecursively]]<br />
| None<br />
|-<br />
| 0x08080202<br />
|?<br />
| [[FS:CreateFile|CreateFile]]<br />
| None<br />
|-<br />
| 0x08090182<br />
|?<br />
| [[FS:CreateDirectory|CreateDirectory]]<br />
| None<br />
|-<br />
| 0x080A0244<br />
|?<br />
| [[FS:RenameDirectory|RenameDirectory]]<br />
| None<br />
|-<br />
| 0x080B0102<br />
|?<br />
| [[FS:OpenDirectory|OpenDirectory]]<br />
| None<br />
|-<br />
| 0x080C00C2<br />
|?<br />
| [[FS:OpenArchive|OpenArchive]]<br />
| Each archive ID code has separate access info bitmasks, if it has any<br />
|-<br />
| 0x080D0144<br />
|?<br />
| [[FS:ControlArchive|ControlArchive]]<br />
| None<br />
|-<br />
| 0x080E0080<br />
|?<br />
| [[FS:CloseArchive|CloseArchive]]<br />
| None<br />
|-<br />
| 0x080F0180<br />
|?<br />
| [[FS:Obsoleted_2_0_FormatThisUserSaveData|Obsoleted_2_0_FormatThisUserSaveData]]<br />
| None<br />
|-<br />
| 0x08100200<br />
|?<br />
| [[FS:Obsoleted_3_0_CreateSystemSaveData|Obsoleted_3_0_CreateSystemSaveData]]<br />
| 0x4, for when the input saveID doesn't match the exheader saveID<br />
|-<br />
| 0x08110040<br />
|?<br />
| [[FS:Obsoleted_3_0_DeleteSystemSaveData|Obsoleted_3_0_DeleteSystemSaveData]]<br />
| 0x1004, for when the input saveID doesn't match the exheader saveID<br />
|-<br />
| 0x08120080<br />
|?<br />
| [[FS:GetFreeBytes|GetFreeBytes]]<br />
| None<br />
|-<br />
| 0x08130000<br />
|?<br />
| [[FS:GetCardType|GetCardType]]<br />
| 0x1017<br />
|-<br />
| 0x08140000<br />
|?<br />
| [[FS:GetSdmcArchiveResource|GetSdmcArchiveResource]]<br />
| None<br />
|-<br />
| 0x08150000<br />
|?<br />
| [[FS:GetNandArchiveResource|GetNandArchiveResource]]<br />
| 0x1007<br />
|-<br />
| 0x08160000<br />
|?<br />
| [[FS:GetSdmcFatfsError|GetSdmcFatfsError]]<br />
| 0x2<br />
|-<br />
| 0x08170000<br />
|?<br />
| [[FS:IsSdmcDetected|IsSdmcDetected]]<br />
| None<br />
|-<br />
| 0x08180000<br />
|?<br />
| [[FS:IsSdmcWritable|IsSdmcWritable]]<br />
| None<br />
|-<br />
| 0x08190042<br />
|?<br />
| [[FS:GetSdmcCid|GetSdmcCid]]<br />
| 0x2<br />
|-<br />
| 0x081A0042<br />
|?<br />
| [[FS:GetNandCid|GetNandCid]]<br />
| 0x2<br />
|-<br />
| 0x081B0000<br />
|?<br />
| [[FS:GetSdmcSpeedInfo|GetSdmcSpeedInfo]]<br />
| 0x2<br />
|-<br />
| 0x081C0000<br />
|?<br />
| [[FS:GetNandSpeedInfo|GetNandSpeedInfo]]<br />
| 0x2<br />
|-<br />
| 0x081D0042<br />
|?<br />
| [[FS:GetSdmcLog|GetSdmcLog]]<br />
| 0x2<br />
|-<br />
| 0x081E0042<br />
|?<br />
| [[FS:GetNandLog|GetNandLog]]<br />
| 0x2<br />
|-<br />
| 0x081F0000<br />
|?<br />
| [[FS:ClearSdmcLog|ClearSdmcLog]]<br />
| 0x2<br />
|-<br />
| 0x08200000<br />
|?<br />
| [[FS:ClearNandLog|ClearNandLog]]<br />
| 0x2<br />
|-<br />
| 0x08210000<br />
|?<br />
| [[FS:CardSlotIsInserted|CardSlotIsInserted]]<br />
| 0x1017<br />
|-<br />
| 0x08220000<br />
|?<br />
| [[FS:CardSlotPowerOn|CardSlotPowerOn]]<br />
| 0x2<br />
|-<br />
| 0x08230000<br />
|?<br />
| [[FS:CardSlotPowerOff|CardSlotPowerOff]]<br />
| 0x2<br />
|-<br />
| 0x08240000<br />
|?<br />
| [[FS:CardSlotGetCardIFPowerStatus|CardSlotGetCardIFPowerStatus]]<br />
| 0x2<br />
|-<br />
| 0x08250040<br />
|?<br />
| [[FS:CardNorDirectCommand|CardNorDirectCommand]]<br />
| 0x2<br />
|-<br />
| 0x08260080<br />
|?<br />
| [[FS:CardNorDirectCommandWithAddress|CardNorDirectCommandWithAddress]]<br />
| 0x2<br />
|-<br />
| 0x08270082<br />
|?<br />
| [[FS:CardNorDirectRead|CardNorDirectRead]]<br />
| 0x2<br />
|-<br />
| 0x082800C2<br />
|?<br />
| [[FS:CardNorDirectReadWithAddress|CardNorDirectReadWithAddress]]<br />
| 0x2<br />
|-<br />
| 0x08290082<br />
|?<br />
| [[FS:CardNorDirectWrite|CardNorDirectWrite]]<br />
| 0x2<br />
|-<br />
| 0x082A00C2<br />
|?<br />
| [[FS:CardNorDirectWriteWithAddress|CardNorDirectWriteWithAddress]]<br />
| 0x2<br />
|-<br />
| 0x082B00C2<br />
|?<br />
| [[FS:CardNorDirectRead_4xIO|CardNorDirectRead_4xIO]]<br />
| 0x2<br />
|-<br />
| 0x082C0082<br />
|?<br />
| [[FS:CardNorDirectCpuWriteWithoutVerify|CardNorDirectCpuWriteWithoutVerify]]<br />
| 0x2<br />
|-<br />
| 0x082D0040<br />
|?<br />
| [[FS:CardNorDirectSectorEraseWithoutVerify|CardNorDirectSectorEraseWithoutVerify]]<br />
| 0x2<br />
|-<br />
| 0x082E0040<br />
|?<br />
| [[FS:GetProductInfo|GetProductInfo]]<br />
| 0x1005<br />
|-<br />
| 0x082F0040<br />
|?<br />
| [[FS:GetProgramLaunchInfo|GetProgramLaunchInfo]]<br />
| 0x1005<br />
|-<br />
| 0x08300182<br />
|?<br />
| [[FS:Obsoleted_3_0_CreateExtSaveData|Obsoleted_3_0_CreateExtSaveData]]<br />
| 0xC, for when the input extdataID doesn't match the exheader extdataID<br />
|-<br />
| 0x08310180<br />
|?<br />
| [[FS:Obsoleted_3_0_CreateSharedExtSaveData|Obsoleted_3_0_CreateSharedExtSaveData]]<br />
| 0x1005<br />
|-<br />
| 0x08320102<br />
|?<br />
| [[FS:Obsoleted_3_0_ReadExtSaveDataIcon|Obsoleted_3_0_ReadExtSaveDataIcon]]<br />
| 0x100D, for when the input extdataID doesn't match the exheader extdataID<br />
|-<br />
| 0x08330082<br />
|?<br />
| [[FS:Obsoleted_3_0_EnumerateExtSaveData|Obsoleted_3_0_EnumerateExtSaveData]]<br />
| 0x1005<br />
|-<br />
| 0x08340082<br />
|?<br />
| [[FS:Obsoleted_3_0_EnumerateSharedExtSaveData|Obsoleted_3_0_EnumerateSharedExtSaveData]]<br />
| 0x1005<br />
|-<br />
| 0x08350080<br />
|?<br />
| [[FS:Obsoleted_3_0_DeleteExtSaveData|Obsoleted_3_0_DeleteExtSaveData]]<br />
| 0x100D, for when the input extdataID doesn't match the exheader extdataID<br />
|-<br />
| 0x08360080<br />
|?<br />
| [[FS:Obsoleted_3_0_DeleteSharedExtSaveData|Obsoleted_3_0_DeleteSharedExtSaveData]]<br />
| 0x1005<br />
|-<br />
| 0x08370040<br />
|?<br />
| [[FS:SetCardSpiBaudRate|SetCardSpiBaudRate]]<br />
| 0x2<br />
|-<br />
| 0x08380040<br />
|?<br />
| [[FS:SetCardSpiBusMode|SetCardSpiBusMode]]<br />
| 0x2<br />
|-<br />
| 0x08390000<br />
|?<br />
| [[FS:SendInitializeInfoTo9|SendInitializeInfoTo9]]<br />
| None<br />
|-<br />
| 0x083A0100<br />
|?<br />
| [[FS:GetSpecialContentIndex|GetSpecialContentIndex]]<br />
| 0x1005<br />
|-<br />
| 0x083B00C2<br />
|?<br />
| [[FS:GetLegacyRomHeader|GetLegacyRomHeader]]<br />
| 0x1015<br />
|-<br />
| 0x083C00C2<br />
|?<br />
| [[FS:GetLegacyBannerData|GetLegacyBannerData]]<br />
| 0x1015<br />
|-<br />
| 0x083D0100<br />
|?<br />
| [[FS:CheckAuthorityToAccessExtSaveData|CheckAuthorityToAccessExtSaveData]]<br />
| 0x44<br />
|-<br />
| 0x083E00C2<br />
|?<br />
| [[FS:QueryTotalQuotaSize|QueryTotalQuotaSize]]<br />
| None<br />
|-<br />
| 0x083F00C0<br />
|?<br />
| [[FS:Obsoleted_3_0_GetExtDataBlockSize|Obsoleted_3_0_GetExtDataBlockSize]]<br />
| None<br />
|-<br />
| 0x08400040<br />
|?<br />
| [[FS:AbnegateAccessRight|AbnegateAccessRight]]<br />
|?<br />
|-<br />
| 0x08410000<br />
|?<br />
| [[FS:DeleteSdmcRoot|DeleteSdmcRoot]]<br />
| 0x1005<br />
|-<br />
| 0x08420040<br />
|?<br />
| [[FS:DeleteAllExtSaveDataOnNand|DeleteAllExtSaveDataOnNand]]<br />
| 0x1005<br />
|-<br />
| 0x08430000<br />
|?<br />
| [[FS:InitializeCtrFileSystem|InitializeCtrFileSystem]]<br />
| None<br />
|-<br />
| 0x08440000<br />
|?<br />
| [[FS:CreateSeed|CreateSeed]]<br />
| 0x2<br />
|-<br />
| 0x084500C2<br />
|?<br />
| [[FS:GetFormatInfo|GetFormatInfo]]<br />
|?<br />
|-<br />
| 0x08460102<br />
|?<br />
| [[FS:GetLegacyRomHeader2|GetLegacyRomHeader2]]<br />
| 0x1015<br />
|-<br />
| 0x08470180<br />
|?<br />
| [[FS:Obsoleted_2_0_FormatCtrCardUserSaveData|Obsoleted_2_0_FormatCtrCardUserSaveData]]<br />
| 0x6<br />
|-<br />
| 0x08480042<br />
|?<br />
| [[FS:GetSdmcCtrRootPath|GetSdmcCtrRootPath]]<br />
| 0x100D<br />
|-<br />
| 0x08490040<br />
|?<br />
| [[FS:GetArchiveResource|GetArchiveResource]]<br />
|?<br />
|-<br />
| 0x084A0002<br />
|?<br />
| [[FS:ExportIntegrityVerificationSeed|ExportIntegrityVerificationSeed]]<br />
| 0x4000<br />
|-<br />
| 0x084B0002<br />
|?<br />
| [[FS:ImportIntegrityVerificationSeed|ImportIntegrityVerificationSeed]]<br />
| 0x4000<br />
|-<br />
| 0x084C0242<br />
|?<br />
| [[FS:FormatSaveData|FormatSaveData]]<br />
| 0x6, in some cases this write isn't needed however<br />
|-<br />
| 0x084D0102<br />
|?<br />
| [[FS:GetLegacySubBannerData|GetLegacySubBannerData]]<br />
| 0x1015<br />
|-<br />
| 0x084E0342<br />
|?<br />
| [[FS:UpdateSha256Context|UpdateSha256Context]]<br />
| 0x5<br />
|-<br />
| 0x084F0102<br />
|?<br />
| [[FS:ReadSpecialFile|ReadSpecialFile]]<br />
| None<br />
|-<br />
| 0x08500040<br />
|?<br />
| [[FS:GetSpecialFileSize|GetSpecialFileSize]]<br />
| None<br />
|-<br />
| 0x08510242<br />
| [[3.0.0-5]]<br />
| [[FS:CreateExtSaveData|CreateExtSaveData]]<br />
| Shared extdata: 0x101005. Regular extdata in certain cases: 0xC<br />
|-<br />
| 0x08520100<br />
| [[3.0.0-5]]<br />
| [[FS:DeleteExtSaveData|DeleteExtSaveData]]<br />
| Shared extdata: 0x101005. Regular extdata in certain cases: 0x10100D<br />
|-<br />
| 0x08530142<br />
| [[3.0.0-5]]<br />
| [[FS:ReadExtSaveDataIcon|ReadExtSaveDataIcon]]<br />
| 0x10100D (this doesn't apply in certain cases, however)<br />
|-<br />
| 0x085400C0<br />
| [[3.0.0-5]]<br />
| [[FS:GetExtDataBlockSize|GetExtDataBlockSize]]<br />
| 0x10100D (this doesn't apply in certain cases, however)<br />
|-<br />
| 0x08550102<br />
| [[3.0.0-5]]<br />
| [[FS:EnumerateExtSaveData|EnumerateExtSaveData]]<br />
| 0x101005<br />
|-<br />
| 0x08560240<br />
| [[3.0.0-5]]<br />
| [[FS:CreateSystemSaveData|CreateSystemSaveData]]<br />
| 0x4 (this doesn't apply in certain cases, however)<br />
|-<br />
| 0x08570080<br />
| [[3.0.0-5]]<br />
| [[FS:DeleteSystemSaveData|DeleteSystemSaveData]]<br />
| 0x1004 (this doesn't apply in certain cases, however)<br />
|-<br />
| 0x08580000<br />
| [[3.0.0-5]]<br />
| [[FS:StartDeviceMoveAsSource|StartDeviceMoveAsSource]]<br />
| 0x2004<br />
|-<br />
| 0x08590200<br />
| [[3.0.0-5]]<br />
| [[FS:StartDeviceMoveAsDestination|StartDeviceMoveAsDestination]]<br />
| 0x2004<br />
|-<br />
| 0x085A00C0<br />
| [[3.0.0-5]]<br />
| [[FS:SetArchivePriority|SetArchivePriority]]<br />
| None<br />
|-<br />
| 0x085B0080<br />
| [[3.0.0-5]]<br />
| [[FS:GetArchivePriority|GetArchivePriority]]<br />
| None<br />
|-<br />
| 0x085C00C0<br />
| [[3.0.0-5]]<br />
| [[FS:SetCtrCardLatencyParameter|SetCtrCardLatencyParameter]]<br />
| 0xE<br />
|-<br />
| 0x085D01C0<br />
| [[3.0.0-5]]<br />
| [[FS:SetFsCompatibilityInfo|SetFsCompatibilityInfo]]<br />
| 0x100001<br />
|-<br />
| 0x085E0040<br />
| [[3.0.0-5]]<br />
| [[FS:ResetCardCompatibilityParameter|ResetCardCompatibilityParameter]]<br />
| 0xE<br />
|-<br />
| 0x085F0040<br />
| [[3.0.0-5]]<br />
| [[FS:SwitchCleanupInvalidSaveData|SwitchCleanupInvalidSaveData]]<br />
| 0x12004<br />
|-<br />
| 0x08600042<br />
| [[3.0.0-5]]<br />
| [[FS:EnumerateSystemSaveData|EnumerateSystemSaveData]]<br />
| 0x2004<br />
|-<br />
| 0x08610042<br />
| [[3.0.0-5]]<br />
| [[FS:InitializeWithSdkVersion|InitializeWithSdkVersion]]<br />
| None<br />
|-<br />
| 0x08620040<br />
| [[3.0.0-5]]<br />
| [[FS:SetPriority|SetPriority]]<br />
| None<br />
|-<br />
| 0x08630000<br />
| [[3.0.0-5]]<br />
| [[FS:GetPriority|GetPriority]]<br />
| None<br />
|-<br />
| 0x08640000<br />
| [[3.0.0-5]]<br />
| [[FS:Obsoleted_4_0_GetNandInfo|Obsoleted_4_0_GetNandInfo]]<br />
| Stubbed, this returns an error<br />
|-<br />
| 0x08650140<br />
| [[4.0.0-7]]<br />
| [[FS:SetSaveDataSecureValue|SetSaveDataSecureValue]]<br />
| 0x121004 (in certain cases this doesn't apply, however)<br />
|-<br />
| 0x086600C0<br />
| [[4.0.0-7]]<br />
| [[FS:GetSaveDataSecureValue|GetSaveDataSecureValue]]<br />
| 0x121004 (in certain cases this doesn't apply, however)<br />
|-<br />
| 0x086700C4<br />
| [[4.0.0-7]]<br />
| [[FS:ControlSecureSave|ControlSecureSave]]<br />
| 0x121004<br />
|-<br />
| 0x08680000<br />
| [[4.0.0-7]]<br />
| [[FS:GetMediaType|GetMediaType]]<br />
| None<br />
|-<br />
| 0x08690000<br />
| [[4.0.0-7]]<br />
| [[FS:Obsoleted_4_0_GetNandEraseCount|Obsoleted_4_0_GetNandEraseCount]]<br />
| Stubbed, this returns an error.<br />
|-<br />
| 0x086A0082<br />
| [[4.0.0-7]]<br />
| [[FS:ReadNandReport|ReadNandReport]]<br />
| None<br />
|-<br />
| 0x086B00C2<br />
|?<br />
|?<br />
| 00121004<br />
|-<br />
| 0x086C00C2<br />
|?<br />
|?<br />
| 00121004<br />
|-<br />
| 0x086D0040<br />
|?<br />
|?<br />
| 00020004<br />
|-<br />
| 0x086E00C0<br />
|?<br />
|?<br />
|None?<br />
|-<br />
| 0x086F0040<br />
|?<br />
|?<br />
| 0xE<br />
|-<br />
| 0x087000C2<br />
|?<br />
|?<br />
|None?<br />
|-<br />
| 0x08710100<br />
|?<br />
|?<br />
| 0xC<br />
|-<br />
| 0x087201C0<br />
|?<br />
|?<br />
| 00080004<br />
|-<br />
| 0x087300C0<br />
|?<br />
|?<br />
| 00080004<br />
|-<br />
| 0x08740000<br />
|?<br />
|?<br />
| 00080004<br />
|-<br />
| 0x08750140<br />
|?<br />
|?<br />
|None?<br />
|-<br />
| 0x087600C0<br />
|?<br />
|?<br />
|None?<br />
|-<br />
| 0x08770100<br />
|?<br />
|?<br />
|?<br />
|-<br />
| 0x087800C0<br />
|?<br />
|?<br />
|?<br />
|-<br />
| 0x087900C2<br />
| ?<br />
| Same as GetLegacyBannerData, except for the last parameter this passes u8 value 0x1 instead of 0x0, for the FSPXI command.<br />
| 0x00101015<br />
|-<br />
| 0x087A0180<br />
| [[9.6.0-24|9.6.0-X]]<br />
| [[FS:AddSeed|AddSeed]]<br />
| 0x00200000<br />
|-<br />
| 0x087B....<br />
| [[9.6.0-24|9.6.0-X]]<br />
| Wrapper for the code internally used for command <0x087A....>.<br />
| 0x00200000<br />
|-<br />
| 0x087C....<br />
| [[9.6.0-24|9.6.0-X]]<br />
| Eventually calls same code as command <0x087A....>.<br />
| 0x00200000<br />
|-<br />
| 0x087D0000<br />
| [[9.6.0-24|9.6.0-X]]<br />
| Writes an u32 from state to cmdreply[2]. Probably the total number of titles in the SEEDDB?<br />
| 0x00200000<br />
|-<br />
| 0x087E0042<br />
| [[9.6.0-24|9.6.0-X]]<br />
| Eventually calls same code as command <0x087A....>. Writes a list of titleIDs to the outbuf, this is for titles with content-lock-seed(s) stored in SEEDDB. (u32 total_titleids_probably, ((Size<<4) <nowiki>|</nowiki> 12), outbufptr)<br />
| 0x00200000<br />
|-<br />
| 0x087F....<br />
| [[9.6.0-24|9.6.0-X]]<br />
| ?<br />
| 0x00200000<br />
|-<br />
| 0x0880....<br />
| [[9.6.0-24|9.6.0-X]]<br />
| Eventually calls same code as command <0x087A....>.<br />
| 0x00200000<br />
|-<br />
| 0x0881....<br />
| [[9.6.0-24|9.6.0-X]]<br />
| Eventually calls same code as command <0x087A....>.<br />
| 0x00200000<br />
|-<br />
| 0x0882....<br />
| [[9.6.0-24|9.6.0-X]]<br />
| Eventually calls same code as command <0x087A....>.<br />
| 0x00200000<br />
|-<br />
| 0x08830000<br />
| [[9.6.0-24|9.6.0-X]]<br />
| Writes an output value to cmdreply[2].<br />
| 0x00200000<br />
|-<br />
| 0x08840042<br />
| [[9.6.0-24|9.6.0-X]]<br />
| Eventually calls same code as command <0x087A....>.<br />
| 0x00200000<br />
|-<br />
| 0x0885....<br />
| [[9.6.0-24|9.6.0-X]]<br />
| ?<br />
| 0x00200000<br />
|-<br />
| 0x088600C0<br />
| [[11.1.0-34|11.1.0-X]]<br />
| [[FS:CheckUpdatedDat|CheckUpdatedDat]]<br />
| 0x00080000<br />
|}<br />
<br />
Note: The question marks from Dummy1 to GetSpecialFileSize on the "available since system version" field are mainly there because I think that most of these are necessary for the main system to function, so theoretically that would mean that since the creation of the 3DS these were available, or since launch if that makes more sense. But because of the peculiar nature of some of the functions, they will remain question marks until they can be confirmed 100%.<br />
<br />
When access rights are required for a command, at least one of the bits in the process access info specified in the above table for the command must be set. Error 0xD9004676 is returned when a process attempts to use a command which it doesn't have access rights for the command. The exheader access info field is all zero's for most applications. Note that the permissions listed in the above table is for system-version v2.x, therefore permission bit(s) added with newer FIRM may be missing from this.<br />
<br />
Each session for fs:USER has separate permissions, initially these are set to all zero's for new fs:USER sessions. The permissions/etc for fs:USER sessions are initialized via [[FS:Initialize]](loaded from the user process exheader).<br />
<br />
== Filesystem service "fs:LDR" ==<br />
This service is identical to fs:USER, except [[FS:OpenArchive]] archive 0x2345678E can only be accessed with fs:LDR.<br />
<br />
== ProgramRegistry service "fs:REG" ==<br />
{| class="wikitable" border="1"<br />
|-<br />
! Command Header<br />
! Description<br />
|-<br />
| 0x000100C6<br />
| [[FSReg:Dummy1|Dummy1]]<br />
|-<br />
| 0x040103C0<br />
| [[FSReg:Register|Register]]<br />
|-<br />
| 0x04020040<br />
| [[FSReg:Unregister|Unregister]]<br />
|-<br />
| 0x040300C0<br />
| [[FSReg:GetProgramInfo|GetProgramInfo]]<br />
|-<br />
| 0x04040100<br />
| [[FSReg:LoadProgram|LoadProgram]]<br />
|-<br />
| 0x04050080<br />
| [[FSReg:UnloadProgram|UnloadProgram]]<br />
|-<br />
| 0x04060080<br />
| [[FSReg:CheckHostLoadId|CheckHostLoadId]]<br />
|}<br />
<br />
Only two sessions can be opened for this service at a time, hence no other processes can use this due to [[Process_Manager_Services|pm-module]] and [[Loader_Services|loader]] using this.<br />
<br />
=File and directory access=<br />
==Files==<br />
File session handles obtained via [[FS:OpenFile]] et al can be used to access files through a service-like interface, despite not being an actual service registered using [[SRV:RegisterService]].<br />
<br />
{| class="wikitable" border="1"<br />
|-<br />
! Command Header<br />
! Description<br />
|-<br />
| 0x000100C6<br />
| [[FSFile:Dummy1|Dummy1]]<br />
|-<br />
| 0x040100C4<br />
| [[FSFile:Control|Control]]<br />
|-<br />
| 0x08010100<br />
| [[FSFile:OpenSubFile|OpenSubFile]]<br />
|-<br />
| 0x080200C2<br />
| [[FSFile:Read|Read]]<br />
|-<br />
| 0x08030102<br />
| [[FSFile:Write|Write]]<br />
|-<br />
| 0x08040000<br />
| [[FSFile:GetSize|GetSize]]<br />
|-<br />
| 0x08050080<br />
| [[FSFile:SetSize|SetSize]]<br />
|-<br />
| 0x08060000<br />
| [[FSFile:GetAttributes|GetAttributes]]<br />
|-<br />
| 0x08070040<br />
| [[FSFile:SetAttributes|SetAttributes]]<br />
|-<br />
| 0x08080000<br />
| [[FSFile:Close|Close]]<br />
|-<br />
| 0x08090000<br />
| [[FSFile:Flush|Flush]]<br />
|-<br />
| 0x080A0040<br />
| [[FSFile:SetPriority|SetPriority]]<br />
|-<br />
| 0x080B0000<br />
| [[FSFile:GetPriority|GetPriority]]<br />
|-<br />
| 0x080C0000<br />
| [[FSFile:OpenLinkFile|OpenLinkFile]]<br />
|-<br />
| 0x0C010100<br />
| [[FSFile:GetAvailable|GetAvailable]]<br />
|}<br />
<br />
==Directories==<br />
{| class="wikitable" border="1"<br />
|-<br />
! Command Header<br />
! Available since system version<br />
! Description<br />
|-<br />
| 0x000100C6<br />
| [[1.0.0-0]]<br />
| [[FSDir:Dummy1|Dummy1]]<br />
|-<br />
| 0x040100C4<br />
| [[1.0.0-0]]<br />
| [[FSDir:Control|Control]]<br />
|-<br />
| 0x08010042<br />
| [[1.0.0-0]]<br />
| [[FSDir:Read|Read]]<br />
|-<br />
| 0x08020000<br />
| [[1.0.0-0]]<br />
| [[FSDir:Close|Close]]<br />
|-<br />
| 0x08030040<br />
| ?<br />
| [[FSDir:SetPriority|SetPriority]]<br />
|-<br />
| 0x08040000<br />
| ?<br />
| [[FSDir:GetPriority|GetPriority]]<br />
|}<br />
<br />
= Archives =<br />
{| class="wikitable" border="1"<br />
|-<br />
! ArchiveId<br />
! Description<br />
! Accessible via [[Filesystem_services|FS]]<br />
! Accessible via [[Filesystem_services_PXI|FSPXI]]<br />
! Only accessible by Process9 internally<br />
! Requires binary [[FS:OpenFile|Lowpath]]<br />
! Required exheader FS access info bitmask<br />
|-<br />
| 0x00000003<br />
| Application [[#RomFS|RomFS]]<br />
| Yes<br />
| No<br />
| No<br />
| No<br />
| None<br />
|-<br />
| 0x00000004<br />
| SaveData (the saveID/mediatype for this is loaded from data originally from the user process' exheader)<br />
| Yes<br />
| No<br />
| No<br />
| No<br />
| None<br />
|-<br />
| 0x00000006<br />
| ExtSaveData<br />
| Yes<br />
| No<br />
| No<br />
| Yes<br />
| 0x100D, when the input extdataID isn't listed in the exheader.<br />
|-<br />
| 0x00000007<br />
| Shared ExtSaveData<br />
| Yes<br />
| No<br />
| No<br />
| Yes<br />
| None<br />
|-<br />
| 0x00000008<br />
| SystemSaveData<br />
| Yes<br />
| No<br />
| No<br />
| Yes<br />
| 0x4, when the input saveID doesn't match the exheader system-saveID.<br />
|-<br />
| 0x00000009<br />
| SDMC<br />
| Yes<br />
| Yes<br />
| No<br />
| No<br />
| 0x8E<br />
|-<br />
| 0x0000000A<br />
| SDMC Write-Only<br />
| Yes<br />
| No<br />
| No<br />
| No<br />
| 0x808E<br />
|-<br />
| 0x12345678<br />
| ExtSaveData for BOSS<br />
| Yes<br />
| No<br />
| No<br />
| Yes<br />
| 0x44<br />
|-<br />
| 0x12345679<br />
| CARD SPI FS<br />
| Yes<br />
| Yes<br />
| No<br />
| No<br />
| 0x16<br />
|-<br />
| 0x1234567B<br />
| ExtSaveData, and ExtSaveData for BOSS<br />
| No<br />
| Yes<br />
| No<br />
| Yes<br />
| <br />
|-<br />
| 0x1234567C<br />
| SystemSaveData<br />
| No<br />
| Yes<br />
| No<br />
| Yes<br />
| <br />
|-<br />
| 0x1234567D<br />
| NAND RW<br />
| Yes<br />
| Yes<br />
| No<br />
| No<br />
| 0x800<br />
|-<br />
| 0x1234567E<br />
| NAND RO<br />
| Yes<br />
| Yes<br />
| No<br />
| No<br />
| 0x200<br />
|-<br />
| 0x1234567F<br />
| NAND RO Write FS<br />
| No<br />
| Yes<br />
| No<br />
| No<br />
| ?<br />
|-<br />
| 0x12345680<br />
| Unknown. There's code for this in spider v9.9, but that code isn't actually used.<br />
| Yes<br />
| ?<br />
| No<br />
| Yes<br />
| ?<br />
|-<br />
| 0x12345681<br />
| Unknown. Accessed by FS service.<br />
| ?<br />
| ?<br />
| No<br />
| ?<br />
| ?<br />
|-<br />
| 0x12345682<br />
| Unknown. There's code for this in spider v9.9, but that code isn't actually used.<br />
| Yes<br />
| ?<br />
| No<br />
| Yes<br />
| ?<br />
|-<br />
| 0x2345678A<br />
| Used for accessing general NCCH data. With FSPXI this also allows savedata access.<br />
| Yes<br />
| Yes<br />
| No<br />
| Yes<br />
| 0x1005<br />
|-<br />
| 0x2345678B<br />
| ?<br />
| No<br />
| No<br />
| Yes<br />
| Yes<br />
| <br />
|-<br />
| 0x2345678C<br />
| Used internally to access [[Title_Database|/dbs]] files?<br />
| No<br />
| No<br />
| Yes<br />
| Yes<br />
| <br />
|-<br />
| 0x2345678D<br />
| ?<br />
| No<br />
| No<br />
| Yes<br />
| No<br />
| <br />
|-<br />
| 0x2345678E<br />
| FSPXI: Similar to archive 0x2345678A. For fs:LDR(used by the "loader" FIRM ARM11-process), only ExeFS. Not accessible with fs:USER.<br />
| Yes<br />
| Yes<br />
| No<br />
| Yes<br />
| None, see description.<br />
|-<br />
| 0x567890AB<br />
| NAND CTR FS<br />
| No<br />
| Yes<br />
| No<br />
| No<br />
| ?<br />
|-<br />
| 0x567890AC<br />
| TWL PHOTO<br />
| Yes<br />
| Yes<br />
| No<br />
| No<br />
| ?<br />
|-<br />
| 0x567890AD<br />
| TWLS (DSi Sound stores recordings here). This is mapped to the FAT12 image stored in the file at [[Twln/shared2/0000]].<br />
| No<br />
| Yes<br />
| No<br />
| No<br />
| ?<br />
|-<br />
| 0x567890AE<br />
| NAND TWL FS<br />
| Yes<br />
| Yes<br />
| No<br />
| No<br />
| 0x100<br />
|-<br />
| 0x567890AF<br />
| NAND W FS<br />
| Yes<br />
| Yes<br />
| No<br />
| No<br />
| 0x100<br />
|-<br />
| 0x567890B0<br />
| ?<br />
| No<br />
| Yes<br />
| No<br />
| No<br />
| <br />
|-<br />
| 0x567890B1<br />
| Gamecard SaveData (for check). This is a wrapper for UserSaveDataForCheck: the OpenArchive code for that is called with archive-lowpath TID=0/mediatype=2(gamecard).<br />
| Yes<br />
| No<br />
| No<br />
| No<br />
| 0x6<br />
|-<br />
| 0x567890B2<br />
| UserSaveData (for check). This is the same as the regular SaveData archive, except with this the savedata ID and mediatype is loaded from the input archive lowpath.<br />
| Yes<br />
| No<br />
| No<br />
| Yes<br />
| 0x6<br />
|-<br />
| 0x567890B4<br />
| ? SaveData from Demo Version of Retail Game<br />
| Yes<br />
| No<br />
| No<br />
| No<br />
| ?<br />
|}<br />
<br />
Archives listed as not requiring a binary lowpath, use lowpath type [[FS:OpenFile|empty]].<br />
<br />
The above permission bitmasks are from v2.x, see the above Services section for how these are handled.<br />
<br />
Archives CTR NAND, NAND RO Write FS, TWL NAND, NAND W FS, and CARD SPI FS require the corresponding process exheader access control mount flag to be set, in the exheader for any of the currently running ARM11 processes, for [[Filesystem_services_PXI|FSPXI]]. The access rights checked by [[Filesystem services|FS]] module for archive mounting with fs:USER, are stored in the process' exheader accessinfo.<br />
<br />
The CARDSPI archive allows access to the gamecard CARD1 raw savedata flash(aka "cardspi:/" in [[FIRM|Process9]]), the file lowpath must be WCHAR "/". The "NAND W FS" archive allows access to the raw NAND image(aka "wnand:/" in Process9), the file lowpath must be WCHAR "/".<br />
<br />
= Filenames and Paths =<br />
PathType:<br />
{| class="wikitable" border="1"<br />
|-<br />
! Value<br />
! Description<br />
|-<br />
| -1<br />
| Returned internally by Process9, when errors occur it seems(in particular when no nul-terminator was found in the input path). The data ptr is set to NULL.<br />
|-<br />
| 0x0<br />
| INVALID - Specifies an invalid path<br />
|-<br />
| 0x1<br />
| EMPTY - Specifies an empty path<br />
|-<br />
| 0x2<br />
| BINARY - Non-text based path. Meaning is per-archive<br />
|-<br />
| 0x3<br />
| ASCII - Text-based path with 7-bit ASCII characters padded to 8-bits each (signed char)<br />
|-<br />
| 0x4<br />
| UTF16 - Text-based path with UTF-16 characters<br />
|}<br />
<br />
In IPC requests, sizes of ASCII and UTF16 paths must include space for the null-terminator. <br />
<br />
== Binary LowPath ==<br />
The format of the data that a binary LowPath points to is custom per archive.<br />
<br />
=== SystemSaveData Archive Path Data Format ===<br />
==== FS ====<br />
{| class="wikitable" border="1"<br />
|-<br />
! Index word<br />
! Description<br />
|-<br />
| 0 <br />
| [[Mediatypes|Mediatype]] (must be zero for NAND)<br />
|-<br />
| 1<br />
| saveid<br />
|}<br />
The file/directory lowpath is a text lowpath in the [[Savegames|savegame]] filesystem.<br />
<br />
==== FSPXI ====<br />
{| class="wikitable" border="1"<br />
|-<br />
! Index word<br />
! Description<br />
|-<br />
| 0 <br />
| u8 [[Mediatypes|Mediatype]] (must be zero for NAND)<br />
|}<br />
The file lowpath is a binary lowpath containing the u64 saveid, however the high word of the saveid is always zero. The mounted file is the cleartext savegame image. Up to 32 SystemSaveData image files can be opened under a single mounted FSPXI archive.<br />
<br />
=== UserSaveDataForCheck Archive Path Data Format ===<br />
{| class="wikitable" border="1"<br />
|-<br />
! Index word<br />
! Description<br />
|-<br />
| 0 <br />
| [[Mediatypes|Mediatype]] (must be non-zero)<br />
|-<br />
| 1<br />
| Lower word saveid<br />
|-<br />
| 2<br />
| Upper word saveid<br />
|}<br />
The file/directory lowpath for this FS archive is a text path in the [[Savegames|savegame]] filesystem.<br />
<br />
=== ExtSaveData Archive Path Data Format ===<br />
{| class="wikitable" border="1"<br />
|-<br />
! Index word<br />
! Description<br />
|-<br />
| 0 <br />
| [[Mediatypes|Mediatype]]<br />
|-<br />
| 1<br />
| Lower word saveid<br />
|-<br />
| 2<br />
| Upper word saveid<br />
|}<br />
For FS, the file/directory lowpath is a text path in the [[extdata]] filesystem. For FSPXI, the file lowpath is a text path relative to the "/extdata/<ExtdataIDHigh>/<ExtdataIDLow>" directory on SD/NAND, for the cleartext extdata image to mount.<br />
<br />
=== 0x2345678A Archive Path Data Format ===<br />
{| class="wikitable" border="1"<br />
|-<br />
! Index word<br />
! Description<br />
|-<br />
| 0<br />
| Lower word programID<br />
|-<br />
| 1<br />
| Upper word programID<br />
|-<br />
| 2 <br />
| [[Mediatypes|Mediatype]]<br />
|-<br />
| 3<br />
| Reserved<br />
|}<br />
<br />
File lowpath:<br />
{| class="wikitable" border="1"<br />
|-<br />
! Index word<br />
! Description<br />
|-<br />
| 0<br />
| 0 for NCCH data, 1 for savedata. The latter is only valid for FSPXI. Value 2 is allowed via archive 0x3, it's unknown what this is.<br />
|-<br />
| 1<br />
| TMD content index / NCSD partition index.<br />
|-<br />
| 2<br />
| Type: 0=romfs(0 for non-NCCH as well), 1=exefs ".code"(?), 2=exefs "icon"/"banner"/"logo", 3=unknown, 4=unknown, 5=unknown.<br />
|-<br />
| 3-4<br />
| Filename for ExeFS.<br />
|}<br />
<br />
The 0x14-byte lowpath is all-zero for accessing the title's main RomFS.<br />
<br />
=== [[RomFS]] ===<br />
<br />
Archives 0x3 and 0x2345678E both allow for accessing the [[RomFS#Level_3_Format|level-3 IVFC images]] for RomFS access. The main CXI RomFS is accessible via an all-zero 0xc-byte binary file-lowpath. The update RomFS can be accessed with the first u32 in the binary file-lowpath being set to 0x5. The user must handle parsing the filesystem used in the exposed image itself.<br />
<br />
The 0x3 archive is an interface for the 0x2345678E archive with the current process programID+mediatype. The file lowpath is 3-words. These words are written to 0x2345678E-archive file_lowpath+0, with the rest of that lowpath set to all-zero(lowpath is different from archive 0x2345678A). File lowpath:<br />
{| class="wikitable" border="1"<br />
|-<br />
! Index word<br />
! Description<br />
|-<br />
| 0<br />
| See above. The only values which FS-module doesn't allow to be used here are:<br />
* 0x1: Error 0xE0E046BE.<br />
* 0x3: Error 0xE0E046BE.<br />
* 0x4: FS-module executes svcBreak when using this.<br />
|-<br />
| 1-2<br />
| See above. Not validated by FS-module.<br />
|}<br />
<br />
=SEEDDB=<br />
With [[9.6.0-24|9.6.0-X]] new [[System_SaveData]] with saveID 0001000F was added, this seems to be handled by FS-module itself, probably via the new service-cmds added to fsuser. [[Home Menu]] and [[NIM_Services|NIM]] module have access to those commands.<br />
<br />
The SEEDDB savedata contains the title-unique seed-data used for the new [[NCCH]] keyY generation added with FIRM [[9.6.0-24|9.6.0-X]].<br />
<br />
= Common Types =<br />
== MediaType ==<br />
{| class="wikitable" border="1"<br />
|-<br />
! Value<br />
! Description<br />
|-<br />
| 0<br />
| NAND<br />
|-<br />
| 1<br />
| SD<br />
|-<br />
| 2<br />
| Game Card<br />
|}<br />
<br />
== SystemMediaType ==<br />
{| class="wikitable" border="1"<br />
|-<br />
! Value<br />
! Description<br />
|-<br />
| 0<br />
| CTR NAND<br />
|-<br />
| 1<br />
| TWL NAND<br />
|-<br />
| 2<br />
| SD<br />
|-<br />
| 2<br />
| TWL Photo<br />
|}<br />
<br />
== OpenFlags ==<br />
{| class="wikitable" border="1"<br />
|-<br />
! Bit<br />
! Description<br />
|-<br />
| 0<br />
| Read<br />
|-<br />
| 1<br />
| Write<br />
|-<br />
| 2<br />
| Create<br />
|}<br />
<br />
== Attributes ==<br />
{| class="wikitable" border="1"<br />
|-<br />
! Offset<br />
! Size<br />
! Description<br />
|-<br />
| 0x0<br />
| 0x1<br />
| Is Directory<br />
|-<br />
| 0x1<br />
| 0x1<br />
| Is Hidden<br />
|-<br />
| 0x2<br />
| 0x1<br />
| Is Archive<br />
|-<br />
| 0x3<br />
| 0x1<br />
| Is Read-Only<br />
|}<br />
<br />
== WriteOption ==<br />
{| class="wikitable" border="1"<br />
|-<br />
! Offset<br />
! Size<br />
! Description<br />
|-<br />
| 0x0<br />
| 0x1<br />
| Flush<br />
|-<br />
| 0x1<br />
| 0x1<br />
| Update Time Stamp<br />
|-<br />
| 0x2<br />
| 0x1<br />
| Reserved<br />
|-<br />
| 0x3<br />
| 0x1<br />
| Reserved<br />
|}<br />
<br />
== DirectoryEntry ==<br />
{| class="wikitable" border="1"<br />
|-<br />
! Offset<br />
! Size<br />
! Description<br />
|-<br />
| 0x0<br />
| 0x20C<br />
| UTF-16 Entry Name<br />
|-<br />
| 0x20C<br />
| 0xA<br />
| 8.3 short filename name<br />
|-<br />
| 0x216<br />
| 0x4<br />
| 8.3 short filename extension<br />
|-<br />
| 0x21A<br />
| 0x1<br />
| Always 1<br />
|-<br />
| 0x21B<br />
| 0x1<br />
| Reserved<br />
|-<br />
| 0x21C<br />
| 0x4<br />
| [[Filesystem_services#Attributes|Attributes]]<br />
|-<br />
| 0x220<br />
| 0x8<br />
| Entry Size<br />
|}<br />
<br />
== ArchiveResource ==<br />
{| class="wikitable" border="1"<br />
|-<br />
! Offset<br />
! Size<br />
! Description<br />
|-<br />
| 0x0<br />
| 0x4<br />
| Sector byte-size<br />
|-<br />
| 0x4<br />
| 0x4<br />
| Cluster byte-size<br />
|-<br />
| 0x8<br />
| 0x4<br />
| Partition capacity in clusters<br />
|-<br />
| 0xC<br />
| 0x4<br />
| Available free space in clusters<br />
|}<br />
<br />
== ProgramInfo ==<br />
{| class="wikitable" border="1"<br />
|-<br />
! Offset<br />
! Size<br />
! Description<br />
|-<br />
| 0x0<br />
| 0x8<br />
| Program ID<br />
|-<br />
| 0x8<br />
| 0x1<br />
| [[Filesystem_services#MediaType|Media Type]]<br />
|-<br />
| 0x9<br />
| 0x7<br />
| Padding<br />
|}<br />
<br />
== ProductInfo ==<br />
{| class="wikitable" border="1"<br />
|-<br />
! Offset<br />
! Size<br />
! Description<br />
|-<br />
| 0x0<br />
| 0x10<br />
| Product Code<br />
|-<br />
| 0x10<br />
| 0x2<br />
| Company Code<br />
|-<br />
| 0x12<br />
| 0x2<br />
| Remaster Version<br />
|}<br />
<br />
== IntegrityVerificationSeed ==<br />
{| class="wikitable" border="1"<br />
|-<br />
! Offset<br />
! Size<br />
! Description<br />
|-<br />
| 0x0<br />
| 0x10<br />
| AES-CBC MAC over a SHA256 hash, which hashes the first 0x110-bytes of the cleartext SEED.<br />
|-<br />
| 0x10<br />
| 0x120<br />
| The [[nand/private/movable.sed]], encrypted with AES-CTR using the above MAC for the counter.<br />
|}<br />
<br />
== ExtSaveDataInfo ==<br />
{| class="wikitable" border="1"<br />
|-<br />
! Offset<br />
! Size<br />
! Description<br />
|-<br />
| 0x0<br />
| 0x1<br />
| [[Filesystem_services#MediaType|Media Type]]<br />
|-<br />
| 0x1<br />
| 0x1<br />
| Unknown<br />
|-<br />
| 0x2<br />
| 0x2<br />
| Reserved<br />
|-<br />
| 0x4<br />
| 0x8<br />
| Save ID<br />
|-<br />
| 0xC<br />
| 0x4<br />
| Reserved<br />
|}<br />
<br />
== SystemSaveDataInfo ==<br />
{| class="wikitable" border="1"<br />
|-<br />
! Offset<br />
! Size<br />
! Description<br />
|-<br />
| 0x0<br />
| 0x1<br />
| [[Filesystem_services#MediaType|Media Type]]<br />
|-<br />
| 0x1<br />
| 0x1<br />
| Unknown<br />
|-<br />
| 0x2<br />
| 0x2<br />
| Reserved<br />
|-<br />
| 0x4<br />
| 0x4<br />
| Save ID<br />
|}<br />
<br />
== SecureValueSlot ==<br />
{| class="wikitable" border="1"<br />
|-<br />
! Value<br />
! Description<br />
|-<br />
| 0x1000<br />
| SD Application<br />
|}<br />
<br />
== CardSpiBaudRate ==<br />
{| class="wikitable" border="1"<br />
|-<br />
! Value<br />
! Description<br />
|-<br />
| 0x0<br />
| 512KHz<br />
|-<br />
| 0x1<br />
| 1MHz<br />
|-<br />
| 0x2<br />
| 2MHz<br />
|-<br />
| 0x3<br />
| 4MHz<br />
|-<br />
| 0x4<br />
| 8MHz<br />
|-<br />
| 0x5<br />
| 16MHz<br />
|}<br />
<br />
== CardSpiBusMode ==<br />
{| class="wikitable" border="1"<br />
|-<br />
! Value<br />
! Description<br />
|-<br />
| 0x0<br />
| 1-bit<br />
|-<br />
| 0x1<br />
| 4-bit<br />
|}<br />
<br />
== SpecialContentType ==<br />
{| class="wikitable" border="1"<br />
|-<br />
! Value<br />
! Description<br />
|-<br />
| 0x1<br />
| Update<br />
|-<br />
| 0x2<br />
| Manual<br />
|-<br />
| 0x3<br />
| DLP Child<br />
|}<br />
<br />
== DeviceMoveContext ==<br />
{| class="wikitable" border="1"<br />
|-<br />
! Offset<br />
! Size<br />
! Description<br />
|-<br />
| 0x0<br />
| 0x10<br />
| IVs<br />
|-<br />
| 0x10<br />
| 0x10<br />
| Encrypt Parameter<br />
|}<br />
<br />
=Errors=<br />
See [[Filesystem_services_PXI]].</div>Mrrraouhttps://www.3dbrew.org/w/index.php?title=Homebrew_Exploits&diff=18320Homebrew Exploits2016-09-29T17:11:20Z<p>Mrrraou: Undo revision 18319 by Thesmgcraft (talk)</p>
<hr />
<div>==Payload==<br />
{| class="wikitable" border="1"<br />
|-<br />
! Works on latest fw<br />
! Name<br />
! Description<br />
! Supported firmwares<br />
|-<br />
| style="background: lightgreen" | Yes<br />
| [https://smealum.github.io/3ds/ *hax payload]<br />
| Booted by all of the below non-sysmodule exploits.<br />
| From '''9.0.0-7''' up to and including '''11.1.0-34'''.<br />
|}<br />
<br />
For the rest of this page, "Supported firmwares" refers to the exploit ''itself'', not whether *hax payload supports it.<br />
<br />
==Standalone Homebrew Launcher Exploits==<br />
The following homebrew exploits can be executed on a previously un-exploited system. ''Please'' see the above Payload section regarding what "Supported firmwares" indicates ''exactly''.<br />
<br />
{| class="wikitable" border="1"<br />
|-<br />
! Works on latest fw<br />
! Name<br />
! Supported firmwares<br />
! Requirements<br />
! Author<br />
! Install<br />
|-<br />
| style="background: salmon" | No<br />
| [[ninjhax|Ninjhax 1.1b]]<br />
| From '''4.0.0-7''' up to and including '''9.2.0-20'''.<br />
| A cartridge or eShop version (JPN-only) of "Cubic Ninja".<br />
| smea<br />
| [http://smealum.net/ninjhax/ Install]<br />
|-<br />
| style="background: lightgreen" | Yes<br />
| [[ninjhax|Ninjhax 2.x]]<br />
| From '''9.0.0-7''' up to and including '''11.1.0-34'''.<br />
| A cartridge or eShop version (JPN-only, not available anymore for purchase) of "Cubic Ninja".<br />
| smea<br />
| [https://smealum.github.io/ninjhax2/ Install]<br />
|-<br />
| style="background: lightgreen" | Yes<br />
| [http://plutooo.github.io/freakyhax/ freakyhax]<br />
| From '''9.0.0-7''' up to and including '''11.1.0-34'''.<br />
| A cartridge or eShop version (USA/EUR/JAP, not available anymore for purchase) of "Freakyform Deluxe".<br />
| plutoo<br />
| [http://plutooo.github.io/freakyhax/ Install]<br />
|-<br />
| style="background: salmon" | No<br />
| [http://plutooo.github.io/smilehax/ smilehax]<br />
| From '''9.0.0-7''' up to and including '''11.0.0-33'''<br />
| SmileBASIC (JPN all versions up to 3.32 excluded, USA 3.31 only)<br />
| plutoo<br />
| [http://plutooo.github.io/smilehax/ Install]<br />
|-<br />
| style="background: salmon" | No<br />
| [http://mrnbayoh.github.io/basicsploit/ BASICSploit]<br />
| From '''9.0.0-7''' up to and including '''11.0.0-33'''<br />
| SmileBASIC (USA all versions)<br />
| MrNbaYoh<br />
| [http://mrnbayoh.github.io/basicsploit/ Install]<br />
|-<br />
| style="background: lightgreen" | Yes<br />
| [[smashbroshax|smashbroshax]] (beaconhax)<br />
| (New 3DS only) From '''9.0.0-X''' up to and including '''11.1.0-34'''.<br />
| Super Smash Bros 3DS (full-game) and a way to broadcast raw wifi beacons. The demo (prior to the updated November 2015 [https://github.com/yellows8/3ds_smashbroshax version]) isn't usable with the *hax payloads. Game-version v1.1.3 fixed the vuln used with this, see the repo for a workaround for that.<br />
| [[User:Yellows8|Yellows8]]<br />
| [https://github.com/yellows8/3ds_smashbroshax Install]<br />
|-<br />
| style="background: salmon" | No<br />
| [[browserhax]]<br />
| From '''9.0.0-2''' to '''11.0.0-33'''<br />
Note that the browser-version-check bypass is only usable prior to [[10.7.0-32]].<br />
| A USA, EUR, JPN, or KOR system.<br />
| [[User:Yellows8|Yellows8]]<br />
| [http://yls8.mtheall.com/3dsbrowserhax.php Install]<br />
|}<br />
<br />
Note that ninjhax 1.x is still not obsolete. Even though ninjhax 2.x can be run on 9.3+, this was made possible (amongst other things) by sacrificing the memory remapping exploit used in ninjhax 1.x (rohax). Therefore, things like JIT engines for emulators can only be supported on ninjhax 1.x. Furthermore, ninjhax 2.x does not run on system versions below 9.0.0-X, while ninjhax 1.x does.<br />
<br />
==Secondary Exploits==<br />
Installation of these exploits requires a previously exploited system to install. After installation, they can be used on their own. ''Please'' see the above Payload section regarding what "Supported firmwares" indicates ''exactly''.<br />
<br />
{| class="wikitable" border="1"<br />
! Works on latest fw<br />
! Name<br />
! Supported firmwares<br />
! Requirements<br />
! Author<br />
! Install<br />
|-<br />
| style="background: salmon" | No<br />
| [[ironhax]]<br />
| From '''9.5.0-X''' up to and including '''10.3.0-X''', for '''X''' up to and including 28.<br />
| A copy of "Ironfall: Invasion" downloaded from eShop before August 11th, 2015. Note the updated version that was released on October 13th, 2015 is not supported.<br />
| smea<br />
| [http://smealum.github.io/3ds/ Install]<br />
|-<br />
| style="background: lightgreen" | Yes<br />
| [http://vegaroxas.github.io/ steelhax]<br />
| From '''9.0.0-X''' up to and including '''11.1.0-X''', for '''X''' up to and including 34.<br />
| A copy of Steel Diver: Sub wars<br />
| Vegaroxas<br />
| [https://github.com/VegaRoXas/vegaroxas.github.io/raw/master/files/steelhax-installer.zip Install]<br />
|-<br />
| style="background: lightgreen" | Yes<br />
| [https://github.com/yellows8/oot3dhax oot3dhax]<br />
| From '''9.0.0-X''' up to and including '''11.1.0-X''', for '''X''' up to and including 34.<br />
| A gamecard or eShop-install of Legend of Zelda: Ocarina of Time 3D. Besides using the installer app, writing raw saveimages with a save dongle for example is another option. Before compression was introduced in the 2016-7-18 release, the size of the *hax payload meant the exploit can't coexist with regular saves on a physical version of the game.<br />
| Yellows8 / smea et al.<br />
| See [https://smealum.github.io/3ds/ here].<br />
|-<br />
| style="background: salmon" | No<br />
| [[menuhax]]<br />
| JPN/USA/EUR: From '''9.0.0-X''' up to and including '''11.0.0-X'''.<br />
KOR: From '''9.6.0-X''' up to and including '''11.0.0-X'''.<br />
| JPN/USA/EUR: Having created [[Home_Menu#Home_Menu_Theme_SD_ExtData|theme extdata]] through opening the official theme selector at least once.<br />
| [[User:Yellows8|Yellows8]]<br />
| [https://github.com/yellows8/3ds_homemenuhax/releases Download]<br />
|-<br />
| style="background: lightgreen" | Yes<br />
| [https://github.com/shinyquagsire23/supermysterychunkhax supermysterychunkhax]<br />
| From '''9.9.0-X''' (USA/JPN) / '''10.2.0-X''' (EUR) up to and including '''11.1.0-X''', for '''X''' up to and including 34.<br />
| A gamecard or eShop-install of Pokémon Super Mystery Dungeon.<br />
| Shiny Quagsire / SALT team<br />
| [https://smd.salthax.org/ Install].<br />
|-<br />
| style="background: salmon" | No, exploit update required.<br />
| [https://github.com/shinyquagsire23/v_hax (v*)hax]<br />
| From '''9.0.0-X''' up to and including '''11.0.0-X''', for '''X''' up to and including 33.<br />
Note that '''9.0.0-X''' is only required for the Homebrew Launcher - the game itself only requires '''2.1.0-X''' for primitive userland code execution.<br />
| A copy of VVVVVV downloaded after March 2012 (v1). The game is not available anymore for purchase.<br />
| Shiny Quagsire / SALT team<br />
| [https://vvvvvv.salthax.org/ Install].<br />
|-<br />
| style="background: salmon" | No, exploit update required.<br />
| [https://github.com/Dazzozo/humblehax humblehax]<br />
| From '''9.0.0-X''' (USA/EUR) up to and including '''11.0.0-X''', for '''X''' up to and including 33.<br />
| An eShop-install of Citizens of Earth (either v1 or v2), featured in the Humble "Friends of Nintendo" Bundle.<br />
| Dazzozo / SALT team<br />
| [https://citizens.salthax.org/ Install].<br />
|-<br />
| style="background: lightgreen" | Yes<br />
| [http://mrnbayoh.github.io/basehaxx/ basehaxx]<br />
| From '''9.0.0-X''' up to and including '''11.1.0-X''', for '''X''' up to and including 34.<br />
| A gamecard or eShop-install of Pokémon Omega Ruby / Alpha Sapphire.<br />
| MrNbaYoh<br />
| [http://mrnbayoh.github.io/basehaxx/ install]<br />
|-<br />
| style="background: lightgreen" | Yes<br />
| [https://github.com/yellows8/stickerhax stickerhax]<br />
| From '''9.0.0-X''' up to and including '''11.1.0-X'''.<br />
| A gamecard or eShop-install of Paper Mario: Sticker Star.<br />
| [[User:Yellows8|Yellows8]]<br />
| [https://github.com/yellows8/stickerhax Here]<br />
|}<br />
<br />
==Exploits without Homebrew Launcher (Not recommended)==<br />
<br />
<u>'''Warning:'''</u> The following exploits can run code, but are missing a 3DSX launcher. They cannot launch any homebrew in the 3DSX format.<br />
<br />
{| class="wikitable" border="1"<br />
|-<br />
! Works on latest fw<br />
! Name<br />
! Supported firmwares<br />
! Requirements<br />
! Author<br />
! Install<br />
|-<br />
| style="background: salmon" | No<br />
| [[browserhax]] (Without the loader in the 3ds_browserhax_common repo)<br />
| (Old3DS) From '''5.0.0-2''' to '''11.0.0-33''' (Pre-v5.0 is supported for some versions if you manually modify the source)<br />
<br />
(New3DS) From '''9.0.0-20''' to '''11.0.0-33'''<br />
<br />
Note that the browser-version-check bypass is only usable prior to [[10.7.0-32]].<br />
| An USA, EUR, or JPN system.<br />
| [[User:Yellows8|Yellows8]]<br />
| [[browserhax|Install]]<br />
|-<br />
| style="background: salmon" | No<br />
| Ninjhax (with specialized payloads)<br />
| Up to '''9.2.0-20'''?<br />
| <br />
| smea + independent developers<br />
| N/A<br />
|}<br />
<br />
==Previous Exploits==<br />
<u>'''Warning:'''</u> These exploits '''do not work'''. They are exploits which no longer function at all, regardless of software or firmware revision.<br />
{| class="wikitable" border="1"<br />
! Works on latest fw<br />
! Name<br />
! Supported firmwares<br />
! Requirements<br />
! Author<br />
! Install<br />
|-<br />
| style="background: salmon" | No<br />
| [[tubehax|Tubehax]]<br />
| None. '''Was''': From '''9.0.0-X''' up to and including '''10.1.0-X''', for '''X''' up to and including 27.<br />
| The YouTube application and an Internet connection. As of October 15, 2015, this is no longer usable due to an update being released which fixes the vuln used by tubehax + app update being forced (see [[YouTube|here]]).<br />
| smea<br />
| [http://smealum.github.io/3ds/ Install]<br />
|}<br />
<br />
==Other Homebrew Loaders==<br />
The [https://github.com/yellows8/hblauncher_loader hblauncher_loader] title can be used when running under modded-FIRM which allows running unsigned titles, to boot the *hax payloads.<br />
<br />
==Sysmodule Exploits==<br />
This section is for system-module exploits, which can be run from the *hax payloads.<br />
<br />
{| class="wikitable" border="1"<br />
! Works on latest fw<br />
! Name<br />
! Supported firmwares<br />
! Requirements<br />
! Author<br />
|-<br />
| style="background: lightgreen" | Yes, that's not the intended default use however.<br />
| [https://github.com/yellows8/ctr-httpwn/releases ctr-httpwn]<br />
| From '''9.6.0-X''' up to and including '''11.1.0-X'''.<br />
| None<br />
| [[User:Yellows8|Yellows8]]<br />
|}<br />
<br />
==WebKit vuln testing==<br />
See [https://github.com/yellows8/3ds_browserhax_common/issues/28 here].</div>Mrrraouhttps://www.3dbrew.org/w/index.php?title=3DS_System_Flaws&diff=183073DS System Flaws2016-09-27T16:37:33Z<p>Mrrraou: </p>
<hr />
<div>Exploits are used to execute unofficial code (homebrew) on the Nintendo 3DS. This page is a list of publicly known system flaws, for userland applications/applets flaws see [[3DS_Userland_Flaws|here]].<br />
<br />
=Stale / Rejected Efforts=<br />
* Neimod has been working on a RAM dumping setup for a little while now. He's de-soldered the 3DS's RAM chip and hooked it and the RAM pinouts on the 3DS' PCB up to a custom RAM dumping setup. A while ago he published photos showing his setup to be working quite well, with the 3DS successfully booting up. However, his flickr stream is now private along with most of his work.<br />
<br />
* Someone (who will remain unnamed) has released CFW and CIA installers, all of which is copied from the work of others, or copyrighted material.<br />
<br />
==Tips and info==<br />
The 3DS uses the XN feature of the ARM11 processor. There's no official way from applications to enable executable permission for memory containing arbitrary unsigned code(there's a [[SVC]] for this, but only [[RO_Services|RO-module]] has access to it). An usable userland exploit would still be useful: you could only do return-oriented-programming with it initially. From ROP one could then exploit system flaw(s), see below.<br />
<br />
SD card [[extdata]] and SD savegames can be attacked, for consoles where the console-unique [[Nand/private/movable.sed|movable.sed]] was dumped(accessing SD data is far easier by running code on the target 3DS however).<br />
<br />
=System flaws=<br />
== Hardware ==<br />
{| class="wikitable" border="1"<br />
! Summary<br />
! Description<br />
! Fixed with hardware model/revision<br />
! Newest hardware model/revision this flaw was checked for<br />
! Timeframe this was discovered<br />
! Discovered by<br />
|-<br />
| ARM9/ARM11 bootrom vectors point at unitialized RAM<br />
| ARM9's and ARM11's exception vectors are hardcoded to point at the CPU's internal memory (0x08000000 region for ARM9, AXIWRAM for ARM11). While the bootrom does set them up to point to an endless loop at some point during boot, it does not do so immediately. As such, a carefully-timed fault injection (via hardware) to trigger an exception (such as an invalid instruction) will cause execution to fall into ARM9 RAM. <br />
Since RAM isn't cleared on boot (see below), one can immediately start execution of their own code here to dump bootrom, OTP, etc.<br />
The ARM9 bootrom does the following at reset: reset vector branches to another instruction, then branches to bootrom+0x8000. Hence, there's no way to know for certain when exactly the ARM9 exception-vector data stored in memory gets initialized.<br />
<br />
This requires *very* *precise* timing for triggering the hardware fault: it's unknown if anyone actually exploited this successfully at the time of writing(the one who attempted+discovered it *originally* as listed in this wiki section hasn't).<br />
| None: all available 3DS models at the time of writing have the exact same ARM9/ARM11 bootrom for the unprotected areas.<br />
| New3DS<br />
| End of February 2014<br />
| [[User:Derrek|derrek]], WulfyStylez (May 2015) independently<br />
|-<br />
| Missing AES key clearing<br />
| The hardware AES engine does not clear keys when doing a hard reset/reboot.<br />
| None<br />
| New3DS<br />
| August 2014<br />
| Mathieulh/Others<br />
|-<br />
| No RAM clearing on reboots<br />
| On an MCU-triggered reboot all RAM including FCRAM/ARM9 memory/AXIWRAM/VRAM keeps its contents.<br />
| None<br />
| New3DS<br />
| March 2014<br />
| [[User:Derrek|derrek]]<br />
|-<br />
| 32bits of actual console-unique TWLNAND keydata<br />
| On retail the 8-bytes at ARM9 address [[Memory_layout|0x01FFB808]] are XORed with hard-coded data, to generate the TWL console-unique keys, including TWLNAND. On Old3DS the high u32 is always 0x0, while on New3DS that u32 is always 0x2. On top of this, the lower u32's highest bit is always ORed. only 31 bits of the TWL console-unique keydata / TWL consoleID are actually console-unique.<br />
This allows one to easily bruteforce the TWL console-unique keydata with *just* data from TWLNAND. On DSi the actual console-unique data for key generation is 8-bytes(all bytes actually set).<br />
| None<br />
| New3DS<br />
| 2012?<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| DSi / 3DS-TWL key-generator<br />
| After using the key generator to generate the normal-key, you could overwrite parts of the normal-key with your own data and then recover the key-generator output by comparing the new crypto output with the original crypto output. From the normal-key outputs, you could deduce the TWL key-generator function.<br />
This applies to the keyX/keyY too.<br />
<br />
This attack does not work for the 3DS key-generator because keyslots 0-3 are only for TWL keys.<br />
| None<br />
| New3DS<br />
| 2011<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| 3DS key-generator<br />
| The algorithm for generating the normal-keys for keyslots is cryptographically weak. As a result, it is easily susceptible to differential cryptanalysis if the normal-key corresponding to any scrambler-generated keyslot is discovered.<br />
<br />
Several such pairs of matching normal-keys and KeyY values were found, leading to deducing the key-generator function.<br />
| None<br />
| New3DS<br />
| February 2015<br />
| [[User:Yellows8|Yellows8]], [[User:Plutooo|plutoo]]<br />
|-<br />
| FIRM partitions known-plaintext<br />
| The [[Flash_Filesystem|FIRM partitions]] are encrypted with AES-CTR without a MAC. Since this works by XOR'ing data with a static (per-console in this case) keystream, one can deduce the keystream of a portion of each FIRM partition if they have the actual FIRM binary stored in it.<br />
<br />
This can be paired with many exploits. For example, it allows minor FIRM downgrades (i.e. 10.4 to 9.6 or 9.5 to 9.4, but not 9.6 to 9.5).<br />
<br />
This can be somewhat addressed by having a FIRM header skip over previously used section offsets, but this would just air-gap newer FIRMs without fixing the core bug. This can also only be done a limited number of times due to the size of FIRM versus the size of the partitions.<br />
| None<br />
| New3DS<br />
| <br />
| Everyone<br />
|}<br />
<br />
== ARM9 software ==<br />
=== arm9loader ===<br />
{| class="wikitable" border="1"<br />
|-<br />
! Summary<br />
! Description<br />
! Successful exploitation result<br />
! Fixed in [[FIRM]] system version<br />
! Last [[FIRM]] system version this flaw was checked for<br />
! Timeframe this was discovered<br />
! Public disclosure timeframe<br />
! Discovered by<br />
|-<br />
| Rearrangable keys in the NAND keystore<br />
| Due to the keystore being encrypted with AES-ECB, one can rearrange blocks and still have the NAND keystore decrypt in a deterministic way. Combining this with the arm9loaderhax and uncleared hash keydata vulnerabilities, one can achieve arm9loaderhax without downgrading to a system version that exposes the OTP data, or using a hardware method. The NAND keystore must be encrypted with console-unique data; therefore, this is not achievable on Old 3DS or 2DS.<br />
| arm9loaderhax achieveable with no extra hardware and without downgrading to a system version which exposes the OTP.<br />
| None<br />
| [[11.1.0-34|11.1.0-X]]<br />
| Early 2016<br />
| 27 September 2016<br />
| Everyone, #Cakey on Freenode, Myria, [[User:Dark samus|dark_samus]]; mathieulh (independently); [[User:Plutooo|plutoo]] (independently)<br />
|-<br />
| Uncleared OTP hash keydata in console-unique 0x11 key-generation<br />
| Kernel9Loader does not clear the [[SHA_Registers#SHA_HASH|SHA_HASH register]] after use. As a result, the data stored here as K9L hands over to Kernel9 is the hash of [[OTP_Registers|OTP data]] used to seed the [[FIRM#New_3DS_FIRM|console-unique NAND keystore decryption key]] set on keyslot 0x11.<br />
<br />
Retrieving this keydata and the [[Flash_Filesystem#0x12C00|NAND keystore]] of the same device allows calculating the decrypted New3DS NAND keystore (non-unique, common to all New3DS units), which contains AES normal keys, also set on keyslot 0x11, which are then used to derive all current [[AES_Registers#Keyslots|New3DS-only AES keyXs]] including the newer batch introduced in [[9.6.0-24#arm9loader|9.6.0-X]]. From there, it is trivial to perform the same key derivation in order to initialize those keys on any system version, and even on Old3DS.<br />
<br />
This can be performed by exploiting the "arm9loaderhax" vulnerability to obtain post-K9L code execution after an MCU reboot (the bootrom section-loading fail is not relevant here, this attack was performed without OTP data by brute-forcing keys), and using this to dump the SHA_HASH register. This attack works on any FIRM version shipping a vulnerable version of K9L, whereas OTP dumping required a boot of <[[3.0.0-6|3.0.0-X]].<br />
<br />
This attack results in obtaining the entire (0x200-bytes) NAND keystore - it was confirmed at a later date that this keystore is encrypted with the same key (by comparing the decrypted data from multiple units), and therefore using another key in this store will not remedy the issue as all keys are known (i.e. later, unused keys decrypt to the same 0x200-bytes constant with the same OTP hash). Later keys could have been encrypted differently but this is not the case. As a result of this, it is not possible for Nintendo to use K9L again in its current format for its intended purpose, though this was not news from the moment people dumped a New3DS OTP.<br />
| Derivation of all New3DS keys generated via the NAND keystore (0x1B "Secure4" etc.)<br />
| None<br />
| [[11.1.0-34|11.1.0-X]]<br />
| ~April 2015, implemented in May 2015<br />
| 13 January 2016<br />
| [[User:WulfyStylez|WulfyStylez]], [[User:Dazzozo|Dazzozo]], [[User:Shinyquagsire23|shinyquagsire23]] (complimentary + implemented), [[User:Plutooo|plutoo]], Normmatt (discovered independently)<br />
|-<br />
| enhanced-arm9loaderhax<br />
| See the 32c3 3ds talk.<br />
Since this is a combination of a trick with the arm9-bootrom + arm9loaderhax, and since you have to manually write FIRM to the firm0/firm1 NAND partitions, this can't be completely fixed. Any system with existing ARM9 code execution and an OTP/OTP hash dump can exploit this. Additionally, by using the FIRM partition known-plaintext bug and bruteforcing the second entry in the keystore, this can currently be exploited on all New3DS systems without any other prerequisite hacks.<br />
| arm9loaderhax which automatically occurs at hard-boot.<br />
| See arm9loaderhax / description.<br />
| See arm9loaderhax / description.<br />
| Theorized around mid July, 2015. Later implemented+tested by [[User:Plutooo|plutoo]] and derrek.<br />
| 32c3 3ds talk (December 27, 2015)<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| Missing verification-block for the 9.6 keys (arm9loaderhax)<br />
| Starting with [[9.6.0-24|9.6.0-X]] a new set of NAND-based keys were introduced. However, no verification block was added to verify that the new key read from NAND is correct. This was technically an issue from [[9.5.0-22|9.5.0-X]] with the original sector+0 keydata, however the below is only possible with [[9.6.0-24|9.6.0-X]] since keyslots 0x15 and 0x16 are generated from different 0x11 keyXs.<br />
<br />
Writing an incorrect key to NAND will cause arm9loader to decrypt the ARM9 kernel as garbage and then jump to it.<br />
<br />
This allows an hardware-based attack where you can boot into an older exploited firmware, fill all memory with NOP sleds/jump-instructions, and then reboot into executing garbage. By automating this process with various input keydata, eventually you'll find some garbage that jumps to your code.<br />
<br />
This gives very early ARM9 code execution (pre-ARM9 kernel). As such, it is possible to dump RSA keyslots with this and calculate the 6.x [[Savegames#6.0.0-11_Savegame_keyY|save]], and 7.x [[NCCH]] keys. This cannot be used to recover keys initialized by arm9loader itself. This is due to it wiping the area used for its stack during NAND sector decryption and keyslot init. <br />
<br />
Due to FIRMs on both Old and New 3DS using the same RSA data, this can be exploited on Old3DS as well, but only if one already has the actual plaintext normalkey from New3DS NAND sector 0x96 offset-0 and has dumped the OTP area of the Old3DS.<br />
| Recovery of 6.x [[Savegames#6.0.0-11_Savegame_keyY|save key]]/7.x [[NCCH]] key<br />
| None<br />
| [[11.1.0-34|11.1.0-X]]<br />
| March, 2015<br />
| <br />
| [[User:Plutooo|plutoo]]<br />
|-<br />
| Uncleared New3DS keyslot 0x11<br />
| Originally the New3DS [[FIRM]] arm9bin loader only cleared keyslot 0x11 when it gets executed at firmlaunch. This was fixed with [[9.5.0-22|9.5.0-X]] by completely clearing keyslot 0x11 immediately after the loader finishes using keyslot 0x11.<br />
This means that any ARM9 code that can execute before the loader clears the keyslot at firmlaunch(including firmlaunch-hax) can get access to the uncleared keyslot 0x11, which then allows one to generate all <=v9.5 New3DS keyXs which are generated by keyslot 0x11.<br />
<br />
Therefore, to completely fix this the loader would have to generate more keys using different keyslot 0x11 keydata. This was done with [[9.6.0-24|9.6.0-X]].<br />
| New3DS keyXs generation<br />
| Mostly fixed with [[9.5.0-22|9.5.0-X]], completely fixed with new keys with [[9.6.0-24|9.6.0-X]].<br />
| <br />
| February 3, 2015 (one day after [[9.5.0-22|9.5.0-X]] release)<br />
| <br />
| [[User:Yellows8|Yellows8]]<br />
|}<br />
<br />
=== Process9 ===<br />
{| class="wikitable" border="1"<br />
|-<br />
! Summary<br />
! Description<br />
! Successful exploitation result<br />
! Fixed in [[FIRM]] system version<br />
! Last [[FIRM]] system version this flaw was checked for<br />
! Timeframe this was discovered<br />
! Public disclosure timeframe<br />
! Discovered by<br />
|-<br />
| Leak of normal-key matching a key-scrambler key<br />
| New 3DS firmware versions [[8.1.0-0 New3DS|8.1.0]] through [[9.2.0-20|9.2.0]] set the encryption key for [[Amiibo]] data using a hardcoded normal-key in Process9. In firmware [[9.3.0-21|9.3.0]], Nintendo "fixed" this by using the key scrambler instead, by calculating the keyY value for keyslot 0x39 that results in the same normal-key, then hardcoding that keyY into Process9.<br />
<br />
Nintendo's fix is actually the problem: Nintendo revealed the normal-key matching an unknown keyX and a known keyY. Combined with the key scrambler using an insecure scrambling algorithm (see "Hardware" above), the key scrambler function could be deduced.<br />
| Deducing the keyX for keyslot 0x39 and the key scrambler algorithm<br />
| New 3DS [[9.3.0-21|9.3.0-X]], sort of<br />
| [[10.0.0-27|10.0.0-X]]<br />
| Sometime in 2015 after the hardware key-generator was broken.<br />
| 32c3 3ds talk (December 27, 2015)<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| Leak of normal-key matching a key-generator key<br />
| During the 3DS' development (June/July 2010) Nintendo added support installing encrypted content ([[CIA]]). Common-key index1 was intended to be a [[AES|hardware generated key]]. However while they added code to generate the key in hardware, they forgot to remove the normal-key for index1 (used elsewhere, likely old debug code). Nintendo later removed the normal key sometime before the first non-prototype firmware release.<br />
<br />
<br />
Knowing the keyY and the normal-key for common-key index1, the devkit key-generator algorithm can be deduced (see "Hardware" above). Additionally the remaining devkit common-keys can be generated once the common-key keyX is recovered.<br />
<br />
Note the devkit key-generator was discovered to be the same as the retail key-generator.<br />
| Deducing the keyX for keyslot 0x3D and hardware key-generator algorithm. Generate remaining devkit common-keys.<br />
| pre-[[1.0.0-0|1.0.0-X]]<br />
| <br />
| Shortly after the key-generator was revealed to be flawed at the 32c3 3ds talk<br />
| January 20, 2016<br />
| [[User:Jakcron|jakcron]]<br />
|-<br />
| ntrcardhax<br />
| <br />
| ARM9 code execution<br />
| 10.4.0-29<br />
| <br />
| March 2015<br />
| 32c3 3ds talk (December 27, 2015)<br />
| [[User:Plutooo|plutoo]]<br />
|-<br />
| Title downgrading via [[Application_Manager_Services|AM]]([[Application_Manager_Services_PXI|PXI]])<br />
| When a title is *already* installed, Process9 will compare the installed title-version with the title-version being installed. When the one being installed is older, Process9 would return an error.<br />
<br />
However, this can be bypassed by just deleting the title first via the service command(s) for that: with the title removed from the [[Title_Database]], Process9 can't compare the input title-version with anything. Hence, titles can be downgraded this way.<br />
<br />
[[11.0.0-33|11.0.0-X]] fixed this for key system titles (MSET, Home Menu, spider, ErrDisp, SKATER, NATIVE_FIRM, and every retail system module), by checking the version of the title to install against a hard-coded list of (titleID, minimumVersionRequired) pairs.<br />
| Bypassing title version check at installation, which then allows downgrading any title.<br />
| [[11.0.0-33|11.0.0-X]], for key system titles.<br />
| NATIVE_FIRM / AM-sysmodule [[11.0.0-33|11.0.0-X]]<br />
| ?<br />
| <br />
| ?<br />
|-<br />
| FAT FS code null-deref<br />
| When FSFile:Read is used with a file which is corrupted on a FAT filesystem(in particular SD), Process9 can crash. This particular crash is caused by a function returning NULL instead of an actual ptr due to an error. The caller of that function doesn't check for NULL which then triggers a read based at NULL.<br />
<br />
Sample "fsck.vfat -n -v -V <fat image backup>" output for the above crash:<br />
<br />
<pre>...<br />
Starting check/repair pass.<br />
<FilePath0> and<br />
<FilePath1><br />
share clusters.<br />
Truncating second to 3375104 bytes.<br />
<FilePath1><br />
File size is 2787392 bytes, cluster chain length is 16384 bytes.<br />
Truncating file to 16384 bytes.<br />
Checking for unused clusters.<br />
Reclaimed 1 unused cluster (16384 bytes).<br />
Checking free cluster summary.<br />
Free cluster summary wrong (1404490 vs. really 1404491)<br />
Auto-correcting.<br />
Starting verification pass.<br />
Checking for unused clusters.<br />
Leaving filesystem unchanged.</pre><br />
| Useless null-based-read<br />
| None<br />
| [[9.6.0-24|9.6.0-X]]<br />
| July 8-9, 2015<br />
| <br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| RSA signature padding checks<br />
| The TWL_FIRM RSA sig padding check code used for all TWL RSA sig-checks has issues, see [[FIRM|here]].<br />
The main 3DS RSA padding check code(non-certificate, including NATIVE_FIRM) uses the function used with the above to extract more padding + the actual hash from the additional padding. This isn't really a problem here because there's proper padding check code which is executed prior to this.<br />
| <br />
| None<br />
| [[9.5.0-22|9.5.0-X]]<br />
| March 2015<br />
| <br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[AMPXI:ValidateDSiWareSectionMAC]] [[AES_Registers|AES]] keyslot reuse<br />
| When the input DSiWare section index is higher than <max number of DSiWare sections supported by this FIRM>, Process9 uses keyid 0x40 for calculating the AESMAC, which translates to keyslot 0x40. The result is that the keyslot is left at whatever was already selected before, since the AES selectkeyslot code will immediately return when keyslot is >=0x40. However, actually exploiting this is difficult: the calculated AESMAC is never returned, this command just compares the calculated AESMAC with the input AESMAC(result-code depends on whether the AESMACs match). It's unknown whether a timing attack would work with this.<br />
This is basically a different form of the pxips9 keyslot vuln, except with AESMAC etc.<br />
| See description.<br />
| None<br />
| [[11.1.0-34|11.1.0-X]]<br />
| March 15, 2015<br />
| December 29, 2015<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| pxips9 [[AES_Registers|AES]] keyslot reuse<br />
| This requires access to the [[Process_Services|ps:ps]]/pxi:ps9 services. One way to get access to this would be snshax on system-version <=10.1.0-X(see 32c3 3ds talk).<br />
When an invalid key-type value is passed to any of the PS commands, Process9 will try to select keyslot 0x40. That aesengine_setkeyslot() code will then immediately return due to the invalid keyslot value. Since that function doesn't return any errors, Process9 will just continue to do crypto with whatever AES keyslot was selected before the PS command was sent.<br />
| Reusing the previously used keyslot, for crypto with PS.<br />
| None<br />
| [[11.1.0-34|11.1.0-X]]<br />
| Roughly the same time(same day?) as firmlaunch-hax.<br />
| December 29, 2015<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| firmlaunch-hax: FIRM header ToCToU<br />
| This can't be exploited from ARM11 userland.<br />
During [[FIRM]] launch, the only FIRM header the ARM9 uses at all is stored in FCRAM, this is 0x200-bytes(the actual used FIRM RSA signature is read to the Process9 stack however). The ARM9 doesn't expect "anything" besides the ARM9 to access this data.<br />
With [[9.5.0-22]] the address of this FIRM header was changed from a FCRAM address, to ARM9-only address 0x01fffc00.<br />
| ARM9 code execution<br />
| [[9.5.0-22]]<br />
| <br />
| 2012, 3 days after [[User:Yellows8|Yellows8]] started Process9 code RE.<br />
| <br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| Uninitialized data output for (PXI) command replies<br />
| PXI commands for various services(including some [[Filesystem_services_PXI|here]] and many others) can write uninitialized data (like from ARM registers) to the command reply. This happens with stubbed commands, but this can also occur with certain commands when returning an error.<br />
Certain ARM11 service commands have this same issue as well.<br />
| <br />
| None<br />
| [[9.3.0-21|9.3.0-X]]<br />
| ?<br />
| <br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[Filesystem_services_PXI|FSPXI]] OpenArchive SD permissions<br />
| Process9 does not use the exheader ARM9 access-mount permission flag for SD at all.<br />
This would mean ARM11-kernelmode code / fs-module itself could directly use FSPXI to access SD card without ARM9 checking for SD access, but this is rather useless since a process is usually running with SD access(Home Menu for example) anyway.<br />
| <br />
| None<br />
| [[9.3.0-21|9.3.0-X]]<br />
| 2012<br />
| <br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[AMPXI:ExportDSiWare]] export path<br />
| Process9 allocates memory on Process9 heap for the export path then verifies that the actual allocated size matches the input size. Then Process9 copies the input path from FCRAM to this buffer, and uses it with the Process9 FS openfile code, which use paths in the form of "<mountpoint>:/<path>".<br />
Process9 does not check the contents of this path at all before passing it to the FS code, besides writing a NUL-terminator to the end of the buffer.<br />
| Exporting of DSiWare to arbitrary Process9 file-paths, such as "nand:/<path>" etc. This isn't really useful since the data which gets written can't be controlled.<br />
| None<br />
| [[9.5.0-22]]<br />
| April 2013<br />
| <br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[DSiWare_Exports]] [[CTCert]] verification<br />
| Just like DSi originally did, 3DS verifies the APCert for DSiWare on SD with the CTCert also in the DSiWare .bin. On DSi this was fixed with with system-version 1.4.2 by verifying with the actual console-unique cert instead(stored in NAND), while on 3DS it's still not(?) fixed.<br />
On 3DS however this is rather useless, due to the entire DSiWare .bin being encrypted with the console-unique movable.sed keyY.<br />
| When the movable.sed keyY for the target 3DS is known and the target 3DS CTCert private-key is unknown, importing of modified DSiWare SD .bin files.<br />
| Unknown, probably none.<br />
| ?<br />
| April 2013<br />
| <br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[Gamecard_Services_PXI]] unchecked REG_CTRCARDCNT transfer-size<br />
| The u8 REG_CTRCARDCNT transfer-size parameter for the [[Gamecard_Services_PXI]] read/write CTRCARD commands is used as an index for an array of u16 values. Before [[5.0.0-11|5.0.0-X]] this u8 value wasn't checked, thus out-of-bounds reads could be triggered(which is rather useless in this case).<br />
| Out-of-bounds read for a value which gets written to a register.<br />
| [[5.0.0-11|5.0.0-X]]<br />
| <br />
| 2013?<br />
| <br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[PXI_Registers|PXI]] cmdbuf buffer overrun<br />
| The Process9 code responsible [[PXI_Registers|PXI]] communications didn't verify the size of the incoming command before writing it to a C++ member variable. <br />
| Probably ARM9 code execution<br />
| [[5.0.0-11|5.0.0-11]]<br />
| <br />
| March 2015, original timeframe if any unknown<br />
| <br />
| [[User:Plutooo|plutoo]]/[[User:Yellows8|Yellows8]]/maybe others(?)<br />
|-<br />
| [[Application_Manager_Services_PXI|PXIAM]] command 0x003D0108(See also [[Application_Manager_Services|this]])<br />
| When handling this command, Process9 allocates a 0x2800-byte heap buffer, then copies the 4 FCRAM input buffers to this heap buffer without checking the sizes at all(only the buffers with non-zero sizes are copied). Starting with [[5.0.0-11|5.0.0-X]], the total combined size of the input data must be <=0x2800.<br />
| ARM9 code execution<br />
| [[5.0.0-11|5.0.0-X]]<br />
| <br />
| May 2013<br />
| <br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[Process_Services_PXI|PS RSA]] commands buffer overflows<br />
| pxips9 cmd1(not accessible via ps:ps) and VerifyRsaSha256: unchecked copy to a buffer in Process9's .bss, from the input FCRAM buffer. The buffer is located before the pxi cmdhandler threads' stacks. SignRsaSha256 also has a buf overflow, but this isn't exploitable.<br />
The buffer for this is the buffer for the signature data. With v5.0, the signature buffer was moved to stack, with a check for the signature data size. When the signature data size is too large, Process9 uses [[SVC|svcBreak]].<br />
| ARM9 code execution<br />
| [[5.0.0-11|5.0.0-X]]<br />
| <br />
| 2012<br />
| <br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[PXI_Registers|PXI]] pxi_id bad check<br />
| The Process9 code responsible for [[PXI_Registers|PXI]] communications read pxi_id as a signed char. There were two flaws:<br />
* They used it as index to a lookup-table without checking the value at all.<br />
* Another function verified that pxi_id < 7, allowing negative values to pass the check. This would also cause an out-of-range table-lookup.<br />
| Maybe ARM9 code execution<br />
| [[3.0.0-5|3.0.0-5]]<br />
|<br />
| March 2015, originally 2012 for the first issue at least<br />
| <br />
| [[User:Plutooo|plutoo]], [[User:Yellows8|Yellows8]], maybe others(?)<br />
|}<br />
<br />
=== Kernel9 ===<br />
{| class="wikitable" border="1"<br />
|-<br />
! Summary<br />
! Description<br />
! Successful exploitation result<br />
! Fixed in [[FIRM]] system version<br />
! Last [[FIRM]] system version this flaw was checked for<br />
! Timeframe this was discovered<br />
! Discovered by<br />
|-<br />
| [[CONFIG Registers#CFG_SYSPROT9|CFG_SYSPROT9]] bit1 not set by Kernel9<br />
| Old versions of Kernel9 never set bit1 of [[CONFIG Registers#CFG_SYSPROT9|CFG_SYSPROT9]]. This leaves the [[OTP Registers|0x10012000]]-region unprotected (this region should be locked early during boot!). Since it's never locked, you can dump it once you get ARM9 code execution.<br />
<br />
From [[3.0.0-5|3.0.0-X]] this was fixed by setting the bit in Kernel9 after poking some registers in that region. On New3DS arm9loader sets this bit instead of Kernel9, which is exploitable through a hardware + software vulnerability (see arm9loaderhax / description).<br />
<br />
This flaw resurged when it gained a new practical use: retrieving the OTP data for a New3DS console in order to decrypt the key data used in arm9loader (see enhanced-arm9loaderhax / description). This was performed by downgrading to a vulnerable system version. By accounting for differences in CTR-NAND crypto (0x05 -> 0x04, see partition encryption types [[Flash_Filesystem#NAND_structure|here]]), it is possible to boot a New3DS using Old3DS firmware 1.0-2.X and an Old3DS [[NCSD#NCSD_header|NCSD Header]] to retrieve the required OTP data using this flaw.<br />
| Dumping of the [[OTP Registers|OTP]] area<br />
| [[3.0.0-5|3.0.0-X]]<br />
|<br />
| February 2015<br />
| [[User:Plutooo|plutoo]], Normmatt independently<br />
|}<br />
<br />
== ARM11 software ==<br />
=== Kernel11 ===<br />
{| class="wikitable" border="1"<br />
|-<br />
! Summary<br />
! Description<br />
! Successful exploitation result<br />
! Fixed in [[FIRM]] system version<br />
! Last [[FIRM]] system version this flaw was checked for<br />
! Timeframe this was discovered<br />
! Discovered by<br />
|-<br />
| [[SVC]] table too small<br />
| The table of function pointers for SVC's only contains entries up to 0x7D, but the biggest allowed SVC for the table is 0x7F. Thus, executing SVC7E or SVC7F would make the SVC-handler read after the buffer, and interpret some ARM instructions as function pointers.<br />
<br />
However, this would require patching the kernel .text or modifying SVC-access-control. Even if you could get these to execute, they would still jump to memory that isn't mapped as executable.<br />
| <br />
| None<br />
| [[11.1.0-34|11.1.0-X]]<br />
| 2012<br />
| Everyone<br />
|-<br />
| [[SVC|svcBackdoor (0x7B)]]<br />
| This backdoor allows executing SVC-mode code at the user-specified code-address. This is used by Process9, using this on the ARM11 (with NATIVE_FIRM) required patching the kernel .text or modifying SVC-access-control.<br />
| See description<br />
| [[11.0.0-33|11.0.0-X]] (deleted)<br />
| <br />
|<br />
| Everyone<br />
|-<br />
| [[Memory_layout#ARM11_Detailed_virtual_memory_map|0xEFF00000]] / 0xDFF00000 ARM11 kernel virtual-memory<br />
| The ARM11 kernel-mode 0xEFF00000/0xDFF00000 virtual-memory(size 0x100000) is mapped to phys-mem 0x1FF00000(entire DSP-mem + entire AXIWRAM), with permissions RW-. This is used during ARM11 kernel startup for loading the FIRM-modules from the FIRM section located in DSP-mem, this never seems to be used after that, however. This is never unmapped either.<br />
| <br />
| None<br />
| [[11.1.0-34|11.1.0-X]]<br />
| <br />
| <br />
|-<br />
| memchunkhax2.1<br />
| Nintendo's fix for memchunkhax2 in [[10.4.0-29|10.4.0-X]] did not fix the GPU case: one may cause the requisite ToCToU race using gspwn, bypassing the new validation.<br />
derrek's original 32c3 presentation for memchunkhax2 commented that a GPU-based attack was possible, but would be difficult. However, memchunkhax2.1 showed that it was possible to do fairly reliably.<br />
| ARM11 kernel code execution<br />
| None<br />
| [[10.4.0-29|10.4.0-X]]<br />
|<br />
| derrek, aliaspider<br />
|-<br />
| memchunkhax2<br />
| <br />
| ARM11 kernel code execution<br />
| [[10.4.0-29|10.4.0-X]] (partially)<br />
| [[10.4.0-29|10.4.0-X]]<br />
|<br />
| derrek<br />
|-<br />
| heaphax<br />
| Can change the size of free memchunk structures stored in FCRAM using DMA, which leads to the ability to allocate memory chunks over already-allocated memory. This can be used in the SYSTEM region to allocate RW memory over any part of the NS system module, which is enough to take it over.<br />
| Code execution with access to all of NS's privileges. (including downgrading) Code execution within any applet.<br />
| [[11.0.0-33|11.0.0-X]], via the new [[Memory_Management#MemoryBlockHeader|memchunkhdr]] MAC which prevents modifying memchunkhdr data with DMA.<br />
| [[11.0.0-33|11.0.0-X]]<br />
| April 2015 ?<br />
| smea<br />
|-<br />
| snshax<br />
| Can force creation of Safe NS process into gspwn-able memory, allowing for takeover.<br />
| Code execution with access to all of NS's privileges. (including downgrading)<br />
| [[10.1.0-27|10.1.0-X]]<br />
| [[10.1.0-27|10.1.0-X]]<br />
| April 2015 ?<br />
| smea<br />
|-<br />
| AffinityMask/processorid validation<br />
| With [[10.0.0-27|10.0.0-X]] the following functions were updated: svcGetThreadAffinityMask, svcGetProcessAffinityMask, svcSetProcessAffinityMask, and svcCreateThread. The code changes for all but svcCreateThread are identical.<br />
The original code with the first 3 did the following: <br />
* if(u32_processorcount > ~0x80000001)return 0xe0e01bfd;<br />
* if(s32_processorcount > <total_cores>)return 0xd8e007fd;<br />
The following code replaced the above:<br />
* if(u32_processorcount >= <total_cores+1>)return 0xd8e007fd;<br />
In theory the latter should catch everything that the former did, so it's unknown if this was really a security issue.<br />
<br />
The svcCreateThread changes with [[10.0.0-27|10.0.0-X]] definitely did fix a security issue.<br />
* Original code: "if(s32_processorid > <total_cores>)return 0xd8e007fd;"<br />
* New code: "if(s32_processorid >= <total_cores> || s32_processorid <= -4)return 0xd8e007fd;"<br />
This fixed an off-by-one issue: if one would use processorid=total_cores, which isn't actually a valid value, svcCreateThread would accept that value on <[[10.0.0-27|10.0.0-X]]. This results in data being written out-of-bounds(baseaddr = arrayaddr + entrysize*processorid), which has the following result:<br />
* Old3DS: Useless kernel-mode crash due to accessing unmapped memory.<br />
* New3DS: uncontrolled data write into a kernel-mode L1 MMU-table. This isn't really useful: the data can't be controlled, and the data which gets overwritten is all-zero anyway(this isn't anywhere near MMU L1 entries for actually mapped memory).<br />
The previous version also allowed large negative s32_processorid values(negative processorid values are special values not actual procids), but it appears using values like that won't actually do anything(meaning no crash) besides the thread not running / thread not running for a while(besides triggering a kernelpanic with certain s32_processorid value(s)).<br />
| Nothing useful<br />
| [[10.0.0-27|10.0.0-X]]<br />
| [[10.0.0-27|10.0.0-X]]<br />
| svcCreateThread issue: May 31, 2015. The rest: September 8, 2015, via v9.6->v10.0 ARM11-kernel code-diff.<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| memchunkhax<br />
| The kernel originally did not validate the data stored in the FCRAM kernel heap [[Memchunkhdr|memchunk-headers]] for free-memory at all. Exploiting this requires raw R/W access to these memchunk-headers, like physical-memory access with gspwn.<br />
<br />
There are ''multiple'' ways to exploit this, but the end-result for most of these is the same: overwrite code in AXIWRAM via the 0xEFF00000/0xDFF00000 kernel virtual-memory mapping.<br />
<br />
This was fixed in [[9.3.0-21|9.3.0-X]] by checking that the memchunk(including size, next, and prev ptrs) is located within the currently used heap memory. The kernel may also check that the next/prev ptrs are valid compared to other memchunk-headers basically. When any of these checks fail, kernelpanic() is called.<br />
| When combined with other flaws: ARM11-kernelmode code execution<br />
| [[9.3.0-21|9.3.0-21]]<br />
| <br />
| February 2014<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| Multiple [[KLinkedListNode|KLinkedListNode]] SlabHeap use after free bugs<br />
| The ARM11-kernel did access the 'key' field of [[KLinkedListNode|KLinkedListNode]] objects, which are located on the SlabHeap, after freeing them. Thus, triggering an allocation of a new [[KLinkedListNode|KLinkedListNode]] object at the right time could result in a type-confusion. Pseudo-code:<br />
SlabHeap_free(KLinkedListNode);<br />
KObject *obj = KLinkedListNode->key; // the object there might have changed!<br />
This bug appeared all over the place.<br />
| ARM11-kernelmode code exec maybe<br />
| [[8.0.0-18|8.0.0-18]]<br />
| <br />
| April 2015<br />
| [[User:Derrek|derrek]]<br />
|-<br />
| PXI [[RPC_Command_Structure|Command]] input/output buffer permissions<br />
| Originally the ARM11-kernel didn't check permissions for PXI input/output buffers for commands. Starting with [[6.0.0-11|6.0.0]] PXI input/output buffers must have RW permissions, otherwise kernelpanic is triggered.<br />
| <br />
| [[6.0.0-11|6.0.0-11]]<br />
| <br />
| 2012<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[SVC|svcStartInterProcessDma]]<br />
| For svcStartInterProcessDma, the kernel code had the following flaws:<br />
<br />
* Originally the ARM11-kernel read the input DmaConfig structure directly in kernel-mode(ldr(b/h) instructions), without checking whether the DmaConfig address is readable under userland. This was fixed by copying that structure to the SVC-mode stack, using the ldrbt instruction.<br />
<br />
* Integer overflows for srcaddr+size and dstaddr+size are now checked(with [[6.0.0-11]]), which were not checked before.<br />
<br />
* The kernel now also checks whether the srcaddr/dstaddr (+size) is within userland memory (0x20000000), the kernel now (with [[6.0.0-11]]) returns an error when the address is beyond userland memory. Using an address >=0x20000000 would result in the kernel reading from the process L1 MMU table, beyond the memory allocated for that MMU table(for vaddr->physaddr conversion). <br />
| <br />
| [[6.0.0-11]]<br />
| <br />
| DmaConfig issue: unknown. The rest: 2014<br />
| [[User:Plutooo|plutoo]], [[User:Yellows8|Yellows8]] independently<br />
|-<br />
| [[SVC|svcControlMemory]] Parameter checks<br />
| For svcControlMemory the parameter check had these two flaws:<br />
<br />
* The allowed range for addr0, addr1, size parameters depends on which MemoryOperation is being specified. The limitation for GSP heap was only checked if op=(u32)0x10003. By setting a random bit in op that has no meaning (like bit17?), op would instead be (u32)0x30003, and the range-check would be less strict and not accurate. However, the kernel doesn't actually use the input address for LINEAR memory-mapping at all besides the range-checks, so this isn't actually useful. This was fixed in the kernel by just checking for the LINEAR bit, instead of comparing the entire MemoryOperation value with 0x10003.<br />
<br />
* Integer overflows on (addr0+size) are now checked that previously weren't (this also applies to most other address checks elsewhere in the kernel).<br />
<br />
| <br />
| [[5.0.0-11]]<br />
| <br />
|<br />
| [[User:Plutooo|plutoo]]<br />
|-<br />
| [[RPC_Command_Structure|Command]] request/response buffer overflow<br />
| Originally the kernel did not check the word-values from the command-header. Starting with [[5.0.0-11]], the kernel will trigger a kernelpanic() when the total word-size of the entire command(including the cmd-header) is larger than 0x40-words (0x100-bytes). This allows overwriting threadlocalstorage+0x180 in the destination thread. However, since the data written there would be translate parameters (such as header-words + buffer addresses), exploiting this would likely be very difficult, if possible at all.<br />
<br />
If the two words at threadlocalstorage+0x180 could be overwritten with controlled data this way, one could then use a command with a buffer-header of <nowiki>((size<<14) | 2)</nowiki> to write arbitrary memory to any RW userland memory in the destination process.<br />
| <br />
| [[5.0.0-11]]<br />
| <br />
| v4.1 FIRM -> v5.0 code diff<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[SVC|SVC stack allocation overflows]]<br />
| <br />
* Syscalls that allocate a variable-length array on stack, only checked bit31 before multiplying by 4/16 (when calculating how much memory to allocate). If a large integer was passed as input to one of these syscalls, an integer overflow would occur, and too little memory would have been allocated on stack resulting in a buffer overrun. <br />
* The alignment (size+7)&~7 calculation before allocation was not checked for integer overflow.<br />
<br />
This might allow for ARM11 kernel code-execution.<br />
<br />
(Applies to svcSetResourceLimitValues, svcGetThreadList, svcGetProcessList, svcReplyAndReceive, svcWaitSynchronizationN.)<br />
| <br />
| [[5.0.0-11]]<br />
| <br />
| v4.1 FIRM -> v5.0 code diff<br />
| [[User:Plutooo|plutoo]], [[User:Yellows8|Yellows8]] complementary<br />
|-<br />
| [[SVC|svcControlMemory]] MemoryOperation MAP memory-permissions<br />
| svcControlMemory with MemoryOperation=MAP allows mapping the already-mapped process virtual-mem at addr1, to addr0. The lowest address permitted for addr1 is 0x00100000. Originally the ARM11 kernel didn't check memory permissions for addr1. Therefore .text as addr1 could be mapped elsewhere as RW- memory, which allowed ARM11 userland code-execution.<br />
| <br />
| [[4.1.0-8]]<br />
| <br />
| 2012<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[RPC_Command_Structure|Command]] input/output buffer permissions<br />
| Originally the ARM11 kernel didn't check memory permissions for the input/output buffers for commands. Starting with [[4.0.0-7]] the ARM11 kernel will trigger a kernelpanic() if the input/output buffers don't have the required memory permissions. For example, this allowed a FSUSER file-read to .text, which therefore allowed ARM11-userland code execution.<br />
| <br />
| [[4.0.0-7]]<br />
| <br />
| 2012<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[SVC|svcReadProcessMemory/svcWriteProcessMemory memory]] permissions<br />
| Originally the kernel only checked the first page(0x1000-bytes) of the src/dst buffers, for svcReadProcessMemory and svcWriteProcessMemory. There is no known retail processes which have access to these SVCs.<br />
| <br />
| [[4.0.0-7]]<br />
| <br />
| 2012?<br />
| [[User:Yellows8|Yellows8]]<br />
|}<br />
<br />
=== [[FIRM]] Sysmodules ===<br />
{| class="wikitable" border="1"<br />
|-<br />
! Summary<br />
! Description<br />
! Successful exploitation result<br />
! Fixed in [[FIRM]] system version<br />
! Last [[FIRM]] system version this flaw was checked for<br />
! Timeframe this was discovered<br />
! Discovered by<br />
|-<br />
| [[Services|"srv:pm"]] process registration<br />
| Originally any process had access to the port "srv:pm". The PID's used for the (un)registration commands are not checked either. This allowed any process to re-register itself with "srv:pm", and therefore allowed the process to give itself access to any service, bypassing the exheader service-access-control list.<br />
<br />
This was fixed in [[7.0.0-13]]: starting with [[7.0.0-13]] "srv:pm" is now a service instead of a globally accessible port. Only processes with PID's less than 6 (in other words: fs, ldr, sm, pm, pxi modules) have access to it. With [[7.0.0-13]] there can only be one session for "srv:pm" open at a time(this is used by pm module), svcBreak will be executed if more sessions are opened by the processes which can access this.<br />
<br />
This flaw was needed for exploiting the <=v4.x Process9 PXI vulnerabilities from ARM11 userland ROP, since most applications don't have access to those service(s).<br />
| Access to arbitrary services<br />
| [[7.0.0-13]]<br />
| <br />
| 2012<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| FSDIR null-deref<br />
| [[Filesystem_services|FS]]-module may crash in some cases when handling directory reading. The trigger seems to be due to using [[FSDir:Close]] without closing the dir-handle afterwards?(Perhaps this is caused by out-of-memory?) This seems to be useless since it's just a null-deref.<br />
| <br />
| None<br />
| [[9.6.0-24|9.6.0-X]]<br />
| May 19(?)-20, 2015<br />
| [[User:Yellows8|Yellows8]]<br />
|}<br />
<br />
=== Standalone Sysmodules ===<br />
{| class="wikitable" border="1"<br />
|-<br />
! Summary<br />
! Description<br />
! Successful exploitation result<br />
! Fixed in system-module system-version<br />
! Last system-module system-version this flaw was checked for<br />
! Timeframe this was discovered<br />
! Timeframe this was added to wiki<br />
! Discovered by<br />
|-<br />
| [[MVD_Services|MVD]]: Stack buffer overflow with [[MVDSTD:SetupOutputBuffers]].<br />
| The input total_entries is not validated when initially processing the input entry-list. This fixed-size input entry-list is copied to stack from the command request. The loop for processing this initializes a global table, the converted linearmem->physaddrs used there are also copied to stack(0x8-bytes of physaddrs per entry).<br />
<br />
If total_entries is too large, MVD-sysmodule will crash due to reading unmapped memory following the stack(0x10000000). Afterwards if the out-of-bounds total_entries is smaller than that, it will crash due accessing address 0x0, hence this useless.<br />
| MVD-sysmodule crash.<br />
| None<br />
| [[9.0.0-20]]<br />
| April 22, 2016 (Tested on the 25th)<br />
| April 25, 2016<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[NWM_Services|NWM]]: Using CTRSDK heap with UDS sharedmem from the user-process.<br />
| See the HTTP-sysmodule section below.<br />
<br />
CTRSDK heap is used with the sharedmem from [[NWMUDS:InitializeWithVersion]]. Buffers are allocated/freed under this heap using [[NWMUDS:Bind]] and [[NWMUDS:Unbind]].<br />
<br />
Hence, overwriting sharedmem with gspwn then using [[NWMUDS:Unbind]] results in the usual controlled CTRSDK memchunk-header write, similar to HTTP-sysmodule.<br />
<br />
This could be done by creating an UDS network, without any other nodes on the network.<br />
<br />
Besides CTRSDK memchunk-headers, there are no addresses stored under this sharedmem.<br />
| ROP under NWM-module.<br />
| None<br />
| [[9.0.0-20|9.0.0-X]]<br />
| April 10, 2016<br />
| April 16, 2016<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[DLP_Services|DLP]]: Out-of-bounds memory access during spectator [[Download_Play|data-frame]] checksum calculation<br />
| DLP doesn't validate the frame_size when receiving spectator data-frames at all, unlike non-spectator data-frames. The actual spectator data-frame parsing code doesn't use that field either. However, the data-frame checksum calculation code called during checksum verification does use the frame_size for loading the size of the framebuf.<br />
<br />
Hence, using a large frame_size like 0xFFFF will result in the checksum calculation code reading data out-of-bounds. This isn't really useful, you could trigger a remote local-WLAN DLP-sysmodule crash while a 3DS system is scanning for DLP networks(due to accessing unmapped memory), but that's about all(trying to infoleak with this likely isn't useful either).<br />
| DLP-sysmodule crash, handled by dlplay system-application by a "connection interrupted" error eventually then a fatal-error via ErrDisp.<br />
| None<br />
| [[10.0.0-27|10.0.0-X]]<br />
| April 8, 2016 (Tested on the 10th)<br />
| April 10, 2016<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[DLP_Services|DLP]]: Out-of-bounds output data writing during spectator sysupdate titlelist [[Download_Play|data-frame]] handling<br />
| The total_entries and out_entryindex fields for the titlelist DLP spectator data-frames are not validated. This is parsed during DLP network scanning. Hence, the specified titlelist data can be written out-of-bounds using the specified out_entryindex and total_entries. A crash will occur while reading the input data-frame titlelist if total_entries is larger than 0x27A, due to accessing unmapped memory.<br />
<br />
There's not much non-zero data to overwrite following the output buffer(located in sharedmem), any ptrs are located in sharedmem. Overwriting certain ptr(s) are only known to cause a crash when attempting to use the DLP-client shutdown service-command.<br />
<br />
There's no known way to exploit the above crash, since the linked-list code involves writes zeros(with a controlled start ptr).<br />
| <br />
| None<br />
| [[10.0.0-27|10.0.0-X]]<br />
| April 8-9, 2016<br />
| April 10, 2016<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[IR_Services|IR]]: Stack buffer overflow with custom hardware<br />
| Originally IR sysmodule used the read value from the I2C-IR registers TXLVL and RXLVL without validating them at all. See [[10.6.0-31|here]] for the fix. This is the size used for reading the data-recv FIFO, etc. The output buffer for reading is located on the stack.<br />
<br />
This should be exploitable if one could successfully setup the custom hardware for this and if the entire intended sizes actually get read from I2C.<br />
| ROP under IR sysmodule.<br />
| [[10.6.0-31|10.6.0-31]]<br />
| <br />
| February 23, 2016 (Unknown if it was noticed before then)<br />
| February 23, 2016<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[HTTP_Services|HTTP]]: Using CTRSDK heap with sharedmem from the user-process.<br />
| The data from httpcAddPostDataAscii and other commands is stored under a CTRSDK heap. That heap is the sharedmem specified by the user-process via the HTTPC Initialize command.<br />
Normally this sharedmem isn't accessible to the user-process once the sysmodule maps it, hence using it is supposed to be "safe".<br />
<br />
This isn't the case due to gspwn however. Since CTRSDK heap code is so insecure in general, one can use gspwn to locate the HTTPC sharedmem + read/write it, then trigger a mem-write under the sysmodule. This can then be used to get ROP going under HTTP-sysmodule.<br />
<br />
This is exploited by [https://github.com/yellows8/ctr-httpwn/ctr-httpwn ctr-httpwn].<br />
| ROP under HTTP sysmdule.<br />
| None<br />
| [[9.6.0-24|9.6.0-X]] (Latest sysmodule version as of [[10.7.0-32|10.7.0-32]])<br />
| Late 2015<br />
| March 22, 2016<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[NIM_Services|NIM]]: Downloading old title-versions from eShop<br />
| Multiple NIM service commands(such as [[NIMS:StartDownload]]) use a title-version value specified by the user-process, NIM does not validate that this input version matches the latest version available via SOAP. Therefore, when combined with AM(PXI) [[#Process9|title-downgrading]] via deleting the target eShop title with System Settings Data Management(if the title was already installed), this allows downloading+installing any title-version from eShop ''if'' it's still available from CDN.<br />
The easiest way to exploit this is to just patch the eShop system-application code using these NIM commands(ideally the code which loads the title-version).<br />
<br />
Originally this was tested with a debugging-system via modded-FIRM, eventually smea implemented it in HANS for the 32c3 release.<br />
| Downloading old title-versions from eShop<br />
| None<br />
| [[10.0.0-27|10.0.0-X]]<br />
| October 24, 2015 (Unknown when exactly the first eShop title downgrade was actually tested, maybe November)<br />
| January 7, 2016 (Same day Ironfall v1.0 was removed from CDN via the main-CXI files)<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[SPI_Services|SPI]] service out-of-bounds write<br />
| cmd1 has out-of-bounds write allowing overwrite of some static variables in .data.<br />
| <br />
| None<br />
| [[9.5.0-22]]<br />
| March 2015<br />
| <br />
| [[User:Plutooo|plutoo]]<br />
|-<br />
| [[NFC_Services|NFC]] module service command buf-overflows<br />
| NFC module copies data with certain commands, from command input buffers to stack without checking the size. These commands include the following, it's unknown if there's more commands with similar issues: "nfc:dev" <0x000C....> and "nfc:s" <0x0037....>.<br />
Since both of these commands are stubbed in the Old3DS NFC module from the very first version(those just return an error), these issues only affect the New3DS NFC module.<br />
<br />
There's no known retail titles which have access to either of these services.<br />
| ROP under NFC module.<br />
| New3DS: None<br />
| New3DS: [[9.5.0-22]]<br />
| December 2014?<br />
| <br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[News_Services|NEWSS]] service command notificationID validation failure<br />
| This module does not validate the input notificationID for <nowiki>"news:s"</nowiki> service commands. This is an out-of-bounds array index bug. For example, [[NEWSS:SetNotificationHeader]] could be used to exploit news module: this copies the input data(size is properly checked) to: out = newsdb_savedata+0x10 + (someu32array[notificationID]*0x70).<br />
| ROP under news module.<br />
| None<br />
| [[9.7.0-25|9.7.0-X]]<br />
| December 2014<br />
| <br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[NWMUDS:DecryptBeaconData]] heap buffer overflow<br />
| input_size = 0x1E * <value the u8 from input_[[NWM_Services|networkstruct]]+0x1D>. Then input_tag0 is copied to a heap buffer. When input_size is larger than 0xFA-bytes, it will then copy input_tag1 to <end_address_of_previous_outbuf>, with size=input_size-0xFA.<br />
<br />
This can be triggered by either using this command directly, or by boadcasting a wifi beacon which triggers it while a 3DS system running the target process is in range, when the process is scanning for hosts to connect to. Processes will only pass tag data to this command when the wlancommID and other thing(s) match the values for the process.<br />
<br />
There's no known way to actually exploit this for getting ROP under NWM-module, at the time of originally adding this to the wiki. This is because the data which gets copied out-of-bounds *and* actually causes crash(es), can't be controlled it seems(with just broadcasting a beacon at least). It's unknown whether this could be exploited from just using NWMUDS service-cmd(s) directly.<br />
| Without any actual way to exploit this: NWM-module DoS, resulting in process termination(process crash). This breaks *everything* involving wifi comms, a reboot is required to recover from this.<br />
| None<br />
| [[9.0.0-20]]<br />
| ~September 23, 2014(see the [[NWMUDS:DecryptBeaconData]] page history)<br />
| August 3, 2015<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[HID_Services|HID]] module shared-mem<br />
| HID module does not validate the index values in [[HID_Shared_Memory|sharedmem]](just changes index to 0 when index == maxval when updating), therefore large values will result in HID module writing HID data to arbitrary addresses.<br />
| ROP under HID module, but this is *very* unlikely to be exploitable since the data written is HID data.<br />
| None<br />
| [[9.3.0-21]]<br />
| 2014?<br />
| <br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| gspwn<br />
| GSP module does not validate addresses given to the GPU. This allows a user-mode application/applet to read/write to a large part of physical FCRAM using GPU DMA. From this, you can overwrite the .text segment of the application you're running under, and gain real code-execution from a ROP-chain. Normally applets' .text([[Home Menu]], [[Internet Browser]], etc) is located beyond the area accessible by the GPU, except for [[RO_Services|CROs]] used by applets([[Internet Browser]] for example).<br />
<br />
FCRAM is gpu-accessible up to physaddr 0x26800000 on Old3DS, and 0x2DC00000 on New3DS. This is BASE_memregion_start(aka SYSTEM_memregion_end)-0x400000 with the default memory-layout on Old3DS/New3DS.<br />
| User-mode code execution.<br />
| None<br />
| [[9.6.0-24|9.6.0-X]]<br />
| Early 2014<br />
| <br />
| smea, [[User:Yellows8|Yellows8]]/others before then<br />
|-<br />
| rohax<br />
| Using gspwn, it is possible to overwrite a loaded [[CRO0]]/[[CRR0]] after its RSA-signature has been validated. Badly validated [[CRO0]] header leads to arbitrary read/write of memory in the ro-process. This gives code-execution in the ro module, who has access to [[SVC|syscalls]] 0x70-0x72, 0x7D.<br />
<br />
This was fixed after [[ninjhax]] release by adding checks on [[CRO0]]-based pointers before writing to them.<br />
| Memory-mapping syscalls.<br />
| [[9.3.0-21]]<br />
| [[9.4.0-21]]<br />
| <br />
| <br />
| smea, [[User:Plutooo|plutoo]] joint effort<br />
|-<br />
| Region free<br />
| Only [[Home Menu]] itself checks gamecards' region when launching them. Therefore, any application launch that is done directly with [[NS]] without signaling Home Menu to launch the app, will result in region checks being bypassed.<br />
This essentially means launching the gamecard with the [[NS_and_APT_Services|"ns:s"]] service. The main way to exploit this is to trigger a FIRM launch with an application specified, either with a normal FIRM launch or a hardware [[NSS:RebootSystem|reboot]].<br />
| Launching gamecards from any region + bypassing Home Menu gamecard-sysupdate installation<br />
| None<br />
| Last tested with [[10.1.0-27|10.1.0-X]].<br />
| June(?) 2014<br />
| <br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[NWM_Services|NWM]] service-cmd state null-ptr deref<br />
| The NWMUDS service command code loads a ptr from .data, adds an offset to that, then passes that as the state address for the actual command-handler function. The value of the ptr loaded from .data is not checked, therefore this will cause crashes due to that being 0x0 when NWMUDS was not properly initialized.<br />
It's unknown whether any NWM services besides NWMUDS have this issue.<br />
| This is rather useless since it's only a crash caused by a state ptr based at 0x0.<br />
| None<br />
| [[9.0.0-20]]<br />
| 2013?<br />
| <br />
| [[User:Yellows8|Yellows8]]<br />
|}<br />
<br />
=== General/CTRSDK ===<br />
{| class="wikitable" border="1"<br />
|-<br />
! Summary<br />
! Description<br />
! Successful exploitation result<br />
! Fixed in version<br />
! Last version this flaw was checked for<br />
! Timeframe this was discovered<br />
! Discovered by<br />
|-<br />
| [[NWM_Services|UDS]] beacon additional-data buffer overflow<br />
| Originally CTRSDK did not validate the UDS additional-data size before using that size to copy the additional-data to a [[NWM_Services|networkstruct]]. This was eventually fixed.<br />
This was discovered while doing code RE with an old dlp-module version. It's unknown in what specific CTRSDK version this was fixed, or even what system-version updated titles with a fixed version.<br />
<br />
It's unknown if there's any titles using a vulnerable CTRSDK version which are also exploitable with this(dlp module can't be exploited with this).<br />
<br />
The maximum number of bytes that can be written beyond the end of the outbuf is 0x37-bytes, with additionaldata_size=0xFF.<br />
| Perhaps ROP, very difficult if possible with anything at all<br />
| ?<br />
| <br />
| September(?) 2014<br />
| [[User:Yellows8|Yellows8]]<br />
|}</div>Mrrraouhttps://www.3dbrew.org/w/index.php?title=3DS_System_Flaws&diff=183043DS System Flaws2016-09-27T11:02:23Z<p>Mrrraou: /* arm9loader */</p>
<hr />
<div>Exploits are used to execute unofficial code (homebrew) on the Nintendo 3DS. This page is a list of publicly known system flaws, for userland applications/applets flaws see [[3DS_Userland_Flaws|here]].<br />
<br />
=Stale / Rejected Efforts=<br />
* Neimod has been working on a RAM dumping setup for a little while now. He's de-soldered the 3DS's RAM chip and hooked it and the RAM pinouts on the 3DS' PCB up to a custom RAM dumping setup. A while ago he published photos showing his setup to be working quite well, with the 3DS successfully booting up. However, his flickr stream is now private along with most of his work.<br />
<br />
* Someone (who will remain unnamed) has released CFW and CIA installers, all of which is copied from the work of others, or copyrighted material.<br />
<br />
==Tips and info==<br />
The 3DS uses the XN feature of the ARM11 processor. There's no official way from applications to enable executable permission for memory containing arbitrary unsigned code(there's a [[SVC]] for this, but only [[RO_Services|RO-module]] has access to it). An usable userland exploit would still be useful: you could only do return-oriented-programming with it initially. From ROP one could then exploit system flaw(s), see below.<br />
<br />
SD card [[extdata]] and SD savegames can be attacked, for consoles where the console-unique [[Nand/private/movable.sed|movable.sed]] was dumped(accessing SD data is far easier by running code on the target 3DS however).<br />
<br />
=System flaws=<br />
== Hardware ==<br />
{| class="wikitable" border="1"<br />
! Summary<br />
! Description<br />
! Fixed with hardware model/revision<br />
! Newest hardware model/revision this flaw was checked for<br />
! Timeframe this was discovered<br />
! Discovered by<br />
|-<br />
| ARM9/ARM11 bootrom vectors point at unitialized RAM<br />
| ARM9's and ARM11's exception vectors are hardcoded to point at the CPU's internal memory (0x08000000 region for ARM9, AXIWRAM for ARM11). While the bootrom does set them up to point to an endless loop at some point during boot, it does not do so immediately. As such, a carefully-timed fault injection (via hardware) to trigger an exception (such as an invalid instruction) will cause execution to fall into ARM9 RAM. <br />
Since RAM isn't cleared on boot (see below), one can immediately start execution of their own code here to dump bootrom, OTP, etc.<br />
The ARM9 bootrom does the following at reset: reset vector branches to another instruction, then branches to bootrom+0x8000. Hence, there's no way to know for certain when exactly the ARM9 exception-vector data stored in memory gets initialized.<br />
<br />
This requires *very* *precise* timing for triggering the hardware fault: it's unknown if anyone actually exploited this successfully at the time of writing(the one who attempted+discovered it *originally* as listed in this wiki section hasn't).<br />
| None: all available 3DS models at the time of writing have the exact same ARM9/ARM11 bootrom for the unprotected areas.<br />
| New3DS<br />
| End of February 2014<br />
| [[User:Derrek|derrek]], WulfyStylez (May 2015) independently<br />
|-<br />
| Missing AES key clearing<br />
| The hardware AES engine does not clear keys when doing a hard reset/reboot.<br />
| None<br />
| New3DS<br />
| August 2014<br />
| Mathieulh/Others<br />
|-<br />
| No RAM clearing on reboots<br />
| On an MCU-triggered reboot all RAM including FCRAM/ARM9 memory/AXIWRAM/VRAM keeps its contents.<br />
| None<br />
| New3DS<br />
| March 2014<br />
| [[User:Derrek|derrek]]<br />
|-<br />
| 32bits of actual console-unique TWLNAND keydata<br />
| On retail the 8-bytes at ARM9 address [[Memory_layout|0x01FFB808]] are XORed with hard-coded data, to generate the TWL console-unique keys, including TWLNAND. On Old3DS the high u32 is always 0x0, while on New3DS that u32 is always 0x2. On top of this, the lower u32's highest bit is always ORed. only 31 bits of the TWL console-unique keydata / TWL consoleID are actually console-unique.<br />
This allows one to easily bruteforce the TWL console-unique keydata with *just* data from TWLNAND. On DSi the actual console-unique data for key generation is 8-bytes(all bytes actually set).<br />
| None<br />
| New3DS<br />
| 2012?<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| DSi / 3DS-TWL key-generator<br />
| After using the key generator to generate the normal-key, you could overwrite parts of the normal-key with your own data and then recover the key-generator output by comparing the new crypto output with the original crypto output. From the normal-key outputs, you could deduce the TWL key-generator function.<br />
This applies to the keyX/keyY too.<br />
<br />
This attack does not work for the 3DS key-generator because keyslots 0-3 are only for TWL keys.<br />
| None<br />
| New3DS<br />
| 2011<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| 3DS key-generator<br />
| The algorithm for generating the normal-keys for keyslots is cryptographically weak. As a result, it is easily susceptible to differential cryptanalysis if the normal-key corresponding to any scrambler-generated keyslot is discovered.<br />
<br />
Several such pairs of matching normal-keys and KeyY values were found, leading to deducing the key-generator function.<br />
| None<br />
| New3DS<br />
| February 2015<br />
| [[User:Yellows8|Yellows8]], [[User:Plutooo|plutoo]]<br />
|-<br />
| FIRM partitions known-plaintext<br />
| The [[Flash_Filesystem|FIRM partitions]] are encrypted with AES-CTR without a MAC. Since this works by XOR'ing data with a static (per-console in this case) keystream, one can deduce the keystream of a portion of each FIRM partition if they have the actual FIRM binary stored in it.<br />
<br />
This can be paired with many exploits. For example, it allows minor FIRM downgrades (i.e. 10.4 to 9.6 or 9.5 to 9.4, but not 9.6 to 9.5).<br />
<br />
This can be somewhat addressed by having a FIRM header skip over previously used section offsets, but this would just air-gap newer FIRMs without fixing the core bug. This can also only be done a limited number of times due to the size of FIRM versus the size of the partitions.<br />
| None<br />
| New3DS<br />
| <br />
| Everyone<br />
|}<br />
<br />
== ARM9 software ==<br />
=== arm9loader ===<br />
{| class="wikitable" border="1"<br />
|-<br />
! Summary<br />
! Description<br />
! Successful exploitation result<br />
! Fixed in [[FIRM]] system version<br />
! Last [[FIRM]] system version this flaw was checked for<br />
! Timeframe this was discovered<br />
! Public disclosure timeframe<br />
! Discovered by<br />
|-<br />
| Rearrangable keys in the NAND keystore<br />
| Due to the keystore being encrypted with AES-ECB, one can rearrange blocks and still have the NAND keystore decrypt in a deterministic way. Combining this with the arm9loaderhax and uncleared hash keydata vulnerabilities, one can achieve arm9loaderhax without downgrading to a system version that exposes the OTP data, or using a hardware method. The NAND keystore must be encrypted with console-unique data; therefore, this is not achievable on Old 3DS or 2DS.<br />
| arm9loaderhax achieveable with no extra hardware and without downgrading to a system version which exposes the OTP.<br />
| None<br />
| [[11.1.0-34|11.1.0-X]]<br />
| Early 2016<br />
| 27 September 2016<br />
| Everyone/[[User:Dark samus|dark_samus]], mathieulh independently<br />
|-<br />
| Uncleared OTP hash keydata in console-unique 0x11 key-generation<br />
| Kernel9Loader does not clear the [[SHA_Registers#SHA_HASH|SHA_HASH register]] after use. As a result, the data stored here as K9L hands over to Kernel9 is the hash of [[OTP_Registers|OTP data]] used to seed the [[FIRM#New_3DS_FIRM|console-unique NAND keystore decryption key]] set on keyslot 0x11.<br />
<br />
Retrieving this keydata and the [[Flash_Filesystem#0x12C00|NAND keystore]] of the same device allows calculating the decrypted New3DS NAND keystore (non-unique, common to all New3DS units), which contains AES normal keys, also set on keyslot 0x11, which are then used to derive all current [[AES_Registers#Keyslots|New3DS-only AES keyXs]] including the newer batch introduced in [[9.6.0-24#arm9loader|9.6.0-X]]. From there, it is trivial to perform the same key derivation in order to initialize those keys on any system version, and even on Old3DS.<br />
<br />
This can be performed by exploiting the "arm9loaderhax" vulnerability to obtain post-K9L code execution after an MCU reboot (the bootrom section-loading fail is not relevant here, this attack was performed without OTP data by brute-forcing keys), and using this to dump the SHA_HASH register. This attack works on any FIRM version shipping a vulnerable version of K9L, whereas OTP dumping required a boot of <[[3.0.0-6|3.0.0-X]].<br />
<br />
This attack results in obtaining the entire (0x200-bytes) NAND keystore - it was confirmed at a later date that this keystore is encrypted with the same key (by comparing the decrypted data from multiple units), and therefore using another key in this store will not remedy the issue as all keys are known (i.e. later, unused keys decrypt to the same 0x200-bytes constant with the same OTP hash). Later keys could have been encrypted differently but this is not the case. As a result of this, it is not possible for Nintendo to use K9L again in its current format for its intended purpose, though this was not news from the moment people dumped a New3DS OTP.<br />
| Derivation of all New3DS keys generated via the NAND keystore (0x1B "Secure4" etc.)<br />
| None<br />
| [[11.1.0-34|11.1.0-X]]<br />
| ~April 2015, implemented in May 2015<br />
| 13 January 2016<br />
| [[User:WulfyStylez|WulfyStylez]], [[User:Dazzozo|Dazzozo]], [[User:Shinyquagsire23|shinyquagsire23]] (complimentary + implemented), [[User:Plutooo|plutoo]], Normmatt (discovered independently)<br />
|-<br />
| enhanced-arm9loaderhax<br />
| See the 32c3 3ds talk.<br />
Since this is a combination of a trick with the arm9-bootrom + arm9loaderhax, and since you have to manually write FIRM to the firm0/firm1 NAND partitions, this can't be completely fixed. Any system with existing ARM9 code execution and an OTP/OTP hash dump can exploit this. Additionally, by using the FIRM partition known-plaintext bug and bruteforcing the second entry in the keystore, this can currently be exploited on all New3DS systems without any other prerequisite hacks.<br />
| arm9loaderhax which automatically occurs at hard-boot.<br />
| See arm9loaderhax / description.<br />
| See arm9loaderhax / description.<br />
| Theorized around mid July, 2015. Later implemented+tested by [[User:Plutooo|plutoo]] and derrek.<br />
| 32c3 3ds talk (December 27, 2015)<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| Missing verification-block for the 9.6 keys (arm9loaderhax)<br />
| Starting with [[9.6.0-24|9.6.0-X]] a new set of NAND-based keys were introduced. However, no verification block was added to verify that the new key read from NAND is correct. This was technically an issue from [[9.5.0-22|9.5.0-X]] with the original sector+0 keydata, however the below is only possible with [[9.6.0-24|9.6.0-X]] since keyslots 0x15 and 0x16 are generated from different 0x11 keyXs.<br />
<br />
Writing an incorrect key to NAND will cause arm9loader to decrypt the ARM9 kernel as garbage and then jump to it.<br />
<br />
This allows an hardware-based attack where you can boot into an older exploited firmware, fill all memory with NOP sleds/jump-instructions, and then reboot into executing garbage. By automating this process with various input keydata, eventually you'll find some garbage that jumps to your code.<br />
<br />
This gives very early ARM9 code execution (pre-ARM9 kernel). As such, it is possible to dump RSA keyslots with this and calculate the 6.x [[Savegames#6.0.0-11_Savegame_keyY|save]], and 7.x [[NCCH]] keys. This cannot be used to recover keys initialized by arm9loader itself. This is due to it wiping the area used for its stack during NAND sector decryption and keyslot init. <br />
<br />
Due to FIRMs on both Old and New 3DS using the same RSA data, this can be exploited on Old3DS as well, but only if one already has the actual plaintext normalkey from New3DS NAND sector 0x96 offset-0 and has dumped the OTP area of the Old3DS.<br />
| Recovery of 6.x [[Savegames#6.0.0-11_Savegame_keyY|save key]]/7.x [[NCCH]] key<br />
| None<br />
| [[11.1.0-34|11.1.0-X]]<br />
| March, 2015<br />
| <br />
| [[User:Plutooo|plutoo]]<br />
|-<br />
| Uncleared New3DS keyslot 0x11<br />
| Originally the New3DS [[FIRM]] arm9bin loader only cleared keyslot 0x11 when it gets executed at firmlaunch. This was fixed with [[9.5.0-22|9.5.0-X]] by completely clearing keyslot 0x11 immediately after the loader finishes using keyslot 0x11.<br />
This means that any ARM9 code that can execute before the loader clears the keyslot at firmlaunch(including firmlaunch-hax) can get access to the uncleared keyslot 0x11, which then allows one to generate all <=v9.5 New3DS keyXs which are generated by keyslot 0x11.<br />
<br />
Therefore, to completely fix this the loader would have to generate more keys using different keyslot 0x11 keydata. This was done with [[9.6.0-24|9.6.0-X]].<br />
| New3DS keyXs generation<br />
| Mostly fixed with [[9.5.0-22|9.5.0-X]], completely fixed with new keys with [[9.6.0-24|9.6.0-X]].<br />
| <br />
| February 3, 2015 (one day after [[9.5.0-22|9.5.0-X]] release)<br />
| <br />
| [[User:Yellows8|Yellows8]]<br />
|}<br />
<br />
=== Process9 ===<br />
{| class="wikitable" border="1"<br />
|-<br />
! Summary<br />
! Description<br />
! Successful exploitation result<br />
! Fixed in [[FIRM]] system version<br />
! Last [[FIRM]] system version this flaw was checked for<br />
! Timeframe this was discovered<br />
! Public disclosure timeframe<br />
! Discovered by<br />
|-<br />
| Leak of normal-key matching a key-scrambler key<br />
| New 3DS firmware versions [[8.1.0-0 New3DS|8.1.0]] through [[9.2.0-20|9.2.0]] set the encryption key for [[Amiibo]] data using a hardcoded normal-key in Process9. In firmware [[9.3.0-21|9.3.0]], Nintendo "fixed" this by using the key scrambler instead, by calculating the keyY value for keyslot 0x39 that results in the same normal-key, then hardcoding that keyY into Process9.<br />
<br />
Nintendo's fix is actually the problem: Nintendo revealed the normal-key matching an unknown keyX and a known keyY. Combined with the key scrambler using an insecure scrambling algorithm (see "Hardware" above), the key scrambler function could be deduced.<br />
| Deducing the keyX for keyslot 0x39 and the key scrambler algorithm<br />
| New 3DS [[9.3.0-21|9.3.0-X]], sort of<br />
| [[10.0.0-27|10.0.0-X]]<br />
| Sometime in 2015 after the hardware key-generator was broken.<br />
| 32c3 3ds talk (December 27, 2015)<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| Leak of normal-key matching a key-generator key<br />
| During the 3DS' development (June/July 2010) Nintendo added support installing encrypted content ([[CIA]]). Common-key index1 was intended to be a [[AES|hardware generated key]]. However while they added code to generate the key in hardware, they forgot to remove the normal-key for index1 (used elsewhere, likely old debug code). Nintendo later removed the normal key sometime before the first non-prototype firmware release.<br />
<br />
<br />
Knowing the keyY and the normal-key for common-key index1, the devkit key-generator algorithm can be deduced (see "Hardware" above). Additionally the remaining devkit common-keys can be generated once the common-key keyX is recovered.<br />
<br />
Note the devkit key-generator was discovered to be the same as the retail key-generator.<br />
| Deducing the keyX for keyslot 0x3D and hardware key-generator algorithm. Generate remaining devkit common-keys.<br />
| pre-[[1.0.0-0|1.0.0-X]]<br />
| <br />
| Shortly after the key-generator was revealed to be flawed at the 32c3 3ds talk<br />
| January 20, 2016<br />
| [[User:Jakcron|jakcron]]<br />
|-<br />
| ntrcardhax<br />
| <br />
| ARM9 code execution<br />
| 10.4.0-29<br />
| <br />
| March 2015<br />
| 32c3 3ds talk (December 27, 2015)<br />
| [[User:Plutooo|plutoo]]<br />
|-<br />
| Title downgrading via [[Application_Manager_Services|AM]]([[Application_Manager_Services_PXI|PXI]])<br />
| When a title is *already* installed, Process9 will compare the installed title-version with the title-version being installed. When the one being installed is older, Process9 would return an error.<br />
<br />
However, this can be bypassed by just deleting the title first via the service command(s) for that: with the title removed from the [[Title_Database]], Process9 can't compare the input title-version with anything. Hence, titles can be downgraded this way.<br />
<br />
[[11.0.0-33|11.0.0-X]] fixed this for key system titles (MSET, Home Menu, spider, ErrDisp, SKATER, NATIVE_FIRM, and every retail system module), by checking the version of the title to install against a hard-coded list of (titleID, minimumVersionRequired) pairs.<br />
| Bypassing title version check at installation, which then allows downgrading any title.<br />
| [[11.0.0-33|11.0.0-X]], for key system titles.<br />
| NATIVE_FIRM / AM-sysmodule [[11.0.0-33|11.0.0-X]]<br />
| ?<br />
| <br />
| ?<br />
|-<br />
| FAT FS code null-deref<br />
| When FSFile:Read is used with a file which is corrupted on a FAT filesystem(in particular SD), Process9 can crash. This particular crash is caused by a function returning NULL instead of an actual ptr due to an error. The caller of that function doesn't check for NULL which then triggers a read based at NULL.<br />
<br />
Sample "fsck.vfat -n -v -V <fat image backup>" output for the above crash:<br />
<br />
<pre>...<br />
Starting check/repair pass.<br />
<FilePath0> and<br />
<FilePath1><br />
share clusters.<br />
Truncating second to 3375104 bytes.<br />
<FilePath1><br />
File size is 2787392 bytes, cluster chain length is 16384 bytes.<br />
Truncating file to 16384 bytes.<br />
Checking for unused clusters.<br />
Reclaimed 1 unused cluster (16384 bytes).<br />
Checking free cluster summary.<br />
Free cluster summary wrong (1404490 vs. really 1404491)<br />
Auto-correcting.<br />
Starting verification pass.<br />
Checking for unused clusters.<br />
Leaving filesystem unchanged.</pre><br />
| Useless null-based-read<br />
| None<br />
| [[9.6.0-24|9.6.0-X]]<br />
| July 8-9, 2015<br />
| <br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| RSA signature padding checks<br />
| The TWL_FIRM RSA sig padding check code used for all TWL RSA sig-checks has issues, see [[FIRM|here]].<br />
The main 3DS RSA padding check code(non-certificate, including NATIVE_FIRM) uses the function used with the above to extract more padding + the actual hash from the additional padding. This isn't really a problem here because there's proper padding check code which is executed prior to this.<br />
| <br />
| None<br />
| [[9.5.0-22|9.5.0-X]]<br />
| March 2015<br />
| <br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[AMPXI:ValidateDSiWareSectionMAC]] [[AES_Registers|AES]] keyslot reuse<br />
| When the input DSiWare section index is higher than <max number of DSiWare sections supported by this FIRM>, Process9 uses keyid 0x40 for calculating the AESMAC, which translates to keyslot 0x40. The result is that the keyslot is left at whatever was already selected before, since the AES selectkeyslot code will immediately return when keyslot is >=0x40. However, actually exploiting this is difficult: the calculated AESMAC is never returned, this command just compares the calculated AESMAC with the input AESMAC(result-code depends on whether the AESMACs match). It's unknown whether a timing attack would work with this.<br />
This is basically a different form of the pxips9 keyslot vuln, except with AESMAC etc.<br />
| See description.<br />
| None<br />
| [[11.1.0-34|11.1.0-X]]<br />
| March 15, 2015<br />
| December 29, 2015<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| pxips9 [[AES_Registers|AES]] keyslot reuse<br />
| This requires access to the [[Process_Services|ps:ps]]/pxi:ps9 services. One way to get access to this would be snshax on system-version <=10.1.0-X(see 32c3 3ds talk).<br />
When an invalid key-type value is passed to any of the PS commands, Process9 will try to select keyslot 0x40. That aesengine_setkeyslot() code will then immediately return due to the invalid keyslot value. Since that function doesn't return any errors, Process9 will just continue to do crypto with whatever AES keyslot was selected before the PS command was sent.<br />
| Reusing the previously used keyslot, for crypto with PS.<br />
| None<br />
| [[11.1.0-34|11.1.0-X]]<br />
| Roughly the same time(same day?) as firmlaunch-hax.<br />
| December 29, 2015<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| firmlaunch-hax: FIRM header ToCToU<br />
| This can't be exploited from ARM11 userland.<br />
During [[FIRM]] launch, the only FIRM header the ARM9 uses at all is stored in FCRAM, this is 0x200-bytes(the actual used FIRM RSA signature is read to the Process9 stack however). The ARM9 doesn't expect "anything" besides the ARM9 to access this data.<br />
With [[9.5.0-22]] the address of this FIRM header was changed from a FCRAM address, to ARM9-only address 0x01fffc00.<br />
| ARM9 code execution<br />
| [[9.5.0-22]]<br />
| <br />
| 2012, 3 days after [[User:Yellows8|Yellows8]] started Process9 code RE.<br />
| <br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| Uninitialized data output for (PXI) command replies<br />
| PXI commands for various services(including some [[Filesystem_services_PXI|here]] and many others) can write uninitialized data (like from ARM registers) to the command reply. This happens with stubbed commands, but this can also occur with certain commands when returning an error.<br />
Certain ARM11 service commands have this same issue as well.<br />
| <br />
| None<br />
| [[9.3.0-21|9.3.0-X]]<br />
| ?<br />
| <br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[Filesystem_services_PXI|FSPXI]] OpenArchive SD permissions<br />
| Process9 does not use the exheader ARM9 access-mount permission flag for SD at all.<br />
This would mean ARM11-kernelmode code / fs-module itself could directly use FSPXI to access SD card without ARM9 checking for SD access, but this is rather useless since a process is usually running with SD access(Home Menu for example) anyway.<br />
| <br />
| None<br />
| [[9.3.0-21|9.3.0-X]]<br />
| 2012<br />
| <br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[AMPXI:ExportDSiWare]] export path<br />
| Process9 allocates memory on Process9 heap for the export path then verifies that the actual allocated size matches the input size. Then Process9 copies the input path from FCRAM to this buffer, and uses it with the Process9 FS openfile code, which use paths in the form of "<mountpoint>:/<path>".<br />
Process9 does not check the contents of this path at all before passing it to the FS code, besides writing a NUL-terminator to the end of the buffer.<br />
| Exporting of DSiWare to arbitrary Process9 file-paths, such as "nand:/<path>" etc. This isn't really useful since the data which gets written can't be controlled.<br />
| None<br />
| [[9.5.0-22]]<br />
| April 2013<br />
| <br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[DSiWare_Exports]] [[CTCert]] verification<br />
| Just like DSi originally did, 3DS verifies the APCert for DSiWare on SD with the CTCert also in the DSiWare .bin. On DSi this was fixed with with system-version 1.4.2 by verifying with the actual console-unique cert instead(stored in NAND), while on 3DS it's still not(?) fixed.<br />
On 3DS however this is rather useless, due to the entire DSiWare .bin being encrypted with the console-unique movable.sed keyY.<br />
| When the movable.sed keyY for the target 3DS is known and the target 3DS CTCert private-key is unknown, importing of modified DSiWare SD .bin files.<br />
| Unknown, probably none.<br />
| ?<br />
| April 2013<br />
| <br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[Gamecard_Services_PXI]] unchecked REG_CTRCARDCNT transfer-size<br />
| The u8 REG_CTRCARDCNT transfer-size parameter for the [[Gamecard_Services_PXI]] read/write CTRCARD commands is used as an index for an array of u16 values. Before [[5.0.0-11|5.0.0-X]] this u8 value wasn't checked, thus out-of-bounds reads could be triggered(which is rather useless in this case).<br />
| Out-of-bounds read for a value which gets written to a register.<br />
| [[5.0.0-11|5.0.0-X]]<br />
| <br />
| 2013?<br />
| <br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[PXI_Registers|PXI]] cmdbuf buffer overrun<br />
| The Process9 code responsible [[PXI_Registers|PXI]] communications didn't verify the size of the incoming command before writing it to a C++ member variable. <br />
| Probably ARM9 code execution<br />
| [[5.0.0-11|5.0.0-11]]<br />
| <br />
| March 2015, original timeframe if any unknown<br />
| <br />
| [[User:Plutooo|plutoo]]/[[User:Yellows8|Yellows8]]/maybe others(?)<br />
|-<br />
| [[Application_Manager_Services_PXI|PXIAM]] command 0x003D0108(See also [[Application_Manager_Services|this]])<br />
| When handling this command, Process9 allocates a 0x2800-byte heap buffer, then copies the 4 FCRAM input buffers to this heap buffer without checking the sizes at all(only the buffers with non-zero sizes are copied). Starting with [[5.0.0-11|5.0.0-X]], the total combined size of the input data must be <=0x2800.<br />
| ARM9 code execution<br />
| [[5.0.0-11|5.0.0-X]]<br />
| <br />
| May 2013<br />
| <br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[Process_Services_PXI|PS RSA]] commands buffer overflows<br />
| pxips9 cmd1(not accessible via ps:ps) and VerifyRsaSha256: unchecked copy to a buffer in Process9's .bss, from the input FCRAM buffer. The buffer is located before the pxi cmdhandler threads' stacks. SignRsaSha256 also has a buf overflow, but this isn't exploitable.<br />
The buffer for this is the buffer for the signature data. With v5.0, the signature buffer was moved to stack, with a check for the signature data size. When the signature data size is too large, Process9 uses [[SVC|svcBreak]].<br />
| ARM9 code execution<br />
| [[5.0.0-11|5.0.0-X]]<br />
| <br />
| 2012<br />
| <br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[PXI_Registers|PXI]] pxi_id bad check<br />
| The Process9 code responsible for [[PXI_Registers|PXI]] communications read pxi_id as a signed char. There were two flaws:<br />
* They used it as index to a lookup-table without checking the value at all.<br />
* Another function verified that pxi_id < 7, allowing negative values to pass the check. This would also cause an out-of-range table-lookup.<br />
| Maybe ARM9 code execution<br />
| [[3.0.0-5|3.0.0-5]]<br />
|<br />
| March 2015, originally 2012 for the first issue at least<br />
| <br />
| [[User:Plutooo|plutoo]], [[User:Yellows8|Yellows8]], maybe others(?)<br />
|}<br />
<br />
=== Kernel9 ===<br />
{| class="wikitable" border="1"<br />
|-<br />
! Summary<br />
! Description<br />
! Successful exploitation result<br />
! Fixed in [[FIRM]] system version<br />
! Last [[FIRM]] system version this flaw was checked for<br />
! Timeframe this was discovered<br />
! Discovered by<br />
|-<br />
| [[CONFIG Registers#CFG_SYSPROT9|CFG_SYSPROT9]] bit1 not set by Kernel9<br />
| Old versions of Kernel9 never set bit1 of [[CONFIG Registers#CFG_SYSPROT9|CFG_SYSPROT9]]. This leaves the [[OTP Registers|0x10012000]]-region unprotected (this region should be locked early during boot!). Since it's never locked, you can dump it once you get ARM9 code execution.<br />
<br />
From [[3.0.0-5|3.0.0-X]] this was fixed by setting the bit in Kernel9 after poking some registers in that region. On New3DS arm9loader sets this bit instead of Kernel9, which is exploitable through a hardware + software vulnerability (see arm9loaderhax / description).<br />
<br />
This flaw resurged when it gained a new practical use: retrieving the OTP data for a New3DS console in order to decrypt the key data used in arm9loader (see enhanced-arm9loaderhax / description). This was performed by downgrading to a vulnerable system version. By accounting for differences in CTR-NAND crypto (0x05 -> 0x04, see partition encryption types [[Flash_Filesystem#NAND_structure|here]]), it is possible to boot a New3DS using Old3DS firmware 1.0-2.X and an Old3DS [[NCSD#NCSD_header|NCSD Header]] to retrieve the required OTP data using this flaw.<br />
| Dumping of the [[OTP Registers|OTP]] area<br />
| [[3.0.0-5|3.0.0-X]]<br />
|<br />
| February 2015<br />
| [[User:Plutooo|plutoo]], Normmatt independently<br />
|}<br />
<br />
== ARM11 software ==<br />
=== Kernel11 ===<br />
{| class="wikitable" border="1"<br />
|-<br />
! Summary<br />
! Description<br />
! Successful exploitation result<br />
! Fixed in [[FIRM]] system version<br />
! Last [[FIRM]] system version this flaw was checked for<br />
! Timeframe this was discovered<br />
! Discovered by<br />
|-<br />
| [[SVC]] table too small<br />
| The table of function pointers for SVC's only contains entries up to 0x7D, but the biggest allowed SVC for the table is 0x7F. Thus, executing SVC7E or SVC7F would make the SVC-handler read after the buffer, and interpret some ARM instructions as function pointers.<br />
<br />
However, this would require patching the kernel .text or modifying SVC-access-control. Even if you could get these to execute, they would still jump to memory that isn't mapped as executable.<br />
| <br />
| None<br />
| [[11.1.0-34|11.1.0-X]]<br />
| 2012<br />
| Everyone<br />
|-<br />
| [[SVC|svcBackdoor (0x7B)]]<br />
| This backdoor allows executing SVC-mode code at the user-specified code-address. This is used by Process9, using this on the ARM11 (with NATIVE_FIRM) required patching the kernel .text or modifying SVC-access-control.<br />
| See description<br />
| [[11.0.0-33|11.0.0-X]] (deleted)<br />
| <br />
|<br />
| Everyone<br />
|-<br />
| [[Memory_layout#ARM11_Detailed_virtual_memory_map|0xEFF00000]] / 0xDFF00000 ARM11 kernel virtual-memory<br />
| The ARM11 kernel-mode 0xEFF00000/0xDFF00000 virtual-memory(size 0x100000) is mapped to phys-mem 0x1FF00000(entire DSP-mem + entire AXIWRAM), with permissions RW-. This is used during ARM11 kernel startup for loading the FIRM-modules from the FIRM section located in DSP-mem, this never seems to be used after that, however. This is never unmapped either.<br />
| <br />
| None<br />
| [[11.1.0-34|11.1.0-X]]<br />
| <br />
| <br />
|-<br />
| memchunkhax2.1<br />
| Nintendo's fix for memchunkhax2 in [[10.4.0-29|10.4.0-X]] did not fix the GPU case: one may cause the requisite ToCToU race using gspwn, bypassing the new validation.<br />
derrek's original 32c3 presentation for memchunkhax2 commented that a GPU-based attack was possible, but would be difficult. However, memchunkhax2.1 showed that it was possible to do fairly reliably.<br />
| ARM11 kernel code execution<br />
| None<br />
| [[10.4.0-29|10.4.0-X]]<br />
|<br />
| derrek, aliaspider<br />
|-<br />
| memchunkhax2<br />
| <br />
| ARM11 kernel code execution<br />
| [[10.4.0-29|10.4.0-X]] (partially)<br />
| [[10.4.0-29|10.4.0-X]]<br />
|<br />
| derrek<br />
|-<br />
| heaphax<br />
| Can change the size of free memchunk structures stored in FCRAM using DMA, which leads to the ability to allocate memory chunks over already-allocated memory. This can be used in the SYSTEM region to allocate RW memory over any part of the NS system module, which is enough to take it over.<br />
| Code execution with access to all of NS's privileges. (including downgrading) Code execution within any applet.<br />
| [[11.0.0-33|11.0.0-X]], via the new [[Memory_Management#MemoryBlockHeader|memchunkhdr]] MAC which prevents modifying memchunkhdr data with DMA.<br />
| [[11.0.0-33|11.0.0-X]]<br />
| April 2015 ?<br />
| smea<br />
|-<br />
| snshax<br />
| Can force creation of Safe NS process into gspwn-able memory, allowing for takeover.<br />
| Code execution with access to all of NS's privileges. (including downgrading)<br />
| [[10.1.0-27|10.1.0-X]]<br />
| [[10.1.0-27|10.1.0-X]]<br />
| April 2015 ?<br />
| smea<br />
|-<br />
| AffinityMask/processorid validation<br />
| With [[10.0.0-27|10.0.0-X]] the following functions were updated: svcGetThreadAffinityMask, svcGetProcessAffinityMask, svcSetProcessAffinityMask, and svcCreateThread. The code changes for all but svcCreateThread are identical.<br />
The original code with the first 3 did the following: <br />
* if(u32_processorcount > ~0x80000001)return 0xe0e01bfd;<br />
* if(s32_processorcount > <total_cores>)return 0xd8e007fd;<br />
The following code replaced the above:<br />
* if(u32_processorcount >= <total_cores+1>)return 0xd8e007fd;<br />
In theory the latter should catch everything that the former did, so it's unknown if this was really a security issue.<br />
<br />
The svcCreateThread changes with [[10.0.0-27|10.0.0-X]] definitely did fix a security issue.<br />
* Original code: "if(s32_processorid > <total_cores>)return 0xd8e007fd;"<br />
* New code: "if(s32_processorid >= <total_cores> || s32_processorid <= -4)return 0xd8e007fd;"<br />
This fixed an off-by-one issue: if one would use processorid=total_cores, which isn't actually a valid value, svcCreateThread would accept that value on <[[10.0.0-27|10.0.0-X]]. This results in data being written out-of-bounds(baseaddr = arrayaddr + entrysize*processorid), which has the following result:<br />
* Old3DS: Useless kernel-mode crash due to accessing unmapped memory.<br />
* New3DS: uncontrolled data write into a kernel-mode L1 MMU-table. This isn't really useful: the data can't be controlled, and the data which gets overwritten is all-zero anyway(this isn't anywhere near MMU L1 entries for actually mapped memory).<br />
The previous version also allowed large negative s32_processorid values(negative processorid values are special values not actual procids), but it appears using values like that won't actually do anything(meaning no crash) besides the thread not running / thread not running for a while(besides triggering a kernelpanic with certain s32_processorid value(s)).<br />
| Nothing useful<br />
| [[10.0.0-27|10.0.0-X]]<br />
| [[10.0.0-27|10.0.0-X]]<br />
| svcCreateThread issue: May 31, 2015. The rest: September 8, 2015, via v9.6->v10.0 ARM11-kernel code-diff.<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| memchunkhax<br />
| The kernel originally did not validate the data stored in the FCRAM kernel heap [[Memchunkhdr|memchunk-headers]] for free-memory at all. Exploiting this requires raw R/W access to these memchunk-headers, like physical-memory access with gspwn.<br />
<br />
There are ''multiple'' ways to exploit this, but the end-result for most of these is the same: overwrite code in AXIWRAM via the 0xEFF00000/0xDFF00000 kernel virtual-memory mapping.<br />
<br />
This was fixed in [[9.3.0-21|9.3.0-X]] by checking that the memchunk(including size, next, and prev ptrs) is located within the currently used heap memory. The kernel may also check that the next/prev ptrs are valid compared to other memchunk-headers basically. When any of these checks fail, kernelpanic() is called.<br />
| When combined with other flaws: ARM11-kernelmode code execution<br />
| [[9.3.0-21|9.3.0-21]]<br />
| <br />
| February 2014<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| Multiple [[KLinkedListNode|KLinkedListNode]] SlabHeap use after free bugs<br />
| The ARM11-kernel did access the 'key' field of [[KLinkedListNode|KLinkedListNode]] objects, which are located on the SlabHeap, after freeing them. Thus, triggering an allocation of a new [[KLinkedListNode|KLinkedListNode]] object at the right time could result in a type-confusion. Pseudo-code:<br />
SlabHeap_free(KLinkedListNode);<br />
KObject *obj = KLinkedListNode->key; // the object there might have changed!<br />
This bug appeared all over the place.<br />
| ARM11-kernelmode code exec maybe<br />
| [[8.0.0-18|8.0.0-18]]<br />
| <br />
| April 2015<br />
| [[User:Derrek|derrek]]<br />
|-<br />
| PXI [[RPC_Command_Structure|Command]] input/output buffer permissions<br />
| Originally the ARM11-kernel didn't check permissions for PXI input/output buffers for commands. Starting with [[6.0.0-11|6.0.0]] PXI input/output buffers must have RW permissions, otherwise kernelpanic is triggered.<br />
| <br />
| [[6.0.0-11|6.0.0-11]]<br />
| <br />
| 2012<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[SVC|svcStartInterProcessDma]]<br />
| For svcStartInterProcessDma, the kernel code had the following flaws:<br />
<br />
* Originally the ARM11-kernel read the input DmaConfig structure directly in kernel-mode(ldr(b/h) instructions), without checking whether the DmaConfig address is readable under userland. This was fixed by copying that structure to the SVC-mode stack, using the ldrbt instruction.<br />
<br />
* Integer overflows for srcaddr+size and dstaddr+size are now checked(with [[6.0.0-11]]), which were not checked before.<br />
<br />
* The kernel now also checks whether the srcaddr/dstaddr (+size) is within userland memory (0x20000000), the kernel now (with [[6.0.0-11]]) returns an error when the address is beyond userland memory. Using an address >=0x20000000 would result in the kernel reading from the process L1 MMU table, beyond the memory allocated for that MMU table(for vaddr->physaddr conversion). <br />
| <br />
| [[6.0.0-11]]<br />
| <br />
| DmaConfig issue: unknown. The rest: 2014<br />
| [[User:Plutooo|plutoo]], [[User:Yellows8|Yellows8]] independently<br />
|-<br />
| [[SVC|svcControlMemory]] Parameter checks<br />
| For svcControlMemory the parameter check had these two flaws:<br />
<br />
* The allowed range for addr0, addr1, size parameters depends on which MemoryOperation is being specified. The limitation for GSP heap was only checked if op=(u32)0x10003. By setting a random bit in op that has no meaning (like bit17?), op would instead be (u32)0x30003, and the range-check would be less strict and not accurate. However, the kernel doesn't actually use the input address for LINEAR memory-mapping at all besides the range-checks, so this isn't actually useful. This was fixed in the kernel by just checking for the LINEAR bit, instead of comparing the entire MemoryOperation value with 0x10003.<br />
<br />
* Integer overflows on (addr0+size) are now checked that previously weren't (this also applies to most other address checks elsewhere in the kernel).<br />
<br />
| <br />
| [[5.0.0-11]]<br />
| <br />
|<br />
| [[User:Plutooo|plutoo]]<br />
|-<br />
| [[RPC_Command_Structure|Command]] request/response buffer overflow<br />
| Originally the kernel did not check the word-values from the command-header. Starting with [[5.0.0-11]], the kernel will trigger a kernelpanic() when the total word-size of the entire command(including the cmd-header) is larger than 0x40-words (0x100-bytes). This allows overwriting threadlocalstorage+0x180 in the destination thread. However, since the data written there would be translate parameters (such as header-words + buffer addresses), exploiting this would likely be very difficult, if possible at all.<br />
<br />
If the two words at threadlocalstorage+0x180 could be overwritten with controlled data this way, one could then use a command with a buffer-header of <nowiki>((size<<14) | 2)</nowiki> to write arbitrary memory to any RW userland memory in the destination process.<br />
| <br />
| [[5.0.0-11]]<br />
| <br />
| v4.1 FIRM -> v5.0 code diff<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[SVC|SVC stack allocation overflows]]<br />
| <br />
* Syscalls that allocate a variable-length array on stack, only checked bit31 before multiplying by 4/16 (when calculating how much memory to allocate). If a large integer was passed as input to one of these syscalls, an integer overflow would occur, and too little memory would have been allocated on stack resulting in a buffer overrun. <br />
* The alignment (size+7)&~7 calculation before allocation was not checked for integer overflow.<br />
<br />
This might allow for ARM11 kernel code-execution.<br />
<br />
(Applies to svcSetResourceLimitValues, svcGetThreadList, svcGetProcessList, svcReplyAndReceive, svcWaitSynchronizationN.)<br />
| <br />
| [[5.0.0-11]]<br />
| <br />
| v4.1 FIRM -> v5.0 code diff<br />
| [[User:Plutooo|plutoo]], [[User:Yellows8|Yellows8]] complementary<br />
|-<br />
| [[SVC|svcControlMemory]] MemoryOperation MAP memory-permissions<br />
| svcControlMemory with MemoryOperation=MAP allows mapping the already-mapped process virtual-mem at addr1, to addr0. The lowest address permitted for addr1 is 0x00100000. Originally the ARM11 kernel didn't check memory permissions for addr1. Therefore .text as addr1 could be mapped elsewhere as RW- memory, which allowed ARM11 userland code-execution.<br />
| <br />
| [[4.1.0-8]]<br />
| <br />
| 2012<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[RPC_Command_Structure|Command]] input/output buffer permissions<br />
| Originally the ARM11 kernel didn't check memory permissions for the input/output buffers for commands. Starting with [[4.0.0-7]] the ARM11 kernel will trigger a kernelpanic() if the input/output buffers don't have the required memory permissions. For example, this allowed a FSUSER file-read to .text, which therefore allowed ARM11-userland code execution.<br />
| <br />
| [[4.0.0-7]]<br />
| <br />
| 2012<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[SVC|svcReadProcessMemory/svcWriteProcessMemory memory]] permissions<br />
| Originally the kernel only checked the first page(0x1000-bytes) of the src/dst buffers, for svcReadProcessMemory and svcWriteProcessMemory. There is no known retail processes which have access to these SVCs.<br />
| <br />
| [[4.0.0-7]]<br />
| <br />
| 2012?<br />
| [[User:Yellows8|Yellows8]]<br />
|}<br />
<br />
=== [[FIRM]] Sysmodules ===<br />
{| class="wikitable" border="1"<br />
|-<br />
! Summary<br />
! Description<br />
! Successful exploitation result<br />
! Fixed in [[FIRM]] system version<br />
! Last [[FIRM]] system version this flaw was checked for<br />
! Timeframe this was discovered<br />
! Discovered by<br />
|-<br />
| [[Services|"srv:pm"]] process registration<br />
| Originally any process had access to the port "srv:pm". The PID's used for the (un)registration commands are not checked either. This allowed any process to re-register itself with "srv:pm", and therefore allowed the process to give itself access to any service, bypassing the exheader service-access-control list.<br />
<br />
This was fixed in [[7.0.0-13]]: starting with [[7.0.0-13]] "srv:pm" is now a service instead of a globally accessible port. Only processes with PID's less than 6 (in other words: fs, ldr, sm, pm, pxi modules) have access to it. With [[7.0.0-13]] there can only be one session for "srv:pm" open at a time(this is used by pm module), svcBreak will be executed if more sessions are opened by the processes which can access this.<br />
<br />
This flaw was needed for exploiting the <=v4.x Process9 PXI vulnerabilities from ARM11 userland ROP, since most applications don't have access to those service(s).<br />
| Access to arbitrary services<br />
| [[7.0.0-13]]<br />
| <br />
| 2012<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| FSDIR null-deref<br />
| [[Filesystem_services|FS]]-module may crash in some cases when handling directory reading. The trigger seems to be due to using [[FSDir:Close]] without closing the dir-handle afterwards?(Perhaps this is caused by out-of-memory?) This seems to be useless since it's just a null-deref.<br />
| <br />
| None<br />
| [[9.6.0-24|9.6.0-X]]<br />
| May 19(?)-20, 2015<br />
| [[User:Yellows8|Yellows8]]<br />
|}<br />
<br />
=== Standalone Sysmodules ===<br />
{| class="wikitable" border="1"<br />
|-<br />
! Summary<br />
! Description<br />
! Successful exploitation result<br />
! Fixed in system-module system-version<br />
! Last system-module system-version this flaw was checked for<br />
! Timeframe this was discovered<br />
! Timeframe this was added to wiki<br />
! Discovered by<br />
|-<br />
| [[MVD_Services|MVD]]: Stack buffer overflow with [[MVDSTD:SetupOutputBuffers]].<br />
| The input total_entries is not validated when initially processing the input entry-list. This fixed-size input entry-list is copied to stack from the command request. The loop for processing this initializes a global table, the converted linearmem->physaddrs used there are also copied to stack(0x8-bytes of physaddrs per entry).<br />
<br />
If total_entries is too large, MVD-sysmodule will crash due to reading unmapped memory following the stack(0x10000000). Afterwards if the out-of-bounds total_entries is smaller than that, it will crash due accessing address 0x0, hence this useless.<br />
| MVD-sysmodule crash.<br />
| None<br />
| [[9.0.0-20]]<br />
| April 22, 2016 (Tested on the 25th)<br />
| April 25, 2016<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[NWM_Services|NWM]]: Using CTRSDK heap with UDS sharedmem from the user-process.<br />
| See the HTTP-sysmodule section below.<br />
<br />
CTRSDK heap is used with the sharedmem from [[NWMUDS:InitializeWithVersion]]. Buffers are allocated/freed under this heap using [[NWMUDS:Bind]] and [[NWMUDS:Unbind]].<br />
<br />
Hence, overwriting sharedmem with gspwn then using [[NWMUDS:Unbind]] results in the usual controlled CTRSDK memchunk-header write, similar to HTTP-sysmodule.<br />
<br />
This could be done by creating an UDS network, without any other nodes on the network.<br />
<br />
Besides CTRSDK memchunk-headers, there are no addresses stored under this sharedmem.<br />
| ROP under NWM-module.<br />
| None<br />
| [[9.0.0-20|9.0.0-X]]<br />
| April 10, 2016<br />
| April 16, 2016<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[DLP_Services|DLP]]: Out-of-bounds memory access during spectator [[Download_Play|data-frame]] checksum calculation<br />
| DLP doesn't validate the frame_size when receiving spectator data-frames at all, unlike non-spectator data-frames. The actual spectator data-frame parsing code doesn't use that field either. However, the data-frame checksum calculation code called during checksum verification does use the frame_size for loading the size of the framebuf.<br />
<br />
Hence, using a large frame_size like 0xFFFF will result in the checksum calculation code reading data out-of-bounds. This isn't really useful, you could trigger a remote local-WLAN DLP-sysmodule crash while a 3DS system is scanning for DLP networks(due to accessing unmapped memory), but that's about all(trying to infoleak with this likely isn't useful either).<br />
| DLP-sysmodule crash, handled by dlplay system-application by a "connection interrupted" error eventually then a fatal-error via ErrDisp.<br />
| None<br />
| [[10.0.0-27|10.0.0-X]]<br />
| April 8, 2016 (Tested on the 10th)<br />
| April 10, 2016<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[DLP_Services|DLP]]: Out-of-bounds output data writing during spectator sysupdate titlelist [[Download_Play|data-frame]] handling<br />
| The total_entries and out_entryindex fields for the titlelist DLP spectator data-frames are not validated. This is parsed during DLP network scanning. Hence, the specified titlelist data can be written out-of-bounds using the specified out_entryindex and total_entries. A crash will occur while reading the input data-frame titlelist if total_entries is larger than 0x27A, due to accessing unmapped memory.<br />
<br />
There's not much non-zero data to overwrite following the output buffer(located in sharedmem), any ptrs are located in sharedmem. Overwriting certain ptr(s) are only known to cause a crash when attempting to use the DLP-client shutdown service-command.<br />
<br />
There's no known way to exploit the above crash, since the linked-list code involves writes zeros(with a controlled start ptr).<br />
| <br />
| None<br />
| [[10.0.0-27|10.0.0-X]]<br />
| April 8-9, 2016<br />
| April 10, 2016<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[IR_Services|IR]]: Stack buffer overflow with custom hardware<br />
| Originally IR sysmodule used the read value from the I2C-IR registers TXLVL and RXLVL without validating them at all. See [[10.6.0-31|here]] for the fix. This is the size used for reading the data-recv FIFO, etc. The output buffer for reading is located on the stack.<br />
<br />
This should be exploitable if one could successfully setup the custom hardware for this and if the entire intended sizes actually get read from I2C.<br />
| ROP under IR sysmodule.<br />
| [[10.6.0-31|10.6.0-31]]<br />
| <br />
| February 23, 2016 (Unknown if it was noticed before then)<br />
| February 23, 2016<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[HTTP_Services|HTTP]]: Using CTRSDK heap with sharedmem from the user-process.<br />
| The data from httpcAddPostDataAscii and other commands is stored under a CTRSDK heap. That heap is the sharedmem specified by the user-process via the HTTPC Initialize command.<br />
Normally this sharedmem isn't accessible to the user-process once the sysmodule maps it, hence using it is supposed to be "safe".<br />
<br />
This isn't the case due to gspwn however. Since CTRSDK heap code is so insecure in general, one can use gspwn to locate the HTTPC sharedmem + read/write it, then trigger a mem-write under the sysmodule. This can then be used to get ROP going under HTTP-sysmodule.<br />
<br />
This is exploited by [https://github.com/yellows8/ctr-httpwn/ctr-httpwn ctr-httpwn].<br />
| ROP under HTTP sysmdule.<br />
| None<br />
| [[9.6.0-24|9.6.0-X]] (Latest sysmodule version as of [[10.7.0-32|10.7.0-32]])<br />
| Late 2015<br />
| March 22, 2016<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[NIM_Services|NIM]]: Downloading old title-versions from eShop<br />
| Multiple NIM service commands(such as [[NIMS:StartDownload]]) use a title-version value specified by the user-process, NIM does not validate that this input version matches the latest version available via SOAP. Therefore, when combined with AM(PXI) [[#Process9|title-downgrading]] via deleting the target eShop title with System Settings Data Management(if the title was already installed), this allows downloading+installing any title-version from eShop ''if'' it's still available from CDN.<br />
The easiest way to exploit this is to just patch the eShop system-application code using these NIM commands(ideally the code which loads the title-version).<br />
<br />
Originally this was tested with a debugging-system via modded-FIRM, eventually smea implemented it in HANS for the 32c3 release.<br />
| Downloading old title-versions from eShop<br />
| None<br />
| [[10.0.0-27|10.0.0-X]]<br />
| October 24, 2015 (Unknown when exactly the first eShop title downgrade was actually tested, maybe November)<br />
| January 7, 2016 (Same day Ironfall v1.0 was removed from CDN via the main-CXI files)<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[SPI_Services|SPI]] service out-of-bounds write<br />
| cmd1 has out-of-bounds write allowing overwrite of some static variables in .data.<br />
| <br />
| None<br />
| [[9.5.0-22]]<br />
| March 2015<br />
| <br />
| [[User:Plutooo|plutoo]]<br />
|-<br />
| [[NFC_Services|NFC]] module service command buf-overflows<br />
| NFC module copies data with certain commands, from command input buffers to stack without checking the size. These commands include the following, it's unknown if there's more commands with similar issues: "nfc:dev" <0x000C....> and "nfc:s" <0x0037....>.<br />
Since both of these commands are stubbed in the Old3DS NFC module from the very first version(those just return an error), these issues only affect the New3DS NFC module.<br />
<br />
There's no known retail titles which have access to either of these services.<br />
| ROP under NFC module.<br />
| New3DS: None<br />
| New3DS: [[9.5.0-22]]<br />
| December 2014?<br />
| <br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[News_Services|NEWSS]] service command notificationID validation failure<br />
| This module does not validate the input notificationID for <nowiki>"news:s"</nowiki> service commands. This is an out-of-bounds array index bug. For example, [[NEWSS:SetNotificationHeader]] could be used to exploit news module: this copies the input data(size is properly checked) to: out = newsdb_savedata+0x10 + (someu32array[notificationID]*0x70).<br />
| ROP under news module.<br />
| None<br />
| [[9.7.0-25|9.7.0-X]]<br />
| December 2014<br />
| <br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[NWMUDS:DecryptBeaconData]] heap buffer overflow<br />
| input_size = 0x1E * <value the u8 from input_[[NWM_Services|networkstruct]]+0x1D>. Then input_tag0 is copied to a heap buffer. When input_size is larger than 0xFA-bytes, it will then copy input_tag1 to <end_address_of_previous_outbuf>, with size=input_size-0xFA.<br />
<br />
This can be triggered by either using this command directly, or by boadcasting a wifi beacon which triggers it while a 3DS system running the target process is in range, when the process is scanning for hosts to connect to. Processes will only pass tag data to this command when the wlancommID and other thing(s) match the values for the process.<br />
<br />
There's no known way to actually exploit this for getting ROP under NWM-module, at the time of originally adding this to the wiki. This is because the data which gets copied out-of-bounds *and* actually causes crash(es), can't be controlled it seems(with just broadcasting a beacon at least). It's unknown whether this could be exploited from just using NWMUDS service-cmd(s) directly.<br />
| Without any actual way to exploit this: NWM-module DoS, resulting in process termination(process crash). This breaks *everything* involving wifi comms, a reboot is required to recover from this.<br />
| None<br />
| [[9.0.0-20]]<br />
| ~September 23, 2014(see the [[NWMUDS:DecryptBeaconData]] page history)<br />
| August 3, 2015<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[HID_Services|HID]] module shared-mem<br />
| HID module does not validate the index values in [[HID_Shared_Memory|sharedmem]](just changes index to 0 when index == maxval when updating), therefore large values will result in HID module writing HID data to arbitrary addresses.<br />
| ROP under HID module, but this is *very* unlikely to be exploitable since the data written is HID data.<br />
| None<br />
| [[9.3.0-21]]<br />
| 2014?<br />
| <br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| gspwn<br />
| GSP module does not validate addresses given to the GPU. This allows a user-mode application/applet to read/write to a large part of physical FCRAM using GPU DMA. From this, you can overwrite the .text segment of the application you're running under, and gain real code-execution from a ROP-chain. Normally applets' .text([[Home Menu]], [[Internet Browser]], etc) is located beyond the area accessible by the GPU, except for [[RO_Services|CROs]] used by applets([[Internet Browser]] for example).<br />
<br />
FCRAM is gpu-accessible up to physaddr 0x26800000 on Old3DS, and 0x2DC00000 on New3DS. This is BASE_memregion_start(aka SYSTEM_memregion_end)-0x400000 with the default memory-layout on Old3DS/New3DS.<br />
| User-mode code execution.<br />
| None<br />
| [[9.6.0-24|9.6.0-X]]<br />
| Early 2014<br />
| <br />
| smea, [[User:Yellows8|Yellows8]]/others before then<br />
|-<br />
| rohax<br />
| Using gspwn, it is possible to overwrite a loaded [[CRO0]]/[[CRR0]] after its RSA-signature has been validated. Badly validated [[CRO0]] header leads to arbitrary read/write of memory in the ro-process. This gives code-execution in the ro module, who has access to [[SVC|syscalls]] 0x70-0x72, 0x7D.<br />
<br />
This was fixed after [[ninjhax]] release by adding checks on [[CRO0]]-based pointers before writing to them.<br />
| Memory-mapping syscalls.<br />
| [[9.3.0-21]]<br />
| [[9.4.0-21]]<br />
| <br />
| <br />
| smea, [[User:Plutooo|plutoo]] joint effort<br />
|-<br />
| Region free<br />
| Only [[Home Menu]] itself checks gamecards' region when launching them. Therefore, any application launch that is done directly with [[NS]] without signaling Home Menu to launch the app, will result in region checks being bypassed.<br />
This essentially means launching the gamecard with the [[NS_and_APT_Services|"ns:s"]] service. The main way to exploit this is to trigger a FIRM launch with an application specified, either with a normal FIRM launch or a hardware [[NSS:RebootSystem|reboot]].<br />
| Launching gamecards from any region + bypassing Home Menu gamecard-sysupdate installation<br />
| None<br />
| Last tested with [[10.1.0-27|10.1.0-X]].<br />
| June(?) 2014<br />
| <br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[NWM_Services|NWM]] service-cmd state null-ptr deref<br />
| The NWMUDS service command code loads a ptr from .data, adds an offset to that, then passes that as the state address for the actual command-handler function. The value of the ptr loaded from .data is not checked, therefore this will cause crashes due to that being 0x0 when NWMUDS was not properly initialized.<br />
It's unknown whether any NWM services besides NWMUDS have this issue.<br />
| This is rather useless since it's only a crash caused by a state ptr based at 0x0.<br />
| None<br />
| [[9.0.0-20]]<br />
| 2013?<br />
| <br />
| [[User:Yellows8|Yellows8]]<br />
|}<br />
<br />
=== General/CTRSDK ===<br />
{| class="wikitable" border="1"<br />
|-<br />
! Summary<br />
! Description<br />
! Successful exploitation result<br />
! Fixed in version<br />
! Last version this flaw was checked for<br />
! Timeframe this was discovered<br />
! Discovered by<br />
|-<br />
| [[NWM_Services|UDS]] beacon additional-data buffer overflow<br />
| Originally CTRSDK did not validate the UDS additional-data size before using that size to copy the additional-data to a [[NWM_Services|networkstruct]]. This was eventually fixed.<br />
This was discovered while doing code RE with an old dlp-module version. It's unknown in what specific CTRSDK version this was fixed, or even what system-version updated titles with a fixed version.<br />
<br />
It's unknown if there's any titles using a vulnerable CTRSDK version which are also exploitable with this(dlp module can't be exploited with this).<br />
<br />
The maximum number of bytes that can be written beyond the end of the outbuf is 0x37-bytes, with additionaldata_size=0xFF.<br />
| Perhaps ROP, very difficult if possible with anything at all<br />
| ?<br />
| <br />
| September(?) 2014<br />
| [[User:Yellows8|Yellows8]]<br />
|}</div>Mrrraouhttps://www.3dbrew.org/w/index.php?title=NS_and_APT_Services&diff=18243NS and APT Services2016-09-17T20:32:35Z<p>Mrrraou: /* DisplayBufferMode */</p>
<hr />
<div>[[Category:Services]]<br />
The NS ('''N'''intendo User Interface '''S'''hell) system module is the first module launched from a CTR-NAND title after the [[FIRM]] processes are loaded (also see [[Bootloader]]). This module is launched by the pm process, with the titleID loaded from NS state(hard-coded TID initialized during applet TID-array initialization). NS first launches [[ErrDisp]], then the menu. On retail the menu TID is loaded from NS state, while on dev/debug the menu TID is loaded from [[Config_Savegame|config]]. On dev-units if the menu TID block doesn't exist in [[Config_Savegame|config]], NS will attempt to launch the alternate menu instead. The TID of the launched menu is then written to [[Configuration Memory|ACTIVEMENUTID]]. NS uses [[PMApp:LaunchTitle|pm:app]] to launch titles.<br />
<br />
NS will not trigger the [[ErrDisp|fatal-error]] screen when launching the regular/alternate menu fails.<br />
<br />
Like home menu NS is constantly running while the system is in 3DS-mode. When attempting to return to home-menu when the home-menu process isn't running(like when the process terminated/crashed), NS will trigger a [[ErrDisp|fatal]] error.<br />
<br />
= Alternate menu =<br />
When launching the regular menu fails, NS will then attempt to launch the alternate menu. This title could be used as a recovery process, however it's normally not used after the factory.<br />
<br />
At the factory for all 3DS systems, [[3DS Development Unit GUI#Test Menu|Test Menu]] is installed with this TID. On retail this title is eventually deleted during [[Factory Setup]].<br />
<br />
= Auto-boot =<br />
After [[PMApp:GetFIRMLaunchParams|loading]] [[FIRM]] params and prior to launching [[ErrDisp]]/Home Menu, NS handles auto-booting titles. The same code called by [[APT:Reboot]] is used for launching FIRM here. When the [[Configuration_Memory|UPDATEFLAG]] is set, NS will launch SAFE_MODE_FIRM with the application titleID set to the [[System_Settings#System_Updater|System Updater]] titleID for this region. When the UPDATEFLAG is not set, NS can auto-boot the following titles as well if [[Configuration_Memory|0x1FF80016]] bit0 is set.<br />
<br />
When bit1 and bit2 are value zero in [[Configuration_Memory|0x1FF80016]], NS will [[NSS:LaunchFIRM|launch]] the title specified by the [[FIRM]] parameters if the title-info is set. This FIRM launch is done after launching [[ErrDisp]] and Home Menu. Otherwise when [[Configuration_Memory|0x1FF80016]] is value 2 and the output u8 from [[PTM|PTMSYSM]] command 0x08140000 is value 0, NS will boot the title specified from the TWL TLNC block from FIRMparams+0x300. This is the same TLNC block which DSi titles wrote to RAM+0x300 for launching other titles via the launcher title. When handling the TLNC block, NS will boot the 3DS System Settings title when the TLNC titleID is the DSi System Settings titleID(the region field in the TLNC TID is not checked/used). When the TLNC titleID is not System Settings, NS will convert the input DSi titleID-high to the 3DS TWL titleID-high(tidhigh = (TLNCtidhigh & 0x7FFF) | 0x48000), then launch TWL_FIRM to run the title. NS does not support launching from gamecard via TLNC.<br />
<br />
= NS Workaround =<br />
A "ns_workaround" was [[5.1.0-11|added]] in NS to workaround the flaw added with [[5.0.0-11]]. When NS is loading before launching any ARM11 processes and certain [[Configuration Memory]] fields are set, NS will launch [[Application_Manager_Services|AM]] then use command [[AM:InstallNATIVEFIRM]]. NS will then execute the code called by [[APT:StartNewestHomeMenu]], the code related to APT:PrepareToStartNewestHomeMenu is not executed here.<br />
<br />
NS will only execute this code-path when [[Configuration Memory|0x1FF80016]] is value zero, when KERNEL_VERSIONMAJOR is value 2, and when KERNEL_VERSIONMINOR is less than 35. Therefore, this code-path is only executed when the running NATIVE_FIRM version is prior to [[5.0.0-11]].<br />
<br />
= NS Service "ns:s" =<br />
{| class="wikitable" border="1"<br />
|-<br />
! Command Header<br />
! Available since system version<br />
! Description<br />
|-<br />
| 0x000100C0<br />
| [[1.0.0-0]] - [[2.0.0-2]]<br />
| [[NSS:LaunchFIRM|LaunchFIRM]]<br />
|-<br />
| 0x000200C0<br />
| [[1.0.0-0]] - [[2.0.0-2]]<br />
| [[NSS:LaunchTitle|LaunchTitle]]<br />
|-<br />
| 0x00030000<br />
| [[1.0.0-0]] - [[2.0.0-2]]<br />
| [[NSS:TerminateApplication|TerminateApplication]]<br />
|-<br />
| 0x00040040<br />
| [[1.0.0-0]] - [[2.0.0-2]]<br />
| [[NSS:TerminateProcess|TerminateProcess]]<br />
|-<br />
| 0x000500C0<br />
| [[1.0.0-0]] - [[2.0.0-2]]<br />
| [[NSS:LaunchApplicationFIRM|LaunchApplicationFIRM]]<br />
|-<br />
| 0x00060042<br />
| [[1.0.0-0]] - [[2.0.0-2]]<br />
| [[NSS:SetWirelessRebootInfo|SetWirelessRebootInfo]]<br />
|-<br />
| 0x00070042<br />
| [[1.0.0-0]] - [[2.0.0-2]]<br />
| [[NSS:CardUpdateInitialize|CardUpdateInitialize]]<br />
|-<br />
| 0x00080000<br />
| [[1.0.0-0]] - [[2.0.0-2]]<br />
| [[NSS:CardUpdateShutdown|CardUpdateShutdown]]<br />
|-<br />
| 0x00090000<br />
| [[1.0.0-0]] - [[2.0.0-2]]<br />
| Gamecard system update related.<br />
|-<br />
| 0x000A0000<br />
| [[1.0.0-0]] - [[2.0.0-2]]<br />
| Gamecard system update related.<br />
|-<br />
| 0x000B0000<br />
| [[1.0.0-0]] - [[2.0.0-2]]<br />
| Gamecard system update related.<br />
|-<br />
| 0x000C0000<br />
| [[1.0.0-0]] - [[2.0.0-2]]<br />
| Gamecard system update related.<br />
|-<br />
| 0x000D0140<br />
| [[1.0.0-0]] - [[2.0.0-2]]<br />
| [[NSS:SetTWLBannerHMAC|SetTWLBannerHMAC]]<br />
|-<br />
| 0x000E0000<br />
| [[1.0.0-0]] - [[2.0.0-2]]<br />
| [[NSS:ShutdownAsync|ShutdownAsync]]<br />
|-<br />
| 0x000F0000<br />
| [[1.0.0-0]] - [[2.0.0-2]]<br />
| This calls [[APT:AppletUtility]] with fixed input params.<br />
|-<br />
| 0x00100180<br />
| [[1.0.0-0]] - [[2.0.0-2]]<br />
| [[NSS:RebootSystem|RebootSystem]]<br />
|-<br />
| 0x00110100<br />
| [[1.0.0-0]] - [[2.0.0-2]]<br />
| [[NSS:TerminateTitle|TerminateTitle]]<br />
|-<br />
| 0x001200C0<br />
| ?<br />
| [[NSS:SetApplicationCpuTimeLimit|SetApplicationCpuTimeLimit]]<br />
|-<br />
| 0x00130000<br />
| ?<br />
| ?<br />
|-<br />
| 0x00140042<br />
| ?<br />
| ?<br />
|-<br />
| 0x00150140<br />
| ?<br />
| [[NSS:LaunchApplication|LaunchApplication]]<br />
|-<br />
| 0x00160000<br />
| [[8.0.0-18]]<br />
| [[NSS:RebootSystemClean|RebootSystemClean]]<br />
|}<br />
<br />
The maximum sessions that can be used with this service is two, therefore only two processes can use this service at the same time.<br />
<br />
=NS Power Service "ns:p"=<br />
{| class="wikitable" border="1"<br />
|-<br />
! Command Header<br />
! Description<br />
|-<br />
| 0x00010040<br />
| [[NSP:RebootSystem|RebootSystem]]<br />
|-<br />
| 0x00020000<br />
| [[NSS:ShutdownAsync|ShutdownAsync]]<br />
|}<br />
<br />
This was added with [[3.0.0-5]]. The PTM sysmodule connects to this service, and syncs whenever [[PTM|ptm:s GetShellState()]] changes.<br />
<br />
=NS Service "ns:c"=<br />
{| class="wikitable" border="1"<br />
|-<br />
! Command Header<br />
! Description<br />
|-<br />
| 0x00010100<br />
| ?<br />
|-<br />
| 0x00020100<br />
| ?<br />
|}<br />
<br />
This was added with [[5.0.0-11]], it's unknown what this is used for.<br />
<br />
=APT Services=<br />
{| class="wikitable" border="1"<br />
|-<br />
! Command Header<br />
! Available since system version<br />
! Accessible with APT:U<br />
! Description<br />
|-<br />
| 0x00010040<br />
| <br />
| Yes<br />
| [[APT:GetLockHandle|GetLockHandle]]<br />
|-<br />
| 0x00020080<br />
| <br />
| See [[APT:Initialize|here]].<br />
| [[APT:Initialize|Initialize]]<br />
|-<br />
| 0x00030040<br />
| <br />
| Yes<br />
| [[APT:Enable|Enable]]<br />
|-<br />
| 0x00040040<br />
| <br />
| Yes<br />
| [[APT:Finalize|Finalize]]<br />
|-<br />
| 0x00050040<br />
| <br />
| Yes<br />
| [[APT:GetAppletManInfo|GetAppletManInfo]]<br />
|-<br />
| 0x00060040<br />
| <br />
| Yes<br />
| [[APT:GetAppletInfo|GetAppletInfo]]<br />
|-<br />
| 0x00070000<br />
| <br />
| Yes<br />
| [[APT:GetLastSignaledAppletId|GetLastSignaledAppletId]]<br />
|-<br />
| 0x00080000<br />
| <br />
| Yes<br />
| [[APT:CountRegisteredApplet|CountRegisteredApplet]]<br />
|-<br />
| 0x00090040<br />
| <br />
| Yes<br />
| [[APT:IsRegistered|IsRegistered]]<br />
|-<br />
| 0x000A0040<br />
| <br />
| Yes<br />
| [[APT:GetAttribute|GetAttribute]]<br />
|-<br />
| 0x000B0040<br />
| <br />
| Yes<br />
| [[APT:InquireNotification|InquireNotification]]<br />
|-<br />
| 0x000C0104<br />
| <br />
| Yes<br />
| [[APT:SendParameter|SendParameter]]<br />
|-<br />
| 0x000D0080<br />
| <br />
| Yes<br />
| [[APT:ReceiveParameter|ReceiveParameter]]<br />
|-<br />
| 0x000E0080<br />
| <br />
| Yes<br />
| [[APT:GlanceParameter|GlanceParameter]]<br />
|-<br />
| 0x000F0100<br />
| <br />
| Yes<br />
| [[APT:CancelParameter|CancelParameter]]<br />
|-<br />
| 0x001000C2<br />
| <br />
| Yes<br />
| [[APT:DebugFunc|DebugFunc]]<br />
|-<br />
| 0x001100C0<br />
| <br />
| Yes<br />
| [[APT:MapProgramIdForDebug|MapProgramIdForDebug]]<br />
|-<br />
| 0x00120040<br />
| <br />
| Yes<br />
| [[APT:SetHomeMenuAppletIdForDebug|SetHomeMenuAppletIdForDebug]]<br />
|-<br />
| 0x00130000<br />
| <br />
| Yes<br />
| [[APT:GetPreparationState|GetPreparationState]]<br />
|-<br />
| 0x00140040<br />
| <br />
| Yes<br />
| [[APT:SetPreparationState|SetPreparationState]]<br />
|-<br />
| 0x00150140<br />
| <br />
| No<br />
| [[APT:PrepareToStartApplication|PrepareToStartApplication]]<br />
|-<br />
| 0x00160040<br />
| <br />
| Yes<br />
| [[APT:PreloadLibraryApplet|PreloadLibraryApplet]]<br />
|-<br />
| 0x00170040<br />
| <br />
| Yes<br />
| [[APT:FinishPreloadingLibraryApplet|FinishPreloadingLibraryApplet]]<br />
|-<br />
| 0x00180040<br />
| <br />
| Yes<br />
| [[APT:PrepareToStartLibraryApplet|PrepareToStartLibraryApplet]]<br />
|-<br />
| 0x00190040<br />
| <br />
| Yes<br />
| [[APT:PrepareToStartSystemApplet|PrepareToStartSystemApplet]]<br />
|-<br />
| 0x001A0000<br />
| <br />
| Yes<br />
| [[APT:PrepareToStartNewestHomeMenu|PrepareToStartNewestHomeMenu]]<br />
|-<br />
| 0x001B00C4<br />
| <br />
| Yes<br />
| [[APT:StartApplication|StartApplication]]<br />
|-<br />
| 0x001C0000<br />
| <br />
| Yes<br />
| [[APT:WakeupApplication|WakeupApplication]]<br />
|-<br />
| 0x001D0000<br />
| <br />
| Yes<br />
| [[APT:CancelApplication|CancelApplication]]<br />
|-<br />
| 0x001E0084<br />
| <br />
| Yes<br />
| [[APT:StartLibraryApplet|StartLibraryApplet]]<br />
|-<br />
| 0x001F0084<br />
| <br />
| Yes<br />
| [[APT:StartSystemApplet|StartSystemApplet]]<br />
|-<br />
| 0x00200044<br />
| <br />
| Yes<br />
| [[APT:StartNewestHomeMenu|StartNewestHomeMenu]]<br />
|-<br />
| 0x00210000<br />
| <br />
| No<br />
| [[APT:OrderToCloseApplication|OrderToCloseApplication]]<br />
|-<br />
| 0x00220040<br />
| <br />
| Yes<br />
| [[APT:PrepareToCloseApplication|PrepareToCloseApplication]]<br />
|-<br />
| 0x00230040<br />
| <br />
| Yes<br />
| [[APT:PrepareToJumpToApplication|PrepareToJumpToApplication]]<br />
|-<br />
| 0x00240044<br />
| <br />
| Yes<br />
| [[APT:JumpToApplication|JumpToApplication]]<br />
|-<br />
| 0x002500C0<br />
| <br />
| Yes<br />
| [[APT:PrepareToCloseLibraryApplet|PrepareToCloseLibraryApplet]]<br />
|-<br />
| 0x00260000<br />
| <br />
| Yes<br />
| [[APT:PrepareToCloseSystemApplet|PrepareToCloseSystemApplet]]<br />
|-<br />
| 0x00270044<br />
| <br />
| Yes<br />
| [[APT:CloseApplication|CloseApplication]]<br />
|-<br />
| 0x00280044<br />
| <br />
| Yes<br />
| [[APT:CloseLibraryApplet|CloseLibraryApplet]]<br />
|-<br />
| 0x00290044<br />
| <br />
| Yes<br />
| [[APT:CloseSystemApplet|CloseSystemApplet]]<br />
|-<br />
| 0x002A0000<br />
| <br />
| Yes<br />
| [[APT:OrderToCloseSystemApplet|OrderToCloseSystemApplet]]<br />
|-<br />
| 0x002B0000<br />
| <br />
| Yes<br />
| [[APT:PrepareToJumpToHomeMenu|PrepareToJumpToHomeMenu]]<br />
|-<br />
| 0x002C0044<br />
| <br />
| Yes<br />
| [[APT:JumpToHomeMenu|JumpToHomeMenu]]<br />
|-<br />
| 0x002D0000<br />
| <br />
| Yes<br />
| [[APT:PrepareToLeaveHomeMenu|PrepareToLeaveHomeMenu]]<br />
|-<br />
| 0x002E0044<br />
| <br />
| Yes<br />
| [[APT:LeaveHomeMenu|LeaveHomeMenu]]<br />
|-<br />
| 0x002F0040<br />
| <br />
| Yes<br />
| [[APT:PrepareToLeaveResidentApplet|PrepareToLeaveResidentApplet]]<br />
|-<br />
| 0x00300044<br />
| <br />
| Yes<br />
| [[APT:LeaveResidentApplet|LeaveResidentApplet]]<br />
|-<br />
| 0x00310100<br />
| <br />
| Yes<br />
| [[APT:PrepareToDoApplicationJump|PrepareToDoApplicationJump]]<br />
|-<br />
| 0x00320084<br />
| <br />
| Yes<br />
| [[APT:DoApplicationJump|DoApplicationJump]]<br />
|-<br />
| 0x00330000<br />
| <br />
| Yes<br />
| [[APT:GetProgramIdOnApplicationJump|GetProgramIdOnApplicationJump]]<br />
|-<br />
| 0x00340084<br />
| <br />
| Yes<br />
| [[APT:SendDeliverArg|SendDeliverArg]]<br />
|-<br />
| 0x00350080<br />
| <br />
| Yes<br />
| [[APT:ReceiveDeliverArg|ReceiveDeliverArg]]<br />
|-<br />
| 0x00360040<br />
| <br />
| Yes<br />
| [[APT:LoadSysMenuArg|LoadSysMenuArg]]<br />
|-<br />
| 0x00370042<br />
| <br />
| Yes<br />
| [[APT:StoreSysMenuArg|StoreSysMenuArg]]<br />
|-<br />
| 0x00380040<br />
| <br />
| Yes<br />
| [[APT:PreloadResidentApplet|PreloadResidentApplet]]<br />
|-<br />
| 0x00390040<br />
| <br />
| Yes<br />
| [[APT:PrepareToStartResidentApplet|PrepareToStartResidentApplet]]<br />
|-<br />
| 0x003A0044<br />
| <br />
| Yes<br />
| [[APT:StartResidentApplet|StartResidentApplet]]<br />
|-<br />
| 0x003B0040<br />
| <br />
| Yes<br />
| [[APT:CancelLibraryApplet|CancelLibraryApplet]]<br />
|-<br />
| 0x003C0042<br />
| <br />
| Yes<br />
| [[APT:SendDspSleep|SendDspSleep]]<br />
|-<br />
| 0x003D0042<br />
| <br />
| Yes<br />
| [[APT:SendDspWakeUp|SendDspWakeUp]]<br />
|-<br />
| 0x003E0080<br />
| <br />
| Yes<br />
| [[APT:ReplySleepQuery|ReplySleepQuery]]<br />
|-<br />
| 0x003F0040<br />
| <br />
| Yes<br />
| [[APT:ReplySleepNotificationComplete|ReplySleepNotificationComplete]]<br />
|-<br />
| 0x00400042<br />
| <br />
| Yes<br />
| [[APT:SendCaptureBufferInfo|SendCaptureBufferInfo]]<br />
|-<br />
| 0x00410040<br />
| <br />
| Yes<br />
| [[APT:ReceiveCaptureBufferInfo|ReceiveCaptureBufferInfo]]<br />
|-<br />
| 0x00420080<br />
| <br />
| Yes<br />
| [[APT:SleepSystem|SleepSystem]]<br />
|-<br />
| 0x00430040<br />
| <br />
| Yes<br />
| [[APT:NotifyToWait|NotifyToWait]]<br />
|-<br />
| 0x00440000<br />
| <br />
| Yes<br />
| [[APT:GetSharedFont|GetSharedFont]]<br />
|-<br />
| 0x00450040<br />
| <br />
| Yes<br />
| [[APT:GetWirelessRebootInfo|GetWirelessRebootInfo]]<br />
|-<br />
| 0x00460104<br />
| <br />
| Yes<br />
| [[APT:Wrap|Wrap]]<br />
|-<br />
| 0x00470104<br />
| <br />
| Yes<br />
| [[APT:Unwrap|Unwrap]]<br />
|-<br />
| 0x00480100<br />
| <br />
| No<br />
| [[APT:GetProgramInfo|GetProgramInfo]]<br />
|-<br />
| 0x00490180<br />
| <br />
| No<br />
| [[APT:Reboot|Reboot]]<br />
|-<br />
| 0x004A0040<br />
| <br />
| Yes<br />
| [[APT:GetCaptureInfo|GetCaptureInfo]]<br />
|-<br />
| 0x004B00C2<br />
| <br />
| Yes<br />
| [[APT:AppletUtility|AppletUtility]]<br />
|-<br />
| 0x004C0000<br />
| <br />
| Yes<br />
| [[APT:SetFatalErrDispMode|SetFatalErrDispMode]]<br />
|-<br />
| 0x004D0080<br />
| <br />
| Yes<br />
| [[APT:GetAppletProgramInfo|GetAppletProgramInfo]]<br />
|-<br />
| 0x004E0000<br />
| <br />
| Yes<br />
| [[APT:HardwareResetAsync|HardwareResetAsync]]<br />
|-<br />
| 0x004F0080<br />
| [[2.2.0-X]]<br />
| Yes<br />
| [[APT:SetApplicationCpuTimeLimit|SetApplicationCpuTimeLimit]]<br />
|-<br />
| 0x00500040<br />
| [[2.2.0-X]]<br />
| Yes<br />
| [[APT:GetApplicationCpuTimeLimit|GetApplicationCpuTimeLimit]]<br />
|-<br />
| 0x00510080<br />
| [[3.0.0-5]]<br />
| Yes<br />
| [[APT:GetStartupArgument|GetStartupArgument]]<br />
|-<br />
| 0x00520104<br />
| [[4.0.0-7]]<br />
| Yes<br />
| [[APT:Wrap1|Wrap1]]<br />
|-<br />
| 0x00530104<br />
| [[4.0.0-7]]<br />
| Yes<br />
| [[APT:Unwrap1|Unwrap1]]<br />
|-<br />
| 0x00540040<br />
| [[5.0.0-11]]<br />
| ?<br />
| ?<br />
|-<br />
| 0x00550040<br />
| [[7.0.0-13]]<br />
| Yes<br />
| [[APT:SetScreencapPostPermission|SetScreencapPostPermission]]<br />
|-<br />
| 0x00560000<br />
| [[7.0.0-13]]<br />
| Yes<br />
| [[APT:GetScreencapPostPermission|GetScreencapPostPermission]]<br />
|-<br />
| 0x00570044<br />
| [[7.0.0-13]]<br />
| ?<br />
| [[APT:WakeupApplication2|WakeupApplication2]]<br />
|-<br />
| 0x00580002<br />
| [[7.0.0-13]]<br />
| Yes<br />
| [[APT:GetProgramID|GetProgramID]]<br />
|-<br />
| 0x01010000<br />
| [[8.0.0-18]]<br />
| Yes<br />
| [[APT:CheckNew3DSApp|CheckNew3DSApp]]<br />
|-<br />
| 0x01020000<br />
| [[8.0.0-18]]<br />
| Yes<br />
| [[APT:CheckNew3DS|CheckNew3DS]]<br />
|-<br />
| 0x01030000<br />
| [[8.0.0-18]]<br />
| Yes<br />
| This writes an output u8 to cmdreply[2], the value is determined by checking various NS internal state + whether this is a New3DS.<br />
The normal output seems to be value 0x2. Forcing this value to 0x1 causes New3DS HID usage(via ir:USER) in Smash Bros to be disabled.<br />
|-<br />
| 0x01040000<br />
| [[8.0.0-18]]<br />
| ?<br />
| [[APT:IsStandardMemoryLayout|IsStandardMemoryLayout]]<br />
|-<br />
| 0x01050100<br />
| [[10.4.0-29]]<br />
| ?<br />
| [[APT:IsTitleAllowed|IsTitleAllowed]]<br />
|}<br />
<br />
These "APT:U" and "APT:S" NS services can handle launching titles/"applets", these services handle signaling for home/power button as well. Only one session for either APT service can be open at a time, normally processes close the service handle immediately once finished using the service. The commands for APT:U and APT:S are exactly the same, however certain commands are only accessible with APT:S(NS module will call [[SVC|svcBreak]] when the command isn't accessible).<br />
<br />
Applets returning to home-menu first use commands APT:PrepareToJumpToHomeMenu and APT:JumpToHomeMenu, followed by these commands to launch home-menu: [[APT:PrepareToStartSystemApplet]] and [[APT:StartSystemApplet]]. [[APT:PrepareToStartSystemApplet]] and [[APT:StartSystemApplet]] are also used for launching the [[Internet Browser]], the camera applet, etc.<br />
<br />
Processes launch applications via home-menu, not directly with [[APT:PrepareToStartApplication]] and [[APT:StartApplication]]. Regular applications can't directly launch applications since [[APT:StartApplication]] launches the process without terminating the currently running application.<br />
<br />
APT:PrepareToDoApplicationJump and APT:DoApplicationJump are used by applications, for launching native/<non-NATIVE_FIRM> applications. These commands notify Home Menu that title launching needs done, Home Menu does the actual title launching via NS commands.<br />
<br />
== AppletAttr ==<br />
{| class="wikitable" border="1"<br />
|-<br />
! Bits<br />
! Description<br />
|-<br />
| 0-2<br />
| [[NS_and_APT_Services#AppletPos|AppletPos]]<br />
|-<br />
| 3<br />
| Manually Acquire/Release GPU Rights<br />
|-<br />
| 4<br />
| Manually Acquire/Release DSP Rights<br />
|-<br />
| 5<br />
| ?<br />
|}<br />
<br />
== DisplayBufferMode ==<br />
{| class="wikitable" border="1"<br />
|-<br />
! Value<br />
! Description<br />
|-<br />
| 0<br />
| FORMAT_R8G8B8A8<br />
|-<br />
| 1<br />
| FORMAT_R8G8B8<br />
|-<br />
| 2<br />
| FORMAT_R5G6B5<br />
|-<br />
| 3<br />
| FORMAT_R5G5B5A1<br />
|-<br />
| 4<br />
| FORMAT_R4G4B4A4<br />
|-<br />
| 0xFFFFFFFF<br />
| FORMAT_UNIMPORTABLE<br />
|}<br />
<br />
This is the same mapping as used for the [[GPU/External_Registers#Framebuffer_color_formats|GPU framebuffer color formats]].<br />
<br />
== AppletPos ==<br />
{| class="wikitable" border="1"<br />
|-<br />
! Value<br />
! Description<br />
|-<br />
| -1<br />
| POS_NONE<br />
|-<br />
| 0<br />
| POS_APP<br />
|-<br />
| 1<br />
| POS_APPLIB<br />
|-<br />
| 2<br />
| POS_SYS<br />
|-<br />
| 3<br />
| POS_SYSLIB<br />
|-<br />
| 4<br />
| POS_RESIDENT<br />
|}<br />
<br />
== QueryReply ==<br />
{| class="wikitable" border="1"<br />
|-<br />
! Value<br />
! Description<br />
|-<br />
| 0<br />
| REPLY_REJECT<br />
|-<br />
| 1<br />
| REPLY_ACCEPT<br />
|-<br />
| 2<br />
| REPLY_LATER<br />
|}<br />
<br />
== Notification ==<br />
{| class="wikitable" border="1"<br />
|-<br />
! Value<br />
! Description<br />
|-<br />
| 0<br />
| NOTIFICATION_NONE<br />
|-<br />
| 1<br />
| NOTIFICATION_HOME_BUTTON_1<br />
|-<br />
| 2<br />
| NOTIFICATION_HOME_BUTTON_2<br />
|-<br />
| 3<br />
| NOTIFICATION_SLEEP_QUERY<br />
|-<br />
| 4<br />
| NOTIFICATION_SLEEP_CANCELED_BY_OPEN<br />
|-<br />
| 5<br />
| NOTIFICATION_SLEEP_ACCEPTED<br />
|-<br />
| 6<br />
| NOTIFICATION_SLEEP_AWAKE<br />
|-<br />
| 7<br />
| NOTIFICATION_SHUTDOWN<br />
|-<br />
| 8<br />
| NOTIFICATION_POWER_BUTTON_CLICK<br />
|-<br />
| 9<br />
| NOTIFICATION_POWER_BUTTON_CLEAR<br />
|-<br />
| 10<br />
| NOTIFICATION_TRY_SLEEP<br />
|-<br />
| 11<br />
| NOTIFICATION_ORDER_TO_CLOSE<br />
|}<br />
<br />
== Command ==<br />
{| class="wikitable" border="1"<br />
|-<br />
! Value<br />
! Description<br />
|-<br />
| 0<br />
| COMMAND_NONE<br />
|-<br />
| 1<br />
| COMMAND_WAKEUP<br />
|-<br />
| 2<br />
| COMMAND_REQUEST<br />
|-<br />
| 3<br />
| COMMAND_RESPONSE<br />
|-<br />
| 4<br />
| COMMAND_EXIT<br />
|-<br />
| 5<br />
| COMMAND_MESSAGE<br />
|-<br />
| 6<br />
| COMMAND_HOME_BUTTON_SINGLE<br />
|-<br />
| 7<br />
| COMMAND_HOME_BUTTON_DOUBLE<br />
|-<br />
| 8<br />
| COMMAND_DSP_SLEEP<br />
|-<br />
| 9<br />
| COMMAND_DSP_WAKEUP<br />
|-<br />
| 10<br />
| COMMAND_WAKEUP_BY_EXIT<br />
|-<br />
| 11<br />
| COMMAND_WAKEUP_BY_PAUSE<br />
|-<br />
| 12<br />
| COMMAND_WAKEUP_BY_CANCEL<br />
|-<br />
| 13<br />
| COMMAND_WAKEUP_BY_CANCELALL<br />
|-<br />
| 14<br />
| COMMAND_WAKEUP_BY_POWER_BUTTON_CLICK<br />
|-<br />
| 15<br />
| COMMAND_WAKEUP_TO_JUMP_HOME<br />
|-<br />
| 16<br />
| COMMAND_REQUEST_FOR_SYS_APPLET<br />
|-<br />
| 17<br />
| COMMAND_WAKEUP_TO_LAUNCH_APPLICATION<br />
|-<br />
| 0x41<br />
| Unknown. [[APT:ReceiveParameter|Received]] by Home Menu during boot when the Home Menu process doesn't terminate properly(svcExitProcess/crash).<br />
|}<br />
<br />
== AppletPreparationState ==<br />
{| class="wikitable" border="1"<br />
|-<br />
! Value<br />
! Description<br />
|-<br />
| 0<br />
| NO_PREPARATION<br />
|-<br />
| 1<br />
| PREPARED_TO_LAUNCH_APP<br />
|-<br />
| 2<br />
| PREPARED_TO_CLOSE_APP<br />
|-<br />
| 3<br />
| PREPARED_TO_FORCE_TO_CLOSE_APP<br />
|-<br />
| 4<br />
| PREPARED_TO_PRELOAD_APPLIB<br />
|-<br />
| 5<br />
| PREPARED_TO_LAUNCH_APPLIB<br />
|-<br />
| 6<br />
| PREPARED_TO_CLOSE_APPLIB<br />
|-<br />
| 7<br />
| PREPARED_TO_LAUNCH_SYS<br />
|-<br />
| 8<br />
| PREPARED_TO_CLOSE_SYS<br />
|-<br />
| 9<br />
| PREPARED_TO_PRELOAD_SYSLIB<br />
|-<br />
| 10<br />
| PREPARED_TO_LAUNCH_SYSLIB<br />
|-<br />
| 11<br />
| PREPARED_TO_CLOSE_SYSLIB<br />
|-<br />
| 12<br />
| PREPARED_TO_LAUNCH_RESIDENT<br />
|-<br />
| 13<br />
| PREPARED_TO_LEAVE_RESIDENT<br />
|-<br />
| 14<br />
| PREPARED_TO_DO_HOMEMENU<br />
|-<br />
| 15<br />
| PREPARED_TO_LEAVE_HOMEMENU<br />
|-<br />
| 16<br />
| PREPARED_TO_START_RESIDENT<br />
|-<br />
| 17<br />
| PREPARED_TO_DO_APP_JUMP<br />
|-<br />
| 18<br />
| PREPARED_TO_FORCE_TO_CLOSE_SYS<br />
|-<br />
| 19<br />
| PREPARED_TO_LAUNCH_OTHER_SYS<br />
|-<br />
| 20<br />
| PREPARED_TO_JUMP_TO_APP<br />
|}<br />
<br />
== StartupArgumentType ==<br />
{| class="wikitable" border="1"<br />
|-<br />
! Value<br />
! Description<br />
|-<br />
| 0<br />
| STARTUP_ARGUMENT_TYPE_OTHER_APP<br />
|-<br />
| 1<br />
| STARTUP_ARGUMENT_TYPE_RESTART<br />
|-<br />
| 2<br />
| STARTUP_ARGUMENT_TYPE_OTHER_MEDIA<br />
|}<br />
<br />
== CaptureBufferInfo ==<br />
{| class="wikitable" border="1"<br />
|-<br />
! Offset<br />
! Size<br />
! Description<br />
|-<br />
| 0x0<br />
| 0x4<br />
| u32, Size<br />
|-<br />
| 0x4<br />
| 0x1<br />
| u8, 3D (0 = not 3D, 1 = 3D)<br />
|-<br />
| 0x5<br />
| 0x3<br />
| Reserved<br />
|-<br />
| 0x8<br />
| 0x4<br />
| Main Screen Left Offset<br />
|-<br />
| 0xC<br />
| 0x4<br />
| Main Screen Right Offset<br />
|-<br />
| 0x10<br />
| 0x4<br />
| Main Screen [[NS_and_APT_Services#DisplayBufferMode|DisplayBufferMode]]<br />
|-<br />
| 0x14<br />
| 0x4<br />
| Sub Screen Left Offset<br />
|-<br />
| 0x18<br />
| 0x4<br />
| Sub Screen Right Offset<br />
|-<br />
| 0x1C<br />
| 0x4<br />
| Sub Screen [[NS_and_APT_Services#DisplayBufferMode|DisplayBufferMode]]<br />
|}<br />
<br />
==WirelessRebootInfo==<br />
{| class="wikitable" border="1"<br />
|-<br />
! Offset<br />
! Size<br />
! Description<br />
|-<br />
| 0x0<br />
| 0x6<br />
| Host MAC address.<br />
|-<br />
| 0x6<br />
| 0x9<br />
| WirelessRebootPassphrase<br />
|-<br />
| 0xF<br />
| 0x1<br />
| Uninitialized<br />
|}<br />
<br />
This is [[NSS:SetWirelessRebootInfo|setup]] by the dlplay system-application, before launching the DLP-child which can then use [[APT:GetWirelessRebootInfo]]. The MAC address and passphrase is used for connecting to the host by the DLP-child. See also [[DLP_Services|here]].<br />
<br />
="APT:A" Service=<br />
This was added with [[7.0.0-13|7.0.0-X]]. Official apps built with the CTRSDK for system-version >=[[7.0.0-13|7.0.0-X]] normally use the "APT:A" service instead of "APT:U". Those processes also have "APT:A" instead of "APT:U" in the service-access-control. It's unknown whether there's anything which is only accessible via "APT:A".<br />
<br />
=Applets=<br />
NS module does not verify that the input appID for the APT service cmds are correct for that type of command. For example, a process-launch of a SystemApplet via LibraryApplet commands works fine(minus the launched-process side of APT probably).<br />
<br />
==System Applets==<br />
On Old3DS there could only be one applet here(Home Menu, Internet Browser, Friend-List, etc) with programID-high 00040030 running at a time. On Old3DS when directly launching one of these 00040030 applets with Home Menu, the Home Menu process will terminate once the process is launched. On Old3DS when returning to Home Menu from that launched process, the Home Menu process is launched again.<br />
<br />
On New3DS the Home Menu process is still running/in-memory, while another system-applet is running. On New3DS it appears that the Home Menu process is terminated+relaunched, when another system-applet terminated without exiting with APT properly.<br />
<br />
==Library Applets==<br />
Library applets can be launched by applications and regular applets. These library applets render to the screen(s) when running, etc. For example, this includes swkbd for text input. See the below appIDs in the 0x2XX range, the actual appID used is 0x4XX however.<br />
<br />
Input data can be sent to the library applet via the NS [[APT:SendParameter|parameter]] buffer, and/or with shared-memory with a shared-mem handle sent to the library applet. Output data from the library applet can be received by [[APT:ReceiveParameter]], the library applet can also use the specified shared-mem for output too.<br />
<br />
=AppIDs=<br />
{| class="wikitable" border="1"<br />
|-<br />
! AppID<br />
! Description<br />
|-<br />
| 0x101<br />
| Home Menu (menu)<br />
|-<br />
| 0x103<br />
| Alternate Menu<br />
|-<br />
| 0x110<br />
| Camera applet (CtrApp)<br />
|-<br />
| 0x112<br />
| Friends List applet (friend)<br />
|-<br />
| 0x113<br />
| Game Notes applet (Cherry)<br />
|-<br />
| 0x114<br />
| [[Internet Browser]] (spider/SKATER)<br />
|-<br />
| 0x115<br />
| Instruction Manual applet<br />
|-<br />
| 0x116<br />
| Notifications applet (newslist)<br />
|-<br />
| 0x117<br />
| Miiverse applet (olv)<br />
|-<br />
| 0x118<br />
| Miiverse posting applet (solv3)<br />
|-<br />
| 0x119<br />
| Amiibo settings (cabinet)<br />
|-<br />
| 0x201<br />
| Software Keyboard (swkbd) (?)<br />
|-<br />
| 0x202<br />
| Mii Selector (appletEd) (?)<br />
|-<br />
| 0x204<br />
| Photo Selector (PNOTE_AP) (?)<br />
|-<br />
| 0x205<br />
| Sound Selector (SNOTE_AP) (?)<br />
|-<br />
| 0x206<br />
| Error Display (error) (?)<br />
|-<br />
| 0x207<br />
| eShop applet (mint) (?)<br />
|-<br />
| 0x208<br />
| Circle Pad Pro Calibrator ([[Extrapad_Applet|extrapad]]) (?)<br />
|-<br />
| 0x209<br />
| Notepad (memolib) (?)<br />
|-<br />
| 0x300<br />
| Application<br />
|-<br />
| 0x301<br />
| eShop (tiger)<br />
|-<br />
| 0x401<br />
| Software Keyboard (swkbd)<br />
|-<br />
| 0x402<br />
| Mii Selector (appletEd)<br />
|-<br />
| 0x404<br />
| Photo Selector (PNOTE_AP)<br />
|-<br />
| 0x405<br />
| Sound Selector (SNOTE_AP)<br />
|-<br />
| 0x406<br />
| Error Display (error)<br />
|-<br />
| 0x407<br />
| eShop applet (mint)<br />
|-<br />
| 0x408<br />
| Circle Pad Pro Calibrator ([[Extrapad_Applet|extrapad]])<br />
|-<br />
| 0x409<br />
| Notepad (memolib)<br />
|-<br />
| 0xF10<br />
| ProgramID: 0004003000008900.<br />
|-<br />
| 0xF11<br />
| ProgramID: 000400000FFFFD00.<br />
|-<br />
| 0xF12<br />
| ProgramID: 000400000FFFFC00.<br />
|-<br />
| 0xF13<br />
| ProgramID: 000400000FFFFB00.<br />
|-<br />
| 0xF14<br />
| ProgramID: 000400000FFFF900.<br />
|-<br />
| 0xF15<br />
| ProgramID: 000400000FFFF800.<br />
|-<br />
| 0xF16<br />
| ProgramID: 000400000FFFF700.<br />
|-<br />
| 0xF17<br />
| ProgramID: 000400000FFFF600.<br />
|-<br />
| 0xF18<br />
| ProgramID: 000400000FFFF500.<br />
|}<br />
<br />
These AppIDs are all for NAND titles, except for 0x300. AppIDs in the 0x1XX range are applets(programID-high 00040030), and the AppIDs in the 0x2XX range are "system libraries"(programID-high 00040030). The 0xFXX AppID range is for development NAND applications, these are not available for retail.<br />
<br />
Note that at some point the total AppID entry count was changed from 28 to 27.</div>Mrrraouhttps://www.3dbrew.org/w/index.php?title=User_talk:100pcrack&diff=14740User talk:100pcrack2015-11-29T17:26:25Z<p>Mrrraou: Created page with "Please take note that an icon pack is not an homebrew."</p>
<hr />
<div>Please take note that an icon pack is not an homebrew.</div>Mrrraouhttps://www.3dbrew.org/w/index.php?title=Homebrew_Releases&diff=14739Homebrew Releases2015-11-29T17:24:50Z<p>Mrrraou: Undo revision 14724 by 100pcrack (talk) : not an homebrew</p>
<hr />
<div>*'''23 February 15''' filfat released [[Homebrew Applications|DownloadMii 1.0.5.10]]<br />
*'''15 January 15''' filfat released [[Homebrew Applications|DownloadMii 1.0.0.0]]<br />
*'''6 January 15''' Yellows8 released [[Homebrew Applications|3ds_homemenu_extdatatool v1.1]]<br />
*'''30 December 14''' Yellows8 released [[Homebrew Applications|3ds_homemenu_extdatatool v1.0]]</div>Mrrraouhttps://www.3dbrew.org/w/index.php?title=System_Settings&diff=14530System Settings2015-11-12T10:41:21Z<p>Mrrraou: Added accessible services list</p>
<hr />
<div>'''System Settings''' allows you to manage various settings, use [[System Transfer]], and use Data Management.<br />
<br />
All applications(CTR/TWL) launched by System Settings are launched via [[NS|APT:PrepareToDoApplicationJump/APT:DoApplicationJump]], such as DS INTERNET and [[System Transfer]].<br />
<br />
== Accessible services ==<br />
<br />
{| class="wikitable" border="1"<br />
|-<br />
! Service<br />
! Last seen on version<br />
|-<br />
| [[Filesystem_services#Filesystem_service_.22fs:USER.22|fs:USER]]<br />
| [[9.0.0-20|v8202]]<br />
|-<br />
| [[GSP_Services|gsp:Gpu]]<br />
| [[9.0.0-20|v8202]]<br />
|-<br />
| [[NDM_Services|ndm:u]]<br />
| [[9.0.0-20|v8202]]<br />
|-<br />
| [[NS#.22APT:A.22_Service|APT:A]]<br />
| [[9.0.0-20|v8202]]<br />
|-<br />
| [[AC_Services|ac:i]]<br />
| [[9.0.0-20|v8202]]<br />
|-<br />
| [[ACT_Services|act:a]]<br />
| [[9.0.0-20|v8202]]<br />
|-<br />
| [[Application_Manager_Services#Application_Manager_services|am:sys]]<br />
| [[9.0.0-20|v8202]]<br />
|-<br />
| [[BOSS_Services|boss:P]]<br />
| [[9.0.0-20|v8202]]<br />
|-<br />
| [[Camera_Services#cam:s_.28PORT_CAL.29|cam:s]]<br />
| [[9.0.0-20|v8202]]<br />
|-<br />
| [[CECD_Services|cecd:s]]<br />
| [[9.0.0-20|v8202]]<br />
|-<br />
| [[Config_Services#Config_NVRAM_service_.22cfg:nor.22|cfg:nor]]<br />
| [[9.0.0-20|v8202]]<br />
|-<br />
| [[DSP_Services|dsp::DSP]]<br />
| [[9.0.0-20|v8202]]<br />
|-<br />
| [[Friend_Services|frd:a]]<br />
| [[9.0.0-20|v8202]]<br />
|-<br />
| [[GSP_Services|gsp::Lcd]]<br />
| [[9.0.0-20|v8202]]<br />
|-<br />
| [[HTTP_Services|http:C]]<br />
| [[9.0.0-20|v8202]]<br />
|-<br />
| [[MIC_Services|mic:u]]<br />
| [[9.0.0-20|v8202]]<br />
|-<br />
| [[News_Services#News_service_.22news:s.22|news:s]]<br />
| [[9.0.0-20|v8202]]<br />
|-<br />
| [[NIM_Services#NIM_user_service_.22nim:u.22|nim:u]]<br />
| [[9.0.0-20|v8202]]<br />
|-<br />
| [[NS#NS_Service_.22ns:s.22|ns:s]]<br />
| [[9.0.0-20|v8202]]<br />
|-<br />
| [[NWM_Services#NWM_service_.22nwm::EXT.22|nwm::EXT]]<br />
| [[9.0.0-20|v8202]]<br />
|-<br />
| [[NWM_Services#NWM_infrastructure_service_.22nwm::INF.22|nwm::INF]]<br />
| [[9.0.0-20|v8202]]<br />
|-<br />
| [[NWM_Services#NWM_socket_service_.22nwm::SOC.22|nwm::SOC]]<br />
| [[9.0.0-20|v8202]]<br />
|-<br />
| [[PTM_Services#GetSystemTime_PTM_Service_.22ptm:gets.22|ptm:gets]]<br />
| [[9.0.0-20|v8202]]<br />
|-<br />
| [[PTM_Services#SysMenu_PTM_Service_.22ptm:sysm.22|ptm:sysm]]<br />
| [[9.0.0-20|v8202]]<br />
|-<br />
| [[Socket_Services#Socket_privileged_service_.22soc:P.22|soc:P]]<br />
| [[9.0.0-20|v8202]]<br />
|-<br />
| [[Socket_Services#Socket_user_service_.22soc:U.22|soc:U]]<br />
| [[9.0.0-20|v8202]]<br />
|-<br />
| [[SSL_Services|ssl:C]]<br />
| [[9.0.0-20|v8202]]<br />
|-<br />
| [[Camera_Services#y2r:u|y2r:u]]<br />
| [[9.0.0-20|v8202]]<br />
|-<br />
| [[QTM_Services#QTM_system_service_.22qtm:s.22|qtm:s]]<br />
| [[9.0.0-20|v8202]]<br />
|-<br />
| [[Config_Services#Config_service_.22cfg:i.22|cfg:i]]<br />
| [[9.0.0-20|v8202]]<br />
|-<br />
| [[HID_Services#HID_service_.22hid:SPVR.22|hid:SPVR]]<br />
| [[9.0.0-20|v8202]]<br />
|}<br />
<br />
== Data Management ==<br />
<br />
=== 3DS ===<br />
<br />
Here you can manage 3DS extra data, and 3DSWare/"Software".<br />
<br />
When managing 3DS Software installed to the SD Card, the [[Title Database|title.db]] is read by the core receiving [[Application Manager Services PXI|AM]] commands. From the title.db file, AM gets a list of installed titles, title sizes and the name of the ".cmd" file for each title, which is used to check the authenticity of the title data(product code, title version, and if an electronic manaual is used, is also kept for each title, in the title.db, but won't be used by the Data Management Utility). For each title listed, it checks if the title is authentic(via the .cmd file). If the title passes authentication, Data Management decrypts/reads the ICN data from the executable NCCH([[CXI]]) and displays it along with the archived title size. If a title doesn't pass authentication, a placeholder icon(light grey with a '?' in the center), name ('????????') and a size of zero are used. Deleting titles removes the title data from the title.db and import.db, and deletes the directory of the content.<br />
<br />
=== DSiWare ===<br />
<br />
See [[DSiWare Exports]].<br />
<br />
== System Format ==<br />
Most of the System Format is done with [[FS:InitializeCtrFileSystem]]. This command updates the high u64 of the keyY stored in [[Nand/private/movable.sed|movable.sed]]. Since this keyY was updated, the data stored on [[SD_Filesystem|SD]] card(sdmc/Nintendo 3DS/<ID0>/<ID1>) and the data under [[Flash_Filesystem|nand/data/<ID0>]] is rendered useless, since that data used the old keyY. Since that data is no longer usable, the system then deletes the two above SD/NAND directories.<br />
<br />
== System Updater ==<br />
The system updater title is identical to the regular system settings, except only system update is accessible with this. On dev units, this title can only be launched under certain conditions.<br />
<br />
On retail units, this title is accessible in scenarios where you have to update via the Internet to use certain 3DS software other than the home menu. i.e. using the eShop, on a system version less than the current one. When one selects "Cancel" from here on retail, the system will shutdown. [[NS]] launches SAFE_MODE_FIRM for running this title, when the [[Configuration_Memory|UPDATEFLAG]] is set during system boot.<br />
<br />
==Exiting System Settings==<br />
Upon exit, the system reboots instead of simply returning to home menu.<br />
<br />
== Parental Controls Reset ==<br />
The following refers to the functionality which generates the Parental Controls "Master Key".<br />
<br />
{| class="wikitable" border="1"<br />
|-<br />
! System Version, for the mset title<br />
! Parental controls reset functionality version<br />
! Notes<br />
|-<br />
| [[1.0.0-0]] - [[5.1.0-11]]<br />
| v0<br />
| <br />
|-<br />
| [[6.0.0-11|6.0]] - [[6.3.0-12]]<br />
| v1<br />
| <br />
|-<br />
| [[7.0.0-13]] - [[7.2.0-17]]<br />
| v2<br />
| <br />
|}<br />
<br />
== ExtData ==<br />
The ExtData [[Extdata#Filesystem|File System]] for System Settings is as follows:<br />
<br />
root<br />
├── icon<br />
├── boss<br />
└── user<br />
├── Backup.dat<br />
└── MsetExt.dat<br />
<br />
{| class="wikitable" border="1"<br />
|-<br />
! File<br />
! Details<br />
! Size<br />
! FW Introduced<br />
! Plaintext<br />
|-<br />
| icon<br />
| Stubbed. Always image 00000002.<br />
| 0x4 Bytes<br />
| n/a<br />
|<br />
|-<br />
| MsetExt.dat<br />
| [[DSiWare Exports]] Management<br />
| 0x960 Bytes<br />
| [[2.0.0-2]]<br />
| [https://dl.dropboxusercontent.com/u/60710927/CTR/Sample/SystemSettingsExtdata/MsetExt.dat Download]<br />
|-<br />
| Backup.dat<br />
| [[SD Savedata Backups]] Management<br />
| 0xf5a0 Bytes<br />
| [[6.0.0-11]]<br />
| [https://dl.dropboxusercontent.com/u/60710927/CTR/Sample/SystemSettingsExtdata/Backup.dat Download]<br />
|}<br />
<br />
=== MsetExt.dat ===<br />
This keeps a record for the DSiWare Exports for a maximum of 300 exports. Each record is in the format:<br />
{| class="wikitable" border="1"<br />
|-<br />
! OFFSET<br />
! SIZE<br />
! DESCRIPTION<br />
|-<br />
| 0<br />
| 4<br />
| Game Code in Little Endian <br />
|-<br />
| 0x4<br />
| 4<br />
| Reserved<br />
|}<br />
<br />
All unused entries are filled with "0xff".<br />
<br />
=== Backup.dat ===<br />
This keeps a record for the 30 save data backup slots for [[SD Savedata Backups]]. Each entry corresponds to an individual backup slot.<br />
<br />
Entry:<br />
{| class="wikitable" border="1"<br />
|-<br />
! OFFSET<br />
! SIZE<br />
! DESCRIPTION<br />
|-<br />
| 0x000<br />
| 8<br />
| Reserved<br />
|-<br />
| 0x8<br />
| 0x800 (0x80*16)<br />
| 16 UTF-16 Title Strings<br />
|-<br />
| 0x808<br />
| 8<br />
| Title ID<br />
|-<br />
| 0x810<br />
| 8<br />
| Unknown<br />
|-<br />
| 0x818<br />
| 8<br />
| Total Save Data Size<br />
|-<br />
| 0x820<br />
| 0x10<br />
| Reserved<br />
|}</div>Mrrraou