3dbrew - User contributions [en]

Flash Filesystem

2017-02-07T01:06:09Z

Plailect: added all known NAND flash sizes

The Nintendo 3DS has several differently sized NAND flash chips. Due to the NCSD header, the actual used size of the Old3DS NAND is 0x3AF00000-bytes(943MiB). On New3DS, the actual NAND size and the total size used by the partitions, is 0x4D800000-bytes(1240MiB).

===Physical Size===
{| class="wikitable" border="1"
! Device
! Manufacturer
! Size
|-
| 2DS
| Toshiba
| 0x3AF00000
|-
| 2DS
| Toshiba
| 0x76000000
|-
| 2DS
| Samsung
| 0x3BA00000
|-
| 2DS
| Samsung
| 0x4D800000
|-
| Old3DS
| Toshiba
| 0x3AF00000
|-
| Old3DS
| Samsung
| 0x3BA00000
|-
| New3DS
| Toshiba
| 0x76000000
|-
| New3DS
| Samsung
| 0x4D800000
|-
| New3DS
| Samsung
| 0x74800000
|}

===Format===
Reading of the flash chip is possible through pinouts on the motherboard and has been performed successfully but the data is encrypted and can't be understood without first decrypting it.

===Region Changing===
See [https://gist.github.com/yellows8/f15be7a51c38cea14f2c here].

===Redirection to SD card===
See [[NAND_Redirection]].

===Encryption===

The NAND file system is encrypted using [[AES|AES-CTR]]. The TWL regions of NAND use the TWL NAND [[AES|keyslot]], while the CTR regions use the CTR NAND [[AES|keyslots]]. The keyslot used for each partition is determined by the NCSD partition FS type and encryption type. The TWL/CTR NAND regions are specified by the NCSD header. The first 0x0B100000 bytes of NAND is encrypted with the TWL keyslot, however before 0x00012E00 only the MBR partition table is encrypted with the TWL keyslot. That region contains the TWL partitions listed below.

The New3DS CTRNAND partition uses a [[AES|keyslot]] separate from the Old3DS one.

Note that re-encrypting a NAND image alone from another 3DS for use on a different 3DS is not enough to use that NAND image on a different 3DS: certain files in the "nand" partition would need modified/replaced as well.

===NAND structure===
{| class="wikitable" border="1"
|-
! Old3DS
! New3DS
! Partition name
! Offset
! Size
! NCSD partition FS type
! NCSD partition encryption type
! NCSD partition index
! [[AES_Registers|AES]] engine keyslot
! Description
|-
| style="background: #ccffbb" | Yes
| style="background: #ccffbb" | Yes
|
| 0x0
| 0x200
|
|
|
|
| [[NCSD]] header, this contains the offsets/sizes of the below CTR-NAND partitions. This block also contains the TWL-NAND MBR partition table.
|-
| style="background: #ccffbb" | Yes
| style="background: #ccffbb" | Yes
|
| 0x00000000
| 0x0B100000
| 0x01
| 0x01
| 0x00
| 0x03
| TWL NAND region
|-
| style="background: #ffccbb" | No
| style="background: #ccffbb" | Yes
|
| 0x00012C00
| 0x200
|
|
|
| See below.
| Console-unique encrypted New3DS key-storage, see below.
|-
| style="background: #ccffbb" | Yes
| style="background: #ccffbb" | Yes
| twln
| 0x00012E00
| 0x08FB5200
|
|
|
| 0x03
| TWL-NAND FAT16 File System. (DSi)
|-
| style="background: #ccffbb" | Yes
| style="background: #ccffbb" | Yes
| twlp
| 0x09011A00
| 0x020B6600
|
|
|
| 0x03
| TWL-NAND PHOTO FAT12 File System. (DSi)
|-
| style="background: #ccffbb" | Yes
| style="background: #ccffbb" | Yes
|
| 0x0B100000
| 0x00030000
| 0x04
| 0x02
| 0x01
| 0x07
| By default this partition is empty(only contains 0x00/0xFF bytes since it was never written to), when AGB_FIRM was never launched. This contains the AGB_FIRM GBA savegame.
|-
| style="background: #ccffbb" | Yes
| style="background: #ccffbb" | Yes
| firm0
| 0x0B130000
| 0x00400000
| 0x03
| 0x02
| 0x02
| 0x06
| [[FIRM|Firmware]] partition.
|-
| style="background: #ccffbb" | Yes
| style="background: #ccffbb" | Yes
| firm1
| 0x0B530000
| 0x00400000
| 0x03
| 0x02
| 0x03
| 0x06
| [[FIRM|Firmware]] partition.(Backup partition, same as above)
|-
| style="background: #ccffbb" | Yes
| style="background: #ffccbb" | No
|
| 0x0B930000
| 0x2F5D0000
| 0x01
| 0x02
| 0x04
| 0x04
| CTR-NAND partition. (3DS)
|-
| style="background: #ccffbb" | Yes
| style="background: #ffccbb" | No
| nand
| 0x0B95CA00
| 0x2F3E3600
|
|
|
| 0x04
| CTR-NAND FAT16 File System.
|-
| style="background: #ffccbb" | No
| style="background: #ccffbb" | Yes
|
| 0x0B930000
| 0x41ED0000
| 0x01
| 0x03
| 0x04
| 0x05
| CTR-NAND partition. (New3DS)
|-
| style="background: #ffccbb" | No
| style="background: #ccffbb" | Yes
| nand
| 0x0B95AE00
| 0x41D2D200
|
|
|
| 0x05
| CTR-NAND FAT16 File System.
|}

3DS TWL NAND FAT partitions has FAT volume name "TWL", for CTR FAT partitions this is "CTR". The offset/size for TWL partitions are stored in the MBR partition table, while the CTR partition table info is stored in the NAND NCSD header. Sector0 in the CTR-NAND partition contains a MBR partition table for the nand FAT16 filesystem, and the MBR signature at +0x1fe.

NAND sectors which were never written to before only contain plaintext 0x00 or 0xFF bytes.

None of the NAND partitions are normally accessible from the ARM11, except for twlp. CTR/TWL NAND FS can only be accessed when the exheader access control descriptor for those are enabled. Normally the CTR/TWL NAND descriptors are never enabled for retail ARM11 [[NCCH#CXI|CXI]] processes. The ARM11 can only access "nand:/rw/" mounted as the nandrw [[FS:OpenArchive|archive]], and "nand:/ro/" mounted as the nandro archive below.

==== 0x4000 ====
On some 3DS systems(such as 3DS XL), there's a plaintext FAT16 boot record located at NAND offset 0x4000. This block does not exist for launch-day 3DS systems. This is the only plaintext block for this "partition".

==== 0x12C00 ====
{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
|-
| 0x0
| 0x10
| Normal-key for keyslot 0x11, used for generating the rest of the New3DS keyslots' keyX by decrypting various data with AES-ECB. With [[9.6.0-24|9.6.0-X]] this is only used for generating the keyX for keyslots 0x15 and 0x18.
|-
| 0x10
| 0x10
| [[9.6.0-24|9.6.0-X]]: Additional normal-key for keyslot 0x11, used for generating the keyX for keyslots 0x16 and 0x19..0x1F.
|-
| 0x20
| 0x1E0
| Not yet used as of New3DS FIRM [[9.6.0-24|9.6.0-X]].
|}

This 0x200-byte sector contains New3DS keys, this entire sector is encrypted with a console-unique keyX+keyY. The keyX+keyY for this is generated by the New3DS [[FIRM|arm9bin-loader]]. Once the arm9bin-loader finishes decrypting this data, the keyX+keyY in the keyslot are then cleared, then the memory used for generating the keydata is disabled(after it finishes using it for TWL key init).

This entire sector is encrypted with AES-ECB, the entire plaintext sector is identical for all retail and dev New3DS systems (differing between the two).

=CTR partition=
The structure of [[nand/title]] appears to be exactly the same as [[SD Filesystem|SD]], except savegames are stored under the [[System SaveData|nand/data/<ID0>/sysdata]] directory instead.
The sub-directory name under [[nand/data]] is the SHA256 hash over the [[nand/private/movable.sed|movable.sed]] keyY. This nand/data/<ID0> directory is the NAND equivalent of the "sdmc/Nintendo 3DS/<ID0>/<ID1>" directory, however the data contained here is stored in cleartext. The movable.sed keyY is only used for AES MACs for nand/data/<ID0>. The nand/data/<ID0>/extdata directory contains the shared [[extdata]], and is structured exactly the same way as SD extdata.

nand
├── __journal.nn_
├── [[nand/data|data]]
│ └── <ID0>
│ ├── [[Extdata|extdata]]
│ └── [[System SaveData|sysdata]]
├── [[Title Database|dbs]]
├── [[nand/fixdata|fixdata]]
│ └── [[nand/fixdata/sysdata|sysdata]]
├── private
│ └── [[nand/private/movable.sed|movable.sed]]
├── [[nand/ro|ro]]
├── [[nand/rw|rw]]
├── [[nand/ticket|ticket]] (This directory is empty since tickets are stored in [[Title Database|ticket.db]])
├── [[Title Data Structure|title]]
└── [[nand/tmp|tmp]] (This is usually empty, even when installation for a system update still needs [[AMNet:FinishInstallToMedia|finalized]])

The "ro" and "rw" directories are accessible through the "nandrw" and "nandro" [[FS:OpenArchive|archives]], respectively. Their contents are as follows:

ro
├── [[nandro/private|private]]
├── [[nandro/shared|shared]]
└── [[nandro/sys|sys]]
├── [[nandro/sys/HWCAL0.dat|HWCAL0.dat]]
└── [[nandro/sys/HWCAL1.dat|HWCAL1.dat]]
rw
├── [[nandrw/shared|shared]]
└── [[nandrw/sys|sys]]
├── [[nandrw/sys/lgy.log|lgy.log]] (This is written to by [[FIRM|TWL_FIRM]] when errors occur, this is equivalent to native.log)
├── [[nandrw/sys/LocalFriendCodeSeed_B|LocalFriendCodeSeed_B]]
├── [[nandrw/sys/native.log|native.log]] (This is written to by [[ErrDisp]])
├── [[nandrw/sys/rand_seed|rand_seed]]
├── [[nandrw/sys/SecureInfo_A|SecureInfo_A]]
└── [[nandrw/sys/updater.log|updater.log]]

=TWL partition=
The structure of these TWL partitions is mostly the same as DSi, except tickets are stored in the CTR FAT FS. The twlp partition is exactly the same as DSi.
The structure of [[twln/title]] is exactly the same as CTR NAND/SD, except the .cmd file is a cleartext file.(This is likely a dummy file) The data directory under system titles' /title directory does not exist, this likely only exists for DSiWare.
The directory names titleID-High used under [[twln/title]] is from DSi.

twln
├── [[twln/import/|import]]
├── [[twln/shared1/|shared1]]
├── [[twln/shared2/|shared2]]
│ └── [[twln/shared2/0000|0000]]
├── [[twln/sys|sys]]
│ ├── [[twln/sys/TWLFontTable.dat|TWLFontTable.dat]]
│ └── [[twln/sys/log/|log]]
│ ├── [[twln/sys/log/inspect.log|inspect.log]]
│ └── [[twln/sys/log/product.log|product.log]]
├── [[twln/ticket/|ticket]]
├── [[twln/title/|title]]
└── [[twln/tmp/|tmp]]

twlp
└── [[twlp/photo/|photo]]

FSPXI:CloseArchive

2017-01-01T06:02:54Z

Plailect: Created page with "=Request= {| class="wikitable" border="1" |- ! Index Word ! Description |- | 0 | Header code [0x00160080] |- | 1 | Archive handle lower word |- | 2 | Archive handle upper wo..."

=Request=
{| class="wikitable" border="1"
|-
! Index Word
! Description
|-
| 0
| Header code [0x00160080]
|-
| 1
| Archive handle lower word
|-
| 2
| Archive handle upper word
|}

=Response=
{| class="wikitable" border="1"
|-
! Index Word
! Description
|-
| 0
| Header code
|-
| 1
| Result code
|}

FSPXI:CloseFile

2017-01-01T05:57:18Z

Plailect: Created page with "=Request= {| class="wikitable" border="1" |- ! Index Word ! Description |- | 0 | Header code [0x000F0080] |- | 1 | File handle lower word |- | 2 | File handle upper word |}..."

=Request=
{| class="wikitable" border="1"
|-
! Index Word
! Description
|-
| 0
| Header code [0x000F0080]
|-
| 1
| File handle lower word
|-
| 2
| File handle upper word
|}

=Response=
{| class="wikitable" border="1"
|-
! Index Word
! Description
|-
| 0
| Header code
|-
| 1
| Result code
|}

FSPXI:CreateFile

2017-01-01T05:55:33Z

Plailect:

=Request=
{| class="wikitable" border="1"
|-
! Index Word
! Description
|-
| 0
| Header code [0x00050202]
|-
| 1
| Transaction (usually 0)
|-
| 2
| Archive handle lower word
|-
| 3
| Archive handle upper word
|-
| 4
| LowPath.Type
|-
| 5
| LowPath.Size
|-
| 6
| [[Filesystem_services#Attributes|Attributes]]
|-
| 7
| File size lower word
|-
| 8
| File size upper word
|-
| 9
| (LowPath.Size<<8) <nowiki>|</nowiki> 4
|-
| 10
| LowPath.Data pointer
|}

=Response=
{| class="wikitable" border="1"
|-
! Index Word
! Description
|-
| 0
| Header code
|-
| 1
| Result code
|}

FSPXI:CreateFile

2017-01-01T05:53:18Z

Plailect: Created page with "=Request= {| class="wikitable" border="1" |- ! Index Word ! Description |- | 0 | Header code [0x00050202] |- | 1 | Transaction (usually 0) |- | 2 | File handle lower word |-..."

=Request=
{| class="wikitable" border="1"
|-
! Index Word
! Description
|-
| 0
| Header code [0x00050202]
|-
| 1
| Transaction (usually 0)
|-
| 2
| File handle lower word
|-
| 3
| File handle upper word
|-
| 4
| LowPath.Type
|-
| 5
| LowPath.Size
|-
| 6
| [[Filesystem_services#Attributes|Attributes]]
|-
| 7
| File size lower word
|-
| 8
| File size upper word
|-
| 9
| (LowPath.Size<<8) <nowiki>|</nowiki> 4
|-
| 10
| LowPath.Data pointer
|}

=Response=
{| class="wikitable" border="1"
|-
! Index Word
! Description
|-
| 0
| Header code
|-
| 1
| Result code
|}

FSPXI:DeleteFile

2017-01-01T05:47:05Z

Plailect: Created page with "=Request= {| class="wikitable" border="1" |- ! Index Word ! Description |- | 0 | Header code [0x00020142] |- | 1 | Transaction (usually 0) |- | 2 | Archive handle lower word..."

=Request=
{| class="wikitable" border="1"
|-
! Index Word
! Description
|-
| 0
| Header code [0x00020142]
|-
| 1
| Transaction (usually 0)
|-
| 2
| Archive handle lower word
|-
| 3
| Archive handle upper word
|-
| 4
| LowPath.Type
|-
| 5
| LowPath.Size
|-
| 6
| (LowPath.Size<<8) <nowiki>|</nowiki> 4
|-
| 7
| LowPath.Data pointer
|}

=Response=
{| class="wikitable" border="1"
|-
! Index Word
! Description
|-
| 0
| Header code
|-
| 1
| Result code
|}

User:Geekpersonman

2016-05-09T23:12:28Z

Plailect: Created page with "Stop editing every single page with "maybe," that's not actually helpful in any way."

Stop editing every single page with "maybe," that's not actually helpful in any way.

EShop

2016-05-07T16:49:12Z

Plailect: /* URLs */

{{DISPLAYTITLE:eShop}}
The Nintendo 3DS eShop was added in the June 2011 update for JP/EUR/USA.

From here, you can download Virtual Console games, 3D Classics, DSiware software, view screenshots, and 3D trailers for upcoming 3DS titles.

While eShop is loading, eShop will use command [[NIMS:CheckSysupdateAvailableSOAP]]. If a system update is available where title installation for system titles still needs finalized (or when the updated titles were not downloaded at all), eShop will then display the "system update is available" message.

The eShop application uses command [[AMNet:FinishInstallToMedia]] to finalize the SD title install (if the whole title is downloaded while eShop is still running), however, before using that command the eShop application also uses [[AMNet:FinishInstallToMedia]] to finalize installing all system titles (from system updates).

== eShop QR Codes ==
eShop QR Codes can be scanned with the camera, allowing one to quickly navigate to the desired eShop title with just two clicks. The QR Codes themselves is a simple text/url QR, started with "ESHOP://" string followed by a decimal eShop content link id(same IDs used internally by eShop for all content) and then some special data, delimited by a dot symbol, which can be ommited.

In order for the QR-code string data to be valid for eShop, it must begin with "ESHOP://5", with the first ID being all decimal.

{| class="wikitable"
|-
! QR Code source
! Region
! Title
! Serial
! Title ID
|-
| ESHOP://50010000000201.PEAALL000000 || EUR || nintendogs + cats: Golden Retriever & New Friends || ADAP || 0004000000030C00
|-
| ESHOP://50010000007870.PEAALL000000 || EUR || Crush 3D || ACRP || 0004000000040400
|-
| ESHOP://50010000008009.PEAALL000000 || EUR || Resident Evil Revelations || ABRE || 000400000005EE00
|-
| ESHOP://50010000008123.J00101Z00095 || JPN || Rhythm Kaitou R: Koutei Napoleon no Isan || ARTJ || 0004000000078100
|-
| ESHOP://50010000008404.PEAALL000000 || EUR || Mario & Sonic at the London 2012 Olympic Games || ACMP || 0004000000054900
|-
| ESHOP://50010000008447.J00101Z00094 || JPN || Biohazard Revelations || ABRJ || 0004000000053B00
|-
| ESHOP://50010000008449.J00101Z00082 || JPN || Itsu no Ma ni Koukan Nikki || JFRJ || 0004000000051600
|-
| ESHOP://50010000008561 || USA || Swapnote || JFRE || 0004000000051700
|-
| ESHOP://50010000008647.J00101Z00096 || JPN || Metal Gear Solid Snake Eater 3D || AMGJ || 000400000007A000
|-
| ESHOP://50010000008648.J00101Z00097 || JPN || Theatrythm Final Fantasy || ATHJ || 0004000000078200
|-
| ESHOP://50010000008782.PEAALL000000 || EUR || Metal Gear Solid Snake Eater 3D || AMGE || 0004000000082400
|-
| ESHOP://50010000008842.PEAALL000000 || EUR || Rhythm Thief And The Emperor's Treasure || ARTP || 000400000006DA00
|-
| ESHOP://50010000009084.J00101Z00121 || JPN || Hatsune Miku And Future Stars: Project Mirai || AM9J || 0004000000048000
|-
| ESHOP://50010000009102.J00101Z00106 || JPN || Denpa Ningen no RPG || JD8J || 0004000000077E00
|-
| ESHOP://50010000009161.J00101Z00118 || JPN || The Rolling Western || JAMJ || 0004000000059B00
|-
| ESHOP://50010000009261 || USA || Dillon's Rolling Western || JAME || 000400000007C400
|-
| ESHOP://50010000009401.J00101Z00120 || JPN || Kingdom Hearts 3D Nintendo Direct 2012.2.22 Video || JZ8J || 0004000000092E00
|-
| ESHOP://50010000009403.J00101Z00119 || JPN || Dragon Quest Monsters: Terry no Wonderland 3D Nintendo Direct 2012.2.22 Video || JZ7J || 0004000000092F00
|-
| ESHOP://50010000009575.PEAALL000000 || EUR || Kid Icarus: Of Myths And Monsters (Virtual Console) || RBLP || 0004000000069500
|-
| ESHOP://50010000009846 || USA || Ketzal's Corridors || JELE || 0004000000083800
|}

* New QR Code for Japanese "Photos with Super Mario" has a different code string: ESHOP://50010000013120.J00108Z00001.CD588EAE95A3A68D15C647DA2AC0945FD88F70AB8A31149E51C4B05FB927B0B8

* There is a link in the Japanese eShop <nowiki>[http://www.nintendo.co.jp/3ds/eshop/qrCode.html?####]</nowiki> where you can replace the #### with the Japanese eShop title's serial and you will get it's QR code. (i.e. http://www.nintendo.co.jp/3ds/eshop/qrCode.html?JCAJ will get you the pushmo QR code)

* You could use Google's Chart API to create a QR code from the codes above: https://chart.googleapis.com/chart?chs=150x150&cht=qr&chl=ESHOP (replace the ESHOP text with the ESHOP:// link from one of the above)

== NS eShop application parameters ==
This section describes the 0x1C-byte structure stored at the application parameters from [[APT:StartApplication]], under the 0x300-byte buffer listed there.

{| class="wikitable"
|-
! Offset
! Size
! Description
|-
| 0x0
| 0x4
| Unknown, usually 0x3?
|-
| 0x4
| 0x4
| Unknown, usually 0x0?
|-
| 0x8
| 0x8
| u64 binary eShop content ID, same ID from the first string in eShop QR-codes except in binary form.
|-
| 0x10
| 0x10
| This is the last string from the QR-code(if any), no NUL-termination.
|}

== ExtData ==
The ExtData [[Extdata#Filesystem|File System]] for eShop is as follows:

root
├── icon
├── boss
│ └── TIGER100.tmp
└── user

{| class="wikitable" border="1"
|-
! File
! Details
! Size
! Firmware Introduced
! Plain text
|-
| icon
| Duplicate from application ExeFS. Always image 00000002
| 0x36C0 Bytes
| [[2.0.0-2]]
| [https://dl.dropboxusercontent.com/u/60710927/CTR/Sample/eShopExtdata/icon Download_EUR]
|-
| TIGER100.tmp
| Always image 00000003.
| 0xCE47 bytes (varies?)
| [[2.0.0-2]]
|
|}

== Music ==
The eShop pulls its music from a static, region-specific link in a format similar to the following:

https:// a248.e.akamai.net/f/248/103046/10m/npdl.c.app.nintendowifi.net/p01/nsa/CtfKXACbUPl8s7lk/BGM1/US_BGM1 ,
where region is one of the primary system regions (JP, US, EU, KR, etc.) Support also exists for 'BGM2', but this seems to be unused.
The music is held in a [[SpotPass|BOSS]] container.

The format consists of a brief XML header describing the audio (including the date it was set as the main eShop theme, loop times, size, etc) followed by a raw AAC stream. Tools such as FFmpeg can handle rebuilding this stream with ADTS headers for proper time info and such.

The [[Home_Menu|Home Menu]] uses nearly the same format for the Theme Shop's background music.

== URLs ==

eShop uses the following domains over HTTPS:

* cp3s-auth.c.shop.nintendowifi.net
* a248.e.akamai.net
* ninja.ctr.shop.nintendo.net
* samurai.ctr.shop.nintendo.net
* ccif.ctr.shop.nintendo.net
* eou.c.shop.nintendowifi.net

These domains are used by [[NIM_Services|NIM]]:

* nus.c.shop.nintendowifi.net
* ecs.c.shop.nintendowifi.net
* cas.c.shop.nintendowifi.net

ninja.ctr.shop.nintendo.net and samurai.ctr.shop.nintendo.net contain the bulk of the eShop information.

Requests with the following parameters will always return XML unless the header "Accept: application/json" is used, in which case JSON will be returned.

=== Common Parameters to ninja and samurai ===

For every request to the ninja and samurai servers, three parameters are always sent, though are not necessarily required:

{| class="wikitable" border="1"
|-
! Parameter
! Required
! Description
! Type
! Normal value
|-
| shop_id
| depends on the URL, usually no
| Describes which eShop instance should be used. 1 indicates the 3DS eShop, 2 indicates the Wii U eShop. 3 yields the same results as 2 but uses the img-eshop image server. 4 yields similar results as 3 but includes VC titles and updates, lacks image links for /titles and lacks release dates, prices and whether eShop and web sales are possible. For 4, links are given in both MP4 and Moflex formats for movies. Values greater than 4 or less than 1 are invalid. Defaults to 2 if not given.
| unsigned integer
| 1
|-
| lang
| no
| Describes the language. Seems to be an ISO 639-1 code in lower case. Every eShop region has a default language that is used if this parameter is not given. Some regions have multiple languages, such as CA (en and fr).
| string (two characters)
| depends on region and eShop settings; for US: en
|-
| _type
| no
| Describes whether the client wants to receive JSON or XML. This parameter seems actually unused and the servers always return XML.
| string
| json
|}

=== samurai ===

samurai.ctr.shop.nintendo.net (samurai) provides metadata about titles. The samurai server provides the backend for the eShop title search.

Common parameters described above can always be sent.

{| class="wikitable" border="1"
|-
! Path
! Description
! Parameters
|-
| /samurai/ws/'''region'''/titles
| Fetches the title list, containing the content id (not the 3DS title id), the product code and the localized title name
| All of these are optional.
* genre[]: genre ID (unsigned int)
* publisher[]: publisher ID (unsigned int)
* price_min: minimum price in region currency (signed int)
* price_max: maximum price in region currency (signed int)
* video_format: "moflex"
* freeword: keyword(s?) to look for (string)
* limit: maximum results
* offset: results to skip
* sort: one of "new", "popular" or "score"
* release_date_before: date/time title must have been released before (UNIX timestamp prefixed by +)
* release_date_after: date/time title must have been released after (UNIX timestamp prefixed by -)
|-
| /samurai/ws/'''region'''/news
| eShop news section
| (none)
|-
| /samurai/ws/'''region'''/telops
| Scrolling news on the top screen
| shop_id is required
|-
| /samurai/ws/'''region'''/directory/'''(long long unsigned int)''' and /samurai/ws/'''region'''/directory/~'''(string)'''
| Collections, like sales
| (none)
|-
| /samurai/ws/'''region'''/title/'''content id'''
| Returns information about the title, more verbose than /titles.
| (none)
|-
| /samurai/ws/'''region'''/demo/'''content id'''
| Returns information about a demo. Content ID is available in the main game's /title entry.
| (none)
|-
| /samurai/ws/'''region'''/contents
| Seems identical to /titles.
| see /titles
|-
| /samurai/ws/'''region'''/genres
| Returns a list of human-readable genre names and their corresponding genre id.
| (none)
|-
| /samurai/ws/'''region'''/publishers
| Returns a list of human-readable publisher names and their corresponding publisher id.
| (none)
|-
| /samurai/ws/'''region'''/platforms
| Returns a list of human-readable platform names and their corresponding platform id.
| (none)
|-
| /samurai/ws/'''region'''/title/'''content id'''/aocs
| Returns a list of add-on contents/downloadable content and prices in eShop region currency.
| (none)
|}

=== ninja ===

ninja.ctr.shop.nintendo.net (ninja) contains the seeds for the new 9.6 crypto, pricing information and handles actions that require authentication, such as purchases. Authentication information seems to be obtained from the [[ACT_Services|act:u sysmodule]] and works through OAuth2.

{| class="wikitable" border="1"
|-
! Path
! Description
! Parameters
|-
| /ninja/ws/'''region'''/title/'''content id'''/ec_info
| Contains information about the title. Such as title id, content size, and if available, the 9.6 crypto seed
| (none)
|-
| /ninja/ws/titles/id_pair
| Provides the content id for the given title id, or vice versa.
| title_id[] or ns_uid[] is required.
|-
| /ninja/ws/'''region'''/tax_locations
| Provides the tax location ID
| postal_code is required.
|-
| /ninja/ws/service_hosts
| Provides CCIF and Samurai servers
| country and shop_id is required.
|-
| /ninja/ws/country/'''region'''
| Various eshop related information for a given region
| (none)
|-
| /ninja/ws/country/'''region'''/replenish_amounts
| Provides the amounts of money you can replenish to your account.
| (none)
|}

=== Trusted Root CAs ===
The eShop application itself uses a [[HTTP_Services|RootCertChain]] for all HTTPS requests, all of the trusted root CAs are the following [[SSLC:RootCertChainAddDefaultCert|default]] ones:
* CertID 0x3
* CertID 0x6
* CertID 0x7
* CertID 0x8
* CertID 0x9
* CertID 0xA

=== Server changes following the November 2, 2015, maintenance ===
Pre-v10.0 eShop used an URL like this: "%s/samurai/ws/%s/title/%llu/other_purchased?shop_id=1&lang=%s&_type=json". That URL was removed with v10.0. That URL was requested when trying to load eShop app-pages. Following the maintenance mentioned above, this page was removed from the server, which broke pre-v10.0 eShop app whenever it tried to access that page.

URL changes between [[9.7.0-25]] and [[10.0.0-27]] are (green = add, red = remove):

%s/ninja/ws/%s/titles/online_prices?title%%5B%%5D=%s&lang=%s&include_coupon=true&shop_id=1&_type=json

%s/ninja/ws/%s/coupon/!check?shop_id=1&_type=json

%s/ninja/ws/my/owned_coupons?ns_uid=%llu&shop_id=1&_type=json

%s/ninja/ws/my/owned_coupons?shop_id=1&_type=json

%s/ninja/ws/my/parental_control/!put?shop_id=1&_type=json

%s/ninja/ws/%s/title/%llu/prepurchase_info?%s=%s&shop_id=1&_type=json

%s/samurai/ws/%s/coupon/%llu/titles?lang=%s&limit=%u&offset=%u&shop_id=1&_type=json

%s/ninja/ws/my/auto_billing/plans?limit=%u&offset=%u&shop_id=1&_type=json

%s/ninja/ws/%s/titles/online_prices?title%%5B%%5D=%s&lang=%s&include_coupon=true&coupon_id=%llu&shop_id=1&_type=json

%s/ninja/ws/my/auto_billing/%014llu/!cancel?shop_id=1&_type=json

%s/samurai/ws/%s/title/%llu/other_purchased?shop_id=1&lang=%s&_type=json

%s/samurai/movie/%s/%s/%014llu/moflex

==New3DS==
CheckNew3DS is called in two functions. This is only used for disabling UI button(s) for downloading New3DS titles when running on Old3DS. For example, on a New3DS patching a CheckNew3DS func-call with <retval=0>, results in the download button on the app page being grayed-out for a New3DS-only title.

==TitleID checks==
There's titleID checks in the system eShop application code for "Pokémon Omega Ruby". This appears to be used with UI-related code, unknown why.

3DS Userland Flaws

2016-04-30T20:55:43Z

Plailect:

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).

=Non-system applications=
{| class="wikitable" border="1"
|-
! Application name
! Summary
! Description
! Fixed in app/system version
! Last app/system version this flaw was checked for
! Timeframe info related to this was added to wiki
! Timeframe this vuln was discovered
! Vuln discovered by
|-
| Cubic Ninja
| Map-data stack smash
| See [[Ninjhax|here]] regarding Ninjhax.
| None
| App: Initial version. System: [[10.4.0-29]].
| Ninjhax release
| July 2014
| [[User:smea|smea]]
|-
| The Legend of Zelda: Ocarina of Time 3D
| UTF-16 name string buffer overflow via unchecked u8 length field
| 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.
* 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.
* 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).
* 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).

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].
| None
| App: Initial version. System: [[10.6.0-31]].
| March 11, 2015
| Around October 22, 2012
| [[User:Yellows8|Yellows8]]
|-
| Super Smash Bros 3DS
| Buffer overflow in local-multiplayer beacon handling.
| See [[smashbroshax|here]].
| App: v1.1.3
| See [[smashbroshax|here]]. System: [[10.3.0-28]].
| Time of exploit release.
| See [[smashbroshax|here]].
| [[User:Yellows8|Yellows8]]
|-
| Pokemon Super Mystery Dungeon
| Heap overflow within linear memory via unchecked save file length
| Pokemon Super Mystery Dungeon uses zlib compression for most of its save files, possibly due to the save files being larger than it's 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.
| None
| [[10.7.0-32]].
| Time of exploit release.
| April 14, 2016
| [[User:Shinyquagsire23|Shiny Quagsire]]
|-
| VVVVVV
| Buffer overflow in XML save file array parsing
| 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.
| None
| [[10.7.0-32]].
| Time of exploit release.
| April 25, 2016
| [[User:Shinyquagsire23|Shiny Quagsire]]
|}

==Useless crashes / applications which were fuzzed==
* 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.

* Pyramids (3DSWare), QR codes: no strings. Only crashes are from out-of-bounds values (like background ID) and are not exploitable.

* [https://github.com/yellows8/mm3d_re The Legend of Zelda: Majora's Mask 3D]

* "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.

* 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 it's allocation.

==Crashes needing investigation==
* Disney Infinity crashes when all savedata overwritten with /dev/urandom. No checksums. 0xFF bytes don't cause a crash.

* 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.

=System applications=
{| class="wikitable" border="1"
|-
! Summary
! Description
! Fixed in version
! Last version this flaw was checked for
! Timeframe this was discovered
! Discovered by
|-
| 3DS [[System Settings]] DS profile string stack-smash
| 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.
| [[7.0.0-13]]
| [[7.0.0-13]]
| 2012
| [[User:Ichfly|Ichfly]]
|}

=System applets=
{| class="wikitable" border="1"
|-
! Summary
! Description
! Fixed in version
! Last version this flaw was checked for
! Timeframe info related to this was added to wiki
! Timeframe this was discovered
! Discovered by
|-
| [[Home Menu]] [[System_SaveData|NAND-savedata]] Launcher.dat icons
| 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.

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).

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.

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.'''
| None
| [[10.3.0-28|10.3.0-X]]
|
| May 14, 2015
| [[User:Yellows8|Yellows8]]
|-
| [[Home Menu]] theme-data decompression buffer overflow ([[menuhax|themehax]])
| 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.

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.

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.

See also [[menuhax|here]].

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.
| [[10.2.0-28|10.2.0-X]]
| [[10.2.0-28|10.2.0-X]]
|
| December 22, 2014
| [[User:Yellows8|Yellows8]], [[User:Myria|Myria]] independently (~spring 2015)
|-
| [[Home Menu]] shuffle body-data buffer overflow ([[menuhax|shufflehax]])
| See [[menuhax|here]].
| [[10.6.0-31|10.6.0-X]]
| [[10.6.0-31|10.6.0-X]]
|
| January 3, 2015
| [[User:Yellows8|Yellows8]]
|-
| Webkit/web-browser bugs
| spider has had at least three different code-execution exploits. Majority of them are use-after-free issues. See also [[browserhax|here]].
|
|
| 2013?
|
| A lot of people.
|-
| Old3DS/New3DS [[Internet_Browser|Browser-version-check]] bypass
| 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}".
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.

See [http://yls8.mtheall.com/3dsbrowserhax.php here] for bypass usage instructions.

This was fixed with [[10.7.0-32|10.7.0-32]], see [[Internet_Browser|here]] for details.
| [[10.7.0-32|10.7.0-32]]
|
| February 25, 2016
| November 2, 2015 (Exactly one week after the browser version pages were initially updated server-side)
| [[User:Yellows8|Yellows8]]
|}

==Useless crashes==
Old3DS system web-browser:
* 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.

* 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).

* 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.

OTP Registers

2016-03-15T00:17:10Z

Plailect: fine

Console-unique keys seem to be derived from here, though it is unknown how. Access to this region is disabled once the ARM9 writes 0x2 to [[CONFIG|REG_SYSPROT9]].

This is very likely the console-unique data store, including [[CTCert]] and other unit info values, that ends up in ITCM at 0x01FFB800. Bootrom would decrypt it, check for magic (0xDEADB00F), and then set CFG_UNITINFO, etc to match the specific console at hand. This is a guess based on the matching size of both sets of data (ITCM's is padded to 0x100, specifically) and the lack of another known source for this data on the system (it is not sourced from eMMC). On top of this, the latter half of this data is likely used as console-unique keydata, thus explaining ITCM's copy being memcleared and the OTP lock mechanism existing.

On [[FIRM]] versions prior to [[3.0.0-6|3.0.0-X]], this region was left unprotected. On versions since [[3.0.0-6|3.0.0-X]], this has been fixed, and the region disable is now done by Kernel9 after doing console-unique TWL keyinit, by setting bit 1 of [[CONFIG|REG_SYSPROT9]]. However, with the [[New_3DS]] FIRM ARM9 binary this is now done in the [[FIRM]] ARM9 binary loader, which also uses the 0x10012000 region for New 3DS key generation.

On development units ([[CONFIG|UNITINFO]]!=0) ARM9 uses the first 8-bytes from 0x10012000 for the TWL Console ID. This region doesn't seem to be used by NATIVE_FIRM on retail at all, besides New3DS key-generation in the [[FIRM|ARM9-loader]]. It is unknown if bootrom reads from it, but it is likely.

{| class="wikitable" border="1"
! Offset
! Size
! Description
|-
| 0x0
| 0x100
| Console-unique data. This data appears to be random, even when multiple consoles' dumps from this area are XORed. None of the raw data here seems to match any of the console-unique keys (tested: keyX, keyY and normal-key, both big and little u32 endianness for all keyslots) for the AES engine. It's unknown whether there's any encryption on this area.
|-
| 0x100
| 0x8
| Before writing REG_SYSPROT9 bit1, the ARM9 copies the 8-byte TWL Console ID here. This sets the registers at 0x4004D00 for ARM7.
|}

OTP Registers

2016-03-15T00:01:01Z

Plailect: if we're going by firm version rather than system version we may as well be specific

Console-unique keys seem to be derived from here, though it is unknown how. Access to this region is disabled once the ARM9 writes 0x2 to [[CONFIG|REG_SYSPROT9]].

This is very likely the console-unique data store, including [[CTCert]] and other unit info values, that ends up in ITCM at 0x01FFB800. Bootrom would decrypt it, check for magic (0xDEADB00F), and then set CFG_UNITINFO, etc to match the specific console at hand. This is a guess based on the matching size of both sets of data (ITCM's is padded to 0x100, specifically) and the lack of another known source for this data on the system (it is not sourced from eMMC). On top of this, the latter half of this data is likely used as console-unique keydata, thus explaining ITCM's copy being memcleared and the OTP lock mechanism existing.

On [[FIRM]] versions prior to 2.32-15 ([[3.0.0-6|3.0.0-X]]), this region was left unprotected. On versions since 2.32-15 ([[3.0.0-6|3.0.0-X]]) this has been fixed, and the region disable is now done by Kernel9 after doing console-unique TWL keyinit, by setting bit 1 of [[CONFIG|REG_SYSPROT9]]. However, with the [[New_3DS]] FIRM ARM9 binary this is now done in the [[FIRM]] ARM9 binary loader, which also uses the 0x10012000 region for New 3DS key generation.

On development units ([[CONFIG|UNITINFO]]!=0) ARM9 uses the first 8-bytes from 0x10012000 for the TWL Console ID. This region doesn't seem to be used by NATIVE_FIRM on retail at all, besides New3DS key-generation in the [[FIRM|ARM9-loader]]. It is unknown if bootrom reads from it, but it is likely.

{| class="wikitable" border="1"
! Offset
! Size
! Description
|-
| 0x0
| 0x100
| Console-unique data. This data appears to be random, even when multiple consoles' dumps from this area are XORed. None of the raw data here seems to match any of the console-unique keys (tested: keyX, keyY and normal-key, both big and little u32 endianness for all keyslots) for the AES engine. It's unknown whether there's any encryption on this area.
|-
| 0x100
| 0x8
| Before writing REG_SYSPROT9 bit1, the ARM9 copies the 8-byte TWL Console ID here. This sets the registers at 0x4004D00 for ARM7.
|}

OTP Registers

2016-03-14T20:37:59Z

Plailect: clarity

Console-unique keys seem to be derived from here, though it is unknown how. Access to this region is disabled once the ARM9 writes 0x2 to [[CONFIG|REG_SYSPROT9]].

This is very likely the console-unique data store, including [[CTCert]] and other unit info values, that ends up in ITCM at 0x01FFB800. Bootrom would decrypt it, check for magic (0xDEADB00F), and then set CFG_UNITINFO, etc to match the specific console at hand. This is a guess based on the matching size of both sets of data (ITCM's is padded to 0x100, specifically) and the lack of another known source for this data on the system (it is not sourced from eMMC). On top of this, the latter half of this data is likely used as console-unique keydata, thus explaining ITCM's copy being memcleared and the OTP lock mechanism existing.

On versions <[[3.0.0-6|3.0.0-X]], the [[OTP Registers|0x10012000]]-region was left unprotected. On versions >[[3.0.0-6|3.0.0-X]], the console-unique TWL keyinit + region disable was done by Kernel9 setting bit 1 of [[CONFIG|REG_SYSPROT9]]. However, with the [[New_3DS]] FIRM ARM9 binary this is now done in the [[FIRM]] ARM9 binary loader, which also uses the 0x10012000 region for key generation.

On development units ([[CONFIG|UNITINFO]]!=0) ARM9 uses the first 8-bytes from 0x10012000 for the TWL Console ID. This region doesn't seem to be used by NATIVE_FIRM on retail at all, besides New3DS key-generation in the [[FIRM|ARM9-loader]]. It is unknown if bootrom reads from it, but it is likely.

{| class="wikitable" border="1"
! Offset
! Size
! Description
|-
| 0x0
| 0x100
| Console-unique data. This data appears to be random, even when multiple consoles' dumps from this area are XORed. None of the raw data here seems to match any of the console-unique keys (tested: keyX, keyY and normal-key, both big and little u32 endianness for all keyslots) for the AES engine. It's unknown whether there's any encryption on this area.
|-
| 0x100
| 0x8
| Before writing REG_SYSPROT9 bit1, the ARM9 copies the 8-byte TWL Console ID here. This sets the registers at 0x4004D00 for ARM7.
|}

3DS System Flaws

2016-03-14T18:00:49Z

Plailect: /* arm9loader */

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]].

=Stale / Rejected Efforts=
* 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.

* Someone (who will remain unnamed) has released CFW and CIA installers, all of which is copied from the work of others, or copyrighted material.

==Tips and info==
The 3DS uses the XN feature of the ARM11 processor. There's no official way from applications to enable executable permission for memory containing arbitrary unsigned code(there's a [[SVC]] for this, but only [[RO_Services|RO-module]] has access to it). An usable userland exploit would still be useful: you could only do return-oriented-programming with it initially. From ROP one could then exploit system flaw(s), see below.

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).

=System flaws=
== Hardware ==
{| class="wikitable" border="1"
! Summary
! Description
! Fixed with hardware model/revision
! Newest hardware model/revision this flaw was checked for
! Timeframe this was discovered
! Discovered by
|-
| ARM9/ARM11 bootrom vectors point at unitialized RAM
| 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.
Since RAM isn't cleared on boot (see below), one can immediately start execution of their own code here to dump bootrom, OTP, etc.
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.

This requires *very* *precise* timing for triggering the hardware fault: it's unknown if anyone actually exploited this successfully at the time of writing(the one who attempted+discovered it *originally* as listed in this wiki section hasn't).
| None: all available 3DS models at the time of writing have the exact same ARM9/ARM11 bootrom for the unprotected areas.
| New3DS
| End of February 2014
| [[User:Derrek|derrek]], WulfyStylez (May 2015) independently
|-
| Missing AES key clearing
| The hardware AES engine does not clear keys when doing a hard reset/reboot.
| None
| New3DS
| August 2014
| Mathieulh/Others
|-
| No RAM clearing on reboots
| On an MCU-triggered reboot all RAM including FCRAM/ARM9 memory/AXIWRAM/VRAM keeps its contents.
| None
| New3DS
| March 2014
| [[User:Derrek|derrek]]
|-
| 32bits of actual console-unique TWLNAND keydata
| 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.
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).
| None
| New3DS
| 2012?
| [[User:Yellows8|Yellows8]]
|-
| DSi / 3DS-TWL key-generator
| 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.
This applies to the keyX/keyY too.

This attack does not work for the 3DS key-generator because keyslots 0-3 are only for TWL keys.
| None
| New3DS
| 2011
| [[User:Yellows8|Yellows8]]
|-
| 3DS key-generator
| 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.

Several such pairs of matching normal-keys and KeyY values were found, leading to deducing the key-generator function.
| None
| New3DS
| February 2015
| [[User:Yellows8|Yellows8]], [[User:Plutooo|plutoo]]
|-
| FIRM partitions known-plaintext
| 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.

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).

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.
| None
| New3DS
|
| Everyone
|}

== ARM9 software ==
=== arm9loader ===
{| class="wikitable" border="1"
|-
! Summary
! Description
! Successful exploitation result
! Fixed in [[FIRM]] system version
! Last [[FIRM]] system version this flaw was checked for
! Timeframe this was discovered
! Public disclosure timeframe
! Discovered by
|-
| Uncleared OTP hash keydata in console-unique 0x11 key-generation
| 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.

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.

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]].

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.
| Derivation of all New3DS keys generated via the NAND keystore (0x1B "Secure4" etc.)
| None
| [[10.4.0-29|10.4.0-X]]
| ~April 2015, implemented in May 2015
| 13 January 2016
| [[User:WulfyStylez|WulfyStylez]], [[User:Dazzozo|Dazzozo]], [[User:Shinyquagsire23|shinyquagsire23]] (complimentary + implemented), [[User:Plutooo|plutoo]], Normmatt (discovered independently)
|-
| enhanced-arm9loaderhax
| See the 32c3 3ds talk.
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 (System Update firm partition writes can be blocked by patching System calls at boot time). 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.
| arm9loaderhax which automatically occurs at hard-boot.
| See arm9loaderhax / description.
| See arm9loaderhax / description.
| Theorized around mid July, 2015. Later implemented+tested by [[User:Plutooo|plutoo]] and derrek.
| 32c3 3ds talk (December 27, 2015)
| [[User:Yellows8|Yellows8]]
|-
| Missing verification-block for the 9.6 keys (arm9loaderhax)
| 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.

Writing an incorrect key to NAND will cause arm9loader to decrypt the ARM9 kernel as garbage and then jump to it.

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.

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.

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.
| Recovery of 6.x [[Savegames#6.0.0-11_Savegame_keyY|save key]]/7.x [[NCCH]] key
| None
| [[10.4.0-29|10.4.0-X]]
| March, 2015
|
| [[User:Plutooo|plutoo]]
|-
| Uncleared New3DS keyslot 0x11
| 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.
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.

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]].
| New3DS keyXs generation
| 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]].
|
| February 3, 2015 (one day after [[9.5.0-22|9.5.0-X]] release)
|
| [[User:Yellows8|Yellows8]]
|}

=== Process9 ===
{| class="wikitable" border="1"
|-
! Summary
! Description
! Successful exploitation result
! Fixed in [[FIRM]] system version
! Last [[FIRM]] system version this flaw was checked for
! Timeframe this was discovered
! Public disclosure timeframe
! Discovered by
|-
| Leak of normal-key matching a key-scrambler key
| 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.

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.
| Deducing the keyX for keyslot 0x39 and the key scrambler algorithm
| New 3DS [[9.3.0-21|9.3.0-X]], sort of
| [[10.0.0-27|10.0.0-X]]
| Sometime in 2015 after the hardware key-generator was broken.
| 32c3 3ds talk (December 27, 2015)
| [[User:Yellows8|Yellows8]]
|-
| Leak of normal-key matching a key-generator key
| 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.

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.

Note the devkit key-generator was discovered to be the same as the retail key-generator.
| Deducing the keyX for keyslot 0x3D and hardware key-generator algorithm. Generate remaining devkit common-keys.
| pre-[[1.0.0-0|1.0.0-X]]
|
| Shortly after the key-generator was revealed to be flawed at the 32c3 3ds talk
| January 20, 2016
| [[User:Jakcron|jakcron]]
|-
| ntrcardhax
|
| ARM9 code execution
| None
| [[10.3.0-28|10.3.0-X]]
| March 2015
| 32c3 3ds talk (December 27, 2015)
| [[User:Plutooo|plutoo]]
|-
| Title downgrading via [[Application_Manager_Services|AM]]([[Application_Manager_Services_PXI|PXI]])
| 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.

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.
| Bypassing title version check at installation, which then allows downgrading any title.
| None
| NATIVE_FIRM / AM-sysmodule [[10.0.0-27|10.0.0-X]]
| ?
|
| ?
|-
| FAT FS code null-deref
| 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.

Sample "fsck.vfat -n -v -V <fat image backup>" output for the above crash:

<pre>...
Starting check/repair pass.
<FilePath0> and
<FilePath1>
share clusters.
Truncating second to 3375104 bytes.
<FilePath1>
File size is 2787392 bytes, cluster chain length is 16384 bytes.
Truncating file to 16384 bytes.
Checking for unused clusters.
Reclaimed 1 unused cluster (16384 bytes).
Checking free cluster summary.
Free cluster summary wrong (1404490 vs. really 1404491)
Auto-correcting.
Starting verification pass.
Checking for unused clusters.
Leaving filesystem unchanged.</pre>
| Useless null-based-read
| None
| [[9.6.0-24|9.6.0-X]]
| July 8-9, 2015
|
| [[User:Yellows8|Yellows8]]
|-
| RSA signature padding checks
| The TWL_FIRM RSA sig padding check code used for all TWL RSA sig-checks has issues, see [[FIRM|here]].
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.
|
| None
| [[9.5.0-22|9.5.0-X]]
| March 2015
|
| [[User:Yellows8|Yellows8]]
|-
| [[AMPXI:ValidateDSiWareSectionMAC]] [[AES_Registers|AES]] keyslot reuse
| 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.
This is basically a different form of the pxips9 keyslot vuln, except with AESMAC etc.
| See description.
| None
| [[10.2.0-28|10.2.0-X]]
| March 15, 2015
| December 29, 2015
| [[User:Yellows8|Yellows8]]
|-
| pxips9 [[AES_Registers|AES]] keyslot reuse
| 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).
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.
| Reusing the previously used keyslot, for crypto with PS.
| None
| [[10.2.0-28|10.2.0-X]]
| Roughly the same time(same day?) as firmlaunch-hax.
| December 29, 2015
| [[User:Yellows8|Yellows8]]
|-
| firmlaunch-hax: FIRM header ToCToU
| This can't be exploited from ARM11 userland.
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.
With [[9.5.0-22]] the address of this FIRM header was changed from a FCRAM address, to ARM9-only address 0x01fffc00.
| ARM9 code execution
| [[9.5.0-22]]
|
| 2012, 3 days after [[User:Yellows8|Yellows8]] started Process9 code RE.
|
| [[User:Yellows8|Yellows8]]
|-
| Uninitialized data output for (PXI) command replies
| 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.
Certain ARM11 service commands have this same issue as well.
|
| None
| [[9.3.0-21|9.3.0-X]]
| ?
|
| [[User:Yellows8|Yellows8]]
|-
| [[Filesystem_services_PXI|FSPXI]] OpenArchive SD permissions
| Process9 does not use the exheader ARM9 access-mount permission flag for SD at all.
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.
|
| None
| [[9.3.0-21|9.3.0-X]]
| 2012
|
| [[User:Yellows8|Yellows8]]
|-
| [[AMPXI:ExportDSiWare]] export path
| 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>".
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.
| 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.
| None
| [[9.5.0-22]]
| April 2013
|
| [[User:Yellows8|Yellows8]]
|-
| [[DSiWare_Exports]] [[CTCert]] verification
| 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.
On 3DS however this is rather useless, due to the entire DSiWare .bin being encrypted with the console-unique movable.sed keyY.
| 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.
| Unknown, probably none.
| ?
| April 2013
|
| [[User:Yellows8|Yellows8]]
|-
| [[Gamecard_Services_PXI]] unchecked REG_CTRCARDCNT transfer-size
| 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).
| Out-of-bounds read for a value which gets written to a register.
| [[5.0.0-11|5.0.0-X]]
|
| 2013?
|
| [[User:Yellows8|Yellows8]]
|-
| [[PXI_Registers|PXI]] cmdbuf buffer overrun
| 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.
| Probably ARM9 code execution
| [[5.0.0-11|5.0.0-11]]
|
| March 2015, original timeframe if any unknown
|
| [[User:Plutooo|plutoo]]/[[User:Yellows8|Yellows8]]/maybe others(?)
|-
| [[Application_Manager_Services_PXI|PXIAM]] command 0x003D0108(See also [[Application_Manager_Services|this]])
| 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.
| ARM9 code execution
| [[5.0.0-11|5.0.0-X]]
|
| May 2013
|
| [[User:Yellows8|Yellows8]]
|-
| [[Process_Services_PXI|PS RSA]] commands buffer overflows
| 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.
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]].
| ARM9 code execution
| [[5.0.0-11|5.0.0-X]]
|
| 2012
|
| [[User:Yellows8|Yellows8]]
|-
| [[PXI_Registers|PXI]] pxi_id bad check
| The Process9 code responsible for [[PXI_Registers|PXI]] communications read pxi_id as a signed char. There were two flaws:
* They used it as index to a lookup-table without checking the value at all.
* Another function verified that pxi_id < 7, allowing negative values to pass the check. This would also cause an out-of-range table-lookup.
| Maybe ARM9 code execution
| [[3.0.0-5|3.0.0-5]]
|
| March 2015, originally 2012 for the first issue at least
|
| [[User:Plutooo|plutoo]], [[User:Yellows8|Yellows8]], maybe others(?)
|}

=== Kernel9 ===
{| class="wikitable" border="1"
|-
! Summary
! Description
! Successful exploitation result
! Fixed in [[FIRM]] system version
! Last [[FIRM]] system version this flaw was checked for
! Timeframe this was discovered
! Discovered by
|-
| [[CONFIG Registers#CFG_SYSPROT9|CFG_SYSPROT9]] bit1 not set by Kernel9
| Old versions of Kernel9 never set bit1 of [[CONFIG Registers#CFG_SYSPROT9|CFG_SYSPROT9]] and instead blocked access to the [[OTP Registers|OTP Registers]] itself, presumably under the assumption that an attacker would never gain code execution under Kernel9. This leaves the [[OTP Registers|0x10012000]]-region unprotected (this region should be locked early during boot!) to an attacker with sufficient privileges. Since it's never locked, you can dump it once you get ARM9 code execution.

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).

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.
| Dumping of the [[OTP Registers|OTP]] area
| [[3.0.0-5|3.0.0-X]]
|
| February 2015
| [[User:Plutooo|plutoo]], Normmatt independently, [[User:Plailect|Plailect]] (hardware-less public implementation)
|}

== ARM11 software ==
=== Kernel11 ===
{| class="wikitable" border="1"
|-
! Summary
! Description
! Successful exploitation result
! Fixed in [[FIRM]] system version
! Last [[FIRM]] system version this flaw was checked for
! Timeframe this was discovered
! Discovered by
|-
| [[SVC]] table too small
| 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.

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.
|
| None
| [[10.2.0-28|10.2.0-X]]
| 2012
| Everyone
|-
| [[SVC|svcBackdoor (0x7B)]]
| This backdoor allows executing SVC-mode code at the user-specified code-address. This is used by Process9, using this on the ARM11(with NATIVE_FIRM) requires patching the kernel .text or modifying SVC-access-control.
| See description
| None
| [[10.2.0-28|10.2.0-X]]
|
| Everyone
|-
| [[Memory_layout#ARM11_Detailed_virtual_memory_map|0xEFF00000]] / 0xDFF00000 ARM11 kernel virtual-memory
| 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.
|
| None
| [[10.2.0-28|10.2.0-X]]
|
|
|-
| Memchunkhax2
|
| ARM11 kernel code execution
| [[10.4.0-29|10.4.0-X]] (partially)
| [[10.4.0-29|10.4.0-X]]
|
| derrek
|-
| AffinityMask/processorid validation
| 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.
The original code with the first 3 did the following:
* if(u32_processorcount > ~0x80000001)return 0xe0e01bfd;
* if(s32_processorcount > <total_cores>)return 0xd8e007fd;
The following code replaced the above:
* if(u32_processorcount >= <total_cores+1>)return 0xd8e007fd;
In theory the latter should catch everything that the former did, so it's unknown if this was really a security issue.

The svcCreateThread changes with [[10.0.0-27|10.0.0-X]] definitely did fix a security issue.
* Original code: "if(s32_processorid > <total_cores>)return 0xd8e007fd;"
* New code: "if(s32_processorid >= <total_cores> || s32_processorid <= -4)return 0xd8e007fd;"
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:
* Old3DS: Useless kernel-mode crash due to accessing unmapped memory.
* 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).
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)).
| Nothing useful
| [[10.0.0-27|10.0.0-X]]
| [[10.0.0-27|10.0.0-X]]
| svcCreateThread issue: May 31, 2015. The rest: September 8, 2015, via v9.6->v10.0 ARM11-kernel code-diff.
| [[User:Yellows8|Yellows8]]
|-
| memchunkhax
| 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.

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.

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.
| When combined with other flaws: ARM11-kernelmode code execution
| [[9.3.0-21|9.3.0-21]]
|
| February 2014
| [[User:Yellows8|Yellows8]]
|-
| Multiple [[KLinkedListNode|KLinkedListNode]] SlabHeap use after free bugs
| 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:
SlabHeap_free(KLinkedListNode);
KObject *obj = KLinkedListNode->key; // the object there might have changed!
This bug appeared all over the place.
| ARM11-kernelmode code exec maybe
| [[8.0.0-18|8.0.0-18]]
|
| April 2015
| [[User:Derrek|derrek]]
|-
| PXI [[RPC_Command_Structure|Command]] input/output buffer permissions
| 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.
|
| [[6.0.0-11|6.0.0-11]]
|
| 2012
| [[User:Yellows8|Yellows8]]
|-
| [[SVC|svcStartInterProcessDma]]
| For svcStartInterProcessDma, the kernel code had the following flaws:

* 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.

* Integer overflows for srcaddr+size and dstaddr+size are now checked(with [[6.0.0-11]]), which were not checked before.

* 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).
|
| [[6.0.0-11]]
|
| DmaConfig issue: unknown. The rest: 2014
| [[User:Plutooo|plutoo]], [[User:Yellows8|Yellows8]] independently
|-
| [[SVC|svcControlMemory]] Parameter checks
| For svcControlMemory the parameter check had these two flaws:

* 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.

* Integer overflows on (addr0+size) are now checked that previously weren't (this also applies to most other address checks elsewhere in the kernel).

|
| [[5.0.0-11]]
|
|
| [[User:Plutooo|plutoo]]
|-
| [[RPC_Command_Structure|Command]] request/response buffer overflow
| 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.

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.
|
| [[5.0.0-11]]
|
| v4.1 FIRM -> v5.0 code diff
| [[User:Yellows8|Yellows8]]
|-
| [[SVC|SVC stack allocation overflows]]
|
* 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.
* The alignment (size+7)&~7 calculation before allocation was not checked for integer overflow.

This might allow for ARM11 kernel code-execution.

(Applies to svcSetResourceLimitValues, svcGetThreadList, svcGetProcessList, svcReplyAndReceive, svcWaitSynchronizationN.)
|
| [[5.0.0-11]]
|
| v4.1 FIRM -> v5.0 code diff
| [[User:Plutooo|plutoo]], [[User:Yellows8|Yellows8]] complementary
|-
| [[SVC|svcControlMemory]] MemoryOperation MAP memory-permissions
| 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.
|
| [[4.1.0-8]]
|
| 2012
| [[User:Yellows8|Yellows8]]
|-
| [[RPC_Command_Structure|Command]] input/output buffer permissions
| 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.
|
| [[4.0.0-7]]
|
| 2012
| [[User:Yellows8|Yellows8]]
|-
| [[SVC|svcReadProcessMemory/svcWriteProcessMemory memory]] permissions
| 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.
|
| [[4.0.0-7]]
|
| 2012?
| [[User:Yellows8|Yellows8]]
|}

=== [[FIRM]] Sysmodules ===
{| class="wikitable" border="1"
|-
! Summary
! Description
! Successful exploitation result
! Fixed in [[FIRM]] system version
! Last [[FIRM]] system version this flaw was checked for
! Timeframe this was discovered
! Discovered by
|-
| [[Services|"srv:pm"]] process registration
| 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.

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.

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).
| Access to arbitrary services
| [[7.0.0-13]]
|
| 2012
| [[User:Yellows8|Yellows8]]
|-
| FSDIR null-deref
| [[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.
|
| None
| [[9.6.0-24|9.6.0-X]]
| May 19(?)-20, 2015
| [[User:Yellows8|Yellows8]]
|}

=== Standalone Sysmodules ===
{| class="wikitable" border="1"
|-
! Summary
! Description
! Successful exploitation result
! Fixed in system-module system-version
! Last system-module system-version this flaw was checked for
! Timeframe this was discovered
! Timeframe this was added to wiki
! Discovered by
|-
| [[IR_Services|IR]]: Stack buffer overflow with custom hardware
| 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.

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.
| ROP under IR sysmodule.
| [[10.6.0-31|10.6.0-31]]
|
| February 23, 2016 (Unknown if it was noticed before then)
| February 23, 2016
| [[User:Yellows8|Yellows8]]
|-
| [[NIM_Services|NIM]]: Downloading old title-versions from eShop
| 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.
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).

Originally this was tested with a debugging-system via modded-FIRM, eventually smea implemented it in HANS for the 32c3 release.
| Downloading old title-versions from eShop
| None
| [[10.0.0-27|10.0.0-X]]
| October 24, 2015 (Unknown when exactly the first eShop title downgrade was actually tested, maybe November)
| January 7, 2016 (Same day Ironfall v1.0 was removed from CDN via the main-CXI files)
| [[User:Yellows8|Yellows8]]
|-
| [[SPI_Services|SPI]] service out-of-bounds write
| cmd1 has out-of-bounds write allowing overwrite of some static variables in .data.
|
| None
| [[9.5.0-22]]
| March 2015
|
| [[User:Plutooo|plutoo]]
|-
| [[NFC_Services|NFC]] module service command buf-overflows
| 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....>.
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.

There's no known retail titles which have access to either of these services.
| ROP under NFC module.
| New3DS: None
| New3DS: [[9.5.0-22]]
| December 2014?
|
| [[User:Yellows8|Yellows8]]
|-
| [[News_Services|NEWSS]] service command notificationID validation failure
| 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).
| ROP under news module.
| None
| [[9.7.0-25|9.7.0-X]]
| December 2014
|
| [[User:Yellows8|Yellows8]]
|-
| [[NWMUDS:DecryptBeaconData]] heap buffer overflow
| 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.

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.

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.
| 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.
| None
| [[9.0.0-20]]
| ~September 23, 2014(see the [[NWMUDS:DecryptBeaconData]] page history)
| August 3, 2015
| [[User:Yellows8|Yellows8]]
|-
| [[HID_Services|HID]] module shared-mem
| 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.
| ROP under HID module, but this is *very* unlikely to be exploitable since the data written is HID data.
| None
| [[9.3.0-21]]
| 2014?
|
| [[User:Yellows8|Yellows8]]
|-
| gspwn
| 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).

FCRAM is gpu-accessible up to physaddr 0x26800000 on Old3DS, and 0x2DC00000 on New3DS. This is BASE_memregion_start(aka SYSTEM_memregion_end)-0x400000 with the default memory-layout on Old3DS/New3DS.
| User-mode code execution.
| None
| [[9.6.0-24|9.6.0-X]]
| Early 2014
|
| smea, [[User:Yellows8|Yellows8]]/others before then
|-
| rohax
| 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.

This was fixed after [[ninjhax]] release by adding checks on [[CRO0]]-based pointers before writing to them.
| Memory-mapping syscalls.
| [[9.3.0-21]]
| [[9.4.0-21]]
|
|
| smea, [[User:Plutooo|plutoo]] joint effort
|-
| Region free
| 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.
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]].
| Launching gamecards from any region + bypassing Home Menu gamecard-sysupdate installation
| None
| Last tested with [[10.1.0-27|10.1.0-X]].
| June(?) 2014
|
| [[User:Yellows8|Yellows8]]
|-
| [[NWM_Services|NWM]] service-cmd state null-ptr deref
| 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.
It's unknown whether any NWM services besides NWMUDS have this issue.
| This is rather useless since it's only a crash caused by a state ptr based at 0x0.
| None
| [[9.0.0-20]]
| 2013?
|
| [[User:Yellows8|Yellows8]]
|}

=== General/CTRSDK ===
{| class="wikitable" border="1"
|-
! Summary
! Description
! Successful exploitation result
! Fixed in version
! Last version this flaw was checked for
! Timeframe this was discovered
! Discovered by
|-
| [[NWM_Services|UDS]] beacon additional-data buffer overflow
| 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.
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.

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).

The maximum number of bytes that can be written beyond the end of the outbuf is 0x37-bytes, with additionaldata_size=0xFF.
| Perhaps ROP, very difficult if possible with anything at all
| ?
|
| September(?) 2014
| [[User:Yellows8|Yellows8]]
|}

3DS System Flaws

2016-03-14T17:51:25Z

Plailect: /* Kernel9 */

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]].

=Stale / Rejected Efforts=
* 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.

* Someone (who will remain unnamed) has released CFW and CIA installers, all of which is copied from the work of others, or copyrighted material.

==Tips and info==
The 3DS uses the XN feature of the ARM11 processor. There's no official way from applications to enable executable permission for memory containing arbitrary unsigned code(there's a [[SVC]] for this, but only [[RO_Services|RO-module]] has access to it). An usable userland exploit would still be useful: you could only do return-oriented-programming with it initially. From ROP one could then exploit system flaw(s), see below.

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).

=System flaws=
== Hardware ==
{| class="wikitable" border="1"
! Summary
! Description
! Fixed with hardware model/revision
! Newest hardware model/revision this flaw was checked for
! Timeframe this was discovered
! Discovered by
|-
| ARM9/ARM11 bootrom vectors point at unitialized RAM
| 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.
Since RAM isn't cleared on boot (see below), one can immediately start execution of their own code here to dump bootrom, OTP, etc.
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.

This requires *very* *precise* timing for triggering the hardware fault: it's unknown if anyone actually exploited this successfully at the time of writing(the one who attempted+discovered it *originally* as listed in this wiki section hasn't).
| None: all available 3DS models at the time of writing have the exact same ARM9/ARM11 bootrom for the unprotected areas.
| New3DS
| End of February 2014
| [[User:Derrek|derrek]], WulfyStylez (May 2015) independently
|-
| Missing AES key clearing
| The hardware AES engine does not clear keys when doing a hard reset/reboot.
| None
| New3DS
| August 2014
| Mathieulh/Others
|-
| No RAM clearing on reboots
| On an MCU-triggered reboot all RAM including FCRAM/ARM9 memory/AXIWRAM/VRAM keeps its contents.
| None
| New3DS
| March 2014
| [[User:Derrek|derrek]]
|-
| 32bits of actual console-unique TWLNAND keydata
| 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.
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).
| None
| New3DS
| 2012?
| [[User:Yellows8|Yellows8]]
|-
| DSi / 3DS-TWL key-generator
| 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.
This applies to the keyX/keyY too.

This attack does not work for the 3DS key-generator because keyslots 0-3 are only for TWL keys.
| None
| New3DS
| 2011
| [[User:Yellows8|Yellows8]]
|-
| 3DS key-generator
| 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.

Several such pairs of matching normal-keys and KeyY values were found, leading to deducing the key-generator function.
| None
| New3DS
| February 2015
| [[User:Yellows8|Yellows8]], [[User:Plutooo|plutoo]]
|-
| FIRM partitions known-plaintext
| 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.

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).

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.
| None
| New3DS
|
| Everyone
|}

== ARM9 software ==
=== arm9loader ===
{| class="wikitable" border="1"
|-
! Summary
! Description
! Successful exploitation result
! Fixed in [[FIRM]] system version
! Last [[FIRM]] system version this flaw was checked for
! Timeframe this was discovered
! Public disclosure timeframe
! Discovered by
|-
| Uncleared OTP hash keydata in console-unique 0x11 key-generation
| 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.

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.

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]].

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.
| Derivation of all New3DS keys generated via the NAND keystore (0x1B "Secure4" etc.)
| None
| [[10.4.0-29|10.4.0-X]]
| ~April 2015, implemented in May 2015
| 13 January 2016
| [[User:WulfyStylez|WulfyStylez]], [[User:Dazzozo|Dazzozo]], [[User:Shinyquagsire23|shinyquagsire23]] (complimentary + implemented), [[User:Plutooo|plutoo]], Normmatt (discovered independently)
|-
| enhanced-arm9loaderhax
| See the 32c3 3ds talk.
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.
| arm9loaderhax which automatically occurs at hard-boot.
| See arm9loaderhax / description.
| See arm9loaderhax / description.
| Theorized around mid July, 2015. Later implemented+tested by [[User:Plutooo|plutoo]] and derrek.
| 32c3 3ds talk (December 27, 2015)
| [[User:Yellows8|Yellows8]]
|-
| Missing verification-block for the 9.6 keys (arm9loaderhax)
| 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.

Writing an incorrect key to NAND will cause arm9loader to decrypt the ARM9 kernel as garbage and then jump to it.

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.

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.

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.
| Recovery of 6.x [[Savegames#6.0.0-11_Savegame_keyY|save key]]/7.x [[NCCH]] key
| None
| [[10.4.0-29|10.4.0-X]]
| March, 2015
|
| [[User:Plutooo|plutoo]]
|-
| Uncleared New3DS keyslot 0x11
| 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.
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.

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]].
| New3DS keyXs generation
| 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]].
|
| February 3, 2015 (one day after [[9.5.0-22|9.5.0-X]] release)
|
| [[User:Yellows8|Yellows8]]
|}

=== Process9 ===
{| class="wikitable" border="1"
|-
! Summary
! Description
! Successful exploitation result
! Fixed in [[FIRM]] system version
! Last [[FIRM]] system version this flaw was checked for
! Timeframe this was discovered
! Public disclosure timeframe
! Discovered by
|-
| Leak of normal-key matching a key-scrambler key
| 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.

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.
| Deducing the keyX for keyslot 0x39 and the key scrambler algorithm
| New 3DS [[9.3.0-21|9.3.0-X]], sort of
| [[10.0.0-27|10.0.0-X]]
| Sometime in 2015 after the hardware key-generator was broken.
| 32c3 3ds talk (December 27, 2015)
| [[User:Yellows8|Yellows8]]
|-
| Leak of normal-key matching a key-generator key
| 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.

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.

Note the devkit key-generator was discovered to be the same as the retail key-generator.
| Deducing the keyX for keyslot 0x3D and hardware key-generator algorithm. Generate remaining devkit common-keys.
| pre-[[1.0.0-0|1.0.0-X]]
|
| Shortly after the key-generator was revealed to be flawed at the 32c3 3ds talk
| January 20, 2016
| [[User:Jakcron|jakcron]]
|-
| ntrcardhax
|
| ARM9 code execution
| None
| [[10.3.0-28|10.3.0-X]]
| March 2015
| 32c3 3ds talk (December 27, 2015)
| [[User:Plutooo|plutoo]]
|-
| Title downgrading via [[Application_Manager_Services|AM]]([[Application_Manager_Services_PXI|PXI]])
| 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.

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.
| Bypassing title version check at installation, which then allows downgrading any title.
| None
| NATIVE_FIRM / AM-sysmodule [[10.0.0-27|10.0.0-X]]
| ?
|
| ?
|-
| FAT FS code null-deref
| 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.

Sample "fsck.vfat -n -v -V <fat image backup>" output for the above crash:

<pre>...
Starting check/repair pass.
<FilePath0> and
<FilePath1>
share clusters.
Truncating second to 3375104 bytes.
<FilePath1>
File size is 2787392 bytes, cluster chain length is 16384 bytes.
Truncating file to 16384 bytes.
Checking for unused clusters.
Reclaimed 1 unused cluster (16384 bytes).
Checking free cluster summary.
Free cluster summary wrong (1404490 vs. really 1404491)
Auto-correcting.
Starting verification pass.
Checking for unused clusters.
Leaving filesystem unchanged.</pre>
| Useless null-based-read
| None
| [[9.6.0-24|9.6.0-X]]
| July 8-9, 2015
|
| [[User:Yellows8|Yellows8]]
|-
| RSA signature padding checks
| The TWL_FIRM RSA sig padding check code used for all TWL RSA sig-checks has issues, see [[FIRM|here]].
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.
|
| None
| [[9.5.0-22|9.5.0-X]]
| March 2015
|
| [[User:Yellows8|Yellows8]]
|-
| [[AMPXI:ValidateDSiWareSectionMAC]] [[AES_Registers|AES]] keyslot reuse
| 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.
This is basically a different form of the pxips9 keyslot vuln, except with AESMAC etc.
| See description.
| None
| [[10.2.0-28|10.2.0-X]]
| March 15, 2015
| December 29, 2015
| [[User:Yellows8|Yellows8]]
|-
| pxips9 [[AES_Registers|AES]] keyslot reuse
| 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).
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.
| Reusing the previously used keyslot, for crypto with PS.
| None
| [[10.2.0-28|10.2.0-X]]
| Roughly the same time(same day?) as firmlaunch-hax.
| December 29, 2015
| [[User:Yellows8|Yellows8]]
|-
| firmlaunch-hax: FIRM header ToCToU
| This can't be exploited from ARM11 userland.
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.
With [[9.5.0-22]] the address of this FIRM header was changed from a FCRAM address, to ARM9-only address 0x01fffc00.
| ARM9 code execution
| [[9.5.0-22]]
|
| 2012, 3 days after [[User:Yellows8|Yellows8]] started Process9 code RE.
|
| [[User:Yellows8|Yellows8]]
|-
| Uninitialized data output for (PXI) command replies
| 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.
Certain ARM11 service commands have this same issue as well.
|
| None
| [[9.3.0-21|9.3.0-X]]
| ?
|
| [[User:Yellows8|Yellows8]]
|-
| [[Filesystem_services_PXI|FSPXI]] OpenArchive SD permissions
| Process9 does not use the exheader ARM9 access-mount permission flag for SD at all.
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.
|
| None
| [[9.3.0-21|9.3.0-X]]
| 2012
|
| [[User:Yellows8|Yellows8]]
|-
| [[AMPXI:ExportDSiWare]] export path
| 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>".
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.
| 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.
| None
| [[9.5.0-22]]
| April 2013
|
| [[User:Yellows8|Yellows8]]
|-
| [[DSiWare_Exports]] [[CTCert]] verification
| 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.
On 3DS however this is rather useless, due to the entire DSiWare .bin being encrypted with the console-unique movable.sed keyY.
| 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.
| Unknown, probably none.
| ?
| April 2013
|
| [[User:Yellows8|Yellows8]]
|-
| [[Gamecard_Services_PXI]] unchecked REG_CTRCARDCNT transfer-size
| 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).
| Out-of-bounds read for a value which gets written to a register.
| [[5.0.0-11|5.0.0-X]]
|
| 2013?
|
| [[User:Yellows8|Yellows8]]
|-
| [[PXI_Registers|PXI]] cmdbuf buffer overrun
| 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.
| Probably ARM9 code execution
| [[5.0.0-11|5.0.0-11]]
|
| March 2015, original timeframe if any unknown
|
| [[User:Plutooo|plutoo]]/[[User:Yellows8|Yellows8]]/maybe others(?)
|-
| [[Application_Manager_Services_PXI|PXIAM]] command 0x003D0108(See also [[Application_Manager_Services|this]])
| 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.
| ARM9 code execution
| [[5.0.0-11|5.0.0-X]]
|
| May 2013
|
| [[User:Yellows8|Yellows8]]
|-
| [[Process_Services_PXI|PS RSA]] commands buffer overflows
| 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.
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]].
| ARM9 code execution
| [[5.0.0-11|5.0.0-X]]
|
| 2012
|
| [[User:Yellows8|Yellows8]]
|-
| [[PXI_Registers|PXI]] pxi_id bad check
| The Process9 code responsible for [[PXI_Registers|PXI]] communications read pxi_id as a signed char. There were two flaws:
* They used it as index to a lookup-table without checking the value at all.
* Another function verified that pxi_id < 7, allowing negative values to pass the check. This would also cause an out-of-range table-lookup.
| Maybe ARM9 code execution
| [[3.0.0-5|3.0.0-5]]
|
| March 2015, originally 2012 for the first issue at least
|
| [[User:Plutooo|plutoo]], [[User:Yellows8|Yellows8]], maybe others(?)
|}

=== Kernel9 ===
{| class="wikitable" border="1"
|-
! Summary
! Description
! Successful exploitation result
! Fixed in [[FIRM]] system version
! Last [[FIRM]] system version this flaw was checked for
! Timeframe this was discovered
! Discovered by
|-
| [[CONFIG Registers#CFG_SYSPROT9|CFG_SYSPROT9]] bit1 not set by Kernel9
| Old versions of Kernel9 never set bit1 of [[CONFIG Registers#CFG_SYSPROT9|CFG_SYSPROT9]] and instead blocked access to the [[OTP Registers|OTP Registers]] itself, presumably under the assumption that an attacker would never gain code execution under Kernel9. This leaves the [[OTP Registers|0x10012000]]-region unprotected (this region should be locked early during boot!) to an attacker with sufficient privileges. Since it's never locked, you can dump it once you get ARM9 code execution.

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).

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.
| Dumping of the [[OTP Registers|OTP]] area
| [[3.0.0-5|3.0.0-X]]
|
| February 2015
| [[User:Plutooo|plutoo]], Normmatt independently, [[User:Plailect|Plailect]] (hardware-less public implementation)
|}

== ARM11 software ==
=== Kernel11 ===
{| class="wikitable" border="1"
|-
! Summary
! Description
! Successful exploitation result
! Fixed in [[FIRM]] system version
! Last [[FIRM]] system version this flaw was checked for
! Timeframe this was discovered
! Discovered by
|-
| [[SVC]] table too small
| 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.

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.
|
| None
| [[10.2.0-28|10.2.0-X]]
| 2012
| Everyone
|-
| [[SVC|svcBackdoor (0x7B)]]
| This backdoor allows executing SVC-mode code at the user-specified code-address. This is used by Process9, using this on the ARM11(with NATIVE_FIRM) requires patching the kernel .text or modifying SVC-access-control.
| See description
| None
| [[10.2.0-28|10.2.0-X]]
|
| Everyone
|-
| [[Memory_layout#ARM11_Detailed_virtual_memory_map|0xEFF00000]] / 0xDFF00000 ARM11 kernel virtual-memory
| 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.
|
| None
| [[10.2.0-28|10.2.0-X]]
|
|
|-
| Memchunkhax2
|
| ARM11 kernel code execution
| [[10.4.0-29|10.4.0-X]] (partially)
| [[10.4.0-29|10.4.0-X]]
|
| derrek
|-
| AffinityMask/processorid validation
| 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.
The original code with the first 3 did the following:
* if(u32_processorcount > ~0x80000001)return 0xe0e01bfd;
* if(s32_processorcount > <total_cores>)return 0xd8e007fd;
The following code replaced the above:
* if(u32_processorcount >= <total_cores+1>)return 0xd8e007fd;
In theory the latter should catch everything that the former did, so it's unknown if this was really a security issue.

The svcCreateThread changes with [[10.0.0-27|10.0.0-X]] definitely did fix a security issue.
* Original code: "if(s32_processorid > <total_cores>)return 0xd8e007fd;"
* New code: "if(s32_processorid >= <total_cores> || s32_processorid <= -4)return 0xd8e007fd;"
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:
* Old3DS: Useless kernel-mode crash due to accessing unmapped memory.
* 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).
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)).
| Nothing useful
| [[10.0.0-27|10.0.0-X]]
| [[10.0.0-27|10.0.0-X]]
| svcCreateThread issue: May 31, 2015. The rest: September 8, 2015, via v9.6->v10.0 ARM11-kernel code-diff.
| [[User:Yellows8|Yellows8]]
|-
| memchunkhax
| 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.

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.

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.
| When combined with other flaws: ARM11-kernelmode code execution
| [[9.3.0-21|9.3.0-21]]
|
| February 2014
| [[User:Yellows8|Yellows8]]
|-
| Multiple [[KLinkedListNode|KLinkedListNode]] SlabHeap use after free bugs
| 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:
SlabHeap_free(KLinkedListNode);
KObject *obj = KLinkedListNode->key; // the object there might have changed!
This bug appeared all over the place.
| ARM11-kernelmode code exec maybe
| [[8.0.0-18|8.0.0-18]]
|
| April 2015
| [[User:Derrek|derrek]]
|-
| PXI [[RPC_Command_Structure|Command]] input/output buffer permissions
| 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.
|
| [[6.0.0-11|6.0.0-11]]
|
| 2012
| [[User:Yellows8|Yellows8]]
|-
| [[SVC|svcStartInterProcessDma]]
| For svcStartInterProcessDma, the kernel code had the following flaws:

* 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.

* Integer overflows for srcaddr+size and dstaddr+size are now checked(with [[6.0.0-11]]), which were not checked before.

* 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).
|
| [[6.0.0-11]]
|
| DmaConfig issue: unknown. The rest: 2014
| [[User:Plutooo|plutoo]], [[User:Yellows8|Yellows8]] independently
|-
| [[SVC|svcControlMemory]] Parameter checks
| For svcControlMemory the parameter check had these two flaws:

* 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.

* Integer overflows on (addr0+size) are now checked that previously weren't (this also applies to most other address checks elsewhere in the kernel).

|
| [[5.0.0-11]]
|
|
| [[User:Plutooo|plutoo]]
|-
| [[RPC_Command_Structure|Command]] request/response buffer overflow
| 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.

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.
|
| [[5.0.0-11]]
|
| v4.1 FIRM -> v5.0 code diff
| [[User:Yellows8|Yellows8]]
|-
| [[SVC|SVC stack allocation overflows]]
|
* 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.
* The alignment (size+7)&~7 calculation before allocation was not checked for integer overflow.

This might allow for ARM11 kernel code-execution.

(Applies to svcSetResourceLimitValues, svcGetThreadList, svcGetProcessList, svcReplyAndReceive, svcWaitSynchronizationN.)
|
| [[5.0.0-11]]
|
| v4.1 FIRM -> v5.0 code diff
| [[User:Plutooo|plutoo]], [[User:Yellows8|Yellows8]] complementary
|-
| [[SVC|svcControlMemory]] MemoryOperation MAP memory-permissions
| 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.
|
| [[4.1.0-8]]
|
| 2012
| [[User:Yellows8|Yellows8]]
|-
| [[RPC_Command_Structure|Command]] input/output buffer permissions
| 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.
|
| [[4.0.0-7]]
|
| 2012
| [[User:Yellows8|Yellows8]]
|-
| [[SVC|svcReadProcessMemory/svcWriteProcessMemory memory]] permissions
| 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.
|
| [[4.0.0-7]]
|
| 2012?
| [[User:Yellows8|Yellows8]]
|}

=== [[FIRM]] Sysmodules ===
{| class="wikitable" border="1"
|-
! Summary
! Description
! Successful exploitation result
! Fixed in [[FIRM]] system version
! Last [[FIRM]] system version this flaw was checked for
! Timeframe this was discovered
! Discovered by
|-
| [[Services|"srv:pm"]] process registration
| 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.

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.

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).
| Access to arbitrary services
| [[7.0.0-13]]
|
| 2012
| [[User:Yellows8|Yellows8]]
|-
| FSDIR null-deref
| [[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.
|
| None
| [[9.6.0-24|9.6.0-X]]
| May 19(?)-20, 2015
| [[User:Yellows8|Yellows8]]
|}

=== Standalone Sysmodules ===
{| class="wikitable" border="1"
|-
! Summary
! Description
! Successful exploitation result
! Fixed in system-module system-version
! Last system-module system-version this flaw was checked for
! Timeframe this was discovered
! Timeframe this was added to wiki
! Discovered by
|-
| [[IR_Services|IR]]: Stack buffer overflow with custom hardware
| 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.

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.
| ROP under IR sysmodule.
| [[10.6.0-31|10.6.0-31]]
|
| February 23, 2016 (Unknown if it was noticed before then)
| February 23, 2016
| [[User:Yellows8|Yellows8]]
|-
| [[NIM_Services|NIM]]: Downloading old title-versions from eShop
| 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.
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).

Originally this was tested with a debugging-system via modded-FIRM, eventually smea implemented it in HANS for the 32c3 release.
| Downloading old title-versions from eShop
| None
| [[10.0.0-27|10.0.0-X]]
| October 24, 2015 (Unknown when exactly the first eShop title downgrade was actually tested, maybe November)
| January 7, 2016 (Same day Ironfall v1.0 was removed from CDN via the main-CXI files)
| [[User:Yellows8|Yellows8]]
|-
| [[SPI_Services|SPI]] service out-of-bounds write
| cmd1 has out-of-bounds write allowing overwrite of some static variables in .data.
|
| None
| [[9.5.0-22]]
| March 2015
|
| [[User:Plutooo|plutoo]]
|-
| [[NFC_Services|NFC]] module service command buf-overflows
| 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....>.
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.

There's no known retail titles which have access to either of these services.
| ROP under NFC module.
| New3DS: None
| New3DS: [[9.5.0-22]]
| December 2014?
|
| [[User:Yellows8|Yellows8]]
|-
| [[News_Services|NEWSS]] service command notificationID validation failure
| 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).
| ROP under news module.
| None
| [[9.7.0-25|9.7.0-X]]
| December 2014
|
| [[User:Yellows8|Yellows8]]
|-
| [[NWMUDS:DecryptBeaconData]] heap buffer overflow
| 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.

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.

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.
| 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.
| None
| [[9.0.0-20]]
| ~September 23, 2014(see the [[NWMUDS:DecryptBeaconData]] page history)
| August 3, 2015
| [[User:Yellows8|Yellows8]]
|-
| [[HID_Services|HID]] module shared-mem
| 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.
| ROP under HID module, but this is *very* unlikely to be exploitable since the data written is HID data.
| None
| [[9.3.0-21]]
| 2014?
|
| [[User:Yellows8|Yellows8]]
|-
| gspwn
| 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).

FCRAM is gpu-accessible up to physaddr 0x26800000 on Old3DS, and 0x2DC00000 on New3DS. This is BASE_memregion_start(aka SYSTEM_memregion_end)-0x400000 with the default memory-layout on Old3DS/New3DS.
| User-mode code execution.
| None
| [[9.6.0-24|9.6.0-X]]
| Early 2014
|
| smea, [[User:Yellows8|Yellows8]]/others before then
|-
| rohax
| 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.

This was fixed after [[ninjhax]] release by adding checks on [[CRO0]]-based pointers before writing to them.
| Memory-mapping syscalls.
| [[9.3.0-21]]
| [[9.4.0-21]]
|
|
| smea, [[User:Plutooo|plutoo]] joint effort
|-
| Region free
| 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.
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]].
| Launching gamecards from any region + bypassing Home Menu gamecard-sysupdate installation
| None
| Last tested with [[10.1.0-27|10.1.0-X]].
| June(?) 2014
|
| [[User:Yellows8|Yellows8]]
|-
| [[NWM_Services|NWM]] service-cmd state null-ptr deref
| 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.
It's unknown whether any NWM services besides NWMUDS have this issue.
| This is rather useless since it's only a crash caused by a state ptr based at 0x0.
| None
| [[9.0.0-20]]
| 2013?
|
| [[User:Yellows8|Yellows8]]
|}

=== General/CTRSDK ===
{| class="wikitable" border="1"
|-
! Summary
! Description
! Successful exploitation result
! Fixed in version
! Last version this flaw was checked for
! Timeframe this was discovered
! Discovered by
|-
| [[NWM_Services|UDS]] beacon additional-data buffer overflow
| 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.
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.

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).

The maximum number of bytes that can be written beyond the end of the outbuf is 0x37-bytes, with additionaldata_size=0xFF.
| Perhaps ROP, very difficult if possible with anything at all
| ?
|
| September(?) 2014
| [[User:Yellows8|Yellows8]]
|}

3DS System Flaws

2016-03-14T17:47:19Z

Plailect: /* Kernel9 */

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]].

=Stale / Rejected Efforts=
* 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.

* Someone (who will remain unnamed) has released CFW and CIA installers, all of which is copied from the work of others, or copyrighted material.

==Tips and info==
The 3DS uses the XN feature of the ARM11 processor. There's no official way from applications to enable executable permission for memory containing arbitrary unsigned code(there's a [[SVC]] for this, but only [[RO_Services|RO-module]] has access to it). An usable userland exploit would still be useful: you could only do return-oriented-programming with it initially. From ROP one could then exploit system flaw(s), see below.

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).

=System flaws=
== Hardware ==
{| class="wikitable" border="1"
! Summary
! Description
! Fixed with hardware model/revision
! Newest hardware model/revision this flaw was checked for
! Timeframe this was discovered
! Discovered by
|-
| ARM9/ARM11 bootrom vectors point at unitialized RAM
| 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.
Since RAM isn't cleared on boot (see below), one can immediately start execution of their own code here to dump bootrom, OTP, etc.
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.

This requires *very* *precise* timing for triggering the hardware fault: it's unknown if anyone actually exploited this successfully at the time of writing(the one who attempted+discovered it *originally* as listed in this wiki section hasn't).
| None: all available 3DS models at the time of writing have the exact same ARM9/ARM11 bootrom for the unprotected areas.
| New3DS
| End of February 2014
| [[User:Derrek|derrek]], WulfyStylez (May 2015) independently
|-
| Missing AES key clearing
| The hardware AES engine does not clear keys when doing a hard reset/reboot.
| None
| New3DS
| August 2014
| Mathieulh/Others
|-
| No RAM clearing on reboots
| On an MCU-triggered reboot all RAM including FCRAM/ARM9 memory/AXIWRAM/VRAM keeps its contents.
| None
| New3DS
| March 2014
| [[User:Derrek|derrek]]
|-
| 32bits of actual console-unique TWLNAND keydata
| 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.
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).
| None
| New3DS
| 2012?
| [[User:Yellows8|Yellows8]]
|-
| DSi / 3DS-TWL key-generator
| 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.
This applies to the keyX/keyY too.

This attack does not work for the 3DS key-generator because keyslots 0-3 are only for TWL keys.
| None
| New3DS
| 2011
| [[User:Yellows8|Yellows8]]
|-
| 3DS key-generator
| 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.

Several such pairs of matching normal-keys and KeyY values were found, leading to deducing the key-generator function.
| None
| New3DS
| February 2015
| [[User:Yellows8|Yellows8]], [[User:Plutooo|plutoo]]
|-
| FIRM partitions known-plaintext
| 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.

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).

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.
| None
| New3DS
|
| Everyone
|}

== ARM9 software ==
=== arm9loader ===
{| class="wikitable" border="1"
|-
! Summary
! Description
! Successful exploitation result
! Fixed in [[FIRM]] system version
! Last [[FIRM]] system version this flaw was checked for
! Timeframe this was discovered
! Public disclosure timeframe
! Discovered by
|-
| Uncleared OTP hash keydata in console-unique 0x11 key-generation
| 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.

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.

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]].

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.
| Derivation of all New3DS keys generated via the NAND keystore (0x1B "Secure4" etc.)
| None
| [[10.4.0-29|10.4.0-X]]
| ~April 2015, implemented in May 2015
| 13 January 2016
| [[User:WulfyStylez|WulfyStylez]], [[User:Dazzozo|Dazzozo]], [[User:Shinyquagsire23|shinyquagsire23]] (complimentary + implemented), [[User:Plutooo|plutoo]], Normmatt (discovered independently)
|-
| enhanced-arm9loaderhax
| See the 32c3 3ds talk.
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.
| arm9loaderhax which automatically occurs at hard-boot.
| See arm9loaderhax / description.
| See arm9loaderhax / description.
| Theorized around mid July, 2015. Later implemented+tested by [[User:Plutooo|plutoo]] and derrek.
| 32c3 3ds talk (December 27, 2015)
| [[User:Yellows8|Yellows8]]
|-
| Missing verification-block for the 9.6 keys (arm9loaderhax)
| 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.

Writing an incorrect key to NAND will cause arm9loader to decrypt the ARM9 kernel as garbage and then jump to it.

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.

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.

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.
| Recovery of 6.x [[Savegames#6.0.0-11_Savegame_keyY|save key]]/7.x [[NCCH]] key
| None
| [[10.4.0-29|10.4.0-X]]
| March, 2015
|
| [[User:Plutooo|plutoo]]
|-
| Uncleared New3DS keyslot 0x11
| 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.
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.

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]].
| New3DS keyXs generation
| 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]].
|
| February 3, 2015 (one day after [[9.5.0-22|9.5.0-X]] release)
|
| [[User:Yellows8|Yellows8]]
|}

=== Process9 ===
{| class="wikitable" border="1"
|-
! Summary
! Description
! Successful exploitation result
! Fixed in [[FIRM]] system version
! Last [[FIRM]] system version this flaw was checked for
! Timeframe this was discovered
! Public disclosure timeframe
! Discovered by
|-
| Leak of normal-key matching a key-scrambler key
| 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.

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.
| Deducing the keyX for keyslot 0x39 and the key scrambler algorithm
| New 3DS [[9.3.0-21|9.3.0-X]], sort of
| [[10.0.0-27|10.0.0-X]]
| Sometime in 2015 after the hardware key-generator was broken.
| 32c3 3ds talk (December 27, 2015)
| [[User:Yellows8|Yellows8]]
|-
| Leak of normal-key matching a key-generator key
| 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.

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.

Note the devkit key-generator was discovered to be the same as the retail key-generator.
| Deducing the keyX for keyslot 0x3D and hardware key-generator algorithm. Generate remaining devkit common-keys.
| pre-[[1.0.0-0|1.0.0-X]]
|
| Shortly after the key-generator was revealed to be flawed at the 32c3 3ds talk
| January 20, 2016
| [[User:Jakcron|jakcron]]
|-
| ntrcardhax
|
| ARM9 code execution
| None
| [[10.3.0-28|10.3.0-X]]
| March 2015
| 32c3 3ds talk (December 27, 2015)
| [[User:Plutooo|plutoo]]
|-
| Title downgrading via [[Application_Manager_Services|AM]]([[Application_Manager_Services_PXI|PXI]])
| 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.

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.
| Bypassing title version check at installation, which then allows downgrading any title.
| None
| NATIVE_FIRM / AM-sysmodule [[10.0.0-27|10.0.0-X]]
| ?
|
| ?
|-
| FAT FS code null-deref
| 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.

Sample "fsck.vfat -n -v -V <fat image backup>" output for the above crash:

<pre>...
Starting check/repair pass.
<FilePath0> and
<FilePath1>
share clusters.
Truncating second to 3375104 bytes.
<FilePath1>
File size is 2787392 bytes, cluster chain length is 16384 bytes.
Truncating file to 16384 bytes.
Checking for unused clusters.
Reclaimed 1 unused cluster (16384 bytes).
Checking free cluster summary.
Free cluster summary wrong (1404490 vs. really 1404491)
Auto-correcting.
Starting verification pass.
Checking for unused clusters.
Leaving filesystem unchanged.</pre>
| Useless null-based-read
| None
| [[9.6.0-24|9.6.0-X]]
| July 8-9, 2015
|
| [[User:Yellows8|Yellows8]]
|-
| RSA signature padding checks
| The TWL_FIRM RSA sig padding check code used for all TWL RSA sig-checks has issues, see [[FIRM|here]].
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.
|
| None
| [[9.5.0-22|9.5.0-X]]
| March 2015
|
| [[User:Yellows8|Yellows8]]
|-
| [[AMPXI:ValidateDSiWareSectionMAC]] [[AES_Registers|AES]] keyslot reuse
| 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.
This is basically a different form of the pxips9 keyslot vuln, except with AESMAC etc.
| See description.
| None
| [[10.2.0-28|10.2.0-X]]
| March 15, 2015
| December 29, 2015
| [[User:Yellows8|Yellows8]]
|-
| pxips9 [[AES_Registers|AES]] keyslot reuse
| 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).
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.
| Reusing the previously used keyslot, for crypto with PS.
| None
| [[10.2.0-28|10.2.0-X]]
| Roughly the same time(same day?) as firmlaunch-hax.
| December 29, 2015
| [[User:Yellows8|Yellows8]]
|-
| firmlaunch-hax: FIRM header ToCToU
| This can't be exploited from ARM11 userland.
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.
With [[9.5.0-22]] the address of this FIRM header was changed from a FCRAM address, to ARM9-only address 0x01fffc00.
| ARM9 code execution
| [[9.5.0-22]]
|
| 2012, 3 days after [[User:Yellows8|Yellows8]] started Process9 code RE.
|
| [[User:Yellows8|Yellows8]]
|-
| Uninitialized data output for (PXI) command replies
| 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.
Certain ARM11 service commands have this same issue as well.
|
| None
| [[9.3.0-21|9.3.0-X]]
| ?
|
| [[User:Yellows8|Yellows8]]
|-
| [[Filesystem_services_PXI|FSPXI]] OpenArchive SD permissions
| Process9 does not use the exheader ARM9 access-mount permission flag for SD at all.
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.
|
| None
| [[9.3.0-21|9.3.0-X]]
| 2012
|
| [[User:Yellows8|Yellows8]]
|-
| [[AMPXI:ExportDSiWare]] export path
| 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>".
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.
| 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.
| None
| [[9.5.0-22]]
| April 2013
|
| [[User:Yellows8|Yellows8]]
|-
| [[DSiWare_Exports]] [[CTCert]] verification
| 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.
On 3DS however this is rather useless, due to the entire DSiWare .bin being encrypted with the console-unique movable.sed keyY.
| 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.
| Unknown, probably none.
| ?
| April 2013
|
| [[User:Yellows8|Yellows8]]
|-
| [[Gamecard_Services_PXI]] unchecked REG_CTRCARDCNT transfer-size
| 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).
| Out-of-bounds read for a value which gets written to a register.
| [[5.0.0-11|5.0.0-X]]
|
| 2013?
|
| [[User:Yellows8|Yellows8]]
|-
| [[PXI_Registers|PXI]] cmdbuf buffer overrun
| 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.
| Probably ARM9 code execution
| [[5.0.0-11|5.0.0-11]]
|
| March 2015, original timeframe if any unknown
|
| [[User:Plutooo|plutoo]]/[[User:Yellows8|Yellows8]]/maybe others(?)
|-
| [[Application_Manager_Services_PXI|PXIAM]] command 0x003D0108(See also [[Application_Manager_Services|this]])
| 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.
| ARM9 code execution
| [[5.0.0-11|5.0.0-X]]
|
| May 2013
|
| [[User:Yellows8|Yellows8]]
|-
| [[Process_Services_PXI|PS RSA]] commands buffer overflows
| 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.
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]].
| ARM9 code execution
| [[5.0.0-11|5.0.0-X]]
|
| 2012
|
| [[User:Yellows8|Yellows8]]
|-
| [[PXI_Registers|PXI]] pxi_id bad check
| The Process9 code responsible for [[PXI_Registers|PXI]] communications read pxi_id as a signed char. There were two flaws:
* They used it as index to a lookup-table without checking the value at all.
* Another function verified that pxi_id < 7, allowing negative values to pass the check. This would also cause an out-of-range table-lookup.
| Maybe ARM9 code execution
| [[3.0.0-5|3.0.0-5]]
|
| March 2015, originally 2012 for the first issue at least
|
| [[User:Plutooo|plutoo]], [[User:Yellows8|Yellows8]], maybe others(?)
|}

=== Kernel9 ===
{| class="wikitable" border="1"
|-
! Summary
! Description
! Successful exploitation result
! Fixed in [[FIRM]] system version
! Last [[FIRM]] system version this flaw was checked for
! Timeframe this was discovered
! Discovered by
|-
| [[CONFIG Registers#CFG_SYSPROT9|CFG_SYSPROT9]] bit1 not set by Kernel9
| Old versions of Kernel9 never set bit1 of [[CONFIG Registers#CFG_SYSPROT9|CFG_SYSPROT9]] and instead blocked access to the [[OTP Registers|OTP Registers]] itself, presumably under the assumption that an attacker would never gain code execution under Kernel9. This leaves the [[OTP Registers|0x10012000]]-region unprotected (this region should be locked early during boot!) to an attacker with sufficient privileges. Since it's never locked, you can dump it once you get ARM9 code execution.

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 vulnerability (see arm9loaderhax / description).

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.
| Dumping of the [[OTP Registers|OTP]] area
| [[3.0.0-5|3.0.0-X]]
|
| February 2015
| [[User:Plutooo|plutoo]], Normmatt independently, [[User:Plailect|Plailect]] (hardware-less public implementation)
|}

== ARM11 software ==
=== Kernel11 ===
{| class="wikitable" border="1"
|-
! Summary
! Description
! Successful exploitation result
! Fixed in [[FIRM]] system version
! Last [[FIRM]] system version this flaw was checked for
! Timeframe this was discovered
! Discovered by
|-
| [[SVC]] table too small
| 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.

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.
|
| None
| [[10.2.0-28|10.2.0-X]]
| 2012
| Everyone
|-
| [[SVC|svcBackdoor (0x7B)]]
| This backdoor allows executing SVC-mode code at the user-specified code-address. This is used by Process9, using this on the ARM11(with NATIVE_FIRM) requires patching the kernel .text or modifying SVC-access-control.
| See description
| None
| [[10.2.0-28|10.2.0-X]]
|
| Everyone
|-
| [[Memory_layout#ARM11_Detailed_virtual_memory_map|0xEFF00000]] / 0xDFF00000 ARM11 kernel virtual-memory
| 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.
|
| None
| [[10.2.0-28|10.2.0-X]]
|
|
|-
| Memchunkhax2
|
| ARM11 kernel code execution
| [[10.4.0-29|10.4.0-X]] (partially)
| [[10.4.0-29|10.4.0-X]]
|
| derrek
|-
| AffinityMask/processorid validation
| 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.
The original code with the first 3 did the following:
* if(u32_processorcount > ~0x80000001)return 0xe0e01bfd;
* if(s32_processorcount > <total_cores>)return 0xd8e007fd;
The following code replaced the above:
* if(u32_processorcount >= <total_cores+1>)return 0xd8e007fd;
In theory the latter should catch everything that the former did, so it's unknown if this was really a security issue.

The svcCreateThread changes with [[10.0.0-27|10.0.0-X]] definitely did fix a security issue.
* Original code: "if(s32_processorid > <total_cores>)return 0xd8e007fd;"
* New code: "if(s32_processorid >= <total_cores> || s32_processorid <= -4)return 0xd8e007fd;"
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:
* Old3DS: Useless kernel-mode crash due to accessing unmapped memory.
* 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).
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)).
| Nothing useful
| [[10.0.0-27|10.0.0-X]]
| [[10.0.0-27|10.0.0-X]]
| svcCreateThread issue: May 31, 2015. The rest: September 8, 2015, via v9.6->v10.0 ARM11-kernel code-diff.
| [[User:Yellows8|Yellows8]]
|-
| memchunkhax
| 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.

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.

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.
| When combined with other flaws: ARM11-kernelmode code execution
| [[9.3.0-21|9.3.0-21]]
|
| February 2014
| [[User:Yellows8|Yellows8]]
|-
| Multiple [[KLinkedListNode|KLinkedListNode]] SlabHeap use after free bugs
| 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:
SlabHeap_free(KLinkedListNode);
KObject *obj = KLinkedListNode->key; // the object there might have changed!
This bug appeared all over the place.
| ARM11-kernelmode code exec maybe
| [[8.0.0-18|8.0.0-18]]
|
| April 2015
| [[User:Derrek|derrek]]
|-
| PXI [[RPC_Command_Structure|Command]] input/output buffer permissions
| 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.
|
| [[6.0.0-11|6.0.0-11]]
|
| 2012
| [[User:Yellows8|Yellows8]]
|-
| [[SVC|svcStartInterProcessDma]]
| For svcStartInterProcessDma, the kernel code had the following flaws:

* 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.

* Integer overflows for srcaddr+size and dstaddr+size are now checked(with [[6.0.0-11]]), which were not checked before.

* 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).
|
| [[6.0.0-11]]
|
| DmaConfig issue: unknown. The rest: 2014
| [[User:Plutooo|plutoo]], [[User:Yellows8|Yellows8]] independently
|-
| [[SVC|svcControlMemory]] Parameter checks
| For svcControlMemory the parameter check had these two flaws:

* 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.

* Integer overflows on (addr0+size) are now checked that previously weren't (this also applies to most other address checks elsewhere in the kernel).

|
| [[5.0.0-11]]
|
|
| [[User:Plutooo|plutoo]]
|-
| [[RPC_Command_Structure|Command]] request/response buffer overflow
| 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.

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.
|
| [[5.0.0-11]]
|
| v4.1 FIRM -> v5.0 code diff
| [[User:Yellows8|Yellows8]]
|-
| [[SVC|SVC stack allocation overflows]]
|
* 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.
* The alignment (size+7)&~7 calculation before allocation was not checked for integer overflow.

This might allow for ARM11 kernel code-execution.

(Applies to svcSetResourceLimitValues, svcGetThreadList, svcGetProcessList, svcReplyAndReceive, svcWaitSynchronizationN.)
|
| [[5.0.0-11]]
|
| v4.1 FIRM -> v5.0 code diff
| [[User:Plutooo|plutoo]], [[User:Yellows8|Yellows8]] complementary
|-
| [[SVC|svcControlMemory]] MemoryOperation MAP memory-permissions
| 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.
|
| [[4.1.0-8]]
|
| 2012
| [[User:Yellows8|Yellows8]]
|-
| [[RPC_Command_Structure|Command]] input/output buffer permissions
| 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.
|
| [[4.0.0-7]]
|
| 2012
| [[User:Yellows8|Yellows8]]
|-
| [[SVC|svcReadProcessMemory/svcWriteProcessMemory memory]] permissions
| 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.
|
| [[4.0.0-7]]
|
| 2012?
| [[User:Yellows8|Yellows8]]
|}

=== [[FIRM]] Sysmodules ===
{| class="wikitable" border="1"
|-
! Summary
! Description
! Successful exploitation result
! Fixed in [[FIRM]] system version
! Last [[FIRM]] system version this flaw was checked for
! Timeframe this was discovered
! Discovered by
|-
| [[Services|"srv:pm"]] process registration
| 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.

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.

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).
| Access to arbitrary services
| [[7.0.0-13]]
|
| 2012
| [[User:Yellows8|Yellows8]]
|-
| FSDIR null-deref
| [[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.
|
| None
| [[9.6.0-24|9.6.0-X]]
| May 19(?)-20, 2015
| [[User:Yellows8|Yellows8]]
|}

=== Standalone Sysmodules ===
{| class="wikitable" border="1"
|-
! Summary
! Description
! Successful exploitation result
! Fixed in system-module system-version
! Last system-module system-version this flaw was checked for
! Timeframe this was discovered
! Timeframe this was added to wiki
! Discovered by
|-
| [[IR_Services|IR]]: Stack buffer overflow with custom hardware
| 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.

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.
| ROP under IR sysmodule.
| [[10.6.0-31|10.6.0-31]]
|
| February 23, 2016 (Unknown if it was noticed before then)
| February 23, 2016
| [[User:Yellows8|Yellows8]]
|-
| [[NIM_Services|NIM]]: Downloading old title-versions from eShop
| 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.
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).

Originally this was tested with a debugging-system via modded-FIRM, eventually smea implemented it in HANS for the 32c3 release.
| Downloading old title-versions from eShop
| None
| [[10.0.0-27|10.0.0-X]]
| October 24, 2015 (Unknown when exactly the first eShop title downgrade was actually tested, maybe November)
| January 7, 2016 (Same day Ironfall v1.0 was removed from CDN via the main-CXI files)
| [[User:Yellows8|Yellows8]]
|-
| [[SPI_Services|SPI]] service out-of-bounds write
| cmd1 has out-of-bounds write allowing overwrite of some static variables in .data.
|
| None
| [[9.5.0-22]]
| March 2015
|
| [[User:Plutooo|plutoo]]
|-
| [[NFC_Services|NFC]] module service command buf-overflows
| 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....>.
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.

There's no known retail titles which have access to either of these services.
| ROP under NFC module.
| New3DS: None
| New3DS: [[9.5.0-22]]
| December 2014?
|
| [[User:Yellows8|Yellows8]]
|-
| [[News_Services|NEWSS]] service command notificationID validation failure
| 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).
| ROP under news module.
| None
| [[9.7.0-25|9.7.0-X]]
| December 2014
|
| [[User:Yellows8|Yellows8]]
|-
| [[NWMUDS:DecryptBeaconData]] heap buffer overflow
| 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.

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.

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.
| 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.
| None
| [[9.0.0-20]]
| ~September 23, 2014(see the [[NWMUDS:DecryptBeaconData]] page history)
| August 3, 2015
| [[User:Yellows8|Yellows8]]
|-
| [[HID_Services|HID]] module shared-mem
| 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.
| ROP under HID module, but this is *very* unlikely to be exploitable since the data written is HID data.
| None
| [[9.3.0-21]]
| 2014?
|
| [[User:Yellows8|Yellows8]]
|-
| gspwn
| 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).

FCRAM is gpu-accessible up to physaddr 0x26800000 on Old3DS, and 0x2DC00000 on New3DS. This is BASE_memregion_start(aka SYSTEM_memregion_end)-0x400000 with the default memory-layout on Old3DS/New3DS.
| User-mode code execution.
| None
| [[9.6.0-24|9.6.0-X]]
| Early 2014
|
| smea, [[User:Yellows8|Yellows8]]/others before then
|-
| rohax
| 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.

This was fixed after [[ninjhax]] release by adding checks on [[CRO0]]-based pointers before writing to them.
| Memory-mapping syscalls.
| [[9.3.0-21]]
| [[9.4.0-21]]
|
|
| smea, [[User:Plutooo|plutoo]] joint effort
|-
| Region free
| 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.
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]].
| Launching gamecards from any region + bypassing Home Menu gamecard-sysupdate installation
| None
| Last tested with [[10.1.0-27|10.1.0-X]].
| June(?) 2014
|
| [[User:Yellows8|Yellows8]]
|-
| [[NWM_Services|NWM]] service-cmd state null-ptr deref
| 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.
It's unknown whether any NWM services besides NWMUDS have this issue.
| This is rather useless since it's only a crash caused by a state ptr based at 0x0.
| None
| [[9.0.0-20]]
| 2013?
|
| [[User:Yellows8|Yellows8]]
|}

=== General/CTRSDK ===
{| class="wikitable" border="1"
|-
! Summary
! Description
! Successful exploitation result
! Fixed in version
! Last version this flaw was checked for
! Timeframe this was discovered
! Discovered by
|-
| [[NWM_Services|UDS]] beacon additional-data buffer overflow
| 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.
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.

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).

The maximum number of bytes that can be written beyond the end of the outbuf is 0x37-bytes, with additionaldata_size=0xFF.
| Perhaps ROP, very difficult if possible with anything at all
| ?
|
| September(?) 2014
| [[User:Yellows8|Yellows8]]
|}

3DS System Flaws

2016-03-14T17:44:42Z

Plailect: /* Kernel9 */

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]].

=Stale / Rejected Efforts=
* 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.

* Someone (who will remain unnamed) has released CFW and CIA installers, all of which is copied from the work of others, or copyrighted material.

==Tips and info==
The 3DS uses the XN feature of the ARM11 processor. There's no official way from applications to enable executable permission for memory containing arbitrary unsigned code(there's a [[SVC]] for this, but only [[RO_Services|RO-module]] has access to it). An usable userland exploit would still be useful: you could only do return-oriented-programming with it initially. From ROP one could then exploit system flaw(s), see below.

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).

=System flaws=
== Hardware ==
{| class="wikitable" border="1"
! Summary
! Description
! Fixed with hardware model/revision
! Newest hardware model/revision this flaw was checked for
! Timeframe this was discovered
! Discovered by
|-
| ARM9/ARM11 bootrom vectors point at unitialized RAM
| 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.
Since RAM isn't cleared on boot (see below), one can immediately start execution of their own code here to dump bootrom, OTP, etc.
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.

This requires *very* *precise* timing for triggering the hardware fault: it's unknown if anyone actually exploited this successfully at the time of writing(the one who attempted+discovered it *originally* as listed in this wiki section hasn't).
| None: all available 3DS models at the time of writing have the exact same ARM9/ARM11 bootrom for the unprotected areas.
| New3DS
| End of February 2014
| [[User:Derrek|derrek]], WulfyStylez (May 2015) independently
|-
| Missing AES key clearing
| The hardware AES engine does not clear keys when doing a hard reset/reboot.
| None
| New3DS
| August 2014
| Mathieulh/Others
|-
| No RAM clearing on reboots
| On an MCU-triggered reboot all RAM including FCRAM/ARM9 memory/AXIWRAM/VRAM keeps its contents.
| None
| New3DS
| March 2014
| [[User:Derrek|derrek]]
|-
| 32bits of actual console-unique TWLNAND keydata
| 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.
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).
| None
| New3DS
| 2012?
| [[User:Yellows8|Yellows8]]
|-
| DSi / 3DS-TWL key-generator
| 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.
This applies to the keyX/keyY too.

This attack does not work for the 3DS key-generator because keyslots 0-3 are only for TWL keys.
| None
| New3DS
| 2011
| [[User:Yellows8|Yellows8]]
|-
| 3DS key-generator
| 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.

Several such pairs of matching normal-keys and KeyY values were found, leading to deducing the key-generator function.
| None
| New3DS
| February 2015
| [[User:Yellows8|Yellows8]], [[User:Plutooo|plutoo]]
|-
| FIRM partitions known-plaintext
| 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.

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).

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.
| None
| New3DS
|
| Everyone
|}

== ARM9 software ==
=== arm9loader ===
{| class="wikitable" border="1"
|-
! Summary
! Description
! Successful exploitation result
! Fixed in [[FIRM]] system version
! Last [[FIRM]] system version this flaw was checked for
! Timeframe this was discovered
! Public disclosure timeframe
! Discovered by
|-
| Uncleared OTP hash keydata in console-unique 0x11 key-generation
| 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.

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.

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]].

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.
| Derivation of all New3DS keys generated via the NAND keystore (0x1B "Secure4" etc.)
| None
| [[10.4.0-29|10.4.0-X]]
| ~April 2015, implemented in May 2015
| 13 January 2016
| [[User:WulfyStylez|WulfyStylez]], [[User:Dazzozo|Dazzozo]], [[User:Shinyquagsire23|shinyquagsire23]] (complimentary + implemented), [[User:Plutooo|plutoo]], Normmatt (discovered independently)
|-
| enhanced-arm9loaderhax
| See the 32c3 3ds talk.
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.
| arm9loaderhax which automatically occurs at hard-boot.
| See arm9loaderhax / description.
| See arm9loaderhax / description.
| Theorized around mid July, 2015. Later implemented+tested by [[User:Plutooo|plutoo]] and derrek.
| 32c3 3ds talk (December 27, 2015)
| [[User:Yellows8|Yellows8]]
|-
| Missing verification-block for the 9.6 keys (arm9loaderhax)
| 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.

Writing an incorrect key to NAND will cause arm9loader to decrypt the ARM9 kernel as garbage and then jump to it.

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.

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.

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.
| Recovery of 6.x [[Savegames#6.0.0-11_Savegame_keyY|save key]]/7.x [[NCCH]] key
| None
| [[10.4.0-29|10.4.0-X]]
| March, 2015
|
| [[User:Plutooo|plutoo]]
|-
| Uncleared New3DS keyslot 0x11
| 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.
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.

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]].
| New3DS keyXs generation
| 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]].
|
| February 3, 2015 (one day after [[9.5.0-22|9.5.0-X]] release)
|
| [[User:Yellows8|Yellows8]]
|}

=== Process9 ===
{| class="wikitable" border="1"
|-
! Summary
! Description
! Successful exploitation result
! Fixed in [[FIRM]] system version
! Last [[FIRM]] system version this flaw was checked for
! Timeframe this was discovered
! Public disclosure timeframe
! Discovered by
|-
| Leak of normal-key matching a key-scrambler key
| 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.

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.
| Deducing the keyX for keyslot 0x39 and the key scrambler algorithm
| New 3DS [[9.3.0-21|9.3.0-X]], sort of
| [[10.0.0-27|10.0.0-X]]
| Sometime in 2015 after the hardware key-generator was broken.
| 32c3 3ds talk (December 27, 2015)
| [[User:Yellows8|Yellows8]]
|-
| Leak of normal-key matching a key-generator key
| 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.

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.

Note the devkit key-generator was discovered to be the same as the retail key-generator.
| Deducing the keyX for keyslot 0x3D and hardware key-generator algorithm. Generate remaining devkit common-keys.
| pre-[[1.0.0-0|1.0.0-X]]
|
| Shortly after the key-generator was revealed to be flawed at the 32c3 3ds talk
| January 20, 2016
| [[User:Jakcron|jakcron]]
|-
| ntrcardhax
|
| ARM9 code execution
| None
| [[10.3.0-28|10.3.0-X]]
| March 2015
| 32c3 3ds talk (December 27, 2015)
| [[User:Plutooo|plutoo]]
|-
| Title downgrading via [[Application_Manager_Services|AM]]([[Application_Manager_Services_PXI|PXI]])
| 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.

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.
| Bypassing title version check at installation, which then allows downgrading any title.
| None
| NATIVE_FIRM / AM-sysmodule [[10.0.0-27|10.0.0-X]]
| ?
|
| ?
|-
| FAT FS code null-deref
| 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.

Sample "fsck.vfat -n -v -V <fat image backup>" output for the above crash:

<pre>...
Starting check/repair pass.
<FilePath0> and
<FilePath1>
share clusters.
Truncating second to 3375104 bytes.
<FilePath1>
File size is 2787392 bytes, cluster chain length is 16384 bytes.
Truncating file to 16384 bytes.
Checking for unused clusters.
Reclaimed 1 unused cluster (16384 bytes).
Checking free cluster summary.
Free cluster summary wrong (1404490 vs. really 1404491)
Auto-correcting.
Starting verification pass.
Checking for unused clusters.
Leaving filesystem unchanged.</pre>
| Useless null-based-read
| None
| [[9.6.0-24|9.6.0-X]]
| July 8-9, 2015
|
| [[User:Yellows8|Yellows8]]
|-
| RSA signature padding checks
| The TWL_FIRM RSA sig padding check code used for all TWL RSA sig-checks has issues, see [[FIRM|here]].
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.
|
| None
| [[9.5.0-22|9.5.0-X]]
| March 2015
|
| [[User:Yellows8|Yellows8]]
|-
| [[AMPXI:ValidateDSiWareSectionMAC]] [[AES_Registers|AES]] keyslot reuse
| 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.
This is basically a different form of the pxips9 keyslot vuln, except with AESMAC etc.
| See description.
| None
| [[10.2.0-28|10.2.0-X]]
| March 15, 2015
| December 29, 2015
| [[User:Yellows8|Yellows8]]
|-
| pxips9 [[AES_Registers|AES]] keyslot reuse
| 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).
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.
| Reusing the previously used keyslot, for crypto with PS.
| None
| [[10.2.0-28|10.2.0-X]]
| Roughly the same time(same day?) as firmlaunch-hax.
| December 29, 2015
| [[User:Yellows8|Yellows8]]
|-
| firmlaunch-hax: FIRM header ToCToU
| This can't be exploited from ARM11 userland.
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.
With [[9.5.0-22]] the address of this FIRM header was changed from a FCRAM address, to ARM9-only address 0x01fffc00.
| ARM9 code execution
| [[9.5.0-22]]
|
| 2012, 3 days after [[User:Yellows8|Yellows8]] started Process9 code RE.
|
| [[User:Yellows8|Yellows8]]
|-
| Uninitialized data output for (PXI) command replies
| 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.
Certain ARM11 service commands have this same issue as well.
|
| None
| [[9.3.0-21|9.3.0-X]]
| ?
|
| [[User:Yellows8|Yellows8]]
|-
| [[Filesystem_services_PXI|FSPXI]] OpenArchive SD permissions
| Process9 does not use the exheader ARM9 access-mount permission flag for SD at all.
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.
|
| None
| [[9.3.0-21|9.3.0-X]]
| 2012
|
| [[User:Yellows8|Yellows8]]
|-
| [[AMPXI:ExportDSiWare]] export path
| 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>".
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.
| 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.
| None
| [[9.5.0-22]]
| April 2013
|
| [[User:Yellows8|Yellows8]]
|-
| [[DSiWare_Exports]] [[CTCert]] verification
| 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.
On 3DS however this is rather useless, due to the entire DSiWare .bin being encrypted with the console-unique movable.sed keyY.
| 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.
| Unknown, probably none.
| ?
| April 2013
|
| [[User:Yellows8|Yellows8]]
|-
| [[Gamecard_Services_PXI]] unchecked REG_CTRCARDCNT transfer-size
| 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).
| Out-of-bounds read for a value which gets written to a register.
| [[5.0.0-11|5.0.0-X]]
|
| 2013?
|
| [[User:Yellows8|Yellows8]]
|-
| [[PXI_Registers|PXI]] cmdbuf buffer overrun
| 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.
| Probably ARM9 code execution
| [[5.0.0-11|5.0.0-11]]
|
| March 2015, original timeframe if any unknown
|
| [[User:Plutooo|plutoo]]/[[User:Yellows8|Yellows8]]/maybe others(?)
|-
| [[Application_Manager_Services_PXI|PXIAM]] command 0x003D0108(See also [[Application_Manager_Services|this]])
| 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.
| ARM9 code execution
| [[5.0.0-11|5.0.0-X]]
|
| May 2013
|
| [[User:Yellows8|Yellows8]]
|-
| [[Process_Services_PXI|PS RSA]] commands buffer overflows
| 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.
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]].
| ARM9 code execution
| [[5.0.0-11|5.0.0-X]]
|
| 2012
|
| [[User:Yellows8|Yellows8]]
|-
| [[PXI_Registers|PXI]] pxi_id bad check
| The Process9 code responsible for [[PXI_Registers|PXI]] communications read pxi_id as a signed char. There were two flaws:
* They used it as index to a lookup-table without checking the value at all.
* Another function verified that pxi_id < 7, allowing negative values to pass the check. This would also cause an out-of-range table-lookup.
| Maybe ARM9 code execution
| [[3.0.0-5|3.0.0-5]]
|
| March 2015, originally 2012 for the first issue at least
|
| [[User:Plutooo|plutoo]], [[User:Yellows8|Yellows8]], maybe others(?)
|}

=== Kernel9 ===
{| class="wikitable" border="1"
|-
! Summary
! Description
! Successful exploitation result
! Fixed in [[FIRM]] system version
! Last [[FIRM]] system version this flaw was checked for
! Timeframe this was discovered
! Discovered by
|-
| [[CONFIG Registers#CFG_SYSPROT9|CFG_SYSPROT9]] bit1 not set by Kernel9
| Old versions of Kernel9 never set bit1 of [[CONFIG Registers#CFG_SYSPROT9|CFG_SYSPROT9]] and instead blocked access to the [[OTP Registers|OTP Registers]] itself, presumably under the assumption that an attacker would never gain code execution under Kernel9. This leaves the [[OTP Registers|0x10012000]]-region unprotected (this region should be locked early during boot!) to an attacker with sufficient privileges. Since it's never locked, you can dump it once you get ARM9 code execution.

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 vulnerability (see arm9loaderhax / description).

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]], and retrieve the required OTP data using this flaw.
| Dumping of the [[OTP Registers|OTP]] area
| [[3.0.0-5|3.0.0-X]]
|
| February 2015
| [[User:Plutooo|plutoo]], Normmatt independently, [[User:Plailect|Plailect]] (hardware-less public implementation)
|}

== ARM11 software ==
=== Kernel11 ===
{| class="wikitable" border="1"
|-
! Summary
! Description
! Successful exploitation result
! Fixed in [[FIRM]] system version
! Last [[FIRM]] system version this flaw was checked for
! Timeframe this was discovered
! Discovered by
|-
| [[SVC]] table too small
| 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.

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.
|
| None
| [[10.2.0-28|10.2.0-X]]
| 2012
| Everyone
|-
| [[SVC|svcBackdoor (0x7B)]]
| This backdoor allows executing SVC-mode code at the user-specified code-address. This is used by Process9, using this on the ARM11(with NATIVE_FIRM) requires patching the kernel .text or modifying SVC-access-control.
| See description
| None
| [[10.2.0-28|10.2.0-X]]
|
| Everyone
|-
| [[Memory_layout#ARM11_Detailed_virtual_memory_map|0xEFF00000]] / 0xDFF00000 ARM11 kernel virtual-memory
| 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.
|
| None
| [[10.2.0-28|10.2.0-X]]
|
|
|-
| Memchunkhax2
|
| ARM11 kernel code execution
| [[10.4.0-29|10.4.0-X]] (partially)
| [[10.4.0-29|10.4.0-X]]
|
| derrek
|-
| AffinityMask/processorid validation
| 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.
The original code with the first 3 did the following:
* if(u32_processorcount > ~0x80000001)return 0xe0e01bfd;
* if(s32_processorcount > <total_cores>)return 0xd8e007fd;
The following code replaced the above:
* if(u32_processorcount >= <total_cores+1>)return 0xd8e007fd;
In theory the latter should catch everything that the former did, so it's unknown if this was really a security issue.

The svcCreateThread changes with [[10.0.0-27|10.0.0-X]] definitely did fix a security issue.
* Original code: "if(s32_processorid > <total_cores>)return 0xd8e007fd;"
* New code: "if(s32_processorid >= <total_cores> || s32_processorid <= -4)return 0xd8e007fd;"
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:
* Old3DS: Useless kernel-mode crash due to accessing unmapped memory.
* 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).
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)).
| Nothing useful
| [[10.0.0-27|10.0.0-X]]
| [[10.0.0-27|10.0.0-X]]
| svcCreateThread issue: May 31, 2015. The rest: September 8, 2015, via v9.6->v10.0 ARM11-kernel code-diff.
| [[User:Yellows8|Yellows8]]
|-
| memchunkhax
| 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.

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.

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.
| When combined with other flaws: ARM11-kernelmode code execution
| [[9.3.0-21|9.3.0-21]]
|
| February 2014
| [[User:Yellows8|Yellows8]]
|-
| Multiple [[KLinkedListNode|KLinkedListNode]] SlabHeap use after free bugs
| 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:
SlabHeap_free(KLinkedListNode);
KObject *obj = KLinkedListNode->key; // the object there might have changed!
This bug appeared all over the place.
| ARM11-kernelmode code exec maybe
| [[8.0.0-18|8.0.0-18]]
|
| April 2015
| [[User:Derrek|derrek]]
|-
| PXI [[RPC_Command_Structure|Command]] input/output buffer permissions
| 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.
|
| [[6.0.0-11|6.0.0-11]]
|
| 2012
| [[User:Yellows8|Yellows8]]
|-
| [[SVC|svcStartInterProcessDma]]
| For svcStartInterProcessDma, the kernel code had the following flaws:

* 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.

* Integer overflows for srcaddr+size and dstaddr+size are now checked(with [[6.0.0-11]]), which were not checked before.

* 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).
|
| [[6.0.0-11]]
|
| DmaConfig issue: unknown. The rest: 2014
| [[User:Plutooo|plutoo]], [[User:Yellows8|Yellows8]] independently
|-
| [[SVC|svcControlMemory]] Parameter checks
| For svcControlMemory the parameter check had these two flaws:

* 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.

* Integer overflows on (addr0+size) are now checked that previously weren't (this also applies to most other address checks elsewhere in the kernel).

|
| [[5.0.0-11]]
|
|
| [[User:Plutooo|plutoo]]
|-
| [[RPC_Command_Structure|Command]] request/response buffer overflow
| 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.

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.
|
| [[5.0.0-11]]
|
| v4.1 FIRM -> v5.0 code diff
| [[User:Yellows8|Yellows8]]
|-
| [[SVC|SVC stack allocation overflows]]
|
* 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.
* The alignment (size+7)&~7 calculation before allocation was not checked for integer overflow.

This might allow for ARM11 kernel code-execution.

(Applies to svcSetResourceLimitValues, svcGetThreadList, svcGetProcessList, svcReplyAndReceive, svcWaitSynchronizationN.)
|
| [[5.0.0-11]]
|
| v4.1 FIRM -> v5.0 code diff
| [[User:Plutooo|plutoo]], [[User:Yellows8|Yellows8]] complementary
|-
| [[SVC|svcControlMemory]] MemoryOperation MAP memory-permissions
| 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.
|
| [[4.1.0-8]]
|
| 2012
| [[User:Yellows8|Yellows8]]
|-
| [[RPC_Command_Structure|Command]] input/output buffer permissions
| 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.
|
| [[4.0.0-7]]
|
| 2012
| [[User:Yellows8|Yellows8]]
|-
| [[SVC|svcReadProcessMemory/svcWriteProcessMemory memory]] permissions
| 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.
|
| [[4.0.0-7]]
|
| 2012?
| [[User:Yellows8|Yellows8]]
|}

=== [[FIRM]] Sysmodules ===
{| class="wikitable" border="1"
|-
! Summary
! Description
! Successful exploitation result
! Fixed in [[FIRM]] system version
! Last [[FIRM]] system version this flaw was checked for
! Timeframe this was discovered
! Discovered by
|-
| [[Services|"srv:pm"]] process registration
| 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.

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.

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).
| Access to arbitrary services
| [[7.0.0-13]]
|
| 2012
| [[User:Yellows8|Yellows8]]
|-
| FSDIR null-deref
| [[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.
|
| None
| [[9.6.0-24|9.6.0-X]]
| May 19(?)-20, 2015
| [[User:Yellows8|Yellows8]]
|}

=== Standalone Sysmodules ===
{| class="wikitable" border="1"
|-
! Summary
! Description
! Successful exploitation result
! Fixed in system-module system-version
! Last system-module system-version this flaw was checked for
! Timeframe this was discovered
! Timeframe this was added to wiki
! Discovered by
|-
| [[IR_Services|IR]]: Stack buffer overflow with custom hardware
| 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.

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.
| ROP under IR sysmodule.
| [[10.6.0-31|10.6.0-31]]
|
| February 23, 2016 (Unknown if it was noticed before then)
| February 23, 2016
| [[User:Yellows8|Yellows8]]
|-
| [[NIM_Services|NIM]]: Downloading old title-versions from eShop
| 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.
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).

Originally this was tested with a debugging-system via modded-FIRM, eventually smea implemented it in HANS for the 32c3 release.
| Downloading old title-versions from eShop
| None
| [[10.0.0-27|10.0.0-X]]
| October 24, 2015 (Unknown when exactly the first eShop title downgrade was actually tested, maybe November)
| January 7, 2016 (Same day Ironfall v1.0 was removed from CDN via the main-CXI files)
| [[User:Yellows8|Yellows8]]
|-
| [[SPI_Services|SPI]] service out-of-bounds write
| cmd1 has out-of-bounds write allowing overwrite of some static variables in .data.
|
| None
| [[9.5.0-22]]
| March 2015
|
| [[User:Plutooo|plutoo]]
|-
| [[NFC_Services|NFC]] module service command buf-overflows
| 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....>.
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.

There's no known retail titles which have access to either of these services.
| ROP under NFC module.
| New3DS: None
| New3DS: [[9.5.0-22]]
| December 2014?
|
| [[User:Yellows8|Yellows8]]
|-
| [[News_Services|NEWSS]] service command notificationID validation failure
| 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).
| ROP under news module.
| None
| [[9.7.0-25|9.7.0-X]]
| December 2014
|
| [[User:Yellows8|Yellows8]]
|-
| [[NWMUDS:DecryptBeaconData]] heap buffer overflow
| 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.

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.

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.
| 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.
| None
| [[9.0.0-20]]
| ~September 23, 2014(see the [[NWMUDS:DecryptBeaconData]] page history)
| August 3, 2015
| [[User:Yellows8|Yellows8]]
|-
| [[HID_Services|HID]] module shared-mem
| 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.
| ROP under HID module, but this is *very* unlikely to be exploitable since the data written is HID data.
| None
| [[9.3.0-21]]
| 2014?
|
| [[User:Yellows8|Yellows8]]
|-
| gspwn
| 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).

FCRAM is gpu-accessible up to physaddr 0x26800000 on Old3DS, and 0x2DC00000 on New3DS. This is BASE_memregion_start(aka SYSTEM_memregion_end)-0x400000 with the default memory-layout on Old3DS/New3DS.
| User-mode code execution.
| None
| [[9.6.0-24|9.6.0-X]]
| Early 2014
|
| smea, [[User:Yellows8|Yellows8]]/others before then
|-
| rohax
| 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.

This was fixed after [[ninjhax]] release by adding checks on [[CRO0]]-based pointers before writing to them.
| Memory-mapping syscalls.
| [[9.3.0-21]]
| [[9.4.0-21]]
|
|
| smea, [[User:Plutooo|plutoo]] joint effort
|-
| Region free
| 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.
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]].
| Launching gamecards from any region + bypassing Home Menu gamecard-sysupdate installation
| None
| Last tested with [[10.1.0-27|10.1.0-X]].
| June(?) 2014
|
| [[User:Yellows8|Yellows8]]
|-
| [[NWM_Services|NWM]] service-cmd state null-ptr deref
| 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.
It's unknown whether any NWM services besides NWMUDS have this issue.
| This is rather useless since it's only a crash caused by a state ptr based at 0x0.
| None
| [[9.0.0-20]]
| 2013?
|
| [[User:Yellows8|Yellows8]]
|}

=== General/CTRSDK ===
{| class="wikitable" border="1"
|-
! Summary
! Description
! Successful exploitation result
! Fixed in version
! Last version this flaw was checked for
! Timeframe this was discovered
! Discovered by
|-
| [[NWM_Services|UDS]] beacon additional-data buffer overflow
| 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.
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.

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).

The maximum number of bytes that can be written beyond the end of the outbuf is 0x37-bytes, with additionaldata_size=0xFF.
| Perhaps ROP, very difficult if possible with anything at all
| ?
|
| September(?) 2014
| [[User:Yellows8|Yellows8]]
|}