3dbrew - User contributions [en]

Mysteries

2016-12-09T06:59:00Z

WulfyStylez: /* Why are there two CTRCARD controllers? */

The following is a list of mysteries.

== General ==
* What is the CTR abbreviation?

== Hardware ==
=== Why are there two CTRCARD controllers? ===
'''Background:''' Also [http://problemkaputt.de/twl-core.jpg DSi SoC pinout] shows evidence of dual NTRCARD controllers on the final DSi SoC. (This was a [https://i.kinja-img.com/gawker-media/image/upload/s--Qk87hEjW--/18j4up3g4zdkqjpg.jpg planned feature] of the DSi before being axed later in development)

=== Why are there two EMMC controllers? ===
'''Theory:''' At some point during 3DS hardware development there was an idea to split up CTR and TWL nand into two different chips.
=== Is there a JTAG? ===
=== Is there more than one revision of the bootrom? ===
'''Background:''' Bootrom visible portion has been dumped on 3DS, 3DSXL, 2DS, New3DS. All matching exactly.
=== What is the EMMC controller @ 0x10100000 doing? ===
'''Background:''' There's dead code in NWM referencing it.
=== Why did they put NTRCARD accessible from ARM11? ===
'''Theory:''' At some point during 3DS hardware development there was a concept where ARM11 ran a menu with DS(i) icons while ARM9 was in TWL mode.

=== Is there a secret message embedded in the 3DS keyscrambler constant? ===
'''Background:''' TWL keyscrambler constant was Nintendo in Japanese, utf-8 encoded.

== Software ==
=== What was the problem in "initial program loader" that was mentioned in an FCC filing by Nintendo for 2DS? ===
'''Background:''' http://www.neogaf.com/forum/showthread.php?t=814624&page=1
=== What did SVC 0x74 in the ARM11 kernel do before it got stubbed? ===
=== What is the PTM abbreviation? ===
=== What is the PDN abbreviation? ===
=== Why is the DTCM not used anywhere except bootrom? ===
'''Background:''' Bootrom is known to use part of DTCM as state, memsetting it to 0 when it's done. After that, it is never used again.

Titles

2016-11-02T05:06:41Z

WulfyStylez: .cmd files

The Nintendo 3DS utilizes a similar title-based organization as seen in the Wii and DSi platforms. The update server is located [http://nus.cdn.c.shop.nintendowifi.net/ccs/download/ here]. When using SSL, the update/shop servers must be accessed via SSLv3.

For a list of 3DS titles see the [[Title list]].

= Title IDs =

The organization of Title IDs has not been documented fully yet. Region info isn't stored in title IDs however there does appear to be evidence that the regions are sequential, similar to how Wii System Menu Updates are ordered: JPN USA EUR KOR and CHN (introduced with the DSi). 3DS has one additional region: TWN.

Note: The terms 'Title ID', 'Partition ID' and 'Media ID' are interchangeable.

'''TitleID Structure''': 0xCCCCABCDLLLLLLRR

* CCCC defines the console '''Platform''' (5=WiiU, 4=3DS, 3=DSi, 1=[http://wiibrew.org/wiki/Title_database Wii])
* ABCD defines the '''Content Category''' of the title, Demo, DLPChild, etc.
* LLLLLL For CTR titles, this is the title's '''Unique ID'''. For TWL converted titles this is in two sections grouped as SSLLLL. SS is the old title identification used by the DSi and is made redundant by 'ABCD'. LLLL is the TWL title's 'Unique ID'. There are restrictions on the Unique ID, see below for more info.
* RR This is the Title ID '''Variation''', and has various uses.

'''Content Categories''':

This u16 is a collection bit mask flag. Each Category is a group of one or more bit masks.

Specific Bitmask Flags:
{| class="wikitable" border="1"
|-
! Category
! Bitmask
|-
| Normal
| 0x0
|-
| DlpChild
| 0x1
|-
| Demo
| 0x2
|-
| Contents
| 0x3
|-
| AddOnContents
| 0x4
|-
| Patch
| 0x6
|-
| CannotExecution
| 0x8
|-
| System
| 0x10
|-
| RequireBatchUpdate
| 0x20
|-
| NotRequireUserApproval
| 0x40
|-
| NotRequireRightForMount
| 0x80
|-
| CanSkipConvertJumpId
| 0x100
|-
| TWL
| 0x8000
|}

* TWL Category bit mask are carried over from original TWL category bitmasks (ignoring bit mask 0x8000), so TWL system titles have the bitmask of 0x8001.

* System titles (TWL and CTR) are eligible to be updated during a System Update.

* Bit Mask 0x4000 appears to be reserved, as it renders the ''TWL'' and ''System'' bit masks useless.

'''Unique ID Restrictions''':

For the CTR titles, there appears to be is a correlation between Unique IDs (UID) and 3DS 'title types'. For developer titles this is known(shown below), and retail titles *appear* to follow suite. It is unknown if this correlation is enforced on retail units, or if it is just for organisation purposes.

{| class="wikitable" border="1"
|-
! TITLE TYPE
! UNIQUE ID RANGE
|-
| System
| 0x0 - 0x2FF
|-
| Application
| 0x300 - 0xF7FFF
|-
| Evaluation
| 0xF8000 - 0xFEFFF (?)
|-
| Prototype*
| 0xFF000 - 0xFF3FF
|-
| Developer
| 0xFF400 - 0xFF7FF (?)
|}
<nowiki>*</nowiki>On the home menu, titles with UIDs within the 'Prototype' range, appear on the home menu after install without the gift fanfare.

ProgramID/titleID low bitmask 0xF0000000(uniqueID bitmask 0xF00000) seems to be related to which hardware the title is allowed to run on. 3DS code tends to clear this bitmask when handling programIDs. This bitmask is normally zero. When this is 0x2, this indicates that the title only runs on [[New_3DS]](that is, programID-low 0x20000000 / uniqueID 0x200000).

'''TitleID Variation''':

This u8 allows enumeration of titles from the same category and unique ID. Common uses are explained below:

* CTR System Titles: The 3DS has two copies of most modules/applets/archives for usage with either the NATIVE_FIRM or SAFE_MODE_FIRM. This is allowed for, by changing the title ID variation of the title to match the core version set by the FIRM it is designed to be used with:
{| class="wikitable" border="1"
|-
! RR
! MEANING
|-
| 02
| System Title (Core version 0x2)
|-
| 03
| SAFE_MODE System Title (Core version 0x3)
|}
Normally on retail SAFE_MODE ARM11 [[NCCH#CXI|CXI]] titles can't be launched, since the [[Configuration_Memory|system]] core version doesn't match the CXI exheader core version.

* Only most non-Normal Applications are known to utilise Title ID variation, this is explained in their respective sections on this page.

* [[3DS Development Unit Software|Dev Menu]] installs CTR Applications with a TitleID variation of 0x02 to the CTR NAND.

* Title ID variation is ignored for TWL titles, this value is carried over from the original TWL title ID and is used for region lock:

= Versions =

v## = 0xHHHH = 0bBBBBBBBB...

* The version major,minor and micro can be extracted from the version number by converting the 16 bit number to binary
* 6 bits : Major, this matches the NCCH remaster-version.
* 6 bits : Minor
* 4 bits : Micro ('Build' in some contexts)
* i.e. v2069 (Taken from 000400DB00017302) = 0b000010 000001 0101 means that the title version is v2.1.5. For reasons unknown, the CVer build, stored in the RomFS of the title, has always been zero (at time of writing), regardless of the CVer build in the TMD. So when predicting the firmware version, this should be taken into account.

= Data Structure =

Titles are installed to either the NAND (System and Application) or to the SD Card (Application only), and their respective directory locations are:

{| class="wikitable" border="1" style="margin: auto;"
|-
|
! scope="col"| [[Flash Filesystem|NAND]]
! scope="col"| [[SD Filesystem|SD]]
|-
! scope="row"| Title Data
| nand/title
| rowspan="2" | sdmc/Nintendo 3DS/<ID0>/<ID1>/title
|-
! scope="row"| Save Data
| nand/data/<ID0>/sysdata
|-
|}

ID0 is the first 0x10-bytes from a SHA256 [[nand/private/movable.sed|hash]] and ID1 is generated from the SD card CID.

Title data stored on the SD Card is encrypted with the console-unique [[nand/private/movable.sed|keyslots]], whereas NAND title data is stored as cleartext.

The base CTR for files stored under /title is likely based on the /title path, similar to extdata. This base CTR is unique per titleID and filename. The base CTR never changes after creation of each file.

When a newer version of a title is installed, the new .app content, .tmd, and .cmd(and .ctx for NAND titles) are written to the /title directory, however the old files here are not yet deleted. Once installation of the title is [[AMNet:InstallTitlesFinish|finalized]], the info from [[Title_Database|import.db]] is moved to [[Title_Database|title.db]] so that the system uses the newer files instead, then the old /title files are deleted.

The title data is contained in this directory structure (note that [[Title list#0004008C - Add-on Content (DLC)|DLC]] titles are stored in a different way):

{| class="wikitable" border="1" style="margin: auto;"
!
! scope="col"| NAND
! scope="col"| SD (non-DLC)
! scope="col"| SD (DLC)
|-
! scope="row"| Title Data:
|
<Title ID High>
└── <Title ID Low>
├── 00000000.ctx
└── content
├── <ContentID>.app
├── <ContentID>.tmd
└── cmd
└── <ContentID>.cmd
| rowspan="2" |
<Title ID High>
└── <Title ID Low>
├── 00000000.ctx
├── content
│ ├── <ContentID>.app
│ ├── <ContentID>.tmd
│ └── cmd
│ └── <ContentID>.cmd
└── data
└── 00000001.sav
| rowspan="2" |
0004008C
└── <Title ID Low>
├── 00000000.ctx
└── content
├── <ContentID>.tmd
├── 00000000
│ └── <ContentID>.app
└── cmd
└── <ContentID>.cmd

|-
! scope="row"| Save Data:
|
<SaveID0>
└── <SaveID1>
└── 00000001.sav
|}

"'''<ContentID>.tmd'''" - (The Content ID is a u32, initially: '''00000000''' when the title is first installed. Changing by an increment of +'''0x1''' for each title update the 3DS installs) This is the [[Title metadata]] associated with the title, it is encrypted with a console-unique [[AES|keyslot]]. The decrypted TMD is available on Nintendo's CDN server at "http://nus.cdn.c.shop.nintendowifi.net/ccs/download/TitleIDhere/tmd". Though CDN version of the title TMD has a certificate chain attached at the end of the TMD, so removing it will give you the 1:1 decrypted TMD. After installation the "<ContentID>.tmd" is redundant, because important title data is extracted and imported into the [[Title Database|title.db]] and ".cmd" files, but is however kept as a reference.

"'''<ContentID>.app'''" - (The Content ID is a u32, taken from the title's [[TMD]]) These files are [[NCCH]] files, where the entire file is encrypted with a console-unique [[AES|keyslot]](this is on top of the encryption of the NCCH contents). There can be more than one NCCH in this directory, as seen with .[[CCI]] files, the game executable ([[CXI]]) can be accompanied with additional non-executable NCCH files ([[NCCH#CFA|CFA]]) such as the electronic manual and DLP Child containers. Determining the function of the encrypted NCCH, is done by finding the Content Index of the "XXXXXXXX.app" file in the title's TMD(see above for retrieving decrypted TMD), interpreting the Content Index is as follows (does not apply to DLC content):

{| class="wikitable" border="1"
|-
! Index
! Content Type
|-
| 0000
| Main Executable (.[[NCCH#CXI|CXI]])(In the case of [[Title list|System Data Archives]], this is a [[NCCH#CFA|CFA]] file)
|-
| 0001
| Home Menu Manual (.[[NCCH#CFA|CFA]])
|-
| 0002
| DLP Child Container (.[[NCCH#CFA|CFA]])
|}

Unlike the TMD, a decrypted version of the NCCH files cannot be retrieved from Nintendo's CDN, the NCCH files do exist on Nintendo's CDN but are [[AES|encrypted]]. Decrypting CDN versions of content, requires the title's [[CommonETicket|ticket]], and the common key specified by an index in the [[CommonETicket|ticket]]. Of course editing/deleting ".app" files will have an effect. Deleting/renaming the manual ".app' will cause the manual not to load when clicked on. And deleting/renaming the executable ".app" will cause the application to not load, and the 3D Banner does not show(The banner is loaded each time from the game's executable NCCH when the home menu loads, it is not cached like the icon and name).

"'''<ContentID>.cmd'''" - (The Content ID is a u32, initially: '''00000001''' when the title is first installed. Changing by an increment of +'''0x1''' for each time the 3DS adds/removes '.app' files) This file contains data taken from the title's [[TMD]]. See the below table for the format of the cleartext .cmd file. The [[Title Database|Title.db]] contains the Content ID for the '.cmd' file, but does not contain a hash of the '.cmd' file. In addition it is also encrypted with a console-unique [[AES|keyslot]]. This acts as part of the DRM for installed titles, along with the [[Title Database|title.db]].

The below AES-MACs(including the last 0x10-bytes of the header) are only used for SD titles, and for NAND [[Title_list|download-play]] titles. For other titles, these MACs are set to all-zero.

{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
|-
| 0x0
| 0x4
| .cmd ContentID, for the .cmd filename. This is the beginning of the header.
|-
| 0x4
| 0x4
| Number of entries? Usually the same as the following u32.
|-
| 0x8
| 0x4
| Number of AESMACs? Usually the same as the preceding u32.
|-
| 0xC
| 0x4
| Unknown, usually (always?) 1.
|-
| 0x10
| 0x10
| AESMAC over contents?
|-
| 0x20
| 0x4*(No. of entries)
| List of contentIDs in (usually) descending order
|-
| 0x20 + 0x4*(No. of entries)
| 0x4*(No. of entries)
| List of contentIDs in (usually) ascending order
|-
| 0x20+0x8*(No. of entries)
| 0x10*(No. of entries)
| These are AESMACs, one for each content.
|}

Entries format:
{| class="wikitable" border="1"
|-
! Start
! Size
! Description
|-
| 0x0
| 0x4
| ContentID
|-
| 0x4
| 0x8
| Unknown
|}

'''"00000001.sav"''' - This is the title's encrypted [[Savegames|savegame]]. Renaming these savegames causes home-menu to hang while launching titles, modifying these saves results in the same corruption errors as other savegames.

'''"00000000.ctx"''' - This file encrypted with a console-unique [[AES|keyslot]] is temporarily stored on SD card while a title is being downloaded from the eShop, it is deleted after the download is completed. This contains an AP0000000000000000 cert used to sign the data following the cert, this cert is signed by the [[CTCert]].
The unknown signed data is likely an ECDSA public key. There's .ctx files stored under the /title directory for NAND CTR/TWL titles, however those use the [[CTXT]] format which is completely different from this SD .ctx format. These .ctx files for NAND/SD titles only exist for titles where installation was not yet finalized(like when a system update install was not yet finalized).

=== DLC Titles ===

DLC titles have a different directory structure to most installed titles. This is because all DLC content for a given title is installed under the same Title ID, but DLC add-ons are usually separate purchases, hence the structure altered so any combination of DLC content can be installed. DLC titles can receive 'updates', this is usually in the form of more DLC content and/or DLC bug fixes. Individual DLC content can only be managed from with-in the application using the DLC.

'''"00000000"''' - This extra directory only found in DLC titles, contains the DLC [[NCCH]] content.

"'''<ContentID>.tmd'''" - This is not modified by the 3DS, and contains the details for all DLC content(installed or not).

"'''<ContentID>.cmd'''" - This contains entries for all '''installed''' DLC [[NCCH]] content, and is updated (<ContentID> will change) every time DLC content is installed/removed.

=Installing other-model system-titles=
When finalizing title-install of already downloaded Old3DS system-titles to a New3DS NAND image with New3DS NATIVE_FIRM, the end result is that the New3DS version (TID-low bitmask 0x20000000) of those titles gets deleted.

It's unknown where this behaviour is implemented (might be NIM, AM, or AMXPXI).

CTXT

2016-11-02T00:01:25Z

WulfyStylez:

This page describes the structure of the .ctx files located at [[Title_Data_Structure|nand:/title/<titlepath>/00000000.ctx]].

=Structure=
{| class="wikitable" border="1"
! Offset
! Size
! Description
|-
| 0x0
| 0x10
| AESMAC over SHA256 of bytes 0x10..0x30
|-
| 0x10
| 0x4
| Magic "CTXT"
|-
| 0x14
| 0x4
| Value 0 usually?
|-
| 0x18
| 0x4
| Value 1 usually?
|-
| 0x1C
| 0x4
| Value 0 usually?
|-
| 0x20
| 0x8
| TitleID
|-
| 0x28
| 0x4
| Unknown u32
|-
| 0x2C
| 0x1D4
| All-zero
|-
| 0x200
| 0x10
| AES-MAC?
|-
| 0x210
| 0x8
| TitleID
|-
| 0x218
| 0x4
| contentID for contentindex0
|-
| 0x21C
| 0x4
| Unknown u32 for contentindex0
|-
| 0x220
| 0x8
| content-size for contentindex0
|-
| 0x228
| 0x8
| Usually zero?
|-
| 0x230
| 0x3CC
| Usually 0xFF?
|-
| 0x5FC
| 0x4
| This has the same value as the u32 at 0x28.
|}

ARM7 Registers

2016-05-13T01:59:07Z

WulfyStylez: RTC is a guess, but what else is a hardware device with up to 0x8 stored at power-off?

The 3DS utilizes an onboard ARM7 core to handle TWL_FIRM and AGB_FIRM's ARM7 requirements. This is due to the fact that much of the hardware used by both ARM7 and ARM9 is (evidently) not physically hooked up to ARM11. Thus, ARM11 cannot simply emulate ARM7.

ARM7 has the AGB BIOS implemented in hardware. The BIOS is completely identical to the original AGB BIOS. The system is booted silently by calling SWI 0x1 (RegisterRamReset), followed by jumping to the code that does SWI 0x0 (SoftReset) to finish booting. The boot splash is still in BIOS, however, and can be seen by calling (or replacing one of the previous interrupts with) SWI 0x26 (HardReset).
= Registers =
ARM9 interfaces with the ARM7 through the following registers:
{| class="wikitable" border="1"
|-
! Name
! Address
! Width
|-
| ARM7_CNT
| 0x10018000
| 0x1
|-
| ARM7_CODE
| 0x10018080
| ?
|-
| ARM7_SAVE_MODE
| 0x10018100
| 0x2
|-
| ARM7_?_CNT
| 0x10018104
| 0x2
|-
| ARM7_RTC_CNT?
| 0x10018108
| 0x2
|-
| ?
| 0x10018110
| 0x4
|-
| ?
| 0x10018114
| 0x4
|-
| ARM7_RTC_LO?
| 0x10018118
| 0x4
|-
| ARM7_RTC_HI?
| 0x1001811C
| 0x4
|-
| ARM7_SAVE_CFG
| 0x10018120
| 0x10
|}

== ARM7_CNT ==
This seems to control the mode of the ARM7. 1 = TWL, 2 = AGB.

== ARM7_CODE ==
This is the first code that will be run after execution begins. TwlProcess9 uses this to put ARM7 in a loop (TWL), and to set the POSTFLG and branch to more copied code (AGB).This doesn't seem to start execution by itself.

== ARM7_SAVE_MODE ==
This tells the save storage emulation hardware which device type to emulate (EEPROM, 512k flash, and SRAM are all that have been spotted). This comes directly from the [[3DS_Virtual_Console#Footer|ROM footer]].

== ARM7_RTC(?) ==
These registers may be used to control a realtime clock. To set or read the data here, first ARM7_RTC_CNT's bit 15 is waited on. Next ARM7_RTC_CNT is set to zero.

For a write: the two registers are written, a 1 is written to ARM7_RTC_CNT, and it is waited on the same as before. Afterwards if bit 14 is not set in ARM7_RTC_CNT, the value was set successfully.

For a read: a 2 is written to ARM7_RTC_CNT, it's waited on again. Afterwards, if bit 14 is not set, the RTC can be read. Presumably the hardware can be re-enabled by writing a zero to ARM7_RTC_CNT at this point, but AGB_FIRM does not.

== ARM7_SAVE_CFG ==
This is copied from rom footer + 0x10. It presumably configures details about storage, such as IDs, and likely allows enabling the RTC for games which need it. Format of this data is unknown, and slightly difficult to determine without some hardware poking.

= Memory map =
The virtual memory mapping for the ARM7 is the same as for the [[Memory_layout#TWL_FIRM_Userland_Memory|other core]]. However, it has additional internal memory mapped to it. Interestingly enough, much of this memory seems to lie within ARM9's own "internal memory."
*0x08060000 -> 0x03800000, ARM7-WRAM (64KB)
*0x080B0000 -> 0x03000000, GBA on-chip WRAM (32KB)
*0x080C0000 -> EEPROM/SRAM/Flash (0x10018104 must be set to 1 before reading memory here, and restored to its previous value afterwards)
*0x01FFC000 -> 0x01000000, ARM9 ITCM under TWL (16KB)

MCU Services

2016-03-24T21:24:33Z

WulfyStylez: /* MCU service "mcu::HWC" */

Only one session can be open per service at a time. If a session is already open for a service, MCU module will wait for the thread handling the session to terminate(triggered by the session being closed by the user process), then it accepts the new session. The commands for each service are handled by separate threads.

=MCU camera service "mcu::CAM"=
{| class="wikitable" border="1"
|-
! Command Header
! Description
|-
| 0x0001....
| ?
|-
| 0x0002....
| ?
|}

=MCU GPU service "mcu::GPU"=
{| class="wikitable" border="1"
|-
! Command Header
! Description
|-
| 0x00010000
| GetLcdPowerState. This writes the value of I2C-MCU register 0xf bit6 to u8 cmdreply[2], and the value of bit5 from that register to u8 cmdreply[3].
|-
| 0x0002....
| SetLcdPowerState. This writes the upper LCD bits of MCU register 0x22.
|-
| 0x0003000
| GetGpuLcdInterfaceState. This writes the value of I2C-MCU register 0xf bit7 to u8 cmdreply[2].
|-
| 0x0004....
| SetGpuLcdInterfaceState. This writes the lower two bits of MCU register 0x22.
|-
| 0x0005....
| ?
|-
| 0x0006....
| ?
|-
| 0x0007....
| ?
|-
| 0x0008....
| ?
|-
| 0x00090000
| GetMcuFwVerHigh. Called by gsp module
|-
| 0x000A0000
| GetMcuFwVerLow. Called by gsp module
|-
| 0x000B....
| Set3dLedState
|-
| 0x000C....
| Get3dLedState
|-
| 0x000D....
| GetMcuGpuEvent
|-
| 0x000E....
| ?
|}

=MCU HID service "mcu::HID"=
{| class="wikitable" border="1"
|-
! Command Header
! Description
|-
| 0x00010000
| ?
|-
| 0x0002....
| ?
|-
| 0x0003....
| ?
|-
| 0x0004....
| ?
|-
| 0x0005....
| ?
|-
| 0x0006....
| ?
|-
| 0x0007....
| Get3dSliderState
|-
| 0x0008....
| ?
|-
| 0x00090000
| ?
|-
| 0x000A0000
| ?
|-
| 0x000B....
| ?
|-
| 0x000C....
| GetMcuHidEvent
|-
| 0x000D0000
| ?
|-
| 0x000E0000
| [[MCUHID:GetSoundVolume|GetSoundVolume]]
|}

=MCU service "mcu::RTC"=
{| class="wikitable" border="1"
|-
! Command Header
! Description
|-
| 0x0001....
| SetSystemClock (RTC)
|-
| 0x0002....
| GetSystemClock (RTC)
|-
| 0x0003....
| ?
|-
| 0x0004....
| ?
|-
| 0x0005....
| ?
|-
| 0x0006....
| ?
|-
| 0x0007....
| ?
|-
| 0x0008....
| ?
|-
| 0x0009....
| ?
|-
| 0x000A....
| ?
|-
| 0x000B....
| ?
|-
| 0x000C....
| ?
|-
| 0x000D....
| ?
|-
| 0x000E....
| ?
|-
| 0x000F....
| ?
|-
| 0x0010....
| ?
|-
| 0x0011....
| ?
|-
| 0x0012....
| ?
|-
| 0x0013....
| ?
|-
| 0x0014....
| ?
|-
| 0x0015....
| ?
|-
| 0x0016....
| ?
|-
| 0x0017....
| ?
|-
| 0x0018....
| ?
|-
| 0x0019....
| ?
|-
| 0x001A....
| ?
|-
| 0x001B....
| ?
|-
| 0x001C....
| ?
|-
| 0x001D....
| ?
|-
| 0x001E....
| ?
|-
| 0x001F0040
| SetPedometerRecordingMode
|-
| 0x00200000
| GetPedometerState
|-
| 0x0021....
| ?
|-
| 0x0022....
| ?
|-
| 0x0023....
| ?
|-
| 0x0024....
| GetMcuRtcEvent
|-
| 0x0025....
| ?
|-
| 0x0026....
| ?
|-
| 0x0027....
| ?
|-
| 0x0028....
| ?
|-
| 0x0029....
| ?
|-
| 0x002A0000
| GetShellState. This writes the value of I2C-MCU register 0xf bit1 to u8 cmdreply[2].
|-
| 0x002B0000
| GetAdapterState. This writes the value of I2C-MCU register 0xf bit3 to u8 cmdreply[2].
|-
| 0x002C0000
| GetBatteryChargeState. This writes the value of I2C-MCU register 0xf bit4 to u8 cmdreply[2].
|-
| 0x002D0000
| [[MCURTC:GetBatteryLevel|GetBatteryLevel]]
|-
| 0x002E....
| ?
|-
| 0x002F....
| ?
|-
| 0x0030....
| ?
|-
| 0x0031....
| ?
|-
| 0x0032....
| [[MCURTC:PowerOff|PowerOff]] (writes 0x1 to i2c MCU device, reg 0x20)
|-
| 0x0033....
| [[MCURTC:HardwareReboot|HardwareReboot]] (writes 0x4 to i2c MCU device, reg 0x20)
|-
| 0x0034....
| ?
|-
| 0x0035....
| Writes 0x10 to i2c MCU device, reg 0x20
|-
| 0x0036....
| SetWatchdogTimer
|-
| 0x0037....
| GetWatchdogTimer
|-
| 0x0038....
| ?
|-
| 0x0039....
| ?
|-
| 0x003A....
| ?
|-
| 0x003B0640
| [[MCURTC:SetInfoLEDPattern|SetInfoLEDPattern]]
|-
| 0x003C0040
| [[MCURTC:SetInfoLEDPatternHeader|SetInfoLEDPatternHeader]]
|-
| 0x003D0000
| [[MCURTC:GetInfoLEDStatus|GetInfoLEDStatus]]
|-
| 0x003E....
| ?
|-
| 0x003F....
| ?
|-
| 0x0040....
| ?
|-
| 0x0041....
| ?
|-
| 0x00420040
| [[MCURTC:SetBatteryEmptyLEDPattern|SetBatteryEmptyLEDPattern]]
|-
| 0x0043....
| ?
|-
| 0x0044....
| ?
|-
| 0x0045....
| ?
|-
| 0x0046....
| ?
|-
| 0x0047....
| ?
|-
| 0x0048....
| ?
|-
| 0x0049....
| ?
|-
| 0x004A....
| ?
|-
| 0x004B....
| ?
|-
| 0x004C....
| ?
|-
| 0x004D....
| [[MCURTC:ReadHidFlagRegister|ReadHidFlagRegister]] (reads i2c MCU device, reg 0x10)
|-
| 0x004E....
| [[MCURTC:PublishHidNotifications|PublishHidNotifications]]
|-
| 0x004F....
| Sets some flag (otherwise set when uploading MCU firmware)
|-
| 0x0050....
| Returns the above flag
|-
| 0x0051....
| SetLegacyPoweroff
|-
| 0x00520000
| IsLegacyPoweroff
|-
| 0x0053....
| ?
|-
| 0x0054....
| ?
|-
| 0x0055....
| ?
|-
| 0x0056....
| ?
|-
| 0x0057....
| ?
|-
| 0x0058....
| ?
|-
| 0x0059....
| SetLegacyJumpProhibitedFlag
|-
| 0x005A....
| GetLegacyJumpProhibitedFlag
|}

Note that using invalid input with these InfoLED/SetBatteryEmptyLEDPattern commands(especially SetInfoLEDPattern) can cause the system to be bricked(however the boot failure may not begin immediately after using the invalid parameters). For the bitmasks controlling these LEDs, bit clear = LED enable, bit set = LED disable? These notification LEDs(red LED, green LED, blue LED, ...) can only be enabled/disabled, nothing more.

=MCU sound service "mcu::SND"=
{| class="wikitable" border="1"
|-
! Command Header
! Description
|-
| 0x0001....
| GetSoundVolume
|-
| 0x0002....
| ?
|-
| 0x0003....
| ?
|}

=MCU wifi service "mcu::NWM"=
{| class="wikitable" border="1"
|-
! Command Header
! Description
|-
| 0x0001....
| SetWiFiLedState
|-
| 0x0002....
| GetWiFiLedState
|-
| 0x0003....
| Sets GPIO 0x20 high/low?
|-
| 0x0004....
| Gets GPIO 0x20 high/low?
|-
| 0x0005....
| Sets GPIO 0x40000 high/low?
|-
| 0x0006....
| Gets GPIO 0x40000 high/low?
|-
| 0x0007....
| Sets a FIRM WiFi-state-related flag?
|-
| 0x0008....
| Gets the above flag
|}

=MCU service "mcu::HWC"=
{| class="wikitable" border="1"
|-
! Command Header
! Description
|-
| 0x0001....
| GetMcuRegister? Seems to read an arbitrary register (by parameter)
|-
| 0x0002....
| SetMcuRegister?
|-
| 0x0003....
| ?
|-
| 0x0004....
| ?
|-
| 0x0005....
| GetBatteryLevel
|-
| 0x0006....
| ?
|-
| 0x0007....
| ?
|-
| 0x0008....
| ?
|-
| 0x0009....
| Set3dLedState
|-
| 0x000A0640
| This is the same as [[MCURTC:SetInfoLEDPattern]].
|-
| 0x000B....
| GetSoundVolume
|-
| 0x000C....
| ?
|-
| 0x000D....
| ?
|-
| 0x000E....
| ?
|-
| 0x000F....
| GetRtcTime
|-
| 0x00100000
| GetMcuFwVerHigh
|-
| 0x00110000
| GetMcuFwVerLow
|}

=MCU service "mcu::PLS"=

RTC-related? Each of these seems to retrieve a second counter from a different RTC register.

{| class="wikitable" border="1"
|-
! Command Header
! Description
|-
| 0x0001....
| ?
|-
| 0x0002....
| ?
|-
| 0x0003....
| ?
|-
| 0x0004....
| ?
|-
| 0x0005....
| ?
|-
| 0x0006....
| ?
|-
| 0x0007....
| ?
|-
| 0x0008....
| ?
|-
| 0x0009....
| ?
|}

=MCU codec service "mcu::CDC"=
{| class="wikitable" border="1"
|-
! Command Header
! Description
|-
| 0x00010000
| ?
|}

=New3DS=
The Old3DS/New3DS MCU sysmodules are identical except that the MCU firmware binary written via I2C is different. The size of that binary is the same. The only different words in .text are for the version of that MCU fw binary.

=MCU firmware versions=

These reside in mcu-module .rodata, are uploaded to MCU register 0x05 and are usually size 0x4003 bytes. (0x4000 bytes with 3 byte magic "jhl"?)

There exists an alternate code path where uploading is done using register 0x3B (decided by making some nonsense conclusions about registers 0x0F and 0x10). This may be a "hack" around early versions of MCU? Register 0x3B is RTC-related on recent versions of MCU, and the "nonsense" condition is not met even on factory MCU firmware.

{| class="wikitable" border="1"
|-
! Title version
! Firmware
|-
| New3DS v8192/safe v9217 (latest)
| 19.56
|-
| Old3DS v6145 to v8192 (latest)
| 18.37
|-
| Old3DS v5122
| 18.35
|-
| Old3DS v4102
| 18.30
|-
| Old3DS v2048
| 17.52
|-
| Old3DS safe v0
| 17.20
|-
| Old3DS factory
| 17.07
|}

Config Savegame

2016-03-24T20:59:20Z

WulfyStylez: /* Configuration blocks */

This page describes the format of the [[Config_Services|Cfg]] [[System_SaveData|NAND]] savegame. These blocks can be accessed with the Cfg service commands.

==Structure of save-file "/config"==
{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
|-
| 0x0
| 0x2
| Total entries
|-
| 0x2
| 0x2
| Data entries offset
|-
| 0x4
| 0x4558
| Block entries
|-
| 0x455C
|
| Data for the entries
|}

The filesize for this /config file is 0x8000-bytes.

==Configuration block entry ==
{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
|-
| 0x0
| 0x4
| BlkID
|-
| 0x4
| 0x4
| Offset to the data for this block when size is >4, otherwise this word is the data for this block
|-
| 0x8
| 0x2
| Size
|-
| 0xA
| 0x2
| Flags
|}

==Configuration blocks==
{| class="wikitable" border="1"
|-
! BlkID
! Size
! Flags
! Description
|-
| 0x00000000
| 0x2
| ?
| Config savegame version?
|-
| 0x00030001
| 0x8
| 0xE
| ? (zeroed)
|-
| 0x00040000
| 0x10
| 0x8
| ?
|-
| 0x00040001
| 0x1C
| 0x8
| ?
|-
| 0x00040002
| 0x12
| 0x8
| ?
|-
| 0x00040003
| 0xC
| 0x8
| ?
|-
| 0x00050001
| 0x2
| 0x8
| ?
|-
| 0x00050002
| 0x38
| 0x8
| ?
|-
| 0x00050003
| 0x20
| 0x8
| ?
|-
| 0x00050005
| 0x20
|?
| Stereo camera settings?
|-
| 0x00050006
| 0x2
| 0x8
| ?
|-
| 0x00070001
| 0x1
|?
| Sound output mode?
|-
| 0x00080000
| 0xC00
| 0x2?
| WiFi configuration slot 0
|-
| 0x00080001
| 0xC00
| 0x2?
| WiFi configuration slot 1
|-
| 0x00080002
| 0xC00
| 0x2?
| WiFi configuration slot 2
|-
| 0x00090000
| 0x8
| 0x2?
| This contains a u64 ID, used by processes using [[NWMUDS:Initialize]]. The first word is the same as [[CfgS:GetLocalFriendCodeSeed|LocalFriendCodeSeed]], while the latter is a separate random word
|-
| 0x00090001
| 0x8
| 0xE
| This console-unique u64 used by [[Cfg:GenHashConsoleUnique|GenHashConsoleUnique]] is generated with the LocalFriendCodeSeed and with random data
|-
| 0x000A0000
| 0x1C
| 0xE
| Username
|-
| 0x000A0001
| 0x2
| 0xE
| Birthday (u8 month, u8 day)
|-
| 0x000A0002
| 0x1
| 0xA
| Language

|-
| 0x000B0000
| 0x4
| 0x8
| CountryInfo
|-
| 0x000B0001
| 0x800
| 0x2?
| Country name in UTF-16, every 0x80-bytes is an entry for each language, in the order of the Language table below (not all entries are set)
|-
| 0x000B0002
| 0x800
| 0x2?
| State name in UTF-16, every 0x80-bytes is an entry for each language
|-
| 0x000B0003
| 0x4
| 0xE
| Pair of 16-bit values, meaning unknown but related to address (ZIP code?)

|-
| 0x000C0000
| 0xC0
| 0x8
| Restricted photo exchange data, and other info
|-
| 0x000C0001
| 0x14
|?
| Same as above?
|-
| 0x000D0000
| 0x4
| 0x2
| u16 at offset 0x0: [[SMDH#EULA_Version|EULA Version]] which was agreed to.
|-
| 0x000F0000
| 0x10
| 0x8?
| Unknown, used by [[NS]] on dev-units for [[SVC|svcKernelSetState]], where Type is 6. During NS startup on debug-units, NS compares the u32 from +8 in this config-block with the [[Configuration_Memory#APPMEMTYPE|APPMEMTYPE]]. When those don't match NS starts a FIRM-launch (with the same FIRM titleID as the currently running one) to boot into a FIRM with the APPMEMTYPE value from this config-block
|-
| 0x000F0004
| 0x4
| 0x8?
| The first u8 is the System-Model [[Cfg:GetSystemModel|value]], the last 3-bytes are unknown
|-
| 0x00110000
| 0x4
|?
| The low u16 indicates whether the system setup is required, such as when the system is booted for the first time or after doing a [[System Settings|System Format]]: 0 = setup required, non-zero = no setup required
|-
| 0x00110001
| 0x8
| 0xA?
| TitleID of the menu to launch, used by [[NS]] on dev units (this block can be edited on dev units with [[3DS Development Unit Software#Config|Config]])
|-
| 0x00120000
| 0x8
| 0x8
| ?
|-
| 0x00130000
| 0x4
|?
| If response is 0x100 then debug mode is enabled.
|-
| 0x00160000
| 0x4
| 0x8?
| Unknown, first byte is used by config service-cmd [[Config_Services|0x00070040]]. (Unknown whether the last 3-bytes are used)
|}

The developer unit TID block only exists on developer units.

===Languages===
{| class="wikitable" border="1"
|-
! ID
! Description
|-
| 0
| JP
|-
| 1
| EN
|-
| 2
| FR
|-
| 3
| DE
|-
| 4
| IT
|-
| 5
| ES
|-
| 6
| ZH
|-
| 7
| KO
|-
| 8
| NL
|-
| 9
| PT
|-
| 10
| RU
|-
| 11
| TW
|}

===CountryInfo===
{| class="wikitable" border="1"
|-
! Byte
! Description
|-
| 0
|?
|-
| 1
|?
|-
| 2
|?
|-
| 3
| Country code, same as DSi/Wii country codes. Value 0xFF is invalid.
|}

===0x000A0000 Block===
{| class="wikitable" border="1"
|-
! Byte
! Description
|-
| 0x0-0x13
| UTF-16 username, with no NULL-terminator.
|-
| 0x14-17
| Usually zero?
|-
| 0x18-0x1B
| u32 NGWord version the username was last checked with. If this value is less than the u32 stored in the NGWord CFA "romfs:/version.dat", the system then checks the username string with the bad-word list CFA again, then updates this field with the value from the CFA
|}

TIMER Registers

2016-03-07T04:42:46Z

WulfyStylez: kinda important!

There are 4 timers. These timers run at a frequency of ~67027.964kHz.

= Registers =
{| class="wikitable" border="1"
! Old3DS
! Name
! Address
! Width
! Used by
|-
| style="background: green" | Yes
| [[#TIMER_VAL|TIMER_VAL]](n)
| 0x10003000 + 4*n
| 2
|
|-
| style="background: green" | Yes
| [[#TIMER_CNT|TIMER_CNT]](n)
| 0x10003002 + 4*n
| 2
|
|}

== TIMER_VAL ==
Writing to REG_TMxVAL loads a starting value for one of the 4 timers, while reading it will show the current timer value.

== TIMER_CNT ==
{| class="wikitable" border="1"
|+ REG_TMxCNT
! BIT
! DESCRIPTION
|-
| 0-1
| Prescaler select (0=F/1, 1=F/64, 2=F/256, 3=F/1024)
|-
| 2
| Count-up (0=Disabled, 1=Enabled)
|-
| 3-5
| Not used
|-
| 6
| IRQ enable (0=Disabled, 1=IRQ on timer value overflow)
|-
| 7
| Start/Stop (0=Stop, 1=Start)
|}

== Count-up ==
When count-up is enabled, the timer value will increase every time the previous timer overflows.

3DS System Flaws

2016-01-19T20:25:54Z

WulfyStylez: this has been leaking all over the place for the last year so i'm just throwing it up for the greater good

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. 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]]
|-
| 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]]. This leaves the [[OTP Registers|0x10012000]]-region unprotected (this region should be locked early during boot!). Since it's never locked, you can dump it once you get ARM9 code execution. See [[OTP Registers|here]] regarding the data stored there.

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.

This flaw resurged when it gained a new practical use: retrieving the OTP data for a New3DS console in order to decrypt the key data used in arm9loader. This was performed by downgrading to a vulnerable system version. By accounting for differences in CTR-NAND crypto (see partition encryption types [[Flash_Filesystem#NAND_structure|here]]), it is possible to boot a New3DS using Old3DS firmware 1.0-2.x, and retrieve the required OTP data using this flaw.
| Dumping of the [[OTP Registers|OTP]] area
| [[3.0.0-5|3.0.0-X]]
|
| February 2015
| [[User:Plutooo|plutoo]], Normmatt independently
|}

== 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]]
| [[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
|-
| [[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-01-19T19:41:56Z

WulfyStylez: this can be worked around as an initial entrypoint but it's not really intended as that. also cleanup on base exploit description - k9l keys aren't really relevant to this hack. standby for known-plaintext description.

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

== 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]]
|-
| 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]]. This leaves the [[OTP Registers|0x10012000]]-region unprotected (this region should be locked early during boot!). Since it's never locked, you can dump it once you get ARM9 code execution. See [[OTP Registers|here]] regarding the data stored there.

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.

This flaw resurged when it gained a new practical use: retrieving the OTP data for a New3DS console in order to decrypt the key data used in arm9loader. This was performed by downgrading to a vulnerable system version. By accounting for differences in CTR-NAND crypto (see partition encryption types [[Flash_Filesystem#NAND_structure|here]]), it is possible to boot a New3DS using Old3DS firmware 1.0-2.x, and retrieve the required OTP data using this flaw.
| Dumping of the [[OTP Registers|OTP]] area
| [[3.0.0-5|3.0.0-X]]
|
| February 2015
| [[User:Plutooo|plutoo]], Normmatt independently
|}

== 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]]
| [[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
|-
| [[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]]
|}

OTP Registers

2015-12-15T14:46:43Z

WulfyStylez: note on console-unique keys and analog in ITCM being memset

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.

Originally the console-unique TWL keyinit + region disable was done by Kernel9. 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 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

2015-12-15T14:20:55Z

WulfyStylez:

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

Originally the console-unique TWL keyinit + region disable was done by Kernel9. 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 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.
|}

NAND Redirection

2015-11-04T01:25:05Z

WulfyStylez: q:3c

NAND redirection is an umbrella term for methods used to redirect [[Flash_Filesystem|NAND]] reads and writes from the actual system storage (in this context called sysNAND) to the SD card (or technically, any other data source). Among other things, this allows for accessing more recent (in some cases fully updated) system versions (installed on the redirection source) while keeping access to full-control exploits (through the old system installed on sysNAND).

=== General Idea ===

The SD filesystem, being a FAT32 partition, can be shrinked and relocated easily. As such, it is easy to make room on the SD card for a full NAND image. By not listing the NAND image partition in the SD card's Master Boot Record (the first 512 bytes of data on the device which is responsible for providing information on the contained filesystems), the NAND image does not interfere with regular SD card access. The actual redirection needs to be done through use of a [[FIRM|firmware]] modification depending on the location of the NAND image on the SD card. Two common approaches for this are known as EmuNAND and RedNAND, albeit these terms are sometimes also used as synonyms for the concept of NAND redirection in general.

=== RedNAND ===

RedNAND places the full NAND image at byte offset 512 on the SD card. The modified firmware hence needs to offset all NAND reads and writes by 512 bytes.

=== EmuNAND ===

Calling the NAND image size N, EmuNAND places bytes [512:N-1] of the NAND image at byte offset 512 on the SD card, and bytes [0:511] at byte offset N. The modified firmware needs to make sure that NAND reads/writes to the first 512 bytes are redirected properly, but leaves all other accesses unmodified.

=== Restrictions on New 3DS ===

If the sysNAND of a New 3DS console is below system version 9.6, it is not currently publicly possible to have NAND redirection work with a redirected NAND of any system version since 9.6. This is because the [[AES|AES engine keyslots]] introduced for NCCH decryption with 9.6 are initialized by arm9loader using data generated from [[OTP Registers|OTP data] upon boot. Since OTP access is blocked via [[CONFIG_Registers#CFG_SYSPROT9|CFG_SYSPROT9]] shortly after that, it's impossible to perform this keyslot initialization at any later time.

3DS Virtual Console

2015-11-01T20:04:41Z

WulfyStylez: /* NAND Savegame */

There's two types of VC titles: regular VC titles, and dedicated GBA VC titles.

=Regular VC=
Regular VC titles: an emulator application + VC ROM in the NCCH [[RomFS]](among other things in the RomFS). The emulator build includes support for all supported VC platforms, not specific to just the included ROM platform.

This emulator includes GBA support, however the GBA emulation for this this is somewhat slow. This was presumably implemented before AGB_FIRM was.

Unlike Wii VC, the 3DS VC ROMs for NES use the "TNES" header.

==RomFS==
* "rom:/rom/" This directory contains the ROM file(s). Filenames used under here don't matter: the filename is determined by the emulator app by doing a directory read.
* "rom:/shaders/" This directory contains GPU shaders used by the emulator app: .shbin, .csdr, and .obj.
* "rom:/VCM/" This directory contains graphics, audio, and text used by the emulator app.
* "rom:/agb.bin" GBA BIOS.
* "rom:/buildtime.txt" Emulator app build timestamp.
* "rom:/config.ini" Emulator configuration .ini, contains sections for all supported 3DS VC platforms.
* "rom:/<rom_name>.patch" rom_name = filename from the rom directory. This .ini contains patches for the ROM.
* "rom:/shader.shbin" GPU shader.

=GBA VC=
GBA VC is run by [[FIRM|AGB_FIRM]]. RomFS isn't used for GBA VC titles, but can be found empty within GBA VC titles. The NCCH [[ExeFS]] contains the same files as a normal application. The [[ExeFS]]:/.code contains the GBA VC ROM followed by a 0x360 byte long footer.

===Footer===
All values in the GBA VC footer are little-endian.
{| class="wikitable" border="1"
|-
! START
! SIZE
! DESCRIPTION
|-
| 0x004
| 0x4
| GBA ROM Filesize
|-
| 0x008
| 0x4
| Save type (see below)
|-
| 0x020
| 0x1
| Manufacturer info select (see below)
|-
| 0x024
| 0x300
| Unknown, three different types of this data have been observed.
|-
| 0x338
| 0x4
| GBA ROM Filesize
|-
| 0x344
| 0x4
| GBA ROM Filesize
|-
| 0x350
| 0x4
| Magic '.CAA'
|-
| 0x35A
| 0x2
| High two bytes of GBA ROM file size
|}

Save types:
* EEPROM (various sizes, IDs specified in footer): 0x2
* SRAM/FRAM (128k): 0xE
* Flash (512k): 0x9

Support for RTC and 1m-flash chips is not implemented in AGB_FIRM.

Manufacturer info:
GBA games' SDK-provided save code only supports a range of manufacturers from which Nintendo was buying memory from around the time of that game's development. As such, most games don't support a generic emulated storage chip. This byte appears to select a manufacturer info set to emulate. This has been observed to be 0x90, 0xC0, and (in one EEPROM-based game), 0x80.
* SRAM games up to and including V111 use 0xC0. Above use 0x90.
* FRAM V103 uses 0xC0. V104+ don't exist, and lower versions also likely use 0xC0.
* Flash V124 was observed 0x90, V131 was observed 0xC0.
* EEPROM-based games vary wildly, since they can likely specify chip info in the 0x10-region of the footer.

===NAND Savegame===
AGB_FIRM saves its active save memory to NAND on exit, this is then immediately picked up by NATIVE_FIRM on reboot by checking [[CONFIG_Registers#CFG_BOOTENV|CFG_BOOTENV]]. From there, this is verified and copied out to SD. The savegame format is as follows:
{| class="wikitable" border="1"
|-
! START
! SIZE
! DESCRIPTION
|-
| 0x0
| 0x4
| Magic ('.SAV')
|-
| 0x4
| 0xC
| Always 0xFF
|-
| 0x10
| 0x10
| AES-MAC of the SHA256 hash of 0x30..0x200 + the entire save itself, keyslot 0x24, keyY from process9 .rodata
|-
| 0x20
| 0x10
| Always 0xFF
|-
|-
| 0x30
| 0x40
| Always 0x1
|-
| 0x34
| 0x4
| Number of times saved (unused?)
|-
| 0x38
| 0x8
| AGB TitleID
|-
| 0x40
| 0x10
| SD card CID from the console the save was made on (verified on load)
|-
| 0x50
| 0x4
| Save start addr (always 0x200)
|-
| 0x54
| 0x4
| Save size
|-
| 0x58
| 0x8
| Always 0xFF (?)
|-
| 0x60
| 0x4
| See [[ARM7_Registers|here]]
|-
| 0x64
| 0x4
| See [[ARM7_Registers|here]]
|-
| 0x68
| 0x198
| Always 0xFF
|}

ARM7 Registers

2015-10-27T02:27:12Z

WulfyStylez: /* Memory map */

The 3DS utilizes an onboard ARM7 core to handle TWL_FIRM and AGB_FIRM's ARM7 requirements. This is due to the fact that much of the hardware used by both ARM7 and ARM9 is (evidently) not physically hooked up to ARM11. Thus, ARM11 cannot simply emulate ARM7.

ARM7 has the AGB BIOS implemented in hardware. The BIOS is completely identical to the original AGB BIOS. The system is booted silently by calling SWI 0x1 (RegisterRamReset), followed by jumping to the code that does SWI 0x0 (SoftReset) to finish booting. The boot splash is still in BIOS, however, and can be seen by calling (or replacing one of the previous interrupts with) SWI 0x26 (HardReset).
= Registers =
ARM9 interfaces with the ARM7 through the following registers:
{| class="wikitable" border="1"
|-
! Name
| Address
! Width
|-
| ARM7_CNT
| 0x10018000
| 0x1
|-
| ARM7_CODE
| 0x10018080
| ?
|-
| ARM7_?_CNT
| 0x10018104
| 0x2
|-
| ARM7_?_STATUS
| 0x10018108
| 0x2
|-
| ARM7_?_WRITE_1
| 0x10018110
| 0x4
|-
| ARM7_?_WRITE_2
| 0x10018114
| 0x4
|-
| ARM7_?_READ_1
| 0x10018118
| 0x4
|-
| ARM7_?_READ_2
| 0x1001811C
| 0x4
|}

== ARM7_CNT ==
This indicates (controls?) the mode of the ARM7. 1 = TWL, 2 = AGB.

== ARM7_CODE ==
This is the first code that will be run after execution begins. TwlProcess9 uses this to put ARM7 in a loop (TWL), and to set the POSTFLG and branch to more copied code (AGB).This doesn't seem to start execution by itself.

== ARM7_?_READ/WRITE ==
The values here are read from, stored in the AGB_FIRM [[3DS_Virtual_Console#NAND_Savegame|savegame]], and then written to the respective registers upon save loading. These registers are read after waiting for bit 15 of ARM7_?_STATUS to be set, writing 0x0 and then 0x2 to that register, and then waiting for bit 15 to be set again. If bit 14 is not set afterward, these registers are read from and stored in the save. Otherwise, these values are saved (and restored) as 0x0.

= Memory map =
The virtual memory mapping for the ARM7 is the same as for the [[Memory_layout#TWL_FIRM_Userland_Memory|other core]]. However, it has additional internal memory mapped to it. Interestingly enough, much of this memory seems to lie within ARM9's own "internal memory."
*0x08060000 -> 0x03800000, ARM7-WRAM (64KB)
*0x080B0000 -> 0x03000000, GBA on-chip WRAM (32KB)
*0x080C0000 -> EEPROM/SRAM/Flash (0x10018104 must be set to 1 before reading memory here, and restored to its previous value afterwards)
*0x01FFC000 -> 0x01000000, ARM9 ITCM under TWL (16KB)

ARM7 Registers

2015-10-27T02:13:53Z

WulfyStylez: more registers

The 3DS utilizes an onboard ARM7 core to handle TWL_FIRM and AGB_FIRM's ARM7 requirements. This is due to the fact that much of the hardware used by both ARM7 and ARM9 is (evidently) not physically hooked up to ARM11. Thus, ARM11 cannot simply emulate ARM7.

ARM7 has the AGB BIOS implemented in hardware. The BIOS is completely identical to the original AGB BIOS. The system is booted silently by calling SWI 0x1 (RegisterRamReset), followed by jumping to the code that does SWI 0x0 (SoftReset) to finish booting. The boot splash is still in BIOS, however, and can be seen by calling (or replacing one of the previous interrupts with) SWI 0x26 (HardReset).
= Registers =
ARM9 interfaces with the ARM7 through the following registers:
{| class="wikitable" border="1"
|-
! Name
| Address
! Width
|-
| ARM7_CNT
| 0x10018000
| 0x1
|-
| ARM7_CODE
| 0x10018080
| ?
|-
| ARM7_?_CNT
| 0x10018104
| 0x2
|-
| ARM7_?_STATUS
| 0x10018108
| 0x2
|-
| ARM7_?_WRITE_1
| 0x10018110
| 0x4
|-
| ARM7_?_WRITE_2
| 0x10018114
| 0x4
|-
| ARM7_?_READ_1
| 0x10018118
| 0x4
|-
| ARM7_?_READ_2
| 0x1001811C
| 0x4
|}

== ARM7_CNT ==
This indicates (controls?) the mode of the ARM7. 1 = TWL, 2 = AGB.

== ARM7_CODE ==
This is the first code that will be run after execution begins. TwlProcess9 uses this to put ARM7 in a loop (TWL), and to set the POSTFLG and branch to more copied code (AGB).This doesn't seem to start execution by itself.

== ARM7_?_READ/WRITE ==
The values here are read from, stored in the AGB_FIRM [[3DS_Virtual_Console#NAND_Savegame|savegame]], and then written to the respective registers upon save loading. These registers are read after waiting for bit 15 of ARM7_?_STATUS to be set, writing 0x0 and then 0x2 to that register, and then waiting for bit 15 to be set again. If bit 14 is not set afterward, these registers are read from and stored in the save. Otherwise, these values are saved (and restored) as 0x0.

= Memory map =
The virtual memory mapping for the ARM7 is the same as for the [[Memory_layout#TWL_FIRM_Userland_Memory|other core]]. However, it has additional internal memory mapped to it. Interestingly enough, much of this memory seems to lie within ARM9's own "internal memory."
*0x08060000 -> 0x03800000, ARM7-WRAM (64KB)
*0x080B0000 -> 0x03000000, GBA on-chip WRAM (32KB)
*0x080C0000 -> ? (0x10018104 is set to 1 before changing memory here, and 0 afterwards, save-related?)
*0x01FFC000 -> 0x01000000, ARM9 ITCM (16KB)

3DS Virtual Console

2015-10-27T02:02:31Z

WulfyStylez: AGB NAND savegame format, MAC, etc

There's two types of VC titles: regular VC titles, and dedicated GBA VC titles.

=Regular VC=
Regular VC titles: an emulator application + VC ROM in the NCCH [[RomFS]](among other things in the RomFS). The emulator build includes support for all supported VC platforms, not specific to just the included ROM platform.

This emulator includes GBA support, however the GBA emulation for this this is somewhat slow. This was presumably implemented before AGB_FIRM was.

Unlike Wii VC, the 3DS VC ROMs for NES use the "TNES" header.

==RomFS==
* "rom:/rom/" This directory contains the ROM file(s). Filenames used under here don't matter: the filename is determined by the emulator app by doing a directory read.
* "rom:/shaders/" This directory contains GPU shaders used by the emulator app: .shbin, .csdr, and .obj.
* "rom:/VCM/" This directory contains graphics, audio, and text used by the emulator app.
* "rom:/agb.bin" GBA BIOS.
* "rom:/buildtime.txt" Emulator app build timestamp.
* "rom:/config.ini" Emulator configuration .ini, contains sections for all supported 3DS VC platforms.
* "rom:/<rom_name>.patch" rom_name = filename from the rom directory. This .ini contains patches for the ROM.
* "rom:/shader.shbin" GPU shader.

=GBA VC=
GBA VC is run by [[FIRM|AGB_FIRM]]. RomFS isn't used for GBA VC titles, but can be found empty within GBA VC titles. The NCCH [[ExeFS]] contains the same files as a normal application. The [[ExeFS]]:/.code contains the GBA VC ROM followed by a 0x360 byte long footer.

===Footer===
All values in the GBA VC footer are little-endian.
{| class="wikitable" border="1"
|-
! START
! SIZE
! DESCRIPTION
|-
| 0x004
| 0x4
| GBA ROM Filesize
|-
| 0x008
| 0x4
| Save type (see below)
|-
| 0x020
| 0x1
| Manufacturer info select (see below)
|-
| 0x024
| 0x300
| Unknown, three different types of this data have been observed.
|-
| 0x338
| 0x4
| GBA ROM Filesize
|-
| 0x344
| 0x4
| GBA ROM Filesize
|-
| 0x350
| 0x4
| Magic '.CAA'
|-
| 0x35A
| 0x2
| High two bytes of GBA ROM file size
|}

Save types:
* EEPROM (various sizes, IDs specified in footer): 0x2
* SRAM/FRAM (128k): 0xE
* Flash (512k): 0x9

Support for RTC and 1m-flash chips is not implemented in AGB_FIRM.

Manufacturer info:
GBA games' SDK-provided save code only supports a range of manufacturers from which Nintendo was buying memory from around the time of that game's development. As such, most games don't support a generic emulated storage chip. This byte appears to select a manufacturer info set to emulate. This has been observed to be 0x90, 0xC0, and (in one EEPROM-based game), 0x80.
* SRAM games up to and including V111 use 0xC0. Above use 0x90.
* FRAM V103 uses 0xC0. V104+ don't exist, and lower versions also likely use 0xC0.
* Flash V124 was observed 0x90, V131 was observed 0xC0.
* EEPROM-based games vary wildly, since they can likely specify chip info in the 0x10-region of the footer.

===NAND Savegame===
AGB_FIRM saves its active save memory to NAND on exit, this is then immediately picked up by NATIVE_FIRM on reboot by checking [[CONFIG_Registers#CFG_BOOTENV|CFG_BOOTENV]]. From there, this is verified and copied out to SD. The savegame format is as follows:
{| class="wikitable" border="1"
|-
! START
! SIZE
! DESCRIPTION
|-
| 0x0
| 0x4
| Magic ('.SAV')
|-
| 0x4
| 0xC
| Always 0xFF
|-
| 0x10
| 0x10
| AES-MAC of the SHA256 hash of 0x30..0x200 + the entire save itself, keyslot 0x24, keyY from process9 .rodata
|-
| 0x20
| 0x10
| Always 0xFF
|-
|-
| 0x30
| 0x40
| Always 0x1?
|-
| 0x34
| 0x4
| ? (observed 0x1, may change though)
|-
| 0x38
| 0x8
| AGB TitleID
|-
| 0x40
| 0x10
| eMMC CID from the console the save was made on (verified on load)
|-
| 0x50
| 0x4
| Save start addr (always 0x200)
|-
| 0x54
| 0x4
| Save size
|-
| 0x58
| 0x8
| Always 0xFF (?)
|-
| 0x60
| 0x4
| See [[ARM7_Registers|here]]
|-
| 0x64
| 0x4
| See [[ARM7_Registers|here]]
|-
| 0x68
| 0x198
| Always 0xFF
|}

CONFIG9 Registers

2015-10-26T17:31:51Z

WulfyStylez: actual usage, clean up some repetition that belongs on the LGY PXI page anyways

= Registers =
{| class="wikitable" border="1"
! Old3DS
! Name
! Address
! Width
! Used by
|-
| style="background: green" | Yes
| [[#CFG_SYSPROT9|CFG_SYSPROT9]]
| 0x10000000
| 1
| Boot9
|-
| style="background: green" | Yes
| [[#CFG_SYSPROT11|CFG_SYSPROT11]]
| 0x10000001
| 1
| Boot9
|-
| style="background: green" | Yes
| CFG_DEBUGUNIT
| 0x10000004
| 4
|
|-
| style="background: green" | Yes
| ?
| 0x10000008
| 1
| TwlProcess9
|-
| style="background: green" | Yes
| [[#CFG_CARDCONF|CFG_CARDCONF]]
| 0x1000000C
| 2
|
|-
| style="background: green" | Yes
|
| 0x10000010
| 1
|
|-
| style="background: green" | Yes
| ?
| 0x10000011
| 1
|
|-
| style="background: green" | Yes
| ?
| 0x10000012
| 2
|
|-
| style="background: green" | Yes
| ?
| 0x10000014
| 2
|
|-
| style="background: green" | Yes
| ?
| 0x10000020
| 2
|
|-
| style="background: green" | Yes
| ?
| 0x10000100
| 2
|
|-
| style="background: red" | No
| [[#CFG_EXTMEMCNT9|CFG_EXTMEMCNT9]]
| 0x10000200
| 1
| NewKernel9
|-
| style="background: green" | Yes
| [[#CFG_MPCORECFG|CFG_MPCORECFG]]
| 0x10000FFC
| 4
|
|-
| style="background: green" | Yes
| [[#CFG_BOOTENV|CFG_BOOTENV]]
| 0x10010000
| 4
|
|-
| style="background: green" | Yes
| [[#CFG_UNITINFO|CFG_UNITINFO]]
| 0x10010010
| 1
| Process9
|-
| style="background: green" | Yes
| [[#CFG_TWLUNITINFO|CFG_TWLUNITINFO]]
| 0x10010014
| 1
| Process9
|}

==CFG_SYSPROT9 ==
Writing values to SYSPROT sets the specified bitmask. The ARM9 [[Memory_layout|bootrom]](+0x8000) is disabled by writing bit0. bit1 is used by NATIVE_FIRM to make sure console-unique TWL AES-keys are only set at hard-boot. It is not possible to set any other bits.

From disassembly of the New3DS process9, it appears that setting bit1 disables the 0x10012000+ region.

== CFG_SYSPROT11 ==
ARM11 bootrom (+0x8000) is disabled by writing bit0. It is not possible to set any other bits.

== CFG_CARDCONF ==
{| class="wikitable" border="1"
! Bit
! Description
|-
| 1-0
| Gamecard active controller select (0=NTRCARD, 1=?, 2=CTRCARD1, 3=CTRCARD2)
|-
| 8
| ?
|}

Depending on the gamecard controller that has been selected, one of the following gamecard registers will become active:
* Selecting NTRCARD will activate the register space at [[NTRCARD|0x10164000]].
* Selecting CTRCARD1 will activate the register space at [[CTRCARD|0x10004000]].
* Selecting CTRCARD2 will activate the register space at [[CTRCARD|0x10005000]].

== 0x10000010 ==
When a gamecard isn't inserted, this register value is 0x01, otherwise when a gamecard is inserted it's value 0x08.

== CFG_EXTMEMCNT9 ==
This register is presumably New3DS-only. Only bit0 is writable: 0 = disable New3DS ARM9 memory at 0x08100000 size 0x80000, 1 = enable.

This bit is set by New3DS ARM9-kernel crt0.

The data in this extended memory doesn't change when disabling the memory, then re-enabling the memory. Reading this extended memory while disabled results in zeros.

== CFG_MPCORECFG ==
Identical to [[PDN#PDN_MPCORE_CFG|PDN_MPCORE_CFG]].

== CFG_BOOTENV ==
This register is used to determine what the previous running FIRM was. Its value is kept following an MCU reboot. Its initial value (on a cold boot) is 0. NATIVE_FIRM [[Development_Services_PXI|sets it to 1]] on shutdown/FIRM launch. [[Legacy_FIRM_PXI|LGY FIRM]] writes value 3 here when launching a TWL title, and writes value 7 when launching an AGB title.

NATIVE_FIRM will only launch titles if this is not value 0, and will only save the [[Flash_Filesystem|AGB_FIRM savegame]] to SD if this is value 7.

== CFG_UNITINFO ==
This 8-bit register is value zero for retail, non-zero for dev/debug units.

== CFG_TWLUNITINFO ==
In the console-unique TWL key-init/etc function the ARM9 copies the u8 value from REG_UNITINFO to this register.

This is also used by TWL_FIRM Process9.

Mode Control Services PXI

2015-10-26T11:59:10Z

WulfyStylez: CFG_BOOTENV note

="pxi:mc" service=
{| class="wikitable" border="1"
|-
! Command Header
! Available since system version
! Description
|-
| 0x00010000
| [[1.0.0-0]]
| This is sent to the ARM9 by the ARM11 PXI-module, when PXI-module is shutting down due to receiving [[Services|srv]] notification-ID 0x100. This sets [[CONFIG_Registers#CFG_BOOTENV|CFG_BOOTENV]] to the value for CTR (0x1), and is only time it's set by Process9.
|-
| 0x0002....
| [[1.0.0-0]]
| Stubbed, does nothing...
|-
| 0x0003....
| [[1.0.0-0]]
| Stubbed, does nothing...
|-
| 0x0004....
| [[1.0.0-0]]
| Stubbed, does nothing...
|-
| 0x00050040
| [[1.0.0-0]]
| (u8 unkval) Unknown. Used by [[PTM_Services|PTM]] module.
|-
| 0x0006....
| [[1.0.0-0]]
| Stubbed, does nothing...
|-
| 0x00070000
| [[1.0.0-0]]
| Stubbed, writes uninitialized stack byte to (u8*)(cmdbuf+4).
|-
| 0x0008....
| [[1.0.0-0]]
| Stubbed, returns 0xE0C0EC03...
|-
| 0x0009....
| [[1.0.0-0]]
| Stubbed, returns 0xE0C0EC03...
|-
| 0x000A....
| [[1.0.0-0]]
|?
|-
| 0x000B....
| [[1.0.0-0]]
| Stubbed, does some unnecessary copying to stack...
|-
| 0x000C....
| [[1.0.0-0]]
| Stubbed, does some unnecessary copying to stack...
|}

Back to↓

[[Services API]]

AES Registers

2015-10-25T17:04:37Z

WulfyStylez: keyslot 0x24 confirmed

== Registers ==
{| class="wikitable" border="1"
! Old3DS
! Name
! Address
! Width
! RW
|-
| style="background: green" | Yes
| [[#AES_CNT|AES_CNT]]
| 0x10009000
| 4
| RW
|-
| style="background: green" | Yes
| [[#AES_BLKCNT|AES_BLKCNT]]
| 0x10009004
| 4
| W?
|-
| style="background: green" | Yes
| [[#AES_WRFIFO/AES_RDFIFO|AES_WRFIFO]]
| 0x10009008
| 4
| W
|-
| style="background: green" | Yes
| [[#AES_WRFIFO/AES_RDFIFO|AES_RDFIFO]]
| 0x1000900C
| 4
| R
|-
| style="background: green" | Yes
| AES_KEYSEL
| 0x10009010
| 1
| RW
|-
| style="background: green" | Yes
| [[#AES_KEYCNT|AES_KEYCNT]]
| 0x10009011
| 1
| RW
|-
| style="background: green" | Yes
| [[#AES_CTR|AES_CTR]]
| 0x10009020
| 16
| W
|-
| style="background: green" | Yes
| [[#AES_MAC|AES_MAC]]
| 0x10009030
| 16
| W
|-
| style="background: green" | Yes
| AES_KEY0
| 0x10009040
| 48
| W
|-
| style="background: green" | Yes
| AES_KEY1
| 0x10009070
| 48
| W
|-
| style="background: green" | Yes
| AES_KEY2
| 0x100090A0
| 48
| W
|-
| style="background: green" | Yes
| AES_KEY3
| 0x100090D0
| 48
| W
|-
| style="background: green" | Yes
| AES_KEYFIFO
| 0x10009100
| 4
| W
|-
| style="background: green" | Yes
| AES_KEYXFIFO
| 0x10009104
| 4
| W
|-
| style="background: green" | Yes
| AES_KEYYFIFO
| 0x10009108
| 4
| W
|}

== AES_CNT ==
{| class="wikitable" border="1"
! Bit
! Description
|-
| 4-0
| Write FIFO count (0-16)
|-
| 9-5
| Read FIFO count (0-16)
|-
| 10
| Flush write FIFO (1=Clear write FIFO)
|-
| 11
| Flush read fifo (1=Clear read FIFO)
|-
| 18-16
| MAC size (encoding = (maclen-2)/2)
|-
| 19
|? (MAC related)
|-
| 20
| MAC input control (0 = read MAC from FIFO, 1 = read from MAC register)
|-
| 21
| MAC status (0 = invalid, 1 = verified)
|-
| 22
| Output endianness (1=Big endian, 0=Little endian)
|-
| 23
| Input endianness (1=Big endian, 0=Little endian)
|-
| 24
| Output word order (1=Normal order, 0=Reversed order)
|-
| 25
| Input word order (1=Normal order, 0=Reversed order)
|-
|-
| 26
| Update keyslot (selects the keyslot specified by REG_AESKEYSEL when this bit is set)
|-
| 29-27
| Mode (0=CCM decrypt, 1=CCM encrypt, 2=CTR, 3=CTR, 4=CBC decrypt, 5=CBC encrypt, 6=ECB decrypt, 7=ECB encrypt)
|-
| 30
| Interrupt enable (1=enable, 0=disable)
|-
| 31
| Start (1=enable/busy, 0=idle)
|}

When bit31 is clear, the AES engine will handle keyslot-selection when bit26 is set immediately. When bit31 is set, the AES engine won't handle bit26 immediately, instead the AES engine will automatically handle the already-set bit26 once bit31 clears(current AES operation finishes).

Clearing bit31 while the AES engine is doing crypto will result in the AES engine stopping crypto, once it finishes processing the current block.

== AES_BLKCNT ==

{| class="wikitable" border="1"
! Bit
! Description
|-
| 16-31
| (Data length)>>4
|}

== AES_WRFIFO/AES_RDFIFO ==
Up to 128 bytes of input data can be buffered.

The input data for the AES crypto operation is written to REG_AESWRFIFO, the output data is read from REG_AESRDFIFO.

Reading from REG_AESRDFIFO when there's no data available in the RDFIFO will result in reading the last word that was in the RDFIFO.

== AES_KEYCNT ==
{| class="wikitable" border="1"
! Bit
! Description
|-
| 5-0
| Keyslot
|-
| 6
| Hardware key-generator type: 0 = 3DS, 1 = DSi.
|-
| 7
| This normally has value 1 written here when updating keys. 0 = disable key FIFO flush, 1 = enable key FIFO flush.
|}

Bit6 is only used when keyslots >=4 are used, value1 has the same affect as doing key-init with the TWL keyslots. Bit6 is only checked when a keyY was completely written, for when the final-normalkey needs updated via the key-generator. Changing bit6 has no affect on the generated normalkey when writing to this bit immediately after writing the last keyY word.

== AES_CTR ==
This register specifies the counter (CTR mode), nonce (CCM mode) or the initialization vector (CBC mode) depending on the mode of operation.
For CBC and CTR mode this register takes up the full 16 bytes, but for CCM mode the nonce is only the first 12 bytes.
The AES engine will automatically increment the counter up to the maximum BLKCNT, after which point it must be manually incremented and set again.

== AES_MAC ==
This register specifies the message authentication code (MAC) for use in CCM mode.

== AES_KEY0/1/2/3 ==
{| class="wikitable" border="1"
! Byte
! Description
|-
| 0-15
| Normalkey
|-
| 16-31
| KeyX
|-
| 32-47
| KeyY
|-}

These registers are the same as they were on TWL, and are likely preserved for compatibility reasons. The keyslot is updated immediately after *any* data(u8/u32/...) is written here, which was used on DSi to [[3DS_System_Flaws|break]] the key-generator.

== Endianness and word order ==
When writing to the AES_CTR or AES_MAC register, the hardware will process the written data according to the current input endianness specified in AES_CNT. However, the current specified input word order will not be honored for this register, and always defaults to reversed word order. Therefore, for normal word order, the reversal must be carried out manually if required.

== Keyslot ranges ==
This is approximately a table of what is set by bootrom before booting into FIRM. Often it appears that keyslots in groups of 4 have the same keyX, and sometimes also same keyY set.

{| class="wikitable" border="1"
! Keyslot
! Name
! KeyX
! KeyY/Normal-key
! Console unique.
|-
| 0x00-0x03
| TWL keys.
| Probably unset.
| Probably unset.
| -
|-
| 0x04-0x07
| NAND partition keys.
| Same for all.
| Different for all.
| style="background: green" | Yes
|-
| 0x08-0x0B
| See below.
| Same for all.
| Different for all.
| style="background: green" | Yes
|-
| 0x0C-0x0F
| SSL cert key.
| Same for all.
| Same for all.
| style="background: red" | No
|-
| 0x10-0x17
| -
| Not set.
| Not set.
| -
|-
| 0x18-0x1B
| Never used.
| Same for all.
| Same for all.
| style="background: green" | Yes
|-
| 0x1C-0x1F
| Never used.
| Same for all.
| Same for all.
| style="background: green" | Yes
|-
| 0x20-0x23
| Never used.
| Same for all.
| Same for all.
| style="background: orange" | Normalkey is not. keyX is. keyY unknown.
|-
| 0x24
| Never used.
| Individually set.
| Individually set.
| style="background: orange" | Normalkey is not. keyX is. keyY unknown.
|-
| 0x25-0x27
| -
| Not set.
| Not set.
| -
|-
| 0x28-0x2B
| Never used.
| Individually set.
| Individually set.
| style="background: orange" | Normalkey is not. keyX is. keyY unknown.
|-
| 0x2C-0x2F
| Various uniques.
| Same for all.
| Same for all, probably.
| style="background: red" | No
|-
| 0x30-0x33
| Various uniques.
| Same for all.
| Same for all, probably.
| style="background: red" | No
|-
| 0x34-0x37
| Various uniques.
| Same for all.
| Same for all, probably.
| style="background: red" | No
|-
| 0x38-0x3B
| Various uniques.
| Same for all.
| Different for all.
| style="background: red" | No
|-
| 0x3C-0x3F
| Various uniques.
| Individually set.
| Individually set.
| style="background: red" | No
|}

Keyslot pairs (0x24, 0x28) and (0x38, 0x3C) shares the same normal-key, while at the same time having different keyX's. This suggests they were set to same normal-key by bootrom.

== Keyslots ==
There are 0x40 keyslots, each of which stores three keys called keyX, keyY and normalkey. All keys can be set explicitly, but the normalkey can optionally be generated using a hardware key generator instead (see below). There is no way to read the contents of a keyslot.

{| class="wikitable" border="1"
! Keyslot
! Description
! KeyX
! KeyY
! Normal-key
! Old3DS
|-
| 0x00-0x03
| TWL keys.
| NATIVE_FIRM hard-boot.
| NATIVE_FIRM hard-boot.
| -
| Yes
|-
| 0x04..0x07
| [[Flash_Filesystem|NAND]] partition keys.

Keyslot is determined by [[NCSD]] partition FS type and encryption type.
The New3DS Process9 sets the keyY for keyslot 0x05 (New3DS CTRNAND) to a key from .(ro)data. Its keyX is console-unique and set by the bootloader.
| Bootrom.
| Bootrom.
| -
| Yes
|-
| 0x0A
| DSiWare export key.

Used for encrypting the all-zero 0x10-byte block in the [[DSiWare_Exports|DSiWare_Exports]] header. Console-unique.
| See above keyslot info.
| See above keyslot info.
|-
| 0x0B
| This is console-unique. This keyslot is used for the NAND [[Title_Database|dbs]] images AESMACs, and the [[Nand/private/movable.sed]] AESMAC(when used).
| See above keyslot info.
| See above keyslot info.
| -
| Yes
|-
| 0x0D
| SSL-certificate key.

See [[PSPXI:EncryptDecryptAes|EncryptDecryptAes]].
| -
| -
| Bootrom.
| Yes
|-
| 0x11
| Temporary keyslot.

Used by FIRM for general normal-key crypto. Also used by the New3DS [[FIRM]] arm9 binary loader.
| Arm9Loader.
| Arm9Loader.
| NATIVE_FIRM.
| Yes
|-
| 0x14
| Starting with [[5.0.0-11]], NATIVE_FIRM Process9 now sets the keyY for this to the same one it uses for initializing 3 of the keyslots' keyYs from [[PSPXI:EncryptDecryptAes|here]].
| Bootrom.
| NATIVE_FIRM boot.
| -
| Yes
|-
| 0x15
| Used/initialized by the New3DS arm9 binary loader, see [[FIRM|here]].
| Arm9Loader.
| Arm9Loader.
| See previous info for this keyslot.
| No
|-
| 0x16
| Used/initialized by the New3DS arm9 binary loader starting with [[9.5.0-22|9.5.0-X]], see [[FIRM|here]].
| Arm9Loader.
| Arm9Loader.
| See previous info for this keyslot.
| No
|-
| 0x18..0x1F
| These are the New3DS keyslots, where the keyX is generated with keyslot 0x11 by the New3DS arm9 binary [[FIRM|loader]]. As of [[FIRM]] [[9.6.0-24|9.6.0-X]] keyslots 0x1C..0x1F are not yet used by Process9.
| Arm9Loader.
| NATIVE_FIRM / see previous info for these keyslots.
| See previous info for these keyslots.
| No
|-
| 0x18
| New3DS [[9.3.0-21|9.3.0-X]] [[NCCH]] key, when ncchflag[3] is 0x0A.
| Arm9Loader.
| NATIVE_FIRM
| -
| No
|-
| 0x19
| New3DS gamecard [[Savegames|savedata]] AES-MAC key.

Equivalent of keyslot 0x33, used when a [[NCSD]] flag is set to a certain value (implemented with [[9.3.0-21|9.3.0-X]]).
| Arm9Loader.
| NATIVE_FIRM
| -
| No
|-
| 0x1A
| New3DS gamecard [[Savegames|savedata]] actual key.

Equivalent of keyslot 0x37, used when a [[NCSD]] flag is set to a certain value (implemented with [[9.3.0-21|9.3.0-X]]).
| Arm9Loader.
| NATIVE_FIRM
| -
| No
|-
| 0x1B
| New3DS [[9.6.0-24|9.6.0-X]] [[NCCH]] key, when ncchflag[3] is 0x0B.
| Arm9Loader.
| NATIVE_FIRM
| -
| No
|-
| 0x24
| AGB_FIRM savegame AES-MAC key.
| Bootrom.
| AGB/NATIVE_FIRM.
| -
| Yes
|-
| 0x25
| [[7.0.0-13|v7.0]] [[NCCH]] key, when ncchflag[3] is 0x01.
| NATIVE_FIRM [[Savegames#6.0.0-11_Savegame_keyY|boot]].
| NATIVE_FIRM.
| -
| Yes
|-
| 0x2C
| Original [[NCCH|NCCH]] key, when ncchflag[3] is 0x00 and always for certain NCCH sections.
| Bootrom.
| Process9.
| -
| Yes
|-
| 0x2D
| UDS local-WLAN CCMP key.

See [[PSPXI:EncryptDecryptAes|EncryptDecryptAes]].
| Bootrom.
| Bootrom.
| -
| Yes
|-
| 0x2E
| Streetpass key.

See [[PSPXI:EncryptDecryptAes|EncryptDecryptAes]].
| Bootrom.
| NATIVE_FIRM.
| -
| Yes
|-
| 0x2F
| [[Savegames#6.0.0-11_Savegame_keyY|v6.0]] save key.
| Bootrom.
| NATIVE_FIRM.
| -
| Yes
|-
| 0x30
| SD/NAND AES-MAC key.

This keyY is initialized via [[Nand/private/movable.sed|movable.sed]]. This is used for calculating the AESMACs under SD [[SD_Filesystem|/Nintendo 3DS/<ID0>/<ID1>/]] (except [[DSiWare_Exports]]) and [[Flash_Filesystem|NAND]] /data/.
| Bootrom.
| NATIVE_FIRM.
| -
| Yes
|-
| 0x31
| APT wrap key.

See [[PSPXI:EncryptDecryptAes|EncryptDecryptAes]]. NATIVE_FIRM sets this keyY to the same one used for keyslot 0x2E.
| Bootrom.
| NATIVE_FIRM.
| -
| Yes
|-
| 0x32
| Unknown.

See [[PSPXI:EncryptDecryptAes|EncryptDecryptAes]].
| Bootrom.
| Bootrom.
| -
| Yes
|-
| 0x33
| Gamecard [[Savegames|savedata]] AES-MAC.
| Bootrom.
| NATIVE_FIRM.
| -
| Yes
|-
| 0x34
| SD key.

This keyY is initialized via [[Nand/private/movable.sed|movable.sed]]. This is used for encrypting *all* SD card data under [[SD_Filesystem|/Nintendo 3DS/<ID0>/<ID1>/]].
| Bootrom.
| NATIVE_FIRM.
| -
| Yes
|-
| 0x35
| Movable.sed key.

This is the keyslot used for movable.sed encryption + AES-MAC with the import/export [[FSPXI:ImportIntegrityVerificationSeed|commands]].
| Bootrom.
| Bootrom.
| -
| Yes
|-
| 0x36
| Unknown. Used by friends module.

See [[PSPXI:EncryptDecryptAes|EncryptDecryptAes]].
| Bootrom.
| Bootrom.
| -
| Yes
|-
| 0x37
| Gamecard [[Savegames|savedata]] actual key.
| Bootrom.
| NATIVE_FIRM.
| -
| Yes
|-
| 0x38
| BOSS key.

See [[PSPXI:EncryptDecryptAes|EncryptDecryptAes]].
| Bootrom.
| Bootrom.
| -
| Yes
|-
| 0x39
| Download Play key, and the actual NFC key for generating retail [[Amiibo]] keys.

This keyslot is used for two different keys. Both are available via [[PSPXI:EncryptDecryptAes|EncryptDecryptAes]]. NATIVE_FIRM sets this keyY to the same one used for keyslot 0x2E.
| Bootrom.
| NATIVE_FIRM.
| -
| Yes
|-
| 0x3A
| DSiWare export key.

This keyY is initialized via [[Nand/private/movable.sed|movable.sed]]. This is used for calculating the AESMACs for SD [[DSiWare_Exports]].
| Bootrom.
| NATIVE_FIRM.
| -
| Yes
|-
| 0x3B
| [[CTRCARD_Registers#CTRCARD_SECSEED|CTR-CARD hardware-crypto seed]] decryption key.

AES-CCM is used, the keyY, nonce and MAC are stored in the [[NCSD#Card_Info_Header|Card Info Header]].
| Bootrom.
| NATIVE_FIRM.
| -
| Yes
|-
| 0x3D
| Common key.

Used to decrypt title keys in [[Ticket]].
| Bootrom.
| NATIVE_FIRM.
| -
| Yes
|}

=== Updating keydata ===
The contents of the keyslot specified in REG_AESKEYCNT can be updated by consecutively writing four words to REG_AESKEYXFIFO (keyX), REG_AESKEYYFIFO(keyY), or REG_AESKEYFIFO (normalkey).

After writing to a keyslot, the keyslot must be selected again(write REG_AESKEYSEL + set REG_AESCNT bit26), even when writing to the same keyslot. Writing the last word to a key FIFO immediately after selecting a keyslot will not affect the keyslot keydata that gets used at that time, the new keydata will not get used until the keyslot gets selected again.

Writing to the key FIFOs with byte writes results in the AES engine converting the byte to a word for setting the key word, with this: word = (byteval) | (byteval<<8) | (byteval<<16) | (byteval<<24). The result is the same regardless of which FIFO register byte was written to.

The TWL keyslots 0x00-0x03 can be set directly by writing to the REG_AESKEY0-REG_AESKEY3 registers.

The key FIFOs can be written simultaneously. For example, executing the following 4 times will result in the keyX and keyY being set to all-zero(unknown for normalkey): memset(0x10009100, 0, 0x100);

Each key FIFO has a 0x10-byte tmp-buffer for storing the words written to that FIFO. Once the last word is written to a key FIFO, the filled tmp-buffer is then written to the key-data for the keyslot selected by REG_AESKEYCNT at the time the last word was written.

=== keyX ===
The ARM9 bootrom initializes the keyX for certain 3DS keyslots, the ARM9 bootrom may also initialize the keyY for certain keyslots. In certain cases Process9 may also set the keyX.

=== Hardware key generator ===
A dedicated hardware key generator can be used to generate a keyslot's normalkey from its keyX and keyY. The hardware key generator is triggered by writing the keyY, which is the only way to trigger it with the 3DS keyslots. The algorithm used for key generation is unknown.

Unless noted otherwise, all keyslots on retail units use the hardware key-generator.

=== FIRM-launch key clearing ===
Starting with [[9.0.0-20]] the Process9 FIRM-launch code now "clears" the following AES keyslots, with certain keydata by writing the normal-key: 0x15 and 0x18-0x20. These are the keyslots used by the New3DS [[FIRM]] arm9bin loader(minus keyslot 0x11), the New3DS Process9 does this too.

IO Registers

2015-10-22T07:05:03Z

WulfyStylez: N3DS DMA addrs notes

= Overview =

{| class="wikitable" border="1"
! Old3DS
! A9/A11
! Category
! Physaddr
! Used by
! Comments
|-
| style="background: green" | Yes
| A9
| [[CONFIG Registers]]
| 0x10000000
| Boot9, Process9
|
|-
| style="background: green" | Yes
| A9
| [[IRQ Registers]]
| 0x10001000
| Boot9, Process9, Kernel9
| ARM9 Interrupt Masking
|-
| style="background: green" | Yes
| A9
| [[NDMA Registers]]
| 0x10002000
| Boot9, Process9
| DMA Engine
|-
| style="background: green" | Yes
| A9
| [[TIMER Registers]]
| 0x10003000
| Boot9, Process9
|
|-
| style="background: green" | Yes
| A9
| [[CTRCARD Registers]]
| 0x10004000 / 0x10005000
| Process9
|
|-
| style="background: green" | Yes
| A9
| [[EMMC Registers]]
| 0x10006000 / 0x10007000
| Boot9, Process9
| 0x10007000 is normally not enabled on retail, all-zeros when read.
|-
| style="background: green" | Yes
| A9
| [[PXI Registers]]
| 0x10008000
| Boot9, Process9
|
|-
| style="background: green" | Yes
| A9
| [[AES Registers]]
| 0x10009000
| Boot9, Process9
|
|-
| style="background: green" | Yes
| A9
| [[SHA Registers]]
| 0x1000A000
| Boot9, Process9
|
|-
| style="background: green" | Yes
| A9
| [[RSA Registers]]
| 0x1000B000
| Boot9, Process9
|
|-
| style="background: green" | Yes
| A9
| [[Corelink DMA Engines|XDMA Registers]]
| 0x1000C000
| Boot9, Kernel9
| [http://infocenter.arm.com/help/topic/com.arm.doc.ddi0424d/index.html CoreLink™ DMA-330] (single-channel).
|-
| style="background: green" | Yes
| A9
| [[SPICARD Registers]]
| 0x1000D800
| Process9
|
|-style="border-top: double"
| style="background: green" | Yes
| ?
| [[CONFIG Registers]]
| 0x10010000
| Process9
|
|-
| style="background: green" | Yes
| ?
| PRNG Registers
| 0x10011000
| Process9
| Used as entropy-source for seeding random number generators.
|-
| style="background: green" | Yes
| ?
| [[OTP Registers]]
| 0x10012000
| Kernel9, NewKernel9Loader
| Top secret.
|-
| style="background: green" | Yes
| ?
| [[ARM7|ARM7 Registers]]
| 0x10018000
| TwlProcess9
| Used to setup the ARM7 core for AGB/TWL
|-style="border-top: double"
| style="background: green" | Yes
| A11/A9
| Debug WIFI SDIO Registers?
| 0x10100000
|
| An SDIO controller is mapped here, NWM references this controller but doesn't have access to it.
|-
| style="background: green" | Yes
| A11/A9
| [[HASH Registers]]
| 0x10101000
| [[Filesystem services]]
|
|-
| style="background: green" | Yes
| A11/A9
| [[Camera Registers]]
| 0x10102000
| [[Camera Services]]
| y2r
|-
| style="background: green" | Yes
| A11/A9
| [[CSND Registers]] / [[DSP Registers]]
| 0x10103000
| TwlBg, [[Codec Services]], [[CSND Services]], [[DSP Services]]
| Sound hardware. For DSP regs, see the "DSi XpertTeak" section in [http://problemkaputt.de/gba.htm no$gba] help.
|-style="border-top: double"
| style="background: green" | Yes
| A11/A9
| LGYFB0
| 0x10110000
| TwlBg
| IO registers used to access legacy output framebuffer, as well as configure the upscaling filter.
|-
| style="background: green" | Yes
| A11/A9
| LGYFB1
| 0x10111000
| TwlBg
| IO registers used to access legacy output framebuffer, as well as configure the upscaling filter.
|-style="border-top: double"
| style="background: green" | Yes
| A11/A9
| [[Camera Registers]]
| 0x10120000
| [[Camera Services]]
|
|-
| style="background: green" | Yes
| A11/A9
| [[Camera Registers]]
| 0x10121000
| [[Camera Services]]
| Mirror of 0x10120000?
|-
| style="background: green" | Yes
| A11/A9
| [[WIFI Registers]]
| 0x10122000
| [[NWM Services]]
| WIFI SDIO bus registers
|-
| style="background: green" | Yes
| A11/A9
| ?
| 0x10123000
| [[NWM Services]]
| WIFI?
|-style="border-top: double"
| style="background: red" | No
| A11/A9
| [[MVD Registers]]
| 0x10130000
| [[MVD Services]]
|
|-
| style="background: red" | No
| A11/A9
| [[MVD Registers]]
| 0x10131000
| [[MVD Services]]
|
|-
| style="background: red" | No
| A11/A9
| [[MVD Registers]]
| 0x10132000
| [[MVD Services]]
|
|-style="border-top: double"
| style="background: green" | Yes
| A11/A9
| [[PDN Registers]]
| 0x10140000
| Process9, Boot11, Kernel11, TwlBg, [[DSP Services]], [[NWM Services]], [[SPI Services]]
| Power management.
|-
| style="background: green" | Yes
| A11/A9
| [[PDN Registers]]
| 0x10141000
| Process9, Boot11, Kernel11, TwlBg, [[Codec Services]], [[NWM Services]], [[SPI Services]], [[PDN Services]]
| Power management
|-
| style="background: green" | Yes
| A11/A9
| [[SPI Registers]]
| 0x10142000
| TwlBg, [[SPI Services]]
|
|-
| style="background: green" | Yes
| A11/A9
| [[SPI Registers]]
| 0x10143000
| TwlBg, dmnt Module
| Debugger related?
|-
| style="background: green" | Yes
| A11/A9
| [[I2C Registers]]
| 0x10144000
| Boot11, Kernel11, TwlBg, [[I2C Services]]
|
|-
| style="background: green" | Yes
| A11/A9
| [[CODEC Registers]]
| 0x10145000
| TwlBg, [[Codec Services]]
|
|-
| style="background: green" | Yes
| A11/A9
| [[HID Registers]]
| 0x10146000
| Boot11, Kernel11, TwlBg, [[HID Services]], dlp Services
| See [[PAD]].
|-
| style="background: green" | Yes
| A11/A9
| [[GPIO Registers]]
| 0x10147000
| Boot11, TwlBg, [[GPIO Services]], [[DSP Services]](v0)
|
|-
| style="background: green" | Yes
| A11/A9
| [[I2C Registers]]
| 0x10148000
| TwlBg, [[I2C Services]]
|
|-style="border-top: double"
| style="background: green" | Yes
| A11/A9
| [[SPI Registers]]
| 0x10160000
| Boot9, TwlBg, [[SPI Services]]
|
|-
| style="background: green" | Yes
| A11/A9
| [[I2C Registers]]
| 0x10161000
| Boot11, TwlBg, [[I2C Services]]
| See [http://problemkaputt.de/gba.htm no$gba] help for some clues maybe.
|-
| style="background: green" | Yes
| A11/A9
| [[MIC Registers]]
| 0x10162000
| [[MIC Services]]
|
|-
| style="background: green" | Yes
| A11/A9
| [[PXI Registers]]
| 0x10163000
| Boot11, Kernel11, TwlBg, [[PXI Services]]
|
|-
| style="background: green" | Yes
| A11/A9
| [[NTRCARD Registers]]
| 0x10164000
| Boot9, Process9
|
|-
| style="background: green" | Yes
| A11/A9
| [[MP Registers]]
| 0x10165000
| [[MP Services]]
|
|-style="border-top: double"
| style="background: green" | Yes
| A11/A9
| [[MP Registers]]
| 0x10170000
| [[MP Services]]
| NTR WIFI Registers, see [http://problemkaputt.de/gbatek.htm#dswirelesscommunications GBATek].
|-
| style="background: green" | Yes
| A11/A9
| [[MP Registers]]
| 0x10171000
| [[MP Services]]
| NTR WIFI Registers (mirror)
|-
| style="background: green" | Yes
| A11/A9
|?
| 0x10172000
|?
| NTR WIFI Unused?
|-
| style="background: green" | Yes
| A11/A9
|?
| 0x10173000
|?
| NTR WIFI Unused?
|-
| style="background: green" | Yes
| A11/A9
| [[MP Registers]]
| 0x10174000
| [[MP Services]]
| NTR WIFI RAM
|-
| style="background: green" | Yes
| A11/A9
| [[MP Registers]]
| 0x10175000
|?
| NTR WIFI RAM
|-
| style="background: green" | Yes
| A11/A9
| [[MP Registers]]
| 0x10176000
|?
| NTR WIFI Registers (mirror)
|-
| style="background: green" | Yes
| A11/A9
| [[MP Registers]]
| 0x10177000
|?
| NTR WIFI Registers (mirror)
|-
| style="background: green" | Yes
| A11/A9
| [[MP Registers]]
| 0x10178000 - 0x10180000
| [[MP Services]]
| NTR WIFI WS1 Region
|-style="border-top: double"
| style="background: green" | Yes
| A11
| [[Corelink DMA Engines|CDMA]]
| 0x10200000
| Boot11, Kernel11
| [http://infocenter.arm.com/help/topic/com.arm.doc.ddi0424d/index.html CoreLink™ DMA-330]. Only used by bootrom on New3DS.
|-
| style="background: green" | Yes
| A11
| ?
| 0x10201000
| TwlBg
|
|-
| style="background: green" | Yes
| A11
| [[LCD Registers]]
| 0x10202000
| TwlBg, Kernel11, [[GSP Services]]
|
|-
| style="background: green" | Yes
| A11
| [[DSP Registers]]
| 0x10203000
| [[DSP Services]]
|
|-
| style="background: green" | Yes
| A11
| ?
| 0x10204000
|
|
|-style="border-top: double"
| style="background: red" | No
| A11
| [[Corelink DMA Engines|CDMA]]
| 0x10206000
| NewKernel11
| CDMA was moved (mirrored?) here on New 3DS. [http://infocenter.arm.com/help/topic/com.arm.doc.ddi0424d/index.html CoreLink™ DMA-330].
|-
| style="background: red" | No
| A11
| [[MVD Registers]]
| 0x10207000
| [[MVD Services]]
| New 3DS only?
|-style="border-top: double"
| style="background: green" | Yes
| A11
| AXI
| 0x1020F000
| TwlBg, [[GSP Services]]
| [http://infocenter.arm.com/help/topic/com.arm.doc.ddi0422a/CHDGHIID.html CoreLink™ NIC-301 r1p0].
|-style="border-top: double"
| style="background: green" | Yes
| A11
| DMA region
| 0x10300000-0x10400000
|
| CDMA wants these addresses. Each page in this region corresponds to the same page in the 0x10100000-0x10200000 region. It is unknown if this is just a separate bus and/or if there are any differences in the registers.
|-style="border-top: double"
| style="background: green" | Yes
| A11
| [[GPU Registers]]
| 0x10400000
| Boot11, Kernel11, [[GSP Services]]
||
|}

IO registers starting at physical address 0x10200000 are not accessible from the ARM9 (which includes all LCD/GPU registers). It seems IO registers below physical address 0x10100000 are not accessible from the ARM11 bus.

ARM11 kernel virtual address mappings for these registers varies for different builds. For ARM11 user mode applications you have:
physaddr = virtaddr - 0x1EC00000 + 0x10100000

Services

2015-09-30T00:17:41Z

WulfyStylez: /* Notifications */

Services are an abstraction of ports and are the commonly used way of inter-process communication outside of the kernel. While handles of regular ports are retrieved from [[SVC]](svcConnectToPort), service handles are retrieved through the port ''srv:'' ("service manager").

When a service is registered, [[SVC|svcCreatePort]] is used without a port-name. This means that the port is inaccessible via the port SVCs outside of sm-module. See below for getting a session handle for sending commands to services.

Processes with PID less than or equal to the number of NATIVE_FIRM built-in modules (fs, sm, pm, pxi, ldr) have access to all services. This value is obtained from [[SVC|svcGetSystemInfo]].

Attempting to use srvGetServiceSession with a service that the process has access to when that service isn't registered, results in svcSendSyncRequest never returning(the exact cause is unknown).

==Service Manager Port "srv:"==
{| class="wikitable" border="1"
|-
! Command Header
! Description
|-
| 0x00010002
| Initialize
|-
| 0x00020000
| GetProcSemaphore() (the handle from this gets signaled when notifications for this process gets triggered)
|-
| 0x00030100
| RegisterService(8-byte servicename, u32 strlen, u32 max_sessions)
|-
| 0x000400C0
| UnregisterService(8-byte servicename, u32 strlen)
|-
| 0x00050100
| GetServiceSession(8-byte servicename, u32 strlen, u32 flags)

Flags bit0: if not set, return port-handle instead of session-handle(from [[SVC|svcCreateSessionToPort]]) when session-handle unavailable (max sessions/timeout?).
|-
| 0x000600C2
| RegisterPort(8-byte servicename, u32 strlen, Handle client_port)
|-
| 0x000700C0
| UnregisterPort(8-byte servicename, u32 strlen)
|-
| 0x00080100
| GetPort(8-byte servicename, u32 strlen, u32 flags).

Flags bit0: return 0 instead of port handle if port was found.
|-
| 0x00090040
| Subscribe(u32 notification_id). This enables the specified notificationID for the current process.
|-
| 0x000A0040
| Unsubscribe(u32 notification_id). This disables the specified notificationID for the current process.
|-
| 0x000B0000
| ReceiveNotification() This returns the notificationID which was triggered, if any(see GetProcSemaphore).
|-
| 0x000C0080
| PublishToSubscriber(u32 notification_id, u32 flag). This fires an notification. Bit0: only fire if not already fired, bit1: return error if error happens, else it always returns 0.
|-
| 0x000D0040
| This can fire notificationIDs and return the number of fired notificationID
|-
| 0x000E00C0
| HasAccessToService(8-byte servicename, u32 strlen). Returns 1 if your process has access to the service.
|}

==Service Manager Process-Manager Port "srv:pm"==
{| class="wikitable" border="1"
|-
! Command Header, prior to [[7.0.0-13]]
! Description
|-
| 0x04030082
| RegisterProcess (u32 procid, u32 wordsz, <nowiki>((wordsz<<16) | 2)</nowiki>, serviceaccesscontrol*).
|-
| 0x04040040
| UnregisterProcess (u32 procid).
|}

The Register command registers a process with the service-manager, which includes registering the serviceaccesscontrol for the process which normally originates from the [[NCCH/Extended_Header|exheader]].

Prior to to [[7.0.0-13]], the commands listed for "srv:" were also accessible under this port with the same command-headers. Starting with [[7.0.0-13]], the "srv:pm" port was changed to a service. With this change, commandIDs for these commands were changed. "srv:pm" was originally vulnerable, this was fixed with [[7.0.0-13]], see [[3DS_exploits|here]]. Originally any process could use "srv:pm", however starting with [[7.0.0-13]] only the built-in NATIVE_FIRM sysmodules have access to it. The only system title which uses "srv:pm" is the [[Process_Manager_Services|Process Manager]].

==Notifications==
{| class="wikitable" border="1"
|-
! ID
! Description
|-
| 0x100
| This indicates that all processes must terminate: power-off, reboot, or [[FIRM]]-launch.
|-
| 0x104
| This indicates that the system is entering sleep mode. (PTM:NotifySleepPreparationComplete needed for this and the following?)
|-
| 0x105
| This indicates that the system has exited sleep mode.
|-
| 0x108
| error at boot?
|-
| 0x202
| POWER button pressed
|-
| 0x204
| This indicates that the HOME button was pressed.
|-
| 0x205
| HOME button pressed
|-
| 0x207
| SD card inserted
|-
| 0x208
| Game cartridge inserted
|-
| 0x209
| SD card removed
|-
| 0x20A
| Game cartridge removed
|-
| 0x20B
| Game cartridge inserted or removed
|}

SVC

2015-09-27T23:24:54Z

WulfyStylez: /* KernelSetState */

= System calls =
{| class="wikitable" border="1"
|-
! Id
! NF ARM11
! NF ARM9
! TF ARM11
! Description
! scope="col" width="200" | Notes
|-
| 0x01
| style="background: green" | Yes
| style="background: red" | No
| style="background: red" | No
| Result ControlMemory(u32* outaddr, u32 addr0, u32 addr1, u32 size, u32 operation, u32 permissions)
| Outaddr is usually the same as the input addr0.
|-
| 0x02
| style="background: green" | Yes
| style="background: red" | No
| style="background: red" | No
| Result QueryMemory(MemoryInfo* info, PageInfo* out, u32 Addr)
|
|-
| 0x03
| style="background: green" | Yes
| style="background: red" | No
| style="background: red" | No
| void ExitProcess(void)
|
|-
| 0x04
| style="background: green" | Yes
| style="background: red" | No
| style="background: red" | No
| Result GetProcessAffinityMask(u8* affinitymask, Handle process, s32 processorcount)
|
|-
| 0x05
| style="background: green" | Yes
| style="background: red" | No
| style="background: red" | No
| Result SetProcessAffinityMask(Handle process, u8* affinitymask, s32 processorcount)
|
|-
| 0x06
| style="background: green" | Yes
| style="background: red" | No
| style="background: red" | No
| Result GetProcessIdealProcessor(s32 *idealprocessor, Handle process)
|
|-
| 0x07
| style="background: green" | Yes
| style="background: red" | No
| style="background: red" | No
| Result SetProcessIdealProcessor(Handle process, s32 idealprocessor)
|
|-
| 0x08
| style="background: green" | Yes
| style="background: green" | Yes
| style="background: green" | Yes
| Result [[Multi-threading#CreateThread|CreateThread]](Handle* thread, func entrypoint, u32 arg, u32 stacktop, s32 threadpriority, s32 processorid)
|
|-
| 0x09
| style="background: green" | Yes
| style="background: green" | Yes
| style="background: green" | Yes
| void [[Multi-threading#ExitThread|ExitThread]](void)
|
|-
| 0x0A
| style="background: green" | Yes
| style="background: green" | Yes
| style="background: green" | Yes
| void [[Multi-threading#SleepThread|SleepThread]](s64 nanoseconds)
|
|-
| 0x0B
| style="background: green" | Yes
| style="background: green" | Yes
| style="background: green" | Yes
| Result [[Multi-threading#GetThreadPriority|GetThreadPriority]](s32* priority, Handle thread)
|
|-
| 0x0C
| style="background: green" | Yes
| style="background: green" | Yes
| style="background: green" | Yes
| Result [[Multi-threading#SetThreadPriority|SetThreadPriority]](Handle thread, s32 priority)
|
|-
| 0x0D
| style="background: green" | Yes
| style="background: red" | No
| style="background: red" | No
| Result [[Multi-threading#GetThreadAffinityMask|GetThreadAffinityMask]](u8* affinitymask, Handle thread, s32 processorcount)
|
|-
| 0x0E
| style="background: green" | Yes
| style="background: red" | No
| style="background: red" | No
| Result [[Multi-threading#SetThreadAffinityMask|SetThreadAffinityMask]](Handle thread, u8* affinitymask, s32 processorcount)
| Replaced with a stub in ARM11 NATIVE_FIRM kernel beginning with [[8.0.0-18]].
|-
| 0x0F
| style="background: green" | Yes
| style="background: red" | No
| style="background: red" | No
| Result [[Multi-threading#GetThreadIdealProcessor|GetThreadIdealProcessor]](s32* processorid, Handle thread)
|
|-
| 0x10
| style="background: green" | Yes
| style="background: red" | No
| style="background: red" | No
| Result [[Multi-threading#SetThreadIdealProcessor|SetThreadIdealProcessor]](Handle thread, s32 processorid)
| Replaced with a stub in ARM11 NATIVE_FIRM kernel beginning with [[8.0.0-18]].
|-
| 0x11
| style="background: green" | Yes
| style="background: red" | No
| style="background: red" | No
| s32 GetCurrentProcessorNumber(void)
|
|-
| 0x12
| style="background: green" | Yes
| style="background: red" | No
| style="background: red" | No
| Result Run(Handle process, StartupInfo* info)
| This starts the main() thread. Buf+0 is main-thread priority, Buf+4 is main-thread stack-size.
|-
| 0x13
| style="background: green" | Yes
| style="background: green" | Yes
| style="background: green" | Yes
| Result [[Multi-threading#CreateMutex|CreateMutex]](Handle* mutex, bool initialLocked)
|
|-
| 0x14
| style="background: green" | Yes
| style="background: green" | Yes
| style="background: green" | Yes
| Result [[Multi-threading#ReleaseMutex|ReleaseMutex]](Handle mutex)
|
|-
| 0x15
| style="background: green" | Yes
| style="background: green" | Yes
| style="background: green" | Yes
| Result [[Multi-threading#CreateSemaphore|CreateSemaphore]](Handle* semaphore, s32 initialCount, s32 maxCount)
|
|-
| 0x16
| style="background: green" | Yes
| style="background: green" | Yes
| style="background: green" | Yes
| Result [[Multi-threading#ReleaseSemaphore|ReleaseSemaphore]](s32* count, Handle semaphore, s32 releaseCount)
|
|-
| 0x17
| style="background: green" | Yes
| style="background: green" | Yes
| style="background: green" | Yes
| Result [[Multi-threading#CreateEvent|CreateEvent]](Handle* event, ResetType resettype)
|
|-
| 0x18
| style="background: green" | Yes
| style="background: green" | Yes
| style="background: green" | Yes
| Result [[Multi-threading#SignalEvent|SignalEvent]](Handle event)
|
|-
| 0x19
| style="background: green" | Yes
| style="background: green" | Yes
| style="background: green" | Yes
| Result [[Multi-threading#ClearEvent|ClearEvent]](Handle event)
|
|-
| 0x1A
| style="background: green" | Yes
| style="background: green" | Yes
| style="background: green" | Yes
| Result CreateTimer(Handle* timer, ResetType resettype)
|
|-
| 0x1B
| style="background: green" | Yes
| style="background: green" | Yes
| style="background: green" | Yes
| Result SetTimer(Handle timer, s64 initial, s64 interval)
|
|-
| 0x1C
| style="background: green" | Yes
| style="background: green" | Yes
| style="background: green" | Yes
| Result CancelTimer(Handle timer)
|
|-
| 0x1D
| style="background: green" | Yes
| style="background: green" | Yes
| style="background: green" | Yes
| Result ClearTimer(Handle timer)
|
|-
| 0x1E
| style="background: green" | Yes
| style="background: red" | No
| style="background: red" | No
| Result CreateMemoryBlock(Handle* memblock, u32 addr, u32 size, u32 mypermission, u32 otherpermission)
|
|-
| 0x1F
| style="background: green" | Yes
| style="background: red" | No
| style="background: red" | No
| Result MapMemoryBlock(Handle memblock, u32 addr, u32 mypermissions, u32 otherpermission)
|
|-
| 0x20
| style="background: green" | Yes
| style="background: red" | No
| style="background: red" | No
| Result UnmapMemoryBlock(Handle memblock, u32 addr)
|
|-
| 0x21
| style="background: green" | Yes
| style="background: green" | Yes
| style="background: green" | Yes
| Result CreateAddressArbiter(Handle* arbiter)
|
|-
| 0x22
| style="background: green" | Yes
| style="background: green" | Yes
| style="background: green" | Yes
| Result ArbitrateAddress(Handle arbiter, u32 addr, ArbitrationType type, s32 value, s64 nanoseconds)
|
|-
| 0x23
| style="background: green" | Yes
| style="background: green" | Yes
| style="background: green" | Yes
| Result CloseHandle(Handle handle)
|
|-
| 0x24
| style="background: green" | Yes
| style="background: green" | Yes
| style="background: green" | Yes
| Result WaitSynchronization1(Handle handle, s64 nanoseconds)
|
|-
| 0x25
| style="background: green" | Yes
| style="background: green" | Yes
| style="background: green" | Yes
| Result WaitSynchronizationN(s32* out, Handle* handles, s32 handlecount, bool waitAll, s64 nanoseconds)
|
|-
| 0x26
| style="background: green" | Yes
| style="background: red" | No
| style="background: red" | No
| Result SignalAndWait(s32* out, Handle signal, Handle* handles, s32 handleCount, bool waitAll, s64 nanoseconds)
| Stubbed
|-
| 0x27
| style="background: green" | Yes
| style="background: green" | Yes
| style="background: green" | Yes
| Result DuplicateHandle(Handle* out, Handle original)
|
|-
| 0x28
| style="background: green" | Yes
| style="background: green" | Yes
| style="background: green" | Yes
| s64 GetSystemTick(void) (This returns the total CPU ticks elapsed since the CPU was powered-on)
|
|-
| 0x29
| style="background: green" | Yes
| style="background: red" | No
| style="background: red" | No
| Result GetHandleInfo(s64* out, Handle handle, HandleInfoType type)
|
|-
| 0x2A
| style="background: green" | Yes
| style="background: green" | Yes
| style="background: green" | Yes
| Result GetSystemInfo(s64* out, SystemInfoType type, s32 param)
|
|-
| 0x2B
| style="background: green" | Yes
| style="background: green" | Yes
| style="background: green" | Yes
| Result GetProcessInfo(s64* out, Handle process, ProcessInfoType type)
|
|-
| 0x2C
| style="background: green" | Yes
| style="background: green" | Yes
| style="background: green" | Yes
| Result [[Multi-threading#GetThreadInfo|GetThreadInfo]](s64* out, Handle thread, ThreadInfoType type)
|
|-
| 0x2D
| style="background: green" | Yes
| style="background: red" | No
| style="background: red" | No
| Result ConnectToPort(Handle* out, const char* portName)
|
|-
| 0x2E
| style="background: green" | Yes
| style="background: red" | No
| style="background: red" | No
| Result SendSyncRequest1(Handle session)
| Stubbed
|
|-
| 0x2F
| style="background: green" | Yes
| style="background: red" | No
| style="background: red" | No
| Result SendSyncRequest2(Handle session)
| Stubbed
|
|-
| 0x30
| style="background: green" | Yes
| style="background: red" | No
| style="background: red" | No
| Result SendSyncRequest3(Handle session)
| Stubbed
|
|-
| 0x31
| style="background: green" | Yes
| style="background: red" | No
| style="background: red" | No
| Result SendSyncRequest4(Handle session)
| Stubbed
|
|-
| 0x32
| style="background: green" | Yes
| style="background: red" | No
| style="background: red" | No
| Result SendSyncRequest(Handle session)
|
|-
| 0x33
| style="background: green" | Yes
| style="background: red" | No
| style="background: red" | No
| Result OpenProcess(Handle* process, u32 processId)
|
|-
| 0x34
| style="background: green" | Yes
| style="background: red" | No
| style="background: red" | No
| Result [[Multi-threading#OpenThread|OpenThread]](Handle* thread, Handle process, u32 threadId)
|
|-
| 0x35
| style="background: green" | Yes
| style="background: red" | No
| style="background: green" | Yes
| Result GetProcessId(u32* processId, Handle process)
|
|-
| 0x36
| style="background: green" | Yes
| style="background: red" | No
| style="background: red" | No
| Result [[Multi-threading#GetProcessIdOfThread|GetProcessIdOfThread]](u32* processId, Handle thread)
|
|-
| 0x37
| style="background: green" | Yes
| style="background: green" | Yes
| style="background: green" | Yes
| Result [[Multi-threading#GetThreadId|GetThreadId]](u32* threadId, Handle thread)
|
|-
| 0x38
| style="background: green" | Yes
| style="background: red" | No
| style="background: red" | No
| Result GetResourceLimit(Handle* resourceLimit, Handle process)
|
|-
| 0x39
| style="background: green" | Yes
| style="background: red" | No
| style="background: red" | No
| Result GetResourceLimitLimitValues(s64* values, Handle resourceLimit, LimitableResource* names, s32 nameCount)
|
|-
| 0x3A
| style="background: green" | Yes
| style="background: red" | No
| style="background: red" | No
| Result GetResourceLimitCurrentValues(s64* values, Handle resourceLimit, LimitableResource* names, s32 nameCount)
|
|-
| 0x3B
| style="background: green" | Yes
| style="background: red" | No
| style="background: red" | No
| Result [[Multi-threading#GetThreadContext|GetThreadContext]](ThreadContext* context, Handle thread)
| Stubbed
|-
| 0x3C
| style="background: green" | Yes
| style="background: green" | Yes
| style="background: green" | Yes
| Break(BreakReason)
|
|-
| 0x3D
| style="background: green" | Yes
| style="background: green" | Yes
| style="background: green" | Yes
| OutputDebugString(void const, int)
| Does nothing on non-debug units.
|-
| 0x3E
| style="background: green" | Yes
| style="background: red" | No
| style="background: red" | No
| ControlPerformanceCounter(unsigned long long, int, unsigned int, unsigned long long)
|
|- style="border-top: double"
| 0x47
| style="background: green" | Yes
| style="background: red" | No
| style="background: red" | No
| Result CreatePort(Handle* portServer, Handle* portClient, const char* name, s32 maxSessions)
| Setting name=NULL creates a private port not accessible from svcConnectToPort.
|-
| 0x48
| style="background: green" | Yes
| style="background: red" | No
| style="background: red" | No
| Result CreateSessionToPort(Handle* session, Handle port)
|
|-
| 0x49
| style="background: green" | Yes
| style="background: red" | No
| style="background: red" | No
| Result CreateSession(Handle* sessionServer, Handle* sessionClient)
|
|-
| 0x4A
| style="background: green" | Yes
| style="background: red" | No
| style="background: red" | No
| Result AcceptSession(Handle* session, Handle port)
|
|-
| 0x4B
| style="background: green" | Yes
| style="background: red" | No
| style="background: red" | No
| Result ReplyAndReceive1(s32* index, Handle* handles, s32 handleCount, Handle replyTarget)
| Stubbed.
|-
| 0x4C
| style="background: green" | Yes
| style="background: red" | No
| style="background: red" | No
| Result ReplyAndReceive2(s32* index, Handle* handles, s32 handleCount, Handle replyTarget)
| Stubbed.
|-
| 0x4D
| style="background: green" | Yes
| style="background: red" | No
| style="background: red" | No
| Result ReplyAndReceive3(s32* index, Handle* handles, s32 handleCount, Handle replyTarget)
| Stubbed.
|-
| 0x4E
| style="background: green" | Yes
| style="background: red" | No
| style="background: red" | No
| Result ReplyAndReceive4(s32* index, Handle* handles, s32 handleCount, Handle replyTarget)
| Stubbed.
|-
| 0x4F
| style="background: green" | Yes
| style="background: red" | No
| style="background: red" | No
| Result ReplyAndReceive(s32* index, Handle* handles, s32 handleCount, Handle replyTarget)
|
|-
| 0x50
| style="background: green" | Yes
| style="background: green" | Yes
| style="background: green" | Yes
| Result BindInterrupt(Interrupt name, Handle syncObject, s32 priority, bool isManualClear)
|
|-
| 0x51
| style="background: green" | Yes
| style="background: green" | Yes
| style="background: green" | Yes
| Result UnbindInterrupt(Interrupt name, Handle syncObject)
|
|-
| 0x52
| style="background: green" | Yes
| style="background: green" | Yes
| style="background: green" | Yes
| Result InvalidateProcessDataCache(Handle process, void* addr, u32 size)
|
|-
| 0x53
| style="background: green" | Yes
| style="background: green" | Yes
| style="background: green" | Yes
| Result StoreProcessDataCache(Handle process, void const* addr, u32 size)
|
|-
| 0x54
| style="background: green" | Yes
| style="background: green" | Yes
| style="background: green" | Yes
| Result FlushProcessDataCache(Handle process, void const* addr, u32 size)
|
|-
| 0x55
| style="background: green" | Yes
| style="background: green" | Yes
| style="background: green" | Yes
| Result StartInterProcessDma(Handle* dma, Handle dstProcess, void* dst, Handle srcProcess, const void* src, u32 size, const DmaConfig& config)
|
|-
| 0x56
| style="background: green" | Yes
| style="background: green" | Yes
| style="background: green" | Yes
| Result StopDma(Handle dma)
|
|-
| 0x57
| style="background: green" | Yes
| style="background: green" | Yes
| style="background: green" | Yes
| Result GetDmaState(DmaState* state, Handle dma)
|
|-
| 0x58
| style="background: green" | Yes
| style="background: green" | Yes
| style="background: green" | Yes
| RestartDma(nn::Handle, void *, void const*, unsigned int, signed char)
|
|- style="border-top: double"
| 0x60
| style="background: green" | Yes
| style="background: red" | No
| style="background: red" | No
| Result DebugActiveProcess(Handle* debug, u32 processID)
|
|-
| 0x61
| style="background: green" | Yes
| style="background: red" | No
| style="background: red" | No
| Result BreakDebugProcess(Handle debug)
|
|-
| 0x62
| style="background: green" | Yes
| style="background: red" | No
| style="background: red" | No
| Result TerminateDebugProcess(Handle debug)
|
|-
| 0x63
| style="background: green" | Yes
| style="background: red" | No
| style="background: red" | No
| Result GetProcessDebugEvent(DebugEventInfo* info, Handle debug)
|
|-
| 0x64
| style="background: green" | Yes
| style="background: red" | No
| style="background: red" | No
| Result ContinueDebugEvent(Handle debug, u32 flags)
|
|-
| 0x65
| style="background: green" | Yes
| style="background: red" | No
| style="background: red" | No
| Result GetProcessList(s32* processCount, u32* processIds, s32 processIdMaxCount)
|
|-
| 0x66
| style="background: green" | Yes
| style="background: red" | No
| style="background: red" | No
| Result GetThreadList(s32* threadCount, u32* threadIds, s32 threadIdMaxCount, Handle domain)
|
|-
| 0x67
| style="background: green" | Yes
| style="background: red" | No
| style="background: red" | No
| Result GetDebugThreadContext(ThreadContext* context, Handle debug, u32 threadId, u32 controlFlags)
|
|-
| 0x68
| style="background: green" | Yes
| style="background: red" | No
| style="background: red" | No
| Result SetDebugThreadContext(Handle debug, u32 threadId, ThreadContext* context, u32 controlFlags)
|
|-
| 0x69
| style="background: green" | Yes
| style="background: red" | No
| style="background: red" | No
| Result QueryDebugProcessMemory(MemoryInfo* blockInfo, PageInfo* pageInfo, Handle process, u32 addr)
|
|-
| 0x6A
| style="background: green" | Yes
| style="background: red" | No
| style="background: red" | No
| Result ReadProcessMemory(void* buffer, Handle debug, u32 addr, u32 size)
|
|-
| 0x6B
| style="background: green" | Yes
| style="background: red" | No
| style="background: red" | No
| Result WriteProcessMemory(Handle debug, void const* buffer, u32 addr, u32 size)
|
|-
| 0x6C
| style="background: green" | Yes
| style="background: red" | No
| style="background: red" | No
| Result SetHardwareBreakPoint(s32 registerId, u32 control, u32 value)
|
|-
| 0x6D
| style="background: green" | Yes
| style="background: red" | No
| style="background: red" | No
| [[Multi-threading#GetDebugThreadParam|GetDebugThreadParam]](long long *, int *, nn::Handle, unsigned int, nn::dmnt::DebugThreadParam)
| Disabled on regular kernel.
|- style="border-top: double"
| 0x70
| style="background: green" | Yes
| style="background: red" | No
| style="background: red" | No
| Result ControlProcessMemory(Handle KProcess, unsigned int Addr0, unsigned int Addr1, unsigned int Size, unsigned int Type, unsigned int Permissions)
|
|-
| 0x71
| style="background: green" | Yes
| style="background: red" | No
| style="background: red" | No
| Result MapProcessMemory(Handle KProcess, unsigned int StartAddr, unsigned int EndAddr)
|
|-
| 0x72
| style="background: green" | Yes
| style="background: red" | No
| style="background: red" | No
| Result UnmapProcessMemory(Handle KProcess, unsigned int StartAddr, unsigned int EndAddr)
|
|-
| 0x73
| style="background: green" | Yes
| style="background: red" | No
| style="background: red" | No
| Result CreateCodeSet(Handle* handle_out, struct CodeSetInfo, u32 code_ptr, u32 ro_ptr, u32 data_ptr)
|
|-
| 0x74
| style="background: green" | Yes
| style="background: red" | No
| style="background: red" | No
| Result RandomStub()
| Stubbed
|-
| 0x75
| style="background: green" | Yes
| style="background: red" | No
| style="background: red" | No
| Result CreateProcess(Handle* handle_out, Handle codeset_handle, u32 arm11kernelcaps_ptr, u32 arm11kernelcaps_num)
|
|-
| 0x76
| style="background: green" | Yes
| style="background: red" | No
| style="background: red" | No
| TerminateProcess(Handle)
|
|-
| 0x77
| style="background: green" | Yes
| style="background: red" | No
| style="background: red" | No
| Result SetProcessResourceLimits(Handle KProcess, Handle KResourceLimit)
|
|-
| 0x78
| style="background: green" | Yes
| style="background: red" | No
| style="background: red" | No
| Result CreateResourceLimit(Handle *KResourceLimit)
|
|-
| 0x79
| style="background: green" | Yes
| style="background: red" | No
| style="background: red" | No
| Result SetResourceLimitValues(Handle res_limit, LimitableResource* resource_type_list, s64* resource_list, u32 count)
|
|-
| 0x7A
| style="background: green" | Yes
| style="background: red" | No
| style="background: green" | Yes
| AddCodeSegment (unsigned int Addr, unsigned int Size)
| Stubbed on NATIVE_FIRM beginning with [[2.0.0-2]]. Used during TWL_FIRM boot.
|-
| 0x7B
| style="background: green" | Yes
| style="background: green" | Yes
| style="background: red" | No
| Backdoor(unsigned int CodeAddress)
| This is used on ARM9 NATIVE_FIRM. No ARM11 processes have access to it without some form of kernelhax.
|-
| 0x7C
| style="background: green" | Yes
| style="background: green" | Yes
| style="background: green" | Yes
| KernelSetState(unsigned int Type, unsigned int Param0, unsigned int Param1, unsigned int Param2)
| The type determines the meaning of each param
|-
| 0x7D
| style="background: green" | Yes
| style="background: red" | No
| style="background: red" | No
| Result QueryProcessMemory(MemInfo *Info, unsigned int *Out, Handle KProcess, unsigned int Addr)
|
|- style="border-top: double"
| 0xFF
| style="background: green" | Yes
| style="background: green" | Yes
| style="background: green" | Yes
| ???
| Debug related? The svcaccesscontrol mask doesn't apply for this SVC. Stubbed on ARM9 NATIVE_FIRM.
|}
NF: NATIVE_FIRM. TF: TWL_FIRM.

Note that "stubbed" here means that the SVC only returns an error, as in the following snippet:

<pre>ROM:FFF04D98 LDR R0, =0xF8C007F4
ROM:FFF04D9C BX LR</pre>
= Types and structures =

== enum MemoryState ==
{| class="wikitable" border="1"
! Memory state flags
! Value
|-
| FREE
| 0
|-
| RESERVED
| 1
|-
| IO
| 2
|-
| STATIC
| 3
|-
| CODE
| 4
|-
| PRIVATE
| 5
|-
| SHARED
| 6
|-
| CONTINUOUS
| 7
|-
| ALIASED
| 8
|-
| ALIAS
| 9
|-
| ALIAS CODE
| 10
|-
| LOCKED
| 11
|}

== enum PageFlags ==
{| class="wikitable" border="1"
! Page flags
! Bit
|-
| LOCKED
| 0
|-
| CHANGED
| 1
|}

== enum MemoryOperation ==

{| class="wikitable" border="1"
! Memory operation
! Id
|-
| FREE
| 1
|-
| RESERVE
| 2
|-
| COMMIT
| 3
|-
| MAP
| 4
|-
| UNMAP
| 5
|-
| PROTECT
| 6
|-
| REGION APP
| 0x100
|-
| REGION SYSTEM
| 0x200
|-
| REGION BASE
| 0x300
|-
| LINEAR
| 0x10000
|}

The LINEAR memory-operation indicates that the mapped physical address is always MappedVAddr+0x0C000000, thus this memory can be used for hardware devices' DMA(such as the [[GPU]]). Addr0+size for this must be within the 0x14000000-0x1C000000 range when Addr0 is non-zero(Addr1 must be zero), Addr0 isn't actually used by svcControlMemory for mapping memory: Addr0 is not used by the kernel after doing address-range checks. The kernel determines what physical-address to use by allocating memory from FCRAM(about the same way as other memory), which is then used to determine the virtual-address.

[[8.0.0-18]] added a new memory mapping(0x30000000-0x38000000) for LINEAR memory, this replaces the original mapping for newer titles. The kernel uses the new mapping when the process memory-region is BASE, or when the process kernel-release-version field is >=0x022c(2.44 / system-version [[8.0.0-18]]).

The input mem-region value for svcControlMemory is only used(when non-zero) when the PID is value 1, for the [[FIRM]] ARM11 "loader" module.

== enum MemoryPermission ==

{| class="wikitable" border="1"
! Memory permission
! Id
|-
| NONE
| 0
|-
| R
| 1
|-
| W
| 2
|-
| RW
| 3
|-
| X
| 4
|-
| RX
| 5
|-
| WX
| 6
|-
| RWX
| 7
|-
| DONTCARE
| 0x10000000
|}

== enum ResetType ==

{| class="wikitable" border="1"
! Reset type
! Id
|-
| ONESHOT
| 0
|-
| STICKY
| 1
|-
| PULSE
| 2
|}

== struct MemoryInfo ==
{| class="wikitable" border="1"
! Type
! Field
|-
| u32
| Base process virtual address
|-
| u32
| Size
|-
| u32
| Permission
|-
| enum MemoryState
| State
|}

== struct PageInfo ==
{| class="wikitable" border="1"
! Type
! Field
|-
| u32
| Flags
|}

== struct StartupInfo ==
{| class="wikitable" border="1"
! Type
! Field
|-
| s32
| Priority
|-
| u32
| Stack size
|-
| s32
| argc
|-
| s16*
| argv
|-
| s16*
| envp
|}

== enum ArbitrationType ==
{| class="wikitable" border="1"
! Address arbitration type
! Value
|-
| FREE
| 0
|-
| AQUIRE
| 1
|-
| KERNEL2
| 2
|-
| AQUIRE_TIMEOUT
| 3
|-
| KERNEL4
| 4
|}

== enum BreakReason ==
{| class="wikitable" border="1"
! Break Reason
! Value
|-
| PANIC
| 0
|-
| ASSERT
| 1
|-
| USER
| 2
|}

== struct CodeSetInfo ==
All addresses are given virtual for the process to be created.
All sizes are given in 0x1000-pages.

{| class="wikitable" border="1"
! Type
! Field
|-
| u8[8]
| Codeset Name
|-
| u16
| Unknown, this is written to field 0x5A of KCodeSet
|-
| u16
| Unknown/padding
|-
| u32
| Unknown/padding
|-
| u32
| .text addr
|-
| u32
| .text size
|-
| u32
| .rodata start
|-
| u32
| .rodata size
|-
| u32
| RW addr (.data + .bss)
|-
| u32
| RW size (.data + .bss)
|-
| u32
| Total .text pages
|-
| u32
| Total .rodata pages
|-
| u32
| Total RW pages (.data + .bss)
|-
| u32
| Unknown/padding
|-
| u8[8]
| Program ID
|}

== struct DebugEventInfo ==

{| class="wikitable" border="1"
! Type
! Field
|-
| u32
| Event type
|-
| u32
| Thread ID (not used in all events)
|-
| u32[2]
| Unknown/padding
|-
| u32[6]
| Event-specific data (see below)
|}

{| class="wikitable" border="1"
! Event type
! Id
|-
| PROCESS
| 0
|-
| CREATE THREAD
| 1
|-
| EXIT THREAD
| 2
|-
| EXIT PROCESS
| 3
|-
| EXCEPTION
| 4
|-
| DLL LOAD
| 5
|-
| DLL UNLOAD
| 6
|-
| SCHEDULE IN
| 7
|-
| SCHEDULE OUT
| 8
|-
| SYSCALL IN
| 9
|-
| SYSCALL OUT
| 10
|-
| OUTPUT STRING
| 11
|-
| MAP
| 12
|}

=== PROCESS event ===

{| class="wikitable" border="1"
! Type
! Field
|-
| u64
| Program ID
|-
| char[8]
| Process name
|-
| u32
| Process ID
|-
| u32
| 0 = newly created process, 1 = attached process
|}

=== CREATE THREAD event ===

{| class="wikitable" border="1"
! Type
! Field
|-
| u32
| Creator thread ID
|-
| u32
| Base address (?)
|-
| u32
| Entrypoint
|}

=== EXIT THREAD/PROCESS events ===

A single u32 reason field is used.

Thread exit reasons:
{| class="wikitable" border="1"
! Reason
! Id
|-
| (None)
| 0
|-
| TERMINATE
| 1
|-
| EXIT PROCESS
| 2
|-
| TERMINATE PROCESS
| 3
|}

Process exit reasons:
{| class="wikitable" border="1"
! Reason
! Id
|-
| (None)
| 0
|-
| TERMINATE
| 1
|-
| UNHANDLED EXCEPTION
| 2
|}

=== EXCEPTION event ===

{| class="wikitable" border="1"
! Type
! Field
|-
| u32
| Exception type
|-
| u32
| Exception address
|-
| u32
| Argument (type-specific)
|}

Exception types:
{| class="wikitable" border="1"
! Reason
! Id
! Argument
|-
| UNDEFINED INSTRUCTION
| 0
| (None)
|-
| (Unknown)
| 1
| (None)
|-
| (Unknown, mem-related)
| 2
| Address
|-
| (Unknown, mem-related)
| 3
| Address
|-
| ATTACH BREAK
| 4
| (None)
|-
| BREAKPOINT
| 5
| (None)
|-
| USER BREAK
| 6
| User break type
|-
| DEBUGGER BREAK
| 7
| (None)
|-
| UNDEFINED SYSCALL
| 8
| Attempted syscall ID
|}

User break types:
{| class="wikitable" border="1"
! Reason
! Id
|-
| PANIC
| 0
|-
| ASSERT
| 1
|-
| USER
| 2
|}

=== SCHEDULER/SYSCALL IN/OUT events ===

{| class="wikitable" border="1"
! Type
! Field
|-
| u64
| Clock tick
|-
| u32
| Syscall (only for SYSCALL events)
|}

=== OUTPUT STRING event ===

{| class="wikitable" border="1"
! Type
! Field
|-
| u32
| String address
|-
| u32
| String size
|}

=== MAP event ===

{| class="wikitable" border="1"
! Type
! Field
|-
| u32
| Mapped address
|-
| u32
| Mapped size
|-
| u32
| MemoryPermission
|-
| u32
| MemoryState
|}

=svcSetHardwareBreakPoint=
This is essentially an interface for writing values to the debug-unit (B/W)RP registers. registerId range 0..5 = breakpoints(BRP0-5), 0x100..0x101 = watchpoints(WRP0-1), anything outside of these ranges will result in an error. This is used for both adding and removing/disabling breakpoints/watchpoints, hence the raw control value parameter.

Here the kernel sets bit15 in the DSCR, to enable monitor-mode debugging.

Regardless of whether this is for a BRP, when bit21 is set in the control input parameter(BRP type = contextID), the kernel will load the target process [[KProcess|contextID]] and use that internally for the value field. The target process is specified via a [[KDebug]] handle passed as the "value" parameter.

Lastly, the kernel disables the specified (B/W)RP, then writes the value parameter / loaded contextID to the (B/W)VR, then writes the input control value to the (B/W)CR.

= Processes =
Each process can only use SVCs which are enabled in the [[NCCH#CXI|exheader]] for this process. The ARM11 kernel SVC handler checks whether the SVC is enabled in the syscall access control mask stored on the SVC-mode stack, when the SVC isn't enabled a kernelpanic() is triggered. Each process has a separate SVC-mode stack, this stack and the syscall access mask stored here is initialized when the process is started. Applications normally only have access to SVCs <=0x3D, however not all SVCs <=0x3D are accessible to the application. The majority of the SVCs accessible to applications are unused by the application.

Each process has a separate handle-table, the size of this table is stored in the exheader. The handles in a handle-table can't be used in the context of other processes, since those handles don't exist in other handle-tables.

0xFFFF8001 is a handle alias for the current KProcess, and 0xFFFF8000 is a handle alias for the current KThread.

Calling svcBreak on retail will only terminate the process which called this SVC.

= Threads =
For svcCreateThread the input address used for Entrypoint_Param and StackTop are normally the same, however these can be arbitrary. For the main thread the Entrypoint_Param is value 0.

Using CloseHandle() with a KThread handle will terminate the specified thread, only if the reference count reaches 0.

Lower priority values give the thread higher priority. For userland apps, priorities between 0x18 and 0x3F are allowed. The priority of the app's main thread seems to be 0x30.

The thread scheduler is cooperative, therefore if a thread takes up all the CPU time (for example if it enters an endless loop), all the other threads that run on the same CPU core won't get a chance to run. The main way of yielding another thread is using an address arbiter.

= Memory Mapping =
ControlMemory and MapMemoryBlock can be used to map memory pages, these two SVCs only support mapping execute-never R/W pages. The input permissions parameter for these SVCs must therefore be <=3, where value zero is used when un-mapping memory. Furthermore it appears that only regular heap pages can be mirrored (it won't work for TLS, stack, .data, .text, for example).

Bitmask 0xF00 for ControlMemory parameter MemoryType is the memory-type, when this is zero the memory-type is loaded from the kernel flags stored in the exheader ARM11 kernel descriptors, for the process using the SVC.

ControlMemory parameter MemoryType with value 0x10003 is used for mapping the GSP [[Memory_layout|heap]]. The low 8-bits are the type: 1 is for un-mapping memory, 3 for mapping memory. Type4 is used to mirror the RW memory at Addr1, to Addr0. Type4 will return an error if Addr1 is located in read-only memory. Addr1 is not used for type1 and type3.

The ARM11 kernel does not allow processes to create shared memory blocks via svcCreateMemoryBlock, when the process memorytype(from the kernel flags stored in the exheader kernel descriptor) is the application memorytype, and when addr=0. It's unknown how the kernel handles addr=0 when the memorytype is not the application memorytype. When addr is non-zero, it must be located in memory which is already mapped. Furthermore, it appears that only regular heap pages (allocated using svcControlMemory op=COMMIT) are accepted as valid addrs.

ControlProcessMemory maps memory in the specified process, this is the only SVC which allows mapping executable memory. Format of the permissions field for memory mapping SVCs: bit0=R, bit1=W, bit2=X. Type6 sets the Addr0 memory permissions to the input permissions, for already mapped memory. Type is the MemoryOperation enum, without the memory-type/memory-region. ControlProcessMemory only supports type4, type5, and type6. ControlProcessMemory does not support using the current KProcess handle alias.

MapProcessMemory maps RW memory starting at address 0x00100000 in the specified KProcess, at the specified StartAddr in the current process. MapProcessMemory then maps 0x08000000 in the specified process, to StartAddr+0x7f00000 in the current process. UnmapProcessMemory unmaps the memory which was mapped by MapProcessMemory.

Note that with the MAP MemoryOperation, the kernel will refuse to MAP memory for the specified addr1, when addr1 was already used with another MAP operation as addr1. The kernel also doesn't allow memory to be freed via the FREE MemoryOperation, when other virtual-memory is mapped to this same memory(when the MAP MemoryOperation was used with this memory with addr1).

= [[DMA]] =
The CTRSDK code for using svcStartInterProcessDma will execute svcBreak when svcStartInterProcessDma returns an error(except for certain error value(s)). Therefore on retail, triggering a svcStartInterProcessDma via a system-module which results in an error from svcStartInterProcessDma will result in the system-module terminating.

= Debugging =
DebugActiveProcess is used to attach to a process for debugging. This SVC can only be used when the target process' ARM11 descriptors stored in the exheader have the kernel flag for "Enable debug" set. Otherwise when that flag is clear, the kernel flags for the process using this SVC must have the "Force debug" flag set.

= KernelSetState =
{| class="wikitable" border="1"
|-
! Type
! Enabled for the NATIVE_FIRM ARM11 kernel
! Enabled for the TWL_FIRM ARM11 kernel
! Description
|-
| 0
| Yes
| No
| This initializes the programID for launching [[FIRM]], then triggers launching [[FIRM]]. Param0 is unused. Param1 is the programID-low, and the programID-high is 0x00040138. Param2 is used only with the [[New_3DS]] kernel, pm-module uses value 0 with this. With New3DS kernel, it forces the programIDlow to be the New3DS NATIVE_FIRM, when the input programIDlow is for the Old3DS NATIVE_FIRM and Param2==0.
|-
| 1
| Yes
| Yes
| Unknown, does nothing with the TWL_FIRM ARM11 kernel.
|-
| 2
| Yes
| Yes
| ?
|-
| 3
| Yes
| No
| This used for initializing the 0x1000-byte buffer used by the launched [[FIRM]]. Param2 is unused. When Param0 is value 1, this buffer is copied to the beginning of FCRAM at 0xF0000000, and Param1 is unused. When Param0 is value 0, this kernel buffer is mapped to process address Param1.
|-
| 4
| No
| Yes
| Param0-Param3 are unused. This unmaps(?) the following virtual memory by writing value physaddr(where physaddr base is 0x80000000) to the L1 MMU table entries: 0x00300000..0x04300000, 0x08000000..0x0FE00000, and 0x10000000..0xF8000000.
|-
| 5
| Yes
| Yes
| ?
|-
| 6
| Yes
| No
| Debug related?
|-
| 7
| Yes
| No
| This triggers an MCU (hard) reboot. Param0-3 are unused. This reboot is triggered via device address 0x4A on the second [[I2C]] bus (the MCU). Register address 0x20 is written to with value 4. This code will not return.
|-
| 8
| Yes
| No
| Alternate unused FIRM launch code-path, with different [[PXI]] FIFO word constants.
|-
| 9
| Yes, implemented at some point after system-version v4.5.
| ?
| Unknown
|-
| 10
| Yes
| ?
| ConfigureNew3DSCPU. Only available for the [[New_3DS]] kernel. Param0 = input value. Only bit0-1 are used here. Bit 0 enables higher core clock, and bit 1 enables additional (L2) cache. This configures the hardware [[PDN_Registers|register]] for the flags listed [[NCCH/Extended_Header#Flag1|here]], among other code which uses the MPCore private memory region registers.
|}

= GetSystemInfo =
{| class="wikitable" border="1"
! SystemInfoType value
! s32 param
! Description
|-
| 0
| 0
| This writes the total used memory size in the following memory regions to out: APPLICATION, SYSTEM, and BASE.
|-
| 0
| 1
| This writes the total used memory size in the APPLICATION memory region to out.
|-
| 0
| 2
| This writes the total used memory size in the SYSTEM memory region to out.
|-
| 0
| 3
| This writes the total used memory size in the BASE memory region to out.
|-
| 25
| Unused
| This writes the total number of threads which were directly launched by the kernel, to out.
|-
| 26
| Unused
| This writes the total number of processes which were directly launched by the kernel, to out. For the NATIVE_FIRM/SAFE_MODE_FIRM ARM11 kernel, this is normally 5, for processes sm, fs, pm, loader, and pxi.
|}

= GetProcessInfo =
Input:
R0 = unused
R1 = Handle process
R2 = ProcessInfoType type

Output:
R0 = Result
R1 = output value lower word
R2 = output value upper word

{| class="wikitable" border="1"
! ProcessInfoType value
! Available since system version
! Description
|-
| 9-19
| [[8.0.0-18]]
| This only returns error 0xD8E007ED.
|-
| 20
| [[8.0.0-18]]
| low u32 = (0x20000000 - <LINEAR virtual-memory base for this process>). That is, the output value is the value which can be added to LINEAR memory vaddrs for converting to physical-memory addrs.
|-
| 21-23
| [[8.0.0-18]]
| This only returns error 0xE0E01BF4.
|}

= GetHandleInfo =

{| class="wikitable" border="1"
! HandleInfoType value
! Description
|-
| 0
| This returns the time in ticks the KProcess referenced by the handle was created. If a KProcess handle was not given, it will write whatever was in r5, r6 when the svc was called.
|-
| 1
| Get internal refcount-1 for kernel object (u32), and also a boolean if the refcount-1 is negative (u32).
|-
| 0x32107
| Returns (u64) 0.
|}

= svc7B Backdoor =
This saves SVC-mode SP+LR on the user-mode stack, then sets the SVC-mode SP to the user-mode SP. This then calls the specified code in SVC-mode. Once the called code returns, this pops the saved SP+LR off the stack for restoring the SVC-mode SP, then returns from the svc7b handler. Note that this svc7b handler does not disable IRQs, if any IRQs/context-switches occur while the SVC-mode SP is set to the user-mode one here, the ARM11-kernel will crash(which hangs the whole ARM11-side system).

= Kernel error-codes =
See [[Error codes]].

{| class="wikitable" border="1"
! Error-code value
! Description
|-
| 0x09401BFE
| Timeout occurred with svcWaitSynchronization*, when timeout is not ~0.
|-
| 0xC8601801
| No more unused/free synchronization objects left to use in a given object's linked list. (KEvent, KMutex, KTimer, KSemaphore, KAddressArbiter, KThread)
|-
| 0xC8601802
| No more unused/free KSharedMemory objects left to use in the KSharedMemory linked list - out of blocks
|-
| 0xC8601809
| No more unused/free KSessions left to use in the KSession linked list - out of sessions
|-
| 0xC860180A
| Not enough free memory available for memory allocation.
|-
| 0xC920181A
| The session was closed by the other process..
|-
| 0xD0401834
| Max connections to port have been exceeded
|-
| 0xD88007FA
| Returned if no KObjectName object in the linked list of such objects matches the port name provided to the svc.
|-
| 0xD8E007ED
| This indicates that a value is outside of the enum being used.
|-
| 0xD8E007F1
| This error indicates Misaligned address.
|-
| 0xD8E007F7
| This error indicates that the input handle used with the SVC does not exist in the process handle-table, or that the handle kernel object type does not match the type used by the SVC.
|-
| 0xD9000402
| Invalid memory permissions for input/output buffers, for svcStartInterProcessDma.
|-
| 0xD9001814
| Failed unprivileged load or store - wrong permissions on memory
|-
| 0xD9001BF7
| This error is returned when the kernel retrieves a pointer to a kernel object, but the object type doesn't match the desired one.
|-
| 0xD92007EA
| This error is returned when a process attempts to use svcCreateMemoryBlock when the process memorytype is the application memorytype, and when addr=0.
|-
| 0xE0E01BF5
| This indicates an invalid address was used.
|-
| 0xF8C007F4
| Invalid type/param0-param3 input for svcKernelSetState. This is also returned for those syscalls marked as stubs.
|}

Hardware

2015-09-18T19:04:45Z

WulfyStylez: new3DS clock stuff

This page lists and describes the hardware found inside the Nintendo 3DS. Many of these parts are custom made and are expanded upon here or in other pages.

== Common hardware ==
{| class="wikitable"
! Type !! Description
|-
| ARM11 Processor Core || [http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0360f/index.html ARM11 2x MPCore & 2x VFPv2 Co-Processor] 268MHz(~268123480 Hz).
On New3DS models, there is instead 4x MPCore & 4x VFPv2.
|-
| ARM9 Processor Core || [http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0201d/index.html ARM946] 134MHz(~134058675 Hz),
|-
| GPU || [http://en.wikipedia.org/wiki/PICA200 DMP PICA] 268MHz,
|-
| DSP || [https://twitter.com/CEVADSP/status/177172880918986752 CEVA TeakLite]. 134Mhz. 24ch 32728Hz sampling rates.
|-
| VRAM || 6 MB within SoC.
|}
The above clock-rates were calculated by calling svcGetSystemTick in sets of 5(call it, execute svcSleepThread for 1s, then call it again), then the average of those were calculated. The clock-rate listed above applies for *all* 4 New3DS MPCores.

New3DS exclusives are able to clock the CPU at 804MHz, but this appears to be limited to the currently running application/app cores. (timed by running svcGetSystemTick on either side of a long idle loop to stay in the current process context. svcSleepThread + svcGetSystemTick implies a tick counter running at 268mhz in this mode.)

== Specifications ==
{| class="wikitable"
! Type !! 3DS !! 3DSXL !! 2DS !! N3DS !! N3DSXL
|-
| SoC || CPU CTR (1048 0H)
CPU CTR (1214 32)
|| CPU CTR A (1226 60)
CPU CTR (1037 21)
|| CPU CTR B (??) || CPU LGR A (1444 86) || CPU LGR A (1446 17)
|-
| FCRAM || [http://www.fujitsu.com/downloads/MICRO/fma/pdf/MB81EDS516545_e511463.pdf 2x64MB Fujitsu MB82M8080-07L] || Fujitsu MB82DBS16641 || Fujitsu MB82DBS1664 || ?? || Fujitsu MB82MK9A9A
|-
| Storage || Toshiba THGBM2G3P1FBAI8 1GB || ?? || Toshiba THGBM4G3P1H8BAIR 1GB || Samsung KLM4G1YEQC 4GB (in 1.3GiB SLC mode)
Toshiba THGBMBG4P1KBAIT 2GB (MLC)
|| Samsung KLM4G1YEMD-B031 4GB (in 1.3GiB SLC mode)
Toshiba THGBMBG4P1KBAIT (MLC)
|-
| Audio Codec || TI PAIC3010B 0AA37DW || ?? || ?? || TI AIC3010B 39C4ETW || TI AIC3010D 48C01JW
|-
| Gyroscope || [http://dl-web.dropbox.com/u/20520664/references/PS-ITG-3200-00-01.4.pdf Invensense ITG-3270 MEMS Gyroscope] || ?? || ?? || ?? || ??
|-
| Accelerometer || ST Micro 2048 33DH X1MAQ Accelerometer Model LIS331DH || ?? || ?? || ?? || ??
|-
| Wifi || Atheros AR6014 || ?? || ?? || ?? || Atheros AR6014G-AL1C
|-
| Infrared IC || NXP S750 0803 TSD031C || ?? || ?? || ?? || NXP S750 1603 TSD438C
|-
| Custom Microcontroller || Renesas UC CTR || ?? || Renesas UC CTR 324KM47 KG10 || Renesas UC KTR || Renesas UC KTR 442KM13 TK14
|-
| PMIC? || TI 93045A4 OAAH86W || ?? || ?? || TI 93045A4 38A6TYW G2 || TI 93045A4 49AF3NW G2
|}

* [11] Official Documentation

* [5],[10] According to iFixit.com ([http://www.ifixit.com/Teardown/Nintendo-3DS-Teardown/5029/1#s22696 source]):

* Datasheet for memory is for a chip in the same series, it has less memory than the one inside the 3DS (128mbits vs 512mbits).

* There is a trove of data on the FCC website at [https://fjallfoss.fcc.gov/oetcf/eas/reports/ViewExhibitReport.cfm?mode=Exhibits&RequestTimeout=500&calledFromFrame=N&application_id=462292&fcc_id=%27EW4DWMW028%27].

* [12] This IC is somewhat similar to [http://www.alldatasheet.net/datasheet-pdf/pdf/347838/NXP/SC16IS750IBS.html this].

== FCRAM ==

There is one FCRAM (Fast Cycle RAM) IC in the 3DS, produced by Fujitsu and branded as MB82M8080-07L. The Fujitsu MB82M8080-07L chip internally contains 2 dies, where each die is branded MB81EDS516545 and MB82DBS08645.

The MB81EDS516545 die is a CMOS Fast Cycle Random Access Memory (FCRAM) with Low Power Double Data Rate (LPDDR) SDRAM Interface containing 512MBit storage accessible in a 64-bit format. The MB81EDS516545 is suited for consumer applications requiring high data bandwidth with low power consumption.

== SoC ==

The 3DS has much of it's internals housed in a SoC (System on Chip) just like it's predecessors. This is done to reduce build costs, cut down on power consumption, as well as make the PCB layout less complex and make the system harder to tamper with. The SoC, branded as the Nintendo 1048 0H, contains the CPU, GPU, DSP and VRAM.

According to official documents, the CPU used is a dual-core ARM11 CPU, clocked at 268MHz. One core is dedicated to system software, while the other is used for application programming, each known as the syscore and appcore, respectively.

== GPU ==

Designed by Digital Media Professionals Inc. (DMP) and codenamed PICA200, 268Mhz.

Block diagram of an ULTRAY2000 based architecture PICA200:

[[File:Pica200BlockDiagram.png]]

PICA200 is compatible with OpenGL ES 1.1. It furthermore provides unique functionality for:
* Per-fragment lighting ("Lighting Maestro")
* Hard- and soft-shadowing ("Shadow Maestro")
* Polygon subdivision ("Figure Maestro")
* Bump mapping and procedural textures ("Mapping Maestro")
* Rendering of gaseous objects ("Particle Maestro")

Some parts of the extended functionality are provided in hardware by an extended geometry pipeline. Most importantly, PICA200 has three programmable vertex processors. There is furthermore a unit called [[GPU/Primitive_Engine|Primitive Engine]], which is a geometry shader unit (using the same instruction set as vertex shaders) with support for variable-size primitives. The Primitive Engine functionality may be disabled, and the geometry shader unit then acts as a fourth vertex processor. See [[Shader_Instruction_Set]] for more information on the shader instruction set.

[[GPU/Fragment Lighting|Fragment lighting]] is implemented as an optional pipeline step during pixel processing. It's implemented by having the vertex shader output an additional attribute describing the transformation (represented by a quaternion) to surface-local space. This per-vertex quaternion can then be interpolated across screen space to calculate dot products relevant for lighting (e.g. light vector dot normal vector). To provide support for advanced lighting models, these dot products are used as indices into programmable lookup tables. With this setup, PICA200 in particular supports the shading models Blinn-Phong, Cook-Terrance, Ward, and microfacet-based BRDF-models.

PICA200 supports four texture units, the fourth of which is used exclusively for [[GPU/Procedural Texture Generation|procedural texture generation]].

== SDIO controller ==

Nintendo recommends SD cards up to 32 GB however the internal SDIO controller seems to support SD cards up to 2.19 Terabyte (32-bit sector number). It's unknown if it really can handle that much. 128 GB was tested and works fine however it causes a major slowdown of the system especially at boot.

== Images ==

=== Front ===

[[Image:CTR_Front.jpg|600px]]

[http://guide-images.ifixit.net/igi/ishJaSCOwLkvbLYK High Resolution]

=== Back ===

[[Image:CTR_Back.jpg]]

[http://guide-images.ifixit.net/igi/n1CKAdbPrHyNPNuW High Resolution]

=== NAND pinout ===

NAND dumping has been successful, but the image is encrypted.

==== Normal model ====

[[Image:CTR_NAND_pinout.png]]

==== XL model ====

[[Image:CTR_NAND_pinout_XL.jpg|500px]]

==== 2DS ====

[[Image:2DSeMMC.jpg|500px]]

==== New 3DS ====

[[Image:N3DSeMMC.jpg]]

==== New 3DS XL ====

[[Image:N3DSXLeMMC.jpg]]

=== WiFi dongle pinout ===
[[Image:CTR_WiFiDongle_pinout.png|600px]]

SDIO interface is colored red:
* CLK
* CMD
* D0, D1, D2, D3

This is the interface for the 'NEW' WiFi module (based on Atheros AR6002) first included in DSi.

The proprietary and by now ancient DS-mode WiFi is colored yellow, pins are unknown.

I2C eeprom is colored blue:
* SCL
* SDA

SPI Flash is colored purple:
* CLK
* CS#
* SI
* SO
* WP#
* NC

=== Auxiliary Microntroller ===
[[Image:CTR_UC.png|600px]]

Monitors HOME button, WiFi switch, 3D slider, volume control slider.
Controls LEDs, various power supplies.

Devices attached to I2C bus:
* UC (master?)
* Accelerometer (slave address 0x18)
* SoC (master? slave?)

FS:UpdateSha256Context

2015-08-16T08:23:54Z

WulfyStylez: /* Request */

=Request=
{| class="wikitable" border="1"
|-
! Index Word
! Description
|-
| 0
| Header code [0x084E0342]
|-
| 1-8
| Input hash (when updating)
|-
| 9
| Input data buffer size
|-
| 10
| Must be non-zero
|-
| 11
| Must be non-zero
|-
| 12
| u8, must be non-zero
|-
| 13
| u8, must be non-zero
|-
| 14
| (Size<<4) <nowiki>|</nowiki> 10
|-
| 15
| Input data buffer ptr
|}

=Response=
{| class="wikitable" border="1"
|-
! Index Word
! Description
|-
| 0
| Header code
|-
| 1
| Resultcode
|-
| 2-9
| Output SHA256 hash
|-
| 10
| (Size<<4) <nowiki>|</nowiki> 10
|-
| 11
| Data buffer ptr, same buffer from the input.
|}

=Description=
This calculates a SHA256 hash using the ARM11 hash engine.

SVC

2015-08-15T20:50:43Z

WulfyStylez: This was rough.

= System calls =
{| class="wikitable" border="1"
|-
! Id
! NF ARM11
! NF ARM9
! TF ARM11
! Description
! scope="col" width="200" | Notes
|-
| 0x01
| style="background: green" | Yes
| style="background: red" | No
| style="background: red" | No
| Result ControlMemory(u32* outaddr, u32 addr0, u32 addr1, u32 size, u32 operation, u32 permissions)
| Outaddr is usually the same as the input addr0.
|-
| 0x02
| style="background: green" | Yes
| style="background: red" | No
| style="background: red" | No
| Result QueryMemory(MemoryInfo* info, PageInfo* out, u32 Addr)
|
|-
| 0x03
| style="background: green" | Yes
| style="background: red" | No
| style="background: red" | No
| void ExitProcess(void)
|
|-
| 0x04
| style="background: green" | Yes
| style="background: red" | No
| style="background: red" | No
| Result GetProcessAffinityMask(u8* affinitymask, Handle process, s32 processorcount)
|
|-
| 0x05
| style="background: green" | Yes
| style="background: red" | No
| style="background: red" | No
| Result SetProcessAffinityMask(Handle process, u8* affinitymask, s32 processorcount)
|
|-
| 0x06
| style="background: green" | Yes
| style="background: red" | No
| style="background: red" | No
| Result GetProcessIdealProcessor(s32 *idealprocessor, Handle process)
|
|-
| 0x07
| style="background: green" | Yes
| style="background: red" | No
| style="background: red" | No
| Result SetProcessIdealProcessor(Handle process, s32 idealprocessor)
|
|-
| 0x08
| style="background: green" | Yes
| style="background: green" | Yes
| style="background: green" | Yes
| Result [[Multi-threading#CreateThread|CreateThread]](Handle* thread, func entrypoint, u32 arg, u32 stacktop, s32 threadpriority, s32 processorid)
|
|-
| 0x09
| style="background: green" | Yes
| style="background: green" | Yes
| style="background: green" | Yes
| void [[Multi-threading#ExitThread|ExitThread]](void)
|
|-
| 0x0A
| style="background: green" | Yes
| style="background: green" | Yes
| style="background: green" | Yes
| void [[Multi-threading#SleepThread|SleepThread]](s64 nanoseconds)
|
|-
| 0x0B
| style="background: green" | Yes
| style="background: green" | Yes
| style="background: green" | Yes
| Result [[Multi-threading#GetThreadPriority|GetThreadPriority]](s32* priority, Handle thread)
|
|-
| 0x0C
| style="background: green" | Yes
| style="background: green" | Yes
| style="background: green" | Yes
| Result [[Multi-threading#SetThreadPriority|SetThreadPriority]](Handle thread, s32 priority)
|
|-
| 0x0D
| style="background: green" | Yes
| style="background: red" | No
| style="background: red" | No
| Result [[Multi-threading#GetThreadAffinityMask|GetThreadAffinityMask]](u8* affinitymask, Handle thread, s32 processorcount)
|
|-
| 0x0E
| style="background: green" | Yes
| style="background: red" | No
| style="background: red" | No
| Result [[Multi-threading#SetThreadAffinityMask|SetThreadAffinityMask]](Handle thread, u8* affinitymask, s32 processorcount)
| Replaced with a stub in ARM11 NATIVE_FIRM kernel beginning with [[8.0.0-18]].
|-
| 0x0F
| style="background: green" | Yes
| style="background: red" | No
| style="background: red" | No
| Result [[Multi-threading#GetThreadIdealProcessor|GetThreadIdealProcessor]](s32* processorid, Handle thread)
|
|-
| 0x10
| style="background: green" | Yes
| style="background: red" | No
| style="background: red" | No
| Result [[Multi-threading#SetThreadIdealProcessor|SetThreadIdealProcessor]](Handle thread, s32 processorid)
| Replaced with a stub in ARM11 NATIVE_FIRM kernel beginning with [[8.0.0-18]].
|-
| 0x11
| style="background: green" | Yes
| style="background: red" | No
| style="background: red" | No
| s32 GetCurrentProcessorNumber(void)
|
|-
| 0x12
| style="background: green" | Yes
| style="background: red" | No
| style="background: red" | No
| Result Run(Handle process, StartupInfo* info)
| This starts the main() thread. Buf+0 is main-thread priority, Buf+4 is main-thread stack-size.
|-
| 0x13
| style="background: green" | Yes
| style="background: green" | Yes
| style="background: green" | Yes
| Result [[Multi-threading#CreateMutex|CreateMutex]](Handle* mutex, bool initialLocked)
|
|-
| 0x14
| style="background: green" | Yes
| style="background: green" | Yes
| style="background: green" | Yes
| Result [[Multi-threading#ReleaseMutex|ReleaseMutex]](Handle mutex)
|
|-
| 0x15
| style="background: green" | Yes
| style="background: green" | Yes
| style="background: green" | Yes
| Result [[Multi-threading#CreateSemaphore|CreateSemaphore]](Handle* semaphore, s32 initialCount, s32 maxCount)
|
|-
| 0x16
| style="background: green" | Yes
| style="background: green" | Yes
| style="background: green" | Yes
| Result [[Multi-threading#ReleaseSemaphore|ReleaseSemaphore]](s32* count, Handle semaphore, s32 releaseCount)
|
|-
| 0x17
| style="background: green" | Yes
| style="background: green" | Yes
| style="background: green" | Yes
| Result [[Multi-threading#CreateEvent|CreateEvent]](Handle* event, ResetType resettype)
|
|-
| 0x18
| style="background: green" | Yes
| style="background: green" | Yes
| style="background: green" | Yes
| Result [[Multi-threading#SignalEvent|SignalEvent]](Handle event)
|
|-
| 0x19
| style="background: green" | Yes
| style="background: green" | Yes
| style="background: green" | Yes
| Result [[Multi-threading#ClearEvent|ClearEvent]](Handle event)
|
|-
| 0x1A
| style="background: green" | Yes
| style="background: green" | Yes
| style="background: green" | Yes
| Result CreateTimer(Handle* timer, ResetType resettype)
|
|-
| 0x1B
| style="background: green" | Yes
| style="background: green" | Yes
| style="background: green" | Yes
| Result SetTimer(Handle timer, s64 initial, s64 interval)
|
|-
| 0x1C
| style="background: green" | Yes
| style="background: green" | Yes
| style="background: green" | Yes
| Result CancelTimer(Handle timer)
|
|-
| 0x1D
| style="background: green" | Yes
| style="background: green" | Yes
| style="background: green" | Yes
| Result ClearTimer(Handle timer)
|
|-
| 0x1E
| style="background: green" | Yes
| style="background: red" | No
| style="background: red" | No
| Result CreateMemoryBlock(Handle* memblock, u32 addr, u32 size, u32 mypermission, u32 otherpermission)
|
|-
| 0x1F
| style="background: green" | Yes
| style="background: red" | No
| style="background: red" | No
| Result MapMemoryBlock(Handle memblock, u32 addr, u32 mypermissions, u32 otherpermission)
|
|-
| 0x20
| style="background: green" | Yes
| style="background: red" | No
| style="background: red" | No
| Result UnmapMemoryBlock(Handle memblock, u32 addr)
|
|-
| 0x21
| style="background: green" | Yes
| style="background: green" | Yes
| style="background: green" | Yes
| Result CreateAddressArbiter(Handle* arbiter)
|
|-
| 0x22
| style="background: green" | Yes
| style="background: green" | Yes
| style="background: green" | Yes
| Result ArbitrateAddress(Handle arbiter, u32 addr, ArbitrationType type, s32 value, s64 nanoseconds)
|
|-
| 0x23
| style="background: green" | Yes
| style="background: green" | Yes
| style="background: green" | Yes
| Result CloseHandle(Handle handle)
|
|-
| 0x24
| style="background: green" | Yes
| style="background: green" | Yes
| style="background: green" | Yes
| Result WaitSynchronization1(Handle handle, s64 nanoseconds)
|
|-
| 0x25
| style="background: green" | Yes
| style="background: green" | Yes
| style="background: green" | Yes
| Result WaitSynchronizationN(s32* out, Handle* handles, s32 handlecount, bool waitAll, s64 nanoseconds)
|
|-
| 0x26
| style="background: green" | Yes
| style="background: red" | No
| style="background: red" | No
| Result SignalAndWait(s32* out, Handle signal, Handle* handles, s32 handleCount, bool waitAll, s64 nanoseconds)
| Stubbed
|-
| 0x27
| style="background: green" | Yes
| style="background: green" | Yes
| style="background: green" | Yes
| Result DuplicateHandle(Handle* out, Handle original)
|
|-
| 0x28
| style="background: green" | Yes
| style="background: green" | Yes
| style="background: green" | Yes
| s64 GetSystemTick(void) (This returns the total CPU ticks elapsed since the CPU was powered-on)
|
|-
| 0x29
| style="background: green" | Yes
| style="background: red" | No
| style="background: red" | No
| Result GetHandleInfo(s64* out, Handle handle, HandleInfoType type)
|
|-
| 0x2A
| style="background: green" | Yes
| style="background: green" | Yes
| style="background: green" | Yes
| Result GetSystemInfo(s64* out, SystemInfoType type, s32 param)
|
|-
| 0x2B
| style="background: green" | Yes
| style="background: green" | Yes
| style="background: green" | Yes
| Result GetProcessInfo(s64* out, Handle process, ProcessInfoType type)
|
|-
| 0x2C
| style="background: green" | Yes
| style="background: green" | Yes
| style="background: green" | Yes
| Result [[Multi-threading#GetThreadInfo|GetThreadInfo]](s64* out, Handle thread, ThreadInfoType type)
|
|-
| 0x2D
| style="background: green" | Yes
| style="background: red" | No
| style="background: red" | No
| Result ConnectToPort(Handle* out, const char* portName)
|
|-
| 0x2E
| style="background: green" | Yes
| style="background: red" | No
| style="background: red" | No
| Result SendSyncRequest1(Handle session)
| Stubbed
|
|-
| 0x2F
| style="background: green" | Yes
| style="background: red" | No
| style="background: red" | No
| Result SendSyncRequest2(Handle session)
| Stubbed
|
|-
| 0x30
| style="background: green" | Yes
| style="background: red" | No
| style="background: red" | No
| Result SendSyncRequest3(Handle session)
| Stubbed
|
|-
| 0x31
| style="background: green" | Yes
| style="background: red" | No
| style="background: red" | No
| Result SendSyncRequest4(Handle session)
| Stubbed
|
|-
| 0x32
| style="background: green" | Yes
| style="background: red" | No
| style="background: red" | No
| Result SendSyncRequest(Handle session)
|
|-
| 0x33
| style="background: green" | Yes
| style="background: red" | No
| style="background: red" | No
| Result OpenProcess(Handle* process, u32 processId)
|
|-
| 0x34
| style="background: green" | Yes
| style="background: red" | No
| style="background: red" | No
| Result [[Multi-threading#OpenThread|OpenThread]](Handle* thread, Handle process, u32 threadId)
|
|-
| 0x35
| style="background: green" | Yes
| style="background: red" | No
| style="background: green" | Yes
| Result GetProcessId(u32* processId, Handle process)
|
|-
| 0x36
| style="background: green" | Yes
| style="background: red" | No
| style="background: red" | No
| Result [[Multi-threading#GetProcessIdOfThread|GetProcessIdOfThread]](u32* processId, Handle thread)
|
|-
| 0x37
| style="background: green" | Yes
| style="background: green" | Yes
| style="background: green" | Yes
| Result [[Multi-threading#GetThreadId|GetThreadId]](u32* threadId, Handle thread)
|
|-
| 0x38
| style="background: green" | Yes
| style="background: red" | No
| style="background: red" | No
| Result GetResourceLimit(Handle* resourceLimit, Handle process)
|
|-
| 0x39
| style="background: green" | Yes
| style="background: red" | No
| style="background: red" | No
| Result GetResourceLimitLimitValues(s64* values, Handle resourceLimit, LimitableResource* names, s32 nameCount)
|
|-
| 0x3A
| style="background: green" | Yes
| style="background: red" | No
| style="background: red" | No
| Result GetResourceLimitCurrentValues(s64* values, Handle resourceLimit, LimitableResource* names, s32 nameCount)
|
|-
| 0x3B
| style="background: green" | Yes
| style="background: red" | No
| style="background: red" | No
| Result [[Multi-threading#GetThreadContext|GetThreadContext]](ThreadContext* context, Handle thread)
| Stubbed
|-
| 0x3C
| style="background: green" | Yes
| style="background: green" | Yes
| style="background: green" | Yes
| Break(BreakReason)
|
|-
| 0x3D
| style="background: green" | Yes
| style="background: green" | Yes
| style="background: green" | Yes
| OutputDebugString(void const, int)
| Does nothing on non-debug units.
|-
| 0x3E
| style="background: green" | Yes
| style="background: red" | No
| style="background: red" | No
| ControlPerformanceCounter(unsigned long long, int, unsigned int, unsigned long long)
|
|- style="border-top: double"
| 0x47
| style="background: green" | Yes
| style="background: red" | No
| style="background: red" | No
| Result CreatePort(Handle* portServer, Handle* portClient, const char* name, s32 maxSessions)
| Setting name=NULL creates a private port not accessible from svcConnectToPort.
|-
| 0x48
| style="background: green" | Yes
| style="background: red" | No
| style="background: red" | No
| Result CreateSessionToPort(Handle* session, Handle port)
|
|-
| 0x49
| style="background: green" | Yes
| style="background: red" | No
| style="background: red" | No
| Result CreateSession(Handle* sessionServer, Handle* sessionClient)
|
|-
| 0x4A
| style="background: green" | Yes
| style="background: red" | No
| style="background: red" | No
| Result AcceptSession(Handle* session, Handle port)
|
|-
| 0x4B
| style="background: green" | Yes
| style="background: red" | No
| style="background: red" | No
| Result ReplyAndReceive1(s32* index, Handle* handles, s32 handleCount, Handle replyTarget)
| Stubbed.
|-
| 0x4C
| style="background: green" | Yes
| style="background: red" | No
| style="background: red" | No
| Result ReplyAndReceive2(s32* index, Handle* handles, s32 handleCount, Handle replyTarget)
| Stubbed.
|-
| 0x4D
| style="background: green" | Yes
| style="background: red" | No
| style="background: red" | No
| Result ReplyAndReceive3(s32* index, Handle* handles, s32 handleCount, Handle replyTarget)
| Stubbed.
|-
| 0x4E
| style="background: green" | Yes
| style="background: red" | No
| style="background: red" | No
| Result ReplyAndReceive4(s32* index, Handle* handles, s32 handleCount, Handle replyTarget)
| Stubbed.
|-
| 0x4F
| style="background: green" | Yes
| style="background: red" | No
| style="background: red" | No
| Result ReplyAndReceive(s32* index, Handle* handles, s32 handleCount, Handle replyTarget)
|
|-
| 0x50
| style="background: green" | Yes
| style="background: green" | Yes
| style="background: green" | Yes
| Result BindInterrupt(Interrupt name, Handle syncObject, s32 priority, bool isManualClear)
|
|-
| 0x51
| style="background: green" | Yes
| style="background: green" | Yes
| style="background: green" | Yes
| Result UnbindInterrupt(Interrupt name, Handle syncObject)
|
|-
| 0x52
| style="background: green" | Yes
| style="background: green" | Yes
| style="background: green" | Yes
| Result InvalidateProcessDataCache(Handle process, void* addr, u32 size)
|
|-
| 0x53
| style="background: green" | Yes
| style="background: green" | Yes
| style="background: green" | Yes
| Result StoreProcessDataCache(Handle process, void const* addr, u32 size)
|
|-
| 0x54
| style="background: green" | Yes
| style="background: green" | Yes
| style="background: green" | Yes
| Result FlushProcessDataCache(Handle process, void const* addr, u32 size)
|
|-
| 0x55
| style="background: green" | Yes
| style="background: green" | Yes
| style="background: green" | Yes
| Result StartInterProcessDma(Handle* dma, Handle dstProcess, void* dst, Handle srcProcess, const void* src, u32 size, const DmaConfig& config)
|
|-
| 0x56
| style="background: green" | Yes
| style="background: green" | Yes
| style="background: green" | Yes
| Result StopDma(Handle dma)
|
|-
| 0x57
| style="background: green" | Yes
| style="background: green" | Yes
| style="background: green" | Yes
| Result GetDmaState(DmaState* state, Handle dma)
|
|-
| 0x58
| style="background: green" | Yes
| style="background: green" | Yes
| style="background: green" | Yes
| RestartDma(nn::Handle, void *, void const*, unsigned int, signed char)
|
|- style="border-top: double"
| 0x60
| style="background: green" | Yes
| style="background: red" | No
| style="background: red" | No
| Result DebugActiveProcess(Handle* debug, u32 processID)
|
|-
| 0x61
| style="background: green" | Yes
| style="background: red" | No
| style="background: red" | No
| Result BreakDebugProcess(Handle debug)
|
|-
| 0x62
| style="background: green" | Yes
| style="background: red" | No
| style="background: red" | No
| Result TerminateDebugProcess(Handle debug)
|
|-
| 0x63
| style="background: green" | Yes
| style="background: red" | No
| style="background: red" | No
| Result GetProcessDebugEvent(DebugEventInfo* info, Handle debug)
|
|-
| 0x64
| style="background: green" | Yes
| style="background: red" | No
| style="background: red" | No
| Result ContinueDebugEvent(Handle debug, u32 flags)
|
|-
| 0x65
| style="background: green" | Yes
| style="background: red" | No
| style="background: red" | No
| Result GetProcessList(s32* processCount, u32* processIds, s32 processIdMaxCount)
|
|-
| 0x66
| style="background: green" | Yes
| style="background: red" | No
| style="background: red" | No
| Result GetThreadList(s32* threadCount, u32* threadIds, s32 threadIdMaxCount, Handle domain)
|
|-
| 0x67
| style="background: green" | Yes
| style="background: red" | No
| style="background: red" | No
| Result GetDebugThreadContext(ThreadContext* context, Handle debug, u32 threadId, u32 controlFlags)
|
|-
| 0x68
| style="background: green" | Yes
| style="background: red" | No
| style="background: red" | No
| Result SetDebugThreadContext(Handle debug, u32 threadId, ThreadContext* context, u32 controlFlags)
|
|-
| 0x69
| style="background: green" | Yes
| style="background: red" | No
| style="background: red" | No
| Result QueryDebugProcessMemory(MemoryInfo* blockInfo, PageInfo* pageInfo, Handle process, u32 addr)
|
|-
| 0x6A
| style="background: green" | Yes
| style="background: red" | No
| style="background: red" | No
| Result ReadProcessMemory(void* buffer, Handle debug, u32 addr, u32 size)
|
|-
| 0x6B
| style="background: green" | Yes
| style="background: red" | No
| style="background: red" | No
| Result WriteProcessMemory(Handle debug, void const* buffer, u32 addr, u32 size)
|
|-
| 0x6C
| style="background: green" | Yes
| style="background: red" | No
| style="background: red" | No
| Result SetHardwareBreakPoint(s32 registerId, u32 control, u32 value)
|
|-
| 0x6D
| style="background: green" | Yes
| style="background: red" | No
| style="background: red" | No
| [[Multi-threading#GetDebugThreadParam|GetDebugThreadParam]](long long *, int *, nn::Handle, unsigned int, nn::dmnt::DebugThreadParam)
| Disabled on regular kernel.
|- style="border-top: double"
| 0x70
| style="background: green" | Yes
| style="background: red" | No
| style="background: red" | No
| Result ControlProcessMemory(Handle KProcess, unsigned int Addr0, unsigned int Addr1, unsigned int Size, unsigned int Type, unsigned int Permissions)
|
|-
| 0x71
| style="background: green" | Yes
| style="background: red" | No
| style="background: red" | No
| Result MapProcessMemory(Handle KProcess, unsigned int StartAddr, unsigned int EndAddr)
|
|-
| 0x72
| style="background: green" | Yes
| style="background: red" | No
| style="background: red" | No
| Result UnmapProcessMemory(Handle KProcess, unsigned int StartAddr, unsigned int EndAddr)
|
|-
| 0x73
| style="background: green" | Yes
| style="background: red" | No
| style="background: red" | No
| Result CreateCodeSet(Handle* handle_out, struct CodeSetInfo, u32 code_ptr, u32 ro_ptr, u32 data_ptr)
|
|-
| 0x74
| style="background: green" | Yes
| style="background: red" | No
| style="background: red" | No
| Result RandomStub()
| Stubbed
|-
| 0x75
| style="background: green" | Yes
| style="background: red" | No
| style="background: red" | No
| Result CreateProcess(Handle* handle_out, Handle codeset_handle, u32 arm11kernelcaps_ptr, u32 arm11kernelcaps_num)
|
|-
| 0x76
| style="background: green" | Yes
| style="background: red" | No
| style="background: red" | No
| TerminateProcess(Handle)
|
|-
| 0x77
| style="background: green" | Yes
| style="background: red" | No
| style="background: red" | No
| Result SetProcessResourceLimits(Handle KProcess, Handle KResourceLimit)
|
|-
| 0x78
| style="background: green" | Yes
| style="background: red" | No
| style="background: red" | No
| Result CreateResourceLimit(Handle *KResourceLimit)
|
|-
| 0x79
| style="background: green" | Yes
| style="background: red" | No
| style="background: red" | No
| Result SetResourceLimitValues(Handle res_limit, LimitableResource* resource_type_list, s64* resource_list, u32 count)
|
|-
| 0x7A
| style="background: green" | Yes
| style="background: red" | No
| style="background: green" | Yes
| AddCodeSegment (unsigned int Addr, unsigned int Size)
| Stubbed on NATIVE_FIRM beginning with [[2.0.0-2]]. Used during TWL_FIRM boot.
|-
| 0x7B
| style="background: green" | Yes
| style="background: green" | Yes
| style="background: red" | No
| Backdoor(unsigned int CodeAddress)
| This is used on ARM9 NATIVE_FIRM. No ARM11 processes have access to it without some form of kernelhax.
|-
| 0x7C
| style="background: green" | Yes
| style="background: green" | Yes
| style="background: green" | Yes
| KernelSetState(unsigned int Type, unsigned int Param0, unsigned int Param1, unsigned int Param2)
| The type determines the meaning of each param
|-
| 0x7D
| style="background: green" | Yes
| style="background: red" | No
| style="background: red" | No
| Result QueryProcessMemory(MemInfo *Info, unsigned int *Out, Handle KProcess, unsigned int Addr)
|
|- style="border-top: double"
| 0xFF
| style="background: green" | Yes
| style="background: green" | Yes
| style="background: green" | Yes
| ???
| Debug related? The svcaccesscontrol mask doesn't apply for this SVC. Stubbed on ARM9 NATIVE_FIRM.
|}
NF: NATIVE_FIRM. TF: TWL_FIRM.

Note that "stubbed" here means that the SVC only returns an error, as in the following snippet:

<pre>ROM:FFF04D98 LDR R0, =0xF8C007F4
ROM:FFF04D9C BX LR</pre>
= Types and structures =

== enum MemoryState ==
{| class="wikitable" border="1"
! Memory state flags
! Value
|-
| FREE
| 0
|-
| RESERVED
| 1
|-
| IO
| 2
|-
| STATIC
| 3
|-
| CODE
| 4
|-
| PRIVATE
| 5
|-
| SHARED
| 6
|-
| CONTINUOUS
| 7
|-
| ALIASED
| 8
|-
| ALIAS
| 9
|-
| ALIAS CODE
| 10
|-
| LOCKED
| 11
|}

== enum PageFlags ==
{| class="wikitable" border="1"
! Page flags
! Bit
|-
| LOCKED
| 0
|-
| CHANGED
| 1
|}

== enum MemoryOperation ==

{| class="wikitable" border="1"
! Memory operation
! Id
|-
| FREE
| 1
|-
| RESERVE
| 2
|-
| COMMIT
| 3
|-
| MAP
| 4
|-
| UNMAP
| 5
|-
| PROTECT
| 6
|-
| REGION APP
| 0x100
|-
| REGION SYSTEM
| 0x200
|-
| REGION BASE
| 0x300
|-
| LINEAR
| 0x10000
|}

The LINEAR memory-operation indicates that the mapped physical address is always MappedVAddr+0x0C000000, thus this memory can be used for hardware devices' DMA(such as the [[GPU]]). Addr0+size for this must be within the 0x14000000-0x1C000000 range when Addr0 is non-zero(Addr1 must be zero), Addr0 isn't actually used by svcControlMemory for mapping memory: Addr0 is not used by the kernel after doing address-range checks. The kernel determines what physical-address to use by allocating memory from FCRAM(about the same way as other memory), which is then used to determine the virtual-address.

[[8.0.0-18]] added a new memory mapping(0x30000000-0x38000000) for LINEAR memory, this replaces the original mapping for newer titles. The kernel uses the new mapping when the process memory-region is BASE, or when the process kernel-release-version field is >=0x022c(2.44 / system-version [[8.0.0-18]]).

The input mem-region value for svcControlMemory is only used(when non-zero) when the PID is value 1, for the [[FIRM]] ARM11 "loader" module.

== enum MemoryPermission ==

{| class="wikitable" border="1"
! Memory permission
! Id
|-
| NONE
| 0
|-
| R
| 1
|-
| W
| 2
|-
| RW
| 3
|-
| X
| 4
|-
| RX
| 5
|-
| WX
| 6
|-
| RWX
| 7
|-
| DONTCARE
| 0x10000000
|}

== enum ResetType ==

{| class="wikitable" border="1"
! Reset type
! Id
|-
| ONESHOT
| 0
|-
| STICKY
| 1
|-
| PULSE
| 2
|}

== struct MemoryInfo ==
{| class="wikitable" border="1"
! Type
! Field
|-
| u32
| Base process virtual address
|-
| u32
| Size
|-
| u32
| Permission
|-
| enum MemoryState
| State
|}

== struct PageInfo ==
{| class="wikitable" border="1"
! Type
! Field
|-
| u32
| Flags
|}

== struct StartupInfo ==
{| class="wikitable" border="1"
! Type
! Field
|-
| s32
| Priority
|-
| u32
| Stack size
|-
| s32
| argc
|-
| s16*
| argv
|-
| s16*
| envp
|}

== enum ArbitrationType ==
{| class="wikitable" border="1"
! Address arbitration type
! Value
|-
| FREE
| 0
|-
| AQUIRE
| 1
|-
| KERNEL2
| 2
|-
| AQUIRE_TIMEOUT
| 3
|-
| KERNEL4
| 4
|}

== enum BreakReason ==
{| class="wikitable" border="1"
! Break Reason
! Value
|-
| PANIC
| 0
|-
| ASSERT
| 1
|-
| USER
| 2
|}

== struct CodeSetInfo ==
All addresses are given virtual for the process to be created.
All sizes are given in 0x1000-pages.

{| class="wikitable" border="1"
! Type
! Field
|-
| u8[8]
| Codeset Name
|-
| u16
| Unknown, this is written to field 0x5A of KCodeSet
|-
| u16
| Unknown/padding
|-
| u32
| Unknown/padding
|-
| u32
| .text addr
|-
| u32
| .text size
|-
| u32
| .rodata start
|-
| u32
| .rodata size
|-
| u32
| RW addr (.data + .bss)
|-
| u32
| RW size (.data + .bss)
|-
| u32
| Total .text pages
|-
| u32
| Total .rodata pages
|-
| u32
| Total RW pages (.data + .bss)
|-
| u32
| Unknown/padding
|-
| u8[8]
| Program ID
|}

== struct DebugEventInfo ==

{| class="wikitable" border="1"
! Type
! Field
|-
| u32
| Event type
|-
| u32
| Thread ID (not used in all events)
|-
| u32[2]
| Unknown/padding
|-
| u32[6]
| Event-specific data (see below)
|}

{| class="wikitable" border="1"
! Event type
! Id
|-
| PROCESS
| 0
|-
| CREATE THREAD
| 1
|-
| EXIT THREAD
| 2
|-
| EXIT PROCESS
| 3
|-
| EXCEPTION
| 4
|-
| DLL LOAD
| 5
|-
| DLL UNLOAD
| 6
|-
| SCHEDULE IN
| 7
|-
| SCHEDULE OUT
| 8
|-
| SYSCALL IN
| 9
|-
| SYSCALL OUT
| 10
|-
| OUTPUT STRING
| 11
|-
| MAP
| 12
|}

=== PROCESS event ===

{| class="wikitable" border="1"
! Type
! Field
|-
| u64
| Program ID
|-
| char[8]
| Process name
|-
| u32
| Process ID
|-
| u32
| 0 = newly created process, 1 = attached process
|}

=== CREATE THREAD event ===

{| class="wikitable" border="1"
! Type
! Field
|-
| u32
| Creator thread ID
|-
| u32
| Base address (?)
|-
| u32
| Entrypoint
|}

=== EXIT THREAD/PROCESS events ===

A single u32 reason field is used.

Thread exit reasons:
{| class="wikitable" border="1"
! Reason
! Id
|-
| (None)
| 0
|-
| TERMINATE
| 1
|-
| EXIT PROCESS
| 2
|-
| TERMINATE PROCESS
| 3
|}

Process exit reasons:
{| class="wikitable" border="1"
! Reason
! Id
|-
| (None)
| 0
|-
| TERMINATE
| 1
|-
| UNHANDLED EXCEPTION
| 2
|}

=== EXCEPTION event ===

{| class="wikitable" border="1"
! Type
! Field
|-
| u32
| Exception type
|-
| u32
| Exception address
|-
| u32
| Argument (type-specific)
|}

Exception types:
{| class="wikitable" border="1"
! Reason
! Id
! Argument
|-
| UNDEFINED INSTRUCTION
| 0
| (None)
|-
| (Unknown)
| 1
| (None)
|-
| (Unknown, mem-related)
| 2
| Address
|-
| (Unknown, mem-related)
| 3
| Address
|-
| ATTACH BREAK
| 4
| (None)
|-
| BREAKPOINT
| 5
| (None)
|-
| USER BREAK
| 6
| User break type
|-
| DEBUGGER BREAK
| 7
| (None)
|-
| UNDEFINED SYSCALL
| 8
| Attempted syscall ID
|}

User break types:
{| class="wikitable" border="1"
! Reason
! Id
|-
| PANIC
| 0
|-
| ASSERT
| 1
|-
| USER
| 2
|}

=== SCHEDULER/SYSCALL IN/OUT events ===

{| class="wikitable" border="1"
! Type
! Field
|-
| u64
| Clock tick
|-
| u32
| Syscall (only for SYSCALL events)
|}

=== OUTPUT STRING event ===

{| class="wikitable" border="1"
! Type
! Field
|-
| u32
| String address
|-
| u32
| String size
|}

=== MAP event ===

{| class="wikitable" border="1"
! Type
! Field
|-
| u32
| Mapped address
|-
| u32
| Mapped size
|-
| u32
| MemoryPermission
|-
| u32
| MemoryState
|}

=svcSetHardwareBreakPoint=
This is essentially an interface for writing values to the debug-unit (B/W)RP registers. registerId range 0..5 = breakpoints(BRP0-5), 0x100..0x101 = watchpoints(WRP0-1), anything outside of these ranges will result in an error. This is used for both adding and removing/disabling breakpoints/watchpoints, hence the raw control value parameter.

Here the kernel sets bit15 in the DSCR, to enable monitor-mode debugging.

Regardless of whether this is for a BRP, when bit21 is set in the control input parameter(BRP type = contextID), the kernel will load the target process [[KProcess|contextID]] and use that internally for the value field. The target process is specified via a [[KDebug]] handle passed as the "value" parameter.

Lastly, the kernel disables the specified (B/W)RP, then writes the value parameter / loaded contextID to the (B/W)VR, then writes the input control value to the (B/W)CR.

= Processes =
Each process can only use SVCs which are enabled in the [[NCCH#CXI|exheader]] for this process. The ARM11 kernel SVC handler checks whether the SVC is enabled in the syscall access control mask stored on the SVC-mode stack, when the SVC isn't enabled a kernelpanic() is triggered. Each process has a separate SVC-mode stack, this stack and the syscall access mask stored here is initialized when the process is started. Applications normally only have access to SVCs <=0x3D, however not all SVCs <=0x3D are accessible to the application. The majority of the SVCs accessible to applications are unused by the application.

Each process has a separate handle-table, the size of this table is stored in the exheader. The handles in a handle-table can't be used in the context of other processes, since those handles don't exist in other handle-tables.

0xFFFF8001 is a handle alias for the current KProcess, and 0xFFFF8000 is a handle alias for the current KThread.

Calling svcBreak on retail will only terminate the process which called this SVC.

= Threads =
For svcCreateThread the input address used for Entrypoint_Param and StackTop are normally the same, however these can be arbitrary. For the main thread the Entrypoint_Param is value 0.

Using CloseHandle() with a KThread handle will terminate the specified thread, only if the reference count reaches 0.

Lower priority values give the thread higher priority. For userland apps, priorities between 0x18 and 0x3F are allowed. The priority of the app's main thread seems to be 0x30.

The thread scheduler is cooperative, therefore if a thread takes up all the CPU time (for example if it enters an endless loop), all the other threads that run on the same CPU core won't get a chance to run. The main way of yielding another thread is using an address arbiter.

= Memory Mapping =
ControlMemory and MapMemoryBlock can be used to map memory pages, these two SVCs only support mapping execute-never R/W pages. The input permissions parameter for these SVCs must therefore be <=3, where value zero is used when un-mapping memory. Furthermore it appears that only regular heap pages can be mirrored (it won't work for TLS, stack, .data, .text, for example).

Bitmask 0xF00 for ControlMemory parameter MemoryType is the memory-type, when this is zero the memory-type is loaded from the kernel flags stored in the exheader ARM11 kernel descriptors, for the process using the SVC.

ControlMemory parameter MemoryType with value 0x10003 is used for mapping the GSP [[Memory_layout|heap]]. The low 8-bits are the type: 1 is for un-mapping memory, 3 for mapping memory. Type4 is used to mirror the RW memory at Addr1, to Addr0. Type4 will return an error if Addr1 is located in read-only memory. Addr1 is not used for type1 and type3.

The ARM11 kernel does not allow processes to create shared memory blocks via svcCreateMemoryBlock, when the process memorytype(from the kernel flags stored in the exheader kernel descriptor) is the application memorytype, and when addr=0. It's unknown how the kernel handles addr=0 when the memorytype is not the application memorytype. When addr is non-zero, it must be located in memory which is already mapped. Furthermore, it appears that only regular heap pages (allocated using svcControlMemory op=COMMIT) are accepted as valid addrs.

ControlProcessMemory maps memory in the specified process, this is the only SVC which allows mapping executable memory. Format of the permissions field for memory mapping SVCs: bit0=R, bit1=W, bit2=X. Type6 sets the Addr0 memory permissions to the input permissions, for already mapped memory. Type is the MemoryOperation enum, without the memory-type/memory-region. ControlProcessMemory only supports type4, type5, and type6. ControlProcessMemory does not support using the current KProcess handle alias.

MapProcessMemory maps RW memory starting at address 0x00100000 in the specified KProcess, at the specified StartAddr in the current process. MapProcessMemory then maps 0x08000000 in the specified process, to StartAddr+0x7f00000 in the current process. UnmapProcessMemory unmaps the memory which was mapped by MapProcessMemory.

Note that with the MAP MemoryOperation, the kernel will refuse to MAP memory for the specified addr1, when addr1 was already used with another MAP operation as addr1. The kernel also doesn't allow memory to be freed via the FREE MemoryOperation, when other virtual-memory is mapped to this same memory(when the MAP MemoryOperation was used with this memory with addr1).

= [[DMA]] =
The CTRSDK code for using svcStartInterProcessDma will execute svcBreak when svcStartInterProcessDma returns an error(except for certain error value(s)). Therefore on retail, triggering a svcStartInterProcessDma via a system-module which results in an error from svcStartInterProcessDma will result in the system-module terminating.

= Debugging =
DebugActiveProcess is used to attach to a process for debugging. This SVC can only be used when the target process' ARM11 descriptors stored in the exheader have the kernel flag for "Enable debug" set. Otherwise when that flag is clear, the kernel flags for the process using this SVC must have the "Force debug" flag set.

= KernelSetState =
{| class="wikitable" border="1"
|-
! Type
! Enabled for the NATIVE_FIRM ARM11 kernel
! Enabled for the TWL_FIRM ARM11 kernel
! Description
|-
| 0
| Yes
| No
| This initializes the programID for launching [[FIRM]], then triggers launching [[FIRM]]. Param0 is unused. Param1 is the programID-low, and the programID-high is 0x00040138. Param2 is used only with the [[New_3DS]] kernel, pm-module uses value 0 with this. With New3DS kernel, it forces the programIDlow to be the New3DS NATIVE_FIRM, when the input programIDlow is for the Old3DS NATIVE_FIRM and Param2==0.
|-
| 1
| Yes
| Yes
| Unknown, does nothing with the TWL_FIRM ARM11 kernel.
|-
| 2
| Yes
| Yes
| ?
|-
| 3
| Yes
| No
| This used for initializing the 0x1000-byte buffer used by the launched [[FIRM]]. Param2 is unused. When Param0 is value 1, this buffer is copied to the beginning of FCRAM at 0xF0000000, and Param1 is unused. When Param0 is value 0, this kernel buffer is mapped to process address Param1.
|-
| 4
| No
| Yes
| Param0-Param3 are unused. This unmaps(?) the following virtual memory by writing value physaddr(where physaddr base is 0x80000000) to the L1 MMU table entries: 0x00300000..0x04300000, 0x08000000..0x0FE00000, and 0x10000000..0xF8000000.
|-
| 5
| Yes
| Yes
| ?
|-
| 6
| Yes
| No
| Debug related?
|-
| 7
| Yes
| No
| This triggers an MCU (hard) reboot. Param0-3 are unused. This reboot is triggered via device address 0x4A on the second [[I2C]] bus (the MCU). Register address 0x20 is written to with value 4. This code will not return.
|-
| 8
| Yes
| No
| Alternate unused FIRM launch code-path, with different [[PXI]] FIFO word constants.
|-
| 9
| Yes, implemented at some point after system-version v4.5.
| ?
| Unknown
|-
| 10
| Yes
| ?
| Only available for the [[New_3DS]] kernel. It's unknown what this is used for.
|}

= GetSystemInfo =
{| class="wikitable" border="1"
! SystemInfoType value
! s32 param
! Description
|-
| 0
| 0
| This writes the total used memory size in the following memory regions to out: APPLICATION, SYSTEM, and BASE.
|-
| 0
| 1
| This writes the total used memory size in the APPLICATION memory region to out.
|-
| 0
| 2
| This writes the total used memory size in the SYSTEM memory region to out.
|-
| 0
| 3
| This writes the total used memory size in the BASE memory region to out.
|-
| 25
| Unused
| This writes the total number of threads which were directly launched by the kernel, to out.
|-
| 26
| Unused
| This writes the total number of processes which were directly launched by the kernel, to out. For the NATIVE_FIRM/SAFE_MODE_FIRM ARM11 kernel, this is normally 5, for processes sm, fs, pm, loader, and pxi.
|}

= GetProcessInfo =
Input:
R0 = unused
R1 = Handle process
R2 = ProcessInfoType type

Output:
R0 = Result
R1 = output value lower word
R2 = output value upper word

{| class="wikitable" border="1"
! ProcessInfoType value
! Available since system version
! Description
|-
| 9-19
| [[8.0.0-18]]
| This only returns error 0xD8E007ED.
|-
| 20
| [[8.0.0-18]]
| low u32 = (0x20000000 - <LINEAR virtual-memory base for this process>). That is, the output value is the value which can be added to LINEAR memory vaddrs for converting to physical-memory addrs.
|-
| 21-23
| [[8.0.0-18]]
| This only returns error 0xE0E01BF4.
|}

= GetHandleInfo =
{| class="wikitable" border="1"
! HandleInfoType value
! Description
|-
| 0
| This writes back two (unknown) u32 fields from the KProcess object. If not a KProcess handle is given, it will write whatever was in r5, r7 when the svc was called.
|-
| 1
| Get internal refcount-1 for kernel object (u32), and also a boolean if the refcount-1 is negative (u32).
|-
| 0x32107
| Returns (u64) 0.
|}

= svc7B Backdoor =
This saves SVC-mode SP+LR on the user-mode stack, then sets the SVC-mode SP to the user-mode SP. This then calls the specified code in SVC-mode. Once the called code returns, this pops the saved SP+LR off the stack for restoring the SVC-mode SP, then returns from the svc7b handler. Note that this svc7b handler does not disable IRQs, if any IRQs/context-switches occur while the SVC-mode SP is set to the user-mode one here, the ARM11-kernel will crash(which hangs the whole ARM11-side system).

= Kernel error-codes =
See [[Error codes]].

{| class="wikitable" border="1"
! Error-code value
! Description
|-
| 0x09401BFE
| Timeout occurred with svcWaitSynchronization*, when timeout is not ~0.
|-
| 0xC8601801
| No more unused/free synchronization objects left to use in a given object's linked list. (KEvent, KMutex, KTimer, KSemaphore, KAddressArbiter, KThread)
|-
| 0xC8601802
| No more unused/free KSharedMemory objects left to use in the KSharedMemory linked list - out of blocks
|-
| 0xC8601809
| No more unused/free KSessions left to use in the KSession linked list - out of sessions
|-
| 0xC860180A
| Not enough free memory available for memory allocation.
|-
| 0xC920181A
| The session was closed by the other process..
|-
| 0xD0401834
| Max connections to port have been exceeded
|-
| 0xD88007FA
| Returned if no KObjectName object in the linked list of such objects matches the port name provided to the svc.
|-
| 0xD8E007ED
| This indicates that a value is outside of the enum being used.
|-
| 0xD8E007F1
| This error indicates Misaligned address.
|-
| 0xD8E007F7
| This error indicates that the input handle used with the SVC does not exist in the process handle-table, or that the handle kernel object type does not match the type used by the SVC.
|-
| 0xD9000402
| Invalid memory permissions for input/output buffers, for svcStartInterProcessDma.
|-
| 0xD9001814
| Failed unprivileged load or store - wrong permissions on memory
|-
| 0xD9001BF7
| This error is returned when the kernel retrieves a pointer to a kernel object, but the object type doesn't match the desired one.
|-
| 0xD92007EA
| This error is returned when a process attempts to use svcCreateMemoryBlock when the process memorytype is the application memorytype, and when addr=0.
|-
| 0xE0E01BF5
| This indicates an invalid address was used.
|-
| 0xF8C007F4
| Invalid type/param0-param3 input for svcKernelSetState. This is also returned for those syscalls marked as stubs.
|}

FIRM

2015-08-08T18:16:16Z

WulfyStylez: /* FIRM Launch Parameters */

This page describes the file format for the [[Title list#00040138 - System Firmware|3DS' Firmware]], it contains four 'sections' of ARM code (ARM9 and ARM11). The firmware sections are not encrypted in the FIRM format.

The ARM9 section contains the ARM9 kernel and the ARM9 process(exheader process name is "Process9"). The ARM11 section(s) contains the ARM11 kernel, and the ARM11 process(es). For NATIVE_FIRM/SAFE_MODE_FIRM these ARM11 processes are sm, fs, pm, loader, and pxi. Normally the 4th section is not used. The code loaded from FIRM is constantly running on the system until another FIRM is launched. The ARM11 kernel is hard-coded to always decompress the FIRM ARM11 modules ExeFS .code, the exheader compression bit is not checked.

== FIRM Header ==
{| class="wikitable" border="1"
|-
! OFFSET
! SIZE
! DESCRIPTION
|-
| 0x000
| 4
| Magic 'FIRM'
|-
| 0x004
| 4
| Reserved1
|-
| 0x008
| 4
| ARM11 Entrypoint
|-
| 0x00C
| 4
| ARM9 Entrypoint
|-
| 0x010
| 0x030
| Reserved2
|-
| 0x040
| 0x0C0 (0x030*4)
| Firmware Section Headers
|-
| 0x100
| 0x100
| RSA-2048 signature of the FIRM header, using SHA-256. This is only checked when bootrom/Process9 is doing FIRM-launch, not when installing FIRM to the NAND firm0/firm1 partitions.
|}

== Firmware Section Headers ==

{| class="wikitable" border="1"
|-
! OFFSET
! SIZE
! DESCRIPTION
|-
| 0x000
| 4
| Offset
|-
| 0x004
| 4
| Address
|-
| 0x008
| 4
| Size
|-
| 0x00C
| 4
| Firmware Type ('0'=ARM9/'1'=ARM11) Process9 doesn't use this field at all.
|-
| 0x010
| 0x020
| SHA-256 Hash of Firmware Section
|}

== [[New_3DS]] FIRM ==
For New3DS firmwares (NATIVE_FIRM, TWL_FIRM, ..), the ARM9 FIRM binary has an additional layer of crypto. At the end of each ARM9 binary, there's a plaintext loader. The format of the FIRM header is identical to regular 3DS FIRM(the RSA modulo is the same as regular 3DS too).

Before checking 0x10000000 the loader main() does the following:
* On [[9.5.0-22|9.5.0-X]]: executes a nop instruction with r0=0 and r1=<address of arm9binhdr+0x50>.
* Clears bit6 in [[AES_Registers|REG_AESKEYCNT]].

If (u8*)0x10000000 bit 1 is clear (which means that this happens only on hard reboots), it does the following things:
* Clears 0x200-bytes on the stack, then reads [[Flash_Filesystem|NAND]] sector 0x96(NAND image offset 0x12C00), with size 0x200-bytes into that stack buffer.
* Checks u8 0x10000000 bit1 again, if it's set then it executes a panic function(set r0-r2=0, execute nop instruction, then execute instruction "bkpt 0x99"). Hashes data from the region [[IO_Registers|0x10012000-0x10012090]] using SHA256 via the [[SHA_Registers|SHA]] hardware.
* Clears bit6 in [[AES_Registers|REG_AESKEYCNT]]. Initializes AES keyslot 0x11 keyX, keyY to the lower and higher portion of the above hash, respectively. Due to the above hashed data, the keyX+keyY here are console-unique.
* Decrypts the first 0x10-byte block in the above read NAND sector with keyslot 0x11 using AES-ECB. [[9.6.0-24|9.6.0-X]]: Then it decrypts the 0x10-bytes at offset 0x10 in the sector with keyslot 0x11.
* Then the normalkey, keyX, and keyY, for keyslot 0x11 are cleared to zero. Runs the TWL key-init/etc code which was originally in the ARM9-kernel, then writes 0x2 to [[CONFIG_Registers|REG_SYSPROT9]].
* Then it uses the above decrypted block from sector+0 to set the normalkey for keyslot 0x11. Decrypts arm9_bin_buf+0 using keyslot 0x11 with AES-ECB, and initialises keyX for keyslot 0x15 with it.
* [[9.6.0-24|9.6.0-X]]: Then it uses the above decrypted block from sector+0 to set the normalkey for keyslot 0x11. Decrypts a 0x10-byte block from arm9loader .(ro)data using keyslot 0x11 with AES-ECB, and initializes keyX for keyslot 0x18 with it(same block as previous versions).
* [[9.6.0-24|9.6.0-X]]: Starting with this version keyslot 0x16 keyX init was moved here, see below for details on this. The code for this is same as [[9.5.0-22|9.5.0-X]], except the decrypted normalkey from sector+0x10 is used for keyslot 0x11 instead.
* Initialises KeyX for keyslots 0x18..0x1F(0x19..0x1F with [[9.6.0-24|9.6.0-X]]) with the output of decrypting a 0x10-byte block with AES-ECB using keyslot 0x11. This block was changed to a new one separate from keyslot 0x18, starting with [[9.6.0-24|9.6.0-X]]. The last byte in this 0x10-byte input block is increased by 0x01 after initializing each keyslot. Before doing the crypto each time, the loader sets the normal-key for keyslot 0x11 to the plaintext normalkey from sector+0(+0x10 with [[9.6.0-24|9.6.0-X]]). These are New3DS-specific keys.
* [[9.5.0-22|9.5.0-X]](moved to above with [[9.6.0-24|9.6.0-X]]): Sets the normal-key for keyslot 0x11 to the same one already decrypted on the stack. Decrypts the 0x10-byte block at arm9binhdr+0x60 with AES-ECB using keyslot 0x11, then sets the keyX for keyslot 0x16 to the output data.
* [[9.5.0-22|9.5.0-X]]: The normalkey, keyX, and keyY, for keyslot 0x11 are then cleared to zero.

When (u8*)0x10000000 bit 1 is set(which means this happens only when this loader runs again for firm-launch), the normalkey, keyX, and keyY, for keyslot 0x11 are cleared to zero.

It sets KeyY for keyslot 0x15(0x16 with [[9.5.0-22|9.5.0-X]]) to arm9_bin_buf+16, the CTR to arm9_bin_buf+32 (both are unique for every version). It then proceeds to decrypt the binary with AES-CTR. When done, it sets the normal-key for the keyslot used for binary decryption to zeros. It then decrypts arm9_bin_buf+64 using an hardcoded keyY for keyslot 0x15([[9.5.0-22|9.5.0-X]]/[[9.6.0-24|9.6.0-X]] also uses keyslot 0x15), sets the normal-key for this keyslot to zeros again, then makes sure the output block is all zeroes. If it is, it does some cleanup then it jumps to the entrypoint for the decrypted binary. Otherwise it will clear the keyX, keyY, and normal-key for each of the keyslots initialized by this loader (on [[9.6.0-24|9.6.0-X]]+, on older versions this was bugged and cleared keys 0x00..0x07 instead of 0x18..0x1F), do cleanup(same cleanup as when the decrypted block is all-zero) then just loop forever.

Thus, the ARM9 binary has the following header:
{| class="wikitable" border="1"
|-
! OFFSET
! SIZE
! DESCRIPTION
|-
| 0x000
| 16
| Encrypted KeyX (same for all FIRM's)
|-
| 0x010
| 16
| KeyY
|-
| 0x020
| 16
| CTR
|-
| 0x030
| 8
| Size of encrypted binary, as ASCII text?
|-
| 0x038
| 8
| ?
|-
| 0x040
| 16
| Control block
|-
| 0x050
| 16
| Added with [[9.5.0-22|9.5.0-X]]. Only used for hardware debugging: a nop instruction is executed with r0=0 and r1=<address of this data>.
|-
| 0x060
| 16
| Added with [[9.5.0-22|9.5.0-X]]. Encrypted keyX for keyslot 0x16.
|}

Originally the padding after the header before offset 0x800(start of actual ARM9-binary) was 0xFF bytes, with [[9.5.0-22|9.5.0-X]] this was changed to 0x0.

For the New3DS NATIVE_FIRM arm9-section header, the only difference between the [[8.1.0-0_New3DS]] version and the [[9.0.0-20]] version is that the keyY, CTR, and the block at 0x30 in the header were updated.

===New3DS ARM9 binary loader versions===
{| class="wikitable" border="1"
|-
! FIRM system version(s)
! Description
|-
| [[8.1.0-0_New3DS]] - [[9.3.0-21|9.3.0-X]]
| Initial version.
|-
| [[9.5.0-22|9.5.0-X]]
| Added keyX initialization for keyslot 0x16(see above), and added code for clearing keyslot 0x11 immediately after the code finishes using keyslot 0x11. The keyslot used for arm9bin decryption was changed from 0x15 to 0x16. Added code for clearing keyslot 0x16 when control-block decryption fails. Added code for using arm9bin_hdr+0x50 with a nop instruction, at the very beginning of the main arm9-loader function. Added two new 0x10-blocks to the arm9bin-hdr.
|-
| [[9.6.0-24|9.6.0-X]]
| See above and [[9.6.0-24|here]].
|}

===New3DS ARM9 kernel===
The only actual code-difference for the Old3DS/New3DS ARM9-kernels' crt0, besides TWL AES / [[IO_Registers|0x10012000]] related code, is that the New3DS ARM9-kernel writes 0x1 to [[CONFIG_Registers|REG_EXTMEMCNT9]] in the crt0.

===New3DS Process9===
The following is all of the differences for Old3DS/New3DS Process9 with [[9.3.0-21|9.3.0-X]]:
* The FIRM-launch code called at the end of the New3DS proc9 main() has different mem-range checks.
* In the New3DS proc9, the v6.0/v7.0 keyinit function at the very beginning(before the original code) had additional code added for setting [[Flash_Filesystem|CTRNAND]] [[AES_Registers|keyslot]] 0x5, with keydata from .data. After setting the keyY, the keyY in .data is cleared.
* In New3DS proc9, the functions for getting the gamecard crypto keyslots / NCCH keyslot can return New3DS keyslots when New3DS flags(NCSD/NCCH) are set.
* The code/data for the binary near the end of arm9mem is slightly different, because of memory-region sizes.
* The only difference in .data(besides the above code binary) is that the New3DS proc9 has an additional 0x10-byte block for the keyslot 0x5 keyY, see above.

== NATIVE_FIRM and SAFE_MODE_FIRM ==
NATIVE_FIRM is the FIRM which is installed to the [[Flash_Filesystem|NAND]] firm partitions, which is loaded by bootrom. SAFE_MODE_FIRM and NATIVE_FIRM for the initial versions are exactly the same, except for the system core version fields. SAFE_MODE is used for running the [[System_Settings#System_Updater|System Updater]].

An overview of NATIVE_FIRM versions along with their contentID is given in [[Configuration_Memory#NATIVE_FIRM_Versions|Configuration Memory]].

== TWL_FIRM and AGB_FIRM ==
TWL_FIRM handles DS(i) backwards compatibility, while AGB_FIRM handles running GBA VC titles. The ARM9 FIRM section for TWL_FIRM and AGB_FIRM are exactly the same(for TWL_FIRM and AGB_FIRM versions which were updated with the same system-update).

=== TWL_FIRM ===
The 3DS-mode ARM9 core seems to switch into DSi-mode(for running DSi-mode ARM9 code) by writing to a [[PDN]] register(this changes the memory layout to DSi-mode / etc, therefore this register poke *must* be executed from ITCM). This is the final 3DS-mode register poke before the ARM9 switches into DSi-mode. DS(i)-mode ARM7 code is run on the internal [[ARM7]] core, which is started up during TWL_FIRM boot. Trying to read from the exception-vector region(address 0x0) under this DSi-mode ARM7 seems to only return 0x00/0xFF data. Also note that this DSi-mode ARM7 runs code(stored in TWL_FIRM) which pokes some DSi-mode registers that on the DSi were used for disabling access to the DSi bootROMs, however these registers do not affect the 3DS DSi-mode ARM9/ARM7 "bootrom" region(exceptionvector region + 0x8000) at all.

For shutting down the system, TWL_FIRM writes u8 value 8 to [[I2C]] MCU register 0x20. For returning to 3DS-mode, TWL_FIRM writes value 4 to that MCU register to trigger a hardware system reboot.

The TWL_FIRM ARM11-process includes a TWL bootloader, see [http://dsibrew.org/wiki/Bootloader here] and [[Memory_layout#Detailed_TWL_FIRM_ARM11_Memory|here]] for details.

TWL_FIRM verifies all TWL RSA padding with the following. This is different from the DSi "BIOS" code.
* The first byte must be 0x0.
* The second byte must be 0x1 or 0x2.
* Executes a while(<value of byte at current pos in RSA message>). When the second_byte in the message is 0x1, the byte at curpos must be 0xFF(otherwise the non-zero value of the byte at curpos doesn't matter). This loop must find a zero byte before offset 0x7F in the message otherwise an error is returned.
* Returns an address for msg_curpos+1.
totalhashdatasize = rsasig_bytesize - above position in the message for the hashdata. The actual "totalhashdatasize" in the RSA message must be <= <expected hashdata_size>(0x74 for bootloader). The TWL_FIRM code copies the RSA "hashdata" to the output buffer, using the actual size of the RSA "hashdata".

== FIRM Launch Parameters ==
The FIRM-launch parameters structure is located at FCRAM+0, size 0x1000-bytes. The ARM11-kernel copies this structure elsewhere, then clears the 0x1000-bytes at FCRAM+0. It will not handle an existing structure at FCRAM+0 if [[CONFIG Registers#CFG_BOOTENV|CFG_BOOTENV]] is zero. The ARM9 kernel writes some values about the boot environment to AXI WRAM during init to enable this.

{| class="wikitable" border="1"
|-
! OFFSET
! SIZE
! DESCRIPTION
|-
| 0x400
| 0x4
| Flags
|-
| 0x410
| 0xC
| This is used for overriding the FIRM_* fields in [[Configuration_Memory]], when the flag listed below is set, in the following order(basically just data-copy from here to 0x1FF80060): "FIRM_?", FIRM_VERSIONREVISION, FIRM_VERSIONMINOR, FIRM_VERSIONMAJOR, FIRM_SYSCOREVER, and FIRM_CTRSDKVERSION.
|-
| 0x438
| 0x4
| The kernel checks this field for value 0xFFFF, if it matches the kernel uses the rest of these parameter fields, otherwise FIRM-launch parameters fields are ignored by the kernel.
|-
| 0x43C
| 0x4
| CRC32, this is calculated starting at FIRM-params offset 0x400, with size 0x140(with this field cleared to zero during calculation). When invalid the kernel clears the entire buffer used for storing the FIRM-params, therefore no actual FIRM-params are handled after that.
|-
| 0x440
| 0x10
| Titleinfo [[FS:GetProgramLaunchInfo|structure]], used by NS during NS startup, to launch the specified title when the below flag is set.
|-
| 0x450
| 0x10
| Titleinfo [[FS:GetProgramLaunchInfo|structure]]. This might be used for returning to the specified title, once the above launched title terminates?
|-
| 0x460
| 0x4
| Bit0: 0 = titleinfo structure isn't set, 1 = titleinfo structure is set.
|-
| 0x480
| 0x20
| This can be set via buf1 for [[APT:SendDeliverArg]]/[[APT:StartApplication]].
|-
| 0x4A0
| 0x10
| This can be set by [[NSS:SetFIRMParams4A0]].
|-
| 0x4B0
| 0x14
| SHA1-HMAC of the banner for TWL/NTR titles. This can be set by [[NSS:SetFIRMParams4B0]].
|-
| 0x500
| 0x40
| This is used by [[APT:LoadSysMenuArg]] and [[APT:StoreSysMenuArg]].
|}

Flags from offset 0x400:
{| class="wikitable" border="1"
|-
! OFFSET
! SIZE
! DESCRIPTION
|-
| 0x0
| 0x1
| This can be used for overriding the default FCRAM [[Memory_layout|memory-regions]] allocation sizes(APPLICATION, SYSTEM, and BASE). The values for this is the same as [[Configuration_Memory#APPMEMTYPE|Configmem-APPMEMTYPE]]. Values 0-1 are handled the same way by the kernel. However for NS, 0=titleinfo structure for launching a title isn't set, while non-zero=titleinfo structure is set.
|-
| 0x1
| 0x3
| Setting bit0 here enables overriding the FIRM_* fields in [[Configuration_Memory]].
|}

NS and APT Services

2015-08-08T07:08:53Z

WulfyStylez: /* NS Service "ns:s" */

[[Category:Services]]
The NS ('''N'''intendo User Interface '''S'''hell) system module is the first module launched from a CTR-NAND title after the [[FIRM]] processes are loaded. This module is launched by the pm process, with the titleID loaded from NS state(hard-coded TID initialized during applet TID-array initialization). NS first launches [[ErrDisp]], then the menu. On retail the menu TID is loaded from NS state, while on dev/debug the menu TID is loaded from [[Config_Savegame|config]]. On dev-units if the menu TID block doesn't exist in [[Config_Savegame|config]], NS will attempt to launch the alternate menu instead. The TID of the launched menu is then written to [[Configuration Memory|ACTIVEMENUTID]]. NS uses [[PMApp:LaunchTitle|pm:app]] to launch titles.

NS will not trigger the [[ErrDisp|fatal-error]] screen when launching the regular/alternate menu fails.

Like home menu NS is constantly running while the system is in 3DS-mode. When attempting to return to home-menu when the home-menu process isn't running(like when the process terminated/crashed), NS will trigger a [[ErrDisp|fatal]] error.

= Alternate menu =
When launching the regular menu fails, NS will then attempt to launch the alternate menu. This title could be used as a recovery process, however it's normally not used after the factory.

At the factory for all 3DS systems, [[3DS Development Unit GUI#Test Menu|Test Menu]] is installed with this TID. On retail this title is eventually deleted during [[Factory Setup]].

= Auto-boot =
After [[PMApp:GetFIRMLaunchParams|loading]] [[FIRM]] params and prior to launching [[ErrDisp]]/Home Menu, NS handles auto-booting titles. The same code called by [[APT:Reboot]] is used for launching FIRM here. When the [[Configuration_Memory|UPDATEFLAG]] is set, NS will launch SAFE_MODE_FIRM with the application titleID set to the [[System_Settings#System_Updater|System Updater]] titleID for this region. When the UPDATEFLAG is not set, NS can auto-boot the following titles as well if [[Configuration_Memory|0x1FF80016]] bit0 is set.

When bit1 and bit2 are value zero in [[Configuration_Memory|0x1FF80016]], NS will [[NSS:LaunchFIRM|launch]] the title specified by the [[FIRM]] parameters if the title-info is set. This FIRM launch is done after launching [[ErrDisp]] and Home Menu. Otherwise when [[Configuration_Memory|0x1FF80016]] is value 2 and the output u8 from [[PTM|PTMSYSM]] command 0x08140000 is value 0, NS will boot the title specified from the TWL TLNC block from FIRMparams+0x300. This is the same TLNC block which DSi titles wrote to RAM+0x300 for launching other titles via the launcher title. When handling the TLNC block, NS will boot the 3DS System Settings title when the TLNC titleID is the DSi System Settings titleID(the region field in the TLNC TID is not checked/used). When the TLNC titleID is not System Settings, NS will convert the input DSi titleID-high to the 3DS TWL titleID-high(tidhigh = (TLNCtidhigh & 0x7FFF) | 0x48000), then launch TWL_FIRM to run the title. NS does not support launching from gamecard via TLNC.

= NS Workaround =
A "ns_workaround" was [[5.1.0-11|added]] in NS to workaround the flaw added with [[5.0.0-11]]. When NS is loading before launching any ARM11 processes and certain [[Configuration Memory]] fields are set, NS will launch [[Application_Manager_Services|AM]] then use command [[AM:InstallNATIVEFIRM]]. NS will then execute the code called by [[APT:StartNewestHomeMenu]], the code related to APT:PrepareToStartNewestHomeMenu is not executed here.

NS will only execute this code-path when [[Configuration Memory|0x1FF80016]] is value zero, when KERNEL_VERSIONMAJOR is value 2, and when KERNEL_VERSIONMINOR is less than 35. Therefore, this code-path is only executed when the running NATIVE_FIRM version is prior to [[5.0.0-11]].

= NS Service "ns:s" =
{| class="wikitable" border="1"
|-
! Command Header
! Available since system version
! Description
|-
| 0x0001....
| [[1.0.0-0]] - [[2.0.0-2]]
| [[NSS:LaunchFIRM|LaunchFIRM]]
|-
| 0x000200C0
| [[1.0.0-0]] - [[2.0.0-2]]
| [[NSS:LaunchTitle|LaunchTitle]]
|-
| 0x0003....
| [[1.0.0-0]] - [[2.0.0-2]]
| Wrapper for [[Process_Manager_Services|PMApp]] command 0x00030080.
|-
| 0x0004....
| [[1.0.0-0]] - [[2.0.0-2]]
| Wrapper for [[Process_Manager_Services|PMApp]] command 0x000500C0.
|-
| 0x000500C0
| [[1.0.0-0]] - [[2.0.0-2]]
| [[NSS:LaunchApplicationFIRM|LaunchApplicationFIRM]]
|-
| 0x00060042
| [[1.0.0-0]] - [[2.0.0-2]]
| [[NSS:SetFIRMParams4A0|SetFIRMParams4A0]]
|-
| 0x00070042
| [[1.0.0-0]] - [[2.0.0-2]]
| [[NSS:CardUpdateInitialize|CardUpdateInitialize]]
|-
| 0x00080000
| [[1.0.0-0]] - [[2.0.0-2]]
| This shuts down the gamecard system update interface: the shared memory is unmapped, the CFA archive is closed, state is cleared, etc.
|-
| 0x0009....
| [[1.0.0-0]] - [[2.0.0-2]]
| Gamecard system update related.
|-
| 0x000A....
| [[1.0.0-0]] - [[2.0.0-2]]
| Gamecard system update related.
|-
| 0x000B....
| [[1.0.0-0]] - [[2.0.0-2]]
| Gamecard system update related.
|-
| 0x000C....
| [[1.0.0-0]] - [[2.0.0-2]]
| Gamecard system update related.
|-
| 0x000D0140
| [[1.0.0-0]] - [[2.0.0-2]]
| [[NSS:SetFIRMParams4B0|SetFIRMParams4B0]]
|-
| 0x000E....
| [[1.0.0-0]] - [[2.0.0-2]]
| Wrapper for "ptm:sysm" service command 0x040700C0.
|-
| 0x000F0000
| [[1.0.0-0]] - [[2.0.0-2]]
| This calls [[APT:AppletUtility]] with fixed input params.
|-
| 0x00100180
| [[1.0.0-0]] - [[2.0.0-2]]
| [[NSS:RebootSystem|RebootSystem]]
|-
| 0x0011....
| [[1.0.0-0]] - [[2.0.0-2]]
| [[NSS:TerminateProcessTID|TerminateProcessTID]]
|-
| 0x0012....
| ?
| Uses pm:app cmdA&B
|-
| 0x0013....
| ?
| ?
|-
| 0x0014....
| ?
| ?
|-
| 0x0015....
| ?
| ?
|-
| 0x00160000
| [[8.0.0-18]]
| This triggers a hw-reboot.
|}

The maximum sessions that can be used with this service is two, therefore only two processes can use this service at the same time.

=NS Service "ns:p"=
This was added with [[3.0.0-5]]. The PTM sysmodule connects to this service, and syncs whenever [[PTM|ptm:s GetShellState()]] changes.

=NS Service "ns:c"=
This was added with [[5.0.0-11]], it's unknown what this is used for.

=APT Services=
{| class="wikitable" border="1"
|-
! Command Header
! Available since system version
! Accessible with APT:U
! Description
|-
| 0x00010040
|
| Yes
| GetLockHandle
|-
| 0x00020080
|
| See [[APTU:Initialize|here]].
| [[APTU:Initialize|Initialize]]
|-
| 0x00030040
|
| Yes
| Enable
|-
| 0x00040040
|
| Yes
| Finalize
|-
| 0x00050040
|
| Yes
| [[APT:GetAppletManInfo|GetAppletManInfo]]
|-
| 0x00060040
|
| Yes
| [[APT:GetAppletInfo|GetAppletInfo]]
|-
| 0x00070000
|
| Yes
| GetLastSignaledAppletId
|-
| 0x00080000
|
| Yes
| CountRegisteredApplet
|-
| 0x00090040
|
| Yes
| [[APT:IsRegistered|IsRegistered]]
|-
| 0x000A0040
|
| Yes
| GetAttribute
|-
| 0x000B0040
|
| Yes
| [[APTU:GetSignalType|InquireNotification]]
|-
| 0x000C0104
|
| Yes
| [[APT:SendParameter|SendParameter]]
|-
| 0x000D0080
|
| Yes
| [[APT:ReceiveParameter|ReceiveParameter]]
|-
| 0x000E0080
|
| Yes
| [[APT:GlanceParameter|GlanceParameter]]
|-
| 0x000F0100
|
| Yes
| [[APT:CancelParameter|CancelParameter]]
|-
| 0x001000C2
|
| Yes
| DebugFunc
|-
| 0x001100C0
|
| Yes
| [[APT:MapProgramIdForDebug|MapProgramIdForDebug]]
|-
| 0x00120040
|
| Yes
| SetHomeMenuAppletIdForDebug
|-
| 0x00130000
|
| Yes
| GetPreparationState
|-
| 0x00140040
|
| Yes
| SetPreparationState
|-
| 0x00150140
|
| No
| [[APT:PrepareToStartApplication|PrepareToStartApplication]]
|-
| 0x00160040
|
| Yes
| PreloadLibraryApplet
|-
| 0x00170040
|
| Yes
| FinishPreloadingLibraryApplet
|-
| 0x00180040
|
| Yes
| PrepareToStartLibraryApplet
|-
| 0x00190040
|
| Yes
| [[APT:PrepareToStartSystemApplet|PrepareToStartSystemApplet]]
|-
| 0x001A0000
|
| Yes
| PrepareToStartNewestHomeMenu
|-
| 0x001B00C4
|
| Yes
| [[APT:StartApplication|StartApplication]]
|-
| 0x001C0000
|
| Yes
| WakeupApplication
|-
| 0x001D0000
|
| Yes
| CancelApplication
|-
| 0x001E0084
|
| Yes
| StartLibraryApplet
|-
| 0x001F0084
|
| Yes
| [[APT:StartSystemApplet|StartSystemApplet]]
|-
| 0x00200044
|
| Yes
| [[APT:StartNewestHomeMenu|StartNewestHomeMenu]]
|-
| 0x00210000
|
| No
| OrderToCloseApplication
|-
| 0x00220040
|
| Yes
| PrepareToCloseApplication(bool isJumpToHome)
|-
| 0x00230040
|
| Yes
| PrepareToJumpToApplication
|-
| 0x00240044
|
| Yes
| JumpToApplication
|-
| 0x002500C0
|
| Yes
| PrepareToCloseLibraryApplet
|-
| 0x00260000
|
| Yes
| PrepareToCloseSystemApplet
|-
| 0x00270044
|
| Yes
| CloseApplication
|-
| 0x00280044
|
| Yes
| CloseLibraryApplet
|-
| 0x00290044
|
| Yes
| CloseSystemApplet
|-
| 0x002A0000
|
| Yes
| OrderToCloseSystemApplet
|-
| 0x002B0000
|
| Yes
| PrepareToJumpToHomeMenu
|-
| 0x002C0044
|
| Yes
| JumpToHomeMenu
|-
| 0x002D0000
|
| Yes
| PrepareToLeaveHomeMenu
|-
| 0x002E0044
|
| Yes
| LeaveHomeMenu
|-
| 0x002F0040
|
| Yes
| PrepareToLeaveResidentApplet
|-
| 0x00300044
|
| Yes
| LeaveResidentApplet
|-
| 0x00310100
|
| Yes
| [[APT:PrepareToDoApplicationJump|PrepareToDoApplicationJump]]
|-
| 0x00320084
|
| Yes
| [[APT:DoApplicationJump|DoApplicationJump]]
|-
| 0x00330000
|
| Yes
| GetProgramIdOnApplicationJump
|-
| 0x00340084
|
| Yes
| [[APT:SendDeliverArg|SendDeliverArg]]
|-
| 0x00350080
|
| Yes
| ReceiveDeliverArg
|-
| 0x00360040
|
| Yes
| [[APT:LoadSysMenuArg|LoadSysMenuArg]]
|-
| 0x00370042
|
| Yes
| [[APT:StoreSysMenuArg|StoreSysMenuArg]]
|-
| 0x00380040
|
| Yes
| PreloadResidentApplet
|-
| 0x00390040
|
| Yes
| PrepareToStartResidentApplet
|-
| 0x003A0044
|
| Yes
| StartResidentApplet
|-
| 0x003B0040
|
| Yes
| CancelLibraryApplet
|-
| 0x003C0042
|
| Yes
| SendDspSleep
|-
| 0x003D0042
|
| Yes
| SendDspWakeUp
|-
| 0x003E0080
|
| Yes
| ReplySleepQuery
|-
| 0x003F0040
|
| Yes
| ReplySleepNotificationComplete
|-
| 0x00400042
|
| Yes
| [[APT:SendCaptureBufferInfo|SendCaptureBufferInfo]]
|-
| 0x00410040
|
| Yes
| [[APT:ReceiveCaptureBufferInfo|ReceiveCaptureBufferInfo]]
|-
| 0x00420080
|
| Yes
| SleepSystem
|-
| 0x00430040
|
| Yes
| NotifyToWait
|-
| 0x00440000
|
| Yes
| GetSharedFont
|-
| 0x00450040
|
| Yes
| GetWirelessRebootInfo
|-
| 0x00460104
|
| Yes
| [[APT:Wrap|Wrap]]
|-
| 0x00470104
|
| Yes
| [[APT:Unwrap|Unwrap]]
|-
| 0x00480100
|
| No
| [[APT:GetProgramInfo|GetProgramInfo]]
|-
| 0x00490180
|
| No
| [[APT:Reboot|Reboot]]
|-
| 0x004A0040
|
| Yes
| [[APT:GetCaptureInfo|GetCaptureInfo]]
|-
| 0x004B00C2
|
| Yes
| [[APT:AppletUtility|AppletUtility]]
|-
| 0x004C0000
|
| Yes
| SetFatalErrDispMode
|-
| 0x004D0080
|
| Yes
| [[APT:GetAppletProgramInfo|GetAppletProgramInfo]]
|-
| 0x004E0000
|
| Yes
| HardwareResetAsync
|-
| 0x004F0080
| [[2.2.0-X]]
| Yes
| [[APT:SetApplicationCpuTimeLimit|SetApplicationCpuTimeLimit]]
|-
| 0x00500040
| [[2.2.0-X]]
| Yes
| [[APT:GetApplicationCpuTimeLimit|GetApplicationCpuTimeLimit]]
|-
| 0x0051....
| [[3.0.0-5]]
| ?
| Uses pm:app cmdB
|-
| 0x00520104
| [[4.0.0-7]]
| ?
| Wrap1
|-
| 0x00530104
| [[4.0.0-7]]
| ?
| Unwrap1
|-
| 0x00540040
| [[5.0.0-11]]
| ?
| ?
|-
| 0x00550040
| [[7.0.0-13]]
| Yes
| This writes the input u8 to a NS state field.
|-
| 0x00560000
| [[7.0.0-13]]
| Yes
| This returns an u8 NS state field(which can be set by cmd 0x00550040), at cmdreply+8.
|-
| 0x00570044
| [[7.0.0-13]]
| ?
| WakeupApplication2?
|-
| 0x00580002
| [[7.0.0-13]]
| ?
| ?
|-
| 0x01010000
| [[8.0.0-18]]
| Yes
| This writes an output u8 to cmdreply indexword[2]. This uses [[PTMSYSM:CheckNew3DS]]. When a certain NS state field is non-zero, the output value is zero, otherwise the output is from [[PTMSYSM:CheckNew3DS]]. Normally this NS state field is zero, however this state field is set to 1 when [[APT:PrepareToStartApplication]] is used with flags bit8 is set.
|-
| 0x01020000
| [[8.0.0-18]]
| Yes
| Wrapper for [[PTMSYSM:CheckNew3DS]].
|-
| 0x01030000
| [[8.0.0-18]]
| Yes
| ?
|-
| 0x01040000
| [[8.0.0-18]]
| ?
| ?
|}

These "APT:U" and "APT:S" NS services can handle launching titles/"applets", these services handle signaling for home/power button as well. Only one session for either APT service can be open at a time, normally processes close the service handle immediately once finished using the service. The commands for APT:U and APT:S are exactly the same, however certain commands are only accessible with APT:S(NS module will call [[SVC|svcBreak]] when the command isn't accessible).

Applets returning to home-menu first use commands APT:PrepareToJumpToHomeMenu and APT:JumpToHomeMenu, followed by these commands to launch home-menu: [[APT:PrepareToStartSystemApplet]] and [[APT:StartSystemApplet]]. [[APT:PrepareToStartSystemApplet]] and [[APT:StartSystemApplet]] are also used for launching the [[Internet Browser]], the camera applet, etc.

Processes launch applications via home-menu, not directly with [[APT:PrepareToStartApplication]] and [[APT:StartApplication]]. Regular applications can't directly launch applications since [[APT:StartApplication]] launches the process without terminating the currently running application.

APT:PrepareToDoApplicationJump and APT:DoApplicationJump are used by applications, for launching native/<non-NATIVE_FIRM> applications. These commands notify Home Menu that title launching needs done, Home Menu does the actual title launching via NS commands.

="APT:A" Service=
This was added with [[7.0.0-13|7.0.0-X]]. Official apps built with the CTRSDK for system-version >=[[7.0.0-13|7.0.0-X]] normally use the "APT:A" service instead of "APT:U". Those processes also have "APT:A" instead of "APT:U" in the service-access-control. It's unknown whether there's anything which is only accessible via "APT:A".

=Library Applets=
Library applets can be launched by applications and regular applets. These library applets render to the screen(s) when running, etc. For example, this includes swkbd for text input. See the below appIDs in the 0x2XX range, the actual appID used is 0x4XX however.

Input data can be sent to the library applet via the NS [[APT:SendParameter|parameter]] buffer, and/or with shared-memory with a shared-mem handle sent to the library applet. Output data from the library applet can be received by [[APT:ReceiveParameter]], the library applet can also use the specified shared-mem for output too.

=AppIDs=
{| class="wikitable" border="1"
|-
! AppID
! Description
|-
| 0x101
| Home Menu (menu)
|-
| 0x103
| Alternate Menu
|-
| 0x110
| Camera applet (CtrApp)
|-
| 0x112
| Friends List applet (friend)
|-
| 0x113
| Game Notes applet (Cherry)
|-
| 0x114
| [[Internet Browser]] (spider/SKATER)
|-
| 0x115
| Instruction Manual applet
|-
| 0x116
| Notifications applet (newslist)
|-
| 0x117
| Miiverse applet (olv)
|-
| 0x201
| Software Keyboard (swkbd) (?)
|-
| 0x202
| Mii Selector (appletEd) (?)
|-
| 0x204
| Photo Selector (PNOTE_AP) (?)
|-
| 0x205
| Sound Selector (SNOTE_AP) (?)
|-
| 0x206
| Error Display (error) (?)
|-
| 0x207
| eShop applet (mint) (?)
|-
| 0x208
| Circle Pad Pro Calibrator ([[Extrapad_Applet|extrapad]]) (?)
|-
| 0x209
| Notepad (memolib) (?)
|-
| 0x300
| Application
|-
| 0x401
| Software Keyboard (swkbd)
|-
| 0x402
| Mii Selector (appletEd)
|-
| 0x404
| Photo Selector (PNOTE_AP)
|-
| 0x405
| Sound Selector (SNOTE_AP)
|-
| 0x406
| Error Display (error)
|-
| 0x407
| eShop applet (mint)
|-
| 0x408
| Circle Pad Pro Calibrator ([[Extrapad_Applet|extrapad]])
|-
| 0x409
| Notepad (memolib)
|-
| 0xF10
| ProgramID: 0004003000008900.
|-
| 0xF11
| ProgramID: 000400000FFFFD00.
|-
| 0xF12
| ProgramID: 000400000FFFFC00.
|-
| 0xF13
| ProgramID: 000400000FFFFB00.
|-
| 0xF14
| ProgramID: 000400000FFFF900.
|-
| 0xF15
| ProgramID: 000400000FFFF800.
|-
| 0xF16
| ProgramID: 000400000FFFF700.
|-
| 0xF17
| ProgramID: 000400000FFFF600.
|-
| 0xF18
| ProgramID: 000400000FFFF500.
|}

These AppIDs are all for NAND titles, except for 0x300. AppIDs in the 0x1XX range are applets(programID-high 00040030), and the AppIDs in the 0x2XX range are "system libraries"(programID-high 00040030). The 0xFXX AppID range is for development NAND applications, these are not available for retail.

Note that at some point the total AppID entry count was changed from 28 to 27.

NSS:SetTWLBannerHMAC

2015-08-08T07:08:37Z

WulfyStylez: /* Request */

=Request=
{| class="wikitable" border="1"
|-
! Index Word
! Description
|-
| 0
| Header code [0x000D0140]
|-
| 1-5
| Input param data
|}

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

=Description=
The input 20-byte data is copied to the NS [[FIRM]] parameter buffer at offset 0x4B0.

Filesystem services

2015-08-06T23:25:30Z

WulfyStylez: this was orphaned

[[Category:Services]]

= Filesystem service "fs:USER" =
You can at most have 32 FS archive handles.

{| class="wikitable" border="1"
|-
! Command Header
! Available since system version
! Description
! scope="col" width="400" | Required [[NCCH/Extended_Header|exheader]] access info bitmask
|-
| 0x000100C6
|?
| Dummy1
| None
|-
| 0x040100C4
|?
| Control
| None
|-
| 0x08010002
|?
| [[FS:Initialize|Initialize]]
| None
|-
| 0x080201C2
|?
| [[FS:OpenFile|OpenFile]]
| None
|-
| 0x08030204
|?
| [[FS:OpenFileDirectly|OpenFileDirectly]]
| None
|-
| 0x08040142
|?
| [[FS:DeleteFile|DeleteFile]]
| None
|-
| 0x08050244
|?
| [[FS:RenameFile|RenameFile]]
| None
|-
| 0x08060142
|?
| [[FS:DeleteDirectory|DeleteDirectory]]
| None
|-
| 0x08070142
|?
| [[FS:DeleteDirectoryRecursively|DeleteDirectoryRecursively]]
| None
|-
| 0x08080202
|?
| [[FS:CreateFile|CreateFile]]
| None
|-
| 0x08090182
|?
| [[FS:CreateDirectory|CreateDirectory]]
| None
|-
| 0x080A0244
|?
| [[FS:RenameDirectory|RenameDirectory]]
| None
|-
| 0x080B0102
|?
| [[FS:OpenDirectory|OpenDirectory]]
| None
|-
| 0x080C00C2
|?
| [[FS:OpenArchive|OpenArchive]]
| Each archive ID code has separate access info bitmasks, if it has any
|-
| 0x080D0144
|?
| ControlArchive
| None
|-
| 0x080E0080
|?
| [[FS:CloseArchive|CloseArchive]]
| None
|-
| 0x080F0180
|?
| [[FS:FormatThisUserSaveData|FormatThisUserSaveData]]
| None
|-
| 0x08100200
|?
| CreateSystemSaveData
| 0x4, for when the input saveID doesn't match the exheader saveID
|-
| 0x08110040
|?
| DeleteSystemSaveData
| 0x1004, for when the input saveID doesn't match the exheader saveID
|-
| 0x08120080
|?
| GetFreeBytes
| None
|-
| 0x08130000
|?
| [[FS:GetCardType|GetCardType]]
| 0x1017
|-
| 0x08140000
|?
| [[FS:GetSdmcArchiveResource|GetSdmcArchiveResource]]
| None
|-
| 0x08150000
|?
| [[FS:GetNandArchiveResource|GetNandArchiveResource]]
| 0x1007
|-
| 0x08160000
|?
| GetSdmcFatfsError
| 0x2
|-
| 0x08170000
|?
| [[FS:IsSdmcDetected|IsSdmcDetected]]
| None
|-
| 0x08180000
|?
| [[FS:IsSdmcWritable|IsSdmcWritable]]
| None
|-
| 0x08190042
|?
| GetSdmcCid
| 0x2
|-
| 0x081A0042
|?
| GetNandCid
| 0x2
|-
| 0x081B0000
|?
| GetSdmcSpeedInfo
| 0x2
|-
| 0x081C0000
|?
| GetNandSpeedInfo
| 0x2
|-
| 0x081D0042
|?
| GetSdmcLog
| 0x2
|-
| 0x081E0042
|?
| GetNandLog
| 0x2
|-
| 0x081F0000
|?
| ClearSdmcLog
| 0x2
|-
| 0x08200000
|?
| ClearNandLog
| 0x2
|-
| 0x08210000
|?
| [[FS:CardSlotIsInserted|CardSlotIsInserted]]
| 0x1017
|-
| 0x08220000
|?
| CardSlotPowerOn
| 0x2
|-
| 0x08230000
|?
| CardSlotPowerOff
| 0x2
|-
| 0x08240000
|?
| CardSlotGetCardIFPowerStatus
| 0x2
|-
| 0x08250040
|?
| CardNorDirectCommand
| 0x2
|-
| 0x08260080
|?
| CardNorDirectCommandWithAddress
| 0x2
|-
| 0x08270082
|?
| CardNorDirectRead
| 0x2
|-
| 0x082800C2
|?
| CardNorDirectReadWithAddress
| 0x2
|-
| 0x08290082
|?
| CardNorDirectWrite
| 0x2
|-
| 0x082A00C2
|?
| CardNorDirectWriteWithAddress
| 0x2
|-
| 0x082B00C2
|?
| CardNorDirectRead_4xIO
| 0x2
|-
| 0x082C0082
|?
| CardNorDirectCpuWriteWithoutVerify
| 0x2
|-
| 0x082D0040
|?
| CardNorDirectSectorEraseWithoutVerify
| 0x2
|-
| 0x082E0040
|?
| [[FS:GetProductInfo|GetProductInfo]]
| 0x1005
|-
| 0x082F0040
|?
| [[FS:GetProgramLaunchInfo|GetProgramLaunchInfo]]
| 0x1005
|-
| 0x08300182
|?
| CreateExtSaveData
| 0xC, for when the input extdataID doesn't match the exheader extdataID
|-
| 0x08310180
|?
| CreateSharedExtSaveData
| 0x1005
|-
| 0x08320102
|?
| [[FS:ReadExtSaveDataIcon|ReadExtSaveDataIcon]]
| 0x100D, for when the input extdataID doesn't match the exheader extdataID
|-
| 0x08330082
|?
| [[FS:EnumerateExtSaveData|EnumerateExtSaveData]]
| 0x1005
|-
| 0x08340082
|?
| EnumerateSharedExtSaveData
| 0x1005
|-
| 0x08350080
|?
| DeleteExtSaveData
| 0x100D, for when the input extdataID doesn't match the exheader extdataID
|-
| 0x08360080
|?
| DeleteSharedExtSaveData
| 0x1005
|-
| 0x08370040
|?
| SetCardSpiBaudRate
| 0x2
|-
| 0x08380040
|?
| SetCardSpiBusMode
| 0x2
|-
| 0x08390000
|?
| SendInitializeInfoTo9
| None
|-
| 0x083A0100
|?
| GetSpecialContentIndex
| 0x1005
|-
| 0x083B00C2
|?
| GetLegacyRomHeader
| 0x1015
|-
| 0x083C00C2
|?
| GetLegacyBannerData
| 0x1015
|-
| 0x083D0100
|?
| CheckAuthorityToAccessExtSaveData
| 0x44
|-
| 0x083E00C2
|?
| QueryTotalQuotaSize
| None
|-
| 0x083F00C0
|?
| GetExtDataBlockSize
| None
|-
| 0x08400040
|?
| AbnegateAccessRight
|?
|-
| 0x08410000
|?
| DeleteSdmcRoot
| 0x1005
|-
| 0x08420040
|?
| DeleteAllExtSaveDataOnNand
| 0x1005
|-
| 0x08430000
|?
| [[FS:InitializeCtrFileSystem|InitializeCtrFileSystem]]
| None
|-
| 0x08440000
|?
| CreateSeed
| 0x2
|-
| 0x084500C2
|?
| [[FS:GetFormatInfo|GetFormatInfo]]
|?
|-
| 0x08460102
|?
| GetLegacyRomHeader2
| 0x1015
|-
| 0x08470180
|?
| FormatCtrCardUserSaveData
| 0x6
|-
| 0x08480042
|?
| GetSdmcCtrRootPath
| 0x100D
|-
| 0x08490040
|?
| [[FS:GetArchiveResource|GetArchiveResource]]
|?
|-
| 0x084A0002
|?
| ExportIntegrityVerificationSeed
| 0x4000
|-
| 0x084B0002
|?
| ImportIntegrityVerificationSeed
| 0x4000
|-
| 0x084C0242
|?
| [[FS:FormatSaveData|FormatSaveData]]
| 0x6, in some cases this write isn't needed however
|-
| 0x084D0102
|?
| GetLegacySubBannerData
| 0x1015
|-
| 0x084E0342
|?
| [[FS:UpdateSha256Context|UpdateSha256Context]]
| 0x5
|-
| 0x084F0102
|?
| ReadSpecialFile
| None
|-
| 0x08500040
|?
| GetSpecialFileSize
| None
|-
| 0x08510242
| [[3.0.0-5]]
| [[FS:CreateExtSaveData|CreateExtSaveData]]
| Shared extdata: 0x101005. Regular extdata in certain cases: 0xC
|-
| 0x08520100
| [[3.0.0-5]]
| DeleteExtSaveData (u32 flags, u64 extdataID)
| Shared extdata: 0x101005. Regular extdata in certain cases: 0x10100D
|-
| 0x08530142
| [[3.0.0-5]]
| ReadExtSaveDataIcon
| 0x10100D (this doesn't apply in certain cases, however)
|-
| 0x085400C0
| [[3.0.0-5]]
| GetExtDataBlockSize?
| 0x10100D (this doesn't apply in certain cases, however)
|-
| 0x08550102
| [[3.0.0-5]]
| EnumerateExtSaveData
| 0x101005
|-
| 0x08560200
| [[3.0.0-5]]
| FsCreateSystemSaveData?
| 0x4 (this doesn't apply in certain cases, however)
|-
| 0x08570080
| [[3.0.0-5]]
| DeleteSystemSaveData
| 0x1004 (this doesn't apply in certain cases, however)
|-
| 0x08580000
| [[3.0.0-5]]
| [[FS:GetMovableSedHashedKeyYRandomData|GetMovableSedHashedKeyYRandomData]]
| 0x2004
|-
| 0x08590200
| [[3.0.0-5]]
| SetMovableSedHashedKeyYRandomData?
| 0x2004
|-
| 0x085A00C0
| [[3.0.0-5]]
| SetArchivePriority(u64 ID,u32 priority)
| None
|-
| 0x085B0080
| [[3.0.0-5]]
| GetArchivePriority(u64 ID,u32 *priority)
| None
|-
| 0x085C00C0
| [[3.0.0-5]]
| SetCtrCardLatencyParameter
| 0xE
|-
| 0x085D0180
| [[3.0.0-5]]
|?
| 0x100001
|-
| 0x085E0040
| [[3.0.0-5]]
| ResetCardCompatibilityParameter
| 0xE
|-
| 0x085F0040
| [[3.0.0-5]]
| SwitchCleanupInvalidSaveData
| 0x12004
|-
| 0x08600042
| [[3.0.0-5]]
| [[FS:EnumerateSystemSaveData|EnumerateSystemSaveData]]
| 0x2004
|-
| 0x08610042
| [[3.0.0-5]]
| [[FS:InitializeWithSdkVersion|InitializeWithSdkVersion]]
| None
|-
| 0x08620040
| [[3.0.0-5]]
| SetPriority
| None
|-
| 0x08630000
| [[3.0.0-5]]
| GetPriority
| None
|-
| 0x08640000
| [[3.0.0-5]]
| Obsoleted_4_0_GetNandInfo
| Stubbed, this returns an error
|-
| 0x08650140
| [[4.0.0-7]]
| SetSaveDataSecureValue, this is used with [[Anti Savegame Restore]].
| 0x121004 (in certain cases this doesn't apply, however)
|-
| 0x086600C0
| [[4.0.0-7]]
| GetSaveDataSecureValue, this is used with [[Anti Savegame Restore]].
| 0x121004 (in certain cases this doesn't apply, however)
|-
| 0x086700C4
| [[4.0.0-7]]
| ControlSecureSave
| 0x121004
|-
| 0x08680000
| [[4.0.0-7]]
| GetMediaType, This loads the u8 mediatype for the current application from already initialized state, this u8 was originally loaded from the same data used by [[FS:GetProgramLaunchInfo|GetProgramLaunchInfo]]. This then writes the u8 to response-word[2]. This is used with [[Anti Savegame Restore]]
| None
|-
| 0x08690000
| [[4.0.0-7]]
| Obsoleted_4_0_GetNandEraseCount Stubbed, this returns an error.
| None
|-
| 0x086A0082
| [[4.0.0-7]]
| ReadNandReport This is a wrapper for [[Filesystem_services_PXI|FSPXI]] command 0x00550082.
| None
|-
| 0x086B00C2
|?
|?
| 00121004
|-
| 0x086C00C2
|?
|?
| 00121004
|-
| 0x086D0040
|?
|?
| 00020004
|-
| 0x086E00C0
|?
|?
|None?
|-
| 0x086F0040
|?
|?
| 0xE
|-
| 0x087000C2
|?
|?
|None?
|-
| 0x08710100
|?
|?
| 0xC
|-
| 0x087201C0
|?
|?
| 00080004
|-
| 0x087300C0
|?
|?
| 00080004
|-
| 0x08740000
|?
|?
| 00080004
|-
| 0x08750140
|?
|?
|None?
|-
| 0x087600C0
|?
|?
|None?
|-
| 0x08770100
|?
|?
|?
|-
| 0x087800C0
|?
|?
|?
|-
| 0x087900C2
| ?
| Same as GetLegacyBannerData, except for the last parameter this passes u8 value 0x1 instead of 0x0, for the FSPXI command.
| 0x00101015
|-
| 0x087A....
| [[9.6.0-24|9.6.0-X]]
| ?
| 0x00200000
|-
| 0x087B....
| [[9.6.0-24|9.6.0-X]]
| Wrapper for the code internally used for command <0x087A....>.
| 0x00200000
|-
| 0x087C....
| [[9.6.0-24|9.6.0-X]]
| Eventually calls same code as command <0x087A....>.
| 0x00200000
|-
| 0x087D0000
| [[9.6.0-24|9.6.0-X]]
| Writes an u32 from state to cmdreply[2]. Probably the total number of titles in the SEEDDB?
| 0x00200000
|-
| 0x087E0042
| [[9.6.0-24|9.6.0-X]]
| Eventually calls same code as command <0x087A....>. Writes a list of titleIDs to the outbuf, this is for titles with content-lock-seed(s) stored in SEEDDB. (u32 total_titleids_probably, ((Size<<4) <nowiki>|</nowiki> 12), outbufptr)
| 0x00200000
|-
| 0x087F....
| [[9.6.0-24|9.6.0-X]]
| ?
| 0x00200000
|-
| 0x0880....
| [[9.6.0-24|9.6.0-X]]
| Eventually calls same code as command <0x087A....>.
| 0x00200000
|-
| 0x0881....
| [[9.6.0-24|9.6.0-X]]
| Eventually calls same code as command <0x087A....>.
| 0x00200000
|-
| 0x0882....
| [[9.6.0-24|9.6.0-X]]
| Eventually calls same code as command <0x087A....>.
| 0x00200000
|-
| 0x08830000
| [[9.6.0-24|9.6.0-X]]
| Writes an output value to cmdreply[2].
| 0x00200000
|-
| 0x0884....
| [[9.6.0-24|9.6.0-X]]
| Eventually calls same code as command <0x087A....>.
| 0x00200000
|-
| 0x0885....
| [[9.6.0-24|9.6.0-X]]
| ?
| 0x00200000
|}

Note: The question marks from Dummy1 to GetSpecialFileSize on the "available since system version" field are mainly there because I think that most of these are necessary for the main system to function, so theoretically that would mean that since the creation of the 3DS these were available, or since launch if that makes more sense. But because of the peculiar nature of some of the functions, they will remain question marks until they can be confirmed 100%.

When access rights are required for a command, at least one of the bits in the process access info specified in the above table for the command must be set. Error 0xD9004676 is returned when a process attempts to use a command which it doesn't have access rights for the command. The exheader access info field is all zero's for most applications. Note that the permissions listed in the above table is for system-version v2.x, therefore permission bit(s) added with newer FIRM may be missing from this.

Each session for fs:USER has separate permissions, initially these are set to all zero's for new fs:USER sessions. The permissions/etc for fs:USER sessions are initialized via [[FS:Initialize]](loaded from the user process exheader).

=File service=
{| class="wikitable" border="1"
|-
! Command Header
! Description
|-
| 0x000100C6
| Dummy1
|-
| 0x040100C4
| Control
|-
| 0x08010100
| OpenSubFile
|-
| 0x080200C2
| [[FSFile:Read|Read]]
|-
| 0x08030102
| [[FSFile:Write|Write]]
|-
| 0x08040000
| [[FSFile:GetSize|GetSize]]
|-
| 0x08050080
| [[FSFile:SetSize|SetSize]]
|-
| 0x08060000
| GetAttributes
|-
| 0x08070040
| SetAttributes
|-
| 0x08080000
| [[FSFile:Close|Close]]
|-
| 0x08090000
| Flush
|-
| 0x080A0040
| SetPriority
|-
| 0x080B0000
| GetPriority
|-
| 0x080C0000
| OpenLinkFile
|-
| 0x0C010100
| ?
|}

=Directory service=
{| class="wikitable" border="1"
|-
! Command Header
! Available since system version
! Description
|-
| 0x000100C6
| [[1.0.0-0]]
| Dummy1
|-
| 0x040100C4
| [[1.0.0-0]]
| Control
|-
| 0x08010042
| [[1.0.0-0]]
| [[FSDir:Read|Read]]
|-
| 0x08020000
| [[1.0.0-0]]
| [[FSDir:Close|Close]]
|-
| 0x08030040
| ?
| SetPriority
|-
| 0x08040000
| ?
| GetPriority
|}

= Filesystem service "fs:LDR" =
This service is identical to fs:USER, except [[FS:OpenArchive]] archive 0x2345678E can only be accessed with fs:LDR.

= ProgramRegistry service "fs:REG" =
{| class="wikitable" border="1"
|-
! Command Header
! Description
|-
| 0x000100C6
| Dummy1
|-
| 0x040103C0
| [[FSReg:Register|Register]]
|-
| 0x04020040
| [[FSReg:Unregister|Unregister]]
|-
| 0x040300C0
| GetProgramInfo
|-
| 0x04040100
| LoadProgram
|-
| 0x04050080
| UnloadProgram
|-
| 0x04060080
| CheckHostLoadId
|}

Only one session can be opened for this service at a time, hence no other processes can use this due to [[Process_Manager_Services|pm-module]] using this.

=SEEDDB=
With [[9.6.0-24|9.6.0-X]] new [[System_SaveData]] with saveID 0001000F was added, this seems to be handled by FS-module itself, probably via the new service-cmds added to fsuser. [[Home Menu]] and [[NIM_Services|NIM]] module have access to those commands.

The SEEDDB savedata contains the title-unique seed-data used for the new [[NCCH]] keyY generation added with FIRM [[9.6.0-24|9.6.0-X]].

=Errors=
See [[Filesystem_services_PXI]].

NCSD

2015-08-02T01:23:33Z

WulfyStylez: time to descend into hell in order to properly document this

[[Category:File formats]]
This page documents the format of NCSD.

== Overview ==
There are two known specialisations of the NCSD container format. The CTR Cart Image (CCI) format and the 3DS' raw [[Flash Filesystem#NAND structure|NAND format]]. CCI is the format of game ROM images.

'''CTR System Update (CSU)''' is a variant of CCI, where the only difference is in the file extension. This is used with developer System Updates and associated [[3DS Development Unit Software|Tools]].

NCSD images start with a NCSD header, followed by up to a maximum of 8 [[NCCH]] partitions.

For CCI images, the partitions are reserved as follows:

{| class="wikitable" border="1"
|-
! [[NCCH]] Index
! Reserved Use
|-
| 0
| Executable Content ([[NCCH#CXI|CXI]])
|-
| 1
| E-Manual ([[NCCH#CFA|CFA]])
|-
| 2
| [[Download Play]] Child container ([[NCCH#CFA|CFA]])
|-
| 6
| New3DS [[System_Update_CFA|Update Data]] ([[NCCH#CFA|CFA]])
|-
| 7
| [[System_Update_CFA|Update Data]] ([[NCCH#CFA|CFA]])
|}

The format of partitions can be determined from the partition FS flags (normally these are zero for CCI/CSU NCSD Images).

== NCSD header ==
{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
|-
| 0x000
| 0x100
| RSA-2048 SHA-256 signature of the NCSD header
|-
| 0x100
| 4
| Magic Number 'NCSD'
|-
| 0x104
| 4
| Size of the NCSD image, in media units (1 media unit = 0x200 bytes)
|-
| 0x108
| 8
| Media ID
|-
| 0x110
| 8
| Partitions FS type (0=None, 1=Normal, 3=FIRM, 4=AGB_FIRM save)
|-
| 0x118
| 8
| Partitions crypt type
|-
| 0x120
| 0x40=(4+4)*8
| Offset & Length partition table, in media units
|-
| 0x160
| 0xA0
| ...
|}

For carts,
{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
|-
| 0x160
| 0x20
| Exheader SHA-256 hash
|-
| 0x180
| 0x4
| Additional header size
|-
| 0x184
| 0x4
| Sector zero offset
|-
| 0x188
| 8
| Partition Flags (See Below)
|-
| 0x190
| 0x40=8*8
| Partition ID table
|-
| 0x1C0
| 0x30
| Reserved
|-
| 0x1F0
| 0xE
| Reserved?
|-
| 0x1FE
| 0x1
| Support for this was implemented with [[9.6.0-24|9.6.0-X]] FIRM. Bit0=1 enables using bits 1-2, it's unknown what these two bits are actually used for(the value of these two bits get compared with some other value during NCSD verification/loading). This appears to enable a new, likely hardware-based, antipiracy check on cartridges.
|-
| 0x1FF
| 0x1
| Support for this was implemented with [[9.6.0-24|9.6.0-X]] FIRM, see below regarding save crypto.
|}

For NAND,

{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
|-
| 0x160
| 0x5E
| Unknown
|-
| 0x1BE
| 0x42
| Encrypted MBR partition-table, for the TWL partitions(key-data used for this keyslot is console-unique).
|}

=== Partition Flags ===
{| class="wikitable" border="1"
|-
! Byte Index
! Description
|-
| 0
| Backup Write Wait Time (The time to wait to write save to backup after the card is recognized (0-255 seconds)).NATIVE_FIRM loads this flag from the gamecard NCSD header starting with [[6.0.0-11]].
|-
| 3
| Media Card Device (1 = NOR Flash, 2 = None, 3 = BT) (SDK 3.X+)
|-
| 4
| Media Platform Index (1 = CTR)
|-
| 5
| Media Type Index (0 = Inner Device, 1 = Card1, 2 = Card2, 3 = Extended Device)
|-
| 6
| Media Unit Size i.e. u32 MediaUnitSize = 0x200*2^flags[6];
|-
| 7
| Media Card Device (1 = NOR Flash, 2 = None, 3 = BT) (Only SDK 2.X)
|}

=== Partition Flags (In Terms of Save Crypto Determination) ===
{| class="wikitable" border="1"
|-
! Byte Index
! Description
|-
| 1
| Starting with [[6.0.0-11]] NATIVE_FIRM will use this flag to determine the gamecard [[Savegames|savegame]] keyY method, when flag[3] is set. 0 = [[2.0.0-2]] hashed keyY, 1 = [[Savegames|new]] keyY method implemented with [[6.0.0-11]]. 0x0A = implemented with [[9.3.0-21|9.3.0-X]]. On Old3DS this is identical to the [[2.2.0-4]] crypto. On New3DS this is identical to the [[2.2.0-4]] crypto, except with New3DS-only gamecard savedata [[AES|keyslots]].
Starting with [[9.6.0-24|9.6.0-X]] FIRM, Process9 now sets <savecrypto_stateval> to partitionflag[1] + <the u8 value from NCSD+0x1FF>, instead of just setting it to partitionflag[1].
|-
| 3
| Support for this flag was implemented in NATIVE_FIRM with [[2.0.0-2]]. When this flag is set the hashed gamecard [[Savegames|savegame]] keyY method is used, this likely still uses the repeating-CTR however. With [[6.0.0-11]] the system will determine the gamecard savegame keyY method via flag[1], instead of just using the hashed keyY via this flag.
|-th
| 7
| This flag enables using the hashed gamecard [[Savegames|savegame]] keyY method, support for this flag was implemented in NATIVE_FIRM with [[2.2.0-4]]. All games with the NCSD image finalized since [[2.2.0-4]](and contains [[2.2.0-4]]+ in the system update partition) have this flag set, this flag also enables using new CTR method as well.
|}

Starting with [[9.6.0-24|9.6.0-X]] FIRM, Process9 will just write val0 to a state field then return 0, instead of returning an error when the save crypto type isn't recognized. This was the *only* actual functionality change in the Old3DS Process9 function for gamecard savedata crypto init.

== Card Info Header ==
{| class="wikitable" border="1"
|-
! OFFSET
! SIZE
! DESCRIPTION
|-
| 0x200
| 4
| CARD2: Writable Address In Media Units (For 'On-Chip' Savedata). CARD1: Always 0xFFFFFFFF.
|-
| 0x204
| 4
| Card Info Bitmask
|-
| 0x208
| 0xDF8
| Reserved1
|-
| 0x1000
| 8
| Media ID (same as first NCCH partitionId)
|-
| 0x1008
| 8
| Reserved2
|-
| 0x1010
| 0x30
| Initial Data
|-
| 0x1040
| 0xC0
| Reserved
|-
| 0x1100
| 0x100
| Copy of first NCCH header (excluding RSA signature)
|}

== Development Card Info Header Extension ==
{| class="wikitable" border="1"
|-
! OFFSET
! SIZE
! DESCRIPTION
|-
| 0x1200
| 0x200
| CardDeviceReserved1
|-
| 0x1400
| 0x10
| TitleKey
|-
| 0x1410
| 0xF0
| CardDeviceReserved2
|}

== Tools ==

[https://github.com/3dshax/ctr/tree/master/ctrtool ctrtool] - (CMD)(Windows/Linux) Parsing NCSD files

[[3DSExplorer]] - (GUI)(Windows Only) Parsing NCSD files

Hardware

2015-08-01T06:12:37Z

WulfyStylez: /* Specifications */

This page lists and describes the hardware found inside the Nintendo 3DS. Many of these parts are custom made and are expanded upon here or in other pages.

== Common hardware ==
{| class="wikitable"
! Type !! Description
|-
| ARM11 Processor Core || [http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0360f/index.html ARM11 2x MPCore & 2x VFPv2 Co-Processor] 268MHz(~268123480 Hz).
On New3DS models, there is instead 4x MPCore & 4x VFPv2.
|-
| ARM9 Processor Core || [http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0201d/index.html ARM946] 134MHz(~134058675 Hz),
|-
| GPU || [http://en.wikipedia.org/wiki/PICA200 DMP PICA] 268MHz,
|-
| DSP || [https://twitter.com/CEVADSP/status/177172880918986752 CEVA TeakLite]. 134Mhz. 24ch 32728Hz sampling rates.
|-
| VRAM || 6 MB within SoC.
|}
The above clock-rates were calculated by calling svcGetSystemTick in sets of 5(call it, execute svcSleepThread for 1s, then call it again), then the average of those were calculated. The clock-rate listed above applies for *all* 4 New3DS MPCores.

== Specifications ==
{| class="wikitable"
! Type !! 3DS !! 3DSXL !! 2DS !! N3DS !! N3DSXL
|-
| SoC || CPU CTR (1048 0H)
CPU CTR (1214 32)
|| CPU CTR A (1226 60)
CPU CTR (1037 21)
|| CPU CTR B (??) || CPU LGR A (1444 86) || CPU LGR A (1446 17)
|-
| FCRAM || [http://www.fujitsu.com/downloads/MICRO/fma/pdf/MB81EDS516545_e511463.pdf 2x64MB Fujitsu MB82M8080-07L] || Fujitsu MB82DBS16641 || Fujitsu MB82DBS1664 || ?? || Fujitsu MB82MK9A9A
|-
| Storage || Toshiba THGBM2G3P1FBAI8 1GB || ?? || Toshiba THGBM4G3P1H8BAIR 1GB || Samsung KLM4G1YEQC 4GB (in 1.3GiB SLC mode)
Toshiba THGBMBG4P1KBAIT 2GB (MLC)
|| Samsung KLM4G1YEMD-B031 4GB (in 1.3GiB SLC mode)
Toshiba THGBMBG4P1KBAIT (MLC)
|-
| Audio Codec || TI PAIC3010B 0AA37DW || ?? || ?? || TI AIC3010B 39C4ETW || TI AIC3010D 48C01JW
|-
| Gyroscope || [http://dl-web.dropbox.com/u/20520664/references/PS-ITG-3200-00-01.4.pdf Invensense ITG-3270 MEMS Gyroscope] || ?? || ?? || ?? || ??
|-
| Accelerometer || ST Micro 2048 33DH X1MAQ Accelerometer Model LIS331DH || ?? || ?? || ?? || ??
|-
| Wifi || Atheros AR6014 || ?? || ?? || ?? || Atheros AR6014G-AL1C
|-
| Infrared IC || NXP S750 0803 TSD031C || ?? || ?? || ?? || NXP S750 1603 TSD438C
|-
| Custom Microcontroller || Renesas UC CTR || ?? || Renesas UC CTR 324KM47 KG10 || Renesas UC KTR || Renesas UC KTR 442KM13 TK14
|-
| PMIC? || TI 93045A4 OAAH86W || ?? || ?? || TI 93045A4 38A6TYW G2 || TI 93045A4 49AF3NW G2
|}

* [11] Official Documentation

* [5],[10] According to iFixit.com ([http://www.ifixit.com/Teardown/Nintendo-3DS-Teardown/5029/1#s22696 source]):

* Datasheet for memory is for a chip in the same series, it has less memory than the one inside the 3DS (128mbits vs 512mbits).

* There is a trove of data on the FCC website at [https://fjallfoss.fcc.gov/oetcf/eas/reports/ViewExhibitReport.cfm?mode=Exhibits&RequestTimeout=500&calledFromFrame=N&application_id=462292&fcc_id=%27EW4DWMW028%27].

* [12] This IC is somewhat similar to [http://www.alldatasheet.net/datasheet-pdf/pdf/347838/NXP/SC16IS750IBS.html this].

== FCRAM ==

There is one FCRAM (Fast Cycle RAM) IC in the 3DS, produced by Fujitsu and branded as MB82M8080-07L. The Fujitsu MB82M8080-07L chip internally contains 2 dies, where each die is branded MB81EDS516545 and MB82DBS08645.

The MB81EDS516545 die is a CMOS Fast Cycle Random Access Memory (FCRAM) with Low Power Double Data Rate (LPDDR) SDRAM Interface containing 512MBit storage accessible in a 64-bit format. The MB81EDS516545 is suited for consumer applications requiring high data bandwidth with low power consumption.

== SoC ==

The 3DS has much of it's internals housed in a SoC (System on Chip) just like it's predecessors. This is done to reduce build costs, cut down on power consumption, as well as make the PCB layout less complex and make the system harder to tamper with. The SoC, branded as the Nintendo 1048 0H, contains the CPU, GPU, DSP and VRAM.

According to official documents, the CPU used is a dual-core ARM11 CPU, clocked at 268MHz. One core is dedicated to system software, while the other is used for application programming, each known as the syscore and appcore, respectively.

== GPU ==

Designed by Digital Media Professionals Inc. (DMP) and codenamed PICA200, 268Mhz.

Block diagram of an ULTRAY2000 based architecture PICA200:

[[File:Pica200BlockDiagram.png]]

PICA200 is compatible with OpenGL ES 1.1. It furthermore provides unique functionality for:
* Per-fragment lighting ("Lighting Maestro")
* Hard- and soft-shadowing ("Shadow Maestro")
* Polygon subdivision ("Figure Maestro")
* Bump mapping and procedural textures ("Mapping Maestro")
* Rendering of gaseous objects ("Particle Maestro")

Some parts of the extended functionality are provided in hardware by an extended geometry pipeline. Most importantly, PICA200 has three programmable vertex processors. There is furthermore a unit called Primitive Engine, which is a geometry shader unit (using the same instruction set as vertex shaders) with support for variable-size primitives. The Primitive Engine functionality may be disabled, and the geometry shader unit then acts as a fourth vertex processor. See [[Shader_Instruction_Set]] for more information on the shader instruction set.

Fragment lighting is implemented as an optional pipeline step during pixel processing. It's implemented by having the vertex shader output an additional attribute describing the transformation (represented by a quaternion) to surface-local space. This per-vertex quaternion can then be interpolated across screen space to calculate dot products relevant for lighting (e.g. light vector dot normal vector). To provide support for advanced lighting models, these dot products are used as indices into programmable lookup tables. With this setup, PICA200 in particular supports the shading models Blinn-Phong, Cook-Terrance, Ward, and microfacet-based BRDF-models.

== SDIO controller ==

Nintendo recommends SD cards up to 32 GB however the internal SDIO controller seems to support SD cards up to 2.19 Terabyte (32-bit sector number). It's unknown if it really can handle that much. 128 GB was tested and works fine however it causes a major slowdown of the system especially at boot.

== Images ==

=== Front ===

[[Image:CTR_Front.jpg|600px]]

[http://guide-images.ifixit.net/igi/ishJaSCOwLkvbLYK High Resolution]

=== Back ===

[[Image:CTR_Back.jpg]]

[http://guide-images.ifixit.net/igi/n1CKAdbPrHyNPNuW High Resolution]

=== NAND pinout ===

NAND dumping has been successful, but the image is encrypted.

==== Normal model ====

[[Image:CTR_NAND_pinout.png]]

==== XL model ====

[[Image:CTR_NAND_pinout_XL.jpg|500px]]

==== 2DS ====

[[Image:2DSeMMC.jpg|500px]]

==== New 3DS ====

[[Image:N3DSeMMC.jpg]]

==== New 3DS XL ====

[[Image:N3DSXLeMMC.jpg]]

=== WiFi dongle pinout ===
[[Image:CTR_WiFiDongle_pinout.png|600px]]

SDIO interface is colored red:
* CLK
* CMD
* D0, D1, D2, D3

This is the interface for the 'NEW' WiFi module (based on Atheros AR6002) first included in DSi.

The proprietary and by now ancient DS-mode WiFi is colored yellow, pins are unknown.

I2C eeprom is colored blue:
* SCL
* SDA

SPI Flash is colored purple:
* CLK
* CS#
* SI
* SO
* WP#
* NC

=== Auxiliary Microntroller ===
[[Image:CTR_UC.png|600px]]

Monitors HOME button, WiFi switch, 3D slider, volume control slider.
Controls LEDs, various power supplies.

Devices attached to I2C bus:
* UC (master?)
* Accelerometer (slave address 0x18)
* SoC (master? slave?)

ARM7 Registers

2015-07-15T14:55:39Z

WulfyStylez: /* Memory map */

Memory layout

2015-07-15T13:19:35Z

WulfyStylez: more aes keys

=ARM11 Physical memory regions =
{| class="wikitable" border="1"
|-
! Old 3DS
! Address
! Size
! Description
|-
| style="background: green" | Yes
| 0x00000000
| 0x00010000
| Bootrom (super secret code/data @ 0x8000)
|-
| style="background: green" | Yes
| 0x00010000
| 0x00010000
| Bootrom mirror
|-
| style="background: green" | Yes
| 0x10000000
|?
| [[IO]] memory
|-
| style="background: green" | Yes
| 0x17E00000
| 0x00002000
| MPCore private memory region

|-
| style="background: red" | No
| 0x17E10000
| 0x00001000
| ?
|-
| style="background: green" | Yes
| 0x18000000
| 0x00600000
| VRAM (divided in two banks, VRAM and VRAMB)
|-
| style="background: red" | No
| 0x1F000000
| 0x00400000
| [[New_3DS]] additional memory
|-
| style="background: green" | Yes
| 0x1FF00000
| 0x00080000
| DSP memory
|-
| style="background: green" | Yes
| 0x1FF80000
| 0x00080000
| AXI WRAM
|-
| style="background: green" | Yes
| 0x20000000
| 0x08000000
| FCRAM
|-
| style="background: red" | No
| 0x28000000
| 0x08000000
| [[New_3DS]] FCRAM extension
|-
| style="background: green" | Yes
| 0xFFFF0000
| 0x00010000
| Bootrom mirror
|}

=ARM9 Physical memory regions =
{| class="wikitable" border="1"
|-
! Old 3DS
! Address
! Size
! Description
|-
| style="background: green" | Yes
| 0x00000000
| 0x08000000
| Instruction TCM, repeating each 0x8000 bytes.
|-
| style="background: green" | Yes
| 0x01FF8000
| 0x00008000
| Instruction TCM (Accessed by the kernel and process by this address)
|-
| style="background: green" | Yes
| 0x07FF8000
| 0x00008000
| Instruction TCM (Accessed by bootrom by this address)
|-
| style="background: green" | Yes
| 0x08000000
| 0x00100000
| ARM9-only internal memory (ARM7's internal regions are mapped here as well)
|-
| style="background: red" | No
| 0x08100000
| 0x00080000
| [[New_3DS]] ARM9-only extension, only enabled when a certain [[CONFIG_Registers|CONFIG]] register is set.
|-
| style="background: green" | Yes
| 0x10000000
| 0x08000000
| [[IO]] memory
|-
| style="background: green" | Yes
| 0x18000000
| 0x00600000
| VRAM (divided in two banks, VRAM and VRAMB)
|-
| style="background: green" | Yes
| 0x1FF00000
| 0x00080000
| DSP memory
|-
| style="background: green" | Yes
| 0x1FF80000
| 0x00080000
| AXI WRAM
|-
| style="background: green" | Yes
| 0x20000000
| 0x08000000
| FCRAM
|-
| style="background: red" | No
| 0x28000000
| 0x08000000
| [[New_3DS]] FCRAM extension
|-
| style="background: green" | Yes
| 0xFFF00000
| 0x00004000
| Data TCM (Mapped during bootrom)
|-
| style="background: green" | Yes
| 0xFFFF0000
| 0x00010000
| Bootrom, the main region is at +0x8000, which is disabled during system boot.
|}

==ARM9 MPU regions==
For the below instruction permissions: RO = memory is executable, while None = not-executable.

===NATIVE_FIRM/SAFE_MODE_FIRM ARM9 kernel===
{| class="wikitable" border="1"
|-
! Region
! Address
! Size
! Privileged-mode data permissions
! User-mode data permissions
! Privileged-mode instruction permissions
! User-mode instruction permissions
|-
| 0
| 0xFFFF0000
| 32KB/0x8000
| RO
| None
| RO
| None
|-
| 1
| 0x01FF8000
| 32KB/0x8000
| RW
| RW
| RO
| RO
|-
| 2
| 0x08000000
| 1MB/0x100000. >=[[8.0.0-18|8.0.0-X]]: 2MB/0x200000.
| RW
| RW
| RO
| RO
|-
| 3
| 0x10000000
| 128KB/0x20000
| RW
| RW
| None
| None
|-
| 4
| 0x10100000
| 512KB/0x80000
| RW
| RW
| None
| None
|-
| 5
| 0x20000000
| 128MB/0x8000000. >=[[8.0.0-18|8.0.0-X]]: 256MB/0x10000000.
| RW
| RW
| None
| None
|-
| 6
| 0x08000000
| 128KB/0x20000
| RW
| None
| RO
| None
|-
| 7
| 0x08020000
| <[[3.0.0-5]]: 64KB/0x10000. >=[[3.0.0-5]]: 32KB/0x8000.
| RW
| None
| RO
| None
|}

The above is the MPU region settings setup by the ARM9-kernel in the crt0.

The New3DS ARM9-kernel MPU region settings are the same as the Old3DS MPU region settings for >=[[8.0.0-18|8.0.0-X]].

At the start of the Process9 function executed in kernel-mode via svc7b during firm-launching, it changes some MPU region settings. At the end of that function, before it uses the ARM9/ARM11 entrypoint fields, it disables MPU.

===New3DS [[FIRM|ARM9-loader]]===
{| class="wikitable" border="1"
|-
! Region
! Address
! Size
! Privileged-mode data permissions
! User-mode data permissions
! Privileged-mode instruction permissions
! User-mode instruction permissions
|-
| 0
| 0xFFFF0000
| 32KB/0x8000
| RO
| None
| RO
| None
|-
| 1
| 0x01FF8000
| 32KB/0x8000
| RW
| None
| RO
| None
|-
| 2
| 0x08000000
| 2MB/0x200000
| RW
| None
| RO
| None
|-
| 3
| 0x10000000
| 128KB/0x20000
| RW
| None
| None
| None
|}

MPU regions 4-7 are disabled. Note that the entire ARM9-loader runs in SVC-mode.

===TWL_FIRM/AGB_FIRM ARM9 kernel===
{| class="wikitable" border="1"
|-
! Region
! Address
! Size
! Privileged-mode data permissions
! User-mode data permissions
! Privileged-mode instruction permissions
! User-mode instruction permissions
|-
| 0
| 0xFFFF0000
| 32KB/0x8000
| RO
| None
| RO
| None
|-
| 1
| 0x01FF8000
| 32KB/0x8000
| RW
| RW
| RO
| RO
|-
| 2
| 0x08000000
| 1MB/0x100000. New3DS: 2MB/0x200000.
| RW
| RW
| RO
| RO
|-
| 3
| 0x10000000
| 2MB/0x200000.
| RW
| RW
| None
| None
|-
| 4
| 0x1FF00000
| 512KB/0x80000
| RW
| RW
| None
| None
|-
| 5
| 0x20000000
| 128MB/0x8000000. New3DS: 256MB/0x10000000.
| RW
| RW
| None
| None
|-
| 6
| 0x08000000
| <[[3.0.0-5|3.0.0-X]]: 256KB/0x40000. >=[[3.0.0-5|3.0.0-X]]: 128KB/0x20000
| RW
| None
| RO
| None
|-
| 7
| 0x08080000
| 128KB/0x20000
| RW
| RW
| RO
| RO
|}

==ARM9 ITCM==
{| class="wikitable" border="1"
|-
! ITCM mirror address
! ITCM bootrom mirror address
! Offset
! Size
! Description
|-
| 0x01FF8000
|
| 0x0
| 0x3700
| Uninitialized memory.
|-
| 0x01FFB700
| 0x07FFB700
| 0x3700
| 0x100
| The unprotected ARM9-bootrom code copies code from unprotected bootrom to 0x07FFB700(ITCM mirror) size 0x100, then calls the code at 0x07FFB700. The code located here is the code used for disabling access to the bootroms.
|-
| 0x01FFB800
|
| 0x3800
| 0x4
| This is always 0xDEADB00F.
|-
| 0x01FFB804
|
| 0x3804
| 0x4
| This is the u32 DeviceId.
|-
| 0x01FFB808
|
| 0x3808
| 0x10
| This is the fall-back keyY used for movable.sed keyY when movable.sed doesn't exist in NAND(the last two words here are used on retail for generating console-unique TWL keydata/etc). This is also used for "LocalFriendCodeSeed", etc.
|-
| 0x01FFB818
|
| 0x3818
| 0x1
| ?
|-
| 0x01FFB819
|
| 0x3819
| 0x1
| This is the [[CTCert]] issuer type: 0 = retail "Nintendo CA - G3_NintendoCTR2prod", non-zero = dev "Nintendo CA - G3_NintendoCTR2dev".
|-
| 0x01FFB81A
|
| 0x381A
| 0x6
| ?
|-
| 0x01FFB820
|
| 0x3820
| 0x4
| This is the CTCert ECDSA exponent, this is byte-swapped when *((u8*)(0x01FFB800+0x18)) is >=5.
|-
| 0x01FFB824
|
| 0x3824
| 0x2
| ?
|-
| 0x01FFB826
|
| 0x3826
| 0x1E
| This is the CTCert ECDSA privk.
|-
| 0x01FFB844
|
| 0x3844
| 0x3C
| This is the CTCert ECDSA signature.
|-
| 0x01FFB880
|
| 0x3880
| 0x80
| This is all-zero.
|-
| 0x01FFB900
|
| 0x3900
| 0x200
| This is the 0x200-bytes from NAND sector0.
|-
| 0x01FFBB00
|
| 0x3B00
| 0x200
| This is the 0x200-bytes from the plaintext NAND firm partition FIRM header, read by bootrom.
|-
| 0x01FFBD00
|
| 0x3D00
| 0x200
| Unknown, not used by [[FIRM]]. Probably RSA related going by the data right after this? These are not console-unique.
|-
| 0x01FFBF00
|
| 0x3F00
| 0x100
| This is the RSA-2048 modulo for [[RSA_Registers|RSA]]-engine slot2.
|-
| 0x01FFC000
|
| 0x4000
| 0x100
| This is the RSA-2048 modulo for RSA-engine slot3.
|-
| 0x01FFC100
|
| 0x4100
| 0x800
| Unknown, not console-unique.
|-
| 0x01FFC900
| 0x07FFC900
| 0x4900
| 0x400
| The unprotected ARM9-bootrom copies data to 0x07FFC900(mirror of 0x01FFC900) size 0x400. This data is copied from AXI WRAM, initialized by ARM11-bootrom(the addr used for the src is determined by [[CONFIG_Registers|REG_UNITINFO]]). These are RSA modulus: retailsrcptr = 0x1FFFD000, devsrvptr = 0x1FFFD400.
* The first 0x100-bytes here is the RSA-2048 modulo for the CFA NCCH header, and for the gamecard NCSD header.
* 0x01FFCA00 is the RSA-2048 modulo for the CXI accessdesc signature, written to rsaengine keyslot1 by NATIVE_FIRM.
* 0x01FFCB00 size 0x200 is unknown, probably RSA related, these aren't used by [[FIRM]](these are not console-unique).
|-
| 0x01FFCD00
|
| 0x4D00
| 0x80
| Unknown, not used by [[FIRM]]. This isn't console-unique.
The first 0x10-bytes are checked by the v6.0/v7.0 NATIVE_FIRM keyinit function, when non-zero it clears this block and continues to do the key generation. Otherwise when this block was already all-zero, it immediately returns.
|-
| 0x01FFCD80
|
| 0x4D80
| 0x64
| 0x01FFCD84 size 0x10-bytes is the NAND CID(the 0x64-byte region at 0x01FFCD80 is initialized by Process9 + ARM9-bootrom). The u32 at 0x01FFCDC4 is the total number of NAND sectors, read from a MMC command.
|-
| 0x01FFCDE4
|
| 0x4DE4
| 0x21C
| Uninitialized memory.
|-
| 0x01FFD000
| 0x07FFD000
| 0x5000
| 0x2470
| The unprotected ARM9-bootrom copies 0x1FFFA000(AXIWRAM mem initialized by ARM11-bootrom) size 0x2470 to 0x07FFD000(mirror of 0x01FFD000). This block contains DSi keys.
* 0x01FFD000 is the RSA-1024 modulus for the retail System Menu
* 0x01FFD080 is the RSA-1024 modulus for DSi Wifi firmware and DSi Sound
* 0x01FFD100 is the RSA-1024 modulus for base DSi apps (Settings, Shop, etc.)
* 0x01FFD180 is the RSA-1024 modulus for DSiWare and RSA-signed cartridge headers
* 0x01FFD210 is the keyY for per-console-encrypted ES blocks
* 0x01FFD220 is the keyY for fixed-keyX ES blocks
* 0x01FFD300 is the DSi common (normal)key
* 0x01FFD350 is a normalkey set on keyslot 0x02, and is likely only used during boot
* 0x01FFD380 is the keyslot 0x00 keyX and the first half of the retail keyY for modcrypt crypto "Nintendo"
* 0x01FFD398 is the keyX used for 'Tad' crypto, usually in keyslot 0x02 "Nintendo DS", ..
* 0x01FFD3A8 is set as the middle two words of keyslot 0x03's keyX, before being overwritten "NINTENDO"
* 0x01FFD3BC is the first 3 words of keyslot 0x01's keyY, see below
* 0x01FFD3C8 is the fixed keyY used for eMMC partition crypto on retail DSi, see below (keyslot 0x03)
* 0x01FFD3E0 is the 0x1048-byte Blowfish data for DSi cart crypto
* 0x01FFE428 is the 0x1048-byte Blowfish data for DS cart crypto
On the 3DS, keyslots 0x02 and 0x03 have the last word set as 0xE1A00005 instead of the original DSi retail keyYs.
|-
| 0x01FFF470
|
| 0x7470
| 0xB90
| Uninitialized memory.
0x01FFFC00 size 0x100-bytes starting with [[9.5.0-22|9.5.0-X]] is the FIRM header used during FIRM-launching.
|}

=[[New_3DS]] physical 0x1F000000 memory=
This area is used by [[QTM Services]](starting at offset 0x200000, size 0x180000). This area is not accessible to the GPU on the old 3DS. The old 3DS and New 3DS GSP module has vaddr->physaddr conversion code for this entire region. On the New 3DS, only the first 0x200000-bytes (half of this memory) are accessible to the GPU.

=Memory map by firmware=
* [[Virtual address mapping FW0B]]
* [[Virtual address mapping FW1F]]
* [[Virtual address mapping FW25]]
* [[Virtual address mapping FW2E]]
* [[Virtual address mapping FW37]]
* [[Virtual address mapping FW38‎]]
* [[Virtual address mapping FW3F]]
* FW49([[9.6.0-24|9.6.0-X]]) ARM11-kernel vmem mapping is identical to FW40([[9.5.0-22|9.5.0-X]]).

* [[Virtual address mapping TWLFIRM04]]

* [[Virtual address mapping New3DS v8.1]]
* [[Virtual address mapping New3DS v9.0]]
* [[Virtual address mapping New3DS v9.2]]

=ARM11 Detailed physical memory map=
18000000 - 18600000: VRAM

1FF80000 - 1FFAB000: Kernel code
1FFAB000 - 1FFF0000: SlabHeap [temporarily contains boot processes]
1FFF0000 - 1FFF1000: ?
1FFF1000 - 1FFF2000: ?
1FFF2000 - 1FFF3000: ?
1FFF3000 - 1FFF4000: ?
1FFF4000 - 1FFF5000: Exception vectors
1FFF5000 - 1FFF5800: Unused?
1FFF5800 - 1FFF5C00: 256-entry L2 MMU table for VA FF4xx000
1FFF5C00 - 1FFF6000: 256-entry L2 MMU table for VA FF5xx000
1FFF6000 - 1FFF6400: 256-entry L2 MMU table for VA FF6xx000
1FFF6400 - 1FFF6800: 256-entry L2 MMU table for VA FF7xx000
1FFF6800 - 1FFF6C00: 256-entry L2 MMU table for VA FF8xx000
1FFF6C00 - 1FFF7000: 256-entry L2 MMU table for VA FF9xx000
1FFF7000 - 1FFF7400: 256-entry L2 MMU table for VA FFAxx000
1FFF7400 - 1FFF7800: 256-entry L2 MMU table for VA FFBxx000
1FFF7800 - 1FFF7C00: MMU table but unused?
1FFF7C00 - 1FFF8000: 256-entry L2 MMU table for VA FFFxx000
1FFF8000 - 1FFFC000: 4096-entry L1 MMU table for VA xxx00000 (CPU 0)
1FFFC000 - 20000000: 4096-entry L1 MMU table for VA xxx00000 (CPU 1)
20000000 - 28000000: Main memory

The entire FCRAM is cleared during NATIVE_FIRM boot. This is probably done by the ARM11 kernel(after loading [[FIRM]] launch parameters from FCRAM)?

== FCRAM memory-regions layout ==
{| class="wikitable" border="1"
! [[Configuration_Memory#APPMEMTYPE|Configmem-APPMEMTYPE]] Value
! Base address relative to FCRAM+0, for APPLICATION mem-region
! Region size, for APPLICATION mem-region
! Base address relative to FCRAM+0, for SYSTEM mem-region
! Region size, for SYSTEM mem-region
! Base address relative to FCRAM+0, for BASE mem-region
! Region size, for BASE mem-region
|-
| 0 (default with regular 3DS kernel, used when the type is not 2-5)
| 0x0
| 0x04000000(64MB)
| 0x04000000
| 0x02C00000
| 0x06C00000
| 0x01400000
|-
| 2
| 0x0
| 0x06000000(96MB)
| 0x06000000
| 0x00C00000
| 0x06C00000
| 0x01400000
|-
| 3
| 0x0
| 0x05000000(80MB)
| 0x05000000
| 0x01C00000
| 0x06C00000
| 0x01400000
|-
| 4
| 0x0
| 0x04800000(72MB)
| 0x04800000
| 0x02400000
| 0x06C00000
| 0x01400000
|-
| 5
| 0x0
| 0x02000000(32MB)
| 0x02000000
| 0x04C00000
| 0x06C00000
| 0x01400000
|-
| 6 (This is the default on New3DS. With [[New_3DS]] kernel this is the type used when the value is not 7)
| 0x0
| 0x07C00000(124MB)
| 0x07C00000
| 0x06400000
| 0x0E000000
| 0x02000000
|-
| 7
| 0x0
| 0x0B200000(178MB)
| 0x0B200000
| 0x02E00000
| 0x0E000000
| 0x02000000
|}

The SYSTEM mem-region size is calculated with: size = FCRAMTOTALSIZE - (APPLICATION_MEMREGIONSIZE + BASE_MEMREGIONSIZE).

Support for type6/7 was [[NCCH/Extended Header|implemented]] in [[NS]] with [[8.0.0-18]], these are only supported in the [[New_3DS]] ARM11-kernel not the regular 3DS kernel. These two types are the only ones supported by the New3DS kernel.

All memory allocated by the kernel itself for kernel use is located under BASE. Most system-modules run under the BASE memregion too.

Free/used memory on [[4.5.0-10]] with Home Menu / Internet Browser, with the default APPMEMTYPE on retail:
{| class="wikitable" border="1"
! Region
! Base address relative to FCRAM+0
! Region size
! Used memory once [[Home Menu]] finishes loading for system boot, on [[4.5.0-10]]
! Used memory with [[Internet Browser]] running instead of [[Home Menu]], on [[4.5.0-10]]
! Free memory once [[Home Menu]] finishes loading for system boot, on [[4.5.0-10]]
! Free memory with [[Internet Browser]] running instead of [[Home Menu]], on [[4.5.0-10]]
|-
| APPLICATION
| 0x0
| 0x04000000
| 0x0
|
| 0x04000000
|
|-
| SYSTEM
| 0x04000000
| 0x02C00000
| 0x01488000
| 0x02A50000
| 0x01778000
| 0x001B0000
|-
| BASE
| 0x06C00000
| 0x01400000
| 0x01202000
| 0x01236000
| 0x001FE000
| 0x001CA000
|}

=ARM11 Detailed virtual memory map=
(valid only for FW0B, see [[#Memory map by firmware|Memory map by firmware]] for subsequent versions)

E8000000 - E8600000: mapped VRAM (18000000 - 18600000)

EFF00000 - F0000000: mapped Internal memory (1FF00000 - 20000000)
F0000000 - F8000000: mapped Main memory

FF401000 - FF402000: mapped ? (27FC7000 - 27FC8000)

FF403000 - FF404000: mapped ? (27FC2000 - 27FC3000)

FF405000 - FF406000: mapped ? (27FBB000 - 27FBC000)

FF407000 - FF408000: mapped ? (27FB3000 - 27FB4000)

FF409000 - FF40A000: mapped ? (27F8E000 - 27F8F000)

FFF00000 - FFF45000: mapped SlabHeap

FFF60000 - FFF8B000: mapped Kernel code

FFFCC000 - FFFCD000: mapped IO [[I2C|I2C]] second bus (10144000 - 10145000)

FFFCE000 - FFFCF000: mapped IO PDC([[LCD]]) (10400000 - 10401000)

FFFD0000 - FFFD1000: mapped IO PDN (10141000 - 10142000)

FFFD2000 - FFFD3000: mapped IO PXI (10163000 - 10164000)

FFFD4000 - FFFD5000: mapped IO PAD (10146000 - 10147000)

FFFD6000 - FFFD7000: mapped IO LCD (10202000 - 10203000)

FFFD8000 - FFFD9000: mapped IO DSP (10140000 - 10141000)

FFFDA000 - FFFDB000: mapped IO XDMA (10200000 - 10201000)

FFFDC000 - FFFE0000: mapped ? (1FFF8000 - 1FFFC000)

FFFE1000 - FFFE2000: mapped ? (1FFF0000 - 1FFF1000)

FFFE3000 - FFFE4000: mapped ? (1FFF2000 - 1FFF3000)

FFFE5000 - FFFE9000: mapped L1 MMU table for VA xxx00000

FFFEA000 - FFFEB000: mapped ? (1FFF1000 - 1FFF2000)

FFFEC000 - FFFED000: mapped ? (1FFF3000 - 1FFF4000)

FFFEE000 - FFFF0000: mapped IO IRQ (17E00000 - 17E02000)

FFFF0000 - FFFF1000: mapped Exception vectors

FFFF2000 - FFFF6000: mapped L1 MMU table for VA xxx00000

FFFF7000 - FFFF8000: mapped ? (1FFF1000 - 1FFF2000)

FFFF9000 - FFFFA000: mapped ? (1FFF3000 - 1FFF4000)

FFFFB000 - FFFFE000: mapped L2 MMU tables (1FFF5000 - 1FFF8000)

==0xFF4XX000==
Each [[KThread|thread]] is allocated a 0x1000-byte page in this region: the first page at 0xFF401000 is for the first created thread, 0xFF403000 for the second thread. This region is used to store the SVC-mode stack for the thread, and thread context data used for context switching. When the IRQ handler, prefetch/data abort handlers, and undefined instruction handler are entered where the SPSR-mode=user, these handlers then store LR+SPSR for the current mode on the SVC-mode stack, then these handlers switch to SVC-mode.

This page does not contain a dedicated block for storing R0-PC(etc). For user-mode, the user-mode regs are instead saved on the SVC-mode stack when IRQs such as timers for context switching are triggered.

Structure of this page, relative to page_endaddr-0xC8:
{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
|-
| 0x0
|
| SVC-mode stack-top. The 0x10-byte SVC-access-control for this thread is also located here, which is checked by the SVC-handler.
|-
| 0x18
| 0x28
| SVC-mode saved registers, stored/loaded during context switches: R4-R9, SL, FP, SP, LR. After loading these registers, the context switch code will jump to the loaded LR.
|-
| 0xC0
| 4
| fpexc from vmrs, used during context switches with the above saved registers.
|}

For NATIVE_FIRM the memory pages for this region are located in FCRAM, however for TWL_FIRM these are located in AXI WRAM. For TWL_FIRM v6704 the first thread's page for this region is located at physical address 0x1FF93000, the next one at 0x1FF92000, etc.

=ARM11 User-land memory regions=
==NATIVE_FIRM/SAFE_MODE_FIRM Userland Memory==
{| class="wikitable" border="1"
|-
! Virtual Address Base
! Physical Address Base
! Region Max Size
! Address-range available for svcMapMemoryBlock
! Description
|-
| 0x00100000 / 0x14000000
|
| 0x03F00000
| No
| The [[ExeFS]]:/.code is loaded here, executables must be loaded to the 0x00100000 region when the exheader "special memory" flag is clear. The 0x03F00000-byte size restriction only applies when this flag is clear. Executables are usually loaded to 0x14000000 when the exheader "special memory" flag is set, however this address can be arbitrary.
|-
| 0x04000000
| ?
| ?
| No
| Used for mapping buffers during IPC, see [[IPC Command Structure]].
|-
| 0x08000000
| Main stack physaddr - <heap size for the allocated vaddr 0x08000000 memory>
| 0x08000000
| Yes
| Heap mapped by [[SVC|ControlMemory]]
|-
| 0x10000000-StackSize
| .bss physical address - total stack pages
| StackSize from process exheader
|
| Stack for the main-thread, initialized by the ARM11 kernel. The StackSize from the exheader is usually 0x4000, therefore the stack-bottom is usually 0x0FFFC000. The stack for the other threads is normally located in the process .data section however this can be arbitrary.
|-
| 0x10000000
|
| 0x04000000
| Yes
| [[SVC|Shared]] memory
|-
| 0x14000000
| FCRAM+0
| 0x08000000
| No
| Can be mapped by [[SVC|ControlMemory]], this is used for processes' [[SVC|LINEAR]]/GSP heap.
|-
| 0x1E800000
| 0x1F000000
| 0x00400000
| No
| [[New_3DS]] additional memory, access to this is specified by the exheader. Added with [[8.0.0-18]], see above section regarding this memory.
|-
| 0x1EC00000
| 0x10100000
| 0x01000000
| No
| [[IO]] registers, the mapped IO pages which each process can access is specified in the [[NCCH#CXI|CXI]] exheader.(Applications normally don't have access to registers in this range)
|-
| 0x1F000000
| 0x18000000
| 0x00600000
| No
| VRAM, access to this is specified by the exheader.
|-
| 0x1FF00000
| 0x1FF00000
| 0x00080000
| No
| DSP memory, access to this is specified by the exheader.
|-
| 0x1FF80000
| FCRAM memory page allocated by the ARM11 kernel.
| 0x1000
| No
| [[Configuration Memory]], all processes have read-only access to this.
|-
| 0x1FF81000
| FCRAM memory page allocated by the ARM11 kernel.
| 0x1000
| No
| [[Configuration Memory|Shared]] page, all processes have read-access to this. Write access to this is specified by the exheader "Shared page writing" kernel flag.
|-
| 0x1FF82000
| ?
| ?
| No
| [[Thread Local Storage]]
|-
| 0x30000000
| FCRAM+0
| 0x08000000(Old3DS) / 0x10000000([[New_3DS]])
| No
| This LINEAR memory mapping was added with [[8.0.0-18]], see [[SVC#enum_MemoryOperation|here]]. This replaces the original 0x14000000 mapping, for system(memory-region=BASE)/newer titles. The Old3DS kernel uses size 0x08000000 for LINEAR-memory address range checks, while the New3DS kernel uses size 0x10000000 for those range checks. Old3DS/New3DS system-module code doing vaddr->phys-addr conversion uses size 0x10000000.
|-
| 0x20000000 / 0x40000000
|
|
|
| This is the end-address of userland memory, memory under this address is process-unique. Memory starting at this address is only accessible in privileged-mode. This address was changed from 0x20000000 to 0x40000000 with [[8.0.0-18]].
|}

All executable pages are read-only, and data pages have the execute-never permission set. Normally .text from the loaded ExeFS:/.code is the only mapped executable memory. Executable [[RO Services|CROs]] can be loaded into memory, once loaded the CRO .text section memory page permissions are changed via [[SVC|ControlProcessMemory]] from RW- to R-X. The address and size of each ExeFS:/.code section is stored in the exheader, the permissions for each section is: .text R-X, .rodata R--, .data RW-, and .bss RW-. The loaded .code is mapped to the addresses specified in the exheader by the ARM11 kernel. The stack permissions is initialized by the ARM11 kernel: RW-. The heap permissions is normally RW-.

All userland memory is mapped with RW permissions for privileged-mode. However, normally the ARM11 kernel only uses userland read/write instructions(or checks that the memory can be written from userland first) for accessing memory specified by [[SVC|SVCs]].

Processes can't directly access memory for other processes. When service [[Services API|commands]] are used, the kernel maps memory in the destination process for input/output buffers, where the addresses in the command received by the process is replaced by this mapped memory. When this is an input buffer, the buffer data is copied to the mapped memory. When this is an output buffer, the data stored in the mapped memory is copied to the destination buffer specified in the command.

The physical address which memory for the application memory-type is mapped to begins at FCRAM+0, the total memory allocated for this memory-type is stored in [[Configuration_Memory]]. Applications' .text + .rodata + .data under the application memory-type is mapped at FCRAM + APPMEMALLOC - (aligned page-size for .text + .rodata + .data). The application .bss is mapped at CODEADDR - .bss size aligned down to the page size.

==TWL_FIRM Userland Memory==
{| class="wikitable" border="1"
|-
! Virtual Address Base
! Physical Address Base
! Size
! Description
|-
| 0x00100000
| 0x1FFAB000 (with newer TWL_FIRM such as v6704 this is located at 0x1FFAC000)
| 0x00055000
| Code + .(ro)data copied from the process 0x00300000 region is located here(.bss is located here as well).
|-
| 0x00155000
| 0x18555000
| 0x000AB000
|
|-
| 0x00200000
| 0x18500000
| 0x00100000
|
|-
| 0x00300000
| 0x24000000
| 0x04000000
| The beginning of the ARM11 process .text is located here.
|-
| 0x08000000
| 0x20000000
| 0x07E00000
|
|-
| 0x1EC00000
| 0x10100000
| 0x00400000
| [[IO]]
|-
| 0x1F000000
| 0x18000000
| 0x00600000
| VRAM
|-
| 0x1FF00000
| 0x1FF00000
| 0x00080000
| This is mapped to the DSP memory.
|}

The above regions are mapped by the ARM11 kernel. Later when the ARM11 process uses [[SVC|svcKernelSetState]] with type4, the kernel unmaps(?) the following regions: 0x00300000..0x04300000, 0x08000000..0x0FE00000, and 0x10000000..0xF8000000.

=== Detailed TWL_FIRM ARM11 Memory ===
{| class="wikitable" border="1"
|-
! Process Virtual Address
! Physical Address
! Size
! Description
|-
| 0x08000000
| 0x20000000
| 0x01000000*4
| DS(i) 0x02000000 RAM. Vaddr = (DSRAMOffset*4) + 0x08000000, where DSRAMOffset is DSRAMAddr-0x02000000.
|-
| 0x0FC00000
| 0x27C00000
|
| Loaded SRL binary, initially the dev DSi launcher SRL is located here(copied here by the ARM11 process).
|-
| 0x0FD00000
| 0x27D00000
|
| The data located here is copied to here by the ARM11 process. The data located here is a TWL NAND [http://dsibrew.org/wiki/Bootloader bootloader] image, using the same format+encryption/verification methods as the DSi NAND bootloader(stage2). The keyX for this bootloader keyslot is initially set to the retail DSi key-data, however when TWL_FIRM is launched this keyX key-data is replaced with a separate keyX. TWL_FIRM can use either the retail DSi bootloader RSA-1024 modulo, or a seperate modulo: normally only the latter is used(the former is only used when loading the image from FS instead of FCRAM). When using the image from FCRAM(default code-path), TWL_FIRM will not calculate+check the hashes for the bootloader code binaries(this is done when loading from FS however).
|-
| 0x0FDF7000
| 0x27DF7000
| 0x1000
| SRL header
|}

= System memory details =
0xFFFF9000 Pointer to the current KThread instance
0xFFFF9004 Pointer to the current KProcess instance
0xFFFF9008 Pointer to the current KScheduler instance
0xFFFF9010 Pointer to the last KThread to encounter an exception

0x8000040 Pointer to the current KThread instance on the ARM9
0x8000044 Pointer to the current KProcess instance on the ARM9
0x8000048 Pointer to the current KScheduler instance on the ARM9

= Handles =
The handle 0xFFFF8001 is a reference to the current KProcess.
The handle 0xFFFF8000 is a reference to the current KThread.

= IO Process/Kernel virtual addressing equivalence =
It seems an IO register's process virtual address can be calculated by adding 0xEB00000 to its physical address.

= VRAM Map While Running System Applets =
*0x1E6000-0x22C500 -- top screen 3D left framebuffer 0(240x400x3) (The "3D right first-framebuf" addr stored in the LCD register is set to this, when the 3D is set to "off")
*0x22C800-0x272D00 -- top screen 3D left framebuffer 1(240x400x3)
*0x273000-0x2B9500 -- top screen 3D right framebuffer 0(240x400x3)
*0x2B9800-0x2FFD00 -- top screen 3D right framebuffer 1(240x400x3)
*0x48F000-0x4C7400 -- bottom screen framebuffer 0(240x320x3)
*0x4C7800-0x4FF800 -- bottom screen framebuffer 1(240x320x3)

These LCD framebuffer addresses are not changed by the system when launching regular applications, the application itself handles that if needed. These VRAM framebuffers are cleared when launching regular applications.

OTP Registers

2015-07-14T13:09:43Z

WulfyStylez:

Keys seem to be stored here? Access to this region is disabled once the ARM9 writes 0x2 to [[CONFIG|REG_SYSPROT9]].

Originally the console-unique TWL keyinit + region disable was done by Kernel9. 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 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.
|}

Memory layout

2015-07-14T13:04:17Z

WulfyStylez: /* ARM9 ITCM */

=ARM11 Physical memory regions =
{| class="wikitable" border="1"
|-
! Old 3DS
! Address
! Size
! Description
|-
| style="background: green" | Yes
| 0x00000000
| 0x00010000
| Bootrom (super secret code/data @ 0x8000)
|-
| style="background: green" | Yes
| 0x00010000
| 0x00010000
| Bootrom mirror
|-
| style="background: green" | Yes
| 0x10000000
|?
| [[IO]] memory
|-
| style="background: green" | Yes
| 0x17E00000
| 0x00002000
| MPCore private memory region

|-
| style="background: red" | No
| 0x17E10000
| 0x00001000
| ?
|-
| style="background: green" | Yes
| 0x18000000
| 0x00600000
| VRAM (divided in two banks, VRAM and VRAMB)
|-
| style="background: red" | No
| 0x1F000000
| 0x00400000
| [[New_3DS]] additional memory
|-
| style="background: green" | Yes
| 0x1FF00000
| 0x00080000
| DSP memory
|-
| style="background: green" | Yes
| 0x1FF80000
| 0x00080000
| AXI WRAM
|-
| style="background: green" | Yes
| 0x20000000
| 0x08000000
| FCRAM
|-
| style="background: red" | No
| 0x28000000
| 0x08000000
| [[New_3DS]] FCRAM extension
|-
| style="background: green" | Yes
| 0xFFFF0000
| 0x00010000
| Bootrom mirror
|}

=ARM9 Physical memory regions =
{| class="wikitable" border="1"
|-
! Old 3DS
! Address
! Size
! Description
|-
| style="background: green" | Yes
| 0x00000000
| 0x08000000
| Instruction TCM, repeating each 0x8000 bytes.
|-
| style="background: green" | Yes
| 0x01FF8000
| 0x00008000
| Instruction TCM (Accessed by the kernel and process by this address)
|-
| style="background: green" | Yes
| 0x07FF8000
| 0x00008000
| Instruction TCM (Accessed by bootrom by this address)
|-
| style="background: green" | Yes
| 0x08000000
| 0x00100000
| ARM9-only internal memory (ARM7's internal regions are mapped here as well)
|-
| style="background: red" | No
| 0x08100000
| 0x00080000
| [[New_3DS]] ARM9-only extension, only enabled when a certain [[CONFIG_Registers|CONFIG]] register is set.
|-
| style="background: green" | Yes
| 0x10000000
| 0x08000000
| [[IO]] memory
|-
| style="background: green" | Yes
| 0x18000000
| 0x00600000
| VRAM (divided in two banks, VRAM and VRAMB)
|-
| style="background: green" | Yes
| 0x1FF00000
| 0x00080000
| DSP memory
|-
| style="background: green" | Yes
| 0x1FF80000
| 0x00080000
| AXI WRAM
|-
| style="background: green" | Yes
| 0x20000000
| 0x08000000
| FCRAM
|-
| style="background: red" | No
| 0x28000000
| 0x08000000
| [[New_3DS]] FCRAM extension
|-
| style="background: green" | Yes
| 0xFFF00000
| 0x00004000
| Data TCM (Mapped during bootrom)
|-
| style="background: green" | Yes
| 0xFFFF0000
| 0x00010000
| Bootrom, the main region is at +0x8000, which is disabled during system boot.
|}

==ARM9 MPU regions==
For the below instruction permissions: RO = memory is executable, while None = not-executable.

===NATIVE_FIRM/SAFE_MODE_FIRM ARM9 kernel===
{| class="wikitable" border="1"
|-
! Region
! Address
! Size
! Privileged-mode data permissions
! User-mode data permissions
! Privileged-mode instruction permissions
! User-mode instruction permissions
|-
| 0
| 0xFFFF0000
| 32KB/0x8000
| RO
| None
| RO
| None
|-
| 1
| 0x01FF8000
| 32KB/0x8000
| RW
| RW
| RO
| RO
|-
| 2
| 0x08000000
| 1MB/0x100000. >=[[8.0.0-18|8.0.0-X]]: 2MB/0x200000.
| RW
| RW
| RO
| RO
|-
| 3
| 0x10000000
| 128KB/0x20000
| RW
| RW
| None
| None
|-
| 4
| 0x10100000
| 512KB/0x80000
| RW
| RW
| None
| None
|-
| 5
| 0x20000000
| 128MB/0x8000000. >=[[8.0.0-18|8.0.0-X]]: 256MB/0x10000000.
| RW
| RW
| None
| None
|-
| 6
| 0x08000000
| 128KB/0x20000
| RW
| None
| RO
| None
|-
| 7
| 0x08020000
| <[[3.0.0-5]]: 64KB/0x10000. >=[[3.0.0-5]]: 32KB/0x8000.
| RW
| None
| RO
| None
|}

The above is the MPU region settings setup by the ARM9-kernel in the crt0.

The New3DS ARM9-kernel MPU region settings are the same as the Old3DS MPU region settings for >=[[8.0.0-18|8.0.0-X]].

At the start of the Process9 function executed in kernel-mode via svc7b during firm-launching, it changes some MPU region settings. At the end of that function, before it uses the ARM9/ARM11 entrypoint fields, it disables MPU.

===New3DS [[FIRM|ARM9-loader]]===
{| class="wikitable" border="1"
|-
! Region
! Address
! Size
! Privileged-mode data permissions
! User-mode data permissions
! Privileged-mode instruction permissions
! User-mode instruction permissions
|-
| 0
| 0xFFFF0000
| 32KB/0x8000
| RO
| None
| RO
| None
|-
| 1
| 0x01FF8000
| 32KB/0x8000
| RW
| None
| RO
| None
|-
| 2
| 0x08000000
| 2MB/0x200000
| RW
| None
| RO
| None
|-
| 3
| 0x10000000
| 128KB/0x20000
| RW
| None
| None
| None
|}

MPU regions 4-7 are disabled. Note that the entire ARM9-loader runs in SVC-mode.

===TWL_FIRM/AGB_FIRM ARM9 kernel===
{| class="wikitable" border="1"
|-
! Region
! Address
! Size
! Privileged-mode data permissions
! User-mode data permissions
! Privileged-mode instruction permissions
! User-mode instruction permissions
|-
| 0
| 0xFFFF0000
| 32KB/0x8000
| RO
| None
| RO
| None
|-
| 1
| 0x01FF8000
| 32KB/0x8000
| RW
| RW
| RO
| RO
|-
| 2
| 0x08000000
| 1MB/0x100000. New3DS: 2MB/0x200000.
| RW
| RW
| RO
| RO
|-
| 3
| 0x10000000
| 2MB/0x200000.
| RW
| RW
| None
| None
|-
| 4
| 0x1FF00000
| 512KB/0x80000
| RW
| RW
| None
| None
|-
| 5
| 0x20000000
| 128MB/0x8000000. New3DS: 256MB/0x10000000.
| RW
| RW
| None
| None
|-
| 6
| 0x08000000
| <[[3.0.0-5|3.0.0-X]]: 256KB/0x40000. >=[[3.0.0-5|3.0.0-X]]: 128KB/0x20000
| RW
| None
| RO
| None
|-
| 7
| 0x08080000
| 128KB/0x20000
| RW
| RW
| RO
| RO
|}

==ARM9 ITCM==
{| class="wikitable" border="1"
|-
! ITCM mirror address
! ITCM bootrom mirror address
! Offset
! Size
! Description
|-
| 0x01FF8000
|
| 0x0
| 0x3700
| Uninitialized memory.
|-
| 0x01FFB700
| 0x07FFB700
| 0x3700
| 0x100
| The unprotected ARM9-bootrom code copies code from unprotected bootrom to 0x07FFB700(ITCM mirror) size 0x100, then calls the code at 0x07FFB700. The code located here is the code used for disabling access to the bootroms.
|-
| 0x01FFB800
|
| 0x3800
| 0x4
| This is always 0xDEADB00F.
|-
| 0x01FFB804
|
| 0x3804
| 0x4
| This is the u32 DeviceId.
|-
| 0x01FFB808
|
| 0x3808
| 0x10
| This is the fall-back keyY used for movable.sed keyY when movable.sed doesn't exist in NAND(the last two words here are used on retail for generating console-unique TWL keydata/etc). This is also used for "LocalFriendCodeSeed", etc.
|-
| 0x01FFB818
|
| 0x3818
| 0x1
| ?
|-
| 0x01FFB819
|
| 0x3819
| 0x1
| This is the [[CTCert]] issuer type: 0 = retail "Nintendo CA - G3_NintendoCTR2prod", non-zero = dev "Nintendo CA - G3_NintendoCTR2dev".
|-
| 0x01FFB81A
|
| 0x381A
| 0x6
| ?
|-
| 0x01FFB820
|
| 0x3820
| 0x4
| This is the CTCert ECDSA exponent, this is byte-swapped when *((u8*)(0x01FFB800+0x18)) is >=5.
|-
| 0x01FFB824
|
| 0x3824
| 0x2
| ?
|-
| 0x01FFB826
|
| 0x3826
| 0x1E
| This is the CTCert ECDSA privk.
|-
| 0x01FFB844
|
| 0x3844
| 0x3C
| This is the CTCert ECDSA signature.
|-
| 0x01FFB880
|
| 0x3880
| 0x80
| This is all-zero.
|-
| 0x01FFB900
|
| 0x3900
| 0x200
| This is the 0x200-bytes from NAND sector0.
|-
| 0x01FFBB00
|
| 0x3B00
| 0x200
| This is the 0x200-bytes from the plaintext NAND firm partition FIRM header, read by bootrom.
|-
| 0x01FFBD00
|
| 0x3D00
| 0x200
| Unknown, not used by [[FIRM]]. Probably RSA related going by the data right after this? These are not console-unique.
|-
| 0x01FFBF00
|
| 0x3F00
| 0x100
| This is the RSA-2048 modulo for [[RSA_Registers|RSA]]-engine slot2.
|-
| 0x01FFC000
|
| 0x4000
| 0x100
| This is the RSA-2048 modulo for RSA-engine slot3.
|-
| 0x01FFC100
|
| 0x4100
| 0x800
| Unknown, not console-unique.
|-
| 0x01FFC900
| 0x07FFC900
| 0x4900
| 0x400
| The unprotected ARM9-bootrom copies data to 0x07FFC900(mirror of 0x01FFC900) size 0x400. This data is copied from AXI WRAM, initialized by ARM11-bootrom(the addr used for the src is determined by [[CONFIG_Registers|REG_UNITINFO]]). These are RSA modulus: retailsrcptr = 0x1FFFD000, devsrvptr = 0x1FFFD400.
* The first 0x100-bytes here is the RSA-2048 modulo for the CFA NCCH header, and for the gamecard NCSD header.
* 0x01FFCA00 is the RSA-2048 modulo for the CXI accessdesc signature, written to rsaengine keyslot1 by NATIVE_FIRM.
* 0x01FFCB00 size 0x200 is unknown, probably RSA related, these aren't used by [[FIRM]](these are not console-unique).
|-
| 0x01FFCD00
|
| 0x4D00
| 0x80
| Unknown, not used by [[FIRM]]. This isn't console-unique.
The first 0x10-bytes are checked by the v6.0/v7.0 NATIVE_FIRM keyinit function, when non-zero it clears this block and continues to do the key generation. Otherwise when this block was already all-zero, it immediately returns.
|-
| 0x01FFCD80
|
| 0x4D80
| 0x64
| 0x01FFCD84 size 0x10-bytes is the NAND CID(the 0x64-byte region at 0x01FFCD80 is initialized by Process9 + ARM9-bootrom). The u32 at 0x01FFCDC4 is the total number of NAND sectors, read from a MMC command.
|-
| 0x01FFCDE4
|
| 0x4DE4
| 0x21C
| Uninitialized memory.
|-
| 0x01FFD000
| 0x07FFD000
| 0x5000
| 0x2470
| The unprotected ARM9-bootrom copies 0x1FFFA000(AXIWRAM mem initialized by ARM11-bootrom) size 0x2470 to 0x07FFD000(mirror of 0x01FFD000). This block contains DSi keys.
* 0x1FFD000 is the RSA-1024 modulus for the retail System Menu
* 0x1FFD080 is the RSA-1024 modulus for DSi Wifi firmware and DSi Sound
* 0x1FFD100 is the RSA-1024 modulus for base DSi apps (Settings, Shop, etc.)
* 0x1FFD180 is the RSA-1024 modulus for DSiWare and RSA-signed cartridge headers
* 0x1FFD210 is the keyY for per-console-encrypted ES blocks
* 0x1FFD220 is the keyY for fixed-keyX ES blocks
* 0x1FFD300 is the DSi common (normal)key
* 0x1FFD380 is the first half of the retail keyY for modcrypt crypto "Nintendo"
* 0x1FFD398 is the keyX used for 'Tad' crypto, usually in keyslot 0x02 "Nintendo DS", ..
* 0x1FFD3C8 is the fixed keyY used for eMMC partition crypto (keyslot 0x03)
* 0x1FFD3E0 is the 0x1048-byte Blowfish data for DSi cart crypto
* 0x1FFE420 is the 0x1048-byte Blowfish data for DS cart crypto
|-
| 0x01FFF470
|
| 0x7470
| 0xB90
| Uninitialized memory.
0x01FFFC00 size 0x100-bytes starting with [[9.5.0-22|9.5.0-X]] is the FIRM header used during FIRM-launching.
|}

=[[New_3DS]] physical 0x1F000000 memory=
This area is used by [[QTM Services]](starting at offset 0x200000, size 0x180000). This area is not accessible to the GPU on the old 3DS. The old 3DS and New 3DS GSP module has vaddr->physaddr conversion code for this entire region. On the New 3DS, only the first 0x200000-bytes (half of this memory) are accessible to the GPU.

=Memory map by firmware=
* [[Virtual address mapping FW0B]]
* [[Virtual address mapping FW1F]]
* [[Virtual address mapping FW25]]
* [[Virtual address mapping FW2E]]
* [[Virtual address mapping FW37]]
* [[Virtual address mapping FW38‎]]
* [[Virtual address mapping FW3F]]
* FW49([[9.6.0-24|9.6.0-X]]) ARM11-kernel vmem mapping is identical to FW40([[9.5.0-22|9.5.0-X]]).

* [[Virtual address mapping TWLFIRM04]]

* [[Virtual address mapping New3DS v8.1]]
* [[Virtual address mapping New3DS v9.0]]
* [[Virtual address mapping New3DS v9.2]]

=ARM11 Detailed physical memory map=
18000000 - 18600000: VRAM

1FF80000 - 1FFAB000: Kernel code
1FFAB000 - 1FFF0000: SlabHeap [temporarily contains boot processes]
1FFF0000 - 1FFF1000: ?
1FFF1000 - 1FFF2000: ?
1FFF2000 - 1FFF3000: ?
1FFF3000 - 1FFF4000: ?
1FFF4000 - 1FFF5000: Exception vectors
1FFF5000 - 1FFF5800: Unused?
1FFF5800 - 1FFF5C00: 256-entry L2 MMU table for VA FF4xx000
1FFF5C00 - 1FFF6000: 256-entry L2 MMU table for VA FF5xx000
1FFF6000 - 1FFF6400: 256-entry L2 MMU table for VA FF6xx000
1FFF6400 - 1FFF6800: 256-entry L2 MMU table for VA FF7xx000
1FFF6800 - 1FFF6C00: 256-entry L2 MMU table for VA FF8xx000
1FFF6C00 - 1FFF7000: 256-entry L2 MMU table for VA FF9xx000
1FFF7000 - 1FFF7400: 256-entry L2 MMU table for VA FFAxx000
1FFF7400 - 1FFF7800: 256-entry L2 MMU table for VA FFBxx000
1FFF7800 - 1FFF7C00: MMU table but unused?
1FFF7C00 - 1FFF8000: 256-entry L2 MMU table for VA FFFxx000
1FFF8000 - 1FFFC000: 4096-entry L1 MMU table for VA xxx00000 (CPU 0)
1FFFC000 - 20000000: 4096-entry L1 MMU table for VA xxx00000 (CPU 1)
20000000 - 28000000: Main memory

The entire FCRAM is cleared during NATIVE_FIRM boot. This is probably done by the ARM11 kernel(after loading [[FIRM]] launch parameters from FCRAM)?

== FCRAM memory-regions layout ==
{| class="wikitable" border="1"
! [[Configuration_Memory#APPMEMTYPE|Configmem-APPMEMTYPE]] Value
! Base address relative to FCRAM+0, for APPLICATION mem-region
! Region size, for APPLICATION mem-region
! Base address relative to FCRAM+0, for SYSTEM mem-region
! Region size, for SYSTEM mem-region
! Base address relative to FCRAM+0, for BASE mem-region
! Region size, for BASE mem-region
|-
| 0 (default with regular 3DS kernel, used when the type is not 2-5)
| 0x0
| 0x04000000(64MB)
| 0x04000000
| 0x02C00000
| 0x06C00000
| 0x01400000
|-
| 2
| 0x0
| 0x06000000(96MB)
| 0x06000000
| 0x00C00000
| 0x06C00000
| 0x01400000
|-
| 3
| 0x0
| 0x05000000(80MB)
| 0x05000000
| 0x01C00000
| 0x06C00000
| 0x01400000
|-
| 4
| 0x0
| 0x04800000(72MB)
| 0x04800000
| 0x02400000
| 0x06C00000
| 0x01400000
|-
| 5
| 0x0
| 0x02000000(32MB)
| 0x02000000
| 0x04C00000
| 0x06C00000
| 0x01400000
|-
| 6 (This is the default on New3DS. With [[New_3DS]] kernel this is the type used when the value is not 7)
| 0x0
| 0x07C00000(124MB)
| 0x07C00000
| 0x06400000
| 0x0E000000
| 0x02000000
|-
| 7
| 0x0
| 0x0B200000(178MB)
| 0x0B200000
| 0x02E00000
| 0x0E000000
| 0x02000000
|}

The SYSTEM mem-region size is calculated with: size = FCRAMTOTALSIZE - (APPLICATION_MEMREGIONSIZE + BASE_MEMREGIONSIZE).

Support for type6/7 was [[NCCH/Extended Header|implemented]] in [[NS]] with [[8.0.0-18]], these are only supported in the [[New_3DS]] ARM11-kernel not the regular 3DS kernel. These two types are the only ones supported by the New3DS kernel.

All memory allocated by the kernel itself for kernel use is located under BASE. Most system-modules run under the BASE memregion too.

Free/used memory on [[4.5.0-10]] with Home Menu / Internet Browser, with the default APPMEMTYPE on retail:
{| class="wikitable" border="1"
! Region
! Base address relative to FCRAM+0
! Region size
! Used memory once [[Home Menu]] finishes loading for system boot, on [[4.5.0-10]]
! Used memory with [[Internet Browser]] running instead of [[Home Menu]], on [[4.5.0-10]]
! Free memory once [[Home Menu]] finishes loading for system boot, on [[4.5.0-10]]
! Free memory with [[Internet Browser]] running instead of [[Home Menu]], on [[4.5.0-10]]
|-
| APPLICATION
| 0x0
| 0x04000000
| 0x0
|
| 0x04000000
|
|-
| SYSTEM
| 0x04000000
| 0x02C00000
| 0x01488000
| 0x02A50000
| 0x01778000
| 0x001B0000
|-
| BASE
| 0x06C00000
| 0x01400000
| 0x01202000
| 0x01236000
| 0x001FE000
| 0x001CA000
|}

=ARM11 Detailed virtual memory map=
(valid only for FW0B, see [[#Memory map by firmware|Memory map by firmware]] for subsequent versions)

E8000000 - E8600000: mapped VRAM (18000000 - 18600000)

EFF00000 - F0000000: mapped Internal memory (1FF00000 - 20000000)
F0000000 - F8000000: mapped Main memory

FF401000 - FF402000: mapped ? (27FC7000 - 27FC8000)

FF403000 - FF404000: mapped ? (27FC2000 - 27FC3000)

FF405000 - FF406000: mapped ? (27FBB000 - 27FBC000)

FF407000 - FF408000: mapped ? (27FB3000 - 27FB4000)

FF409000 - FF40A000: mapped ? (27F8E000 - 27F8F000)

FFF00000 - FFF45000: mapped SlabHeap

FFF60000 - FFF8B000: mapped Kernel code

FFFCC000 - FFFCD000: mapped IO [[I2C|I2C]] second bus (10144000 - 10145000)

FFFCE000 - FFFCF000: mapped IO PDC([[LCD]]) (10400000 - 10401000)

FFFD0000 - FFFD1000: mapped IO PDN (10141000 - 10142000)

FFFD2000 - FFFD3000: mapped IO PXI (10163000 - 10164000)

FFFD4000 - FFFD5000: mapped IO PAD (10146000 - 10147000)

FFFD6000 - FFFD7000: mapped IO LCD (10202000 - 10203000)

FFFD8000 - FFFD9000: mapped IO DSP (10140000 - 10141000)

FFFDA000 - FFFDB000: mapped IO XDMA (10200000 - 10201000)

FFFDC000 - FFFE0000: mapped ? (1FFF8000 - 1FFFC000)

FFFE1000 - FFFE2000: mapped ? (1FFF0000 - 1FFF1000)

FFFE3000 - FFFE4000: mapped ? (1FFF2000 - 1FFF3000)

FFFE5000 - FFFE9000: mapped L1 MMU table for VA xxx00000

FFFEA000 - FFFEB000: mapped ? (1FFF1000 - 1FFF2000)

FFFEC000 - FFFED000: mapped ? (1FFF3000 - 1FFF4000)

FFFEE000 - FFFF0000: mapped IO IRQ (17E00000 - 17E02000)

FFFF0000 - FFFF1000: mapped Exception vectors

FFFF2000 - FFFF6000: mapped L1 MMU table for VA xxx00000

FFFF7000 - FFFF8000: mapped ? (1FFF1000 - 1FFF2000)

FFFF9000 - FFFFA000: mapped ? (1FFF3000 - 1FFF4000)

FFFFB000 - FFFFE000: mapped L2 MMU tables (1FFF5000 - 1FFF8000)

==0xFF4XX000==
Each [[KThread|thread]] is allocated a 0x1000-byte page in this region: the first page at 0xFF401000 is for the first created thread, 0xFF403000 for the second thread. This region is used to store the SVC-mode stack for the thread, and thread context data used for context switching. When the IRQ handler, prefetch/data abort handlers, and undefined instruction handler are entered where the SPSR-mode=user, these handlers then store LR+SPSR for the current mode on the SVC-mode stack, then these handlers switch to SVC-mode.

This page does not contain a dedicated block for storing R0-PC(etc). For user-mode, the user-mode regs are instead saved on the SVC-mode stack when IRQs such as timers for context switching are triggered.

Structure of this page, relative to page_endaddr-0xC8:
{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
|-
| 0x0
|
| SVC-mode stack-top. The 0x10-byte SVC-access-control for this thread is also located here, which is checked by the SVC-handler.
|-
| 0x18
| 0x28
| SVC-mode saved registers, stored/loaded during context switches: R4-R9, SL, FP, SP, LR. After loading these registers, the context switch code will jump to the loaded LR.
|-
| 0xC0
| 4
| fpexc from vmrs, used during context switches with the above saved registers.
|}

For NATIVE_FIRM the memory pages for this region are located in FCRAM, however for TWL_FIRM these are located in AXI WRAM. For TWL_FIRM v6704 the first thread's page for this region is located at physical address 0x1FF93000, the next one at 0x1FF92000, etc.

=ARM11 User-land memory regions=
==NATIVE_FIRM/SAFE_MODE_FIRM Userland Memory==
{| class="wikitable" border="1"
|-
! Virtual Address Base
! Physical Address Base
! Region Max Size
! Address-range available for svcMapMemoryBlock
! Description
|-
| 0x00100000 / 0x14000000
|
| 0x03F00000
| No
| The [[ExeFS]]:/.code is loaded here, executables must be loaded to the 0x00100000 region when the exheader "special memory" flag is clear. The 0x03F00000-byte size restriction only applies when this flag is clear. Executables are usually loaded to 0x14000000 when the exheader "special memory" flag is set, however this address can be arbitrary.
|-
| 0x04000000
| ?
| ?
| No
| Used for mapping buffers during IPC, see [[IPC Command Structure]].
|-
| 0x08000000
| Main stack physaddr - <heap size for the allocated vaddr 0x08000000 memory>
| 0x08000000
| Yes
| Heap mapped by [[SVC|ControlMemory]]
|-
| 0x10000000-StackSize
| .bss physical address - total stack pages
| StackSize from process exheader
|
| Stack for the main-thread, initialized by the ARM11 kernel. The StackSize from the exheader is usually 0x4000, therefore the stack-bottom is usually 0x0FFFC000. The stack for the other threads is normally located in the process .data section however this can be arbitrary.
|-
| 0x10000000
|
| 0x04000000
| Yes
| [[SVC|Shared]] memory
|-
| 0x14000000
| FCRAM+0
| 0x08000000
| No
| Can be mapped by [[SVC|ControlMemory]], this is used for processes' [[SVC|LINEAR]]/GSP heap.
|-
| 0x1E800000
| 0x1F000000
| 0x00400000
| No
| [[New_3DS]] additional memory, access to this is specified by the exheader. Added with [[8.0.0-18]], see above section regarding this memory.
|-
| 0x1EC00000
| 0x10100000
| 0x01000000
| No
| [[IO]] registers, the mapped IO pages which each process can access is specified in the [[NCCH#CXI|CXI]] exheader.(Applications normally don't have access to registers in this range)
|-
| 0x1F000000
| 0x18000000
| 0x00600000
| No
| VRAM, access to this is specified by the exheader.
|-
| 0x1FF00000
| 0x1FF00000
| 0x00080000
| No
| DSP memory, access to this is specified by the exheader.
|-
| 0x1FF80000
| FCRAM memory page allocated by the ARM11 kernel.
| 0x1000
| No
| [[Configuration Memory]], all processes have read-only access to this.
|-
| 0x1FF81000
| FCRAM memory page allocated by the ARM11 kernel.
| 0x1000
| No
| [[Configuration Memory|Shared]] page, all processes have read-access to this. Write access to this is specified by the exheader "Shared page writing" kernel flag.
|-
| 0x1FF82000
| ?
| ?
| No
| [[Thread Local Storage]]
|-
| 0x30000000
| FCRAM+0
| 0x08000000(Old3DS) / 0x10000000([[New_3DS]])
| No
| This LINEAR memory mapping was added with [[8.0.0-18]], see [[SVC#enum_MemoryOperation|here]]. This replaces the original 0x14000000 mapping, for system(memory-region=BASE)/newer titles. The Old3DS kernel uses size 0x08000000 for LINEAR-memory address range checks, while the New3DS kernel uses size 0x10000000 for those range checks. Old3DS/New3DS system-module code doing vaddr->phys-addr conversion uses size 0x10000000.
|-
| 0x20000000 / 0x40000000
|
|
|
| This is the end-address of userland memory, memory under this address is process-unique. Memory starting at this address is only accessible in privileged-mode. This address was changed from 0x20000000 to 0x40000000 with [[8.0.0-18]].
|}

All executable pages are read-only, and data pages have the execute-never permission set. Normally .text from the loaded ExeFS:/.code is the only mapped executable memory. Executable [[RO Services|CROs]] can be loaded into memory, once loaded the CRO .text section memory page permissions are changed via [[SVC|ControlProcessMemory]] from RW- to R-X. The address and size of each ExeFS:/.code section is stored in the exheader, the permissions for each section is: .text R-X, .rodata R--, .data RW-, and .bss RW-. The loaded .code is mapped to the addresses specified in the exheader by the ARM11 kernel. The stack permissions is initialized by the ARM11 kernel: RW-. The heap permissions is normally RW-.

All userland memory is mapped with RW permissions for privileged-mode. However, normally the ARM11 kernel only uses userland read/write instructions(or checks that the memory can be written from userland first) for accessing memory specified by [[SVC|SVCs]].

Processes can't directly access memory for other processes. When service [[Services API|commands]] are used, the kernel maps memory in the destination process for input/output buffers, where the addresses in the command received by the process is replaced by this mapped memory. When this is an input buffer, the buffer data is copied to the mapped memory. When this is an output buffer, the data stored in the mapped memory is copied to the destination buffer specified in the command.

The physical address which memory for the application memory-type is mapped to begins at FCRAM+0, the total memory allocated for this memory-type is stored in [[Configuration_Memory]]. Applications' .text + .rodata + .data under the application memory-type is mapped at FCRAM + APPMEMALLOC - (aligned page-size for .text + .rodata + .data). The application .bss is mapped at CODEADDR - .bss size aligned down to the page size.

==TWL_FIRM Userland Memory==
{| class="wikitable" border="1"
|-
! Virtual Address Base
! Physical Address Base
! Size
! Description
|-
| 0x00100000
| 0x1FFAB000 (with newer TWL_FIRM such as v6704 this is located at 0x1FFAC000)
| 0x00055000
| Code + .(ro)data copied from the process 0x00300000 region is located here(.bss is located here as well).
|-
| 0x00155000
| 0x18555000
| 0x000AB000
|
|-
| 0x00200000
| 0x18500000
| 0x00100000
|
|-
| 0x00300000
| 0x24000000
| 0x04000000
| The beginning of the ARM11 process .text is located here.
|-
| 0x08000000
| 0x20000000
| 0x07E00000
|
|-
| 0x1EC00000
| 0x10100000
| 0x00400000
| [[IO]]
|-
| 0x1F000000
| 0x18000000
| 0x00600000
| VRAM
|-
| 0x1FF00000
| 0x1FF00000
| 0x00080000
| This is mapped to the DSP memory.
|}

The above regions are mapped by the ARM11 kernel. Later when the ARM11 process uses [[SVC|svcKernelSetState]] with type4, the kernel unmaps(?) the following regions: 0x00300000..0x04300000, 0x08000000..0x0FE00000, and 0x10000000..0xF8000000.

=== Detailed TWL_FIRM ARM11 Memory ===
{| class="wikitable" border="1"
|-
! Process Virtual Address
! Physical Address
! Size
! Description
|-
| 0x08000000
| 0x20000000
| 0x01000000*4
| DS(i) 0x02000000 RAM. Vaddr = (DSRAMOffset*4) + 0x08000000, where DSRAMOffset is DSRAMAddr-0x02000000.
|-
| 0x0FC00000
| 0x27C00000
|
| Loaded SRL binary, initially the dev DSi launcher SRL is located here(copied here by the ARM11 process).
|-
| 0x0FD00000
| 0x27D00000
|
| The data located here is copied to here by the ARM11 process. The data located here is a TWL NAND [http://dsibrew.org/wiki/Bootloader bootloader] image, using the same format+encryption/verification methods as the DSi NAND bootloader(stage2). The keyX for this bootloader keyslot is initially set to the retail DSi key-data, however when TWL_FIRM is launched this keyX key-data is replaced with a separate keyX. TWL_FIRM can use either the retail DSi bootloader RSA-1024 modulo, or a seperate modulo: normally only the latter is used(the former is only used when loading the image from FS instead of FCRAM). When using the image from FCRAM(default code-path), TWL_FIRM will not calculate+check the hashes for the bootloader code binaries(this is done when loading from FS however).
|-
| 0x0FDF7000
| 0x27DF7000
| 0x1000
| SRL header
|}

= System memory details =
0xFFFF9000 Pointer to the current KThread instance
0xFFFF9004 Pointer to the current KProcess instance
0xFFFF9008 Pointer to the current KScheduler instance
0xFFFF9010 Pointer to the last KThread to encounter an exception

0x8000040 Pointer to the current KThread instance on the ARM9
0x8000044 Pointer to the current KProcess instance on the ARM9
0x8000048 Pointer to the current KScheduler instance on the ARM9

= Handles =
The handle 0xFFFF8001 is a reference to the current KProcess.
The handle 0xFFFF8000 is a reference to the current KThread.

= IO Process/Kernel virtual addressing equivalence =
It seems an IO register's process virtual address can be calculated by adding 0xEB00000 to its physical address.

= VRAM Map While Running System Applets =
*0x1E6000-0x22C500 -- top screen 3D left framebuffer 0(240x400x3) (The "3D right first-framebuf" addr stored in the LCD register is set to this, when the 3D is set to "off")
*0x22C800-0x272D00 -- top screen 3D left framebuffer 1(240x400x3)
*0x273000-0x2B9500 -- top screen 3D right framebuffer 0(240x400x3)
*0x2B9800-0x2FFD00 -- top screen 3D right framebuffer 1(240x400x3)
*0x48F000-0x4C7400 -- bottom screen framebuffer 0(240x320x3)
*0x4C7800-0x4FF800 -- bottom screen framebuffer 1(240x320x3)

These LCD framebuffer addresses are not changed by the system when launching regular applications, the application itself handles that if needed. These VRAM framebuffers are cleared when launching regular applications.

9.9.0-26

2015-07-14T03:29:39Z

WulfyStylez: Created page with "The Old3DS+New3DS 9.9.0-26 system update was released on July 13, 2015 for all available regions. == Change-log == Official change-log: * Further improvements to overall system ..."

The Old3DS+New3DS 9.9.0-26 system update was released on July 13, 2015 for all available regions.

== Change-log ==
Official change-log:
* Further improvements to overall system stability, system security, and other minor adjustments have been made to enhance the user experience

==System Titles==
All of the following titles were updated for Old3DS+New3DS: [[Home Menu]], [[CVer]], and [[NVer]].

Both platforms' browsers ([[Internet_Browser|spider and SKATER]]) were updated. The wording in the changelog would seem to imply that webkit received bugfixes or was otherwise updated.

==See Also==
System update reports:

News/Archive

2015-07-14T03:17:51Z

WulfyStylez:

*'''23 March 15''' Nintendo released system update [[9.6.0-24]].
*'''2 March 15''' Nintendo released system update [[9.5.0-23]].
*'''15 February 15''' WinterMute released [http://devkitpro.org/viewtopic.php?f=13&t=8409 devkitARM release 44].
*'''2 February 15''' Nintendo released system update [[9.5.0-22]], which fixes [[3DS System Flaws|firmlaunch-hax]].
*'''16 January 15''' smea released regionthree [https://github.com/smealum/regionthree/blob/master/README.md], enabling region free gaming on latest firmware.
*'''24 December 14''' smea released [[Ninjhax]] 1.1 ('''NOT''' a fix for firmware [[9.3.0-21]] or [[9.4.0-21]]).
*'''11 December 14''' Nintendo released system update [[9.4.0-21]].
*'''8 December 14''' Nintendo released system update [[9.3.0-21]], which fixes [[3DS System Flaws|rohax]].
*'''20 November 14''' smea released [[Ninjhax]], the first public [[Homebrew Exploits|homebrew exploit]] compatible with system-versions [[4.0.0-7]]-[[9.2.0-20]].
*'''29 October 14''' Nintendo released system update [[9.2.0-20]].
*'''10 October 14''' Nintendo released system update [[9.1.0-20J]].
*'''6 October 14''' Nintendo released system update [[9.0.0-20]].
*'''29 August 14''' Nintendo announced [[New 3DS]].
*'''7 August 14''' Nintendo released system update [[8.1.0-19]].
*'''24 July 14''' Nintendo released system update [[8.1.0-18]].
*'''7 July 14''' Nintendo released system update [[8.0.0-18]].
*'''12 May 14''' Nintendo released system update [[7.2.0-17]].
*'''26 February 14''' Nintendo released system update [[7.1.0-16]].
*'''22 January 14''' Nintendo released system update [[7.1.0-15]].
*'''19 December 13''' Nintendo released system update [[7.1.0-14]].
*'''9 December 13''' Nintendo released system update [[7.0.0-13]].
*'''13 September 13''' Nintendo released system update [[6.3.0-12]].
*'''20 August 13''' [[3DSExplorer|3DSExplorer v1.5.3]] updated by [[User:Elisherer|Elisherer]] (Enable trimming NCSD)
*'''6 August 13''' Nintendo released system update [[6.2.0-12]].
*'''11 July 13''' Nintendo released system update [[6.1.0-12U]] for only USA.
*'''27 June 13''' Nintendo released system update [[6.1.0-11]] (6.1.0-12 for all regions except USA).
*'''17 June 13''' Nintendo released system update [[6.0.0-11]] (6.0.0-12 for all regions except USA).
*'''4 April 13''' Nintendo released system update [[5.1.0-11]].
*'''25 March 13''' Nintendo released system update [[5.0.0-11]].
*'''14 January 13''' [[3DSExplorer|3DSExplorer v1.5.1]] updated by [[User:Elisherer|Elisherer]]
*'''4 December 12''' Nintendo released system update [[4.5.0-10]].
*'''1 December 12''' [[3DSExplorer|3DSExplorer v1.4]] updated by [[User:Elisherer|Elisherer]]
*'''2 November 12''' Added page for [[Fundraiser|Chip decapping fundraiser]]
*'''8 January 13''' [[3DSExplorer|3DSExplorer v1.5]] updated by [[User:Elisherer|Elisherer]]
*'''23 September 12''' [[005tools|005tools v0.1b]] by [[User:McHaggis|McHaggis]]
*'''19 September 12''' Nintendo released system update [[4.4.0-10]].
*'''17 August 12''' Nintendo released New Super Mario Bros. 2, the first 3DS title released simultaneously in stores and as an [[eShop]] download.
*'''28 July 12''' [[3DSExplorer|3DSExplorer v1.3]] (modified by 3DSGuy) updated by [[User:Elisherer|Elisherer]]
*'''24 July 12''' Nintendo released system update [[4.3.0-10]].
*'''26 June 12''' Nintendo released system update [[4.2.0-9]].
*'''19 May 12''' [[3DSExplorer|3DSExplorer v1.2.1]] updated by [[User:Elisherer|Elisherer]]
*'''15 May 12''' Nintendo released its first implementation of 3DS '[[Title list#0004000E - Add-on Content|Add-on Content]]' with the Mario Kart 1.1 update.
*'''14 May 12''' Nintendo released system update [[4.1.0-8]].
*'''24 April 12''' Nintendo released system update [[4.0.0-7]].
*'''08 February 12''' [[CiTRUS|CiTRUS v0.2]] updated by [[User:Xcution|Xcution]]
*'''04 February 12''' [[CiTRUS|CiTRUS v0.1]] released by [[User:Xcution|Xcution]]
*'''02 February 12''' [[3DSExplorer|3DSExplorer v1.2]] updated by [[User:Elisherer|elisherer]]
*'''26 January 12''' [[Crappy Tiny Reader|CTR - Crappy Tiny Reader v0.07]] updated by [[User:PsyKopaT|PsyKo]]
*'''05 January 12''' [[Crappy Tiny Reader|CTR - Crappy Tiny Reader v0.06]] updated by [[User:PsyKopaT|PsyKo]]
*'''21 December 11''' Nintendo released system update [[3.0.0-6]]
*'''21 December 11''' [[3DSExplorer|3DSExplorer v1.1.1]] updated by [[User:Elisherer|elisherer]]
*'''7 December 11''' [[3DSExplorer|3DSExplorer v0.96]] updated by [[User:Elisherer|elisherer]]
*'''4 September 11''' [[3DSViewer|3DSViewer v0.1]] released by [[User:Elisherer|elisherer]]
*'''1 August 11''' [[3DS Save DeEncrypter3DS|Save DeEncrypter v1.0]] released by [[User:Blite|Blite]]
*'''25 July 11''' Nintendo released system update [[2.1.0-4]].
*'''15 June 11''' Nintendo released system update [[2.1.0-3]].
*'''6 June 11''' Nintendo released system update [[2.0.0-2]].
*'''6 April 11''' [[DSaveManager|DSaveManager v0.1]] released by [[User:Crediar|crediar]]
*'''4 April 11''' [[3DSaveTool|3DSaveTool v0.2b]] released by [[User:Crediar|crediar]]
*'''2 April 11''' [[3DSaveTool|3DSaveTool v0.1]] released by [[User:Crediar|crediar]]
*'''28 March 11''' Fixed 3DBrew wiki issues, now fully operational!
*'''18 March 11''' 3DBrew launched.

== 3DBrew International ==
Our community is an international community.

We have freedom, and we will express it in our language (but you have to write it in English before ;)!

News

2015-07-14T03:16:33Z

WulfyStylez:

<noinclude>
==Adding an item==
* Log in to the wiki. Editing is disabled if you don't have an account.
* Add the news event to the top of the list, using this format for the date: <tt><nowiki>'''</nowiki>{{#time: d F y}}<nowiki>''' </nowiki></tt>. Please include the application's creator, version number, and a link to a page on 3DBrew about the application. No external links please.
* '''Move the last entry to the [[:News/Archive|news archive]]. There should be no more than 4 entrees in the list.'''

==Archives==
For older news, see the [[:News/Archive|news archive]].

=== News ===
</noinclude>
*'''13 July 15''' Nintendo released system update [[9.9.0-26]].
*'''1 June 15''' Nintendo released system update [[9.8.0-25]].
*'''03 May 15''' smea released regionFOUR [https://github.com/smealum/regionFOUR/blob/master/README.md], enabling region free gaming on latest firmware. (again)
*'''20 April 15''' Nintendo released system update [[9.7.0-25]].

EShop

2015-07-04T23:01:43Z

WulfyStylez: the entire link actually varies between regions

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.

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

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 Demo || ADA/B/C || 0004000200030c01
|-
| ESHOP://50010000007870.PEAALL000000 || EUR || Crush 3D || A??P || 00040002
|-
| ESHOP://50010000008009.PEAALL000000 || EUR || Resident Evil Revelations Demo || ABRE || 000400020005ee01
|-
| ESHOP://50010000008123.J00101Z00095 || JPN || Rhythm Thief And The Emperor's Treasure Demo || ARTJ || 00040002
|-
| ESHOP://50010000008404.PEAALL000000 || EUR || Mario And Sonic At The London 2012 Olympic Games Demo || ACMP [http://mediacontent.nintendo-europe.com/NOE/images/game_content/ACMP-MarioAndSonicAtTheLondon2012OlympicGames-QRCode-EA_ALL_000_001.bmp] || 00040002
|-
| ESHOP://50010000008447.J00101Z00094 || JPN || Resident Evil Revelations Demo || ABRJ || 00040002
|-
| ESHOP://50010000008449.J00101Z00082 || JPN || Swapnote || JFRJ ||?
|-
| ESHOP://50010000008561 || USA || Swapnote || JFRE || 0004000000051700
|-
| ESHOP://50010000008647.J00101Z00096 || JPN || Metal Gear Solid Snake Eater 3D Demo || AMGJ || 0004000200048101
|-
| ESHOP://50010000008648.J00101Z00097 || JPN || Theatrythm Final Fantasy || ATHJ ||?
|-
| ESHOP://50010000008782.PEAALL000000 || EUR || Metal Gear Solid Snake Eater 3D Demo || AMGE || 0004000200082401
|-
| ESHOP://50010000008842.PEAALL000000 || EUR || Rhythm Thief And The Emperor's Treasure Demo || ARTP [http://mediacontent.nintendo-europe.com/NOE/images/game_content/ARTP-RhythmThief_TheEmperorsTreasure-QRCode-EA_ALL_000_001.bmp] || 00040002
|-
| ESHOP://50010000009084.J00101Z00121 || JPN || Hatsune Miku And Future Stars: Project Mirai Demo || AM9J || 00040002
|-
| ESHOP://50010000009102.J00101Z00106 || JPN || Denpa Ningen RPG || JD8J ||?
|-
| ESHOP://50010000009161.J00101Z00118 || JPN || Dillon's Rolling Western || JAMJ || 00040000
|-
| ESHOP://50010000009261 || USA || Dillon's Rolling Western || JAME? || 00040000
|-
| ESHOP://50010000009401.J00101Z00120 || JPN || Kingdom Hearts 3D Video Download || JZ8J ||?
|-
| ESHOP://50010000009403.J00101Z00119 || JPN || DQM 3D Video Download || JZ7J ||?
|-
| ESHOP://50010000009575.PEAALL000000 || EUR || Kid Icarus: Of Myths And Monsters (Virtual Console) ||? ||?
|-
| ESHOP://50010000009846 || USA || Ketzal's Corridors ||? ||?
|}

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

EShop

2015-07-04T22:30:37Z

WulfyStylez: eShop music format stuff (captcha is broken for me, sorry for bad link)

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.

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

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 Demo || ADA/B/C || 0004000200030c01
|-
| ESHOP://50010000007870.PEAALL000000 || EUR || Crush 3D || A??P || 00040002
|-
| ESHOP://50010000008009.PEAALL000000 || EUR || Resident Evil Revelations Demo || ABRE || 000400020005ee01
|-
| ESHOP://50010000008123.J00101Z00095 || JPN || Rhythm Thief And The Emperor's Treasure Demo || ARTJ || 00040002
|-
| ESHOP://50010000008404.PEAALL000000 || EUR || Mario And Sonic At The London 2012 Olympic Games Demo || ACMP [http://mediacontent.nintendo-europe.com/NOE/images/game_content/ACMP-MarioAndSonicAtTheLondon2012OlympicGames-QRCode-EA_ALL_000_001.bmp] || 00040002
|-
| ESHOP://50010000008447.J00101Z00094 || JPN || Resident Evil Revelations Demo || ABRJ || 00040002
|-
| ESHOP://50010000008449.J00101Z00082 || JPN || Swapnote || JFRJ ||?
|-
| ESHOP://50010000008561 || USA || Swapnote || JFRE || 0004000000051700
|-
| ESHOP://50010000008647.J00101Z00096 || JPN || Metal Gear Solid Snake Eater 3D Demo || AMGJ || 0004000200048101
|-
| ESHOP://50010000008648.J00101Z00097 || JPN || Theatrythm Final Fantasy || ATHJ ||?
|-
| ESHOP://50010000008782.PEAALL000000 || EUR || Metal Gear Solid Snake Eater 3D Demo || AMGE || 0004000200082401
|-
| ESHOP://50010000008842.PEAALL000000 || EUR || Rhythm Thief And The Emperor's Treasure Demo || ARTP [http://mediacontent.nintendo-europe.com/NOE/images/game_content/ARTP-RhythmThief_TheEmperorsTreasure-QRCode-EA_ALL_000_001.bmp] || 00040002
|-
| ESHOP://50010000009084.J00101Z00121 || JPN || Hatsune Miku And Future Stars: Project Mirai Demo || AM9J || 00040002
|-
| ESHOP://50010000009102.J00101Z00106 || JPN || Denpa Ningen RPG || JD8J ||?
|-
| ESHOP://50010000009161.J00101Z00118 || JPN || Dillon's Rolling Western || JAMJ || 00040000
|-
| ESHOP://50010000009261 || USA || Dillon's Rolling Western || JAME? || 00040000
|-
| ESHOP://50010000009401.J00101Z00120 || JPN || Kingdom Hearts 3D Video Download || JZ8J ||?
|-
| ESHOP://50010000009403.J00101Z00119 || JPN || DQM 3D Video Download || JZ7J ||?
|-
| ESHOP://50010000009575.PEAALL000000 || EUR || Kid Icarus: Of Myths And Monsters (Virtual Console) ||? ||?
|-
| ESHOP://50010000009846 || USA || Ketzal's Corridors ||? ||?
|}

* 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 the following format:

https:// a248.e.akamai.net/f/248/103046/10m/npdl.c.app.nintendowifi.net/p01/nsa/CtfKXACbUPl8s7lk/BGM1/REGION_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.

SpotPass

2015-06-14T10:27:57Z

WulfyStylez: /* Content Container */

'''SpotPass''' is a Nintendo 3DS feature that allows the 3DS to automatically download content, notifications, and software when it's in standby mode.(SpotPass may download/upload some content while the 3DS is in "active" mode, but *only* if the currently active app uses SpotPass) SpotPass can upload content as well. Software downloaded with SpotPass is stored on SD card.

SpotPass Internet communications are mostly HTTPS transfers.

In System Settings, you can disable SpotPass automatic title downloading, but it states that important software will still downloaded.(This only disables downloading of free titles via SpotPass)

'nasc.nintendowifi.net' confirmed usages:(not SpotPass related)

*Friends List applet requires this server to be 'Online' (most likely the reason for regular requests to this server)
*Required for initialization of [[eShop]], (for first time eShop users). Not required for using eShop after first use.

Every time the system connects to the wifi AP, the BOSS(SpotPass) module itself will download the cleartext xml policylist: "https://nppl.c.app.nintendowifi.net/p01/policylist/3/<countrycode>". This policylist contains a list of SpotPass tasks for certain titles. This policylist can control whether the specified tasks are processed at all. The default user-agent used for SpotPass HTTPS requests(including this policylist) is: "PBOS-5.0/<printed hex u64 [[CfgS:GetLocalFriendCodeSeed|LocalFriendCodeSeed]]>-<hex u64 obtained via the friends service>/<text [[CVer|system]] [[NVer|version]]>/<unknown decimal value>/0". No user-agent is used for plaintext HTTP requests with SpotPass.

In some cases the BOSS module will add the following URL parameter to HTTPS requests, when connected to a [[Nintendo Zone]] AP: "ap=<NZoneApNum>".

== Titles Spotpass usage ==
{| class="wikitable"
|-
! Title
! Description
|-
| [[Home Menu]]
| Home Menu uses SpotPass for system notifications, and for uploading data from home-menu shared extdata.
|-
| [[System Settings]]
| System Settings uses SpotPass for uploading data, with this URL: https://npul.c.app.nintendowifi.net/p01/recv/<RegionID>/sendcfg This RegionID is separate from the RegionIDs home-menu uses.
|-
| ?
| Unknown log data is uploaded with this URL: https://logus-p.est.c.app.nintendowifi.net/LogServer_us_live/Upload
|}

== Automatic System Update Download ==
See [[Automatic System Update Download]].

== Content Container ==

SpotPass content can use this container to encrypt the payload and sign it, however SpotPass also supports downloading raw content without this container. The cleartext content is stored in [[extdata]]. The format of these headers is big-endian.

=== BOSS Header ===
{| class="wikitable"
|-
! Offset
! Length
! Description
|-
| 0x0
| 0x4
| Magic Number "boss"
|-
| 0x4
| 0x4
| Magic Number 0x10001
|-
| 0x8
| 0x4
| Big-endian filesize
|-
| 0xC
| 0x8
| u64 release date (UNIX timestamp)
|-
| 0x14
| 0x2
| Must always be 0x1
|-
| 0x16
| 0x2
| Padding
|-
| 0x18
| 0x2
| Content header hash type, always 0x2 for SHA-256
|-
| 0x1A
| 0x2
| Content header RSA size, always 0x2 for RSA-2048 (X<<7)
|-
| 0x1C
| 0xC
| First 12 bytes of the CTR
|}

Data following the BOSS header is encrypted with AES-CTR. The first 12 bytes of the CTR are from offset 0x1C of the header, while the last word of the CTR in big-endian is 0x1. The CTR from the header is random per file, and an unique random CTR is used each time the content is updated. The cleartext data begins with the content header.

=== Content Header ===
{| class="wikitable"
|-
! Offset
! Length
! Description
|-
| 0x0
| 0x10
| ?
|-
| 0x10
| 0x2
| FileID used for the extdata filename
|-
| 0x12
| 0x20
| SHA-256 hash
|-
| 0x32
| 0x100
| RSA-2048 signature over the above hash
|}

The first 0x10-bytes are all-zero except the first byte which is usually 0x80. It's unknown what the first 0x10-bytes are used for.

The hash at offset 0x12 hashes the 0x12-byte data at offset 0x0 followed by a zero u16. The RSA signature is signed by Nintendo. Following this header is the actual content payload, which is written to a cleartext file under the [[extdata]] /boss directory. The data following the payload header is written to extdata, but it's unknown what data is written to the extdata file before the content payload.

=== Payload Content Header ===
{| class="wikitable"
|-
! Offset
! Length
! Description
|-
| 0x0
| 0x8
| ProgramID
|-
| 0x8
| 0x4
| Usually zero?
|-
| 0xC
| 0x4
| Usually 0x10001? (observed 0x20001 in eShop strings)
|-
| 0x10
| 0x4
| Size of the payload after this header
|-
| 0x14
| 0x4
| Extdata FileID
|-
| 0x18
| 0x4
| ?
|-
| 0x1C
| 0x20
| SHA-256 hash, unknown what this hashes
|-
| 0x3C
| 0x100
| RSA-2048 signature over the previous SHA-256 hash
|}

This signature is signed by Nintendo with the same key-pair as the content header.

[[Category:Nintendo Software]]

CIA

2015-06-14T04:44:53Z

WulfyStylez: /* CIA Header */

[[Category:File formats]]
== Overview ==
CIA stands for '''C'''TR '''I'''mportable '''A'''rchive. This format allows the installation titles to the 3DS. CIA files and titles on [[Title list|Nintendo's CDN]] contain identical data. As a consequence, valid CIA files can be generated from CDN content. This also means CIA files can contain anything that titles on Nintendo's CDN can contain.

Under normal circumstances CIA files are used where downloading a title is impractical or not possible. Such as distributing a [[Download Play]] child, or installing forced Gamecard updates. Those CIA(s) are stored by the titles in question, in an auxiliary [[NCCH#CFA|CFA]] file.

Development Units, are capable of manually installing CIA files via the [[3DS Development Unit Software#Dev Menu|Dev Menu]].

== Format ==

This is the current version of the CIA format, it was finalised in late 2010. (Older versions of the CIA format can be viewed on the [[Talk:CIA|Talk]] page)

The CIA format has a similar structure to the [http://wiibrew.org/wiki/Wad WAD format].

The file is represented in little-endian.

The data is aligned in 64 byte blocks (if a content ends at the middle of the block, the next content will begin from a new block).

=== CIA Header ===

{| class="wikitable" border="1"
|-
! START
! SIZE
! DESCRIPTION
|-
| 0x00
| 0x04
| Archive Header Size (Usually = 0x2020 bytes)
|-
| 0x04
| 0x02
| Type
|-
| 0x06
| 0x02
| Version
|-
| 0x08
| 0x04
| Certificate chain size
|-
| 0x0C
| 0x04
| [[Ticket]] size
|-
| 0x10
| 0x04
| [[TMD]] file size
|-
| 0x14
| 0x04
| Meta size (0 if no Meta data is present)
|-
| 0x18
| 0x08
| Content size
|-
| 0x20
| 0x2000
| Content Index
|}

The order of the sections in the CIA file:
* certificate chain
* Ticket
* TMD file data
* Content file data
* Meta file data (Not a necessary component)

The contents (NCCH/SRL) are encrypted using 128-bit AES-CBC. The encryption uses the decrypted titlekey from the [[Ticket#Structure|ticket]], and the content index from the TMD padded with zeros as the IV.

=== Certificate Chain ===

There are three [[Certificates|certificates]] in this chain:

{| class="wikitable" border="1"
|-
! CERTIFICATE
! SIGNATURE TYPE
! RETAIL CERT NAME
! DEBUG CERT NAME
! DESCRIPTION
|-
| CA
| RSA-4096
| CA00000003
| CA00000004
| Used to verify the Ticket/TMD Certificates
|-
| Ticket
| RSA-2048
| XS0000000c
| XS00000009
| Used to verify the Ticket signature
|-
| TMD
| RSA-2048
| CP0000000b
| CP0000000a
| Used to verify the TMD signature
|}

The CA certificate is issued by 'Root', the public key for which is stored in NATIVE_FIRM.

=== Meta ===

The structure of this data is as follows:

{| class="wikitable" border="1"
|-
! START
! SIZE
! DESCRIPTION
|-
| 0x00
| 0x180
| Title ID dependency list - Taken from the application's [[NCCH#Extended Header|ExHeader]]
|-
| 0x180
| 0x180
| Reserved
|-
| 0x300
| 0x4
| Core Version
|-
| 0x304
| 0xFC
| Reserved
|-
| 0x400
| 0x36C0
| [[SMDH|Icon Data]](.ICN) - Taken from the application's [[ExeFS]]
|}

Obviously this section is not present in TWL CIA files, or any other CIA file which does not contain a [[NCCH#CXI|CXI]].

== Tools ==

* [https://github.com/3dshax/ctr/tree/master/ctrtool ctrtool] - Reading/Extraction of CIA files. This can only decrypt the title-key for development CIAs, since retail CIAs use the [[AES]] hardware key-scrambler for the common-key keyslot.

* [https://github.com/ctrdev/ctrsdk/tree/master/tools/make_cia make_cia] - Generating CIA files. Requires CommonKey and ticket/TMD RSA-2048 private exponents.

* [https://github.com/ctrdev/ctrsdk/tree/master/tools/make_cdn_cia make_cdn_cia] - (CMD)(Windows/Linux) Generates CIA files from CDN Content

== Title Key Encryption ==

The unencrypted Title Key is used to encrypt the data in a CIA. The encrypted Title Key of a CIA can be found at offset 0x1BF in a CIA's Ticket.
Each Title Key is encrypted with AES-CBC to get the encrypted Title Key.

To encrypt an unencrypted title key, you need:

* Common key (as byte array)
* Title ID (as ulong)
* (and of course the unencrypted title key you want to encrypt) (as byte array)

The title key encryption process starts by converting the ulong (Title ID) into a byte array using by retrieving the bytes of the Title ID using BitConverter.GetBytes().
If the converted bytes (title ID) are in Little Endian, reverse those bytes. (in C# it would be Array.Reverse(byte_array_from_bitconverter))
This process makes the Title Key encryption IV.

Next, after you've gotten your Title Key's IV, you can start your cryptography transformation. Using AESManaged, where:

Key = Common Key

IV = the byte array found in the conversion process above

Mode = CipherMode.CBC

Create the encryptor (AesManaged.CreateEncryptor(key, iv)) where the key and IV are both the same as above.

Then, create a CryptoStream and a MemoryStream. The Crypto stream should start with the arguments (memorystream, aes_transform_from_above, CryptoStreamMode.Write).

Write to the CryptoStream where buffer=unencrypted_titlekey, offset=0, and count=the length of the unencrypted title key.

Use FlushFinalBlock() on the CryptoStream.

Finally, then, the encrypted title key will be available from your memory
stream. (to output the calculated encrypted title key as a byte array, you can use memorystream.ToArray(), for example)

Example function: (C#)

<pre>
public static byte[] EncryptMyTitleKey(byte[] commonKey, byte[] titleKey, ulong titleId)
{
// Make encryption IV
byte[] titleidasbytes = new byte[0x10];
for (int i = 0; i < 0x10; i++)
{
titleidasbytes[i] = 0;
}
byte[] bitBytes = BitConverter.GetBytes(titleId);
if (BitConverter.IsLittleEndian)
{
Array.Reverse(bitBytes);
}
bitBytes.CopyTo(titleidasbytes, 0);
// Encrypt
ICryptoTransform transform = new AesManaged { Key = commonKey, IV = titleidasbytes, Mode = CipherMode.CBC }.CreateEncryptor(commonKey, titleidasbytes);
MemoryStream memstream = new MemoryStream();
CryptoStream cryptostream = new CryptoStream(memstream, transform, CryptoStreamMode.Write);
cryptostream.Write(titleKey, 0, titleKey.Length);
cryptostream.FlushFinalBlock();
return memstream.ToArray();
}
</pre>

Services

2015-06-12T04:39:09Z

WulfyStylez:

Services are an abstraction of ports and are the commonly used way of inter-process communication outside of the kernel. While handles of regular ports are retrieved from [[SVC]](svcConnectToPort), service handles are retrieved through the port ''srv:'' ("service manager").

When a service is registered, [[SVC|svcCreatePort]] is used without a port-name. This means that the port is inaccessible via the port SVCs outside of sm-module. See below for getting a session handle for sending commands to services.

Processes with PID less than or equal to the number of NATIVE_FIRM built-in modules (fs, sm, pm, pxi, ldr) have access to all services. This value is obtained from [[SVC|svcGetSystemInfo]].

Attempting to use srvGetServiceSession with a service that the process has access to when that service isn't registered, results in svcSendSyncRequest never returning(the exact cause is unknown).

==Service Manager Port "srv:"==
{| class="wikitable" border="1"
|-
! Command Header
! Description
|-
| 0x00010002
| Initialize
|-
| 0x00020000
| GetProcSemaphore() (the handle from this gets signaled when notifications for this process gets triggered)
|-
| 0x00030100
| RegisterService(8-byte servicename, u32 strlen, u32 max_sessions)
|-
| 0x000400C0
| UnregisterService(8-byte servicename, u32 strlen)
|-
| 0x00050100
| GetServiceSession(8-byte servicename, u32 strlen, u32 flags)

Flags bit0: if not set, return port-handle instead of session-handle(from [[SVC|svcCreateSessionToPort]]) when session-handle unavailable (max sessions/timeout?).
|-
| 0x000600C2
| RegisterPort(8-byte servicename, u32 strlen, Handle client_port)
|-
| 0x000700C0
| UnregisterPort(8-byte servicename, u32 strlen)
|-
| 0x00080100
| GetPort(8-byte servicename, u32 strlen, u32 flags).

Flags bit0: return 0 instead of port handle if port was found.
|-
| 0x00090040
| Subscribe(u32 notification_id). This enables the specified notificationID for the current process.
|-
| 0x000A0040
| Unsubscribe(u32 notification_id). This disables the specified notificationID for the current process.
|-
| 0x000B0000
| ReceiveNotification() This returns the notificationID which was triggered, if any(see GetProcSemaphore).
|-
| 0x000C0080
| PublishToSubscriber(u32 notification_id, u32 flag). This fires an notification. Bit0: only fire if not already fired, bit1: return error if error happens, else it always returns 0.
|-
| 0x000D0040
| This can fire notificationIDs and return the number of fired notificationID
|-
| 0x000E00C0
| HasAccessToService(8-byte servicename, u32 strlen). Returns 1 if your process has access to the service.
|}

==Service Manager Process-Manager Port "srv:pm"==
{| class="wikitable" border="1"
|-
! Command Header, prior to [[7.0.0-13]]
! Description
|-
| 0x04030082
| RegisterProcess (u32 procid, u32 wordsz, <nowiki>((wordsz<<16) | 2)</nowiki>, serviceaccesscontrol*).
|-
| 0x04040040
| UnregisterProcess (u32 procid).
|}

The Register command registers a process with the service-manager, which includes registering the serviceaccesscontrol for the process which normally originates from the [[NCCH/Extended_Header|exheader]].

Prior to to [[7.0.0-13]], the commands listed for "srv:" were also accessible under this port with the same command-headers. Starting with [[7.0.0-13]], the "srv:pm" port was changed to a service. With this change, commandIDs for these commands were changed. "srv:pm" was originally vulnerable, this was fixed with [[7.0.0-13]], see [[3DS_exploits|here]]. Originally any process could use "srv:pm", however starting with [[7.0.0-13]] only the built-in NATIVE_FIRM sysmodules have access to it. The only system title which uses "srv:pm" is the [[Process_Manager_Services|Process Manager]].

==Notifications==
{| class="wikitable" border="1"
|-
! ID
! Description
|-
| 0x100
| This indicates that all processes must terminate: power-off, reboot, or [[FIRM]]-launch.
|-
| 0x105
| This indicates that the system is entering sleep mode.
|-
| 0x108
| error at boot?
|-
| 0x202
| POWER button pressed
|-
| 0x204
| This indicates that the HOME button was pressed.
|-
| 0x205
| HOME button pressed
|-
| 0x207
| SD card inserted
|-
| 0x208
| Game cartridge inserted
|-
| 0x209
| SD card removed
|-
| 0x20A
| Game cartridge removed
|-
| 0x20B
| Game cartridge inserted or removed
|}

Error codes

2015-06-11T01:49:45Z

WulfyStylez:

All system error codes follow a shared format.

{| class="wikitable" border="1"
|-
! Bits
! Description
|-
| 0-9
| Description
|-
| 10-17
| Module
|-
| 21-26
| Summary
|-
| 27-31
| Level
|}

Description ranges:

{| class="wikitable" border="1"
|-
! Num
! Description
|-
| 100-179
| Not found
|-
| 180-199
| Exists already
|-
| 200-219
| Not enough space
|-
| 220-229
| Invalidated archive
|-
| 230-339
| Unacceptable
|-
| 390-399
| Verification failure
|-
| 760-779
| Not supported
|}

Description values:

{| class="wikitable" border="1"
|-
! Num
! Description
|-
| 0
| Success
|-
| 2
| Invalid memory permissions (kernel)
|-
| 4
| Invalid ticket version (AM)
|-
| 5
| Invalid string length. This error is returned when service name length is greater than 8 or zero. (srv)
|-
| 6
| Access denied. This error is returned when you request a service that you don't have access to. (srv)
|-
| 7
| String size does not match string contents. This error is returned when service name contains an unexpected null byte. (srv)
|-
| 8
| Camera already in use/busy (qtm).
|-
| 10
| Not enough memory (os)
|-
| 26
| Session closed by remote (os)
|-
| 37
| Invalid NCCH? (AM)
|-
| 39
| Invalid title version (AM)
|-
| 43
| Database doesn't exist/failed to open (AM)
|-
| 44
| Trying to uninstall system-app (AM)
|-
| 101
| Archive not mounted/mount-point not found (fs)
|-
| 105
| Request timed out (http)
|-
| 106
| Invalid signature/CIA? (AM)
|-
| 120
| Title/object not found? (fs)
|-
| 141
| Gamecard not inserted? (fs)
|-
| 230
| Invalid open-flags / permissions? (fs)
|-
| 271
| Invalid configuration (mvd).
|-
| 391
| NCCH hash-check failed? (fs)
|-
| 392
| RSA/AES-MAC verification failed? (fs)
|-
| 393
| Invalid database? (AM)
|-
| 395
| RomFS/Savedata hash-check failed? (fs)
|-
| 630
| Command not allowed / missing permissions? (fs)
|-
| 702
| Invalid path? (fs)
|-
| 761
| Incorrect read-size for ExeFS? (fs)
|-
| 1000
| Invalid selection
|-
| 1001
| Too large
|-
| 1002
| Not authorized
|-
| 1003
| Already done
|-
| 1004
| Invalid size
|-
| 1005
| Invalid enum value
|-
| 1006
| Invalid combination
|-
| 1007
| No data
|-
| 1008
| Busy
|-
| 1009
| Misaligned address
|-
| 1010
| Misaligned size
|-
| 1011
| Out of memory
|-
| 1012
| Not implemented
|-
| 1013
| Invalid address
|-
| 1014
| Invalid pointer
|-
| 1015
| Invalid handle
|-
| 1016
| Not initialized
|-
| 1017
| Already initialized
|-
| 1018
| Not found
|-
| 1019
| Cancel requested
|-
| 1020
| Already exists
|-
| 1021
| Out of range
|-
| 1022
| Timeout
|-
| 1023
| Invalid result value
|}

Summary values:
{| class="wikitable" border="1"
|-
! Num
! Description
|-
| 0
| Success
|-
| 1
| Nothing happened
|-
| 2
| Would block
|-
| 3
| Out of resource
|-
| 4
| Not found
|-
| 5
| Invalid state
|-
| 6
| Not supported
|-
| 7
| Invalid argument
|-
| 8
| Wrong argument
|-
| 9
| Canceled
|-
| 10
| Status changed
|-
| 11
| Internal
|-
| 63
| Invalid result value
|}

Module values:
{| class="wikitable" border="1"
|-
! Num
! Description
|-
| 0
| Common
|-
| 1
| Kernel
|-
| 2
| Util
|-
| 3
| File server
|-
| 4
| Loader server
|-
| 5
| TCB
|-
| 6
| OS
|-
| 7
| DBG
|-
| 8
| DMNT
|-
| 9
| PDN
|-
| 10
| GX
|-
| 11
| I2C
|-
| 12
| GPIO
|-
| 13
| DD
|-
| 14
| CODEC
|-
| 15
| SPI
|-
| 16
| PXI
|-
| 17
| FS
|-
| 18
| DI
|-
| 19
| HID
|-
| 20
| CAM
|-
| 21
| PI
|-
| 22
| PM
|-
| 23
| PM_LOW
|-
| 24
| FSI
|-
| 25
| SRV
|-
| 26
| NDM
|-
| 27
| NWM
|-
| 28
| SOC
|-
| 29
| LDR
|-
| 30
| ACC
|-
| 31
| RomFS
|-
| 32
| AM
|-
| 33
| HIO
|-
| 34
| Updater
|-
| 35
| MIC
|-
| 36
| FND
|-
| 37
| MP
|-
| 38
| MPWL
|-
| 39
| AC
|-
| 40
| HTTP
|-
| 41
| DSP
|-
| 42
| SND
|-
| 43
| DLP
|-
| 44
| HIO_LOW
|-
| 45
| CSND
|-
| 46
| SSL
|-
| 47
| AM_LOW
|-
| 48
| NEX
|-
| 49
| Friends
|-
| 50
| RDT
|-
| 51
| Applet
|-
| 52
| NIM
|-
| 53
| PTM
|-
| 54
| MIDI
|-
| 55
| MC
|-
| 56
| SWC
|-
| 57
| FatFS
|-
| 58
| NGC
|-
| 59
| CARD
|-
| 60
| CARDNOR
|-
| 61
| SDMC
|-
| 62
| BOSS
|-
| 63
| DBM
|-
| 64
| Config
|-
| 65
| PS
|-
| 66
| CEC
|-
| 67
| IR
|-
| 68
| UDS
|-
| 69
| PL
|-
| 70
| CUP
|-
| 71
| Gyroscope
|-
| 72
| MCU
|-
| 73
| NS
|-
| 74
| News
|-
| 75
| RO
|-
| 76
| GD
|-
| 77
| Card SPI
|-
| 78
| EC
|-
| 79
| Web Browser
|-
| 80
| Test
|-
| 81
| ENC
|-
| 82
| PIA
|-
| 92
| MVD
|-
| 96
| QTM
|-
| 254
| Application
|-
| 255
| Invalid result value
|}

Level values:
{| class="wikitable" border="1"
|-
! Num
! Description
|-
| 0
| Success
|-
| 1
| Info
|-
| 25
| Status
|-
| 26
| Temporary
|-
| 27
| Permanent
|-
| 28
| Usage
|-
| 29
| Reinitialize
|-
| 30
| Reset
|-
| 31
| Fatal
|}

Loader Services

2015-06-06T21:59:15Z

WulfyStylez: /* Loader service "Loader" */

[[Category:Services]]
= Loader service "Loader" =
{| class="wikitable" border="1"
|-
! Command Header
! Description
|-
| 0x00010080
| LoadProcess(u64 titlehandle). This maps 0x10000000 and reads ExeFS:/.code there, then decompresses it if needed. This then uses [[SVC|svcCreateProcess]] and svcSetupProcess. Once finished this writes the KProcess handle to cmdreply[3].
|-
| 0x00020200
| RegisterProgram. Writes u64 titlehandle starting at cmdreply[2].
|-
| 0x00030080
| UnregisterProgram
|-
| 0x00040080
| GetExheader(u64 titlehandle)
|}

Services API

2015-06-05T04:21:15Z

WulfyStylez:

Nintendo provides application developers with an API, which communicate with certain services. Services, in this sense, are system processes running in the background which wait for incoming requests. When a process wants to communicate with a service, it first needs to get a handle to the named service, and then it can communicate with the service via interprocess communication. Each service has a name up to 8 characters, for example "nim:u".

Handles for services are retrieved from the service manager port, "srv:". Services are an abstraction of ports, they operate the same way except regular ports can have their handles retrieved directly from a SVC.

For a description of how commands and arguments are passed to services, see [[IPC Command Structure]].

List of services:
{| class="wikitable" border="1"
|-
! Old3ds
! Services
! Service names
! scope="col" width="200" | Notes
|-
| style="background: green" | Yes
| [[Filesystem services‎]]
| fs:USER, fs:LDR, fs:REG
|
|-
| style="background: green" | Yes
| [[Process Services‎]]
|
|
|-
| style="background: green" | Yes
| [[PXI Services‎]]
| PxiFS0, PxiFS1, PxiFSB, PxiFSR, PxiPM, pxi:am9, pxi:dev, pxi:mc, pxi:ps9
|
|-
| style="background: green" | Yes
| [[Application Manager Services]]
| am:app, am:net, am:u, am:sys, am:pipe
|
|-
| style="background: green" | Yes
| [[Process Manager Services]]
| pm:app, pm:dbg
|
|-
| style="background: green" | Yes
| [[NIM Services]]
| nim:aoc, nim:ndm, nim:s, nim:u
|
|-
| style="background: green" | Yes
| [[Config Services]]
|
|
|-
| style="background: green" | Yes
| [[NS|NS and APT Services]]
| ns:s, ns:p, ns:c, APT:A, APT:S, APT:U
|
|-
| style="background: green" | Yes
| [[RO Services]]
| ldr:ro
|
|-
| style="background: green" | Yes
| [[NDM Services]]
|
|
|-
| style="background: green" | Yes
| [[CSND Services]]
| csnd:SND
|
|-
| style="background: green" | Yes
| [[Camera Services]]
| cam:u, y2r:u, cam:s, cam:c, cam:q (New3DS only)
|
|-
| style="background: green" | Yes
| [[Codec Services]]
| cdc:HID, cdc:MIC, cdc:CSN, cdc:DSP, cdc:LGY, cdc:CHK
|
|-
| style="background: green" | Yes
| [[DLP Services]]
| dlp:CLNT, dlp:FKCL, dlp:SRVR
|
|-
| style="background: green" | Yes
| [[DSP Services]]
| dsp::DSP
|
|-
| style="background: green" | Yes
| [[GSP Services]]
| gsp::Lcd, gsp::Gpu
|
|-
| style="background: green" | Yes
| [[BOSS Services]]
| boss:U
|
|-
| style="background: green" | Yes
| [[IR Services]]
|
|
|-
| style="background: green" | Yes
| [[I2C Services]]
| i2c::MCU, i2c::CAM, i2c::LCD, i2c::DEB, i2c::HID, i2c::IR, i2c::EEP
|
|-
| style="background: green" | Yes
| [[GPIO Services]]
| gpio:CDC, gpio:MCU, gpio:HID, gpio:NWM, gpio:IR
|
|-
| style="background: green" | Yes
| [[HID Services]]
| hid:NFC, hid:QTM, hid:SPVR, hid:USER
|
|-
| style="background: green" | Yes
| [[PTM Services]]
| ptm:gets, ptm:play, ptm:s, ptm:sets, ptm:sysm, ptm:u
|
|-
| style="background: green" | Yes
| [[NWM Services]]
| nwm::UDS
|
|-
| style="background: green" | Yes
| [[HTTP Services]]
| http:C
|
|-
| style="background: green" | Yes
| [[SSL Services]]
| ssl:C
|
|-
| style="background: green" | Yes
| [[Socket Services]]
| soc:P, soc:U
|
|-
| style="background: green" | Yes
| [[AC Services]]
| ac:i, ac:u
|
|-
| style="background: green" | Yes
| [[Friend Services]]
| frd:a, frd:u
|
|-
| style="background: green" | Yes
| [[News Services]]
|
|
|-
| style="background: green" | Yes
| [[PDN Services]]
|
|
|-
| style="background: green" | Yes
| [[SPI Services]]
|
|
|-
| style="background: green" | Yes
| [[Loader Services]]
|
|
|-
| style="background: green" | Yes
| [[MCU Services]]
| mcu::CAM, mcu::GPU, mcu::HID, mcu::RTC, mcu::SND, mcu::NWM, mcu::HWC, mcu::PLS, mcu::CDC
|
|-
| style="background: green" | Yes
| [[MIC Services]]
| mic:u
|
|-
| style="background: green" | Yes
| [[ACT Services]]
| act:a, act:u
|
|-
| style="background: red" | No
| [[NFC Services]]
|
|
|-
| style="background: red" | No
| [[MVD Services]]
|
|
|-
| style="background: red" | No
| [[QTM Services]]
|
|
|}

List of PXI services:
* [[Filesystem services PXI]]
* [[Process Services PXI]]
* [[Application Manager Services PXI]]
* [[Process Manager Services PXI]]
* [[Development Services PXI]]
* [[Gamecard Services PXI]]
* [[Legacy FIRM PXI]] (TWL_FIRM/AGB_FIRM)

List of ports:
* [[ErrDisp]]
* [[Services]]

See [[Error codes]].

3DS Virtual Console

2015-06-02T03:44:37Z

WulfyStylez: /* GBA VC */

IO Registers

2015-05-28T10:13:07Z

WulfyStylez: /* Overview */

= Overview =

{| class="wikitable" border="1"
! Old3DS
! A9/A11
! Category
! Physaddr
! Used by
! Comments
|-
| style="background: green" | Yes
| A9
| [[CONFIG Registers]]
| 0x10000000
| Boot9, Process9
|
|-
| style="background: green" | Yes
| A9
| [[IRQ Registers]]
| 0x10001000
| Boot9, Process9, Kernel9
| ARM9 Interrupt Masking
|-
| style="background: green" | Yes
| A9
| [[NDMA Registers]]
| 0x10002000
| Boot9, Process9
| DMA Engine
|-
| style="background: green" | Yes
| A9
| [[TIMER Registers]]
| 0x10003000
| Boot9, Process9
|
|-
| style="background: green" | Yes
| A9
| [[CTRCARD Registers]]
| 0x10004000 / 0x10005000
| Process9
|
|-
| style="background: green" | Yes
| A9
| [[EMMC Registers]]
| 0x10006000 / 0x10007000
| Boot9, Process9
| 0x10007000 is normally not enabled on retail, all-zeros when read.
|-
| style="background: green" | Yes
| A9
| [[PXI Registers]]
| 0x10008000
| Boot9, Process9
|
|-
| style="background: green" | Yes
| A9
| [[AES Registers]]
| 0x10009000
| Boot9, Process9
|
|-
| style="background: green" | Yes
| A9
| [[SHA Registers]]
| 0x1000A000
| Boot9, Process9
|
|-
| style="background: green" | Yes
| A9
| [[RSA Registers]]
| 0x1000B000
| Boot9, Process9
|
|-
| style="background: green" | Yes
| A9
| [[XDMA Registers]]
| 0x1000C000
| Boot9, Kernel9
| [http://infocenter.arm.com/help/topic/com.arm.doc.ddi0424d/index.html CoreLink™ DMA-330] (single-channel).
|-
| style="background: green" | Yes
| A9
| [[SPICARD Registers]]
| 0x1000D800
| Process9
|
|-style="border-top: double"
| style="background: green" | Yes
| ?
| [[CONFIG Registers]]
| 0x10010000
| Process9
|
|-
| style="background: green" | Yes
| ?
| PRNG Registers
| 0x10011000
| Process9
| Used as entropy-source for seeding random number generators.
|-
| style="background: green" | Yes
| ?
| [[OTP Registers]]
| 0x10012000
| Kernel9, NewKernel9Loader
| Top secret.
|-
| style="background: green" | Yes
| ?
| [[ARM7|ARM7 Registers]]
| 0x10018000
| TwlProcess9
| Used to setup the ARM7 core for AGB/TWL
|-style="border-top: double"
| style="background: green" | Yes
| ?
| ?
| 0x10100000
| ?
| ?
|-
| style="background: green" | Yes
| A11/A9
| [[HASH Registers]]
| 0x10101000
| [[Filesystem services]]
|
|-
| style="background: green" | Yes
| A11/A9
| [[Camera Registers]]
| 0x10102000
| [[Camera Services]]
| y2r
|-
| style="background: green" | Yes
| A11/A9
| [[CSND Registers]] / [[DSP Registers]]
| 0x10103000
| TwlBg, [[Codec Services]], [[CSND Services]], [[DSP Services]]
| Sound hardware. For DSP regs, see the "DSi XpertTeak" section in [http://problemkaputt.de/gba.htm no$gba] help.
|-style="border-top: double"
| style="background: green" | Yes
| A11/A9
| LGYFB0
| 0x10110000
| TwlBg
| IO registers used to access legacy output framebuffer, as well as configure the upscaling filter.
|-
| style="background: green" | Yes
| A11/A9
| LGYFB1
| 0x10111000
| TwlBg
| IO registers used to access legacy output framebuffer, as well as configure the upscaling filter.
|-style="border-top: double"
| style="background: green" | Yes
| A11/A9
| [[Camera Registers]]
| 0x10120000
| [[Camera Services]]
|
|-
| style="background: green" | Yes
| A11/A9
| [[Camera Registers]]
| 0x10121000
| [[Camera Services]]
| Mirror of 0x10120000?
|-
| style="background: green" | Yes
| A11/A9
|?
| 0x10122000
| [[NWM Services]]
| WIFI?
|-
| style="background: green" | Yes
| A11/A9
|?
| 0x10123000
| [[NWM Services]]
| WIFI?
|-style="border-top: double"
| style="background: red" | No
| A11/A9
| [[MVD Registers]]
| 0x10130000
| [[MVD Services]]
|
|-
| style="background: red" | No
| A11/A9
| [[MVD Registers]]
| 0x10131000
| [[MVD Services]]
|
|-
| style="background: red" | No
| A11/A9
| [[MVD Registers]]
| 0x10132000
| [[MVD Services]]
|
|-style="border-top: double"
| style="background: green" | Yes
| A11/A9
| [[PDN Registers]]
| 0x10140000
| Process9, Boot11, Kernel11, TwlBg, [[DSP Services]], [[NWM Services]], [[SPI Services]]
| Power management.
|-
| style="background: green" | Yes
| A11/A9
| [[PDN Registers]]
| 0x10141000
| Process9, Boot11, Kernel11, TwlBg, [[Codec Services]], [[NWM Services]], [[SPI Services]], [[PDN Services]]
| Power management
|-
| style="background: green" | Yes
| A11/A9
| [[SPI Registers]]
| 0x10142000
| TwlBg, [[SPI Services]]
|
|-
| style="background: green" | Yes
| A11/A9
| [[SPI Registers]]
| 0x10143000
| TwlBg, dmnt Module
| Debugger related?
|-
| style="background: green" | Yes
| A11/A9
| [[I2C Registers]]
| 0x10144000
| Boot11, Kernel11, TwlBg, [[I2C Services]]
|
|-
| style="background: green" | Yes
| A11/A9
| [[CODEC Registers]]
| 0x10145000
| TwlBg, [[Codec Services]]
|
|-
| style="background: green" | Yes
| A11/A9
| [[HID Registers]]
| 0x10146000
| Boot11, Kernel11, TwlBg, [[HID Services]], dlp Services
| See [[PAD]].
|-
| style="background: green" | Yes
| A11/A9
| [[GPIO Registers]]
| 0x10147000
| Boot11, TwlBg, [[GPIO Services]], [[DSP Services]](v0)
|
|-
| style="background: green" | Yes
| A11/A9
| [[I2C Registers]]
| 0x10148000
| TwlBg, [[I2C Services]]
|
|-style="border-top: double"
| style="background: green" | Yes
| A11/A9
| [[SPI Registers]]
| 0x10160000
| Boot9, TwlBg, [[SPI Services]]
|
|-
| style="background: green" | Yes
| A11/A9
| [[I2C Registers]]
| 0x10161000
| Boot11, TwlBg, [[I2C Services]]
| See [http://problemkaputt.de/gba.htm no$gba] help for some clues maybe.
|-
| style="background: green" | Yes
| A11/A9
| [[MIC Registers]]
| 0x10162000
| [[MIC Services]]
|
|-
| style="background: green" | Yes
| A11/A9
| [[PXI Registers]]
| 0x10163000
| Boot11, Kernel11, TwlBg, [[PXI Services]]
|
|-
| style="background: green" | Yes
| A11/A9
| [[NTRCARD Registers]]
| 0x10164000
| Boot9, Process9
|
|-
| style="background: green" | Yes
| A11/A9
| [[MP Registers]]
| 0x10165000
| [[MP Services]]
|
|-style="border-top: double"
| style="background: green" | Yes
| A11/A9
| [[MP Registers]]
| 0x10170000
| [[MP Services]]
| NTR WIFI Registers, see [http://problemkaputt.de/gbatek.htm#dswirelesscommunications GBATek].
|-
| style="background: green" | Yes
| A11/A9
| [[MP Registers]]
| 0x10171000
| [[MP Services]]
| NTR WIFI Registers (mirror)
|-
| style="background: green" | Yes
| A11/A9
|?
| 0x10172000
|?
| NTR WIFI Unused?
|-
| style="background: green" | Yes
| A11/A9
|?
| 0x10173000
|?
| NTR WIFI Unused?
|-
| style="background: green" | Yes
| A11/A9
| [[MP Registers]]
| 0x10174000
| [[MP Services]]
| NTR WIFI RAM
|-
| style="background: green" | Yes
| A11/A9
| [[MP Registers]]
| 0x10175000
|?
| NTR WIFI RAM
|-
| style="background: green" | Yes
| A11/A9
| [[MP Registers]]
| 0x10176000
|?
| NTR WIFI Registers (mirror)
|-
| style="background: green" | Yes
| A11/A9
| [[MP Registers]]
| 0x10177000
|?
| NTR WIFI Registers (mirror)
|-
| style="background: green" | Yes
| A11/A9
| [[MP Registers]]
| 0x10178000 - 0x10180000
| [[MP Services]]
| NTR WIFI WS1 Region
|-style="border-top: double"
| style="background: green" | Yes
| A11
| CDMA
| 0x10200000
| Boot11, Kernel11
| [http://infocenter.arm.com/help/topic/com.arm.doc.ddi0424d/index.html CoreLink™ DMA-330]. Not used on New3DS.
|-
| style="background: green" | Yes
| A11
| ?
| 0x10201000
| TwlBg
|
|-
| style="background: green" | Yes
| A11
| [[LCD Registers]]
| 0x10202000
| TwlBg, Kernel11, [[GSP Services]]
|
|-
| style="background: green" | Yes
| A11
| [[DSP Registers]]
| 0x10203000
| [[DSP Services]]
|
|-
| style="background: green" | Yes
| A11
| ?
| 0x10204000
|
|
|-style="border-top: double"
| style="background: red" | No
| A11
| CDMA
| 0x10206000
| NewKernel11
| CDMA was moved here on New 3DS. [http://infocenter.arm.com/help/topic/com.arm.doc.ddi0424d/index.html CoreLink™ DMA-330].
|-
| style="background: red" | No
| A11
| [[MVD Registers]]
| 0x10207000
| [[MVD Services]]
| New 3DS only?
|-style="border-top: double"
| style="background: green" | Yes
| A11
| AXI
| 0x1020F000
| TwlBg, [[GSP Services]]
| [http://infocenter.arm.com/help/topic/com.arm.doc.ddi0422a/CHDGHIID.html CoreLink™ NIC-301 r1p0].
|-style="border-top: double"
| style="background: green" | Yes
| A11
| MIRROR
| 0x10300000-0x10400000
|
| Mirror of 0x10100000-0x10200000 (faster bus?), CDMA wants these addresses
|-style="border-top: double"
| style="background: green" | Yes
| A11
| [[GPU Registers]]
| 0x10400000
| Boot11, Kernel11, [[GSP Services]]
||
|}

IO registers starting at physical address 0x10200000 are not accessible from the ARM9 (which includes all LCD/GPU registers). It seems IO registers below physical address 0x10100000 are not accessible from the ARM11 bus.

ARM11 kernel virtual address mappings for these registers varies for different builds. For ARM11 user mode applications you have:
physaddr = virtaddr - 0x1EC00000 + 0x10100000

Application Manager Services PXI

2015-05-27T19:58:57Z

WulfyStylez: /* Errors */

{| class="wikitable" border="1"
|-
! Command Header
! Available since system version
! Description
|-
| 0x00010040
| [[1.0.0-0]]
| [[AMPXI:GetTitleCount|GetTitleCount]]
|-
| 0x00020082
| [[1.0.0-0]]
| [[AMPXI:GetTitleList|GetTitleList]]
|-
| 0x00030084
| [[1.0.0-0]]
| [[AMPXI:GetTitleInfo|GetTitleInfo]]
|-
| 0x000400C0
| [[1.0.0-0]]
| [[AMPXI:DeleteTitle|DeleteTitle]]
|-
| 0x000500C0
| [[1.0.0-0]]
| [[AMPXI:GetTitleProductCode|GetTitleProductCode]]
|-
| 0x000600C0
| [[1.0.0-0]]
| (unknown_u8, unknown_u64)
|-
| 0x00070080
| [[1.0.0-0]]
| (unknown_u8, unknown_u32)
|-
| 0x00080080
| [[1.0.0-0]]
| [[AMPXI:InstallFIRM|InstallFIRM]]
|-
| 0x00090000
| [[1.0.0-0]]
| InstallTikBegin
|-
| 0x000A0042
| [[1.0.0-0]]
| InstallTikWrite (size, ptr, ptrsize)
|-
| 0x000B0000
| [[1.0.0-0]]
| InstallTikAbort
|-
| 0x000C0000
| [[1.0.0-0]]
| InstallTikFinish
|-
| 0x000D0080
| [[1.0.0-0]]
| (unknown_u64)
|-
| 0x000E0000
| [[1.0.0-0]]
| GetTitleAllCount
|-
| 0x000F0082
| [[1.0.0-0]]
| GetTitleAllList
|-
| 0x00100100
| [[1.0.0-0]]
| InstallTitleBegin (?)
|-
| 0x00110000
| [[1.0.0-0]]
| InstallTitleAbort (?)
|-
| 0x00120100
| [[1.0.0-0]]
| InstallTitleResume (?)
|-
| 0x00130000
| [[1.0.0-0]]
| InstallTmdBegin (?)
|-
| 0x00140042
| [[1.0.0-0]]
| [[AMPXI:InstallTmdWrite|InstallTmdWrite]]
|-
| 0x00150000
| [[1.0.0-0]]
|?
|-
| 0x00160040
| [[1.0.0-0]]
| InstallTmdFinish (?)
|-
| 0x00170040
| [[1.0.0-0]]
| [[AMPXI:InstallContentBegin|InstallContentBegin]]
|-
| 0x00180042
| [[1.0.0-0]]
| [[AMPXI:InstallContentWrite|InstallContentWrite]]
|-
| 0x00190000
| [[1.0.0-0]]
| InstallContentAbort (?)
|-
| 0x001A0000
| [[1.0.0-0]]
|?
|-
| 0x001B0040
| [[1.0.0-0]]
| [[AMPXI:InstallContentResume|InstallContentResume]]
|-
| 0x001C0000
| [[1.0.0-0]]
| [[AMPXI:InstallContentFinish|InstallContentFinish]]
|-
| 0x001D0040
| [[1.0.0-0]]
| (unknown_u8, unknown_u32)
|-
| 0x001E00C2
| [[1.0.0-0]]
| (unknown_entrycount, unknown_u8, unknown_u32, ptr, ptrsize)
|-
| 0x001F0084
| [[1.0.0-0]]
| [[AMPXI:GetTitleTemporaryInfo|GetTitleTemporaryInfo]]
|-
| 0x002000C0
| [[1.0.0-0]]
| (unknown_u8, unknown_u64)
|-
| 0x002100C0
| [[1.0.0-0]]
| (unknown_u8, unknown_u64)
|-
| 0x00220102
| [[1.0.0-0]]
| (count, unknown_u8, unknown_u64, ptrsize_count_mul_2, ptr)
|-
| 0x00230104
| [[1.0.0-0]]
| (count, unknown_u8, unknown_u64, ptr1size_count_mul_2, ptr1, ptr2size_count_mul_24, ptr2)
|-
| 0x00240102
| [[1.0.0-0]]
| (count, unknown_u8, unknown_u64, ptrsize_count_mul2, ptr)
|-
| 0x00250000
| [[1.0.0-0]]
| GetContentCount (?)
|-
| 0x00260042
| [[1.0.0-0]]
| GetContentIds (?)
|-
| 0x00270044
| [[1.0.0-0]]
| GetContentInfoForIds (?)
|-
| 0x00280000
| [[1.0.0-0]]
|?
|-
| 0x00290000
| [[1.0.0-0]]
| InstallTitleFinish (?)
|-
| 0x002A00C2
| [[1.0.0-0]]
| (unknown_u8, count, unknown_u8, ptrsize_count_mul_8, ptr)
|-
| 0x002B....
| [[1.0.0-0]]
| ?
|-
| 0x002C....
| [[1.0.0-0]]
| ?
|-
| 0x002D....
| [[1.0.0-0]]
| ?
|-
| 0x002E....
| [[1.0.0-0]]
| ?
|-
| 0x002F....
| [[1.0.0-0]]
| ?
|-
| 0x0030....
| [[1.0.0-0]]
| ?
|-
| 0x0031....
| [[1.0.0-0]]
| ?
|-
| 0x0032....
| [[1.0.0-0]]
| ?
|-
| 0x0033....
| [[1.0.0-0]]
| ?
|-
| 0x0034....
| [[1.0.0-0]]
| ?
|-
| 0x0035....
| [[1.0.0-0]]
| ?
|-
| 0x0036....
| [[1.0.0-0]]
| ?
|-
| 0x0037....
| [[1.0.0-0]]
| ?
|-
| 0x0038....
| [[1.0.0-0]]
| ?
|-
| 0x00390146
| [[1.0.0-0]]
| (size2, size3, unknown_u64, size1, ptr1size_size1, ptr1, ptr2size_size2, ptr2, ptr3size_size3, ptr3)
|-
| 0x003A0146
| [[1.0.0-0]]
| (unknown_u64, size1, size2, size3, ptr1size_size1, ptr1, ptr2size_size2, ptr2, ptr3size_size3, ptr3)
|-
| 0x003B0042
| [[1.0.0-0]]
| [[AMPXI:GetCTCert|GetCTCert]]
|-
| 0x003C0000
| [[1.0.0-0]]
|?
|-
| 0x003D0108
| [[1.0.0-0]]
| (size1, size2, size3, size4, ptr1size, ptr1, ptr2size, ptr2, ptr3size, ptr3, ptr4size, ptr4)
|-
| 0x003E0042
| [[1.0.0-0]]
| (size, ptrsize, ptr)
|-
| 0x003F0040
| [[1.0.0-0]]
| (unknown_u8)
|-
| 0x00400040
| [[1.0.0-0]]
| FinishInstallToMedia (u8 mediatype)
|-
| 0x00410000
| [[1.0.0-0]]
|?
|-
| 0x00420142
| [[1.0.0-0]]
| InstallCommit
|-
| 0x004301C8
| [[2.0.0-2]]
| [[AMPXI:VerifyDSiWareFooter|VerifyDSiWareFooter]]
|-
| 0x004400C4
| [[2.0.0-2]]
| This does basically nothing: after checking the two buffers' mem-ranges successfully(on failure it executes svcBreak like all other Process9 code for that), this just returns 0x0.
|-
| 0x00450108
| [[2.0.0-2]]
| (size1, size3, size2, unknown_u8, ptr1size, ptr1, ptr2size, ptr2, ptr3size, ptr3, ptr4size_size2, ptr4) (DecryptDSiWareData)
|-
| 0x00460182
| [[2.0.0-2]]
| [[AMPXI:WriteTWLSavedata|WriteTWLSavedata]]
|-
| 0x00470080
| [[2.0.0-2]]
| (unknown_u8, unknown_u8)
|-
| 0x00480040
| [[2.0.0-2]]
| [[AMPXI:ReloadDBS|ReloadDBS]]
|-
| 0x00490080
| [[2.0.0-2]]
| (unknown_u64)
|-
| 0x004A0102
| [[2.0.0-2]]
| (count, unknown_u64, unknown_u8, ptrsize_count_mul_8, ptr)
|-
| 0x004B0100
| [[2.0.0-2]]
| (unknown_u64, unknown_u64)
|-
| 0x004C0042
| [[2.0.0-2]]
| (count, ptrsize_count_mul_24, ptr)
|-
| 0x004D0144
| [[2.0.0-2]]
| [[AMPXI:ExportDSiWare|ExportDSiWare]]
|-
| 0x004E00C0
| [[2.0.0-2]]
| (unknown_u64, unknown_u8)
|-
| 0x004F00C0
| [[2.0.0-2]]
| [[AMPXI:GetDSiWareExportSize|GetDSiWareExportSize]]
|-
| 0x00500044
| [[2.0.0-2]]
| (count, ptr1size_count_mul_8, ptr1, ptr2size_count_mul_4, ptr2)
|-
| 0x00510000
| [[2.0.0-2]]
|?
|-
| 0x00520040
| [[2.0.0-2]]
| (unknown_u8)
|-
| 0x00530084
| [[2.0.0-2]]
| [[AMPXI:ValidateDSiWareMovableSedHash|ValidateDSiWareMovableSedHash]]
|-
| 0x00540000
| [[2.0.0-2]]
|?
|-
| 0x005500C4
| [[2.0.0-2]]
| [[AMPXI:ValidateDSiWareSectionMAC|ValidateDSiWareSectionMAC]]
|-
| 0x005600C0
| [[2.0.0-2]]
| (unknown_u64, unknown_u16)
|-
| 0x00570042
| [[4.0.0-7]]
| ?
|-
| 0x0058....
| [[4.0.0-7]]
| ?
|-
| 0x00590104
| [[4.0.0-7]]
| ?
|-
| 0x005A0142
| [[4.0.0-7]]
| ?
|-
| 0x005B....
| [[4.0.0-7]]
| ?
|-
| 0x005C0044
| [[4.0.0-7]]
| ?
|-
| 0x005D0082
| [[4.0.0-7]]
| ?
|-
| 0x005E0102
| [[4.0.0-7]]
| ?
|-
| 0x005F....
| [[4.0.0-7]]
| ?
|-
| 0x00600102
| [[4.0.0-7]]
| ?
|-
| 0x00610142
| [[4.0.0-7]]
| ?
|-
| 0x00620044
| [[4.0.0-7]]
| ?
|-
| 0x00630042
| [[4.0.0-7]]
| ?
|-
| 0x0064....
| [[4.0.0-7]]
| ?
|-
| 0x0065....
| [[4.0.0-7]]
| ?
|-
| 0x0066....
| [[4.0.0-7]]
| Stubbed starting with [[4.0.0-7]], this only returns zero for the command result-code.
|-
| 0x00670082
| [[4.0.0-7]]
| ?
|-
| 0x006801C2
| [[4.0.0-7]]
| ?
|-
| 0x0069....
| [[4.0.0-7]]
| ?
|-
| 0x006A....
| [[4.0.0-7]]
| ?
|-
| 0x006B0142
| [[4.0.0-7]]
| ?
|-
| 0x006C....
| [[5.0.0-11]]
| (u8 [[Mediatypes|Mediatype]], u64 programID)
|}

=Errors=
{| class="wikitable" border="1"
|-
! Error-code
! Description
|-
| 0xC8A0802B
| This indicates the the [[Title_Database|dbs]] image(.db) does not exist, or opening the .db file failed.
|-
| 0xC8E083FC
| This error indicates that the title is already installed, with the same title-version as the title being installed?
|-
| 0xD8E08027
| Invalid title-version, or the title-version of the title being installed is older than the currently installed title-version.
|-
| 0xD8A08004
| Invalid ticket title version.
|-
| 0xD8E08025
| Invalid NCCH. returned from InstallContentFinish
|-
| 0xD8A08029
| Error-type 1
|-
| 0xD8E08065
| Error-type -1
|-
| 0xD8E08065+1 / 0xD8E08066
| Error-type -2
|-
| 0xD8E08065+2 / 0xD8E08067
| Error-type -3
|-
| 0xD8E08065+3 / 0xD8E08068
| Error-type -4
|-
| 0xD8E08065+4 / 0xD8E08069
| Error-type -5
|-
| 0xD8E08065+5 / 0xD8E0806A
| Error-type -6. Returned when a function returns error -2011: signature or hash check for cert(TMD/TIK/cert-chain, ...) failed.
|-
| 0xD8E08065+6 / 0xD8E0806B
| Error-type -7
|-
| 0xD8E08065+7 / 0xD8E0806C
| Error-type -8
|-
| 0xD8E08065+8 / 0xD8E0806D
| Error-type -9
|-
| 0xD8E08065+9 / 0xD8E0806E
| Error-type -10
|-
| 0xD8E08065+10 / 0xD8E0806F
| Error-type -11
|-
| 0xD8E08065+11 / 0xD8E08070
| Error-type -12
|-
| 0xD8E08065+12 / 0xD8E08071
| Error-type -13
|-
| 0xD8E08065+13 / 0xD8E08072
| Error-type -14
|-
| 0xD8A083FA
| Invalid titleID.
|-
| 0xE0E0802C
| AM module returns this error when the system-title bit is set for the input CTR/TWL titleID-high, for [[AM:DeleteApplicationTitle]].
|}

CIA

2015-05-27T09:45:57Z

WulfyStylez: this was super wrong

[[Category:File formats]]
== Overview ==
CIA stands for '''C'''TR '''I'''mportable '''A'''rchive. This format allows the installation titles to the 3DS. CIA files and titles on [[Title list|Nintendo's CDN]] contain identical data. As a consequence, valid CIA files can be generated from CDN content. This also means CIA files can contain anything that titles on Nintendo's CDN can contain.

Under normal circumstances CIA files are used where downloading a title is impractical or not possible. Such as distributing a [[Download Play]] child, or installing forced Gamecard updates. Those CIA(s) are stored by the titles in question, in an auxiliary [[NCCH#CFA|CFA]] file.

Development Units, are capable of manually installing CIA files via the [[3DS Development Unit Software#Dev Menu|Dev Menu]].

== Format ==

This is the current version of the CIA format, it was finalised in late 2010. (Older versions of the CIA format can be viewed on the [[Talk:CIA|Talk]] page)

The CIA format has a similar structure to the [http://wiibrew.org/wiki/Wad WAD format].

The file is represented in little-endian.

The data is aligned in 64 byte blocks (if a content ends at the middle of the block, the next content will begin from a new block).

=== CIA Header ===

{| class="wikitable" border="1"
|-
! START
! SIZE
! DESCRIPTION
|-
| 0x00
| 0x04
| Archive Header Size (Usually = 0x2020 bytes)
|-
| 0x04
| 0x02
| Type
|-
| 0x06
| 0x02
| Version
|-
| 0x08
| 0x04
| Certificate chain size
|-
| 0x0C
| 0x04
| [[Ticket]] size
|-
| 0x10
| 0x04
| [[TMD]] file size
|-
| 0x14
| 0x04
| Meta size (0 if no Meta data is present)
|-
| 0x18
| 0x08
| Content size
|-
| 0x20
| 0x2000
| Content Index
|}

The order of the sections in the CIA file:
* certificate chain
* Ticket
* TMD file data
* Content file data
* Meta file data (Not a necessary component)

The contents (NCCH/SRL) are encrypted using 128-bit AES-CBC. The encryption uses the decrypted titlekey from the [[Ticket#Structure|ticket]], and the individual content ID padded with zeros as the IV.

=== Certificate Chain ===

There are three [[Certificates|certificates]] in this chain:

{| class="wikitable" border="1"
|-
! CERTIFICATE
! SIGNATURE TYPE
! RETAIL CERT NAME
! DEBUG CERT NAME
! DESCRIPTION
|-
| CA
| RSA-4096
| CA00000003
| CA00000004
| Used to verify the Ticket/TMD Certificates
|-
| Ticket
| RSA-2048
| XS0000000c
| XS00000009
| Used to verify the Ticket signature
|-
| TMD
| RSA-2048
| CP0000000b
| CP0000000a
| Used to verify the TMD signature
|}

The CA certificate is issued by 'Root', the public key for which is stored in NATIVE_FIRM.

=== Meta ===

The structure of this data is as follows:

{| class="wikitable" border="1"
|-
! START
! SIZE
! DESCRIPTION
|-
| 0x00
| 0x180
| Title ID dependency list - Taken from the application's [[NCCH#Extended Header|ExHeader]]
|-
| 0x180
| 0x180
| Reserved
|-
| 0x300
| 0x4
| Core Version
|-
| 0x304
| 0xFC
| Reserved
|-
| 0x400
| 0x36C0
| [[SMDH|Icon Data]](.ICN) - Taken from the application's [[ExeFS]]
|}

Obviously this section is not present in TWL CIA files, or any other CIA file which does not contain a [[NCCH#CXI|CXI]].

== Tools ==

* [https://github.com/3dshax/ctr/tree/master/ctrtool ctrtool] - Reading/Extraction of CIA files. This can only decrypt the title-key for development CIAs, since retail CIAs use the [[AES]] hardware key-scrambler for the common-key keyslot.

* [https://github.com/ctrdev/ctrsdk/tree/master/tools/make_cia make_cia] - Generating CIA files. Requires CommonKey and ticket/TMD RSA-2048 private exponents.

* [https://github.com/ctrdev/ctrsdk/tree/master/tools/make_cdn_cia make_cdn_cia] - (CMD)(Windows/Linux) Generates CIA files from CDN Content

== Title Key Encryption ==

The unencrypted Title Key is used to encrypt the data in a CIA. The encrypted Title Key of a CIA can be found at offset 0x1BF in a CIA's Ticket.
Each Title Key is encrypted with AES-CBC to get the encrypted Title Key.

To encrypt an unencrypted title key, you need:

* Common key (as byte array)
* Title ID (as ulong)
* (and of course the unencrypted title key you want to encrypt) (as byte array)

The title key encryption process starts by converting the ulong (Title ID) into a byte array using by retrieving the bytes of the Title ID using BitConverter.GetBytes().
If the converted bytes (title ID) are in Little Endian, reverse those bytes. (in C# it would be Array.Reverse(byte_array_from_bitconverter))
This process makes the Title Key encryption IV.

Next, after you've gotten your Title Key's IV, you can start your cryptography transformation. Using AESManaged, where:

Key = Common Key

IV = the byte array found in the conversion process above

Mode = CipherMode.CBC

Create the encryptor (AesManaged.CreateEncryptor(key, iv)) where the key and IV are both the same as above.

Then, create a CryptoStream and a MemoryStream. The Crypto stream should start with the arguments (memorystream, aes_transform_from_above, CryptoStreamMode.Write).

Write to the CryptoStream where buffer=unencrypted_titlekey, offset=0, and count=the length of the unencrypted title key.

Use FlushFinalBlock() on the CryptoStream.

Finally, then, the encrypted title key will be available from your memory
stream. (to output the calculated encrypted title key as a byte array, you can use memorystream.ToArray(), for example)

Example function: (C#)

<pre>
public static byte[] EncryptMyTitleKey(byte[] commonKey, byte[] titleKey, ulong titleId)
{
// Make encryption IV
byte[] titleidasbytes = new byte[0x10];
for (int i = 0; i < 0x10; i++)
{
titleidasbytes[i] = 0;
}
byte[] bitBytes = BitConverter.GetBytes(titleId);
if (BitConverter.IsLittleEndian)
{
Array.Reverse(bitBytes);
}
bitBytes.CopyTo(titleidasbytes, 0);
// Encrypt
ICryptoTransform transform = new AesManaged { Key = commonKey, IV = titleidasbytes, Mode = CipherMode.CBC }.CreateEncryptor(commonKey, titleidasbytes);
MemoryStream memstream = new MemoryStream();
CryptoStream cryptostream = new CryptoStream(memstream, transform, CryptoStreamMode.Write);
cryptostream.Write(titleKey, 0, titleKey.Length);
cryptostream.FlushFinalBlock();
return memstream.ToArray();
}
</pre>