https://www.3dbrew.org/w/api.php?action=feedcontributions&user=Myria&feedformat=atom3dbrew - User contributions [en]2024-03-29T15:59:39ZUser contributionsMediaWiki 1.35.8https://www.3dbrew.org/w/index.php?title=Serials&diff=21969Serials2022-09-26T02:34:51Z<p>Myria: /* Console Serial Numbers */ Brazil existence confirmed</p>
<hr />
<div>This page talks about the 3DS products' serial number and model number structures (the console, manual, accessories, games, etc...).<br />
<br />
== Console Serial Numbers ==<br />
<br />
A 3DS console serial number is composed of at least two letters followed by nine decimal digits. The ninth digit is a "check digit", meaning that it is derived from the other digits.<br />
<br />
The check digit is an industry-standard algorithm, the one used for UPC codes. To calculate the check digit of a 3DS console, separate the non-check digits into "odd" and "even" groups, where the "odd" group is digits in odd-numbered positions, and the "even" group is digits in even-numbered positions. (The first digit is "odd", with "first" representing "1".)<br />
<br />
After separating the digits, add the digits in each group together. Multiply the sum of the even digits by 3, then add the sum of the odd digits. To calculate the check digit, take this value modulo 10, and if not 0, subtract from 10.<br />
<br />
Example: CW404567772<br />
<br />
The non-check digits are 40456777. Separating into odd and even groups, we get the following:<br />
<br />
Odds: 4 + 4 + 6 + 7 = 21<br />
Evens: 0 + 5 + 7 + 7 = 19<br />
<br />
Applying the algorithm, we get ((3 * 19) + 21) % 10 = 8, which is not 0, thus 10 - 8 = 2, matching the example's check digit.<br />
<br />
The letter prefixes are a letter specifying the device, followed by one letter specifying the region in which it was sold. In some regions, a third letter is present; a current guess is that this letter distinguishes among factories for a given sales region. Note that several different sales regions' console may be considered to be the same region for region-locking purposes, such as Europe and Australia.<br />
<br />
The current serial number scheme began with the DSi, hence its listing in the tables below. Among standalone consoles, the Wii U belongs to this scheme as well; the Switch started a new scheme.<br />
<br />
{| class="wikitable"<br />
! Model !! Device Prefix (Retail) !! Device Prefix (Dev/Test)<br />
|-<br />
| ''DSi'' || T || V<br />
|-<br />
| ''DSi XL/LL'' || W || D<br />
|-<br />
| ''Nintendo Zone Box'' || Z || ''N/A''<br />
|-<br />
| ''Wii U'' || F || ''unknown''<br />
|-<br />
| ''Wii U gamepad'' || J || J<br />
|-<br />
| 3DS || C || E<br />
|-<br />
| 3DS XL/LL || S || R<br />
|-<br />
| 2DS || A || P<br />
|-<br />
| New 3DS || Y || Y<br />
|-<br />
| New 3DS XL/LL || Q || Q<br />
|-<br />
| New 2DS XL/LL || N || N<br />
|}<br />
<br />
Test ("Panda") units with the same prefix as retail can be distinguished by test units having 00 or 01 as the first two digits of the serial number portion. 00 was used with the New 3DS and New 3DS XL for test units; 01 was used with the New 2DS XL test unit. Preview versions of the N2DS XL given out to the press had 01; these appear to have been test units with the development titles deleted.<br />
<br />
Old 3DS development systems (Partner-CTR, IS-CTR-BOX, IS-SPR-BOX) use the "E" and "R" prefixes like test systems, but have 90 (Partner-CTR) or 91 (IS-CTR-BOX, IS-SPR-BOX) as their first two digits. Similarly, the main New 3DS development unit, IS-SNAKE-BOX, uses the Y prefix (same as retail) with 91. It is currently unknown what is the serial number format of the rare New 3DS XL development system (IS-CLOSER-BOX).<br />
<br />
{| class="wikitable"<br />
! Sales Region !! Region Lock !! Region Suffix<br />
|-<br />
| Japan || Japan || JF, JH, JM<br />
|-<br />
| North America || North America || W<br />
|-<br />
| Brazil || North America || B<br />
|-<br />
| Middle East / Southeast Asia || North America || S<br />
|-<br />
| Europe || Europe || EE, EF, EH, EM<br />
|-<br />
| Australia || Europe || AH, AG<br />
|-<br />
| South Korea || Korea || KF, KH, KM<br />
|-<br />
| China (iQue) || China || CF, CH, CM<br />
|}<br />
<br />
== Console Models ==<br />
<br />
{| class="wikitable"<br />
! Device !! Product Code<br />
|-<br />
| ''DS'' || NTR<br />
|-<br />
| ''DS lite'' || USG<br />
|-<br />
| ''DSi'' || TWL<br />
|-<br />
| ''DSi XL/LL'' || UTL<br />
|-<br />
| ''Wii U'' || WUP<br />
|-<br />
| 3DS || CTR<br />
|-<br />
| 3DS XL/LL || SPR<br />
|-<br />
| 2DS || FTR<br />
|-<br />
| [[New 3DS]] || KTR<br />
|-<br />
| [[New 3DS]] XL/LL || RED<br />
|-<br />
| New 2DS XL/LL || JAN<br />
|}<br />
<br />
The DS had the product code NTR (short for Nitro), so we see the TR is recurring.<br />
<br />
== Title ID and Unique ID ==<br />
''see [[Titles]]''<br />
<br />
== NCCH Product Code ==<br />
<br />
This serial is similiar to the "physical serial" described later in this page; it is the canonical identifier for a specific title in the field of business formalities with Nintendo, but this is not reflected in the 3DS's software architecture (where it is vastly unused in favor of the Title ID: it is therefore considered the successor of the "internal name" contained in ROMs of previous handhelds), is not guaranteed to be unique.<br />
<br />
The product code is located in a [[NCCH]]'s header (not its ExHeader).<br />
<br />
The product code "CTR-P-CTAP" is the default generic product code for NCCH files. Most [[NCSD|NCCHs apart from the first one]] in a title are generally CTR-P-CTAP.<br />
Referring to "the product code of a title" is therefore a simplification for "the product code of the NCCH in its first partition".<br />
<br />
So, for example, a Japanese copy of Ridge Racer 3D would have a product code of "CTR-P-ARRJ" and a serial of "LNA-CTR-ARRJ-JPN".<br />
<br />
A Nintendo-assigned product code follows this format, however, there is no requirement for a product code to match or resemble this structure as long as it's within the length limit:<br />
<br />
[CTR/KTR]-[Category letter]-[Type][Identifier][Region]-[Sub ID]<br />
<br />
{| class="wikitable"<br />
! Category letter !! Description<br />
|-<br />
| P || Cartridge software, or downloadable versions of them.<br />
|-<br />
| N || Digital-only releases, including [[Title list|system applications and applets]].<br />
|-<br />
| M || [[DLC]]<br />
|-<br />
| T || [[eShop Demos]], excluding so-called "special demos" which are category N.<br />
|-<br />
| U || [[Title list#0004000E - Add-on Content (Updates)|Patches]] for category P titles.<br />
|}<br />
<br />
The "sub ID" only applies to DLC, demos, and local copies of Download Play titles. It's a 2-digit number associated with the [[Title list|Title ID Variation]].<br />
<br />
See the next chapter for explanation of the other components of the Product Code.<br />
<br />
== Physical Serial ==<br />
[Product][Retail/Demo]-[Platform]-[Type][Game ID][Region]-[Label Region]<br />
<br />
{| class="wikitable"<br />
! Field !! Length !! Description !! colspan=2 | Values<br />
|-<br />
|-align=center<br />
| rowspan="6" | Product<br />
| rowspan="6" | 2<br />
| rowspan="6" | Product type<br />
|-<br />
| LN || Cartridge<br />
|-<br />
| MA || Instruction manual<br />
|-<br />
| TS || Game box<br />
|-<br />
| FA || Leaflet<br />
|-<br />
| MK || Quick-start Guide<br />
|-align=center<br />
| rowspan="3" | Retail/Demo<br />
| rowspan="3" | 1 <br />
| rowspan="3" |<br />
|-<br />
| A || Retail<br />
|-<br />
| Z || Demo<br />
|-align=center<br />
| rowspan="3" | CTR/KTR<br />
| rowspan="3" | 3<br />
| rowspan="3" | Platform<br />
|-<br />
| CTR || 3DS<br />
|-<br />
| KTR || New 3DS<br />
|-align=center<br />
| rowspan="11" | Type<br />
| rowspan="11" | 1<br />
| rowspan="11" | <br />
|-<br />
| A || retail<br />
|-<br />
| B || retail<br />
|-<br />
| C || used for N3DS exclusive retail and default 'CTAP'<br />
|-<br />
| E || used for card 2 type retail cartridges<br />
|-<br />
| H || used for built in applications like [[Mii Maker]]<br />
|-<br />
| J || normal eShop Title<br />
|-<br />
| K || normal eShop Title?<br />
|-<br />
| S || 3D Classics<br />
|-<br />
| P || used with GBA eShop titles<br />
|-<br />
| T || used with NES eShop titles<br />
|-align=center<br />
| Identifier<br />
| 2<br />
| colspan=3 |Game ID (two alphanumeric characters)<br />
|-align=center<br />
| rowspan="10" | Region<br />
| rowspan="10" | 1<br />
| rowspan="10" | <br />
|-<br />
| E || English (US)<br />
|-<br />
| P || PAL (Europe/Australia)<br />
|-<br />
| J || Japanese (Japan)<br />
|-<br />
| K || Korean (Korea)<br />
|-<br />
| C || Chinese (China/Taiwan)<br />
|-<br />
| Y || Multiple regions<br />
|-<br />
| W || Tai'''w'''an(?) (Taiwan/Hong Kong)<br />
|-<br />
| Z || Multiple regions<br />
|-<br />
| A || All (region-free)<br />
|-<br />
|-align=center<br />
| rowspan="12" | Label Region<br />
| rowspan="12" | 3<br />
| rowspan="12" | <br />
|-<br />
| USA || United States<br />
|-<br />
| EUR || Europe<br />
|-<br />
| CAN || Canada (US version with additional French text added to box)<br />
|-<br />
| AUS || Australia<br />
|-<br />
| JPN || Japan<br />
|-<br />
| KOR || Korea<br />
|-<br />
| TWN || Taiwan/Hong Kong<br />
|-<br />
| CHT || Taiwan/Hong Kong ("Chinese-Traditional")<br />
|-<br />
| CHN || China<br />
|-<br />
| UKV || United Kingdom ("United Kingdom version")<br />
|-<br />
| MDE || Saudi Arabia/U.A.E./Malaysia/Singapore ("Middle East")<br />
|}<br />
<br />
=== Electronic Manuals ===<br />
<br />
Some eShop titles have [[NCCH#CFA|Electronic Manuals]] which store the product code at the end of the 'Health & Safety' section of the manual. However, product codes can differ from the above format as shown below:<br />
<br />
CTR-[P/N/T/U]-[Type][Game ID][Region]-[Region]-[Digit]<br />
<br />
CTR-[Type][Game ID][Region]-[Region]-[Digit]<br />
<br />
* P/N/T/U - Same as in product code structure<br />
* [Type][Game ID][Region] - Same as in serial structure<br />
* [Region] - A three character representation of the title region, i.e. 'EUR' (not always present)<br />
* [Digit] - A single digit usually '1' or '0' (not always present). Possibly revision or manual revision.<br />
<br />
'''Note:''' These alternate versions of the product code, potentially found in [[NCCH#CFA|Electronic Manuals]] don't represent the actual product code, as found in the game's CXI. They are only found in the game's Home Menu manual, and on the game's packaging and external labeling.<br />
<br />
==Back of Card Serial==<br />
AREPY10111 (example)<br />
<br />
AAAABCDEEE<br/><br />
'''A''' - Identifier (last 4 digits of product code)<br/><br />
'''B''' - Production Month (numbers, then after Sep its X,Y,Z for Oct,Nov,Dec)<br/><br />
'''C''' - Production Year (2010 + C)*<br/><br />
'''D''' - Revision/Remaster Version (should match the main NCCH's Exheader Remaster Version)<br/><br />
'''E''' - Production Run? (000-999)**<br />
<br />
<nowiki>* </nowiki>Or (2020 + C), if produced in that decade. Example [https://www.youtube.com/watch?v=DcH8mK6yXj4 here] at the 2:10 mark.<br/><br />
<nowiki>** </nowiki>European demo/kiosk carts have "08B" or "08H"</div>Myriahttps://www.3dbrew.org/w/index.php?title=NCSD&diff=21960NCSD2022-09-10T23:03:57Z<p>Myria: deleted unwanted duplicate</p>
<hr />
<div>[[Category:File formats]]<br />
This page documents the format of NCSD.<br />
<br />
== Overview ==<br />
There are two known specialisations of the NCSD container format. The CTR Cart Image (CCI) format and the 3DS' raw [[Flash Filesystem#NAND structure|NAND format]]. CCI is the format of game ROM images.<br />
<br />
'''CTR System Update (CSU)''' is a variant of CCI, where the only difference is in the file extension. This is used with developer System Updates and associated [[3DS Development Unit Software|Tools]].<br />
<br />
<br />
NCSD images start with a NCSD header, followed by up to a maximum of 8 [[NCCH]] partitions.<br />
<br />
For CCI images, the partitions are reserved as follows:<br />
<br />
{| class="wikitable" border="1"<br />
|-<br />
! [[NCCH]] Index<br />
! Reserved Use<br />
|-<br />
| 0<br />
| Executable Content ([[NCCH#CXI|CXI]])<br />
|-<br />
| 1<br />
| E-Manual ([[NCCH#CFA|CFA]])<br />
|-<br />
| 2<br />
| [[Download Play]] Child container ([[NCCH#CFA|CFA]])<br />
|-<br />
| 6<br />
| New3DS [[System_Update_CFA|Update Data]] ([[NCCH#CFA|CFA]])<br />
|-<br />
| 7<br />
| [[System_Update_CFA|Update Data]] ([[NCCH#CFA|CFA]])<br />
|}<br />
<br />
The format of partitions can be determined from the partition FS flags (normally these are zero for CCI/CSU NCSD Images).<br />
<br />
== NCSD header ==<br />
{| class="wikitable" border="1"<br />
|-<br />
! Offset<br />
! Size<br />
! Description<br />
|-<br />
| 0x000<br />
| 0x100<br />
| RSA-2048 SHA-256 signature of the NCSD header<br />
|-<br />
| 0x100<br />
| 4<br />
| Magic Number 'NCSD'<br />
|-<br />
| 0x104<br />
| 4<br />
| Size of the NCSD image, in media units (1 media unit = 0x200 bytes)<br />
|-<br />
| 0x108<br />
| 8<br />
| Media ID<br />
|-<br />
| 0x110<br />
| 8<br />
| Partitions FS type (0=None, 1=Normal, 3=FIRM, 4=AGB_FIRM save)<br />
|-<br />
| 0x118<br />
| 8<br />
| Partitions crypt type (each byte corresponds to a partition in the partition table)<br />
|-<br />
| 0x120<br />
| 0x40=(4+4)*8<br />
| Offset & Length partition table, in media units<br />
|-<br />
| 0x160<br />
| 0xA0<br />
| ...<br />
|}<br />
<br />
For carts,<br />
{| class="wikitable" border="1"<br />
|-<br />
! Offset<br />
! Size<br />
! Description<br />
|-<br />
| 0x160<br />
| 0x20<br />
| Exheader SHA-256 hash<br />
|-<br />
| 0x180<br />
| 0x4<br />
| Additional header size<br />
|-<br />
| 0x184<br />
| 0x4<br />
| Sector zero offset<br />
|-<br />
| 0x188<br />
| 8<br />
| Partition Flags (See Below)<br />
|-<br />
| 0x190<br />
| 0x40=8*8<br />
| Partition ID table <br />
|-<br />
| 0x1D0<br />
| 0x20<br />
| Reserved<br />
|-<br />
| 0x1F0<br />
| 0xE<br />
| Reserved?<br />
|-<br />
| 0x1FE<br />
| 0x1<br />
| Support for this was implemented with [[9.6.0-24|9.6.0-X]] FIRM. Bit0=1 enables using bits 1-2, it's unknown what these two bits are actually used for(the value of these two bits get compared with some other value during NCSD verification/loading). This appears to enable a new, likely hardware-based, antipiracy check on cartridges.<br />
|-<br />
| 0x1FF<br />
| 0x1<br />
| Support for this was implemented with [[9.6.0-24|9.6.0-X]] FIRM, see below regarding save crypto.<br />
|}<br />
<br />
For NAND,<br />
<br />
{| class="wikitable" border="1"<br />
|-<br />
! Offset<br />
! Size<br />
! Description<br />
|-<br />
| 0x160<br />
| 0x5E<br />
| Unknown<br />
|-<br />
| 0x1BE<br />
| 0x42<br />
| Encrypted MBR partition-table, for the TWL partitions(key-data used for this keyslot is console-unique).<br />
|}<br />
<br />
=== NCSD Signature ===<br />
The RSA public key used for gamecard NCSD is stored in [[Memory_layout|ITCM]]. The separate public key used for NAND NCSD is stored in Process9 .(ro)data instead of ITCM, and in [[Bootloader|boot ROM]].<br />
<br />
For the boot ROM check, sighax may be used to fake-sign NAND headers. Process9's check will fail, however, unless patched.<br />
<br />
=== Partition Flags ===<br />
{| class="wikitable" border="1"<br />
|-<br />
! Byte Index<br />
! Description<br />
|-<br />
| 0<br />
| Backup Write Wait Time (The time to wait to write save to backup after the card is recognized (0-255 seconds)).NATIVE_FIRM loads this flag from the gamecard NCSD header starting with [[6.0.0-11]].<br />
|-<br />
| 3<br />
| Media Card Device (1 = NOR Flash, 2 = None, 3 = BT) (SDK 3.X+)<br />
|-<br />
| 4<br />
| Media Platform Index (1 = CTR)<br />
|-<br />
| 5<br />
| Media Type Index (0 = Inner Device, 1 = Card1, 2 = Card2, 3 = Extended Device)<br />
|-<br />
| 6<br />
| Media Unit Size i.e. u32 MediaUnitSize = 0x200*2^flags[6];<br />
|-<br />
| 7<br />
| Media Card Device (1 = NOR Flash, 2 = None, 3 = BT) (Only SDK 2.X)<br />
|}<br />
<br />
=== Partition Flags (In Terms of Save Crypto Determination) ===<br />
{| class="wikitable" border="1"<br />
|-<br />
! Byte Index<br />
! Description<br />
|-<br />
| 1<br />
| Starting with [[6.0.0-11]] NATIVE_FIRM will use this flag to determine the gamecard [[Savegames|savegame]] keyY method, when flag[3] is set. 0 = [[2.0.0-2]] hashed keyY, 1 = [[Savegames|new]] keyY method implemented with [[6.0.0-11]]. 0x0A = implemented with [[9.3.0-21|9.3.0-X]]. On Old3DS this is identical to the [[2.2.0-4]] crypto. On New3DS this is identical to the [[2.2.0-4]] crypto, except with New3DS-only gamecard savedata [[AES|keyslots]].<br />
Starting with [[9.6.0-24|9.6.0-X]] FIRM, Process9 now sets <savecrypto_stateval> to partitionflag[1] + <the u8 value from NCSD+0x1FF>, instead of just setting it to partitionflag[1].<br />
|-<br />
| 3<br />
| Support for this flag was implemented in NATIVE_FIRM with [[2.0.0-2]]. When this flag is set the hashed gamecard [[Savegames|savegame]] keyY method is used, this likely still uses the repeating-CTR however. With [[6.0.0-11]] the system will determine the gamecard savegame keyY method via flag[1], instead of just using the hashed keyY via this flag.<br />
|-th<br />
| 7<br />
| This flag enables using the hashed gamecard [[Savegames|savegame]] keyY method, support for this flag was implemented in NATIVE_FIRM with [[2.2.0-4]]. All games with the NCSD image finalized since [[2.2.0-4]](and contains [[2.2.0-4]]+ in the system update partition) have this flag set, this flag also enables using new CTR method as well.<br />
|}<br />
<br />
Starting with [[9.6.0-24|9.6.0-X]] FIRM, Process9 will just write val0 to a state field then return 0, instead of returning an error when the save crypto type isn't recognized. This was the *only* actual functionality change in the Old3DS Process9 function for gamecard savedata crypto init.<br />
<br />
== Card Info Header ==<br />
{| class="wikitable" border="1"<br />
|-<br />
! OFFSET<br />
! SIZE<br />
! DESCRIPTION<br />
|-<br />
| 0x200<br />
| 4<br />
| CARD2: Writable Address In Media Units (For 'On-Chip' Savedata). CARD1: Always 0xFFFFFFFF.<br />
|-<br />
| 0x204<br />
| 4<br />
| Card Info Bitmask<br />
|-<br />
| 0x208<br />
| 0xF8<br />
| Reserved<br />
|-<br />
| 0x300<br />
| 4<br />
| Filled size of cartridge<br />
|-<br />
| 0x304<br />
| 0xC<br />
| Reserved<br />
|-<br />
| 0x310<br />
| 2<br />
| Title version<br />
|-<br />
| 0x312<br />
| 2<br />
| Card revision<br />
|-<br />
| 0x314<br />
| 0xC<br />
| Reserved<br />
|-<br />
| 0x320<br />
| 8<br />
| Title ID of [[CVer]] in included update partition<br />
|-<br />
| 0x328<br />
| 2<br />
| Version number of [[CVer]] in included update partition<br />
|-<br />
| 0x32A<br />
| 0xCD6<br />
| Reserved<br />
|-<br />
| 0x1000<br />
| 0x10<br />
| Card seed keyY (first u64 is Media ID (same as first NCCH partitionId))<br />
|-<br />
| 0x1010<br />
| 0x10<br />
| Encrypted card seed (AES-CCM, keyslot 0x3B for retail cards, see [[CTRCARD_Registers|CTRCARD_SECSEED]])<br />
|-<br />
| 0x1020<br />
| 0x10<br />
| Card seed AES-MAC<br />
|-<br />
| 0x1030<br />
| 0xC<br />
| Card seed nonce<br />
|-<br />
| 0x103C<br />
| 0xC4<br />
| Reserved3<br />
|-<br />
| 0x1100<br />
| 0x100<br />
| Copy of first NCCH header (excluding RSA signature)<br />
|}<br />
<br />
== Development Card Info Header Extension ==<br />
{| class="wikitable" border="1"<br />
|-<br />
! OFFSET<br />
! SIZE<br />
! DESCRIPTION<br />
|-<br />
| 0x1200<br />
| 0x200<br />
| CardDeviceReserved1<br />
|-<br />
| 0x1400<br />
| 0x10<br />
| TitleKey<br />
|-<br />
| 0x1410<br />
| 0xF0<br />
| CardDeviceReserved2<br />
|-<br />
| 0x1500<br />
| 0x1B00<br />
| CardDeviceReserved3<br />
|-<br />
| 0x3000<br />
| 0x1000<br />
| Test pattern<br />
|}<br />
<br />
"TitleKey" is the decrypted version of the title key at 0x1000-0x103B ("Encrypted card seed"). This field appears to be what development--and maybe retail?--cards read to know what card encryption seed to use in the CTR protocol.<br />
<br />
Note that a particular flashcard vendor puts what many refer to as "private headers" here in place of actual development card information. This header is constituted by a cartridge-unique Id obtained from [[Process_Services_PXI|pxi:ps9::GetRomId]] and the title-unique cart ID (identical for all carts of the same title; can be retrieved using the NTR gamecard protocol command 0x90 or through the CTR protocol commands 0x90 or 0xA2).<br />
<br />
The CardDeviceReserved areas have random-looking data whose purpose is unknown, other than perhaps to hide the TitleKey.<br />
<br />
The test pattern is the same one encountered in development DS/DSi cartridges. Its layout is as follows:<br />
<br />
{| class="wikitable" border="1"<br />
|-<br />
! OFFSET<br />
! SIZE<br />
! DESCRIPTION<br />
|-<br />
| 0x3000<br />
| 8<br />
| The bytes FF,00,FF,00,AA,55,AA,55.<br />
|-<br />
| 0x3008<br />
| 0x1F8<br />
| An ascending byte sequence equal to the offset mod 256 (08,09,0A, ..., FE,FF,00,01, ..., FF).<br />
|-<br />
| 0x3200<br />
| 0x200<br />
| A descending byte sequence equal to 255 minus the offset mod 256 (FF,FE,FD, ..., 00,FF,DE, ..., 00).<br />
|-<br />
| 0x3400<br />
| 0x200<br />
| Filled with 00 bytes.<br />
|-<br />
| 0x3600<br />
| 0x200<br />
| Filled with FF bytes.<br />
|-<br />
| 0x3800<br />
| 0x200<br />
| Filled with 0F bytes.<br />
|-<br />
| 0x3A00<br />
| 0x200<br />
| Filled with F0 bytes.<br />
|-<br />
| 0x3C00<br />
| 0x200<br />
| Filled with 55 bytes.<br />
|-<br />
| 0x3E00<br />
| 0x1FF<br />
| Filled with AA bytes.<br />
|-<br />
| 0x3FFF<br />
| 1<br />
| The final byte is a 00.<br />
|}<br />
<br />
Retail cards always return FF when attempting to read 0x1200-0x3FFF. They probably actually have the same data as development cards, but there's no way to read it.<br />
<br />
== Tools ==<br />
<br />
[https://github.com/3dshax/ctr/tree/master/ctrtool ctrtool] - (CMD)(Windows/Linux) Parsing NCSD files<br />
<br />
[[3DSExplorer]] - (GUI)(Windows Only) Parsing NCSD files</div>Myriahttps://www.3dbrew.org/w/index.php?title=NCSD&diff=21959NCSD2022-09-10T23:01:14Z<p>Myria: /* Development Card Info Header Extension */ filled in a bunch of missing pieces</p>
<hr />
<div>[[Category:File formats]]<br />
This page documents the format of NCSD.<br />
<br />
== Overview ==<br />
There are two known specialisations of the NCSD container format. The CTR Cart Image (CCI) format and the 3DS' raw [[Flash Filesystem#NAND structure|NAND format]]. CCI is the format of game ROM images.<br />
<br />
'''CTR System Update (CSU)''' is a variant of CCI, where the only difference is in the file extension. This is used with developer System Updates and associated [[3DS Development Unit Software|Tools]].<br />
<br />
<br />
NCSD images start with a NCSD header, followed by up to a maximum of 8 [[NCCH]] partitions.<br />
<br />
For CCI images, the partitions are reserved as follows:<br />
<br />
{| class="wikitable" border="1"<br />
|-<br />
! [[NCCH]] Index<br />
! Reserved Use<br />
|-<br />
| 0<br />
| Executable Content ([[NCCH#CXI|CXI]])<br />
|-<br />
| 1<br />
| E-Manual ([[NCCH#CFA|CFA]])<br />
|-<br />
| 2<br />
| [[Download Play]] Child container ([[NCCH#CFA|CFA]])<br />
|-<br />
| 6<br />
| New3DS [[System_Update_CFA|Update Data]] ([[NCCH#CFA|CFA]])<br />
|-<br />
| 7<br />
| [[System_Update_CFA|Update Data]] ([[NCCH#CFA|CFA]])<br />
|}<br />
<br />
The format of partitions can be determined from the partition FS flags (normally these are zero for CCI/CSU NCSD Images).<br />
<br />
== NCSD header ==<br />
{| class="wikitable" border="1"<br />
|-<br />
! Offset<br />
! Size<br />
! Description<br />
|-<br />
| 0x000<br />
| 0x100<br />
| RSA-2048 SHA-256 signature of the NCSD header<br />
|-<br />
| 0x100<br />
| 4<br />
| Magic Number 'NCSD'<br />
|-<br />
| 0x104<br />
| 4<br />
| Size of the NCSD image, in media units (1 media unit = 0x200 bytes)<br />
|-<br />
| 0x108<br />
| 8<br />
| Media ID<br />
|-<br />
| 0x110<br />
| 8<br />
| Partitions FS type (0=None, 1=Normal, 3=FIRM, 4=AGB_FIRM save)<br />
|-<br />
| 0x118<br />
| 8<br />
| Partitions crypt type (each byte corresponds to a partition in the partition table)<br />
|-<br />
| 0x120<br />
| 0x40=(4+4)*8<br />
| Offset & Length partition table, in media units<br />
|-<br />
| 0x160<br />
| 0xA0<br />
| ...<br />
|}<br />
<br />
For carts,<br />
{| class="wikitable" border="1"<br />
|-<br />
! Offset<br />
! Size<br />
! Description<br />
|-<br />
| 0x160<br />
| 0x20<br />
| Exheader SHA-256 hash<br />
|-<br />
| 0x180<br />
| 0x4<br />
| Additional header size<br />
|-<br />
| 0x184<br />
| 0x4<br />
| Sector zero offset<br />
|-<br />
| 0x188<br />
| 8<br />
| Partition Flags (See Below)<br />
|-<br />
| 0x190<br />
| 0x40=8*8<br />
| Partition ID table <br />
|-<br />
| 0x1D0<br />
| 0x20<br />
| Reserved<br />
|-<br />
| 0x1F0<br />
| 0xE<br />
| Reserved?<br />
|-<br />
| 0x1FE<br />
| 0x1<br />
| Support for this was implemented with [[9.6.0-24|9.6.0-X]] FIRM. Bit0=1 enables using bits 1-2, it's unknown what these two bits are actually used for(the value of these two bits get compared with some other value during NCSD verification/loading). This appears to enable a new, likely hardware-based, antipiracy check on cartridges.<br />
|-<br />
| 0x1FF<br />
| 0x1<br />
| Support for this was implemented with [[9.6.0-24|9.6.0-X]] FIRM, see below regarding save crypto.<br />
|}<br />
<br />
For NAND,<br />
<br />
{| class="wikitable" border="1"<br />
|-<br />
! Offset<br />
! Size<br />
! Description<br />
|-<br />
| 0x160<br />
| 0x5E<br />
| Unknown<br />
|-<br />
| 0x1BE<br />
| 0x42<br />
| Encrypted MBR partition-table, for the TWL partitions(key-data used for this keyslot is console-unique).<br />
|}<br />
<br />
=== NCSD Signature ===<br />
The RSA public key used for gamecard NCSD is stored in [[Memory_layout|ITCM]]. The separate public key used for NAND NCSD is stored in Process9 .(ro)data instead of ITCM, and in [[Bootloader|boot ROM]].<br />
<br />
For the boot ROM check, sighax may be used to fake-sign NAND headers. Process9's check will fail, however, unless patched.<br />
<br />
=== Partition Flags ===<br />
{| class="wikitable" border="1"<br />
|-<br />
! Byte Index<br />
! Description<br />
|-<br />
| 0<br />
| Backup Write Wait Time (The time to wait to write save to backup after the card is recognized (0-255 seconds)).NATIVE_FIRM loads this flag from the gamecard NCSD header starting with [[6.0.0-11]].<br />
|-<br />
| 3<br />
| Media Card Device (1 = NOR Flash, 2 = None, 3 = BT) (SDK 3.X+)<br />
|-<br />
| 4<br />
| Media Platform Index (1 = CTR)<br />
|-<br />
| 5<br />
| Media Type Index (0 = Inner Device, 1 = Card1, 2 = Card2, 3 = Extended Device)<br />
|-<br />
| 6<br />
| Media Unit Size i.e. u32 MediaUnitSize = 0x200*2^flags[6];<br />
|-<br />
| 7<br />
| Media Card Device (1 = NOR Flash, 2 = None, 3 = BT) (Only SDK 2.X)<br />
|}<br />
<br />
=== Partition Flags (In Terms of Save Crypto Determination) ===<br />
{| class="wikitable" border="1"<br />
|-<br />
! Byte Index<br />
! Description<br />
|-<br />
| 1<br />
| Starting with [[6.0.0-11]] NATIVE_FIRM will use this flag to determine the gamecard [[Savegames|savegame]] keyY method, when flag[3] is set. 0 = [[2.0.0-2]] hashed keyY, 1 = [[Savegames|new]] keyY method implemented with [[6.0.0-11]]. 0x0A = implemented with [[9.3.0-21|9.3.0-X]]. On Old3DS this is identical to the [[2.2.0-4]] crypto. On New3DS this is identical to the [[2.2.0-4]] crypto, except with New3DS-only gamecard savedata [[AES|keyslots]].<br />
Starting with [[9.6.0-24|9.6.0-X]] FIRM, Process9 now sets <savecrypto_stateval> to partitionflag[1] + <the u8 value from NCSD+0x1FF>, instead of just setting it to partitionflag[1].<br />
|-<br />
| 3<br />
| Support for this flag was implemented in NATIVE_FIRM with [[2.0.0-2]]. When this flag is set the hashed gamecard [[Savegames|savegame]] keyY method is used, this likely still uses the repeating-CTR however. With [[6.0.0-11]] the system will determine the gamecard savegame keyY method via flag[1], instead of just using the hashed keyY via this flag.<br />
|-th<br />
| 7<br />
| This flag enables using the hashed gamecard [[Savegames|savegame]] keyY method, support for this flag was implemented in NATIVE_FIRM with [[2.2.0-4]]. All games with the NCSD image finalized since [[2.2.0-4]](and contains [[2.2.0-4]]+ in the system update partition) have this flag set, this flag also enables using new CTR method as well.<br />
|}<br />
<br />
Starting with [[9.6.0-24|9.6.0-X]] FIRM, Process9 will just write val0 to a state field then return 0, instead of returning an error when the save crypto type isn't recognized. This was the *only* actual functionality change in the Old3DS Process9 function for gamecard savedata crypto init.<br />
<br />
== Card Info Header ==<br />
{| class="wikitable" border="1"<br />
|-<br />
! OFFSET<br />
! SIZE<br />
! DESCRIPTION<br />
|-<br />
| 0x200<br />
| 4<br />
| CARD2: Writable Address In Media Units (For 'On-Chip' Savedata). CARD1: Always 0xFFFFFFFF.<br />
|-<br />
| 0x204<br />
| 4<br />
| Card Info Bitmask<br />
|-<br />
| 0x208<br />
| 0xF8<br />
| Reserved<br />
|-<br />
| 0x300<br />
| 4<br />
| Filled size of cartridge<br />
|-<br />
| 0x304<br />
| 0xC<br />
| Reserved<br />
|-<br />
| 0x310<br />
| 2<br />
| Title version<br />
|-<br />
| 0x312<br />
| 2<br />
| Card revision<br />
|-<br />
| 0x314<br />
| 0xC<br />
| Reserved<br />
|-<br />
| 0x320<br />
| 8<br />
| Title ID of [[CVer]] in included update partition<br />
|-<br />
| 0x328<br />
| 2<br />
| Version number of [[CVer]] in included update partition<br />
|-<br />
| 0x32A<br />
| 0xCD6<br />
| Reserved<br />
|-<br />
| 0x1000<br />
| 0x10<br />
| Card seed keyY (first u64 is Media ID (same as first NCCH partitionId))<br />
|-<br />
| 0x1010<br />
| 0x10<br />
| Encrypted card seed (AES-CCM, keyslot 0x3B for retail cards, see [[CTRCARD_Registers|CTRCARD_SECSEED]])<br />
|-<br />
| 0x1020<br />
| 0x10<br />
| Card seed AES-MAC<br />
|-<br />
| 0x1030<br />
| 0xC<br />
| Card seed nonce<br />
|-<br />
| 0x103C<br />
| 0xC4<br />
| Reserved3<br />
|-<br />
| 0x1100<br />
| 0x100<br />
| Copy of first NCCH header (excluding RSA signature)<br />
|}<br />
<br />
== Development Card Info Header Extension ==<br />
{| class="wikitable" border="1"<br />
|-<br />
! OFFSET<br />
! SIZE<br />
! DESCRIPTION<br />
|-<br />
| 0x1200<br />
| 0x200<br />
| CardDeviceReserved1<br />
|-<br />
| 0x1400<br />
| 0x10<br />
| TitleKey<br />
|-<br />
| 0x1410<br />
| 0xF0<br />
| CardDeviceReserved2<br />
|}<br />
<br />
== Development Card Info Header Extension ==<br />
{| class="wikitable" border="1"<br />
|-<br />
! OFFSET<br />
! SIZE<br />
! DESCRIPTION<br />
|-<br />
| 0x1200<br />
| 0x200<br />
| CardDeviceReserved1<br />
|-<br />
| 0x1400<br />
| 0x10<br />
| TitleKey<br />
|-<br />
| 0x1410<br />
| 0xF0<br />
| CardDeviceReserved2<br />
|-<br />
| 0x1500<br />
| 0x1B00<br />
| CardDeviceReserved3<br />
|-<br />
| 0x3000<br />
| 0x1000<br />
| Test pattern<br />
|}<br />
<br />
"TitleKey" is the decrypted version of the title key at 0x1000-0x103B ("Encrypted card seed"). This field appears to be what development--and maybe retail?--cards read to know what card encryption seed to use in the CTR protocol.<br />
<br />
Note that a particular flashcard vendor puts what many refer to as "private headers" here in place of actual development card information. This header is constituted by a cartridge-unique Id obtained from [[Process_Services_PXI|pxi:ps9::GetRomId]] and the title-unique cart ID (identical for all carts of the same title; can be retrieved using the NTR gamecard protocol command 0x90 or through the CTR protocol commands 0x90 or 0xA2).<br />
<br />
The CardDeviceReserved areas have random-looking data whose purpose is unknown, other than perhaps to hide the TitleKey.<br />
<br />
The test pattern is the same one encountered in development DS/DSi cartridges. Its layout is as follows:<br />
<br />
{| class="wikitable" border="1"<br />
|-<br />
! OFFSET<br />
! SIZE<br />
! DESCRIPTION<br />
|-<br />
| 0x3000<br />
| 8<br />
| The bytes FF,00,FF,00,AA,55,AA,55.<br />
|-<br />
| 0x3008<br />
| 0x1F8<br />
| An ascending byte sequence equal to the offset mod 256 (08,09,0A, ..., FE,FF,00,01, ..., FF).<br />
|-<br />
| 0x3200<br />
| 0x200<br />
| A descending byte sequence equal to 255 minus the offset mod 256 (FF,FE,FD, ..., 00,FF,DE, ..., 00).<br />
|-<br />
| 0x3400<br />
| 0x200<br />
| Filled with 00 bytes.<br />
|-<br />
| 0x3600<br />
| 0x200<br />
| Filled with FF bytes.<br />
|-<br />
| 0x3800<br />
| 0x200<br />
| Filled with 0F bytes.<br />
|-<br />
| 0x3A00<br />
| 0x200<br />
| Filled with F0 bytes.<br />
|-<br />
| 0x3C00<br />
| 0x200<br />
| Filled with 55 bytes.<br />
|-<br />
| 0x3E00<br />
| 0x1FF<br />
| Filled with AA bytes.<br />
|-<br />
| 0x3FFF<br />
| 1<br />
| The final byte is a 00.<br />
|}<br />
<br />
Retail cards always return FF when attempting to read 0x1200-0x3FFF. They probably actually have the same data as development cards, but there's no way to read it.<br />
<br />
== Tools ==<br />
<br />
[https://github.com/3dshax/ctr/tree/master/ctrtool ctrtool] - (CMD)(Windows/Linux) Parsing NCSD files<br />
<br />
[[3DSExplorer]] - (GUI)(Windows Only) Parsing NCSD files</div>Myriahttps://www.3dbrew.org/w/index.php?title=NCSD&diff=21958NCSD2022-09-10T22:44:44Z<p>Myria: /* Card Info Header */ added system update info</p>
<hr />
<div>[[Category:File formats]]<br />
This page documents the format of NCSD.<br />
<br />
== Overview ==<br />
There are two known specialisations of the NCSD container format. The CTR Cart Image (CCI) format and the 3DS' raw [[Flash Filesystem#NAND structure|NAND format]]. CCI is the format of game ROM images.<br />
<br />
'''CTR System Update (CSU)''' is a variant of CCI, where the only difference is in the file extension. This is used with developer System Updates and associated [[3DS Development Unit Software|Tools]].<br />
<br />
<br />
NCSD images start with a NCSD header, followed by up to a maximum of 8 [[NCCH]] partitions.<br />
<br />
For CCI images, the partitions are reserved as follows:<br />
<br />
{| class="wikitable" border="1"<br />
|-<br />
! [[NCCH]] Index<br />
! Reserved Use<br />
|-<br />
| 0<br />
| Executable Content ([[NCCH#CXI|CXI]])<br />
|-<br />
| 1<br />
| E-Manual ([[NCCH#CFA|CFA]])<br />
|-<br />
| 2<br />
| [[Download Play]] Child container ([[NCCH#CFA|CFA]])<br />
|-<br />
| 6<br />
| New3DS [[System_Update_CFA|Update Data]] ([[NCCH#CFA|CFA]])<br />
|-<br />
| 7<br />
| [[System_Update_CFA|Update Data]] ([[NCCH#CFA|CFA]])<br />
|}<br />
<br />
The format of partitions can be determined from the partition FS flags (normally these are zero for CCI/CSU NCSD Images).<br />
<br />
== NCSD header ==<br />
{| class="wikitable" border="1"<br />
|-<br />
! Offset<br />
! Size<br />
! Description<br />
|-<br />
| 0x000<br />
| 0x100<br />
| RSA-2048 SHA-256 signature of the NCSD header<br />
|-<br />
| 0x100<br />
| 4<br />
| Magic Number 'NCSD'<br />
|-<br />
| 0x104<br />
| 4<br />
| Size of the NCSD image, in media units (1 media unit = 0x200 bytes)<br />
|-<br />
| 0x108<br />
| 8<br />
| Media ID<br />
|-<br />
| 0x110<br />
| 8<br />
| Partitions FS type (0=None, 1=Normal, 3=FIRM, 4=AGB_FIRM save)<br />
|-<br />
| 0x118<br />
| 8<br />
| Partitions crypt type (each byte corresponds to a partition in the partition table)<br />
|-<br />
| 0x120<br />
| 0x40=(4+4)*8<br />
| Offset & Length partition table, in media units<br />
|-<br />
| 0x160<br />
| 0xA0<br />
| ...<br />
|}<br />
<br />
For carts,<br />
{| class="wikitable" border="1"<br />
|-<br />
! Offset<br />
! Size<br />
! Description<br />
|-<br />
| 0x160<br />
| 0x20<br />
| Exheader SHA-256 hash<br />
|-<br />
| 0x180<br />
| 0x4<br />
| Additional header size<br />
|-<br />
| 0x184<br />
| 0x4<br />
| Sector zero offset<br />
|-<br />
| 0x188<br />
| 8<br />
| Partition Flags (See Below)<br />
|-<br />
| 0x190<br />
| 0x40=8*8<br />
| Partition ID table <br />
|-<br />
| 0x1D0<br />
| 0x20<br />
| Reserved<br />
|-<br />
| 0x1F0<br />
| 0xE<br />
| Reserved?<br />
|-<br />
| 0x1FE<br />
| 0x1<br />
| Support for this was implemented with [[9.6.0-24|9.6.0-X]] FIRM. Bit0=1 enables using bits 1-2, it's unknown what these two bits are actually used for(the value of these two bits get compared with some other value during NCSD verification/loading). This appears to enable a new, likely hardware-based, antipiracy check on cartridges.<br />
|-<br />
| 0x1FF<br />
| 0x1<br />
| Support for this was implemented with [[9.6.0-24|9.6.0-X]] FIRM, see below regarding save crypto.<br />
|}<br />
<br />
For NAND,<br />
<br />
{| class="wikitable" border="1"<br />
|-<br />
! Offset<br />
! Size<br />
! Description<br />
|-<br />
| 0x160<br />
| 0x5E<br />
| Unknown<br />
|-<br />
| 0x1BE<br />
| 0x42<br />
| Encrypted MBR partition-table, for the TWL partitions(key-data used for this keyslot is console-unique).<br />
|}<br />
<br />
=== NCSD Signature ===<br />
The RSA public key used for gamecard NCSD is stored in [[Memory_layout|ITCM]]. The separate public key used for NAND NCSD is stored in Process9 .(ro)data instead of ITCM, and in [[Bootloader|boot ROM]].<br />
<br />
For the boot ROM check, sighax may be used to fake-sign NAND headers. Process9's check will fail, however, unless patched.<br />
<br />
=== Partition Flags ===<br />
{| class="wikitable" border="1"<br />
|-<br />
! Byte Index<br />
! Description<br />
|-<br />
| 0<br />
| Backup Write Wait Time (The time to wait to write save to backup after the card is recognized (0-255 seconds)).NATIVE_FIRM loads this flag from the gamecard NCSD header starting with [[6.0.0-11]].<br />
|-<br />
| 3<br />
| Media Card Device (1 = NOR Flash, 2 = None, 3 = BT) (SDK 3.X+)<br />
|-<br />
| 4<br />
| Media Platform Index (1 = CTR)<br />
|-<br />
| 5<br />
| Media Type Index (0 = Inner Device, 1 = Card1, 2 = Card2, 3 = Extended Device)<br />
|-<br />
| 6<br />
| Media Unit Size i.e. u32 MediaUnitSize = 0x200*2^flags[6];<br />
|-<br />
| 7<br />
| Media Card Device (1 = NOR Flash, 2 = None, 3 = BT) (Only SDK 2.X)<br />
|}<br />
<br />
=== Partition Flags (In Terms of Save Crypto Determination) ===<br />
{| class="wikitable" border="1"<br />
|-<br />
! Byte Index<br />
! Description<br />
|-<br />
| 1<br />
| Starting with [[6.0.0-11]] NATIVE_FIRM will use this flag to determine the gamecard [[Savegames|savegame]] keyY method, when flag[3] is set. 0 = [[2.0.0-2]] hashed keyY, 1 = [[Savegames|new]] keyY method implemented with [[6.0.0-11]]. 0x0A = implemented with [[9.3.0-21|9.3.0-X]]. On Old3DS this is identical to the [[2.2.0-4]] crypto. On New3DS this is identical to the [[2.2.0-4]] crypto, except with New3DS-only gamecard savedata [[AES|keyslots]].<br />
Starting with [[9.6.0-24|9.6.0-X]] FIRM, Process9 now sets <savecrypto_stateval> to partitionflag[1] + <the u8 value from NCSD+0x1FF>, instead of just setting it to partitionflag[1].<br />
|-<br />
| 3<br />
| Support for this flag was implemented in NATIVE_FIRM with [[2.0.0-2]]. When this flag is set the hashed gamecard [[Savegames|savegame]] keyY method is used, this likely still uses the repeating-CTR however. With [[6.0.0-11]] the system will determine the gamecard savegame keyY method via flag[1], instead of just using the hashed keyY via this flag.<br />
|-th<br />
| 7<br />
| This flag enables using the hashed gamecard [[Savegames|savegame]] keyY method, support for this flag was implemented in NATIVE_FIRM with [[2.2.0-4]]. All games with the NCSD image finalized since [[2.2.0-4]](and contains [[2.2.0-4]]+ in the system update partition) have this flag set, this flag also enables using new CTR method as well.<br />
|}<br />
<br />
Starting with [[9.6.0-24|9.6.0-X]] FIRM, Process9 will just write val0 to a state field then return 0, instead of returning an error when the save crypto type isn't recognized. This was the *only* actual functionality change in the Old3DS Process9 function for gamecard savedata crypto init.<br />
<br />
== Card Info Header ==<br />
{| class="wikitable" border="1"<br />
|-<br />
! OFFSET<br />
! SIZE<br />
! DESCRIPTION<br />
|-<br />
| 0x200<br />
| 4<br />
| CARD2: Writable Address In Media Units (For 'On-Chip' Savedata). CARD1: Always 0xFFFFFFFF.<br />
|-<br />
| 0x204<br />
| 4<br />
| Card Info Bitmask<br />
|-<br />
| 0x208<br />
| 0xF8<br />
| Reserved<br />
|-<br />
| 0x300<br />
| 4<br />
| Filled size of cartridge<br />
|-<br />
| 0x304<br />
| 0xC<br />
| Reserved<br />
|-<br />
| 0x310<br />
| 2<br />
| Title version<br />
|-<br />
| 0x312<br />
| 2<br />
| Card revision<br />
|-<br />
| 0x314<br />
| 0xC<br />
| Reserved<br />
|-<br />
| 0x320<br />
| 8<br />
| Title ID of [[CVer]] in included update partition<br />
|-<br />
| 0x328<br />
| 2<br />
| Version number of [[CVer]] in included update partition<br />
|-<br />
| 0x32A<br />
| 0xCD6<br />
| Reserved<br />
|-<br />
| 0x1000<br />
| 0x10<br />
| Card seed keyY (first u64 is Media ID (same as first NCCH partitionId))<br />
|-<br />
| 0x1010<br />
| 0x10<br />
| Encrypted card seed (AES-CCM, keyslot 0x3B for retail cards, see [[CTRCARD_Registers|CTRCARD_SECSEED]])<br />
|-<br />
| 0x1020<br />
| 0x10<br />
| Card seed AES-MAC<br />
|-<br />
| 0x1030<br />
| 0xC<br />
| Card seed nonce<br />
|-<br />
| 0x103C<br />
| 0xC4<br />
| Reserved3<br />
|-<br />
| 0x1100<br />
| 0x100<br />
| Copy of first NCCH header (excluding RSA signature)<br />
|}<br />
<br />
== Development Card Info Header Extension ==<br />
{| class="wikitable" border="1"<br />
|-<br />
! OFFSET<br />
! SIZE<br />
! DESCRIPTION<br />
|-<br />
| 0x1200<br />
| 0x200<br />
| CardDeviceReserved1<br />
|-<br />
| 0x1400<br />
| 0x10<br />
| TitleKey<br />
|-<br />
| 0x1410<br />
| 0xF0<br />
| CardDeviceReserved2<br />
|}<br />
<br />
Note that a particular flashcard vendor puts what many refer to as "private headers" here in place of actual development card information. This header is constituted by a cartridge-unique Id obtained from [[Process_Services_PXI|pxi:ps9::GetRomId]] and the title-unique cart ID (identical for all carts of the same title; can be retrieved using the NTR gamecard protocol command 0x90 or through the CTR protocol commands 0x90 or 0xA2).<br />
<br />
== Tools ==<br />
<br />
[https://github.com/3dshax/ctr/tree/master/ctrtool ctrtool] - (CMD)(Windows/Linux) Parsing NCSD files<br />
<br />
[[3DSExplorer]] - (GUI)(Windows Only) Parsing NCSD files</div>Myriahttps://www.3dbrew.org/w/index.php?title=NCSD&diff=21957NCSD2022-09-10T22:05:02Z<p>Myria: /* NCSD Signature */ mention sighax and boot ROM</p>
<hr />
<div>[[Category:File formats]]<br />
This page documents the format of NCSD.<br />
<br />
== Overview ==<br />
There are two known specialisations of the NCSD container format. The CTR Cart Image (CCI) format and the 3DS' raw [[Flash Filesystem#NAND structure|NAND format]]. CCI is the format of game ROM images.<br />
<br />
'''CTR System Update (CSU)''' is a variant of CCI, where the only difference is in the file extension. This is used with developer System Updates and associated [[3DS Development Unit Software|Tools]].<br />
<br />
<br />
NCSD images start with a NCSD header, followed by up to a maximum of 8 [[NCCH]] partitions.<br />
<br />
For CCI images, the partitions are reserved as follows:<br />
<br />
{| class="wikitable" border="1"<br />
|-<br />
! [[NCCH]] Index<br />
! Reserved Use<br />
|-<br />
| 0<br />
| Executable Content ([[NCCH#CXI|CXI]])<br />
|-<br />
| 1<br />
| E-Manual ([[NCCH#CFA|CFA]])<br />
|-<br />
| 2<br />
| [[Download Play]] Child container ([[NCCH#CFA|CFA]])<br />
|-<br />
| 6<br />
| New3DS [[System_Update_CFA|Update Data]] ([[NCCH#CFA|CFA]])<br />
|-<br />
| 7<br />
| [[System_Update_CFA|Update Data]] ([[NCCH#CFA|CFA]])<br />
|}<br />
<br />
The format of partitions can be determined from the partition FS flags (normally these are zero for CCI/CSU NCSD Images).<br />
<br />
== NCSD header ==<br />
{| class="wikitable" border="1"<br />
|-<br />
! Offset<br />
! Size<br />
! Description<br />
|-<br />
| 0x000<br />
| 0x100<br />
| RSA-2048 SHA-256 signature of the NCSD header<br />
|-<br />
| 0x100<br />
| 4<br />
| Magic Number 'NCSD'<br />
|-<br />
| 0x104<br />
| 4<br />
| Size of the NCSD image, in media units (1 media unit = 0x200 bytes)<br />
|-<br />
| 0x108<br />
| 8<br />
| Media ID<br />
|-<br />
| 0x110<br />
| 8<br />
| Partitions FS type (0=None, 1=Normal, 3=FIRM, 4=AGB_FIRM save)<br />
|-<br />
| 0x118<br />
| 8<br />
| Partitions crypt type (each byte corresponds to a partition in the partition table)<br />
|-<br />
| 0x120<br />
| 0x40=(4+4)*8<br />
| Offset & Length partition table, in media units<br />
|-<br />
| 0x160<br />
| 0xA0<br />
| ...<br />
|}<br />
<br />
For carts,<br />
{| class="wikitable" border="1"<br />
|-<br />
! Offset<br />
! Size<br />
! Description<br />
|-<br />
| 0x160<br />
| 0x20<br />
| Exheader SHA-256 hash<br />
|-<br />
| 0x180<br />
| 0x4<br />
| Additional header size<br />
|-<br />
| 0x184<br />
| 0x4<br />
| Sector zero offset<br />
|-<br />
| 0x188<br />
| 8<br />
| Partition Flags (See Below)<br />
|-<br />
| 0x190<br />
| 0x40=8*8<br />
| Partition ID table <br />
|-<br />
| 0x1D0<br />
| 0x20<br />
| Reserved<br />
|-<br />
| 0x1F0<br />
| 0xE<br />
| Reserved?<br />
|-<br />
| 0x1FE<br />
| 0x1<br />
| Support for this was implemented with [[9.6.0-24|9.6.0-X]] FIRM. Bit0=1 enables using bits 1-2, it's unknown what these two bits are actually used for(the value of these two bits get compared with some other value during NCSD verification/loading). This appears to enable a new, likely hardware-based, antipiracy check on cartridges.<br />
|-<br />
| 0x1FF<br />
| 0x1<br />
| Support for this was implemented with [[9.6.0-24|9.6.0-X]] FIRM, see below regarding save crypto.<br />
|}<br />
<br />
For NAND,<br />
<br />
{| class="wikitable" border="1"<br />
|-<br />
! Offset<br />
! Size<br />
! Description<br />
|-<br />
| 0x160<br />
| 0x5E<br />
| Unknown<br />
|-<br />
| 0x1BE<br />
| 0x42<br />
| Encrypted MBR partition-table, for the TWL partitions(key-data used for this keyslot is console-unique).<br />
|}<br />
<br />
=== NCSD Signature ===<br />
The RSA public key used for gamecard NCSD is stored in [[Memory_layout|ITCM]]. The separate public key used for NAND NCSD is stored in Process9 .(ro)data instead of ITCM, and in [[Bootloader|boot ROM]].<br />
<br />
For the boot ROM check, sighax may be used to fake-sign NAND headers. Process9's check will fail, however, unless patched.<br />
<br />
=== Partition Flags ===<br />
{| class="wikitable" border="1"<br />
|-<br />
! Byte Index<br />
! Description<br />
|-<br />
| 0<br />
| Backup Write Wait Time (The time to wait to write save to backup after the card is recognized (0-255 seconds)).NATIVE_FIRM loads this flag from the gamecard NCSD header starting with [[6.0.0-11]].<br />
|-<br />
| 3<br />
| Media Card Device (1 = NOR Flash, 2 = None, 3 = BT) (SDK 3.X+)<br />
|-<br />
| 4<br />
| Media Platform Index (1 = CTR)<br />
|-<br />
| 5<br />
| Media Type Index (0 = Inner Device, 1 = Card1, 2 = Card2, 3 = Extended Device)<br />
|-<br />
| 6<br />
| Media Unit Size i.e. u32 MediaUnitSize = 0x200*2^flags[6];<br />
|-<br />
| 7<br />
| Media Card Device (1 = NOR Flash, 2 = None, 3 = BT) (Only SDK 2.X)<br />
|}<br />
<br />
=== Partition Flags (In Terms of Save Crypto Determination) ===<br />
{| class="wikitable" border="1"<br />
|-<br />
! Byte Index<br />
! Description<br />
|-<br />
| 1<br />
| Starting with [[6.0.0-11]] NATIVE_FIRM will use this flag to determine the gamecard [[Savegames|savegame]] keyY method, when flag[3] is set. 0 = [[2.0.0-2]] hashed keyY, 1 = [[Savegames|new]] keyY method implemented with [[6.0.0-11]]. 0x0A = implemented with [[9.3.0-21|9.3.0-X]]. On Old3DS this is identical to the [[2.2.0-4]] crypto. On New3DS this is identical to the [[2.2.0-4]] crypto, except with New3DS-only gamecard savedata [[AES|keyslots]].<br />
Starting with [[9.6.0-24|9.6.0-X]] FIRM, Process9 now sets <savecrypto_stateval> to partitionflag[1] + <the u8 value from NCSD+0x1FF>, instead of just setting it to partitionflag[1].<br />
|-<br />
| 3<br />
| Support for this flag was implemented in NATIVE_FIRM with [[2.0.0-2]]. When this flag is set the hashed gamecard [[Savegames|savegame]] keyY method is used, this likely still uses the repeating-CTR however. With [[6.0.0-11]] the system will determine the gamecard savegame keyY method via flag[1], instead of just using the hashed keyY via this flag.<br />
|-th<br />
| 7<br />
| This flag enables using the hashed gamecard [[Savegames|savegame]] keyY method, support for this flag was implemented in NATIVE_FIRM with [[2.2.0-4]]. All games with the NCSD image finalized since [[2.2.0-4]](and contains [[2.2.0-4]]+ in the system update partition) have this flag set, this flag also enables using new CTR method as well.<br />
|}<br />
<br />
Starting with [[9.6.0-24|9.6.0-X]] FIRM, Process9 will just write val0 to a state field then return 0, instead of returning an error when the save crypto type isn't recognized. This was the *only* actual functionality change in the Old3DS Process9 function for gamecard savedata crypto init.<br />
<br />
== Card Info Header ==<br />
{| class="wikitable" border="1"<br />
|-<br />
! OFFSET<br />
! SIZE<br />
! DESCRIPTION<br />
|-<br />
| 0x200<br />
| 4<br />
| CARD2: Writable Address In Media Units (For 'On-Chip' Savedata). CARD1: Always 0xFFFFFFFF.<br />
|-<br />
| 0x204<br />
| 4<br />
| Card Info Bitmask<br />
|-<br />
| 0x208<br />
| 0x108<br />
| Reserved1<br />
|-<br />
| 0x310<br />
| 2<br />
| Title version<br />
|-<br />
| 0x312<br />
| 2<br />
| Card revision<br />
|-<br />
| 0x208<br />
| 0xCEE<br />
| Reserved2<br />
|-<br />
| 0x1000<br />
| 0x10<br />
| Card seed keyY (first u64 is Media ID (same as first NCCH partitionId))<br />
|-<br />
| 0x1010<br />
| 0x10<br />
| Encrypted card seed (AES-CCM, keyslot 0x3B for retail cards, see [[CTRCARD_Registers|CTRCARD_SECSEED]])<br />
|-<br />
| 0x1020<br />
| 0x10<br />
| Card seed AES-MAC<br />
|-<br />
| 0x1030<br />
| 0xC<br />
| Card seed nonce<br />
|-<br />
| 0x103C<br />
| 0xC4<br />
| Reserved3<br />
|-<br />
| 0x1100<br />
| 0x100<br />
| Copy of first NCCH header (excluding RSA signature)<br />
|}<br />
<br />
== Development Card Info Header Extension ==<br />
{| class="wikitable" border="1"<br />
|-<br />
! OFFSET<br />
! SIZE<br />
! DESCRIPTION<br />
|-<br />
| 0x1200<br />
| 0x200<br />
| CardDeviceReserved1<br />
|-<br />
| 0x1400<br />
| 0x10<br />
| TitleKey<br />
|-<br />
| 0x1410<br />
| 0xF0<br />
| CardDeviceReserved2<br />
|}<br />
<br />
Note that a particular flashcard vendor puts what many refer to as "private headers" here in place of actual development card information. This header is constituted by a cartridge-unique Id obtained from [[Process_Services_PXI|pxi:ps9::GetRomId]] and the title-unique cart ID (identical for all carts of the same title; can be retrieved using the NTR gamecard protocol command 0x90 or through the CTR protocol commands 0x90 or 0xA2).<br />
<br />
== Tools ==<br />
<br />
[https://github.com/3dshax/ctr/tree/master/ctrtool ctrtool] - (CMD)(Windows/Linux) Parsing NCSD files<br />
<br />
[[3DSExplorer]] - (GUI)(Windows Only) Parsing NCSD files</div>Myriahttps://www.3dbrew.org/w/index.php?title=CTCert&diff=21581CTCert2021-09-07T02:51:12Z<p>Myria: better layout; delete redundant sentence</p>
<hr />
<div>=Summary=<br />
The console-unique CTCert is used for signing [[Title Data Structure|CTX]] files, the DeviceCert used by [[eShop]], and for [[DSiWare_Exports|DSiWare]] exports. This ECDSA signature, the ECDSA private key for this cert, and the IssuerID is loaded from memory initialized by bootrom instead of NAND. This is the 3DS equivalent of the DSi TWCert.<br />
<br />
The CTCert is signed with ECDSA by Nintendo. CTCerts can be verified via a DER stored in NATIVE_FIRM, separate DERs are used for retail and dev/debug.<br />
<br />
=Structure=<br />
{| class="wikitable" border="1"<br />
! Offset<br />
! Size<br />
! Description<br />
|-<br />
| 0x00<br />
| 0x04<br />
| [[Certificates|Signature]] Type, 0x010005.<br />
|-<br />
| 0x04<br />
| 0x3C<br />
| ECDSA Signature using Nintendo's private key, in big-endian. The first 0x1E bytes are "r"; the second 0x1E bytes are "s". The hash is SHA-256 computed over this certificate, starting at byte 0x80 ("Cert Issue ID") to the end.<br />
|-<br />
| 0x40<br />
| 0x40<br />
| Padding<br />
|-<br />
| 0x80<br />
| 0x40<br />
| Cert Issuer ID, for retail this is "Nintendo CA - G3_NintendoCTR2prod", for dev "Nintendo CA - G3_NintendoCTR2dev"<br />
|-<br />
| 0xC0<br />
| 0x04<br />
| Key Type<br />
|-<br />
| 0xC4<br />
| 0x40<br />
| Key ID: "CT<DeviceId>-<ConsoleType>", where DeviceId is the hex [[PSPXI:GetDeviceId|DeviceId]], and ConsoleType is 00 for retail, 01 for dev<br />
|-<br />
| 0x104<br />
| 0x04<br />
| Expiration time as UNIX Timestamp in big endian.<br />
|-<br />
| 0x108<br />
| 0x3C<br />
| ECDSA Public Key of this console as a curve point in big-endian. The first 0x1E bytes are "x" of this point; the second 0x1E bytes are "y".<br />
|-<br />
| 0x144<br />
| 0x3C<br />
| Padding<br />
|}<br />
<br />
Boot ROM decrypts [[OTP Registers]] and writes the private key and Nintendo's signature of CTCert to [[Memory_layout#ARM9_ITCM|ARM9 ITCM]]; the public key is computed from the private key.<br />
<br />
The curve used for ECDSA is sect233r1.</div>Myriahttps://www.3dbrew.org/w/index.php?title=CTCert&diff=21580CTCert2021-09-07T02:49:46Z<p>Myria: fix links</p>
<hr />
<div>=Summary=<br />
The console-unique CTCert is used for signing [[Title Data Structure|CTX]] files, the DeviceCert used by [[eShop]], and for [[DSiWare_Exports|DSiWare]] exports. This ECDSA signature, the ECDSA private key for this cert, and the IssuerID is loaded from memory initialized by bootrom instead of NAND. This is the 3DS equivalent of the DSi TWCert.<br />
<br />
The CTCert is signed with ECDSA by Nintendo. CTCerts can be verified via a DER stored in NATIVE_FIRM, separate DERs are used for retail and dev/debug.<br />
<br />
=Structure=<br />
{| class="wikitable" border="1"<br />
! Offset<br />
! Size<br />
! Description<br />
|-<br />
| 0x00<br />
| 0x04<br />
| [[Certificates|Signature]] Type, 0x010005.<br />
|-<br />
| 0x04<br />
| 0x3C<br />
| ECDSA Signature using Nintendo's private key, in big-endian. The first 0x1E bytes are "r"; the second 0x1E bytes are "s". The hash is SHA-256 computed over this certificate, starting at byte 0x80 ("Cert Issue ID") to the end.<br />
|-<br />
| 0x40<br />
| 0x40<br />
| Padding<br />
|-<br />
| 0x80<br />
| 0x40<br />
| Cert Issuer ID, for retail this is "Nintendo CA - G3_NintendoCTR2prod", for dev "Nintendo CA - G3_NintendoCTR2dev"<br />
|-<br />
| 0xC0<br />
| 0x04<br />
| Key Type<br />
|-<br />
| 0xC4<br />
| 0x40<br />
| Key ID: "CT<DeviceId>-<ConsoleType>", where DeviceId is the hex [[PSPXI:GetDeviceId|DeviceId]], and ConsoleType is 00 for retail, 01 for dev<br />
|-<br />
| 0x104<br />
| 0x04<br />
| Expiration time as UNIX Timestamp in big endian.<br />
|-<br />
| 0x108<br />
| 0x3C<br />
| ECDSA Public Key of this console as a curve point in big-endian. The first 0x1E bytes are "x" of this point; the second 0x1E bytes are "y".<br />
|-<br />
| 0x144<br />
| 0x3C<br />
| Padding<br />
|}<br />
<br />
The ECDSA public key for this cert is calculated from the ECDSA private key initialized by bootrom. Boot ROM decrypts [[OTP Registers]] and writes the private key and Nintendo's signature of this certificate to [[Memory_layout#ARM9_ITCM|ARM9 ITCM]]; the public key is computed from the private key.<br />
The curve used for ECDSA is sect233r1.</div>Myriahttps://www.3dbrew.org/w/index.php?title=CTCert&diff=21579CTCert2021-09-07T02:48:24Z<p>Myria: More accurate description of ECDSA stuff</p>
<hr />
<div>=Summary=<br />
The console-unique CTCert is used for signing [[Title Data Structure|CTX]] files, the DeviceCert used by [[eShop]], and for [[DSiWare_Exports|DSiWare]] exports. This ECDSA signature, the ECDSA private key for this cert, and the IssuerID is loaded from memory initialized by bootrom instead of NAND. This is the 3DS equivalent of the DSi TWCert.<br />
<br />
The CTCert is signed with ECDSA by Nintendo. CTCerts can be verified via a DER stored in NATIVE_FIRM, separate DERs are used for retail and dev/debug.<br />
<br />
=Structure=<br />
{| class="wikitable" border="1"<br />
! Offset<br />
! Size<br />
! Description<br />
|-<br />
| 0x00<br />
| 0x04<br />
| [[Certificates|Signature]] Type, 0x010005.<br />
|-<br />
| 0x04<br />
| 0x3C<br />
| ECDSA Signature using Nintendo's private key, in big-endian. The first 0x1E bytes are "r"; the second 0x1E bytes are "s". The hash is SHA-256 computed over this certificate, starting at byte 0x80 ("Cert Issue ID") to the end.<br />
|-<br />
| 0x40<br />
| 0x40<br />
| Padding<br />
|-<br />
| 0x80<br />
| 0x40<br />
| Cert Issuer ID, for retail this is "Nintendo CA - G3_NintendoCTR2prod", for dev "Nintendo CA - G3_NintendoCTR2dev"<br />
|-<br />
| 0xC0<br />
| 0x04<br />
| Key Type<br />
|-<br />
| 0xC4<br />
| 0x40<br />
| Key ID: "CT<DeviceId>-<ConsoleType>", where DeviceId is the hex [[PSPXI:GetDeviceId|DeviceId]], and ConsoleType is 00 for retail, 01 for dev<br />
|-<br />
| 0x104<br />
| 0x04<br />
| Expiration time as UNIX Timestamp in big endian.<br />
|-<br />
| 0x108<br />
| 0x3C<br />
| ECDSA Public Key of this console as a curve point in big-endian. The first 0x1E bytes are "x" of this point; the second 0x1E bytes are "y".<br />
|-<br />
| 0x144<br />
| 0x3C<br />
| Padding<br />
|}<br />
<br />
The ECDSA public key for this cert is calculated from the ECDSA private key initialized by bootrom. Boot ROM decrypts [[OTP]] and writes the private key and Nintendo's signature of this certificate to [[ITCM]]; the public key is computed from the private key.<br />
The curve used for ECDSA is sect233r1.</div>Myriahttps://www.3dbrew.org/w/index.php?title=Serials&diff=21332Serials2020-09-12T04:08:28Z<p>Myria: /* Console Serial Numbers */ debug DSi XL is D</p>
<hr />
<div>This page talks about the 3DS products' serial number and model number structures (the console, manual, accessories, games, etc...).<br />
<br />
== Console Serial Numbers ==<br />
<br />
A 3DS console serial number is composed of at least two letters followed by nine decimal digits. The ninth digit is a "check digit", meaning that it is derived from the other digits.<br />
<br />
The check digit is an industry-standard algorithm, the one used for UPC codes. To calculate the check digit of a 3DS console, separate the non-check digits into "odd" and "even" groups, where the "odd" group is digits in odd-numbered positions, and the "even" group is digits in even-numbered positions. (The first digit is "odd", with "first" representing "1".)<br />
<br />
After separating the digits, add the digits in each group together. Multiply the sum of the even digits by 3, then add the sum of the odd digits. To calculate the check digit, take this value modulo 10, and if not 0, subtract from 10.<br />
<br />
Example: CW404567772<br />
<br />
The non-check digits are 40456777. Separating into odd and even groups, we get the following:<br />
<br />
Odds: 4 + 4 + 6 + 7 = 21<br />
Evens: 0 + 5 + 7 + 7 = 19<br />
<br />
Applying the algorithm, we get ((3 * 19) + 21) % 10 = 8, which is not 0, thus 10 - 8 = 2, matching the example's check digit.<br />
<br />
The letter prefixes are a letter specifying the device, followed by one letter specifying the region in which it was sold. In some regions, a third letter is present; a current guess is that this letter distinguishes among factories for a given sales region. Note that several different sales regions' console may be considered to be the same region for region-locking purposes, such as Europe and Australia.<br />
<br />
The current serial number scheme began with the DSi, hence its listing in the tables below. Among standalone consoles, the Wii U belongs to this scheme as well; the Switch started a new scheme.<br />
<br />
{| class="wikitable"<br />
! Model !! Device Prefix (Retail) !! Device Prefix (Dev/Test)<br />
|-<br />
| ''DSi'' || T || V<br />
|-<br />
| ''DSi XL/LL'' || W || D<br />
|-<br />
| ''Nintendo Zone Box'' || Z || ''N/A''<br />
|-<br />
| ''Wii U'' || F || ''unknown''<br />
|-<br />
| ''Wii U gamepad'' || J || J<br />
|-<br />
| 3DS || C || E<br />
|-<br />
| 3DS XL/LL || S || R<br />
|-<br />
| 2DS || A || P<br />
|-<br />
| New 3DS || Y || Y<br />
|-<br />
| New 3DS XL/LL || Q || Q<br />
|-<br />
| New 2DS XL/LL || N || N<br />
|}<br />
<br />
Test ("Panda") units with the same prefix as retail can be distinguished by test units having 00 or 01 as the first two digits of the serial number portion. 00 was used with the New 3DS and New 3DS XL for test units; 01 was used with the New 2DS XL test unit. Preview versions of the N2DS XL given out to the press had 01; these appear to have been test units with the development titles deleted.<br />
<br />
Old 3DS development systems (Partner-CTR, IS-CTR-BOX, IS-SPR-BOX) use the "E" and "R" prefixes like test systems, but have 90 (Partner-CTR) or 91 (IS-CTR-BOX, IS-SPR-BOX) as their first two digits. Similarly, the main New 3DS development unit, IS-SNAKE-BOX, uses the Y prefix (same as retail) with 91. It is currently unknown what is the serial number format of the rare New 3DS XL development system (IS-CLOSER-BOX).<br />
<br />
{| class="wikitable"<br />
! Sales Region !! Region Lock !! Region Suffix<br />
|-<br />
| Japan || Japan || JF, JH, JM<br />
|-<br />
| North America || North America || W<br />
|-<br />
| Middle East / Southeast Asia || North America || S<br />
|-<br />
| Europe || Europe || EF, EH, EM<br />
|-<br />
| Australia || Europe || AH, AG<br />
|-<br />
| South Korea || Korea || KF, KH, KM<br />
|-<br />
| China (iQue) || China || CF, CH, CM<br />
|}<br />
<br />
== Console Models ==<br />
<br />
{| class="wikitable"<br />
! Device !! Product Code<br />
|-<br />
| ''DS'' || NTR<br />
|-<br />
| ''DS lite'' || USG<br />
|-<br />
| ''DSi'' || TWL<br />
|-<br />
| ''DSi XL/LL'' || UTL<br />
|-<br />
| ''Wii U'' || WUP<br />
|-<br />
| 3DS || CTR<br />
|-<br />
| 3DS XL/LL || SPR<br />
|-<br />
| 2DS || FTR<br />
|-<br />
| [[New 3DS]] || KTR<br />
|-<br />
| [[New 3DS]] XL/LL || RED<br />
|-<br />
| New 2DS XL/LL || JAN<br />
|}<br />
<br />
The DS had the product code NTR (short for Nitro), so we see the TR is recurring.<br />
<br />
== Title ID and Unique ID ==<br />
''see [[Titles]]''<br />
<br />
== NCCH Product Code ==<br />
<br />
This serial is similiar to the "physical serial" described later in this page; it is the canonical identifier for a specific title in the field of business formalities with Nintendo, but this is not reflected in the 3DS's software architecture (where it is vastly unused in favor of the Title ID: it is therefore considered the successor of the "internal name" contained in ROMs of previous handhelds), is not guaranteed to be unique.<br />
<br />
The product code is located in a [[NCCH]]'s header (not its ExHeader).<br />
<br />
The product code "CTR-P-CTAP" is the default generic product code for NCCH files. Most [[NCSD|NCCHs apart from the first one]] in a title are generally CTR-P-CTAP.<br />
Referring to "the product code of a title" is therefore a simplification for "the product code of the NCCH in its first partition".<br />
<br />
So, for example, a Japanese copy of Ridge Racer 3D would have a product code of "CTR-P-ARRJ" and a serial of "LNA-CTR-ARRJ-JPN".<br />
<br />
A Nintendo-assigned product code follows this format, however, there is no requirement for a product code to match or resemble this structure as long as it's within the length limit:<br />
<br />
[CTR/KTR]-[Category letter]-[Type][Identifier][Region]-[Sub ID]<br />
<br />
{| class="wikitable"<br />
! Category letter !! Description<br />
|-<br />
| P || Cartridge software, or downloadable versions of them.<br />
|-<br />
| N || Digital-only releases, including [[Title list|system applications and applets]].<br />
|-<br />
| M || [[DLC]]<br />
|-<br />
| T || [[eShop Demos]], excluding so-called "special demos" which are category N.<br />
|-<br />
| U || [[Title list#0004000E - Add-on Content (Updates)|Patches]] for category P titles.<br />
|}<br />
<br />
The "sub ID" only applies to DLC, demos, and local copies of Download Play titles. It's a 2-digit number associated with the [[Title list|Title ID Variation]].<br />
<br />
See the next chapter for explanation of the other components of the Product Code.<br />
<br />
== Physical Serial ==<br />
[Product][Retail/Demo]-[Platform]-[Type][Game ID][Region]-[Label Region]<br />
<br />
{| class="wikitable"<br />
! Field !! Length !! Description !! colspan=2 | Values<br />
|-<br />
|-align=center<br />
| rowspan="6" | Product<br />
| rowspan="6" | 2<br />
| rowspan="6" | Product type<br />
|-<br />
| LN || Cartridge<br />
|-<br />
| MA || Instruction manual<br />
|-<br />
| TS || Game box<br />
|-<br />
| FA || Leaflet<br />
|-<br />
| MK || Quick-start Guide<br />
|-align=center<br />
| rowspan="3" | Retail/Demo<br />
| rowspan="3" | 1 <br />
| rowspan="3" |<br />
|-<br />
| A || Retail<br />
|-<br />
| Z || Demo<br />
|-align=center<br />
| rowspan="3" | CTR/KTR<br />
| rowspan="3" | 3<br />
| rowspan="3" | Platform<br />
|-<br />
| CTR || 3DS<br />
|-<br />
| KTR || New 3DS<br />
|-align=center<br />
| rowspan="11" | Type<br />
| rowspan="11" | 1<br />
| rowspan="11" | <br />
|-<br />
| A || retail<br />
|-<br />
| B || retail<br />
|-<br />
| C || used for N3DS exclusive retail and default 'CTAP'<br />
|-<br />
| E || used for card 2 type retail cartridges<br />
|-<br />
| H || used for built in applications like [[Mii Maker]]<br />
|-<br />
| J || normal eShop Title<br />
|-<br />
| K || normal eShop Title?<br />
|-<br />
| S || 3D Classics<br />
|-<br />
| P || used with GBA eShop titles<br />
|-<br />
| T || used with NES eShop titles<br />
|-align=center<br />
| Identifier<br />
| 2<br />
| colspan=3 |Game ID (two alphanumeric characters)<br />
|-align=center<br />
| rowspan="10" | Region<br />
| rowspan="10" | 1<br />
| rowspan="10" | <br />
|-<br />
| E || English (US)<br />
|-<br />
| P || PAL (Europe/Australia)<br />
|-<br />
| J || Japanese (Japan)<br />
|-<br />
| K || Korean (Korea)<br />
|-<br />
| C || Chinese (China/Taiwan)<br />
|-<br />
| Y || Multiple regions<br />
|-<br />
| W || Tai'''w'''an(?) (Taiwan/Hong Kong)<br />
|-<br />
| Z || Multiple regions<br />
|-<br />
| A || All (region-free)<br />
|-<br />
|-align=center<br />
| rowspan="12" | Label Region<br />
| rowspan="12" | 3<br />
| rowspan="12" | <br />
|-<br />
| USA || United States<br />
|-<br />
| EUR || Europe<br />
|-<br />
| CAN || Canada (US version with additional French text added to box)<br />
|-<br />
| AUS || Australia<br />
|-<br />
| JPN || Japan<br />
|-<br />
| KOR || Korea<br />
|-<br />
| TWN || Taiwan/Hong Kong<br />
|-<br />
| CHT || Taiwan/Hong Kong ("Chinese-Traditional")<br />
|-<br />
| CHN || China<br />
|-<br />
| UKV || United Kingdom ("United Kingdom version")<br />
|-<br />
| MDE || Saudi Arabia/U.A.E./Malaysia/Singapore ("Middle East")<br />
|}<br />
<br />
=== Electronic Manuals ===<br />
<br />
Some eShop titles have [[NCCH#CFA|Electronic Manuals]] which store the product code at the end of the 'Health & Safety' section of the manual. However, product codes can differ from the above format as shown below:<br />
<br />
CTR-[P/N/T/U]-[Type][Game ID][Region]-[Region]-[Digit]<br />
<br />
CTR-[Type][Game ID][Region]-[Region]-[Digit]<br />
<br />
* P/N/T/U - Same as in product code structure<br />
* [Type][Game ID][Region] - Same as in serial structure<br />
* [Region] - A three character representation of the title region, i.e. 'EUR' (not always present)<br />
* [Digit] - A single digit usually '1' or '0' (not always present). Possibly revision or manual revision.<br />
<br />
'''Note:''' These alternate versions of the product code, potentially found in [[NCCH#CFA|Electronic Manuals]] don't represent the actual product code, as found in the game's CXI. They are only found in the game's Home Menu manual, and on the game's packaging and external labeling.<br />
<br />
==Back of Card Serial==<br />
AREPY10111 (example)<br />
<br />
AAAABCDEEE<br/><br />
'''A''' - Identifier (last 4 digits of product code)<br/><br />
'''B''' - Production Month (numbers, then after Sep its X,Y,Z for Oct,Nov,Dec)<br/><br />
'''C''' - Production Year (2010 + C)<br/><br />
'''D''' - Revision/Remaster Version (should match the main NCCH's Exheader Remaster Version)<br/><br />
'''E''' - Production Run? (000-999)*<br />
<br />
<nowiki>*</nowiki>European demo/kiosk carts have "08B" or "08H"</div>Myriahttps://www.3dbrew.org/w/index.php?title=Serials&diff=21287Serials2020-06-06T02:27:04Z<p>Myria: /* Console Serial Numbers */ Nintendo Zone Box</p>
<hr />
<div>This page talks about the 3DS products' serial number and model number structures (the console, manual, accessories, games, etc...).<br />
<br />
== Console Serial Numbers ==<br />
<br />
A 3DS console serial number is composed of at least two letters followed by nine decimal digits. The ninth digit is a "check digit", meaning that it is derived from the other digits.<br />
<br />
The check digit is an industry-standard algorithm, the one used for UPC codes. To calculate the check digit of a 3DS console, separate the non-check digits into "odd" and "even" groups, where the "odd" group is digits in odd-numbered positions, and the "even" group is digits in even-numbered positions. (The first digit is "odd", with "first" representing "1".)<br />
<br />
After separating the digits, add the digits in each group together. Multiply the sum of the even digits by 3, then add the sum of the odd digits. To calculate the check digit, take this value modulo 10, and if not 0, subtract from 10.<br />
<br />
Example: CW404567772<br />
<br />
The non-check digits are 40456777. Separating into odd and even groups, we get the following:<br />
<br />
Odds: 4 + 4 + 6 + 7 = 21<br />
Evens: 0 + 5 + 7 + 7 = 19<br />
<br />
Applying the algorithm, we get ((3 * 19) + 21) % 10 = 8, which is not 0, thus 10 - 8 = 2, matching the example's check digit.<br />
<br />
The letter prefixes are a letter specifying the device, followed by one letter specifying the region in which it was sold. In some regions, a third letter is present; a current guess is that this letter distinguishes among factories for a given sales region. Note that several different sales regions' console may be considered to be the same region for region-locking purposes, such as Europe and Australia.<br />
<br />
The current serial number scheme began with the DSi, hence its listing in the tables below. Among standalone consoles, the Wii U belongs to this scheme as well; the Switch started a new scheme.<br />
<br />
{| class="wikitable"<br />
! Model !! Device Prefix (Retail) !! Device Prefix (Dev/Test)<br />
|-<br />
| ''DSi'' || T || V<br />
|-<br />
| ''DSi XL/LL'' || W || ''unknown''<br />
|-<br />
| ''Nintendo Zone Box'' || Z || ''N/A''<br />
|-<br />
| ''Wii U'' || F || ''unknown''<br />
|-<br />
| ''Wii U gamepad'' || J || J<br />
|-<br />
| 3DS || C || E<br />
|-<br />
| 3DS XL/LL || S || R<br />
|-<br />
| 2DS || A || P<br />
|-<br />
| New 3DS || Y || Y<br />
|-<br />
| New 3DS XL/LL || Q || Q<br />
|-<br />
| New 2DS XL/LL || N || N<br />
|}<br />
<br />
Test ("Panda") units with the same prefix as retail can be distinguished by test units having 00 or 01 as the first two digits of the serial number portion. 00 was used with the New 3DS and New 3DS XL for test units; 01 was used with the New 2DS XL test unit. Preview versions of the N2DS XL given out to the press had 01; these appear to have been test units with the development titles deleted.<br />
<br />
Old 3DS development systems (Partner-CTR, IS-CTR-BOX, IS-SPR-BOX) use the "E" and "R" prefixes like test systems, but have 90 (Partner-CTR) or 91 (IS-CTR-BOX, IS-SPR-BOX) as their first two digits. Similarly, the main New 3DS development unit, IS-SNAKE-BOX, uses the Y prefix (same as retail) with 91. It is currently unknown what is the serial number format of the rare New 3DS XL development system (IS-CLOSER-BOX).<br />
<br />
{| class="wikitable"<br />
! Sales Region !! Region Lock !! Region Suffix<br />
|-<br />
| Japan || Japan || JF, JH, JM<br />
|-<br />
| North America || North America || W<br />
|-<br />
| Middle East / Southeast Asia || North America || S<br />
|-<br />
| Europe || Europe || EF, EH, EM<br />
|-<br />
| Australia || Europe || AH, AG<br />
|-<br />
| South Korea || Korea || KF, KH, KM<br />
|-<br />
| China (iQue) || China || CF, CH, CM<br />
|}<br />
<br />
== Console Models ==<br />
<br />
{| class="wikitable"<br />
! Device !! Product Code<br />
|-<br />
| ''DS'' || NTR<br />
|-<br />
| ''DS lite'' || USG<br />
|-<br />
| ''DSi'' || TWL<br />
|-<br />
| ''DSi XL/LL'' || UTL<br />
|-<br />
| ''Wii U'' || WUP<br />
|-<br />
| 3DS || CTR<br />
|-<br />
| 3DS XL/LL || SPR<br />
|-<br />
| 2DS || FTR<br />
|-<br />
| [[New 3DS]] || KTR<br />
|-<br />
| [[New 3DS]] XL/LL || RED<br />
|-<br />
| New 2DS XL/LL || JAN<br />
|}<br />
<br />
The DS had the product code NTR (short for Nitro), so we see the TR is recurring.<br />
<br />
== Title ID and Unique ID ==<br />
''see [[Titles]]''<br />
<br />
== NCCH Product Code ==<br />
<br />
This serial is similiar to the "physical serial" described later in this page; it is the canonical identifier for a specific title in the field of business formalities with Nintendo, but this is not reflected in the 3DS's software architecture (where it is vastly unused in favor of the Title ID: it is therefore considered the successor of the "internal name" contained in ROMs of previous handhelds), is not guaranteed to be unique.<br />
<br />
The product code is located in a [[NCCH]]'s header (not its ExHeader).<br />
<br />
The product code "CTR-P-CTAP" is the default generic product code for NCCH files. Most [[NCSD|NCCHs apart from the first one]] in a title are generally CTR-P-CTAP.<br />
Referring to "the product code of a title" is therefore a simplification for "the product code of the NCCH in its first partition".<br />
<br />
So, for example, a Japanese copy of Ridge Racer 3D would have a product code of "CTR-P-ARRJ" and a serial of "LNA-CTR-ARRJ-JPN".<br />
<br />
A Nintendo-assigned product code follows this format, however, there is no requirement for a product code to match or resemble this structure as long as it's within the length limit:<br />
<br />
[CTR/KTR]-[Category letter]-[Type][Identifier][Region]-[Sub ID]<br />
<br />
{| class="wikitable"<br />
! Category letter !! Description<br />
|-<br />
| P || Cartridge software, or downloadable versions of them.<br />
|-<br />
| N || Digital-only releases, including [[Title list|system applications and applets]].<br />
|-<br />
| M || [[DLC]]<br />
|-<br />
| T || [[eShop Demos]], excluding so-called "special demos" which are category N.<br />
|-<br />
| U || [[Title list#0004000E - Add-on Content (Updates)|Patches]] for category P titles.<br />
|}<br />
<br />
The "sub ID" only applies to DLC, demos, and local copies of Download Play titles. It's a 2-digit number associated with the [[Title list|Title ID Variation]].<br />
<br />
See the next chapter for explanation of the other components of the Product Code.<br />
<br />
== Physical Serial ==<br />
[Product][Retail/Demo]-[Platform]-[Type][Game ID][Region]-[Label Region]<br />
<br />
{| class="wikitable"<br />
! Field !! Length !! Description !! colspan=2 | Values<br />
|-<br />
|-align=center<br />
| rowspan="6" | Product<br />
| rowspan="6" | 2<br />
| rowspan="6" | Product type<br />
|-<br />
| LN || Cartridge<br />
|-<br />
| MA || Instruction manual<br />
|-<br />
| TS || Game box<br />
|-<br />
| FA || Leaflet<br />
|-<br />
| MK || Quick-start Guide<br />
|-align=center<br />
| rowspan="3" | Retail/Demo<br />
| rowspan="3" | 1 <br />
| rowspan="3" |<br />
|-<br />
| A || Retail<br />
|-<br />
| Z || Demo<br />
|-align=center<br />
| rowspan="3" | CTR/KTR<br />
| rowspan="3" | 3<br />
| rowspan="3" | Platform<br />
|-<br />
| CTR || 3DS<br />
|-<br />
| KTR || New 3DS<br />
|-align=center<br />
| rowspan="11" | Type<br />
| rowspan="11" | 1<br />
| rowspan="11" | <br />
|-<br />
| A || retail<br />
|-<br />
| B || retail<br />
|-<br />
| C || used for N3DS exclusive retail and default 'CTAP'<br />
|-<br />
| E || used for card 2 type retail cartridges<br />
|-<br />
| H || used for built in applications like [[Mii Maker]]<br />
|-<br />
| J || normal eShop Title<br />
|-<br />
| K || normal eShop Title?<br />
|-<br />
| S || 3D Classics<br />
|-<br />
| P || used with GBA eShop titles<br />
|-<br />
| T || used with NES eShop titles<br />
|-align=center<br />
| Identifier<br />
| 2<br />
| colspan=3 |Game ID (two alphanumeric characters)<br />
|-align=center<br />
| rowspan="10" | Region<br />
| rowspan="10" | 1<br />
| rowspan="10" | <br />
|-<br />
| E || English (US)<br />
|-<br />
| P || PAL (Europe/Australia)<br />
|-<br />
| J || Japanese (Japan)<br />
|-<br />
| K || Korean (Korea)<br />
|-<br />
| C || Chinese (China/Taiwan)<br />
|-<br />
| Y || Multiple regions<br />
|-<br />
| W || Tai'''w'''an(?) (Taiwan/Hong Kong)<br />
|-<br />
| Z || Multiple regions<br />
|-<br />
| A || All (region-free)<br />
|-<br />
|-align=center<br />
| rowspan="12" | Label Region<br />
| rowspan="12" | 3<br />
| rowspan="12" | <br />
|-<br />
| USA || United States<br />
|-<br />
| EUR || Europe<br />
|-<br />
| CAN || Canada (US version with additional French text added to box)<br />
|-<br />
| AUS || Australia<br />
|-<br />
| JPN || Japan<br />
|-<br />
| KOR || Korea<br />
|-<br />
| TWN || Taiwan/Hong Kong<br />
|-<br />
| CHT || Taiwan/Hong Kong ("Chinese-Traditional")<br />
|-<br />
| CHN || China<br />
|-<br />
| UKV || United Kingdom ("United Kingdom version")<br />
|-<br />
| MDE || Saudi Arabia/U.A.E./Malaysia/Singapore ("Middle East")<br />
|}<br />
<br />
=== Electronic Manuals ===<br />
<br />
Some eShop titles have [[NCCH#CFA|Electronic Manuals]] which store the product code at the end of the 'Health & Safety' section of the manual. However, product codes can differ from the above format as shown below:<br />
<br />
CTR-[P/N/T/U]-[Type][Game ID][Region]-[Region]-[Digit]<br />
<br />
CTR-[Type][Game ID][Region]-[Region]-[Digit]<br />
<br />
* P/N/T/U - Same as in product code structure<br />
* [Type][Game ID][Region] - Same as in serial structure<br />
* [Region] - A three character representation of the title region, i.e. 'EUR' (not always present)<br />
* [Digit] - A single digit usually '1' or '0' (not always present). Possibly revision or manual revision.<br />
<br />
'''Note:''' These alternate versions of the product code, potentially found in [[NCCH#CFA|Electronic Manuals]] don't represent the actual product code, as found in the game's CXI. They are only found in the game's Home Menu manual, and on the game's packaging and external labeling.<br />
<br />
==Back of Card Serial==<br />
AREPY10111 (example)<br />
<br />
AAAABCDEEE<br/><br />
'''A''' - Identifier (last 4 digits of product code)<br/><br />
'''B''' - Production Month (X,Y,Z -> Oct,Nov,Dec)<br/><br />
'''C''' - Production Year (2010 + C)<br/><br />
'''D''' - Revision/Remaster Version (should match the main NCCH's Exheader Remaster Version)<br/><br />
'''E''' - Production Run? (000-999)*<br />
<br />
<nowiki>*</nowiki>European demo/kiosk carts have "08B" or "08H"</div>Myriahttps://www.3dbrew.org/w/index.php?title=3DS_System_Flaws&diff=208163DS System Flaws2018-08-21T04:14:35Z<p>Myria: CFG_SYSPROT9 -> CFG9_SYSPROT9 to match CONFIG Registers page</p>
<hr />
<div>Exploits are used to execute unofficial code (homebrew) on the Nintendo 3DS. This page is a list of publicly known system flaws, for userland applications/applets flaws see [[3DS_Userland_Flaws|here]].<br />
<br />
=Stale / Rejected Efforts=<br />
* Neimod has been working on a RAM dumping setup for a little while now. He's de-soldered the 3DS's RAM chip and hooked it and the RAM pinouts on the 3DS' PCB up to a custom RAM dumping setup. A while ago he published photos showing his setup to be working quite well, with the 3DS successfully booting up. However, his flickr stream is now private along with most of his work.<br />
<br />
* Someone (who will remain unnamed) has released CFW and CIA installers, all of which is copied from the work of others, or copyrighted material.<br />
<br />
==Tips and info==<br />
The 3DS uses the XN feature of the ARM11 processor. There's no official way from applications to enable executable permission for memory containing arbitrary unsigned code(there's a [[SVC]] for this, but only [[RO_Services|RO-module]] has access to it). A usable userland exploit would still be useful: you could only do return-oriented-programming with it initially. From ROP one could then exploit system flaw(s), see below.<br />
<br />
SD card [[extdata]] and SD savegames can be attacked, for consoles where the console-unique [[Nand/private/movable.sed|movable.sed]] was dumped(accessing SD data is far easier by running code on the target 3DS however).<br />
<br />
=System flaws=<br />
== Hardware ==<br />
{| class="wikitable" border="1"<br />
! Summary<br />
! Description<br />
! Fixed with hardware model/revision<br />
! Newest hardware model/revision this flaw was checked for<br />
! Timeframe this was discovered<br />
! Discovered by<br />
|-<br />
| ARM9/ARM11 bootrom vectors point at uninitialized RAM<br />
| ARM9's and ARM11's exception vectors are hardcoded to point at the CPU's internal memory (0x08000000 region for ARM9, AXIWRAM for ARM11). While the bootrom does set them up to point to an endless loop at some point during boot, it does not do so immediately. As such, a carefully-timed fault injection (via hardware) to trigger an exception (such as an invalid instruction) will cause execution to fall into ARM9 RAM. <br />
Since RAM isn't cleared on boot (see below), one can immediately start execution of their own code here to dump bootrom, OTP, etc.<br />
The ARM9 bootrom does the following at reset: reset vector branches to another instruction, then branches to bootrom+0x8000. Hence, there's no way to know for certain when exactly the ARM9 exception-vector data stored in memory gets initialized.<br />
<br />
This requires *very* *precise* timing for triggering the hardware fault.<br />
<br />
It has been exploited by derrek to dump the ARM9 bootrom as of Summer 2015.<br />
| None: all available 3DS models at the time of writing have the exact same ARM9/ARM11 bootrom for the unprotected areas.<br />
| New3DS<br />
| End of February 2014<br />
| [[User:Derrek|derrek]], WulfyStylez (May 2015) independently<br />
|-<br />
| Missing AES key clearing<br />
| The hardware AES engine does not clear keys when doing a hard reset/reboot.<br />
| None<br />
| New3DS<br />
| August 2014<br />
| Mathieulh/Others<br />
|-<br />
| No RAM clearing on reboots<br />
| On an MCU-triggered reboot all RAM including FCRAM/ARM9 memory/AXIWRAM/VRAM keeps its contents.<br />
| None<br />
| New3DS<br />
| March 2014<br />
| [[User:Derrek|derrek]]<br />
|-<br />
| 32bits of actual console-unique TWLNAND keydata<br />
| On retail the 8-bytes at ARM9 address [[Memory_layout|0x01FFB808]] are XORed with hard-coded data, to generate the TWL console-unique keys, including TWLNAND. On Old3DS the high u32 is always 0x0, while on New3DS that u32 is always 0x2. On top of this, the lower u32's highest bit is always ORed. only 31 bits of the TWL console-unique keydata / TWL consoleID are actually console-unique.<br />
This allows one to easily bruteforce the TWL console-unique keydata with *just* data from TWLNAND. On DSi the actual console-unique data for key generation is 8-bytes(all bytes actually set).<br />
| None<br />
| New3DS<br />
| 2012?<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| DSi / 3DS-TWL key-generator<br />
| After using the key generator to generate the normal-key, you could overwrite parts of the normal-key with your own data and then recover the key-generator output by comparing the new crypto output with the original crypto output. From the normal-key outputs, you could deduce the TWL key-generator function.<br />
This applies to the keyX/keyY too.<br />
<br />
This attack does not work for the 3DS key-generator because keyslots 0-3 are only for TWL keys.<br />
| None<br />
| New3DS<br />
| 2011<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| 3DS key-generator<br />
| The algorithm for generating the normal-keys for keyslots is cryptographically weak. As a result, it is easily susceptible to differential cryptanalysis if the normal-key corresponding to any scrambler-generated keyslot is discovered.<br />
<br />
Several such pairs of matching normal-keys and KeyY values were found, leading to deducing the key-generator function.<br />
| None<br />
| New3DS<br />
| February 2015<br />
| [[User:Yellows8|Yellows8]], [[User:Plutooo|plutoo]]<br />
|-<br />
| RSA keyslots don't clear exponent when setting modulus<br />
| The [[RSA_Registers|RSA keyslots]] are set by boot ROM to have four private RSA keys. The exponent value in the RSA registers is write-only and not readable.<br />
<br />
However, when setting a keyslot's modulus, the RSA hardware leaves the exponent alone. This allows retrieving the exponent by doing a discrete logarithm of the output.<br />
<br />
By setting the modulus to a prime number whose modular multiplicative order is "smooth" (that is, p-1 is divisible by only small prime numbers), discrete logarithms can be calculated quickly using the [[wikipedia:Pohlig-Hellman algorithm|Pohlig-Hellman algorithm]]. If the prime chosen is greater than the modulus, but the same bit size, the discrete logarithm is the private exponent.<br />
<br />
This exploit's usefulness is limited: RSA keyslot 0 is only used in current firmware for deriving the 6.x save and 7.x NCCH keys, which were already known, and the other three keyslots are entirely unused. Additionally, with a boot ROM dump, this exploit is moot; these private keys are located in the protected ARM9 boot ROM.<br />
| None<br />
| New3DS<br />
| March 2016<br />
| [[User:Myria|Myria]]<br />
|-<br />
| [[CONFIG11_Registers#CFG11_GPUPROT|CFG11_GPUPROT]] allowing acccess to AXIWRAM/FCRAM-BASE-memregion<br />
| [[CONFIG11_Registers#CFG11_GPUPROT|CFG11_GPUPROT]] can be configured by anything with access to it to allow the GPU to access the entire AXIWRAM+FCRAM. For example, this is an issue for any sysmodule that gets exploited and has access to this register memory-page(include one that's listed below).<br />
<br />
See also "kernelhax via gspwn" below.<br />
| None<br />
| New3DS<br />
| February 7, 2017<br />
| [[User:Yellows8|Yellows8]]<br />
|}<br />
<br />
== Boot ROM ==<br />
{| class="wikitable" border="1"<br />
! Summary<br />
! Description<br />
! Fixed with hardware model/revision<br />
! Newest hardware model/revision this flaw was checked for<br />
! Timeframe this was discovered<br />
! Discovered by<br />
|-<br />
| FIRM partitions known-plaintext<br />
| The [[Flash_Filesystem|FIRM partitions]] are encrypted with AES-CTR without a MAC. Since this works by XOR'ing data with a static (per-console in this case) keystream, one can deduce the keystream of a portion of each FIRM partition if they have the actual FIRM binary stored in it.<br />
<br />
This can be paired with many exploits. For example, it allows minor FIRM downgrades (i.e. 10.4 to 9.6 or 9.5 to 9.4, but not 9.6 to 9.5).<br />
However it is most commonly used to install arbitrary FIRMs (usually boot9strap), thanks to sighax.<br />
<br />
This can be somewhat addressed by having a FIRM header skip over previously used section offsets, but this would just air-gap newer FIRMs without fixing the core bug. This can also only be done a limited number of times due to the size of FIRM versus the size of the partitions.<br />
| None<br />
| New3DS<br />
| <br />
| Everyone<br />
|-<br />
| Boot9 AES keyinit function issues<br />
| [[Bootloader|Boot9]] seems to have two bugs in the AES key-init function, see [[AES_Registers#AES_key-init|here]].<br />
| None<br />
| BootROM issue.<br />
| 2015<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| New3DS has same boot ROM as Old3DS<br />
| The New3DS has the exact same boot ROM as the Old3DS. This means, among other things, that all the same boot ROM flaws are present. Also, this meant that it is possible to boot Old3DS firmware on New3DS (see "CFG9_SYSPROT9 bit1 not set by Kernel9").<br />
| None<br />
| New3DS<br />
| October 2014<br />
| Everyone<br />
|-<br />
| sighax: Boot9 improper validation of FIRM partition RSA signatures<br />
| The [[Flash_Filesystem|FIRM partitions]] are signed with RSA-2048 using SHA-256 and PKCS #1 v1.5 padding. Boot9, however, improperly validates the padding in three ways:<br />
# Boot9 permits block type 02, meant for encrypted messages, to be used for signatures. Only 01, for signatures, should have been permitted. As a result, when using block type 02, a signature block is not required to have a long string of FF bytes as padding, but rather any nonzero random values suffice.<br />
# Boot9 does not require that the length of the padding fill out the signature block completely. As a result, there is considerable freedom in the layout of a signature.<br />
# Boot9 fails to do bounds checking in its parsing of the DER-encoded hash algorithm type and hash value; the length values given in DER are permitted to point outside the signature block.<br />
Flaw 3 allows the DER encoding to be such that boot9 believes that the signature's hash value is outside the range of the block itself, somewhere on the stack. This can be pointed at the correct hash value it computes. Boot9 then memcmp's the calculated hash against itself, and thinks that the hash is valid.<br />
<br />
As a result of the above, we estimate that one in 2<sup>43</sup> (~8.8 trillion) random fake signatures will be considered by Boot9 to be valid. This is well within the range of brute force, particularly with an optimized GPU implementation. An Nvidia GTX 1080 Ti would take about one week to find a match.<br />
| None<br />
| New3DS<br />
| July 2015<br />
| [[User:Derrek|derrek]]<br />
|-<br />
| Boot9 FIRM loading doesn't blacklist memory-mapped I/O<br />
| [[Bootloader|Boot9]]'s FIRM loading blacklists Boot9 data regions, but forgets to do other important regions, including Memory-mapped I/O. Combined with sighax, by loading a malicious FIRM section to MMIO, one can get Boot9/Boot11 code execution. <br />
| None<br />
| New3DS<br />
| 2015(?)<br />
| [[User:Derrek|derrek]] (2015?), [[User:Normmatt|Normmatt]] and [[User:SciresM|SciresM]] independently (January 2017).<br />
|-<br />
| "superhax": Boot9 FIRM loading blacklist check is flawed<br />
| Boot9 only makes sure the '''start''' and '''end''' address of each section is not covered by a blacklisted region. Thus, it is possible to overwrite blacklisted regions (e.g. ARM9 Exception Vectors) by choosing a FIRM section range that encloses an entire blacklisted region. The vulnerable code looks like this: if(blRegions[i].start <= sectionStart && blRegions[i].end > sectionStart <nowiki>||</nowiki> blRegions[i].start <= sectionEnd && blRegions[i].end > sectionEnd) return false; // failure<br />
| None<br />
| New3DS<br />
| August 2015<br />
| [[User:Plutoo|plutoo]], [[User:Yellows8|yellows8]]<br />
|}<br />
<br />
== ARM9 software ==<br />
<br />
=== arm9loader ===<br />
{| class="wikitable" border="1"<br />
|-<br />
! Summary<br />
! Description<br />
! Successful exploitation result<br />
! Fixed in [[FIRM]] system version<br />
! Last [[FIRM]] system version this flaw was checked for<br />
! Timeframe this was discovered<br />
! Public disclosure timeframe<br />
! Discovered by<br />
|-<br />
| Generating the keysector console-unique keys with ITCM+Boot9<br />
| [[Bootloader|Boot9]] decrypts the 0x100-byte [[OTP_Registers|OTP]] using AES-CBC with keydata stored in Boot9. If hash verification is successful, the plaintext of the first 0x90-bytes are copied into [[Memory_layout|ITCM]]. This is the ''exact'' ''same'' region hashed by arm9loader when generating the console-unique keys for decrypting the keysector, except arm9loader uses the raw encrypted OTP.<br />
<br />
Therefore, with the OTP keydata+IV from Boot9 you can: encrypt the 0x90-bytes from ITCM, then hash the output to get the console-unique keys for the system's keysector. This can even be done for Old3DS which doesn't have the arm9loader keysector officially.<br />
<br />
It's unknown why arm9loader only used the first 0x90-bytes of OTP. Using more data from OTP would've prevented this. Fixing this would require doing exactly that, but that would also mean updating the NAND keysector(which is dangerous).<br />
| See description.<br />
| None<br />
| <br />
| 2015<br />
| January 6, 2017<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| Rearrangable keys in the NAND keystore<br />
| Due to the keystore being encrypted with AES-ECB, one can rearrange blocks and still have the NAND keystore decrypt in a deterministic way. <br />
<br />
Using 10.0 FIRM it is possible to rearrange keys such that ARM9 memory is executed. As such using existing ARM9 execution 10.0 FIRM can be written to NAND and a payload written to memory, with the payload to be executed post-K9L using an MCU reboot.<br />
| arm9loaderhax given existing ARM9 code execution<br />
| None<br />
| [[11.3.0-36|11.3.0-X]]<br />
| Early 2016<br />
| 27 September 2016<br />
| Myria, [[User:Dark samus|dark_samus]]; mathieulh (independently); [[User:Plutooo|plutoo]] (independently) + others<br />
|-<br />
| Uncleared OTP hash keydata in console-unique 0x11 key-generation<br />
| Kernel9Loader does not clear the [[SHA_Registers#SHA_HASH|SHA_HASH register]] after use. As a result, the data stored here as K9L hands over to Kernel9 is the hash of [[OTP_Registers|OTP data]] used to seed the [[FIRM#New_3DS_FIRM|console-unique NAND keystore decryption key]] set on keyslot 0x11.<br />
<br />
Retrieving this keydata and the [[Flash_Filesystem#0x12C00|NAND keystore]] of the same device allows calculating the decrypted New3DS NAND keystore (non-unique, common to all New3DS units), which contains AES normal keys, also set on keyslot 0x11, which are then used to derive all current [[AES_Registers#Keyslots|New3DS-only AES keyXs]] including the newer batch introduced in [[9.6.0-24#arm9loader|9.6.0-X]]. From there, it is trivial to perform the same key derivation in order to initialize those keys on any system version, and even on Old3DS.<br />
<br />
This can be performed by exploiting the "arm9loaderhax" vulnerability to obtain post-K9L code execution after an MCU reboot (the bootrom section-loading fail is not relevant here, this attack was performed without OTP data by brute-forcing keys), and using this to dump the SHA_HASH register. This attack works on any FIRM version shipping a vulnerable version of K9L, whereas OTP dumping required a boot of <[[3.0.0-6|3.0.0-X]].<br />
<br />
This attack results in obtaining the entire (0x200-bytes) NAND keystore - it was confirmed at a later date that this keystore is encrypted with the same key (by comparing the decrypted data from multiple units), and therefore using another key in this store will not remedy the issue as all keys are known (i.e. later, unused keys decrypt to the same 0x200-bytes constant with the same OTP hash). Later keys could have been encrypted differently but this is not the case. As a result of this, it is not possible for Nintendo to use K9L again in its current format for its intended purpose, though this was not news from the moment people dumped a New3DS OTP.<br />
| Derivation of all New3DS keys generated via the NAND keystore (0x1B "Secure4" etc.)<br />
| None<br />
| [[11.3.0-36|11.3.0-X]]<br />
| ~April 2015, implemented in May 2015<br />
| 13 January 2016<br />
| [[User:WulfyStylez|WulfyStylez]], [[User:Dazzozo|Dazzozo]], [[User:Shinyquagsire23|shinyquagsire23]] (complimentary + implemented), [[User:Plutooo|plutoo]], Normmatt (discovered independently)<br />
|-<br />
| enhanced-arm9loaderhax<br />
| See the 32c3 3ds talk.<br />
Since this is a combination of a trick with the arm9-bootrom + arm9loaderhax, and since you have to manually write FIRM to the firm0/firm1 NAND partitions, this can't be completely fixed. Any system with existing ARM9 code execution and an OTP/OTP hash dump can exploit this. Additionally, by using the FIRM partition known-plaintext bug and bruteforcing the second entry in the keystore, this can currently be exploited on all New3DS systems without any other prerequisite hacks.<br />
| arm9loaderhax which automatically occurs at hard-boot.<br />
| See arm9loaderhax / description.<br />
| See arm9loaderhax / description.<br />
| Theorized around mid July, 2015. Later implemented+tested by [[User:Plutooo|plutoo]] and [[User:Derrek|derrek]].<br />
| 32c3 3ds talk (December 27, 2015)<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| arm9loaderhax: Missing verification block for the 9.6 keys<br />
| Starting with [[9.6.0-24|9.6.0-X]] a new set of NAND-based keys were introduced. However, no verification block was added to verify that the new key read from NAND is correct. This was technically an issue from [[9.5.0-22|9.5.0-X]] with the original sector+0 keydata, however the below is only possible with [[9.6.0-24|9.6.0-X]] since keyslots 0x15 and 0x16 are generated from different 0x11 keyXs.<br />
<br />
Writing an incorrect key to NAND will cause arm9loader to decrypt the ARM9 kernel as garbage and then jump to it.<br />
<br />
This allows an hardware-based attack where you can boot into an older exploited firmware, fill all memory with NOP sleds/jump-instructions, and then reboot into executing garbage. By automating this process with various input keydata, eventually you'll find some garbage that jumps to your code.<br />
<br />
This gives very early ARM9 code execution (pre-ARM9 kernel). As such, it is possible to dump RSA keyslots with this and calculate the 6.x [[Savegames#6.0.0-11_Savegame_keyY|save]], and 7.x [[NCCH]] keys. This cannot be used to recover keys initialized by arm9loader itself. This is due to it wiping the area used for its stack during NAND sector decryption and keyslot init. <br />
<br />
Due to FIRMs on both Old and New 3DS using the same RSA data, this can be exploited on Old3DS as well, but only if one already has the actual plaintext normalkey from New3DS NAND sector 0x96 offset-0 and has dumped the OTP area of the Old3DS.<br />
| Recovery of 6.x [[Savegames#6.0.0-11_Savegame_keyY|save key]]/7.x [[NCCH]] key, access to uncleared OTP hash keydata<br />
| None<br />
| [[11.3.0-36|11.3.0-X]]<br />
| March 2015<br />
| <br />
| [[User:Plutooo|plutoo]]<br />
|-<br />
| arm9loader runs on Old3DS<br />
| Despite being written only for New3DS, all of arm9loader runs fine on Old3DS. It's not until booting Kernel9 that a New3DS FIRM partition would crash on an Old3DS. As a result, if a bug exists in arm9loader to get control, it can be exploited on Old3DS by writing New3DS FIRM to the FIRM partitions. Thus, arm9loaderhax works on both Old3DS and New3DS.<br />
| arm9loader bugs also compromise Old3DS<br />
| None<br />
| [[11.3.0-36|11.3.0-X]]<br />
| Sometime in 2015<br />
| <br />
| [[User:Plutooo|plutoo]] presumably<br />
|-<br />
| Uncleared New3DS keyslot 0x11<br />
| Originally the New3DS [[FIRM]] arm9bin loader only cleared keyslot 0x11 when it gets executed at firmlaunch. This was fixed with [[9.5.0-22|9.5.0-X]] by completely clearing keyslot 0x11 immediately after the loader finishes using keyslot 0x11.<br />
This means that any ARM9 code that can execute before the loader clears the keyslot at firmlaunch(including firmlaunch-hax) can get access to the uncleared keyslot 0x11, which then allows one to generate all <=v9.5 New3DS keyXs which are generated by keyslot 0x11.<br />
<br />
Therefore, to completely fix this the loader would have to generate more keys using different keyslot 0x11 keydata. This was done with [[9.6.0-24|9.6.0-X]].<br />
| New3DS keyXs generation<br />
| Mostly fixed with [[9.5.0-22|9.5.0-X]], completely fixed with new keys with [[9.6.0-24|9.6.0-X]].<br />
| <br />
| February 3, 2015 (one day after [[9.5.0-22|9.5.0-X]] release)<br />
| <br />
| [[User:Yellows8|Yellows8]]<br />
|}<br />
<br />
=== Process9 ===<br />
{| class="wikitable" border="1"<br />
|-<br />
! Summary<br />
! Description<br />
! Successful exploitation result<br />
! Fixed in [[FIRM]] system version<br />
! Last [[FIRM]] system version this flaw was checked for<br />
! Timeframe this was discovered<br />
! Public disclosure timeframe<br />
! Discovered by<br />
|-<br />
| Leak of normal-key matching a key-scrambler key<br />
| New 3DS firmware versions [[8.1.0-0 New3DS|8.1.0]] through [[9.2.0-20|9.2.0]] set the encryption key for [[Amiibo]] data using a hardcoded normal-key in Process9. In firmware [[9.3.0-21|9.3.0]], Nintendo "fixed" this by using the key scrambler instead, by calculating the keyY value for keyslot 0x39 that results in the same normal-key, then hardcoding that keyY into Process9.<br />
<br />
Nintendo's fix is actually the problem: Nintendo revealed the normal-key matching an unknown keyX and a known keyY. Combined with the key scrambler using an insecure scrambling algorithm (see "Hardware" above), the key scrambler function could be deduced.<br />
| Deducing the keyX for keyslot 0x39 and the key scrambler algorithm<br />
| New 3DS [[9.3.0-21|9.3.0-X]], sort of<br />
| [[10.0.0-27|10.0.0-X]]<br />
| Sometime in 2015 after the hardware key-generator was broken.<br />
| 32c3 3ds talk (December 27, 2015)<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| Leak of normal-key matching a key-generator key<br />
| During the 3DS' development (June/July 2010) Nintendo added support installing encrypted content ([[CIA]]). Common-key index1 was intended to be a [[AES|hardware generated key]]. However while they added code to generate the key in hardware, they forgot to remove the normal-key for index1 (used elsewhere, likely old debug code). Nintendo later removed the normal key sometime before the first non-prototype firmware release.<br />
<br />
Knowing the keyY and the normal-key for common-key index1, the devkit key-generator algorithm can be deduced (see "Hardware" above). Additionally the remaining devkit common-keys can be generated once the common-key keyX is recovered.<br />
<br />
Note that the devkit key-generator was discovered to be the same as the retail key-generator.<br />
| Deducing the keyX for keyslot 0x3D and hardware key-generator algorithm. Generate remaining devkit common-keys.<br />
| pre-[[1.0.0-0|1.0.0-X]]<br />
| <br />
| Shortly after the key-generator was revealed to be flawed at the 32c3 3ds talk<br />
| January 20, 2016<br />
| [[User:Jakcron|jakcron]]<br />
|-<br />
| Factory firmware is vulnerable to sighax<br />
| During the 3DS's development, presumably boot9 was written (including the sighax vulnerability). This vulnerability is also present in factory firmware (and earlier, including 0.11). This was fixed in version 1.0.0-0.<br />
| Deducing the mechanics of the sighax vulnerability in boot9 without having a dump of protected boot9. ARM9 code execution on factory/earlier firmware.<br />
| [[1.0.0-0|1.0.0-X]]<br />
| [[1.0.0-0|1.0.0-X]]<br />
| May 9, 2017<br />
| May 19, 2017<br />
| [[User:SciresM|SciresM]], [[User:Myria|Myria]]<br />
|-<br />
| twlhax: Corrupted SRL header leads to memory overwrite<br />
| During TWL_FIRM boot, the ARM11 process TwlBg puts launcher.srl, the DSi bootloader, into FCRAM. TWL_FIRM Process9 then parses the [http://dsibrew.org/wiki/NDS_Format SRL header] to place launcher.srl's code where DSi mode can execute it.<br />
<br />
DSi-mode memory is in FCRAM, but interleaved. Each byte of DSi-mode memory also exists at some address in 3DS FCRAM space.<br />
<br />
Process9 does not validate the RSA signature on launcher.srl, unlike SRLs loaded from cartridge or NAND (DSiWare). A compromised ARM11 can, in a manner similar to firmlaunchhax, send a launcher.srl with a modified SRL header. By setting the SRL header's ARM7/ARM9 load addresses and sizes carefully, accounting for the different memory map and for DSi mode's interleaved memory, it is possible to overwrite part of Process9's stack and take control with a ROP chain.<br />
<br />
Fixed in 11.8.0-X by... (fill me in)<br />
| ARM9 code execution (whilst still in 3DS mode)<br />
| [[11.8.0-41|11.8.0-X]]<br />
| [[11.8.0-41|11.8.0-X]]<br />
|<br />
| August 11, 2018<br />
| smea<br />
|-<br />
| safefirmhax<br />
| SAFE_MODE_FIRM is almost never updated(even when NATIVE_FIRM is updated for vuln fixes), this can be noticed by ''just'' checking 3dbrew/ninupdates title-listings.<br />
<br />
The fix for 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 <=> Kernel11 sync, PXI sync and then repeat the original attack on SAFE_FIRM instead.<br />
| ARM9 code execution<br />
| [[11.3.0-36|11.3.0-X]]<br />
| <br />
| 2012-2013?<br />
| Wiki: January 2, 2017<br />
| Everyone<br />
|-<br />
| safefirmhax 1.1<br />
| Nintendo's original safefirmhax fix was flawed -- they added a global boolean that got set to true whenever a non-sysmodule title got launched (except for a hardcoded repair title id), and panic()'d if that boolean was true to prevent launching safefirm after hax was active. However, because the boolean was initially false after firmlaunch -- With ARM11-kernel execution, one could FIRM-launch into NATIVE_FIRM, and then immediately FIRM-launch again into SAFE_FIRM early in NATIVE_FIRM boot before the boolean got set to true to repeat the safehax attack.<br />
<br />
This was fixed by adding additional CFG9_BOOTENV checks to firmlaunch code in 11.4.<br />
| ARM9 code execution<br />
| [[11.4.0-37|11.4.0-X]]<br />
| <br />
| safefirmhax fix<br />
| Wiki: April 10, 2017<br />
| Everyone<br />
|-<br />
| ntrcardhax<br />
| When reading the banner of a NTR title, Process9 relies on a hardware register to know when the banner was fully read.<br />
However that register is shared between the ARM9 and the ARM11.<br />
An attacker with k11 control can so make Process9 believe the banner continues forever and so trigger a buffer overflow.<br />
With a custom banner for a NTR flashcart, this leads to code execution in Process9.<br />
<br />
This was fixed by adding bound checks on the read data.<br />
| ARM9 code execution<br />
| [[10.4.0-29|10.4.0-X]]<br />
| <br />
| March 2015<br />
| 32c3 3ds talk (December 27, 2015)<br />
| [[User:Plutooo|plutoo]]<br />
|-<br />
| Title downgrading via [[Application_Manager_Services|AM]]([[Application_Manager_Services_PXI|PXI]])<br />
| When a title is *already* installed, Process9 will compare the installed title-version with the title-version being installed. When the one being installed is older, Process9 would return an error.<br />
<br />
However, this can be bypassed by just deleting the title first via the service command(s) for that: with the title removed from the [[Title_Database]], Process9 can't compare the input title-version with anything. Hence, titles can be downgraded this way.<br />
<br />
[[11.0.0-33|11.0.0-X]] fixed this for key system titles (MSET, Home Menu, spider, ErrDisp, SKATER, NATIVE_FIRM, and every retail system module), by checking the version of the title to install against a hard-coded list of (titleID, minimumVersionRequired) pairs.<br />
| Bypassing title version check at installation, which then allows downgrading any title.<br />
| [[11.0.0-33|11.0.0-X]], for key system titles.<br />
| NATIVE_FIRM / AM-sysmodule [[11.0.0-33|11.0.0-X]]<br />
| ?<br />
| <br />
| ?<br />
|-<br />
| Anti-downgrade list did not include all system titles initially<br />
| The anti-downgrade list did not include legacy FIRMs until [[11.8.0-41|11.8.0-X]]. Therefore, legacy FIRMs could still be downgraded.<br />
| Downgrading legacy FIRMs; allowing to exploit bugs in older legacy FIRMs (of which at least one exists, see below).<br />
| [[11.8.0-33|11.8.0]]<br />
| [[11.8.0-33|11.8.0]]<br />
| ?<br />
| Wiki: August 5, 2018<br />
| Everyone<br />
|-<br />
| TWL_FIRM cmd-9 unchecked offset<br />
| In [[1.0.0-0|1.0.0-X]]'s TWL_FIRM, cmds 8 and 9 were not stubbed (whereas in the corresponding NATIVE_FIRM, they were).<br />
Command 8 does the Process9 initialisation for NTR carts if an NTR cart is inserted (NTR, not TWL, judged by chipid).<br />
<br />
Command 9 takes (u32 offset_read, u32 offset_write, u32 offset_read_end), and basically just copies (offset_read_end - offset_read) bytes starting at (offset_read) of [NTR cart header in arm9mem, NTR secure area in fcram, TWL secure area in fcram], to 0x18001000 + offset_write + offset_read.<br />
<br />
offset_write is not checked at all, thus this leads to ARM9 code execution as long as any NTR cart, including flashcarts that would normally be blocked by TWL_FIRM, is inserted.<br />
<br />
In [[2.0.0-2|2.0.0-X]] TWL_FIRM, those commands were stubbed out.<br />
| ARM9 code execution<br />
| [[2.0.0-2|2.0.0-X]]<br />
| [[2.0.0-2|2.0.0-X]]<br />
| January 2018<br />
| Wiki: August 5, 2018<br />
| [[User:Riley|Riley]]<br />
|-<br />
| FIRM launch doesn't check target FIRM version<br />
| When executing a FIRM launch, Process9 doesn't validate that the target FIRM isn't an old version. This allows booting an exploitable FIRM from a newer FIRM, if you can get the exploitable FIRM installed. ([[11.0.0-33|11.0.0-X]] now prevents installing old versions of system titles, but this doesn't affect titles already installed.)<br />
<br />
This had a use after [[9.6.0-24|9.6.0-X]]: on a compromised 3DS running 9.2.0, you could install the 9.6.0 NATIVE_FIRM to FIRM0/FIRM1, but avoid putting it into the NATIVE_FIRM title. This would boot the 9.2.0 system software but with the 9.6.0 Process9 and Kernel11. With a user-mode exploit in a sufficiently-privileged application (e.g. mset), you could trigger a FIRM launch back to NATIVE_FIRM, which would load the 9.2.0 Process9 and Kernel11.<br />
<br />
9.6.0's keyslots 0x15 and 0x16 are unknown to 9.2.0, so 9.2.0 would not clear them. You then could do firmlaunchhax against 9.2.0 to get ARM9 access with keyslots 0x15 and 0x16 set to their proper 9.6.0 values, allowing decrypting 9.6.0's encrypted titles. Once the New3DS keystore was dumped, this became moot.<br />
| Decrypting 9.6.0 NCCH files without dumping New3DS keystore<br />
| None (but now moot)<br />
| [[9.6.0-24|9.6.0-X]]<br />
| March 2015<br />
| August 12, 2018<br />
| [[User:Yellows8|Yellows8]], [[User:Myria|Myria]]<br />
|-<br />
| FAT FS code null-deref<br />
| When FSFile:Read is used with a file which is corrupted on a FAT filesystem(in particular SD), Process9 can crash. This particular crash is caused by a function returning NULL instead of an actual ptr due to an error. The caller of that function doesn't check for NULL which then triggers a read based at NULL.<br />
<br />
Sample "fsck.vfat -n -v -V <fat image backup>" output for the above crash:<br />
<br />
<pre>...<br />
Starting check/repair pass.<br />
<FilePath0> and<br />
<FilePath1><br />
share clusters.<br />
Truncating second to 3375104 bytes.<br />
<FilePath1><br />
File size is 2787392 bytes, cluster chain length is 16384 bytes.<br />
Truncating file to 16384 bytes.<br />
Checking for unused clusters.<br />
Reclaimed 1 unused cluster (16384 bytes).<br />
Checking free cluster summary.<br />
Free cluster summary wrong (1404490 vs. really 1404491)<br />
Auto-correcting.<br />
Starting verification pass.<br />
Checking for unused clusters.<br />
Leaving filesystem unchanged.</pre><br />
| Useless null-based-read<br />
| None<br />
| [[9.6.0-24|9.6.0-X]]<br />
| July 8-9, 2015<br />
| <br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| RSA signature padding checks<br />
| The TWL_FIRM RSA sig padding check code used for all TWL RSA sig-checks has issues, see [[FIRM|here]].<br />
The main 3DS RSA padding check code(non-certificate, including NATIVE_FIRM) uses the function used with the above to extract more padding + the actual hash from the additional padding. This isn't really a problem here because there's proper padding check code which is executed prior to this.<br />
| <br />
| None<br />
| [[9.5.0-22|9.5.0-X]]<br />
| March 2015<br />
| <br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[AMPXI:ValidateDSiWareSectionMAC]] [[AES_Registers|AES]] keyslot reuse<br />
| When the input DSiWare section index is higher than <max number of DSiWare sections supported by this FIRM>, Process9 uses keyid 0x40 for calculating the AESMAC, which translates to keyslot 0x40. The result is that the keyslot is left at whatever was already selected before, since the AES selectkeyslot code will immediately return when keyslot is >=0x40. However, actually exploiting this is difficult: the calculated AESMAC is never returned, this command just compares the calculated AESMAC with the input AESMAC(result-code depends on whether the AESMACs match). It's unknown whether a timing attack would work with this.<br />
This is basically a different form of the pxips9 keyslot vuln, except with AESMAC etc.<br />
| See description.<br />
| None<br />
| [[11.3.0-36|11.3.0-X]]<br />
| March 15, 2015<br />
| December 29, 2015<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| pxips9 [[AES_Registers|AES]] keyslot reuse<br />
| This requires access to the [[Process_Services|ps:ps]]/pxi:ps9 services. One way to get access to this would be snshax on system-version <=10.1.0-X(see 32c3 3ds talk).<br />
When an invalid key-type value is passed to any of the PS commands, Process9 will try to select keyslot 0x40. That aesengine_setkeyslot() code will then immediately return due to the invalid keyslot value. Since that function doesn't return any errors, Process9 will just continue to do crypto with whatever AES keyslot was selected before the PS command was sent.<br />
| Reusing the previously used keyslot, for crypto with PS.<br />
| None<br />
| [[11.3.0-36|11.3.0-X]]<br />
| Roughly the same time(same day?) as firmlaunch-hax.<br />
| December 29, 2015<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| firmlaunch-hax: FIRM header ToCToU<br />
| This can't be exploited from ARM11 userland.<br />
During [[FIRM]] launch, the only FIRM header the ARM9 uses at all is stored in FCRAM, this is 0x200-bytes(the actual used FIRM RSA signature is read to the Process9 stack however). The ARM9 doesn't expect "anything" besides the ARM9 to access this data.<br />
With [[9.5.0-22]] the address of this FIRM header was changed from a FCRAM address, to ARM9-only address 0x01fffc00.<br />
| ARM9 code execution<br />
| [[9.5.0-22]]<br />
| <br />
| 2012, 3 days after [[User:Yellows8|Yellows8]] started Process9 code RE.<br />
| <br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| Uninitialized data output for (PXI) command replies<br />
| PXI commands for various services(including some [[Filesystem_services_PXI|here]] and many others) can write uninitialized data (like from ARM registers) to the command reply. This happens with stubbed commands, but this can also occur with certain commands when returning an error.<br />
Certain ARM11 service commands have this same issue as well.<br />
| <br />
| None<br />
| [[9.3.0-21|9.3.0-X]]<br />
| ?<br />
| <br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[Filesystem_services_PXI|FSPXI]] OpenArchive SD permissions<br />
| Process9 does not use the exheader ARM9 access-mount permission flag for SD at all.<br />
This would mean ARM11-kernelmode code / fs-module itself could directly use FSPXI to access SD card without ARM9 checking for SD access, but this is rather useless since a process is usually running with SD access(Home Menu for example) anyway.<br />
| <br />
| None<br />
| [[9.3.0-21|9.3.0-X]]<br />
| 2012<br />
| <br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[AMPXI:ExportDSiWare]] export path<br />
| Process9 allocates memory on Process9 heap for the export path then verifies that the actual allocated size matches the input size. Then Process9 copies the input path from FCRAM to this buffer, and uses it with the Process9 FS openfile code, which use paths in the form of "<mountpoint>:/<path>".<br />
Process9 does not check the contents of this path at all before passing it to the FS code, besides writing a NUL-terminator to the end of the buffer.<br />
| Exporting of DSiWare to arbitrary Process9 file-paths, such as "nand:/<path>" etc. This isn't really useful since the data which gets written can't be controlled.<br />
| None<br />
| [[9.5.0-22]]<br />
| April 2013<br />
| <br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[DSiWare_Exports]] [[CTCert]] verification<br />
| Just like DSi originally did, 3DS verifies the APCert for DSiWare on SD with the CTCert also in the DSiWare .bin. On DSi this was fixed with with system-version 1.4.2 by verifying with the actual console-unique cert instead(stored in NAND), while on 3DS it's still not(?) fixed.<br />
On 3DS however this is useless, unless one can obtain the console-unique movable.sed keyY which encrypts the entire DSiWare .bin.<br />
| When the movable.sed keyY for the target 3DS is known and the target 3DS CTCert private-key is unknown, importing of modified DSiWare SD .bin files.<br />
| None.<br />
| 11.6.0-X<br />
| April 2013<br />
| <br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| seedminer: movable.sed keyY vulnerable to brute-force<br />
| Half of the movable.sed keyY's 128 bits are leaked through the [[Nandrw/sys/LocalFriendCodeSeed_B|LFCS]], which is available in userland and below. The LFCS itself also leaks almost half of the remaining bits by following the ratio: u32 keyY[3]=1/5(LFCS). The remaining keyY[3] uncertainty of about ±2000 can be greatly reduced by plotting expected error margins with several keyYs. This results in a final uncertainty of about 2^40, easily within practical brute force range of an average modern PC.<br />
| Knowing the keyY of a given 3ds allows for modification of DSiWare export contents, and chained with several other public vulns, ultimately arm9 execution.<br />
| None.<br />
| 11.6.0-X<br />
| December 2017<br />
| January 2018<br />
| zoogie<br />
|-<br />
| Improper validation of DSiWare title SRLs<br />
| The 3DS does not verify if the actual SRL embedded in the title's directory matches the titleID in the TMD before launching it or importing it from an sd DSiWare export. <br />
| This allows embedding older, exploitable DSiWare titles in completely different, unexploitable DSiWare titles. Since DSiWare has raw NAND RW, this can result in arm9 control through FIRM known-plaintext and sighax attacks.<br />
| None.<br />
| 11.6.0-X<br />
| 2015?<br />
| December 2016<br />
| Everyone<br />
|-<br />
| [[Gamecard_Services_PXI]] unchecked REG_CTRCARDCNT transfer-size<br />
| The u8 REG_CTRCARDCNT transfer-size parameter for the [[Gamecard_Services_PXI]] read/write CTRCARD commands is used as an index for an array of u16 values. Before [[5.0.0-11|5.0.0-X]] this u8 value wasn't checked, thus out-of-bounds reads could be triggered(which is rather useless in this case).<br />
| Out-of-bounds read for a value which gets written to a register.<br />
| [[5.0.0-11|5.0.0-X]]<br />
| <br />
| 2013?<br />
| <br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[PXI_Registers|PXI]] cmdbuf buffer overrun<br />
| The Process9 code responsible [[PXI_Registers|PXI]] communications didn't verify the size of the incoming command before writing it to a C++ member variable. <br />
| Probably ARM9 code execution<br />
| [[5.0.0-11|5.0.0-11]]<br />
| <br />
| March 2015, original timeframe if any unknown<br />
| <br />
| [[User:Plutooo|plutoo]]/[[User:Yellows8|Yellows8]]/maybe others(?)<br />
|-<br />
| [[Application_Manager_Services_PXI|PXIAM]] command 0x003D0108(See also [[Application_Manager_Services|this]])<br />
| When handling this command, Process9 allocates a 0x2800-byte heap buffer, then copies the 4 FCRAM input buffers to this heap buffer without checking the sizes at all(only the buffers with non-zero sizes are copied). Starting with [[5.0.0-11|5.0.0-X]], the total combined size of the input data must be <=0x2800.<br />
| ARM9 code execution<br />
| [[5.0.0-11|5.0.0-X]]<br />
| <br />
| May 2013<br />
| <br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[Process_Services_PXI|PS RSA]] commands buffer overflows<br />
| pxips9 cmd1(not accessible via ps:ps) and VerifyRsaSha256: unchecked copy to a buffer in Process9's .bss, from the input FCRAM buffer. The buffer is located before the pxi cmdhandler threads' stacks. SignRsaSha256 also has a buf overflow, but this isn't exploitable.<br />
The buffer for this is the buffer for the signature data. With v5.0, the signature buffer was moved to stack, with a check for the signature data size. When the signature data size is too large, Process9 uses [[SVC|svcBreak]].<br />
| ARM9 code execution<br />
| [[5.0.0-11|5.0.0-X]]<br />
| <br />
| 2012<br />
| <br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[PXI_Registers|PXI]] pxi_id bad check<br />
| The Process9 code responsible for [[PXI_Registers|PXI]] communications read pxi_id as a signed char. There were two flaws:<br />
* They used it as index to a lookup-table without checking the value at all.<br />
* Another function verified that pxi_id < 7, allowing negative values to pass the check. This would also cause an out-of-range table-lookup.<br />
| Maybe ARM9 code execution<br />
| [[3.0.0-5|3.0.0-5]]<br />
|<br />
| March 2015, originally 2012 for the first issue at least<br />
| <br />
| [[User:Plutooo|plutoo]], [[User:Yellows8|Yellows8]], maybe others(?)<br />
|}<br />
<br />
=== Kernel9 ===<br />
{| class="wikitable" border="1"<br />
|-<br />
! Summary<br />
! Description<br />
! Successful exploitation result<br />
! Fixed in [[FIRM]] system version<br />
! Last [[FIRM]] system version this flaw was checked for<br />
! Timeframe this was discovered<br />
! Discovered by<br />
|-<br />
| [[CONFIG Registers#CFG9_SYSPROT9|CFG9_SYSPROT9]] bit1 not set by Kernel9<br />
| Old versions of Kernel9 never set bit1 of [[CONFIG Registers#CFG9_SYSPROT9|CFG9_SYSPROT9]]. This leaves the [[OTP Registers|0x10012000]]-region unprotected (this region should be locked early during boot!). Since it's never locked, you can dump it once you get ARM9 code execution.<br />
<br />
From [[3.0.0-5|3.0.0-X]] this was fixed by setting the bit in Kernel9 after poking some registers in that region. On New3DS arm9loader sets this bit instead of Kernel9, which is exploitable through a hardware + software vulnerability (see arm9loaderhax / description).<br />
<br />
This flaw resurged when it gained a new practical use: retrieving the OTP data for a New3DS console in order to decrypt the key data used in arm9loader (see enhanced-arm9loaderhax / description). This was performed by downgrading to a vulnerable system version. By accounting for differences in CTR-NAND crypto (0x05 -> 0x04, see partition encryption types [[Flash_Filesystem#NAND_structure|here]]) and using an Old3DS [[NCSD#NCSD_header|NCSD Header]], it is possible to boot a New3DS using Old3DS firmware 1.0-2.x to retrieve the required OTP data using this flaw.<br />
| Dumping the [[OTP Registers|OTP]] area.<br />
Decrypting New3DS sector 0x96 keyblock.<br />
| [[3.0.0-5|3.0.0-X]]<br />
|<br />
| February 2015<br />
| [[User:Plutooo|plutoo]], Normmatt independently<br />
|}<br />
<br />
== ARM11 software ==<br />
=== Kernel11 ===<br />
{| class="wikitable" border="1"<br />
|-<br />
! Summary<br />
! Description<br />
! Successful exploitation result<br />
! Fixed in [[FIRM]] system version<br />
! Last [[FIRM]] system version this flaw was checked for<br />
! Timeframe this was discovered<br />
! Discovered by<br />
|-<br />
| [[SVC|svcSetProcessIdealProcessor]] reference count overflow and therefore use-after-free.<br />
| The SVC receive two arguments: handle and idealprocessor. The handle is used to get the KProcess object and the KProcess->refCnt gets incremented,later the function check if the KProcess->mem_type != BASE and if yes, it checks for idealprocessor == 2 or idealprocessor != 3. The problem here is that if you pass the idealprocessor = 3 it won't meet any condition and return the error 0xD9001BEA without decrement the reference count. <br />
It can be abused to overflow the KProcess reference count that will lead to an Use-after-free. <br />
| Before [[11.2.0-35|11.2.0-X]]: reference count overflow and therefore use-after-free.<br />
| <br />
| [[11.6.0-39|11.6.0-X]]<br />
| November 2, 2017<br />
| [[User:st4rk|st4rk]]<br />
|-<br />
| [[SVC|svcGetThreadList]] process reference leak<br />
| When given a valid process handle (including <code>0xFFFF8001</code>), svcGetThreadList forgets to decrement the reference count of the underlying [[KProcess]] instance, after having finished using it.<br />
| Before [[11.2.0-35|11.2.0-X]]: reference count overflow and therefore use-after-free, but this UAF was most likely not exploitable<br />
| <br />
| [[11.3.0-36|11.3.0-X]]<br />
| April 3, 2017<br />
| [[User:TuxSH|TuxSH]]<br />
|-<br />
| kernelhax via gspwn<br />
| Originally the kernel didn't initialize [[CONFIG11_Registers#CFG11_GPUPROT|CFG11_GPUPROT]]. Since it's 0 at hard-boot, this allowed the GPU to access the entire FCRAM + AXIWRAM.<br />
| Entire FCRAM+AXIWRAM R/W.<br />
| [[3.0.0-5|3.0.0-X]]<br />
| <br />
| February 7, 2017<br />
| [[User:Plutooo|plutoo]], [[User:Yellows8|Yellows8]] partly<br />
|-<br />
| fasthax<br />
| When a KTimer is created in pulse mode, the kernel calls a virtual function to reset the timer each time it pulses. The scheduler is locked for that core to avoid race conditions, but another core can call CloseHandle on the timer and free it, leading to a UAF vtable call.<br />
| See description.<br />
| [[11.3.0-36|11.3.0-X]]<br />
| [[11.3.0-36|11.3.0-X]]<br />
| May 2016<br />
| nedwill<br />
|-<br />
| ipctakeover<br />
| When sending cmdreplies, it does not validate that the src_addr and src_size match the equivalent dst_addr and dst_size. With a modified addr/size specified in a cmdreply for an output buffer, the data-copy for the first/last pages could be used to overwrite data outside of the buffer specified by the original process.<br />
<br />
Used by ctr-httpwn as of v1.2, for "ipctakeover/bosshaxx".<br />
<br />
This can be used to takeover processes where the process is using your service session. Like HTTPC -> BOSS, for bosshaxx above. NIM takeover can be done too(actual stack buffer overflow can trigger), etc.<br />
| See description.<br />
| None<br />
| [[11.3.0-36|11.3.0-X]]<br />
| November 26, 2016<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| Using IPC input buffers as output buffers<br />
| When sending cmdreplies, it does not validate that the cmdreply descriptor type matches the equivalent cmdreq descriptor type. This could be used by an exploited sysmodule to use what was intended as an input-buffer as an output-buffer, and also combine other IPC vuln(s) with this.<br />
<br />
Used by ctr-httpwn as of v1.2, for "ipctakeover/bosshaxx".<br />
| See description.<br />
| None<br />
| [[11.3.0-36|11.3.0-X]]<br />
| November 2016<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[SVC]] table too small<br />
| The table of function pointers for SVC's only contains entries up to 0x7D, but the biggest allowed SVC for the table is 0x7F. Thus, executing SVC7E or SVC7F would make the SVC-handler read after the buffer, and interpret some ARM instructions as function pointers.<br />
<br />
However, this would require patching the kernel .text or modifying SVC-access-control. Even if you could get these to execute, they would still jump to memory that isn't mapped as executable.<br />
| <br />
| None<br />
| [[11.3.0-36|11.3.0-X]]<br />
| 2012<br />
| Everyone<br />
|-<br />
| [[SVC|svcBackdoor (0x7B)]]<br />
| This backdoor allows executing SVC-mode code at the user-specified code-address. This is used by Process9, using this on the ARM11 (with NATIVE_FIRM) required patching the kernel .text or modifying SVC-access-control.<br />
| See description<br />
| [[11.0.0-33|11.0.0-X]] (deleted)<br />
| <br />
|<br />
| Everyone<br />
|-<br />
| veryslowpidhax<br />
| '''This is completely different from the kernelmode-code-execution vuln described in the below separate entry.'''<br />
<br />
When updating the kernel global PID counter under [[SVC|svcCreateProcess]] the kernel does not check for wraparound to 0x0(the PID for the very first process). This only matters because [[Services|SM-module]] allows processes with PID value less than <total ARM11 FIRM modules> to access ''all'' services, without checking exheader service-access-control; and because Kernel11 checks for the PID to be 1 (loader) to use the input mem-region value on ControlMemory. This alone does not affect access the [[SVC|SVCs]] access table at all.<br />
<br />
Inlined ldrex+strex code is used for updating the above counter. [[11.2.0-35|11.2.0-X]] had changes for similar code, but it was only for dedicated ldrex+strex functions(mainly for kernel objects) and hence this PID code was not affected.<br />
<br />
With launching+terminating a sysmodule repeatedly with this via ns:s, it would take weeks to finish(if not at least about a month?).<br />
| Access to all [[Services_API|services]], ControlMemory on any given mem-region.<br />
| None<br />
| [[11.3.0-36|11.3.0-X]]<br />
| 2012 maybe?<br />
| <br />
|-<br />
| slowhax/waithax<br />
| svcWaitSynchronizationN does not decrement the references to valid handles in an array before returning an error when it encounters an invalid handle. This allows one to (slowly) overflow the reference count for a handle object to zero.<br />
| ARM11 kernel-mode code execution<br />
| [[11.2.0-35|11.2.0-X]]<br />
| [[11.2.0-35|11.2.0-X]]<br />
| 2016<br />
| nedwill, [[User:Derrek|derrek]]<br />
|-<br />
| [[Memory_layout#ARM11_Detailed_virtual_memory_map|0xEFF00000]] / 0xDFF00000 ARM11 kernel virtual-memory<br />
| The ARM11 kernel-mode 0xEFF00000/0xDFF00000 virtual-memory(size 0x100000) is mapped to phys-mem 0x1FF00000(entire DSP-mem + entire AXIWRAM), with permissions RW-. This is used during ARM11 kernel startup for loading the FIRM-modules from the FIRM section located in DSP-mem, this never seems to be used after that, however. This is never unmapped either.<br />
| <br />
| None<br />
| [[11.3.0-36|11.3.0-X]]<br />
| <br />
| <br />
|-<br />
| memchunkhax2.1<br />
| Nintendo's fix for memchunkhax2 in [[10.4.0-29|10.4.0-X]] did not fix the GPU case: one may cause the requisite ToCToU race using gspwn, bypassing the new validation.<br />
derrek's original 32c3 presentation for memchunkhax2 commented that a GPU-based attack was possible, but would be difficult. However, memchunkhax2.1 showed that it was possible to do fairly reliably.<br />
| ARM11 kernel code execution<br />
| [[11.0.0-33|11.0.0-X]], via the new [[Memory_Management#MemoryBlockHeader|memchunkhdr]] MAC which prevents modifying memchunkhdr data with DMA.<br />
| [[11.0.0-33|11.0.0-X]]<br />
|<br />
| [[User:Derrek|derrek]], aliaspider<br />
|-<br />
| memchunkhax2<br />
| When allocating a block of memory, the "next" pointer of the [[Memory_Management#MemoryBlockHeader|memchunkhdr]] is accessed without being checked after being mapped to userland.<br />
This allows a race condition, where the process can change the next pointer just before it's accessed. By pointing the next pointer to a crafted memchunckhdr in the kernel SlabHeap, some of the SlabHeap is allocated to the calling process, allowing to change vtables of kernel objects. <br />
| ARM11 kernel code execution<br />
| [[10.4.0-29|10.4.0-X]] (partially, see memchunkhax2.1)<br />
| [[10.4.0-29|10.4.0-X]]<br />
|<br />
| [[User:Derrek|derrek]]<br />
|-<br />
| heaphax<br />
| Can change the size of free memchunk structures stored in FCRAM using DMA, which leads to the ability to allocate memory chunks over already-allocated memory. This can be used in the SYSTEM region to allocate RW memory over any part of the NS system module, which is enough to take it over.<br />
| Code execution with access to all of NS's privileges. (including downgrading) Code execution within any applet.<br />
| [[11.0.0-33|11.0.0-X]], via the new [[Memory_Management#MemoryBlockHeader|memchunkhdr]] MAC which prevents modifying memchunkhdr data with DMA.<br />
| [[11.0.0-33|11.0.0-X]]<br />
| April 2015 ?<br />
| smea<br />
|-<br />
| snshax<br />
| Can force creation of Safe NS process into gspwn-able memory, allowing for takeover.<br />
| Code execution with access to all of NS's privileges. (including downgrading)<br />
| [[10.1.0-27|10.1.0-X]]<br />
| [[10.1.0-27|10.1.0-X]]<br />
| April 2015 ?<br />
| smea<br />
|-<br />
| AffinityMask/processorid validation<br />
| With [[10.0.0-27|10.0.0-X]] the following functions were updated: svcGetThreadAffinityMask, svcGetProcessAffinityMask, svcSetProcessAffinityMask, and svcCreateThread. The code changes for all but svcCreateThread are identical.<br />
The original code with the first 3 did the following: <br />
* if(u32_processorcount > ~0x80000001)return 0xe0e01bfd;<br />
* if(s32_processorcount > <total_cores>)return 0xd8e007fd;<br />
The following code replaced the above:<br />
* if(u32_processorcount >= <total_cores+1>)return 0xd8e007fd;<br />
In theory the latter should catch everything that the former did, so it's unknown if this was really a security issue.<br />
<br />
The svcCreateThread changes with [[10.0.0-27|10.0.0-X]] definitely did fix a security issue.<br />
* Original code: "if(s32_processorid > <total_cores>)return 0xd8e007fd;"<br />
* New code: "if(s32_processorid >= <total_cores> || s32_processorid <= -4)return 0xd8e007fd;"<br />
This fixed an off-by-one issue: if one would use processorid=total_cores, which isn't actually a valid value, svcCreateThread would accept that value on <[[10.0.0-27|10.0.0-X]]. This results in data being written out-of-bounds(baseaddr = arrayaddr + entrysize*processorid), which has the following result:<br />
* Old3DS: Useless kernel-mode crash due to accessing unmapped memory.<br />
* New3DS: uncontrolled data write into a kernel-mode L1 MMU-table. This isn't really useful: the data can't be controlled, and the data which gets overwritten is all-zero anyway(this isn't anywhere near MMU L1 entries for actually mapped memory).<br />
The previous version also allowed large negative s32_processorid values(negative processorid values are special values not actual procids), but it appears using values like that won't actually do anything(meaning no crash) besides the thread not running / thread not running for a while(besides triggering a kernelpanic with certain s32_processorid value(s)).<br />
| Nothing useful<br />
| [[10.0.0-27|10.0.0-X]]<br />
| [[10.0.0-27|10.0.0-X]]<br />
| svcCreateThread issue: May 31, 2015. The rest: September 8, 2015, via v9.6->v10.0 ARM11-kernel code-diff.<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| memchunkhax<br />
| The kernel originally did not validate the data stored in the FCRAM kernel heap [[Memchunkhdr|memchunk-headers]] for free-memory at all. Exploiting this requires raw R/W access to these memchunk-headers, like physical-memory access with gspwn.<br />
<br />
There are ''multiple'' ways to exploit this, but the end-result for most of these is the same: overwrite code in AXIWRAM via the 0xEFF00000/0xDFF00000 kernel virtual-memory mapping.<br />
<br />
This was fixed in [[9.3.0-21|9.3.0-X]] by checking that the memchunk(including size, next, and prev ptrs) is located within the currently used heap memory. The kernel may also check that the next/prev ptrs are valid compared to other memchunk-headers basically. When any of these checks fail, kernelpanic() is called.<br />
| When combined with other flaws: ARM11-kernelmode code execution<br />
| [[9.3.0-21|9.3.0-21]]<br />
| <br />
| February 2014<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| Multiple [[KLinkedListNode|KLinkedListNode]] SlabHeap use after free bugs<br />
| The ARM11-kernel did access the 'key' field of [[KLinkedListNode|KLinkedListNode]] objects, which are located on the SlabHeap, after freeing them. Thus, triggering an allocation of a new [[KLinkedListNode|KLinkedListNode]] object at the right time could result in a type-confusion. Pseudo-code:<br />
SlabHeap_free(KLinkedListNode);<br />
KObject *obj = KLinkedListNode->key; // the object there might have changed!<br />
This bug appeared all over the place.<br />
| ARM11-kernelmode code exec maybe<br />
| [[8.0.0-18|8.0.0-18]]<br />
| <br />
| April 2015<br />
| [[User:Derrek|derrek]]<br />
|-<br />
| PXI [[RPC_Command_Structure|Command]] input/output buffer permissions<br />
| Originally the ARM11-kernel didn't check permissions for PXI input/output buffers for commands. Starting with [[6.0.0-11|6.0.0]] PXI input/output buffers must have RW permissions, otherwise kernelpanic is triggered.<br />
| <br />
| [[6.0.0-11|6.0.0-11]]<br />
| <br />
| 2012<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[SVC|svcStartInterProcessDma]]<br />
| For svcStartInterProcessDma, the kernel code had the following flaws:<br />
<br />
* Originally the ARM11-kernel read the input DmaConfig structure directly in kernel-mode(ldr(b/h) instructions), without checking whether the DmaConfig address is readable under userland. This was fixed by copying that structure to the SVC-mode stack, using the ldrbt instruction.<br />
<br />
* Integer overflows for srcaddr+size and dstaddr+size are now checked(with [[6.0.0-11]]), which were not checked before.<br />
<br />
* The kernel now also checks whether the srcaddr/dstaddr (+size) is within userland memory (0x20000000), the kernel now (with [[6.0.0-11]]) returns an error when the address is beyond userland memory. Using an address >=0x20000000 would result in the kernel reading from the process L1 MMU table, beyond the memory allocated for that MMU table(for vaddr->physaddr conversion). <br />
| <br />
| [[6.0.0-11]]<br />
| <br />
| DmaConfig issue: unknown. The rest: 2014<br />
| [[User:Plutooo|plutoo]], [[User:Yellows8|Yellows8]] independently<br />
|-<br />
| [[SVC|svcControlMemory]] Parameter checks<br />
| For svcControlMemory the parameter check had these two flaws:<br />
<br />
* The allowed range for addr0, addr1, size parameters depends on which MemoryOperation is being specified. The limitation for GSP heap was only checked if op=(u32)0x10003. By setting a random bit in op that has no meaning (like bit17?), op would instead be (u32)0x30003, and the range-check would be less strict and not accurate. However, the kernel doesn't actually use the input address for LINEAR memory-mapping at all besides the range-checks, so this isn't actually useful. This was fixed in the kernel by just checking for the LINEAR bit, instead of comparing the entire MemoryOperation value with 0x10003.<br />
<br />
* Integer overflows on (addr0+size) are now checked that previously weren't (this also applies to most other address checks elsewhere in the kernel).<br />
<br />
| <br />
| [[5.0.0-11]]<br />
| <br />
|<br />
| [[User:Plutooo|plutoo]]<br />
|-<br />
| [[RPC_Command_Structure|Command]] request/response buffer overflow<br />
| Originally the kernel did not check the word-values from the command-header. Starting with [[5.0.0-11]], the kernel will trigger a kernelpanic() when the total word-size of the entire command(including the cmd-header) is larger than 0x40-words (0x100-bytes). This allows overwriting threadlocalstorage+0x180 in the destination thread. However, since the data written there would be translate parameters (such as header-words + buffer addresses), exploiting this would likely be very difficult, if possible at all.<br />
<br />
If the two words at threadlocalstorage+0x180 could be overwritten with controlled data this way, one could then use a command with a buffer-header of <nowiki>((size<<14) | 2)</nowiki> to write arbitrary memory to any RW userland memory in the destination process.<br />
| <br />
| [[5.0.0-11]]<br />
| <br />
| v4.1 FIRM -> v5.0 code diff<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[SVC|SVC stack allocation overflows]]<br />
| <br />
* Syscalls that allocate a variable-length array on stack, only checked bit31 before multiplying by 4/16 (when calculating how much memory to allocate). If a large integer was passed as input to one of these syscalls, an integer overflow would occur, and too little memory would have been allocated on stack resulting in a buffer overrun. <br />
* The alignment (size+7)&~7 calculation before allocation was not checked for integer overflow.<br />
<br />
This might allow for ARM11 kernel code-execution.<br />
<br />
(Applies to svcSetResourceLimitValues, svcGetThreadList, svcGetProcessList, svcReplyAndReceive, svcWaitSynchronizationN.)<br />
| <br />
| [[5.0.0-11]]<br />
| <br />
| v4.1 FIRM -> v5.0 code diff<br />
| [[User:Plutooo|plutoo]], [[User:Yellows8|Yellows8]] complementary<br />
|-<br />
| [[SVC|svcControlMemory]] MemoryOperation MAP memory-permissions<br />
| svcControlMemory with MemoryOperation=MAP allows mapping the already-mapped process virtual-mem at addr1, to addr0. The lowest address permitted for addr1 is 0x00100000. Originally the ARM11 kernel didn't check memory permissions for addr1. Therefore .text as addr1 could be mapped elsewhere as RW- memory, which allowed ARM11 userland code-execution.<br />
| <br />
| [[4.1.0-8]]<br />
| <br />
| 2012<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[RPC_Command_Structure|Command]] input/output buffer permissions<br />
| Originally the ARM11 kernel didn't check memory permissions for the input/output buffers for commands. Starting with [[4.0.0-7]] the ARM11 kernel will trigger a kernelpanic() if the input/output buffers don't have the required memory permissions. For example, this allowed a FSUSER file-read to .text, which therefore allowed ARM11-userland code execution.<br />
| <br />
| [[4.0.0-7]]<br />
| <br />
| 2012<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[SVC|svcReadProcessMemory/svcWriteProcessMemory memory]] permissions<br />
| Originally the kernel only checked the first page(0x1000-bytes) of the src/dst buffers, for svcReadProcessMemory and svcWriteProcessMemory. There is no known retail processes which have access to these SVCs.<br />
| <br />
| [[4.0.0-7]]<br />
| <br />
| 2012?<br />
| [[User:Yellows8|Yellows8]]<br />
|}<br />
<br />
=== [[FIRM]] Sysmodules ===<br />
{| class="wikitable" border="1"<br />
|-<br />
! Summary<br />
! Description<br />
! Successful exploitation result<br />
! Fixed in [[FIRM]] system version<br />
! Last [[FIRM]] system version this flaw was checked for<br />
! Timeframe this was discovered<br />
! Discovered by<br />
|-<br />
| [[Services|"srv:pm"]] process registration<br />
| Originally any process had access to the port "srv:pm". The PID's used for the (un)registration commands are not checked either. This allowed any process to re-register itself with "srv:pm", and therefore allowed the process to give itself access to any service, bypassing the exheader service-access-control list.<br />
<br />
This was fixed in [[7.0.0-13]]: starting with [[7.0.0-13]] "srv:pm" is now a service instead of a globally accessible port. Only processes with PID's less than 6 (in other words: fs, ldr, sm, pm, pxi modules) have access to it. With [[7.0.0-13]] there can only be one session for "srv:pm" open at a time(this is used by pm module), svcBreak will be executed if more sessions are opened by the processes which can access this.<br />
<br />
This flaw was needed for exploiting the <=v4.x Process9 PXI vulnerabilities from ARM11 userland ROP, since most applications don't have access to those service(s).<br />
| Access to arbitrary services<br />
| [[7.0.0-13]]<br />
| <br />
| 2012<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| FSDIR null-deref<br />
| [[Filesystem_services|FS]]-module may crash in some cases when handling directory reading. The trigger seems to be due to using [[FSDir:Close]] without closing the dir-handle afterwards?(Perhaps this is caused by out-of-memory?) This seems to be useless since it's just a null-deref.<br />
| <br />
| None<br />
| [[9.6.0-24|9.6.0-X]]<br />
| May 19(?)-20, 2015<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[SM]] out-of-bounds BSS write (table 1 entry too small)<br />
| After accepting a new session, [[SM]] writes a (handler ID (0 for srv: sessions (max. 64), 1 for the srv:pm one), pointer to session context structure in BSS) pair in a global array. However that array is only 64-entry-big instead of 65 (as it ought to be), and no bound check is done in that regard.<br />
<br />
Unfortunately, as of [[11.4.0-37]], the overwritten fields are totally unused after their initialization by <code>__libc_init_array</code>.<br />
| Not currently exploitable<br />
| None<br />
| [[11.4.0-37]]<br />
|<br />
|<br />
|}<br />
<br />
=== Standalone Sysmodules ===<br />
{| class="wikitable" border="1"<br />
|-<br />
! Summary<br />
! Description<br />
! Successful exploitation result<br />
! Fixed in system-module system-version<br />
! Last system-module system-version this flaw was checked for<br />
! Timeframe this was discovered<br />
! Timeframe this was added to wiki<br />
! Discovered by<br />
|-<br />
| [[MP:SendDataFrame]] missing input array index validation<br />
| [[MP:SendDataFrame]] doesn't validate the input index at cmdreq[1], unless the function for flag=non-zero is executed. This is used to calculate the following, without validating the index at all: someptr = stateptr + (index*0x924) + somestateoffset.<br />
<br />
After validating some flags from someptr, when input_flag=0 the input buffer data is copied to someptr+someotheroffset+0x14 with the u16 size loaded from someptr+someotheroffset.<br />
<br />
With a large input index someptr could be setup to be at a <target address>, for overwriting memory.<br />
<br />
This is probably difficult to exploit.<br />
| <br />
| None<br />
| [[8.0.0-18]](MP-sysmodule v2048)<br />
| January 22, 2017<br />
| January 22, 2017<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[MP_Services|MP]] cmd1 out-of-bounds handle read<br />
| MP-sysmodule handles the input parameter for cmd1 as a s32. It checks for >=16, but not <0. With <16 it basically does the following(array of entries 4-bytes each): *outhandle = ((Handle*)(stateptr+offsetinstate))[inputindex].<br />
<br />
Hence, this can be used to load any handle in MP-sysmodule memory. MP doesn't really have any service handles of interest however(can be obtained from elsewhere too).<br />
| Reading any handle in MP-sysmodule memory.<br />
| None<br />
| [[8.0.0-18]](MP-sysmodule v2048)<br />
| January 21, 2017<br />
| January 22, 2017<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| AM stack/.bss infoleak via [[AM:ReadTwlBackupInfo]]([[AM:ReadTwlBackupInfoEx|Ex]])<br />
| After writing the output-info structure to stack, it then copies that structure to the output buffer ptr using the size from the command. The size is not checked. This could be used to read data from the AM-service-thread stack handling the command + .bss.<br />
<br />
'''This was not tested on hardware.'''<br />
| Stack/.bss reading<br />
| None<br />
| [[10.0.0-27]](AM v9217)<br />
| Roughly October 17, 2016<br />
| October 25, 2016<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[MVD_Services|MVD]]: Stack buffer overflow with [[MVDSTD:SetupOutputBuffers]].<br />
| The input total_entries is not validated when initially processing the input entry-list. This fixed-size input entry-list is copied to stack from the command request. The loop for processing this initializes a global table, the converted linearmem->physaddrs used there are also copied to stack(0x8-bytes of physaddrs per entry).<br />
<br />
If total_entries is too large, MVD-sysmodule will crash due to reading unmapped memory following the stack(0x10000000). Afterwards if the out-of-bounds total_entries is smaller than that, it will crash due accessing address 0x0, hence this useless.<br />
| MVD-sysmodule crash.<br />
| None<br />
| [[9.0.0-20]]<br />
| April 22, 2016 (Tested on the 25th)<br />
| April 25, 2016<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[NWM_Services|NWM]]: Using CTRSDK heap with UDS sharedmem from the user-process.<br />
| See the HTTP-sysmodule section below.<br />
<br />
CTRSDK heap is used with the sharedmem from [[NWMUDS:InitializeWithVersion]]. Buffers are allocated/freed under this heap using [[NWMUDS:Bind]] and [[NWMUDS:Unbind]].<br />
<br />
Hence, overwriting sharedmem with gspwn then using [[NWMUDS:Unbind]] results in the usual controlled CTRSDK memchunk-header write, similar to HTTP-sysmodule.<br />
<br />
This could be done by creating an UDS network, without any other nodes on the network.<br />
<br />
Besides CTRSDK memchunk-headers, there are no addresses stored under this sharedmem.<br />
| ROP under NWM-module.<br />
| [[11.4.0-37|11.4.0-X]]<br />
| [[9.0.0-20|9.0.0-X]]<br />
| April 10, 2016<br />
| April 16, 2016<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[DLP_Services|DLP]]: Out-of-bounds memory access during spectator [[Download_Play|data-frame]] checksum calculation<br />
| DLP doesn't validate the frame_size when receiving spectator data-frames at all, unlike non-spectator data-frames. The actual spectator data-frame parsing code doesn't use that field either. However, the data-frame checksum calculation code called during checksum verification does use the frame_size for loading the size of the framebuf.<br />
<br />
Hence, using a large frame_size like 0xFFFF will result in the checksum calculation code reading data out-of-bounds. This isn't really useful, you could trigger a remote local-WLAN DLP-sysmodule crash while a 3DS system is scanning for DLP networks(due to accessing unmapped memory), but that's about all(trying to infoleak with this likely isn't useful either).<br />
| DLP-sysmodule crash, handled by dlplay system-application by a "connection interrupted" error eventually then a fatal-error via ErrDisp.<br />
| None<br />
| [[10.0.0-27|10.0.0-X]]<br />
| April 8, 2016 (Tested on the 10th)<br />
| April 10, 2016<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[DLP_Services|DLP]]: Out-of-bounds output data writing during spectator sysupdate titlelist [[Download_Play|data-frame]] handling<br />
| The total_entries and out_entryindex fields for the titlelist DLP spectator data-frames are not validated. This is parsed during DLP network scanning. Hence, the specified titlelist data can be written out-of-bounds using the specified out_entryindex and total_entries. A crash will occur while reading the input data-frame titlelist if total_entries is larger than 0x27A, due to accessing unmapped memory.<br />
<br />
There's not much non-zero data to overwrite following the output buffer(located in sharedmem), any ptrs are located in sharedmem. Overwriting certain ptr(s) are only known to cause a crash when attempting to use the DLP-client shutdown service-command.<br />
<br />
There's no known way to exploit the above crash, since the linked-list code involves writes zeros(with a controlled start ptr).<br />
| <br />
| None<br />
| [[10.0.0-27|10.0.0-X]]<br />
| April 8-9, 2016<br />
| April 10, 2016<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[IR_Services|IR]]: Stack buffer overflow with custom hardware<br />
| Originally IR sysmodule used the read value from the I2C-IR registers TXLVL and RXLVL without validating them at all. See [[10.6.0-31|here]] for the fix. This is the size used for reading the data-recv FIFO, etc. The output buffer for reading is located on the stack.<br />
<br />
This should be exploitable if one could successfully setup the custom hardware for this and if the entire intended sizes actually get read from I2C.<br />
| ROP under IR sysmodule.<br />
| [[10.6.0-31|10.6.0-31]]<br />
| <br />
| February 23, 2016 (Unknown if it was noticed before then)<br />
| February 23, 2016<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[HTTP_Services|HTTP]]: Using CTRSDK heap with sharedmem from the user-process.<br />
| The data from httpcAddPostDataAscii and other commands is stored under a CTRSDK heap. That heap is the sharedmem specified by the user-process via the HTTPC Initialize command.<br />
Normally this sharedmem isn't accessible to the user-process once the sysmodule maps it, hence using it is supposed to be "safe".<br />
<br />
This isn't the case due to gspwn however. Since CTRSDK heap code is so insecure in general, one can use gspwn to locate the HTTPC sharedmem + read/write it, then trigger a mem-write under the sysmodule. This can then be used to get ROP going under HTTP-sysmodule.<br />
<br />
This is exploited by [https://github.com/yellows8/ctr-httpwn/ctr-httpwn ctr-httpwn].<br />
| ROP under HTTP sysmdule.<br />
| [[11.4.0-37|11.4.0-X]]<br />
| [[9.6.0-24|9.6.0-X]] (Latest sysmodule version as of [[10.7.0-32|10.7.0-32]])<br />
| Late 2015<br />
| March 22, 2016<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[NIM_Services|NIM]]: Downloading old title-versions from eShop<br />
| Multiple NIM service commands(such as [[NIMS:StartDownload]]) use a title-version value specified by the user-process, NIM does not validate that this input version matches the latest version available via SOAP. Therefore, when combined with AM(PXI) [[#Process9|title-downgrading]] via deleting the target eShop title with System Settings Data Management(if the title was already installed), this allows downloading+installing any title-version from eShop ''if'' it's still available from CDN.<br />
The easiest way to exploit this is to just patch the eShop system-application code using these NIM commands(ideally the code which loads the title-version).<br />
<br />
Originally this was tested with a debugging-system via modded-FIRM, eventually smea implemented it in HANS for the 32c3 release.<br />
| Downloading old title-versions from eShop<br />
| None<br />
| [[10.0.0-27|10.0.0-X]]<br />
| October 24, 2015 (Unknown when exactly the first eShop title downgrade was actually tested, maybe November)<br />
| January 7, 2016 (Same day Ironfall v1.0 was removed from CDN via the main-CXI files)<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[SPI_Services|SPI]] service out-of-bounds write<br />
| cmd1 has out-of-bounds write allowing overwrite of some static variables in .data.<br />
| <br />
| None<br />
| [[9.5.0-22]]<br />
| March 2015<br />
| <br />
| [[User:Plutooo|plutoo]]<br />
|-<br />
| [[NFC_Services|NFC]] module service command buf-overflows<br />
| NFC module copies data with certain commands, from command input buffers to stack without checking the size. These commands include the following, it's unknown if there's more commands with similar issues: "nfc:dev" <0x000C....> and "nfc:s" <0x0037....>.<br />
Since both of these commands are stubbed in the Old3DS NFC module from the very first version(those just return an error), these issues only affect the New3DS NFC module.<br />
<br />
There's no known retail titles which have access to either of these services.<br />
| ROP under NFC module.<br />
| New3DS: None<br />
| New3DS: [[9.5.0-22]]<br />
| December 2014?<br />
| <br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[News_Services|NEWSS]] service command notificationID validation failure<br />
| This module does not validate the input notificationID for <nowiki>"news:s"</nowiki> service commands. This is an out-of-bounds array index bug. For example, [[NEWSS:SetNotificationHeader]] could be used to exploit news module: this copies the input data(size is properly checked) to: out = newsdb_savedata+0x10 + (someu32array[notificationID]*0x70).<br />
| ROP under news module.<br />
| None<br />
| [[9.7.0-25|9.7.0-X]]<br />
| December 2014<br />
| <br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[NWMUDS:DecryptBeaconData]] heap buffer overflow<br />
| input_size = 0x1E * <value the u8 from input_[[NWM_Services|networkstruct]]+0x1D>. Then input_tag0 is copied to a heap buffer. When input_size is larger than 0xFA-bytes, it will then copy input_tag1 to <end_address_of_previous_outbuf>, with size=input_size-0xFA.<br />
<br />
This can be triggered by either using this command directly, or by boadcasting a wifi beacon which triggers it while a 3DS system running the target process is in range, when the process is scanning for hosts to connect to. Processes will only pass tag data to this command when the wlancommID and other thing(s) match the values for the process.<br />
<br />
There's no known way to actually exploit this for getting ROP under NWM-module, at the time of originally adding this to the wiki. This is because the data which gets copied out-of-bounds *and* actually causes crash(es), can't be controlled it seems(with just broadcasting a beacon at least). It's unknown whether this could be exploited from just using NWMUDS service-cmd(s) directly.<br />
| Without any actual way to exploit this: NWM-module DoS, resulting in process termination(process crash). This breaks *everything* involving wifi comms, a reboot is required to recover from this.<br />
| None<br />
| [[9.0.0-20]]<br />
| ~September 23, 2014(see the [[NWMUDS:DecryptBeaconData]] page history)<br />
| August 3, 2015<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[HID_Services|HID]] module shared-mem<br />
| HID module does not validate the index values in [[HID_Shared_Memory|sharedmem]](just changes index to 0 when index == maxval when updating), therefore large values will result in HID module writing HID data to arbitrary addresses.<br />
| ROP under HID module, but this is *very* unlikely to be exploitable since the data written is HID data.<br />
| None<br />
| [[9.3.0-21]]<br />
| 2014?<br />
| <br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| gspwn<br />
| GSP module does not validate addresses given to the GPU. This allows a user-mode application/applet to read/write to a large part of physical FCRAM using GPU DMA. From this, you can overwrite the .text segment of the application you're running under, and gain real code-execution from a ROP-chain. Normally applets' .text([[Home Menu]], [[Internet Browser]], etc) is located beyond the area accessible by the GPU, except for [[RO_Services|CROs]] used by applets([[Internet Browser]] for example).<br />
<br />
FCRAM is gpu-accessible up to physaddr 0x26800000 on Old3DS, and 0x2D800000 on New3DS. This is BASE_memregion_start(aka SYSTEM_memregion_end)-0x400000 (0x800000 with New3DS) with the default memory-layout on Old3DS/New3DS. With [[11.3.0-36|11.3.0-X]] the cutoff now varies due to the new [[SVC]] 0x59. The New3DS "normal"(non-APPLICATION) cutoff was changed to 0x2D000000 due to the new [[SVC]] 0x59.<br />
| User-mode code execution.<br />
| None<br />
| [[9.6.0-24|9.6.0-X]]<br />
| Early 2014<br />
| <br />
| smea, [[User:Yellows8|Yellows8]]/others before then<br />
|-<br />
| rohax<br />
| Using gspwn, it is possible to overwrite a loaded [[CRO0]]/[[CRR0]] after its RSA-signature has been validated. Badly validated [[CRO0]] header leads to arbitrary read/write of memory in the ro-process. This gives code-execution in the ro module, who has access to [[SVC|syscalls]] 0x70-0x72, 0x7D.<br />
<br />
This was fixed after [[ninjhax]] release by adding checks on [[CRO0]]-based pointers before writing to them.<br />
| Memory-mapping syscalls.<br />
| [[9.3.0-21]]<br />
| [[9.4.0-21]]<br />
| <br />
| <br />
| smea, [[User:Plutooo|plutoo]] joint effort<br />
|-<br />
| Region free<br />
| Only [[Home Menu]] itself checks gamecards' region when launching them. Therefore, any application launch that is done directly with [[NS]] without signaling Home Menu to launch the app, will result in region checks being bypassed.<br />
This essentially means launching the gamecard with the [[NS_and_APT_Services|"ns:s"]] service. The main way to exploit this is to trigger a FIRM launch with an application specified, either with a normal FIRM launch or a hardware [[NSS:RebootSystem|reboot]].<br />
| Launching gamecards from any region + bypassing Home Menu gamecard-sysupdate installation<br />
| None<br />
| Last tested with [[10.1.0-27|10.1.0-X]].<br />
| June(?) 2014<br />
| <br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[NWM_Services|NWM]] service-cmd state null-ptr deref<br />
| The NWMUDS service command code loads a ptr from .data, adds an offset to that, then passes that as the state address for the actual command-handler function. The value of the ptr loaded from .data is not checked, therefore this will cause crashes due to that being 0x0 when NWMUDS was not properly initialized.<br />
It's unknown whether any NWM services besides NWMUDS have this issue.<br />
| This is rather useless since it's only a crash caused by a state ptr based at 0x0.<br />
| None<br />
| [[9.0.0-20]]<br />
| 2013?<br />
| <br />
| [[User:Yellows8|Yellows8]]<br />
|}<br />
<br />
=== General/CTRSDK ===<br />
{| class="wikitable" border="1"<br />
|-<br />
! Summary<br />
! Description<br />
! Successful exploitation result<br />
! Fixed in version<br />
! Last version this flaw was checked for<br />
! Timeframe this was discovered<br />
! Discovered by<br />
|-<br />
| [[NWM_Services|UDS]] beacon additional-data buffer overflow<br />
| Originally CTRSDK did not validate the UDS additional-data size before using that size to copy the additional-data to a [[NWM_Services|networkstruct]]. This was eventually fixed.<br />
This was discovered while doing code RE with an old dlp-module version. It's unknown in what specific CTRSDK version this was fixed, or even what system-version updated titles with a fixed version.<br />
<br />
It's unknown if there's any titles using a vulnerable CTRSDK version which are also exploitable with this(dlp module can't be exploited with this).<br />
<br />
The maximum number of bytes that can be written beyond the end of the outbuf is 0x37-bytes, with additionaldata_size=0xFF.<br />
| Perhaps ROP, very difficult if possible with anything at all<br />
| ?<br />
| <br />
| September(?) 2014<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| CTPK buffer overflow<br />
| At offset 0x20 in CTPK is an array for each texture, each entry is 0x20-bytes. This contains a wordindex(entry+0x18) for some srcdata relative to CTPK+0, and an u8 wordsize(entry+0x14) for this data. The CTRSDK function handling this doesn't validate the size, when copying srcdata using this size to the output buffer. Applications usually have the output buffer on the stack, hence stack buffer overflow.<br />
<br />
While CTPK(*.ctpk) are normally only loaded from RomFS, some application(s) load from elsewhere too.<br />
| ROP under the target application.<br />
| None?<br />
| "[SDK+NINTENDO:CTR_SDK-11_4_0_200_none]"<br />
| November 14, 2016<br />
| [[User:Yellows8|Yellows8]]<br />
|}</div>Myriahttps://www.3dbrew.org/w/index.php?title=3DS_System_Flaws&diff=208133DS System Flaws2018-08-12T07:00:49Z<p>Myria: /* Process9 */ smea's twlhax presentation</p>
<hr />
<div>Exploits are used to execute unofficial code (homebrew) on the Nintendo 3DS. This page is a list of publicly known system flaws, for userland applications/applets flaws see [[3DS_Userland_Flaws|here]].<br />
<br />
=Stale / Rejected Efforts=<br />
* Neimod has been working on a RAM dumping setup for a little while now. He's de-soldered the 3DS's RAM chip and hooked it and the RAM pinouts on the 3DS' PCB up to a custom RAM dumping setup. A while ago he published photos showing his setup to be working quite well, with the 3DS successfully booting up. However, his flickr stream is now private along with most of his work.<br />
<br />
* Someone (who will remain unnamed) has released CFW and CIA installers, all of which is copied from the work of others, or copyrighted material.<br />
<br />
==Tips and info==<br />
The 3DS uses the XN feature of the ARM11 processor. There's no official way from applications to enable executable permission for memory containing arbitrary unsigned code(there's a [[SVC]] for this, but only [[RO_Services|RO-module]] has access to it). A usable userland exploit would still be useful: you could only do return-oriented-programming with it initially. From ROP one could then exploit system flaw(s), see below.<br />
<br />
SD card [[extdata]] and SD savegames can be attacked, for consoles where the console-unique [[Nand/private/movable.sed|movable.sed]] was dumped(accessing SD data is far easier by running code on the target 3DS however).<br />
<br />
=System flaws=<br />
== Hardware ==<br />
{| class="wikitable" border="1"<br />
! Summary<br />
! Description<br />
! Fixed with hardware model/revision<br />
! Newest hardware model/revision this flaw was checked for<br />
! Timeframe this was discovered<br />
! Discovered by<br />
|-<br />
| ARM9/ARM11 bootrom vectors point at uninitialized RAM<br />
| ARM9's and ARM11's exception vectors are hardcoded to point at the CPU's internal memory (0x08000000 region for ARM9, AXIWRAM for ARM11). While the bootrom does set them up to point to an endless loop at some point during boot, it does not do so immediately. As such, a carefully-timed fault injection (via hardware) to trigger an exception (such as an invalid instruction) will cause execution to fall into ARM9 RAM. <br />
Since RAM isn't cleared on boot (see below), one can immediately start execution of their own code here to dump bootrom, OTP, etc.<br />
The ARM9 bootrom does the following at reset: reset vector branches to another instruction, then branches to bootrom+0x8000. Hence, there's no way to know for certain when exactly the ARM9 exception-vector data stored in memory gets initialized.<br />
<br />
This requires *very* *precise* timing for triggering the hardware fault.<br />
<br />
It has been exploited by derrek to dump the ARM9 bootrom as of Summer 2015.<br />
| None: all available 3DS models at the time of writing have the exact same ARM9/ARM11 bootrom for the unprotected areas.<br />
| New3DS<br />
| End of February 2014<br />
| [[User:Derrek|derrek]], WulfyStylez (May 2015) independently<br />
|-<br />
| Missing AES key clearing<br />
| The hardware AES engine does not clear keys when doing a hard reset/reboot.<br />
| None<br />
| New3DS<br />
| August 2014<br />
| Mathieulh/Others<br />
|-<br />
| No RAM clearing on reboots<br />
| On an MCU-triggered reboot all RAM including FCRAM/ARM9 memory/AXIWRAM/VRAM keeps its contents.<br />
| None<br />
| New3DS<br />
| March 2014<br />
| [[User:Derrek|derrek]]<br />
|-<br />
| 32bits of actual console-unique TWLNAND keydata<br />
| On retail the 8-bytes at ARM9 address [[Memory_layout|0x01FFB808]] are XORed with hard-coded data, to generate the TWL console-unique keys, including TWLNAND. On Old3DS the high u32 is always 0x0, while on New3DS that u32 is always 0x2. On top of this, the lower u32's highest bit is always ORed. only 31 bits of the TWL console-unique keydata / TWL consoleID are actually console-unique.<br />
This allows one to easily bruteforce the TWL console-unique keydata with *just* data from TWLNAND. On DSi the actual console-unique data for key generation is 8-bytes(all bytes actually set).<br />
| None<br />
| New3DS<br />
| 2012?<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| DSi / 3DS-TWL key-generator<br />
| After using the key generator to generate the normal-key, you could overwrite parts of the normal-key with your own data and then recover the key-generator output by comparing the new crypto output with the original crypto output. From the normal-key outputs, you could deduce the TWL key-generator function.<br />
This applies to the keyX/keyY too.<br />
<br />
This attack does not work for the 3DS key-generator because keyslots 0-3 are only for TWL keys.<br />
| None<br />
| New3DS<br />
| 2011<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| 3DS key-generator<br />
| The algorithm for generating the normal-keys for keyslots is cryptographically weak. As a result, it is easily susceptible to differential cryptanalysis if the normal-key corresponding to any scrambler-generated keyslot is discovered.<br />
<br />
Several such pairs of matching normal-keys and KeyY values were found, leading to deducing the key-generator function.<br />
| None<br />
| New3DS<br />
| February 2015<br />
| [[User:Yellows8|Yellows8]], [[User:Plutooo|plutoo]]<br />
|-<br />
| RSA keyslots don't clear exponent when setting modulus<br />
| The [[RSA_Registers|RSA keyslots]] are set by boot ROM to have four private RSA keys. The exponent value in the RSA registers is write-only and not readable.<br />
<br />
However, when setting a keyslot's modulus, the RSA hardware leaves the exponent alone. This allows retrieving the exponent by doing a discrete logarithm of the output.<br />
<br />
By setting the modulus to a prime number whose modular multiplicative order is "smooth" (that is, p-1 is divisible by only small prime numbers), discrete logarithms can be calculated quickly using the [[wikipedia:Pohlig-Hellman algorithm|Pohlig-Hellman algorithm]]. If the prime chosen is greater than the modulus, but the same bit size, the discrete logarithm is the private exponent.<br />
<br />
This exploit's usefulness is limited: RSA keyslot 0 is only used in current firmware for deriving the 6.x save and 7.x NCCH keys, which were already known, and the other three keyslots are entirely unused. Additionally, with a boot ROM dump, this exploit is moot; these private keys are located in the protected ARM9 boot ROM.<br />
| None<br />
| New3DS<br />
| March 2016<br />
| [[User:Myria|Myria]]<br />
|-<br />
| [[CONFIG11_Registers#CFG11_GPUPROT|CFG11_GPUPROT]] allowing acccess to AXIWRAM/FCRAM-BASE-memregion<br />
| [[CONFIG11_Registers#CFG11_GPUPROT|CFG11_GPUPROT]] can be configured by anything with access to it to allow the GPU to access the entire AXIWRAM+FCRAM. For example, this is an issue for any sysmodule that gets exploited and has access to this register memory-page(include one that's listed below).<br />
<br />
See also "kernelhax via gspwn" below.<br />
| None<br />
| New3DS<br />
| February 7, 2017<br />
| [[User:Yellows8|Yellows8]]<br />
|}<br />
<br />
== Boot ROM ==<br />
{| class="wikitable" border="1"<br />
! Summary<br />
! Description<br />
! Fixed with hardware model/revision<br />
! Newest hardware model/revision this flaw was checked for<br />
! Timeframe this was discovered<br />
! Discovered by<br />
|-<br />
| FIRM partitions known-plaintext<br />
| The [[Flash_Filesystem|FIRM partitions]] are encrypted with AES-CTR without a MAC. Since this works by XOR'ing data with a static (per-console in this case) keystream, one can deduce the keystream of a portion of each FIRM partition if they have the actual FIRM binary stored in it.<br />
<br />
This can be paired with many exploits. For example, it allows minor FIRM downgrades (i.e. 10.4 to 9.6 or 9.5 to 9.4, but not 9.6 to 9.5).<br />
However it is most commonly used to install arbitrary FIRMs (usually boot9strap), thanks to sighax.<br />
<br />
This can be somewhat addressed by having a FIRM header skip over previously used section offsets, but this would just air-gap newer FIRMs without fixing the core bug. This can also only be done a limited number of times due to the size of FIRM versus the size of the partitions.<br />
| None<br />
| New3DS<br />
| <br />
| Everyone<br />
|-<br />
| Boot9 AES keyinit function issues<br />
| [[Bootloader|Boot9]] seems to have two bugs in the AES key-init function, see [[AES_Registers#AES_key-init|here]].<br />
| None<br />
| BootROM issue.<br />
| 2015<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| New3DS has same boot ROM as Old3DS<br />
| The New3DS has the exact same boot ROM as the Old3DS. This means, among other things, that all the same boot ROM flaws are present. Also, this meant that it is possible to boot Old3DS firmware on New3DS (see "CFG_SYSPROT9 bit1 not set by Kernel9").<br />
| None<br />
| New3DS<br />
| October 2014<br />
| Everyone<br />
|-<br />
| sighax: Boot9 improper validation of FIRM partition RSA signatures<br />
| The [[Flash_Filesystem|FIRM partitions]] are signed with RSA-2048 using SHA-256 and PKCS #1 v1.5 padding. Boot9, however, improperly validates the padding in three ways:<br />
# Boot9 permits block type 02, meant for encrypted messages, to be used for signatures. Only 01, for signatures, should have been permitted. As a result, when using block type 02, a signature block is not required to have a long string of FF bytes as padding, but rather any nonzero random values suffice.<br />
# Boot9 does not require that the length of the padding fill out the signature block completely. As a result, there is considerable freedom in the layout of a signature.<br />
# Boot9 fails to do bounds checking in its parsing of the DER-encoded hash algorithm type and hash value; the length values given in DER are permitted to point outside the signature block.<br />
Flaw 3 allows the DER encoding to be such that boot9 believes that the signature's hash value is outside the range of the block itself, somewhere on the stack. This can be pointed at the correct hash value it computes. Boot9 then memcmp's the calculated hash against itself, and thinks that the hash is valid.<br />
<br />
As a result of the above, we estimate that one in 2<sup>43</sup> (~8.8 trillion) random fake signatures will be considered by Boot9 to be valid. This is well within the range of brute force, particularly with an optimized GPU implementation. An Nvidia GTX 1080 Ti would take about one week to find a match.<br />
| None<br />
| New3DS<br />
| July 2015<br />
| [[User:Derrek|derrek]]<br />
|-<br />
| Boot9 FIRM loading doesn't blacklist memory-mapped I/O<br />
| [[Bootloader|Boot9]]'s FIRM loading blacklists Boot9 data regions, but forgets to do other important regions, including Memory-mapped I/O. Combined with sighax, by loading a malicious FIRM section to MMIO, one can get Boot9/Boot11 code execution. <br />
| None<br />
| New3DS<br />
| 2015(?)<br />
| [[User:Derrek|derrek]] (2015?), [[User:Normmatt|Normmatt]] and [[User:SciresM|SciresM]] independently (January 2017).<br />
|-<br />
| "superhax": Boot9 FIRM loading blacklist check is flawed<br />
| Boot9 only makes sure the '''start''' and '''end''' address of each section is not covered by a blacklisted region. Thus, it is possible to overwrite blacklisted regions (e.g. ARM9 Exception Vectors) by choosing a FIRM section range that encloses an entire blacklisted region. The vulnerable code looks like this: if(blRegions[i].start <= sectionStart && blRegions[i].end > sectionStart <nowiki>||</nowiki> blRegions[i].start <= sectionEnd && blRegions[i].end > sectionEnd) return false; // failure<br />
| None<br />
| New3DS<br />
| August 2015<br />
| [[User:Plutoo|plutoo]], [[User:Yellows8|yellows8]]<br />
|}<br />
<br />
== ARM9 software ==<br />
<br />
=== arm9loader ===<br />
{| class="wikitable" border="1"<br />
|-<br />
! Summary<br />
! Description<br />
! Successful exploitation result<br />
! Fixed in [[FIRM]] system version<br />
! Last [[FIRM]] system version this flaw was checked for<br />
! Timeframe this was discovered<br />
! Public disclosure timeframe<br />
! Discovered by<br />
|-<br />
| Generating the keysector console-unique keys with ITCM+Boot9<br />
| [[Bootloader|Boot9]] decrypts the 0x100-byte [[OTP_Registers|OTP]] using AES-CBC with keydata stored in Boot9. If hash verification is successful, the plaintext of the first 0x90-bytes are copied into [[Memory_layout|ITCM]]. This is the ''exact'' ''same'' region hashed by arm9loader when generating the console-unique keys for decrypting the keysector, except arm9loader uses the raw encrypted OTP.<br />
<br />
Therefore, with the OTP keydata+IV from Boot9 you can: encrypt the 0x90-bytes from ITCM, then hash the output to get the console-unique keys for the system's keysector. This can even be done for Old3DS which doesn't have the arm9loader keysector officially.<br />
<br />
It's unknown why arm9loader only used the first 0x90-bytes of OTP. Using more data from OTP would've prevented this. Fixing this would require doing exactly that, but that would also mean updating the NAND keysector(which is dangerous).<br />
| See description.<br />
| None<br />
| <br />
| 2015<br />
| January 6, 2017<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| Rearrangable keys in the NAND keystore<br />
| Due to the keystore being encrypted with AES-ECB, one can rearrange blocks and still have the NAND keystore decrypt in a deterministic way. <br />
<br />
Using 10.0 FIRM it is possible to rearrange keys such that ARM9 memory is executed. As such using existing ARM9 execution 10.0 FIRM can be written to NAND and a payload written to memory, with the payload to be executed post-K9L using an MCU reboot.<br />
| arm9loaderhax given existing ARM9 code execution<br />
| None<br />
| [[11.3.0-36|11.3.0-X]]<br />
| Early 2016<br />
| 27 September 2016<br />
| Myria, [[User:Dark samus|dark_samus]]; mathieulh (independently); [[User:Plutooo|plutoo]] (independently) + others<br />
|-<br />
| Uncleared OTP hash keydata in console-unique 0x11 key-generation<br />
| Kernel9Loader does not clear the [[SHA_Registers#SHA_HASH|SHA_HASH register]] after use. As a result, the data stored here as K9L hands over to Kernel9 is the hash of [[OTP_Registers|OTP data]] used to seed the [[FIRM#New_3DS_FIRM|console-unique NAND keystore decryption key]] set on keyslot 0x11.<br />
<br />
Retrieving this keydata and the [[Flash_Filesystem#0x12C00|NAND keystore]] of the same device allows calculating the decrypted New3DS NAND keystore (non-unique, common to all New3DS units), which contains AES normal keys, also set on keyslot 0x11, which are then used to derive all current [[AES_Registers#Keyslots|New3DS-only AES keyXs]] including the newer batch introduced in [[9.6.0-24#arm9loader|9.6.0-X]]. From there, it is trivial to perform the same key derivation in order to initialize those keys on any system version, and even on Old3DS.<br />
<br />
This can be performed by exploiting the "arm9loaderhax" vulnerability to obtain post-K9L code execution after an MCU reboot (the bootrom section-loading fail is not relevant here, this attack was performed without OTP data by brute-forcing keys), and using this to dump the SHA_HASH register. This attack works on any FIRM version shipping a vulnerable version of K9L, whereas OTP dumping required a boot of <[[3.0.0-6|3.0.0-X]].<br />
<br />
This attack results in obtaining the entire (0x200-bytes) NAND keystore - it was confirmed at a later date that this keystore is encrypted with the same key (by comparing the decrypted data from multiple units), and therefore using another key in this store will not remedy the issue as all keys are known (i.e. later, unused keys decrypt to the same 0x200-bytes constant with the same OTP hash). Later keys could have been encrypted differently but this is not the case. As a result of this, it is not possible for Nintendo to use K9L again in its current format for its intended purpose, though this was not news from the moment people dumped a New3DS OTP.<br />
| Derivation of all New3DS keys generated via the NAND keystore (0x1B "Secure4" etc.)<br />
| None<br />
| [[11.3.0-36|11.3.0-X]]<br />
| ~April 2015, implemented in May 2015<br />
| 13 January 2016<br />
| [[User:WulfyStylez|WulfyStylez]], [[User:Dazzozo|Dazzozo]], [[User:Shinyquagsire23|shinyquagsire23]] (complimentary + implemented), [[User:Plutooo|plutoo]], Normmatt (discovered independently)<br />
|-<br />
| enhanced-arm9loaderhax<br />
| See the 32c3 3ds talk.<br />
Since this is a combination of a trick with the arm9-bootrom + arm9loaderhax, and since you have to manually write FIRM to the firm0/firm1 NAND partitions, this can't be completely fixed. Any system with existing ARM9 code execution and an OTP/OTP hash dump can exploit this. Additionally, by using the FIRM partition known-plaintext bug and bruteforcing the second entry in the keystore, this can currently be exploited on all New3DS systems without any other prerequisite hacks.<br />
| arm9loaderhax which automatically occurs at hard-boot.<br />
| See arm9loaderhax / description.<br />
| See arm9loaderhax / description.<br />
| Theorized around mid July, 2015. Later implemented+tested by [[User:Plutooo|plutoo]] and [[User:Derrek|derrek]].<br />
| 32c3 3ds talk (December 27, 2015)<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| arm9loaderhax: Missing verification block for the 9.6 keys<br />
| Starting with [[9.6.0-24|9.6.0-X]] a new set of NAND-based keys were introduced. However, no verification block was added to verify that the new key read from NAND is correct. This was technically an issue from [[9.5.0-22|9.5.0-X]] with the original sector+0 keydata, however the below is only possible with [[9.6.0-24|9.6.0-X]] since keyslots 0x15 and 0x16 are generated from different 0x11 keyXs.<br />
<br />
Writing an incorrect key to NAND will cause arm9loader to decrypt the ARM9 kernel as garbage and then jump to it.<br />
<br />
This allows an hardware-based attack where you can boot into an older exploited firmware, fill all memory with NOP sleds/jump-instructions, and then reboot into executing garbage. By automating this process with various input keydata, eventually you'll find some garbage that jumps to your code.<br />
<br />
This gives very early ARM9 code execution (pre-ARM9 kernel). As such, it is possible to dump RSA keyslots with this and calculate the 6.x [[Savegames#6.0.0-11_Savegame_keyY|save]], and 7.x [[NCCH]] keys. This cannot be used to recover keys initialized by arm9loader itself. This is due to it wiping the area used for its stack during NAND sector decryption and keyslot init. <br />
<br />
Due to FIRMs on both Old and New 3DS using the same RSA data, this can be exploited on Old3DS as well, but only if one already has the actual plaintext normalkey from New3DS NAND sector 0x96 offset-0 and has dumped the OTP area of the Old3DS.<br />
| Recovery of 6.x [[Savegames#6.0.0-11_Savegame_keyY|save key]]/7.x [[NCCH]] key, access to uncleared OTP hash keydata<br />
| None<br />
| [[11.3.0-36|11.3.0-X]]<br />
| March 2015<br />
| <br />
| [[User:Plutooo|plutoo]]<br />
|-<br />
| arm9loader runs on Old3DS<br />
| Despite being written only for New3DS, all of arm9loader runs fine on Old3DS. It's not until booting Kernel9 that a New3DS FIRM partition would crash on an Old3DS. As a result, if a bug exists in arm9loader to get control, it can be exploited on Old3DS by writing New3DS FIRM to the FIRM partitions. Thus, arm9loaderhax works on both Old3DS and New3DS.<br />
| arm9loader bugs also compromise Old3DS<br />
| None<br />
| [[11.3.0-36|11.3.0-X]]<br />
| Sometime in 2015<br />
| <br />
| [[User:Plutooo|plutoo]] presumably<br />
|-<br />
| Uncleared New3DS keyslot 0x11<br />
| Originally the New3DS [[FIRM]] arm9bin loader only cleared keyslot 0x11 when it gets executed at firmlaunch. This was fixed with [[9.5.0-22|9.5.0-X]] by completely clearing keyslot 0x11 immediately after the loader finishes using keyslot 0x11.<br />
This means that any ARM9 code that can execute before the loader clears the keyslot at firmlaunch(including firmlaunch-hax) can get access to the uncleared keyslot 0x11, which then allows one to generate all <=v9.5 New3DS keyXs which are generated by keyslot 0x11.<br />
<br />
Therefore, to completely fix this the loader would have to generate more keys using different keyslot 0x11 keydata. This was done with [[9.6.0-24|9.6.0-X]].<br />
| New3DS keyXs generation<br />
| Mostly fixed with [[9.5.0-22|9.5.0-X]], completely fixed with new keys with [[9.6.0-24|9.6.0-X]].<br />
| <br />
| February 3, 2015 (one day after [[9.5.0-22|9.5.0-X]] release)<br />
| <br />
| [[User:Yellows8|Yellows8]]<br />
|}<br />
<br />
=== Process9 ===<br />
{| class="wikitable" border="1"<br />
|-<br />
! Summary<br />
! Description<br />
! Successful exploitation result<br />
! Fixed in [[FIRM]] system version<br />
! Last [[FIRM]] system version this flaw was checked for<br />
! Timeframe this was discovered<br />
! Public disclosure timeframe<br />
! Discovered by<br />
|-<br />
| Leak of normal-key matching a key-scrambler key<br />
| New 3DS firmware versions [[8.1.0-0 New3DS|8.1.0]] through [[9.2.0-20|9.2.0]] set the encryption key for [[Amiibo]] data using a hardcoded normal-key in Process9. In firmware [[9.3.0-21|9.3.0]], Nintendo "fixed" this by using the key scrambler instead, by calculating the keyY value for keyslot 0x39 that results in the same normal-key, then hardcoding that keyY into Process9.<br />
<br />
Nintendo's fix is actually the problem: Nintendo revealed the normal-key matching an unknown keyX and a known keyY. Combined with the key scrambler using an insecure scrambling algorithm (see "Hardware" above), the key scrambler function could be deduced.<br />
| Deducing the keyX for keyslot 0x39 and the key scrambler algorithm<br />
| New 3DS [[9.3.0-21|9.3.0-X]], sort of<br />
| [[10.0.0-27|10.0.0-X]]<br />
| Sometime in 2015 after the hardware key-generator was broken.<br />
| 32c3 3ds talk (December 27, 2015)<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| Leak of normal-key matching a key-generator key<br />
| During the 3DS' development (June/July 2010) Nintendo added support installing encrypted content ([[CIA]]). Common-key index1 was intended to be a [[AES|hardware generated key]]. However while they added code to generate the key in hardware, they forgot to remove the normal-key for index1 (used elsewhere, likely old debug code). Nintendo later removed the normal key sometime before the first non-prototype firmware release.<br />
<br />
Knowing the keyY and the normal-key for common-key index1, the devkit key-generator algorithm can be deduced (see "Hardware" above). Additionally the remaining devkit common-keys can be generated once the common-key keyX is recovered.<br />
<br />
Note that the devkit key-generator was discovered to be the same as the retail key-generator.<br />
| Deducing the keyX for keyslot 0x3D and hardware key-generator algorithm. Generate remaining devkit common-keys.<br />
| pre-[[1.0.0-0|1.0.0-X]]<br />
| <br />
| Shortly after the key-generator was revealed to be flawed at the 32c3 3ds talk<br />
| January 20, 2016<br />
| [[User:Jakcron|jakcron]]<br />
|-<br />
| Factory firmware is vulnerable to sighax<br />
| During the 3DS's development, presumably boot9 was written (including the sighax vulnerability). This vulnerability is also present in factory firmware (and earlier, including 0.11). This was fixed in version 1.0.0-0.<br />
| Deducing the mechanics of the sighax vulnerability in boot9 without having a dump of protected boot9. ARM9 code execution on factory/earlier firmware.<br />
| [[1.0.0-0|1.0.0-X]]<br />
| [[1.0.0-0|1.0.0-X]]<br />
| May 9, 2017<br />
| May 19, 2017<br />
| [[User:SciresM|SciresM]], [[User:Myria|Myria]]<br />
|-<br />
| twlhax: Corrupted SRL header leads to memory overwrite<br />
| During TWL_FIRM boot, the ARM11 process TwlBg puts launcher.srl, the DSi bootloader, into FCRAM. TWL_FIRM Process9 then parses the [http://dsibrew.org/wiki/NDS_Format SRL header] to place launcher.srl's code where DSi mode can execute it.<br />
<br />
DSi-mode memory is in FCRAM, but interleaved. Each byte of DSi-mode memory also exists at some address in 3DS FCRAM space.<br />
<br />
Process9 does not validate the RSA signature on launcher.srl, unlike SRLs loaded from cartridge or NAND (DSiWare). A compromised ARM11 can, in a manner similar to firmlaunchhax, send a launcher.srl with a modified SRL header. By setting the SRL header's ARM7/ARM9 load addresses and sizes carefully, accounting for the different memory map and for DSi mode's interleaved memory, it is possible to overwrite part of Process9's stack and take control with a ROP chain.<br />
<br />
Fixed in 11.8.0-X by... (fill me in)<br />
| ARM9 code execution (whilst still in 3DS mode)<br />
| [[11.8.0-41|11.8.0-X]]<br />
| [[11.8.0-41|11.8.0-X]]<br />
|<br />
| August 11, 2018<br />
| smea<br />
|-<br />
| safefirmhax<br />
| SAFE_MODE_FIRM is almost never updated(even when NATIVE_FIRM is updated for vuln fixes), this can be noticed by ''just'' checking 3dbrew/ninupdates title-listings.<br />
<br />
The fix for 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 <=> Kernel11 sync, PXI sync and then repeat the original attack on SAFE_FIRM instead.<br />
| ARM9 code execution<br />
| [[11.3.0-36|11.3.0-X]]<br />
| <br />
| 2012-2013?<br />
| Wiki: January 2, 2017<br />
| Everyone<br />
|-<br />
| safefirmhax 1.1<br />
| Nintendo's original safefirmhax fix was flawed -- they added a global boolean that got set to true whenever a non-sysmodule title got launched (except for a hardcoded repair title id), and panic()'d if that boolean was true to prevent launching safefirm after hax was active. However, because the boolean was initially false after firmlaunch -- With ARM11-kernel execution, one could FIRM-launch into NATIVE_FIRM, and then immediately FIRM-launch again into SAFE_FIRM early in NATIVE_FIRM boot before the boolean got set to true to repeat the safehax attack.<br />
<br />
This was fixed by adding additional CFG9_BOOTENV checks to firmlaunch code in 11.4.<br />
| ARM9 code execution<br />
| [[11.4.0-37|11.4.0-X]]<br />
| <br />
| safefirmhax fix<br />
| Wiki: April 10, 2017<br />
| Everyone<br />
|-<br />
| ntrcardhax<br />
| When reading the banner of a NTR title, Process9 relies on a hardware register to know when the banner was fully read.<br />
However that register is shared between the ARM9 and the ARM11.<br />
An attacker with k11 control can so make Process9 believe the banner continues forever and so trigger a buffer overflow.<br />
With a custom banner for a NTR flashcart, this leads to code execution in Process9.<br />
<br />
This was fixed by adding bound checks on the read data.<br />
| ARM9 code execution<br />
| [[10.4.0-29|10.4.0-X]]<br />
| <br />
| March 2015<br />
| 32c3 3ds talk (December 27, 2015)<br />
| [[User:Plutooo|plutoo]]<br />
|-<br />
| Title downgrading via [[Application_Manager_Services|AM]]([[Application_Manager_Services_PXI|PXI]])<br />
| When a title is *already* installed, Process9 will compare the installed title-version with the title-version being installed. When the one being installed is older, Process9 would return an error.<br />
<br />
However, this can be bypassed by just deleting the title first via the service command(s) for that: with the title removed from the [[Title_Database]], Process9 can't compare the input title-version with anything. Hence, titles can be downgraded this way.<br />
<br />
[[11.0.0-33|11.0.0-X]] fixed this for key system titles (MSET, Home Menu, spider, ErrDisp, SKATER, NATIVE_FIRM, and every retail system module), by checking the version of the title to install against a hard-coded list of (titleID, minimumVersionRequired) pairs.<br />
| Bypassing title version check at installation, which then allows downgrading any title.<br />
| [[11.0.0-33|11.0.0-X]], for key system titles.<br />
| NATIVE_FIRM / AM-sysmodule [[11.0.0-33|11.0.0-X]]<br />
| ?<br />
| <br />
| ?<br />
|-<br />
| Anti-downgrade list did not include all system titles initially<br />
| The anti-downgrade list did not include legacy FIRMs until [[11.8.0-41|11.8.0-X]]. Therefore, legacy FIRMs could still be downgraded.<br />
| Downgrading legacy FIRMs; allowing to exploit bugs in older legacy FIRMs (of which at least one exists, see below).<br />
| [[11.8.0-33|11.8.0]]<br />
| [[11.8.0-33|11.8.0]]<br />
| ?<br />
| Wiki: August 5, 2018<br />
| Everyone<br />
|-<br />
| TWL_FIRM cmd-9 unchecked offset<br />
| In [[1.0.0-0|1.0.0-X]]'s TWL_FIRM, cmds 8 and 9 were not stubbed (whereas in the corresponding NATIVE_FIRM, they were).<br />
Command 8 does the Process9 initialisation for NTR carts if an NTR cart is inserted (NTR, not TWL, judged by chipid).<br />
<br />
Command 9 takes (u32 offset_read, u32 offset_write, u32 offset_read_end), and basically just copies (offset_read_end - offset_read) bytes starting at (offset_read) of [NTR cart header in arm9mem, NTR secure area in fcram, TWL secure area in fcram], to 0x18001000 + offset_write + offset_read.<br />
<br />
offset_write is not checked at all, thus this leads to ARM9 code execution as long as any NTR cart, including flashcarts that would normally be blocked by TWL_FIRM, is inserted.<br />
<br />
In [[2.0.0-2|2.0.0-X]] TWL_FIRM, those commands were stubbed out.<br />
| ARM9 code execution<br />
| [[2.0.0-2|2.0.0-X]]<br />
| [[2.0.0-2|2.0.0-X]]<br />
| January 2018<br />
| Wiki: August 5, 2018<br />
| [[User:Riley|Riley]]<br />
|-<br />
| FIRM launch doesn't check target FIRM version<br />
| When executing a FIRM launch, Process9 doesn't validate that the target FIRM isn't an old version. This allows booting an exploitable FIRM from a newer FIRM, if you can get the exploitable FIRM installed. ([[11.0.0-33|11.0.0-X]] now prevents installing old versions of system titles, but this doesn't affect titles already installed.)<br />
<br />
This had a use after [[9.6.0-24|9.6.0-X]]: on a compromised 3DS running 9.2.0, you could install the 9.6.0 NATIVE_FIRM to FIRM0/FIRM1, but avoid putting it into the NATIVE_FIRM title. This would boot the 9.2.0 system software but with the 9.6.0 Process9 and Kernel11. With a user-mode exploit in a sufficiently-privileged application (e.g. mset), you could trigger a FIRM launch back to NATIVE_FIRM, which would load the 9.2.0 Process9 and Kernel11.<br />
<br />
9.6.0's keyslots 0x15 and 0x16 are unknown to 9.2.0, so 9.2.0 would not clear them. You then could do firmlaunchhax against 9.2.0 to get ARM9 access with keyslots 0x15 and 0x16 set to their proper 9.6.0 values, allowing decrypting 9.6.0's encrypted titles. Once the New3DS keystore was dumped, this became moot.<br />
| Decrypting 9.6.0 NCCH files without dumping New3DS keystore<br />
| None (but now moot)<br />
| [[9.6.0-24|9.6.0-X]]<br />
| March 2015<br />
| August 12, 2018<br />
| [[User:Yellows8|Yellows8]], [[User:Myria|Myria]]<br />
|-<br />
| FAT FS code null-deref<br />
| When FSFile:Read is used with a file which is corrupted on a FAT filesystem(in particular SD), Process9 can crash. This particular crash is caused by a function returning NULL instead of an actual ptr due to an error. The caller of that function doesn't check for NULL which then triggers a read based at NULL.<br />
<br />
Sample "fsck.vfat -n -v -V <fat image backup>" output for the above crash:<br />
<br />
<pre>...<br />
Starting check/repair pass.<br />
<FilePath0> and<br />
<FilePath1><br />
share clusters.<br />
Truncating second to 3375104 bytes.<br />
<FilePath1><br />
File size is 2787392 bytes, cluster chain length is 16384 bytes.<br />
Truncating file to 16384 bytes.<br />
Checking for unused clusters.<br />
Reclaimed 1 unused cluster (16384 bytes).<br />
Checking free cluster summary.<br />
Free cluster summary wrong (1404490 vs. really 1404491)<br />
Auto-correcting.<br />
Starting verification pass.<br />
Checking for unused clusters.<br />
Leaving filesystem unchanged.</pre><br />
| Useless null-based-read<br />
| None<br />
| [[9.6.0-24|9.6.0-X]]<br />
| July 8-9, 2015<br />
| <br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| RSA signature padding checks<br />
| The TWL_FIRM RSA sig padding check code used for all TWL RSA sig-checks has issues, see [[FIRM|here]].<br />
The main 3DS RSA padding check code(non-certificate, including NATIVE_FIRM) uses the function used with the above to extract more padding + the actual hash from the additional padding. This isn't really a problem here because there's proper padding check code which is executed prior to this.<br />
| <br />
| None<br />
| [[9.5.0-22|9.5.0-X]]<br />
| March 2015<br />
| <br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[AMPXI:ValidateDSiWareSectionMAC]] [[AES_Registers|AES]] keyslot reuse<br />
| When the input DSiWare section index is higher than <max number of DSiWare sections supported by this FIRM>, Process9 uses keyid 0x40 for calculating the AESMAC, which translates to keyslot 0x40. The result is that the keyslot is left at whatever was already selected before, since the AES selectkeyslot code will immediately return when keyslot is >=0x40. However, actually exploiting this is difficult: the calculated AESMAC is never returned, this command just compares the calculated AESMAC with the input AESMAC(result-code depends on whether the AESMACs match). It's unknown whether a timing attack would work with this.<br />
This is basically a different form of the pxips9 keyslot vuln, except with AESMAC etc.<br />
| See description.<br />
| None<br />
| [[11.3.0-36|11.3.0-X]]<br />
| March 15, 2015<br />
| December 29, 2015<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| pxips9 [[AES_Registers|AES]] keyslot reuse<br />
| This requires access to the [[Process_Services|ps:ps]]/pxi:ps9 services. One way to get access to this would be snshax on system-version <=10.1.0-X(see 32c3 3ds talk).<br />
When an invalid key-type value is passed to any of the PS commands, Process9 will try to select keyslot 0x40. That aesengine_setkeyslot() code will then immediately return due to the invalid keyslot value. Since that function doesn't return any errors, Process9 will just continue to do crypto with whatever AES keyslot was selected before the PS command was sent.<br />
| Reusing the previously used keyslot, for crypto with PS.<br />
| None<br />
| [[11.3.0-36|11.3.0-X]]<br />
| Roughly the same time(same day?) as firmlaunch-hax.<br />
| December 29, 2015<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| firmlaunch-hax: FIRM header ToCToU<br />
| This can't be exploited from ARM11 userland.<br />
During [[FIRM]] launch, the only FIRM header the ARM9 uses at all is stored in FCRAM, this is 0x200-bytes(the actual used FIRM RSA signature is read to the Process9 stack however). The ARM9 doesn't expect "anything" besides the ARM9 to access this data.<br />
With [[9.5.0-22]] the address of this FIRM header was changed from a FCRAM address, to ARM9-only address 0x01fffc00.<br />
| ARM9 code execution<br />
| [[9.5.0-22]]<br />
| <br />
| 2012, 3 days after [[User:Yellows8|Yellows8]] started Process9 code RE.<br />
| <br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| Uninitialized data output for (PXI) command replies<br />
| PXI commands for various services(including some [[Filesystem_services_PXI|here]] and many others) can write uninitialized data (like from ARM registers) to the command reply. This happens with stubbed commands, but this can also occur with certain commands when returning an error.<br />
Certain ARM11 service commands have this same issue as well.<br />
| <br />
| None<br />
| [[9.3.0-21|9.3.0-X]]<br />
| ?<br />
| <br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[Filesystem_services_PXI|FSPXI]] OpenArchive SD permissions<br />
| Process9 does not use the exheader ARM9 access-mount permission flag for SD at all.<br />
This would mean ARM11-kernelmode code / fs-module itself could directly use FSPXI to access SD card without ARM9 checking for SD access, but this is rather useless since a process is usually running with SD access(Home Menu for example) anyway.<br />
| <br />
| None<br />
| [[9.3.0-21|9.3.0-X]]<br />
| 2012<br />
| <br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[AMPXI:ExportDSiWare]] export path<br />
| Process9 allocates memory on Process9 heap for the export path then verifies that the actual allocated size matches the input size. Then Process9 copies the input path from FCRAM to this buffer, and uses it with the Process9 FS openfile code, which use paths in the form of "<mountpoint>:/<path>".<br />
Process9 does not check the contents of this path at all before passing it to the FS code, besides writing a NUL-terminator to the end of the buffer.<br />
| Exporting of DSiWare to arbitrary Process9 file-paths, such as "nand:/<path>" etc. This isn't really useful since the data which gets written can't be controlled.<br />
| None<br />
| [[9.5.0-22]]<br />
| April 2013<br />
| <br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[DSiWare_Exports]] [[CTCert]] verification<br />
| Just like DSi originally did, 3DS verifies the APCert for DSiWare on SD with the CTCert also in the DSiWare .bin. On DSi this was fixed with with system-version 1.4.2 by verifying with the actual console-unique cert instead(stored in NAND), while on 3DS it's still not(?) fixed.<br />
On 3DS however this is useless, unless one can obtain the console-unique movable.sed keyY which encrypts the entire DSiWare .bin.<br />
| When the movable.sed keyY for the target 3DS is known and the target 3DS CTCert private-key is unknown, importing of modified DSiWare SD .bin files.<br />
| None.<br />
| 11.6.0-X<br />
| April 2013<br />
| <br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| seedminer: movable.sed keyY vulnerable to brute-force<br />
| Half of the movable.sed keyY's 128 bits are leaked through the [[Nandrw/sys/LocalFriendCodeSeed_B|LFCS]], which is available in userland and below. The LFCS itself also leaks almost half of the remaining bits by following the ratio: u32 keyY[3]=1/5(LFCS). The remaining keyY[3] uncertainty of about ±2000 can be greatly reduced by plotting expected error margins with several keyYs. This results in a final uncertainty of about 2^40, easily within practical brute force range of an average modern PC.<br />
| Knowing the keyY of a given 3ds allows for modification of DSiWare export contents, and chained with several other public vulns, ultimately arm9 execution.<br />
| None.<br />
| 11.6.0-X<br />
| December 2017<br />
| January 2018<br />
| zoogie<br />
|-<br />
| Improper validation of DSiWare title SRLs<br />
| The 3DS does not verify if the actual SRL embedded in the title's directory matches the titleID in the TMD before launching it or importing it from an sd DSiWare export. <br />
| This allows embedding older, exploitable DSiWare titles in completely different, unexploitable DSiWare titles. Since DSiWare has raw NAND RW, this can result in arm9 control through FIRM known-plaintext and sighax attacks.<br />
| None.<br />
| 11.6.0-X<br />
| 2015?<br />
| December 2016<br />
| Everyone<br />
|-<br />
| [[Gamecard_Services_PXI]] unchecked REG_CTRCARDCNT transfer-size<br />
| The u8 REG_CTRCARDCNT transfer-size parameter for the [[Gamecard_Services_PXI]] read/write CTRCARD commands is used as an index for an array of u16 values. Before [[5.0.0-11|5.0.0-X]] this u8 value wasn't checked, thus out-of-bounds reads could be triggered(which is rather useless in this case).<br />
| Out-of-bounds read for a value which gets written to a register.<br />
| [[5.0.0-11|5.0.0-X]]<br />
| <br />
| 2013?<br />
| <br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[PXI_Registers|PXI]] cmdbuf buffer overrun<br />
| The Process9 code responsible [[PXI_Registers|PXI]] communications didn't verify the size of the incoming command before writing it to a C++ member variable. <br />
| Probably ARM9 code execution<br />
| [[5.0.0-11|5.0.0-11]]<br />
| <br />
| March 2015, original timeframe if any unknown<br />
| <br />
| [[User:Plutooo|plutoo]]/[[User:Yellows8|Yellows8]]/maybe others(?)<br />
|-<br />
| [[Application_Manager_Services_PXI|PXIAM]] command 0x003D0108(See also [[Application_Manager_Services|this]])<br />
| When handling this command, Process9 allocates a 0x2800-byte heap buffer, then copies the 4 FCRAM input buffers to this heap buffer without checking the sizes at all(only the buffers with non-zero sizes are copied). Starting with [[5.0.0-11|5.0.0-X]], the total combined size of the input data must be <=0x2800.<br />
| ARM9 code execution<br />
| [[5.0.0-11|5.0.0-X]]<br />
| <br />
| May 2013<br />
| <br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[Process_Services_PXI|PS RSA]] commands buffer overflows<br />
| pxips9 cmd1(not accessible via ps:ps) and VerifyRsaSha256: unchecked copy to a buffer in Process9's .bss, from the input FCRAM buffer. The buffer is located before the pxi cmdhandler threads' stacks. SignRsaSha256 also has a buf overflow, but this isn't exploitable.<br />
The buffer for this is the buffer for the signature data. With v5.0, the signature buffer was moved to stack, with a check for the signature data size. When the signature data size is too large, Process9 uses [[SVC|svcBreak]].<br />
| ARM9 code execution<br />
| [[5.0.0-11|5.0.0-X]]<br />
| <br />
| 2012<br />
| <br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[PXI_Registers|PXI]] pxi_id bad check<br />
| The Process9 code responsible for [[PXI_Registers|PXI]] communications read pxi_id as a signed char. There were two flaws:<br />
* They used it as index to a lookup-table without checking the value at all.<br />
* Another function verified that pxi_id < 7, allowing negative values to pass the check. This would also cause an out-of-range table-lookup.<br />
| Maybe ARM9 code execution<br />
| [[3.0.0-5|3.0.0-5]]<br />
|<br />
| March 2015, originally 2012 for the first issue at least<br />
| <br />
| [[User:Plutooo|plutoo]], [[User:Yellows8|Yellows8]], maybe others(?)<br />
|}<br />
<br />
=== Kernel9 ===<br />
{| class="wikitable" border="1"<br />
|-<br />
! Summary<br />
! Description<br />
! Successful exploitation result<br />
! Fixed in [[FIRM]] system version<br />
! Last [[FIRM]] system version this flaw was checked for<br />
! Timeframe this was discovered<br />
! Discovered by<br />
|-<br />
| [[CONFIG Registers#CFG_SYSPROT9|CFG_SYSPROT9]] bit1 not set by Kernel9<br />
| Old versions of Kernel9 never set bit1 of [[CONFIG Registers#CFG_SYSPROT9|CFG_SYSPROT9]]. This leaves the [[OTP Registers|0x10012000]]-region unprotected (this region should be locked early during boot!). Since it's never locked, you can dump it once you get ARM9 code execution.<br />
<br />
From [[3.0.0-5|3.0.0-X]] this was fixed by setting the bit in Kernel9 after poking some registers in that region. On New3DS arm9loader sets this bit instead of Kernel9, which is exploitable through a hardware + software vulnerability (see arm9loaderhax / description).<br />
<br />
This flaw resurged when it gained a new practical use: retrieving the OTP data for a New3DS console in order to decrypt the key data used in arm9loader (see enhanced-arm9loaderhax / description). This was performed by downgrading to a vulnerable system version. By accounting for differences in CTR-NAND crypto (0x05 -> 0x04, see partition encryption types [[Flash_Filesystem#NAND_structure|here]]) and using an Old3DS [[NCSD#NCSD_header|NCSD Header]], it is possible to boot a New3DS using Old3DS firmware 1.0-2.x to retrieve the required OTP data using this flaw.<br />
| Dumping the [[OTP Registers|OTP]] area.<br />
Decrypting New3DS sector 0x96 keyblock.<br />
| [[3.0.0-5|3.0.0-X]]<br />
|<br />
| February 2015<br />
| [[User:Plutooo|plutoo]], Normmatt independently<br />
|}<br />
<br />
== ARM11 software ==<br />
=== Kernel11 ===<br />
{| class="wikitable" border="1"<br />
|-<br />
! Summary<br />
! Description<br />
! Successful exploitation result<br />
! Fixed in [[FIRM]] system version<br />
! Last [[FIRM]] system version this flaw was checked for<br />
! Timeframe this was discovered<br />
! Discovered by<br />
|-<br />
| [[SVC|svcSetProcessIdealProcessor]] reference count overflow and therefore use-after-free.<br />
| The SVC receive two arguments: handle and idealprocessor. The handle is used to get the KProcess object and the KProcess->refCnt gets incremented,later the function check if the KProcess->mem_type != BASE and if yes, it checks for idealprocessor == 2 or idealprocessor != 3. The problem here is that if you pass the idealprocessor = 3 it won't meet any condition and return the error 0xD9001BEA without decrement the reference count. <br />
It can be abused to overflow the KProcess reference count that will lead to an Use-after-free. <br />
| Before [[11.2.0-35|11.2.0-X]]: reference count overflow and therefore use-after-free.<br />
| <br />
| [[11.6.0-39|11.6.0-X]]<br />
| November 2, 2017<br />
| [[User:st4rk|st4rk]]<br />
|-<br />
| [[SVC|svcGetThreadList]] process reference leak<br />
| When given a valid process handle (including <code>0xFFFF8001</code>), svcGetThreadList forgets to decrement the reference count of the underlying [[KProcess]] instance, after having finished using it.<br />
| Before [[11.2.0-35|11.2.0-X]]: reference count overflow and therefore use-after-free, but this UAF was most likely not exploitable<br />
| <br />
| [[11.3.0-36|11.3.0-X]]<br />
| April 3, 2017<br />
| [[User:TuxSH|TuxSH]]<br />
|-<br />
| kernelhax via gspwn<br />
| Originally the kernel didn't initialize [[CONFIG11_Registers#CFG11_GPUPROT|CFG11_GPUPROT]]. Since it's 0 at hard-boot, this allowed the GPU to access the entire FCRAM + AXIWRAM.<br />
| Entire FCRAM+AXIWRAM R/W.<br />
| [[3.0.0-5|3.0.0-X]]<br />
| <br />
| February 7, 2017<br />
| [[User:Plutooo|plutoo]], [[User:Yellows8|Yellows8]] partly<br />
|-<br />
| fasthax<br />
| When a KTimer is created in pulse mode, the kernel calls a virtual function to reset the timer each time it pulses. The scheduler is locked for that core to avoid race conditions, but another core can call CloseHandle on the timer and free it, leading to a UAF vtable call.<br />
| See description.<br />
| [[11.3.0-36|11.3.0-X]]<br />
| [[11.3.0-36|11.3.0-X]]<br />
| May 2016<br />
| nedwill<br />
|-<br />
| ipctakeover<br />
| When sending cmdreplies, it does not validate that the src_addr and src_size match the equivalent dst_addr and dst_size. With a modified addr/size specified in a cmdreply for an output buffer, the data-copy for the first/last pages could be used to overwrite data outside of the buffer specified by the original process.<br />
<br />
Used by ctr-httpwn as of v1.2, for "ipctakeover/bosshaxx".<br />
<br />
This can be used to takeover processes where the process is using your service session. Like HTTPC -> BOSS, for bosshaxx above. NIM takeover can be done too(actual stack buffer overflow can trigger), etc.<br />
| See description.<br />
| None<br />
| [[11.3.0-36|11.3.0-X]]<br />
| November 26, 2016<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| Using IPC input buffers as output buffers<br />
| When sending cmdreplies, it does not validate that the cmdreply descriptor type matches the equivalent cmdreq descriptor type. This could be used by an exploited sysmodule to use what was intended as an input-buffer as an output-buffer, and also combine other IPC vuln(s) with this.<br />
<br />
Used by ctr-httpwn as of v1.2, for "ipctakeover/bosshaxx".<br />
| See description.<br />
| None<br />
| [[11.3.0-36|11.3.0-X]]<br />
| November 2016<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[SVC]] table too small<br />
| The table of function pointers for SVC's only contains entries up to 0x7D, but the biggest allowed SVC for the table is 0x7F. Thus, executing SVC7E or SVC7F would make the SVC-handler read after the buffer, and interpret some ARM instructions as function pointers.<br />
<br />
However, this would require patching the kernel .text or modifying SVC-access-control. Even if you could get these to execute, they would still jump to memory that isn't mapped as executable.<br />
| <br />
| None<br />
| [[11.3.0-36|11.3.0-X]]<br />
| 2012<br />
| Everyone<br />
|-<br />
| [[SVC|svcBackdoor (0x7B)]]<br />
| This backdoor allows executing SVC-mode code at the user-specified code-address. This is used by Process9, using this on the ARM11 (with NATIVE_FIRM) required patching the kernel .text or modifying SVC-access-control.<br />
| See description<br />
| [[11.0.0-33|11.0.0-X]] (deleted)<br />
| <br />
|<br />
| Everyone<br />
|-<br />
| veryslowpidhax<br />
| '''This is completely different from the kernelmode-code-execution vuln described in the below separate entry.'''<br />
<br />
When updating the kernel global PID counter under [[SVC|svcCreateProcess]] the kernel does not check for wraparound to 0x0(the PID for the very first process). This only matters because [[Services|SM-module]] allows processes with PID value less than <total ARM11 FIRM modules> to access ''all'' services, without checking exheader service-access-control; and because Kernel11 checks for the PID to be 1 (loader) to use the input mem-region value on ControlMemory. This alone does not affect access the [[SVC|SVCs]] access table at all.<br />
<br />
Inlined ldrex+strex code is used for updating the above counter. [[11.2.0-35|11.2.0-X]] had changes for similar code, but it was only for dedicated ldrex+strex functions(mainly for kernel objects) and hence this PID code was not affected.<br />
<br />
With launching+terminating a sysmodule repeatedly with this via ns:s, it would take weeks to finish(if not at least about a month?).<br />
| Access to all [[Services_API|services]], ControlMemory on any given mem-region.<br />
| None<br />
| [[11.3.0-36|11.3.0-X]]<br />
| 2012 maybe?<br />
| <br />
|-<br />
| slowhax/waithax<br />
| svcWaitSynchronizationN does not decrement the references to valid handles in an array before returning an error when it encounters an invalid handle. This allows one to (slowly) overflow the reference count for a handle object to zero.<br />
| ARM11 kernel-mode code execution<br />
| [[11.2.0-35|11.2.0-X]]<br />
| [[11.2.0-35|11.2.0-X]]<br />
| 2016<br />
| nedwill, [[User:Derrek|derrek]]<br />
|-<br />
| [[Memory_layout#ARM11_Detailed_virtual_memory_map|0xEFF00000]] / 0xDFF00000 ARM11 kernel virtual-memory<br />
| The ARM11 kernel-mode 0xEFF00000/0xDFF00000 virtual-memory(size 0x100000) is mapped to phys-mem 0x1FF00000(entire DSP-mem + entire AXIWRAM), with permissions RW-. This is used during ARM11 kernel startup for loading the FIRM-modules from the FIRM section located in DSP-mem, this never seems to be used after that, however. This is never unmapped either.<br />
| <br />
| None<br />
| [[11.3.0-36|11.3.0-X]]<br />
| <br />
| <br />
|-<br />
| memchunkhax2.1<br />
| Nintendo's fix for memchunkhax2 in [[10.4.0-29|10.4.0-X]] did not fix the GPU case: one may cause the requisite ToCToU race using gspwn, bypassing the new validation.<br />
derrek's original 32c3 presentation for memchunkhax2 commented that a GPU-based attack was possible, but would be difficult. However, memchunkhax2.1 showed that it was possible to do fairly reliably.<br />
| ARM11 kernel code execution<br />
| [[11.0.0-33|11.0.0-X]], via the new [[Memory_Management#MemoryBlockHeader|memchunkhdr]] MAC which prevents modifying memchunkhdr data with DMA.<br />
| [[11.0.0-33|11.0.0-X]]<br />
|<br />
| [[User:Derrek|derrek]], aliaspider<br />
|-<br />
| memchunkhax2<br />
| When allocating a block of memory, the "next" pointer of the [[Memory_Management#MemoryBlockHeader|memchunkhdr]] is accessed without being checked after being mapped to userland.<br />
This allows a race condition, where the process can change the next pointer just before it's accessed. By pointing the next pointer to a crafted memchunckhdr in the kernel SlabHeap, some of the SlabHeap is allocated to the calling process, allowing to change vtables of kernel objects. <br />
| ARM11 kernel code execution<br />
| [[10.4.0-29|10.4.0-X]] (partially, see memchunkhax2.1)<br />
| [[10.4.0-29|10.4.0-X]]<br />
|<br />
| [[User:Derrek|derrek]]<br />
|-<br />
| heaphax<br />
| Can change the size of free memchunk structures stored in FCRAM using DMA, which leads to the ability to allocate memory chunks over already-allocated memory. This can be used in the SYSTEM region to allocate RW memory over any part of the NS system module, which is enough to take it over.<br />
| Code execution with access to all of NS's privileges. (including downgrading) Code execution within any applet.<br />
| [[11.0.0-33|11.0.0-X]], via the new [[Memory_Management#MemoryBlockHeader|memchunkhdr]] MAC which prevents modifying memchunkhdr data with DMA.<br />
| [[11.0.0-33|11.0.0-X]]<br />
| April 2015 ?<br />
| smea<br />
|-<br />
| snshax<br />
| Can force creation of Safe NS process into gspwn-able memory, allowing for takeover.<br />
| Code execution with access to all of NS's privileges. (including downgrading)<br />
| [[10.1.0-27|10.1.0-X]]<br />
| [[10.1.0-27|10.1.0-X]]<br />
| April 2015 ?<br />
| smea<br />
|-<br />
| AffinityMask/processorid validation<br />
| With [[10.0.0-27|10.0.0-X]] the following functions were updated: svcGetThreadAffinityMask, svcGetProcessAffinityMask, svcSetProcessAffinityMask, and svcCreateThread. The code changes for all but svcCreateThread are identical.<br />
The original code with the first 3 did the following: <br />
* if(u32_processorcount > ~0x80000001)return 0xe0e01bfd;<br />
* if(s32_processorcount > <total_cores>)return 0xd8e007fd;<br />
The following code replaced the above:<br />
* if(u32_processorcount >= <total_cores+1>)return 0xd8e007fd;<br />
In theory the latter should catch everything that the former did, so it's unknown if this was really a security issue.<br />
<br />
The svcCreateThread changes with [[10.0.0-27|10.0.0-X]] definitely did fix a security issue.<br />
* Original code: "if(s32_processorid > <total_cores>)return 0xd8e007fd;"<br />
* New code: "if(s32_processorid >= <total_cores> || s32_processorid <= -4)return 0xd8e007fd;"<br />
This fixed an off-by-one issue: if one would use processorid=total_cores, which isn't actually a valid value, svcCreateThread would accept that value on <[[10.0.0-27|10.0.0-X]]. This results in data being written out-of-bounds(baseaddr = arrayaddr + entrysize*processorid), which has the following result:<br />
* Old3DS: Useless kernel-mode crash due to accessing unmapped memory.<br />
* New3DS: uncontrolled data write into a kernel-mode L1 MMU-table. This isn't really useful: the data can't be controlled, and the data which gets overwritten is all-zero anyway(this isn't anywhere near MMU L1 entries for actually mapped memory).<br />
The previous version also allowed large negative s32_processorid values(negative processorid values are special values not actual procids), but it appears using values like that won't actually do anything(meaning no crash) besides the thread not running / thread not running for a while(besides triggering a kernelpanic with certain s32_processorid value(s)).<br />
| Nothing useful<br />
| [[10.0.0-27|10.0.0-X]]<br />
| [[10.0.0-27|10.0.0-X]]<br />
| svcCreateThread issue: May 31, 2015. The rest: September 8, 2015, via v9.6->v10.0 ARM11-kernel code-diff.<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| memchunkhax<br />
| The kernel originally did not validate the data stored in the FCRAM kernel heap [[Memchunkhdr|memchunk-headers]] for free-memory at all. Exploiting this requires raw R/W access to these memchunk-headers, like physical-memory access with gspwn.<br />
<br />
There are ''multiple'' ways to exploit this, but the end-result for most of these is the same: overwrite code in AXIWRAM via the 0xEFF00000/0xDFF00000 kernel virtual-memory mapping.<br />
<br />
This was fixed in [[9.3.0-21|9.3.0-X]] by checking that the memchunk(including size, next, and prev ptrs) is located within the currently used heap memory. The kernel may also check that the next/prev ptrs are valid compared to other memchunk-headers basically. When any of these checks fail, kernelpanic() is called.<br />
| When combined with other flaws: ARM11-kernelmode code execution<br />
| [[9.3.0-21|9.3.0-21]]<br />
| <br />
| February 2014<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| Multiple [[KLinkedListNode|KLinkedListNode]] SlabHeap use after free bugs<br />
| The ARM11-kernel did access the 'key' field of [[KLinkedListNode|KLinkedListNode]] objects, which are located on the SlabHeap, after freeing them. Thus, triggering an allocation of a new [[KLinkedListNode|KLinkedListNode]] object at the right time could result in a type-confusion. Pseudo-code:<br />
SlabHeap_free(KLinkedListNode);<br />
KObject *obj = KLinkedListNode->key; // the object there might have changed!<br />
This bug appeared all over the place.<br />
| ARM11-kernelmode code exec maybe<br />
| [[8.0.0-18|8.0.0-18]]<br />
| <br />
| April 2015<br />
| [[User:Derrek|derrek]]<br />
|-<br />
| PXI [[RPC_Command_Structure|Command]] input/output buffer permissions<br />
| Originally the ARM11-kernel didn't check permissions for PXI input/output buffers for commands. Starting with [[6.0.0-11|6.0.0]] PXI input/output buffers must have RW permissions, otherwise kernelpanic is triggered.<br />
| <br />
| [[6.0.0-11|6.0.0-11]]<br />
| <br />
| 2012<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[SVC|svcStartInterProcessDma]]<br />
| For svcStartInterProcessDma, the kernel code had the following flaws:<br />
<br />
* Originally the ARM11-kernel read the input DmaConfig structure directly in kernel-mode(ldr(b/h) instructions), without checking whether the DmaConfig address is readable under userland. This was fixed by copying that structure to the SVC-mode stack, using the ldrbt instruction.<br />
<br />
* Integer overflows for srcaddr+size and dstaddr+size are now checked(with [[6.0.0-11]]), which were not checked before.<br />
<br />
* The kernel now also checks whether the srcaddr/dstaddr (+size) is within userland memory (0x20000000), the kernel now (with [[6.0.0-11]]) returns an error when the address is beyond userland memory. Using an address >=0x20000000 would result in the kernel reading from the process L1 MMU table, beyond the memory allocated for that MMU table(for vaddr->physaddr conversion). <br />
| <br />
| [[6.0.0-11]]<br />
| <br />
| DmaConfig issue: unknown. The rest: 2014<br />
| [[User:Plutooo|plutoo]], [[User:Yellows8|Yellows8]] independently<br />
|-<br />
| [[SVC|svcControlMemory]] Parameter checks<br />
| For svcControlMemory the parameter check had these two flaws:<br />
<br />
* The allowed range for addr0, addr1, size parameters depends on which MemoryOperation is being specified. The limitation for GSP heap was only checked if op=(u32)0x10003. By setting a random bit in op that has no meaning (like bit17?), op would instead be (u32)0x30003, and the range-check would be less strict and not accurate. However, the kernel doesn't actually use the input address for LINEAR memory-mapping at all besides the range-checks, so this isn't actually useful. This was fixed in the kernel by just checking for the LINEAR bit, instead of comparing the entire MemoryOperation value with 0x10003.<br />
<br />
* Integer overflows on (addr0+size) are now checked that previously weren't (this also applies to most other address checks elsewhere in the kernel).<br />
<br />
| <br />
| [[5.0.0-11]]<br />
| <br />
|<br />
| [[User:Plutooo|plutoo]]<br />
|-<br />
| [[RPC_Command_Structure|Command]] request/response buffer overflow<br />
| Originally the kernel did not check the word-values from the command-header. Starting with [[5.0.0-11]], the kernel will trigger a kernelpanic() when the total word-size of the entire command(including the cmd-header) is larger than 0x40-words (0x100-bytes). This allows overwriting threadlocalstorage+0x180 in the destination thread. However, since the data written there would be translate parameters (such as header-words + buffer addresses), exploiting this would likely be very difficult, if possible at all.<br />
<br />
If the two words at threadlocalstorage+0x180 could be overwritten with controlled data this way, one could then use a command with a buffer-header of <nowiki>((size<<14) | 2)</nowiki> to write arbitrary memory to any RW userland memory in the destination process.<br />
| <br />
| [[5.0.0-11]]<br />
| <br />
| v4.1 FIRM -> v5.0 code diff<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[SVC|SVC stack allocation overflows]]<br />
| <br />
* Syscalls that allocate a variable-length array on stack, only checked bit31 before multiplying by 4/16 (when calculating how much memory to allocate). If a large integer was passed as input to one of these syscalls, an integer overflow would occur, and too little memory would have been allocated on stack resulting in a buffer overrun. <br />
* The alignment (size+7)&~7 calculation before allocation was not checked for integer overflow.<br />
<br />
This might allow for ARM11 kernel code-execution.<br />
<br />
(Applies to svcSetResourceLimitValues, svcGetThreadList, svcGetProcessList, svcReplyAndReceive, svcWaitSynchronizationN.)<br />
| <br />
| [[5.0.0-11]]<br />
| <br />
| v4.1 FIRM -> v5.0 code diff<br />
| [[User:Plutooo|plutoo]], [[User:Yellows8|Yellows8]] complementary<br />
|-<br />
| [[SVC|svcControlMemory]] MemoryOperation MAP memory-permissions<br />
| svcControlMemory with MemoryOperation=MAP allows mapping the already-mapped process virtual-mem at addr1, to addr0. The lowest address permitted for addr1 is 0x00100000. Originally the ARM11 kernel didn't check memory permissions for addr1. Therefore .text as addr1 could be mapped elsewhere as RW- memory, which allowed ARM11 userland code-execution.<br />
| <br />
| [[4.1.0-8]]<br />
| <br />
| 2012<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[RPC_Command_Structure|Command]] input/output buffer permissions<br />
| Originally the ARM11 kernel didn't check memory permissions for the input/output buffers for commands. Starting with [[4.0.0-7]] the ARM11 kernel will trigger a kernelpanic() if the input/output buffers don't have the required memory permissions. For example, this allowed a FSUSER file-read to .text, which therefore allowed ARM11-userland code execution.<br />
| <br />
| [[4.0.0-7]]<br />
| <br />
| 2012<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[SVC|svcReadProcessMemory/svcWriteProcessMemory memory]] permissions<br />
| Originally the kernel only checked the first page(0x1000-bytes) of the src/dst buffers, for svcReadProcessMemory and svcWriteProcessMemory. There is no known retail processes which have access to these SVCs.<br />
| <br />
| [[4.0.0-7]]<br />
| <br />
| 2012?<br />
| [[User:Yellows8|Yellows8]]<br />
|}<br />
<br />
=== [[FIRM]] Sysmodules ===<br />
{| class="wikitable" border="1"<br />
|-<br />
! Summary<br />
! Description<br />
! Successful exploitation result<br />
! Fixed in [[FIRM]] system version<br />
! Last [[FIRM]] system version this flaw was checked for<br />
! Timeframe this was discovered<br />
! Discovered by<br />
|-<br />
| [[Services|"srv:pm"]] process registration<br />
| Originally any process had access to the port "srv:pm". The PID's used for the (un)registration commands are not checked either. This allowed any process to re-register itself with "srv:pm", and therefore allowed the process to give itself access to any service, bypassing the exheader service-access-control list.<br />
<br />
This was fixed in [[7.0.0-13]]: starting with [[7.0.0-13]] "srv:pm" is now a service instead of a globally accessible port. Only processes with PID's less than 6 (in other words: fs, ldr, sm, pm, pxi modules) have access to it. With [[7.0.0-13]] there can only be one session for "srv:pm" open at a time(this is used by pm module), svcBreak will be executed if more sessions are opened by the processes which can access this.<br />
<br />
This flaw was needed for exploiting the <=v4.x Process9 PXI vulnerabilities from ARM11 userland ROP, since most applications don't have access to those service(s).<br />
| Access to arbitrary services<br />
| [[7.0.0-13]]<br />
| <br />
| 2012<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| FSDIR null-deref<br />
| [[Filesystem_services|FS]]-module may crash in some cases when handling directory reading. The trigger seems to be due to using [[FSDir:Close]] without closing the dir-handle afterwards?(Perhaps this is caused by out-of-memory?) This seems to be useless since it's just a null-deref.<br />
| <br />
| None<br />
| [[9.6.0-24|9.6.0-X]]<br />
| May 19(?)-20, 2015<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[SM]] out-of-bounds BSS write (table 1 entry too small)<br />
| After accepting a new session, [[SM]] writes a (handler ID (0 for srv: sessions (max. 64), 1 for the srv:pm one), pointer to session context structure in BSS) pair in a global array. However that array is only 64-entry-big instead of 65 (as it ought to be), and no bound check is done in that regard.<br />
<br />
Unfortunately, as of [[11.4.0-37]], the overwritten fields are totally unused after their initialization by <code>__libc_init_array</code>.<br />
| Not currently exploitable<br />
| None<br />
| [[11.4.0-37]]<br />
|<br />
|<br />
|}<br />
<br />
=== Standalone Sysmodules ===<br />
{| class="wikitable" border="1"<br />
|-<br />
! Summary<br />
! Description<br />
! Successful exploitation result<br />
! Fixed in system-module system-version<br />
! Last system-module system-version this flaw was checked for<br />
! Timeframe this was discovered<br />
! Timeframe this was added to wiki<br />
! Discovered by<br />
|-<br />
| [[MP:SendDataFrame]] missing input array index validation<br />
| [[MP:SendDataFrame]] doesn't validate the input index at cmdreq[1], unless the function for flag=non-zero is executed. This is used to calculate the following, without validating the index at all: someptr = stateptr + (index*0x924) + somestateoffset.<br />
<br />
After validating some flags from someptr, when input_flag=0 the input buffer data is copied to someptr+someotheroffset+0x14 with the u16 size loaded from someptr+someotheroffset.<br />
<br />
With a large input index someptr could be setup to be at a <target address>, for overwriting memory.<br />
<br />
This is probably difficult to exploit.<br />
| <br />
| None<br />
| [[8.0.0-18]](MP-sysmodule v2048)<br />
| January 22, 2017<br />
| January 22, 2017<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[MP_Services|MP]] cmd1 out-of-bounds handle read<br />
| MP-sysmodule handles the input parameter for cmd1 as a s32. It checks for >=16, but not <0. With <16 it basically does the following(array of entries 4-bytes each): *outhandle = ((Handle*)(stateptr+offsetinstate))[inputindex].<br />
<br />
Hence, this can be used to load any handle in MP-sysmodule memory. MP doesn't really have any service handles of interest however(can be obtained from elsewhere too).<br />
| Reading any handle in MP-sysmodule memory.<br />
| None<br />
| [[8.0.0-18]](MP-sysmodule v2048)<br />
| January 21, 2017<br />
| January 22, 2017<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| AM stack/.bss infoleak via [[AM:ReadTwlBackupInfo]]([[AM:ReadTwlBackupInfoEx|Ex]])<br />
| After writing the output-info structure to stack, it then copies that structure to the output buffer ptr using the size from the command. The size is not checked. This could be used to read data from the AM-service-thread stack handling the command + .bss.<br />
<br />
'''This was not tested on hardware.'''<br />
| Stack/.bss reading<br />
| None<br />
| [[10.0.0-27]](AM v9217)<br />
| Roughly October 17, 2016<br />
| October 25, 2016<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[MVD_Services|MVD]]: Stack buffer overflow with [[MVDSTD:SetupOutputBuffers]].<br />
| The input total_entries is not validated when initially processing the input entry-list. This fixed-size input entry-list is copied to stack from the command request. The loop for processing this initializes a global table, the converted linearmem->physaddrs used there are also copied to stack(0x8-bytes of physaddrs per entry).<br />
<br />
If total_entries is too large, MVD-sysmodule will crash due to reading unmapped memory following the stack(0x10000000). Afterwards if the out-of-bounds total_entries is smaller than that, it will crash due accessing address 0x0, hence this useless.<br />
| MVD-sysmodule crash.<br />
| None<br />
| [[9.0.0-20]]<br />
| April 22, 2016 (Tested on the 25th)<br />
| April 25, 2016<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[NWM_Services|NWM]]: Using CTRSDK heap with UDS sharedmem from the user-process.<br />
| See the HTTP-sysmodule section below.<br />
<br />
CTRSDK heap is used with the sharedmem from [[NWMUDS:InitializeWithVersion]]. Buffers are allocated/freed under this heap using [[NWMUDS:Bind]] and [[NWMUDS:Unbind]].<br />
<br />
Hence, overwriting sharedmem with gspwn then using [[NWMUDS:Unbind]] results in the usual controlled CTRSDK memchunk-header write, similar to HTTP-sysmodule.<br />
<br />
This could be done by creating an UDS network, without any other nodes on the network.<br />
<br />
Besides CTRSDK memchunk-headers, there are no addresses stored under this sharedmem.<br />
| ROP under NWM-module.<br />
| [[11.4.0-37|11.4.0-X]]<br />
| [[9.0.0-20|9.0.0-X]]<br />
| April 10, 2016<br />
| April 16, 2016<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[DLP_Services|DLP]]: Out-of-bounds memory access during spectator [[Download_Play|data-frame]] checksum calculation<br />
| DLP doesn't validate the frame_size when receiving spectator data-frames at all, unlike non-spectator data-frames. The actual spectator data-frame parsing code doesn't use that field either. However, the data-frame checksum calculation code called during checksum verification does use the frame_size for loading the size of the framebuf.<br />
<br />
Hence, using a large frame_size like 0xFFFF will result in the checksum calculation code reading data out-of-bounds. This isn't really useful, you could trigger a remote local-WLAN DLP-sysmodule crash while a 3DS system is scanning for DLP networks(due to accessing unmapped memory), but that's about all(trying to infoleak with this likely isn't useful either).<br />
| DLP-sysmodule crash, handled by dlplay system-application by a "connection interrupted" error eventually then a fatal-error via ErrDisp.<br />
| None<br />
| [[10.0.0-27|10.0.0-X]]<br />
| April 8, 2016 (Tested on the 10th)<br />
| April 10, 2016<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[DLP_Services|DLP]]: Out-of-bounds output data writing during spectator sysupdate titlelist [[Download_Play|data-frame]] handling<br />
| The total_entries and out_entryindex fields for the titlelist DLP spectator data-frames are not validated. This is parsed during DLP network scanning. Hence, the specified titlelist data can be written out-of-bounds using the specified out_entryindex and total_entries. A crash will occur while reading the input data-frame titlelist if total_entries is larger than 0x27A, due to accessing unmapped memory.<br />
<br />
There's not much non-zero data to overwrite following the output buffer(located in sharedmem), any ptrs are located in sharedmem. Overwriting certain ptr(s) are only known to cause a crash when attempting to use the DLP-client shutdown service-command.<br />
<br />
There's no known way to exploit the above crash, since the linked-list code involves writes zeros(with a controlled start ptr).<br />
| <br />
| None<br />
| [[10.0.0-27|10.0.0-X]]<br />
| April 8-9, 2016<br />
| April 10, 2016<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[IR_Services|IR]]: Stack buffer overflow with custom hardware<br />
| Originally IR sysmodule used the read value from the I2C-IR registers TXLVL and RXLVL without validating them at all. See [[10.6.0-31|here]] for the fix. This is the size used for reading the data-recv FIFO, etc. The output buffer for reading is located on the stack.<br />
<br />
This should be exploitable if one could successfully setup the custom hardware for this and if the entire intended sizes actually get read from I2C.<br />
| ROP under IR sysmodule.<br />
| [[10.6.0-31|10.6.0-31]]<br />
| <br />
| February 23, 2016 (Unknown if it was noticed before then)<br />
| February 23, 2016<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[HTTP_Services|HTTP]]: Using CTRSDK heap with sharedmem from the user-process.<br />
| The data from httpcAddPostDataAscii and other commands is stored under a CTRSDK heap. That heap is the sharedmem specified by the user-process via the HTTPC Initialize command.<br />
Normally this sharedmem isn't accessible to the user-process once the sysmodule maps it, hence using it is supposed to be "safe".<br />
<br />
This isn't the case due to gspwn however. Since CTRSDK heap code is so insecure in general, one can use gspwn to locate the HTTPC sharedmem + read/write it, then trigger a mem-write under the sysmodule. This can then be used to get ROP going under HTTP-sysmodule.<br />
<br />
This is exploited by [https://github.com/yellows8/ctr-httpwn/ctr-httpwn ctr-httpwn].<br />
| ROP under HTTP sysmdule.<br />
| [[11.4.0-37|11.4.0-X]]<br />
| [[9.6.0-24|9.6.0-X]] (Latest sysmodule version as of [[10.7.0-32|10.7.0-32]])<br />
| Late 2015<br />
| March 22, 2016<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[NIM_Services|NIM]]: Downloading old title-versions from eShop<br />
| Multiple NIM service commands(such as [[NIMS:StartDownload]]) use a title-version value specified by the user-process, NIM does not validate that this input version matches the latest version available via SOAP. Therefore, when combined with AM(PXI) [[#Process9|title-downgrading]] via deleting the target eShop title with System Settings Data Management(if the title was already installed), this allows downloading+installing any title-version from eShop ''if'' it's still available from CDN.<br />
The easiest way to exploit this is to just patch the eShop system-application code using these NIM commands(ideally the code which loads the title-version).<br />
<br />
Originally this was tested with a debugging-system via modded-FIRM, eventually smea implemented it in HANS for the 32c3 release.<br />
| Downloading old title-versions from eShop<br />
| None<br />
| [[10.0.0-27|10.0.0-X]]<br />
| October 24, 2015 (Unknown when exactly the first eShop title downgrade was actually tested, maybe November)<br />
| January 7, 2016 (Same day Ironfall v1.0 was removed from CDN via the main-CXI files)<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[SPI_Services|SPI]] service out-of-bounds write<br />
| cmd1 has out-of-bounds write allowing overwrite of some static variables in .data.<br />
| <br />
| None<br />
| [[9.5.0-22]]<br />
| March 2015<br />
| <br />
| [[User:Plutooo|plutoo]]<br />
|-<br />
| [[NFC_Services|NFC]] module service command buf-overflows<br />
| NFC module copies data with certain commands, from command input buffers to stack without checking the size. These commands include the following, it's unknown if there's more commands with similar issues: "nfc:dev" <0x000C....> and "nfc:s" <0x0037....>.<br />
Since both of these commands are stubbed in the Old3DS NFC module from the very first version(those just return an error), these issues only affect the New3DS NFC module.<br />
<br />
There's no known retail titles which have access to either of these services.<br />
| ROP under NFC module.<br />
| New3DS: None<br />
| New3DS: [[9.5.0-22]]<br />
| December 2014?<br />
| <br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[News_Services|NEWSS]] service command notificationID validation failure<br />
| This module does not validate the input notificationID for <nowiki>"news:s"</nowiki> service commands. This is an out-of-bounds array index bug. For example, [[NEWSS:SetNotificationHeader]] could be used to exploit news module: this copies the input data(size is properly checked) to: out = newsdb_savedata+0x10 + (someu32array[notificationID]*0x70).<br />
| ROP under news module.<br />
| None<br />
| [[9.7.0-25|9.7.0-X]]<br />
| December 2014<br />
| <br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[NWMUDS:DecryptBeaconData]] heap buffer overflow<br />
| input_size = 0x1E * <value the u8 from input_[[NWM_Services|networkstruct]]+0x1D>. Then input_tag0 is copied to a heap buffer. When input_size is larger than 0xFA-bytes, it will then copy input_tag1 to <end_address_of_previous_outbuf>, with size=input_size-0xFA.<br />
<br />
This can be triggered by either using this command directly, or by boadcasting a wifi beacon which triggers it while a 3DS system running the target process is in range, when the process is scanning for hosts to connect to. Processes will only pass tag data to this command when the wlancommID and other thing(s) match the values for the process.<br />
<br />
There's no known way to actually exploit this for getting ROP under NWM-module, at the time of originally adding this to the wiki. This is because the data which gets copied out-of-bounds *and* actually causes crash(es), can't be controlled it seems(with just broadcasting a beacon at least). It's unknown whether this could be exploited from just using NWMUDS service-cmd(s) directly.<br />
| Without any actual way to exploit this: NWM-module DoS, resulting in process termination(process crash). This breaks *everything* involving wifi comms, a reboot is required to recover from this.<br />
| None<br />
| [[9.0.0-20]]<br />
| ~September 23, 2014(see the [[NWMUDS:DecryptBeaconData]] page history)<br />
| August 3, 2015<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[HID_Services|HID]] module shared-mem<br />
| HID module does not validate the index values in [[HID_Shared_Memory|sharedmem]](just changes index to 0 when index == maxval when updating), therefore large values will result in HID module writing HID data to arbitrary addresses.<br />
| ROP under HID module, but this is *very* unlikely to be exploitable since the data written is HID data.<br />
| None<br />
| [[9.3.0-21]]<br />
| 2014?<br />
| <br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| gspwn<br />
| GSP module does not validate addresses given to the GPU. This allows a user-mode application/applet to read/write to a large part of physical FCRAM using GPU DMA. From this, you can overwrite the .text segment of the application you're running under, and gain real code-execution from a ROP-chain. Normally applets' .text([[Home Menu]], [[Internet Browser]], etc) is located beyond the area accessible by the GPU, except for [[RO_Services|CROs]] used by applets([[Internet Browser]] for example).<br />
<br />
FCRAM is gpu-accessible up to physaddr 0x26800000 on Old3DS, and 0x2D800000 on New3DS. This is BASE_memregion_start(aka SYSTEM_memregion_end)-0x400000 (0x800000 with New3DS) with the default memory-layout on Old3DS/New3DS. With [[11.3.0-36|11.3.0-X]] the cutoff now varies due to the new [[SVC]] 0x59. The New3DS "normal"(non-APPLICATION) cutoff was changed to 0x2D000000 due to the new [[SVC]] 0x59.<br />
| User-mode code execution.<br />
| None<br />
| [[9.6.0-24|9.6.0-X]]<br />
| Early 2014<br />
| <br />
| smea, [[User:Yellows8|Yellows8]]/others before then<br />
|-<br />
| rohax<br />
| Using gspwn, it is possible to overwrite a loaded [[CRO0]]/[[CRR0]] after its RSA-signature has been validated. Badly validated [[CRO0]] header leads to arbitrary read/write of memory in the ro-process. This gives code-execution in the ro module, who has access to [[SVC|syscalls]] 0x70-0x72, 0x7D.<br />
<br />
This was fixed after [[ninjhax]] release by adding checks on [[CRO0]]-based pointers before writing to them.<br />
| Memory-mapping syscalls.<br />
| [[9.3.0-21]]<br />
| [[9.4.0-21]]<br />
| <br />
| <br />
| smea, [[User:Plutooo|plutoo]] joint effort<br />
|-<br />
| Region free<br />
| Only [[Home Menu]] itself checks gamecards' region when launching them. Therefore, any application launch that is done directly with [[NS]] without signaling Home Menu to launch the app, will result in region checks being bypassed.<br />
This essentially means launching the gamecard with the [[NS_and_APT_Services|"ns:s"]] service. The main way to exploit this is to trigger a FIRM launch with an application specified, either with a normal FIRM launch or a hardware [[NSS:RebootSystem|reboot]].<br />
| Launching gamecards from any region + bypassing Home Menu gamecard-sysupdate installation<br />
| None<br />
| Last tested with [[10.1.0-27|10.1.0-X]].<br />
| June(?) 2014<br />
| <br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[NWM_Services|NWM]] service-cmd state null-ptr deref<br />
| The NWMUDS service command code loads a ptr from .data, adds an offset to that, then passes that as the state address for the actual command-handler function. The value of the ptr loaded from .data is not checked, therefore this will cause crashes due to that being 0x0 when NWMUDS was not properly initialized.<br />
It's unknown whether any NWM services besides NWMUDS have this issue.<br />
| This is rather useless since it's only a crash caused by a state ptr based at 0x0.<br />
| None<br />
| [[9.0.0-20]]<br />
| 2013?<br />
| <br />
| [[User:Yellows8|Yellows8]]<br />
|}<br />
<br />
=== General/CTRSDK ===<br />
{| class="wikitable" border="1"<br />
|-<br />
! Summary<br />
! Description<br />
! Successful exploitation result<br />
! Fixed in version<br />
! Last version this flaw was checked for<br />
! Timeframe this was discovered<br />
! Discovered by<br />
|-<br />
| [[NWM_Services|UDS]] beacon additional-data buffer overflow<br />
| Originally CTRSDK did not validate the UDS additional-data size before using that size to copy the additional-data to a [[NWM_Services|networkstruct]]. This was eventually fixed.<br />
This was discovered while doing code RE with an old dlp-module version. It's unknown in what specific CTRSDK version this was fixed, or even what system-version updated titles with a fixed version.<br />
<br />
It's unknown if there's any titles using a vulnerable CTRSDK version which are also exploitable with this(dlp module can't be exploited with this).<br />
<br />
The maximum number of bytes that can be written beyond the end of the outbuf is 0x37-bytes, with additionaldata_size=0xFF.<br />
| Perhaps ROP, very difficult if possible with anything at all<br />
| ?<br />
| <br />
| September(?) 2014<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| CTPK buffer overflow<br />
| At offset 0x20 in CTPK is an array for each texture, each entry is 0x20-bytes. This contains a wordindex(entry+0x18) for some srcdata relative to CTPK+0, and an u8 wordsize(entry+0x14) for this data. The CTRSDK function handling this doesn't validate the size, when copying srcdata using this size to the output buffer. Applications usually have the output buffer on the stack, hence stack buffer overflow.<br />
<br />
While CTPK(*.ctpk) are normally only loaded from RomFS, some application(s) load from elsewhere too.<br />
| ROP under the target application.<br />
| None?<br />
| "[SDK+NINTENDO:CTR_SDK-11_4_0_200_none]"<br />
| November 14, 2016<br />
| [[User:Yellows8|Yellows8]]<br />
|}</div>Myriahttps://www.3dbrew.org/w/index.php?title=3DS_System_Flaws&diff=208123DS System Flaws2018-08-12T06:31:49Z<p>Myria: /* Process9 */ Historical entry "FIRM launch doesn't check target FIRM version"</p>
<hr />
<div>Exploits are used to execute unofficial code (homebrew) on the Nintendo 3DS. This page is a list of publicly known system flaws, for userland applications/applets flaws see [[3DS_Userland_Flaws|here]].<br />
<br />
=Stale / Rejected Efforts=<br />
* Neimod has been working on a RAM dumping setup for a little while now. He's de-soldered the 3DS's RAM chip and hooked it and the RAM pinouts on the 3DS' PCB up to a custom RAM dumping setup. A while ago he published photos showing his setup to be working quite well, with the 3DS successfully booting up. However, his flickr stream is now private along with most of his work.<br />
<br />
* Someone (who will remain unnamed) has released CFW and CIA installers, all of which is copied from the work of others, or copyrighted material.<br />
<br />
==Tips and info==<br />
The 3DS uses the XN feature of the ARM11 processor. There's no official way from applications to enable executable permission for memory containing arbitrary unsigned code(there's a [[SVC]] for this, but only [[RO_Services|RO-module]] has access to it). A usable userland exploit would still be useful: you could only do return-oriented-programming with it initially. From ROP one could then exploit system flaw(s), see below.<br />
<br />
SD card [[extdata]] and SD savegames can be attacked, for consoles where the console-unique [[Nand/private/movable.sed|movable.sed]] was dumped(accessing SD data is far easier by running code on the target 3DS however).<br />
<br />
=System flaws=<br />
== Hardware ==<br />
{| class="wikitable" border="1"<br />
! Summary<br />
! Description<br />
! Fixed with hardware model/revision<br />
! Newest hardware model/revision this flaw was checked for<br />
! Timeframe this was discovered<br />
! Discovered by<br />
|-<br />
| ARM9/ARM11 bootrom vectors point at uninitialized RAM<br />
| ARM9's and ARM11's exception vectors are hardcoded to point at the CPU's internal memory (0x08000000 region for ARM9, AXIWRAM for ARM11). While the bootrom does set them up to point to an endless loop at some point during boot, it does not do so immediately. As such, a carefully-timed fault injection (via hardware) to trigger an exception (such as an invalid instruction) will cause execution to fall into ARM9 RAM. <br />
Since RAM isn't cleared on boot (see below), one can immediately start execution of their own code here to dump bootrom, OTP, etc.<br />
The ARM9 bootrom does the following at reset: reset vector branches to another instruction, then branches to bootrom+0x8000. Hence, there's no way to know for certain when exactly the ARM9 exception-vector data stored in memory gets initialized.<br />
<br />
This requires *very* *precise* timing for triggering the hardware fault.<br />
<br />
It has been exploited by derrek to dump the ARM9 bootrom as of Summer 2015.<br />
| None: all available 3DS models at the time of writing have the exact same ARM9/ARM11 bootrom for the unprotected areas.<br />
| New3DS<br />
| End of February 2014<br />
| [[User:Derrek|derrek]], WulfyStylez (May 2015) independently<br />
|-<br />
| Missing AES key clearing<br />
| The hardware AES engine does not clear keys when doing a hard reset/reboot.<br />
| None<br />
| New3DS<br />
| August 2014<br />
| Mathieulh/Others<br />
|-<br />
| No RAM clearing on reboots<br />
| On an MCU-triggered reboot all RAM including FCRAM/ARM9 memory/AXIWRAM/VRAM keeps its contents.<br />
| None<br />
| New3DS<br />
| March 2014<br />
| [[User:Derrek|derrek]]<br />
|-<br />
| 32bits of actual console-unique TWLNAND keydata<br />
| On retail the 8-bytes at ARM9 address [[Memory_layout|0x01FFB808]] are XORed with hard-coded data, to generate the TWL console-unique keys, including TWLNAND. On Old3DS the high u32 is always 0x0, while on New3DS that u32 is always 0x2. On top of this, the lower u32's highest bit is always ORed. only 31 bits of the TWL console-unique keydata / TWL consoleID are actually console-unique.<br />
This allows one to easily bruteforce the TWL console-unique keydata with *just* data from TWLNAND. On DSi the actual console-unique data for key generation is 8-bytes(all bytes actually set).<br />
| None<br />
| New3DS<br />
| 2012?<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| DSi / 3DS-TWL key-generator<br />
| After using the key generator to generate the normal-key, you could overwrite parts of the normal-key with your own data and then recover the key-generator output by comparing the new crypto output with the original crypto output. From the normal-key outputs, you could deduce the TWL key-generator function.<br />
This applies to the keyX/keyY too.<br />
<br />
This attack does not work for the 3DS key-generator because keyslots 0-3 are only for TWL keys.<br />
| None<br />
| New3DS<br />
| 2011<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| 3DS key-generator<br />
| The algorithm for generating the normal-keys for keyslots is cryptographically weak. As a result, it is easily susceptible to differential cryptanalysis if the normal-key corresponding to any scrambler-generated keyslot is discovered.<br />
<br />
Several such pairs of matching normal-keys and KeyY values were found, leading to deducing the key-generator function.<br />
| None<br />
| New3DS<br />
| February 2015<br />
| [[User:Yellows8|Yellows8]], [[User:Plutooo|plutoo]]<br />
|-<br />
| RSA keyslots don't clear exponent when setting modulus<br />
| The [[RSA_Registers|RSA keyslots]] are set by boot ROM to have four private RSA keys. The exponent value in the RSA registers is write-only and not readable.<br />
<br />
However, when setting a keyslot's modulus, the RSA hardware leaves the exponent alone. This allows retrieving the exponent by doing a discrete logarithm of the output.<br />
<br />
By setting the modulus to a prime number whose modular multiplicative order is "smooth" (that is, p-1 is divisible by only small prime numbers), discrete logarithms can be calculated quickly using the [[wikipedia:Pohlig-Hellman algorithm|Pohlig-Hellman algorithm]]. If the prime chosen is greater than the modulus, but the same bit size, the discrete logarithm is the private exponent.<br />
<br />
This exploit's usefulness is limited: RSA keyslot 0 is only used in current firmware for deriving the 6.x save and 7.x NCCH keys, which were already known, and the other three keyslots are entirely unused. Additionally, with a boot ROM dump, this exploit is moot; these private keys are located in the protected ARM9 boot ROM.<br />
| None<br />
| New3DS<br />
| March 2016<br />
| [[User:Myria|Myria]]<br />
|-<br />
| [[CONFIG11_Registers#CFG11_GPUPROT|CFG11_GPUPROT]] allowing acccess to AXIWRAM/FCRAM-BASE-memregion<br />
| [[CONFIG11_Registers#CFG11_GPUPROT|CFG11_GPUPROT]] can be configured by anything with access to it to allow the GPU to access the entire AXIWRAM+FCRAM. For example, this is an issue for any sysmodule that gets exploited and has access to this register memory-page(include one that's listed below).<br />
<br />
See also "kernelhax via gspwn" below.<br />
| None<br />
| New3DS<br />
| February 7, 2017<br />
| [[User:Yellows8|Yellows8]]<br />
|}<br />
<br />
== Boot ROM ==<br />
{| class="wikitable" border="1"<br />
! Summary<br />
! Description<br />
! Fixed with hardware model/revision<br />
! Newest hardware model/revision this flaw was checked for<br />
! Timeframe this was discovered<br />
! Discovered by<br />
|-<br />
| FIRM partitions known-plaintext<br />
| The [[Flash_Filesystem|FIRM partitions]] are encrypted with AES-CTR without a MAC. Since this works by XOR'ing data with a static (per-console in this case) keystream, one can deduce the keystream of a portion of each FIRM partition if they have the actual FIRM binary stored in it.<br />
<br />
This can be paired with many exploits. For example, it allows minor FIRM downgrades (i.e. 10.4 to 9.6 or 9.5 to 9.4, but not 9.6 to 9.5).<br />
However it is most commonly used to install arbitrary FIRMs (usually boot9strap), thanks to sighax.<br />
<br />
This can be somewhat addressed by having a FIRM header skip over previously used section offsets, but this would just air-gap newer FIRMs without fixing the core bug. This can also only be done a limited number of times due to the size of FIRM versus the size of the partitions.<br />
| None<br />
| New3DS<br />
| <br />
| Everyone<br />
|-<br />
| Boot9 AES keyinit function issues<br />
| [[Bootloader|Boot9]] seems to have two bugs in the AES key-init function, see [[AES_Registers#AES_key-init|here]].<br />
| None<br />
| BootROM issue.<br />
| 2015<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| New3DS has same boot ROM as Old3DS<br />
| The New3DS has the exact same boot ROM as the Old3DS. This means, among other things, that all the same boot ROM flaws are present. Also, this meant that it is possible to boot Old3DS firmware on New3DS (see "CFG_SYSPROT9 bit1 not set by Kernel9").<br />
| None<br />
| New3DS<br />
| October 2014<br />
| Everyone<br />
|-<br />
| sighax: Boot9 improper validation of FIRM partition RSA signatures<br />
| The [[Flash_Filesystem|FIRM partitions]] are signed with RSA-2048 using SHA-256 and PKCS #1 v1.5 padding. Boot9, however, improperly validates the padding in three ways:<br />
# Boot9 permits block type 02, meant for encrypted messages, to be used for signatures. Only 01, for signatures, should have been permitted. As a result, when using block type 02, a signature block is not required to have a long string of FF bytes as padding, but rather any nonzero random values suffice.<br />
# Boot9 does not require that the length of the padding fill out the signature block completely. As a result, there is considerable freedom in the layout of a signature.<br />
# Boot9 fails to do bounds checking in its parsing of the DER-encoded hash algorithm type and hash value; the length values given in DER are permitted to point outside the signature block.<br />
Flaw 3 allows the DER encoding to be such that boot9 believes that the signature's hash value is outside the range of the block itself, somewhere on the stack. This can be pointed at the correct hash value it computes. Boot9 then memcmp's the calculated hash against itself, and thinks that the hash is valid.<br />
<br />
As a result of the above, we estimate that one in 2<sup>43</sup> (~8.8 trillion) random fake signatures will be considered by Boot9 to be valid. This is well within the range of brute force, particularly with an optimized GPU implementation. An Nvidia GTX 1080 Ti would take about one week to find a match.<br />
| None<br />
| New3DS<br />
| July 2015<br />
| [[User:Derrek|derrek]]<br />
|-<br />
| Boot9 FIRM loading doesn't blacklist memory-mapped I/O<br />
| [[Bootloader|Boot9]]'s FIRM loading blacklists Boot9 data regions, but forgets to do other important regions, including Memory-mapped I/O. Combined with sighax, by loading a malicious FIRM section to MMIO, one can get Boot9/Boot11 code execution. <br />
| None<br />
| New3DS<br />
| 2015(?)<br />
| [[User:Derrek|derrek]] (2015?), [[User:Normmatt|Normmatt]] and [[User:SciresM|SciresM]] independently (January 2017).<br />
|-<br />
| "superhax": Boot9 FIRM loading blacklist check is flawed<br />
| Boot9 only makes sure the '''start''' and '''end''' address of each section is not covered by a blacklisted region. Thus, it is possible to overwrite blacklisted regions (e.g. ARM9 Exception Vectors) by choosing a FIRM section range that encloses an entire blacklisted region. The vulnerable code looks like this: if(blRegions[i].start <= sectionStart && blRegions[i].end > sectionStart <nowiki>||</nowiki> blRegions[i].start <= sectionEnd && blRegions[i].end > sectionEnd) return false; // failure<br />
| None<br />
| New3DS<br />
| August 2015<br />
| [[User:Plutoo|plutoo]], [[User:Yellows8|yellows8]]<br />
|}<br />
<br />
== ARM9 software ==<br />
<br />
=== arm9loader ===<br />
{| class="wikitable" border="1"<br />
|-<br />
! Summary<br />
! Description<br />
! Successful exploitation result<br />
! Fixed in [[FIRM]] system version<br />
! Last [[FIRM]] system version this flaw was checked for<br />
! Timeframe this was discovered<br />
! Public disclosure timeframe<br />
! Discovered by<br />
|-<br />
| Generating the keysector console-unique keys with ITCM+Boot9<br />
| [[Bootloader|Boot9]] decrypts the 0x100-byte [[OTP_Registers|OTP]] using AES-CBC with keydata stored in Boot9. If hash verification is successful, the plaintext of the first 0x90-bytes are copied into [[Memory_layout|ITCM]]. This is the ''exact'' ''same'' region hashed by arm9loader when generating the console-unique keys for decrypting the keysector, except arm9loader uses the raw encrypted OTP.<br />
<br />
Therefore, with the OTP keydata+IV from Boot9 you can: encrypt the 0x90-bytes from ITCM, then hash the output to get the console-unique keys for the system's keysector. This can even be done for Old3DS which doesn't have the arm9loader keysector officially.<br />
<br />
It's unknown why arm9loader only used the first 0x90-bytes of OTP. Using more data from OTP would've prevented this. Fixing this would require doing exactly that, but that would also mean updating the NAND keysector(which is dangerous).<br />
| See description.<br />
| None<br />
| <br />
| 2015<br />
| January 6, 2017<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| Rearrangable keys in the NAND keystore<br />
| Due to the keystore being encrypted with AES-ECB, one can rearrange blocks and still have the NAND keystore decrypt in a deterministic way. <br />
<br />
Using 10.0 FIRM it is possible to rearrange keys such that ARM9 memory is executed. As such using existing ARM9 execution 10.0 FIRM can be written to NAND and a payload written to memory, with the payload to be executed post-K9L using an MCU reboot.<br />
| arm9loaderhax given existing ARM9 code execution<br />
| None<br />
| [[11.3.0-36|11.3.0-X]]<br />
| Early 2016<br />
| 27 September 2016<br />
| Myria, [[User:Dark samus|dark_samus]]; mathieulh (independently); [[User:Plutooo|plutoo]] (independently) + others<br />
|-<br />
| Uncleared OTP hash keydata in console-unique 0x11 key-generation<br />
| Kernel9Loader does not clear the [[SHA_Registers#SHA_HASH|SHA_HASH register]] after use. As a result, the data stored here as K9L hands over to Kernel9 is the hash of [[OTP_Registers|OTP data]] used to seed the [[FIRM#New_3DS_FIRM|console-unique NAND keystore decryption key]] set on keyslot 0x11.<br />
<br />
Retrieving this keydata and the [[Flash_Filesystem#0x12C00|NAND keystore]] of the same device allows calculating the decrypted New3DS NAND keystore (non-unique, common to all New3DS units), which contains AES normal keys, also set on keyslot 0x11, which are then used to derive all current [[AES_Registers#Keyslots|New3DS-only AES keyXs]] including the newer batch introduced in [[9.6.0-24#arm9loader|9.6.0-X]]. From there, it is trivial to perform the same key derivation in order to initialize those keys on any system version, and even on Old3DS.<br />
<br />
This can be performed by exploiting the "arm9loaderhax" vulnerability to obtain post-K9L code execution after an MCU reboot (the bootrom section-loading fail is not relevant here, this attack was performed without OTP data by brute-forcing keys), and using this to dump the SHA_HASH register. This attack works on any FIRM version shipping a vulnerable version of K9L, whereas OTP dumping required a boot of <[[3.0.0-6|3.0.0-X]].<br />
<br />
This attack results in obtaining the entire (0x200-bytes) NAND keystore - it was confirmed at a later date that this keystore is encrypted with the same key (by comparing the decrypted data from multiple units), and therefore using another key in this store will not remedy the issue as all keys are known (i.e. later, unused keys decrypt to the same 0x200-bytes constant with the same OTP hash). Later keys could have been encrypted differently but this is not the case. As a result of this, it is not possible for Nintendo to use K9L again in its current format for its intended purpose, though this was not news from the moment people dumped a New3DS OTP.<br />
| Derivation of all New3DS keys generated via the NAND keystore (0x1B "Secure4" etc.)<br />
| None<br />
| [[11.3.0-36|11.3.0-X]]<br />
| ~April 2015, implemented in May 2015<br />
| 13 January 2016<br />
| [[User:WulfyStylez|WulfyStylez]], [[User:Dazzozo|Dazzozo]], [[User:Shinyquagsire23|shinyquagsire23]] (complimentary + implemented), [[User:Plutooo|plutoo]], Normmatt (discovered independently)<br />
|-<br />
| enhanced-arm9loaderhax<br />
| See the 32c3 3ds talk.<br />
Since this is a combination of a trick with the arm9-bootrom + arm9loaderhax, and since you have to manually write FIRM to the firm0/firm1 NAND partitions, this can't be completely fixed. Any system with existing ARM9 code execution and an OTP/OTP hash dump can exploit this. Additionally, by using the FIRM partition known-plaintext bug and bruteforcing the second entry in the keystore, this can currently be exploited on all New3DS systems without any other prerequisite hacks.<br />
| arm9loaderhax which automatically occurs at hard-boot.<br />
| See arm9loaderhax / description.<br />
| See arm9loaderhax / description.<br />
| Theorized around mid July, 2015. Later implemented+tested by [[User:Plutooo|plutoo]] and [[User:Derrek|derrek]].<br />
| 32c3 3ds talk (December 27, 2015)<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| arm9loaderhax: Missing verification block for the 9.6 keys<br />
| Starting with [[9.6.0-24|9.6.0-X]] a new set of NAND-based keys were introduced. However, no verification block was added to verify that the new key read from NAND is correct. This was technically an issue from [[9.5.0-22|9.5.0-X]] with the original sector+0 keydata, however the below is only possible with [[9.6.0-24|9.6.0-X]] since keyslots 0x15 and 0x16 are generated from different 0x11 keyXs.<br />
<br />
Writing an incorrect key to NAND will cause arm9loader to decrypt the ARM9 kernel as garbage and then jump to it.<br />
<br />
This allows an hardware-based attack where you can boot into an older exploited firmware, fill all memory with NOP sleds/jump-instructions, and then reboot into executing garbage. By automating this process with various input keydata, eventually you'll find some garbage that jumps to your code.<br />
<br />
This gives very early ARM9 code execution (pre-ARM9 kernel). As such, it is possible to dump RSA keyslots with this and calculate the 6.x [[Savegames#6.0.0-11_Savegame_keyY|save]], and 7.x [[NCCH]] keys. This cannot be used to recover keys initialized by arm9loader itself. This is due to it wiping the area used for its stack during NAND sector decryption and keyslot init. <br />
<br />
Due to FIRMs on both Old and New 3DS using the same RSA data, this can be exploited on Old3DS as well, but only if one already has the actual plaintext normalkey from New3DS NAND sector 0x96 offset-0 and has dumped the OTP area of the Old3DS.<br />
| Recovery of 6.x [[Savegames#6.0.0-11_Savegame_keyY|save key]]/7.x [[NCCH]] key, access to uncleared OTP hash keydata<br />
| None<br />
| [[11.3.0-36|11.3.0-X]]<br />
| March 2015<br />
| <br />
| [[User:Plutooo|plutoo]]<br />
|-<br />
| arm9loader runs on Old3DS<br />
| Despite being written only for New3DS, all of arm9loader runs fine on Old3DS. It's not until booting Kernel9 that a New3DS FIRM partition would crash on an Old3DS. As a result, if a bug exists in arm9loader to get control, it can be exploited on Old3DS by writing New3DS FIRM to the FIRM partitions. Thus, arm9loaderhax works on both Old3DS and New3DS.<br />
| arm9loader bugs also compromise Old3DS<br />
| None<br />
| [[11.3.0-36|11.3.0-X]]<br />
| Sometime in 2015<br />
| <br />
| [[User:Plutooo|plutoo]] presumably<br />
|-<br />
| Uncleared New3DS keyslot 0x11<br />
| Originally the New3DS [[FIRM]] arm9bin loader only cleared keyslot 0x11 when it gets executed at firmlaunch. This was fixed with [[9.5.0-22|9.5.0-X]] by completely clearing keyslot 0x11 immediately after the loader finishes using keyslot 0x11.<br />
This means that any ARM9 code that can execute before the loader clears the keyslot at firmlaunch(including firmlaunch-hax) can get access to the uncleared keyslot 0x11, which then allows one to generate all <=v9.5 New3DS keyXs which are generated by keyslot 0x11.<br />
<br />
Therefore, to completely fix this the loader would have to generate more keys using different keyslot 0x11 keydata. This was done with [[9.6.0-24|9.6.0-X]].<br />
| New3DS keyXs generation<br />
| Mostly fixed with [[9.5.0-22|9.5.0-X]], completely fixed with new keys with [[9.6.0-24|9.6.0-X]].<br />
| <br />
| February 3, 2015 (one day after [[9.5.0-22|9.5.0-X]] release)<br />
| <br />
| [[User:Yellows8|Yellows8]]<br />
|}<br />
<br />
=== Process9 ===<br />
{| class="wikitable" border="1"<br />
|-<br />
! Summary<br />
! Description<br />
! Successful exploitation result<br />
! Fixed in [[FIRM]] system version<br />
! Last [[FIRM]] system version this flaw was checked for<br />
! Timeframe this was discovered<br />
! Public disclosure timeframe<br />
! Discovered by<br />
|-<br />
| Leak of normal-key matching a key-scrambler key<br />
| New 3DS firmware versions [[8.1.0-0 New3DS|8.1.0]] through [[9.2.0-20|9.2.0]] set the encryption key for [[Amiibo]] data using a hardcoded normal-key in Process9. In firmware [[9.3.0-21|9.3.0]], Nintendo "fixed" this by using the key scrambler instead, by calculating the keyY value for keyslot 0x39 that results in the same normal-key, then hardcoding that keyY into Process9.<br />
<br />
Nintendo's fix is actually the problem: Nintendo revealed the normal-key matching an unknown keyX and a known keyY. Combined with the key scrambler using an insecure scrambling algorithm (see "Hardware" above), the key scrambler function could be deduced.<br />
| Deducing the keyX for keyslot 0x39 and the key scrambler algorithm<br />
| New 3DS [[9.3.0-21|9.3.0-X]], sort of<br />
| [[10.0.0-27|10.0.0-X]]<br />
| Sometime in 2015 after the hardware key-generator was broken.<br />
| 32c3 3ds talk (December 27, 2015)<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| Leak of normal-key matching a key-generator key<br />
| During the 3DS' development (June/July 2010) Nintendo added support installing encrypted content ([[CIA]]). Common-key index1 was intended to be a [[AES|hardware generated key]]. However while they added code to generate the key in hardware, they forgot to remove the normal-key for index1 (used elsewhere, likely old debug code). Nintendo later removed the normal key sometime before the first non-prototype firmware release.<br />
<br />
Knowing the keyY and the normal-key for common-key index1, the devkit key-generator algorithm can be deduced (see "Hardware" above). Additionally the remaining devkit common-keys can be generated once the common-key keyX is recovered.<br />
<br />
Note that the devkit key-generator was discovered to be the same as the retail key-generator.<br />
| Deducing the keyX for keyslot 0x3D and hardware key-generator algorithm. Generate remaining devkit common-keys.<br />
| pre-[[1.0.0-0|1.0.0-X]]<br />
| <br />
| Shortly after the key-generator was revealed to be flawed at the 32c3 3ds talk<br />
| January 20, 2016<br />
| [[User:Jakcron|jakcron]]<br />
|-<br />
| Factory firmware is vulnerable to sighax<br />
| During the 3DS's development, presumably boot9 was written (including the sighax) vulnerability. This vulnerability is also present in factory firmware (and earlier, including 0.11). This was fixed in version 1.0.0-0.<br />
| Deducing the mechanics of the sighax vulnerability in boot9 without having boot9 prot. Arm9 code execution on factory/earlier firmware.<br />
| [[1.0.0-0|1.0.0-X]]<br />
| [[1.0.0-0|1.0.0-X]]<br />
| May 9, 2017<br />
| May 19, 2017<br />
| [[User:SciresM|SciresM]], [[User:Myria|Myria]]<br />
|-<br />
| safefirmhax<br />
| SAFE_MODE_FIRM is almost never updated(even when NATIVE_FIRM is updated for vuln fixes), this can be noticed by ''just'' checking 3dbrew/ninupdates title-listings.<br />
<br />
The fix for 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 <=> Kernel11 sync, PXI sync and then repeat the original attack on SAFE_FIRM instead.<br />
| ARM9 code execution<br />
| [[11.3.0-36|11.3.0-X]]<br />
| <br />
| 2012-2013?<br />
| Wiki: January 2, 2017<br />
| Everyone<br />
|-<br />
| safefirmhax 1.1<br />
| Nintendo's original safefirmhax fix was flawed -- they added a global boolean that got set to true whenever a non-sysmodule title got launched (except for a hardcoded repair title id), and panic()'d if that boolean was true to prevent launching safefirm after hax was active. However, because the boolean was initially false after firmlaunch -- With ARM11-kernel execution, one could FIRM-launch into NATIVE_FIRM, and then immediately FIRM-launch again into SAFE_FIRM early in NATIVE_FIRM boot before the boolean got set to true to repeat the safehax attack.<br />
<br />
This was fixed by adding additional CFG9_BOOTENV checks to firmlaunch code in 11.4.<br />
| ARM9 code execution<br />
| [[11.4.0-37|11.4.0-X]]<br />
| <br />
| safefirmhax fix<br />
| Wiki: April 10, 2017<br />
| Everyone<br />
|-<br />
| ntrcardhax<br />
| When reading the banner of a NTR title, Process9 relies on a hardware register to know when the banner was fully read.<br />
However that register is shared between the ARM9 and the ARM11.<br />
An attacker with k11 control can so make Process9 believe the banner continues forever and so trigger a buffer overflow.<br />
With a custom banner for a NTR flashcart, this leads to code execution in Process9.<br />
<br />
This was fixed by adding bound checks on the read data.<br />
| ARM9 code execution<br />
| [[10.4.0-29|10.4.0-X]]<br />
| <br />
| March 2015<br />
| 32c3 3ds talk (December 27, 2015)<br />
| [[User:Plutooo|plutoo]]<br />
|-<br />
| Title downgrading via [[Application_Manager_Services|AM]]([[Application_Manager_Services_PXI|PXI]])<br />
| When a title is *already* installed, Process9 will compare the installed title-version with the title-version being installed. When the one being installed is older, Process9 would return an error.<br />
<br />
However, this can be bypassed by just deleting the title first via the service command(s) for that: with the title removed from the [[Title_Database]], Process9 can't compare the input title-version with anything. Hence, titles can be downgraded this way.<br />
<br />
[[11.0.0-33|11.0.0-X]] fixed this for key system titles (MSET, Home Menu, spider, ErrDisp, SKATER, NATIVE_FIRM, and every retail system module), by checking the version of the title to install against a hard-coded list of (titleID, minimumVersionRequired) pairs.<br />
| Bypassing title version check at installation, which then allows downgrading any title.<br />
| [[11.0.0-33|11.0.0-X]], for key system titles.<br />
| NATIVE_FIRM / AM-sysmodule [[11.0.0-33|11.0.0-X]]<br />
| ?<br />
| <br />
| ?<br />
|-<br />
| Anti-downgrade list did not include all system titles initially<br />
| The anti-downgrade list did not include legacy FIRMs until [[11.8.0-41|11.8.0-X]]. Therefore, legacy FIRMs could still be downgraded.<br />
| Downgrading legacy FIRMs; allowing to exploit bugs in older legacy FIRMs (of which at least one exists, see below).<br />
| [[11.8.0-33|11.8.0]]<br />
| [[11.8.0-33|11.8.0]]<br />
| ?<br />
| Wiki: August 5, 2018<br />
| Everyone<br />
|-<br />
| TWL_FIRM cmd-9 unchecked offset<br />
| In [[1.0.0-0|1.0.0-X]]'s TWL_FIRM, cmds 8 and 9 were not stubbed (whereas in the corresponding NATIVE_FIRM, they were).<br />
Command 8 does the Process9 initialisation for NTR carts if an NTR cart is inserted (NTR, not TWL, judged by chipid).<br />
<br />
Command 9 takes (u32 offset_read, u32 offset_write, u32 offset_read_end), and basically just copies (offset_read_end - offset_read) bytes starting at (offset_read) of [NTR cart header in arm9mem, NTR secure area in fcram, TWL secure area in fcram], to 0x18001000 + offset_write + offset_read.<br />
<br />
offset_write is not checked at all, thus this leads to ARM9 code execution as long as any NTR cart, including flashcarts that would normally be blocked by TWL_FIRM, is inserted.<br />
<br />
In [[2.0.0-2|2.0.0-X]] TWL_FIRM, those commands were stubbed out.<br />
| ARM9 code execution<br />
| [[2.0.0-2|2.0.0-X]]<br />
| [[2.0.0-2|2.0.0-X]]<br />
| January 2018<br />
| Wiki: August 5, 2018<br />
| [[User:Riley|Riley]]<br />
|-<br />
| FIRM launch doesn't check target FIRM version<br />
| When executing a FIRM launch, Process9 doesn't validate that the target FIRM isn't an old version. This allows booting an exploitable FIRM from a newer FIRM, if you can get the exploitable FIRM installed. ([[11.0.0-33|11.0.0-X]] now prevents installing old versions of system titles, but this doesn't affect titles already installed.)<br />
<br />
This had a use after [[9.6.0-24|9.6.0-X]]: on a compromised 3DS running 9.2.0, you could install the 9.6.0 NATIVE_FIRM to FIRM0/FIRM1, but avoid putting it into the NATIVE_FIRM title. This would boot the 9.2.0 system software but with the 9.6.0 Process9 and Kernel11. With a user-mode exploit in a sufficiently-privileged application (e.g. mset), you could trigger a FIRM launch back to NATIVE_FIRM, which would load the 9.2.0 Process9 and Kernel11.<br />
<br />
9.6.0's keyslots 0x15 and 0x16 are unknown to 9.2.0, so 9.2.0 would not clear them. You then could do firmlaunchhax against 9.2.0 to get ARM9 access with keyslots 0x15 and 0x16 set to their proper 9.6.0 values, allowing decrypting 9.6.0's encrypted titles. Once the New3DS keystore was dumped, this became moot.<br />
| Decrypting 9.6.0 NCCH files without dumping New3DS keystore<br />
| None (but now moot)<br />
| [[9.6.0-24|9.6.0-X]]<br />
| March 2015<br />
| August 12, 2018<br />
| [[User:Yellows8|Yellows8]], [[User:Myria|Myria]]<br />
|-<br />
| FAT FS code null-deref<br />
| When FSFile:Read is used with a file which is corrupted on a FAT filesystem(in particular SD), Process9 can crash. This particular crash is caused by a function returning NULL instead of an actual ptr due to an error. The caller of that function doesn't check for NULL which then triggers a read based at NULL.<br />
<br />
Sample "fsck.vfat -n -v -V <fat image backup>" output for the above crash:<br />
<br />
<pre>...<br />
Starting check/repair pass.<br />
<FilePath0> and<br />
<FilePath1><br />
share clusters.<br />
Truncating second to 3375104 bytes.<br />
<FilePath1><br />
File size is 2787392 bytes, cluster chain length is 16384 bytes.<br />
Truncating file to 16384 bytes.<br />
Checking for unused clusters.<br />
Reclaimed 1 unused cluster (16384 bytes).<br />
Checking free cluster summary.<br />
Free cluster summary wrong (1404490 vs. really 1404491)<br />
Auto-correcting.<br />
Starting verification pass.<br />
Checking for unused clusters.<br />
Leaving filesystem unchanged.</pre><br />
| Useless null-based-read<br />
| None<br />
| [[9.6.0-24|9.6.0-X]]<br />
| July 8-9, 2015<br />
| <br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| RSA signature padding checks<br />
| The TWL_FIRM RSA sig padding check code used for all TWL RSA sig-checks has issues, see [[FIRM|here]].<br />
The main 3DS RSA padding check code(non-certificate, including NATIVE_FIRM) uses the function used with the above to extract more padding + the actual hash from the additional padding. This isn't really a problem here because there's proper padding check code which is executed prior to this.<br />
| <br />
| None<br />
| [[9.5.0-22|9.5.0-X]]<br />
| March 2015<br />
| <br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[AMPXI:ValidateDSiWareSectionMAC]] [[AES_Registers|AES]] keyslot reuse<br />
| When the input DSiWare section index is higher than <max number of DSiWare sections supported by this FIRM>, Process9 uses keyid 0x40 for calculating the AESMAC, which translates to keyslot 0x40. The result is that the keyslot is left at whatever was already selected before, since the AES selectkeyslot code will immediately return when keyslot is >=0x40. However, actually exploiting this is difficult: the calculated AESMAC is never returned, this command just compares the calculated AESMAC with the input AESMAC(result-code depends on whether the AESMACs match). It's unknown whether a timing attack would work with this.<br />
This is basically a different form of the pxips9 keyslot vuln, except with AESMAC etc.<br />
| See description.<br />
| None<br />
| [[11.3.0-36|11.3.0-X]]<br />
| March 15, 2015<br />
| December 29, 2015<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| pxips9 [[AES_Registers|AES]] keyslot reuse<br />
| This requires access to the [[Process_Services|ps:ps]]/pxi:ps9 services. One way to get access to this would be snshax on system-version <=10.1.0-X(see 32c3 3ds talk).<br />
When an invalid key-type value is passed to any of the PS commands, Process9 will try to select keyslot 0x40. That aesengine_setkeyslot() code will then immediately return due to the invalid keyslot value. Since that function doesn't return any errors, Process9 will just continue to do crypto with whatever AES keyslot was selected before the PS command was sent.<br />
| Reusing the previously used keyslot, for crypto with PS.<br />
| None<br />
| [[11.3.0-36|11.3.0-X]]<br />
| Roughly the same time(same day?) as firmlaunch-hax.<br />
| December 29, 2015<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| firmlaunch-hax: FIRM header ToCToU<br />
| This can't be exploited from ARM11 userland.<br />
During [[FIRM]] launch, the only FIRM header the ARM9 uses at all is stored in FCRAM, this is 0x200-bytes(the actual used FIRM RSA signature is read to the Process9 stack however). The ARM9 doesn't expect "anything" besides the ARM9 to access this data.<br />
With [[9.5.0-22]] the address of this FIRM header was changed from a FCRAM address, to ARM9-only address 0x01fffc00.<br />
| ARM9 code execution<br />
| [[9.5.0-22]]<br />
| <br />
| 2012, 3 days after [[User:Yellows8|Yellows8]] started Process9 code RE.<br />
| <br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| Uninitialized data output for (PXI) command replies<br />
| PXI commands for various services(including some [[Filesystem_services_PXI|here]] and many others) can write uninitialized data (like from ARM registers) to the command reply. This happens with stubbed commands, but this can also occur with certain commands when returning an error.<br />
Certain ARM11 service commands have this same issue as well.<br />
| <br />
| None<br />
| [[9.3.0-21|9.3.0-X]]<br />
| ?<br />
| <br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[Filesystem_services_PXI|FSPXI]] OpenArchive SD permissions<br />
| Process9 does not use the exheader ARM9 access-mount permission flag for SD at all.<br />
This would mean ARM11-kernelmode code / fs-module itself could directly use FSPXI to access SD card without ARM9 checking for SD access, but this is rather useless since a process is usually running with SD access(Home Menu for example) anyway.<br />
| <br />
| None<br />
| [[9.3.0-21|9.3.0-X]]<br />
| 2012<br />
| <br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[AMPXI:ExportDSiWare]] export path<br />
| Process9 allocates memory on Process9 heap for the export path then verifies that the actual allocated size matches the input size. Then Process9 copies the input path from FCRAM to this buffer, and uses it with the Process9 FS openfile code, which use paths in the form of "<mountpoint>:/<path>".<br />
Process9 does not check the contents of this path at all before passing it to the FS code, besides writing a NUL-terminator to the end of the buffer.<br />
| Exporting of DSiWare to arbitrary Process9 file-paths, such as "nand:/<path>" etc. This isn't really useful since the data which gets written can't be controlled.<br />
| None<br />
| [[9.5.0-22]]<br />
| April 2013<br />
| <br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[DSiWare_Exports]] [[CTCert]] verification<br />
| Just like DSi originally did, 3DS verifies the APCert for DSiWare on SD with the CTCert also in the DSiWare .bin. On DSi this was fixed with with system-version 1.4.2 by verifying with the actual console-unique cert instead(stored in NAND), while on 3DS it's still not(?) fixed.<br />
On 3DS however this is useless, unless one can obtain the console-unique movable.sed keyY which encrypts the entire DSiWare .bin.<br />
| When the movable.sed keyY for the target 3DS is known and the target 3DS CTCert private-key is unknown, importing of modified DSiWare SD .bin files.<br />
| None.<br />
| 11.6.0-X<br />
| April 2013<br />
| <br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| seedminer: movable.sed keyY vulnerable to brute-force<br />
| Half of the movable.sed keyY's 128 bits are leaked through the [[Nandrw/sys/LocalFriendCodeSeed_B|LFCS]], which is available in userland and below. The LFCS itself also leaks almost half of the remaining bits by following the ratio: u32 keyY[3]=1/5(LFCS). The remaining keyY[3] uncertainty of about ±2000 can be greatly reduced by plotting expected error margins with several keyYs. This results in a final uncertainty of about 2^40, easily within practical brute force range of an average modern PC.<br />
| Knowing the keyY of a given 3ds allows for modification of DSiWare export contents, and chained with several other public vulns, ultimately arm9 execution.<br />
| None.<br />
| 11.6.0-X<br />
| December 2017<br />
| January 2018<br />
| zoogie<br />
|-<br />
| Improper validation of DSiWare title SRLs<br />
| The 3DS does not verify if the actual SRL embedded in the title's directory matches the titleID in the TMD before launching it or importing it from an sd DSiWare export. <br />
| This allows embedding older, exploitable DSiWare titles in completely different, unexploitable DSiWare titles. Since DSiWare has raw NAND RW, this can result in arm9 control through FIRM known-plaintext and sighax attacks.<br />
| None.<br />
| 11.6.0-X<br />
| 2015?<br />
| December 2016<br />
| Everyone<br />
|-<br />
| [[Gamecard_Services_PXI]] unchecked REG_CTRCARDCNT transfer-size<br />
| The u8 REG_CTRCARDCNT transfer-size parameter for the [[Gamecard_Services_PXI]] read/write CTRCARD commands is used as an index for an array of u16 values. Before [[5.0.0-11|5.0.0-X]] this u8 value wasn't checked, thus out-of-bounds reads could be triggered(which is rather useless in this case).<br />
| Out-of-bounds read for a value which gets written to a register.<br />
| [[5.0.0-11|5.0.0-X]]<br />
| <br />
| 2013?<br />
| <br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[PXI_Registers|PXI]] cmdbuf buffer overrun<br />
| The Process9 code responsible [[PXI_Registers|PXI]] communications didn't verify the size of the incoming command before writing it to a C++ member variable. <br />
| Probably ARM9 code execution<br />
| [[5.0.0-11|5.0.0-11]]<br />
| <br />
| March 2015, original timeframe if any unknown<br />
| <br />
| [[User:Plutooo|plutoo]]/[[User:Yellows8|Yellows8]]/maybe others(?)<br />
|-<br />
| [[Application_Manager_Services_PXI|PXIAM]] command 0x003D0108(See also [[Application_Manager_Services|this]])<br />
| When handling this command, Process9 allocates a 0x2800-byte heap buffer, then copies the 4 FCRAM input buffers to this heap buffer without checking the sizes at all(only the buffers with non-zero sizes are copied). Starting with [[5.0.0-11|5.0.0-X]], the total combined size of the input data must be <=0x2800.<br />
| ARM9 code execution<br />
| [[5.0.0-11|5.0.0-X]]<br />
| <br />
| May 2013<br />
| <br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[Process_Services_PXI|PS RSA]] commands buffer overflows<br />
| pxips9 cmd1(not accessible via ps:ps) and VerifyRsaSha256: unchecked copy to a buffer in Process9's .bss, from the input FCRAM buffer. The buffer is located before the pxi cmdhandler threads' stacks. SignRsaSha256 also has a buf overflow, but this isn't exploitable.<br />
The buffer for this is the buffer for the signature data. With v5.0, the signature buffer was moved to stack, with a check for the signature data size. When the signature data size is too large, Process9 uses [[SVC|svcBreak]].<br />
| ARM9 code execution<br />
| [[5.0.0-11|5.0.0-X]]<br />
| <br />
| 2012<br />
| <br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[PXI_Registers|PXI]] pxi_id bad check<br />
| The Process9 code responsible for [[PXI_Registers|PXI]] communications read pxi_id as a signed char. There were two flaws:<br />
* They used it as index to a lookup-table without checking the value at all.<br />
* Another function verified that pxi_id < 7, allowing negative values to pass the check. This would also cause an out-of-range table-lookup.<br />
| Maybe ARM9 code execution<br />
| [[3.0.0-5|3.0.0-5]]<br />
|<br />
| March 2015, originally 2012 for the first issue at least<br />
| <br />
| [[User:Plutooo|plutoo]], [[User:Yellows8|Yellows8]], maybe others(?)<br />
|}<br />
<br />
=== Kernel9 ===<br />
{| class="wikitable" border="1"<br />
|-<br />
! Summary<br />
! Description<br />
! Successful exploitation result<br />
! Fixed in [[FIRM]] system version<br />
! Last [[FIRM]] system version this flaw was checked for<br />
! Timeframe this was discovered<br />
! Discovered by<br />
|-<br />
| [[CONFIG Registers#CFG_SYSPROT9|CFG_SYSPROT9]] bit1 not set by Kernel9<br />
| Old versions of Kernel9 never set bit1 of [[CONFIG Registers#CFG_SYSPROT9|CFG_SYSPROT9]]. This leaves the [[OTP Registers|0x10012000]]-region unprotected (this region should be locked early during boot!). Since it's never locked, you can dump it once you get ARM9 code execution.<br />
<br />
From [[3.0.0-5|3.0.0-X]] this was fixed by setting the bit in Kernel9 after poking some registers in that region. On New3DS arm9loader sets this bit instead of Kernel9, which is exploitable through a hardware + software vulnerability (see arm9loaderhax / description).<br />
<br />
This flaw resurged when it gained a new practical use: retrieving the OTP data for a New3DS console in order to decrypt the key data used in arm9loader (see enhanced-arm9loaderhax / description). This was performed by downgrading to a vulnerable system version. By accounting for differences in CTR-NAND crypto (0x05 -> 0x04, see partition encryption types [[Flash_Filesystem#NAND_structure|here]]) and using an Old3DS [[NCSD#NCSD_header|NCSD Header]], it is possible to boot a New3DS using Old3DS firmware 1.0-2.x to retrieve the required OTP data using this flaw.<br />
| Dumping the [[OTP Registers|OTP]] area.<br />
Decrypting New3DS sector 0x96 keyblock.<br />
| [[3.0.0-5|3.0.0-X]]<br />
|<br />
| February 2015<br />
| [[User:Plutooo|plutoo]], Normmatt independently<br />
|}<br />
<br />
== ARM11 software ==<br />
=== Kernel11 ===<br />
{| class="wikitable" border="1"<br />
|-<br />
! Summary<br />
! Description<br />
! Successful exploitation result<br />
! Fixed in [[FIRM]] system version<br />
! Last [[FIRM]] system version this flaw was checked for<br />
! Timeframe this was discovered<br />
! Discovered by<br />
|-<br />
| [[SVC|svcSetProcessIdealProcessor]] reference count overflow and therefore use-after-free.<br />
| The SVC receive two arguments: handle and idealprocessor. The handle is used to get the KProcess object and the KProcess->refCnt gets incremented,later the function check if the KProcess->mem_type != BASE and if yes, it checks for idealprocessor == 2 or idealprocessor != 3. The problem here is that if you pass the idealprocessor = 3 it won't meet any condition and return the error 0xD9001BEA without decrement the reference count. <br />
It can be abused to overflow the KProcess reference count that will lead to an Use-after-free. <br />
| Before [[11.2.0-35|11.2.0-X]]: reference count overflow and therefore use-after-free.<br />
| <br />
| [[11.6.0-39|11.6.0-X]]<br />
| November 2, 2017<br />
| [[User:st4rk|st4rk]]<br />
|-<br />
| [[SVC|svcGetThreadList]] process reference leak<br />
| When given a valid process handle (including <code>0xFFFF8001</code>), svcGetThreadList forgets to decrement the reference count of the underlying [[KProcess]] instance, after having finished using it.<br />
| Before [[11.2.0-35|11.2.0-X]]: reference count overflow and therefore use-after-free, but this UAF was most likely not exploitable<br />
| <br />
| [[11.3.0-36|11.3.0-X]]<br />
| April 3, 2017<br />
| [[User:TuxSH|TuxSH]]<br />
|-<br />
| kernelhax via gspwn<br />
| Originally the kernel didn't initialize [[CONFIG11_Registers#CFG11_GPUPROT|CFG11_GPUPROT]]. Since it's 0 at hard-boot, this allowed the GPU to access the entire FCRAM + AXIWRAM.<br />
| Entire FCRAM+AXIWRAM R/W.<br />
| [[3.0.0-5|3.0.0-X]]<br />
| <br />
| February 7, 2017<br />
| [[User:Plutooo|plutoo]], [[User:Yellows8|Yellows8]] partly<br />
|-<br />
| fasthax<br />
| When a KTimer is created in pulse mode, the kernel calls a virtual function to reset the timer each time it pulses. The scheduler is locked for that core to avoid race conditions, but another core can call CloseHandle on the timer and free it, leading to a UAF vtable call.<br />
| See description.<br />
| [[11.3.0-36|11.3.0-X]]<br />
| [[11.3.0-36|11.3.0-X]]<br />
| May 2016<br />
| nedwill<br />
|-<br />
| ipctakeover<br />
| When sending cmdreplies, it does not validate that the src_addr and src_size match the equivalent dst_addr and dst_size. With a modified addr/size specified in a cmdreply for an output buffer, the data-copy for the first/last pages could be used to overwrite data outside of the buffer specified by the original process.<br />
<br />
Used by ctr-httpwn as of v1.2, for "ipctakeover/bosshaxx".<br />
<br />
This can be used to takeover processes where the process is using your service session. Like HTTPC -> BOSS, for bosshaxx above. NIM takeover can be done too(actual stack buffer overflow can trigger), etc.<br />
| See description.<br />
| None<br />
| [[11.3.0-36|11.3.0-X]]<br />
| November 26, 2016<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| Using IPC input buffers as output buffers<br />
| When sending cmdreplies, it does not validate that the cmdreply descriptor type matches the equivalent cmdreq descriptor type. This could be used by an exploited sysmodule to use what was intended as an input-buffer as an output-buffer, and also combine other IPC vuln(s) with this.<br />
<br />
Used by ctr-httpwn as of v1.2, for "ipctakeover/bosshaxx".<br />
| See description.<br />
| None<br />
| [[11.3.0-36|11.3.0-X]]<br />
| November 2016<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[SVC]] table too small<br />
| The table of function pointers for SVC's only contains entries up to 0x7D, but the biggest allowed SVC for the table is 0x7F. Thus, executing SVC7E or SVC7F would make the SVC-handler read after the buffer, and interpret some ARM instructions as function pointers.<br />
<br />
However, this would require patching the kernel .text or modifying SVC-access-control. Even if you could get these to execute, they would still jump to memory that isn't mapped as executable.<br />
| <br />
| None<br />
| [[11.3.0-36|11.3.0-X]]<br />
| 2012<br />
| Everyone<br />
|-<br />
| [[SVC|svcBackdoor (0x7B)]]<br />
| This backdoor allows executing SVC-mode code at the user-specified code-address. This is used by Process9, using this on the ARM11 (with NATIVE_FIRM) required patching the kernel .text or modifying SVC-access-control.<br />
| See description<br />
| [[11.0.0-33|11.0.0-X]] (deleted)<br />
| <br />
|<br />
| Everyone<br />
|-<br />
| veryslowpidhax<br />
| '''This is completely different from the kernelmode-code-execution vuln described in the below separate entry.'''<br />
<br />
When updating the kernel global PID counter under [[SVC|svcCreateProcess]] the kernel does not check for wraparound to 0x0(the PID for the very first process). This only matters because [[Services|SM-module]] allows processes with PID value less than <total ARM11 FIRM modules> to access ''all'' services, without checking exheader service-access-control; and because Kernel11 checks for the PID to be 1 (loader) to use the input mem-region value on ControlMemory. This alone does not affect access the [[SVC|SVCs]] access table at all.<br />
<br />
Inlined ldrex+strex code is used for updating the above counter. [[11.2.0-35|11.2.0-X]] had changes for similar code, but it was only for dedicated ldrex+strex functions(mainly for kernel objects) and hence this PID code was not affected.<br />
<br />
With launching+terminating a sysmodule repeatedly with this via ns:s, it would take weeks to finish(if not at least about a month?).<br />
| Access to all [[Services_API|services]], ControlMemory on any given mem-region.<br />
| None<br />
| [[11.3.0-36|11.3.0-X]]<br />
| 2012 maybe?<br />
| <br />
|-<br />
| slowhax/waithax<br />
| svcWaitSynchronizationN does not decrement the references to valid handles in an array before returning an error when it encounters an invalid handle. This allows one to (slowly) overflow the reference count for a handle object to zero.<br />
| ARM11 kernel-mode code execution<br />
| [[11.2.0-35|11.2.0-X]]<br />
| [[11.2.0-35|11.2.0-X]]<br />
| 2016<br />
| nedwill, [[User:Derrek|derrek]]<br />
|-<br />
| [[Memory_layout#ARM11_Detailed_virtual_memory_map|0xEFF00000]] / 0xDFF00000 ARM11 kernel virtual-memory<br />
| The ARM11 kernel-mode 0xEFF00000/0xDFF00000 virtual-memory(size 0x100000) is mapped to phys-mem 0x1FF00000(entire DSP-mem + entire AXIWRAM), with permissions RW-. This is used during ARM11 kernel startup for loading the FIRM-modules from the FIRM section located in DSP-mem, this never seems to be used after that, however. This is never unmapped either.<br />
| <br />
| None<br />
| [[11.3.0-36|11.3.0-X]]<br />
| <br />
| <br />
|-<br />
| memchunkhax2.1<br />
| Nintendo's fix for memchunkhax2 in [[10.4.0-29|10.4.0-X]] did not fix the GPU case: one may cause the requisite ToCToU race using gspwn, bypassing the new validation.<br />
derrek's original 32c3 presentation for memchunkhax2 commented that a GPU-based attack was possible, but would be difficult. However, memchunkhax2.1 showed that it was possible to do fairly reliably.<br />
| ARM11 kernel code execution<br />
| [[11.0.0-33|11.0.0-X]], via the new [[Memory_Management#MemoryBlockHeader|memchunkhdr]] MAC which prevents modifying memchunkhdr data with DMA.<br />
| [[11.0.0-33|11.0.0-X]]<br />
|<br />
| [[User:Derrek|derrek]], aliaspider<br />
|-<br />
| memchunkhax2<br />
| When allocating a block of memory, the "next" pointer of the [[Memory_Management#MemoryBlockHeader|memchunkhdr]] is accessed without being checked after being mapped to userland.<br />
This allows a race condition, where the process can change the next pointer just before it's accessed. By pointing the next pointer to a crafted memchunckhdr in the kernel SlabHeap, some of the SlabHeap is allocated to the calling process, allowing to change vtables of kernel objects. <br />
| ARM11 kernel code execution<br />
| [[10.4.0-29|10.4.0-X]] (partially, see memchunkhax2.1)<br />
| [[10.4.0-29|10.4.0-X]]<br />
|<br />
| [[User:Derrek|derrek]]<br />
|-<br />
| heaphax<br />
| Can change the size of free memchunk structures stored in FCRAM using DMA, which leads to the ability to allocate memory chunks over already-allocated memory. This can be used in the SYSTEM region to allocate RW memory over any part of the NS system module, which is enough to take it over.<br />
| Code execution with access to all of NS's privileges. (including downgrading) Code execution within any applet.<br />
| [[11.0.0-33|11.0.0-X]], via the new [[Memory_Management#MemoryBlockHeader|memchunkhdr]] MAC which prevents modifying memchunkhdr data with DMA.<br />
| [[11.0.0-33|11.0.0-X]]<br />
| April 2015 ?<br />
| smea<br />
|-<br />
| snshax<br />
| Can force creation of Safe NS process into gspwn-able memory, allowing for takeover.<br />
| Code execution with access to all of NS's privileges. (including downgrading)<br />
| [[10.1.0-27|10.1.0-X]]<br />
| [[10.1.0-27|10.1.0-X]]<br />
| April 2015 ?<br />
| smea<br />
|-<br />
| AffinityMask/processorid validation<br />
| With [[10.0.0-27|10.0.0-X]] the following functions were updated: svcGetThreadAffinityMask, svcGetProcessAffinityMask, svcSetProcessAffinityMask, and svcCreateThread. The code changes for all but svcCreateThread are identical.<br />
The original code with the first 3 did the following: <br />
* if(u32_processorcount > ~0x80000001)return 0xe0e01bfd;<br />
* if(s32_processorcount > <total_cores>)return 0xd8e007fd;<br />
The following code replaced the above:<br />
* if(u32_processorcount >= <total_cores+1>)return 0xd8e007fd;<br />
In theory the latter should catch everything that the former did, so it's unknown if this was really a security issue.<br />
<br />
The svcCreateThread changes with [[10.0.0-27|10.0.0-X]] definitely did fix a security issue.<br />
* Original code: "if(s32_processorid > <total_cores>)return 0xd8e007fd;"<br />
* New code: "if(s32_processorid >= <total_cores> || s32_processorid <= -4)return 0xd8e007fd;"<br />
This fixed an off-by-one issue: if one would use processorid=total_cores, which isn't actually a valid value, svcCreateThread would accept that value on <[[10.0.0-27|10.0.0-X]]. This results in data being written out-of-bounds(baseaddr = arrayaddr + entrysize*processorid), which has the following result:<br />
* Old3DS: Useless kernel-mode crash due to accessing unmapped memory.<br />
* New3DS: uncontrolled data write into a kernel-mode L1 MMU-table. This isn't really useful: the data can't be controlled, and the data which gets overwritten is all-zero anyway(this isn't anywhere near MMU L1 entries for actually mapped memory).<br />
The previous version also allowed large negative s32_processorid values(negative processorid values are special values not actual procids), but it appears using values like that won't actually do anything(meaning no crash) besides the thread not running / thread not running for a while(besides triggering a kernelpanic with certain s32_processorid value(s)).<br />
| Nothing useful<br />
| [[10.0.0-27|10.0.0-X]]<br />
| [[10.0.0-27|10.0.0-X]]<br />
| svcCreateThread issue: May 31, 2015. The rest: September 8, 2015, via v9.6->v10.0 ARM11-kernel code-diff.<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| memchunkhax<br />
| The kernel originally did not validate the data stored in the FCRAM kernel heap [[Memchunkhdr|memchunk-headers]] for free-memory at all. Exploiting this requires raw R/W access to these memchunk-headers, like physical-memory access with gspwn.<br />
<br />
There are ''multiple'' ways to exploit this, but the end-result for most of these is the same: overwrite code in AXIWRAM via the 0xEFF00000/0xDFF00000 kernel virtual-memory mapping.<br />
<br />
This was fixed in [[9.3.0-21|9.3.0-X]] by checking that the memchunk(including size, next, and prev ptrs) is located within the currently used heap memory. The kernel may also check that the next/prev ptrs are valid compared to other memchunk-headers basically. When any of these checks fail, kernelpanic() is called.<br />
| When combined with other flaws: ARM11-kernelmode code execution<br />
| [[9.3.0-21|9.3.0-21]]<br />
| <br />
| February 2014<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| Multiple [[KLinkedListNode|KLinkedListNode]] SlabHeap use after free bugs<br />
| The ARM11-kernel did access the 'key' field of [[KLinkedListNode|KLinkedListNode]] objects, which are located on the SlabHeap, after freeing them. Thus, triggering an allocation of a new [[KLinkedListNode|KLinkedListNode]] object at the right time could result in a type-confusion. Pseudo-code:<br />
SlabHeap_free(KLinkedListNode);<br />
KObject *obj = KLinkedListNode->key; // the object there might have changed!<br />
This bug appeared all over the place.<br />
| ARM11-kernelmode code exec maybe<br />
| [[8.0.0-18|8.0.0-18]]<br />
| <br />
| April 2015<br />
| [[User:Derrek|derrek]]<br />
|-<br />
| PXI [[RPC_Command_Structure|Command]] input/output buffer permissions<br />
| Originally the ARM11-kernel didn't check permissions for PXI input/output buffers for commands. Starting with [[6.0.0-11|6.0.0]] PXI input/output buffers must have RW permissions, otherwise kernelpanic is triggered.<br />
| <br />
| [[6.0.0-11|6.0.0-11]]<br />
| <br />
| 2012<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[SVC|svcStartInterProcessDma]]<br />
| For svcStartInterProcessDma, the kernel code had the following flaws:<br />
<br />
* Originally the ARM11-kernel read the input DmaConfig structure directly in kernel-mode(ldr(b/h) instructions), without checking whether the DmaConfig address is readable under userland. This was fixed by copying that structure to the SVC-mode stack, using the ldrbt instruction.<br />
<br />
* Integer overflows for srcaddr+size and dstaddr+size are now checked(with [[6.0.0-11]]), which were not checked before.<br />
<br />
* The kernel now also checks whether the srcaddr/dstaddr (+size) is within userland memory (0x20000000), the kernel now (with [[6.0.0-11]]) returns an error when the address is beyond userland memory. Using an address >=0x20000000 would result in the kernel reading from the process L1 MMU table, beyond the memory allocated for that MMU table(for vaddr->physaddr conversion). <br />
| <br />
| [[6.0.0-11]]<br />
| <br />
| DmaConfig issue: unknown. The rest: 2014<br />
| [[User:Plutooo|plutoo]], [[User:Yellows8|Yellows8]] independently<br />
|-<br />
| [[SVC|svcControlMemory]] Parameter checks<br />
| For svcControlMemory the parameter check had these two flaws:<br />
<br />
* The allowed range for addr0, addr1, size parameters depends on which MemoryOperation is being specified. The limitation for GSP heap was only checked if op=(u32)0x10003. By setting a random bit in op that has no meaning (like bit17?), op would instead be (u32)0x30003, and the range-check would be less strict and not accurate. However, the kernel doesn't actually use the input address for LINEAR memory-mapping at all besides the range-checks, so this isn't actually useful. This was fixed in the kernel by just checking for the LINEAR bit, instead of comparing the entire MemoryOperation value with 0x10003.<br />
<br />
* Integer overflows on (addr0+size) are now checked that previously weren't (this also applies to most other address checks elsewhere in the kernel).<br />
<br />
| <br />
| [[5.0.0-11]]<br />
| <br />
|<br />
| [[User:Plutooo|plutoo]]<br />
|-<br />
| [[RPC_Command_Structure|Command]] request/response buffer overflow<br />
| Originally the kernel did not check the word-values from the command-header. Starting with [[5.0.0-11]], the kernel will trigger a kernelpanic() when the total word-size of the entire command(including the cmd-header) is larger than 0x40-words (0x100-bytes). This allows overwriting threadlocalstorage+0x180 in the destination thread. However, since the data written there would be translate parameters (such as header-words + buffer addresses), exploiting this would likely be very difficult, if possible at all.<br />
<br />
If the two words at threadlocalstorage+0x180 could be overwritten with controlled data this way, one could then use a command with a buffer-header of <nowiki>((size<<14) | 2)</nowiki> to write arbitrary memory to any RW userland memory in the destination process.<br />
| <br />
| [[5.0.0-11]]<br />
| <br />
| v4.1 FIRM -> v5.0 code diff<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[SVC|SVC stack allocation overflows]]<br />
| <br />
* Syscalls that allocate a variable-length array on stack, only checked bit31 before multiplying by 4/16 (when calculating how much memory to allocate). If a large integer was passed as input to one of these syscalls, an integer overflow would occur, and too little memory would have been allocated on stack resulting in a buffer overrun. <br />
* The alignment (size+7)&~7 calculation before allocation was not checked for integer overflow.<br />
<br />
This might allow for ARM11 kernel code-execution.<br />
<br />
(Applies to svcSetResourceLimitValues, svcGetThreadList, svcGetProcessList, svcReplyAndReceive, svcWaitSynchronizationN.)<br />
| <br />
| [[5.0.0-11]]<br />
| <br />
| v4.1 FIRM -> v5.0 code diff<br />
| [[User:Plutooo|plutoo]], [[User:Yellows8|Yellows8]] complementary<br />
|-<br />
| [[SVC|svcControlMemory]] MemoryOperation MAP memory-permissions<br />
| svcControlMemory with MemoryOperation=MAP allows mapping the already-mapped process virtual-mem at addr1, to addr0. The lowest address permitted for addr1 is 0x00100000. Originally the ARM11 kernel didn't check memory permissions for addr1. Therefore .text as addr1 could be mapped elsewhere as RW- memory, which allowed ARM11 userland code-execution.<br />
| <br />
| [[4.1.0-8]]<br />
| <br />
| 2012<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[RPC_Command_Structure|Command]] input/output buffer permissions<br />
| Originally the ARM11 kernel didn't check memory permissions for the input/output buffers for commands. Starting with [[4.0.0-7]] the ARM11 kernel will trigger a kernelpanic() if the input/output buffers don't have the required memory permissions. For example, this allowed a FSUSER file-read to .text, which therefore allowed ARM11-userland code execution.<br />
| <br />
| [[4.0.0-7]]<br />
| <br />
| 2012<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[SVC|svcReadProcessMemory/svcWriteProcessMemory memory]] permissions<br />
| Originally the kernel only checked the first page(0x1000-bytes) of the src/dst buffers, for svcReadProcessMemory and svcWriteProcessMemory. There is no known retail processes which have access to these SVCs.<br />
| <br />
| [[4.0.0-7]]<br />
| <br />
| 2012?<br />
| [[User:Yellows8|Yellows8]]<br />
|}<br />
<br />
=== [[FIRM]] Sysmodules ===<br />
{| class="wikitable" border="1"<br />
|-<br />
! Summary<br />
! Description<br />
! Successful exploitation result<br />
! Fixed in [[FIRM]] system version<br />
! Last [[FIRM]] system version this flaw was checked for<br />
! Timeframe this was discovered<br />
! Discovered by<br />
|-<br />
| [[Services|"srv:pm"]] process registration<br />
| Originally any process had access to the port "srv:pm". The PID's used for the (un)registration commands are not checked either. This allowed any process to re-register itself with "srv:pm", and therefore allowed the process to give itself access to any service, bypassing the exheader service-access-control list.<br />
<br />
This was fixed in [[7.0.0-13]]: starting with [[7.0.0-13]] "srv:pm" is now a service instead of a globally accessible port. Only processes with PID's less than 6 (in other words: fs, ldr, sm, pm, pxi modules) have access to it. With [[7.0.0-13]] there can only be one session for "srv:pm" open at a time(this is used by pm module), svcBreak will be executed if more sessions are opened by the processes which can access this.<br />
<br />
This flaw was needed for exploiting the <=v4.x Process9 PXI vulnerabilities from ARM11 userland ROP, since most applications don't have access to those service(s).<br />
| Access to arbitrary services<br />
| [[7.0.0-13]]<br />
| <br />
| 2012<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| FSDIR null-deref<br />
| [[Filesystem_services|FS]]-module may crash in some cases when handling directory reading. The trigger seems to be due to using [[FSDir:Close]] without closing the dir-handle afterwards?(Perhaps this is caused by out-of-memory?) This seems to be useless since it's just a null-deref.<br />
| <br />
| None<br />
| [[9.6.0-24|9.6.0-X]]<br />
| May 19(?)-20, 2015<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[SM]] out-of-bounds BSS write (table 1 entry too small)<br />
| After accepting a new session, [[SM]] writes a (handler ID (0 for srv: sessions (max. 64), 1 for the srv:pm one), pointer to session context structure in BSS) pair in a global array. However that array is only 64-entry-big instead of 65 (as it ought to be), and no bound check is done in that regard.<br />
<br />
Unfortunately, as of [[11.4.0-37]], the overwritten fields are totally unused after their initialization by <code>__libc_init_array</code>.<br />
| Not currently exploitable<br />
| None<br />
| [[11.4.0-37]]<br />
|<br />
|<br />
|}<br />
<br />
=== Standalone Sysmodules ===<br />
{| class="wikitable" border="1"<br />
|-<br />
! Summary<br />
! Description<br />
! Successful exploitation result<br />
! Fixed in system-module system-version<br />
! Last system-module system-version this flaw was checked for<br />
! Timeframe this was discovered<br />
! Timeframe this was added to wiki<br />
! Discovered by<br />
|-<br />
| [[MP:SendDataFrame]] missing input array index validation<br />
| [[MP:SendDataFrame]] doesn't validate the input index at cmdreq[1], unless the function for flag=non-zero is executed. This is used to calculate the following, without validating the index at all: someptr = stateptr + (index*0x924) + somestateoffset.<br />
<br />
After validating some flags from someptr, when input_flag=0 the input buffer data is copied to someptr+someotheroffset+0x14 with the u16 size loaded from someptr+someotheroffset.<br />
<br />
With a large input index someptr could be setup to be at a <target address>, for overwriting memory.<br />
<br />
This is probably difficult to exploit.<br />
| <br />
| None<br />
| [[8.0.0-18]](MP-sysmodule v2048)<br />
| January 22, 2017<br />
| January 22, 2017<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[MP_Services|MP]] cmd1 out-of-bounds handle read<br />
| MP-sysmodule handles the input parameter for cmd1 as a s32. It checks for >=16, but not <0. With <16 it basically does the following(array of entries 4-bytes each): *outhandle = ((Handle*)(stateptr+offsetinstate))[inputindex].<br />
<br />
Hence, this can be used to load any handle in MP-sysmodule memory. MP doesn't really have any service handles of interest however(can be obtained from elsewhere too).<br />
| Reading any handle in MP-sysmodule memory.<br />
| None<br />
| [[8.0.0-18]](MP-sysmodule v2048)<br />
| January 21, 2017<br />
| January 22, 2017<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| AM stack/.bss infoleak via [[AM:ReadTwlBackupInfo]]([[AM:ReadTwlBackupInfoEx|Ex]])<br />
| After writing the output-info structure to stack, it then copies that structure to the output buffer ptr using the size from the command. The size is not checked. This could be used to read data from the AM-service-thread stack handling the command + .bss.<br />
<br />
'''This was not tested on hardware.'''<br />
| Stack/.bss reading<br />
| None<br />
| [[10.0.0-27]](AM v9217)<br />
| Roughly October 17, 2016<br />
| October 25, 2016<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[MVD_Services|MVD]]: Stack buffer overflow with [[MVDSTD:SetupOutputBuffers]].<br />
| The input total_entries is not validated when initially processing the input entry-list. This fixed-size input entry-list is copied to stack from the command request. The loop for processing this initializes a global table, the converted linearmem->physaddrs used there are also copied to stack(0x8-bytes of physaddrs per entry).<br />
<br />
If total_entries is too large, MVD-sysmodule will crash due to reading unmapped memory following the stack(0x10000000). Afterwards if the out-of-bounds total_entries is smaller than that, it will crash due accessing address 0x0, hence this useless.<br />
| MVD-sysmodule crash.<br />
| None<br />
| [[9.0.0-20]]<br />
| April 22, 2016 (Tested on the 25th)<br />
| April 25, 2016<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[NWM_Services|NWM]]: Using CTRSDK heap with UDS sharedmem from the user-process.<br />
| See the HTTP-sysmodule section below.<br />
<br />
CTRSDK heap is used with the sharedmem from [[NWMUDS:InitializeWithVersion]]. Buffers are allocated/freed under this heap using [[NWMUDS:Bind]] and [[NWMUDS:Unbind]].<br />
<br />
Hence, overwriting sharedmem with gspwn then using [[NWMUDS:Unbind]] results in the usual controlled CTRSDK memchunk-header write, similar to HTTP-sysmodule.<br />
<br />
This could be done by creating an UDS network, without any other nodes on the network.<br />
<br />
Besides CTRSDK memchunk-headers, there are no addresses stored under this sharedmem.<br />
| ROP under NWM-module.<br />
| [[11.4.0-37|11.4.0-X]]<br />
| [[9.0.0-20|9.0.0-X]]<br />
| April 10, 2016<br />
| April 16, 2016<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[DLP_Services|DLP]]: Out-of-bounds memory access during spectator [[Download_Play|data-frame]] checksum calculation<br />
| DLP doesn't validate the frame_size when receiving spectator data-frames at all, unlike non-spectator data-frames. The actual spectator data-frame parsing code doesn't use that field either. However, the data-frame checksum calculation code called during checksum verification does use the frame_size for loading the size of the framebuf.<br />
<br />
Hence, using a large frame_size like 0xFFFF will result in the checksum calculation code reading data out-of-bounds. This isn't really useful, you could trigger a remote local-WLAN DLP-sysmodule crash while a 3DS system is scanning for DLP networks(due to accessing unmapped memory), but that's about all(trying to infoleak with this likely isn't useful either).<br />
| DLP-sysmodule crash, handled by dlplay system-application by a "connection interrupted" error eventually then a fatal-error via ErrDisp.<br />
| None<br />
| [[10.0.0-27|10.0.0-X]]<br />
| April 8, 2016 (Tested on the 10th)<br />
| April 10, 2016<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[DLP_Services|DLP]]: Out-of-bounds output data writing during spectator sysupdate titlelist [[Download_Play|data-frame]] handling<br />
| The total_entries and out_entryindex fields for the titlelist DLP spectator data-frames are not validated. This is parsed during DLP network scanning. Hence, the specified titlelist data can be written out-of-bounds using the specified out_entryindex and total_entries. A crash will occur while reading the input data-frame titlelist if total_entries is larger than 0x27A, due to accessing unmapped memory.<br />
<br />
There's not much non-zero data to overwrite following the output buffer(located in sharedmem), any ptrs are located in sharedmem. Overwriting certain ptr(s) are only known to cause a crash when attempting to use the DLP-client shutdown service-command.<br />
<br />
There's no known way to exploit the above crash, since the linked-list code involves writes zeros(with a controlled start ptr).<br />
| <br />
| None<br />
| [[10.0.0-27|10.0.0-X]]<br />
| April 8-9, 2016<br />
| April 10, 2016<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[IR_Services|IR]]: Stack buffer overflow with custom hardware<br />
| Originally IR sysmodule used the read value from the I2C-IR registers TXLVL and RXLVL without validating them at all. See [[10.6.0-31|here]] for the fix. This is the size used for reading the data-recv FIFO, etc. The output buffer for reading is located on the stack.<br />
<br />
This should be exploitable if one could successfully setup the custom hardware for this and if the entire intended sizes actually get read from I2C.<br />
| ROP under IR sysmodule.<br />
| [[10.6.0-31|10.6.0-31]]<br />
| <br />
| February 23, 2016 (Unknown if it was noticed before then)<br />
| February 23, 2016<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[HTTP_Services|HTTP]]: Using CTRSDK heap with sharedmem from the user-process.<br />
| The data from httpcAddPostDataAscii and other commands is stored under a CTRSDK heap. That heap is the sharedmem specified by the user-process via the HTTPC Initialize command.<br />
Normally this sharedmem isn't accessible to the user-process once the sysmodule maps it, hence using it is supposed to be "safe".<br />
<br />
This isn't the case due to gspwn however. Since CTRSDK heap code is so insecure in general, one can use gspwn to locate the HTTPC sharedmem + read/write it, then trigger a mem-write under the sysmodule. This can then be used to get ROP going under HTTP-sysmodule.<br />
<br />
This is exploited by [https://github.com/yellows8/ctr-httpwn/ctr-httpwn ctr-httpwn].<br />
| ROP under HTTP sysmdule.<br />
| [[11.4.0-37|11.4.0-X]]<br />
| [[9.6.0-24|9.6.0-X]] (Latest sysmodule version as of [[10.7.0-32|10.7.0-32]])<br />
| Late 2015<br />
| March 22, 2016<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[NIM_Services|NIM]]: Downloading old title-versions from eShop<br />
| Multiple NIM service commands(such as [[NIMS:StartDownload]]) use a title-version value specified by the user-process, NIM does not validate that this input version matches the latest version available via SOAP. Therefore, when combined with AM(PXI) [[#Process9|title-downgrading]] via deleting the target eShop title with System Settings Data Management(if the title was already installed), this allows downloading+installing any title-version from eShop ''if'' it's still available from CDN.<br />
The easiest way to exploit this is to just patch the eShop system-application code using these NIM commands(ideally the code which loads the title-version).<br />
<br />
Originally this was tested with a debugging-system via modded-FIRM, eventually smea implemented it in HANS for the 32c3 release.<br />
| Downloading old title-versions from eShop<br />
| None<br />
| [[10.0.0-27|10.0.0-X]]<br />
| October 24, 2015 (Unknown when exactly the first eShop title downgrade was actually tested, maybe November)<br />
| January 7, 2016 (Same day Ironfall v1.0 was removed from CDN via the main-CXI files)<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[SPI_Services|SPI]] service out-of-bounds write<br />
| cmd1 has out-of-bounds write allowing overwrite of some static variables in .data.<br />
| <br />
| None<br />
| [[9.5.0-22]]<br />
| March 2015<br />
| <br />
| [[User:Plutooo|plutoo]]<br />
|-<br />
| [[NFC_Services|NFC]] module service command buf-overflows<br />
| NFC module copies data with certain commands, from command input buffers to stack without checking the size. These commands include the following, it's unknown if there's more commands with similar issues: "nfc:dev" <0x000C....> and "nfc:s" <0x0037....>.<br />
Since both of these commands are stubbed in the Old3DS NFC module from the very first version(those just return an error), these issues only affect the New3DS NFC module.<br />
<br />
There's no known retail titles which have access to either of these services.<br />
| ROP under NFC module.<br />
| New3DS: None<br />
| New3DS: [[9.5.0-22]]<br />
| December 2014?<br />
| <br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[News_Services|NEWSS]] service command notificationID validation failure<br />
| This module does not validate the input notificationID for <nowiki>"news:s"</nowiki> service commands. This is an out-of-bounds array index bug. For example, [[NEWSS:SetNotificationHeader]] could be used to exploit news module: this copies the input data(size is properly checked) to: out = newsdb_savedata+0x10 + (someu32array[notificationID]*0x70).<br />
| ROP under news module.<br />
| None<br />
| [[9.7.0-25|9.7.0-X]]<br />
| December 2014<br />
| <br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[NWMUDS:DecryptBeaconData]] heap buffer overflow<br />
| input_size = 0x1E * <value the u8 from input_[[NWM_Services|networkstruct]]+0x1D>. Then input_tag0 is copied to a heap buffer. When input_size is larger than 0xFA-bytes, it will then copy input_tag1 to <end_address_of_previous_outbuf>, with size=input_size-0xFA.<br />
<br />
This can be triggered by either using this command directly, or by boadcasting a wifi beacon which triggers it while a 3DS system running the target process is in range, when the process is scanning for hosts to connect to. Processes will only pass tag data to this command when the wlancommID and other thing(s) match the values for the process.<br />
<br />
There's no known way to actually exploit this for getting ROP under NWM-module, at the time of originally adding this to the wiki. This is because the data which gets copied out-of-bounds *and* actually causes crash(es), can't be controlled it seems(with just broadcasting a beacon at least). It's unknown whether this could be exploited from just using NWMUDS service-cmd(s) directly.<br />
| Without any actual way to exploit this: NWM-module DoS, resulting in process termination(process crash). This breaks *everything* involving wifi comms, a reboot is required to recover from this.<br />
| None<br />
| [[9.0.0-20]]<br />
| ~September 23, 2014(see the [[NWMUDS:DecryptBeaconData]] page history)<br />
| August 3, 2015<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[HID_Services|HID]] module shared-mem<br />
| HID module does not validate the index values in [[HID_Shared_Memory|sharedmem]](just changes index to 0 when index == maxval when updating), therefore large values will result in HID module writing HID data to arbitrary addresses.<br />
| ROP under HID module, but this is *very* unlikely to be exploitable since the data written is HID data.<br />
| None<br />
| [[9.3.0-21]]<br />
| 2014?<br />
| <br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| gspwn<br />
| GSP module does not validate addresses given to the GPU. This allows a user-mode application/applet to read/write to a large part of physical FCRAM using GPU DMA. From this, you can overwrite the .text segment of the application you're running under, and gain real code-execution from a ROP-chain. Normally applets' .text([[Home Menu]], [[Internet Browser]], etc) is located beyond the area accessible by the GPU, except for [[RO_Services|CROs]] used by applets([[Internet Browser]] for example).<br />
<br />
FCRAM is gpu-accessible up to physaddr 0x26800000 on Old3DS, and 0x2D800000 on New3DS. This is BASE_memregion_start(aka SYSTEM_memregion_end)-0x400000 (0x800000 with New3DS) with the default memory-layout on Old3DS/New3DS. With [[11.3.0-36|11.3.0-X]] the cutoff now varies due to the new [[SVC]] 0x59. The New3DS "normal"(non-APPLICATION) cutoff was changed to 0x2D000000 due to the new [[SVC]] 0x59.<br />
| User-mode code execution.<br />
| None<br />
| [[9.6.0-24|9.6.0-X]]<br />
| Early 2014<br />
| <br />
| smea, [[User:Yellows8|Yellows8]]/others before then<br />
|-<br />
| rohax<br />
| Using gspwn, it is possible to overwrite a loaded [[CRO0]]/[[CRR0]] after its RSA-signature has been validated. Badly validated [[CRO0]] header leads to arbitrary read/write of memory in the ro-process. This gives code-execution in the ro module, who has access to [[SVC|syscalls]] 0x70-0x72, 0x7D.<br />
<br />
This was fixed after [[ninjhax]] release by adding checks on [[CRO0]]-based pointers before writing to them.<br />
| Memory-mapping syscalls.<br />
| [[9.3.0-21]]<br />
| [[9.4.0-21]]<br />
| <br />
| <br />
| smea, [[User:Plutooo|plutoo]] joint effort<br />
|-<br />
| Region free<br />
| Only [[Home Menu]] itself checks gamecards' region when launching them. Therefore, any application launch that is done directly with [[NS]] without signaling Home Menu to launch the app, will result in region checks being bypassed.<br />
This essentially means launching the gamecard with the [[NS_and_APT_Services|"ns:s"]] service. The main way to exploit this is to trigger a FIRM launch with an application specified, either with a normal FIRM launch or a hardware [[NSS:RebootSystem|reboot]].<br />
| Launching gamecards from any region + bypassing Home Menu gamecard-sysupdate installation<br />
| None<br />
| Last tested with [[10.1.0-27|10.1.0-X]].<br />
| June(?) 2014<br />
| <br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[NWM_Services|NWM]] service-cmd state null-ptr deref<br />
| The NWMUDS service command code loads a ptr from .data, adds an offset to that, then passes that as the state address for the actual command-handler function. The value of the ptr loaded from .data is not checked, therefore this will cause crashes due to that being 0x0 when NWMUDS was not properly initialized.<br />
It's unknown whether any NWM services besides NWMUDS have this issue.<br />
| This is rather useless since it's only a crash caused by a state ptr based at 0x0.<br />
| None<br />
| [[9.0.0-20]]<br />
| 2013?<br />
| <br />
| [[User:Yellows8|Yellows8]]<br />
|}<br />
<br />
=== General/CTRSDK ===<br />
{| class="wikitable" border="1"<br />
|-<br />
! Summary<br />
! Description<br />
! Successful exploitation result<br />
! Fixed in version<br />
! Last version this flaw was checked for<br />
! Timeframe this was discovered<br />
! Discovered by<br />
|-<br />
| [[NWM_Services|UDS]] beacon additional-data buffer overflow<br />
| Originally CTRSDK did not validate the UDS additional-data size before using that size to copy the additional-data to a [[NWM_Services|networkstruct]]. This was eventually fixed.<br />
This was discovered while doing code RE with an old dlp-module version. It's unknown in what specific CTRSDK version this was fixed, or even what system-version updated titles with a fixed version.<br />
<br />
It's unknown if there's any titles using a vulnerable CTRSDK version which are also exploitable with this(dlp module can't be exploited with this).<br />
<br />
The maximum number of bytes that can be written beyond the end of the outbuf is 0x37-bytes, with additionaldata_size=0xFF.<br />
| Perhaps ROP, very difficult if possible with anything at all<br />
| ?<br />
| <br />
| September(?) 2014<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| CTPK buffer overflow<br />
| At offset 0x20 in CTPK is an array for each texture, each entry is 0x20-bytes. This contains a wordindex(entry+0x18) for some srcdata relative to CTPK+0, and an u8 wordsize(entry+0x14) for this data. The CTRSDK function handling this doesn't validate the size, when copying srcdata using this size to the output buffer. Applications usually have the output buffer on the stack, hence stack buffer overflow.<br />
<br />
While CTPK(*.ctpk) are normally only loaded from RomFS, some application(s) load from elsewhere too.<br />
| ROP under the target application.<br />
| None?<br />
| "[SDK+NINTENDO:CTR_SDK-11_4_0_200_none]"<br />
| November 14, 2016<br />
| [[User:Yellows8|Yellows8]]<br />
|}</div>Myriahttps://www.3dbrew.org/w/index.php?title=3DS_System_Flaws&diff=208113DS System Flaws2018-08-12T05:48:03Z<p>Myria: /* arm9loader */ arm9loader runs on Old3DS</p>
<hr />
<div>Exploits are used to execute unofficial code (homebrew) on the Nintendo 3DS. This page is a list of publicly known system flaws, for userland applications/applets flaws see [[3DS_Userland_Flaws|here]].<br />
<br />
=Stale / Rejected Efforts=<br />
* Neimod has been working on a RAM dumping setup for a little while now. He's de-soldered the 3DS's RAM chip and hooked it and the RAM pinouts on the 3DS' PCB up to a custom RAM dumping setup. A while ago he published photos showing his setup to be working quite well, with the 3DS successfully booting up. However, his flickr stream is now private along with most of his work.<br />
<br />
* Someone (who will remain unnamed) has released CFW and CIA installers, all of which is copied from the work of others, or copyrighted material.<br />
<br />
==Tips and info==<br />
The 3DS uses the XN feature of the ARM11 processor. There's no official way from applications to enable executable permission for memory containing arbitrary unsigned code(there's a [[SVC]] for this, but only [[RO_Services|RO-module]] has access to it). A usable userland exploit would still be useful: you could only do return-oriented-programming with it initially. From ROP one could then exploit system flaw(s), see below.<br />
<br />
SD card [[extdata]] and SD savegames can be attacked, for consoles where the console-unique [[Nand/private/movable.sed|movable.sed]] was dumped(accessing SD data is far easier by running code on the target 3DS however).<br />
<br />
=System flaws=<br />
== Hardware ==<br />
{| class="wikitable" border="1"<br />
! Summary<br />
! Description<br />
! Fixed with hardware model/revision<br />
! Newest hardware model/revision this flaw was checked for<br />
! Timeframe this was discovered<br />
! Discovered by<br />
|-<br />
| ARM9/ARM11 bootrom vectors point at uninitialized RAM<br />
| ARM9's and ARM11's exception vectors are hardcoded to point at the CPU's internal memory (0x08000000 region for ARM9, AXIWRAM for ARM11). While the bootrom does set them up to point to an endless loop at some point during boot, it does not do so immediately. As such, a carefully-timed fault injection (via hardware) to trigger an exception (such as an invalid instruction) will cause execution to fall into ARM9 RAM. <br />
Since RAM isn't cleared on boot (see below), one can immediately start execution of their own code here to dump bootrom, OTP, etc.<br />
The ARM9 bootrom does the following at reset: reset vector branches to another instruction, then branches to bootrom+0x8000. Hence, there's no way to know for certain when exactly the ARM9 exception-vector data stored in memory gets initialized.<br />
<br />
This requires *very* *precise* timing for triggering the hardware fault.<br />
<br />
It has been exploited by derrek to dump the ARM9 bootrom as of Summer 2015.<br />
| None: all available 3DS models at the time of writing have the exact same ARM9/ARM11 bootrom for the unprotected areas.<br />
| New3DS<br />
| End of February 2014<br />
| [[User:Derrek|derrek]], WulfyStylez (May 2015) independently<br />
|-<br />
| Missing AES key clearing<br />
| The hardware AES engine does not clear keys when doing a hard reset/reboot.<br />
| None<br />
| New3DS<br />
| August 2014<br />
| Mathieulh/Others<br />
|-<br />
| No RAM clearing on reboots<br />
| On an MCU-triggered reboot all RAM including FCRAM/ARM9 memory/AXIWRAM/VRAM keeps its contents.<br />
| None<br />
| New3DS<br />
| March 2014<br />
| [[User:Derrek|derrek]]<br />
|-<br />
| 32bits of actual console-unique TWLNAND keydata<br />
| On retail the 8-bytes at ARM9 address [[Memory_layout|0x01FFB808]] are XORed with hard-coded data, to generate the TWL console-unique keys, including TWLNAND. On Old3DS the high u32 is always 0x0, while on New3DS that u32 is always 0x2. On top of this, the lower u32's highest bit is always ORed. only 31 bits of the TWL console-unique keydata / TWL consoleID are actually console-unique.<br />
This allows one to easily bruteforce the TWL console-unique keydata with *just* data from TWLNAND. On DSi the actual console-unique data for key generation is 8-bytes(all bytes actually set).<br />
| None<br />
| New3DS<br />
| 2012?<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| DSi / 3DS-TWL key-generator<br />
| After using the key generator to generate the normal-key, you could overwrite parts of the normal-key with your own data and then recover the key-generator output by comparing the new crypto output with the original crypto output. From the normal-key outputs, you could deduce the TWL key-generator function.<br />
This applies to the keyX/keyY too.<br />
<br />
This attack does not work for the 3DS key-generator because keyslots 0-3 are only for TWL keys.<br />
| None<br />
| New3DS<br />
| 2011<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| 3DS key-generator<br />
| The algorithm for generating the normal-keys for keyslots is cryptographically weak. As a result, it is easily susceptible to differential cryptanalysis if the normal-key corresponding to any scrambler-generated keyslot is discovered.<br />
<br />
Several such pairs of matching normal-keys and KeyY values were found, leading to deducing the key-generator function.<br />
| None<br />
| New3DS<br />
| February 2015<br />
| [[User:Yellows8|Yellows8]], [[User:Plutooo|plutoo]]<br />
|-<br />
| RSA keyslots don't clear exponent when setting modulus<br />
| The [[RSA_Registers|RSA keyslots]] are set by boot ROM to have four private RSA keys. The exponent value in the RSA registers is write-only and not readable.<br />
<br />
However, when setting a keyslot's modulus, the RSA hardware leaves the exponent alone. This allows retrieving the exponent by doing a discrete logarithm of the output.<br />
<br />
By setting the modulus to a prime number whose modular multiplicative order is "smooth" (that is, p-1 is divisible by only small prime numbers), discrete logarithms can be calculated quickly using the [[wikipedia:Pohlig-Hellman algorithm|Pohlig-Hellman algorithm]]. If the prime chosen is greater than the modulus, but the same bit size, the discrete logarithm is the private exponent.<br />
<br />
This exploit's usefulness is limited: RSA keyslot 0 is only used in current firmware for deriving the 6.x save and 7.x NCCH keys, which were already known, and the other three keyslots are entirely unused. Additionally, with a boot ROM dump, this exploit is moot; these private keys are located in the protected ARM9 boot ROM.<br />
| None<br />
| New3DS<br />
| March 2016<br />
| [[User:Myria|Myria]]<br />
|-<br />
| [[CONFIG11_Registers#CFG11_GPUPROT|CFG11_GPUPROT]] allowing acccess to AXIWRAM/FCRAM-BASE-memregion<br />
| [[CONFIG11_Registers#CFG11_GPUPROT|CFG11_GPUPROT]] can be configured by anything with access to it to allow the GPU to access the entire AXIWRAM+FCRAM. For example, this is an issue for any sysmodule that gets exploited and has access to this register memory-page(include one that's listed below).<br />
<br />
See also "kernelhax via gspwn" below.<br />
| None<br />
| New3DS<br />
| February 7, 2017<br />
| [[User:Yellows8|Yellows8]]<br />
|}<br />
<br />
== Boot ROM ==<br />
{| class="wikitable" border="1"<br />
! Summary<br />
! Description<br />
! Fixed with hardware model/revision<br />
! Newest hardware model/revision this flaw was checked for<br />
! Timeframe this was discovered<br />
! Discovered by<br />
|-<br />
| FIRM partitions known-plaintext<br />
| The [[Flash_Filesystem|FIRM partitions]] are encrypted with AES-CTR without a MAC. Since this works by XOR'ing data with a static (per-console in this case) keystream, one can deduce the keystream of a portion of each FIRM partition if they have the actual FIRM binary stored in it.<br />
<br />
This can be paired with many exploits. For example, it allows minor FIRM downgrades (i.e. 10.4 to 9.6 or 9.5 to 9.4, but not 9.6 to 9.5).<br />
However it is most commonly used to install arbitrary FIRMs (usually boot9strap), thanks to sighax.<br />
<br />
This can be somewhat addressed by having a FIRM header skip over previously used section offsets, but this would just air-gap newer FIRMs without fixing the core bug. This can also only be done a limited number of times due to the size of FIRM versus the size of the partitions.<br />
| None<br />
| New3DS<br />
| <br />
| Everyone<br />
|-<br />
| Boot9 AES keyinit function issues<br />
| [[Bootloader|Boot9]] seems to have two bugs in the AES key-init function, see [[AES_Registers#AES_key-init|here]].<br />
| None<br />
| BootROM issue.<br />
| 2015<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| New3DS has same boot ROM as Old3DS<br />
| The New3DS has the exact same boot ROM as the Old3DS. This means, among other things, that all the same boot ROM flaws are present. Also, this meant that it is possible to boot Old3DS firmware on New3DS (see "CFG_SYSPROT9 bit1 not set by Kernel9").<br />
| None<br />
| New3DS<br />
| October 2014<br />
| Everyone<br />
|-<br />
| sighax: Boot9 improper validation of FIRM partition RSA signatures<br />
| The [[Flash_Filesystem|FIRM partitions]] are signed with RSA-2048 using SHA-256 and PKCS #1 v1.5 padding. Boot9, however, improperly validates the padding in three ways:<br />
# Boot9 permits block type 02, meant for encrypted messages, to be used for signatures. Only 01, for signatures, should have been permitted. As a result, when using block type 02, a signature block is not required to have a long string of FF bytes as padding, but rather any nonzero random values suffice.<br />
# Boot9 does not require that the length of the padding fill out the signature block completely. As a result, there is considerable freedom in the layout of a signature.<br />
# Boot9 fails to do bounds checking in its parsing of the DER-encoded hash algorithm type and hash value; the length values given in DER are permitted to point outside the signature block.<br />
Flaw 3 allows the DER encoding to be such that boot9 believes that the signature's hash value is outside the range of the block itself, somewhere on the stack. This can be pointed at the correct hash value it computes. Boot9 then memcmp's the calculated hash against itself, and thinks that the hash is valid.<br />
<br />
As a result of the above, we estimate that one in 2<sup>43</sup> (~8.8 trillion) random fake signatures will be considered by Boot9 to be valid. This is well within the range of brute force, particularly with an optimized GPU implementation. An Nvidia GTX 1080 Ti would take about one week to find a match.<br />
| None<br />
| New3DS<br />
| July 2015<br />
| [[User:Derrek|derrek]]<br />
|-<br />
| Boot9 FIRM loading doesn't blacklist memory-mapped I/O<br />
| [[Bootloader|Boot9]]'s FIRM loading blacklists Boot9 data regions, but forgets to do other important regions, including Memory-mapped I/O. Combined with sighax, by loading a malicious FIRM section to MMIO, one can get Boot9/Boot11 code execution. <br />
| None<br />
| New3DS<br />
| 2015(?)<br />
| [[User:Derrek|derrek]] (2015?), [[User:Normmatt|Normmatt]] and [[User:SciresM|SciresM]] independently (January 2017).<br />
|-<br />
| "superhax": Boot9 FIRM loading blacklist check is flawed<br />
| Boot9 only makes sure the '''start''' and '''end''' address of each section is not covered by a blacklisted region. Thus, it is possible to overwrite blacklisted regions (e.g. ARM9 Exception Vectors) by choosing a FIRM section range that encloses an entire blacklisted region. The vulnerable code looks like this: if(blRegions[i].start <= sectionStart && blRegions[i].end > sectionStart <nowiki>||</nowiki> blRegions[i].start <= sectionEnd && blRegions[i].end > sectionEnd) return false; // failure<br />
| None<br />
| New3DS<br />
| August 2015<br />
| [[User:Plutoo|plutoo]], [[User:Yellows8|yellows8]]<br />
|}<br />
<br />
== ARM9 software ==<br />
<br />
=== arm9loader ===<br />
{| class="wikitable" border="1"<br />
|-<br />
! Summary<br />
! Description<br />
! Successful exploitation result<br />
! Fixed in [[FIRM]] system version<br />
! Last [[FIRM]] system version this flaw was checked for<br />
! Timeframe this was discovered<br />
! Public disclosure timeframe<br />
! Discovered by<br />
|-<br />
| Generating the keysector console-unique keys with ITCM+Boot9<br />
| [[Bootloader|Boot9]] decrypts the 0x100-byte [[OTP_Registers|OTP]] using AES-CBC with keydata stored in Boot9. If hash verification is successful, the plaintext of the first 0x90-bytes are copied into [[Memory_layout|ITCM]]. This is the ''exact'' ''same'' region hashed by arm9loader when generating the console-unique keys for decrypting the keysector, except arm9loader uses the raw encrypted OTP.<br />
<br />
Therefore, with the OTP keydata+IV from Boot9 you can: encrypt the 0x90-bytes from ITCM, then hash the output to get the console-unique keys for the system's keysector. This can even be done for Old3DS which doesn't have the arm9loader keysector officially.<br />
<br />
It's unknown why arm9loader only used the first 0x90-bytes of OTP. Using more data from OTP would've prevented this. Fixing this would require doing exactly that, but that would also mean updating the NAND keysector(which is dangerous).<br />
| See description.<br />
| None<br />
| <br />
| 2015<br />
| January 6, 2017<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| Rearrangable keys in the NAND keystore<br />
| Due to the keystore being encrypted with AES-ECB, one can rearrange blocks and still have the NAND keystore decrypt in a deterministic way. <br />
<br />
Using 10.0 FIRM it is possible to rearrange keys such that ARM9 memory is executed. As such using existing ARM9 execution 10.0 FIRM can be written to NAND and a payload written to memory, with the payload to be executed post-K9L using an MCU reboot.<br />
| arm9loaderhax given existing ARM9 code execution<br />
| None<br />
| [[11.3.0-36|11.3.0-X]]<br />
| Early 2016<br />
| 27 September 2016<br />
| Myria, [[User:Dark samus|dark_samus]]; mathieulh (independently); [[User:Plutooo|plutoo]] (independently) + others<br />
|-<br />
| Uncleared OTP hash keydata in console-unique 0x11 key-generation<br />
| Kernel9Loader does not clear the [[SHA_Registers#SHA_HASH|SHA_HASH register]] after use. As a result, the data stored here as K9L hands over to Kernel9 is the hash of [[OTP_Registers|OTP data]] used to seed the [[FIRM#New_3DS_FIRM|console-unique NAND keystore decryption key]] set on keyslot 0x11.<br />
<br />
Retrieving this keydata and the [[Flash_Filesystem#0x12C00|NAND keystore]] of the same device allows calculating the decrypted New3DS NAND keystore (non-unique, common to all New3DS units), which contains AES normal keys, also set on keyslot 0x11, which are then used to derive all current [[AES_Registers#Keyslots|New3DS-only AES keyXs]] including the newer batch introduced in [[9.6.0-24#arm9loader|9.6.0-X]]. From there, it is trivial to perform the same key derivation in order to initialize those keys on any system version, and even on Old3DS.<br />
<br />
This can be performed by exploiting the "arm9loaderhax" vulnerability to obtain post-K9L code execution after an MCU reboot (the bootrom section-loading fail is not relevant here, this attack was performed without OTP data by brute-forcing keys), and using this to dump the SHA_HASH register. This attack works on any FIRM version shipping a vulnerable version of K9L, whereas OTP dumping required a boot of <[[3.0.0-6|3.0.0-X]].<br />
<br />
This attack results in obtaining the entire (0x200-bytes) NAND keystore - it was confirmed at a later date that this keystore is encrypted with the same key (by comparing the decrypted data from multiple units), and therefore using another key in this store will not remedy the issue as all keys are known (i.e. later, unused keys decrypt to the same 0x200-bytes constant with the same OTP hash). Later keys could have been encrypted differently but this is not the case. As a result of this, it is not possible for Nintendo to use K9L again in its current format for its intended purpose, though this was not news from the moment people dumped a New3DS OTP.<br />
| Derivation of all New3DS keys generated via the NAND keystore (0x1B "Secure4" etc.)<br />
| None<br />
| [[11.3.0-36|11.3.0-X]]<br />
| ~April 2015, implemented in May 2015<br />
| 13 January 2016<br />
| [[User:WulfyStylez|WulfyStylez]], [[User:Dazzozo|Dazzozo]], [[User:Shinyquagsire23|shinyquagsire23]] (complimentary + implemented), [[User:Plutooo|plutoo]], Normmatt (discovered independently)<br />
|-<br />
| enhanced-arm9loaderhax<br />
| See the 32c3 3ds talk.<br />
Since this is a combination of a trick with the arm9-bootrom + arm9loaderhax, and since you have to manually write FIRM to the firm0/firm1 NAND partitions, this can't be completely fixed. Any system with existing ARM9 code execution and an OTP/OTP hash dump can exploit this. Additionally, by using the FIRM partition known-plaintext bug and bruteforcing the second entry in the keystore, this can currently be exploited on all New3DS systems without any other prerequisite hacks.<br />
| arm9loaderhax which automatically occurs at hard-boot.<br />
| See arm9loaderhax / description.<br />
| See arm9loaderhax / description.<br />
| Theorized around mid July, 2015. Later implemented+tested by [[User:Plutooo|plutoo]] and [[User:Derrek|derrek]].<br />
| 32c3 3ds talk (December 27, 2015)<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| arm9loaderhax: Missing verification block for the 9.6 keys<br />
| Starting with [[9.6.0-24|9.6.0-X]] a new set of NAND-based keys were introduced. However, no verification block was added to verify that the new key read from NAND is correct. This was technically an issue from [[9.5.0-22|9.5.0-X]] with the original sector+0 keydata, however the below is only possible with [[9.6.0-24|9.6.0-X]] since keyslots 0x15 and 0x16 are generated from different 0x11 keyXs.<br />
<br />
Writing an incorrect key to NAND will cause arm9loader to decrypt the ARM9 kernel as garbage and then jump to it.<br />
<br />
This allows an hardware-based attack where you can boot into an older exploited firmware, fill all memory with NOP sleds/jump-instructions, and then reboot into executing garbage. By automating this process with various input keydata, eventually you'll find some garbage that jumps to your code.<br />
<br />
This gives very early ARM9 code execution (pre-ARM9 kernel). As such, it is possible to dump RSA keyslots with this and calculate the 6.x [[Savegames#6.0.0-11_Savegame_keyY|save]], and 7.x [[NCCH]] keys. This cannot be used to recover keys initialized by arm9loader itself. This is due to it wiping the area used for its stack during NAND sector decryption and keyslot init. <br />
<br />
Due to FIRMs on both Old and New 3DS using the same RSA data, this can be exploited on Old3DS as well, but only if one already has the actual plaintext normalkey from New3DS NAND sector 0x96 offset-0 and has dumped the OTP area of the Old3DS.<br />
| Recovery of 6.x [[Savegames#6.0.0-11_Savegame_keyY|save key]]/7.x [[NCCH]] key, access to uncleared OTP hash keydata<br />
| None<br />
| [[11.3.0-36|11.3.0-X]]<br />
| March 2015<br />
| <br />
| [[User:Plutooo|plutoo]]<br />
|-<br />
| arm9loader runs on Old3DS<br />
| Despite being written only for New3DS, all of arm9loader runs fine on Old3DS. It's not until booting Kernel9 that a New3DS FIRM partition would crash on an Old3DS. As a result, if a bug exists in arm9loader to get control, it can be exploited on Old3DS by writing New3DS FIRM to the FIRM partitions. Thus, arm9loaderhax works on both Old3DS and New3DS.<br />
| arm9loader bugs also compromise Old3DS<br />
| None<br />
| [[11.3.0-36|11.3.0-X]]<br />
| Sometime in 2015<br />
| <br />
| [[User:Plutooo|plutoo]] presumably<br />
|-<br />
| Uncleared New3DS keyslot 0x11<br />
| Originally the New3DS [[FIRM]] arm9bin loader only cleared keyslot 0x11 when it gets executed at firmlaunch. This was fixed with [[9.5.0-22|9.5.0-X]] by completely clearing keyslot 0x11 immediately after the loader finishes using keyslot 0x11.<br />
This means that any ARM9 code that can execute before the loader clears the keyslot at firmlaunch(including firmlaunch-hax) can get access to the uncleared keyslot 0x11, which then allows one to generate all <=v9.5 New3DS keyXs which are generated by keyslot 0x11.<br />
<br />
Therefore, to completely fix this the loader would have to generate more keys using different keyslot 0x11 keydata. This was done with [[9.6.0-24|9.6.0-X]].<br />
| New3DS keyXs generation<br />
| Mostly fixed with [[9.5.0-22|9.5.0-X]], completely fixed with new keys with [[9.6.0-24|9.6.0-X]].<br />
| <br />
| February 3, 2015 (one day after [[9.5.0-22|9.5.0-X]] release)<br />
| <br />
| [[User:Yellows8|Yellows8]]<br />
|}<br />
<br />
=== Process9 ===<br />
{| class="wikitable" border="1"<br />
|-<br />
! Summary<br />
! Description<br />
! Successful exploitation result<br />
! Fixed in [[FIRM]] system version<br />
! Last [[FIRM]] system version this flaw was checked for<br />
! Timeframe this was discovered<br />
! Public disclosure timeframe<br />
! Discovered by<br />
|-<br />
| Leak of normal-key matching a key-scrambler key<br />
| New 3DS firmware versions [[8.1.0-0 New3DS|8.1.0]] through [[9.2.0-20|9.2.0]] set the encryption key for [[Amiibo]] data using a hardcoded normal-key in Process9. In firmware [[9.3.0-21|9.3.0]], Nintendo "fixed" this by using the key scrambler instead, by calculating the keyY value for keyslot 0x39 that results in the same normal-key, then hardcoding that keyY into Process9.<br />
<br />
Nintendo's fix is actually the problem: Nintendo revealed the normal-key matching an unknown keyX and a known keyY. Combined with the key scrambler using an insecure scrambling algorithm (see "Hardware" above), the key scrambler function could be deduced.<br />
| Deducing the keyX for keyslot 0x39 and the key scrambler algorithm<br />
| New 3DS [[9.3.0-21|9.3.0-X]], sort of<br />
| [[10.0.0-27|10.0.0-X]]<br />
| Sometime in 2015 after the hardware key-generator was broken.<br />
| 32c3 3ds talk (December 27, 2015)<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| Leak of normal-key matching a key-generator key<br />
| During the 3DS' development (June/July 2010) Nintendo added support installing encrypted content ([[CIA]]). Common-key index1 was intended to be a [[AES|hardware generated key]]. However while they added code to generate the key in hardware, they forgot to remove the normal-key for index1 (used elsewhere, likely old debug code). Nintendo later removed the normal key sometime before the first non-prototype firmware release.<br />
<br />
Knowing the keyY and the normal-key for common-key index1, the devkit key-generator algorithm can be deduced (see "Hardware" above). Additionally the remaining devkit common-keys can be generated once the common-key keyX is recovered.<br />
<br />
Note that the devkit key-generator was discovered to be the same as the retail key-generator.<br />
| Deducing the keyX for keyslot 0x3D and hardware key-generator algorithm. Generate remaining devkit common-keys.<br />
| pre-[[1.0.0-0|1.0.0-X]]<br />
| <br />
| Shortly after the key-generator was revealed to be flawed at the 32c3 3ds talk<br />
| January 20, 2016<br />
| [[User:Jakcron|jakcron]]<br />
|-<br />
| Factory firmware is vulnerable to sighax<br />
| During the 3DS's development, presumably boot9 was written (including the sighax) vulnerability. This vulnerability is also present in factory firmware (and earlier, including 0.11). This was fixed in version 1.0.0-0.<br />
| Deducing the mechanics of the sighax vulnerability in boot9 without having boot9 prot. Arm9 code execution on factory/earlier firmware.<br />
| [[1.0.0-0|1.0.0-X]]<br />
| [[1.0.0-0|1.0.0-X]]<br />
| May 9, 2017<br />
| May 19, 2017<br />
| [[User:SciresM|SciresM]], [[User:Myria|Myria]]<br />
|-<br />
| safefirmhax<br />
| SAFE_MODE_FIRM is almost never updated(even when NATIVE_FIRM is updated for vuln fixes), this can be noticed by ''just'' checking 3dbrew/ninupdates title-listings.<br />
<br />
The fix for 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 <=> Kernel11 sync, PXI sync and then repeat the original attack on SAFE_FIRM instead.<br />
| ARM9 code execution<br />
| [[11.3.0-36|11.3.0-X]]<br />
| <br />
| 2012-2013?<br />
| Wiki: January 2, 2017<br />
| Everyone<br />
|-<br />
| safefirmhax 1.1<br />
| Nintendo's original safefirmhax fix was flawed -- they added a global boolean that got set to true whenever a non-sysmodule title got launched (except for a hardcoded repair title id), and panic()'d if that boolean was true to prevent launching safefirm after hax was active. However, because the boolean was initially false after firmlaunch -- With ARM11-kernel execution, one could FIRM-launch into NATIVE_FIRM, and then immediately FIRM-launch again into SAFE_FIRM early in NATIVE_FIRM boot before the boolean got set to true to repeat the safehax attack.<br />
<br />
This was fixed by adding additional CFG9_BOOTENV checks to firmlaunch code in 11.4.<br />
| ARM9 code execution<br />
| [[11.4.0-37|11.4.0-X]]<br />
| <br />
| safefirmhax fix<br />
| Wiki: April 10, 2017<br />
| Everyone<br />
|-<br />
| ntrcardhax<br />
| When reading the banner of a NTR title, Process9 relies on a hardware register to know when the banner was fully read.<br />
However that register is shared between the ARM9 and the ARM11.<br />
An attacker with k11 control can so make Process9 believe the banner continues forever and so trigger a buffer overflow.<br />
With a custom banner for a NTR flashcart, this leads to code execution in Process9.<br />
<br />
This was fixed by adding bound checks on the read data.<br />
| ARM9 code execution<br />
| [[10.4.0-29|10.4.0-X]]<br />
| <br />
| March 2015<br />
| 32c3 3ds talk (December 27, 2015)<br />
| [[User:Plutooo|plutoo]]<br />
|-<br />
| Title downgrading via [[Application_Manager_Services|AM]]([[Application_Manager_Services_PXI|PXI]])<br />
| When a title is *already* installed, Process9 will compare the installed title-version with the title-version being installed. When the one being installed is older, Process9 would return an error.<br />
<br />
However, this can be bypassed by just deleting the title first via the service command(s) for that: with the title removed from the [[Title_Database]], Process9 can't compare the input title-version with anything. Hence, titles can be downgraded this way.<br />
<br />
[[11.0.0-33|11.0.0-X]] fixed this for key system titles (MSET, Home Menu, spider, ErrDisp, SKATER, NATIVE_FIRM, and every retail system module), by checking the version of the title to install against a hard-coded list of (titleID, minimumVersionRequired) pairs.<br />
| Bypassing title version check at installation, which then allows downgrading any title.<br />
| [[11.0.0-33|11.0.0-X]], for key system titles.<br />
| NATIVE_FIRM / AM-sysmodule [[11.0.0-33|11.0.0-X]]<br />
| ?<br />
| <br />
| ?<br />
|-<br />
| Anti-downgrade list did not include all system titles initially<br />
| The anti-downgrade list did not include legacy FIRMs until [[11.8.0-41|11.8.0-X]]. Therefore, legacy FIRMs could still be downgraded.<br />
| Downgrading legacy FIRMs; allowing to exploit bugs in older legacy FIRMs (of which at least one exists, see below).<br />
| [[11.8.0-33|11.8.0]]<br />
| [[11.8.0-33|11.8.0]]<br />
| ?<br />
| Wiki: August 5, 2018<br />
| Everyone<br />
|-<br />
| TWL_FIRM cmd-9 unchecked offset<br />
| In [[1.0.0-0|1.0.0-X]]'s TWL_FIRM, cmds 8 and 9 were not stubbed (whereas in the corresponding NATIVE_FIRM, they were).<br />
Command 8 does the Process9 initialisation for NTR carts if an NTR cart is inserted (NTR, not TWL, judged by chipid).<br />
<br />
Command 9 takes (u32 offset_read, u32 offset_write, u32 offset_read_end), and basically just copies (offset_read_end - offset_read) bytes starting at (offset_read) of [NTR cart header in arm9mem, NTR secure area in fcram, TWL secure area in fcram], to 0x18001000 + offset_write + offset_read.<br />
<br />
offset_write is not checked at all, thus this leads to ARM9 code execution as long as any NTR cart, including flashcarts that would normally be blocked by TWL_FIRM, is inserted.<br />
<br />
In [[2.0.0-2|2.0.0-X]] TWL_FIRM, those commands were stubbed out.<br />
| ARM9 code execution<br />
| [[2.0.0-2|2.0.0-X]]<br />
| [[2.0.0-2|2.0.0-X]]<br />
| January 2018<br />
| Wiki: August 5, 2018<br />
| [[User:Riley|Riley]]<br />
|-<br />
| FAT FS code null-deref<br />
| When FSFile:Read is used with a file which is corrupted on a FAT filesystem(in particular SD), Process9 can crash. This particular crash is caused by a function returning NULL instead of an actual ptr due to an error. The caller of that function doesn't check for NULL which then triggers a read based at NULL.<br />
<br />
Sample "fsck.vfat -n -v -V <fat image backup>" output for the above crash:<br />
<br />
<pre>...<br />
Starting check/repair pass.<br />
<FilePath0> and<br />
<FilePath1><br />
share clusters.<br />
Truncating second to 3375104 bytes.<br />
<FilePath1><br />
File size is 2787392 bytes, cluster chain length is 16384 bytes.<br />
Truncating file to 16384 bytes.<br />
Checking for unused clusters.<br />
Reclaimed 1 unused cluster (16384 bytes).<br />
Checking free cluster summary.<br />
Free cluster summary wrong (1404490 vs. really 1404491)<br />
Auto-correcting.<br />
Starting verification pass.<br />
Checking for unused clusters.<br />
Leaving filesystem unchanged.</pre><br />
| Useless null-based-read<br />
| None<br />
| [[9.6.0-24|9.6.0-X]]<br />
| July 8-9, 2015<br />
| <br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| RSA signature padding checks<br />
| The TWL_FIRM RSA sig padding check code used for all TWL RSA sig-checks has issues, see [[FIRM|here]].<br />
The main 3DS RSA padding check code(non-certificate, including NATIVE_FIRM) uses the function used with the above to extract more padding + the actual hash from the additional padding. This isn't really a problem here because there's proper padding check code which is executed prior to this.<br />
| <br />
| None<br />
| [[9.5.0-22|9.5.0-X]]<br />
| March 2015<br />
| <br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[AMPXI:ValidateDSiWareSectionMAC]] [[AES_Registers|AES]] keyslot reuse<br />
| When the input DSiWare section index is higher than <max number of DSiWare sections supported by this FIRM>, Process9 uses keyid 0x40 for calculating the AESMAC, which translates to keyslot 0x40. The result is that the keyslot is left at whatever was already selected before, since the AES selectkeyslot code will immediately return when keyslot is >=0x40. However, actually exploiting this is difficult: the calculated AESMAC is never returned, this command just compares the calculated AESMAC with the input AESMAC(result-code depends on whether the AESMACs match). It's unknown whether a timing attack would work with this.<br />
This is basically a different form of the pxips9 keyslot vuln, except with AESMAC etc.<br />
| See description.<br />
| None<br />
| [[11.3.0-36|11.3.0-X]]<br />
| March 15, 2015<br />
| December 29, 2015<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| pxips9 [[AES_Registers|AES]] keyslot reuse<br />
| This requires access to the [[Process_Services|ps:ps]]/pxi:ps9 services. One way to get access to this would be snshax on system-version <=10.1.0-X(see 32c3 3ds talk).<br />
When an invalid key-type value is passed to any of the PS commands, Process9 will try to select keyslot 0x40. That aesengine_setkeyslot() code will then immediately return due to the invalid keyslot value. Since that function doesn't return any errors, Process9 will just continue to do crypto with whatever AES keyslot was selected before the PS command was sent.<br />
| Reusing the previously used keyslot, for crypto with PS.<br />
| None<br />
| [[11.3.0-36|11.3.0-X]]<br />
| Roughly the same time(same day?) as firmlaunch-hax.<br />
| December 29, 2015<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| firmlaunch-hax: FIRM header ToCToU<br />
| This can't be exploited from ARM11 userland.<br />
During [[FIRM]] launch, the only FIRM header the ARM9 uses at all is stored in FCRAM, this is 0x200-bytes(the actual used FIRM RSA signature is read to the Process9 stack however). The ARM9 doesn't expect "anything" besides the ARM9 to access this data.<br />
With [[9.5.0-22]] the address of this FIRM header was changed from a FCRAM address, to ARM9-only address 0x01fffc00.<br />
| ARM9 code execution<br />
| [[9.5.0-22]]<br />
| <br />
| 2012, 3 days after [[User:Yellows8|Yellows8]] started Process9 code RE.<br />
| <br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| Uninitialized data output for (PXI) command replies<br />
| PXI commands for various services(including some [[Filesystem_services_PXI|here]] and many others) can write uninitialized data (like from ARM registers) to the command reply. This happens with stubbed commands, but this can also occur with certain commands when returning an error.<br />
Certain ARM11 service commands have this same issue as well.<br />
| <br />
| None<br />
| [[9.3.0-21|9.3.0-X]]<br />
| ?<br />
| <br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[Filesystem_services_PXI|FSPXI]] OpenArchive SD permissions<br />
| Process9 does not use the exheader ARM9 access-mount permission flag for SD at all.<br />
This would mean ARM11-kernelmode code / fs-module itself could directly use FSPXI to access SD card without ARM9 checking for SD access, but this is rather useless since a process is usually running with SD access(Home Menu for example) anyway.<br />
| <br />
| None<br />
| [[9.3.0-21|9.3.0-X]]<br />
| 2012<br />
| <br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[AMPXI:ExportDSiWare]] export path<br />
| Process9 allocates memory on Process9 heap for the export path then verifies that the actual allocated size matches the input size. Then Process9 copies the input path from FCRAM to this buffer, and uses it with the Process9 FS openfile code, which use paths in the form of "<mountpoint>:/<path>".<br />
Process9 does not check the contents of this path at all before passing it to the FS code, besides writing a NUL-terminator to the end of the buffer.<br />
| Exporting of DSiWare to arbitrary Process9 file-paths, such as "nand:/<path>" etc. This isn't really useful since the data which gets written can't be controlled.<br />
| None<br />
| [[9.5.0-22]]<br />
| April 2013<br />
| <br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[DSiWare_Exports]] [[CTCert]] verification<br />
| Just like DSi originally did, 3DS verifies the APCert for DSiWare on SD with the CTCert also in the DSiWare .bin. On DSi this was fixed with with system-version 1.4.2 by verifying with the actual console-unique cert instead(stored in NAND), while on 3DS it's still not(?) fixed.<br />
On 3DS however this is useless, unless one can obtain the console-unique movable.sed keyY which encrypts the entire DSiWare .bin.<br />
| When the movable.sed keyY for the target 3DS is known and the target 3DS CTCert private-key is unknown, importing of modified DSiWare SD .bin files.<br />
| None.<br />
| 11.6.0-X<br />
| April 2013<br />
| <br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| seedminer: movable.sed keyY vulnerable to brute-force<br />
| Half of the movable.sed keyY's 128 bits are leaked through the [[Nandrw/sys/LocalFriendCodeSeed_B|LFCS]], which is available in userland and below. The LFCS itself also leaks almost half of the remaining bits by following the ratio: u32 keyY[3]=1/5(LFCS). The remaining keyY[3] uncertainty of about ±2000 can be greatly reduced by plotting expected error margins with several keyYs. This results in a final uncertainty of about 2^40, easily within practical brute force range of an average modern PC.<br />
| Knowing the keyY of a given 3ds allows for modification of DSiWare export contents, and chained with several other public vulns, ultimately arm9 execution.<br />
| None.<br />
| 11.6.0-X<br />
| December 2017<br />
| January 2018<br />
| zoogie<br />
|-<br />
| Improper validation of DSiWare title SRLs<br />
| The 3DS does not verify if the actual SRL embedded in the title's directory matches the titleID in the TMD before launching it or importing it from an sd DSiWare export. <br />
| This allows embedding older, exploitable DSiWare titles in completely different, unexploitable DSiWare titles. Since DSiWare has raw NAND RW, this can result in arm9 control through FIRM known-plaintext and sighax attacks.<br />
| None.<br />
| 11.6.0-X<br />
| 2015?<br />
| December 2016<br />
| Everyone<br />
|-<br />
| [[Gamecard_Services_PXI]] unchecked REG_CTRCARDCNT transfer-size<br />
| The u8 REG_CTRCARDCNT transfer-size parameter for the [[Gamecard_Services_PXI]] read/write CTRCARD commands is used as an index for an array of u16 values. Before [[5.0.0-11|5.0.0-X]] this u8 value wasn't checked, thus out-of-bounds reads could be triggered(which is rather useless in this case).<br />
| Out-of-bounds read for a value which gets written to a register.<br />
| [[5.0.0-11|5.0.0-X]]<br />
| <br />
| 2013?<br />
| <br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[PXI_Registers|PXI]] cmdbuf buffer overrun<br />
| The Process9 code responsible [[PXI_Registers|PXI]] communications didn't verify the size of the incoming command before writing it to a C++ member variable. <br />
| Probably ARM9 code execution<br />
| [[5.0.0-11|5.0.0-11]]<br />
| <br />
| March 2015, original timeframe if any unknown<br />
| <br />
| [[User:Plutooo|plutoo]]/[[User:Yellows8|Yellows8]]/maybe others(?)<br />
|-<br />
| [[Application_Manager_Services_PXI|PXIAM]] command 0x003D0108(See also [[Application_Manager_Services|this]])<br />
| When handling this command, Process9 allocates a 0x2800-byte heap buffer, then copies the 4 FCRAM input buffers to this heap buffer without checking the sizes at all(only the buffers with non-zero sizes are copied). Starting with [[5.0.0-11|5.0.0-X]], the total combined size of the input data must be <=0x2800.<br />
| ARM9 code execution<br />
| [[5.0.0-11|5.0.0-X]]<br />
| <br />
| May 2013<br />
| <br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[Process_Services_PXI|PS RSA]] commands buffer overflows<br />
| pxips9 cmd1(not accessible via ps:ps) and VerifyRsaSha256: unchecked copy to a buffer in Process9's .bss, from the input FCRAM buffer. The buffer is located before the pxi cmdhandler threads' stacks. SignRsaSha256 also has a buf overflow, but this isn't exploitable.<br />
The buffer for this is the buffer for the signature data. With v5.0, the signature buffer was moved to stack, with a check for the signature data size. When the signature data size is too large, Process9 uses [[SVC|svcBreak]].<br />
| ARM9 code execution<br />
| [[5.0.0-11|5.0.0-X]]<br />
| <br />
| 2012<br />
| <br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[PXI_Registers|PXI]] pxi_id bad check<br />
| The Process9 code responsible for [[PXI_Registers|PXI]] communications read pxi_id as a signed char. There were two flaws:<br />
* They used it as index to a lookup-table without checking the value at all.<br />
* Another function verified that pxi_id < 7, allowing negative values to pass the check. This would also cause an out-of-range table-lookup.<br />
| Maybe ARM9 code execution<br />
| [[3.0.0-5|3.0.0-5]]<br />
|<br />
| March 2015, originally 2012 for the first issue at least<br />
| <br />
| [[User:Plutooo|plutoo]], [[User:Yellows8|Yellows8]], maybe others(?)<br />
|}<br />
<br />
=== Kernel9 ===<br />
{| class="wikitable" border="1"<br />
|-<br />
! Summary<br />
! Description<br />
! Successful exploitation result<br />
! Fixed in [[FIRM]] system version<br />
! Last [[FIRM]] system version this flaw was checked for<br />
! Timeframe this was discovered<br />
! Discovered by<br />
|-<br />
| [[CONFIG Registers#CFG_SYSPROT9|CFG_SYSPROT9]] bit1 not set by Kernel9<br />
| Old versions of Kernel9 never set bit1 of [[CONFIG Registers#CFG_SYSPROT9|CFG_SYSPROT9]]. This leaves the [[OTP Registers|0x10012000]]-region unprotected (this region should be locked early during boot!). Since it's never locked, you can dump it once you get ARM9 code execution.<br />
<br />
From [[3.0.0-5|3.0.0-X]] this was fixed by setting the bit in Kernel9 after poking some registers in that region. On New3DS arm9loader sets this bit instead of Kernel9, which is exploitable through a hardware + software vulnerability (see arm9loaderhax / description).<br />
<br />
This flaw resurged when it gained a new practical use: retrieving the OTP data for a New3DS console in order to decrypt the key data used in arm9loader (see enhanced-arm9loaderhax / description). This was performed by downgrading to a vulnerable system version. By accounting for differences in CTR-NAND crypto (0x05 -> 0x04, see partition encryption types [[Flash_Filesystem#NAND_structure|here]]) and using an Old3DS [[NCSD#NCSD_header|NCSD Header]], it is possible to boot a New3DS using Old3DS firmware 1.0-2.x to retrieve the required OTP data using this flaw.<br />
| Dumping the [[OTP Registers|OTP]] area.<br />
Decrypting New3DS sector 0x96 keyblock.<br />
| [[3.0.0-5|3.0.0-X]]<br />
|<br />
| February 2015<br />
| [[User:Plutooo|plutoo]], Normmatt independently<br />
|}<br />
<br />
== ARM11 software ==<br />
=== Kernel11 ===<br />
{| class="wikitable" border="1"<br />
|-<br />
! Summary<br />
! Description<br />
! Successful exploitation result<br />
! Fixed in [[FIRM]] system version<br />
! Last [[FIRM]] system version this flaw was checked for<br />
! Timeframe this was discovered<br />
! Discovered by<br />
|-<br />
| [[SVC|svcSetProcessIdealProcessor]] reference count overflow and therefore use-after-free.<br />
| The SVC receive two arguments: handle and idealprocessor. The handle is used to get the KProcess object and the KProcess->refCnt gets incremented,later the function check if the KProcess->mem_type != BASE and if yes, it checks for idealprocessor == 2 or idealprocessor != 3. The problem here is that if you pass the idealprocessor = 3 it won't meet any condition and return the error 0xD9001BEA without decrement the reference count. <br />
It can be abused to overflow the KProcess reference count that will lead to an Use-after-free. <br />
| Before [[11.2.0-35|11.2.0-X]]: reference count overflow and therefore use-after-free.<br />
| <br />
| [[11.6.0-39|11.6.0-X]]<br />
| November 2, 2017<br />
| [[User:st4rk|st4rk]]<br />
|-<br />
| [[SVC|svcGetThreadList]] process reference leak<br />
| When given a valid process handle (including <code>0xFFFF8001</code>), svcGetThreadList forgets to decrement the reference count of the underlying [[KProcess]] instance, after having finished using it.<br />
| Before [[11.2.0-35|11.2.0-X]]: reference count overflow and therefore use-after-free, but this UAF was most likely not exploitable<br />
| <br />
| [[11.3.0-36|11.3.0-X]]<br />
| April 3, 2017<br />
| [[User:TuxSH|TuxSH]]<br />
|-<br />
| kernelhax via gspwn<br />
| Originally the kernel didn't initialize [[CONFIG11_Registers#CFG11_GPUPROT|CFG11_GPUPROT]]. Since it's 0 at hard-boot, this allowed the GPU to access the entire FCRAM + AXIWRAM.<br />
| Entire FCRAM+AXIWRAM R/W.<br />
| [[3.0.0-5|3.0.0-X]]<br />
| <br />
| February 7, 2017<br />
| [[User:Plutooo|plutoo]], [[User:Yellows8|Yellows8]] partly<br />
|-<br />
| fasthax<br />
| When a KTimer is created in pulse mode, the kernel calls a virtual function to reset the timer each time it pulses. The scheduler is locked for that core to avoid race conditions, but another core can call CloseHandle on the timer and free it, leading to a UAF vtable call.<br />
| See description.<br />
| [[11.3.0-36|11.3.0-X]]<br />
| [[11.3.0-36|11.3.0-X]]<br />
| May 2016<br />
| nedwill<br />
|-<br />
| ipctakeover<br />
| When sending cmdreplies, it does not validate that the src_addr and src_size match the equivalent dst_addr and dst_size. With a modified addr/size specified in a cmdreply for an output buffer, the data-copy for the first/last pages could be used to overwrite data outside of the buffer specified by the original process.<br />
<br />
Used by ctr-httpwn as of v1.2, for "ipctakeover/bosshaxx".<br />
<br />
This can be used to takeover processes where the process is using your service session. Like HTTPC -> BOSS, for bosshaxx above. NIM takeover can be done too(actual stack buffer overflow can trigger), etc.<br />
| See description.<br />
| None<br />
| [[11.3.0-36|11.3.0-X]]<br />
| November 26, 2016<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| Using IPC input buffers as output buffers<br />
| When sending cmdreplies, it does not validate that the cmdreply descriptor type matches the equivalent cmdreq descriptor type. This could be used by an exploited sysmodule to use what was intended as an input-buffer as an output-buffer, and also combine other IPC vuln(s) with this.<br />
<br />
Used by ctr-httpwn as of v1.2, for "ipctakeover/bosshaxx".<br />
| See description.<br />
| None<br />
| [[11.3.0-36|11.3.0-X]]<br />
| November 2016<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[SVC]] table too small<br />
| The table of function pointers for SVC's only contains entries up to 0x7D, but the biggest allowed SVC for the table is 0x7F. Thus, executing SVC7E or SVC7F would make the SVC-handler read after the buffer, and interpret some ARM instructions as function pointers.<br />
<br />
However, this would require patching the kernel .text or modifying SVC-access-control. Even if you could get these to execute, they would still jump to memory that isn't mapped as executable.<br />
| <br />
| None<br />
| [[11.3.0-36|11.3.0-X]]<br />
| 2012<br />
| Everyone<br />
|-<br />
| [[SVC|svcBackdoor (0x7B)]]<br />
| This backdoor allows executing SVC-mode code at the user-specified code-address. This is used by Process9, using this on the ARM11 (with NATIVE_FIRM) required patching the kernel .text or modifying SVC-access-control.<br />
| See description<br />
| [[11.0.0-33|11.0.0-X]] (deleted)<br />
| <br />
|<br />
| Everyone<br />
|-<br />
| veryslowpidhax<br />
| '''This is completely different from the kernelmode-code-execution vuln described in the below separate entry.'''<br />
<br />
When updating the kernel global PID counter under [[SVC|svcCreateProcess]] the kernel does not check for wraparound to 0x0(the PID for the very first process). This only matters because [[Services|SM-module]] allows processes with PID value less than <total ARM11 FIRM modules> to access ''all'' services, without checking exheader service-access-control; and because Kernel11 checks for the PID to be 1 (loader) to use the input mem-region value on ControlMemory. This alone does not affect access the [[SVC|SVCs]] access table at all.<br />
<br />
Inlined ldrex+strex code is used for updating the above counter. [[11.2.0-35|11.2.0-X]] had changes for similar code, but it was only for dedicated ldrex+strex functions(mainly for kernel objects) and hence this PID code was not affected.<br />
<br />
With launching+terminating a sysmodule repeatedly with this via ns:s, it would take weeks to finish(if not at least about a month?).<br />
| Access to all [[Services_API|services]], ControlMemory on any given mem-region.<br />
| None<br />
| [[11.3.0-36|11.3.0-X]]<br />
| 2012 maybe?<br />
| <br />
|-<br />
| slowhax/waithax<br />
| svcWaitSynchronizationN does not decrement the references to valid handles in an array before returning an error when it encounters an invalid handle. This allows one to (slowly) overflow the reference count for a handle object to zero.<br />
| ARM11 kernel-mode code execution<br />
| [[11.2.0-35|11.2.0-X]]<br />
| [[11.2.0-35|11.2.0-X]]<br />
| 2016<br />
| nedwill, [[User:Derrek|derrek]]<br />
|-<br />
| [[Memory_layout#ARM11_Detailed_virtual_memory_map|0xEFF00000]] / 0xDFF00000 ARM11 kernel virtual-memory<br />
| The ARM11 kernel-mode 0xEFF00000/0xDFF00000 virtual-memory(size 0x100000) is mapped to phys-mem 0x1FF00000(entire DSP-mem + entire AXIWRAM), with permissions RW-. This is used during ARM11 kernel startup for loading the FIRM-modules from the FIRM section located in DSP-mem, this never seems to be used after that, however. This is never unmapped either.<br />
| <br />
| None<br />
| [[11.3.0-36|11.3.0-X]]<br />
| <br />
| <br />
|-<br />
| memchunkhax2.1<br />
| Nintendo's fix for memchunkhax2 in [[10.4.0-29|10.4.0-X]] did not fix the GPU case: one may cause the requisite ToCToU race using gspwn, bypassing the new validation.<br />
derrek's original 32c3 presentation for memchunkhax2 commented that a GPU-based attack was possible, but would be difficult. However, memchunkhax2.1 showed that it was possible to do fairly reliably.<br />
| ARM11 kernel code execution<br />
| [[11.0.0-33|11.0.0-X]], via the new [[Memory_Management#MemoryBlockHeader|memchunkhdr]] MAC which prevents modifying memchunkhdr data with DMA.<br />
| [[11.0.0-33|11.0.0-X]]<br />
|<br />
| [[User:Derrek|derrek]], aliaspider<br />
|-<br />
| memchunkhax2<br />
| When allocating a block of memory, the "next" pointer of the [[Memory_Management#MemoryBlockHeader|memchunkhdr]] is accessed without being checked after being mapped to userland.<br />
This allows a race condition, where the process can change the next pointer just before it's accessed. By pointing the next pointer to a crafted memchunckhdr in the kernel SlabHeap, some of the SlabHeap is allocated to the calling process, allowing to change vtables of kernel objects. <br />
| ARM11 kernel code execution<br />
| [[10.4.0-29|10.4.0-X]] (partially, see memchunkhax2.1)<br />
| [[10.4.0-29|10.4.0-X]]<br />
|<br />
| [[User:Derrek|derrek]]<br />
|-<br />
| heaphax<br />
| Can change the size of free memchunk structures stored in FCRAM using DMA, which leads to the ability to allocate memory chunks over already-allocated memory. This can be used in the SYSTEM region to allocate RW memory over any part of the NS system module, which is enough to take it over.<br />
| Code execution with access to all of NS's privileges. (including downgrading) Code execution within any applet.<br />
| [[11.0.0-33|11.0.0-X]], via the new [[Memory_Management#MemoryBlockHeader|memchunkhdr]] MAC which prevents modifying memchunkhdr data with DMA.<br />
| [[11.0.0-33|11.0.0-X]]<br />
| April 2015 ?<br />
| smea<br />
|-<br />
| snshax<br />
| Can force creation of Safe NS process into gspwn-able memory, allowing for takeover.<br />
| Code execution with access to all of NS's privileges. (including downgrading)<br />
| [[10.1.0-27|10.1.0-X]]<br />
| [[10.1.0-27|10.1.0-X]]<br />
| April 2015 ?<br />
| smea<br />
|-<br />
| AffinityMask/processorid validation<br />
| With [[10.0.0-27|10.0.0-X]] the following functions were updated: svcGetThreadAffinityMask, svcGetProcessAffinityMask, svcSetProcessAffinityMask, and svcCreateThread. The code changes for all but svcCreateThread are identical.<br />
The original code with the first 3 did the following: <br />
* if(u32_processorcount > ~0x80000001)return 0xe0e01bfd;<br />
* if(s32_processorcount > <total_cores>)return 0xd8e007fd;<br />
The following code replaced the above:<br />
* if(u32_processorcount >= <total_cores+1>)return 0xd8e007fd;<br />
In theory the latter should catch everything that the former did, so it's unknown if this was really a security issue.<br />
<br />
The svcCreateThread changes with [[10.0.0-27|10.0.0-X]] definitely did fix a security issue.<br />
* Original code: "if(s32_processorid > <total_cores>)return 0xd8e007fd;"<br />
* New code: "if(s32_processorid >= <total_cores> || s32_processorid <= -4)return 0xd8e007fd;"<br />
This fixed an off-by-one issue: if one would use processorid=total_cores, which isn't actually a valid value, svcCreateThread would accept that value on <[[10.0.0-27|10.0.0-X]]. This results in data being written out-of-bounds(baseaddr = arrayaddr + entrysize*processorid), which has the following result:<br />
* Old3DS: Useless kernel-mode crash due to accessing unmapped memory.<br />
* New3DS: uncontrolled data write into a kernel-mode L1 MMU-table. This isn't really useful: the data can't be controlled, and the data which gets overwritten is all-zero anyway(this isn't anywhere near MMU L1 entries for actually mapped memory).<br />
The previous version also allowed large negative s32_processorid values(negative processorid values are special values not actual procids), but it appears using values like that won't actually do anything(meaning no crash) besides the thread not running / thread not running for a while(besides triggering a kernelpanic with certain s32_processorid value(s)).<br />
| Nothing useful<br />
| [[10.0.0-27|10.0.0-X]]<br />
| [[10.0.0-27|10.0.0-X]]<br />
| svcCreateThread issue: May 31, 2015. The rest: September 8, 2015, via v9.6->v10.0 ARM11-kernel code-diff.<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| memchunkhax<br />
| The kernel originally did not validate the data stored in the FCRAM kernel heap [[Memchunkhdr|memchunk-headers]] for free-memory at all. Exploiting this requires raw R/W access to these memchunk-headers, like physical-memory access with gspwn.<br />
<br />
There are ''multiple'' ways to exploit this, but the end-result for most of these is the same: overwrite code in AXIWRAM via the 0xEFF00000/0xDFF00000 kernel virtual-memory mapping.<br />
<br />
This was fixed in [[9.3.0-21|9.3.0-X]] by checking that the memchunk(including size, next, and prev ptrs) is located within the currently used heap memory. The kernel may also check that the next/prev ptrs are valid compared to other memchunk-headers basically. When any of these checks fail, kernelpanic() is called.<br />
| When combined with other flaws: ARM11-kernelmode code execution<br />
| [[9.3.0-21|9.3.0-21]]<br />
| <br />
| February 2014<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| Multiple [[KLinkedListNode|KLinkedListNode]] SlabHeap use after free bugs<br />
| The ARM11-kernel did access the 'key' field of [[KLinkedListNode|KLinkedListNode]] objects, which are located on the SlabHeap, after freeing them. Thus, triggering an allocation of a new [[KLinkedListNode|KLinkedListNode]] object at the right time could result in a type-confusion. Pseudo-code:<br />
SlabHeap_free(KLinkedListNode);<br />
KObject *obj = KLinkedListNode->key; // the object there might have changed!<br />
This bug appeared all over the place.<br />
| ARM11-kernelmode code exec maybe<br />
| [[8.0.0-18|8.0.0-18]]<br />
| <br />
| April 2015<br />
| [[User:Derrek|derrek]]<br />
|-<br />
| PXI [[RPC_Command_Structure|Command]] input/output buffer permissions<br />
| Originally the ARM11-kernel didn't check permissions for PXI input/output buffers for commands. Starting with [[6.0.0-11|6.0.0]] PXI input/output buffers must have RW permissions, otherwise kernelpanic is triggered.<br />
| <br />
| [[6.0.0-11|6.0.0-11]]<br />
| <br />
| 2012<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[SVC|svcStartInterProcessDma]]<br />
| For svcStartInterProcessDma, the kernel code had the following flaws:<br />
<br />
* Originally the ARM11-kernel read the input DmaConfig structure directly in kernel-mode(ldr(b/h) instructions), without checking whether the DmaConfig address is readable under userland. This was fixed by copying that structure to the SVC-mode stack, using the ldrbt instruction.<br />
<br />
* Integer overflows for srcaddr+size and dstaddr+size are now checked(with [[6.0.0-11]]), which were not checked before.<br />
<br />
* The kernel now also checks whether the srcaddr/dstaddr (+size) is within userland memory (0x20000000), the kernel now (with [[6.0.0-11]]) returns an error when the address is beyond userland memory. Using an address >=0x20000000 would result in the kernel reading from the process L1 MMU table, beyond the memory allocated for that MMU table(for vaddr->physaddr conversion). <br />
| <br />
| [[6.0.0-11]]<br />
| <br />
| DmaConfig issue: unknown. The rest: 2014<br />
| [[User:Plutooo|plutoo]], [[User:Yellows8|Yellows8]] independently<br />
|-<br />
| [[SVC|svcControlMemory]] Parameter checks<br />
| For svcControlMemory the parameter check had these two flaws:<br />
<br />
* The allowed range for addr0, addr1, size parameters depends on which MemoryOperation is being specified. The limitation for GSP heap was only checked if op=(u32)0x10003. By setting a random bit in op that has no meaning (like bit17?), op would instead be (u32)0x30003, and the range-check would be less strict and not accurate. However, the kernel doesn't actually use the input address for LINEAR memory-mapping at all besides the range-checks, so this isn't actually useful. This was fixed in the kernel by just checking for the LINEAR bit, instead of comparing the entire MemoryOperation value with 0x10003.<br />
<br />
* Integer overflows on (addr0+size) are now checked that previously weren't (this also applies to most other address checks elsewhere in the kernel).<br />
<br />
| <br />
| [[5.0.0-11]]<br />
| <br />
|<br />
| [[User:Plutooo|plutoo]]<br />
|-<br />
| [[RPC_Command_Structure|Command]] request/response buffer overflow<br />
| Originally the kernel did not check the word-values from the command-header. Starting with [[5.0.0-11]], the kernel will trigger a kernelpanic() when the total word-size of the entire command(including the cmd-header) is larger than 0x40-words (0x100-bytes). This allows overwriting threadlocalstorage+0x180 in the destination thread. However, since the data written there would be translate parameters (such as header-words + buffer addresses), exploiting this would likely be very difficult, if possible at all.<br />
<br />
If the two words at threadlocalstorage+0x180 could be overwritten with controlled data this way, one could then use a command with a buffer-header of <nowiki>((size<<14) | 2)</nowiki> to write arbitrary memory to any RW userland memory in the destination process.<br />
| <br />
| [[5.0.0-11]]<br />
| <br />
| v4.1 FIRM -> v5.0 code diff<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[SVC|SVC stack allocation overflows]]<br />
| <br />
* Syscalls that allocate a variable-length array on stack, only checked bit31 before multiplying by 4/16 (when calculating how much memory to allocate). If a large integer was passed as input to one of these syscalls, an integer overflow would occur, and too little memory would have been allocated on stack resulting in a buffer overrun. <br />
* The alignment (size+7)&~7 calculation before allocation was not checked for integer overflow.<br />
<br />
This might allow for ARM11 kernel code-execution.<br />
<br />
(Applies to svcSetResourceLimitValues, svcGetThreadList, svcGetProcessList, svcReplyAndReceive, svcWaitSynchronizationN.)<br />
| <br />
| [[5.0.0-11]]<br />
| <br />
| v4.1 FIRM -> v5.0 code diff<br />
| [[User:Plutooo|plutoo]], [[User:Yellows8|Yellows8]] complementary<br />
|-<br />
| [[SVC|svcControlMemory]] MemoryOperation MAP memory-permissions<br />
| svcControlMemory with MemoryOperation=MAP allows mapping the already-mapped process virtual-mem at addr1, to addr0. The lowest address permitted for addr1 is 0x00100000. Originally the ARM11 kernel didn't check memory permissions for addr1. Therefore .text as addr1 could be mapped elsewhere as RW- memory, which allowed ARM11 userland code-execution.<br />
| <br />
| [[4.1.0-8]]<br />
| <br />
| 2012<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[RPC_Command_Structure|Command]] input/output buffer permissions<br />
| Originally the ARM11 kernel didn't check memory permissions for the input/output buffers for commands. Starting with [[4.0.0-7]] the ARM11 kernel will trigger a kernelpanic() if the input/output buffers don't have the required memory permissions. For example, this allowed a FSUSER file-read to .text, which therefore allowed ARM11-userland code execution.<br />
| <br />
| [[4.0.0-7]]<br />
| <br />
| 2012<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[SVC|svcReadProcessMemory/svcWriteProcessMemory memory]] permissions<br />
| Originally the kernel only checked the first page(0x1000-bytes) of the src/dst buffers, for svcReadProcessMemory and svcWriteProcessMemory. There is no known retail processes which have access to these SVCs.<br />
| <br />
| [[4.0.0-7]]<br />
| <br />
| 2012?<br />
| [[User:Yellows8|Yellows8]]<br />
|}<br />
<br />
=== [[FIRM]] Sysmodules ===<br />
{| class="wikitable" border="1"<br />
|-<br />
! Summary<br />
! Description<br />
! Successful exploitation result<br />
! Fixed in [[FIRM]] system version<br />
! Last [[FIRM]] system version this flaw was checked for<br />
! Timeframe this was discovered<br />
! Discovered by<br />
|-<br />
| [[Services|"srv:pm"]] process registration<br />
| Originally any process had access to the port "srv:pm". The PID's used for the (un)registration commands are not checked either. This allowed any process to re-register itself with "srv:pm", and therefore allowed the process to give itself access to any service, bypassing the exheader service-access-control list.<br />
<br />
This was fixed in [[7.0.0-13]]: starting with [[7.0.0-13]] "srv:pm" is now a service instead of a globally accessible port. Only processes with PID's less than 6 (in other words: fs, ldr, sm, pm, pxi modules) have access to it. With [[7.0.0-13]] there can only be one session for "srv:pm" open at a time(this is used by pm module), svcBreak will be executed if more sessions are opened by the processes which can access this.<br />
<br />
This flaw was needed for exploiting the <=v4.x Process9 PXI vulnerabilities from ARM11 userland ROP, since most applications don't have access to those service(s).<br />
| Access to arbitrary services<br />
| [[7.0.0-13]]<br />
| <br />
| 2012<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| FSDIR null-deref<br />
| [[Filesystem_services|FS]]-module may crash in some cases when handling directory reading. The trigger seems to be due to using [[FSDir:Close]] without closing the dir-handle afterwards?(Perhaps this is caused by out-of-memory?) This seems to be useless since it's just a null-deref.<br />
| <br />
| None<br />
| [[9.6.0-24|9.6.0-X]]<br />
| May 19(?)-20, 2015<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[SM]] out-of-bounds BSS write (table 1 entry too small)<br />
| After accepting a new session, [[SM]] writes a (handler ID (0 for srv: sessions (max. 64), 1 for the srv:pm one), pointer to session context structure in BSS) pair in a global array. However that array is only 64-entry-big instead of 65 (as it ought to be), and no bound check is done in that regard.<br />
<br />
Unfortunately, as of [[11.4.0-37]], the overwritten fields are totally unused after their initialization by <code>__libc_init_array</code>.<br />
| Not currently exploitable<br />
| None<br />
| [[11.4.0-37]]<br />
|<br />
|<br />
|}<br />
<br />
=== Standalone Sysmodules ===<br />
{| class="wikitable" border="1"<br />
|-<br />
! Summary<br />
! Description<br />
! Successful exploitation result<br />
! Fixed in system-module system-version<br />
! Last system-module system-version this flaw was checked for<br />
! Timeframe this was discovered<br />
! Timeframe this was added to wiki<br />
! Discovered by<br />
|-<br />
| [[MP:SendDataFrame]] missing input array index validation<br />
| [[MP:SendDataFrame]] doesn't validate the input index at cmdreq[1], unless the function for flag=non-zero is executed. This is used to calculate the following, without validating the index at all: someptr = stateptr + (index*0x924) + somestateoffset.<br />
<br />
After validating some flags from someptr, when input_flag=0 the input buffer data is copied to someptr+someotheroffset+0x14 with the u16 size loaded from someptr+someotheroffset.<br />
<br />
With a large input index someptr could be setup to be at a <target address>, for overwriting memory.<br />
<br />
This is probably difficult to exploit.<br />
| <br />
| None<br />
| [[8.0.0-18]](MP-sysmodule v2048)<br />
| January 22, 2017<br />
| January 22, 2017<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[MP_Services|MP]] cmd1 out-of-bounds handle read<br />
| MP-sysmodule handles the input parameter for cmd1 as a s32. It checks for >=16, but not <0. With <16 it basically does the following(array of entries 4-bytes each): *outhandle = ((Handle*)(stateptr+offsetinstate))[inputindex].<br />
<br />
Hence, this can be used to load any handle in MP-sysmodule memory. MP doesn't really have any service handles of interest however(can be obtained from elsewhere too).<br />
| Reading any handle in MP-sysmodule memory.<br />
| None<br />
| [[8.0.0-18]](MP-sysmodule v2048)<br />
| January 21, 2017<br />
| January 22, 2017<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| AM stack/.bss infoleak via [[AM:ReadTwlBackupInfo]]([[AM:ReadTwlBackupInfoEx|Ex]])<br />
| After writing the output-info structure to stack, it then copies that structure to the output buffer ptr using the size from the command. The size is not checked. This could be used to read data from the AM-service-thread stack handling the command + .bss.<br />
<br />
'''This was not tested on hardware.'''<br />
| Stack/.bss reading<br />
| None<br />
| [[10.0.0-27]](AM v9217)<br />
| Roughly October 17, 2016<br />
| October 25, 2016<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[MVD_Services|MVD]]: Stack buffer overflow with [[MVDSTD:SetupOutputBuffers]].<br />
| The input total_entries is not validated when initially processing the input entry-list. This fixed-size input entry-list is copied to stack from the command request. The loop for processing this initializes a global table, the converted linearmem->physaddrs used there are also copied to stack(0x8-bytes of physaddrs per entry).<br />
<br />
If total_entries is too large, MVD-sysmodule will crash due to reading unmapped memory following the stack(0x10000000). Afterwards if the out-of-bounds total_entries is smaller than that, it will crash due accessing address 0x0, hence this useless.<br />
| MVD-sysmodule crash.<br />
| None<br />
| [[9.0.0-20]]<br />
| April 22, 2016 (Tested on the 25th)<br />
| April 25, 2016<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[NWM_Services|NWM]]: Using CTRSDK heap with UDS sharedmem from the user-process.<br />
| See the HTTP-sysmodule section below.<br />
<br />
CTRSDK heap is used with the sharedmem from [[NWMUDS:InitializeWithVersion]]. Buffers are allocated/freed under this heap using [[NWMUDS:Bind]] and [[NWMUDS:Unbind]].<br />
<br />
Hence, overwriting sharedmem with gspwn then using [[NWMUDS:Unbind]] results in the usual controlled CTRSDK memchunk-header write, similar to HTTP-sysmodule.<br />
<br />
This could be done by creating an UDS network, without any other nodes on the network.<br />
<br />
Besides CTRSDK memchunk-headers, there are no addresses stored under this sharedmem.<br />
| ROP under NWM-module.<br />
| [[11.4.0-37|11.4.0-X]]<br />
| [[9.0.0-20|9.0.0-X]]<br />
| April 10, 2016<br />
| April 16, 2016<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[DLP_Services|DLP]]: Out-of-bounds memory access during spectator [[Download_Play|data-frame]] checksum calculation<br />
| DLP doesn't validate the frame_size when receiving spectator data-frames at all, unlike non-spectator data-frames. The actual spectator data-frame parsing code doesn't use that field either. However, the data-frame checksum calculation code called during checksum verification does use the frame_size for loading the size of the framebuf.<br />
<br />
Hence, using a large frame_size like 0xFFFF will result in the checksum calculation code reading data out-of-bounds. This isn't really useful, you could trigger a remote local-WLAN DLP-sysmodule crash while a 3DS system is scanning for DLP networks(due to accessing unmapped memory), but that's about all(trying to infoleak with this likely isn't useful either).<br />
| DLP-sysmodule crash, handled by dlplay system-application by a "connection interrupted" error eventually then a fatal-error via ErrDisp.<br />
| None<br />
| [[10.0.0-27|10.0.0-X]]<br />
| April 8, 2016 (Tested on the 10th)<br />
| April 10, 2016<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[DLP_Services|DLP]]: Out-of-bounds output data writing during spectator sysupdate titlelist [[Download_Play|data-frame]] handling<br />
| The total_entries and out_entryindex fields for the titlelist DLP spectator data-frames are not validated. This is parsed during DLP network scanning. Hence, the specified titlelist data can be written out-of-bounds using the specified out_entryindex and total_entries. A crash will occur while reading the input data-frame titlelist if total_entries is larger than 0x27A, due to accessing unmapped memory.<br />
<br />
There's not much non-zero data to overwrite following the output buffer(located in sharedmem), any ptrs are located in sharedmem. Overwriting certain ptr(s) are only known to cause a crash when attempting to use the DLP-client shutdown service-command.<br />
<br />
There's no known way to exploit the above crash, since the linked-list code involves writes zeros(with a controlled start ptr).<br />
| <br />
| None<br />
| [[10.0.0-27|10.0.0-X]]<br />
| April 8-9, 2016<br />
| April 10, 2016<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[IR_Services|IR]]: Stack buffer overflow with custom hardware<br />
| Originally IR sysmodule used the read value from the I2C-IR registers TXLVL and RXLVL without validating them at all. See [[10.6.0-31|here]] for the fix. This is the size used for reading the data-recv FIFO, etc. The output buffer for reading is located on the stack.<br />
<br />
This should be exploitable if one could successfully setup the custom hardware for this and if the entire intended sizes actually get read from I2C.<br />
| ROP under IR sysmodule.<br />
| [[10.6.0-31|10.6.0-31]]<br />
| <br />
| February 23, 2016 (Unknown if it was noticed before then)<br />
| February 23, 2016<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[HTTP_Services|HTTP]]: Using CTRSDK heap with sharedmem from the user-process.<br />
| The data from httpcAddPostDataAscii and other commands is stored under a CTRSDK heap. That heap is the sharedmem specified by the user-process via the HTTPC Initialize command.<br />
Normally this sharedmem isn't accessible to the user-process once the sysmodule maps it, hence using it is supposed to be "safe".<br />
<br />
This isn't the case due to gspwn however. Since CTRSDK heap code is so insecure in general, one can use gspwn to locate the HTTPC sharedmem + read/write it, then trigger a mem-write under the sysmodule. This can then be used to get ROP going under HTTP-sysmodule.<br />
<br />
This is exploited by [https://github.com/yellows8/ctr-httpwn/ctr-httpwn ctr-httpwn].<br />
| ROP under HTTP sysmdule.<br />
| [[11.4.0-37|11.4.0-X]]<br />
| [[9.6.0-24|9.6.0-X]] (Latest sysmodule version as of [[10.7.0-32|10.7.0-32]])<br />
| Late 2015<br />
| March 22, 2016<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[NIM_Services|NIM]]: Downloading old title-versions from eShop<br />
| Multiple NIM service commands(such as [[NIMS:StartDownload]]) use a title-version value specified by the user-process, NIM does not validate that this input version matches the latest version available via SOAP. Therefore, when combined with AM(PXI) [[#Process9|title-downgrading]] via deleting the target eShop title with System Settings Data Management(if the title was already installed), this allows downloading+installing any title-version from eShop ''if'' it's still available from CDN.<br />
The easiest way to exploit this is to just patch the eShop system-application code using these NIM commands(ideally the code which loads the title-version).<br />
<br />
Originally this was tested with a debugging-system via modded-FIRM, eventually smea implemented it in HANS for the 32c3 release.<br />
| Downloading old title-versions from eShop<br />
| None<br />
| [[10.0.0-27|10.0.0-X]]<br />
| October 24, 2015 (Unknown when exactly the first eShop title downgrade was actually tested, maybe November)<br />
| January 7, 2016 (Same day Ironfall v1.0 was removed from CDN via the main-CXI files)<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[SPI_Services|SPI]] service out-of-bounds write<br />
| cmd1 has out-of-bounds write allowing overwrite of some static variables in .data.<br />
| <br />
| None<br />
| [[9.5.0-22]]<br />
| March 2015<br />
| <br />
| [[User:Plutooo|plutoo]]<br />
|-<br />
| [[NFC_Services|NFC]] module service command buf-overflows<br />
| NFC module copies data with certain commands, from command input buffers to stack without checking the size. These commands include the following, it's unknown if there's more commands with similar issues: "nfc:dev" <0x000C....> and "nfc:s" <0x0037....>.<br />
Since both of these commands are stubbed in the Old3DS NFC module from the very first version(those just return an error), these issues only affect the New3DS NFC module.<br />
<br />
There's no known retail titles which have access to either of these services.<br />
| ROP under NFC module.<br />
| New3DS: None<br />
| New3DS: [[9.5.0-22]]<br />
| December 2014?<br />
| <br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[News_Services|NEWSS]] service command notificationID validation failure<br />
| This module does not validate the input notificationID for <nowiki>"news:s"</nowiki> service commands. This is an out-of-bounds array index bug. For example, [[NEWSS:SetNotificationHeader]] could be used to exploit news module: this copies the input data(size is properly checked) to: out = newsdb_savedata+0x10 + (someu32array[notificationID]*0x70).<br />
| ROP under news module.<br />
| None<br />
| [[9.7.0-25|9.7.0-X]]<br />
| December 2014<br />
| <br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[NWMUDS:DecryptBeaconData]] heap buffer overflow<br />
| input_size = 0x1E * <value the u8 from input_[[NWM_Services|networkstruct]]+0x1D>. Then input_tag0 is copied to a heap buffer. When input_size is larger than 0xFA-bytes, it will then copy input_tag1 to <end_address_of_previous_outbuf>, with size=input_size-0xFA.<br />
<br />
This can be triggered by either using this command directly, or by boadcasting a wifi beacon which triggers it while a 3DS system running the target process is in range, when the process is scanning for hosts to connect to. Processes will only pass tag data to this command when the wlancommID and other thing(s) match the values for the process.<br />
<br />
There's no known way to actually exploit this for getting ROP under NWM-module, at the time of originally adding this to the wiki. This is because the data which gets copied out-of-bounds *and* actually causes crash(es), can't be controlled it seems(with just broadcasting a beacon at least). It's unknown whether this could be exploited from just using NWMUDS service-cmd(s) directly.<br />
| Without any actual way to exploit this: NWM-module DoS, resulting in process termination(process crash). This breaks *everything* involving wifi comms, a reboot is required to recover from this.<br />
| None<br />
| [[9.0.0-20]]<br />
| ~September 23, 2014(see the [[NWMUDS:DecryptBeaconData]] page history)<br />
| August 3, 2015<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[HID_Services|HID]] module shared-mem<br />
| HID module does not validate the index values in [[HID_Shared_Memory|sharedmem]](just changes index to 0 when index == maxval when updating), therefore large values will result in HID module writing HID data to arbitrary addresses.<br />
| ROP under HID module, but this is *very* unlikely to be exploitable since the data written is HID data.<br />
| None<br />
| [[9.3.0-21]]<br />
| 2014?<br />
| <br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| gspwn<br />
| GSP module does not validate addresses given to the GPU. This allows a user-mode application/applet to read/write to a large part of physical FCRAM using GPU DMA. From this, you can overwrite the .text segment of the application you're running under, and gain real code-execution from a ROP-chain. Normally applets' .text([[Home Menu]], [[Internet Browser]], etc) is located beyond the area accessible by the GPU, except for [[RO_Services|CROs]] used by applets([[Internet Browser]] for example).<br />
<br />
FCRAM is gpu-accessible up to physaddr 0x26800000 on Old3DS, and 0x2D800000 on New3DS. This is BASE_memregion_start(aka SYSTEM_memregion_end)-0x400000 (0x800000 with New3DS) with the default memory-layout on Old3DS/New3DS. With [[11.3.0-36|11.3.0-X]] the cutoff now varies due to the new [[SVC]] 0x59. The New3DS "normal"(non-APPLICATION) cutoff was changed to 0x2D000000 due to the new [[SVC]] 0x59.<br />
| User-mode code execution.<br />
| None<br />
| [[9.6.0-24|9.6.0-X]]<br />
| Early 2014<br />
| <br />
| smea, [[User:Yellows8|Yellows8]]/others before then<br />
|-<br />
| rohax<br />
| Using gspwn, it is possible to overwrite a loaded [[CRO0]]/[[CRR0]] after its RSA-signature has been validated. Badly validated [[CRO0]] header leads to arbitrary read/write of memory in the ro-process. This gives code-execution in the ro module, who has access to [[SVC|syscalls]] 0x70-0x72, 0x7D.<br />
<br />
This was fixed after [[ninjhax]] release by adding checks on [[CRO0]]-based pointers before writing to them.<br />
| Memory-mapping syscalls.<br />
| [[9.3.0-21]]<br />
| [[9.4.0-21]]<br />
| <br />
| <br />
| smea, [[User:Plutooo|plutoo]] joint effort<br />
|-<br />
| Region free<br />
| Only [[Home Menu]] itself checks gamecards' region when launching them. Therefore, any application launch that is done directly with [[NS]] without signaling Home Menu to launch the app, will result in region checks being bypassed.<br />
This essentially means launching the gamecard with the [[NS_and_APT_Services|"ns:s"]] service. The main way to exploit this is to trigger a FIRM launch with an application specified, either with a normal FIRM launch or a hardware [[NSS:RebootSystem|reboot]].<br />
| Launching gamecards from any region + bypassing Home Menu gamecard-sysupdate installation<br />
| None<br />
| Last tested with [[10.1.0-27|10.1.0-X]].<br />
| June(?) 2014<br />
| <br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[NWM_Services|NWM]] service-cmd state null-ptr deref<br />
| The NWMUDS service command code loads a ptr from .data, adds an offset to that, then passes that as the state address for the actual command-handler function. The value of the ptr loaded from .data is not checked, therefore this will cause crashes due to that being 0x0 when NWMUDS was not properly initialized.<br />
It's unknown whether any NWM services besides NWMUDS have this issue.<br />
| This is rather useless since it's only a crash caused by a state ptr based at 0x0.<br />
| None<br />
| [[9.0.0-20]]<br />
| 2013?<br />
| <br />
| [[User:Yellows8|Yellows8]]<br />
|}<br />
<br />
=== General/CTRSDK ===<br />
{| class="wikitable" border="1"<br />
|-<br />
! Summary<br />
! Description<br />
! Successful exploitation result<br />
! Fixed in version<br />
! Last version this flaw was checked for<br />
! Timeframe this was discovered<br />
! Discovered by<br />
|-<br />
| [[NWM_Services|UDS]] beacon additional-data buffer overflow<br />
| Originally CTRSDK did not validate the UDS additional-data size before using that size to copy the additional-data to a [[NWM_Services|networkstruct]]. This was eventually fixed.<br />
This was discovered while doing code RE with an old dlp-module version. It's unknown in what specific CTRSDK version this was fixed, or even what system-version updated titles with a fixed version.<br />
<br />
It's unknown if there's any titles using a vulnerable CTRSDK version which are also exploitable with this(dlp module can't be exploited with this).<br />
<br />
The maximum number of bytes that can be written beyond the end of the outbuf is 0x37-bytes, with additionaldata_size=0xFF.<br />
| Perhaps ROP, very difficult if possible with anything at all<br />
| ?<br />
| <br />
| September(?) 2014<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| CTPK buffer overflow<br />
| At offset 0x20 in CTPK is an array for each texture, each entry is 0x20-bytes. This contains a wordindex(entry+0x18) for some srcdata relative to CTPK+0, and an u8 wordsize(entry+0x14) for this data. The CTRSDK function handling this doesn't validate the size, when copying srcdata using this size to the output buffer. Applications usually have the output buffer on the stack, hence stack buffer overflow.<br />
<br />
While CTPK(*.ctpk) are normally only loaded from RomFS, some application(s) load from elsewhere too.<br />
| ROP under the target application.<br />
| None?<br />
| "[SDK+NINTENDO:CTR_SDK-11_4_0_200_none]"<br />
| November 14, 2016<br />
| [[User:Yellows8|Yellows8]]<br />
|}</div>Myriahttps://www.3dbrew.org/w/index.php?title=3DS_System_Flaws&diff=208103DS System Flaws2018-08-12T05:44:18Z<p>Myria: /* arm9loader */ arm9loader runs on Old3DS</p>
<hr />
<div>Exploits are used to execute unofficial code (homebrew) on the Nintendo 3DS. This page is a list of publicly known system flaws, for userland applications/applets flaws see [[3DS_Userland_Flaws|here]].<br />
<br />
=Stale / Rejected Efforts=<br />
* Neimod has been working on a RAM dumping setup for a little while now. He's de-soldered the 3DS's RAM chip and hooked it and the RAM pinouts on the 3DS' PCB up to a custom RAM dumping setup. A while ago he published photos showing his setup to be working quite well, with the 3DS successfully booting up. However, his flickr stream is now private along with most of his work.<br />
<br />
* Someone (who will remain unnamed) has released CFW and CIA installers, all of which is copied from the work of others, or copyrighted material.<br />
<br />
==Tips and info==<br />
The 3DS uses the XN feature of the ARM11 processor. There's no official way from applications to enable executable permission for memory containing arbitrary unsigned code(there's a [[SVC]] for this, but only [[RO_Services|RO-module]] has access to it). A usable userland exploit would still be useful: you could only do return-oriented-programming with it initially. From ROP one could then exploit system flaw(s), see below.<br />
<br />
SD card [[extdata]] and SD savegames can be attacked, for consoles where the console-unique [[Nand/private/movable.sed|movable.sed]] was dumped(accessing SD data is far easier by running code on the target 3DS however).<br />
<br />
=System flaws=<br />
== Hardware ==<br />
{| class="wikitable" border="1"<br />
! Summary<br />
! Description<br />
! Fixed with hardware model/revision<br />
! Newest hardware model/revision this flaw was checked for<br />
! Timeframe this was discovered<br />
! Discovered by<br />
|-<br />
| ARM9/ARM11 bootrom vectors point at uninitialized RAM<br />
| ARM9's and ARM11's exception vectors are hardcoded to point at the CPU's internal memory (0x08000000 region for ARM9, AXIWRAM for ARM11). While the bootrom does set them up to point to an endless loop at some point during boot, it does not do so immediately. As such, a carefully-timed fault injection (via hardware) to trigger an exception (such as an invalid instruction) will cause execution to fall into ARM9 RAM. <br />
Since RAM isn't cleared on boot (see below), one can immediately start execution of their own code here to dump bootrom, OTP, etc.<br />
The ARM9 bootrom does the following at reset: reset vector branches to another instruction, then branches to bootrom+0x8000. Hence, there's no way to know for certain when exactly the ARM9 exception-vector data stored in memory gets initialized.<br />
<br />
This requires *very* *precise* timing for triggering the hardware fault.<br />
<br />
It has been exploited by derrek to dump the ARM9 bootrom as of Summer 2015.<br />
| None: all available 3DS models at the time of writing have the exact same ARM9/ARM11 bootrom for the unprotected areas.<br />
| New3DS<br />
| End of February 2014<br />
| [[User:Derrek|derrek]], WulfyStylez (May 2015) independently<br />
|-<br />
| Missing AES key clearing<br />
| The hardware AES engine does not clear keys when doing a hard reset/reboot.<br />
| None<br />
| New3DS<br />
| August 2014<br />
| Mathieulh/Others<br />
|-<br />
| No RAM clearing on reboots<br />
| On an MCU-triggered reboot all RAM including FCRAM/ARM9 memory/AXIWRAM/VRAM keeps its contents.<br />
| None<br />
| New3DS<br />
| March 2014<br />
| [[User:Derrek|derrek]]<br />
|-<br />
| 32bits of actual console-unique TWLNAND keydata<br />
| On retail the 8-bytes at ARM9 address [[Memory_layout|0x01FFB808]] are XORed with hard-coded data, to generate the TWL console-unique keys, including TWLNAND. On Old3DS the high u32 is always 0x0, while on New3DS that u32 is always 0x2. On top of this, the lower u32's highest bit is always ORed. only 31 bits of the TWL console-unique keydata / TWL consoleID are actually console-unique.<br />
This allows one to easily bruteforce the TWL console-unique keydata with *just* data from TWLNAND. On DSi the actual console-unique data for key generation is 8-bytes(all bytes actually set).<br />
| None<br />
| New3DS<br />
| 2012?<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| DSi / 3DS-TWL key-generator<br />
| After using the key generator to generate the normal-key, you could overwrite parts of the normal-key with your own data and then recover the key-generator output by comparing the new crypto output with the original crypto output. From the normal-key outputs, you could deduce the TWL key-generator function.<br />
This applies to the keyX/keyY too.<br />
<br />
This attack does not work for the 3DS key-generator because keyslots 0-3 are only for TWL keys.<br />
| None<br />
| New3DS<br />
| 2011<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| 3DS key-generator<br />
| The algorithm for generating the normal-keys for keyslots is cryptographically weak. As a result, it is easily susceptible to differential cryptanalysis if the normal-key corresponding to any scrambler-generated keyslot is discovered.<br />
<br />
Several such pairs of matching normal-keys and KeyY values were found, leading to deducing the key-generator function.<br />
| None<br />
| New3DS<br />
| February 2015<br />
| [[User:Yellows8|Yellows8]], [[User:Plutooo|plutoo]]<br />
|-<br />
| RSA keyslots don't clear exponent when setting modulus<br />
| The [[RSA_Registers|RSA keyslots]] are set by boot ROM to have four private RSA keys. The exponent value in the RSA registers is write-only and not readable.<br />
<br />
However, when setting a keyslot's modulus, the RSA hardware leaves the exponent alone. This allows retrieving the exponent by doing a discrete logarithm of the output.<br />
<br />
By setting the modulus to a prime number whose modular multiplicative order is "smooth" (that is, p-1 is divisible by only small prime numbers), discrete logarithms can be calculated quickly using the [[wikipedia:Pohlig-Hellman algorithm|Pohlig-Hellman algorithm]]. If the prime chosen is greater than the modulus, but the same bit size, the discrete logarithm is the private exponent.<br />
<br />
This exploit's usefulness is limited: RSA keyslot 0 is only used in current firmware for deriving the 6.x save and 7.x NCCH keys, which were already known, and the other three keyslots are entirely unused. Additionally, with a boot ROM dump, this exploit is moot; these private keys are located in the protected ARM9 boot ROM.<br />
| None<br />
| New3DS<br />
| March 2016<br />
| [[User:Myria|Myria]]<br />
|-<br />
| [[CONFIG11_Registers#CFG11_GPUPROT|CFG11_GPUPROT]] allowing acccess to AXIWRAM/FCRAM-BASE-memregion<br />
| [[CONFIG11_Registers#CFG11_GPUPROT|CFG11_GPUPROT]] can be configured by anything with access to it to allow the GPU to access the entire AXIWRAM+FCRAM. For example, this is an issue for any sysmodule that gets exploited and has access to this register memory-page(include one that's listed below).<br />
<br />
See also "kernelhax via gspwn" below.<br />
| None<br />
| New3DS<br />
| February 7, 2017<br />
| [[User:Yellows8|Yellows8]]<br />
|}<br />
<br />
== Boot ROM ==<br />
{| class="wikitable" border="1"<br />
! Summary<br />
! Description<br />
! Fixed with hardware model/revision<br />
! Newest hardware model/revision this flaw was checked for<br />
! Timeframe this was discovered<br />
! Discovered by<br />
|-<br />
| FIRM partitions known-plaintext<br />
| The [[Flash_Filesystem|FIRM partitions]] are encrypted with AES-CTR without a MAC. Since this works by XOR'ing data with a static (per-console in this case) keystream, one can deduce the keystream of a portion of each FIRM partition if they have the actual FIRM binary stored in it.<br />
<br />
This can be paired with many exploits. For example, it allows minor FIRM downgrades (i.e. 10.4 to 9.6 or 9.5 to 9.4, but not 9.6 to 9.5).<br />
However it is most commonly used to install arbitrary FIRMs (usually boot9strap), thanks to sighax.<br />
<br />
This can be somewhat addressed by having a FIRM header skip over previously used section offsets, but this would just air-gap newer FIRMs without fixing the core bug. This can also only be done a limited number of times due to the size of FIRM versus the size of the partitions.<br />
| None<br />
| New3DS<br />
| <br />
| Everyone<br />
|-<br />
| Boot9 AES keyinit function issues<br />
| [[Bootloader|Boot9]] seems to have two bugs in the AES key-init function, see [[AES_Registers#AES_key-init|here]].<br />
| None<br />
| BootROM issue.<br />
| 2015<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| New3DS has same boot ROM as Old3DS<br />
| The New3DS has the exact same boot ROM as the Old3DS. This means, among other things, that all the same boot ROM flaws are present. Also, this meant that it is possible to boot Old3DS firmware on New3DS (see "CFG_SYSPROT9 bit1 not set by Kernel9").<br />
| None<br />
| New3DS<br />
| October 2014<br />
| Everyone<br />
|-<br />
| sighax: Boot9 improper validation of FIRM partition RSA signatures<br />
| The [[Flash_Filesystem|FIRM partitions]] are signed with RSA-2048 using SHA-256 and PKCS #1 v1.5 padding. Boot9, however, improperly validates the padding in three ways:<br />
# Boot9 permits block type 02, meant for encrypted messages, to be used for signatures. Only 01, for signatures, should have been permitted. As a result, when using block type 02, a signature block is not required to have a long string of FF bytes as padding, but rather any nonzero random values suffice.<br />
# Boot9 does not require that the length of the padding fill out the signature block completely. As a result, there is considerable freedom in the layout of a signature.<br />
# Boot9 fails to do bounds checking in its parsing of the DER-encoded hash algorithm type and hash value; the length values given in DER are permitted to point outside the signature block.<br />
Flaw 3 allows the DER encoding to be such that boot9 believes that the signature's hash value is outside the range of the block itself, somewhere on the stack. This can be pointed at the correct hash value it computes. Boot9 then memcmp's the calculated hash against itself, and thinks that the hash is valid.<br />
<br />
As a result of the above, we estimate that one in 2<sup>43</sup> (~8.8 trillion) random fake signatures will be considered by Boot9 to be valid. This is well within the range of brute force, particularly with an optimized GPU implementation. An Nvidia GTX 1080 Ti would take about one week to find a match.<br />
| None<br />
| New3DS<br />
| July 2015<br />
| [[User:Derrek|derrek]]<br />
|-<br />
| Boot9 FIRM loading doesn't blacklist memory-mapped I/O<br />
| [[Bootloader|Boot9]]'s FIRM loading blacklists Boot9 data regions, but forgets to do other important regions, including Memory-mapped I/O. Combined with sighax, by loading a malicious FIRM section to MMIO, one can get Boot9/Boot11 code execution. <br />
| None<br />
| New3DS<br />
| 2015(?)<br />
| [[User:Derrek|derrek]] (2015?), [[User:Normmatt|Normmatt]] and [[User:SciresM|SciresM]] independently (January 2017).<br />
|-<br />
| "superhax": Boot9 FIRM loading blacklist check is flawed<br />
| Boot9 only makes sure the '''start''' and '''end''' address of each section is not covered by a blacklisted region. Thus, it is possible to overwrite blacklisted regions (e.g. ARM9 Exception Vectors) by choosing a FIRM section range that encloses an entire blacklisted region. The vulnerable code looks like this: if(blRegions[i].start <= sectionStart && blRegions[i].end > sectionStart <nowiki>||</nowiki> blRegions[i].start <= sectionEnd && blRegions[i].end > sectionEnd) return false; // failure<br />
| None<br />
| New3DS<br />
| August 2015<br />
| [[User:Plutoo|plutoo]], [[User:Yellows8|yellows8]]<br />
|}<br />
<br />
== ARM9 software ==<br />
<br />
=== arm9loader ===<br />
{| class="wikitable" border="1"<br />
|-<br />
! Summary<br />
! Description<br />
! Successful exploitation result<br />
! Fixed in [[FIRM]] system version<br />
! Last [[FIRM]] system version this flaw was checked for<br />
! Timeframe this was discovered<br />
! Public disclosure timeframe<br />
! Discovered by<br />
|-<br />
| Generating the keysector console-unique keys with ITCM+Boot9<br />
| [[Bootloader|Boot9]] decrypts the 0x100-byte [[OTP_Registers|OTP]] using AES-CBC with keydata stored in Boot9. If hash verification is successful, the plaintext of the first 0x90-bytes are copied into [[Memory_layout|ITCM]]. This is the ''exact'' ''same'' region hashed by arm9loader when generating the console-unique keys for decrypting the keysector, except arm9loader uses the raw encrypted OTP.<br />
<br />
Therefore, with the OTP keydata+IV from Boot9 you can: encrypt the 0x90-bytes from ITCM, then hash the output to get the console-unique keys for the system's keysector. This can even be done for Old3DS which doesn't have the arm9loader keysector officially.<br />
<br />
It's unknown why arm9loader only used the first 0x90-bytes of OTP. Using more data from OTP would've prevented this. Fixing this would require doing exactly that, but that would also mean updating the NAND keysector(which is dangerous).<br />
| See description.<br />
| None<br />
| <br />
| 2015<br />
| January 6, 2017<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| Rearrangable keys in the NAND keystore<br />
| Due to the keystore being encrypted with AES-ECB, one can rearrange blocks and still have the NAND keystore decrypt in a deterministic way. <br />
<br />
Using 10.0 FIRM it is possible to rearrange keys such that ARM9 memory is executed. As such using existing ARM9 execution 10.0 FIRM can be written to NAND and a payload written to memory, with the payload to be executed post-K9L using an MCU reboot.<br />
| arm9loaderhax given existing ARM9 code execution<br />
| None<br />
| [[11.3.0-36|11.3.0-X]]<br />
| Early 2016<br />
| 27 September 2016<br />
| Myria, [[User:Dark samus|dark_samus]]; mathieulh (independently); [[User:Plutooo|plutoo]] (independently) + others<br />
|-<br />
| Uncleared OTP hash keydata in console-unique 0x11 key-generation<br />
| Kernel9Loader does not clear the [[SHA_Registers#SHA_HASH|SHA_HASH register]] after use. As a result, the data stored here as K9L hands over to Kernel9 is the hash of [[OTP_Registers|OTP data]] used to seed the [[FIRM#New_3DS_FIRM|console-unique NAND keystore decryption key]] set on keyslot 0x11.<br />
<br />
Retrieving this keydata and the [[Flash_Filesystem#0x12C00|NAND keystore]] of the same device allows calculating the decrypted New3DS NAND keystore (non-unique, common to all New3DS units), which contains AES normal keys, also set on keyslot 0x11, which are then used to derive all current [[AES_Registers#Keyslots|New3DS-only AES keyXs]] including the newer batch introduced in [[9.6.0-24#arm9loader|9.6.0-X]]. From there, it is trivial to perform the same key derivation in order to initialize those keys on any system version, and even on Old3DS.<br />
<br />
This can be performed by exploiting the "arm9loaderhax" vulnerability to obtain post-K9L code execution after an MCU reboot (the bootrom section-loading fail is not relevant here, this attack was performed without OTP data by brute-forcing keys), and using this to dump the SHA_HASH register. This attack works on any FIRM version shipping a vulnerable version of K9L, whereas OTP dumping required a boot of <[[3.0.0-6|3.0.0-X]].<br />
<br />
This attack results in obtaining the entire (0x200-bytes) NAND keystore - it was confirmed at a later date that this keystore is encrypted with the same key (by comparing the decrypted data from multiple units), and therefore using another key in this store will not remedy the issue as all keys are known (i.e. later, unused keys decrypt to the same 0x200-bytes constant with the same OTP hash). Later keys could have been encrypted differently but this is not the case. As a result of this, it is not possible for Nintendo to use K9L again in its current format for its intended purpose, though this was not news from the moment people dumped a New3DS OTP.<br />
| Derivation of all New3DS keys generated via the NAND keystore (0x1B "Secure4" etc.)<br />
| None<br />
| [[11.3.0-36|11.3.0-X]]<br />
| ~April 2015, implemented in May 2015<br />
| 13 January 2016<br />
| [[User:WulfyStylez|WulfyStylez]], [[User:Dazzozo|Dazzozo]], [[User:Shinyquagsire23|shinyquagsire23]] (complimentary + implemented), [[User:Plutooo|plutoo]], Normmatt (discovered independently)<br />
|-<br />
| enhanced-arm9loaderhax<br />
| See the 32c3 3ds talk.<br />
Since this is a combination of a trick with the arm9-bootrom + arm9loaderhax, and since you have to manually write FIRM to the firm0/firm1 NAND partitions, this can't be completely fixed. Any system with existing ARM9 code execution and an OTP/OTP hash dump can exploit this. Additionally, by using the FIRM partition known-plaintext bug and bruteforcing the second entry in the keystore, this can currently be exploited on all New3DS systems without any other prerequisite hacks.<br />
| arm9loaderhax which automatically occurs at hard-boot.<br />
| See arm9loaderhax / description.<br />
| See arm9loaderhax / description.<br />
| Theorized around mid July, 2015. Later implemented+tested by [[User:Plutooo|plutoo]] and [[User:Derrek|derrek]].<br />
| 32c3 3ds talk (December 27, 2015)<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| Missing verification-block for the 9.6 keys (arm9loaderhax)<br />
| Starting with [[9.6.0-24|9.6.0-X]] a new set of NAND-based keys were introduced. However, no verification block was added to verify that the new key read from NAND is correct. This was technically an issue from [[9.5.0-22|9.5.0-X]] with the original sector+0 keydata, however the below is only possible with [[9.6.0-24|9.6.0-X]] since keyslots 0x15 and 0x16 are generated from different 0x11 keyXs.<br />
<br />
Writing an incorrect key to NAND will cause arm9loader to decrypt the ARM9 kernel as garbage and then jump to it.<br />
<br />
This allows an hardware-based attack where you can boot into an older exploited firmware, fill all memory with NOP sleds/jump-instructions, and then reboot into executing garbage. By automating this process with various input keydata, eventually you'll find some garbage that jumps to your code.<br />
<br />
This gives very early ARM9 code execution (pre-ARM9 kernel). As such, it is possible to dump RSA keyslots with this and calculate the 6.x [[Savegames#6.0.0-11_Savegame_keyY|save]], and 7.x [[NCCH]] keys. This cannot be used to recover keys initialized by arm9loader itself. This is due to it wiping the area used for its stack during NAND sector decryption and keyslot init. <br />
<br />
Due to FIRMs on both Old and New 3DS using the same RSA data, this can be exploited on Old3DS as well, but only if one already has the actual plaintext normalkey from New3DS NAND sector 0x96 offset-0 and has dumped the OTP area of the Old3DS.<br />
| Recovery of 6.x [[Savegames#6.0.0-11_Savegame_keyY|save key]]/7.x [[NCCH]] key, access to uncleared OTP hash keydata<br />
| None<br />
| [[11.3.0-36|11.3.0-X]]<br />
| March 2015<br />
| <br />
| [[User:Plutooo|plutoo]]<br />
|-<br />
| arm9loader runs on Old3DS<br />
| Despite being written only for New3DS, all of arm9loader runs fine on Old3DS. It's not until booting Kernel9 that a New3DS FIRM partition would crash on an Old3DS. As a result, if a bug exists in arm9loader to get control, it can be exploited on Old3DS by writing New3DS FIRM to the FIRM partitions. Thus, arm9loaderhax works on both Old3DS and New3DS.<br />
| arm9loader bugs also compromise Old3DS<br />
| None<br />
| [[11.3.0-36|11.3.0-X]]<br />
| March 2015<br />
| [[User:Plutooo|plutoo]] first, probably<br />
|-<br />
| Uncleared New3DS keyslot 0x11<br />
| Originally the New3DS [[FIRM]] arm9bin loader only cleared keyslot 0x11 when it gets executed at firmlaunch. This was fixed with [[9.5.0-22|9.5.0-X]] by completely clearing keyslot 0x11 immediately after the loader finishes using keyslot 0x11.<br />
This means that any ARM9 code that can execute before the loader clears the keyslot at firmlaunch(including firmlaunch-hax) can get access to the uncleared keyslot 0x11, which then allows one to generate all <=v9.5 New3DS keyXs which are generated by keyslot 0x11.<br />
<br />
Therefore, to completely fix this the loader would have to generate more keys using different keyslot 0x11 keydata. This was done with [[9.6.0-24|9.6.0-X]].<br />
| New3DS keyXs generation<br />
| Mostly fixed with [[9.5.0-22|9.5.0-X]], completely fixed with new keys with [[9.6.0-24|9.6.0-X]].<br />
| <br />
| February 3, 2015 (one day after [[9.5.0-22|9.5.0-X]] release)<br />
| <br />
| [[User:Yellows8|Yellows8]]<br />
|}<br />
<br />
=== Process9 ===<br />
{| class="wikitable" border="1"<br />
|-<br />
! Summary<br />
! Description<br />
! Successful exploitation result<br />
! Fixed in [[FIRM]] system version<br />
! Last [[FIRM]] system version this flaw was checked for<br />
! Timeframe this was discovered<br />
! Public disclosure timeframe<br />
! Discovered by<br />
|-<br />
| Leak of normal-key matching a key-scrambler key<br />
| New 3DS firmware versions [[8.1.0-0 New3DS|8.1.0]] through [[9.2.0-20|9.2.0]] set the encryption key for [[Amiibo]] data using a hardcoded normal-key in Process9. In firmware [[9.3.0-21|9.3.0]], Nintendo "fixed" this by using the key scrambler instead, by calculating the keyY value for keyslot 0x39 that results in the same normal-key, then hardcoding that keyY into Process9.<br />
<br />
Nintendo's fix is actually the problem: Nintendo revealed the normal-key matching an unknown keyX and a known keyY. Combined with the key scrambler using an insecure scrambling algorithm (see "Hardware" above), the key scrambler function could be deduced.<br />
| Deducing the keyX for keyslot 0x39 and the key scrambler algorithm<br />
| New 3DS [[9.3.0-21|9.3.0-X]], sort of<br />
| [[10.0.0-27|10.0.0-X]]<br />
| Sometime in 2015 after the hardware key-generator was broken.<br />
| 32c3 3ds talk (December 27, 2015)<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| Leak of normal-key matching a key-generator key<br />
| During the 3DS' development (June/July 2010) Nintendo added support installing encrypted content ([[CIA]]). Common-key index1 was intended to be a [[AES|hardware generated key]]. However while they added code to generate the key in hardware, they forgot to remove the normal-key for index1 (used elsewhere, likely old debug code). Nintendo later removed the normal key sometime before the first non-prototype firmware release.<br />
<br />
Knowing the keyY and the normal-key for common-key index1, the devkit key-generator algorithm can be deduced (see "Hardware" above). Additionally the remaining devkit common-keys can be generated once the common-key keyX is recovered.<br />
<br />
Note that the devkit key-generator was discovered to be the same as the retail key-generator.<br />
| Deducing the keyX for keyslot 0x3D and hardware key-generator algorithm. Generate remaining devkit common-keys.<br />
| pre-[[1.0.0-0|1.0.0-X]]<br />
| <br />
| Shortly after the key-generator was revealed to be flawed at the 32c3 3ds talk<br />
| January 20, 2016<br />
| [[User:Jakcron|jakcron]]<br />
|-<br />
| Factory firmware is vulnerable to sighax<br />
| During the 3DS's development, presumably boot9 was written (including the sighax) vulnerability. This vulnerability is also present in factory firmware (and earlier, including 0.11). This was fixed in version 1.0.0-0.<br />
| Deducing the mechanics of the sighax vulnerability in boot9 without having boot9 prot. Arm9 code execution on factory/earlier firmware.<br />
| [[1.0.0-0|1.0.0-X]]<br />
| [[1.0.0-0|1.0.0-X]]<br />
| May 9, 2017<br />
| May 19, 2017<br />
| [[User:SciresM|SciresM]], [[User:Myria|Myria]]<br />
|-<br />
| safefirmhax<br />
| SAFE_MODE_FIRM is almost never updated(even when NATIVE_FIRM is updated for vuln fixes), this can be noticed by ''just'' checking 3dbrew/ninupdates title-listings.<br />
<br />
The fix for 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 <=> Kernel11 sync, PXI sync and then repeat the original attack on SAFE_FIRM instead.<br />
| ARM9 code execution<br />
| [[11.3.0-36|11.3.0-X]]<br />
| <br />
| 2012-2013?<br />
| Wiki: January 2, 2017<br />
| Everyone<br />
|-<br />
| safefirmhax 1.1<br />
| Nintendo's original safefirmhax fix was flawed -- they added a global boolean that got set to true whenever a non-sysmodule title got launched (except for a hardcoded repair title id), and panic()'d if that boolean was true to prevent launching safefirm after hax was active. However, because the boolean was initially false after firmlaunch -- With ARM11-kernel execution, one could FIRM-launch into NATIVE_FIRM, and then immediately FIRM-launch again into SAFE_FIRM early in NATIVE_FIRM boot before the boolean got set to true to repeat the safehax attack.<br />
<br />
This was fixed by adding additional CFG9_BOOTENV checks to firmlaunch code in 11.4.<br />
| ARM9 code execution<br />
| [[11.4.0-37|11.4.0-X]]<br />
| <br />
| safefirmhax fix<br />
| Wiki: April 10, 2017<br />
| Everyone<br />
|-<br />
| ntrcardhax<br />
| When reading the banner of a NTR title, Process9 relies on a hardware register to know when the banner was fully read.<br />
However that register is shared between the ARM9 and the ARM11.<br />
An attacker with k11 control can so make Process9 believe the banner continues forever and so trigger a buffer overflow.<br />
With a custom banner for a NTR flashcart, this leads to code execution in Process9.<br />
<br />
This was fixed by adding bound checks on the read data.<br />
| ARM9 code execution<br />
| [[10.4.0-29|10.4.0-X]]<br />
| <br />
| March 2015<br />
| 32c3 3ds talk (December 27, 2015)<br />
| [[User:Plutooo|plutoo]]<br />
|-<br />
| Title downgrading via [[Application_Manager_Services|AM]]([[Application_Manager_Services_PXI|PXI]])<br />
| When a title is *already* installed, Process9 will compare the installed title-version with the title-version being installed. When the one being installed is older, Process9 would return an error.<br />
<br />
However, this can be bypassed by just deleting the title first via the service command(s) for that: with the title removed from the [[Title_Database]], Process9 can't compare the input title-version with anything. Hence, titles can be downgraded this way.<br />
<br />
[[11.0.0-33|11.0.0-X]] fixed this for key system titles (MSET, Home Menu, spider, ErrDisp, SKATER, NATIVE_FIRM, and every retail system module), by checking the version of the title to install against a hard-coded list of (titleID, minimumVersionRequired) pairs.<br />
| Bypassing title version check at installation, which then allows downgrading any title.<br />
| [[11.0.0-33|11.0.0-X]], for key system titles.<br />
| NATIVE_FIRM / AM-sysmodule [[11.0.0-33|11.0.0-X]]<br />
| ?<br />
| <br />
| ?<br />
|-<br />
| Anti-downgrade list did not include all system titles initially<br />
| The anti-downgrade list did not include legacy FIRMs until [[11.8.0-41|11.8.0-X]]. Therefore, legacy FIRMs could still be downgraded.<br />
| Downgrading legacy FIRMs; allowing to exploit bugs in older legacy FIRMs (of which at least one exists, see below).<br />
| [[11.8.0-33|11.8.0]]<br />
| [[11.8.0-33|11.8.0]]<br />
| ?<br />
| Wiki: August 5, 2018<br />
| Everyone<br />
|-<br />
| TWL_FIRM cmd-9 unchecked offset<br />
| In [[1.0.0-0|1.0.0-X]]'s TWL_FIRM, cmds 8 and 9 were not stubbed (whereas in the corresponding NATIVE_FIRM, they were).<br />
Command 8 does the Process9 initialisation for NTR carts if an NTR cart is inserted (NTR, not TWL, judged by chipid).<br />
<br />
Command 9 takes (u32 offset_read, u32 offset_write, u32 offset_read_end), and basically just copies (offset_read_end - offset_read) bytes starting at (offset_read) of [NTR cart header in arm9mem, NTR secure area in fcram, TWL secure area in fcram], to 0x18001000 + offset_write + offset_read.<br />
<br />
offset_write is not checked at all, thus this leads to ARM9 code execution as long as any NTR cart, including flashcarts that would normally be blocked by TWL_FIRM, is inserted.<br />
<br />
In [[2.0.0-2|2.0.0-X]] TWL_FIRM, those commands were stubbed out.<br />
| ARM9 code execution<br />
| [[2.0.0-2|2.0.0-X]]<br />
| [[2.0.0-2|2.0.0-X]]<br />
| January 2018<br />
| Wiki: August 5, 2018<br />
| [[User:Riley|Riley]]<br />
|-<br />
| FAT FS code null-deref<br />
| When FSFile:Read is used with a file which is corrupted on a FAT filesystem(in particular SD), Process9 can crash. This particular crash is caused by a function returning NULL instead of an actual ptr due to an error. The caller of that function doesn't check for NULL which then triggers a read based at NULL.<br />
<br />
Sample "fsck.vfat -n -v -V <fat image backup>" output for the above crash:<br />
<br />
<pre>...<br />
Starting check/repair pass.<br />
<FilePath0> and<br />
<FilePath1><br />
share clusters.<br />
Truncating second to 3375104 bytes.<br />
<FilePath1><br />
File size is 2787392 bytes, cluster chain length is 16384 bytes.<br />
Truncating file to 16384 bytes.<br />
Checking for unused clusters.<br />
Reclaimed 1 unused cluster (16384 bytes).<br />
Checking free cluster summary.<br />
Free cluster summary wrong (1404490 vs. really 1404491)<br />
Auto-correcting.<br />
Starting verification pass.<br />
Checking for unused clusters.<br />
Leaving filesystem unchanged.</pre><br />
| Useless null-based-read<br />
| None<br />
| [[9.6.0-24|9.6.0-X]]<br />
| July 8-9, 2015<br />
| <br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| RSA signature padding checks<br />
| The TWL_FIRM RSA sig padding check code used for all TWL RSA sig-checks has issues, see [[FIRM|here]].<br />
The main 3DS RSA padding check code(non-certificate, including NATIVE_FIRM) uses the function used with the above to extract more padding + the actual hash from the additional padding. This isn't really a problem here because there's proper padding check code which is executed prior to this.<br />
| <br />
| None<br />
| [[9.5.0-22|9.5.0-X]]<br />
| March 2015<br />
| <br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[AMPXI:ValidateDSiWareSectionMAC]] [[AES_Registers|AES]] keyslot reuse<br />
| When the input DSiWare section index is higher than <max number of DSiWare sections supported by this FIRM>, Process9 uses keyid 0x40 for calculating the AESMAC, which translates to keyslot 0x40. The result is that the keyslot is left at whatever was already selected before, since the AES selectkeyslot code will immediately return when keyslot is >=0x40. However, actually exploiting this is difficult: the calculated AESMAC is never returned, this command just compares the calculated AESMAC with the input AESMAC(result-code depends on whether the AESMACs match). It's unknown whether a timing attack would work with this.<br />
This is basically a different form of the pxips9 keyslot vuln, except with AESMAC etc.<br />
| See description.<br />
| None<br />
| [[11.3.0-36|11.3.0-X]]<br />
| March 15, 2015<br />
| December 29, 2015<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| pxips9 [[AES_Registers|AES]] keyslot reuse<br />
| This requires access to the [[Process_Services|ps:ps]]/pxi:ps9 services. One way to get access to this would be snshax on system-version <=10.1.0-X(see 32c3 3ds talk).<br />
When an invalid key-type value is passed to any of the PS commands, Process9 will try to select keyslot 0x40. That aesengine_setkeyslot() code will then immediately return due to the invalid keyslot value. Since that function doesn't return any errors, Process9 will just continue to do crypto with whatever AES keyslot was selected before the PS command was sent.<br />
| Reusing the previously used keyslot, for crypto with PS.<br />
| None<br />
| [[11.3.0-36|11.3.0-X]]<br />
| Roughly the same time(same day?) as firmlaunch-hax.<br />
| December 29, 2015<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| firmlaunch-hax: FIRM header ToCToU<br />
| This can't be exploited from ARM11 userland.<br />
During [[FIRM]] launch, the only FIRM header the ARM9 uses at all is stored in FCRAM, this is 0x200-bytes(the actual used FIRM RSA signature is read to the Process9 stack however). The ARM9 doesn't expect "anything" besides the ARM9 to access this data.<br />
With [[9.5.0-22]] the address of this FIRM header was changed from a FCRAM address, to ARM9-only address 0x01fffc00.<br />
| ARM9 code execution<br />
| [[9.5.0-22]]<br />
| <br />
| 2012, 3 days after [[User:Yellows8|Yellows8]] started Process9 code RE.<br />
| <br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| Uninitialized data output for (PXI) command replies<br />
| PXI commands for various services(including some [[Filesystem_services_PXI|here]] and many others) can write uninitialized data (like from ARM registers) to the command reply. This happens with stubbed commands, but this can also occur with certain commands when returning an error.<br />
Certain ARM11 service commands have this same issue as well.<br />
| <br />
| None<br />
| [[9.3.0-21|9.3.0-X]]<br />
| ?<br />
| <br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[Filesystem_services_PXI|FSPXI]] OpenArchive SD permissions<br />
| Process9 does not use the exheader ARM9 access-mount permission flag for SD at all.<br />
This would mean ARM11-kernelmode code / fs-module itself could directly use FSPXI to access SD card without ARM9 checking for SD access, but this is rather useless since a process is usually running with SD access(Home Menu for example) anyway.<br />
| <br />
| None<br />
| [[9.3.0-21|9.3.0-X]]<br />
| 2012<br />
| <br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[AMPXI:ExportDSiWare]] export path<br />
| Process9 allocates memory on Process9 heap for the export path then verifies that the actual allocated size matches the input size. Then Process9 copies the input path from FCRAM to this buffer, and uses it with the Process9 FS openfile code, which use paths in the form of "<mountpoint>:/<path>".<br />
Process9 does not check the contents of this path at all before passing it to the FS code, besides writing a NUL-terminator to the end of the buffer.<br />
| Exporting of DSiWare to arbitrary Process9 file-paths, such as "nand:/<path>" etc. This isn't really useful since the data which gets written can't be controlled.<br />
| None<br />
| [[9.5.0-22]]<br />
| April 2013<br />
| <br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[DSiWare_Exports]] [[CTCert]] verification<br />
| Just like DSi originally did, 3DS verifies the APCert for DSiWare on SD with the CTCert also in the DSiWare .bin. On DSi this was fixed with with system-version 1.4.2 by verifying with the actual console-unique cert instead(stored in NAND), while on 3DS it's still not(?) fixed.<br />
On 3DS however this is useless, unless one can obtain the console-unique movable.sed keyY which encrypts the entire DSiWare .bin.<br />
| When the movable.sed keyY for the target 3DS is known and the target 3DS CTCert private-key is unknown, importing of modified DSiWare SD .bin files.<br />
| None.<br />
| 11.6.0-X<br />
| April 2013<br />
| <br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| seedminer: movable.sed keyY vulnerable to brute-force<br />
| Half of the movable.sed keyY's 128 bits are leaked through the [[Nandrw/sys/LocalFriendCodeSeed_B|LFCS]], which is available in userland and below. The LFCS itself also leaks almost half of the remaining bits by following the ratio: u32 keyY[3]=1/5(LFCS). The remaining keyY[3] uncertainty of about ±2000 can be greatly reduced by plotting expected error margins with several keyYs. This results in a final uncertainty of about 2^40, easily within practical brute force range of an average modern PC.<br />
| Knowing the keyY of a given 3ds allows for modification of DSiWare export contents, and chained with several other public vulns, ultimately arm9 execution.<br />
| None.<br />
| 11.6.0-X<br />
| December 2017<br />
| January 2018<br />
| zoogie<br />
|-<br />
| Improper validation of DSiWare title SRLs<br />
| The 3DS does not verify if the actual SRL embedded in the title's directory matches the titleID in the TMD before launching it or importing it from an sd DSiWare export. <br />
| This allows embedding older, exploitable DSiWare titles in completely different, unexploitable DSiWare titles. Since DSiWare has raw NAND RW, this can result in arm9 control through FIRM known-plaintext and sighax attacks.<br />
| None.<br />
| 11.6.0-X<br />
| 2015?<br />
| December 2016<br />
| Everyone<br />
|-<br />
| [[Gamecard_Services_PXI]] unchecked REG_CTRCARDCNT transfer-size<br />
| The u8 REG_CTRCARDCNT transfer-size parameter for the [[Gamecard_Services_PXI]] read/write CTRCARD commands is used as an index for an array of u16 values. Before [[5.0.0-11|5.0.0-X]] this u8 value wasn't checked, thus out-of-bounds reads could be triggered(which is rather useless in this case).<br />
| Out-of-bounds read for a value which gets written to a register.<br />
| [[5.0.0-11|5.0.0-X]]<br />
| <br />
| 2013?<br />
| <br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[PXI_Registers|PXI]] cmdbuf buffer overrun<br />
| The Process9 code responsible [[PXI_Registers|PXI]] communications didn't verify the size of the incoming command before writing it to a C++ member variable. <br />
| Probably ARM9 code execution<br />
| [[5.0.0-11|5.0.0-11]]<br />
| <br />
| March 2015, original timeframe if any unknown<br />
| <br />
| [[User:Plutooo|plutoo]]/[[User:Yellows8|Yellows8]]/maybe others(?)<br />
|-<br />
| [[Application_Manager_Services_PXI|PXIAM]] command 0x003D0108(See also [[Application_Manager_Services|this]])<br />
| When handling this command, Process9 allocates a 0x2800-byte heap buffer, then copies the 4 FCRAM input buffers to this heap buffer without checking the sizes at all(only the buffers with non-zero sizes are copied). Starting with [[5.0.0-11|5.0.0-X]], the total combined size of the input data must be <=0x2800.<br />
| ARM9 code execution<br />
| [[5.0.0-11|5.0.0-X]]<br />
| <br />
| May 2013<br />
| <br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[Process_Services_PXI|PS RSA]] commands buffer overflows<br />
| pxips9 cmd1(not accessible via ps:ps) and VerifyRsaSha256: unchecked copy to a buffer in Process9's .bss, from the input FCRAM buffer. The buffer is located before the pxi cmdhandler threads' stacks. SignRsaSha256 also has a buf overflow, but this isn't exploitable.<br />
The buffer for this is the buffer for the signature data. With v5.0, the signature buffer was moved to stack, with a check for the signature data size. When the signature data size is too large, Process9 uses [[SVC|svcBreak]].<br />
| ARM9 code execution<br />
| [[5.0.0-11|5.0.0-X]]<br />
| <br />
| 2012<br />
| <br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[PXI_Registers|PXI]] pxi_id bad check<br />
| The Process9 code responsible for [[PXI_Registers|PXI]] communications read pxi_id as a signed char. There were two flaws:<br />
* They used it as index to a lookup-table without checking the value at all.<br />
* Another function verified that pxi_id < 7, allowing negative values to pass the check. This would also cause an out-of-range table-lookup.<br />
| Maybe ARM9 code execution<br />
| [[3.0.0-5|3.0.0-5]]<br />
|<br />
| March 2015, originally 2012 for the first issue at least<br />
| <br />
| [[User:Plutooo|plutoo]], [[User:Yellows8|Yellows8]], maybe others(?)<br />
|}<br />
<br />
=== Kernel9 ===<br />
{| class="wikitable" border="1"<br />
|-<br />
! Summary<br />
! Description<br />
! Successful exploitation result<br />
! Fixed in [[FIRM]] system version<br />
! Last [[FIRM]] system version this flaw was checked for<br />
! Timeframe this was discovered<br />
! Discovered by<br />
|-<br />
| [[CONFIG Registers#CFG_SYSPROT9|CFG_SYSPROT9]] bit1 not set by Kernel9<br />
| Old versions of Kernel9 never set bit1 of [[CONFIG Registers#CFG_SYSPROT9|CFG_SYSPROT9]]. This leaves the [[OTP Registers|0x10012000]]-region unprotected (this region should be locked early during boot!). Since it's never locked, you can dump it once you get ARM9 code execution.<br />
<br />
From [[3.0.0-5|3.0.0-X]] this was fixed by setting the bit in Kernel9 after poking some registers in that region. On New3DS arm9loader sets this bit instead of Kernel9, which is exploitable through a hardware + software vulnerability (see arm9loaderhax / description).<br />
<br />
This flaw resurged when it gained a new practical use: retrieving the OTP data for a New3DS console in order to decrypt the key data used in arm9loader (see enhanced-arm9loaderhax / description). This was performed by downgrading to a vulnerable system version. By accounting for differences in CTR-NAND crypto (0x05 -> 0x04, see partition encryption types [[Flash_Filesystem#NAND_structure|here]]) and using an Old3DS [[NCSD#NCSD_header|NCSD Header]], it is possible to boot a New3DS using Old3DS firmware 1.0-2.x to retrieve the required OTP data using this flaw.<br />
| Dumping the [[OTP Registers|OTP]] area.<br />
Decrypting New3DS sector 0x96 keyblock.<br />
| [[3.0.0-5|3.0.0-X]]<br />
|<br />
| February 2015<br />
| [[User:Plutooo|plutoo]], Normmatt independently<br />
|}<br />
<br />
== ARM11 software ==<br />
=== Kernel11 ===<br />
{| class="wikitable" border="1"<br />
|-<br />
! Summary<br />
! Description<br />
! Successful exploitation result<br />
! Fixed in [[FIRM]] system version<br />
! Last [[FIRM]] system version this flaw was checked for<br />
! Timeframe this was discovered<br />
! Discovered by<br />
|-<br />
| [[SVC|svcSetProcessIdealProcessor]] reference count overflow and therefore use-after-free.<br />
| The SVC receive two arguments: handle and idealprocessor. The handle is used to get the KProcess object and the KProcess->refCnt gets incremented,later the function check if the KProcess->mem_type != BASE and if yes, it checks for idealprocessor == 2 or idealprocessor != 3. The problem here is that if you pass the idealprocessor = 3 it won't meet any condition and return the error 0xD9001BEA without decrement the reference count. <br />
It can be abused to overflow the KProcess reference count that will lead to an Use-after-free. <br />
| Before [[11.2.0-35|11.2.0-X]]: reference count overflow and therefore use-after-free.<br />
| <br />
| [[11.6.0-39|11.6.0-X]]<br />
| November 2, 2017<br />
| [[User:st4rk|st4rk]]<br />
|-<br />
| [[SVC|svcGetThreadList]] process reference leak<br />
| When given a valid process handle (including <code>0xFFFF8001</code>), svcGetThreadList forgets to decrement the reference count of the underlying [[KProcess]] instance, after having finished using it.<br />
| Before [[11.2.0-35|11.2.0-X]]: reference count overflow and therefore use-after-free, but this UAF was most likely not exploitable<br />
| <br />
| [[11.3.0-36|11.3.0-X]]<br />
| April 3, 2017<br />
| [[User:TuxSH|TuxSH]]<br />
|-<br />
| kernelhax via gspwn<br />
| Originally the kernel didn't initialize [[CONFIG11_Registers#CFG11_GPUPROT|CFG11_GPUPROT]]. Since it's 0 at hard-boot, this allowed the GPU to access the entire FCRAM + AXIWRAM.<br />
| Entire FCRAM+AXIWRAM R/W.<br />
| [[3.0.0-5|3.0.0-X]]<br />
| <br />
| February 7, 2017<br />
| [[User:Plutooo|plutoo]], [[User:Yellows8|Yellows8]] partly<br />
|-<br />
| fasthax<br />
| When a KTimer is created in pulse mode, the kernel calls a virtual function to reset the timer each time it pulses. The scheduler is locked for that core to avoid race conditions, but another core can call CloseHandle on the timer and free it, leading to a UAF vtable call.<br />
| See description.<br />
| [[11.3.0-36|11.3.0-X]]<br />
| [[11.3.0-36|11.3.0-X]]<br />
| May 2016<br />
| nedwill<br />
|-<br />
| ipctakeover<br />
| When sending cmdreplies, it does not validate that the src_addr and src_size match the equivalent dst_addr and dst_size. With a modified addr/size specified in a cmdreply for an output buffer, the data-copy for the first/last pages could be used to overwrite data outside of the buffer specified by the original process.<br />
<br />
Used by ctr-httpwn as of v1.2, for "ipctakeover/bosshaxx".<br />
<br />
This can be used to takeover processes where the process is using your service session. Like HTTPC -> BOSS, for bosshaxx above. NIM takeover can be done too(actual stack buffer overflow can trigger), etc.<br />
| See description.<br />
| None<br />
| [[11.3.0-36|11.3.0-X]]<br />
| November 26, 2016<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| Using IPC input buffers as output buffers<br />
| When sending cmdreplies, it does not validate that the cmdreply descriptor type matches the equivalent cmdreq descriptor type. This could be used by an exploited sysmodule to use what was intended as an input-buffer as an output-buffer, and also combine other IPC vuln(s) with this.<br />
<br />
Used by ctr-httpwn as of v1.2, for "ipctakeover/bosshaxx".<br />
| See description.<br />
| None<br />
| [[11.3.0-36|11.3.0-X]]<br />
| November 2016<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[SVC]] table too small<br />
| The table of function pointers for SVC's only contains entries up to 0x7D, but the biggest allowed SVC for the table is 0x7F. Thus, executing SVC7E or SVC7F would make the SVC-handler read after the buffer, and interpret some ARM instructions as function pointers.<br />
<br />
However, this would require patching the kernel .text or modifying SVC-access-control. Even if you could get these to execute, they would still jump to memory that isn't mapped as executable.<br />
| <br />
| None<br />
| [[11.3.0-36|11.3.0-X]]<br />
| 2012<br />
| Everyone<br />
|-<br />
| [[SVC|svcBackdoor (0x7B)]]<br />
| This backdoor allows executing SVC-mode code at the user-specified code-address. This is used by Process9, using this on the ARM11 (with NATIVE_FIRM) required patching the kernel .text or modifying SVC-access-control.<br />
| See description<br />
| [[11.0.0-33|11.0.0-X]] (deleted)<br />
| <br />
|<br />
| Everyone<br />
|-<br />
| veryslowpidhax<br />
| '''This is completely different from the kernelmode-code-execution vuln described in the below separate entry.'''<br />
<br />
When updating the kernel global PID counter under [[SVC|svcCreateProcess]] the kernel does not check for wraparound to 0x0(the PID for the very first process). This only matters because [[Services|SM-module]] allows processes with PID value less than <total ARM11 FIRM modules> to access ''all'' services, without checking exheader service-access-control; and because Kernel11 checks for the PID to be 1 (loader) to use the input mem-region value on ControlMemory. This alone does not affect access the [[SVC|SVCs]] access table at all.<br />
<br />
Inlined ldrex+strex code is used for updating the above counter. [[11.2.0-35|11.2.0-X]] had changes for similar code, but it was only for dedicated ldrex+strex functions(mainly for kernel objects) and hence this PID code was not affected.<br />
<br />
With launching+terminating a sysmodule repeatedly with this via ns:s, it would take weeks to finish(if not at least about a month?).<br />
| Access to all [[Services_API|services]], ControlMemory on any given mem-region.<br />
| None<br />
| [[11.3.0-36|11.3.0-X]]<br />
| 2012 maybe?<br />
| <br />
|-<br />
| slowhax/waithax<br />
| svcWaitSynchronizationN does not decrement the references to valid handles in an array before returning an error when it encounters an invalid handle. This allows one to (slowly) overflow the reference count for a handle object to zero.<br />
| ARM11 kernel-mode code execution<br />
| [[11.2.0-35|11.2.0-X]]<br />
| [[11.2.0-35|11.2.0-X]]<br />
| 2016<br />
| nedwill, [[User:Derrek|derrek]]<br />
|-<br />
| [[Memory_layout#ARM11_Detailed_virtual_memory_map|0xEFF00000]] / 0xDFF00000 ARM11 kernel virtual-memory<br />
| The ARM11 kernel-mode 0xEFF00000/0xDFF00000 virtual-memory(size 0x100000) is mapped to phys-mem 0x1FF00000(entire DSP-mem + entire AXIWRAM), with permissions RW-. This is used during ARM11 kernel startup for loading the FIRM-modules from the FIRM section located in DSP-mem, this never seems to be used after that, however. This is never unmapped either.<br />
| <br />
| None<br />
| [[11.3.0-36|11.3.0-X]]<br />
| <br />
| <br />
|-<br />
| memchunkhax2.1<br />
| Nintendo's fix for memchunkhax2 in [[10.4.0-29|10.4.0-X]] did not fix the GPU case: one may cause the requisite ToCToU race using gspwn, bypassing the new validation.<br />
derrek's original 32c3 presentation for memchunkhax2 commented that a GPU-based attack was possible, but would be difficult. However, memchunkhax2.1 showed that it was possible to do fairly reliably.<br />
| ARM11 kernel code execution<br />
| [[11.0.0-33|11.0.0-X]], via the new [[Memory_Management#MemoryBlockHeader|memchunkhdr]] MAC which prevents modifying memchunkhdr data with DMA.<br />
| [[11.0.0-33|11.0.0-X]]<br />
|<br />
| [[User:Derrek|derrek]], aliaspider<br />
|-<br />
| memchunkhax2<br />
| When allocating a block of memory, the "next" pointer of the [[Memory_Management#MemoryBlockHeader|memchunkhdr]] is accessed without being checked after being mapped to userland.<br />
This allows a race condition, where the process can change the next pointer just before it's accessed. By pointing the next pointer to a crafted memchunckhdr in the kernel SlabHeap, some of the SlabHeap is allocated to the calling process, allowing to change vtables of kernel objects. <br />
| ARM11 kernel code execution<br />
| [[10.4.0-29|10.4.0-X]] (partially, see memchunkhax2.1)<br />
| [[10.4.0-29|10.4.0-X]]<br />
|<br />
| [[User:Derrek|derrek]]<br />
|-<br />
| heaphax<br />
| Can change the size of free memchunk structures stored in FCRAM using DMA, which leads to the ability to allocate memory chunks over already-allocated memory. This can be used in the SYSTEM region to allocate RW memory over any part of the NS system module, which is enough to take it over.<br />
| Code execution with access to all of NS's privileges. (including downgrading) Code execution within any applet.<br />
| [[11.0.0-33|11.0.0-X]], via the new [[Memory_Management#MemoryBlockHeader|memchunkhdr]] MAC which prevents modifying memchunkhdr data with DMA.<br />
| [[11.0.0-33|11.0.0-X]]<br />
| April 2015 ?<br />
| smea<br />
|-<br />
| snshax<br />
| Can force creation of Safe NS process into gspwn-able memory, allowing for takeover.<br />
| Code execution with access to all of NS's privileges. (including downgrading)<br />
| [[10.1.0-27|10.1.0-X]]<br />
| [[10.1.0-27|10.1.0-X]]<br />
| April 2015 ?<br />
| smea<br />
|-<br />
| AffinityMask/processorid validation<br />
| With [[10.0.0-27|10.0.0-X]] the following functions were updated: svcGetThreadAffinityMask, svcGetProcessAffinityMask, svcSetProcessAffinityMask, and svcCreateThread. The code changes for all but svcCreateThread are identical.<br />
The original code with the first 3 did the following: <br />
* if(u32_processorcount > ~0x80000001)return 0xe0e01bfd;<br />
* if(s32_processorcount > <total_cores>)return 0xd8e007fd;<br />
The following code replaced the above:<br />
* if(u32_processorcount >= <total_cores+1>)return 0xd8e007fd;<br />
In theory the latter should catch everything that the former did, so it's unknown if this was really a security issue.<br />
<br />
The svcCreateThread changes with [[10.0.0-27|10.0.0-X]] definitely did fix a security issue.<br />
* Original code: "if(s32_processorid > <total_cores>)return 0xd8e007fd;"<br />
* New code: "if(s32_processorid >= <total_cores> || s32_processorid <= -4)return 0xd8e007fd;"<br />
This fixed an off-by-one issue: if one would use processorid=total_cores, which isn't actually a valid value, svcCreateThread would accept that value on <[[10.0.0-27|10.0.0-X]]. This results in data being written out-of-bounds(baseaddr = arrayaddr + entrysize*processorid), which has the following result:<br />
* Old3DS: Useless kernel-mode crash due to accessing unmapped memory.<br />
* New3DS: uncontrolled data write into a kernel-mode L1 MMU-table. This isn't really useful: the data can't be controlled, and the data which gets overwritten is all-zero anyway(this isn't anywhere near MMU L1 entries for actually mapped memory).<br />
The previous version also allowed large negative s32_processorid values(negative processorid values are special values not actual procids), but it appears using values like that won't actually do anything(meaning no crash) besides the thread not running / thread not running for a while(besides triggering a kernelpanic with certain s32_processorid value(s)).<br />
| Nothing useful<br />
| [[10.0.0-27|10.0.0-X]]<br />
| [[10.0.0-27|10.0.0-X]]<br />
| svcCreateThread issue: May 31, 2015. The rest: September 8, 2015, via v9.6->v10.0 ARM11-kernel code-diff.<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| memchunkhax<br />
| The kernel originally did not validate the data stored in the FCRAM kernel heap [[Memchunkhdr|memchunk-headers]] for free-memory at all. Exploiting this requires raw R/W access to these memchunk-headers, like physical-memory access with gspwn.<br />
<br />
There are ''multiple'' ways to exploit this, but the end-result for most of these is the same: overwrite code in AXIWRAM via the 0xEFF00000/0xDFF00000 kernel virtual-memory mapping.<br />
<br />
This was fixed in [[9.3.0-21|9.3.0-X]] by checking that the memchunk(including size, next, and prev ptrs) is located within the currently used heap memory. The kernel may also check that the next/prev ptrs are valid compared to other memchunk-headers basically. When any of these checks fail, kernelpanic() is called.<br />
| When combined with other flaws: ARM11-kernelmode code execution<br />
| [[9.3.0-21|9.3.0-21]]<br />
| <br />
| February 2014<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| Multiple [[KLinkedListNode|KLinkedListNode]] SlabHeap use after free bugs<br />
| The ARM11-kernel did access the 'key' field of [[KLinkedListNode|KLinkedListNode]] objects, which are located on the SlabHeap, after freeing them. Thus, triggering an allocation of a new [[KLinkedListNode|KLinkedListNode]] object at the right time could result in a type-confusion. Pseudo-code:<br />
SlabHeap_free(KLinkedListNode);<br />
KObject *obj = KLinkedListNode->key; // the object there might have changed!<br />
This bug appeared all over the place.<br />
| ARM11-kernelmode code exec maybe<br />
| [[8.0.0-18|8.0.0-18]]<br />
| <br />
| April 2015<br />
| [[User:Derrek|derrek]]<br />
|-<br />
| PXI [[RPC_Command_Structure|Command]] input/output buffer permissions<br />
| Originally the ARM11-kernel didn't check permissions for PXI input/output buffers for commands. Starting with [[6.0.0-11|6.0.0]] PXI input/output buffers must have RW permissions, otherwise kernelpanic is triggered.<br />
| <br />
| [[6.0.0-11|6.0.0-11]]<br />
| <br />
| 2012<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[SVC|svcStartInterProcessDma]]<br />
| For svcStartInterProcessDma, the kernel code had the following flaws:<br />
<br />
* Originally the ARM11-kernel read the input DmaConfig structure directly in kernel-mode(ldr(b/h) instructions), without checking whether the DmaConfig address is readable under userland. This was fixed by copying that structure to the SVC-mode stack, using the ldrbt instruction.<br />
<br />
* Integer overflows for srcaddr+size and dstaddr+size are now checked(with [[6.0.0-11]]), which were not checked before.<br />
<br />
* The kernel now also checks whether the srcaddr/dstaddr (+size) is within userland memory (0x20000000), the kernel now (with [[6.0.0-11]]) returns an error when the address is beyond userland memory. Using an address >=0x20000000 would result in the kernel reading from the process L1 MMU table, beyond the memory allocated for that MMU table(for vaddr->physaddr conversion). <br />
| <br />
| [[6.0.0-11]]<br />
| <br />
| DmaConfig issue: unknown. The rest: 2014<br />
| [[User:Plutooo|plutoo]], [[User:Yellows8|Yellows8]] independently<br />
|-<br />
| [[SVC|svcControlMemory]] Parameter checks<br />
| For svcControlMemory the parameter check had these two flaws:<br />
<br />
* The allowed range for addr0, addr1, size parameters depends on which MemoryOperation is being specified. The limitation for GSP heap was only checked if op=(u32)0x10003. By setting a random bit in op that has no meaning (like bit17?), op would instead be (u32)0x30003, and the range-check would be less strict and not accurate. However, the kernel doesn't actually use the input address for LINEAR memory-mapping at all besides the range-checks, so this isn't actually useful. This was fixed in the kernel by just checking for the LINEAR bit, instead of comparing the entire MemoryOperation value with 0x10003.<br />
<br />
* Integer overflows on (addr0+size) are now checked that previously weren't (this also applies to most other address checks elsewhere in the kernel).<br />
<br />
| <br />
| [[5.0.0-11]]<br />
| <br />
|<br />
| [[User:Plutooo|plutoo]]<br />
|-<br />
| [[RPC_Command_Structure|Command]] request/response buffer overflow<br />
| Originally the kernel did not check the word-values from the command-header. Starting with [[5.0.0-11]], the kernel will trigger a kernelpanic() when the total word-size of the entire command(including the cmd-header) is larger than 0x40-words (0x100-bytes). This allows overwriting threadlocalstorage+0x180 in the destination thread. However, since the data written there would be translate parameters (such as header-words + buffer addresses), exploiting this would likely be very difficult, if possible at all.<br />
<br />
If the two words at threadlocalstorage+0x180 could be overwritten with controlled data this way, one could then use a command with a buffer-header of <nowiki>((size<<14) | 2)</nowiki> to write arbitrary memory to any RW userland memory in the destination process.<br />
| <br />
| [[5.0.0-11]]<br />
| <br />
| v4.1 FIRM -> v5.0 code diff<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[SVC|SVC stack allocation overflows]]<br />
| <br />
* Syscalls that allocate a variable-length array on stack, only checked bit31 before multiplying by 4/16 (when calculating how much memory to allocate). If a large integer was passed as input to one of these syscalls, an integer overflow would occur, and too little memory would have been allocated on stack resulting in a buffer overrun. <br />
* The alignment (size+7)&~7 calculation before allocation was not checked for integer overflow.<br />
<br />
This might allow for ARM11 kernel code-execution.<br />
<br />
(Applies to svcSetResourceLimitValues, svcGetThreadList, svcGetProcessList, svcReplyAndReceive, svcWaitSynchronizationN.)<br />
| <br />
| [[5.0.0-11]]<br />
| <br />
| v4.1 FIRM -> v5.0 code diff<br />
| [[User:Plutooo|plutoo]], [[User:Yellows8|Yellows8]] complementary<br />
|-<br />
| [[SVC|svcControlMemory]] MemoryOperation MAP memory-permissions<br />
| svcControlMemory with MemoryOperation=MAP allows mapping the already-mapped process virtual-mem at addr1, to addr0. The lowest address permitted for addr1 is 0x00100000. Originally the ARM11 kernel didn't check memory permissions for addr1. Therefore .text as addr1 could be mapped elsewhere as RW- memory, which allowed ARM11 userland code-execution.<br />
| <br />
| [[4.1.0-8]]<br />
| <br />
| 2012<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[RPC_Command_Structure|Command]] input/output buffer permissions<br />
| Originally the ARM11 kernel didn't check memory permissions for the input/output buffers for commands. Starting with [[4.0.0-7]] the ARM11 kernel will trigger a kernelpanic() if the input/output buffers don't have the required memory permissions. For example, this allowed a FSUSER file-read to .text, which therefore allowed ARM11-userland code execution.<br />
| <br />
| [[4.0.0-7]]<br />
| <br />
| 2012<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[SVC|svcReadProcessMemory/svcWriteProcessMemory memory]] permissions<br />
| Originally the kernel only checked the first page(0x1000-bytes) of the src/dst buffers, for svcReadProcessMemory and svcWriteProcessMemory. There is no known retail processes which have access to these SVCs.<br />
| <br />
| [[4.0.0-7]]<br />
| <br />
| 2012?<br />
| [[User:Yellows8|Yellows8]]<br />
|}<br />
<br />
=== [[FIRM]] Sysmodules ===<br />
{| class="wikitable" border="1"<br />
|-<br />
! Summary<br />
! Description<br />
! Successful exploitation result<br />
! Fixed in [[FIRM]] system version<br />
! Last [[FIRM]] system version this flaw was checked for<br />
! Timeframe this was discovered<br />
! Discovered by<br />
|-<br />
| [[Services|"srv:pm"]] process registration<br />
| Originally any process had access to the port "srv:pm". The PID's used for the (un)registration commands are not checked either. This allowed any process to re-register itself with "srv:pm", and therefore allowed the process to give itself access to any service, bypassing the exheader service-access-control list.<br />
<br />
This was fixed in [[7.0.0-13]]: starting with [[7.0.0-13]] "srv:pm" is now a service instead of a globally accessible port. Only processes with PID's less than 6 (in other words: fs, ldr, sm, pm, pxi modules) have access to it. With [[7.0.0-13]] there can only be one session for "srv:pm" open at a time(this is used by pm module), svcBreak will be executed if more sessions are opened by the processes which can access this.<br />
<br />
This flaw was needed for exploiting the <=v4.x Process9 PXI vulnerabilities from ARM11 userland ROP, since most applications don't have access to those service(s).<br />
| Access to arbitrary services<br />
| [[7.0.0-13]]<br />
| <br />
| 2012<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| FSDIR null-deref<br />
| [[Filesystem_services|FS]]-module may crash in some cases when handling directory reading. The trigger seems to be due to using [[FSDir:Close]] without closing the dir-handle afterwards?(Perhaps this is caused by out-of-memory?) This seems to be useless since it's just a null-deref.<br />
| <br />
| None<br />
| [[9.6.0-24|9.6.0-X]]<br />
| May 19(?)-20, 2015<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[SM]] out-of-bounds BSS write (table 1 entry too small)<br />
| After accepting a new session, [[SM]] writes a (handler ID (0 for srv: sessions (max. 64), 1 for the srv:pm one), pointer to session context structure in BSS) pair in a global array. However that array is only 64-entry-big instead of 65 (as it ought to be), and no bound check is done in that regard.<br />
<br />
Unfortunately, as of [[11.4.0-37]], the overwritten fields are totally unused after their initialization by <code>__libc_init_array</code>.<br />
| Not currently exploitable<br />
| None<br />
| [[11.4.0-37]]<br />
|<br />
|<br />
|}<br />
<br />
=== Standalone Sysmodules ===<br />
{| class="wikitable" border="1"<br />
|-<br />
! Summary<br />
! Description<br />
! Successful exploitation result<br />
! Fixed in system-module system-version<br />
! Last system-module system-version this flaw was checked for<br />
! Timeframe this was discovered<br />
! Timeframe this was added to wiki<br />
! Discovered by<br />
|-<br />
| [[MP:SendDataFrame]] missing input array index validation<br />
| [[MP:SendDataFrame]] doesn't validate the input index at cmdreq[1], unless the function for flag=non-zero is executed. This is used to calculate the following, without validating the index at all: someptr = stateptr + (index*0x924) + somestateoffset.<br />
<br />
After validating some flags from someptr, when input_flag=0 the input buffer data is copied to someptr+someotheroffset+0x14 with the u16 size loaded from someptr+someotheroffset.<br />
<br />
With a large input index someptr could be setup to be at a <target address>, for overwriting memory.<br />
<br />
This is probably difficult to exploit.<br />
| <br />
| None<br />
| [[8.0.0-18]](MP-sysmodule v2048)<br />
| January 22, 2017<br />
| January 22, 2017<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[MP_Services|MP]] cmd1 out-of-bounds handle read<br />
| MP-sysmodule handles the input parameter for cmd1 as a s32. It checks for >=16, but not <0. With <16 it basically does the following(array of entries 4-bytes each): *outhandle = ((Handle*)(stateptr+offsetinstate))[inputindex].<br />
<br />
Hence, this can be used to load any handle in MP-sysmodule memory. MP doesn't really have any service handles of interest however(can be obtained from elsewhere too).<br />
| Reading any handle in MP-sysmodule memory.<br />
| None<br />
| [[8.0.0-18]](MP-sysmodule v2048)<br />
| January 21, 2017<br />
| January 22, 2017<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| AM stack/.bss infoleak via [[AM:ReadTwlBackupInfo]]([[AM:ReadTwlBackupInfoEx|Ex]])<br />
| After writing the output-info structure to stack, it then copies that structure to the output buffer ptr using the size from the command. The size is not checked. This could be used to read data from the AM-service-thread stack handling the command + .bss.<br />
<br />
'''This was not tested on hardware.'''<br />
| Stack/.bss reading<br />
| None<br />
| [[10.0.0-27]](AM v9217)<br />
| Roughly October 17, 2016<br />
| October 25, 2016<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[MVD_Services|MVD]]: Stack buffer overflow with [[MVDSTD:SetupOutputBuffers]].<br />
| The input total_entries is not validated when initially processing the input entry-list. This fixed-size input entry-list is copied to stack from the command request. The loop for processing this initializes a global table, the converted linearmem->physaddrs used there are also copied to stack(0x8-bytes of physaddrs per entry).<br />
<br />
If total_entries is too large, MVD-sysmodule will crash due to reading unmapped memory following the stack(0x10000000). Afterwards if the out-of-bounds total_entries is smaller than that, it will crash due accessing address 0x0, hence this useless.<br />
| MVD-sysmodule crash.<br />
| None<br />
| [[9.0.0-20]]<br />
| April 22, 2016 (Tested on the 25th)<br />
| April 25, 2016<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[NWM_Services|NWM]]: Using CTRSDK heap with UDS sharedmem from the user-process.<br />
| See the HTTP-sysmodule section below.<br />
<br />
CTRSDK heap is used with the sharedmem from [[NWMUDS:InitializeWithVersion]]. Buffers are allocated/freed under this heap using [[NWMUDS:Bind]] and [[NWMUDS:Unbind]].<br />
<br />
Hence, overwriting sharedmem with gspwn then using [[NWMUDS:Unbind]] results in the usual controlled CTRSDK memchunk-header write, similar to HTTP-sysmodule.<br />
<br />
This could be done by creating an UDS network, without any other nodes on the network.<br />
<br />
Besides CTRSDK memchunk-headers, there are no addresses stored under this sharedmem.<br />
| ROP under NWM-module.<br />
| [[11.4.0-37|11.4.0-X]]<br />
| [[9.0.0-20|9.0.0-X]]<br />
| April 10, 2016<br />
| April 16, 2016<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[DLP_Services|DLP]]: Out-of-bounds memory access during spectator [[Download_Play|data-frame]] checksum calculation<br />
| DLP doesn't validate the frame_size when receiving spectator data-frames at all, unlike non-spectator data-frames. The actual spectator data-frame parsing code doesn't use that field either. However, the data-frame checksum calculation code called during checksum verification does use the frame_size for loading the size of the framebuf.<br />
<br />
Hence, using a large frame_size like 0xFFFF will result in the checksum calculation code reading data out-of-bounds. This isn't really useful, you could trigger a remote local-WLAN DLP-sysmodule crash while a 3DS system is scanning for DLP networks(due to accessing unmapped memory), but that's about all(trying to infoleak with this likely isn't useful either).<br />
| DLP-sysmodule crash, handled by dlplay system-application by a "connection interrupted" error eventually then a fatal-error via ErrDisp.<br />
| None<br />
| [[10.0.0-27|10.0.0-X]]<br />
| April 8, 2016 (Tested on the 10th)<br />
| April 10, 2016<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[DLP_Services|DLP]]: Out-of-bounds output data writing during spectator sysupdate titlelist [[Download_Play|data-frame]] handling<br />
| The total_entries and out_entryindex fields for the titlelist DLP spectator data-frames are not validated. This is parsed during DLP network scanning. Hence, the specified titlelist data can be written out-of-bounds using the specified out_entryindex and total_entries. A crash will occur while reading the input data-frame titlelist if total_entries is larger than 0x27A, due to accessing unmapped memory.<br />
<br />
There's not much non-zero data to overwrite following the output buffer(located in sharedmem), any ptrs are located in sharedmem. Overwriting certain ptr(s) are only known to cause a crash when attempting to use the DLP-client shutdown service-command.<br />
<br />
There's no known way to exploit the above crash, since the linked-list code involves writes zeros(with a controlled start ptr).<br />
| <br />
| None<br />
| [[10.0.0-27|10.0.0-X]]<br />
| April 8-9, 2016<br />
| April 10, 2016<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[IR_Services|IR]]: Stack buffer overflow with custom hardware<br />
| Originally IR sysmodule used the read value from the I2C-IR registers TXLVL and RXLVL without validating them at all. See [[10.6.0-31|here]] for the fix. This is the size used for reading the data-recv FIFO, etc. The output buffer for reading is located on the stack.<br />
<br />
This should be exploitable if one could successfully setup the custom hardware for this and if the entire intended sizes actually get read from I2C.<br />
| ROP under IR sysmodule.<br />
| [[10.6.0-31|10.6.0-31]]<br />
| <br />
| February 23, 2016 (Unknown if it was noticed before then)<br />
| February 23, 2016<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[HTTP_Services|HTTP]]: Using CTRSDK heap with sharedmem from the user-process.<br />
| The data from httpcAddPostDataAscii and other commands is stored under a CTRSDK heap. That heap is the sharedmem specified by the user-process via the HTTPC Initialize command.<br />
Normally this sharedmem isn't accessible to the user-process once the sysmodule maps it, hence using it is supposed to be "safe".<br />
<br />
This isn't the case due to gspwn however. Since CTRSDK heap code is so insecure in general, one can use gspwn to locate the HTTPC sharedmem + read/write it, then trigger a mem-write under the sysmodule. This can then be used to get ROP going under HTTP-sysmodule.<br />
<br />
This is exploited by [https://github.com/yellows8/ctr-httpwn/ctr-httpwn ctr-httpwn].<br />
| ROP under HTTP sysmdule.<br />
| [[11.4.0-37|11.4.0-X]]<br />
| [[9.6.0-24|9.6.0-X]] (Latest sysmodule version as of [[10.7.0-32|10.7.0-32]])<br />
| Late 2015<br />
| March 22, 2016<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[NIM_Services|NIM]]: Downloading old title-versions from eShop<br />
| Multiple NIM service commands(such as [[NIMS:StartDownload]]) use a title-version value specified by the user-process, NIM does not validate that this input version matches the latest version available via SOAP. Therefore, when combined with AM(PXI) [[#Process9|title-downgrading]] via deleting the target eShop title with System Settings Data Management(if the title was already installed), this allows downloading+installing any title-version from eShop ''if'' it's still available from CDN.<br />
The easiest way to exploit this is to just patch the eShop system-application code using these NIM commands(ideally the code which loads the title-version).<br />
<br />
Originally this was tested with a debugging-system via modded-FIRM, eventually smea implemented it in HANS for the 32c3 release.<br />
| Downloading old title-versions from eShop<br />
| None<br />
| [[10.0.0-27|10.0.0-X]]<br />
| October 24, 2015 (Unknown when exactly the first eShop title downgrade was actually tested, maybe November)<br />
| January 7, 2016 (Same day Ironfall v1.0 was removed from CDN via the main-CXI files)<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[SPI_Services|SPI]] service out-of-bounds write<br />
| cmd1 has out-of-bounds write allowing overwrite of some static variables in .data.<br />
| <br />
| None<br />
| [[9.5.0-22]]<br />
| March 2015<br />
| <br />
| [[User:Plutooo|plutoo]]<br />
|-<br />
| [[NFC_Services|NFC]] module service command buf-overflows<br />
| NFC module copies data with certain commands, from command input buffers to stack without checking the size. These commands include the following, it's unknown if there's more commands with similar issues: "nfc:dev" <0x000C....> and "nfc:s" <0x0037....>.<br />
Since both of these commands are stubbed in the Old3DS NFC module from the very first version(those just return an error), these issues only affect the New3DS NFC module.<br />
<br />
There's no known retail titles which have access to either of these services.<br />
| ROP under NFC module.<br />
| New3DS: None<br />
| New3DS: [[9.5.0-22]]<br />
| December 2014?<br />
| <br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[News_Services|NEWSS]] service command notificationID validation failure<br />
| This module does not validate the input notificationID for <nowiki>"news:s"</nowiki> service commands. This is an out-of-bounds array index bug. For example, [[NEWSS:SetNotificationHeader]] could be used to exploit news module: this copies the input data(size is properly checked) to: out = newsdb_savedata+0x10 + (someu32array[notificationID]*0x70).<br />
| ROP under news module.<br />
| None<br />
| [[9.7.0-25|9.7.0-X]]<br />
| December 2014<br />
| <br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[NWMUDS:DecryptBeaconData]] heap buffer overflow<br />
| input_size = 0x1E * <value the u8 from input_[[NWM_Services|networkstruct]]+0x1D>. Then input_tag0 is copied to a heap buffer. When input_size is larger than 0xFA-bytes, it will then copy input_tag1 to <end_address_of_previous_outbuf>, with size=input_size-0xFA.<br />
<br />
This can be triggered by either using this command directly, or by boadcasting a wifi beacon which triggers it while a 3DS system running the target process is in range, when the process is scanning for hosts to connect to. Processes will only pass tag data to this command when the wlancommID and other thing(s) match the values for the process.<br />
<br />
There's no known way to actually exploit this for getting ROP under NWM-module, at the time of originally adding this to the wiki. This is because the data which gets copied out-of-bounds *and* actually causes crash(es), can't be controlled it seems(with just broadcasting a beacon at least). It's unknown whether this could be exploited from just using NWMUDS service-cmd(s) directly.<br />
| Without any actual way to exploit this: NWM-module DoS, resulting in process termination(process crash). This breaks *everything* involving wifi comms, a reboot is required to recover from this.<br />
| None<br />
| [[9.0.0-20]]<br />
| ~September 23, 2014(see the [[NWMUDS:DecryptBeaconData]] page history)<br />
| August 3, 2015<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[HID_Services|HID]] module shared-mem<br />
| HID module does not validate the index values in [[HID_Shared_Memory|sharedmem]](just changes index to 0 when index == maxval when updating), therefore large values will result in HID module writing HID data to arbitrary addresses.<br />
| ROP under HID module, but this is *very* unlikely to be exploitable since the data written is HID data.<br />
| None<br />
| [[9.3.0-21]]<br />
| 2014?<br />
| <br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| gspwn<br />
| GSP module does not validate addresses given to the GPU. This allows a user-mode application/applet to read/write to a large part of physical FCRAM using GPU DMA. From this, you can overwrite the .text segment of the application you're running under, and gain real code-execution from a ROP-chain. Normally applets' .text([[Home Menu]], [[Internet Browser]], etc) is located beyond the area accessible by the GPU, except for [[RO_Services|CROs]] used by applets([[Internet Browser]] for example).<br />
<br />
FCRAM is gpu-accessible up to physaddr 0x26800000 on Old3DS, and 0x2D800000 on New3DS. This is BASE_memregion_start(aka SYSTEM_memregion_end)-0x400000 (0x800000 with New3DS) with the default memory-layout on Old3DS/New3DS. With [[11.3.0-36|11.3.0-X]] the cutoff now varies due to the new [[SVC]] 0x59. The New3DS "normal"(non-APPLICATION) cutoff was changed to 0x2D000000 due to the new [[SVC]] 0x59.<br />
| User-mode code execution.<br />
| None<br />
| [[9.6.0-24|9.6.0-X]]<br />
| Early 2014<br />
| <br />
| smea, [[User:Yellows8|Yellows8]]/others before then<br />
|-<br />
| rohax<br />
| Using gspwn, it is possible to overwrite a loaded [[CRO0]]/[[CRR0]] after its RSA-signature has been validated. Badly validated [[CRO0]] header leads to arbitrary read/write of memory in the ro-process. This gives code-execution in the ro module, who has access to [[SVC|syscalls]] 0x70-0x72, 0x7D.<br />
<br />
This was fixed after [[ninjhax]] release by adding checks on [[CRO0]]-based pointers before writing to them.<br />
| Memory-mapping syscalls.<br />
| [[9.3.0-21]]<br />
| [[9.4.0-21]]<br />
| <br />
| <br />
| smea, [[User:Plutooo|plutoo]] joint effort<br />
|-<br />
| Region free<br />
| Only [[Home Menu]] itself checks gamecards' region when launching them. Therefore, any application launch that is done directly with [[NS]] without signaling Home Menu to launch the app, will result in region checks being bypassed.<br />
This essentially means launching the gamecard with the [[NS_and_APT_Services|"ns:s"]] service. The main way to exploit this is to trigger a FIRM launch with an application specified, either with a normal FIRM launch or a hardware [[NSS:RebootSystem|reboot]].<br />
| Launching gamecards from any region + bypassing Home Menu gamecard-sysupdate installation<br />
| None<br />
| Last tested with [[10.1.0-27|10.1.0-X]].<br />
| June(?) 2014<br />
| <br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[NWM_Services|NWM]] service-cmd state null-ptr deref<br />
| The NWMUDS service command code loads a ptr from .data, adds an offset to that, then passes that as the state address for the actual command-handler function. The value of the ptr loaded from .data is not checked, therefore this will cause crashes due to that being 0x0 when NWMUDS was not properly initialized.<br />
It's unknown whether any NWM services besides NWMUDS have this issue.<br />
| This is rather useless since it's only a crash caused by a state ptr based at 0x0.<br />
| None<br />
| [[9.0.0-20]]<br />
| 2013?<br />
| <br />
| [[User:Yellows8|Yellows8]]<br />
|}<br />
<br />
=== General/CTRSDK ===<br />
{| class="wikitable" border="1"<br />
|-<br />
! Summary<br />
! Description<br />
! Successful exploitation result<br />
! Fixed in version<br />
! Last version this flaw was checked for<br />
! Timeframe this was discovered<br />
! Discovered by<br />
|-<br />
| [[NWM_Services|UDS]] beacon additional-data buffer overflow<br />
| Originally CTRSDK did not validate the UDS additional-data size before using that size to copy the additional-data to a [[NWM_Services|networkstruct]]. This was eventually fixed.<br />
This was discovered while doing code RE with an old dlp-module version. It's unknown in what specific CTRSDK version this was fixed, or even what system-version updated titles with a fixed version.<br />
<br />
It's unknown if there's any titles using a vulnerable CTRSDK version which are also exploitable with this(dlp module can't be exploited with this).<br />
<br />
The maximum number of bytes that can be written beyond the end of the outbuf is 0x37-bytes, with additionaldata_size=0xFF.<br />
| Perhaps ROP, very difficult if possible with anything at all<br />
| ?<br />
| <br />
| September(?) 2014<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| CTPK buffer overflow<br />
| At offset 0x20 in CTPK is an array for each texture, each entry is 0x20-bytes. This contains a wordindex(entry+0x18) for some srcdata relative to CTPK+0, and an u8 wordsize(entry+0x14) for this data. The CTRSDK function handling this doesn't validate the size, when copying srcdata using this size to the output buffer. Applications usually have the output buffer on the stack, hence stack buffer overflow.<br />
<br />
While CTPK(*.ctpk) are normally only loaded from RomFS, some application(s) load from elsewhere too.<br />
| ROP under the target application.<br />
| None?<br />
| "[SDK+NINTENDO:CTR_SDK-11_4_0_200_none]"<br />
| November 14, 2016<br />
| [[User:Yellows8|Yellows8]]<br />
|}</div>Myriahttps://www.3dbrew.org/w/index.php?title=3DS_System_Flaws&diff=208093DS System Flaws2018-08-12T05:17:05Z<p>Myria: /* Boot ROM */ Better sighax description</p>
<hr />
<div>Exploits are used to execute unofficial code (homebrew) on the Nintendo 3DS. This page is a list of publicly known system flaws, for userland applications/applets flaws see [[3DS_Userland_Flaws|here]].<br />
<br />
=Stale / Rejected Efforts=<br />
* Neimod has been working on a RAM dumping setup for a little while now. He's de-soldered the 3DS's RAM chip and hooked it and the RAM pinouts on the 3DS' PCB up to a custom RAM dumping setup. A while ago he published photos showing his setup to be working quite well, with the 3DS successfully booting up. However, his flickr stream is now private along with most of his work.<br />
<br />
* Someone (who will remain unnamed) has released CFW and CIA installers, all of which is copied from the work of others, or copyrighted material.<br />
<br />
==Tips and info==<br />
The 3DS uses the XN feature of the ARM11 processor. There's no official way from applications to enable executable permission for memory containing arbitrary unsigned code(there's a [[SVC]] for this, but only [[RO_Services|RO-module]] has access to it). A usable userland exploit would still be useful: you could only do return-oriented-programming with it initially. From ROP one could then exploit system flaw(s), see below.<br />
<br />
SD card [[extdata]] and SD savegames can be attacked, for consoles where the console-unique [[Nand/private/movable.sed|movable.sed]] was dumped(accessing SD data is far easier by running code on the target 3DS however).<br />
<br />
=System flaws=<br />
== Hardware ==<br />
{| class="wikitable" border="1"<br />
! Summary<br />
! Description<br />
! Fixed with hardware model/revision<br />
! Newest hardware model/revision this flaw was checked for<br />
! Timeframe this was discovered<br />
! Discovered by<br />
|-<br />
| ARM9/ARM11 bootrom vectors point at uninitialized RAM<br />
| ARM9's and ARM11's exception vectors are hardcoded to point at the CPU's internal memory (0x08000000 region for ARM9, AXIWRAM for ARM11). While the bootrom does set them up to point to an endless loop at some point during boot, it does not do so immediately. As such, a carefully-timed fault injection (via hardware) to trigger an exception (such as an invalid instruction) will cause execution to fall into ARM9 RAM. <br />
Since RAM isn't cleared on boot (see below), one can immediately start execution of their own code here to dump bootrom, OTP, etc.<br />
The ARM9 bootrom does the following at reset: reset vector branches to another instruction, then branches to bootrom+0x8000. Hence, there's no way to know for certain when exactly the ARM9 exception-vector data stored in memory gets initialized.<br />
<br />
This requires *very* *precise* timing for triggering the hardware fault.<br />
<br />
It has been exploited by derrek to dump the ARM9 bootrom as of Summer 2015.<br />
| None: all available 3DS models at the time of writing have the exact same ARM9/ARM11 bootrom for the unprotected areas.<br />
| New3DS<br />
| End of February 2014<br />
| [[User:Derrek|derrek]], WulfyStylez (May 2015) independently<br />
|-<br />
| Missing AES key clearing<br />
| The hardware AES engine does not clear keys when doing a hard reset/reboot.<br />
| None<br />
| New3DS<br />
| August 2014<br />
| Mathieulh/Others<br />
|-<br />
| No RAM clearing on reboots<br />
| On an MCU-triggered reboot all RAM including FCRAM/ARM9 memory/AXIWRAM/VRAM keeps its contents.<br />
| None<br />
| New3DS<br />
| March 2014<br />
| [[User:Derrek|derrek]]<br />
|-<br />
| 32bits of actual console-unique TWLNAND keydata<br />
| On retail the 8-bytes at ARM9 address [[Memory_layout|0x01FFB808]] are XORed with hard-coded data, to generate the TWL console-unique keys, including TWLNAND. On Old3DS the high u32 is always 0x0, while on New3DS that u32 is always 0x2. On top of this, the lower u32's highest bit is always ORed. only 31 bits of the TWL console-unique keydata / TWL consoleID are actually console-unique.<br />
This allows one to easily bruteforce the TWL console-unique keydata with *just* data from TWLNAND. On DSi the actual console-unique data for key generation is 8-bytes(all bytes actually set).<br />
| None<br />
| New3DS<br />
| 2012?<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| DSi / 3DS-TWL key-generator<br />
| After using the key generator to generate the normal-key, you could overwrite parts of the normal-key with your own data and then recover the key-generator output by comparing the new crypto output with the original crypto output. From the normal-key outputs, you could deduce the TWL key-generator function.<br />
This applies to the keyX/keyY too.<br />
<br />
This attack does not work for the 3DS key-generator because keyslots 0-3 are only for TWL keys.<br />
| None<br />
| New3DS<br />
| 2011<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| 3DS key-generator<br />
| The algorithm for generating the normal-keys for keyslots is cryptographically weak. As a result, it is easily susceptible to differential cryptanalysis if the normal-key corresponding to any scrambler-generated keyslot is discovered.<br />
<br />
Several such pairs of matching normal-keys and KeyY values were found, leading to deducing the key-generator function.<br />
| None<br />
| New3DS<br />
| February 2015<br />
| [[User:Yellows8|Yellows8]], [[User:Plutooo|plutoo]]<br />
|-<br />
| RSA keyslots don't clear exponent when setting modulus<br />
| The [[RSA_Registers|RSA keyslots]] are set by boot ROM to have four private RSA keys. The exponent value in the RSA registers is write-only and not readable.<br />
<br />
However, when setting a keyslot's modulus, the RSA hardware leaves the exponent alone. This allows retrieving the exponent by doing a discrete logarithm of the output.<br />
<br />
By setting the modulus to a prime number whose modular multiplicative order is "smooth" (that is, p-1 is divisible by only small prime numbers), discrete logarithms can be calculated quickly using the [[wikipedia:Pohlig-Hellman algorithm|Pohlig-Hellman algorithm]]. If the prime chosen is greater than the modulus, but the same bit size, the discrete logarithm is the private exponent.<br />
<br />
This exploit's usefulness is limited: RSA keyslot 0 is only used in current firmware for deriving the 6.x save and 7.x NCCH keys, which were already known, and the other three keyslots are entirely unused. Additionally, with a boot ROM dump, this exploit is moot; these private keys are located in the protected ARM9 boot ROM.<br />
| None<br />
| New3DS<br />
| March 2016<br />
| [[User:Myria|Myria]]<br />
|-<br />
| [[CONFIG11_Registers#CFG11_GPUPROT|CFG11_GPUPROT]] allowing acccess to AXIWRAM/FCRAM-BASE-memregion<br />
| [[CONFIG11_Registers#CFG11_GPUPROT|CFG11_GPUPROT]] can be configured by anything with access to it to allow the GPU to access the entire AXIWRAM+FCRAM. For example, this is an issue for any sysmodule that gets exploited and has access to this register memory-page(include one that's listed below).<br />
<br />
See also "kernelhax via gspwn" below.<br />
| None<br />
| New3DS<br />
| February 7, 2017<br />
| [[User:Yellows8|Yellows8]]<br />
|}<br />
<br />
== Boot ROM ==<br />
{| class="wikitable" border="1"<br />
! Summary<br />
! Description<br />
! Fixed with hardware model/revision<br />
! Newest hardware model/revision this flaw was checked for<br />
! Timeframe this was discovered<br />
! Discovered by<br />
|-<br />
| FIRM partitions known-plaintext<br />
| The [[Flash_Filesystem|FIRM partitions]] are encrypted with AES-CTR without a MAC. Since this works by XOR'ing data with a static (per-console in this case) keystream, one can deduce the keystream of a portion of each FIRM partition if they have the actual FIRM binary stored in it.<br />
<br />
This can be paired with many exploits. For example, it allows minor FIRM downgrades (i.e. 10.4 to 9.6 or 9.5 to 9.4, but not 9.6 to 9.5).<br />
However it is most commonly used to install arbitrary FIRMs (usually boot9strap), thanks to sighax.<br />
<br />
This can be somewhat addressed by having a FIRM header skip over previously used section offsets, but this would just air-gap newer FIRMs without fixing the core bug. This can also only be done a limited number of times due to the size of FIRM versus the size of the partitions.<br />
| None<br />
| New3DS<br />
| <br />
| Everyone<br />
|-<br />
| Boot9 AES keyinit function issues<br />
| [[Bootloader|Boot9]] seems to have two bugs in the AES key-init function, see [[AES_Registers#AES_key-init|here]].<br />
| None<br />
| BootROM issue.<br />
| 2015<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| New3DS has same boot ROM as Old3DS<br />
| The New3DS has the exact same boot ROM as the Old3DS. This means, among other things, that all the same boot ROM flaws are present. Also, this meant that it is possible to boot Old3DS firmware on New3DS (see "CFG_SYSPROT9 bit1 not set by Kernel9").<br />
| None<br />
| New3DS<br />
| October 2014<br />
| Everyone<br />
|-<br />
| sighax: Boot9 improper validation of FIRM partition RSA signatures<br />
| The [[Flash_Filesystem|FIRM partitions]] are signed with RSA-2048 using SHA-256 and PKCS #1 v1.5 padding. Boot9, however, improperly validates the padding in three ways:<br />
# Boot9 permits block type 02, meant for encrypted messages, to be used for signatures. Only 01, for signatures, should have been permitted. As a result, when using block type 02, a signature block is not required to have a long string of FF bytes as padding, but rather any nonzero random values suffice.<br />
# Boot9 does not require that the length of the padding fill out the signature block completely. As a result, there is considerable freedom in the layout of a signature.<br />
# Boot9 fails to do bounds checking in its parsing of the DER-encoded hash algorithm type and hash value; the length values given in DER are permitted to point outside the signature block.<br />
Flaw 3 allows the DER encoding to be such that boot9 believes that the signature's hash value is outside the range of the block itself, somewhere on the stack. This can be pointed at the correct hash value it computes. Boot9 then memcmp's the calculated hash against itself, and thinks that the hash is valid.<br />
<br />
As a result of the above, we estimate that one in 2<sup>43</sup> (~8.8 trillion) random fake signatures will be considered by Boot9 to be valid. This is well within the range of brute force, particularly with an optimized GPU implementation. An Nvidia GTX 1080 Ti would take about one week to find a match.<br />
| None<br />
| New3DS<br />
| July 2015<br />
| [[User:Derrek|derrek]]<br />
|-<br />
| Boot9 FIRM loading doesn't blacklist memory-mapped I/O<br />
| [[Bootloader|Boot9]]'s FIRM loading blacklists Boot9 data regions, but forgets to do other important regions, including Memory-mapped I/O. Combined with sighax, by loading a malicious FIRM section to MMIO, one can get Boot9/Boot11 code execution. <br />
| None<br />
| New3DS<br />
| 2015(?)<br />
| [[User:Derrek|derrek]] (2015?), [[User:Normmatt|Normmatt]] and [[User:SciresM|SciresM]] independently (January 2017).<br />
|-<br />
| "superhax": Boot9 FIRM loading blacklist check is flawed<br />
| Boot9 only makes sure the '''start''' and '''end''' address of each section is not covered by a blacklisted region. Thus, it is possible to overwrite blacklisted regions (e.g. ARM9 Exception Vectors) by choosing a FIRM section range that encloses an entire blacklisted region. The vulnerable code looks like this: if(blRegions[i].start <= sectionStart && blRegions[i].end > sectionStart <nowiki>||</nowiki> blRegions[i].start <= sectionEnd && blRegions[i].end > sectionEnd) return false; // failure<br />
| None<br />
| New3DS<br />
| August 2015<br />
| [[User:Plutoo|plutoo]], [[User:Yellows8|yellows8]]<br />
|}<br />
<br />
== ARM9 software ==<br />
<br />
=== arm9loader ===<br />
{| class="wikitable" border="1"<br />
|-<br />
! Summary<br />
! Description<br />
! Successful exploitation result<br />
! Fixed in [[FIRM]] system version<br />
! Last [[FIRM]] system version this flaw was checked for<br />
! Timeframe this was discovered<br />
! Public disclosure timeframe<br />
! Discovered by<br />
|-<br />
| Generating the keysector console-unique keys with ITCM+Boot9<br />
| [[Bootloader|Boot9]] decrypts the 0x100-byte [[OTP_Registers|OTP]] using AES-CBC with keydata stored in Boot9. If hash verification is successful, the plaintext of the first 0x90-bytes are copied into [[Memory_layout|ITCM]]. This is the ''exact'' ''same'' region hashed by arm9loader when generating the console-unique keys for decrypting the keysector, except arm9loader uses the raw encrypted OTP.<br />
<br />
Therefore, with the OTP keydata+IV from Boot9 you can: encrypt the 0x90-bytes from ITCM, then hash the output to get the console-unique keys for the system's keysector. This can even be done for Old3DS which doesn't have the arm9loader keysector officially.<br />
<br />
It's unknown why arm9loader only used the first 0x90-bytes of OTP. Using more data from OTP would've prevented this. Fixing this would require doing exactly that, but that would also mean updating the NAND keysector(which is dangerous).<br />
| See description.<br />
| None<br />
| <br />
| 2015<br />
| January 6, 2017<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| Rearrangable keys in the NAND keystore<br />
| Due to the keystore being encrypted with AES-ECB, one can rearrange blocks and still have the NAND keystore decrypt in a deterministic way. <br />
<br />
Using 10.0 FIRM it is possible to rearrange keys such that ARM9 memory is executed. As such using existing ARM9 execution 10.0 FIRM can be written to NAND and a payload written to memory, with the payload to be executed post-K9L using an MCU reboot.<br />
| arm9loaderhax given existing ARM9 code execution<br />
| None<br />
| [[11.3.0-36|11.3.0-X]]<br />
| Early 2016<br />
| 27 September 2016<br />
| Myria, [[User:Dark samus|dark_samus]]; mathieulh (independently); [[User:Plutooo|plutoo]] (independently) + others<br />
|-<br />
| Uncleared OTP hash keydata in console-unique 0x11 key-generation<br />
| Kernel9Loader does not clear the [[SHA_Registers#SHA_HASH|SHA_HASH register]] after use. As a result, the data stored here as K9L hands over to Kernel9 is the hash of [[OTP_Registers|OTP data]] used to seed the [[FIRM#New_3DS_FIRM|console-unique NAND keystore decryption key]] set on keyslot 0x11.<br />
<br />
Retrieving this keydata and the [[Flash_Filesystem#0x12C00|NAND keystore]] of the same device allows calculating the decrypted New3DS NAND keystore (non-unique, common to all New3DS units), which contains AES normal keys, also set on keyslot 0x11, which are then used to derive all current [[AES_Registers#Keyslots|New3DS-only AES keyXs]] including the newer batch introduced in [[9.6.0-24#arm9loader|9.6.0-X]]. From there, it is trivial to perform the same key derivation in order to initialize those keys on any system version, and even on Old3DS.<br />
<br />
This can be performed by exploiting the "arm9loaderhax" vulnerability to obtain post-K9L code execution after an MCU reboot (the bootrom section-loading fail is not relevant here, this attack was performed without OTP data by brute-forcing keys), and using this to dump the SHA_HASH register. This attack works on any FIRM version shipping a vulnerable version of K9L, whereas OTP dumping required a boot of <[[3.0.0-6|3.0.0-X]].<br />
<br />
This attack results in obtaining the entire (0x200-bytes) NAND keystore - it was confirmed at a later date that this keystore is encrypted with the same key (by comparing the decrypted data from multiple units), and therefore using another key in this store will not remedy the issue as all keys are known (i.e. later, unused keys decrypt to the same 0x200-bytes constant with the same OTP hash). Later keys could have been encrypted differently but this is not the case. As a result of this, it is not possible for Nintendo to use K9L again in its current format for its intended purpose, though this was not news from the moment people dumped a New3DS OTP.<br />
| Derivation of all New3DS keys generated via the NAND keystore (0x1B "Secure4" etc.)<br />
| None<br />
| [[11.3.0-36|11.3.0-X]]<br />
| ~April 2015, implemented in May 2015<br />
| 13 January 2016<br />
| [[User:WulfyStylez|WulfyStylez]], [[User:Dazzozo|Dazzozo]], [[User:Shinyquagsire23|shinyquagsire23]] (complimentary + implemented), [[User:Plutooo|plutoo]], Normmatt (discovered independently)<br />
|-<br />
| enhanced-arm9loaderhax<br />
| See the 32c3 3ds talk.<br />
Since this is a combination of a trick with the arm9-bootrom + arm9loaderhax, and since you have to manually write FIRM to the firm0/firm1 NAND partitions, this can't be completely fixed. Any system with existing ARM9 code execution and an OTP/OTP hash dump can exploit this. Additionally, by using the FIRM partition known-plaintext bug and bruteforcing the second entry in the keystore, this can currently be exploited on all New3DS systems without any other prerequisite hacks.<br />
| arm9loaderhax which automatically occurs at hard-boot.<br />
| See arm9loaderhax / description.<br />
| See arm9loaderhax / description.<br />
| Theorized around mid July, 2015. Later implemented+tested by [[User:Plutooo|plutoo]] and [[User:Derrek|derrek]].<br />
| 32c3 3ds talk (December 27, 2015)<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| Missing verification-block for the 9.6 keys (arm9loaderhax)<br />
| Starting with [[9.6.0-24|9.6.0-X]] a new set of NAND-based keys were introduced. However, no verification block was added to verify that the new key read from NAND is correct. This was technically an issue from [[9.5.0-22|9.5.0-X]] with the original sector+0 keydata, however the below is only possible with [[9.6.0-24|9.6.0-X]] since keyslots 0x15 and 0x16 are generated from different 0x11 keyXs.<br />
<br />
Writing an incorrect key to NAND will cause arm9loader to decrypt the ARM9 kernel as garbage and then jump to it.<br />
<br />
This allows an hardware-based attack where you can boot into an older exploited firmware, fill all memory with NOP sleds/jump-instructions, and then reboot into executing garbage. By automating this process with various input keydata, eventually you'll find some garbage that jumps to your code.<br />
<br />
This gives very early ARM9 code execution (pre-ARM9 kernel). As such, it is possible to dump RSA keyslots with this and calculate the 6.x [[Savegames#6.0.0-11_Savegame_keyY|save]], and 7.x [[NCCH]] keys. This cannot be used to recover keys initialized by arm9loader itself. This is due to it wiping the area used for its stack during NAND sector decryption and keyslot init. <br />
<br />
Due to FIRMs on both Old and New 3DS using the same RSA data, this can be exploited on Old3DS as well, but only if one already has the actual plaintext normalkey from New3DS NAND sector 0x96 offset-0 and has dumped the OTP area of the Old3DS.<br />
| Recovery of 6.x [[Savegames#6.0.0-11_Savegame_keyY|save key]]/7.x [[NCCH]] key, access to uncleared OTP hash keydata<br />
| None<br />
| [[11.3.0-36|11.3.0-X]]<br />
| March, 2015<br />
| <br />
| [[User:Plutooo|plutoo]]<br />
|-<br />
| Uncleared New3DS keyslot 0x11<br />
| Originally the New3DS [[FIRM]] arm9bin loader only cleared keyslot 0x11 when it gets executed at firmlaunch. This was fixed with [[9.5.0-22|9.5.0-X]] by completely clearing keyslot 0x11 immediately after the loader finishes using keyslot 0x11.<br />
This means that any ARM9 code that can execute before the loader clears the keyslot at firmlaunch(including firmlaunch-hax) can get access to the uncleared keyslot 0x11, which then allows one to generate all <=v9.5 New3DS keyXs which are generated by keyslot 0x11.<br />
<br />
Therefore, to completely fix this the loader would have to generate more keys using different keyslot 0x11 keydata. This was done with [[9.6.0-24|9.6.0-X]].<br />
| New3DS keyXs generation<br />
| Mostly fixed with [[9.5.0-22|9.5.0-X]], completely fixed with new keys with [[9.6.0-24|9.6.0-X]].<br />
| <br />
| February 3, 2015 (one day after [[9.5.0-22|9.5.0-X]] release)<br />
| <br />
| [[User:Yellows8|Yellows8]]<br />
|}<br />
<br />
=== Process9 ===<br />
{| class="wikitable" border="1"<br />
|-<br />
! Summary<br />
! Description<br />
! Successful exploitation result<br />
! Fixed in [[FIRM]] system version<br />
! Last [[FIRM]] system version this flaw was checked for<br />
! Timeframe this was discovered<br />
! Public disclosure timeframe<br />
! Discovered by<br />
|-<br />
| Leak of normal-key matching a key-scrambler key<br />
| New 3DS firmware versions [[8.1.0-0 New3DS|8.1.0]] through [[9.2.0-20|9.2.0]] set the encryption key for [[Amiibo]] data using a hardcoded normal-key in Process9. In firmware [[9.3.0-21|9.3.0]], Nintendo "fixed" this by using the key scrambler instead, by calculating the keyY value for keyslot 0x39 that results in the same normal-key, then hardcoding that keyY into Process9.<br />
<br />
Nintendo's fix is actually the problem: Nintendo revealed the normal-key matching an unknown keyX and a known keyY. Combined with the key scrambler using an insecure scrambling algorithm (see "Hardware" above), the key scrambler function could be deduced.<br />
| Deducing the keyX for keyslot 0x39 and the key scrambler algorithm<br />
| New 3DS [[9.3.0-21|9.3.0-X]], sort of<br />
| [[10.0.0-27|10.0.0-X]]<br />
| Sometime in 2015 after the hardware key-generator was broken.<br />
| 32c3 3ds talk (December 27, 2015)<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| Leak of normal-key matching a key-generator key<br />
| During the 3DS' development (June/July 2010) Nintendo added support installing encrypted content ([[CIA]]). Common-key index1 was intended to be a [[AES|hardware generated key]]. However while they added code to generate the key in hardware, they forgot to remove the normal-key for index1 (used elsewhere, likely old debug code). Nintendo later removed the normal key sometime before the first non-prototype firmware release.<br />
<br />
Knowing the keyY and the normal-key for common-key index1, the devkit key-generator algorithm can be deduced (see "Hardware" above). Additionally the remaining devkit common-keys can be generated once the common-key keyX is recovered.<br />
<br />
Note that the devkit key-generator was discovered to be the same as the retail key-generator.<br />
| Deducing the keyX for keyslot 0x3D and hardware key-generator algorithm. Generate remaining devkit common-keys.<br />
| pre-[[1.0.0-0|1.0.0-X]]<br />
| <br />
| Shortly after the key-generator was revealed to be flawed at the 32c3 3ds talk<br />
| January 20, 2016<br />
| [[User:Jakcron|jakcron]]<br />
|-<br />
| Factory firmware is vulnerable to sighax<br />
| During the 3DS's development, presumably boot9 was written (including the sighax) vulnerability. This vulnerability is also present in factory firmware (and earlier, including 0.11). This was fixed in version 1.0.0-0.<br />
| Deducing the mechanics of the sighax vulnerability in boot9 without having boot9 prot. Arm9 code execution on factory/earlier firmware.<br />
| [[1.0.0-0|1.0.0-X]]<br />
| [[1.0.0-0|1.0.0-X]]<br />
| May 9, 2017<br />
| May 19, 2017<br />
| [[User:SciresM|SciresM]], [[User:Myria|Myria]]<br />
|-<br />
| safefirmhax<br />
| SAFE_MODE_FIRM is almost never updated(even when NATIVE_FIRM is updated for vuln fixes), this can be noticed by ''just'' checking 3dbrew/ninupdates title-listings.<br />
<br />
The fix for 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 <=> Kernel11 sync, PXI sync and then repeat the original attack on SAFE_FIRM instead.<br />
| ARM9 code execution<br />
| [[11.3.0-36|11.3.0-X]]<br />
| <br />
| 2012-2013?<br />
| Wiki: January 2, 2017<br />
| Everyone<br />
|-<br />
| safefirmhax 1.1<br />
| Nintendo's original safefirmhax fix was flawed -- they added a global boolean that got set to true whenever a non-sysmodule title got launched (except for a hardcoded repair title id), and panic()'d if that boolean was true to prevent launching safefirm after hax was active. However, because the boolean was initially false after firmlaunch -- With ARM11-kernel execution, one could FIRM-launch into NATIVE_FIRM, and then immediately FIRM-launch again into SAFE_FIRM early in NATIVE_FIRM boot before the boolean got set to true to repeat the safehax attack.<br />
<br />
This was fixed by adding additional CFG9_BOOTENV checks to firmlaunch code in 11.4.<br />
| ARM9 code execution<br />
| [[11.4.0-37|11.4.0-X]]<br />
| <br />
| safefirmhax fix<br />
| Wiki: April 10, 2017<br />
| Everyone<br />
|-<br />
| ntrcardhax<br />
| When reading the banner of a NTR title, Process9 relies on a hardware register to know when the banner was fully read.<br />
However that register is shared between the ARM9 and the ARM11.<br />
An attacker with k11 control can so make Process9 believe the banner continues forever and so trigger a buffer overflow.<br />
With a custom banner for a NTR flashcart, this leads to code execution in Process9.<br />
<br />
This was fixed by adding bound checks on the read data.<br />
| ARM9 code execution<br />
| [[10.4.0-29|10.4.0-X]]<br />
| <br />
| March 2015<br />
| 32c3 3ds talk (December 27, 2015)<br />
| [[User:Plutooo|plutoo]]<br />
|-<br />
| Title downgrading via [[Application_Manager_Services|AM]]([[Application_Manager_Services_PXI|PXI]])<br />
| When a title is *already* installed, Process9 will compare the installed title-version with the title-version being installed. When the one being installed is older, Process9 would return an error.<br />
<br />
However, this can be bypassed by just deleting the title first via the service command(s) for that: with the title removed from the [[Title_Database]], Process9 can't compare the input title-version with anything. Hence, titles can be downgraded this way.<br />
<br />
[[11.0.0-33|11.0.0-X]] fixed this for key system titles (MSET, Home Menu, spider, ErrDisp, SKATER, NATIVE_FIRM, and every retail system module), by checking the version of the title to install against a hard-coded list of (titleID, minimumVersionRequired) pairs.<br />
| Bypassing title version check at installation, which then allows downgrading any title.<br />
| [[11.0.0-33|11.0.0-X]], for key system titles.<br />
| NATIVE_FIRM / AM-sysmodule [[11.0.0-33|11.0.0-X]]<br />
| ?<br />
| <br />
| ?<br />
|-<br />
| Anti-downgrade list did not include all system titles initially<br />
| The anti-downgrade list did not include legacy FIRMs until [[11.8.0-41|11.8.0-X]]. Therefore, legacy FIRMs could still be downgraded.<br />
| Downgrading legacy FIRMs; allowing to exploit bugs in older legacy FIRMs (of which at least one exists, see below).<br />
| [[11.8.0-33|11.8.0]]<br />
| [[11.8.0-33|11.8.0]]<br />
| ?<br />
| Wiki: August 5, 2018<br />
| Everyone<br />
|-<br />
| TWL_FIRM cmd-9 unchecked offset<br />
| In [[1.0.0-0|1.0.0-X]]'s TWL_FIRM, cmds 8 and 9 were not stubbed (whereas in the corresponding NATIVE_FIRM, they were).<br />
Command 8 does the Process9 initialisation for NTR carts if an NTR cart is inserted (NTR, not TWL, judged by chipid).<br />
<br />
Command 9 takes (u32 offset_read, u32 offset_write, u32 offset_read_end), and basically just copies (offset_read_end - offset_read) bytes starting at (offset_read) of [NTR cart header in arm9mem, NTR secure area in fcram, TWL secure area in fcram], to 0x18001000 + offset_write + offset_read.<br />
<br />
offset_write is not checked at all, thus this leads to ARM9 code execution as long as any NTR cart, including flashcarts that would normally be blocked by TWL_FIRM, is inserted.<br />
<br />
In [[2.0.0-2|2.0.0-X]] TWL_FIRM, those commands were stubbed out.<br />
| ARM9 code execution<br />
| [[2.0.0-2|2.0.0-X]]<br />
| [[2.0.0-2|2.0.0-X]]<br />
| January 2018<br />
| Wiki: August 5, 2018<br />
| [[User:Riley|Riley]]<br />
|-<br />
| FAT FS code null-deref<br />
| When FSFile:Read is used with a file which is corrupted on a FAT filesystem(in particular SD), Process9 can crash. This particular crash is caused by a function returning NULL instead of an actual ptr due to an error. The caller of that function doesn't check for NULL which then triggers a read based at NULL.<br />
<br />
Sample "fsck.vfat -n -v -V <fat image backup>" output for the above crash:<br />
<br />
<pre>...<br />
Starting check/repair pass.<br />
<FilePath0> and<br />
<FilePath1><br />
share clusters.<br />
Truncating second to 3375104 bytes.<br />
<FilePath1><br />
File size is 2787392 bytes, cluster chain length is 16384 bytes.<br />
Truncating file to 16384 bytes.<br />
Checking for unused clusters.<br />
Reclaimed 1 unused cluster (16384 bytes).<br />
Checking free cluster summary.<br />
Free cluster summary wrong (1404490 vs. really 1404491)<br />
Auto-correcting.<br />
Starting verification pass.<br />
Checking for unused clusters.<br />
Leaving filesystem unchanged.</pre><br />
| Useless null-based-read<br />
| None<br />
| [[9.6.0-24|9.6.0-X]]<br />
| July 8-9, 2015<br />
| <br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| RSA signature padding checks<br />
| The TWL_FIRM RSA sig padding check code used for all TWL RSA sig-checks has issues, see [[FIRM|here]].<br />
The main 3DS RSA padding check code(non-certificate, including NATIVE_FIRM) uses the function used with the above to extract more padding + the actual hash from the additional padding. This isn't really a problem here because there's proper padding check code which is executed prior to this.<br />
| <br />
| None<br />
| [[9.5.0-22|9.5.0-X]]<br />
| March 2015<br />
| <br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[AMPXI:ValidateDSiWareSectionMAC]] [[AES_Registers|AES]] keyslot reuse<br />
| When the input DSiWare section index is higher than <max number of DSiWare sections supported by this FIRM>, Process9 uses keyid 0x40 for calculating the AESMAC, which translates to keyslot 0x40. The result is that the keyslot is left at whatever was already selected before, since the AES selectkeyslot code will immediately return when keyslot is >=0x40. However, actually exploiting this is difficult: the calculated AESMAC is never returned, this command just compares the calculated AESMAC with the input AESMAC(result-code depends on whether the AESMACs match). It's unknown whether a timing attack would work with this.<br />
This is basically a different form of the pxips9 keyslot vuln, except with AESMAC etc.<br />
| See description.<br />
| None<br />
| [[11.3.0-36|11.3.0-X]]<br />
| March 15, 2015<br />
| December 29, 2015<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| pxips9 [[AES_Registers|AES]] keyslot reuse<br />
| This requires access to the [[Process_Services|ps:ps]]/pxi:ps9 services. One way to get access to this would be snshax on system-version <=10.1.0-X(see 32c3 3ds talk).<br />
When an invalid key-type value is passed to any of the PS commands, Process9 will try to select keyslot 0x40. That aesengine_setkeyslot() code will then immediately return due to the invalid keyslot value. Since that function doesn't return any errors, Process9 will just continue to do crypto with whatever AES keyslot was selected before the PS command was sent.<br />
| Reusing the previously used keyslot, for crypto with PS.<br />
| None<br />
| [[11.3.0-36|11.3.0-X]]<br />
| Roughly the same time(same day?) as firmlaunch-hax.<br />
| December 29, 2015<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| firmlaunch-hax: FIRM header ToCToU<br />
| This can't be exploited from ARM11 userland.<br />
During [[FIRM]] launch, the only FIRM header the ARM9 uses at all is stored in FCRAM, this is 0x200-bytes(the actual used FIRM RSA signature is read to the Process9 stack however). The ARM9 doesn't expect "anything" besides the ARM9 to access this data.<br />
With [[9.5.0-22]] the address of this FIRM header was changed from a FCRAM address, to ARM9-only address 0x01fffc00.<br />
| ARM9 code execution<br />
| [[9.5.0-22]]<br />
| <br />
| 2012, 3 days after [[User:Yellows8|Yellows8]] started Process9 code RE.<br />
| <br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| Uninitialized data output for (PXI) command replies<br />
| PXI commands for various services(including some [[Filesystem_services_PXI|here]] and many others) can write uninitialized data (like from ARM registers) to the command reply. This happens with stubbed commands, but this can also occur with certain commands when returning an error.<br />
Certain ARM11 service commands have this same issue as well.<br />
| <br />
| None<br />
| [[9.3.0-21|9.3.0-X]]<br />
| ?<br />
| <br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[Filesystem_services_PXI|FSPXI]] OpenArchive SD permissions<br />
| Process9 does not use the exheader ARM9 access-mount permission flag for SD at all.<br />
This would mean ARM11-kernelmode code / fs-module itself could directly use FSPXI to access SD card without ARM9 checking for SD access, but this is rather useless since a process is usually running with SD access(Home Menu for example) anyway.<br />
| <br />
| None<br />
| [[9.3.0-21|9.3.0-X]]<br />
| 2012<br />
| <br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[AMPXI:ExportDSiWare]] export path<br />
| Process9 allocates memory on Process9 heap for the export path then verifies that the actual allocated size matches the input size. Then Process9 copies the input path from FCRAM to this buffer, and uses it with the Process9 FS openfile code, which use paths in the form of "<mountpoint>:/<path>".<br />
Process9 does not check the contents of this path at all before passing it to the FS code, besides writing a NUL-terminator to the end of the buffer.<br />
| Exporting of DSiWare to arbitrary Process9 file-paths, such as "nand:/<path>" etc. This isn't really useful since the data which gets written can't be controlled.<br />
| None<br />
| [[9.5.0-22]]<br />
| April 2013<br />
| <br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[DSiWare_Exports]] [[CTCert]] verification<br />
| Just like DSi originally did, 3DS verifies the APCert for DSiWare on SD with the CTCert also in the DSiWare .bin. On DSi this was fixed with with system-version 1.4.2 by verifying with the actual console-unique cert instead(stored in NAND), while on 3DS it's still not(?) fixed.<br />
On 3DS however this is useless, unless one can obtain the console-unique movable.sed keyY which encrypts the entire DSiWare .bin.<br />
| When the movable.sed keyY for the target 3DS is known and the target 3DS CTCert private-key is unknown, importing of modified DSiWare SD .bin files.<br />
| None.<br />
| 11.6.0-X<br />
| April 2013<br />
| <br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| seedminer: movable.sed keyY vulnerable to brute-force<br />
| Half of the movable.sed keyY's 128 bits are leaked through the [[Nandrw/sys/LocalFriendCodeSeed_B|LFCS]], which is available in userland and below. The LFCS itself also leaks almost half of the remaining bits by following the ratio: u32 keyY[3]=1/5(LFCS). The remaining keyY[3] uncertainty of about ±2000 can be greatly reduced by plotting expected error margins with several keyYs. This results in a final uncertainty of about 2^40, easily within practical brute force range of an average modern PC.<br />
| Knowing the keyY of a given 3ds allows for modification of DSiWare export contents, and chained with several other public vulns, ultimately arm9 execution.<br />
| None.<br />
| 11.6.0-X<br />
| December 2017<br />
| January 2018<br />
| zoogie<br />
|-<br />
| Improper validation of DSiWare title SRLs<br />
| The 3DS does not verify if the actual SRL embedded in the title's directory matches the titleID in the TMD before launching it or importing it from an sd DSiWare export. <br />
| This allows embedding older, exploitable DSiWare titles in completely different, unexploitable DSiWare titles. Since DSiWare has raw NAND RW, this can result in arm9 control through FIRM known-plaintext and sighax attacks.<br />
| None.<br />
| 11.6.0-X<br />
| 2015?<br />
| December 2016<br />
| Everyone<br />
|-<br />
| [[Gamecard_Services_PXI]] unchecked REG_CTRCARDCNT transfer-size<br />
| The u8 REG_CTRCARDCNT transfer-size parameter for the [[Gamecard_Services_PXI]] read/write CTRCARD commands is used as an index for an array of u16 values. Before [[5.0.0-11|5.0.0-X]] this u8 value wasn't checked, thus out-of-bounds reads could be triggered(which is rather useless in this case).<br />
| Out-of-bounds read for a value which gets written to a register.<br />
| [[5.0.0-11|5.0.0-X]]<br />
| <br />
| 2013?<br />
| <br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[PXI_Registers|PXI]] cmdbuf buffer overrun<br />
| The Process9 code responsible [[PXI_Registers|PXI]] communications didn't verify the size of the incoming command before writing it to a C++ member variable. <br />
| Probably ARM9 code execution<br />
| [[5.0.0-11|5.0.0-11]]<br />
| <br />
| March 2015, original timeframe if any unknown<br />
| <br />
| [[User:Plutooo|plutoo]]/[[User:Yellows8|Yellows8]]/maybe others(?)<br />
|-<br />
| [[Application_Manager_Services_PXI|PXIAM]] command 0x003D0108(See also [[Application_Manager_Services|this]])<br />
| When handling this command, Process9 allocates a 0x2800-byte heap buffer, then copies the 4 FCRAM input buffers to this heap buffer without checking the sizes at all(only the buffers with non-zero sizes are copied). Starting with [[5.0.0-11|5.0.0-X]], the total combined size of the input data must be <=0x2800.<br />
| ARM9 code execution<br />
| [[5.0.0-11|5.0.0-X]]<br />
| <br />
| May 2013<br />
| <br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[Process_Services_PXI|PS RSA]] commands buffer overflows<br />
| pxips9 cmd1(not accessible via ps:ps) and VerifyRsaSha256: unchecked copy to a buffer in Process9's .bss, from the input FCRAM buffer. The buffer is located before the pxi cmdhandler threads' stacks. SignRsaSha256 also has a buf overflow, but this isn't exploitable.<br />
The buffer for this is the buffer for the signature data. With v5.0, the signature buffer was moved to stack, with a check for the signature data size. When the signature data size is too large, Process9 uses [[SVC|svcBreak]].<br />
| ARM9 code execution<br />
| [[5.0.0-11|5.0.0-X]]<br />
| <br />
| 2012<br />
| <br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[PXI_Registers|PXI]] pxi_id bad check<br />
| The Process9 code responsible for [[PXI_Registers|PXI]] communications read pxi_id as a signed char. There were two flaws:<br />
* They used it as index to a lookup-table without checking the value at all.<br />
* Another function verified that pxi_id < 7, allowing negative values to pass the check. This would also cause an out-of-range table-lookup.<br />
| Maybe ARM9 code execution<br />
| [[3.0.0-5|3.0.0-5]]<br />
|<br />
| March 2015, originally 2012 for the first issue at least<br />
| <br />
| [[User:Plutooo|plutoo]], [[User:Yellows8|Yellows8]], maybe others(?)<br />
|}<br />
<br />
=== Kernel9 ===<br />
{| class="wikitable" border="1"<br />
|-<br />
! Summary<br />
! Description<br />
! Successful exploitation result<br />
! Fixed in [[FIRM]] system version<br />
! Last [[FIRM]] system version this flaw was checked for<br />
! Timeframe this was discovered<br />
! Discovered by<br />
|-<br />
| [[CONFIG Registers#CFG_SYSPROT9|CFG_SYSPROT9]] bit1 not set by Kernel9<br />
| Old versions of Kernel9 never set bit1 of [[CONFIG Registers#CFG_SYSPROT9|CFG_SYSPROT9]]. This leaves the [[OTP Registers|0x10012000]]-region unprotected (this region should be locked early during boot!). Since it's never locked, you can dump it once you get ARM9 code execution.<br />
<br />
From [[3.0.0-5|3.0.0-X]] this was fixed by setting the bit in Kernel9 after poking some registers in that region. On New3DS arm9loader sets this bit instead of Kernel9, which is exploitable through a hardware + software vulnerability (see arm9loaderhax / description).<br />
<br />
This flaw resurged when it gained a new practical use: retrieving the OTP data for a New3DS console in order to decrypt the key data used in arm9loader (see enhanced-arm9loaderhax / description). This was performed by downgrading to a vulnerable system version. By accounting for differences in CTR-NAND crypto (0x05 -> 0x04, see partition encryption types [[Flash_Filesystem#NAND_structure|here]]) and using an Old3DS [[NCSD#NCSD_header|NCSD Header]], it is possible to boot a New3DS using Old3DS firmware 1.0-2.x to retrieve the required OTP data using this flaw.<br />
| Dumping the [[OTP Registers|OTP]] area.<br />
Decrypting New3DS sector 0x96 keyblock.<br />
| [[3.0.0-5|3.0.0-X]]<br />
|<br />
| February 2015<br />
| [[User:Plutooo|plutoo]], Normmatt independently<br />
|}<br />
<br />
== ARM11 software ==<br />
=== Kernel11 ===<br />
{| class="wikitable" border="1"<br />
|-<br />
! Summary<br />
! Description<br />
! Successful exploitation result<br />
! Fixed in [[FIRM]] system version<br />
! Last [[FIRM]] system version this flaw was checked for<br />
! Timeframe this was discovered<br />
! Discovered by<br />
|-<br />
| [[SVC|svcSetProcessIdealProcessor]] reference count overflow and therefore use-after-free.<br />
| The SVC receive two arguments: handle and idealprocessor. The handle is used to get the KProcess object and the KProcess->refCnt gets incremented,later the function check if the KProcess->mem_type != BASE and if yes, it checks for idealprocessor == 2 or idealprocessor != 3. The problem here is that if you pass the idealprocessor = 3 it won't meet any condition and return the error 0xD9001BEA without decrement the reference count. <br />
It can be abused to overflow the KProcess reference count that will lead to an Use-after-free. <br />
| Before [[11.2.0-35|11.2.0-X]]: reference count overflow and therefore use-after-free.<br />
| <br />
| [[11.6.0-39|11.6.0-X]]<br />
| November 2, 2017<br />
| [[User:st4rk|st4rk]]<br />
|-<br />
| [[SVC|svcGetThreadList]] process reference leak<br />
| When given a valid process handle (including <code>0xFFFF8001</code>), svcGetThreadList forgets to decrement the reference count of the underlying [[KProcess]] instance, after having finished using it.<br />
| Before [[11.2.0-35|11.2.0-X]]: reference count overflow and therefore use-after-free, but this UAF was most likely not exploitable<br />
| <br />
| [[11.3.0-36|11.3.0-X]]<br />
| April 3, 2017<br />
| [[User:TuxSH|TuxSH]]<br />
|-<br />
| kernelhax via gspwn<br />
| Originally the kernel didn't initialize [[CONFIG11_Registers#CFG11_GPUPROT|CFG11_GPUPROT]]. Since it's 0 at hard-boot, this allowed the GPU to access the entire FCRAM + AXIWRAM.<br />
| Entire FCRAM+AXIWRAM R/W.<br />
| [[3.0.0-5|3.0.0-X]]<br />
| <br />
| February 7, 2017<br />
| [[User:Plutooo|plutoo]], [[User:Yellows8|Yellows8]] partly<br />
|-<br />
| fasthax<br />
| When a KTimer is created in pulse mode, the kernel calls a virtual function to reset the timer each time it pulses. The scheduler is locked for that core to avoid race conditions, but another core can call CloseHandle on the timer and free it, leading to a UAF vtable call.<br />
| See description.<br />
| [[11.3.0-36|11.3.0-X]]<br />
| [[11.3.0-36|11.3.0-X]]<br />
| May 2016<br />
| nedwill<br />
|-<br />
| ipctakeover<br />
| When sending cmdreplies, it does not validate that the src_addr and src_size match the equivalent dst_addr and dst_size. With a modified addr/size specified in a cmdreply for an output buffer, the data-copy for the first/last pages could be used to overwrite data outside of the buffer specified by the original process.<br />
<br />
Used by ctr-httpwn as of v1.2, for "ipctakeover/bosshaxx".<br />
<br />
This can be used to takeover processes where the process is using your service session. Like HTTPC -> BOSS, for bosshaxx above. NIM takeover can be done too(actual stack buffer overflow can trigger), etc.<br />
| See description.<br />
| None<br />
| [[11.3.0-36|11.3.0-X]]<br />
| November 26, 2016<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| Using IPC input buffers as output buffers<br />
| When sending cmdreplies, it does not validate that the cmdreply descriptor type matches the equivalent cmdreq descriptor type. This could be used by an exploited sysmodule to use what was intended as an input-buffer as an output-buffer, and also combine other IPC vuln(s) with this.<br />
<br />
Used by ctr-httpwn as of v1.2, for "ipctakeover/bosshaxx".<br />
| See description.<br />
| None<br />
| [[11.3.0-36|11.3.0-X]]<br />
| November 2016<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[SVC]] table too small<br />
| The table of function pointers for SVC's only contains entries up to 0x7D, but the biggest allowed SVC for the table is 0x7F. Thus, executing SVC7E or SVC7F would make the SVC-handler read after the buffer, and interpret some ARM instructions as function pointers.<br />
<br />
However, this would require patching the kernel .text or modifying SVC-access-control. Even if you could get these to execute, they would still jump to memory that isn't mapped as executable.<br />
| <br />
| None<br />
| [[11.3.0-36|11.3.0-X]]<br />
| 2012<br />
| Everyone<br />
|-<br />
| [[SVC|svcBackdoor (0x7B)]]<br />
| This backdoor allows executing SVC-mode code at the user-specified code-address. This is used by Process9, using this on the ARM11 (with NATIVE_FIRM) required patching the kernel .text or modifying SVC-access-control.<br />
| See description<br />
| [[11.0.0-33|11.0.0-X]] (deleted)<br />
| <br />
|<br />
| Everyone<br />
|-<br />
| veryslowpidhax<br />
| '''This is completely different from the kernelmode-code-execution vuln described in the below separate entry.'''<br />
<br />
When updating the kernel global PID counter under [[SVC|svcCreateProcess]] the kernel does not check for wraparound to 0x0(the PID for the very first process). This only matters because [[Services|SM-module]] allows processes with PID value less than <total ARM11 FIRM modules> to access ''all'' services, without checking exheader service-access-control; and because Kernel11 checks for the PID to be 1 (loader) to use the input mem-region value on ControlMemory. This alone does not affect access the [[SVC|SVCs]] access table at all.<br />
<br />
Inlined ldrex+strex code is used for updating the above counter. [[11.2.0-35|11.2.0-X]] had changes for similar code, but it was only for dedicated ldrex+strex functions(mainly for kernel objects) and hence this PID code was not affected.<br />
<br />
With launching+terminating a sysmodule repeatedly with this via ns:s, it would take weeks to finish(if not at least about a month?).<br />
| Access to all [[Services_API|services]], ControlMemory on any given mem-region.<br />
| None<br />
| [[11.3.0-36|11.3.0-X]]<br />
| 2012 maybe?<br />
| <br />
|-<br />
| slowhax/waithax<br />
| svcWaitSynchronizationN does not decrement the references to valid handles in an array before returning an error when it encounters an invalid handle. This allows one to (slowly) overflow the reference count for a handle object to zero.<br />
| ARM11 kernel-mode code execution<br />
| [[11.2.0-35|11.2.0-X]]<br />
| [[11.2.0-35|11.2.0-X]]<br />
| 2016<br />
| nedwill, [[User:Derrek|derrek]]<br />
|-<br />
| [[Memory_layout#ARM11_Detailed_virtual_memory_map|0xEFF00000]] / 0xDFF00000 ARM11 kernel virtual-memory<br />
| The ARM11 kernel-mode 0xEFF00000/0xDFF00000 virtual-memory(size 0x100000) is mapped to phys-mem 0x1FF00000(entire DSP-mem + entire AXIWRAM), with permissions RW-. This is used during ARM11 kernel startup for loading the FIRM-modules from the FIRM section located in DSP-mem, this never seems to be used after that, however. This is never unmapped either.<br />
| <br />
| None<br />
| [[11.3.0-36|11.3.0-X]]<br />
| <br />
| <br />
|-<br />
| memchunkhax2.1<br />
| Nintendo's fix for memchunkhax2 in [[10.4.0-29|10.4.0-X]] did not fix the GPU case: one may cause the requisite ToCToU race using gspwn, bypassing the new validation.<br />
derrek's original 32c3 presentation for memchunkhax2 commented that a GPU-based attack was possible, but would be difficult. However, memchunkhax2.1 showed that it was possible to do fairly reliably.<br />
| ARM11 kernel code execution<br />
| [[11.0.0-33|11.0.0-X]], via the new [[Memory_Management#MemoryBlockHeader|memchunkhdr]] MAC which prevents modifying memchunkhdr data with DMA.<br />
| [[11.0.0-33|11.0.0-X]]<br />
|<br />
| [[User:Derrek|derrek]], aliaspider<br />
|-<br />
| memchunkhax2<br />
| When allocating a block of memory, the "next" pointer of the [[Memory_Management#MemoryBlockHeader|memchunkhdr]] is accessed without being checked after being mapped to userland.<br />
This allows a race condition, where the process can change the next pointer just before it's accessed. By pointing the next pointer to a crafted memchunckhdr in the kernel SlabHeap, some of the SlabHeap is allocated to the calling process, allowing to change vtables of kernel objects. <br />
| ARM11 kernel code execution<br />
| [[10.4.0-29|10.4.0-X]] (partially, see memchunkhax2.1)<br />
| [[10.4.0-29|10.4.0-X]]<br />
|<br />
| [[User:Derrek|derrek]]<br />
|-<br />
| heaphax<br />
| Can change the size of free memchunk structures stored in FCRAM using DMA, which leads to the ability to allocate memory chunks over already-allocated memory. This can be used in the SYSTEM region to allocate RW memory over any part of the NS system module, which is enough to take it over.<br />
| Code execution with access to all of NS's privileges. (including downgrading) Code execution within any applet.<br />
| [[11.0.0-33|11.0.0-X]], via the new [[Memory_Management#MemoryBlockHeader|memchunkhdr]] MAC which prevents modifying memchunkhdr data with DMA.<br />
| [[11.0.0-33|11.0.0-X]]<br />
| April 2015 ?<br />
| smea<br />
|-<br />
| snshax<br />
| Can force creation of Safe NS process into gspwn-able memory, allowing for takeover.<br />
| Code execution with access to all of NS's privileges. (including downgrading)<br />
| [[10.1.0-27|10.1.0-X]]<br />
| [[10.1.0-27|10.1.0-X]]<br />
| April 2015 ?<br />
| smea<br />
|-<br />
| AffinityMask/processorid validation<br />
| With [[10.0.0-27|10.0.0-X]] the following functions were updated: svcGetThreadAffinityMask, svcGetProcessAffinityMask, svcSetProcessAffinityMask, and svcCreateThread. The code changes for all but svcCreateThread are identical.<br />
The original code with the first 3 did the following: <br />
* if(u32_processorcount > ~0x80000001)return 0xe0e01bfd;<br />
* if(s32_processorcount > <total_cores>)return 0xd8e007fd;<br />
The following code replaced the above:<br />
* if(u32_processorcount >= <total_cores+1>)return 0xd8e007fd;<br />
In theory the latter should catch everything that the former did, so it's unknown if this was really a security issue.<br />
<br />
The svcCreateThread changes with [[10.0.0-27|10.0.0-X]] definitely did fix a security issue.<br />
* Original code: "if(s32_processorid > <total_cores>)return 0xd8e007fd;"<br />
* New code: "if(s32_processorid >= <total_cores> || s32_processorid <= -4)return 0xd8e007fd;"<br />
This fixed an off-by-one issue: if one would use processorid=total_cores, which isn't actually a valid value, svcCreateThread would accept that value on <[[10.0.0-27|10.0.0-X]]. This results in data being written out-of-bounds(baseaddr = arrayaddr + entrysize*processorid), which has the following result:<br />
* Old3DS: Useless kernel-mode crash due to accessing unmapped memory.<br />
* New3DS: uncontrolled data write into a kernel-mode L1 MMU-table. This isn't really useful: the data can't be controlled, and the data which gets overwritten is all-zero anyway(this isn't anywhere near MMU L1 entries for actually mapped memory).<br />
The previous version also allowed large negative s32_processorid values(negative processorid values are special values not actual procids), but it appears using values like that won't actually do anything(meaning no crash) besides the thread not running / thread not running for a while(besides triggering a kernelpanic with certain s32_processorid value(s)).<br />
| Nothing useful<br />
| [[10.0.0-27|10.0.0-X]]<br />
| [[10.0.0-27|10.0.0-X]]<br />
| svcCreateThread issue: May 31, 2015. The rest: September 8, 2015, via v9.6->v10.0 ARM11-kernel code-diff.<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| memchunkhax<br />
| The kernel originally did not validate the data stored in the FCRAM kernel heap [[Memchunkhdr|memchunk-headers]] for free-memory at all. Exploiting this requires raw R/W access to these memchunk-headers, like physical-memory access with gspwn.<br />
<br />
There are ''multiple'' ways to exploit this, but the end-result for most of these is the same: overwrite code in AXIWRAM via the 0xEFF00000/0xDFF00000 kernel virtual-memory mapping.<br />
<br />
This was fixed in [[9.3.0-21|9.3.0-X]] by checking that the memchunk(including size, next, and prev ptrs) is located within the currently used heap memory. The kernel may also check that the next/prev ptrs are valid compared to other memchunk-headers basically. When any of these checks fail, kernelpanic() is called.<br />
| When combined with other flaws: ARM11-kernelmode code execution<br />
| [[9.3.0-21|9.3.0-21]]<br />
| <br />
| February 2014<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| Multiple [[KLinkedListNode|KLinkedListNode]] SlabHeap use after free bugs<br />
| The ARM11-kernel did access the 'key' field of [[KLinkedListNode|KLinkedListNode]] objects, which are located on the SlabHeap, after freeing them. Thus, triggering an allocation of a new [[KLinkedListNode|KLinkedListNode]] object at the right time could result in a type-confusion. Pseudo-code:<br />
SlabHeap_free(KLinkedListNode);<br />
KObject *obj = KLinkedListNode->key; // the object there might have changed!<br />
This bug appeared all over the place.<br />
| ARM11-kernelmode code exec maybe<br />
| [[8.0.0-18|8.0.0-18]]<br />
| <br />
| April 2015<br />
| [[User:Derrek|derrek]]<br />
|-<br />
| PXI [[RPC_Command_Structure|Command]] input/output buffer permissions<br />
| Originally the ARM11-kernel didn't check permissions for PXI input/output buffers for commands. Starting with [[6.0.0-11|6.0.0]] PXI input/output buffers must have RW permissions, otherwise kernelpanic is triggered.<br />
| <br />
| [[6.0.0-11|6.0.0-11]]<br />
| <br />
| 2012<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[SVC|svcStartInterProcessDma]]<br />
| For svcStartInterProcessDma, the kernel code had the following flaws:<br />
<br />
* Originally the ARM11-kernel read the input DmaConfig structure directly in kernel-mode(ldr(b/h) instructions), without checking whether the DmaConfig address is readable under userland. This was fixed by copying that structure to the SVC-mode stack, using the ldrbt instruction.<br />
<br />
* Integer overflows for srcaddr+size and dstaddr+size are now checked(with [[6.0.0-11]]), which were not checked before.<br />
<br />
* The kernel now also checks whether the srcaddr/dstaddr (+size) is within userland memory (0x20000000), the kernel now (with [[6.0.0-11]]) returns an error when the address is beyond userland memory. Using an address >=0x20000000 would result in the kernel reading from the process L1 MMU table, beyond the memory allocated for that MMU table(for vaddr->physaddr conversion). <br />
| <br />
| [[6.0.0-11]]<br />
| <br />
| DmaConfig issue: unknown. The rest: 2014<br />
| [[User:Plutooo|plutoo]], [[User:Yellows8|Yellows8]] independently<br />
|-<br />
| [[SVC|svcControlMemory]] Parameter checks<br />
| For svcControlMemory the parameter check had these two flaws:<br />
<br />
* The allowed range for addr0, addr1, size parameters depends on which MemoryOperation is being specified. The limitation for GSP heap was only checked if op=(u32)0x10003. By setting a random bit in op that has no meaning (like bit17?), op would instead be (u32)0x30003, and the range-check would be less strict and not accurate. However, the kernel doesn't actually use the input address for LINEAR memory-mapping at all besides the range-checks, so this isn't actually useful. This was fixed in the kernel by just checking for the LINEAR bit, instead of comparing the entire MemoryOperation value with 0x10003.<br />
<br />
* Integer overflows on (addr0+size) are now checked that previously weren't (this also applies to most other address checks elsewhere in the kernel).<br />
<br />
| <br />
| [[5.0.0-11]]<br />
| <br />
|<br />
| [[User:Plutooo|plutoo]]<br />
|-<br />
| [[RPC_Command_Structure|Command]] request/response buffer overflow<br />
| Originally the kernel did not check the word-values from the command-header. Starting with [[5.0.0-11]], the kernel will trigger a kernelpanic() when the total word-size of the entire command(including the cmd-header) is larger than 0x40-words (0x100-bytes). This allows overwriting threadlocalstorage+0x180 in the destination thread. However, since the data written there would be translate parameters (such as header-words + buffer addresses), exploiting this would likely be very difficult, if possible at all.<br />
<br />
If the two words at threadlocalstorage+0x180 could be overwritten with controlled data this way, one could then use a command with a buffer-header of <nowiki>((size<<14) | 2)</nowiki> to write arbitrary memory to any RW userland memory in the destination process.<br />
| <br />
| [[5.0.0-11]]<br />
| <br />
| v4.1 FIRM -> v5.0 code diff<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[SVC|SVC stack allocation overflows]]<br />
| <br />
* Syscalls that allocate a variable-length array on stack, only checked bit31 before multiplying by 4/16 (when calculating how much memory to allocate). If a large integer was passed as input to one of these syscalls, an integer overflow would occur, and too little memory would have been allocated on stack resulting in a buffer overrun. <br />
* The alignment (size+7)&~7 calculation before allocation was not checked for integer overflow.<br />
<br />
This might allow for ARM11 kernel code-execution.<br />
<br />
(Applies to svcSetResourceLimitValues, svcGetThreadList, svcGetProcessList, svcReplyAndReceive, svcWaitSynchronizationN.)<br />
| <br />
| [[5.0.0-11]]<br />
| <br />
| v4.1 FIRM -> v5.0 code diff<br />
| [[User:Plutooo|plutoo]], [[User:Yellows8|Yellows8]] complementary<br />
|-<br />
| [[SVC|svcControlMemory]] MemoryOperation MAP memory-permissions<br />
| svcControlMemory with MemoryOperation=MAP allows mapping the already-mapped process virtual-mem at addr1, to addr0. The lowest address permitted for addr1 is 0x00100000. Originally the ARM11 kernel didn't check memory permissions for addr1. Therefore .text as addr1 could be mapped elsewhere as RW- memory, which allowed ARM11 userland code-execution.<br />
| <br />
| [[4.1.0-8]]<br />
| <br />
| 2012<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[RPC_Command_Structure|Command]] input/output buffer permissions<br />
| Originally the ARM11 kernel didn't check memory permissions for the input/output buffers for commands. Starting with [[4.0.0-7]] the ARM11 kernel will trigger a kernelpanic() if the input/output buffers don't have the required memory permissions. For example, this allowed a FSUSER file-read to .text, which therefore allowed ARM11-userland code execution.<br />
| <br />
| [[4.0.0-7]]<br />
| <br />
| 2012<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[SVC|svcReadProcessMemory/svcWriteProcessMemory memory]] permissions<br />
| Originally the kernel only checked the first page(0x1000-bytes) of the src/dst buffers, for svcReadProcessMemory and svcWriteProcessMemory. There is no known retail processes which have access to these SVCs.<br />
| <br />
| [[4.0.0-7]]<br />
| <br />
| 2012?<br />
| [[User:Yellows8|Yellows8]]<br />
|}<br />
<br />
=== [[FIRM]] Sysmodules ===<br />
{| class="wikitable" border="1"<br />
|-<br />
! Summary<br />
! Description<br />
! Successful exploitation result<br />
! Fixed in [[FIRM]] system version<br />
! Last [[FIRM]] system version this flaw was checked for<br />
! Timeframe this was discovered<br />
! Discovered by<br />
|-<br />
| [[Services|"srv:pm"]] process registration<br />
| Originally any process had access to the port "srv:pm". The PID's used for the (un)registration commands are not checked either. This allowed any process to re-register itself with "srv:pm", and therefore allowed the process to give itself access to any service, bypassing the exheader service-access-control list.<br />
<br />
This was fixed in [[7.0.0-13]]: starting with [[7.0.0-13]] "srv:pm" is now a service instead of a globally accessible port. Only processes with PID's less than 6 (in other words: fs, ldr, sm, pm, pxi modules) have access to it. With [[7.0.0-13]] there can only be one session for "srv:pm" open at a time(this is used by pm module), svcBreak will be executed if more sessions are opened by the processes which can access this.<br />
<br />
This flaw was needed for exploiting the <=v4.x Process9 PXI vulnerabilities from ARM11 userland ROP, since most applications don't have access to those service(s).<br />
| Access to arbitrary services<br />
| [[7.0.0-13]]<br />
| <br />
| 2012<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| FSDIR null-deref<br />
| [[Filesystem_services|FS]]-module may crash in some cases when handling directory reading. The trigger seems to be due to using [[FSDir:Close]] without closing the dir-handle afterwards?(Perhaps this is caused by out-of-memory?) This seems to be useless since it's just a null-deref.<br />
| <br />
| None<br />
| [[9.6.0-24|9.6.0-X]]<br />
| May 19(?)-20, 2015<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[SM]] out-of-bounds BSS write (table 1 entry too small)<br />
| After accepting a new session, [[SM]] writes a (handler ID (0 for srv: sessions (max. 64), 1 for the srv:pm one), pointer to session context structure in BSS) pair in a global array. However that array is only 64-entry-big instead of 65 (as it ought to be), and no bound check is done in that regard.<br />
<br />
Unfortunately, as of [[11.4.0-37]], the overwritten fields are totally unused after their initialization by <code>__libc_init_array</code>.<br />
| Not currently exploitable<br />
| None<br />
| [[11.4.0-37]]<br />
|<br />
|<br />
|}<br />
<br />
=== Standalone Sysmodules ===<br />
{| class="wikitable" border="1"<br />
|-<br />
! Summary<br />
! Description<br />
! Successful exploitation result<br />
! Fixed in system-module system-version<br />
! Last system-module system-version this flaw was checked for<br />
! Timeframe this was discovered<br />
! Timeframe this was added to wiki<br />
! Discovered by<br />
|-<br />
| [[MP:SendDataFrame]] missing input array index validation<br />
| [[MP:SendDataFrame]] doesn't validate the input index at cmdreq[1], unless the function for flag=non-zero is executed. This is used to calculate the following, without validating the index at all: someptr = stateptr + (index*0x924) + somestateoffset.<br />
<br />
After validating some flags from someptr, when input_flag=0 the input buffer data is copied to someptr+someotheroffset+0x14 with the u16 size loaded from someptr+someotheroffset.<br />
<br />
With a large input index someptr could be setup to be at a <target address>, for overwriting memory.<br />
<br />
This is probably difficult to exploit.<br />
| <br />
| None<br />
| [[8.0.0-18]](MP-sysmodule v2048)<br />
| January 22, 2017<br />
| January 22, 2017<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[MP_Services|MP]] cmd1 out-of-bounds handle read<br />
| MP-sysmodule handles the input parameter for cmd1 as a s32. It checks for >=16, but not <0. With <16 it basically does the following(array of entries 4-bytes each): *outhandle = ((Handle*)(stateptr+offsetinstate))[inputindex].<br />
<br />
Hence, this can be used to load any handle in MP-sysmodule memory. MP doesn't really have any service handles of interest however(can be obtained from elsewhere too).<br />
| Reading any handle in MP-sysmodule memory.<br />
| None<br />
| [[8.0.0-18]](MP-sysmodule v2048)<br />
| January 21, 2017<br />
| January 22, 2017<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| AM stack/.bss infoleak via [[AM:ReadTwlBackupInfo]]([[AM:ReadTwlBackupInfoEx|Ex]])<br />
| After writing the output-info structure to stack, it then copies that structure to the output buffer ptr using the size from the command. The size is not checked. This could be used to read data from the AM-service-thread stack handling the command + .bss.<br />
<br />
'''This was not tested on hardware.'''<br />
| Stack/.bss reading<br />
| None<br />
| [[10.0.0-27]](AM v9217)<br />
| Roughly October 17, 2016<br />
| October 25, 2016<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[MVD_Services|MVD]]: Stack buffer overflow with [[MVDSTD:SetupOutputBuffers]].<br />
| The input total_entries is not validated when initially processing the input entry-list. This fixed-size input entry-list is copied to stack from the command request. The loop for processing this initializes a global table, the converted linearmem->physaddrs used there are also copied to stack(0x8-bytes of physaddrs per entry).<br />
<br />
If total_entries is too large, MVD-sysmodule will crash due to reading unmapped memory following the stack(0x10000000). Afterwards if the out-of-bounds total_entries is smaller than that, it will crash due accessing address 0x0, hence this useless.<br />
| MVD-sysmodule crash.<br />
| None<br />
| [[9.0.0-20]]<br />
| April 22, 2016 (Tested on the 25th)<br />
| April 25, 2016<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[NWM_Services|NWM]]: Using CTRSDK heap with UDS sharedmem from the user-process.<br />
| See the HTTP-sysmodule section below.<br />
<br />
CTRSDK heap is used with the sharedmem from [[NWMUDS:InitializeWithVersion]]. Buffers are allocated/freed under this heap using [[NWMUDS:Bind]] and [[NWMUDS:Unbind]].<br />
<br />
Hence, overwriting sharedmem with gspwn then using [[NWMUDS:Unbind]] results in the usual controlled CTRSDK memchunk-header write, similar to HTTP-sysmodule.<br />
<br />
This could be done by creating an UDS network, without any other nodes on the network.<br />
<br />
Besides CTRSDK memchunk-headers, there are no addresses stored under this sharedmem.<br />
| ROP under NWM-module.<br />
| [[11.4.0-37|11.4.0-X]]<br />
| [[9.0.0-20|9.0.0-X]]<br />
| April 10, 2016<br />
| April 16, 2016<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[DLP_Services|DLP]]: Out-of-bounds memory access during spectator [[Download_Play|data-frame]] checksum calculation<br />
| DLP doesn't validate the frame_size when receiving spectator data-frames at all, unlike non-spectator data-frames. The actual spectator data-frame parsing code doesn't use that field either. However, the data-frame checksum calculation code called during checksum verification does use the frame_size for loading the size of the framebuf.<br />
<br />
Hence, using a large frame_size like 0xFFFF will result in the checksum calculation code reading data out-of-bounds. This isn't really useful, you could trigger a remote local-WLAN DLP-sysmodule crash while a 3DS system is scanning for DLP networks(due to accessing unmapped memory), but that's about all(trying to infoleak with this likely isn't useful either).<br />
| DLP-sysmodule crash, handled by dlplay system-application by a "connection interrupted" error eventually then a fatal-error via ErrDisp.<br />
| None<br />
| [[10.0.0-27|10.0.0-X]]<br />
| April 8, 2016 (Tested on the 10th)<br />
| April 10, 2016<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[DLP_Services|DLP]]: Out-of-bounds output data writing during spectator sysupdate titlelist [[Download_Play|data-frame]] handling<br />
| The total_entries and out_entryindex fields for the titlelist DLP spectator data-frames are not validated. This is parsed during DLP network scanning. Hence, the specified titlelist data can be written out-of-bounds using the specified out_entryindex and total_entries. A crash will occur while reading the input data-frame titlelist if total_entries is larger than 0x27A, due to accessing unmapped memory.<br />
<br />
There's not much non-zero data to overwrite following the output buffer(located in sharedmem), any ptrs are located in sharedmem. Overwriting certain ptr(s) are only known to cause a crash when attempting to use the DLP-client shutdown service-command.<br />
<br />
There's no known way to exploit the above crash, since the linked-list code involves writes zeros(with a controlled start ptr).<br />
| <br />
| None<br />
| [[10.0.0-27|10.0.0-X]]<br />
| April 8-9, 2016<br />
| April 10, 2016<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[IR_Services|IR]]: Stack buffer overflow with custom hardware<br />
| Originally IR sysmodule used the read value from the I2C-IR registers TXLVL and RXLVL without validating them at all. See [[10.6.0-31|here]] for the fix. This is the size used for reading the data-recv FIFO, etc. The output buffer for reading is located on the stack.<br />
<br />
This should be exploitable if one could successfully setup the custom hardware for this and if the entire intended sizes actually get read from I2C.<br />
| ROP under IR sysmodule.<br />
| [[10.6.0-31|10.6.0-31]]<br />
| <br />
| February 23, 2016 (Unknown if it was noticed before then)<br />
| February 23, 2016<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[HTTP_Services|HTTP]]: Using CTRSDK heap with sharedmem from the user-process.<br />
| The data from httpcAddPostDataAscii and other commands is stored under a CTRSDK heap. That heap is the sharedmem specified by the user-process via the HTTPC Initialize command.<br />
Normally this sharedmem isn't accessible to the user-process once the sysmodule maps it, hence using it is supposed to be "safe".<br />
<br />
This isn't the case due to gspwn however. Since CTRSDK heap code is so insecure in general, one can use gspwn to locate the HTTPC sharedmem + read/write it, then trigger a mem-write under the sysmodule. This can then be used to get ROP going under HTTP-sysmodule.<br />
<br />
This is exploited by [https://github.com/yellows8/ctr-httpwn/ctr-httpwn ctr-httpwn].<br />
| ROP under HTTP sysmdule.<br />
| [[11.4.0-37|11.4.0-X]]<br />
| [[9.6.0-24|9.6.0-X]] (Latest sysmodule version as of [[10.7.0-32|10.7.0-32]])<br />
| Late 2015<br />
| March 22, 2016<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[NIM_Services|NIM]]: Downloading old title-versions from eShop<br />
| Multiple NIM service commands(such as [[NIMS:StartDownload]]) use a title-version value specified by the user-process, NIM does not validate that this input version matches the latest version available via SOAP. Therefore, when combined with AM(PXI) [[#Process9|title-downgrading]] via deleting the target eShop title with System Settings Data Management(if the title was already installed), this allows downloading+installing any title-version from eShop ''if'' it's still available from CDN.<br />
The easiest way to exploit this is to just patch the eShop system-application code using these NIM commands(ideally the code which loads the title-version).<br />
<br />
Originally this was tested with a debugging-system via modded-FIRM, eventually smea implemented it in HANS for the 32c3 release.<br />
| Downloading old title-versions from eShop<br />
| None<br />
| [[10.0.0-27|10.0.0-X]]<br />
| October 24, 2015 (Unknown when exactly the first eShop title downgrade was actually tested, maybe November)<br />
| January 7, 2016 (Same day Ironfall v1.0 was removed from CDN via the main-CXI files)<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[SPI_Services|SPI]] service out-of-bounds write<br />
| cmd1 has out-of-bounds write allowing overwrite of some static variables in .data.<br />
| <br />
| None<br />
| [[9.5.0-22]]<br />
| March 2015<br />
| <br />
| [[User:Plutooo|plutoo]]<br />
|-<br />
| [[NFC_Services|NFC]] module service command buf-overflows<br />
| NFC module copies data with certain commands, from command input buffers to stack without checking the size. These commands include the following, it's unknown if there's more commands with similar issues: "nfc:dev" <0x000C....> and "nfc:s" <0x0037....>.<br />
Since both of these commands are stubbed in the Old3DS NFC module from the very first version(those just return an error), these issues only affect the New3DS NFC module.<br />
<br />
There's no known retail titles which have access to either of these services.<br />
| ROP under NFC module.<br />
| New3DS: None<br />
| New3DS: [[9.5.0-22]]<br />
| December 2014?<br />
| <br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[News_Services|NEWSS]] service command notificationID validation failure<br />
| This module does not validate the input notificationID for <nowiki>"news:s"</nowiki> service commands. This is an out-of-bounds array index bug. For example, [[NEWSS:SetNotificationHeader]] could be used to exploit news module: this copies the input data(size is properly checked) to: out = newsdb_savedata+0x10 + (someu32array[notificationID]*0x70).<br />
| ROP under news module.<br />
| None<br />
| [[9.7.0-25|9.7.0-X]]<br />
| December 2014<br />
| <br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[NWMUDS:DecryptBeaconData]] heap buffer overflow<br />
| input_size = 0x1E * <value the u8 from input_[[NWM_Services|networkstruct]]+0x1D>. Then input_tag0 is copied to a heap buffer. When input_size is larger than 0xFA-bytes, it will then copy input_tag1 to <end_address_of_previous_outbuf>, with size=input_size-0xFA.<br />
<br />
This can be triggered by either using this command directly, or by boadcasting a wifi beacon which triggers it while a 3DS system running the target process is in range, when the process is scanning for hosts to connect to. Processes will only pass tag data to this command when the wlancommID and other thing(s) match the values for the process.<br />
<br />
There's no known way to actually exploit this for getting ROP under NWM-module, at the time of originally adding this to the wiki. This is because the data which gets copied out-of-bounds *and* actually causes crash(es), can't be controlled it seems(with just broadcasting a beacon at least). It's unknown whether this could be exploited from just using NWMUDS service-cmd(s) directly.<br />
| Without any actual way to exploit this: NWM-module DoS, resulting in process termination(process crash). This breaks *everything* involving wifi comms, a reboot is required to recover from this.<br />
| None<br />
| [[9.0.0-20]]<br />
| ~September 23, 2014(see the [[NWMUDS:DecryptBeaconData]] page history)<br />
| August 3, 2015<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[HID_Services|HID]] module shared-mem<br />
| HID module does not validate the index values in [[HID_Shared_Memory|sharedmem]](just changes index to 0 when index == maxval when updating), therefore large values will result in HID module writing HID data to arbitrary addresses.<br />
| ROP under HID module, but this is *very* unlikely to be exploitable since the data written is HID data.<br />
| None<br />
| [[9.3.0-21]]<br />
| 2014?<br />
| <br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| gspwn<br />
| GSP module does not validate addresses given to the GPU. This allows a user-mode application/applet to read/write to a large part of physical FCRAM using GPU DMA. From this, you can overwrite the .text segment of the application you're running under, and gain real code-execution from a ROP-chain. Normally applets' .text([[Home Menu]], [[Internet Browser]], etc) is located beyond the area accessible by the GPU, except for [[RO_Services|CROs]] used by applets([[Internet Browser]] for example).<br />
<br />
FCRAM is gpu-accessible up to physaddr 0x26800000 on Old3DS, and 0x2D800000 on New3DS. This is BASE_memregion_start(aka SYSTEM_memregion_end)-0x400000 (0x800000 with New3DS) with the default memory-layout on Old3DS/New3DS. With [[11.3.0-36|11.3.0-X]] the cutoff now varies due to the new [[SVC]] 0x59. The New3DS "normal"(non-APPLICATION) cutoff was changed to 0x2D000000 due to the new [[SVC]] 0x59.<br />
| User-mode code execution.<br />
| None<br />
| [[9.6.0-24|9.6.0-X]]<br />
| Early 2014<br />
| <br />
| smea, [[User:Yellows8|Yellows8]]/others before then<br />
|-<br />
| rohax<br />
| Using gspwn, it is possible to overwrite a loaded [[CRO0]]/[[CRR0]] after its RSA-signature has been validated. Badly validated [[CRO0]] header leads to arbitrary read/write of memory in the ro-process. This gives code-execution in the ro module, who has access to [[SVC|syscalls]] 0x70-0x72, 0x7D.<br />
<br />
This was fixed after [[ninjhax]] release by adding checks on [[CRO0]]-based pointers before writing to them.<br />
| Memory-mapping syscalls.<br />
| [[9.3.0-21]]<br />
| [[9.4.0-21]]<br />
| <br />
| <br />
| smea, [[User:Plutooo|plutoo]] joint effort<br />
|-<br />
| Region free<br />
| Only [[Home Menu]] itself checks gamecards' region when launching them. Therefore, any application launch that is done directly with [[NS]] without signaling Home Menu to launch the app, will result in region checks being bypassed.<br />
This essentially means launching the gamecard with the [[NS_and_APT_Services|"ns:s"]] service. The main way to exploit this is to trigger a FIRM launch with an application specified, either with a normal FIRM launch or a hardware [[NSS:RebootSystem|reboot]].<br />
| Launching gamecards from any region + bypassing Home Menu gamecard-sysupdate installation<br />
| None<br />
| Last tested with [[10.1.0-27|10.1.0-X]].<br />
| June(?) 2014<br />
| <br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[NWM_Services|NWM]] service-cmd state null-ptr deref<br />
| The NWMUDS service command code loads a ptr from .data, adds an offset to that, then passes that as the state address for the actual command-handler function. The value of the ptr loaded from .data is not checked, therefore this will cause crashes due to that being 0x0 when NWMUDS was not properly initialized.<br />
It's unknown whether any NWM services besides NWMUDS have this issue.<br />
| This is rather useless since it's only a crash caused by a state ptr based at 0x0.<br />
| None<br />
| [[9.0.0-20]]<br />
| 2013?<br />
| <br />
| [[User:Yellows8|Yellows8]]<br />
|}<br />
<br />
=== General/CTRSDK ===<br />
{| class="wikitable" border="1"<br />
|-<br />
! Summary<br />
! Description<br />
! Successful exploitation result<br />
! Fixed in version<br />
! Last version this flaw was checked for<br />
! Timeframe this was discovered<br />
! Discovered by<br />
|-<br />
| [[NWM_Services|UDS]] beacon additional-data buffer overflow<br />
| Originally CTRSDK did not validate the UDS additional-data size before using that size to copy the additional-data to a [[NWM_Services|networkstruct]]. This was eventually fixed.<br />
This was discovered while doing code RE with an old dlp-module version. It's unknown in what specific CTRSDK version this was fixed, or even what system-version updated titles with a fixed version.<br />
<br />
It's unknown if there's any titles using a vulnerable CTRSDK version which are also exploitable with this(dlp module can't be exploited with this).<br />
<br />
The maximum number of bytes that can be written beyond the end of the outbuf is 0x37-bytes, with additionaldata_size=0xFF.<br />
| Perhaps ROP, very difficult if possible with anything at all<br />
| ?<br />
| <br />
| September(?) 2014<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| CTPK buffer overflow<br />
| At offset 0x20 in CTPK is an array for each texture, each entry is 0x20-bytes. This contains a wordindex(entry+0x18) for some srcdata relative to CTPK+0, and an u8 wordsize(entry+0x14) for this data. The CTRSDK function handling this doesn't validate the size, when copying srcdata using this size to the output buffer. Applications usually have the output buffer on the stack, hence stack buffer overflow.<br />
<br />
While CTPK(*.ctpk) are normally only loaded from RomFS, some application(s) load from elsewhere too.<br />
| ROP under the target application.<br />
| None?<br />
| "[SDK+NINTENDO:CTR_SDK-11_4_0_200_none]"<br />
| November 14, 2016<br />
| [[User:Yellows8|Yellows8]]<br />
|}</div>Myriahttps://www.3dbrew.org/w/index.php?title=3DS_Userland_Flaws&diff=208083DS Userland Flaws2018-08-12T04:55:09Z<p>Myria: /* System applets */ smea's defcon presentation: mhax</p>
<hr />
<div>This page lists vulnerabilities / exploits for 3DS applications and applets. Exploiting these initially results in ROP, from that ROP one can then for example try exploiting [[3DS_System_Flaws|system]] flaw(s).<br />
<br />
=Non-system applications=<br />
{| class="wikitable" border="1"<br />
|-<br />
! Application name<br />
! Summary<br />
! Description<br />
! Fixed in app/system version<br />
! Last app/system version this flaw was checked for<br />
! Timeframe info related to this was added to wiki<br />
! Timeframe this vuln was discovered<br />
! Vuln discovered by<br />
|-<br />
| Cubic Ninja<br />
| Map-data stack smash<br />
| See [[Ninjhax|here]] regarding Ninjhax.<br />
| None<br />
| App: Initial version. System: [[10.4.0-29]].<br />
| Ninjhax release<br />
| July 2014<br />
| [[User:smea|smea]]<br />
|-<br />
| The Legend of Zelda: Ocarina of Time 3D<br />
| UTF-16 name string buffer overflow via unchecked u8 length field<br />
| The u8 at offset 0x2C in the savefile is the character-length of the UTF-16 string at offset 0x1C. When copying this string, it's essentially a memory-copy with lenval*2, not a string-copy. This can be used to trigger buffer overflows at various locations depending on the string length.<br />
* When value is >=0x6E it crashes when saving the saveslot, this causes a stack-smash however it normally crashes before it returns from the function which had the stack-frame overwritten.<br />
* With value >=0x9A, it crashes via stack-smash in-game once any dialogs are opened(touching buttons on the touch-screen can trigger it too).<br />
* Length value>=0xCD causes a crash while loading the saveslot, via a heap buffer overflow. This buf-overflow overwrites a heap memchunk following the allocated buffer. When the first 16-bits overwriting that heap memchunk is not the memchunk magic-number(0x7373), the mem-alloc code will just return a NULL ptr which later results in a crash. When the magic-number is valid, the mem-alloc code will continue to attempt to parse the memchunk, which may crash depending on the data which overwrote the memchunk. This heap code is separate from the CTRSDK heap code. Exploiting this doesn't seem to be possible: since the heap code actually verifies that the magic-number for the next/prev memchunk ptrs are correct(unlike CTRSDK), it's not possible to change those ptrs to useful arbitrary addresses outside of savedata(like with triggering a write to a c++ object ptr which later is used with a vtable func-call, this is what one would do with CTRSDK heap here).<br />
<br />
On March 11, 2015, an exploit using this vuln was released, that one was intended for warez/etc. The following exploit wasn't released before then mainly because doing so would (presumably) result in the vuln being fixed. The following old exploit was released on March 14, 2015: [https://github.com/yellows8/oot3dhax].<br />
| None<br />
| App: Initial version. System: [[10.6.0-31]].<br />
| March 11, 2015<br />
| Around October 22, 2012<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| Super Smash Bros 3DS<br />
| Buffer overflow in local-multiplayer beacon handling.<br />
| See [[smashbroshax|here]].<br />
| App: v1.1.3<br />
| See [[smashbroshax|here]]. System: [[10.3.0-28]].<br />
| Time of exploit release.<br />
| See [[smashbroshax|here]].<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| Pokemon Super Mystery Dungeon<br />
| Heap overflow within linear memory via unchecked save file length<br />
| Pokemon Super Mystery Dungeon uses zlib compression for most of its save files, possibly due to the save files being larger than its predecessor, Gates to Infinity. When a save file is being prepared to be loaded and read from, only a 0x32000 large buffer is allocated for file reading, and a 0x3e800-large buffer for decompression is also allocated before the file is read. However, the game does not limit the size of the file read to this allocation bound, allowing for the file to overflow into the linear memory heap and into the next allocation. Since Pokemon Super Mystery Dungeon stores allocation memchunks directly before the allocation, overwriting the next memchunk with a corrupted one allows for arbitrary writes of linear heap pointers when the next buffer is allocated or arbitrary writes of any pointer within writable memory when the corrupted buffer is freed.<br />
| None<br />
| O3DS: [[11.3.0-36]]. N3DS: [[11.4.0-37]].<br />
| Time of exploit release.<br />
| April 14, 2016<br />
| [[User:Shinyquagsire23|Shiny Quagsire]]<br />
|-<br />
| VVVVVV<br />
| Buffer overflow in XML save file array parsing<br />
| VVVVVV utilizes several XML files (renamed with a .vvv extension) to store level save data, stats and settings. Within these XML files are several tags containing an array of data which, when parsed, is not properly checked to be of proper length for the tag being parsed from. This allows for an overflow of 16-bit array values from the location where the array is parsed. With unlock.vvv, XML data is parsed to the stack, and with level saves the heap. This allows for the pointer where the level save worldmap tag array should be parsed into to be overwritten with a stack address, allowing for ROP from within the XML array parsing function on the next level load.<br />
| App: v1.1<br />
| [[10.7.0-32]].<br />
| Time of exploit release.<br />
| April 25, 2016<br />
| [[User:Shinyquagsire23|Shiny Quagsire]]<br />
|-<br />
| Citizens of Earth<br />
| Save file read stack smash<br />
| Citizens of Earth also uses "XML" files for saves, which are actually entirely binary data (not XML at all) with no checksums. These files are read from the filesystem on to a fixed size stack buffer which leads to an incredibly trivial stack smash. When using the autosave slot for this, the save is parsed when the user selects "continue". When using one of the dedicated save slots (1-3), the save is parsed shortly after the company splash screens fade. Note that the save is read quite high (descending) on the stack - when exploiting this, one would likely need to move SP due to almost instantly overflowing the physical stack.<br />
| None<br />
| [[10.7.0-32]].<br />
| Time of exploit release.<br />
| May 5, 2016<br />
| [[User:Dazzozo|Dazzozo]]<br />
|-<br />
| SmileBASIC 3.x<br />
| Poor parameter validation on "BGSCREEN" command<br />
| The SmileBASIC "BGSCREEN" command's second parameter is not properly validated as being within range. As a result, one can set the screen size to an absurdly large value. This means that the "BGGET" and "BGPUT" commands can then be used on out-of-range values to read and write a significant chunk of the interpreter's address space.<br />
With a series of carefully-designed BGPUT commands, one can build a ROP chain and cause it to be executed.<br />
| App: 3.3.2.<br />
| System: [[11.0.0-33]].<br />
| July 20, 2016<br />
| Around June 26, 2016<br />
| slackerSnail, 12Me12, incvoid<br />
Exploited by MrNbaYoh and [[User:Plutooo|plutoo]].<br />
|-<br />
| The Legend of Zelda: Tri Force Heroes<br />
| [[3DS_System_Flaws#General.2FCTRSDK|CTRSDK]] CTPK buffer overflow combined with game's usage of SpotPass<br />
| During the very first screen displayed by the game during boot("Loading..."), just seconds after title launch, the game loads CTPK from the [[BOSS_Services|stored]] SpotPass content. Hence, this game could be exploited via the vulnerable CTRSDK CTPK code ''if'' one could get custom SpotPass data into extdata somehow(ctr-httpwn >=v1.2 with bosshaxx allows this).<br />
<br />
The code for this runs from a thread separate from the main-thread, with the stack in linearmem heap. This SpotPass handling triggers before the game ever opens the regular savedata archive. The extdata is opened at some point before this: it opens a file for checking if it exists, then immediately closes it.<br />
<br />
The two SpotPass URLs for this have always(?) returned HTTP 404 as of November 2016. It appears these were intended for use as textures for additional costumes(and never got used publicly), but this wasn't tested.<br />
<br />
This is used by [https://github.com/yellows8/ctpkpwn ctpkpwn_tfh].<br />
| None<br />
| App: v2.1.0<br />
| November 18, 2016<br />
| November 14, 2016<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| Pixel Paint<br />
| Buffer overflow via unchecked extdata file length<br />
| Pixel Paint loads pictures saved by the user from extdatas. The file is read to a fixed size buffer but the file length remains unchecked, so with a large enough file, one can overwrite pointers in memory and gain control of the execution flow.<br />
| None<br />
| App: Initial version. System: [[11.2.0-35]].<br />
| December 27, 2016<br />
| November 5, 2016<br />
| [[User:Nba_Yoh|MrNbaYoh]]<br />
|-<br />
| Steel Diver : Sub Wars<br />
| Heap overflow / arbitrary memcpy<br />
| Savefile datas are stored as key/value pairs, a large enough string key makes the game overwrite a memcpy source/destination addresses and size arguments. So one can actually memcpy a rop on the stack and gain control of the execution flow.<br />
| None<br />
| System: [[11.2.0-35]].<br />
| December 27, 2016<br />
| Around July 15, 2016<br />
| [[User:Nba_Yoh|MrNbaYoh]], Vegaroxas<br />
|-<br />
| 1001 Spikes<br />
| Buffer overflow via unchecked array-indexes in XML savefile parsing<br />
| The savefiles are stored as renamed .xml files, which contain several tags with attributes like 'array-index="array-value"', where both of these are converted from ASCII strings to integers as signed-int32, and the array-value given blindly written to an array inside a structure using the (unchecked) index given. With several of these attributes, one can overwrite the stack starting from the stored lr of the function that does this parsing, and write a ROP chain there. Testing used the "LevelAttempts" tag which is the last such tag parsed in that function.<br />
| None<br />
| App: v1.2.0 (TMD v2096)<br />
| December 27, 2016<br />
| Around November 2, 2016<br />
| [[User:Riley|Riley]]<br />
|-<br />
| Pokemon Omega Ruby/Alpha Sapphire<br />
| Secret base team name heap overflow<br />
| When the player wants to edit the team name, it is copied over the heap, however its length is not verified. So with a large enough team name one can overwrite some pointers and get two arbitrary jumps and then get control of the execution flow.<br />
| None<br />
| App: 1.4. System: [[11.2.0-35]].<br />
| December 30, 2016<br />
| June, 2016<br />
| [[User:Nba_Yoh|MrNbaYoh]]<br />
|-<br />
| Swapdoodle<br />
| Heap buffer overflow via unchecked size<br />
| The letter file format used by doodlebomb is composed of multiple chunks. Each chunks is described in the header of the file where the name, size and CRC of each chunk are stored. Some chunks are meant to be headers, every header's size should be 0x80, however the length of the STAHED1 chunk remains unchecked and the game memcpy the chunk to a 0x80 byte buffer with the length provided in the file. This way one is able to overwrite some pointers and get control of the execution flow.<br />
| App: > v1.1.1<br />
| App: v1.1.1<br />
| April 24, 2017<br />
| February, 2017<br />
| [[User:Nba_Yoh|MrNbaYoh]]<br />
|-<br />
| Pokemon Picross<br />
| Arbitrary memcpy via unchecked size<br />
| When reading the savefile, the game handles some lists of buffers that are copied to memory. These buffers should always be 0x14-bytes long but the game uses the size provided in the savefile to copy them. These buffers are copied in some structs and thus with a big enough length value, one can overwrite the next struct which contains a size and a destination address for a memcpy.<br />
| None?<br />
| App: ?<br />
| May 29, 2017<br />
| June, 2016<br />
| [[User:Nba_Yoh|MrNbaYoh]]<br />
|-<br />
| RPG Maker Fes/Player<br />
| Buffer overflow on .bss section<br />
| When loading a project, the game copies multiple chunks over the BSS section. However the number of chunks to copy is not checked, thus a large amount of chunk result in a buffer overflow. There's multiple way to exploit this flaw to gain an arbitrary memcpy or an arbitrary jump.<br />
| None?<br />
| App: ?<br />
| August 28, 2017<br />
| August, 2017<br />
| [[User:Nba_Yoh|MrNbaYoh]]<br />
|-<br />
| RPG Maker Fes/Player<br />
| Buffer overflow via unchecked file size<br />
| When loading a project, the game loads the file to a 0x200000 bytes long buffer. However the size remains unchecked, so with a big enough file one can overflow the buffer and overwrite a thread stack and then achieve ROP.<br />
| None?<br />
| App: ?<br />
| August 29, 2017<br />
| August, 2017<br />
| [[User:Nba_Yoh|MrNbaYoh]]<br />
|-<br />
| Pokemon Omega Ruby/Alpha Sapphire<br />
| PSS data heap/stack overflow<br />
| When launching the game, multiple chunks from the save file are parsed and copied to a large heap buffer. When parsing PSS data (acquaintances, passerby) the game copies each entry to the heap buffer, the number of entries to copy is read from the end of the multiple pss data chunks and is not checked, leading to an overflow. The "PSS data - friends" chunk is vulnerable too, but the overflow occurs on the stack and unfortunately this isn't exploitable because of a 4 bytes uncontrolled value (in each entry) that gets written on sensitive data.<br />
| None<br />
| App: 1.4. System: [[11.6.0]].<br />
| October 1, 2017<br />
| June, 2016<br />
| [[User:Nba_Yoh|MrNbaYoh]]<br />
|-<br />
| RPG Maker Fes/Player<br />
| OOB write<br />
| When handling events in a map, the indices of "buttons" are not checked. This results in an out of bound bit write, one can thus write a rop directly on the stack (bit by bit).<br />
| None?<br />
| App: ?<br />
| August 5, 2018<br />
| <br />
| [[User:Nba_Yoh|MrNbaYoh]]<br />
|}<br />
<br />
==Flipnote Studio 3D==<br />
<br />
{| class="wikitable" border="1"<br />
|-<br />
! Summary<br />
! Description<br />
! Fixed in app/system version<br />
! Timeframe info related to this was added to wiki<br />
! Flaw discovered by<br />
|-<br />
| KFH frame count overflow<br />
| The KFH frame count field should not be >= 0x3E8, but it wasn't checked and so uncontrolled data were written over pointers, causing an unexploitable crash.<br />
| System: 11.6<br />
| September 20, 2017<br />
| [[User:Nba_Yoh|MrNbaYoh]]<br />
|-<br />
| KMI paper color overflow<br />
| Paper color field (and similar color fields) in KMI chunks was not checked, a too high value caused a jump to an uncontrolled location.<br />
| System: 11.6<br />
| September 20, 2017<br />
| [[User:Nba_Yoh|MrNbaYoh]]<br />
|-<br />
| KSN BGM data size overflow<br />
| The size of the BGM data in the KSN chunk was not checked, it was used in a memcpy so with a big enough size one could overwrite a thread stack on linear mem and achieve ROP (notehax v1).<br />
| System: 11.6<br />
| September 20, 2017<br />
| [[User:Nba_Yoh|MrNbaYoh]]<br />
|-<br />
| KMC chunk unchecked<br />
| The KMC chunk was not verified at all, the CRC32 and the size were not checked. A big enough size caused an integer overflow and made the game read the file backward.<br />
| System: 11.6<br />
| September 20, 2017<br />
| [[User:Nba_Yoh|MrNbaYoh]]<br />
|-<br />
| KMI layer size unchecked<br />
| The 3 layer size fields in KMI chunks were not checked, leading to some crashes in the editor.<br />
| System: 11.6<br />
| September 20, 2017<br />
| [[User:Nba_Yoh|MrNbaYoh]]<br />
|-<br />
| Bad "queue" implementation<br />
| When a KWZ was parsed, frames were copied in a kind of queue, bounds were not checked obviously, so with the KMI layer size flaw one was able to fill completely the queue, then write past the buffer and overwrite a heap chunk header (notehax v2). This is not possible anymore, the queue cannot be filled because layer sizes are checked. Moreover each time an element is removed from the queue, the whole content is memmoved *facepalm*.<br />
| System: 11.6<br />
| September 20, 2017<br />
| [[User:Nba_Yoh|MrNbaYoh]]<br />
|}<br />
<br />
==Useless crashes / applications which were fuzzed==<br />
* Pushmo (3DSWare), QR codes: level name is properly limited to 16 characters, game doesn't crash with a longer name. The only possible crashes are triggered by out-of-bounds array index values, these crashes are not exploitable due to the index value being 8bit.<br />
<br />
* [[Pyramids (3DSWare)]], QR codes: no strings. Only crashes are from out-of-bounds values (like background ID) and are not exploitable.<br />
<br />
* [[Pyramids 2 (3DSWare)]], QR codes: no strings. Only crashes are from out-of-bounds values (like background ID) and are not exploitable.<br />
<br />
* [https://github.com/yellows8/mm3d_re The Legend of Zelda: Majora's Mask 3D]<br />
<br />
* "The Legend of Zelda: A Link Between Worlds" and "The Legend of Zelda: Tri Force Heroes": these games don't crash at all when the entire save-file(minus constant header data) is overwritten with /dev/random output / 0xFF-bytes. All of the CRC32s were updated for this of course. Note that this refers to the regular save file: Tri Force Heroes can be exploited via BOSS extdata - see above.<br />
<br />
* Pokemon Mystery Dungeon: Gates to Infinity has the same unchecked file bounds as Pokemon Super Mystery Dungeon, however since save compression was introduced in Pokemon Super Mystery Dungeon, it only allocates one buffer within the application heap instead of several within the linear heap, resulting in nothing to corrupt or overwrite even if the file's length is extended past its allocation.<br />
<br />
* "Kid Icarus: Uprising": Overwriting the entire savedata results in various crashes, nothing useful.<br />
<br />
* Savedata/extdata for "Super Smash Bros 3DS": Overwriting the various files stored under savedata/extdata results in useless crashes.<br />
<br />
* "StarFox 64 3D": Doesn't crash at all with the entire savedata overwritten.<br />
<br />
* "Frogger 3D": Overwriting a savefile with random-data results in *nothing* crashing.<br />
<br />
* "Mutant Mudds": Overwriting the savefile with random data results in a crash<br />
<br />
* "Animal Crossing: New Leaf": Creating a QR code from random data results in a valid QR code and a random design. In some very rare cases(which aren't always reproducible?) a crash/etc may occur, but this isn't known to be useful.<br />
<br />
==Crashes needing investigation==<br />
* Disney Infinity crashes when all savedata overwritten with /dev/urandom. No checksums. 0xFF bytes don't cause a crash.<br />
<br />
* Football Up Online / Soccer Up Online and Football Up 3D / Soccer Up 3D crash when teamname(UTF-16) length = 0x48 AND 0x20 null bytes are removed after just the name or if teamname length is way longer than 0x48.<br />
<br />
=System applications=<br />
{| class="wikitable" border="1"<br />
|-<br />
! Summary<br />
! Description<br />
! Fixed in version<br />
! Last version this flaw was checked for<br />
! Timeframe this was discovered<br />
! Discovered by<br />
|-<br />
| 3DS [[System Settings]] DS profile string stack-smash<br />
| Too long or corrupted strings (01Ah 2 Nickname length in characters 050h 2 Message length in characters) in the NVRAM DS user settings (System Settings->Other Settings->Profile->Nintendo DS Profile) cause it to crash in 3DS-mode due to a stack-smash. The DSi is not vulnerable to this, DSi launcher(menu) and DSi System Settings will reset the NVRAM user-settings if the length field values are too long(same result as when the CRCs are invalid). TWL_FIRM also resets the NVRAM user-settings when the string-length(s) are too long.<br />
| [[7.0.0-13]]<br />
| [[7.0.0-13]]<br />
| 2012<br />
| [[User:Ichfly|Ichfly]]<br />
|-<br />
| [[Nintendo 3DS Sound]]<br />
| When a .m4a is loaded, the song name is copied to a 256 byte buffer. When the song name begins with a Unicode BOM marker, it memcpy's the tag using the user-provided length. This gives an arbitrary write which can be used to achieve ROP.<br />
| [[11.4.0-37]]<br />
| [[11.4.0-37]]<br />
| June/July 2016<br />
| [[User:nedwill|nedwill]]<br />
|}<br />
<br />
=System applets=<br />
{| class="wikitable" border="1"<br />
|-<br />
! Summary<br />
! Description<br />
! Fixed in version<br />
! Last version this flaw was checked for<br />
! Introduced with version<br />
! Timeframe info related to this was added to wiki<br />
! Timeframe this was discovered<br />
! Discovered by<br />
|-<br />
| Webkit/web-browser bugs<br />
| spider has had at least three different code-execution exploits. Majority of them are use-after-free issues. See also [[browserhax|here]].<br />
|<br />
|<br />
| <br />
| 2013?<br />
|<br />
| A lot of people.<br />
|-<br />
| Old3DS/New3DS [[Internet_Browser|Browser-version-check]] bypass<br />
| When the browser-version-check code runs where the savedata for it was never initialized(such as when the user used the "Initialize savedata" option), it will use base_timestamp=0 instead of the timestamp loaded from savedata. This is then used with "if(cur_timestamp - base_timestamp >= <24h timestamp>){Run browser-version-check HTTPS request code}".<br />
Hence, if the savedata was just initialized, and if the system datetime is set to before January 2, 2000, the browser-version-check will be skipped. This includes January 1, 2000, 00:00, because that's the epoch(timestamp value 0x0) used with this timestamp.<br />
<br />
See [http://yls8.mtheall.com/3dsbrowserhax.php here] for bypass usage instructions.<br />
<br />
This was fixed with [[10.7.0-32|10.7.0-32]], see [[Internet_Browser|here]] for details.<br />
| [[10.7.0-32|10.7.0-32]]<br />
| <br />
| [[9.9.0-26|9.9.0-26]]<br />
| February 25, 2016<br />
| November 2, 2015 (Exactly one week after the browser version pages were initially updated server-side)<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| Skater - Bookmark OOB write<br />
| Each bookmark has an id that should not exceed 0x63 (99), however ids are not checked, this results in an OOB write on the stack, but only the value 0x01 can be written.<br />
| <br />
| [[11.6.0-39|11.6.0-39]]<br />
| <br />
| May 21, 2018<br />
| May 20, 2018<br />
| [[User:Nba_Yoh|MrNbaYoh]]<br />
|-<br />
| MicroSD Management - malformed security blob causes stack buffer overflow (mhax) <br />
| The MicroSD Management application's parsing of Windows NTLM security blobs in the SMB/CIFS protocol doesn't verify that the client's specified NT domain name is less than 32 UTF-16 characters. When it's longer, a stack buffer overrun occurs, leading to a ROP chain and complete control of the mcopy application.<br />
<br />
The malformed security blob can be sent by an attacker within the SMB_COM_SESSION_SETUP_ANDX (0x73) packet.<br />
| [[11.8.0-41|11.8.0-41]]<br />
| [[11.8.0-41|11.8.0-41]]<br />
| [[9.0.0-20|9.0.0-20]]<br />
| August 12, 2018<br />
| 2018<br />
| smea<br />
|}<br />
<br />
==Home Menu==<br />
{| class="wikitable" border="1"<br />
|-<br />
! Summary<br />
! Description<br />
! Fixed in version<br />
! Last version this flaw was checked for<br />
! Introduced with version<br />
! Timeframe info related to this was added to wiki<br />
! Timeframe this was discovered<br />
! Discovered by<br />
|-<br />
| bossbannerhax<br />
| After successfully loading [[Extended_Banner|extended-banner]] data(done when selecting an icon), Home Menu attempts to load "[[CBMD]]" data into a 0x100000-byte heap buffer from the [[BOSS_Services|stored]] SpotPass content. When successful and the magic-number is CBMD, Home Menu then decompresses the exbanner sections into another fixed-size heap buffer, without checking the outsize at all. The main CBMD CGFX code with ExeFS checks the size, but this code doesn't(however this is exbanner "CBMD", not a "normal" CBMD).<br />
<br />
Used with menuhax as of v3.2.<br />
| [[11.3.0-36|11.3.0-X]]<br />
| <br />
| [[1.0.0-0|1.0.0-0]]<br />
| November 18, 2016<br />
| December 23, 2014<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| sdiconhax<br />
| This is basically the same as nandiconhax, the vulnerable SD/NAND functions are ''identical'' minus the file-buffer offsets. Exploitation is different due to different heap-buffer location though. Unlike nandiconhax, the icon buffer for SD is located in linearmem(with recent Home Menu versions at least). This is used by [[menuhax]].<br />
| [[11.1.0-34|11.1.0-X]]<br />
| <br />
| [[4.0.0-7|4.0.0-X]]<br />
| July 27, 2016<br />
| October 23, 2015<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[System_SaveData|NAND-savedata]] Launcher.dat icons (nandiconhax)<br />
| The homemenu code processing the titleid list @ launcherdat+8 copies those titleIDs to another buffer, where the offset relative to that buffer is calculated using the corresponding s8/s16 entries. Those two values are not range checked at all. Hence, one can use this to write u64(s) with arbitrary values to before/after this allocated output buffer. See [[Home_Menu|here]] regarding Launcher.dat structure.<br />
<br />
This can be exploited(with Launcher.dat loading at startup at least) by using a s16 for the icon entry with value 0xFFEC(-20)(and perhaps more icons with similar s16 values to write multiple u64s). The result is that the u64 value is written to outbuf-0xA0, which overwrites object+0(vtable) and object+4(doesn't matter here) for an object that gets used a bit after the vulnerable function triggers. The low 32bits of the u64 can then be set to the address of controlled memory(either outbuf in regular heap or the entire launcherdat buffer in linearmem), for use as a fake vtable in order to get control of PC. From there one can begin ROP via vtable funcptrs to do a stack-pivot(r4=objectaddr at the time the above object gets used).<br />
<br />
Originally this vuln could only be triggered via Launcher.dat at Home Menu startup, right after Launcher.dat gets loaded + memory gets allocated, once the file-format version code is finished running. Starting with v9.6 this can be triggered when loading layouts from SD extdata as well. The vuln itself triggers before the layout data is written to Launcher.dat, but it doesn't seem to be possible to overwrite anything which actually gets used before the function which writes Launcher.dat into the layout gets called.<br />
<br />
Home Menu has some sort of fail-safe system(or at least on v9.7) when Home Menu crashes due to Launcher.dat(this also applies for other things with Home Menu): after crashing once, Home Menu resets Launcher.dat to a state where it no longer crashes anymore. However, note that any exploits using this which hang/etc without crashing will still brick the system. '''Hence, attempting anything with this on physnand without hw-nand-access isn't really recommended.'''<br />
| [[11.1.0-34|11.1.0-X]]<br />
| <br />
| [[4.0.0-7|4.0.0-X]]<br />
| <br />
| May 14, 2015<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| Theme-data decompression buffer overflow ([[menuhax|themehax]])<br />
| The only func-call size parameter used by the theme decompression function is one for the compressed size, none for the decompressed size. The decompressed-size value from the LZ header is used by this function to check when to stop decompressing, but this function itself has nothing to verify the decompressed_size with. The code calling this function does not check or even use the decompressed size from the header either.<br />
<br />
This function is separate from the rest of the Home Menu code: the function used for decompressing themes is *only* used for decompressing themes, nothing else. There's a separate decompression function in Home Menu used for decompressing everything else.<br />
<br />
That other decompression function in Home Menu handles decompression size properly(decompressed size check for max buffer size is done by code calling the other function, not in the function itself). Unlike the other function, the theme function supports multiple LZ algorithms, but the one which actually gets used in official themes is the same one supported by the other function anyway.<br />
<br />
See also [[menuhax|here]].<br />
<br />
With [[10.2.0-28|10.2.0-X]] Home Menu, the only code change was that the following was added right after theme-load and before actual decompression: "if(<get_lzheader_decompressed_size>(compressed_buf) > 0x150000)<exit>;". This fixed the vuln.<br />
| [[10.2.0-28|10.2.0-X]]<br />
| [[10.2.0-28|10.2.0-X]]<br />
| <Old3DS/New3DS version which added initial theme support><br />
| <br />
| December 22, 2014<br />
| [[User:Yellows8|Yellows8]], [[User:Myria|Myria]] independently (~spring 2015)<br />
|-<br />
| Shuffle body-data buffer overflow ([[menuhax|shufflehax]])<br />
| See [[menuhax|here]].<br />
| [[10.6.0-31|10.6.0-X]]<br />
| [[10.6.0-31|10.6.0-X]]<br />
| [[9.3.0-21|9.3.0-X]]<br />
| <br />
| January 3, 2015<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| Extdata file-data loading buffer overflow<br />
| The extdata file-reading code allocates a fixed-size heap buffer for the expected filesize, then reads the filedata into this buffer using the actual FS filesize. Before v5.0 the filesize used here wasn't validated, hence if the filesize is larger than alloc_size a buffer overflow would occur. ''After'' doing the file-read it does validate that the actual_readsize matches the alloc_size, but at this point the buffer overflow has already occurred.<br />
<br />
This affected at least the following: SaveData.dat and Cache.dat.<br />
<br />
This can be triggered with SaveData.dat by installing a <v4.0 Home Menu version, with Home Menu extdata from >=v4.0 still on SD. When this is done with v2.0 Home Menu, a kernelpanic occurs when processing an AM command(it appears a buffer ptr which is then passed to a command was overwritten with 0x0 - of course other SaveData.dat filesizes may result in different behaviour).<br />
| [[5.0.0-11|5.0.0-X]]<br />
| <br />
| [[2.0.0-2|2.0.0-X]]<br />
| June 9, 2016<br />
| June 9, 2016<br />
| [[User:Yellows8|Yellows8]]<br />
|}<br />
<br />
The icon data arrays used with {sd/nand}iconhax were added to SaveData.dat/Launcher.dat with [[4.0.0-7|4.0.0-X]], hence the vulnerable functions were added with that same version.<br />
<br />
With <=v4.0 the SaveData.dat buffer is located in the regular heap. It's unknown when exactly it was moved to linearmem, which is where it's located with recent versions. It's located in linearmem for KOR >=v9.6 for example.<br />
<br />
The SaveData.dat/Launcher.dat icon vulns were fixed by doing various unsigned >=60/>=360 checks on the loaded values. When these checks fail, it just skips over handling this icon entry. Hence, the original value can't be negative / out-of-bounds any more.<br />
<br />
==Useless crashes==<br />
Old3DS system web-browser:<br />
* 2^32 characters long string(''finally'' fixed with v10.6): this is similar to the vulnerability fixed [http://git.chromium.org/gitweb/?p=external/Webkit.git;a=commitdiff;h=ec471f16fbd1f879cb631f9b022fd16acd75f4d4 here], concat-large-strings-crash2.html triggers a crash which is about the same as the one triggered by a 2^32 string. Most of the time this vulnerability will cause a memory page permissions fault, since the WebKit code attempts to copy the string text data to the output buffer located in read-only [[CRO0|CRO]] heap memory. The only difference between a crash triggered by a 2^32 string and the concat-large-strings-crash2.html crash is at the former copies the string data using the original string length(like 1 text character for "x", 4 for "xxxx") while the latter attempts to copy >12MB. In some ''very'' rare cases a thread separate from the string data-copy thread will crash, this might be exploitable. However, this is mostly useless since it rarely crashes this way.<br />
<br />
* Trying to directly load a page via the browser "URL" option with [https://github.com/yellows8/3ds_browserhax_common webkitdebug] setup, causes a crash to trigger in oss.cro due to an use-after-free being caught with webkitdebug. This is presumably some sort of realloc() issue in the libcurl version used by the <={v10.2-v10.3} browser. This happens with *every* *single* *page* one tries to load via the "URL" option, but not when loading links on the current page, hence this is probably useless. A different use-after-free with realloc triggers with loading any page at all regardless of method too(libcurl probably).<br />
<br />
* This WebKit build has ''a lot'' of crash-trigger bugs that only happen with [https://github.com/yellows8/3ds_browserhax_common webkitdebug] completely setup(addr accesses near 0x0), with ''just'' trying to load any page at all.</div>Myriahttps://www.3dbrew.org/w/index.php?title=3DS_System_Flaws&diff=207883DS System Flaws2018-08-01T05:14:29Z<p>Myria: /* Process9 */ Added "seedminer" label</p>
<hr />
<div>Exploits are used to execute unofficial code (homebrew) on the Nintendo 3DS. This page is a list of publicly known system flaws, for userland applications/applets flaws see [[3DS_Userland_Flaws|here]].<br />
<br />
=Stale / Rejected Efforts=<br />
* Neimod has been working on a RAM dumping setup for a little while now. He's de-soldered the 3DS's RAM chip and hooked it and the RAM pinouts on the 3DS' PCB up to a custom RAM dumping setup. A while ago he published photos showing his setup to be working quite well, with the 3DS successfully booting up. However, his flickr stream is now private along with most of his work.<br />
<br />
* Someone (who will remain unnamed) has released CFW and CIA installers, all of which is copied from the work of others, or copyrighted material.<br />
<br />
==Tips and info==<br />
The 3DS uses the XN feature of the ARM11 processor. There's no official way from applications to enable executable permission for memory containing arbitrary unsigned code(there's a [[SVC]] for this, but only [[RO_Services|RO-module]] has access to it). A usable userland exploit would still be useful: you could only do return-oriented-programming with it initially. From ROP one could then exploit system flaw(s), see below.<br />
<br />
SD card [[extdata]] and SD savegames can be attacked, for consoles where the console-unique [[Nand/private/movable.sed|movable.sed]] was dumped(accessing SD data is far easier by running code on the target 3DS however).<br />
<br />
=System flaws=<br />
== Hardware ==<br />
{| class="wikitable" border="1"<br />
! Summary<br />
! Description<br />
! Fixed with hardware model/revision<br />
! Newest hardware model/revision this flaw was checked for<br />
! Timeframe this was discovered<br />
! Discovered by<br />
|-<br />
| ARM9/ARM11 bootrom vectors point at uninitialized RAM<br />
| ARM9's and ARM11's exception vectors are hardcoded to point at the CPU's internal memory (0x08000000 region for ARM9, AXIWRAM for ARM11). While the bootrom does set them up to point to an endless loop at some point during boot, it does not do so immediately. As such, a carefully-timed fault injection (via hardware) to trigger an exception (such as an invalid instruction) will cause execution to fall into ARM9 RAM. <br />
Since RAM isn't cleared on boot (see below), one can immediately start execution of their own code here to dump bootrom, OTP, etc.<br />
The ARM9 bootrom does the following at reset: reset vector branches to another instruction, then branches to bootrom+0x8000. Hence, there's no way to know for certain when exactly the ARM9 exception-vector data stored in memory gets initialized.<br />
<br />
This requires *very* *precise* timing for triggering the hardware fault.<br />
<br />
It has been exploited by derrek to dump the ARM9 bootrom as of Summer 2015.<br />
| None: all available 3DS models at the time of writing have the exact same ARM9/ARM11 bootrom for the unprotected areas.<br />
| New3DS<br />
| End of February 2014<br />
| [[User:Derrek|derrek]], WulfyStylez (May 2015) independently<br />
|-<br />
| Missing AES key clearing<br />
| The hardware AES engine does not clear keys when doing a hard reset/reboot.<br />
| None<br />
| New3DS<br />
| August 2014<br />
| Mathieulh/Others<br />
|-<br />
| No RAM clearing on reboots<br />
| On an MCU-triggered reboot all RAM including FCRAM/ARM9 memory/AXIWRAM/VRAM keeps its contents.<br />
| None<br />
| New3DS<br />
| March 2014<br />
| [[User:Derrek|derrek]]<br />
|-<br />
| 32bits of actual console-unique TWLNAND keydata<br />
| On retail the 8-bytes at ARM9 address [[Memory_layout|0x01FFB808]] are XORed with hard-coded data, to generate the TWL console-unique keys, including TWLNAND. On Old3DS the high u32 is always 0x0, while on New3DS that u32 is always 0x2. On top of this, the lower u32's highest bit is always ORed. only 31 bits of the TWL console-unique keydata / TWL consoleID are actually console-unique.<br />
This allows one to easily bruteforce the TWL console-unique keydata with *just* data from TWLNAND. On DSi the actual console-unique data for key generation is 8-bytes(all bytes actually set).<br />
| None<br />
| New3DS<br />
| 2012?<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| DSi / 3DS-TWL key-generator<br />
| After using the key generator to generate the normal-key, you could overwrite parts of the normal-key with your own data and then recover the key-generator output by comparing the new crypto output with the original crypto output. From the normal-key outputs, you could deduce the TWL key-generator function.<br />
This applies to the keyX/keyY too.<br />
<br />
This attack does not work for the 3DS key-generator because keyslots 0-3 are only for TWL keys.<br />
| None<br />
| New3DS<br />
| 2011<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| 3DS key-generator<br />
| The algorithm for generating the normal-keys for keyslots is cryptographically weak. As a result, it is easily susceptible to differential cryptanalysis if the normal-key corresponding to any scrambler-generated keyslot is discovered.<br />
<br />
Several such pairs of matching normal-keys and KeyY values were found, leading to deducing the key-generator function.<br />
| None<br />
| New3DS<br />
| February 2015<br />
| [[User:Yellows8|Yellows8]], [[User:Plutooo|plutoo]]<br />
|-<br />
| RSA keyslots don't clear exponent when setting modulus<br />
| The [[RSA_Registers|RSA keyslots]] are set by boot ROM to have four private RSA keys. The exponent value in the RSA registers is write-only and not readable.<br />
<br />
However, when setting a keyslot's modulus, the RSA hardware leaves the exponent alone. This allows retrieving the exponent by doing a discrete logarithm of the output.<br />
<br />
By setting the modulus to a prime number whose modular multiplicative order is "smooth" (that is, p-1 is divisible by only small prime numbers), discrete logarithms can be calculated quickly using the [[wikipedia:Pohlig-Hellman algorithm|Pohlig-Hellman algorithm]]. If the prime chosen is greater than the modulus, but the same bit size, the discrete logarithm is the private exponent.<br />
<br />
This exploit's usefulness is limited: RSA keyslot 0 is only used in current firmware for deriving the 6.x save and 7.x NCCH keys, which were already known, and the other three keyslots are entirely unused. Additionally, with a boot ROM dump, this exploit is moot; these private keys are located in the protected ARM9 boot ROM.<br />
| None<br />
| New3DS<br />
| March 2016<br />
| [[User:Myria|Myria]]<br />
|-<br />
| [[CONFIG11_Registers#CFG11_GPUPROT|CFG11_GPUPROT]] allowing acccess to AXIWRAM/FCRAM-BASE-memregion<br />
| [[CONFIG11_Registers#CFG11_GPUPROT|CFG11_GPUPROT]] can be configured by anything with access to it to allow the GPU to access the entire AXIWRAM+FCRAM. For example, this is an issue for any sysmodule that gets exploited and has access to this register memory-page(include one that's listed below).<br />
<br />
See also "kernelhax via gspwn" below.<br />
| None<br />
| New3DS<br />
| February 7, 2017<br />
| [[User:Yellows8|Yellows8]]<br />
|}<br />
<br />
== Boot ROM ==<br />
{| class="wikitable" border="1"<br />
! Summary<br />
! Description<br />
! Fixed with hardware model/revision<br />
! Newest hardware model/revision this flaw was checked for<br />
! Timeframe this was discovered<br />
! Discovered by<br />
|-<br />
| FIRM partitions known-plaintext<br />
| The [[Flash_Filesystem|FIRM partitions]] are encrypted with AES-CTR without a MAC. Since this works by XOR'ing data with a static (per-console in this case) keystream, one can deduce the keystream of a portion of each FIRM partition if they have the actual FIRM binary stored in it.<br />
<br />
This can be paired with many exploits. For example, it allows minor FIRM downgrades (i.e. 10.4 to 9.6 or 9.5 to 9.4, but not 9.6 to 9.5).<br />
However it is most commonly used to install arbitrary FIRMs (usually boot9strap), thanks to sighax.<br />
<br />
This can be somewhat addressed by having a FIRM header skip over previously used section offsets, but this would just air-gap newer FIRMs without fixing the core bug. This can also only be done a limited number of times due to the size of FIRM versus the size of the partitions.<br />
| None<br />
| New3DS<br />
| <br />
| Everyone<br />
|-<br />
| Boot9 AES keyinit function issues<br />
| [[Bootloader|Boot9]] seems to have two bugs in the AES key-init function, see [[AES_Registers#AES_key-init|here]].<br />
| None<br />
| BootROM issue.<br />
| 2015<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| New3DS has same boot ROM as Old3DS<br />
| The New3DS has the exact same boot ROM as the Old3DS. This means, among other things, that all the same boot ROM flaws are present. Also, this meant that it is possible to boot Old3DS firmware on New3DS (see "CFG_SYSPROT9 bit1 not set by Kernel9").<br />
| None<br />
| New3DS<br />
| October 2014<br />
| Everyone<br />
|-<br />
| sighax: Boot9 improper PKCS #1 v1.5 signature validation<br />
| The [[Flash_Filesystem|FIRM partitions]] are signed with RSA-2048 using SHA-256 and PKCS #1 v1.5 padding. Boot9, however, does improper validation of the padding in three ways:<br />
# Boot9 permits block type 02, meant for encrypted messages, to be used for signatures. Only 01, for signatures, should have been permitted. As a result, a signature block is not required to have a long string of FF bytes as padding, but rather any random values suffice. While correct for encryption, this severely lessens security of signatures.<br />
# Boot9 does not require that the length of the padding fill out the signature block completely. As a result, there is considerable freedom in the layout of a signature.<br />
# Boot9 fails to do bounds checking in its parsing of the DER-encoded hash algorithm type and hash value; the length values given in DER are permitted to point outside the signature block.<br />
Flaw 3 allows the DER encoding to be such that boot9 believes that the signature's hash value is outside the range of the block itself, somewhere on the stack. This can be pointed at the correct hash value it computes. Boot9 then memcmp's the calculated hash against itself, and thinks that the hash is valid.<br />
<br />
When all three flaws are combined, a brute force in a reasonable amount of time can find a signature that passes all checks.<br />
| None<br />
| New3DS<br />
| July 2015<br />
| [[User:Derrek|derrek]]<br />
|-<br />
| Boot9 FIRM loading doesn't blacklist memory-mapped I/O<br />
| [[Bootloader|Boot9]]'s FIRM loading blacklists Boot9 data regions, but forgets to do other important regions, including Memory-mapped I/O. Combined with sighax, by loading a malicious FIRM section to MMIO, one can get Boot9/Boot11 code execution. <br />
| None<br />
| New3DS<br />
| 2015(?)<br />
| [[User:Derrek|derrek]] (2015?), [[User:Normmatt|Normmatt]] and [[User:SciresM|SciresM]] independently (January 2017).<br />
|-<br />
| "superhax": Boot9 FIRM loading blacklist check is flawed<br />
| Boot9 only makes sure the '''start''' and '''end''' address of each section is not covered by a blacklisted region. Thus, it is possible to overwrite blacklisted regions (e.g. ARM9 Exception Vectors) by choosing a FIRM section range that encloses an entire blacklisted region. The vulnerable code looks like this: if(blRegions[i].start <= sectionStart && blRegions[i].end > sectionStart <nowiki>||</nowiki> blRegions[i].start <= sectionEnd && blRegions[i].end > sectionEnd) return false; // failure<br />
| None<br />
| New3DS<br />
| August 2015<br />
| [[User:Plutoo|plutoo]], [[User:Yellows8|yellows8]]<br />
|}<br />
<br />
== ARM9 software ==<br />
<br />
=== arm9loader ===<br />
{| class="wikitable" border="1"<br />
|-<br />
! Summary<br />
! Description<br />
! Successful exploitation result<br />
! Fixed in [[FIRM]] system version<br />
! Last [[FIRM]] system version this flaw was checked for<br />
! Timeframe this was discovered<br />
! Public disclosure timeframe<br />
! Discovered by<br />
|-<br />
| Generating the keysector console-unique keys with ITCM+Boot9<br />
| [[Bootloader|Boot9]] decrypts the 0x100-byte [[OTP_Registers|OTP]] using AES-CBC with keydata stored in Boot9. If hash verification is successful, the plaintext of the first 0x90-bytes are copied into [[Memory_layout|ITCM]]. This is the ''exact'' ''same'' region hashed by arm9loader when generating the console-unique keys for decrypting the keysector, except arm9loader uses the raw encrypted OTP.<br />
<br />
Therefore, with the OTP keydata+IV from Boot9 you can: encrypt the 0x90-bytes from ITCM, then hash the output to get the console-unique keys for the system's keysector. This can even be done for Old3DS which doesn't have the arm9loader keysector officially.<br />
<br />
It's unknown why arm9loader only used the first 0x90-bytes of OTP. Using more data from OTP would've prevented this. Fixing this would require doing exactly that, but that would also mean updating the NAND keysector(which is dangerous).<br />
| See description.<br />
| None<br />
| <br />
| 2015<br />
| January 6, 2017<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| Rearrangable keys in the NAND keystore<br />
| Due to the keystore being encrypted with AES-ECB, one can rearrange blocks and still have the NAND keystore decrypt in a deterministic way. <br />
<br />
Using 10.0 FIRM it is possible to rearrange keys such that ARM9 memory is executed. As such using existing ARM9 execution 10.0 FIRM can be written to NAND and a payload written to memory, with the payload to be executed post-K9L using an MCU reboot.<br />
| arm9loaderhax given existing ARM9 code execution<br />
| None<br />
| [[11.3.0-36|11.3.0-X]]<br />
| Early 2016<br />
| 27 September 2016<br />
| Myria, [[User:Dark samus|dark_samus]]; mathieulh (independently); [[User:Plutooo|plutoo]] (independently) + others<br />
|-<br />
| Uncleared OTP hash keydata in console-unique 0x11 key-generation<br />
| Kernel9Loader does not clear the [[SHA_Registers#SHA_HASH|SHA_HASH register]] after use. As a result, the data stored here as K9L hands over to Kernel9 is the hash of [[OTP_Registers|OTP data]] used to seed the [[FIRM#New_3DS_FIRM|console-unique NAND keystore decryption key]] set on keyslot 0x11.<br />
<br />
Retrieving this keydata and the [[Flash_Filesystem#0x12C00|NAND keystore]] of the same device allows calculating the decrypted New3DS NAND keystore (non-unique, common to all New3DS units), which contains AES normal keys, also set on keyslot 0x11, which are then used to derive all current [[AES_Registers#Keyslots|New3DS-only AES keyXs]] including the newer batch introduced in [[9.6.0-24#arm9loader|9.6.0-X]]. From there, it is trivial to perform the same key derivation in order to initialize those keys on any system version, and even on Old3DS.<br />
<br />
This can be performed by exploiting the "arm9loaderhax" vulnerability to obtain post-K9L code execution after an MCU reboot (the bootrom section-loading fail is not relevant here, this attack was performed without OTP data by brute-forcing keys), and using this to dump the SHA_HASH register. This attack works on any FIRM version shipping a vulnerable version of K9L, whereas OTP dumping required a boot of <[[3.0.0-6|3.0.0-X]].<br />
<br />
This attack results in obtaining the entire (0x200-bytes) NAND keystore - it was confirmed at a later date that this keystore is encrypted with the same key (by comparing the decrypted data from multiple units), and therefore using another key in this store will not remedy the issue as all keys are known (i.e. later, unused keys decrypt to the same 0x200-bytes constant with the same OTP hash). Later keys could have been encrypted differently but this is not the case. As a result of this, it is not possible for Nintendo to use K9L again in its current format for its intended purpose, though this was not news from the moment people dumped a New3DS OTP.<br />
| Derivation of all New3DS keys generated via the NAND keystore (0x1B "Secure4" etc.)<br />
| None<br />
| [[11.3.0-36|11.3.0-X]]<br />
| ~April 2015, implemented in May 2015<br />
| 13 January 2016<br />
| [[User:WulfyStylez|WulfyStylez]], [[User:Dazzozo|Dazzozo]], [[User:Shinyquagsire23|shinyquagsire23]] (complimentary + implemented), [[User:Plutooo|plutoo]], Normmatt (discovered independently)<br />
|-<br />
| enhanced-arm9loaderhax<br />
| See the 32c3 3ds talk.<br />
Since this is a combination of a trick with the arm9-bootrom + arm9loaderhax, and since you have to manually write FIRM to the firm0/firm1 NAND partitions, this can't be completely fixed. Any system with existing ARM9 code execution and an OTP/OTP hash dump can exploit this. Additionally, by using the FIRM partition known-plaintext bug and bruteforcing the second entry in the keystore, this can currently be exploited on all New3DS systems without any other prerequisite hacks.<br />
| arm9loaderhax which automatically occurs at hard-boot.<br />
| See arm9loaderhax / description.<br />
| See arm9loaderhax / description.<br />
| Theorized around mid July, 2015. Later implemented+tested by [[User:Plutooo|plutoo]] and [[User:Derrek|derrek]].<br />
| 32c3 3ds talk (December 27, 2015)<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| Missing verification-block for the 9.6 keys (arm9loaderhax)<br />
| Starting with [[9.6.0-24|9.6.0-X]] a new set of NAND-based keys were introduced. However, no verification block was added to verify that the new key read from NAND is correct. This was technically an issue from [[9.5.0-22|9.5.0-X]] with the original sector+0 keydata, however the below is only possible with [[9.6.0-24|9.6.0-X]] since keyslots 0x15 and 0x16 are generated from different 0x11 keyXs.<br />
<br />
Writing an incorrect key to NAND will cause arm9loader to decrypt the ARM9 kernel as garbage and then jump to it.<br />
<br />
This allows an hardware-based attack where you can boot into an older exploited firmware, fill all memory with NOP sleds/jump-instructions, and then reboot into executing garbage. By automating this process with various input keydata, eventually you'll find some garbage that jumps to your code.<br />
<br />
This gives very early ARM9 code execution (pre-ARM9 kernel). As such, it is possible to dump RSA keyslots with this and calculate the 6.x [[Savegames#6.0.0-11_Savegame_keyY|save]], and 7.x [[NCCH]] keys. This cannot be used to recover keys initialized by arm9loader itself. This is due to it wiping the area used for its stack during NAND sector decryption and keyslot init. <br />
<br />
Due to FIRMs on both Old and New 3DS using the same RSA data, this can be exploited on Old3DS as well, but only if one already has the actual plaintext normalkey from New3DS NAND sector 0x96 offset-0 and has dumped the OTP area of the Old3DS.<br />
| Recovery of 6.x [[Savegames#6.0.0-11_Savegame_keyY|save key]]/7.x [[NCCH]] key, access to uncleared OTP hash keydata<br />
| None<br />
| [[11.3.0-36|11.3.0-X]]<br />
| March, 2015<br />
| <br />
| [[User:Plutooo|plutoo]]<br />
|-<br />
| Uncleared New3DS keyslot 0x11<br />
| Originally the New3DS [[FIRM]] arm9bin loader only cleared keyslot 0x11 when it gets executed at firmlaunch. This was fixed with [[9.5.0-22|9.5.0-X]] by completely clearing keyslot 0x11 immediately after the loader finishes using keyslot 0x11.<br />
This means that any ARM9 code that can execute before the loader clears the keyslot at firmlaunch(including firmlaunch-hax) can get access to the uncleared keyslot 0x11, which then allows one to generate all <=v9.5 New3DS keyXs which are generated by keyslot 0x11.<br />
<br />
Therefore, to completely fix this the loader would have to generate more keys using different keyslot 0x11 keydata. This was done with [[9.6.0-24|9.6.0-X]].<br />
| New3DS keyXs generation<br />
| Mostly fixed with [[9.5.0-22|9.5.0-X]], completely fixed with new keys with [[9.6.0-24|9.6.0-X]].<br />
| <br />
| February 3, 2015 (one day after [[9.5.0-22|9.5.0-X]] release)<br />
| <br />
| [[User:Yellows8|Yellows8]]<br />
|}<br />
<br />
=== Process9 ===<br />
{| class="wikitable" border="1"<br />
|-<br />
! Summary<br />
! Description<br />
! Successful exploitation result<br />
! Fixed in [[FIRM]] system version<br />
! Last [[FIRM]] system version this flaw was checked for<br />
! Timeframe this was discovered<br />
! Public disclosure timeframe<br />
! Discovered by<br />
|-<br />
| Leak of normal-key matching a key-scrambler key<br />
| New 3DS firmware versions [[8.1.0-0 New3DS|8.1.0]] through [[9.2.0-20|9.2.0]] set the encryption key for [[Amiibo]] data using a hardcoded normal-key in Process9. In firmware [[9.3.0-21|9.3.0]], Nintendo "fixed" this by using the key scrambler instead, by calculating the keyY value for keyslot 0x39 that results in the same normal-key, then hardcoding that keyY into Process9.<br />
<br />
Nintendo's fix is actually the problem: Nintendo revealed the normal-key matching an unknown keyX and a known keyY. Combined with the key scrambler using an insecure scrambling algorithm (see "Hardware" above), the key scrambler function could be deduced.<br />
| Deducing the keyX for keyslot 0x39 and the key scrambler algorithm<br />
| New 3DS [[9.3.0-21|9.3.0-X]], sort of<br />
| [[10.0.0-27|10.0.0-X]]<br />
| Sometime in 2015 after the hardware key-generator was broken.<br />
| 32c3 3ds talk (December 27, 2015)<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| Leak of normal-key matching a key-generator key<br />
| During the 3DS' development (June/July 2010) Nintendo added support installing encrypted content ([[CIA]]). Common-key index1 was intended to be a [[AES|hardware generated key]]. However while they added code to generate the key in hardware, they forgot to remove the normal-key for index1 (used elsewhere, likely old debug code). Nintendo later removed the normal key sometime before the first non-prototype firmware release.<br />
<br />
Knowing the keyY and the normal-key for common-key index1, the devkit key-generator algorithm can be deduced (see "Hardware" above). Additionally the remaining devkit common-keys can be generated once the common-key keyX is recovered.<br />
<br />
Note that the devkit key-generator was discovered to be the same as the retail key-generator.<br />
| Deducing the keyX for keyslot 0x3D and hardware key-generator algorithm. Generate remaining devkit common-keys.<br />
| pre-[[1.0.0-0|1.0.0-X]]<br />
| <br />
| Shortly after the key-generator was revealed to be flawed at the 32c3 3ds talk<br />
| January 20, 2016<br />
| [[User:Jakcron|jakcron]]<br />
|-<br />
| Factory firmware is vulnerable to sighax<br />
| During the 3DS's development, presumably boot9 was written (including the sighax) vulnerability. This vulnerability is also present in factory firmware (and earlier, including 0.11). This was fixed in version 1.0.0-0.<br />
| Deducing the mechanics of the sighax vulnerability in boot9 without having boot9 prot. Arm9 code execution on factory/earlier firmware.<br />
| [[1.0.0-0|1.0.0-X]]<br />
| [[1.0.0-0|1.0.0-X]]<br />
| May 9, 2017<br />
| May 19, 2017<br />
| [[User:SciresM|SciresM]], [[User:Myria|Myria]]<br />
|-<br />
| safefirmhax<br />
| SAFE_MODE_FIRM is almost never updated(even when NATIVE_FIRM is updated for vuln fixes), this can be noticed by ''just'' checking 3dbrew/ninupdates title-listings.<br />
<br />
The fix for 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 <=> Kernel11 sync, PXI sync and then repeat the original attack on SAFE_FIRM instead.<br />
| ARM9 code execution<br />
| [[11.3.0-36|11.3.0-X]]<br />
| <br />
| 2012-2013?<br />
| Wiki: January 2, 2017<br />
| Everyone<br />
|-<br />
| safefirmhax 1.1<br />
| Nintendo's original safefirmhax fix was flawed -- they added a global boolean that got set to true whenever a non-sysmodule title got launched (except for a hardcoded repair title id), and panic()'d if that boolean was true to prevent launching safefirm after hax was active. However, because the boolean was initially false after firmlaunch -- With ARM11-kernel execution, one could FIRM-launch into NATIVE_FIRM, and then immediately FIRM-launch again into SAFE_FIRM early in NATIVE_FIRM boot before the boolean got set to true to repeat the safehax attack.<br />
<br />
This was fixed by adding additional CFG9_BOOTENV checks to firmlaunch code in 11.4.<br />
| ARM9 code execution<br />
| [[11.4.0-37|11.4.0-X]]<br />
| <br />
| safefirmhax fix<br />
| Wiki: April 10, 2017<br />
| Everyone<br />
|-<br />
| ntrcardhax<br />
| When reading the banner of a NTR title, Process9 relies on a hardware register to know when the banner was fully read.<br />
However that register is shared between the ARM9 and the ARM11.<br />
An attacker with k11 control can so make Process9 believe the banner continues forever and so trigger a buffer overflow.<br />
With a custom banner for a NTR flashcart, this leads to code execution in Process9.<br />
<br />
This was fixed by adding bound checks on the read data.<br />
| ARM9 code execution<br />
| [[10.4.0-29|10.4.0-X]]<br />
| <br />
| March 2015<br />
| 32c3 3ds talk (December 27, 2015)<br />
| [[User:Plutooo|plutoo]]<br />
|-<br />
| Title downgrading via [[Application_Manager_Services|AM]]([[Application_Manager_Services_PXI|PXI]])<br />
| When a title is *already* installed, Process9 will compare the installed title-version with the title-version being installed. When the one being installed is older, Process9 would return an error.<br />
<br />
However, this can be bypassed by just deleting the title first via the service command(s) for that: with the title removed from the [[Title_Database]], Process9 can't compare the input title-version with anything. Hence, titles can be downgraded this way.<br />
<br />
[[11.0.0-33|11.0.0-X]] fixed this for key system titles (MSET, Home Menu, spider, ErrDisp, SKATER, NATIVE_FIRM, and every retail system module), by checking the version of the title to install against a hard-coded list of (titleID, minimumVersionRequired) pairs.<br />
| Bypassing title version check at installation, which then allows downgrading any title.<br />
| [[11.0.0-33|11.0.0-X]], for key system titles.<br />
| NATIVE_FIRM / AM-sysmodule [[11.0.0-33|11.0.0-X]]<br />
| ?<br />
| <br />
| ?<br />
|-<br />
| FAT FS code null-deref<br />
| When FSFile:Read is used with a file which is corrupted on a FAT filesystem(in particular SD), Process9 can crash. This particular crash is caused by a function returning NULL instead of an actual ptr due to an error. The caller of that function doesn't check for NULL which then triggers a read based at NULL.<br />
<br />
Sample "fsck.vfat -n -v -V <fat image backup>" output for the above crash:<br />
<br />
<pre>...<br />
Starting check/repair pass.<br />
<FilePath0> and<br />
<FilePath1><br />
share clusters.<br />
Truncating second to 3375104 bytes.<br />
<FilePath1><br />
File size is 2787392 bytes, cluster chain length is 16384 bytes.<br />
Truncating file to 16384 bytes.<br />
Checking for unused clusters.<br />
Reclaimed 1 unused cluster (16384 bytes).<br />
Checking free cluster summary.<br />
Free cluster summary wrong (1404490 vs. really 1404491)<br />
Auto-correcting.<br />
Starting verification pass.<br />
Checking for unused clusters.<br />
Leaving filesystem unchanged.</pre><br />
| Useless null-based-read<br />
| None<br />
| [[9.6.0-24|9.6.0-X]]<br />
| July 8-9, 2015<br />
| <br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| RSA signature padding checks<br />
| The TWL_FIRM RSA sig padding check code used for all TWL RSA sig-checks has issues, see [[FIRM|here]].<br />
The main 3DS RSA padding check code(non-certificate, including NATIVE_FIRM) uses the function used with the above to extract more padding + the actual hash from the additional padding. This isn't really a problem here because there's proper padding check code which is executed prior to this.<br />
| <br />
| None<br />
| [[9.5.0-22|9.5.0-X]]<br />
| March 2015<br />
| <br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[AMPXI:ValidateDSiWareSectionMAC]] [[AES_Registers|AES]] keyslot reuse<br />
| When the input DSiWare section index is higher than <max number of DSiWare sections supported by this FIRM>, Process9 uses keyid 0x40 for calculating the AESMAC, which translates to keyslot 0x40. The result is that the keyslot is left at whatever was already selected before, since the AES selectkeyslot code will immediately return when keyslot is >=0x40. However, actually exploiting this is difficult: the calculated AESMAC is never returned, this command just compares the calculated AESMAC with the input AESMAC(result-code depends on whether the AESMACs match). It's unknown whether a timing attack would work with this.<br />
This is basically a different form of the pxips9 keyslot vuln, except with AESMAC etc.<br />
| See description.<br />
| None<br />
| [[11.3.0-36|11.3.0-X]]<br />
| March 15, 2015<br />
| December 29, 2015<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| pxips9 [[AES_Registers|AES]] keyslot reuse<br />
| This requires access to the [[Process_Services|ps:ps]]/pxi:ps9 services. One way to get access to this would be snshax on system-version <=10.1.0-X(see 32c3 3ds talk).<br />
When an invalid key-type value is passed to any of the PS commands, Process9 will try to select keyslot 0x40. That aesengine_setkeyslot() code will then immediately return due to the invalid keyslot value. Since that function doesn't return any errors, Process9 will just continue to do crypto with whatever AES keyslot was selected before the PS command was sent.<br />
| Reusing the previously used keyslot, for crypto with PS.<br />
| None<br />
| [[11.3.0-36|11.3.0-X]]<br />
| Roughly the same time(same day?) as firmlaunch-hax.<br />
| December 29, 2015<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| firmlaunch-hax: FIRM header ToCToU<br />
| This can't be exploited from ARM11 userland.<br />
During [[FIRM]] launch, the only FIRM header the ARM9 uses at all is stored in FCRAM, this is 0x200-bytes(the actual used FIRM RSA signature is read to the Process9 stack however). The ARM9 doesn't expect "anything" besides the ARM9 to access this data.<br />
With [[9.5.0-22]] the address of this FIRM header was changed from a FCRAM address, to ARM9-only address 0x01fffc00.<br />
| ARM9 code execution<br />
| [[9.5.0-22]]<br />
| <br />
| 2012, 3 days after [[User:Yellows8|Yellows8]] started Process9 code RE.<br />
| <br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| Uninitialized data output for (PXI) command replies<br />
| PXI commands for various services(including some [[Filesystem_services_PXI|here]] and many others) can write uninitialized data (like from ARM registers) to the command reply. This happens with stubbed commands, but this can also occur with certain commands when returning an error.<br />
Certain ARM11 service commands have this same issue as well.<br />
| <br />
| None<br />
| [[9.3.0-21|9.3.0-X]]<br />
| ?<br />
| <br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[Filesystem_services_PXI|FSPXI]] OpenArchive SD permissions<br />
| Process9 does not use the exheader ARM9 access-mount permission flag for SD at all.<br />
This would mean ARM11-kernelmode code / fs-module itself could directly use FSPXI to access SD card without ARM9 checking for SD access, but this is rather useless since a process is usually running with SD access(Home Menu for example) anyway.<br />
| <br />
| None<br />
| [[9.3.0-21|9.3.0-X]]<br />
| 2012<br />
| <br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[AMPXI:ExportDSiWare]] export path<br />
| Process9 allocates memory on Process9 heap for the export path then verifies that the actual allocated size matches the input size. Then Process9 copies the input path from FCRAM to this buffer, and uses it with the Process9 FS openfile code, which use paths in the form of "<mountpoint>:/<path>".<br />
Process9 does not check the contents of this path at all before passing it to the FS code, besides writing a NUL-terminator to the end of the buffer.<br />
| Exporting of DSiWare to arbitrary Process9 file-paths, such as "nand:/<path>" etc. This isn't really useful since the data which gets written can't be controlled.<br />
| None<br />
| [[9.5.0-22]]<br />
| April 2013<br />
| <br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[DSiWare_Exports]] [[CTCert]] verification<br />
| Just like DSi originally did, 3DS verifies the APCert for DSiWare on SD with the CTCert also in the DSiWare .bin. On DSi this was fixed with with system-version 1.4.2 by verifying with the actual console-unique cert instead(stored in NAND), while on 3DS it's still not(?) fixed.<br />
On 3DS however this is useless, unless one can obtain the console-unique movable.sed keyY which encrypts the entire DSiWare .bin.<br />
| When the movable.sed keyY for the target 3DS is known and the target 3DS CTCert private-key is unknown, importing of modified DSiWare SD .bin files.<br />
| None.<br />
| 11.6.0-X<br />
| April 2013<br />
| <br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| seedminer: movable.sed keyY vulnerable to brute-force<br />
| Half of the movable.sed keyY's 128 bits are leaked through the [[Nandrw/sys/LocalFriendCodeSeed_B|LFCS]], which is available in userland and below. The LFCS itself also leaks almost half of the remaining bits by following the ratio: u32 keyY[3]=1/5(LFCS). The remaining keyY[3] uncertainty of about ±2000 can be greatly reduced by plotting expected error margins with several keyYs. This results in a final uncertainty of about 2^40, easily within practical brute force range of an average modern PC.<br />
| Knowing the keyY of a given 3ds allows for modification of DSiWare export contents, and chained with several other public vulns, ultimately arm9 execution.<br />
| None.<br />
| 11.6.0-X<br />
| December 2017<br />
| January 2018<br />
| zoogie<br />
|-<br />
| Improper validation of DSiWare title SRLs<br />
| The 3DS does not verify if the actual SRL embedded in the title's directory matches the titleID in the TMD before launching it or importing it from an sd DSiWare export. <br />
| This allows embedding older, exploitable DSiWare titles in completely different, unexploitable DSiWare titles. Since DSiWare has raw NAND RW, this can result in arm9 control through FIRM known-plaintext and sighax attacks.<br />
| None.<br />
| 11.6.0-X<br />
| 2015?<br />
| December 2016<br />
| Everyone<br />
|-<br />
| [[Gamecard_Services_PXI]] unchecked REG_CTRCARDCNT transfer-size<br />
| The u8 REG_CTRCARDCNT transfer-size parameter for the [[Gamecard_Services_PXI]] read/write CTRCARD commands is used as an index for an array of u16 values. Before [[5.0.0-11|5.0.0-X]] this u8 value wasn't checked, thus out-of-bounds reads could be triggered(which is rather useless in this case).<br />
| Out-of-bounds read for a value which gets written to a register.<br />
| [[5.0.0-11|5.0.0-X]]<br />
| <br />
| 2013?<br />
| <br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[PXI_Registers|PXI]] cmdbuf buffer overrun<br />
| The Process9 code responsible [[PXI_Registers|PXI]] communications didn't verify the size of the incoming command before writing it to a C++ member variable. <br />
| Probably ARM9 code execution<br />
| [[5.0.0-11|5.0.0-11]]<br />
| <br />
| March 2015, original timeframe if any unknown<br />
| <br />
| [[User:Plutooo|plutoo]]/[[User:Yellows8|Yellows8]]/maybe others(?)<br />
|-<br />
| [[Application_Manager_Services_PXI|PXIAM]] command 0x003D0108(See also [[Application_Manager_Services|this]])<br />
| When handling this command, Process9 allocates a 0x2800-byte heap buffer, then copies the 4 FCRAM input buffers to this heap buffer without checking the sizes at all(only the buffers with non-zero sizes are copied). Starting with [[5.0.0-11|5.0.0-X]], the total combined size of the input data must be <=0x2800.<br />
| ARM9 code execution<br />
| [[5.0.0-11|5.0.0-X]]<br />
| <br />
| May 2013<br />
| <br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[Process_Services_PXI|PS RSA]] commands buffer overflows<br />
| pxips9 cmd1(not accessible via ps:ps) and VerifyRsaSha256: unchecked copy to a buffer in Process9's .bss, from the input FCRAM buffer. The buffer is located before the pxi cmdhandler threads' stacks. SignRsaSha256 also has a buf overflow, but this isn't exploitable.<br />
The buffer for this is the buffer for the signature data. With v5.0, the signature buffer was moved to stack, with a check for the signature data size. When the signature data size is too large, Process9 uses [[SVC|svcBreak]].<br />
| ARM9 code execution<br />
| [[5.0.0-11|5.0.0-X]]<br />
| <br />
| 2012<br />
| <br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[PXI_Registers|PXI]] pxi_id bad check<br />
| The Process9 code responsible for [[PXI_Registers|PXI]] communications read pxi_id as a signed char. There were two flaws:<br />
* They used it as index to a lookup-table without checking the value at all.<br />
* Another function verified that pxi_id < 7, allowing negative values to pass the check. This would also cause an out-of-range table-lookup.<br />
| Maybe ARM9 code execution<br />
| [[3.0.0-5|3.0.0-5]]<br />
|<br />
| March 2015, originally 2012 for the first issue at least<br />
| <br />
| [[User:Plutooo|plutoo]], [[User:Yellows8|Yellows8]], maybe others(?)<br />
|}<br />
<br />
=== Kernel9 ===<br />
{| class="wikitable" border="1"<br />
|-<br />
! Summary<br />
! Description<br />
! Successful exploitation result<br />
! Fixed in [[FIRM]] system version<br />
! Last [[FIRM]] system version this flaw was checked for<br />
! Timeframe this was discovered<br />
! Discovered by<br />
|-<br />
| [[CONFIG Registers#CFG_SYSPROT9|CFG_SYSPROT9]] bit1 not set by Kernel9<br />
| Old versions of Kernel9 never set bit1 of [[CONFIG Registers#CFG_SYSPROT9|CFG_SYSPROT9]]. This leaves the [[OTP Registers|0x10012000]]-region unprotected (this region should be locked early during boot!). Since it's never locked, you can dump it once you get ARM9 code execution.<br />
<br />
From [[3.0.0-5|3.0.0-X]] this was fixed by setting the bit in Kernel9 after poking some registers in that region. On New3DS arm9loader sets this bit instead of Kernel9, which is exploitable through a hardware + software vulnerability (see arm9loaderhax / description).<br />
<br />
This flaw resurged when it gained a new practical use: retrieving the OTP data for a New3DS console in order to decrypt the key data used in arm9loader (see enhanced-arm9loaderhax / description). This was performed by downgrading to a vulnerable system version. By accounting for differences in CTR-NAND crypto (0x05 -> 0x04, see partition encryption types [[Flash_Filesystem#NAND_structure|here]]) and using an Old3DS [[NCSD#NCSD_header|NCSD Header]], it is possible to boot a New3DS using Old3DS firmware 1.0-2.x to retrieve the required OTP data using this flaw.<br />
| Dumping the [[OTP Registers|OTP]] area.<br />
Decrypting New3DS sector 0x96 keyblock.<br />
| [[3.0.0-5|3.0.0-X]]<br />
|<br />
| February 2015<br />
| [[User:Plutooo|plutoo]], Normmatt independently<br />
|}<br />
<br />
== ARM11 software ==<br />
=== Kernel11 ===<br />
{| class="wikitable" border="1"<br />
|-<br />
! Summary<br />
! Description<br />
! Successful exploitation result<br />
! Fixed in [[FIRM]] system version<br />
! Last [[FIRM]] system version this flaw was checked for<br />
! Timeframe this was discovered<br />
! Discovered by<br />
|-<br />
| [[SVC|svcSetProcessIdealProcessor]] reference count overflow and therefore use-after-free.<br />
| The SVC receive two arguments: handle and idealprocessor. The handle is used to get the KProcess object and the KProcess->refCnt gets incremented,later the function check if the KProcess->mem_type != BASE and if yes, it checks for idealprocessor == 2 or idealprocessor != 3. The problem here is that if you pass the idealprocessor = 3 it won't meet any condition and return the error 0xD9001BEA without decrement the reference count. <br />
It can be abused to overflow the KProcess reference count that will lead to an Use-after-free. <br />
| Before [[11.2.0-35|11.2.0-X]]: reference count overflow and therefore use-after-free.<br />
| <br />
| [[11.6.0-39|11.6.0-X]]<br />
| November 2, 2017<br />
| [[User:st4rk|st4rk]]<br />
|-<br />
| [[SVC|svcGetThreadList]] process reference leak<br />
| When given a valid process handle (including <code>0xFFFF8001</code>), svcGetThreadList forgets to decrement the reference count of the underlying [[KProcess]] instance, after having finished using it.<br />
| Before [[11.2.0-35|11.2.0-X]]: reference count overflow and therefore use-after-free, but this UAF was most likely not exploitable<br />
| <br />
| [[11.3.0-36|11.3.0-X]]<br />
| April 3, 2017<br />
| [[User:TuxSH|TuxSH]]<br />
|-<br />
| kernelhax via gspwn<br />
| Originally the kernel didn't initialize [[CONFIG11_Registers#CFG11_GPUPROT|CFG11_GPUPROT]]. Since it's 0 at hard-boot, this allowed the GPU to access the entire FCRAM + AXIWRAM.<br />
| Entire FCRAM+AXIWRAM R/W.<br />
| [[3.0.0-5|3.0.0-X]]<br />
| <br />
| February 7, 2017<br />
| [[User:Plutooo|plutoo]], [[User:Yellows8|Yellows8]] partly<br />
|-<br />
| fasthax<br />
| When a KTimer is created in pulse mode, the kernel calls a virtual function to reset the timer each time it pulses. The scheduler is locked for that core to avoid race conditions, but another core can call CloseHandle on the timer and free it, leading to a UAF vtable call.<br />
| See description.<br />
| [[11.3.0-36|11.3.0-X]]<br />
| [[11.3.0-36|11.3.0-X]]<br />
| May 2016<br />
| nedwill<br />
|-<br />
| ipctakeover<br />
| When sending cmdreplies, it does not validate that the src_addr and src_size match the equivalent dst_addr and dst_size. With a modified addr/size specified in a cmdreply for an output buffer, the data-copy for the first/last pages could be used to overwrite data outside of the buffer specified by the original process.<br />
<br />
Used by ctr-httpwn as of v1.2, for "ipctakeover/bosshaxx".<br />
<br />
This can be used to takeover processes where the process is using your service session. Like HTTPC -> BOSS, for bosshaxx above. NIM takeover can be done too(actual stack buffer overflow can trigger), etc.<br />
| See description.<br />
| None<br />
| [[11.3.0-36|11.3.0-X]]<br />
| November 26, 2016<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| Using IPC input buffers as output buffers<br />
| When sending cmdreplies, it does not validate that the cmdreply descriptor type matches the equivalent cmdreq descriptor type. This could be used by an exploited sysmodule to use what was intended as an input-buffer as an output-buffer, and also combine other IPC vuln(s) with this.<br />
<br />
Used by ctr-httpwn as of v1.2, for "ipctakeover/bosshaxx".<br />
| See description.<br />
| None<br />
| [[11.3.0-36|11.3.0-X]]<br />
| November 2016<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[SVC]] table too small<br />
| The table of function pointers for SVC's only contains entries up to 0x7D, but the biggest allowed SVC for the table is 0x7F. Thus, executing SVC7E or SVC7F would make the SVC-handler read after the buffer, and interpret some ARM instructions as function pointers.<br />
<br />
However, this would require patching the kernel .text or modifying SVC-access-control. Even if you could get these to execute, they would still jump to memory that isn't mapped as executable.<br />
| <br />
| None<br />
| [[11.3.0-36|11.3.0-X]]<br />
| 2012<br />
| Everyone<br />
|-<br />
| [[SVC|svcBackdoor (0x7B)]]<br />
| This backdoor allows executing SVC-mode code at the user-specified code-address. This is used by Process9, using this on the ARM11 (with NATIVE_FIRM) required patching the kernel .text or modifying SVC-access-control.<br />
| See description<br />
| [[11.0.0-33|11.0.0-X]] (deleted)<br />
| <br />
|<br />
| Everyone<br />
|-<br />
| veryslowpidhax<br />
| '''This is completely different from the kernelmode-code-execution vuln described in the below separate entry.'''<br />
<br />
When updating the kernel global PID counter under [[SVC|svcCreateProcess]] the kernel does not check for wraparound to 0x0(the PID for the very first process). This only matters because [[Services|SM-module]] allows processes with PID value less than <total ARM11 FIRM modules> to access ''all'' services, without checking exheader service-access-control; and because Kernel11 checks for the PID to be 1 (loader) to use the input mem-region value on ControlMemory. This alone does not affect access the [[SVC|SVCs]] access table at all.<br />
<br />
Inlined ldrex+strex code is used for updating the above counter. [[11.2.0-35|11.2.0-X]] had changes for similar code, but it was only for dedicated ldrex+strex functions(mainly for kernel objects) and hence this PID code was not affected.<br />
<br />
With launching+terminating a sysmodule repeatedly with this via ns:s, it would take weeks to finish(if not at least about a month?).<br />
| Access to all [[Services_API|services]], ControlMemory on any given mem-region.<br />
| None<br />
| [[11.3.0-36|11.3.0-X]]<br />
| 2012 maybe?<br />
| <br />
|-<br />
| slowhax/waithax<br />
| svcWaitSynchronizationN does not decrement the references to valid handles in an array before returning an error when it encounters an invalid handle. This allows one to (slowly) overflow the reference count for a handle object to zero.<br />
| ARM11 kernel-mode code execution<br />
| [[11.2.0-35|11.2.0-X]]<br />
| [[11.2.0-35|11.2.0-X]]<br />
| 2016<br />
| nedwill, [[User:Derrek|derrek]]<br />
|-<br />
| [[Memory_layout#ARM11_Detailed_virtual_memory_map|0xEFF00000]] / 0xDFF00000 ARM11 kernel virtual-memory<br />
| The ARM11 kernel-mode 0xEFF00000/0xDFF00000 virtual-memory(size 0x100000) is mapped to phys-mem 0x1FF00000(entire DSP-mem + entire AXIWRAM), with permissions RW-. This is used during ARM11 kernel startup for loading the FIRM-modules from the FIRM section located in DSP-mem, this never seems to be used after that, however. This is never unmapped either.<br />
| <br />
| None<br />
| [[11.3.0-36|11.3.0-X]]<br />
| <br />
| <br />
|-<br />
| memchunkhax2.1<br />
| Nintendo's fix for memchunkhax2 in [[10.4.0-29|10.4.0-X]] did not fix the GPU case: one may cause the requisite ToCToU race using gspwn, bypassing the new validation.<br />
derrek's original 32c3 presentation for memchunkhax2 commented that a GPU-based attack was possible, but would be difficult. However, memchunkhax2.1 showed that it was possible to do fairly reliably.<br />
| ARM11 kernel code execution<br />
| [[11.0.0-33|11.0.0-X]], via the new [[Memory_Management#MemoryBlockHeader|memchunkhdr]] MAC which prevents modifying memchunkhdr data with DMA.<br />
| [[11.0.0-33|11.0.0-X]]<br />
|<br />
| [[User:Derrek|derrek]], aliaspider<br />
|-<br />
| memchunkhax2<br />
| When allocating a block of memory, the "next" pointer of the [[Memory_Management#MemoryBlockHeader|memchunkhdr]] is accessed without being checked after being mapped to userland.<br />
This allows a race condition, where the process can change the next pointer just before it's accessed. By pointing the next pointer to a crafted memchunckhdr in the kernel SlabHeap, some of the SlabHeap is allocated to the calling process, allowing to change vtables of kernel objects. <br />
| ARM11 kernel code execution<br />
| [[10.4.0-29|10.4.0-X]] (partially, see memchunkhax2.1)<br />
| [[10.4.0-29|10.4.0-X]]<br />
|<br />
| [[User:Derrek|derrek]]<br />
|-<br />
| heaphax<br />
| Can change the size of free memchunk structures stored in FCRAM using DMA, which leads to the ability to allocate memory chunks over already-allocated memory. This can be used in the SYSTEM region to allocate RW memory over any part of the NS system module, which is enough to take it over.<br />
| Code execution with access to all of NS's privileges. (including downgrading) Code execution within any applet.<br />
| [[11.0.0-33|11.0.0-X]], via the new [[Memory_Management#MemoryBlockHeader|memchunkhdr]] MAC which prevents modifying memchunkhdr data with DMA.<br />
| [[11.0.0-33|11.0.0-X]]<br />
| April 2015 ?<br />
| smea<br />
|-<br />
| snshax<br />
| Can force creation of Safe NS process into gspwn-able memory, allowing for takeover.<br />
| Code execution with access to all of NS's privileges. (including downgrading)<br />
| [[10.1.0-27|10.1.0-X]]<br />
| [[10.1.0-27|10.1.0-X]]<br />
| April 2015 ?<br />
| smea<br />
|-<br />
| AffinityMask/processorid validation<br />
| With [[10.0.0-27|10.0.0-X]] the following functions were updated: svcGetThreadAffinityMask, svcGetProcessAffinityMask, svcSetProcessAffinityMask, and svcCreateThread. The code changes for all but svcCreateThread are identical.<br />
The original code with the first 3 did the following: <br />
* if(u32_processorcount > ~0x80000001)return 0xe0e01bfd;<br />
* if(s32_processorcount > <total_cores>)return 0xd8e007fd;<br />
The following code replaced the above:<br />
* if(u32_processorcount >= <total_cores+1>)return 0xd8e007fd;<br />
In theory the latter should catch everything that the former did, so it's unknown if this was really a security issue.<br />
<br />
The svcCreateThread changes with [[10.0.0-27|10.0.0-X]] definitely did fix a security issue.<br />
* Original code: "if(s32_processorid > <total_cores>)return 0xd8e007fd;"<br />
* New code: "if(s32_processorid >= <total_cores> || s32_processorid <= -4)return 0xd8e007fd;"<br />
This fixed an off-by-one issue: if one would use processorid=total_cores, which isn't actually a valid value, svcCreateThread would accept that value on <[[10.0.0-27|10.0.0-X]]. This results in data being written out-of-bounds(baseaddr = arrayaddr + entrysize*processorid), which has the following result:<br />
* Old3DS: Useless kernel-mode crash due to accessing unmapped memory.<br />
* New3DS: uncontrolled data write into a kernel-mode L1 MMU-table. This isn't really useful: the data can't be controlled, and the data which gets overwritten is all-zero anyway(this isn't anywhere near MMU L1 entries for actually mapped memory).<br />
The previous version also allowed large negative s32_processorid values(negative processorid values are special values not actual procids), but it appears using values like that won't actually do anything(meaning no crash) besides the thread not running / thread not running for a while(besides triggering a kernelpanic with certain s32_processorid value(s)).<br />
| Nothing useful<br />
| [[10.0.0-27|10.0.0-X]]<br />
| [[10.0.0-27|10.0.0-X]]<br />
| svcCreateThread issue: May 31, 2015. The rest: September 8, 2015, via v9.6->v10.0 ARM11-kernel code-diff.<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| memchunkhax<br />
| The kernel originally did not validate the data stored in the FCRAM kernel heap [[Memchunkhdr|memchunk-headers]] for free-memory at all. Exploiting this requires raw R/W access to these memchunk-headers, like physical-memory access with gspwn.<br />
<br />
There are ''multiple'' ways to exploit this, but the end-result for most of these is the same: overwrite code in AXIWRAM via the 0xEFF00000/0xDFF00000 kernel virtual-memory mapping.<br />
<br />
This was fixed in [[9.3.0-21|9.3.0-X]] by checking that the memchunk(including size, next, and prev ptrs) is located within the currently used heap memory. The kernel may also check that the next/prev ptrs are valid compared to other memchunk-headers basically. When any of these checks fail, kernelpanic() is called.<br />
| When combined with other flaws: ARM11-kernelmode code execution<br />
| [[9.3.0-21|9.3.0-21]]<br />
| <br />
| February 2014<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| Multiple [[KLinkedListNode|KLinkedListNode]] SlabHeap use after free bugs<br />
| The ARM11-kernel did access the 'key' field of [[KLinkedListNode|KLinkedListNode]] objects, which are located on the SlabHeap, after freeing them. Thus, triggering an allocation of a new [[KLinkedListNode|KLinkedListNode]] object at the right time could result in a type-confusion. Pseudo-code:<br />
SlabHeap_free(KLinkedListNode);<br />
KObject *obj = KLinkedListNode->key; // the object there might have changed!<br />
This bug appeared all over the place.<br />
| ARM11-kernelmode code exec maybe<br />
| [[8.0.0-18|8.0.0-18]]<br />
| <br />
| April 2015<br />
| [[User:Derrek|derrek]]<br />
|-<br />
| PXI [[RPC_Command_Structure|Command]] input/output buffer permissions<br />
| Originally the ARM11-kernel didn't check permissions for PXI input/output buffers for commands. Starting with [[6.0.0-11|6.0.0]] PXI input/output buffers must have RW permissions, otherwise kernelpanic is triggered.<br />
| <br />
| [[6.0.0-11|6.0.0-11]]<br />
| <br />
| 2012<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[SVC|svcStartInterProcessDma]]<br />
| For svcStartInterProcessDma, the kernel code had the following flaws:<br />
<br />
* Originally the ARM11-kernel read the input DmaConfig structure directly in kernel-mode(ldr(b/h) instructions), without checking whether the DmaConfig address is readable under userland. This was fixed by copying that structure to the SVC-mode stack, using the ldrbt instruction.<br />
<br />
* Integer overflows for srcaddr+size and dstaddr+size are now checked(with [[6.0.0-11]]), which were not checked before.<br />
<br />
* The kernel now also checks whether the srcaddr/dstaddr (+size) is within userland memory (0x20000000), the kernel now (with [[6.0.0-11]]) returns an error when the address is beyond userland memory. Using an address >=0x20000000 would result in the kernel reading from the process L1 MMU table, beyond the memory allocated for that MMU table(for vaddr->physaddr conversion). <br />
| <br />
| [[6.0.0-11]]<br />
| <br />
| DmaConfig issue: unknown. The rest: 2014<br />
| [[User:Plutooo|plutoo]], [[User:Yellows8|Yellows8]] independently<br />
|-<br />
| [[SVC|svcControlMemory]] Parameter checks<br />
| For svcControlMemory the parameter check had these two flaws:<br />
<br />
* The allowed range for addr0, addr1, size parameters depends on which MemoryOperation is being specified. The limitation for GSP heap was only checked if op=(u32)0x10003. By setting a random bit in op that has no meaning (like bit17?), op would instead be (u32)0x30003, and the range-check would be less strict and not accurate. However, the kernel doesn't actually use the input address for LINEAR memory-mapping at all besides the range-checks, so this isn't actually useful. This was fixed in the kernel by just checking for the LINEAR bit, instead of comparing the entire MemoryOperation value with 0x10003.<br />
<br />
* Integer overflows on (addr0+size) are now checked that previously weren't (this also applies to most other address checks elsewhere in the kernel).<br />
<br />
| <br />
| [[5.0.0-11]]<br />
| <br />
|<br />
| [[User:Plutooo|plutoo]]<br />
|-<br />
| [[RPC_Command_Structure|Command]] request/response buffer overflow<br />
| Originally the kernel did not check the word-values from the command-header. Starting with [[5.0.0-11]], the kernel will trigger a kernelpanic() when the total word-size of the entire command(including the cmd-header) is larger than 0x40-words (0x100-bytes). This allows overwriting threadlocalstorage+0x180 in the destination thread. However, since the data written there would be translate parameters (such as header-words + buffer addresses), exploiting this would likely be very difficult, if possible at all.<br />
<br />
If the two words at threadlocalstorage+0x180 could be overwritten with controlled data this way, one could then use a command with a buffer-header of <nowiki>((size<<14) | 2)</nowiki> to write arbitrary memory to any RW userland memory in the destination process.<br />
| <br />
| [[5.0.0-11]]<br />
| <br />
| v4.1 FIRM -> v5.0 code diff<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[SVC|SVC stack allocation overflows]]<br />
| <br />
* Syscalls that allocate a variable-length array on stack, only checked bit31 before multiplying by 4/16 (when calculating how much memory to allocate). If a large integer was passed as input to one of these syscalls, an integer overflow would occur, and too little memory would have been allocated on stack resulting in a buffer overrun. <br />
* The alignment (size+7)&~7 calculation before allocation was not checked for integer overflow.<br />
<br />
This might allow for ARM11 kernel code-execution.<br />
<br />
(Applies to svcSetResourceLimitValues, svcGetThreadList, svcGetProcessList, svcReplyAndReceive, svcWaitSynchronizationN.)<br />
| <br />
| [[5.0.0-11]]<br />
| <br />
| v4.1 FIRM -> v5.0 code diff<br />
| [[User:Plutooo|plutoo]], [[User:Yellows8|Yellows8]] complementary<br />
|-<br />
| [[SVC|svcControlMemory]] MemoryOperation MAP memory-permissions<br />
| svcControlMemory with MemoryOperation=MAP allows mapping the already-mapped process virtual-mem at addr1, to addr0. The lowest address permitted for addr1 is 0x00100000. Originally the ARM11 kernel didn't check memory permissions for addr1. Therefore .text as addr1 could be mapped elsewhere as RW- memory, which allowed ARM11 userland code-execution.<br />
| <br />
| [[4.1.0-8]]<br />
| <br />
| 2012<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[RPC_Command_Structure|Command]] input/output buffer permissions<br />
| Originally the ARM11 kernel didn't check memory permissions for the input/output buffers for commands. Starting with [[4.0.0-7]] the ARM11 kernel will trigger a kernelpanic() if the input/output buffers don't have the required memory permissions. For example, this allowed a FSUSER file-read to .text, which therefore allowed ARM11-userland code execution.<br />
| <br />
| [[4.0.0-7]]<br />
| <br />
| 2012<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[SVC|svcReadProcessMemory/svcWriteProcessMemory memory]] permissions<br />
| Originally the kernel only checked the first page(0x1000-bytes) of the src/dst buffers, for svcReadProcessMemory and svcWriteProcessMemory. There is no known retail processes which have access to these SVCs.<br />
| <br />
| [[4.0.0-7]]<br />
| <br />
| 2012?<br />
| [[User:Yellows8|Yellows8]]<br />
|}<br />
<br />
=== [[FIRM]] Sysmodules ===<br />
{| class="wikitable" border="1"<br />
|-<br />
! Summary<br />
! Description<br />
! Successful exploitation result<br />
! Fixed in [[FIRM]] system version<br />
! Last [[FIRM]] system version this flaw was checked for<br />
! Timeframe this was discovered<br />
! Discovered by<br />
|-<br />
| [[Services|"srv:pm"]] process registration<br />
| Originally any process had access to the port "srv:pm". The PID's used for the (un)registration commands are not checked either. This allowed any process to re-register itself with "srv:pm", and therefore allowed the process to give itself access to any service, bypassing the exheader service-access-control list.<br />
<br />
This was fixed in [[7.0.0-13]]: starting with [[7.0.0-13]] "srv:pm" is now a service instead of a globally accessible port. Only processes with PID's less than 6 (in other words: fs, ldr, sm, pm, pxi modules) have access to it. With [[7.0.0-13]] there can only be one session for "srv:pm" open at a time(this is used by pm module), svcBreak will be executed if more sessions are opened by the processes which can access this.<br />
<br />
This flaw was needed for exploiting the <=v4.x Process9 PXI vulnerabilities from ARM11 userland ROP, since most applications don't have access to those service(s).<br />
| Access to arbitrary services<br />
| [[7.0.0-13]]<br />
| <br />
| 2012<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| FSDIR null-deref<br />
| [[Filesystem_services|FS]]-module may crash in some cases when handling directory reading. The trigger seems to be due to using [[FSDir:Close]] without closing the dir-handle afterwards?(Perhaps this is caused by out-of-memory?) This seems to be useless since it's just a null-deref.<br />
| <br />
| None<br />
| [[9.6.0-24|9.6.0-X]]<br />
| May 19(?)-20, 2015<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[SM]] out-of-bounds BSS write (table 1 entry too small)<br />
| After accepting a new session, [[SM]] writes a (handler ID (0 for srv: sessions (max. 64), 1 for the srv:pm one), pointer to session context structure in BSS) pair in a global array. However that array is only 64-entry-big instead of 65 (as it ought to be), and no bound check is done in that regard.<br />
<br />
Unfortunately, as of [[11.4.0-37]], the overwritten fields are totally unused after their initialization by <code>__libc_init_array</code>.<br />
| Not currently exploitable<br />
| None<br />
| [[11.4.0-37]]<br />
|<br />
|<br />
|}<br />
<br />
=== Standalone Sysmodules ===<br />
{| class="wikitable" border="1"<br />
|-<br />
! Summary<br />
! Description<br />
! Successful exploitation result<br />
! Fixed in system-module system-version<br />
! Last system-module system-version this flaw was checked for<br />
! Timeframe this was discovered<br />
! Timeframe this was added to wiki<br />
! Discovered by<br />
|-<br />
| [[MP:SendDataFrame]] missing input array index validation<br />
| [[MP:SendDataFrame]] doesn't validate the input index at cmdreq[1], unless the function for flag=non-zero is executed. This is used to calculate the following, without validating the index at all: someptr = stateptr + (index*0x924) + somestateoffset.<br />
<br />
After validating some flags from someptr, when input_flag=0 the input buffer data is copied to someptr+someotheroffset+0x14 with the u16 size loaded from someptr+someotheroffset.<br />
<br />
With a large input index someptr could be setup to be at a <target address>, for overwriting memory.<br />
<br />
This is probably difficult to exploit.<br />
| <br />
| None<br />
| [[8.0.0-18]](MP-sysmodule v2048)<br />
| January 22, 2017<br />
| January 22, 2017<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[MP_Services|MP]] cmd1 out-of-bounds handle read<br />
| MP-sysmodule handles the input parameter for cmd1 as a s32. It checks for >=16, but not <0. With <16 it basically does the following(array of entries 4-bytes each): *outhandle = ((Handle*)(stateptr+offsetinstate))[inputindex].<br />
<br />
Hence, this can be used to load any handle in MP-sysmodule memory. MP doesn't really have any service handles of interest however(can be obtained from elsewhere too).<br />
| Reading any handle in MP-sysmodule memory.<br />
| None<br />
| [[8.0.0-18]](MP-sysmodule v2048)<br />
| January 21, 2017<br />
| January 22, 2017<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| AM stack/.bss infoleak via [[AM:ReadTwlBackupInfo]]([[AM:ReadTwlBackupInfoEx|Ex]])<br />
| After writing the output-info structure to stack, it then copies that structure to the output buffer ptr using the size from the command. The size is not checked. This could be used to read data from the AM-service-thread stack handling the command + .bss.<br />
<br />
'''This was not tested on hardware.'''<br />
| Stack/.bss reading<br />
| None<br />
| [[10.0.0-27]](AM v9217)<br />
| Roughly October 17, 2016<br />
| October 25, 2016<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[MVD_Services|MVD]]: Stack buffer overflow with [[MVDSTD:SetupOutputBuffers]].<br />
| The input total_entries is not validated when initially processing the input entry-list. This fixed-size input entry-list is copied to stack from the command request. The loop for processing this initializes a global table, the converted linearmem->physaddrs used there are also copied to stack(0x8-bytes of physaddrs per entry).<br />
<br />
If total_entries is too large, MVD-sysmodule will crash due to reading unmapped memory following the stack(0x10000000). Afterwards if the out-of-bounds total_entries is smaller than that, it will crash due accessing address 0x0, hence this useless.<br />
| MVD-sysmodule crash.<br />
| None<br />
| [[9.0.0-20]]<br />
| April 22, 2016 (Tested on the 25th)<br />
| April 25, 2016<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[NWM_Services|NWM]]: Using CTRSDK heap with UDS sharedmem from the user-process.<br />
| See the HTTP-sysmodule section below.<br />
<br />
CTRSDK heap is used with the sharedmem from [[NWMUDS:InitializeWithVersion]]. Buffers are allocated/freed under this heap using [[NWMUDS:Bind]] and [[NWMUDS:Unbind]].<br />
<br />
Hence, overwriting sharedmem with gspwn then using [[NWMUDS:Unbind]] results in the usual controlled CTRSDK memchunk-header write, similar to HTTP-sysmodule.<br />
<br />
This could be done by creating an UDS network, without any other nodes on the network.<br />
<br />
Besides CTRSDK memchunk-headers, there are no addresses stored under this sharedmem.<br />
| ROP under NWM-module.<br />
| [[11.4.0-37|11.4.0-X]]<br />
| [[9.0.0-20|9.0.0-X]]<br />
| April 10, 2016<br />
| April 16, 2016<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[DLP_Services|DLP]]: Out-of-bounds memory access during spectator [[Download_Play|data-frame]] checksum calculation<br />
| DLP doesn't validate the frame_size when receiving spectator data-frames at all, unlike non-spectator data-frames. The actual spectator data-frame parsing code doesn't use that field either. However, the data-frame checksum calculation code called during checksum verification does use the frame_size for loading the size of the framebuf.<br />
<br />
Hence, using a large frame_size like 0xFFFF will result in the checksum calculation code reading data out-of-bounds. This isn't really useful, you could trigger a remote local-WLAN DLP-sysmodule crash while a 3DS system is scanning for DLP networks(due to accessing unmapped memory), but that's about all(trying to infoleak with this likely isn't useful either).<br />
| DLP-sysmodule crash, handled by dlplay system-application by a "connection interrupted" error eventually then a fatal-error via ErrDisp.<br />
| None<br />
| [[10.0.0-27|10.0.0-X]]<br />
| April 8, 2016 (Tested on the 10th)<br />
| April 10, 2016<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[DLP_Services|DLP]]: Out-of-bounds output data writing during spectator sysupdate titlelist [[Download_Play|data-frame]] handling<br />
| The total_entries and out_entryindex fields for the titlelist DLP spectator data-frames are not validated. This is parsed during DLP network scanning. Hence, the specified titlelist data can be written out-of-bounds using the specified out_entryindex and total_entries. A crash will occur while reading the input data-frame titlelist if total_entries is larger than 0x27A, due to accessing unmapped memory.<br />
<br />
There's not much non-zero data to overwrite following the output buffer(located in sharedmem), any ptrs are located in sharedmem. Overwriting certain ptr(s) are only known to cause a crash when attempting to use the DLP-client shutdown service-command.<br />
<br />
There's no known way to exploit the above crash, since the linked-list code involves writes zeros(with a controlled start ptr).<br />
| <br />
| None<br />
| [[10.0.0-27|10.0.0-X]]<br />
| April 8-9, 2016<br />
| April 10, 2016<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[IR_Services|IR]]: Stack buffer overflow with custom hardware<br />
| Originally IR sysmodule used the read value from the I2C-IR registers TXLVL and RXLVL without validating them at all. See [[10.6.0-31|here]] for the fix. This is the size used for reading the data-recv FIFO, etc. The output buffer for reading is located on the stack.<br />
<br />
This should be exploitable if one could successfully setup the custom hardware for this and if the entire intended sizes actually get read from I2C.<br />
| ROP under IR sysmodule.<br />
| [[10.6.0-31|10.6.0-31]]<br />
| <br />
| February 23, 2016 (Unknown if it was noticed before then)<br />
| February 23, 2016<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[HTTP_Services|HTTP]]: Using CTRSDK heap with sharedmem from the user-process.<br />
| The data from httpcAddPostDataAscii and other commands is stored under a CTRSDK heap. That heap is the sharedmem specified by the user-process via the HTTPC Initialize command.<br />
Normally this sharedmem isn't accessible to the user-process once the sysmodule maps it, hence using it is supposed to be "safe".<br />
<br />
This isn't the case due to gspwn however. Since CTRSDK heap code is so insecure in general, one can use gspwn to locate the HTTPC sharedmem + read/write it, then trigger a mem-write under the sysmodule. This can then be used to get ROP going under HTTP-sysmodule.<br />
<br />
This is exploited by [https://github.com/yellows8/ctr-httpwn/ctr-httpwn ctr-httpwn].<br />
| ROP under HTTP sysmdule.<br />
| [[11.4.0-37|11.4.0-X]]<br />
| [[9.6.0-24|9.6.0-X]] (Latest sysmodule version as of [[10.7.0-32|10.7.0-32]])<br />
| Late 2015<br />
| March 22, 2016<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[NIM_Services|NIM]]: Downloading old title-versions from eShop<br />
| Multiple NIM service commands(such as [[NIMS:StartDownload]]) use a title-version value specified by the user-process, NIM does not validate that this input version matches the latest version available via SOAP. Therefore, when combined with AM(PXI) [[#Process9|title-downgrading]] via deleting the target eShop title with System Settings Data Management(if the title was already installed), this allows downloading+installing any title-version from eShop ''if'' it's still available from CDN.<br />
The easiest way to exploit this is to just patch the eShop system-application code using these NIM commands(ideally the code which loads the title-version).<br />
<br />
Originally this was tested with a debugging-system via modded-FIRM, eventually smea implemented it in HANS for the 32c3 release.<br />
| Downloading old title-versions from eShop<br />
| None<br />
| [[10.0.0-27|10.0.0-X]]<br />
| October 24, 2015 (Unknown when exactly the first eShop title downgrade was actually tested, maybe November)<br />
| January 7, 2016 (Same day Ironfall v1.0 was removed from CDN via the main-CXI files)<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[SPI_Services|SPI]] service out-of-bounds write<br />
| cmd1 has out-of-bounds write allowing overwrite of some static variables in .data.<br />
| <br />
| None<br />
| [[9.5.0-22]]<br />
| March 2015<br />
| <br />
| [[User:Plutooo|plutoo]]<br />
|-<br />
| [[NFC_Services|NFC]] module service command buf-overflows<br />
| NFC module copies data with certain commands, from command input buffers to stack without checking the size. These commands include the following, it's unknown if there's more commands with similar issues: "nfc:dev" <0x000C....> and "nfc:s" <0x0037....>.<br />
Since both of these commands are stubbed in the Old3DS NFC module from the very first version(those just return an error), these issues only affect the New3DS NFC module.<br />
<br />
There's no known retail titles which have access to either of these services.<br />
| ROP under NFC module.<br />
| New3DS: None<br />
| New3DS: [[9.5.0-22]]<br />
| December 2014?<br />
| <br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[News_Services|NEWSS]] service command notificationID validation failure<br />
| This module does not validate the input notificationID for <nowiki>"news:s"</nowiki> service commands. This is an out-of-bounds array index bug. For example, [[NEWSS:SetNotificationHeader]] could be used to exploit news module: this copies the input data(size is properly checked) to: out = newsdb_savedata+0x10 + (someu32array[notificationID]*0x70).<br />
| ROP under news module.<br />
| None<br />
| [[9.7.0-25|9.7.0-X]]<br />
| December 2014<br />
| <br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[NWMUDS:DecryptBeaconData]] heap buffer overflow<br />
| input_size = 0x1E * <value the u8 from input_[[NWM_Services|networkstruct]]+0x1D>. Then input_tag0 is copied to a heap buffer. When input_size is larger than 0xFA-bytes, it will then copy input_tag1 to <end_address_of_previous_outbuf>, with size=input_size-0xFA.<br />
<br />
This can be triggered by either using this command directly, or by boadcasting a wifi beacon which triggers it while a 3DS system running the target process is in range, when the process is scanning for hosts to connect to. Processes will only pass tag data to this command when the wlancommID and other thing(s) match the values for the process.<br />
<br />
There's no known way to actually exploit this for getting ROP under NWM-module, at the time of originally adding this to the wiki. This is because the data which gets copied out-of-bounds *and* actually causes crash(es), can't be controlled it seems(with just broadcasting a beacon at least). It's unknown whether this could be exploited from just using NWMUDS service-cmd(s) directly.<br />
| Without any actual way to exploit this: NWM-module DoS, resulting in process termination(process crash). This breaks *everything* involving wifi comms, a reboot is required to recover from this.<br />
| None<br />
| [[9.0.0-20]]<br />
| ~September 23, 2014(see the [[NWMUDS:DecryptBeaconData]] page history)<br />
| August 3, 2015<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[HID_Services|HID]] module shared-mem<br />
| HID module does not validate the index values in [[HID_Shared_Memory|sharedmem]](just changes index to 0 when index == maxval when updating), therefore large values will result in HID module writing HID data to arbitrary addresses.<br />
| ROP under HID module, but this is *very* unlikely to be exploitable since the data written is HID data.<br />
| None<br />
| [[9.3.0-21]]<br />
| 2014?<br />
| <br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| gspwn<br />
| GSP module does not validate addresses given to the GPU. This allows a user-mode application/applet to read/write to a large part of physical FCRAM using GPU DMA. From this, you can overwrite the .text segment of the application you're running under, and gain real code-execution from a ROP-chain. Normally applets' .text([[Home Menu]], [[Internet Browser]], etc) is located beyond the area accessible by the GPU, except for [[RO_Services|CROs]] used by applets([[Internet Browser]] for example).<br />
<br />
FCRAM is gpu-accessible up to physaddr 0x26800000 on Old3DS, and 0x2D800000 on New3DS. This is BASE_memregion_start(aka SYSTEM_memregion_end)-0x400000 (0x800000 with New3DS) with the default memory-layout on Old3DS/New3DS. With [[11.3.0-36|11.3.0-X]] the cutoff now varies due to the new [[SVC]] 0x59. The New3DS "normal"(non-APPLICATION) cutoff was changed to 0x2D000000 due to the new [[SVC]] 0x59.<br />
| User-mode code execution.<br />
| None<br />
| [[9.6.0-24|9.6.0-X]]<br />
| Early 2014<br />
| <br />
| smea, [[User:Yellows8|Yellows8]]/others before then<br />
|-<br />
| rohax<br />
| Using gspwn, it is possible to overwrite a loaded [[CRO0]]/[[CRR0]] after its RSA-signature has been validated. Badly validated [[CRO0]] header leads to arbitrary read/write of memory in the ro-process. This gives code-execution in the ro module, who has access to [[SVC|syscalls]] 0x70-0x72, 0x7D.<br />
<br />
This was fixed after [[ninjhax]] release by adding checks on [[CRO0]]-based pointers before writing to them.<br />
| Memory-mapping syscalls.<br />
| [[9.3.0-21]]<br />
| [[9.4.0-21]]<br />
| <br />
| <br />
| smea, [[User:Plutooo|plutoo]] joint effort<br />
|-<br />
| Region free<br />
| Only [[Home Menu]] itself checks gamecards' region when launching them. Therefore, any application launch that is done directly with [[NS]] without signaling Home Menu to launch the app, will result in region checks being bypassed.<br />
This essentially means launching the gamecard with the [[NS_and_APT_Services|"ns:s"]] service. The main way to exploit this is to trigger a FIRM launch with an application specified, either with a normal FIRM launch or a hardware [[NSS:RebootSystem|reboot]].<br />
| Launching gamecards from any region + bypassing Home Menu gamecard-sysupdate installation<br />
| None<br />
| Last tested with [[10.1.0-27|10.1.0-X]].<br />
| June(?) 2014<br />
| <br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[NWM_Services|NWM]] service-cmd state null-ptr deref<br />
| The NWMUDS service command code loads a ptr from .data, adds an offset to that, then passes that as the state address for the actual command-handler function. The value of the ptr loaded from .data is not checked, therefore this will cause crashes due to that being 0x0 when NWMUDS was not properly initialized.<br />
It's unknown whether any NWM services besides NWMUDS have this issue.<br />
| This is rather useless since it's only a crash caused by a state ptr based at 0x0.<br />
| None<br />
| [[9.0.0-20]]<br />
| 2013?<br />
| <br />
| [[User:Yellows8|Yellows8]]<br />
|}<br />
<br />
=== General/CTRSDK ===<br />
{| class="wikitable" border="1"<br />
|-<br />
! Summary<br />
! Description<br />
! Successful exploitation result<br />
! Fixed in version<br />
! Last version this flaw was checked for<br />
! Timeframe this was discovered<br />
! Discovered by<br />
|-<br />
| [[NWM_Services|UDS]] beacon additional-data buffer overflow<br />
| Originally CTRSDK did not validate the UDS additional-data size before using that size to copy the additional-data to a [[NWM_Services|networkstruct]]. This was eventually fixed.<br />
This was discovered while doing code RE with an old dlp-module version. It's unknown in what specific CTRSDK version this was fixed, or even what system-version updated titles with a fixed version.<br />
<br />
It's unknown if there's any titles using a vulnerable CTRSDK version which are also exploitable with this(dlp module can't be exploited with this).<br />
<br />
The maximum number of bytes that can be written beyond the end of the outbuf is 0x37-bytes, with additionaldata_size=0xFF.<br />
| Perhaps ROP, very difficult if possible with anything at all<br />
| ?<br />
| <br />
| September(?) 2014<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| CTPK buffer overflow<br />
| At offset 0x20 in CTPK is an array for each texture, each entry is 0x20-bytes. This contains a wordindex(entry+0x18) for some srcdata relative to CTPK+0, and an u8 wordsize(entry+0x14) for this data. The CTRSDK function handling this doesn't validate the size, when copying srcdata using this size to the output buffer. Applications usually have the output buffer on the stack, hence stack buffer overflow.<br />
<br />
While CTPK(*.ctpk) are normally only loaded from RomFS, some application(s) load from elsewhere too.<br />
| ROP under the target application.<br />
| None?<br />
| "[SDK+NINTENDO:CTR_SDK-11_4_0_200_none]"<br />
| November 14, 2016<br />
| [[User:Yellows8|Yellows8]]<br />
|}</div>Myriahttps://www.3dbrew.org/w/index.php?title=3DS_System_Flaws&diff=207873DS System Flaws2018-08-01T04:49:11Z<p>Myria: /* Boot ROM */ New3DS has same boot ROM as Old3DS</p>
<hr />
<div>Exploits are used to execute unofficial code (homebrew) on the Nintendo 3DS. This page is a list of publicly known system flaws, for userland applications/applets flaws see [[3DS_Userland_Flaws|here]].<br />
<br />
=Stale / Rejected Efforts=<br />
* Neimod has been working on a RAM dumping setup for a little while now. He's de-soldered the 3DS's RAM chip and hooked it and the RAM pinouts on the 3DS' PCB up to a custom RAM dumping setup. A while ago he published photos showing his setup to be working quite well, with the 3DS successfully booting up. However, his flickr stream is now private along with most of his work.<br />
<br />
* Someone (who will remain unnamed) has released CFW and CIA installers, all of which is copied from the work of others, or copyrighted material.<br />
<br />
==Tips and info==<br />
The 3DS uses the XN feature of the ARM11 processor. There's no official way from applications to enable executable permission for memory containing arbitrary unsigned code(there's a [[SVC]] for this, but only [[RO_Services|RO-module]] has access to it). A usable userland exploit would still be useful: you could only do return-oriented-programming with it initially. From ROP one could then exploit system flaw(s), see below.<br />
<br />
SD card [[extdata]] and SD savegames can be attacked, for consoles where the console-unique [[Nand/private/movable.sed|movable.sed]] was dumped(accessing SD data is far easier by running code on the target 3DS however).<br />
<br />
=System flaws=<br />
== Hardware ==<br />
{| class="wikitable" border="1"<br />
! Summary<br />
! Description<br />
! Fixed with hardware model/revision<br />
! Newest hardware model/revision this flaw was checked for<br />
! Timeframe this was discovered<br />
! Discovered by<br />
|-<br />
| ARM9/ARM11 bootrom vectors point at uninitialized RAM<br />
| ARM9's and ARM11's exception vectors are hardcoded to point at the CPU's internal memory (0x08000000 region for ARM9, AXIWRAM for ARM11). While the bootrom does set them up to point to an endless loop at some point during boot, it does not do so immediately. As such, a carefully-timed fault injection (via hardware) to trigger an exception (such as an invalid instruction) will cause execution to fall into ARM9 RAM. <br />
Since RAM isn't cleared on boot (see below), one can immediately start execution of their own code here to dump bootrom, OTP, etc.<br />
The ARM9 bootrom does the following at reset: reset vector branches to another instruction, then branches to bootrom+0x8000. Hence, there's no way to know for certain when exactly the ARM9 exception-vector data stored in memory gets initialized.<br />
<br />
This requires *very* *precise* timing for triggering the hardware fault.<br />
<br />
It has been exploited by derrek to dump the ARM9 bootrom as of Summer 2015.<br />
| None: all available 3DS models at the time of writing have the exact same ARM9/ARM11 bootrom for the unprotected areas.<br />
| New3DS<br />
| End of February 2014<br />
| [[User:Derrek|derrek]], WulfyStylez (May 2015) independently<br />
|-<br />
| Missing AES key clearing<br />
| The hardware AES engine does not clear keys when doing a hard reset/reboot.<br />
| None<br />
| New3DS<br />
| August 2014<br />
| Mathieulh/Others<br />
|-<br />
| No RAM clearing on reboots<br />
| On an MCU-triggered reboot all RAM including FCRAM/ARM9 memory/AXIWRAM/VRAM keeps its contents.<br />
| None<br />
| New3DS<br />
| March 2014<br />
| [[User:Derrek|derrek]]<br />
|-<br />
| 32bits of actual console-unique TWLNAND keydata<br />
| On retail the 8-bytes at ARM9 address [[Memory_layout|0x01FFB808]] are XORed with hard-coded data, to generate the TWL console-unique keys, including TWLNAND. On Old3DS the high u32 is always 0x0, while on New3DS that u32 is always 0x2. On top of this, the lower u32's highest bit is always ORed. only 31 bits of the TWL console-unique keydata / TWL consoleID are actually console-unique.<br />
This allows one to easily bruteforce the TWL console-unique keydata with *just* data from TWLNAND. On DSi the actual console-unique data for key generation is 8-bytes(all bytes actually set).<br />
| None<br />
| New3DS<br />
| 2012?<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| DSi / 3DS-TWL key-generator<br />
| After using the key generator to generate the normal-key, you could overwrite parts of the normal-key with your own data and then recover the key-generator output by comparing the new crypto output with the original crypto output. From the normal-key outputs, you could deduce the TWL key-generator function.<br />
This applies to the keyX/keyY too.<br />
<br />
This attack does not work for the 3DS key-generator because keyslots 0-3 are only for TWL keys.<br />
| None<br />
| New3DS<br />
| 2011<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| 3DS key-generator<br />
| The algorithm for generating the normal-keys for keyslots is cryptographically weak. As a result, it is easily susceptible to differential cryptanalysis if the normal-key corresponding to any scrambler-generated keyslot is discovered.<br />
<br />
Several such pairs of matching normal-keys and KeyY values were found, leading to deducing the key-generator function.<br />
| None<br />
| New3DS<br />
| February 2015<br />
| [[User:Yellows8|Yellows8]], [[User:Plutooo|plutoo]]<br />
|-<br />
| RSA keyslots don't clear exponent when setting modulus<br />
| The [[RSA_Registers|RSA keyslots]] are set by boot ROM to have four private RSA keys. The exponent value in the RSA registers is write-only and not readable.<br />
<br />
However, when setting a keyslot's modulus, the RSA hardware leaves the exponent alone. This allows retrieving the exponent by doing a discrete logarithm of the output.<br />
<br />
By setting the modulus to a prime number whose modular multiplicative order is "smooth" (that is, p-1 is divisible by only small prime numbers), discrete logarithms can be calculated quickly using the [[wikipedia:Pohlig-Hellman algorithm|Pohlig-Hellman algorithm]]. If the prime chosen is greater than the modulus, but the same bit size, the discrete logarithm is the private exponent.<br />
<br />
This exploit's usefulness is limited: RSA keyslot 0 is only used in current firmware for deriving the 6.x save and 7.x NCCH keys, which were already known, and the other three keyslots are entirely unused. Additionally, with a boot ROM dump, this exploit is moot; these private keys are located in the protected ARM9 boot ROM.<br />
| None<br />
| New3DS<br />
| March 2016<br />
| [[User:Myria|Myria]]<br />
|-<br />
| [[CONFIG11_Registers#CFG11_GPUPROT|CFG11_GPUPROT]] allowing acccess to AXIWRAM/FCRAM-BASE-memregion<br />
| [[CONFIG11_Registers#CFG11_GPUPROT|CFG11_GPUPROT]] can be configured by anything with access to it to allow the GPU to access the entire AXIWRAM+FCRAM. For example, this is an issue for any sysmodule that gets exploited and has access to this register memory-page(include one that's listed below).<br />
<br />
See also "kernelhax via gspwn" below.<br />
| None<br />
| New3DS<br />
| February 7, 2017<br />
| [[User:Yellows8|Yellows8]]<br />
|}<br />
<br />
== Boot ROM ==<br />
{| class="wikitable" border="1"<br />
! Summary<br />
! Description<br />
! Fixed with hardware model/revision<br />
! Newest hardware model/revision this flaw was checked for<br />
! Timeframe this was discovered<br />
! Discovered by<br />
|-<br />
| FIRM partitions known-plaintext<br />
| The [[Flash_Filesystem|FIRM partitions]] are encrypted with AES-CTR without a MAC. Since this works by XOR'ing data with a static (per-console in this case) keystream, one can deduce the keystream of a portion of each FIRM partition if they have the actual FIRM binary stored in it.<br />
<br />
This can be paired with many exploits. For example, it allows minor FIRM downgrades (i.e. 10.4 to 9.6 or 9.5 to 9.4, but not 9.6 to 9.5).<br />
However it is most commonly used to install arbitrary FIRMs (usually boot9strap), thanks to sighax.<br />
<br />
This can be somewhat addressed by having a FIRM header skip over previously used section offsets, but this would just air-gap newer FIRMs without fixing the core bug. This can also only be done a limited number of times due to the size of FIRM versus the size of the partitions.<br />
| None<br />
| New3DS<br />
| <br />
| Everyone<br />
|-<br />
| Boot9 AES keyinit function issues<br />
| [[Bootloader|Boot9]] seems to have two bugs in the AES key-init function, see [[AES_Registers#AES_key-init|here]].<br />
| None<br />
| BootROM issue.<br />
| 2015<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| New3DS has same boot ROM as Old3DS<br />
| The New3DS has the exact same boot ROM as the Old3DS. This means, among other things, that all the same boot ROM flaws are present. Also, this meant that it is possible to boot Old3DS firmware on New3DS (see "CFG_SYSPROT9 bit1 not set by Kernel9").<br />
| None<br />
| New3DS<br />
| October 2014<br />
| Everyone<br />
|-<br />
| sighax: Boot9 improper PKCS #1 v1.5 signature validation<br />
| The [[Flash_Filesystem|FIRM partitions]] are signed with RSA-2048 using SHA-256 and PKCS #1 v1.5 padding. Boot9, however, does improper validation of the padding in three ways:<br />
# Boot9 permits block type 02, meant for encrypted messages, to be used for signatures. Only 01, for signatures, should have been permitted. As a result, a signature block is not required to have a long string of FF bytes as padding, but rather any random values suffice. While correct for encryption, this severely lessens security of signatures.<br />
# Boot9 does not require that the length of the padding fill out the signature block completely. As a result, there is considerable freedom in the layout of a signature.<br />
# Boot9 fails to do bounds checking in its parsing of the DER-encoded hash algorithm type and hash value; the length values given in DER are permitted to point outside the signature block.<br />
Flaw 3 allows the DER encoding to be such that boot9 believes that the signature's hash value is outside the range of the block itself, somewhere on the stack. This can be pointed at the correct hash value it computes. Boot9 then memcmp's the calculated hash against itself, and thinks that the hash is valid.<br />
<br />
When all three flaws are combined, a brute force in a reasonable amount of time can find a signature that passes all checks.<br />
| None<br />
| New3DS<br />
| July 2015<br />
| [[User:Derrek|derrek]]<br />
|-<br />
| Boot9 FIRM loading doesn't blacklist memory-mapped I/O<br />
| [[Bootloader|Boot9]]'s FIRM loading blacklists Boot9 data regions, but forgets to do other important regions, including Memory-mapped I/O. Combined with sighax, by loading a malicious FIRM section to MMIO, one can get Boot9/Boot11 code execution. <br />
| None<br />
| New3DS<br />
| 2015(?)<br />
| [[User:Derrek|derrek]] (2015?), [[User:Normmatt|Normmatt]] and [[User:SciresM|SciresM]] independently (January 2017).<br />
|-<br />
| "superhax": Boot9 FIRM loading blacklist check is flawed<br />
| Boot9 only makes sure the '''start''' and '''end''' address of each section is not covered by a blacklisted region. Thus, it is possible to overwrite blacklisted regions (e.g. ARM9 Exception Vectors) by choosing a FIRM section range that encloses an entire blacklisted region. The vulnerable code looks like this: if(blRegions[i].start <= sectionStart && blRegions[i].end > sectionStart <nowiki>||</nowiki> blRegions[i].start <= sectionEnd && blRegions[i].end > sectionEnd) return false; // failure<br />
| None<br />
| New3DS<br />
| August 2015<br />
| [[User:Plutoo|plutoo]], [[User:Yellows8|yellows8]]<br />
|}<br />
<br />
== ARM9 software ==<br />
<br />
=== arm9loader ===<br />
{| class="wikitable" border="1"<br />
|-<br />
! Summary<br />
! Description<br />
! Successful exploitation result<br />
! Fixed in [[FIRM]] system version<br />
! Last [[FIRM]] system version this flaw was checked for<br />
! Timeframe this was discovered<br />
! Public disclosure timeframe<br />
! Discovered by<br />
|-<br />
| Generating the keysector console-unique keys with ITCM+Boot9<br />
| [[Bootloader|Boot9]] decrypts the 0x100-byte [[OTP_Registers|OTP]] using AES-CBC with keydata stored in Boot9. If hash verification is successful, the plaintext of the first 0x90-bytes are copied into [[Memory_layout|ITCM]]. This is the ''exact'' ''same'' region hashed by arm9loader when generating the console-unique keys for decrypting the keysector, except arm9loader uses the raw encrypted OTP.<br />
<br />
Therefore, with the OTP keydata+IV from Boot9 you can: encrypt the 0x90-bytes from ITCM, then hash the output to get the console-unique keys for the system's keysector. This can even be done for Old3DS which doesn't have the arm9loader keysector officially.<br />
<br />
It's unknown why arm9loader only used the first 0x90-bytes of OTP. Using more data from OTP would've prevented this. Fixing this would require doing exactly that, but that would also mean updating the NAND keysector(which is dangerous).<br />
| See description.<br />
| None<br />
| <br />
| 2015<br />
| January 6, 2017<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| Rearrangable keys in the NAND keystore<br />
| Due to the keystore being encrypted with AES-ECB, one can rearrange blocks and still have the NAND keystore decrypt in a deterministic way. <br />
<br />
Using 10.0 FIRM it is possible to rearrange keys such that ARM9 memory is executed. As such using existing ARM9 execution 10.0 FIRM can be written to NAND and a payload written to memory, with the payload to be executed post-K9L using an MCU reboot.<br />
| arm9loaderhax given existing ARM9 code execution<br />
| None<br />
| [[11.3.0-36|11.3.0-X]]<br />
| Early 2016<br />
| 27 September 2016<br />
| Myria, [[User:Dark samus|dark_samus]]; mathieulh (independently); [[User:Plutooo|plutoo]] (independently) + others<br />
|-<br />
| Uncleared OTP hash keydata in console-unique 0x11 key-generation<br />
| Kernel9Loader does not clear the [[SHA_Registers#SHA_HASH|SHA_HASH register]] after use. As a result, the data stored here as K9L hands over to Kernel9 is the hash of [[OTP_Registers|OTP data]] used to seed the [[FIRM#New_3DS_FIRM|console-unique NAND keystore decryption key]] set on keyslot 0x11.<br />
<br />
Retrieving this keydata and the [[Flash_Filesystem#0x12C00|NAND keystore]] of the same device allows calculating the decrypted New3DS NAND keystore (non-unique, common to all New3DS units), which contains AES normal keys, also set on keyslot 0x11, which are then used to derive all current [[AES_Registers#Keyslots|New3DS-only AES keyXs]] including the newer batch introduced in [[9.6.0-24#arm9loader|9.6.0-X]]. From there, it is trivial to perform the same key derivation in order to initialize those keys on any system version, and even on Old3DS.<br />
<br />
This can be performed by exploiting the "arm9loaderhax" vulnerability to obtain post-K9L code execution after an MCU reboot (the bootrom section-loading fail is not relevant here, this attack was performed without OTP data by brute-forcing keys), and using this to dump the SHA_HASH register. This attack works on any FIRM version shipping a vulnerable version of K9L, whereas OTP dumping required a boot of <[[3.0.0-6|3.0.0-X]].<br />
<br />
This attack results in obtaining the entire (0x200-bytes) NAND keystore - it was confirmed at a later date that this keystore is encrypted with the same key (by comparing the decrypted data from multiple units), and therefore using another key in this store will not remedy the issue as all keys are known (i.e. later, unused keys decrypt to the same 0x200-bytes constant with the same OTP hash). Later keys could have been encrypted differently but this is not the case. As a result of this, it is not possible for Nintendo to use K9L again in its current format for its intended purpose, though this was not news from the moment people dumped a New3DS OTP.<br />
| Derivation of all New3DS keys generated via the NAND keystore (0x1B "Secure4" etc.)<br />
| None<br />
| [[11.3.0-36|11.3.0-X]]<br />
| ~April 2015, implemented in May 2015<br />
| 13 January 2016<br />
| [[User:WulfyStylez|WulfyStylez]], [[User:Dazzozo|Dazzozo]], [[User:Shinyquagsire23|shinyquagsire23]] (complimentary + implemented), [[User:Plutooo|plutoo]], Normmatt (discovered independently)<br />
|-<br />
| enhanced-arm9loaderhax<br />
| See the 32c3 3ds talk.<br />
Since this is a combination of a trick with the arm9-bootrom + arm9loaderhax, and since you have to manually write FIRM to the firm0/firm1 NAND partitions, this can't be completely fixed. Any system with existing ARM9 code execution and an OTP/OTP hash dump can exploit this. Additionally, by using the FIRM partition known-plaintext bug and bruteforcing the second entry in the keystore, this can currently be exploited on all New3DS systems without any other prerequisite hacks.<br />
| arm9loaderhax which automatically occurs at hard-boot.<br />
| See arm9loaderhax / description.<br />
| See arm9loaderhax / description.<br />
| Theorized around mid July, 2015. Later implemented+tested by [[User:Plutooo|plutoo]] and [[User:Derrek|derrek]].<br />
| 32c3 3ds talk (December 27, 2015)<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| Missing verification-block for the 9.6 keys (arm9loaderhax)<br />
| Starting with [[9.6.0-24|9.6.0-X]] a new set of NAND-based keys were introduced. However, no verification block was added to verify that the new key read from NAND is correct. This was technically an issue from [[9.5.0-22|9.5.0-X]] with the original sector+0 keydata, however the below is only possible with [[9.6.0-24|9.6.0-X]] since keyslots 0x15 and 0x16 are generated from different 0x11 keyXs.<br />
<br />
Writing an incorrect key to NAND will cause arm9loader to decrypt the ARM9 kernel as garbage and then jump to it.<br />
<br />
This allows an hardware-based attack where you can boot into an older exploited firmware, fill all memory with NOP sleds/jump-instructions, and then reboot into executing garbage. By automating this process with various input keydata, eventually you'll find some garbage that jumps to your code.<br />
<br />
This gives very early ARM9 code execution (pre-ARM9 kernel). As such, it is possible to dump RSA keyslots with this and calculate the 6.x [[Savegames#6.0.0-11_Savegame_keyY|save]], and 7.x [[NCCH]] keys. This cannot be used to recover keys initialized by arm9loader itself. This is due to it wiping the area used for its stack during NAND sector decryption and keyslot init. <br />
<br />
Due to FIRMs on both Old and New 3DS using the same RSA data, this can be exploited on Old3DS as well, but only if one already has the actual plaintext normalkey from New3DS NAND sector 0x96 offset-0 and has dumped the OTP area of the Old3DS.<br />
| Recovery of 6.x [[Savegames#6.0.0-11_Savegame_keyY|save key]]/7.x [[NCCH]] key, access to uncleared OTP hash keydata<br />
| None<br />
| [[11.3.0-36|11.3.0-X]]<br />
| March, 2015<br />
| <br />
| [[User:Plutooo|plutoo]]<br />
|-<br />
| Uncleared New3DS keyslot 0x11<br />
| Originally the New3DS [[FIRM]] arm9bin loader only cleared keyslot 0x11 when it gets executed at firmlaunch. This was fixed with [[9.5.0-22|9.5.0-X]] by completely clearing keyslot 0x11 immediately after the loader finishes using keyslot 0x11.<br />
This means that any ARM9 code that can execute before the loader clears the keyslot at firmlaunch(including firmlaunch-hax) can get access to the uncleared keyslot 0x11, which then allows one to generate all <=v9.5 New3DS keyXs which are generated by keyslot 0x11.<br />
<br />
Therefore, to completely fix this the loader would have to generate more keys using different keyslot 0x11 keydata. This was done with [[9.6.0-24|9.6.0-X]].<br />
| New3DS keyXs generation<br />
| Mostly fixed with [[9.5.0-22|9.5.0-X]], completely fixed with new keys with [[9.6.0-24|9.6.0-X]].<br />
| <br />
| February 3, 2015 (one day after [[9.5.0-22|9.5.0-X]] release)<br />
| <br />
| [[User:Yellows8|Yellows8]]<br />
|}<br />
<br />
=== Process9 ===<br />
{| class="wikitable" border="1"<br />
|-<br />
! Summary<br />
! Description<br />
! Successful exploitation result<br />
! Fixed in [[FIRM]] system version<br />
! Last [[FIRM]] system version this flaw was checked for<br />
! Timeframe this was discovered<br />
! Public disclosure timeframe<br />
! Discovered by<br />
|-<br />
| Leak of normal-key matching a key-scrambler key<br />
| New 3DS firmware versions [[8.1.0-0 New3DS|8.1.0]] through [[9.2.0-20|9.2.0]] set the encryption key for [[Amiibo]] data using a hardcoded normal-key in Process9. In firmware [[9.3.0-21|9.3.0]], Nintendo "fixed" this by using the key scrambler instead, by calculating the keyY value for keyslot 0x39 that results in the same normal-key, then hardcoding that keyY into Process9.<br />
<br />
Nintendo's fix is actually the problem: Nintendo revealed the normal-key matching an unknown keyX and a known keyY. Combined with the key scrambler using an insecure scrambling algorithm (see "Hardware" above), the key scrambler function could be deduced.<br />
| Deducing the keyX for keyslot 0x39 and the key scrambler algorithm<br />
| New 3DS [[9.3.0-21|9.3.0-X]], sort of<br />
| [[10.0.0-27|10.0.0-X]]<br />
| Sometime in 2015 after the hardware key-generator was broken.<br />
| 32c3 3ds talk (December 27, 2015)<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| Leak of normal-key matching a key-generator key<br />
| During the 3DS' development (June/July 2010) Nintendo added support installing encrypted content ([[CIA]]). Common-key index1 was intended to be a [[AES|hardware generated key]]. However while they added code to generate the key in hardware, they forgot to remove the normal-key for index1 (used elsewhere, likely old debug code). Nintendo later removed the normal key sometime before the first non-prototype firmware release.<br />
<br />
<br />
Knowing the keyY and the normal-key for common-key index1, the devkit key-generator algorithm can be deduced (see "Hardware" above). Additionally the remaining devkit common-keys can be generated once the common-key keyX is recovered.<br />
<br />
Note the devkit key-generator was discovered to be the same as the retail key-generator.<br />
| Deducing the keyX for keyslot 0x3D and hardware key-generator algorithm. Generate remaining devkit common-keys.<br />
| pre-[[1.0.0-0|1.0.0-X]]<br />
| <br />
| Shortly after the key-generator was revealed to be flawed at the 32c3 3ds talk<br />
| January 20, 2016<br />
| [[User:Jakcron|jakcron]]<br />
|-<br />
| Factory firmware is vulnerable to sighax<br />
| During the 3DS's development, presumably boot9 was written (including the sighax) vulnerability. This vulnerability is also present in factory firmware (and earlier, including 0.11). This was fixed in version 1.0.0-0.<br />
| Deducing the mechanics of the sighax vulnerability in boot9 without having boot9 prot. Arm9 code execution on factory/earlier firmware.<br />
| [[1.0.0-0|1.0.0-X]]<br />
| [[1.0.0-0|1.0.0-X]]<br />
| May 9, 2017<br />
| May 19, 2017<br />
| [[User:SciresM|SciresM]], [[User:Myria|Myria]]<br />
|-<br />
| safefirmhax<br />
| SAFE_MODE_FIRM is almost never updated(even when NATIVE_FIRM is updated for vuln fixes), this can be noticed by ''just'' checking 3dbrew/ninupdates title-listings.<br />
<br />
The fix for 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 <=> Kernel11 sync, PXI sync and then repeat the original attack on SAFE_FIRM instead.<br />
| ARM9 code execution<br />
| [[11.3.0-36|11.3.0-X]]<br />
| <br />
| 2012-2013?<br />
| Wiki: January 2, 2017<br />
| Everyone<br />
|-<br />
| safefirmhax 1.1<br />
| Nintendo's original safefirmhax fix was flawed -- they added a global boolean that got set to true whenever a non-sysmodule title got launched (except for a hardcoded repair title id), and panic()'d if that boolean was true to prevent launching safefirm after hax was active. However, because the boolean was initially false after firmlaunch -- With ARM11-kernel execution, one could FIRM-launch into NATIVE_FIRM, and then immediately FIRM-launch again into SAFE_FIRM early in NATIVE_FIRM boot before the boolean got set to true to repeat the safehax attack.<br />
<br />
This was fixed by adding additional CFG9_BOOTENV checks to firmlaunch code in 11.4.<br />
| ARM9 code execution<br />
| [[11.4.0-37|11.4.0-X]]<br />
| <br />
| safefirmhax fix<br />
| Wiki: April 10, 2017<br />
| Everyone<br />
|-<br />
| ntrcardhax<br />
| When reading the banner of a NTR title, Process9 relies on a hardware register to know when the banner was fully read.<br />
However that register is shared between the ARM9 and the ARM11.<br />
An attacker with k11 control can so make Process9 believe the banner continues forever and so trigger a buffer overflow.<br />
With a custom banner for a NTR flashcart, this leads to code execution in Process9.<br />
<br />
This was fixed by adding bound checks on the read data.<br />
| ARM9 code execution<br />
| [[10.4.0-29|10.4.0-X]]<br />
| <br />
| March 2015<br />
| 32c3 3ds talk (December 27, 2015)<br />
| [[User:Plutooo|plutoo]]<br />
|-<br />
| Title downgrading via [[Application_Manager_Services|AM]]([[Application_Manager_Services_PXI|PXI]])<br />
| When a title is *already* installed, Process9 will compare the installed title-version with the title-version being installed. When the one being installed is older, Process9 would return an error.<br />
<br />
However, this can be bypassed by just deleting the title first via the service command(s) for that: with the title removed from the [[Title_Database]], Process9 can't compare the input title-version with anything. Hence, titles can be downgraded this way.<br />
<br />
[[11.0.0-33|11.0.0-X]] fixed this for key system titles (MSET, Home Menu, spider, ErrDisp, SKATER, NATIVE_FIRM, and every retail system module), by checking the version of the title to install against a hard-coded list of (titleID, minimumVersionRequired) pairs.<br />
| Bypassing title version check at installation, which then allows downgrading any title.<br />
| [[11.0.0-33|11.0.0-X]], for key system titles.<br />
| NATIVE_FIRM / AM-sysmodule [[11.0.0-33|11.0.0-X]]<br />
| ?<br />
| <br />
| ?<br />
|-<br />
| FAT FS code null-deref<br />
| When FSFile:Read is used with a file which is corrupted on a FAT filesystem(in particular SD), Process9 can crash. This particular crash is caused by a function returning NULL instead of an actual ptr due to an error. The caller of that function doesn't check for NULL which then triggers a read based at NULL.<br />
<br />
Sample "fsck.vfat -n -v -V <fat image backup>" output for the above crash:<br />
<br />
<pre>...<br />
Starting check/repair pass.<br />
<FilePath0> and<br />
<FilePath1><br />
share clusters.<br />
Truncating second to 3375104 bytes.<br />
<FilePath1><br />
File size is 2787392 bytes, cluster chain length is 16384 bytes.<br />
Truncating file to 16384 bytes.<br />
Checking for unused clusters.<br />
Reclaimed 1 unused cluster (16384 bytes).<br />
Checking free cluster summary.<br />
Free cluster summary wrong (1404490 vs. really 1404491)<br />
Auto-correcting.<br />
Starting verification pass.<br />
Checking for unused clusters.<br />
Leaving filesystem unchanged.</pre><br />
| Useless null-based-read<br />
| None<br />
| [[9.6.0-24|9.6.0-X]]<br />
| July 8-9, 2015<br />
| <br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| RSA signature padding checks<br />
| The TWL_FIRM RSA sig padding check code used for all TWL RSA sig-checks has issues, see [[FIRM|here]].<br />
The main 3DS RSA padding check code(non-certificate, including NATIVE_FIRM) uses the function used with the above to extract more padding + the actual hash from the additional padding. This isn't really a problem here because there's proper padding check code which is executed prior to this.<br />
| <br />
| None<br />
| [[9.5.0-22|9.5.0-X]]<br />
| March 2015<br />
| <br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[AMPXI:ValidateDSiWareSectionMAC]] [[AES_Registers|AES]] keyslot reuse<br />
| When the input DSiWare section index is higher than <max number of DSiWare sections supported by this FIRM>, Process9 uses keyid 0x40 for calculating the AESMAC, which translates to keyslot 0x40. The result is that the keyslot is left at whatever was already selected before, since the AES selectkeyslot code will immediately return when keyslot is >=0x40. However, actually exploiting this is difficult: the calculated AESMAC is never returned, this command just compares the calculated AESMAC with the input AESMAC(result-code depends on whether the AESMACs match). It's unknown whether a timing attack would work with this.<br />
This is basically a different form of the pxips9 keyslot vuln, except with AESMAC etc.<br />
| See description.<br />
| None<br />
| [[11.3.0-36|11.3.0-X]]<br />
| March 15, 2015<br />
| December 29, 2015<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| pxips9 [[AES_Registers|AES]] keyslot reuse<br />
| This requires access to the [[Process_Services|ps:ps]]/pxi:ps9 services. One way to get access to this would be snshax on system-version <=10.1.0-X(see 32c3 3ds talk).<br />
When an invalid key-type value is passed to any of the PS commands, Process9 will try to select keyslot 0x40. That aesengine_setkeyslot() code will then immediately return due to the invalid keyslot value. Since that function doesn't return any errors, Process9 will just continue to do crypto with whatever AES keyslot was selected before the PS command was sent.<br />
| Reusing the previously used keyslot, for crypto with PS.<br />
| None<br />
| [[11.3.0-36|11.3.0-X]]<br />
| Roughly the same time(same day?) as firmlaunch-hax.<br />
| December 29, 2015<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| firmlaunch-hax: FIRM header ToCToU<br />
| This can't be exploited from ARM11 userland.<br />
During [[FIRM]] launch, the only FIRM header the ARM9 uses at all is stored in FCRAM, this is 0x200-bytes(the actual used FIRM RSA signature is read to the Process9 stack however). The ARM9 doesn't expect "anything" besides the ARM9 to access this data.<br />
With [[9.5.0-22]] the address of this FIRM header was changed from a FCRAM address, to ARM9-only address 0x01fffc00.<br />
| ARM9 code execution<br />
| [[9.5.0-22]]<br />
| <br />
| 2012, 3 days after [[User:Yellows8|Yellows8]] started Process9 code RE.<br />
| <br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| Uninitialized data output for (PXI) command replies<br />
| PXI commands for various services(including some [[Filesystem_services_PXI|here]] and many others) can write uninitialized data (like from ARM registers) to the command reply. This happens with stubbed commands, but this can also occur with certain commands when returning an error.<br />
Certain ARM11 service commands have this same issue as well.<br />
| <br />
| None<br />
| [[9.3.0-21|9.3.0-X]]<br />
| ?<br />
| <br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[Filesystem_services_PXI|FSPXI]] OpenArchive SD permissions<br />
| Process9 does not use the exheader ARM9 access-mount permission flag for SD at all.<br />
This would mean ARM11-kernelmode code / fs-module itself could directly use FSPXI to access SD card without ARM9 checking for SD access, but this is rather useless since a process is usually running with SD access(Home Menu for example) anyway.<br />
| <br />
| None<br />
| [[9.3.0-21|9.3.0-X]]<br />
| 2012<br />
| <br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[AMPXI:ExportDSiWare]] export path<br />
| Process9 allocates memory on Process9 heap for the export path then verifies that the actual allocated size matches the input size. Then Process9 copies the input path from FCRAM to this buffer, and uses it with the Process9 FS openfile code, which use paths in the form of "<mountpoint>:/<path>".<br />
Process9 does not check the contents of this path at all before passing it to the FS code, besides writing a NUL-terminator to the end of the buffer.<br />
| Exporting of DSiWare to arbitrary Process9 file-paths, such as "nand:/<path>" etc. This isn't really useful since the data which gets written can't be controlled.<br />
| None<br />
| [[9.5.0-22]]<br />
| April 2013<br />
| <br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[DSiWare_Exports]] [[CTCert]] verification<br />
| Just like DSi originally did, 3DS verifies the APCert for DSiWare on SD with the CTCert also in the DSiWare .bin. On DSi this was fixed with with system-version 1.4.2 by verifying with the actual console-unique cert instead(stored in NAND), while on 3DS it's still not(?) fixed.<br />
On 3DS however this is useless, unless one can obtain the console-unique movable.sed keyY which encrypts the entire DSiWare .bin.<br />
| When the movable.sed keyY for the target 3DS is known and the target 3DS CTCert private-key is unknown, importing of modified DSiWare SD .bin files.<br />
| None.<br />
| 11.6.0-X<br />
| April 2013<br />
| <br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| movable.sed keyY vulnerable to brute-force<br />
| Half of the movable.sed keyY's 128 bits are leaked through the [[Nandrw/sys/LocalFriendCodeSeed_B|LFCS]], which is available in userland and below. The LFCS itself also leaks almost half of the remaining bits by following the ratio: u32 keyY[3]=1/5(LFCS). The remaining keyY[3] uncertainty of about ±2000 can be greatly reduced by plotting expected error margins with several keyYs. This results in a final uncertainty of about 2^40, easily within practical brute force range of an average modern PC.<br />
| Knowing the keyY of a given 3ds allows for modification of DSiWare export contents, and chained with several other public vulns, ultimately arm9 execution.<br />
| None.<br />
| 11.6.0-X<br />
| December 2017<br />
| January 2018<br />
| zoogie<br />
|-<br />
| Improper validation of DSiWare title SRLs<br />
| The 3DS does not verify if the actual SRL embedded in the title's directory matches the titleID in the TMD before launching it or importing it from an sd DSiWare export. <br />
| This allows embedding older, exploitable DSiWare titles in completely different, unexploitable DSiWare titles. Since DSiWare has raw NAND RW, this can result in arm9 control through FIRM known-plaintext and sighax attacks.<br />
| None.<br />
| 11.6.0-X<br />
| 2015?<br />
| December 2016<br />
| Everyone<br />
|-<br />
| [[Gamecard_Services_PXI]] unchecked REG_CTRCARDCNT transfer-size<br />
| The u8 REG_CTRCARDCNT transfer-size parameter for the [[Gamecard_Services_PXI]] read/write CTRCARD commands is used as an index for an array of u16 values. Before [[5.0.0-11|5.0.0-X]] this u8 value wasn't checked, thus out-of-bounds reads could be triggered(which is rather useless in this case).<br />
| Out-of-bounds read for a value which gets written to a register.<br />
| [[5.0.0-11|5.0.0-X]]<br />
| <br />
| 2013?<br />
| <br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[PXI_Registers|PXI]] cmdbuf buffer overrun<br />
| The Process9 code responsible [[PXI_Registers|PXI]] communications didn't verify the size of the incoming command before writing it to a C++ member variable. <br />
| Probably ARM9 code execution<br />
| [[5.0.0-11|5.0.0-11]]<br />
| <br />
| March 2015, original timeframe if any unknown<br />
| <br />
| [[User:Plutooo|plutoo]]/[[User:Yellows8|Yellows8]]/maybe others(?)<br />
|-<br />
| [[Application_Manager_Services_PXI|PXIAM]] command 0x003D0108(See also [[Application_Manager_Services|this]])<br />
| When handling this command, Process9 allocates a 0x2800-byte heap buffer, then copies the 4 FCRAM input buffers to this heap buffer without checking the sizes at all(only the buffers with non-zero sizes are copied). Starting with [[5.0.0-11|5.0.0-X]], the total combined size of the input data must be <=0x2800.<br />
| ARM9 code execution<br />
| [[5.0.0-11|5.0.0-X]]<br />
| <br />
| May 2013<br />
| <br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[Process_Services_PXI|PS RSA]] commands buffer overflows<br />
| pxips9 cmd1(not accessible via ps:ps) and VerifyRsaSha256: unchecked copy to a buffer in Process9's .bss, from the input FCRAM buffer. The buffer is located before the pxi cmdhandler threads' stacks. SignRsaSha256 also has a buf overflow, but this isn't exploitable.<br />
The buffer for this is the buffer for the signature data. With v5.0, the signature buffer was moved to stack, with a check for the signature data size. When the signature data size is too large, Process9 uses [[SVC|svcBreak]].<br />
| ARM9 code execution<br />
| [[5.0.0-11|5.0.0-X]]<br />
| <br />
| 2012<br />
| <br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[PXI_Registers|PXI]] pxi_id bad check<br />
| The Process9 code responsible for [[PXI_Registers|PXI]] communications read pxi_id as a signed char. There were two flaws:<br />
* They used it as index to a lookup-table without checking the value at all.<br />
* Another function verified that pxi_id < 7, allowing negative values to pass the check. This would also cause an out-of-range table-lookup.<br />
| Maybe ARM9 code execution<br />
| [[3.0.0-5|3.0.0-5]]<br />
|<br />
| March 2015, originally 2012 for the first issue at least<br />
| <br />
| [[User:Plutooo|plutoo]], [[User:Yellows8|Yellows8]], maybe others(?)<br />
|}<br />
<br />
=== Kernel9 ===<br />
{| class="wikitable" border="1"<br />
|-<br />
! Summary<br />
! Description<br />
! Successful exploitation result<br />
! Fixed in [[FIRM]] system version<br />
! Last [[FIRM]] system version this flaw was checked for<br />
! Timeframe this was discovered<br />
! Discovered by<br />
|-<br />
| [[CONFIG Registers#CFG_SYSPROT9|CFG_SYSPROT9]] bit1 not set by Kernel9<br />
| Old versions of Kernel9 never set bit1 of [[CONFIG Registers#CFG_SYSPROT9|CFG_SYSPROT9]]. This leaves the [[OTP Registers|0x10012000]]-region unprotected (this region should be locked early during boot!). Since it's never locked, you can dump it once you get ARM9 code execution.<br />
<br />
From [[3.0.0-5|3.0.0-X]] this was fixed by setting the bit in Kernel9 after poking some registers in that region. On New3DS arm9loader sets this bit instead of Kernel9, which is exploitable through a hardware + software vulnerability (see arm9loaderhax / description).<br />
<br />
This flaw resurged when it gained a new practical use: retrieving the OTP data for a New3DS console in order to decrypt the key data used in arm9loader (see enhanced-arm9loaderhax / description). This was performed by downgrading to a vulnerable system version. By accounting for differences in CTR-NAND crypto (0x05 -> 0x04, see partition encryption types [[Flash_Filesystem#NAND_structure|here]]) and using an Old3DS [[NCSD#NCSD_header|NCSD Header]], it is possible to boot a New3DS using Old3DS firmware 1.0-2.x to retrieve the required OTP data using this flaw.<br />
| Dumping the [[OTP Registers|OTP]] area.<br />
Decrypting New3DS sector 0x96 keyblock.<br />
| [[3.0.0-5|3.0.0-X]]<br />
|<br />
| February 2015<br />
| [[User:Plutooo|plutoo]], Normmatt independently<br />
|}<br />
<br />
== ARM11 software ==<br />
=== Kernel11 ===<br />
{| class="wikitable" border="1"<br />
|-<br />
! Summary<br />
! Description<br />
! Successful exploitation result<br />
! Fixed in [[FIRM]] system version<br />
! Last [[FIRM]] system version this flaw was checked for<br />
! Timeframe this was discovered<br />
! Discovered by<br />
|-<br />
| [[SVC|svcSetProcessIdealProcessor]] reference count overflow and therefore use-after-free.<br />
| The SVC receive two arguments: handle and idealprocessor. The handle is used to get the KProcess object and the KProcess->refCnt gets incremented,later the function check if the KProcess->mem_type != BASE and if yes, it checks for idealprocessor == 2 or idealprocessor != 3. The problem here is that if you pass the idealprocessor = 3 it won't meet any condition and return the error 0xD9001BEA without decrement the reference count. <br />
It can be abused to overflow the KProcess reference count that will lead to an Use-after-free. <br />
| Before [[11.2.0-35|11.2.0-X]]: reference count overflow and therefore use-after-free.<br />
| <br />
| [[11.6.0-39|11.6.0-X]]<br />
| November 2, 2017<br />
| [[User:st4rk|st4rk]]<br />
|-<br />
| [[SVC|svcGetThreadList]] process reference leak<br />
| When given a valid process handle (including <code>0xFFFF8001</code>), svcGetThreadList forgets to decrement the reference count of the underlying [[KProcess]] instance, after having finished using it.<br />
| Before [[11.2.0-35|11.2.0-X]]: reference count overflow and therefore use-after-free, but this UAF was most likely not exploitable<br />
| <br />
| [[11.3.0-36|11.3.0-X]]<br />
| April 3, 2017<br />
| [[User:TuxSH|TuxSH]]<br />
|-<br />
| kernelhax via gspwn<br />
| Originally the kernel didn't initialize [[CONFIG11_Registers#CFG11_GPUPROT|CFG11_GPUPROT]]. Since it's 0 at hard-boot, this allowed the GPU to access the entire FCRAM + AXIWRAM.<br />
| Entire FCRAM+AXIWRAM R/W.<br />
| [[3.0.0-5|3.0.0-X]]<br />
| <br />
| February 7, 2017<br />
| [[User:Plutooo|plutoo]], [[User:Yellows8|Yellows8]] partly<br />
|-<br />
| fasthax<br />
| When a KTimer is created in pulse mode, the kernel calls a virtual function to reset the timer each time it pulses. The scheduler is locked for that core to avoid race conditions, but another core can call CloseHandle on the timer and free it, leading to a UAF vtable call.<br />
| See description.<br />
| [[11.3.0-36|11.3.0-X]]<br />
| [[11.3.0-36|11.3.0-X]]<br />
| May 2016<br />
| nedwill<br />
|-<br />
| ipctakeover<br />
| When sending cmdreplies, it does not validate that the src_addr and src_size match the equivalent dst_addr and dst_size. With a modified addr/size specified in a cmdreply for an output buffer, the data-copy for the first/last pages could be used to overwrite data outside of the buffer specified by the original process.<br />
<br />
Used by ctr-httpwn as of v1.2, for "ipctakeover/bosshaxx".<br />
<br />
This can be used to takeover processes where the process is using your service session. Like HTTPC -> BOSS, for bosshaxx above. NIM takeover can be done too(actual stack buffer overflow can trigger), etc.<br />
| See description.<br />
| None<br />
| [[11.3.0-36|11.3.0-X]]<br />
| November 26, 2016<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| Using IPC input buffers as output buffers<br />
| When sending cmdreplies, it does not validate that the cmdreply descriptor type matches the equivalent cmdreq descriptor type. This could be used by an exploited sysmodule to use what was intended as an input-buffer as an output-buffer, and also combine other IPC vuln(s) with this.<br />
<br />
Used by ctr-httpwn as of v1.2, for "ipctakeover/bosshaxx".<br />
| See description.<br />
| None<br />
| [[11.3.0-36|11.3.0-X]]<br />
| November 2016<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[SVC]] table too small<br />
| The table of function pointers for SVC's only contains entries up to 0x7D, but the biggest allowed SVC for the table is 0x7F. Thus, executing SVC7E or SVC7F would make the SVC-handler read after the buffer, and interpret some ARM instructions as function pointers.<br />
<br />
However, this would require patching the kernel .text or modifying SVC-access-control. Even if you could get these to execute, they would still jump to memory that isn't mapped as executable.<br />
| <br />
| None<br />
| [[11.3.0-36|11.3.0-X]]<br />
| 2012<br />
| Everyone<br />
|-<br />
| [[SVC|svcBackdoor (0x7B)]]<br />
| This backdoor allows executing SVC-mode code at the user-specified code-address. This is used by Process9, using this on the ARM11 (with NATIVE_FIRM) required patching the kernel .text or modifying SVC-access-control.<br />
| See description<br />
| [[11.0.0-33|11.0.0-X]] (deleted)<br />
| <br />
|<br />
| Everyone<br />
|-<br />
| veryslowpidhax<br />
| '''This is completely different from the kernelmode-code-execution vuln described in the below separate entry.'''<br />
<br />
When updating the kernel global PID counter under [[SVC|svcCreateProcess]] the kernel does not check for wraparound to 0x0(the PID for the very first process). This only matters because [[Services|SM-module]] allows processes with PID value less than <total ARM11 FIRM modules> to access ''all'' services, without checking exheader service-access-control; and because Kernel11 checks for the PID to be 1 (loader) to use the input mem-region value on ControlMemory. This alone does not affect access the [[SVC|SVCs]] access table at all.<br />
<br />
Inlined ldrex+strex code is used for updating the above counter. [[11.2.0-35|11.2.0-X]] had changes for similar code, but it was only for dedicated ldrex+strex functions(mainly for kernel objects) and hence this PID code was not affected.<br />
<br />
With launching+terminating a sysmodule repeatedly with this via ns:s, it would take weeks to finish(if not at least about a month?).<br />
| Access to all [[Services_API|services]], ControlMemory on any given mem-region.<br />
| None<br />
| [[11.3.0-36|11.3.0-X]]<br />
| 2012 maybe?<br />
| <br />
|-<br />
| slowhax/waithax<br />
| svcWaitSynchronizationN does not decrement the references to valid handles in an array before returning an error when it encounters an invalid handle. This allows one to (slowly) overflow the reference count for a handle object to zero.<br />
| ARM11 kernel-mode code execution<br />
| [[11.2.0-35|11.2.0-X]]<br />
| [[11.2.0-35|11.2.0-X]]<br />
| 2016<br />
| nedwill, [[User:Derrek|derrek]]<br />
|-<br />
| [[Memory_layout#ARM11_Detailed_virtual_memory_map|0xEFF00000]] / 0xDFF00000 ARM11 kernel virtual-memory<br />
| The ARM11 kernel-mode 0xEFF00000/0xDFF00000 virtual-memory(size 0x100000) is mapped to phys-mem 0x1FF00000(entire DSP-mem + entire AXIWRAM), with permissions RW-. This is used during ARM11 kernel startup for loading the FIRM-modules from the FIRM section located in DSP-mem, this never seems to be used after that, however. This is never unmapped either.<br />
| <br />
| None<br />
| [[11.3.0-36|11.3.0-X]]<br />
| <br />
| <br />
|-<br />
| memchunkhax2.1<br />
| Nintendo's fix for memchunkhax2 in [[10.4.0-29|10.4.0-X]] did not fix the GPU case: one may cause the requisite ToCToU race using gspwn, bypassing the new validation.<br />
derrek's original 32c3 presentation for memchunkhax2 commented that a GPU-based attack was possible, but would be difficult. However, memchunkhax2.1 showed that it was possible to do fairly reliably.<br />
| ARM11 kernel code execution<br />
| [[11.0.0-33|11.0.0-X]], via the new [[Memory_Management#MemoryBlockHeader|memchunkhdr]] MAC which prevents modifying memchunkhdr data with DMA.<br />
| [[11.0.0-33|11.0.0-X]]<br />
|<br />
| [[User:Derrek|derrek]], aliaspider<br />
|-<br />
| memchunkhax2<br />
| When allocating a block of memory, the "next" pointer of the [[Memory_Management#MemoryBlockHeader|memchunkhdr]] is accessed without being checked after being mapped to userland.<br />
This allows a race condition, where the process can change the next pointer just before it's accessed. By pointing the next pointer to a crafted memchunckhdr in the kernel SlabHeap, some of the SlabHeap is allocated to the calling process, allowing to change vtables of kernel objects. <br />
| ARM11 kernel code execution<br />
| [[10.4.0-29|10.4.0-X]] (partially, see memchunkhax2.1)<br />
| [[10.4.0-29|10.4.0-X]]<br />
|<br />
| [[User:Derrek|derrek]]<br />
|-<br />
| heaphax<br />
| Can change the size of free memchunk structures stored in FCRAM using DMA, which leads to the ability to allocate memory chunks over already-allocated memory. This can be used in the SYSTEM region to allocate RW memory over any part of the NS system module, which is enough to take it over.<br />
| Code execution with access to all of NS's privileges. (including downgrading) Code execution within any applet.<br />
| [[11.0.0-33|11.0.0-X]], via the new [[Memory_Management#MemoryBlockHeader|memchunkhdr]] MAC which prevents modifying memchunkhdr data with DMA.<br />
| [[11.0.0-33|11.0.0-X]]<br />
| April 2015 ?<br />
| smea<br />
|-<br />
| snshax<br />
| Can force creation of Safe NS process into gspwn-able memory, allowing for takeover.<br />
| Code execution with access to all of NS's privileges. (including downgrading)<br />
| [[10.1.0-27|10.1.0-X]]<br />
| [[10.1.0-27|10.1.0-X]]<br />
| April 2015 ?<br />
| smea<br />
|-<br />
| AffinityMask/processorid validation<br />
| With [[10.0.0-27|10.0.0-X]] the following functions were updated: svcGetThreadAffinityMask, svcGetProcessAffinityMask, svcSetProcessAffinityMask, and svcCreateThread. The code changes for all but svcCreateThread are identical.<br />
The original code with the first 3 did the following: <br />
* if(u32_processorcount > ~0x80000001)return 0xe0e01bfd;<br />
* if(s32_processorcount > <total_cores>)return 0xd8e007fd;<br />
The following code replaced the above:<br />
* if(u32_processorcount >= <total_cores+1>)return 0xd8e007fd;<br />
In theory the latter should catch everything that the former did, so it's unknown if this was really a security issue.<br />
<br />
The svcCreateThread changes with [[10.0.0-27|10.0.0-X]] definitely did fix a security issue.<br />
* Original code: "if(s32_processorid > <total_cores>)return 0xd8e007fd;"<br />
* New code: "if(s32_processorid >= <total_cores> || s32_processorid <= -4)return 0xd8e007fd;"<br />
This fixed an off-by-one issue: if one would use processorid=total_cores, which isn't actually a valid value, svcCreateThread would accept that value on <[[10.0.0-27|10.0.0-X]]. This results in data being written out-of-bounds(baseaddr = arrayaddr + entrysize*processorid), which has the following result:<br />
* Old3DS: Useless kernel-mode crash due to accessing unmapped memory.<br />
* New3DS: uncontrolled data write into a kernel-mode L1 MMU-table. This isn't really useful: the data can't be controlled, and the data which gets overwritten is all-zero anyway(this isn't anywhere near MMU L1 entries for actually mapped memory).<br />
The previous version also allowed large negative s32_processorid values(negative processorid values are special values not actual procids), but it appears using values like that won't actually do anything(meaning no crash) besides the thread not running / thread not running for a while(besides triggering a kernelpanic with certain s32_processorid value(s)).<br />
| Nothing useful<br />
| [[10.0.0-27|10.0.0-X]]<br />
| [[10.0.0-27|10.0.0-X]]<br />
| svcCreateThread issue: May 31, 2015. The rest: September 8, 2015, via v9.6->v10.0 ARM11-kernel code-diff.<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| memchunkhax<br />
| The kernel originally did not validate the data stored in the FCRAM kernel heap [[Memchunkhdr|memchunk-headers]] for free-memory at all. Exploiting this requires raw R/W access to these memchunk-headers, like physical-memory access with gspwn.<br />
<br />
There are ''multiple'' ways to exploit this, but the end-result for most of these is the same: overwrite code in AXIWRAM via the 0xEFF00000/0xDFF00000 kernel virtual-memory mapping.<br />
<br />
This was fixed in [[9.3.0-21|9.3.0-X]] by checking that the memchunk(including size, next, and prev ptrs) is located within the currently used heap memory. The kernel may also check that the next/prev ptrs are valid compared to other memchunk-headers basically. When any of these checks fail, kernelpanic() is called.<br />
| When combined with other flaws: ARM11-kernelmode code execution<br />
| [[9.3.0-21|9.3.0-21]]<br />
| <br />
| February 2014<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| Multiple [[KLinkedListNode|KLinkedListNode]] SlabHeap use after free bugs<br />
| The ARM11-kernel did access the 'key' field of [[KLinkedListNode|KLinkedListNode]] objects, which are located on the SlabHeap, after freeing them. Thus, triggering an allocation of a new [[KLinkedListNode|KLinkedListNode]] object at the right time could result in a type-confusion. Pseudo-code:<br />
SlabHeap_free(KLinkedListNode);<br />
KObject *obj = KLinkedListNode->key; // the object there might have changed!<br />
This bug appeared all over the place.<br />
| ARM11-kernelmode code exec maybe<br />
| [[8.0.0-18|8.0.0-18]]<br />
| <br />
| April 2015<br />
| [[User:Derrek|derrek]]<br />
|-<br />
| PXI [[RPC_Command_Structure|Command]] input/output buffer permissions<br />
| Originally the ARM11-kernel didn't check permissions for PXI input/output buffers for commands. Starting with [[6.0.0-11|6.0.0]] PXI input/output buffers must have RW permissions, otherwise kernelpanic is triggered.<br />
| <br />
| [[6.0.0-11|6.0.0-11]]<br />
| <br />
| 2012<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[SVC|svcStartInterProcessDma]]<br />
| For svcStartInterProcessDma, the kernel code had the following flaws:<br />
<br />
* Originally the ARM11-kernel read the input DmaConfig structure directly in kernel-mode(ldr(b/h) instructions), without checking whether the DmaConfig address is readable under userland. This was fixed by copying that structure to the SVC-mode stack, using the ldrbt instruction.<br />
<br />
* Integer overflows for srcaddr+size and dstaddr+size are now checked(with [[6.0.0-11]]), which were not checked before.<br />
<br />
* The kernel now also checks whether the srcaddr/dstaddr (+size) is within userland memory (0x20000000), the kernel now (with [[6.0.0-11]]) returns an error when the address is beyond userland memory. Using an address >=0x20000000 would result in the kernel reading from the process L1 MMU table, beyond the memory allocated for that MMU table(for vaddr->physaddr conversion). <br />
| <br />
| [[6.0.0-11]]<br />
| <br />
| DmaConfig issue: unknown. The rest: 2014<br />
| [[User:Plutooo|plutoo]], [[User:Yellows8|Yellows8]] independently<br />
|-<br />
| [[SVC|svcControlMemory]] Parameter checks<br />
| For svcControlMemory the parameter check had these two flaws:<br />
<br />
* The allowed range for addr0, addr1, size parameters depends on which MemoryOperation is being specified. The limitation for GSP heap was only checked if op=(u32)0x10003. By setting a random bit in op that has no meaning (like bit17?), op would instead be (u32)0x30003, and the range-check would be less strict and not accurate. However, the kernel doesn't actually use the input address for LINEAR memory-mapping at all besides the range-checks, so this isn't actually useful. This was fixed in the kernel by just checking for the LINEAR bit, instead of comparing the entire MemoryOperation value with 0x10003.<br />
<br />
* Integer overflows on (addr0+size) are now checked that previously weren't (this also applies to most other address checks elsewhere in the kernel).<br />
<br />
| <br />
| [[5.0.0-11]]<br />
| <br />
|<br />
| [[User:Plutooo|plutoo]]<br />
|-<br />
| [[RPC_Command_Structure|Command]] request/response buffer overflow<br />
| Originally the kernel did not check the word-values from the command-header. Starting with [[5.0.0-11]], the kernel will trigger a kernelpanic() when the total word-size of the entire command(including the cmd-header) is larger than 0x40-words (0x100-bytes). This allows overwriting threadlocalstorage+0x180 in the destination thread. However, since the data written there would be translate parameters (such as header-words + buffer addresses), exploiting this would likely be very difficult, if possible at all.<br />
<br />
If the two words at threadlocalstorage+0x180 could be overwritten with controlled data this way, one could then use a command with a buffer-header of <nowiki>((size<<14) | 2)</nowiki> to write arbitrary memory to any RW userland memory in the destination process.<br />
| <br />
| [[5.0.0-11]]<br />
| <br />
| v4.1 FIRM -> v5.0 code diff<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[SVC|SVC stack allocation overflows]]<br />
| <br />
* Syscalls that allocate a variable-length array on stack, only checked bit31 before multiplying by 4/16 (when calculating how much memory to allocate). If a large integer was passed as input to one of these syscalls, an integer overflow would occur, and too little memory would have been allocated on stack resulting in a buffer overrun. <br />
* The alignment (size+7)&~7 calculation before allocation was not checked for integer overflow.<br />
<br />
This might allow for ARM11 kernel code-execution.<br />
<br />
(Applies to svcSetResourceLimitValues, svcGetThreadList, svcGetProcessList, svcReplyAndReceive, svcWaitSynchronizationN.)<br />
| <br />
| [[5.0.0-11]]<br />
| <br />
| v4.1 FIRM -> v5.0 code diff<br />
| [[User:Plutooo|plutoo]], [[User:Yellows8|Yellows8]] complementary<br />
|-<br />
| [[SVC|svcControlMemory]] MemoryOperation MAP memory-permissions<br />
| svcControlMemory with MemoryOperation=MAP allows mapping the already-mapped process virtual-mem at addr1, to addr0. The lowest address permitted for addr1 is 0x00100000. Originally the ARM11 kernel didn't check memory permissions for addr1. Therefore .text as addr1 could be mapped elsewhere as RW- memory, which allowed ARM11 userland code-execution.<br />
| <br />
| [[4.1.0-8]]<br />
| <br />
| 2012<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[RPC_Command_Structure|Command]] input/output buffer permissions<br />
| Originally the ARM11 kernel didn't check memory permissions for the input/output buffers for commands. Starting with [[4.0.0-7]] the ARM11 kernel will trigger a kernelpanic() if the input/output buffers don't have the required memory permissions. For example, this allowed a FSUSER file-read to .text, which therefore allowed ARM11-userland code execution.<br />
| <br />
| [[4.0.0-7]]<br />
| <br />
| 2012<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[SVC|svcReadProcessMemory/svcWriteProcessMemory memory]] permissions<br />
| Originally the kernel only checked the first page(0x1000-bytes) of the src/dst buffers, for svcReadProcessMemory and svcWriteProcessMemory. There is no known retail processes which have access to these SVCs.<br />
| <br />
| [[4.0.0-7]]<br />
| <br />
| 2012?<br />
| [[User:Yellows8|Yellows8]]<br />
|}<br />
<br />
=== [[FIRM]] Sysmodules ===<br />
{| class="wikitable" border="1"<br />
|-<br />
! Summary<br />
! Description<br />
! Successful exploitation result<br />
! Fixed in [[FIRM]] system version<br />
! Last [[FIRM]] system version this flaw was checked for<br />
! Timeframe this was discovered<br />
! Discovered by<br />
|-<br />
| [[Services|"srv:pm"]] process registration<br />
| Originally any process had access to the port "srv:pm". The PID's used for the (un)registration commands are not checked either. This allowed any process to re-register itself with "srv:pm", and therefore allowed the process to give itself access to any service, bypassing the exheader service-access-control list.<br />
<br />
This was fixed in [[7.0.0-13]]: starting with [[7.0.0-13]] "srv:pm" is now a service instead of a globally accessible port. Only processes with PID's less than 6 (in other words: fs, ldr, sm, pm, pxi modules) have access to it. With [[7.0.0-13]] there can only be one session for "srv:pm" open at a time(this is used by pm module), svcBreak will be executed if more sessions are opened by the processes which can access this.<br />
<br />
This flaw was needed for exploiting the <=v4.x Process9 PXI vulnerabilities from ARM11 userland ROP, since most applications don't have access to those service(s).<br />
| Access to arbitrary services<br />
| [[7.0.0-13]]<br />
| <br />
| 2012<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| FSDIR null-deref<br />
| [[Filesystem_services|FS]]-module may crash in some cases when handling directory reading. The trigger seems to be due to using [[FSDir:Close]] without closing the dir-handle afterwards?(Perhaps this is caused by out-of-memory?) This seems to be useless since it's just a null-deref.<br />
| <br />
| None<br />
| [[9.6.0-24|9.6.0-X]]<br />
| May 19(?)-20, 2015<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[SM]] out-of-bounds BSS write (table 1 entry too small)<br />
| After accepting a new session, [[SM]] writes a (handler ID (0 for srv: sessions (max. 64), 1 for the srv:pm one), pointer to session context structure in BSS) pair in a global array. However that array is only 64-entry-big instead of 65 (as it ought to be), and no bound check is done in that regard.<br />
<br />
Unfortunately, as of [[11.4.0-37]], the overwritten fields are totally unused after their initialization by <code>__libc_init_array</code>.<br />
| Not currently exploitable<br />
| None<br />
| [[11.4.0-37]]<br />
|<br />
|<br />
|}<br />
<br />
=== Standalone Sysmodules ===<br />
{| class="wikitable" border="1"<br />
|-<br />
! Summary<br />
! Description<br />
! Successful exploitation result<br />
! Fixed in system-module system-version<br />
! Last system-module system-version this flaw was checked for<br />
! Timeframe this was discovered<br />
! Timeframe this was added to wiki<br />
! Discovered by<br />
|-<br />
| [[MP:SendDataFrame]] missing input array index validation<br />
| [[MP:SendDataFrame]] doesn't validate the input index at cmdreq[1], unless the function for flag=non-zero is executed. This is used to calculate the following, without validating the index at all: someptr = stateptr + (index*0x924) + somestateoffset.<br />
<br />
After validating some flags from someptr, when input_flag=0 the input buffer data is copied to someptr+someotheroffset+0x14 with the u16 size loaded from someptr+someotheroffset.<br />
<br />
With a large input index someptr could be setup to be at a <target address>, for overwriting memory.<br />
<br />
This is probably difficult to exploit.<br />
| <br />
| None<br />
| [[8.0.0-18]](MP-sysmodule v2048)<br />
| January 22, 2017<br />
| January 22, 2017<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[MP_Services|MP]] cmd1 out-of-bounds handle read<br />
| MP-sysmodule handles the input parameter for cmd1 as a s32. It checks for >=16, but not <0. With <16 it basically does the following(array of entries 4-bytes each): *outhandle = ((Handle*)(stateptr+offsetinstate))[inputindex].<br />
<br />
Hence, this can be used to load any handle in MP-sysmodule memory. MP doesn't really have any service handles of interest however(can be obtained from elsewhere too).<br />
| Reading any handle in MP-sysmodule memory.<br />
| None<br />
| [[8.0.0-18]](MP-sysmodule v2048)<br />
| January 21, 2017<br />
| January 22, 2017<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| AM stack/.bss infoleak via [[AM:ReadTwlBackupInfo]]([[AM:ReadTwlBackupInfoEx|Ex]])<br />
| After writing the output-info structure to stack, it then copies that structure to the output buffer ptr using the size from the command. The size is not checked. This could be used to read data from the AM-service-thread stack handling the command + .bss.<br />
<br />
'''This was not tested on hardware.'''<br />
| Stack/.bss reading<br />
| None<br />
| [[10.0.0-27]](AM v9217)<br />
| Roughly October 17, 2016<br />
| October 25, 2016<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[MVD_Services|MVD]]: Stack buffer overflow with [[MVDSTD:SetupOutputBuffers]].<br />
| The input total_entries is not validated when initially processing the input entry-list. This fixed-size input entry-list is copied to stack from the command request. The loop for processing this initializes a global table, the converted linearmem->physaddrs used there are also copied to stack(0x8-bytes of physaddrs per entry).<br />
<br />
If total_entries is too large, MVD-sysmodule will crash due to reading unmapped memory following the stack(0x10000000). Afterwards if the out-of-bounds total_entries is smaller than that, it will crash due accessing address 0x0, hence this useless.<br />
| MVD-sysmodule crash.<br />
| None<br />
| [[9.0.0-20]]<br />
| April 22, 2016 (Tested on the 25th)<br />
| April 25, 2016<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[NWM_Services|NWM]]: Using CTRSDK heap with UDS sharedmem from the user-process.<br />
| See the HTTP-sysmodule section below.<br />
<br />
CTRSDK heap is used with the sharedmem from [[NWMUDS:InitializeWithVersion]]. Buffers are allocated/freed under this heap using [[NWMUDS:Bind]] and [[NWMUDS:Unbind]].<br />
<br />
Hence, overwriting sharedmem with gspwn then using [[NWMUDS:Unbind]] results in the usual controlled CTRSDK memchunk-header write, similar to HTTP-sysmodule.<br />
<br />
This could be done by creating an UDS network, without any other nodes on the network.<br />
<br />
Besides CTRSDK memchunk-headers, there are no addresses stored under this sharedmem.<br />
| ROP under NWM-module.<br />
| [[11.4.0-37|11.4.0-X]]<br />
| [[9.0.0-20|9.0.0-X]]<br />
| April 10, 2016<br />
| April 16, 2016<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[DLP_Services|DLP]]: Out-of-bounds memory access during spectator [[Download_Play|data-frame]] checksum calculation<br />
| DLP doesn't validate the frame_size when receiving spectator data-frames at all, unlike non-spectator data-frames. The actual spectator data-frame parsing code doesn't use that field either. However, the data-frame checksum calculation code called during checksum verification does use the frame_size for loading the size of the framebuf.<br />
<br />
Hence, using a large frame_size like 0xFFFF will result in the checksum calculation code reading data out-of-bounds. This isn't really useful, you could trigger a remote local-WLAN DLP-sysmodule crash while a 3DS system is scanning for DLP networks(due to accessing unmapped memory), but that's about all(trying to infoleak with this likely isn't useful either).<br />
| DLP-sysmodule crash, handled by dlplay system-application by a "connection interrupted" error eventually then a fatal-error via ErrDisp.<br />
| None<br />
| [[10.0.0-27|10.0.0-X]]<br />
| April 8, 2016 (Tested on the 10th)<br />
| April 10, 2016<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[DLP_Services|DLP]]: Out-of-bounds output data writing during spectator sysupdate titlelist [[Download_Play|data-frame]] handling<br />
| The total_entries and out_entryindex fields for the titlelist DLP spectator data-frames are not validated. This is parsed during DLP network scanning. Hence, the specified titlelist data can be written out-of-bounds using the specified out_entryindex and total_entries. A crash will occur while reading the input data-frame titlelist if total_entries is larger than 0x27A, due to accessing unmapped memory.<br />
<br />
There's not much non-zero data to overwrite following the output buffer(located in sharedmem), any ptrs are located in sharedmem. Overwriting certain ptr(s) are only known to cause a crash when attempting to use the DLP-client shutdown service-command.<br />
<br />
There's no known way to exploit the above crash, since the linked-list code involves writes zeros(with a controlled start ptr).<br />
| <br />
| None<br />
| [[10.0.0-27|10.0.0-X]]<br />
| April 8-9, 2016<br />
| April 10, 2016<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[IR_Services|IR]]: Stack buffer overflow with custom hardware<br />
| Originally IR sysmodule used the read value from the I2C-IR registers TXLVL and RXLVL without validating them at all. See [[10.6.0-31|here]] for the fix. This is the size used for reading the data-recv FIFO, etc. The output buffer for reading is located on the stack.<br />
<br />
This should be exploitable if one could successfully setup the custom hardware for this and if the entire intended sizes actually get read from I2C.<br />
| ROP under IR sysmodule.<br />
| [[10.6.0-31|10.6.0-31]]<br />
| <br />
| February 23, 2016 (Unknown if it was noticed before then)<br />
| February 23, 2016<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[HTTP_Services|HTTP]]: Using CTRSDK heap with sharedmem from the user-process.<br />
| The data from httpcAddPostDataAscii and other commands is stored under a CTRSDK heap. That heap is the sharedmem specified by the user-process via the HTTPC Initialize command.<br />
Normally this sharedmem isn't accessible to the user-process once the sysmodule maps it, hence using it is supposed to be "safe".<br />
<br />
This isn't the case due to gspwn however. Since CTRSDK heap code is so insecure in general, one can use gspwn to locate the HTTPC sharedmem + read/write it, then trigger a mem-write under the sysmodule. This can then be used to get ROP going under HTTP-sysmodule.<br />
<br />
This is exploited by [https://github.com/yellows8/ctr-httpwn/ctr-httpwn ctr-httpwn].<br />
| ROP under HTTP sysmdule.<br />
| [[11.4.0-37|11.4.0-X]]<br />
| [[9.6.0-24|9.6.0-X]] (Latest sysmodule version as of [[10.7.0-32|10.7.0-32]])<br />
| Late 2015<br />
| March 22, 2016<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[NIM_Services|NIM]]: Downloading old title-versions from eShop<br />
| Multiple NIM service commands(such as [[NIMS:StartDownload]]) use a title-version value specified by the user-process, NIM does not validate that this input version matches the latest version available via SOAP. Therefore, when combined with AM(PXI) [[#Process9|title-downgrading]] via deleting the target eShop title with System Settings Data Management(if the title was already installed), this allows downloading+installing any title-version from eShop ''if'' it's still available from CDN.<br />
The easiest way to exploit this is to just patch the eShop system-application code using these NIM commands(ideally the code which loads the title-version).<br />
<br />
Originally this was tested with a debugging-system via modded-FIRM, eventually smea implemented it in HANS for the 32c3 release.<br />
| Downloading old title-versions from eShop<br />
| None<br />
| [[10.0.0-27|10.0.0-X]]<br />
| October 24, 2015 (Unknown when exactly the first eShop title downgrade was actually tested, maybe November)<br />
| January 7, 2016 (Same day Ironfall v1.0 was removed from CDN via the main-CXI files)<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[SPI_Services|SPI]] service out-of-bounds write<br />
| cmd1 has out-of-bounds write allowing overwrite of some static variables in .data.<br />
| <br />
| None<br />
| [[9.5.0-22]]<br />
| March 2015<br />
| <br />
| [[User:Plutooo|plutoo]]<br />
|-<br />
| [[NFC_Services|NFC]] module service command buf-overflows<br />
| NFC module copies data with certain commands, from command input buffers to stack without checking the size. These commands include the following, it's unknown if there's more commands with similar issues: "nfc:dev" <0x000C....> and "nfc:s" <0x0037....>.<br />
Since both of these commands are stubbed in the Old3DS NFC module from the very first version(those just return an error), these issues only affect the New3DS NFC module.<br />
<br />
There's no known retail titles which have access to either of these services.<br />
| ROP under NFC module.<br />
| New3DS: None<br />
| New3DS: [[9.5.0-22]]<br />
| December 2014?<br />
| <br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[News_Services|NEWSS]] service command notificationID validation failure<br />
| This module does not validate the input notificationID for <nowiki>"news:s"</nowiki> service commands. This is an out-of-bounds array index bug. For example, [[NEWSS:SetNotificationHeader]] could be used to exploit news module: this copies the input data(size is properly checked) to: out = newsdb_savedata+0x10 + (someu32array[notificationID]*0x70).<br />
| ROP under news module.<br />
| None<br />
| [[9.7.0-25|9.7.0-X]]<br />
| December 2014<br />
| <br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[NWMUDS:DecryptBeaconData]] heap buffer overflow<br />
| input_size = 0x1E * <value the u8 from input_[[NWM_Services|networkstruct]]+0x1D>. Then input_tag0 is copied to a heap buffer. When input_size is larger than 0xFA-bytes, it will then copy input_tag1 to <end_address_of_previous_outbuf>, with size=input_size-0xFA.<br />
<br />
This can be triggered by either using this command directly, or by boadcasting a wifi beacon which triggers it while a 3DS system running the target process is in range, when the process is scanning for hosts to connect to. Processes will only pass tag data to this command when the wlancommID and other thing(s) match the values for the process.<br />
<br />
There's no known way to actually exploit this for getting ROP under NWM-module, at the time of originally adding this to the wiki. This is because the data which gets copied out-of-bounds *and* actually causes crash(es), can't be controlled it seems(with just broadcasting a beacon at least). It's unknown whether this could be exploited from just using NWMUDS service-cmd(s) directly.<br />
| Without any actual way to exploit this: NWM-module DoS, resulting in process termination(process crash). This breaks *everything* involving wifi comms, a reboot is required to recover from this.<br />
| None<br />
| [[9.0.0-20]]<br />
| ~September 23, 2014(see the [[NWMUDS:DecryptBeaconData]] page history)<br />
| August 3, 2015<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[HID_Services|HID]] module shared-mem<br />
| HID module does not validate the index values in [[HID_Shared_Memory|sharedmem]](just changes index to 0 when index == maxval when updating), therefore large values will result in HID module writing HID data to arbitrary addresses.<br />
| ROP under HID module, but this is *very* unlikely to be exploitable since the data written is HID data.<br />
| None<br />
| [[9.3.0-21]]<br />
| 2014?<br />
| <br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| gspwn<br />
| GSP module does not validate addresses given to the GPU. This allows a user-mode application/applet to read/write to a large part of physical FCRAM using GPU DMA. From this, you can overwrite the .text segment of the application you're running under, and gain real code-execution from a ROP-chain. Normally applets' .text([[Home Menu]], [[Internet Browser]], etc) is located beyond the area accessible by the GPU, except for [[RO_Services|CROs]] used by applets([[Internet Browser]] for example).<br />
<br />
FCRAM is gpu-accessible up to physaddr 0x26800000 on Old3DS, and 0x2D800000 on New3DS. This is BASE_memregion_start(aka SYSTEM_memregion_end)-0x400000 (0x800000 with New3DS) with the default memory-layout on Old3DS/New3DS. With [[11.3.0-36|11.3.0-X]] the cutoff now varies due to the new [[SVC]] 0x59. The New3DS "normal"(non-APPLICATION) cutoff was changed to 0x2D000000 due to the new [[SVC]] 0x59.<br />
| User-mode code execution.<br />
| None<br />
| [[9.6.0-24|9.6.0-X]]<br />
| Early 2014<br />
| <br />
| smea, [[User:Yellows8|Yellows8]]/others before then<br />
|-<br />
| rohax<br />
| Using gspwn, it is possible to overwrite a loaded [[CRO0]]/[[CRR0]] after its RSA-signature has been validated. Badly validated [[CRO0]] header leads to arbitrary read/write of memory in the ro-process. This gives code-execution in the ro module, who has access to [[SVC|syscalls]] 0x70-0x72, 0x7D.<br />
<br />
This was fixed after [[ninjhax]] release by adding checks on [[CRO0]]-based pointers before writing to them.<br />
| Memory-mapping syscalls.<br />
| [[9.3.0-21]]<br />
| [[9.4.0-21]]<br />
| <br />
| <br />
| smea, [[User:Plutooo|plutoo]] joint effort<br />
|-<br />
| Region free<br />
| Only [[Home Menu]] itself checks gamecards' region when launching them. Therefore, any application launch that is done directly with [[NS]] without signaling Home Menu to launch the app, will result in region checks being bypassed.<br />
This essentially means launching the gamecard with the [[NS_and_APT_Services|"ns:s"]] service. The main way to exploit this is to trigger a FIRM launch with an application specified, either with a normal FIRM launch or a hardware [[NSS:RebootSystem|reboot]].<br />
| Launching gamecards from any region + bypassing Home Menu gamecard-sysupdate installation<br />
| None<br />
| Last tested with [[10.1.0-27|10.1.0-X]].<br />
| June(?) 2014<br />
| <br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[NWM_Services|NWM]] service-cmd state null-ptr deref<br />
| The NWMUDS service command code loads a ptr from .data, adds an offset to that, then passes that as the state address for the actual command-handler function. The value of the ptr loaded from .data is not checked, therefore this will cause crashes due to that being 0x0 when NWMUDS was not properly initialized.<br />
It's unknown whether any NWM services besides NWMUDS have this issue.<br />
| This is rather useless since it's only a crash caused by a state ptr based at 0x0.<br />
| None<br />
| [[9.0.0-20]]<br />
| 2013?<br />
| <br />
| [[User:Yellows8|Yellows8]]<br />
|}<br />
<br />
=== General/CTRSDK ===<br />
{| class="wikitable" border="1"<br />
|-<br />
! Summary<br />
! Description<br />
! Successful exploitation result<br />
! Fixed in version<br />
! Last version this flaw was checked for<br />
! Timeframe this was discovered<br />
! Discovered by<br />
|-<br />
| [[NWM_Services|UDS]] beacon additional-data buffer overflow<br />
| Originally CTRSDK did not validate the UDS additional-data size before using that size to copy the additional-data to a [[NWM_Services|networkstruct]]. This was eventually fixed.<br />
This was discovered while doing code RE with an old dlp-module version. It's unknown in what specific CTRSDK version this was fixed, or even what system-version updated titles with a fixed version.<br />
<br />
It's unknown if there's any titles using a vulnerable CTRSDK version which are also exploitable with this(dlp module can't be exploited with this).<br />
<br />
The maximum number of bytes that can be written beyond the end of the outbuf is 0x37-bytes, with additionaldata_size=0xFF.<br />
| Perhaps ROP, very difficult if possible with anything at all<br />
| ?<br />
| <br />
| September(?) 2014<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| CTPK buffer overflow<br />
| At offset 0x20 in CTPK is an array for each texture, each entry is 0x20-bytes. This contains a wordindex(entry+0x18) for some srcdata relative to CTPK+0, and an u8 wordsize(entry+0x14) for this data. The CTRSDK function handling this doesn't validate the size, when copying srcdata using this size to the output buffer. Applications usually have the output buffer on the stack, hence stack buffer overflow.<br />
<br />
While CTPK(*.ctpk) are normally only loaded from RomFS, some application(s) load from elsewhere too.<br />
| ROP under the target application.<br />
| None?<br />
| "[SDK+NINTENDO:CTR_SDK-11_4_0_200_none]"<br />
| November 14, 2016<br />
| [[User:Yellows8|Yellows8]]<br />
|}</div>Myriahttps://www.3dbrew.org/w/index.php?title=3DS_System_Flaws&diff=207863DS System Flaws2018-08-01T04:41:48Z<p>Myria: /* Kernel9 */ wording clarifications</p>
<hr />
<div>Exploits are used to execute unofficial code (homebrew) on the Nintendo 3DS. This page is a list of publicly known system flaws, for userland applications/applets flaws see [[3DS_Userland_Flaws|here]].<br />
<br />
=Stale / Rejected Efforts=<br />
* Neimod has been working on a RAM dumping setup for a little while now. He's de-soldered the 3DS's RAM chip and hooked it and the RAM pinouts on the 3DS' PCB up to a custom RAM dumping setup. A while ago he published photos showing his setup to be working quite well, with the 3DS successfully booting up. However, his flickr stream is now private along with most of his work.<br />
<br />
* Someone (who will remain unnamed) has released CFW and CIA installers, all of which is copied from the work of others, or copyrighted material.<br />
<br />
==Tips and info==<br />
The 3DS uses the XN feature of the ARM11 processor. There's no official way from applications to enable executable permission for memory containing arbitrary unsigned code(there's a [[SVC]] for this, but only [[RO_Services|RO-module]] has access to it). A usable userland exploit would still be useful: you could only do return-oriented-programming with it initially. From ROP one could then exploit system flaw(s), see below.<br />
<br />
SD card [[extdata]] and SD savegames can be attacked, for consoles where the console-unique [[Nand/private/movable.sed|movable.sed]] was dumped(accessing SD data is far easier by running code on the target 3DS however).<br />
<br />
=System flaws=<br />
== Hardware ==<br />
{| class="wikitable" border="1"<br />
! Summary<br />
! Description<br />
! Fixed with hardware model/revision<br />
! Newest hardware model/revision this flaw was checked for<br />
! Timeframe this was discovered<br />
! Discovered by<br />
|-<br />
| ARM9/ARM11 bootrom vectors point at uninitialized RAM<br />
| ARM9's and ARM11's exception vectors are hardcoded to point at the CPU's internal memory (0x08000000 region for ARM9, AXIWRAM for ARM11). While the bootrom does set them up to point to an endless loop at some point during boot, it does not do so immediately. As such, a carefully-timed fault injection (via hardware) to trigger an exception (such as an invalid instruction) will cause execution to fall into ARM9 RAM. <br />
Since RAM isn't cleared on boot (see below), one can immediately start execution of their own code here to dump bootrom, OTP, etc.<br />
The ARM9 bootrom does the following at reset: reset vector branches to another instruction, then branches to bootrom+0x8000. Hence, there's no way to know for certain when exactly the ARM9 exception-vector data stored in memory gets initialized.<br />
<br />
This requires *very* *precise* timing for triggering the hardware fault.<br />
<br />
It has been exploited by derrek to dump the ARM9 bootrom as of Summer 2015.<br />
| None: all available 3DS models at the time of writing have the exact same ARM9/ARM11 bootrom for the unprotected areas.<br />
| New3DS<br />
| End of February 2014<br />
| [[User:Derrek|derrek]], WulfyStylez (May 2015) independently<br />
|-<br />
| Missing AES key clearing<br />
| The hardware AES engine does not clear keys when doing a hard reset/reboot.<br />
| None<br />
| New3DS<br />
| August 2014<br />
| Mathieulh/Others<br />
|-<br />
| No RAM clearing on reboots<br />
| On an MCU-triggered reboot all RAM including FCRAM/ARM9 memory/AXIWRAM/VRAM keeps its contents.<br />
| None<br />
| New3DS<br />
| March 2014<br />
| [[User:Derrek|derrek]]<br />
|-<br />
| 32bits of actual console-unique TWLNAND keydata<br />
| On retail the 8-bytes at ARM9 address [[Memory_layout|0x01FFB808]] are XORed with hard-coded data, to generate the TWL console-unique keys, including TWLNAND. On Old3DS the high u32 is always 0x0, while on New3DS that u32 is always 0x2. On top of this, the lower u32's highest bit is always ORed. only 31 bits of the TWL console-unique keydata / TWL consoleID are actually console-unique.<br />
This allows one to easily bruteforce the TWL console-unique keydata with *just* data from TWLNAND. On DSi the actual console-unique data for key generation is 8-bytes(all bytes actually set).<br />
| None<br />
| New3DS<br />
| 2012?<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| DSi / 3DS-TWL key-generator<br />
| After using the key generator to generate the normal-key, you could overwrite parts of the normal-key with your own data and then recover the key-generator output by comparing the new crypto output with the original crypto output. From the normal-key outputs, you could deduce the TWL key-generator function.<br />
This applies to the keyX/keyY too.<br />
<br />
This attack does not work for the 3DS key-generator because keyslots 0-3 are only for TWL keys.<br />
| None<br />
| New3DS<br />
| 2011<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| 3DS key-generator<br />
| The algorithm for generating the normal-keys for keyslots is cryptographically weak. As a result, it is easily susceptible to differential cryptanalysis if the normal-key corresponding to any scrambler-generated keyslot is discovered.<br />
<br />
Several such pairs of matching normal-keys and KeyY values were found, leading to deducing the key-generator function.<br />
| None<br />
| New3DS<br />
| February 2015<br />
| [[User:Yellows8|Yellows8]], [[User:Plutooo|plutoo]]<br />
|-<br />
| RSA keyslots don't clear exponent when setting modulus<br />
| The [[RSA_Registers|RSA keyslots]] are set by boot ROM to have four private RSA keys. The exponent value in the RSA registers is write-only and not readable.<br />
<br />
However, when setting a keyslot's modulus, the RSA hardware leaves the exponent alone. This allows retrieving the exponent by doing a discrete logarithm of the output.<br />
<br />
By setting the modulus to a prime number whose modular multiplicative order is "smooth" (that is, p-1 is divisible by only small prime numbers), discrete logarithms can be calculated quickly using the [[wikipedia:Pohlig-Hellman algorithm|Pohlig-Hellman algorithm]]. If the prime chosen is greater than the modulus, but the same bit size, the discrete logarithm is the private exponent.<br />
<br />
This exploit's usefulness is limited: RSA keyslot 0 is only used in current firmware for deriving the 6.x save and 7.x NCCH keys, which were already known, and the other three keyslots are entirely unused. Additionally, with a boot ROM dump, this exploit is moot; these private keys are located in the protected ARM9 boot ROM.<br />
| None<br />
| New3DS<br />
| March 2016<br />
| [[User:Myria|Myria]]<br />
|-<br />
| [[CONFIG11_Registers#CFG11_GPUPROT|CFG11_GPUPROT]] allowing acccess to AXIWRAM/FCRAM-BASE-memregion<br />
| [[CONFIG11_Registers#CFG11_GPUPROT|CFG11_GPUPROT]] can be configured by anything with access to it to allow the GPU to access the entire AXIWRAM+FCRAM. For example, this is an issue for any sysmodule that gets exploited and has access to this register memory-page(include one that's listed below).<br />
<br />
See also "kernelhax via gspwn" below.<br />
| None<br />
| New3DS<br />
| February 7, 2017<br />
| [[User:Yellows8|Yellows8]]<br />
|}<br />
<br />
== Boot ROM ==<br />
{| class="wikitable" border="1"<br />
! Summary<br />
! Description<br />
! Fixed with hardware model/revision<br />
! Newest hardware model/revision this flaw was checked for<br />
! Timeframe this was discovered<br />
! Discovered by<br />
|-<br />
| FIRM partitions known-plaintext<br />
| The [[Flash_Filesystem|FIRM partitions]] are encrypted with AES-CTR without a MAC. Since this works by XOR'ing data with a static (per-console in this case) keystream, one can deduce the keystream of a portion of each FIRM partition if they have the actual FIRM binary stored in it.<br />
<br />
This can be paired with many exploits. For example, it allows minor FIRM downgrades (i.e. 10.4 to 9.6 or 9.5 to 9.4, but not 9.6 to 9.5).<br />
However it is most commonly used to install arbitrary FIRMs (usually boot9strap), thanks to sighax.<br />
<br />
This can be somewhat addressed by having a FIRM header skip over previously used section offsets, but this would just air-gap newer FIRMs without fixing the core bug. This can also only be done a limited number of times due to the size of FIRM versus the size of the partitions.<br />
| None<br />
| New3DS<br />
| <br />
| Everyone<br />
|-<br />
| Boot9 AES keyinit function issues<br />
| [[Bootloader|Boot9]] seems to have two bugs in the AES key-init function, see [[AES_Registers#AES_key-init|here]].<br />
| None<br />
| BootROM issue.<br />
| 2015<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| sighax: Boot9 improper PKCS #1 v1.5 signature validation<br />
| The [[Flash_Filesystem|FIRM partitions]] are signed with RSA-2048 using SHA-256 and PKCS #1 v1.5 padding. Boot9, however, does improper validation of the padding in three ways:<br />
# Boot9 permits block type 02, meant for encrypted messages, to be used for signatures. Only 01, for signatures, should have been permitted. As a result, a signature block is not required to have a long string of FF bytes as padding, but rather any random values suffice. While correct for encryption, this severely lessens security of signatures.<br />
# Boot9 does not require that the length of the padding fill out the signature block completely. As a result, there is considerable freedom in the layout of a signature.<br />
# Boot9 fails to do bounds checking in its parsing of the DER-encoded hash algorithm type and hash value; the length values given in DER are permitted to point outside the signature block.<br />
Flaw 3 allows the DER encoding to be such that boot9 believes that the signature's hash value is outside the range of the block itself, somewhere on the stack. This can be pointed at the correct hash value it computes. Boot9 then memcmp's the calculated hash against itself, and thinks that the hash is valid.<br />
<br />
When all three flaws are combined, a brute force in a reasonable amount of time can find a signature that passes all checks.<br />
| None<br />
| New3DS<br />
| July 2015<br />
| [[User:Derrek|derrek]]<br />
|-<br />
| Boot9 FIRM loading doesn't blacklist memory-mapped I/O<br />
| [[Bootloader|Boot9]]'s FIRM loading blacklists Boot9 data regions, but forgets to do other important regions, including Memory-mapped I/O. Combined with sighax, by loading a malicious FIRM section to MMIO, one can get Boot9/Boot11 code execution. <br />
| None<br />
| New3DS<br />
| 2015(?)<br />
| [[User:Derrek|derrek]] (2015?), [[User:Normmatt|Normmatt]] and [[User:SciresM|SciresM]] independently (January 2017).<br />
|-<br />
| "superhax": Boot9 FIRM loading blacklist check is flawed<br />
| Boot9 only makes sure the '''start''' and '''end''' address of each section is not covered by a blacklisted region. Thus, it is possible to overwrite blacklisted regions (e.g. ARM9 Exception Vectors) by choosing a FIRM section range that encloses an entire blacklisted region. The vulnerable code looks like this: if(blRegions[i].start <= sectionStart && blRegions[i].end > sectionStart <nowiki>||</nowiki> blRegions[i].start <= sectionEnd && blRegions[i].end > sectionEnd) return false; // failure<br />
| None<br />
| New3DS<br />
| August 2015<br />
| [[User:Plutoo|plutoo]], [[User:Yellows8|yellows8]]<br />
|}<br />
<br />
== ARM9 software ==<br />
<br />
=== arm9loader ===<br />
{| class="wikitable" border="1"<br />
|-<br />
! Summary<br />
! Description<br />
! Successful exploitation result<br />
! Fixed in [[FIRM]] system version<br />
! Last [[FIRM]] system version this flaw was checked for<br />
! Timeframe this was discovered<br />
! Public disclosure timeframe<br />
! Discovered by<br />
|-<br />
| Generating the keysector console-unique keys with ITCM+Boot9<br />
| [[Bootloader|Boot9]] decrypts the 0x100-byte [[OTP_Registers|OTP]] using AES-CBC with keydata stored in Boot9. If hash verification is successful, the plaintext of the first 0x90-bytes are copied into [[Memory_layout|ITCM]]. This is the ''exact'' ''same'' region hashed by arm9loader when generating the console-unique keys for decrypting the keysector, except arm9loader uses the raw encrypted OTP.<br />
<br />
Therefore, with the OTP keydata+IV from Boot9 you can: encrypt the 0x90-bytes from ITCM, then hash the output to get the console-unique keys for the system's keysector. This can even be done for Old3DS which doesn't have the arm9loader keysector officially.<br />
<br />
It's unknown why arm9loader only used the first 0x90-bytes of OTP. Using more data from OTP would've prevented this. Fixing this would require doing exactly that, but that would also mean updating the NAND keysector(which is dangerous).<br />
| See description.<br />
| None<br />
| <br />
| 2015<br />
| January 6, 2017<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| Rearrangable keys in the NAND keystore<br />
| Due to the keystore being encrypted with AES-ECB, one can rearrange blocks and still have the NAND keystore decrypt in a deterministic way. <br />
<br />
Using 10.0 FIRM it is possible to rearrange keys such that ARM9 memory is executed. As such using existing ARM9 execution 10.0 FIRM can be written to NAND and a payload written to memory, with the payload to be executed post-K9L using an MCU reboot.<br />
| arm9loaderhax given existing ARM9 code execution<br />
| None<br />
| [[11.3.0-36|11.3.0-X]]<br />
| Early 2016<br />
| 27 September 2016<br />
| Myria, [[User:Dark samus|dark_samus]]; mathieulh (independently); [[User:Plutooo|plutoo]] (independently) + others<br />
|-<br />
| Uncleared OTP hash keydata in console-unique 0x11 key-generation<br />
| Kernel9Loader does not clear the [[SHA_Registers#SHA_HASH|SHA_HASH register]] after use. As a result, the data stored here as K9L hands over to Kernel9 is the hash of [[OTP_Registers|OTP data]] used to seed the [[FIRM#New_3DS_FIRM|console-unique NAND keystore decryption key]] set on keyslot 0x11.<br />
<br />
Retrieving this keydata and the [[Flash_Filesystem#0x12C00|NAND keystore]] of the same device allows calculating the decrypted New3DS NAND keystore (non-unique, common to all New3DS units), which contains AES normal keys, also set on keyslot 0x11, which are then used to derive all current [[AES_Registers#Keyslots|New3DS-only AES keyXs]] including the newer batch introduced in [[9.6.0-24#arm9loader|9.6.0-X]]. From there, it is trivial to perform the same key derivation in order to initialize those keys on any system version, and even on Old3DS.<br />
<br />
This can be performed by exploiting the "arm9loaderhax" vulnerability to obtain post-K9L code execution after an MCU reboot (the bootrom section-loading fail is not relevant here, this attack was performed without OTP data by brute-forcing keys), and using this to dump the SHA_HASH register. This attack works on any FIRM version shipping a vulnerable version of K9L, whereas OTP dumping required a boot of <[[3.0.0-6|3.0.0-X]].<br />
<br />
This attack results in obtaining the entire (0x200-bytes) NAND keystore - it was confirmed at a later date that this keystore is encrypted with the same key (by comparing the decrypted data from multiple units), and therefore using another key in this store will not remedy the issue as all keys are known (i.e. later, unused keys decrypt to the same 0x200-bytes constant with the same OTP hash). Later keys could have been encrypted differently but this is not the case. As a result of this, it is not possible for Nintendo to use K9L again in its current format for its intended purpose, though this was not news from the moment people dumped a New3DS OTP.<br />
| Derivation of all New3DS keys generated via the NAND keystore (0x1B "Secure4" etc.)<br />
| None<br />
| [[11.3.0-36|11.3.0-X]]<br />
| ~April 2015, implemented in May 2015<br />
| 13 January 2016<br />
| [[User:WulfyStylez|WulfyStylez]], [[User:Dazzozo|Dazzozo]], [[User:Shinyquagsire23|shinyquagsire23]] (complimentary + implemented), [[User:Plutooo|plutoo]], Normmatt (discovered independently)<br />
|-<br />
| enhanced-arm9loaderhax<br />
| See the 32c3 3ds talk.<br />
Since this is a combination of a trick with the arm9-bootrom + arm9loaderhax, and since you have to manually write FIRM to the firm0/firm1 NAND partitions, this can't be completely fixed. Any system with existing ARM9 code execution and an OTP/OTP hash dump can exploit this. Additionally, by using the FIRM partition known-plaintext bug and bruteforcing the second entry in the keystore, this can currently be exploited on all New3DS systems without any other prerequisite hacks.<br />
| arm9loaderhax which automatically occurs at hard-boot.<br />
| See arm9loaderhax / description.<br />
| See arm9loaderhax / description.<br />
| Theorized around mid July, 2015. Later implemented+tested by [[User:Plutooo|plutoo]] and [[User:Derrek|derrek]].<br />
| 32c3 3ds talk (December 27, 2015)<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| Missing verification-block for the 9.6 keys (arm9loaderhax)<br />
| Starting with [[9.6.0-24|9.6.0-X]] a new set of NAND-based keys were introduced. However, no verification block was added to verify that the new key read from NAND is correct. This was technically an issue from [[9.5.0-22|9.5.0-X]] with the original sector+0 keydata, however the below is only possible with [[9.6.0-24|9.6.0-X]] since keyslots 0x15 and 0x16 are generated from different 0x11 keyXs.<br />
<br />
Writing an incorrect key to NAND will cause arm9loader to decrypt the ARM9 kernel as garbage and then jump to it.<br />
<br />
This allows an hardware-based attack where you can boot into an older exploited firmware, fill all memory with NOP sleds/jump-instructions, and then reboot into executing garbage. By automating this process with various input keydata, eventually you'll find some garbage that jumps to your code.<br />
<br />
This gives very early ARM9 code execution (pre-ARM9 kernel). As such, it is possible to dump RSA keyslots with this and calculate the 6.x [[Savegames#6.0.0-11_Savegame_keyY|save]], and 7.x [[NCCH]] keys. This cannot be used to recover keys initialized by arm9loader itself. This is due to it wiping the area used for its stack during NAND sector decryption and keyslot init. <br />
<br />
Due to FIRMs on both Old and New 3DS using the same RSA data, this can be exploited on Old3DS as well, but only if one already has the actual plaintext normalkey from New3DS NAND sector 0x96 offset-0 and has dumped the OTP area of the Old3DS.<br />
| Recovery of 6.x [[Savegames#6.0.0-11_Savegame_keyY|save key]]/7.x [[NCCH]] key, access to uncleared OTP hash keydata<br />
| None<br />
| [[11.3.0-36|11.3.0-X]]<br />
| March, 2015<br />
| <br />
| [[User:Plutooo|plutoo]]<br />
|-<br />
| Uncleared New3DS keyslot 0x11<br />
| Originally the New3DS [[FIRM]] arm9bin loader only cleared keyslot 0x11 when it gets executed at firmlaunch. This was fixed with [[9.5.0-22|9.5.0-X]] by completely clearing keyslot 0x11 immediately after the loader finishes using keyslot 0x11.<br />
This means that any ARM9 code that can execute before the loader clears the keyslot at firmlaunch(including firmlaunch-hax) can get access to the uncleared keyslot 0x11, which then allows one to generate all <=v9.5 New3DS keyXs which are generated by keyslot 0x11.<br />
<br />
Therefore, to completely fix this the loader would have to generate more keys using different keyslot 0x11 keydata. This was done with [[9.6.0-24|9.6.0-X]].<br />
| New3DS keyXs generation<br />
| Mostly fixed with [[9.5.0-22|9.5.0-X]], completely fixed with new keys with [[9.6.0-24|9.6.0-X]].<br />
| <br />
| February 3, 2015 (one day after [[9.5.0-22|9.5.0-X]] release)<br />
| <br />
| [[User:Yellows8|Yellows8]]<br />
|}<br />
<br />
=== Process9 ===<br />
{| class="wikitable" border="1"<br />
|-<br />
! Summary<br />
! Description<br />
! Successful exploitation result<br />
! Fixed in [[FIRM]] system version<br />
! Last [[FIRM]] system version this flaw was checked for<br />
! Timeframe this was discovered<br />
! Public disclosure timeframe<br />
! Discovered by<br />
|-<br />
| Leak of normal-key matching a key-scrambler key<br />
| New 3DS firmware versions [[8.1.0-0 New3DS|8.1.0]] through [[9.2.0-20|9.2.0]] set the encryption key for [[Amiibo]] data using a hardcoded normal-key in Process9. In firmware [[9.3.0-21|9.3.0]], Nintendo "fixed" this by using the key scrambler instead, by calculating the keyY value for keyslot 0x39 that results in the same normal-key, then hardcoding that keyY into Process9.<br />
<br />
Nintendo's fix is actually the problem: Nintendo revealed the normal-key matching an unknown keyX and a known keyY. Combined with the key scrambler using an insecure scrambling algorithm (see "Hardware" above), the key scrambler function could be deduced.<br />
| Deducing the keyX for keyslot 0x39 and the key scrambler algorithm<br />
| New 3DS [[9.3.0-21|9.3.0-X]], sort of<br />
| [[10.0.0-27|10.0.0-X]]<br />
| Sometime in 2015 after the hardware key-generator was broken.<br />
| 32c3 3ds talk (December 27, 2015)<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| Leak of normal-key matching a key-generator key<br />
| During the 3DS' development (June/July 2010) Nintendo added support installing encrypted content ([[CIA]]). Common-key index1 was intended to be a [[AES|hardware generated key]]. However while they added code to generate the key in hardware, they forgot to remove the normal-key for index1 (used elsewhere, likely old debug code). Nintendo later removed the normal key sometime before the first non-prototype firmware release.<br />
<br />
<br />
Knowing the keyY and the normal-key for common-key index1, the devkit key-generator algorithm can be deduced (see "Hardware" above). Additionally the remaining devkit common-keys can be generated once the common-key keyX is recovered.<br />
<br />
Note the devkit key-generator was discovered to be the same as the retail key-generator.<br />
| Deducing the keyX for keyslot 0x3D and hardware key-generator algorithm. Generate remaining devkit common-keys.<br />
| pre-[[1.0.0-0|1.0.0-X]]<br />
| <br />
| Shortly after the key-generator was revealed to be flawed at the 32c3 3ds talk<br />
| January 20, 2016<br />
| [[User:Jakcron|jakcron]]<br />
|-<br />
| Factory firmware is vulnerable to sighax<br />
| During the 3DS's development, presumably boot9 was written (including the sighax) vulnerability. This vulnerability is also present in factory firmware (and earlier, including 0.11). This was fixed in version 1.0.0-0.<br />
| Deducing the mechanics of the sighax vulnerability in boot9 without having boot9 prot. Arm9 code execution on factory/earlier firmware.<br />
| [[1.0.0-0|1.0.0-X]]<br />
| [[1.0.0-0|1.0.0-X]]<br />
| May 9, 2017<br />
| May 19, 2017<br />
| [[User:SciresM|SciresM]], [[User:Myria|Myria]]<br />
|-<br />
| safefirmhax<br />
| SAFE_MODE_FIRM is almost never updated(even when NATIVE_FIRM is updated for vuln fixes), this can be noticed by ''just'' checking 3dbrew/ninupdates title-listings.<br />
<br />
The fix for 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 <=> Kernel11 sync, PXI sync and then repeat the original attack on SAFE_FIRM instead.<br />
| ARM9 code execution<br />
| [[11.3.0-36|11.3.0-X]]<br />
| <br />
| 2012-2013?<br />
| Wiki: January 2, 2017<br />
| Everyone<br />
|-<br />
| safefirmhax 1.1<br />
| Nintendo's original safefirmhax fix was flawed -- they added a global boolean that got set to true whenever a non-sysmodule title got launched (except for a hardcoded repair title id), and panic()'d if that boolean was true to prevent launching safefirm after hax was active. However, because the boolean was initially false after firmlaunch -- With ARM11-kernel execution, one could FIRM-launch into NATIVE_FIRM, and then immediately FIRM-launch again into SAFE_FIRM early in NATIVE_FIRM boot before the boolean got set to true to repeat the safehax attack.<br />
<br />
This was fixed by adding additional CFG9_BOOTENV checks to firmlaunch code in 11.4.<br />
| ARM9 code execution<br />
| [[11.4.0-37|11.4.0-X]]<br />
| <br />
| safefirmhax fix<br />
| Wiki: April 10, 2017<br />
| Everyone<br />
|-<br />
| ntrcardhax<br />
| When reading the banner of a NTR title, Process9 relies on a hardware register to know when the banner was fully read.<br />
However that register is shared between the ARM9 and the ARM11.<br />
An attacker with k11 control can so make Process9 believe the banner continues forever and so trigger a buffer overflow.<br />
With a custom banner for a NTR flashcart, this leads to code execution in Process9.<br />
<br />
This was fixed by adding bound checks on the read data.<br />
| ARM9 code execution<br />
| [[10.4.0-29|10.4.0-X]]<br />
| <br />
| March 2015<br />
| 32c3 3ds talk (December 27, 2015)<br />
| [[User:Plutooo|plutoo]]<br />
|-<br />
| Title downgrading via [[Application_Manager_Services|AM]]([[Application_Manager_Services_PXI|PXI]])<br />
| When a title is *already* installed, Process9 will compare the installed title-version with the title-version being installed. When the one being installed is older, Process9 would return an error.<br />
<br />
However, this can be bypassed by just deleting the title first via the service command(s) for that: with the title removed from the [[Title_Database]], Process9 can't compare the input title-version with anything. Hence, titles can be downgraded this way.<br />
<br />
[[11.0.0-33|11.0.0-X]] fixed this for key system titles (MSET, Home Menu, spider, ErrDisp, SKATER, NATIVE_FIRM, and every retail system module), by checking the version of the title to install against a hard-coded list of (titleID, minimumVersionRequired) pairs.<br />
| Bypassing title version check at installation, which then allows downgrading any title.<br />
| [[11.0.0-33|11.0.0-X]], for key system titles.<br />
| NATIVE_FIRM / AM-sysmodule [[11.0.0-33|11.0.0-X]]<br />
| ?<br />
| <br />
| ?<br />
|-<br />
| FAT FS code null-deref<br />
| When FSFile:Read is used with a file which is corrupted on a FAT filesystem(in particular SD), Process9 can crash. This particular crash is caused by a function returning NULL instead of an actual ptr due to an error. The caller of that function doesn't check for NULL which then triggers a read based at NULL.<br />
<br />
Sample "fsck.vfat -n -v -V <fat image backup>" output for the above crash:<br />
<br />
<pre>...<br />
Starting check/repair pass.<br />
<FilePath0> and<br />
<FilePath1><br />
share clusters.<br />
Truncating second to 3375104 bytes.<br />
<FilePath1><br />
File size is 2787392 bytes, cluster chain length is 16384 bytes.<br />
Truncating file to 16384 bytes.<br />
Checking for unused clusters.<br />
Reclaimed 1 unused cluster (16384 bytes).<br />
Checking free cluster summary.<br />
Free cluster summary wrong (1404490 vs. really 1404491)<br />
Auto-correcting.<br />
Starting verification pass.<br />
Checking for unused clusters.<br />
Leaving filesystem unchanged.</pre><br />
| Useless null-based-read<br />
| None<br />
| [[9.6.0-24|9.6.0-X]]<br />
| July 8-9, 2015<br />
| <br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| RSA signature padding checks<br />
| The TWL_FIRM RSA sig padding check code used for all TWL RSA sig-checks has issues, see [[FIRM|here]].<br />
The main 3DS RSA padding check code(non-certificate, including NATIVE_FIRM) uses the function used with the above to extract more padding + the actual hash from the additional padding. This isn't really a problem here because there's proper padding check code which is executed prior to this.<br />
| <br />
| None<br />
| [[9.5.0-22|9.5.0-X]]<br />
| March 2015<br />
| <br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[AMPXI:ValidateDSiWareSectionMAC]] [[AES_Registers|AES]] keyslot reuse<br />
| When the input DSiWare section index is higher than <max number of DSiWare sections supported by this FIRM>, Process9 uses keyid 0x40 for calculating the AESMAC, which translates to keyslot 0x40. The result is that the keyslot is left at whatever was already selected before, since the AES selectkeyslot code will immediately return when keyslot is >=0x40. However, actually exploiting this is difficult: the calculated AESMAC is never returned, this command just compares the calculated AESMAC with the input AESMAC(result-code depends on whether the AESMACs match). It's unknown whether a timing attack would work with this.<br />
This is basically a different form of the pxips9 keyslot vuln, except with AESMAC etc.<br />
| See description.<br />
| None<br />
| [[11.3.0-36|11.3.0-X]]<br />
| March 15, 2015<br />
| December 29, 2015<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| pxips9 [[AES_Registers|AES]] keyslot reuse<br />
| This requires access to the [[Process_Services|ps:ps]]/pxi:ps9 services. One way to get access to this would be snshax on system-version <=10.1.0-X(see 32c3 3ds talk).<br />
When an invalid key-type value is passed to any of the PS commands, Process9 will try to select keyslot 0x40. That aesengine_setkeyslot() code will then immediately return due to the invalid keyslot value. Since that function doesn't return any errors, Process9 will just continue to do crypto with whatever AES keyslot was selected before the PS command was sent.<br />
| Reusing the previously used keyslot, for crypto with PS.<br />
| None<br />
| [[11.3.0-36|11.3.0-X]]<br />
| Roughly the same time(same day?) as firmlaunch-hax.<br />
| December 29, 2015<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| firmlaunch-hax: FIRM header ToCToU<br />
| This can't be exploited from ARM11 userland.<br />
During [[FIRM]] launch, the only FIRM header the ARM9 uses at all is stored in FCRAM, this is 0x200-bytes(the actual used FIRM RSA signature is read to the Process9 stack however). The ARM9 doesn't expect "anything" besides the ARM9 to access this data.<br />
With [[9.5.0-22]] the address of this FIRM header was changed from a FCRAM address, to ARM9-only address 0x01fffc00.<br />
| ARM9 code execution<br />
| [[9.5.0-22]]<br />
| <br />
| 2012, 3 days after [[User:Yellows8|Yellows8]] started Process9 code RE.<br />
| <br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| Uninitialized data output for (PXI) command replies<br />
| PXI commands for various services(including some [[Filesystem_services_PXI|here]] and many others) can write uninitialized data (like from ARM registers) to the command reply. This happens with stubbed commands, but this can also occur with certain commands when returning an error.<br />
Certain ARM11 service commands have this same issue as well.<br />
| <br />
| None<br />
| [[9.3.0-21|9.3.0-X]]<br />
| ?<br />
| <br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[Filesystem_services_PXI|FSPXI]] OpenArchive SD permissions<br />
| Process9 does not use the exheader ARM9 access-mount permission flag for SD at all.<br />
This would mean ARM11-kernelmode code / fs-module itself could directly use FSPXI to access SD card without ARM9 checking for SD access, but this is rather useless since a process is usually running with SD access(Home Menu for example) anyway.<br />
| <br />
| None<br />
| [[9.3.0-21|9.3.0-X]]<br />
| 2012<br />
| <br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[AMPXI:ExportDSiWare]] export path<br />
| Process9 allocates memory on Process9 heap for the export path then verifies that the actual allocated size matches the input size. Then Process9 copies the input path from FCRAM to this buffer, and uses it with the Process9 FS openfile code, which use paths in the form of "<mountpoint>:/<path>".<br />
Process9 does not check the contents of this path at all before passing it to the FS code, besides writing a NUL-terminator to the end of the buffer.<br />
| Exporting of DSiWare to arbitrary Process9 file-paths, such as "nand:/<path>" etc. This isn't really useful since the data which gets written can't be controlled.<br />
| None<br />
| [[9.5.0-22]]<br />
| April 2013<br />
| <br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[DSiWare_Exports]] [[CTCert]] verification<br />
| Just like DSi originally did, 3DS verifies the APCert for DSiWare on SD with the CTCert also in the DSiWare .bin. On DSi this was fixed with with system-version 1.4.2 by verifying with the actual console-unique cert instead(stored in NAND), while on 3DS it's still not(?) fixed.<br />
On 3DS however this is useless, unless one can obtain the console-unique movable.sed keyY which encrypts the entire DSiWare .bin.<br />
| When the movable.sed keyY for the target 3DS is known and the target 3DS CTCert private-key is unknown, importing of modified DSiWare SD .bin files.<br />
| None.<br />
| 11.6.0-X<br />
| April 2013<br />
| <br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| movable.sed keyY vulnerable to brute-force<br />
| Half of the movable.sed keyY's 128 bits are leaked through the [[Nandrw/sys/LocalFriendCodeSeed_B|LFCS]], which is available in userland and below. The LFCS itself also leaks almost half of the remaining bits by following the ratio: u32 keyY[3]=1/5(LFCS). The remaining keyY[3] uncertainty of about ±2000 can be greatly reduced by plotting expected error margins with several keyYs. This results in a final uncertainty of about 2^40, easily within practical brute force range of an average modern PC.<br />
| Knowing the keyY of a given 3ds allows for modification of DSiWare export contents, and chained with several other public vulns, ultimately arm9 execution.<br />
| None.<br />
| 11.6.0-X<br />
| December 2017<br />
| January 2018<br />
| zoogie<br />
|-<br />
| Improper validation of DSiWare title SRLs<br />
| The 3DS does not verify if the actual SRL embedded in the title's directory matches the titleID in the TMD before launching it or importing it from an sd DSiWare export. <br />
| This allows embedding older, exploitable DSiWare titles in completely different, unexploitable DSiWare titles. Since DSiWare has raw NAND RW, this can result in arm9 control through FIRM known-plaintext and sighax attacks.<br />
| None.<br />
| 11.6.0-X<br />
| 2015?<br />
| December 2016<br />
| Everyone<br />
|-<br />
| [[Gamecard_Services_PXI]] unchecked REG_CTRCARDCNT transfer-size<br />
| The u8 REG_CTRCARDCNT transfer-size parameter for the [[Gamecard_Services_PXI]] read/write CTRCARD commands is used as an index for an array of u16 values. Before [[5.0.0-11|5.0.0-X]] this u8 value wasn't checked, thus out-of-bounds reads could be triggered(which is rather useless in this case).<br />
| Out-of-bounds read for a value which gets written to a register.<br />
| [[5.0.0-11|5.0.0-X]]<br />
| <br />
| 2013?<br />
| <br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[PXI_Registers|PXI]] cmdbuf buffer overrun<br />
| The Process9 code responsible [[PXI_Registers|PXI]] communications didn't verify the size of the incoming command before writing it to a C++ member variable. <br />
| Probably ARM9 code execution<br />
| [[5.0.0-11|5.0.0-11]]<br />
| <br />
| March 2015, original timeframe if any unknown<br />
| <br />
| [[User:Plutooo|plutoo]]/[[User:Yellows8|Yellows8]]/maybe others(?)<br />
|-<br />
| [[Application_Manager_Services_PXI|PXIAM]] command 0x003D0108(See also [[Application_Manager_Services|this]])<br />
| When handling this command, Process9 allocates a 0x2800-byte heap buffer, then copies the 4 FCRAM input buffers to this heap buffer without checking the sizes at all(only the buffers with non-zero sizes are copied). Starting with [[5.0.0-11|5.0.0-X]], the total combined size of the input data must be <=0x2800.<br />
| ARM9 code execution<br />
| [[5.0.0-11|5.0.0-X]]<br />
| <br />
| May 2013<br />
| <br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[Process_Services_PXI|PS RSA]] commands buffer overflows<br />
| pxips9 cmd1(not accessible via ps:ps) and VerifyRsaSha256: unchecked copy to a buffer in Process9's .bss, from the input FCRAM buffer. The buffer is located before the pxi cmdhandler threads' stacks. SignRsaSha256 also has a buf overflow, but this isn't exploitable.<br />
The buffer for this is the buffer for the signature data. With v5.0, the signature buffer was moved to stack, with a check for the signature data size. When the signature data size is too large, Process9 uses [[SVC|svcBreak]].<br />
| ARM9 code execution<br />
| [[5.0.0-11|5.0.0-X]]<br />
| <br />
| 2012<br />
| <br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[PXI_Registers|PXI]] pxi_id bad check<br />
| The Process9 code responsible for [[PXI_Registers|PXI]] communications read pxi_id as a signed char. There were two flaws:<br />
* They used it as index to a lookup-table without checking the value at all.<br />
* Another function verified that pxi_id < 7, allowing negative values to pass the check. This would also cause an out-of-range table-lookup.<br />
| Maybe ARM9 code execution<br />
| [[3.0.0-5|3.0.0-5]]<br />
|<br />
| March 2015, originally 2012 for the first issue at least<br />
| <br />
| [[User:Plutooo|plutoo]], [[User:Yellows8|Yellows8]], maybe others(?)<br />
|}<br />
<br />
=== Kernel9 ===<br />
{| class="wikitable" border="1"<br />
|-<br />
! Summary<br />
! Description<br />
! Successful exploitation result<br />
! Fixed in [[FIRM]] system version<br />
! Last [[FIRM]] system version this flaw was checked for<br />
! Timeframe this was discovered<br />
! Discovered by<br />
|-<br />
| [[CONFIG Registers#CFG_SYSPROT9|CFG_SYSPROT9]] bit1 not set by Kernel9<br />
| Old versions of Kernel9 never set bit1 of [[CONFIG Registers#CFG_SYSPROT9|CFG_SYSPROT9]]. This leaves the [[OTP Registers|0x10012000]]-region unprotected (this region should be locked early during boot!). Since it's never locked, you can dump it once you get ARM9 code execution.<br />
<br />
From [[3.0.0-5|3.0.0-X]] this was fixed by setting the bit in Kernel9 after poking some registers in that region. On New3DS arm9loader sets this bit instead of Kernel9, which is exploitable through a hardware + software vulnerability (see arm9loaderhax / description).<br />
<br />
This flaw resurged when it gained a new practical use: retrieving the OTP data for a New3DS console in order to decrypt the key data used in arm9loader (see enhanced-arm9loaderhax / description). This was performed by downgrading to a vulnerable system version. By accounting for differences in CTR-NAND crypto (0x05 -> 0x04, see partition encryption types [[Flash_Filesystem#NAND_structure|here]]) and using an Old3DS [[NCSD#NCSD_header|NCSD Header]], it is possible to boot a New3DS using Old3DS firmware 1.0-2.x to retrieve the required OTP data using this flaw.<br />
| Dumping the [[OTP Registers|OTP]] area.<br />
Decrypting New3DS sector 0x96 keyblock.<br />
| [[3.0.0-5|3.0.0-X]]<br />
|<br />
| February 2015<br />
| [[User:Plutooo|plutoo]], Normmatt independently<br />
|}<br />
<br />
== ARM11 software ==<br />
=== Kernel11 ===<br />
{| class="wikitable" border="1"<br />
|-<br />
! Summary<br />
! Description<br />
! Successful exploitation result<br />
! Fixed in [[FIRM]] system version<br />
! Last [[FIRM]] system version this flaw was checked for<br />
! Timeframe this was discovered<br />
! Discovered by<br />
|-<br />
| [[SVC|svcSetProcessIdealProcessor]] reference count overflow and therefore use-after-free.<br />
| The SVC receive two arguments: handle and idealprocessor. The handle is used to get the KProcess object and the KProcess->refCnt gets incremented,later the function check if the KProcess->mem_type != BASE and if yes, it checks for idealprocessor == 2 or idealprocessor != 3. The problem here is that if you pass the idealprocessor = 3 it won't meet any condition and return the error 0xD9001BEA without decrement the reference count. <br />
It can be abused to overflow the KProcess reference count that will lead to an Use-after-free. <br />
| Before [[11.2.0-35|11.2.0-X]]: reference count overflow and therefore use-after-free.<br />
| <br />
| [[11.6.0-39|11.6.0-X]]<br />
| November 2, 2017<br />
| [[User:st4rk|st4rk]]<br />
|-<br />
| [[SVC|svcGetThreadList]] process reference leak<br />
| When given a valid process handle (including <code>0xFFFF8001</code>), svcGetThreadList forgets to decrement the reference count of the underlying [[KProcess]] instance, after having finished using it.<br />
| Before [[11.2.0-35|11.2.0-X]]: reference count overflow and therefore use-after-free, but this UAF was most likely not exploitable<br />
| <br />
| [[11.3.0-36|11.3.0-X]]<br />
| April 3, 2017<br />
| [[User:TuxSH|TuxSH]]<br />
|-<br />
| kernelhax via gspwn<br />
| Originally the kernel didn't initialize [[CONFIG11_Registers#CFG11_GPUPROT|CFG11_GPUPROT]]. Since it's 0 at hard-boot, this allowed the GPU to access the entire FCRAM + AXIWRAM.<br />
| Entire FCRAM+AXIWRAM R/W.<br />
| [[3.0.0-5|3.0.0-X]]<br />
| <br />
| February 7, 2017<br />
| [[User:Plutooo|plutoo]], [[User:Yellows8|Yellows8]] partly<br />
|-<br />
| fasthax<br />
| When a KTimer is created in pulse mode, the kernel calls a virtual function to reset the timer each time it pulses. The scheduler is locked for that core to avoid race conditions, but another core can call CloseHandle on the timer and free it, leading to a UAF vtable call.<br />
| See description.<br />
| [[11.3.0-36|11.3.0-X]]<br />
| [[11.3.0-36|11.3.0-X]]<br />
| May 2016<br />
| nedwill<br />
|-<br />
| ipctakeover<br />
| When sending cmdreplies, it does not validate that the src_addr and src_size match the equivalent dst_addr and dst_size. With a modified addr/size specified in a cmdreply for an output buffer, the data-copy for the first/last pages could be used to overwrite data outside of the buffer specified by the original process.<br />
<br />
Used by ctr-httpwn as of v1.2, for "ipctakeover/bosshaxx".<br />
<br />
This can be used to takeover processes where the process is using your service session. Like HTTPC -> BOSS, for bosshaxx above. NIM takeover can be done too(actual stack buffer overflow can trigger), etc.<br />
| See description.<br />
| None<br />
| [[11.3.0-36|11.3.0-X]]<br />
| November 26, 2016<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| Using IPC input buffers as output buffers<br />
| When sending cmdreplies, it does not validate that the cmdreply descriptor type matches the equivalent cmdreq descriptor type. This could be used by an exploited sysmodule to use what was intended as an input-buffer as an output-buffer, and also combine other IPC vuln(s) with this.<br />
<br />
Used by ctr-httpwn as of v1.2, for "ipctakeover/bosshaxx".<br />
| See description.<br />
| None<br />
| [[11.3.0-36|11.3.0-X]]<br />
| November 2016<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[SVC]] table too small<br />
| The table of function pointers for SVC's only contains entries up to 0x7D, but the biggest allowed SVC for the table is 0x7F. Thus, executing SVC7E or SVC7F would make the SVC-handler read after the buffer, and interpret some ARM instructions as function pointers.<br />
<br />
However, this would require patching the kernel .text or modifying SVC-access-control. Even if you could get these to execute, they would still jump to memory that isn't mapped as executable.<br />
| <br />
| None<br />
| [[11.3.0-36|11.3.0-X]]<br />
| 2012<br />
| Everyone<br />
|-<br />
| [[SVC|svcBackdoor (0x7B)]]<br />
| This backdoor allows executing SVC-mode code at the user-specified code-address. This is used by Process9, using this on the ARM11 (with NATIVE_FIRM) required patching the kernel .text or modifying SVC-access-control.<br />
| See description<br />
| [[11.0.0-33|11.0.0-X]] (deleted)<br />
| <br />
|<br />
| Everyone<br />
|-<br />
| veryslowpidhax<br />
| '''This is completely different from the kernelmode-code-execution vuln described in the below separate entry.'''<br />
<br />
When updating the kernel global PID counter under [[SVC|svcCreateProcess]] the kernel does not check for wraparound to 0x0(the PID for the very first process). This only matters because [[Services|SM-module]] allows processes with PID value less than <total ARM11 FIRM modules> to access ''all'' services, without checking exheader service-access-control; and because Kernel11 checks for the PID to be 1 (loader) to use the input mem-region value on ControlMemory. This alone does not affect access the [[SVC|SVCs]] access table at all.<br />
<br />
Inlined ldrex+strex code is used for updating the above counter. [[11.2.0-35|11.2.0-X]] had changes for similar code, but it was only for dedicated ldrex+strex functions(mainly for kernel objects) and hence this PID code was not affected.<br />
<br />
With launching+terminating a sysmodule repeatedly with this via ns:s, it would take weeks to finish(if not at least about a month?).<br />
| Access to all [[Services_API|services]], ControlMemory on any given mem-region.<br />
| None<br />
| [[11.3.0-36|11.3.0-X]]<br />
| 2012 maybe?<br />
| <br />
|-<br />
| slowhax/waithax<br />
| svcWaitSynchronizationN does not decrement the references to valid handles in an array before returning an error when it encounters an invalid handle. This allows one to (slowly) overflow the reference count for a handle object to zero.<br />
| ARM11 kernel-mode code execution<br />
| [[11.2.0-35|11.2.0-X]]<br />
| [[11.2.0-35|11.2.0-X]]<br />
| 2016<br />
| nedwill, [[User:Derrek|derrek]]<br />
|-<br />
| [[Memory_layout#ARM11_Detailed_virtual_memory_map|0xEFF00000]] / 0xDFF00000 ARM11 kernel virtual-memory<br />
| The ARM11 kernel-mode 0xEFF00000/0xDFF00000 virtual-memory(size 0x100000) is mapped to phys-mem 0x1FF00000(entire DSP-mem + entire AXIWRAM), with permissions RW-. This is used during ARM11 kernel startup for loading the FIRM-modules from the FIRM section located in DSP-mem, this never seems to be used after that, however. This is never unmapped either.<br />
| <br />
| None<br />
| [[11.3.0-36|11.3.0-X]]<br />
| <br />
| <br />
|-<br />
| memchunkhax2.1<br />
| Nintendo's fix for memchunkhax2 in [[10.4.0-29|10.4.0-X]] did not fix the GPU case: one may cause the requisite ToCToU race using gspwn, bypassing the new validation.<br />
derrek's original 32c3 presentation for memchunkhax2 commented that a GPU-based attack was possible, but would be difficult. However, memchunkhax2.1 showed that it was possible to do fairly reliably.<br />
| ARM11 kernel code execution<br />
| [[11.0.0-33|11.0.0-X]], via the new [[Memory_Management#MemoryBlockHeader|memchunkhdr]] MAC which prevents modifying memchunkhdr data with DMA.<br />
| [[11.0.0-33|11.0.0-X]]<br />
|<br />
| [[User:Derrek|derrek]], aliaspider<br />
|-<br />
| memchunkhax2<br />
| When allocating a block of memory, the "next" pointer of the [[Memory_Management#MemoryBlockHeader|memchunkhdr]] is accessed without being checked after being mapped to userland.<br />
This allows a race condition, where the process can change the next pointer just before it's accessed. By pointing the next pointer to a crafted memchunckhdr in the kernel SlabHeap, some of the SlabHeap is allocated to the calling process, allowing to change vtables of kernel objects. <br />
| ARM11 kernel code execution<br />
| [[10.4.0-29|10.4.0-X]] (partially, see memchunkhax2.1)<br />
| [[10.4.0-29|10.4.0-X]]<br />
|<br />
| [[User:Derrek|derrek]]<br />
|-<br />
| heaphax<br />
| Can change the size of free memchunk structures stored in FCRAM using DMA, which leads to the ability to allocate memory chunks over already-allocated memory. This can be used in the SYSTEM region to allocate RW memory over any part of the NS system module, which is enough to take it over.<br />
| Code execution with access to all of NS's privileges. (including downgrading) Code execution within any applet.<br />
| [[11.0.0-33|11.0.0-X]], via the new [[Memory_Management#MemoryBlockHeader|memchunkhdr]] MAC which prevents modifying memchunkhdr data with DMA.<br />
| [[11.0.0-33|11.0.0-X]]<br />
| April 2015 ?<br />
| smea<br />
|-<br />
| snshax<br />
| Can force creation of Safe NS process into gspwn-able memory, allowing for takeover.<br />
| Code execution with access to all of NS's privileges. (including downgrading)<br />
| [[10.1.0-27|10.1.0-X]]<br />
| [[10.1.0-27|10.1.0-X]]<br />
| April 2015 ?<br />
| smea<br />
|-<br />
| AffinityMask/processorid validation<br />
| With [[10.0.0-27|10.0.0-X]] the following functions were updated: svcGetThreadAffinityMask, svcGetProcessAffinityMask, svcSetProcessAffinityMask, and svcCreateThread. The code changes for all but svcCreateThread are identical.<br />
The original code with the first 3 did the following: <br />
* if(u32_processorcount > ~0x80000001)return 0xe0e01bfd;<br />
* if(s32_processorcount > <total_cores>)return 0xd8e007fd;<br />
The following code replaced the above:<br />
* if(u32_processorcount >= <total_cores+1>)return 0xd8e007fd;<br />
In theory the latter should catch everything that the former did, so it's unknown if this was really a security issue.<br />
<br />
The svcCreateThread changes with [[10.0.0-27|10.0.0-X]] definitely did fix a security issue.<br />
* Original code: "if(s32_processorid > <total_cores>)return 0xd8e007fd;"<br />
* New code: "if(s32_processorid >= <total_cores> || s32_processorid <= -4)return 0xd8e007fd;"<br />
This fixed an off-by-one issue: if one would use processorid=total_cores, which isn't actually a valid value, svcCreateThread would accept that value on <[[10.0.0-27|10.0.0-X]]. This results in data being written out-of-bounds(baseaddr = arrayaddr + entrysize*processorid), which has the following result:<br />
* Old3DS: Useless kernel-mode crash due to accessing unmapped memory.<br />
* New3DS: uncontrolled data write into a kernel-mode L1 MMU-table. This isn't really useful: the data can't be controlled, and the data which gets overwritten is all-zero anyway(this isn't anywhere near MMU L1 entries for actually mapped memory).<br />
The previous version also allowed large negative s32_processorid values(negative processorid values are special values not actual procids), but it appears using values like that won't actually do anything(meaning no crash) besides the thread not running / thread not running for a while(besides triggering a kernelpanic with certain s32_processorid value(s)).<br />
| Nothing useful<br />
| [[10.0.0-27|10.0.0-X]]<br />
| [[10.0.0-27|10.0.0-X]]<br />
| svcCreateThread issue: May 31, 2015. The rest: September 8, 2015, via v9.6->v10.0 ARM11-kernel code-diff.<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| memchunkhax<br />
| The kernel originally did not validate the data stored in the FCRAM kernel heap [[Memchunkhdr|memchunk-headers]] for free-memory at all. Exploiting this requires raw R/W access to these memchunk-headers, like physical-memory access with gspwn.<br />
<br />
There are ''multiple'' ways to exploit this, but the end-result for most of these is the same: overwrite code in AXIWRAM via the 0xEFF00000/0xDFF00000 kernel virtual-memory mapping.<br />
<br />
This was fixed in [[9.3.0-21|9.3.0-X]] by checking that the memchunk(including size, next, and prev ptrs) is located within the currently used heap memory. The kernel may also check that the next/prev ptrs are valid compared to other memchunk-headers basically. When any of these checks fail, kernelpanic() is called.<br />
| When combined with other flaws: ARM11-kernelmode code execution<br />
| [[9.3.0-21|9.3.0-21]]<br />
| <br />
| February 2014<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| Multiple [[KLinkedListNode|KLinkedListNode]] SlabHeap use after free bugs<br />
| The ARM11-kernel did access the 'key' field of [[KLinkedListNode|KLinkedListNode]] objects, which are located on the SlabHeap, after freeing them. Thus, triggering an allocation of a new [[KLinkedListNode|KLinkedListNode]] object at the right time could result in a type-confusion. Pseudo-code:<br />
SlabHeap_free(KLinkedListNode);<br />
KObject *obj = KLinkedListNode->key; // the object there might have changed!<br />
This bug appeared all over the place.<br />
| ARM11-kernelmode code exec maybe<br />
| [[8.0.0-18|8.0.0-18]]<br />
| <br />
| April 2015<br />
| [[User:Derrek|derrek]]<br />
|-<br />
| PXI [[RPC_Command_Structure|Command]] input/output buffer permissions<br />
| Originally the ARM11-kernel didn't check permissions for PXI input/output buffers for commands. Starting with [[6.0.0-11|6.0.0]] PXI input/output buffers must have RW permissions, otherwise kernelpanic is triggered.<br />
| <br />
| [[6.0.0-11|6.0.0-11]]<br />
| <br />
| 2012<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[SVC|svcStartInterProcessDma]]<br />
| For svcStartInterProcessDma, the kernel code had the following flaws:<br />
<br />
* Originally the ARM11-kernel read the input DmaConfig structure directly in kernel-mode(ldr(b/h) instructions), without checking whether the DmaConfig address is readable under userland. This was fixed by copying that structure to the SVC-mode stack, using the ldrbt instruction.<br />
<br />
* Integer overflows for srcaddr+size and dstaddr+size are now checked(with [[6.0.0-11]]), which were not checked before.<br />
<br />
* The kernel now also checks whether the srcaddr/dstaddr (+size) is within userland memory (0x20000000), the kernel now (with [[6.0.0-11]]) returns an error when the address is beyond userland memory. Using an address >=0x20000000 would result in the kernel reading from the process L1 MMU table, beyond the memory allocated for that MMU table(for vaddr->physaddr conversion). <br />
| <br />
| [[6.0.0-11]]<br />
| <br />
| DmaConfig issue: unknown. The rest: 2014<br />
| [[User:Plutooo|plutoo]], [[User:Yellows8|Yellows8]] independently<br />
|-<br />
| [[SVC|svcControlMemory]] Parameter checks<br />
| For svcControlMemory the parameter check had these two flaws:<br />
<br />
* The allowed range for addr0, addr1, size parameters depends on which MemoryOperation is being specified. The limitation for GSP heap was only checked if op=(u32)0x10003. By setting a random bit in op that has no meaning (like bit17?), op would instead be (u32)0x30003, and the range-check would be less strict and not accurate. However, the kernel doesn't actually use the input address for LINEAR memory-mapping at all besides the range-checks, so this isn't actually useful. This was fixed in the kernel by just checking for the LINEAR bit, instead of comparing the entire MemoryOperation value with 0x10003.<br />
<br />
* Integer overflows on (addr0+size) are now checked that previously weren't (this also applies to most other address checks elsewhere in the kernel).<br />
<br />
| <br />
| [[5.0.0-11]]<br />
| <br />
|<br />
| [[User:Plutooo|plutoo]]<br />
|-<br />
| [[RPC_Command_Structure|Command]] request/response buffer overflow<br />
| Originally the kernel did not check the word-values from the command-header. Starting with [[5.0.0-11]], the kernel will trigger a kernelpanic() when the total word-size of the entire command(including the cmd-header) is larger than 0x40-words (0x100-bytes). This allows overwriting threadlocalstorage+0x180 in the destination thread. However, since the data written there would be translate parameters (such as header-words + buffer addresses), exploiting this would likely be very difficult, if possible at all.<br />
<br />
If the two words at threadlocalstorage+0x180 could be overwritten with controlled data this way, one could then use a command with a buffer-header of <nowiki>((size<<14) | 2)</nowiki> to write arbitrary memory to any RW userland memory in the destination process.<br />
| <br />
| [[5.0.0-11]]<br />
| <br />
| v4.1 FIRM -> v5.0 code diff<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[SVC|SVC stack allocation overflows]]<br />
| <br />
* Syscalls that allocate a variable-length array on stack, only checked bit31 before multiplying by 4/16 (when calculating how much memory to allocate). If a large integer was passed as input to one of these syscalls, an integer overflow would occur, and too little memory would have been allocated on stack resulting in a buffer overrun. <br />
* The alignment (size+7)&~7 calculation before allocation was not checked for integer overflow.<br />
<br />
This might allow for ARM11 kernel code-execution.<br />
<br />
(Applies to svcSetResourceLimitValues, svcGetThreadList, svcGetProcessList, svcReplyAndReceive, svcWaitSynchronizationN.)<br />
| <br />
| [[5.0.0-11]]<br />
| <br />
| v4.1 FIRM -> v5.0 code diff<br />
| [[User:Plutooo|plutoo]], [[User:Yellows8|Yellows8]] complementary<br />
|-<br />
| [[SVC|svcControlMemory]] MemoryOperation MAP memory-permissions<br />
| svcControlMemory with MemoryOperation=MAP allows mapping the already-mapped process virtual-mem at addr1, to addr0. The lowest address permitted for addr1 is 0x00100000. Originally the ARM11 kernel didn't check memory permissions for addr1. Therefore .text as addr1 could be mapped elsewhere as RW- memory, which allowed ARM11 userland code-execution.<br />
| <br />
| [[4.1.0-8]]<br />
| <br />
| 2012<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[RPC_Command_Structure|Command]] input/output buffer permissions<br />
| Originally the ARM11 kernel didn't check memory permissions for the input/output buffers for commands. Starting with [[4.0.0-7]] the ARM11 kernel will trigger a kernelpanic() if the input/output buffers don't have the required memory permissions. For example, this allowed a FSUSER file-read to .text, which therefore allowed ARM11-userland code execution.<br />
| <br />
| [[4.0.0-7]]<br />
| <br />
| 2012<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[SVC|svcReadProcessMemory/svcWriteProcessMemory memory]] permissions<br />
| Originally the kernel only checked the first page(0x1000-bytes) of the src/dst buffers, for svcReadProcessMemory and svcWriteProcessMemory. There is no known retail processes which have access to these SVCs.<br />
| <br />
| [[4.0.0-7]]<br />
| <br />
| 2012?<br />
| [[User:Yellows8|Yellows8]]<br />
|}<br />
<br />
=== [[FIRM]] Sysmodules ===<br />
{| class="wikitable" border="1"<br />
|-<br />
! Summary<br />
! Description<br />
! Successful exploitation result<br />
! Fixed in [[FIRM]] system version<br />
! Last [[FIRM]] system version this flaw was checked for<br />
! Timeframe this was discovered<br />
! Discovered by<br />
|-<br />
| [[Services|"srv:pm"]] process registration<br />
| Originally any process had access to the port "srv:pm". The PID's used for the (un)registration commands are not checked either. This allowed any process to re-register itself with "srv:pm", and therefore allowed the process to give itself access to any service, bypassing the exheader service-access-control list.<br />
<br />
This was fixed in [[7.0.0-13]]: starting with [[7.0.0-13]] "srv:pm" is now a service instead of a globally accessible port. Only processes with PID's less than 6 (in other words: fs, ldr, sm, pm, pxi modules) have access to it. With [[7.0.0-13]] there can only be one session for "srv:pm" open at a time(this is used by pm module), svcBreak will be executed if more sessions are opened by the processes which can access this.<br />
<br />
This flaw was needed for exploiting the <=v4.x Process9 PXI vulnerabilities from ARM11 userland ROP, since most applications don't have access to those service(s).<br />
| Access to arbitrary services<br />
| [[7.0.0-13]]<br />
| <br />
| 2012<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| FSDIR null-deref<br />
| [[Filesystem_services|FS]]-module may crash in some cases when handling directory reading. The trigger seems to be due to using [[FSDir:Close]] without closing the dir-handle afterwards?(Perhaps this is caused by out-of-memory?) This seems to be useless since it's just a null-deref.<br />
| <br />
| None<br />
| [[9.6.0-24|9.6.0-X]]<br />
| May 19(?)-20, 2015<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[SM]] out-of-bounds BSS write (table 1 entry too small)<br />
| After accepting a new session, [[SM]] writes a (handler ID (0 for srv: sessions (max. 64), 1 for the srv:pm one), pointer to session context structure in BSS) pair in a global array. However that array is only 64-entry-big instead of 65 (as it ought to be), and no bound check is done in that regard.<br />
<br />
Unfortunately, as of [[11.4.0-37]], the overwritten fields are totally unused after their initialization by <code>__libc_init_array</code>.<br />
| Not currently exploitable<br />
| None<br />
| [[11.4.0-37]]<br />
|<br />
|<br />
|}<br />
<br />
=== Standalone Sysmodules ===<br />
{| class="wikitable" border="1"<br />
|-<br />
! Summary<br />
! Description<br />
! Successful exploitation result<br />
! Fixed in system-module system-version<br />
! Last system-module system-version this flaw was checked for<br />
! Timeframe this was discovered<br />
! Timeframe this was added to wiki<br />
! Discovered by<br />
|-<br />
| [[MP:SendDataFrame]] missing input array index validation<br />
| [[MP:SendDataFrame]] doesn't validate the input index at cmdreq[1], unless the function for flag=non-zero is executed. This is used to calculate the following, without validating the index at all: someptr = stateptr + (index*0x924) + somestateoffset.<br />
<br />
After validating some flags from someptr, when input_flag=0 the input buffer data is copied to someptr+someotheroffset+0x14 with the u16 size loaded from someptr+someotheroffset.<br />
<br />
With a large input index someptr could be setup to be at a <target address>, for overwriting memory.<br />
<br />
This is probably difficult to exploit.<br />
| <br />
| None<br />
| [[8.0.0-18]](MP-sysmodule v2048)<br />
| January 22, 2017<br />
| January 22, 2017<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[MP_Services|MP]] cmd1 out-of-bounds handle read<br />
| MP-sysmodule handles the input parameter for cmd1 as a s32. It checks for >=16, but not <0. With <16 it basically does the following(array of entries 4-bytes each): *outhandle = ((Handle*)(stateptr+offsetinstate))[inputindex].<br />
<br />
Hence, this can be used to load any handle in MP-sysmodule memory. MP doesn't really have any service handles of interest however(can be obtained from elsewhere too).<br />
| Reading any handle in MP-sysmodule memory.<br />
| None<br />
| [[8.0.0-18]](MP-sysmodule v2048)<br />
| January 21, 2017<br />
| January 22, 2017<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| AM stack/.bss infoleak via [[AM:ReadTwlBackupInfo]]([[AM:ReadTwlBackupInfoEx|Ex]])<br />
| After writing the output-info structure to stack, it then copies that structure to the output buffer ptr using the size from the command. The size is not checked. This could be used to read data from the AM-service-thread stack handling the command + .bss.<br />
<br />
'''This was not tested on hardware.'''<br />
| Stack/.bss reading<br />
| None<br />
| [[10.0.0-27]](AM v9217)<br />
| Roughly October 17, 2016<br />
| October 25, 2016<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[MVD_Services|MVD]]: Stack buffer overflow with [[MVDSTD:SetupOutputBuffers]].<br />
| The input total_entries is not validated when initially processing the input entry-list. This fixed-size input entry-list is copied to stack from the command request. The loop for processing this initializes a global table, the converted linearmem->physaddrs used there are also copied to stack(0x8-bytes of physaddrs per entry).<br />
<br />
If total_entries is too large, MVD-sysmodule will crash due to reading unmapped memory following the stack(0x10000000). Afterwards if the out-of-bounds total_entries is smaller than that, it will crash due accessing address 0x0, hence this useless.<br />
| MVD-sysmodule crash.<br />
| None<br />
| [[9.0.0-20]]<br />
| April 22, 2016 (Tested on the 25th)<br />
| April 25, 2016<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[NWM_Services|NWM]]: Using CTRSDK heap with UDS sharedmem from the user-process.<br />
| See the HTTP-sysmodule section below.<br />
<br />
CTRSDK heap is used with the sharedmem from [[NWMUDS:InitializeWithVersion]]. Buffers are allocated/freed under this heap using [[NWMUDS:Bind]] and [[NWMUDS:Unbind]].<br />
<br />
Hence, overwriting sharedmem with gspwn then using [[NWMUDS:Unbind]] results in the usual controlled CTRSDK memchunk-header write, similar to HTTP-sysmodule.<br />
<br />
This could be done by creating an UDS network, without any other nodes on the network.<br />
<br />
Besides CTRSDK memchunk-headers, there are no addresses stored under this sharedmem.<br />
| ROP under NWM-module.<br />
| [[11.4.0-37|11.4.0-X]]<br />
| [[9.0.0-20|9.0.0-X]]<br />
| April 10, 2016<br />
| April 16, 2016<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[DLP_Services|DLP]]: Out-of-bounds memory access during spectator [[Download_Play|data-frame]] checksum calculation<br />
| DLP doesn't validate the frame_size when receiving spectator data-frames at all, unlike non-spectator data-frames. The actual spectator data-frame parsing code doesn't use that field either. However, the data-frame checksum calculation code called during checksum verification does use the frame_size for loading the size of the framebuf.<br />
<br />
Hence, using a large frame_size like 0xFFFF will result in the checksum calculation code reading data out-of-bounds. This isn't really useful, you could trigger a remote local-WLAN DLP-sysmodule crash while a 3DS system is scanning for DLP networks(due to accessing unmapped memory), but that's about all(trying to infoleak with this likely isn't useful either).<br />
| DLP-sysmodule crash, handled by dlplay system-application by a "connection interrupted" error eventually then a fatal-error via ErrDisp.<br />
| None<br />
| [[10.0.0-27|10.0.0-X]]<br />
| April 8, 2016 (Tested on the 10th)<br />
| April 10, 2016<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[DLP_Services|DLP]]: Out-of-bounds output data writing during spectator sysupdate titlelist [[Download_Play|data-frame]] handling<br />
| The total_entries and out_entryindex fields for the titlelist DLP spectator data-frames are not validated. This is parsed during DLP network scanning. Hence, the specified titlelist data can be written out-of-bounds using the specified out_entryindex and total_entries. A crash will occur while reading the input data-frame titlelist if total_entries is larger than 0x27A, due to accessing unmapped memory.<br />
<br />
There's not much non-zero data to overwrite following the output buffer(located in sharedmem), any ptrs are located in sharedmem. Overwriting certain ptr(s) are only known to cause a crash when attempting to use the DLP-client shutdown service-command.<br />
<br />
There's no known way to exploit the above crash, since the linked-list code involves writes zeros(with a controlled start ptr).<br />
| <br />
| None<br />
| [[10.0.0-27|10.0.0-X]]<br />
| April 8-9, 2016<br />
| April 10, 2016<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[IR_Services|IR]]: Stack buffer overflow with custom hardware<br />
| Originally IR sysmodule used the read value from the I2C-IR registers TXLVL and RXLVL without validating them at all. See [[10.6.0-31|here]] for the fix. This is the size used for reading the data-recv FIFO, etc. The output buffer for reading is located on the stack.<br />
<br />
This should be exploitable if one could successfully setup the custom hardware for this and if the entire intended sizes actually get read from I2C.<br />
| ROP under IR sysmodule.<br />
| [[10.6.0-31|10.6.0-31]]<br />
| <br />
| February 23, 2016 (Unknown if it was noticed before then)<br />
| February 23, 2016<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[HTTP_Services|HTTP]]: Using CTRSDK heap with sharedmem from the user-process.<br />
| The data from httpcAddPostDataAscii and other commands is stored under a CTRSDK heap. That heap is the sharedmem specified by the user-process via the HTTPC Initialize command.<br />
Normally this sharedmem isn't accessible to the user-process once the sysmodule maps it, hence using it is supposed to be "safe".<br />
<br />
This isn't the case due to gspwn however. Since CTRSDK heap code is so insecure in general, one can use gspwn to locate the HTTPC sharedmem + read/write it, then trigger a mem-write under the sysmodule. This can then be used to get ROP going under HTTP-sysmodule.<br />
<br />
This is exploited by [https://github.com/yellows8/ctr-httpwn/ctr-httpwn ctr-httpwn].<br />
| ROP under HTTP sysmdule.<br />
| [[11.4.0-37|11.4.0-X]]<br />
| [[9.6.0-24|9.6.0-X]] (Latest sysmodule version as of [[10.7.0-32|10.7.0-32]])<br />
| Late 2015<br />
| March 22, 2016<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[NIM_Services|NIM]]: Downloading old title-versions from eShop<br />
| Multiple NIM service commands(such as [[NIMS:StartDownload]]) use a title-version value specified by the user-process, NIM does not validate that this input version matches the latest version available via SOAP. Therefore, when combined with AM(PXI) [[#Process9|title-downgrading]] via deleting the target eShop title with System Settings Data Management(if the title was already installed), this allows downloading+installing any title-version from eShop ''if'' it's still available from CDN.<br />
The easiest way to exploit this is to just patch the eShop system-application code using these NIM commands(ideally the code which loads the title-version).<br />
<br />
Originally this was tested with a debugging-system via modded-FIRM, eventually smea implemented it in HANS for the 32c3 release.<br />
| Downloading old title-versions from eShop<br />
| None<br />
| [[10.0.0-27|10.0.0-X]]<br />
| October 24, 2015 (Unknown when exactly the first eShop title downgrade was actually tested, maybe November)<br />
| January 7, 2016 (Same day Ironfall v1.0 was removed from CDN via the main-CXI files)<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[SPI_Services|SPI]] service out-of-bounds write<br />
| cmd1 has out-of-bounds write allowing overwrite of some static variables in .data.<br />
| <br />
| None<br />
| [[9.5.0-22]]<br />
| March 2015<br />
| <br />
| [[User:Plutooo|plutoo]]<br />
|-<br />
| [[NFC_Services|NFC]] module service command buf-overflows<br />
| NFC module copies data with certain commands, from command input buffers to stack without checking the size. These commands include the following, it's unknown if there's more commands with similar issues: "nfc:dev" <0x000C....> and "nfc:s" <0x0037....>.<br />
Since both of these commands are stubbed in the Old3DS NFC module from the very first version(those just return an error), these issues only affect the New3DS NFC module.<br />
<br />
There's no known retail titles which have access to either of these services.<br />
| ROP under NFC module.<br />
| New3DS: None<br />
| New3DS: [[9.5.0-22]]<br />
| December 2014?<br />
| <br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[News_Services|NEWSS]] service command notificationID validation failure<br />
| This module does not validate the input notificationID for <nowiki>"news:s"</nowiki> service commands. This is an out-of-bounds array index bug. For example, [[NEWSS:SetNotificationHeader]] could be used to exploit news module: this copies the input data(size is properly checked) to: out = newsdb_savedata+0x10 + (someu32array[notificationID]*0x70).<br />
| ROP under news module.<br />
| None<br />
| [[9.7.0-25|9.7.0-X]]<br />
| December 2014<br />
| <br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[NWMUDS:DecryptBeaconData]] heap buffer overflow<br />
| input_size = 0x1E * <value the u8 from input_[[NWM_Services|networkstruct]]+0x1D>. Then input_tag0 is copied to a heap buffer. When input_size is larger than 0xFA-bytes, it will then copy input_tag1 to <end_address_of_previous_outbuf>, with size=input_size-0xFA.<br />
<br />
This can be triggered by either using this command directly, or by boadcasting a wifi beacon which triggers it while a 3DS system running the target process is in range, when the process is scanning for hosts to connect to. Processes will only pass tag data to this command when the wlancommID and other thing(s) match the values for the process.<br />
<br />
There's no known way to actually exploit this for getting ROP under NWM-module, at the time of originally adding this to the wiki. This is because the data which gets copied out-of-bounds *and* actually causes crash(es), can't be controlled it seems(with just broadcasting a beacon at least). It's unknown whether this could be exploited from just using NWMUDS service-cmd(s) directly.<br />
| Without any actual way to exploit this: NWM-module DoS, resulting in process termination(process crash). This breaks *everything* involving wifi comms, a reboot is required to recover from this.<br />
| None<br />
| [[9.0.0-20]]<br />
| ~September 23, 2014(see the [[NWMUDS:DecryptBeaconData]] page history)<br />
| August 3, 2015<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[HID_Services|HID]] module shared-mem<br />
| HID module does not validate the index values in [[HID_Shared_Memory|sharedmem]](just changes index to 0 when index == maxval when updating), therefore large values will result in HID module writing HID data to arbitrary addresses.<br />
| ROP under HID module, but this is *very* unlikely to be exploitable since the data written is HID data.<br />
| None<br />
| [[9.3.0-21]]<br />
| 2014?<br />
| <br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| gspwn<br />
| GSP module does not validate addresses given to the GPU. This allows a user-mode application/applet to read/write to a large part of physical FCRAM using GPU DMA. From this, you can overwrite the .text segment of the application you're running under, and gain real code-execution from a ROP-chain. Normally applets' .text([[Home Menu]], [[Internet Browser]], etc) is located beyond the area accessible by the GPU, except for [[RO_Services|CROs]] used by applets([[Internet Browser]] for example).<br />
<br />
FCRAM is gpu-accessible up to physaddr 0x26800000 on Old3DS, and 0x2D800000 on New3DS. This is BASE_memregion_start(aka SYSTEM_memregion_end)-0x400000 (0x800000 with New3DS) with the default memory-layout on Old3DS/New3DS. With [[11.3.0-36|11.3.0-X]] the cutoff now varies due to the new [[SVC]] 0x59. The New3DS "normal"(non-APPLICATION) cutoff was changed to 0x2D000000 due to the new [[SVC]] 0x59.<br />
| User-mode code execution.<br />
| None<br />
| [[9.6.0-24|9.6.0-X]]<br />
| Early 2014<br />
| <br />
| smea, [[User:Yellows8|Yellows8]]/others before then<br />
|-<br />
| rohax<br />
| Using gspwn, it is possible to overwrite a loaded [[CRO0]]/[[CRR0]] after its RSA-signature has been validated. Badly validated [[CRO0]] header leads to arbitrary read/write of memory in the ro-process. This gives code-execution in the ro module, who has access to [[SVC|syscalls]] 0x70-0x72, 0x7D.<br />
<br />
This was fixed after [[ninjhax]] release by adding checks on [[CRO0]]-based pointers before writing to them.<br />
| Memory-mapping syscalls.<br />
| [[9.3.0-21]]<br />
| [[9.4.0-21]]<br />
| <br />
| <br />
| smea, [[User:Plutooo|plutoo]] joint effort<br />
|-<br />
| Region free<br />
| Only [[Home Menu]] itself checks gamecards' region when launching them. Therefore, any application launch that is done directly with [[NS]] without signaling Home Menu to launch the app, will result in region checks being bypassed.<br />
This essentially means launching the gamecard with the [[NS_and_APT_Services|"ns:s"]] service. The main way to exploit this is to trigger a FIRM launch with an application specified, either with a normal FIRM launch or a hardware [[NSS:RebootSystem|reboot]].<br />
| Launching gamecards from any region + bypassing Home Menu gamecard-sysupdate installation<br />
| None<br />
| Last tested with [[10.1.0-27|10.1.0-X]].<br />
| June(?) 2014<br />
| <br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[NWM_Services|NWM]] service-cmd state null-ptr deref<br />
| The NWMUDS service command code loads a ptr from .data, adds an offset to that, then passes that as the state address for the actual command-handler function. The value of the ptr loaded from .data is not checked, therefore this will cause crashes due to that being 0x0 when NWMUDS was not properly initialized.<br />
It's unknown whether any NWM services besides NWMUDS have this issue.<br />
| This is rather useless since it's only a crash caused by a state ptr based at 0x0.<br />
| None<br />
| [[9.0.0-20]]<br />
| 2013?<br />
| <br />
| [[User:Yellows8|Yellows8]]<br />
|}<br />
<br />
=== General/CTRSDK ===<br />
{| class="wikitable" border="1"<br />
|-<br />
! Summary<br />
! Description<br />
! Successful exploitation result<br />
! Fixed in version<br />
! Last version this flaw was checked for<br />
! Timeframe this was discovered<br />
! Discovered by<br />
|-<br />
| [[NWM_Services|UDS]] beacon additional-data buffer overflow<br />
| Originally CTRSDK did not validate the UDS additional-data size before using that size to copy the additional-data to a [[NWM_Services|networkstruct]]. This was eventually fixed.<br />
This was discovered while doing code RE with an old dlp-module version. It's unknown in what specific CTRSDK version this was fixed, or even what system-version updated titles with a fixed version.<br />
<br />
It's unknown if there's any titles using a vulnerable CTRSDK version which are also exploitable with this(dlp module can't be exploited with this).<br />
<br />
The maximum number of bytes that can be written beyond the end of the outbuf is 0x37-bytes, with additionaldata_size=0xFF.<br />
| Perhaps ROP, very difficult if possible with anything at all<br />
| ?<br />
| <br />
| September(?) 2014<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| CTPK buffer overflow<br />
| At offset 0x20 in CTPK is an array for each texture, each entry is 0x20-bytes. This contains a wordindex(entry+0x18) for some srcdata relative to CTPK+0, and an u8 wordsize(entry+0x14) for this data. The CTRSDK function handling this doesn't validate the size, when copying srcdata using this size to the output buffer. Applications usually have the output buffer on the stack, hence stack buffer overflow.<br />
<br />
While CTPK(*.ctpk) are normally only loaded from RomFS, some application(s) load from elsewhere too.<br />
| ROP under the target application.<br />
| None?<br />
| "[SDK+NINTENDO:CTR_SDK-11_4_0_200_none]"<br />
| November 14, 2016<br />
| [[User:Yellows8|Yellows8]]<br />
|}</div>Myriahttps://www.3dbrew.org/w/index.php?title=3DS_System_Flaws&diff=207853DS System Flaws2018-08-01T04:33:03Z<p>Myria: /* System flaws */ Moved some Hardware flaws to a new Boot ROM section</p>
<hr />
<div>Exploits are used to execute unofficial code (homebrew) on the Nintendo 3DS. This page is a list of publicly known system flaws, for userland applications/applets flaws see [[3DS_Userland_Flaws|here]].<br />
<br />
=Stale / Rejected Efforts=<br />
* Neimod has been working on a RAM dumping setup for a little while now. He's de-soldered the 3DS's RAM chip and hooked it and the RAM pinouts on the 3DS' PCB up to a custom RAM dumping setup. A while ago he published photos showing his setup to be working quite well, with the 3DS successfully booting up. However, his flickr stream is now private along with most of his work.<br />
<br />
* Someone (who will remain unnamed) has released CFW and CIA installers, all of which is copied from the work of others, or copyrighted material.<br />
<br />
==Tips and info==<br />
The 3DS uses the XN feature of the ARM11 processor. There's no official way from applications to enable executable permission for memory containing arbitrary unsigned code(there's a [[SVC]] for this, but only [[RO_Services|RO-module]] has access to it). A usable userland exploit would still be useful: you could only do return-oriented-programming with it initially. From ROP one could then exploit system flaw(s), see below.<br />
<br />
SD card [[extdata]] and SD savegames can be attacked, for consoles where the console-unique [[Nand/private/movable.sed|movable.sed]] was dumped(accessing SD data is far easier by running code on the target 3DS however).<br />
<br />
=System flaws=<br />
== Hardware ==<br />
{| class="wikitable" border="1"<br />
! Summary<br />
! Description<br />
! Fixed with hardware model/revision<br />
! Newest hardware model/revision this flaw was checked for<br />
! Timeframe this was discovered<br />
! Discovered by<br />
|-<br />
| ARM9/ARM11 bootrom vectors point at uninitialized RAM<br />
| ARM9's and ARM11's exception vectors are hardcoded to point at the CPU's internal memory (0x08000000 region for ARM9, AXIWRAM for ARM11). While the bootrom does set them up to point to an endless loop at some point during boot, it does not do so immediately. As such, a carefully-timed fault injection (via hardware) to trigger an exception (such as an invalid instruction) will cause execution to fall into ARM9 RAM. <br />
Since RAM isn't cleared on boot (see below), one can immediately start execution of their own code here to dump bootrom, OTP, etc.<br />
The ARM9 bootrom does the following at reset: reset vector branches to another instruction, then branches to bootrom+0x8000. Hence, there's no way to know for certain when exactly the ARM9 exception-vector data stored in memory gets initialized.<br />
<br />
This requires *very* *precise* timing for triggering the hardware fault.<br />
<br />
It has been exploited by derrek to dump the ARM9 bootrom as of Summer 2015.<br />
| None: all available 3DS models at the time of writing have the exact same ARM9/ARM11 bootrom for the unprotected areas.<br />
| New3DS<br />
| End of February 2014<br />
| [[User:Derrek|derrek]], WulfyStylez (May 2015) independently<br />
|-<br />
| Missing AES key clearing<br />
| The hardware AES engine does not clear keys when doing a hard reset/reboot.<br />
| None<br />
| New3DS<br />
| August 2014<br />
| Mathieulh/Others<br />
|-<br />
| No RAM clearing on reboots<br />
| On an MCU-triggered reboot all RAM including FCRAM/ARM9 memory/AXIWRAM/VRAM keeps its contents.<br />
| None<br />
| New3DS<br />
| March 2014<br />
| [[User:Derrek|derrek]]<br />
|-<br />
| 32bits of actual console-unique TWLNAND keydata<br />
| On retail the 8-bytes at ARM9 address [[Memory_layout|0x01FFB808]] are XORed with hard-coded data, to generate the TWL console-unique keys, including TWLNAND. On Old3DS the high u32 is always 0x0, while on New3DS that u32 is always 0x2. On top of this, the lower u32's highest bit is always ORed. only 31 bits of the TWL console-unique keydata / TWL consoleID are actually console-unique.<br />
This allows one to easily bruteforce the TWL console-unique keydata with *just* data from TWLNAND. On DSi the actual console-unique data for key generation is 8-bytes(all bytes actually set).<br />
| None<br />
| New3DS<br />
| 2012?<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| DSi / 3DS-TWL key-generator<br />
| After using the key generator to generate the normal-key, you could overwrite parts of the normal-key with your own data and then recover the key-generator output by comparing the new crypto output with the original crypto output. From the normal-key outputs, you could deduce the TWL key-generator function.<br />
This applies to the keyX/keyY too.<br />
<br />
This attack does not work for the 3DS key-generator because keyslots 0-3 are only for TWL keys.<br />
| None<br />
| New3DS<br />
| 2011<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| 3DS key-generator<br />
| The algorithm for generating the normal-keys for keyslots is cryptographically weak. As a result, it is easily susceptible to differential cryptanalysis if the normal-key corresponding to any scrambler-generated keyslot is discovered.<br />
<br />
Several such pairs of matching normal-keys and KeyY values were found, leading to deducing the key-generator function.<br />
| None<br />
| New3DS<br />
| February 2015<br />
| [[User:Yellows8|Yellows8]], [[User:Plutooo|plutoo]]<br />
|-<br />
| RSA keyslots don't clear exponent when setting modulus<br />
| The [[RSA_Registers|RSA keyslots]] are set by boot ROM to have four private RSA keys. The exponent value in the RSA registers is write-only and not readable.<br />
<br />
However, when setting a keyslot's modulus, the RSA hardware leaves the exponent alone. This allows retrieving the exponent by doing a discrete logarithm of the output.<br />
<br />
By setting the modulus to a prime number whose modular multiplicative order is "smooth" (that is, p-1 is divisible by only small prime numbers), discrete logarithms can be calculated quickly using the [[wikipedia:Pohlig-Hellman algorithm|Pohlig-Hellman algorithm]]. If the prime chosen is greater than the modulus, but the same bit size, the discrete logarithm is the private exponent.<br />
<br />
This exploit's usefulness is limited: RSA keyslot 0 is only used in current firmware for deriving the 6.x save and 7.x NCCH keys, which were already known, and the other three keyslots are entirely unused. Additionally, with a boot ROM dump, this exploit is moot; these private keys are located in the protected ARM9 boot ROM.<br />
| None<br />
| New3DS<br />
| March 2016<br />
| [[User:Myria|Myria]]<br />
|-<br />
| [[CONFIG11_Registers#CFG11_GPUPROT|CFG11_GPUPROT]] allowing acccess to AXIWRAM/FCRAM-BASE-memregion<br />
| [[CONFIG11_Registers#CFG11_GPUPROT|CFG11_GPUPROT]] can be configured by anything with access to it to allow the GPU to access the entire AXIWRAM+FCRAM. For example, this is an issue for any sysmodule that gets exploited and has access to this register memory-page(include one that's listed below).<br />
<br />
See also "kernelhax via gspwn" below.<br />
| None<br />
| New3DS<br />
| February 7, 2017<br />
| [[User:Yellows8|Yellows8]]<br />
|}<br />
<br />
== Boot ROM ==<br />
{| class="wikitable" border="1"<br />
! Summary<br />
! Description<br />
! Fixed with hardware model/revision<br />
! Newest hardware model/revision this flaw was checked for<br />
! Timeframe this was discovered<br />
! Discovered by<br />
|-<br />
| FIRM partitions known-plaintext<br />
| The [[Flash_Filesystem|FIRM partitions]] are encrypted with AES-CTR without a MAC. Since this works by XOR'ing data with a static (per-console in this case) keystream, one can deduce the keystream of a portion of each FIRM partition if they have the actual FIRM binary stored in it.<br />
<br />
This can be paired with many exploits. For example, it allows minor FIRM downgrades (i.e. 10.4 to 9.6 or 9.5 to 9.4, but not 9.6 to 9.5).<br />
However it is most commonly used to install arbitrary FIRMs (usually boot9strap), thanks to sighax.<br />
<br />
This can be somewhat addressed by having a FIRM header skip over previously used section offsets, but this would just air-gap newer FIRMs without fixing the core bug. This can also only be done a limited number of times due to the size of FIRM versus the size of the partitions.<br />
| None<br />
| New3DS<br />
| <br />
| Everyone<br />
|-<br />
| Boot9 AES keyinit function issues<br />
| [[Bootloader|Boot9]] seems to have two bugs in the AES key-init function, see [[AES_Registers#AES_key-init|here]].<br />
| None<br />
| BootROM issue.<br />
| 2015<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| sighax: Boot9 improper PKCS #1 v1.5 signature validation<br />
| The [[Flash_Filesystem|FIRM partitions]] are signed with RSA-2048 using SHA-256 and PKCS #1 v1.5 padding. Boot9, however, does improper validation of the padding in three ways:<br />
# Boot9 permits block type 02, meant for encrypted messages, to be used for signatures. Only 01, for signatures, should have been permitted. As a result, a signature block is not required to have a long string of FF bytes as padding, but rather any random values suffice. While correct for encryption, this severely lessens security of signatures.<br />
# Boot9 does not require that the length of the padding fill out the signature block completely. As a result, there is considerable freedom in the layout of a signature.<br />
# Boot9 fails to do bounds checking in its parsing of the DER-encoded hash algorithm type and hash value; the length values given in DER are permitted to point outside the signature block.<br />
Flaw 3 allows the DER encoding to be such that boot9 believes that the signature's hash value is outside the range of the block itself, somewhere on the stack. This can be pointed at the correct hash value it computes. Boot9 then memcmp's the calculated hash against itself, and thinks that the hash is valid.<br />
<br />
When all three flaws are combined, a brute force in a reasonable amount of time can find a signature that passes all checks.<br />
| None<br />
| New3DS<br />
| July 2015<br />
| [[User:Derrek|derrek]]<br />
|-<br />
| Boot9 FIRM loading doesn't blacklist memory-mapped I/O<br />
| [[Bootloader|Boot9]]'s FIRM loading blacklists Boot9 data regions, but forgets to do other important regions, including Memory-mapped I/O. Combined with sighax, by loading a malicious FIRM section to MMIO, one can get Boot9/Boot11 code execution. <br />
| None<br />
| New3DS<br />
| 2015(?)<br />
| [[User:Derrek|derrek]] (2015?), [[User:Normmatt|Normmatt]] and [[User:SciresM|SciresM]] independently (January 2017).<br />
|-<br />
| "superhax": Boot9 FIRM loading blacklist check is flawed<br />
| Boot9 only makes sure the '''start''' and '''end''' address of each section is not covered by a blacklisted region. Thus, it is possible to overwrite blacklisted regions (e.g. ARM9 Exception Vectors) by choosing a FIRM section range that encloses an entire blacklisted region. The vulnerable code looks like this: if(blRegions[i].start <= sectionStart && blRegions[i].end > sectionStart <nowiki>||</nowiki> blRegions[i].start <= sectionEnd && blRegions[i].end > sectionEnd) return false; // failure<br />
| None<br />
| New3DS<br />
| August 2015<br />
| [[User:Plutoo|plutoo]], [[User:Yellows8|yellows8]]<br />
|}<br />
<br />
== ARM9 software ==<br />
<br />
=== arm9loader ===<br />
{| class="wikitable" border="1"<br />
|-<br />
! Summary<br />
! Description<br />
! Successful exploitation result<br />
! Fixed in [[FIRM]] system version<br />
! Last [[FIRM]] system version this flaw was checked for<br />
! Timeframe this was discovered<br />
! Public disclosure timeframe<br />
! Discovered by<br />
|-<br />
| Generating the keysector console-unique keys with ITCM+Boot9<br />
| [[Bootloader|Boot9]] decrypts the 0x100-byte [[OTP_Registers|OTP]] using AES-CBC with keydata stored in Boot9. If hash verification is successful, the plaintext of the first 0x90-bytes are copied into [[Memory_layout|ITCM]]. This is the ''exact'' ''same'' region hashed by arm9loader when generating the console-unique keys for decrypting the keysector, except arm9loader uses the raw encrypted OTP.<br />
<br />
Therefore, with the OTP keydata+IV from Boot9 you can: encrypt the 0x90-bytes from ITCM, then hash the output to get the console-unique keys for the system's keysector. This can even be done for Old3DS which doesn't have the arm9loader keysector officially.<br />
<br />
It's unknown why arm9loader only used the first 0x90-bytes of OTP. Using more data from OTP would've prevented this. Fixing this would require doing exactly that, but that would also mean updating the NAND keysector(which is dangerous).<br />
| See description.<br />
| None<br />
| <br />
| 2015<br />
| January 6, 2017<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| Rearrangable keys in the NAND keystore<br />
| Due to the keystore being encrypted with AES-ECB, one can rearrange blocks and still have the NAND keystore decrypt in a deterministic way. <br />
<br />
Using 10.0 FIRM it is possible to rearrange keys such that ARM9 memory is executed. As such using existing ARM9 execution 10.0 FIRM can be written to NAND and a payload written to memory, with the payload to be executed post-K9L using an MCU reboot.<br />
| arm9loaderhax given existing ARM9 code execution<br />
| None<br />
| [[11.3.0-36|11.3.0-X]]<br />
| Early 2016<br />
| 27 September 2016<br />
| Myria, [[User:Dark samus|dark_samus]]; mathieulh (independently); [[User:Plutooo|plutoo]] (independently) + others<br />
|-<br />
| Uncleared OTP hash keydata in console-unique 0x11 key-generation<br />
| Kernel9Loader does not clear the [[SHA_Registers#SHA_HASH|SHA_HASH register]] after use. As a result, the data stored here as K9L hands over to Kernel9 is the hash of [[OTP_Registers|OTP data]] used to seed the [[FIRM#New_3DS_FIRM|console-unique NAND keystore decryption key]] set on keyslot 0x11.<br />
<br />
Retrieving this keydata and the [[Flash_Filesystem#0x12C00|NAND keystore]] of the same device allows calculating the decrypted New3DS NAND keystore (non-unique, common to all New3DS units), which contains AES normal keys, also set on keyslot 0x11, which are then used to derive all current [[AES_Registers#Keyslots|New3DS-only AES keyXs]] including the newer batch introduced in [[9.6.0-24#arm9loader|9.6.0-X]]. From there, it is trivial to perform the same key derivation in order to initialize those keys on any system version, and even on Old3DS.<br />
<br />
This can be performed by exploiting the "arm9loaderhax" vulnerability to obtain post-K9L code execution after an MCU reboot (the bootrom section-loading fail is not relevant here, this attack was performed without OTP data by brute-forcing keys), and using this to dump the SHA_HASH register. This attack works on any FIRM version shipping a vulnerable version of K9L, whereas OTP dumping required a boot of <[[3.0.0-6|3.0.0-X]].<br />
<br />
This attack results in obtaining the entire (0x200-bytes) NAND keystore - it was confirmed at a later date that this keystore is encrypted with the same key (by comparing the decrypted data from multiple units), and therefore using another key in this store will not remedy the issue as all keys are known (i.e. later, unused keys decrypt to the same 0x200-bytes constant with the same OTP hash). Later keys could have been encrypted differently but this is not the case. As a result of this, it is not possible for Nintendo to use K9L again in its current format for its intended purpose, though this was not news from the moment people dumped a New3DS OTP.<br />
| Derivation of all New3DS keys generated via the NAND keystore (0x1B "Secure4" etc.)<br />
| None<br />
| [[11.3.0-36|11.3.0-X]]<br />
| ~April 2015, implemented in May 2015<br />
| 13 January 2016<br />
| [[User:WulfyStylez|WulfyStylez]], [[User:Dazzozo|Dazzozo]], [[User:Shinyquagsire23|shinyquagsire23]] (complimentary + implemented), [[User:Plutooo|plutoo]], Normmatt (discovered independently)<br />
|-<br />
| enhanced-arm9loaderhax<br />
| See the 32c3 3ds talk.<br />
Since this is a combination of a trick with the arm9-bootrom + arm9loaderhax, and since you have to manually write FIRM to the firm0/firm1 NAND partitions, this can't be completely fixed. Any system with existing ARM9 code execution and an OTP/OTP hash dump can exploit this. Additionally, by using the FIRM partition known-plaintext bug and bruteforcing the second entry in the keystore, this can currently be exploited on all New3DS systems without any other prerequisite hacks.<br />
| arm9loaderhax which automatically occurs at hard-boot.<br />
| See arm9loaderhax / description.<br />
| See arm9loaderhax / description.<br />
| Theorized around mid July, 2015. Later implemented+tested by [[User:Plutooo|plutoo]] and [[User:Derrek|derrek]].<br />
| 32c3 3ds talk (December 27, 2015)<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| Missing verification-block for the 9.6 keys (arm9loaderhax)<br />
| Starting with [[9.6.0-24|9.6.0-X]] a new set of NAND-based keys were introduced. However, no verification block was added to verify that the new key read from NAND is correct. This was technically an issue from [[9.5.0-22|9.5.0-X]] with the original sector+0 keydata, however the below is only possible with [[9.6.0-24|9.6.0-X]] since keyslots 0x15 and 0x16 are generated from different 0x11 keyXs.<br />
<br />
Writing an incorrect key to NAND will cause arm9loader to decrypt the ARM9 kernel as garbage and then jump to it.<br />
<br />
This allows an hardware-based attack where you can boot into an older exploited firmware, fill all memory with NOP sleds/jump-instructions, and then reboot into executing garbage. By automating this process with various input keydata, eventually you'll find some garbage that jumps to your code.<br />
<br />
This gives very early ARM9 code execution (pre-ARM9 kernel). As such, it is possible to dump RSA keyslots with this and calculate the 6.x [[Savegames#6.0.0-11_Savegame_keyY|save]], and 7.x [[NCCH]] keys. This cannot be used to recover keys initialized by arm9loader itself. This is due to it wiping the area used for its stack during NAND sector decryption and keyslot init. <br />
<br />
Due to FIRMs on both Old and New 3DS using the same RSA data, this can be exploited on Old3DS as well, but only if one already has the actual plaintext normalkey from New3DS NAND sector 0x96 offset-0 and has dumped the OTP area of the Old3DS.<br />
| Recovery of 6.x [[Savegames#6.0.0-11_Savegame_keyY|save key]]/7.x [[NCCH]] key, access to uncleared OTP hash keydata<br />
| None<br />
| [[11.3.0-36|11.3.0-X]]<br />
| March, 2015<br />
| <br />
| [[User:Plutooo|plutoo]]<br />
|-<br />
| Uncleared New3DS keyslot 0x11<br />
| Originally the New3DS [[FIRM]] arm9bin loader only cleared keyslot 0x11 when it gets executed at firmlaunch. This was fixed with [[9.5.0-22|9.5.0-X]] by completely clearing keyslot 0x11 immediately after the loader finishes using keyslot 0x11.<br />
This means that any ARM9 code that can execute before the loader clears the keyslot at firmlaunch(including firmlaunch-hax) can get access to the uncleared keyslot 0x11, which then allows one to generate all <=v9.5 New3DS keyXs which are generated by keyslot 0x11.<br />
<br />
Therefore, to completely fix this the loader would have to generate more keys using different keyslot 0x11 keydata. This was done with [[9.6.0-24|9.6.0-X]].<br />
| New3DS keyXs generation<br />
| Mostly fixed with [[9.5.0-22|9.5.0-X]], completely fixed with new keys with [[9.6.0-24|9.6.0-X]].<br />
| <br />
| February 3, 2015 (one day after [[9.5.0-22|9.5.0-X]] release)<br />
| <br />
| [[User:Yellows8|Yellows8]]<br />
|}<br />
<br />
=== Process9 ===<br />
{| class="wikitable" border="1"<br />
|-<br />
! Summary<br />
! Description<br />
! Successful exploitation result<br />
! Fixed in [[FIRM]] system version<br />
! Last [[FIRM]] system version this flaw was checked for<br />
! Timeframe this was discovered<br />
! Public disclosure timeframe<br />
! Discovered by<br />
|-<br />
| Leak of normal-key matching a key-scrambler key<br />
| New 3DS firmware versions [[8.1.0-0 New3DS|8.1.0]] through [[9.2.0-20|9.2.0]] set the encryption key for [[Amiibo]] data using a hardcoded normal-key in Process9. In firmware [[9.3.0-21|9.3.0]], Nintendo "fixed" this by using the key scrambler instead, by calculating the keyY value for keyslot 0x39 that results in the same normal-key, then hardcoding that keyY into Process9.<br />
<br />
Nintendo's fix is actually the problem: Nintendo revealed the normal-key matching an unknown keyX and a known keyY. Combined with the key scrambler using an insecure scrambling algorithm (see "Hardware" above), the key scrambler function could be deduced.<br />
| Deducing the keyX for keyslot 0x39 and the key scrambler algorithm<br />
| New 3DS [[9.3.0-21|9.3.0-X]], sort of<br />
| [[10.0.0-27|10.0.0-X]]<br />
| Sometime in 2015 after the hardware key-generator was broken.<br />
| 32c3 3ds talk (December 27, 2015)<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| Leak of normal-key matching a key-generator key<br />
| During the 3DS' development (June/July 2010) Nintendo added support installing encrypted content ([[CIA]]). Common-key index1 was intended to be a [[AES|hardware generated key]]. However while they added code to generate the key in hardware, they forgot to remove the normal-key for index1 (used elsewhere, likely old debug code). Nintendo later removed the normal key sometime before the first non-prototype firmware release.<br />
<br />
<br />
Knowing the keyY and the normal-key for common-key index1, the devkit key-generator algorithm can be deduced (see "Hardware" above). Additionally the remaining devkit common-keys can be generated once the common-key keyX is recovered.<br />
<br />
Note the devkit key-generator was discovered to be the same as the retail key-generator.<br />
| Deducing the keyX for keyslot 0x3D and hardware key-generator algorithm. Generate remaining devkit common-keys.<br />
| pre-[[1.0.0-0|1.0.0-X]]<br />
| <br />
| Shortly after the key-generator was revealed to be flawed at the 32c3 3ds talk<br />
| January 20, 2016<br />
| [[User:Jakcron|jakcron]]<br />
|-<br />
| Factory firmware is vulnerable to sighax<br />
| During the 3DS's development, presumably boot9 was written (including the sighax) vulnerability. This vulnerability is also present in factory firmware (and earlier, including 0.11). This was fixed in version 1.0.0-0.<br />
| Deducing the mechanics of the sighax vulnerability in boot9 without having boot9 prot. Arm9 code execution on factory/earlier firmware.<br />
| [[1.0.0-0|1.0.0-X]]<br />
| [[1.0.0-0|1.0.0-X]]<br />
| May 9, 2017<br />
| May 19, 2017<br />
| [[User:SciresM|SciresM]], [[User:Myria|Myria]]<br />
|-<br />
| safefirmhax<br />
| SAFE_MODE_FIRM is almost never updated(even when NATIVE_FIRM is updated for vuln fixes), this can be noticed by ''just'' checking 3dbrew/ninupdates title-listings.<br />
<br />
The fix for 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 <=> Kernel11 sync, PXI sync and then repeat the original attack on SAFE_FIRM instead.<br />
| ARM9 code execution<br />
| [[11.3.0-36|11.3.0-X]]<br />
| <br />
| 2012-2013?<br />
| Wiki: January 2, 2017<br />
| Everyone<br />
|-<br />
| safefirmhax 1.1<br />
| Nintendo's original safefirmhax fix was flawed -- they added a global boolean that got set to true whenever a non-sysmodule title got launched (except for a hardcoded repair title id), and panic()'d if that boolean was true to prevent launching safefirm after hax was active. However, because the boolean was initially false after firmlaunch -- With ARM11-kernel execution, one could FIRM-launch into NATIVE_FIRM, and then immediately FIRM-launch again into SAFE_FIRM early in NATIVE_FIRM boot before the boolean got set to true to repeat the safehax attack.<br />
<br />
This was fixed by adding additional CFG9_BOOTENV checks to firmlaunch code in 11.4.<br />
| ARM9 code execution<br />
| [[11.4.0-37|11.4.0-X]]<br />
| <br />
| safefirmhax fix<br />
| Wiki: April 10, 2017<br />
| Everyone<br />
|-<br />
| ntrcardhax<br />
| When reading the banner of a NTR title, Process9 relies on a hardware register to know when the banner was fully read.<br />
However that register is shared between the ARM9 and the ARM11.<br />
An attacker with k11 control can so make Process9 believe the banner continues forever and so trigger a buffer overflow.<br />
With a custom banner for a NTR flashcart, this leads to code execution in Process9.<br />
<br />
This was fixed by adding bound checks on the read data.<br />
| ARM9 code execution<br />
| [[10.4.0-29|10.4.0-X]]<br />
| <br />
| March 2015<br />
| 32c3 3ds talk (December 27, 2015)<br />
| [[User:Plutooo|plutoo]]<br />
|-<br />
| Title downgrading via [[Application_Manager_Services|AM]]([[Application_Manager_Services_PXI|PXI]])<br />
| When a title is *already* installed, Process9 will compare the installed title-version with the title-version being installed. When the one being installed is older, Process9 would return an error.<br />
<br />
However, this can be bypassed by just deleting the title first via the service command(s) for that: with the title removed from the [[Title_Database]], Process9 can't compare the input title-version with anything. Hence, titles can be downgraded this way.<br />
<br />
[[11.0.0-33|11.0.0-X]] fixed this for key system titles (MSET, Home Menu, spider, ErrDisp, SKATER, NATIVE_FIRM, and every retail system module), by checking the version of the title to install against a hard-coded list of (titleID, minimumVersionRequired) pairs.<br />
| Bypassing title version check at installation, which then allows downgrading any title.<br />
| [[11.0.0-33|11.0.0-X]], for key system titles.<br />
| NATIVE_FIRM / AM-sysmodule [[11.0.0-33|11.0.0-X]]<br />
| ?<br />
| <br />
| ?<br />
|-<br />
| FAT FS code null-deref<br />
| When FSFile:Read is used with a file which is corrupted on a FAT filesystem(in particular SD), Process9 can crash. This particular crash is caused by a function returning NULL instead of an actual ptr due to an error. The caller of that function doesn't check for NULL which then triggers a read based at NULL.<br />
<br />
Sample "fsck.vfat -n -v -V <fat image backup>" output for the above crash:<br />
<br />
<pre>...<br />
Starting check/repair pass.<br />
<FilePath0> and<br />
<FilePath1><br />
share clusters.<br />
Truncating second to 3375104 bytes.<br />
<FilePath1><br />
File size is 2787392 bytes, cluster chain length is 16384 bytes.<br />
Truncating file to 16384 bytes.<br />
Checking for unused clusters.<br />
Reclaimed 1 unused cluster (16384 bytes).<br />
Checking free cluster summary.<br />
Free cluster summary wrong (1404490 vs. really 1404491)<br />
Auto-correcting.<br />
Starting verification pass.<br />
Checking for unused clusters.<br />
Leaving filesystem unchanged.</pre><br />
| Useless null-based-read<br />
| None<br />
| [[9.6.0-24|9.6.0-X]]<br />
| July 8-9, 2015<br />
| <br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| RSA signature padding checks<br />
| The TWL_FIRM RSA sig padding check code used for all TWL RSA sig-checks has issues, see [[FIRM|here]].<br />
The main 3DS RSA padding check code(non-certificate, including NATIVE_FIRM) uses the function used with the above to extract more padding + the actual hash from the additional padding. This isn't really a problem here because there's proper padding check code which is executed prior to this.<br />
| <br />
| None<br />
| [[9.5.0-22|9.5.0-X]]<br />
| March 2015<br />
| <br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[AMPXI:ValidateDSiWareSectionMAC]] [[AES_Registers|AES]] keyslot reuse<br />
| When the input DSiWare section index is higher than <max number of DSiWare sections supported by this FIRM>, Process9 uses keyid 0x40 for calculating the AESMAC, which translates to keyslot 0x40. The result is that the keyslot is left at whatever was already selected before, since the AES selectkeyslot code will immediately return when keyslot is >=0x40. However, actually exploiting this is difficult: the calculated AESMAC is never returned, this command just compares the calculated AESMAC with the input AESMAC(result-code depends on whether the AESMACs match). It's unknown whether a timing attack would work with this.<br />
This is basically a different form of the pxips9 keyslot vuln, except with AESMAC etc.<br />
| See description.<br />
| None<br />
| [[11.3.0-36|11.3.0-X]]<br />
| March 15, 2015<br />
| December 29, 2015<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| pxips9 [[AES_Registers|AES]] keyslot reuse<br />
| This requires access to the [[Process_Services|ps:ps]]/pxi:ps9 services. One way to get access to this would be snshax on system-version <=10.1.0-X(see 32c3 3ds talk).<br />
When an invalid key-type value is passed to any of the PS commands, Process9 will try to select keyslot 0x40. That aesengine_setkeyslot() code will then immediately return due to the invalid keyslot value. Since that function doesn't return any errors, Process9 will just continue to do crypto with whatever AES keyslot was selected before the PS command was sent.<br />
| Reusing the previously used keyslot, for crypto with PS.<br />
| None<br />
| [[11.3.0-36|11.3.0-X]]<br />
| Roughly the same time(same day?) as firmlaunch-hax.<br />
| December 29, 2015<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| firmlaunch-hax: FIRM header ToCToU<br />
| This can't be exploited from ARM11 userland.<br />
During [[FIRM]] launch, the only FIRM header the ARM9 uses at all is stored in FCRAM, this is 0x200-bytes(the actual used FIRM RSA signature is read to the Process9 stack however). The ARM9 doesn't expect "anything" besides the ARM9 to access this data.<br />
With [[9.5.0-22]] the address of this FIRM header was changed from a FCRAM address, to ARM9-only address 0x01fffc00.<br />
| ARM9 code execution<br />
| [[9.5.0-22]]<br />
| <br />
| 2012, 3 days after [[User:Yellows8|Yellows8]] started Process9 code RE.<br />
| <br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| Uninitialized data output for (PXI) command replies<br />
| PXI commands for various services(including some [[Filesystem_services_PXI|here]] and many others) can write uninitialized data (like from ARM registers) to the command reply. This happens with stubbed commands, but this can also occur with certain commands when returning an error.<br />
Certain ARM11 service commands have this same issue as well.<br />
| <br />
| None<br />
| [[9.3.0-21|9.3.0-X]]<br />
| ?<br />
| <br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[Filesystem_services_PXI|FSPXI]] OpenArchive SD permissions<br />
| Process9 does not use the exheader ARM9 access-mount permission flag for SD at all.<br />
This would mean ARM11-kernelmode code / fs-module itself could directly use FSPXI to access SD card without ARM9 checking for SD access, but this is rather useless since a process is usually running with SD access(Home Menu for example) anyway.<br />
| <br />
| None<br />
| [[9.3.0-21|9.3.0-X]]<br />
| 2012<br />
| <br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[AMPXI:ExportDSiWare]] export path<br />
| Process9 allocates memory on Process9 heap for the export path then verifies that the actual allocated size matches the input size. Then Process9 copies the input path from FCRAM to this buffer, and uses it with the Process9 FS openfile code, which use paths in the form of "<mountpoint>:/<path>".<br />
Process9 does not check the contents of this path at all before passing it to the FS code, besides writing a NUL-terminator to the end of the buffer.<br />
| Exporting of DSiWare to arbitrary Process9 file-paths, such as "nand:/<path>" etc. This isn't really useful since the data which gets written can't be controlled.<br />
| None<br />
| [[9.5.0-22]]<br />
| April 2013<br />
| <br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[DSiWare_Exports]] [[CTCert]] verification<br />
| Just like DSi originally did, 3DS verifies the APCert for DSiWare on SD with the CTCert also in the DSiWare .bin. On DSi this was fixed with with system-version 1.4.2 by verifying with the actual console-unique cert instead(stored in NAND), while on 3DS it's still not(?) fixed.<br />
On 3DS however this is useless, unless one can obtain the console-unique movable.sed keyY which encrypts the entire DSiWare .bin.<br />
| When the movable.sed keyY for the target 3DS is known and the target 3DS CTCert private-key is unknown, importing of modified DSiWare SD .bin files.<br />
| None.<br />
| 11.6.0-X<br />
| April 2013<br />
| <br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| movable.sed keyY vulnerable to brute-force<br />
| Half of the movable.sed keyY's 128 bits are leaked through the [[Nandrw/sys/LocalFriendCodeSeed_B|LFCS]], which is available in userland and below. The LFCS itself also leaks almost half of the remaining bits by following the ratio: u32 keyY[3]=1/5(LFCS). The remaining keyY[3] uncertainty of about ±2000 can be greatly reduced by plotting expected error margins with several keyYs. This results in a final uncertainty of about 2^40, easily within practical brute force range of an average modern PC.<br />
| Knowing the keyY of a given 3ds allows for modification of DSiWare export contents, and chained with several other public vulns, ultimately arm9 execution.<br />
| None.<br />
| 11.6.0-X<br />
| December 2017<br />
| January 2018<br />
| zoogie<br />
|-<br />
| Improper validation of DSiWare title SRLs<br />
| The 3DS does not verify if the actual SRL embedded in the title's directory matches the titleID in the TMD before launching it or importing it from an sd DSiWare export. <br />
| This allows embedding older, exploitable DSiWare titles in completely different, unexploitable DSiWare titles. Since DSiWare has raw NAND RW, this can result in arm9 control through FIRM known-plaintext and sighax attacks.<br />
| None.<br />
| 11.6.0-X<br />
| 2015?<br />
| December 2016<br />
| Everyone<br />
|-<br />
| [[Gamecard_Services_PXI]] unchecked REG_CTRCARDCNT transfer-size<br />
| The u8 REG_CTRCARDCNT transfer-size parameter for the [[Gamecard_Services_PXI]] read/write CTRCARD commands is used as an index for an array of u16 values. Before [[5.0.0-11|5.0.0-X]] this u8 value wasn't checked, thus out-of-bounds reads could be triggered(which is rather useless in this case).<br />
| Out-of-bounds read for a value which gets written to a register.<br />
| [[5.0.0-11|5.0.0-X]]<br />
| <br />
| 2013?<br />
| <br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[PXI_Registers|PXI]] cmdbuf buffer overrun<br />
| The Process9 code responsible [[PXI_Registers|PXI]] communications didn't verify the size of the incoming command before writing it to a C++ member variable. <br />
| Probably ARM9 code execution<br />
| [[5.0.0-11|5.0.0-11]]<br />
| <br />
| March 2015, original timeframe if any unknown<br />
| <br />
| [[User:Plutooo|plutoo]]/[[User:Yellows8|Yellows8]]/maybe others(?)<br />
|-<br />
| [[Application_Manager_Services_PXI|PXIAM]] command 0x003D0108(See also [[Application_Manager_Services|this]])<br />
| When handling this command, Process9 allocates a 0x2800-byte heap buffer, then copies the 4 FCRAM input buffers to this heap buffer without checking the sizes at all(only the buffers with non-zero sizes are copied). Starting with [[5.0.0-11|5.0.0-X]], the total combined size of the input data must be <=0x2800.<br />
| ARM9 code execution<br />
| [[5.0.0-11|5.0.0-X]]<br />
| <br />
| May 2013<br />
| <br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[Process_Services_PXI|PS RSA]] commands buffer overflows<br />
| pxips9 cmd1(not accessible via ps:ps) and VerifyRsaSha256: unchecked copy to a buffer in Process9's .bss, from the input FCRAM buffer. The buffer is located before the pxi cmdhandler threads' stacks. SignRsaSha256 also has a buf overflow, but this isn't exploitable.<br />
The buffer for this is the buffer for the signature data. With v5.0, the signature buffer was moved to stack, with a check for the signature data size. When the signature data size is too large, Process9 uses [[SVC|svcBreak]].<br />
| ARM9 code execution<br />
| [[5.0.0-11|5.0.0-X]]<br />
| <br />
| 2012<br />
| <br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[PXI_Registers|PXI]] pxi_id bad check<br />
| The Process9 code responsible for [[PXI_Registers|PXI]] communications read pxi_id as a signed char. There were two flaws:<br />
* They used it as index to a lookup-table without checking the value at all.<br />
* Another function verified that pxi_id < 7, allowing negative values to pass the check. This would also cause an out-of-range table-lookup.<br />
| Maybe ARM9 code execution<br />
| [[3.0.0-5|3.0.0-5]]<br />
|<br />
| March 2015, originally 2012 for the first issue at least<br />
| <br />
| [[User:Plutooo|plutoo]], [[User:Yellows8|Yellows8]], maybe others(?)<br />
|}<br />
<br />
=== Kernel9 ===<br />
{| class="wikitable" border="1"<br />
|-<br />
! Summary<br />
! Description<br />
! Successful exploitation result<br />
! Fixed in [[FIRM]] system version<br />
! Last [[FIRM]] system version this flaw was checked for<br />
! Timeframe this was discovered<br />
! Discovered by<br />
|-<br />
| [[CONFIG Registers#CFG_SYSPROT9|CFG_SYSPROT9]] bit1 not set by Kernel9<br />
| Old versions of Kernel9 never set bit1 of [[CONFIG Registers#CFG_SYSPROT9|CFG_SYSPROT9]]. This leaves the [[OTP Registers|0x10012000]]-region unprotected (this region should be locked early during boot!). Since it's never locked, you can dump it once you get ARM9 code execution.<br />
<br />
From [[3.0.0-5|3.0.0-X]] this was fixed by setting the bit in Kernel9 after poking some registers in that region. On New3DS arm9loader sets this bit instead of Kernel9, which is exploitable through a hardware + software vulnerability (see arm9loaderhax / description).<br />
<br />
This flaw resurged when it gained a new practical use: retrieving the OTP data for a New3DS console in order to decrypt the key data used in arm9loader (see enhanced-arm9loaderhax / description). This was performed by downgrading to a vulnerable system version. By accounting for differences in CTR-NAND crypto (0x05 -> 0x04, see partition encryption types [[Flash_Filesystem#NAND_structure|here]]), it is possible to boot a New3DS using Old3DS firmware 1.0-2.X and an Old3DS [[NCSD#NCSD_header|NCSD Header]] to retrieve the required OTP data using this flaw.<br />
| Dumping of the [[OTP Registers|OTP]] area<br />
| [[3.0.0-5|3.0.0-X]]<br />
|<br />
| February 2015<br />
| [[User:Plutooo|plutoo]], Normmatt independently<br />
|}<br />
<br />
== ARM11 software ==<br />
=== Kernel11 ===<br />
{| class="wikitable" border="1"<br />
|-<br />
! Summary<br />
! Description<br />
! Successful exploitation result<br />
! Fixed in [[FIRM]] system version<br />
! Last [[FIRM]] system version this flaw was checked for<br />
! Timeframe this was discovered<br />
! Discovered by<br />
|-<br />
| [[SVC|svcSetProcessIdealProcessor]] reference count overflow and therefore use-after-free.<br />
| The SVC receive two arguments: handle and idealprocessor. The handle is used to get the KProcess object and the KProcess->refCnt gets incremented,later the function check if the KProcess->mem_type != BASE and if yes, it checks for idealprocessor == 2 or idealprocessor != 3. The problem here is that if you pass the idealprocessor = 3 it won't meet any condition and return the error 0xD9001BEA without decrement the reference count. <br />
It can be abused to overflow the KProcess reference count that will lead to an Use-after-free. <br />
| Before [[11.2.0-35|11.2.0-X]]: reference count overflow and therefore use-after-free.<br />
| <br />
| [[11.6.0-39|11.6.0-X]]<br />
| November 2, 2017<br />
| [[User:st4rk|st4rk]]<br />
|-<br />
| [[SVC|svcGetThreadList]] process reference leak<br />
| When given a valid process handle (including <code>0xFFFF8001</code>), svcGetThreadList forgets to decrement the reference count of the underlying [[KProcess]] instance, after having finished using it.<br />
| Before [[11.2.0-35|11.2.0-X]]: reference count overflow and therefore use-after-free, but this UAF was most likely not exploitable<br />
| <br />
| [[11.3.0-36|11.3.0-X]]<br />
| April 3, 2017<br />
| [[User:TuxSH|TuxSH]]<br />
|-<br />
| kernelhax via gspwn<br />
| Originally the kernel didn't initialize [[CONFIG11_Registers#CFG11_GPUPROT|CFG11_GPUPROT]]. Since it's 0 at hard-boot, this allowed the GPU to access the entire FCRAM + AXIWRAM.<br />
| Entire FCRAM+AXIWRAM R/W.<br />
| [[3.0.0-5|3.0.0-X]]<br />
| <br />
| February 7, 2017<br />
| [[User:Plutooo|plutoo]], [[User:Yellows8|Yellows8]] partly<br />
|-<br />
| fasthax<br />
| When a KTimer is created in pulse mode, the kernel calls a virtual function to reset the timer each time it pulses. The scheduler is locked for that core to avoid race conditions, but another core can call CloseHandle on the timer and free it, leading to a UAF vtable call.<br />
| See description.<br />
| [[11.3.0-36|11.3.0-X]]<br />
| [[11.3.0-36|11.3.0-X]]<br />
| May 2016<br />
| nedwill<br />
|-<br />
| ipctakeover<br />
| When sending cmdreplies, it does not validate that the src_addr and src_size match the equivalent dst_addr and dst_size. With a modified addr/size specified in a cmdreply for an output buffer, the data-copy for the first/last pages could be used to overwrite data outside of the buffer specified by the original process.<br />
<br />
Used by ctr-httpwn as of v1.2, for "ipctakeover/bosshaxx".<br />
<br />
This can be used to takeover processes where the process is using your service session. Like HTTPC -> BOSS, for bosshaxx above. NIM takeover can be done too(actual stack buffer overflow can trigger), etc.<br />
| See description.<br />
| None<br />
| [[11.3.0-36|11.3.0-X]]<br />
| November 26, 2016<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| Using IPC input buffers as output buffers<br />
| When sending cmdreplies, it does not validate that the cmdreply descriptor type matches the equivalent cmdreq descriptor type. This could be used by an exploited sysmodule to use what was intended as an input-buffer as an output-buffer, and also combine other IPC vuln(s) with this.<br />
<br />
Used by ctr-httpwn as of v1.2, for "ipctakeover/bosshaxx".<br />
| See description.<br />
| None<br />
| [[11.3.0-36|11.3.0-X]]<br />
| November 2016<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[SVC]] table too small<br />
| The table of function pointers for SVC's only contains entries up to 0x7D, but the biggest allowed SVC for the table is 0x7F. Thus, executing SVC7E or SVC7F would make the SVC-handler read after the buffer, and interpret some ARM instructions as function pointers.<br />
<br />
However, this would require patching the kernel .text or modifying SVC-access-control. Even if you could get these to execute, they would still jump to memory that isn't mapped as executable.<br />
| <br />
| None<br />
| [[11.3.0-36|11.3.0-X]]<br />
| 2012<br />
| Everyone<br />
|-<br />
| [[SVC|svcBackdoor (0x7B)]]<br />
| This backdoor allows executing SVC-mode code at the user-specified code-address. This is used by Process9, using this on the ARM11 (with NATIVE_FIRM) required patching the kernel .text or modifying SVC-access-control.<br />
| See description<br />
| [[11.0.0-33|11.0.0-X]] (deleted)<br />
| <br />
|<br />
| Everyone<br />
|-<br />
| veryslowpidhax<br />
| '''This is completely different from the kernelmode-code-execution vuln described in the below separate entry.'''<br />
<br />
When updating the kernel global PID counter under [[SVC|svcCreateProcess]] the kernel does not check for wraparound to 0x0(the PID for the very first process). This only matters because [[Services|SM-module]] allows processes with PID value less than <total ARM11 FIRM modules> to access ''all'' services, without checking exheader service-access-control; and because Kernel11 checks for the PID to be 1 (loader) to use the input mem-region value on ControlMemory. This alone does not affect access the [[SVC|SVCs]] access table at all.<br />
<br />
Inlined ldrex+strex code is used for updating the above counter. [[11.2.0-35|11.2.0-X]] had changes for similar code, but it was only for dedicated ldrex+strex functions(mainly for kernel objects) and hence this PID code was not affected.<br />
<br />
With launching+terminating a sysmodule repeatedly with this via ns:s, it would take weeks to finish(if not at least about a month?).<br />
| Access to all [[Services_API|services]], ControlMemory on any given mem-region.<br />
| None<br />
| [[11.3.0-36|11.3.0-X]]<br />
| 2012 maybe?<br />
| <br />
|-<br />
| slowhax/waithax<br />
| svcWaitSynchronizationN does not decrement the references to valid handles in an array before returning an error when it encounters an invalid handle. This allows one to (slowly) overflow the reference count for a handle object to zero.<br />
| ARM11 kernel-mode code execution<br />
| [[11.2.0-35|11.2.0-X]]<br />
| [[11.2.0-35|11.2.0-X]]<br />
| 2016<br />
| nedwill, [[User:Derrek|derrek]]<br />
|-<br />
| [[Memory_layout#ARM11_Detailed_virtual_memory_map|0xEFF00000]] / 0xDFF00000 ARM11 kernel virtual-memory<br />
| The ARM11 kernel-mode 0xEFF00000/0xDFF00000 virtual-memory(size 0x100000) is mapped to phys-mem 0x1FF00000(entire DSP-mem + entire AXIWRAM), with permissions RW-. This is used during ARM11 kernel startup for loading the FIRM-modules from the FIRM section located in DSP-mem, this never seems to be used after that, however. This is never unmapped either.<br />
| <br />
| None<br />
| [[11.3.0-36|11.3.0-X]]<br />
| <br />
| <br />
|-<br />
| memchunkhax2.1<br />
| Nintendo's fix for memchunkhax2 in [[10.4.0-29|10.4.0-X]] did not fix the GPU case: one may cause the requisite ToCToU race using gspwn, bypassing the new validation.<br />
derrek's original 32c3 presentation for memchunkhax2 commented that a GPU-based attack was possible, but would be difficult. However, memchunkhax2.1 showed that it was possible to do fairly reliably.<br />
| ARM11 kernel code execution<br />
| [[11.0.0-33|11.0.0-X]], via the new [[Memory_Management#MemoryBlockHeader|memchunkhdr]] MAC which prevents modifying memchunkhdr data with DMA.<br />
| [[11.0.0-33|11.0.0-X]]<br />
|<br />
| [[User:Derrek|derrek]], aliaspider<br />
|-<br />
| memchunkhax2<br />
| When allocating a block of memory, the "next" pointer of the [[Memory_Management#MemoryBlockHeader|memchunkhdr]] is accessed without being checked after being mapped to userland.<br />
This allows a race condition, where the process can change the next pointer just before it's accessed. By pointing the next pointer to a crafted memchunckhdr in the kernel SlabHeap, some of the SlabHeap is allocated to the calling process, allowing to change vtables of kernel objects. <br />
| ARM11 kernel code execution<br />
| [[10.4.0-29|10.4.0-X]] (partially, see memchunkhax2.1)<br />
| [[10.4.0-29|10.4.0-X]]<br />
|<br />
| [[User:Derrek|derrek]]<br />
|-<br />
| heaphax<br />
| Can change the size of free memchunk structures stored in FCRAM using DMA, which leads to the ability to allocate memory chunks over already-allocated memory. This can be used in the SYSTEM region to allocate RW memory over any part of the NS system module, which is enough to take it over.<br />
| Code execution with access to all of NS's privileges. (including downgrading) Code execution within any applet.<br />
| [[11.0.0-33|11.0.0-X]], via the new [[Memory_Management#MemoryBlockHeader|memchunkhdr]] MAC which prevents modifying memchunkhdr data with DMA.<br />
| [[11.0.0-33|11.0.0-X]]<br />
| April 2015 ?<br />
| smea<br />
|-<br />
| snshax<br />
| Can force creation of Safe NS process into gspwn-able memory, allowing for takeover.<br />
| Code execution with access to all of NS's privileges. (including downgrading)<br />
| [[10.1.0-27|10.1.0-X]]<br />
| [[10.1.0-27|10.1.0-X]]<br />
| April 2015 ?<br />
| smea<br />
|-<br />
| AffinityMask/processorid validation<br />
| With [[10.0.0-27|10.0.0-X]] the following functions were updated: svcGetThreadAffinityMask, svcGetProcessAffinityMask, svcSetProcessAffinityMask, and svcCreateThread. The code changes for all but svcCreateThread are identical.<br />
The original code with the first 3 did the following: <br />
* if(u32_processorcount > ~0x80000001)return 0xe0e01bfd;<br />
* if(s32_processorcount > <total_cores>)return 0xd8e007fd;<br />
The following code replaced the above:<br />
* if(u32_processorcount >= <total_cores+1>)return 0xd8e007fd;<br />
In theory the latter should catch everything that the former did, so it's unknown if this was really a security issue.<br />
<br />
The svcCreateThread changes with [[10.0.0-27|10.0.0-X]] definitely did fix a security issue.<br />
* Original code: "if(s32_processorid > <total_cores>)return 0xd8e007fd;"<br />
* New code: "if(s32_processorid >= <total_cores> || s32_processorid <= -4)return 0xd8e007fd;"<br />
This fixed an off-by-one issue: if one would use processorid=total_cores, which isn't actually a valid value, svcCreateThread would accept that value on <[[10.0.0-27|10.0.0-X]]. This results in data being written out-of-bounds(baseaddr = arrayaddr + entrysize*processorid), which has the following result:<br />
* Old3DS: Useless kernel-mode crash due to accessing unmapped memory.<br />
* New3DS: uncontrolled data write into a kernel-mode L1 MMU-table. This isn't really useful: the data can't be controlled, and the data which gets overwritten is all-zero anyway(this isn't anywhere near MMU L1 entries for actually mapped memory).<br />
The previous version also allowed large negative s32_processorid values(negative processorid values are special values not actual procids), but it appears using values like that won't actually do anything(meaning no crash) besides the thread not running / thread not running for a while(besides triggering a kernelpanic with certain s32_processorid value(s)).<br />
| Nothing useful<br />
| [[10.0.0-27|10.0.0-X]]<br />
| [[10.0.0-27|10.0.0-X]]<br />
| svcCreateThread issue: May 31, 2015. The rest: September 8, 2015, via v9.6->v10.0 ARM11-kernel code-diff.<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| memchunkhax<br />
| The kernel originally did not validate the data stored in the FCRAM kernel heap [[Memchunkhdr|memchunk-headers]] for free-memory at all. Exploiting this requires raw R/W access to these memchunk-headers, like physical-memory access with gspwn.<br />
<br />
There are ''multiple'' ways to exploit this, but the end-result for most of these is the same: overwrite code in AXIWRAM via the 0xEFF00000/0xDFF00000 kernel virtual-memory mapping.<br />
<br />
This was fixed in [[9.3.0-21|9.3.0-X]] by checking that the memchunk(including size, next, and prev ptrs) is located within the currently used heap memory. The kernel may also check that the next/prev ptrs are valid compared to other memchunk-headers basically. When any of these checks fail, kernelpanic() is called.<br />
| When combined with other flaws: ARM11-kernelmode code execution<br />
| [[9.3.0-21|9.3.0-21]]<br />
| <br />
| February 2014<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| Multiple [[KLinkedListNode|KLinkedListNode]] SlabHeap use after free bugs<br />
| The ARM11-kernel did access the 'key' field of [[KLinkedListNode|KLinkedListNode]] objects, which are located on the SlabHeap, after freeing them. Thus, triggering an allocation of a new [[KLinkedListNode|KLinkedListNode]] object at the right time could result in a type-confusion. Pseudo-code:<br />
SlabHeap_free(KLinkedListNode);<br />
KObject *obj = KLinkedListNode->key; // the object there might have changed!<br />
This bug appeared all over the place.<br />
| ARM11-kernelmode code exec maybe<br />
| [[8.0.0-18|8.0.0-18]]<br />
| <br />
| April 2015<br />
| [[User:Derrek|derrek]]<br />
|-<br />
| PXI [[RPC_Command_Structure|Command]] input/output buffer permissions<br />
| Originally the ARM11-kernel didn't check permissions for PXI input/output buffers for commands. Starting with [[6.0.0-11|6.0.0]] PXI input/output buffers must have RW permissions, otherwise kernelpanic is triggered.<br />
| <br />
| [[6.0.0-11|6.0.0-11]]<br />
| <br />
| 2012<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[SVC|svcStartInterProcessDma]]<br />
| For svcStartInterProcessDma, the kernel code had the following flaws:<br />
<br />
* Originally the ARM11-kernel read the input DmaConfig structure directly in kernel-mode(ldr(b/h) instructions), without checking whether the DmaConfig address is readable under userland. This was fixed by copying that structure to the SVC-mode stack, using the ldrbt instruction.<br />
<br />
* Integer overflows for srcaddr+size and dstaddr+size are now checked(with [[6.0.0-11]]), which were not checked before.<br />
<br />
* The kernel now also checks whether the srcaddr/dstaddr (+size) is within userland memory (0x20000000), the kernel now (with [[6.0.0-11]]) returns an error when the address is beyond userland memory. Using an address >=0x20000000 would result in the kernel reading from the process L1 MMU table, beyond the memory allocated for that MMU table(for vaddr->physaddr conversion). <br />
| <br />
| [[6.0.0-11]]<br />
| <br />
| DmaConfig issue: unknown. The rest: 2014<br />
| [[User:Plutooo|plutoo]], [[User:Yellows8|Yellows8]] independently<br />
|-<br />
| [[SVC|svcControlMemory]] Parameter checks<br />
| For svcControlMemory the parameter check had these two flaws:<br />
<br />
* The allowed range for addr0, addr1, size parameters depends on which MemoryOperation is being specified. The limitation for GSP heap was only checked if op=(u32)0x10003. By setting a random bit in op that has no meaning (like bit17?), op would instead be (u32)0x30003, and the range-check would be less strict and not accurate. However, the kernel doesn't actually use the input address for LINEAR memory-mapping at all besides the range-checks, so this isn't actually useful. This was fixed in the kernel by just checking for the LINEAR bit, instead of comparing the entire MemoryOperation value with 0x10003.<br />
<br />
* Integer overflows on (addr0+size) are now checked that previously weren't (this also applies to most other address checks elsewhere in the kernel).<br />
<br />
| <br />
| [[5.0.0-11]]<br />
| <br />
|<br />
| [[User:Plutooo|plutoo]]<br />
|-<br />
| [[RPC_Command_Structure|Command]] request/response buffer overflow<br />
| Originally the kernel did not check the word-values from the command-header. Starting with [[5.0.0-11]], the kernel will trigger a kernelpanic() when the total word-size of the entire command(including the cmd-header) is larger than 0x40-words (0x100-bytes). This allows overwriting threadlocalstorage+0x180 in the destination thread. However, since the data written there would be translate parameters (such as header-words + buffer addresses), exploiting this would likely be very difficult, if possible at all.<br />
<br />
If the two words at threadlocalstorage+0x180 could be overwritten with controlled data this way, one could then use a command with a buffer-header of <nowiki>((size<<14) | 2)</nowiki> to write arbitrary memory to any RW userland memory in the destination process.<br />
| <br />
| [[5.0.0-11]]<br />
| <br />
| v4.1 FIRM -> v5.0 code diff<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[SVC|SVC stack allocation overflows]]<br />
| <br />
* Syscalls that allocate a variable-length array on stack, only checked bit31 before multiplying by 4/16 (when calculating how much memory to allocate). If a large integer was passed as input to one of these syscalls, an integer overflow would occur, and too little memory would have been allocated on stack resulting in a buffer overrun. <br />
* The alignment (size+7)&~7 calculation before allocation was not checked for integer overflow.<br />
<br />
This might allow for ARM11 kernel code-execution.<br />
<br />
(Applies to svcSetResourceLimitValues, svcGetThreadList, svcGetProcessList, svcReplyAndReceive, svcWaitSynchronizationN.)<br />
| <br />
| [[5.0.0-11]]<br />
| <br />
| v4.1 FIRM -> v5.0 code diff<br />
| [[User:Plutooo|plutoo]], [[User:Yellows8|Yellows8]] complementary<br />
|-<br />
| [[SVC|svcControlMemory]] MemoryOperation MAP memory-permissions<br />
| svcControlMemory with MemoryOperation=MAP allows mapping the already-mapped process virtual-mem at addr1, to addr0. The lowest address permitted for addr1 is 0x00100000. Originally the ARM11 kernel didn't check memory permissions for addr1. Therefore .text as addr1 could be mapped elsewhere as RW- memory, which allowed ARM11 userland code-execution.<br />
| <br />
| [[4.1.0-8]]<br />
| <br />
| 2012<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[RPC_Command_Structure|Command]] input/output buffer permissions<br />
| Originally the ARM11 kernel didn't check memory permissions for the input/output buffers for commands. Starting with [[4.0.0-7]] the ARM11 kernel will trigger a kernelpanic() if the input/output buffers don't have the required memory permissions. For example, this allowed a FSUSER file-read to .text, which therefore allowed ARM11-userland code execution.<br />
| <br />
| [[4.0.0-7]]<br />
| <br />
| 2012<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[SVC|svcReadProcessMemory/svcWriteProcessMemory memory]] permissions<br />
| Originally the kernel only checked the first page(0x1000-bytes) of the src/dst buffers, for svcReadProcessMemory and svcWriteProcessMemory. There is no known retail processes which have access to these SVCs.<br />
| <br />
| [[4.0.0-7]]<br />
| <br />
| 2012?<br />
| [[User:Yellows8|Yellows8]]<br />
|}<br />
<br />
=== [[FIRM]] Sysmodules ===<br />
{| class="wikitable" border="1"<br />
|-<br />
! Summary<br />
! Description<br />
! Successful exploitation result<br />
! Fixed in [[FIRM]] system version<br />
! Last [[FIRM]] system version this flaw was checked for<br />
! Timeframe this was discovered<br />
! Discovered by<br />
|-<br />
| [[Services|"srv:pm"]] process registration<br />
| Originally any process had access to the port "srv:pm". The PID's used for the (un)registration commands are not checked either. This allowed any process to re-register itself with "srv:pm", and therefore allowed the process to give itself access to any service, bypassing the exheader service-access-control list.<br />
<br />
This was fixed in [[7.0.0-13]]: starting with [[7.0.0-13]] "srv:pm" is now a service instead of a globally accessible port. Only processes with PID's less than 6 (in other words: fs, ldr, sm, pm, pxi modules) have access to it. With [[7.0.0-13]] there can only be one session for "srv:pm" open at a time(this is used by pm module), svcBreak will be executed if more sessions are opened by the processes which can access this.<br />
<br />
This flaw was needed for exploiting the <=v4.x Process9 PXI vulnerabilities from ARM11 userland ROP, since most applications don't have access to those service(s).<br />
| Access to arbitrary services<br />
| [[7.0.0-13]]<br />
| <br />
| 2012<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| FSDIR null-deref<br />
| [[Filesystem_services|FS]]-module may crash in some cases when handling directory reading. The trigger seems to be due to using [[FSDir:Close]] without closing the dir-handle afterwards?(Perhaps this is caused by out-of-memory?) This seems to be useless since it's just a null-deref.<br />
| <br />
| None<br />
| [[9.6.0-24|9.6.0-X]]<br />
| May 19(?)-20, 2015<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[SM]] out-of-bounds BSS write (table 1 entry too small)<br />
| After accepting a new session, [[SM]] writes a (handler ID (0 for srv: sessions (max. 64), 1 for the srv:pm one), pointer to session context structure in BSS) pair in a global array. However that array is only 64-entry-big instead of 65 (as it ought to be), and no bound check is done in that regard.<br />
<br />
Unfortunately, as of [[11.4.0-37]], the overwritten fields are totally unused after their initialization by <code>__libc_init_array</code>.<br />
| Not currently exploitable<br />
| None<br />
| [[11.4.0-37]]<br />
|<br />
|<br />
|}<br />
<br />
=== Standalone Sysmodules ===<br />
{| class="wikitable" border="1"<br />
|-<br />
! Summary<br />
! Description<br />
! Successful exploitation result<br />
! Fixed in system-module system-version<br />
! Last system-module system-version this flaw was checked for<br />
! Timeframe this was discovered<br />
! Timeframe this was added to wiki<br />
! Discovered by<br />
|-<br />
| [[MP:SendDataFrame]] missing input array index validation<br />
| [[MP:SendDataFrame]] doesn't validate the input index at cmdreq[1], unless the function for flag=non-zero is executed. This is used to calculate the following, without validating the index at all: someptr = stateptr + (index*0x924) + somestateoffset.<br />
<br />
After validating some flags from someptr, when input_flag=0 the input buffer data is copied to someptr+someotheroffset+0x14 with the u16 size loaded from someptr+someotheroffset.<br />
<br />
With a large input index someptr could be setup to be at a <target address>, for overwriting memory.<br />
<br />
This is probably difficult to exploit.<br />
| <br />
| None<br />
| [[8.0.0-18]](MP-sysmodule v2048)<br />
| January 22, 2017<br />
| January 22, 2017<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[MP_Services|MP]] cmd1 out-of-bounds handle read<br />
| MP-sysmodule handles the input parameter for cmd1 as a s32. It checks for >=16, but not <0. With <16 it basically does the following(array of entries 4-bytes each): *outhandle = ((Handle*)(stateptr+offsetinstate))[inputindex].<br />
<br />
Hence, this can be used to load any handle in MP-sysmodule memory. MP doesn't really have any service handles of interest however(can be obtained from elsewhere too).<br />
| Reading any handle in MP-sysmodule memory.<br />
| None<br />
| [[8.0.0-18]](MP-sysmodule v2048)<br />
| January 21, 2017<br />
| January 22, 2017<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| AM stack/.bss infoleak via [[AM:ReadTwlBackupInfo]]([[AM:ReadTwlBackupInfoEx|Ex]])<br />
| After writing the output-info structure to stack, it then copies that structure to the output buffer ptr using the size from the command. The size is not checked. This could be used to read data from the AM-service-thread stack handling the command + .bss.<br />
<br />
'''This was not tested on hardware.'''<br />
| Stack/.bss reading<br />
| None<br />
| [[10.0.0-27]](AM v9217)<br />
| Roughly October 17, 2016<br />
| October 25, 2016<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[MVD_Services|MVD]]: Stack buffer overflow with [[MVDSTD:SetupOutputBuffers]].<br />
| The input total_entries is not validated when initially processing the input entry-list. This fixed-size input entry-list is copied to stack from the command request. The loop for processing this initializes a global table, the converted linearmem->physaddrs used there are also copied to stack(0x8-bytes of physaddrs per entry).<br />
<br />
If total_entries is too large, MVD-sysmodule will crash due to reading unmapped memory following the stack(0x10000000). Afterwards if the out-of-bounds total_entries is smaller than that, it will crash due accessing address 0x0, hence this useless.<br />
| MVD-sysmodule crash.<br />
| None<br />
| [[9.0.0-20]]<br />
| April 22, 2016 (Tested on the 25th)<br />
| April 25, 2016<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[NWM_Services|NWM]]: Using CTRSDK heap with UDS sharedmem from the user-process.<br />
| See the HTTP-sysmodule section below.<br />
<br />
CTRSDK heap is used with the sharedmem from [[NWMUDS:InitializeWithVersion]]. Buffers are allocated/freed under this heap using [[NWMUDS:Bind]] and [[NWMUDS:Unbind]].<br />
<br />
Hence, overwriting sharedmem with gspwn then using [[NWMUDS:Unbind]] results in the usual controlled CTRSDK memchunk-header write, similar to HTTP-sysmodule.<br />
<br />
This could be done by creating an UDS network, without any other nodes on the network.<br />
<br />
Besides CTRSDK memchunk-headers, there are no addresses stored under this sharedmem.<br />
| ROP under NWM-module.<br />
| [[11.4.0-37|11.4.0-X]]<br />
| [[9.0.0-20|9.0.0-X]]<br />
| April 10, 2016<br />
| April 16, 2016<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[DLP_Services|DLP]]: Out-of-bounds memory access during spectator [[Download_Play|data-frame]] checksum calculation<br />
| DLP doesn't validate the frame_size when receiving spectator data-frames at all, unlike non-spectator data-frames. The actual spectator data-frame parsing code doesn't use that field either. However, the data-frame checksum calculation code called during checksum verification does use the frame_size for loading the size of the framebuf.<br />
<br />
Hence, using a large frame_size like 0xFFFF will result in the checksum calculation code reading data out-of-bounds. This isn't really useful, you could trigger a remote local-WLAN DLP-sysmodule crash while a 3DS system is scanning for DLP networks(due to accessing unmapped memory), but that's about all(trying to infoleak with this likely isn't useful either).<br />
| DLP-sysmodule crash, handled by dlplay system-application by a "connection interrupted" error eventually then a fatal-error via ErrDisp.<br />
| None<br />
| [[10.0.0-27|10.0.0-X]]<br />
| April 8, 2016 (Tested on the 10th)<br />
| April 10, 2016<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[DLP_Services|DLP]]: Out-of-bounds output data writing during spectator sysupdate titlelist [[Download_Play|data-frame]] handling<br />
| The total_entries and out_entryindex fields for the titlelist DLP spectator data-frames are not validated. This is parsed during DLP network scanning. Hence, the specified titlelist data can be written out-of-bounds using the specified out_entryindex and total_entries. A crash will occur while reading the input data-frame titlelist if total_entries is larger than 0x27A, due to accessing unmapped memory.<br />
<br />
There's not much non-zero data to overwrite following the output buffer(located in sharedmem), any ptrs are located in sharedmem. Overwriting certain ptr(s) are only known to cause a crash when attempting to use the DLP-client shutdown service-command.<br />
<br />
There's no known way to exploit the above crash, since the linked-list code involves writes zeros(with a controlled start ptr).<br />
| <br />
| None<br />
| [[10.0.0-27|10.0.0-X]]<br />
| April 8-9, 2016<br />
| April 10, 2016<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[IR_Services|IR]]: Stack buffer overflow with custom hardware<br />
| Originally IR sysmodule used the read value from the I2C-IR registers TXLVL and RXLVL without validating them at all. See [[10.6.0-31|here]] for the fix. This is the size used for reading the data-recv FIFO, etc. The output buffer for reading is located on the stack.<br />
<br />
This should be exploitable if one could successfully setup the custom hardware for this and if the entire intended sizes actually get read from I2C.<br />
| ROP under IR sysmodule.<br />
| [[10.6.0-31|10.6.0-31]]<br />
| <br />
| February 23, 2016 (Unknown if it was noticed before then)<br />
| February 23, 2016<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[HTTP_Services|HTTP]]: Using CTRSDK heap with sharedmem from the user-process.<br />
| The data from httpcAddPostDataAscii and other commands is stored under a CTRSDK heap. That heap is the sharedmem specified by the user-process via the HTTPC Initialize command.<br />
Normally this sharedmem isn't accessible to the user-process once the sysmodule maps it, hence using it is supposed to be "safe".<br />
<br />
This isn't the case due to gspwn however. Since CTRSDK heap code is so insecure in general, one can use gspwn to locate the HTTPC sharedmem + read/write it, then trigger a mem-write under the sysmodule. This can then be used to get ROP going under HTTP-sysmodule.<br />
<br />
This is exploited by [https://github.com/yellows8/ctr-httpwn/ctr-httpwn ctr-httpwn].<br />
| ROP under HTTP sysmdule.<br />
| [[11.4.0-37|11.4.0-X]]<br />
| [[9.6.0-24|9.6.0-X]] (Latest sysmodule version as of [[10.7.0-32|10.7.0-32]])<br />
| Late 2015<br />
| March 22, 2016<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[NIM_Services|NIM]]: Downloading old title-versions from eShop<br />
| Multiple NIM service commands(such as [[NIMS:StartDownload]]) use a title-version value specified by the user-process, NIM does not validate that this input version matches the latest version available via SOAP. Therefore, when combined with AM(PXI) [[#Process9|title-downgrading]] via deleting the target eShop title with System Settings Data Management(if the title was already installed), this allows downloading+installing any title-version from eShop ''if'' it's still available from CDN.<br />
The easiest way to exploit this is to just patch the eShop system-application code using these NIM commands(ideally the code which loads the title-version).<br />
<br />
Originally this was tested with a debugging-system via modded-FIRM, eventually smea implemented it in HANS for the 32c3 release.<br />
| Downloading old title-versions from eShop<br />
| None<br />
| [[10.0.0-27|10.0.0-X]]<br />
| October 24, 2015 (Unknown when exactly the first eShop title downgrade was actually tested, maybe November)<br />
| January 7, 2016 (Same day Ironfall v1.0 was removed from CDN via the main-CXI files)<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[SPI_Services|SPI]] service out-of-bounds write<br />
| cmd1 has out-of-bounds write allowing overwrite of some static variables in .data.<br />
| <br />
| None<br />
| [[9.5.0-22]]<br />
| March 2015<br />
| <br />
| [[User:Plutooo|plutoo]]<br />
|-<br />
| [[NFC_Services|NFC]] module service command buf-overflows<br />
| NFC module copies data with certain commands, from command input buffers to stack without checking the size. These commands include the following, it's unknown if there's more commands with similar issues: "nfc:dev" <0x000C....> and "nfc:s" <0x0037....>.<br />
Since both of these commands are stubbed in the Old3DS NFC module from the very first version(those just return an error), these issues only affect the New3DS NFC module.<br />
<br />
There's no known retail titles which have access to either of these services.<br />
| ROP under NFC module.<br />
| New3DS: None<br />
| New3DS: [[9.5.0-22]]<br />
| December 2014?<br />
| <br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[News_Services|NEWSS]] service command notificationID validation failure<br />
| This module does not validate the input notificationID for <nowiki>"news:s"</nowiki> service commands. This is an out-of-bounds array index bug. For example, [[NEWSS:SetNotificationHeader]] could be used to exploit news module: this copies the input data(size is properly checked) to: out = newsdb_savedata+0x10 + (someu32array[notificationID]*0x70).<br />
| ROP under news module.<br />
| None<br />
| [[9.7.0-25|9.7.0-X]]<br />
| December 2014<br />
| <br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[NWMUDS:DecryptBeaconData]] heap buffer overflow<br />
| input_size = 0x1E * <value the u8 from input_[[NWM_Services|networkstruct]]+0x1D>. Then input_tag0 is copied to a heap buffer. When input_size is larger than 0xFA-bytes, it will then copy input_tag1 to <end_address_of_previous_outbuf>, with size=input_size-0xFA.<br />
<br />
This can be triggered by either using this command directly, or by boadcasting a wifi beacon which triggers it while a 3DS system running the target process is in range, when the process is scanning for hosts to connect to. Processes will only pass tag data to this command when the wlancommID and other thing(s) match the values for the process.<br />
<br />
There's no known way to actually exploit this for getting ROP under NWM-module, at the time of originally adding this to the wiki. This is because the data which gets copied out-of-bounds *and* actually causes crash(es), can't be controlled it seems(with just broadcasting a beacon at least). It's unknown whether this could be exploited from just using NWMUDS service-cmd(s) directly.<br />
| Without any actual way to exploit this: NWM-module DoS, resulting in process termination(process crash). This breaks *everything* involving wifi comms, a reboot is required to recover from this.<br />
| None<br />
| [[9.0.0-20]]<br />
| ~September 23, 2014(see the [[NWMUDS:DecryptBeaconData]] page history)<br />
| August 3, 2015<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[HID_Services|HID]] module shared-mem<br />
| HID module does not validate the index values in [[HID_Shared_Memory|sharedmem]](just changes index to 0 when index == maxval when updating), therefore large values will result in HID module writing HID data to arbitrary addresses.<br />
| ROP under HID module, but this is *very* unlikely to be exploitable since the data written is HID data.<br />
| None<br />
| [[9.3.0-21]]<br />
| 2014?<br />
| <br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| gspwn<br />
| GSP module does not validate addresses given to the GPU. This allows a user-mode application/applet to read/write to a large part of physical FCRAM using GPU DMA. From this, you can overwrite the .text segment of the application you're running under, and gain real code-execution from a ROP-chain. Normally applets' .text([[Home Menu]], [[Internet Browser]], etc) is located beyond the area accessible by the GPU, except for [[RO_Services|CROs]] used by applets([[Internet Browser]] for example).<br />
<br />
FCRAM is gpu-accessible up to physaddr 0x26800000 on Old3DS, and 0x2D800000 on New3DS. This is BASE_memregion_start(aka SYSTEM_memregion_end)-0x400000 (0x800000 with New3DS) with the default memory-layout on Old3DS/New3DS. With [[11.3.0-36|11.3.0-X]] the cutoff now varies due to the new [[SVC]] 0x59. The New3DS "normal"(non-APPLICATION) cutoff was changed to 0x2D000000 due to the new [[SVC]] 0x59.<br />
| User-mode code execution.<br />
| None<br />
| [[9.6.0-24|9.6.0-X]]<br />
| Early 2014<br />
| <br />
| smea, [[User:Yellows8|Yellows8]]/others before then<br />
|-<br />
| rohax<br />
| Using gspwn, it is possible to overwrite a loaded [[CRO0]]/[[CRR0]] after its RSA-signature has been validated. Badly validated [[CRO0]] header leads to arbitrary read/write of memory in the ro-process. This gives code-execution in the ro module, who has access to [[SVC|syscalls]] 0x70-0x72, 0x7D.<br />
<br />
This was fixed after [[ninjhax]] release by adding checks on [[CRO0]]-based pointers before writing to them.<br />
| Memory-mapping syscalls.<br />
| [[9.3.0-21]]<br />
| [[9.4.0-21]]<br />
| <br />
| <br />
| smea, [[User:Plutooo|plutoo]] joint effort<br />
|-<br />
| Region free<br />
| Only [[Home Menu]] itself checks gamecards' region when launching them. Therefore, any application launch that is done directly with [[NS]] without signaling Home Menu to launch the app, will result in region checks being bypassed.<br />
This essentially means launching the gamecard with the [[NS_and_APT_Services|"ns:s"]] service. The main way to exploit this is to trigger a FIRM launch with an application specified, either with a normal FIRM launch or a hardware [[NSS:RebootSystem|reboot]].<br />
| Launching gamecards from any region + bypassing Home Menu gamecard-sysupdate installation<br />
| None<br />
| Last tested with [[10.1.0-27|10.1.0-X]].<br />
| June(?) 2014<br />
| <br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[NWM_Services|NWM]] service-cmd state null-ptr deref<br />
| The NWMUDS service command code loads a ptr from .data, adds an offset to that, then passes that as the state address for the actual command-handler function. The value of the ptr loaded from .data is not checked, therefore this will cause crashes due to that being 0x0 when NWMUDS was not properly initialized.<br />
It's unknown whether any NWM services besides NWMUDS have this issue.<br />
| This is rather useless since it's only a crash caused by a state ptr based at 0x0.<br />
| None<br />
| [[9.0.0-20]]<br />
| 2013?<br />
| <br />
| [[User:Yellows8|Yellows8]]<br />
|}<br />
<br />
=== General/CTRSDK ===<br />
{| class="wikitable" border="1"<br />
|-<br />
! Summary<br />
! Description<br />
! Successful exploitation result<br />
! Fixed in version<br />
! Last version this flaw was checked for<br />
! Timeframe this was discovered<br />
! Discovered by<br />
|-<br />
| [[NWM_Services|UDS]] beacon additional-data buffer overflow<br />
| Originally CTRSDK did not validate the UDS additional-data size before using that size to copy the additional-data to a [[NWM_Services|networkstruct]]. This was eventually fixed.<br />
This was discovered while doing code RE with an old dlp-module version. It's unknown in what specific CTRSDK version this was fixed, or even what system-version updated titles with a fixed version.<br />
<br />
It's unknown if there's any titles using a vulnerable CTRSDK version which are also exploitable with this(dlp module can't be exploited with this).<br />
<br />
The maximum number of bytes that can be written beyond the end of the outbuf is 0x37-bytes, with additionaldata_size=0xFF.<br />
| Perhaps ROP, very difficult if possible with anything at all<br />
| ?<br />
| <br />
| September(?) 2014<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| CTPK buffer overflow<br />
| At offset 0x20 in CTPK is an array for each texture, each entry is 0x20-bytes. This contains a wordindex(entry+0x18) for some srcdata relative to CTPK+0, and an u8 wordsize(entry+0x14) for this data. The CTRSDK function handling this doesn't validate the size, when copying srcdata using this size to the output buffer. Applications usually have the output buffer on the stack, hence stack buffer overflow.<br />
<br />
While CTPK(*.ctpk) are normally only loaded from RomFS, some application(s) load from elsewhere too.<br />
| ROP under the target application.<br />
| None?<br />
| "[SDK+NINTENDO:CTR_SDK-11_4_0_200_none]"<br />
| November 14, 2016<br />
| [[User:Yellows8|Yellows8]]<br />
|}</div>Myriahttps://www.3dbrew.org/w/index.php?title=System_Font&diff=20644System Font2018-03-11T20:34:48Z<p>Myria: /* Unicode Private Use characters */ grammar fix</p>
<hr />
<div>During system boot, the system-font is loaded by [[NS]] to LINEAR-memory(in the original 0x14000000 vmem region) which always gets allocated at SYSTEM_memregion+0. Due to it being located there, all of this is GPU accessible. The [[BCFNT]] is loaded from the font title for the system region into that memory. During loading, the font-data is modified: the magic-num at fontdata+0 is changed from "CFNT" to "CFNU", and all file offsets are converted to addresses in this allocated linearmem. Processes can get the sharedmem_handle+vaddr for mapping the sharedmem for this via [[NS and APT Services|APT:GetSharedFont]].<br />
<br />
With font-data title-version v0 for USA/EUR/JPN, the size of this entire sharedmem is 0x332000-bytes.<br />
<br />
Shared mem structure:<br />
{| class="wikitable" border="1"<br />
|-<br />
! Offset<br />
! Size<br />
! Description<br />
|-<br />
| 0x0<br />
| 0x80<br />
| Header<br />
|-<br />
| 0x80<br />
| Font data size<br />
| The actual font data.<br />
|-<br />
| 0x80 + Font data size<br />
| 0x332000 - 0x80 - Font data size<br />
| This is leftover data from decompression operation. During the font loading process, compressed data is loaded to <code>sharedmem + 0x332000 - compressed_size_aligned_to_4</code>, and then is decompressed to <code>sharedmem + 0x80</code>. Compressed data at the end that doesn't get overwritten by decompressed data remains in the shared memory<br />
|}<br />
<br />
Header structure:<br />
{| class="wikitable" border="1"<br />
|-<br />
! Offset<br />
! Size<br />
! Description<br />
|-<br />
| 0x0<br />
| 0x4<br />
| Status. <br />
1: loading system font<br />
<br />
2: system font loaded<br />
<br />
3: failed to load system font<br />
|-<br />
| 0x4<br />
| 0x4<br />
| Region. Indicates which [[Title_list#0004009B_-_Shared_Data_Archives|system font archive]] is loaded<br />
1: region JPN/EUR/USA (archive 0004009B00014002)<br />
<br />
2: region CHN (archive 0004009B00014102) <br />
<br />
3: region KOR (archive 0004009B00014202) <br />
<br />
4: region TWN (archive 0004009B00014302)<br />
|-<br />
| 0x8<br />
| 0x4<br />
| Decompressed font data size.<br />
|-<br />
| 0xC<br />
| 0x74<br />
| Normally all-zero?<br />
|}<br />
<br />
==Unicode Private Use characters==<br />
<br />
Some of these characters are used for tutorial message boxes and notifications; they can also be generally used in [[Mii]] names, [[SMDH|application titles]], etc.<br />
<br />
Most of these originated in the "icons" tab of the DS's standard software keyboard, and were extensively used in its firmware UI.<br />
<br />
{|border="1" cellpadding="2" cellspacing="0" style="border-collapse:collapse;"<br />
|-<br />
| colspan="17" style="background:#F8F8F8;text-align:center" | ''Private Use Area''<br />
|----- style="background:#ccf"<br />
!width="4%"|U+!!width="6%"|0!!width="6%"|1!!width="6%"|2!!width="6%"|3!!width="6%"|4!!width="6%"|5!!width="6%"|6!!width="6%"|7!!width="6%"|8!!width="6%"|9!!width="6%"|A!!width="6%"|B!!width="6%"|C!!width="6%"|D!!width="6%"|E!!width="6%"|F<br />
|----- align="center"<br />
!E00x<br />
|A button||B button||X button||Y button||L button||R button||D-pad (unmarked)||DS alarm clock||Boxed emoticon :)||Boxed emoticon >(||Boxed emoticon :O||Boxed emoticon -_-||Sun||Cloud||Umbrella||Snowman<br />
|----- align="center"<br />
!E01x<br />
|Negative boxed exclamation mark||Negative boxed question mark||Envelope||Cell phone||Thickly-boxed + (touch calibration mark)||Spades||Diamonds||Hearts||Flowers||Right arrow||Left arrow||Up arrow||Down arrow||Circled dot (like "your position" in smartphone maps)||Camera||Crossed-out square<br />
|----- align="center"<br />
!E02x<br />
|Spinner up-left||Spinner up||Spinner up-right||Spinner right||Spinner down-right||Spinner down||Spinner down-left||Spinner left||Large cross||Boxed A (Pictochat room)||Boxed B (Pictochat room)||Boxed C (Pictochat room)||Boxed D (Pictochat room)||Negative boxed A (Automatic DS boot)||Negative boxed M (Manual DS boot)||Crossed-out square<br />
|----- align="center"<br />
!E03x<br />
|"P" (Pictochat logo)||"I" (Pictochat logo)||"C" (Pictochat logo)||"T" (Pictochat logo)||"H" (Pictochat logo)||"A" (Pictochat logo)||Crossed-out square||Crossed-out square||Crossed-out square||Crossed-out square||Crossed-out square||Crossed-out square||Crossed-out square||Crossed-out square||Boxed negative X (small letter)||Boxed negative X (big bold letter)<br />
|----- align="center"<br />
!E04x<br />
|Power button (Wiimote)||D-pad (Wiimote)||A button (Wiimote)||B button (Wiimote)||Home button (Wiimote)||Start button (Wiimote)||Select button (Wiimote)||1 button (Wiimote)||2 button (Wiimote)||Analog stick (Nunchuck)||C button (Nunchuck)||Z button (Nunchuck)||a button (Classic)||b button (Classic)||x button (Classic)||y button (Classic)<br />
|----- align="center"<br />
!E05x<br />
|Left analog stick (Classic)||Right analog stick (Classic)||L button (Classic)||R button (Classic)||ZL button (Classic)||ZR button (Classic)||Return (keyboard symbol)||Space (keyboard symbol)||Wii pointer||Wii pointer "1"||Wii pointer "2"||Wii pointer "3"||Wii pointer "4"||Wii pointer dragging||Wii pointer dragging "1"||Wii pointer dragging "2"<br />
|----- align="center"<br />
!E06x<br />
|Wii pointer dragging "3"||Wii pointer dragging "4"||Wii pointer panning||Wii pointer panning "1!||Wii pointer panning "2"||Wii pointer panning "3"||Wii pointer panning "4"||Wii logo||Superscripr "er"||Superscript "re"||Superscript "e"||Negative boxed question mark||nothing||nothing||nothing||nothing<br />
|----- align="center"<br />
!E07x<br />
|Boxed X||Boxed negative X (Close button)||Back||Home||Steps||Play coin||Video camera||Analog stick (3DS)||Power button (O3DS)||D-pad up||D-pad down||D-pad left||D-pad right||D-pad vertical||D-pad horizontal||nothing<br />
|}<br />
<br />
Table courtesy [https://en.wikibooks.org/wiki/Unicode/Character_reference/E000-EFFF Wikibooks]</div>Myriahttps://www.3dbrew.org/w/index.php?title=Serials&diff=20642Serials2018-03-10T20:36:54Z<p>Myria: /* Physical Serial */ Better explanation of -CAN</p>
<hr />
<div>This page talks about the 3DS products' serial number and model number structures (the console, manual, accessories, games, etc...).<br />
<br />
== Console Serial Numbers ==<br />
<br />
A 3DS console serial number is composed of at least two letters followed by nine decimal digits. The ninth digit is a "check digit", meaning that it is derived from the other digits.<br />
<br />
The check digit is an industry-standard algorithm, the one used for UPC codes. To calculate the check digit of a 3DS console, separate the non-check digits into "odd" and "even" groups, where the "odd" group is digits in odd-numbered positions, and the "even" group is digits in even-numbered positions. (The first digit is "odd", with "first" representing "1".)<br />
<br />
After separating the digits, add the digits in each group together. Multiply the sum of the even digits by 3, then add the sum of the odd digits. To calculate the check digit, take this value modulo 10, and if not 0, subtract from 10.<br />
<br />
Example: CW404567772<br />
<br />
The non-check digits are 40456777. Separating into odd and even groups, we get the following:<br />
<br />
Odds: 4 + 4 + 6 + 7 = 21<br />
Evens: 0 + 5 + 7 + 7 = 19<br />
<br />
Applying the algorithm, we get ((3 * 19) + 21) % 10 = 8, which is not 0, thus 10 - 8 = 2, matching the example's check digit.<br />
<br />
The letter prefixes are a letter specifying the device, followed by one letter specifying the region in which it was sold. In some regions, a third letter is present; a current guess is that this letter distinguishes among factories for a given sales region. Note that several different sales regions' console may be considered to be the same region for region-locking purposes, such as Europe and Australia.<br />
<br />
The current serial number scheme began with the DSi, hence its listing in the tables below. Among standalone consoles, the Wii U belongs to this scheme as well; the Switch started a new scheme.<br />
<br />
{| class="wikitable"<br />
! Model !! Device Prefix (Retail) !! Device Prefix (Dev/Test)<br />
|-<br />
| ''DSi'' || T || V<br />
|-<br />
| ''DSi XL/LL'' || W || ''unknown''<br />
|-<br />
| ''Wii U'' || F || ''unknown''<br />
|-<br />
| ''Wii U gamepad'' || J || J<br />
|-<br />
| 3DS || C || E<br />
|-<br />
| 3DS XL/LL || S || R<br />
|-<br />
| 2DS || A || P<br />
|-<br />
| New 3DS || Y || Y<br />
|-<br />
| New 3DS XL/LL || Q || Q<br />
|-<br />
| New 2DS XL/LL || N || N<br />
|}<br />
<br />
Test ("Panda") units with the same prefix as retail can be distinguished by test units having 00 or 01 as the first two digits of the serial number portion. 00 was used with the New 3DS and New 3DS XL for test units; 01 was used with the New 2DS XL test unit. Preview versions of the N2DS XL given out to the press had 01; these appear to have been test units with the development titles deleted.<br />
<br />
Old 3DS development systems (Partner-CTR, IS-CTR-BOX, IS-SPR-BOX) use the "E" and "R" prefixes like test systems, but have 90 (Partner-CTR) or 91 (IS-CTR-BOX, IS-SPR-BOX) as their first two digits. Similarly, the main New 3DS development unit, IS-SNAKE-BOX, uses the Y prefix (same as retail) with 91. It is currently unknown what is the serial number format of the rare New 3DS XL development system (IS-CLOSER-BOX).<br />
<br />
{| class="wikitable"<br />
! Sales Region !! Region Lock !! Region Suffix<br />
|-<br />
| Japan || Japan || JF, JH, JM<br />
|-<br />
| North America || North America || W<br />
|-<br />
| Middle East / Southeast Asia || North America || S<br />
|-<br />
| Europe || Europe || EF, EH, EM<br />
|-<br />
| Australia || Europe || AH, AG<br />
|-<br />
| South Korea || Korea || KF, KH, KM<br />
|-<br />
| China (iQue) || China || CF, CH, CM<br />
|}<br />
<br />
== Console Models ==<br />
<br />
{| class="wikitable"<br />
! Device !! Product Code<br />
|-<br />
| ''DS'' || NTR<br />
|-<br />
| ''DS lite'' || USG<br />
|-<br />
| ''DSi'' || TWL<br />
|-<br />
| ''DSi XL/LL'' || UTL<br />
|-<br />
| ''Wii U'' || WUP<br />
|-<br />
| 3DS || CTR<br />
|-<br />
| 3DS XL/LL || SPR<br />
|-<br />
| 2DS || FTR<br />
|-<br />
| [[New 3DS]] || KTR<br />
|-<br />
| [[New 3DS]] XL/LL || RED<br />
|-<br />
| New 2DS XL/LL || JAN<br />
|}<br />
<br />
The DS had the product code NTR (short for Nitro), so we see the TR is recurring.<br />
<br />
== Title ID and Unique ID ==<br />
''see [[Titles]]''<br />
<br />
== NCCH Product Code ==<br />
<br />
This serial is similiar to the "physical serial" described later in this page; it is the canonical identifier for a specific title in the field of business formalities with Nintendo, but this is not reflected in the 3DS's software architecture (where it is vastly unused in favor of the Title ID: it is therefore considered the successor of the "internal name" contained in ROMs of previous handhelds), is not guaranteed to be unique.<br />
<br />
The product code is located in a [[NCCH]]'s header (not its ExHeader).<br />
<br />
The product code "CTR-P-CTAP" is the default generic product code for NCCH files. Most [[NCSD|NCCHs apart from the first one]] in a title are generally CTR-P-CTAP.<br />
Referring to "the product code of a title" is therefore a simplification for "the product code of the NCCH in its first partition".<br />
<br />
So, for example, a Japanese copy of Ridge Racer 3D would have a product code of "CTR-P-ARRJ" and a serial of "LNA-CTR-ARRJ-JPN".<br />
<br />
A Nintendo-assigned product code follows this format, however, there is no requirement for a product code to match or resemble this structure as long as it's within the length limit:<br />
<br />
[CTR/KTR]-[Category letter]-[Type][Identifier][Region]-[Sub ID]<br />
<br />
{| class="wikitable"<br />
! Category letter !! Description<br />
|-<br />
| P || Cartridge software, or downloadable versions of them.<br />
|-<br />
| N || Digital-only releases, including [[Title list|system applications and applets]].<br />
|-<br />
| M || [[DLC]]<br />
|-<br />
| T || [[eShop Demos]], excluding so-called "special demos" which are category N.<br />
|-<br />
| U || [[Title list#0004000E - Add-on Content (Updates)|Patches]] for category P titles.<br />
|}<br />
<br />
The "sub ID" only applies to DLC, demos, and local copies of Download Play titles. It's a 2-digit number associated with the [[Title list|Title ID Variation]].<br />
<br />
See the next chapter for explanation of the other components of the Product Code.<br />
<br />
== Physical Serial ==<br />
<br />
[Product][Retail/Demo]-CTR-[Type][Identifier][Region]-[Label Region]<br />
<br />
{| class="wikitable"<br />
! Field !! Length !! Description !! colspan=2 | Values<br />
|-<br />
|-align=center<br />
| rowspan="6" | Product<br />
| rowspan="6" | 2<br />
| rowspan="6" | Product type<br />
|-<br />
| LN || Cartridge<br />
|-<br />
| MA || Instruction manual<br />
|-<br />
| TS || Game box<br />
|-<br />
| FA || Leaflet<br />
|-<br />
| MK || Quick-start Guide<br />
|-align=center<br />
| rowspan="3" | Retail/Demo<br />
| rowspan="3" | 1 <br />
| rowspan="3" |<br />
|-<br />
| A || Retail<br />
|-<br />
| Z || Demo<br />
|-align=center<br />
| rowspan="3" | CTR/KTR<br />
| rowspan="3" | 3<br />
| rowspan="3" | Platform<br />
|-<br />
| CTR || 3DS<br />
|-<br />
| KTR || New 3DS<br />
|-align=center<br />
| rowspan="11" | Type<br />
| rowspan="11" | 1<br />
| rowspan="11" | <br />
|-<br />
| A || retail<br />
|-<br />
| B || retail<br />
|-<br />
| C || used for N3DS exclusive retail and default 'CTAP'<br />
|-<br />
| E || used for card 2 type retail cartridges<br />
|-<br />
| H || used for built in applications like [[Mii Maker]]<br />
|-<br />
| J || normal eShop Title<br />
|-<br />
| K || unknown, seen in Mighty Gunvolt<br />
|-<br />
| S || usually a 3D Classics eShop title<br />
|-<br />
| P || used with GBA eShop titles<br />
|-<br />
| T || used with NES eShop titles<br />
|-align=center<br />
| Identifier<br />
| 2<br />
| colspan=3 |Game name (two alphanumeric characters)<br />
|-align=center<br />
| rowspan="10" | Region<br />
| rowspan="10" | 1<br />
| rowspan="10" | <br />
|-<br />
| E || English (US)<br />
|-<br />
| P || PAL (Europe/Australia)<br />
|-<br />
| J || Japanese (Japan)<br />
|-<br />
| K || Korean (Korea)<br />
|-<br />
| C || Chinese (China/Taiwan)<br />
|-<br />
| Y || Multiple regions<br />
|-<br />
| W || Tai'''w'''an(?) (Taiwan/Hong Kong)<br />
|-<br />
| Z || Multiple regions<br />
|-<br />
| A || All (region-free)<br />
|-<br />
|-align=center<br />
| rowspan="12" | Label Region<br />
| rowspan="12" | 3<br />
| rowspan="12" | <br />
|-<br />
| USA || United States<br />
|-<br />
| EUR || Europe<br />
|-<br />
| CAN || Canada (US version with additional French text added to box)<br />
|-<br />
| AUS || Australia<br />
|-<br />
| JPN || Japan<br />
|-<br />
| KOR || Korea<br />
|-<br />
| TWN || Taiwan/Hong Kong<br />
|-<br />
| CHT || Taiwan/Hong Kong ("Chinese-Traditional")<br />
|-<br />
| CHN || China<br />
|-<br />
| UKV || United Kingdom ("United Kingdom version")<br />
|-<br />
| MDE || Saudi Arabia/U.A.E./Malaysia/Singapore ("Middle East")<br />
|}<br />
<br />
=== Electronic Manuals ===<br />
<br />
Some eShop titles have [[NCCH#CFA|Electronic Manuals]] which store the product code at the end of the 'Health & Safety' section of the manual. However, product codes can differ from the above format as shown below:<br />
<br />
CTR-[P/N/T/U]-[Type][Identifier][Region]-[Region]-[Digit]<br />
<br />
CTR-[Type][Identifier][Region]-[Region]-[Digit]<br />
<br />
* P/N/T/U - Same as in product code structure<br />
* [Type][Identifier][Region] - Same as in serial structure<br />
* [Region] - A three character representation of the title region, i.e. 'EUR' (not always present)<br />
* [Digit] - A single digit usually '1' or '0' (not always present). Possibly revision or manual revision.<br />
<br />
'''Note:''' These alternate versions of the product code, potentially found in [[NCCH#CFA|Electronic Manuals]] don't represent the actual product code, as found in the game's CXI. They are only found in the game's Home Menu manual, and on the game's packaging and external labeling.<br />
<br />
==Back of Card Serial==<br />
AREPY10111 (example)<br />
<br />
AAAABCDEEE (presumably)<br/><br />
'''A''' - Identifier (last 4 digits of product code)<br/><br />
'''B''' - Production Month (X,Y,Z -> Oct,Nov,Dec)<br/><br />
'''C''' - Production Year (2010 + C)<br/><br />
'''D''' - Revision<br/><br />
'''E''' - Production Run? (000-999) (*)<br />
<br />
* European demo/kiosk carts say have "08B" as the last three characters with no "Property of Nintendo" label to cover it.</div>Myriahttps://www.3dbrew.org/w/index.php?title=Serials&diff=20641Serials2018-03-10T20:26:56Z<p>Myria: /* Console Serial Numbers */ wii u gamepad; dev units have "JU"</p>
<hr />
<div>This page talks about the 3DS products' serial number and model number structures (the console, manual, accessories, games, etc...).<br />
<br />
== Console Serial Numbers ==<br />
<br />
A 3DS console serial number is composed of at least two letters followed by nine decimal digits. The ninth digit is a "check digit", meaning that it is derived from the other digits.<br />
<br />
The check digit is an industry-standard algorithm, the one used for UPC codes. To calculate the check digit of a 3DS console, separate the non-check digits into "odd" and "even" groups, where the "odd" group is digits in odd-numbered positions, and the "even" group is digits in even-numbered positions. (The first digit is "odd", with "first" representing "1".)<br />
<br />
After separating the digits, add the digits in each group together. Multiply the sum of the even digits by 3, then add the sum of the odd digits. To calculate the check digit, take this value modulo 10, and if not 0, subtract from 10.<br />
<br />
Example: CW404567772<br />
<br />
The non-check digits are 40456777. Separating into odd and even groups, we get the following:<br />
<br />
Odds: 4 + 4 + 6 + 7 = 21<br />
Evens: 0 + 5 + 7 + 7 = 19<br />
<br />
Applying the algorithm, we get ((3 * 19) + 21) % 10 = 8, which is not 0, thus 10 - 8 = 2, matching the example's check digit.<br />
<br />
The letter prefixes are a letter specifying the device, followed by one letter specifying the region in which it was sold. In some regions, a third letter is present; a current guess is that this letter distinguishes among factories for a given sales region. Note that several different sales regions' console may be considered to be the same region for region-locking purposes, such as Europe and Australia.<br />
<br />
The current serial number scheme began with the DSi, hence its listing in the tables below. Among standalone consoles, the Wii U belongs to this scheme as well; the Switch started a new scheme.<br />
<br />
{| class="wikitable"<br />
! Model !! Device Prefix (Retail) !! Device Prefix (Dev/Test)<br />
|-<br />
| ''DSi'' || T || V<br />
|-<br />
| ''DSi XL/LL'' || W || ''unknown''<br />
|-<br />
| ''Wii U'' || F || ''unknown''<br />
|-<br />
| ''Wii U gamepad'' || J || J<br />
|-<br />
| 3DS || C || E<br />
|-<br />
| 3DS XL/LL || S || R<br />
|-<br />
| 2DS || A || P<br />
|-<br />
| New 3DS || Y || Y<br />
|-<br />
| New 3DS XL/LL || Q || Q<br />
|-<br />
| New 2DS XL/LL || N || N<br />
|}<br />
<br />
Test ("Panda") units with the same prefix as retail can be distinguished by test units having 00 or 01 as the first two digits of the serial number portion. 00 was used with the New 3DS and New 3DS XL for test units; 01 was used with the New 2DS XL test unit. Preview versions of the N2DS XL given out to the press had 01; these appear to have been test units with the development titles deleted.<br />
<br />
Old 3DS development systems (Partner-CTR, IS-CTR-BOX, IS-SPR-BOX) use the "E" and "R" prefixes like test systems, but have 90 (Partner-CTR) or 91 (IS-CTR-BOX, IS-SPR-BOX) as their first two digits. Similarly, the main New 3DS development unit, IS-SNAKE-BOX, uses the Y prefix (same as retail) with 91. It is currently unknown what is the serial number format of the rare New 3DS XL development system (IS-CLOSER-BOX).<br />
<br />
{| class="wikitable"<br />
! Sales Region !! Region Lock !! Region Suffix<br />
|-<br />
| Japan || Japan || JF, JH, JM<br />
|-<br />
| North America || North America || W<br />
|-<br />
| Middle East / Southeast Asia || North America || S<br />
|-<br />
| Europe || Europe || EF, EH, EM<br />
|-<br />
| Australia || Europe || AH, AG<br />
|-<br />
| South Korea || Korea || KF, KH, KM<br />
|-<br />
| China (iQue) || China || CF, CH, CM<br />
|}<br />
<br />
== Console Models ==<br />
<br />
{| class="wikitable"<br />
! Device !! Product Code<br />
|-<br />
| ''DS'' || NTR<br />
|-<br />
| ''DS lite'' || USG<br />
|-<br />
| ''DSi'' || TWL<br />
|-<br />
| ''DSi XL/LL'' || UTL<br />
|-<br />
| ''Wii U'' || WUP<br />
|-<br />
| 3DS || CTR<br />
|-<br />
| 3DS XL/LL || SPR<br />
|-<br />
| 2DS || FTR<br />
|-<br />
| [[New 3DS]] || KTR<br />
|-<br />
| [[New 3DS]] XL/LL || RED<br />
|-<br />
| New 2DS XL/LL || JAN<br />
|}<br />
<br />
The DS had the product code NTR (short for Nitro), so we see the TR is recurring.<br />
<br />
== Title ID and Unique ID ==<br />
''see [[Titles]]''<br />
<br />
== NCCH Product Code ==<br />
<br />
This serial is similiar to the "physical serial" described later in this page; it is the canonical identifier for a specific title in the field of business formalities with Nintendo, but this is not reflected in the 3DS's software architecture (where it is vastly unused in favor of the Title ID: it is therefore considered the successor of the "internal name" contained in ROMs of previous handhelds), is not guaranteed to be unique.<br />
<br />
The product code is located in a [[NCCH]]'s header (not its ExHeader).<br />
<br />
The product code "CTR-P-CTAP" is the default generic product code for NCCH files. Most [[NCSD|NCCHs apart from the first one]] in a title are generally CTR-P-CTAP.<br />
Referring to "the product code of a title" is therefore a simplification for "the product code of the NCCH in its first partition".<br />
<br />
So, for example, a Japanese copy of Ridge Racer 3D would have a product code of "CTR-P-ARRJ" and a serial of "LNA-CTR-ARRJ-JPN".<br />
<br />
A Nintendo-assigned product code follows this format, however, there is no requirement for a product code to match or resemble this structure as long as it's within the length limit:<br />
<br />
[CTR/KTR]-[Category letter]-[Type][Identifier][Region]-[Sub ID]<br />
<br />
{| class="wikitable"<br />
! Category letter !! Description<br />
|-<br />
| P || Cartridge software, or downloadable versions of them.<br />
|-<br />
| N || Digital-only releases, including [[Title list|system applications and applets]].<br />
|-<br />
| M || [[DLC]]<br />
|-<br />
| T || [[eShop Demos]], excluding so-called "special demos" which are category N.<br />
|-<br />
| U || [[Title list#0004000E - Add-on Content (Updates)|Patches]] for category P titles.<br />
|}<br />
<br />
The "sub ID" only applies to DLC, demos, and local copies of Download Play titles. It's a 2-digit number associated with the [[Title list|Title ID Variation]].<br />
<br />
See the next chapter for explanation of the other components of the Product Code.<br />
<br />
== Physical Serial ==<br />
<br />
[Product][Retail/Demo]-CTR-[Type][Identifier][Region]-[Label Region]<br />
<br />
{| class="wikitable"<br />
! Field !! Length !! Description !! colspan=2 | Values<br />
|-<br />
|-align=center<br />
| rowspan="6" | Product<br />
| rowspan="6" | 2<br />
| rowspan="6" | Product type<br />
|-<br />
| LN || Cartridge<br />
|-<br />
| MA || Instruction manual<br />
|-<br />
| TS || Game box<br />
|-<br />
| FA || Leaflet<br />
|-<br />
| MK || Quick-start Guide<br />
|-align=center<br />
| rowspan="3" | Retail/Demo<br />
| rowspan="3" | 1 <br />
| rowspan="3" |<br />
|-<br />
| A || Retail<br />
|-<br />
| Z || Demo<br />
|-align=center<br />
| rowspan="3" | CTR/KTR<br />
| rowspan="3" | 3<br />
| rowspan="3" | Platform<br />
|-<br />
| CTR || 3DS<br />
|-<br />
| KTR || New 3DS<br />
|-align=center<br />
| rowspan="11" | Type<br />
| rowspan="11" | 1<br />
| rowspan="11" | <br />
|-<br />
| A || retail<br />
|-<br />
| B || retail<br />
|-<br />
| C || used for N3DS exclusive retail and default 'CTAP'<br />
|-<br />
| E || used for card 2 type retail cartridges<br />
|-<br />
| H || used for built in applications like [[Mii Maker]]<br />
|-<br />
| J || normal eShop Title<br />
|-<br />
| K || unknown, seen in Mighty Gunvolt<br />
|-<br />
| S || usually a 3D Classics eShop title<br />
|-<br />
| P || used with GBA eShop titles<br />
|-<br />
| T || used with NES eShop titles<br />
|-align=center<br />
| Identifier<br />
| 2<br />
| colspan=3 |Game name (two alphanumeric characters)<br />
|-align=center<br />
| rowspan="10" | Region<br />
| rowspan="10" | 1<br />
| rowspan="10" | <br />
|-<br />
| E || English (US)<br />
|-<br />
| P || PAL (Europe/Australia)<br />
|-<br />
| J || Japanese (Japan)<br />
|-<br />
| K || Korean (Korea)<br />
|-<br />
| C || Chinese (China/Taiwan)<br />
|-<br />
| Y || Multiple regions<br />
|-<br />
| W || Tai'''w'''an(?) (Taiwan/Hong Kong)<br />
|-<br />
| Z || Multiple regions<br />
|-<br />
| A || All (region-free)<br />
|-<br />
|-align=center<br />
| rowspan="12" | Label Region<br />
| rowspan="12" | 3<br />
| rowspan="12" | <br />
|-<br />
| USA || United States<br />
|-<br />
| EUR || Europe<br />
|-<br />
| CAN || Canada<br />
|-<br />
| AUS || Australia<br />
|-<br />
| JPN || Japan<br />
|-<br />
| KOR || Korea<br />
|-<br />
| TWN || Taiwan/Hong Kong<br />
|-<br />
| CHT || Taiwan/Hong Kong ("Chinese-Traditional")<br />
|-<br />
| CHN || China<br />
|-<br />
| UKV || United Kingdom ("United Kingdom version")<br />
|-<br />
| MDE || Saudi Arabia/U.A.E./Malaysia/Singapore ("Middle East")<br />
|}<br />
<br />
=== Electronic Manuals ===<br />
<br />
Some eShop titles have [[NCCH#CFA|Electronic Manuals]] which store the product code at the end of the 'Health & Safety' section of the manual. However, product codes can differ from the above format as shown below:<br />
<br />
CTR-[P/N/T/U]-[Type][Identifier][Region]-[Region]-[Digit]<br />
<br />
CTR-[Type][Identifier][Region]-[Region]-[Digit]<br />
<br />
* P/N/T/U - Same as in product code structure<br />
* [Type][Identifier][Region] - Same as in serial structure<br />
* [Region] - A three character representation of the title region, i.e. 'EUR' (not always present)<br />
* [Digit] - A single digit usually '1' or '0' (not always present). Possibly revision or manual revision.<br />
<br />
'''Note:''' These alternate versions of the product code, potentially found in [[NCCH#CFA|Electronic Manuals]] don't represent the actual product code, as found in the game's CXI. They are only found in the game's Home Menu manual, and on the game's packaging and external labeling.<br />
<br />
==Back of Card Serial==<br />
AREPY10111 (example)<br />
<br />
AAAABCDEEE (presumably)<br/><br />
'''A''' - Identifier (last 4 digits of product code)<br/><br />
'''B''' - Production Month (X,Y,Z -> Oct,Nov,Dec)<br/><br />
'''C''' - Production Year (2010 + C)<br/><br />
'''D''' - Revision<br/><br />
'''E''' - Production Run? (000-999) (*)<br />
<br />
* European demo/kiosk carts say have "08B" as the last three characters with no "Property of Nintendo" label to cover it.</div>Myriahttps://www.3dbrew.org/w/index.php?title=Serials&diff=20635Serials2018-03-10T07:26:07Z<p>Myria: /* Back of Card Serial */ 08B = demo/kiosk</p>
<hr />
<div>This page talks about the 3DS products' serial number and model number structures (the console, manual, accessories, games, etc...).<br />
<br />
== Console Serial Numbers ==<br />
<br />
A 3DS console serial number is composed of at least two letters followed by nine decimal digits. The ninth digit is a "check digit", meaning that it is derived from the other digits.<br />
<br />
The check digit is an industry-standard algorithm, the one used for UPC codes. To calculate the check digit of a 3DS console, separate the non-check digits into "odd" and "even" groups, where the "odd" group is digits in odd-numbered positions, and the "even" group is digits in even-numbered positions. (The first digit is "odd", with "first" representing "1".)<br />
<br />
After separating the digits, add the digits in each group together. Multiply the sum of the even digits by 3, then add the sum of the odd digits. To calculate the check digit, take this value modulo 10, and if not 0, subtract from 10.<br />
<br />
Example: CW404567772<br />
<br />
The non-check digits are 40456777. Separating into odd and even groups, we get the following:<br />
<br />
Odds: 4 + 4 + 6 + 7 = 21<br />
Evens: 0 + 5 + 7 + 7 = 19<br />
<br />
Applying the algorithm, we get ((3 * 19) + 21) % 10 = 8, which is not 0, thus 10 - 8 = 2, matching the example's check digit.<br />
<br />
The letter prefixes are a letter specifying the device, followed by one letter specifying the region in which it was sold. In some regions, a third letter is present; a current guess is that this letter distinguishes among factories for a given sales region. Note that several different sales regions' console may be considered to be the same region for region-locking purposes, such as Europe and Australia.<br />
<br />
The current serial number scheme began with the DSi, hence its listing in the tables below. Among standalone consoles, the Wii U belongs to this scheme as well; the Switch started a new scheme.<br />
<br />
{| class="wikitable"<br />
! Model !! Device Prefix (Retail) !! Device Prefix (Dev/Test)<br />
|-<br />
| ''DSi'' || T || V<br />
|-<br />
| ''DSi XL/LL'' || W || ''unknown''<br />
|-<br />
| ''Wii U'' || F || ''unknown''<br />
|-<br />
| 3DS || C || E<br />
|-<br />
| 3DS XL/LL || S || R<br />
|-<br />
| 2DS || A || P<br />
|-<br />
| New 3DS || Y || Y<br />
|-<br />
| New 3DS XL/LL || Q || Q<br />
|-<br />
| New 2DS XL/LL || N || N<br />
|}<br />
<br />
Test ("Panda") units with the same prefix as retail can be distinguished by test units having 00 or 01 as the first two digits of the serial number portion. 00 was used with the New 3DS and New 3DS XL for test units; 01 was used with the New 2DS XL test unit. Preview versions of the N2DS XL given out to the press had 01; these appear to have been test units with the development titles deleted.<br />
<br />
Old 3DS development systems (Partner-CTR, IS-CTR-BOX, IS-SPR-BOX) use the "E" and "R" prefixes like test systems, but have 90 (Partner-CTR) or 91 (IS-CTR-BOX, IS-SPR-BOX) as their first two digits. Similarly, the main New 3DS development unit, IS-SNAKE-BOX, uses the Y prefix (same as retail) with 91. It is currently unknown what is the serial number format of the rare New 3DS XL development system (IS-CLOSER-BOX).<br />
<br />
{| class="wikitable"<br />
! Sales Region !! Region Lock !! Region Suffix<br />
|-<br />
| Japan || Japan || JF, JH, JM<br />
|-<br />
| North America || North America || W<br />
|-<br />
| Middle East / Southeast Asia || North America || S<br />
|-<br />
| Europe || Europe || EF, EH, EM<br />
|-<br />
| Australia || Europe || AH, AG<br />
|-<br />
| South Korea || Korea || KF, KH, KM<br />
|-<br />
| China (iQue) || China || CF, CH, CM<br />
|}<br />
<br />
== Console Models ==<br />
<br />
{| class="wikitable"<br />
! Device !! Product Code<br />
|-<br />
| ''DS'' || NTR<br />
|-<br />
| ''DS lite'' || USG<br />
|-<br />
| ''DSi'' || TWL<br />
|-<br />
| ''DSi XL/LL'' || UTL<br />
|-<br />
| ''Wii U'' || WUP<br />
|-<br />
| 3DS || CTR<br />
|-<br />
| 3DS XL/LL || SPR<br />
|-<br />
| 2DS || FTR<br />
|-<br />
| [[New 3DS]] || KTR<br />
|-<br />
| [[New 3DS]] XL/LL || RED<br />
|-<br />
| New 2DS XL/LL || JAN<br />
|}<br />
<br />
The DS had the product code NTR (short for Nitro), so we see the TR is recurring.<br />
<br />
== Title ID and Unique ID ==<br />
''see [[Titles]]''<br />
<br />
== NCCH Product Code ==<br />
<br />
This serial is similiar to the "physical serial" described later in this page; it is the canonical identifier for a specific title in the field of business formalities with Nintendo, but this is not reflected in the 3DS's software architecture (where it is vastly unused in favor of the Title ID: it is therefore considered the successor of the "internal name" contained in ROMs of previous handhelds), is not guaranteed to be unique.<br />
<br />
The product code is located in a [[NCCH]]'s header (not its ExHeader).<br />
<br />
The product code "CTR-P-CTAP" is the default generic product code for NCCH files. Most [[NCSD|NCCHs apart from the first one]] in a title are generally CTR-P-CTAP.<br />
Referring to "the product code of a title" is therefore a simplification for "the product code of the NCCH in its first partition".<br />
<br />
So, for example, a Japanese copy of Ridge Racer 3D would have a product code of "CTR-P-ARRJ" and a serial of "LNA-CTR-ARRJ-JPN".<br />
<br />
A Nintendo-assigned product code follows this format, however, there is no requirement for a product code to match or resemble this structure as long as it's within the length limit:<br />
<br />
[CTR/KTR]-[Category letter]-[Type][Identifier][Region]-[Sub ID]<br />
<br />
{| class="wikitable"<br />
! Category letter !! Description<br />
|-<br />
| P || Cartridge software, or downloadable versions of them.<br />
|-<br />
| N || Digital-only releases, including [[Title list|system applications and applets]].<br />
|-<br />
| M || [[DLC]]<br />
|-<br />
| T || [[eShop Demos]], excluding so-called "special demos" which are category N.<br />
|-<br />
| U || [[Title list#0004000E - Add-on Content (Updates)|Patches]] for category P titles.<br />
|}<br />
<br />
The "sub ID" only applies to DLC, demos, and local copies of Download Play titles. It's a 2-digit number associated with the [[Title list|Title ID Variation]].<br />
<br />
See the next chapter for explanation of the other components of the Product Code.<br />
<br />
== Physical Serial ==<br />
<br />
[Product][Retail/Demo]-CTR-[Type][Identifier][Region]-[Label Region]<br />
<br />
{| class="wikitable"<br />
! Field !! Length !! Description !! colspan=2 | Values<br />
|-<br />
|-align=center<br />
| rowspan="6" | Product<br />
| rowspan="6" | 2<br />
| rowspan="6" | Product type<br />
|-<br />
| LN || Cartridge<br />
|-<br />
| MA || Instruction manual<br />
|-<br />
| TS || Game box<br />
|-<br />
| FA || Leaflet<br />
|-<br />
| MK || Quick-start Guide<br />
|-align=center<br />
| rowspan="3" | Retail/Demo<br />
| rowspan="3" | 1 <br />
| rowspan="3" |<br />
|-<br />
| A || Retail<br />
|-<br />
| Z || Demo<br />
|-align=center<br />
| rowspan="3" | CTR/KTR<br />
| rowspan="3" | 3<br />
| rowspan="3" | Platform<br />
|-<br />
| CTR || 3DS<br />
|-<br />
| KTR || New 3DS<br />
|-align=center<br />
| rowspan="11" | Type<br />
| rowspan="11" | 1<br />
| rowspan="11" | <br />
|-<br />
| A || retail<br />
|-<br />
| B || retail<br />
|-<br />
| C || used for N3DS exclusive retail and default 'CTAP'<br />
|-<br />
| E || used for card 2 type retail cartridges<br />
|-<br />
| H || used for built in applications like [[Mii Maker]]<br />
|-<br />
| J || normal eShop Title<br />
|-<br />
| K || unknown, seen in Mighty Gunvolt<br />
|-<br />
| S || usually a 3D Classics eShop title<br />
|-<br />
| P || used with GBA eShop titles<br />
|-<br />
| T || used with NES eShop titles<br />
|-align=center<br />
| Identifier<br />
| 2<br />
| colspan=3 |Game name (two alphanumeric characters)<br />
|-align=center<br />
| rowspan="10" | Region<br />
| rowspan="10" | 1<br />
| rowspan="10" | <br />
|-<br />
| E || English (US)<br />
|-<br />
| P || PAL (Europe/Australia)<br />
|-<br />
| J || Japanese (Japan)<br />
|-<br />
| K || Korean (Korea)<br />
|-<br />
| C || Chinese (China/Taiwan)<br />
|-<br />
| Y || Multiple regions<br />
|-<br />
| W || Tai'''w'''an(?) (Taiwan/Hong Kong)<br />
|-<br />
| Z || Multiple regions<br />
|-<br />
| A || All (region-free)<br />
|-<br />
|-align=center<br />
| rowspan="12" | Label Region<br />
| rowspan="12" | 3<br />
| rowspan="12" | <br />
|-<br />
| USA || United States<br />
|-<br />
| EUR || Europe<br />
|-<br />
| CAN || Canada<br />
|-<br />
| AUS || Australia<br />
|-<br />
| JPN || Japan<br />
|-<br />
| KOR || Korea<br />
|-<br />
| TWN || Taiwan/Hong Kong<br />
|-<br />
| CHT || Taiwan/Hong Kong ("Chinese-Traditional")<br />
|-<br />
| CHN || China<br />
|-<br />
| UKV || United Kingdom ("United Kingdom version")<br />
|-<br />
| MDE || Saudi Arabia/U.A.E./Malaysia/Singapore ("Middle East")<br />
|}<br />
<br />
=== Electronic Manuals ===<br />
<br />
Some eShop titles have [[NCCH#CFA|Electronic Manuals]] which store the product code at the end of the 'Health & Safety' section of the manual. However, product codes can differ from the above format as shown below:<br />
<br />
CTR-[P/N/T/U]-[Type][Identifier][Region]-[Region]-[Digit]<br />
<br />
CTR-[Type][Identifier][Region]-[Region]-[Digit]<br />
<br />
* P/N/T/U - Same as in product code structure<br />
* [Type][Identifier][Region] - Same as in serial structure<br />
* [Region] - A three character representation of the title region, i.e. 'EUR' (not always present)<br />
* [Digit] - A single digit usually '1' or '0' (not always present). Possibly revision or manual revision.<br />
<br />
'''Note:''' These alternate versions of the product code, potentially found in [[NCCH#CFA|Electronic Manuals]] don't represent the actual product code, as found in the game's CXI. They are only found in the game's Home Menu manual, and on the game's packaging and external labeling.<br />
<br />
==Back of Card Serial==<br />
AREPY10111 (example)<br />
<br />
AAAABCDEEE (presumably)<br/><br />
'''A''' - Identifier (last 4 digits of product code)<br/><br />
'''B''' - Production Month (X,Y,Z -> Oct,Nov,Dec)<br/><br />
'''C''' - Production Year (2010 + C)<br/><br />
'''D''' - Revision<br/><br />
'''E''' - Production Run? (000-999) (*)<br />
<br />
* European demo/kiosk carts say have "08B" as the last three characters with no "Property of Nintendo" label to cover it.</div>Myriahttps://www.3dbrew.org/w/index.php?title=Nandrw/sys/SecureInfo_A&diff=20625Nandrw/sys/SecureInfo A2018-03-01T04:06:34Z<p>Myria: Dev system updaters have the SecureInfo private key.</p>
<hr />
<div>{{DISPLAYTITLE:Nandrw/sys/SecureInfo_A}}<br />
=SecureInfo format=<br />
{| class="wikitable" border="1"<br />
! Offset<br />
! Size<br />
! Description<br />
|-<br />
| 0x0<br />
| 0x100<br />
| RSA-2048 signature over the following 0x11-bytes.<br />
|-<br />
| 0x100<br />
| 0x1<br />
| Region<br />
|-<br />
| 0x101<br />
| 0x1<br />
| Normally zero<br />
|-<br />
| 0x102<br />
| 0xF<br />
| ASCII serial number, without the [[Serials#Console_Serial_Numbers|check digit]]<br />
|}<br />
<br />
The RSA private key for dev systems is embedded inside the dev system updater package so that the region can be changed.<br />
<br />
=SecureInfo Region Values=<br />
{| class="wikitable" border="1"<br />
! Value<br />
! Description<br />
|-<br />
| 0<br />
| JPN<br />
|-<br />
| 1<br />
| USA<br />
|-<br />
| 2<br />
| EUR<br />
|-<br />
| 3<br />
| AUS(for system-update SOAP at least), unused. The [[NS]] programIDs for the applet AppIDs for this are the same as JPN?<br />
|-<br />
| 4<br />
| CHN<br />
|-<br />
| 5<br />
| KOR<br />
|-<br />
| 6<br />
| TWN<br />
|}<br />
<br />
NIM module uses "AUS" for value3 for SOAP requests, however the server doesn't return a titlelist for that. On AUS 3DS systems this region field is set to EUR instead.<br />
<br />
=See Also=<br />
* [[Config Services]]</div>Myriahttps://www.3dbrew.org/w/index.php?title=Nandrw/sys/SecureInfo_A&diff=20624Nandrw/sys/SecureInfo A2018-03-01T04:03:56Z<p>Myria: SecureInfo doesn't have the serial number check digit.</p>
<hr />
<div>{{DISPLAYTITLE:Nandrw/sys/SecureInfo_A}}<br />
=SecureInfo format=<br />
{| class="wikitable" border="1"<br />
! Offset<br />
! Size<br />
! Description<br />
|-<br />
| 0x0<br />
| 0x100<br />
| RSA-2048 signature over the following 0x11-bytes.<br />
|-<br />
| 0x100<br />
| 0x1<br />
| Region<br />
|-<br />
| 0x101<br />
| 0x1<br />
| Normally zero<br />
|-<br />
| 0x102<br />
| 0xF<br />
| ASCII serial number, without the [[Serials#Console_Serial_Numbers|check digit]]<br />
|}<br />
<br />
=SecureInfo Region Values=<br />
{| class="wikitable" border="1"<br />
! Value<br />
! Description<br />
|-<br />
| 0<br />
| JPN<br />
|-<br />
| 1<br />
| USA<br />
|-<br />
| 2<br />
| EUR<br />
|-<br />
| 3<br />
| AUS(for system-update SOAP at least), unused. The [[NS]] programIDs for the applet AppIDs for this are the same as JPN?<br />
|-<br />
| 4<br />
| CHN<br />
|-<br />
| 5<br />
| KOR<br />
|-<br />
| 6<br />
| TWN<br />
|}<br />
<br />
NIM module uses "AUS" for value3 for SOAP requests, however the server doesn't return a titlelist for that. On AUS 3DS systems this region field is set to EUR instead.<br />
<br />
=See Also=<br />
* [[Config Services]]</div>Myriahttps://www.3dbrew.org/w/index.php?title=Serials&diff=20617Serials2018-02-25T05:57:25Z<p>Myria: /* Physical Serial */ MDE = Middle East, confirmed on my ALBW copy</p>
<hr />
<div>This page talks about the 3DS products' serial number and model number structures (the console, manual, accessories, games, etc...).<br />
<br />
== Console Serial Numbers ==<br />
<br />
A 3DS console serial number is composed of at least two letters followed by nine decimal digits. The ninth digit is a "check digit", meaning that it is derived from the other digits.<br />
<br />
The check digit is an industry-standard algorithm, the one used for UPC codes. To calculate the check digit of a 3DS console, separate the non-check digits into "odd" and "even" groups, where the "odd" group is digits in odd-numbered positions, and the "even" group is digits in even-numbered positions. (The first digit is "odd", with "first" representing "1".)<br />
<br />
After separating the digits, add the digits in each group together. Multiply the sum of the even digits by 3, then add the sum of the odd digits. To calculate the check digit, take this value modulo 10, and if not 0, subtract from 10.<br />
<br />
Example: CW404567772<br />
<br />
The non-check digits are 40456777. Separating into odd and even groups, we get the following:<br />
<br />
Odds: 4 + 4 + 6 + 7 = 21<br />
Evens: 0 + 5 + 7 + 7 = 19<br />
<br />
Applying the algorithm, we get ((3 * 19) + 21) % 10 = 8, which is not 0, thus 10 - 8 = 2, matching the example's check digit.<br />
<br />
The letter prefixes are a letter specifying the device, followed by one letter specifying the region in which it was sold. In some regions, a third letter is present; a current guess is that this letter distinguishes among factories for a given sales region. Note that several different sales regions' console may be considered to be the same region for region-locking purposes, such as Europe and Australia.<br />
<br />
The current serial number scheme began with the DSi, hence its listing in the tables below. Among standalone consoles, the Wii U belongs to this scheme as well; the Switch started a new scheme.<br />
<br />
{| class="wikitable"<br />
! Model !! Device Prefix (Retail) !! Device Prefix (Dev/Test)<br />
|-<br />
| ''DSi'' || T || V<br />
|-<br />
| ''DSi XL/LL'' || W || ''unknown''<br />
|-<br />
| ''Wii U'' || F || ''unknown''<br />
|-<br />
| 3DS || C || E<br />
|-<br />
| 3DS XL/LL || S || R<br />
|-<br />
| 2DS || A || P<br />
|-<br />
| New 3DS || Y || Y<br />
|-<br />
| New 3DS XL/LL || Q || Q<br />
|-<br />
| New 2DS XL/LL || N || N<br />
|}<br />
<br />
Test ("Panda") units with the same prefix as retail can be distinguished by test units having 00 or 01 as the first two digits of the serial number portion. 00 was used with the New 3DS and New 3DS XL for test units; 01 was used with the New 2DS XL test unit. Preview versions of the N2DS XL given out to the press had 01; these appear to have been test units with the development titles deleted.<br />
<br />
Old 3DS development systems (Partner-CTR, IS-CTR-BOX, IS-SPR-BOX) use the "E" and "R" prefixes like test systems, but have 90 (Partner-CTR) or 91 (IS-CTR-BOX, IS-SPR-BOX) as their first two digits. Similarly, the main New 3DS development unit, IS-SNAKE-BOX, uses the Y prefix (same as retail) with 91. It is currently unknown what is the serial number format of the rare New 3DS XL development system (IS-CLOSER-BOX).<br />
<br />
{| class="wikitable"<br />
! Sales Region !! Region Lock !! Region Suffix<br />
|-<br />
| Japan || Japan || JF, JH, JM<br />
|-<br />
| North America || North America || W<br />
|-<br />
| Middle East / Southeast Asia || North America || S<br />
|-<br />
| Europe || Europe || EF, EH, EM<br />
|-<br />
| Australia || Europe || AH, AG<br />
|-<br />
| South Korea || Korea || KF, KH, KM<br />
|-<br />
| China (iQue) || China || CF, CH, CM<br />
|}<br />
<br />
== Console Models ==<br />
<br />
{| class="wikitable"<br />
! Device !! Product Code<br />
|-<br />
| ''DS'' || NTR<br />
|-<br />
| ''DS lite'' || USG<br />
|-<br />
| ''DSi'' || TWL<br />
|-<br />
| ''DSi XL/LL'' || UTL<br />
|-<br />
| ''Wii U'' || WUP<br />
|-<br />
| 3DS || CTR<br />
|-<br />
| 3DS XL/LL || SPR<br />
|-<br />
| 2DS || FTR<br />
|-<br />
| [[New 3DS]] || KTR<br />
|-<br />
| [[New 3DS]] XL/LL || RED<br />
|-<br />
| New 2DS XL/LL || JAN<br />
|}<br />
<br />
The DS had the product code NTR (short for Nitro), so we see the TR is recurring.<br />
<br />
== Title ID and Unique ID ==<br />
''see [[Titles]]''<br />
<br />
== NCCH Product Code ==<br />
<br />
This serial is similiar to the "physical serial" described later in this page; it is the canonical identifier for a specific title in the field of business formalities with Nintendo, but this is not reflected in the 3DS's software architecture (where it is vastly unused in favor of the Title ID: it is therefore considered the successor of the "internal name" contained in ROMs of previous handhelds), is not guaranteed to be unique.<br />
<br />
The product code is located in a [[NCCH]]'s header (not its ExHeader).<br />
<br />
The product code "CTR-P-CTAP" is the default generic product code for NCCH files. Most [[NCSD|NCCHs apart from the first one]] in a title are generally CTR-P-CTAP.<br />
Referring to "the product code of a title" is therefore a simplification for "the product code of the NCCH in its first partition".<br />
<br />
So, for example, a Japanese copy of Ridge Racer 3D would have a product code of "CTR-P-ARRJ" and a serial of "LNA-CTR-ARRJ-JPN".<br />
<br />
A Nintendo-assigned product code follows this format, however, there is no requirement for a product code to match or resemble this structure as long as it's within the length limit:<br />
<br />
[CTR/KTR]-[Category letter]-[Type][Identifier][Region]-[Sub ID]<br />
<br />
{| class="wikitable"<br />
! Category letter !! Description<br />
|-<br />
| P || Cartridge software, or downloadable versions of them.<br />
|-<br />
| N || Digital-only releases, including [[Title list|system applications and applets]].<br />
|-<br />
| M || [[DLC]]<br />
|-<br />
| T || [[eShop Demos]], excluding so-called "special demos" which are category N.<br />
|-<br />
| U || [[Title list#0004000E - Add-on Content (Updates)|Patches]] for category P titles.<br />
|}<br />
<br />
The "sub ID" only applies to DLC, demos, and local copies of Download Play titles. It's a 2-digit number associated with the [[Title list|Title ID Variation]].<br />
<br />
See the next chapter for explanation of the other components of the Product Code.<br />
<br />
== Physical Serial ==<br />
<br />
[Product][Retail/Demo]-CTR-[Type][Identifier][Region]-[Label Region]<br />
<br />
{| class="wikitable"<br />
! Field !! Length !! Description !! colspan=2 | Values<br />
|-<br />
|-align=center<br />
| rowspan="6" | Product<br />
| rowspan="6" | 2<br />
| rowspan="6" | Product type<br />
|-<br />
| LN || Cartridge<br />
|-<br />
| MA || Instruction manual<br />
|-<br />
| TS || Game box<br />
|-<br />
| FA || Leaflet<br />
|-<br />
| MK || Quick-start Guide<br />
|-align=center<br />
| rowspan="3" | Retail/Demo<br />
| rowspan="3" | 1 <br />
| rowspan="3" |<br />
|-<br />
| A || Retail<br />
|-<br />
| Z || Demo<br />
|-align=center<br />
| rowspan="3" | CTR/KTR<br />
| rowspan="3" | 3<br />
| rowspan="3" | Platform<br />
|-<br />
| CTR || 3DS<br />
|-<br />
| KTR || New 3DS<br />
|-align=center<br />
| rowspan="11" | Type<br />
| rowspan="11" | 1<br />
| rowspan="11" | <br />
|-<br />
| A || Retail<br />
|-<br />
| B || <br />
|-<br />
| C || part of the default serial 'CTAP'<br />
|-<br />
| E || <br />
|-<br />
| H || used for built in applications like [[Mii Maker]]<br />
|-<br />
| J || normal eShop Title<br />
|-<br />
| K || unknown, seen in Mighty Gunvolt<br />
|-<br />
| S || usually a 3D Classics eShop title<br />
|-<br />
| P || used with GBA eShop titles<br />
|-<br />
| T || used with NES eShop titles<br />
|-align=center<br />
| Identifier<br />
| 2<br />
| colspan=3 |Game name (two alphanumeric characters)<br />
|-align=center<br />
| rowspan="10" | Region<br />
| rowspan="10" | 1<br />
| rowspan="10" | <br />
|-<br />
| E || English (US)<br />
|-<br />
| P || PAL (Europe/Australia)<br />
|-<br />
| J || Japanese (Japan)<br />
|-<br />
| K || Korean (Korea)<br />
|-<br />
| C || Chinese (China/Taiwan)<br />
|-<br />
| Y || Multiple regions<br />
|-<br />
| W || Tai'''w'''an(?) (Taiwan/Hong Kong)<br />
|-<br />
| Z || Multiple regions<br />
|-<br />
| A || All (region-free)<br />
|-<br />
|-align=center<br />
| rowspan="12" | Label Region<br />
| rowspan="12" | 3<br />
| rowspan="12" | <br />
|-<br />
| USA || United States<br />
|-<br />
| EUR || Europe<br />
|-<br />
| CAN || Canada<br />
|-<br />
| AUS || Australia<br />
|-<br />
| JPN || Japan<br />
|-<br />
| KOR || Korea<br />
|-<br />
| TWN || Taiwan/Hong Kong<br />
|-<br />
| CHT || Taiwan/Hong Kong ("Chinese-Traditional")<br />
|-<br />
| CHN || China<br />
|-<br />
| UKV || United Kingdom ("United Kingdom version")<br />
|-<br />
| MDE || Saudi Arabia/U.A.E./Malaysia/Singapore ("Middle East")<br />
|}<br />
<br />
=== Electronic Manuals ===<br />
<br />
Some eShop titles have [[NCCH#CFA|Electronic Manuals]] which store the product code at the end of the 'Health & Safety' section of the manual. However, product codes can differ from the above format as shown below:<br />
<br />
CTR-[P/N/T/U]-[Type][Identifier][Region]-[Region]-[Digit]<br />
<br />
CTR-[Type][Identifier][Region]-[Region]-[Digit]<br />
<br />
* P/N/T/U - Same as in product code structure<br />
* [Type][Identifier][Region] - Same as in serial structure<br />
* [Region] - A three character representation of the title region, i.e. 'EUR' (not always present)<br />
* [Digit] - A single digit usually '1' or '0' (not always present). Possibly revision or manual revision.<br />
<br />
'''Note:''' These alternate versions of the product code, potentially found in [[NCCH#CFA|Electronic Manuals]] don't represent the actual product code, as found in the game's CXI. They are only found in the game's Home Menu manual, and on the game's packaging and external labeling.<br />
<br />
==Back of Card Serial==<br />
AREPY10111 (example)<br />
<br />
AAAABCDEEE (presumably)<br/><br />
'''A''' - Identifier (last 4 digits of product code)<br/><br />
'''B''' - Production Month (X,Y,Z -> Oct,Nov,Dec)<br/><br />
'''C''' - Production Year (2010 + C)<br/><br />
'''D''' - Revision<br/><br />
'''E''' - Production Run? (000-999)</div>Myriahttps://www.3dbrew.org/w/index.php?title=Nand/private/movable.sed&diff=20608Nand/private/movable.sed2018-02-19T21:27:50Z<p>Myria: punctuation</p>
<hr />
<div>{| class="wikitable" border="1"<br />
! Offset<br />
! Size<br />
! Description<br />
|-<br />
| 0x0<br />
| 0x4<br />
| Magic "SEED"<br />
|-<br />
| 0x4<br />
| 0x4<br />
| When u8[1] is non-zero, this indicates that the additional 0x20-bytes AES-MAC block at the end of movable.sed exists. If u8[1] is zero, then u8 [0], [2], and [3] must be zero as well.<br />
|-<br />
| 0x8<br />
| 0x110<br />
| Copied from [[Nandrw/sys/LocalFriendCodeSeed_B]] (or LocalFriendCodeSeed_A if it exists). The last 8 bytes (LocalFriendCodeSeed) becomes the first 8 bytes of a [[AES]] engine keyY for 3 keyslots<br />
|-<br />
| 0x118<br />
| 0x8<br />
| The higher 8 bytes of the keyY<br />
|-<br />
| 0x120<br />
| 0x20<br />
| This data is written to the file when doing a [[System Settings|System Format]]. The original movable.sed from the factory is only 0x120-bytes. The last 0x10-bytes in this block is an AES-MAC over a SHA256 hash, using the same keyslot used for NAND [[Title_Database|dbs]]. This hash is calculated over the first 0x130-bytes of movable.sed. This AES-MAC is verified is during movable.sed verification(before RSA verification).<br />
|}<br />
<br />
This keyY is the console-unique portion of the 3 keyslots used for everything stored under [[SD Filesystem|sdmc/Nintendo 3DS/<ID0>/<ID1>]] and [[Flash Filesystem|nand/data/<ID0>]]. For SD this is used for encryption and AES MACs, however for NAND this is only used for AES MACs. This file is transferred to the destination 3DS during a [[System Transfer]]. The movable.sed keyY high u64 is [[FS:InitializeCtrFileSystem|updated]] on the source 3DS during a [[System Transfer]], and when doing a system format with [[System Settings]].<br />
<br />
Movable.sed always exists on retail and development units(written to NAND at the factory), however if reading this file fails(svcBreak would be executed if the [[Filesystem_services_PXI|file-read]] code-path return value is 0xC8804464) the system will fall-back to using a console-unique keyY already in [[PSPXI:GetLocalFriendCodeSeed|memory]], with the last 8-bytes being loaded from the 8-bytes following that u64. On development units the code-path handling movable.sed would execute [[SVC|svcBreak]] if file-reading(regardless of error-code) or verifying the RSA signature fails(this would brick the 3DS), RSA verification failure on a retail unit here would also cause a brick.<br />
<br />
The keyY is hashed with SHA256, the first 0x10-bytes from the hash is used with the below snprintf for ID0 in [[SD Filesystem|sdmc/Nintendo 3DS/<ID0>/<ID1>]] and [[Flash Filesystem|nand/data/<ID0>]]. ID0 is generated by: snprintf(outdirname, maxlen, "%08x%08x%08x%08x", hashword[0], hashword[1], hashword[2], hashword[3]). Thus, ID0 is the first half of the SHA-256 of movable.sed bytes 0x110-0x11F inclusive, with the four u32s of the half-SHA-256 byte-flipped.</div>Myriahttps://www.3dbrew.org/w/index.php?title=Nand/private/movable.sed&diff=20607Nand/private/movable.sed2018-02-19T21:25:37Z<p>Myria: Added note that the snprintf implies byte flipping.</p>
<hr />
<div>{| class="wikitable" border="1"<br />
! Offset<br />
! Size<br />
! Description<br />
|-<br />
| 0x0<br />
| 0x4<br />
| Magic "SEED"<br />
|-<br />
| 0x4<br />
| 0x4<br />
| When u8[1] is non-zero, this indicates that the additional 0x20-bytes AES-MAC block at the end of movable.sed exists. If u8[1] is zero, then u8 [0], [2], and [3] must be zero as well.<br />
|-<br />
| 0x8<br />
| 0x110<br />
| Copied from [[Nandrw/sys/LocalFriendCodeSeed_B]] (or LocalFriendCodeSeed_A if it exists). The last 8 bytes (LocalFriendCodeSeed) becomes the first 8 bytes of a [[AES]] engine keyY for 3 keyslots<br />
|-<br />
| 0x118<br />
| 0x8<br />
| The higher 8 bytes of the keyY<br />
|-<br />
| 0x120<br />
| 0x20<br />
| This data is written to the file when doing a [[System Settings|System Format]]. The original movable.sed from the factory is only 0x120-bytes. The last 0x10-bytes in this block is an AES-MAC over a SHA256 hash, using the same keyslot used for NAND [[Title_Database|dbs]]. This hash is calculated over the first 0x130-bytes of movable.sed. This AES-MAC is verified is during movable.sed verification(before RSA verification).<br />
|}<br />
<br />
This keyY is the console-unique portion of the 3 keyslots used for everything stored under [[SD Filesystem|sdmc/Nintendo 3DS/<ID0>/<ID1>]] and [[Flash Filesystem|nand/data/<ID0>]]. For SD this is used for encryption and AES MACs, however for NAND this is only used for AES MACs. This file is transferred to the destination 3DS during a [[System Transfer]]. The movable.sed keyY high u64 is [[FS:InitializeCtrFileSystem|updated]] on the source 3DS during a [[System Transfer]], and when doing a system format with [[System Settings]].<br />
<br />
Movable.sed always exists on retail and development units(written to NAND at the factory), however if reading this file fails(svcBreak would be executed if the [[Filesystem_services_PXI|file-read]] code-path return value is 0xC8804464) the system will fall-back to using a console-unique keyY already in [[PSPXI:GetLocalFriendCodeSeed|memory]], with the last 8-bytes being loaded from the 8-bytes following that u64. On development units the code-path handling movable.sed would execute [[SVC|svcBreak]] if file-reading(regardless of error-code) or verifying the RSA signature fails(this would brick the 3DS), RSA verification failure on a retail unit here would also cause a brick.<br />
<br />
The keyY is hashed with SHA256, the first 0x10-bytes from the hash is used with the below snprintf for ID0 in [[SD Filesystem|sdmc/Nintendo 3DS/<ID0>/<ID1>]] and [[Flash Filesystem|nand/data/<ID0>]]. ID0 is generated by: snprintf(outdirname, maxlen, "%08x%08x%08x%08x", hashword[0], hashword[1], hashword[2], hashword[3]). Thus, ID0 is the first half of the SHA-256 of movable.sed bytes 0x110-0x11F inclusive with the four u32s of the half-SHA-256 byte-flipped.</div>Myriahttps://www.3dbrew.org/w/index.php?title=3DS_System_Flaws&diff=206063DS System Flaws2018-02-19T21:00:03Z<p>Myria: /* Process9 */ Made "LFCS" into a link as a clarification</p>
<hr />
<div>Exploits are used to execute unofficial code (homebrew) on the Nintendo 3DS. This page is a list of publicly known system flaws, for userland applications/applets flaws see [[3DS_Userland_Flaws|here]].<br />
<br />
=Stale / Rejected Efforts=<br />
* Neimod has been working on a RAM dumping setup for a little while now. He's de-soldered the 3DS's RAM chip and hooked it and the RAM pinouts on the 3DS' PCB up to a custom RAM dumping setup. A while ago he published photos showing his setup to be working quite well, with the 3DS successfully booting up. However, his flickr stream is now private along with most of his work.<br />
<br />
* Someone (who will remain unnamed) has released CFW and CIA installers, all of which is copied from the work of others, or copyrighted material.<br />
<br />
==Tips and info==<br />
The 3DS uses the XN feature of the ARM11 processor. There's no official way from applications to enable executable permission for memory containing arbitrary unsigned code(there's a [[SVC]] for this, but only [[RO_Services|RO-module]] has access to it). A usable userland exploit would still be useful: you could only do return-oriented-programming with it initially. From ROP one could then exploit system flaw(s), see below.<br />
<br />
SD card [[extdata]] and SD savegames can be attacked, for consoles where the console-unique [[Nand/private/movable.sed|movable.sed]] was dumped(accessing SD data is far easier by running code on the target 3DS however).<br />
<br />
=System flaws=<br />
== Hardware ==<br />
{| class="wikitable" border="1"<br />
! Summary<br />
! Description<br />
! Fixed with hardware model/revision<br />
! Newest hardware model/revision this flaw was checked for<br />
! Timeframe this was discovered<br />
! Discovered by<br />
|-<br />
| ARM9/ARM11 bootrom vectors point at uninitialized RAM<br />
| ARM9's and ARM11's exception vectors are hardcoded to point at the CPU's internal memory (0x08000000 region for ARM9, AXIWRAM for ARM11). While the bootrom does set them up to point to an endless loop at some point during boot, it does not do so immediately. As such, a carefully-timed fault injection (via hardware) to trigger an exception (such as an invalid instruction) will cause execution to fall into ARM9 RAM. <br />
Since RAM isn't cleared on boot (see below), one can immediately start execution of their own code here to dump bootrom, OTP, etc.<br />
The ARM9 bootrom does the following at reset: reset vector branches to another instruction, then branches to bootrom+0x8000. Hence, there's no way to know for certain when exactly the ARM9 exception-vector data stored in memory gets initialized.<br />
<br />
This requires *very* *precise* timing for triggering the hardware fault.<br />
<br />
It has been exploited by derrek to dump the ARM9 bootrom as of Summer 2015.<br />
| None: all available 3DS models at the time of writing have the exact same ARM9/ARM11 bootrom for the unprotected areas.<br />
| New3DS<br />
| End of February 2014<br />
| [[User:Derrek|derrek]], WulfyStylez (May 2015) independently<br />
|-<br />
| Missing AES key clearing<br />
| The hardware AES engine does not clear keys when doing a hard reset/reboot.<br />
| None<br />
| New3DS<br />
| August 2014<br />
| Mathieulh/Others<br />
|-<br />
| No RAM clearing on reboots<br />
| On an MCU-triggered reboot all RAM including FCRAM/ARM9 memory/AXIWRAM/VRAM keeps its contents.<br />
| None<br />
| New3DS<br />
| March 2014<br />
| [[User:Derrek|derrek]]<br />
|-<br />
| 32bits of actual console-unique TWLNAND keydata<br />
| On retail the 8-bytes at ARM9 address [[Memory_layout|0x01FFB808]] are XORed with hard-coded data, to generate the TWL console-unique keys, including TWLNAND. On Old3DS the high u32 is always 0x0, while on New3DS that u32 is always 0x2. On top of this, the lower u32's highest bit is always ORed. only 31 bits of the TWL console-unique keydata / TWL consoleID are actually console-unique.<br />
This allows one to easily bruteforce the TWL console-unique keydata with *just* data from TWLNAND. On DSi the actual console-unique data for key generation is 8-bytes(all bytes actually set).<br />
| None<br />
| New3DS<br />
| 2012?<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| DSi / 3DS-TWL key-generator<br />
| After using the key generator to generate the normal-key, you could overwrite parts of the normal-key with your own data and then recover the key-generator output by comparing the new crypto output with the original crypto output. From the normal-key outputs, you could deduce the TWL key-generator function.<br />
This applies to the keyX/keyY too.<br />
<br />
This attack does not work for the 3DS key-generator because keyslots 0-3 are only for TWL keys.<br />
| None<br />
| New3DS<br />
| 2011<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| 3DS key-generator<br />
| The algorithm for generating the normal-keys for keyslots is cryptographically weak. As a result, it is easily susceptible to differential cryptanalysis if the normal-key corresponding to any scrambler-generated keyslot is discovered.<br />
<br />
Several such pairs of matching normal-keys and KeyY values were found, leading to deducing the key-generator function.<br />
| None<br />
| New3DS<br />
| February 2015<br />
| [[User:Yellows8|Yellows8]], [[User:Plutooo|plutoo]]<br />
|-<br />
| FIRM partitions known-plaintext<br />
| The [[Flash_Filesystem|FIRM partitions]] are encrypted with AES-CTR without a MAC. Since this works by XOR'ing data with a static (per-console in this case) keystream, one can deduce the keystream of a portion of each FIRM partition if they have the actual FIRM binary stored in it.<br />
<br />
This can be paired with many exploits. For example, it allows minor FIRM downgrades (i.e. 10.4 to 9.6 or 9.5 to 9.4, but not 9.6 to 9.5).<br />
<br />
This can be somewhat addressed by having a FIRM header skip over previously used section offsets, but this would just air-gap newer FIRMs without fixing the core bug. This can also only be done a limited number of times due to the size of FIRM versus the size of the partitions.<br />
| None<br />
| New3DS<br />
| <br />
| Everyone<br />
|-<br />
| RSA keyslots don't clear exponent when setting modulus<br />
| The [[RSA_Registers|RSA keyslots]] are set by boot ROM to have four private RSA keys. The exponent value in the RSA registers is write-only and not readable.<br />
<br />
However, when setting a keyslot's modulus, the RSA hardware leaves the exponent alone. This allows retrieving the exponent by doing a discrete logarithm of the output.<br />
<br />
By setting the modulus to a prime number whose modular multiplicative order is "smooth" (that is, p-1 is divisible by only small prime numbers), discrete logarithms can be calculated quickly using the [[wikipedia:Pohlig-Hellman algorithm|Pohlig-Hellman algorithm]]. If the prime chosen is greater than the modulus, but the same bit size, the discrete logarithm is the private exponent.<br />
<br />
This exploit's usefulness is limited: RSA keyslot 0 is only used in current firmware for deriving the 6.x save and 7.x NCCH keys, which were already known, and the other three keyslots are entirely unused. Additionally, with a boot ROM dump, this exploit is moot; these private keys are located in the protected ARM9 boot ROM.<br />
| None<br />
| New3DS<br />
| March 2016<br />
| [[User:Myria|Myria]]<br />
|-<br />
| Boot9 AES keyinit function issues<br />
| [[Bootloader|Boot9]] seems to have two bugs in the AES key-init function, see [[AES_Registers#AES_key-init|here]].<br />
| None<br />
| BootROM issue.<br />
| 2015<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[CONFIG11_Registers#CFG11_GPUPROT|CFG11_GPUPROT]] allowing acccess to AXIWRAM/FCRAM-BASE-memregion<br />
| [[CONFIG11_Registers#CFG11_GPUPROT|CFG11_GPUPROT]] can be configured by anything with access to it to allow the GPU to access the entire AXIWRAM+FCRAM. For example, this is an issue for any sysmodule that gets exploited and has access to this register memory-page(include one that's listed below).<br />
<br />
See also "kernelhax via gspwn" below.<br />
| None<br />
| New3DS<br />
| February 7, 2017<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| sighax: Boot9 improper PKCS #1 v1.5 signature validation<br />
| The [[Flash_Filesystem|FIRM partitions]] are signed with RSA-2048 using SHA-256 and PKCS #1 v1.5 padding. Boot9, however, does improper validation of the padding in three ways:<br />
# Boot9 permits block type 02, meant for encrypted messages, to be used for signatures. Only 01, for signatures, should have been permitted. As a result, a signature block is not required to have a long string of FF bytes as padding, but rather any random values suffice. While correct for encryption, this severely lessens security of signatures.<br />
# Boot9 does not require that the length of the padding fill out the signature block completely. As a result, there is considerable freedom in the layout of a signature.<br />
# Boot9 fails to do bounds checking in its parsing of the DER-encoded hash algorithm type and hash value; the length values given in DER are permitted to point outside the signature block.<br />
Flaw 3 allows the DER encoding to be such that boot9 believes that the signature's hash value is outside the range of the block itself, somewhere on the stack. This can be pointed at the correct hash value it computes. Boot9 then memcmp's the calculated hash against itself, and thinks that the hash is valid.<br />
<br />
When all three flaws are combined, a brute force in a reasonable amount of time can find a signature that passes all checks.<br />
| None<br />
| New3DS<br />
| July 2015<br />
| [[User:Derrek|derrek]]<br />
|-<br />
| Boot9 FIRM loading doesn't blacklist memory-mapped I/O<br />
| [[Bootloader|Boot9]]'s FIRM loading blacklists Boot9 data regions, but forgets to do other important regions, including Memory-mapped I/O. Combined with sighax, by loading a malicious FIRM section to MMIO, one can get Boot9/Boot11 code execution. <br />
| None<br />
| New3DS<br />
| 2015(?)<br />
| [[User:Derrek|derrek]] (2015?), [[User:Normmatt|Normmatt]] and [[User:SciresM|SciresM]] independently (January 2017).<br />
|}<br />
<br />
== ARM9 software ==<br />
<br />
=== arm9loader ===<br />
{| class="wikitable" border="1"<br />
|-<br />
! Summary<br />
! Description<br />
! Successful exploitation result<br />
! Fixed in [[FIRM]] system version<br />
! Last [[FIRM]] system version this flaw was checked for<br />
! Timeframe this was discovered<br />
! Public disclosure timeframe<br />
! Discovered by<br />
|-<br />
| Generating the keysector console-unique keys with ITCM+Boot9<br />
| [[Bootloader|Boot9]] decrypts the 0x100-byte [[OTP_Registers|OTP]] using AES-CBC with keydata stored in Boot9. If hash verification is successful, the plaintext of the first 0x90-bytes are copied into [[Memory_layout|ITCM]]. This is the ''exact'' ''same'' region hashed by arm9loader when generating the console-unique keys for decrypting the keysector, except arm9loader uses the raw encrypted OTP.<br />
<br />
Therefore, with the OTP keydata+IV from Boot9 you can: encrypt the 0x90-bytes from ITCM, then hash the output to get the console-unique keys for the system's keysector. This can even be done for Old3DS which doesn't have the arm9loader keysector officially.<br />
<br />
It's unknown why arm9loader only used the first 0x90-bytes of OTP. Using more data from OTP would've prevented this. Fixing this would require doing exactly that, but that would also mean updating the NAND keysector(which is dangerous).<br />
| See description.<br />
| None<br />
| <br />
| 2015<br />
| January 6, 2017<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| Rearrangable keys in the NAND keystore<br />
| Due to the keystore being encrypted with AES-ECB, one can rearrange blocks and still have the NAND keystore decrypt in a deterministic way. <br />
<br />
Using 10.0 FIRM it is possible to rearrange keys such that ARM9 memory is executed. As such using existing ARM9 execution 10.0 FIRM can be written to NAND and a payload written to memory, with the payload to be executed post-K9L using an MCU reboot.<br />
| arm9loaderhax given existing ARM9 code execution<br />
| None<br />
| [[11.3.0-36|11.3.0-X]]<br />
| Early 2016<br />
| 27 September 2016<br />
| Myria, [[User:Dark samus|dark_samus]]; mathieulh (independently); [[User:Plutooo|plutoo]] (independently) + others<br />
|-<br />
| Uncleared OTP hash keydata in console-unique 0x11 key-generation<br />
| Kernel9Loader does not clear the [[SHA_Registers#SHA_HASH|SHA_HASH register]] after use. As a result, the data stored here as K9L hands over to Kernel9 is the hash of [[OTP_Registers|OTP data]] used to seed the [[FIRM#New_3DS_FIRM|console-unique NAND keystore decryption key]] set on keyslot 0x11.<br />
<br />
Retrieving this keydata and the [[Flash_Filesystem#0x12C00|NAND keystore]] of the same device allows calculating the decrypted New3DS NAND keystore (non-unique, common to all New3DS units), which contains AES normal keys, also set on keyslot 0x11, which are then used to derive all current [[AES_Registers#Keyslots|New3DS-only AES keyXs]] including the newer batch introduced in [[9.6.0-24#arm9loader|9.6.0-X]]. From there, it is trivial to perform the same key derivation in order to initialize those keys on any system version, and even on Old3DS.<br />
<br />
This can be performed by exploiting the "arm9loaderhax" vulnerability to obtain post-K9L code execution after an MCU reboot (the bootrom section-loading fail is not relevant here, this attack was performed without OTP data by brute-forcing keys), and using this to dump the SHA_HASH register. This attack works on any FIRM version shipping a vulnerable version of K9L, whereas OTP dumping required a boot of <[[3.0.0-6|3.0.0-X]].<br />
<br />
This attack results in obtaining the entire (0x200-bytes) NAND keystore - it was confirmed at a later date that this keystore is encrypted with the same key (by comparing the decrypted data from multiple units), and therefore using another key in this store will not remedy the issue as all keys are known (i.e. later, unused keys decrypt to the same 0x200-bytes constant with the same OTP hash). Later keys could have been encrypted differently but this is not the case. As a result of this, it is not possible for Nintendo to use K9L again in its current format for its intended purpose, though this was not news from the moment people dumped a New3DS OTP.<br />
| Derivation of all New3DS keys generated via the NAND keystore (0x1B "Secure4" etc.)<br />
| None<br />
| [[11.3.0-36|11.3.0-X]]<br />
| ~April 2015, implemented in May 2015<br />
| 13 January 2016<br />
| [[User:WulfyStylez|WulfyStylez]], [[User:Dazzozo|Dazzozo]], [[User:Shinyquagsire23|shinyquagsire23]] (complimentary + implemented), [[User:Plutooo|plutoo]], Normmatt (discovered independently)<br />
|-<br />
| enhanced-arm9loaderhax<br />
| See the 32c3 3ds talk.<br />
Since this is a combination of a trick with the arm9-bootrom + arm9loaderhax, and since you have to manually write FIRM to the firm0/firm1 NAND partitions, this can't be completely fixed. Any system with existing ARM9 code execution and an OTP/OTP hash dump can exploit this. Additionally, by using the FIRM partition known-plaintext bug and bruteforcing the second entry in the keystore, this can currently be exploited on all New3DS systems without any other prerequisite hacks.<br />
| arm9loaderhax which automatically occurs at hard-boot.<br />
| See arm9loaderhax / description.<br />
| See arm9loaderhax / description.<br />
| Theorized around mid July, 2015. Later implemented+tested by [[User:Plutooo|plutoo]] and [[User:Derrek|derrek]].<br />
| 32c3 3ds talk (December 27, 2015)<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| Missing verification-block for the 9.6 keys (arm9loaderhax)<br />
| Starting with [[9.6.0-24|9.6.0-X]] a new set of NAND-based keys were introduced. However, no verification block was added to verify that the new key read from NAND is correct. This was technically an issue from [[9.5.0-22|9.5.0-X]] with the original sector+0 keydata, however the below is only possible with [[9.6.0-24|9.6.0-X]] since keyslots 0x15 and 0x16 are generated from different 0x11 keyXs.<br />
<br />
Writing an incorrect key to NAND will cause arm9loader to decrypt the ARM9 kernel as garbage and then jump to it.<br />
<br />
This allows an hardware-based attack where you can boot into an older exploited firmware, fill all memory with NOP sleds/jump-instructions, and then reboot into executing garbage. By automating this process with various input keydata, eventually you'll find some garbage that jumps to your code.<br />
<br />
This gives very early ARM9 code execution (pre-ARM9 kernel). As such, it is possible to dump RSA keyslots with this and calculate the 6.x [[Savegames#6.0.0-11_Savegame_keyY|save]], and 7.x [[NCCH]] keys. This cannot be used to recover keys initialized by arm9loader itself. This is due to it wiping the area used for its stack during NAND sector decryption and keyslot init. <br />
<br />
Due to FIRMs on both Old and New 3DS using the same RSA data, this can be exploited on Old3DS as well, but only if one already has the actual plaintext normalkey from New3DS NAND sector 0x96 offset-0 and has dumped the OTP area of the Old3DS.<br />
| Recovery of 6.x [[Savegames#6.0.0-11_Savegame_keyY|save key]]/7.x [[NCCH]] key, access to uncleared OTP hash keydata<br />
| None<br />
| [[11.3.0-36|11.3.0-X]]<br />
| March, 2015<br />
| <br />
| [[User:Plutooo|plutoo]]<br />
|-<br />
| Uncleared New3DS keyslot 0x11<br />
| Originally the New3DS [[FIRM]] arm9bin loader only cleared keyslot 0x11 when it gets executed at firmlaunch. This was fixed with [[9.5.0-22|9.5.0-X]] by completely clearing keyslot 0x11 immediately after the loader finishes using keyslot 0x11.<br />
This means that any ARM9 code that can execute before the loader clears the keyslot at firmlaunch(including firmlaunch-hax) can get access to the uncleared keyslot 0x11, which then allows one to generate all <=v9.5 New3DS keyXs which are generated by keyslot 0x11.<br />
<br />
Therefore, to completely fix this the loader would have to generate more keys using different keyslot 0x11 keydata. This was done with [[9.6.0-24|9.6.0-X]].<br />
| New3DS keyXs generation<br />
| Mostly fixed with [[9.5.0-22|9.5.0-X]], completely fixed with new keys with [[9.6.0-24|9.6.0-X]].<br />
| <br />
| February 3, 2015 (one day after [[9.5.0-22|9.5.0-X]] release)<br />
| <br />
| [[User:Yellows8|Yellows8]]<br />
|}<br />
<br />
=== Process9 ===<br />
{| class="wikitable" border="1"<br />
|-<br />
! Summary<br />
! Description<br />
! Successful exploitation result<br />
! Fixed in [[FIRM]] system version<br />
! Last [[FIRM]] system version this flaw was checked for<br />
! Timeframe this was discovered<br />
! Public disclosure timeframe<br />
! Discovered by<br />
|-<br />
| Leak of normal-key matching a key-scrambler key<br />
| New 3DS firmware versions [[8.1.0-0 New3DS|8.1.0]] through [[9.2.0-20|9.2.0]] set the encryption key for [[Amiibo]] data using a hardcoded normal-key in Process9. In firmware [[9.3.0-21|9.3.0]], Nintendo "fixed" this by using the key scrambler instead, by calculating the keyY value for keyslot 0x39 that results in the same normal-key, then hardcoding that keyY into Process9.<br />
<br />
Nintendo's fix is actually the problem: Nintendo revealed the normal-key matching an unknown keyX and a known keyY. Combined with the key scrambler using an insecure scrambling algorithm (see "Hardware" above), the key scrambler function could be deduced.<br />
| Deducing the keyX for keyslot 0x39 and the key scrambler algorithm<br />
| New 3DS [[9.3.0-21|9.3.0-X]], sort of<br />
| [[10.0.0-27|10.0.0-X]]<br />
| Sometime in 2015 after the hardware key-generator was broken.<br />
| 32c3 3ds talk (December 27, 2015)<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| Leak of normal-key matching a key-generator key<br />
| During the 3DS' development (June/July 2010) Nintendo added support installing encrypted content ([[CIA]]). Common-key index1 was intended to be a [[AES|hardware generated key]]. However while they added code to generate the key in hardware, they forgot to remove the normal-key for index1 (used elsewhere, likely old debug code). Nintendo later removed the normal key sometime before the first non-prototype firmware release.<br />
<br />
<br />
Knowing the keyY and the normal-key for common-key index1, the devkit key-generator algorithm can be deduced (see "Hardware" above). Additionally the remaining devkit common-keys can be generated once the common-key keyX is recovered.<br />
<br />
Note the devkit key-generator was discovered to be the same as the retail key-generator.<br />
| Deducing the keyX for keyslot 0x3D and hardware key-generator algorithm. Generate remaining devkit common-keys.<br />
| pre-[[1.0.0-0|1.0.0-X]]<br />
| <br />
| Shortly after the key-generator was revealed to be flawed at the 32c3 3ds talk<br />
| January 20, 2016<br />
| [[User:Jakcron|jakcron]]<br />
|-<br />
| Factory firmware is vulnerable to sighax<br />
| During the 3DS's development, presumably boot9 was written (including the sighax) vulnerability. This vulnerability is also present in factory firmware (and earlier, including 0.11). This was fixed in version 1.0.0-0.<br />
| Deducing the mechanics of the sighax vulnerability in boot9 without having boot9 prot. Arm9 code execution on factory/earlier firmware.<br />
| [[1.0.0-0|1.0.0-X]]<br />
| [[1.0.0-0|1.0.0-X]]<br />
| May 9, 2017<br />
| May 19, 2017<br />
| [[User:SciresM|SciresM]], [[User:Myria|Myria]]<br />
|-<br />
| safefirmhax<br />
| SAFE_MODE_FIRM is almost never updated(even when NATIVE_FIRM is updated for vuln fixes), this can be noticed by ''just'' checking 3dbrew/ninupdates title-listings.<br />
<br />
The fix for 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 <=> Kernel11 sync, PXI sync and then repeat the original attack on SAFE_FIRM instead.<br />
| ARM9 code execution<br />
| [[11.3.0-36|11.3.0-X]]<br />
| <br />
| 2012-2013?<br />
| Wiki: January 2, 2017<br />
| Everyone<br />
|-<br />
| safefirmhax 1.1<br />
| Nintendo's original safefirmhax fix was flawed -- they added a global boolean that got set to true whenever a non-sysmodule title got launched (except for a hardcoded repair title id), and panic()'d if that boolean was true to prevent launching safefirm after hax was active. However, because the boolean was initially false after firmlaunch -- With ARM11-kernel execution, one could FIRM-launch into NATIVE_FIRM, and then immediately FIRM-launch again into SAFE_FIRM early in NATIVE_FIRM boot before the boolean got set to true to repeat the safehax attack.<br />
<br />
This was fixed by adding additional CFG9_BOOTENV checks to firmlaunch code in 11.4.<br />
| ARM9 code execution<br />
| [[11.4.0-37|11.4.0-X]]<br />
| <br />
| safefirmhax fix<br />
| Wiki: April 10, 2017<br />
| Everyone<br />
|-<br />
| ntrcardhax<br />
| When reading the banner of a NTR title, Process9 relies on a hardware register to know when the banner was fully read.<br />
However that register is shared between the ARM9 and the ARM11.<br />
An attacker with k11 control can so make Process9 believe the banner continues forever and so trigger a buffer overflow.<br />
With a custom banner for a NTR flashcart, this leads to code execution in Process9.<br />
<br />
This was fixed by adding bound checks on the read data.<br />
| ARM9 code execution<br />
| [[10.4.0-29|10.4.0-X]]<br />
| <br />
| March 2015<br />
| 32c3 3ds talk (December 27, 2015)<br />
| [[User:Plutooo|plutoo]]<br />
|-<br />
| Title downgrading via [[Application_Manager_Services|AM]]([[Application_Manager_Services_PXI|PXI]])<br />
| When a title is *already* installed, Process9 will compare the installed title-version with the title-version being installed. When the one being installed is older, Process9 would return an error.<br />
<br />
However, this can be bypassed by just deleting the title first via the service command(s) for that: with the title removed from the [[Title_Database]], Process9 can't compare the input title-version with anything. Hence, titles can be downgraded this way.<br />
<br />
[[11.0.0-33|11.0.0-X]] fixed this for key system titles (MSET, Home Menu, spider, ErrDisp, SKATER, NATIVE_FIRM, and every retail system module), by checking the version of the title to install against a hard-coded list of (titleID, minimumVersionRequired) pairs.<br />
| Bypassing title version check at installation, which then allows downgrading any title.<br />
| [[11.0.0-33|11.0.0-X]], for key system titles.<br />
| NATIVE_FIRM / AM-sysmodule [[11.0.0-33|11.0.0-X]]<br />
| ?<br />
| <br />
| ?<br />
|-<br />
| FAT FS code null-deref<br />
| When FSFile:Read is used with a file which is corrupted on a FAT filesystem(in particular SD), Process9 can crash. This particular crash is caused by a function returning NULL instead of an actual ptr due to an error. The caller of that function doesn't check for NULL which then triggers a read based at NULL.<br />
<br />
Sample "fsck.vfat -n -v -V <fat image backup>" output for the above crash:<br />
<br />
<pre>...<br />
Starting check/repair pass.<br />
<FilePath0> and<br />
<FilePath1><br />
share clusters.<br />
Truncating second to 3375104 bytes.<br />
<FilePath1><br />
File size is 2787392 bytes, cluster chain length is 16384 bytes.<br />
Truncating file to 16384 bytes.<br />
Checking for unused clusters.<br />
Reclaimed 1 unused cluster (16384 bytes).<br />
Checking free cluster summary.<br />
Free cluster summary wrong (1404490 vs. really 1404491)<br />
Auto-correcting.<br />
Starting verification pass.<br />
Checking for unused clusters.<br />
Leaving filesystem unchanged.</pre><br />
| Useless null-based-read<br />
| None<br />
| [[9.6.0-24|9.6.0-X]]<br />
| July 8-9, 2015<br />
| <br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| RSA signature padding checks<br />
| The TWL_FIRM RSA sig padding check code used for all TWL RSA sig-checks has issues, see [[FIRM|here]].<br />
The main 3DS RSA padding check code(non-certificate, including NATIVE_FIRM) uses the function used with the above to extract more padding + the actual hash from the additional padding. This isn't really a problem here because there's proper padding check code which is executed prior to this.<br />
| <br />
| None<br />
| [[9.5.0-22|9.5.0-X]]<br />
| March 2015<br />
| <br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[AMPXI:ValidateDSiWareSectionMAC]] [[AES_Registers|AES]] keyslot reuse<br />
| When the input DSiWare section index is higher than <max number of DSiWare sections supported by this FIRM>, Process9 uses keyid 0x40 for calculating the AESMAC, which translates to keyslot 0x40. The result is that the keyslot is left at whatever was already selected before, since the AES selectkeyslot code will immediately return when keyslot is >=0x40. However, actually exploiting this is difficult: the calculated AESMAC is never returned, this command just compares the calculated AESMAC with the input AESMAC(result-code depends on whether the AESMACs match). It's unknown whether a timing attack would work with this.<br />
This is basically a different form of the pxips9 keyslot vuln, except with AESMAC etc.<br />
| See description.<br />
| None<br />
| [[11.3.0-36|11.3.0-X]]<br />
| March 15, 2015<br />
| December 29, 2015<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| pxips9 [[AES_Registers|AES]] keyslot reuse<br />
| This requires access to the [[Process_Services|ps:ps]]/pxi:ps9 services. One way to get access to this would be snshax on system-version <=10.1.0-X(see 32c3 3ds talk).<br />
When an invalid key-type value is passed to any of the PS commands, Process9 will try to select keyslot 0x40. That aesengine_setkeyslot() code will then immediately return due to the invalid keyslot value. Since that function doesn't return any errors, Process9 will just continue to do crypto with whatever AES keyslot was selected before the PS command was sent.<br />
| Reusing the previously used keyslot, for crypto with PS.<br />
| None<br />
| [[11.3.0-36|11.3.0-X]]<br />
| Roughly the same time(same day?) as firmlaunch-hax.<br />
| December 29, 2015<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| firmlaunch-hax: FIRM header ToCToU<br />
| This can't be exploited from ARM11 userland.<br />
During [[FIRM]] launch, the only FIRM header the ARM9 uses at all is stored in FCRAM, this is 0x200-bytes(the actual used FIRM RSA signature is read to the Process9 stack however). The ARM9 doesn't expect "anything" besides the ARM9 to access this data.<br />
With [[9.5.0-22]] the address of this FIRM header was changed from a FCRAM address, to ARM9-only address 0x01fffc00.<br />
| ARM9 code execution<br />
| [[9.5.0-22]]<br />
| <br />
| 2012, 3 days after [[User:Yellows8|Yellows8]] started Process9 code RE.<br />
| <br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| Uninitialized data output for (PXI) command replies<br />
| PXI commands for various services(including some [[Filesystem_services_PXI|here]] and many others) can write uninitialized data (like from ARM registers) to the command reply. This happens with stubbed commands, but this can also occur with certain commands when returning an error.<br />
Certain ARM11 service commands have this same issue as well.<br />
| <br />
| None<br />
| [[9.3.0-21|9.3.0-X]]<br />
| ?<br />
| <br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[Filesystem_services_PXI|FSPXI]] OpenArchive SD permissions<br />
| Process9 does not use the exheader ARM9 access-mount permission flag for SD at all.<br />
This would mean ARM11-kernelmode code / fs-module itself could directly use FSPXI to access SD card without ARM9 checking for SD access, but this is rather useless since a process is usually running with SD access(Home Menu for example) anyway.<br />
| <br />
| None<br />
| [[9.3.0-21|9.3.0-X]]<br />
| 2012<br />
| <br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[AMPXI:ExportDSiWare]] export path<br />
| Process9 allocates memory on Process9 heap for the export path then verifies that the actual allocated size matches the input size. Then Process9 copies the input path from FCRAM to this buffer, and uses it with the Process9 FS openfile code, which use paths in the form of "<mountpoint>:/<path>".<br />
Process9 does not check the contents of this path at all before passing it to the FS code, besides writing a NUL-terminator to the end of the buffer.<br />
| Exporting of DSiWare to arbitrary Process9 file-paths, such as "nand:/<path>" etc. This isn't really useful since the data which gets written can't be controlled.<br />
| None<br />
| [[9.5.0-22]]<br />
| April 2013<br />
| <br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[DSiWare_Exports]] [[CTCert]] verification<br />
| Just like DSi originally did, 3DS verifies the APCert for DSiWare on SD with the CTCert also in the DSiWare .bin. On DSi this was fixed with with system-version 1.4.2 by verifying with the actual console-unique cert instead(stored in NAND), while on 3DS it's still not(?) fixed.<br />
On 3DS however this is useless, unless one can obtain the console-unique movable.sed keyY which encrypts the entire DSiWare .bin.<br />
| When the movable.sed keyY for the target 3DS is known and the target 3DS CTCert private-key is unknown, importing of modified DSiWare SD .bin files.<br />
| Unknown, probably none.<br />
| ?<br />
| April 2013<br />
| <br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| movable.sed keyY vulnerable to brute-force<br />
| Half of the movable.sed keyY's 128 bits are leaked through the [[Nandrw/sys/LocalFriendCodeSeed_B|LFCS]], which is available in userland and below. The LFCS itself also leaks almost half of the remaining bits by following the ratio: u32 keyY[3]=1/5(LFCS). The remaining keyY[3] uncertainty of about ±2000 can be greatly reduced by plotting expected error margins with several keyYs. This results in a final uncertainty of about 2^40, easily within practical brute force range of an average modern PC.<br />
| Knowing the keyY of a given 3ds allows for modification of DSiWare export contents, and chained with several other public vulns, ultimately arm9 execution.<br />
| None.<br />
| 11.6.0-X<br />
| December 2017<br />
| January 2018<br />
| zoogie<br />
|-<br />
| Improper validation of DSiWare title SRLs<br />
| The 3DS does not verify if the actual SRL embedded in the title's directory matches the titleID in the TMD before launching it or importing it from an sd DSiWare export. <br />
| This allows embedding older, exploitable DSiWare titles in completely different, unexploitable DSiWare titles. Since DSiWare has raw NAND RW, this can result in arm9 control through FIRM known-plaintext and sighax attacks.<br />
| None.<br />
| 11.6.0-X<br />
| 2015?<br />
| December 2016<br />
| Everyone<br />
|-<br />
| [[Gamecard_Services_PXI]] unchecked REG_CTRCARDCNT transfer-size<br />
| The u8 REG_CTRCARDCNT transfer-size parameter for the [[Gamecard_Services_PXI]] read/write CTRCARD commands is used as an index for an array of u16 values. Before [[5.0.0-11|5.0.0-X]] this u8 value wasn't checked, thus out-of-bounds reads could be triggered(which is rather useless in this case).<br />
| Out-of-bounds read for a value which gets written to a register.<br />
| [[5.0.0-11|5.0.0-X]]<br />
| <br />
| 2013?<br />
| <br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[PXI_Registers|PXI]] cmdbuf buffer overrun<br />
| The Process9 code responsible [[PXI_Registers|PXI]] communications didn't verify the size of the incoming command before writing it to a C++ member variable. <br />
| Probably ARM9 code execution<br />
| [[5.0.0-11|5.0.0-11]]<br />
| <br />
| March 2015, original timeframe if any unknown<br />
| <br />
| [[User:Plutooo|plutoo]]/[[User:Yellows8|Yellows8]]/maybe others(?)<br />
|-<br />
| [[Application_Manager_Services_PXI|PXIAM]] command 0x003D0108(See also [[Application_Manager_Services|this]])<br />
| When handling this command, Process9 allocates a 0x2800-byte heap buffer, then copies the 4 FCRAM input buffers to this heap buffer without checking the sizes at all(only the buffers with non-zero sizes are copied). Starting with [[5.0.0-11|5.0.0-X]], the total combined size of the input data must be <=0x2800.<br />
| ARM9 code execution<br />
| [[5.0.0-11|5.0.0-X]]<br />
| <br />
| May 2013<br />
| <br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[Process_Services_PXI|PS RSA]] commands buffer overflows<br />
| pxips9 cmd1(not accessible via ps:ps) and VerifyRsaSha256: unchecked copy to a buffer in Process9's .bss, from the input FCRAM buffer. The buffer is located before the pxi cmdhandler threads' stacks. SignRsaSha256 also has a buf overflow, but this isn't exploitable.<br />
The buffer for this is the buffer for the signature data. With v5.0, the signature buffer was moved to stack, with a check for the signature data size. When the signature data size is too large, Process9 uses [[SVC|svcBreak]].<br />
| ARM9 code execution<br />
| [[5.0.0-11|5.0.0-X]]<br />
| <br />
| 2012<br />
| <br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[PXI_Registers|PXI]] pxi_id bad check<br />
| The Process9 code responsible for [[PXI_Registers|PXI]] communications read pxi_id as a signed char. There were two flaws:<br />
* They used it as index to a lookup-table without checking the value at all.<br />
* Another function verified that pxi_id < 7, allowing negative values to pass the check. This would also cause an out-of-range table-lookup.<br />
| Maybe ARM9 code execution<br />
| [[3.0.0-5|3.0.0-5]]<br />
|<br />
| March 2015, originally 2012 for the first issue at least<br />
| <br />
| [[User:Plutooo|plutoo]], [[User:Yellows8|Yellows8]], maybe others(?)<br />
|}<br />
<br />
=== Kernel9 ===<br />
{| class="wikitable" border="1"<br />
|-<br />
! Summary<br />
! Description<br />
! Successful exploitation result<br />
! Fixed in [[FIRM]] system version<br />
! Last [[FIRM]] system version this flaw was checked for<br />
! Timeframe this was discovered<br />
! Discovered by<br />
|-<br />
| [[CONFIG Registers#CFG_SYSPROT9|CFG_SYSPROT9]] bit1 not set by Kernel9<br />
| Old versions of Kernel9 never set bit1 of [[CONFIG Registers#CFG_SYSPROT9|CFG_SYSPROT9]]. This leaves the [[OTP Registers|0x10012000]]-region unprotected (this region should be locked early during boot!). Since it's never locked, you can dump it once you get ARM9 code execution.<br />
<br />
From [[3.0.0-5|3.0.0-X]] this was fixed by setting the bit in Kernel9 after poking some registers in that region. On New3DS arm9loader sets this bit instead of Kernel9, which is exploitable through a hardware + software vulnerability (see arm9loaderhax / description).<br />
<br />
This flaw resurged when it gained a new practical use: retrieving the OTP data for a New3DS console in order to decrypt the key data used in arm9loader (see enhanced-arm9loaderhax / description). This was performed by downgrading to a vulnerable system version. By accounting for differences in CTR-NAND crypto (0x05 -> 0x04, see partition encryption types [[Flash_Filesystem#NAND_structure|here]]), it is possible to boot a New3DS using Old3DS firmware 1.0-2.X and an Old3DS [[NCSD#NCSD_header|NCSD Header]] to retrieve the required OTP data using this flaw.<br />
| Dumping of the [[OTP Registers|OTP]] area<br />
| [[3.0.0-5|3.0.0-X]]<br />
|<br />
| February 2015<br />
| [[User:Plutooo|plutoo]], Normmatt independently<br />
|}<br />
<br />
== ARM11 software ==<br />
=== Kernel11 ===<br />
{| class="wikitable" border="1"<br />
|-<br />
! Summary<br />
! Description<br />
! Successful exploitation result<br />
! Fixed in [[FIRM]] system version<br />
! Last [[FIRM]] system version this flaw was checked for<br />
! Timeframe this was discovered<br />
! Discovered by<br />
|-<br />
| [[SVC|svcSetProcessIdealProcessor]] reference count overflow and therefore use-after-free.<br />
| The SVC receive two arguments: handle and idealprocessor. The handle is used to get the KProcess object and the KProcess->refCnt gets incremented,later the function check if the KProcess->mem_type != BASE and if yes, it checks for idealprocessor == 2 or idealprocessor != 3. The problem here is that if you pass the idealprocessor = 3 it won't meet any condition and return the error 0xD9001BEA without decrement the reference count. <br />
It can be abused to overflow the KProcess reference count that will lead to an Use-after-free. <br />
| Before [[11.2.0-35|11.2.0-X]]: reference count overflow and therefore use-after-free.<br />
| <br />
| [[11.6.0-39|11.6.0-X]]<br />
| November 2, 2017<br />
| [[User:st4rk|st4rk]]<br />
|-<br />
| [[SVC|svcGetThreadList]] process reference leak<br />
| When given a valid process handle (including <code>0xFFFF8001</code>), svcGetThreadList forgets to decrement the reference count of the underlying [[KProcess]] instance, after having finished using it.<br />
| Before [[11.2.0-35|11.2.0-X]]: reference count overflow and therefore use-after-free, but this UAF was most likely not exploitable<br />
| <br />
| [[11.3.0-36|11.3.0-X]]<br />
| April 3, 2017<br />
| [[User:TuxSH|TuxSH]]<br />
|-<br />
| kernelhax via gspwn<br />
| Originally the kernel didn't initialize [[CONFIG11_Registers#CFG11_GPUPROT|CFG11_GPUPROT]]. Since it's 0 at hard-boot, this allowed the GPU to access the entire FCRAM + AXIWRAM.<br />
| Entire FCRAM+AXIWRAM R/W.<br />
| [[3.0.0-5|3.0.0-X]]<br />
| <br />
| February 7, 2017<br />
| [[User:Plutooo|plutoo]], [[User:Yellows8|Yellows8]] partly<br />
|-<br />
| fasthax<br />
| When a KTimer is created in pulse mode, the kernel calls a virtual function to reset the timer each time it pulses. The scheduler is locked for that core to avoid race conditions, but another core can call CloseHandle on the timer and free it, leading to a UAF vtable call.<br />
| See description.<br />
| [[11.3.0-36|11.3.0-X]]<br />
| [[11.3.0-36|11.3.0-X]]<br />
| May 2016<br />
| nedwill<br />
|-<br />
| ipctakeover<br />
| When sending cmdreplies, it does not validate that the src_addr and src_size match the equivalent dst_addr and dst_size. With a modified addr/size specified in a cmdreply for an output buffer, the data-copy for the first/last pages could be used to overwrite data outside of the buffer specified by the original process.<br />
<br />
Used by ctr-httpwn as of v1.2, for "ipctakeover/bosshaxx".<br />
<br />
This can be used to takeover processes where the process is using your service session. Like HTTPC -> BOSS, for bosshaxx above. NIM takeover can be done too(actual stack buffer overflow can trigger), etc.<br />
| See description.<br />
| None<br />
| [[11.3.0-36|11.3.0-X]]<br />
| November 26, 2016<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| Using IPC input buffers as output buffers<br />
| When sending cmdreplies, it does not validate that the cmdreply descriptor type matches the equivalent cmdreq descriptor type. This could be used by an exploited sysmodule to use what was intended as an input-buffer as an output-buffer, and also combine other IPC vuln(s) with this.<br />
<br />
Used by ctr-httpwn as of v1.2, for "ipctakeover/bosshaxx".<br />
| See description.<br />
| None<br />
| [[11.3.0-36|11.3.0-X]]<br />
| November 2016<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[SVC]] table too small<br />
| The table of function pointers for SVC's only contains entries up to 0x7D, but the biggest allowed SVC for the table is 0x7F. Thus, executing SVC7E or SVC7F would make the SVC-handler read after the buffer, and interpret some ARM instructions as function pointers.<br />
<br />
However, this would require patching the kernel .text or modifying SVC-access-control. Even if you could get these to execute, they would still jump to memory that isn't mapped as executable.<br />
| <br />
| None<br />
| [[11.3.0-36|11.3.0-X]]<br />
| 2012<br />
| Everyone<br />
|-<br />
| [[SVC|svcBackdoor (0x7B)]]<br />
| This backdoor allows executing SVC-mode code at the user-specified code-address. This is used by Process9, using this on the ARM11 (with NATIVE_FIRM) required patching the kernel .text or modifying SVC-access-control.<br />
| See description<br />
| [[11.0.0-33|11.0.0-X]] (deleted)<br />
| <br />
|<br />
| Everyone<br />
|-<br />
| veryslowpidhax<br />
| '''This is completely different from the kernelmode-code-execution vuln described in the below separate entry.'''<br />
<br />
When updating the kernel global PID counter under [[SVC|svcCreateProcess]] the kernel does not check for wraparound to 0x0(the PID for the very first process). This only matters because [[Services|SM-module]] allows processes with PID value less than <total ARM11 FIRM modules> to access ''all'' services, without checking exheader service-access-control; and because Kernel11 checks for the PID to be 1 (loader) to use the input mem-region value on ControlMemory. This alone does not affect access the [[SVC|SVCs]] access table at all.<br />
<br />
Inlined ldrex+strex code is used for updating the above counter. [[11.2.0-35|11.2.0-X]] had changes for similar code, but it was only for dedicated ldrex+strex functions(mainly for kernel objects) and hence this PID code was not affected.<br />
<br />
With launching+terminating a sysmodule repeatedly with this via ns:s, it would take weeks to finish(if not at least about a month?).<br />
| Access to all [[Services_API|services]], ControlMemory on any given mem-region.<br />
| None<br />
| [[11.3.0-36|11.3.0-X]]<br />
| 2012 maybe?<br />
| <br />
|-<br />
| slowhax/waithax<br />
| svcWaitSynchronizationN does not decrement the references to valid handles in an array before returning an error when it encounters an invalid handle. This allows one to (slowly) overflow the reference count for a handle object to zero.<br />
| ARM11 kernel-mode code execution<br />
| [[11.2.0-35|11.2.0-X]]<br />
| [[11.2.0-35|11.2.0-X]]<br />
| 2016<br />
| nedwill, [[User:Derrek|derrek]]<br />
|-<br />
| [[Memory_layout#ARM11_Detailed_virtual_memory_map|0xEFF00000]] / 0xDFF00000 ARM11 kernel virtual-memory<br />
| The ARM11 kernel-mode 0xEFF00000/0xDFF00000 virtual-memory(size 0x100000) is mapped to phys-mem 0x1FF00000(entire DSP-mem + entire AXIWRAM), with permissions RW-. This is used during ARM11 kernel startup for loading the FIRM-modules from the FIRM section located in DSP-mem, this never seems to be used after that, however. This is never unmapped either.<br />
| <br />
| None<br />
| [[11.3.0-36|11.3.0-X]]<br />
| <br />
| <br />
|-<br />
| memchunkhax2.1<br />
| Nintendo's fix for memchunkhax2 in [[10.4.0-29|10.4.0-X]] did not fix the GPU case: one may cause the requisite ToCToU race using gspwn, bypassing the new validation.<br />
derrek's original 32c3 presentation for memchunkhax2 commented that a GPU-based attack was possible, but would be difficult. However, memchunkhax2.1 showed that it was possible to do fairly reliably.<br />
| ARM11 kernel code execution<br />
| [[11.0.0-33|11.0.0-X]], via the new [[Memory_Management#MemoryBlockHeader|memchunkhdr]] MAC which prevents modifying memchunkhdr data with DMA.<br />
| [[11.0.0-33|11.0.0-X]]<br />
|<br />
| [[User:Derrek|derrek]], aliaspider<br />
|-<br />
| memchunkhax2<br />
| When allocating a block of memory, the "next" pointer of the [[Memory_Management#MemoryBlockHeader|memchunkhdr]] is accessed without being checked after being mapped to userland.<br />
This allows a race condition, where the process can change the next pointer just before it's accessed. By pointing the next pointer to a crafted memchunckhdr in the kernel SlabHeap, some of the SlabHeap is allocated to the calling process, allowing to change vtables of kernel objects. <br />
| ARM11 kernel code execution<br />
| [[10.4.0-29|10.4.0-X]] (partially, see memchunkhax2.1)<br />
| [[10.4.0-29|10.4.0-X]]<br />
|<br />
| [[User:Derrek|derrek]]<br />
|-<br />
| heaphax<br />
| Can change the size of free memchunk structures stored in FCRAM using DMA, which leads to the ability to allocate memory chunks over already-allocated memory. This can be used in the SYSTEM region to allocate RW memory over any part of the NS system module, which is enough to take it over.<br />
| Code execution with access to all of NS's privileges. (including downgrading) Code execution within any applet.<br />
| [[11.0.0-33|11.0.0-X]], via the new [[Memory_Management#MemoryBlockHeader|memchunkhdr]] MAC which prevents modifying memchunkhdr data with DMA.<br />
| [[11.0.0-33|11.0.0-X]]<br />
| April 2015 ?<br />
| smea<br />
|-<br />
| snshax<br />
| Can force creation of Safe NS process into gspwn-able memory, allowing for takeover.<br />
| Code execution with access to all of NS's privileges. (including downgrading)<br />
| [[10.1.0-27|10.1.0-X]]<br />
| [[10.1.0-27|10.1.0-X]]<br />
| April 2015 ?<br />
| smea<br />
|-<br />
| AffinityMask/processorid validation<br />
| With [[10.0.0-27|10.0.0-X]] the following functions were updated: svcGetThreadAffinityMask, svcGetProcessAffinityMask, svcSetProcessAffinityMask, and svcCreateThread. The code changes for all but svcCreateThread are identical.<br />
The original code with the first 3 did the following: <br />
* if(u32_processorcount > ~0x80000001)return 0xe0e01bfd;<br />
* if(s32_processorcount > <total_cores>)return 0xd8e007fd;<br />
The following code replaced the above:<br />
* if(u32_processorcount >= <total_cores+1>)return 0xd8e007fd;<br />
In theory the latter should catch everything that the former did, so it's unknown if this was really a security issue.<br />
<br />
The svcCreateThread changes with [[10.0.0-27|10.0.0-X]] definitely did fix a security issue.<br />
* Original code: "if(s32_processorid > <total_cores>)return 0xd8e007fd;"<br />
* New code: "if(s32_processorid >= <total_cores> || s32_processorid <= -4)return 0xd8e007fd;"<br />
This fixed an off-by-one issue: if one would use processorid=total_cores, which isn't actually a valid value, svcCreateThread would accept that value on <[[10.0.0-27|10.0.0-X]]. This results in data being written out-of-bounds(baseaddr = arrayaddr + entrysize*processorid), which has the following result:<br />
* Old3DS: Useless kernel-mode crash due to accessing unmapped memory.<br />
* New3DS: uncontrolled data write into a kernel-mode L1 MMU-table. This isn't really useful: the data can't be controlled, and the data which gets overwritten is all-zero anyway(this isn't anywhere near MMU L1 entries for actually mapped memory).<br />
The previous version also allowed large negative s32_processorid values(negative processorid values are special values not actual procids), but it appears using values like that won't actually do anything(meaning no crash) besides the thread not running / thread not running for a while(besides triggering a kernelpanic with certain s32_processorid value(s)).<br />
| Nothing useful<br />
| [[10.0.0-27|10.0.0-X]]<br />
| [[10.0.0-27|10.0.0-X]]<br />
| svcCreateThread issue: May 31, 2015. The rest: September 8, 2015, via v9.6->v10.0 ARM11-kernel code-diff.<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| memchunkhax<br />
| The kernel originally did not validate the data stored in the FCRAM kernel heap [[Memchunkhdr|memchunk-headers]] for free-memory at all. Exploiting this requires raw R/W access to these memchunk-headers, like physical-memory access with gspwn.<br />
<br />
There are ''multiple'' ways to exploit this, but the end-result for most of these is the same: overwrite code in AXIWRAM via the 0xEFF00000/0xDFF00000 kernel virtual-memory mapping.<br />
<br />
This was fixed in [[9.3.0-21|9.3.0-X]] by checking that the memchunk(including size, next, and prev ptrs) is located within the currently used heap memory. The kernel may also check that the next/prev ptrs are valid compared to other memchunk-headers basically. When any of these checks fail, kernelpanic() is called.<br />
| When combined with other flaws: ARM11-kernelmode code execution<br />
| [[9.3.0-21|9.3.0-21]]<br />
| <br />
| February 2014<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| Multiple [[KLinkedListNode|KLinkedListNode]] SlabHeap use after free bugs<br />
| The ARM11-kernel did access the 'key' field of [[KLinkedListNode|KLinkedListNode]] objects, which are located on the SlabHeap, after freeing them. Thus, triggering an allocation of a new [[KLinkedListNode|KLinkedListNode]] object at the right time could result in a type-confusion. Pseudo-code:<br />
SlabHeap_free(KLinkedListNode);<br />
KObject *obj = KLinkedListNode->key; // the object there might have changed!<br />
This bug appeared all over the place.<br />
| ARM11-kernelmode code exec maybe<br />
| [[8.0.0-18|8.0.0-18]]<br />
| <br />
| April 2015<br />
| [[User:Derrek|derrek]]<br />
|-<br />
| PXI [[RPC_Command_Structure|Command]] input/output buffer permissions<br />
| Originally the ARM11-kernel didn't check permissions for PXI input/output buffers for commands. Starting with [[6.0.0-11|6.0.0]] PXI input/output buffers must have RW permissions, otherwise kernelpanic is triggered.<br />
| <br />
| [[6.0.0-11|6.0.0-11]]<br />
| <br />
| 2012<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[SVC|svcStartInterProcessDma]]<br />
| For svcStartInterProcessDma, the kernel code had the following flaws:<br />
<br />
* Originally the ARM11-kernel read the input DmaConfig structure directly in kernel-mode(ldr(b/h) instructions), without checking whether the DmaConfig address is readable under userland. This was fixed by copying that structure to the SVC-mode stack, using the ldrbt instruction.<br />
<br />
* Integer overflows for srcaddr+size and dstaddr+size are now checked(with [[6.0.0-11]]), which were not checked before.<br />
<br />
* The kernel now also checks whether the srcaddr/dstaddr (+size) is within userland memory (0x20000000), the kernel now (with [[6.0.0-11]]) returns an error when the address is beyond userland memory. Using an address >=0x20000000 would result in the kernel reading from the process L1 MMU table, beyond the memory allocated for that MMU table(for vaddr->physaddr conversion). <br />
| <br />
| [[6.0.0-11]]<br />
| <br />
| DmaConfig issue: unknown. The rest: 2014<br />
| [[User:Plutooo|plutoo]], [[User:Yellows8|Yellows8]] independently<br />
|-<br />
| [[SVC|svcControlMemory]] Parameter checks<br />
| For svcControlMemory the parameter check had these two flaws:<br />
<br />
* The allowed range for addr0, addr1, size parameters depends on which MemoryOperation is being specified. The limitation for GSP heap was only checked if op=(u32)0x10003. By setting a random bit in op that has no meaning (like bit17?), op would instead be (u32)0x30003, and the range-check would be less strict and not accurate. However, the kernel doesn't actually use the input address for LINEAR memory-mapping at all besides the range-checks, so this isn't actually useful. This was fixed in the kernel by just checking for the LINEAR bit, instead of comparing the entire MemoryOperation value with 0x10003.<br />
<br />
* Integer overflows on (addr0+size) are now checked that previously weren't (this also applies to most other address checks elsewhere in the kernel).<br />
<br />
| <br />
| [[5.0.0-11]]<br />
| <br />
|<br />
| [[User:Plutooo|plutoo]]<br />
|-<br />
| [[RPC_Command_Structure|Command]] request/response buffer overflow<br />
| Originally the kernel did not check the word-values from the command-header. Starting with [[5.0.0-11]], the kernel will trigger a kernelpanic() when the total word-size of the entire command(including the cmd-header) is larger than 0x40-words (0x100-bytes). This allows overwriting threadlocalstorage+0x180 in the destination thread. However, since the data written there would be translate parameters (such as header-words + buffer addresses), exploiting this would likely be very difficult, if possible at all.<br />
<br />
If the two words at threadlocalstorage+0x180 could be overwritten with controlled data this way, one could then use a command with a buffer-header of <nowiki>((size<<14) | 2)</nowiki> to write arbitrary memory to any RW userland memory in the destination process.<br />
| <br />
| [[5.0.0-11]]<br />
| <br />
| v4.1 FIRM -> v5.0 code diff<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[SVC|SVC stack allocation overflows]]<br />
| <br />
* Syscalls that allocate a variable-length array on stack, only checked bit31 before multiplying by 4/16 (when calculating how much memory to allocate). If a large integer was passed as input to one of these syscalls, an integer overflow would occur, and too little memory would have been allocated on stack resulting in a buffer overrun. <br />
* The alignment (size+7)&~7 calculation before allocation was not checked for integer overflow.<br />
<br />
This might allow for ARM11 kernel code-execution.<br />
<br />
(Applies to svcSetResourceLimitValues, svcGetThreadList, svcGetProcessList, svcReplyAndReceive, svcWaitSynchronizationN.)<br />
| <br />
| [[5.0.0-11]]<br />
| <br />
| v4.1 FIRM -> v5.0 code diff<br />
| [[User:Plutooo|plutoo]], [[User:Yellows8|Yellows8]] complementary<br />
|-<br />
| [[SVC|svcControlMemory]] MemoryOperation MAP memory-permissions<br />
| svcControlMemory with MemoryOperation=MAP allows mapping the already-mapped process virtual-mem at addr1, to addr0. The lowest address permitted for addr1 is 0x00100000. Originally the ARM11 kernel didn't check memory permissions for addr1. Therefore .text as addr1 could be mapped elsewhere as RW- memory, which allowed ARM11 userland code-execution.<br />
| <br />
| [[4.1.0-8]]<br />
| <br />
| 2012<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[RPC_Command_Structure|Command]] input/output buffer permissions<br />
| Originally the ARM11 kernel didn't check memory permissions for the input/output buffers for commands. Starting with [[4.0.0-7]] the ARM11 kernel will trigger a kernelpanic() if the input/output buffers don't have the required memory permissions. For example, this allowed a FSUSER file-read to .text, which therefore allowed ARM11-userland code execution.<br />
| <br />
| [[4.0.0-7]]<br />
| <br />
| 2012<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[SVC|svcReadProcessMemory/svcWriteProcessMemory memory]] permissions<br />
| Originally the kernel only checked the first page(0x1000-bytes) of the src/dst buffers, for svcReadProcessMemory and svcWriteProcessMemory. There is no known retail processes which have access to these SVCs.<br />
| <br />
| [[4.0.0-7]]<br />
| <br />
| 2012?<br />
| [[User:Yellows8|Yellows8]]<br />
|}<br />
<br />
=== [[FIRM]] Sysmodules ===<br />
{| class="wikitable" border="1"<br />
|-<br />
! Summary<br />
! Description<br />
! Successful exploitation result<br />
! Fixed in [[FIRM]] system version<br />
! Last [[FIRM]] system version this flaw was checked for<br />
! Timeframe this was discovered<br />
! Discovered by<br />
|-<br />
| [[Services|"srv:pm"]] process registration<br />
| Originally any process had access to the port "srv:pm". The PID's used for the (un)registration commands are not checked either. This allowed any process to re-register itself with "srv:pm", and therefore allowed the process to give itself access to any service, bypassing the exheader service-access-control list.<br />
<br />
This was fixed in [[7.0.0-13]]: starting with [[7.0.0-13]] "srv:pm" is now a service instead of a globally accessible port. Only processes with PID's less than 6 (in other words: fs, ldr, sm, pm, pxi modules) have access to it. With [[7.0.0-13]] there can only be one session for "srv:pm" open at a time(this is used by pm module), svcBreak will be executed if more sessions are opened by the processes which can access this.<br />
<br />
This flaw was needed for exploiting the <=v4.x Process9 PXI vulnerabilities from ARM11 userland ROP, since most applications don't have access to those service(s).<br />
| Access to arbitrary services<br />
| [[7.0.0-13]]<br />
| <br />
| 2012<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| FSDIR null-deref<br />
| [[Filesystem_services|FS]]-module may crash in some cases when handling directory reading. The trigger seems to be due to using [[FSDir:Close]] without closing the dir-handle afterwards?(Perhaps this is caused by out-of-memory?) This seems to be useless since it's just a null-deref.<br />
| <br />
| None<br />
| [[9.6.0-24|9.6.0-X]]<br />
| May 19(?)-20, 2015<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[SM]] out-of-bounds BSS write (table 1 entry too small)<br />
| After accepting a new session, [[SM]] writes a (handler ID (0 for srv: sessions (max. 64), 1 for the srv:pm one), pointer to session context structure in BSS) pair in a global array. However that array is only 64-entry-big instead of 65 (as it ought to be), and no bound check is done in that regard.<br />
<br />
Unfortunately, as of [[11.4.0-37]], the overwritten fields are totally unused after their initialization by <code>__libc_init_array</code>.<br />
| Not currently exploitable<br />
| None<br />
| [[11.4.0-37]]<br />
|<br />
|<br />
|}<br />
<br />
=== Standalone Sysmodules ===<br />
{| class="wikitable" border="1"<br />
|-<br />
! Summary<br />
! Description<br />
! Successful exploitation result<br />
! Fixed in system-module system-version<br />
! Last system-module system-version this flaw was checked for<br />
! Timeframe this was discovered<br />
! Timeframe this was added to wiki<br />
! Discovered by<br />
|-<br />
| [[MP:SendDataFrame]] missing input array index validation<br />
| [[MP:SendDataFrame]] doesn't validate the input index at cmdreq[1], unless the function for flag=non-zero is executed. This is used to calculate the following, without validating the index at all: someptr = stateptr + (index*0x924) + somestateoffset.<br />
<br />
After validating some flags from someptr, when input_flag=0 the input buffer data is copied to someptr+someotheroffset+0x14 with the u16 size loaded from someptr+someotheroffset.<br />
<br />
With a large input index someptr could be setup to be at a <target address>, for overwriting memory.<br />
<br />
This is probably difficult to exploit.<br />
| <br />
| None<br />
| [[8.0.0-18]](MP-sysmodule v2048)<br />
| January 22, 2017<br />
| January 22, 2017<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[MP_Services|MP]] cmd1 out-of-bounds handle read<br />
| MP-sysmodule handles the input parameter for cmd1 as a s32. It checks for >=16, but not <0. With <16 it basically does the following(array of entries 4-bytes each): *outhandle = ((Handle*)(stateptr+offsetinstate))[inputindex].<br />
<br />
Hence, this can be used to load any handle in MP-sysmodule memory. MP doesn't really have any service handles of interest however(can be obtained from elsewhere too).<br />
| Reading any handle in MP-sysmodule memory.<br />
| None<br />
| [[8.0.0-18]](MP-sysmodule v2048)<br />
| January 21, 2017<br />
| January 22, 2017<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| AM stack/.bss infoleak via [[AM:ReadTwlBackupInfo]]([[AM:ReadTwlBackupInfoEx|Ex]])<br />
| After writing the output-info structure to stack, it then copies that structure to the output buffer ptr using the size from the command. The size is not checked. This could be used to read data from the AM-service-thread stack handling the command + .bss.<br />
<br />
'''This was not tested on hardware.'''<br />
| Stack/.bss reading<br />
| None<br />
| [[10.0.0-27]](AM v9217)<br />
| Roughly October 17, 2016<br />
| October 25, 2016<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[MVD_Services|MVD]]: Stack buffer overflow with [[MVDSTD:SetupOutputBuffers]].<br />
| The input total_entries is not validated when initially processing the input entry-list. This fixed-size input entry-list is copied to stack from the command request. The loop for processing this initializes a global table, the converted linearmem->physaddrs used there are also copied to stack(0x8-bytes of physaddrs per entry).<br />
<br />
If total_entries is too large, MVD-sysmodule will crash due to reading unmapped memory following the stack(0x10000000). Afterwards if the out-of-bounds total_entries is smaller than that, it will crash due accessing address 0x0, hence this useless.<br />
| MVD-sysmodule crash.<br />
| None<br />
| [[9.0.0-20]]<br />
| April 22, 2016 (Tested on the 25th)<br />
| April 25, 2016<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[NWM_Services|NWM]]: Using CTRSDK heap with UDS sharedmem from the user-process.<br />
| See the HTTP-sysmodule section below.<br />
<br />
CTRSDK heap is used with the sharedmem from [[NWMUDS:InitializeWithVersion]]. Buffers are allocated/freed under this heap using [[NWMUDS:Bind]] and [[NWMUDS:Unbind]].<br />
<br />
Hence, overwriting sharedmem with gspwn then using [[NWMUDS:Unbind]] results in the usual controlled CTRSDK memchunk-header write, similar to HTTP-sysmodule.<br />
<br />
This could be done by creating an UDS network, without any other nodes on the network.<br />
<br />
Besides CTRSDK memchunk-headers, there are no addresses stored under this sharedmem.<br />
| ROP under NWM-module.<br />
| [[11.4.0-37|11.4.0-X]]<br />
| [[9.0.0-20|9.0.0-X]]<br />
| April 10, 2016<br />
| April 16, 2016<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[DLP_Services|DLP]]: Out-of-bounds memory access during spectator [[Download_Play|data-frame]] checksum calculation<br />
| DLP doesn't validate the frame_size when receiving spectator data-frames at all, unlike non-spectator data-frames. The actual spectator data-frame parsing code doesn't use that field either. However, the data-frame checksum calculation code called during checksum verification does use the frame_size for loading the size of the framebuf.<br />
<br />
Hence, using a large frame_size like 0xFFFF will result in the checksum calculation code reading data out-of-bounds. This isn't really useful, you could trigger a remote local-WLAN DLP-sysmodule crash while a 3DS system is scanning for DLP networks(due to accessing unmapped memory), but that's about all(trying to infoleak with this likely isn't useful either).<br />
| DLP-sysmodule crash, handled by dlplay system-application by a "connection interrupted" error eventually then a fatal-error via ErrDisp.<br />
| None<br />
| [[10.0.0-27|10.0.0-X]]<br />
| April 8, 2016 (Tested on the 10th)<br />
| April 10, 2016<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[DLP_Services|DLP]]: Out-of-bounds output data writing during spectator sysupdate titlelist [[Download_Play|data-frame]] handling<br />
| The total_entries and out_entryindex fields for the titlelist DLP spectator data-frames are not validated. This is parsed during DLP network scanning. Hence, the specified titlelist data can be written out-of-bounds using the specified out_entryindex and total_entries. A crash will occur while reading the input data-frame titlelist if total_entries is larger than 0x27A, due to accessing unmapped memory.<br />
<br />
There's not much non-zero data to overwrite following the output buffer(located in sharedmem), any ptrs are located in sharedmem. Overwriting certain ptr(s) are only known to cause a crash when attempting to use the DLP-client shutdown service-command.<br />
<br />
There's no known way to exploit the above crash, since the linked-list code involves writes zeros(with a controlled start ptr).<br />
| <br />
| None<br />
| [[10.0.0-27|10.0.0-X]]<br />
| April 8-9, 2016<br />
| April 10, 2016<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[IR_Services|IR]]: Stack buffer overflow with custom hardware<br />
| Originally IR sysmodule used the read value from the I2C-IR registers TXLVL and RXLVL without validating them at all. See [[10.6.0-31|here]] for the fix. This is the size used for reading the data-recv FIFO, etc. The output buffer for reading is located on the stack.<br />
<br />
This should be exploitable if one could successfully setup the custom hardware for this and if the entire intended sizes actually get read from I2C.<br />
| ROP under IR sysmodule.<br />
| [[10.6.0-31|10.6.0-31]]<br />
| <br />
| February 23, 2016 (Unknown if it was noticed before then)<br />
| February 23, 2016<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[HTTP_Services|HTTP]]: Using CTRSDK heap with sharedmem from the user-process.<br />
| The data from httpcAddPostDataAscii and other commands is stored under a CTRSDK heap. That heap is the sharedmem specified by the user-process via the HTTPC Initialize command.<br />
Normally this sharedmem isn't accessible to the user-process once the sysmodule maps it, hence using it is supposed to be "safe".<br />
<br />
This isn't the case due to gspwn however. Since CTRSDK heap code is so insecure in general, one can use gspwn to locate the HTTPC sharedmem + read/write it, then trigger a mem-write under the sysmodule. This can then be used to get ROP going under HTTP-sysmodule.<br />
<br />
This is exploited by [https://github.com/yellows8/ctr-httpwn/ctr-httpwn ctr-httpwn].<br />
| ROP under HTTP sysmdule.<br />
| [[11.4.0-37|11.4.0-X]]<br />
| [[9.6.0-24|9.6.0-X]] (Latest sysmodule version as of [[10.7.0-32|10.7.0-32]])<br />
| Late 2015<br />
| March 22, 2016<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[NIM_Services|NIM]]: Downloading old title-versions from eShop<br />
| Multiple NIM service commands(such as [[NIMS:StartDownload]]) use a title-version value specified by the user-process, NIM does not validate that this input version matches the latest version available via SOAP. Therefore, when combined with AM(PXI) [[#Process9|title-downgrading]] via deleting the target eShop title with System Settings Data Management(if the title was already installed), this allows downloading+installing any title-version from eShop ''if'' it's still available from CDN.<br />
The easiest way to exploit this is to just patch the eShop system-application code using these NIM commands(ideally the code which loads the title-version).<br />
<br />
Originally this was tested with a debugging-system via modded-FIRM, eventually smea implemented it in HANS for the 32c3 release.<br />
| Downloading old title-versions from eShop<br />
| None<br />
| [[10.0.0-27|10.0.0-X]]<br />
| October 24, 2015 (Unknown when exactly the first eShop title downgrade was actually tested, maybe November)<br />
| January 7, 2016 (Same day Ironfall v1.0 was removed from CDN via the main-CXI files)<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[SPI_Services|SPI]] service out-of-bounds write<br />
| cmd1 has out-of-bounds write allowing overwrite of some static variables in .data.<br />
| <br />
| None<br />
| [[9.5.0-22]]<br />
| March 2015<br />
| <br />
| [[User:Plutooo|plutoo]]<br />
|-<br />
| [[NFC_Services|NFC]] module service command buf-overflows<br />
| NFC module copies data with certain commands, from command input buffers to stack without checking the size. These commands include the following, it's unknown if there's more commands with similar issues: "nfc:dev" <0x000C....> and "nfc:s" <0x0037....>.<br />
Since both of these commands are stubbed in the Old3DS NFC module from the very first version(those just return an error), these issues only affect the New3DS NFC module.<br />
<br />
There's no known retail titles which have access to either of these services.<br />
| ROP under NFC module.<br />
| New3DS: None<br />
| New3DS: [[9.5.0-22]]<br />
| December 2014?<br />
| <br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[News_Services|NEWSS]] service command notificationID validation failure<br />
| This module does not validate the input notificationID for <nowiki>"news:s"</nowiki> service commands. This is an out-of-bounds array index bug. For example, [[NEWSS:SetNotificationHeader]] could be used to exploit news module: this copies the input data(size is properly checked) to: out = newsdb_savedata+0x10 + (someu32array[notificationID]*0x70).<br />
| ROP under news module.<br />
| None<br />
| [[9.7.0-25|9.7.0-X]]<br />
| December 2014<br />
| <br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[NWMUDS:DecryptBeaconData]] heap buffer overflow<br />
| input_size = 0x1E * <value the u8 from input_[[NWM_Services|networkstruct]]+0x1D>. Then input_tag0 is copied to a heap buffer. When input_size is larger than 0xFA-bytes, it will then copy input_tag1 to <end_address_of_previous_outbuf>, with size=input_size-0xFA.<br />
<br />
This can be triggered by either using this command directly, or by boadcasting a wifi beacon which triggers it while a 3DS system running the target process is in range, when the process is scanning for hosts to connect to. Processes will only pass tag data to this command when the wlancommID and other thing(s) match the values for the process.<br />
<br />
There's no known way to actually exploit this for getting ROP under NWM-module, at the time of originally adding this to the wiki. This is because the data which gets copied out-of-bounds *and* actually causes crash(es), can't be controlled it seems(with just broadcasting a beacon at least). It's unknown whether this could be exploited from just using NWMUDS service-cmd(s) directly.<br />
| Without any actual way to exploit this: NWM-module DoS, resulting in process termination(process crash). This breaks *everything* involving wifi comms, a reboot is required to recover from this.<br />
| None<br />
| [[9.0.0-20]]<br />
| ~September 23, 2014(see the [[NWMUDS:DecryptBeaconData]] page history)<br />
| August 3, 2015<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[HID_Services|HID]] module shared-mem<br />
| HID module does not validate the index values in [[HID_Shared_Memory|sharedmem]](just changes index to 0 when index == maxval when updating), therefore large values will result in HID module writing HID data to arbitrary addresses.<br />
| ROP under HID module, but this is *very* unlikely to be exploitable since the data written is HID data.<br />
| None<br />
| [[9.3.0-21]]<br />
| 2014?<br />
| <br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| gspwn<br />
| GSP module does not validate addresses given to the GPU. This allows a user-mode application/applet to read/write to a large part of physical FCRAM using GPU DMA. From this, you can overwrite the .text segment of the application you're running under, and gain real code-execution from a ROP-chain. Normally applets' .text([[Home Menu]], [[Internet Browser]], etc) is located beyond the area accessible by the GPU, except for [[RO_Services|CROs]] used by applets([[Internet Browser]] for example).<br />
<br />
FCRAM is gpu-accessible up to physaddr 0x26800000 on Old3DS, and 0x2D800000 on New3DS. This is BASE_memregion_start(aka SYSTEM_memregion_end)-0x400000 (0x800000 with New3DS) with the default memory-layout on Old3DS/New3DS. With [[11.3.0-36|11.3.0-X]] the cutoff now varies due to the new [[SVC]] 0x59. The New3DS "normal"(non-APPLICATION) cutoff was changed to 0x2D000000 due to the new [[SVC]] 0x59.<br />
| User-mode code execution.<br />
| None<br />
| [[9.6.0-24|9.6.0-X]]<br />
| Early 2014<br />
| <br />
| smea, [[User:Yellows8|Yellows8]]/others before then<br />
|-<br />
| rohax<br />
| Using gspwn, it is possible to overwrite a loaded [[CRO0]]/[[CRR0]] after its RSA-signature has been validated. Badly validated [[CRO0]] header leads to arbitrary read/write of memory in the ro-process. This gives code-execution in the ro module, who has access to [[SVC|syscalls]] 0x70-0x72, 0x7D.<br />
<br />
This was fixed after [[ninjhax]] release by adding checks on [[CRO0]]-based pointers before writing to them.<br />
| Memory-mapping syscalls.<br />
| [[9.3.0-21]]<br />
| [[9.4.0-21]]<br />
| <br />
| <br />
| smea, [[User:Plutooo|plutoo]] joint effort<br />
|-<br />
| Region free<br />
| Only [[Home Menu]] itself checks gamecards' region when launching them. Therefore, any application launch that is done directly with [[NS]] without signaling Home Menu to launch the app, will result in region checks being bypassed.<br />
This essentially means launching the gamecard with the [[NS_and_APT_Services|"ns:s"]] service. The main way to exploit this is to trigger a FIRM launch with an application specified, either with a normal FIRM launch or a hardware [[NSS:RebootSystem|reboot]].<br />
| Launching gamecards from any region + bypassing Home Menu gamecard-sysupdate installation<br />
| None<br />
| Last tested with [[10.1.0-27|10.1.0-X]].<br />
| June(?) 2014<br />
| <br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| [[NWM_Services|NWM]] service-cmd state null-ptr deref<br />
| The NWMUDS service command code loads a ptr from .data, adds an offset to that, then passes that as the state address for the actual command-handler function. The value of the ptr loaded from .data is not checked, therefore this will cause crashes due to that being 0x0 when NWMUDS was not properly initialized.<br />
It's unknown whether any NWM services besides NWMUDS have this issue.<br />
| This is rather useless since it's only a crash caused by a state ptr based at 0x0.<br />
| None<br />
| [[9.0.0-20]]<br />
| 2013?<br />
| <br />
| [[User:Yellows8|Yellows8]]<br />
|}<br />
<br />
=== General/CTRSDK ===<br />
{| class="wikitable" border="1"<br />
|-<br />
! Summary<br />
! Description<br />
! Successful exploitation result<br />
! Fixed in version<br />
! Last version this flaw was checked for<br />
! Timeframe this was discovered<br />
! Discovered by<br />
|-<br />
| [[NWM_Services|UDS]] beacon additional-data buffer overflow<br />
| Originally CTRSDK did not validate the UDS additional-data size before using that size to copy the additional-data to a [[NWM_Services|networkstruct]]. This was eventually fixed.<br />
This was discovered while doing code RE with an old dlp-module version. It's unknown in what specific CTRSDK version this was fixed, or even what system-version updated titles with a fixed version.<br />
<br />
It's unknown if there's any titles using a vulnerable CTRSDK version which are also exploitable with this(dlp module can't be exploited with this).<br />
<br />
The maximum number of bytes that can be written beyond the end of the outbuf is 0x37-bytes, with additionaldata_size=0xFF.<br />
| Perhaps ROP, very difficult if possible with anything at all<br />
| ?<br />
| <br />
| September(?) 2014<br />
| [[User:Yellows8|Yellows8]]<br />
|-<br />
| CTPK buffer overflow<br />
| At offset 0x20 in CTPK is an array for each texture, each entry is 0x20-bytes. This contains a wordindex(entry+0x18) for some srcdata relative to CTPK+0, and an u8 wordsize(entry+0x14) for this data. The CTRSDK function handling this doesn't validate the size, when copying srcdata using this size to the output buffer. Applications usually have the output buffer on the stack, hence stack buffer overflow.<br />
<br />
While CTPK(*.ctpk) are normally only loaded from RomFS, some application(s) load from elsewhere too.<br />
| ROP under the target application.<br />
| None?<br />
| "[SDK+NINTENDO:CTR_SDK-11_4_0_200_none]"<br />
| November 14, 2016<br />
| [[User:Yellows8|Yellows8]]<br />
|}</div>Myriahttps://www.3dbrew.org/w/index.php?title=Serials&diff=20602Serials2018-02-18T05:53:25Z<p>Myria: /* Physical Serial */ My Taiwanese Bio Hazard is -CHT. Still region W though.</p>
<hr />
<div>This page talks about the 3DS products' serial number and model number structures (the console, manual, accessories, games, etc...).<br />
<br />
== Console Serial Numbers ==<br />
<br />
A 3DS console serial number is composed of at least two letters followed by nine decimal digits. The ninth digit is a "check digit", meaning that it is derived from the other digits.<br />
<br />
The check digit is an industry-standard algorithm, the one used for UPC codes. To calculate the check digit of a 3DS console, separate the non-check digits into "odd" and "even" groups, where the "odd" group is digits in odd-numbered positions, and the "even" group is digits in even-numbered positions. (The first digit is "odd", with "first" representing "1".)<br />
<br />
After separating the digits, add the digits in each group together. Multiply the sum of the even digits by 3, then add the sum of the odd digits. To calculate the check digit, take this value modulo 10, and if not 0, subtract from 10.<br />
<br />
Example: CW404567772<br />
<br />
The non-check digits are 40456777. Separating into odd and even groups, we get the following:<br />
<br />
Odds: 4 + 4 + 6 + 7 = 21<br />
Evens: 0 + 5 + 7 + 7 = 19<br />
<br />
Applying the algorithm, we get ((3 * 19) + 21) % 10 = 8, which is not 0, thus 10 - 8 = 2, matching the example's check digit.<br />
<br />
The letter prefixes are a letter specifying the device, followed by one letter specifying the region in which it was sold. In some regions, a third letter is present; a current guess is that this letter distinguishes among factories for a given sales region. Note that several different sales regions' console may be considered to be the same region for region-locking purposes, such as Europe and Australia.<br />
<br />
The current serial number scheme began with the DSi, hence its listing in the tables below. Among standalone consoles, the Wii U belongs to this scheme as well; the Switch started a new scheme.<br />
<br />
{| class="wikitable"<br />
! Model !! Device Prefix (Retail) !! Device Prefix (Dev/Test)<br />
|-<br />
| ''DSi'' || T || V<br />
|-<br />
| ''DSi XL/LL'' || W || ''unknown''<br />
|-<br />
| ''Wii U'' || F || ''unknown''<br />
|-<br />
| 3DS || C || E<br />
|-<br />
| 3DS XL/LL || S || R<br />
|-<br />
| 2DS || A || P<br />
|-<br />
| New 3DS || Y || Y<br />
|-<br />
| New 3DS XL/LL || Q || Q<br />
|-<br />
| New 2DS XL/LL || N || N<br />
|}<br />
<br />
Test ("Panda") units with the same prefix as retail can be distinguished by test units having 00 or 01 as the first two digits of the serial number portion. 00 was used with the New 3DS and New 3DS XL for test units; 01 was used with the New 2DS XL test unit. Preview versions of the N2DS XL given out to the press had 01; these appear to have been test units with the development titles deleted.<br />
<br />
Old 3DS development systems (Partner-CTR, IS-CTR-BOX, IS-SPR-BOX) use the "E" and "R" prefixes like test systems, but have 90 (Partner-CTR) or 91 (IS-CTR-BOX, IS-SPR-BOX) as their first two digits. Similarly, the main New 3DS development unit, IS-SNAKE-BOX, uses the Y prefix (same as retail) with 91. It is currently unknown what is the serial number format of the rare New 3DS XL development system (IS-CLOSER-BOX).<br />
<br />
{| class="wikitable"<br />
! Sales Region !! Region Lock !! Region Suffix<br />
|-<br />
| Japan || Japan || JF, JH, JM<br />
|-<br />
| North America || North America || W<br />
|-<br />
| Middle East / Southeast Asia || North America || S<br />
|-<br />
| Europe || Europe || EF, EH, EM<br />
|-<br />
| Australia || Europe || AH, AG<br />
|-<br />
| South Korea || Korea || KF, KH, KM<br />
|-<br />
| China (iQue) || China || CF, CH, CM<br />
|}<br />
<br />
== Console Models ==<br />
<br />
{| class="wikitable"<br />
! Device !! Product Code<br />
|-<br />
| ''DS'' || NTR<br />
|-<br />
| ''DS lite'' || USG<br />
|-<br />
| ''DSi'' || TWL<br />
|-<br />
| ''DSi XL/LL'' || UTL<br />
|-<br />
| ''Wii U'' || WUP<br />
|-<br />
| 3DS || CTR<br />
|-<br />
| 3DS XL/LL || SPR<br />
|-<br />
| 2DS || FTR<br />
|-<br />
| [[New 3DS]] || KTR<br />
|-<br />
| [[New 3DS]] XL/LL || RED<br />
|-<br />
| New 2DS XL/LL || JAN<br />
|}<br />
<br />
The DS had the product code NTR (short for Nitro), so we see the TR is recurring.<br />
<br />
== Title ID and Unique ID ==<br />
''see [[Titles]]''<br />
<br />
== NCCH Product Code ==<br />
<br />
This serial is similiar to the "physical serial" described later in this page; it is the canonical identifier for a specific title in the field of business formalities with Nintendo, but this is not reflected in the 3DS's software architecture (where it is vastly unused in favor of the Title ID: it is therefore considered the successor of the "internal name" contained in ROMs of previous handhelds), is not guaranteed to be unique.<br />
<br />
The product code is located in a [[NCCH]]'s header (not its ExHeader).<br />
<br />
The product code "CTR-P-CTAP" is the default generic product code for NCCH files. Most [[NCSD|NCCHs apart from the first one]] in a title are generally CTR-P-CTAP.<br />
Referring to "the product code of a title" is therefore a simplification for "the product code of the NCCH in its first partition".<br />
<br />
So, for example, a Japanese copy of Ridge Racer 3D would have a product code of "CTR-P-ARRJ" and a serial of "LNA-CTR-ARRJ-JPN".<br />
<br />
A Nintendo-assigned product code follows this format, however, there is no requirement for a product code to match or resemble this structure as long as it's within the length limit:<br />
<br />
[CTR/KTR]-[Category letter]-[Type][Identifier][Region]-[Sub ID]<br />
<br />
{| class="wikitable"<br />
! Category letter !! Description<br />
|-<br />
| P || Cartridge software, or downloadable versions of them.<br />
|-<br />
| N || Digital-only releases, including [[Title list|system applications and applets]].<br />
|-<br />
| M || [[DLC]]<br />
|-<br />
| T || [[eShop Demos]], excluding so-called "special demos" which are category N.<br />
|-<br />
| U || [[Title list#0004000E - Add-on Content (Updates)|Patches]] for category P titles.<br />
|}<br />
<br />
The "sub ID" only applies to DLC, demos, and local copies of Download Play titles. It's a 2-digit number associated with the [[Title list|Title ID Variation]].<br />
<br />
See the next chapter for explanation of the other components of the Product Code.<br />
<br />
== Physical Serial ==<br />
<br />
[Product][Retail/Demo]-CTR-[Type][Identifier][Region]-[Label Region]<br />
<br />
{| class="wikitable"<br />
! Field !! Length !! Description !! colspan=2 | Values<br />
|-<br />
|-align=center<br />
| rowspan="6" | Product<br />
| rowspan="6" | 2<br />
| rowspan="6" | Product type<br />
|-<br />
| LN || Cartridge<br />
|-<br />
| MA || Instruction manual<br />
|-<br />
| TS || Game box<br />
|-<br />
| FA || Leaflet<br />
|-<br />
| MK || Quick-start Guide<br />
|-align=center<br />
| rowspan="3" | Retail/Demo<br />
| rowspan="3" | 1 <br />
| rowspan="3" |<br />
|-<br />
| A || Retail<br />
|-<br />
| Z || Demo<br />
|-align=center<br />
| rowspan="3" | CTR/KTR<br />
| rowspan="3" | 3<br />
| rowspan="3" | Platform<br />
|-<br />
| CTR || 3DS<br />
|-<br />
| KTR || New 3DS<br />
|-align=center<br />
| rowspan="11" | Type<br />
| rowspan="11" | 1<br />
| rowspan="11" | <br />
|-<br />
| A || Retail<br />
|-<br />
| B || <br />
|-<br />
| C || part of the default serial 'CTAP'<br />
|-<br />
| E || <br />
|-<br />
| H || used for built in applications like [[Mii Maker]]<br />
|-<br />
| J || normal eShop Title<br />
|-<br />
| K || unknown, seen in Mighty Gunvolt<br />
|-<br />
| S || usually a 3D Classics eShop title<br />
|-<br />
| P || used with GBA eShop titles<br />
|-<br />
| T || used with NES eShop titles<br />
|-align=center<br />
| Identifier<br />
| 2<br />
| colspan=3 |Game name (two alphanumeric characters)<br />
|-align=center<br />
| rowspan="10" | Region<br />
| rowspan="10" | 1<br />
| rowspan="10" | <br />
|-<br />
| E || English (US)<br />
|-<br />
| P || PAL (Europe/Australia)<br />
|-<br />
| J || Japanese (Japan)<br />
|-<br />
| K || Korean (Korea)<br />
|-<br />
| C || Chinese (China/Taiwan)<br />
|-<br />
| Y || Multiple regions<br />
|-<br />
| W || Tai'''w'''an(?) (Taiwan/Hong Kong)<br />
|-<br />
| Z || Multiple regions<br />
|-<br />
| A || All (region-free)<br />
|-<br />
|-align=center<br />
| rowspan="11" | Label Region<br />
| rowspan="11" | 3<br />
| rowspan="11" | <br />
|-<br />
| USA || USA<br />
|-<br />
| EUR || Europe<br />
|-<br />
| CAN || Canada<br />
|-<br />
| AUS || Australia<br />
|-<br />
| JPN || Japan<br />
|-<br />
| KOR || Korea<br />
|-<br />
| TWN || Taiwan/Hong Kong<br />
|-<br />
| CHT || Taiwan/Hong Kong ("Chinese-Traditional")<br />
|-<br />
| CHN || China<br />
|-<br />
| UKV || United Kingdom version(?) (United Kingdom)<br />
|}<br />
<br />
=== Electronic Manuals ===<br />
<br />
Some eShop titles have [[NCCH#CFA|Electronic Manuals]] which store the product code at the end of the 'Health & Safety' section of the manual. However, product codes can differ from the above format as shown below:<br />
<br />
CTR-[P/N/T/U]-[Type][Identifier][Region]-[Region]-[Digit]<br />
<br />
CTR-[Type][Identifier][Region]-[Region]-[Digit]<br />
<br />
* P/N/T/U - Same as in product code structure<br />
* [Type][Identifier][Region] - Same as in serial structure<br />
* [Region] - A three character representation of the title region, i.e. 'EUR' (not always present)<br />
* [Digit] - A single digit usually '1' or '0' (not always present). Possibly revision or manual revision.<br />
<br />
'''Note:''' These alternate versions of the product code, potentially found in [[NCCH#CFA|Electronic Manuals]] don't represent the actual product code, as found in the game's CXI. They are only found in the game's Home Menu manual, and on the game's packaging and external labeling.<br />
<br />
==Back of Card Serial==<br />
AREPY10111 (example)<br />
<br />
AAAABCDEEE (presumably)<br/><br />
'''A''' - Identifier (last 4 digits of product code)<br/><br />
'''B''' - Production Month (X,Y,Z -> Oct,Nov,Dec)<br/><br />
'''C''' - Production Year (2010 + C)<br/><br />
'''D''' - Revision<br/><br />
'''E''' - Production Run? (000-999)</div>Myriahttps://www.3dbrew.org/w/index.php?title=Serials&diff=20601Serials2018-02-18T05:48:10Z<p>Myria: /* Physical Serial */ Formatting fix</p>
<hr />
<div>This page talks about the 3DS products' serial number and model number structures (the console, manual, accessories, games, etc...).<br />
<br />
== Console Serial Numbers ==<br />
<br />
A 3DS console serial number is composed of at least two letters followed by nine decimal digits. The ninth digit is a "check digit", meaning that it is derived from the other digits.<br />
<br />
The check digit is an industry-standard algorithm, the one used for UPC codes. To calculate the check digit of a 3DS console, separate the non-check digits into "odd" and "even" groups, where the "odd" group is digits in odd-numbered positions, and the "even" group is digits in even-numbered positions. (The first digit is "odd", with "first" representing "1".)<br />
<br />
After separating the digits, add the digits in each group together. Multiply the sum of the even digits by 3, then add the sum of the odd digits. To calculate the check digit, take this value modulo 10, and if not 0, subtract from 10.<br />
<br />
Example: CW404567772<br />
<br />
The non-check digits are 40456777. Separating into odd and even groups, we get the following:<br />
<br />
Odds: 4 + 4 + 6 + 7 = 21<br />
Evens: 0 + 5 + 7 + 7 = 19<br />
<br />
Applying the algorithm, we get ((3 * 19) + 21) % 10 = 8, which is not 0, thus 10 - 8 = 2, matching the example's check digit.<br />
<br />
The letter prefixes are a letter specifying the device, followed by one letter specifying the region in which it was sold. In some regions, a third letter is present; a current guess is that this letter distinguishes among factories for a given sales region. Note that several different sales regions' console may be considered to be the same region for region-locking purposes, such as Europe and Australia.<br />
<br />
The current serial number scheme began with the DSi, hence its listing in the tables below. Among standalone consoles, the Wii U belongs to this scheme as well; the Switch started a new scheme.<br />
<br />
{| class="wikitable"<br />
! Model !! Device Prefix (Retail) !! Device Prefix (Dev/Test)<br />
|-<br />
| ''DSi'' || T || V<br />
|-<br />
| ''DSi XL/LL'' || W || ''unknown''<br />
|-<br />
| ''Wii U'' || F || ''unknown''<br />
|-<br />
| 3DS || C || E<br />
|-<br />
| 3DS XL/LL || S || R<br />
|-<br />
| 2DS || A || P<br />
|-<br />
| New 3DS || Y || Y<br />
|-<br />
| New 3DS XL/LL || Q || Q<br />
|-<br />
| New 2DS XL/LL || N || N<br />
|}<br />
<br />
Test ("Panda") units with the same prefix as retail can be distinguished by test units having 00 or 01 as the first two digits of the serial number portion. 00 was used with the New 3DS and New 3DS XL for test units; 01 was used with the New 2DS XL test unit. Preview versions of the N2DS XL given out to the press had 01; these appear to have been test units with the development titles deleted.<br />
<br />
Old 3DS development systems (Partner-CTR, IS-CTR-BOX, IS-SPR-BOX) use the "E" and "R" prefixes like test systems, but have 90 (Partner-CTR) or 91 (IS-CTR-BOX, IS-SPR-BOX) as their first two digits. Similarly, the main New 3DS development unit, IS-SNAKE-BOX, uses the Y prefix (same as retail) with 91. It is currently unknown what is the serial number format of the rare New 3DS XL development system (IS-CLOSER-BOX).<br />
<br />
{| class="wikitable"<br />
! Sales Region !! Region Lock !! Region Suffix<br />
|-<br />
| Japan || Japan || JF, JH, JM<br />
|-<br />
| North America || North America || W<br />
|-<br />
| Middle East / Southeast Asia || North America || S<br />
|-<br />
| Europe || Europe || EF, EH, EM<br />
|-<br />
| Australia || Europe || AH, AG<br />
|-<br />
| South Korea || Korea || KF, KH, KM<br />
|-<br />
| China (iQue) || China || CF, CH, CM<br />
|}<br />
<br />
== Console Models ==<br />
<br />
{| class="wikitable"<br />
! Device !! Product Code<br />
|-<br />
| ''DS'' || NTR<br />
|-<br />
| ''DS lite'' || USG<br />
|-<br />
| ''DSi'' || TWL<br />
|-<br />
| ''DSi XL/LL'' || UTL<br />
|-<br />
| ''Wii U'' || WUP<br />
|-<br />
| 3DS || CTR<br />
|-<br />
| 3DS XL/LL || SPR<br />
|-<br />
| 2DS || FTR<br />
|-<br />
| [[New 3DS]] || KTR<br />
|-<br />
| [[New 3DS]] XL/LL || RED<br />
|-<br />
| New 2DS XL/LL || JAN<br />
|}<br />
<br />
The DS had the product code NTR (short for Nitro), so we see the TR is recurring.<br />
<br />
== Title ID and Unique ID ==<br />
''see [[Titles]]''<br />
<br />
== NCCH Product Code ==<br />
<br />
This serial is similiar to the "physical serial" described later in this page; it is the canonical identifier for a specific title in the field of business formalities with Nintendo, but this is not reflected in the 3DS's software architecture (where it is vastly unused in favor of the Title ID: it is therefore considered the successor of the "internal name" contained in ROMs of previous handhelds), is not guaranteed to be unique.<br />
<br />
The product code is located in a [[NCCH]]'s header (not its ExHeader).<br />
<br />
The product code "CTR-P-CTAP" is the default generic product code for NCCH files. Most [[NCSD|NCCHs apart from the first one]] in a title are generally CTR-P-CTAP.<br />
Referring to "the product code of a title" is therefore a simplification for "the product code of the NCCH in its first partition".<br />
<br />
So, for example, a Japanese copy of Ridge Racer 3D would have a product code of "CTR-P-ARRJ" and a serial of "LNA-CTR-ARRJ-JPN".<br />
<br />
A Nintendo-assigned product code follows this format, however, there is no requirement for a product code to match or resemble this structure as long as it's within the length limit:<br />
<br />
[CTR/KTR]-[Category letter]-[Type][Identifier][Region]-[Sub ID]<br />
<br />
{| class="wikitable"<br />
! Category letter !! Description<br />
|-<br />
| P || Cartridge software, or downloadable versions of them.<br />
|-<br />
| N || Digital-only releases, including [[Title list|system applications and applets]].<br />
|-<br />
| M || [[DLC]]<br />
|-<br />
| T || [[eShop Demos]], excluding so-called "special demos" which are category N.<br />
|-<br />
| U || [[Title list#0004000E - Add-on Content (Updates)|Patches]] for category P titles.<br />
|}<br />
<br />
The "sub ID" only applies to DLC, demos, and local copies of Download Play titles. It's a 2-digit number associated with the [[Title list|Title ID Variation]].<br />
<br />
See the next chapter for explanation of the other components of the Product Code.<br />
<br />
== Physical Serial ==<br />
<br />
[Product][Retail/Demo]-CTR-[Type][Identifier][Region]-[Label Region]<br />
<br />
{| class="wikitable"<br />
! Field !! Length !! Description !! colspan=2 | Values<br />
|-<br />
|-align=center<br />
| rowspan="6" | Product<br />
| rowspan="6" | 2<br />
| rowspan="6" | Product type<br />
|-<br />
| LN || Cartridge<br />
|-<br />
| MA || Instruction manual<br />
|-<br />
| TS || Game box<br />
|-<br />
| FA || Leaflet<br />
|-<br />
| MK || Quick-start Guide<br />
|-align=center<br />
| rowspan="3" | Retail/Demo<br />
| rowspan="3" | 1 <br />
| rowspan="3" |<br />
|-<br />
| A || Retail<br />
|-<br />
| Z || Demo<br />
|-align=center<br />
| rowspan="3" | CTR/KTR<br />
| rowspan="3" | 3<br />
| rowspan="3" | Platform<br />
|-<br />
| CTR || 3DS<br />
|-<br />
| KTR || New 3DS<br />
|-align=center<br />
| rowspan="11" | Type<br />
| rowspan="11" | 1<br />
| rowspan="11" | <br />
|-<br />
| A || Retail<br />
|-<br />
| B || <br />
|-<br />
| C || part of the default serial 'CTAP'<br />
|-<br />
| E || <br />
|-<br />
| H || used for built in applications like [[Mii Maker]]<br />
|-<br />
| J || normal eShop Title<br />
|-<br />
| K || unknown, seen in Mighty Gunvolt<br />
|-<br />
| S || usually a 3D Classics eShop title<br />
|-<br />
| P || used with GBA eShop titles<br />
|-<br />
| T || used with NES eShop titles<br />
|-align=center<br />
| Identifier<br />
| 2<br />
| colspan=3 |Game name (two alphanumeric characters)<br />
|-align=center<br />
| rowspan="10" | Region<br />
| rowspan="10" | 1<br />
| rowspan="10" | <br />
|-<br />
| E || English (US)<br />
|-<br />
| P || PAL (Europe/Australia)<br />
|-<br />
| J || Japanese (Japan)<br />
|-<br />
| K || Korean (Korea)<br />
|-<br />
| C || Chinese (China/Taiwan)<br />
|-<br />
| Y || Multiple regions<br />
|-<br />
| W || Tai'''w'''an(?) (Taiwan/Hong Kong)<br />
|-<br />
| Z || Multiple regions<br />
|-<br />
| A || All (region-free)<br />
|-<br />
|-align=center<br />
| rowspan="10" | Label Region<br />
| rowspan="10" | 3<br />
| rowspan="10" | <br />
|-<br />
| USA || USA<br />
|-<br />
| EUR || Europe<br />
|-<br />
| CAN || Canada<br />
|-<br />
| AUS || Australia<br />
|-<br />
| JPN || Japan<br />
|-<br />
| KOR || Korea<br />
|-<br />
| TWN || Taiwan/Hong Kong<br />
|-<br />
| CHN || China<br />
|-<br />
| UKV || United Kingdom version(?) (United Kingdom)<br />
|}<br />
<br />
=== Electronic Manuals ===<br />
<br />
Some eShop titles have [[NCCH#CFA|Electronic Manuals]] which store the product code at the end of the 'Health & Safety' section of the manual. However, product codes can differ from the above format as shown below:<br />
<br />
CTR-[P/N/T/U]-[Type][Identifier][Region]-[Region]-[Digit]<br />
<br />
CTR-[Type][Identifier][Region]-[Region]-[Digit]<br />
<br />
* P/N/T/U - Same as in product code structure<br />
* [Type][Identifier][Region] - Same as in serial structure<br />
* [Region] - A three character representation of the title region, i.e. 'EUR' (not always present)<br />
* [Digit] - A single digit usually '1' or '0' (not always present). Possibly revision or manual revision.<br />
<br />
'''Note:''' These alternate versions of the product code, potentially found in [[NCCH#CFA|Electronic Manuals]] don't represent the actual product code, as found in the game's CXI. They are only found in the game's Home Menu manual, and on the game's packaging and external labeling.<br />
<br />
==Back of Card Serial==<br />
AREPY10111 (example)<br />
<br />
AAAABCDEEE (presumably)<br/><br />
'''A''' - Identifier (last 4 digits of product code)<br/><br />
'''B''' - Production Month (X,Y,Z -> Oct,Nov,Dec)<br/><br />
'''C''' - Production Year (2010 + C)<br/><br />
'''D''' - Revision<br/><br />
'''E''' - Production Run? (000-999)</div>Myriahttps://www.3dbrew.org/w/index.php?title=Serials&diff=20600Serials2018-02-18T05:41:59Z<p>Myria: /* Physical Serial */ I have an Australian A Link Between Worlds and it's AUS</p>
<hr />
<div>This page talks about the 3DS products' serial number and model number structures (the console, manual, accessories, games, etc...).<br />
<br />
== Console Serial Numbers ==<br />
<br />
A 3DS console serial number is composed of at least two letters followed by nine decimal digits. The ninth digit is a "check digit", meaning that it is derived from the other digits.<br />
<br />
The check digit is an industry-standard algorithm, the one used for UPC codes. To calculate the check digit of a 3DS console, separate the non-check digits into "odd" and "even" groups, where the "odd" group is digits in odd-numbered positions, and the "even" group is digits in even-numbered positions. (The first digit is "odd", with "first" representing "1".)<br />
<br />
After separating the digits, add the digits in each group together. Multiply the sum of the even digits by 3, then add the sum of the odd digits. To calculate the check digit, take this value modulo 10, and if not 0, subtract from 10.<br />
<br />
Example: CW404567772<br />
<br />
The non-check digits are 40456777. Separating into odd and even groups, we get the following:<br />
<br />
Odds: 4 + 4 + 6 + 7 = 21<br />
Evens: 0 + 5 + 7 + 7 = 19<br />
<br />
Applying the algorithm, we get ((3 * 19) + 21) % 10 = 8, which is not 0, thus 10 - 8 = 2, matching the example's check digit.<br />
<br />
The letter prefixes are a letter specifying the device, followed by one letter specifying the region in which it was sold. In some regions, a third letter is present; a current guess is that this letter distinguishes among factories for a given sales region. Note that several different sales regions' console may be considered to be the same region for region-locking purposes, such as Europe and Australia.<br />
<br />
The current serial number scheme began with the DSi, hence its listing in the tables below. Among standalone consoles, the Wii U belongs to this scheme as well; the Switch started a new scheme.<br />
<br />
{| class="wikitable"<br />
! Model !! Device Prefix (Retail) !! Device Prefix (Dev/Test)<br />
|-<br />
| ''DSi'' || T || V<br />
|-<br />
| ''DSi XL/LL'' || W || ''unknown''<br />
|-<br />
| ''Wii U'' || F || ''unknown''<br />
|-<br />
| 3DS || C || E<br />
|-<br />
| 3DS XL/LL || S || R<br />
|-<br />
| 2DS || A || P<br />
|-<br />
| New 3DS || Y || Y<br />
|-<br />
| New 3DS XL/LL || Q || Q<br />
|-<br />
| New 2DS XL/LL || N || N<br />
|}<br />
<br />
Test ("Panda") units with the same prefix as retail can be distinguished by test units having 00 or 01 as the first two digits of the serial number portion. 00 was used with the New 3DS and New 3DS XL for test units; 01 was used with the New 2DS XL test unit. Preview versions of the N2DS XL given out to the press had 01; these appear to have been test units with the development titles deleted.<br />
<br />
Old 3DS development systems (Partner-CTR, IS-CTR-BOX, IS-SPR-BOX) use the "E" and "R" prefixes like test systems, but have 90 (Partner-CTR) or 91 (IS-CTR-BOX, IS-SPR-BOX) as their first two digits. Similarly, the main New 3DS development unit, IS-SNAKE-BOX, uses the Y prefix (same as retail) with 91. It is currently unknown what is the serial number format of the rare New 3DS XL development system (IS-CLOSER-BOX).<br />
<br />
{| class="wikitable"<br />
! Sales Region !! Region Lock !! Region Suffix<br />
|-<br />
| Japan || Japan || JF, JH, JM<br />
|-<br />
| North America || North America || W<br />
|-<br />
| Middle East / Southeast Asia || North America || S<br />
|-<br />
| Europe || Europe || EF, EH, EM<br />
|-<br />
| Australia || Europe || AH, AG<br />
|-<br />
| South Korea || Korea || KF, KH, KM<br />
|-<br />
| China (iQue) || China || CF, CH, CM<br />
|}<br />
<br />
== Console Models ==<br />
<br />
{| class="wikitable"<br />
! Device !! Product Code<br />
|-<br />
| ''DS'' || NTR<br />
|-<br />
| ''DS lite'' || USG<br />
|-<br />
| ''DSi'' || TWL<br />
|-<br />
| ''DSi XL/LL'' || UTL<br />
|-<br />
| ''Wii U'' || WUP<br />
|-<br />
| 3DS || CTR<br />
|-<br />
| 3DS XL/LL || SPR<br />
|-<br />
| 2DS || FTR<br />
|-<br />
| [[New 3DS]] || KTR<br />
|-<br />
| [[New 3DS]] XL/LL || RED<br />
|-<br />
| New 2DS XL/LL || JAN<br />
|}<br />
<br />
The DS had the product code NTR (short for Nitro), so we see the TR is recurring.<br />
<br />
== Title ID and Unique ID ==<br />
''see [[Titles]]''<br />
<br />
== NCCH Product Code ==<br />
<br />
This serial is similiar to the "physical serial" described later in this page; it is the canonical identifier for a specific title in the field of business formalities with Nintendo, but this is not reflected in the 3DS's software architecture (where it is vastly unused in favor of the Title ID: it is therefore considered the successor of the "internal name" contained in ROMs of previous handhelds), is not guaranteed to be unique.<br />
<br />
The product code is located in a [[NCCH]]'s header (not its ExHeader).<br />
<br />
The product code "CTR-P-CTAP" is the default generic product code for NCCH files. Most [[NCSD|NCCHs apart from the first one]] in a title are generally CTR-P-CTAP.<br />
Referring to "the product code of a title" is therefore a simplification for "the product code of the NCCH in its first partition".<br />
<br />
So, for example, a Japanese copy of Ridge Racer 3D would have a product code of "CTR-P-ARRJ" and a serial of "LNA-CTR-ARRJ-JPN".<br />
<br />
A Nintendo-assigned product code follows this format, however, there is no requirement for a product code to match or resemble this structure as long as it's within the length limit:<br />
<br />
[CTR/KTR]-[Category letter]-[Type][Identifier][Region]-[Sub ID]<br />
<br />
{| class="wikitable"<br />
! Category letter !! Description<br />
|-<br />
| P || Cartridge software, or downloadable versions of them.<br />
|-<br />
| N || Digital-only releases, including [[Title list|system applications and applets]].<br />
|-<br />
| M || [[DLC]]<br />
|-<br />
| T || [[eShop Demos]], excluding so-called "special demos" which are category N.<br />
|-<br />
| U || [[Title list#0004000E - Add-on Content (Updates)|Patches]] for category P titles.<br />
|}<br />
<br />
The "sub ID" only applies to DLC, demos, and local copies of Download Play titles. It's a 2-digit number associated with the [[Title list|Title ID Variation]].<br />
<br />
See the next chapter for explanation of the other components of the Product Code.<br />
<br />
== Physical Serial ==<br />
<br />
[Product][Retail/Demo]-CTR-[Type][Identifier][Region]-[Label Region]<br />
<br />
{| class="wikitable"<br />
! Field !! Length !! Description !! colspan=2 | Values<br />
|-<br />
|-align=center<br />
| rowspan="6" | Product<br />
| rowspan="6" | 2<br />
| rowspan="6" | Product type<br />
|-<br />
| LN || Cartridge<br />
|-<br />
| MA || Instruction manual<br />
|-<br />
| TS || Game box<br />
|-<br />
| FA || Leaflet<br />
|-<br />
| MK || Quick-start Guide<br />
|-align=center<br />
| rowspan="3" | Retail/Demo<br />
| rowspan="3" | 1 <br />
| rowspan="3" |<br />
|-<br />
| A || Retail<br />
|-<br />
| Z || Demo<br />
|-align=center<br />
| rowspan="3" | CTR/KTR<br />
| rowspan="3" | 3<br />
| rowspan="3" | Platform<br />
|-<br />
| CTR || 3DS<br />
|-<br />
| KTR || New 3DS<br />
|-align=center<br />
| rowspan="11" | Type<br />
| rowspan="11" | 1<br />
| rowspan="11" | <br />
|-<br />
| A || Retail<br />
|-<br />
| B || <br />
|-<br />
| C || part of the default serial 'CTAP'<br />
|-<br />
| E || <br />
|-<br />
| H || used for built in applications like [[Mii Maker]]<br />
|-<br />
| J || normal eShop Title<br />
|-<br />
| K || unknown, seen in Mighty Gunvolt<br />
|-<br />
| S || usually a 3D Classics eShop title<br />
|-<br />
| P || used with GBA eShop titles<br />
|-<br />
| T || used with NES eShop titles<br />
|-align=center<br />
| Identifier<br />
| 2<br />
| colspan=3 |Game name (two alphanumeric characters)<br />
|-align=center<br />
| rowspan="10" | Region<br />
| rowspan="10" | 1<br />
| rowspan="10" | <br />
|-<br />
| E || English (US)<br />
|-<br />
| P || PAL (Europe/Australia)<br />
|-<br />
| J || Japanese (Japan)<br />
|-<br />
| K || Korean (Korea)<br />
|-<br />
| C || Chinese (China/Taiwan)<br />
|-<br />
| Y || Multiple regions<br />
|-<br />
| W || Tai'''w'''an(?) (Taiwan/Hong Kong)<br />
|-<br />
| Z || Multiple regions<br />
|-<br />
| A || All (region-free)<br />
|-<br />
|-align=center<br />
| rowspan="9" | Label Region<br />
| rowspan="9" | 3<br />
| rowspan="9" | <br />
|-<br />
| USA || USA<br />
|-<br />
| EUR || Europe<br />
|-<br />
| CAN || Canada<br />
|-<br />
| AUS || Australia<br />
|-<br />
| JPN || Japan<br />
|-<br />
| KOR || Korea<br />
|-<br />
| TWN || Taiwan/Hong Kong<br />
|-<br />
| CHN || China<br />
|-<br />
| UKV || United Kingdom version(?) (United Kingdom)<br />
|}<br />
<br />
=== Electronic Manuals ===<br />
<br />
Some eShop titles have [[NCCH#CFA|Electronic Manuals]] which store the product code at the end of the 'Health & Safety' section of the manual. However, product codes can differ from the above format as shown below:<br />
<br />
CTR-[P/N/T/U]-[Type][Identifier][Region]-[Region]-[Digit]<br />
<br />
CTR-[Type][Identifier][Region]-[Region]-[Digit]<br />
<br />
* P/N/T/U - Same as in product code structure<br />
* [Type][Identifier][Region] - Same as in serial structure<br />
* [Region] - A three character representation of the title region, i.e. 'EUR' (not always present)<br />
* [Digit] - A single digit usually '1' or '0' (not always present). Possibly revision or manual revision.<br />
<br />
'''Note:''' These alternate versions of the product code, potentially found in [[NCCH#CFA|Electronic Manuals]] don't represent the actual product code, as found in the game's CXI. They are only found in the game's Home Menu manual, and on the game's packaging and external labeling.<br />
<br />
==Back of Card Serial==<br />
AREPY10111 (example)<br />
<br />
AAAABCDEEE (presumably)<br/><br />
'''A''' - Identifier (last 4 digits of product code)<br/><br />
'''B''' - Production Month (X,Y,Z -> Oct,Nov,Dec)<br/><br />
'''C''' - Production Year (2010 + C)<br/><br />
'''D''' - Revision<br/><br />
'''E''' - Production Run? (000-999)</div>Myriahttps://www.3dbrew.org/w/index.php?title=Serials&diff=20088Serials2017-06-15T08:46:07Z<p>Myria: /* Console Serial Numbers */ IS-SNAKE-BOX is Yx91.</p>
<hr />
<div>This page talks about the 3DS products' serial number and model number structures (the console, manual, accessories, games, etc...).<br />
<br />
== Console Serial Numbers ==<br />
<br />
A 3DS console serial number is composed of at least two letters followed by nine decimal digits. The ninth digit is a "check digit", meaning that it is derived from the other digits.<br />
<br />
The check digit is an industry-standard algorithm, the one used for UPC codes. To calculate the check digit of a 3DS console, separate the non-check digits into "odd" and "even" groups, where the "odd" group is digits in odd-numbered positions, and the "even" group is digits in even-numbered positions. (The first digit is "odd", with "first" representing "1".)<br />
<br />
After separating the digits, add the digits in each group together. Multiply the sum of the even digits by 3, then add the sum of the odd digits. To calculate the check digit, take this value modulo 10, and if not 0, subtract from 10.<br />
<br />
Example: CW404567772<br />
<br />
The non-check digits are 40456777. Separating into odd and even groups, we get the following:<br />
<br />
Odds: 4 + 4 + 6 + 7 = 21<br />
Evens: 0 + 5 + 7 + 7 = 19<br />
<br />
Applying the algorithm, we get ((3 * 19) + 21) % 10 = 8, which is not 0, thus 10 - 8 = 2, matching the example's check digit.<br />
<br />
The letter prefixes are a letter specifying the device, followed by one letter specifying the region in which it was sold. In some regions, a third letter is present; a current guess is that this letter distinguishes among factories for a given sales region. Note that several different sales regions' console may be considered to be the same region for region-locking purposes, such as Europe and Australia.<br />
<br />
The current serial number scheme began with the DSi, hence its listing in the tables below. Among standalone consoles, the Wii U belongs to this scheme as well; the Switch started a new scheme.<br />
<br />
{| class="wikitable"<br />
! Model !! Device Prefix (Retail) !! Device Prefix (Dev/Test)<br />
|-<br />
| ''DSi'' || T || V<br />
|-<br />
| ''DSi XL/LL'' || W || ''unknown''<br />
|-<br />
| ''Wii U'' || F || ''unknown''<br />
|-<br />
| 3DS || C || E<br />
|-<br />
| 3DS XL/LL || S || R<br />
|-<br />
| 2DS || A || P<br />
|-<br />
| New 3DS || Y || Y<br />
|-<br />
| New 3DS XL/LL || Q || Q<br />
|-<br />
| New 2DS XL/LL || N || N<br />
|}<br />
<br />
Test ("Panda") units with the same prefix as retail can be distinguished by test units having 00 or 01 as the first two digits of the serial number portion. 00 was used with the New 3DS and New 3DS XL for test units; 01 was used with the New 2DS XL test unit. Preview versions of the N2DS XL given out to the press had 01; these appear to have been test units with the development titles deleted.<br />
<br />
Old 3DS development systems (Partner-CTR, IS-CTR-BOX, IS-SPR-BOX) use the "E" and "R" prefixes like test systems, but have 90 (Partner-CTR) or 91 (IS-CTR-BOX, IS-SPR-BOX) as their first two digits. Similarly, the main New 3DS development unit, IS-SNAKE-BOX, uses the Y prefix (same as retail) with 91. It is currently unknown what is the serial number format of the rare New 3DS XL development system (IS-CLOSER-BOX).<br />
<br />
{| class="wikitable"<br />
! Sales Region !! Region Lock !! Region Suffix<br />
|-<br />
| Japan || Japan || JF, JH, JM<br />
|-<br />
| North America || North America || W<br />
|-<br />
| Middle East / Southeast Asia || North America || S<br />
|-<br />
| Europe || Europe || EF, EH, EM<br />
|-<br />
| Australia || Europe || AH, AG<br />
|-<br />
| South Korea || Korea || KF, KH, KM<br />
|-<br />
| China (iQue) || China || CF, CH, CM<br />
|}<br />
<br />
== Console Models ==<br />
<br />
{| class="wikitable"<br />
! Device !! Product Code<br />
|-<br />
| ''DS'' || NTR<br />
|-<br />
| ''DS lite'' || USG<br />
|-<br />
| ''DSi'' || TWL<br />
|-<br />
| ''DSi XL/LL'' || UTL<br />
|-<br />
| ''Wii U'' || WUP<br />
|-<br />
| 3DS || CTR<br />
|-<br />
| 3DS XL/LL || SPR<br />
|-<br />
| 2DS || FTR<br />
|-<br />
| [[New 3DS]] || KTR<br />
|-<br />
| [[New 3DS]] XL/LL || RED<br />
|-<br />
| New 2DS XL/LL || JAN<br />
|}<br />
<br />
The DS had the product code NTR (short for Nitro), so we see the TR is recurring.<br />
<br />
== Title ID and Unique ID ==<br />
''see [[Titles]]''<br />
<br />
== NCCH Product Code ==<br />
<br />
This serial is similiar to the "physical serial" described later in this page; it is the canonical identifier for a specific title in the field of business formalities with Nintendo, but this is not reflected in the 3DS's software architecture (where it is vastly unused in favor of the Title ID: it is therefore considered the successor of the "internal name" contained in ROMs of previous handhelds), is not guaranteed to be unique.<br />
<br />
The product code is located in a [[NCCH]]'s header (not its ExHeader).<br />
<br />
The product code "CTR-P-CTAP" is the default generic product code for NCCH files. Most [[NCSD|NCCHs apart from the first one]] in a title are generally CTR-P-CTAP.<br />
Referring to "the product code of a title" is therefore a simplification for "the product code of the NCCH in its first partition".<br />
<br />
So, for example, a Japanese copy of Ridge Racer 3D would have a product code of "CTR-P-ARRJ" and a serial of "LNA-CTR-ARRJ-JPN".<br />
<br />
A Nintendo-assigned product code follows this format, however, there is no requirement for a product code to match or resemble this structure as long as it's within the length limit:<br />
<br />
[CTR/KTR]-[Category letter]-[Type][Identifier][Region]-[Sub ID]<br />
<br />
{| class="wikitable"<br />
! Category letter !! Description<br />
|-<br />
| P || Cartridge software, or downloadable versions of them.<br />
|-<br />
| N || Digital-only releases, including [[Title list|system applications and applets]].<br />
|-<br />
| M || [[DLC]]<br />
|-<br />
| T || [[eShop Demos]], excluding so-called "special demos" which are category N.<br />
|-<br />
| U || [[Title list#0004000E - Add-on Content (Updates)|Patches]] for category P titles.<br />
|}<br />
<br />
The "sub ID" only applies to DLC, demos, and local copies of Download Play titles. It's a 2-digit number associated with the [[Title list|Title ID Variation]].<br />
<br />
See the next chapter for explanation of the other components of the Product Code.<br />
<br />
== Physical Serial ==<br />
<br />
[Product][Retail/Demo]-CTR-[Type][Identifier][Region]-[Label Region]<br />
<br />
{| class="wikitable"<br />
! Field !! Length !! Description<br />
|-<br />
| Product || 2 || Product type (cartridges are LN, game boxes are TS, instruction manuals are MA, leaflets are FA, quick-start guides are MK)<br />
|-<br />
| Retail/Demo || 1 || Retail (A) or Demo (Z)<br />
|-<br />
| CTR/KTR || 3 || Platform. CTR = 3DS, KTR = New 3DS<br />
|-<br />
| Type || 1 || [A/C/H/J/K/S/P/T] - Retail / C is part of the default serial 'CTAP' / H is used for built in applications like [[Mii Maker]] / J is for a normal eShop Title / K is unknown, seen in Mighty Gunvolt / S is usually a 3D Classics eShop title / P is used with GBA eShop titles / T is used with NES eShop titles.<br />
|-<br />
| Identifier || 2 || game name (two alphanumeric characters).<br />
|-<br />
| Region || 1 || [E/P/J/K/C/Y/W/Z/A] - English (US) / PAL (Europe/Australia) / Japanese (Japan) / Korean (Korea) / Chinese (China/Taiwan) / Multiple regions / Tai'''w'''an(?) (Taiwan/Hong Kong) / Multiple regions / All (region-free)<br />
|-<br />
| Label Region || 3 || [USA/EUR/CAN/JPN/KOR/TWN/CHN/UKV] - USA / Europe / Canada / Japan / Korea / Taiwan/Hong Kong / China / United Kingdom version(?) (United Kingdom)<br />
|}<br />
<br />
=== Electronic Manuals ===<br />
<br />
Some eShop titles have [[NCCH#CFA|Electronic Manuals]] which store the product code at the end of the 'Health & Safety' section of the manual. However, product codes can differ from the above format as shown below:<br />
<br />
CTR-[P/N/T/U]-[Type][Identifier][Region]-[Region]-[Digit]<br />
<br />
CTR-[Type][Identifier][Region]-[Region]-[Digit]<br />
<br />
* P/N/T/U - Same as in product code structure<br />
* [Type][Identifier][Region] - Same as in serial structure<br />
* [Region] - A three character representation of the title region, i.e. 'EUR' (not always present)<br />
* [Digit] - A single digit usually '1' or '0' (not always present)<br />
<br />
'''Note:''' These alternate versions of the product code, potentially found in [[NCCH#CFA|Electronic Manuals]] don't represent the actual product code, as found in the game's CXI. They are only found in the game's Home Menu manual, and on the game's packaging and external labeling.<br />
<br />
==Back of Card Serial==<br />
AREPY10111<br />
<br />
AAAABCDEEE (presumably)<br />
<br />
[Identifier]-[Production Month]-[Production Year]-[Revision]-[Production Run?]</div>Myriahttps://www.3dbrew.org/w/index.php?title=Serials&diff=20087Serials2017-06-15T08:35:59Z<p>Myria: /* Console Serial Numbers */ Better explanation of first 2 digits. Retail Aus/NZ New 2DS XL systems have prefix "NAG".</p>
<hr />
<div>This page talks about the 3DS products' serial number and model number structures (the console, manual, accessories, games, etc...).<br />
<br />
== Console Serial Numbers ==<br />
<br />
A 3DS console serial number is composed of at least two letters followed by nine decimal digits. The ninth digit is a "check digit", meaning that it is derived from the other digits.<br />
<br />
The check digit is an industry-standard algorithm, the one used for UPC codes. To calculate the check digit of a 3DS console, separate the non-check digits into "odd" and "even" groups, where the "odd" group is digits in odd-numbered positions, and the "even" group is digits in even-numbered positions. (The first digit is "odd", with "first" representing "1".)<br />
<br />
After separating the digits, add the digits in each group together. Multiply the sum of the even digits by 3, then add the sum of the odd digits. To calculate the check digit, take this value modulo 10, and if not 0, subtract from 10.<br />
<br />
Example: CW404567772<br />
<br />
The non-check digits are 40456777. Separating into odd and even groups, we get the following:<br />
<br />
Odds: 4 + 4 + 6 + 7 = 21<br />
Evens: 0 + 5 + 7 + 7 = 19<br />
<br />
Applying the algorithm, we get ((3 * 19) + 21) % 10 = 8, which is not 0, thus 10 - 8 = 2, matching the example's check digit.<br />
<br />
The letter prefixes are a letter specifying the device, followed by one letter specifying the region in which it was sold. In some regions, a third letter is present; a current guess is that this letter distinguishes among factories for a given sales region. Note that several different sales regions' console may be considered to be the same region for region-locking purposes, such as Europe and Australia.<br />
<br />
The current serial number scheme began with the DSi, hence its listing in the tables below. Among standalone consoles, the Wii U belongs to this scheme as well; the Switch started a new scheme.<br />
<br />
{| class="wikitable"<br />
! Model !! Device Prefix (Retail) !! Device Prefix (Dev/Test)<br />
|-<br />
| ''DSi'' || T || V<br />
|-<br />
| ''DSi XL/LL'' || W || ''unknown''<br />
|-<br />
| ''Wii U'' || F || ''unknown''<br />
|-<br />
| 3DS || C || E<br />
|-<br />
| 3DS XL/LL || S || R<br />
|-<br />
| 2DS || A || P<br />
|-<br />
| New 3DS || Y || Y<br />
|-<br />
| New 3DS XL/LL || Q || Q<br />
|-<br />
| New 2DS XL/LL || N || N<br />
|}<br />
<br />
Test ("Panda") units with the same prefix as retail can be distinguished by test units having 00 or 01 as the first two digits of the serial number portion. 00 was used with the New 3DS and New 3DS XL for test units; 01 was used with the New 2DS XL test unit. Preview versions of the N2DS XL given out to the press had 01; these appear to have been test units with the development titles deleted.<br />
<br />
Old 3DS development systems (Partner-CTR, IS-CTR-BOX, IS-SPR-BOX) use the "E" and "R" prefixes like test systems, but have 90 (Partner-CTR) or 91 (IS-CTR-BOX, IS-SPR-BOX) as their first two digits. It is currently unknown what is the serial number format of New 3DS development systems (IS-SNAKE-BOX, IS-CLOSER-BOX).<br />
<br />
{| class="wikitable"<br />
! Sales Region !! Region Lock !! Region Suffix<br />
|-<br />
| Japan || Japan || JF, JH, JM<br />
|-<br />
| North America || North America || W<br />
|-<br />
| Middle East / Southeast Asia || North America || S<br />
|-<br />
| Europe || Europe || EF, EH, EM<br />
|-<br />
| Australia || Europe || AH, AG<br />
|-<br />
| South Korea || Korea || KF, KH, KM<br />
|-<br />
| China (iQue) || China || CF, CH, CM<br />
|}<br />
<br />
== Console Models ==<br />
<br />
{| class="wikitable"<br />
! Device !! Product Code<br />
|-<br />
| ''DS'' || NTR<br />
|-<br />
| ''DS lite'' || USG<br />
|-<br />
| ''DSi'' || TWL<br />
|-<br />
| ''DSi XL/LL'' || UTL<br />
|-<br />
| ''Wii U'' || WUP<br />
|-<br />
| 3DS || CTR<br />
|-<br />
| 3DS XL/LL || SPR<br />
|-<br />
| 2DS || FTR<br />
|-<br />
| [[New 3DS]] || KTR<br />
|-<br />
| [[New 3DS]] XL/LL || RED<br />
|-<br />
| New 2DS XL/LL || JAN<br />
|}<br />
<br />
The DS had the product code NTR (short for Nitro), so we see the TR is recurring.<br />
<br />
== Title ID and Unique ID ==<br />
''see [[Titles]]''<br />
<br />
== NCCH Product Code ==<br />
<br />
This serial is similiar to the "physical serial" described later in this page; it is the canonical identifier for a specific title in the field of business formalities with Nintendo, but this is not reflected in the 3DS's software architecture (where it is vastly unused in favor of the Title ID: it is therefore considered the successor of the "internal name" contained in ROMs of previous handhelds), is not guaranteed to be unique.<br />
<br />
The product code is located in a [[NCCH]]'s header (not its ExHeader).<br />
<br />
The product code "CTR-P-CTAP" is the default generic product code for NCCH files. Most [[NCSD|NCCHs apart from the first one]] in a title are generally CTR-P-CTAP.<br />
Referring to "the product code of a title" is therefore a simplification for "the product code of the NCCH in its first partition".<br />
<br />
So, for example, a Japanese copy of Ridge Racer 3D would have a product code of "CTR-P-ARRJ" and a serial of "LNA-CTR-ARRJ-JPN".<br />
<br />
A Nintendo-assigned product code follows this format, however, there is no requirement for a product code to match or resemble this structure as long as it's within the length limit:<br />
<br />
[CTR/KTR]-[Category letter]-[Type][Identifier][Region]-[Sub ID]<br />
<br />
{| class="wikitable"<br />
! Category letter !! Description<br />
|-<br />
| P || Cartridge software, or downloadable versions of them.<br />
|-<br />
| N || Digital-only releases, including [[Title list|system applications and applets]].<br />
|-<br />
| M || [[DLC]]<br />
|-<br />
| T || [[eShop Demos]], excluding so-called "special demos" which are category N.<br />
|-<br />
| U || [[Title list#0004000E - Add-on Content (Updates)|Patches]] for category P titles.<br />
|}<br />
<br />
The "sub ID" only applies to DLC, demos, and local copies of Download Play titles. It's a 2-digit number associated with the [[Title list|Title ID Variation]].<br />
<br />
See the next chapter for explanation of the other components of the Product Code.<br />
<br />
== Physical Serial ==<br />
<br />
[Product][Retail/Demo]-CTR-[Type][Identifier][Region]-[Label Region]<br />
<br />
{| class="wikitable"<br />
! Field !! Length !! Description<br />
|-<br />
| Product || 2 || Product type (cartridges are LN, game boxes are TS, instruction manuals are MA, leaflets are FA, quick-start guides are MK)<br />
|-<br />
| Retail/Demo || 1 || Retail (A) or Demo (Z)<br />
|-<br />
| CTR/KTR || 3 || Platform. CTR = 3DS, KTR = New 3DS<br />
|-<br />
| Type || 1 || [A/C/H/J/K/S/P/T] - Retail / C is part of the default serial 'CTAP' / H is used for built in applications like [[Mii Maker]] / J is for a normal eShop Title / K is unknown, seen in Mighty Gunvolt / S is usually a 3D Classics eShop title / P is used with GBA eShop titles / T is used with NES eShop titles.<br />
|-<br />
| Identifier || 2 || game name (two alphanumeric characters).<br />
|-<br />
| Region || 1 || [E/P/J/K/C/Y/W/Z/A] - English (US) / PAL (Europe/Australia) / Japanese (Japan) / Korean (Korea) / Chinese (China/Taiwan) / Multiple regions / Tai'''w'''an(?) (Taiwan/Hong Kong) / Multiple regions / All (region-free)<br />
|-<br />
| Label Region || 3 || [USA/EUR/CAN/JPN/KOR/TWN/CHN/UKV] - USA / Europe / Canada / Japan / Korea / Taiwan/Hong Kong / China / United Kingdom version(?) (United Kingdom)<br />
|}<br />
<br />
=== Electronic Manuals ===<br />
<br />
Some eShop titles have [[NCCH#CFA|Electronic Manuals]] which store the product code at the end of the 'Health & Safety' section of the manual. However, product codes can differ from the above format as shown below:<br />
<br />
CTR-[P/N/T/U]-[Type][Identifier][Region]-[Region]-[Digit]<br />
<br />
CTR-[Type][Identifier][Region]-[Region]-[Digit]<br />
<br />
* P/N/T/U - Same as in product code structure<br />
* [Type][Identifier][Region] - Same as in serial structure<br />
* [Region] - A three character representation of the title region, i.e. 'EUR' (not always present)<br />
* [Digit] - A single digit usually '1' or '0' (not always present)<br />
<br />
'''Note:''' These alternate versions of the product code, potentially found in [[NCCH#CFA|Electronic Manuals]] don't represent the actual product code, as found in the game's CXI. They are only found in the game's Home Menu manual, and on the game's packaging and external labeling.<br />
<br />
==Back of Card Serial==<br />
AREPY10111<br />
<br />
AAAABCDEEE (presumably)<br />
<br />
[Identifier]-[Production Month]-[Production Year]-[Revision]-[Production Run?]</div>Myriahttps://www.3dbrew.org/w/index.php?title=I2C_Registers&diff=20067I2C Registers2017-06-05T08:32:09Z<p>Myria: /* Device 3 */ found the f*cking system model register, finally</p>
<hr />
<div>= Registers =<br />
{| class="wikitable" border="1"<br />
! Old3DS<br />
! Name<br />
! Address<br />
! Width<br />
! Used by<br />
|-<br />
| style="background: green" | Yes<br />
| I2C1_DATA<br />
| 0x10161000<br />
| 1<br />
| I2C bus 1 devices<br />
|-<br />
| style="background: green" | Yes<br />
| [[#I2C_CNT|I2C1_CNT]]<br />
| 0x10161001<br />
| 1<br />
| I2C bus 1 devices<br />
|-<br />
| style="background: green" | Yes<br />
| I2C1_CNTEX<br />
| 0x10161002<br />
| 2<br />
| I2C bus 1 devices<br />
|-<br />
| style="background: green" | Yes<br />
| I2C1_SCL<br />
| 0x10161004<br />
| 2<br />
| I2C bus 1 devices<br />
|-<br />
| style="background: green" | Yes<br />
| I2C2_DATA<br />
| 0x10144000<br />
| 1<br />
| I2C bus 2 devices<br />
|-<br />
| style="background: green" | Yes<br />
| [[#I2C_CNT|I2C2_CNT]]<br />
| 0x10144001<br />
| 1<br />
| I2C bus 2 devices<br />
|-<br />
| style="background: green" | Yes<br />
| I2C2_CNTEX<br />
| 0x10144002<br />
| 2<br />
| I2C bus 2 devices<br />
|-<br />
| style="background: green" | Yes<br />
| I2C2_SCL<br />
| 0x10144004<br />
| 2<br />
| I2C bus 2 devices<br />
|-<br />
| style="background: green" | Yes<br />
| I2C3_DATA<br />
| 0x10148000<br />
| 1<br />
| I2C bus 3 devices<br />
|-<br />
| style="background: green" | Yes<br />
| [[#I2C_CNT|I2C3_CNT]]<br />
| 0x10148001<br />
| 1<br />
| I2C bus 3 devices<br />
|-<br />
| style="background: green" | Yes<br />
| I2C3_CNTEX<br />
| 0x10148002<br />
| 2<br />
| I2C bus 3 devices<br />
|-<br />
| style="background: green" | Yes<br />
| I2C3_SCL<br />
| 0x10148004<br />
| 2<br />
| I2C bus 3 devices<br />
|}<br />
<br />
== I2C_CNT ==<br />
{| class="wikitable" border="1"<br />
! BIT<br />
! DESCRIPTION<br />
|-<br />
| 0<br />
| Stop (0=No, 1=Stop/last byte)<br />
|-<br />
| 1<br />
| Start (0=No, 1=Start/first byte)<br />
|-<br />
| 2<br />
| Pause (0=Transfer Data, 1=Pause after Error, used with/after Stop)<br />
|-<br />
| 4<br />
| Ack Flag (0=Error, 1=Okay) (For DataRead: W, for DataWrite: R)<br />
|-<br />
| 5<br />
| Data Direction (0=Write, 1=Read)<br />
|-<br />
| 6<br />
| Interrupt Enable (0=Disable, 1=Enable)<br />
|-<br />
| 7<br />
| Start/busy (0=Ready, 1=Start/busy)<br />
|}<br />
<br />
= I2C Devices =<br />
{| class="wikitable" border="1"<br />
! [[I2C_Registers|Device id]]<br />
! Device bus id<br />
! Device Write Address<br />
! Accessible via I2C [[I2C_Services|service]]<br />
! Device description<br />
|-<br />
| 0<br />
| 1<br />
| 0x4a<br />
| "i2c::MCU"<br />
| Power management?(same device addr as the DSi power-management)<br />
|-<br />
| 1<br />
| 1<br />
| 0x7a<br />
| "i2c::CAM"<br />
| Camera0?(same dev-addr as DSi cam0)<br />
|-<br />
| 2<br />
| 1<br />
| 0x78<br />
| "i2c::CAM"<br />
| Camera1?(same dev-addr as DSi cam1)<br />
|-<br />
| 3<br />
| 2<br />
| 0x4a<br />
| "i2c::MCU"<br />
| MCU<br />
|-<br />
| 4<br />
| 2<br />
| 0x78<br />
| "i2c::CAM"<br />
| ?<br />
|-<br />
| 5<br />
| 2<br />
| 0x2c<br />
| "i2c::LCD"<br />
| ?<br />
|-<br />
| 6<br />
| 2<br />
| 0x2e<br />
| "i2c::LCD"<br />
| ?<br />
|-<br />
| 7<br />
| 2<br />
| 0x40<br />
| "i2c::DEB"<br />
| ?<br />
|-<br />
| 8<br />
| 2<br />
| 0x44<br />
| "i2c::DEB"<br />
| ?<br />
|-<br />
| 9<br />
| 3<br />
| 0xa6<br />
| "i2c::HID"<br />
| Unknown. The device table in I2C-module had the device address changed from 0xA6 to 0xD6 with [[8.0.0-18]].<br />
|-<br />
| 10<br />
| 3<br />
| 0xd0<br />
| "i2c::HID"<br />
| Gyroscope<br />
|-<br />
| 11<br />
| 3<br />
| 0xd2<br />
| "i2c::HID"<br />
| ?<br />
|-<br />
| 12<br />
| 3<br />
| 0xa4<br />
| "i2c::HID"<br />
| DebugPad<br />
|-<br />
| 13<br />
| 3<br />
| 0x9a<br />
| "i2c::IR"<br />
| IR<br />
|-<br />
| 14<br />
| 3<br />
| 0xa0<br />
| "i2c::EEP"<br />
| eeprom?<br />
|-<br />
| 15<br />
| 2<br />
| 0xee<br />
| "i2c::NFC"<br />
| New3DS-only [[NFC_Services|NFC]]<br />
|-<br />
| 16<br />
| 1<br />
| 0x40<br />
| "i2c::QTM"<br />
| New3DS-only [[QTM_Services|QTM]]<br />
|-<br />
| 17<br />
| 3<br />
| 0x54<br />
| "i2c::IR"<br />
| Used by IR-module starting with [[8.0.0-18]], for New3DS-only HID via "ir:rst". This deviceid doesn't seem to be supported by i2c module on [[8.0.0-18]](actual support was later added in New3DS i2c module).<br />
|}<br />
<br />
'''Notice''': These device addresses are used for writing to the respective device, for reading bit0 must be set (see I2C protocol). Thus, the actual device address is >> 1.<br />
<br />
== Device 3 ==<br />
{| class="wikitable" border="1"<br />
! REGISTER<br />
! WIDTH<br />
! INFO<br />
! DESCRIPTION <br />
|-<br />
| 0x00<br />
| s<br />
| ro<br />
| Version high<br />
|-<br />
| 0x01<br />
| s<br />
| ro<br />
| Version low<br />
|-<br />
| 0x02<br />
| s<br />
| ro<br />
| ?<br />
|-<br />
| 0x03<br />
| s<br />
| rw<br />
| Top screen flicker<br />
|-<br />
| 0x04<br />
| s<br />
| rw<br />
| Bottom screen flicker<br />
|-<br />
| 0x05<br />
| s / 0x4003?<br />
| rw / ?<br />
| Danger zone - [[MCU_Services#MCU_firmware_versions|MCU firmware]] is uploaded here (???)<br />
|-<br />
| 0x06<br />
| s<br />
| rw<br />
| ?<br />
|-<br />
| 0x07<br />
| s<br />
| rw<br />
| ?<br />
|-<br />
| 0x08<br />
| s<br />
| ro<br />
| Raw 3D slider position<br />
|-<br />
| 0x09<br />
| s<br />
| ro<br />
| Volume slider state (0x00 - 0x3F)<br />
This is the same value returned by [[MCUHWC:GetSoundVolume|MCUHWC:GetSoundVolume]]<br />
|-<br />
| 0x0A<br />
| s<br />
| ro<br />
| ? (seems to be power management related?)<br />
|-<br />
| 0x0B<br />
| s<br />
| ro<br />
| Battery percentage<br />
|-<br />
| 0x0C<br />
| s<br />
| ro<br />
| ? (changes to 0 for a second when the charger is plugged in then it resets to its previous value)<br />
|-<br />
| 0x0D<br />
| s<br />
| ro<br />
| System voltage<br />
|-<br />
| 0x0E<br />
| s<br />
| ro<br />
| ?<br />
|-<br />
| 0x0F<br />
| s<br />
| ro<br />
| Flags: bit7-5 are read via [[MCU_Services|mcu::GPU]]. The rest of these are read via [[MCU_Services|mcu::RTC]]: bit4 = BatteryChargeState. bit3 = AdapterState. bit1 = ShellState.<br />
|-<br />
| 0x10<br />
| s<br />
| ro<br />
| Special HID status flags: bit0 = power button pressed, bit1 = power button pressed long, bit2 = home button pressed, bit3 = home button released, bit4 = wifi slider enabled, bit5 = shell got closed, bit6 = shell got opened. If nothing has changed this register is 0.<br />
Needs confirmation (or some flags to enable).<br />
|-<br />
| 0x11<br />
| s<br />
| ro<br />
| ?<br />
|-<br />
| 0x12<br />
| s<br />
| ro<br />
| 0x40 if volume slider position changed<br />
Needs confirmation (or some flags to enable).<br />
|-<br />
| 0x13<br />
| s<br />
| ro<br />
| ?<br />
|-<br />
| 0x14<br />
| s<br />
| ro<br />
| ?<br />
|-<br />
| 0x15<br />
| s<br />
| rw<br />
| ?<br />
|-<br />
| 0x16<br />
| s<br />
| rw<br />
| ?<br />
|-<br />
| 0x17<br />
| s<br />
| rw<br />
| ?<br />
|-<br />
| 0x18<br />
| s<br />
| rw<br />
| ?<br />
|-<br />
| 0x19<br />
| s<br />
| rw<br />
| ?<br />
|-<br />
| 0x1A<br />
| s<br />
| rw<br />
| ?<br />
|-<br />
| 0x1B<br />
| s<br />
| rw<br />
| ?<br />
|-<br />
| 0x1C<br />
| s<br />
| rw<br />
| ?<br />
|-<br />
| 0x1D<br />
| s<br />
| rw<br />
| ?<br />
|-<br />
| 0x1E<br />
| s<br />
| rw<br />
| ?<br />
|-<br />
| 0x1F<br />
| s<br />
| rw<br />
| ?<br />
|-<br />
| 0x20<br />
| s<br />
| wo<br />
| System power control - bit0 = power off, bit1 = reboot (unused?). bit2 = reboot (used by mcu-module and LgyBg). bit3 = used by LgyBg to power off, causes hangs in 3DS-mode. bit4 = doesn't seem to do anything, but an mcu::RTC command uses this. Other bits are unused, and seem to do nothing.<br />
|-<br />
| 0x21<br />
| s<br />
| ro(?)<br />
| ?<br />
|-<br />
| 0x22<br />
| s<br />
| wo<br />
| Used to set LCD states. bit0 = don't push to LCDs, bit1 = push to LCDs, bit2 = bottom screen backlight off, bit3 = bottom screen backlight on, bit4 = top screen backlight off, bit5 = top screen backlight on<br />
|-<br />
| 0x23<br />
| s<br />
| ro(?)<br />
| ?<br />
|-<br />
| 0x24<br />
| s<br />
| ??<br />
| Watchdog timer. This must be set *before* the timer is triggered, otherwise the old value is used. Value zero disables the watchdog.<br />
|-<br />
| 0x25<br />
| s<br />
| rw<br />
| ?<br />
|-<br />
| 0x26<br />
| s<br />
| rw<br />
| ?<br />
|-<br />
| 0x27<br />
| s<br />
| ro (rw?)<br />
| Raw volume slider state<br />
|-<br />
| 0x28<br />
| s<br />
| rw<br />
| Brightness of the WiFi/Power LED<br />
|-<br />
| 0x29<br />
| dynamic / s<br />
| ro / rw<br />
| Repeat register, any byte written in the first byte gets repeated indefinitely(?, needs confirmation past 0xFF). The rest of the bytes are read-only. Setting the shared byte of this register (via overflow glitches) will also work, confirming that this is a semi-dynamic register as the first byte is stored in the shared register pool, but the rest of the bytes are fake.<br />
|-<br />
| 0x2A<br />
| s<br />
| rw<br />
| WiFi LED state, non-0 value turns on the WiFi LED, capped at 0x0F<br />
|-<br />
| 0x2B<br />
| s<br />
| rw<br />
| Camera LED state, 0, 3, 6-0xF = off, 1 = slowly blinking, 2 = constantly on, 4 = flash once, 5 = delay before changing to 2<br />
|-<br />
| 0x2C<br />
| s<br />
| rw<br />
| 3D LED state, capped at 0x0F<br />
|-<br />
| 0x2D<br />
| 0x64<br />
| wo<br />
| This is used for [[MCURTC:SetInfoLEDPattern|controlling]] the notification LED (see [[MCURTC:SetInfoLEDPatternHeader]] as well), when this register is written. It's possible to write data here with size less than 0x64, and only that portion of the pattern data will get overwritten. Reading from this register only returns zeroes, so it's considered write-only.<br />
|-<br />
| 0x2E<br />
| s<br />
| ro<br />
| This [[MCURTC:GetInfoLEDStatus|returns]] the notification LED status when read (1 means new cycle started)<br />
|-<br />
| 0x2F<br />
| s<br />
| ro(?)<br />
| ?<br />
|-<br />
| 0x30<br />
- 0x37<br />
| s<br />
| rw<br />
| RTC time (system clock). 7 bytes are read from this. The upper nibble of each byte encodes 10s (BCD), so each byte is post-processed with (byte & 0xF) + (10 * (byte >> 4)). Byte 0 encodes seconds, byte 1 minutes, byte 2 hours, byte *4* days, byte 5 months and byte 6 years (byte 3 is unused?)<br />
|-<br />
| 0x38<br />
| s<br />
| rw<br />
| ?<br />
|-<br />
| 0x39<br />
| s<br />
| rw<br />
| ?<br />
|-<br />
| 0x3A<br />
| s<br />
| rw<br />
| ?<br />
|-<br />
| 0x3B<br />
| s<br />
| rw<br />
| ?<br />
|-<br />
| 0x3C<br />
| s<br />
| rw<br />
| ?<br />
|-<br />
| 0x3D<br />
0x3E<br />
| s (2)<br />
| ro<br />
| RTC tick counter (resets to 0 when the seconds increase)<br />
|-<br />
| 0x3F<br />
| s<br />
| wo<br />
| Peripheral power related? bit0 seems to depower everything, pressing the power key afterwards instantly turns the whole 3DS off<br />
|-<br />
| 0x40<br />
| s<br />
| rw<br />
| ?<br />
|-<br />
| 0x41<br />
| s<br />
| rw<br />
| ?<br />
|-<br />
| 0x42<br />
| s<br />
| rw<br />
| ?<br />
|-<br />
| 0x43<br />
| s<br />
| rw<br />
| ?<br />
|-<br />
| 0x44<br />
| s<br />
| rw<br />
| ? (setting this seems to freeze the system for a second)<br />
|-<br />
| 0x45<br />
| s<br />
| rw<br />
| ?<br />
|-<br />
| 0x46<br />
| s<br />
| ro<br />
| Gyro Y(?) axis rotation (0x00 = flat, 0x40 = 3DS standing on right side, 0xBE = 3DS standing on left side)<br />
|-<br />
| 0x48<br />
| s<br />
| ro<br />
| Gyro Z(?) axis rotation (0x00 = flat, 0x40 = 3DS standing horizontally, 0xBE = 3DS base is horizontally upside-down)<br />
|-<br />
| 0x4A<br />
| s<br />
| ro<br />
| Gyro X(?) axis rotation (0x00 = 3DS base facing upwards, 0x40 = face-down flat, 0xBE = standing(?) flat)<br />
|-<br />
| 0x4B<br />
| s<br />
| rw<br />
| ? (setting this to 0xFF seems to freeze the system when trying to transition to Home Menu if some other registers are set accordingly)<br />
|-<br />
| 0x4C<br />
| s<br />
| rw<br />
| ?<br />
|-<br />
| 0x4D<br />
| s<br />
| rw<br />
| ?<br />
|-<br />
| 0x4E<br />
| s<br />
| rw<br />
| ?<br />
|-<br />
| 0x4F<br />
| 6(?)<br />
| ro<br />
| Unkonwn. Reading past the 6th byte is FF-filled, so register size of 6 is assumed.<br />
|-<br />
| 0x50<br />
- 0x57<br />
| s<br />
| rw<br />
| ?<br />
|-<br />
| 0x58<br />
| s<br />
| rw<br />
| DSP volume slider 0% volume offset (setting this to 0xFF will esentially mute the DSP as it's the volume slider's maximum raw value)<br />
|-<br />
| 0x59<br />
| s<br />
| rw<br />
| DSP volume slider 100% volume offset (setting both this and the above to 0 will disable the volume slider with 100% volume, setting this to a lower value than the above will make the volume slider have only 2 states; on and off)<br />
|-<br />
| 0x5A<br />
| s<br />
| rw<br />
| ?<br />
|-<br />
| 0x5B<br />
- 0x5F<br />
| s<br />
| ro(?)<br />
| ? (these seem to be invalid regsiters)<br />
|-<br />
| 0x60<br />
| 0x100<br />
| ro<br />
first byte is wo<br />
| Looping queue register<br />
Writing to first byte resets the queue position to the nth element<br />
Reading from this register causes the values to shift up by `readsize-1`(needs confirmation) bytes after returning `readsize-1` bytes from the top of the stack (first byte is read-only, so is always zero)<br />
|-<br />
| 0x61<br />
| 0x100<br />
| rw<br />
| Writing to this register pushes values on top of register 0x60's stack. Reading from this register doesn't advance the stack.<br />
The first byte is used to store flags for managing FIRM/NS state - bit0 = "WirelessDisabled", bit1 = "SoftwareClosed", bit2 = "PowerOffInitiated", bit4 = "LegacyJumpProhibited". This register survives power-off, but does not seem to be saved to non-volatile storage (does not survive battery pulls). This register doesn't seem to actually control MCU behaviour by itself, it just seems to be used for storing arbitrary data.<br />
|-<br />
| 0x62 - 0x7E<br />
| s<br />
| invalid (ro)<br />
| These registers don't exist at all, thus reading them will yield 0xFF<br />
|-<br />
| 0x7F<br />
| 19(?)<br />
| ro<br />
| Various system state information.<br />
byte 06: battery related? (seems to decrease while charging and increase while discharging)<br />
byte 09: system model (see [[Cfg:GetSystemModel#System_Model_Values|Cfg:GetSystemModel]] for values)<br />
byte 10: power LED related? 0 is off, 1 is red<br />
byte 13: RGB LED red factor<br />
byte 14: RGB LED green factor<br />
byte 15: RGB LED blue factor<br />
byte 17: WiFi LED brightness<br />
byte 18: raw button states?<br />
bit0: unset while power button is held<br />
bit1: unset while home button is held<br />
bit2: unset while Wifi slider is held<br />
bit5: unset while the charging LED is active<br />
bit6: unset while charger is plugged in<br />
<br />
this byte is reset to 0 before an svcBreak takes effect<br />
|-<br />
| 0x80<br />
- 0xFF<br />
| s<br />
| invalid (ro)<br />
| These registers don't exist at all, thus reading them will yield 0xFF<br />
|}<br />
<br />
Note: the letter "s" in the size field means that the given register is in a "shared register pool", meaning if you read/write with size more than 1 you can read the next `readamount-1` of shared registers. It's possible to corrupt the shared value of a "non-shared" register by writing into a shared register with a size bigger than one. Writing more than 0x100 bytes into a shared register will corrupt all writable registers, including the shared portion of "non-shared" registers.<br />
<br />
Non-shared register: it's a register separate from the shared register pool. Messing with these registers will not affect the shared register pool at all.<br />
<br />
== Device 5 & 6 ==<br />
LCD controllers for main/sub displays, most likely.<br />
<br />
{| class="wikitable" border="1"<br />
! Register<br />
! Width<br />
! Name<br />
! Description<br />
|-<br />
| 0x1<br />
| 8<br />
| ?<br />
| <br />
|-<br />
| 0x11<br />
| 8<br />
| ?<br />
| <br />
|-<br />
| 0x40<br />
| 8<br />
| CMD_IN/CMD_RESULT1<br />
| Write to trigger a command? Seen commands: 0xFF=Reset?, 0x62=IsFinished?. Result is stored in CMD_RESULT1:CMD_RESULT0.<br />
|-<br />
| 0x41<br />
| 8<br />
| CMD_RESULT0<br />
| Read result <br />
|-<br />
| 0x50<br />
| 8<br />
| ?<br />
| <br />
|-<br />
| 0x60<br />
| 8<br />
| ?<br />
| <br />
|-<br />
| 0xFE<br />
| 8<br />
| ?<br />
| <br />
|}<br />
<br />
== Device 10 ==<br />
See the datasheet linked to on the [[Hardware]] page for reference.<br />
<br />
== Device 12 ==<br />
{| class="wikitable" border="1"<br />
! REGISTER<br />
! WIDTH<br />
! DESCRIPTION <br />
|-<br />
| 0x0<br />
| 21<br />
| DebugPad state.<br />
|}<br />
<br />
This is the DebugPad device, see [[HID_Shared_Memory|here]].<br />
<br />
== Device 13 ==<br />
{| class="wikitable" border="1"<br />
! Raw I2C register address<br />
! Internal register address<br />
! Width<br />
! Description <br />
|-<br />
| 0x0<br />
| 0x0<br />
| 0x40<br />
| RHR / THR (data receive/send FIFO)<br />
|-<br />
| 0x8<br />
| 0x1<br />
| 0x1<br />
| IER<br />
|-<br />
| 0x10<br />
| 0x2<br />
| 0x1<br />
| FCR/IIR<br />
|-<br />
| 0x18<br />
| 0x3<br />
| 0x1<br />
| LCR<br />
|-<br />
| 0x20<br />
| 0x4<br />
| 0x1<br />
| MCR<br />
|-<br />
| 0x28<br />
| 0x5<br />
| 0x1<br />
| LSR<br />
|-<br />
| 0x30<br />
| 0x6<br />
| 0x1<br />
| MSR/TCR<br />
|-<br />
| 0x38<br />
| 0x7<br />
| 0x1<br />
| SPR/TLR<br />
|-<br />
| 0x40<br />
| 0x8<br />
| 0x1<br />
| TXLVL<br />
|-<br />
| 0x48<br />
| 0x9<br />
| 0x1<br />
| RXLVL<br />
|-<br />
| 0x50<br />
| 0xA<br />
| 0x1<br />
| IODir<br />
|-<br />
| 0x58<br />
| 0xB<br />
| 0x1<br />
| IOState<br />
|-<br />
| 0x60<br />
| 0xC<br />
| 0x1<br />
| IoIntEna<br />
|-<br />
| 0x68<br />
| 0xD<br />
| 0x1<br />
| reserved<br />
|-<br />
| 0x70<br />
| 0xE<br />
| 0x1<br />
| IOControl<br />
|-<br />
| 0x78<br />
| 0xF<br />
| 0x1<br />
| EFCR<br />
|}<br />
<br />
See the [http://www.alldatasheet.net/datasheet-pdf/pdf/347838/NXP/SC16IS750IBS.html datasheet] linked to on the [[Hardware]] page for reference. From that datasheet, for the structure of the I2C register address u8: "Bit 0 is not used, bits 2:1 select the channel, bits 6:3 select one of the UART internal registers. Bit 7 is not used with the I2C-bus interface, but it is used by the SPI interface to indicate a read or a write operation."<br />
<br />
== Device 14 ==<br />
<br />
Used by [[Config_Services|Cfg]]-sysmodule via the i2c::EEP service. This is presumably EEPROM going by the service name.<br />
<br />
The Cfg-module code which loads the [[Flash_Filesystem|CCAL]](nandro:/sys/{HWCAL0.dat/HWCAL1.dat}) file from NAND will load it from I2C instead, if a certain state flag is non-zero. Likewise for the function which writes CCAL to NAND. HMAC/hash verification after loading is skipped when the CCAL was loaded from I2C.<br />
<br />
== Device 15 ==<br />
This the New3DS [[NFC_Services|NFC]] controller "I2C" interface. This device is accessed via the WriteDeviceRaw/ReadDeviceRaw I2C service [[I2C_Services|commands]].<br />
<br />
Since the *Raw commands are used with this, this device has no I2C registers. Instead, raw data is transfered after the I2C device is selected. Hence, WriteDeviceRaw is used for sending commands to the controller, while ReadDeviceRaw is for receiving responses from the controller. Certain commands may return multiple command responses.<br />
<br />
Command request / response structure:<br />
{| class="wikitable" border="1"<br />
! Offset<br />
! Size<br />
! Description<br />
|-<br />
| 0x0<br />
| 0x1<br />
| Normally 0x10?<br />
|-<br />
| 0x1<br />
| 0x1<br />
| Command source / destination.<br />
|-<br />
| 0x2<br />
| 0x1<br />
| CmdID<br />
|-<br />
| 0x3<br />
| 0x1<br />
| Payload size.<br />
|}<br />
<br />
Following the above header is the payload data(when payload size is non-zero), with the size specified in the header. The command response payload is usually at least 1-byte, where that byte appears to be normally 0x0. For command requests the payload data is the command parameters.<br />
<br />
For command requests sent to the NFC tag itself, Cmd[1]=0x0 and CmdID=0x0. The command request payload data here is the actual command request data for the NFC tag, starting with the CmdID u8 at payload+0.<br />
<br />
During NFC module startup, a certain command is sent to the controller which eventually(after various cmd-reply headers etc) returns the following the payload after the first byte in the payload:<br />
000000: 44 65 63 20 32 32 20 32 30 31 32 31 34 3a 35 33 Dec 22 201214:53 <br />
000010: 3a 35 30 01 05 0d 46 05 1b 79 20 07 32 30 37 39 :50...F..y .2079<br />
000020: 31 42 35 1B5<br />
<br />
Or that is: "Dec 22 201214:53:50<binary>20791B5". Therefore, this appears to return the part-number of the NFC controller(other command request(s) / response(s) use this part-number value too).<br />
<br />
=== NFC controller commands ===<br />
{| class="wikitable" border="1"<br />
! CmdRequest[1]<br />
! CmdID<br />
! Payload data for parameters<br />
! Description<br />
|-<br />
| 0x2E<br />
| 0x2F<br />
| Firmware image for this chunk, size varies.<br />
| This is used during NFC module startup to upload the firmware image to the NFC controller. This is used repeatedly to upload multiple chunks of the image.<br />
|}</div>Myriahttps://www.3dbrew.org/w/index.php?title=Nandrw/sys/LocalFriendCodeSeed_B&diff=20065Nandrw/sys/LocalFriendCodeSeed B2017-06-05T05:16:24Z<p>Myria: /* Format */ devkit flag in LocalFriendCodeSeed?</p>
<hr />
<div>{{DISPLAYTITLE:Nandrw/sys/LocalFriendCodeSeed_B}}<br />
=Format=<br />
{| class="wikitable" border="1"<br />
! Offset<br />
! Size<br />
! Description<br />
|-<br />
| 0x0<br />
| 0x100<br />
| RSA-2048 signature over the following 0x10-bytes.<br />
|-<br />
| 0x100<br />
| 0x8<br />
| Normally zero? The second byte (offset 0x101) appears to be 0x01 if system is a devkit?<br />
|-<br />
| 0x108<br />
| 0x8<br />
| LocalFriendCodeSeed. Since the data of the whole file gets copied to [[Nand/private/movable.sed|movable.sed]], this also becomes the first 8 bytes of the keyY there.<br />
|}<br />
<br />
This contains the same LocalFriendCodeSeed data that [[PSPXI:GetLocalFriendCodeSeed]] retrieves from memory.<br />
<br />
=See Also=<br />
* [[Config Services]]</div>Myriahttps://www.3dbrew.org/w/index.php?title=RSA_Registers&diff=20062RSA Registers2017-06-04T09:13:28Z<p>Myria: /* RSA_MOD */ Note about attack to read RSA_EXPFIFO indirectly</p>
<hr />
<div>= Registers =<br />
{| class="wikitable" border="1"<br />
! Old3DS<br />
! Name<br />
! Address<br />
! Width<br />
! Used by<br />
|-<br />
| style="background: green" | Yes<br />
| [[#RSA_CNT|RSA_CNT]]<br />
| 0x1000B000<br />
| 0x04<br />
|<br />
|-<br />
| style="background: green" | Yes<br />
| RSA_?<br />
| 0x1000B0F0<br />
| 0x04<br />
|<br />
|-<br />
| style="background: green" | Yes<br />
| [[#RSA_SLOT|RSA_SLOT]]0<br />
| 0x1000B100<br />
| 0x10<br />
|<br />
|-<br />
| style="background: green" | Yes<br />
| [[#RSA_SLOT|RSA_SLOT]]1<br />
| 0x1000B110<br />
| 0x10<br />
|<br />
|-<br />
| style="background: green" | Yes<br />
| [[#RSA_SLOT|RSA_SLOT]]2<br />
| 0x1000B120<br />
| 0x10<br />
|<br />
|-<br />
| style="background: green" | Yes<br />
| [[#RSA_SLOT|RSA_SLOT]]3<br />
| 0x1000B130<br />
| 0x10<br />
|<br />
|-<br />
| style="background: green" | Yes<br />
| [[#RSA_EXPFIFO|RSA_EXPFIFO]]<br />
| 0x1000B200<br />
| 0x04<br />
|<br />
|-<br />
| style="background: green" | Yes<br />
| [[#RSA_MOD|RSA_MOD]]<br />
| 0x1000B400<br />
| 0x100<br />
|<br />
|-<br />
| style="background: green" | Yes<br />
| [[#RSA_TXT|RSA_TXT]]<br />
| 0x1000B800<br />
| 0x100<br />
|<br />
|}<br />
<br />
== RSA_CNT ==<br />
{| class="wikitable" border="1"<br />
! Bit<br />
! Description<br />
|-<br />
| 0<br />
| Start (1=Enable/Busy, 0=Idle)<br />
|-<br />
| 1<br />
| ?<br />
|-<br />
| 4-7<br />
| Keyslot (Bit6-7 don't actually affect the keyslot)<br />
|-<br />
| 8<br />
| Endianness (1=Little endian, 0=Big endian)<br />
|-<br />
| 9<br />
| Word order (1=Normal order, 0=Reversed order)<br />
|}<br />
<br />
== RSA_SLOT ==<br />
{| class="wikitable" border="1"<br />
! Name<br />
! Offset<br />
! Width<br />
|-<br />
| [[#RSA_SLOTCNT|RSA_SLOTCNT]]<br />
| 0x0<br />
| 0x4<br />
|-<br />
| [[#RSA_SLOTSIZE|RSA_SLOTSIZE]]<br />
| 0x4<br />
| 0x4<br />
|-<br />
| ?<br />
| 0x8<br />
| 0x4<br />
|-<br />
| ?<br />
| 0xC<br />
| 0x4<br />
|}<br />
<br />
== RSA_SLOTCNT ==<br />
{| class="wikitable" border="1"<br />
! Bits<br />
! Description<br />
|-<br />
| 0<br />
| Key status (1=Key has been set, 0=Key has not been set yet)<br />
|-<br />
| 1<br />
| Key write-protect, this bit is RW. (0 = no protection, 1 = protected)<br />
|-<br />
| 30-2<br />
| ?<br />
|-<br />
| 31<br />
| ?<br />
|}<br />
<br />
Before writing RSA_EXPFIFO/RSA_MOD, bit0 here should be cleared when bit31 is already clear. Otherwise, the ARM9 will hang when attempting to write to RSA_EXPFIFO.<br />
<br />
== RSA_SLOTSIZE ==<br />
This contains the RSA size for this slot, in words. Normally this is 0x40 for RSA-2048.<br />
<br />
== RSA_EXPFIFO ==<br />
The 0x100-byte private or public exponent is written to this write-only FIFO.<br />
<br />
== RSA_MOD ==<br />
The RSA key modulus for the selected keyslot can be written here. When writing the RSA modulus, the modulus must align with the end of the register area.<br />
<br />
Writing to RSA_MOD does not change the exponent written with RSA_EXPFIFO. An attack based on the [[wikipedia:Pohlig-Hellman algorithm|Pohlig-Hellman algorithm]] exists to "read" the contents of RSA_EXPFIFO as a result (see [[3DS System Flaws#Hardware|3DS System Flaws]]).<br />
<br />
== RSA_TXT ==<br />
The RSA signature can be written here, and the data read from here is the message. When writing the RSA signature, the signature must be prepended with zeroes until it is a multiple of 8 bytes, and the end of the signature must align with the end of the register area.<br />
<br />
The PKCS message padding must be manually checked by software, as hardware will only do raw RSA operations.<br />
<br />
== Keyslots usage ==<br />
{| class="wikitable" border="1"<br />
! Keyslot<br />
! Description<br />
|-<br />
| 0<br />
| Arbitrary<br />
|-<br />
| 1<br />
| [[NCCH#CXI|CXI]] access desc (following the exheader)<br />
|-<br />
| 2-3<br />
| Initialized by the ARM9 bootrom, but not used by any of the [[FIRM]]s. It's unknown what the ARM9 bootrom uses these for, if anything.<br />
|}</div>Myriahttps://www.3dbrew.org/w/index.php?title=Serials&diff=20056Serials2017-05-31T05:04:23Z<p>Myria: /* Console Serial Numbers */ Got a picture of a Chinese (iQue) 3DS's underside.</p>
<hr />
<div>This page talks about the 3DS products' serial number and model number structures (the console, manual, accessories, games, etc...).<br />
<br />
== Console Serial Numbers ==<br />
<br />
A 3DS console serial number is composed of at least two letters followed by nine decimal digits. The ninth digit is a "check digit", meaning that it is derived from the other digits.<br />
<br />
The check digit is an industry-standard algorithm, the one used for UPC codes. To calculate the check digit of a 3DS console, separate the non-check digits into "odd" and "even" groups, where the "odd" group is digits in odd-numbered positions, and the "even" group is digits in even-numbered positions. (The first digit is "odd", with "first" representing "1".)<br />
<br />
After separating the digits, add the digits in each group together. Multiply the sum of the even digits by 3, then add the sum of the odd digits. To calculate the check digit, take this value modulo 10, and if not 0, subtract from 10.<br />
<br />
Example: CW404567772<br />
<br />
The non-check digits are 40456777. Separating into odd and even groups, we get the following:<br />
<br />
Odds: 4 + 4 + 6 + 7 = 21<br />
Evens: 0 + 5 + 7 + 7 = 19<br />
<br />
Applying the algorithm, we get ((3 * 19) + 21) % 10 = 8, which is not 0, thus 10 - 8 = 2, matching the example's check digit.<br />
<br />
The letter prefixes are a letter specifying the device, followed by one letter specifying the region in which it was sold. In some regions, a third letter is present; a current guess is that this letter distinguishes among factories for a given sales region. Note that several different sales regions' console may be considered to be the same region for region-locking purposes, such as Europe and Australia.<br />
<br />
The current serial number scheme began with the DSi, hence its listing in the tables below. Among standalone consoles, the Wii U belongs to this scheme as well; the Switch started a new scheme.<br />
<br />
{| class="wikitable"<br />
! Model !! Device Prefix (Retail) !! Device Prefix (Dev)<br />
|-<br />
| ''DSi'' || T || V<br />
|-<br />
| ''DSi XL/LL'' || W ||<br />
|-<br />
| ''Wii U'' || F ||<br />
|-<br />
| 3DS || C || E<br />
|-<br />
| 3DS XL/LL || S || R<br />
|-<br />
| 2DS || A || P<br />
|-<br />
| New 3DS || Y || Y<br />
|-<br />
| New 3DS XL/LL || Q || Q<br />
|-<br />
| New 2DS XL/LL || N || N<br />
|}<br />
<br />
Development units with the same prefix as retail can be distinguished by development units having 00 as the first two digits of the serial number portion. It's currently not known definitively, but 01 as the first two digits seems to mean a retail unit given out to the press - this was seen for New 2DS XL units reviewed by the press.<br />
<br />
{| class="wikitable"<br />
! Sales Region !! Region Lock !! Region Suffix<br />
|-<br />
| Japan || Japan || JF, JH, JM<br />
|-<br />
| North America || North America || W<br />
|-<br />
| Middle East / Southeast Asia || North America || S<br />
|-<br />
| Europe || Europe || EF, EH, EM<br />
|-<br />
| Australia || Europe || AH<br />
|-<br />
| South Korea || Korea || KF, KH, KM<br />
|-<br />
| China (iQue) || China || CF, CH, CM<br />
|}<br />
<br />
== Console Models ==<br />
<br />
{| class="wikitable"<br />
! Device !! Product Code<br />
|-<br />
| ''DS'' || NTR<br />
|-<br />
| ''DS lite'' || USG<br />
|-<br />
| ''DSi'' || TWL<br />
|-<br />
| ''DSi XL/LL'' || UTL<br />
|-<br />
| ''Wii U'' || WUP<br />
|-<br />
| 3DS || CTR<br />
|-<br />
| 3DS XL/LL || SPR<br />
|-<br />
| 2DS || FTR<br />
|-<br />
| [[New 3DS]] || KTR<br />
|-<br />
| [[New 3DS]] XL/LL || RED<br />
|-<br />
| New 2DS XL/LL || JAN<br />
|}<br />
<br />
The DS had the product code NTR, so we see the TR is recurring.<br />
<br />
== Title ID and Unique ID ==<br />
''see [[Titles]]''<br />
<br />
== NCCH Product Code ==<br />
<br />
This serial is similiar to the "physical serial" described later in this page; it is the canonical identifier for a specific title in the field of business formalities with Nintendo, but this is not reflected in the 3DS's software architecture (where it is vastly unused in favor of the Title ID: it is therefore considered the successor of the "internal name" contained in ROMs of previous handhelds), is not guaranteed to be unique.<br />
<br />
The product code is located in a [[NCCH]]'s header (not its ExHeader).<br />
<br />
The product code "CTR-P-CTAP" is the default generic product code for NCCH files. Most [[NCSD|NCCHs apart from the first one]] in a title are generally CTR-P-CTAP.<br />
Referring to "the product code of a title" is therefore a simplification for "the product code of the NCCH in its first partition".<br />
<br />
So, for example, a Japanese copy of Ridge Racer 3D would have a product code of "CTR-P-ARRJ" and a serial of "LNA-CTR-ARRJ-JPN".<br />
<br />
A Nintendo-assigned product code follows this format, however, there is no requirement for a product code to match or resemble this structure as long as it's within the length limit:<br />
<br />
[CTR/KTR]-[Category letter]-[Type][Identifier][Region]-[Sub ID]<br />
<br />
{| class="wikitable"<br />
! Category letter !! Description<br />
|-<br />
| P || Cartridge software, or downloadable versions of them.<br />
|-<br />
| N || Digital-only releases, including [[Title list|system applications and applets]].<br />
|-<br />
| M || [[DLC]]<br />
|-<br />
| T || [[eShop Demos]], excluding so-called "special demos" which are category N.<br />
|-<br />
| U || [[Title list#0004000E - Add-on Content (Updates)|Patches]] for category P titles.<br />
|}<br />
<br />
The "sub ID" only applies to DLC, demos, and local copies of Download Play titles. It's a 2-digit number associated with the [[Title list|Title ID Variation]].<br />
<br />
See the next chapter for explanation of the other components of the Product Code.<br />
<br />
== Physical Serial ==<br />
<br />
[Product][Retail/Demo]-CTR-[Type][Identifier][Region]-[Label Region]<br />
<br />
{| class="wikitable"<br />
! Field !! Length !! Description<br />
|-<br />
| Product || 2 || Product type (cartridges are LN, game boxes are TS, instruction manuals are MA, leaflets are FA, quick-start guides are MK)<br />
|-<br />
| Retail/Demo || 1 || Retail (A) or Demo (Z)<br />
|-<br />
| CTR/KTR || 3 || Platform. CTR = 3DS, KTR = New 3DS<br />
|-<br />
| Type || 1 || [A/C/H/J/K/S/P/T] - Retail / C is part of the default serial 'CTAP' / H is used for built in applications like [[Mii Maker]] / J is for a normal eShop Title / K is unknown, seen in Mighty Gunvolt / S is usually a 3D Classics eShop title / P is used with GBA eShop titles / T is used with NES eShop titles.<br />
|-<br />
| Identifier || 2 || game name (two alphanumeric characters).<br />
|-<br />
| Region || 1 || [E/P/J/K/C/Y/W/Z/A] - English (US) / PAL (Europe/Australia) / Japanese (Japan) / Korean (Korea) / Chinese (China/Taiwan) / Multiple regions / Tai'''w'''an(?) (Taiwan/Hong Kong) / Multiple regions / All (region-free)<br />
|-<br />
| Label Region || 3 || [USA/EUR/CAN/JPN/KOR/TWN/CHN/UKV] - USA / Europe / Canada / Japan / Korea / Taiwan/Hong Kong / China / United Kingdom version(?) (United Kingdom)<br />
|}<br />
<br />
=== Electronic Manuals ===<br />
<br />
Some eShop titles have [[NCCH#CFA|Electronic Manuals]] which store the product code at the end of the 'Health & Safety' section of the manual. However, product codes can differ from the above format as shown below:<br />
<br />
CTR-[P/N/T/U]-[Type][Identifier][Region]-[Region]-[Digit]<br />
<br />
CTR-[Type][Identifier][Region]-[Region]-[Digit]<br />
<br />
* P/N/T/U - Same as in product code structure<br />
* [Type][Identifier][Region] - Same as in serial structure<br />
* [Region] - A three character representation of the title region, i.e. 'EUR' (not always present)<br />
* [Digit] - A single digit usually '1' or '0' (not always present)<br />
<br />
'''Note:''' These alternate versions of the product code, potentially found in [[NCCH#CFA|Electronic Manuals]] don't represent the actual product code, as found in the game's CXI. They are only found in the game's Home Menu manual, and on the game's packaging and external labeling.<br />
<br />
==Back of Card Serial==<br />
AREPY10111<br />
<br />
AAAABCDEEE (presumably)<br />
<br />
[Identifier]-[Production Month]-[Production Year]-[Revision]-[Production Run?]</div>Myriahttps://www.3dbrew.org/w/index.php?title=Serials&diff=20055Serials2017-05-30T18:30:31Z<p>Myria: /* Console Serial Numbers */ Got a picture of the bottom of a DSi panda. Now I know why they're called "pandas", too.</p>
<hr />
<div>This page talks about the 3DS products' serial number and model number structures (the console, manual, accessories, games, etc...).<br />
<br />
== Console Serial Numbers ==<br />
<br />
A 3DS console serial number is composed of at least two letters followed by nine decimal digits. The ninth digit is a "check digit", meaning that it is derived from the other digits.<br />
<br />
The check digit is an industry-standard algorithm, the one used for UPC codes. To calculate the check digit of a 3DS console, separate the non-check digits into "odd" and "even" groups, where the "odd" group is digits in odd-numbered positions, and the "even" group is digits in even-numbered positions. (The first digit is "odd", with "first" representing "1".)<br />
<br />
After separating the digits, add the digits in each group together. Multiply the sum of the even digits by 3, then add the sum of the odd digits. To calculate the check digit, take this value modulo 10, and if not 0, subtract from 10.<br />
<br />
Example: CW404567772<br />
<br />
The non-check digits are 40456777. Separating into odd and even groups, we get the following:<br />
<br />
Odds: 4 + 4 + 6 + 7 = 21<br />
Evens: 0 + 5 + 7 + 7 = 19<br />
<br />
Applying the algorithm, we get ((3 * 19) + 21) % 10 = 8, which is not 0, thus 10 - 8 = 2, matching the example's check digit.<br />
<br />
The letter prefixes are a letter specifying the device, followed by one letter specifying the region in which it was sold. In some regions, a third letter is present; a current guess is that this letter distinguishes among factories for a given sales region. Note that several different sales regions' console may be considered to be the same region for region-locking purposes, such as Europe and Australia.<br />
<br />
The current serial number scheme began with the DSi, hence its listing in the tables below. Among standalone consoles, the Wii U belongs to this scheme as well; the Switch started a new scheme.<br />
<br />
{| class="wikitable"<br />
! Model !! Device Prefix (Retail) !! Device Prefix (Dev)<br />
|-<br />
| ''DSi'' || T || V<br />
|-<br />
| ''DSi XL/LL'' || W ||<br />
|-<br />
| ''Wii U'' || F ||<br />
|-<br />
| 3DS || C || E<br />
|-<br />
| 3DS XL/LL || S || R<br />
|-<br />
| 2DS || A || P<br />
|-<br />
| New 3DS || Y || Y<br />
|-<br />
| New 3DS XL/LL || Q || Q<br />
|-<br />
| New 2DS XL/LL || N || N<br />
|}<br />
<br />
Development units with the same prefix as retail can be distinguished by development units having 00 as the first two digits of the serial number portion. It's currently not known definitively, but 01 as the first two digits seems to mean a retail unit given out to the press - this was seen for New 2DS XL units reviewed by the press.<br />
<br />
{| class="wikitable"<br />
! Sales Region !! Region Lock !! Region Suffix<br />
|-<br />
| Japan || Japan || JF, JH, JM<br />
|-<br />
| North America || North America || W<br />
|-<br />
| Middle East / Southeast Asia || North America || S<br />
|-<br />
| Europe || Europe || EF, EH, EM<br />
|-<br />
| Australia || Europe || AH<br />
|-<br />
| South Korea || Korea || KF, KH, KM<br />
|}<br />
<br />
== Console Models ==<br />
<br />
{| class="wikitable"<br />
! Device !! Product Code<br />
|-<br />
| ''DS'' || NTR<br />
|-<br />
| ''DS lite'' || USG<br />
|-<br />
| ''DSi'' || TWL<br />
|-<br />
| ''DSi XL/LL'' || UTL<br />
|-<br />
| ''Wii U'' || WUP<br />
|-<br />
| 3DS || CTR<br />
|-<br />
| 3DS XL/LL || SPR<br />
|-<br />
| 2DS || FTR<br />
|-<br />
| [[New 3DS]] || KTR<br />
|-<br />
| [[New 3DS]] XL/LL || RED<br />
|-<br />
| New 2DS XL/LL || JAN<br />
|}<br />
<br />
The DS had the product code NTR, so we see the TR is recurring.<br />
<br />
== Title ID and Unique ID ==<br />
''see [[Titles]]''<br />
<br />
== NCCH Product Code ==<br />
<br />
This serial is similiar to the "physical serial" described later in this page; it is the canonical identifier for a specific title in the field of business formalities with Nintendo, but this is not reflected in the 3DS's software architecture (where it is vastly unused in favor of the Title ID: it is therefore considered the successor of the "internal name" contained in ROMs of previous handhelds), is not guaranteed to be unique.<br />
<br />
The product code is located in a [[NCCH]]'s header (not its ExHeader).<br />
<br />
The product code "CTR-P-CTAP" is the default generic product code for NCCH files. Most [[NCSD|NCCHs apart from the first one]] in a title are generally CTR-P-CTAP.<br />
Referring to "the product code of a title" is therefore a simplification for "the product code of the NCCH in its first partition".<br />
<br />
So, for example, a Japanese copy of Ridge Racer 3D would have a product code of "CTR-P-ARRJ" and a serial of "LNA-CTR-ARRJ-JPN".<br />
<br />
A Nintendo-assigned product code follows this format, however, there is no requirement for a product code to match or resemble this structure as long as it's within the length limit:<br />
<br />
[CTR/KTR]-[Category letter]-[Type][Identifier][Region]-[Sub ID]<br />
<br />
{| class="wikitable"<br />
! Category letter !! Description<br />
|-<br />
| P || Cartridge software, or downloadable versions of them.<br />
|-<br />
| N || Digital-only releases, including [[Title list|system applications and applets]].<br />
|-<br />
| M || [[DLC]]<br />
|-<br />
| T || [[eShop Demos]], excluding so-called "special demos" which are category N.<br />
|-<br />
| U || [[Title list#0004000E - Add-on Content (Updates)|Patches]] for category P titles.<br />
|}<br />
<br />
The "sub ID" only applies to DLC, demos, and local copies of Download Play titles. It's a 2-digit number associated with the [[Title list|Title ID Variation]].<br />
<br />
See the next chapter for explanation of the other components of the Product Code.<br />
<br />
== Physical Serial ==<br />
<br />
[Product][Retail/Demo]-CTR-[Type][Identifier][Region]-[Label Region]<br />
<br />
{| class="wikitable"<br />
! Field !! Length !! Description<br />
|-<br />
| Product || 2 || Product type (cartridges are LN, game boxes are TS, instruction manuals are MA, leaflets are FA, quick-start guides are MK)<br />
|-<br />
| Retail/Demo || 1 || Retail (A) or Demo (Z)<br />
|-<br />
| CTR/KTR || 3 || Platform. CTR = 3DS, KTR = New 3DS<br />
|-<br />
| Type || 1 || [A/C/H/J/K/S/P/T] - Retail / C is part of the default serial 'CTAP' / H is used for built in applications like [[Mii Maker]] / J is for a normal eShop Title / K is unknown, seen in Mighty Gunvolt / S is usually a 3D Classics eShop title / P is used with GBA eShop titles / T is used with NES eShop titles.<br />
|-<br />
| Identifier || 2 || game name (two alphanumeric characters).<br />
|-<br />
| Region || 1 || [E/P/J/K/C/Y/W/Z/A] - English (US) / PAL (Europe/Australia) / Japanese (Japan) / Korean (Korea) / Chinese (China/Taiwan) / Multiple regions / Tai'''w'''an(?) (Taiwan/Hong Kong) / Multiple regions / All (region-free)<br />
|-<br />
| Label Region || 3 || [USA/EUR/CAN/JPN/KOR/TWN/CHN/UKV] - USA / Europe / Canada / Japan / Korea / Taiwan/Hong Kong / China / United Kingdom version(?) (United Kingdom)<br />
|}<br />
<br />
=== Electronic Manuals ===<br />
<br />
Some eShop titles have [[NCCH#CFA|Electronic Manuals]] which store the product code at the end of the 'Health & Safety' section of the manual. However, product codes can differ from the above format as shown below:<br />
<br />
CTR-[P/N/T/U]-[Type][Identifier][Region]-[Region]-[Digit]<br />
<br />
CTR-[Type][Identifier][Region]-[Region]-[Digit]<br />
<br />
* P/N/T/U - Same as in product code structure<br />
* [Type][Identifier][Region] - Same as in serial structure<br />
* [Region] - A three character representation of the title region, i.e. 'EUR' (not always present)<br />
* [Digit] - A single digit usually '1' or '0' (not always present)<br />
<br />
'''Note:''' These alternate versions of the product code, potentially found in [[NCCH#CFA|Electronic Manuals]] don't represent the actual product code, as found in the game's CXI. They are only found in the game's Home Menu manual, and on the game's packaging and external labeling.<br />
<br />
==Back of Card Serial==<br />
AREPY10111<br />
<br />
AAAABCDEEE (presumably)<br />
<br />
[Identifier]-[Production Month]-[Production Year]-[Revision]-[Production Run?]</div>Myriahttps://www.3dbrew.org/w/index.php?title=Title_list&diff=20054Title list2017-05-30T07:23:24Z<p>Myria: /* System Applet Notes */ Additional product codes for system modules. Also, Korea has no Miiverse modules.</p>
<hr />
<div>==== CTR Title List Notes ====<br />
Reports/title-lists [https://yls8.mtheall.com/ninupdates/reports.php here] are automatically obtained from the system update SOAP.<br />
<br />
== CTR System Titles ==<br />
{| class="wikitable sortable" border="1"<br />
|-<br />
! Category Bit Mask<br />
! Title Type<br />
! Internal Description<br />
! Bit Mask(s)<br />
|-<br />
| 0x0010<br />
| Application<br />
| SYSTEM_APPLICATION<br />
| Normal<nowiki> | </nowiki>System<br />
|-<br />
| 0x001B<br />
| System Data Archives<br />
| SYSTEM_CONTENT<br />
| Contents<nowiki> | </nowiki>CannotExecution<nowiki> | </nowiki>System<br />
|-<br />
| 0x009B<br />
| Shared Data Archives<br />
| SHARED_CONTENT<br />
| Contents<nowiki> | </nowiki>CannotExecution<nowiki> | </nowiki>System<nowiki> | </nowiki>NotRequireRightForMount<br />
|-<br />
| 0x00DB<br />
| System Data Archives<br />
| AUTO_UPDATE_CONTENT<br />
| Contents<nowiki> | </nowiki>CannotExecution<nowiki> | </nowiki>System<nowiki> | </nowiki>NotRequireUserApproval<nowiki> | </nowiki>NotRequireRightForMount<br />
|-<br />
| 0x0030<br />
| Applet<br />
| APPLET<br />
| Normal<nowiki> | </nowiki>System<nowiki> | </nowiki>RequireBatchUpdate<br />
|-<br />
| 0x0130<br />
| Module<br />
| BASE<br />
| Normal<nowiki> | </nowiki>System<nowiki> | </nowiki>RequireBatchUpdate<nowiki> | </nowiki>CanSkipConvertJumpId<br />
|-<br />
| 0x0138<br />
| Firmware <br />
| FIRMWARE<br />
| Normal<nowiki> | </nowiki>CannotExecution<nowiki> | </nowiki>System<nowiki> | </nowiki>RequireBatchUpdate<nowiki> | </nowiki>CanSkipConvertJumpId<br />
|}<br />
<br />
=== 00040010 - System Applications ===<br />
==== System Application Notes ====<br />
System Application titles have a unique title low that varies by region.<br />
Regardless of version, the ExeFS:/.code for mset is the same for USA/EUR/JPN. <br />
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). <br />
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.<br />
The ''only'' system-applications included with gamecard-sysupdates are: [[System Settings]], [[Download Play]], and SAFE_MODE [[System Settings#System Updater|System Updater]]. <br />
The only system-applications included with the New3DS gamecard-sysupdate partition are: "menu" stub and "friend" stub.<br />
<br />
{| class="wikitable sortable" border="1"<br />
|-<br />
! JPN TIDLow<br />
! USA TIDLow<br />
! EUR TIDLow<br />
! CHN TIDLow<br />
! KOR TIDLow<br />
! TWN TIDLow<br />
! [[Product code]]<br />
! Description<br />
! JPN Versions<br />
! EUR Versions<br />
! USA Versions<br />
! CHN Versions<br />
! KOR Versions<br />
! TWN Versions<br />
! Status<br />
|-<br />
| 00020000<br />
| 00021000<br />
| 00022000<br />
| 00026000<br />
| 00027000<br />
| 00028000<br />
| CTR-N-HAS?<br />
| [[System Settings]] (mset)<br />
| [[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]]<br />
| [[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]]<br />
| [[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]]<br />
| [[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]]<br />
| [[4.0.0-7|v1026]], [[5.0.0-11|v2049]], [[7.0.0-13|v4098]]<br />
| [[4.1.0-8|v8]], [[4.2.0-9|v1024]], [[5.0.0-11|v2050]], [[7.0.0-13|v3074]]<br />
| Active<br />
|-<br />
| 00020100<br />
| 00021100<br />
| 00022100<br />
| 00026100<br />
| 00027100<br />
| 00028100<br />
| CTR-N-HDL?<br />
| [[Download Play]] (dlplay)<br />
| [[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]])<br />
| [[1.0.0-0|v0]], [[2.1.0-4|v1026]], [[4.0.0-7|v2051]], [[9.0.0-20|v3073]]<br />
| [[1.0.0-0|v0]], [[2.1.0-4|v1026]], [[4.0.0-7|v2051]], [[9.0.0-20|v3073]]<br />
| [[4.0.0-7|v4]]<br />
| [[4.0.0-7|v1027]]<br />
| [[4.1.0-8|v4]]<br />
| Active<br />
|-<br />
| 00020200<br />
| 00021200<br />
| 00022200<br />
| 00026200<br />
| 00027200<br />
| 00028200<br />
| CTR-N-HMK?<br />
| [[Activity Log]]<br />
| [[1.0.0-0|v0]], [[2.0.0-2|v1026]], [[3.0.0-5|v2051]], [[10.6.0-31|v2080]]<br />
| [[1.0.0-0|v0]], [[2.0.0-2|v1026]], [[3.0.0-5|v2054]], [[7.0.0-13|v2064]]<br />
| Same as EUR<br />
| [[4.0.0-7|v3]]<br />
| [[4.0.0-7|v2]], [[7.0.0-13|v16]]<br />
| [[4.1.0-8|v2]]<br />
| Active<br />
|-<br />
| 00020300<br />
| 00021300<br />
| 00022300<br />
| 00026300<br />
| 00027300<br />
| 00028300<br />
| ?<br />
| [[Health and Safety Information]] (safe)<br />
| [[1.0.0-0|v0]], [[4.0.0-7|v1024]], [[6.0.0-11|v2050]]<br />
| [[1.0.0-0|v0]], [[3.0.0-5|v1024]], [[4.0.0-7|v2050]], [[6.0.0-11|v3077]]<br />
| [[1.0.0-0|v0]], [[4.0.0-7|v1026]], [[6.1.0-12U|v2051]]<br />
| [[4.0.0-7|v5]]<br />
| [[4.0.0-7|v2]]<br />
| [[4.1.0-8|v5]]<br />
| Active<br />
|-<br />
| 20020300<br />
| 20021300<br />
| 20022300<br />
| N/A<br />
| 20027300<br />
| N/A<br />
| CTR-N-HAC?<br />
| [[New_3DS]] [[Health and Safety Information]]<br />
| [[8.1.0-0_New3DS|v2]], [[9.3.0-21|v17]]<br />
| [[8.1.0-0_New3DS|v1]]<br />
| Same as EUR.<br />
| N/A<br />
| [[9.6.0-24|v2]]<br />
| N/A<br />
| Active<br />
|-<br />
| 00020400<br />
| 00021400<br />
| 00022400<br />
| 00026400<br />
| 00027400<br />
| 00028400<br />
| CTR-N-HEP?<br />
| [[Nintendo 3DS Camera]] (CtrApp)<br />
| [[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]]<br />
| [[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]]<br />
| [[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]]<br />
| [[4.0.0-7|v3]]<br />
| [[4.0.0-7|v2]], [[7.0.0-13|v1040]]<br />
| [[4.1.0-8|v3]]<br />
| Active<br />
|-<br />
| 00020500<br />
| 00021500<br />
| 00022500<br />
| 00026500<br />
| 00027500<br />
| 00028500<br />
| CTR-N-HES?<br />
| [[Nintendo 3DS Sound]] (CtrApp)<br />
| [[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]], [[11.4.0-37|v4096]]<br />
| [[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]], [[11.4.0-37|v4096]]<br />
| [[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]], [[11.4.0-37|v4096]]<br />
| [[4.0.0-7|v2]], [[11.4.0-37|v1024]]<br />
| [[4.0.0-7|v2]], [[7.0.0-13|v16]],[[11.4.0-37|v4096]]<br />
| [[4.1.0-8|v3]], [[11.4.0-37|v1024]]<br />
| Active<br />
|-<br />
| 00020700<br />
| 00021700<br />
| 00022700<br />
| 00026700<br />
| 00027700<br />
| 00028700<br />
| CTR-N-HED?<br />
| [[Mii Maker]] (EDIT)<br />
| [[1.0.0-0|v0]], [[2.0.0-2|v1026]], [[7.0.0-13|v2055]], [[10.6.0-31|v2064]]<br />
| Same as JPN<br />
| Same as JPN<br />
| [[4.0.0-7|v1]]<br />
| [[4.0.0-7|v1]], [[7.0.0-13|v16]]<br />
| [[4.1.0-8|v2]]<br />
| Active<br />
|-<br />
| 00020800<br />
| 00021800<br />
| 00022800<br />
| 00026800<br />
| 00027800<br />
| 00028800<br />
| CTR-N-HME?<br />
| [[StreetPass Mii Plaza]] (MEET)<br />
| [[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]]<br />
| [[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]]<br />
| [[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]]<br />
| [[4.0.0-7|v0]], [[4.4.0-10|v4096]]<br />
| [[4.0.0-7|v1]], [[4.4.0-10|v4096]], [[7.0.0-13|v5120]]<br />
| [[4.1.0-8|v1]], [[4.4.0-10|v4096]]<br />
| Active<br />
|-<br />
| 00020900<br />
| 00021900<br />
| 00022900<br />
| N/A<br />
| 00027900<br />
| 00028900<br />
| CTR-N-HGR?<br />
| [[eShop]] (tiger)<br />
| [[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]]<br />
| [[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]]<br />
| [[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]]<br />
| N/A<br />
| [[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]]<br />
| [[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]]<br />
| Active<br />
|-<br />
| 00020A00<br />
| 00021A00<br />
| 00022A00<br />
| N/A<br />
| 00027A00<br />
| 00028A00<br />
| CTR-N-HCB?<br />
| [[System Transfer]] (CARDBOARD)<br />
| [[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]]<br />
| [[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]]<br />
| [[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]]<br />
| N/A<br />
| [[4.0.0-7|v2]], [[5.0.0-11|v1025]], [[7.0.0-13|v2061]], [[9.0.0-20|v3082]]<br />
| [[4.1.0-8|v2]], [[5.0.0-11|v1025]], [[7.0.0-13|v2061]]<br />
| Active<br />
|-<br />
| 00020B00<br />
| 00021B00<br />
| 00022B00<br />
| N/A<br />
| N/A<br />
| N/A<br />
| CTR-N-HMA?<br />
| [[Nintendo Zone]] ("Nintendo")<br />
| [[1.0.0-0|v0]], [[3.0.0-5|v1034]]<br />
| Same as JPN<br />
| Same as JPN<br />
| N/A<br />
| N/A<br />
| N/A<br />
| Active<br />
|-<br />
| 00020D00<br />
| 00021D00<br />
| 00022D00<br />
| 00026D00<br />
| 00027D00<br />
| 00028D00<br />
| CTR-N-HCH?<br />
| [[Face Raiders]]<br />
| [[1.0.0-0|v0]], [[2.1.0-4|v1028]]<br />
| [[1.0.0-0|v0]], [[2.1.0-4|v1028]], [[7.0.0-13|v1040]]<br />
| Same as EUR<br />
| [[4.0.0-7|v0]]<br />
| [[4.0.0-7|v0]]<br />
| [[4.1.0-8|v2]]<br />
| Active<br />
|-<br />
| 20020D00<br />
| 20021D00<br />
| 20022D00<br />
| N/A<br />
| 20027D00<br />
| N/A<br />
| ?<br />
| [[New_3DS]] [[Face Raiders]]<br />
| [[8.1.0-0_New3DS|v2050]]<br />
| [[8.1.0-0_New3DS|v2049]]<br />
| Same as EUR.<br />
| N/A<br />
| [[9.6.0-24|v2049]]<br />
| N/A<br />
| Active<br />
|-<br />
| 00020E00<br />
| 00021E00<br />
| 00022E00<br />
| 00026E00<br />
| 00027E00<br />
| 00028E00<br />
| CTR-N-HAR?<br />
| [[AR Games]] (AR_ACT)<br />
| [[1.0.0-0|v0]], [[2.1.0-4|v1026]]<br />
| [[1.0.0-0|v0]], [[2.1.0-4|v1026]], [[7.0.0-13|v1040]]<br />
| [[1.0.0-0|v0]], [[2.1.0-4|v1027]], [[7.0.0-13|v1040]]<br />
| [[4.0.0-7|v0]]<br />
| [[4.0.0-7|v0]], [[7.0.0-13|v16]]<br />
| [[4.1.0-8|v1]]<br />
| Active<br />
|-<br />
| 00020F00<br />
| 00021F00<br />
| 00022F00<br />
| 00026F00<br />
| 00027F00<br />
| 00028F00<br />
| CTR-N-HSH?<br />
| SAFE_MODE [[System Settings#System Updater|System Updater]] (mset)<br />
| [[1.0.0-0|v0]], [[3.0.0-5|v1024]], [[6.0.0-11|v2049]]<br />
| [[1.0.0-0|v0]], [[3.0.0-5|v1024]], [[6.0.0-11|v2050]]<br />
| Same as JPN<br />
| [[4.0.0-7|v1]], [[6.0.0-11|v1026]]<br />
| [[4.0.0-7|v1]]<br />
| [[4.1.0-8|v1]]<br />
| Active<br />
|-<br />
| 00023000<br />
| 00024000<br />
| 00025000<br />
| N/A<br />
| N/A<br />
| N/A<br />
| (Variable?)<br />
| Promotional video<br />
| [[1.1.0-1|v2]], [[2.0.0-2|v2048]]<br />
| [[1.1.0-1|v<unknown>]], [[2.0.0-2|v2048]]<br />
| [[1.1.0-1|v0]], [[2.0.0-2|v2048]]<br />
| N/A<br />
| N/A<br />
| N/A<br />
| Stubbed<br />
|-<br />
| 0002BF00<br />
| 0002C000<br />
| 0002C100<br />
| N/A<br />
| N/A<br />
| N/A<br />
| CTR-N-HAF?<br />
| [[Nintendo Network ID Settings]] (act)<br />
| [[7.0.0-13|v14]], [[7.2.0-17|v1029]], [[9.0.0-20|v2051]], [[9.3.0-21|v3072]]<br />
| Same as JPN<br />
| Same as JPN<br />
| N/A<br />
| N/A<br />
| N/A<br />
| Active<br />
|-<br />
| 20023100<br />
| 20024100<br />
| 20025100<br />
| N/A<br />
| N/A<br />
| N/A<br />
| CTR-N-HAJ?<br />
| [[microSD Management]] ('mcopy') ([[New_3DS]]-only)<br />
| [[8.1.0-0_New3DS|v8]], [[9.0.0-20|v1024]]<br />
| [[8.1.0-0_New3DS|v4]]<br />
| [[8.1.0-0_New3DS|v5]]<br />
| N/A<br />
| N/A<br />
| N/A<br />
| Available<br />
|-<br />
| 2002C800<br />
| 2002CF00<br />
| 2002D000<br />
| N/A<br />
| 2002D700<br />
| N/A<br />
| CTR-P-CTAP<br />
| [[New_3DS]]-only, currently stubbed. "HOME menu/menu".<br />
| [[8.1.0-0_New3DS|v2]], [[9.0.0-20|v18]], [[9.3.0-21|v34]], [[9.6.0-24|v50]]<br />
| [[8.1.0-0_New3DS|v1]], [[9.3.0-21|v17]], [[9.6.0-24|v34]]<br />
| [[8.1.0-0_New3DS|v1]], [[9.3.0-21|v18]], [[9.6.0-24|v33]]<br />
| N/A<br />
| [[9.6.0-24|v2]]<br />
| N/A<br />
| Stubbed<br />
|-<br />
| 2002C900<br />
| 2002D100<br />
| 2002D200<br />
| N/A<br />
| 2002D800<br />
| N/A<br />
| CTR-P-CTAP<br />
| [[New_3DS]]-only, currently stubbed. "Friends list/friend".<br />
| [[8.1.0-0_New3DS|v1]]<br />
| Same as JPN.<br />
| [[8.1.0-0_New3DS|v0]], [[9.3.0-21|v16]]<br />
| N/A<br />
| [[9.6.0-24|v2]]<br />
| N/A<br />
| Stubbed<br />
|-<br />
| 2002CA00<br />
| 2002D300<br />
| 2002D400<br />
| N/A<br />
| 2002D900<br />
| N/A<br />
| CTR-P-CTAP<br />
| [[New_3DS]]-only, currently stubbed. "Notifications/newslist".<br />
| [[8.1.0-0_New3DS|v0]], v1([[Home_Menu|JPN-only]] Oct 2, 2014 "sysupdate", actually uploaded on 09-29-14. Identical to v0, same TMDs besides title-versions)<br />
| [[8.1.0-0_New3DS|v2]]<br />
| [[8.1.0-0_New3DS|v0]]<br />
| N/A<br />
| [[9.6.0-24|v2]]<br />
| N/A<br />
| Stubbed<br />
|-<br />
| 2002CB00<br />
| 2002D500<br />
| 2002D600<br />
| N/A<br />
| 2002DA00<br />
| N/A<br />
| CTR-P-CTAP<br />
| [[New_3DS]]-only, currently stubbed. "Game notes/cherry".<br />
| [[8.1.0-0_New3DS|v0]], [[9.0.0-20|v1]]<br />
| [[8.1.0-0_New3DS|v2]]<br />
| Same as EUR.<br />
| N/A<br />
| [[9.6.0-24|v1]]<br />
| N/A<br />
| Stubbed<br />
|}<br />
<br />
=== 0004001B - [[NCCH#CFA|System Data Archives]] ===<br />
{| class="wikitable sortable" border="1"<br />
|-<br />
! TitleID Low<br />
! Description<br />
! Versions<br />
|-<br />
| 00010002<br />
| [[ClCertA]]<br />
| [[1.0.0-0|v0]]<br />
|-<br />
| 00010702<br />
| [[NS CFA]]<br />
| [[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]])<br />
|-<br />
| 00010802<br />
| This CFA only contains a 1-byte "dummy.txt" in the RomFS, which contains '0'.<br />
| [[6.3.0-12|v0]], [[9.5.0-23|v1024]], [[10.5.0-30|v2048]], [[11.0.0-33|v3072]]<br />
|-<br />
| 00018002<br />
| Same contents as 00010802. Starting with [[7.1.0-15]], the "dummy.txt" file was removed from RomFS: this CFA RomFS now contains web-browser data(similar to 00018102) for NNID / networking, etc.<br />
| [[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]]<br />
|-<br />
| 00018102<br />
| This contains local web-browser data(html/js, gfx, etc) for the Miiverse Offline-mode.<br />
| [[7.0.0-13|v11]], [[9.0.0-20|v1025]](also for [[8.1.0-0_New3DS]])<br />
|-<br />
| 00018202<br />
| This contains the webkit/OSS [[CRO0|CROs]] used with the Miiverse applet and the "act" application.<br />
| [[7.0.0-13|v7]], [[8.1.0-0_New3DS|v1026]]([[8.1.0-0_New3DS]]), [[9.0.0-20|v2050]]<br />
|-<br />
| 00019002<br />
| [[Fangate_updater]]<br />
| [[9.3.0-21|v2]], [[9.6.0-24|v1026]]<br />
|}<br />
<br />
=== 00040030 - System Applets===<br />
==== System Applet Notes ====<br />
Most of these processes are applets, see [[NS_and_APT_Services|here]] for details.<br />
All of the below processes use the "SYSTEM" [[SVC|memory-region]].<br />
The ExeFS for Home Menu is exactly the same for USA/EUR/JPN.<br />
The Miiverse applet seems to use a web browser with webkit.<br />
<br />
{| class="wikitable sortable" border="1"<br />
|-<br />
! JPN TitleIDLow<br />
! USA TitleIDLow<br />
! EUR TitleIDLow<br />
! CHN TitleIDLow<br />
! KOR TitleIDLow<br />
! TWN TitleIDLow<br />
! [[Product code]]<br />
! Description<br />
! JPN Versions<br />
! USA Versions<br />
! EUR Versions<br />
|-<br />
|colspan=6 align=center| 00008102<br />
| CTR-P-CTAP<br />
| [[NS#Alternate menu|Test Menu]] (Demo1)<br />
|colspan=3 align=center| ..., v64, ..., v27648<br />
|-<br />
| 00008202<br />
| 00008F02<br />
| 00009802<br />
| 0000A102<br />
| 0000A902<br />
| 0000B102<br />
| CTR-P-HMM?<br />
| [[Home Menu]] (menu)<br />
| [[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]]<br />
| [[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]]<br />
| [[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]]<br />
|-<br />
| 00008402<br />
| 00009002<br />
| 00009902<br />
| 0000A202<br />
| 0000AA02<br />
| 0000B202<br />
| CTR-N-HCS?<br />
| Camera applet used by Home-menu (CtrApp)<br />
|colspan=3| v0, v1036, [[9.0.0-20|v2049]](Also for [[8.1.0-0_New3DS]])<br />
|-<br />
| 00008502<br />
| 00009102<br />
| 00009A02<br />
| ?<br />
| ?<br />
| ?<br />
| ?<br />
| Not available on CDN<br />
| ?<br />
| ?<br />
| ?<br />
|-<br />
| 00008602<br />
| 00009202<br />
| 00009B02<br />
| 0000A402<br />
| 0000AC02<br />
| 0000B402<br />
| CTR-N-HMV?<br />
| Instruction Manual, applet for displaying instruction manuals<br />
|colspan=3| v0, v1026, v2048, v3072, [[5.0.0-11|v4097]], [[9.0.0-20|v5120]](Also for [[8.1.0-0_New3DS]])<br />
|-<br />
| 00008702<br />
| 00009302<br />
| 00009C02<br />
| 0000A502<br />
| 0000AD02<br />
| 0000B502<br />
| CTR-N-HGM?<br />
| Game Notes (Cherry)<br />
|colspan=3| v0, v1026, v2049, [[5.0.0-11|v3073]], [[9.0.0-20|v4096]](Also for [[8.1.0-0_New3DS]])<br />
|-<br />
| 00008802<br />
| 00009402<br />
| 00009D02<br />
| 0000A602<br />
| 0000AE02<br />
| 0000B602<br />
| <br />
| [[Internet Browser]] (spider)<br />
|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]]<br />
|-<br />
| 20008802<br />
| 20009402<br />
| 20009D02<br />
| ?<br />
| 2000AE02<br />
| N/A<br />
| CTR-N-HBR?<br />
| [[New 3DS]] [[Internet Browser]] (SKATER)<br />
|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]]<br />
|-<br />
|colspan=6| 00008A02<br />
| <br />
| Fatal error viewer ([[ErrDisp]])<br />
|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]])<br />
|-<br />
|colspan=6| 00008A03<br />
| <br />
| SAFE_MODE [[ErrDisp]]<br />
|colspan=3| v0<br />
|-<br />
| 20008A03<br />
| 20008A03<br />
| 20008A03<br />
| ?<br />
| 20008A03<br />
| N/A<br />
| <br />
| [[New_3DS]] SAFE_MODE [[ErrDisp]]<br />
|colspan=3| [[8.1.0-0_New3DS|v7169]]<br />
|-<br />
| 00008D02<br />
| 00009602<br />
| 00009F02<br />
| 0000A702<br />
| 0000AF02<br />
| 0000B702<br />
| CTR-N-HFR?<br />
| Friend List (friend)<br />
|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]])<br />
|-<br />
| 00008E02<br />
| 00009702<br />
| 0000A002<br />
| 0000A802<br />
| 0000B002<br />
| 0000B802<br />
| CTR-N-HCR?<br />
| Notifications (newslist)<br />
|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]])<br />
|-<br />
| 0000C002<br />
| 0000C802<br />
| 0000D002<br />
| 0000D802<br />
| 0000DE02<br />
| 0000E402<br />
| CTR-N-HKY?<br />
| Software Keyboard (swkbd)<br />
|colspan=3| v0, v1026, v2053, [[7.0.0-13|v3072]], [[9.0.0-20|v4096]](Also for [[8.1.0-0_New3DS]])<br />
|-<br />
| 0000C003<br />
| 0000C803<br />
| 0000D003<br />
| 0000D803<br />
| 0000DE03<br />
| 0000E403<br />
| <br />
| SAFE_MODE Software Keyboard (swkbd)<br />
|colspan=3| v0<br />
|-<br />
| 2000C003<br />
| 2000C803<br />
| 2000D003<br />
| ?<br />
| 2000DE03<br />
| N/A<br />
| <br />
| [[New 3DS]] SAFE_MODE Software Keyboard (swkbd)<br />
| [[8.1.0-0_New3DS|v1024]]<br />
|colspan=2|[[9.0.0-20|v0]]<br />
|-<br />
| 0000C102<br />
| 0000C902<br />
| 0000D102<br />
| 0000D902<br />
| 0000DF02<br />
| 0000E502<br />
| CTR-N-HMS?<br />
| Mii picker (appletEd)<br />
|colspan=3| v0, v1026, [[9.0.0-20|v2048]](Also for [[8.1.0-0_New3DS]]), [[9.3.0-21|v3077]]<br />
|-<br />
| 0000C302<br />
| 0000CB02<br />
| 0000D302<br />
| 0000DB02<br />
| 0000E102<br />
| 0000E702<br />
| CTR-N-HCC?<br />
| Picture picker (PNOTE_AP)<br />
|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]]<br />
|-<br />
| 0000C402<br />
| 0000CC02<br />
| 0000D402<br />
| 0000DC02<br />
| 0000E202<br />
| 0000E802<br />
| CTR-N-HMC?<br />
| [[Nintendo 3DS Sound|Voice memo]] picker (SNOTE_AP)<br />
|colspan=3| v0, v3, [[8.0.0-18|v1026]], [[9.0.0-20|v2048]](Also for [[8.1.0-0_New3DS]])<br />
|-<br />
|colspan=3| 0000C502<br />
|colspan=3| 0000CF02<br />
| CTR-N-HEEA<br />
CTR-N-HEEK<br />
| Non-critical (online, etc) error display (error)<br />
|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]]<br />
|-<br />
|colspan=3| 0000C503<br />
|colspan=3| 0000CF03<br />
| <br />
| SAFE_MODE error applet<br />
|colspan=3| v0<br />
|-<br />
| 2000C503<br />
| 2000C503<br />
| 2000C503<br />
| ?<br />
| 2000CF03<br />
| N/A<br />
| <br />
| [[New 3DS]] SAFE_MODE error applet<br />
|colspan=3| [[8.1.0-0_New3DS|v1024]]<br />
|-<br />
|colspan=3| 0000CD02<br />
|colspan=3| 0000D502<br />
| CTR-N-HADA<br />
CTR-N-HADK<br />
| [[Circle Pad Pro]] test/calibration applet (extrapad)<br />
|colspan=3| v1, v1026, [[8.1.0-0_New3DS|v2048]]([[8.1.0-0_New3DS]]), [[9.0.0-20|v3073]]<br />
|-<br />
| 0000C602<br />
| 0000CE02<br />
| 0000D602<br />
| N/A<br />
| 0000E302<br />
| 0000E902<br />
| CTR-N-HAA?<br />
| eShop applet, used by applications for accessing the eShop, for DLC/etc. Also used by the eShop application itself. (mint)<br />
|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]]<br />
|-<br />
| 0000BC02<br />
| 0000BD02<br />
| 0000BE02<br />
| ?<br />
| N/A<br />
| ?<br />
| CTR-N-HAE?<br />
| Miiverse (olv)<br />
|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]]<br />
|-<br />
|colspan=3| 0000F602<br />
| ?<br />
| N/A<br />
| ?<br />
| CTR-N-HAGA<br />
| Likely the "system library" for Miiverse (memolib)<br />
|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]]<br />
|-<br />
| 00008302<br />
| 00008B02<br />
| 0000BA02<br />
| ?<br />
| N/A<br />
| ?<br />
| CTR-N-HAH?<br />
| In-app Miiverse-posting applet (solv3)<br />
|colspan=3| [[9.0.0-20|v6]]<br />
|-<br />
| 00009502<br />
| 00009E02<br />
| 0000B902<br />
| ?<br />
| 00008C02<br />
| 0000BF02<br />
| CTR-N-HA3?<br />
| Cabinet ([[amiibo Settings]])<br />
|colspan=3| [[9.3.0-21|v7]], (v1024 for TWN), [[9.6.0-24|v1031]]<br />
|}<br />
<br />
=== 0004009B - [[NCCH#CFA|Shared Data Archives]] ===<br />
{| class="wikitable sortable" border="1"<br />
|-<br />
! JPN TitleIDLow<br />
! USA TitleIDLow<br />
! EUR TitleIDLow<br />
! CHN TitleIDLow<br />
! KOR TitleIDLow<br />
! TWN TitleIDLow<br />
! Description<br />
! Versions<br />
|-<br />
| 00010202<br />
| 00010202<br />
| 00010202<br />
| 00010202<br />
| 00010202<br />
| 00010202<br />
| Probably Mii-related, contains "CFL_Res.dat" in the RomFS.<br />
| v0<br />
|-<br />
| 00010402<br />
| 00010402<br />
| 00010402<br />
| 00010402<br />
| 00010402<br />
| 00010402<br />
| Region Manifest. Mounted as "area:"<br />
| v0, v1024, v2050, v3072, [[7.0.0-13|v4098]], [[9.6.0-24|v5122]]<br />
|-<br />
| 00010602<br />
| 00010602<br />
| 00010602<br />
| 00010602<br />
| 00010602<br />
| 00010602<br />
| Non-Nintendo TLS Root-CA Certificates (RomFS contains files with filename "CACERT_PUBLIC_CA_<val>.der", where <val> is 5..8)<br />
| v2, [[10.5.0-30|v1024]]<br />
|-<br />
|<br />
|<br />
|<br />
| 00011002<br />
| <br />
| <br />
| "CHN/CN" Dictionary.<br />
| v1<br />
|-<br />
| <br />
| <br />
|<br />
|<br />
|<br />
| 00011102 <br />
| "TWN/TN" dictionary.<br />
| v1<br />
|-<br />
| <br />
| <br />
| 00011202<br />
|<br />
|<br />
| <br />
| "NL/NL" dictionary.<br />
| v0<br />
|-<br />
| <br />
| <br />
| 00011302<br />
|<br />
|<br />
| <br />
| "EN/GB" dictionary.<br />
| v0<br />
|-<br />
| <br />
| 00011402<br />
|<br />
| <br />
| <br />
|<br />
| "EN/US" dictionary.<br />
| v0<br />
|-<br />
| <br />
| <br />
| 00011502<br />
|<br />
|<br />
| <br />
| "FR/FR/regular" dictionary.<br />
| v0<br />
|-<br />
| <br />
| 00011602<br />
|<br />
|<br />
| <br />
| <br />
| "FR/CA/regular" dictionary.<br />
| v0<br />
|-<br />
| <br />
| <br />
| 00011702<br />
|<br />
| <br />
| <br />
| "DE/regular" dictionary.<br />
| v0<br />
|-<br />
| <br />
| <br />
| 00011802<br />
|<br />
| <br />
| <br />
| "IT/IT" dictionary.<br />
| v0<br />
|-<br />
| 00011902<br />
| <br />
|<br />
| <br />
|<br />
| <br />
| "JA_small/32" dictionary.<br />
| v0<br />
|-<br />
| <br />
| <br />
|<br />
|<br />
| 00011A02<br />
| <br />
| "KO/KO" dictionary.<br />
| v1<br />
|-<br />
| <br />
| <br />
| 00011B02<br />
|<br />
|<br />
| <br />
| "PT/PT/regular" dictionary.<br />
| v0<br />
|-<br />
| <br />
| <br />
| 00011C02<br />
|<br />
|<br />
| <br />
| "RU/regular" dictionary.<br />
| v0<br />
|-<br />
| <br />
| 00011D02<br />
| 00011D02<br />
|<br />
|<br />
| <br />
| "ES/ES" dictionary.<br />
| v0<br />
|-<br />
| <br />
| 00011E02<br />
|<br />
| <br />
|<br />
| <br />
| "PT/BR/regular" dictionary.<br />
| v0<br />
|-<br />
| 00012202<br />
| 00012302<br />
| 00012102<br />
| 00012402<br />
| 00012502<br />
| 00012602<br />
| ?contains a lists with error strings<br />
| 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]])<br />
|-<br />
| 00013202<br />
| 00013302<br />
| 00013102<br />
| 00013502<br />
| <br />
| <br />
| Mounted as "eula:"<br />
| 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]])<br />
|-<br />
| 00014002<br />
| 00014002<br />
| 00014002<br />
| 00014002<br />
| 00014002<br />
| 00014002<br />
| JPN/EUR/USA [[System Font]] ("font:")<br />
| v0<br />
|-<br />
| 00014102<br />
| 00014102<br />
| 00014102<br />
| 00014102<br />
| 00014102<br />
| 00014102<br />
| CHN [[System Font]] ("font:")<br />
| v0, v1024<br />
|-<br />
| 00014202<br />
| 00014202<br />
| 00014202<br />
| 00014202<br />
| 00014202<br />
| 00014202<br />
| KOR [[System Font]] ("font:")<br />
| v0, v1024<br />
|-<br />
| 00014302<br />
| 00014302<br />
| 00014302<br />
| 00014302<br />
| 00014302<br />
| 00014302<br />
| TWN [[System Font]] ("font:")<br />
| v0, v1024<br />
|-<br />
| 00015202<br />
| 00015302<br />
| 00015102<br />
| N/A<br />
| 00015502<br />
| 0015602<br />
| Mounted as "rate:"<br />
| v0 (EUR: v0, v1024) (KOR: v1024)<br />
|}<br />
<br />
=== 000400DB - [[NCCH#CFA|System Data Archives]] ===<br />
==== System Data Archive Notes ====<br />
These [[NVer]] titleIDs can be found @ offset 0x320 in every [[CCI]].<br />
<br />
{| class="wikitable sortable" border="1"<br />
|-<br />
! EUR TitleIDLow<br />
! JPN TitleIDLow<br />
! USA TitleIDLow<br />
! CHN TitleIDLow<br />
! KOR TitleIDLow<br />
! TWN TitleIDLow<br />
! Description<br />
! USA/EUR/JPN Versions<br />
! CHN Versions<br />
! TWN Versions<br />
! KOR Versions<br />
|-<br />
| 00010302<br />
| 00010302<br />
| 00010302<br />
| 00010302<br />
| 00010302<br />
| 00010302<br />
| NGWord bad word list<br />
| [[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]]<br />
| Same as USA<br />
| Same as USA<br />
| Same as USA<br />
|-<br />
| 00010502<br />
| 00010502<br />
| 00010502<br />
| 00010502<br />
| 00010502<br />
| 00010502<br />
| [[Nintendo Zone]] hotspot list<br />
| [[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]]<br />
| Same as USA<br />
| Same as USA<br />
| Same as USA<br />
|-<br />
| 00016102<br />
| 00016202<br />
| 00016302<br />
| 00016402<br />
| 00016502<br />
| 00016602<br />
| [[NVer]]<br />
| [[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]]<br />
| [[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]]<br />
| [[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]]<br />
| [[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]]<br />
|-<br />
| 20016102<br />
| 20016202<br />
| 20016302<br />
| N/A<br />
| 20016502<br />
| N/A<br />
| [[New_3DS]] [[NVer]]<br />
| [[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]]<br />
| N/A<br />
| N/A<br />
| [[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]]<br />
|-<br />
| 00017102<br />
| 00017202<br />
| 00017302<br />
| 00017402<br />
| 00017502<br />
| 00017602<br />
| [[CVer]]<br />
| [[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]]<br />
| [[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]]<br />
| Same as CHN<br />
| Same as CHN + [[11.1.0-34|v11280]]<br />
|}<br />
<br />
=== 00040130 - System [[Services API|Modules]] ===<br />
==== System Module Notes ====<br />
Once Home Menu finishes loading, all of the below system modules are running, except for MP, RO, and act which are automatically [[Process_Manager_Services|loaded]] when a process requires them. <br />
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. <br />
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.<br />
All of the below system modules use the "BASE" [[SVC|memory-region]](specified in the exheader), except when listed otherwise for certain modules.<br />
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). <br />
The exheader dependency list handling change is for the [[New 3DS]] system-module(s), which do not exist on Old3DS. <br />
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.<br />
<br />
{| class="wikitable sortable" border="1"<br />
|-<br />
! TitleID Low<br />
! Description<br />
! Versions<br />
|-<br />
| 00001002<br />
| [[Services|sm]] (Stored in [[FIRM|NATIVE_FIRM]])<br />
| N/A<br />
|-<br />
| 00001003<br />
| SAFE_MODE [[Services|sm]] (Stored in SAFE_MODE NATIVE_FIRM)<br />
| N/A<br />
|-<br />
| 00001102<br />
| [[Filesystem services‎|fs]] (Stored in [[FIRM|NATIVE_FIRM]])<br />
| N/A<br />
|-<br />
| 00001103<br />
| SAFE_MODE [[Filesystem services‎|fs]] (Stored in SAFE_MODE NATIVE_FIRM)<br />
| N/A<br />
|-<br />
| 00001202<br />
| [[Process Manager Services|pm]] (Stored in [[FIRM|NATIVE_FIRM]])<br />
| N/A<br />
|-<br />
| 00001203<br />
| SAFE_MODE [[Process Manager Services|pm]] (Stored in SAFE_MODE NATIVE_FIRM)<br />
| N/A<br />
|-<br />
| 00001302<br />
| [[Loader Services‎|loader]] (Stored in [[FIRM|NATIVE_FIRM]])<br />
| N/A<br />
|-<br />
| 00001303<br />
| SAFE_MODE [[Loader Services‎|loader]] (Stored in SAFE_MODE NATIVE_FIRM)<br />
| N/A<br />
|-<br />
| 00001402<br />
| [[PXI Services‎|pxi]] (Stored in [[FIRM|NATIVE_FIRM]])<br />
| N/A<br />
|-<br />
| 00001403<br />
| SAFE_MODE [[PXI Services‎|pxi]] (Stored in SAFE_MODE NATIVE_FIRM)<br />
| N/A<br />
|-<br />
| 00001502<br />
| [[Application Manager Services|AM]] ( Application Manager )<br />
| [[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]]<br />
|-<br />
| 00001503<br />
| SAFE_MODE [[Application Manager Services|AM]]<br />
| [[1.0.0-0|v0]]<br />
|-<br />
| 20001503<br />
| [[New_3DS]] SAFE_MODE [[Application Manager Services|AM]]<br />
| [[8.1.0-0_New3DS|v7169]]<br />
|-<br />
| 00001602<br />
| [[Camera Services|Camera]]<br />
| [[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]]<br />
|-<br />
| 20001602<br />
| [[New_3DS]] [[Camera Services|Camera]]<br />
| [[8.1.0-0_New3DS|v8200]], [[9.0.0-20|v9218]], [[9.3.0-21|v10242]], [[10.0.0-27|v11265]]<br />
|-<br />
| 00001702<br />
| [[Config Services|Config]] (cfg)<br />
| [[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]]<br />
|-<br />
| 00001703<br />
| SAFE_MODE [[Config Services|Config]] (cfg)<br />
| [[1.0.0-0|v0]]<br />
|-<br />
| 20001703<br />
| [[New_3DS]] SAFE_MODE [[Config Services|Config]] (cfg)<br />
| [[8.1.0-0_New3DS|v11265]]<br />
|-<br />
| 00001802<br />
| [[Codec Services|Codec]]<br />
| [[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]])<br />
|-<br />
| 00001803<br />
| SAFE_MODE [[Codec Services|Codec]]<br />
| [[1.0.0-0|v0]]<br />
|-<br />
| 20001803<br />
| [[New_3DS]] SAFE_MODE [[Codec Services|Codec]]<br />
| [[8.1.0-0_New3DS|v7169]]<br />
|-<br />
| 00001A02<br />
| [[DSP Services|DSP]]<br />
| [[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]]<br />
|-<br />
| 00001A03<br />
| SAFE_MODE [[DSP Services|DSP]]<br />
| [[1.0.0-0|v0]]<br />
|-<br />
| 20001A03<br />
| [[New_3DS]] SAFE_MODE [[DSP Services|DSP]]<br />
| [[8.1.0-0_New3DS|v6145]]<br />
|-<br />
| 00001B02<br />
| [[GPIO Services|GPIO]]<br />
| [[1.0.0-0|v0]], [[5.0.0-11|v1025]], [[8.0.0-18|v2048]], [[9.5.0-22|v3073]]<br />
|-<br />
| 00001B03<br />
| SAFE_MODE [[GPIO Services|GPIO]]<br />
| [[1.0.0-0|v0]]<br />
|-<br />
| 20001B03<br />
| [[New_3DS]] SAFE_MODE [[GPIO Services|GPIO]]<br />
| [[8.1.0-0_New3DS|v3073]]<br />
|-<br />
| 00001C02<br />
| [[GSP Services|GSP]]<br />
| [[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]]<br />
|-<br />
| 20001C02<br />
| [[New_3DS]] [[GSP Services|GSP]]<br />
| [[8.1.0-0_New3DS|v10243]], [[9.3.0-21|v11267]], [[9.6.0-24|v12294]], [[11.3.0-36|v13312]]<br />
|-<br />
| 00001C03<br />
| SAFE_MODE [[GSP Services|GSP]]<br />
| [[1.0.0-0|v0]]<br />
|-<br />
| 20001C03<br />
| [[New_3DS]] SAFE_MODE [[GSP Services|GSP]]<br />
| [[8.1.0-0_New3DS|v9217]]<br />
|-<br />
| 00001D02<br />
| [[HID Services|HID]] (Human Interface Devices) <br />
| [[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]]<br />
|-<br />
| 00001D03<br />
| SAFE_MODE [[HID Services|HID]]<br />
| [[1.0.0-0|v0]]<br />
|-<br />
| 20001D03<br />
| [[New_3DS]] SAFE_MODE [[HID Services|HID]]<br />
| [[8.1.0-0_New3DS|v8193]]<br />
|-<br />
| 00001E02<br />
| [[I2C Services|i2c]]<br />
| [[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]]<br />
|-<br />
| 20001E02<br />
| [[New_3DS]] [[I2C Services|i2c]]<br />
| [[8.1.0-0_New3DS|v4096]], [[9.3.0-21|v5121]]<br />
|- <br />
| 00001E03<br />
| SAFE_MODE [[I2C Services|i2c]]<br />
| [[1.0.0-0|v0]]<br />
|- <br />
| 20001E03<br />
| [[New_3DS]] SAFE_MODE [[I2C Services|i2c]]<br />
| [[8.1.0-0_New3DS|v4097]]<br />
|-<br />
| 00001F02<br />
| [[MCU Services|MCU]]<br />
| [[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]]<br />
|-<br />
| 20001F02<br />
| [[New_3DS]] [[MCU Services|MCU]]<br />
| [[8.1.0-0_New3DS|v8192]]<br />
|-<br />
| 00001F03<br />
| SAFE_MODE [[MCU Services|MCU]]<br />
| [[1.0.0-0|v0]]<br />
|-<br />
| 20001F03<br />
| [[New_3DS]] SAFE_MODE [[MCU Services|MCU]]<br />
| [[8.1.0-0_New3DS|v9217]]<br />
|-<br />
| 00002002<br />
| [[MIC Services|MIC]] (Microphone)<br />
| [[1.0.0-0|v0]], [[5.0.0-11|v1025]], [[8.0.0-18|v2048]]<br />
|-<br />
| 00002102<br />
| [[PDN Services|PDN]]<br />
| [[1.0.0-0|v0]], [[5.0.0-11|v1025]], [[8.0.0-18|v2048]]<br />
|-<br />
| 00002103<br />
| SAFE_MODE [[PDN Services|PDN]]<br />
| [[1.0.0-0|v0]]<br />
|-<br />
| 20002103<br />
| [[New_3DS]] SAFE_MODE [[PDN Services|PDN]]<br />
| [[8.1.0-0_New3DS|v3073]]<br />
|-<br />
| 00002202<br />
| [[PTM Services|PTM]] (Play time, pedometer, and battery manager)<br />
| [[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]]<br />
|-<br />
| 20002202<br />
| [[New_3DS]] [[PTM Services|PTM]] (Play time, pedometer, and battery manager)<br />
| [[8.1.0-0_New3DS|v10240]], [[9.6.0-24|v11264]]<br />
|-<br />
| 00002203<br />
| SAFE_MODE [[PTM Services|PTM]]<br />
| [[1.0.0-0|v0]]<br />
|-<br />
| 20002203<br />
| [[New_3DS]] SAFE_MODE [[PTM Services|PTM]]<br />
| [[8.1.0-0_New3DS|v10241]]<br />
|-<br />
| 00002302<br />
| [[SPI Services|spi]]<br />
| [[1.0.0-0|v0]], [[2.0.0-2|v1025]], [[5.0.0-11|v2049]], [[8.0.0-18|v3072]]<br />
|-<br />
| 20002302<br />
| [[New_3DS]] [[SPI Services|spi]]<br />
| [[8.1.0-0_New3DS|v4096]]<br />
|-<br />
| 00002303<br />
| SAFE_MODE [[SPI Services|spi]]<br />
| [[1.0.0-0|v0]]<br />
|-<br />
| 20002303<br />
| [[New_3DS]] SAFE_MODE [[SPI Services|spi]]<br />
| [[8.1.0-0_New3DS|v4097]]<br />
|-<br />
| 00002402<br />
| [[AC Services|AC]] (Network manager)<br />
| [[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]]<br />
|-<br />
| 00002403<br />
| SAFE_MODE [[AC Services|AC]]<br />
| [[1.0.0-0|v0]]<br />
|-<br />
| 20002403<br />
| [[New_3DS]] SAFE_MODE [[AC Services|AC]]<br />
| [[8.1.0-0_New3DS|v8193]]<br />
|-<br />
| 00002602<br />
| [[CECD Services|Cecd]] (StreetPass)<br />
| [[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]]<br />
|-<br />
| 00002702<br />
| [[CSND Services|CSND]]<br />
| [[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]]<br />
|-<br />
| 00002703<br />
| SAFE_MODE [[CSND Services|CSND]]<br />
| [[1.0.0-0|v0]]<br />
|-<br />
| 20002703<br />
| [[New_3DS]] SAFE_MODE [[CSND Services|CSND]]<br />
| [[8.1.0-0_New3DS|v5121]]<br />
|-<br />
| 00002802<br />
| [[DLP Services|DLP]] ([[Download Play]])<br />
| [[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]]<br />
|-<br />
| 00002902<br />
| [[HTTP Services|HTTP]]<br />
| [[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]]<br />
|-<br />
| 00002903<br />
| SAFE_MODE [[HTTP Services|HTTP]]<br />
| [[1.0.0-0|v0]]<br />
|-<br />
| 20002903<br />
| [[New_3DS]] SAFE_MODE [[HTTP Services|HTTP]]<br />
| [[8.1.0-0_New3DS|v10241]]<br />
|-<br />
| 00002A02<br />
| [[MP Services|MP]]<br />
| [[1.0.0-0|v0]], [[5.0.0-11|v1025]], [[8.0.0-18|v2048]]<br />
|-<br />
| 00002A03<br />
| SAFE_MODE [[MP Services|MP]]<br />
| [[1.0.0-0|v0]]<br />
|-<br />
| 00002B02<br />
| [[NDM Services|NDM]]<br />
| [[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]]<br />
|-<br />
| 00002C02<br />
| [[NIM Services|NIM]]<br />
| [[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]]<br />
|-<br />
| 00002C03<br />
| SAFE_MODE [[NIM Services|NIM]]<br />
| [[1.0.0-0|v0]]<br />
|-<br />
| 20002C03<br />
| [[New_3DS]] SAFE_MODE [[NIM Services|NIM]]<br />
| [[8.1.0-0_New3DS|v9217]]<br />
|-<br />
| 00002D02<br />
| [[NWM Services|NWM]] ( Low-level wifi manager )<br />
| [[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]]<br />
|-<br />
| 00002D03<br />
| SAFE_MODE [[NWM Services|NWM]]<br />
| [[1.0.0-0|v0]], [[6.0.0-11|v5120]]<br />
|-<br />
| 20002D03<br />
| [[New_3DS]] SAFE_MODE [[NWM Services|NWM]]<br />
| [[8.1.0-0_New3DS|v10241]]<br />
|-<br />
| 00002E02<br />
| [[Socket Services|Sockets]]<br />
| [[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]]<br />
|-<br />
| 00002E03<br />
| SAFE_MODE [[Socket Services|Sockets]]<br />
| [[1.0.0-0|v0]]<br />
|-<br />
| 20002E03<br />
| [[New_3DS]] SAFE_MODE [[Socket Services|Sockets]]<br />
| [[8.1.0-0_New3DS|v7169]]<br />
|-<br />
| 00002F02<br />
| [[SSL Services|SSL]]<br />
| [[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]]<br />
|-<br />
| 00002F03<br />
| SAFE_MODE [[SSL Services|SSL]]<br />
| [[1.0.0-0|v0]]<br />
|-<br />
| 20002F03<br />
| [[New_3DS]] SAFE_MODE [[SSL Services|SSL]]<br />
| [[8.1.0-0_New3DS|v7169]]<br />
|-<br />
| 00003000<br />
| [[FIRM|Process9]] (in SAFE_MODE and normal NATIVE_FIRM)<br />
| <br />
|-<br />
| 00003102<br />
| [[Process Services‎|PS]] ( Process Manager )<br />
| [[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]]<br />
|-<br />
| 00003103<br />
| SAFE_MODE [[Process Services‎|PS]]<br />
| [[1.0.0-0|v0]]<br />
|-<br />
| 20003103<br />
| [[New_3DS]] SAFE_MODE [[Process Services‎|PS]]<br />
| [[8.1.0-0_New3DS|v5121]]<br />
|-<br />
| 00003202<br />
| [[Friend Services‎|friends]] (Friends list)<br />
| [[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]], [[11.4.0-37|v15360]]<br />
|-<br />
| 00003203<br />
| SAFE_MODE [[Friend Services‎|friends]] (Friends list)<br />
| [[1.0.0-0|v0]]<br />
|-<br />
| 20003203<br />
| [[New_3DS]] SAFE_MODE [[Friend Services‎|friends]] (Friends list)<br />
| [[8.1.0-0_New3DS|v8193]]<br />
|-<br />
| 00003302<br />
| [[IR Services‎|IR]] (Infrared)<br />
| [[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]]<br />
|-<br />
| 00003303<br />
| SAFE_MODE [[IR Services‎|IR]]<br />
| [[1.0.0-0|v0]]<br />
|-<br />
| 20003303<br />
| [[New_3DS]] SAFE_MODE [[IR Services‎|IR]]<br />
| [[8.1.0-0_New3DS|v7169]]<br />
|- <br />
| 00003402<br />
| [[BOSS Services‎|BOSS]] (SpotPass)<br />
| [[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]]<br />
|-<br />
| 00003502<br />
| [[News Services‎|News]] (Notifications)<br />
| [[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]]<br />
|-<br />
| 00003702<br />
| [[RO_Services|RO]]<br />
| [[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]]<br />
|-<br />
| 00003802<br />
| [[ACT Services‎|act]] (handles Nintendo Network '''a'''c'''c'''oun'''t'''s)<br />
| [[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]]<br />
|-<br />
| 00004002<br />
| Old3DS [[NFC_Services|nfc]]<br />
| [[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]]<br />
|-<br />
| 20004002<br />
| [[New_3DS]] [[NFC_Services|nfc]]<br />
| [[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]]<br />
|-<br />
| 20004102<br />
| [[New_3DS]] [[MVD Services|mvd]]<br />
| [[8.1.0-0_New3DS|v0]], [[9.0.0-20|v1024]]<br />
|-<br />
| 20004202<br />
| [[New_3DS]] [[QTM Services|qtm]]<br />
| [[8.1.0-0_New3DS|v8]], [[9.0.0-20|v1024]], [[9.3.0-21|v2052]]<br />
|-<br />
| 00008002<br />
| [[NS]] (Memory-region: "SYSTEM")<br />
| [[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]]<br />
|-<br />
| 00008003<br />
| SAFE_MODE [[NS]] (Memory-region: "SYSTEM")<br />
| [[1.0.0-0|v0]]<br />
|-<br />
| 20008003<br />
| [[New_3DS]] SAFE_MODE [[NS]] (Memory-region: "SYSTEM")<br />
| [[8.1.0-0_New3DS|v13313]]<br />
|}<br />
<br />
=== 00040138 - [[FIRM|System Firmware]] ===<br />
==== System Firmare Notes ====<br />
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/<TID>/data use a custom format, this is handled by AGB_FIRM.<br />
<br />
{| class="wikitable sortable" border="1"<br />
|-<br />
! TitleID Low<br />
! Description<br />
! USA/EUR/JPN Versions<br />
! CHN Versions<br />
! KOR Versions<br />
! TWN Versions<br />
|-<br />
| 00000001<br />
| Unknown, very similar to SAFE_MODE_FIRM. Exists only on dev units and seems to only be used by SystemUpdaters.<br />
| v0<br />
| <br />
| <br />
| <br />
|-<br />
| 00000002<br />
| NATIVE_FIRM (Native Firmware)<br />
| [[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]]<br />
| Same as USA/EUR/JPN starting with the USA/EUR/JPN [[4.0.0-7]] title-version<br />
| Same as CHN.<br />
| Same as CHN.<br />
|-<br />
| 20000002<br />
| [[New_3DS]] NATIVE_FIRM (Native Firmware)<br />
| [[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]]<br />
| N/A<br />
| Same as CHN.<br />
| Same as CHN.<br />
|-<br />
| 00000003<br />
| SAFE_MODE_FIRM <br />
| [[1.0.0-0|v432]], [[3.0.0-5|v5632]]<br />
| Same as USA/EUR/JPN starting with the USA/EUR/JPN [[3.0.0-5]] title-version<br />
| Same as CHN.<br />
| Same as CHN.<br />
|-<br />
| 20000003<br />
| [[New_3DS]] SAFE_MODE_FIRM <br />
| [[8.1.0-0_New3DS|v16081]]<br />
| N/A<br />
| Same as CHN.<br />
| Same as CHN.<br />
|-<br />
| 00000102 <br />
| TWL_FIRM ( DSi Firmware )<br />
| [[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]]<br />
| Same as USA/EUR/JPN starting with the USA/EUR/JPN [[4.0.0-7]] title-version<br />
| Same as CHN.<br />
| Same as CHN.<br />
|-<br />
| 20000102 <br />
| [[New_3DS]] TWL_FIRM ( DSi Firmware )<br />
| [[8.1.0-0_New3DS|v9936]]<br />
| N/A<br />
| Same as CHN.<br />
| Same as CHN.<br />
|- <br />
| 00000202<br />
| AGB_FIRM ( GBA Firmware )<br />
| [[3.0.0-5|v519]], v1553, [[4.0.0-7|v2576]], [[6.0.0-11|v3665]]<br />
| [[4.0.0-7|v2576]]<br />
| [[4.0.0-7|v2576]], [[6.0.0-11|v3665]]<br />
| Same as CHN.<br />
|- <br />
| 20000202<br />
| [[New_3DS]] AGB_FIRM ( GBA Firmware )<br />
| [[8.1.0-0_New3DS|v4816]]<br />
| N/A<br />
| N/A<br />
| N/A<br />
|}<br />
<br />
== Application Titles ==<br />
{| class="wikitable sortable" border="1"<br />
|-<br />
! Category Bit Mask<br />
! Content Category<br />
! Bit Mask(s)<br />
|-<br />
| 0x0000<br />
| [[Title list/eShop Titles|Application / eShop]]<br />
| Normal<br />
|-<br />
| 0x0001<br />
| Download Play Child<br />
| DlpChild<br />
|-<br />
| 0x0002<br />
| [[EShop Demos|Demo]]<br />
| Demo<br />
|-<br />
| 0x000E<br />
| [[Title list/Patches|Patch]]<br />
| CannotExecution<nowiki> | </nowiki>Patch<br />
|-<br />
| 0x008C<br />
| [[Title list/DLC|Downloadable Content]]<br />
| NotRequireRightForMount<nowiki> | </nowiki>CannotExecution<nowiki> | </nowiki>AddOnContents<br />
|}<br />
<br />
=== 00040001 - [[Download Play]] Titles ===<br />
==== Download Play Notes ====<br />
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.<br />
<br />
== Factory Titles ==<br />
==== Factory Titles Notes ====<br />
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.<br />
<br />
{| class="wikitable sortable" border="1"<br />
|-<br />
! TitleID<br />
! Description<br />
! Versions<br />
|-<br />
| 000400000F802A00<br />
| Unknown. Appears to be a [[9.8.0-25|gamecard]] title. See also [[11.3.0-36|here]].<br />
Used during [[Nintendo_Service_Center_Tools|repair]], first non-system title listed in [[PTM_Services|playlog]] from repair.<br />
| ?<br />
|-<br />
| 000400000F802100<br />
| Used during [[Nintendo_Service_Center_Tools|repair]], second non-system title listed in [[PTM_Services|playlog]] from repair.<br />
| ?<br />
|-<br />
| 000400000F802200<br />
| Used during [[Nintendo_Service_Center_Tools|repair]], third non-system title listed in [[PTM_Services|playlog]] from repair.<br />
| ?<br />
|-<br />
| 000400000FFFFD00<br />
| Used by retail NS for appID 0xF11, but this isn't available on retail CDN.<br />
| ?<br />
|-<br />
| 000400000FFFFC00<br />
| Used by retail NS for appID 0xF12, but this isn't available on retail CDN.<br />
| ?<br />
|-<br />
| 000400000FFFFB00<br />
| Used by retail NS for appID 0xF13, but this isn't available on retail CDN.<br />
| ?<br />
|-<br />
| 000400000FFFF900<br />
| Used by retail NS for appID 0xF14, but this isn't available on retail CDN.<br />
| ?<br />
|-<br />
| 000400000FFFF800<br />
| Used by retail NS for appID 0xF15, but this isn't available on retail CDN.<br />
| ?<br />
|-<br />
| 000400000FFFF700<br />
| Used by retail NS for appID 0xF16, but this isn't available on retail CDN.<br />
| ?<br />
|-<br />
| 000400000FFFF600<br />
| Used by retail NS for appID 0xF17, but this isn't available on retail CDN.<br />
| ?<br />
|-<br />
| 000400000FFFF500<br />
| Used by retail NS for appID 0xF18, but this isn't available on retail CDN.<br />
| ?<br />
|-<br />
| 0004003000008900<br />
| Used by retail NS for appID 0xF10, but this isn't available on retail CDN.<br />
| ?<br />
|-<br />
| 0004013000001902<br />
| dmnt, debugger sysmodule. This use devunit-only HIO for devunit<>pc comms. This only exists for development units(launched by NS during startup depending on certain [[Configuration_Memory]] fields' values). <br />
This is installed at the [[Factory_Setup|factory]], then later deleted at the factory on retail units.<br />
| ?<br />
|-<br />
| 0004013000003602<br />
| "debugger". This only exist for development units(launched by NS during startup depending on certain [[Configuration_Memory]] fields' values).<br />
| ?<br />
|}<br />
<br />
== TWL (DSi) Titles ==<br />
==== TWL Title Notes ====<br />
Bitmask 0x1 for TWL titles denotes a system title (determining whether the title will be updated during a System Update).<br />
<br />
It appears to be sufficient, but not necessary, to make the title invisible on the [[Home Menu]].<br />
<br />
Bitmask 0x2 for TWL titles may indicate no-execute.<br />
<br />
Bitmask 0x4 for TWL titles indicates internal storage.<br />
<br />
Bitmask 0x10 for TWL titles is found on developer tools.<br />
<br />
<br />
{| class="wikitable sortable" border="1"<br />
|-<br />
! Content Category<br />
! Bit Mask(s)<br />
! Category Bit Mask<br />
|-<br />
| Application (DSiWare)<br />
| TWL<nowiki> | </nowiki>0x4<br />
| 0x8004<br />
|-<br />
| System Application<br />
| TWL<nowiki> | </nowiki>0x1<nowiki> | </nowiki>0x4<br />
| 0x8005<br />
|-<br />
| System Archive<br />
| TWL<nowiki> | </nowiki>0x1<nowiki> | </nowiki>0x2<nowiki> | </nowiki>0x4<nowiki> | </nowiki>0x8<br />
| 0x800F<br />
|-<br />
| Developer Tool<br />
| TWL<nowiki> | </nowiki>0x1<nowiki> | </nowiki>0x4<nowiki> | </nowiki>0x10<br />
| 0x8015<br />
|}<br />
<br />
<br />
=== 00048005 - System Applications===<br />
{| class="wikitable sortable" border="1"<br />
|-<br />
! TitleID Low<br />
! Region<br />
! Description<br />
! Versions<br />
! Information<br />
|-<br />
| 42383841(B88A)<br />
| ALL<br />
| [[DS Internet]]<br />
| v0, [[2.1.0-4|v1025]], [[3.0.0-5|v2048]]<br />
| [[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. <br />
|-<br />
| 484E4441(HNDA)<br />
| ALL<br />
| [[Download Play]]<br />
| v1024<br />
| This [[Download Play]] application is the DS-mode Download Play client, launched by the 3DS-mode Download Play application.<br />
|-<br />
| 484E4443(HNDC)<br />
| CHN<br />
| [[Download Play]]<br />
| v1024<br />
| See Above Description.<br />
|-<br />
| 484E444B(HNDK)<br />
| KOR<br />
| [[Download Play]]<br />
| v1024<br />
| See Above Description.<br />
|}<br />
<br />
=== 0004800F - System Data Archives===<br />
==== System Data Archive Notes ====<br />
New system updates only block DS flash-cards when whitelist is updated, or when TWL_FIRM is updated. <br />
The whitelist contains the data used for detecting flash-cards, this is used by TWL_FIRM.<br />
<br />
{| class="wikitable sortable" border="1"<br />
|-<br />
! TitleID Low<br />
! Description<br />
! Versions<br />
|-<br />
| 484E4841(HNHA)<br />
| [[Nintendo DS Cart Whitelist]] - <br />
| 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]]<br />
|-<br />
| 484E4C41(HNLA)<br />
| [[Version Data]]<br />
| v0<br />
|}<br />
<br />
=== 00048004 - DSiWare Ports ===<br />
==== DSiWare Port Notes ====<br />
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.<br />
See [[3DS DSiWare Titles]] for a complete list.</div>Myriahttps://www.3dbrew.org/w/index.php?title=Title_list&diff=20053Title list2017-05-30T07:11:40Z<p>Myria: /* System Applet Notes */ product code for instruction manual</p>
<hr />
<div>==== CTR Title List Notes ====<br />
Reports/title-lists [https://yls8.mtheall.com/ninupdates/reports.php here] are automatically obtained from the system update SOAP.<br />
<br />
== CTR System Titles ==<br />
{| class="wikitable sortable" border="1"<br />
|-<br />
! Category Bit Mask<br />
! Title Type<br />
! Internal Description<br />
! Bit Mask(s)<br />
|-<br />
| 0x0010<br />
| Application<br />
| SYSTEM_APPLICATION<br />
| Normal<nowiki> | </nowiki>System<br />
|-<br />
| 0x001B<br />
| System Data Archives<br />
| SYSTEM_CONTENT<br />
| Contents<nowiki> | </nowiki>CannotExecution<nowiki> | </nowiki>System<br />
|-<br />
| 0x009B<br />
| Shared Data Archives<br />
| SHARED_CONTENT<br />
| Contents<nowiki> | </nowiki>CannotExecution<nowiki> | </nowiki>System<nowiki> | </nowiki>NotRequireRightForMount<br />
|-<br />
| 0x00DB<br />
| System Data Archives<br />
| AUTO_UPDATE_CONTENT<br />
| Contents<nowiki> | </nowiki>CannotExecution<nowiki> | </nowiki>System<nowiki> | </nowiki>NotRequireUserApproval<nowiki> | </nowiki>NotRequireRightForMount<br />
|-<br />
| 0x0030<br />
| Applet<br />
| APPLET<br />
| Normal<nowiki> | </nowiki>System<nowiki> | </nowiki>RequireBatchUpdate<br />
|-<br />
| 0x0130<br />
| Module<br />
| BASE<br />
| Normal<nowiki> | </nowiki>System<nowiki> | </nowiki>RequireBatchUpdate<nowiki> | </nowiki>CanSkipConvertJumpId<br />
|-<br />
| 0x0138<br />
| Firmware <br />
| FIRMWARE<br />
| Normal<nowiki> | </nowiki>CannotExecution<nowiki> | </nowiki>System<nowiki> | </nowiki>RequireBatchUpdate<nowiki> | </nowiki>CanSkipConvertJumpId<br />
|}<br />
<br />
=== 00040010 - System Applications ===<br />
==== System Application Notes ====<br />
System Application titles have a unique title low that varies by region.<br />
Regardless of version, the ExeFS:/.code for mset is the same for USA/EUR/JPN. <br />
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). <br />
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.<br />
The ''only'' system-applications included with gamecard-sysupdates are: [[System Settings]], [[Download Play]], and SAFE_MODE [[System Settings#System Updater|System Updater]]. <br />
The only system-applications included with the New3DS gamecard-sysupdate partition are: "menu" stub and "friend" stub.<br />
<br />
{| class="wikitable sortable" border="1"<br />
|-<br />
! JPN TIDLow<br />
! USA TIDLow<br />
! EUR TIDLow<br />
! CHN TIDLow<br />
! KOR TIDLow<br />
! TWN TIDLow<br />
! [[Product code]]<br />
! Description<br />
! JPN Versions<br />
! EUR Versions<br />
! USA Versions<br />
! CHN Versions<br />
! KOR Versions<br />
! TWN Versions<br />
! Status<br />
|-<br />
| 00020000<br />
| 00021000<br />
| 00022000<br />
| 00026000<br />
| 00027000<br />
| 00028000<br />
| CTR-N-HAS?<br />
| [[System Settings]] (mset)<br />
| [[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]]<br />
| [[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]]<br />
| [[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]]<br />
| [[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]]<br />
| [[4.0.0-7|v1026]], [[5.0.0-11|v2049]], [[7.0.0-13|v4098]]<br />
| [[4.1.0-8|v8]], [[4.2.0-9|v1024]], [[5.0.0-11|v2050]], [[7.0.0-13|v3074]]<br />
| Active<br />
|-<br />
| 00020100<br />
| 00021100<br />
| 00022100<br />
| 00026100<br />
| 00027100<br />
| 00028100<br />
| CTR-N-HDL?<br />
| [[Download Play]] (dlplay)<br />
| [[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]])<br />
| [[1.0.0-0|v0]], [[2.1.0-4|v1026]], [[4.0.0-7|v2051]], [[9.0.0-20|v3073]]<br />
| [[1.0.0-0|v0]], [[2.1.0-4|v1026]], [[4.0.0-7|v2051]], [[9.0.0-20|v3073]]<br />
| [[4.0.0-7|v4]]<br />
| [[4.0.0-7|v1027]]<br />
| [[4.1.0-8|v4]]<br />
| Active<br />
|-<br />
| 00020200<br />
| 00021200<br />
| 00022200<br />
| 00026200<br />
| 00027200<br />
| 00028200<br />
| CTR-N-HMK?<br />
| [[Activity Log]]<br />
| [[1.0.0-0|v0]], [[2.0.0-2|v1026]], [[3.0.0-5|v2051]], [[10.6.0-31|v2080]]<br />
| [[1.0.0-0|v0]], [[2.0.0-2|v1026]], [[3.0.0-5|v2054]], [[7.0.0-13|v2064]]<br />
| Same as EUR<br />
| [[4.0.0-7|v3]]<br />
| [[4.0.0-7|v2]], [[7.0.0-13|v16]]<br />
| [[4.1.0-8|v2]]<br />
| Active<br />
|-<br />
| 00020300<br />
| 00021300<br />
| 00022300<br />
| 00026300<br />
| 00027300<br />
| 00028300<br />
| ?<br />
| [[Health and Safety Information]] (safe)<br />
| [[1.0.0-0|v0]], [[4.0.0-7|v1024]], [[6.0.0-11|v2050]]<br />
| [[1.0.0-0|v0]], [[3.0.0-5|v1024]], [[4.0.0-7|v2050]], [[6.0.0-11|v3077]]<br />
| [[1.0.0-0|v0]], [[4.0.0-7|v1026]], [[6.1.0-12U|v2051]]<br />
| [[4.0.0-7|v5]]<br />
| [[4.0.0-7|v2]]<br />
| [[4.1.0-8|v5]]<br />
| Active<br />
|-<br />
| 20020300<br />
| 20021300<br />
| 20022300<br />
| N/A<br />
| 20027300<br />
| N/A<br />
| CTR-N-HAC?<br />
| [[New_3DS]] [[Health and Safety Information]]<br />
| [[8.1.0-0_New3DS|v2]], [[9.3.0-21|v17]]<br />
| [[8.1.0-0_New3DS|v1]]<br />
| Same as EUR.<br />
| N/A<br />
| [[9.6.0-24|v2]]<br />
| N/A<br />
| Active<br />
|-<br />
| 00020400<br />
| 00021400<br />
| 00022400<br />
| 00026400<br />
| 00027400<br />
| 00028400<br />
| CTR-N-HEP?<br />
| [[Nintendo 3DS Camera]] (CtrApp)<br />
| [[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]]<br />
| [[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]]<br />
| [[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]]<br />
| [[4.0.0-7|v3]]<br />
| [[4.0.0-7|v2]], [[7.0.0-13|v1040]]<br />
| [[4.1.0-8|v3]]<br />
| Active<br />
|-<br />
| 00020500<br />
| 00021500<br />
| 00022500<br />
| 00026500<br />
| 00027500<br />
| 00028500<br />
| CTR-N-HES?<br />
| [[Nintendo 3DS Sound]] (CtrApp)<br />
| [[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]], [[11.4.0-37|v4096]]<br />
| [[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]], [[11.4.0-37|v4096]]<br />
| [[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]], [[11.4.0-37|v4096]]<br />
| [[4.0.0-7|v2]], [[11.4.0-37|v1024]]<br />
| [[4.0.0-7|v2]], [[7.0.0-13|v16]],[[11.4.0-37|v4096]]<br />
| [[4.1.0-8|v3]], [[11.4.0-37|v1024]]<br />
| Active<br />
|-<br />
| 00020700<br />
| 00021700<br />
| 00022700<br />
| 00026700<br />
| 00027700<br />
| 00028700<br />
| CTR-N-HED?<br />
| [[Mii Maker]] (EDIT)<br />
| [[1.0.0-0|v0]], [[2.0.0-2|v1026]], [[7.0.0-13|v2055]], [[10.6.0-31|v2064]]<br />
| Same as JPN<br />
| Same as JPN<br />
| [[4.0.0-7|v1]]<br />
| [[4.0.0-7|v1]], [[7.0.0-13|v16]]<br />
| [[4.1.0-8|v2]]<br />
| Active<br />
|-<br />
| 00020800<br />
| 00021800<br />
| 00022800<br />
| 00026800<br />
| 00027800<br />
| 00028800<br />
| CTR-N-HME?<br />
| [[StreetPass Mii Plaza]] (MEET)<br />
| [[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]]<br />
| [[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]]<br />
| [[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]]<br />
| [[4.0.0-7|v0]], [[4.4.0-10|v4096]]<br />
| [[4.0.0-7|v1]], [[4.4.0-10|v4096]], [[7.0.0-13|v5120]]<br />
| [[4.1.0-8|v1]], [[4.4.0-10|v4096]]<br />
| Active<br />
|-<br />
| 00020900<br />
| 00021900<br />
| 00022900<br />
| N/A<br />
| 00027900<br />
| 00028900<br />
| CTR-N-HGR?<br />
| [[eShop]] (tiger)<br />
| [[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]]<br />
| [[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]]<br />
| [[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]]<br />
| N/A<br />
| [[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]]<br />
| [[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]]<br />
| Active<br />
|-<br />
| 00020A00<br />
| 00021A00<br />
| 00022A00<br />
| N/A<br />
| 00027A00<br />
| 00028A00<br />
| CTR-N-HCB?<br />
| [[System Transfer]] (CARDBOARD)<br />
| [[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]]<br />
| [[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]]<br />
| [[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]]<br />
| N/A<br />
| [[4.0.0-7|v2]], [[5.0.0-11|v1025]], [[7.0.0-13|v2061]], [[9.0.0-20|v3082]]<br />
| [[4.1.0-8|v2]], [[5.0.0-11|v1025]], [[7.0.0-13|v2061]]<br />
| Active<br />
|-<br />
| 00020B00<br />
| 00021B00<br />
| 00022B00<br />
| N/A<br />
| N/A<br />
| N/A<br />
| CTR-N-HMA?<br />
| [[Nintendo Zone]] ("Nintendo")<br />
| [[1.0.0-0|v0]], [[3.0.0-5|v1034]]<br />
| Same as JPN<br />
| Same as JPN<br />
| N/A<br />
| N/A<br />
| N/A<br />
| Active<br />
|-<br />
| 00020D00<br />
| 00021D00<br />
| 00022D00<br />
| 00026D00<br />
| 00027D00<br />
| 00028D00<br />
| CTR-N-HCH?<br />
| [[Face Raiders]]<br />
| [[1.0.0-0|v0]], [[2.1.0-4|v1028]]<br />
| [[1.0.0-0|v0]], [[2.1.0-4|v1028]], [[7.0.0-13|v1040]]<br />
| Same as EUR<br />
| [[4.0.0-7|v0]]<br />
| [[4.0.0-7|v0]]<br />
| [[4.1.0-8|v2]]<br />
| Active<br />
|-<br />
| 20020D00<br />
| 20021D00<br />
| 20022D00<br />
| N/A<br />
| 20027D00<br />
| N/A<br />
| ?<br />
| [[New_3DS]] [[Face Raiders]]<br />
| [[8.1.0-0_New3DS|v2050]]<br />
| [[8.1.0-0_New3DS|v2049]]<br />
| Same as EUR.<br />
| N/A<br />
| [[9.6.0-24|v2049]]<br />
| N/A<br />
| Active<br />
|-<br />
| 00020E00<br />
| 00021E00<br />
| 00022E00<br />
| 00026E00<br />
| 00027E00<br />
| 00028E00<br />
| CTR-N-HAR?<br />
| [[AR Games]] (AR_ACT)<br />
| [[1.0.0-0|v0]], [[2.1.0-4|v1026]]<br />
| [[1.0.0-0|v0]], [[2.1.0-4|v1026]], [[7.0.0-13|v1040]]<br />
| [[1.0.0-0|v0]], [[2.1.0-4|v1027]], [[7.0.0-13|v1040]]<br />
| [[4.0.0-7|v0]]<br />
| [[4.0.0-7|v0]], [[7.0.0-13|v16]]<br />
| [[4.1.0-8|v1]]<br />
| Active<br />
|-<br />
| 00020F00<br />
| 00021F00<br />
| 00022F00<br />
| 00026F00<br />
| 00027F00<br />
| 00028F00<br />
| CTR-N-HSH?<br />
| SAFE_MODE [[System Settings#System Updater|System Updater]] (mset)<br />
| [[1.0.0-0|v0]], [[3.0.0-5|v1024]], [[6.0.0-11|v2049]]<br />
| [[1.0.0-0|v0]], [[3.0.0-5|v1024]], [[6.0.0-11|v2050]]<br />
| Same as JPN<br />
| [[4.0.0-7|v1]], [[6.0.0-11|v1026]]<br />
| [[4.0.0-7|v1]]<br />
| [[4.1.0-8|v1]]<br />
| Active<br />
|-<br />
| 00023000<br />
| 00024000<br />
| 00025000<br />
| N/A<br />
| N/A<br />
| N/A<br />
| (Variable?)<br />
| Promotional video<br />
| [[1.1.0-1|v2]], [[2.0.0-2|v2048]]<br />
| [[1.1.0-1|v<unknown>]], [[2.0.0-2|v2048]]<br />
| [[1.1.0-1|v0]], [[2.0.0-2|v2048]]<br />
| N/A<br />
| N/A<br />
| N/A<br />
| Stubbed<br />
|-<br />
| 0002BF00<br />
| 0002C000<br />
| 0002C100<br />
| N/A<br />
| N/A<br />
| N/A<br />
| CTR-N-HAF?<br />
| [[Nintendo Network ID Settings]] (act)<br />
| [[7.0.0-13|v14]], [[7.2.0-17|v1029]], [[9.0.0-20|v2051]], [[9.3.0-21|v3072]]<br />
| Same as JPN<br />
| Same as JPN<br />
| N/A<br />
| N/A<br />
| N/A<br />
| Active<br />
|-<br />
| 20023100<br />
| 20024100<br />
| 20025100<br />
| N/A<br />
| N/A<br />
| N/A<br />
| CTR-N-HAJ?<br />
| [[microSD Management]] ('mcopy') ([[New_3DS]]-only)<br />
| [[8.1.0-0_New3DS|v8]], [[9.0.0-20|v1024]]<br />
| [[8.1.0-0_New3DS|v4]]<br />
| [[8.1.0-0_New3DS|v5]]<br />
| N/A<br />
| N/A<br />
| N/A<br />
| Available<br />
|-<br />
| 2002C800<br />
| 2002CF00<br />
| 2002D000<br />
| N/A<br />
| 2002D700<br />
| N/A<br />
| CTR-P-CTAP<br />
| [[New_3DS]]-only, currently stubbed. "HOME menu/menu".<br />
| [[8.1.0-0_New3DS|v2]], [[9.0.0-20|v18]], [[9.3.0-21|v34]], [[9.6.0-24|v50]]<br />
| [[8.1.0-0_New3DS|v1]], [[9.3.0-21|v17]], [[9.6.0-24|v34]]<br />
| [[8.1.0-0_New3DS|v1]], [[9.3.0-21|v18]], [[9.6.0-24|v33]]<br />
| N/A<br />
| [[9.6.0-24|v2]]<br />
| N/A<br />
| Stubbed<br />
|-<br />
| 2002C900<br />
| 2002D100<br />
| 2002D200<br />
| N/A<br />
| 2002D800<br />
| N/A<br />
| CTR-P-CTAP<br />
| [[New_3DS]]-only, currently stubbed. "Friends list/friend".<br />
| [[8.1.0-0_New3DS|v1]]<br />
| Same as JPN.<br />
| [[8.1.0-0_New3DS|v0]], [[9.3.0-21|v16]]<br />
| N/A<br />
| [[9.6.0-24|v2]]<br />
| N/A<br />
| Stubbed<br />
|-<br />
| 2002CA00<br />
| 2002D300<br />
| 2002D400<br />
| N/A<br />
| 2002D900<br />
| N/A<br />
| CTR-P-CTAP<br />
| [[New_3DS]]-only, currently stubbed. "Notifications/newslist".<br />
| [[8.1.0-0_New3DS|v0]], v1([[Home_Menu|JPN-only]] Oct 2, 2014 "sysupdate", actually uploaded on 09-29-14. Identical to v0, same TMDs besides title-versions)<br />
| [[8.1.0-0_New3DS|v2]]<br />
| [[8.1.0-0_New3DS|v0]]<br />
| N/A<br />
| [[9.6.0-24|v2]]<br />
| N/A<br />
| Stubbed<br />
|-<br />
| 2002CB00<br />
| 2002D500<br />
| 2002D600<br />
| N/A<br />
| 2002DA00<br />
| N/A<br />
| CTR-P-CTAP<br />
| [[New_3DS]]-only, currently stubbed. "Game notes/cherry".<br />
| [[8.1.0-0_New3DS|v0]], [[9.0.0-20|v1]]<br />
| [[8.1.0-0_New3DS|v2]]<br />
| Same as EUR.<br />
| N/A<br />
| [[9.6.0-24|v1]]<br />
| N/A<br />
| Stubbed<br />
|}<br />
<br />
=== 0004001B - [[NCCH#CFA|System Data Archives]] ===<br />
{| class="wikitable sortable" border="1"<br />
|-<br />
! TitleID Low<br />
! Description<br />
! Versions<br />
|-<br />
| 00010002<br />
| [[ClCertA]]<br />
| [[1.0.0-0|v0]]<br />
|-<br />
| 00010702<br />
| [[NS CFA]]<br />
| [[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]])<br />
|-<br />
| 00010802<br />
| This CFA only contains a 1-byte "dummy.txt" in the RomFS, which contains '0'.<br />
| [[6.3.0-12|v0]], [[9.5.0-23|v1024]], [[10.5.0-30|v2048]], [[11.0.0-33|v3072]]<br />
|-<br />
| 00018002<br />
| Same contents as 00010802. Starting with [[7.1.0-15]], the "dummy.txt" file was removed from RomFS: this CFA RomFS now contains web-browser data(similar to 00018102) for NNID / networking, etc.<br />
| [[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]]<br />
|-<br />
| 00018102<br />
| This contains local web-browser data(html/js, gfx, etc) for the Miiverse Offline-mode.<br />
| [[7.0.0-13|v11]], [[9.0.0-20|v1025]](also for [[8.1.0-0_New3DS]])<br />
|-<br />
| 00018202<br />
| This contains the webkit/OSS [[CRO0|CROs]] used with the Miiverse applet and the "act" application.<br />
| [[7.0.0-13|v7]], [[8.1.0-0_New3DS|v1026]]([[8.1.0-0_New3DS]]), [[9.0.0-20|v2050]]<br />
|-<br />
| 00019002<br />
| [[Fangate_updater]]<br />
| [[9.3.0-21|v2]], [[9.6.0-24|v1026]]<br />
|}<br />
<br />
=== 00040030 - System Applets===<br />
==== System Applet Notes ====<br />
Most of these processes are applets, see [[NS_and_APT_Services|here]] for details.<br />
All of the below processes use the "SYSTEM" [[SVC|memory-region]].<br />
The ExeFS for Home Menu is exactly the same for USA/EUR/JPN.<br />
The Miiverse applet seems to use a web browser with webkit.<br />
<br />
{| class="wikitable sortable" border="1"<br />
|-<br />
! JPN TitleIDLow<br />
! USA TitleIDLow<br />
! EUR TitleIDLow<br />
! CHN TitleIDLow<br />
! KOR TitleIDLow<br />
! TWN TitleIDLow<br />
! [[Product code]]<br />
! Description<br />
! JPN Versions<br />
! USA Versions<br />
! EUR Versions<br />
|-<br />
|colspan=6 align=center| 00008102<br />
| CTR-P-CTAP<br />
| [[NS#Alternate menu|Test Menu]] (Demo1)<br />
|colspan=3 align=center| ..., v64, ..., v27648<br />
|-<br />
| 00008202<br />
| 00008F02<br />
| 00009802<br />
| 0000A102<br />
| 0000A902<br />
| 0000B102<br />
| CTR-P-HMM?<br />
| [[Home Menu]] (menu)<br />
| [[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]]<br />
| [[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]]<br />
| [[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]]<br />
|-<br />
| 00008402<br />
| 00009002<br />
| 00009902<br />
| 0000A202<br />
| 0000AA02<br />
| 0000B202<br />
| CTR-N-HCS?<br />
| Camera applet used by Home-menu (CtrApp)<br />
|colspan=3| v0, v1036, [[9.0.0-20|v2049]](Also for [[8.1.0-0_New3DS]])<br />
|-<br />
| 00008502<br />
| 00009102<br />
| 00009A02<br />
| ?<br />
| ?<br />
| ?<br />
| ?<br />
| Not available on CDN<br />
| ?<br />
| ?<br />
| ?<br />
|-<br />
| 00008602<br />
| 00009202<br />
| 00009B02<br />
| 0000A402<br />
| 0000AC02<br />
| 0000B402<br />
| CTR-N-HMV?<br />
| Instruction Manual, applet for displaying instruction manuals<br />
|colspan=3| v0, v1026, v2048, v3072, [[5.0.0-11|v4097]], [[9.0.0-20|v5120]](Also for [[8.1.0-0_New3DS]])<br />
|-<br />
| 00008702<br />
| 00009302<br />
| 00009C02<br />
| 0000A502<br />
| 0000AD02<br />
| 0000B502<br />
| CTR-N-HGM?<br />
| Game Notes (Cherry)<br />
|colspan=3| v0, v1026, v2049, [[5.0.0-11|v3073]], [[9.0.0-20|v4096]](Also for [[8.1.0-0_New3DS]])<br />
|-<br />
| 00008802<br />
| 00009402<br />
| 00009D02<br />
| 0000A602<br />
| 0000AE02<br />
| 0000B602<br />
| <br />
| [[Internet Browser]] (spider)<br />
|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]]<br />
|-<br />
| 20008802<br />
| 20009402<br />
| 20009D02<br />
| ?<br />
| 2000AE02<br />
| N/A<br />
| CTR-N-HBR?<br />
| [[New 3DS]] [[Internet Browser]] (SKATER)<br />
|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]]<br />
|-<br />
|colspan=6| 00008A02<br />
| <br />
| Fatal error viewer ([[ErrDisp]])<br />
|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]])<br />
|-<br />
|colspan=6| 00008A03<br />
| <br />
| SAFE_MODE [[ErrDisp]]<br />
|colspan=3| v0<br />
|-<br />
| 20008A03<br />
| 20008A03<br />
| 20008A03<br />
| ?<br />
| 20008A03<br />
| N/A<br />
| <br />
| [[New_3DS]] SAFE_MODE [[ErrDisp]]<br />
|colspan=3| [[8.1.0-0_New3DS|v7169]]<br />
|-<br />
| 00008D02<br />
| 00009602<br />
| 00009F02<br />
| 0000A702<br />
| 0000AF02<br />
| 0000B702<br />
| CTR-N-HFR?<br />
| Friend List (friend)<br />
|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]])<br />
|-<br />
| 00008E02<br />
| 00009702<br />
| 0000A002<br />
| 0000A802<br />
| 0000B002<br />
| 0000B802<br />
| CTR-N-HCR?<br />
| Notifications (newslist)<br />
|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]])<br />
|-<br />
| 0000C002<br />
| 0000C802<br />
| 0000D002<br />
| 0000D802<br />
| 0000DE02<br />
| 0000E402<br />
| CTR-N-HKY?<br />
| Software Keyboard (swkbd)<br />
|colspan=3| v0, v1026, v2053, [[7.0.0-13|v3072]], [[9.0.0-20|v4096]](Also for [[8.1.0-0_New3DS]])<br />
|-<br />
| 0000C003<br />
| 0000C803<br />
| 0000D003<br />
| 0000D803<br />
| 0000DE03<br />
| 0000E403<br />
| <br />
| SAFE_MODE Software Keyboard (swkbd)<br />
|colspan=3| v0<br />
|-<br />
| 2000C003<br />
| 2000C803<br />
| 2000D003<br />
| ?<br />
| 2000DE03<br />
| N/A<br />
| <br />
| [[New 3DS]] SAFE_MODE Software Keyboard (swkbd)<br />
| [[8.1.0-0_New3DS|v1024]]<br />
|colspan=2|[[9.0.0-20|v0]]<br />
|-<br />
| 0000C102<br />
| 0000C902<br />
| 0000D102<br />
| 0000D902<br />
| 0000DF02<br />
| 0000E502<br />
| <br />
| Mii picker (appletEd)<br />
|colspan=3| v0, v1026, [[9.0.0-20|v2048]](Also for [[8.1.0-0_New3DS]]), [[9.3.0-21|v3077]]<br />
|-<br />
| 0000C302<br />
| 0000CB02<br />
| 0000D302<br />
| 0000DB02<br />
| 0000E102<br />
| 0000E702<br />
| <br />
| Picture picker (PNOTE_AP)<br />
|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]]<br />
|-<br />
| 0000C402<br />
| 0000CC02<br />
| 0000D402<br />
| 0000DC02<br />
| 0000E202<br />
| 0000E802<br />
| <br />
| [[Nintendo 3DS Sound|Voice memo]] picker (SNOTE_AP)<br />
|colspan=3| v0, v3, [[8.0.0-18|v1026]], [[9.0.0-20|v2048]](Also for [[8.1.0-0_New3DS]])<br />
|-<br />
|colspan=3| 0000C502<br />
|colspan=3| 0000CF02<br />
| <br />
| Non-critical (online, etc) error display (error)<br />
|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]]<br />
|-<br />
|colspan=3| 0000C503<br />
|colspan=3| 0000CF03<br />
| <br />
| SAFE_MODE error applet<br />
|colspan=3| v0<br />
|-<br />
| 2000C503<br />
| 2000C503<br />
| 2000C503<br />
| ?<br />
| 2000CF03<br />
| N/A<br />
| <br />
| [[New 3DS]] SAFE_MODE error applet<br />
|colspan=3| [[8.1.0-0_New3DS|v1024]]<br />
|-<br />
|colspan=3| 0000CD02<br />
|colspan=3| 0000D502<br />
| <br />
| [[Circle Pad Pro]] test/calibration applet (extrapad)<br />
|colspan=3| v1, v1026, [[8.1.0-0_New3DS|v2048]]([[8.1.0-0_New3DS]]), [[9.0.0-20|v3073]]<br />
|-<br />
| 0000C602<br />
| 0000CE02<br />
| 0000D602<br />
| N/A<br />
| 0000E302<br />
| 0000E902<br />
| CTR-N-HAA?<br />
| eShop applet, used by applications for accessing the eShop, for DLC/etc. Also used by the eShop application itself. (mint)<br />
|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]]<br />
|-<br />
| 0000BC02<br />
| 0000BD02<br />
| 0000BE02<br />
| ?<br />
| ?<br />
| ?<br />
| CTR-N-HAE?<br />
| Miiverse (olv)<br />
|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]]<br />
|-<br />
| 0000F602<br />
| 0000F602<br />
| 0000F602<br />
| ?<br />
| ?<br />
| ?<br />
| <br />
| Likely the "system library" for Miiverse (memolib)<br />
|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]]<br />
|-<br />
| 00008302<br />
| 00008B02<br />
| 0000BA02<br />
| ?<br />
| ?<br />
| ?<br />
| CTR-N-HAH?<br />
| In-app Miiverse-posting applet (solv3)<br />
|colspan=3| [[9.0.0-20|v6]]<br />
|-<br />
| 00009502<br />
| 00009E02<br />
| 0000B902<br />
| ?<br />
| 00008C02<br />
| 0000BF02<br />
| CTR-N-HA3?<br />
| Cabinet ([[amiibo Settings]])<br />
|colspan=3| [[9.3.0-21|v7]], (v1024 for TWN), [[9.6.0-24|v1031]]<br />
|}<br />
<br />
=== 0004009B - [[NCCH#CFA|Shared Data Archives]] ===<br />
{| class="wikitable sortable" border="1"<br />
|-<br />
! JPN TitleIDLow<br />
! USA TitleIDLow<br />
! EUR TitleIDLow<br />
! CHN TitleIDLow<br />
! KOR TitleIDLow<br />
! TWN TitleIDLow<br />
! Description<br />
! Versions<br />
|-<br />
| 00010202<br />
| 00010202<br />
| 00010202<br />
| 00010202<br />
| 00010202<br />
| 00010202<br />
| Probably Mii-related, contains "CFL_Res.dat" in the RomFS.<br />
| v0<br />
|-<br />
| 00010402<br />
| 00010402<br />
| 00010402<br />
| 00010402<br />
| 00010402<br />
| 00010402<br />
| Region Manifest. Mounted as "area:"<br />
| v0, v1024, v2050, v3072, [[7.0.0-13|v4098]], [[9.6.0-24|v5122]]<br />
|-<br />
| 00010602<br />
| 00010602<br />
| 00010602<br />
| 00010602<br />
| 00010602<br />
| 00010602<br />
| Non-Nintendo TLS Root-CA Certificates (RomFS contains files with filename "CACERT_PUBLIC_CA_<val>.der", where <val> is 5..8)<br />
| v2, [[10.5.0-30|v1024]]<br />
|-<br />
|<br />
|<br />
|<br />
| 00011002<br />
| <br />
| <br />
| "CHN/CN" Dictionary.<br />
| v1<br />
|-<br />
| <br />
| <br />
|<br />
|<br />
|<br />
| 00011102 <br />
| "TWN/TN" dictionary.<br />
| v1<br />
|-<br />
| <br />
| <br />
| 00011202<br />
|<br />
|<br />
| <br />
| "NL/NL" dictionary.<br />
| v0<br />
|-<br />
| <br />
| <br />
| 00011302<br />
|<br />
|<br />
| <br />
| "EN/GB" dictionary.<br />
| v0<br />
|-<br />
| <br />
| 00011402<br />
|<br />
| <br />
| <br />
|<br />
| "EN/US" dictionary.<br />
| v0<br />
|-<br />
| <br />
| <br />
| 00011502<br />
|<br />
|<br />
| <br />
| "FR/FR/regular" dictionary.<br />
| v0<br />
|-<br />
| <br />
| 00011602<br />
|<br />
|<br />
| <br />
| <br />
| "FR/CA/regular" dictionary.<br />
| v0<br />
|-<br />
| <br />
| <br />
| 00011702<br />
|<br />
| <br />
| <br />
| "DE/regular" dictionary.<br />
| v0<br />
|-<br />
| <br />
| <br />
| 00011802<br />
|<br />
| <br />
| <br />
| "IT/IT" dictionary.<br />
| v0<br />
|-<br />
| 00011902<br />
| <br />
|<br />
| <br />
|<br />
| <br />
| "JA_small/32" dictionary.<br />
| v0<br />
|-<br />
| <br />
| <br />
|<br />
|<br />
| 00011A02<br />
| <br />
| "KO/KO" dictionary.<br />
| v1<br />
|-<br />
| <br />
| <br />
| 00011B02<br />
|<br />
|<br />
| <br />
| "PT/PT/regular" dictionary.<br />
| v0<br />
|-<br />
| <br />
| <br />
| 00011C02<br />
|<br />
|<br />
| <br />
| "RU/regular" dictionary.<br />
| v0<br />
|-<br />
| <br />
| 00011D02<br />
| 00011D02<br />
|<br />
|<br />
| <br />
| "ES/ES" dictionary.<br />
| v0<br />
|-<br />
| <br />
| 00011E02<br />
|<br />
| <br />
|<br />
| <br />
| "PT/BR/regular" dictionary.<br />
| v0<br />
|-<br />
| 00012202<br />
| 00012302<br />
| 00012102<br />
| 00012402<br />
| 00012502<br />
| 00012602<br />
| ?contains a lists with error strings<br />
| 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]])<br />
|-<br />
| 00013202<br />
| 00013302<br />
| 00013102<br />
| 00013502<br />
| <br />
| <br />
| Mounted as "eula:"<br />
| 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]])<br />
|-<br />
| 00014002<br />
| 00014002<br />
| 00014002<br />
| 00014002<br />
| 00014002<br />
| 00014002<br />
| JPN/EUR/USA [[System Font]] ("font:")<br />
| v0<br />
|-<br />
| 00014102<br />
| 00014102<br />
| 00014102<br />
| 00014102<br />
| 00014102<br />
| 00014102<br />
| CHN [[System Font]] ("font:")<br />
| v0, v1024<br />
|-<br />
| 00014202<br />
| 00014202<br />
| 00014202<br />
| 00014202<br />
| 00014202<br />
| 00014202<br />
| KOR [[System Font]] ("font:")<br />
| v0, v1024<br />
|-<br />
| 00014302<br />
| 00014302<br />
| 00014302<br />
| 00014302<br />
| 00014302<br />
| 00014302<br />
| TWN [[System Font]] ("font:")<br />
| v0, v1024<br />
|-<br />
| 00015202<br />
| 00015302<br />
| 00015102<br />
| N/A<br />
| 00015502<br />
| 0015602<br />
| Mounted as "rate:"<br />
| v0 (EUR: v0, v1024) (KOR: v1024)<br />
|}<br />
<br />
=== 000400DB - [[NCCH#CFA|System Data Archives]] ===<br />
==== System Data Archive Notes ====<br />
These [[NVer]] titleIDs can be found @ offset 0x320 in every [[CCI]].<br />
<br />
{| class="wikitable sortable" border="1"<br />
|-<br />
! EUR TitleIDLow<br />
! JPN TitleIDLow<br />
! USA TitleIDLow<br />
! CHN TitleIDLow<br />
! KOR TitleIDLow<br />
! TWN TitleIDLow<br />
! Description<br />
! USA/EUR/JPN Versions<br />
! CHN Versions<br />
! TWN Versions<br />
! KOR Versions<br />
|-<br />
| 00010302<br />
| 00010302<br />
| 00010302<br />
| 00010302<br />
| 00010302<br />
| 00010302<br />
| NGWord bad word list<br />
| [[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]]<br />
| Same as USA<br />
| Same as USA<br />
| Same as USA<br />
|-<br />
| 00010502<br />
| 00010502<br />
| 00010502<br />
| 00010502<br />
| 00010502<br />
| 00010502<br />
| [[Nintendo Zone]] hotspot list<br />
| [[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]]<br />
| Same as USA<br />
| Same as USA<br />
| Same as USA<br />
|-<br />
| 00016102<br />
| 00016202<br />
| 00016302<br />
| 00016402<br />
| 00016502<br />
| 00016602<br />
| [[NVer]]<br />
| [[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]]<br />
| [[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]]<br />
| [[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]]<br />
| [[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]]<br />
|-<br />
| 20016102<br />
| 20016202<br />
| 20016302<br />
| N/A<br />
| 20016502<br />
| N/A<br />
| [[New_3DS]] [[NVer]]<br />
| [[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]]<br />
| N/A<br />
| N/A<br />
| [[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]]<br />
|-<br />
| 00017102<br />
| 00017202<br />
| 00017302<br />
| 00017402<br />
| 00017502<br />
| 00017602<br />
| [[CVer]]<br />
| [[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]]<br />
| [[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]]<br />
| Same as CHN<br />
| Same as CHN + [[11.1.0-34|v11280]]<br />
|}<br />
<br />
=== 00040130 - System [[Services API|Modules]] ===<br />
==== System Module Notes ====<br />
Once Home Menu finishes loading, all of the below system modules are running, except for MP, RO, and act which are automatically [[Process_Manager_Services|loaded]] when a process requires them. <br />
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. <br />
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.<br />
All of the below system modules use the "BASE" [[SVC|memory-region]](specified in the exheader), except when listed otherwise for certain modules.<br />
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). <br />
The exheader dependency list handling change is for the [[New 3DS]] system-module(s), which do not exist on Old3DS. <br />
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.<br />
<br />
{| class="wikitable sortable" border="1"<br />
|-<br />
! TitleID Low<br />
! Description<br />
! Versions<br />
|-<br />
| 00001002<br />
| [[Services|sm]] (Stored in [[FIRM|NATIVE_FIRM]])<br />
| N/A<br />
|-<br />
| 00001003<br />
| SAFE_MODE [[Services|sm]] (Stored in SAFE_MODE NATIVE_FIRM)<br />
| N/A<br />
|-<br />
| 00001102<br />
| [[Filesystem services‎|fs]] (Stored in [[FIRM|NATIVE_FIRM]])<br />
| N/A<br />
|-<br />
| 00001103<br />
| SAFE_MODE [[Filesystem services‎|fs]] (Stored in SAFE_MODE NATIVE_FIRM)<br />
| N/A<br />
|-<br />
| 00001202<br />
| [[Process Manager Services|pm]] (Stored in [[FIRM|NATIVE_FIRM]])<br />
| N/A<br />
|-<br />
| 00001203<br />
| SAFE_MODE [[Process Manager Services|pm]] (Stored in SAFE_MODE NATIVE_FIRM)<br />
| N/A<br />
|-<br />
| 00001302<br />
| [[Loader Services‎|loader]] (Stored in [[FIRM|NATIVE_FIRM]])<br />
| N/A<br />
|-<br />
| 00001303<br />
| SAFE_MODE [[Loader Services‎|loader]] (Stored in SAFE_MODE NATIVE_FIRM)<br />
| N/A<br />
|-<br />
| 00001402<br />
| [[PXI Services‎|pxi]] (Stored in [[FIRM|NATIVE_FIRM]])<br />
| N/A<br />
|-<br />
| 00001403<br />
| SAFE_MODE [[PXI Services‎|pxi]] (Stored in SAFE_MODE NATIVE_FIRM)<br />
| N/A<br />
|-<br />
| 00001502<br />
| [[Application Manager Services|AM]] ( Application Manager )<br />
| [[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]]<br />
|-<br />
| 00001503<br />
| SAFE_MODE [[Application Manager Services|AM]]<br />
| [[1.0.0-0|v0]]<br />
|-<br />
| 20001503<br />
| [[New_3DS]] SAFE_MODE [[Application Manager Services|AM]]<br />
| [[8.1.0-0_New3DS|v7169]]<br />
|-<br />
| 00001602<br />
| [[Camera Services|Camera]]<br />
| [[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]]<br />
|-<br />
| 20001602<br />
| [[New_3DS]] [[Camera Services|Camera]]<br />
| [[8.1.0-0_New3DS|v8200]], [[9.0.0-20|v9218]], [[9.3.0-21|v10242]], [[10.0.0-27|v11265]]<br />
|-<br />
| 00001702<br />
| [[Config Services|Config]] (cfg)<br />
| [[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]]<br />
|-<br />
| 00001703<br />
| SAFE_MODE [[Config Services|Config]] (cfg)<br />
| [[1.0.0-0|v0]]<br />
|-<br />
| 20001703<br />
| [[New_3DS]] SAFE_MODE [[Config Services|Config]] (cfg)<br />
| [[8.1.0-0_New3DS|v11265]]<br />
|-<br />
| 00001802<br />
| [[Codec Services|Codec]]<br />
| [[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]])<br />
|-<br />
| 00001803<br />
| SAFE_MODE [[Codec Services|Codec]]<br />
| [[1.0.0-0|v0]]<br />
|-<br />
| 20001803<br />
| [[New_3DS]] SAFE_MODE [[Codec Services|Codec]]<br />
| [[8.1.0-0_New3DS|v7169]]<br />
|-<br />
| 00001A02<br />
| [[DSP Services|DSP]]<br />
| [[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]]<br />
|-<br />
| 00001A03<br />
| SAFE_MODE [[DSP Services|DSP]]<br />
| [[1.0.0-0|v0]]<br />
|-<br />
| 20001A03<br />
| [[New_3DS]] SAFE_MODE [[DSP Services|DSP]]<br />
| [[8.1.0-0_New3DS|v6145]]<br />
|-<br />
| 00001B02<br />
| [[GPIO Services|GPIO]]<br />
| [[1.0.0-0|v0]], [[5.0.0-11|v1025]], [[8.0.0-18|v2048]], [[9.5.0-22|v3073]]<br />
|-<br />
| 00001B03<br />
| SAFE_MODE [[GPIO Services|GPIO]]<br />
| [[1.0.0-0|v0]]<br />
|-<br />
| 20001B03<br />
| [[New_3DS]] SAFE_MODE [[GPIO Services|GPIO]]<br />
| [[8.1.0-0_New3DS|v3073]]<br />
|-<br />
| 00001C02<br />
| [[GSP Services|GSP]]<br />
| [[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]]<br />
|-<br />
| 20001C02<br />
| [[New_3DS]] [[GSP Services|GSP]]<br />
| [[8.1.0-0_New3DS|v10243]], [[9.3.0-21|v11267]], [[9.6.0-24|v12294]], [[11.3.0-36|v13312]]<br />
|-<br />
| 00001C03<br />
| SAFE_MODE [[GSP Services|GSP]]<br />
| [[1.0.0-0|v0]]<br />
|-<br />
| 20001C03<br />
| [[New_3DS]] SAFE_MODE [[GSP Services|GSP]]<br />
| [[8.1.0-0_New3DS|v9217]]<br />
|-<br />
| 00001D02<br />
| [[HID Services|HID]] (Human Interface Devices) <br />
| [[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]]<br />
|-<br />
| 00001D03<br />
| SAFE_MODE [[HID Services|HID]]<br />
| [[1.0.0-0|v0]]<br />
|-<br />
| 20001D03<br />
| [[New_3DS]] SAFE_MODE [[HID Services|HID]]<br />
| [[8.1.0-0_New3DS|v8193]]<br />
|-<br />
| 00001E02<br />
| [[I2C Services|i2c]]<br />
| [[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]]<br />
|-<br />
| 20001E02<br />
| [[New_3DS]] [[I2C Services|i2c]]<br />
| [[8.1.0-0_New3DS|v4096]], [[9.3.0-21|v5121]]<br />
|- <br />
| 00001E03<br />
| SAFE_MODE [[I2C Services|i2c]]<br />
| [[1.0.0-0|v0]]<br />
|- <br />
| 20001E03<br />
| [[New_3DS]] SAFE_MODE [[I2C Services|i2c]]<br />
| [[8.1.0-0_New3DS|v4097]]<br />
|-<br />
| 00001F02<br />
| [[MCU Services|MCU]]<br />
| [[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]]<br />
|-<br />
| 20001F02<br />
| [[New_3DS]] [[MCU Services|MCU]]<br />
| [[8.1.0-0_New3DS|v8192]]<br />
|-<br />
| 00001F03<br />
| SAFE_MODE [[MCU Services|MCU]]<br />
| [[1.0.0-0|v0]]<br />
|-<br />
| 20001F03<br />
| [[New_3DS]] SAFE_MODE [[MCU Services|MCU]]<br />
| [[8.1.0-0_New3DS|v9217]]<br />
|-<br />
| 00002002<br />
| [[MIC Services|MIC]] (Microphone)<br />
| [[1.0.0-0|v0]], [[5.0.0-11|v1025]], [[8.0.0-18|v2048]]<br />
|-<br />
| 00002102<br />
| [[PDN Services|PDN]]<br />
| [[1.0.0-0|v0]], [[5.0.0-11|v1025]], [[8.0.0-18|v2048]]<br />
|-<br />
| 00002103<br />
| SAFE_MODE [[PDN Services|PDN]]<br />
| [[1.0.0-0|v0]]<br />
|-<br />
| 20002103<br />
| [[New_3DS]] SAFE_MODE [[PDN Services|PDN]]<br />
| [[8.1.0-0_New3DS|v3073]]<br />
|-<br />
| 00002202<br />
| [[PTM Services|PTM]] (Play time, pedometer, and battery manager)<br />
| [[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]]<br />
|-<br />
| 20002202<br />
| [[New_3DS]] [[PTM Services|PTM]] (Play time, pedometer, and battery manager)<br />
| [[8.1.0-0_New3DS|v10240]], [[9.6.0-24|v11264]]<br />
|-<br />
| 00002203<br />
| SAFE_MODE [[PTM Services|PTM]]<br />
| [[1.0.0-0|v0]]<br />
|-<br />
| 20002203<br />
| [[New_3DS]] SAFE_MODE [[PTM Services|PTM]]<br />
| [[8.1.0-0_New3DS|v10241]]<br />
|-<br />
| 00002302<br />
| [[SPI Services|spi]]<br />
| [[1.0.0-0|v0]], [[2.0.0-2|v1025]], [[5.0.0-11|v2049]], [[8.0.0-18|v3072]]<br />
|-<br />
| 20002302<br />
| [[New_3DS]] [[SPI Services|spi]]<br />
| [[8.1.0-0_New3DS|v4096]]<br />
|-<br />
| 00002303<br />
| SAFE_MODE [[SPI Services|spi]]<br />
| [[1.0.0-0|v0]]<br />
|-<br />
| 20002303<br />
| [[New_3DS]] SAFE_MODE [[SPI Services|spi]]<br />
| [[8.1.0-0_New3DS|v4097]]<br />
|-<br />
| 00002402<br />
| [[AC Services|AC]] (Network manager)<br />
| [[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]]<br />
|-<br />
| 00002403<br />
| SAFE_MODE [[AC Services|AC]]<br />
| [[1.0.0-0|v0]]<br />
|-<br />
| 20002403<br />
| [[New_3DS]] SAFE_MODE [[AC Services|AC]]<br />
| [[8.1.0-0_New3DS|v8193]]<br />
|-<br />
| 00002602<br />
| [[CECD Services|Cecd]] (StreetPass)<br />
| [[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]]<br />
|-<br />
| 00002702<br />
| [[CSND Services|CSND]]<br />
| [[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]]<br />
|-<br />
| 00002703<br />
| SAFE_MODE [[CSND Services|CSND]]<br />
| [[1.0.0-0|v0]]<br />
|-<br />
| 20002703<br />
| [[New_3DS]] SAFE_MODE [[CSND Services|CSND]]<br />
| [[8.1.0-0_New3DS|v5121]]<br />
|-<br />
| 00002802<br />
| [[DLP Services|DLP]] ([[Download Play]])<br />
| [[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]]<br />
|-<br />
| 00002902<br />
| [[HTTP Services|HTTP]]<br />
| [[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]]<br />
|-<br />
| 00002903<br />
| SAFE_MODE [[HTTP Services|HTTP]]<br />
| [[1.0.0-0|v0]]<br />
|-<br />
| 20002903<br />
| [[New_3DS]] SAFE_MODE [[HTTP Services|HTTP]]<br />
| [[8.1.0-0_New3DS|v10241]]<br />
|-<br />
| 00002A02<br />
| [[MP Services|MP]]<br />
| [[1.0.0-0|v0]], [[5.0.0-11|v1025]], [[8.0.0-18|v2048]]<br />
|-<br />
| 00002A03<br />
| SAFE_MODE [[MP Services|MP]]<br />
| [[1.0.0-0|v0]]<br />
|-<br />
| 00002B02<br />
| [[NDM Services|NDM]]<br />
| [[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]]<br />
|-<br />
| 00002C02<br />
| [[NIM Services|NIM]]<br />
| [[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]]<br />
|-<br />
| 00002C03<br />
| SAFE_MODE [[NIM Services|NIM]]<br />
| [[1.0.0-0|v0]]<br />
|-<br />
| 20002C03<br />
| [[New_3DS]] SAFE_MODE [[NIM Services|NIM]]<br />
| [[8.1.0-0_New3DS|v9217]]<br />
|-<br />
| 00002D02<br />
| [[NWM Services|NWM]] ( Low-level wifi manager )<br />
| [[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]]<br />
|-<br />
| 00002D03<br />
| SAFE_MODE [[NWM Services|NWM]]<br />
| [[1.0.0-0|v0]], [[6.0.0-11|v5120]]<br />
|-<br />
| 20002D03<br />
| [[New_3DS]] SAFE_MODE [[NWM Services|NWM]]<br />
| [[8.1.0-0_New3DS|v10241]]<br />
|-<br />
| 00002E02<br />
| [[Socket Services|Sockets]]<br />
| [[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]]<br />
|-<br />
| 00002E03<br />
| SAFE_MODE [[Socket Services|Sockets]]<br />
| [[1.0.0-0|v0]]<br />
|-<br />
| 20002E03<br />
| [[New_3DS]] SAFE_MODE [[Socket Services|Sockets]]<br />
| [[8.1.0-0_New3DS|v7169]]<br />
|-<br />
| 00002F02<br />
| [[SSL Services|SSL]]<br />
| [[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]]<br />
|-<br />
| 00002F03<br />
| SAFE_MODE [[SSL Services|SSL]]<br />
| [[1.0.0-0|v0]]<br />
|-<br />
| 20002F03<br />
| [[New_3DS]] SAFE_MODE [[SSL Services|SSL]]<br />
| [[8.1.0-0_New3DS|v7169]]<br />
|-<br />
| 00003000<br />
| [[FIRM|Process9]] (in SAFE_MODE and normal NATIVE_FIRM)<br />
| <br />
|-<br />
| 00003102<br />
| [[Process Services‎|PS]] ( Process Manager )<br />
| [[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]]<br />
|-<br />
| 00003103<br />
| SAFE_MODE [[Process Services‎|PS]]<br />
| [[1.0.0-0|v0]]<br />
|-<br />
| 20003103<br />
| [[New_3DS]] SAFE_MODE [[Process Services‎|PS]]<br />
| [[8.1.0-0_New3DS|v5121]]<br />
|-<br />
| 00003202<br />
| [[Friend Services‎|friends]] (Friends list)<br />
| [[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]], [[11.4.0-37|v15360]]<br />
|-<br />
| 00003203<br />
| SAFE_MODE [[Friend Services‎|friends]] (Friends list)<br />
| [[1.0.0-0|v0]]<br />
|-<br />
| 20003203<br />
| [[New_3DS]] SAFE_MODE [[Friend Services‎|friends]] (Friends list)<br />
| [[8.1.0-0_New3DS|v8193]]<br />
|-<br />
| 00003302<br />
| [[IR Services‎|IR]] (Infrared)<br />
| [[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]]<br />
|-<br />
| 00003303<br />
| SAFE_MODE [[IR Services‎|IR]]<br />
| [[1.0.0-0|v0]]<br />
|-<br />
| 20003303<br />
| [[New_3DS]] SAFE_MODE [[IR Services‎|IR]]<br />
| [[8.1.0-0_New3DS|v7169]]<br />
|- <br />
| 00003402<br />
| [[BOSS Services‎|BOSS]] (SpotPass)<br />
| [[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]]<br />
|-<br />
| 00003502<br />
| [[News Services‎|News]] (Notifications)<br />
| [[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]]<br />
|-<br />
| 00003702<br />
| [[RO_Services|RO]]<br />
| [[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]]<br />
|-<br />
| 00003802<br />
| [[ACT Services‎|act]] (handles Nintendo Network '''a'''c'''c'''oun'''t'''s)<br />
| [[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]]<br />
|-<br />
| 00004002<br />
| Old3DS [[NFC_Services|nfc]]<br />
| [[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]]<br />
|-<br />
| 20004002<br />
| [[New_3DS]] [[NFC_Services|nfc]]<br />
| [[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]]<br />
|-<br />
| 20004102<br />
| [[New_3DS]] [[MVD Services|mvd]]<br />
| [[8.1.0-0_New3DS|v0]], [[9.0.0-20|v1024]]<br />
|-<br />
| 20004202<br />
| [[New_3DS]] [[QTM Services|qtm]]<br />
| [[8.1.0-0_New3DS|v8]], [[9.0.0-20|v1024]], [[9.3.0-21|v2052]]<br />
|-<br />
| 00008002<br />
| [[NS]] (Memory-region: "SYSTEM")<br />
| [[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]]<br />
|-<br />
| 00008003<br />
| SAFE_MODE [[NS]] (Memory-region: "SYSTEM")<br />
| [[1.0.0-0|v0]]<br />
|-<br />
| 20008003<br />
| [[New_3DS]] SAFE_MODE [[NS]] (Memory-region: "SYSTEM")<br />
| [[8.1.0-0_New3DS|v13313]]<br />
|}<br />
<br />
=== 00040138 - [[FIRM|System Firmware]] ===<br />
==== System Firmare Notes ====<br />
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/<TID>/data use a custom format, this is handled by AGB_FIRM.<br />
<br />
{| class="wikitable sortable" border="1"<br />
|-<br />
! TitleID Low<br />
! Description<br />
! USA/EUR/JPN Versions<br />
! CHN Versions<br />
! KOR Versions<br />
! TWN Versions<br />
|-<br />
| 00000001<br />
| Unknown, very similar to SAFE_MODE_FIRM. Exists only on dev units and seems to only be used by SystemUpdaters.<br />
| v0<br />
| <br />
| <br />
| <br />
|-<br />
| 00000002<br />
| NATIVE_FIRM (Native Firmware)<br />
| [[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]]<br />
| Same as USA/EUR/JPN starting with the USA/EUR/JPN [[4.0.0-7]] title-version<br />
| Same as CHN.<br />
| Same as CHN.<br />
|-<br />
| 20000002<br />
| [[New_3DS]] NATIVE_FIRM (Native Firmware)<br />
| [[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]]<br />
| N/A<br />
| Same as CHN.<br />
| Same as CHN.<br />
|-<br />
| 00000003<br />
| SAFE_MODE_FIRM <br />
| [[1.0.0-0|v432]], [[3.0.0-5|v5632]]<br />
| Same as USA/EUR/JPN starting with the USA/EUR/JPN [[3.0.0-5]] title-version<br />
| Same as CHN.<br />
| Same as CHN.<br />
|-<br />
| 20000003<br />
| [[New_3DS]] SAFE_MODE_FIRM <br />
| [[8.1.0-0_New3DS|v16081]]<br />
| N/A<br />
| Same as CHN.<br />
| Same as CHN.<br />
|-<br />
| 00000102 <br />
| TWL_FIRM ( DSi Firmware )<br />
| [[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]]<br />
| Same as USA/EUR/JPN starting with the USA/EUR/JPN [[4.0.0-7]] title-version<br />
| Same as CHN.<br />
| Same as CHN.<br />
|-<br />
| 20000102 <br />
| [[New_3DS]] TWL_FIRM ( DSi Firmware )<br />
| [[8.1.0-0_New3DS|v9936]]<br />
| N/A<br />
| Same as CHN.<br />
| Same as CHN.<br />
|- <br />
| 00000202<br />
| AGB_FIRM ( GBA Firmware )<br />
| [[3.0.0-5|v519]], v1553, [[4.0.0-7|v2576]], [[6.0.0-11|v3665]]<br />
| [[4.0.0-7|v2576]]<br />
| [[4.0.0-7|v2576]], [[6.0.0-11|v3665]]<br />
| Same as CHN.<br />
|- <br />
| 20000202<br />
| [[New_3DS]] AGB_FIRM ( GBA Firmware )<br />
| [[8.1.0-0_New3DS|v4816]]<br />
| N/A<br />
| N/A<br />
| N/A<br />
|}<br />
<br />
== Application Titles ==<br />
{| class="wikitable sortable" border="1"<br />
|-<br />
! Category Bit Mask<br />
! Content Category<br />
! Bit Mask(s)<br />
|-<br />
| 0x0000<br />
| [[Title list/eShop Titles|Application / eShop]]<br />
| Normal<br />
|-<br />
| 0x0001<br />
| Download Play Child<br />
| DlpChild<br />
|-<br />
| 0x0002<br />
| [[EShop Demos|Demo]]<br />
| Demo<br />
|-<br />
| 0x000E<br />
| [[Title list/Patches|Patch]]<br />
| CannotExecution<nowiki> | </nowiki>Patch<br />
|-<br />
| 0x008C<br />
| [[Title list/DLC|Downloadable Content]]<br />
| NotRequireRightForMount<nowiki> | </nowiki>CannotExecution<nowiki> | </nowiki>AddOnContents<br />
|}<br />
<br />
=== 00040001 - [[Download Play]] Titles ===<br />
==== Download Play Notes ====<br />
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.<br />
<br />
== Factory Titles ==<br />
==== Factory Titles Notes ====<br />
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.<br />
<br />
{| class="wikitable sortable" border="1"<br />
|-<br />
! TitleID<br />
! Description<br />
! Versions<br />
|-<br />
| 000400000F802A00<br />
| Unknown. Appears to be a [[9.8.0-25|gamecard]] title. See also [[11.3.0-36|here]].<br />
Used during [[Nintendo_Service_Center_Tools|repair]], first non-system title listed in [[PTM_Services|playlog]] from repair.<br />
| ?<br />
|-<br />
| 000400000F802100<br />
| Used during [[Nintendo_Service_Center_Tools|repair]], second non-system title listed in [[PTM_Services|playlog]] from repair.<br />
| ?<br />
|-<br />
| 000400000F802200<br />
| Used during [[Nintendo_Service_Center_Tools|repair]], third non-system title listed in [[PTM_Services|playlog]] from repair.<br />
| ?<br />
|-<br />
| 000400000FFFFD00<br />
| Used by retail NS for appID 0xF11, but this isn't available on retail CDN.<br />
| ?<br />
|-<br />
| 000400000FFFFC00<br />
| Used by retail NS for appID 0xF12, but this isn't available on retail CDN.<br />
| ?<br />
|-<br />
| 000400000FFFFB00<br />
| Used by retail NS for appID 0xF13, but this isn't available on retail CDN.<br />
| ?<br />
|-<br />
| 000400000FFFF900<br />
| Used by retail NS for appID 0xF14, but this isn't available on retail CDN.<br />
| ?<br />
|-<br />
| 000400000FFFF800<br />
| Used by retail NS for appID 0xF15, but this isn't available on retail CDN.<br />
| ?<br />
|-<br />
| 000400000FFFF700<br />
| Used by retail NS for appID 0xF16, but this isn't available on retail CDN.<br />
| ?<br />
|-<br />
| 000400000FFFF600<br />
| Used by retail NS for appID 0xF17, but this isn't available on retail CDN.<br />
| ?<br />
|-<br />
| 000400000FFFF500<br />
| Used by retail NS for appID 0xF18, but this isn't available on retail CDN.<br />
| ?<br />
|-<br />
| 0004003000008900<br />
| Used by retail NS for appID 0xF10, but this isn't available on retail CDN.<br />
| ?<br />
|-<br />
| 0004013000001902<br />
| dmnt, debugger sysmodule. This use devunit-only HIO for devunit<>pc comms. This only exists for development units(launched by NS during startup depending on certain [[Configuration_Memory]] fields' values). <br />
This is installed at the [[Factory_Setup|factory]], then later deleted at the factory on retail units.<br />
| ?<br />
|-<br />
| 0004013000003602<br />
| "debugger". This only exist for development units(launched by NS during startup depending on certain [[Configuration_Memory]] fields' values).<br />
| ?<br />
|}<br />
<br />
== TWL (DSi) Titles ==<br />
==== TWL Title Notes ====<br />
Bitmask 0x1 for TWL titles denotes a system title (determining whether the title will be updated during a System Update).<br />
<br />
It appears to be sufficient, but not necessary, to make the title invisible on the [[Home Menu]].<br />
<br />
Bitmask 0x2 for TWL titles may indicate no-execute.<br />
<br />
Bitmask 0x4 for TWL titles indicates internal storage.<br />
<br />
Bitmask 0x10 for TWL titles is found on developer tools.<br />
<br />
<br />
{| class="wikitable sortable" border="1"<br />
|-<br />
! Content Category<br />
! Bit Mask(s)<br />
! Category Bit Mask<br />
|-<br />
| Application (DSiWare)<br />
| TWL<nowiki> | </nowiki>0x4<br />
| 0x8004<br />
|-<br />
| System Application<br />
| TWL<nowiki> | </nowiki>0x1<nowiki> | </nowiki>0x4<br />
| 0x8005<br />
|-<br />
| System Archive<br />
| TWL<nowiki> | </nowiki>0x1<nowiki> | </nowiki>0x2<nowiki> | </nowiki>0x4<nowiki> | </nowiki>0x8<br />
| 0x800F<br />
|-<br />
| Developer Tool<br />
| TWL<nowiki> | </nowiki>0x1<nowiki> | </nowiki>0x4<nowiki> | </nowiki>0x10<br />
| 0x8015<br />
|}<br />
<br />
<br />
=== 00048005 - System Applications===<br />
{| class="wikitable sortable" border="1"<br />
|-<br />
! TitleID Low<br />
! Region<br />
! Description<br />
! Versions<br />
! Information<br />
|-<br />
| 42383841(B88A)<br />
| ALL<br />
| [[DS Internet]]<br />
| v0, [[2.1.0-4|v1025]], [[3.0.0-5|v2048]]<br />
| [[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. <br />
|-<br />
| 484E4441(HNDA)<br />
| ALL<br />
| [[Download Play]]<br />
| v1024<br />
| This [[Download Play]] application is the DS-mode Download Play client, launched by the 3DS-mode Download Play application.<br />
|-<br />
| 484E4443(HNDC)<br />
| CHN<br />
| [[Download Play]]<br />
| v1024<br />
| See Above Description.<br />
|-<br />
| 484E444B(HNDK)<br />
| KOR<br />
| [[Download Play]]<br />
| v1024<br />
| See Above Description.<br />
|}<br />
<br />
=== 0004800F - System Data Archives===<br />
==== System Data Archive Notes ====<br />
New system updates only block DS flash-cards when whitelist is updated, or when TWL_FIRM is updated. <br />
The whitelist contains the data used for detecting flash-cards, this is used by TWL_FIRM.<br />
<br />
{| class="wikitable sortable" border="1"<br />
|-<br />
! TitleID Low<br />
! Description<br />
! Versions<br />
|-<br />
| 484E4841(HNHA)<br />
| [[Nintendo DS Cart Whitelist]] - <br />
| 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]]<br />
|-<br />
| 484E4C41(HNLA)<br />
| [[Version Data]]<br />
| v0<br />
|}<br />
<br />
=== 00048004 - DSiWare Ports ===<br />
==== DSiWare Port Notes ====<br />
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.<br />
See [[3DS DSiWare Titles]] for a complete list.</div>Myriahttps://www.3dbrew.org/w/index.php?title=Cfg:GetSystemModel&diff=20050Cfg:GetSystemModel2017-05-29T08:44:31Z<p>Myria: /* Description */ explanation of A and P serial number tags</p>
<hr />
<div>=Request=<br />
{| class="wikitable" border="1"<br />
|-<br />
! Index Word<br />
! Description<br />
|-<br />
| 0<br />
| Header code [0x00050000]<br />
|}<br />
<br />
=Response=<br />
{| class="wikitable" border="1"<br />
|-<br />
! Index Word<br />
! Description<br />
|-<br />
| 0<br />
| Header code<br />
|-<br />
| 1<br />
| Result code<br />
|-<br />
| 2<br />
| u8 output system model<br />
|}<br />
<br />
=System Model Values=<br />
{| class="wikitable" border="1"<br />
|-<br />
! Value<br />
! Description<br />
! Codename string used by [[ACT_Services|ACT-sysmodule]]<br />
|-<br />
|-<br />
| 0<br />
| Nintendo 3DS<br />
| CTR<br />
|-<br />
| 1<br />
| Nintendo 3DS XL<br />
| SPR<br />
|-<br />
| 2<br />
| [[New_3DS]]<br />
| KTR<br />
|-<br />
| 3<br />
| Nintendo 2DS<br />
| FTR<br />
|-<br />
| 4<br />
| [[New_3DS]] XL<br />
| RED<br />
|-<br />
| 5<br />
| New 2DS XL<br />
| JAN<br />
|}<br />
<br />
=Description=<br />
This uses the code for [[CfgS:GetConfigInfoBlk8]] to load 4-bytes from blkID [[Config_Savegame|0x000F0004]]. The first u8 from this output is written to the command-response output u8. When this value=3 for Nintendo 2DS, this uses the code for [[CfgS:SecureInfoGetSerialNo]] to load the SerialNo. The first byte from the SerialNo must be 'A' (retail 2DS) or 'P' (devkit 2DS) when the above value is set for Nintendo 2DS, otherwise this returns error 0xD8A10006 and clears the output u8 to value zero.</div>Myriahttps://www.3dbrew.org/w/index.php?title=Cfg:GetSystemModel&diff=20049Cfg:GetSystemModel2017-05-29T08:42:59Z<p>Myria: Added New 2DS XL</p>
<hr />
<div>=Request=<br />
{| class="wikitable" border="1"<br />
|-<br />
! Index Word<br />
! Description<br />
|-<br />
| 0<br />
| Header code [0x00050000]<br />
|}<br />
<br />
=Response=<br />
{| class="wikitable" border="1"<br />
|-<br />
! Index Word<br />
! Description<br />
|-<br />
| 0<br />
| Header code<br />
|-<br />
| 1<br />
| Result code<br />
|-<br />
| 2<br />
| u8 output system model<br />
|}<br />
<br />
=System Model Values=<br />
{| class="wikitable" border="1"<br />
|-<br />
! Value<br />
! Description<br />
! Codename string used by [[ACT_Services|ACT-sysmodule]]<br />
|-<br />
|-<br />
| 0<br />
| Nintendo 3DS<br />
| CTR<br />
|-<br />
| 1<br />
| Nintendo 3DS XL<br />
| SPR<br />
|-<br />
| 2<br />
| [[New_3DS]]<br />
| KTR<br />
|-<br />
| 3<br />
| Nintendo 2DS<br />
| FTR<br />
|-<br />
| 4<br />
| [[New_3DS]] XL<br />
| RED<br />
|-<br />
| 5<br />
| New 2DS XL<br />
| JAN<br />
|}<br />
<br />
=Description=<br />
This uses the code for [[CfgS:GetConfigInfoBlk8]] to load 4-bytes from blkID [[Config_Savegame|0x000F0004]]. The first u8 from this output is written to the command-response output u8. When this value=3 for Nintendo 2DS, this uses the code for [[CfgS:SecureInfoGetSerialNo]] to load the SerialNo. The first byte from the SerialNo must be 'A' or 'P' when the above value is set for Nintendo 2DS, otherwise this returns error 0xD8A10006 and clears the output u8 to value zero.</div>Myriahttps://www.3dbrew.org/w/index.php?title=Serials&diff=20039Serials2017-05-23T06:39:16Z<p>Myria: /* Console Models */ Added "/LL" designation to DSi XL</p>
<hr />
<div>This page talks about the 3DS products' serial number and model number structures (the console, manual, accessories, games, etc...).<br />
<br />
== Console Serial Numbers ==<br />
<br />
A 3DS console serial number is composed of at least two letters followed by nine decimal digits. The ninth digit is a "check digit", meaning that it is derived from the other digits.<br />
<br />
The check digit is an industry-standard algorithm, the one used for UPC codes. To calculate the check digit of a 3DS console, separate the non-check digits into "odd" and "even" groups, where the "odd" group is digits in odd-numbered positions, and the "even" group is digits in even-numbered positions. (The first digit is "odd", with "first" representing "1".)<br />
<br />
After separating the digits, add the digits in each group together. Multiply the sum of the even digits by 3, then add the sum of the odd digits. To calculate the check digit, take this value modulo 10, and if not 0, subtract from 10.<br />
<br />
Example: CW404567772<br />
<br />
The non-check digits are 40456777. Separating into odd and even groups, we get the following:<br />
<br />
Odds: 4 + 4 + 6 + 7 = 21<br />
Evens: 0 + 5 + 7 + 7 = 19<br />
<br />
Applying the algorithm, we get ((3 * 19) + 21) % 10 = 8, which is not 0, thus 10 - 8 = 2, matching the example's check digit.<br />
<br />
The letter prefixes are a letter specifying the device, followed by one letter specifying the region in which it was sold. In some regions, a third letter is present; a current guess is that this letter distinguishes among factories for a given sales region. Note that several different sales regions' console may be considered to be the same region for region-locking purposes, such as Europe and Australia.<br />
<br />
The current serial number scheme began with the DSi, hence its listing in the tables below. Among standalone consoles, the Wii U belongs to this scheme as well; the Switch started a new scheme.<br />
<br />
{| class="wikitable"<br />
! Model !! Device Prefix (Retail) !! Device Prefix (Dev)<br />
|-<br />
| ''DSi'' || T ||<br />
|-<br />
| ''DSi XL/LL'' || W ||<br />
|-<br />
| ''Wii U'' || F ||<br />
|-<br />
| 3DS || C || E<br />
|-<br />
| 3DS XL/LL || S || R<br />
|-<br />
| 2DS || A || P<br />
|-<br />
| New 3DS || Y || Y<br />
|-<br />
| New 3DS XL/LL || Q || Q<br />
|-<br />
| New 2DS XL/LL || N || N<br />
|}<br />
<br />
Development units with the same prefix as retail can be distinguished by development units having 00 as the first two digits of the serial number portion. It's currently not known definitively, but 01 as the first two digits seems to mean a retail unit given out to the press - this was seen for New 2DS XL units reviewed by the press.<br />
<br />
{| class="wikitable"<br />
! Sales Region !! Region Lock !! Region Suffix<br />
|-<br />
| Japan || Japan || JF, JH, JM<br />
|-<br />
| North America || North America || W<br />
|-<br />
| Middle East / Southeast Asia || North America || S<br />
|-<br />
| Europe || Europe || EF, EH, EM<br />
|-<br />
| Australia || Europe || AH<br />
|-<br />
| South Korea || Korea || KF, KH, KM<br />
|}<br />
<br />
== Console Models ==<br />
<br />
{| class="wikitable"<br />
! Device !! Product Code<br />
|-<br />
| ''DS'' || NTR<br />
|-<br />
| ''DS lite'' || USG<br />
|-<br />
| ''DSi'' || TWL<br />
|-<br />
| ''DSi XL/LL'' || UTL<br />
|-<br />
| ''Wii U'' || WUP<br />
|-<br />
| 3DS || CTR<br />
|-<br />
| 3DS XL/LL || SPR<br />
|-<br />
| 2DS || FTR<br />
|-<br />
| [[New 3DS]] || KTR<br />
|-<br />
| [[New 3DS]] XL/LL || RED<br />
|-<br />
| New 2DS XL/LL || JAN<br />
|}<br />
<br />
The DS had the product code NTR, so we see the TR is recurring.<br />
<br />
== Title ID and Unique ID ==<br />
''see [[Titles]]''<br />
<br />
== NCCH Product Code ==<br />
<br />
This serial is similiar to the "physical serial" described later in this page; it is the canonical identifier for a specific title in the field of business formalities with Nintendo, but this is not reflected in the 3DS's software architecture (where it is vastly unused in favor of the Title ID: it is therefore considered the successor of the "internal name" contained in ROMs of previous handhelds), is not guaranteed to be unique.<br />
<br />
The product code is located in a [[NCCH]]'s header (not its ExHeader).<br />
<br />
The product code "CTR-P-CTAP" is the default generic product code for NCCH files. Most [[NCSD|NCCHs apart from the first one]] in a title are generally CTR-P-CTAP.<br />
Referring to "the product code of a title" is therefore a simplification for "the product code of the NCCH in its first partition".<br />
<br />
So, for example, a Japanese copy of Ridge Racer 3D would have a product code of "CTR-P-ARRJ" and a serial of "LNA-CTR-ARRJ-JPN".<br />
<br />
A Nintendo-assigned product code follows this format, however, there is no requirement for a product code to match or resemble this structure as long as it's within the length limit:<br />
<br />
[CTR/KTR]-[Category letter]-[Type][Identifier][Region]-[Sub ID]<br />
<br />
{| class="wikitable"<br />
! Category letter !! Description<br />
|-<br />
| P || Cartridge software, or downloadable versions of them.<br />
|-<br />
| N || Digital-only releases, including [[Title list|system applications and applets]].<br />
|-<br />
| M || [[DLC]]<br />
|-<br />
| T || [[eShop Demos]], excluding so-called "special demos" which are category N.<br />
|-<br />
| U || [[Title list#0004000E - Add-on Content (Updates)|Patches]] for category P titles.<br />
|}<br />
<br />
The "sub ID" only applies to DLC, demos, and local copies of Download Play titles. It's a 2-digit number associated with the [[Title list|Title ID Variation]].<br />
<br />
See the next chapter for explanation of the other components of the Product Code.<br />
<br />
== Physical Serial ==<br />
<br />
[Product][Retail/Demo]-CTR-[Type][Identifier][Region]-[Label Region]<br />
<br />
{| class="wikitable"<br />
! Field !! Length !! Description<br />
|-<br />
| Product || 2 || Product type (cartridges are LN, game boxes are TS, instruction manuals are MA, leaflets are FA, quick-start guides are MK)<br />
|-<br />
| Retail/Demo || 1 || Retail (A) or Demo (Z)<br />
|-<br />
| CTR/KTR || 3 || Platform. CTR = 3DS, KTR = New 3DS<br />
|-<br />
| Type || 1 || [A/C/H/J/K/S/P/T] - Retail / C is part of the default serial 'CTAP' / H is used for built in applications like [[Mii Maker]] / J is for a normal eShop Title / K is unknown, seen in Mighty Gunvolt / S is usually a 3D Classics eShop title / P is used with GBA eShop titles / T is used with NES eShop titles.<br />
|-<br />
| Identifier || 2 || game name (two alphanumeric characters).<br />
|-<br />
| Region || 1 || [E/P/J/K/C/Y/W/Z/A] - English (US) / PAL (Europe/Australia) / Japanese (Japan) / Korean (Korea) / Chinese (China/Taiwan) / Multiple regions / Tai'''w'''an(?) (Taiwan/Hong Kong) / Multiple regions / All (region-free)<br />
|-<br />
| Label Region || 3 || [USA/EUR/CAN/JPN/KOR/TWN/CHN/UKV] - USA / Europe / Canada / Japan / Korea / Taiwan/Hong Kong / China / United Kingdom version(?) (United Kingdom)<br />
|}<br />
<br />
=== Electronic Manuals ===<br />
<br />
Some eShop titles have [[NCCH#CFA|Electronic Manuals]] which store the product code at the end of the 'Health & Safety' section of the manual. However, product codes can differ from the above format as shown below:<br />
<br />
CTR-[P/N/T/U]-[Type][Identifier][Region]-[Region]-[Digit]<br />
<br />
CTR-[Type][Identifier][Region]-[Region]-[Digit]<br />
<br />
* P/N/T/U - Same as in product code structure<br />
* [Type][Identifier][Region] - Same as in serial structure<br />
* [Region] - A three character representation of the title region, i.e. 'EUR' (not always present)<br />
* [Digit] - A single digit usually '1' or '0' (not always present)<br />
<br />
'''Note:''' These alternate versions of the product code, potentially found in [[NCCH#CFA|Electronic Manuals]] don't represent the actual product code, as found in the game's CXI. They are only found in the game's Home Menu manual, and on the game's packaging and external labeling.<br />
<br />
==Back of Card Serial==<br />
AREPY10111<br />
<br />
AAAABCDEEE (presumably)<br />
<br />
[Identifier]-[Production Month]-[Production Year]-[Revision]-[Production Run?]</div>Myriahttps://www.3dbrew.org/w/index.php?title=Serials&diff=20038Serials2017-05-23T06:38:24Z<p>Myria: Added Wii U since it uses the same serial number scheme</p>
<hr />
<div>This page talks about the 3DS products' serial number and model number structures (the console, manual, accessories, games, etc...).<br />
<br />
== Console Serial Numbers ==<br />
<br />
A 3DS console serial number is composed of at least two letters followed by nine decimal digits. The ninth digit is a "check digit", meaning that it is derived from the other digits.<br />
<br />
The check digit is an industry-standard algorithm, the one used for UPC codes. To calculate the check digit of a 3DS console, separate the non-check digits into "odd" and "even" groups, where the "odd" group is digits in odd-numbered positions, and the "even" group is digits in even-numbered positions. (The first digit is "odd", with "first" representing "1".)<br />
<br />
After separating the digits, add the digits in each group together. Multiply the sum of the even digits by 3, then add the sum of the odd digits. To calculate the check digit, take this value modulo 10, and if not 0, subtract from 10.<br />
<br />
Example: CW404567772<br />
<br />
The non-check digits are 40456777. Separating into odd and even groups, we get the following:<br />
<br />
Odds: 4 + 4 + 6 + 7 = 21<br />
Evens: 0 + 5 + 7 + 7 = 19<br />
<br />
Applying the algorithm, we get ((3 * 19) + 21) % 10 = 8, which is not 0, thus 10 - 8 = 2, matching the example's check digit.<br />
<br />
The letter prefixes are a letter specifying the device, followed by one letter specifying the region in which it was sold. In some regions, a third letter is present; a current guess is that this letter distinguishes among factories for a given sales region. Note that several different sales regions' console may be considered to be the same region for region-locking purposes, such as Europe and Australia.<br />
<br />
The current serial number scheme began with the DSi, hence its listing in the tables below. Among standalone consoles, the Wii U belongs to this scheme as well; the Switch started a new scheme.<br />
<br />
{| class="wikitable"<br />
! Model !! Device Prefix (Retail) !! Device Prefix (Dev)<br />
|-<br />
| ''DSi'' || T ||<br />
|-<br />
| ''DSi XL/LL'' || W ||<br />
|-<br />
| ''Wii U'' || F ||<br />
|-<br />
| 3DS || C || E<br />
|-<br />
| 3DS XL/LL || S || R<br />
|-<br />
| 2DS || A || P<br />
|-<br />
| New 3DS || Y || Y<br />
|-<br />
| New 3DS XL/LL || Q || Q<br />
|-<br />
| New 2DS XL/LL || N || N<br />
|}<br />
<br />
Development units with the same prefix as retail can be distinguished by development units having 00 as the first two digits of the serial number portion. It's currently not known definitively, but 01 as the first two digits seems to mean a retail unit given out to the press - this was seen for New 2DS XL units reviewed by the press.<br />
<br />
{| class="wikitable"<br />
! Sales Region !! Region Lock !! Region Suffix<br />
|-<br />
| Japan || Japan || JF, JH, JM<br />
|-<br />
| North America || North America || W<br />
|-<br />
| Middle East / Southeast Asia || North America || S<br />
|-<br />
| Europe || Europe || EF, EH, EM<br />
|-<br />
| Australia || Europe || AH<br />
|-<br />
| South Korea || Korea || KF, KH, KM<br />
|}<br />
<br />
== Console Models ==<br />
<br />
{| class="wikitable"<br />
! Device !! Product Code<br />
|-<br />
| ''DS'' || NTR<br />
|-<br />
| ''DS lite'' || USG<br />
|-<br />
| ''DSi'' || TWL<br />
|-<br />
| ''DSi XL'' || UTL<br />
|-<br />
| ''Wii U'' || WUP<br />
|-<br />
| 3DS || CTR<br />
|-<br />
| 3DS XL/LL || SPR<br />
|-<br />
| 2DS || FTR<br />
|-<br />
| [[New 3DS]] || KTR<br />
|-<br />
| [[New 3DS]] XL/LL || RED<br />
|-<br />
| New 2DS XL/LL || JAN<br />
|}<br />
<br />
The DS had the product code NTR, so we see the TR is recurring.<br />
<br />
== Title ID and Unique ID ==<br />
''see [[Titles]]''<br />
<br />
== NCCH Product Code ==<br />
<br />
This serial is similiar to the "physical serial" described later in this page; it is the canonical identifier for a specific title in the field of business formalities with Nintendo, but this is not reflected in the 3DS's software architecture (where it is vastly unused in favor of the Title ID: it is therefore considered the successor of the "internal name" contained in ROMs of previous handhelds), is not guaranteed to be unique.<br />
<br />
The product code is located in a [[NCCH]]'s header (not its ExHeader).<br />
<br />
The product code "CTR-P-CTAP" is the default generic product code for NCCH files. Most [[NCSD|NCCHs apart from the first one]] in a title are generally CTR-P-CTAP.<br />
Referring to "the product code of a title" is therefore a simplification for "the product code of the NCCH in its first partition".<br />
<br />
So, for example, a Japanese copy of Ridge Racer 3D would have a product code of "CTR-P-ARRJ" and a serial of "LNA-CTR-ARRJ-JPN".<br />
<br />
A Nintendo-assigned product code follows this format, however, there is no requirement for a product code to match or resemble this structure as long as it's within the length limit:<br />
<br />
[CTR/KTR]-[Category letter]-[Type][Identifier][Region]-[Sub ID]<br />
<br />
{| class="wikitable"<br />
! Category letter !! Description<br />
|-<br />
| P || Cartridge software, or downloadable versions of them.<br />
|-<br />
| N || Digital-only releases, including [[Title list|system applications and applets]].<br />
|-<br />
| M || [[DLC]]<br />
|-<br />
| T || [[eShop Demos]], excluding so-called "special demos" which are category N.<br />
|-<br />
| U || [[Title list#0004000E - Add-on Content (Updates)|Patches]] for category P titles.<br />
|}<br />
<br />
The "sub ID" only applies to DLC, demos, and local copies of Download Play titles. It's a 2-digit number associated with the [[Title list|Title ID Variation]].<br />
<br />
See the next chapter for explanation of the other components of the Product Code.<br />
<br />
== Physical Serial ==<br />
<br />
[Product][Retail/Demo]-CTR-[Type][Identifier][Region]-[Label Region]<br />
<br />
{| class="wikitable"<br />
! Field !! Length !! Description<br />
|-<br />
| Product || 2 || Product type (cartridges are LN, game boxes are TS, instruction manuals are MA, leaflets are FA, quick-start guides are MK)<br />
|-<br />
| Retail/Demo || 1 || Retail (A) or Demo (Z)<br />
|-<br />
| CTR/KTR || 3 || Platform. CTR = 3DS, KTR = New 3DS<br />
|-<br />
| Type || 1 || [A/C/H/J/K/S/P/T] - Retail / C is part of the default serial 'CTAP' / H is used for built in applications like [[Mii Maker]] / J is for a normal eShop Title / K is unknown, seen in Mighty Gunvolt / S is usually a 3D Classics eShop title / P is used with GBA eShop titles / T is used with NES eShop titles.<br />
|-<br />
| Identifier || 2 || game name (two alphanumeric characters).<br />
|-<br />
| Region || 1 || [E/P/J/K/C/Y/W/Z/A] - English (US) / PAL (Europe/Australia) / Japanese (Japan) / Korean (Korea) / Chinese (China/Taiwan) / Multiple regions / Tai'''w'''an(?) (Taiwan/Hong Kong) / Multiple regions / All (region-free)<br />
|-<br />
| Label Region || 3 || [USA/EUR/CAN/JPN/KOR/TWN/CHN/UKV] - USA / Europe / Canada / Japan / Korea / Taiwan/Hong Kong / China / United Kingdom version(?) (United Kingdom)<br />
|}<br />
<br />
=== Electronic Manuals ===<br />
<br />
Some eShop titles have [[NCCH#CFA|Electronic Manuals]] which store the product code at the end of the 'Health & Safety' section of the manual. However, product codes can differ from the above format as shown below:<br />
<br />
CTR-[P/N/T/U]-[Type][Identifier][Region]-[Region]-[Digit]<br />
<br />
CTR-[Type][Identifier][Region]-[Region]-[Digit]<br />
<br />
* P/N/T/U - Same as in product code structure<br />
* [Type][Identifier][Region] - Same as in serial structure<br />
* [Region] - A three character representation of the title region, i.e. 'EUR' (not always present)<br />
* [Digit] - A single digit usually '1' or '0' (not always present)<br />
<br />
'''Note:''' These alternate versions of the product code, potentially found in [[NCCH#CFA|Electronic Manuals]] don't represent the actual product code, as found in the game's CXI. They are only found in the game's Home Menu manual, and on the game's packaging and external labeling.<br />
<br />
==Back of Card Serial==<br />
AREPY10111<br />
<br />
AAAABCDEEE (presumably)<br />
<br />
[Identifier]-[Production Month]-[Production Year]-[Revision]-[Production Run?]</div>Myriahttps://www.3dbrew.org/w/index.php?title=Serials&diff=20031Serials2017-05-22T06:06:29Z<p>Myria: /* Console Serial Numbers */ note about "01" serials</p>
<hr />
<div>This page talks about the 3DS products' serial number and model number structures (the console, manual, accessories, games, etc...).<br />
<br />
== Console Serial Numbers ==<br />
<br />
A 3DS console serial number is composed of at least two letters followed by nine decimal digits. The ninth digit is a "check digit", meaning that it is derived from the other digits.<br />
<br />
The check digit is an industry-standard algorithm, the one used for UPC codes. To calculate the check digit of a 3DS console, separate the non-check digits into "odd" and "even" groups, where the "odd" group is digits in odd-numbered positions, and the "even" group is digits in even-numbered positions. (The first digit is "odd", with "first" representing "1".)<br />
<br />
After separating the digits, add the digits in each group together. Multiply the sum of the even digits by 3, then add the sum of the odd digits. To calculate the check digit, take this value modulo 10, and if not 0, subtract from 10.<br />
<br />
Example: CW404567772<br />
<br />
The non-check digits are 40456777. Separating into odd and even groups, we get the following:<br />
<br />
Odds: 4 + 4 + 6 + 7 = 21<br />
Evens: 0 + 5 + 7 + 7 = 19<br />
<br />
Applying the algorithm, we get ((3 * 19) + 21) % 10 = 8, which is not 0, thus 10 - 8 = 2, matching the example's check digit.<br />
<br />
The letter prefixes are a letter specifying the device, followed by one letter specifying the region in which it was sold. In some regions, a third letter is present; a current guess is that this letter distinguishes among factories for a given sales region. Note that several different sales regions' console may be considered to be the same region for region-locking purposes, such as Europe and Australia.<br />
<br />
The current serial number system began with the DSi, hence its listing in the tables below.<br />
<br />
{| class="wikitable"<br />
! Model !! Device Prefix (Retail) !! Device Prefix (Dev)<br />
|-<br />
| ''DSi'' || T ||<br />
|-<br />
| ''DSi XL'' || W<br />
|-<br />
| 3DS || C || E<br />
|-<br />
| 3DS XL/LL || S || R<br />
|-<br />
| 2DS || A || P<br />
|-<br />
| New 3DS || Y || Y<br />
|-<br />
| New 3DS XL/LL || Q || Q<br />
|-<br />
| New 2DS XL/LL || N || N<br />
|}<br />
<br />
Development units with the same prefix as retail can be distinguished by development units having 00 as the first two digits of the serial number portion. It's currently not known definitively, but 01 as the first two digits seems to mean a retail unit given out to the press - this was seen for New 2DS XL units reviewed by the press.<br />
<br />
{| class="wikitable"<br />
! Sales Region !! Region Lock !! Region Suffix<br />
|-<br />
| Japan || Japan || JF, JH, JM<br />
|-<br />
| North America || North America || W<br />
|-<br />
| Middle East / Southeast Asia || North America || S<br />
|-<br />
| Europe || Europe || EF, EH, EM<br />
|-<br />
| Australia || Europe || AH<br />
|-<br />
| South Korea || Korea || KF, KH, KM<br />
|}<br />
<br />
== Console Models ==<br />
<br />
{| class="wikitable"<br />
! Device !! Product Code<br />
|-<br />
| ''DS'' || NTR<br />
|-<br />
| ''DS lite'' || USG<br />
|-<br />
| ''DSi'' || TWL<br />
|-<br />
| ''DSi XL'' || UTL<br />
|-<br />
| 3DS || CTR<br />
|-<br />
| 3DS XL/LL || SPR<br />
|-<br />
| 2DS || FTR<br />
|-<br />
| [[New 3DS]] || KTR<br />
|-<br />
| [[New 3DS]] XL/LL || RED<br />
|-<br />
| New 2DS XL/LL || JAN<br />
|}<br />
<br />
The DS had the product code NTR, so we see the TR is recurring.<br />
<br />
== Title ID and Unique ID ==<br />
''see [[Titles]]''<br />
<br />
== NCCH Product Code ==<br />
<br />
This serial is similiar to the "physical serial" described later in this page; it is the canonical identifier for a specific title in the field of business formalities with Nintendo, but this is not reflected in the 3DS's software architecture (where it is vastly unused in favor of the Title ID: it is therefore considered the successor of the "internal name" contained in ROMs of previous handhelds), is not guaranteed to be unique.<br />
<br />
The product code is located in a [[NCCH]]'s header (not its ExHeader).<br />
<br />
The product code "CTR-P-CTAP" is the default generic product code for NCCH files. Most [[NCSD|NCCHs apart from the first one]] in a title are generally CTR-P-CTAP.<br />
Referring to "the product code of a title" is therefore a simplification for "the product code of the NCCH in its first partition".<br />
<br />
So, for example, a Japanese copy of Ridge Racer 3D would have a product code of "CTR-P-ARRJ" and a serial of "LNA-CTR-ARRJ-JPN".<br />
<br />
A Nintendo-assigned product code follows this format, however, there is no requirement for a product code to match or resemble this structure as long as it's within the length limit:<br />
<br />
[CTR/KTR]-[Category letter]-[Type][Identifier][Region]-[Sub ID]<br />
<br />
{| class="wikitable"<br />
! Category letter !! Description<br />
|-<br />
| P || Cartridge software, or downloadable versions of them.<br />
|-<br />
| N || Digital-only releases, including [[Title list|system applications and applets]].<br />
|-<br />
| M || [[DLC]]<br />
|-<br />
| T || [[eShop Demos]], excluding so-called "special demos" which are category N.<br />
|-<br />
| U || [[Title list#0004000E - Add-on Content (Updates)|Patches]] for category P titles.<br />
|}<br />
<br />
The "sub ID" only applies to DLC, demos, and local copies of Download Play titles. It's a 2-digit number associated with the [[Title list|Title ID Variation]].<br />
<br />
See the next chapter for explanation of the other components of the Product Code.<br />
<br />
== Physical Serial ==<br />
<br />
[Product][Retail/Demo]-CTR-[Type][Identifier][Region]-[Label Region]<br />
<br />
{| class="wikitable"<br />
! Field !! Length !! Description<br />
|-<br />
| Product || 2 || Product type (cartridges are LN, game boxes are TS, instruction manuals are MA, leaflets are FA, quick-start guides are MK)<br />
|-<br />
| Retail/Demo || 1 || Retail (A) or Demo (Z)<br />
|-<br />
| CTR/KTR || 3 || Platform. CTR = 3DS, KTR = New 3DS<br />
|-<br />
| Type || 1 || [A/C/H/J/K/S/P/T] - Retail / C is part of the default serial 'CTAP' / H is used for built in applications like [[Mii Maker]] / J is for a normal eShop Title / K is unknown, seen in Mighty Gunvolt / S is usually a 3D Classics eShop title / P is used with GBA eShop titles / T is used with NES eShop titles.<br />
|-<br />
| Identifier || 2 || game name (two alphanumeric characters).<br />
|-<br />
| Region || 1 || [E/P/J/K/C/Y/W/Z/A] - English (US) / PAL (Europe/Australia) / Japanese (Japan) / Korean (Korea) / Chinese (China/Taiwan) / Multiple regions / Tai'''w'''an(?) (Taiwan/Hong Kong) / Multiple regions / All (region-free)<br />
|-<br />
| Label Region || 3 || [USA/EUR/CAN/JPN/KOR/TWN/CHN/UKV] - USA / Europe / Canada / Japan / Korea / Taiwan/Hong Kong / China / United Kingdom version(?) (United Kingdom)<br />
|}<br />
<br />
=== Electronic Manuals ===<br />
<br />
Some eShop titles have [[NCCH#CFA|Electronic Manuals]] which store the product code at the end of the 'Health & Safety' section of the manual. However, product codes can differ from the above format as shown below:<br />
<br />
CTR-[P/N/T/U]-[Type][Identifier][Region]-[Region]-[Digit]<br />
<br />
CTR-[Type][Identifier][Region]-[Region]-[Digit]<br />
<br />
* P/N/T/U - Same as in product code structure<br />
* [Type][Identifier][Region] - Same as in serial structure<br />
* [Region] - A three character representation of the title region, i.e. 'EUR' (not always present)<br />
* [Digit] - A single digit usually '1' or '0' (not always present)<br />
<br />
'''Note:''' These alternate versions of the product code, potentially found in [[NCCH#CFA|Electronic Manuals]] don't represent the actual product code, as found in the game's CXI. They are only found in the game's Home Menu manual, and on the game's packaging and external labeling.<br />
<br />
==Back of Card Serial==<br />
AREPY10111<br />
<br />
AAAABCDEEE (presumably)<br />
<br />
[Identifier]-[Production Month]-[Production Year]-[Revision]-[Production Run?]</div>Myriahttps://www.3dbrew.org/w/index.php?title=Serials&diff=20030Serials2017-05-22T06:00:26Z<p>Myria: /* Console Serial Numbers */ found picture of N2DS XL serial number</p>
<hr />
<div>This page talks about the 3DS products' serial number and model number structures (the console, manual, accessories, games, etc...).<br />
<br />
== Console Serial Numbers ==<br />
<br />
A 3DS console serial number is composed of at least two letters followed by nine decimal digits. The ninth digit is a "check digit", meaning that it is derived from the other digits.<br />
<br />
The check digit is an industry-standard algorithm, the one used for UPC codes. To calculate the check digit of a 3DS console, separate the non-check digits into "odd" and "even" groups, where the "odd" group is digits in odd-numbered positions, and the "even" group is digits in even-numbered positions. (The first digit is "odd", with "first" representing "1".)<br />
<br />
After separating the digits, add the digits in each group together. Multiply the sum of the even digits by 3, then add the sum of the odd digits. To calculate the check digit, take this value modulo 10, and if not 0, subtract from 10.<br />
<br />
Example: CW404567772<br />
<br />
The non-check digits are 40456777. Separating into odd and even groups, we get the following:<br />
<br />
Odds: 4 + 4 + 6 + 7 = 21<br />
Evens: 0 + 5 + 7 + 7 = 19<br />
<br />
Applying the algorithm, we get ((3 * 19) + 21) % 10 = 8, which is not 0, thus 10 - 8 = 2, matching the example's check digit.<br />
<br />
The letter prefixes are a letter specifying the device, followed by one letter specifying the region in which it was sold. In some regions, a third letter is present; a current guess is that this letter distinguishes among factories for a given sales region. Note that several different sales regions' console may be considered to be the same region for region-locking purposes, such as Europe and Australia.<br />
<br />
The current serial number system began with the DSi, hence its listing in the tables below.<br />
<br />
{| class="wikitable"<br />
! Model !! Device Prefix (Retail) !! Device Prefix (Dev)<br />
|-<br />
| ''DSi'' || T ||<br />
|-<br />
| ''DSi XL'' || W<br />
|-<br />
| 3DS || C || E<br />
|-<br />
| 3DS XL/LL || S || R<br />
|-<br />
| 2DS || A || P<br />
|-<br />
| New 3DS || Y || Y<br />
|-<br />
| New 3DS XL/LL || Q || Q<br />
|-<br />
| New 2DS XL/LL || N ||<br />
|}<br />
<br />
Development units with the same prefix as retail can be distinguished by development units having a 0 as the first digit of the serial number portion.<br />
<br />
{| class="wikitable"<br />
! Sales Region !! Region Lock !! Region Suffix<br />
|-<br />
| Japan || Japan || JF, JH, JM<br />
|-<br />
| North America || North America || W<br />
|-<br />
| Middle East / Southeast Asia || North America || S<br />
|-<br />
| Europe || Europe || EF, EH, EM<br />
|-<br />
| Australia || Europe || AH<br />
|-<br />
| South Korea || Korea || KF, KH, KM<br />
|}<br />
<br />
== Console Models ==<br />
<br />
{| class="wikitable"<br />
! Device !! Product Code<br />
|-<br />
| ''DS'' || NTR<br />
|-<br />
| ''DS lite'' || USG<br />
|-<br />
| ''DSi'' || TWL<br />
|-<br />
| ''DSi XL'' || UTL<br />
|-<br />
| 3DS || CTR<br />
|-<br />
| 3DS XL/LL || SPR<br />
|-<br />
| 2DS || FTR<br />
|-<br />
| [[New 3DS]] || KTR<br />
|-<br />
| [[New 3DS]] XL/LL || RED<br />
|-<br />
| New 2DS XL/LL || JAN<br />
|}<br />
<br />
The DS had the product code NTR, so we see the TR is recurring.<br />
<br />
== Title ID and Unique ID ==<br />
''see [[Titles]]''<br />
<br />
== NCCH Product Code ==<br />
<br />
This serial is similiar to the "physical serial" described later in this page; it is the canonical identifier for a specific title in the field of business formalities with Nintendo, but this is not reflected in the 3DS's software architecture (where it is vastly unused in favor of the Title ID: it is therefore considered the successor of the "internal name" contained in ROMs of previous handhelds), is not guaranteed to be unique.<br />
<br />
The product code is located in a [[NCCH]]'s header (not its ExHeader).<br />
<br />
The product code "CTR-P-CTAP" is the default generic product code for NCCH files. Most [[NCSD|NCCHs apart from the first one]] in a title are generally CTR-P-CTAP.<br />
Referring to "the product code of a title" is therefore a simplification for "the product code of the NCCH in its first partition".<br />
<br />
So, for example, a Japanese copy of Ridge Racer 3D would have a product code of "CTR-P-ARRJ" and a serial of "LNA-CTR-ARRJ-JPN".<br />
<br />
A Nintendo-assigned product code follows this format, however, there is no requirement for a product code to match or resemble this structure as long as it's within the length limit:<br />
<br />
[CTR/KTR]-[Category letter]-[Type][Identifier][Region]-[Sub ID]<br />
<br />
{| class="wikitable"<br />
! Category letter !! Description<br />
|-<br />
| P || Cartridge software, or downloadable versions of them.<br />
|-<br />
| N || Digital-only releases, including [[Title list|system applications and applets]].<br />
|-<br />
| M || [[DLC]]<br />
|-<br />
| T || [[eShop Demos]], excluding so-called "special demos" which are category N.<br />
|-<br />
| U || [[Title list#0004000E - Add-on Content (Updates)|Patches]] for category P titles.<br />
|}<br />
<br />
The "sub ID" only applies to DLC, demos, and local copies of Download Play titles. It's a 2-digit number associated with the [[Title list|Title ID Variation]].<br />
<br />
See the next chapter for explanation of the other components of the Product Code.<br />
<br />
== Physical Serial ==<br />
<br />
[Product][Retail/Demo]-CTR-[Type][Identifier][Region]-[Label Region]<br />
<br />
{| class="wikitable"<br />
! Field !! Length !! Description<br />
|-<br />
| Product || 2 || Product type (cartridges are LN, game boxes are TS, instruction manuals are MA, leaflets are FA, quick-start guides are MK)<br />
|-<br />
| Retail/Demo || 1 || Retail (A) or Demo (Z)<br />
|-<br />
| CTR/KTR || 3 || Platform. CTR = 3DS, KTR = New 3DS<br />
|-<br />
| Type || 1 || [A/C/H/J/K/S/P/T] - Retail / C is part of the default serial 'CTAP' / H is used for built in applications like [[Mii Maker]] / J is for a normal eShop Title / K is unknown, seen in Mighty Gunvolt / S is usually a 3D Classics eShop title / P is used with GBA eShop titles / T is used with NES eShop titles.<br />
|-<br />
| Identifier || 2 || game name (two alphanumeric characters).<br />
|-<br />
| Region || 1 || [E/P/J/K/C/Y/W/Z/A] - English (US) / PAL (Europe/Australia) / Japanese (Japan) / Korean (Korea) / Chinese (China/Taiwan) / Multiple regions / Tai'''w'''an(?) (Taiwan/Hong Kong) / Multiple regions / All (region-free)<br />
|-<br />
| Label Region || 3 || [USA/EUR/CAN/JPN/KOR/TWN/CHN/UKV] - USA / Europe / Canada / Japan / Korea / Taiwan/Hong Kong / China / United Kingdom version(?) (United Kingdom)<br />
|}<br />
<br />
=== Electronic Manuals ===<br />
<br />
Some eShop titles have [[NCCH#CFA|Electronic Manuals]] which store the product code at the end of the 'Health & Safety' section of the manual. However, product codes can differ from the above format as shown below:<br />
<br />
CTR-[P/N/T/U]-[Type][Identifier][Region]-[Region]-[Digit]<br />
<br />
CTR-[Type][Identifier][Region]-[Region]-[Digit]<br />
<br />
* P/N/T/U - Same as in product code structure<br />
* [Type][Identifier][Region] - Same as in serial structure<br />
* [Region] - A three character representation of the title region, i.e. 'EUR' (not always present)<br />
* [Digit] - A single digit usually '1' or '0' (not always present)<br />
<br />
'''Note:''' These alternate versions of the product code, potentially found in [[NCCH#CFA|Electronic Manuals]] don't represent the actual product code, as found in the game's CXI. They are only found in the game's Home Menu manual, and on the game's packaging and external labeling.<br />
<br />
==Back of Card Serial==<br />
AREPY10111<br />
<br />
AAAABCDEEE (presumably)<br />
<br />
[Identifier]-[Production Month]-[Production Year]-[Revision]-[Production Run?]</div>Myriahttps://www.3dbrew.org/w/index.php?title=Serials&diff=20029Serials2017-05-22T05:55:12Z<p>Myria: fixed N2DSXL in table</p>
<hr />
<div>This page talks about the 3DS products' serial number and model number structures (the console, manual, accessories, games, etc...).<br />
<br />
== Console Serial Numbers ==<br />
<br />
A 3DS console serial number is composed of at least two letters followed by nine decimal digits. The ninth digit is a "check digit", meaning that it is derived from the other digits.<br />
<br />
The check digit is an industry-standard algorithm, the one used for UPC codes. To calculate the check digit of a 3DS console, separate the non-check digits into "odd" and "even" groups, where the "odd" group is digits in odd-numbered positions, and the "even" group is digits in even-numbered positions. (The first digit is "odd", with "first" representing "1".)<br />
<br />
After separating the digits, add the digits in each group together. Multiply the sum of the even digits by 3, then add the sum of the odd digits. To calculate the check digit, take this value modulo 10, and if not 0, subtract from 10.<br />
<br />
Example: CW404567772<br />
<br />
The non-check digits are 40456777. Separating into odd and even groups, we get the following:<br />
<br />
Odds: 4 + 4 + 6 + 7 = 21<br />
Evens: 0 + 5 + 7 + 7 = 19<br />
<br />
Applying the algorithm, we get ((3 * 19) + 21) % 10 = 8, which is not 0, thus 10 - 8 = 2, matching the example's check digit.<br />
<br />
The letter prefixes are a letter specifying the device, followed by one letter specifying the region in which it was sold. In some regions, a third letter is present; a current guess is that this letter distinguishes among factories for a given sales region. Note that several different sales regions' console may be considered to be the same region for region-locking purposes, such as Europe and Australia.<br />
<br />
The current serial number system began with the DSi, hence its listing in the tables below.<br />
<br />
{| class="wikitable"<br />
! Model !! Device Prefix (Retail) !! Device Prefix (Dev)<br />
|-<br />
| ''DSi'' || T ||<br />
|-<br />
| ''DSi XL'' || W<br />
|-<br />
| 3DS || C || E<br />
|-<br />
| 3DS XL/LL || S || R<br />
|-<br />
| 2DS || A || P<br />
|-<br />
| New 3DS || Y || Y<br />
|-<br />
| New 3DS XL/LL || Q || Q<br />
|-<br />
| New 2DS XL/LL || ||<br />
|}<br />
<br />
Development units with the same prefix as retail can be distinguished by development units having a 0 as the first digit of the serial number portion.<br />
<br />
{| class="wikitable"<br />
! Sales Region !! Region Lock !! Region Suffix<br />
|-<br />
| Japan || Japan || JF, JH, JM<br />
|-<br />
| North America || North America || W<br />
|-<br />
| Middle East / Southeast Asia || North America || S<br />
|-<br />
| Europe || Europe || EF, EH, EM<br />
|-<br />
| Australia || Europe || AH<br />
|-<br />
| South Korea || Korea || KF, KH, KM<br />
|}<br />
<br />
== Console Models ==<br />
<br />
{| class="wikitable"<br />
! Device !! Product Code<br />
|-<br />
| ''DS'' || NTR<br />
|-<br />
| ''DS lite'' || USG<br />
|-<br />
| ''DSi'' || TWL<br />
|-<br />
| ''DSi XL'' || UTL<br />
|-<br />
| 3DS || CTR<br />
|-<br />
| 3DS XL/LL || SPR<br />
|-<br />
| 2DS || FTR<br />
|-<br />
| [[New 3DS]] || KTR<br />
|-<br />
| [[New 3DS]] XL/LL || RED<br />
|-<br />
| New 2DS XL/LL || JAN<br />
|}<br />
<br />
The DS had the product code NTR, so we see the TR is recurring.<br />
<br />
== Title ID and Unique ID ==<br />
''see [[Titles]]''<br />
<br />
== NCCH Product Code ==<br />
<br />
This serial is similiar to the "physical serial" described later in this page; it is the canonical identifier for a specific title in the field of business formalities with Nintendo, but this is not reflected in the 3DS's software architecture (where it is vastly unused in favor of the Title ID: it is therefore considered the successor of the "internal name" contained in ROMs of previous handhelds), is not guaranteed to be unique.<br />
<br />
The product code is located in a [[NCCH]]'s header (not its ExHeader).<br />
<br />
The product code "CTR-P-CTAP" is the default generic product code for NCCH files. Most [[NCSD|NCCHs apart from the first one]] in a title are generally CTR-P-CTAP.<br />
Referring to "the product code of a title" is therefore a simplification for "the product code of the NCCH in its first partition".<br />
<br />
So, for example, a Japanese copy of Ridge Racer 3D would have a product code of "CTR-P-ARRJ" and a serial of "LNA-CTR-ARRJ-JPN".<br />
<br />
A Nintendo-assigned product code follows this format, however, there is no requirement for a product code to match or resemble this structure as long as it's within the length limit:<br />
<br />
[CTR/KTR]-[Category letter]-[Type][Identifier][Region]-[Sub ID]<br />
<br />
{| class="wikitable"<br />
! Category letter !! Description<br />
|-<br />
| P || Cartridge software, or downloadable versions of them.<br />
|-<br />
| N || Digital-only releases, including [[Title list|system applications and applets]].<br />
|-<br />
| M || [[DLC]]<br />
|-<br />
| T || [[eShop Demos]], excluding so-called "special demos" which are category N.<br />
|-<br />
| U || [[Title list#0004000E - Add-on Content (Updates)|Patches]] for category P titles.<br />
|}<br />
<br />
The "sub ID" only applies to DLC, demos, and local copies of Download Play titles. It's a 2-digit number associated with the [[Title list|Title ID Variation]].<br />
<br />
See the next chapter for explanation of the other components of the Product Code.<br />
<br />
== Physical Serial ==<br />
<br />
[Product][Retail/Demo]-CTR-[Type][Identifier][Region]-[Label Region]<br />
<br />
{| class="wikitable"<br />
! Field !! Length !! Description<br />
|-<br />
| Product || 2 || Product type (cartridges are LN, game boxes are TS, instruction manuals are MA, leaflets are FA, quick-start guides are MK)<br />
|-<br />
| Retail/Demo || 1 || Retail (A) or Demo (Z)<br />
|-<br />
| CTR/KTR || 3 || Platform. CTR = 3DS, KTR = New 3DS<br />
|-<br />
| Type || 1 || [A/C/H/J/K/S/P/T] - Retail / C is part of the default serial 'CTAP' / H is used for built in applications like [[Mii Maker]] / J is for a normal eShop Title / K is unknown, seen in Mighty Gunvolt / S is usually a 3D Classics eShop title / P is used with GBA eShop titles / T is used with NES eShop titles.<br />
|-<br />
| Identifier || 2 || game name (two alphanumeric characters).<br />
|-<br />
| Region || 1 || [E/P/J/K/C/Y/W/Z/A] - English (US) / PAL (Europe/Australia) / Japanese (Japan) / Korean (Korea) / Chinese (China/Taiwan) / Multiple regions / Tai'''w'''an(?) (Taiwan/Hong Kong) / Multiple regions / All (region-free)<br />
|-<br />
| Label Region || 3 || [USA/EUR/CAN/JPN/KOR/TWN/CHN/UKV] - USA / Europe / Canada / Japan / Korea / Taiwan/Hong Kong / China / United Kingdom version(?) (United Kingdom)<br />
|}<br />
<br />
=== Electronic Manuals ===<br />
<br />
Some eShop titles have [[NCCH#CFA|Electronic Manuals]] which store the product code at the end of the 'Health & Safety' section of the manual. However, product codes can differ from the above format as shown below:<br />
<br />
CTR-[P/N/T/U]-[Type][Identifier][Region]-[Region]-[Digit]<br />
<br />
CTR-[Type][Identifier][Region]-[Region]-[Digit]<br />
<br />
* P/N/T/U - Same as in product code structure<br />
* [Type][Identifier][Region] - Same as in serial structure<br />
* [Region] - A three character representation of the title region, i.e. 'EUR' (not always present)<br />
* [Digit] - A single digit usually '1' or '0' (not always present)<br />
<br />
'''Note:''' These alternate versions of the product code, potentially found in [[NCCH#CFA|Electronic Manuals]] don't represent the actual product code, as found in the game's CXI. They are only found in the game's Home Menu manual, and on the game's packaging and external labeling.<br />
<br />
==Back of Card Serial==<br />
AREPY10111<br />
<br />
AAAABCDEEE (presumably)<br />
<br />
[Identifier]-[Production Month]-[Production Year]-[Revision]-[Production Run?]</div>Myria