<?xml version="1.0"?>
<feed xmlns="http://www.w3.org/2005/Atom" xml:lang="en">
	<id>https://www.3dbrew.org/w/api.php?action=feedcontributions&amp;feedformat=atom&amp;user=Motezazer</id>
	<title>3dbrew - User contributions [en]</title>
	<link rel="self" type="application/atom+xml" href="https://www.3dbrew.org/w/api.php?action=feedcontributions&amp;feedformat=atom&amp;user=Motezazer"/>
	<link rel="alternate" type="text/html" href="https://www.3dbrew.org/wiki/Special:Contributions/Motezazer"/>
	<updated>2026-04-21T20:40:14Z</updated>
	<subtitle>User contributions</subtitle>
	<generator>MediaWiki 1.43.1</generator>
	<entry>
		<id>https://www.3dbrew.org/w/index.php?title=CONFIG9_Registers&amp;diff=20045</id>
		<title>CONFIG9 Registers</title>
		<link rel="alternate" type="text/html" href="https://www.3dbrew.org/w/index.php?title=CONFIG9_Registers&amp;diff=20045"/>
		<updated>2017-05-25T16:20:50Z</updated>

		<summary type="html">&lt;p&gt;Motezazer: Misled&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;= Registers =&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot; border=&amp;quot;1&amp;quot;&lt;br /&gt;
!  Old3DS&lt;br /&gt;
!  Name&lt;br /&gt;
!  Address&lt;br /&gt;
!  Width&lt;br /&gt;
!  Used by&lt;br /&gt;
|-&lt;br /&gt;
| style=&amp;quot;background: green&amp;quot; | Yes&lt;br /&gt;
| [[#CFG9_SYSPROT9|CFG9_SYSPROT9]]&lt;br /&gt;
| 0x10000000&lt;br /&gt;
| 1&lt;br /&gt;
| Boot9&lt;br /&gt;
|-&lt;br /&gt;
| style=&amp;quot;background: green&amp;quot; | Yes&lt;br /&gt;
| [[#CFG9_SYSPROT11|CFG9_SYSPROT11]]&lt;br /&gt;
| 0x10000001&lt;br /&gt;
| 1&lt;br /&gt;
| Boot9&lt;br /&gt;
|-&lt;br /&gt;
| style=&amp;quot;background: green&amp;quot; | Yes&lt;br /&gt;
| [[#CFG9_RST11|CFG9_RST11]]&lt;br /&gt;
| 0x10000002&lt;br /&gt;
| 1&lt;br /&gt;
| Boot9&lt;br /&gt;
|-&lt;br /&gt;
| style=&amp;quot;background: green&amp;quot; | Yes&lt;br /&gt;
| CFG9_DEBUGCTL&lt;br /&gt;
| 0x10000004&lt;br /&gt;
| 4&lt;br /&gt;
|&lt;br /&gt;
|-&lt;br /&gt;
| style=&amp;quot;background: green&amp;quot; | Yes&lt;br /&gt;
| ?&lt;br /&gt;
| 0x10000008&lt;br /&gt;
| 1&lt;br /&gt;
| Boot9, Process9, TwlProcess9&lt;br /&gt;
|-&lt;br /&gt;
| style=&amp;quot;background: green&amp;quot; | Yes&lt;br /&gt;
| [[#CFG9_CARDCTL|CFG9_CARDCTL]]&lt;br /&gt;
| 0x1000000C&lt;br /&gt;
| 2&lt;br /&gt;
| Process9&lt;br /&gt;
|-&lt;br /&gt;
| style=&amp;quot;background: green&amp;quot; | Yes&lt;br /&gt;
| [[#CFG9_CARDSTATUS|CFG9_CARDSTATUS]]&lt;br /&gt;
| 0x10000010&lt;br /&gt;
| 1&lt;br /&gt;
| Process9&lt;br /&gt;
|-&lt;br /&gt;
| style=&amp;quot;background: green&amp;quot; | Yes&lt;br /&gt;
| CFG9_CARDCYCLES0&lt;br /&gt;
| 0x10000012&lt;br /&gt;
| 2&lt;br /&gt;
| Boot9, Process9&lt;br /&gt;
|-&lt;br /&gt;
| style=&amp;quot;background: green&amp;quot; | Yes&lt;br /&gt;
| CFG9_CARDCYCLES1&lt;br /&gt;
| 0x10000014&lt;br /&gt;
| 2&lt;br /&gt;
| Boot9, Process9&lt;br /&gt;
|-&lt;br /&gt;
| style=&amp;quot;background: green&amp;quot; | Yes&lt;br /&gt;
| ?&lt;br /&gt;
| 0x10000020&lt;br /&gt;
| 2&lt;br /&gt;
|&lt;br /&gt;
|-&lt;br /&gt;
| style=&amp;quot;background: green&amp;quot; | Yes&lt;br /&gt;
| ?&lt;br /&gt;
| 0x10000100&lt;br /&gt;
| 2&lt;br /&gt;
|&lt;br /&gt;
|-&lt;br /&gt;
| style=&amp;quot;background: red&amp;quot; | No&lt;br /&gt;
| [[#CFG9_EXTMEMCNT9|CFG9_EXTMEMCNT9]]&lt;br /&gt;
| 0x10000200&lt;br /&gt;
| 1&lt;br /&gt;
| NewKernel9&lt;br /&gt;
|-&lt;br /&gt;
| style=&amp;quot;background: green&amp;quot; | Yes&lt;br /&gt;
| [[#CFG9_MPCORECFG|CFG9_MPCORECFG]]&lt;br /&gt;
| 0x10000FFC&lt;br /&gt;
| 4&lt;br /&gt;
|&lt;br /&gt;
|-&lt;br /&gt;
| style=&amp;quot;background: green&amp;quot; | Yes&lt;br /&gt;
| [[#CFG9_BOOTENV|CFG9_BOOTENV]]&lt;br /&gt;
| 0x10010000&lt;br /&gt;
| 4&lt;br /&gt;
|&lt;br /&gt;
|-&lt;br /&gt;
| style=&amp;quot;background: green&amp;quot; | Yes&lt;br /&gt;
| [[#CFG9_UNITINFO|CFG9_UNITINFO]]&lt;br /&gt;
| 0x10010010&lt;br /&gt;
| 1&lt;br /&gt;
| Process9&lt;br /&gt;
|-&lt;br /&gt;
| style=&amp;quot;background: green&amp;quot; | Yes&lt;br /&gt;
| [[#CFG9_TWLUNITINFO|CFG9_TWLUNITINFO]]&lt;br /&gt;
| 0x10010014&lt;br /&gt;
| 1&lt;br /&gt;
| Process9&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
== CFG9_SYSPROT9 ==&lt;br /&gt;
CFG9_SYSPROT9 is used to permanently disable certain security-sensitive ARM9 memory areas until the next hard reset.&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot; border=&amp;quot;1&amp;quot;&lt;br /&gt;
!  Bit&lt;br /&gt;
!  Description&lt;br /&gt;
!  Used by&lt;br /&gt;
|-&lt;br /&gt;
| 0&lt;br /&gt;
| Disables ARM9 [[Memory_layout|bootrom]](+0x8000) when set to 1, and enables access to [[Memory_layout|FCRAM]]. Cannot be cleared to 0 once set to 1.&lt;br /&gt;
| Boot9&lt;br /&gt;
|-&lt;br /&gt;
| 1&lt;br /&gt;
| Disables [[OTP_Registers|OTP area]] when set to 1. Cannot be cleared to 0 once set to 1.&lt;br /&gt;
| NewKernel9Loader, Process9&lt;br /&gt;
|-&lt;br /&gt;
| 31-2&lt;br /&gt;
| Not used&lt;br /&gt;
|&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
On Old 3DS, NATIVE_FIRM reads CFG9_SYSPROT9 to know whether it has previously initialized the TWL console-unique keys using the OTP data.  After setting the TWL console-unique keys, NATIVE_FIRM sets CFG9_SYSPROT9 bit 1 to disable the OTP area.  In subsequent FIRM launches prior to the next reset, NATIVE_FIRM will see that the OTP area is disabled, and skip this step.&lt;br /&gt;
&lt;br /&gt;
On New 3DS, the above is instead done by the [[FIRM#New_3DS_FIRM|Kernel9 loader]].  In addition to using the OTP data for initializing the TWL console-unique keys, the Kernel9 loader will generate the decryption key for NATIVE_FIRM.  The final keyslot for NATIVE_FIRM is preserved, so that at a non-reset FIRM launch, the keyslot can be reused, since the OTP would then be inaccessible.&lt;br /&gt;
&lt;br /&gt;
== CFG9_SYSPROT11 ==&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot; border=&amp;quot;1&amp;quot;&lt;br /&gt;
!  Bit&lt;br /&gt;
!  Description&lt;br /&gt;
!  Used by&lt;br /&gt;
|-&lt;br /&gt;
| 0&lt;br /&gt;
| Disables ARM11 [[Memory_layout|bootrom]](+0x8000) when set to 1, and enables access to [[Memory_layout|FCRAM]]. Cannot be cleared to 0 once set to 1.&lt;br /&gt;
| Boot9&lt;br /&gt;
|-&lt;br /&gt;
| 31-1&lt;br /&gt;
| Not used&lt;br /&gt;
|&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
== CFG9_RST11 ==&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot; border=&amp;quot;1&amp;quot;&lt;br /&gt;
!  Bit&lt;br /&gt;
!  Description&lt;br /&gt;
!  Used by&lt;br /&gt;
|-&lt;br /&gt;
| 0&lt;br /&gt;
| Presumably takes ARM11 out of reset. Cannot be set to 1 once it has been cleared.&lt;br /&gt;
| Boot9&lt;br /&gt;
|-&lt;br /&gt;
| 31-1&lt;br /&gt;
| Not used&lt;br /&gt;
|&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
== 0x10000008 ==&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot; border=&amp;quot;1&amp;quot;&lt;br /&gt;
!  Bit&lt;br /&gt;
!  Description&lt;br /&gt;
!  Used by&lt;br /&gt;
|-&lt;br /&gt;
| 1-0&lt;br /&gt;
| ?&lt;br /&gt;
|&lt;br /&gt;
|-&lt;br /&gt;
| 3-2&lt;br /&gt;
| AES related? Value 3 written after write to AES_CTL.&lt;br /&gt;
| Boot9, Process9, TwlProcess9&lt;br /&gt;
|-&lt;br /&gt;
| 31-4&lt;br /&gt;
| Reserved&lt;br /&gt;
|&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
== CFG9_CARDCTL ==&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot; border=&amp;quot;1&amp;quot;&lt;br /&gt;
!  Bit&lt;br /&gt;
!  Description&lt;br /&gt;
!  Used by&lt;br /&gt;
|-&lt;br /&gt;
| 1-0&lt;br /&gt;
| Gamecard active controller select (0=NTRCARD, 1=?, 2=CTRCARD0, 3=CTRCARD1)&lt;br /&gt;
| Process9&lt;br /&gt;
|-&lt;br /&gt;
| 8&lt;br /&gt;
| Enable gamecard eject IRQ, maybe?&lt;br /&gt;
| Process9&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
Depending on the gamecard controller that has been selected, one of the following gamecard registers will become active:&lt;br /&gt;
* Selecting NTRCARD will activate the register space at [[NTRCARD|0x10164000]].&lt;br /&gt;
* Selecting CTRCARD0 will activate the register space at [[CTRCARD|0x10004000]].&lt;br /&gt;
* Selecting CTRCARD1 will activate the register space at [[CTRCARD|0x10005000]].&lt;br /&gt;
&lt;br /&gt;
== CFG9_CARDSTATUS ==&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot; border=&amp;quot;1&amp;quot;&lt;br /&gt;
!  Bit&lt;br /&gt;
!  Description&lt;br /&gt;
!  Used by&lt;br /&gt;
|-&lt;br /&gt;
| 0&lt;br /&gt;
| Cartridge-slot empty (0=inserted, 1=empty)&lt;br /&gt;
| Process9&lt;br /&gt;
|-&lt;br /&gt;
| 3-2&lt;br /&gt;
| ?&lt;br /&gt;
| Process9&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
== CFG9_EXTMEMCNT9 ==&lt;br /&gt;
This register is New3DS-only.&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot; border=&amp;quot;1&amp;quot;&lt;br /&gt;
!  Bit&lt;br /&gt;
!  Description&lt;br /&gt;
!  Used by&lt;br /&gt;
|-&lt;br /&gt;
| 0&lt;br /&gt;
| Hide extended ARM9 memory (0=hidden, 1=shown)&lt;br /&gt;
| Kernel9 (New3DS)&lt;br /&gt;
|-&lt;br /&gt;
| 31-1&lt;br /&gt;
| Reserved&lt;br /&gt;
|&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
== CFG9_MPCORECFG ==&lt;br /&gt;
Identical to [[PDN#PDN_MPCORE_CFG|PDN_MPCORE_CFG]].&lt;br /&gt;
&lt;br /&gt;
== CFG9_BOOTENV ==&lt;br /&gt;
This register is used to determine what the previous running FIRM was. Its value is kept following an MCU reboot. Its initial value (on a cold boot) is 0. NATIVE_FIRM [[Development_Services_PXI|sets it to 1]] on shutdown/FIRM launch. [[Legacy_FIRM_PXI|LGY FIRM]] writes value 3 here when launching a TWL title, and writes value 7 when launching an AGB title.&lt;br /&gt;
&lt;br /&gt;
NATIVE_FIRM will only launch titles if this is not value 0, and will only save the [[Flash_Filesystem|AGB_FIRM savegame]] to SD if this is value 7.&lt;br /&gt;
&lt;br /&gt;
== CFG9_UNITINFO ==&lt;br /&gt;
This 8-bit register is value zero for retail, non-zero for dev/debug units.&lt;br /&gt;
&lt;br /&gt;
== CFG9_TWLUNITINFO ==&lt;br /&gt;
In the console-unique TWL key-init/etc function the ARM9 copies the u8 value from REG_UNITINFO to this register.&lt;br /&gt;
&lt;br /&gt;
This is also used by TWL_FIRM Process9.&lt;/div&gt;</summary>
		<author><name>Motezazer</name></author>
	</entry>
	<entry>
		<id>https://www.3dbrew.org/w/index.php?title=CONFIG9_Registers&amp;diff=20044</id>
		<title>CONFIG9 Registers</title>
		<link rel="alternate" type="text/html" href="https://www.3dbrew.org/w/index.php?title=CONFIG9_Registers&amp;diff=20044"/>
		<updated>2017-05-25T15:58:49Z</updated>

		<summary type="html">&lt;p&gt;Motezazer: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;= Registers =&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot; border=&amp;quot;1&amp;quot;&lt;br /&gt;
!  Old3DS&lt;br /&gt;
!  Name&lt;br /&gt;
!  Address&lt;br /&gt;
!  Width&lt;br /&gt;
!  Used by&lt;br /&gt;
|-&lt;br /&gt;
| style=&amp;quot;background: green&amp;quot; | Yes&lt;br /&gt;
| [[#CFG9_SYSPROT9|CFG9_SYSPROT9]]&lt;br /&gt;
| 0x10000000&lt;br /&gt;
| 1&lt;br /&gt;
| Boot9&lt;br /&gt;
|-&lt;br /&gt;
| style=&amp;quot;background: green&amp;quot; | Yes&lt;br /&gt;
| [[#CFG9_SYSPROT11|CFG9_SYSPROT11]]&lt;br /&gt;
| 0x10000001&lt;br /&gt;
| 1&lt;br /&gt;
| Boot9&lt;br /&gt;
|-&lt;br /&gt;
| style=&amp;quot;background: green&amp;quot; | Yes&lt;br /&gt;
| [[#CFG9_RST11|CFG9_RST11]]&lt;br /&gt;
| 0x10000002&lt;br /&gt;
| 1&lt;br /&gt;
| Boot9&lt;br /&gt;
|-&lt;br /&gt;
| style=&amp;quot;background: green&amp;quot; | Yes&lt;br /&gt;
| CFG9_DEBUGCTL&lt;br /&gt;
| 0x10000004&lt;br /&gt;
| 4&lt;br /&gt;
|&lt;br /&gt;
|-&lt;br /&gt;
| style=&amp;quot;background: green&amp;quot; | Yes&lt;br /&gt;
| ?&lt;br /&gt;
| 0x10000008&lt;br /&gt;
| 1&lt;br /&gt;
| Boot9, Process9, TwlProcess9&lt;br /&gt;
|-&lt;br /&gt;
| style=&amp;quot;background: green&amp;quot; | Yes&lt;br /&gt;
| [[#CFG9_CARDCTL|CFG9_CARDCTL]]&lt;br /&gt;
| 0x1000000C&lt;br /&gt;
| 2&lt;br /&gt;
| Process9&lt;br /&gt;
|-&lt;br /&gt;
| style=&amp;quot;background: green&amp;quot; | Yes&lt;br /&gt;
| [[#CFG9_CARDSTATUS|CFG9_CARDSTATUS]]&lt;br /&gt;
| 0x10000010&lt;br /&gt;
| 1&lt;br /&gt;
| Process9&lt;br /&gt;
|-&lt;br /&gt;
| style=&amp;quot;background: green&amp;quot; | Yes&lt;br /&gt;
| CFG9_CARDCYCLES0&lt;br /&gt;
| 0x10000012&lt;br /&gt;
| 2&lt;br /&gt;
| Boot9, Process9&lt;br /&gt;
|-&lt;br /&gt;
| style=&amp;quot;background: green&amp;quot; | Yes&lt;br /&gt;
| CFG9_CARDCYCLES1&lt;br /&gt;
| 0x10000014&lt;br /&gt;
| 2&lt;br /&gt;
| Boot9, Process9&lt;br /&gt;
|-&lt;br /&gt;
| style=&amp;quot;background: green&amp;quot; | Yes&lt;br /&gt;
| ?&lt;br /&gt;
| 0x10000020&lt;br /&gt;
| 2&lt;br /&gt;
|&lt;br /&gt;
|-&lt;br /&gt;
| style=&amp;quot;background: green&amp;quot; | Yes&lt;br /&gt;
| ?&lt;br /&gt;
| 0x10000100&lt;br /&gt;
| 2&lt;br /&gt;
|&lt;br /&gt;
|-&lt;br /&gt;
| style=&amp;quot;background: red&amp;quot; | No&lt;br /&gt;
| [[#CFG9_EXTMEMCNT9|CFG9_EXTMEMCNT9]]&lt;br /&gt;
| 0x10000200&lt;br /&gt;
| 1&lt;br /&gt;
| NewKernel9&lt;br /&gt;
|-&lt;br /&gt;
| style=&amp;quot;background: green&amp;quot; | Yes&lt;br /&gt;
| [[#CFG9_MPCORECFG|CFG9_MPCORECFG]]&lt;br /&gt;
| 0x10000FFC&lt;br /&gt;
| 4&lt;br /&gt;
|&lt;br /&gt;
|-&lt;br /&gt;
| style=&amp;quot;background: green&amp;quot; | Yes&lt;br /&gt;
| [[#CFG9_BOOTENV|CFG9_BOOTENV]]&lt;br /&gt;
| 0x10010000&lt;br /&gt;
| 4&lt;br /&gt;
|&lt;br /&gt;
|-&lt;br /&gt;
| style=&amp;quot;background: green&amp;quot; | Yes&lt;br /&gt;
| [[#CFG9_UNITINFO|CFG9_UNITINFO]]&lt;br /&gt;
| 0x10010010&lt;br /&gt;
| 1&lt;br /&gt;
| Process9&lt;br /&gt;
|-&lt;br /&gt;
| style=&amp;quot;background: green&amp;quot; | Yes&lt;br /&gt;
| [[#CFG9_TWLUNITINFO|CFG9_TWLUNITINFO]]&lt;br /&gt;
| 0x10010014&lt;br /&gt;
| 1&lt;br /&gt;
| Process9&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
== CFG9_SYSPROT9 ==&lt;br /&gt;
CFG9_SYSPROT9 is used to permanently disable certain security-sensitive ARM9 memory areas until the next hard reset.&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot; border=&amp;quot;1&amp;quot;&lt;br /&gt;
!  Bit&lt;br /&gt;
!  Description&lt;br /&gt;
!  Used by&lt;br /&gt;
|-&lt;br /&gt;
| 0&lt;br /&gt;
| Disables ARM9 [[Memory_layout|bootrom]](+0x8000) when set to 1, and enables access to [[Memory_layout|FCRAM]]. Cannot be cleared to 0 once set to 1.&lt;br /&gt;
| Boot9&lt;br /&gt;
|-&lt;br /&gt;
| 1&lt;br /&gt;
| Disables [[OTP_Registers|OTP area]] when set to 1. On N3DS, also enables access to the extra 128 MB of [[Memory_layout|FCRAM]]. Cannot be cleared to 0 once set to 1.&lt;br /&gt;
| NewKernel9Loader, Process9&lt;br /&gt;
|-&lt;br /&gt;
| 31-2&lt;br /&gt;
| Not used&lt;br /&gt;
|&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
On Old 3DS, NATIVE_FIRM reads CFG9_SYSPROT9 to know whether it has previously initialized the TWL console-unique keys using the OTP data.  After setting the TWL console-unique keys, NATIVE_FIRM sets CFG9_SYSPROT9 bit 1 to disable the OTP area.  In subsequent FIRM launches prior to the next reset, NATIVE_FIRM will see that the OTP area is disabled, and skip this step.&lt;br /&gt;
&lt;br /&gt;
On New 3DS, the above is instead done by the [[FIRM#New_3DS_FIRM|Kernel9 loader]].  In addition to using the OTP data for initializing the TWL console-unique keys, the Kernel9 loader will generate the decryption key for NATIVE_FIRM.  The final keyslot for NATIVE_FIRM is preserved, so that at a non-reset FIRM launch, the keyslot can be reused, since the OTP would then be inaccessible.&lt;br /&gt;
&lt;br /&gt;
== CFG9_SYSPROT11 ==&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot; border=&amp;quot;1&amp;quot;&lt;br /&gt;
!  Bit&lt;br /&gt;
!  Description&lt;br /&gt;
!  Used by&lt;br /&gt;
|-&lt;br /&gt;
| 0&lt;br /&gt;
| Disables ARM11 [[Memory_layout|bootrom]](+0x8000) when set to 1, and enables access to [[Memory_layout|FCRAM]]. Cannot be cleared to 0 once set to 1.&lt;br /&gt;
| Boot9&lt;br /&gt;
|-&lt;br /&gt;
| 31-1&lt;br /&gt;
| Not used&lt;br /&gt;
|&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
== CFG9_RST11 ==&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot; border=&amp;quot;1&amp;quot;&lt;br /&gt;
!  Bit&lt;br /&gt;
!  Description&lt;br /&gt;
!  Used by&lt;br /&gt;
|-&lt;br /&gt;
| 0&lt;br /&gt;
| Presumably takes ARM11 out of reset. Cannot be set to 1 once it has been cleared.&lt;br /&gt;
| Boot9&lt;br /&gt;
|-&lt;br /&gt;
| 31-1&lt;br /&gt;
| Not used&lt;br /&gt;
|&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
== 0x10000008 ==&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot; border=&amp;quot;1&amp;quot;&lt;br /&gt;
!  Bit&lt;br /&gt;
!  Description&lt;br /&gt;
!  Used by&lt;br /&gt;
|-&lt;br /&gt;
| 1-0&lt;br /&gt;
| ?&lt;br /&gt;
|&lt;br /&gt;
|-&lt;br /&gt;
| 3-2&lt;br /&gt;
| AES related? Value 3 written after write to AES_CTL.&lt;br /&gt;
| Boot9, Process9, TwlProcess9&lt;br /&gt;
|-&lt;br /&gt;
| 31-4&lt;br /&gt;
| Reserved&lt;br /&gt;
|&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
== CFG9_CARDCTL ==&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot; border=&amp;quot;1&amp;quot;&lt;br /&gt;
!  Bit&lt;br /&gt;
!  Description&lt;br /&gt;
!  Used by&lt;br /&gt;
|-&lt;br /&gt;
| 1-0&lt;br /&gt;
| Gamecard active controller select (0=NTRCARD, 1=?, 2=CTRCARD0, 3=CTRCARD1)&lt;br /&gt;
| Process9&lt;br /&gt;
|-&lt;br /&gt;
| 8&lt;br /&gt;
| Enable gamecard eject IRQ, maybe?&lt;br /&gt;
| Process9&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
Depending on the gamecard controller that has been selected, one of the following gamecard registers will become active:&lt;br /&gt;
* Selecting NTRCARD will activate the register space at [[NTRCARD|0x10164000]].&lt;br /&gt;
* Selecting CTRCARD0 will activate the register space at [[CTRCARD|0x10004000]].&lt;br /&gt;
* Selecting CTRCARD1 will activate the register space at [[CTRCARD|0x10005000]].&lt;br /&gt;
&lt;br /&gt;
== CFG9_CARDSTATUS ==&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot; border=&amp;quot;1&amp;quot;&lt;br /&gt;
!  Bit&lt;br /&gt;
!  Description&lt;br /&gt;
!  Used by&lt;br /&gt;
|-&lt;br /&gt;
| 0&lt;br /&gt;
| Cartridge-slot empty (0=inserted, 1=empty)&lt;br /&gt;
| Process9&lt;br /&gt;
|-&lt;br /&gt;
| 3-2&lt;br /&gt;
| ?&lt;br /&gt;
| Process9&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
== CFG9_EXTMEMCNT9 ==&lt;br /&gt;
This register is New3DS-only.&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot; border=&amp;quot;1&amp;quot;&lt;br /&gt;
!  Bit&lt;br /&gt;
!  Description&lt;br /&gt;
!  Used by&lt;br /&gt;
|-&lt;br /&gt;
| 0&lt;br /&gt;
| Hide extended ARM9 memory (0=hidden, 1=shown)&lt;br /&gt;
| Kernel9 (New3DS)&lt;br /&gt;
|-&lt;br /&gt;
| 31-1&lt;br /&gt;
| Reserved&lt;br /&gt;
|&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
== CFG9_MPCORECFG ==&lt;br /&gt;
Identical to [[PDN#PDN_MPCORE_CFG|PDN_MPCORE_CFG]].&lt;br /&gt;
&lt;br /&gt;
== CFG9_BOOTENV ==&lt;br /&gt;
This register is used to determine what the previous running FIRM was. Its value is kept following an MCU reboot. Its initial value (on a cold boot) is 0. NATIVE_FIRM [[Development_Services_PXI|sets it to 1]] on shutdown/FIRM launch. [[Legacy_FIRM_PXI|LGY FIRM]] writes value 3 here when launching a TWL title, and writes value 7 when launching an AGB title.&lt;br /&gt;
&lt;br /&gt;
NATIVE_FIRM will only launch titles if this is not value 0, and will only save the [[Flash_Filesystem|AGB_FIRM savegame]] to SD if this is value 7.&lt;br /&gt;
&lt;br /&gt;
== CFG9_UNITINFO ==&lt;br /&gt;
This 8-bit register is value zero for retail, non-zero for dev/debug units.&lt;br /&gt;
&lt;br /&gt;
== CFG9_TWLUNITINFO ==&lt;br /&gt;
In the console-unique TWL key-init/etc function the ARM9 copies the u8 value from REG_UNITINFO to this register.&lt;br /&gt;
&lt;br /&gt;
This is also used by TWL_FIRM Process9.&lt;/div&gt;</summary>
		<author><name>Motezazer</name></author>
	</entry>
	<entry>
		<id>https://www.3dbrew.org/w/index.php?title=Mysteries&amp;diff=20015</id>
		<title>Mysteries</title>
		<link rel="alternate" type="text/html" href="https://www.3dbrew.org/w/index.php?title=Mysteries&amp;diff=20015"/>
		<updated>2017-05-20T09:33:08Z</updated>

		<summary type="html">&lt;p&gt;Motezazer: boot9strap allows code bootROM code execution, but this is not normal behaviour. The NTR path is just another path to boot a FIRM.&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;The following is a list of mysteries.&lt;br /&gt;
&lt;br /&gt;
== General ==&lt;br /&gt;
* What is the CTR abbreviation?&lt;br /&gt;
: C may stand for Chiheisen (&amp;quot;horizon&amp;quot; in Japanese, the O3DS&#039;s codename being &amp;quot;Project Horizon&amp;quot;).&lt;br /&gt;
:: Not true, Horizon refers to the OS.&lt;br /&gt;
&lt;br /&gt;
== Hardware ==&lt;br /&gt;
=== Why are there two CTRCARD controllers? ===&lt;br /&gt;
&#039;&#039;&#039;Background:&#039;&#039;&#039; Also [http://problemkaputt.de/twl-core.jpg DSi SoC pinout] shows evidence of dual NTRCARD controllers on the final DSi SoC. (This was a [http://i.imgur.com/0kJlbEw.png planned feature] of the DSi before being axed later in development)&lt;br /&gt;
&lt;br /&gt;
=== Why are there two EMMC controllers? ===&lt;br /&gt;
&#039;&#039;&#039;Theory:&#039;&#039;&#039; At some point during 3DS hardware development there was an idea to split up CTR and TWL nand into two different chips.&lt;br /&gt;
=== Is there a JTAG? ===&lt;br /&gt;
=== Is there more than one revision of the bootrom? ===&lt;br /&gt;
&#039;&#039;&#039;Background:&#039;&#039;&#039; Bootrom visible portion has been dumped on 3DS, 3DSXL, 2DS, New3DS. All matching exactly.&lt;br /&gt;
=== What is the EMMC controller @ 0x10100000 doing? ===&lt;br /&gt;
&#039;&#039;&#039;Background:&#039;&#039;&#039; There&#039;s dead code in NWM referencing it.&lt;br /&gt;
=== Why did they put NTRCARD accessible from ARM11? ===&lt;br /&gt;
&#039;&#039;&#039;Theory:&#039;&#039;&#039; At some point during 3DS hardware development there was a concept where ARM11 ran a menu with DS(i) icons while ARM9 was in TWL mode.&lt;br /&gt;
&lt;br /&gt;
=== Is there a secret message embedded in the 3DS keyscrambler constant? ===&lt;br /&gt;
&#039;&#039;&#039;Background:&#039;&#039;&#039; TWL key scrambler constant was &amp;quot;Nintendo Co., Ltd&amp;quot; in Japanese (&amp;quot;任天堂株式会社&amp;quot;), UTF-16LE encoded, with byte order mark.  The 3DS key scrambler constant, by comparison, is random-looking.&lt;br /&gt;
&lt;br /&gt;
=== What is the PDN abbreviation? ===&lt;br /&gt;
: Power distribution network&lt;br /&gt;
&lt;br /&gt;
=== How does Nintendo reflash bricked systems? ===&lt;br /&gt;
&#039;&#039;&#039;Theory:&#039;&#039;&#039; Before trying to boot from NAND, the bootrom checks to see if a key combination (Start + Select + X) is being held, and whether the shell is closed. If so, it tries to boot from an inserted NTR (Nintendo DS) cartridge.&lt;br /&gt;
This allows to execute a FIRM that is probably used by Nintendo to reflash the system.&lt;br /&gt;
&lt;br /&gt;
== Software ==&lt;br /&gt;
=== What was the problem in &amp;quot;initial program loader&amp;quot; that was mentioned in an FCC filing by Nintendo for 2DS? ===&lt;br /&gt;
&#039;&#039;&#039;Background:&#039;&#039;&#039; http://www.neogaf.com/forum/showthread.php?t=814624&amp;amp;page=1&lt;br /&gt;
=== What did SVC 0x74 in the ARM11 kernel do before it got stubbed? ===&lt;br /&gt;
=== What is the PTM abbreviation? ===&lt;br /&gt;
: Power/time management&lt;br /&gt;
&lt;br /&gt;
=== Why is the DTCM not used anywhere except bootrom? ===&lt;br /&gt;
&#039;&#039;&#039;Background:&#039;&#039;&#039; Bootrom is known to use part of DTCM as state, memsetting it to 0 when it&#039;s done. After that, it is never used again.&lt;br /&gt;
=== How is CTRAging launched during factory setup? ===&lt;br /&gt;
&#039;&#039;&#039;Background:&#039;&#039;&#039; No TestMenu version is capable of launching CTRAging directly: O3DS factory TestMenu can only launch DevMenu installed on NAND, the inserted cartridge and the TWL/AGB test apps; N3DS factory TestMenu can only launch DevMenu installed on NAND, the inserted cartridge and System Settings.&lt;br /&gt;
=== Why are there 4 stubbed syscalls named SendSyncRequest1-4? ===&lt;/div&gt;</summary>
		<author><name>Motezazer</name></author>
	</entry>
	<entry>
		<id>https://www.3dbrew.org/w/index.php?title=FIRM&amp;diff=19648</id>
		<title>FIRM</title>
		<link rel="alternate" type="text/html" href="https://www.3dbrew.org/w/index.php?title=FIRM&amp;diff=19648"/>
		<updated>2017-02-16T12:36:57Z</updated>

		<summary type="html">&lt;p&gt;Motezazer: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;This page describes the file format for the [[Title list#00040138 - System Firmware|3DS&#039; Firmware]], it contains up to four &#039;sections&#039; of data comprising the ARM9 and ARM11 kernels, and some fundamental processes. The firmware sections are not encrypted. In a nutshell, a FIRM contains all the data required to set up the ARM9 and ARM11 kernels, and basic operating functionality.&lt;br /&gt;
&lt;br /&gt;
The ARM9 section contains the ARM9 kernel (and loader) and the Process9 NCCH (which is the only process run in user mode on the ARM9). The ARM11 sections contain the ARM11 kernel (and loader), and various ARM11 process NCCHs. For NATIVE_FIRM/SAFE_MODE_FIRM these ARM11 processes are sm, fs, pm, loader, and pxi. Normally the 4th section is not used. The code loaded from FIRM is constantly running on the system until another FIRM is launched. The ARM11 kernel is hard-coded to always decompress the ExeFS .code of embedded ARM11 NCCHs without checking the exheader compression bit.&lt;br /&gt;
&lt;br /&gt;
== FIRM Header ==&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot; border=&amp;quot;1&amp;quot;&lt;br /&gt;
|-&lt;br /&gt;
!  OFFSET&lt;br /&gt;
!  SIZE&lt;br /&gt;
!  DESCRIPTION&lt;br /&gt;
|-&lt;br /&gt;
|  0x000&lt;br /&gt;
|  4&lt;br /&gt;
|  Magic &#039;FIRM&#039;&lt;br /&gt;
|-&lt;br /&gt;
|  0x004&lt;br /&gt;
|  4&lt;br /&gt;
|  Boot priority (highest value = max prio), this is normally zero.&lt;br /&gt;
|-&lt;br /&gt;
|  0x008&lt;br /&gt;
|  4&lt;br /&gt;
|  ARM11 Entrypoint&lt;br /&gt;
|-&lt;br /&gt;
|  0x00C&lt;br /&gt;
|  4&lt;br /&gt;
|  ARM9 Entrypoint&lt;br /&gt;
|-&lt;br /&gt;
|  0x010&lt;br /&gt;
|  0x030&lt;br /&gt;
|  Reserved&lt;br /&gt;
|-&lt;br /&gt;
|  0x040&lt;br /&gt;
|  0x0C0 (0x030*4)&lt;br /&gt;
|  Firmware Section Headers&lt;br /&gt;
|-&lt;br /&gt;
|  0x100&lt;br /&gt;
|  0x100&lt;br /&gt;
|  RSA-2048 signature of the FIRM header&#039;s SHA-256 hash. The signature is checked when bootrom/Process9 are doing FIRM-launch (with the public key being hardcoded in each). The signature is not checked when installing FIRM to the NAND firm0/firm1 partitions.&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
== Firmware Section Headers ==&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot; border=&amp;quot;1&amp;quot;&lt;br /&gt;
|-&lt;br /&gt;
!  OFFSET&lt;br /&gt;
!  SIZE&lt;br /&gt;
!  DESCRIPTION&lt;br /&gt;
|-&lt;br /&gt;
|  0x000&lt;br /&gt;
|  4&lt;br /&gt;
|  Byte offset&lt;br /&gt;
|-&lt;br /&gt;
|  0x004&lt;br /&gt;
|  4&lt;br /&gt;
|  Physical address where the section is loaded to.&lt;br /&gt;
|-&lt;br /&gt;
|  0x008&lt;br /&gt;
|  4&lt;br /&gt;
|  Byte-size.  While loading FIRM this is the field used to determine whether the section exists or not, by checking for value 0x0.&lt;br /&gt;
|-&lt;br /&gt;
|  0x00C&lt;br /&gt;
|  4&lt;br /&gt;
|  Copy-method (0 = NDMA, 1 = XDMA, 2 = CPU mem-copy), Process9 ignores this field. Boot9 doesn&#039;t immediately throw an error when this isn&#039;t 0..2. In that case it will jump over section-data-loading which then results in the hash verification with the below hash being done with the hash already stored in the SHA hardware.&lt;br /&gt;
|-&lt;br /&gt;
|  0x010&lt;br /&gt;
|  0x020&lt;br /&gt;
|  SHA-256 Hash of Firmware Section&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
== [[New_3DS]] FIRM ==&lt;br /&gt;
For New3DS firmwares (NATIVE_FIRM, TWL_FIRM, ..), the ARM9 FIRM binary has an additional layer of crypto. At the end of each ARM9 binary, there&#039;s a plaintext loader. The format of the FIRM header is identical to regular 3DS FIRM(the RSA modulo is the same as regular 3DS too).&lt;br /&gt;
&lt;br /&gt;
Before checking [[CONFIG_Registers|CFG_SYSPROT9]] the loader main() does the following:&lt;br /&gt;
* On [[9.5.0-22|9.5.0-X]]: executes a nop instruction with r0=0 and r1=&amp;lt;address of arm9binhdr+0x50&amp;gt;.&lt;br /&gt;
* Clears bit6 in [[AES_Registers|REG_AESKEYCNT]].&lt;br /&gt;
&lt;br /&gt;
If [[CONFIG_Registers#CFG_SYSPROT9|CFG_SYSPROT9]] bit 1 is clear (which means the OTP area is unlocked and so it knows that this is a hard reboot), it does the following things:&lt;br /&gt;
* Clears 0x200-bytes on the stack, then reads [[Flash_Filesystem|NAND]] sector 0x96(NAND image offset 0x12C00), with size 0x200-bytes into that stack buffer.&lt;br /&gt;
* Checks [[CONFIG_Registers#CFG_SYSPROT9|CFG_SYSPROT9]] bit 1 again, if it&#039;s set then it executes a panic function(set r0-r2=0, execute nop instruction, then execute instruction &amp;quot;bkpt 0x99&amp;quot;).&lt;br /&gt;
* Hashes data from the OTP region [[IO_Registers|0x10012000-0x10012090]] using SHA256 via the [[SHA_Registers|SHA]] hardware.&lt;br /&gt;
* Clears bit6 in [[AES_Registers|REG_AESKEYCNT]]. Initializes AES keyslot 0x11 keyX, keyY to the lower and higher portion of the above hash, respectively. Due to the above hashed data, the keyX+keyY here are console-unique.&lt;br /&gt;
* Decrypts the first 0x10-byte block in the above read NAND sector with keyslot 0x11 using AES-ECB. [[9.6.0-24|9.6.0-X]]: Then it decrypts the 0x10-bytes at offset 0x10 in the sector with keyslot 0x11.&lt;br /&gt;
* Then the normalkey, keyX, and keyY, for keyslot 0x11 are cleared to zero. Runs the TWL key-init/etc code which was originally in the ARM9-kernel, then writes 0x2 to [[CONFIG_Registers|CFG_SYSPROT9]] to disable the OTP area.&lt;br /&gt;
* Then it uses the above decrypted block from sector+0 to set the normalkey for keyslot 0x11. Decrypts arm9_bin_buf+0 using keyslot 0x11 with AES-ECB, and initialises keyX for keyslot 0x15 with it.&lt;br /&gt;
* [[9.6.0-24|9.6.0-X]]: Then it uses the above decrypted block from sector+0 to set the normalkey for keyslot 0x11. Decrypts a 0x10-byte block from arm9loader .(ro)data using keyslot 0x11 with AES-ECB, and initializes keyX for keyslot 0x18 with it(same block as previous versions).&lt;br /&gt;
* [[9.6.0-24|9.6.0-X]]: Starting with this version keyslot 0x16 keyX init was moved here, see below for details on this. The code for this is same as  [[9.5.0-22|9.5.0-X]], except the decrypted normalkey from sector+0x10 is used for keyslot 0x11 instead.&lt;br /&gt;
* Initialises KeyX for keyslots 0x18..0x1F(0x19..0x1F with [[9.6.0-24|9.6.0-X]]) with the output of decrypting a 0x10-byte block with AES-ECB using keyslot 0x11. This block was changed to a new one separate from keyslot 0x18, starting with [[9.6.0-24|9.6.0-X]]. The last byte in this 0x10-byte input block is increased by 0x01 after initializing each keyslot. Before doing the crypto each time, the loader sets the normal-key for keyslot 0x11 to the plaintext normalkey from sector+0(+0x10 with [[9.6.0-24|9.6.0-X]]). These are New3DS-specific keys.&lt;br /&gt;
* [[9.5.0-22|9.5.0-X]](moved to above with [[9.6.0-24|9.6.0-X]]): Sets the normal-key for keyslot 0x11 to the same one already decrypted on the stack. Decrypts the 0x10-byte block at arm9binhdr+0x60 with AES-ECB using keyslot 0x11, then sets the keyX for keyslot 0x16 to the output data.&lt;br /&gt;
* [[9.5.0-22|9.5.0-X]]: The normalkey, keyX, and keyY, for keyslot 0x11 are then cleared to zero.&lt;br /&gt;
&lt;br /&gt;
When [[CONFIG_Registers#CFG_SYSPROT9|CFG_SYSPROT9]] bit 1 is set(which means this happens only when this loader runs again for firm-launch), the normalkey, keyX, and keyY, for keyslot 0x11 are cleared to zero.&lt;br /&gt;
&lt;br /&gt;
It sets KeyY for keyslot 0x15(0x16 with [[9.5.0-22|9.5.0-X]]) to arm9_bin_buf+16, the CTR to arm9_bin_buf+32 (both are unique for every version). It then proceeds to decrypt the binary with AES-CTR. When done, it sets the normal-key for the keyslot used for binary decryption to zeros. It then decrypts arm9_bin_buf+64 using an hardcoded keyY for keyslot 0x15([[9.5.0-22|9.5.0-X]]/[[9.6.0-24|9.6.0-X]] also uses keyslot 0x15), sets the normal-key for this keyslot to zeros again, then makes sure the output block is all zeroes. If it is, it does some cleanup then it jumps to the entrypoint for the decrypted binary. Otherwise it will clear the keyX, keyY, and normal-key for each of the keyslots initialized by this loader (on [[9.6.0-24|9.6.0-X]]+, on older versions this was bugged and cleared keys 0x00..0x07 instead of 0x18..0x1F), do cleanup(same cleanup as when the decrypted block is all-zero) then just loop forever.&lt;br /&gt;
&lt;br /&gt;
Thus, the ARM9 binary has the following header:&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot; border=&amp;quot;1&amp;quot;&lt;br /&gt;
|-&lt;br /&gt;
!  OFFSET&lt;br /&gt;
!  SIZE&lt;br /&gt;
!  DESCRIPTION&lt;br /&gt;
|-&lt;br /&gt;
|  0x000&lt;br /&gt;
|  16&lt;br /&gt;
|  Encrypted KeyX (same for all FIRM&#039;s)&lt;br /&gt;
|-&lt;br /&gt;
|  0x010&lt;br /&gt;
|  16&lt;br /&gt;
|  KeyY&lt;br /&gt;
|-&lt;br /&gt;
|  0x020&lt;br /&gt;
|  16&lt;br /&gt;
|  CTR&lt;br /&gt;
|-&lt;br /&gt;
|  0x030&lt;br /&gt;
|  8&lt;br /&gt;
|  Size of encrypted binary, as ASCII text?&lt;br /&gt;
|-&lt;br /&gt;
|  0x038&lt;br /&gt;
|  8&lt;br /&gt;
|  ?&lt;br /&gt;
|-&lt;br /&gt;
|  0x040&lt;br /&gt;
|  16&lt;br /&gt;
|  Control block&lt;br /&gt;
|-&lt;br /&gt;
|  0x050&lt;br /&gt;
|  16&lt;br /&gt;
|  Added with [[9.5.0-22|9.5.0-X]]. Only used for hardware debugging: a nop instruction is executed with r0=0 and r1=&amp;lt;address of this data&amp;gt;.&lt;br /&gt;
|-&lt;br /&gt;
|  0x060&lt;br /&gt;
|  16&lt;br /&gt;
|  Added with [[9.5.0-22|9.5.0-X]]. Encrypted keyX for keyslot 0x16.&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
Originally the padding after the header before offset 0x800(start of actual ARM9-binary) was 0xFF bytes, with [[9.5.0-22|9.5.0-X]] this was changed to 0x0.&lt;br /&gt;
&lt;br /&gt;
For the New3DS NATIVE_FIRM arm9-section header, the only difference between the [[8.1.0-0_New3DS]] version and the [[9.0.0-20]] version is that the keyY, CTR, and the block at 0x30 in the header were updated.&lt;br /&gt;
&lt;br /&gt;
===New3DS ARM9 binary loader versions===&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot; border=&amp;quot;1&amp;quot;&lt;br /&gt;
|-&lt;br /&gt;
!  FIRM system version(s)&lt;br /&gt;
!  Description&lt;br /&gt;
|-&lt;br /&gt;
| [[8.1.0-0_New3DS]] - [[9.3.0-21|9.3.0-X]]&lt;br /&gt;
| Initial version.&lt;br /&gt;
|-&lt;br /&gt;
| [[9.5.0-22|9.5.0-X]]&lt;br /&gt;
| Added keyX initialization for keyslot 0x16(see above), and added code for clearing keyslot 0x11 immediately after the code finishes using keyslot 0x11. The keyslot used for arm9bin decryption was changed from 0x15 to 0x16. Added code for clearing keyslot 0x16 when control-block decryption fails. Added code for using arm9bin_hdr+0x50 with a nop instruction, at the very beginning of the main arm9-loader function. Added two new 0x10-blocks to the arm9bin-hdr.&lt;br /&gt;
|-&lt;br /&gt;
| [[9.6.0-24|9.6.0-X]] - [[11.3.0-36|11.3.0-X]]&lt;br /&gt;
| See above and [[9.6.0-24|here]].&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
===New3DS ARM9 kernel===&lt;br /&gt;
The only actual code-difference for the Old3DS/New3DS ARM9-kernels&#039; crt0, besides TWL AES / [[IO_Registers|0x10012000]] related code, is that the New3DS ARM9-kernel writes 0x1 to [[CONFIG_Registers|REG_EXTMEMCNT9]] in the crt0.&lt;br /&gt;
&lt;br /&gt;
===New3DS Process9===&lt;br /&gt;
The following is all of the differences for Old3DS/New3DS Process9 with [[9.3.0-21|9.3.0-X]]:&lt;br /&gt;
* The FIRM-launch code called at the end of the New3DS proc9 main() has different mem-range checks.&lt;br /&gt;
* In the New3DS proc9, the v6.0/v7.0 keyinit function at the very beginning(before the original code) had additional code added for setting [[Flash_Filesystem|CTRNAND]] [[AES_Registers|keyslot]] 0x5, with keydata from .data. After setting the keyY, the keyY in .data is cleared.&lt;br /&gt;
* In New3DS proc9, the functions for getting the gamecard crypto keyslots / NCCH keyslot can return New3DS keyslots when New3DS flags(NCSD/NCCH) are set.&lt;br /&gt;
* The code/data for the binary near the end of arm9mem is slightly different, because of memory-region sizes.&lt;br /&gt;
* The only difference in .data(besides the above code binary) is that the New3DS proc9 has an additional 0x10-byte block for the keyslot 0x5 keyY, see above.&lt;br /&gt;
&lt;br /&gt;
== Variations ==&lt;br /&gt;
There exists different official firmwares for the 3DS: The default one (NATIVE_FIRM) is used to run all 3DS content and boots by default, while backwards compatibility is handled by TWL_FIRM and AGB_FIRM. There furthermore is a rescue mode provided by SAFE_MODE_FIRM.&lt;br /&gt;
&lt;br /&gt;
=== NATIVE_FIRM ===&lt;br /&gt;
NATIVE_FIRM is the FIRM which is installed to the [[Flash_Filesystem|NAND]] firm partitions, which is loaded by bootrom.&lt;br /&gt;
&lt;br /&gt;
Version history:&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot; border=&amp;quot;1&amp;quot;&lt;br /&gt;
!  System version&lt;br /&gt;
!  old 3DS title version&lt;br /&gt;
!  old 3DS hex title contentID&lt;br /&gt;
!  Kernel/FIRM version (old 3DS/new 3DS)&lt;br /&gt;
|-&lt;br /&gt;
| [[Factory_Setup|Factory]] FIRM (titleID 00040001-00000002)&lt;br /&gt;
| v0&lt;br /&gt;
| 00&lt;br /&gt;
| 2.3-0&lt;br /&gt;
|-&lt;br /&gt;
| Pre-1.0. Referenced in the v1.0 Home Menu NCCH plain-region.&lt;br /&gt;
| &lt;br /&gt;
| &lt;br /&gt;
| 2.23-X&lt;br /&gt;
|-&lt;br /&gt;
| [[1.0.0-0|1.0.0]]&lt;br /&gt;
| v432&lt;br /&gt;
| 00&lt;br /&gt;
| 2.27-0&lt;br /&gt;
|-&lt;br /&gt;
| [[1.1.0-1|1.1.0]]&lt;br /&gt;
| v1472&lt;br /&gt;
| 02&lt;br /&gt;
| 2.28-0&lt;br /&gt;
|-&lt;br /&gt;
| [[2.0.0-2|2.0.0]]&lt;br /&gt;
| v2516&lt;br /&gt;
| 09&lt;br /&gt;
| 2.29-7&lt;br /&gt;
|-&lt;br /&gt;
| [[2.1.0-3|2.1.0]]&lt;br /&gt;
| v3553&lt;br /&gt;
| 0B&lt;br /&gt;
| 2.30-18&lt;br /&gt;
|-&lt;br /&gt;
| [[2.2.0-X|2.2.0]]&lt;br /&gt;
| v4595&lt;br /&gt;
| 0F&lt;br /&gt;
| 2.31-40&lt;br /&gt;
|-&lt;br /&gt;
| [[3.0.0-5|3.0.0]]&lt;br /&gt;
| v5647&lt;br /&gt;
| 18&lt;br /&gt;
| 2.32-15&lt;br /&gt;
|-&lt;br /&gt;
| [[4.0.0-7|4.0.0]]&lt;br /&gt;
| v6677&lt;br /&gt;
| 1D&lt;br /&gt;
| 2.33-4&lt;br /&gt;
|-&lt;br /&gt;
| [[4.1.0-8|4.1.0]]&lt;br /&gt;
| v7712&lt;br /&gt;
| 1F&lt;br /&gt;
| 2.34-0&lt;br /&gt;
|-&lt;br /&gt;
| [[5.0.0-11|5.0.0]]&lt;br /&gt;
| v8758&lt;br /&gt;
| 25&lt;br /&gt;
| 2.35-6&lt;br /&gt;
|-&lt;br /&gt;
| [[5.1.0-11|5.1.0]]&lt;br /&gt;
| v9792&lt;br /&gt;
| 26&lt;br /&gt;
| 2.36-0&lt;br /&gt;
|-&lt;br /&gt;
| [[6.0.0-11|6.0.0]]&lt;br /&gt;
| v10833&lt;br /&gt;
| 29&lt;br /&gt;
| 2.37-0&lt;br /&gt;
|-&lt;br /&gt;
| [[6.1.0-11|6.1.0]]&lt;br /&gt;
| v11872&lt;br /&gt;
| 2A&lt;br /&gt;
| 2.38-0&lt;br /&gt;
|-&lt;br /&gt;
| [[7.0.0-13|7.0.0]]&lt;br /&gt;
| v12916&lt;br /&gt;
| 2E&lt;br /&gt;
| 2.39-4&lt;br /&gt;
|-&lt;br /&gt;
| [[7.2.0-17|7.2.0]]&lt;br /&gt;
| v13956&lt;br /&gt;
| 30&lt;br /&gt;
| 2.40-0&lt;br /&gt;
|-&lt;br /&gt;
| [[8.0.0-18|8.0.0]]&lt;br /&gt;
| v15047&lt;br /&gt;
| 37&lt;br /&gt;
| 2.44-6&lt;br /&gt;
|-&lt;br /&gt;
| [[8.1.0-0_New3DS]]&lt;br /&gt;
|N/A&lt;br /&gt;
|N/A&lt;br /&gt;
| 2.45-5&lt;br /&gt;
|-&lt;br /&gt;
| [[9.0.0-20|9.0.0]]&lt;br /&gt;
| v17120&lt;br /&gt;
| 38&lt;br /&gt;
| 2.46-0&lt;br /&gt;
|-&lt;br /&gt;
| [[9.3.0-21|9.3.0]]&lt;br /&gt;
| v18182&lt;br /&gt;
| 3F&lt;br /&gt;
| 2.48-3&lt;br /&gt;
|-&lt;br /&gt;
| [[9.5.0-22|9.5.0]]&lt;br /&gt;
| v19216&lt;br /&gt;
| 40&lt;br /&gt;
| 2.49-0&lt;br /&gt;
|-&lt;br /&gt;
| [[9.6.0-24|9.6.0]]&lt;br /&gt;
| v20262&lt;br /&gt;
| 49&lt;br /&gt;
| 2.50-1&lt;br /&gt;
|-&lt;br /&gt;
| [[10.0.0-27|10.0.0]]&lt;br /&gt;
| v21288&lt;br /&gt;
| 4B&lt;br /&gt;
| 2.50-7&lt;br /&gt;
|-&lt;br /&gt;
| [[10.2.0-28|10.2.0]]&lt;br /&gt;
| v22313&lt;br /&gt;
| 4C&lt;br /&gt;
| 2.50-9&lt;br /&gt;
|-&lt;br /&gt;
| [[10.4.0-29|10.4.0]]&lt;br /&gt;
| v23341&lt;br /&gt;
| 50&lt;br /&gt;
| 2.50-11&lt;br /&gt;
|-&lt;br /&gt;
| [[11.0.0-33|11.0.0]]&lt;br /&gt;
| v24368&lt;br /&gt;
| 52&lt;br /&gt;
| 2.51-0&lt;br /&gt;
|-&lt;br /&gt;
| [[11.1.0-34|11.1.0]]&lt;br /&gt;
| v25396&lt;br /&gt;
| 56&lt;br /&gt;
| 2.51-2&lt;br /&gt;
|-&lt;br /&gt;
| [[11.2.0-35|11.2.0]]&lt;br /&gt;
| v26432&lt;br /&gt;
| 58&lt;br /&gt;
| 2.52-0&lt;br /&gt;
|-&lt;br /&gt;
| [[11.3.0-36|11.3.0]]&lt;br /&gt;
| v27476&lt;br /&gt;
| 5C&lt;br /&gt;
| 2.53-0&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
The above kernel/FIRM versions are in the format: &amp;lt;KERNEL_VERSIONMAJOR&amp;gt;.&amp;lt;KERNEL_VERSIONMINOR&amp;gt;-&amp;lt;KERNEL_VERSIONREVISION&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
=== SAFE_MODE_FIRM ===&lt;br /&gt;
SAFE_MODE is used for running the [[System_Settings#System_Updater|System Updater]]. SAFE_MODE_FIRM and NATIVE_FIRM for the initial versions are exactly the same, except for the system core version fields.&lt;br /&gt;
&lt;br /&gt;
=== TWL_FIRM ===&lt;br /&gt;
TWL_FIRM handles DS(i) backwards compatibility.&lt;br /&gt;
&lt;br /&gt;
The 3DS-mode ARM9 core seems to switch into DSi-mode(for running DSi-mode ARM9 code) by writing to a [[PDN]] register(this changes the memory layout to DSi-mode / etc, therefore this register poke *must* be executed from ITCM). This is the final 3DS-mode register poke before the ARM9 switches into DSi-mode. DS(i)-mode ARM7 code is run on the internal [[ARM7]] core, which is started up during TWL_FIRM boot. Trying to read from the exception-vector region(address 0x0) under this DSi-mode ARM7 seems to only return 0x00/0xFF data. Also note that this DSi-mode ARM7 runs code(stored in TWL_FIRM) which pokes some DSi-mode registers that on the DSi were used for disabling access to the DSi bootROMs, however these registers do not affect the 3DS DSi-mode ARM9/ARM7 &amp;quot;bootrom&amp;quot; region(exceptionvector region + 0x8000) at all.&lt;br /&gt;
&lt;br /&gt;
For shutting down the system, TWL_FIRM writes u8 value 8 to [[I2C]] MCU register 0x20. For returning to 3DS-mode, TWL_FIRM writes value 4 to that MCU register to trigger a hardware system reboot.&lt;br /&gt;
&lt;br /&gt;
The TWL_FIRM ARM11-process includes a TWL bootloader, see [http://dsibrew.org/wiki/Bootloader here] and [[Memory_layout#Detailed_TWL_FIRM_ARM11_Memory|here]] for details.&lt;br /&gt;
&lt;br /&gt;
TWL_FIRM verifies all TWL RSA padding with the following. This is different from the DSi &amp;quot;BIOS&amp;quot; code.&lt;br /&gt;
* The first byte must be 0x0.&lt;br /&gt;
* The second byte must be 0x1 or 0x2.&lt;br /&gt;
* Executes a while(&amp;lt;value of byte at current pos in RSA message&amp;gt;). When the second_byte in the message is 0x1, the byte at curpos must be 0xFF(otherwise the non-zero value of the byte at curpos doesn&#039;t matter). This loop must find a zero byte before offset 0x7F in the message otherwise an error is returned.&lt;br /&gt;
* Returns an address for msg_curpos+1.&lt;br /&gt;
totalhashdatasize = rsasig_bytesize - above position in the message for the hashdata. The actual &amp;quot;totalhashdatasize&amp;quot; in the RSA message must be &amp;lt;= &amp;lt;expected hashdata_size&amp;gt;(0x74 for bootloader). The TWL_FIRM code copies the RSA &amp;quot;hashdata&amp;quot; to the output buffer, using the actual size of the RSA &amp;quot;hashdata&amp;quot;.&lt;br /&gt;
&lt;br /&gt;
=== AGB_FIRM ===&lt;br /&gt;
AGB_FIRM handles running GBA VC titles. The ARM9 FIRM section for TWL_FIRM and AGB_FIRM are exactly the same (for TWL_FIRM and AGB_FIRM versions which were updated with the same system-update).&lt;br /&gt;
&lt;br /&gt;
== FIRM Launch Parameters ==&lt;br /&gt;
The FIRM-launch parameters structure is located at FCRAM+0, size 0x1000-bytes. The ARM11-kernel copies this structure elsewhere, then clears the 0x1000-bytes at FCRAM+0. It will not handle an existing structure at FCRAM+0 if [[CONFIG Registers#CFG_BOOTENV|CFG_BOOTENV]] is zero. The ARM9 kernel [[Configuration_Memory#0x1FF80016|writes some values]] about the boot environment to AXI WRAM during init to enable this.&lt;br /&gt;
&lt;br /&gt;
Note: it seems NATIVE_FIRM ARM11-kernel didn&#039;t parse this during boot until [[3.0.0-5|3.0.0-X]]?&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot; border=&amp;quot;1&amp;quot;&lt;br /&gt;
|-&lt;br /&gt;
!  OFFSET&lt;br /&gt;
!  SIZE&lt;br /&gt;
!  DESCRIPTION&lt;br /&gt;
|-&lt;br /&gt;
| 0x300&lt;br /&gt;
| 0x100&lt;br /&gt;
| &#039;TLNC&#039; block created by TWL applications, handled by NS for backwards-compatibility purposes. See [[NS#Auto-boot|here]] for more info.&lt;br /&gt;
|-&lt;br /&gt;
| 0x400&lt;br /&gt;
| 0x4&lt;br /&gt;
| Flags&lt;br /&gt;
|-&lt;br /&gt;
| 0x410&lt;br /&gt;
| 0xC&lt;br /&gt;
| This is used for overriding the FIRM_* fields in [[Configuration_Memory]], when the flag listed below is set, in the following order(basically just data-copy from here to 0x1FF80060): &amp;quot;FIRM_?&amp;quot;, FIRM_VERSIONREVISION, FIRM_VERSIONMINOR, FIRM_VERSIONMAJOR, FIRM_SYSCOREVER, and FIRM_CTRSDKVERSION.&lt;br /&gt;
|-&lt;br /&gt;
| 0x438&lt;br /&gt;
| 0x4&lt;br /&gt;
| The kernel checks this field for value 0xFFFF, if it matches the kernel uses the rest of these parameter fields, otherwise FIRM-launch parameters fields are ignored by the kernel.&lt;br /&gt;
|-&lt;br /&gt;
| 0x43C&lt;br /&gt;
| 0x4&lt;br /&gt;
| CRC32, this is calculated starting at FIRM-params offset 0x400, with size 0x140(with this field cleared to zero during calculation). When invalid the kernel clears the entire buffer used for storing the FIRM-params, therefore no actual FIRM-params are handled after that.&lt;br /&gt;
|-&lt;br /&gt;
| 0x440&lt;br /&gt;
| 0x10&lt;br /&gt;
| Titleinfo [[Filesystem_services#ProgramInfo|Program Info]], used by NS during NS startup, to launch the specified title when the below flag is set.&lt;br /&gt;
|-&lt;br /&gt;
| 0x450&lt;br /&gt;
| 0x10&lt;br /&gt;
| Titleinfo [[Filesystem_services#ProgramInfo|Program Info]]. This might be used for returning to the specified title, once the above launched title terminates?&lt;br /&gt;
|-&lt;br /&gt;
| 0x460&lt;br /&gt;
| 0x4&lt;br /&gt;
| Bit0: 0 = titleinfo structure isn&#039;t set, 1 = titleinfo structure is set.&lt;br /&gt;
|-&lt;br /&gt;
| 0x480&lt;br /&gt;
| 0x20&lt;br /&gt;
| This can be set via buf1 for [[APT:SendDeliverArg]]/[[APT:StartApplication]].&lt;br /&gt;
|-&lt;br /&gt;
| 0x4A0&lt;br /&gt;
| 0x10&lt;br /&gt;
| This can be set by [[NSS:SetWirelessRebootInfo]].&lt;br /&gt;
|-&lt;br /&gt;
| 0x4B0&lt;br /&gt;
| 0x14&lt;br /&gt;
| SHA1-HMAC of the banner for TWL/NTR titles. This can be set by [[NSS:SetTWLBannerHMAC]].&lt;br /&gt;
|-&lt;br /&gt;
| 0x500&lt;br /&gt;
| 0x40&lt;br /&gt;
| This is used by [[APT:LoadSysMenuArg]] and [[APT:StoreSysMenuArg]].&lt;br /&gt;
|-&lt;br /&gt;
| 0xD70&lt;br /&gt;
| 0x290&lt;br /&gt;
| [[Config Savegame|Config]] data struct for LGY FIRM.&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
Flags from offset 0x400:&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot; border=&amp;quot;1&amp;quot;&lt;br /&gt;
|-&lt;br /&gt;
!  OFFSET&lt;br /&gt;
!  SIZE&lt;br /&gt;
!  DESCRIPTION&lt;br /&gt;
|-&lt;br /&gt;
| 0x0&lt;br /&gt;
| 0x1&lt;br /&gt;
| This can be used for overriding the default FCRAM [[Memory_layout|memory-regions]] allocation sizes(APPLICATION, SYSTEM, and BASE). The values for this is the same as [[Configuration_Memory#APPMEMTYPE|Configmem-APPMEMTYPE]]. Values 0-1 are handled the same way by the kernel. However for NS, 0=titleinfo structure for launching a title isn&#039;t set, while non-zero=titleinfo structure is set.&lt;br /&gt;
|-&lt;br /&gt;
| 0x1&lt;br /&gt;
| 0x3&lt;br /&gt;
| Setting bit0 here enables overriding the FIRM_* fields in [[Configuration_Memory]].&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
[[Config Savegame|Config]] struct for booting LGY FIRMs from offset 0xD70:&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot; border=&amp;quot;1&amp;quot;&lt;br /&gt;
|-&lt;br /&gt;
!  OFFSET&lt;br /&gt;
!  SIZE&lt;br /&gt;
!  DESCRIPTION&lt;br /&gt;
|-&lt;br /&gt;
| 0x0&lt;br /&gt;
| 0x1&lt;br /&gt;
| Config block 0x30000.&lt;br /&gt;
|-&lt;br /&gt;
| 0x1&lt;br /&gt;
| 0x1&lt;br /&gt;
| Config block 0x70001.&lt;br /&gt;
|-&lt;br /&gt;
| 0x2&lt;br /&gt;
| 0x1&lt;br /&gt;
| System language (Config block 0xA0002).&lt;br /&gt;
|-&lt;br /&gt;
| 0x3&lt;br /&gt;
| 0x1&lt;br /&gt;
| [[Cfg:SecureInfoGetRegion|Region from SecureInfo]] (&amp;quot;pseudo-block&amp;quot; 0x140000 in LGY FIRM).&lt;br /&gt;
|-&lt;br /&gt;
| 0x4&lt;br /&gt;
| 0xF&lt;br /&gt;
| [[CfgS:SecureInfoGetSerialNo|Serial number from SecureInfo]] (&amp;quot;pseudo-block&amp;quot; 0x140001 in LGY FIRM).&lt;br /&gt;
|-&lt;br /&gt;
| 0x13&lt;br /&gt;
| 0x1&lt;br /&gt;
| Config block 0x100002.&lt;br /&gt;
|-&lt;br /&gt;
| 0x14&lt;br /&gt;
| 0x10&lt;br /&gt;
| Config block 0x100003.&lt;br /&gt;
|-&lt;br /&gt;
| 0x24&lt;br /&gt;
| 0x2&lt;br /&gt;
| Config block 0x100000.&lt;br /&gt;
|-&lt;br /&gt;
| 0x26&lt;br /&gt;
| 0x1&lt;br /&gt;
| Cleared to zero.&lt;br /&gt;
|-&lt;br /&gt;
| 0x27&lt;br /&gt;
| 0x1&lt;br /&gt;
| Cleared to zero.&lt;br /&gt;
|-&lt;br /&gt;
| 0x28&lt;br /&gt;
| 0x94&lt;br /&gt;
| Config block 0x100001.&lt;br /&gt;
|-&lt;br /&gt;
| 0xBC&lt;br /&gt;
| 0x2&lt;br /&gt;
| Config block 0x50000.&lt;br /&gt;
|-&lt;br /&gt;
| 0xBE&lt;br /&gt;
| 0x2&lt;br /&gt;
| Config block 0x50001.&lt;br /&gt;
|-&lt;br /&gt;
| 0xC0&lt;br /&gt;
| 0x38&lt;br /&gt;
| Config block 0x50002.&lt;br /&gt;
|-&lt;br /&gt;
| 0xF8&lt;br /&gt;
| 0x20&lt;br /&gt;
| Config block 0x50004.&lt;br /&gt;
|-&lt;br /&gt;
| 0x118&lt;br /&gt;
| 0x134&lt;br /&gt;
| Config block 0x20000.&lt;br /&gt;
|-&lt;br /&gt;
| 0x24C&lt;br /&gt;
| 0x10&lt;br /&gt;
| Config block 0x40000.&lt;br /&gt;
|-&lt;br /&gt;
| 0x25C&lt;br /&gt;
| 0x1C&lt;br /&gt;
| Config block 0x40001.&lt;br /&gt;
|-&lt;br /&gt;
| 0x278&lt;br /&gt;
| 0x4&lt;br /&gt;
| Cleared to zero.&lt;br /&gt;
|-&lt;br /&gt;
| 0x27C&lt;br /&gt;
| 0x4&lt;br /&gt;
| Cleared to zero.&lt;br /&gt;
|-&lt;br /&gt;
| 0x280&lt;br /&gt;
| 0x8&lt;br /&gt;
| Config block 0x30001.&lt;br /&gt;
|-&lt;br /&gt;
| 0x288&lt;br /&gt;
| 0x2&lt;br /&gt;
| CRC16 over the above fields from offset 0x0, size 0x288. If not valid, LGY FIRM uses dummy data from .(ro)data.&lt;br /&gt;
|-&lt;br /&gt;
| 0x28A&lt;br /&gt;
| 0x2&lt;br /&gt;
| If non-zero, the size (below) is hardcoded (currently) to value 0x288, otherwise the size field below is used.&lt;br /&gt;
|-&lt;br /&gt;
| 0x28C&lt;br /&gt;
| 0x4&lt;br /&gt;
| Value 0x288 (size used for verifying the CRC16).&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
&amp;quot;Cleared to zero&amp;quot; fields above are not read at all by LGY FIRM.&lt;/div&gt;</summary>
		<author><name>Motezazer</name></author>
	</entry>
	<entry>
		<id>https://www.3dbrew.org/w/index.php?title=Title_list&amp;diff=19585</id>
		<title>Title list</title>
		<link rel="alternate" type="text/html" href="https://www.3dbrew.org/w/index.php?title=Title_list&amp;diff=19585"/>
		<updated>2017-02-11T15:45:30Z</updated>

		<summary type="html">&lt;p&gt;Motezazer: 11.2 and 11.3&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;NOTE: This Title list is a condensed version, only the System Titles lists are full lists. For a full list of titles on Nintendo&#039;s CDN, see [http://mtheall.com/~mtheall/tmdlist.php here]. The reports/title-lists from [https://yls8.mtheall.com/ninupdates/reports.php here] are automatically obtained from the system update SOAP.&lt;br /&gt;
&lt;br /&gt;
== CTR System Titles ==&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot; border=&amp;quot;1&amp;quot;&lt;br /&gt;
|-&lt;br /&gt;
!  System Category&lt;br /&gt;
!  Bit Mask(s)&lt;br /&gt;
!  Category Bit Mask&lt;br /&gt;
|-&lt;br /&gt;
|  Application (SYSTEM_APPLICATION)&lt;br /&gt;
|  Normal&amp;lt;nowiki&amp;gt;|&amp;lt;/nowiki&amp;gt;System&lt;br /&gt;
|  0x0010&lt;br /&gt;
|-&lt;br /&gt;
|  System Data Archives (SYSTEM_CONTENT)&lt;br /&gt;
|  Contents&amp;lt;nowiki&amp;gt;|&amp;lt;/nowiki&amp;gt;CannotExecution&amp;lt;nowiki&amp;gt;|&amp;lt;/nowiki&amp;gt;System&lt;br /&gt;
|  0x001B&lt;br /&gt;
|-&lt;br /&gt;
|  Shared Data Archives (SHARED_CONTENT)&lt;br /&gt;
|  Contents&amp;lt;nowiki&amp;gt;|&amp;lt;/nowiki&amp;gt;CannotExecution&amp;lt;nowiki&amp;gt;|&amp;lt;/nowiki&amp;gt;System&amp;lt;nowiki&amp;gt;|&amp;lt;/nowiki&amp;gt;NotRequireRightForMount&lt;br /&gt;
|  0x009B&lt;br /&gt;
|-&lt;br /&gt;
|  System Data Archives (AUTO_UPDATE_CONTENT)&lt;br /&gt;
|  Contents&amp;lt;nowiki&amp;gt;|&amp;lt;/nowiki&amp;gt;CannotExecution&amp;lt;nowiki&amp;gt;|&amp;lt;/nowiki&amp;gt;System&amp;lt;nowiki&amp;gt;|&amp;lt;/nowiki&amp;gt;NotRequireUserApproval&amp;lt;nowiki&amp;gt;|&amp;lt;/nowiki&amp;gt;NotRequireRightForMount&lt;br /&gt;
|  0x00DB&lt;br /&gt;
|-&lt;br /&gt;
|  Applet (APPLET)&lt;br /&gt;
|  Normal&amp;lt;nowiki&amp;gt;|&amp;lt;/nowiki&amp;gt;System&amp;lt;nowiki&amp;gt;|&amp;lt;/nowiki&amp;gt;RequireBatchUpdate&lt;br /&gt;
|  0x0030&lt;br /&gt;
|-&lt;br /&gt;
|  Module (BASE)&lt;br /&gt;
|  Normal&amp;lt;nowiki&amp;gt;|&amp;lt;/nowiki&amp;gt;System&amp;lt;nowiki&amp;gt;|&amp;lt;/nowiki&amp;gt;RequireBatchUpdate&amp;lt;nowiki&amp;gt;|&amp;lt;/nowiki&amp;gt;CanSkipConvertJumpId&lt;br /&gt;
|  0x0130&lt;br /&gt;
|-&lt;br /&gt;
|  Firmware (FIRMWARE)&lt;br /&gt;
|  Normal&amp;lt;nowiki&amp;gt;|&amp;lt;/nowiki&amp;gt;CannotExecution&amp;lt;nowiki&amp;gt;|&amp;lt;/nowiki&amp;gt;System&amp;lt;nowiki&amp;gt;|&amp;lt;/nowiki&amp;gt;RequireBatchUpdate&amp;lt;nowiki&amp;gt;|&amp;lt;/nowiki&amp;gt;CanSkipConvertJumpId&lt;br /&gt;
|  0x0138&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
=== 00040010 - System Applications ===&lt;br /&gt;
The versions for CHN, KOR, and TWN are separate from the other regions.&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot; border=&amp;quot;1&amp;quot;&lt;br /&gt;
|-&lt;br /&gt;
!  JPN TIDLow&lt;br /&gt;
!  USA TIDLow&lt;br /&gt;
!  EUR TIDLow&lt;br /&gt;
!  CHN TIDLow&lt;br /&gt;
!  KOR TIDLow&lt;br /&gt;
!  TWN TIDLow&lt;br /&gt;
!  [[Product code]]&lt;br /&gt;
!  Description&lt;br /&gt;
!  JPN Versions&lt;br /&gt;
!  EUR Versions&lt;br /&gt;
!  USA Versions&lt;br /&gt;
!  CHN Versions&lt;br /&gt;
!  KOR Versions&lt;br /&gt;
!  TWN Versions&lt;br /&gt;
!  Status&lt;br /&gt;
|-&lt;br /&gt;
| 00020000&lt;br /&gt;
| 00021000&lt;br /&gt;
| 00022000&lt;br /&gt;
| 00026000&lt;br /&gt;
| 00027000&lt;br /&gt;
| 00028000&lt;br /&gt;
| CTR-N-HAS?&lt;br /&gt;
| [[System Settings]] (mset)&lt;br /&gt;
| [[1.0.0-0|v0]], [[2.0.0-2|v1027]], [[3.0.0-5|v2060]], [[4.0.0-7|v3074]], [[5.0.0-11|v4097]], [[6.0.0-11|v5127]], [[7.0.0-13|v6157]], [[7.2.0-17|v7173]], [[8.1.0-0_New3DS|v8198]]([[8.1.0-0_New3DS]]), [[9.0.0-20|v9224]], [[9.6.0-24|v10245]], [[10.6.0-31|v10256]]&lt;br /&gt;
| [[1.0.0-0|v0]], [[2.0.0-2|v1027]], [[3.0.0-5|v2061]], [[4.0.0-7|v3075]], [[5.0.0-11|v4097]], [[6.0.0-11|v5127]], [[7.0.0-13|v6157]], [[7.2.0-17|v7174]], [[9.0.0-20|v8202]], [[9.6.0-24|v9220]]&lt;br /&gt;
| [[1.0.0-0|v0]], [[2.0.0-2|v1027]], [[3.0.0-5|v2062]], [[4.0.0-7|v3078]], [[5.0.0-11|v4098]], [[6.0.0-11|v5128]], [[7.0.0-13|v6157]], [[7.2.0-17|v7174]], [[9.0.0-20|v8203]], [[9.6.0-24|v9221]]&lt;br /&gt;
| [[4.0.0-7|v8]], [[4.4.0-10|v1024]](CHN-only sysupdate for just mset), [[5.0.0-11|v2049]], [[7.0.0-13|v3075]]&lt;br /&gt;
| [[4.0.0-7|v1026]], [[5.0.0-11|v2049]], [[7.0.0-13|v4098]]&lt;br /&gt;
| [[4.1.0-8|v8]], [[4.2.0-9|v1024]], [[5.0.0-11|v2050]], [[7.0.0-13|v3074]]&lt;br /&gt;
| Active&lt;br /&gt;
|-&lt;br /&gt;
| 00020100&lt;br /&gt;
| 00021100&lt;br /&gt;
| 00022100&lt;br /&gt;
| 00026100&lt;br /&gt;
| 00027100&lt;br /&gt;
| 00028100&lt;br /&gt;
| CTR-N-HDL?&lt;br /&gt;
| [[Download Play]] (dlplay)&lt;br /&gt;
| [[1.0.0-0|v0]], [[2.1.0-4|v1026]], [[4.0.0-7|v2051]], [[9.0.0-20|v3072]](Also for [[8.1.0-0_New3DS]])&lt;br /&gt;
| [[1.0.0-0|v0]], [[2.1.0-4|v1026]], [[4.0.0-7|v2051]], [[9.0.0-20|v3073]]&lt;br /&gt;
| [[1.0.0-0|v0]], [[2.1.0-4|v1026]], [[4.0.0-7|v2051]], [[9.0.0-20|v3073]]&lt;br /&gt;
| [[4.0.0-7|v4]]&lt;br /&gt;
| [[4.0.0-7|v1027]]&lt;br /&gt;
| [[4.1.0-8|v4]]&lt;br /&gt;
| Active&lt;br /&gt;
|-&lt;br /&gt;
| 00020200&lt;br /&gt;
| 00021200&lt;br /&gt;
| 00022200&lt;br /&gt;
| 00026200&lt;br /&gt;
| 00027200&lt;br /&gt;
| 00028200&lt;br /&gt;
| CTR-N-HMK?&lt;br /&gt;
| [[Activity Log]]&lt;br /&gt;
| [[1.0.0-0|v0]], [[2.0.0-2|v1026]], [[3.0.0-5|v2051]], [[10.6.0-31|v2080]]&lt;br /&gt;
| [[1.0.0-0|v0]], [[2.0.0-2|v1026]], [[3.0.0-5|v2054]], [[7.0.0-13|v2064]]&lt;br /&gt;
| Same as EUR&lt;br /&gt;
| [[4.0.0-7|v3]]&lt;br /&gt;
| [[4.0.0-7|v2]], [[7.0.0-13|v16]]&lt;br /&gt;
| [[4.1.0-8|v2]]&lt;br /&gt;
| Active&lt;br /&gt;
|-&lt;br /&gt;
| 00020300&lt;br /&gt;
| 00021300&lt;br /&gt;
| 00022300&lt;br /&gt;
| 00026300&lt;br /&gt;
| 00027300&lt;br /&gt;
| 00028300&lt;br /&gt;
| ?&lt;br /&gt;
| [[Health and Safety Information]] (safe)&lt;br /&gt;
| [[1.0.0-0|v0]], [[4.0.0-7|v1024]], [[6.0.0-11|v2050]]&lt;br /&gt;
| [[1.0.0-0|v0]], [[3.0.0-5|v1024]], [[4.0.0-7|v2050]], [[6.0.0-11|v3077]]&lt;br /&gt;
| [[1.0.0-0|v0]], [[4.0.0-7|v1026]], [[6.1.0-12U|v2051]]&lt;br /&gt;
| [[4.0.0-7|v5]]&lt;br /&gt;
| [[4.0.0-7|v2]]&lt;br /&gt;
| [[4.1.0-8|v5]]&lt;br /&gt;
| Active&lt;br /&gt;
|-&lt;br /&gt;
| 20020300&lt;br /&gt;
| 20021300&lt;br /&gt;
| 20022300&lt;br /&gt;
| N/A&lt;br /&gt;
| 20027300&lt;br /&gt;
| N/A&lt;br /&gt;
| CTR-N-HAC?&lt;br /&gt;
| [[New_3DS]] [[Health and Safety Information]]&lt;br /&gt;
| [[8.1.0-0_New3DS|v2]], [[9.3.0-21|v17]]&lt;br /&gt;
| [[8.1.0-0_New3DS|v1]]&lt;br /&gt;
| Same as EUR.&lt;br /&gt;
| N/A&lt;br /&gt;
| [[9.6.0-24|v2]]&lt;br /&gt;
| N/A&lt;br /&gt;
| Active&lt;br /&gt;
|-&lt;br /&gt;
| 00020400&lt;br /&gt;
| 00021400&lt;br /&gt;
| 00022400&lt;br /&gt;
| 00026400&lt;br /&gt;
| 00027400&lt;br /&gt;
| 00028400&lt;br /&gt;
| CTR-N-HEP?&lt;br /&gt;
| [[Nintendo 3DS Camera]] (CtrApp)&lt;br /&gt;
| [[1.0.0-0|v0]], [[2.1.0-4|v16]], [[3.0.0-5|v1038]], [[4.0.0-7|v2048]], [[6.0.0-11|v3073]], [[9.0.0-20|v4097]](Also for [[8.1.0-0_New3DS]]), [[10.6.0-31|v4112]]&lt;br /&gt;
| [[1.0.0-0|v0]], [[2.1.0-4|v16]], [[3.0.0-5|v1039]], [[4.0.0-7|v2048]], [[6.0.0-11|v3073]], [[7.0.0-13|v3088]], [[9.0.0-20|v4097]]&lt;br /&gt;
| [[1.0.0-0|v0]], [[2.1.0-4|v16]], [[3.0.0-5|v1039]], [[4.0.0-7|v2048]], [[6.1.0-12U|v3074]], [[7.0.0-13|v3088]], [[9.0.0-20|v4097]]&lt;br /&gt;
| [[4.0.0-7|v3]]&lt;br /&gt;
| [[4.0.0-7|v2]], [[7.0.0-13|v1040]]&lt;br /&gt;
| [[4.1.0-8|v3]]&lt;br /&gt;
| Active&lt;br /&gt;
|-&lt;br /&gt;
| 00020500&lt;br /&gt;
| 00021500&lt;br /&gt;
| 00022500&lt;br /&gt;
| 00026500&lt;br /&gt;
| 00027500&lt;br /&gt;
| 00028500&lt;br /&gt;
| CTR-N-HES?&lt;br /&gt;
| [[Nintendo 3DS Sound]] (CtrApp)&lt;br /&gt;
| [[1.0.0-0|v0]], [[2.1.0-4|v1027]], [[3.0.0-5|v2049]], [[4.0.0-7|v3072]], [[7.0.0-13|v3089]], [[10.6.0-31|3104]]&lt;br /&gt;
| [[1.0.0-0|v0]], [[2.1.0-4|v1027]], [[3.0.0-5|v2049]], [[4.0.0-7|v3072]], [[7.0.0-13|v3088]]&lt;br /&gt;
| [[1.0.0-0|v0]], [[2.1.0-4|v1027]], [[3.0.0-5|v2049]], [[4.0.0-7|v3072]], [[7.0.0-13|v3088]]&lt;br /&gt;
| [[4.0.0-7|v2]]&lt;br /&gt;
| [[4.0.0-7|v2]], [[7.0.0-13|v16]]&lt;br /&gt;
| [[4.1.0-8|v3]]&lt;br /&gt;
| Active&lt;br /&gt;
|-&lt;br /&gt;
| 00020700&lt;br /&gt;
| 00021700&lt;br /&gt;
| 00022700&lt;br /&gt;
| 00026700&lt;br /&gt;
| 00027700&lt;br /&gt;
| 00028700&lt;br /&gt;
| CTR-N-HED?&lt;br /&gt;
| [[Mii Maker]] (EDIT)&lt;br /&gt;
| [[1.0.0-0|v0]], [[2.0.0-2|v1026]], [[7.0.0-13|v2055]], [[10.6.0-31|v2064]]&lt;br /&gt;
| Same as JPN&lt;br /&gt;
| Same as JPN&lt;br /&gt;
| [[4.0.0-7|v1]]&lt;br /&gt;
| [[4.0.0-7|v1]], [[7.0.0-13|v16]]&lt;br /&gt;
| [[4.1.0-8|v2]]&lt;br /&gt;
| Active&lt;br /&gt;
|-&lt;br /&gt;
| 00020800&lt;br /&gt;
| 00021800&lt;br /&gt;
| 00022800&lt;br /&gt;
| 00026800&lt;br /&gt;
| 00027800&lt;br /&gt;
| 00028800&lt;br /&gt;
| CTR-N-HME?&lt;br /&gt;
| [[StreetPass Mii Plaza]] (MEET)&lt;br /&gt;
| [[1.0.0-0|v0]], v1027, [[2.1.0-4|v2048]], [[3.0.0-5|v3087]], [[3.0.0-6|v4096]], [[6.0.0-11|v5121]]&lt;br /&gt;
| [[1.0.0-0|v0]], v1027, [[2.1.0-4|v2048]], [[3.0.0-5|v3087]], [[3.0.0-6|v4096]], [[6.0.0-11|v5122]]&lt;br /&gt;
| [[1.0.0-0|v0]], v1027, [[2.1.0-4|v2048]], [[3.0.0-5|v3087]], [[3.0.0-6|v4096]], [[6.1.0-12U|v5124]], [[7.0.0-13|v5136]]&lt;br /&gt;
| [[4.0.0-7|v0]], [[4.4.0-10|v4096]]&lt;br /&gt;
| [[4.0.0-7|v1]], [[4.4.0-10|v4096]], [[7.0.0-13|v5120]]&lt;br /&gt;
| [[4.1.0-8|v1]], [[4.4.0-10|v4096]]&lt;br /&gt;
| Active&lt;br /&gt;
|-&lt;br /&gt;
| 00020900&lt;br /&gt;
| 00021900&lt;br /&gt;
| 00022900&lt;br /&gt;
| N/A&lt;br /&gt;
| 00027900&lt;br /&gt;
| 00028900&lt;br /&gt;
| CTR-N-HGR?&lt;br /&gt;
| [[eShop]] (tiger)&lt;br /&gt;
| [[2.0.0-2|v4]], [[2.1.0-3|v1026]], [[3.0.0-5|v2057]], [[4.0.0-7|v3081]], [[4.1.0-8|v4096]], [[4.2.0-9|v5123]], [[4.3.0-10|v6146]], [[5.0.0-11|v7169]], [[7.0.0-13|v8206]], [[7.1.0-14|v9231]], [[7.2.0-17|v10245]], [[8.0.0-18|v11265]], [[8.1.0-19|v12288]], [[9.0.0-20|v13320]], [[9.3.0-21|v15366]], [[9.5.0-22|v16384]], [[9.6.0-24|v17421]], [[9.7.0-25|v18432]], [[10.0.0-27|v19465]], [[10.4.0-29|v20483]], [[10.7.0-32|v21504]], [[11.3.0-36|v23552]]&lt;br /&gt;
| [[2.0.0-2|v4]], [[2.1.0-3|v1026]], [[3.0.0-5|v2058]], [[4.0.0-7|v3081]], [[4.1.0-8|v4096]], [[4.2.0-9|v5123]], [[4.3.0-10|v6146]], [[5.0.0-11|v7171]], [[7.0.0-13|v8206]], [[7.1.0-14|v9231]], [[7.2.0-17|v10245]], [[8.0.0-18|v11265]], [[8.1.0-19|v12288]], [[9.0.0-20|v13320]], [[9.3.0-21|v15366]], [[9.5.0-22|v16384]], [[9.6.0-24|v17421]], [[9.7.0-25|v18432]], [[10.0.0-27|v19465]], [[10.4.0-29|v20482]], [[10.7.0-32|v21505]], [[11.2.0-35|v22528]], [[11.3.0-36|v23552]]&lt;br /&gt;
| [[2.0.0-2|v4]], [[2.1.0-3|v1026]], [[3.0.0-5|v2058]], [[4.0.0-7|v3081]], [[4.1.0-8|v4096]], [[4.2.0-9|v5123]], [[4.3.0-10|v6146]], [[5.0.0-11|v7170]], [[7.0.0-13|v8206]], [[7.1.0-14|v9231]], [[7.2.0-17|v10246]], [[8.0.0-18|v11265]], [[8.1.0-19|v12288]], [[9.0.0-20|v13321]], [[9.3.0-21|v15366]], [[9.5.0-22|v16384]], [[9.6.0-24|v17422]], [[9.7.0-25|v18432]], [[10.0.0-27|v19465]], [[10.4.0-29|v20482]], [[10.7.0-32|v21506]], [[11.3.0-36|v23552]]&lt;br /&gt;
| N/A&lt;br /&gt;
| [[4.0.0-7|v3082]], [[4.1.0-8|v4096]], [[4.2.0-9|v5123]], [[4.3.0-10|v6146]], [[5.0.0-11|v7169]], [[7.0.0-13|v8205]], [[7.1.0-14|v9231]], [[8.1.0-19|v12288]], [[9.0.0-20|v13320]], [[9.3.0-21|v15366]], [[9.5.0-22|v16384]], [[9.6.0-24|v17420]], [[9.7.0-25|v18432]], [[10.0.0-27|v19465]], [[10.4.0-29|v20482]]&lt;br /&gt;
| [[4.1.0-8|v4096]], [[4.2.0-9|v5123]], [[4.3.0-10|v6146]], [[5.0.0-11|v7170]], [[7.0.0-13|v8205]], [[7.1.0-14|v9231]], [[8.1.0-19|v12288]], [[9.3.0-21|v15366]], [[9.5.0-22|v16384]], [[9.6.0-24|v17421]], [[9.7.0-25|v18432]], [[10.0.0-27|v19465]]&lt;br /&gt;
| Active&lt;br /&gt;
|-&lt;br /&gt;
| 00020A00&lt;br /&gt;
| 00021A00&lt;br /&gt;
| 00022A00&lt;br /&gt;
| N/A&lt;br /&gt;
| 00027A00&lt;br /&gt;
| 00028A00&lt;br /&gt;
| CTR-N-HCB?&lt;br /&gt;
| [[System Transfer]] (CARDBOARD)&lt;br /&gt;
| [[2.0.0-2|v4]], [[3.0.0-5|v1035]], [[4.0.0-7|v2050]], [[5.0.0-11|v3074]], [[7.0.0-13|v4109]], [[9.0.0-20|v5130]], [[9.6.0-24|v6154]]&lt;br /&gt;
| [[2.0.0-2|v4]], [[3.0.0-5|v1035]], [[4.0.0-7|v2050]], [[5.0.0-11|v3073]], [[7.0.0-13|v4109]], [[9.0.0-20|v5131]], [[9.6.0-24|v6155]]&lt;br /&gt;
| [[2.0.0-2|v4]], [[3.0.0-5|v1035]], [[4.0.0-7|v2051]], [[5.0.0-11|v3073]], [[7.0.0-13|v4109]], [[9.0.0-20|v5131]], [[9.6.0-24|v6156]]&lt;br /&gt;
| N/A&lt;br /&gt;
| [[4.0.0-7|v2]], [[5.0.0-11|v1025]], [[7.0.0-13|v2061]], [[9.0.0-20|v3082]]&lt;br /&gt;
| [[4.1.0-8|v2]], [[5.0.0-11|v1025]], [[7.0.0-13|v2061]]&lt;br /&gt;
| Active&lt;br /&gt;
|-&lt;br /&gt;
| 00020B00&lt;br /&gt;
| 00021B00&lt;br /&gt;
| 00022B00&lt;br /&gt;
| N/A&lt;br /&gt;
| N/A&lt;br /&gt;
| N/A&lt;br /&gt;
| CTR-N-HMA?&lt;br /&gt;
| [[Nintendo Zone]] (&amp;quot;Nintendo&amp;quot;)&lt;br /&gt;
| [[1.0.0-0|v0]], [[3.0.0-5|v1034]]&lt;br /&gt;
| Same as JPN&lt;br /&gt;
| Same as JPN&lt;br /&gt;
| N/A&lt;br /&gt;
| N/A&lt;br /&gt;
| N/A&lt;br /&gt;
| Active&lt;br /&gt;
|-&lt;br /&gt;
| 00020D00&lt;br /&gt;
| 00021D00&lt;br /&gt;
| 00022D00&lt;br /&gt;
| 00026D00&lt;br /&gt;
| 00027D00&lt;br /&gt;
| 00028D00&lt;br /&gt;
| CTR-N-HCH?&lt;br /&gt;
| [[Face Raiders]]&lt;br /&gt;
| [[1.0.0-0|v0]], [[2.1.0-4|v1028]]&lt;br /&gt;
| [[1.0.0-0|v0]], [[2.1.0-4|v1028]], [[7.0.0-13|v1040]]&lt;br /&gt;
| Same as EUR&lt;br /&gt;
| [[4.0.0-7|v0]]&lt;br /&gt;
| [[4.0.0-7|v0]]&lt;br /&gt;
| [[4.1.0-8|v2]]&lt;br /&gt;
| Active&lt;br /&gt;
|-&lt;br /&gt;
| 20020D00&lt;br /&gt;
| 20021D00&lt;br /&gt;
| 20022D00&lt;br /&gt;
| N/A&lt;br /&gt;
| 20027D00&lt;br /&gt;
| N/A&lt;br /&gt;
| ?&lt;br /&gt;
| [[New_3DS]] [[Face Raiders]]&lt;br /&gt;
| [[8.1.0-0_New3DS|v2050]]&lt;br /&gt;
| [[8.1.0-0_New3DS|v2049]]&lt;br /&gt;
| Same as EUR.&lt;br /&gt;
| N/A&lt;br /&gt;
| [[9.6.0-24|v2049]]&lt;br /&gt;
| N/A&lt;br /&gt;
| Active&lt;br /&gt;
|-&lt;br /&gt;
| 00020E00&lt;br /&gt;
| 00021E00&lt;br /&gt;
| 00022E00&lt;br /&gt;
| 00026E00&lt;br /&gt;
| 00027E00&lt;br /&gt;
| 00028E00&lt;br /&gt;
| CTR-N-HAR?&lt;br /&gt;
| [[AR Games]] (AR_ACT)&lt;br /&gt;
| [[1.0.0-0|v0]], [[2.1.0-4|v1026]]&lt;br /&gt;
| [[1.0.0-0|v0]], [[2.1.0-4|v1026]], [[7.0.0-13|v1040]]&lt;br /&gt;
| [[1.0.0-0|v0]], [[2.1.0-4|v1027]], [[7.0.0-13|v1040]]&lt;br /&gt;
| [[4.0.0-7|v0]]&lt;br /&gt;
| [[4.0.0-7|v0]], [[7.0.0-13|v16]]&lt;br /&gt;
| [[4.1.0-8|v1]]&lt;br /&gt;
| Active&lt;br /&gt;
|-&lt;br /&gt;
| 00020F00&lt;br /&gt;
| 00021F00&lt;br /&gt;
| 00022F00&lt;br /&gt;
| 00026F00&lt;br /&gt;
| 00027F00&lt;br /&gt;
| 00028F00&lt;br /&gt;
| CTR-N-HSH?&lt;br /&gt;
| SAFE_MODE [[System Settings#System Updater|System Updater]] (mset)&lt;br /&gt;
| [[1.0.0-0|v0]], [[3.0.0-5|v1024]], [[6.0.0-11|v2049]]&lt;br /&gt;
| [[1.0.0-0|v0]], [[3.0.0-5|v1024]], [[6.0.0-11|v2050]]&lt;br /&gt;
| Same as JPN&lt;br /&gt;
| [[4.0.0-7|v1]], [[6.0.0-11|v1026]]&lt;br /&gt;
| [[4.0.0-7|v1]]&lt;br /&gt;
| [[4.1.0-8|v1]]&lt;br /&gt;
| Active&lt;br /&gt;
|-&lt;br /&gt;
| 00023000&lt;br /&gt;
| 00024000&lt;br /&gt;
| 00025000&lt;br /&gt;
| N/A&lt;br /&gt;
| N/A&lt;br /&gt;
| N/A&lt;br /&gt;
| (Variable?)&lt;br /&gt;
| Promotional video&lt;br /&gt;
| [[1.1.0-1|v2]], [[2.0.0-2|v2048]]&lt;br /&gt;
| [[1.1.0-1|v&amp;lt;unknown&amp;gt;]], [[2.0.0-2|v2048]]&lt;br /&gt;
| [[1.1.0-1|v0]], [[2.0.0-2|v2048]]&lt;br /&gt;
| N/A&lt;br /&gt;
| N/A&lt;br /&gt;
| N/A&lt;br /&gt;
| Stubbed&lt;br /&gt;
|-&lt;br /&gt;
| 0002BF00&lt;br /&gt;
| 0002C000&lt;br /&gt;
| 0002C100&lt;br /&gt;
| N/A&lt;br /&gt;
| N/A&lt;br /&gt;
| N/A&lt;br /&gt;
| CTR-N-HAF?&lt;br /&gt;
| Nintendo Network ID Settings (act)&lt;br /&gt;
| [[7.0.0-13|v14]], [[7.2.0-17|v1029]], [[9.0.0-20|v2051]], [[9.3.0-21|v3072]]&lt;br /&gt;
| Same as JPN&lt;br /&gt;
| Same as JPN&lt;br /&gt;
| N/A&lt;br /&gt;
| N/A&lt;br /&gt;
| N/A&lt;br /&gt;
| Active&lt;br /&gt;
|-&lt;br /&gt;
| 20023100&lt;br /&gt;
| 20024100&lt;br /&gt;
| 20025100&lt;br /&gt;
| N/A&lt;br /&gt;
| N/A&lt;br /&gt;
| N/A&lt;br /&gt;
| CTR-N-HAJ?&lt;br /&gt;
| [[microSD Management]] (&#039;mcopy&#039;) ([[New_3DS]]-only)&lt;br /&gt;
| [[8.1.0-0_New3DS|v8]], [[9.0.0-20|v1024]]&lt;br /&gt;
| [[8.1.0-0_New3DS|v4]]&lt;br /&gt;
| [[8.1.0-0_New3DS|v5]]&lt;br /&gt;
| N/A&lt;br /&gt;
| N/A&lt;br /&gt;
| N/A&lt;br /&gt;
| Available&lt;br /&gt;
|-&lt;br /&gt;
| 2002C800&lt;br /&gt;
| 2002CF00&lt;br /&gt;
| 2002D000&lt;br /&gt;
| N/A&lt;br /&gt;
| 2002D700&lt;br /&gt;
| N/A&lt;br /&gt;
| CTR-P-CTAP&lt;br /&gt;
| [[New_3DS]]-only, currently stubbed. &amp;quot;HOME menu/menu&amp;quot;.&lt;br /&gt;
| [[8.1.0-0_New3DS|v2]], [[9.0.0-20|v18]], [[9.3.0-21|v34]], [[9.6.0-24|v50]]&lt;br /&gt;
| [[8.1.0-0_New3DS|v1]], [[9.3.0-21|v17]], [[9.6.0-24|v34]]&lt;br /&gt;
| [[8.1.0-0_New3DS|v1]], [[9.3.0-21|v18]], [[9.6.0-24|v33]]&lt;br /&gt;
| N/A&lt;br /&gt;
| [[9.6.0-24|v2]]&lt;br /&gt;
| N/A&lt;br /&gt;
| Stubbed&lt;br /&gt;
|-&lt;br /&gt;
| 2002C900&lt;br /&gt;
| 2002D100&lt;br /&gt;
| 2002D200&lt;br /&gt;
| N/A&lt;br /&gt;
| 2002D800&lt;br /&gt;
| N/A&lt;br /&gt;
| CTR-P-CTAP&lt;br /&gt;
| [[New_3DS]]-only, currently stubbed. &amp;quot;Friends list/friend&amp;quot;.&lt;br /&gt;
| [[8.1.0-0_New3DS|v1]]&lt;br /&gt;
| Same as JPN.&lt;br /&gt;
| [[8.1.0-0_New3DS|v0]], [[9.3.0-21|v16]]&lt;br /&gt;
| N/A&lt;br /&gt;
| [[9.6.0-24|v2]]&lt;br /&gt;
| N/A&lt;br /&gt;
| Stubbed&lt;br /&gt;
|-&lt;br /&gt;
| 2002CA00&lt;br /&gt;
| 2002D300&lt;br /&gt;
| 2002D400&lt;br /&gt;
| N/A&lt;br /&gt;
| 2002D900&lt;br /&gt;
| N/A&lt;br /&gt;
| CTR-P-CTAP&lt;br /&gt;
| [[New_3DS]]-only, currently stubbed. &amp;quot;Notifications/newslist&amp;quot;.&lt;br /&gt;
| [[8.1.0-0_New3DS|v0]], v1([[Home_Menu|JPN-only]] Oct 2, 2014 &amp;quot;sysupdate&amp;quot;, actually uploaded on 09-29-14. Identical to v0, same TMDs besides title-versions)&lt;br /&gt;
| [[8.1.0-0_New3DS|v2]]&lt;br /&gt;
| [[8.1.0-0_New3DS|v0]]&lt;br /&gt;
| N/A&lt;br /&gt;
| [[9.6.0-24|v2]]&lt;br /&gt;
| N/A&lt;br /&gt;
| Stubbed&lt;br /&gt;
|-&lt;br /&gt;
| 2002CB00&lt;br /&gt;
| 2002D500&lt;br /&gt;
| 2002D600&lt;br /&gt;
| N/A&lt;br /&gt;
| 2002DA00&lt;br /&gt;
| N/A&lt;br /&gt;
| CTR-P-CTAP&lt;br /&gt;
| [[New_3DS]]-only, currently stubbed. &amp;quot;Game notes/cherry&amp;quot;.&lt;br /&gt;
| [[8.1.0-0_New3DS|v0]], [[9.0.0-20|v1]]&lt;br /&gt;
| [[8.1.0-0_New3DS|v2]]&lt;br /&gt;
| Same as EUR.&lt;br /&gt;
| N/A&lt;br /&gt;
| [[9.6.0-24|v1]]&lt;br /&gt;
| N/A&lt;br /&gt;
| Stubbed&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
The &amp;quot;act&amp;quot; application seems to use a web browser with webkit?&lt;br /&gt;
&lt;br /&gt;
Regardless of version, the ExeFS:/.code for mset is the same for USA/EUR/JPN. The [[4.0.0-7]] version of mset([[4.1.0-8]] for TWN) has the same ExeFS:/.code for all regions(JPN, USA, EUR, CHN, KOR, TWN). The [[5.0.0-11]] mset ExeFS:/.code is the same for all regions as well, except for CHN. The [[7.0.0-13]] mset ExeFS:/.code is unique for the following regions: CHN, KOR, and TWN.&lt;br /&gt;
&lt;br /&gt;
=== 0004001B - [[NCCH#CFA|System Data Archives]] ===&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot; border=&amp;quot;1&amp;quot;&lt;br /&gt;
|-&lt;br /&gt;
!  TitleID Low&lt;br /&gt;
!  Description&lt;br /&gt;
!  Versions&lt;br /&gt;
|-&lt;br /&gt;
| 00010002&lt;br /&gt;
| [[ClCertA]]&lt;br /&gt;
| [[1.0.0-0|v0]]&lt;br /&gt;
|-&lt;br /&gt;
| 00010702&lt;br /&gt;
| [[NS CFA]]&lt;br /&gt;
| [[3.0.0-5|v0]], [[6.0.0-11|v1028]], [[6.3.0-12|v2048]], [[7.0.0-13|v3073]], [[9.0.0-20|v4096]](also for [[8.1.0-0_New3DS]])&lt;br /&gt;
|-&lt;br /&gt;
| 00010802&lt;br /&gt;
| This CFA only contains a 1-byte &amp;quot;dummy.txt&amp;quot; in the RomFS, which contains &#039;0&#039;.&lt;br /&gt;
| [[6.3.0-12|v0]], [[9.5.0-23|v1024]], [[10.5.0-30|v2048]], [[11.0.0-33|v3072]]&lt;br /&gt;
|-&lt;br /&gt;
| 00018002&lt;br /&gt;
| Same contents as 00010802. Starting with [[7.1.0-15]], the &amp;quot;dummy.txt&amp;quot; file was removed from RomFS: this CFA RomFS now contains web-browser data(similar to 00018102) for NNID / networking, etc.&lt;br /&gt;
| [[7.0.0-13|v14]], [[7.1.0-15|v1025]], [[7.2.0-17|v2055]], [[9.0.0-20|v3078]], [[9.3.0-21|v4096]], [[9.6.0-24|v5120]]&lt;br /&gt;
|-&lt;br /&gt;
| 00018102&lt;br /&gt;
| This contains local web-browser data(html/js, gfx, etc) for the Miiverse Offline-mode.&lt;br /&gt;
| [[7.0.0-13|v11]], [[9.0.0-20|v1025]](also for [[8.1.0-0_New3DS]])&lt;br /&gt;
|-&lt;br /&gt;
| 00018202&lt;br /&gt;
| This contains the webkit/OSS [[CRO0|CROs]] used with the Miiverse applet and the &amp;quot;act&amp;quot; application.&lt;br /&gt;
| [[7.0.0-13|v7]], [[8.1.0-0_New3DS|v1026]]([[8.1.0-0_New3DS]]), [[9.0.0-20|v2050]]&lt;br /&gt;
|-&lt;br /&gt;
| 00019002&lt;br /&gt;
| [[Fangate_updater]]&lt;br /&gt;
| [[9.3.0-21|v2]], [[9.6.0-24|v1026]]&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
=== 00040030 - Applets===&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot; border=&amp;quot;1&amp;quot;&lt;br /&gt;
|-&lt;br /&gt;
!  JPN TitleIDLow&lt;br /&gt;
!  USA TitleIDLow&lt;br /&gt;
!  EUR TitleIDLow&lt;br /&gt;
!  CHN TitleIDLow&lt;br /&gt;
!  KOR TitleIDLow&lt;br /&gt;
!  TWN TitleIDLow&lt;br /&gt;
!  [[Product code]]&lt;br /&gt;
!  Description&lt;br /&gt;
!  JPN Versions&lt;br /&gt;
!  USA Versions&lt;br /&gt;
!  EUR Versions&lt;br /&gt;
|-&lt;br /&gt;
|colspan=6 align=center| 00008102&lt;br /&gt;
| CTR-P-CTAP&lt;br /&gt;
| [[NS#Alternate menu|Test Menu]] (Demo1)&lt;br /&gt;
|colspan=3 align=center| ..., v64, ..., v27648&lt;br /&gt;
|-&lt;br /&gt;
| 00008202&lt;br /&gt;
| 00008F02&lt;br /&gt;
| 00009802&lt;br /&gt;
| 0000A102&lt;br /&gt;
| 0000A902&lt;br /&gt;
| 0000B102&lt;br /&gt;
| CTR-P-HMM?&lt;br /&gt;
| [[Home Menu]] (menu)&lt;br /&gt;
| [[1.0.0-0|v0]], [[2.0.0-2|v1027]], [[2.1.0-3|v2049]], [[2.2.0-X|v3075]], [[3.0.0-5|v4111]], [[4.0.0-7|v5131]], [[4.2.0-9|v6146]], [[5.0.0-11|v7172]], [[6.0.0-11|v8198]], [[7.0.0-13|v9230]], [[8.1.0-0_New3DS|v10250]]([[8.1.0-0_New3DS]]), [[9.0.0-20|v13313]], [[9.1.0-20J|v14336]], [[9.2.0-20|v15360]], [[9.3.0-21|v16402]], [[9.4.0-21|v17408]], [[9.5.0-22|v18432]], [[9.6.0-24|v19476]], [[9.7.0-25|v20487]], [[9.8.0-25|v22528]], [[10.1.0-27|v23552]], [[10.2.0-28|v24576]], [[10.3.0-28|v25600]], [[10.4.0-29|v26626]], [[10.6.0-31|v27648]], [[11.1.0-34|v28672]], [[11.3.0-36|v29696]]&lt;br /&gt;
| [[1.0.0-0|v0]], [[2.0.0-2|v1027]], [[2.1.0-3|v2049]], [[2.2.0-X|v3075]], [[3.0.0-5|v4111]], [[4.0.0-7|v5131]], [[4.2.0-9|v6146]], [[5.0.0-11|v7172]], [[6.0.0-11|v8198]], [[7.0.0-13|v9230]], [[9.0.0-20|v11272]], [[9.2.0-20|v12288]], [[9.3.0-21|v13330]], [[9.4.0-21|v14336]], [[9.5.0-22|v15360]], [[9.6.0-24|v16404]], [[9.7.0-25|v17415]], [[9.8.0-25|v19456]], [[9.9.0-26|v20480]], [[10.1.0-27|v21504]], [[10.2.0-28|v22528]], [[10.3.0-28|v23552]], [[10.4.0-29|v24578]], [[10.6.0-31|v25600]], [[11.1.0-34|v26624]], [[11.3.0-36|v27648]]&lt;br /&gt;
| [[1.0.0-0|v0]], [[2.0.0-2|v1027]], [[2.1.0-3|v2049]], [[2.2.0-X|v3075]], [[3.0.0-5|v4111]], [[4.0.0-7|v5131]], [[4.2.0-9|v6146]], [[5.0.0-11|v7172]], [[6.0.0-11|v8198]], [[7.0.0-13|v9230]], [[9.0.0-20|v11272]], [[9.2.0-20|v12288]], [[9.3.0-21|v13330]], [[9.4.0-21|v14336]], [[9.5.0-22|v15360]], [[9.6.0-24|v16404]], [[9.7.0-25|v17415]], [[9.8.0-25|v19456]], [[10.1.0-27|v20480]], [[10.2.0-28|v21504]], [[10.3.0-28|v22528]], [[10.4.0-29|v23554]], [[10.6.0-31|v24576]], [[11.1.0-34|v25600]], [[11.3.0-36|v26624]]&lt;br /&gt;
|-&lt;br /&gt;
| 00008402&lt;br /&gt;
| 00009002&lt;br /&gt;
| 00009902&lt;br /&gt;
| 0000A202&lt;br /&gt;
| 0000AA02&lt;br /&gt;
| 0000B202&lt;br /&gt;
| CTR-N-HCS?&lt;br /&gt;
| Camera applet used by Home-menu (CtrApp)&lt;br /&gt;
|colspan=3| v0, v1036, [[9.0.0-20|v2049]](Also for [[8.1.0-0_New3DS]])&lt;br /&gt;
|-&lt;br /&gt;
| 00008502&lt;br /&gt;
| 00009102&lt;br /&gt;
| 00009A02&lt;br /&gt;
| ?&lt;br /&gt;
| ?&lt;br /&gt;
| ?&lt;br /&gt;
| ?&lt;br /&gt;
| Not available on CDN&lt;br /&gt;
| ?&lt;br /&gt;
| ?&lt;br /&gt;
| ?&lt;br /&gt;
|-&lt;br /&gt;
| 00008602&lt;br /&gt;
| 00009202&lt;br /&gt;
| 00009B02&lt;br /&gt;
| 0000A402&lt;br /&gt;
| 0000AC02&lt;br /&gt;
| 0000B402&lt;br /&gt;
| &lt;br /&gt;
| Instruction Manual, applet for displaying instruction manuals&lt;br /&gt;
|colspan=3| v0, v1026, v2048, v3072, [[5.0.0-11|v4097]], [[9.0.0-20|v5120]](Also for [[8.1.0-0_New3DS]])&lt;br /&gt;
|-&lt;br /&gt;
| 00008702&lt;br /&gt;
| 00009302&lt;br /&gt;
| 00009C02&lt;br /&gt;
| 0000A502&lt;br /&gt;
| 0000AD02&lt;br /&gt;
| 0000B502&lt;br /&gt;
| CTR-N-HGM?&lt;br /&gt;
| Game Notes (Cherry)&lt;br /&gt;
|colspan=3| v0, v1026, v2049, [[5.0.0-11|v3073]], [[9.0.0-20|v4096]](Also for [[8.1.0-0_New3DS]])&lt;br /&gt;
|-&lt;br /&gt;
| 00008802&lt;br /&gt;
| 00009402&lt;br /&gt;
| 00009D02&lt;br /&gt;
| 0000A602&lt;br /&gt;
| 0000AE02&lt;br /&gt;
| 0000B602&lt;br /&gt;
| &lt;br /&gt;
| [[Internet Browser]] (spider)&lt;br /&gt;
|colspan=3| [[2.0.0-2|v6]], [[2.1.0-4|v1024]], [[4.0.0-7|v2050]], [[5.0.0-11|v3074 (EUR)/v3075(USA,JAP)]], [[7.0.0-13|v3088]], [[7.1.0-16|v4096]], [[9.5.0-23|v5121]], [[9.9.0-26|v6149]], [[10.2.0-28|v7168]], [[10.6.0-31|v8192]], [[10.7.0-32|v9232]], [[11.1.0-34|v10240]]&lt;br /&gt;
|-&lt;br /&gt;
| 20008802&lt;br /&gt;
| 20009402&lt;br /&gt;
| 20009D02&lt;br /&gt;
| ?&lt;br /&gt;
| 2000AE02&lt;br /&gt;
| N/A&lt;br /&gt;
| CTR-N-HBR?&lt;br /&gt;
| [[New 3DS]] [[Internet Browser]] (SKATER)&lt;br /&gt;
|colspan=3| [[8.1.0-0_New3DS|v10]], [[9.3.0-21|v1027]], [[9.6.0-24|v2051]], [[9.9.0-26|v3077]], [[10.2.0-28|v4096]], [[10.4.0-29|v5121]], [[10.6.0-31|v6144]], [[10.7.0-32|v7184]], [[11.1.0-34|v8192]]&lt;br /&gt;
|-&lt;br /&gt;
|colspan=6| 00008A02&lt;br /&gt;
| &lt;br /&gt;
| Fatal error viewer ([[ErrDisp]])&lt;br /&gt;
|colspan=3| v0, v1025, [[2.2.0-X|v2048]], [[3.0.0-5|v3072]], [[4.0.0-7|v4096]], [[5.0.0-11|v5121]], [[8.0.0-18|v6144]], [[9.0.0-20|v7168]](Also for [[8.1.0-0_New3DS]])&lt;br /&gt;
|-&lt;br /&gt;
|colspan=6| 00008A03&lt;br /&gt;
| &lt;br /&gt;
| SAFE_MODE [[ErrDisp]]&lt;br /&gt;
|colspan=3| v0&lt;br /&gt;
|-&lt;br /&gt;
| 20008A03&lt;br /&gt;
| 20008A03&lt;br /&gt;
| 20008A03&lt;br /&gt;
| ?&lt;br /&gt;
| 20008A03&lt;br /&gt;
| N/A&lt;br /&gt;
| &lt;br /&gt;
| [[New_3DS]] SAFE_MODE [[ErrDisp]]&lt;br /&gt;
|colspan=3| [[8.1.0-0_New3DS|v7169]]&lt;br /&gt;
|-&lt;br /&gt;
| 00008D02&lt;br /&gt;
| 00009602&lt;br /&gt;
| 00009F02&lt;br /&gt;
| 0000A702&lt;br /&gt;
| 0000AF02&lt;br /&gt;
| 0000B702&lt;br /&gt;
| CTR-N-HFR?&lt;br /&gt;
| Friend List (friend)&lt;br /&gt;
|colspan=3| v0, v1026, [[2.2.0-X|v2051]], v3082, v4099, [[7.0.0-13|v5120]], [[9.0.0-20|v6144]](Also for [[8.1.0-0_New3DS]]) (EUR v6, v1024, v3082, v4099, [[7.0.0-13|v5120]], [[9.0.0-20|v6144]])&lt;br /&gt;
|-&lt;br /&gt;
| 00008E02&lt;br /&gt;
| 00009702&lt;br /&gt;
| 0000A002&lt;br /&gt;
| 0000A802&lt;br /&gt;
| 0000B002&lt;br /&gt;
| 0000B802&lt;br /&gt;
| CTR-N-HCR?&lt;br /&gt;
| Notifications (newslist)&lt;br /&gt;
|colspan=3| v0, v1029, v2054, v3075, [[9.0.0-20|v4097]] (EUR v6, v1024, v2054, v3075, [[9.0.0-20|v4097]]) (JPN: ..., [[8.1.0-0_New3DS|v4096]], [[9.0.0-20|v5121]])&lt;br /&gt;
|-&lt;br /&gt;
| 0000C002&lt;br /&gt;
| 0000C802&lt;br /&gt;
| 0000D002&lt;br /&gt;
| 0000D802&lt;br /&gt;
| 0000DE02&lt;br /&gt;
| 0000E402&lt;br /&gt;
| CTR-N-HKY?&lt;br /&gt;
| Software Keyboard (swkbd)&lt;br /&gt;
|colspan=3| v0, v1026, v2053, [[7.0.0-13|v3072]], [[9.0.0-20|v4096]](Also for [[8.1.0-0_New3DS]])&lt;br /&gt;
|-&lt;br /&gt;
| 0000C003&lt;br /&gt;
| 0000C803&lt;br /&gt;
| 0000D003&lt;br /&gt;
| 0000D803&lt;br /&gt;
| 0000DE03&lt;br /&gt;
| 0000E403&lt;br /&gt;
| &lt;br /&gt;
| SAFE_MODE Software Keyboard (swkbd)&lt;br /&gt;
|colspan=3| v0&lt;br /&gt;
|-&lt;br /&gt;
| 2000C003&lt;br /&gt;
| 2000C803&lt;br /&gt;
| 2000D003&lt;br /&gt;
| ?&lt;br /&gt;
| 2000DE03&lt;br /&gt;
| N/A&lt;br /&gt;
| &lt;br /&gt;
| [[New 3DS]] SAFE_MODE Software Keyboard (swkbd)&lt;br /&gt;
| [[8.1.0-0_New3DS|v1024]]&lt;br /&gt;
|colspan=2|[[9.0.0-20|v0]]&lt;br /&gt;
|-&lt;br /&gt;
| 0000C102&lt;br /&gt;
| 0000C902&lt;br /&gt;
| 0000D102&lt;br /&gt;
| 0000D902&lt;br /&gt;
| 0000DF02&lt;br /&gt;
| 0000E502&lt;br /&gt;
| &lt;br /&gt;
| Mii picker (appletEd)&lt;br /&gt;
|colspan=3| v0, v1026, [[9.0.0-20|v2048]](Also for [[8.1.0-0_New3DS]]), [[9.3.0-21|v3077]]&lt;br /&gt;
|-&lt;br /&gt;
| 0000C302&lt;br /&gt;
| 0000CB02&lt;br /&gt;
| 0000D302&lt;br /&gt;
| 0000DB02&lt;br /&gt;
| 0000E102&lt;br /&gt;
| 0000E702&lt;br /&gt;
| &lt;br /&gt;
| Picture picker (PNOTE_AP)&lt;br /&gt;
|colspan=3| v0, v1024, [[8.1.0-0_New3DS|v2049]]([[8.1.0-0_New3DS]]), [[9.0.0-20|v3075]], [[9.3.0-21|v4096]]&lt;br /&gt;
|-&lt;br /&gt;
| 0000C402&lt;br /&gt;
| 0000CC02&lt;br /&gt;
| 0000D402&lt;br /&gt;
| 0000DC02&lt;br /&gt;
| 0000E202&lt;br /&gt;
| 0000E802&lt;br /&gt;
| &lt;br /&gt;
| [[Nintendo 3DS Sound|Voice memo]] picker (SNOTE_AP)&lt;br /&gt;
|colspan=3| v0, v3, [[8.0.0-18|v1026]], [[9.0.0-20|v2048]](Also for [[8.1.0-0_New3DS]])&lt;br /&gt;
|-&lt;br /&gt;
|colspan=3| 0000C502&lt;br /&gt;
|colspan=3| 0000CF02&lt;br /&gt;
| &lt;br /&gt;
| Non-critical (online, etc) error display (error)&lt;br /&gt;
|colspan=3| v0, v1026, v2053, v3074, [[8.1.0-0_New3DS|v4096]]([[8.1.0-0_New3DS]]), [[9.0.0-20|v5128]], [[9.6.0-24|v6145]]&lt;br /&gt;
|-&lt;br /&gt;
|colspan=3| 0000C503&lt;br /&gt;
|colspan=3| 0000CF03&lt;br /&gt;
| &lt;br /&gt;
| SAFE_MODE error applet&lt;br /&gt;
|colspan=3| v0&lt;br /&gt;
|-&lt;br /&gt;
| 2000C503&lt;br /&gt;
| 2000C503&lt;br /&gt;
| 2000C503&lt;br /&gt;
| ?&lt;br /&gt;
| 2000CF03&lt;br /&gt;
| N/A&lt;br /&gt;
| &lt;br /&gt;
| [[New 3DS]] SAFE_MODE error applet&lt;br /&gt;
|colspan=3| [[8.1.0-0_New3DS|v1024]]&lt;br /&gt;
|-&lt;br /&gt;
|colspan=3| 0000CD02&lt;br /&gt;
|colspan=3| 0000D502&lt;br /&gt;
| &lt;br /&gt;
| [[Circle Pad Pro]] test/calibration applet (extrapad)&lt;br /&gt;
|colspan=3| v1, v1026, [[8.1.0-0_New3DS|v2048]]([[8.1.0-0_New3DS]]), [[9.0.0-20|v3073]]&lt;br /&gt;
|-&lt;br /&gt;
| 0000C602&lt;br /&gt;
| 0000CE02&lt;br /&gt;
| 0000D602&lt;br /&gt;
| N/A&lt;br /&gt;
| 0000E302&lt;br /&gt;
| 0000E902&lt;br /&gt;
| CTR-N-HAA?&lt;br /&gt;
| eShop applet, used by applications for accessing the eShop, for DLC/etc. Also used by the eShop application itself. (mint)&lt;br /&gt;
|colspan=3| v5, v1028, [[4.2.0-9|v2050]], [[5.0.0-11|v3072]], [[7.0.0-13|v4109]], [[7.2.0-17|v5125]](v5123 for JPN), [[8.0.0-18|v6145]], [[8.1.0-0_New3DS|v7168]]([[8.1.0-0_New3DS]]), [[9.0.0-20|v8200]], [[9.3.0-21|v9224]], [[9.6.0-24|v10247]], [[9.8.0-25|v11264]], [[10.0.0-27|v12293]], [[10.1.0-27|v13312]], [[10.3.0-28|v14337]], [[10.4.0-29|v15360]], [[10.7.0-32|v16384]], [[11.2.0-35|v17408]](EUR), [[11.3.0-36|v18432]]&lt;br /&gt;
|-&lt;br /&gt;
| 0000BC02&lt;br /&gt;
| 0000BD02&lt;br /&gt;
| 0000BE02&lt;br /&gt;
| ?&lt;br /&gt;
| ?&lt;br /&gt;
| ?&lt;br /&gt;
| CTR-N-HAE?&lt;br /&gt;
| Miiverse (olv)&lt;br /&gt;
|colspan=3| [[7.0.0-13|v14]], [[7.2.0-17|v1024]], [[9.0.0-20|v2048]](Also for [[8.1.0-0_New3DS]]), [[9.3.0-21|v3072]], [[9.6.0-24|v4096]]&lt;br /&gt;
|-&lt;br /&gt;
| 0000F602&lt;br /&gt;
| 0000F602&lt;br /&gt;
| 0000F602&lt;br /&gt;
| ?&lt;br /&gt;
| ?&lt;br /&gt;
| ?&lt;br /&gt;
| &lt;br /&gt;
| Likely the &amp;quot;system library&amp;quot; for Miiverse (memolib)&lt;br /&gt;
|colspan=3| [[7.0.0-13|v5]], [[8.1.0-0_New3DS|v1024]]([[8.1.0-0_New3DS]]), [[9.0.0-20|v2050]], [[9.3.0-21|v3072]]&lt;br /&gt;
|-&lt;br /&gt;
| 00008302&lt;br /&gt;
| 00008B02&lt;br /&gt;
| 0000BA02&lt;br /&gt;
| ?&lt;br /&gt;
| ?&lt;br /&gt;
| ?&lt;br /&gt;
| CTR-N-HAH?&lt;br /&gt;
| In-app Miiverse-posting applet (solv3)&lt;br /&gt;
|colspan=3| [[9.0.0-20|v6]]&lt;br /&gt;
|-&lt;br /&gt;
| 00009502&lt;br /&gt;
| 00009E02&lt;br /&gt;
| 0000B902&lt;br /&gt;
| ?&lt;br /&gt;
| 00008C02&lt;br /&gt;
| 0000BF02&lt;br /&gt;
| CTR-N-HA3?&lt;br /&gt;
| Cabinet ([[amiibo Settings]])&lt;br /&gt;
|colspan=3| [[9.3.0-21|v7]], (v1024 for TWN), [[9.6.0-24|v1031]]&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
Most of these processes are applets, see [[NS_and_APT_Services|here]] for details.&lt;br /&gt;
&lt;br /&gt;
All of the above processes use the &amp;quot;SYSTEM&amp;quot; [[SVC|memory-region]].&lt;br /&gt;
&lt;br /&gt;
The ExeFS for Home Menu is exactly the same for USA/EUR/JPN.&lt;br /&gt;
&lt;br /&gt;
The Miiverse applet seems to use a web browser with webkit.&lt;br /&gt;
&lt;br /&gt;
=== 0004009B - [[NCCH#CFA|System Data Archives]] (Shared Archives) ===&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot; border=&amp;quot;1&amp;quot;&lt;br /&gt;
|-&lt;br /&gt;
!  JPN TitleIDLow&lt;br /&gt;
!  USA TitleIDLow&lt;br /&gt;
!  EUR TitleIDLow&lt;br /&gt;
!  KOR TitleIDLow&lt;br /&gt;
!  Description&lt;br /&gt;
!  Versions&lt;br /&gt;
|-&lt;br /&gt;
| 00010202&lt;br /&gt;
| 00010202&lt;br /&gt;
| 00010202&lt;br /&gt;
| 00010202&lt;br /&gt;
| Probably Mii-related, contains &amp;quot;CFL_Res.dat&amp;quot; in the RomFS.&lt;br /&gt;
| v0&lt;br /&gt;
|-&lt;br /&gt;
| 00010302&lt;br /&gt;
| 00010302&lt;br /&gt;
| 00010302&lt;br /&gt;
|&lt;br /&gt;
| Only exists for dev-units.&lt;br /&gt;
| v0, v2052&lt;br /&gt;
|-&lt;br /&gt;
| 00010402&lt;br /&gt;
| 00010402&lt;br /&gt;
| 00010402&lt;br /&gt;
| 00010402&lt;br /&gt;
| Mounted as &amp;quot;area:&amp;quot;, contains Country and Region names&lt;br /&gt;
| v0, v1024, v2050, v3072, [[7.0.0-13|v4098]], [[9.6.0-24|v5122]]&lt;br /&gt;
|-&lt;br /&gt;
| 00010502&lt;br /&gt;
| 00010502&lt;br /&gt;
| 00010502&lt;br /&gt;
|&lt;br /&gt;
| Only exists for dev-units.&lt;br /&gt;
| v0, v1024, v2048&lt;br /&gt;
|-&lt;br /&gt;
| 00010602&lt;br /&gt;
| 00010602&lt;br /&gt;
| 00010602&lt;br /&gt;
| 00010602&lt;br /&gt;
| Non-Nintendo TLS Root-CA Certificates (RomFS contains files with filename &amp;quot;CACERT_PUBLIC_CA_&amp;lt;val&amp;gt;.der&amp;quot;, where &amp;lt;val&amp;gt; is 5..8)&lt;br /&gt;
| v2, [[10.5.0-30|v1024]]&lt;br /&gt;
|-&lt;br /&gt;
| &lt;br /&gt;
| &lt;br /&gt;
| 00011202&lt;br /&gt;
|&lt;br /&gt;
| &amp;quot;NL/NL&amp;quot; dictionary.&lt;br /&gt;
| v0&lt;br /&gt;
|-&lt;br /&gt;
| &lt;br /&gt;
| &lt;br /&gt;
| 00011302&lt;br /&gt;
|&lt;br /&gt;
| &amp;quot;EN/GB&amp;quot; dictionary.&lt;br /&gt;
| v0&lt;br /&gt;
|-&lt;br /&gt;
| &lt;br /&gt;
| 00011402&lt;br /&gt;
|&lt;br /&gt;
| &lt;br /&gt;
| &amp;quot;EN/US&amp;quot; dictionary.&lt;br /&gt;
| v0&lt;br /&gt;
|-&lt;br /&gt;
| &lt;br /&gt;
| &lt;br /&gt;
| 00011502&lt;br /&gt;
|&lt;br /&gt;
| &amp;quot;FR/FR/regular&amp;quot; dictionary.&lt;br /&gt;
| v0&lt;br /&gt;
|-&lt;br /&gt;
| &lt;br /&gt;
| 00011602&lt;br /&gt;
|&lt;br /&gt;
| &lt;br /&gt;
| &amp;quot;FR/CA/regular&amp;quot; dictionary.&lt;br /&gt;
| v0&lt;br /&gt;
|-&lt;br /&gt;
| &lt;br /&gt;
| &lt;br /&gt;
| 00011702&lt;br /&gt;
|&lt;br /&gt;
| &amp;quot;DE/regular&amp;quot; dictionary.&lt;br /&gt;
| v0&lt;br /&gt;
|-&lt;br /&gt;
| &lt;br /&gt;
| &lt;br /&gt;
| 00011802&lt;br /&gt;
|&lt;br /&gt;
| &amp;quot;IT/IT&amp;quot; dictionary.&lt;br /&gt;
| v0&lt;br /&gt;
|-&lt;br /&gt;
| 00011902&lt;br /&gt;
| &lt;br /&gt;
|&lt;br /&gt;
| &lt;br /&gt;
| &amp;quot;JA_small/32&amp;quot; dictionary.&lt;br /&gt;
| v0&lt;br /&gt;
|-&lt;br /&gt;
| &lt;br /&gt;
| &lt;br /&gt;
|&lt;br /&gt;
| 00011A02&lt;br /&gt;
| ?&lt;br /&gt;
| v1&lt;br /&gt;
|-&lt;br /&gt;
| &lt;br /&gt;
| &lt;br /&gt;
| 00011B02&lt;br /&gt;
|&lt;br /&gt;
| &amp;quot;PT/PT/regular&amp;quot; dictionary.&lt;br /&gt;
| v0&lt;br /&gt;
|-&lt;br /&gt;
| &lt;br /&gt;
| &lt;br /&gt;
| 00011C02&lt;br /&gt;
|&lt;br /&gt;
| &amp;quot;RU/regular&amp;quot; dictionary.&lt;br /&gt;
| v0&lt;br /&gt;
|-&lt;br /&gt;
| &lt;br /&gt;
| 00011D02&lt;br /&gt;
| 00011D02&lt;br /&gt;
|&lt;br /&gt;
| &amp;quot;ES/ES&amp;quot; dictionary.&lt;br /&gt;
| v0&lt;br /&gt;
|-&lt;br /&gt;
| &lt;br /&gt;
| 00011E02&lt;br /&gt;
|&lt;br /&gt;
| &lt;br /&gt;
| &amp;quot;PT/BR/regular&amp;quot; dictionary.&lt;br /&gt;
| v0&lt;br /&gt;
|-&lt;br /&gt;
| 00012202&lt;br /&gt;
| 00012302&lt;br /&gt;
| 00012102&lt;br /&gt;
| 00012502&lt;br /&gt;
| ?contains a lists with error strings&lt;br /&gt;
| v1026, v2053, v3073, [[4.2.0-9|v4096]], [[5.0.0-11|v5120]], [[7.0.0-13|v6149]], [[7.2.0-17|v7168]], [[8.0.0-18|v8192]], [[9.0.0-20|v9218]], [[9.3.0-21|v10242]], [[9.6.0-24|v11269]], [[10.0.0-27|v12289]], [[10.4.0-29|v13312]], [[10.7.0-32|v13313]] (JPN: [[11.1.0-34|v14336]]) (KOR: [[9.6.0-24|v6148]], [[10.0.0-27|v7169]], [[10.3.0-28|v8193]], [[10.4.0-29|v9216]], [[11.1.0-34|v10240]])&lt;br /&gt;
|-&lt;br /&gt;
| 00013202&lt;br /&gt;
| 00013302&lt;br /&gt;
| 00013102&lt;br /&gt;
| 00013502&lt;br /&gt;
| Mounted as &amp;quot;eula:&amp;quot;&lt;br /&gt;
| v0, v1024, v2049 USA: v1024, v2051, [[7.0.0-13|v3074]], [[7.2.0-17|v4100]](EUR-only), [[9.0.0-20|v4099]], [[9.9.0-26|v6144]], [[10.4.0-29|v7168]] (KOR: [[9.7.0-25|v1025]])&lt;br /&gt;
|-&lt;br /&gt;
| 00014002&lt;br /&gt;
| 00014002&lt;br /&gt;
| 00014002&lt;br /&gt;
| 00014002&lt;br /&gt;
| JPN/EUR/USA [[System Font]] (&amp;quot;font:&amp;quot;)&lt;br /&gt;
| v0&lt;br /&gt;
|-&lt;br /&gt;
| 00014102&lt;br /&gt;
| 00014102&lt;br /&gt;
| 00014102&lt;br /&gt;
| 00014102&lt;br /&gt;
| CHN [[System Font]] (&amp;quot;font:&amp;quot;)&lt;br /&gt;
| v0, v1024&lt;br /&gt;
|-&lt;br /&gt;
| 00014202&lt;br /&gt;
| 00014202&lt;br /&gt;
| 00014202&lt;br /&gt;
| 00014202&lt;br /&gt;
| KOR [[System Font]] (&amp;quot;font:&amp;quot;)&lt;br /&gt;
| v0, v1024&lt;br /&gt;
|-&lt;br /&gt;
| 00014302&lt;br /&gt;
| 00014302&lt;br /&gt;
| 00014302&lt;br /&gt;
| 00014302&lt;br /&gt;
| TWN [[System Font]] (&amp;quot;font:&amp;quot;)&lt;br /&gt;
| v0, v1024&lt;br /&gt;
|-&lt;br /&gt;
| 00015202&lt;br /&gt;
| 00015302&lt;br /&gt;
| 00015102&lt;br /&gt;
| 00015502&lt;br /&gt;
| Mounted as &amp;quot;rate:&amp;quot;&lt;br /&gt;
| v0 (EUR: v0, v1024) (KOR: v1024)&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
=== 000400DB - [[NCCH#CFA|System Data Archives]] ===&lt;br /&gt;
These [[NVer]] titleIDs can be found @ offset 0x320 in every [[CCI]].&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot; border=&amp;quot;1&amp;quot;&lt;br /&gt;
|-&lt;br /&gt;
!  EUR TitleIDLow&lt;br /&gt;
!  JPN TitleIDLow&lt;br /&gt;
!  USA TitleIDLow&lt;br /&gt;
!  CHN TitleIDLow&lt;br /&gt;
!  KOR TitleIDLow&lt;br /&gt;
!  TWN TitleIDLow&lt;br /&gt;
!  Description&lt;br /&gt;
!  USA/EUR/JPN Versions&lt;br /&gt;
!  CHN Versions&lt;br /&gt;
!  TWN Versions&lt;br /&gt;
!  KOR Versions&lt;br /&gt;
|-&lt;br /&gt;
| 00010302&lt;br /&gt;
| 00010302&lt;br /&gt;
| 00010302&lt;br /&gt;
| 00010302&lt;br /&gt;
| 00010302&lt;br /&gt;
| 00010302&lt;br /&gt;
| NGWord bad word list&lt;br /&gt;
| [[1.0.0-0|v0]], [[2.0.0-2|v1024]], [[3.0.0-5|v2052]], [[4.0.0-7|v3072]], [[4.3.0-10|v4096]], [[5.0.0-11|v5120]], [[9.0.0-20|v6144]], [[9.3.0-21|v7168]], [[9.6.0-24|v8192]], [[11.1.0-34|v9217]]&lt;br /&gt;
| Same as USA&lt;br /&gt;
| Same as USA&lt;br /&gt;
| Same as USA&lt;br /&gt;
|-&lt;br /&gt;
| 00010502&lt;br /&gt;
| 00010502&lt;br /&gt;
| 00010502&lt;br /&gt;
| 00010502&lt;br /&gt;
| 00010502&lt;br /&gt;
| 00010502&lt;br /&gt;
| [[Nintendo Zone]] hotspot list&lt;br /&gt;
| [[1.0.0-0|v0]], [[2.0.0-2|v1024]], [[3.0.0-5|v2048]], [[4.0.0-7|v3073]], [[4.3.0-10|v4096]], [[4.4.0-10|v5120]], [[4.5.0-10|v6144]], [[5.0.0-11|v7169]], [[6.0.0-11|v8192]], [[6.2.0-12|v9216]], [[7.0.0-13|v10242]], [[7.2.0-17|v11267]], [[8.0.0-18|v12288]], [[9.0.0-20|v14336]], [[9.3.0-21|v15360]], [[9.6.0-24|v16386]], [[10.0.0-27|v17409]], [[10.4.0-29|v18432]], [[11.1.0-34|v19457]]&lt;br /&gt;
| Same as USA&lt;br /&gt;
| Same as USA&lt;br /&gt;
| Same as USA&lt;br /&gt;
|-&lt;br /&gt;
| 00016102&lt;br /&gt;
| 00016202&lt;br /&gt;
| 00016302&lt;br /&gt;
| 00016402&lt;br /&gt;
| 00016502&lt;br /&gt;
| 00016602&lt;br /&gt;
| [[NVer]]&lt;br /&gt;
| [[1.0.0-0|v0]], [[1.1.0-1|v16]], [[2.0.0-2|v32]], [[2.1.0-3|v48]], [[2.1.0-4|v64]], [[3.0.0-5|v80]], [[3.0.0-6|v96]], [[4.0.0-7|v112]],  [[4.1.0-8|v128]], [[4.2.0-9|v144]], [[4.3.0-10|v160]], [[5.0.0-11|v176]], non-USA=[[6.0.0-11|v192]]/USA=[[6.1.0-12U|v192]], [[7.0.0-13|v208]], [[7.1.0-14|v224]], [[7.1.0-15|v240]], [[7.1.0-16|v256]], [[7.2.0-17|v272]], [[8.0.0-18|v288]], [[8.1.0-19|v304]], [[9.0.0-20|v320]], [[9.3.0-21|v336]], [[9.5.0-22|v352]], [[9.5.0-23|v368]], [[9.6.0-24|v384]], [[9.7.0-25|v400]], [[9.9.0-26|v416]], [[10.0.0-27|v432]], [[10.2.0-28|v448]], [[10.4.0-29|v464]], [[10.5.0-30|v480]], [[10.6.0-31|v496]], [[10.7.0-32|v512]], [[11.0.0-33|v528]], [[11.1.0-34|v544]], [[11.2.0-35|v560]], [[11.3.0-36|v576]]&lt;br /&gt;
| [[4.0.0-7|v113]], [[4.2.0-9|v128]], [[5.0.0-11|v129]], [[7.1.0-16|v130]], [[7.2.0-17|v272]], [[9.5.0-23|v131]], [[9.9.0-26|v132]]&lt;br /&gt;
| [[4.1.0-8|v114]], [[4.2.0-9|v133]], [[4.3.0-10|v134]], [[5.0.0-11|v136]], [[7.0.0-13|v144]], [[7.1.0-14|v160]] [[7.1.0-16|v192]], [[7.2.0-17|v272]], [[8.0.0-18|v208]], [[8.1.0-19|v224]], [[9.0.0-20|v240]], [[9.5.0-22|v272]], [[9.5.0-23|v288]], [[9.6.0-24|v304]], [[9.7.0-25|v320]], [[9.9.0-26|v336]], [[10.0.0-27|v352]], [[10.2.0-28|v368]], [[10.4.0-29|v384]], [[10.5.0-30|v400]], [[10.6.0-31|v416]], [[10.7.0-32|v432]], [[11.0.0-33|v448]], [[11.1.0-34|v464]], [[11.2.0-35|v480]], [[11.3.0-36|v496]]&lt;br /&gt;
| [[4.0.0-7|v113]], [[4.1.0-8|v114]], [[4.2.0-9|v133]], [[4.3.0-10|v134]], [[5.0.0-11|v136]], [[7.0.0-13|v160]], [[7.1.0-14|v176]], [[7.1.0-16|v176]], [[7.2.0-17|v272]], [[8.0.0-18|v224]], [[8.1.0-19|v240]], [[9.0.0-20|v256]], [[9.3.0-21|v272]], [[9.5.0-22|v288]], [[9.5.0-23|v304]], [[9.6.0-24|v320]], [[9.7.0-25|v336]], [[9.9.0-26|v352]], [[10.0.0-27|v368]], [[10.2.0-28|v384]], [[10.4.0-29|v400]], [[10.5.0-30|v416]], [[10.6.0-31|v432]], [[10.7.0-32|v448]], [[11.0.0-33|v464]], [[11.1.0-34|v480]], [[11.2.0-35|v496]], [[11.3.0-36|v512]]&lt;br /&gt;
|-&lt;br /&gt;
| 20016102&lt;br /&gt;
| 20016202&lt;br /&gt;
| 20016302&lt;br /&gt;
| N/A&lt;br /&gt;
| 20016502&lt;br /&gt;
| N/A&lt;br /&gt;
| [[New_3DS]] [[NVer]]&lt;br /&gt;
| [[8.1.0-0_New3DS|v0]], [[9.0.0-20|v320]], [[9.3.0-21|v336]], [[9.5.0-22|v352]], [[9.5.0-22|v352]], [[9.5.0-23|v368]], [[9.6.0-24|v384]], [[9.7.0-25|v400]], [[9.9.0-26|v416]], [[10.0.0-27|v432]], [[10.2.0-28|v448]], [[10.4.0-29|v464]], [[10.5.0-30|v480]], [[10.6.0-31|v496]], [[10.7.0-32|v512]], [[11.0.0-33|v528]], [[11.1.0-34|v544]], [[11.2.0-35|v560]], [[11.3.0-36|v576]]&lt;br /&gt;
| N/A&lt;br /&gt;
| N/A&lt;br /&gt;
| [[9.6.0-24|v320]], [[9.7.0-25|v336]], [[9.9.0-26|v352]], [[10.0.0-27|v368]], [[10.2.0-28|v384]], [[10.4.0-29|v400]], [[10.5.0-30|v416]], [[10.6.0-31|v432]], [[10.7.0-32|v448]], [[11.0.0-33|v464]], [[11.2.0-35|v496]], [[11.3.0-36|v512]]&lt;br /&gt;
|-&lt;br /&gt;
| 00017102&lt;br /&gt;
| 00017202&lt;br /&gt;
| 00017302&lt;br /&gt;
| 00017402&lt;br /&gt;
| 00017502&lt;br /&gt;
| 00017602&lt;br /&gt;
| [[CVer]]&lt;br /&gt;
| [[1.0.0-0|v1024]], [[1.1.0-1|v1045]], [[2.0.0-2|v2049]], [[2.1.0-3|v2069]], [[2.2.0-X|v2088]] [[3.0.0-5|v3088]], [[4.0.0-7|v4098]], [[4.1.0-8|v4113]], [[4.2.0-9|v4130]], [[4.3.0-10|v4145]], [[4.4.0-10|v4163]], [[4.5.0-10|v4176]], [[5.0.0-11|v5120]], [[5.1.0-11|v5136]], [[6.0.0-11|v6146]], [[6.1.0-11|v6160]], [[6.2.0-12|v6178]], [[6.3.0-12|v6192]], [[7.0.0-13|v7175]], [[7.1.0-14|v7187]], [[7.2.0-17|v7203]], [[8.0.0-18|v8196]], [[8.1.0-18|v8208]], [[8.1.0-0_New3DS|v8215]](8.1.0-0_New3DS), [[9.0.0-20|v9218]], [[9.1.0-20J|v9232]](JPN-only), [[9.2.0-20|v9248]], [[9.3.0-21|v9264]], [[9.4.0-21|v9280]], [[9.5.0-22|v9296]], [[9.6.0-24|v9319]], [[9.7.0-25|v9328]], [[9.8.0-25|v9344]], [[9.9.0-26|v9360]], [[10.0.0-27|v10240]], [[10.1.0-27|v10256]], [[10.2.0-28|v10272]], [[10.3.0-28|v10288]], [[10.4.0-29|v10304]], [[10.5.0-30|v10320]], [[10.6.0-31|v10336]], [[10.7.0-32|v10352]], [[11.0.0-33|v11264]], [[11.1.0-34|v11280]], [[11.2.0-35|v11296]], [[11.3.0-36|v11312]]&lt;br /&gt;
| [[1.0.0-0|v1024]], [[1.1.0-1|v1045]], [[2.0.0-2|v2049]], [[2.1.0-3|v2069]], [[2.2.0-X|v2088]] [[3.0.0-5|v3088]], [[4.0.0-7|v4098]], [[4.1.0-8|v4113]], [[4.2.0-9|v4130]], [[4.3.0-10|v4145]], [[4.4.0-10|v4163]], [[4.5.0-10|v4176]], [[5.0.0-11|v5120]], [[5.1.0-11|v5136]], [[6.0.0-11|v6146]], [[6.1.0-11|v6160]], [[6.2.0-12|v6178]], [[6.3.0-12|v6192]], [[7.0.0-13|v7175]], [[7.1.0-14|v7187]], [[7.2.0-17|v7203]], [[8.0.0-18|v8196]], [[8.1.0-18|v8208]], [[9.0.0-20|v9217]], [[9.3.0-21|v9264]], [[9.5.0-22|v9296]], [[9.6.0-24|v9319]], [[9.7.0-25|v9328]], [[9.8.0-25|v9344]], [[9.9.0-26|v9360]], [[10.0.0-27|v10240]], [[10.2.0-28|v10272]], [[10.4.0-29|v10304]], [[10.5.0-30|v10320]], [[10.6.0-31|v10336]], [[10.7.0-32|v10352]], [[11.2.0-35|v11296]], [[11.3.0-36|v11312]]&lt;br /&gt;
| Same as CHN&lt;br /&gt;
| Same as CHN + [[11.1.0-34|v11280]]&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
=== 00040130 - System [[Services API|Modules]] ===&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot; border=&amp;quot;1&amp;quot;&lt;br /&gt;
|-&lt;br /&gt;
!  TitleID Low&lt;br /&gt;
!  Description&lt;br /&gt;
!  Versions&lt;br /&gt;
|-&lt;br /&gt;
| 00001002&lt;br /&gt;
| [[Services|sm]] (Stored in [[FIRM|NATIVE_FIRM]])&lt;br /&gt;
| N/A&lt;br /&gt;
|-&lt;br /&gt;
| 00001003&lt;br /&gt;
| SAFE_MODE [[Services|sm]] (Stored in SAFE_MODE NATIVE_FIRM)&lt;br /&gt;
| N/A&lt;br /&gt;
|-&lt;br /&gt;
| 00001102&lt;br /&gt;
| [[Filesystem services‎|fs]] (Stored in [[FIRM|NATIVE_FIRM]])&lt;br /&gt;
| N/A&lt;br /&gt;
|-&lt;br /&gt;
| 00001103&lt;br /&gt;
| SAFE_MODE [[Filesystem services‎|fs]] (Stored in SAFE_MODE NATIVE_FIRM)&lt;br /&gt;
| N/A&lt;br /&gt;
|-&lt;br /&gt;
| 00001202&lt;br /&gt;
| [[Process Manager Services|pm]] (Stored in [[FIRM|NATIVE_FIRM]])&lt;br /&gt;
| N/A&lt;br /&gt;
|-&lt;br /&gt;
| 00001203&lt;br /&gt;
| SAFE_MODE [[Process Manager Services|pm]] (Stored in SAFE_MODE NATIVE_FIRM)&lt;br /&gt;
| N/A&lt;br /&gt;
|-&lt;br /&gt;
| 00001302&lt;br /&gt;
| [[Loader Services‎|loader]]  (Stored in [[FIRM|NATIVE_FIRM]])&lt;br /&gt;
| N/A&lt;br /&gt;
|-&lt;br /&gt;
| 00001303&lt;br /&gt;
| SAFE_MODE [[Loader Services‎|loader]]  (Stored in SAFE_MODE NATIVE_FIRM)&lt;br /&gt;
| N/A&lt;br /&gt;
|-&lt;br /&gt;
| 00001402&lt;br /&gt;
| [[PXI Services‎|pxi]]  (Stored in [[FIRM|NATIVE_FIRM]])&lt;br /&gt;
| N/A&lt;br /&gt;
|-&lt;br /&gt;
| 00001403&lt;br /&gt;
| SAFE_MODE [[PXI Services‎|pxi]]  (Stored in SAFE_MODE NATIVE_FIRM)&lt;br /&gt;
| N/A&lt;br /&gt;
|-&lt;br /&gt;
| 00001502&lt;br /&gt;
| [[Application Manager Services|AM]] ( Application Manager )&lt;br /&gt;
| [[1.0.0-0|v0]], [[2.0.0-2|v1026]], [[3.0.0-5|v2053]], [[4.0.0-7|v3072]], [[5.0.0-11|v4098]], [[6.0.0-11|v5120]], [[8.0.0-18|v6148]], [[8.1.0-0_New3DS|v7168]]([[8.1.0-0_New3DS]]), [[9.0.0-20|v8192]], [[10.0.0-27|v9217]]&lt;br /&gt;
|-&lt;br /&gt;
| 00001503&lt;br /&gt;
| SAFE_MODE [[Application Manager Services|AM]]&lt;br /&gt;
| [[1.0.0-0|v0]]&lt;br /&gt;
|-&lt;br /&gt;
| 20001503&lt;br /&gt;
| [[New_3DS]] SAFE_MODE [[Application Manager Services|AM]]&lt;br /&gt;
| [[8.1.0-0_New3DS|v7169]]&lt;br /&gt;
|-&lt;br /&gt;
| 00001602&lt;br /&gt;
| [[Camera Services|Camera]]&lt;br /&gt;
| [[1.0.0-0|v0]], [[2.0.0-2|v1026]], [[3.0.0-5|v2048]], [[4.0.0-7|v3074]], [[5.0.0-11|v4098]], [[6.0.0-11|v5120]], [[7.1.0-14|v6146]], [[8.0.0-18|v7172]], [[9.0.0-20|v9216]], [[9.3.0-21|v10242]], [[10.0.0-27|v11265]]&lt;br /&gt;
|-&lt;br /&gt;
| 20001602&lt;br /&gt;
| [[New_3DS]] [[Camera Services|Camera]]&lt;br /&gt;
| [[8.1.0-0_New3DS|v8200]], [[9.0.0-20|v9218]], [[9.3.0-21|v10242]], [[10.0.0-27|v11265]]&lt;br /&gt;
|-&lt;br /&gt;
| 00001702&lt;br /&gt;
| [[Config Services|Config]] (cfg)&lt;br /&gt;
| [[1.0.0-0|v0]], [[2.0.0-2|v1024]], [[3.0.0-5|v2049]], v3072, [[4.0.0-7|v4096]], [[5.0.0-11|v5122]], [[6.0.0-11|v6145]], [[6.1.0-11|v7168]], [[7.0.0-13|v8196]], [[7.2.0-17|v9220]], [[8.0.0-18|v10243]], [[8.1.0-0_New3DS|v11265]]([[8.1.0-0_New3DS]]), [[9.0.0-20|v12290]], [[9.3.0-21|v13315]], [[9.6.0-24|v14342]]&lt;br /&gt;
|-&lt;br /&gt;
| 00001703&lt;br /&gt;
| SAFE_MODE [[Config Services|Config]] (cfg)&lt;br /&gt;
| [[1.0.0-0|v0]]&lt;br /&gt;
|-&lt;br /&gt;
| 20001703&lt;br /&gt;
| [[New_3DS]] SAFE_MODE [[Config Services|Config]] (cfg)&lt;br /&gt;
| [[8.1.0-0_New3DS|v11265]]&lt;br /&gt;
|-&lt;br /&gt;
| 00001802&lt;br /&gt;
| [[Codec Services|Codec]]&lt;br /&gt;
| [[1.0.0-0|v0]], [[2.0.0-2|v1025]], [[2.2.0-X|v2048]], [[3.0.0-5|v3072]], [[5.0.0-11|v4098]], [[7.0.0-13|v5120]], [[8.0.0-18|v6144]], [[9.0.0-20|v7168]](Also for [[8.1.0-0_New3DS]])&lt;br /&gt;
|-&lt;br /&gt;
| 00001803&lt;br /&gt;
| SAFE_MODE [[Codec Services|Codec]]&lt;br /&gt;
| [[1.0.0-0|v0]]&lt;br /&gt;
|-&lt;br /&gt;
| 20001803&lt;br /&gt;
| [[New_3DS]] SAFE_MODE [[Codec Services|Codec]]&lt;br /&gt;
| [[8.1.0-0_New3DS|v7169]]&lt;br /&gt;
|-&lt;br /&gt;
| 00001902&lt;br /&gt;
| dmnt, debugger sysmodule. This use devunit-only HIO for devunit&amp;lt;&amp;gt;pc comms. This only exists for development units(launched by NS during startup depending on certain [[Configuration_Memory]] fields&#039; values). This is installed at the [[Factory_Setup|factory]], then later deleted at the factory on retail units.&lt;br /&gt;
| &lt;br /&gt;
|-&lt;br /&gt;
| 00001A02&lt;br /&gt;
| [[DSP Services|DSP]]&lt;br /&gt;
| [[1.0.0-0|v0]], [[3.0.0-5|v1024]], [[4.0.0-7|v2048]], [[5.0.0-11|v3074]], [[6.0.0-11|v4096]], [[8.0.0-18|v5120]], [[9.7.0-25|v6145]], [[11.1.0-34|v7169]]&lt;br /&gt;
|-&lt;br /&gt;
| 00001A03&lt;br /&gt;
| SAFE_MODE [[DSP Services|DSP]]&lt;br /&gt;
| [[1.0.0-0|v0]]&lt;br /&gt;
|-&lt;br /&gt;
| 20001A03&lt;br /&gt;
| [[New_3DS]] SAFE_MODE [[DSP Services|DSP]]&lt;br /&gt;
| [[8.1.0-0_New3DS|v6145]]&lt;br /&gt;
|-&lt;br /&gt;
| 00001B02&lt;br /&gt;
| [[GPIO Services|GPIO]]&lt;br /&gt;
| [[1.0.0-0|v0]], [[5.0.0-11|v1025]], [[8.0.0-18|v2048]], [[9.5.0-22|v3073]]&lt;br /&gt;
|-&lt;br /&gt;
| 00001B03&lt;br /&gt;
| SAFE_MODE [[GPIO Services|GPIO]]&lt;br /&gt;
| [[1.0.0-0|v0]]&lt;br /&gt;
|-&lt;br /&gt;
| 20001B03&lt;br /&gt;
| [[New_3DS]] SAFE_MODE [[GPIO Services|GPIO]]&lt;br /&gt;
| [[8.1.0-0_New3DS|v3073]]&lt;br /&gt;
|-&lt;br /&gt;
| 00001C02&lt;br /&gt;
| [[GSP Services|GSP]]&lt;br /&gt;
| [[1.0.0-0|v0]], [[1.1.0-1|v1040]], [[2.0.0-2|v2049]], [[3.0.0-5|v3075]], v4098, [[4.0.0-7|v5120]], [[5.0.0-11|v6145]], [[6.0.0-11|v7168]], [[8.0.0-18|v8196]], [[9.0.0-20|v10240]], [[9.3.0-21|v11264]], [[9.6.0-24|v12294]], [[11.3.0-36|v13312]]&lt;br /&gt;
|-&lt;br /&gt;
| 20001C02&lt;br /&gt;
| [[New_3DS]] [[GSP Services|GSP]]&lt;br /&gt;
| [[8.1.0-0_New3DS|v10243]], [[9.3.0-21|v11267]], [[9.6.0-24|v12294]], [[11.3.0-36|v13312]]&lt;br /&gt;
|-&lt;br /&gt;
| 00001C03&lt;br /&gt;
| SAFE_MODE [[GSP Services|GSP]]&lt;br /&gt;
| [[1.0.0-0|v0]]&lt;br /&gt;
|-&lt;br /&gt;
| 20001C03&lt;br /&gt;
| [[New_3DS]] SAFE_MODE [[GSP Services|GSP]]&lt;br /&gt;
| [[8.1.0-0_New3DS|v9217]]&lt;br /&gt;
|-&lt;br /&gt;
| 00001D02&lt;br /&gt;
| [[HID Services|HID]] (Human Interface Devices) &lt;br /&gt;
| [[1.0.0-0|v0]], [[2.0.0-2|v1025]], [[2.2.0-X|v2048]], [[3.0.0-5|v3072]], [[4.0.0-7|v4096]], [[5.0.0-11|v5121]], [[7.2.0-17|v6148]], [[8.0.0-18|v7168]], [[8.1.0-0_New3DS|v8192]]([[8.1.0-0_New3DS]]), [[9.0.0-20|v9216]], [[9.3.0-21|v10240]]&lt;br /&gt;
|-&lt;br /&gt;
| 00001D03&lt;br /&gt;
| SAFE_MODE [[HID Services|HID]]&lt;br /&gt;
| [[1.0.0-0|v0]]&lt;br /&gt;
|-&lt;br /&gt;
| 20001D03&lt;br /&gt;
| [[New_3DS]] SAFE_MODE [[HID Services|HID]]&lt;br /&gt;
| [[8.1.0-0_New3DS|v8193]]&lt;br /&gt;
|-&lt;br /&gt;
| 00001E02&lt;br /&gt;
| [[I2C Services|i2c]]&lt;br /&gt;
| [[1.0.0-0|v0]], [[3.0.0-5|v1024]], [[5.0.0-11|v2049]], [[8.0.0-18|v3076]], [[9.3.0-21|v5120]]&lt;br /&gt;
|-&lt;br /&gt;
| 20001E02&lt;br /&gt;
| [[New_3DS]] [[I2C Services|i2c]]&lt;br /&gt;
| [[8.1.0-0_New3DS|v4096]], [[9.3.0-21|v5121]]&lt;br /&gt;
|- &lt;br /&gt;
| 00001E03&lt;br /&gt;
| SAFE_MODE [[I2C Services|i2c]]&lt;br /&gt;
| [[1.0.0-0|v0]]&lt;br /&gt;
|- &lt;br /&gt;
| 20001E03&lt;br /&gt;
| [[New_3DS]] SAFE_MODE [[I2C Services|i2c]]&lt;br /&gt;
| [[8.1.0-0_New3DS|v4097]]&lt;br /&gt;
|-&lt;br /&gt;
| 00001F02&lt;br /&gt;
| [[MCU Services|MCU]]&lt;br /&gt;
| [[1.0.0-0|v0]], [[2.0.0-2|v1026]], [[2.1.0-3|v2048]], [[3.0.0-5|v3072]], [[4.0.0-7|v4102]], [[5.0.0-11|v5122]], [[6.0.0-11|v6145]], [[7.0.0-13|v7168]], [[8.0.0-18|v8192]]&lt;br /&gt;
|-&lt;br /&gt;
| 20001F02&lt;br /&gt;
| [[New_3DS]] [[MCU Services|MCU]]&lt;br /&gt;
| [[8.1.0-0_New3DS|v8192]]&lt;br /&gt;
|-&lt;br /&gt;
| 00001F03&lt;br /&gt;
| SAFE_MODE [[MCU Services|MCU]]&lt;br /&gt;
| [[1.0.0-0|v0]]&lt;br /&gt;
|-&lt;br /&gt;
| 20001F03&lt;br /&gt;
| [[New_3DS]] SAFE_MODE [[MCU Services|MCU]]&lt;br /&gt;
| [[8.1.0-0_New3DS|v9217]]&lt;br /&gt;
|-&lt;br /&gt;
| 00002002&lt;br /&gt;
| [[MIC Services|MIC]] (Microphone)&lt;br /&gt;
| [[1.0.0-0|v0]], [[5.0.0-11|v1025]], [[8.0.0-18|v2048]]&lt;br /&gt;
|-&lt;br /&gt;
| 00002102&lt;br /&gt;
| [[PDN Services|PDN]]&lt;br /&gt;
| [[1.0.0-0|v0]], [[5.0.0-11|v1025]], [[8.0.0-18|v2048]]&lt;br /&gt;
|-&lt;br /&gt;
| 00002103&lt;br /&gt;
| SAFE_MODE [[PDN Services|PDN]]&lt;br /&gt;
| [[1.0.0-0|v0]]&lt;br /&gt;
|-&lt;br /&gt;
| 20002103&lt;br /&gt;
| [[New_3DS]] SAFE_MODE [[PDN Services|PDN]]&lt;br /&gt;
| [[8.1.0-0_New3DS|v3073]]&lt;br /&gt;
|-&lt;br /&gt;
| 00002202&lt;br /&gt;
| [[PTM Services|PTM]] (Play time, pedometer, and battery manager)&lt;br /&gt;
| [[1.0.0-0|v0]], [[2.0.0-2|v1026]], [[2.2.0-X|v2048]], [[3.0.0-5|v3075]], v4096, [[4.0.0-7|v5120]], [[5.0.0-11|v6146]], [[6.0.0-11|v7168]], [[7.0.0-13|v8192]], [[8.0.0-18|v9219]], [[9.6.0-24|v11264]]&lt;br /&gt;
|-&lt;br /&gt;
| 20002202&lt;br /&gt;
| [[New_3DS]] [[PTM Services|PTM]] (Play time, pedometer, and battery manager)&lt;br /&gt;
| [[8.1.0-0_New3DS|v10240]], [[9.6.0-24|v11264]]&lt;br /&gt;
|-&lt;br /&gt;
| 00002203&lt;br /&gt;
| SAFE_MODE [[PTM Services|PTM]]&lt;br /&gt;
| [[1.0.0-0|v0]]&lt;br /&gt;
|-&lt;br /&gt;
| 20002203&lt;br /&gt;
| [[New_3DS]] SAFE_MODE [[PTM Services|PTM]]&lt;br /&gt;
| [[8.1.0-0_New3DS|v10241]]&lt;br /&gt;
|-&lt;br /&gt;
| 00002302&lt;br /&gt;
| [[SPI Services|spi]]&lt;br /&gt;
| [[1.0.0-0|v0]], [[2.0.0-2|v1025]], [[5.0.0-11|v2049]], [[8.0.0-18|v3072]]&lt;br /&gt;
|-&lt;br /&gt;
| 20002302&lt;br /&gt;
| [[New_3DS]] [[SPI Services|spi]]&lt;br /&gt;
| [[8.1.0-0_New3DS|v4096]]&lt;br /&gt;
|-&lt;br /&gt;
| 00002303&lt;br /&gt;
| SAFE_MODE [[SPI Services|spi]]&lt;br /&gt;
| [[1.0.0-0|v0]]&lt;br /&gt;
|-&lt;br /&gt;
| 20002303&lt;br /&gt;
| [[New_3DS]] SAFE_MODE [[SPI Services|spi]]&lt;br /&gt;
| [[8.1.0-0_New3DS|v4097]]&lt;br /&gt;
|-&lt;br /&gt;
| 00002402&lt;br /&gt;
| [[AC Services|AC]] (Network manager)&lt;br /&gt;
| [[1.0.0-0|v0]], [[1.1.0-1|v1024]], [[2.0.0-2|v2052]], [[2.1.0-3|v3072]], [[3.0.0-5|v4101]], [[5.0.0-11|v5122]], [[7.0.0-13|v6145]], [[8.0.0-18|v7172]], [[9.0.0-20|v8192]](Also for [[8.1.0-0_New3DS]]), [[9.3.0-21|v9216]]&lt;br /&gt;
|-&lt;br /&gt;
| 00002403&lt;br /&gt;
| SAFE_MODE [[AC Services|AC]]&lt;br /&gt;
| [[1.0.0-0|v0]]&lt;br /&gt;
|-&lt;br /&gt;
| 20002403&lt;br /&gt;
| [[New_3DS]] SAFE_MODE [[AC Services|AC]]&lt;br /&gt;
| [[8.1.0-0_New3DS|v8193]]&lt;br /&gt;
|-&lt;br /&gt;
| 00002602&lt;br /&gt;
| [[CECD Services|Cecd]] (StreetPass)&lt;br /&gt;
| [[1.0.0-0|v0]], [[2.0.0-2|v1026]], [[2.2.0-X|v2048]], [[3.0.0-5|v3073]], [[4.0.0-7|v4097]], [[5.0.0-11|v5122]], [[6.0.0-11|v6144]], [[6.2.0-12|v7170]], [[7.0.0-13|v8193]], [[8.0.0-18|v9216]], [[9.0.0-20|v10240]]&lt;br /&gt;
|-&lt;br /&gt;
| 00002702&lt;br /&gt;
| [[CSND Services|CSND]]&lt;br /&gt;
| [[1.0.0-0|v0]], [[2.0.0-2|v1025]], [[4.0.0-7|v2048]], [[5.0.0-11|v3073]], [[8.0.0-18|v4096]], [[9.0.0-20|v5120]]&lt;br /&gt;
|-&lt;br /&gt;
| 00002703&lt;br /&gt;
| SAFE_MODE [[CSND Services|CSND]]&lt;br /&gt;
| [[1.0.0-0|v0]]&lt;br /&gt;
|-&lt;br /&gt;
| 20002703&lt;br /&gt;
| [[New_3DS]] SAFE_MODE [[CSND Services|CSND]]&lt;br /&gt;
| [[8.1.0-0_New3DS|v5121]]&lt;br /&gt;
|-&lt;br /&gt;
| 00002802&lt;br /&gt;
| [[DLP Services|DLP]] ([[Download Play]])&lt;br /&gt;
| [[1.0.0-0|v0]], [[2.0.0-2|v1026]], [[2.2.0-X|v2048]], [[3.0.0-5|v3078]], [[5.0.0-11|v4099]], [[8.0.0-18|v5123]], [[9.0.0-20|v6145]](Also for [[8.1.0-0_New3DS]]), [[9.6.0-24|v7174]], [[10.0.0-27|v8192]]&lt;br /&gt;
|-&lt;br /&gt;
| 00002902&lt;br /&gt;
| [[HTTP Services|HTTP]]&lt;br /&gt;
| [[1.0.0-0|v0]], [[2.0.0-2|v1026]], [[2.1.0-3|v2049]], [[2.2.0-X|v3072]], [[3.0.0-5|v4099]], [[4.0.0-7|v5122]], [[5.0.0-11|v6145]], [[7.0.0-13|v7171]], [[7.1.0-14|v8192]], [[8.0.0-18|v9220]], [[8.1.0-18|v10245]], [[8.1.0-0_New3DS|v11264]]([[8.1.0-0_New3DS]]), [[9.0.0-20|v12288]], [[9.6.0-24|v13318]]&lt;br /&gt;
|-&lt;br /&gt;
| 00002903&lt;br /&gt;
| SAFE_MODE [[HTTP Services|HTTP]]&lt;br /&gt;
| [[1.0.0-0|v0]]&lt;br /&gt;
|-&lt;br /&gt;
| 20002903&lt;br /&gt;
| [[New_3DS]] SAFE_MODE [[HTTP Services|HTTP]]&lt;br /&gt;
| [[8.1.0-0_New3DS|v10241]]&lt;br /&gt;
|-&lt;br /&gt;
| 00002A02&lt;br /&gt;
| [[MP Services|MP]]&lt;br /&gt;
| [[1.0.0-0|v0]], [[5.0.0-11|v1025]], [[8.0.0-18|v2048]]&lt;br /&gt;
|-&lt;br /&gt;
| 00002A03&lt;br /&gt;
| SAFE_MODE [[MP Services|MP]]&lt;br /&gt;
| [[1.0.0-0|v0]]&lt;br /&gt;
|-&lt;br /&gt;
| 00002B02&lt;br /&gt;
| [[NDM Services|NDM]]&lt;br /&gt;
| [[1.0.0-0|v0]], [[2.0.0-2|v1025]], [[3.0.0-5|v2049]], [[4.0.0-7|v3072]], [[5.0.0-11|v4098]], [[8.0.0-18|v5124]], [[8.1.0-0_New3DS|v6144]]([[8.1.0-0_New3DS]]), [[9.0.0-20|v7169]]&lt;br /&gt;
|-&lt;br /&gt;
| 00002C02&lt;br /&gt;
| [[NIM Services|NIM]]&lt;br /&gt;
| [[1.0.0-0|v0]], [[2.0.0-2|v1028]], [[3.0.0-5|v2055]], [[4.0.0-7|v3074]], [[5.0.0-11|v4100]], [[6.0.0-11|v5120]], [[7.0.0-13|v6148]], [[7.2.0-17|v7174]], [[8.0.0-18|v8195]], [[8.1.0-0_New3DS|v9217]]([[8.1.0-0_New3DS]]), [[9.0.0-20|v10249]], [[9.3.0-21|v11267]], [[9.6.0-24|v12296]], [[10.0.0-27|v13313]]&lt;br /&gt;
|-&lt;br /&gt;
| 00002C03&lt;br /&gt;
| SAFE_MODE [[NIM Services|NIM]]&lt;br /&gt;
| [[1.0.0-0|v0]]&lt;br /&gt;
|-&lt;br /&gt;
| 20002C03&lt;br /&gt;
| [[New_3DS]] SAFE_MODE [[NIM Services|NIM]]&lt;br /&gt;
| [[8.1.0-0_New3DS|v9217]]&lt;br /&gt;
|-&lt;br /&gt;
| 00002D02&lt;br /&gt;
| [[NWM Services|NWM]] ( Low-level wifi manager )&lt;br /&gt;
| [[1.0.0-0|v0]], [[1.1.0-1|v1024]], [[2.0.0-2|v2052]], [[2.2.0-X|v3072]], [[3.0.0-5|v4101]], [[4.0.0-7|v5120]], [[5.0.0-11|v6148]], [[6.0.0-11|v7169]], [[7.2.0-17|v8196]], [[8.0.0-18|v9216]], [[9.0.0-20|v10240]]&lt;br /&gt;
|-&lt;br /&gt;
| 00002D03&lt;br /&gt;
| SAFE_MODE [[NWM Services|NWM]]&lt;br /&gt;
| [[1.0.0-0|v0]], [[6.0.0-11|v5120]]&lt;br /&gt;
|-&lt;br /&gt;
| 20002D03&lt;br /&gt;
| [[New_3DS]] SAFE_MODE [[NWM Services|NWM]]&lt;br /&gt;
| [[8.1.0-0_New3DS|v10241]]&lt;br /&gt;
|-&lt;br /&gt;
| 00002E02&lt;br /&gt;
| [[Socket Services|Sockets]]&lt;br /&gt;
| [[1.0.0-0|v0]], [[1.1.0-1|v1024]], [[2.0.0-2|v2053]], [[3.0.0-5|v3075]], [[4.0.0-7|v4096]], [[5.0.0-11|v5121]], [[8.0.0-18|v6144]], [[9.0.0-20|v7168]], [[10.6.0-31|v8192]]&lt;br /&gt;
|-&lt;br /&gt;
| 00002E03&lt;br /&gt;
| SAFE_MODE [[Socket Services|Sockets]]&lt;br /&gt;
| [[1.0.0-0|v0]]&lt;br /&gt;
|-&lt;br /&gt;
| 20002E03&lt;br /&gt;
| [[New_3DS]] SAFE_MODE [[Socket Services|Sockets]]&lt;br /&gt;
| [[8.1.0-0_New3DS|v7169]]&lt;br /&gt;
|-&lt;br /&gt;
| 00002F02&lt;br /&gt;
| [[SSL Services|SSL]]&lt;br /&gt;
| [[1.0.0-0|v0]], [[2.0.0-2|v1024]], [[2.1.0-3|v2048]], [[3.0.0-5|v3072]], [[4.0.0-7|v4096]], [[5.0.0-11|v5122]], [[8.0.0-18|v6144]], [[9.0.0-20|v7168]], [[9.6.0-24|v8198]]&lt;br /&gt;
|-&lt;br /&gt;
| 00002F03&lt;br /&gt;
| SAFE_MODE [[SSL Services|SSL]]&lt;br /&gt;
| [[1.0.0-0|v0]]&lt;br /&gt;
|-&lt;br /&gt;
| 20002F03&lt;br /&gt;
| [[New_3DS]] SAFE_MODE [[SSL Services|SSL]]&lt;br /&gt;
| [[8.1.0-0_New3DS|v7169]]&lt;br /&gt;
|-&lt;br /&gt;
| 00003000&lt;br /&gt;
| [[FIRM|Process9]] (in SAFE_MODE and normal NATIVE_FIRM)&lt;br /&gt;
| N/A&lt;br /&gt;
|-&lt;br /&gt;
| 00003102&lt;br /&gt;
| [[Process Services‎|PS]] ( Process Manager )&lt;br /&gt;
| [[1.0.0-0|v0]], [[2.0.0-2|v1025]], [[5.0.0-11|v2049]], [[6.0.0-11|v3072]], [[8.0.0-18|v4096]], [[9.0.0-20|v5120]]&lt;br /&gt;
|-&lt;br /&gt;
| 00003103&lt;br /&gt;
| SAFE_MODE [[Process Services‎|PS]]&lt;br /&gt;
| [[1.0.0-0|v0]]&lt;br /&gt;
|-&lt;br /&gt;
| 20003103&lt;br /&gt;
| [[New_3DS]] SAFE_MODE [[Process Services‎|PS]]&lt;br /&gt;
| [[8.1.0-0_New3DS|v5121]]&lt;br /&gt;
|-&lt;br /&gt;
| 00003202&lt;br /&gt;
| [[Friend Services‎|friends]] (Friends list)&lt;br /&gt;
| [[1.0.0-0|v0]], [[2.0.0-2|v1028]], [[2.2.0-X|v2048]], [[3.0.0-5|v3072]], [[4.0.0-7|v4096]], [[5.0.0-11|v5122]], [[7.0.0-13|v6145]], [[8.0.0-18|v7172]], [[9.0.0-20|v8192]](Also for [[8.1.0-0_New3DS]]), [[10.5.0-30|v9216]], [[10.7.0-32|v10240]], [[11.0.0-33|v11264]], [[11.1.0-34|v12288]], [[11.2.0-35|v13312]], [[11.3.0-36|v14336]]&lt;br /&gt;
|-&lt;br /&gt;
| 00003203&lt;br /&gt;
| SAFE_MODE [[Friend Services‎|friends]] (Friends list)&lt;br /&gt;
| [[1.0.0-0|v0]]&lt;br /&gt;
|-&lt;br /&gt;
| 20003203&lt;br /&gt;
| [[New_3DS]] SAFE_MODE [[Friend Services‎|friends]] (Friends list)&lt;br /&gt;
| [[8.1.0-0_New3DS|v8193]]&lt;br /&gt;
|-&lt;br /&gt;
| 00003302&lt;br /&gt;
| [[IR Services‎|IR]] (Infrared)&lt;br /&gt;
| [[1.0.0-0|v0]], [[2.0.0-2|v1026]], [[2.2.0-X|v2048]], [[3.0.0-5|v3072]], [[4.0.0-7|v4096]], [[5.0.0-11|v5121]], [[8.0.0-18|v6148]], [[8.1.0-0_New3DS|v7170]]([[8.1.0-0_New3DS]]), [[9.0.0-20|v8192]], [[9.3.0-21|v9216]], [[9.6.0-24|v10246]], [[10.0.0-27|v11265]], [[10.6.0-31|v12289]]&lt;br /&gt;
|-&lt;br /&gt;
| 00003303&lt;br /&gt;
| SAFE_MODE [[IR Services‎|IR]]&lt;br /&gt;
| [[1.0.0-0|v0]]&lt;br /&gt;
|-&lt;br /&gt;
| 20003303&lt;br /&gt;
| [[New_3DS]] SAFE_MODE [[IR Services‎|IR]]&lt;br /&gt;
| [[8.1.0-0_New3DS|v7169]]&lt;br /&gt;
|- &lt;br /&gt;
| 00003402&lt;br /&gt;
| [[BOSS Services‎|BOSS]] (SpotPass)&lt;br /&gt;
| [[1.0.0-0|v0]], [[1.1.0-1|v1024]], [[2.0.0-2|v2053]], [[2.2.0-X|v3073]], [[3.0.0-5|v4101]], [[4.0.0-7|v5122]], [[5.0.0-11|v6146]], [[6.0.0-11|v7169]], [[6.2.0-12|v8193]], [[7.0.0-13|v9222]], [[8.0.0-18|v10240]], [[9.0.0-20|v11266]], [[10.0.0-27|v12289]], [[10.4.0-29|v13314]]&lt;br /&gt;
|-&lt;br /&gt;
| 00003502&lt;br /&gt;
| [[News Services‎|News]] (Notifications)&lt;br /&gt;
| [[1.0.0-0|v0]], [[2.0.0-2|v1028]], [[2.2.0-X|v2048]], [[3.0.0-5|v3072]], [[5.0.0-11|v4097]], [[8.0.0-18|v5120]], [[9.0.0-20|v6147]], [[9.7.0-25|v7168]]&lt;br /&gt;
|-&lt;br /&gt;
| 00003602&lt;br /&gt;
| &amp;quot;debugger&amp;quot;. This only exist for development units(launched by NS during startup depending on certain [[Configuration_Memory]] fields&#039; values).&lt;br /&gt;
| &lt;br /&gt;
|-&lt;br /&gt;
| 00003702&lt;br /&gt;
| [[RO_Services|RO]]&lt;br /&gt;
| [[2.0.0-2|v0]], [[4.0.0-7|v1024]], [[5.0.0-11|v2049]], [[7.2.0-17|v3074]], [[8.0.0-18|v4096]], [[9.0.0-20|v5120]](Also for [[8.1.0-0_New3DS]]), [[9.3.0-21|v6148]]&lt;br /&gt;
|-&lt;br /&gt;
| 00003802&lt;br /&gt;
| [[ACT Services‎|act]] (handles Nintendo Network &#039;&#039;&#039;a&#039;&#039;&#039;c&#039;&#039;&#039;c&#039;&#039;&#039;oun&#039;&#039;&#039;t&#039;&#039;&#039;s)&lt;br /&gt;
| [[7.0.0-13|v1029]], [[7.1.0-14|v2050]], [[7.2.0-17|v3077]], [[8.0.0-18|v4099]], [[8.1.0-0_New3DS|v5120]]([[8.1.0-0_New3DS]]), [[9.0.0-20|v6144]], [[9.3.0-21|v7168]], [[9.6.0-24|v8198]]&lt;br /&gt;
|-&lt;br /&gt;
| 00004002&lt;br /&gt;
| Old3DS [[NFC_Services|nfc]]&lt;br /&gt;
| [[9.3.0-21|v2053]], [[9.6.0-24|v4106]], [[9.7.0-25|v5121]], [[10.0.0-27|v6145]], [[10.6.0-31|v7168]], [[10.7.0-32|v8192]]&lt;br /&gt;
|-&lt;br /&gt;
| 20004002&lt;br /&gt;
| [[New_3DS]] [[NFC_Services|nfc]]&lt;br /&gt;
| [[8.1.0-0_New3DS|v0]], [[9.0.0-20|v1024]], [[9.3.0-21|v2053]], [[9.5.0-22|v3073]], [[9.6.0-24|v4102]], [[10.0.0-27|v6145]], [[10.6.0-31|v7168]]&lt;br /&gt;
|-&lt;br /&gt;
| 20004102&lt;br /&gt;
| [[New_3DS]] [[MVD Services|mvd]]&lt;br /&gt;
| [[8.1.0-0_New3DS|v0]], [[9.0.0-20|v1024]]&lt;br /&gt;
|-&lt;br /&gt;
| 20004202&lt;br /&gt;
| [[New_3DS]] [[QTM Services|qtm]]&lt;br /&gt;
| [[8.1.0-0_New3DS|v8]], [[9.0.0-20|v1024]], [[9.3.0-21|v2052]]&lt;br /&gt;
|-&lt;br /&gt;
| 00008002&lt;br /&gt;
| [[NS]] (Memory-region: &amp;quot;SYSTEM&amp;quot;)&lt;br /&gt;
| [[1.0.0-0|v0]], [[2.0.0-2|v1028]], [[2.2.0-X|v2048]], [[3.0.0-5|v3077]], v4096, [[4.0.0-7|v5121]], [[5.0.0-11|v6148]], [[5.1.0-11|v7168]], [[6.0.0-11|v8193]], [[6.1.0-11|v9216]], [[7.0.0-13|v10248]], [[7.2.0-17|v11268]], [[8.0.0-18|v12291]], [[8.1.0-0_New3DS|v13312]]([[8.1.0-0_New3DS]]), [[9.0.0-20|v14336]], [[9.3.0-21|v15360]], [[9.6.0-24|v16390]], [[9.8.0-25|v17408]], [[10.0.0-27|v18433]], [[10.4.0-29|v19458]], [[11.1.0-34|v20482]], [[11.3.0-36|v21504]]&lt;br /&gt;
|-&lt;br /&gt;
| 00008003&lt;br /&gt;
| SAFE_MODE [[NS]] (Memory-region: &amp;quot;SYSTEM&amp;quot;)&lt;br /&gt;
| [[1.0.0-0|v0]]&lt;br /&gt;
|-&lt;br /&gt;
| 20008003&lt;br /&gt;
| [[New_3DS]] SAFE_MODE [[NS]] (Memory-region: &amp;quot;SYSTEM&amp;quot;)&lt;br /&gt;
| [[8.1.0-0_New3DS|v13313]]&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
Once Home Menu finishes loading, all of the above system modules are running, except for MP, RO, and act which are automatically [[Process_Manager_Services|loaded]] when a process requires them. When [[Process_Manager_Services|PM]]-module terminates processes, it will check whether the processes listed as dependencies for this process are listed as dependencies for other processes. Any processes which are no longer listed in any processes dependencies lists are then terminated. On [[New_3DS]], the only New3DS-specific system-module which automatically gets loaded during system boot is qtm.&lt;br /&gt;
&lt;br /&gt;
All of the above system modules use the &amp;quot;BASE&amp;quot; [[SVC|memory-region]](specified in the exheader), except when listed otherwise for certain modules.&lt;br /&gt;
&lt;br /&gt;
When handling the exheader dependency list starting with [[8.0.0-18]], Old3DS FIRM [[Process_Manager_Services|PM]]-module now skips handling titles in this list which have any bits in programID-low bitmask 0xF0000000 set(with [[8.0.0-18]] this is hard-coded). The exheader dependency list handling change is for the [[New 3DS]] system-module(s), which do not exist on Old3DS. When the New3DS pm-module is launching any title except [[NS]], it first attempts to launch the title with programID-low bitmask 0x20000000 set, then with that bitmask clear if launching fails.&lt;br /&gt;
&lt;br /&gt;
=== 00040138 - [[FIRM|System Firmware]] ===&lt;br /&gt;
NATIVE_FIRM and SAFE_MODE_FIRM for the initial versions are exactly the same, besides [[Configuration_Memory|core-version]] fields. SAFE_MODE_FIRM is used for running SAFE_MODE titles, on retail SAFE_MODE_FIRM seems to be only used for running the [[System_Settings#System_Updater|System Updater]] application. When a GBA VC title is launched, AGB_FIRM is launched to handle running this title. GBA VC savegames stored under SD card /title/&amp;lt;TID&amp;gt;/data use a custom format, this is handled by AGB_FIRM.&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot; border=&amp;quot;1&amp;quot;&lt;br /&gt;
|-&lt;br /&gt;
!  TitleID Low&lt;br /&gt;
!  Description&lt;br /&gt;
!  USA/EUR/JPN Versions&lt;br /&gt;
!  CHN Versions&lt;br /&gt;
!  KOR Versions&lt;br /&gt;
!  TWN Versions&lt;br /&gt;
|-&lt;br /&gt;
| 00000001&lt;br /&gt;
| Unknown, very similar to SAFE_MODE_FIRM. Exists only on dev units and seems to only be used by SystemUpdaters.&lt;br /&gt;
| v0&lt;br /&gt;
| &lt;br /&gt;
| &lt;br /&gt;
| &lt;br /&gt;
|-&lt;br /&gt;
| 00000002&lt;br /&gt;
| NATIVE_FIRM (Native Firmware)&lt;br /&gt;
| [[1.0.0-0|v432]], [[1.1.0-1|v1472]], [[2.0.0-2|v2516]], [[2.1.0-3|v3553]], [[2.2.0-X|v4595]], [[3.0.0-5|v5647]], [[4.0.0-7|v6677]], [[4.1.0-8|v7712]], [[5.0.0-11|v8758]], [[5.1.0-11|v9792]], [[6.0.0-11|v10833]], [[6.1.0-11|v11872]], [[7.0.0-13|v12916]], [[7.2.0-17|v13956]], v15043, [[8.0.0-18|v15047]], [[9.0.0-20|v17120]], [[9.3.0-21|v18182]], [[9.5.0-22|v19216]], [[9.6.0-24|v20262]], [[10.0.0-27|v21288]], [[10.2.0-28|v22313]], [[10.4.0-29|v23341]], [[11.0.0-33|v24368]], [[11.1.0-34|v25396]], [[11.2.0-35|v26432]], [[11.3.0-36|v27476]]&lt;br /&gt;
| Same as USA/EUR/JPN starting with the USA/EUR/JPN [[4.0.0-7]] title-version&lt;br /&gt;
| Same as CHN.&lt;br /&gt;
| Same as CHN.&lt;br /&gt;
|-&lt;br /&gt;
| 20000002&lt;br /&gt;
| [[New_3DS]] NATIVE_FIRM (Native Firmware)&lt;br /&gt;
| [[8.1.0-0_New3DS|v16085]], [[9.0.0-20|v17120]], [[9.3.0-21|v18182]], [[9.5.0-22|v19218]], [[9.6.0-24|v20262]], [[10.0.0-27|v21288]], [[10.2.0-28|v22313]], [[10.4.0-29|v23341]], [[11.0.0-33|v24368]], [[11.1.0-34|v25396]], [[11.2.0-35|v26432]], [[11.3.0-36|v27476]]&lt;br /&gt;
| N/A&lt;br /&gt;
| Same as CHN.&lt;br /&gt;
| Same as CHN.&lt;br /&gt;
|-&lt;br /&gt;
| 00000003&lt;br /&gt;
| SAFE_MODE_FIRM &lt;br /&gt;
| [[1.0.0-0|v432]], [[3.0.0-5|v5632]]&lt;br /&gt;
| Same as USA/EUR/JPN starting with the USA/EUR/JPN [[3.0.0-5]] title-version&lt;br /&gt;
| Same as CHN.&lt;br /&gt;
| Same as CHN.&lt;br /&gt;
|-&lt;br /&gt;
| 20000003&lt;br /&gt;
| [[New_3DS]] SAFE_MODE_FIRM &lt;br /&gt;
| [[8.1.0-0_New3DS|v16081]]&lt;br /&gt;
| N/A&lt;br /&gt;
| Same as CHN.&lt;br /&gt;
| Same as CHN.&lt;br /&gt;
|-&lt;br /&gt;
| 00000102 &lt;br /&gt;
| TWL_FIRM ( DSi Firmware )&lt;br /&gt;
| [[1.0.0-0|v432]], [[2.0.0-2|v1489]], [[3.0.0-5|v2565]], v3601, [[4.0.0-7|v4625]], [[4.4.0-10|v5681]], [[4.5.0-10|v6704]], [[6.0.0-11|v7762]], [[6.2.0-12|v8817]]&lt;br /&gt;
| Same as USA/EUR/JPN starting with the USA/EUR/JPN [[4.0.0-7]] title-version&lt;br /&gt;
| Same as CHN.&lt;br /&gt;
| Same as CHN.&lt;br /&gt;
|-&lt;br /&gt;
| 20000102 &lt;br /&gt;
| [[New_3DS]] TWL_FIRM ( DSi Firmware )&lt;br /&gt;
| [[8.1.0-0_New3DS|v9936]]&lt;br /&gt;
| N/A&lt;br /&gt;
| Same as CHN.&lt;br /&gt;
| Same as CHN.&lt;br /&gt;
|- &lt;br /&gt;
| 00000202&lt;br /&gt;
| AGB_FIRM ( GBA Firmware )&lt;br /&gt;
| [[3.0.0-5|v519]], v1553, [[4.0.0-7|v2576]], [[6.0.0-11|v3665]]&lt;br /&gt;
| [[4.0.0-7|v2576]]&lt;br /&gt;
| [[4.0.0-7|v2576]], [[6.0.0-11|v3665]]&lt;br /&gt;
| Same as CHN.&lt;br /&gt;
|- &lt;br /&gt;
| 20000202&lt;br /&gt;
| [[New_3DS]] AGB_FIRM ( GBA Firmware )&lt;br /&gt;
| [[8.1.0-0_New3DS|v4816]]&lt;br /&gt;
| N/A&lt;br /&gt;
| N/A&lt;br /&gt;
| N/A&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
== Application Titles ==&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot; border=&amp;quot;1&amp;quot;&lt;br /&gt;
|-&lt;br /&gt;
!  Content Category&lt;br /&gt;
!  Bit Mask(s)&lt;br /&gt;
!  Category Bit Mask&lt;br /&gt;
|-&lt;br /&gt;
|  [[Title list/eShop Titles|Application]] (eShop Title)&lt;br /&gt;
|  Normal&lt;br /&gt;
|  0x0000&lt;br /&gt;
|-&lt;br /&gt;
|  DLP Child&lt;br /&gt;
|  DlpChild&lt;br /&gt;
|  0x0001&lt;br /&gt;
|-&lt;br /&gt;
|  [[EShop Demos|Demo]]&lt;br /&gt;
|  Demo&lt;br /&gt;
|  0x0002&lt;br /&gt;
|-&lt;br /&gt;
|  [[Title list/Patches|Patch]]&lt;br /&gt;
|  CannotExecution&amp;lt;nowiki&amp;gt;|&amp;lt;/nowiki&amp;gt;Patch&lt;br /&gt;
|  0x000E&lt;br /&gt;
|-&lt;br /&gt;
|  [[Title list/DLC|Add-on Content]] (DLC)&lt;br /&gt;
|  NotRequireRightForMount&amp;lt;nowiki&amp;gt;|&amp;lt;/nowiki&amp;gt;CannotExecution&amp;lt;nowiki&amp;gt;|&amp;lt;/nowiki&amp;gt;AddOnContents&lt;br /&gt;
|  0x008C&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
=== 00040001 - [[Download Play]] Titles ===&lt;br /&gt;
This titleID-high/programID-high is used for the titles sent over [[Download Play]]. Only one 00040001 Download Play title is installed to NAND /title at a time. There can be a maximum of 255 Download Play child titles per Unique ID, indexed by Title ID Variation. The legal index range: 0x0 - 0xff.&lt;br /&gt;
&lt;br /&gt;
== Other Titles ==&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot; border=&amp;quot;1&amp;quot;&lt;br /&gt;
|-&lt;br /&gt;
!  TitleID&lt;br /&gt;
!  Description&lt;br /&gt;
!  Versions&lt;br /&gt;
|-&lt;br /&gt;
| 000400000F802A00&lt;br /&gt;
| Unknown. Appears to be a [[9.8.0-25|gamecard]] title. See also [[11.3.0-36|here]].&lt;br /&gt;
Used during [[Nintendo_Service_Center_Tools|repair]], first non-system title listed in [[PTM_Services|playlog]] from repair.&lt;br /&gt;
| &lt;br /&gt;
|-&lt;br /&gt;
| 000400000F802100&lt;br /&gt;
| Used during [[Nintendo_Service_Center_Tools|repair]], second non-system title listed in [[PTM_Services|playlog]] from repair.&lt;br /&gt;
| &lt;br /&gt;
|-&lt;br /&gt;
| 000400000F802200&lt;br /&gt;
| Used during [[Nintendo_Service_Center_Tools|repair]], third non-system title listed in [[PTM_Services|playlog]] from repair.&lt;br /&gt;
| &lt;br /&gt;
|-&lt;br /&gt;
| 0004003000008900&lt;br /&gt;
|  Used by retail NS for appID 0xF10, but this isn&#039;t available on retail CDN.&lt;br /&gt;
| ?&lt;br /&gt;
|-&lt;br /&gt;
| 000400000FFFFD00&lt;br /&gt;
|  Used by retail NS for appID 0xF11, but this isn&#039;t available on retail CDN.&lt;br /&gt;
| ?&lt;br /&gt;
|-&lt;br /&gt;
| 000400000FFFFC00&lt;br /&gt;
|  Used by retail NS for appID 0xF12, but this isn&#039;t available on retail CDN.&lt;br /&gt;
| ?&lt;br /&gt;
|-&lt;br /&gt;
| 000400000FFFFB00&lt;br /&gt;
|  Used by retail NS for appID 0xF13, but this isn&#039;t available on retail CDN.&lt;br /&gt;
| ?&lt;br /&gt;
|-&lt;br /&gt;
| 000400000FFFF900&lt;br /&gt;
|  Used by retail NS for appID 0xF14, but this isn&#039;t available on retail CDN.&lt;br /&gt;
| ?&lt;br /&gt;
|-&lt;br /&gt;
| 000400000FFFF800&lt;br /&gt;
|  Used by retail NS for appID 0xF15, but this isn&#039;t available on retail CDN.&lt;br /&gt;
| ?&lt;br /&gt;
|-&lt;br /&gt;
| 000400000FFFF700&lt;br /&gt;
|  Used by retail NS for appID 0xF16, but this isn&#039;t available on retail CDN.&lt;br /&gt;
| ?&lt;br /&gt;
|-&lt;br /&gt;
| 000400000FFFF600&lt;br /&gt;
|  Used by retail NS for appID 0xF17, but this isn&#039;t available on retail CDN.&lt;br /&gt;
| ?&lt;br /&gt;
|-&lt;br /&gt;
| 000400000FFFF500&lt;br /&gt;
|  Used by retail NS for appID 0xF18, but this isn&#039;t available on retail CDN.&lt;br /&gt;
| ?&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
This section is for hard-coded titleIDs referenced in codebins on retail. This can include [[Factory_Setup|factory]]/[[Nintendo_Service_Center_Tools|repair]] titles as well.&lt;br /&gt;
&lt;br /&gt;
== TWL (DSi) Titles ==&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot; border=&amp;quot;1&amp;quot;&lt;br /&gt;
|-&lt;br /&gt;
!  Content Category&lt;br /&gt;
!  Bit Mask(s)&lt;br /&gt;
!  Category Bit Mask&lt;br /&gt;
|-&lt;br /&gt;
|  Application (DSiWare)&lt;br /&gt;
|  TWL&amp;lt;nowiki&amp;gt;|&amp;lt;/nowiki&amp;gt;0x4&lt;br /&gt;
|  0x8004&lt;br /&gt;
|-&lt;br /&gt;
|  System Application&lt;br /&gt;
|  TWL&amp;lt;nowiki&amp;gt;|&amp;lt;/nowiki&amp;gt;0x1&amp;lt;nowiki&amp;gt;|&amp;lt;/nowiki&amp;gt;0x4&lt;br /&gt;
|  0x8005&lt;br /&gt;
|-&lt;br /&gt;
|  System Archive&lt;br /&gt;
|  TWL&amp;lt;nowiki&amp;gt;|&amp;lt;/nowiki&amp;gt;0x1&amp;lt;nowiki&amp;gt;|&amp;lt;/nowiki&amp;gt;0x2&amp;lt;nowiki&amp;gt;|&amp;lt;/nowiki&amp;gt;0x4&amp;lt;nowiki&amp;gt;|&amp;lt;/nowiki&amp;gt;0x8&lt;br /&gt;
|  0x800F&lt;br /&gt;
|-&lt;br /&gt;
|  Developer Tool&lt;br /&gt;
|  TWL&amp;lt;nowiki&amp;gt;|&amp;lt;/nowiki&amp;gt;0x1&amp;lt;nowiki&amp;gt;|&amp;lt;/nowiki&amp;gt;0x4&amp;lt;nowiki&amp;gt;|&amp;lt;/nowiki&amp;gt;0x10&lt;br /&gt;
|  0x8015&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
Bitmask 0x1 for TWL titles denotes a system title (determining whether the title will be updated during a System Update). It appears to be sufficient, but not necessary, to make the title invisible on the [[Home Menu]].&lt;br /&gt;
&lt;br /&gt;
Bitmask 0x2 for TWL titles may indicate no-execute.&lt;br /&gt;
&lt;br /&gt;
Bitmask 0x4 for TWL titles indicates internal storage.&lt;br /&gt;
&lt;br /&gt;
Bitmask 0x10 for TWL titles is found on developer tools.&lt;br /&gt;
&lt;br /&gt;
=== 00048005 - System Applications===&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot; border=&amp;quot;1&amp;quot;&lt;br /&gt;
|-&lt;br /&gt;
!  TitleID Low&lt;br /&gt;
!  Region&lt;br /&gt;
!  Description&lt;br /&gt;
!  Versions&lt;br /&gt;
!  Information&lt;br /&gt;
|-&lt;br /&gt;
| 42383841(B88A)&lt;br /&gt;
| ALL&lt;br /&gt;
| [[DS Internet]]&lt;br /&gt;
| v0, [[2.1.0-4|v1025]], [[3.0.0-5|v2048]]&lt;br /&gt;
| [[DS Internet]] is the DS-mode application, (also integrated in every online-enabled DS game) and now accessible through [[System Settings]] for configuring network settings for DS software. &lt;br /&gt;
|-&lt;br /&gt;
| 484E4441(HNDA)&lt;br /&gt;
| ALL&lt;br /&gt;
| [[Download Play]]&lt;br /&gt;
| v1024&lt;br /&gt;
| This [[Download Play]] application is the DS-mode Download Play client, launched by the 3DS-mode Download Play application.&lt;br /&gt;
|-&lt;br /&gt;
| 484E4443(HNDC)&lt;br /&gt;
| CHN&lt;br /&gt;
| [[Download Play]]&lt;br /&gt;
| v1024&lt;br /&gt;
| See Above Description.&lt;br /&gt;
|-&lt;br /&gt;
| 484E444B(HNDK)&lt;br /&gt;
| KOR&lt;br /&gt;
| [[Download Play]]&lt;br /&gt;
| v1024&lt;br /&gt;
| See Above Description.&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
=== 0004800F - System Data Archives===&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot; border=&amp;quot;1&amp;quot;&lt;br /&gt;
|-&lt;br /&gt;
!  TitleID Low&lt;br /&gt;
!  Description&lt;br /&gt;
!  Versions&lt;br /&gt;
|-&lt;br /&gt;
| 484E4841(HNHA)&lt;br /&gt;
| [[Nintendo DS Cart Whitelist]]&lt;br /&gt;
| v0, [[2.0.0-2|v1026]], [[2.2.0-X|v2048]], [[3.0.0-5|v3072]], [[4.0.0-7|v4096]], [[4.2.0-9|v5120]], [[4.3.0-10|v6145]], [[4.4.0-10|v7168]], [[4.5.0-10|v8192]], [[5.0.0-11|v9216]], [[6.0.0-11|v10240]], [[7.0.0-13|v11264]]&lt;br /&gt;
|-&lt;br /&gt;
| 484E4C41(HNLA)&lt;br /&gt;
| [[Version Data]]&lt;br /&gt;
| v0&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
New system updates only block DS flash-cards when the above whitelist was updated, or when TWL_FIRM was updated. The whitelist contains the data used for detecting flash-cards, this is used by TWL_FIRM.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== 00048004 - DSiWare ===&lt;br /&gt;
Although these have a titleID high separate from DSi and a titleID is stored in the SRLs, the content of these SRLs are identical to DSi.&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot; border=&amp;quot;1&amp;quot;&lt;br /&gt;
|-&lt;br /&gt;
!  TitleID Low&lt;br /&gt;
!  Region&lt;br /&gt;
!  Description&lt;br /&gt;
!  Versions&lt;br /&gt;
|-&lt;br /&gt;
| 4B4B5456(KKTV)&lt;br /&gt;
| EUR&lt;br /&gt;
| Cut the Rope&lt;br /&gt;
| v0, v64&lt;br /&gt;
|-&lt;br /&gt;
| 4B4E5256(KNRV)&lt;br /&gt;
| EUR&lt;br /&gt;
| A Little Bit of... Brain Training™: Maths Edition &lt;br /&gt;
| v0&lt;br /&gt;
|-&lt;br /&gt;
| 4B5A4C56(KZLV)&lt;br /&gt;
| EUR&lt;br /&gt;
| Plants vs. Zombies™&lt;br /&gt;
| v0&lt;br /&gt;
|-&lt;br /&gt;
| 4B454256(KEBV)&lt;br /&gt;
| EUR&lt;br /&gt;
| ELECTROPLANKTON (Hanenbow)&lt;br /&gt;
| v0&lt;br /&gt;
|-&lt;br /&gt;
| 4B513956(KQ9V)&lt;br /&gt;
| EUR&lt;br /&gt;
| Zelda: Four Swords Anniversary Edition&lt;br /&gt;
| v16&lt;br /&gt;
|-&lt;br /&gt;
| 4B574256(KWBV)&lt;br /&gt;
| EUR&lt;br /&gt;
| Mario Calculator &lt;br /&gt;
| v0&lt;br /&gt;
|-&lt;br /&gt;
| 4B574656(KWFV)&lt;br /&gt;
| EUR&lt;br /&gt;
| Mario Clock &lt;br /&gt;
| v0&lt;br /&gt;
|}&lt;/div&gt;</summary>
		<author><name>Motezazer</name></author>
	</entry>
	<entry>
		<id>https://www.3dbrew.org/w/index.php?title=FIRM&amp;diff=19160</id>
		<title>FIRM</title>
		<link rel="alternate" type="text/html" href="https://www.3dbrew.org/w/index.php?title=FIRM&amp;diff=19160"/>
		<updated>2017-01-05T17:06:58Z</updated>

		<summary type="html">&lt;p&gt;Motezazer: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;This page describes the file format for the [[Title list#00040138 - System Firmware|3DS&#039; Firmware]], it contains up to four &#039;sections&#039; of data comprising the ARM9 and ARM11 kernels, and some fundamental processes. The firmware sections are not encrypted. In a nutshell, a FIRM contains all the data required to set up the ARM9 and ARM11 kernels, and basic operating functionality.&lt;br /&gt;
&lt;br /&gt;
The ARM9 section contains the ARM9 kernel (and loader) and the Process9 NCCH (which is the only process run in user mode on the ARM9). The ARM11 sections contain the ARM11 kernel (and loader), and various ARM11 process NCCHs. For NATIVE_FIRM/SAFE_MODE_FIRM these ARM11 processes are sm, fs, pm, loader, and pxi. Normally the 4th section is not used. The code loaded from FIRM is constantly running on the system until another FIRM is launched. The ARM11 kernel is hard-coded to always decompress the ExeFS .code of embedded ARM11 NCCHs without checking the exheader compression bit.&lt;br /&gt;
&lt;br /&gt;
== FIRM Header ==&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot; border=&amp;quot;1&amp;quot;&lt;br /&gt;
|-&lt;br /&gt;
!  OFFSET&lt;br /&gt;
!  SIZE&lt;br /&gt;
!  DESCRIPTION&lt;br /&gt;
|-&lt;br /&gt;
|  0x000&lt;br /&gt;
|  4&lt;br /&gt;
|  Magic &#039;FIRM&#039;&lt;br /&gt;
|-&lt;br /&gt;
|  0x004&lt;br /&gt;
|  4&lt;br /&gt;
|  Boot priority (highest value = max prio), this is normally zero.&lt;br /&gt;
|-&lt;br /&gt;
|  0x008&lt;br /&gt;
|  4&lt;br /&gt;
|  ARM11 Entrypoint&lt;br /&gt;
|-&lt;br /&gt;
|  0x00C&lt;br /&gt;
|  4&lt;br /&gt;
|  ARM9 Entrypoint&lt;br /&gt;
|-&lt;br /&gt;
|  0x010&lt;br /&gt;
|  0x030&lt;br /&gt;
|  Reserved&lt;br /&gt;
|-&lt;br /&gt;
|  0x040&lt;br /&gt;
|  0x0C0 (0x030*4)&lt;br /&gt;
|  Firmware Section Headers&lt;br /&gt;
|-&lt;br /&gt;
|  0x100&lt;br /&gt;
|  0x100&lt;br /&gt;
|  RSA-2048 signature of the FIRM header&#039;s SHA-256 hash. The signature is checked when bootrom/Process9 are doing FIRM-launch (with the public key being hardcoded in each). The signature is not checked when installing FIRM to the NAND firm0/firm1 partitions.&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
== Firmware Section Headers ==&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot; border=&amp;quot;1&amp;quot;&lt;br /&gt;
|-&lt;br /&gt;
!  OFFSET&lt;br /&gt;
!  SIZE&lt;br /&gt;
!  DESCRIPTION&lt;br /&gt;
|-&lt;br /&gt;
|  0x000&lt;br /&gt;
|  4&lt;br /&gt;
|  Byte offset&lt;br /&gt;
|-&lt;br /&gt;
|  0x004&lt;br /&gt;
|  4&lt;br /&gt;
|  Physical address where the section is loaded to.&lt;br /&gt;
|-&lt;br /&gt;
|  0x008&lt;br /&gt;
|  4&lt;br /&gt;
|  Byte-size.  While loading FIRM this is the field used to determine whether the section exists or not, by checking for value 0x0.&lt;br /&gt;
|-&lt;br /&gt;
|  0x00C&lt;br /&gt;
|  4&lt;br /&gt;
|  Copy-method (0 = NDMA, 1 = XDMA, 2 = CPU mem-copy), Process9 ignores this field.&lt;br /&gt;
|-&lt;br /&gt;
|  0x010&lt;br /&gt;
|  0x020&lt;br /&gt;
|  SHA-256 Hash of Firmware Section&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
== [[New_3DS]] FIRM ==&lt;br /&gt;
For New3DS firmwares (NATIVE_FIRM, TWL_FIRM, ..), the ARM9 FIRM binary has an additional layer of crypto. At the end of each ARM9 binary, there&#039;s a plaintext loader. The format of the FIRM header is identical to regular 3DS FIRM(the RSA modulo is the same as regular 3DS too).&lt;br /&gt;
&lt;br /&gt;
Before checking [[CONFIG_Registers|CFG_SYSPROT9]] the loader main() does the following:&lt;br /&gt;
* On [[9.5.0-22|9.5.0-X]]: executes a nop instruction with r0=0 and r1=&amp;lt;address of arm9binhdr+0x50&amp;gt;.&lt;br /&gt;
* Clears bit6 in [[AES_Registers|REG_AESKEYCNT]].&lt;br /&gt;
&lt;br /&gt;
If [[CONFIG_Registers#CFG_SYSPROT9|CFG_SYSPROT9]] bit 1 is clear (which means the OTP area is unlocked and so it knows that this is a hard reboot), it does the following things:&lt;br /&gt;
* Clears 0x200-bytes on the stack, then reads [[Flash_Filesystem|NAND]] sector 0x96(NAND image offset 0x12C00), with size 0x200-bytes into that stack buffer.&lt;br /&gt;
* Checks [[CONFIG_Registers#CFG_SYSPROT9|CFG_SYSPROT9]] bit 1 again, if it&#039;s set then it executes a panic function(set r0-r2=0, execute nop instruction, then execute instruction &amp;quot;bkpt 0x99&amp;quot;).&lt;br /&gt;
* Hashes data from the OTP region [[IO_Registers|0x10012000-0x10012090]] using SHA256 via the [[SHA_Registers|SHA]] hardware.&lt;br /&gt;
* Clears bit6 in [[AES_Registers|REG_AESKEYCNT]]. Initializes AES keyslot 0x11 keyX, keyY to the lower and higher portion of the above hash, respectively. Due to the above hashed data, the keyX+keyY here are console-unique.&lt;br /&gt;
* Decrypts the first 0x10-byte block in the above read NAND sector with keyslot 0x11 using AES-ECB. [[9.6.0-24|9.6.0-X]]: Then it decrypts the 0x10-bytes at offset 0x10 in the sector with keyslot 0x11.&lt;br /&gt;
* Then the normalkey, keyX, and keyY, for keyslot 0x11 are cleared to zero. Runs the TWL key-init/etc code which was originally in the ARM9-kernel, then writes 0x2 to [[CONFIG_Registers|CFG_SYSPROT9]] to disable the OTP area.&lt;br /&gt;
* Then it uses the above decrypted block from sector+0 to set the normalkey for keyslot 0x11. Decrypts arm9_bin_buf+0 using keyslot 0x11 with AES-ECB, and initialises keyX for keyslot 0x15 with it.&lt;br /&gt;
* [[9.6.0-24|9.6.0-X]]: Then it uses the above decrypted block from sector+0 to set the normalkey for keyslot 0x11. Decrypts a 0x10-byte block from arm9loader .(ro)data using keyslot 0x11 with AES-ECB, and initializes keyX for keyslot 0x18 with it(same block as previous versions).&lt;br /&gt;
* [[9.6.0-24|9.6.0-X]]: Starting with this version keyslot 0x16 keyX init was moved here, see below for details on this. The code for this is same as  [[9.5.0-22|9.5.0-X]], except the decrypted normalkey from sector+0x10 is used for keyslot 0x11 instead.&lt;br /&gt;
* Initialises KeyX for keyslots 0x18..0x1F(0x19..0x1F with [[9.6.0-24|9.6.0-X]]) with the output of decrypting a 0x10-byte block with AES-ECB using keyslot 0x11. This block was changed to a new one separate from keyslot 0x18, starting with [[9.6.0-24|9.6.0-X]]. The last byte in this 0x10-byte input block is increased by 0x01 after initializing each keyslot. Before doing the crypto each time, the loader sets the normal-key for keyslot 0x11 to the plaintext normalkey from sector+0(+0x10 with [[9.6.0-24|9.6.0-X]]). These are New3DS-specific keys.&lt;br /&gt;
* [[9.5.0-22|9.5.0-X]](moved to above with [[9.6.0-24|9.6.0-X]]): Sets the normal-key for keyslot 0x11 to the same one already decrypted on the stack. Decrypts the 0x10-byte block at arm9binhdr+0x60 with AES-ECB using keyslot 0x11, then sets the keyX for keyslot 0x16 to the output data.&lt;br /&gt;
* [[9.5.0-22|9.5.0-X]]: The normalkey, keyX, and keyY, for keyslot 0x11 are then cleared to zero.&lt;br /&gt;
&lt;br /&gt;
When [[CONFIG_Registers#CFG_SYSPROT9|CFG_SYSPROT9]] bit 1 is set(which means this happens only when this loader runs again for firm-launch), the normalkey, keyX, and keyY, for keyslot 0x11 are cleared to zero.&lt;br /&gt;
&lt;br /&gt;
It sets KeyY for keyslot 0x15(0x16 with [[9.5.0-22|9.5.0-X]]) to arm9_bin_buf+16, the CTR to arm9_bin_buf+32 (both are unique for every version). It then proceeds to decrypt the binary with AES-CTR. When done, it sets the normal-key for the keyslot used for binary decryption to zeros. It then decrypts arm9_bin_buf+64 using an hardcoded keyY for keyslot 0x15([[9.5.0-22|9.5.0-X]]/[[9.6.0-24|9.6.0-X]] also uses keyslot 0x15), sets the normal-key for this keyslot to zeros again, then makes sure the output block is all zeroes. If it is, it does some cleanup then it jumps to the entrypoint for the decrypted binary. Otherwise it will clear the keyX, keyY, and normal-key for each of the keyslots initialized by this loader (on [[9.6.0-24|9.6.0-X]]+, on older versions this was bugged and cleared keys 0x00..0x07 instead of 0x18..0x1F), do cleanup(same cleanup as when the decrypted block is all-zero) then just loop forever.&lt;br /&gt;
&lt;br /&gt;
Thus, the ARM9 binary has the following header:&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot; border=&amp;quot;1&amp;quot;&lt;br /&gt;
|-&lt;br /&gt;
!  OFFSET&lt;br /&gt;
!  SIZE&lt;br /&gt;
!  DESCRIPTION&lt;br /&gt;
|-&lt;br /&gt;
|  0x000&lt;br /&gt;
|  16&lt;br /&gt;
|  Encrypted KeyX (same for all FIRM&#039;s)&lt;br /&gt;
|-&lt;br /&gt;
|  0x010&lt;br /&gt;
|  16&lt;br /&gt;
|  KeyY&lt;br /&gt;
|-&lt;br /&gt;
|  0x020&lt;br /&gt;
|  16&lt;br /&gt;
|  CTR&lt;br /&gt;
|-&lt;br /&gt;
|  0x030&lt;br /&gt;
|  8&lt;br /&gt;
|  Size of encrypted binary, as ASCII text?&lt;br /&gt;
|-&lt;br /&gt;
|  0x038&lt;br /&gt;
|  8&lt;br /&gt;
|  ?&lt;br /&gt;
|-&lt;br /&gt;
|  0x040&lt;br /&gt;
|  16&lt;br /&gt;
|  Control block&lt;br /&gt;
|-&lt;br /&gt;
|  0x050&lt;br /&gt;
|  16&lt;br /&gt;
|  Added with [[9.5.0-22|9.5.0-X]]. Only used for hardware debugging: a nop instruction is executed with r0=0 and r1=&amp;lt;address of this data&amp;gt;.&lt;br /&gt;
|-&lt;br /&gt;
|  0x060&lt;br /&gt;
|  16&lt;br /&gt;
|  Added with [[9.5.0-22|9.5.0-X]]. Encrypted keyX for keyslot 0x16.&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
Originally the padding after the header before offset 0x800(start of actual ARM9-binary) was 0xFF bytes, with [[9.5.0-22|9.5.0-X]] this was changed to 0x0.&lt;br /&gt;
&lt;br /&gt;
For the New3DS NATIVE_FIRM arm9-section header, the only difference between the [[8.1.0-0_New3DS]] version and the [[9.0.0-20]] version is that the keyY, CTR, and the block at 0x30 in the header were updated.&lt;br /&gt;
&lt;br /&gt;
===New3DS ARM9 binary loader versions===&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot; border=&amp;quot;1&amp;quot;&lt;br /&gt;
|-&lt;br /&gt;
!  FIRM system version(s)&lt;br /&gt;
!  Description&lt;br /&gt;
|-&lt;br /&gt;
| [[8.1.0-0_New3DS]] - [[9.3.0-21|9.3.0-X]]&lt;br /&gt;
| Initial version.&lt;br /&gt;
|-&lt;br /&gt;
| [[9.5.0-22|9.5.0-X]]&lt;br /&gt;
| Added keyX initialization for keyslot 0x16(see above), and added code for clearing keyslot 0x11 immediately after the code finishes using keyslot 0x11. The keyslot used for arm9bin decryption was changed from 0x15 to 0x16. Added code for clearing keyslot 0x16 when control-block decryption fails. Added code for using arm9bin_hdr+0x50 with a nop instruction, at the very beginning of the main arm9-loader function. Added two new 0x10-blocks to the arm9bin-hdr.&lt;br /&gt;
|-&lt;br /&gt;
| [[9.6.0-24|9.6.0-X]] - [[11.2.0-35|11.2.0-X]]&lt;br /&gt;
| See above and [[9.6.0-24|here]].&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
===New3DS ARM9 kernel===&lt;br /&gt;
The only actual code-difference for the Old3DS/New3DS ARM9-kernels&#039; crt0, besides TWL AES / [[IO_Registers|0x10012000]] related code, is that the New3DS ARM9-kernel writes 0x1 to [[CONFIG_Registers|REG_EXTMEMCNT9]] in the crt0.&lt;br /&gt;
&lt;br /&gt;
===New3DS Process9===&lt;br /&gt;
The following is all of the differences for Old3DS/New3DS Process9 with [[9.3.0-21|9.3.0-X]]:&lt;br /&gt;
* The FIRM-launch code called at the end of the New3DS proc9 main() has different mem-range checks.&lt;br /&gt;
* In the New3DS proc9, the v6.0/v7.0 keyinit function at the very beginning(before the original code) had additional code added for setting [[Flash_Filesystem|CTRNAND]] [[AES_Registers|keyslot]] 0x5, with keydata from .data. After setting the keyY, the keyY in .data is cleared.&lt;br /&gt;
* In New3DS proc9, the functions for getting the gamecard crypto keyslots / NCCH keyslot can return New3DS keyslots when New3DS flags(NCSD/NCCH) are set.&lt;br /&gt;
* The code/data for the binary near the end of arm9mem is slightly different, because of memory-region sizes.&lt;br /&gt;
* The only difference in .data(besides the above code binary) is that the New3DS proc9 has an additional 0x10-byte block for the keyslot 0x5 keyY, see above.&lt;br /&gt;
&lt;br /&gt;
== Variations ==&lt;br /&gt;
There exists different official firmwares for the 3DS: The default one (NATIVE_FIRM) is used to run all 3DS content and boots by default, while backwards compatibility is handled by TWL_FIRM and AGB_FIRM. There furthermore is a rescue mode provided by SAFE_MODE_FIRM.&lt;br /&gt;
&lt;br /&gt;
=== NATIVE_FIRM ===&lt;br /&gt;
NATIVE_FIRM is the FIRM which is installed to the [[Flash_Filesystem|NAND]] firm partitions, which is loaded by bootrom.&lt;br /&gt;
&lt;br /&gt;
Version history:&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot; border=&amp;quot;1&amp;quot;&lt;br /&gt;
!  System version&lt;br /&gt;
!  old 3DS title version&lt;br /&gt;
!  old 3DS hex title contentID&lt;br /&gt;
!  Kernel/FIRM version (old 3DS/new 3DS)&lt;br /&gt;
|-&lt;br /&gt;
| [[Factory_Setup|Factory]] FIRM (titleID 00040001-00000002)&lt;br /&gt;
| v0&lt;br /&gt;
| 00&lt;br /&gt;
| 2.3-0&lt;br /&gt;
|-&lt;br /&gt;
| Pre-1.0. Referenced in the v1.0 Home Menu NCCH plain-region.&lt;br /&gt;
| &lt;br /&gt;
| &lt;br /&gt;
| 2.23-X&lt;br /&gt;
|-&lt;br /&gt;
| [[1.0.0-0|1.0.0]]&lt;br /&gt;
| v432&lt;br /&gt;
| 00&lt;br /&gt;
| 2.27-0&lt;br /&gt;
|-&lt;br /&gt;
| [[1.1.0-1|1.1.0]]&lt;br /&gt;
| v1472&lt;br /&gt;
| 02&lt;br /&gt;
| 2.28-0&lt;br /&gt;
|-&lt;br /&gt;
| [[2.0.0-2|2.0.0]]&lt;br /&gt;
| v2516&lt;br /&gt;
| 09&lt;br /&gt;
| 2.29-7&lt;br /&gt;
|-&lt;br /&gt;
| [[2.1.0-3|2.1.0]]&lt;br /&gt;
| v3553&lt;br /&gt;
| 0B&lt;br /&gt;
| 2.30-18&lt;br /&gt;
|-&lt;br /&gt;
| [[2.2.0-X|2.2.0]]&lt;br /&gt;
| v4595&lt;br /&gt;
| 0F&lt;br /&gt;
| 2.31-40&lt;br /&gt;
|-&lt;br /&gt;
| [[3.0.0-5|3.0.0]]&lt;br /&gt;
| v5647&lt;br /&gt;
| 18&lt;br /&gt;
| 2.32-15&lt;br /&gt;
|-&lt;br /&gt;
| [[4.0.0-7|4.0.0]]&lt;br /&gt;
| v6677&lt;br /&gt;
| 1D&lt;br /&gt;
| 2.33-4&lt;br /&gt;
|-&lt;br /&gt;
| [[4.1.0-8|4.1.0]]&lt;br /&gt;
| v7712&lt;br /&gt;
| 1F&lt;br /&gt;
| 2.34-0&lt;br /&gt;
|-&lt;br /&gt;
| [[5.0.0-11|5.0.0]]&lt;br /&gt;
| v8758&lt;br /&gt;
| 25&lt;br /&gt;
| 2.35-6&lt;br /&gt;
|-&lt;br /&gt;
| [[5.1.0-11|5.1.0]]&lt;br /&gt;
| v9792&lt;br /&gt;
| 26&lt;br /&gt;
| 2.36-0&lt;br /&gt;
|-&lt;br /&gt;
| [[6.0.0-11|6.0.0]]&lt;br /&gt;
| v10833&lt;br /&gt;
| 29&lt;br /&gt;
| 2.37-0&lt;br /&gt;
|-&lt;br /&gt;
| [[6.1.0-11|6.1.0]]&lt;br /&gt;
| v11872&lt;br /&gt;
| 2A&lt;br /&gt;
| 2.38-0&lt;br /&gt;
|-&lt;br /&gt;
| [[7.0.0-13|7.0.0]]&lt;br /&gt;
| v12916&lt;br /&gt;
| 2E&lt;br /&gt;
| 2.39-4&lt;br /&gt;
|-&lt;br /&gt;
| [[7.2.0-17|7.2.0]]&lt;br /&gt;
| v13956&lt;br /&gt;
| 30&lt;br /&gt;
| 2.40-0&lt;br /&gt;
|-&lt;br /&gt;
| [[8.0.0-18|8.0.0]]&lt;br /&gt;
| v15047&lt;br /&gt;
| 37&lt;br /&gt;
| 2.44-6&lt;br /&gt;
|-&lt;br /&gt;
| [[8.1.0-0_New3DS]]&lt;br /&gt;
|N/A&lt;br /&gt;
|N/A&lt;br /&gt;
| 2.45-5&lt;br /&gt;
|-&lt;br /&gt;
| [[9.0.0-20|9.0.0]]&lt;br /&gt;
| v17120&lt;br /&gt;
| 38&lt;br /&gt;
| 2.46-0&lt;br /&gt;
|-&lt;br /&gt;
| [[9.3.0-21|9.3.0]]&lt;br /&gt;
| v18182&lt;br /&gt;
| 3F&lt;br /&gt;
| 2.48-3&lt;br /&gt;
|-&lt;br /&gt;
| [[9.5.0-22|9.5.0]]&lt;br /&gt;
| v19216&lt;br /&gt;
| 40&lt;br /&gt;
| 2.49-0&lt;br /&gt;
|-&lt;br /&gt;
| [[9.6.0-24|9.6.0]]&lt;br /&gt;
| v20262&lt;br /&gt;
| 49&lt;br /&gt;
| 2.50-1&lt;br /&gt;
|-&lt;br /&gt;
| [[10.0.0-27|10.0.0]]&lt;br /&gt;
| v21288&lt;br /&gt;
| 4B&lt;br /&gt;
| 2.50-7&lt;br /&gt;
|-&lt;br /&gt;
| [[10.2.0-28|10.2.0]]&lt;br /&gt;
| v22313&lt;br /&gt;
| 4C&lt;br /&gt;
| 2.50-9&lt;br /&gt;
|-&lt;br /&gt;
| [[10.4.0-29|10.4.0]]&lt;br /&gt;
| v23341&lt;br /&gt;
| 50&lt;br /&gt;
| 2.50-11&lt;br /&gt;
|-&lt;br /&gt;
| [[11.0.0-33|11.0.0]]&lt;br /&gt;
| v24368&lt;br /&gt;
| 52&lt;br /&gt;
| 2.51-0&lt;br /&gt;
|-&lt;br /&gt;
| [[11.1.0-34|11.1.0]]&lt;br /&gt;
| v25396&lt;br /&gt;
| 56&lt;br /&gt;
| 2.51-2&lt;br /&gt;
|-&lt;br /&gt;
| [[11.2.0-35|11.2.0]]&lt;br /&gt;
| v26432&lt;br /&gt;
| 58&lt;br /&gt;
| 2.52-0&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
The above kernel/FIRM versions are in the format: &amp;lt;KERNEL_VERSIONMAJOR&amp;gt;.&amp;lt;KERNEL_VERSIONMINOR&amp;gt;-&amp;lt;KERNEL_VERSIONREVISION&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
=== SAFE_MODE_FIRM ===&lt;br /&gt;
SAFE_MODE is used for running the [[System_Settings#System_Updater|System Updater]]. SAFE_MODE_FIRM and NATIVE_FIRM for the initial versions are exactly the same, except for the system core version fields.&lt;br /&gt;
&lt;br /&gt;
=== TWL_FIRM ===&lt;br /&gt;
TWL_FIRM handles DS(i) backwards compatibility.&lt;br /&gt;
&lt;br /&gt;
The 3DS-mode ARM9 core seems to switch into DSi-mode(for running DSi-mode ARM9 code) by writing to a [[PDN]] register(this changes the memory layout to DSi-mode / etc, therefore this register poke *must* be executed from ITCM). This is the final 3DS-mode register poke before the ARM9 switches into DSi-mode. DS(i)-mode ARM7 code is run on the internal [[ARM7]] core, which is started up during TWL_FIRM boot. Trying to read from the exception-vector region(address 0x0) under this DSi-mode ARM7 seems to only return 0x00/0xFF data. Also note that this DSi-mode ARM7 runs code(stored in TWL_FIRM) which pokes some DSi-mode registers that on the DSi were used for disabling access to the DSi bootROMs, however these registers do not affect the 3DS DSi-mode ARM9/ARM7 &amp;quot;bootrom&amp;quot; region(exceptionvector region + 0x8000) at all.&lt;br /&gt;
&lt;br /&gt;
For shutting down the system, TWL_FIRM writes u8 value 8 to [[I2C]] MCU register 0x20. For returning to 3DS-mode, TWL_FIRM writes value 4 to that MCU register to trigger a hardware system reboot.&lt;br /&gt;
&lt;br /&gt;
The TWL_FIRM ARM11-process includes a TWL bootloader, see [http://dsibrew.org/wiki/Bootloader here] and [[Memory_layout#Detailed_TWL_FIRM_ARM11_Memory|here]] for details.&lt;br /&gt;
&lt;br /&gt;
TWL_FIRM verifies all TWL RSA padding with the following. This is different from the DSi &amp;quot;BIOS&amp;quot; code.&lt;br /&gt;
* The first byte must be 0x0.&lt;br /&gt;
* The second byte must be 0x1 or 0x2.&lt;br /&gt;
* Executes a while(&amp;lt;value of byte at current pos in RSA message&amp;gt;). When the second_byte in the message is 0x1, the byte at curpos must be 0xFF(otherwise the non-zero value of the byte at curpos doesn&#039;t matter). This loop must find a zero byte before offset 0x7F in the message otherwise an error is returned.&lt;br /&gt;
* Returns an address for msg_curpos+1.&lt;br /&gt;
totalhashdatasize = rsasig_bytesize - above position in the message for the hashdata. The actual &amp;quot;totalhashdatasize&amp;quot; in the RSA message must be &amp;lt;= &amp;lt;expected hashdata_size&amp;gt;(0x74 for bootloader). The TWL_FIRM code copies the RSA &amp;quot;hashdata&amp;quot; to the output buffer, using the actual size of the RSA &amp;quot;hashdata&amp;quot;.&lt;br /&gt;
&lt;br /&gt;
=== AGB_FIRM ===&lt;br /&gt;
AGB_FIRM handles running GBA VC titles. The ARM9 FIRM section for TWL_FIRM and AGB_FIRM are exactly the same (for TWL_FIRM and AGB_FIRM versions which were updated with the same system-update).&lt;br /&gt;
&lt;br /&gt;
== FIRM Launch Parameters ==&lt;br /&gt;
The FIRM-launch parameters structure is located at FCRAM+0, size 0x1000-bytes. The ARM11-kernel copies this structure elsewhere, then clears the 0x1000-bytes at FCRAM+0. It will not handle an existing structure at FCRAM+0 if [[CONFIG Registers#CFG_BOOTENV|CFG_BOOTENV]] is zero. The ARM9 kernel [[Configuration_Memory#0x1FF80016|writes some values]] about the boot environment to AXI WRAM during init to enable this.&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot; border=&amp;quot;1&amp;quot;&lt;br /&gt;
|-&lt;br /&gt;
!  OFFSET&lt;br /&gt;
!  SIZE&lt;br /&gt;
!  DESCRIPTION&lt;br /&gt;
|-&lt;br /&gt;
| 0x300&lt;br /&gt;
| 0x100&lt;br /&gt;
| &#039;TLNC&#039; block created by TWL applications, handled by NS for backwards-compatibility purposes. See [[NS#Auto-boot|here]] for more info.&lt;br /&gt;
|-&lt;br /&gt;
| 0x400&lt;br /&gt;
| 0x4&lt;br /&gt;
| Flags&lt;br /&gt;
|-&lt;br /&gt;
| 0x410&lt;br /&gt;
| 0xC&lt;br /&gt;
| This is used for overriding the FIRM_* fields in [[Configuration_Memory]], when the flag listed below is set, in the following order(basically just data-copy from here to 0x1FF80060): &amp;quot;FIRM_?&amp;quot;, FIRM_VERSIONREVISION, FIRM_VERSIONMINOR, FIRM_VERSIONMAJOR, FIRM_SYSCOREVER, and FIRM_CTRSDKVERSION.&lt;br /&gt;
|-&lt;br /&gt;
| 0x438&lt;br /&gt;
| 0x4&lt;br /&gt;
| The kernel checks this field for value 0xFFFF, if it matches the kernel uses the rest of these parameter fields, otherwise FIRM-launch parameters fields are ignored by the kernel.&lt;br /&gt;
|-&lt;br /&gt;
| 0x43C&lt;br /&gt;
| 0x4&lt;br /&gt;
| CRC32, this is calculated starting at FIRM-params offset 0x400, with size 0x140(with this field cleared to zero during calculation). When invalid the kernel clears the entire buffer used for storing the FIRM-params, therefore no actual FIRM-params are handled after that.&lt;br /&gt;
|-&lt;br /&gt;
| 0x440&lt;br /&gt;
| 0x10&lt;br /&gt;
| Titleinfo [[Filesystem_services#ProgramInfo|Program Info]], used by NS during NS startup, to launch the specified title when the below flag is set.&lt;br /&gt;
|-&lt;br /&gt;
| 0x450&lt;br /&gt;
| 0x10&lt;br /&gt;
| Titleinfo [[Filesystem_services#ProgramInfo|Program Info]]. This might be used for returning to the specified title, once the above launched title terminates?&lt;br /&gt;
|-&lt;br /&gt;
| 0x460&lt;br /&gt;
| 0x4&lt;br /&gt;
| Bit0: 0 = titleinfo structure isn&#039;t set, 1 = titleinfo structure is set.&lt;br /&gt;
|-&lt;br /&gt;
| 0x480&lt;br /&gt;
| 0x20&lt;br /&gt;
| This can be set via buf1 for [[APT:SendDeliverArg]]/[[APT:StartApplication]].&lt;br /&gt;
|-&lt;br /&gt;
| 0x4A0&lt;br /&gt;
| 0x10&lt;br /&gt;
| This can be set by [[NSS:SetWirelessRebootInfo]].&lt;br /&gt;
|-&lt;br /&gt;
| 0x4B0&lt;br /&gt;
| 0x14&lt;br /&gt;
| SHA1-HMAC of the banner for TWL/NTR titles. This can be set by [[NSS:SetTWLBannerHMAC]].&lt;br /&gt;
|-&lt;br /&gt;
| 0x500&lt;br /&gt;
| 0x40&lt;br /&gt;
| This is used by [[APT:LoadSysMenuArg]] and [[APT:StoreSysMenuArg]].&lt;br /&gt;
|-&lt;br /&gt;
| 0xD70&lt;br /&gt;
| 0x290&lt;br /&gt;
| [[Config Savegame|Config]] data struct for LGY FIRM.&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
Flags from offset 0x400:&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot; border=&amp;quot;1&amp;quot;&lt;br /&gt;
|-&lt;br /&gt;
!  OFFSET&lt;br /&gt;
!  SIZE&lt;br /&gt;
!  DESCRIPTION&lt;br /&gt;
|-&lt;br /&gt;
| 0x0&lt;br /&gt;
| 0x1&lt;br /&gt;
| This can be used for overriding the default FCRAM [[Memory_layout|memory-regions]] allocation sizes(APPLICATION, SYSTEM, and BASE). The values for this is the same as [[Configuration_Memory#APPMEMTYPE|Configmem-APPMEMTYPE]]. Values 0-1 are handled the same way by the kernel. However for NS, 0=titleinfo structure for launching a title isn&#039;t set, while non-zero=titleinfo structure is set.&lt;br /&gt;
|-&lt;br /&gt;
| 0x1&lt;br /&gt;
| 0x3&lt;br /&gt;
| Setting bit0 here enables overriding the FIRM_* fields in [[Configuration_Memory]].&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
[[Config Savegame|Config]] struct for booting LGY FIRMs from offset 0xD70:&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot; border=&amp;quot;1&amp;quot;&lt;br /&gt;
|-&lt;br /&gt;
!  OFFSET&lt;br /&gt;
!  SIZE&lt;br /&gt;
!  DESCRIPTION&lt;br /&gt;
|-&lt;br /&gt;
| 0x0&lt;br /&gt;
| 0x1&lt;br /&gt;
| Config block 0x30000.&lt;br /&gt;
|-&lt;br /&gt;
| 0x1&lt;br /&gt;
| 0x1&lt;br /&gt;
| Config block 0x70001.&lt;br /&gt;
|-&lt;br /&gt;
| 0x2&lt;br /&gt;
| 0x1&lt;br /&gt;
| System language (Config block 0xA0002).&lt;br /&gt;
|-&lt;br /&gt;
| 0x3&lt;br /&gt;
| 0x1&lt;br /&gt;
| [[Cfg:SecureInfoGetRegion|Region from SecureInfo]] (&amp;quot;pseudo-block&amp;quot; 0x140000 in LGY FIRM).&lt;br /&gt;
|-&lt;br /&gt;
| 0x4&lt;br /&gt;
| 0xF&lt;br /&gt;
| [[CfgS:SecureInfoGetSerialNo|Serial number from SecureInfo]] (&amp;quot;pseudo-block&amp;quot; 0x140001 in LGY FIRM).&lt;br /&gt;
|-&lt;br /&gt;
| 0x13&lt;br /&gt;
| 0x1&lt;br /&gt;
| Config block 0x100002.&lt;br /&gt;
|-&lt;br /&gt;
| 0x14&lt;br /&gt;
| 0x10&lt;br /&gt;
| Config block 0x100003.&lt;br /&gt;
|-&lt;br /&gt;
| 0x24&lt;br /&gt;
| 0x2&lt;br /&gt;
| Config block 0x100000.&lt;br /&gt;
|-&lt;br /&gt;
| 0x26&lt;br /&gt;
| 0x1&lt;br /&gt;
| Cleared to zero.&lt;br /&gt;
|-&lt;br /&gt;
| 0x27&lt;br /&gt;
| 0x1&lt;br /&gt;
| Cleared to zero.&lt;br /&gt;
|-&lt;br /&gt;
| 0x28&lt;br /&gt;
| 0x94&lt;br /&gt;
| Config block 0x100001.&lt;br /&gt;
|-&lt;br /&gt;
| 0xBC&lt;br /&gt;
| 0x2&lt;br /&gt;
| Config block 0x50000.&lt;br /&gt;
|-&lt;br /&gt;
| 0xBE&lt;br /&gt;
| 0x2&lt;br /&gt;
| Config block 0x50001.&lt;br /&gt;
|-&lt;br /&gt;
| 0xC0&lt;br /&gt;
| 0x38&lt;br /&gt;
| Config block 0x50002.&lt;br /&gt;
|-&lt;br /&gt;
| 0xF8&lt;br /&gt;
| 0x20&lt;br /&gt;
| Config block 0x50004.&lt;br /&gt;
|-&lt;br /&gt;
| 0x118&lt;br /&gt;
| 0x134&lt;br /&gt;
| Config block 0x20000.&lt;br /&gt;
|-&lt;br /&gt;
| 0x24C&lt;br /&gt;
| 0x10&lt;br /&gt;
| Config block 0x40000.&lt;br /&gt;
|-&lt;br /&gt;
| 0x25C&lt;br /&gt;
| 0x1C&lt;br /&gt;
| Config block 0x40001.&lt;br /&gt;
|-&lt;br /&gt;
| 0x278&lt;br /&gt;
| 0x4&lt;br /&gt;
| Cleared to zero.&lt;br /&gt;
|-&lt;br /&gt;
| 0x27C&lt;br /&gt;
| 0x4&lt;br /&gt;
| Cleared to zero.&lt;br /&gt;
|-&lt;br /&gt;
| 0x280&lt;br /&gt;
| 0x8&lt;br /&gt;
| Config block 0x30001.&lt;br /&gt;
|-&lt;br /&gt;
| 0x288&lt;br /&gt;
| 0x2&lt;br /&gt;
| CRC16 over the above fields from offset 0x0, size 0x288. If not valid, LGY FIRM uses dummy data from .(ro)data.&lt;br /&gt;
|-&lt;br /&gt;
| 0x28A&lt;br /&gt;
| 0x2&lt;br /&gt;
| If non-zero, the size (below) is hardcoded (currently) to value 0x288, otherwise the size field below is used.&lt;br /&gt;
|-&lt;br /&gt;
| 0x28C&lt;br /&gt;
| 0x4&lt;br /&gt;
| Value 0x288 (size used for verifying the CRC16).&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
&amp;quot;Cleared to zero&amp;quot; fields above are not read at all by LGY FIRM.&lt;/div&gt;</summary>
		<author><name>Motezazer</name></author>
	</entry>
	<entry>
		<id>https://www.3dbrew.org/w/index.php?title=3DS_System_Flaws&amp;diff=19130</id>
		<title>3DS System Flaws</title>
		<link rel="alternate" type="text/html" href="https://www.3dbrew.org/w/index.php?title=3DS_System_Flaws&amp;diff=19130"/>
		<updated>2017-01-02T19:14:18Z</updated>

		<summary type="html">&lt;p&gt;Motezazer: ntrcardhax description&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;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]].&lt;br /&gt;
&lt;br /&gt;
=Stale / Rejected Efforts=&lt;br /&gt;
* Neimod has been working on a RAM dumping setup for a little while now. He&#039;s de-soldered the 3DS&#039;s RAM chip and hooked it and the RAM pinouts on the 3DS&#039; 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.&lt;br /&gt;
&lt;br /&gt;
* Someone (who will remain unnamed) has released CFW and CIA installers, all of which is copied from the work of others, or copyrighted material.&lt;br /&gt;
&lt;br /&gt;
==Tips and info==&lt;br /&gt;
The 3DS uses the XN feature of the ARM11 processor. There&#039;s no official way from applications to enable executable permission for memory containing arbitrary unsigned code(there&#039;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.&lt;br /&gt;
&lt;br /&gt;
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).&lt;br /&gt;
&lt;br /&gt;
=System flaws=&lt;br /&gt;
== Hardware ==&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot; border=&amp;quot;1&amp;quot;&lt;br /&gt;
!  Summary&lt;br /&gt;
!  Description&lt;br /&gt;
!  Fixed with hardware model/revision&lt;br /&gt;
!  Newest hardware model/revision this flaw was checked for&lt;br /&gt;
!  Timeframe this was discovered&lt;br /&gt;
!  Discovered by&lt;br /&gt;
|-&lt;br /&gt;
| ARM9/ARM11 bootrom vectors point at uninitialized RAM&lt;br /&gt;
| ARM9&#039;s and ARM11&#039;s exception vectors are hardcoded to point at the CPU&#039;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. &lt;br /&gt;
Since RAM isn&#039;t cleared on boot (see below), one can immediately start execution of their own code here to dump bootrom, OTP, etc.&lt;br /&gt;
The ARM9 bootrom does the following at reset:  reset vector branches to another instruction, then branches to bootrom+0x8000. Hence, there&#039;s no way to know for certain when exactly the ARM9 exception-vector data stored in memory gets initialized.&lt;br /&gt;
&lt;br /&gt;
This requires *very* *precise* timing for triggering the hardware fault.&lt;br /&gt;
&lt;br /&gt;
It has been exploited by derrek to dump the ARM9 bootrom as of Summer 2015.&lt;br /&gt;
| None: all available 3DS models at the time of writing have the exact same ARM9/ARM11 bootrom for the unprotected areas.&lt;br /&gt;
| New3DS&lt;br /&gt;
| End of February 2014&lt;br /&gt;
| [[User:Derrek|derrek]], WulfyStylez (May 2015) independently&lt;br /&gt;
|-&lt;br /&gt;
| Missing AES key clearing&lt;br /&gt;
| The hardware AES engine does not clear keys when doing a hard reset/reboot.&lt;br /&gt;
| None&lt;br /&gt;
| New3DS&lt;br /&gt;
| August 2014&lt;br /&gt;
| Mathieulh/Others&lt;br /&gt;
|-&lt;br /&gt;
| No RAM clearing on reboots&lt;br /&gt;
| On an MCU-triggered reboot all RAM including FCRAM/ARM9 memory/AXIWRAM/VRAM keeps its contents.&lt;br /&gt;
| None&lt;br /&gt;
| New3DS&lt;br /&gt;
| March 2014&lt;br /&gt;
| [[User:Derrek|derrek]]&lt;br /&gt;
|-&lt;br /&gt;
| 32bits of actual console-unique TWLNAND keydata&lt;br /&gt;
| 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&#039;s highest bit is always ORed. only 31 bits of the TWL console-unique keydata / TWL consoleID are actually console-unique.&lt;br /&gt;
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).&lt;br /&gt;
| None&lt;br /&gt;
| New3DS&lt;br /&gt;
| 2012?&lt;br /&gt;
| [[User:Yellows8|Yellows8]]&lt;br /&gt;
|-&lt;br /&gt;
| DSi / 3DS-TWL key-generator&lt;br /&gt;
| 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.&lt;br /&gt;
This applies to the keyX/keyY too.&lt;br /&gt;
&lt;br /&gt;
This attack does not work for the 3DS key-generator because keyslots 0-3 are only for TWL keys.&lt;br /&gt;
| None&lt;br /&gt;
| New3DS&lt;br /&gt;
| 2011&lt;br /&gt;
| [[User:Yellows8|Yellows8]]&lt;br /&gt;
|-&lt;br /&gt;
| 3DS key-generator&lt;br /&gt;
| 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.&lt;br /&gt;
&lt;br /&gt;
Several such pairs of matching normal-keys and KeyY values were found, leading to deducing the key-generator function.&lt;br /&gt;
| None&lt;br /&gt;
| New3DS&lt;br /&gt;
| February 2015&lt;br /&gt;
| [[User:Yellows8|Yellows8]], [[User:Plutooo|plutoo]]&lt;br /&gt;
|-&lt;br /&gt;
| FIRM partitions known-plaintext&lt;br /&gt;
| The [[Flash_Filesystem|FIRM partitions]] are encrypted with AES-CTR without a MAC. Since this works by XOR&#039;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.&lt;br /&gt;
&lt;br /&gt;
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).&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
| None&lt;br /&gt;
| New3DS&lt;br /&gt;
| &lt;br /&gt;
| Everyone&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
== ARM9 software ==&lt;br /&gt;
&lt;br /&gt;
=== arm9loader ===&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot; border=&amp;quot;1&amp;quot;&lt;br /&gt;
|-&lt;br /&gt;
!  Summary&lt;br /&gt;
!  Description&lt;br /&gt;
!  Successful exploitation result&lt;br /&gt;
!  Fixed in [[FIRM]] system version&lt;br /&gt;
!  Last [[FIRM]] system version this flaw was checked for&lt;br /&gt;
!  Timeframe this was discovered&lt;br /&gt;
!  Public disclosure timeframe&lt;br /&gt;
!  Discovered by&lt;br /&gt;
|-&lt;br /&gt;
| Rearrangable keys in the NAND keystore&lt;br /&gt;
| Due to the keystore being encrypted with AES-ECB, one can rearrange blocks and still have the NAND keystore decrypt in a deterministic way. &lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
| arm9loaderhax given existing ARM9 code execution&lt;br /&gt;
| None&lt;br /&gt;
| [[11.2.0-35|11.2.0-X]]&lt;br /&gt;
| Early 2016&lt;br /&gt;
| 27 September 2016&lt;br /&gt;
| Myria, [[User:Dark samus|dark_samus]]; mathieulh (independently); [[User:Plutooo|plutoo]] (independently) + others&lt;br /&gt;
|-&lt;br /&gt;
| Uncleared OTP hash keydata in console-unique 0x11 key-generation&lt;br /&gt;
| 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.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
This can be performed by exploiting the &amp;quot;arm9loaderhax&amp;quot; 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 &amp;lt;[[3.0.0-6|3.0.0-X]].&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
| Derivation of all New3DS keys generated via the NAND keystore (0x1B &amp;quot;Secure4&amp;quot; etc.)&lt;br /&gt;
| None&lt;br /&gt;
| [[11.2.0-35|11.2.0-X]]&lt;br /&gt;
| ~April 2015, implemented in May 2015&lt;br /&gt;
| 13 January 2016&lt;br /&gt;
| [[User:WulfyStylez|WulfyStylez]], [[User:Dazzozo|Dazzozo]], [[User:Shinyquagsire23|shinyquagsire23]] (complimentary + implemented), [[User:Plutooo|plutoo]], Normmatt (discovered independently)&lt;br /&gt;
|-&lt;br /&gt;
| enhanced-arm9loaderhax&lt;br /&gt;
| See the 32c3 3ds talk.&lt;br /&gt;
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&#039;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.&lt;br /&gt;
| arm9loaderhax which automatically occurs at hard-boot.&lt;br /&gt;
| See arm9loaderhax / description.&lt;br /&gt;
| See arm9loaderhax / description.&lt;br /&gt;
| Theorized around mid July, 2015. Later implemented+tested by [[User:Plutooo|plutoo]] and [[User:Derrek|derrek]].&lt;br /&gt;
| 32c3 3ds talk (December 27, 2015)&lt;br /&gt;
| [[User:Yellows8|Yellows8]]&lt;br /&gt;
|-&lt;br /&gt;
| Missing verification-block for the 9.6 keys (arm9loaderhax)&lt;br /&gt;
| 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.&lt;br /&gt;
&lt;br /&gt;
Writing an incorrect key to NAND will cause arm9loader to decrypt the ARM9 kernel as garbage and then jump to it.&lt;br /&gt;
&lt;br /&gt;
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&#039;ll find some garbage that jumps to your code.&lt;br /&gt;
&lt;br /&gt;
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. &lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
| Recovery of 6.x [[Savegames#6.0.0-11_Savegame_keyY|save key]]/7.x [[NCCH]] key, access to uncleared OTP hash keydata&lt;br /&gt;
| None&lt;br /&gt;
| [[11.2.0-35|11.2.0-X]]&lt;br /&gt;
| March, 2015&lt;br /&gt;
| &lt;br /&gt;
| [[User:Plutooo|plutoo]]&lt;br /&gt;
|-&lt;br /&gt;
| Uncleared New3DS keyslot 0x11&lt;br /&gt;
| 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.&lt;br /&gt;
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 &amp;lt;=v9.5 New3DS keyXs which are generated by keyslot 0x11.&lt;br /&gt;
&lt;br /&gt;
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]].&lt;br /&gt;
| New3DS keyXs generation&lt;br /&gt;
| 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]].&lt;br /&gt;
| &lt;br /&gt;
| February 3, 2015 (one day after [[9.5.0-22|9.5.0-X]] release)&lt;br /&gt;
| &lt;br /&gt;
| [[User:Yellows8|Yellows8]]&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
=== Process9 ===&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot; border=&amp;quot;1&amp;quot;&lt;br /&gt;
|-&lt;br /&gt;
!  Summary&lt;br /&gt;
!  Description&lt;br /&gt;
!  Successful exploitation result&lt;br /&gt;
!  Fixed in [[FIRM]] system version&lt;br /&gt;
!  Last [[FIRM]] system version this flaw was checked for&lt;br /&gt;
!  Timeframe this was discovered&lt;br /&gt;
!  Public disclosure timeframe&lt;br /&gt;
!  Discovered by&lt;br /&gt;
|-&lt;br /&gt;
| Leak of normal-key matching a key-scrambler key&lt;br /&gt;
| 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 &amp;quot;fixed&amp;quot; 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.&lt;br /&gt;
&lt;br /&gt;
Nintendo&#039;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 &amp;quot;Hardware&amp;quot; above), the key scrambler function could be deduced.&lt;br /&gt;
| Deducing the keyX for keyslot 0x39 and the key scrambler algorithm&lt;br /&gt;
| New 3DS [[9.3.0-21|9.3.0-X]], sort of&lt;br /&gt;
| [[10.0.0-27|10.0.0-X]]&lt;br /&gt;
| Sometime in 2015 after the hardware key-generator was broken.&lt;br /&gt;
| 32c3 3ds talk (December 27, 2015)&lt;br /&gt;
| [[User:Yellows8|Yellows8]]&lt;br /&gt;
|-&lt;br /&gt;
| Leak of normal-key matching a key-generator key&lt;br /&gt;
| During the 3DS&#039; 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.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
Knowing the keyY and the normal-key for common-key index1, the devkit key-generator algorithm can be deduced (see &amp;quot;Hardware&amp;quot; above). Additionally the remaining devkit common-keys can be generated once the common-key keyX is recovered.&lt;br /&gt;
&lt;br /&gt;
Note the devkit key-generator was discovered to be the same as the retail key-generator.&lt;br /&gt;
| Deducing the keyX for keyslot 0x3D and hardware key-generator algorithm. Generate remaining devkit common-keys.&lt;br /&gt;
| pre-[[1.0.0-0|1.0.0-X]]&lt;br /&gt;
| &lt;br /&gt;
| Shortly after the key-generator was revealed to be flawed at the 32c3 3ds talk&lt;br /&gt;
| January 20, 2016&lt;br /&gt;
| [[User:Jakcron|jakcron]]&lt;br /&gt;
|-&lt;br /&gt;
| safefirmhax&lt;br /&gt;
| SAFE_MODE_FIRM is almost never updated(even when NATIVE_FIRM is updated for vuln fixes), this can be noticed by &#039;&#039;just&#039;&#039; checking 3dbrew/ninupdates title-listings.&lt;br /&gt;
&lt;br /&gt;
The fix for firmlaunch-hax 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 &amp;lt;=&amp;gt; Kernel11 sync, PXI sync and then repeat the original attack on SAFE_FIRM instead.&lt;br /&gt;
| ARM9 code execution&lt;br /&gt;
| None&lt;br /&gt;
| &lt;br /&gt;
| &lt;br /&gt;
| &lt;br /&gt;
| Everyone&lt;br /&gt;
|-&lt;br /&gt;
| ntrcardhax&lt;br /&gt;
| When reading the banner of a NTR title, Process9 relies on a hardware register to know when the banner was fully read.&lt;br /&gt;
However that register is shared between the ARM9 and the ARM11.&lt;br /&gt;
An attacker with k11 control can so make Process9 believe the banner continues forever and so trigger a buffer overflow.&lt;br /&gt;
With a custom banner for a NTR flashcart, this leads to code execution in Process9.&lt;br /&gt;
&lt;br /&gt;
This was fixed by adding bound checks on the read data.&lt;br /&gt;
| ARM9 code execution&lt;br /&gt;
| [[10.4.0-29|10.4.0-X]]&lt;br /&gt;
| &lt;br /&gt;
| March 2015&lt;br /&gt;
| 32c3 3ds talk (December 27, 2015)&lt;br /&gt;
| [[User:Plutooo|plutoo]]&lt;br /&gt;
|-&lt;br /&gt;
| Title downgrading via [[Application_Manager_Services|AM]]([[Application_Manager_Services_PXI|PXI]])&lt;br /&gt;
| 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.&lt;br /&gt;
&lt;br /&gt;
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&#039;t compare the input title-version with anything. Hence, titles can be downgraded this way.&lt;br /&gt;
&lt;br /&gt;
[[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.&lt;br /&gt;
| Bypassing title version check at installation, which then allows downgrading any title.&lt;br /&gt;
| [[11.0.0-33|11.0.0-X]], for key system titles.&lt;br /&gt;
| NATIVE_FIRM / AM-sysmodule [[11.0.0-33|11.0.0-X]]&lt;br /&gt;
| ?&lt;br /&gt;
| &lt;br /&gt;
| ?&lt;br /&gt;
|-&lt;br /&gt;
| FAT FS code null-deref&lt;br /&gt;
| 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&#039;t check for NULL which then triggers a read based at NULL.&lt;br /&gt;
&lt;br /&gt;
Sample &amp;quot;fsck.vfat -n -v -V &amp;lt;fat image backup&amp;gt;&amp;quot; output for the above crash:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;...&lt;br /&gt;
Starting check/repair pass.&lt;br /&gt;
&amp;lt;FilePath0&amp;gt; and&lt;br /&gt;
&amp;lt;FilePath1&amp;gt;&lt;br /&gt;
 share clusters.&lt;br /&gt;
 Truncating second to 3375104 bytes.&lt;br /&gt;
&amp;lt;FilePath1&amp;gt;&lt;br /&gt;
 File size is 2787392 bytes, cluster chain length is 16384 bytes.&lt;br /&gt;
 Truncating file to 16384 bytes.&lt;br /&gt;
Checking for unused clusters.&lt;br /&gt;
Reclaimed 1 unused cluster (16384 bytes).&lt;br /&gt;
Checking free cluster summary.&lt;br /&gt;
Free cluster summary wrong (1404490 vs. really 1404491)&lt;br /&gt;
 Auto-correcting.&lt;br /&gt;
Starting verification pass.&lt;br /&gt;
Checking for unused clusters.&lt;br /&gt;
Leaving filesystem unchanged.&amp;lt;/pre&amp;gt;&lt;br /&gt;
| Useless null-based-read&lt;br /&gt;
| None&lt;br /&gt;
| [[9.6.0-24|9.6.0-X]]&lt;br /&gt;
| July 8-9, 2015&lt;br /&gt;
| &lt;br /&gt;
| [[User:Yellows8|Yellows8]]&lt;br /&gt;
|-&lt;br /&gt;
| RSA signature padding checks&lt;br /&gt;
| The TWL_FIRM RSA sig padding check code used for all TWL RSA sig-checks has issues, see [[FIRM|here]].&lt;br /&gt;
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&#039;t really a problem here because there&#039;s proper padding check code which is executed prior to this.&lt;br /&gt;
| &lt;br /&gt;
| None&lt;br /&gt;
| [[9.5.0-22|9.5.0-X]]&lt;br /&gt;
| March 2015&lt;br /&gt;
| &lt;br /&gt;
| [[User:Yellows8|Yellows8]]&lt;br /&gt;
|-&lt;br /&gt;
| [[AMPXI:ValidateDSiWareSectionMAC]] [[AES_Registers|AES]] keyslot reuse&lt;br /&gt;
| When the input DSiWare section index is higher than &amp;lt;max number of DSiWare sections supported by this FIRM&amp;gt;, 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 &amp;gt;=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&#039;s unknown whether a timing attack would work with this.&lt;br /&gt;
This is basically a different form of the pxips9 keyslot vuln, except with AESMAC etc.&lt;br /&gt;
| See description.&lt;br /&gt;
| None&lt;br /&gt;
| [[11.2.0-35|11.2.0-X]]&lt;br /&gt;
| March 15, 2015&lt;br /&gt;
| December 29, 2015&lt;br /&gt;
| [[User:Yellows8|Yellows8]]&lt;br /&gt;
|-&lt;br /&gt;
| pxips9 [[AES_Registers|AES]] keyslot reuse&lt;br /&gt;
| 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 &amp;lt;=10.1.0-X(see 32c3 3ds talk).&lt;br /&gt;
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&#039;t return any errors, Process9 will just continue to do crypto with whatever AES keyslot was selected before the PS command was sent.&lt;br /&gt;
| Reusing the previously used keyslot, for crypto with PS.&lt;br /&gt;
| None&lt;br /&gt;
| [[11.2.0-35|11.2.0-X]]&lt;br /&gt;
| Roughly the same time(same day?) as firmlaunch-hax.&lt;br /&gt;
| December 29, 2015&lt;br /&gt;
| [[User:Yellows8|Yellows8]]&lt;br /&gt;
|-&lt;br /&gt;
| firmlaunch-hax: FIRM header ToCToU&lt;br /&gt;
| This can&#039;t be exploited from ARM11 userland.&lt;br /&gt;
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&#039;t expect &amp;quot;anything&amp;quot; besides the ARM9 to access this data.&lt;br /&gt;
With [[9.5.0-22]] the address of this FIRM header was changed from a FCRAM address, to ARM9-only address 0x01fffc00.&lt;br /&gt;
| ARM9 code execution&lt;br /&gt;
| [[9.5.0-22]]&lt;br /&gt;
| &lt;br /&gt;
| 2012, 3 days after [[User:Yellows8|Yellows8]] started Process9 code RE.&lt;br /&gt;
| &lt;br /&gt;
| [[User:Yellows8|Yellows8]]&lt;br /&gt;
|-&lt;br /&gt;
| Uninitialized data output for (PXI) command replies&lt;br /&gt;
| 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.&lt;br /&gt;
Certain ARM11 service commands have this same issue as well.&lt;br /&gt;
| &lt;br /&gt;
| None&lt;br /&gt;
| [[9.3.0-21|9.3.0-X]]&lt;br /&gt;
| ?&lt;br /&gt;
| &lt;br /&gt;
| [[User:Yellows8|Yellows8]]&lt;br /&gt;
|-&lt;br /&gt;
| [[Filesystem_services_PXI|FSPXI]] OpenArchive SD permissions&lt;br /&gt;
| Process9 does not use the exheader ARM9 access-mount permission flag for SD at all.&lt;br /&gt;
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.&lt;br /&gt;
| &lt;br /&gt;
| None&lt;br /&gt;
| [[9.3.0-21|9.3.0-X]]&lt;br /&gt;
| 2012&lt;br /&gt;
| &lt;br /&gt;
| [[User:Yellows8|Yellows8]]&lt;br /&gt;
|-&lt;br /&gt;
| [[AMPXI:ExportDSiWare]] export path&lt;br /&gt;
| 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 &amp;quot;&amp;lt;mountpoint&amp;gt;:/&amp;lt;path&amp;gt;&amp;quot;.&lt;br /&gt;
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.&lt;br /&gt;
| Exporting of DSiWare to arbitrary Process9 file-paths, such as &amp;quot;nand:/&amp;lt;path&amp;gt;&amp;quot; etc. This isn&#039;t really useful since the data which gets written can&#039;t be controlled.&lt;br /&gt;
| None&lt;br /&gt;
| [[9.5.0-22]]&lt;br /&gt;
| April 2013&lt;br /&gt;
| &lt;br /&gt;
| [[User:Yellows8|Yellows8]]&lt;br /&gt;
|-&lt;br /&gt;
| [[DSiWare_Exports]] [[CTCert]] verification&lt;br /&gt;
| 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&#039;s still not(?) fixed.&lt;br /&gt;
On 3DS however this is rather useless, due to the entire DSiWare .bin being encrypted with the console-unique movable.sed keyY.&lt;br /&gt;
| 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.&lt;br /&gt;
| Unknown, probably none.&lt;br /&gt;
| ?&lt;br /&gt;
| April 2013&lt;br /&gt;
| &lt;br /&gt;
| [[User:Yellows8|Yellows8]]&lt;br /&gt;
|-&lt;br /&gt;
| [[Gamecard_Services_PXI]] unchecked REG_CTRCARDCNT transfer-size&lt;br /&gt;
| 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&#039;t checked, thus out-of-bounds reads could be triggered(which is rather useless in this case).&lt;br /&gt;
| Out-of-bounds read for a value which gets written to a register.&lt;br /&gt;
| [[5.0.0-11|5.0.0-X]]&lt;br /&gt;
| &lt;br /&gt;
| 2013?&lt;br /&gt;
| &lt;br /&gt;
| [[User:Yellows8|Yellows8]]&lt;br /&gt;
|-&lt;br /&gt;
| [[PXI_Registers|PXI]] cmdbuf buffer overrun&lt;br /&gt;
| The Process9 code responsible [[PXI_Registers|PXI]] communications didn&#039;t verify the size of the incoming command before writing it to a C++ member variable. &lt;br /&gt;
| Probably ARM9 code execution&lt;br /&gt;
| [[5.0.0-11|5.0.0-11]]&lt;br /&gt;
| &lt;br /&gt;
| March 2015, original timeframe if any unknown&lt;br /&gt;
| &lt;br /&gt;
| [[User:Plutooo|plutoo]]/[[User:Yellows8|Yellows8]]/maybe others(?)&lt;br /&gt;
|-&lt;br /&gt;
| [[Application_Manager_Services_PXI|PXIAM]] command 0x003D0108(See also [[Application_Manager_Services|this]])&lt;br /&gt;
| 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 &amp;lt;=0x2800.&lt;br /&gt;
| ARM9 code execution&lt;br /&gt;
| [[5.0.0-11|5.0.0-X]]&lt;br /&gt;
| &lt;br /&gt;
| May 2013&lt;br /&gt;
| &lt;br /&gt;
| [[User:Yellows8|Yellows8]]&lt;br /&gt;
|-&lt;br /&gt;
| [[Process_Services_PXI|PS RSA]] commands buffer overflows&lt;br /&gt;
| pxips9 cmd1(not accessible via ps:ps) and VerifyRsaSha256: unchecked copy to a buffer in Process9&#039;s .bss, from the input FCRAM buffer. The buffer is located before the pxi cmdhandler threads&#039; stacks. SignRsaSha256 also has a buf overflow, but this isn&#039;t exploitable.&lt;br /&gt;
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]].&lt;br /&gt;
| ARM9 code execution&lt;br /&gt;
| [[5.0.0-11|5.0.0-X]]&lt;br /&gt;
| &lt;br /&gt;
| 2012&lt;br /&gt;
| &lt;br /&gt;
| [[User:Yellows8|Yellows8]]&lt;br /&gt;
|-&lt;br /&gt;
| [[PXI_Registers|PXI]] pxi_id bad check&lt;br /&gt;
| The Process9 code responsible for [[PXI_Registers|PXI]] communications read pxi_id as a signed char. There were two flaws:&lt;br /&gt;
* They used it as index to a lookup-table without checking the value at all.&lt;br /&gt;
* Another function verified that pxi_id &amp;lt; 7, allowing negative values to pass the check. This would also cause an out-of-range table-lookup.&lt;br /&gt;
| Maybe ARM9 code execution&lt;br /&gt;
| [[3.0.0-5|3.0.0-5]]&lt;br /&gt;
|&lt;br /&gt;
| March 2015, originally 2012 for the first issue at least&lt;br /&gt;
| &lt;br /&gt;
| [[User:Plutooo|plutoo]], [[User:Yellows8|Yellows8]], maybe others(?)&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
=== Kernel9 ===&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot; border=&amp;quot;1&amp;quot;&lt;br /&gt;
|-&lt;br /&gt;
!  Summary&lt;br /&gt;
!  Description&lt;br /&gt;
!  Successful exploitation result&lt;br /&gt;
!  Fixed in [[FIRM]] system version&lt;br /&gt;
!  Last [[FIRM]] system version this flaw was checked for&lt;br /&gt;
!  Timeframe this was discovered&lt;br /&gt;
!  Discovered by&lt;br /&gt;
|-&lt;br /&gt;
| [[CONFIG Registers#CFG_SYSPROT9|CFG_SYSPROT9]] bit1 not set by Kernel9&lt;br /&gt;
| 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&#039;s never locked, you can dump it once you get ARM9 code execution.&lt;br /&gt;
&lt;br /&gt;
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).&lt;br /&gt;
&lt;br /&gt;
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 -&amp;gt; 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.&lt;br /&gt;
| Dumping of the [[OTP Registers|OTP]] area&lt;br /&gt;
| [[3.0.0-5|3.0.0-X]]&lt;br /&gt;
|&lt;br /&gt;
| February 2015&lt;br /&gt;
| [[User:Plutooo|plutoo]], Normmatt independently&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
== ARM11 software ==&lt;br /&gt;
=== Kernel11 ===&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot; border=&amp;quot;1&amp;quot;&lt;br /&gt;
|-&lt;br /&gt;
!  Summary&lt;br /&gt;
!  Description&lt;br /&gt;
!  Successful exploitation result&lt;br /&gt;
!  Fixed in [[FIRM]] system version&lt;br /&gt;
!  Last [[FIRM]] system version this flaw was checked for&lt;br /&gt;
!  Timeframe this was discovered&lt;br /&gt;
!  Discovered by&lt;br /&gt;
|-&lt;br /&gt;
|  [[SVC]] table too small&lt;br /&gt;
|  The table of function pointers for SVC&#039;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.&lt;br /&gt;
&lt;br /&gt;
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&#039;t mapped as executable.&lt;br /&gt;
| &lt;br /&gt;
|  None&lt;br /&gt;
| [[11.2.0-35|11.2.0-X]]&lt;br /&gt;
| 2012&lt;br /&gt;
| Everyone&lt;br /&gt;
|-&lt;br /&gt;
|  [[SVC|svcBackdoor (0x7B)]]&lt;br /&gt;
|  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.&lt;br /&gt;
| See description&lt;br /&gt;
| [[11.0.0-33|11.0.0-X]] (deleted)&lt;br /&gt;
| &lt;br /&gt;
|&lt;br /&gt;
| Everyone&lt;br /&gt;
|-&lt;br /&gt;
| veryslowpidhax&lt;br /&gt;
| &#039;&#039;&#039;This is completely different from the kernelmode-code-execution vuln described in the below separate entry.&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
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 &amp;lt;total ARM11 FIRM modules&amp;gt; to access &#039;&#039;all&#039;&#039; 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.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
With launching+terminating a sysmodule repeatedly with this via ns:s, it would take weeks to finish(if not at least about a month?).&lt;br /&gt;
| Access to all [[Services_API|services]], ControlMemory on any given mem-region.&lt;br /&gt;
| None&lt;br /&gt;
| [[11.2.0-35|11.2.0-X]]&lt;br /&gt;
| 2012 maybe?&lt;br /&gt;
| &lt;br /&gt;
|-&lt;br /&gt;
|  slowhax/waithax&lt;br /&gt;
|  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.&lt;br /&gt;
| ARM11 kernel-mode code execution&lt;br /&gt;
| [[11.2.0-35|11.2.0-X]]&lt;br /&gt;
| [[11.2.0-35|11.2.0-X]]&lt;br /&gt;
| 2016&lt;br /&gt;
| nedwill, [[User:Derrek|derrek]]&lt;br /&gt;
|-&lt;br /&gt;
| [[Memory_layout#ARM11_Detailed_virtual_memory_map|0xEFF00000]] / 0xDFF00000 ARM11 kernel virtual-memory&lt;br /&gt;
| 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.&lt;br /&gt;
| &lt;br /&gt;
| None&lt;br /&gt;
| [[11.2.0-35|11.2.0-X]]&lt;br /&gt;
| &lt;br /&gt;
| &lt;br /&gt;
|-&lt;br /&gt;
| memchunkhax2.1&lt;br /&gt;
| Nintendo&#039;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.&lt;br /&gt;
derrek&#039;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.&lt;br /&gt;
| ARM11 kernel code execution&lt;br /&gt;
| [[11.0.0-33|11.0.0-X]], via the new [[Memory_Management#MemoryBlockHeader|memchunkhdr]] MAC which prevents modifying memchunkhdr data with DMA.&lt;br /&gt;
| [[11.0.0-33|11.0.0-X]]&lt;br /&gt;
|&lt;br /&gt;
| [[User:Derrek|derrek]], aliaspider&lt;br /&gt;
|-&lt;br /&gt;
| memchunkhax2&lt;br /&gt;
| When allocating a block of memory, the &amp;quot;next&amp;quot; pointer of the [[Memory_Management#MemoryBlockHeader|memchunkhdr]] is accessed without being checked after being mapped to userland.&lt;br /&gt;
This allows a race condition, where the process can change the next pointer just before it&#039;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. &lt;br /&gt;
| ARM11 kernel code execution&lt;br /&gt;
| [[10.4.0-29|10.4.0-X]] (partially, see memchunkhax2.1)&lt;br /&gt;
| [[10.4.0-29|10.4.0-X]]&lt;br /&gt;
|&lt;br /&gt;
| [[User:Derrek|derrek]]&lt;br /&gt;
|-&lt;br /&gt;
| heaphax&lt;br /&gt;
| 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.&lt;br /&gt;
| Code execution with access to all of NS&#039;s privileges. (including downgrading) Code execution within any applet.&lt;br /&gt;
| [[11.0.0-33|11.0.0-X]], via the new [[Memory_Management#MemoryBlockHeader|memchunkhdr]] MAC which prevents modifying memchunkhdr data with DMA.&lt;br /&gt;
| [[11.0.0-33|11.0.0-X]]&lt;br /&gt;
| April 2015 ?&lt;br /&gt;
| smea&lt;br /&gt;
|-&lt;br /&gt;
| snshax&lt;br /&gt;
| Can force creation of Safe NS process into gspwn-able memory, allowing for takeover.&lt;br /&gt;
| Code execution with access to all of NS&#039;s privileges. (including downgrading)&lt;br /&gt;
| [[10.1.0-27|10.1.0-X]]&lt;br /&gt;
| [[10.1.0-27|10.1.0-X]]&lt;br /&gt;
| April 2015 ?&lt;br /&gt;
| smea&lt;br /&gt;
|-&lt;br /&gt;
|  AffinityMask/processorid validation&lt;br /&gt;
|  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.&lt;br /&gt;
The original code with the first 3 did the following: &lt;br /&gt;
* if(u32_processorcount &amp;gt; ~0x80000001)return 0xe0e01bfd;&lt;br /&gt;
* if(s32_processorcount &amp;gt; &amp;lt;total_cores&amp;gt;)return 0xd8e007fd;&lt;br /&gt;
The following code replaced the above:&lt;br /&gt;
* if(u32_processorcount &amp;gt;= &amp;lt;total_cores+1&amp;gt;)return 0xd8e007fd;&lt;br /&gt;
In theory the latter should catch everything that the former did, so it&#039;s unknown if this was really a security issue.&lt;br /&gt;
&lt;br /&gt;
The svcCreateThread changes with [[10.0.0-27|10.0.0-X]] definitely did fix a security issue.&lt;br /&gt;
* Original code: &amp;quot;if(s32_processorid &amp;gt; &amp;lt;total_cores&amp;gt;)return 0xd8e007fd;&amp;quot;&lt;br /&gt;
* New code: &amp;quot;if(s32_processorid &amp;gt;= &amp;lt;total_cores&amp;gt; || s32_processorid &amp;lt;= -4)return 0xd8e007fd;&amp;quot;&lt;br /&gt;
This fixed an off-by-one issue: if one would use processorid=total_cores, which isn&#039;t actually a valid value, svcCreateThread would accept that value on &amp;lt;[[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:&lt;br /&gt;
* Old3DS: Useless kernel-mode crash due to accessing unmapped memory.&lt;br /&gt;
* New3DS: uncontrolled data write into a kernel-mode L1 MMU-table. This isn&#039;t really useful: the data can&#039;t be controlled, and the data which gets overwritten is all-zero anyway(this isn&#039;t anywhere near MMU L1 entries for actually mapped memory).&lt;br /&gt;
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&#039;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)).&lt;br /&gt;
| Nothing useful&lt;br /&gt;
|  [[10.0.0-27|10.0.0-X]]&lt;br /&gt;
| [[10.0.0-27|10.0.0-X]]&lt;br /&gt;
| svcCreateThread issue: May 31, 2015. The rest: September 8, 2015, via v9.6-&amp;gt;v10.0 ARM11-kernel code-diff.&lt;br /&gt;
| [[User:Yellows8|Yellows8]]&lt;br /&gt;
|-&lt;br /&gt;
| memchunkhax&lt;br /&gt;
| 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.&lt;br /&gt;
&lt;br /&gt;
There are &#039;&#039;multiple&#039;&#039; 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.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
| When combined with other flaws: ARM11-kernelmode code execution&lt;br /&gt;
| [[9.3.0-21|9.3.0-21]]&lt;br /&gt;
| &lt;br /&gt;
| February 2014&lt;br /&gt;
| [[User:Yellows8|Yellows8]]&lt;br /&gt;
|-&lt;br /&gt;
| Multiple [[KLinkedListNode|KLinkedListNode]] SlabHeap use after free bugs&lt;br /&gt;
| The ARM11-kernel did access the &#039;key&#039; 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:&lt;br /&gt;
SlabHeap_free(KLinkedListNode);&lt;br /&gt;
KObject *obj = KLinkedListNode-&amp;gt;key;  // the object there might have changed!&lt;br /&gt;
This bug appeared all over the place.&lt;br /&gt;
| ARM11-kernelmode code exec maybe&lt;br /&gt;
| [[8.0.0-18|8.0.0-18]]&lt;br /&gt;
| &lt;br /&gt;
| April 2015&lt;br /&gt;
| [[User:Derrek|derrek]]&lt;br /&gt;
|-&lt;br /&gt;
| PXI [[RPC_Command_Structure|Command]] input/output buffer permissions&lt;br /&gt;
| Originally the ARM11-kernel didn&#039;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.&lt;br /&gt;
| &lt;br /&gt;
| [[6.0.0-11|6.0.0-11]]&lt;br /&gt;
| &lt;br /&gt;
| 2012&lt;br /&gt;
| [[User:Yellows8|Yellows8]]&lt;br /&gt;
|-&lt;br /&gt;
| [[SVC|svcStartInterProcessDma]]&lt;br /&gt;
| For svcStartInterProcessDma, the kernel code had the following flaws:&lt;br /&gt;
&lt;br /&gt;
* 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.&lt;br /&gt;
&lt;br /&gt;
* Integer overflows for srcaddr+size and dstaddr+size are now checked(with [[6.0.0-11]]), which were not checked before.&lt;br /&gt;
&lt;br /&gt;
* 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 &amp;gt;=0x20000000 would result in the kernel reading from the process L1 MMU table, beyond the memory allocated for that MMU table(for vaddr-&amp;gt;physaddr conversion). &lt;br /&gt;
| &lt;br /&gt;
| [[6.0.0-11]]&lt;br /&gt;
| &lt;br /&gt;
| DmaConfig issue: unknown. The rest: 2014&lt;br /&gt;
| [[User:Plutooo|plutoo]], [[User:Yellows8|Yellows8]] independently&lt;br /&gt;
|-&lt;br /&gt;
| [[SVC|svcControlMemory]] Parameter checks&lt;br /&gt;
| For svcControlMemory the parameter check had these two flaws:&lt;br /&gt;
&lt;br /&gt;
* 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&#039;t actually use the input address for LINEAR memory-mapping at all besides the range-checks, so this isn&#039;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.&lt;br /&gt;
&lt;br /&gt;
* Integer overflows on (addr0+size) are now checked that previously weren&#039;t (this also applies to most other address checks elsewhere in the kernel).&lt;br /&gt;
&lt;br /&gt;
| &lt;br /&gt;
| [[5.0.0-11]]&lt;br /&gt;
| &lt;br /&gt;
|&lt;br /&gt;
| [[User:Plutooo|plutoo]]&lt;br /&gt;
|-&lt;br /&gt;
| [[RPC_Command_Structure|Command]] request/response buffer overflow&lt;br /&gt;
| 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.&lt;br /&gt;
&lt;br /&gt;
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 &amp;lt;nowiki&amp;gt;((size&amp;lt;&amp;lt;14) | 2)&amp;lt;/nowiki&amp;gt; to write arbitrary memory to any RW userland memory in the destination process.&lt;br /&gt;
| &lt;br /&gt;
| [[5.0.0-11]]&lt;br /&gt;
| &lt;br /&gt;
| v4.1 FIRM -&amp;gt; v5.0 code diff&lt;br /&gt;
| [[User:Yellows8|Yellows8]]&lt;br /&gt;
|-&lt;br /&gt;
| [[SVC|SVC stack allocation overflows]]&lt;br /&gt;
| &lt;br /&gt;
* 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. &lt;br /&gt;
* The alignment (size+7)&amp;amp;~7 calculation before allocation was not checked for integer overflow.&lt;br /&gt;
&lt;br /&gt;
This might allow for ARM11 kernel code-execution.&lt;br /&gt;
&lt;br /&gt;
(Applies to svcSetResourceLimitValues, svcGetThreadList, svcGetProcessList, svcReplyAndReceive, svcWaitSynchronizationN.)&lt;br /&gt;
| &lt;br /&gt;
| [[5.0.0-11]]&lt;br /&gt;
| &lt;br /&gt;
| v4.1 FIRM -&amp;gt; v5.0 code diff&lt;br /&gt;
| [[User:Plutooo|plutoo]], [[User:Yellows8|Yellows8]] complementary&lt;br /&gt;
|-&lt;br /&gt;
| [[SVC|svcControlMemory]] MemoryOperation MAP memory-permissions&lt;br /&gt;
| 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&#039;t check memory permissions for addr1. Therefore .text as addr1 could be mapped elsewhere as RW- memory, which allowed ARM11 userland code-execution.&lt;br /&gt;
| &lt;br /&gt;
| [[4.1.0-8]]&lt;br /&gt;
| &lt;br /&gt;
| 2012&lt;br /&gt;
| [[User:Yellows8|Yellows8]]&lt;br /&gt;
|-&lt;br /&gt;
| [[RPC_Command_Structure|Command]] input/output buffer permissions&lt;br /&gt;
| Originally the ARM11 kernel didn&#039;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&#039;t have the required memory permissions. For example, this allowed a FSUSER file-read to .text, which therefore allowed ARM11-userland code execution.&lt;br /&gt;
| &lt;br /&gt;
| [[4.0.0-7]]&lt;br /&gt;
| &lt;br /&gt;
| 2012&lt;br /&gt;
| [[User:Yellows8|Yellows8]]&lt;br /&gt;
|-&lt;br /&gt;
| [[SVC|svcReadProcessMemory/svcWriteProcessMemory memory]] permissions&lt;br /&gt;
| 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.&lt;br /&gt;
| &lt;br /&gt;
| [[4.0.0-7]]&lt;br /&gt;
| &lt;br /&gt;
| 2012?&lt;br /&gt;
| [[User:Yellows8|Yellows8]]&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
=== [[FIRM]] Sysmodules ===&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot; border=&amp;quot;1&amp;quot;&lt;br /&gt;
|-&lt;br /&gt;
!  Summary&lt;br /&gt;
!  Description&lt;br /&gt;
!  Successful exploitation result&lt;br /&gt;
!  Fixed in [[FIRM]] system version&lt;br /&gt;
!  Last [[FIRM]] system version this flaw was checked for&lt;br /&gt;
!  Timeframe this was discovered&lt;br /&gt;
!  Discovered by&lt;br /&gt;
|-&lt;br /&gt;
| [[Services|&amp;quot;srv:pm&amp;quot;]] process registration&lt;br /&gt;
| Originally any process had access to the port &amp;quot;srv:pm&amp;quot;. The PID&#039;s used for the (un)registration commands are not checked either. This allowed any process to re-register itself with &amp;quot;srv:pm&amp;quot;, and therefore allowed the process to give itself access to any service, bypassing the exheader service-access-control list.&lt;br /&gt;
&lt;br /&gt;
This was fixed in [[7.0.0-13]]: starting with [[7.0.0-13]] &amp;quot;srv:pm&amp;quot; is now a service instead of a globally accessible port. Only processes with PID&#039;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 &amp;quot;srv:pm&amp;quot; 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.&lt;br /&gt;
&lt;br /&gt;
This flaw was needed for exploiting the &amp;lt;=v4.x Process9 PXI vulnerabilities from ARM11 userland ROP, since most applications don&#039;t have access to those service(s).&lt;br /&gt;
| Access to arbitrary services&lt;br /&gt;
| [[7.0.0-13]]&lt;br /&gt;
| &lt;br /&gt;
| 2012&lt;br /&gt;
| [[User:Yellows8|Yellows8]]&lt;br /&gt;
|-&lt;br /&gt;
| FSDIR null-deref&lt;br /&gt;
| [[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&#039;s just a null-deref.&lt;br /&gt;
| &lt;br /&gt;
| None&lt;br /&gt;
| [[9.6.0-24|9.6.0-X]]&lt;br /&gt;
| May 19(?)-20, 2015&lt;br /&gt;
| [[User:Yellows8|Yellows8]]&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
=== Standalone Sysmodules ===&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot; border=&amp;quot;1&amp;quot;&lt;br /&gt;
|-&lt;br /&gt;
!  Summary&lt;br /&gt;
!  Description&lt;br /&gt;
!  Successful exploitation result&lt;br /&gt;
!  Fixed in system-module system-version&lt;br /&gt;
!  Last system-module system-version this flaw was checked for&lt;br /&gt;
!  Timeframe this was discovered&lt;br /&gt;
!  Timeframe this was added to wiki&lt;br /&gt;
!  Discovered by&lt;br /&gt;
|-&lt;br /&gt;
| AM stack/.bss infoleak via [[AM:ReadTwlBackupInfo]]([[AM:ReadTwlBackupInfoEx|Ex]])&lt;br /&gt;
| 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.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;This was not tested on hardware.&#039;&#039;&#039;&lt;br /&gt;
| Stack/.bss reading&lt;br /&gt;
| None&lt;br /&gt;
| [[10.0.0-27]](AM v9217)&lt;br /&gt;
| Roughly October 17, 2016&lt;br /&gt;
| October 25, 2016&lt;br /&gt;
| [[User:Yellows8|Yellows8]]&lt;br /&gt;
|-&lt;br /&gt;
| [[MVD_Services|MVD]]: Stack buffer overflow with [[MVDSTD:SetupOutputBuffers]].&lt;br /&gt;
| 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-&amp;gt;physaddrs used there are also copied to stack(0x8-bytes of physaddrs per entry).&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
| MVD-sysmodule crash.&lt;br /&gt;
| None&lt;br /&gt;
| [[9.0.0-20]]&lt;br /&gt;
| April 22, 2016 (Tested on the 25th)&lt;br /&gt;
| April 25, 2016&lt;br /&gt;
| [[User:Yellows8|Yellows8]]&lt;br /&gt;
|-&lt;br /&gt;
| [[NWM_Services|NWM]]: Using CTRSDK heap with UDS sharedmem from the user-process.&lt;br /&gt;
| See the HTTP-sysmodule section below.&lt;br /&gt;
&lt;br /&gt;
CTRSDK heap is used with the sharedmem from [[NWMUDS:InitializeWithVersion]]. Buffers are allocated/freed under this heap using [[NWMUDS:Bind]] and [[NWMUDS:Unbind]].&lt;br /&gt;
&lt;br /&gt;
Hence, overwriting sharedmem with gspwn then using [[NWMUDS:Unbind]] results in the usual controlled CTRSDK memchunk-header write, similar to HTTP-sysmodule.&lt;br /&gt;
&lt;br /&gt;
This could be done by creating an UDS network, without any other nodes on the network.&lt;br /&gt;
&lt;br /&gt;
Besides CTRSDK memchunk-headers, there are no addresses stored under this sharedmem.&lt;br /&gt;
| ROP under NWM-module.&lt;br /&gt;
| None&lt;br /&gt;
| [[9.0.0-20|9.0.0-X]]&lt;br /&gt;
| April 10, 2016&lt;br /&gt;
| April 16, 2016&lt;br /&gt;
| [[User:Yellows8|Yellows8]]&lt;br /&gt;
|-&lt;br /&gt;
| [[DLP_Services|DLP]]: Out-of-bounds memory access during spectator [[Download_Play|data-frame]] checksum calculation&lt;br /&gt;
| DLP doesn&#039;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&#039;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.&lt;br /&gt;
&lt;br /&gt;
Hence, using a large frame_size like 0xFFFF will result in the checksum calculation code reading data out-of-bounds. This isn&#039;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&#039;s about all(trying to infoleak with this likely isn&#039;t useful either).&lt;br /&gt;
| DLP-sysmodule crash, handled by dlplay system-application by a &amp;quot;connection interrupted&amp;quot; error eventually then a fatal-error via ErrDisp.&lt;br /&gt;
| None&lt;br /&gt;
| [[10.0.0-27|10.0.0-X]]&lt;br /&gt;
| April 8, 2016 (Tested on the 10th)&lt;br /&gt;
| April 10, 2016&lt;br /&gt;
| [[User:Yellows8|Yellows8]]&lt;br /&gt;
|-&lt;br /&gt;
| [[DLP_Services|DLP]]: Out-of-bounds output data writing during spectator sysupdate titlelist [[Download_Play|data-frame]] handling&lt;br /&gt;
| 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.&lt;br /&gt;
&lt;br /&gt;
There&#039;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.&lt;br /&gt;
&lt;br /&gt;
There&#039;s no known way to exploit the above crash, since the linked-list code involves writes zeros(with a controlled start ptr).&lt;br /&gt;
| &lt;br /&gt;
| None&lt;br /&gt;
| [[10.0.0-27|10.0.0-X]]&lt;br /&gt;
| April 8-9, 2016&lt;br /&gt;
| April 10, 2016&lt;br /&gt;
| [[User:Yellows8|Yellows8]]&lt;br /&gt;
|-&lt;br /&gt;
| [[IR_Services|IR]]: Stack buffer overflow with custom hardware&lt;br /&gt;
| 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.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
| ROP under IR sysmodule.&lt;br /&gt;
| [[10.6.0-31|10.6.0-31]]&lt;br /&gt;
| &lt;br /&gt;
| February 23, 2016 (Unknown if it was noticed before then)&lt;br /&gt;
| February 23, 2016&lt;br /&gt;
| [[User:Yellows8|Yellows8]]&lt;br /&gt;
|-&lt;br /&gt;
| [[HTTP_Services|HTTP]]: Using CTRSDK heap with sharedmem from the user-process.&lt;br /&gt;
| 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.&lt;br /&gt;
Normally this sharedmem isn&#039;t accessible to the user-process once the sysmodule maps it, hence using it is supposed to be &amp;quot;safe&amp;quot;.&lt;br /&gt;
&lt;br /&gt;
This isn&#039;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.&lt;br /&gt;
&lt;br /&gt;
This is exploited by [https://github.com/yellows8/ctr-httpwn/ctr-httpwn ctr-httpwn].&lt;br /&gt;
| ROP under HTTP sysmdule.&lt;br /&gt;
| None&lt;br /&gt;
| [[9.6.0-24|9.6.0-X]] (Latest sysmodule version as of [[10.7.0-32|10.7.0-32]])&lt;br /&gt;
| Late 2015&lt;br /&gt;
| March 22, 2016&lt;br /&gt;
| [[User:Yellows8|Yellows8]]&lt;br /&gt;
|-&lt;br /&gt;
| [[NIM_Services|NIM]]: Downloading old title-versions from eShop&lt;br /&gt;
| 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 &#039;&#039;if&#039;&#039; it&#039;s still available from CDN.&lt;br /&gt;
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).&lt;br /&gt;
&lt;br /&gt;
Originally this was tested with a debugging-system via modded-FIRM, eventually smea implemented it in HANS for the 32c3 release.&lt;br /&gt;
| Downloading old title-versions from eShop&lt;br /&gt;
| None&lt;br /&gt;
| [[10.0.0-27|10.0.0-X]]&lt;br /&gt;
| October 24, 2015 (Unknown when exactly the first eShop title downgrade was actually tested, maybe November)&lt;br /&gt;
| January 7, 2016 (Same day Ironfall v1.0 was removed from CDN via the main-CXI files)&lt;br /&gt;
| [[User:Yellows8|Yellows8]]&lt;br /&gt;
|-&lt;br /&gt;
| [[SPI_Services|SPI]] service out-of-bounds write&lt;br /&gt;
| cmd1 has out-of-bounds write allowing overwrite of some static variables in .data.&lt;br /&gt;
| &lt;br /&gt;
| None&lt;br /&gt;
| [[9.5.0-22]]&lt;br /&gt;
| March 2015&lt;br /&gt;
| &lt;br /&gt;
| [[User:Plutooo|plutoo]]&lt;br /&gt;
|-&lt;br /&gt;
| [[NFC_Services|NFC]] module service command buf-overflows&lt;br /&gt;
| NFC module copies data with certain commands, from command input buffers to stack without checking the size. These commands include the following, it&#039;s unknown if there&#039;s more commands with similar issues: &amp;quot;nfc:dev&amp;quot; &amp;lt;0x000C....&amp;gt; and &amp;quot;nfc:s&amp;quot; &amp;lt;0x0037....&amp;gt;.&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
There&#039;s no known retail titles which have access to either of these services.&lt;br /&gt;
| ROP under NFC module.&lt;br /&gt;
| New3DS: None&lt;br /&gt;
| New3DS: [[9.5.0-22]]&lt;br /&gt;
| December 2014?&lt;br /&gt;
| &lt;br /&gt;
| [[User:Yellows8|Yellows8]]&lt;br /&gt;
|-&lt;br /&gt;
| [[News_Services|NEWSS]] service command notificationID validation failure&lt;br /&gt;
| This module does not validate the input notificationID for &amp;lt;nowiki&amp;gt;&amp;quot;news:s&amp;quot;&amp;lt;/nowiki&amp;gt; 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).&lt;br /&gt;
| ROP under news module.&lt;br /&gt;
| None&lt;br /&gt;
| [[9.7.0-25|9.7.0-X]]&lt;br /&gt;
| December 2014&lt;br /&gt;
| &lt;br /&gt;
| [[User:Yellows8|Yellows8]]&lt;br /&gt;
|-&lt;br /&gt;
| [[NWMUDS:DecryptBeaconData]] heap buffer overflow&lt;br /&gt;
| input_size = 0x1E * &amp;lt;value the u8 from input_[[NWM_Services|networkstruct]]+0x1D&amp;gt;. Then input_tag0 is copied to a heap buffer. When input_size is larger than 0xFA-bytes, it will then copy input_tag1 to &amp;lt;end_address_of_previous_outbuf&amp;gt;, with size=input_size-0xFA.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
There&#039;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&#039;t be controlled it seems(with just broadcasting a beacon at least). It&#039;s unknown whether this could be exploited from just using NWMUDS service-cmd(s) directly.&lt;br /&gt;
| 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.&lt;br /&gt;
| None&lt;br /&gt;
| [[9.0.0-20]]&lt;br /&gt;
| ~September 23, 2014(see the [[NWMUDS:DecryptBeaconData]] page history)&lt;br /&gt;
| August 3, 2015&lt;br /&gt;
| [[User:Yellows8|Yellows8]]&lt;br /&gt;
|-&lt;br /&gt;
| [[HID_Services|HID]] module shared-mem&lt;br /&gt;
| 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.&lt;br /&gt;
| ROP under HID module, but this is *very* unlikely to be exploitable since the data written is HID data.&lt;br /&gt;
| None&lt;br /&gt;
| [[9.3.0-21]]&lt;br /&gt;
| 2014?&lt;br /&gt;
| &lt;br /&gt;
| [[User:Yellows8|Yellows8]]&lt;br /&gt;
|-&lt;br /&gt;
| gspwn&lt;br /&gt;
| 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&#039;re running under, and gain real code-execution from a ROP-chain. Normally applets&#039; .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).&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
| User-mode code execution.&lt;br /&gt;
| None&lt;br /&gt;
| [[9.6.0-24|9.6.0-X]]&lt;br /&gt;
| Early 2014&lt;br /&gt;
| &lt;br /&gt;
| smea, [[User:Yellows8|Yellows8]]/others before then&lt;br /&gt;
|-&lt;br /&gt;
| rohax&lt;br /&gt;
| 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.&lt;br /&gt;
&lt;br /&gt;
This was fixed after [[ninjhax]] release by adding checks on [[CRO0]]-based pointers before writing to them.&lt;br /&gt;
| Memory-mapping syscalls.&lt;br /&gt;
| [[9.3.0-21]]&lt;br /&gt;
| [[9.4.0-21]]&lt;br /&gt;
| &lt;br /&gt;
| &lt;br /&gt;
| smea, [[User:Plutooo|plutoo]] joint effort&lt;br /&gt;
|-&lt;br /&gt;
| Region free&lt;br /&gt;
| Only [[Home Menu]] itself checks gamecards&#039; 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.&lt;br /&gt;
This essentially means launching the gamecard with the [[NS_and_APT_Services|&amp;quot;ns:s&amp;quot;]] 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]].&lt;br /&gt;
| Launching gamecards from any region + bypassing Home Menu gamecard-sysupdate installation&lt;br /&gt;
| None&lt;br /&gt;
| Last tested with [[10.1.0-27|10.1.0-X]].&lt;br /&gt;
| June(?) 2014&lt;br /&gt;
| &lt;br /&gt;
| [[User:Yellows8|Yellows8]]&lt;br /&gt;
|-&lt;br /&gt;
| [[NWM_Services|NWM]] service-cmd state null-ptr deref&lt;br /&gt;
| 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.&lt;br /&gt;
It&#039;s unknown whether any NWM services besides NWMUDS have this issue.&lt;br /&gt;
| This is rather useless since it&#039;s only a crash caused by a state ptr based at 0x0.&lt;br /&gt;
| None&lt;br /&gt;
| [[9.0.0-20]]&lt;br /&gt;
| 2013?&lt;br /&gt;
| &lt;br /&gt;
| [[User:Yellows8|Yellows8]]&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
=== General/CTRSDK ===&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot; border=&amp;quot;1&amp;quot;&lt;br /&gt;
|-&lt;br /&gt;
!  Summary&lt;br /&gt;
!  Description&lt;br /&gt;
!  Successful exploitation result&lt;br /&gt;
!  Fixed in version&lt;br /&gt;
!  Last version this flaw was checked for&lt;br /&gt;
!  Timeframe this was discovered&lt;br /&gt;
!  Discovered by&lt;br /&gt;
|-&lt;br /&gt;
| [[NWM_Services|UDS]] beacon additional-data buffer overflow&lt;br /&gt;
| 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.&lt;br /&gt;
This was discovered while doing code RE with an old dlp-module version. It&#039;s unknown in what specific CTRSDK version this was fixed, or even what system-version updated titles with a fixed version.&lt;br /&gt;
&lt;br /&gt;
It&#039;s unknown if there&#039;s any titles using a vulnerable CTRSDK version which are also exploitable with this(dlp module can&#039;t be exploited with this).&lt;br /&gt;
&lt;br /&gt;
The maximum number of bytes that can be written beyond the end of the outbuf is 0x37-bytes, with additionaldata_size=0xFF.&lt;br /&gt;
| Perhaps ROP, very difficult if possible with anything at all&lt;br /&gt;
| ?&lt;br /&gt;
| &lt;br /&gt;
| September(?) 2014&lt;br /&gt;
| [[User:Yellows8|Yellows8]]&lt;br /&gt;
|-&lt;br /&gt;
| CTPK buffer overflow&lt;br /&gt;
| 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&#039;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.&lt;br /&gt;
&lt;br /&gt;
While CTPK(*.ctpk) are normally only loaded from RomFS, some application(s) load from elsewhere too.&lt;br /&gt;
| ROP under the target application.&lt;br /&gt;
| None?&lt;br /&gt;
| &amp;quot;[SDK+NINTENDO:CTR_SDK-11_4_0_200_none]&amp;quot;&lt;br /&gt;
| November 14, 2016&lt;br /&gt;
| [[User:Yellows8|Yellows8]]&lt;br /&gt;
|}&lt;/div&gt;</summary>
		<author><name>Motezazer</name></author>
	</entry>
	<entry>
		<id>https://www.3dbrew.org/w/index.php?title=Talk:3DS_System_Flaws&amp;diff=19129</id>
		<title>Talk:3DS System Flaws</title>
		<link rel="alternate" type="text/html" href="https://www.3dbrew.org/w/index.php?title=Talk:3DS_System_Flaws&amp;diff=19129"/>
		<updated>2017-01-02T19:02:14Z</updated>

		<summary type="html">&lt;p&gt;Motezazer: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;I have a way to freeze the 3DS which might be exploitable - see [[Talk:Internet Browser]]. [[User:R4wrz0rz0r|R4wrz0rz0r]] 14:59, 20 June 2011 (CEST)&lt;br /&gt;
: That crash isn&#039;t exploitable unless you&#039;re extremely lucky. Don&#039;t waste your time. --[[User:Luigi2us|Luigi2us]] 20:44, 15 August 2011 (CEST)&lt;br /&gt;
&lt;br /&gt;
It is not so bad to looking for buffer overflow.&lt;br /&gt;
 But try to know about file system  is more important.&lt;br /&gt;
&lt;br /&gt;
And we do not know enough about CCI,... formats to write an exploit with a loader which loads an executable file!&lt;br /&gt;
Maybe we should try to make a savegame exploit...&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
Yeah, yeah, great hacking plans, kids. What are you going to do once you find a buffer overflow? Blindly write stuff to memory hoping to hit the PICA200 registers someday? Quit wasting your time with buffer overflows. Come back when more is known. --[[User:Luigi2us|Luigi2us]] 20:42, 15 August 2011 (CEST)&lt;br /&gt;
&lt;br /&gt;
         How would you write a 3DS Exploit, Luigi2us?&lt;br /&gt;
&lt;br /&gt;
We should ask Neimod to use his RAM dumping setup to see where link&#039;s name is in OOT:3D. If it is not properly limited, and is near the regions the console executes next, we might be able to get a buffer overflow exploit. We should try to get a way to do a system exploit ASAP with this method &lt;br /&gt;
--[[User:Alex theman|Alex theman]] 16:00, 15 July 2013 (CEST)&lt;br /&gt;
:Dear iirc, neimod use RAM modfication not exploit, and yellow use exploit. --snip-- --[[User:Syphurith|Syphurith]] 06:29, 16 July 2013 (CEST) &lt;br /&gt;
I know that and we should see what would happen, &#039;&#039;&#039;if&#039;&#039;&#039; we could get this exploit running. And by the way you are really mentally handicapped and should not be posting on this wiki period. Third, [http://tvtropes.org/pmwiki/pmwiki.php/Main/CowboyBebopAtHisComputer your a cowboy bebop at his computer]. And I have been on the sega fourms and i know this BS like the back of my hand. Go on the Sega fourm now!. Before you get banned! For stupidity!&lt;br /&gt;
:Orz. All okey. If you are hurted, take my apologize. I&#039;m not wanting to hurt anyone, so not knowing why you&#039;re getting angry. Also i would take no more interests in that gateway (at least before anyone confirmed that). &lt;br /&gt;
:*Buffer overflow is somewhat difficult for ARM executables since there is no-execution flags. So yellow&#039;s is ROP.&lt;br /&gt;
:*If you think you&#039;re very powerful to get new progress just contact him on IRC not here (he merely be here). Also that is your idea that a RAM dump may help so please ask him yourself.&lt;br /&gt;
:*Always be calm. This wiki is not a site for querrals - So if you think i&#039;m wrong OK i&#039;m wrong.&lt;br /&gt;
:&amp;gt;&amp;gt;Head back to continue MSIL hacking.. Have a good time here.--[[User:Syphurith|Syphurith]] 08:16, 18 July 2013 (CEST)&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
SAFE FIRM was only updated once, at 3.0: maybe because of the OTP locking fail? --[[User:motezazer|motezazer]] 20:56, 02 January 2017 (CET)&lt;/div&gt;</summary>
		<author><name>Motezazer</name></author>
	</entry>
	<entry>
		<id>https://www.3dbrew.org/w/index.php?title=3DS_System_Flaws&amp;diff=18541</id>
		<title>3DS System Flaws</title>
		<link rel="alternate" type="text/html" href="https://www.3dbrew.org/w/index.php?title=3DS_System_Flaws&amp;diff=18541"/>
		<updated>2016-11-06T14:30:29Z</updated>

		<summary type="html">&lt;p&gt;Motezazer: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;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]].&lt;br /&gt;
&lt;br /&gt;
=Stale / Rejected Efforts=&lt;br /&gt;
* Neimod has been working on a RAM dumping setup for a little while now. He&#039;s de-soldered the 3DS&#039;s RAM chip and hooked it and the RAM pinouts on the 3DS&#039; 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.&lt;br /&gt;
&lt;br /&gt;
* Someone (who will remain unnamed) has released CFW and CIA installers, all of which is copied from the work of others, or copyrighted material.&lt;br /&gt;
&lt;br /&gt;
==Tips and info==&lt;br /&gt;
The 3DS uses the XN feature of the ARM11 processor. There&#039;s no official way from applications to enable executable permission for memory containing arbitrary unsigned code(there&#039;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.&lt;br /&gt;
&lt;br /&gt;
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).&lt;br /&gt;
&lt;br /&gt;
=System flaws=&lt;br /&gt;
== Hardware ==&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot; border=&amp;quot;1&amp;quot;&lt;br /&gt;
!  Summary&lt;br /&gt;
!  Description&lt;br /&gt;
!  Fixed with hardware model/revision&lt;br /&gt;
!  Newest hardware model/revision this flaw was checked for&lt;br /&gt;
!  Timeframe this was discovered&lt;br /&gt;
!  Discovered by&lt;br /&gt;
|-&lt;br /&gt;
| ARM9/ARM11 bootrom vectors point at unitialized RAM&lt;br /&gt;
| ARM9&#039;s and ARM11&#039;s exception vectors are hardcoded to point at the CPU&#039;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. &lt;br /&gt;
Since RAM isn&#039;t cleared on boot (see below), one can immediately start execution of their own code here to dump bootrom, OTP, etc.&lt;br /&gt;
The ARM9 bootrom does the following at reset:  reset vector branches to another instruction, then branches to bootrom+0x8000. Hence, there&#039;s no way to know for certain when exactly the ARM9 exception-vector data stored in memory gets initialized.&lt;br /&gt;
&lt;br /&gt;
This requires *very* *precise* timing for triggering the hardware fault: it&#039;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&#039;t).&lt;br /&gt;
| None: all available 3DS models at the time of writing have the exact same ARM9/ARM11 bootrom for the unprotected areas.&lt;br /&gt;
| New3DS&lt;br /&gt;
| End of February 2014&lt;br /&gt;
| [[User:Derrek|derrek]], WulfyStylez (May 2015) independently&lt;br /&gt;
|-&lt;br /&gt;
| Missing AES key clearing&lt;br /&gt;
| The hardware AES engine does not clear keys when doing a hard reset/reboot.&lt;br /&gt;
| None&lt;br /&gt;
| New3DS&lt;br /&gt;
| August 2014&lt;br /&gt;
| Mathieulh/Others&lt;br /&gt;
|-&lt;br /&gt;
| No RAM clearing on reboots&lt;br /&gt;
| On an MCU-triggered reboot all RAM including FCRAM/ARM9 memory/AXIWRAM/VRAM keeps its contents.&lt;br /&gt;
| None&lt;br /&gt;
| New3DS&lt;br /&gt;
| March 2014&lt;br /&gt;
| [[User:Derrek|derrek]]&lt;br /&gt;
|-&lt;br /&gt;
| 32bits of actual console-unique TWLNAND keydata&lt;br /&gt;
| 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&#039;s highest bit is always ORed. only 31 bits of the TWL console-unique keydata / TWL consoleID are actually console-unique.&lt;br /&gt;
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).&lt;br /&gt;
| None&lt;br /&gt;
| New3DS&lt;br /&gt;
| 2012?&lt;br /&gt;
| [[User:Yellows8|Yellows8]]&lt;br /&gt;
|-&lt;br /&gt;
| DSi / 3DS-TWL key-generator&lt;br /&gt;
| 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.&lt;br /&gt;
This applies to the keyX/keyY too.&lt;br /&gt;
&lt;br /&gt;
This attack does not work for the 3DS key-generator because keyslots 0-3 are only for TWL keys.&lt;br /&gt;
| None&lt;br /&gt;
| New3DS&lt;br /&gt;
| 2011&lt;br /&gt;
| [[User:Yellows8|Yellows8]]&lt;br /&gt;
|-&lt;br /&gt;
| 3DS key-generator&lt;br /&gt;
| 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.&lt;br /&gt;
&lt;br /&gt;
Several such pairs of matching normal-keys and KeyY values were found, leading to deducing the key-generator function.&lt;br /&gt;
| None&lt;br /&gt;
| New3DS&lt;br /&gt;
| February 2015&lt;br /&gt;
| [[User:Yellows8|Yellows8]], [[User:Plutooo|plutoo]]&lt;br /&gt;
|-&lt;br /&gt;
| FIRM partitions known-plaintext&lt;br /&gt;
| The [[Flash_Filesystem|FIRM partitions]] are encrypted with AES-CTR without a MAC. Since this works by XOR&#039;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.&lt;br /&gt;
&lt;br /&gt;
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).&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
| None&lt;br /&gt;
| New3DS&lt;br /&gt;
| &lt;br /&gt;
| Everyone&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
== ARM9 software ==&lt;br /&gt;
=== arm9loader ===&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot; border=&amp;quot;1&amp;quot;&lt;br /&gt;
|-&lt;br /&gt;
!  Summary&lt;br /&gt;
!  Description&lt;br /&gt;
!  Successful exploitation result&lt;br /&gt;
!  Fixed in [[FIRM]] system version&lt;br /&gt;
!  Last [[FIRM]] system version this flaw was checked for&lt;br /&gt;
!  Timeframe this was discovered&lt;br /&gt;
!  Public disclosure timeframe&lt;br /&gt;
!  Discovered by&lt;br /&gt;
|-&lt;br /&gt;
| Rearrangable keys in the NAND keystore&lt;br /&gt;
| Due to the keystore being encrypted with AES-ECB, one can rearrange blocks and still have the NAND keystore decrypt in a deterministic way. &lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
| arm9loaderhax given existing ARM9 code execution&lt;br /&gt;
| None&lt;br /&gt;
| [[11.2.0-35|11.2.0-X]]&lt;br /&gt;
| Early 2016&lt;br /&gt;
| 27 September 2016&lt;br /&gt;
| Myria, [[User:Dark samus|dark_samus]]; mathieulh (independently); [[User:Plutooo|plutoo]] (independently) + others&lt;br /&gt;
|-&lt;br /&gt;
| Uncleared OTP hash keydata in console-unique 0x11 key-generation&lt;br /&gt;
| 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.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
This can be performed by exploiting the &amp;quot;arm9loaderhax&amp;quot; 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 &amp;lt;[[3.0.0-6|3.0.0-X]].&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
| Derivation of all New3DS keys generated via the NAND keystore (0x1B &amp;quot;Secure4&amp;quot; etc.)&lt;br /&gt;
| None&lt;br /&gt;
| [[11.2.0-35|11.2.0-X]]&lt;br /&gt;
| ~April 2015, implemented in May 2015&lt;br /&gt;
| 13 January 2016&lt;br /&gt;
| [[User:WulfyStylez|WulfyStylez]], [[User:Dazzozo|Dazzozo]], [[User:Shinyquagsire23|shinyquagsire23]] (complimentary + implemented), [[User:Plutooo|plutoo]], Normmatt (discovered independently)&lt;br /&gt;
|-&lt;br /&gt;
| enhanced-arm9loaderhax&lt;br /&gt;
| See the 32c3 3ds talk.&lt;br /&gt;
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&#039;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.&lt;br /&gt;
| arm9loaderhax which automatically occurs at hard-boot.&lt;br /&gt;
| See arm9loaderhax / description.&lt;br /&gt;
| See arm9loaderhax / description.&lt;br /&gt;
| Theorized around mid July, 2015. Later implemented+tested by [[User:Plutooo|plutoo]] and derrek.&lt;br /&gt;
| 32c3 3ds talk (December 27, 2015)&lt;br /&gt;
| [[User:Yellows8|Yellows8]]&lt;br /&gt;
|-&lt;br /&gt;
| Missing verification-block for the 9.6 keys (arm9loaderhax)&lt;br /&gt;
| 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.&lt;br /&gt;
&lt;br /&gt;
Writing an incorrect key to NAND will cause arm9loader to decrypt the ARM9 kernel as garbage and then jump to it.&lt;br /&gt;
&lt;br /&gt;
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&#039;ll find some garbage that jumps to your code.&lt;br /&gt;
&lt;br /&gt;
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. &lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
| Recovery of 6.x [[Savegames#6.0.0-11_Savegame_keyY|save key]]/7.x [[NCCH]] key, access to uncleared OTP hash keydata&lt;br /&gt;
| None&lt;br /&gt;
| [[11.2.0-35|11.2.0-X]]&lt;br /&gt;
| March, 2015&lt;br /&gt;
| &lt;br /&gt;
| [[User:Plutooo|plutoo]]&lt;br /&gt;
|-&lt;br /&gt;
| Uncleared New3DS keyslot 0x11&lt;br /&gt;
| 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.&lt;br /&gt;
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 &amp;lt;=v9.5 New3DS keyXs which are generated by keyslot 0x11.&lt;br /&gt;
&lt;br /&gt;
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]].&lt;br /&gt;
| New3DS keyXs generation&lt;br /&gt;
| 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]].&lt;br /&gt;
| &lt;br /&gt;
| February 3, 2015 (one day after [[9.5.0-22|9.5.0-X]] release)&lt;br /&gt;
| &lt;br /&gt;
| [[User:Yellows8|Yellows8]]&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
=== Process9 ===&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot; border=&amp;quot;1&amp;quot;&lt;br /&gt;
|-&lt;br /&gt;
!  Summary&lt;br /&gt;
!  Description&lt;br /&gt;
!  Successful exploitation result&lt;br /&gt;
!  Fixed in [[FIRM]] system version&lt;br /&gt;
!  Last [[FIRM]] system version this flaw was checked for&lt;br /&gt;
!  Timeframe this was discovered&lt;br /&gt;
!  Public disclosure timeframe&lt;br /&gt;
!  Discovered by&lt;br /&gt;
|-&lt;br /&gt;
| Leak of normal-key matching a key-scrambler key&lt;br /&gt;
| 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 &amp;quot;fixed&amp;quot; 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.&lt;br /&gt;
&lt;br /&gt;
Nintendo&#039;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 &amp;quot;Hardware&amp;quot; above), the key scrambler function could be deduced.&lt;br /&gt;
| Deducing the keyX for keyslot 0x39 and the key scrambler algorithm&lt;br /&gt;
| New 3DS [[9.3.0-21|9.3.0-X]], sort of&lt;br /&gt;
| [[10.0.0-27|10.0.0-X]]&lt;br /&gt;
| Sometime in 2015 after the hardware key-generator was broken.&lt;br /&gt;
| 32c3 3ds talk (December 27, 2015)&lt;br /&gt;
| [[User:Yellows8|Yellows8]]&lt;br /&gt;
|-&lt;br /&gt;
| Leak of normal-key matching a key-generator key&lt;br /&gt;
| During the 3DS&#039; 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.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
Knowing the keyY and the normal-key for common-key index1, the devkit key-generator algorithm can be deduced (see &amp;quot;Hardware&amp;quot; above). Additionally the remaining devkit common-keys can be generated once the common-key keyX is recovered.&lt;br /&gt;
&lt;br /&gt;
Note the devkit key-generator was discovered to be the same as the retail key-generator.&lt;br /&gt;
| Deducing the keyX for keyslot 0x3D and hardware key-generator algorithm. Generate remaining devkit common-keys.&lt;br /&gt;
| pre-[[1.0.0-0|1.0.0-X]]&lt;br /&gt;
| &lt;br /&gt;
| Shortly after the key-generator was revealed to be flawed at the 32c3 3ds talk&lt;br /&gt;
| January 20, 2016&lt;br /&gt;
| [[User:Jakcron|jakcron]]&lt;br /&gt;
|-&lt;br /&gt;
| ntrcardhax&lt;br /&gt;
| &lt;br /&gt;
| ARM9 code execution&lt;br /&gt;
| 10.4.0-29&lt;br /&gt;
| &lt;br /&gt;
| March 2015&lt;br /&gt;
| 32c3 3ds talk (December 27, 2015)&lt;br /&gt;
| [[User:Plutooo|plutoo]]&lt;br /&gt;
|-&lt;br /&gt;
| Title downgrading via [[Application_Manager_Services|AM]]([[Application_Manager_Services_PXI|PXI]])&lt;br /&gt;
| 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.&lt;br /&gt;
&lt;br /&gt;
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&#039;t compare the input title-version with anything. Hence, titles can be downgraded this way.&lt;br /&gt;
&lt;br /&gt;
[[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.&lt;br /&gt;
| Bypassing title version check at installation, which then allows downgrading any title.&lt;br /&gt;
| [[11.0.0-33|11.0.0-X]], for key system titles.&lt;br /&gt;
| NATIVE_FIRM / AM-sysmodule [[11.0.0-33|11.0.0-X]]&lt;br /&gt;
| ?&lt;br /&gt;
| &lt;br /&gt;
| ?&lt;br /&gt;
|-&lt;br /&gt;
| FAT FS code null-deref&lt;br /&gt;
| 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&#039;t check for NULL which then triggers a read based at NULL.&lt;br /&gt;
&lt;br /&gt;
Sample &amp;quot;fsck.vfat -n -v -V &amp;lt;fat image backup&amp;gt;&amp;quot; output for the above crash:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;...&lt;br /&gt;
Starting check/repair pass.&lt;br /&gt;
&amp;lt;FilePath0&amp;gt; and&lt;br /&gt;
&amp;lt;FilePath1&amp;gt;&lt;br /&gt;
 share clusters.&lt;br /&gt;
 Truncating second to 3375104 bytes.&lt;br /&gt;
&amp;lt;FilePath1&amp;gt;&lt;br /&gt;
 File size is 2787392 bytes, cluster chain length is 16384 bytes.&lt;br /&gt;
 Truncating file to 16384 bytes.&lt;br /&gt;
Checking for unused clusters.&lt;br /&gt;
Reclaimed 1 unused cluster (16384 bytes).&lt;br /&gt;
Checking free cluster summary.&lt;br /&gt;
Free cluster summary wrong (1404490 vs. really 1404491)&lt;br /&gt;
 Auto-correcting.&lt;br /&gt;
Starting verification pass.&lt;br /&gt;
Checking for unused clusters.&lt;br /&gt;
Leaving filesystem unchanged.&amp;lt;/pre&amp;gt;&lt;br /&gt;
| Useless null-based-read&lt;br /&gt;
| None&lt;br /&gt;
| [[9.6.0-24|9.6.0-X]]&lt;br /&gt;
| July 8-9, 2015&lt;br /&gt;
| &lt;br /&gt;
| [[User:Yellows8|Yellows8]]&lt;br /&gt;
|-&lt;br /&gt;
| RSA signature padding checks&lt;br /&gt;
| The TWL_FIRM RSA sig padding check code used for all TWL RSA sig-checks has issues, see [[FIRM|here]].&lt;br /&gt;
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&#039;t really a problem here because there&#039;s proper padding check code which is executed prior to this.&lt;br /&gt;
| &lt;br /&gt;
| None&lt;br /&gt;
| [[9.5.0-22|9.5.0-X]]&lt;br /&gt;
| March 2015&lt;br /&gt;
| &lt;br /&gt;
| [[User:Yellows8|Yellows8]]&lt;br /&gt;
|-&lt;br /&gt;
| [[AMPXI:ValidateDSiWareSectionMAC]] [[AES_Registers|AES]] keyslot reuse&lt;br /&gt;
| When the input DSiWare section index is higher than &amp;lt;max number of DSiWare sections supported by this FIRM&amp;gt;, 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 &amp;gt;=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&#039;s unknown whether a timing attack would work with this.&lt;br /&gt;
This is basically a different form of the pxips9 keyslot vuln, except with AESMAC etc.&lt;br /&gt;
| See description.&lt;br /&gt;
| None&lt;br /&gt;
| [[11.2.0-35|11.2.0-X]]&lt;br /&gt;
| March 15, 2015&lt;br /&gt;
| December 29, 2015&lt;br /&gt;
| [[User:Yellows8|Yellows8]]&lt;br /&gt;
|-&lt;br /&gt;
| pxips9 [[AES_Registers|AES]] keyslot reuse&lt;br /&gt;
| 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 &amp;lt;=10.1.0-X(see 32c3 3ds talk).&lt;br /&gt;
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&#039;t return any errors, Process9 will just continue to do crypto with whatever AES keyslot was selected before the PS command was sent.&lt;br /&gt;
| Reusing the previously used keyslot, for crypto with PS.&lt;br /&gt;
| None&lt;br /&gt;
| [[11.2.0-35|11.2.0-X]]&lt;br /&gt;
| Roughly the same time(same day?) as firmlaunch-hax.&lt;br /&gt;
| December 29, 2015&lt;br /&gt;
| [[User:Yellows8|Yellows8]]&lt;br /&gt;
|-&lt;br /&gt;
| firmlaunch-hax: FIRM header ToCToU&lt;br /&gt;
| This can&#039;t be exploited from ARM11 userland.&lt;br /&gt;
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&#039;t expect &amp;quot;anything&amp;quot; besides the ARM9 to access this data.&lt;br /&gt;
With [[9.5.0-22]] the address of this FIRM header was changed from a FCRAM address, to ARM9-only address 0x01fffc00.&lt;br /&gt;
| ARM9 code execution&lt;br /&gt;
| [[9.5.0-22]]&lt;br /&gt;
| &lt;br /&gt;
| 2012, 3 days after [[User:Yellows8|Yellows8]] started Process9 code RE.&lt;br /&gt;
| &lt;br /&gt;
| [[User:Yellows8|Yellows8]]&lt;br /&gt;
|-&lt;br /&gt;
| Uninitialized data output for (PXI) command replies&lt;br /&gt;
| 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.&lt;br /&gt;
Certain ARM11 service commands have this same issue as well.&lt;br /&gt;
| &lt;br /&gt;
| None&lt;br /&gt;
| [[9.3.0-21|9.3.0-X]]&lt;br /&gt;
| ?&lt;br /&gt;
| &lt;br /&gt;
| [[User:Yellows8|Yellows8]]&lt;br /&gt;
|-&lt;br /&gt;
| [[Filesystem_services_PXI|FSPXI]] OpenArchive SD permissions&lt;br /&gt;
| Process9 does not use the exheader ARM9 access-mount permission flag for SD at all.&lt;br /&gt;
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.&lt;br /&gt;
| &lt;br /&gt;
| None&lt;br /&gt;
| [[9.3.0-21|9.3.0-X]]&lt;br /&gt;
| 2012&lt;br /&gt;
| &lt;br /&gt;
| [[User:Yellows8|Yellows8]]&lt;br /&gt;
|-&lt;br /&gt;
| [[AMPXI:ExportDSiWare]] export path&lt;br /&gt;
| 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 &amp;quot;&amp;lt;mountpoint&amp;gt;:/&amp;lt;path&amp;gt;&amp;quot;.&lt;br /&gt;
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.&lt;br /&gt;
| Exporting of DSiWare to arbitrary Process9 file-paths, such as &amp;quot;nand:/&amp;lt;path&amp;gt;&amp;quot; etc. This isn&#039;t really useful since the data which gets written can&#039;t be controlled.&lt;br /&gt;
| None&lt;br /&gt;
| [[9.5.0-22]]&lt;br /&gt;
| April 2013&lt;br /&gt;
| &lt;br /&gt;
| [[User:Yellows8|Yellows8]]&lt;br /&gt;
|-&lt;br /&gt;
| [[DSiWare_Exports]] [[CTCert]] verification&lt;br /&gt;
| 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&#039;s still not(?) fixed.&lt;br /&gt;
On 3DS however this is rather useless, due to the entire DSiWare .bin being encrypted with the console-unique movable.sed keyY.&lt;br /&gt;
| 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.&lt;br /&gt;
| Unknown, probably none.&lt;br /&gt;
| ?&lt;br /&gt;
| April 2013&lt;br /&gt;
| &lt;br /&gt;
| [[User:Yellows8|Yellows8]]&lt;br /&gt;
|-&lt;br /&gt;
| [[Gamecard_Services_PXI]] unchecked REG_CTRCARDCNT transfer-size&lt;br /&gt;
| 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&#039;t checked, thus out-of-bounds reads could be triggered(which is rather useless in this case).&lt;br /&gt;
| Out-of-bounds read for a value which gets written to a register.&lt;br /&gt;
| [[5.0.0-11|5.0.0-X]]&lt;br /&gt;
| &lt;br /&gt;
| 2013?&lt;br /&gt;
| &lt;br /&gt;
| [[User:Yellows8|Yellows8]]&lt;br /&gt;
|-&lt;br /&gt;
| [[PXI_Registers|PXI]] cmdbuf buffer overrun&lt;br /&gt;
| The Process9 code responsible [[PXI_Registers|PXI]] communications didn&#039;t verify the size of the incoming command before writing it to a C++ member variable. &lt;br /&gt;
| Probably ARM9 code execution&lt;br /&gt;
| [[5.0.0-11|5.0.0-11]]&lt;br /&gt;
| &lt;br /&gt;
| March 2015, original timeframe if any unknown&lt;br /&gt;
| &lt;br /&gt;
| [[User:Plutooo|plutoo]]/[[User:Yellows8|Yellows8]]/maybe others(?)&lt;br /&gt;
|-&lt;br /&gt;
| [[Application_Manager_Services_PXI|PXIAM]] command 0x003D0108(See also [[Application_Manager_Services|this]])&lt;br /&gt;
| 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 &amp;lt;=0x2800.&lt;br /&gt;
| ARM9 code execution&lt;br /&gt;
| [[5.0.0-11|5.0.0-X]]&lt;br /&gt;
| &lt;br /&gt;
| May 2013&lt;br /&gt;
| &lt;br /&gt;
| [[User:Yellows8|Yellows8]]&lt;br /&gt;
|-&lt;br /&gt;
| [[Process_Services_PXI|PS RSA]] commands buffer overflows&lt;br /&gt;
| pxips9 cmd1(not accessible via ps:ps) and VerifyRsaSha256: unchecked copy to a buffer in Process9&#039;s .bss, from the input FCRAM buffer. The buffer is located before the pxi cmdhandler threads&#039; stacks. SignRsaSha256 also has a buf overflow, but this isn&#039;t exploitable.&lt;br /&gt;
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]].&lt;br /&gt;
| ARM9 code execution&lt;br /&gt;
| [[5.0.0-11|5.0.0-X]]&lt;br /&gt;
| &lt;br /&gt;
| 2012&lt;br /&gt;
| &lt;br /&gt;
| [[User:Yellows8|Yellows8]]&lt;br /&gt;
|-&lt;br /&gt;
| [[PXI_Registers|PXI]] pxi_id bad check&lt;br /&gt;
| The Process9 code responsible for [[PXI_Registers|PXI]] communications read pxi_id as a signed char. There were two flaws:&lt;br /&gt;
* They used it as index to a lookup-table without checking the value at all.&lt;br /&gt;
* Another function verified that pxi_id &amp;lt; 7, allowing negative values to pass the check. This would also cause an out-of-range table-lookup.&lt;br /&gt;
| Maybe ARM9 code execution&lt;br /&gt;
| [[3.0.0-5|3.0.0-5]]&lt;br /&gt;
|&lt;br /&gt;
| March 2015, originally 2012 for the first issue at least&lt;br /&gt;
| &lt;br /&gt;
| [[User:Plutooo|plutoo]], [[User:Yellows8|Yellows8]], maybe others(?)&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
=== Kernel9 ===&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot; border=&amp;quot;1&amp;quot;&lt;br /&gt;
|-&lt;br /&gt;
!  Summary&lt;br /&gt;
!  Description&lt;br /&gt;
!  Successful exploitation result&lt;br /&gt;
!  Fixed in [[FIRM]] system version&lt;br /&gt;
!  Last [[FIRM]] system version this flaw was checked for&lt;br /&gt;
!  Timeframe this was discovered&lt;br /&gt;
!  Discovered by&lt;br /&gt;
|-&lt;br /&gt;
| [[CONFIG Registers#CFG_SYSPROT9|CFG_SYSPROT9]] bit1 not set by Kernel9&lt;br /&gt;
| 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&#039;s never locked, you can dump it once you get ARM9 code execution.&lt;br /&gt;
&lt;br /&gt;
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).&lt;br /&gt;
&lt;br /&gt;
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 -&amp;gt; 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.&lt;br /&gt;
| Dumping of the [[OTP Registers|OTP]] area&lt;br /&gt;
| [[3.0.0-5|3.0.0-X]]&lt;br /&gt;
|&lt;br /&gt;
| February 2015&lt;br /&gt;
| [[User:Plutooo|plutoo]], Normmatt independently&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
== ARM11 software ==&lt;br /&gt;
=== Kernel11 ===&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot; border=&amp;quot;1&amp;quot;&lt;br /&gt;
|-&lt;br /&gt;
!  Summary&lt;br /&gt;
!  Description&lt;br /&gt;
!  Successful exploitation result&lt;br /&gt;
!  Fixed in [[FIRM]] system version&lt;br /&gt;
!  Last [[FIRM]] system version this flaw was checked for&lt;br /&gt;
!  Timeframe this was discovered&lt;br /&gt;
!  Discovered by&lt;br /&gt;
|-&lt;br /&gt;
|  [[SVC]] table too small&lt;br /&gt;
|  The table of function pointers for SVC&#039;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.&lt;br /&gt;
&lt;br /&gt;
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&#039;t mapped as executable.&lt;br /&gt;
| &lt;br /&gt;
|  None&lt;br /&gt;
| [[11.2.0-35|11.2.0-X]]&lt;br /&gt;
| 2012&lt;br /&gt;
| Everyone&lt;br /&gt;
|-&lt;br /&gt;
|  [[SVC|svcBackdoor (0x7B)]]&lt;br /&gt;
|  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.&lt;br /&gt;
| See description&lt;br /&gt;
| [[11.0.0-33|11.0.0-X]] (deleted)&lt;br /&gt;
| &lt;br /&gt;
|&lt;br /&gt;
| Everyone&lt;br /&gt;
|-&lt;br /&gt;
| veryslowpidhax&lt;br /&gt;
| &#039;&#039;&#039;This is completely different from the kernelmode-code-execution vuln described in the below separate entry.&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
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 &amp;lt;total ARM11 FIRM modules&amp;gt; to access &#039;&#039;all&#039;&#039; services, without checking exheader service-access-control. This alone does not affect access to [[SVC|SVCs]] at all.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
With launching+terminating a sysmodule repeatedly with this via ns:s, it would take weeks to finish(if not at least about a month?).&lt;br /&gt;
| Access to all [[Services_API|services]].&lt;br /&gt;
| None&lt;br /&gt;
| [[11.2.0-35|11.2.0-X]]&lt;br /&gt;
| 2012 maybe?&lt;br /&gt;
| &lt;br /&gt;
|-&lt;br /&gt;
|  slowhax&lt;br /&gt;
|  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.&lt;br /&gt;
| ARM11 kernel-mode code execution&lt;br /&gt;
| [[11.2.0-35|11.2.0-X]]&lt;br /&gt;
| [[11.2.0-35|11.2.0-X]]&lt;br /&gt;
| 2016?&lt;br /&gt;
| nedwill, derrek, others?&lt;br /&gt;
|-&lt;br /&gt;
| [[Memory_layout#ARM11_Detailed_virtual_memory_map|0xEFF00000]] / 0xDFF00000 ARM11 kernel virtual-memory&lt;br /&gt;
| 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.&lt;br /&gt;
| &lt;br /&gt;
| None&lt;br /&gt;
| [[11.2.0-35|11.2.0-X]]&lt;br /&gt;
| &lt;br /&gt;
| &lt;br /&gt;
|-&lt;br /&gt;
| memchunkhax2.1&lt;br /&gt;
| Nintendo&#039;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.&lt;br /&gt;
derrek&#039;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.&lt;br /&gt;
| ARM11 kernel code execution&lt;br /&gt;
| [[11.0.0-33|11.0.0-X]], via the new [[Memory_Management#MemoryBlockHeader|memchunkhdr]] MAC which prevents modifying memchunkhdr data with DMA.&lt;br /&gt;
| [[11.0.0-33|11.0.0-X]]&lt;br /&gt;
|&lt;br /&gt;
| derrek, aliaspider&lt;br /&gt;
|-&lt;br /&gt;
| memchunkhax2&lt;br /&gt;
| When allocating a block of memory, the &amp;quot;next&amp;quot; pointer of the [[Memory_Management#MemoryBlockHeader|memchunkhdr]] is accessed without being checked after being mapped to userland.&lt;br /&gt;
This allows a race condition, where the process can change the next pointer just before it&#039;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. &lt;br /&gt;
| ARM11 kernel code execution&lt;br /&gt;
| [[10.4.0-29|10.4.0-X]] (partially, see memchunkhax2.1)&lt;br /&gt;
| [[10.4.0-29|10.4.0-X]]&lt;br /&gt;
|&lt;br /&gt;
| derrek&lt;br /&gt;
|-&lt;br /&gt;
| heaphax&lt;br /&gt;
| 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.&lt;br /&gt;
| Code execution with access to all of NS&#039;s privileges. (including downgrading) Code execution within any applet.&lt;br /&gt;
| [[11.0.0-33|11.0.0-X]], via the new [[Memory_Management#MemoryBlockHeader|memchunkhdr]] MAC which prevents modifying memchunkhdr data with DMA.&lt;br /&gt;
| [[11.0.0-33|11.0.0-X]]&lt;br /&gt;
| April 2015 ?&lt;br /&gt;
| smea&lt;br /&gt;
|-&lt;br /&gt;
| snshax&lt;br /&gt;
| Can force creation of Safe NS process into gspwn-able memory, allowing for takeover.&lt;br /&gt;
| Code execution with access to all of NS&#039;s privileges. (including downgrading)&lt;br /&gt;
| [[10.1.0-27|10.1.0-X]]&lt;br /&gt;
| [[10.1.0-27|10.1.0-X]]&lt;br /&gt;
| April 2015 ?&lt;br /&gt;
| smea&lt;br /&gt;
|-&lt;br /&gt;
|  AffinityMask/processorid validation&lt;br /&gt;
|  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.&lt;br /&gt;
The original code with the first 3 did the following: &lt;br /&gt;
* if(u32_processorcount &amp;gt; ~0x80000001)return 0xe0e01bfd;&lt;br /&gt;
* if(s32_processorcount &amp;gt; &amp;lt;total_cores&amp;gt;)return 0xd8e007fd;&lt;br /&gt;
The following code replaced the above:&lt;br /&gt;
* if(u32_processorcount &amp;gt;= &amp;lt;total_cores+1&amp;gt;)return 0xd8e007fd;&lt;br /&gt;
In theory the latter should catch everything that the former did, so it&#039;s unknown if this was really a security issue.&lt;br /&gt;
&lt;br /&gt;
The svcCreateThread changes with [[10.0.0-27|10.0.0-X]] definitely did fix a security issue.&lt;br /&gt;
* Original code: &amp;quot;if(s32_processorid &amp;gt; &amp;lt;total_cores&amp;gt;)return 0xd8e007fd;&amp;quot;&lt;br /&gt;
* New code: &amp;quot;if(s32_processorid &amp;gt;= &amp;lt;total_cores&amp;gt; || s32_processorid &amp;lt;= -4)return 0xd8e007fd;&amp;quot;&lt;br /&gt;
This fixed an off-by-one issue: if one would use processorid=total_cores, which isn&#039;t actually a valid value, svcCreateThread would accept that value on &amp;lt;[[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:&lt;br /&gt;
* Old3DS: Useless kernel-mode crash due to accessing unmapped memory.&lt;br /&gt;
* New3DS: uncontrolled data write into a kernel-mode L1 MMU-table. This isn&#039;t really useful: the data can&#039;t be controlled, and the data which gets overwritten is all-zero anyway(this isn&#039;t anywhere near MMU L1 entries for actually mapped memory).&lt;br /&gt;
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&#039;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)).&lt;br /&gt;
| Nothing useful&lt;br /&gt;
|  [[10.0.0-27|10.0.0-X]]&lt;br /&gt;
| [[10.0.0-27|10.0.0-X]]&lt;br /&gt;
| svcCreateThread issue: May 31, 2015. The rest: September 8, 2015, via v9.6-&amp;gt;v10.0 ARM11-kernel code-diff.&lt;br /&gt;
| [[User:Yellows8|Yellows8]]&lt;br /&gt;
|-&lt;br /&gt;
| memchunkhax&lt;br /&gt;
| 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.&lt;br /&gt;
&lt;br /&gt;
There are &#039;&#039;multiple&#039;&#039; 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.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
| When combined with other flaws: ARM11-kernelmode code execution&lt;br /&gt;
| [[9.3.0-21|9.3.0-21]]&lt;br /&gt;
| &lt;br /&gt;
| February 2014&lt;br /&gt;
| [[User:Yellows8|Yellows8]]&lt;br /&gt;
|-&lt;br /&gt;
| Multiple [[KLinkedListNode|KLinkedListNode]] SlabHeap use after free bugs&lt;br /&gt;
| The ARM11-kernel did access the &#039;key&#039; 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:&lt;br /&gt;
SlabHeap_free(KLinkedListNode);&lt;br /&gt;
KObject *obj = KLinkedListNode-&amp;gt;key;  // the object there might have changed!&lt;br /&gt;
This bug appeared all over the place.&lt;br /&gt;
| ARM11-kernelmode code exec maybe&lt;br /&gt;
| [[8.0.0-18|8.0.0-18]]&lt;br /&gt;
| &lt;br /&gt;
| April 2015&lt;br /&gt;
| [[User:Derrek|derrek]]&lt;br /&gt;
|-&lt;br /&gt;
| PXI [[RPC_Command_Structure|Command]] input/output buffer permissions&lt;br /&gt;
| Originally the ARM11-kernel didn&#039;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.&lt;br /&gt;
| &lt;br /&gt;
| [[6.0.0-11|6.0.0-11]]&lt;br /&gt;
| &lt;br /&gt;
| 2012&lt;br /&gt;
| [[User:Yellows8|Yellows8]]&lt;br /&gt;
|-&lt;br /&gt;
| [[SVC|svcStartInterProcessDma]]&lt;br /&gt;
| For svcStartInterProcessDma, the kernel code had the following flaws:&lt;br /&gt;
&lt;br /&gt;
* 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.&lt;br /&gt;
&lt;br /&gt;
* Integer overflows for srcaddr+size and dstaddr+size are now checked(with [[6.0.0-11]]), which were not checked before.&lt;br /&gt;
&lt;br /&gt;
* 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 &amp;gt;=0x20000000 would result in the kernel reading from the process L1 MMU table, beyond the memory allocated for that MMU table(for vaddr-&amp;gt;physaddr conversion). &lt;br /&gt;
| &lt;br /&gt;
| [[6.0.0-11]]&lt;br /&gt;
| &lt;br /&gt;
| DmaConfig issue: unknown. The rest: 2014&lt;br /&gt;
| [[User:Plutooo|plutoo]], [[User:Yellows8|Yellows8]] independently&lt;br /&gt;
|-&lt;br /&gt;
| [[SVC|svcControlMemory]] Parameter checks&lt;br /&gt;
| For svcControlMemory the parameter check had these two flaws:&lt;br /&gt;
&lt;br /&gt;
* 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&#039;t actually use the input address for LINEAR memory-mapping at all besides the range-checks, so this isn&#039;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.&lt;br /&gt;
&lt;br /&gt;
* Integer overflows on (addr0+size) are now checked that previously weren&#039;t (this also applies to most other address checks elsewhere in the kernel).&lt;br /&gt;
&lt;br /&gt;
| &lt;br /&gt;
| [[5.0.0-11]]&lt;br /&gt;
| &lt;br /&gt;
|&lt;br /&gt;
| [[User:Plutooo|plutoo]]&lt;br /&gt;
|-&lt;br /&gt;
| [[RPC_Command_Structure|Command]] request/response buffer overflow&lt;br /&gt;
| 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.&lt;br /&gt;
&lt;br /&gt;
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 &amp;lt;nowiki&amp;gt;((size&amp;lt;&amp;lt;14) | 2)&amp;lt;/nowiki&amp;gt; to write arbitrary memory to any RW userland memory in the destination process.&lt;br /&gt;
| &lt;br /&gt;
| [[5.0.0-11]]&lt;br /&gt;
| &lt;br /&gt;
| v4.1 FIRM -&amp;gt; v5.0 code diff&lt;br /&gt;
| [[User:Yellows8|Yellows8]]&lt;br /&gt;
|-&lt;br /&gt;
| [[SVC|SVC stack allocation overflows]]&lt;br /&gt;
| &lt;br /&gt;
* 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. &lt;br /&gt;
* The alignment (size+7)&amp;amp;~7 calculation before allocation was not checked for integer overflow.&lt;br /&gt;
&lt;br /&gt;
This might allow for ARM11 kernel code-execution.&lt;br /&gt;
&lt;br /&gt;
(Applies to svcSetResourceLimitValues, svcGetThreadList, svcGetProcessList, svcReplyAndReceive, svcWaitSynchronizationN.)&lt;br /&gt;
| &lt;br /&gt;
| [[5.0.0-11]]&lt;br /&gt;
| &lt;br /&gt;
| v4.1 FIRM -&amp;gt; v5.0 code diff&lt;br /&gt;
| [[User:Plutooo|plutoo]], [[User:Yellows8|Yellows8]] complementary&lt;br /&gt;
|-&lt;br /&gt;
| [[SVC|svcControlMemory]] MemoryOperation MAP memory-permissions&lt;br /&gt;
| 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&#039;t check memory permissions for addr1. Therefore .text as addr1 could be mapped elsewhere as RW- memory, which allowed ARM11 userland code-execution.&lt;br /&gt;
| &lt;br /&gt;
| [[4.1.0-8]]&lt;br /&gt;
| &lt;br /&gt;
| 2012&lt;br /&gt;
| [[User:Yellows8|Yellows8]]&lt;br /&gt;
|-&lt;br /&gt;
| [[RPC_Command_Structure|Command]] input/output buffer permissions&lt;br /&gt;
| Originally the ARM11 kernel didn&#039;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&#039;t have the required memory permissions. For example, this allowed a FSUSER file-read to .text, which therefore allowed ARM11-userland code execution.&lt;br /&gt;
| &lt;br /&gt;
| [[4.0.0-7]]&lt;br /&gt;
| &lt;br /&gt;
| 2012&lt;br /&gt;
| [[User:Yellows8|Yellows8]]&lt;br /&gt;
|-&lt;br /&gt;
| [[SVC|svcReadProcessMemory/svcWriteProcessMemory memory]] permissions&lt;br /&gt;
| 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.&lt;br /&gt;
| &lt;br /&gt;
| [[4.0.0-7]]&lt;br /&gt;
| &lt;br /&gt;
| 2012?&lt;br /&gt;
| [[User:Yellows8|Yellows8]]&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
=== [[FIRM]] Sysmodules ===&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot; border=&amp;quot;1&amp;quot;&lt;br /&gt;
|-&lt;br /&gt;
!  Summary&lt;br /&gt;
!  Description&lt;br /&gt;
!  Successful exploitation result&lt;br /&gt;
!  Fixed in [[FIRM]] system version&lt;br /&gt;
!  Last [[FIRM]] system version this flaw was checked for&lt;br /&gt;
!  Timeframe this was discovered&lt;br /&gt;
!  Discovered by&lt;br /&gt;
|-&lt;br /&gt;
| [[Services|&amp;quot;srv:pm&amp;quot;]] process registration&lt;br /&gt;
| Originally any process had access to the port &amp;quot;srv:pm&amp;quot;. The PID&#039;s used for the (un)registration commands are not checked either. This allowed any process to re-register itself with &amp;quot;srv:pm&amp;quot;, and therefore allowed the process to give itself access to any service, bypassing the exheader service-access-control list.&lt;br /&gt;
&lt;br /&gt;
This was fixed in [[7.0.0-13]]: starting with [[7.0.0-13]] &amp;quot;srv:pm&amp;quot; is now a service instead of a globally accessible port. Only processes with PID&#039;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 &amp;quot;srv:pm&amp;quot; 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.&lt;br /&gt;
&lt;br /&gt;
This flaw was needed for exploiting the &amp;lt;=v4.x Process9 PXI vulnerabilities from ARM11 userland ROP, since most applications don&#039;t have access to those service(s).&lt;br /&gt;
| Access to arbitrary services&lt;br /&gt;
| [[7.0.0-13]]&lt;br /&gt;
| &lt;br /&gt;
| 2012&lt;br /&gt;
| [[User:Yellows8|Yellows8]]&lt;br /&gt;
|-&lt;br /&gt;
| FSDIR null-deref&lt;br /&gt;
| [[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&#039;s just a null-deref.&lt;br /&gt;
| &lt;br /&gt;
| None&lt;br /&gt;
| [[9.6.0-24|9.6.0-X]]&lt;br /&gt;
| May 19(?)-20, 2015&lt;br /&gt;
| [[User:Yellows8|Yellows8]]&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
=== Standalone Sysmodules ===&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot; border=&amp;quot;1&amp;quot;&lt;br /&gt;
|-&lt;br /&gt;
!  Summary&lt;br /&gt;
!  Description&lt;br /&gt;
!  Successful exploitation result&lt;br /&gt;
!  Fixed in system-module system-version&lt;br /&gt;
!  Last system-module system-version this flaw was checked for&lt;br /&gt;
!  Timeframe this was discovered&lt;br /&gt;
!  Timeframe this was added to wiki&lt;br /&gt;
!  Discovered by&lt;br /&gt;
|-&lt;br /&gt;
| AM stack/.bss infoleak via [[AM:ReadTwlBackupInfo]]([[AM:ReadTwlBackupInfoEx|Ex]])&lt;br /&gt;
| 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.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;This was not tested on hardware.&#039;&#039;&#039;&lt;br /&gt;
| Stack/.bss reading&lt;br /&gt;
| None&lt;br /&gt;
| [[10.0.0-27]](AM v9217)&lt;br /&gt;
| Roughly October 17, 2016&lt;br /&gt;
| October 25, 2016&lt;br /&gt;
| [[User:Yellows8|Yellows8]]&lt;br /&gt;
|-&lt;br /&gt;
| [[MVD_Services|MVD]]: Stack buffer overflow with [[MVDSTD:SetupOutputBuffers]].&lt;br /&gt;
| 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-&amp;gt;physaddrs used there are also copied to stack(0x8-bytes of physaddrs per entry).&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
| MVD-sysmodule crash.&lt;br /&gt;
| None&lt;br /&gt;
| [[9.0.0-20]]&lt;br /&gt;
| April 22, 2016 (Tested on the 25th)&lt;br /&gt;
| April 25, 2016&lt;br /&gt;
| [[User:Yellows8|Yellows8]]&lt;br /&gt;
|-&lt;br /&gt;
| [[NWM_Services|NWM]]: Using CTRSDK heap with UDS sharedmem from the user-process.&lt;br /&gt;
| See the HTTP-sysmodule section below.&lt;br /&gt;
&lt;br /&gt;
CTRSDK heap is used with the sharedmem from [[NWMUDS:InitializeWithVersion]]. Buffers are allocated/freed under this heap using [[NWMUDS:Bind]] and [[NWMUDS:Unbind]].&lt;br /&gt;
&lt;br /&gt;
Hence, overwriting sharedmem with gspwn then using [[NWMUDS:Unbind]] results in the usual controlled CTRSDK memchunk-header write, similar to HTTP-sysmodule.&lt;br /&gt;
&lt;br /&gt;
This could be done by creating an UDS network, without any other nodes on the network.&lt;br /&gt;
&lt;br /&gt;
Besides CTRSDK memchunk-headers, there are no addresses stored under this sharedmem.&lt;br /&gt;
| ROP under NWM-module.&lt;br /&gt;
| None&lt;br /&gt;
| [[9.0.0-20|9.0.0-X]]&lt;br /&gt;
| April 10, 2016&lt;br /&gt;
| April 16, 2016&lt;br /&gt;
| [[User:Yellows8|Yellows8]]&lt;br /&gt;
|-&lt;br /&gt;
| [[DLP_Services|DLP]]: Out-of-bounds memory access during spectator [[Download_Play|data-frame]] checksum calculation&lt;br /&gt;
| DLP doesn&#039;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&#039;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.&lt;br /&gt;
&lt;br /&gt;
Hence, using a large frame_size like 0xFFFF will result in the checksum calculation code reading data out-of-bounds. This isn&#039;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&#039;s about all(trying to infoleak with this likely isn&#039;t useful either).&lt;br /&gt;
| DLP-sysmodule crash, handled by dlplay system-application by a &amp;quot;connection interrupted&amp;quot; error eventually then a fatal-error via ErrDisp.&lt;br /&gt;
| None&lt;br /&gt;
| [[10.0.0-27|10.0.0-X]]&lt;br /&gt;
| April 8, 2016 (Tested on the 10th)&lt;br /&gt;
| April 10, 2016&lt;br /&gt;
| [[User:Yellows8|Yellows8]]&lt;br /&gt;
|-&lt;br /&gt;
| [[DLP_Services|DLP]]: Out-of-bounds output data writing during spectator sysupdate titlelist [[Download_Play|data-frame]] handling&lt;br /&gt;
| 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.&lt;br /&gt;
&lt;br /&gt;
There&#039;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.&lt;br /&gt;
&lt;br /&gt;
There&#039;s no known way to exploit the above crash, since the linked-list code involves writes zeros(with a controlled start ptr).&lt;br /&gt;
| &lt;br /&gt;
| None&lt;br /&gt;
| [[10.0.0-27|10.0.0-X]]&lt;br /&gt;
| April 8-9, 2016&lt;br /&gt;
| April 10, 2016&lt;br /&gt;
| [[User:Yellows8|Yellows8]]&lt;br /&gt;
|-&lt;br /&gt;
| [[IR_Services|IR]]: Stack buffer overflow with custom hardware&lt;br /&gt;
| 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.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
| ROP under IR sysmodule.&lt;br /&gt;
| [[10.6.0-31|10.6.0-31]]&lt;br /&gt;
| &lt;br /&gt;
| February 23, 2016 (Unknown if it was noticed before then)&lt;br /&gt;
| February 23, 2016&lt;br /&gt;
| [[User:Yellows8|Yellows8]]&lt;br /&gt;
|-&lt;br /&gt;
| [[HTTP_Services|HTTP]]: Using CTRSDK heap with sharedmem from the user-process.&lt;br /&gt;
| 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.&lt;br /&gt;
Normally this sharedmem isn&#039;t accessible to the user-process once the sysmodule maps it, hence using it is supposed to be &amp;quot;safe&amp;quot;.&lt;br /&gt;
&lt;br /&gt;
This isn&#039;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.&lt;br /&gt;
&lt;br /&gt;
This is exploited by [https://github.com/yellows8/ctr-httpwn/ctr-httpwn ctr-httpwn].&lt;br /&gt;
| ROP under HTTP sysmdule.&lt;br /&gt;
| None&lt;br /&gt;
| [[9.6.0-24|9.6.0-X]] (Latest sysmodule version as of [[10.7.0-32|10.7.0-32]])&lt;br /&gt;
| Late 2015&lt;br /&gt;
| March 22, 2016&lt;br /&gt;
| [[User:Yellows8|Yellows8]]&lt;br /&gt;
|-&lt;br /&gt;
| [[NIM_Services|NIM]]: Downloading old title-versions from eShop&lt;br /&gt;
| 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 &#039;&#039;if&#039;&#039; it&#039;s still available from CDN.&lt;br /&gt;
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).&lt;br /&gt;
&lt;br /&gt;
Originally this was tested with a debugging-system via modded-FIRM, eventually smea implemented it in HANS for the 32c3 release.&lt;br /&gt;
| Downloading old title-versions from eShop&lt;br /&gt;
| None&lt;br /&gt;
| [[10.0.0-27|10.0.0-X]]&lt;br /&gt;
| October 24, 2015 (Unknown when exactly the first eShop title downgrade was actually tested, maybe November)&lt;br /&gt;
| January 7, 2016 (Same day Ironfall v1.0 was removed from CDN via the main-CXI files)&lt;br /&gt;
| [[User:Yellows8|Yellows8]]&lt;br /&gt;
|-&lt;br /&gt;
| [[SPI_Services|SPI]] service out-of-bounds write&lt;br /&gt;
| cmd1 has out-of-bounds write allowing overwrite of some static variables in .data.&lt;br /&gt;
| &lt;br /&gt;
| None&lt;br /&gt;
| [[9.5.0-22]]&lt;br /&gt;
| March 2015&lt;br /&gt;
| &lt;br /&gt;
| [[User:Plutooo|plutoo]]&lt;br /&gt;
|-&lt;br /&gt;
| [[NFC_Services|NFC]] module service command buf-overflows&lt;br /&gt;
| NFC module copies data with certain commands, from command input buffers to stack without checking the size. These commands include the following, it&#039;s unknown if there&#039;s more commands with similar issues: &amp;quot;nfc:dev&amp;quot; &amp;lt;0x000C....&amp;gt; and &amp;quot;nfc:s&amp;quot; &amp;lt;0x0037....&amp;gt;.&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
There&#039;s no known retail titles which have access to either of these services.&lt;br /&gt;
| ROP under NFC module.&lt;br /&gt;
| New3DS: None&lt;br /&gt;
| New3DS: [[9.5.0-22]]&lt;br /&gt;
| December 2014?&lt;br /&gt;
| &lt;br /&gt;
| [[User:Yellows8|Yellows8]]&lt;br /&gt;
|-&lt;br /&gt;
| [[News_Services|NEWSS]] service command notificationID validation failure&lt;br /&gt;
| This module does not validate the input notificationID for &amp;lt;nowiki&amp;gt;&amp;quot;news:s&amp;quot;&amp;lt;/nowiki&amp;gt; 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).&lt;br /&gt;
| ROP under news module.&lt;br /&gt;
| None&lt;br /&gt;
| [[9.7.0-25|9.7.0-X]]&lt;br /&gt;
| December 2014&lt;br /&gt;
| &lt;br /&gt;
| [[User:Yellows8|Yellows8]]&lt;br /&gt;
|-&lt;br /&gt;
| [[NWMUDS:DecryptBeaconData]] heap buffer overflow&lt;br /&gt;
| input_size = 0x1E * &amp;lt;value the u8 from input_[[NWM_Services|networkstruct]]+0x1D&amp;gt;. Then input_tag0 is copied to a heap buffer. When input_size is larger than 0xFA-bytes, it will then copy input_tag1 to &amp;lt;end_address_of_previous_outbuf&amp;gt;, with size=input_size-0xFA.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
There&#039;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&#039;t be controlled it seems(with just broadcasting a beacon at least). It&#039;s unknown whether this could be exploited from just using NWMUDS service-cmd(s) directly.&lt;br /&gt;
| 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.&lt;br /&gt;
| None&lt;br /&gt;
| [[9.0.0-20]]&lt;br /&gt;
| ~September 23, 2014(see the [[NWMUDS:DecryptBeaconData]] page history)&lt;br /&gt;
| August 3, 2015&lt;br /&gt;
| [[User:Yellows8|Yellows8]]&lt;br /&gt;
|-&lt;br /&gt;
| [[HID_Services|HID]] module shared-mem&lt;br /&gt;
| 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.&lt;br /&gt;
| ROP under HID module, but this is *very* unlikely to be exploitable since the data written is HID data.&lt;br /&gt;
| None&lt;br /&gt;
| [[9.3.0-21]]&lt;br /&gt;
| 2014?&lt;br /&gt;
| &lt;br /&gt;
| [[User:Yellows8|Yellows8]]&lt;br /&gt;
|-&lt;br /&gt;
| gspwn&lt;br /&gt;
| 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&#039;re running under, and gain real code-execution from a ROP-chain. Normally applets&#039; .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).&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
| User-mode code execution.&lt;br /&gt;
| None&lt;br /&gt;
| [[9.6.0-24|9.6.0-X]]&lt;br /&gt;
| Early 2014&lt;br /&gt;
| &lt;br /&gt;
| smea, [[User:Yellows8|Yellows8]]/others before then&lt;br /&gt;
|-&lt;br /&gt;
| rohax&lt;br /&gt;
| 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.&lt;br /&gt;
&lt;br /&gt;
This was fixed after [[ninjhax]] release by adding checks on [[CRO0]]-based pointers before writing to them.&lt;br /&gt;
| Memory-mapping syscalls.&lt;br /&gt;
| [[9.3.0-21]]&lt;br /&gt;
| [[9.4.0-21]]&lt;br /&gt;
| &lt;br /&gt;
| &lt;br /&gt;
| smea, [[User:Plutooo|plutoo]] joint effort&lt;br /&gt;
|-&lt;br /&gt;
| Region free&lt;br /&gt;
| Only [[Home Menu]] itself checks gamecards&#039; 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.&lt;br /&gt;
This essentially means launching the gamecard with the [[NS_and_APT_Services|&amp;quot;ns:s&amp;quot;]] 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]].&lt;br /&gt;
| Launching gamecards from any region + bypassing Home Menu gamecard-sysupdate installation&lt;br /&gt;
| None&lt;br /&gt;
| Last tested with [[10.1.0-27|10.1.0-X]].&lt;br /&gt;
| June(?) 2014&lt;br /&gt;
| &lt;br /&gt;
| [[User:Yellows8|Yellows8]]&lt;br /&gt;
|-&lt;br /&gt;
| [[NWM_Services|NWM]] service-cmd state null-ptr deref&lt;br /&gt;
| 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.&lt;br /&gt;
It&#039;s unknown whether any NWM services besides NWMUDS have this issue.&lt;br /&gt;
| This is rather useless since it&#039;s only a crash caused by a state ptr based at 0x0.&lt;br /&gt;
| None&lt;br /&gt;
| [[9.0.0-20]]&lt;br /&gt;
| 2013?&lt;br /&gt;
| &lt;br /&gt;
| [[User:Yellows8|Yellows8]]&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
=== General/CTRSDK ===&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot; border=&amp;quot;1&amp;quot;&lt;br /&gt;
|-&lt;br /&gt;
!  Summary&lt;br /&gt;
!  Description&lt;br /&gt;
!  Successful exploitation result&lt;br /&gt;
!  Fixed in version&lt;br /&gt;
!  Last version this flaw was checked for&lt;br /&gt;
!  Timeframe this was discovered&lt;br /&gt;
!  Discovered by&lt;br /&gt;
|-&lt;br /&gt;
| [[NWM_Services|UDS]] beacon additional-data buffer overflow&lt;br /&gt;
| 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.&lt;br /&gt;
This was discovered while doing code RE with an old dlp-module version. It&#039;s unknown in what specific CTRSDK version this was fixed, or even what system-version updated titles with a fixed version.&lt;br /&gt;
&lt;br /&gt;
It&#039;s unknown if there&#039;s any titles using a vulnerable CTRSDK version which are also exploitable with this(dlp module can&#039;t be exploited with this).&lt;br /&gt;
&lt;br /&gt;
The maximum number of bytes that can be written beyond the end of the outbuf is 0x37-bytes, with additionaldata_size=0xFF.&lt;br /&gt;
| Perhaps ROP, very difficult if possible with anything at all&lt;br /&gt;
| ?&lt;br /&gt;
| &lt;br /&gt;
| September(?) 2014&lt;br /&gt;
| [[User:Yellows8|Yellows8]]&lt;br /&gt;
|}&lt;/div&gt;</summary>
		<author><name>Motezazer</name></author>
	</entry>
	<entry>
		<id>https://www.3dbrew.org/w/index.php?title=11.2.0-35&amp;diff=18540</id>
		<title>11.2.0-35</title>
		<link rel="alternate" type="text/html" href="https://www.3dbrew.org/w/index.php?title=11.2.0-35&amp;diff=18540"/>
		<updated>2016-11-06T00:56:15Z</updated>

		<summary type="html">&lt;p&gt;Motezazer: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;The Old3DS+New3DS 11.2.0-35 system update was released on October 24, 2016. This Old3DS update was released for the following regions: USA, EUR, JPN, CHN, KOR, and TWN. This New3DS update was released for the following regions: USA, EUR, JPN, CHN, KOR, and TWN.&lt;br /&gt;
&lt;br /&gt;
Security flaws fixed: &amp;lt;fill this in manually later, see the updatedetails page from the ninupdates-report page(s) once available for now&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
==Change-log==&lt;br /&gt;
[http://en-americas-support.nintendo.com/app/answers/detail/a_id/667/p/430/c/267 Official] USA change-log:&lt;br /&gt;
* Further improvements to overall system stability and other minor adjustments have been made to enhance the user experience&lt;br /&gt;
&lt;br /&gt;
==System Titles==&lt;br /&gt;
===NATIVE_FIRM===&lt;br /&gt;
====Process9====&lt;br /&gt;
Actual code changed in Process9 .text. 2 functions were updated, and 1 new function was added which is called by the first function(see below).&lt;br /&gt;
&lt;br /&gt;
The same function that was updated on [[11.0.0-33|11.0.0-33]] (to check minimum versions when installing titles) was updated again: the versions of the titles to install are now checked &#039;&#039;twice&#039;&#039;. This is an attempt to fix a race condition.&lt;br /&gt;
&lt;br /&gt;
====New3DS [[FIRM|arm9loader]]====&lt;br /&gt;
The arm9loader wasn&#039;t changed.&lt;br /&gt;
&lt;br /&gt;
====ARM11-kernel====&lt;br /&gt;
3 functions were updated.&lt;br /&gt;
&lt;br /&gt;
The first one is the actual handler function for svcWaitSynchronizationN.&lt;br /&gt;
&lt;br /&gt;
After incrementing the counter with ldrex/strex, the last two functions now load the counter with plain ldr and executes kernelpanic() when it&#039;s zero.&lt;br /&gt;
&lt;br /&gt;
====Modules====&lt;br /&gt;
The only updated FIRM module was loader.&lt;br /&gt;
&lt;br /&gt;
=====loader=====&lt;br /&gt;
Only one function was updated, the same function involved with codebin-physmem-randomization as the previous updates.&lt;br /&gt;
&lt;br /&gt;
All added titles:&lt;br /&gt;
* JPN/USA/EUR/CHN/TWN Paper Mario: Sticker Star&lt;br /&gt;
* JPN/USA/EUR Steel Diver: Sub Wars&lt;br /&gt;
&lt;br /&gt;
When handling an APPLICATION memregion process and the uniqueID doesn&#039;t match any of the hard-coded ones, this then loads the [[NCCH/Extended_Header|exheader]] kernel release version. If loaded successfully, the codebin-physmem-randomization is automatically enabled if the version is &amp;gt;=0x234([[FIRM]] 2.52 for 11.2.0-35). Hence, all applications built for &amp;gt;=11.2.0-35 and have the kernel release version field will have codebin-physmem-randomization automatically enabled.&lt;br /&gt;
&lt;br /&gt;
===friends-sysmodule===&lt;br /&gt;
Like past updates the only change was updating fdpver(changed from 7 to 8).&lt;br /&gt;
&lt;br /&gt;
===mint===&lt;br /&gt;
Only updated for EUR. ExeFS .code and &amp;quot;romfs:/message/EU_Spanish/mint.msbt.lz&amp;quot; were updated.&lt;br /&gt;
&lt;br /&gt;
===eShop===&lt;br /&gt;
The eShop system-application was only updated for EUR. ExeFS .code was updated, no change for RomFS.&lt;br /&gt;
&lt;br /&gt;
==See Also==&lt;br /&gt;
System update report(s):&lt;br /&gt;
* [https://yls8.mtheall.com/ninupdates/reports.php?date=10-24-16_08-00-49&amp;amp;sys=ctr]&lt;br /&gt;
* [https://yls8.mtheall.com/ninupdates/reports.php?date=10-24-16_08-01-02&amp;amp;sys=ktr]&lt;/div&gt;</summary>
		<author><name>Motezazer</name></author>
	</entry>
	<entry>
		<id>https://www.3dbrew.org/w/index.php?title=Homebrew_Exploits&amp;diff=17329</id>
		<title>Homebrew Exploits</title>
		<link rel="alternate" type="text/html" href="https://www.3dbrew.org/w/index.php?title=Homebrew_Exploits&amp;diff=17329"/>
		<updated>2016-05-10T19:29:28Z</updated>

		<summary type="html">&lt;p&gt;Motezazer: The wrong version number was edited.&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;==Standalone Homebrew Launcher Exploits==&lt;br /&gt;
The following homebrew exploits can be executed on a previously un-exploited system.&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot; border=&amp;quot;1&amp;quot;&lt;br /&gt;
|-&lt;br /&gt;
!  Works on latest fw&lt;br /&gt;
!  Name&lt;br /&gt;
!  Supported firmwares&lt;br /&gt;
!  Requirements&lt;br /&gt;
!  Author&lt;br /&gt;
!  Install&lt;br /&gt;
|-&lt;br /&gt;
| style=&amp;quot;background: salmon&amp;quot; | No&lt;br /&gt;
| [[ninjhax|Ninjhax 1.1b]]&lt;br /&gt;
| From &#039;&#039;&#039;4.0.0-7&#039;&#039;&#039; up to and including &#039;&#039;&#039;9.2.0-20&#039;&#039;&#039;.&lt;br /&gt;
| A cartridge or eShop version (JPN-only) of &amp;quot;Cubic Ninja&amp;quot;.&lt;br /&gt;
| smea&lt;br /&gt;
| [http://smealum.net/ninjhax/ Install]&lt;br /&gt;
|-&lt;br /&gt;
| style=&amp;quot;background: salmon&amp;quot; | No, needs updated.&lt;br /&gt;
| [[ninjhax|Ninjhax 2.5]]&lt;br /&gt;
| From &#039;&#039;&#039;9.0.0-7&#039;&#039;&#039; up to and including &#039;&#039;&#039;10.7.0-32&#039;&#039;&#039;.&lt;br /&gt;
|  A cartridge or eShop version (JPN-only) of &amp;quot;Cubic Ninja&amp;quot;.&lt;br /&gt;
| smea&lt;br /&gt;
| [https://smealum.github.io/ninjhax2/ Install]&lt;br /&gt;
|-&lt;br /&gt;
| style=&amp;quot;background: lightgreen&amp;quot; | Yes&lt;br /&gt;
| [[smashbroshax|smashbroshax]] (beaconhax)&lt;br /&gt;
| (New 3DS only) From &#039;&#039;&#039;9.0.0-X&#039;&#039;&#039; up to and including &#039;&#039;&#039;11.0.0-33&#039;&#039;&#039;.&lt;br /&gt;
| 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&#039;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.&lt;br /&gt;
| [[User:Yellows8|Yellows8]]&lt;br /&gt;
| [https://github.com/yellows8/3ds_smashbroshax Install]&lt;br /&gt;
|-&lt;br /&gt;
| style=&amp;quot;background: salmon&amp;quot; | No&lt;br /&gt;
| [[browserhax]]&lt;br /&gt;
| (Old 3DS) From &#039;&#039;&#039;9.0.0-16&#039;&#039;&#039; to &#039;&#039;&#039;9.5.0-22&#039;&#039;&#039;, &#039;&#039;&#039;9.5.0-23&#039;&#039;&#039; to &#039;&#039;&#039;9.8.0-25&#039;&#039;&#039;, &#039;&#039;&#039;9.9.0-26&#039;&#039;&#039; to &#039;&#039;&#039;10.1.0-27&#039;&#039;&#039;, &#039;&#039;&#039;10.2.0-28&#039;&#039;&#039; to &#039;&#039;&#039;10.5.0-30&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
(New 3DS) From &#039;&#039;&#039;9.0.0-20&#039;&#039;&#039; to &#039;&#039;&#039;9.2.0-20&#039;&#039;&#039;, &#039;&#039;&#039;9.3.0-21&#039;&#039;&#039; to &#039;&#039;&#039;9.5.0-23&#039;&#039;&#039;, &#039;&#039;&#039;9.6.0-24&#039;&#039;&#039; to &#039;&#039;&#039;9.8.0-25&#039;&#039;&#039;, &#039;&#039;&#039;9.9.0-26&#039;&#039;&#039; to &#039;&#039;&#039;10.1.0-27&#039;&#039;&#039;, &#039;&#039;&#039;10.2.0-28&#039;&#039;&#039; to &#039;&#039;&#039;10.5.0-30&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
Note that the browser-version-check bypass is only usable prior to [[10.7.0-32]].&lt;br /&gt;
| An USA, EUR, or JPN system.&lt;br /&gt;
| [[User:Yellows8|Yellows8]]&lt;br /&gt;
| [http://yls8.mtheall.com/3dsbrowserhax.php Install]&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
==Secondary Exploits==&lt;br /&gt;
Installation of these exploits requires a previously exploited system to install. After installation, they can be used on their own.&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot; border=&amp;quot;1&amp;quot;&lt;br /&gt;
!  Works on latest fw&lt;br /&gt;
!  Name&lt;br /&gt;
!  Supported firmwares&lt;br /&gt;
!  Requirements&lt;br /&gt;
!  Author&lt;br /&gt;
!  Install&lt;br /&gt;
|-&lt;br /&gt;
| style=&amp;quot;background: salmon&amp;quot; | No&lt;br /&gt;
| [[ironhax]]&lt;br /&gt;
| From &#039;&#039;&#039;9.5.0-X&#039;&#039;&#039; up to and including &#039;&#039;&#039;10.3.0-X&#039;&#039;&#039;, for &#039;&#039;&#039;X&#039;&#039;&#039; up to and including 28.&lt;br /&gt;
| A copy of &amp;quot;Ironfall: Invasion&amp;quot; downloaded from eShop before August 11th, 2015. Note the updated version that was released on October 13th, 2015 is not supported.&lt;br /&gt;
| smea&lt;br /&gt;
| [http://smealum.github.io/3ds/ Install]&lt;br /&gt;
|-&lt;br /&gt;
| style=&amp;quot;background: salmon&amp;quot; | No, needs updated.&lt;br /&gt;
| [https://github.com/yellows8/oot3dhax oot3dhax]&lt;br /&gt;
| From &#039;&#039;&#039;9.0.0-X&#039;&#039;&#039; up to and including &#039;&#039;&#039;10.7.0-X&#039;&#039;&#039;, for &#039;&#039;&#039;X&#039;&#039;&#039; up to and including 32.&lt;br /&gt;
| 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. Due to lack of free space with the size of the *hax payload, the only save-slot that can exist in the *gamecard* savedata is the oot3dhax save-slot.&lt;br /&gt;
| Yellows8 / smea et al.&lt;br /&gt;
| See [https://smealum.github.io/3ds/ here].&lt;br /&gt;
|-&lt;br /&gt;
| style=&amp;quot;background: salmon&amp;quot; | No&lt;br /&gt;
| [[menuhax]]&lt;br /&gt;
| From &#039;&#039;&#039;9.0.0-X&#039;&#039;&#039; up to and including &#039;&#039;&#039;10.5.0-X&#039;&#039;&#039;, for &#039;&#039;&#039;X&#039;&#039;&#039; up to and including 30.&lt;br /&gt;
|&lt;br /&gt;
| [[User:Yellows8|Yellows8]]&lt;br /&gt;
| [https://github.com/yellows8/3ds_homemenuhax/releases Download]&lt;br /&gt;
|-&lt;br /&gt;
| style=&amp;quot;background: lightgreen&amp;quot; | Yes&lt;br /&gt;
| [https://github.com/shinyquagsire23/supermysterychunkhax supermysterychunkhax]&lt;br /&gt;
| From &#039;&#039;&#039;9.9.0-X&#039;&#039;&#039; (USA/JPN) / &#039;&#039;&#039;10.2.0-X&#039;&#039;&#039; (EUR) up to and including &#039;&#039;&#039;11.0.0-X&#039;&#039;&#039;, for &#039;&#039;&#039;X&#039;&#039;&#039; up to and including 33.&lt;br /&gt;
| A gamecard or eShop-install of Pokémon Super Mystery Dungeon.&lt;br /&gt;
| Shiny Quagsire / SALT team&lt;br /&gt;
| [https://smd.salthax.org/ Install].&lt;br /&gt;
|-&lt;br /&gt;
| style=&amp;quot;background: lightgreen&amp;quot; | Yes&lt;br /&gt;
| [https://github.com/shinyquagsire23/v_hax (v*)hax]&lt;br /&gt;
| From &#039;&#039;&#039;9.0.0-X&#039;&#039;&#039; up to and including &#039;&#039;&#039;11.0.0-X&#039;&#039;&#039;, for &#039;&#039;&#039;X&#039;&#039;&#039; up to and including 33.&lt;br /&gt;
Note that &#039;&#039;&#039;9.0.0-X&#039;&#039;&#039; is only required for the Homebrew Launcher - the game itself only requires &#039;&#039;&#039;2.1.0-X&#039;&#039;&#039; for primitive userland code execution.&lt;br /&gt;
| A copy of VVVVVV downloaded after March 2012 (v1)&lt;br /&gt;
| Shiny Quagsire / SALT team&lt;br /&gt;
| [https://vvvvvv.salthax.org/ Install].&lt;br /&gt;
|-&lt;br /&gt;
| style=&amp;quot;background: lightgreen&amp;quot; | Yes&lt;br /&gt;
| [https://github.com/Dazzozo/humblehax humblehax]&lt;br /&gt;
| From &#039;&#039;&#039;9.0.0-X&#039;&#039;&#039; (USA/EUR) up to and including &#039;&#039;&#039;11.0.0-X&#039;&#039;&#039;, for &#039;&#039;&#039;X&#039;&#039;&#039; up to and including 33.&lt;br /&gt;
| An eShop-install of Citizens of Earth, featured in the Humble &amp;quot;Friends of Nintendo&amp;quot; Bundle.&lt;br /&gt;
| Dazzozo / SALT team&lt;br /&gt;
| [https://citizens.salthax.org/ Install].&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
==Exploits without Homebrew Launcher (Not recommended)==&lt;br /&gt;
&lt;br /&gt;
&amp;lt;u&amp;gt;&#039;&#039;&#039;Warning:&#039;&#039;&#039;&amp;lt;/u&amp;gt; The following exploits can run code, but are missing a 3DSX launcher. They cannot launch any homebrew in the 3DSX format.&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot; border=&amp;quot;1&amp;quot;&lt;br /&gt;
|-&lt;br /&gt;
!  Works on latest fw&lt;br /&gt;
!  Name&lt;br /&gt;
!  Supported firmwares&lt;br /&gt;
!  Requirements&lt;br /&gt;
!  Author&lt;br /&gt;
!  Install&lt;br /&gt;
|-&lt;br /&gt;
| style=&amp;quot;background: salmon&amp;quot; | No&lt;br /&gt;
| [[browserhax]] (Without the loader in the 3ds_browserhax_common repo)&lt;br /&gt;
| (Old3DS) From &#039;&#039;&#039;2.1.0-4&#039;&#039;&#039; to &#039;&#039;&#039;3.0.0-6&#039;&#039;&#039;, &#039;&#039;&#039;4.0.0-7&#039;&#039;&#039; to &#039;&#039;&#039;4.5.0-10&#039;&#039;&#039;, &#039;&#039;&#039;5.0.0-11&#039;&#039;&#039; to &#039;&#039;&#039;7.0.0-13&#039;&#039;&#039;, &#039;&#039;&#039;7.1.0-16&#039;&#039;&#039; to &#039;&#039;&#039;9.5.0-22&#039;&#039;&#039;, &#039;&#039;&#039;9.5.0-23&#039;&#039;&#039; to &#039;&#039;&#039;9.8.0-25&#039;&#039;&#039;, &#039;&#039;&#039;9.9.0-26&#039;&#039;&#039; to &#039;&#039;&#039;10.1.0-27&#039;&#039;&#039;, &#039;&#039;&#039;10.2.0-28&#039;&#039;&#039; to &#039;&#039;&#039;10.5.0-30&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
(New3DS) From &#039;&#039;&#039;9.0.0-20&#039;&#039;&#039; to &#039;&#039;&#039;9.2.0-20&#039;&#039;&#039;, &#039;&#039;&#039;9.3.0-21&#039;&#039;&#039; to &#039;&#039;&#039;9.5.0-23&#039;&#039;&#039;, &#039;&#039;&#039;9.6.0-24&#039;&#039;&#039; to &#039;&#039;&#039;9.8.0-25&#039;&#039;&#039;, &#039;&#039;&#039;9.9.0-26&#039;&#039;&#039; to &#039;&#039;&#039;10.1.0-27&#039;&#039;&#039;, &#039;&#039;&#039;10.2.0-28&#039;&#039;&#039; to &#039;&#039;&#039;10.5.0-30&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
Note that the browser-version-check bypass is only usable prior to [[10.7.0-32]].&lt;br /&gt;
| An USA, EUR, or JPN system.&lt;br /&gt;
| [[User:Yellows8|Yellows8]]&lt;br /&gt;
| [[browserhax|Install]]&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
==Previous Exploits==&lt;br /&gt;
&amp;lt;u&amp;gt;&#039;&#039;&#039;Warning:&#039;&#039;&#039;&amp;lt;/u&amp;gt; These exploits &#039;&#039;&#039;do not work&#039;&#039;&#039;. They are exploits which no longer function at all, regardless of software or firmware revision.&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot; border=&amp;quot;1&amp;quot;&lt;br /&gt;
!  Works on latest fw&lt;br /&gt;
! Name&lt;br /&gt;
! Supported firmwares&lt;br /&gt;
! Requirements&lt;br /&gt;
! Author&lt;br /&gt;
! Install&lt;br /&gt;
|-&lt;br /&gt;
| style=&amp;quot;background: salmon&amp;quot; | No&lt;br /&gt;
| [[tubehax|Tubehax]]&lt;br /&gt;
| None. &#039;&#039;&#039;Was&#039;&#039;&#039;: From &#039;&#039;&#039;9.0.0-X&#039;&#039;&#039; up to and including &#039;&#039;&#039;10.1.0-X&#039;&#039;&#039;, for &#039;&#039;&#039;X&#039;&#039;&#039; up to and including 27.&lt;br /&gt;
| 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]]).&lt;br /&gt;
| smea&lt;br /&gt;
| [http://smealum.github.io/3ds/ Install]&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
==Other Homebrew Loaders==&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
==Sysmodule Exploits==&lt;br /&gt;
This section is for system-module exploits, which can be run from the *hax payloads.&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot; border=&amp;quot;1&amp;quot;&lt;br /&gt;
! Works on latest fw&lt;br /&gt;
! Name&lt;br /&gt;
! Supported firmwares&lt;br /&gt;
! Requirements&lt;br /&gt;
! Author&lt;br /&gt;
|-&lt;br /&gt;
| Yes, that&#039;s not the intended default use however.&lt;br /&gt;
| [https://github.com/yellows8/ctr-httpwn/releases ctr-httpwn]&lt;br /&gt;
| From &#039;&#039;&#039;9.6.0-X&#039;&#039;&#039; up to and including &#039;&#039;&#039;10.7.0-X&#039;&#039;&#039;, for &#039;&#039;&#039;X&#039;&#039;&#039; up to and including 32.&lt;br /&gt;
| None&lt;br /&gt;
| [[User:Yellows8|Yellows8]]&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
==WebKit vuln testing==&lt;br /&gt;
See [https://github.com/yellows8/3ds_browserhax_common/issues/28 here].&lt;/div&gt;</summary>
		<author><name>Motezazer</name></author>
	</entry>
	<entry>
		<id>https://www.3dbrew.org/w/index.php?title=3DS_System_Flaws&amp;diff=17313</id>
		<title>3DS System Flaws</title>
		<link rel="alternate" type="text/html" href="https://www.3dbrew.org/w/index.php?title=3DS_System_Flaws&amp;diff=17313"/>
		<updated>2016-05-10T13:40:08Z</updated>

		<summary type="html">&lt;p&gt;Motezazer: /* Process9 */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;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]].&lt;br /&gt;
&lt;br /&gt;
=Stale / Rejected Efforts=&lt;br /&gt;
* Neimod has been working on a RAM dumping setup for a little while now. He&#039;s de-soldered the 3DS&#039;s RAM chip and hooked it and the RAM pinouts on the 3DS&#039; 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.&lt;br /&gt;
&lt;br /&gt;
* Someone (who will remain unnamed) has released CFW and CIA installers, all of which is copied from the work of others, or copyrighted material.&lt;br /&gt;
&lt;br /&gt;
==Tips and info==&lt;br /&gt;
The 3DS uses the XN feature of the ARM11 processor. There&#039;s no official way from applications to enable executable permission for memory containing arbitrary unsigned code(there&#039;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.&lt;br /&gt;
&lt;br /&gt;
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).&lt;br /&gt;
&lt;br /&gt;
=System flaws=&lt;br /&gt;
== Hardware ==&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot; border=&amp;quot;1&amp;quot;&lt;br /&gt;
!  Summary&lt;br /&gt;
!  Description&lt;br /&gt;
!  Fixed with hardware model/revision&lt;br /&gt;
!  Newest hardware model/revision this flaw was checked for&lt;br /&gt;
!  Timeframe this was discovered&lt;br /&gt;
!  Discovered by&lt;br /&gt;
|-&lt;br /&gt;
| ARM9/ARM11 bootrom vectors point at unitialized RAM&lt;br /&gt;
| ARM9&#039;s and ARM11&#039;s exception vectors are hardcoded to point at the CPU&#039;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. &lt;br /&gt;
Since RAM isn&#039;t cleared on boot (see below), one can immediately start execution of their own code here to dump bootrom, OTP, etc.&lt;br /&gt;
The ARM9 bootrom does the following at reset:  reset vector branches to another instruction, then branches to bootrom+0x8000. Hence, there&#039;s no way to know for certain when exactly the ARM9 exception-vector data stored in memory gets initialized.&lt;br /&gt;
&lt;br /&gt;
This requires *very* *precise* timing for triggering the hardware fault: it&#039;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&#039;t).&lt;br /&gt;
| None: all available 3DS models at the time of writing have the exact same ARM9/ARM11 bootrom for the unprotected areas.&lt;br /&gt;
| New3DS&lt;br /&gt;
| End of February 2014&lt;br /&gt;
| [[User:Derrek|derrek]], WulfyStylez (May 2015) independently&lt;br /&gt;
|-&lt;br /&gt;
| Missing AES key clearing&lt;br /&gt;
| The hardware AES engine does not clear keys when doing a hard reset/reboot.&lt;br /&gt;
| None&lt;br /&gt;
| New3DS&lt;br /&gt;
| August 2014&lt;br /&gt;
| Mathieulh/Others&lt;br /&gt;
|-&lt;br /&gt;
| No RAM clearing on reboots&lt;br /&gt;
| On an MCU-triggered reboot all RAM including FCRAM/ARM9 memory/AXIWRAM/VRAM keeps its contents.&lt;br /&gt;
| None&lt;br /&gt;
| New3DS&lt;br /&gt;
| March 2014&lt;br /&gt;
| [[User:Derrek|derrek]]&lt;br /&gt;
|-&lt;br /&gt;
| 32bits of actual console-unique TWLNAND keydata&lt;br /&gt;
| 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&#039;s highest bit is always ORed. only 31 bits of the TWL console-unique keydata / TWL consoleID are actually console-unique.&lt;br /&gt;
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).&lt;br /&gt;
| None&lt;br /&gt;
| New3DS&lt;br /&gt;
| 2012?&lt;br /&gt;
| [[User:Yellows8|Yellows8]]&lt;br /&gt;
|-&lt;br /&gt;
| DSi / 3DS-TWL key-generator&lt;br /&gt;
| 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.&lt;br /&gt;
This applies to the keyX/keyY too.&lt;br /&gt;
&lt;br /&gt;
This attack does not work for the 3DS key-generator because keyslots 0-3 are only for TWL keys.&lt;br /&gt;
| None&lt;br /&gt;
| New3DS&lt;br /&gt;
| 2011&lt;br /&gt;
| [[User:Yellows8|Yellows8]]&lt;br /&gt;
|-&lt;br /&gt;
| 3DS key-generator&lt;br /&gt;
| 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.&lt;br /&gt;
&lt;br /&gt;
Several such pairs of matching normal-keys and KeyY values were found, leading to deducing the key-generator function.&lt;br /&gt;
| None&lt;br /&gt;
| New3DS&lt;br /&gt;
| February 2015&lt;br /&gt;
| [[User:Yellows8|Yellows8]], [[User:Plutooo|plutoo]]&lt;br /&gt;
|-&lt;br /&gt;
| FIRM partitions known-plaintext&lt;br /&gt;
| The [[Flash_Filesystem|FIRM partitions]] are encrypted with AES-CTR without a MAC. Since this works by XOR&#039;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.&lt;br /&gt;
&lt;br /&gt;
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).&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
| None&lt;br /&gt;
| New3DS&lt;br /&gt;
| &lt;br /&gt;
| Everyone&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
== ARM9 software ==&lt;br /&gt;
=== arm9loader ===&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot; border=&amp;quot;1&amp;quot;&lt;br /&gt;
|-&lt;br /&gt;
!  Summary&lt;br /&gt;
!  Description&lt;br /&gt;
!  Successful exploitation result&lt;br /&gt;
!  Fixed in [[FIRM]] system version&lt;br /&gt;
!  Last [[FIRM]] system version this flaw was checked for&lt;br /&gt;
!  Timeframe this was discovered&lt;br /&gt;
!  Public disclosure timeframe&lt;br /&gt;
!  Discovered by&lt;br /&gt;
|-&lt;br /&gt;
| Uncleared OTP hash keydata in console-unique 0x11 key-generation&lt;br /&gt;
| 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.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
This can be performed by exploiting the &amp;quot;arm9loaderhax&amp;quot; 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 &amp;lt;[[3.0.0-6|3.0.0-X]].&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
| Derivation of all New3DS keys generated via the NAND keystore (0x1B &amp;quot;Secure4&amp;quot; etc.)&lt;br /&gt;
| None&lt;br /&gt;
| [[10.4.0-29|10.4.0-X]]&lt;br /&gt;
| ~April 2015, implemented in May 2015&lt;br /&gt;
| 13 January 2016&lt;br /&gt;
| [[User:WulfyStylez|WulfyStylez]], [[User:Dazzozo|Dazzozo]], [[User:Shinyquagsire23|shinyquagsire23]] (complimentary + implemented), [[User:Plutooo|plutoo]], Normmatt (discovered independently)&lt;br /&gt;
|-&lt;br /&gt;
| enhanced-arm9loaderhax&lt;br /&gt;
| See the 32c3 3ds talk.&lt;br /&gt;
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&#039;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.&lt;br /&gt;
| arm9loaderhax which automatically occurs at hard-boot.&lt;br /&gt;
| See arm9loaderhax / description.&lt;br /&gt;
| See arm9loaderhax / description.&lt;br /&gt;
| Theorized around mid July, 2015. Later implemented+tested by [[User:Plutooo|plutoo]] and derrek.&lt;br /&gt;
| 32c3 3ds talk (December 27, 2015)&lt;br /&gt;
| [[User:Yellows8|Yellows8]]&lt;br /&gt;
|-&lt;br /&gt;
| Missing verification-block for the 9.6 keys (arm9loaderhax)&lt;br /&gt;
| 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.&lt;br /&gt;
&lt;br /&gt;
Writing an incorrect key to NAND will cause arm9loader to decrypt the ARM9 kernel as garbage and then jump to it.&lt;br /&gt;
&lt;br /&gt;
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&#039;ll find some garbage that jumps to your code.&lt;br /&gt;
&lt;br /&gt;
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. &lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
| Recovery of 6.x [[Savegames#6.0.0-11_Savegame_keyY|save key]]/7.x [[NCCH]] key&lt;br /&gt;
| None&lt;br /&gt;
| [[10.4.0-29|10.4.0-X]]&lt;br /&gt;
| March, 2015&lt;br /&gt;
| &lt;br /&gt;
| [[User:Plutooo|plutoo]]&lt;br /&gt;
|-&lt;br /&gt;
| Uncleared New3DS keyslot 0x11&lt;br /&gt;
| 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.&lt;br /&gt;
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 &amp;lt;=v9.5 New3DS keyXs which are generated by keyslot 0x11.&lt;br /&gt;
&lt;br /&gt;
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]].&lt;br /&gt;
| New3DS keyXs generation&lt;br /&gt;
| 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]].&lt;br /&gt;
| &lt;br /&gt;
| February 3, 2015 (one day after [[9.5.0-22|9.5.0-X]] release)&lt;br /&gt;
| &lt;br /&gt;
| [[User:Yellows8|Yellows8]]&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
=== Process9 ===&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot; border=&amp;quot;1&amp;quot;&lt;br /&gt;
|-&lt;br /&gt;
!  Summary&lt;br /&gt;
!  Description&lt;br /&gt;
!  Successful exploitation result&lt;br /&gt;
!  Fixed in [[FIRM]] system version&lt;br /&gt;
!  Last [[FIRM]] system version this flaw was checked for&lt;br /&gt;
!  Timeframe this was discovered&lt;br /&gt;
!  Public disclosure timeframe&lt;br /&gt;
!  Discovered by&lt;br /&gt;
|-&lt;br /&gt;
| Leak of normal-key matching a key-scrambler key&lt;br /&gt;
| 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 &amp;quot;fixed&amp;quot; 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.&lt;br /&gt;
&lt;br /&gt;
Nintendo&#039;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 &amp;quot;Hardware&amp;quot; above), the key scrambler function could be deduced.&lt;br /&gt;
| Deducing the keyX for keyslot 0x39 and the key scrambler algorithm&lt;br /&gt;
| New 3DS [[9.3.0-21|9.3.0-X]], sort of&lt;br /&gt;
| [[10.0.0-27|10.0.0-X]]&lt;br /&gt;
| Sometime in 2015 after the hardware key-generator was broken.&lt;br /&gt;
| 32c3 3ds talk (December 27, 2015)&lt;br /&gt;
| [[User:Yellows8|Yellows8]]&lt;br /&gt;
|-&lt;br /&gt;
| Leak of normal-key matching a key-generator key&lt;br /&gt;
| During the 3DS&#039; 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.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
Knowing the keyY and the normal-key for common-key index1, the devkit key-generator algorithm can be deduced (see &amp;quot;Hardware&amp;quot; above). Additionally the remaining devkit common-keys can be generated once the common-key keyX is recovered.&lt;br /&gt;
&lt;br /&gt;
Note the devkit key-generator was discovered to be the same as the retail key-generator.&lt;br /&gt;
| Deducing the keyX for keyslot 0x3D and hardware key-generator algorithm. Generate remaining devkit common-keys.&lt;br /&gt;
| pre-[[1.0.0-0|1.0.0-X]]&lt;br /&gt;
| &lt;br /&gt;
| Shortly after the key-generator was revealed to be flawed at the 32c3 3ds talk&lt;br /&gt;
| January 20, 2016&lt;br /&gt;
| [[User:Jakcron|jakcron]]&lt;br /&gt;
|-&lt;br /&gt;
| ntrcardhax&lt;br /&gt;
| &lt;br /&gt;
| ARM9 code execution&lt;br /&gt;
| 10.4.0-29&lt;br /&gt;
| &lt;br /&gt;
| March 2015&lt;br /&gt;
| 32c3 3ds talk (December 27, 2015)&lt;br /&gt;
| [[User:Plutooo|plutoo]]&lt;br /&gt;
|-&lt;br /&gt;
| Title downgrading via [[Application_Manager_Services|AM]]([[Application_Manager_Services_PXI|PXI]])&lt;br /&gt;
| 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.&lt;br /&gt;
&lt;br /&gt;
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&#039;t compare the input title-version with anything. Hence, titles can be downgraded this way.&lt;br /&gt;
&lt;br /&gt;
[[11.0.0-33|11.0.0-X]] fixed it 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.&lt;br /&gt;
| Bypassing title version check at installation, which then allows downgrading any title.&lt;br /&gt;
| [[11.0.0-33|11.0.0-X]], for key system titles.&lt;br /&gt;
| NATIVE_FIRM / AM-sysmodule [[11.0.0-33|11.0.0-X]]&lt;br /&gt;
| ?&lt;br /&gt;
| &lt;br /&gt;
| ?&lt;br /&gt;
|-&lt;br /&gt;
| FAT FS code null-deref&lt;br /&gt;
| 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&#039;t check for NULL which then triggers a read based at NULL.&lt;br /&gt;
&lt;br /&gt;
Sample &amp;quot;fsck.vfat -n -v -V &amp;lt;fat image backup&amp;gt;&amp;quot; output for the above crash:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;...&lt;br /&gt;
Starting check/repair pass.&lt;br /&gt;
&amp;lt;FilePath0&amp;gt; and&lt;br /&gt;
&amp;lt;FilePath1&amp;gt;&lt;br /&gt;
 share clusters.&lt;br /&gt;
 Truncating second to 3375104 bytes.&lt;br /&gt;
&amp;lt;FilePath1&amp;gt;&lt;br /&gt;
 File size is 2787392 bytes, cluster chain length is 16384 bytes.&lt;br /&gt;
 Truncating file to 16384 bytes.&lt;br /&gt;
Checking for unused clusters.&lt;br /&gt;
Reclaimed 1 unused cluster (16384 bytes).&lt;br /&gt;
Checking free cluster summary.&lt;br /&gt;
Free cluster summary wrong (1404490 vs. really 1404491)&lt;br /&gt;
 Auto-correcting.&lt;br /&gt;
Starting verification pass.&lt;br /&gt;
Checking for unused clusters.&lt;br /&gt;
Leaving filesystem unchanged.&amp;lt;/pre&amp;gt;&lt;br /&gt;
| Useless null-based-read&lt;br /&gt;
| None&lt;br /&gt;
| [[9.6.0-24|9.6.0-X]]&lt;br /&gt;
| July 8-9, 2015&lt;br /&gt;
| &lt;br /&gt;
| [[User:Yellows8|Yellows8]]&lt;br /&gt;
|-&lt;br /&gt;
| RSA signature padding checks&lt;br /&gt;
| The TWL_FIRM RSA sig padding check code used for all TWL RSA sig-checks has issues, see [[FIRM|here]].&lt;br /&gt;
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&#039;t really a problem here because there&#039;s proper padding check code which is executed prior to this.&lt;br /&gt;
| &lt;br /&gt;
| None&lt;br /&gt;
| [[9.5.0-22|9.5.0-X]]&lt;br /&gt;
| March 2015&lt;br /&gt;
| &lt;br /&gt;
| [[User:Yellows8|Yellows8]]&lt;br /&gt;
|-&lt;br /&gt;
| [[AMPXI:ValidateDSiWareSectionMAC]] [[AES_Registers|AES]] keyslot reuse&lt;br /&gt;
| When the input DSiWare section index is higher than &amp;lt;max number of DSiWare sections supported by this FIRM&amp;gt;, 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 &amp;gt;=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&#039;s unknown whether a timing attack would work with this.&lt;br /&gt;
This is basically a different form of the pxips9 keyslot vuln, except with AESMAC etc.&lt;br /&gt;
| See description.&lt;br /&gt;
| None&lt;br /&gt;
| [[10.2.0-28|10.2.0-X]]&lt;br /&gt;
| March 15, 2015&lt;br /&gt;
| December 29, 2015&lt;br /&gt;
| [[User:Yellows8|Yellows8]]&lt;br /&gt;
|-&lt;br /&gt;
| pxips9 [[AES_Registers|AES]] keyslot reuse&lt;br /&gt;
| 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 &amp;lt;=10.1.0-X(see 32c3 3ds talk).&lt;br /&gt;
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&#039;t return any errors, Process9 will just continue to do crypto with whatever AES keyslot was selected before the PS command was sent.&lt;br /&gt;
| Reusing the previously used keyslot, for crypto with PS.&lt;br /&gt;
| None&lt;br /&gt;
| [[10.2.0-28|10.2.0-X]]&lt;br /&gt;
| Roughly the same time(same day?) as firmlaunch-hax.&lt;br /&gt;
| December 29, 2015&lt;br /&gt;
| [[User:Yellows8|Yellows8]]&lt;br /&gt;
|-&lt;br /&gt;
| firmlaunch-hax: FIRM header ToCToU&lt;br /&gt;
| This can&#039;t be exploited from ARM11 userland.&lt;br /&gt;
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&#039;t expect &amp;quot;anything&amp;quot; besides the ARM9 to access this data.&lt;br /&gt;
With [[9.5.0-22]] the address of this FIRM header was changed from a FCRAM address, to ARM9-only address 0x01fffc00.&lt;br /&gt;
| ARM9 code execution&lt;br /&gt;
| [[9.5.0-22]]&lt;br /&gt;
| &lt;br /&gt;
| 2012, 3 days after [[User:Yellows8|Yellows8]] started Process9 code RE.&lt;br /&gt;
| &lt;br /&gt;
| [[User:Yellows8|Yellows8]]&lt;br /&gt;
|-&lt;br /&gt;
| Uninitialized data output for (PXI) command replies&lt;br /&gt;
| 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.&lt;br /&gt;
Certain ARM11 service commands have this same issue as well.&lt;br /&gt;
| &lt;br /&gt;
| None&lt;br /&gt;
| [[9.3.0-21|9.3.0-X]]&lt;br /&gt;
| ?&lt;br /&gt;
| &lt;br /&gt;
| [[User:Yellows8|Yellows8]]&lt;br /&gt;
|-&lt;br /&gt;
| [[Filesystem_services_PXI|FSPXI]] OpenArchive SD permissions&lt;br /&gt;
| Process9 does not use the exheader ARM9 access-mount permission flag for SD at all.&lt;br /&gt;
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.&lt;br /&gt;
| &lt;br /&gt;
| None&lt;br /&gt;
| [[9.3.0-21|9.3.0-X]]&lt;br /&gt;
| 2012&lt;br /&gt;
| &lt;br /&gt;
| [[User:Yellows8|Yellows8]]&lt;br /&gt;
|-&lt;br /&gt;
| [[AMPXI:ExportDSiWare]] export path&lt;br /&gt;
| 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 &amp;quot;&amp;lt;mountpoint&amp;gt;:/&amp;lt;path&amp;gt;&amp;quot;.&lt;br /&gt;
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.&lt;br /&gt;
| Exporting of DSiWare to arbitrary Process9 file-paths, such as &amp;quot;nand:/&amp;lt;path&amp;gt;&amp;quot; etc. This isn&#039;t really useful since the data which gets written can&#039;t be controlled.&lt;br /&gt;
| None&lt;br /&gt;
| [[9.5.0-22]]&lt;br /&gt;
| April 2013&lt;br /&gt;
| &lt;br /&gt;
| [[User:Yellows8|Yellows8]]&lt;br /&gt;
|-&lt;br /&gt;
| [[DSiWare_Exports]] [[CTCert]] verification&lt;br /&gt;
| 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&#039;s still not(?) fixed.&lt;br /&gt;
On 3DS however this is rather useless, due to the entire DSiWare .bin being encrypted with the console-unique movable.sed keyY.&lt;br /&gt;
| 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.&lt;br /&gt;
| Unknown, probably none.&lt;br /&gt;
| ?&lt;br /&gt;
| April 2013&lt;br /&gt;
| &lt;br /&gt;
| [[User:Yellows8|Yellows8]]&lt;br /&gt;
|-&lt;br /&gt;
| [[Gamecard_Services_PXI]] unchecked REG_CTRCARDCNT transfer-size&lt;br /&gt;
| 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&#039;t checked, thus out-of-bounds reads could be triggered(which is rather useless in this case).&lt;br /&gt;
| Out-of-bounds read for a value which gets written to a register.&lt;br /&gt;
| [[5.0.0-11|5.0.0-X]]&lt;br /&gt;
| &lt;br /&gt;
| 2013?&lt;br /&gt;
| &lt;br /&gt;
| [[User:Yellows8|Yellows8]]&lt;br /&gt;
|-&lt;br /&gt;
| [[PXI_Registers|PXI]] cmdbuf buffer overrun&lt;br /&gt;
| The Process9 code responsible [[PXI_Registers|PXI]] communications didn&#039;t verify the size of the incoming command before writing it to a C++ member variable. &lt;br /&gt;
| Probably ARM9 code execution&lt;br /&gt;
| [[5.0.0-11|5.0.0-11]]&lt;br /&gt;
| &lt;br /&gt;
| March 2015, original timeframe if any unknown&lt;br /&gt;
| &lt;br /&gt;
| [[User:Plutooo|plutoo]]/[[User:Yellows8|Yellows8]]/maybe others(?)&lt;br /&gt;
|-&lt;br /&gt;
| [[Application_Manager_Services_PXI|PXIAM]] command 0x003D0108(See also [[Application_Manager_Services|this]])&lt;br /&gt;
| 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 &amp;lt;=0x2800.&lt;br /&gt;
| ARM9 code execution&lt;br /&gt;
| [[5.0.0-11|5.0.0-X]]&lt;br /&gt;
| &lt;br /&gt;
| May 2013&lt;br /&gt;
| &lt;br /&gt;
| [[User:Yellows8|Yellows8]]&lt;br /&gt;
|-&lt;br /&gt;
| [[Process_Services_PXI|PS RSA]] commands buffer overflows&lt;br /&gt;
| pxips9 cmd1(not accessible via ps:ps) and VerifyRsaSha256: unchecked copy to a buffer in Process9&#039;s .bss, from the input FCRAM buffer. The buffer is located before the pxi cmdhandler threads&#039; stacks. SignRsaSha256 also has a buf overflow, but this isn&#039;t exploitable.&lt;br /&gt;
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]].&lt;br /&gt;
| ARM9 code execution&lt;br /&gt;
| [[5.0.0-11|5.0.0-X]]&lt;br /&gt;
| &lt;br /&gt;
| 2012&lt;br /&gt;
| &lt;br /&gt;
| [[User:Yellows8|Yellows8]]&lt;br /&gt;
|-&lt;br /&gt;
| [[PXI_Registers|PXI]] pxi_id bad check&lt;br /&gt;
| The Process9 code responsible for [[PXI_Registers|PXI]] communications read pxi_id as a signed char. There were two flaws:&lt;br /&gt;
* They used it as index to a lookup-table without checking the value at all.&lt;br /&gt;
* Another function verified that pxi_id &amp;lt; 7, allowing negative values to pass the check. This would also cause an out-of-range table-lookup.&lt;br /&gt;
| Maybe ARM9 code execution&lt;br /&gt;
| [[3.0.0-5|3.0.0-5]]&lt;br /&gt;
|&lt;br /&gt;
| March 2015, originally 2012 for the first issue at least&lt;br /&gt;
| &lt;br /&gt;
| [[User:Plutooo|plutoo]], [[User:Yellows8|Yellows8]], maybe others(?)&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
=== Kernel9 ===&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot; border=&amp;quot;1&amp;quot;&lt;br /&gt;
|-&lt;br /&gt;
!  Summary&lt;br /&gt;
!  Description&lt;br /&gt;
!  Successful exploitation result&lt;br /&gt;
!  Fixed in [[FIRM]] system version&lt;br /&gt;
!  Last [[FIRM]] system version this flaw was checked for&lt;br /&gt;
!  Timeframe this was discovered&lt;br /&gt;
!  Discovered by&lt;br /&gt;
|-&lt;br /&gt;
| [[CONFIG Registers#CFG_SYSPROT9|CFG_SYSPROT9]] bit1 not set by Kernel9&lt;br /&gt;
| 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&#039;s never locked, you can dump it once you get ARM9 code execution.&lt;br /&gt;
&lt;br /&gt;
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).&lt;br /&gt;
&lt;br /&gt;
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 -&amp;gt; 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.&lt;br /&gt;
| Dumping of the [[OTP Registers|OTP]] area&lt;br /&gt;
| [[3.0.0-5|3.0.0-X]]&lt;br /&gt;
|&lt;br /&gt;
| February 2015&lt;br /&gt;
| [[User:Plutooo|plutoo]], Normmatt independently&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
== ARM11 software ==&lt;br /&gt;
=== Kernel11 ===&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot; border=&amp;quot;1&amp;quot;&lt;br /&gt;
|-&lt;br /&gt;
!  Summary&lt;br /&gt;
!  Description&lt;br /&gt;
!  Successful exploitation result&lt;br /&gt;
!  Fixed in [[FIRM]] system version&lt;br /&gt;
!  Last [[FIRM]] system version this flaw was checked for&lt;br /&gt;
!  Timeframe this was discovered&lt;br /&gt;
!  Discovered by&lt;br /&gt;
|-&lt;br /&gt;
|  [[SVC]] table too small&lt;br /&gt;
|  The table of function pointers for SVC&#039;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.&lt;br /&gt;
&lt;br /&gt;
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&#039;t mapped as executable.&lt;br /&gt;
| &lt;br /&gt;
|  None&lt;br /&gt;
| [[10.2.0-28|10.2.0-X]]&lt;br /&gt;
| 2012&lt;br /&gt;
| Everyone&lt;br /&gt;
|-&lt;br /&gt;
|  [[SVC|svcBackdoor (0x7B)]]&lt;br /&gt;
|  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.&lt;br /&gt;
| See description&lt;br /&gt;
| [[11.0.0-33|11.0.0-33]] (deleted)&lt;br /&gt;
| &lt;br /&gt;
|&lt;br /&gt;
| Everyone&lt;br /&gt;
|-&lt;br /&gt;
| [[Memory_layout#ARM11_Detailed_virtual_memory_map|0xEFF00000]] / 0xDFF00000 ARM11 kernel virtual-memory&lt;br /&gt;
| 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.&lt;br /&gt;
| &lt;br /&gt;
| None&lt;br /&gt;
| [[10.2.0-28|10.2.0-X]]&lt;br /&gt;
| &lt;br /&gt;
| &lt;br /&gt;
|-&lt;br /&gt;
| memchunkhax2.1&lt;br /&gt;
| Nintendo&#039;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.&lt;br /&gt;
derrek&#039;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.&lt;br /&gt;
| ARM11 kernel code execution&lt;br /&gt;
| None&lt;br /&gt;
| [[10.4.0-29|10.4.0-X]]&lt;br /&gt;
|&lt;br /&gt;
| derrek, aliaspider&lt;br /&gt;
|-&lt;br /&gt;
| memchunkhax2&lt;br /&gt;
| &lt;br /&gt;
| ARM11 kernel code execution&lt;br /&gt;
| [[10.4.0-29|10.4.0-X]] (partially)&lt;br /&gt;
| [[10.4.0-29|10.4.0-X]]&lt;br /&gt;
|&lt;br /&gt;
| derrek&lt;br /&gt;
|-&lt;br /&gt;
|  AffinityMask/processorid validation&lt;br /&gt;
|  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.&lt;br /&gt;
The original code with the first 3 did the following: &lt;br /&gt;
* if(u32_processorcount &amp;gt; ~0x80000001)return 0xe0e01bfd;&lt;br /&gt;
* if(s32_processorcount &amp;gt; &amp;lt;total_cores&amp;gt;)return 0xd8e007fd;&lt;br /&gt;
The following code replaced the above:&lt;br /&gt;
* if(u32_processorcount &amp;gt;= &amp;lt;total_cores+1&amp;gt;)return 0xd8e007fd;&lt;br /&gt;
In theory the latter should catch everything that the former did, so it&#039;s unknown if this was really a security issue.&lt;br /&gt;
&lt;br /&gt;
The svcCreateThread changes with [[10.0.0-27|10.0.0-X]] definitely did fix a security issue.&lt;br /&gt;
* Original code: &amp;quot;if(s32_processorid &amp;gt; &amp;lt;total_cores&amp;gt;)return 0xd8e007fd;&amp;quot;&lt;br /&gt;
* New code: &amp;quot;if(s32_processorid &amp;gt;= &amp;lt;total_cores&amp;gt; || s32_processorid &amp;lt;= -4)return 0xd8e007fd;&amp;quot;&lt;br /&gt;
This fixed an off-by-one issue: if one would use processorid=total_cores, which isn&#039;t actually a valid value, svcCreateThread would accept that value on &amp;lt;[[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:&lt;br /&gt;
* Old3DS: Useless kernel-mode crash due to accessing unmapped memory.&lt;br /&gt;
* New3DS: uncontrolled data write into a kernel-mode L1 MMU-table. This isn&#039;t really useful: the data can&#039;t be controlled, and the data which gets overwritten is all-zero anyway(this isn&#039;t anywhere near MMU L1 entries for actually mapped memory).&lt;br /&gt;
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&#039;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)).&lt;br /&gt;
| Nothing useful&lt;br /&gt;
|  [[10.0.0-27|10.0.0-X]]&lt;br /&gt;
| [[10.0.0-27|10.0.0-X]]&lt;br /&gt;
| svcCreateThread issue: May 31, 2015. The rest: September 8, 2015, via v9.6-&amp;gt;v10.0 ARM11-kernel code-diff.&lt;br /&gt;
| [[User:Yellows8|Yellows8]]&lt;br /&gt;
|-&lt;br /&gt;
| memchunkhax&lt;br /&gt;
| 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.&lt;br /&gt;
&lt;br /&gt;
There are &#039;&#039;multiple&#039;&#039; 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.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
| When combined with other flaws: ARM11-kernelmode code execution&lt;br /&gt;
| [[9.3.0-21|9.3.0-21]]&lt;br /&gt;
| &lt;br /&gt;
| February 2014&lt;br /&gt;
| [[User:Yellows8|Yellows8]]&lt;br /&gt;
|-&lt;br /&gt;
| Multiple [[KLinkedListNode|KLinkedListNode]] SlabHeap use after free bugs&lt;br /&gt;
| The ARM11-kernel did access the &#039;key&#039; 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:&lt;br /&gt;
SlabHeap_free(KLinkedListNode);&lt;br /&gt;
KObject *obj = KLinkedListNode-&amp;gt;key;  // the object there might have changed!&lt;br /&gt;
This bug appeared all over the place.&lt;br /&gt;
| ARM11-kernelmode code exec maybe&lt;br /&gt;
| [[8.0.0-18|8.0.0-18]]&lt;br /&gt;
| &lt;br /&gt;
| April 2015&lt;br /&gt;
| [[User:Derrek|derrek]]&lt;br /&gt;
|-&lt;br /&gt;
| PXI [[RPC_Command_Structure|Command]] input/output buffer permissions&lt;br /&gt;
| Originally the ARM11-kernel didn&#039;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.&lt;br /&gt;
| &lt;br /&gt;
| [[6.0.0-11|6.0.0-11]]&lt;br /&gt;
| &lt;br /&gt;
| 2012&lt;br /&gt;
| [[User:Yellows8|Yellows8]]&lt;br /&gt;
|-&lt;br /&gt;
| [[SVC|svcStartInterProcessDma]]&lt;br /&gt;
| For svcStartInterProcessDma, the kernel code had the following flaws:&lt;br /&gt;
&lt;br /&gt;
* 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.&lt;br /&gt;
&lt;br /&gt;
* Integer overflows for srcaddr+size and dstaddr+size are now checked(with [[6.0.0-11]]), which were not checked before.&lt;br /&gt;
&lt;br /&gt;
* 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 &amp;gt;=0x20000000 would result in the kernel reading from the process L1 MMU table, beyond the memory allocated for that MMU table(for vaddr-&amp;gt;physaddr conversion). &lt;br /&gt;
| &lt;br /&gt;
| [[6.0.0-11]]&lt;br /&gt;
| &lt;br /&gt;
| DmaConfig issue: unknown. The rest: 2014&lt;br /&gt;
| [[User:Plutooo|plutoo]], [[User:Yellows8|Yellows8]] independently&lt;br /&gt;
|-&lt;br /&gt;
| [[SVC|svcControlMemory]] Parameter checks&lt;br /&gt;
| For svcControlMemory the parameter check had these two flaws:&lt;br /&gt;
&lt;br /&gt;
* 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&#039;t actually use the input address for LINEAR memory-mapping at all besides the range-checks, so this isn&#039;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.&lt;br /&gt;
&lt;br /&gt;
* Integer overflows on (addr0+size) are now checked that previously weren&#039;t (this also applies to most other address checks elsewhere in the kernel).&lt;br /&gt;
&lt;br /&gt;
| &lt;br /&gt;
| [[5.0.0-11]]&lt;br /&gt;
| &lt;br /&gt;
|&lt;br /&gt;
| [[User:Plutooo|plutoo]]&lt;br /&gt;
|-&lt;br /&gt;
| [[RPC_Command_Structure|Command]] request/response buffer overflow&lt;br /&gt;
| 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.&lt;br /&gt;
&lt;br /&gt;
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 &amp;lt;nowiki&amp;gt;((size&amp;lt;&amp;lt;14) | 2)&amp;lt;/nowiki&amp;gt; to write arbitrary memory to any RW userland memory in the destination process.&lt;br /&gt;
| &lt;br /&gt;
| [[5.0.0-11]]&lt;br /&gt;
| &lt;br /&gt;
| v4.1 FIRM -&amp;gt; v5.0 code diff&lt;br /&gt;
| [[User:Yellows8|Yellows8]]&lt;br /&gt;
|-&lt;br /&gt;
| [[SVC|SVC stack allocation overflows]]&lt;br /&gt;
| &lt;br /&gt;
* 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. &lt;br /&gt;
* The alignment (size+7)&amp;amp;~7 calculation before allocation was not checked for integer overflow.&lt;br /&gt;
&lt;br /&gt;
This might allow for ARM11 kernel code-execution.&lt;br /&gt;
&lt;br /&gt;
(Applies to svcSetResourceLimitValues, svcGetThreadList, svcGetProcessList, svcReplyAndReceive, svcWaitSynchronizationN.)&lt;br /&gt;
| &lt;br /&gt;
| [[5.0.0-11]]&lt;br /&gt;
| &lt;br /&gt;
| v4.1 FIRM -&amp;gt; v5.0 code diff&lt;br /&gt;
| [[User:Plutooo|plutoo]], [[User:Yellows8|Yellows8]] complementary&lt;br /&gt;
|-&lt;br /&gt;
| [[SVC|svcControlMemory]] MemoryOperation MAP memory-permissions&lt;br /&gt;
| 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&#039;t check memory permissions for addr1. Therefore .text as addr1 could be mapped elsewhere as RW- memory, which allowed ARM11 userland code-execution.&lt;br /&gt;
| &lt;br /&gt;
| [[4.1.0-8]]&lt;br /&gt;
| &lt;br /&gt;
| 2012&lt;br /&gt;
| [[User:Yellows8|Yellows8]]&lt;br /&gt;
|-&lt;br /&gt;
| [[RPC_Command_Structure|Command]] input/output buffer permissions&lt;br /&gt;
| Originally the ARM11 kernel didn&#039;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&#039;t have the required memory permissions. For example, this allowed a FSUSER file-read to .text, which therefore allowed ARM11-userland code execution.&lt;br /&gt;
| &lt;br /&gt;
| [[4.0.0-7]]&lt;br /&gt;
| &lt;br /&gt;
| 2012&lt;br /&gt;
| [[User:Yellows8|Yellows8]]&lt;br /&gt;
|-&lt;br /&gt;
| [[SVC|svcReadProcessMemory/svcWriteProcessMemory memory]] permissions&lt;br /&gt;
| 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.&lt;br /&gt;
| &lt;br /&gt;
| [[4.0.0-7]]&lt;br /&gt;
| &lt;br /&gt;
| 2012?&lt;br /&gt;
| [[User:Yellows8|Yellows8]]&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
=== [[FIRM]] Sysmodules ===&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot; border=&amp;quot;1&amp;quot;&lt;br /&gt;
|-&lt;br /&gt;
!  Summary&lt;br /&gt;
!  Description&lt;br /&gt;
!  Successful exploitation result&lt;br /&gt;
!  Fixed in [[FIRM]] system version&lt;br /&gt;
!  Last [[FIRM]] system version this flaw was checked for&lt;br /&gt;
!  Timeframe this was discovered&lt;br /&gt;
!  Discovered by&lt;br /&gt;
|-&lt;br /&gt;
| [[Services|&amp;quot;srv:pm&amp;quot;]] process registration&lt;br /&gt;
| Originally any process had access to the port &amp;quot;srv:pm&amp;quot;. The PID&#039;s used for the (un)registration commands are not checked either. This allowed any process to re-register itself with &amp;quot;srv:pm&amp;quot;, and therefore allowed the process to give itself access to any service, bypassing the exheader service-access-control list.&lt;br /&gt;
&lt;br /&gt;
This was fixed in [[7.0.0-13]]: starting with [[7.0.0-13]] &amp;quot;srv:pm&amp;quot; is now a service instead of a globally accessible port. Only processes with PID&#039;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 &amp;quot;srv:pm&amp;quot; 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.&lt;br /&gt;
&lt;br /&gt;
This flaw was needed for exploiting the &amp;lt;=v4.x Process9 PXI vulnerabilities from ARM11 userland ROP, since most applications don&#039;t have access to those service(s).&lt;br /&gt;
| Access to arbitrary services&lt;br /&gt;
| [[7.0.0-13]]&lt;br /&gt;
| &lt;br /&gt;
| 2012&lt;br /&gt;
| [[User:Yellows8|Yellows8]]&lt;br /&gt;
|-&lt;br /&gt;
| FSDIR null-deref&lt;br /&gt;
| [[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&#039;s just a null-deref.&lt;br /&gt;
| &lt;br /&gt;
| None&lt;br /&gt;
| [[9.6.0-24|9.6.0-X]]&lt;br /&gt;
| May 19(?)-20, 2015&lt;br /&gt;
| [[User:Yellows8|Yellows8]]&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
=== Standalone Sysmodules ===&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot; border=&amp;quot;1&amp;quot;&lt;br /&gt;
|-&lt;br /&gt;
!  Summary&lt;br /&gt;
!  Description&lt;br /&gt;
!  Successful exploitation result&lt;br /&gt;
!  Fixed in system-module system-version&lt;br /&gt;
!  Last system-module system-version this flaw was checked for&lt;br /&gt;
!  Timeframe this was discovered&lt;br /&gt;
!  Timeframe this was added to wiki&lt;br /&gt;
!  Discovered by&lt;br /&gt;
|-&lt;br /&gt;
| [[MVD_Services|MVD]]: Stack buffer overflow with [[MVDSTD:SetupOutputBuffers]].&lt;br /&gt;
| 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-&amp;gt;physaddrs used there are also copied to stack(0x8-bytes of physaddrs per entry).&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
| MVD-sysmodule crash.&lt;br /&gt;
| None&lt;br /&gt;
| [[9.0.0-20]]&lt;br /&gt;
| April 22, 2016 (Tested on the 25th)&lt;br /&gt;
| April 25, 2016&lt;br /&gt;
| [[User:Yellows8|Yellows8]]&lt;br /&gt;
|-&lt;br /&gt;
| [[NWM_Services|NWM]]: Using CTRSDK heap with UDS sharedmem from the user-process.&lt;br /&gt;
| See the HTTP-sysmodule section below.&lt;br /&gt;
&lt;br /&gt;
CTRSDK heap is used with the sharedmem from [[NWMUDS:InitializeWithVersion]]. Buffers are allocated/freed under this heap using [[NWMUDS:Bind]] and [[NWMUDS:Unbind]].&lt;br /&gt;
&lt;br /&gt;
Hence, overwriting sharedmem with gspwn then using [[NWMUDS:Unbind]] results in the usual controlled CTRSDK memchunk-header write, similar to HTTP-sysmodule.&lt;br /&gt;
&lt;br /&gt;
This could be done by creating an UDS network, without any other nodes on the network.&lt;br /&gt;
&lt;br /&gt;
Besides CTRSDK memchunk-headers, there are no addresses stored under this sharedmem.&lt;br /&gt;
| ROP under NWM-module.&lt;br /&gt;
| None&lt;br /&gt;
| [[9.0.0-20|9.0.0-X]]&lt;br /&gt;
| April 10, 2016&lt;br /&gt;
| April 16, 2016&lt;br /&gt;
| [[User:Yellows8|Yellows8]]&lt;br /&gt;
|-&lt;br /&gt;
| [[DLP_Services|DLP]]: Out-of-bounds memory access during spectator [[Download_Play|data-frame]] checksum calculation&lt;br /&gt;
| DLP doesn&#039;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&#039;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.&lt;br /&gt;
&lt;br /&gt;
Hence, using a large frame_size like 0xFFFF will result in the checksum calculation code reading data out-of-bounds. This isn&#039;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&#039;s about all(trying to infoleak with this likely isn&#039;t useful either).&lt;br /&gt;
| DLP-sysmodule crash, handled by dlplay system-application by a &amp;quot;connection interrupted&amp;quot; error eventually then a fatal-error via ErrDisp.&lt;br /&gt;
| None&lt;br /&gt;
| [[10.0.0-27|10.0.0-X]]&lt;br /&gt;
| April 8, 2016 (Tested on the 10th)&lt;br /&gt;
| April 10, 2016&lt;br /&gt;
| [[User:Yellows8|Yellows8]]&lt;br /&gt;
|-&lt;br /&gt;
| [[DLP_Services|DLP]]: Out-of-bounds output data writing during spectator sysupdate titlelist [[Download_Play|data-frame]] handling&lt;br /&gt;
| 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.&lt;br /&gt;
&lt;br /&gt;
There&#039;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.&lt;br /&gt;
&lt;br /&gt;
There&#039;s no known way to exploit the above crash, since the linked-list code involves writes zeros(with a controlled start ptr).&lt;br /&gt;
| &lt;br /&gt;
| None&lt;br /&gt;
| [[10.0.0-27|10.0.0-X]]&lt;br /&gt;
| April 8-9, 2016&lt;br /&gt;
| April 10, 2016&lt;br /&gt;
| [[User:Yellows8|Yellows8]]&lt;br /&gt;
|-&lt;br /&gt;
| [[IR_Services|IR]]: Stack buffer overflow with custom hardware&lt;br /&gt;
| 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.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
| ROP under IR sysmodule.&lt;br /&gt;
| [[10.6.0-31|10.6.0-31]]&lt;br /&gt;
| &lt;br /&gt;
| February 23, 2016 (Unknown if it was noticed before then)&lt;br /&gt;
| February 23, 2016&lt;br /&gt;
| [[User:Yellows8|Yellows8]]&lt;br /&gt;
|-&lt;br /&gt;
| [[HTTP_Services|HTTP]]: Using CTRSDK heap with sharedmem from the user-process.&lt;br /&gt;
| 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.&lt;br /&gt;
Normally this sharedmem isn&#039;t accessible to the user-process once the sysmodule maps it, hence using it is supposed to be &amp;quot;safe&amp;quot;.&lt;br /&gt;
&lt;br /&gt;
This isn&#039;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.&lt;br /&gt;
&lt;br /&gt;
This is exploited by [https://github.com/yellows8/ctr-httpwn/ctr-httpwn ctr-httpwn].&lt;br /&gt;
| ROP under HTTP sysmdule.&lt;br /&gt;
| None&lt;br /&gt;
| [[9.6.0-24|9.6.0-X]] (Latest sysmodule version as of [[10.7.0-32|10.7.0-32]])&lt;br /&gt;
| Late 2015&lt;br /&gt;
| March 22, 2016&lt;br /&gt;
| [[User:Yellows8|Yellows8]]&lt;br /&gt;
|-&lt;br /&gt;
| [[NIM_Services|NIM]]: Downloading old title-versions from eShop&lt;br /&gt;
| 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 &#039;&#039;if&#039;&#039; it&#039;s still available from CDN.&lt;br /&gt;
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).&lt;br /&gt;
&lt;br /&gt;
Originally this was tested with a debugging-system via modded-FIRM, eventually smea implemented it in HANS for the 32c3 release.&lt;br /&gt;
| Downloading old title-versions from eShop&lt;br /&gt;
| None&lt;br /&gt;
| [[10.0.0-27|10.0.0-X]]&lt;br /&gt;
| October 24, 2015 (Unknown when exactly the first eShop title downgrade was actually tested, maybe November)&lt;br /&gt;
| January 7, 2016 (Same day Ironfall v1.0 was removed from CDN via the main-CXI files)&lt;br /&gt;
| [[User:Yellows8|Yellows8]]&lt;br /&gt;
|-&lt;br /&gt;
| [[SPI_Services|SPI]] service out-of-bounds write&lt;br /&gt;
| cmd1 has out-of-bounds write allowing overwrite of some static variables in .data.&lt;br /&gt;
| &lt;br /&gt;
| None&lt;br /&gt;
| [[9.5.0-22]]&lt;br /&gt;
| March 2015&lt;br /&gt;
| &lt;br /&gt;
| [[User:Plutooo|plutoo]]&lt;br /&gt;
|-&lt;br /&gt;
| [[NFC_Services|NFC]] module service command buf-overflows&lt;br /&gt;
| NFC module copies data with certain commands, from command input buffers to stack without checking the size. These commands include the following, it&#039;s unknown if there&#039;s more commands with similar issues: &amp;quot;nfc:dev&amp;quot; &amp;lt;0x000C....&amp;gt; and &amp;quot;nfc:s&amp;quot; &amp;lt;0x0037....&amp;gt;.&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
There&#039;s no known retail titles which have access to either of these services.&lt;br /&gt;
| ROP under NFC module.&lt;br /&gt;
| New3DS: None&lt;br /&gt;
| New3DS: [[9.5.0-22]]&lt;br /&gt;
| December 2014?&lt;br /&gt;
| &lt;br /&gt;
| [[User:Yellows8|Yellows8]]&lt;br /&gt;
|-&lt;br /&gt;
| [[News_Services|NEWSS]] service command notificationID validation failure&lt;br /&gt;
| This module does not validate the input notificationID for &amp;lt;nowiki&amp;gt;&amp;quot;news:s&amp;quot;&amp;lt;/nowiki&amp;gt; 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).&lt;br /&gt;
| ROP under news module.&lt;br /&gt;
| None&lt;br /&gt;
| [[9.7.0-25|9.7.0-X]]&lt;br /&gt;
| December 2014&lt;br /&gt;
| &lt;br /&gt;
| [[User:Yellows8|Yellows8]]&lt;br /&gt;
|-&lt;br /&gt;
| [[NWMUDS:DecryptBeaconData]] heap buffer overflow&lt;br /&gt;
| input_size = 0x1E * &amp;lt;value the u8 from input_[[NWM_Services|networkstruct]]+0x1D&amp;gt;. Then input_tag0 is copied to a heap buffer. When input_size is larger than 0xFA-bytes, it will then copy input_tag1 to &amp;lt;end_address_of_previous_outbuf&amp;gt;, with size=input_size-0xFA.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
There&#039;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&#039;t be controlled it seems(with just broadcasting a beacon at least). It&#039;s unknown whether this could be exploited from just using NWMUDS service-cmd(s) directly.&lt;br /&gt;
| 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.&lt;br /&gt;
| None&lt;br /&gt;
| [[9.0.0-20]]&lt;br /&gt;
| ~September 23, 2014(see the [[NWMUDS:DecryptBeaconData]] page history)&lt;br /&gt;
| August 3, 2015&lt;br /&gt;
| [[User:Yellows8|Yellows8]]&lt;br /&gt;
|-&lt;br /&gt;
| [[HID_Services|HID]] module shared-mem&lt;br /&gt;
| 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.&lt;br /&gt;
| ROP under HID module, but this is *very* unlikely to be exploitable since the data written is HID data.&lt;br /&gt;
| None&lt;br /&gt;
| [[9.3.0-21]]&lt;br /&gt;
| 2014?&lt;br /&gt;
| &lt;br /&gt;
| [[User:Yellows8|Yellows8]]&lt;br /&gt;
|-&lt;br /&gt;
| gspwn&lt;br /&gt;
| 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&#039;re running under, and gain real code-execution from a ROP-chain. Normally applets&#039; .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).&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
| User-mode code execution.&lt;br /&gt;
| None&lt;br /&gt;
| [[9.6.0-24|9.6.0-X]]&lt;br /&gt;
| Early 2014&lt;br /&gt;
| &lt;br /&gt;
| smea, [[User:Yellows8|Yellows8]]/others before then&lt;br /&gt;
|-&lt;br /&gt;
| rohax&lt;br /&gt;
| 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.&lt;br /&gt;
&lt;br /&gt;
This was fixed after [[ninjhax]] release by adding checks on [[CRO0]]-based pointers before writing to them.&lt;br /&gt;
| Memory-mapping syscalls.&lt;br /&gt;
| [[9.3.0-21]]&lt;br /&gt;
| [[9.4.0-21]]&lt;br /&gt;
| &lt;br /&gt;
| &lt;br /&gt;
| smea, [[User:Plutooo|plutoo]] joint effort&lt;br /&gt;
|-&lt;br /&gt;
| Region free&lt;br /&gt;
| Only [[Home Menu]] itself checks gamecards&#039; 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.&lt;br /&gt;
This essentially means launching the gamecard with the [[NS_and_APT_Services|&amp;quot;ns:s&amp;quot;]] 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]].&lt;br /&gt;
| Launching gamecards from any region + bypassing Home Menu gamecard-sysupdate installation&lt;br /&gt;
| None&lt;br /&gt;
| Last tested with [[10.1.0-27|10.1.0-X]].&lt;br /&gt;
| June(?) 2014&lt;br /&gt;
| &lt;br /&gt;
| [[User:Yellows8|Yellows8]]&lt;br /&gt;
|-&lt;br /&gt;
| [[NWM_Services|NWM]] service-cmd state null-ptr deref&lt;br /&gt;
| 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.&lt;br /&gt;
It&#039;s unknown whether any NWM services besides NWMUDS have this issue.&lt;br /&gt;
| This is rather useless since it&#039;s only a crash caused by a state ptr based at 0x0.&lt;br /&gt;
| None&lt;br /&gt;
| [[9.0.0-20]]&lt;br /&gt;
| 2013?&lt;br /&gt;
| &lt;br /&gt;
| [[User:Yellows8|Yellows8]]&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
=== General/CTRSDK ===&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot; border=&amp;quot;1&amp;quot;&lt;br /&gt;
|-&lt;br /&gt;
!  Summary&lt;br /&gt;
!  Description&lt;br /&gt;
!  Successful exploitation result&lt;br /&gt;
!  Fixed in version&lt;br /&gt;
!  Last version this flaw was checked for&lt;br /&gt;
!  Timeframe this was discovered&lt;br /&gt;
!  Discovered by&lt;br /&gt;
|-&lt;br /&gt;
| [[NWM_Services|UDS]] beacon additional-data buffer overflow&lt;br /&gt;
| 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.&lt;br /&gt;
This was discovered while doing code RE with an old dlp-module version. It&#039;s unknown in what specific CTRSDK version this was fixed, or even what system-version updated titles with a fixed version.&lt;br /&gt;
&lt;br /&gt;
It&#039;s unknown if there&#039;s any titles using a vulnerable CTRSDK version which are also exploitable with this(dlp module can&#039;t be exploited with this).&lt;br /&gt;
&lt;br /&gt;
The maximum number of bytes that can be written beyond the end of the outbuf is 0x37-bytes, with additionaldata_size=0xFF.&lt;br /&gt;
| Perhaps ROP, very difficult if possible with anything at all&lt;br /&gt;
| ?&lt;br /&gt;
| &lt;br /&gt;
| September(?) 2014&lt;br /&gt;
| [[User:Yellows8|Yellows8]]&lt;br /&gt;
|}&lt;/div&gt;</summary>
		<author><name>Motezazer</name></author>
	</entry>
	<entry>
		<id>https://www.3dbrew.org/w/index.php?title=FirmwareNews&amp;diff=16050</id>
		<title>FirmwareNews</title>
		<link rel="alternate" type="text/html" href="https://www.3dbrew.org/w/index.php?title=FirmwareNews&amp;diff=16050"/>
		<updated>2016-03-15T14:25:24Z</updated>

		<summary type="html">&lt;p&gt;Motezazer: Updated the latest firmware&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;As of this writing, the latest firmware is &#039;&#039;&#039; 10.7.0-32&#039;&#039;&#039;.&lt;br /&gt;
&lt;br /&gt;
There are ways to run homebrew on this version, see [[Homebrew Exploits]].&lt;br /&gt;
&lt;br /&gt;
----&lt;br /&gt;
&lt;br /&gt;
Full system control exploits are only public for system versions up to and including &#039;&#039;&#039;9.2.0-X&#039;&#039;&#039;.&lt;/div&gt;</summary>
		<author><name>Motezazer</name></author>
	</entry>
	<entry>
		<id>https://www.3dbrew.org/w/index.php?title=3DS_System_Flaws&amp;diff=16027</id>
		<title>3DS System Flaws</title>
		<link rel="alternate" type="text/html" href="https://www.3dbrew.org/w/index.php?title=3DS_System_Flaws&amp;diff=16027"/>
		<updated>2016-03-14T19:59:22Z</updated>

		<summary type="html">&lt;p&gt;Motezazer: They just forgot to set the bit in SYSPROT9. They wouldn&amp;#039;t create a hardware lock to not use it.&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;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]].&lt;br /&gt;
&lt;br /&gt;
=Stale / Rejected Efforts=&lt;br /&gt;
* Neimod has been working on a RAM dumping setup for a little while now. He&#039;s de-soldered the 3DS&#039;s RAM chip and hooked it and the RAM pinouts on the 3DS&#039; 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.&lt;br /&gt;
&lt;br /&gt;
* Someone (who will remain unnamed) has released CFW and CIA installers, all of which is copied from the work of others, or copyrighted material.&lt;br /&gt;
&lt;br /&gt;
==Tips and info==&lt;br /&gt;
The 3DS uses the XN feature of the ARM11 processor. There&#039;s no official way from applications to enable executable permission for memory containing arbitrary unsigned code(there&#039;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.&lt;br /&gt;
&lt;br /&gt;
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).&lt;br /&gt;
&lt;br /&gt;
=System flaws=&lt;br /&gt;
== Hardware ==&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot; border=&amp;quot;1&amp;quot;&lt;br /&gt;
!  Summary&lt;br /&gt;
!  Description&lt;br /&gt;
!  Fixed with hardware model/revision&lt;br /&gt;
!  Newest hardware model/revision this flaw was checked for&lt;br /&gt;
!  Timeframe this was discovered&lt;br /&gt;
!  Discovered by&lt;br /&gt;
|-&lt;br /&gt;
| ARM9/ARM11 bootrom vectors point at unitialized RAM&lt;br /&gt;
| ARM9&#039;s and ARM11&#039;s exception vectors are hardcoded to point at the CPU&#039;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. &lt;br /&gt;
Since RAM isn&#039;t cleared on boot (see below), one can immediately start execution of their own code here to dump bootrom, OTP, etc.&lt;br /&gt;
The ARM9 bootrom does the following at reset:  reset vector branches to another instruction, then branches to bootrom+0x8000. Hence, there&#039;s no way to know for certain when exactly the ARM9 exception-vector data stored in memory gets initialized.&lt;br /&gt;
&lt;br /&gt;
This requires *very* *precise* timing for triggering the hardware fault: it&#039;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&#039;t).&lt;br /&gt;
| None: all available 3DS models at the time of writing have the exact same ARM9/ARM11 bootrom for the unprotected areas.&lt;br /&gt;
| New3DS&lt;br /&gt;
| End of February 2014&lt;br /&gt;
| [[User:Derrek|derrek]], WulfyStylez (May 2015) independently&lt;br /&gt;
|-&lt;br /&gt;
| Missing AES key clearing&lt;br /&gt;
| The hardware AES engine does not clear keys when doing a hard reset/reboot.&lt;br /&gt;
| None&lt;br /&gt;
| New3DS&lt;br /&gt;
| August 2014&lt;br /&gt;
| Mathieulh/Others&lt;br /&gt;
|-&lt;br /&gt;
| No RAM clearing on reboots&lt;br /&gt;
| On an MCU-triggered reboot all RAM including FCRAM/ARM9 memory/AXIWRAM/VRAM keeps its contents.&lt;br /&gt;
| None&lt;br /&gt;
| New3DS&lt;br /&gt;
| March 2014&lt;br /&gt;
| [[User:Derrek|derrek]]&lt;br /&gt;
|-&lt;br /&gt;
| 32bits of actual console-unique TWLNAND keydata&lt;br /&gt;
| 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&#039;s highest bit is always ORed. only 31 bits of the TWL console-unique keydata / TWL consoleID are actually console-unique.&lt;br /&gt;
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).&lt;br /&gt;
| None&lt;br /&gt;
| New3DS&lt;br /&gt;
| 2012?&lt;br /&gt;
| [[User:Yellows8|Yellows8]]&lt;br /&gt;
|-&lt;br /&gt;
| DSi / 3DS-TWL key-generator&lt;br /&gt;
| 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.&lt;br /&gt;
This applies to the keyX/keyY too.&lt;br /&gt;
&lt;br /&gt;
This attack does not work for the 3DS key-generator because keyslots 0-3 are only for TWL keys.&lt;br /&gt;
| None&lt;br /&gt;
| New3DS&lt;br /&gt;
| 2011&lt;br /&gt;
| [[User:Yellows8|Yellows8]]&lt;br /&gt;
|-&lt;br /&gt;
| 3DS key-generator&lt;br /&gt;
| 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.&lt;br /&gt;
&lt;br /&gt;
Several such pairs of matching normal-keys and KeyY values were found, leading to deducing the key-generator function.&lt;br /&gt;
| None&lt;br /&gt;
| New3DS&lt;br /&gt;
| February 2015&lt;br /&gt;
| [[User:Yellows8|Yellows8]], [[User:Plutooo|plutoo]]&lt;br /&gt;
|-&lt;br /&gt;
| FIRM partitions known-plaintext&lt;br /&gt;
| The [[Flash_Filesystem|FIRM partitions]] are encrypted with AES-CTR without a MAC. Since this works by XOR&#039;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.&lt;br /&gt;
&lt;br /&gt;
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).&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
| None&lt;br /&gt;
| New3DS&lt;br /&gt;
| &lt;br /&gt;
| Everyone&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
== ARM9 software ==&lt;br /&gt;
=== arm9loader ===&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot; border=&amp;quot;1&amp;quot;&lt;br /&gt;
|-&lt;br /&gt;
!  Summary&lt;br /&gt;
!  Description&lt;br /&gt;
!  Successful exploitation result&lt;br /&gt;
!  Fixed in [[FIRM]] system version&lt;br /&gt;
!  Last [[FIRM]] system version this flaw was checked for&lt;br /&gt;
!  Timeframe this was discovered&lt;br /&gt;
!  Public disclosure timeframe&lt;br /&gt;
!  Discovered by&lt;br /&gt;
|-&lt;br /&gt;
| Uncleared OTP hash keydata in console-unique 0x11 key-generation&lt;br /&gt;
| 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.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
This can be performed by exploiting the &amp;quot;arm9loaderhax&amp;quot; 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 &amp;lt;[[3.0.0-6|3.0.0-X]].&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
| Derivation of all New3DS keys generated via the NAND keystore (0x1B &amp;quot;Secure4&amp;quot; etc.)&lt;br /&gt;
| None&lt;br /&gt;
| [[10.4.0-29|10.4.0-X]]&lt;br /&gt;
| ~April 2015, implemented in May 2015&lt;br /&gt;
| 13 January 2016&lt;br /&gt;
| [[User:WulfyStylez|WulfyStylez]], [[User:Dazzozo|Dazzozo]], [[User:Shinyquagsire23|shinyquagsire23]] (complimentary + implemented), [[User:Plutooo|plutoo]], Normmatt (discovered independently)&lt;br /&gt;
|-&lt;br /&gt;
| enhanced-arm9loaderhax&lt;br /&gt;
| See the 32c3 3ds talk.&lt;br /&gt;
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&#039;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.&lt;br /&gt;
| arm9loaderhax which automatically occurs at hard-boot.&lt;br /&gt;
| See arm9loaderhax / description.&lt;br /&gt;
| See arm9loaderhax / description.&lt;br /&gt;
| Theorized around mid July, 2015. Later implemented+tested by [[User:Plutooo|plutoo]] and derrek.&lt;br /&gt;
| 32c3 3ds talk (December 27, 2015)&lt;br /&gt;
| [[User:Yellows8|Yellows8]]&lt;br /&gt;
|-&lt;br /&gt;
| Missing verification-block for the 9.6 keys (arm9loaderhax)&lt;br /&gt;
| 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.&lt;br /&gt;
&lt;br /&gt;
Writing an incorrect key to NAND will cause arm9loader to decrypt the ARM9 kernel as garbage and then jump to it.&lt;br /&gt;
&lt;br /&gt;
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&#039;ll find some garbage that jumps to your code.&lt;br /&gt;
&lt;br /&gt;
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. &lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
| Recovery of 6.x [[Savegames#6.0.0-11_Savegame_keyY|save key]]/7.x [[NCCH]] key&lt;br /&gt;
| None&lt;br /&gt;
| [[10.4.0-29|10.4.0-X]]&lt;br /&gt;
| March, 2015&lt;br /&gt;
| &lt;br /&gt;
| [[User:Plutooo|plutoo]]&lt;br /&gt;
|-&lt;br /&gt;
| Uncleared New3DS keyslot 0x11&lt;br /&gt;
| 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.&lt;br /&gt;
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 &amp;lt;=v9.5 New3DS keyXs which are generated by keyslot 0x11.&lt;br /&gt;
&lt;br /&gt;
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]].&lt;br /&gt;
| New3DS keyXs generation&lt;br /&gt;
| 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]].&lt;br /&gt;
| &lt;br /&gt;
| February 3, 2015 (one day after [[9.5.0-22|9.5.0-X]] release)&lt;br /&gt;
| &lt;br /&gt;
| [[User:Yellows8|Yellows8]]&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
=== Process9 ===&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot; border=&amp;quot;1&amp;quot;&lt;br /&gt;
|-&lt;br /&gt;
!  Summary&lt;br /&gt;
!  Description&lt;br /&gt;
!  Successful exploitation result&lt;br /&gt;
!  Fixed in [[FIRM]] system version&lt;br /&gt;
!  Last [[FIRM]] system version this flaw was checked for&lt;br /&gt;
!  Timeframe this was discovered&lt;br /&gt;
!  Public disclosure timeframe&lt;br /&gt;
!  Discovered by&lt;br /&gt;
|-&lt;br /&gt;
| Leak of normal-key matching a key-scrambler key&lt;br /&gt;
| 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 &amp;quot;fixed&amp;quot; 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.&lt;br /&gt;
&lt;br /&gt;
Nintendo&#039;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 &amp;quot;Hardware&amp;quot; above), the key scrambler function could be deduced.&lt;br /&gt;
| Deducing the keyX for keyslot 0x39 and the key scrambler algorithm&lt;br /&gt;
| New 3DS [[9.3.0-21|9.3.0-X]], sort of&lt;br /&gt;
| [[10.0.0-27|10.0.0-X]]&lt;br /&gt;
| Sometime in 2015 after the hardware key-generator was broken.&lt;br /&gt;
| 32c3 3ds talk (December 27, 2015)&lt;br /&gt;
| [[User:Yellows8|Yellows8]]&lt;br /&gt;
|-&lt;br /&gt;
| Leak of normal-key matching a key-generator key&lt;br /&gt;
| During the 3DS&#039; 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.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
Knowing the keyY and the normal-key for common-key index1, the devkit key-generator algorithm can be deduced (see &amp;quot;Hardware&amp;quot; above). Additionally the remaining devkit common-keys can be generated once the common-key keyX is recovered.&lt;br /&gt;
&lt;br /&gt;
Note the devkit key-generator was discovered to be the same as the retail key-generator.&lt;br /&gt;
| Deducing the keyX for keyslot 0x3D and hardware key-generator algorithm. Generate remaining devkit common-keys.&lt;br /&gt;
| pre-[[1.0.0-0|1.0.0-X]]&lt;br /&gt;
| &lt;br /&gt;
| Shortly after the key-generator was revealed to be flawed at the 32c3 3ds talk&lt;br /&gt;
| January 20, 2016&lt;br /&gt;
| [[User:Jakcron|jakcron]]&lt;br /&gt;
|-&lt;br /&gt;
| ntrcardhax&lt;br /&gt;
| &lt;br /&gt;
| ARM9 code execution&lt;br /&gt;
| None&lt;br /&gt;
| [[10.3.0-28|10.3.0-X]]&lt;br /&gt;
| March 2015&lt;br /&gt;
| 32c3 3ds talk (December 27, 2015)&lt;br /&gt;
| [[User:Plutooo|plutoo]]&lt;br /&gt;
|-&lt;br /&gt;
| Title downgrading via [[Application_Manager_Services|AM]]([[Application_Manager_Services_PXI|PXI]])&lt;br /&gt;
| 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.&lt;br /&gt;
&lt;br /&gt;
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&#039;t compare the input title-version with anything. Hence, titles can be downgraded this way.&lt;br /&gt;
| Bypassing title version check at installation, which then allows downgrading any title.&lt;br /&gt;
| None&lt;br /&gt;
| NATIVE_FIRM / AM-sysmodule [[10.0.0-27|10.0.0-X]]&lt;br /&gt;
| ?&lt;br /&gt;
| &lt;br /&gt;
| ?&lt;br /&gt;
|-&lt;br /&gt;
| FAT FS code null-deref&lt;br /&gt;
| 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&#039;t check for NULL which then triggers a read based at NULL.&lt;br /&gt;
&lt;br /&gt;
Sample &amp;quot;fsck.vfat -n -v -V &amp;lt;fat image backup&amp;gt;&amp;quot; output for the above crash:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;...&lt;br /&gt;
Starting check/repair pass.&lt;br /&gt;
&amp;lt;FilePath0&amp;gt; and&lt;br /&gt;
&amp;lt;FilePath1&amp;gt;&lt;br /&gt;
 share clusters.&lt;br /&gt;
 Truncating second to 3375104 bytes.&lt;br /&gt;
&amp;lt;FilePath1&amp;gt;&lt;br /&gt;
 File size is 2787392 bytes, cluster chain length is 16384 bytes.&lt;br /&gt;
 Truncating file to 16384 bytes.&lt;br /&gt;
Checking for unused clusters.&lt;br /&gt;
Reclaimed 1 unused cluster (16384 bytes).&lt;br /&gt;
Checking free cluster summary.&lt;br /&gt;
Free cluster summary wrong (1404490 vs. really 1404491)&lt;br /&gt;
 Auto-correcting.&lt;br /&gt;
Starting verification pass.&lt;br /&gt;
Checking for unused clusters.&lt;br /&gt;
Leaving filesystem unchanged.&amp;lt;/pre&amp;gt;&lt;br /&gt;
| Useless null-based-read&lt;br /&gt;
| None&lt;br /&gt;
| [[9.6.0-24|9.6.0-X]]&lt;br /&gt;
| July 8-9, 2015&lt;br /&gt;
| &lt;br /&gt;
| [[User:Yellows8|Yellows8]]&lt;br /&gt;
|-&lt;br /&gt;
| RSA signature padding checks&lt;br /&gt;
| The TWL_FIRM RSA sig padding check code used for all TWL RSA sig-checks has issues, see [[FIRM|here]].&lt;br /&gt;
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&#039;t really a problem here because there&#039;s proper padding check code which is executed prior to this.&lt;br /&gt;
| &lt;br /&gt;
| None&lt;br /&gt;
| [[9.5.0-22|9.5.0-X]]&lt;br /&gt;
| March 2015&lt;br /&gt;
| &lt;br /&gt;
| [[User:Yellows8|Yellows8]]&lt;br /&gt;
|-&lt;br /&gt;
| [[AMPXI:ValidateDSiWareSectionMAC]] [[AES_Registers|AES]] keyslot reuse&lt;br /&gt;
| When the input DSiWare section index is higher than &amp;lt;max number of DSiWare sections supported by this FIRM&amp;gt;, 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 &amp;gt;=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&#039;s unknown whether a timing attack would work with this.&lt;br /&gt;
This is basically a different form of the pxips9 keyslot vuln, except with AESMAC etc.&lt;br /&gt;
| See description.&lt;br /&gt;
| None&lt;br /&gt;
| [[10.2.0-28|10.2.0-X]]&lt;br /&gt;
| March 15, 2015&lt;br /&gt;
| December 29, 2015&lt;br /&gt;
| [[User:Yellows8|Yellows8]]&lt;br /&gt;
|-&lt;br /&gt;
| pxips9 [[AES_Registers|AES]] keyslot reuse&lt;br /&gt;
| 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 &amp;lt;=10.1.0-X(see 32c3 3ds talk).&lt;br /&gt;
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&#039;t return any errors, Process9 will just continue to do crypto with whatever AES keyslot was selected before the PS command was sent.&lt;br /&gt;
| Reusing the previously used keyslot, for crypto with PS.&lt;br /&gt;
| None&lt;br /&gt;
| [[10.2.0-28|10.2.0-X]]&lt;br /&gt;
| Roughly the same time(same day?) as firmlaunch-hax.&lt;br /&gt;
| December 29, 2015&lt;br /&gt;
| [[User:Yellows8|Yellows8]]&lt;br /&gt;
|-&lt;br /&gt;
| firmlaunch-hax: FIRM header ToCToU&lt;br /&gt;
| This can&#039;t be exploited from ARM11 userland.&lt;br /&gt;
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&#039;t expect &amp;quot;anything&amp;quot; besides the ARM9 to access this data.&lt;br /&gt;
With [[9.5.0-22]] the address of this FIRM header was changed from a FCRAM address, to ARM9-only address 0x01fffc00.&lt;br /&gt;
| ARM9 code execution&lt;br /&gt;
| [[9.5.0-22]]&lt;br /&gt;
| &lt;br /&gt;
| 2012, 3 days after [[User:Yellows8|Yellows8]] started Process9 code RE.&lt;br /&gt;
| &lt;br /&gt;
| [[User:Yellows8|Yellows8]]&lt;br /&gt;
|-&lt;br /&gt;
| Uninitialized data output for (PXI) command replies&lt;br /&gt;
| 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.&lt;br /&gt;
Certain ARM11 service commands have this same issue as well.&lt;br /&gt;
| &lt;br /&gt;
| None&lt;br /&gt;
| [[9.3.0-21|9.3.0-X]]&lt;br /&gt;
| ?&lt;br /&gt;
| &lt;br /&gt;
| [[User:Yellows8|Yellows8]]&lt;br /&gt;
|-&lt;br /&gt;
| [[Filesystem_services_PXI|FSPXI]] OpenArchive SD permissions&lt;br /&gt;
| Process9 does not use the exheader ARM9 access-mount permission flag for SD at all.&lt;br /&gt;
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.&lt;br /&gt;
| &lt;br /&gt;
| None&lt;br /&gt;
| [[9.3.0-21|9.3.0-X]]&lt;br /&gt;
| 2012&lt;br /&gt;
| &lt;br /&gt;
| [[User:Yellows8|Yellows8]]&lt;br /&gt;
|-&lt;br /&gt;
| [[AMPXI:ExportDSiWare]] export path&lt;br /&gt;
| 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 &amp;quot;&amp;lt;mountpoint&amp;gt;:/&amp;lt;path&amp;gt;&amp;quot;.&lt;br /&gt;
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.&lt;br /&gt;
| Exporting of DSiWare to arbitrary Process9 file-paths, such as &amp;quot;nand:/&amp;lt;path&amp;gt;&amp;quot; etc. This isn&#039;t really useful since the data which gets written can&#039;t be controlled.&lt;br /&gt;
| None&lt;br /&gt;
| [[9.5.0-22]]&lt;br /&gt;
| April 2013&lt;br /&gt;
| &lt;br /&gt;
| [[User:Yellows8|Yellows8]]&lt;br /&gt;
|-&lt;br /&gt;
| [[DSiWare_Exports]] [[CTCert]] verification&lt;br /&gt;
| 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&#039;s still not(?) fixed.&lt;br /&gt;
On 3DS however this is rather useless, due to the entire DSiWare .bin being encrypted with the console-unique movable.sed keyY.&lt;br /&gt;
| 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.&lt;br /&gt;
| Unknown, probably none.&lt;br /&gt;
| ?&lt;br /&gt;
| April 2013&lt;br /&gt;
| &lt;br /&gt;
| [[User:Yellows8|Yellows8]]&lt;br /&gt;
|-&lt;br /&gt;
| [[Gamecard_Services_PXI]] unchecked REG_CTRCARDCNT transfer-size&lt;br /&gt;
| 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&#039;t checked, thus out-of-bounds reads could be triggered(which is rather useless in this case).&lt;br /&gt;
| Out-of-bounds read for a value which gets written to a register.&lt;br /&gt;
| [[5.0.0-11|5.0.0-X]]&lt;br /&gt;
| &lt;br /&gt;
| 2013?&lt;br /&gt;
| &lt;br /&gt;
| [[User:Yellows8|Yellows8]]&lt;br /&gt;
|-&lt;br /&gt;
| [[PXI_Registers|PXI]] cmdbuf buffer overrun&lt;br /&gt;
| The Process9 code responsible [[PXI_Registers|PXI]] communications didn&#039;t verify the size of the incoming command before writing it to a C++ member variable. &lt;br /&gt;
| Probably ARM9 code execution&lt;br /&gt;
| [[5.0.0-11|5.0.0-11]]&lt;br /&gt;
| &lt;br /&gt;
| March 2015, original timeframe if any unknown&lt;br /&gt;
| &lt;br /&gt;
| [[User:Plutooo|plutoo]]/[[User:Yellows8|Yellows8]]/maybe others(?)&lt;br /&gt;
|-&lt;br /&gt;
| [[Application_Manager_Services_PXI|PXIAM]] command 0x003D0108(See also [[Application_Manager_Services|this]])&lt;br /&gt;
| 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 &amp;lt;=0x2800.&lt;br /&gt;
| ARM9 code execution&lt;br /&gt;
| [[5.0.0-11|5.0.0-X]]&lt;br /&gt;
| &lt;br /&gt;
| May 2013&lt;br /&gt;
| &lt;br /&gt;
| [[User:Yellows8|Yellows8]]&lt;br /&gt;
|-&lt;br /&gt;
| [[Process_Services_PXI|PS RSA]] commands buffer overflows&lt;br /&gt;
| pxips9 cmd1(not accessible via ps:ps) and VerifyRsaSha256: unchecked copy to a buffer in Process9&#039;s .bss, from the input FCRAM buffer. The buffer is located before the pxi cmdhandler threads&#039; stacks. SignRsaSha256 also has a buf overflow, but this isn&#039;t exploitable.&lt;br /&gt;
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]].&lt;br /&gt;
| ARM9 code execution&lt;br /&gt;
| [[5.0.0-11|5.0.0-X]]&lt;br /&gt;
| &lt;br /&gt;
| 2012&lt;br /&gt;
| &lt;br /&gt;
| [[User:Yellows8|Yellows8]]&lt;br /&gt;
|-&lt;br /&gt;
| [[PXI_Registers|PXI]] pxi_id bad check&lt;br /&gt;
| The Process9 code responsible for [[PXI_Registers|PXI]] communications read pxi_id as a signed char. There were two flaws:&lt;br /&gt;
* They used it as index to a lookup-table without checking the value at all.&lt;br /&gt;
* Another function verified that pxi_id &amp;lt; 7, allowing negative values to pass the check. This would also cause an out-of-range table-lookup.&lt;br /&gt;
| Maybe ARM9 code execution&lt;br /&gt;
| [[3.0.0-5|3.0.0-5]]&lt;br /&gt;
|&lt;br /&gt;
| March 2015, originally 2012 for the first issue at least&lt;br /&gt;
| &lt;br /&gt;
| [[User:Plutooo|plutoo]], [[User:Yellows8|Yellows8]], maybe others(?)&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
=== Kernel9 ===&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot; border=&amp;quot;1&amp;quot;&lt;br /&gt;
|-&lt;br /&gt;
!  Summary&lt;br /&gt;
!  Description&lt;br /&gt;
!  Successful exploitation result&lt;br /&gt;
!  Fixed in [[FIRM]] system version&lt;br /&gt;
!  Last [[FIRM]] system version this flaw was checked for&lt;br /&gt;
!  Timeframe this was discovered&lt;br /&gt;
!  Discovered by&lt;br /&gt;
|-&lt;br /&gt;
| [[CONFIG Registers#CFG_SYSPROT9|CFG_SYSPROT9]] bit1 not set by Kernel9&lt;br /&gt;
| 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&#039;s never locked, you can dump it once you get ARM9 code execution.&lt;br /&gt;
&lt;br /&gt;
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).&lt;br /&gt;
&lt;br /&gt;
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 -&amp;gt; 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.&lt;br /&gt;
| Dumping of the [[OTP Registers|OTP]] area&lt;br /&gt;
| [[3.0.0-5|3.0.0-X]]&lt;br /&gt;
|&lt;br /&gt;
| February 2015&lt;br /&gt;
| [[User:Plutooo|plutoo]], Normmatt independently&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
== ARM11 software ==&lt;br /&gt;
=== Kernel11 ===&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot; border=&amp;quot;1&amp;quot;&lt;br /&gt;
|-&lt;br /&gt;
!  Summary&lt;br /&gt;
!  Description&lt;br /&gt;
!  Successful exploitation result&lt;br /&gt;
!  Fixed in [[FIRM]] system version&lt;br /&gt;
!  Last [[FIRM]] system version this flaw was checked for&lt;br /&gt;
!  Timeframe this was discovered&lt;br /&gt;
!  Discovered by&lt;br /&gt;
|-&lt;br /&gt;
|  [[SVC]] table too small&lt;br /&gt;
|  The table of function pointers for SVC&#039;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.&lt;br /&gt;
&lt;br /&gt;
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&#039;t mapped as executable.&lt;br /&gt;
| &lt;br /&gt;
|  None&lt;br /&gt;
| [[10.2.0-28|10.2.0-X]]&lt;br /&gt;
| 2012&lt;br /&gt;
| Everyone&lt;br /&gt;
|-&lt;br /&gt;
|  [[SVC|svcBackdoor (0x7B)]]&lt;br /&gt;
|  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) requires patching the kernel .text or modifying SVC-access-control.&lt;br /&gt;
| See description&lt;br /&gt;
|  None&lt;br /&gt;
| [[10.2.0-28|10.2.0-X]]&lt;br /&gt;
|&lt;br /&gt;
| Everyone&lt;br /&gt;
|-&lt;br /&gt;
| [[Memory_layout#ARM11_Detailed_virtual_memory_map|0xEFF00000]] / 0xDFF00000 ARM11 kernel virtual-memory&lt;br /&gt;
| 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.&lt;br /&gt;
| &lt;br /&gt;
| None&lt;br /&gt;
| [[10.2.0-28|10.2.0-X]]&lt;br /&gt;
| &lt;br /&gt;
| &lt;br /&gt;
|-&lt;br /&gt;
| Memchunkhax2&lt;br /&gt;
| &lt;br /&gt;
| ARM11 kernel code execution&lt;br /&gt;
| [[10.4.0-29|10.4.0-X]] (partially)&lt;br /&gt;
| [[10.4.0-29|10.4.0-X]]&lt;br /&gt;
|&lt;br /&gt;
| derrek&lt;br /&gt;
|-&lt;br /&gt;
|  AffinityMask/processorid validation&lt;br /&gt;
|  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.&lt;br /&gt;
The original code with the first 3 did the following: &lt;br /&gt;
* if(u32_processorcount &amp;gt; ~0x80000001)return 0xe0e01bfd;&lt;br /&gt;
* if(s32_processorcount &amp;gt; &amp;lt;total_cores&amp;gt;)return 0xd8e007fd;&lt;br /&gt;
The following code replaced the above:&lt;br /&gt;
* if(u32_processorcount &amp;gt;= &amp;lt;total_cores+1&amp;gt;)return 0xd8e007fd;&lt;br /&gt;
In theory the latter should catch everything that the former did, so it&#039;s unknown if this was really a security issue.&lt;br /&gt;
&lt;br /&gt;
The svcCreateThread changes with [[10.0.0-27|10.0.0-X]] definitely did fix a security issue.&lt;br /&gt;
* Original code: &amp;quot;if(s32_processorid &amp;gt; &amp;lt;total_cores&amp;gt;)return 0xd8e007fd;&amp;quot;&lt;br /&gt;
* New code: &amp;quot;if(s32_processorid &amp;gt;= &amp;lt;total_cores&amp;gt; || s32_processorid &amp;lt;= -4)return 0xd8e007fd;&amp;quot;&lt;br /&gt;
This fixed an off-by-one issue: if one would use processorid=total_cores, which isn&#039;t actually a valid value, svcCreateThread would accept that value on &amp;lt;[[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:&lt;br /&gt;
* Old3DS: Useless kernel-mode crash due to accessing unmapped memory.&lt;br /&gt;
* New3DS: uncontrolled data write into a kernel-mode L1 MMU-table. This isn&#039;t really useful: the data can&#039;t be controlled, and the data which gets overwritten is all-zero anyway(this isn&#039;t anywhere near MMU L1 entries for actually mapped memory).&lt;br /&gt;
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&#039;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)).&lt;br /&gt;
| Nothing useful&lt;br /&gt;
|  [[10.0.0-27|10.0.0-X]]&lt;br /&gt;
| [[10.0.0-27|10.0.0-X]]&lt;br /&gt;
| svcCreateThread issue: May 31, 2015. The rest: September 8, 2015, via v9.6-&amp;gt;v10.0 ARM11-kernel code-diff.&lt;br /&gt;
| [[User:Yellows8|Yellows8]]&lt;br /&gt;
|-&lt;br /&gt;
| memchunkhax&lt;br /&gt;
| 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.&lt;br /&gt;
&lt;br /&gt;
There are &#039;&#039;multiple&#039;&#039; 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.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
| When combined with other flaws: ARM11-kernelmode code execution&lt;br /&gt;
| [[9.3.0-21|9.3.0-21]]&lt;br /&gt;
| &lt;br /&gt;
| February 2014&lt;br /&gt;
| [[User:Yellows8|Yellows8]]&lt;br /&gt;
|-&lt;br /&gt;
| Multiple [[KLinkedListNode|KLinkedListNode]] SlabHeap use after free bugs&lt;br /&gt;
| The ARM11-kernel did access the &#039;key&#039; 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:&lt;br /&gt;
SlabHeap_free(KLinkedListNode);&lt;br /&gt;
KObject *obj = KLinkedListNode-&amp;gt;key;  // the object there might have changed!&lt;br /&gt;
This bug appeared all over the place.&lt;br /&gt;
| ARM11-kernelmode code exec maybe&lt;br /&gt;
| [[8.0.0-18|8.0.0-18]]&lt;br /&gt;
| &lt;br /&gt;
| April 2015&lt;br /&gt;
| [[User:Derrek|derrek]]&lt;br /&gt;
|-&lt;br /&gt;
| PXI [[RPC_Command_Structure|Command]] input/output buffer permissions&lt;br /&gt;
| Originally the ARM11-kernel didn&#039;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.&lt;br /&gt;
| &lt;br /&gt;
| [[6.0.0-11|6.0.0-11]]&lt;br /&gt;
| &lt;br /&gt;
| 2012&lt;br /&gt;
| [[User:Yellows8|Yellows8]]&lt;br /&gt;
|-&lt;br /&gt;
| [[SVC|svcStartInterProcessDma]]&lt;br /&gt;
| For svcStartInterProcessDma, the kernel code had the following flaws:&lt;br /&gt;
&lt;br /&gt;
* 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.&lt;br /&gt;
&lt;br /&gt;
* Integer overflows for srcaddr+size and dstaddr+size are now checked(with [[6.0.0-11]]), which were not checked before.&lt;br /&gt;
&lt;br /&gt;
* 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 &amp;gt;=0x20000000 would result in the kernel reading from the process L1 MMU table, beyond the memory allocated for that MMU table(for vaddr-&amp;gt;physaddr conversion). &lt;br /&gt;
| &lt;br /&gt;
| [[6.0.0-11]]&lt;br /&gt;
| &lt;br /&gt;
| DmaConfig issue: unknown. The rest: 2014&lt;br /&gt;
| [[User:Plutooo|plutoo]], [[User:Yellows8|Yellows8]] independently&lt;br /&gt;
|-&lt;br /&gt;
| [[SVC|svcControlMemory]] Parameter checks&lt;br /&gt;
| For svcControlMemory the parameter check had these two flaws:&lt;br /&gt;
&lt;br /&gt;
* 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&#039;t actually use the input address for LINEAR memory-mapping at all besides the range-checks, so this isn&#039;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.&lt;br /&gt;
&lt;br /&gt;
* Integer overflows on (addr0+size) are now checked that previously weren&#039;t (this also applies to most other address checks elsewhere in the kernel).&lt;br /&gt;
&lt;br /&gt;
| &lt;br /&gt;
| [[5.0.0-11]]&lt;br /&gt;
| &lt;br /&gt;
|&lt;br /&gt;
| [[User:Plutooo|plutoo]]&lt;br /&gt;
|-&lt;br /&gt;
| [[RPC_Command_Structure|Command]] request/response buffer overflow&lt;br /&gt;
| 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.&lt;br /&gt;
&lt;br /&gt;
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 &amp;lt;nowiki&amp;gt;((size&amp;lt;&amp;lt;14) | 2)&amp;lt;/nowiki&amp;gt; to write arbitrary memory to any RW userland memory in the destination process.&lt;br /&gt;
| &lt;br /&gt;
| [[5.0.0-11]]&lt;br /&gt;
| &lt;br /&gt;
| v4.1 FIRM -&amp;gt; v5.0 code diff&lt;br /&gt;
| [[User:Yellows8|Yellows8]]&lt;br /&gt;
|-&lt;br /&gt;
| [[SVC|SVC stack allocation overflows]]&lt;br /&gt;
| &lt;br /&gt;
* 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. &lt;br /&gt;
* The alignment (size+7)&amp;amp;~7 calculation before allocation was not checked for integer overflow.&lt;br /&gt;
&lt;br /&gt;
This might allow for ARM11 kernel code-execution.&lt;br /&gt;
&lt;br /&gt;
(Applies to svcSetResourceLimitValues, svcGetThreadList, svcGetProcessList, svcReplyAndReceive, svcWaitSynchronizationN.)&lt;br /&gt;
| &lt;br /&gt;
| [[5.0.0-11]]&lt;br /&gt;
| &lt;br /&gt;
| v4.1 FIRM -&amp;gt; v5.0 code diff&lt;br /&gt;
| [[User:Plutooo|plutoo]], [[User:Yellows8|Yellows8]] complementary&lt;br /&gt;
|-&lt;br /&gt;
| [[SVC|svcControlMemory]] MemoryOperation MAP memory-permissions&lt;br /&gt;
| 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&#039;t check memory permissions for addr1. Therefore .text as addr1 could be mapped elsewhere as RW- memory, which allowed ARM11 userland code-execution.&lt;br /&gt;
| &lt;br /&gt;
| [[4.1.0-8]]&lt;br /&gt;
| &lt;br /&gt;
| 2012&lt;br /&gt;
| [[User:Yellows8|Yellows8]]&lt;br /&gt;
|-&lt;br /&gt;
| [[RPC_Command_Structure|Command]] input/output buffer permissions&lt;br /&gt;
| Originally the ARM11 kernel didn&#039;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&#039;t have the required memory permissions. For example, this allowed a FSUSER file-read to .text, which therefore allowed ARM11-userland code execution.&lt;br /&gt;
| &lt;br /&gt;
| [[4.0.0-7]]&lt;br /&gt;
| &lt;br /&gt;
| 2012&lt;br /&gt;
| [[User:Yellows8|Yellows8]]&lt;br /&gt;
|-&lt;br /&gt;
| [[SVC|svcReadProcessMemory/svcWriteProcessMemory memory]] permissions&lt;br /&gt;
| 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.&lt;br /&gt;
| &lt;br /&gt;
| [[4.0.0-7]]&lt;br /&gt;
| &lt;br /&gt;
| 2012?&lt;br /&gt;
| [[User:Yellows8|Yellows8]]&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
=== [[FIRM]] Sysmodules ===&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot; border=&amp;quot;1&amp;quot;&lt;br /&gt;
|-&lt;br /&gt;
!  Summary&lt;br /&gt;
!  Description&lt;br /&gt;
!  Successful exploitation result&lt;br /&gt;
!  Fixed in [[FIRM]] system version&lt;br /&gt;
!  Last [[FIRM]] system version this flaw was checked for&lt;br /&gt;
!  Timeframe this was discovered&lt;br /&gt;
!  Discovered by&lt;br /&gt;
|-&lt;br /&gt;
| [[Services|&amp;quot;srv:pm&amp;quot;]] process registration&lt;br /&gt;
| Originally any process had access to the port &amp;quot;srv:pm&amp;quot;. The PID&#039;s used for the (un)registration commands are not checked either. This allowed any process to re-register itself with &amp;quot;srv:pm&amp;quot;, and therefore allowed the process to give itself access to any service, bypassing the exheader service-access-control list.&lt;br /&gt;
&lt;br /&gt;
This was fixed in [[7.0.0-13]]: starting with [[7.0.0-13]] &amp;quot;srv:pm&amp;quot; is now a service instead of a globally accessible port. Only processes with PID&#039;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 &amp;quot;srv:pm&amp;quot; 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.&lt;br /&gt;
&lt;br /&gt;
This flaw was needed for exploiting the &amp;lt;=v4.x Process9 PXI vulnerabilities from ARM11 userland ROP, since most applications don&#039;t have access to those service(s).&lt;br /&gt;
| Access to arbitrary services&lt;br /&gt;
| [[7.0.0-13]]&lt;br /&gt;
| &lt;br /&gt;
| 2012&lt;br /&gt;
| [[User:Yellows8|Yellows8]]&lt;br /&gt;
|-&lt;br /&gt;
| FSDIR null-deref&lt;br /&gt;
| [[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&#039;s just a null-deref.&lt;br /&gt;
| &lt;br /&gt;
| None&lt;br /&gt;
| [[9.6.0-24|9.6.0-X]]&lt;br /&gt;
| May 19(?)-20, 2015&lt;br /&gt;
| [[User:Yellows8|Yellows8]]&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
=== Standalone Sysmodules ===&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot; border=&amp;quot;1&amp;quot;&lt;br /&gt;
|-&lt;br /&gt;
!  Summary&lt;br /&gt;
!  Description&lt;br /&gt;
!  Successful exploitation result&lt;br /&gt;
!  Fixed in system-module system-version&lt;br /&gt;
!  Last system-module system-version this flaw was checked for&lt;br /&gt;
!  Timeframe this was discovered&lt;br /&gt;
!  Timeframe this was added to wiki&lt;br /&gt;
!  Discovered by&lt;br /&gt;
|-&lt;br /&gt;
| [[IR_Services|IR]]: Stack buffer overflow with custom hardware&lt;br /&gt;
| 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.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
| ROP under IR sysmodule.&lt;br /&gt;
| [[10.6.0-31|10.6.0-31]]&lt;br /&gt;
| &lt;br /&gt;
| February 23, 2016 (Unknown if it was noticed before then)&lt;br /&gt;
| February 23, 2016&lt;br /&gt;
| [[User:Yellows8|Yellows8]]&lt;br /&gt;
|-&lt;br /&gt;
| [[NIM_Services|NIM]]: Downloading old title-versions from eShop&lt;br /&gt;
| 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 &#039;&#039;if&#039;&#039; it&#039;s still available from CDN.&lt;br /&gt;
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).&lt;br /&gt;
&lt;br /&gt;
Originally this was tested with a debugging-system via modded-FIRM, eventually smea implemented it in HANS for the 32c3 release.&lt;br /&gt;
| Downloading old title-versions from eShop&lt;br /&gt;
| None&lt;br /&gt;
| [[10.0.0-27|10.0.0-X]]&lt;br /&gt;
| October 24, 2015 (Unknown when exactly the first eShop title downgrade was actually tested, maybe November)&lt;br /&gt;
| January 7, 2016 (Same day Ironfall v1.0 was removed from CDN via the main-CXI files)&lt;br /&gt;
| [[User:Yellows8|Yellows8]]&lt;br /&gt;
|-&lt;br /&gt;
| [[SPI_Services|SPI]] service out-of-bounds write&lt;br /&gt;
| cmd1 has out-of-bounds write allowing overwrite of some static variables in .data.&lt;br /&gt;
| &lt;br /&gt;
| None&lt;br /&gt;
| [[9.5.0-22]]&lt;br /&gt;
| March 2015&lt;br /&gt;
| &lt;br /&gt;
| [[User:Plutooo|plutoo]]&lt;br /&gt;
|-&lt;br /&gt;
| [[NFC_Services|NFC]] module service command buf-overflows&lt;br /&gt;
| NFC module copies data with certain commands, from command input buffers to stack without checking the size. These commands include the following, it&#039;s unknown if there&#039;s more commands with similar issues: &amp;quot;nfc:dev&amp;quot; &amp;lt;0x000C....&amp;gt; and &amp;quot;nfc:s&amp;quot; &amp;lt;0x0037....&amp;gt;.&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
There&#039;s no known retail titles which have access to either of these services.&lt;br /&gt;
| ROP under NFC module.&lt;br /&gt;
| New3DS: None&lt;br /&gt;
| New3DS: [[9.5.0-22]]&lt;br /&gt;
| December 2014?&lt;br /&gt;
| &lt;br /&gt;
| [[User:Yellows8|Yellows8]]&lt;br /&gt;
|-&lt;br /&gt;
| [[News_Services|NEWSS]] service command notificationID validation failure&lt;br /&gt;
| This module does not validate the input notificationID for &amp;lt;nowiki&amp;gt;&amp;quot;news:s&amp;quot;&amp;lt;/nowiki&amp;gt; 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).&lt;br /&gt;
| ROP under news module.&lt;br /&gt;
| None&lt;br /&gt;
| [[9.7.0-25|9.7.0-X]]&lt;br /&gt;
| December 2014&lt;br /&gt;
| &lt;br /&gt;
| [[User:Yellows8|Yellows8]]&lt;br /&gt;
|-&lt;br /&gt;
| [[NWMUDS:DecryptBeaconData]] heap buffer overflow&lt;br /&gt;
| input_size = 0x1E * &amp;lt;value the u8 from input_[[NWM_Services|networkstruct]]+0x1D&amp;gt;. Then input_tag0 is copied to a heap buffer. When input_size is larger than 0xFA-bytes, it will then copy input_tag1 to &amp;lt;end_address_of_previous_outbuf&amp;gt;, with size=input_size-0xFA.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
There&#039;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&#039;t be controlled it seems(with just broadcasting a beacon at least). It&#039;s unknown whether this could be exploited from just using NWMUDS service-cmd(s) directly.&lt;br /&gt;
| 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.&lt;br /&gt;
| None&lt;br /&gt;
| [[9.0.0-20]]&lt;br /&gt;
| ~September 23, 2014(see the [[NWMUDS:DecryptBeaconData]] page history)&lt;br /&gt;
| August 3, 2015&lt;br /&gt;
| [[User:Yellows8|Yellows8]]&lt;br /&gt;
|-&lt;br /&gt;
| [[HID_Services|HID]] module shared-mem&lt;br /&gt;
| 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.&lt;br /&gt;
| ROP under HID module, but this is *very* unlikely to be exploitable since the data written is HID data.&lt;br /&gt;
| None&lt;br /&gt;
| [[9.3.0-21]]&lt;br /&gt;
| 2014?&lt;br /&gt;
| &lt;br /&gt;
| [[User:Yellows8|Yellows8]]&lt;br /&gt;
|-&lt;br /&gt;
| gspwn&lt;br /&gt;
| 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&#039;re running under, and gain real code-execution from a ROP-chain. Normally applets&#039; .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).&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
| User-mode code execution.&lt;br /&gt;
| None&lt;br /&gt;
| [[9.6.0-24|9.6.0-X]]&lt;br /&gt;
| Early 2014&lt;br /&gt;
| &lt;br /&gt;
| smea, [[User:Yellows8|Yellows8]]/others before then&lt;br /&gt;
|-&lt;br /&gt;
| rohax&lt;br /&gt;
| 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.&lt;br /&gt;
&lt;br /&gt;
This was fixed after [[ninjhax]] release by adding checks on [[CRO0]]-based pointers before writing to them.&lt;br /&gt;
| Memory-mapping syscalls.&lt;br /&gt;
| [[9.3.0-21]]&lt;br /&gt;
| [[9.4.0-21]]&lt;br /&gt;
| &lt;br /&gt;
| &lt;br /&gt;
| smea, [[User:Plutooo|plutoo]] joint effort&lt;br /&gt;
|-&lt;br /&gt;
| Region free&lt;br /&gt;
| Only [[Home Menu]] itself checks gamecards&#039; 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.&lt;br /&gt;
This essentially means launching the gamecard with the [[NS_and_APT_Services|&amp;quot;ns:s&amp;quot;]] 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]].&lt;br /&gt;
| Launching gamecards from any region + bypassing Home Menu gamecard-sysupdate installation&lt;br /&gt;
| None&lt;br /&gt;
| Last tested with [[10.1.0-27|10.1.0-X]].&lt;br /&gt;
| June(?) 2014&lt;br /&gt;
| &lt;br /&gt;
| [[User:Yellows8|Yellows8]]&lt;br /&gt;
|-&lt;br /&gt;
| [[NWM_Services|NWM]] service-cmd state null-ptr deref&lt;br /&gt;
| 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.&lt;br /&gt;
It&#039;s unknown whether any NWM services besides NWMUDS have this issue.&lt;br /&gt;
| This is rather useless since it&#039;s only a crash caused by a state ptr based at 0x0.&lt;br /&gt;
| None&lt;br /&gt;
| [[9.0.0-20]]&lt;br /&gt;
| 2013?&lt;br /&gt;
| &lt;br /&gt;
| [[User:Yellows8|Yellows8]]&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
=== General/CTRSDK ===&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot; border=&amp;quot;1&amp;quot;&lt;br /&gt;
|-&lt;br /&gt;
!  Summary&lt;br /&gt;
!  Description&lt;br /&gt;
!  Successful exploitation result&lt;br /&gt;
!  Fixed in version&lt;br /&gt;
!  Last version this flaw was checked for&lt;br /&gt;
!  Timeframe this was discovered&lt;br /&gt;
!  Discovered by&lt;br /&gt;
|-&lt;br /&gt;
| [[NWM_Services|UDS]] beacon additional-data buffer overflow&lt;br /&gt;
| 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.&lt;br /&gt;
This was discovered while doing code RE with an old dlp-module version. It&#039;s unknown in what specific CTRSDK version this was fixed, or even what system-version updated titles with a fixed version.&lt;br /&gt;
&lt;br /&gt;
It&#039;s unknown if there&#039;s any titles using a vulnerable CTRSDK version which are also exploitable with this(dlp module can&#039;t be exploited with this).&lt;br /&gt;
&lt;br /&gt;
The maximum number of bytes that can be written beyond the end of the outbuf is 0x37-bytes, with additionaldata_size=0xFF.&lt;br /&gt;
| Perhaps ROP, very difficult if possible with anything at all&lt;br /&gt;
| ?&lt;br /&gt;
| &lt;br /&gt;
| September(?) 2014&lt;br /&gt;
| [[User:Yellows8|Yellows8]]&lt;br /&gt;
|}&lt;/div&gt;</summary>
		<author><name>Motezazer</name></author>
	</entry>
	<entry>
		<id>https://www.3dbrew.org/w/index.php?title=10.4.0-29&amp;diff=15998</id>
		<title>10.4.0-29</title>
		<link rel="alternate" type="text/html" href="https://www.3dbrew.org/w/index.php?title=10.4.0-29&amp;diff=15998"/>
		<updated>2016-03-08T19:55:31Z</updated>

		<summary type="html">&lt;p&gt;Motezazer: memchunkhax2 status clarification&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;The Old3DS+New3DS 10.4.0-29 system update was released on January 18, 2016. This Old3DS update was released for the following regions: USA, EUR, JPN, CHN, KOR, and TWN. This New3DS update was released for the following regions: USA, EUR, JPN, CHN, and KOR.&lt;br /&gt;
&lt;br /&gt;
Security flaws fixed: yes, see below.&lt;br /&gt;
&lt;br /&gt;
Old3DS/New3DS browserhax and menuhax were not fixed(the Old3DS browser wasn&#039;t even updated).&lt;br /&gt;
&lt;br /&gt;
==Change-log==&lt;br /&gt;
[http://en-americas-support.nintendo.com/app/answers/detail/a_id/667/p/430/c/267 Official] USA change-log:&lt;br /&gt;
* Further improvements to overall system stability and other minor adjustments have been made to enhance the user experience&lt;br /&gt;
&lt;br /&gt;
==System Titles==&lt;br /&gt;
&lt;br /&gt;
===NATIVE_FIRM===&lt;br /&gt;
[[3DS_System_Flaws#Kernel11|memchunkhax2]] was partially fixed by reading the [[MemoryBlockHeader]] next pointer before it is mapped to userland, but it can still be exploited using GPU. Only &#039;&#039;one&#039;&#039; function was changed in arm11kernel.&lt;br /&gt;
&lt;br /&gt;
The only updated FIRM sysmodules were fs and loader, for fs only a version-field in .code was updated used with a debug NOP-instruction.&lt;br /&gt;
&lt;br /&gt;
====loader====&lt;br /&gt;
The loader process .text was previously 0x331C-bytes, it&#039;s now 0x36F0-bytes.&lt;br /&gt;
&lt;br /&gt;
All code changes:&lt;br /&gt;
* Some code using svcGetSystemTick was added. This is used by L_14002670.&lt;br /&gt;
* L_140022b8(L_14002234 in previous loader version): This is the function which calls L_140025f0. Code was added between the code which loads the memregion value from exheader, and the func call for mapping it(L_140025f0). This new code determines what to pass for the L_140025f0 insp4 flag. By default the value passed for that flag is 0.&lt;br /&gt;
** When the process memregion is APPLICATION, the programID is for a CTR title, and the uniqueid matches the eShop system-application(&#039;&#039;all&#039;&#039; regions including CHN), the flag is set to 1.&lt;br /&gt;
** When the process memregion is SYSTEM, the flag is set to 1 when the reslimit_category is not LIB_APPLET.&lt;br /&gt;
* L_140025f0(L_140024e4 in previous loader version) now calls another function(L_14002670) instead of svcControlMemory directly, for mapping the codebin memory. The insp4 flag from the L_140025f0 input is passed to L_14002670 as sp0.&lt;br /&gt;
* L_14002670: New function used for mapping the codebin. When the insp0 flag is zero, this does the normal memory-mapping, otherwise a special memory-mapping codepath is used. This codepath still uses the same memregion specified in the exheader.&lt;br /&gt;
&lt;br /&gt;
The special memory-mapping codepath is basically a method of mapping the codebin with svcControlMemory using up to 8 chunks, each with a random size. Each chunk is done in a random order. Since the allocation order is random, this also means the order of each .text chunk in physmem is random too. When the total size of the randomized page-count is less than the required amount, an 8th chunk is used to pad the total size to the exact required size. It appears the total combined size used with svcControlMemory is &#039;&#039;always&#039;&#039; exactly the same as what&#039;s required for the codebin.&lt;br /&gt;
&lt;br /&gt;
Regarding chunk size calculation:&lt;br /&gt;
* s32 maxval = (codebin_totalrequiredpages - pagepos) &amp;gt;&amp;gt; 4;&lt;br /&gt;
* The above maxval field is set to 15 if it&#039;s &amp;gt;=15.&lt;br /&gt;
* pagecount = L_14001730(maxval);&lt;br /&gt;
* pagecount = (pagecount+1) &amp;lt;&amp;lt; 4;&lt;br /&gt;
* chunksize = pagecount &amp;lt;&amp;lt; 12;&lt;br /&gt;
&lt;br /&gt;
This is an attempt at randomizing the layout of physmem .text, due to gspwn.&lt;br /&gt;
&lt;br /&gt;
====ARM9====&lt;br /&gt;
There were no New3DS-only changes in Process9, the arm9loader wasn&#039;t changed either.&lt;br /&gt;
&lt;br /&gt;
There were exactly 4 updated functions in Process9, all of these involve NTRCARD:&lt;br /&gt;
* The first two functions had code added which clears a certain state field to 0 around the beginning of the function.&lt;br /&gt;
* The third function now passes value 0x1000 as inr2 when calling the fourth function.&lt;br /&gt;
* The fourth and last function, this is the function used for reading the card header. A buffer-overflow check was added in the NTRCARD reading loop: &amp;quot;if(out_bufpos &amp;gt;= inr2)&amp;lt;skip over copying the word to output&amp;gt;&amp;quot;.&lt;br /&gt;
&lt;br /&gt;
===NS===&lt;br /&gt;
NS added [[APT:IsTitleAllowed|a new APT command]] used by Home Menu which now checks whether IronFall is on the latest version before launching; if it is on an exploitable version and the function is called to launch IronFall the system will refuse to launch the title(it&#039;s unknown what exactly caused a &amp;quot;reboot&amp;quot; here). This check is done again before launching the title, throwing an error if it fails.&lt;br /&gt;
&lt;br /&gt;
All [[NS]] code changes:&lt;br /&gt;
* L_103e6c(prev ver at L_103e6c): APT cmd-handler, this was updated for the command mentioned above.&lt;br /&gt;
* L_1086f4: New function, this is called by the above cmd-handler. This basically just calls L_10b1cc.&lt;br /&gt;
* L_10b1cc: New function, this is the actual [[APT:IsTitleAllowed]] implementation. Returns 0 for blocked, 1 for allowed.&lt;br /&gt;
** The beginning of this function is the same as L_10d598, without the u16 check right away.&lt;br /&gt;
** This initializes amu, then uses [[AM:GetTitleInfo]] with the input programID(mediatype is hard-coded to SD). If the latter returns an error, this will exit with retval0.&lt;br /&gt;
** If u16 entry+4 is &amp;lt; (titleversion&amp;gt;&amp;gt;10), this then exits with retval1.&lt;br /&gt;
** Then the AM:GetTitleInfo + versioncheck code is repeated using the update-data title.&lt;br /&gt;
** This lastly exits, with retval1 if the update-data titlever is newer than the entry one.&lt;br /&gt;
* L_10d598: New function, only called by L_10df40. This is the internal-NS-only version of the [[APT:IsTitleAllowed]] code. Returns 0 for blocked, 1 for allowed.&lt;br /&gt;
** This immediately returns 1 when the mediatype isn&#039;t SD, or when the title isn&#039;t a CTR title.&lt;br /&gt;
** Then it loads the uniqueid from the input struct, for determining which entry to use from a table in .rodata. The uniqueid is compared with hard-coded constants in the function code itself, even though the table contains the uniqueids too. The code looks like: &amp;quot;if(uniqueid == constant0) {entryptr = addr0} else if ...&amp;quot;. When no entry is found, this immediately returns 1.&lt;br /&gt;
** Lastly, if input_version_value is &amp;lt;= u16 entry+4, this returns 0, otherwise 1 is returned.&lt;br /&gt;
* L_10df40(prev ver at L_10ddd4): This appears to be the main function used by NS for launching titles in general(minus [[NSS:LaunchTitle]] used by the *hax payloads). Code was added for calling L_10d598() in two locations. The version value passed to L_10d598 here is the title NCCH remaster-version. When that function returns &amp;lt;blocked&amp;gt;, this code returns error 0xC8A0CC04.&lt;br /&gt;
&lt;br /&gt;
See [[APT:IsTitleAllowed|here]] regarding the contents of that table.&lt;br /&gt;
&lt;br /&gt;
===Home Menu===&lt;br /&gt;
The code changes for Home Menu appear to be just title/AM related / GUI.&lt;br /&gt;
&lt;br /&gt;
Code was implemented for using [[APT:IsTitleAllowed]] mentioned above. This is only done after VersionList handling(for example when one tries to launch the app without updating), prior to doing the actual application launch. When that returns 0, Home Menu will display a message using the following text from new message-strings:&lt;br /&gt;
 You need to update this &lt;br /&gt;
 software before you can&lt;br /&gt;
 launch it.&lt;br /&gt;
&lt;br /&gt;
===SpotPass sysmodule===&lt;br /&gt;
Only one function was changed in the [[BOSS_Services|BOSS]]/SpotPass sysmodule, the changes in this function seem to be minor.&lt;br /&gt;
&lt;br /&gt;
===Internet Browser===&lt;br /&gt;
Only the New3DS Internet Browser was updated, see [[Internet_Browser|here]] for that.&lt;br /&gt;
&lt;br /&gt;
===eShop system-application===&lt;br /&gt;
Some ratings-related strings were added to the main codebin(&amp;quot;ratPEGI_U_02&amp;quot; and &amp;quot;detailPEGI_D_01&amp;quot;).&lt;br /&gt;
&lt;br /&gt;
The message files were updated:&lt;br /&gt;
 diff --git a/v19465/tiger.msbt.lz.decom.wstrs b/v20482/tiger.msbt.lz.decom.wstrs&lt;br /&gt;
 index 2a3a24e..55358d0 100644&lt;br /&gt;
 --- a/v19465/tiger.msbt.lz.decom.wstrs&lt;br /&gt;
 +++ b/v20482/tiger.msbt.lz.decom.wstrs&lt;br /&gt;
 @@ -258,6 +258,7 @@ Charts&lt;br /&gt;
  Search Results: &lt;br /&gt;
  Price: TBD&lt;br /&gt;
  Offers in-game purchases&lt;br /&gt;
 +Video &lt;br /&gt;
  This software is currently unavailable.&lt;br /&gt;
  Page &lt;br /&gt;
  Go to Page&lt;br /&gt;
&lt;br /&gt;
===mint===&lt;br /&gt;
Only the main codebin was updated, nothing changed with strings in that codebin(besides a string containing a version which gets updated for each mint update).&lt;br /&gt;
&lt;br /&gt;
===0004009B00012302===&lt;br /&gt;
The USA 0004009B00012302 CFA(and the equivalent titleIDs for the other regions) was updated, the following message was added to 20000_msbt_LZ.bin:&lt;br /&gt;
 An error has occurred.&lt;br /&gt;
 Please check if there is corrupted data&lt;br /&gt;
 in Data Management &lt;br /&gt;
  Nintendo 3DS&lt;br /&gt;
 in the System Settings.&lt;br /&gt;
 If the problem persists, please&lt;br /&gt;
 make a note of the error code&lt;br /&gt;
 and visit support.nintendo.com.&lt;br /&gt;
&lt;br /&gt;
==See Also==&lt;br /&gt;
System update report(s):&lt;br /&gt;
* [http://yls8.mtheall.com/ninupdates/reports.php?date=01-18-16_07-00-49&amp;amp;sys=ctr]&lt;br /&gt;
* [http://yls8.mtheall.com/ninupdates/reports.php?date=01-18-16_07-00-58&amp;amp;sys=ktr]&lt;/div&gt;</summary>
		<author><name>Motezazer</name></author>
	</entry>
	<entry>
		<id>https://www.3dbrew.org/w/index.php?title=3DS_System_Flaws&amp;diff=15997</id>
		<title>3DS System Flaws</title>
		<link rel="alternate" type="text/html" href="https://www.3dbrew.org/w/index.php?title=3DS_System_Flaws&amp;diff=15997"/>
		<updated>2016-03-08T16:24:47Z</updated>

		<summary type="html">&lt;p&gt;Motezazer: Memchunkhax2 wasn&amp;#039;t completly fixed with 10.4&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;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]].&lt;br /&gt;
&lt;br /&gt;
=Stale / Rejected Efforts=&lt;br /&gt;
* Neimod has been working on a RAM dumping setup for a little while now. He&#039;s de-soldered the 3DS&#039;s RAM chip and hooked it and the RAM pinouts on the 3DS&#039; 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.&lt;br /&gt;
&lt;br /&gt;
* Someone (who will remain unnamed) has released CFW and CIA installers, all of which is copied from the work of others, or copyrighted material.&lt;br /&gt;
&lt;br /&gt;
==Tips and info==&lt;br /&gt;
The 3DS uses the XN feature of the ARM11 processor. There&#039;s no official way from applications to enable executable permission for memory containing arbitrary unsigned code(there&#039;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.&lt;br /&gt;
&lt;br /&gt;
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).&lt;br /&gt;
&lt;br /&gt;
=System flaws=&lt;br /&gt;
== Hardware ==&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot; border=&amp;quot;1&amp;quot;&lt;br /&gt;
!  Summary&lt;br /&gt;
!  Description&lt;br /&gt;
!  Fixed with hardware model/revision&lt;br /&gt;
!  Newest hardware model/revision this flaw was checked for&lt;br /&gt;
!  Timeframe this was discovered&lt;br /&gt;
!  Discovered by&lt;br /&gt;
|-&lt;br /&gt;
| ARM9/ARM11 bootrom vectors point at unitialized RAM&lt;br /&gt;
| ARM9&#039;s and ARM11&#039;s exception vectors are hardcoded to point at the CPU&#039;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. &lt;br /&gt;
Since RAM isn&#039;t cleared on boot (see below), one can immediately start execution of their own code here to dump bootrom, OTP, etc.&lt;br /&gt;
The ARM9 bootrom does the following at reset:  reset vector branches to another instruction, then branches to bootrom+0x8000. Hence, there&#039;s no way to know for certain when exactly the ARM9 exception-vector data stored in memory gets initialized.&lt;br /&gt;
&lt;br /&gt;
This requires *very* *precise* timing for triggering the hardware fault: it&#039;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&#039;t).&lt;br /&gt;
| None: all available 3DS models at the time of writing have the exact same ARM9/ARM11 bootrom for the unprotected areas.&lt;br /&gt;
| New3DS&lt;br /&gt;
| End of February 2014&lt;br /&gt;
| [[User:Derrek|derrek]], WulfyStylez (May 2015) independently&lt;br /&gt;
|-&lt;br /&gt;
| Missing AES key clearing&lt;br /&gt;
| The hardware AES engine does not clear keys when doing a hard reset/reboot.&lt;br /&gt;
| None&lt;br /&gt;
| New3DS&lt;br /&gt;
| August 2014&lt;br /&gt;
| Mathieulh/Others&lt;br /&gt;
|-&lt;br /&gt;
| No RAM clearing on reboots&lt;br /&gt;
| On an MCU-triggered reboot all RAM including FCRAM/ARM9 memory/AXIWRAM/VRAM keeps its contents.&lt;br /&gt;
| None&lt;br /&gt;
| New3DS&lt;br /&gt;
| March 2014&lt;br /&gt;
| [[User:Derrek|derrek]]&lt;br /&gt;
|-&lt;br /&gt;
| 32bits of actual console-unique TWLNAND keydata&lt;br /&gt;
| 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&#039;s highest bit is always ORed. only 31 bits of the TWL console-unique keydata / TWL consoleID are actually console-unique.&lt;br /&gt;
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).&lt;br /&gt;
| None&lt;br /&gt;
| New3DS&lt;br /&gt;
| 2012?&lt;br /&gt;
| [[User:Yellows8|Yellows8]]&lt;br /&gt;
|-&lt;br /&gt;
| DSi / 3DS-TWL key-generator&lt;br /&gt;
| 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.&lt;br /&gt;
This applies to the keyX/keyY too.&lt;br /&gt;
&lt;br /&gt;
This attack does not work for the 3DS key-generator because keyslots 0-3 are only for TWL keys.&lt;br /&gt;
| None&lt;br /&gt;
| New3DS&lt;br /&gt;
| 2011&lt;br /&gt;
| [[User:Yellows8|Yellows8]]&lt;br /&gt;
|-&lt;br /&gt;
| 3DS key-generator&lt;br /&gt;
| 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.&lt;br /&gt;
&lt;br /&gt;
Several such pairs of matching normal-keys and KeyY values were found, leading to deducing the key-generator function.&lt;br /&gt;
| None&lt;br /&gt;
| New3DS&lt;br /&gt;
| February 2015&lt;br /&gt;
| [[User:Yellows8|Yellows8]], [[User:Plutooo|plutoo]]&lt;br /&gt;
|-&lt;br /&gt;
| FIRM partitions known-plaintext&lt;br /&gt;
| The [[Flash_Filesystem|FIRM partitions]] are encrypted with AES-CTR without a MAC. Since this works by XOR&#039;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.&lt;br /&gt;
&lt;br /&gt;
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).&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
| None&lt;br /&gt;
| New3DS&lt;br /&gt;
| &lt;br /&gt;
| Everyone&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
== ARM9 software ==&lt;br /&gt;
=== arm9loader ===&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot; border=&amp;quot;1&amp;quot;&lt;br /&gt;
|-&lt;br /&gt;
!  Summary&lt;br /&gt;
!  Description&lt;br /&gt;
!  Successful exploitation result&lt;br /&gt;
!  Fixed in [[FIRM]] system version&lt;br /&gt;
!  Last [[FIRM]] system version this flaw was checked for&lt;br /&gt;
!  Timeframe this was discovered&lt;br /&gt;
!  Public disclosure timeframe&lt;br /&gt;
!  Discovered by&lt;br /&gt;
|-&lt;br /&gt;
| Uncleared OTP hash keydata in console-unique 0x11 key-generation&lt;br /&gt;
| 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.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
This can be performed by exploiting the &amp;quot;arm9loaderhax&amp;quot; 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 &amp;lt;[[3.0.0-6|3.0.0-X]].&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
| Derivation of all New3DS keys generated via the NAND keystore (0x1B &amp;quot;Secure4&amp;quot; etc.)&lt;br /&gt;
| None&lt;br /&gt;
| [[10.4.0-29|10.4.0-X]]&lt;br /&gt;
| ~April 2015, implemented in May 2015&lt;br /&gt;
| 13 January 2016&lt;br /&gt;
| [[User:WulfyStylez|WulfyStylez]], [[User:Dazzozo|Dazzozo]], [[User:Shinyquagsire23|shinyquagsire23]] (complimentary + implemented), [[User:Plutooo|plutoo]], Normmatt (discovered independently)&lt;br /&gt;
|-&lt;br /&gt;
| enhanced-arm9loaderhax&lt;br /&gt;
| See the 32c3 3ds talk.&lt;br /&gt;
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&#039;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.&lt;br /&gt;
| arm9loaderhax which automatically occurs at hard-boot.&lt;br /&gt;
| See arm9loaderhax / description.&lt;br /&gt;
| See arm9loaderhax / description.&lt;br /&gt;
| Theorized around mid July, 2015. Later implemented+tested by [[User:Plutooo|plutoo]] and derrek.&lt;br /&gt;
| 32c3 3ds talk (December 27, 2015)&lt;br /&gt;
| [[User:Yellows8|Yellows8]]&lt;br /&gt;
|-&lt;br /&gt;
| Missing verification-block for the 9.6 keys (arm9loaderhax)&lt;br /&gt;
| 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.&lt;br /&gt;
&lt;br /&gt;
Writing an incorrect key to NAND will cause arm9loader to decrypt the ARM9 kernel as garbage and then jump to it.&lt;br /&gt;
&lt;br /&gt;
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&#039;ll find some garbage that jumps to your code.&lt;br /&gt;
&lt;br /&gt;
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. &lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
| Recovery of 6.x [[Savegames#6.0.0-11_Savegame_keyY|save key]]/7.x [[NCCH]] key&lt;br /&gt;
| None&lt;br /&gt;
| [[10.4.0-29|10.4.0-X]]&lt;br /&gt;
| March, 2015&lt;br /&gt;
| &lt;br /&gt;
| [[User:Plutooo|plutoo]]&lt;br /&gt;
|-&lt;br /&gt;
| Uncleared New3DS keyslot 0x11&lt;br /&gt;
| 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.&lt;br /&gt;
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 &amp;lt;=v9.5 New3DS keyXs which are generated by keyslot 0x11.&lt;br /&gt;
&lt;br /&gt;
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]].&lt;br /&gt;
| New3DS keyXs generation&lt;br /&gt;
| 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]].&lt;br /&gt;
| &lt;br /&gt;
| February 3, 2015 (one day after [[9.5.0-22|9.5.0-X]] release)&lt;br /&gt;
| &lt;br /&gt;
| [[User:Yellows8|Yellows8]]&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
=== Process9 ===&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot; border=&amp;quot;1&amp;quot;&lt;br /&gt;
|-&lt;br /&gt;
!  Summary&lt;br /&gt;
!  Description&lt;br /&gt;
!  Successful exploitation result&lt;br /&gt;
!  Fixed in [[FIRM]] system version&lt;br /&gt;
!  Last [[FIRM]] system version this flaw was checked for&lt;br /&gt;
!  Timeframe this was discovered&lt;br /&gt;
!  Public disclosure timeframe&lt;br /&gt;
!  Discovered by&lt;br /&gt;
|-&lt;br /&gt;
| Leak of normal-key matching a key-scrambler key&lt;br /&gt;
| 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 &amp;quot;fixed&amp;quot; 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.&lt;br /&gt;
&lt;br /&gt;
Nintendo&#039;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 &amp;quot;Hardware&amp;quot; above), the key scrambler function could be deduced.&lt;br /&gt;
| Deducing the keyX for keyslot 0x39 and the key scrambler algorithm&lt;br /&gt;
| New 3DS [[9.3.0-21|9.3.0-X]], sort of&lt;br /&gt;
| [[10.0.0-27|10.0.0-X]]&lt;br /&gt;
| Sometime in 2015 after the hardware key-generator was broken.&lt;br /&gt;
| 32c3 3ds talk (December 27, 2015)&lt;br /&gt;
| [[User:Yellows8|Yellows8]]&lt;br /&gt;
|-&lt;br /&gt;
| Leak of normal-key matching a key-generator key&lt;br /&gt;
| During the 3DS&#039; 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.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
Knowing the keyY and the normal-key for common-key index1, the devkit key-generator algorithm can be deduced (see &amp;quot;Hardware&amp;quot; above). Additionally the remaining devkit common-keys can be generated once the common-key keyX is recovered.&lt;br /&gt;
&lt;br /&gt;
Note the devkit key-generator was discovered to be the same as the retail key-generator.&lt;br /&gt;
| Deducing the keyX for keyslot 0x3D and hardware key-generator algorithm. Generate remaining devkit common-keys.&lt;br /&gt;
| pre-[[1.0.0-0|1.0.0-X]]&lt;br /&gt;
| &lt;br /&gt;
| Shortly after the key-generator was revealed to be flawed at the 32c3 3ds talk&lt;br /&gt;
| January 20, 2016&lt;br /&gt;
| [[User:Jakcron|jakcron]]&lt;br /&gt;
|-&lt;br /&gt;
| ntrcardhax&lt;br /&gt;
| &lt;br /&gt;
| ARM9 code execution&lt;br /&gt;
| None&lt;br /&gt;
| [[10.3.0-28|10.3.0-X]]&lt;br /&gt;
| March 2015&lt;br /&gt;
| 32c3 3ds talk (December 27, 2015)&lt;br /&gt;
| [[User:Plutooo|plutoo]]&lt;br /&gt;
|-&lt;br /&gt;
| Title downgrading via [[Application_Manager_Services|AM]]([[Application_Manager_Services_PXI|PXI]])&lt;br /&gt;
| 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.&lt;br /&gt;
&lt;br /&gt;
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&#039;t compare the input title-version with anything. Hence, titles can be downgraded this way.&lt;br /&gt;
| Bypassing title version check at installation, which then allows downgrading any title.&lt;br /&gt;
| None&lt;br /&gt;
| NATIVE_FIRM / AM-sysmodule [[10.0.0-27|10.0.0-X]]&lt;br /&gt;
| ?&lt;br /&gt;
| &lt;br /&gt;
| ?&lt;br /&gt;
|-&lt;br /&gt;
| FAT FS code null-deref&lt;br /&gt;
| 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&#039;t check for NULL which then triggers a read based at NULL.&lt;br /&gt;
&lt;br /&gt;
Sample &amp;quot;fsck.vfat -n -v -V &amp;lt;fat image backup&amp;gt;&amp;quot; output for the above crash:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;...&lt;br /&gt;
Starting check/repair pass.&lt;br /&gt;
&amp;lt;FilePath0&amp;gt; and&lt;br /&gt;
&amp;lt;FilePath1&amp;gt;&lt;br /&gt;
 share clusters.&lt;br /&gt;
 Truncating second to 3375104 bytes.&lt;br /&gt;
&amp;lt;FilePath1&amp;gt;&lt;br /&gt;
 File size is 2787392 bytes, cluster chain length is 16384 bytes.&lt;br /&gt;
 Truncating file to 16384 bytes.&lt;br /&gt;
Checking for unused clusters.&lt;br /&gt;
Reclaimed 1 unused cluster (16384 bytes).&lt;br /&gt;
Checking free cluster summary.&lt;br /&gt;
Free cluster summary wrong (1404490 vs. really 1404491)&lt;br /&gt;
 Auto-correcting.&lt;br /&gt;
Starting verification pass.&lt;br /&gt;
Checking for unused clusters.&lt;br /&gt;
Leaving filesystem unchanged.&amp;lt;/pre&amp;gt;&lt;br /&gt;
| Useless null-based-read&lt;br /&gt;
| None&lt;br /&gt;
| [[9.6.0-24|9.6.0-X]]&lt;br /&gt;
| July 8-9, 2015&lt;br /&gt;
| &lt;br /&gt;
| [[User:Yellows8|Yellows8]]&lt;br /&gt;
|-&lt;br /&gt;
| RSA signature padding checks&lt;br /&gt;
| The TWL_FIRM RSA sig padding check code used for all TWL RSA sig-checks has issues, see [[FIRM|here]].&lt;br /&gt;
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&#039;t really a problem here because there&#039;s proper padding check code which is executed prior to this.&lt;br /&gt;
| &lt;br /&gt;
| None&lt;br /&gt;
| [[9.5.0-22|9.5.0-X]]&lt;br /&gt;
| March 2015&lt;br /&gt;
| &lt;br /&gt;
| [[User:Yellows8|Yellows8]]&lt;br /&gt;
|-&lt;br /&gt;
| [[AMPXI:ValidateDSiWareSectionMAC]] [[AES_Registers|AES]] keyslot reuse&lt;br /&gt;
| When the input DSiWare section index is higher than &amp;lt;max number of DSiWare sections supported by this FIRM&amp;gt;, 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 &amp;gt;=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&#039;s unknown whether a timing attack would work with this.&lt;br /&gt;
This is basically a different form of the pxips9 keyslot vuln, except with AESMAC etc.&lt;br /&gt;
| See description.&lt;br /&gt;
| None&lt;br /&gt;
| [[10.2.0-28|10.2.0-X]]&lt;br /&gt;
| March 15, 2015&lt;br /&gt;
| December 29, 2015&lt;br /&gt;
| [[User:Yellows8|Yellows8]]&lt;br /&gt;
|-&lt;br /&gt;
| pxips9 [[AES_Registers|AES]] keyslot reuse&lt;br /&gt;
| 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 &amp;lt;=10.1.0-X(see 32c3 3ds talk).&lt;br /&gt;
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&#039;t return any errors, Process9 will just continue to do crypto with whatever AES keyslot was selected before the PS command was sent.&lt;br /&gt;
| Reusing the previously used keyslot, for crypto with PS.&lt;br /&gt;
| None&lt;br /&gt;
| [[10.2.0-28|10.2.0-X]]&lt;br /&gt;
| Roughly the same time(same day?) as firmlaunch-hax.&lt;br /&gt;
| December 29, 2015&lt;br /&gt;
| [[User:Yellows8|Yellows8]]&lt;br /&gt;
|-&lt;br /&gt;
| firmlaunch-hax: FIRM header ToCToU&lt;br /&gt;
| This can&#039;t be exploited from ARM11 userland.&lt;br /&gt;
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&#039;t expect &amp;quot;anything&amp;quot; besides the ARM9 to access this data.&lt;br /&gt;
With [[9.5.0-22]] the address of this FIRM header was changed from a FCRAM address, to ARM9-only address 0x01fffc00.&lt;br /&gt;
| ARM9 code execution&lt;br /&gt;
| [[9.5.0-22]]&lt;br /&gt;
| &lt;br /&gt;
| 2012, 3 days after [[User:Yellows8|Yellows8]] started Process9 code RE.&lt;br /&gt;
| &lt;br /&gt;
| [[User:Yellows8|Yellows8]]&lt;br /&gt;
|-&lt;br /&gt;
| Uninitialized data output for (PXI) command replies&lt;br /&gt;
| 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.&lt;br /&gt;
Certain ARM11 service commands have this same issue as well.&lt;br /&gt;
| &lt;br /&gt;
| None&lt;br /&gt;
| [[9.3.0-21|9.3.0-X]]&lt;br /&gt;
| ?&lt;br /&gt;
| &lt;br /&gt;
| [[User:Yellows8|Yellows8]]&lt;br /&gt;
|-&lt;br /&gt;
| [[Filesystem_services_PXI|FSPXI]] OpenArchive SD permissions&lt;br /&gt;
| Process9 does not use the exheader ARM9 access-mount permission flag for SD at all.&lt;br /&gt;
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.&lt;br /&gt;
| &lt;br /&gt;
| None&lt;br /&gt;
| [[9.3.0-21|9.3.0-X]]&lt;br /&gt;
| 2012&lt;br /&gt;
| &lt;br /&gt;
| [[User:Yellows8|Yellows8]]&lt;br /&gt;
|-&lt;br /&gt;
| [[AMPXI:ExportDSiWare]] export path&lt;br /&gt;
| 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 &amp;quot;&amp;lt;mountpoint&amp;gt;:/&amp;lt;path&amp;gt;&amp;quot;.&lt;br /&gt;
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.&lt;br /&gt;
| Exporting of DSiWare to arbitrary Process9 file-paths, such as &amp;quot;nand:/&amp;lt;path&amp;gt;&amp;quot; etc. This isn&#039;t really useful since the data which gets written can&#039;t be controlled.&lt;br /&gt;
| None&lt;br /&gt;
| [[9.5.0-22]]&lt;br /&gt;
| April 2013&lt;br /&gt;
| &lt;br /&gt;
| [[User:Yellows8|Yellows8]]&lt;br /&gt;
|-&lt;br /&gt;
| [[DSiWare_Exports]] [[CTCert]] verification&lt;br /&gt;
| 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&#039;s still not(?) fixed.&lt;br /&gt;
On 3DS however this is rather useless, due to the entire DSiWare .bin being encrypted with the console-unique movable.sed keyY.&lt;br /&gt;
| 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.&lt;br /&gt;
| Unknown, probably none.&lt;br /&gt;
| ?&lt;br /&gt;
| April 2013&lt;br /&gt;
| &lt;br /&gt;
| [[User:Yellows8|Yellows8]]&lt;br /&gt;
|-&lt;br /&gt;
| [[Gamecard_Services_PXI]] unchecked REG_CTRCARDCNT transfer-size&lt;br /&gt;
| 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&#039;t checked, thus out-of-bounds reads could be triggered(which is rather useless in this case).&lt;br /&gt;
| Out-of-bounds read for a value which gets written to a register.&lt;br /&gt;
| [[5.0.0-11|5.0.0-X]]&lt;br /&gt;
| &lt;br /&gt;
| 2013?&lt;br /&gt;
| &lt;br /&gt;
| [[User:Yellows8|Yellows8]]&lt;br /&gt;
|-&lt;br /&gt;
| [[PXI_Registers|PXI]] cmdbuf buffer overrun&lt;br /&gt;
| The Process9 code responsible [[PXI_Registers|PXI]] communications didn&#039;t verify the size of the incoming command before writing it to a C++ member variable. &lt;br /&gt;
| Probably ARM9 code execution&lt;br /&gt;
| [[5.0.0-11|5.0.0-11]]&lt;br /&gt;
| &lt;br /&gt;
| March 2015, original timeframe if any unknown&lt;br /&gt;
| &lt;br /&gt;
| [[User:Plutooo|plutoo]]/[[User:Yellows8|Yellows8]]/maybe others(?)&lt;br /&gt;
|-&lt;br /&gt;
| [[Application_Manager_Services_PXI|PXIAM]] command 0x003D0108(See also [[Application_Manager_Services|this]])&lt;br /&gt;
| 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 &amp;lt;=0x2800.&lt;br /&gt;
| ARM9 code execution&lt;br /&gt;
| [[5.0.0-11|5.0.0-X]]&lt;br /&gt;
| &lt;br /&gt;
| May 2013&lt;br /&gt;
| &lt;br /&gt;
| [[User:Yellows8|Yellows8]]&lt;br /&gt;
|-&lt;br /&gt;
| [[Process_Services_PXI|PS RSA]] commands buffer overflows&lt;br /&gt;
| pxips9 cmd1(not accessible via ps:ps) and VerifyRsaSha256: unchecked copy to a buffer in Process9&#039;s .bss, from the input FCRAM buffer. The buffer is located before the pxi cmdhandler threads&#039; stacks. SignRsaSha256 also has a buf overflow, but this isn&#039;t exploitable.&lt;br /&gt;
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]].&lt;br /&gt;
| ARM9 code execution&lt;br /&gt;
| [[5.0.0-11|5.0.0-X]]&lt;br /&gt;
| &lt;br /&gt;
| 2012&lt;br /&gt;
| &lt;br /&gt;
| [[User:Yellows8|Yellows8]]&lt;br /&gt;
|-&lt;br /&gt;
| [[PXI_Registers|PXI]] pxi_id bad check&lt;br /&gt;
| The Process9 code responsible for [[PXI_Registers|PXI]] communications read pxi_id as a signed char. There were two flaws:&lt;br /&gt;
* They used it as index to a lookup-table without checking the value at all.&lt;br /&gt;
* Another function verified that pxi_id &amp;lt; 7, allowing negative values to pass the check. This would also cause an out-of-range table-lookup.&lt;br /&gt;
| Maybe ARM9 code execution&lt;br /&gt;
| [[3.0.0-5|3.0.0-5]]&lt;br /&gt;
|&lt;br /&gt;
| March 2015, originally 2012 for the first issue at least&lt;br /&gt;
| &lt;br /&gt;
| [[User:Plutooo|plutoo]], [[User:Yellows8|Yellows8]], maybe others(?)&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
=== Kernel9 ===&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot; border=&amp;quot;1&amp;quot;&lt;br /&gt;
|-&lt;br /&gt;
!  Summary&lt;br /&gt;
!  Description&lt;br /&gt;
!  Successful exploitation result&lt;br /&gt;
!  Fixed in [[FIRM]] system version&lt;br /&gt;
!  Last [[FIRM]] system version this flaw was checked for&lt;br /&gt;
!  Timeframe this was discovered&lt;br /&gt;
!  Discovered by&lt;br /&gt;
|-&lt;br /&gt;
| [[CONFIG Registers#CFG_SYSPROT9|CFG_SYSPROT9]] bit1 not set by Kernel9&lt;br /&gt;
| 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&#039;s never locked, you can dump it once you get ARM9 code execution. See [[OTP Registers|here]] regarding the data stored there.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
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. This was performed by downgrading to a vulnerable system version. By accounting for differences in CTR-NAND crypto (see partition encryption types [[Flash_Filesystem#NAND_structure|here]]), it is possible to boot a New3DS using Old3DS firmware 1.0-2.x, and retrieve the required OTP data using this flaw.&lt;br /&gt;
| Dumping of the [[OTP Registers|OTP]] area&lt;br /&gt;
| [[3.0.0-5|3.0.0-X]]&lt;br /&gt;
|&lt;br /&gt;
| February 2015&lt;br /&gt;
| [[User:Plutooo|plutoo]], Normmatt independently&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
== ARM11 software ==&lt;br /&gt;
=== Kernel11 ===&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot; border=&amp;quot;1&amp;quot;&lt;br /&gt;
|-&lt;br /&gt;
!  Summary&lt;br /&gt;
!  Description&lt;br /&gt;
!  Successful exploitation result&lt;br /&gt;
!  Fixed in [[FIRM]] system version&lt;br /&gt;
!  Last [[FIRM]] system version this flaw was checked for&lt;br /&gt;
!  Timeframe this was discovered&lt;br /&gt;
!  Discovered by&lt;br /&gt;
|-&lt;br /&gt;
|  [[SVC]] table too small&lt;br /&gt;
|  The table of function pointers for SVC&#039;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.&lt;br /&gt;
&lt;br /&gt;
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&#039;t mapped as executable.&lt;br /&gt;
| &lt;br /&gt;
|  None&lt;br /&gt;
| [[10.2.0-28|10.2.0-X]]&lt;br /&gt;
| 2012&lt;br /&gt;
| Everyone&lt;br /&gt;
|-&lt;br /&gt;
|  [[SVC|svcBackdoor (0x7B)]]&lt;br /&gt;
|  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) requires patching the kernel .text or modifying SVC-access-control.&lt;br /&gt;
| See description&lt;br /&gt;
|  None&lt;br /&gt;
| [[10.2.0-28|10.2.0-X]]&lt;br /&gt;
|&lt;br /&gt;
| Everyone&lt;br /&gt;
|-&lt;br /&gt;
| [[Memory_layout#ARM11_Detailed_virtual_memory_map|0xEFF00000]] / 0xDFF00000 ARM11 kernel virtual-memory&lt;br /&gt;
| 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.&lt;br /&gt;
| &lt;br /&gt;
| None&lt;br /&gt;
| [[10.2.0-28|10.2.0-X]]&lt;br /&gt;
| &lt;br /&gt;
| &lt;br /&gt;
|-&lt;br /&gt;
| Memchunkhax2&lt;br /&gt;
| &lt;br /&gt;
| ARM11 kernel code execution&lt;br /&gt;
| [[10.4.0-29|10.4.0-X]] (partially)&lt;br /&gt;
| [[10.4.0-29|10.4.0-X]]&lt;br /&gt;
|&lt;br /&gt;
| derrek&lt;br /&gt;
|-&lt;br /&gt;
|  AffinityMask/processorid validation&lt;br /&gt;
|  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.&lt;br /&gt;
The original code with the first 3 did the following: &lt;br /&gt;
* if(u32_processorcount &amp;gt; ~0x80000001)return 0xe0e01bfd;&lt;br /&gt;
* if(s32_processorcount &amp;gt; &amp;lt;total_cores&amp;gt;)return 0xd8e007fd;&lt;br /&gt;
The following code replaced the above:&lt;br /&gt;
* if(u32_processorcount &amp;gt;= &amp;lt;total_cores+1&amp;gt;)return 0xd8e007fd;&lt;br /&gt;
In theory the latter should catch everything that the former did, so it&#039;s unknown if this was really a security issue.&lt;br /&gt;
&lt;br /&gt;
The svcCreateThread changes with [[10.0.0-27|10.0.0-X]] definitely did fix a security issue.&lt;br /&gt;
* Original code: &amp;quot;if(s32_processorid &amp;gt; &amp;lt;total_cores&amp;gt;)return 0xd8e007fd;&amp;quot;&lt;br /&gt;
* New code: &amp;quot;if(s32_processorid &amp;gt;= &amp;lt;total_cores&amp;gt; || s32_processorid &amp;lt;= -4)return 0xd8e007fd;&amp;quot;&lt;br /&gt;
This fixed an off-by-one issue: if one would use processorid=total_cores, which isn&#039;t actually a valid value, svcCreateThread would accept that value on &amp;lt;[[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:&lt;br /&gt;
* Old3DS: Useless kernel-mode crash due to accessing unmapped memory.&lt;br /&gt;
* New3DS: uncontrolled data write into a kernel-mode L1 MMU-table. This isn&#039;t really useful: the data can&#039;t be controlled, and the data which gets overwritten is all-zero anyway(this isn&#039;t anywhere near MMU L1 entries for actually mapped memory).&lt;br /&gt;
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&#039;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)).&lt;br /&gt;
| Nothing useful&lt;br /&gt;
|  [[10.0.0-27|10.0.0-X]]&lt;br /&gt;
| [[10.0.0-27|10.0.0-X]]&lt;br /&gt;
| svcCreateThread issue: May 31, 2015. The rest: September 8, 2015, via v9.6-&amp;gt;v10.0 ARM11-kernel code-diff.&lt;br /&gt;
| [[User:Yellows8|Yellows8]]&lt;br /&gt;
|-&lt;br /&gt;
| memchunkhax&lt;br /&gt;
| 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.&lt;br /&gt;
&lt;br /&gt;
There are &#039;&#039;multiple&#039;&#039; 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.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
| When combined with other flaws: ARM11-kernelmode code execution&lt;br /&gt;
| [[9.3.0-21|9.3.0-21]]&lt;br /&gt;
| &lt;br /&gt;
| February 2014&lt;br /&gt;
| [[User:Yellows8|Yellows8]]&lt;br /&gt;
|-&lt;br /&gt;
| Multiple [[KLinkedListNode|KLinkedListNode]] SlabHeap use after free bugs&lt;br /&gt;
| The ARM11-kernel did access the &#039;key&#039; 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:&lt;br /&gt;
SlabHeap_free(KLinkedListNode);&lt;br /&gt;
KObject *obj = KLinkedListNode-&amp;gt;key;  // the object there might have changed!&lt;br /&gt;
This bug appeared all over the place.&lt;br /&gt;
| ARM11-kernelmode code exec maybe&lt;br /&gt;
| [[8.0.0-18|8.0.0-18]]&lt;br /&gt;
| &lt;br /&gt;
| April 2015&lt;br /&gt;
| [[User:Derrek|derrek]]&lt;br /&gt;
|-&lt;br /&gt;
| PXI [[RPC_Command_Structure|Command]] input/output buffer permissions&lt;br /&gt;
| Originally the ARM11-kernel didn&#039;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.&lt;br /&gt;
| &lt;br /&gt;
| [[6.0.0-11|6.0.0-11]]&lt;br /&gt;
| &lt;br /&gt;
| 2012&lt;br /&gt;
| [[User:Yellows8|Yellows8]]&lt;br /&gt;
|-&lt;br /&gt;
| [[SVC|svcStartInterProcessDma]]&lt;br /&gt;
| For svcStartInterProcessDma, the kernel code had the following flaws:&lt;br /&gt;
&lt;br /&gt;
* 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.&lt;br /&gt;
&lt;br /&gt;
* Integer overflows for srcaddr+size and dstaddr+size are now checked(with [[6.0.0-11]]), which were not checked before.&lt;br /&gt;
&lt;br /&gt;
* 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 &amp;gt;=0x20000000 would result in the kernel reading from the process L1 MMU table, beyond the memory allocated for that MMU table(for vaddr-&amp;gt;physaddr conversion). &lt;br /&gt;
| &lt;br /&gt;
| [[6.0.0-11]]&lt;br /&gt;
| &lt;br /&gt;
| DmaConfig issue: unknown. The rest: 2014&lt;br /&gt;
| [[User:Plutooo|plutoo]], [[User:Yellows8|Yellows8]] independently&lt;br /&gt;
|-&lt;br /&gt;
| [[SVC|svcControlMemory]] Parameter checks&lt;br /&gt;
| For svcControlMemory the parameter check had these two flaws:&lt;br /&gt;
&lt;br /&gt;
* 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&#039;t actually use the input address for LINEAR memory-mapping at all besides the range-checks, so this isn&#039;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.&lt;br /&gt;
&lt;br /&gt;
* Integer overflows on (addr0+size) are now checked that previously weren&#039;t (this also applies to most other address checks elsewhere in the kernel).&lt;br /&gt;
&lt;br /&gt;
| &lt;br /&gt;
| [[5.0.0-11]]&lt;br /&gt;
| &lt;br /&gt;
|&lt;br /&gt;
| [[User:Plutooo|plutoo]]&lt;br /&gt;
|-&lt;br /&gt;
| [[RPC_Command_Structure|Command]] request/response buffer overflow&lt;br /&gt;
| 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.&lt;br /&gt;
&lt;br /&gt;
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 &amp;lt;nowiki&amp;gt;((size&amp;lt;&amp;lt;14) | 2)&amp;lt;/nowiki&amp;gt; to write arbitrary memory to any RW userland memory in the destination process.&lt;br /&gt;
| &lt;br /&gt;
| [[5.0.0-11]]&lt;br /&gt;
| &lt;br /&gt;
| v4.1 FIRM -&amp;gt; v5.0 code diff&lt;br /&gt;
| [[User:Yellows8|Yellows8]]&lt;br /&gt;
|-&lt;br /&gt;
| [[SVC|SVC stack allocation overflows]]&lt;br /&gt;
| &lt;br /&gt;
* 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. &lt;br /&gt;
* The alignment (size+7)&amp;amp;~7 calculation before allocation was not checked for integer overflow.&lt;br /&gt;
&lt;br /&gt;
This might allow for ARM11 kernel code-execution.&lt;br /&gt;
&lt;br /&gt;
(Applies to svcSetResourceLimitValues, svcGetThreadList, svcGetProcessList, svcReplyAndReceive, svcWaitSynchronizationN.)&lt;br /&gt;
| &lt;br /&gt;
| [[5.0.0-11]]&lt;br /&gt;
| &lt;br /&gt;
| v4.1 FIRM -&amp;gt; v5.0 code diff&lt;br /&gt;
| [[User:Plutooo|plutoo]], [[User:Yellows8|Yellows8]] complementary&lt;br /&gt;
|-&lt;br /&gt;
| [[SVC|svcControlMemory]] MemoryOperation MAP memory-permissions&lt;br /&gt;
| 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&#039;t check memory permissions for addr1. Therefore .text as addr1 could be mapped elsewhere as RW- memory, which allowed ARM11 userland code-execution.&lt;br /&gt;
| &lt;br /&gt;
| [[4.1.0-8]]&lt;br /&gt;
| &lt;br /&gt;
| 2012&lt;br /&gt;
| [[User:Yellows8|Yellows8]]&lt;br /&gt;
|-&lt;br /&gt;
| [[RPC_Command_Structure|Command]] input/output buffer permissions&lt;br /&gt;
| Originally the ARM11 kernel didn&#039;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&#039;t have the required memory permissions. For example, this allowed a FSUSER file-read to .text, which therefore allowed ARM11-userland code execution.&lt;br /&gt;
| &lt;br /&gt;
| [[4.0.0-7]]&lt;br /&gt;
| &lt;br /&gt;
| 2012&lt;br /&gt;
| [[User:Yellows8|Yellows8]]&lt;br /&gt;
|-&lt;br /&gt;
| [[SVC|svcReadProcessMemory/svcWriteProcessMemory memory]] permissions&lt;br /&gt;
| 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.&lt;br /&gt;
| &lt;br /&gt;
| [[4.0.0-7]]&lt;br /&gt;
| &lt;br /&gt;
| 2012?&lt;br /&gt;
| [[User:Yellows8|Yellows8]]&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
=== [[FIRM]] Sysmodules ===&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot; border=&amp;quot;1&amp;quot;&lt;br /&gt;
|-&lt;br /&gt;
!  Summary&lt;br /&gt;
!  Description&lt;br /&gt;
!  Successful exploitation result&lt;br /&gt;
!  Fixed in [[FIRM]] system version&lt;br /&gt;
!  Last [[FIRM]] system version this flaw was checked for&lt;br /&gt;
!  Timeframe this was discovered&lt;br /&gt;
!  Discovered by&lt;br /&gt;
|-&lt;br /&gt;
| [[Services|&amp;quot;srv:pm&amp;quot;]] process registration&lt;br /&gt;
| Originally any process had access to the port &amp;quot;srv:pm&amp;quot;. The PID&#039;s used for the (un)registration commands are not checked either. This allowed any process to re-register itself with &amp;quot;srv:pm&amp;quot;, and therefore allowed the process to give itself access to any service, bypassing the exheader service-access-control list.&lt;br /&gt;
&lt;br /&gt;
This was fixed in [[7.0.0-13]]: starting with [[7.0.0-13]] &amp;quot;srv:pm&amp;quot; is now a service instead of a globally accessible port. Only processes with PID&#039;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 &amp;quot;srv:pm&amp;quot; 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.&lt;br /&gt;
&lt;br /&gt;
This flaw was needed for exploiting the &amp;lt;=v4.x Process9 PXI vulnerabilities from ARM11 userland ROP, since most applications don&#039;t have access to those service(s).&lt;br /&gt;
| Access to arbitrary services&lt;br /&gt;
| [[7.0.0-13]]&lt;br /&gt;
| &lt;br /&gt;
| 2012&lt;br /&gt;
| [[User:Yellows8|Yellows8]]&lt;br /&gt;
|-&lt;br /&gt;
| FSDIR null-deref&lt;br /&gt;
| [[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&#039;s just a null-deref.&lt;br /&gt;
| &lt;br /&gt;
| None&lt;br /&gt;
| [[9.6.0-24|9.6.0-X]]&lt;br /&gt;
| May 19(?)-20, 2015&lt;br /&gt;
| [[User:Yellows8|Yellows8]]&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
=== Standalone Sysmodules ===&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot; border=&amp;quot;1&amp;quot;&lt;br /&gt;
|-&lt;br /&gt;
!  Summary&lt;br /&gt;
!  Description&lt;br /&gt;
!  Successful exploitation result&lt;br /&gt;
!  Fixed in system-module system-version&lt;br /&gt;
!  Last system-module system-version this flaw was checked for&lt;br /&gt;
!  Timeframe this was discovered&lt;br /&gt;
!  Timeframe this was added to wiki&lt;br /&gt;
!  Discovered by&lt;br /&gt;
|-&lt;br /&gt;
| [[IR_Services|IR]]: Stack buffer overflow with custom hardware&lt;br /&gt;
| 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.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
| ROP under IR sysmodule.&lt;br /&gt;
| [[10.6.0-31|10.6.0-31]]&lt;br /&gt;
| &lt;br /&gt;
| February 23, 2016 (Unknown if it was noticed before then)&lt;br /&gt;
| February 23, 2016&lt;br /&gt;
| [[User:Yellows8|Yellows8]]&lt;br /&gt;
|-&lt;br /&gt;
| [[NIM_Services|NIM]]: Downloading old title-versions from eShop&lt;br /&gt;
| 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 &#039;&#039;if&#039;&#039; it&#039;s still available from CDN.&lt;br /&gt;
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).&lt;br /&gt;
&lt;br /&gt;
Originally this was tested with a debugging-system via modded-FIRM, eventually smea implemented it in HANS for the 32c3 release.&lt;br /&gt;
| Downloading old title-versions from eShop&lt;br /&gt;
| None&lt;br /&gt;
| [[10.0.0-27|10.0.0-X]]&lt;br /&gt;
| October 24, 2015 (Unknown when exactly the first eShop title downgrade was actually tested, maybe November)&lt;br /&gt;
| January 7, 2016 (Same day Ironfall v1.0 was removed from CDN via the main-CXI files)&lt;br /&gt;
| [[User:Yellows8|Yellows8]]&lt;br /&gt;
|-&lt;br /&gt;
| [[SPI_Services|SPI]] service out-of-bounds write&lt;br /&gt;
| cmd1 has out-of-bounds write allowing overwrite of some static variables in .data.&lt;br /&gt;
| &lt;br /&gt;
| None&lt;br /&gt;
| [[9.5.0-22]]&lt;br /&gt;
| March 2015&lt;br /&gt;
| &lt;br /&gt;
| [[User:Plutooo|plutoo]]&lt;br /&gt;
|-&lt;br /&gt;
| [[NFC_Services|NFC]] module service command buf-overflows&lt;br /&gt;
| NFC module copies data with certain commands, from command input buffers to stack without checking the size. These commands include the following, it&#039;s unknown if there&#039;s more commands with similar issues: &amp;quot;nfc:dev&amp;quot; &amp;lt;0x000C....&amp;gt; and &amp;quot;nfc:s&amp;quot; &amp;lt;0x0037....&amp;gt;.&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
There&#039;s no known retail titles which have access to either of these services.&lt;br /&gt;
| ROP under NFC module.&lt;br /&gt;
| New3DS: None&lt;br /&gt;
| New3DS: [[9.5.0-22]]&lt;br /&gt;
| December 2014?&lt;br /&gt;
| &lt;br /&gt;
| [[User:Yellows8|Yellows8]]&lt;br /&gt;
|-&lt;br /&gt;
| [[News_Services|NEWSS]] service command notificationID validation failure&lt;br /&gt;
| This module does not validate the input notificationID for &amp;lt;nowiki&amp;gt;&amp;quot;news:s&amp;quot;&amp;lt;/nowiki&amp;gt; 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).&lt;br /&gt;
| ROP under news module.&lt;br /&gt;
| None&lt;br /&gt;
| [[9.7.0-25|9.7.0-X]]&lt;br /&gt;
| December 2014&lt;br /&gt;
| &lt;br /&gt;
| [[User:Yellows8|Yellows8]]&lt;br /&gt;
|-&lt;br /&gt;
| [[NWMUDS:DecryptBeaconData]] heap buffer overflow&lt;br /&gt;
| input_size = 0x1E * &amp;lt;value the u8 from input_[[NWM_Services|networkstruct]]+0x1D&amp;gt;. Then input_tag0 is copied to a heap buffer. When input_size is larger than 0xFA-bytes, it will then copy input_tag1 to &amp;lt;end_address_of_previous_outbuf&amp;gt;, with size=input_size-0xFA.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
There&#039;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&#039;t be controlled it seems(with just broadcasting a beacon at least). It&#039;s unknown whether this could be exploited from just using NWMUDS service-cmd(s) directly.&lt;br /&gt;
| 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.&lt;br /&gt;
| None&lt;br /&gt;
| [[9.0.0-20]]&lt;br /&gt;
| ~September 23, 2014(see the [[NWMUDS:DecryptBeaconData]] page history)&lt;br /&gt;
| August 3, 2015&lt;br /&gt;
| [[User:Yellows8|Yellows8]]&lt;br /&gt;
|-&lt;br /&gt;
| [[HID_Services|HID]] module shared-mem&lt;br /&gt;
| 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.&lt;br /&gt;
| ROP under HID module, but this is *very* unlikely to be exploitable since the data written is HID data.&lt;br /&gt;
| None&lt;br /&gt;
| [[9.3.0-21]]&lt;br /&gt;
| 2014?&lt;br /&gt;
| &lt;br /&gt;
| [[User:Yellows8|Yellows8]]&lt;br /&gt;
|-&lt;br /&gt;
| gspwn&lt;br /&gt;
| 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&#039;re running under, and gain real code-execution from a ROP-chain. Normally applets&#039; .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).&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
| User-mode code execution.&lt;br /&gt;
| None&lt;br /&gt;
| [[9.6.0-24|9.6.0-X]]&lt;br /&gt;
| Early 2014&lt;br /&gt;
| &lt;br /&gt;
| smea, [[User:Yellows8|Yellows8]]/others before then&lt;br /&gt;
|-&lt;br /&gt;
| rohax&lt;br /&gt;
| 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.&lt;br /&gt;
&lt;br /&gt;
This was fixed after [[ninjhax]] release by adding checks on [[CRO0]]-based pointers before writing to them.&lt;br /&gt;
| Memory-mapping syscalls.&lt;br /&gt;
| [[9.3.0-21]]&lt;br /&gt;
| [[9.4.0-21]]&lt;br /&gt;
| &lt;br /&gt;
| &lt;br /&gt;
| smea, [[User:Plutooo|plutoo]] joint effort&lt;br /&gt;
|-&lt;br /&gt;
| Region free&lt;br /&gt;
| Only [[Home Menu]] itself checks gamecards&#039; 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.&lt;br /&gt;
This essentially means launching the gamecard with the [[NS_and_APT_Services|&amp;quot;ns:s&amp;quot;]] 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]].&lt;br /&gt;
| Launching gamecards from any region + bypassing Home Menu gamecard-sysupdate installation&lt;br /&gt;
| None&lt;br /&gt;
| Last tested with [[10.1.0-27|10.1.0-X]].&lt;br /&gt;
| June(?) 2014&lt;br /&gt;
| &lt;br /&gt;
| [[User:Yellows8|Yellows8]]&lt;br /&gt;
|-&lt;br /&gt;
| [[NWM_Services|NWM]] service-cmd state null-ptr deref&lt;br /&gt;
| 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.&lt;br /&gt;
It&#039;s unknown whether any NWM services besides NWMUDS have this issue.&lt;br /&gt;
| This is rather useless since it&#039;s only a crash caused by a state ptr based at 0x0.&lt;br /&gt;
| None&lt;br /&gt;
| [[9.0.0-20]]&lt;br /&gt;
| 2013?&lt;br /&gt;
| &lt;br /&gt;
| [[User:Yellows8|Yellows8]]&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
=== General/CTRSDK ===&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot; border=&amp;quot;1&amp;quot;&lt;br /&gt;
|-&lt;br /&gt;
!  Summary&lt;br /&gt;
!  Description&lt;br /&gt;
!  Successful exploitation result&lt;br /&gt;
!  Fixed in version&lt;br /&gt;
!  Last version this flaw was checked for&lt;br /&gt;
!  Timeframe this was discovered&lt;br /&gt;
!  Discovered by&lt;br /&gt;
|-&lt;br /&gt;
| [[NWM_Services|UDS]] beacon additional-data buffer overflow&lt;br /&gt;
| 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.&lt;br /&gt;
This was discovered while doing code RE with an old dlp-module version. It&#039;s unknown in what specific CTRSDK version this was fixed, or even what system-version updated titles with a fixed version.&lt;br /&gt;
&lt;br /&gt;
It&#039;s unknown if there&#039;s any titles using a vulnerable CTRSDK version which are also exploitable with this(dlp module can&#039;t be exploited with this).&lt;br /&gt;
&lt;br /&gt;
The maximum number of bytes that can be written beyond the end of the outbuf is 0x37-bytes, with additionaldata_size=0xFF.&lt;br /&gt;
| Perhaps ROP, very difficult if possible with anything at all&lt;br /&gt;
| ?&lt;br /&gt;
| &lt;br /&gt;
| September(?) 2014&lt;br /&gt;
| [[User:Yellows8|Yellows8]]&lt;br /&gt;
|}&lt;/div&gt;</summary>
		<author><name>Motezazer</name></author>
	</entry>
	<entry>
		<id>https://www.3dbrew.org/w/index.php?title=3DS_System_Flaws&amp;diff=15435</id>
		<title>3DS System Flaws</title>
		<link rel="alternate" type="text/html" href="https://www.3dbrew.org/w/index.php?title=3DS_System_Flaws&amp;diff=15435"/>
		<updated>2016-01-19T18:37:08Z</updated>

		<summary type="html">&lt;p&gt;Motezazer: enhanced-arm9loaderhax CAN be fixed&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;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]].&lt;br /&gt;
&lt;br /&gt;
=Stale / Rejected Efforts=&lt;br /&gt;
* Neimod has been working on a RAM dumping setup for a little while now. He&#039;s de-soldered the 3DS&#039;s RAM chip and hooked it and the RAM pinouts on the 3DS&#039; 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.&lt;br /&gt;
&lt;br /&gt;
* Someone (who will remain unnamed) has released CFW and CIA installers, all of which is copied from the work of others, or copyrighted material.&lt;br /&gt;
&lt;br /&gt;
==Tips and info==&lt;br /&gt;
The 3DS uses the XN feature of the ARM11 processor. There&#039;s no official way from applications to enable executable permission for memory containing arbitrary unsigned code(there&#039;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.&lt;br /&gt;
&lt;br /&gt;
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).&lt;br /&gt;
&lt;br /&gt;
=System flaws=&lt;br /&gt;
== Hardware ==&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot; border=&amp;quot;1&amp;quot;&lt;br /&gt;
!  Summary&lt;br /&gt;
!  Description&lt;br /&gt;
!  Fixed with hardware model/revision&lt;br /&gt;
!  Newest hardware model/revision this flaw was checked for&lt;br /&gt;
!  Timeframe this was discovered&lt;br /&gt;
!  Discovered by&lt;br /&gt;
|-&lt;br /&gt;
| ARM9/ARM11 bootrom vectors point at unitialized RAM&lt;br /&gt;
| ARM9&#039;s and ARM11&#039;s exception vectors are hardcoded to point at the CPU&#039;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. &lt;br /&gt;
Since RAM isn&#039;t cleared on boot (see below), one can immediately start execution of their own code here to dump bootrom, OTP, etc.&lt;br /&gt;
The ARM9 bootrom does the following at reset:  reset vector branches to another instruction, then branches to bootrom+0x8000. Hence, there&#039;s no way to know for certain when exactly the ARM9 exception-vector data stored in memory gets initialized.&lt;br /&gt;
&lt;br /&gt;
This requires *very* *precise* timing for triggering the hardware fault: it&#039;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&#039;t).&lt;br /&gt;
| None: all available 3DS models at the time of writing have the exact same ARM9/ARM11 bootrom for the unprotected areas.&lt;br /&gt;
| New3DS&lt;br /&gt;
| End of February 2014&lt;br /&gt;
| [[User:Derrek|derrek]], WulfyStylez (May 2015) independently&lt;br /&gt;
|-&lt;br /&gt;
| Missing AES key clearing&lt;br /&gt;
| The hardware AES engine does not clear keys when doing a hard reset/reboot.&lt;br /&gt;
| None&lt;br /&gt;
| New3DS&lt;br /&gt;
| August 2014&lt;br /&gt;
| Mathieulh/Others&lt;br /&gt;
|-&lt;br /&gt;
| No RAM clearing on reboots&lt;br /&gt;
| On an MCU-triggered reboot all RAM including FCRAM/ARM9 memory/AXIWRAM/VRAM keeps its contents.&lt;br /&gt;
| None&lt;br /&gt;
| New3DS&lt;br /&gt;
| March 2014&lt;br /&gt;
| [[User:Derrek|derrek]]&lt;br /&gt;
|-&lt;br /&gt;
| 32bits of actual console-unique TWLNAND keydata&lt;br /&gt;
| 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&#039;s highest bit is always ORed. only 31 bits of the TWL console-unique keydata / TWL consoleID are actually console-unique.&lt;br /&gt;
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).&lt;br /&gt;
| None&lt;br /&gt;
| New3DS&lt;br /&gt;
| 2012?&lt;br /&gt;
| [[User:Yellows8|Yellows8]]&lt;br /&gt;
|-&lt;br /&gt;
| DSi / 3DS-TWL key-generator&lt;br /&gt;
| 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.&lt;br /&gt;
This applies to the keyX/keyY too.&lt;br /&gt;
&lt;br /&gt;
This attack does not work for the 3DS key-generator because keyslots 0-3 are only for TWL keys.&lt;br /&gt;
| None&lt;br /&gt;
| New3DS&lt;br /&gt;
| 2011&lt;br /&gt;
| [[User:Yellows8|Yellows8]]&lt;br /&gt;
|-&lt;br /&gt;
| 3DS key-generator&lt;br /&gt;
| 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.&lt;br /&gt;
&lt;br /&gt;
Several such pairs of matching normal-keys and KeyY values were found, leading to deducing the key-generator function.&lt;br /&gt;
| None&lt;br /&gt;
| New3DS&lt;br /&gt;
| February 2015&lt;br /&gt;
| [[User:Yellows8|Yellows8]], [[User:Plutooo|plutoo]]&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
== ARM9 software ==&lt;br /&gt;
=== arm9loader ===&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot; border=&amp;quot;1&amp;quot;&lt;br /&gt;
|-&lt;br /&gt;
!  Summary&lt;br /&gt;
!  Description&lt;br /&gt;
!  Successful exploitation result&lt;br /&gt;
!  Fixed in [[FIRM]] system version&lt;br /&gt;
!  Last [[FIRM]] system version this flaw was checked for&lt;br /&gt;
!  Timeframe this was discovered&lt;br /&gt;
!  Public disclosure timeframe&lt;br /&gt;
!  Discovered by&lt;br /&gt;
|-&lt;br /&gt;
| Uncleared OTP hash keydata in console-unique 0x11 key-generation&lt;br /&gt;
| 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.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
This can be performed by exploiting the &amp;quot;arm9loaderhax&amp;quot; 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 &amp;lt;[[3.0.0-6|3.0.0-X]].&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
| Derivation of all New3DS keys generated via the NAND keystore (0x1B &amp;quot;Secure4&amp;quot; etc.)&lt;br /&gt;
| None&lt;br /&gt;
| [[10.4.0-29|10.4.0-X]]&lt;br /&gt;
| ~April 2015, implemented in May 2015&lt;br /&gt;
| 13 January 2016&lt;br /&gt;
| [[User:WulfyStylez|WulfyStylez]], [[User:Dazzozo|Dazzozo]], [[User:Shinyquagsire23|shinyquagsire23]] (complimentary + implemented), [[User:Plutooo|plutoo]], Normmatt (discovered independently)&lt;br /&gt;
|-&lt;br /&gt;
| enhanced-arm9loaderhax&lt;br /&gt;
| See the 32c3 3ds talk.&lt;br /&gt;
Since this is a combination of a trick with the arm9-bootrom + arm9loaderhax and it is mandatory to manually write FIRM to the firm0/firm1 NAND partitions, this can&#039;t be completely fixed as long as one has the proper FIRM xorpads. However, if one doesn&#039;t have said FIRM xorpads, a FIRM update could prevent the obtention of useful xorpads to downgrade his FIRM. For that, the updated sections would need to start after the size of the latest vulnerable FIRM. The &amp;quot;hole&amp;quot; would be filled with random data generated on first boot. Thus, as we don&#039;t know the decrypted value, we can&#039;t generate the relevant xorpad without ARM9 access.&lt;br /&gt;
| arm9loaderhax which automatically occurs at hard-boot.&lt;br /&gt;
| See arm9loaderhax / description.&lt;br /&gt;
| See arm9loaderhax / description.&lt;br /&gt;
| Theorized around mid July, 2015. Later implemented+tested by [[User:Plutooo|plutoo]] and derrek.&lt;br /&gt;
| 32c3 3ds talk (December 27, 2015)&lt;br /&gt;
| [[User:Yellows8|Yellows8]]&lt;br /&gt;
|-&lt;br /&gt;
| Missing verification-block for the 9.6 keys (arm9loaderhax)&lt;br /&gt;
| 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.&lt;br /&gt;
&lt;br /&gt;
Writing an incorrect key to NAND will cause arm9loader to decrypt the ARM9 kernel as garbage and then jump to it.&lt;br /&gt;
&lt;br /&gt;
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&#039;ll find some garbage that jumps to your code.&lt;br /&gt;
&lt;br /&gt;
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. &lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
| Recovery of 6.x [[Savegames#6.0.0-11_Savegame_keyY|save key]]/7.x [[NCCH]] key&lt;br /&gt;
| None&lt;br /&gt;
| [[10.4.0-29|10.4.0-X]]&lt;br /&gt;
| March, 2015&lt;br /&gt;
| &lt;br /&gt;
| [[User:Plutooo|plutoo]]&lt;br /&gt;
|-&lt;br /&gt;
| Uncleared New3DS keyslot 0x11&lt;br /&gt;
| 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.&lt;br /&gt;
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 &amp;lt;=v9.5 New3DS keyXs which are generated by keyslot 0x11.&lt;br /&gt;
&lt;br /&gt;
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]].&lt;br /&gt;
| New3DS keyXs generation&lt;br /&gt;
| 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]].&lt;br /&gt;
| &lt;br /&gt;
| February 3, 2015 (one day after [[9.5.0-22|9.5.0-X]] release)&lt;br /&gt;
| &lt;br /&gt;
| [[User:Yellows8|Yellows8]]&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
=== Process9 ===&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot; border=&amp;quot;1&amp;quot;&lt;br /&gt;
|-&lt;br /&gt;
!  Summary&lt;br /&gt;
!  Description&lt;br /&gt;
!  Successful exploitation result&lt;br /&gt;
!  Fixed in [[FIRM]] system version&lt;br /&gt;
!  Last [[FIRM]] system version this flaw was checked for&lt;br /&gt;
!  Timeframe this was discovered&lt;br /&gt;
!  Public disclosure timeframe&lt;br /&gt;
!  Discovered by&lt;br /&gt;
|-&lt;br /&gt;
| Leak of normal-key matching a key-scrambler key&lt;br /&gt;
| 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 &amp;quot;fixed&amp;quot; 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.&lt;br /&gt;
&lt;br /&gt;
Nintendo&#039;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 &amp;quot;Hardware&amp;quot; above), the key scrambler function could be deduced.&lt;br /&gt;
| Deducing the keyX for keyslot 0x39 and the key scrambler algorithm&lt;br /&gt;
| New 3DS [[9.3.0-21|9.3.0-X]], sort of&lt;br /&gt;
| [[10.0.0-27|10.0.0-X]]&lt;br /&gt;
| Sometime in 2015 after the hardware key-generator was broken.&lt;br /&gt;
| 32c3 3ds talk (December 27, 2015)&lt;br /&gt;
| [[User:Yellows8|Yellows8]]&lt;br /&gt;
|-&lt;br /&gt;
| ntrcardhax&lt;br /&gt;
| &lt;br /&gt;
| ARM9 code execution&lt;br /&gt;
| None&lt;br /&gt;
| [[10.3.0-28|10.3.0-X]]&lt;br /&gt;
| March 2015&lt;br /&gt;
| 32c3 3ds talk (December 27, 2015)&lt;br /&gt;
| [[User:Plutooo|plutoo]]&lt;br /&gt;
|-&lt;br /&gt;
| Title downgrading via [[Application_Manager_Services|AM]]([[Application_Manager_Services_PXI|PXI]])&lt;br /&gt;
| 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.&lt;br /&gt;
&lt;br /&gt;
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&#039;t compare the input title-version with anything. Hence, titles can be downgraded this way.&lt;br /&gt;
| Bypassing title version check at installation, which then allows downgrading any title.&lt;br /&gt;
| None&lt;br /&gt;
| NATIVE_FIRM / AM-sysmodule [[10.0.0-27|10.0.0-X]]&lt;br /&gt;
| ?&lt;br /&gt;
| &lt;br /&gt;
| ?&lt;br /&gt;
|-&lt;br /&gt;
| FAT FS code null-deref&lt;br /&gt;
| 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&#039;t check for NULL which then triggers a read based at NULL.&lt;br /&gt;
&lt;br /&gt;
Sample &amp;quot;fsck.vfat -n -v -V &amp;lt;fat image backup&amp;gt;&amp;quot; output for the above crash:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;...&lt;br /&gt;
Starting check/repair pass.&lt;br /&gt;
&amp;lt;FilePath0&amp;gt; and&lt;br /&gt;
&amp;lt;FilePath1&amp;gt;&lt;br /&gt;
 share clusters.&lt;br /&gt;
 Truncating second to 3375104 bytes.&lt;br /&gt;
&amp;lt;FilePath1&amp;gt;&lt;br /&gt;
 File size is 2787392 bytes, cluster chain length is 16384 bytes.&lt;br /&gt;
 Truncating file to 16384 bytes.&lt;br /&gt;
Checking for unused clusters.&lt;br /&gt;
Reclaimed 1 unused cluster (16384 bytes).&lt;br /&gt;
Checking free cluster summary.&lt;br /&gt;
Free cluster summary wrong (1404490 vs. really 1404491)&lt;br /&gt;
 Auto-correcting.&lt;br /&gt;
Starting verification pass.&lt;br /&gt;
Checking for unused clusters.&lt;br /&gt;
Leaving filesystem unchanged.&amp;lt;/pre&amp;gt;&lt;br /&gt;
| Useless null-based-read&lt;br /&gt;
| None&lt;br /&gt;
| [[9.6.0-24|9.6.0-X]]&lt;br /&gt;
| July 8-9, 2015&lt;br /&gt;
| &lt;br /&gt;
| [[User:Yellows8|Yellows8]]&lt;br /&gt;
|-&lt;br /&gt;
| RSA signature padding checks&lt;br /&gt;
| The TWL_FIRM RSA sig padding check code used for all TWL RSA sig-checks has issues, see [[FIRM|here]].&lt;br /&gt;
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&#039;t really a problem here because there&#039;s proper padding check code which is executed prior to this.&lt;br /&gt;
| &lt;br /&gt;
| None&lt;br /&gt;
| [[9.5.0-22|9.5.0-X]]&lt;br /&gt;
| March 2015&lt;br /&gt;
| &lt;br /&gt;
| [[User:Yellows8|Yellows8]]&lt;br /&gt;
|-&lt;br /&gt;
| [[AMPXI:ValidateDSiWareSectionMAC]] [[AES_Registers|AES]] keyslot reuse&lt;br /&gt;
| When the input DSiWare section index is higher than &amp;lt;max number of DSiWare sections supported by this FIRM&amp;gt;, 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 &amp;gt;=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&#039;s unknown whether a timing attack would work with this.&lt;br /&gt;
This is basically a different form of the pxips9 keyslot vuln, except with AESMAC etc.&lt;br /&gt;
| See description.&lt;br /&gt;
| None&lt;br /&gt;
| [[10.2.0-28|10.2.0-X]]&lt;br /&gt;
| March 15, 2015&lt;br /&gt;
| December 29, 2015&lt;br /&gt;
| [[User:Yellows8|Yellows8]]&lt;br /&gt;
|-&lt;br /&gt;
| pxips9 [[AES_Registers|AES]] keyslot reuse&lt;br /&gt;
| 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 &amp;lt;=10.1.0-X(see 32c3 3ds talk).&lt;br /&gt;
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&#039;t return any errors, Process9 will just continue to do crypto with whatever AES keyslot was selected before the PS command was sent.&lt;br /&gt;
| Reusing the previously used keyslot, for crypto with PS.&lt;br /&gt;
| None&lt;br /&gt;
| [[10.2.0-28|10.2.0-X]]&lt;br /&gt;
| Roughly the same time(same day?) as firmlaunch-hax.&lt;br /&gt;
| December 29, 2015&lt;br /&gt;
| [[User:Yellows8|Yellows8]]&lt;br /&gt;
|-&lt;br /&gt;
| firmlaunch-hax: FIRM header ToCToU&lt;br /&gt;
| This can&#039;t be exploited from ARM11 userland.&lt;br /&gt;
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&#039;t expect &amp;quot;anything&amp;quot; besides the ARM9 to access this data.&lt;br /&gt;
With [[9.5.0-22]] the address of this FIRM header was changed from a FCRAM address, to ARM9-only address 0x01fffc00.&lt;br /&gt;
| ARM9 code execution&lt;br /&gt;
| [[9.5.0-22]]&lt;br /&gt;
| &lt;br /&gt;
| 2012, 3 days after [[User:Yellows8|Yellows8]] started Process9 code RE.&lt;br /&gt;
| &lt;br /&gt;
| [[User:Yellows8|Yellows8]]&lt;br /&gt;
|-&lt;br /&gt;
| Uninitialized data output for (PXI) command replies&lt;br /&gt;
| 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.&lt;br /&gt;
Certain ARM11 service commands have this same issue as well.&lt;br /&gt;
| &lt;br /&gt;
| None&lt;br /&gt;
| [[9.3.0-21|9.3.0-X]]&lt;br /&gt;
| ?&lt;br /&gt;
| &lt;br /&gt;
| [[User:Yellows8|Yellows8]]&lt;br /&gt;
|-&lt;br /&gt;
| [[Filesystem_services_PXI|FSPXI]] OpenArchive SD permissions&lt;br /&gt;
| Process9 does not use the exheader ARM9 access-mount permission flag for SD at all.&lt;br /&gt;
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.&lt;br /&gt;
| &lt;br /&gt;
| None&lt;br /&gt;
| [[9.3.0-21|9.3.0-X]]&lt;br /&gt;
| 2012&lt;br /&gt;
| &lt;br /&gt;
| [[User:Yellows8|Yellows8]]&lt;br /&gt;
|-&lt;br /&gt;
| [[AMPXI:ExportDSiWare]] export path&lt;br /&gt;
| 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 &amp;quot;&amp;lt;mountpoint&amp;gt;:/&amp;lt;path&amp;gt;&amp;quot;.&lt;br /&gt;
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.&lt;br /&gt;
| Exporting of DSiWare to arbitrary Process9 file-paths, such as &amp;quot;nand:/&amp;lt;path&amp;gt;&amp;quot; etc. This isn&#039;t really useful since the data which gets written can&#039;t be controlled.&lt;br /&gt;
| None&lt;br /&gt;
| [[9.5.0-22]]&lt;br /&gt;
| April 2013&lt;br /&gt;
| &lt;br /&gt;
| [[User:Yellows8|Yellows8]]&lt;br /&gt;
|-&lt;br /&gt;
| [[DSiWare_Exports]] [[CTCert]] verification&lt;br /&gt;
| 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&#039;s still not(?) fixed.&lt;br /&gt;
On 3DS however this is rather useless, due to the entire DSiWare .bin being encrypted with the console-unique movable.sed keyY.&lt;br /&gt;
| 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.&lt;br /&gt;
| Unknown, probably none.&lt;br /&gt;
| ?&lt;br /&gt;
| April 2013&lt;br /&gt;
| &lt;br /&gt;
| [[User:Yellows8|Yellows8]]&lt;br /&gt;
|-&lt;br /&gt;
| [[Gamecard_Services_PXI]] unchecked REG_CTRCARDCNT transfer-size&lt;br /&gt;
| 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&#039;t checked, thus out-of-bounds reads could be triggered(which is rather useless in this case).&lt;br /&gt;
| Out-of-bounds read for a value which gets written to a register.&lt;br /&gt;
| [[5.0.0-11|5.0.0-X]]&lt;br /&gt;
| &lt;br /&gt;
| 2013?&lt;br /&gt;
| &lt;br /&gt;
| [[User:Yellows8|Yellows8]]&lt;br /&gt;
|-&lt;br /&gt;
| [[PXI_Registers|PXI]] cmdbuf buffer overrun&lt;br /&gt;
| The Process9 code responsible [[PXI_Registers|PXI]] communications didn&#039;t verify the size of the incoming command before writing it to a C++ member variable. &lt;br /&gt;
| Probably ARM9 code execution&lt;br /&gt;
| [[5.0.0-11|5.0.0-11]]&lt;br /&gt;
| &lt;br /&gt;
| March 2015, original timeframe if any unknown&lt;br /&gt;
| &lt;br /&gt;
| [[User:Plutooo|plutoo]]/[[User:Yellows8|Yellows8]]/maybe others(?)&lt;br /&gt;
|-&lt;br /&gt;
| [[Application_Manager_Services_PXI|PXIAM]] command 0x003D0108(See also [[Application_Manager_Services|this]])&lt;br /&gt;
| 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 &amp;lt;=0x2800.&lt;br /&gt;
| ARM9 code execution&lt;br /&gt;
| [[5.0.0-11|5.0.0-X]]&lt;br /&gt;
| &lt;br /&gt;
| May 2013&lt;br /&gt;
| &lt;br /&gt;
| [[User:Yellows8|Yellows8]]&lt;br /&gt;
|-&lt;br /&gt;
| [[Process_Services_PXI|PS RSA]] commands buffer overflows&lt;br /&gt;
| pxips9 cmd1(not accessible via ps:ps) and VerifyRsaSha256: unchecked copy to a buffer in Process9&#039;s .bss, from the input FCRAM buffer. The buffer is located before the pxi cmdhandler threads&#039; stacks. SignRsaSha256 also has a buf overflow, but this isn&#039;t exploitable.&lt;br /&gt;
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]].&lt;br /&gt;
| ARM9 code execution&lt;br /&gt;
| [[5.0.0-11|5.0.0-X]]&lt;br /&gt;
| &lt;br /&gt;
| 2012&lt;br /&gt;
| &lt;br /&gt;
| [[User:Yellows8|Yellows8]]&lt;br /&gt;
|-&lt;br /&gt;
| [[PXI_Registers|PXI]] pxi_id bad check&lt;br /&gt;
| The Process9 code responsible for [[PXI_Registers|PXI]] communications read pxi_id as a signed char. There were two flaws:&lt;br /&gt;
* They used it as index to a lookup-table without checking the value at all.&lt;br /&gt;
* Another function verified that pxi_id &amp;lt; 7, allowing negative values to pass the check. This would also cause an out-of-range table-lookup.&lt;br /&gt;
| Maybe ARM9 code execution&lt;br /&gt;
| [[3.0.0-5|3.0.0-5]]&lt;br /&gt;
|&lt;br /&gt;
| March 2015, originally 2012 for the first issue at least&lt;br /&gt;
| &lt;br /&gt;
| [[User:Plutooo|plutoo]], [[User:Yellows8|Yellows8]], maybe others(?)&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
=== Kernel9 ===&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot; border=&amp;quot;1&amp;quot;&lt;br /&gt;
|-&lt;br /&gt;
!  Summary&lt;br /&gt;
!  Description&lt;br /&gt;
!  Successful exploitation result&lt;br /&gt;
!  Fixed in [[FIRM]] system version&lt;br /&gt;
!  Last [[FIRM]] system version this flaw was checked for&lt;br /&gt;
!  Timeframe this was discovered&lt;br /&gt;
!  Discovered by&lt;br /&gt;
|-&lt;br /&gt;
| [[CONFIG Registers#CFG_SYSPROT9|CFG_SYSPROT9]] bit1 not set by Kernel9&lt;br /&gt;
| 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&#039;s never locked, you can dump it once you get ARM9 code execution. See [[OTP Registers|here]] regarding the data stored there.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
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. This was performed by downgrading to a vulnerable system version. By accounting for differences in CTR-NAND crypto (see partition encryption types [[Flash_Filesystem#NAND_structure|here]]), it is possible to boot a New3DS using Old3DS firmware 1.0-2.x, and retrieve the required OTP data using this flaw.&lt;br /&gt;
| Dumping of the [[OTP Registers|OTP]] area&lt;br /&gt;
| [[3.0.0-5|3.0.0-X]]&lt;br /&gt;
|&lt;br /&gt;
| February 2015&lt;br /&gt;
| [[User:Plutooo|plutoo]], Normmatt independently&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
== ARM11 software ==&lt;br /&gt;
=== Kernel11 ===&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot; border=&amp;quot;1&amp;quot;&lt;br /&gt;
|-&lt;br /&gt;
!  Summary&lt;br /&gt;
!  Description&lt;br /&gt;
!  Successful exploitation result&lt;br /&gt;
!  Fixed in [[FIRM]] system version&lt;br /&gt;
!  Last [[FIRM]] system version this flaw was checked for&lt;br /&gt;
!  Timeframe this was discovered&lt;br /&gt;
!  Discovered by&lt;br /&gt;
|-&lt;br /&gt;
|  [[SVC]] table too small&lt;br /&gt;
|  The table of function pointers for SVC&#039;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.&lt;br /&gt;
&lt;br /&gt;
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&#039;t mapped as executable.&lt;br /&gt;
| &lt;br /&gt;
|  None&lt;br /&gt;
| [[10.2.0-28|10.2.0-X]]&lt;br /&gt;
| 2012&lt;br /&gt;
| Everyone&lt;br /&gt;
|-&lt;br /&gt;
|  [[SVC|svcBackdoor (0x7B)]]&lt;br /&gt;
|  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) requires patching the kernel .text or modifying SVC-access-control.&lt;br /&gt;
| See description&lt;br /&gt;
|  None&lt;br /&gt;
| [[10.2.0-28|10.2.0-X]]&lt;br /&gt;
|&lt;br /&gt;
| Everyone&lt;br /&gt;
|-&lt;br /&gt;
| [[Memory_layout#ARM11_Detailed_virtual_memory_map|0xEFF00000]] / 0xDFF00000 ARM11 kernel virtual-memory&lt;br /&gt;
| 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.&lt;br /&gt;
| &lt;br /&gt;
| None&lt;br /&gt;
| [[10.2.0-28|10.2.0-X]]&lt;br /&gt;
| &lt;br /&gt;
| &lt;br /&gt;
|-&lt;br /&gt;
| Memchunkhax2&lt;br /&gt;
| &lt;br /&gt;
| ARM11 kernel code execution&lt;br /&gt;
| [[10.4.0-29|10.4.0-X]]&lt;br /&gt;
| [[10.4.0-29|10.4.0-X]]&lt;br /&gt;
|&lt;br /&gt;
| derrek&lt;br /&gt;
|-&lt;br /&gt;
|  AffinityMask/processorid validation&lt;br /&gt;
|  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.&lt;br /&gt;
The original code with the first 3 did the following: &lt;br /&gt;
* if(u32_processorcount &amp;gt; ~0x80000001)return 0xe0e01bfd;&lt;br /&gt;
* if(s32_processorcount &amp;gt; &amp;lt;total_cores&amp;gt;)return 0xd8e007fd;&lt;br /&gt;
The following code replaced the above:&lt;br /&gt;
* if(u32_processorcount &amp;gt;= &amp;lt;total_cores+1&amp;gt;)return 0xd8e007fd;&lt;br /&gt;
In theory the latter should catch everything that the former did, so it&#039;s unknown if this was really a security issue.&lt;br /&gt;
&lt;br /&gt;
The svcCreateThread changes with [[10.0.0-27|10.0.0-X]] definitely did fix a security issue.&lt;br /&gt;
* Original code: &amp;quot;if(s32_processorid &amp;gt; &amp;lt;total_cores&amp;gt;)return 0xd8e007fd;&amp;quot;&lt;br /&gt;
* New code: &amp;quot;if(s32_processorid &amp;gt;= &amp;lt;total_cores&amp;gt; || s32_processorid &amp;lt;= -4)return 0xd8e007fd;&amp;quot;&lt;br /&gt;
This fixed an off-by-one issue: if one would use processorid=total_cores, which isn&#039;t actually a valid value, svcCreateThread would accept that value on &amp;lt;[[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:&lt;br /&gt;
* Old3DS: Useless kernel-mode crash due to accessing unmapped memory.&lt;br /&gt;
* New3DS: uncontrolled data write into a kernel-mode L1 MMU-table. This isn&#039;t really useful: the data can&#039;t be controlled, and the data which gets overwritten is all-zero anyway(this isn&#039;t anywhere near MMU L1 entries for actually mapped memory).&lt;br /&gt;
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&#039;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)).&lt;br /&gt;
| Nothing useful&lt;br /&gt;
|  [[10.0.0-27|10.0.0-X]]&lt;br /&gt;
| [[10.0.0-27|10.0.0-X]]&lt;br /&gt;
| svcCreateThread issue: May 31, 2015. The rest: September 8, 2015, via v9.6-&amp;gt;v10.0 ARM11-kernel code-diff.&lt;br /&gt;
| [[User:Yellows8|Yellows8]]&lt;br /&gt;
|-&lt;br /&gt;
| memchunkhax&lt;br /&gt;
| 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.&lt;br /&gt;
&lt;br /&gt;
There are &#039;&#039;multiple&#039;&#039; 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.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
| When combined with other flaws: ARM11-kernelmode code execution&lt;br /&gt;
| [[9.3.0-21|9.3.0-21]]&lt;br /&gt;
| &lt;br /&gt;
| February 2014&lt;br /&gt;
| [[User:Yellows8|Yellows8]]&lt;br /&gt;
|-&lt;br /&gt;
| Multiple [[KLinkedListNode|KLinkedListNode]] SlabHeap use after free bugs&lt;br /&gt;
| The ARM11-kernel did access the &#039;key&#039; 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:&lt;br /&gt;
SlabHeap_free(KLinkedListNode);&lt;br /&gt;
KObject *obj = KLinkedListNode-&amp;gt;key;  // the object there might have changed!&lt;br /&gt;
This bug appeared all over the place.&lt;br /&gt;
| ARM11-kernelmode code exec maybe&lt;br /&gt;
| [[8.0.0-18|8.0.0-18]]&lt;br /&gt;
| &lt;br /&gt;
| April 2015&lt;br /&gt;
| [[User:Derrek|derrek]]&lt;br /&gt;
|-&lt;br /&gt;
| PXI [[RPC_Command_Structure|Command]] input/output buffer permissions&lt;br /&gt;
| Originally the ARM11-kernel didn&#039;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.&lt;br /&gt;
| &lt;br /&gt;
| [[6.0.0-11|6.0.0-11]]&lt;br /&gt;
| &lt;br /&gt;
| 2012&lt;br /&gt;
| [[User:Yellows8|Yellows8]]&lt;br /&gt;
|-&lt;br /&gt;
| [[SVC|svcStartInterProcessDma]]&lt;br /&gt;
| For svcStartInterProcessDma, the kernel code had the following flaws:&lt;br /&gt;
&lt;br /&gt;
* 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.&lt;br /&gt;
&lt;br /&gt;
* Integer overflows for srcaddr+size and dstaddr+size are now checked(with [[6.0.0-11]]), which were not checked before.&lt;br /&gt;
&lt;br /&gt;
* 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 &amp;gt;=0x20000000 would result in the kernel reading from the process L1 MMU table, beyond the memory allocated for that MMU table(for vaddr-&amp;gt;physaddr conversion). &lt;br /&gt;
| &lt;br /&gt;
| [[6.0.0-11]]&lt;br /&gt;
| &lt;br /&gt;
| DmaConfig issue: unknown. The rest: 2014&lt;br /&gt;
| [[User:Plutooo|plutoo]], [[User:Yellows8|Yellows8]] independently&lt;br /&gt;
|-&lt;br /&gt;
| [[SVC|svcControlMemory]] Parameter checks&lt;br /&gt;
| For svcControlMemory the parameter check had these two flaws:&lt;br /&gt;
&lt;br /&gt;
* 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&#039;t actually use the input address for LINEAR memory-mapping at all besides the range-checks, so this isn&#039;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.&lt;br /&gt;
&lt;br /&gt;
* Integer overflows on (addr0+size) are now checked that previously weren&#039;t (this also applies to most other address checks elsewhere in the kernel).&lt;br /&gt;
&lt;br /&gt;
| &lt;br /&gt;
| [[5.0.0-11]]&lt;br /&gt;
| &lt;br /&gt;
|&lt;br /&gt;
| [[User:Plutooo|plutoo]]&lt;br /&gt;
|-&lt;br /&gt;
| [[RPC_Command_Structure|Command]] request/response buffer overflow&lt;br /&gt;
| 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.&lt;br /&gt;
&lt;br /&gt;
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 &amp;lt;nowiki&amp;gt;((size&amp;lt;&amp;lt;14) | 2)&amp;lt;/nowiki&amp;gt; to write arbitrary memory to any RW userland memory in the destination process.&lt;br /&gt;
| &lt;br /&gt;
| [[5.0.0-11]]&lt;br /&gt;
| &lt;br /&gt;
| v4.1 FIRM -&amp;gt; v5.0 code diff&lt;br /&gt;
| [[User:Yellows8|Yellows8]]&lt;br /&gt;
|-&lt;br /&gt;
| [[SVC|SVC stack allocation overflows]]&lt;br /&gt;
| &lt;br /&gt;
* 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. &lt;br /&gt;
* The alignment (size+7)&amp;amp;~7 calculation before allocation was not checked for integer overflow.&lt;br /&gt;
&lt;br /&gt;
This might allow for ARM11 kernel code-execution.&lt;br /&gt;
&lt;br /&gt;
(Applies to svcSetResourceLimitValues, svcGetThreadList, svcGetProcessList, svcReplyAndReceive, svcWaitSynchronizationN.)&lt;br /&gt;
| &lt;br /&gt;
| [[5.0.0-11]]&lt;br /&gt;
| &lt;br /&gt;
| v4.1 FIRM -&amp;gt; v5.0 code diff&lt;br /&gt;
| [[User:Plutooo|plutoo]], [[User:Yellows8|Yellows8]] complementary&lt;br /&gt;
|-&lt;br /&gt;
| [[SVC|svcControlMemory]] MemoryOperation MAP memory-permissions&lt;br /&gt;
| 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&#039;t check memory permissions for addr1. Therefore .text as addr1 could be mapped elsewhere as RW- memory, which allowed ARM11 userland code-execution.&lt;br /&gt;
| &lt;br /&gt;
| [[4.1.0-8]]&lt;br /&gt;
| &lt;br /&gt;
| 2012&lt;br /&gt;
| [[User:Yellows8|Yellows8]]&lt;br /&gt;
|-&lt;br /&gt;
| [[RPC_Command_Structure|Command]] input/output buffer permissions&lt;br /&gt;
| Originally the ARM11 kernel didn&#039;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&#039;t have the required memory permissions. For example, this allowed a FSUSER file-read to .text, which therefore allowed ARM11-userland code execution.&lt;br /&gt;
| &lt;br /&gt;
| [[4.0.0-7]]&lt;br /&gt;
| &lt;br /&gt;
| 2012&lt;br /&gt;
| [[User:Yellows8|Yellows8]]&lt;br /&gt;
|-&lt;br /&gt;
| [[SVC|svcReadProcessMemory/svcWriteProcessMemory memory]] permissions&lt;br /&gt;
| 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.&lt;br /&gt;
| &lt;br /&gt;
| [[4.0.0-7]]&lt;br /&gt;
| &lt;br /&gt;
| 2012?&lt;br /&gt;
| [[User:Yellows8|Yellows8]]&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
=== [[FIRM]] Sysmodules ===&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot; border=&amp;quot;1&amp;quot;&lt;br /&gt;
|-&lt;br /&gt;
!  Summary&lt;br /&gt;
!  Description&lt;br /&gt;
!  Successful exploitation result&lt;br /&gt;
!  Fixed in [[FIRM]] system version&lt;br /&gt;
!  Last [[FIRM]] system version this flaw was checked for&lt;br /&gt;
!  Timeframe this was discovered&lt;br /&gt;
!  Discovered by&lt;br /&gt;
|-&lt;br /&gt;
| [[Services|&amp;quot;srv:pm&amp;quot;]] process registration&lt;br /&gt;
| Originally any process had access to the port &amp;quot;srv:pm&amp;quot;. The PID&#039;s used for the (un)registration commands are not checked either. This allowed any process to re-register itself with &amp;quot;srv:pm&amp;quot;, and therefore allowed the process to give itself access to any service, bypassing the exheader service-access-control list.&lt;br /&gt;
&lt;br /&gt;
This was fixed in [[7.0.0-13]]: starting with [[7.0.0-13]] &amp;quot;srv:pm&amp;quot; is now a service instead of a globally accessible port. Only processes with PID&#039;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 &amp;quot;srv:pm&amp;quot; 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.&lt;br /&gt;
&lt;br /&gt;
This flaw was needed for exploiting the &amp;lt;=v4.x Process9 PXI vulnerabilities from ARM11 userland ROP, since most applications don&#039;t have access to those service(s).&lt;br /&gt;
| Access to arbitrary services&lt;br /&gt;
| [[7.0.0-13]]&lt;br /&gt;
| &lt;br /&gt;
| 2012&lt;br /&gt;
| [[User:Yellows8|Yellows8]]&lt;br /&gt;
|-&lt;br /&gt;
| FSDIR null-deref&lt;br /&gt;
| [[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&#039;s just a null-deref.&lt;br /&gt;
| &lt;br /&gt;
| None&lt;br /&gt;
| [[9.6.0-24|9.6.0-X]]&lt;br /&gt;
| May 19(?)-20, 2015&lt;br /&gt;
| [[User:Yellows8|Yellows8]]&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
=== Standalone Sysmodules ===&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot; border=&amp;quot;1&amp;quot;&lt;br /&gt;
|-&lt;br /&gt;
!  Summary&lt;br /&gt;
!  Description&lt;br /&gt;
!  Successful exploitation result&lt;br /&gt;
!  Fixed in system-module system-version&lt;br /&gt;
!  Last system-module system-version this flaw was checked for&lt;br /&gt;
!  Timeframe this was discovered&lt;br /&gt;
!  Timeframe this was added to wiki&lt;br /&gt;
!  Discovered by&lt;br /&gt;
|-&lt;br /&gt;
| [[NIM_Services|NIM]]: Downloading old title-versions from eShop&lt;br /&gt;
| 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 &#039;&#039;if&#039;&#039; it&#039;s still available from CDN.&lt;br /&gt;
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).&lt;br /&gt;
&lt;br /&gt;
Originally this was tested with a debugging-system via modded-FIRM, eventually smea implemented it in HANS for the 32c3 release.&lt;br /&gt;
| Downloading old title-versions from eShop&lt;br /&gt;
| None&lt;br /&gt;
| [[10.0.0-27|10.0.0-X]]&lt;br /&gt;
| October 24, 2015 (Unknown when exactly the first eShop title downgrade was actually tested, maybe November)&lt;br /&gt;
| January 7, 2016 (Same day Ironfall v1.0 was removed from CDN via the main-CXI files)&lt;br /&gt;
| [[User:Yellows8|Yellows8]]&lt;br /&gt;
|-&lt;br /&gt;
| [[SPI_Services|SPI]] service out-of-bounds write&lt;br /&gt;
| cmd1 has out-of-bounds write allowing overwrite of some static variables in .data.&lt;br /&gt;
| &lt;br /&gt;
| None&lt;br /&gt;
| [[9.5.0-22]]&lt;br /&gt;
| March 2015&lt;br /&gt;
| &lt;br /&gt;
| [[User:Plutooo|plutoo]]&lt;br /&gt;
|-&lt;br /&gt;
| [[NFC_Services|NFC]] module service command buf-overflows&lt;br /&gt;
| NFC module copies data with certain commands, from command input buffers to stack without checking the size. These commands include the following, it&#039;s unknown if there&#039;s more commands with similar issues: &amp;quot;nfc:dev&amp;quot; &amp;lt;0x000C....&amp;gt; and &amp;quot;nfc:s&amp;quot; &amp;lt;0x0037....&amp;gt;.&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
There&#039;s no known retail titles which have access to either of these services.&lt;br /&gt;
| ROP under NFC module.&lt;br /&gt;
| New3DS: None&lt;br /&gt;
| New3DS: [[9.5.0-22]]&lt;br /&gt;
| December 2014?&lt;br /&gt;
| &lt;br /&gt;
| [[User:Yellows8|Yellows8]]&lt;br /&gt;
|-&lt;br /&gt;
| [[News_Services|NEWSS]] service command notificationID validation failure&lt;br /&gt;
| This module does not validate the input notificationID for &amp;lt;nowiki&amp;gt;&amp;quot;news:s&amp;quot;&amp;lt;/nowiki&amp;gt; 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).&lt;br /&gt;
| ROP under news module.&lt;br /&gt;
| None&lt;br /&gt;
| [[9.7.0-25|9.7.0-X]]&lt;br /&gt;
| December 2014&lt;br /&gt;
| &lt;br /&gt;
| [[User:Yellows8|Yellows8]]&lt;br /&gt;
|-&lt;br /&gt;
| [[NWMUDS:DecryptBeaconData]] heap buffer overflow&lt;br /&gt;
| input_size = 0x1E * &amp;lt;value the u8 from input_[[NWM_Services|networkstruct]]+0x1D&amp;gt;. Then input_tag0 is copied to a heap buffer. When input_size is larger than 0xFA-bytes, it will then copy input_tag1 to &amp;lt;end_address_of_previous_outbuf&amp;gt;, with size=input_size-0xFA.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
There&#039;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&#039;t be controlled it seems(with just broadcasting a beacon at least). It&#039;s unknown whether this could be exploited from just using NWMUDS service-cmd(s) directly.&lt;br /&gt;
| 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.&lt;br /&gt;
| None&lt;br /&gt;
| [[9.0.0-20]]&lt;br /&gt;
| ~September 23, 2014(see the [[NWMUDS:DecryptBeaconData]] page history)&lt;br /&gt;
| August 3, 2015&lt;br /&gt;
| [[User:Yellows8|Yellows8]]&lt;br /&gt;
|-&lt;br /&gt;
| [[HID_Services|HID]] module shared-mem&lt;br /&gt;
| 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.&lt;br /&gt;
| ROP under HID module, but this is *very* unlikely to be exploitable since the data written is HID data.&lt;br /&gt;
| None&lt;br /&gt;
| [[9.3.0-21]]&lt;br /&gt;
| 2014?&lt;br /&gt;
| &lt;br /&gt;
| [[User:Yellows8|Yellows8]]&lt;br /&gt;
|-&lt;br /&gt;
| gspwn&lt;br /&gt;
| 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&#039;re running under, and gain real code-execution from a ROP-chain. Normally applets&#039; .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).&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
| User-mode code execution.&lt;br /&gt;
| None&lt;br /&gt;
| [[9.6.0-24|9.6.0-X]]&lt;br /&gt;
| Early 2014&lt;br /&gt;
| &lt;br /&gt;
| smea, [[User:Yellows8|Yellows8]]/others before then&lt;br /&gt;
|-&lt;br /&gt;
| rohax&lt;br /&gt;
| 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.&lt;br /&gt;
&lt;br /&gt;
This was fixed after [[ninjhax]] release by adding checks on [[CRO0]]-based pointers before writing to them.&lt;br /&gt;
| Memory-mapping syscalls.&lt;br /&gt;
| [[9.3.0-21]]&lt;br /&gt;
| [[9.4.0-21]]&lt;br /&gt;
| &lt;br /&gt;
| &lt;br /&gt;
| smea, [[User:Plutooo|plutoo]] joint effort&lt;br /&gt;
|-&lt;br /&gt;
| Region free&lt;br /&gt;
| Only [[Home Menu]] itself checks gamecards&#039; 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.&lt;br /&gt;
This essentially means launching the gamecard with the [[NS_and_APT_Services|&amp;quot;ns:s&amp;quot;]] 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]].&lt;br /&gt;
| Launching gamecards from any region + bypassing Home Menu gamecard-sysupdate installation&lt;br /&gt;
| None&lt;br /&gt;
| Last tested with [[10.1.0-27|10.1.0-X]].&lt;br /&gt;
| June(?) 2014&lt;br /&gt;
| &lt;br /&gt;
| [[User:Yellows8|Yellows8]]&lt;br /&gt;
|-&lt;br /&gt;
| [[NWM_Services|NWM]] service-cmd state null-ptr deref&lt;br /&gt;
| 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.&lt;br /&gt;
It&#039;s unknown whether any NWM services besides NWMUDS have this issue.&lt;br /&gt;
| This is rather useless since it&#039;s only a crash caused by a state ptr based at 0x0.&lt;br /&gt;
| None&lt;br /&gt;
| [[9.0.0-20]]&lt;br /&gt;
| 2013?&lt;br /&gt;
| &lt;br /&gt;
| [[User:Yellows8|Yellows8]]&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
=== General/CTRSDK ===&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot; border=&amp;quot;1&amp;quot;&lt;br /&gt;
|-&lt;br /&gt;
!  Summary&lt;br /&gt;
!  Description&lt;br /&gt;
!  Successful exploitation result&lt;br /&gt;
!  Fixed in version&lt;br /&gt;
!  Last version this flaw was checked for&lt;br /&gt;
!  Timeframe this was discovered&lt;br /&gt;
!  Discovered by&lt;br /&gt;
|-&lt;br /&gt;
| [[NWM_Services|UDS]] beacon additional-data buffer overflow&lt;br /&gt;
| 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.&lt;br /&gt;
This was discovered while doing code RE with an old dlp-module version. It&#039;s unknown in what specific CTRSDK version this was fixed, or even what system-version updated titles with a fixed version.&lt;br /&gt;
&lt;br /&gt;
It&#039;s unknown if there&#039;s any titles using a vulnerable CTRSDK version which are also exploitable with this(dlp module can&#039;t be exploited with this).&lt;br /&gt;
&lt;br /&gt;
The maximum number of bytes that can be written beyond the end of the outbuf is 0x37-bytes, with additionaldata_size=0xFF.&lt;br /&gt;
| Perhaps ROP, very difficult if possible with anything at all&lt;br /&gt;
| ?&lt;br /&gt;
| &lt;br /&gt;
| September(?) 2014&lt;br /&gt;
| [[User:Yellows8|Yellows8]]&lt;br /&gt;
|}&lt;/div&gt;</summary>
		<author><name>Motezazer</name></author>
	</entry>
	<entry>
		<id>https://www.3dbrew.org/w/index.php?title=AES_Registers&amp;diff=15124</id>
		<title>AES Registers</title>
		<link rel="alternate" type="text/html" href="https://www.3dbrew.org/w/index.php?title=AES_Registers&amp;diff=15124"/>
		<updated>2016-01-01T01:39:43Z</updated>

		<summary type="html">&lt;p&gt;Motezazer: Well it&amp;#039;s leaked now.&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;== Registers ==&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot; border=&amp;quot;1&amp;quot;&lt;br /&gt;
!  Old3DS&lt;br /&gt;
!  Name&lt;br /&gt;
!  Address&lt;br /&gt;
!  Width&lt;br /&gt;
!  RW&lt;br /&gt;
|-&lt;br /&gt;
| style=&amp;quot;background: green&amp;quot; | Yes&lt;br /&gt;
| [[#AES_CNT|AES_CNT]]&lt;br /&gt;
| 0x10009000&lt;br /&gt;
| 4&lt;br /&gt;
| RW&lt;br /&gt;
|-&lt;br /&gt;
| style=&amp;quot;background: green&amp;quot; | Yes&lt;br /&gt;
| [[#AES_BLKCNT|AES_BLKCNT]]&lt;br /&gt;
| 0x10009004&lt;br /&gt;
| 4&lt;br /&gt;
| W?&lt;br /&gt;
|-&lt;br /&gt;
| style=&amp;quot;background: green&amp;quot; | Yes&lt;br /&gt;
| [[#AES_WRFIFO/AES_RDFIFO|AES_WRFIFO]]&lt;br /&gt;
| 0x10009008&lt;br /&gt;
| 4&lt;br /&gt;
| W&lt;br /&gt;
|-&lt;br /&gt;
| style=&amp;quot;background: green&amp;quot; | Yes&lt;br /&gt;
| [[#AES_WRFIFO/AES_RDFIFO|AES_RDFIFO]]&lt;br /&gt;
| 0x1000900C&lt;br /&gt;
| 4&lt;br /&gt;
| R&lt;br /&gt;
|-&lt;br /&gt;
| style=&amp;quot;background: green&amp;quot; | Yes&lt;br /&gt;
| AES_KEYSEL&lt;br /&gt;
| 0x10009010&lt;br /&gt;
| 1&lt;br /&gt;
| RW&lt;br /&gt;
|-&lt;br /&gt;
| style=&amp;quot;background: green&amp;quot; | Yes&lt;br /&gt;
| [[#AES_KEYCNT|AES_KEYCNT]]&lt;br /&gt;
| 0x10009011&lt;br /&gt;
| 1&lt;br /&gt;
| RW&lt;br /&gt;
|-&lt;br /&gt;
| style=&amp;quot;background: green&amp;quot; | Yes&lt;br /&gt;
| [[#AES_CTR|AES_CTR]]&lt;br /&gt;
| 0x10009020&lt;br /&gt;
| 16&lt;br /&gt;
| W&lt;br /&gt;
|-&lt;br /&gt;
| style=&amp;quot;background: green&amp;quot; | Yes&lt;br /&gt;
| [[#AES_MAC|AES_MAC]]&lt;br /&gt;
| 0x10009030&lt;br /&gt;
| 16&lt;br /&gt;
| W&lt;br /&gt;
|-&lt;br /&gt;
| style=&amp;quot;background: green&amp;quot; | Yes&lt;br /&gt;
| AES_KEY0&lt;br /&gt;
| 0x10009040&lt;br /&gt;
| 48&lt;br /&gt;
| W&lt;br /&gt;
|-&lt;br /&gt;
| style=&amp;quot;background: green&amp;quot; | Yes&lt;br /&gt;
| AES_KEY1&lt;br /&gt;
| 0x10009070&lt;br /&gt;
| 48&lt;br /&gt;
| W&lt;br /&gt;
|-&lt;br /&gt;
| style=&amp;quot;background: green&amp;quot; | Yes&lt;br /&gt;
| AES_KEY2&lt;br /&gt;
| 0x100090A0&lt;br /&gt;
| 48&lt;br /&gt;
| W&lt;br /&gt;
|-&lt;br /&gt;
| style=&amp;quot;background: green&amp;quot; | Yes&lt;br /&gt;
| AES_KEY3&lt;br /&gt;
| 0x100090D0&lt;br /&gt;
| 48&lt;br /&gt;
| W&lt;br /&gt;
|-&lt;br /&gt;
| style=&amp;quot;background: green&amp;quot; | Yes&lt;br /&gt;
| AES_KEYFIFO&lt;br /&gt;
| 0x10009100&lt;br /&gt;
| 4&lt;br /&gt;
| W&lt;br /&gt;
|-&lt;br /&gt;
| style=&amp;quot;background: green&amp;quot; | Yes&lt;br /&gt;
| AES_KEYXFIFO&lt;br /&gt;
| 0x10009104&lt;br /&gt;
| 4&lt;br /&gt;
| W&lt;br /&gt;
|-&lt;br /&gt;
| style=&amp;quot;background: green&amp;quot; | Yes&lt;br /&gt;
| AES_KEYYFIFO&lt;br /&gt;
| 0x10009108&lt;br /&gt;
| 4&lt;br /&gt;
| W&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
== AES_CNT ==&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot; border=&amp;quot;1&amp;quot;&lt;br /&gt;
!  Bit&lt;br /&gt;
!  Description&lt;br /&gt;
|-&lt;br /&gt;
| 4-0&lt;br /&gt;
| Write FIFO count (0-16)&lt;br /&gt;
|-&lt;br /&gt;
| 9-5&lt;br /&gt;
| Read FIFO count (0-16)&lt;br /&gt;
|-&lt;br /&gt;
| 10&lt;br /&gt;
| Flush write FIFO (1=Clear write FIFO)&lt;br /&gt;
|-&lt;br /&gt;
| 11&lt;br /&gt;
| Flush read fifo (1=Clear read FIFO)&lt;br /&gt;
|-&lt;br /&gt;
| 18-16&lt;br /&gt;
| MAC size (encoding = (maclen-2)/2)&lt;br /&gt;
|-&lt;br /&gt;
| 19&lt;br /&gt;
|? (MAC related)&lt;br /&gt;
|-&lt;br /&gt;
| 20&lt;br /&gt;
| MAC input control (0 = read MAC from FIFO, 1 = read from MAC register)&lt;br /&gt;
|-&lt;br /&gt;
| 21&lt;br /&gt;
| MAC status (0 = invalid, 1 = verified)&lt;br /&gt;
|-&lt;br /&gt;
| 22&lt;br /&gt;
| Output endianness (1=Big endian, 0=Little endian)&lt;br /&gt;
|-&lt;br /&gt;
| 23&lt;br /&gt;
| Input endianness (1=Big endian, 0=Little endian)&lt;br /&gt;
|-&lt;br /&gt;
| 24&lt;br /&gt;
| Output word order (1=Normal order, 0=Reversed order)&lt;br /&gt;
|-&lt;br /&gt;
| 25&lt;br /&gt;
| Input word order (1=Normal order, 0=Reversed order)&lt;br /&gt;
|-&lt;br /&gt;
|-&lt;br /&gt;
| 26&lt;br /&gt;
| Update keyslot (selects the keyslot specified by REG_AESKEYSEL when this bit is set)&lt;br /&gt;
|-&lt;br /&gt;
| 29-27&lt;br /&gt;
| Mode (0=CCM decrypt, 1=CCM encrypt, 2=CTR, 3=CTR, 4=CBC decrypt, 5=CBC encrypt, 6=ECB decrypt, 7=ECB encrypt)&lt;br /&gt;
|-&lt;br /&gt;
| 30&lt;br /&gt;
| Interrupt enable (1=enable, 0=disable)&lt;br /&gt;
|-&lt;br /&gt;
| 31&lt;br /&gt;
| Start (1=enable/busy, 0=idle)&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
When bit31 is clear, the AES engine will handle keyslot-selection when bit26 is set immediately. When bit31 is set, the AES engine won&#039;t handle bit26 immediately, instead the AES engine will automatically handle the already-set bit26 once bit31 clears(current AES operation finishes).&lt;br /&gt;
&lt;br /&gt;
Clearing bit31 while the AES engine is doing crypto will result in the AES engine stopping crypto, once it finishes processing the current block.&lt;br /&gt;
&lt;br /&gt;
== AES_BLKCNT ==&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot; border=&amp;quot;1&amp;quot;&lt;br /&gt;
!  Bit&lt;br /&gt;
!  Description&lt;br /&gt;
|-&lt;br /&gt;
| 16-31&lt;br /&gt;
| (Data length)&amp;gt;&amp;gt;4&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
== AES_WRFIFO/AES_RDFIFO ==&lt;br /&gt;
Up to 128 bytes of input data can be buffered.&lt;br /&gt;
&lt;br /&gt;
The input data for the AES crypto operation is written to REG_AESWRFIFO, the output data is read from REG_AESRDFIFO.&lt;br /&gt;
&lt;br /&gt;
Reading from REG_AESRDFIFO when there&#039;s no data available in the RDFIFO will result in reading the last word that was in the RDFIFO.&lt;br /&gt;
&lt;br /&gt;
== AES_KEYCNT ==&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot; border=&amp;quot;1&amp;quot;&lt;br /&gt;
!  Bit&lt;br /&gt;
!  Description&lt;br /&gt;
|-&lt;br /&gt;
| 5-0&lt;br /&gt;
| Keyslot&lt;br /&gt;
|-&lt;br /&gt;
| 6&lt;br /&gt;
| Hardware key-generator type: 0 = 3DS, 1 = DSi.&lt;br /&gt;
|-&lt;br /&gt;
| 7&lt;br /&gt;
| This normally has value 1 written here when updating keys. 0 = disable key FIFO flush, 1 = enable key FIFO flush.&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
Bit6 is only used when keyslots &amp;gt;=4 are used, value1 has the same affect as doing key-init with the TWL keyslots. Bit6 is only checked when a keyY was completely written, for when the final-normalkey needs updated via the key-generator. Changing bit6 has no affect on the generated normalkey when writing to this bit immediately after writing the last keyY word.&lt;br /&gt;
&lt;br /&gt;
== AES_CTR ==&lt;br /&gt;
This register specifies the counter (CTR mode), nonce (CCM mode) or the initialization vector (CBC mode) depending on the mode of operation.&lt;br /&gt;
For CBC and CTR mode this register takes up the full 16 bytes, but for CCM mode the nonce is only the first 12 bytes.&lt;br /&gt;
The AES engine will automatically increment the counter up to the maximum BLKCNT, after which point it must be manually incremented and set again.&lt;br /&gt;
&lt;br /&gt;
== AES_MAC ==&lt;br /&gt;
This register specifies the message authentication code (MAC) for use in CCM mode.&lt;br /&gt;
&lt;br /&gt;
== AES_KEY0/1/2/3 ==&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot; border=&amp;quot;1&amp;quot;&lt;br /&gt;
!  Byte&lt;br /&gt;
!  Description&lt;br /&gt;
|-&lt;br /&gt;
| 0-15&lt;br /&gt;
| Normalkey&lt;br /&gt;
|-&lt;br /&gt;
| 16-31&lt;br /&gt;
| KeyX&lt;br /&gt;
|-&lt;br /&gt;
| 32-47&lt;br /&gt;
| KeyY&lt;br /&gt;
|-}&lt;br /&gt;
&lt;br /&gt;
These registers are the same as they were on TWL, and are likely preserved for compatibility reasons. The keyslot is updated immediately after *any* data(u8/u32/...) is written here, which was used on DSi to [[3DS_System_Flaws|break]] the key-generator.&lt;br /&gt;
&lt;br /&gt;
== Endianness and word order ==&lt;br /&gt;
When writing to the AES_CTR or AES_MAC register, the hardware will process the written data according to the current input endianness specified in AES_CNT. However, the current specified input word order will not be honored for this register, and always defaults to reversed word order. Therefore, for normal word order, the reversal must be carried out manually if required.&lt;br /&gt;
&lt;br /&gt;
== Keyslot ranges ==&lt;br /&gt;
This is approximately a table of what is set by bootrom before booting into FIRM. Often it appears that keyslots in groups of 4 have the same keyX, and sometimes also same keyY set.&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot; border=&amp;quot;1&amp;quot;&lt;br /&gt;
!  Keyslot&lt;br /&gt;
!  Name&lt;br /&gt;
!  KeyX&lt;br /&gt;
!  KeyY/Normal-key&lt;br /&gt;
!  Console unique.&lt;br /&gt;
|-&lt;br /&gt;
| 0x00-0x03&lt;br /&gt;
| TWL keys.&lt;br /&gt;
| Probably unset.&lt;br /&gt;
| Probably unset.&lt;br /&gt;
| -&lt;br /&gt;
|-&lt;br /&gt;
| 0x04-0x07&lt;br /&gt;
| NAND partition keys.&lt;br /&gt;
| Same for all.&lt;br /&gt;
| Different for all.&lt;br /&gt;
| style=&amp;quot;background: green&amp;quot; | Yes&lt;br /&gt;
|-&lt;br /&gt;
| 0x08-0x0B&lt;br /&gt;
| See below.&lt;br /&gt;
| Same for all.&lt;br /&gt;
| Different for all.&lt;br /&gt;
| style=&amp;quot;background: green&amp;quot; | Yes&lt;br /&gt;
|-&lt;br /&gt;
| 0x0C-0x0F&lt;br /&gt;
| SSL cert key.&lt;br /&gt;
| Same for all.&lt;br /&gt;
| Same for all.&lt;br /&gt;
| style=&amp;quot;background: red&amp;quot; | No&lt;br /&gt;
|-&lt;br /&gt;
| 0x10-0x17&lt;br /&gt;
| -&lt;br /&gt;
| Not set.&lt;br /&gt;
| Not set.&lt;br /&gt;
| -&lt;br /&gt;
|-&lt;br /&gt;
| 0x18-0x1B&lt;br /&gt;
| Never used.&lt;br /&gt;
| Same for all.&lt;br /&gt;
| Same for all.&lt;br /&gt;
| style=&amp;quot;background: green&amp;quot; | Yes&lt;br /&gt;
|-&lt;br /&gt;
| 0x1C-0x1F&lt;br /&gt;
| Never used.&lt;br /&gt;
| Same for all.&lt;br /&gt;
| Same for all.&lt;br /&gt;
| style=&amp;quot;background: green&amp;quot; | Yes&lt;br /&gt;
|-&lt;br /&gt;
| 0x20-0x23&lt;br /&gt;
| Never used.&lt;br /&gt;
| Same for all.&lt;br /&gt;
| Same for all.&lt;br /&gt;
| style=&amp;quot;background: orange&amp;quot; | Normalkey is not. keyX is. keyY unknown.&lt;br /&gt;
|-&lt;br /&gt;
| 0x24&lt;br /&gt;
| Never used.&lt;br /&gt;
| Individually set.&lt;br /&gt;
| Individually set.&lt;br /&gt;
| style=&amp;quot;background: orange&amp;quot; | Normalkey is not. keyX is. keyY unknown.&lt;br /&gt;
|-&lt;br /&gt;
| 0x25-0x27&lt;br /&gt;
| -&lt;br /&gt;
| Not set.&lt;br /&gt;
| Not set.&lt;br /&gt;
| -&lt;br /&gt;
|-&lt;br /&gt;
| 0x28-0x2B&lt;br /&gt;
| Never used.&lt;br /&gt;
| Individually set.&lt;br /&gt;
| Individually set.&lt;br /&gt;
| style=&amp;quot;background: orange&amp;quot; | Normalkey is not. keyX is. keyY unknown.&lt;br /&gt;
|-&lt;br /&gt;
| 0x2C-0x2F&lt;br /&gt;
| Various uniques.&lt;br /&gt;
| Same for all.&lt;br /&gt;
| Same for all, probably.&lt;br /&gt;
| style=&amp;quot;background: red&amp;quot; | No&lt;br /&gt;
|-&lt;br /&gt;
| 0x30-0x33&lt;br /&gt;
| Various uniques.&lt;br /&gt;
| Same for all.&lt;br /&gt;
| Same for all, probably.&lt;br /&gt;
| style=&amp;quot;background: red&amp;quot; | No&lt;br /&gt;
|-&lt;br /&gt;
| 0x34-0x37&lt;br /&gt;
| Various uniques.&lt;br /&gt;
| Same for all.&lt;br /&gt;
| Same for all, probably.&lt;br /&gt;
| style=&amp;quot;background: red&amp;quot; | No&lt;br /&gt;
|-&lt;br /&gt;
| 0x38-0x3B&lt;br /&gt;
| Various uniques.&lt;br /&gt;
| Same for all.&lt;br /&gt;
| Different for all.&lt;br /&gt;
| style=&amp;quot;background: red&amp;quot; | No&lt;br /&gt;
|-&lt;br /&gt;
| 0x3C-0x3F&lt;br /&gt;
| Various uniques.&lt;br /&gt;
| Individually set.&lt;br /&gt;
| Individually set.&lt;br /&gt;
| style=&amp;quot;background: red&amp;quot; | No&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
Keyslot pairs (0x24, 0x28) and (0x38, 0x3C) shares the same normal-key, while at the same time having different keyX&#039;s. This suggests they were set to same normal-key by bootrom.&lt;br /&gt;
&lt;br /&gt;
== Keyslots ==&lt;br /&gt;
There are 0x40 keyslots, each of which stores three keys called keyX, keyY and normalkey. All keys can be set explicitly, but the normalkey can optionally be generated using a hardware key generator instead (see [[#Hardware_key_generator|below]]). There is no way to read the contents of a keyslot.&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot; border=&amp;quot;1&amp;quot;&lt;br /&gt;
!  Keyslot&lt;br /&gt;
!  Description&lt;br /&gt;
!  KeyX set by&lt;br /&gt;
!  KeyY set by&lt;br /&gt;
!  Normal-key&lt;br /&gt;
!  Old3DS&lt;br /&gt;
|-&lt;br /&gt;
| 0x00-0x03&lt;br /&gt;
| TWL keys.&lt;br /&gt;
| NATIVE_FIRM hard-boot.&lt;br /&gt;
| NATIVE_FIRM hard-boot.&lt;br /&gt;
| -&lt;br /&gt;
| Yes&lt;br /&gt;
|-&lt;br /&gt;
| 0x04..0x07&lt;br /&gt;
| [[Flash_Filesystem|NAND]] partition keys.&lt;br /&gt;
&lt;br /&gt;
Keyslot is determined by [[NCSD]] partition FS type and encryption type. &lt;br /&gt;
The New3DS Process9 sets the keyY for keyslot 0x05 (New3DS CTRNAND) to a key from .(ro)data. Its keyX is console-unique and set by the bootloader.&lt;br /&gt;
| Bootrom.&lt;br /&gt;
| Bootrom.&lt;br /&gt;
| -&lt;br /&gt;
| Yes&lt;br /&gt;
|-&lt;br /&gt;
| 0x0A&lt;br /&gt;
| DSiWare export key.&lt;br /&gt;
&lt;br /&gt;
Used for encrypting the all-zero 0x10-byte block in the [[DSiWare_Exports|DSiWare_Exports]] header. Console-unique.&lt;br /&gt;
| See above keyslot info.&lt;br /&gt;
| See above keyslot info.&lt;br /&gt;
| -&lt;br /&gt;
| Yes&lt;br /&gt;
|-&lt;br /&gt;
| 0x0B&lt;br /&gt;
| This is console-unique. This keyslot is used for the NAND [[Title_Database|dbs]] images AESMACs, and the [[Nand/private/movable.sed]] AESMAC(when used).&lt;br /&gt;
| See above keyslot info.&lt;br /&gt;
| See above keyslot info.&lt;br /&gt;
| -&lt;br /&gt;
| Yes&lt;br /&gt;
|-&lt;br /&gt;
| 0x0D&lt;br /&gt;
| SSL-certificate key.&lt;br /&gt;
&lt;br /&gt;
See [[PSPXI:EncryptDecryptAes|EncryptDecryptAes]].&lt;br /&gt;
| -&lt;br /&gt;
| -&lt;br /&gt;
| Bootrom.&lt;br /&gt;
| Yes&lt;br /&gt;
|-&lt;br /&gt;
| 0x11&lt;br /&gt;
| Temporary keyslot.&lt;br /&gt;
&lt;br /&gt;
Used by FIRM for general normal-key crypto. Also used by the New3DS [[FIRM]] arm9 binary loader.&lt;br /&gt;
| Arm9Loader. &lt;br /&gt;
| Arm9Loader.&lt;br /&gt;
| NATIVE_FIRM.&lt;br /&gt;
| Yes&lt;br /&gt;
|-&lt;br /&gt;
| 0x14&lt;br /&gt;
| Starting with [[5.0.0-11]], NATIVE_FIRM Process9 now sets the keyY for this to the same one it uses for initializing 3 of the keyslots&#039; keyYs from [[PSPXI:EncryptDecryptAes|here]].&lt;br /&gt;
| Bootrom.&lt;br /&gt;
| NATIVE_FIRM boot.&lt;br /&gt;
| -&lt;br /&gt;
| Yes&lt;br /&gt;
|-&lt;br /&gt;
| 0x15&lt;br /&gt;
| Used/initialized by the New3DS arm9 binary loader, see [[FIRM|here]].&lt;br /&gt;
| Arm9Loader.&lt;br /&gt;
| Arm9Loader.&lt;br /&gt;
| See previous info for this keyslot.&lt;br /&gt;
| No&lt;br /&gt;
|-&lt;br /&gt;
| 0x16&lt;br /&gt;
| Used/initialized by the New3DS arm9 binary loader starting with [[9.5.0-22|9.5.0-X]], see [[FIRM|here]].&lt;br /&gt;
| Arm9Loader.&lt;br /&gt;
| Arm9Loader.&lt;br /&gt;
| See previous info for this keyslot.&lt;br /&gt;
| No&lt;br /&gt;
|-&lt;br /&gt;
| 0x18..0x1F&lt;br /&gt;
| These are the New3DS keyslots, where the keyX is generated with keyslot 0x11 by the New3DS arm9 binary [[FIRM|loader]]. As of [[FIRM]] [[9.6.0-24|9.6.0-X]] keyslots 0x1C..0x1F are not yet used by Process9.&lt;br /&gt;
| Arm9Loader.&lt;br /&gt;
| NATIVE_FIRM / see previous info for these keyslots.&lt;br /&gt;
| See previous info for these keyslots.&lt;br /&gt;
| No&lt;br /&gt;
|-&lt;br /&gt;
| 0x18&lt;br /&gt;
| New3DS [[9.3.0-21|9.3.0-X]] [[NCCH]] key, when ncchflag[3] is 0x0A.&lt;br /&gt;
| Arm9Loader.&lt;br /&gt;
| NATIVE_FIRM&lt;br /&gt;
| -&lt;br /&gt;
| No&lt;br /&gt;
|-&lt;br /&gt;
| 0x19&lt;br /&gt;
| New3DS gamecard [[Savegames|savedata]] AES-MAC key.&lt;br /&gt;
&lt;br /&gt;
Equivalent of keyslot 0x33, used when a [[NCSD]] flag is set to a certain value (implemented with [[9.3.0-21|9.3.0-X]]).&lt;br /&gt;
| Arm9Loader.&lt;br /&gt;
| NATIVE_FIRM&lt;br /&gt;
| -&lt;br /&gt;
| No&lt;br /&gt;
|-&lt;br /&gt;
| 0x1A&lt;br /&gt;
| New3DS gamecard [[Savegames|savedata]] actual key.&lt;br /&gt;
&lt;br /&gt;
Equivalent of keyslot 0x37, used when a [[NCSD]] flag is set to a certain value (implemented with [[9.3.0-21|9.3.0-X]]).&lt;br /&gt;
| Arm9Loader.&lt;br /&gt;
| NATIVE_FIRM&lt;br /&gt;
| -&lt;br /&gt;
| No&lt;br /&gt;
|-&lt;br /&gt;
| 0x1B&lt;br /&gt;
| New3DS [[9.6.0-24|9.6.0-X]] [[NCCH]] key, when ncchflag[3] is 0x0B.&lt;br /&gt;
| Arm9Loader.&lt;br /&gt;
| NATIVE_FIRM&lt;br /&gt;
| -&lt;br /&gt;
| No&lt;br /&gt;
|-&lt;br /&gt;
| 0x24&lt;br /&gt;
| AGB_FIRM savegame AES-MAC key.&lt;br /&gt;
| Bootrom.&lt;br /&gt;
| AGB/NATIVE_FIRM.&lt;br /&gt;
| -&lt;br /&gt;
| Yes&lt;br /&gt;
|-&lt;br /&gt;
| 0x25&lt;br /&gt;
| [[7.0.0-13|v7.0]] [[NCCH]] key, when ncchflag[3] is 0x01.&lt;br /&gt;
| NATIVE_FIRM [[Savegames#6.0.0-11_Savegame_keyY|boot]].&lt;br /&gt;
| NATIVE_FIRM.&lt;br /&gt;
| -&lt;br /&gt;
| Yes&lt;br /&gt;
|-&lt;br /&gt;
| 0x2C&lt;br /&gt;
| Original [[NCCH|NCCH]] key, when ncchflag[3] is 0x00 and always for certain NCCH sections.&lt;br /&gt;
| Bootrom.&lt;br /&gt;
| Process9.&lt;br /&gt;
| -&lt;br /&gt;
| Yes&lt;br /&gt;
|-&lt;br /&gt;
| 0x2D&lt;br /&gt;
| UDS local-WLAN CCMP key.&lt;br /&gt;
&lt;br /&gt;
See [[PSPXI:EncryptDecryptAes|EncryptDecryptAes]].&lt;br /&gt;
| Bootrom.&lt;br /&gt;
| Bootrom.&lt;br /&gt;
| -&lt;br /&gt;
| Yes&lt;br /&gt;
|-&lt;br /&gt;
| 0x2E&lt;br /&gt;
| Streetpass key.&lt;br /&gt;
&lt;br /&gt;
See [[PSPXI:EncryptDecryptAes|EncryptDecryptAes]].&lt;br /&gt;
| Bootrom.&lt;br /&gt;
| NATIVE_FIRM.&lt;br /&gt;
| -&lt;br /&gt;
| Yes&lt;br /&gt;
|-&lt;br /&gt;
| 0x2F&lt;br /&gt;
| [[Savegames#6.0.0-11_Savegame_keyY|v6.0]] save key.&lt;br /&gt;
| Bootrom.&lt;br /&gt;
| NATIVE_FIRM.&lt;br /&gt;
| -&lt;br /&gt;
| Yes&lt;br /&gt;
|-&lt;br /&gt;
| 0x30&lt;br /&gt;
| SD/NAND AES-MAC key.&lt;br /&gt;
&lt;br /&gt;
This keyY is initialized via [[Nand/private/movable.sed|movable.sed]]. This is used for calculating the AESMACs under SD [[SD_Filesystem|/Nintendo 3DS/&amp;lt;ID0&amp;gt;/&amp;lt;ID1&amp;gt;/]] (except [[DSiWare_Exports]]) and [[Flash_Filesystem|NAND]] /data/.&lt;br /&gt;
| Bootrom.&lt;br /&gt;
| NATIVE_FIRM.&lt;br /&gt;
| -&lt;br /&gt;
| Yes&lt;br /&gt;
|-&lt;br /&gt;
| 0x31&lt;br /&gt;
| APT wrap key.&lt;br /&gt;
&lt;br /&gt;
See [[PSPXI:EncryptDecryptAes|EncryptDecryptAes]]. NATIVE_FIRM sets this keyY to the same one used for keyslot 0x2E.&lt;br /&gt;
| Bootrom.&lt;br /&gt;
| NATIVE_FIRM.&lt;br /&gt;
| -&lt;br /&gt;
| Yes&lt;br /&gt;
|-&lt;br /&gt;
| 0x32&lt;br /&gt;
| Unknown.&lt;br /&gt;
&lt;br /&gt;
See [[PSPXI:EncryptDecryptAes|EncryptDecryptAes]].&lt;br /&gt;
| Bootrom.&lt;br /&gt;
| Bootrom.&lt;br /&gt;
| -&lt;br /&gt;
| Yes&lt;br /&gt;
|-&lt;br /&gt;
| 0x33&lt;br /&gt;
| Gamecard [[Savegames|savedata]] AES-MAC.&lt;br /&gt;
| Bootrom.&lt;br /&gt;
| NATIVE_FIRM.&lt;br /&gt;
| -&lt;br /&gt;
| Yes&lt;br /&gt;
|-&lt;br /&gt;
| 0x34&lt;br /&gt;
| SD key.&lt;br /&gt;
&lt;br /&gt;
This keyY is initialized via [[Nand/private/movable.sed|movable.sed]]. This is used for encrypting *all* SD card data under [[SD_Filesystem|/Nintendo 3DS/&amp;lt;ID0&amp;gt;/&amp;lt;ID1&amp;gt;/]].&lt;br /&gt;
| Bootrom.&lt;br /&gt;
| NATIVE_FIRM.&lt;br /&gt;
| -&lt;br /&gt;
| Yes&lt;br /&gt;
|-&lt;br /&gt;
| 0x35&lt;br /&gt;
| Movable.sed key.&lt;br /&gt;
&lt;br /&gt;
This is the keyslot used for movable.sed encryption + AES-MAC with the import/export [[FSPXI:ImportIntegrityVerificationSeed|commands]].&lt;br /&gt;
| Bootrom.&lt;br /&gt;
| Bootrom.&lt;br /&gt;
| -&lt;br /&gt;
| Yes&lt;br /&gt;
|-&lt;br /&gt;
| 0x36&lt;br /&gt;
| Unknown. Used by friends module.&lt;br /&gt;
&lt;br /&gt;
See [[PSPXI:EncryptDecryptAes|EncryptDecryptAes]].&lt;br /&gt;
| Bootrom.&lt;br /&gt;
| Bootrom.&lt;br /&gt;
| -&lt;br /&gt;
| Yes&lt;br /&gt;
|-&lt;br /&gt;
| 0x37&lt;br /&gt;
| Gamecard [[Savegames|savedata]] actual key.&lt;br /&gt;
| Bootrom.&lt;br /&gt;
| NATIVE_FIRM.&lt;br /&gt;
| -&lt;br /&gt;
| Yes&lt;br /&gt;
|-&lt;br /&gt;
| 0x38&lt;br /&gt;
| BOSS key.&lt;br /&gt;
&lt;br /&gt;
See [[PSPXI:EncryptDecryptAes|EncryptDecryptAes]].&lt;br /&gt;
| Bootrom.&lt;br /&gt;
| Bootrom.&lt;br /&gt;
| -&lt;br /&gt;
| Yes&lt;br /&gt;
|-&lt;br /&gt;
| 0x39&lt;br /&gt;
| Download Play key, and the actual NFC key for generating retail [[Amiibo]] keys.&lt;br /&gt;
&lt;br /&gt;
This keyslot is used for two different keys. Both are available via [[PSPXI:EncryptDecryptAes|EncryptDecryptAes]]. NATIVE_FIRM sets this keyY to the same one used for keyslot 0x2E.&lt;br /&gt;
| Bootrom.&lt;br /&gt;
| NATIVE_FIRM.&lt;br /&gt;
| -&lt;br /&gt;
| Yes&lt;br /&gt;
|-&lt;br /&gt;
| 0x3A&lt;br /&gt;
| DSiWare export key.&lt;br /&gt;
&lt;br /&gt;
This keyY is initialized via [[Nand/private/movable.sed|movable.sed]]. This is used for calculating the AESMACs for SD [[DSiWare_Exports]].&lt;br /&gt;
| Bootrom.&lt;br /&gt;
| NATIVE_FIRM.&lt;br /&gt;
| -&lt;br /&gt;
| Yes&lt;br /&gt;
|-&lt;br /&gt;
| 0x3B&lt;br /&gt;
| [[CTRCARD_Registers#CTRCARD_SECSEED|CTR-CARD hardware-crypto seed]] decryption key.&lt;br /&gt;
&lt;br /&gt;
AES-CCM is used, the keyY, nonce and MAC are stored in the [[NCSD#Card_Info_Header|Card Info Header]].&lt;br /&gt;
| Bootrom.&lt;br /&gt;
| NATIVE_FIRM.&lt;br /&gt;
| -&lt;br /&gt;
| Yes&lt;br /&gt;
|-&lt;br /&gt;
| 0x3D&lt;br /&gt;
| Common key.&lt;br /&gt;
&lt;br /&gt;
Used to decrypt title keys in [[Ticket]].&lt;br /&gt;
| Bootrom.&lt;br /&gt;
| NATIVE_FIRM.&lt;br /&gt;
| -&lt;br /&gt;
| Yes&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
=== Updating keydata ===&lt;br /&gt;
The contents of the keyslot specified in REG_AESKEYCNT can be updated by consecutively writing four words to REG_AESKEYXFIFO (keyX), REG_AESKEYYFIFO(keyY), or REG_AESKEYFIFO (normalkey).&lt;br /&gt;
&lt;br /&gt;
After writing to a keyslot, the keyslot must be selected again(write REG_AESKEYSEL + set REG_AESCNT bit26), even when writing to the same keyslot. Writing the last word to a key FIFO immediately after selecting a keyslot will not affect the keyslot keydata that gets used at that time, the new keydata will not get used until the keyslot gets selected again.&lt;br /&gt;
&lt;br /&gt;
Writing to the key FIFOs with byte writes results in the AES engine converting the byte to a word for setting the key word, with this: word = (byteval) | (byteval&amp;lt;&amp;lt;8) | (byteval&amp;lt;&amp;lt;16) | (byteval&amp;lt;&amp;lt;24). The result is the same regardless of which FIFO register byte was written to.&lt;br /&gt;
&lt;br /&gt;
The TWL keyslots 0x00-0x03 can be set directly by writing to the REG_AESKEY0-REG_AESKEY3 registers.&lt;br /&gt;
&lt;br /&gt;
The key FIFOs can be written simultaneously. For example, executing the following 4 times will result in the keyX and keyY being set to all-zero(unknown for normalkey): memset(0x10009100, 0, 0x100);&lt;br /&gt;
&lt;br /&gt;
Each key FIFO has a 0x10-byte tmp-buffer for storing the words written to that FIFO. Once the last word is written to a key FIFO, the filled tmp-buffer is then written to the key-data for the keyslot selected by REG_AESKEYCNT at the time the last word was written.&lt;br /&gt;
&lt;br /&gt;
=== Hardware key generator ===&lt;br /&gt;
A dedicated hardware key generator can be used to generate a keyslot&#039;s normal-key from its keyX and keyY. The hardware key generator is triggered by writing the keyY, which is the only way to trigger it with the 3DS keyslots.&lt;br /&gt;
&lt;br /&gt;
The algorithm for generating the normal-key from keyX and keyY is as follows, in big-endian 128-bit unsigned wraparound arithmetic:&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot; border=&amp;quot;1&amp;quot;&lt;br /&gt;
! Mode&lt;br /&gt;
! Formula&lt;br /&gt;
|-&lt;br /&gt;
| 3DS&lt;br /&gt;
| NormalKey = (((KeyX ROL 2) XOR KeyY) + C) ROR 41&lt;br /&gt;
|-&lt;br /&gt;
| DSi&lt;br /&gt;
| NormalKey = ((KeyX XOR KeyY) + C) ROL 42&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
Unless noted otherwise, all keyslots on retail units use the hardware key generator.&lt;br /&gt;
&lt;br /&gt;
=== FIRM-launch key clearing ===&lt;br /&gt;
Starting with [[9.0.0-20]] the Process9 FIRM-launch code now &amp;quot;clears&amp;quot; the following AES keyslots, with certain keydata by writing the normal-key: 0x15 and 0x18-0x20. These are the keyslots used by the New3DS [[FIRM]] arm9bin loader(minus keyslot 0x11), the New3DS Process9 does this too.&lt;/div&gt;</summary>
		<author><name>Motezazer</name></author>
	</entry>
	<entry>
		<id>https://www.3dbrew.org/w/index.php?title=Homebrew_Exploits&amp;diff=14393</id>
		<title>Homebrew Exploits</title>
		<link rel="alternate" type="text/html" href="https://www.3dbrew.org/w/index.php?title=Homebrew_Exploits&amp;diff=14393"/>
		<updated>2015-10-30T23:03:46Z</updated>

		<summary type="html">&lt;p&gt;Motezazer: 10.2.0-30 doesn&amp;#039;t exist yet&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;==Standalone Homebrew Launcher Exploits==&lt;br /&gt;
The following homebrew exploits can be executed on a previously un-exploited system.&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot; border=&amp;quot;1&amp;quot;&lt;br /&gt;
|-&lt;br /&gt;
!  Works on latest fw&lt;br /&gt;
!  Name&lt;br /&gt;
!  Supported firmwares&lt;br /&gt;
!  Requirements&lt;br /&gt;
!  Author&lt;br /&gt;
!  Install&lt;br /&gt;
|-&lt;br /&gt;
| style=&amp;quot;background: red&amp;quot; | No&lt;br /&gt;
| [[ninjhax|Ninjhax 1.1b]]&lt;br /&gt;
| From &#039;&#039;&#039;4.0.0-7&#039;&#039;&#039; up to and including &#039;&#039;&#039;9.2.0-20&#039;&#039;&#039;.&lt;br /&gt;
| A cartridge or eShop version (JPN-only) of &amp;quot;Cubic Ninja&amp;quot;.&lt;br /&gt;
| smea&lt;br /&gt;
| [http://smealum.net/ninjhax/ Install]&lt;br /&gt;
|-&lt;br /&gt;
| style=&amp;quot;background: green&amp;quot; | Yes&lt;br /&gt;
| [[ninjhax|Ninjhax 2.5]]&lt;br /&gt;
| From &#039;&#039;&#039;9.0.0-7&#039;&#039;&#039; up to and including &#039;&#039;&#039;10.2.0-28&#039;&#039;&#039;.&lt;br /&gt;
|  A cartridge or eShop version (JPN-only) of &amp;quot;Cubic Ninja&amp;quot;.&lt;br /&gt;
| smea&lt;br /&gt;
| [https://smealum.github.io/ninjhax2/ Install]&lt;br /&gt;
|-&lt;br /&gt;
| style=&amp;quot;background: green&amp;quot; | Yes&lt;br /&gt;
| [[smashbroshax|smashbroshax]] (beaconhax)&lt;br /&gt;
| (New 3DS only) From &#039;&#039;&#039;9.0.0-X&#039;&#039;&#039; up to and including &#039;&#039;&#039;10.2.0-28&#039;&#039;&#039;.&lt;br /&gt;
| Super Smash Bros 3DS (full-game or demo) and a way to broadcast raw wifi beacons.&lt;br /&gt;
| [[User:Yellows8|Yellows8]]&lt;br /&gt;
| [https://github.com/yellows8/3ds_smashbroshax Install]&lt;br /&gt;
|-&lt;br /&gt;
| style=&amp;quot;background: red&amp;quot; | No&lt;br /&gt;
| [[browserhax]]&lt;br /&gt;
| (Old 3DS) From &#039;&#039;&#039;9.0.0-16&#039;&#039;&#039; to &#039;&#039;&#039;9.5.0-22&#039;&#039;&#039;, &#039;&#039;&#039;9.5.0-23&#039;&#039;&#039; to &#039;&#039;&#039;9.8.0-25&#039;&#039;&#039;, &#039;&#039;&#039;9.9.0-26&#039;&#039;&#039; to &#039;&#039;&#039;10.1.0-27&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
(New 3DS) From &#039;&#039;&#039;9.0.0-20&#039;&#039;&#039; to &#039;&#039;&#039;9.2.0-20&#039;&#039;&#039;, &#039;&#039;&#039;9.3.0-21&#039;&#039;&#039; to &#039;&#039;&#039;9.5.0-23&#039;&#039;&#039;, &#039;&#039;&#039;9.6.0-24&#039;&#039;&#039; to &#039;&#039;&#039;9.8.0-25&#039;&#039;&#039;, &#039;&#039;&#039;9.9.0-26&#039;&#039;&#039; to &#039;&#039;&#039;10.1.0-27&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
|&lt;br /&gt;
| [[User:Yellows8|Yellows8]]&lt;br /&gt;
| [http://yls8.mtheall.com/3dsbrowserhax.php Install]&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
==Secondary Exploits==&lt;br /&gt;
Installation of these exploits requires a previously exploited system to install. After installation, they can be used on their own.&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot; border=&amp;quot;1&amp;quot;&lt;br /&gt;
!  Works on latest fw&lt;br /&gt;
!  Name&lt;br /&gt;
!  Supported firmwares&lt;br /&gt;
!  Requirements&lt;br /&gt;
!  Author&lt;br /&gt;
!  Install&lt;br /&gt;
|-&lt;br /&gt;
| style=&amp;quot;background: green&amp;quot; | Yes&lt;br /&gt;
| [[ironhax]]&lt;br /&gt;
| From &#039;&#039;&#039;9.5.0-X&#039;&#039;&#039; up to and including &#039;&#039;&#039;10.2.0-X&#039;&#039;&#039;, for &#039;&#039;&#039;X&#039;&#039;&#039; up to and including 28.&lt;br /&gt;
| A copy of &amp;quot;Ironfall: Invasion&amp;quot; downloaded from eShop before August 11th, 2015. Note the updated version that was released on October 13th, 2015 is not supported.&lt;br /&gt;
| smea&lt;br /&gt;
| [http://smealum.github.io/3ds/ Install]&lt;br /&gt;
|-&lt;br /&gt;
| style=&amp;quot;background: green&amp;quot; | Yes&lt;br /&gt;
| [https://github.com/yellows8/oot3dhax oot3dhax]&lt;br /&gt;
| From &#039;&#039;&#039;9.5.0-X&#039;&#039;&#039; up to and including &#039;&#039;&#039;10.2.0-X&#039;&#039;&#039;, for &#039;&#039;&#039;X&#039;&#039;&#039; up to and including 28.&lt;br /&gt;
| A gamecard or eShop-install of Legend of Zelda: Ocarina of Time 3D.&lt;br /&gt;
| Actual hax/payload: Yellows8/smea et all. Installer: Meladroit.&lt;br /&gt;
| [https://github.com/meladroit/oot3dhax_installer Installer]&lt;br /&gt;
|-&lt;br /&gt;
| style=&amp;quot;background: red&amp;quot; | No&lt;br /&gt;
| [[menuhax]]&lt;br /&gt;
| From &#039;&#039;&#039;9.0.0-X&#039;&#039;&#039; up to and including &#039;&#039;&#039;10.1.0-X&#039;&#039;&#039;, for &#039;&#039;&#039;X&#039;&#039;&#039; up to and including 27.&lt;br /&gt;
|&lt;br /&gt;
| [[User:Yellows8|Yellows8]]&lt;br /&gt;
| [https://github.com/yellows8/3ds_homemenuhax/releases Download]&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
==Exploits without Homebrew Launcher (Not recommended)==&lt;br /&gt;
&lt;br /&gt;
&amp;lt;u&amp;gt;&#039;&#039;&#039;Warning:&#039;&#039;&#039;&amp;lt;/u&amp;gt; The following exploits can run code, but are missing a 3DSX launcher. They cannot launch any homebrew in the 3DSX format.&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot; border=&amp;quot;1&amp;quot;&lt;br /&gt;
|-&lt;br /&gt;
!  Works on latest fw&lt;br /&gt;
!  Name&lt;br /&gt;
!  Supported firmwares&lt;br /&gt;
!  Requirements&lt;br /&gt;
!  Author&lt;br /&gt;
!  Install&lt;br /&gt;
|-&lt;br /&gt;
| style=&amp;quot;background: red&amp;quot; | No&lt;br /&gt;
| [[browserhax]] (Without the loader in the 3ds_browserhax_common repo)&lt;br /&gt;
| (Old3DS) From &#039;&#039;&#039;2.1.0-4&#039;&#039;&#039; to &#039;&#039;&#039;3.0.0-6&#039;&#039;&#039;, &#039;&#039;&#039;4.0.0-7&#039;&#039;&#039; to &#039;&#039;&#039;4.5.0-10&#039;&#039;&#039;, &#039;&#039;&#039;5.0.0-11&#039;&#039;&#039; to &#039;&#039;&#039;7.0.0-13&#039;&#039;&#039;, &#039;&#039;&#039;7.1.0-16&#039;&#039;&#039; to &#039;&#039;&#039;9.5.0-22&#039;&#039;&#039;, &#039;&#039;&#039;9.5.0-23&#039;&#039;&#039; to &#039;&#039;&#039;9.8.0-25&#039;&#039;&#039;, &#039;&#039;&#039;9.9.0-26&#039;&#039;&#039; to &#039;&#039;&#039;10.1.0-27&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
(New3DS) From &#039;&#039;&#039;9.0.0-20&#039;&#039;&#039; to &#039;&#039;&#039;9.2.0-20&#039;&#039;&#039;, &#039;&#039;&#039;9.3.0-21&#039;&#039;&#039; to &#039;&#039;&#039;9.5.0-23&#039;&#039;&#039;, &#039;&#039;&#039;9.6.0-24&#039;&#039;&#039; to &#039;&#039;&#039;9.8.0-25&#039;&#039;&#039;, &#039;&#039;&#039;9.9.0-26&#039;&#039;&#039; to &#039;&#039;&#039;10.1.0-27&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
See above section regarding [[10.2.0-28|10.2.0-X]].&lt;br /&gt;
|&lt;br /&gt;
| [[User:Yellows8|Yellows8]]&lt;br /&gt;
| [[browserhax|Install]]&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
==Previous Exploits==&lt;br /&gt;
&amp;lt;u&amp;gt;&#039;&#039;&#039;Warning:&#039;&#039;&#039;&amp;lt;/u&amp;gt; These exploits &#039;&#039;&#039;do not work&#039;&#039;&#039;. They are exploits which no longer function at all, regardless of software or firmware revision.&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot; border=&amp;quot;1&amp;quot;&lt;br /&gt;
!  Works on latest fw&lt;br /&gt;
! Name&lt;br /&gt;
! Supported firmwares&lt;br /&gt;
! Requirements&lt;br /&gt;
! Author&lt;br /&gt;
! Install&lt;br /&gt;
|-&lt;br /&gt;
| style=&amp;quot;background: red&amp;quot; | No&lt;br /&gt;
| [[tubehax|Tubehax]]&lt;br /&gt;
| None. &#039;&#039;&#039;Was&#039;&#039;&#039;: From &#039;&#039;&#039;9.0.0-X&#039;&#039;&#039; up to and including &#039;&#039;&#039;10.1.0-X&#039;&#039;&#039;, for &#039;&#039;&#039;X&#039;&#039;&#039; up to and including 27.&lt;br /&gt;
| 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]]).&lt;br /&gt;
| smea&lt;br /&gt;
| [http://smealum.github.io/3ds/ Install]&lt;br /&gt;
|}&lt;/div&gt;</summary>
		<author><name>Motezazer</name></author>
	</entry>
</feed>