3dbrew - User contributions [en]

Mysteries

2022-08-10T03:56:11Z

Shinyquagsire23: formatting

The following is a list of mysteries.

== General ==
* What is the CTR abbreviation?
: C may stand for Chiheisen ("horizon" in Japanese, the O3DS's codename being "Project Horizon").
:: Not true, Horizon refers to the OS.
: CTR stands for Citrus.

== 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 [http://i.imgur.com/0kJlbEw.png 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 the entire 3DS Family (3DS, 3DSXL, 2DS, New3DS, New3DSXL, New2DSXL), and even a prototype board from April(?) 2010. 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 key scrambler constant was "Nintendo Co., Ltd" in Japanese ("任天堂株式会社"), UTF-16LE encoded, with byte order mark. The 3DS key scrambler constant, by comparison, is random-looking.

=== What is the PDN abbreviation? ===
: PowerDowN

=== How does Nintendo reflash bricked systems? ===
Before trying to boot from NAND, the bootrom checks to see if a key combination (Start + Select + X) is being held, and whether the shell is closed. If so, it tries to boot from an inserted NTR (Nintendo DS) cartridge.
This allows to execute a FIRM that is probably used by Nintendo to reflash the system.

== 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

This could be referring to the ROM on the AR6K wireless chip:
* Some 2DS units have the WiFi chip soldered directly to the board (such as the 2DS in this FCC filing: https://fccid.link/BKE/FTR001N), and some do not.
* The AR6K ROM only acts as an initial loader.
* Maybe some AR6K-family devices allow signature checks on the firmware? Or maybe some registers weren't write-once but should have been?

=== What did SVC 0x74 in the ARM11 kernel do before it got stubbed? ===
=== What is the PTM abbreviation? ===
: PlayTime Management

=== 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.
=== How is CTRAging launched during factory setup? ===
'''Background:''' No TestMenu version is capable of launching CTRAging directly: O3DS factory TestMenu can only launch DevMenu installed on NAND, the inserted cartridge and the TWL/AGB test apps; N3DS factory TestMenu can only launch DevMenu installed on NAND, the inserted cartridge and System Settings.

'''Theory:''' NtrBoot another time
=== Why are there 4 stubbed syscalls named SendSyncRequest1-4? ===
=== Is there a deterministic formula for calculating the Movable.sed KeyY high u64? ===
'''Background:''' We know now that the high 4 bytes of KeyY can be reliably estimated to be 1/5th of the LocalFriendCodeSeed (low 8 bytes of KeyY), which is close enough to brute force. However, the actual value is usually about 0-4000 units off the actual high u32 of the KeyY (called msed3 in the seedminer implementation). Could there possibly be a deterministic formula given this 1/5 ratio is so close to the correct value? It's difficult to imagine this is just a coincidence.

Mysteries

2022-08-10T03:53:38Z

Shinyquagsire23: just spitballing here

The following is a list of mysteries.

== General ==
* What is the CTR abbreviation?
: C may stand for Chiheisen ("horizon" in Japanese, the O3DS's codename being "Project Horizon").
:: Not true, Horizon refers to the OS.
: CTR stands for Citrus.

== 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 [http://i.imgur.com/0kJlbEw.png 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 the entire 3DS Family (3DS, 3DSXL, 2DS, New3DS, New3DSXL, New2DSXL), and even a prototype board from April(?) 2010. 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 key scrambler constant was "Nintendo Co., Ltd" in Japanese ("任天堂株式会社"), UTF-16LE encoded, with byte order mark. The 3DS key scrambler constant, by comparison, is random-looking.

=== What is the PDN abbreviation? ===
: PowerDowN

=== How does Nintendo reflash bricked systems? ===
Before trying to boot from NAND, the bootrom checks to see if a key combination (Start + Select + X) is being held, and whether the shell is closed. If so, it tries to boot from an inserted NTR (Nintendo DS) cartridge.
This allows to execute a FIRM that is probably used by Nintendo to reflash the system.

== 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

This could be referring to the ROM on the AR6K wireless chip:
- Some 2DS units have the WiFi chip soldered directly to the board (such as the 2DS in this FCC filing: https://fccid.link/BKE/FTR001N), and some do not.
- The AR6K ROM only acts as an initial loader.
- Maybe some AR6K-family devices allow signature checks on the firmware? Or maybe some registers weren't write-once but should have been?

=== What did SVC 0x74 in the ARM11 kernel do before it got stubbed? ===
=== What is the PTM abbreviation? ===
: PlayTime Management

=== 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.
=== How is CTRAging launched during factory setup? ===
'''Background:''' No TestMenu version is capable of launching CTRAging directly: O3DS factory TestMenu can only launch DevMenu installed on NAND, the inserted cartridge and the TWL/AGB test apps; N3DS factory TestMenu can only launch DevMenu installed on NAND, the inserted cartridge and System Settings.

'''Theory:''' NtrBoot another time
=== Why are there 4 stubbed syscalls named SendSyncRequest1-4? ===
=== Is there a deterministic formula for calculating the Movable.sed KeyY high u64? ===
'''Background:''' We know now that the high 4 bytes of KeyY can be reliably estimated to be 1/5th of the LocalFriendCodeSeed (low 8 bytes of KeyY), which is close enough to brute force. However, the actual value is usually about 0-4000 units off the actual high u32 of the KeyY (called msed3 in the seedminer implementation). Could there possibly be a deterministic formula given this 1/5 ratio is so close to the correct value? It's difficult to imagine this is just a coincidence.

FIRM

2021-08-19T00:29:47Z

Shinyquagsire23: TWL_FIRM wifi chip params, partially pulled from GBATek

This page describes the file format for the [[Title list#00040138 - System Firmware|3DS' Firmware]], it contains up to four 'sections' of data comprising the ARM9 and ARM11 kernels, and some fundamental processes. The firmware sections are not encrypted. In a nutshell, a FIRM contains all the data required to set up the ARM9 and ARM11 kernels, and basic operating functionality.

The ARM9 section contains the ARM9 kernel (and loader) and the Process9 NCCH (which is the only process run in user mode on the ARM9). The ARM11 sections contain the ARM11 kernel (and loader), and various ARM11 process NCCHs. For NATIVE_FIRM/SAFE_MODE_FIRM these ARM11 processes are sm, fs, pm, loader, and pxi. Normally the 4th section is not used. The code loaded from FIRM is constantly running on the system until another FIRM is launched. The ARM11 kernel is hard-coded to always decompress the ExeFS .code of embedded ARM11 NCCHs without checking the exheader compression bit.

== FIRM Header ==
{| class="wikitable" border="1"
|-
! OFFSET
! SIZE
! DESCRIPTION
|-
| 0x000
| 4
| Magic 'FIRM'
|-
| 0x004
| 4
| Boot priority (highest value = max prio), this is normally zero.
|-
| 0x008
| 4
| ARM11 Entrypoint
|-
| 0x00C
| 4
| ARM9 Entrypoint
|-
| 0x010
| 0x030
| Reserved
|-
| 0x040
| 0x0C0 (0x030*4)
| Firmware Section Headers
|-
| 0x100
| 0x100
| RSA-2048 signature of the FIRM header's SHA-256 hash. The signature is checked when bootrom/Process9 are doing FIRM-launch (with the public key being hardcoded in each). The signature is not checked when installing FIRM to the NAND firm0/firm1 partitions.
|}

== Firmware Section Headers ==

{| class="wikitable" border="1"
|-
! OFFSET
! SIZE
! DESCRIPTION
|-
| 0x000
| 4
| Byte offset
|-
| 0x004
| 4
| Physical address where the section is loaded to.
|-
| 0x008
| 4
| Byte-size. While loading FIRM this is the field used to determine whether the section exists or not, by checking for value 0x0.
|-
| 0x00C
| 4
| Copy-method (0 = NDMA, 1 = XDMA, 2 = CPU mem-copy), Process9 ignores this field. Boot9 doesn't immediately throw an error when this isn't 0..2. In that case it will jump over section-data-loading which then results in the hash verification with the below hash being done with the hash already stored in the SHA hardware.
|-
| 0x010
| 0x020
| SHA-256 Hash of Firmware Section
|}

The contents of individual sections ''may'' be encrypted if the FIRM is not meant to be booted from NAND, i.e. if it is meant to be booted from SPI flash or NTR cartridge. If hash checks fail for all FIRM sections if treated as plaintext, it may be worth trying to check if the sections are encrypted. The encryption is detailed on [[Bootloader#Non-NAND_FIRM_boot|the bootloader page]].

== [[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 [[CONFIG_Registers|CFG_SYSPROT9]] 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 [[CONFIG_Registers#CFG_SYSPROT9|CFG_SYSPROT9]] bit 1 is clear (which means the OTP area is unlocked and so it knows that this is a hard reboot), it does the following things:
* 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 [[CONFIG_Registers#CFG_SYSPROT9|CFG_SYSPROT9]] bit 1 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 OTP 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|CFG_SYSPROT9]] to disable the OTP area.
* 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 [[CONFIG_Registers#CFG_SYSPROT9|CFG_SYSPROT9]] bit 1 is set(which means this happens only when this loader runs again for firm-launch), the normalkey, keyX, and keyY, for keyslot 0x11 are cleared to zero.

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]] - [[11.3.0-36|11.3.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.

== Variations ==
There exists different official firmwares for the 3DS: The default one (NATIVE_FIRM) is used to run all 3DS content and boots by default, while backwards compatibility is handled by TWL_FIRM and AGB_FIRM. There furthermore is a rescue mode provided by SAFE_MODE_FIRM.

=== NATIVE_FIRM ===
NATIVE_FIRM is the FIRM which is installed to the [[Flash_Filesystem|NAND]] firm partitions, which is loaded by bootrom.

Version history:

{| class="wikitable" border="1"
! System version
! old 3DS title version
! old 3DS hex title contentID
! Kernel/FIRM version (old 3DS/new 3DS)
! FIRM ARM11-sysmodule Product Code
|-
| [[Factory_Setup|Factory]] FIRM (titleID 00040001-00000002)
| v0
| 00
| 2.3-0
|-
| Pre-1.0. Referenced in the v1.0 Home Menu NCCH plain-region.
|
|
| 2.23-X
|-
| [[1.0.0-0|1.0.0]]
| v432
| 00
| 2.27-0
|-
| [[1.1.0-1|1.1.0]]
| v1472
| 02
| 2.28-0
|-
| [[2.0.0-2|2.0.0]]
| v2516
| 09
| 2.29-7
|-
| [[2.1.0-3|2.1.0]]
| v3553
| 0B
| 2.30-18
| 0608builder
|-
| [[2.2.0-X|2.2.0]]
| v4595
| 0F
| 2.31-40
| 0909builder
|-
| [[3.0.0-5|3.0.0]]
| v5647
| 18
| 2.32-15
| 1128builder
|-
| [[4.0.0-7|4.0.0]]
| v6677
| 1D
| 2.33-4
| 0406builder
|-
| [[4.1.0-8|4.1.0]]
| v7712
| 1F
| 2.34-0
| 0508builder
|-
| [[5.0.0-11|5.0.0]]
| v8758
| 25
| 2.35-6
| 0228builder
|-
| [[5.1.0-11|5.1.0]]
| v9792
| 26
| 2.36-0
| 0401builder
|-
| [[6.0.0-11|6.0.0]]
| v10833
| 29
| 2.37-0
| 0520builder
|-
| [[6.1.0-11|6.1.0]]
| v11872
| 2A
| 2.38-0
| 0625builder
|-
| [[7.0.0-13|7.0.0]]
| v12916
| 2E
| 2.39-4
| 1125builder
|-
| [[7.2.0-17|7.2.0]]
| v13956
| 30
| 2.40-0
| 0404builder
|-
| [[8.0.0-18|8.0.0]]
| v15047
| 37
| 2.44-6
| 0701builder
|-
| [[8.1.0-0_New3DS]]
|N/A
|N/A
| 2.45-5
|-
| [[9.0.0-20|9.0.0]]
| v17120
| 38
| 2.46-0
| 0828builder
|-
| [[9.3.0-21|9.3.0]]
| v18182
| 3F
| 2.48-3
| 1125builder
|-
| [[9.5.0-22|9.5.0]]
| v19216
| 40
| 2.49-0
| 0126builder
|-
| [[9.6.0-24|9.6.0]]
| v20262
| 49
| 2.50-1
| 0311builder
|-
| [[10.0.0-27|10.0.0]]
| v21288
| 4B
| 2.50-7
| 0812builder
|-
| [[10.2.0-28|10.2.0]]
| v22313
| 4C
| 2.50-9
| 1009builder
|-
| [[10.4.0-29|10.4.0]]
| v23341
| 50
| 2.50-11
| 1224builder
|-
| [[11.0.0-33|11.0.0]]
| v24368
| 52
| 2.51-0
| 0406builder
|-
| [[11.1.0-34|11.1.0]]
| v25396
| 56
| 2.51-2
| 0805builder
|-
| [[11.2.0-35|11.2.0]]
| v26432
| 58
| 2.52-0
| 1015builder
|-
| [[11.3.0-36|11.3.0]]
| v27476
| 5C
| 2.53-0
| 0126builder
|-
| [[11.4.0-37|11.4.0]]
| v28512
| 5E
| 2.54-0
| 0314builder
|-
| [[11.8.0-41|11.8.0]]
| v29557
| 64
| 2.55-0
| 0710pseg-ciuser
|-
| [[11.12.0-44|11.12.0]]
| v30593
| 66
| 2.56-0
| 1021pseg-ciuser
|-
| [[11.14.0-46|11.14.0]]
| v31633
| 69
| 2.57-0
| 0929pseg-ciuser
|}

The above kernel/FIRM versions are in the format: <KERNEL_VERSIONMAJOR>.<KERNEL_VERSIONMINOR>-<KERNEL_VERSIONREVISION>.

=== SAFE_MODE_FIRM ===
SAFE_MODE is used for running the [[System_Settings#System_Updater|System Updater]]. SAFE_MODE_FIRM and NATIVE_FIRM for the initial versions are exactly the same, except for the system core version fields. Kernel/FIRM versions for SAFE_MODE_FIRM are: (old3ds) v432 = 3.27-0, v5632 = 3.32-0, (new3ds) v16081 = 3.45-3.

=== TWL_FIRM ===
TWL_FIRM handles DS(i) backwards compatibility.

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

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

== 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 [[Configuration_Memory#0x1FF80016|writes some values]] about the boot environment to AXI WRAM during init to enable this.

Note: it seems NATIVE_FIRM ARM11-kernel didn't parse this during boot until [[3.0.0-5|3.0.0-X]]?

{| class="wikitable" border="1"
|-
! OFFSET
! SIZE
! DESCRIPTION
|-
| 0x000
| 0x300
| TWL auto-load parameters, passed as-is onto the new title. NS will only read the oldTitleId field from it and add it to the TWL title list if it's a CTR titleId
|-
| 0x300
| 0x100
| 'TLNC' block created by TWL applications, handled by NS for backwards-compatibility purposes. See [[NS#Auto-boot|here]] for more info.
|-
| 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 [[Filesystem_services#ProgramInfo|Program Info]], used by NS during NS startup, to launch the specified title when the below flag is set.
|-
| 0x450
| 0x10
| Titleinfo [[Filesystem_services#ProgramInfo|Program Info]]. 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:SetWirelessRebootInfo]].
|-
| 0x4B0
| 0x14
| SHA1-HMAC of the banner for TWL/NTR titles. This can be set by [[NSS:SetTWLBannerHMAC]].
|-
| 0x500
| 0x40
| This is used by [[APT:LoadSysMenuArg]] and [[APT:StoreSysMenuArg]].
|-
| 0xD50
| 0x20
| Atheros WiFi configuration struct
|-
| 0xD70
| 0x290
| [[Config Savegame|Config]] data struct for LGY FIRM.
|}

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

Atheros WiFi configuration struct for booting TWL_FIRM, from offset 0xD50. This struct is copied directly to 0x20005E0 in DSi memory. Since DSi cartridge ROMs include SDIO drivers for the wireless card and can't be updated, this structure allows interoperability between the original DSi wireless cards (AR6002/DWM-W015 and AR6013/DWM-W024) as well as the 3DS's AR6014/DWM-W028.
{| class="wikitable" border="1"
|-
! OFFSET
! SIZE
! DESCRIPTION
|-
| 0x0
| 0x1
| WiFi Board Type (1=DWM-W015, 2=DWM-W024, 3=DWM-W028; 0x03 on 3DS)
|-
| 0x1
| 0x1
| Unknown (0x00)
|-
| 0x2
| 0x2
| CRC16 from 0x4 to 0x20 (0x1C bytes)
|-
| 0x4
| 0x4
| Atheros RAM Vars/Host Interest address (0x520000 on 3DS)
|-
| 0x8
| 0x4
| Atheros RAM base (0x520000 on 3DS)
|-
| 0xC
| 0x4
| Atheros RAM size (0x20000 on 3DS)
|-
| 0x10
| 0x10
| Unknown (Zeroed)
|}

[[Config Savegame|Config]] struct for booting LGY FIRMs from offset 0xD70:
{| class="wikitable" border="1"
|-
! OFFSET
! SIZE
! DESCRIPTION
|-
| 0x0
| 0x1
| RTC compensation value (config block 0x30000).
|-
| 0x1
| 0x1
| Sound output mode (config block 0x70001).
|-
| 0x2
| 0x1
| System language (config block 0xA0002).
|-
| 0x3
| 0x1
| [[Cfg:SecureInfoGetRegion|Region from SecureInfo]] ("pseudo-block" 0x140000 in LGY FIRM).
|-
| 0x4
| 0xF
| [[CfgS:SecureInfoGetSerialNo|Serial number from SecureInfo]] ("pseudo-block" 0x140001 in LGY FIRM).
|-
| 0x13
| 0x1
| TWL country code (config block 0x100002).
|-
| 0x14
| 0x10
| TWL "movable" UID, used for DSiWare exports (config block 0x100003).
|-
| 0x24
| 0x2
| TWL EULA info (config block 0x100000).
|-
| 0x26
| 0x1
| Cleared to zero.
|-
| 0x27
| 0x1
| Cleared to zero.
|-
| 0x28
| 0x94
| TWL parental control data (config block 0x100001).
|-
| 0xBC
| 0x2
| LCD flicker calibration data (config block 0x50000).
|-
| 0xBE
| 0x2
| Backlight data (config block 0x50001).
|-
| 0xC0
| 0x38
| Backlight PWM table (config block 0x50002).
|-
| 0xF8
| 0x20
| Power saving mode (ABL) calibration (config block 0x50004).
|-
| 0x118
| 0x134
| CODEC calibration data (config block 0x20000).
|-
| 0x24C
| 0x10
| Touch screen calibration data (config block 0x40000).
|-
| 0x25C
| 0x1C
| Analog stick calibration data (config block 0x40001).
|-
| 0x278
| 0x4
| Cleared to zero.
|-
| 0x27C
| 0x4
| Cleared to zero.
|-
| 0x280
| 0x8
| User time offset (config block 0x30001).
|-
| 0x288
| 0x2
| CRC16 over the above fields from offset 0x0, size 0x288. If not valid, LGY FIRM uses dummy data from .(ro)data.
|-
| 0x28A
| 0x2
| Version, maybe? If non-zero, the size (below) is hardcoded (currently) to value 0x288, otherwise the size field below is used.
|-
| 0x28C
| 0x4
| Value 0x288 (size used for verifying the CRC16).
|}

"Cleared to zero" fields above are not read at all by LGY FIRM.

Application Manager Services

2017-11-06T17:45:03Z

Shinyquagsire23:

[[Category:Services]]

= Application Manager services "am:sys", "am:u", "am:net" =
{| class="wikitable" border="1"
|-
! Command Header
! Description
|-
| 0x00010040
| [[AM:GetNumPrograms|GetNumPrograms]]
|-
| 0x00020082
| [[AM:GetProgramList|GetProgramList]]
|-
| 0x00030084
| [[AM:GetProgramInfos|GetProgramInfos]]
|-
| 0x000400C0
| [[AM:DeleteUserProgram|DeleteUserProgram]]
|-
| 0x000500C0
| [[AM:GetProductCode|GetProductCode]]
|-
| 0x000600C0
| [[AM:GetStorageId|GetStorageId]]
|-
| 0x00070080
| [[AM:DeleteTicket|DeleteTicket]]
|-
| 0x00080000
| [[AM:GetNumTickets|GetNumTickets]]
|-
| 0x00090082
| [[AM:GetTicketList|GetTicketList]]
|-
| 0x000A0000
| [[AM:GetDeviceId|GetDeviceId]]
|-
| 0x000B0040
| [[AM:GetNumImportTitleContexts|GetNumImportTitleContexts]]
|-
| 0x000C0082
| [[AM:GetImportTitleContextList|GetImportTitleContextList]]
|-
| 0x000D0084
| [[AM:GetImportTitleContexts|GetImportTitleContexts]]
|-
| 0x000E00C0
| [[AM:DeleteImportTitleContext|DeleteImportTitleContext]]
|-
| 0x000F00C0
| [[AM:GetNumImportContentContexts|GetNumImportContentContexts]]
|-
| 0x00100102
| [[AM:GetImportContentContextList|GetImportContentContextList]]
|-
| 0x00110104
| [[AM:GetImportContentContexts|GetImportContentContexts]]
|-
| 0x00120102
| [[AM:DeleteImportContentContexts|DeleteImportContentContexts]]
|-
| 0x00130040
| [[AM:NeedsCleanup|NeedsCleanup]]
|-
| 0x00140040
| [[AM:DoCleanup|DoCleanup]]
|-
| 0x00150040
| [[AM:DeleteAllImportContexts|DeleteAllImportContexts]]
|-
| 0x00160000
| [[AM:DeleteAllTemporaryPrograms|DeleteAllTemporaryPrograms]]
|-
| 0x00170044
| [[AM:ImportTwlBackupLegacy|ImportTwlBackupLegacy]]
|-
| 0x00180080
| [[AM:InitializeTitleDatabase|InitializeTitleDatabase]]
|-
| 0x00190040
| [[AM:QueryAvailableTitleDatabase|QueryAvailableTitleDatabase]]
|-
| 0x001A00C0
| [[AM:CalcTwlBackupSize|CalcTwlBackupSize]]
|-
| 0x001B0144
| [[AM:ExportTwlBackup|ExportTwlBackup]]
|-
| 0x001C0084
| [[AM:ImportTwlBackup|ImportTwlBackup]]
|-
| 0x001D0000
| [[AM:DeleteAllTwlUserPrograms|DeleteAllTwlUserPrograms]]
|-
| 0x001E00C8
| [[AM:ReadTwlBackupInfo|ReadTwlBackupInfo]]
|-
| 0x001F0040
| [[AM:DeleteAllExpiredUserPrograms|DeleteAllExpiredUserPrograms]]
|-
| 0x00200000
| [[AM:GetTwlArchiveResourceInfo|GetTwlArchiveResourceInfo]]
|-
| 0x00210042
| [[AM:GetPersonalizedTicketInfoList|GetPersonalizedTicketInfoList]]
|-
| 0x00220080
| [[AM:DeleteAllImportContextsFiltered|DeleteAllImportContextsFiltered]]
|-
| 0x00230080
| [[AM:GetNumImportTitleContextsFiltered|GetNumImportTitleContextsFiltered]]
|-
| 0x002400C2
| [[AM:GetImportTitleContextListFiltered|GetImportTitleContextListFiltered]]
|-
| 0x002500C0
| [[AM:CheckContentRights|CheckContentRights]]
|-
| 0x00260044
| [[AM:GetTicketLimitInfos|GetTicketLimitInfos]]
|-
| 0x00270044
| [[AM:GetDemoLaunchInfos|GetDemoLaunchInfos]]
|-
| 0x00280108
| [[AM:ReadTwlBackupInfoEx|ReadTwlBackupInfoEx]]
|-
| 0x00290082
| [[AM:DeleteUserProgramsAtomically|DeleteUserProgramsAtomically]]
|-
| 0x002A00C0
| [[AM:GetNumExistingContentInfosSystem|GetNumExistingContentInfosSystem]]
|-
| 0x002B0142
| [[AM:ListExistingContentInfosSystem|ListExistingContentInfosSystem]]
|-
| 0x002C0084
| [[AM:GetProgramInfosIgnorePlatform|GetProgramInfosIgnorePlatform]]
|-
| 0x002D00C0
| [[AM:CheckContentRightsIgnorePlatform|CheckContentRightsIgnorePlatform]]
|}

= Application Manager services "am:u" and "am:net" =
{| class="wikitable" border="1"
|-
! Command Header
! Description
|-
| 0x04010080
| [[AM:UpdateFirmwareTo|UpdateFirmwareTo]]
|-
| 0x04020040
| [[AM:BeginImportProgram|BeginImportProgram]]
|-
| 0x04030000
| [[AM:BeginImportProgramTemporarily|BeginImportProgramTemporarily]]
|-
| 0x04040002
| [[AM:CancelImportProgram|CancelImportProgram]]
|-
| 0x04050002
| [[AM:EndImportProgram|EndImportProgram]]
|-
| 0x04060002
| [[AM:EndImportProgramWithoutCommit|EndImportProgramWithoutCommit]]
|-
| 0x040700C2
| [[AM:CommitImportPrograms|CommitImportPrograms]]
|-
| 0x04080042
| [[AM:GetProgramInfoFromCia|GetProgramInfoFromCia]]
|-
| 0x04090004
| [[AM:GetSystemMenuDataFromCia|GetSystemMenuDataFromCia]]
|-
| 0x040A0002
| [[AM:GetDependencyListFromCia|GetDependencyListFromCia]]
|-
| 0x040B0002
| [[AM:GetTransferSizeFromCia|GetTransferSizeFromCia]]
|-
| 0x040C0002
| [[AM:GetCoreVersionFromCia|GetCoreVersionFromCia]]
|-
| 0x040D0042
| [[AM:GetRequiredSizeFromCia|GetRequiredSizeFromCia]]
|-
| 0x040E00C2
| [[AM:CommitImportProgramsAndUpdateFirmwareAuto|CommitImportProgramsAndUpdateFirmwareAuto]]
|-
| 0x040F0000
| [[AM:UpdateFirmwareAuto|UpdateFirmwareAuto]]
|-
| 0x041000C0
| [[AM:DeleteProgram|DeleteProgram]]
|-
| 0x04110044
| [[AM:GetTwlProgramListForReboot|GetTwlProgramListForReboot]]
|-
| 0x04120000
| [[AM:GetSystemUpdaterMutex|GetSystemUpdaterMutex]]
|-
| 0x04130002
| [[AM:GetMetaSizeFromCia|GetMetaSizeFromCia]]
|-
| 0x04140044
| [[AM:GetMetaDataFromCia|GetMetaDataFromCia]]
|-
| 0x04150080
| [[AM:CheckDemoLaunchRights|CheckDemoLaunchRights]]
|-
| 0x041600C0
| [[AM:GetInternalTitleLocationInfo|GetInternalTitleLocationInfo]]
|-
| 0x041700C0
| [[AM:PerpetuateAgbSaveData|PerpetuateAgbSaveData]]
|-
| 0x04180040
| [[AM:BeginImportProgramForOverWrite|BeginImportProgramForOverWrite]]
|-
| 0x04190000
| [[AM:BeginImportSystemProgram|BeginImportSystemProgram]]
|}

= Application Manager service "am:app" =
{| class="wikitable" border="1"
|-
! Command Header
! Description
|-
| 0x100100C0
| [[AM:GetDLCContentInfoCount|GetDLCContentInfoCount]]
|-
| 0x10020104
| [[AM:FindDLCContentInfos|FindDLCContentInfos]]
|-
| 0x10030142
| [[AM:ListDLCContentInfos|ListDLCContentInfos]]
|-
| 0x10040102
| [[AM:DeleteContents|DeleteContents]]
|-
| 0x10050084
| [[AM:GetDLCTitleInfos|GetDLCTitleInfos]]
|-
| 0x10060080
| [[AM:GetNumDataTitleTickets|GetNumDataTitleTickets]]
|-
| 0x10070102
| [[AM:ListDataTitleTicketInfos|ListDataTitleTicketInfos]]
|-
| 0x100801C2
| [[AM:GetItemRights|GetItemRights]]
|-
| 0x100900C0
| [[AM:IsDataTitleInUse|IsDataTitleInUse]]
|-
| 0x100A0000
| [[AM:IsExternalTitleDatabaseInitialized|IsExternalTitleDatabaseInitialized]]
|-
| 0x100B00C0
| [[AM:GetNumExistingContentInfos|GetNumExistingContentInfos]]
|-
| 0x100C0142
| [[AM:ListExistingContentInfos|ListExistingContentInfos]]
|-
| 0x100D0084
| [[AM:GetPatchTitleInfos|GetPatchTitleInfos]]
|}

The only commands accessible with this service are listed under this section.

= Application Manager service "am:sys" =
This service only has access to the 0x00XX* commands listed above, and the "am:app" commands.

= Application Manager service "am:u" =

= Application Manager network service "am:net" =
{| class="wikitable" border="1"
|-
! Command Header
! Description
|-
| 0x08010000
| [[AMNet:BeginImportTicket|BeginImportTicket]]
|-
| 0x08020002
| [[AMNet:CancelImportTicket|CancelImportTicket]]
|-
| 0x08030002
| [[AMNet:EndImportTicket|EndImportTicket]]
|-
| 0x08040100
| [[AMNet:BeginImportTitle|BeginImportTitle]]
|-
| 0x08050000
| [[AMNet:StopImportTitle|StopImportTitle]]
|-
| 0x080600C0
| [[AMNet:ResumeImportTitle|ResumeImportTitle]]
|-
| 0x08070000
| [[AMNet:CancelImportTitle|CancelImportTitle]]
|-
| 0x08080000
| [[AMNet:EndImportTitle|EndImportTitle]]
|-
| 0x080900C2
| [[AMNet:CommitImportTitles|CommitImportTitles]]
|-
| 0x080A0000
| [[AMNet:BeginImportTmd|BeginImportTmd]]
|-
| 0x080B0002
| [[AMNet:CancelImportTmd|CancelImportTmd]]
|-
| 0x080C0042
| [[AMNet:EndImportTmd|EndImportTmd]]
|-
| 0x080D0042
| [[AMNet:CreateImportContentContexts|CreateImportContentContexts]]
|-
| 0x080E0040
| [[AMNet:BeginImportContent|BeginImportContent]]
|-
| 0x080F0002
| [[AMNet:StopImportContent|StopImportContent]]
|-
| 0x08100040
| [[AMNet:ResumeImportContent|ResumeImportContent]]
|-
| 0x08110002
| [[AMNet:CancelImportContent|CancelImportContent]]
|-
| 0x08120002
| [[AMNet:EndImportContent|EndImportContent]]
|-
| 0x08130000
| [[AMNet:GetNumCurrentImportContentContexts|GetNumCurrentImportContentContexts]]
|-
| 0x08140042
| [[AMNet:GetCurrentImportContentContextList|GetCurrentImportContentContextList]]
|-
| 0x08150044
| [[AMNet:GetCurrentImportContentContexts|GetCurrentImportContentContexts]]
|-
| 0x08160146
| [[AMNet:Sign|Sign]]
|-
| 0x08170146
| [[AMNet:Verify|Verify]]
|-
| 0x08180042
| [[AMNet:GetDeviceCert|GetDeviceCert]]
|-
| 0x08190108
| [[AMNet:ImportCertificates|ImportCertificates]]
|-
| 0x081A0042
| [[AMNet:ImportCertificate|ImportCertificate]]
|-
| 0x081B00C2
| [[AMNet:CommitImportTitlesAndUpdateFirmwareAuto|CommitImportTitlesAndUpdateFirmwareAuto]]
|-
| 0x081C0100
| [[AMNet:DeleteTicketId|DeleteTicketId]]
|-
| 0x081D0080
| [[AMNet:GetNumTicketIds|GetNumTicketIds]]
|-
| 0x081E0102
| [[AMNet:GetTicketIdList|GetTicketIdList]]
|-
| 0x081F0080
| [[AMNet:GetNumTicketsOfProgram|GetNumTicketsOfProgram]]
|-
| 0x08200102
| [[AMNet:ListTicketInfos|ListTicketInfos]]
|-
| 0x08210142
| [[AMNet:GetRightsOnlyTicketData|GetRightsOnlyTicketData]]
|-
| 0x08220000
| [[AMNet:GetNumCurrentContentInfos|GetNumCurrentContentInfos]]
|-
| 0x08230044
| [[AMNet:FindCurrentContentInfos|FindCurrentContentInfos]]
|-
| 0x08240082
| [[AMNet:ListCurrentContentInfos|ListCurrentContentInfos]]
|-
| 0x08250102
| [[AMNet:CalculateContextRequiredSize|CalculateContextRequiredSize]]
|-
| 0x08260042
| [[AMNet:UpdateImportContentContexts|UpdateImportContentContexts]]
|-
| 0x08270000
| [[AMNet:DeleteAllDemoLaunchInfos|DeleteAllDemoLaunchInfos]]
|-
| 0x082800C0
| [[AMNet:BeginImportTitleForOverWrite|BeginImportTitleForOverWrite]]
|}

= File service =
{| class="wikitable" border="1"
|-
! Command Header
! Available since system-version
! Description
|-
| 0x0001....
|
| Stubbed. After validating the translate-paramater headers, this just returns error 0xE0C046F8.
|-
| 0x0401....
|
| ?
|-
| 0x08010100
|
| ?
|-
| 0x080200C2
|
| [[AMFile:Read|Read]]
|-
| 0x08030102
|
| [[AMFile:Write|Write]]
|-
| 0x08040000
|
| [[AMFile:GetSize|GetSize]]
|-
| 0x08050080
|
| [[AMFile:SetSize|SetSize]]
|-
| 0x08060000
|
| ?
|-
| 0x08070000
|
| ?
|-
| 0x08080000
|
| [[AMFile:Close|Close]]
|-
| 0x08090000
|
| ?
|-
| 0x080A0000
|
| This just returns 0.
|-
| 0x080B0000
|
| This just returns 0.
|-
| 0x080C0000
|
| This just returns 0.
|}

This is similar to [[Filesystem_services#File_service|FSFile]].

For handling each command that's actually implemented, the AM cmdhandler function calls a vtable funcptr.

The private port for this seems to be referred to as "am:pipe", even though the "am:pipe" string isn't actually used.

=Types=
==TicketInfo==
{| class="wikitable" border="1"
|-
! Offset
! Length
! Description
|-
| 0x0
| 0x8
| Title ID
|-
| 0x8
| 0x8
| Ticket ID
|-
| 0x10
| 0x2
| Version
|-
| 0x12
| 0x2
| Padding
|-
| 0x14
| 0x4
| Size
|}

==TitleInfo==
{| class="wikitable" border="1"
|-
! Offset
! Length
! Description
|-
| 0x0
| 0x8
| Title ID
|-
| 0x8
| 0x8
| Size
|-
| 0x10
| 0x2
| Version
|-
| 0x12
| 0x2
| Padding
|-
| 0x14
| 0x4
| Type
|}

==ContentInfo==
{| class="wikitable" border="1"
|-
! Offset
! Length
! Description
|-
| 0x0
| 0x2
| Index
|-
| 0x2
| 0x2
| Type
|-
| 0x4
| 0x4
| Content ID
|-
| 0x8
| 0x8
| Size
|-
| 0x10
| 0x8
| RomFS Size
|}

==ImportTitleContext==
{| class="wikitable" border="1"
|-
! Offset
! Length
! Description
|-
| 0x0
| 0x8
| Title ID
|-
| 0x8
| 0x2
| Version
|-
| 0xA
| 0x2
| State
|-
| 0xC
| 0x4
| Type
|-
| 0x10
| 0x8
| Size
|}

===ImportTitleContextState===
{| class="wikitable" border="1"
|-
! Value
! Description
|-
| 0
| None
|-
| 1
| Waiting for import
|-
| 2
| Resumable
|-
| 3
| Waiting for commit
|-
| 4
| Already exists
|-
| 5
| Deleting
|-
| 6
| Needs cleanup
|}

==ImportContentContext==
{| class="wikitable" border="1"
|-
! Offset
! Length
! Description
|-
| 0x0
| 0x4
| Content ID
|-
| 0x4
| 0x2
| Index
|-
| 0x6
| 0x2
| Type
|-
| 0x8
| 0x8
| Size
|-
| 0x10
| 0x8
| Current Install Offset
|}

=Errors=
See [[Application_Manager_Services_PXI|this]].

AM:GetNumContentInfos

2017-11-06T17:43:44Z

Shinyquagsire23: Shinyquagsire23 moved page AM:GetNumContentInfos to AM:GetDLCContentInfoCount: doesn't work with anything except DLC

#REDIRECT [[AM:GetDLCContentInfoCount]]

AM:GetDLCContentInfoCount

2017-11-06T17:43:43Z

Shinyquagsire23: Shinyquagsire23 moved page AM:GetNumContentInfos to AM:GetDLCContentInfoCount: doesn't work with anything except DLC

TID high value must be 0x0004008C, otherwise 0xE0E0801F is returned.
=Request=
{| class="wikitable" border="1"
|-
! Index Word
! Description
|-
| 0
| Header code [0x100100C0]
|-
| 1
| [[Filesystem_services#MediaType|Media Type]]
|-
| 2-3
| u64, Title ID
|}

=Response=
{| class="wikitable" border="1"
|-
! Index Word
! Description
|-
| 0
| Header code
|-
| 1
| Result code
|-
| 2
| Number of Content Infos
|}

AM:GetDLCContentInfoCount

2017-11-06T17:22:57Z

Shinyquagsire23: oh look the error code is different on this one

Application Manager Services

2017-11-03T17:18:54Z

Shinyquagsire23: Renamed more calls for clarity

[[Category:Services]]

= Application Manager services "am:sys", "am:u", "am:net" =
{| class="wikitable" border="1"
|-
! Command Header
! Description
|-
| 0x00010040
| [[AM:GetNumPrograms|GetNumPrograms]]
|-
| 0x00020082
| [[AM:GetProgramList|GetProgramList]]
|-
| 0x00030084
| [[AM:GetProgramInfos|GetProgramInfos]]
|-
| 0x000400C0
| [[AM:DeleteUserProgram|DeleteUserProgram]]
|-
| 0x000500C0
| [[AM:GetProductCode|GetProductCode]]
|-
| 0x000600C0
| [[AM:GetStorageId|GetStorageId]]
|-
| 0x00070080
| [[AM:DeleteTicket|DeleteTicket]]
|-
| 0x00080000
| [[AM:GetNumTickets|GetNumTickets]]
|-
| 0x00090082
| [[AM:GetTicketList|GetTicketList]]
|-
| 0x000A0000
| [[AM:GetDeviceId|GetDeviceId]]
|-
| 0x000B0040
| [[AM:GetNumImportTitleContexts|GetNumImportTitleContexts]]
|-
| 0x000C0082
| [[AM:GetImportTitleContextList|GetImportTitleContextList]]
|-
| 0x000D0084
| [[AM:GetImportTitleContexts|GetImportTitleContexts]]
|-
| 0x000E00C0
| [[AM:DeleteImportTitleContext|DeleteImportTitleContext]]
|-
| 0x000F00C0
| [[AM:GetNumImportContentContexts|GetNumImportContentContexts]]
|-
| 0x00100102
| [[AM:GetImportContentContextList|GetImportContentContextList]]
|-
| 0x00110104
| [[AM:GetImportContentContexts|GetImportContentContexts]]
|-
| 0x00120102
| [[AM:DeleteImportContentContexts|DeleteImportContentContexts]]
|-
| 0x00130040
| [[AM:NeedsCleanup|NeedsCleanup]]
|-
| 0x00140040
| [[AM:DoCleanup|DoCleanup]]
|-
| 0x00150040
| [[AM:DeleteAllImportContexts|DeleteAllImportContexts]]
|-
| 0x00160000
| [[AM:DeleteAllTemporaryPrograms|DeleteAllTemporaryPrograms]]
|-
| 0x00170044
| [[AM:ImportTwlBackupLegacy|ImportTwlBackupLegacy]]
|-
| 0x00180080
| [[AM:InitializeTitleDatabase|InitializeTitleDatabase]]
|-
| 0x00190040
| [[AM:QueryAvailableTitleDatabase|QueryAvailableTitleDatabase]]
|-
| 0x001A00C0
| [[AM:CalcTwlBackupSize|CalcTwlBackupSize]]
|-
| 0x001B0144
| [[AM:ExportTwlBackup|ExportTwlBackup]]
|-
| 0x001C0084
| [[AM:ImportTwlBackup|ImportTwlBackup]]
|-
| 0x001D0000
| [[AM:DeleteAllTwlUserPrograms|DeleteAllTwlUserPrograms]]
|-
| 0x001E00C8
| [[AM:ReadTwlBackupInfo|ReadTwlBackupInfo]]
|-
| 0x001F0040
| [[AM:DeleteAllExpiredUserPrograms|DeleteAllExpiredUserPrograms]]
|-
| 0x00200000
| [[AM:GetTwlArchiveResourceInfo|GetTwlArchiveResourceInfo]]
|-
| 0x00210042
| [[AM:GetPersonalizedTicketInfoList|GetPersonalizedTicketInfoList]]
|-
| 0x00220080
| [[AM:DeleteAllImportContextsFiltered|DeleteAllImportContextsFiltered]]
|-
| 0x00230080
| [[AM:GetNumImportTitleContextsFiltered|GetNumImportTitleContextsFiltered]]
|-
| 0x002400C2
| [[AM:GetImportTitleContextListFiltered|GetImportTitleContextListFiltered]]
|-
| 0x002500C0
| [[AM:CheckContentRights|CheckContentRights]]
|-
| 0x00260044
| [[AM:GetTicketLimitInfos|GetTicketLimitInfos]]
|-
| 0x00270044
| [[AM:GetDemoLaunchInfos|GetDemoLaunchInfos]]
|-
| 0x00280108
| [[AM:ReadTwlBackupInfoEx|ReadTwlBackupInfoEx]]
|-
| 0x00290082
| [[AM:DeleteUserProgramsAtomically|DeleteUserProgramsAtomically]]
|-
| 0x002A00C0
| [[AM:GetNumExistingContentInfosSystem|GetNumExistingContentInfosSystem]]
|-
| 0x002B0142
| [[AM:ListExistingContentInfosSystem|ListExistingContentInfosSystem]]
|-
| 0x002C0084
| [[AM:GetProgramInfosIgnorePlatform|GetProgramInfosIgnorePlatform]]
|-
| 0x002D00C0
| [[AM:CheckContentRightsIgnorePlatform|CheckContentRightsIgnorePlatform]]
|}

= Application Manager services "am:u" and "am:net" =
{| class="wikitable" border="1"
|-
! Command Header
! Description
|-
| 0x04010080
| [[AM:UpdateFirmwareTo|UpdateFirmwareTo]]
|-
| 0x04020040
| [[AM:BeginImportProgram|BeginImportProgram]]
|-
| 0x04030000
| [[AM:BeginImportProgramTemporarily|BeginImportProgramTemporarily]]
|-
| 0x04040002
| [[AM:CancelImportProgram|CancelImportProgram]]
|-
| 0x04050002
| [[AM:EndImportProgram|EndImportProgram]]
|-
| 0x04060002
| [[AM:EndImportProgramWithoutCommit|EndImportProgramWithoutCommit]]
|-
| 0x040700C2
| [[AM:CommitImportPrograms|CommitImportPrograms]]
|-
| 0x04080042
| [[AM:GetProgramInfoFromCia|GetProgramInfoFromCia]]
|-
| 0x04090004
| [[AM:GetSystemMenuDataFromCia|GetSystemMenuDataFromCia]]
|-
| 0x040A0002
| [[AM:GetDependencyListFromCia|GetDependencyListFromCia]]
|-
| 0x040B0002
| [[AM:GetTransferSizeFromCia|GetTransferSizeFromCia]]
|-
| 0x040C0002
| [[AM:GetCoreVersionFromCia|GetCoreVersionFromCia]]
|-
| 0x040D0042
| [[AM:GetRequiredSizeFromCia|GetRequiredSizeFromCia]]
|-
| 0x040E00C2
| [[AM:CommitImportProgramsAndUpdateFirmwareAuto|CommitImportProgramsAndUpdateFirmwareAuto]]
|-
| 0x040F0000
| [[AM:UpdateFirmwareAuto|UpdateFirmwareAuto]]
|-
| 0x041000C0
| [[AM:DeleteProgram|DeleteProgram]]
|-
| 0x04110044
| [[AM:GetTwlProgramListForReboot|GetTwlProgramListForReboot]]
|-
| 0x04120000
| [[AM:GetSystemUpdaterMutex|GetSystemUpdaterMutex]]
|-
| 0x04130002
| [[AM:GetMetaSizeFromCia|GetMetaSizeFromCia]]
|-
| 0x04140044
| [[AM:GetMetaDataFromCia|GetMetaDataFromCia]]
|-
| 0x04150080
| [[AM:CheckDemoLaunchRights|CheckDemoLaunchRights]]
|-
| 0x041600C0
| [[AM:GetInternalTitleLocationInfo|GetInternalTitleLocationInfo]]
|-
| 0x041700C0
| [[AM:PerpetuateAgbSaveData|PerpetuateAgbSaveData]]
|-
| 0x04180040
| [[AM:BeginImportProgramForOverWrite|BeginImportProgramForOverWrite]]
|-
| 0x04190000
| [[AM:BeginImportSystemProgram|BeginImportSystemProgram]]
|}

= Application Manager service "am:app" =
{| class="wikitable" border="1"
|-
! Command Header
! Description
|-
| 0x100100C0
| [[AM:GetNumContentInfos|GetNumContentInfos]]
|-
| 0x10020104
| [[AM:FindDLCContentInfos|FindDLCContentInfos]]
|-
| 0x10030142
| [[AM:ListDLCContentInfos|ListDLCContentInfos]]
|-
| 0x10040102
| [[AM:DeleteContents|DeleteContents]]
|-
| 0x10050084
| [[AM:GetDLCTitleInfos|GetDLCTitleInfos]]
|-
| 0x10060080
| [[AM:GetNumDataTitleTickets|GetNumDataTitleTickets]]
|-
| 0x10070102
| [[AM:ListDataTitleTicketInfos|ListDataTitleTicketInfos]]
|-
| 0x100801C2
| [[AM:GetItemRights|GetItemRights]]
|-
| 0x100900C0
| [[AM:IsDataTitleInUse|IsDataTitleInUse]]
|-
| 0x100A0000
| [[AM:IsExternalTitleDatabaseInitialized|IsExternalTitleDatabaseInitialized]]
|-
| 0x100B00C0
| [[AM:GetNumExistingContentInfos|GetNumExistingContentInfos]]
|-
| 0x100C0142
| [[AM:ListExistingContentInfos|ListExistingContentInfos]]
|-
| 0x100D0084
| [[AM:GetPatchTitleInfos|GetPatchTitleInfos]]
|}

The only commands accessible with this service are listed under this section.

= Application Manager service "am:sys" =
This service only has access to the 0x00XX* commands listed above, and the "am:app" commands.

= Application Manager service "am:u" =

= Application Manager network service "am:net" =
{| class="wikitable" border="1"
|-
! Command Header
! Description
|-
| 0x08010000
| [[AMNet:BeginImportTicket|BeginImportTicket]]
|-
| 0x08020002
| [[AMNet:CancelImportTicket|CancelImportTicket]]
|-
| 0x08030002
| [[AMNet:EndImportTicket|EndImportTicket]]
|-
| 0x08040100
| [[AMNet:BeginImportTitle|BeginImportTitle]]
|-
| 0x08050000
| [[AMNet:StopImportTitle|StopImportTitle]]
|-
| 0x080600C0
| [[AMNet:ResumeImportTitle|ResumeImportTitle]]
|-
| 0x08070000
| [[AMNet:CancelImportTitle|CancelImportTitle]]
|-
| 0x08080000
| [[AMNet:EndImportTitle|EndImportTitle]]
|-
| 0x080900C2
| [[AMNet:CommitImportTitles|CommitImportTitles]]
|-
| 0x080A0000
| [[AMNet:BeginImportTmd|BeginImportTmd]]
|-
| 0x080B0002
| [[AMNet:CancelImportTmd|CancelImportTmd]]
|-
| 0x080C0042
| [[AMNet:EndImportTmd|EndImportTmd]]
|-
| 0x080D0042
| [[AMNet:CreateImportContentContexts|CreateImportContentContexts]]
|-
| 0x080E0040
| [[AMNet:BeginImportContent|BeginImportContent]]
|-
| 0x080F0002
| [[AMNet:StopImportContent|StopImportContent]]
|-
| 0x08100040
| [[AMNet:ResumeImportContent|ResumeImportContent]]
|-
| 0x08110002
| [[AMNet:CancelImportContent|CancelImportContent]]
|-
| 0x08120002
| [[AMNet:EndImportContent|EndImportContent]]
|-
| 0x08130000
| [[AMNet:GetNumCurrentImportContentContexts|GetNumCurrentImportContentContexts]]
|-
| 0x08140042
| [[AMNet:GetCurrentImportContentContextList|GetCurrentImportContentContextList]]
|-
| 0x08150044
| [[AMNet:GetCurrentImportContentContexts|GetCurrentImportContentContexts]]
|-
| 0x08160146
| [[AMNet:Sign|Sign]]
|-
| 0x08170146
| [[AMNet:Verify|Verify]]
|-
| 0x08180042
| [[AMNet:GetDeviceCert|GetDeviceCert]]
|-
| 0x08190108
| [[AMNet:ImportCertificates|ImportCertificates]]
|-
| 0x081A0042
| [[AMNet:ImportCertificate|ImportCertificate]]
|-
| 0x081B00C2
| [[AMNet:CommitImportTitlesAndUpdateFirmwareAuto|CommitImportTitlesAndUpdateFirmwareAuto]]
|-
| 0x081C0100
| [[AMNet:DeleteTicketId|DeleteTicketId]]
|-
| 0x081D0080
| [[AMNet:GetNumTicketIds|GetNumTicketIds]]
|-
| 0x081E0102
| [[AMNet:GetTicketIdList|GetTicketIdList]]
|-
| 0x081F0080
| [[AMNet:GetNumTicketsOfProgram|GetNumTicketsOfProgram]]
|-
| 0x08200102
| [[AMNet:ListTicketInfos|ListTicketInfos]]
|-
| 0x08210142
| [[AMNet:GetRightsOnlyTicketData|GetRightsOnlyTicketData]]
|-
| 0x08220000
| [[AMNet:GetNumCurrentContentInfos|GetNumCurrentContentInfos]]
|-
| 0x08230044
| [[AMNet:FindCurrentContentInfos|FindCurrentContentInfos]]
|-
| 0x08240082
| [[AMNet:ListCurrentContentInfos|ListCurrentContentInfos]]
|-
| 0x08250102
| [[AMNet:CalculateContextRequiredSize|CalculateContextRequiredSize]]
|-
| 0x08260042
| [[AMNet:UpdateImportContentContexts|UpdateImportContentContexts]]
|-
| 0x08270000
| [[AMNet:DeleteAllDemoLaunchInfos|DeleteAllDemoLaunchInfos]]
|-
| 0x082800C0
| [[AMNet:BeginImportTitleForOverWrite|BeginImportTitleForOverWrite]]
|}

= File service =
{| class="wikitable" border="1"
|-
! Command Header
! Available since system-version
! Description
|-
| 0x0001....
|
| Stubbed. After validating the translate-paramater headers, this just returns error 0xE0C046F8.
|-
| 0x0401....
|
| ?
|-
| 0x08010100
|
| ?
|-
| 0x080200C2
|
| [[AMFile:Read|Read]]
|-
| 0x08030102
|
| [[AMFile:Write|Write]]
|-
| 0x08040000
|
| [[AMFile:GetSize|GetSize]]
|-
| 0x08050080
|
| [[AMFile:SetSize|SetSize]]
|-
| 0x08060000
|
| ?
|-
| 0x08070000
|
| ?
|-
| 0x08080000
|
| [[AMFile:Close|Close]]
|-
| 0x08090000
|
| ?
|-
| 0x080A0000
|
| This just returns 0.
|-
| 0x080B0000
|
| This just returns 0.
|-
| 0x080C0000
|
| This just returns 0.
|}

This is similar to [[Filesystem_services#File_service|FSFile]].

For handling each command that's actually implemented, the AM cmdhandler function calls a vtable funcptr.

The private port for this seems to be referred to as "am:pipe", even though the "am:pipe" string isn't actually used.

=Types=
==TicketInfo==
{| class="wikitable" border="1"
|-
! Offset
! Length
! Description
|-
| 0x0
| 0x8
| Title ID
|-
| 0x8
| 0x8
| Ticket ID
|-
| 0x10
| 0x2
| Version
|-
| 0x12
| 0x2
| Padding
|-
| 0x14
| 0x4
| Size
|}

==TitleInfo==
{| class="wikitable" border="1"
|-
! Offset
! Length
! Description
|-
| 0x0
| 0x8
| Title ID
|-
| 0x8
| 0x8
| Size
|-
| 0x10
| 0x2
| Version
|-
| 0x12
| 0x2
| Padding
|-
| 0x14
| 0x4
| Type
|}

==ContentInfo==
{| class="wikitable" border="1"
|-
! Offset
! Length
! Description
|-
| 0x0
| 0x2
| Index
|-
| 0x2
| 0x2
| Type
|-
| 0x4
| 0x4
| Content ID
|-
| 0x8
| 0x8
| Size
|-
| 0x10
| 0x8
| RomFS Size
|}

==ImportTitleContext==
{| class="wikitable" border="1"
|-
! Offset
! Length
! Description
|-
| 0x0
| 0x8
| Title ID
|-
| 0x8
| 0x2
| Version
|-
| 0xA
| 0x2
| State
|-
| 0xC
| 0x4
| Type
|-
| 0x10
| 0x8
| Size
|}

===ImportTitleContextState===
{| class="wikitable" border="1"
|-
! Value
! Description
|-
| 0
| None
|-
| 1
| Waiting for import
|-
| 2
| Resumable
|-
| 3
| Waiting for commit
|-
| 4
| Already exists
|-
| 5
| Deleting
|-
| 6
| Needs cleanup
|}

==ImportContentContext==
{| class="wikitable" border="1"
|-
! Offset
! Length
! Description
|-
| 0x0
| 0x4
| Content ID
|-
| 0x4
| 0x2
| Index
|-
| 0x6
| 0x2
| Type
|-
| 0x8
| 0x8
| Size
|-
| 0x10
| 0x8
| Current Install Offset
|}

=Errors=
See [[Application_Manager_Services_PXI|this]].

AM:FindContentInfos

2017-11-03T17:17:37Z

Shinyquagsire23: Shinyquagsire23 moved page AM:FindContentInfos to AM:FindDLCContentInfos

#REDIRECT [[AM:FindDLCContentInfos]]

AM:FindDLCContentInfos

2017-11-03T17:17:37Z

Shinyquagsire23: Shinyquagsire23 moved page AM:FindContentInfos to AM:FindDLCContentInfos

TID high value must be 0x0004008C, otherwise 0xE0E0803C is returned.
=Request=
{| class="wikitable" border="1"
|-
! Index Word
! Description
|-
| 0
| Header code [0x10020104]
|-
| 1
| [[Filesystem_services#MediaType|Media Type]]
|-
| 2-3
| u64, Title ID
|-
| 4
| Content Count
|-
| 5
| ((Content Count * 2) << 4) <nowiki>|</nowiki> 0xA
|-
| 6
| Content Indices Input Pointer
|-
| 7
| ((Content Count * 0x18) << 4) <nowiki>|</nowiki> 0xC
|-
| 8
| [[Application_Manager_Services#ContentInfo|Content Infos]] Output Pointer
|}

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

AM:ListContentInfos

2017-11-03T17:17:20Z

Shinyquagsire23: Shinyquagsire23 moved page AM:ListContentInfos to AM:ListDLCContentInfos: These *only* work on DLC.

#REDIRECT [[AM:ListDLCContentInfos]]

AM:ListDLCContentInfos

2017-11-03T17:17:20Z

Shinyquagsire23: Shinyquagsire23 moved page AM:ListContentInfos to AM:ListDLCContentInfos: These *only* work on DLC.

TID high value must be 0x0004008C, otherwise 0xE0E0803C is returned.
=Request=
{| class="wikitable" border="1"
|-
! Index Word
! Description
|-
| 0
| Header code [0x10030142]
|-
| 1
| Content Count
|-
| 2
| [[Filesystem_services#MediaType|Media Type]]
|-
| 3-4
| u64, Title ID
|-
| 5
| Offset
|-
| 6
| ((Content Count * 0x18) << 4) <nowiki>|</nowiki> 0xC
|-
| 7
| [[Application_Manager_Services#ContentInfo|Content Infos]] Output Pointer
|}

=Response=
{| class="wikitable" border="1"
|-
! Index Word
! Description
|-
| 0
| Header code
|-
| 1
| Result code
|-
| 2
| Number of Content Infos Read
|}

AM:ListDLCContentInfos

2017-11-03T17:15:12Z

Shinyquagsire23:

AM:FindDLCContentInfos

2017-11-03T17:15:05Z

Shinyquagsire23:

AM:GetPatchTitleInfos

2017-10-26T15:38:00Z

Shinyquagsire23:

Iterates through a list of TIDs to return [[Application_Manager_Services#TitleInfo|Title Infos]]. One pass over the TID list is done initially to validate that all TID high values are 0x0004000E, otherwise 0xE0E0803C is returned. [[Application_Manager_Services#TitleInfo|Title Info]] is only written once all titles are validated as patch titles.
=Request=
{| class="wikitable" border="1"
|-
! Index Word
! Description
|-
| 0
| Header code [0x100D0084]
|-
| 1
| [[Filesystem_services#MediaType|Media Type]]
|-
| 2
| Title Count
|-
| 3
| ((Title Count * 8) << 4) <nowiki>|</nowiki> 0xA
|-
| 4
| Title IDs Input Pointer
|-
| 5
| ((Title Count * 0x18) << 4) <nowiki>|</nowiki> 0xC
|-
| 6
| [[Application_Manager_Services#TitleInfo|Title Infos]] Output Pointer
|}

=Response=
{| class="wikitable" border="1"
|-
! Index Word
! Description
|-
| 0
| Header code
|-
| 1
| Result code
|-
| 2
| ((Title Count * 8) << 4) <nowiki>|</nowiki> 0xA
|-
| 3
| Title IDs Pointer
|-
| 4
| ((Title Count * 0x18) << 4) <nowiki>|</nowiki> 0xC
|-
| 5
| [[Application_Manager_Services#TitleInfo|Title Infos]] Pointer
|}

AM:GetDLCTitleInfos

2017-10-26T15:37:12Z

Shinyquagsire23:

Iterates through a list of TIDs to return [[Application_Manager_Services#TitleInfo|Title Infos]]. One pass over the TID list is done initially to validate that all TID high values are 0x0004008C, otherwise 0xE0E0803C is returned. [[Application_Manager_Services#TitleInfo|Title Info]] is only written once all titles are validated as DLC.
=Request=
{| class="wikitable" border="1"
|-
! Index Word
! Description
|-
| 0
| Header code [0x10050084]
|-
| 1
| [[Filesystem_services#MediaType|Media Type]]
|-
| 2
| Title Count
|-
| 3
| ((Title Count * 8) << 4) <nowiki>|</nowiki> 0xA
|-
| 4
| Title IDs Input Pointer
|-
| 5
| ((Title Count * 0x18) << 4) <nowiki>|</nowiki> 0xC
|-
| 6
| [[Application_Manager_Services#TitleInfo|Title Infos]] Output Pointer
|}

=Response=
{| class="wikitable" border="1"
|-
! Index Word
! Description
|-
| 0
| Header code
|-
| 1
| Result code
|-
| 2
| ((Title Count * 8) << 4) <nowiki>|</nowiki> 0xA
|-
| 3
| Title IDs Pointer
|-
| 4
| ((Title Count * 0x18) << 4) <nowiki>|</nowiki> 0xC
|-
| 5
| [[Application_Manager_Services#TitleInfo|Title Infos]] Pointer
|}

Application Manager Services

2017-10-26T15:31:14Z

Shinyquagsire23: /* Application Manager service "am:app" */

[[Category:Services]]

= Application Manager services "am:sys", "am:u", "am:net" =
{| class="wikitable" border="1"
|-
! Command Header
! Description
|-
| 0x00010040
| [[AM:GetNumPrograms|GetNumPrograms]]
|-
| 0x00020082
| [[AM:GetProgramList|GetProgramList]]
|-
| 0x00030084
| [[AM:GetProgramInfos|GetProgramInfos]]
|-
| 0x000400C0
| [[AM:DeleteUserProgram|DeleteUserProgram]]
|-
| 0x000500C0
| [[AM:GetProductCode|GetProductCode]]
|-
| 0x000600C0
| [[AM:GetStorageId|GetStorageId]]
|-
| 0x00070080
| [[AM:DeleteTicket|DeleteTicket]]
|-
| 0x00080000
| [[AM:GetNumTickets|GetNumTickets]]
|-
| 0x00090082
| [[AM:GetTicketList|GetTicketList]]
|-
| 0x000A0000
| [[AM:GetDeviceId|GetDeviceId]]
|-
| 0x000B0040
| [[AM:GetNumImportTitleContexts|GetNumImportTitleContexts]]
|-
| 0x000C0082
| [[AM:GetImportTitleContextList|GetImportTitleContextList]]
|-
| 0x000D0084
| [[AM:GetImportTitleContexts|GetImportTitleContexts]]
|-
| 0x000E00C0
| [[AM:DeleteImportTitleContext|DeleteImportTitleContext]]
|-
| 0x000F00C0
| [[AM:GetNumImportContentContexts|GetNumImportContentContexts]]
|-
| 0x00100102
| [[AM:GetImportContentContextList|GetImportContentContextList]]
|-
| 0x00110104
| [[AM:GetImportContentContexts|GetImportContentContexts]]
|-
| 0x00120102
| [[AM:DeleteImportContentContexts|DeleteImportContentContexts]]
|-
| 0x00130040
| [[AM:NeedsCleanup|NeedsCleanup]]
|-
| 0x00140040
| [[AM:DoCleanup|DoCleanup]]
|-
| 0x00150040
| [[AM:DeleteAllImportContexts|DeleteAllImportContexts]]
|-
| 0x00160000
| [[AM:DeleteAllTemporaryPrograms|DeleteAllTemporaryPrograms]]
|-
| 0x00170044
| [[AM:ImportTwlBackupLegacy|ImportTwlBackupLegacy]]
|-
| 0x00180080
| [[AM:InitializeTitleDatabase|InitializeTitleDatabase]]
|-
| 0x00190040
| [[AM:QueryAvailableTitleDatabase|QueryAvailableTitleDatabase]]
|-
| 0x001A00C0
| [[AM:CalcTwlBackupSize|CalcTwlBackupSize]]
|-
| 0x001B0144
| [[AM:ExportTwlBackup|ExportTwlBackup]]
|-
| 0x001C0084
| [[AM:ImportTwlBackup|ImportTwlBackup]]
|-
| 0x001D0000
| [[AM:DeleteAllTwlUserPrograms|DeleteAllTwlUserPrograms]]
|-
| 0x001E00C8
| [[AM:ReadTwlBackupInfo|ReadTwlBackupInfo]]
|-
| 0x001F0040
| [[AM:DeleteAllExpiredUserPrograms|DeleteAllExpiredUserPrograms]]
|-
| 0x00200000
| [[AM:GetTwlArchiveResourceInfo|GetTwlArchiveResourceInfo]]
|-
| 0x00210042
| [[AM:GetPersonalizedTicketInfoList|GetPersonalizedTicketInfoList]]
|-
| 0x00220080
| [[AM:DeleteAllImportContextsFiltered|DeleteAllImportContextsFiltered]]
|-
| 0x00230080
| [[AM:GetNumImportTitleContextsFiltered|GetNumImportTitleContextsFiltered]]
|-
| 0x002400C2
| [[AM:GetImportTitleContextListFiltered|GetImportTitleContextListFiltered]]
|-
| 0x002500C0
| [[AM:CheckContentRights|CheckContentRights]]
|-
| 0x00260044
| [[AM:GetTicketLimitInfos|GetTicketLimitInfos]]
|-
| 0x00270044
| [[AM:GetDemoLaunchInfos|GetDemoLaunchInfos]]
|-
| 0x00280108
| [[AM:ReadTwlBackupInfoEx|ReadTwlBackupInfoEx]]
|-
| 0x00290082
| [[AM:DeleteUserProgramsAtomically|DeleteUserProgramsAtomically]]
|-
| 0x002A00C0
| [[AM:GetNumExistingContentInfosSystem|GetNumExistingContentInfosSystem]]
|-
| 0x002B0142
| [[AM:ListExistingContentInfosSystem|ListExistingContentInfosSystem]]
|-
| 0x002C0084
| [[AM:GetProgramInfosIgnorePlatform|GetProgramInfosIgnorePlatform]]
|-
| 0x002D00C0
| [[AM:CheckContentRightsIgnorePlatform|CheckContentRightsIgnorePlatform]]
|}

= Application Manager services "am:u" and "am:net" =
{| class="wikitable" border="1"
|-
! Command Header
! Description
|-
| 0x04010080
| [[AM:UpdateFirmwareTo|UpdateFirmwareTo]]
|-
| 0x04020040
| [[AM:BeginImportProgram|BeginImportProgram]]
|-
| 0x04030000
| [[AM:BeginImportProgramTemporarily|BeginImportProgramTemporarily]]
|-
| 0x04040002
| [[AM:CancelImportProgram|CancelImportProgram]]
|-
| 0x04050002
| [[AM:EndImportProgram|EndImportProgram]]
|-
| 0x04060002
| [[AM:EndImportProgramWithoutCommit|EndImportProgramWithoutCommit]]
|-
| 0x040700C2
| [[AM:CommitImportPrograms|CommitImportPrograms]]
|-
| 0x04080042
| [[AM:GetProgramInfoFromCia|GetProgramInfoFromCia]]
|-
| 0x04090004
| [[AM:GetSystemMenuDataFromCia|GetSystemMenuDataFromCia]]
|-
| 0x040A0002
| [[AM:GetDependencyListFromCia|GetDependencyListFromCia]]
|-
| 0x040B0002
| [[AM:GetTransferSizeFromCia|GetTransferSizeFromCia]]
|-
| 0x040C0002
| [[AM:GetCoreVersionFromCia|GetCoreVersionFromCia]]
|-
| 0x040D0042
| [[AM:GetRequiredSizeFromCia|GetRequiredSizeFromCia]]
|-
| 0x040E00C2
| [[AM:CommitImportProgramsAndUpdateFirmwareAuto|CommitImportProgramsAndUpdateFirmwareAuto]]
|-
| 0x040F0000
| [[AM:UpdateFirmwareAuto|UpdateFirmwareAuto]]
|-
| 0x041000C0
| [[AM:DeleteProgram|DeleteProgram]]
|-
| 0x04110044
| [[AM:GetTwlProgramListForReboot|GetTwlProgramListForReboot]]
|-
| 0x04120000
| [[AM:GetSystemUpdaterMutex|GetSystemUpdaterMutex]]
|-
| 0x04130002
| [[AM:GetMetaSizeFromCia|GetMetaSizeFromCia]]
|-
| 0x04140044
| [[AM:GetMetaDataFromCia|GetMetaDataFromCia]]
|-
| 0x04150080
| [[AM:CheckDemoLaunchRights|CheckDemoLaunchRights]]
|-
| 0x041600C0
| [[AM:GetInternalTitleLocationInfo|GetInternalTitleLocationInfo]]
|-
| 0x041700C0
| [[AM:PerpetuateAgbSaveData|PerpetuateAgbSaveData]]
|-
| 0x04180040
| [[AM:BeginImportProgramForOverWrite|BeginImportProgramForOverWrite]]
|-
| 0x04190000
| [[AM:BeginImportSystemProgram|BeginImportSystemProgram]]
|}

= Application Manager service "am:app" =
{| class="wikitable" border="1"
|-
! Command Header
! Description
|-
| 0x100100C0
| [[AM:GetNumContentInfos|GetNumContentInfos]]
|-
| 0x10020104
| [[AM:FindContentInfos|FindContentInfos]]
|-
| 0x10030142
| [[AM:ListContentInfos|ListContentInfos]]
|-
| 0x10040102
| [[AM:DeleteContents|DeleteContents]]
|-
| 0x10050084
| [[AM:GetDLCTitleInfos|GetDLCTitleInfos]]
|-
| 0x10060080
| [[AM:GetNumDataTitleTickets|GetNumDataTitleTickets]]
|-
| 0x10070102
| [[AM:ListDataTitleTicketInfos|ListDataTitleTicketInfos]]
|-
| 0x100801C2
| [[AM:GetItemRights|GetItemRights]]
|-
| 0x100900C0
| [[AM:IsDataTitleInUse|IsDataTitleInUse]]
|-
| 0x100A0000
| [[AM:IsExternalTitleDatabaseInitialized|IsExternalTitleDatabaseInitialized]]
|-
| 0x100B00C0
| [[AM:GetNumExistingContentInfos|GetNumExistingContentInfos]]
|-
| 0x100C0142
| [[AM:ListExistingContentInfos|ListExistingContentInfos]]
|-
| 0x100D0084
| [[AM:GetPatchTitleInfos|GetPatchTitleInfos]]
|}

The only commands accessible with this service are listed under this section.

= Application Manager service "am:sys" =
This service only has access to the 0x00XX* commands listed above, and the "am:app" commands.

= Application Manager service "am:u" =

= Application Manager network service "am:net" =
{| class="wikitable" border="1"
|-
! Command Header
! Description
|-
| 0x08010000
| [[AMNet:BeginImportTicket|BeginImportTicket]]
|-
| 0x08020002
| [[AMNet:CancelImportTicket|CancelImportTicket]]
|-
| 0x08030002
| [[AMNet:EndImportTicket|EndImportTicket]]
|-
| 0x08040100
| [[AMNet:BeginImportTitle|BeginImportTitle]]
|-
| 0x08050000
| [[AMNet:StopImportTitle|StopImportTitle]]
|-
| 0x080600C0
| [[AMNet:ResumeImportTitle|ResumeImportTitle]]
|-
| 0x08070000
| [[AMNet:CancelImportTitle|CancelImportTitle]]
|-
| 0x08080000
| [[AMNet:EndImportTitle|EndImportTitle]]
|-
| 0x080900C2
| [[AMNet:CommitImportTitles|CommitImportTitles]]
|-
| 0x080A0000
| [[AMNet:BeginImportTmd|BeginImportTmd]]
|-
| 0x080B0002
| [[AMNet:CancelImportTmd|CancelImportTmd]]
|-
| 0x080C0042
| [[AMNet:EndImportTmd|EndImportTmd]]
|-
| 0x080D0042
| [[AMNet:CreateImportContentContexts|CreateImportContentContexts]]
|-
| 0x080E0040
| [[AMNet:BeginImportContent|BeginImportContent]]
|-
| 0x080F0002
| [[AMNet:StopImportContent|StopImportContent]]
|-
| 0x08100040
| [[AMNet:ResumeImportContent|ResumeImportContent]]
|-
| 0x08110002
| [[AMNet:CancelImportContent|CancelImportContent]]
|-
| 0x08120002
| [[AMNet:EndImportContent|EndImportContent]]
|-
| 0x08130000
| [[AMNet:GetNumCurrentImportContentContexts|GetNumCurrentImportContentContexts]]
|-
| 0x08140042
| [[AMNet:GetCurrentImportContentContextList|GetCurrentImportContentContextList]]
|-
| 0x08150044
| [[AMNet:GetCurrentImportContentContexts|GetCurrentImportContentContexts]]
|-
| 0x08160146
| [[AMNet:Sign|Sign]]
|-
| 0x08170146
| [[AMNet:Verify|Verify]]
|-
| 0x08180042
| [[AMNet:GetDeviceCert|GetDeviceCert]]
|-
| 0x08190108
| [[AMNet:ImportCertificates|ImportCertificates]]
|-
| 0x081A0042
| [[AMNet:ImportCertificate|ImportCertificate]]
|-
| 0x081B00C2
| [[AMNet:CommitImportTitlesAndUpdateFirmwareAuto|CommitImportTitlesAndUpdateFirmwareAuto]]
|-
| 0x081C0100
| [[AMNet:DeleteTicketId|DeleteTicketId]]
|-
| 0x081D0080
| [[AMNet:GetNumTicketIds|GetNumTicketIds]]
|-
| 0x081E0102
| [[AMNet:GetTicketIdList|GetTicketIdList]]
|-
| 0x081F0080
| [[AMNet:GetNumTicketsOfProgram|GetNumTicketsOfProgram]]
|-
| 0x08200102
| [[AMNet:ListTicketInfos|ListTicketInfos]]
|-
| 0x08210142
| [[AMNet:GetRightsOnlyTicketData|GetRightsOnlyTicketData]]
|-
| 0x08220000
| [[AMNet:GetNumCurrentContentInfos|GetNumCurrentContentInfos]]
|-
| 0x08230044
| [[AMNet:FindCurrentContentInfos|FindCurrentContentInfos]]
|-
| 0x08240082
| [[AMNet:ListCurrentContentInfos|ListCurrentContentInfos]]
|-
| 0x08250102
| [[AMNet:CalculateContextRequiredSize|CalculateContextRequiredSize]]
|-
| 0x08260042
| [[AMNet:UpdateImportContentContexts|UpdateImportContentContexts]]
|-
| 0x08270000
| [[AMNet:DeleteAllDemoLaunchInfos|DeleteAllDemoLaunchInfos]]
|-
| 0x082800C0
| [[AMNet:BeginImportTitleForOverWrite|BeginImportTitleForOverWrite]]
|}

= File service =
{| class="wikitable" border="1"
|-
! Command Header
! Available since system-version
! Description
|-
| 0x0001....
|
| Stubbed. After validating the translate-paramater headers, this just returns error 0xE0C046F8.
|-
| 0x0401....
|
| ?
|-
| 0x08010100
|
| ?
|-
| 0x080200C2
|
| [[AMFile:Read|Read]]
|-
| 0x08030102
|
| [[AMFile:Write|Write]]
|-
| 0x08040000
|
| [[AMFile:GetSize|GetSize]]
|-
| 0x08050080
|
| [[AMFile:SetSize|SetSize]]
|-
| 0x08060000
|
| ?
|-
| 0x08070000
|
| ?
|-
| 0x08080000
|
| [[AMFile:Close|Close]]
|-
| 0x08090000
|
| ?
|-
| 0x080A0000
|
| This just returns 0.
|-
| 0x080B0000
|
| This just returns 0.
|-
| 0x080C0000
|
| This just returns 0.
|}

This is similar to [[Filesystem_services#File_service|FSFile]].

For handling each command that's actually implemented, the AM cmdhandler function calls a vtable funcptr.

The private port for this seems to be referred to as "am:pipe", even though the "am:pipe" string isn't actually used.

=Types=
==TicketInfo==
{| class="wikitable" border="1"
|-
! Offset
! Length
! Description
|-
| 0x0
| 0x8
| Title ID
|-
| 0x8
| 0x8
| Ticket ID
|-
| 0x10
| 0x2
| Version
|-
| 0x12
| 0x2
| Padding
|-
| 0x14
| 0x4
| Size
|}

==TitleInfo==
{| class="wikitable" border="1"
|-
! Offset
! Length
! Description
|-
| 0x0
| 0x8
| Title ID
|-
| 0x8
| 0x8
| Size
|-
| 0x10
| 0x2
| Version
|-
| 0x12
| 0x2
| Padding
|-
| 0x14
| 0x4
| Type
|}

==ContentInfo==
{| class="wikitable" border="1"
|-
! Offset
! Length
! Description
|-
| 0x0
| 0x2
| Index
|-
| 0x2
| 0x2
| Type
|-
| 0x4
| 0x4
| Content ID
|-
| 0x8
| 0x8
| Size
|-
| 0x10
| 0x8
| RomFS Size
|}

==ImportTitleContext==
{| class="wikitable" border="1"
|-
! Offset
! Length
! Description
|-
| 0x0
| 0x8
| Title ID
|-
| 0x8
| 0x2
| Version
|-
| 0xA
| 0x2
| State
|-
| 0xC
| 0x4
| Type
|-
| 0x10
| 0x8
| Size
|}

===ImportTitleContextState===
{| class="wikitable" border="1"
|-
! Value
! Description
|-
| 0
| None
|-
| 1
| Waiting for import
|-
| 2
| Resumable
|-
| 3
| Waiting for commit
|-
| 4
| Already exists
|-
| 5
| Deleting
|-
| 6
| Needs cleanup
|}

==ImportContentContext==
{| class="wikitable" border="1"
|-
! Offset
! Length
! Description
|-
| 0x0
| 0x4
| Content ID
|-
| 0x4
| 0x2
| Index
|-
| 0x6
| 0x2
| Type
|-
| 0x8
| 0x8
| Size
|-
| 0x10
| 0x8
| Current Install Offset
|}

=Errors=
See [[Application_Manager_Services_PXI|this]].

AM:GetDataTitleInfos

2017-10-26T15:30:34Z

Shinyquagsire23: Shinyquagsire23 moved page AM:GetDataTitleInfos to AM:GetDLCTitleInfos: "Data" is a bit vague here, the function specifically checks for 0004008C which is the DLC TID high

#REDIRECT [[AM:GetDLCTitleInfos]]

AM:GetDLCTitleInfos

2017-10-26T15:30:34Z

Shinyquagsire23: Shinyquagsire23 moved page AM:GetDataTitleInfos to AM:GetDLCTitleInfos: "Data" is a bit vague here, the function specifically checks for 0004008C which is the DLC TID high

=Request=
{| class="wikitable" border="1"
|-
! Index Word
! Description
|-
| 0
| Header code [0x10050084]
|-
| 1
| [[Filesystem_services#MediaType|Media Type]]
|-
| 2
| Title Count
|-
| 3
| ((Title Count * 8) << 4) <nowiki>|</nowiki> 0xA
|-
| 4
| Title IDs Input Pointer
|-
| 5
| ((Title Count * 0x18) << 4) <nowiki>|</nowiki> 0xC
|-
| 6
| [[Application_Manager_Services#TitleInfo|Title Infos]] Output Pointer
|}

=Response=
{| class="wikitable" border="1"
|-
! Index Word
! Description
|-
| 0
| Header code
|-
| 1
| Result code
|-
| 2
| ((Title Count * 8) << 4) <nowiki>|</nowiki> 0xA
|-
| 3
| Title IDs Pointer
|-
| 4
| ((Title Count * 0x18) << 4) <nowiki>|</nowiki> 0xC
|-
| 5
| [[Application_Manager_Services#TitleInfo|Title Infos]] Pointer
|}

AM:GetProgramInfos

2017-10-26T02:01:01Z

Shinyquagsire23: get yourself a service who can map both?

=Request=
{| class="wikitable" border="1"
|-
! Index Word
! Description
|-
| 0
| Header code [0x00030084]
|-
| 1
| [[Filesystem_services#MediaType|Media Type]]
|-
| 2
| Title Count
|-
| 3
| ((Title Count * 8) << 4) <nowiki>|</nowiki> 0xA
|-
| 4
| Title IDs Input Pointer
|-
| 5
| ((Title Count * 0x18) << 4) <nowiki>|</nowiki> 0xC
|-
| 6
| [[Application_Manager_Services#TitleInfo|Title Infos]] Output Pointer
|}

=Response=
{| class="wikitable" border="1"
|-
! Index Word
! Description
|-
| 0
| Header code
|-
| 1
| Result code
|-
| 2
| ((Title Count * 8) << 4) <nowiki>|</nowiki> 0xA
|-
| 3
| Title IDs Pointer
|-
| 4
| ((Title Count * 0x18) << 4) <nowiki>|</nowiki> 0xC
|-
| 5
| [[Application_Manager_Services#TitleInfo|Title Infos]] Pointer
|}

AM:GetDLCTitleInfos

2017-10-26T01:59:34Z

Shinyquagsire23:

AM:GetPatchTitleInfos

2017-10-25T21:35:08Z

Shinyquagsire23: ???

=Request=
{| class="wikitable" border="1"
|-
! Index Word
! Description
|-
| 0
| Header code [0x100D0084]
|-
| 1
| [[Filesystem_services#MediaType|Media Type]]
|-
| 2
| Title Count
|-
| 3
| ((Title Count * 8) << 4) <nowiki>|</nowiki> 0xA
|-
| 4
| Title IDs Input Pointer
|-
| 5
| ((Title Count * 0x18) << 4) <nowiki>|</nowiki> 0xC
|-
| 6
| [[Application_Manager_Services#TitleInfo|Title Infos]] Output Pointer
|}

=Response=
{| class="wikitable" border="1"
|-
! Index Word
! Description
|-
| 0
| Header code
|-
| 1
| Result code
|-
| 2
| ((Title Count * 8) << 4) <nowiki>|</nowiki> 0xA
|-
| 3
| Title IDs Pointer
|-
| 4
| ((Title Count * 0x18) << 4) <nowiki>|</nowiki> 0xC
|-
| 5
| [[Application_Manager_Services#TitleInfo|Title Infos]] Pointer
|}

Application Manager Services PXI

2017-10-21T20:03:24Z

Shinyquagsire23:

=Application Manager Services PXI "pxi:am9"=
{| 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]]
| [[AMPXI:GetTitleExtDataId|GetTitleExtDataId]]
|-
| 0x00070080
| [[1.0.0-0]]
| [[AMPXI:DeletePendingTitles|DeletePendingTitles]]
|-
| 0x00080080
| [[1.0.0-0]]
| [[AMPXI:InstallFIRM|InstallFIRM]]
|-
| 0x00090000
| [[1.0.0-0]]
| [[AMPXI:InstallTikBegin|InstallTikBegin]]
|-
| 0x000A0042
| [[1.0.0-0]]
| [[AMPXI:InstallTikWrite|InstallTikWrite]]
|-
| 0x000B0000
| [[1.0.0-0]]
| [[AMPXI:InstallTikAbort|InstallTikAbort]]
|-
| 0x000C0000
| [[1.0.0-0]]
| [[AMPXI:InstallTikFinish|InstallTikFinish]]
|-
| 0x000D0080
| [[1.0.0-0]]
| [[AMPXI:DeleteTicket|DeleteTicket]]
|-
| 0x000E0000
| [[1.0.0-0]]
| [[AMPXI:GetTicketCount|GetTicketCount]]
|-
| 0x000F0082
| [[1.0.0-0]]
| [[AMPXI:GetTicketList|GetTicketList]]
|-
| 0x00100100
| [[1.0.0-0]]
| [[AMPXI:InstallTitleBegin|InstallTitleBegin]]
|-
| 0x00110000
| [[1.0.0-0]]
| [[AMPXI:InstallTitleAbort|InstallTitleAbort]]
|-
| 0x001200C0
| [[1.0.0-0]]
| [[AMPXI:InstallTitleResume|InstallTitleResume]]
|-
| 0x00130000
| [[1.0.0-0]]
| [[AMPXI:InstallTmdBegin|InstallTmdBegin]]
|-
| 0x00140042
| [[1.0.0-0]]
| [[AMPXI:InstallTmdWrite|InstallTmdWrite]]
|-
| 0x00150000
| [[1.0.0-0]]
| [[AMPXI:InstallTmdAbort|InstallTmdAbort]]
|-
| 0x00160040
| [[1.0.0-0]]
| [[AMPXI:InstallTmdFinish|InstallTmdFinish]]
|-
| 0x00170040
| [[1.0.0-0]]
| [[AMPXI:InstallContentBegin|InstallContentBegin]]
|-
| 0x00180042
| [[1.0.0-0]]
| [[AMPXI:InstallContentWrite|InstallContentWrite]]
|-
| 0x00190000
| [[1.0.0-0]]
| [[AMPXI:InstallContentAbort|InstallContentAbort]]
|-
| 0x001A0000
| [[1.0.0-0]]
| InstallContentAbortDSi (?)
|-
| 0x001B0040
| [[1.0.0-0]]
| [[AMPXI:InstallContentResume|InstallContentResume]]
|-
| 0x001C0000
| [[1.0.0-0]]
| [[AMPXI:InstallContentFinish|InstallContentFinish]]
|-
| 0x001D0080
| [[1.0.0-0]]
| [[AMPXI:GetPendingTitleCount|GetPendingTitleCount]]
|-
| 0x001E00C2
| [[1.0.0-0]]
| [[AMPXI:GetPendingTitleList|GetPendingTitleList]]
|-
| 0x001F0084
| [[1.0.0-0]]
| [[AMPXI:GetPendingTitleInfo|GetPendingTitleInfo]]
|-
| 0x002000C0
| [[1.0.0-0]]
| [[AMPXI:DeletePendingTitle|DeletePendingTitle]]
|-
| 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]]
| InstallTitleAbortDSi (?)
|-
| 0x00290000
| [[1.0.0-0]]
| [[AMPXI:InstallTitleFinish|InstallTitleFinish]]
|-
| 0x002A00C2
| [[1.0.0-0]]
| [[AMPXI:InstallTitlesFinish|InstallTitlesFinish]]
|-
| 0x002B....
| [[1.0.0-0]]
| Stubbed.
|-
| 0x002C....
| [[1.0.0-0]]
| Stubbed.
|-
| 0x002D....
| [[1.0.0-0]]
| Stubbed.
|-
| 0x002E....
| [[1.0.0-0]]
| Stubbed.
|-
| 0x002F....
| [[1.0.0-0]]
| Stubbed.
|-
| 0x0030....
| [[1.0.0-0]]
| Stubbed.
|-
| 0x0031....
| [[1.0.0-0]]
| Stubbed.
|-
| 0x0032....
| [[1.0.0-0]]
| Stubbed.
|-
| 0x0033....
| [[1.0.0-0]]
| Stubbed.
|-
| 0x0034....
| [[1.0.0-0]]
| Stubbed.
|-
| 0x0035....
| [[1.0.0-0]]
| Stubbed.
|-
| 0x0036....
| [[1.0.0-0]]
| Stubbed.
|-
| 0x0037....
| [[1.0.0-0]]
| Stubbed.
|-
| 0x0038....
| [[1.0.0-0]]
| Stubbed.
|-
| 0x00390146
| [[1.0.0-0]]
| (size2, size3, unknown_u64, size1, ptr1size_size1, ptr1, ptr2size_size2, ptr2, ptr3size_size3, ptr3)
|-
| 0x003A0146
| [[1.0.0-0]]
| Stubbed.
|-
| 0x003B0042
| [[1.0.0-0]]
| [[AMPXI:GetCTCert|GetCTCert]]
|-
| 0x003C0000
| [[1.0.0-0]]
| [[AMPXI:GetDeviceID|GetDeviceID]]
|-
| 0x003D0108
| [[1.0.0-0]]
| [[AMPXI:SetCertificates|SetCertificates]]
|-
| 0x003E0042
| [[1.0.0-0]]
| [[AMPXI:SetCertificate|SetCertificate]]
|-
| 0x003F0040
| [[1.0.0-0]]
| (unknown_u8)
|-
| 0x00400040
| [[1.0.0-0]]
| [[AMPXI:DoCleanup|DoCleanup]]
|-
| 0x00410000
| [[1.0.0-0]]
|?
|-
| 0x00420142
| [[1.0.0-0]]
| [[AMPXI:InstallTitlesFinishFIRM|InstallTitlesFinishFIRM]]
|-
| 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]]
| [[AMPXI:InitializeTitleDatabase|InitializeTitleDatabase]]
|-
| 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]]
| InstallTitleBeginDSi (?) (unknown_u64, u8_optype) The optype must be 5 or 11, but it's not used after validating it. Disabling using this in AM-sysmodule breaks DSiWare-importing. This is used right before [[AMPXI:InstallTmdBegin|InstallTmdBegin]] in AM-sysmodule.
|-
| 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]]
| [[AMPXI:GetTWLPartitionInfo|GetTWLPartitionInfo]]
|-
| 0x005500C4
| [[2.0.0-2]]
| [[AMPXI:ValidateDSiWareSectionMAC|ValidateDSiWareSectionMAC]]
|-
| 0x005600C0
| [[2.0.0-2]]
| (unknown_u64, unknown_u16)
|-
| 0x00570042
| [[4.0.0-7]]
| [[AMPXI:InstallTitleSetContentIndices|InstallTitleSetContentIndices]]
|-
| 0x005800C0
| [[4.0.0-7]]
| [[AMPXI:GetNumContentInfos|GetNumContentInfos]]
|-
| 0x00590104
| [[4.0.0-7]]
| [[AMPXI:FindContentInfos|FindContentInfos]]
|-
| 0x005A0142
| [[4.0.0-7]]
| [[AMPXI:ListContentInfos|ListContentInfos]]
|-
| 0x005B0000
| [[4.0.0-7]]
| ?
|-
| 0x005C0044
| [[4.0.0-7]]
| ?
|-
| 0x005D0082
| [[4.0.0-7]]
| ?
|-
| 0x005E0102
| [[4.0.0-7]]
| [[AMPXI:DeleteContents|DeleteContents]]
|-
| 0x005F0080
| [[4.0.0-7]]
| ?
|-
| 0x00600102
| [[4.0.0-7]]
| [[AMPXI:ListDataTitleTicketInfos|ListDataTitleTicketInfos]]
|-
| 0x00610142
| [[4.0.0-7]]
| ?
|-
| 0x00620044
| [[4.0.0-7]]
| ?
|-
| 0x00630042
| [[4.0.0-7]]
| ?
|-
| 0x006400C0
| [[4.0.0-7]]
| ?
|-
| 0x006500C0
| [[4.0.0-7]]
| [[AMPXI:MigrateAGBtoSAV|MigrateAGBtoSAV]]
|-
| 0x0066....
| [[4.0.0-7]]
| Stubbed starting with [[4.0.0-7]].
|-
| 0x00670082
| [[4.0.0-7]]
| ?
|-
| 0x006801C2
| [[4.0.0-7]]
| ?
|-
| 0x006900C0
| [[4.0.0-7]]
| [[AMPXI:IsDataTitleInUse|IsDataTitleInUse]]
|-
| 0x006A00C0
| [[4.0.0-7]]
| ?
|-
| 0x006B0142
| [[4.0.0-7]]
| ?
|-
| 0x006C00C0
| [[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
| Wrong installation state.
|-
| 0xD8E08020
| CIA file is empty.
|-
| 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. Returned when a CIA header is invalid.
|-
| 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(?) / the specified title(s) don't exist.
|-
| 0xE0E0802C
| AM module returns this error when the system-title bit is set for the input CTR/TWL titleID-high, for [[AM:DeleteApplicationTitle]].
|}

Error codes

2017-10-21T19:42:29Z

Shinyquagsire23:

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

For the description field, codes in range 1000(?)~1023 is common to all modules, while codes outside this range are defined independently by each module.

Description ranges: (some if not all of these could be specifically for fs-module)

{| class="wikitable" border="1"
|-
! Num
! Description
|-
| 100-179
| Not found
|-
| 130-179 (subset of previous)
| Media not found
|-
| 180-199
| Exists already
|-
| 200-219
| Not enough space
|-
| 220-229
| Invalidated archive
|-
| 230-339
| Unacceptable
|-
| 260-279 (subset of previous)
| Write protected
|-
| 360-389
| Bad format
|-
| 390-399
| Verification failure
|-
| 600-629
| Out of resources
|-
| 630-660
| Access denied
|-
| 700-729
| Invalid argument
|-
| 730-749
| Not initialized
|-
| 750-759
| Already initialized
|-
| 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)
|-
| 32
| Empty CIA? (AM)
|-
| 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)
|-
| 47
| Invalid command header (OS)
|-
| 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
| GSP
|-
| 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
|-
| 83
| ACT
|-
| 84
| VCTL
|-
| 85
| OLV
|-
| 86
| NEIA
|-
| 87
| NPNS
|-
| 90
| AVD
|-
| 91
| L2B
|-
| 92
| MVD
|-
| 93
| NFC
|-
| 94
| UART
|-
| 95
| SPM
|-
| 96
| QTM
|-
| 97
| NFP (amiibo)
|-
| 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
|}

Application Manager Services PXI

2017-10-21T19:41:34Z

Shinyquagsire23:

=Application Manager Services PXI "pxi:am9"=
{| 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]]
| [[AMPXI:GetTitleExtDataId|GetTitleExtDataId]]
|-
| 0x00070080
| [[1.0.0-0]]
| [[AMPXI:DeletePendingTitles|DeletePendingTitles]]
|-
| 0x00080080
| [[1.0.0-0]]
| [[AMPXI:InstallFIRM|InstallFIRM]]
|-
| 0x00090000
| [[1.0.0-0]]
| [[AMPXI:InstallTikBegin|InstallTikBegin]]
|-
| 0x000A0042
| [[1.0.0-0]]
| [[AMPXI:InstallTikWrite|InstallTikWrite]]
|-
| 0x000B0000
| [[1.0.0-0]]
| [[AMPXI:InstallTikAbort|InstallTikAbort]]
|-
| 0x000C0000
| [[1.0.0-0]]
| [[AMPXI:InstallTikFinish|InstallTikFinish]]
|-
| 0x000D0080
| [[1.0.0-0]]
| [[AMPXI:DeleteTicket|DeleteTicket]]
|-
| 0x000E0000
| [[1.0.0-0]]
| [[AMPXI:GetTicketCount|GetTicketCount]]
|-
| 0x000F0082
| [[1.0.0-0]]
| [[AMPXI:GetTicketList|GetTicketList]]
|-
| 0x00100100
| [[1.0.0-0]]
| [[AMPXI:InstallTitleBegin|InstallTitleBegin]]
|-
| 0x00110000
| [[1.0.0-0]]
| [[AMPXI:InstallTitleAbort|InstallTitleAbort]]
|-
| 0x001200C0
| [[1.0.0-0]]
| [[AMPXI:InstallTitleResume|InstallTitleResume]]
|-
| 0x00130000
| [[1.0.0-0]]
| [[AMPXI:InstallTmdBegin|InstallTmdBegin]]
|-
| 0x00140042
| [[1.0.0-0]]
| [[AMPXI:InstallTmdWrite|InstallTmdWrite]]
|-
| 0x00150000
| [[1.0.0-0]]
| [[AMPXI:InstallTmdAbort|InstallTmdAbort]]
|-
| 0x00160040
| [[1.0.0-0]]
| [[AMPXI:InstallTmdFinish|InstallTmdFinish]]
|-
| 0x00170040
| [[1.0.0-0]]
| [[AMPXI:InstallContentBegin|InstallContentBegin]]
|-
| 0x00180042
| [[1.0.0-0]]
| [[AMPXI:InstallContentWrite|InstallContentWrite]]
|-
| 0x00190000
| [[1.0.0-0]]
| [[AMPXI:InstallContentAbort|InstallContentAbort]]
|-
| 0x001A0000
| [[1.0.0-0]]
| InstallContentAbortDSi (?)
|-
| 0x001B0040
| [[1.0.0-0]]
| [[AMPXI:InstallContentResume|InstallContentResume]]
|-
| 0x001C0000
| [[1.0.0-0]]
| [[AMPXI:InstallContentFinish|InstallContentFinish]]
|-
| 0x001D0080
| [[1.0.0-0]]
| [[AMPXI:GetPendingTitleCount|GetPendingTitleCount]]
|-
| 0x001E00C2
| [[1.0.0-0]]
| [[AMPXI:GetPendingTitleList|GetPendingTitleList]]
|-
| 0x001F0084
| [[1.0.0-0]]
| [[AMPXI:GetPendingTitleInfo|GetPendingTitleInfo]]
|-
| 0x002000C0
| [[1.0.0-0]]
| [[AMPXI:DeletePendingTitle|DeletePendingTitle]]
|-
| 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]]
| InstallTitleAbortDSi (?)
|-
| 0x00290000
| [[1.0.0-0]]
| [[AMPXI:InstallTitleFinish|InstallTitleFinish]]
|-
| 0x002A00C2
| [[1.0.0-0]]
| [[AMPXI:InstallTitlesFinish|InstallTitlesFinish]]
|-
| 0x002B....
| [[1.0.0-0]]
| Stubbed.
|-
| 0x002C....
| [[1.0.0-0]]
| Stubbed.
|-
| 0x002D....
| [[1.0.0-0]]
| Stubbed.
|-
| 0x002E....
| [[1.0.0-0]]
| Stubbed.
|-
| 0x002F....
| [[1.0.0-0]]
| Stubbed.
|-
| 0x0030....
| [[1.0.0-0]]
| Stubbed.
|-
| 0x0031....
| [[1.0.0-0]]
| Stubbed.
|-
| 0x0032....
| [[1.0.0-0]]
| Stubbed.
|-
| 0x0033....
| [[1.0.0-0]]
| Stubbed.
|-
| 0x0034....
| [[1.0.0-0]]
| Stubbed.
|-
| 0x0035....
| [[1.0.0-0]]
| Stubbed.
|-
| 0x0036....
| [[1.0.0-0]]
| Stubbed.
|-
| 0x0037....
| [[1.0.0-0]]
| Stubbed.
|-
| 0x0038....
| [[1.0.0-0]]
| Stubbed.
|-
| 0x00390146
| [[1.0.0-0]]
| (size2, size3, unknown_u64, size1, ptr1size_size1, ptr1, ptr2size_size2, ptr2, ptr3size_size3, ptr3)
|-
| 0x003A0146
| [[1.0.0-0]]
| Stubbed.
|-
| 0x003B0042
| [[1.0.0-0]]
| [[AMPXI:GetCTCert|GetCTCert]]
|-
| 0x003C0000
| [[1.0.0-0]]
| [[AMPXI:GetDeviceID|GetDeviceID]]
|-
| 0x003D0108
| [[1.0.0-0]]
| [[AMPXI:SetCertificates|SetCertificates]]
|-
| 0x003E0042
| [[1.0.0-0]]
| [[AMPXI:SetCertificate|SetCertificate]]
|-
| 0x003F0040
| [[1.0.0-0]]
| (unknown_u8)
|-
| 0x00400040
| [[1.0.0-0]]
| [[AMPXI:DoCleanup|DoCleanup]]
|-
| 0x00410000
| [[1.0.0-0]]
|?
|-
| 0x00420142
| [[1.0.0-0]]
| [[AMPXI:InstallTitlesFinishFIRM|InstallTitlesFinishFIRM]]
|-
| 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]]
| [[AMPXI:InitializeTitleDatabase|InitializeTitleDatabase]]
|-
| 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]]
| InstallTitleBeginDSi (?) (unknown_u64, u8_optype) The optype must be 5 or 11, but it's not used after validating it. Disabling using this in AM-sysmodule breaks DSiWare-importing. This is used right before [[AMPXI:InstallTmdBegin|InstallTmdBegin]] in AM-sysmodule.
|-
| 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]]
| [[AMPXI:GetTWLPartitionInfo|GetTWLPartitionInfo]]
|-
| 0x005500C4
| [[2.0.0-2]]
| [[AMPXI:ValidateDSiWareSectionMAC|ValidateDSiWareSectionMAC]]
|-
| 0x005600C0
| [[2.0.0-2]]
| (unknown_u64, unknown_u16)
|-
| 0x00570042
| [[4.0.0-7]]
| [[AMPXI:InstallTitleSetContentIndices|InstallTitleSetContentIndices]]
|-
| 0x005800C0
| [[4.0.0-7]]
| [[AMPXI:GetNumContentInfos|GetNumContentInfos]]
|-
| 0x00590104
| [[4.0.0-7]]
| [[AMPXI:FindContentInfos|FindContentInfos]]
|-
| 0x005A0142
| [[4.0.0-7]]
| [[AMPXI:ListContentInfos|ListContentInfos]]
|-
| 0x005B0000
| [[4.0.0-7]]
| ?
|-
| 0x005C0044
| [[4.0.0-7]]
| ?
|-
| 0x005D0082
| [[4.0.0-7]]
| ?
|-
| 0x005E0102
| [[4.0.0-7]]
| [[AMPXI:DeleteContents|DeleteContents]]
|-
| 0x005F0080
| [[4.0.0-7]]
| ?
|-
| 0x00600102
| [[4.0.0-7]]
| [[AMPXI:ListDataTitleTicketInfos|ListDataTitleTicketInfos]]
|-
| 0x00610142
| [[4.0.0-7]]
| ?
|-
| 0x00620044
| [[4.0.0-7]]
| ?
|-
| 0x00630042
| [[4.0.0-7]]
| ?
|-
| 0x006400C0
| [[4.0.0-7]]
| ?
|-
| 0x006500C0
| [[4.0.0-7]]
| [[AMPXI:MigrateAGBtoSAV|MigrateAGBtoSAV]]
|-
| 0x0066....
| [[4.0.0-7]]
| Stubbed starting with [[4.0.0-7]].
|-
| 0x00670082
| [[4.0.0-7]]
| ?
|-
| 0x006801C2
| [[4.0.0-7]]
| ?
|-
| 0x006900C0
| [[4.0.0-7]]
| [[AMPXI:IsDataTitleInUse|IsDataTitleInUse]]
|-
| 0x006A00C0
| [[4.0.0-7]]
| ?
|-
| 0x006B0142
| [[4.0.0-7]]
| ?
|-
| 0x006C00C0
| [[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
| Wrong installation state.
|-
| 0xD8E08020
| CIA file is empty.
|-
| 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(?) / the specified title(s) don't exist.
|-
| 0xE0E0802C
| AM module returns this error when the system-title bit is set for the input CTR/TWL titleID-high, for [[AM:DeleteApplicationTitle]].
|}

Filesystem services

2017-10-04T01:43:54Z

Shinyquagsire23: funky but not content-related

[[Category:Services]]

= 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
|?
| [[FS:Dummy1|Dummy1]]
| None
|-
| 0x040100C4
|?
| [[FS:Control|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
|?
| [[FS:ControlArchive|ControlArchive]]
| None
|-
| 0x080E0080
|?
| [[FS:CloseArchive|CloseArchive]]
| None
|-
| 0x080F0180
|?
| [[FS:Obsoleted_2_0_FormatThisUserSaveData|Obsoleted_2_0_FormatThisUserSaveData]]
| None
|-
| 0x08100200
|?
| [[FS:Obsoleted_3_0_CreateSystemSaveData|Obsoleted_3_0_CreateSystemSaveData]]
| 0x4, for when the input saveID doesn't match the exheader saveID
|-
| 0x08110040
|?
| [[FS:Obsoleted_3_0_DeleteSystemSaveData|Obsoleted_3_0_DeleteSystemSaveData]]
| 0x1004, for when the input saveID doesn't match the exheader saveID
|-
| 0x08120080
|?
| [[FS:GetFreeBytes|GetFreeBytes]]
| None
|-
| 0x08130000
|?
| [[FS:GetCardType|GetCardType]]
| 0x1017
|-
| 0x08140000
|?
| [[FS:GetSdmcArchiveResource|GetSdmcArchiveResource]]
| None
|-
| 0x08150000
|?
| [[FS:GetNandArchiveResource|GetNandArchiveResource]]
| 0x1007
|-
| 0x08160000
|?
| [[FS:GetSdmcFatfsError|GetSdmcFatfsError]]
| 0x2
|-
| 0x08170000
|?
| [[FS:IsSdmcDetected|IsSdmcDetected]]
| None
|-
| 0x08180000
|?
| [[FS:IsSdmcWritable|IsSdmcWritable]]
| None
|-
| 0x08190042
|?
| [[FS:GetSdmcCid|GetSdmcCid]]
| 0x2
|-
| 0x081A0042
|?
| [[FS:GetNandCid|GetNandCid]]
| 0x2
|-
| 0x081B0000
|?
| [[FS:GetSdmcSpeedInfo|GetSdmcSpeedInfo]]
| 0x2
|-
| 0x081C0000
|?
| [[FS:GetNandSpeedInfo|GetNandSpeedInfo]]
| 0x2
|-
| 0x081D0042
|?
| [[FS:GetSdmcLog|GetSdmcLog]]
| 0x2
|-
| 0x081E0042
|?
| [[FS:GetNandLog|GetNandLog]]
| 0x2
|-
| 0x081F0000
|?
| [[FS:ClearSdmcLog|ClearSdmcLog]]
| 0x2
|-
| 0x08200000
|?
| [[FS:ClearNandLog|ClearNandLog]]
| 0x2
|-
| 0x08210000
|?
| [[FS:CardSlotIsInserted|CardSlotIsInserted]]
| 0x1017
|-
| 0x08220000
|?
| [[FS:CardSlotPowerOn|CardSlotPowerOn]]
| 0x2
|-
| 0x08230000
|?
| [[FS:CardSlotPowerOff|CardSlotPowerOff]]
| 0x2
|-
| 0x08240000
|?
| [[FS:CardSlotGetCardIFPowerStatus|CardSlotGetCardIFPowerStatus]]
| 0x2
|-
| 0x08250040
|?
| [[FS:CardNorDirectCommand|CardNorDirectCommand]]
| 0x2
|-
| 0x08260080
|?
| [[FS:CardNorDirectCommandWithAddress|CardNorDirectCommandWithAddress]]
| 0x2
|-
| 0x08270082
|?
| [[FS:CardNorDirectRead|CardNorDirectRead]]
| 0x2
|-
| 0x082800C2
|?
| [[FS:CardNorDirectReadWithAddress|CardNorDirectReadWithAddress]]
| 0x2
|-
| 0x08290082
|?
| [[FS:CardNorDirectWrite|CardNorDirectWrite]]
| 0x2
|-
| 0x082A00C2
|?
| [[FS:CardNorDirectWriteWithAddress|CardNorDirectWriteWithAddress]]
| 0x2
|-
| 0x082B00C2
|?
| [[FS:CardNorDirectRead_4xIO|CardNorDirectRead_4xIO]]
| 0x2
|-
| 0x082C0082
|?
| [[FS:CardNorDirectCpuWriteWithoutVerify|CardNorDirectCpuWriteWithoutVerify]]
| 0x2
|-
| 0x082D0040
|?
| [[FS:CardNorDirectSectorEraseWithoutVerify|CardNorDirectSectorEraseWithoutVerify]]
| 0x2
|-
| 0x082E0040
|?
| [[FS:GetProductInfo|GetProductInfo]]
| 0x1005
|-
| 0x082F0040
|?
| [[FS:GetProgramLaunchInfo|GetProgramLaunchInfo]]
| 0x1005
|-
| 0x08300182
|?
| [[FS:Obsoleted_3_0_CreateExtSaveData|Obsoleted_3_0_CreateExtSaveData]]
| 0xC, for when the input extdataID doesn't match the exheader extdataID
|-
| 0x08310180
|?
| [[FS:Obsoleted_3_0_CreateSharedExtSaveData|Obsoleted_3_0_CreateSharedExtSaveData]]
| 0x1005
|-
| 0x08320102
|?
| [[FS:Obsoleted_3_0_ReadExtSaveDataIcon|Obsoleted_3_0_ReadExtSaveDataIcon]]
| 0x100D, for when the input extdataID doesn't match the exheader extdataID
|-
| 0x08330082
|?
| [[FS:Obsoleted_3_0_EnumerateExtSaveData|Obsoleted_3_0_EnumerateExtSaveData]]
| 0x1005
|-
| 0x08340082
|?
| [[FS:Obsoleted_3_0_EnumerateSharedExtSaveData|Obsoleted_3_0_EnumerateSharedExtSaveData]]
| 0x1005
|-
| 0x08350080
|?
| [[FS:Obsoleted_3_0_DeleteExtSaveData|Obsoleted_3_0_DeleteExtSaveData]]
| 0x100D, for when the input extdataID doesn't match the exheader extdataID
|-
| 0x08360080
|?
| [[FS:Obsoleted_3_0_DeleteSharedExtSaveData|Obsoleted_3_0_DeleteSharedExtSaveData]]
| 0x1005
|-
| 0x08370040
|?
| [[FS:SetCardSpiBaudRate|SetCardSpiBaudRate]]
| 0x2
|-
| 0x08380040
|?
| [[FS:SetCardSpiBusMode|SetCardSpiBusMode]]
| 0x2
|-
| 0x08390000
|?
| [[FS:SendInitializeInfoTo9|SendInitializeInfoTo9]]
| None
|-
| 0x083A0100
|?
| [[FS:GetSpecialContentIndex|GetSpecialContentIndex]]
| 0x1005
|-
| 0x083B00C2
|?
| [[FS:GetLegacyRomHeader|GetLegacyRomHeader]]
| 0x1015
|-
| 0x083C00C2
|?
| [[FS:GetLegacyBannerData|GetLegacyBannerData]]
| 0x1015
|-
| 0x083D0100
|?
| [[FS:CheckAuthorityToAccessExtSaveData|CheckAuthorityToAccessExtSaveData]]
| 0x44
|-
| 0x083E00C2
|?
| [[FS:QueryTotalQuotaSize|QueryTotalQuotaSize]]
| None
|-
| 0x083F00C0
|?
| [[FS:Obsoleted_3_0_GetExtDataBlockSize|Obsoleted_3_0_GetExtDataBlockSize]]
| None
|-
| 0x08400040
|?
| [[FS:AbnegateAccessRight|AbnegateAccessRight]]
|?
|-
| 0x08410000
|?
| [[FS:DeleteSdmcRoot|DeleteSdmcRoot]]
| 0x1005
|-
| 0x08420040
|?
| [[FS:DeleteAllExtSaveDataOnNand|DeleteAllExtSaveDataOnNand]]
| 0x1005
|-
| 0x08430000
|?
| [[FS:InitializeCtrFileSystem|InitializeCtrFileSystem]]
| None
|-
| 0x08440000
|?
| [[FS:CreateSeed|CreateSeed]]
| 0x2
|-
| 0x084500C2
|?
| [[FS:GetFormatInfo|GetFormatInfo]]
|?
|-
| 0x08460102
|?
| [[FS:GetLegacyRomHeader2|GetLegacyRomHeader2]]
| 0x1015
|-
| 0x08470180
|?
| [[FS:Obsoleted_2_0_FormatCtrCardUserSaveData|Obsoleted_2_0_FormatCtrCardUserSaveData]]
| 0x6
|-
| 0x08480042
|?
| [[FS:GetSdmcCtrRootPath|GetSdmcCtrRootPath]]
| 0x100D
|-
| 0x08490040
|?
| [[FS:GetArchiveResource|GetArchiveResource]]
|?
|-
| 0x084A0002
|?
| [[FS:ExportIntegrityVerificationSeed|ExportIntegrityVerificationSeed]]
| 0x4000
|-
| 0x084B0002
|?
| [[FS:ImportIntegrityVerificationSeed|ImportIntegrityVerificationSeed]]
| 0x4000
|-
| 0x084C0242
|?
| [[FS:FormatSaveData|FormatSaveData]]
| 0x6, in some cases this write isn't needed however
|-
| 0x084D0102
|?
| [[FS:GetLegacySubBannerData|GetLegacySubBannerData]]
| 0x1015
|-
| 0x084E0342
|?
| [[FS:UpdateSha256Context|UpdateSha256Context]]
| 0x5
|-
| 0x084F0102
|?
| [[FS:ReadSpecialFile|ReadSpecialFile]]
| None
|-
| 0x08500040
|?
| [[FS:GetSpecialFileSize|GetSpecialFileSize]]
| None
|-
| 0x08510242
| [[3.0.0-5]]
| [[FS:CreateExtSaveData|CreateExtSaveData]]
| Shared extdata: 0x101005. Regular extdata in certain cases: 0xC
|-
| 0x08520100
| [[3.0.0-5]]
| [[FS:DeleteExtSaveData|DeleteExtSaveData]]
| Shared extdata: 0x101005. Regular extdata in certain cases: 0x10100D
|-
| 0x08530142
| [[3.0.0-5]]
| [[FS:ReadExtSaveDataIcon|ReadExtSaveDataIcon]]
| 0x10100D (this doesn't apply in certain cases, however)
|-
| 0x085400C0
| [[3.0.0-5]]
| [[FS:GetExtDataBlockSize|GetExtDataBlockSize]]
| 0x10100D (this doesn't apply in certain cases, however)
|-
| 0x08550102
| [[3.0.0-5]]
| [[FS:EnumerateExtSaveData|EnumerateExtSaveData]]
| 0x101005
|-
| 0x08560240
| [[3.0.0-5]]
| [[FS:CreateSystemSaveData|CreateSystemSaveData]]
| 0x4 (this doesn't apply in certain cases, however)
|-
| 0x08570080
| [[3.0.0-5]]
| [[FS:DeleteSystemSaveData|DeleteSystemSaveData]]
| 0x1004 (this doesn't apply in certain cases, however)
|-
| 0x08580000
| [[3.0.0-5]]
| [[FS:StartDeviceMoveAsSource|StartDeviceMoveAsSource]]
| 0x2004
|-
| 0x08590200
| [[3.0.0-5]]
| [[FS:StartDeviceMoveAsDestination|StartDeviceMoveAsDestination]]
| 0x2004
|-
| 0x085A00C0
| [[3.0.0-5]]
| [[FS:SetArchivePriority|SetArchivePriority]]
| None
|-
| 0x085B0080
| [[3.0.0-5]]
| [[FS:GetArchivePriority|GetArchivePriority]]
| None
|-
| 0x085C00C0
| [[3.0.0-5]]
| [[FS:SetCtrCardLatencyParameter|SetCtrCardLatencyParameter]]
| 0xE
|-
| 0x085D01C0
| [[3.0.0-5]]
| [[FS:SetFsCompatibilityInfo|SetFsCompatibilityInfo]]
| 0x100001
|-
| 0x085E0040
| [[3.0.0-5]]
| [[FS:ResetCardCompatibilityParameter|ResetCardCompatibilityParameter]]
| 0xE
|-
| 0x085F0040
| [[3.0.0-5]]
| [[FS:SwitchCleanupInvalidSaveData|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]]
| [[FS:SetPriority|SetPriority]]
| None
|-
| 0x08630000
| [[3.0.0-5]]
| [[FS:GetPriority|GetPriority]]
| None
|-
| 0x08640000
| [[3.0.0-5]]
| [[FS:Obsoleted_4_0_GetNandInfo|Obsoleted_4_0_GetNandInfo]]
| Stubbed, this returns an error
|-
| 0x08650140
| [[4.0.0-7]]
| [[FS:SetSaveDataSecureValue|SetSaveDataSecureValue]]
| 0x121004 (in certain cases this doesn't apply, however)
|-
| 0x086600C0
| [[4.0.0-7]]
| [[FS:GetSaveDataSecureValue|GetSaveDataSecureValue]]
| 0x121004 (in certain cases this doesn't apply, however)
|-
| 0x086700C4
| [[4.0.0-7]]
| [[FS:ControlSecureSave|ControlSecureSave]]
| 0x121004
|-
| 0x08680000
| [[4.0.0-7]]
| [[FS:GetMediaType|GetMediaType]]
| None
|-
| 0x08690000
| [[4.0.0-7]]
| [[FS:Obsoleted_4_0_GetNandEraseCount|Obsoleted_4_0_GetNandEraseCount]]
| Stubbed, this returns an error.
|-
| 0x086A0082
| [[4.0.0-7]]
| [[FS:ReadNandReport|ReadNandReport]]
| None
|-
| 0x086B00C2
|?
|?
| 00121004
|-
| 0x086C00C2
|?
|?
| 00121004
|-
| 0x086D0040
|?
|?
| 00020004
|-
| 0x086E00C0
|Related to Secure Value? Used in Pokemon Sun/Moon.
|?
|None?
|-
| 0x086F0040
|Related to Secure Value? Used in Pokemon Sun/Moon.
|?
| 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
|-
| 0x087A0180
| [[9.6.0-24|9.6.0-X]]
| [[FS:AddSeed|AddSeed]]
| 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
|-
| 0x08840042
| [[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
|-
| 0x088600C0
| [[11.1.0-34|11.1.0-X]]
| [[FS:CheckUpdatedDat|CheckUpdatedDat]]
| 0x00080000
|}

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

== 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
| [[FSReg:Dummy1|Dummy1]]
|-
| 0x040103C0
| [[FSReg:Register|Register]]
|-
| 0x04020040
| [[FSReg:Unregister|Unregister]]
|-
| 0x040300C0
| [[FSReg:GetProgramInfo|GetProgramInfo]]
|-
| 0x04040100
| [[FSReg:LoadProgram|LoadProgram]]
|-
| 0x04050080
| [[FSReg:UnloadProgram|UnloadProgram]]
|-
| 0x04060080
| [[FSReg:CheckHostLoadId|CheckHostLoadId]]
|}

Only two sessions can be opened for this service at a time, hence no other processes can use this due to [[Process_Manager_Services|pm-module]] and [[Loader_Services|loader]] using this.

=File and directory access=
==Files==
File session handles obtained via [[FS:OpenFile]] et al can be used to access files through a service-like interface, despite not being an actual service registered using [[SRV:RegisterService]].

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

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

= Archives =
{| class="wikitable" border="1"
|-
! ArchiveId
! Description
! Accessible via [[Filesystem_services|FS]]
! Accessible via [[Filesystem_services_PXI|FSPXI]]
! Only accessible by Process9 internally
! Requires binary [[FS:OpenFile|Lowpath]]
! Required exheader FS access info bitmask
|-
| 0x00000003
| SelfNCCH (including [[#RomFS|RomFS]])
| Yes
| No
| No
| No
| None
|-
| 0x00000004
| SaveData (the saveID/mediatype for this is loaded from data originally from the user process' exheader)
| Yes
| No
| No
| No
| None
|-
| 0x00000006
| ExtSaveData
| Yes
| No
| No
| Yes
| 0x100D, when the input extdataID isn't listed in the exheader.
|-
| 0x00000007
| Shared ExtSaveData
| Yes
| No
| No
| Yes
| None
|-
| 0x00000008
| SystemSaveData
| Yes
| No
| No
| Yes
| 0x4, when the input saveID doesn't match the exheader system-saveID.
|-
| 0x00000009
| SDMC
| Yes
| Yes
| No
| No
| 0x8E
|-
| 0x0000000A
| SDMC Write-Only
| Yes
| No
| No
| No
| 0x808E
|-
| 0x12345678
| ExtSaveData for BOSS
| Yes
| No
| No
| Yes
| 0x44
|-
| 0x12345679
| CARD SPI FS
| Yes
| Yes
| No
| No
| 0x16
|-
| 0x1234567B
| ExtSaveData, and ExtSaveData for BOSS
| No
| Yes
| No
| Yes
|
|-
| 0x1234567C
| SystemSaveData
| No
| Yes
| No
| Yes
|
|-
| 0x1234567D
| NAND RW
| Yes
| Yes
| No
| No
| 0x800
|-
| 0x1234567E
| NAND RO
| Yes
| Yes
| No
| No
| 0x200
|-
| 0x1234567F
| NAND RO Write FS
| No
| Yes
| No
| No
| ?
|-
| 0x12345680
| Unknown. There's code for this in spider v9.9, but that code isn't actually used.
| Yes
| ?
| No
| Yes
| ?
|-
| 0x12345681
| Unknown. Accessed by FS service.
| ?
| ?
| No
| ?
| ?
|-
| 0x12345682
| Unknown. There's code for this in spider v9.9, but that code isn't actually used.
| Yes
| ?
| No
| Yes
| ?
|-
| 0x2345678A
| Used for accessing general NCCH data. With FSPXI this also allows savedata access.
| Yes
| Yes
| No
| Yes
| 0x1005
|-
| 0x2345678B
| ?
| No
| No
| Yes
| Yes
|
|-
| 0x2345678C
| Used internally to access [[Title_Database|/dbs]] files?
| No
| No
| Yes
| Yes
|
|-
| 0x2345678D
| ?
| No
| No
| Yes
| No
|
|-
| 0x2345678E
| FSPXI: Similar to archive 0x2345678A. For fs:LDR(used by the "loader" FIRM ARM11-process), only ExeFS. Not accessible with fs:USER.
| Yes
| Yes
| No
| Yes
| None, see description.
|-
| 0x567890AB
| NAND CTR FS
| No
| Yes
| No
| No
| ?
|-
| 0x567890AC
| TWL PHOTO
| Yes
| Yes
| No
| No
| ?
|-
| 0x567890AD
| TWLS (DSi Sound stores recordings here). This is mapped to the FAT12 image stored in the file at [[Twln/shared2/0000]].
| No
| Yes
| No
| No
| ?
|-
| 0x567890AE
| NAND TWL FS
| Yes
| Yes
| No
| No
| 0x100
|-
| 0x567890AF
| NAND W FS
| Yes
| Yes
| No
| No
| 0x100
|-
| 0x567890B0
| ?
| No
| Yes
| No
| No
|
|-
| 0x567890B1
| Gamecard SaveData (for check). This is a wrapper for UserSaveDataForCheck: the OpenArchive code for that is called with archive-lowpath TID=0/mediatype=2(gamecard).
| Yes
| No
| No
| No
| 0x6
|-
| 0x567890B2
| UserSaveData (for check). This is the same as the regular SaveData archive, except with this the savedata ID and mediatype is loaded from the input archive lowpath.
| Yes
| No
| No
| Yes
| 0x6
|-
| 0x567890B4
| Similar to 0x567890B2 but can only access Accessible Save specified in [[NCCH/Extended_Header#Storage_Info|exheader]]?
| Yes
| No
| No
| Yes
| ?
|}

Archives listed as not requiring a binary lowpath, use lowpath type [[FS:OpenFile|empty]].

The above permission bitmasks are from v2.x, see the above Services section for how these are handled.

Archives CTR NAND, NAND RO Write FS, TWL NAND, NAND W FS, and CARD SPI FS require the corresponding process exheader access control mount flag to be set, in the exheader for any of the currently running ARM11 processes, for [[Filesystem_services_PXI|FSPXI]]. The access rights checked by [[Filesystem services|FS]] module for archive mounting with fs:USER, are stored in the process' exheader accessinfo.

The CARDSPI archive allows access to the gamecard CARD1 raw savedata flash(aka "cardspi:/" in [[FIRM|Process9]]), the file lowpath must be WCHAR "/". The "NAND W FS" archive allows access to the raw NAND image(aka "wnand:/" in Process9), the file lowpath must be WCHAR "/".

= Filenames and Paths =
PathType:
{| class="wikitable" border="1"
|-
! Value
! Description
|-
| -1
| Returned internally by Process9, when errors occur it seems(in particular when no nul-terminator was found in the input path). The data ptr is set to NULL.
|-
| 0x0
| INVALID - Specifies an invalid path
|-
| 0x1
| EMPTY - Specifies an empty path
|-
| 0x2
| BINARY - Non-text based path. Meaning is per-archive
|-
| 0x3
| ASCII - Text-based path with 7-bit ASCII characters padded to 8-bits each (signed char)
|-
| 0x4
| UTF16 - Text-based path with UTF-16 characters
|}

In IPC requests, sizes of ASCII and UTF16 paths must include space for the null-terminator.

== Binary LowPath ==
The format of the data that a binary LowPath points to is custom per archive.

=== SelfNCCH File Path Data Format ===
{| class="wikitable" border="1"
|-
! Index word
! Description
|-
| 0
| Type:
* 0x0: RomFS
* 0x1: error 0xD9004676
* 0x2: ExeFS
* 0x3: Error 0xE0E046BE.
* 0x4: FS-module crashes on this
* 0x5: Update RomFS?
|-
| 1-2
| File name for ExeFS ("icon"/"banner"/"logo"). ".code" is not allowed
|}

Note that ExeFS files only support reading from offset=0 and with size=file_size.

=== SystemSaveData Archive Path Data Format ===
==== FS ====
{| class="wikitable" border="1"
|-
! Index word
! Description
|-
| 0
| [[Mediatypes|Mediatype]] (must be zero for NAND)
|-
| 1
| saveid
|}
The file/directory lowpath is a text lowpath in the [[Savegames|savegame]] filesystem.

==== FSPXI ====
{| class="wikitable" border="1"
|-
! Index word
! Description
|-
| 0
| u8 [[Mediatypes|Mediatype]] (must be zero for NAND)
|}
The file lowpath is a binary lowpath containing the u64 saveid, however the high word of the saveid is always zero. The mounted file is the cleartext savegame image. Up to 32 SystemSaveData image files can be opened under a single mounted FSPXI archive.

=== UserSaveDataForCheck Archive Path Data Format ===
{| class="wikitable" border="1"
|-
! Index word
! Description
|-
| 0
| [[Mediatypes|Mediatype]] (must be non-zero)
|-
| 1
| Lower word saveid
|-
| 2
| Upper word saveid
|}
The file/directory lowpath for this FS archive is a text path in the [[Savegames|savegame]] filesystem.

=== 0x567890B4 Archive Path Data Format ===
{| class="wikitable" border="1"
|-
! Index word
! Description
|-
| 0
| [[Mediatypes|Mediatype]]
|-
| 1
| <code><nowiki>Lower_word_saveid >> 8</nowiki></code> ?
|-
| 2
| Unknown. Game calculate this using formula <code><nowiki>(unknown_a & 0xFFFFFF00) | unknown_b</nowiki></code>
|}

=== ExtSaveData Archive Path Data Format ===
{| class="wikitable" border="1"
|-
! Index word
! Description
|-
| 0
| [[Mediatypes|Mediatype]]
|-
| 1
| Lower word saveid
|-
| 2
| Upper word saveid
|}
For FS, the file/directory lowpath is a text path in the [[extdata]] filesystem. For FSPXI, the file lowpath is a text path relative to the "/extdata/<ExtdataIDHigh>/<ExtdataIDLow>" directory on SD/NAND, for the cleartext extdata image to mount.

=== 0x2345678A Archive Path Data Format ===
{| class="wikitable" border="1"
|-
! Index word
! Description
|-
| 0
| Lower word programID
|-
| 1
| Upper word programID
|-
| 2
| ([[Mediatypes|Mediatype]] & 0xFF) | (uninitialized_data? & 0xFFFFFF00)
|-
| 3
| Number of something? Hardcoded per-archive, 0 for ExeFS, 200 for area:, 100 for rate:, 40 for eula:, etc.
|}

File lowpath:
{| class="wikitable" border="1"
|-
! Index word
! Description
|-
| 0
| 0 for NCCH data, 1 for savedata. The latter is only valid for FSPXI. Value 2 is allowed via archive 0x3, it's unknown what this is.
|-
| 1
| TMD content index / NCSD partition index.
|-
| 2
| Type: 0=romfs(0 for non-NCCH as well), 1=exefs ".code"(?), 2=exefs "icon"/"banner"/"logo", 3=unknown, 4=unknown, 5=unknown.
|-
| 3-4
| Filename for ExeFS.
|}

The 0x14-byte lowpath is all-zero for accessing the title's main RomFS.

=== [[RomFS]] ===

Archives 0x3 and 0x2345678E both allow for accessing the [[RomFS#Level_3_Format|level-3 IVFC images]] for RomFS access. The main CXI RomFS is accessible via an all-zero 0xc-byte binary file-lowpath. The update RomFS can be accessed with the first u32 in the binary file-lowpath being set to 0x5. The user must handle parsing the filesystem used in the exposed image itself.

With FSPXI the returned data for RomFS is the entire RomFS section from the NCCH, starting at the IVFC header.

The 0x3 archive is an interface for the 0x2345678E archive with the current process programID+mediatype. The file lowpath is 3-words. These words are written to 0x2345678E-archive file_lowpath+0, with the rest of that lowpath set to all-zero(lowpath is different from archive 0x2345678A). File lowpath:
{| class="wikitable" border="1"
|-
! Index word
! Description
|-
| 0
| See above. The only values which FS-module doesn't allow to be used here are:
* 0x1: Error 0xE0E046BE.
* 0x3: Error 0xE0E046BE.
* 0x4: FS-module executes svcBreak when using this.
|-
| 1-2
| See above. Not validated by FS-module.
|}

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

= Common Types =
== MediaType ==
{| class="wikitable" border="1"
|-
! Value
! Description
|-
| 0
| NAND
|-
| 1
| SD
|-
| 2
| Game Card
|}

== SystemMediaType ==
{| class="wikitable" border="1"
|-
! Value
! Description
|-
| 0
| CTR NAND
|-
| 1
| TWL NAND
|-
| 2
| SD
|-
| 2
| TWL Photo
|}

== OpenFlags ==
{| class="wikitable" border="1"
|-
! Bit
! Description
|-
| 0
| Read
|-
| 1
| Write
|-
| 2
| Create
|}

== Attributes ==
{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
|-
| 0x0
| 0x1
| Is Directory
|-
| 0x1
| 0x1
| Is Hidden
|-
| 0x2
| 0x1
| Is Archive
|-
| 0x3
| 0x1
| Is Read-Only
|}

== WriteOption ==
{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
|-
| 0x0
| 0x1
| Flush
|-
| 0x1
| 0x1
| Update Time Stamp
|-
| 0x2
| 0x1
| Reserved
|-
| 0x3
| 0x1
| Reserved
|}

== DirectoryEntry ==
{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
|-
| 0x0
| 0x20C
| UTF-16 Entry Name
|-
| 0x20C
| 0xA
| 8.3 short filename name
|-
| 0x216
| 0x4
| 8.3 short filename extension
|-
| 0x21A
| 0x1
| Always 1
|-
| 0x21B
| 0x1
| Reserved
|-
| 0x21C
| 0x4
| [[Filesystem_services#Attributes|Attributes]]
|-
| 0x220
| 0x8
| Entry Size
|}

== ArchiveResource ==
{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
|-
| 0x0
| 0x4
| Sector byte-size
|-
| 0x4
| 0x4
| Cluster byte-size
|-
| 0x8
| 0x4
| Partition capacity in clusters
|-
| 0xC
| 0x4
| Available free space in clusters
|}

== ProgramInfo ==
{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
|-
| 0x0
| 0x8
| Program ID
|-
| 0x8
| 0x1
| [[Filesystem_services#MediaType|Media Type]]
|-
| 0x9
| 0x7
| Padding
|}

== ProductInfo ==
{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
|-
| 0x0
| 0x10
| Product Code
|-
| 0x10
| 0x2
| Company Code
|-
| 0x12
| 0x2
| Remaster Version
|}

== IntegrityVerificationSeed ==
{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
|-
| 0x0
| 0x10
| AES-CBC MAC over a SHA256 hash, which hashes the first 0x110-bytes of the cleartext SEED.
|-
| 0x10
| 0x120
| The [[nand/private/movable.sed]], encrypted with AES-CTR using the above MAC for the counter.
|}

== ExtSaveDataInfo ==
{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
|-
| 0x0
| 0x1
| [[Filesystem_services#MediaType|Media Type]]
|-
| 0x1
| 0x1
| Unknown
|-
| 0x2
| 0x2
| Reserved
|-
| 0x4
| 0x8
| Save ID
|-
| 0xC
| 0x4
| Reserved
|}

== SystemSaveDataInfo ==
{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
|-
| 0x0
| 0x1
| [[Filesystem_services#MediaType|Media Type]]
|-
| 0x1
| 0x1
| Unknown
|-
| 0x2
| 0x2
| Reserved
|-
| 0x4
| 0x4
| Save ID
|}

== SecureValueSlot ==
{| class="wikitable" border="1"
|-
! Value
! Description
|-
| 0x1000
| SD Application
|}

== CardSpiBaudRate ==
{| class="wikitable" border="1"
|-
! Value
! Description
|-
| 0x0
| 512KHz
|-
| 0x1
| 1MHz
|-
| 0x2
| 2MHz
|-
| 0x3
| 4MHz
|-
| 0x4
| 8MHz
|-
| 0x5
| 16MHz
|}

== CardSpiBusMode ==
{| class="wikitable" border="1"
|-
! Value
! Description
|-
| 0x0
| 1-bit
|-
| 0x1
| 4-bit
|}

== SpecialContentType ==
{| class="wikitable" border="1"
|-
! Value
! Description
|-
| 0x1
| Update
|-
| 0x2
| Manual
|-
| 0x3
| DLP Child
|}

== DeviceMoveContext ==
{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
|-
| 0x0
| 0x10
| IVs
|-
| 0x10
| 0x10
| Encrypt Parameter
|}

=Errors=
See [[Filesystem_services_PXI]].

Filesystem services

2017-10-03T16:18:55Z

Shinyquagsire23: TID 0004009b00010202 seems to get its content ID 0 accessed with 0x2? MSET's manual (index 1) is accessed with 0x5 and 0x1 seems to be the norm for most archive's content index 0.

[[Category:Services]]

= 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
|?
| [[FS:Dummy1|Dummy1]]
| None
|-
| 0x040100C4
|?
| [[FS:Control|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
|?
| [[FS:ControlArchive|ControlArchive]]
| None
|-
| 0x080E0080
|?
| [[FS:CloseArchive|CloseArchive]]
| None
|-
| 0x080F0180
|?
| [[FS:Obsoleted_2_0_FormatThisUserSaveData|Obsoleted_2_0_FormatThisUserSaveData]]
| None
|-
| 0x08100200
|?
| [[FS:Obsoleted_3_0_CreateSystemSaveData|Obsoleted_3_0_CreateSystemSaveData]]
| 0x4, for when the input saveID doesn't match the exheader saveID
|-
| 0x08110040
|?
| [[FS:Obsoleted_3_0_DeleteSystemSaveData|Obsoleted_3_0_DeleteSystemSaveData]]
| 0x1004, for when the input saveID doesn't match the exheader saveID
|-
| 0x08120080
|?
| [[FS:GetFreeBytes|GetFreeBytes]]
| None
|-
| 0x08130000
|?
| [[FS:GetCardType|GetCardType]]
| 0x1017
|-
| 0x08140000
|?
| [[FS:GetSdmcArchiveResource|GetSdmcArchiveResource]]
| None
|-
| 0x08150000
|?
| [[FS:GetNandArchiveResource|GetNandArchiveResource]]
| 0x1007
|-
| 0x08160000
|?
| [[FS:GetSdmcFatfsError|GetSdmcFatfsError]]
| 0x2
|-
| 0x08170000
|?
| [[FS:IsSdmcDetected|IsSdmcDetected]]
| None
|-
| 0x08180000
|?
| [[FS:IsSdmcWritable|IsSdmcWritable]]
| None
|-
| 0x08190042
|?
| [[FS:GetSdmcCid|GetSdmcCid]]
| 0x2
|-
| 0x081A0042
|?
| [[FS:GetNandCid|GetNandCid]]
| 0x2
|-
| 0x081B0000
|?
| [[FS:GetSdmcSpeedInfo|GetSdmcSpeedInfo]]
| 0x2
|-
| 0x081C0000
|?
| [[FS:GetNandSpeedInfo|GetNandSpeedInfo]]
| 0x2
|-
| 0x081D0042
|?
| [[FS:GetSdmcLog|GetSdmcLog]]
| 0x2
|-
| 0x081E0042
|?
| [[FS:GetNandLog|GetNandLog]]
| 0x2
|-
| 0x081F0000
|?
| [[FS:ClearSdmcLog|ClearSdmcLog]]
| 0x2
|-
| 0x08200000
|?
| [[FS:ClearNandLog|ClearNandLog]]
| 0x2
|-
| 0x08210000
|?
| [[FS:CardSlotIsInserted|CardSlotIsInserted]]
| 0x1017
|-
| 0x08220000
|?
| [[FS:CardSlotPowerOn|CardSlotPowerOn]]
| 0x2
|-
| 0x08230000
|?
| [[FS:CardSlotPowerOff|CardSlotPowerOff]]
| 0x2
|-
| 0x08240000
|?
| [[FS:CardSlotGetCardIFPowerStatus|CardSlotGetCardIFPowerStatus]]
| 0x2
|-
| 0x08250040
|?
| [[FS:CardNorDirectCommand|CardNorDirectCommand]]
| 0x2
|-
| 0x08260080
|?
| [[FS:CardNorDirectCommandWithAddress|CardNorDirectCommandWithAddress]]
| 0x2
|-
| 0x08270082
|?
| [[FS:CardNorDirectRead|CardNorDirectRead]]
| 0x2
|-
| 0x082800C2
|?
| [[FS:CardNorDirectReadWithAddress|CardNorDirectReadWithAddress]]
| 0x2
|-
| 0x08290082
|?
| [[FS:CardNorDirectWrite|CardNorDirectWrite]]
| 0x2
|-
| 0x082A00C2
|?
| [[FS:CardNorDirectWriteWithAddress|CardNorDirectWriteWithAddress]]
| 0x2
|-
| 0x082B00C2
|?
| [[FS:CardNorDirectRead_4xIO|CardNorDirectRead_4xIO]]
| 0x2
|-
| 0x082C0082
|?
| [[FS:CardNorDirectCpuWriteWithoutVerify|CardNorDirectCpuWriteWithoutVerify]]
| 0x2
|-
| 0x082D0040
|?
| [[FS:CardNorDirectSectorEraseWithoutVerify|CardNorDirectSectorEraseWithoutVerify]]
| 0x2
|-
| 0x082E0040
|?
| [[FS:GetProductInfo|GetProductInfo]]
| 0x1005
|-
| 0x082F0040
|?
| [[FS:GetProgramLaunchInfo|GetProgramLaunchInfo]]
| 0x1005
|-
| 0x08300182
|?
| [[FS:Obsoleted_3_0_CreateExtSaveData|Obsoleted_3_0_CreateExtSaveData]]
| 0xC, for when the input extdataID doesn't match the exheader extdataID
|-
| 0x08310180
|?
| [[FS:Obsoleted_3_0_CreateSharedExtSaveData|Obsoleted_3_0_CreateSharedExtSaveData]]
| 0x1005
|-
| 0x08320102
|?
| [[FS:Obsoleted_3_0_ReadExtSaveDataIcon|Obsoleted_3_0_ReadExtSaveDataIcon]]
| 0x100D, for when the input extdataID doesn't match the exheader extdataID
|-
| 0x08330082
|?
| [[FS:Obsoleted_3_0_EnumerateExtSaveData|Obsoleted_3_0_EnumerateExtSaveData]]
| 0x1005
|-
| 0x08340082
|?
| [[FS:Obsoleted_3_0_EnumerateSharedExtSaveData|Obsoleted_3_0_EnumerateSharedExtSaveData]]
| 0x1005
|-
| 0x08350080
|?
| [[FS:Obsoleted_3_0_DeleteExtSaveData|Obsoleted_3_0_DeleteExtSaveData]]
| 0x100D, for when the input extdataID doesn't match the exheader extdataID
|-
| 0x08360080
|?
| [[FS:Obsoleted_3_0_DeleteSharedExtSaveData|Obsoleted_3_0_DeleteSharedExtSaveData]]
| 0x1005
|-
| 0x08370040
|?
| [[FS:SetCardSpiBaudRate|SetCardSpiBaudRate]]
| 0x2
|-
| 0x08380040
|?
| [[FS:SetCardSpiBusMode|SetCardSpiBusMode]]
| 0x2
|-
| 0x08390000
|?
| [[FS:SendInitializeInfoTo9|SendInitializeInfoTo9]]
| None
|-
| 0x083A0100
|?
| [[FS:GetSpecialContentIndex|GetSpecialContentIndex]]
| 0x1005
|-
| 0x083B00C2
|?
| [[FS:GetLegacyRomHeader|GetLegacyRomHeader]]
| 0x1015
|-
| 0x083C00C2
|?
| [[FS:GetLegacyBannerData|GetLegacyBannerData]]
| 0x1015
|-
| 0x083D0100
|?
| [[FS:CheckAuthorityToAccessExtSaveData|CheckAuthorityToAccessExtSaveData]]
| 0x44
|-
| 0x083E00C2
|?
| [[FS:QueryTotalQuotaSize|QueryTotalQuotaSize]]
| None
|-
| 0x083F00C0
|?
| [[FS:Obsoleted_3_0_GetExtDataBlockSize|Obsoleted_3_0_GetExtDataBlockSize]]
| None
|-
| 0x08400040
|?
| [[FS:AbnegateAccessRight|AbnegateAccessRight]]
|?
|-
| 0x08410000
|?
| [[FS:DeleteSdmcRoot|DeleteSdmcRoot]]
| 0x1005
|-
| 0x08420040
|?
| [[FS:DeleteAllExtSaveDataOnNand|DeleteAllExtSaveDataOnNand]]
| 0x1005
|-
| 0x08430000
|?
| [[FS:InitializeCtrFileSystem|InitializeCtrFileSystem]]
| None
|-
| 0x08440000
|?
| [[FS:CreateSeed|CreateSeed]]
| 0x2
|-
| 0x084500C2
|?
| [[FS:GetFormatInfo|GetFormatInfo]]
|?
|-
| 0x08460102
|?
| [[FS:GetLegacyRomHeader2|GetLegacyRomHeader2]]
| 0x1015
|-
| 0x08470180
|?
| [[FS:Obsoleted_2_0_FormatCtrCardUserSaveData|Obsoleted_2_0_FormatCtrCardUserSaveData]]
| 0x6
|-
| 0x08480042
|?
| [[FS:GetSdmcCtrRootPath|GetSdmcCtrRootPath]]
| 0x100D
|-
| 0x08490040
|?
| [[FS:GetArchiveResource|GetArchiveResource]]
|?
|-
| 0x084A0002
|?
| [[FS:ExportIntegrityVerificationSeed|ExportIntegrityVerificationSeed]]
| 0x4000
|-
| 0x084B0002
|?
| [[FS:ImportIntegrityVerificationSeed|ImportIntegrityVerificationSeed]]
| 0x4000
|-
| 0x084C0242
|?
| [[FS:FormatSaveData|FormatSaveData]]
| 0x6, in some cases this write isn't needed however
|-
| 0x084D0102
|?
| [[FS:GetLegacySubBannerData|GetLegacySubBannerData]]
| 0x1015
|-
| 0x084E0342
|?
| [[FS:UpdateSha256Context|UpdateSha256Context]]
| 0x5
|-
| 0x084F0102
|?
| [[FS:ReadSpecialFile|ReadSpecialFile]]
| None
|-
| 0x08500040
|?
| [[FS:GetSpecialFileSize|GetSpecialFileSize]]
| None
|-
| 0x08510242
| [[3.0.0-5]]
| [[FS:CreateExtSaveData|CreateExtSaveData]]
| Shared extdata: 0x101005. Regular extdata in certain cases: 0xC
|-
| 0x08520100
| [[3.0.0-5]]
| [[FS:DeleteExtSaveData|DeleteExtSaveData]]
| Shared extdata: 0x101005. Regular extdata in certain cases: 0x10100D
|-
| 0x08530142
| [[3.0.0-5]]
| [[FS:ReadExtSaveDataIcon|ReadExtSaveDataIcon]]
| 0x10100D (this doesn't apply in certain cases, however)
|-
| 0x085400C0
| [[3.0.0-5]]
| [[FS:GetExtDataBlockSize|GetExtDataBlockSize]]
| 0x10100D (this doesn't apply in certain cases, however)
|-
| 0x08550102
| [[3.0.0-5]]
| [[FS:EnumerateExtSaveData|EnumerateExtSaveData]]
| 0x101005
|-
| 0x08560240
| [[3.0.0-5]]
| [[FS:CreateSystemSaveData|CreateSystemSaveData]]
| 0x4 (this doesn't apply in certain cases, however)
|-
| 0x08570080
| [[3.0.0-5]]
| [[FS:DeleteSystemSaveData|DeleteSystemSaveData]]
| 0x1004 (this doesn't apply in certain cases, however)
|-
| 0x08580000
| [[3.0.0-5]]
| [[FS:StartDeviceMoveAsSource|StartDeviceMoveAsSource]]
| 0x2004
|-
| 0x08590200
| [[3.0.0-5]]
| [[FS:StartDeviceMoveAsDestination|StartDeviceMoveAsDestination]]
| 0x2004
|-
| 0x085A00C0
| [[3.0.0-5]]
| [[FS:SetArchivePriority|SetArchivePriority]]
| None
|-
| 0x085B0080
| [[3.0.0-5]]
| [[FS:GetArchivePriority|GetArchivePriority]]
| None
|-
| 0x085C00C0
| [[3.0.0-5]]
| [[FS:SetCtrCardLatencyParameter|SetCtrCardLatencyParameter]]
| 0xE
|-
| 0x085D01C0
| [[3.0.0-5]]
| [[FS:SetFsCompatibilityInfo|SetFsCompatibilityInfo]]
| 0x100001
|-
| 0x085E0040
| [[3.0.0-5]]
| [[FS:ResetCardCompatibilityParameter|ResetCardCompatibilityParameter]]
| 0xE
|-
| 0x085F0040
| [[3.0.0-5]]
| [[FS:SwitchCleanupInvalidSaveData|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]]
| [[FS:SetPriority|SetPriority]]
| None
|-
| 0x08630000
| [[3.0.0-5]]
| [[FS:GetPriority|GetPriority]]
| None
|-
| 0x08640000
| [[3.0.0-5]]
| [[FS:Obsoleted_4_0_GetNandInfo|Obsoleted_4_0_GetNandInfo]]
| Stubbed, this returns an error
|-
| 0x08650140
| [[4.0.0-7]]
| [[FS:SetSaveDataSecureValue|SetSaveDataSecureValue]]
| 0x121004 (in certain cases this doesn't apply, however)
|-
| 0x086600C0
| [[4.0.0-7]]
| [[FS:GetSaveDataSecureValue|GetSaveDataSecureValue]]
| 0x121004 (in certain cases this doesn't apply, however)
|-
| 0x086700C4
| [[4.0.0-7]]
| [[FS:ControlSecureSave|ControlSecureSave]]
| 0x121004
|-
| 0x08680000
| [[4.0.0-7]]
| [[FS:GetMediaType|GetMediaType]]
| None
|-
| 0x08690000
| [[4.0.0-7]]
| [[FS:Obsoleted_4_0_GetNandEraseCount|Obsoleted_4_0_GetNandEraseCount]]
| Stubbed, this returns an error.
|-
| 0x086A0082
| [[4.0.0-7]]
| [[FS:ReadNandReport|ReadNandReport]]
| None
|-
| 0x086B00C2
|?
|?
| 00121004
|-
| 0x086C00C2
|?
|?
| 00121004
|-
| 0x086D0040
|?
|?
| 00020004
|-
| 0x086E00C0
|Related to Secure Value? Used in Pokemon Sun/Moon.
|?
|None?
|-
| 0x086F0040
|Related to Secure Value? Used in Pokemon Sun/Moon.
|?
| 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
|-
| 0x087A0180
| [[9.6.0-24|9.6.0-X]]
| [[FS:AddSeed|AddSeed]]
| 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
|-
| 0x08840042
| [[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
|-
| 0x088600C0
| [[11.1.0-34|11.1.0-X]]
| [[FS:CheckUpdatedDat|CheckUpdatedDat]]
| 0x00080000
|}

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

== 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
| [[FSReg:Dummy1|Dummy1]]
|-
| 0x040103C0
| [[FSReg:Register|Register]]
|-
| 0x04020040
| [[FSReg:Unregister|Unregister]]
|-
| 0x040300C0
| [[FSReg:GetProgramInfo|GetProgramInfo]]
|-
| 0x04040100
| [[FSReg:LoadProgram|LoadProgram]]
|-
| 0x04050080
| [[FSReg:UnloadProgram|UnloadProgram]]
|-
| 0x04060080
| [[FSReg:CheckHostLoadId|CheckHostLoadId]]
|}

Only two sessions can be opened for this service at a time, hence no other processes can use this due to [[Process_Manager_Services|pm-module]] and [[Loader_Services|loader]] using this.

=File and directory access=
==Files==
File session handles obtained via [[FS:OpenFile]] et al can be used to access files through a service-like interface, despite not being an actual service registered using [[SRV:RegisterService]].

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

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

= Archives =
{| class="wikitable" border="1"
|-
! ArchiveId
! Description
! Accessible via [[Filesystem_services|FS]]
! Accessible via [[Filesystem_services_PXI|FSPXI]]
! Only accessible by Process9 internally
! Requires binary [[FS:OpenFile|Lowpath]]
! Required exheader FS access info bitmask
|-
| 0x00000003
| SelfNCCH (including [[#RomFS|RomFS]])
| Yes
| No
| No
| No
| None
|-
| 0x00000004
| SaveData (the saveID/mediatype for this is loaded from data originally from the user process' exheader)
| Yes
| No
| No
| No
| None
|-
| 0x00000006
| ExtSaveData
| Yes
| No
| No
| Yes
| 0x100D, when the input extdataID isn't listed in the exheader.
|-
| 0x00000007
| Shared ExtSaveData
| Yes
| No
| No
| Yes
| None
|-
| 0x00000008
| SystemSaveData
| Yes
| No
| No
| Yes
| 0x4, when the input saveID doesn't match the exheader system-saveID.
|-
| 0x00000009
| SDMC
| Yes
| Yes
| No
| No
| 0x8E
|-
| 0x0000000A
| SDMC Write-Only
| Yes
| No
| No
| No
| 0x808E
|-
| 0x12345678
| ExtSaveData for BOSS
| Yes
| No
| No
| Yes
| 0x44
|-
| 0x12345679
| CARD SPI FS
| Yes
| Yes
| No
| No
| 0x16
|-
| 0x1234567B
| ExtSaveData, and ExtSaveData for BOSS
| No
| Yes
| No
| Yes
|
|-
| 0x1234567C
| SystemSaveData
| No
| Yes
| No
| Yes
|
|-
| 0x1234567D
| NAND RW
| Yes
| Yes
| No
| No
| 0x800
|-
| 0x1234567E
| NAND RO
| Yes
| Yes
| No
| No
| 0x200
|-
| 0x1234567F
| NAND RO Write FS
| No
| Yes
| No
| No
| ?
|-
| 0x12345680
| Unknown. There's code for this in spider v9.9, but that code isn't actually used.
| Yes
| ?
| No
| Yes
| ?
|-
| 0x12345681
| Unknown. Accessed by FS service.
| ?
| ?
| No
| ?
| ?
|-
| 0x12345682
| Unknown. There's code for this in spider v9.9, but that code isn't actually used.
| Yes
| ?
| No
| Yes
| ?
|-
| 0x2345678A
| Used for accessing general NCCH data. With FSPXI this also allows savedata access.
| Yes
| Yes
| No
| Yes
| 0x1005
|-
| 0x2345678B
| ?
| No
| No
| Yes
| Yes
|
|-
| 0x2345678C
| Used internally to access [[Title_Database|/dbs]] files?
| No
| No
| Yes
| Yes
|
|-
| 0x2345678D
| ?
| No
| No
| Yes
| No
|
|-
| 0x2345678E
| FSPXI: Similar to archive 0x2345678A. For fs:LDR(used by the "loader" FIRM ARM11-process), only ExeFS. Not accessible with fs:USER.
| Yes
| Yes
| No
| Yes
| None, see description.
|-
| 0x567890AB
| NAND CTR FS
| No
| Yes
| No
| No
| ?
|-
| 0x567890AC
| TWL PHOTO
| Yes
| Yes
| No
| No
| ?
|-
| 0x567890AD
| TWLS (DSi Sound stores recordings here). This is mapped to the FAT12 image stored in the file at [[Twln/shared2/0000]].
| No
| Yes
| No
| No
| ?
|-
| 0x567890AE
| NAND TWL FS
| Yes
| Yes
| No
| No
| 0x100
|-
| 0x567890AF
| NAND W FS
| Yes
| Yes
| No
| No
| 0x100
|-
| 0x567890B0
| ?
| No
| Yes
| No
| No
|
|-
| 0x567890B1
| Gamecard SaveData (for check). This is a wrapper for UserSaveDataForCheck: the OpenArchive code for that is called with archive-lowpath TID=0/mediatype=2(gamecard).
| Yes
| No
| No
| No
| 0x6
|-
| 0x567890B2
| UserSaveData (for check). This is the same as the regular SaveData archive, except with this the savedata ID and mediatype is loaded from the input archive lowpath.
| Yes
| No
| No
| Yes
| 0x6
|-
| 0x567890B4
| Similar to 0x567890B2 but can only access Accessible Save specified in [[NCCH/Extended_Header#Storage_Info|exheader]]?
| Yes
| No
| No
| Yes
| ?
|}

Archives listed as not requiring a binary lowpath, use lowpath type [[FS:OpenFile|empty]].

The above permission bitmasks are from v2.x, see the above Services section for how these are handled.

Archives CTR NAND, NAND RO Write FS, TWL NAND, NAND W FS, and CARD SPI FS require the corresponding process exheader access control mount flag to be set, in the exheader for any of the currently running ARM11 processes, for [[Filesystem_services_PXI|FSPXI]]. The access rights checked by [[Filesystem services|FS]] module for archive mounting with fs:USER, are stored in the process' exheader accessinfo.

The CARDSPI archive allows access to the gamecard CARD1 raw savedata flash(aka "cardspi:/" in [[FIRM|Process9]]), the file lowpath must be WCHAR "/". The "NAND W FS" archive allows access to the raw NAND image(aka "wnand:/" in Process9), the file lowpath must be WCHAR "/".

= Filenames and Paths =
PathType:
{| class="wikitable" border="1"
|-
! Value
! Description
|-
| -1
| Returned internally by Process9, when errors occur it seems(in particular when no nul-terminator was found in the input path). The data ptr is set to NULL.
|-
| 0x0
| INVALID - Specifies an invalid path
|-
| 0x1
| EMPTY - Specifies an empty path
|-
| 0x2
| BINARY - Non-text based path. Meaning is per-archive
|-
| 0x3
| ASCII - Text-based path with 7-bit ASCII characters padded to 8-bits each (signed char)
|-
| 0x4
| UTF16 - Text-based path with UTF-16 characters
|}

In IPC requests, sizes of ASCII and UTF16 paths must include space for the null-terminator.

== Binary LowPath ==
The format of the data that a binary LowPath points to is custom per archive.

=== SelfNCCH File Path Data Format ===
{| class="wikitable" border="1"
|-
! Index word
! Description
|-
| 0
| Type:
* 0x0: RomFS
* 0x1: error 0xD9004676
* 0x2: ExeFS
* 0x3: Error 0xE0E046BE.
* 0x4: FS-module crashes on this
* 0x5: Update RomFS?
|-
| 1-2
| File name for ExeFS ("icon"/"banner"/"logo"). ".code" is not allowed
|}

Note that ExeFS files only support reading from offset=0 and with size=file_size.

=== SystemSaveData Archive Path Data Format ===
==== FS ====
{| class="wikitable" border="1"
|-
! Index word
! Description
|-
| 0
| [[Mediatypes|Mediatype]] (must be zero for NAND)
|-
| 1
| saveid
|}
The file/directory lowpath is a text lowpath in the [[Savegames|savegame]] filesystem.

==== FSPXI ====
{| class="wikitable" border="1"
|-
! Index word
! Description
|-
| 0
| u8 [[Mediatypes|Mediatype]] (must be zero for NAND)
|}
The file lowpath is a binary lowpath containing the u64 saveid, however the high word of the saveid is always zero. The mounted file is the cleartext savegame image. Up to 32 SystemSaveData image files can be opened under a single mounted FSPXI archive.

=== UserSaveDataForCheck Archive Path Data Format ===
{| class="wikitable" border="1"
|-
! Index word
! Description
|-
| 0
| [[Mediatypes|Mediatype]] (must be non-zero)
|-
| 1
| Lower word saveid
|-
| 2
| Upper word saveid
|}
The file/directory lowpath for this FS archive is a text path in the [[Savegames|savegame]] filesystem.

=== 0x567890B4 Archive Path Data Format ===
{| class="wikitable" border="1"
|-
! Index word
! Description
|-
| 0
| [[Mediatypes|Mediatype]]
|-
| 1
| <code><nowiki>Lower_word_saveid >> 8</nowiki></code> ?
|-
| 2
| Unknown. Game calculate this using formula <code><nowiki>(unknown_a & 0xFFFFFF00) | unknown_b</nowiki></code>
|}

=== ExtSaveData Archive Path Data Format ===
{| class="wikitable" border="1"
|-
! Index word
! Description
|-
| 0
| [[Mediatypes|Mediatype]]
|-
| 1
| Lower word saveid
|-
| 2
| Upper word saveid
|}
For FS, the file/directory lowpath is a text path in the [[extdata]] filesystem. For FSPXI, the file lowpath is a text path relative to the "/extdata/<ExtdataIDHigh>/<ExtdataIDLow>" directory on SD/NAND, for the cleartext extdata image to mount.

=== 0x2345678A Archive Path Data Format ===
{| class="wikitable" border="1"
|-
! Index word
! Description
|-
| 0
| Lower word programID
|-
| 1
| Upper word programID
|-
| 2
| ([[Mediatypes|Mediatype]] & 0xFF) | (uninitialized_data? & 0xFFFFFF00)
|-
| 3
| [[Title_metadata#Content_chunk_records|Content Index]] << 2 | (2=romfs?, 1=romfs, 0=exefs)
|}

File lowpath:
{| class="wikitable" border="1"
|-
! Index word
! Description
|-
| 0
| 0 for NCCH data, 1 for savedata. The latter is only valid for FSPXI. Value 2 is allowed via archive 0x3, it's unknown what this is.
|-
| 1
| TMD content index / NCSD partition index.
|-
| 2
| Type: 0=romfs(0 for non-NCCH as well), 1=exefs ".code"(?), 2=exefs "icon"/"banner"/"logo", 3=unknown, 4=unknown, 5=unknown.
|-
| 3-4
| Filename for ExeFS.
|}

The 0x14-byte lowpath is all-zero for accessing the title's main RomFS.

=== [[RomFS]] ===

Archives 0x3 and 0x2345678E both allow for accessing the [[RomFS#Level_3_Format|level-3 IVFC images]] for RomFS access. The main CXI RomFS is accessible via an all-zero 0xc-byte binary file-lowpath. The update RomFS can be accessed with the first u32 in the binary file-lowpath being set to 0x5. The user must handle parsing the filesystem used in the exposed image itself.

With FSPXI the returned data for RomFS is the entire RomFS section from the NCCH, starting at the IVFC header.

The 0x3 archive is an interface for the 0x2345678E archive with the current process programID+mediatype. The file lowpath is 3-words. These words are written to 0x2345678E-archive file_lowpath+0, with the rest of that lowpath set to all-zero(lowpath is different from archive 0x2345678A). File lowpath:
{| class="wikitable" border="1"
|-
! Index word
! Description
|-
| 0
| See above. The only values which FS-module doesn't allow to be used here are:
* 0x1: Error 0xE0E046BE.
* 0x3: Error 0xE0E046BE.
* 0x4: FS-module executes svcBreak when using this.
|-
| 1-2
| See above. Not validated by FS-module.
|}

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

= Common Types =
== MediaType ==
{| class="wikitable" border="1"
|-
! Value
! Description
|-
| 0
| NAND
|-
| 1
| SD
|-
| 2
| Game Card
|}

== SystemMediaType ==
{| class="wikitable" border="1"
|-
! Value
! Description
|-
| 0
| CTR NAND
|-
| 1
| TWL NAND
|-
| 2
| SD
|-
| 2
| TWL Photo
|}

== OpenFlags ==
{| class="wikitable" border="1"
|-
! Bit
! Description
|-
| 0
| Read
|-
| 1
| Write
|-
| 2
| Create
|}

== Attributes ==
{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
|-
| 0x0
| 0x1
| Is Directory
|-
| 0x1
| 0x1
| Is Hidden
|-
| 0x2
| 0x1
| Is Archive
|-
| 0x3
| 0x1
| Is Read-Only
|}

== WriteOption ==
{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
|-
| 0x0
| 0x1
| Flush
|-
| 0x1
| 0x1
| Update Time Stamp
|-
| 0x2
| 0x1
| Reserved
|-
| 0x3
| 0x1
| Reserved
|}

== DirectoryEntry ==
{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
|-
| 0x0
| 0x20C
| UTF-16 Entry Name
|-
| 0x20C
| 0xA
| 8.3 short filename name
|-
| 0x216
| 0x4
| 8.3 short filename extension
|-
| 0x21A
| 0x1
| Always 1
|-
| 0x21B
| 0x1
| Reserved
|-
| 0x21C
| 0x4
| [[Filesystem_services#Attributes|Attributes]]
|-
| 0x220
| 0x8
| Entry Size
|}

== ArchiveResource ==
{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
|-
| 0x0
| 0x4
| Sector byte-size
|-
| 0x4
| 0x4
| Cluster byte-size
|-
| 0x8
| 0x4
| Partition capacity in clusters
|-
| 0xC
| 0x4
| Available free space in clusters
|}

== ProgramInfo ==
{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
|-
| 0x0
| 0x8
| Program ID
|-
| 0x8
| 0x1
| [[Filesystem_services#MediaType|Media Type]]
|-
| 0x9
| 0x7
| Padding
|}

== ProductInfo ==
{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
|-
| 0x0
| 0x10
| Product Code
|-
| 0x10
| 0x2
| Company Code
|-
| 0x12
| 0x2
| Remaster Version
|}

== IntegrityVerificationSeed ==
{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
|-
| 0x0
| 0x10
| AES-CBC MAC over a SHA256 hash, which hashes the first 0x110-bytes of the cleartext SEED.
|-
| 0x10
| 0x120
| The [[nand/private/movable.sed]], encrypted with AES-CTR using the above MAC for the counter.
|}

== ExtSaveDataInfo ==
{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
|-
| 0x0
| 0x1
| [[Filesystem_services#MediaType|Media Type]]
|-
| 0x1
| 0x1
| Unknown
|-
| 0x2
| 0x2
| Reserved
|-
| 0x4
| 0x8
| Save ID
|-
| 0xC
| 0x4
| Reserved
|}

== SystemSaveDataInfo ==
{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
|-
| 0x0
| 0x1
| [[Filesystem_services#MediaType|Media Type]]
|-
| 0x1
| 0x1
| Unknown
|-
| 0x2
| 0x2
| Reserved
|-
| 0x4
| 0x4
| Save ID
|}

== SecureValueSlot ==
{| class="wikitable" border="1"
|-
! Value
! Description
|-
| 0x1000
| SD Application
|}

== CardSpiBaudRate ==
{| class="wikitable" border="1"
|-
! Value
! Description
|-
| 0x0
| 512KHz
|-
| 0x1
| 1MHz
|-
| 0x2
| 2MHz
|-
| 0x3
| 4MHz
|-
| 0x4
| 8MHz
|-
| 0x5
| 16MHz
|}

== CardSpiBusMode ==
{| class="wikitable" border="1"
|-
! Value
! Description
|-
| 0x0
| 1-bit
|-
| 0x1
| 4-bit
|}

== SpecialContentType ==
{| class="wikitable" border="1"
|-
! Value
! Description
|-
| 0x1
| Update
|-
| 0x2
| Manual
|-
| 0x3
| DLP Child
|}

== DeviceMoveContext ==
{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
|-
| 0x0
| 0x10
| IVs
|-
| 0x10
| 0x10
| Encrypt Parameter
|}

=Errors=
See [[Filesystem_services_PXI]].

Filesystem services

2017-10-02T22:44:46Z

Shinyquagsire23:

[[Category:Services]]

= 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
|?
| [[FS:Dummy1|Dummy1]]
| None
|-
| 0x040100C4
|?
| [[FS:Control|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
|?
| [[FS:ControlArchive|ControlArchive]]
| None
|-
| 0x080E0080
|?
| [[FS:CloseArchive|CloseArchive]]
| None
|-
| 0x080F0180
|?
| [[FS:Obsoleted_2_0_FormatThisUserSaveData|Obsoleted_2_0_FormatThisUserSaveData]]
| None
|-
| 0x08100200
|?
| [[FS:Obsoleted_3_0_CreateSystemSaveData|Obsoleted_3_0_CreateSystemSaveData]]
| 0x4, for when the input saveID doesn't match the exheader saveID
|-
| 0x08110040
|?
| [[FS:Obsoleted_3_0_DeleteSystemSaveData|Obsoleted_3_0_DeleteSystemSaveData]]
| 0x1004, for when the input saveID doesn't match the exheader saveID
|-
| 0x08120080
|?
| [[FS:GetFreeBytes|GetFreeBytes]]
| None
|-
| 0x08130000
|?
| [[FS:GetCardType|GetCardType]]
| 0x1017
|-
| 0x08140000
|?
| [[FS:GetSdmcArchiveResource|GetSdmcArchiveResource]]
| None
|-
| 0x08150000
|?
| [[FS:GetNandArchiveResource|GetNandArchiveResource]]
| 0x1007
|-
| 0x08160000
|?
| [[FS:GetSdmcFatfsError|GetSdmcFatfsError]]
| 0x2
|-
| 0x08170000
|?
| [[FS:IsSdmcDetected|IsSdmcDetected]]
| None
|-
| 0x08180000
|?
| [[FS:IsSdmcWritable|IsSdmcWritable]]
| None
|-
| 0x08190042
|?
| [[FS:GetSdmcCid|GetSdmcCid]]
| 0x2
|-
| 0x081A0042
|?
| [[FS:GetNandCid|GetNandCid]]
| 0x2
|-
| 0x081B0000
|?
| [[FS:GetSdmcSpeedInfo|GetSdmcSpeedInfo]]
| 0x2
|-
| 0x081C0000
|?
| [[FS:GetNandSpeedInfo|GetNandSpeedInfo]]
| 0x2
|-
| 0x081D0042
|?
| [[FS:GetSdmcLog|GetSdmcLog]]
| 0x2
|-
| 0x081E0042
|?
| [[FS:GetNandLog|GetNandLog]]
| 0x2
|-
| 0x081F0000
|?
| [[FS:ClearSdmcLog|ClearSdmcLog]]
| 0x2
|-
| 0x08200000
|?
| [[FS:ClearNandLog|ClearNandLog]]
| 0x2
|-
| 0x08210000
|?
| [[FS:CardSlotIsInserted|CardSlotIsInserted]]
| 0x1017
|-
| 0x08220000
|?
| [[FS:CardSlotPowerOn|CardSlotPowerOn]]
| 0x2
|-
| 0x08230000
|?
| [[FS:CardSlotPowerOff|CardSlotPowerOff]]
| 0x2
|-
| 0x08240000
|?
| [[FS:CardSlotGetCardIFPowerStatus|CardSlotGetCardIFPowerStatus]]
| 0x2
|-
| 0x08250040
|?
| [[FS:CardNorDirectCommand|CardNorDirectCommand]]
| 0x2
|-
| 0x08260080
|?
| [[FS:CardNorDirectCommandWithAddress|CardNorDirectCommandWithAddress]]
| 0x2
|-
| 0x08270082
|?
| [[FS:CardNorDirectRead|CardNorDirectRead]]
| 0x2
|-
| 0x082800C2
|?
| [[FS:CardNorDirectReadWithAddress|CardNorDirectReadWithAddress]]
| 0x2
|-
| 0x08290082
|?
| [[FS:CardNorDirectWrite|CardNorDirectWrite]]
| 0x2
|-
| 0x082A00C2
|?
| [[FS:CardNorDirectWriteWithAddress|CardNorDirectWriteWithAddress]]
| 0x2
|-
| 0x082B00C2
|?
| [[FS:CardNorDirectRead_4xIO|CardNorDirectRead_4xIO]]
| 0x2
|-
| 0x082C0082
|?
| [[FS:CardNorDirectCpuWriteWithoutVerify|CardNorDirectCpuWriteWithoutVerify]]
| 0x2
|-
| 0x082D0040
|?
| [[FS:CardNorDirectSectorEraseWithoutVerify|CardNorDirectSectorEraseWithoutVerify]]
| 0x2
|-
| 0x082E0040
|?
| [[FS:GetProductInfo|GetProductInfo]]
| 0x1005
|-
| 0x082F0040
|?
| [[FS:GetProgramLaunchInfo|GetProgramLaunchInfo]]
| 0x1005
|-
| 0x08300182
|?
| [[FS:Obsoleted_3_0_CreateExtSaveData|Obsoleted_3_0_CreateExtSaveData]]
| 0xC, for when the input extdataID doesn't match the exheader extdataID
|-
| 0x08310180
|?
| [[FS:Obsoleted_3_0_CreateSharedExtSaveData|Obsoleted_3_0_CreateSharedExtSaveData]]
| 0x1005
|-
| 0x08320102
|?
| [[FS:Obsoleted_3_0_ReadExtSaveDataIcon|Obsoleted_3_0_ReadExtSaveDataIcon]]
| 0x100D, for when the input extdataID doesn't match the exheader extdataID
|-
| 0x08330082
|?
| [[FS:Obsoleted_3_0_EnumerateExtSaveData|Obsoleted_3_0_EnumerateExtSaveData]]
| 0x1005
|-
| 0x08340082
|?
| [[FS:Obsoleted_3_0_EnumerateSharedExtSaveData|Obsoleted_3_0_EnumerateSharedExtSaveData]]
| 0x1005
|-
| 0x08350080
|?
| [[FS:Obsoleted_3_0_DeleteExtSaveData|Obsoleted_3_0_DeleteExtSaveData]]
| 0x100D, for when the input extdataID doesn't match the exheader extdataID
|-
| 0x08360080
|?
| [[FS:Obsoleted_3_0_DeleteSharedExtSaveData|Obsoleted_3_0_DeleteSharedExtSaveData]]
| 0x1005
|-
| 0x08370040
|?
| [[FS:SetCardSpiBaudRate|SetCardSpiBaudRate]]
| 0x2
|-
| 0x08380040
|?
| [[FS:SetCardSpiBusMode|SetCardSpiBusMode]]
| 0x2
|-
| 0x08390000
|?
| [[FS:SendInitializeInfoTo9|SendInitializeInfoTo9]]
| None
|-
| 0x083A0100
|?
| [[FS:GetSpecialContentIndex|GetSpecialContentIndex]]
| 0x1005
|-
| 0x083B00C2
|?
| [[FS:GetLegacyRomHeader|GetLegacyRomHeader]]
| 0x1015
|-
| 0x083C00C2
|?
| [[FS:GetLegacyBannerData|GetLegacyBannerData]]
| 0x1015
|-
| 0x083D0100
|?
| [[FS:CheckAuthorityToAccessExtSaveData|CheckAuthorityToAccessExtSaveData]]
| 0x44
|-
| 0x083E00C2
|?
| [[FS:QueryTotalQuotaSize|QueryTotalQuotaSize]]
| None
|-
| 0x083F00C0
|?
| [[FS:Obsoleted_3_0_GetExtDataBlockSize|Obsoleted_3_0_GetExtDataBlockSize]]
| None
|-
| 0x08400040
|?
| [[FS:AbnegateAccessRight|AbnegateAccessRight]]
|?
|-
| 0x08410000
|?
| [[FS:DeleteSdmcRoot|DeleteSdmcRoot]]
| 0x1005
|-
| 0x08420040
|?
| [[FS:DeleteAllExtSaveDataOnNand|DeleteAllExtSaveDataOnNand]]
| 0x1005
|-
| 0x08430000
|?
| [[FS:InitializeCtrFileSystem|InitializeCtrFileSystem]]
| None
|-
| 0x08440000
|?
| [[FS:CreateSeed|CreateSeed]]
| 0x2
|-
| 0x084500C2
|?
| [[FS:GetFormatInfo|GetFormatInfo]]
|?
|-
| 0x08460102
|?
| [[FS:GetLegacyRomHeader2|GetLegacyRomHeader2]]
| 0x1015
|-
| 0x08470180
|?
| [[FS:Obsoleted_2_0_FormatCtrCardUserSaveData|Obsoleted_2_0_FormatCtrCardUserSaveData]]
| 0x6
|-
| 0x08480042
|?
| [[FS:GetSdmcCtrRootPath|GetSdmcCtrRootPath]]
| 0x100D
|-
| 0x08490040
|?
| [[FS:GetArchiveResource|GetArchiveResource]]
|?
|-
| 0x084A0002
|?
| [[FS:ExportIntegrityVerificationSeed|ExportIntegrityVerificationSeed]]
| 0x4000
|-
| 0x084B0002
|?
| [[FS:ImportIntegrityVerificationSeed|ImportIntegrityVerificationSeed]]
| 0x4000
|-
| 0x084C0242
|?
| [[FS:FormatSaveData|FormatSaveData]]
| 0x6, in some cases this write isn't needed however
|-
| 0x084D0102
|?
| [[FS:GetLegacySubBannerData|GetLegacySubBannerData]]
| 0x1015
|-
| 0x084E0342
|?
| [[FS:UpdateSha256Context|UpdateSha256Context]]
| 0x5
|-
| 0x084F0102
|?
| [[FS:ReadSpecialFile|ReadSpecialFile]]
| None
|-
| 0x08500040
|?
| [[FS:GetSpecialFileSize|GetSpecialFileSize]]
| None
|-
| 0x08510242
| [[3.0.0-5]]
| [[FS:CreateExtSaveData|CreateExtSaveData]]
| Shared extdata: 0x101005. Regular extdata in certain cases: 0xC
|-
| 0x08520100
| [[3.0.0-5]]
| [[FS:DeleteExtSaveData|DeleteExtSaveData]]
| Shared extdata: 0x101005. Regular extdata in certain cases: 0x10100D
|-
| 0x08530142
| [[3.0.0-5]]
| [[FS:ReadExtSaveDataIcon|ReadExtSaveDataIcon]]
| 0x10100D (this doesn't apply in certain cases, however)
|-
| 0x085400C0
| [[3.0.0-5]]
| [[FS:GetExtDataBlockSize|GetExtDataBlockSize]]
| 0x10100D (this doesn't apply in certain cases, however)
|-
| 0x08550102
| [[3.0.0-5]]
| [[FS:EnumerateExtSaveData|EnumerateExtSaveData]]
| 0x101005
|-
| 0x08560240
| [[3.0.0-5]]
| [[FS:CreateSystemSaveData|CreateSystemSaveData]]
| 0x4 (this doesn't apply in certain cases, however)
|-
| 0x08570080
| [[3.0.0-5]]
| [[FS:DeleteSystemSaveData|DeleteSystemSaveData]]
| 0x1004 (this doesn't apply in certain cases, however)
|-
| 0x08580000
| [[3.0.0-5]]
| [[FS:StartDeviceMoveAsSource|StartDeviceMoveAsSource]]
| 0x2004
|-
| 0x08590200
| [[3.0.0-5]]
| [[FS:StartDeviceMoveAsDestination|StartDeviceMoveAsDestination]]
| 0x2004
|-
| 0x085A00C0
| [[3.0.0-5]]
| [[FS:SetArchivePriority|SetArchivePriority]]
| None
|-
| 0x085B0080
| [[3.0.0-5]]
| [[FS:GetArchivePriority|GetArchivePriority]]
| None
|-
| 0x085C00C0
| [[3.0.0-5]]
| [[FS:SetCtrCardLatencyParameter|SetCtrCardLatencyParameter]]
| 0xE
|-
| 0x085D01C0
| [[3.0.0-5]]
| [[FS:SetFsCompatibilityInfo|SetFsCompatibilityInfo]]
| 0x100001
|-
| 0x085E0040
| [[3.0.0-5]]
| [[FS:ResetCardCompatibilityParameter|ResetCardCompatibilityParameter]]
| 0xE
|-
| 0x085F0040
| [[3.0.0-5]]
| [[FS:SwitchCleanupInvalidSaveData|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]]
| [[FS:SetPriority|SetPriority]]
| None
|-
| 0x08630000
| [[3.0.0-5]]
| [[FS:GetPriority|GetPriority]]
| None
|-
| 0x08640000
| [[3.0.0-5]]
| [[FS:Obsoleted_4_0_GetNandInfo|Obsoleted_4_0_GetNandInfo]]
| Stubbed, this returns an error
|-
| 0x08650140
| [[4.0.0-7]]
| [[FS:SetSaveDataSecureValue|SetSaveDataSecureValue]]
| 0x121004 (in certain cases this doesn't apply, however)
|-
| 0x086600C0
| [[4.0.0-7]]
| [[FS:GetSaveDataSecureValue|GetSaveDataSecureValue]]
| 0x121004 (in certain cases this doesn't apply, however)
|-
| 0x086700C4
| [[4.0.0-7]]
| [[FS:ControlSecureSave|ControlSecureSave]]
| 0x121004
|-
| 0x08680000
| [[4.0.0-7]]
| [[FS:GetMediaType|GetMediaType]]
| None
|-
| 0x08690000
| [[4.0.0-7]]
| [[FS:Obsoleted_4_0_GetNandEraseCount|Obsoleted_4_0_GetNandEraseCount]]
| Stubbed, this returns an error.
|-
| 0x086A0082
| [[4.0.0-7]]
| [[FS:ReadNandReport|ReadNandReport]]
| None
|-
| 0x086B00C2
|?
|?
| 00121004
|-
| 0x086C00C2
|?
|?
| 00121004
|-
| 0x086D0040
|?
|?
| 00020004
|-
| 0x086E00C0
|Related to Secure Value? Used in Pokemon Sun/Moon.
|?
|None?
|-
| 0x086F0040
|Related to Secure Value? Used in Pokemon Sun/Moon.
|?
| 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
|-
| 0x087A0180
| [[9.6.0-24|9.6.0-X]]
| [[FS:AddSeed|AddSeed]]
| 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
|-
| 0x08840042
| [[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
|-
| 0x088600C0
| [[11.1.0-34|11.1.0-X]]
| [[FS:CheckUpdatedDat|CheckUpdatedDat]]
| 0x00080000
|}

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

== 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
| [[FSReg:Dummy1|Dummy1]]
|-
| 0x040103C0
| [[FSReg:Register|Register]]
|-
| 0x04020040
| [[FSReg:Unregister|Unregister]]
|-
| 0x040300C0
| [[FSReg:GetProgramInfo|GetProgramInfo]]
|-
| 0x04040100
| [[FSReg:LoadProgram|LoadProgram]]
|-
| 0x04050080
| [[FSReg:UnloadProgram|UnloadProgram]]
|-
| 0x04060080
| [[FSReg:CheckHostLoadId|CheckHostLoadId]]
|}

Only two sessions can be opened for this service at a time, hence no other processes can use this due to [[Process_Manager_Services|pm-module]] and [[Loader_Services|loader]] using this.

=File and directory access=
==Files==
File session handles obtained via [[FS:OpenFile]] et al can be used to access files through a service-like interface, despite not being an actual service registered using [[SRV:RegisterService]].

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

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

= Archives =
{| class="wikitable" border="1"
|-
! ArchiveId
! Description
! Accessible via [[Filesystem_services|FS]]
! Accessible via [[Filesystem_services_PXI|FSPXI]]
! Only accessible by Process9 internally
! Requires binary [[FS:OpenFile|Lowpath]]
! Required exheader FS access info bitmask
|-
| 0x00000003
| SelfNCCH (including [[#RomFS|RomFS]])
| Yes
| No
| No
| No
| None
|-
| 0x00000004
| SaveData (the saveID/mediatype for this is loaded from data originally from the user process' exheader)
| Yes
| No
| No
| No
| None
|-
| 0x00000006
| ExtSaveData
| Yes
| No
| No
| Yes
| 0x100D, when the input extdataID isn't listed in the exheader.
|-
| 0x00000007
| Shared ExtSaveData
| Yes
| No
| No
| Yes
| None
|-
| 0x00000008
| SystemSaveData
| Yes
| No
| No
| Yes
| 0x4, when the input saveID doesn't match the exheader system-saveID.
|-
| 0x00000009
| SDMC
| Yes
| Yes
| No
| No
| 0x8E
|-
| 0x0000000A
| SDMC Write-Only
| Yes
| No
| No
| No
| 0x808E
|-
| 0x12345678
| ExtSaveData for BOSS
| Yes
| No
| No
| Yes
| 0x44
|-
| 0x12345679
| CARD SPI FS
| Yes
| Yes
| No
| No
| 0x16
|-
| 0x1234567B
| ExtSaveData, and ExtSaveData for BOSS
| No
| Yes
| No
| Yes
|
|-
| 0x1234567C
| SystemSaveData
| No
| Yes
| No
| Yes
|
|-
| 0x1234567D
| NAND RW
| Yes
| Yes
| No
| No
| 0x800
|-
| 0x1234567E
| NAND RO
| Yes
| Yes
| No
| No
| 0x200
|-
| 0x1234567F
| NAND RO Write FS
| No
| Yes
| No
| No
| ?
|-
| 0x12345680
| Unknown. There's code for this in spider v9.9, but that code isn't actually used.
| Yes
| ?
| No
| Yes
| ?
|-
| 0x12345681
| Unknown. Accessed by FS service.
| ?
| ?
| No
| ?
| ?
|-
| 0x12345682
| Unknown. There's code for this in spider v9.9, but that code isn't actually used.
| Yes
| ?
| No
| Yes
| ?
|-
| 0x2345678A
| Used for accessing general NCCH data. With FSPXI this also allows savedata access.
| Yes
| Yes
| No
| Yes
| 0x1005
|-
| 0x2345678B
| ?
| No
| No
| Yes
| Yes
|
|-
| 0x2345678C
| Used internally to access [[Title_Database|/dbs]] files?
| No
| No
| Yes
| Yes
|
|-
| 0x2345678D
| ?
| No
| No
| Yes
| No
|
|-
| 0x2345678E
| FSPXI: Similar to archive 0x2345678A. For fs:LDR(used by the "loader" FIRM ARM11-process), only ExeFS. Not accessible with fs:USER.
| Yes
| Yes
| No
| Yes
| None, see description.
|-
| 0x567890AB
| NAND CTR FS
| No
| Yes
| No
| No
| ?
|-
| 0x567890AC
| TWL PHOTO
| Yes
| Yes
| No
| No
| ?
|-
| 0x567890AD
| TWLS (DSi Sound stores recordings here). This is mapped to the FAT12 image stored in the file at [[Twln/shared2/0000]].
| No
| Yes
| No
| No
| ?
|-
| 0x567890AE
| NAND TWL FS
| Yes
| Yes
| No
| No
| 0x100
|-
| 0x567890AF
| NAND W FS
| Yes
| Yes
| No
| No
| 0x100
|-
| 0x567890B0
| ?
| No
| Yes
| No
| No
|
|-
| 0x567890B1
| Gamecard SaveData (for check). This is a wrapper for UserSaveDataForCheck: the OpenArchive code for that is called with archive-lowpath TID=0/mediatype=2(gamecard).
| Yes
| No
| No
| No
| 0x6
|-
| 0x567890B2
| UserSaveData (for check). This is the same as the regular SaveData archive, except with this the savedata ID and mediatype is loaded from the input archive lowpath.
| Yes
| No
| No
| Yes
| 0x6
|-
| 0x567890B4
| Similar to 0x567890B2 but can only access Accessible Save specified in [[NCCH/Extended_Header#Storage_Info|exheader]]?
| Yes
| No
| No
| Yes
| ?
|}

Archives listed as not requiring a binary lowpath, use lowpath type [[FS:OpenFile|empty]].

The above permission bitmasks are from v2.x, see the above Services section for how these are handled.

Archives CTR NAND, NAND RO Write FS, TWL NAND, NAND W FS, and CARD SPI FS require the corresponding process exheader access control mount flag to be set, in the exheader for any of the currently running ARM11 processes, for [[Filesystem_services_PXI|FSPXI]]. The access rights checked by [[Filesystem services|FS]] module for archive mounting with fs:USER, are stored in the process' exheader accessinfo.

The CARDSPI archive allows access to the gamecard CARD1 raw savedata flash(aka "cardspi:/" in [[FIRM|Process9]]), the file lowpath must be WCHAR "/". The "NAND W FS" archive allows access to the raw NAND image(aka "wnand:/" in Process9), the file lowpath must be WCHAR "/".

= Filenames and Paths =
PathType:
{| class="wikitable" border="1"
|-
! Value
! Description
|-
| -1
| Returned internally by Process9, when errors occur it seems(in particular when no nul-terminator was found in the input path). The data ptr is set to NULL.
|-
| 0x0
| INVALID - Specifies an invalid path
|-
| 0x1
| EMPTY - Specifies an empty path
|-
| 0x2
| BINARY - Non-text based path. Meaning is per-archive
|-
| 0x3
| ASCII - Text-based path with 7-bit ASCII characters padded to 8-bits each (signed char)
|-
| 0x4
| UTF16 - Text-based path with UTF-16 characters
|}

In IPC requests, sizes of ASCII and UTF16 paths must include space for the null-terminator.

== Binary LowPath ==
The format of the data that a binary LowPath points to is custom per archive.

=== SelfNCCH File Path Data Format ===
{| class="wikitable" border="1"
|-
! Index word
! Description
|-
| 0
| Type:
* 0x0: RomFS
* 0x1: error 0xD9004676
* 0x2: ExeFS
* 0x3: Error 0xE0E046BE.
* 0x4: FS-module crashes on this
* 0x5: Update RomFS?
|-
| 1-2
| File name for ExeFS ("icon"/"banner"/"logo"). ".code" is not allowed
|}

Note that ExeFS files only support reading from offset=0 and with size=file_size.

=== SystemSaveData Archive Path Data Format ===
==== FS ====
{| class="wikitable" border="1"
|-
! Index word
! Description
|-
| 0
| [[Mediatypes|Mediatype]] (must be zero for NAND)
|-
| 1
| saveid
|}
The file/directory lowpath is a text lowpath in the [[Savegames|savegame]] filesystem.

==== FSPXI ====
{| class="wikitable" border="1"
|-
! Index word
! Description
|-
| 0
| u8 [[Mediatypes|Mediatype]] (must be zero for NAND)
|}
The file lowpath is a binary lowpath containing the u64 saveid, however the high word of the saveid is always zero. The mounted file is the cleartext savegame image. Up to 32 SystemSaveData image files can be opened under a single mounted FSPXI archive.

=== UserSaveDataForCheck Archive Path Data Format ===
{| class="wikitable" border="1"
|-
! Index word
! Description
|-
| 0
| [[Mediatypes|Mediatype]] (must be non-zero)
|-
| 1
| Lower word saveid
|-
| 2
| Upper word saveid
|}
The file/directory lowpath for this FS archive is a text path in the [[Savegames|savegame]] filesystem.

=== 0x567890B4 Archive Path Data Format ===
{| class="wikitable" border="1"
|-
! Index word
! Description
|-
| 0
| [[Mediatypes|Mediatype]]
|-
| 1
| <code><nowiki>Lower_word_saveid >> 8</nowiki></code> ?
|-
| 2
| Unknown. Game calculate this using formula <code><nowiki>(unknown_a & 0xFFFFFF00) | unknown_b</nowiki></code>
|}

=== ExtSaveData Archive Path Data Format ===
{| class="wikitable" border="1"
|-
! Index word
! Description
|-
| 0
| [[Mediatypes|Mediatype]]
|-
| 1
| Lower word saveid
|-
| 2
| Upper word saveid
|}
For FS, the file/directory lowpath is a text path in the [[extdata]] filesystem. For FSPXI, the file lowpath is a text path relative to the "/extdata/<ExtdataIDHigh>/<ExtdataIDLow>" directory on SD/NAND, for the cleartext extdata image to mount.

=== 0x2345678A Archive Path Data Format ===
{| class="wikitable" border="1"
|-
! Index word
! Description
|-
| 0
| Lower word programID
|-
| 1
| Upper word programID
|-
| 2
| ([[Mediatypes|Mediatype]] & 0xFF) | (uninitialized_data? & 0xFFFFFF00)
|-
| 3
| [[Title_metadata#Content_chunk_records|Content Index]] << 1 | (1=romfs, 0=exefs)
|}

File lowpath:
{| class="wikitable" border="1"
|-
! Index word
! Description
|-
| 0
| 0 for NCCH data, 1 for savedata. The latter is only valid for FSPXI. Value 2 is allowed via archive 0x3, it's unknown what this is.
|-
| 1
| TMD content index / NCSD partition index.
|-
| 2
| Type: 0=romfs(0 for non-NCCH as well), 1=exefs ".code"(?), 2=exefs "icon"/"banner"/"logo", 3=unknown, 4=unknown, 5=unknown.
|-
| 3-4
| Filename for ExeFS.
|}

The 0x14-byte lowpath is all-zero for accessing the title's main RomFS.

=== [[RomFS]] ===

Archives 0x3 and 0x2345678E both allow for accessing the [[RomFS#Level_3_Format|level-3 IVFC images]] for RomFS access. The main CXI RomFS is accessible via an all-zero 0xc-byte binary file-lowpath. The update RomFS can be accessed with the first u32 in the binary file-lowpath being set to 0x5. The user must handle parsing the filesystem used in the exposed image itself.

With FSPXI the returned data for RomFS is the entire RomFS section from the NCCH, starting at the IVFC header.

The 0x3 archive is an interface for the 0x2345678E archive with the current process programID+mediatype. The file lowpath is 3-words. These words are written to 0x2345678E-archive file_lowpath+0, with the rest of that lowpath set to all-zero(lowpath is different from archive 0x2345678A). File lowpath:
{| class="wikitable" border="1"
|-
! Index word
! Description
|-
| 0
| See above. The only values which FS-module doesn't allow to be used here are:
* 0x1: Error 0xE0E046BE.
* 0x3: Error 0xE0E046BE.
* 0x4: FS-module executes svcBreak when using this.
|-
| 1-2
| See above. Not validated by FS-module.
|}

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

= Common Types =
== MediaType ==
{| class="wikitable" border="1"
|-
! Value
! Description
|-
| 0
| NAND
|-
| 1
| SD
|-
| 2
| Game Card
|}

== SystemMediaType ==
{| class="wikitable" border="1"
|-
! Value
! Description
|-
| 0
| CTR NAND
|-
| 1
| TWL NAND
|-
| 2
| SD
|-
| 2
| TWL Photo
|}

== OpenFlags ==
{| class="wikitable" border="1"
|-
! Bit
! Description
|-
| 0
| Read
|-
| 1
| Write
|-
| 2
| Create
|}

== Attributes ==
{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
|-
| 0x0
| 0x1
| Is Directory
|-
| 0x1
| 0x1
| Is Hidden
|-
| 0x2
| 0x1
| Is Archive
|-
| 0x3
| 0x1
| Is Read-Only
|}

== WriteOption ==
{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
|-
| 0x0
| 0x1
| Flush
|-
| 0x1
| 0x1
| Update Time Stamp
|-
| 0x2
| 0x1
| Reserved
|-
| 0x3
| 0x1
| Reserved
|}

== DirectoryEntry ==
{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
|-
| 0x0
| 0x20C
| UTF-16 Entry Name
|-
| 0x20C
| 0xA
| 8.3 short filename name
|-
| 0x216
| 0x4
| 8.3 short filename extension
|-
| 0x21A
| 0x1
| Always 1
|-
| 0x21B
| 0x1
| Reserved
|-
| 0x21C
| 0x4
| [[Filesystem_services#Attributes|Attributes]]
|-
| 0x220
| 0x8
| Entry Size
|}

== ArchiveResource ==
{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
|-
| 0x0
| 0x4
| Sector byte-size
|-
| 0x4
| 0x4
| Cluster byte-size
|-
| 0x8
| 0x4
| Partition capacity in clusters
|-
| 0xC
| 0x4
| Available free space in clusters
|}

== ProgramInfo ==
{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
|-
| 0x0
| 0x8
| Program ID
|-
| 0x8
| 0x1
| [[Filesystem_services#MediaType|Media Type]]
|-
| 0x9
| 0x7
| Padding
|}

== ProductInfo ==
{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
|-
| 0x0
| 0x10
| Product Code
|-
| 0x10
| 0x2
| Company Code
|-
| 0x12
| 0x2
| Remaster Version
|}

== IntegrityVerificationSeed ==
{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
|-
| 0x0
| 0x10
| AES-CBC MAC over a SHA256 hash, which hashes the first 0x110-bytes of the cleartext SEED.
|-
| 0x10
| 0x120
| The [[nand/private/movable.sed]], encrypted with AES-CTR using the above MAC for the counter.
|}

== ExtSaveDataInfo ==
{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
|-
| 0x0
| 0x1
| [[Filesystem_services#MediaType|Media Type]]
|-
| 0x1
| 0x1
| Unknown
|-
| 0x2
| 0x2
| Reserved
|-
| 0x4
| 0x8
| Save ID
|-
| 0xC
| 0x4
| Reserved
|}

== SystemSaveDataInfo ==
{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
|-
| 0x0
| 0x1
| [[Filesystem_services#MediaType|Media Type]]
|-
| 0x1
| 0x1
| Unknown
|-
| 0x2
| 0x2
| Reserved
|-
| 0x4
| 0x4
| Save ID
|}

== SecureValueSlot ==
{| class="wikitable" border="1"
|-
! Value
! Description
|-
| 0x1000
| SD Application
|}

== CardSpiBaudRate ==
{| class="wikitable" border="1"
|-
! Value
! Description
|-
| 0x0
| 512KHz
|-
| 0x1
| 1MHz
|-
| 0x2
| 2MHz
|-
| 0x3
| 4MHz
|-
| 0x4
| 8MHz
|-
| 0x5
| 16MHz
|}

== CardSpiBusMode ==
{| class="wikitable" border="1"
|-
! Value
! Description
|-
| 0x0
| 1-bit
|-
| 0x1
| 4-bit
|}

== SpecialContentType ==
{| class="wikitable" border="1"
|-
! Value
! Description
|-
| 0x1
| Update
|-
| 0x2
| Manual
|-
| 0x3
| DLP Child
|}

== DeviceMoveContext ==
{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
|-
| 0x0
| 0x10
| IVs
|-
| 0x10
| 0x10
| Encrypt Parameter
|}

=Errors=
See [[Filesystem_services_PXI]].

Application Manager Services

2017-09-25T02:54:04Z

Shinyquagsire23: /* ContentInfo */

[[Category:Services]]

= Application Manager services "am:sys", "am:u", "am:net" =
{| class="wikitable" border="1"
|-
! Command Header
! Description
|-
| 0x00010040
| [[AM:GetNumPrograms|GetNumPrograms]]
|-
| 0x00020082
| [[AM:GetProgramList|GetProgramList]]
|-
| 0x00030084
| [[AM:GetProgramInfos|GetProgramInfos]]
|-
| 0x000400C0
| [[AM:DeleteUserProgram|DeleteUserProgram]]
|-
| 0x000500C0
| [[AM:GetProductCode|GetProductCode]]
|-
| 0x000600C0
| [[AM:GetStorageId|GetStorageId]]
|-
| 0x00070080
| [[AM:DeleteTicket|DeleteTicket]]
|-
| 0x00080000
| [[AM:GetNumTickets|GetNumTickets]]
|-
| 0x00090082
| [[AM:GetTicketList|GetTicketList]]
|-
| 0x000A0000
| [[AM:GetDeviceId|GetDeviceId]]
|-
| 0x000B0040
| [[AM:GetNumImportTitleContexts|GetNumImportTitleContexts]]
|-
| 0x000C0082
| [[AM:GetImportTitleContextList|GetImportTitleContextList]]
|-
| 0x000D0084
| [[AM:GetImportTitleContexts|GetImportTitleContexts]]
|-
| 0x000E00C0
| [[AM:DeleteImportTitleContext|DeleteImportTitleContext]]
|-
| 0x000F00C0
| [[AM:GetNumImportContentContexts|GetNumImportContentContexts]]
|-
| 0x00100102
| [[AM:GetImportContentContextList|GetImportContentContextList]]
|-
| 0x00110104
| [[AM:GetImportContentContexts|GetImportContentContexts]]
|-
| 0x00120102
| [[AM:DeleteImportContentContexts|DeleteImportContentContexts]]
|-
| 0x00130040
| [[AM:NeedsCleanup|NeedsCleanup]]
|-
| 0x00140040
| [[AM:DoCleanup|DoCleanup]]
|-
| 0x00150040
| [[AM:DeleteAllImportContexts|DeleteAllImportContexts]]
|-
| 0x00160000
| [[AM:DeleteAllTemporaryPrograms|DeleteAllTemporaryPrograms]]
|-
| 0x00170044
| [[AM:ImportTwlBackupLegacy|ImportTwlBackupLegacy]]
|-
| 0x00180080
| [[AM:InitializeTitleDatabase|InitializeTitleDatabase]]
|-
| 0x00190040
| [[AM:QueryAvailableTitleDatabase|QueryAvailableTitleDatabase]]
|-
| 0x001A00C0
| [[AM:CalcTwlBackupSize|CalcTwlBackupSize]]
|-
| 0x001B0144
| [[AM:ExportTwlBackup|ExportTwlBackup]]
|-
| 0x001C0084
| [[AM:ImportTwlBackup|ImportTwlBackup]]
|-
| 0x001D0000
| [[AM:DeleteAllTwlUserPrograms|DeleteAllTwlUserPrograms]]
|-
| 0x001E00C8
| [[AM:ReadTwlBackupInfo|ReadTwlBackupInfo]]
|-
| 0x001F0040
| [[AM:DeleteAllExpiredUserPrograms|DeleteAllExpiredUserPrograms]]
|-
| 0x00200000
| [[AM:GetTwlArchiveResourceInfo|GetTwlArchiveResourceInfo]]
|-
| 0x00210042
| [[AM:GetPersonalizedTicketInfoList|GetPersonalizedTicketInfoList]]
|-
| 0x00220080
| [[AM:DeleteAllImportContextsFiltered|DeleteAllImportContextsFiltered]]
|-
| 0x00230080
| [[AM:GetNumImportTitleContextsFiltered|GetNumImportTitleContextsFiltered]]
|-
| 0x002400C2
| [[AM:GetImportTitleContextListFiltered|GetImportTitleContextListFiltered]]
|-
| 0x002500C0
| [[AM:CheckContentRights|CheckContentRights]]
|-
| 0x00260044
| [[AM:GetTicketLimitInfos|GetTicketLimitInfos]]
|-
| 0x00270044
| [[AM:GetDemoLaunchInfos|GetDemoLaunchInfos]]
|-
| 0x00280108
| [[AM:ReadTwlBackupInfoEx|ReadTwlBackupInfoEx]]
|-
| 0x00290082
| [[AM:DeleteUserProgramsAtomically|DeleteUserProgramsAtomically]]
|-
| 0x002A00C0
| [[AM:GetNumExistingContentInfosSystem|GetNumExistingContentInfosSystem]]
|-
| 0x002B0142
| [[AM:ListExistingContentInfosSystem|ListExistingContentInfosSystem]]
|-
| 0x002C0084
| [[AM:GetProgramInfosIgnorePlatform|GetProgramInfosIgnorePlatform]]
|-
| 0x002D00C0
| [[AM:CheckContentRightsIgnorePlatform|CheckContentRightsIgnorePlatform]]
|}

= Application Manager services "am:u" and "am:net" =
{| class="wikitable" border="1"
|-
! Command Header
! Description
|-
| 0x04010080
| [[AM:UpdateFirmwareTo|UpdateFirmwareTo]]
|-
| 0x04020040
| [[AM:BeginImportProgram|BeginImportProgram]]
|-
| 0x04030000
| [[AM:BeginImportProgramTemporarily|BeginImportProgramTemporarily]]
|-
| 0x04040002
| [[AM:CancelImportProgram|CancelImportProgram]]
|-
| 0x04050002
| [[AM:EndImportProgram|EndImportProgram]]
|-
| 0x04060002
| [[AM:EndImportProgramWithoutCommit|EndImportProgramWithoutCommit]]
|-
| 0x040700C2
| [[AM:CommitImportPrograms|CommitImportPrograms]]
|-
| 0x04080042
| [[AM:GetProgramInfoFromCia|GetProgramInfoFromCia]]
|-
| 0x04090004
| [[AM:GetSystemMenuDataFromCia|GetSystemMenuDataFromCia]]
|-
| 0x040A0002
| [[AM:GetDependencyListFromCia|GetDependencyListFromCia]]
|-
| 0x040B0002
| [[AM:GetTransferSizeFromCia|GetTransferSizeFromCia]]
|-
| 0x040C0002
| [[AM:GetCoreVersionFromCia|GetCoreVersionFromCia]]
|-
| 0x040D0042
| [[AM:GetRequiredSizeFromCia|GetRequiredSizeFromCia]]
|-
| 0x040E00C2
| [[AM:CommitImportProgramsAndUpdateFirmwareAuto|CommitImportProgramsAndUpdateFirmwareAuto]]
|-
| 0x040F0000
| [[AM:UpdateFirmwareAuto|UpdateFirmwareAuto]]
|-
| 0x041000C0
| [[AM:DeleteProgram|DeleteProgram]]
|-
| 0x04110044
| [[AM:GetTwlProgramListForReboot|GetTwlProgramListForReboot]]
|-
| 0x04120000
| [[AM:GetSystemUpdaterMutex|GetSystemUpdaterMutex]]
|-
| 0x04130002
| [[AM:GetMetaSizeFromCia|GetMetaSizeFromCia]]
|-
| 0x04140044
| [[AM:GetMetaDataFromCia|GetMetaDataFromCia]]
|-
| 0x04150080
| [[AM:CheckDemoLaunchRights|CheckDemoLaunchRights]]
|-
| 0x041600C0
| [[AM:GetInternalTitleLocationInfo|GetInternalTitleLocationInfo]]
|-
| 0x041700C0
| [[AM:PerpetuateAgbSaveData|PerpetuateAgbSaveData]]
|-
| 0x04180040
| [[AM:BeginImportProgramForOverWrite|BeginImportProgramForOverWrite]]
|-
| 0x04190000
| [[AM:BeginImportSystemProgram|BeginImportSystemProgram]]
|}

= Application Manager service "am:app" =
{| class="wikitable" border="1"
|-
! Command Header
! Description
|-
| 0x100100C0
| [[AM:GetNumContentInfos|GetNumContentInfos]]
|-
| 0x10020104
| [[AM:FindContentInfos|FindContentInfos]]
|-
| 0x10030142
| [[AM:ListContentInfos|ListContentInfos]]
|-
| 0x10040102
| [[AM:DeleteContents|DeleteContents]]
|-
| 0x10050084
| [[AM:GetDataTitleInfos|GetDataTitleInfos]]
|-
| 0x10060080
| [[AM:GetNumDataTitleTickets|GetNumDataTitleTickets]]
|-
| 0x10070102
| [[AM:ListDataTitleTicketInfos|ListDataTitleTicketInfos]]
|-
| 0x100801C2
| [[AM:GetItemRights|GetItemRights]]
|-
| 0x100900C0
| [[AM:IsDataTitleInUse|IsDataTitleInUse]]
|-
| 0x100A0000
| [[AM:IsExternalTitleDatabaseInitialized|IsExternalTitleDatabaseInitialized]]
|-
| 0x100B00C0
| [[AM:GetNumExistingContentInfos|GetNumExistingContentInfos]]
|-
| 0x100C0142
| [[AM:ListExistingContentInfos|ListExistingContentInfos]]
|-
| 0x100D0084
| [[AM:GetPatchTitleInfos|GetPatchTitleInfos]]
|}

The only commands accessible with this service are listed under this section.

= Application Manager service "am:sys" =
This service only has access to the 0x00XX* commands listed above, and the "am:app" commands.

= Application Manager service "am:u" =

= Application Manager network service "am:net" =
{| class="wikitable" border="1"
|-
! Command Header
! Description
|-
| 0x08010000
| [[AMNet:BeginImportTicket|BeginImportTicket]]
|-
| 0x08020002
| [[AMNet:CancelImportTicket|CancelImportTicket]]
|-
| 0x08030002
| [[AMNet:EndImportTicket|EndImportTicket]]
|-
| 0x08040100
| [[AMNet:BeginImportTitle|BeginImportTitle]]
|-
| 0x08050000
| [[AMNet:StopImportTitle|StopImportTitle]]
|-
| 0x080600C0
| [[AMNet:ResumeImportTitle|ResumeImportTitle]]
|-
| 0x08070000
| [[AMNet:CancelImportTitle|CancelImportTitle]]
|-
| 0x08080000
| [[AMNet:EndImportTitle|EndImportTitle]]
|-
| 0x080900C2
| [[AMNet:CommitImportTitles|CommitImportTitles]]
|-
| 0x080A0000
| [[AMNet:BeginImportTmd|BeginImportTmd]]
|-
| 0x080B0002
| [[AMNet:CancelImportTmd|CancelImportTmd]]
|-
| 0x080C0042
| [[AMNet:EndImportTmd|EndImportTmd]]
|-
| 0x080D0042
| [[AMNet:CreateImportContentContexts|CreateImportContentContexts]]
|-
| 0x080E0040
| [[AMNet:BeginImportContent|BeginImportContent]]
|-
| 0x080F0002
| [[AMNet:StopImportContent|StopImportContent]]
|-
| 0x08100040
| [[AMNet:ResumeImportContent|ResumeImportContent]]
|-
| 0x08110002
| [[AMNet:CancelImportContent|CancelImportContent]]
|-
| 0x08120002
| [[AMNet:EndImportContent|EndImportContent]]
|-
| 0x08130000
| [[AMNet:GetNumCurrentImportContentContexts|GetNumCurrentImportContentContexts]]
|-
| 0x08140042
| [[AMNet:GetCurrentImportContentContextList|GetCurrentImportContentContextList]]
|-
| 0x08150044
| [[AMNet:GetCurrentImportContentContexts|GetCurrentImportContentContexts]]
|-
| 0x08160146
| [[AMNet:Sign|Sign]]
|-
| 0x08170146
| [[AMNet:Verify|Verify]]
|-
| 0x08180042
| [[AMNet:GetDeviceCert|GetDeviceCert]]
|-
| 0x08190108
| [[AMNet:ImportCertificates|ImportCertificates]]
|-
| 0x081A0042
| [[AMNet:ImportCertificate|ImportCertificate]]
|-
| 0x081B00C2
| [[AMNet:CommitImportTitlesAndUpdateFirmwareAuto|CommitImportTitlesAndUpdateFirmwareAuto]]
|-
| 0x081C0100
| [[AMNet:DeleteTicketId|DeleteTicketId]]
|-
| 0x081D0080
| [[AMNet:GetNumTicketIds|GetNumTicketIds]]
|-
| 0x081E0102
| [[AMNet:GetTicketIdList|GetTicketIdList]]
|-
| 0x081F0080
| [[AMNet:GetNumTicketsOfProgram|GetNumTicketsOfProgram]]
|-
| 0x08200102
| [[AMNet:ListTicketInfos|ListTicketInfos]]
|-
| 0x08210142
| [[AMNet:GetRightsOnlyTicketData|GetRightsOnlyTicketData]]
|-
| 0x08220000
| [[AMNet:GetNumCurrentContentInfos|GetNumCurrentContentInfos]]
|-
| 0x08230044
| [[AMNet:FindCurrentContentInfos|FindCurrentContentInfos]]
|-
| 0x08240082
| [[AMNet:ListCurrentContentInfos|ListCurrentContentInfos]]
|-
| 0x08250102
| [[AMNet:CalculateContextRequiredSize|CalculateContextRequiredSize]]
|-
| 0x08260042
| [[AMNet:UpdateImportContentContexts|UpdateImportContentContexts]]
|-
| 0x08270000
| [[AMNet:DeleteAllDemoLaunchInfos|DeleteAllDemoLaunchInfos]]
|-
| 0x082800C0
| [[AMNet:BeginImportTitleForOverWrite|BeginImportTitleForOverWrite]]
|}

= File service =
{| class="wikitable" border="1"
|-
! Command Header
! Available since system-version
! Description
|-
| 0x0001....
|
| Stubbed. After validating the translate-paramater headers, this just returns error 0xE0C046F8.
|-
| 0x0401....
|
| ?
|-
| 0x08010100
|
| ?
|-
| 0x080200C2
|
| [[AMFile:Read|Read]]
|-
| 0x08030102
|
| [[AMFile:Write|Write]]
|-
| 0x08040000
|
| [[AMFile:GetSize|GetSize]]
|-
| 0x08050080
|
| [[AMFile:SetSize|SetSize]]
|-
| 0x08060000
|
| ?
|-
| 0x08070000
|
| ?
|-
| 0x08080000
|
| [[AMFile:Close|Close]]
|-
| 0x08090000
|
| ?
|-
| 0x080A0000
|
| This just returns 0.
|-
| 0x080B0000
|
| This just returns 0.
|-
| 0x080C0000
|
| This just returns 0.
|}

This is similar to [[Filesystem_services#File_service|FSFile]].

For handling each command that's actually implemented, the AM cmdhandler function calls a vtable funcptr.

The private port for this seems to be referred to as "am:pipe", even though the "am:pipe" string isn't actually used.

=Types=
==TicketInfo==
{| class="wikitable" border="1"
|-
! Offset
! Length
! Description
|-
| 0x0
| 0x8
| Title ID
|-
| 0x8
| 0x8
| Ticket ID
|-
| 0x10
| 0x2
| Version
|-
| 0x12
| 0x2
| Padding
|-
| 0x14
| 0x4
| Size
|}

==TitleInfo==
{| class="wikitable" border="1"
|-
! Offset
! Length
! Description
|-
| 0x0
| 0x8
| Title ID
|-
| 0x8
| 0x8
| Size
|-
| 0x10
| 0x2
| Version
|-
| 0x12
| 0x2
| Padding
|-
| 0x14
| 0x4
| Type
|}

==ContentInfo==
{| class="wikitable" border="1"
|-
! Offset
! Length
! Description
|-
| 0x0
| 0x2
| Index
|-
| 0x2
| 0x2
| Type
|-
| 0x4
| 0x4
| Content ID
|-
| 0x8
| 0x8
| Size
|-
| 0x10
| 0x8
| RomFS Size
|}

==ImportTitleContext==
{| class="wikitable" border="1"
|-
! Offset
! Length
! Description
|-
| 0x0
| 0x8
| Title ID
|-
| 0x8
| 0x2
| Version
|-
| 0xA
| 0x2
| State
|-
| 0xC
| 0x4
| Type
|-
| 0x10
| 0x8
| Size
|}

===ImportTitleContextState===
{| class="wikitable" border="1"
|-
! Value
! Description
|-
| 0
| None
|-
| 1
| Waiting for import
|-
| 2
| Resumable
|-
| 3
| Waiting for commit
|-
| 4
| Already exists
|-
| 5
| Deleting
|-
| 6
| Needs cleanup
|}

==ImportContentContext==
{| class="wikitable" border="1"
|-
! Offset
! Length
! Description
|-
| 0x0
| 0x4
| Content ID
|-
| 0x4
| 0x2
| Index
|-
| 0x6
| 0x2
| Type
|-
| 0x8
| 0x8
| Size
|-
| 0x10
| 0x8
| Current Install Offset
|}

=Errors=
See [[Application_Manager_Services_PXI|this]].

Filesystem services

2016-11-23T07:17:25Z

Shinyquagsire23: Found references in GameSys::GameData::RepairCTRSecureValue

[[Category:Services]]

= 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
|?
| [[FS:Dummy1|Dummy1]]
| None
|-
| 0x040100C4
|?
| [[FS:Control|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
|?
| [[FS:ControlArchive|ControlArchive]]
| None
|-
| 0x080E0080
|?
| [[FS:CloseArchive|CloseArchive]]
| None
|-
| 0x080F0180
|?
| [[FS:Obsoleted_2_0_FormatThisUserSaveData|Obsoleted_2_0_FormatThisUserSaveData]]
| None
|-
| 0x08100200
|?
| [[FS:Obsoleted_3_0_CreateSystemSaveData|Obsoleted_3_0_CreateSystemSaveData]]
| 0x4, for when the input saveID doesn't match the exheader saveID
|-
| 0x08110040
|?
| [[FS:Obsoleted_3_0_DeleteSystemSaveData|Obsoleted_3_0_DeleteSystemSaveData]]
| 0x1004, for when the input saveID doesn't match the exheader saveID
|-
| 0x08120080
|?
| [[FS:GetFreeBytes|GetFreeBytes]]
| None
|-
| 0x08130000
|?
| [[FS:GetCardType|GetCardType]]
| 0x1017
|-
| 0x08140000
|?
| [[FS:GetSdmcArchiveResource|GetSdmcArchiveResource]]
| None
|-
| 0x08150000
|?
| [[FS:GetNandArchiveResource|GetNandArchiveResource]]
| 0x1007
|-
| 0x08160000
|?
| [[FS:GetSdmcFatfsError|GetSdmcFatfsError]]
| 0x2
|-
| 0x08170000
|?
| [[FS:IsSdmcDetected|IsSdmcDetected]]
| None
|-
| 0x08180000
|?
| [[FS:IsSdmcWritable|IsSdmcWritable]]
| None
|-
| 0x08190042
|?
| [[FS:GetSdmcCid|GetSdmcCid]]
| 0x2
|-
| 0x081A0042
|?
| [[FS:GetNandCid|GetNandCid]]
| 0x2
|-
| 0x081B0000
|?
| [[FS:GetSdmcSpeedInfo|GetSdmcSpeedInfo]]
| 0x2
|-
| 0x081C0000
|?
| [[FS:GetNandSpeedInfo|GetNandSpeedInfo]]
| 0x2
|-
| 0x081D0042
|?
| [[FS:GetSdmcLog|GetSdmcLog]]
| 0x2
|-
| 0x081E0042
|?
| [[FS:GetNandLog|GetNandLog]]
| 0x2
|-
| 0x081F0000
|?
| [[FS:ClearSdmcLog|ClearSdmcLog]]
| 0x2
|-
| 0x08200000
|?
| [[FS:ClearNandLog|ClearNandLog]]
| 0x2
|-
| 0x08210000
|?
| [[FS:CardSlotIsInserted|CardSlotIsInserted]]
| 0x1017
|-
| 0x08220000
|?
| [[FS:CardSlotPowerOn|CardSlotPowerOn]]
| 0x2
|-
| 0x08230000
|?
| [[FS:CardSlotPowerOff|CardSlotPowerOff]]
| 0x2
|-
| 0x08240000
|?
| [[FS:CardSlotGetCardIFPowerStatus|CardSlotGetCardIFPowerStatus]]
| 0x2
|-
| 0x08250040
|?
| [[FS:CardNorDirectCommand|CardNorDirectCommand]]
| 0x2
|-
| 0x08260080
|?
| [[FS:CardNorDirectCommandWithAddress|CardNorDirectCommandWithAddress]]
| 0x2
|-
| 0x08270082
|?
| [[FS:CardNorDirectRead|CardNorDirectRead]]
| 0x2
|-
| 0x082800C2
|?
| [[FS:CardNorDirectReadWithAddress|CardNorDirectReadWithAddress]]
| 0x2
|-
| 0x08290082
|?
| [[FS:CardNorDirectWrite|CardNorDirectWrite]]
| 0x2
|-
| 0x082A00C2
|?
| [[FS:CardNorDirectWriteWithAddress|CardNorDirectWriteWithAddress]]
| 0x2
|-
| 0x082B00C2
|?
| [[FS:CardNorDirectRead_4xIO|CardNorDirectRead_4xIO]]
| 0x2
|-
| 0x082C0082
|?
| [[FS:CardNorDirectCpuWriteWithoutVerify|CardNorDirectCpuWriteWithoutVerify]]
| 0x2
|-
| 0x082D0040
|?
| [[FS:CardNorDirectSectorEraseWithoutVerify|CardNorDirectSectorEraseWithoutVerify]]
| 0x2
|-
| 0x082E0040
|?
| [[FS:GetProductInfo|GetProductInfo]]
| 0x1005
|-
| 0x082F0040
|?
| [[FS:GetProgramLaunchInfo|GetProgramLaunchInfo]]
| 0x1005
|-
| 0x08300182
|?
| [[FS:Obsoleted_3_0_CreateExtSaveData|Obsoleted_3_0_CreateExtSaveData]]
| 0xC, for when the input extdataID doesn't match the exheader extdataID
|-
| 0x08310180
|?
| [[FS:Obsoleted_3_0_CreateSharedExtSaveData|Obsoleted_3_0_CreateSharedExtSaveData]]
| 0x1005
|-
| 0x08320102
|?
| [[FS:Obsoleted_3_0_ReadExtSaveDataIcon|Obsoleted_3_0_ReadExtSaveDataIcon]]
| 0x100D, for when the input extdataID doesn't match the exheader extdataID
|-
| 0x08330082
|?
| [[FS:Obsoleted_3_0_EnumerateExtSaveData|Obsoleted_3_0_EnumerateExtSaveData]]
| 0x1005
|-
| 0x08340082
|?
| [[FS:Obsoleted_3_0_EnumerateSharedExtSaveData|Obsoleted_3_0_EnumerateSharedExtSaveData]]
| 0x1005
|-
| 0x08350080
|?
| [[FS:Obsoleted_3_0_DeleteExtSaveData|Obsoleted_3_0_DeleteExtSaveData]]
| 0x100D, for when the input extdataID doesn't match the exheader extdataID
|-
| 0x08360080
|?
| [[FS:Obsoleted_3_0_DeleteSharedExtSaveData|Obsoleted_3_0_DeleteSharedExtSaveData]]
| 0x1005
|-
| 0x08370040
|?
| [[FS:SetCardSpiBaudRate|SetCardSpiBaudRate]]
| 0x2
|-
| 0x08380040
|?
| [[FS:SetCardSpiBusMode|SetCardSpiBusMode]]
| 0x2
|-
| 0x08390000
|?
| [[FS:SendInitializeInfoTo9|SendInitializeInfoTo9]]
| None
|-
| 0x083A0100
|?
| [[FS:GetSpecialContentIndex|GetSpecialContentIndex]]
| 0x1005
|-
| 0x083B00C2
|?
| [[FS:GetLegacyRomHeader|GetLegacyRomHeader]]
| 0x1015
|-
| 0x083C00C2
|?
| [[FS:GetLegacyBannerData|GetLegacyBannerData]]
| 0x1015
|-
| 0x083D0100
|?
| [[FS:CheckAuthorityToAccessExtSaveData|CheckAuthorityToAccessExtSaveData]]
| 0x44
|-
| 0x083E00C2
|?
| [[FS:QueryTotalQuotaSize|QueryTotalQuotaSize]]
| None
|-
| 0x083F00C0
|?
| [[FS:Obsoleted_3_0_GetExtDataBlockSize|Obsoleted_3_0_GetExtDataBlockSize]]
| None
|-
| 0x08400040
|?
| [[FS:AbnegateAccessRight|AbnegateAccessRight]]
|?
|-
| 0x08410000
|?
| [[FS:DeleteSdmcRoot|DeleteSdmcRoot]]
| 0x1005
|-
| 0x08420040
|?
| [[FS:DeleteAllExtSaveDataOnNand|DeleteAllExtSaveDataOnNand]]
| 0x1005
|-
| 0x08430000
|?
| [[FS:InitializeCtrFileSystem|InitializeCtrFileSystem]]
| None
|-
| 0x08440000
|?
| [[FS:CreateSeed|CreateSeed]]
| 0x2
|-
| 0x084500C2
|?
| [[FS:GetFormatInfo|GetFormatInfo]]
|?
|-
| 0x08460102
|?
| [[FS:GetLegacyRomHeader2|GetLegacyRomHeader2]]
| 0x1015
|-
| 0x08470180
|?
| [[FS:Obsoleted_2_0_FormatCtrCardUserSaveData|Obsoleted_2_0_FormatCtrCardUserSaveData]]
| 0x6
|-
| 0x08480042
|?
| [[FS:GetSdmcCtrRootPath|GetSdmcCtrRootPath]]
| 0x100D
|-
| 0x08490040
|?
| [[FS:GetArchiveResource|GetArchiveResource]]
|?
|-
| 0x084A0002
|?
| [[FS:ExportIntegrityVerificationSeed|ExportIntegrityVerificationSeed]]
| 0x4000
|-
| 0x084B0002
|?
| [[FS:ImportIntegrityVerificationSeed|ImportIntegrityVerificationSeed]]
| 0x4000
|-
| 0x084C0242
|?
| [[FS:FormatSaveData|FormatSaveData]]
| 0x6, in some cases this write isn't needed however
|-
| 0x084D0102
|?
| [[FS:GetLegacySubBannerData|GetLegacySubBannerData]]
| 0x1015
|-
| 0x084E0342
|?
| [[FS:UpdateSha256Context|UpdateSha256Context]]
| 0x5
|-
| 0x084F0102
|?
| [[FS:ReadSpecialFile|ReadSpecialFile]]
| None
|-
| 0x08500040
|?
| [[FS:GetSpecialFileSize|GetSpecialFileSize]]
| None
|-
| 0x08510242
| [[3.0.0-5]]
| [[FS:CreateExtSaveData|CreateExtSaveData]]
| Shared extdata: 0x101005. Regular extdata in certain cases: 0xC
|-
| 0x08520100
| [[3.0.0-5]]
| [[FS:DeleteExtSaveData|DeleteExtSaveData]]
| Shared extdata: 0x101005. Regular extdata in certain cases: 0x10100D
|-
| 0x08530142
| [[3.0.0-5]]
| [[FS:ReadExtSaveDataIcon|ReadExtSaveDataIcon]]
| 0x10100D (this doesn't apply in certain cases, however)
|-
| 0x085400C0
| [[3.0.0-5]]
| [[FS:GetExtDataBlockSize|GetExtDataBlockSize]]
| 0x10100D (this doesn't apply in certain cases, however)
|-
| 0x08550102
| [[3.0.0-5]]
| [[FS:EnumerateExtSaveData|EnumerateExtSaveData]]
| 0x101005
|-
| 0x08560240
| [[3.0.0-5]]
| [[FS:CreateSystemSaveData|CreateSystemSaveData]]
| 0x4 (this doesn't apply in certain cases, however)
|-
| 0x08570080
| [[3.0.0-5]]
| [[FS:DeleteSystemSaveData|DeleteSystemSaveData]]
| 0x1004 (this doesn't apply in certain cases, however)
|-
| 0x08580000
| [[3.0.0-5]]
| [[FS:StartDeviceMoveAsSource|StartDeviceMoveAsSource]]
| 0x2004
|-
| 0x08590200
| [[3.0.0-5]]
| [[FS:StartDeviceMoveAsDestination|StartDeviceMoveAsDestination]]
| 0x2004
|-
| 0x085A00C0
| [[3.0.0-5]]
| [[FS:SetArchivePriority|SetArchivePriority]]
| None
|-
| 0x085B0080
| [[3.0.0-5]]
| [[FS:GetArchivePriority|GetArchivePriority]]
| None
|-
| 0x085C00C0
| [[3.0.0-5]]
| [[FS:SetCtrCardLatencyParameter|SetCtrCardLatencyParameter]]
| 0xE
|-
| 0x085D01C0
| [[3.0.0-5]]
| [[FS:SetFsCompatibilityInfo|SetFsCompatibilityInfo]]
| 0x100001
|-
| 0x085E0040
| [[3.0.0-5]]
| [[FS:ResetCardCompatibilityParameter|ResetCardCompatibilityParameter]]
| 0xE
|-
| 0x085F0040
| [[3.0.0-5]]
| [[FS:SwitchCleanupInvalidSaveData|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]]
| [[FS:SetPriority|SetPriority]]
| None
|-
| 0x08630000
| [[3.0.0-5]]
| [[FS:GetPriority|GetPriority]]
| None
|-
| 0x08640000
| [[3.0.0-5]]
| [[FS:Obsoleted_4_0_GetNandInfo|Obsoleted_4_0_GetNandInfo]]
| Stubbed, this returns an error
|-
| 0x08650140
| [[4.0.0-7]]
| [[FS:SetSaveDataSecureValue|SetSaveDataSecureValue]]
| 0x121004 (in certain cases this doesn't apply, however)
|-
| 0x086600C0
| [[4.0.0-7]]
| [[FS:GetSaveDataSecureValue|GetSaveDataSecureValue]]
| 0x121004 (in certain cases this doesn't apply, however)
|-
| 0x086700C4
| [[4.0.0-7]]
| [[FS:ControlSecureSave|ControlSecureSave]]
| 0x121004
|-
| 0x08680000
| [[4.0.0-7]]
| [[FS:GetMediaType|GetMediaType]]
| None
|-
| 0x08690000
| [[4.0.0-7]]
| [[FS:Obsoleted_4_0_GetNandEraseCount|Obsoleted_4_0_GetNandEraseCount]]
| Stubbed, this returns an error.
|-
| 0x086A0082
| [[4.0.0-7]]
| [[FS:ReadNandReport|ReadNandReport]]
| None
|-
| 0x086B00C2
|?
|?
| 00121004
|-
| 0x086C00C2
|?
|?
| 00121004
|-
| 0x086D0040
|?
|?
| 00020004
|-
| 0x086E00C0
|Related to Secure Value? Used in Pokemon Sun/Moon.
|?
|None?
|-
| 0x086F0040
|Related to Secure Value? Used in Pokemon Sun/Moon.
|?
| 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
|-
| 0x087A0180
| [[9.6.0-24|9.6.0-X]]
| [[FS:AddSeed|AddSeed]]
| 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
|-
| 0x08840042
| [[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
|-
| 0x088600C0
| [[11.1.0-34|11.1.0-X]]
| [[FS:CheckUpdatedDat|CheckUpdatedDat]]
| 0x00080000
|}

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

== 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
| [[FSReg:Dummy1|Dummy1]]
|-
| 0x040103C0
| [[FSReg:Register|Register]]
|-
| 0x04020040
| [[FSReg:Unregister|Unregister]]
|-
| 0x040300C0
| [[FSReg:GetProgramInfo|GetProgramInfo]]
|-
| 0x04040100
| [[FSReg:LoadProgram|LoadProgram]]
|-
| 0x04050080
| [[FSReg:UnloadProgram|UnloadProgram]]
|-
| 0x04060080
| [[FSReg:CheckHostLoadId|CheckHostLoadId]]
|}

Only two sessions can be opened for this service at a time, hence no other processes can use this due to [[Process_Manager_Services|pm-module]] and [[Loader_Services|loader]] using this.

=File and directory access=
==Files==
File session handles obtained via [[FS:OpenFile]] et al can be used to access files through a service-like interface, despite not being an actual service registered using [[SRV:RegisterService]].

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

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

= Archives =
{| class="wikitable" border="1"
|-
! ArchiveId
! Description
! Accessible via [[Filesystem_services|FS]]
! Accessible via [[Filesystem_services_PXI|FSPXI]]
! Only accessible by Process9 internally
! Requires binary [[FS:OpenFile|Lowpath]]
! Required exheader FS access info bitmask
|-
| 0x00000003
| Application [[#RomFS|RomFS]]
| Yes
| No
| No
| No
| None
|-
| 0x00000004
| SaveData (the saveID/mediatype for this is loaded from data originally from the user process' exheader)
| Yes
| No
| No
| No
| None
|-
| 0x00000006
| ExtSaveData
| Yes
| No
| No
| Yes
| 0x100D, when the input extdataID isn't listed in the exheader.
|-
| 0x00000007
| Shared ExtSaveData
| Yes
| No
| No
| Yes
| None
|-
| 0x00000008
| SystemSaveData
| Yes
| No
| No
| Yes
| 0x4, when the input saveID doesn't match the exheader system-saveID.
|-
| 0x00000009
| SDMC
| Yes
| Yes
| No
| No
| 0x8E
|-
| 0x0000000A
| SDMC Write-Only
| Yes
| No
| No
| No
| 0x808E
|-
| 0x12345678
| ExtSaveData for BOSS
| Yes
| No
| No
| Yes
| 0x44
|-
| 0x12345679
| CARD SPI FS
| Yes
| Yes
| No
| No
| 0x16
|-
| 0x1234567B
| ExtSaveData, and ExtSaveData for BOSS
| No
| Yes
| No
| Yes
|
|-
| 0x1234567C
| SystemSaveData
| No
| Yes
| No
| Yes
|
|-
| 0x1234567D
| NAND RW
| Yes
| Yes
| No
| No
| 0x800
|-
| 0x1234567E
| NAND RO
| Yes
| Yes
| No
| No
| 0x200
|-
| 0x1234567F
| NAND RO Write FS
| No
| Yes
| No
| No
| ?
|-
| 0x12345680
| Unknown. There's code for this in spider v9.9, but that code isn't actually used.
| Yes
| ?
| No
| Yes
| ?
|-
| 0x12345681
| Unknown. Accessed by FS service.
| ?
| ?
| No
| ?
| ?
|-
| 0x12345682
| Unknown. There's code for this in spider v9.9, but that code isn't actually used.
| Yes
| ?
| No
| Yes
| ?
|-
| 0x2345678A
| Used for accessing general NCCH data. With FSPXI this also allows savedata access.
| Yes
| Yes
| No
| Yes
| 0x1005
|-
| 0x2345678B
| ?
| No
| No
| Yes
| Yes
|
|-
| 0x2345678C
| Used internally to access [[Title_Database|/dbs]] files?
| No
| No
| Yes
| Yes
|
|-
| 0x2345678D
| ?
| No
| No
| Yes
| No
|
|-
| 0x2345678E
| FSPXI: Similar to archive 0x2345678A. For fs:LDR(used by the "loader" FIRM ARM11-process), only ExeFS. Not accessible with fs:USER.
| Yes
| Yes
| No
| Yes
| None, see description.
|-
| 0x567890AB
| NAND CTR FS
| No
| Yes
| No
| No
| ?
|-
| 0x567890AC
| TWL PHOTO
| Yes
| Yes
| No
| No
| ?
|-
| 0x567890AD
| TWLS (DSi Sound stores recordings here). This is mapped to the FAT12 image stored in the file at [[Twln/shared2/0000]].
| No
| Yes
| No
| No
| ?
|-
| 0x567890AE
| NAND TWL FS
| Yes
| Yes
| No
| No
| 0x100
|-
| 0x567890AF
| NAND W FS
| Yes
| Yes
| No
| No
| 0x100
|-
| 0x567890B0
| ?
| No
| Yes
| No
| No
|
|-
| 0x567890B1
| Gamecard SaveData (for check). This is a wrapper for UserSaveDataForCheck: the OpenArchive code for that is called with archive-lowpath TID=0/mediatype=2(gamecard).
| Yes
| No
| No
| No
| 0x6
|-
| 0x567890B2
| UserSaveData (for check). This is the same as the regular SaveData archive, except with this the savedata ID and mediatype is loaded from the input archive lowpath.
| Yes
| No
| No
| Yes
| 0x6
|-
| 0x567890B4
| Similar to 0x567890B2 but can only access Accessible Save specified in [[NCCH/Extended_Header#Storage_Info|exheader]]?
| Yes
| No
| No
| Yes
| ?
|}

Archives listed as not requiring a binary lowpath, use lowpath type [[FS:OpenFile|empty]].

The above permission bitmasks are from v2.x, see the above Services section for how these are handled.

Archives CTR NAND, NAND RO Write FS, TWL NAND, NAND W FS, and CARD SPI FS require the corresponding process exheader access control mount flag to be set, in the exheader for any of the currently running ARM11 processes, for [[Filesystem_services_PXI|FSPXI]]. The access rights checked by [[Filesystem services|FS]] module for archive mounting with fs:USER, are stored in the process' exheader accessinfo.

The CARDSPI archive allows access to the gamecard CARD1 raw savedata flash(aka "cardspi:/" in [[FIRM|Process9]]), the file lowpath must be WCHAR "/". The "NAND W FS" archive allows access to the raw NAND image(aka "wnand:/" in Process9), the file lowpath must be WCHAR "/".

= Filenames and Paths =
PathType:
{| class="wikitable" border="1"
|-
! Value
! Description
|-
| -1
| Returned internally by Process9, when errors occur it seems(in particular when no nul-terminator was found in the input path). The data ptr is set to NULL.
|-
| 0x0
| INVALID - Specifies an invalid path
|-
| 0x1
| EMPTY - Specifies an empty path
|-
| 0x2
| BINARY - Non-text based path. Meaning is per-archive
|-
| 0x3
| ASCII - Text-based path with 7-bit ASCII characters padded to 8-bits each (signed char)
|-
| 0x4
| UTF16 - Text-based path with UTF-16 characters
|}

In IPC requests, sizes of ASCII and UTF16 paths must include space for the null-terminator.

== Binary LowPath ==
The format of the data that a binary LowPath points to is custom per archive.

=== SystemSaveData Archive Path Data Format ===
==== FS ====
{| class="wikitable" border="1"
|-
! Index word
! Description
|-
| 0
| [[Mediatypes|Mediatype]] (must be zero for NAND)
|-
| 1
| saveid
|}
The file/directory lowpath is a text lowpath in the [[Savegames|savegame]] filesystem.

==== FSPXI ====
{| class="wikitable" border="1"
|-
! Index word
! Description
|-
| 0
| u8 [[Mediatypes|Mediatype]] (must be zero for NAND)
|}
The file lowpath is a binary lowpath containing the u64 saveid, however the high word of the saveid is always zero. The mounted file is the cleartext savegame image. Up to 32 SystemSaveData image files can be opened under a single mounted FSPXI archive.

=== UserSaveDataForCheck Archive Path Data Format ===
{| class="wikitable" border="1"
|-
! Index word
! Description
|-
| 0
| [[Mediatypes|Mediatype]] (must be non-zero)
|-
| 1
| Lower word saveid
|-
| 2
| Upper word saveid
|}
The file/directory lowpath for this FS archive is a text path in the [[Savegames|savegame]] filesystem.

=== 0x567890B4 Archive Path Data Format ===
{| class="wikitable" border="1"
|-
! Index word
! Description
|-
| 0
| [[Mediatypes|Mediatype]]
|-
| 1
| Lower word saveid
|-
| 2
| Unknown. Game calculate this using formula <code><nowiki>(unknown_a & 0xFFFFFF00) | unknown_b</nowiki></code>
|}

=== ExtSaveData Archive Path Data Format ===
{| class="wikitable" border="1"
|-
! Index word
! Description
|-
| 0
| [[Mediatypes|Mediatype]]
|-
| 1
| Lower word saveid
|-
| 2
| Upper word saveid
|}
For FS, the file/directory lowpath is a text path in the [[extdata]] filesystem. For FSPXI, the file lowpath is a text path relative to the "/extdata/<ExtdataIDHigh>/<ExtdataIDLow>" directory on SD/NAND, for the cleartext extdata image to mount.

=== 0x2345678A Archive Path Data Format ===
{| class="wikitable" border="1"
|-
! Index word
! Description
|-
| 0
| Lower word programID
|-
| 1
| Upper word programID
|-
| 2
| [[Mediatypes|Mediatype]]
|-
| 3
| Reserved
|}

File lowpath:
{| class="wikitable" border="1"
|-
! Index word
! Description
|-
| 0
| 0 for NCCH data, 1 for savedata. The latter is only valid for FSPXI. Value 2 is allowed via archive 0x3, it's unknown what this is.
|-
| 1
| TMD content index / NCSD partition index.
|-
| 2
| Type: 0=romfs(0 for non-NCCH as well), 1=exefs ".code"(?), 2=exefs "icon"/"banner"/"logo", 3=unknown, 4=unknown, 5=unknown.
|-
| 3-4
| Filename for ExeFS.
|}

The 0x14-byte lowpath is all-zero for accessing the title's main RomFS.

=== [[RomFS]] ===

Archives 0x3 and 0x2345678E both allow for accessing the [[RomFS#Level_3_Format|level-3 IVFC images]] for RomFS access. The main CXI RomFS is accessible via an all-zero 0xc-byte binary file-lowpath. The update RomFS can be accessed with the first u32 in the binary file-lowpath being set to 0x5. The user must handle parsing the filesystem used in the exposed image itself.

The 0x3 archive is an interface for the 0x2345678E archive with the current process programID+mediatype. The file lowpath is 3-words. These words are written to 0x2345678E-archive file_lowpath+0, with the rest of that lowpath set to all-zero(lowpath is different from archive 0x2345678A). File lowpath:
{| class="wikitable" border="1"
|-
! Index word
! Description
|-
| 0
| See above. The only values which FS-module doesn't allow to be used here are:
* 0x1: Error 0xE0E046BE.
* 0x3: Error 0xE0E046BE.
* 0x4: FS-module executes svcBreak when using this.
|-
| 1-2
| See above. Not validated by FS-module.
|}

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

= Common Types =
== MediaType ==
{| class="wikitable" border="1"
|-
! Value
! Description
|-
| 0
| NAND
|-
| 1
| SD
|-
| 2
| Game Card
|}

== SystemMediaType ==
{| class="wikitable" border="1"
|-
! Value
! Description
|-
| 0
| CTR NAND
|-
| 1
| TWL NAND
|-
| 2
| SD
|-
| 2
| TWL Photo
|}

== OpenFlags ==
{| class="wikitable" border="1"
|-
! Bit
! Description
|-
| 0
| Read
|-
| 1
| Write
|-
| 2
| Create
|}

== Attributes ==
{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
|-
| 0x0
| 0x1
| Is Directory
|-
| 0x1
| 0x1
| Is Hidden
|-
| 0x2
| 0x1
| Is Archive
|-
| 0x3
| 0x1
| Is Read-Only
|}

== WriteOption ==
{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
|-
| 0x0
| 0x1
| Flush
|-
| 0x1
| 0x1
| Update Time Stamp
|-
| 0x2
| 0x1
| Reserved
|-
| 0x3
| 0x1
| Reserved
|}

== DirectoryEntry ==
{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
|-
| 0x0
| 0x20C
| UTF-16 Entry Name
|-
| 0x20C
| 0xA
| 8.3 short filename name
|-
| 0x216
| 0x4
| 8.3 short filename extension
|-
| 0x21A
| 0x1
| Always 1
|-
| 0x21B
| 0x1
| Reserved
|-
| 0x21C
| 0x4
| [[Filesystem_services#Attributes|Attributes]]
|-
| 0x220
| 0x8
| Entry Size
|}

== ArchiveResource ==
{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
|-
| 0x0
| 0x4
| Sector byte-size
|-
| 0x4
| 0x4
| Cluster byte-size
|-
| 0x8
| 0x4
| Partition capacity in clusters
|-
| 0xC
| 0x4
| Available free space in clusters
|}

== ProgramInfo ==
{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
|-
| 0x0
| 0x8
| Program ID
|-
| 0x8
| 0x1
| [[Filesystem_services#MediaType|Media Type]]
|-
| 0x9
| 0x7
| Padding
|}

== ProductInfo ==
{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
|-
| 0x0
| 0x10
| Product Code
|-
| 0x10
| 0x2
| Company Code
|-
| 0x12
| 0x2
| Remaster Version
|}

== IntegrityVerificationSeed ==
{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
|-
| 0x0
| 0x10
| AES-CBC MAC over a SHA256 hash, which hashes the first 0x110-bytes of the cleartext SEED.
|-
| 0x10
| 0x120
| The [[nand/private/movable.sed]], encrypted with AES-CTR using the above MAC for the counter.
|}

== ExtSaveDataInfo ==
{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
|-
| 0x0
| 0x1
| [[Filesystem_services#MediaType|Media Type]]
|-
| 0x1
| 0x1
| Unknown
|-
| 0x2
| 0x2
| Reserved
|-
| 0x4
| 0x8
| Save ID
|-
| 0xC
| 0x4
| Reserved
|}

== SystemSaveDataInfo ==
{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
|-
| 0x0
| 0x1
| [[Filesystem_services#MediaType|Media Type]]
|-
| 0x1
| 0x1
| Unknown
|-
| 0x2
| 0x2
| Reserved
|-
| 0x4
| 0x4
| Save ID
|}

== SecureValueSlot ==
{| class="wikitable" border="1"
|-
! Value
! Description
|-
| 0x1000
| SD Application
|}

== CardSpiBaudRate ==
{| class="wikitable" border="1"
|-
! Value
! Description
|-
| 0x0
| 512KHz
|-
| 0x1
| 1MHz
|-
| 0x2
| 2MHz
|-
| 0x3
| 4MHz
|-
| 0x4
| 8MHz
|-
| 0x5
| 16MHz
|}

== CardSpiBusMode ==
{| class="wikitable" border="1"
|-
! Value
! Description
|-
| 0x0
| 1-bit
|-
| 0x1
| 4-bit
|}

== SpecialContentType ==
{| class="wikitable" border="1"
|-
! Value
! Description
|-
| 0x1
| Update
|-
| 0x2
| Manual
|-
| 0x3
| DLP Child
|}

== DeviceMoveContext ==
{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
|-
| 0x0
| 0x10
| IVs
|-
| 0x10
| 0x10
| Encrypt Parameter
|}

=Errors=
See [[Filesystem_services_PXI]].

Homebrew Exploits

2016-10-08T22:29:14Z

Shinyquagsire23: (v*)hax can rest in peace

==Payload==
{| class="wikitable" border="1"
|-
! Works on latest fw
! Name
! Description
! Supported firmwares
|-
| style="background: lightgreen" | Yes
| [https://smealum.github.io/3ds/ *hax payload]
| Booted by all of the below non-sysmodule exploits.
| From '''9.0.0-7''' up to and including '''11.1.0-34'''.
|}

For the rest of this page, "Supported firmwares" refers to the exploit ''itself'', not whether *hax payload supports it.

==Standalone Homebrew Launcher Exploits==
The following homebrew exploits can be executed on a previously un-exploited system. ''Please'' see the above Payload section regarding what "Supported firmwares" indicates ''exactly''.

{| class="wikitable" border="1"
|-
! Works on latest fw
! Name
! Supported firmwares
! Requirements
! Author
! Install
|-
| style="background: salmon" | No
| [[ninjhax|Ninjhax 1.1b]]
| From '''4.0.0-7''' up to and including '''9.2.0-20'''.
| A cartridge or eShop version (JPN-only) of "Cubic Ninja".
| smea
| [http://smealum.net/ninjhax/ Install]
|-
| style="background: lightgreen" | Yes
| [[ninjhax|Ninjhax 2.x]]
| From '''9.0.0-7''' up to and including '''11.1.0-34'''.
| A cartridge or eShop version (JPN-only, not available anymore for purchase) of "Cubic Ninja".
| smea
| [https://smealum.github.io/ninjhax2/ Install]
|-
| style="background: lightgreen" | Yes
| [http://plutooo.github.io/freakyhax/ freakyhax]
| From '''9.0.0-7''' up to and including '''11.1.0-34'''.
| A cartridge or eShop version (USA/EUR/JAP, not available anymore for purchase) of "Freakyform Deluxe".
| plutoo
| [http://plutooo.github.io/freakyhax/ Install]
|-
| style="background: salmon" | No
| [http://plutooo.github.io/smilehax/ smilehax]
| From '''9.0.0-7''' up to and including '''11.0.0-33'''
| SmileBASIC (JPN all versions up to 3.32 excluded, USA 3.31 only)
| plutoo
| [http://plutooo.github.io/smilehax/ Install]
|-
| style="background: salmon" | No
| [http://mrnbayoh.github.io/basicsploit/ BASICSploit]
| From '''9.0.0-7''' up to and including '''11.0.0-33'''
| SmileBASIC (USA all versions)
| MrNbaYoh
| [http://mrnbayoh.github.io/basicsploit/ Install]
|-
| style="background: lightgreen" | Yes
| [[smashbroshax|smashbroshax]] (beaconhax)
| (New 3DS only) From '''9.0.0-X''' up to and including '''11.1.0-34'''.
| Super Smash Bros 3DS (full-game) and a way to broadcast raw wifi beacons. The demo (prior to the updated November 2015 [https://github.com/yellows8/3ds_smashbroshax version]) isn't usable with the *hax payloads. Game-version v1.1.3 fixed the vuln used with this, see the repo for a workaround for that.
| [[User:Yellows8|Yellows8]]
| [https://github.com/yellows8/3ds_smashbroshax Install]
|-
| style="background: salmon" | No
| [[browserhax]]
| From '''9.0.0-2''' to '''11.0.0-33'''
Note that the browser-version-check bypass is only usable prior to [[10.7.0-32]].
| A USA, EUR, JPN, or KOR system.
| [[User:Yellows8|Yellows8]]
| [http://yls8.mtheall.com/3dsbrowserhax.php Install]
|}

Note that ninjhax 1.x is still not obsolete. Even though ninjhax 2.x can be run on 9.3+, this was made possible (amongst other things) by sacrificing the memory remapping exploit used in ninjhax 1.x (rohax). Therefore, things like JIT engines for emulators can only be supported on ninjhax 1.x. Furthermore, ninjhax 2.x does not run on system versions below 9.0.0-X, while ninjhax 1.x does.

==Secondary Exploits==
Installation of these exploits requires a previously exploited system to install. After installation, they can be used on their own. ''Please'' see the above Payload section regarding what "Supported firmwares" indicates ''exactly''.

{| class="wikitable" border="1"
! Works on latest fw
! Name
! Supported firmwares
! Requirements
! Author
! Install
|-
| style="background: salmon" | No
| [[ironhax]]
| From '''9.5.0-X''' up to and including '''10.3.0-X''', for '''X''' up to and including 28.
| A copy of "Ironfall: Invasion" downloaded from eShop before August 11th, 2015. Note the updated version that was released on October 13th, 2015 is not supported.
| smea
| [http://smealum.github.io/3ds/ Install]
|-
| style="background: lightgreen" | Yes
| [http://vegaroxas.github.io/ steelhax]
| From '''9.0.0-X''' up to and including '''11.1.0-X''', for '''X''' up to and including 34.
| A copy of Steel Diver: Sub wars
| Vegaroxas
| [https://github.com/VegaRoXas/vegaroxas.github.io/raw/master/files/steelhax-installer.zip Install]
|-
| style="background: lightgreen" | Yes
| [https://github.com/yellows8/oot3dhax oot3dhax]
| From '''9.0.0-X''' up to and including '''11.1.0-X''', for '''X''' up to and including 34.
| A gamecard or eShop-install of Legend of Zelda: Ocarina of Time 3D. Besides using the installer app, writing raw saveimages with a save dongle for example is another option. Before compression was introduced in the 2016-7-18 release, the size of the *hax payload meant the exploit can't coexist with regular saves on a physical version of the game.
| Yellows8 / smea et al.
| See [https://smealum.github.io/3ds/ here].
|-
| style="background: salmon" | No
| [[menuhax]]
| JPN/USA/EUR: From '''9.0.0-X''' up to and including '''11.0.0-X'''.
KOR: From '''9.6.0-X''' up to and including '''11.0.0-X'''.
| JPN/USA/EUR: Having created [[Home_Menu#Home_Menu_Theme_SD_ExtData|theme extdata]] through opening the official theme selector at least once.
| [[User:Yellows8|Yellows8]]
| [https://github.com/yellows8/3ds_homemenuhax/releases Download]
|-
| style="background: lightgreen" | Yes
| [https://github.com/shinyquagsire23/supermysterychunkhax supermysterychunkhax]
| From '''9.9.0-X''' (USA/JPN) / '''10.2.0-X''' (EUR) up to and including '''11.1.0-X''', for '''X''' up to and including 34.
| A gamecard or eShop-install of Pokémon Super Mystery Dungeon.
| Shiny Quagsire / SALT team
| [https://smd.salthax.org/ Install].
|-
| style="background: salmon" | No
| [https://github.com/shinyquagsire23/v_hax (v*)hax]
| From '''9.0.0-X''' up to and including '''11.0.0-X''', for '''X''' up to and including 33.
Note that '''9.0.0-X''' is only required for the Homebrew Launcher - the game itself only requires '''2.1.0-X''' for primitive userland code execution.
| A copy of VVVVVV downloaded after March 2012 (v1). v1.1 patches out the overflow vulnerability used by (v*)hax.
| Shiny Quagsire / SALT team
| [https://vvvvvv.salthax.org/ Install].
|-
| style="background: salmon" | No, exploit update required.
| [https://github.com/Dazzozo/humblehax humblehax]
| From '''9.0.0-X''' (USA/EUR) up to and including '''11.0.0-X''', for '''X''' up to and including 33.
| An eShop-install of Citizens of Earth (either v1 or v2), featured in the Humble "Friends of Nintendo" Bundle.
| Dazzozo / SALT team
| [https://citizens.salthax.org/ Install].
|-
| style="background: lightgreen" | Yes
| [http://mrnbayoh.github.io/basehaxx/ basehaxx]
| From '''9.0.0-X''' up to and including '''11.1.0-X''', for '''X''' up to and including 34.
| A gamecard or eShop-install of Pokémon Omega Ruby / Alpha Sapphire.
| MrNbaYoh
| [http://mrnbayoh.github.io/basehaxx/ install]
|-
| style="background: lightgreen" | Yes
| [https://github.com/yellows8/stickerhax stickerhax]
| From '''9.0.0-X''' up to and including '''11.1.0-X'''.
| A gamecard or eShop-install of Paper Mario: Sticker Star.
| [[User:Yellows8|Yellows8]]
| [https://github.com/yellows8/stickerhax Here]
|}

==Exploits without Homebrew Launcher (Not recommended)==

'''Warning:''' The following exploits can run code, but are missing a 3DSX launcher. They cannot launch any homebrew in the 3DSX format.

{| class="wikitable" border="1"
|-
! Works on latest fw
! Name
! Supported firmwares
! Requirements
! Author
! Install
|-
| style="background: salmon" | No
| [[browserhax]] (Without the loader in the 3ds_browserhax_common repo)
| (Old3DS) From '''5.0.0-2''' to '''11.0.0-33''' (Pre-v5.0 is supported for some versions if you manually modify the source)

(New3DS) From '''9.0.0-20''' to '''11.0.0-33'''

Note that the browser-version-check bypass is only usable prior to [[10.7.0-32]].
| An USA, EUR, or JPN system.
| [[User:Yellows8|Yellows8]]
| [[browserhax|Install]]
|-
| style="background: salmon" | No
| Ninjhax (with specialized payloads)
| Up to '''9.2.0-20'''?
|
| smea + independent developers
| N/A
|}

==Previous Exploits==
'''Warning:''' These exploits '''do not work'''. They are exploits which no longer function at all, regardless of software or firmware revision.
{| class="wikitable" border="1"
! Works on latest fw
! Name
! Supported firmwares
! Requirements
! Author
! Install
|-
| style="background: salmon" | No
| [[tubehax|Tubehax]]
| None. '''Was''': From '''9.0.0-X''' up to and including '''10.1.0-X''', for '''X''' up to and including 27.
| The YouTube application and an Internet connection. As of October 15, 2015, this is no longer usable due to an update being released which fixes the vuln used by tubehax + app update being forced (see [[YouTube|here]]).
| smea
| [http://smealum.github.io/3ds/ Install]
|}

==Other Homebrew Loaders==
The [https://github.com/yellows8/hblauncher_loader hblauncher_loader] title can be used when running under modded-FIRM which allows running unsigned titles, to boot the *hax payloads.

==Sysmodule Exploits==
This section is for system-module exploits, which can be run from the *hax payloads.

{| class="wikitable" border="1"
! Works on latest fw
! Name
! Supported firmwares
! Requirements
! Author
|-
| style="background: lightgreen" | Yes, that's not the intended default use however.
| [https://github.com/yellows8/ctr-httpwn/releases ctr-httpwn]
| From '''9.6.0-X''' up to and including '''11.1.0-X'''.
| None
| [[User:Yellows8|Yellows8]]
|}

==WebKit vuln testing==
See [https://github.com/yellows8/3ds_browserhax_common/issues/28 here].

3DS System Flaws

2016-09-28T02:41:39Z

Shinyquagsire23: The description still sucked. Lots of ambiguity with arm9loaderhax, OTP hash is relevant only to enhanced-arm9loaderhax and rearranging useless w/o the original arm9loaderhax flaw.

Exploits are used to execute unofficial code (homebrew) on the Nintendo 3DS. This page is a list of publicly known system flaws, for userland applications/applets flaws see [[3DS_Userland_Flaws|here]].

=Stale / Rejected Efforts=
* Neimod has been working on a RAM dumping setup for a little while now. He's de-soldered the 3DS's RAM chip and hooked it and the RAM pinouts on the 3DS' PCB up to a custom RAM dumping setup. A while ago he published photos showing his setup to be working quite well, with the 3DS successfully booting up. However, his flickr stream is now private along with most of his work.

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

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

SD card [[extdata]] and SD savegames can be attacked, for consoles where the console-unique [[Nand/private/movable.sed|movable.sed]] was dumped(accessing SD data is far easier by running code on the target 3DS however).

=System flaws=
== Hardware ==
{| class="wikitable" border="1"
! Summary
! Description
! Fixed with hardware model/revision
! Newest hardware model/revision this flaw was checked for
! Timeframe this was discovered
! Discovered by
|-
| ARM9/ARM11 bootrom vectors point at unitialized RAM
| ARM9's and ARM11's exception vectors are hardcoded to point at the CPU's internal memory (0x08000000 region for ARM9, AXIWRAM for ARM11). While the bootrom does set them up to point to an endless loop at some point during boot, it does not do so immediately. As such, a carefully-timed fault injection (via hardware) to trigger an exception (such as an invalid instruction) will cause execution to fall into ARM9 RAM.
Since RAM isn't cleared on boot (see below), one can immediately start execution of their own code here to dump bootrom, OTP, etc.
The ARM9 bootrom does the following at reset: reset vector branches to another instruction, then branches to bootrom+0x8000. Hence, there's no way to know for certain when exactly the ARM9 exception-vector data stored in memory gets initialized.

This requires *very* *precise* timing for triggering the hardware fault: it's unknown if anyone actually exploited this successfully at the time of writing(the one who attempted+discovered it *originally* as listed in this wiki section hasn't).
| None: all available 3DS models at the time of writing have the exact same ARM9/ARM11 bootrom for the unprotected areas.
| New3DS
| End of February 2014
| [[User:Derrek|derrek]], WulfyStylez (May 2015) independently
|-
| Missing AES key clearing
| The hardware AES engine does not clear keys when doing a hard reset/reboot.
| None
| New3DS
| August 2014
| Mathieulh/Others
|-
| No RAM clearing on reboots
| On an MCU-triggered reboot all RAM including FCRAM/ARM9 memory/AXIWRAM/VRAM keeps its contents.
| None
| New3DS
| March 2014
| [[User:Derrek|derrek]]
|-
| 32bits of actual console-unique TWLNAND keydata
| On retail the 8-bytes at ARM9 address [[Memory_layout|0x01FFB808]] are XORed with hard-coded data, to generate the TWL console-unique keys, including TWLNAND. On Old3DS the high u32 is always 0x0, while on New3DS that u32 is always 0x2. On top of this, the lower u32's highest bit is always ORed. only 31 bits of the TWL console-unique keydata / TWL consoleID are actually console-unique.
This allows one to easily bruteforce the TWL console-unique keydata with *just* data from TWLNAND. On DSi the actual console-unique data for key generation is 8-bytes(all bytes actually set).
| None
| New3DS
| 2012?
| [[User:Yellows8|Yellows8]]
|-
| DSi / 3DS-TWL key-generator
| After using the key generator to generate the normal-key, you could overwrite parts of the normal-key with your own data and then recover the key-generator output by comparing the new crypto output with the original crypto output. From the normal-key outputs, you could deduce the TWL key-generator function.
This applies to the keyX/keyY too.

This attack does not work for the 3DS key-generator because keyslots 0-3 are only for TWL keys.
| None
| New3DS
| 2011
| [[User:Yellows8|Yellows8]]
|-
| 3DS key-generator
| The algorithm for generating the normal-keys for keyslots is cryptographically weak. As a result, it is easily susceptible to differential cryptanalysis if the normal-key corresponding to any scrambler-generated keyslot is discovered.

Several such pairs of matching normal-keys and KeyY values were found, leading to deducing the key-generator function.
| None
| New3DS
| February 2015
| [[User:Yellows8|Yellows8]], [[User:Plutooo|plutoo]]
|-
| FIRM partitions known-plaintext
| The [[Flash_Filesystem|FIRM partitions]] are encrypted with AES-CTR without a MAC. Since this works by XOR'ing data with a static (per-console in this case) keystream, one can deduce the keystream of a portion of each FIRM partition if they have the actual FIRM binary stored in it.

This can be paired with many exploits. For example, it allows minor FIRM downgrades (i.e. 10.4 to 9.6 or 9.5 to 9.4, but not 9.6 to 9.5).

This can be somewhat addressed by having a FIRM header skip over previously used section offsets, but this would just air-gap newer FIRMs without fixing the core bug. This can also only be done a limited number of times due to the size of FIRM versus the size of the partitions.
| None
| New3DS
|
| Everyone
|}

== ARM9 software ==
=== arm9loader ===
{| class="wikitable" border="1"
|-
! Summary
! Description
! Successful exploitation result
! Fixed in [[FIRM]] system version
! Last [[FIRM]] system version this flaw was checked for
! Timeframe this was discovered
! Public disclosure timeframe
! Discovered by
|-
| Rearrangable keys in the NAND keystore
| Due to the keystore being encrypted with AES-ECB, one can rearrange blocks and still have the NAND keystore decrypt in a deterministic way.

Using 10.0 FIRM it is possible to rearrange keys such that ARM9 memory is executed. As such using existing ARM9 execution 10.0 FIRM can be written to NAND and a payload written to memory, with the payload to be executed post-K9L using an MCU reboot.
| arm9loaderhax given existing ARM9 code execution
| None
| [[11.1.0-34|11.1.0-X]]
| Early 2016
| 27 September 2016
| Myria, [[User:Dark samus|dark_samus]]; mathieulh (independently); [[User:Plutooo|plutoo]] (independently) + others
|-
| 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
| [[11.1.0-34|11.1.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, access to uncleared OTP hash keydata
| None
| [[11.1.0-34|11.1.0-X]]
| March, 2015
|
| [[User:Plutooo|plutoo]]
|-
| Uncleared New3DS keyslot 0x11
| Originally the New3DS [[FIRM]] arm9bin loader only cleared keyslot 0x11 when it gets executed at firmlaunch. This was fixed with [[9.5.0-22|9.5.0-X]] by completely clearing keyslot 0x11 immediately after the loader finishes using keyslot 0x11.
This means that any ARM9 code that can execute before the loader clears the keyslot at firmlaunch(including firmlaunch-hax) can get access to the uncleared keyslot 0x11, which then allows one to generate all <=v9.5 New3DS keyXs which are generated by keyslot 0x11.

Therefore, to completely fix this the loader would have to generate more keys using different keyslot 0x11 keydata. This was done with [[9.6.0-24|9.6.0-X]].
| New3DS keyXs generation
| Mostly fixed with [[9.5.0-22|9.5.0-X]], completely fixed with new keys with [[9.6.0-24|9.6.0-X]].
|
| February 3, 2015 (one day after [[9.5.0-22|9.5.0-X]] release)
|
| [[User:Yellows8|Yellows8]]
|}

=== Process9 ===
{| class="wikitable" border="1"
|-
! Summary
! Description
! Successful exploitation result
! Fixed in [[FIRM]] system version
! Last [[FIRM]] system version this flaw was checked for
! Timeframe this was discovered
! Public disclosure timeframe
! Discovered by
|-
| Leak of normal-key matching a key-scrambler key
| New 3DS firmware versions [[8.1.0-0 New3DS|8.1.0]] through [[9.2.0-20|9.2.0]] set the encryption key for [[Amiibo]] data using a hardcoded normal-key in Process9. In firmware [[9.3.0-21|9.3.0]], Nintendo "fixed" this by using the key scrambler instead, by calculating the keyY value for keyslot 0x39 that results in the same normal-key, then hardcoding that keyY into Process9.

Nintendo's fix is actually the problem: Nintendo revealed the normal-key matching an unknown keyX and a known keyY. Combined with the key scrambler using an insecure scrambling algorithm (see "Hardware" above), the key scrambler function could be deduced.
| Deducing the keyX for keyslot 0x39 and the key scrambler algorithm
| New 3DS [[9.3.0-21|9.3.0-X]], sort of
| [[10.0.0-27|10.0.0-X]]
| Sometime in 2015 after the hardware key-generator was broken.
| 32c3 3ds talk (December 27, 2015)
| [[User:Yellows8|Yellows8]]
|-
| Leak of normal-key matching a key-generator key
| During the 3DS' development (June/July 2010) Nintendo added support installing encrypted content ([[CIA]]). Common-key index1 was intended to be a [[AES|hardware generated key]]. However while they added code to generate the key in hardware, they forgot to remove the normal-key for index1 (used elsewhere, likely old debug code). Nintendo later removed the normal key sometime before the first non-prototype firmware release.

Knowing the keyY and the normal-key for common-key index1, the devkit key-generator algorithm can be deduced (see "Hardware" above). Additionally the remaining devkit common-keys can be generated once the common-key keyX is recovered.

Note the devkit key-generator was discovered to be the same as the retail key-generator.
| Deducing the keyX for keyslot 0x3D and hardware key-generator algorithm. Generate remaining devkit common-keys.
| pre-[[1.0.0-0|1.0.0-X]]
|
| Shortly after the key-generator was revealed to be flawed at the 32c3 3ds talk
| January 20, 2016
| [[User:Jakcron|jakcron]]
|-
| ntrcardhax
|
| ARM9 code execution
| 10.4.0-29
|
| 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.

[[11.0.0-33|11.0.0-X]] fixed this for key system titles (MSET, Home Menu, spider, ErrDisp, SKATER, NATIVE_FIRM, and every retail system module), by checking the version of the title to install against a hard-coded list of (titleID, minimumVersionRequired) pairs.
| Bypassing title version check at installation, which then allows downgrading any title.
| [[11.0.0-33|11.0.0-X]], for key system titles.
| NATIVE_FIRM / AM-sysmodule [[11.0.0-33|11.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
| [[11.1.0-34|11.1.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
| [[11.1.0-34|11.1.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.

From [[3.0.0-5|3.0.0-X]] this was fixed by setting the bit in Kernel9 after poking some registers in that region. On New3DS arm9loader sets this bit instead of Kernel9, which is exploitable through a hardware + software vulnerability (see arm9loaderhax / description).

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

== 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
| [[11.1.0-34|11.1.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) required patching the kernel .text or modifying SVC-access-control.
| See description
| [[11.0.0-33|11.0.0-X]] (deleted)
|
|
| 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
| [[11.1.0-34|11.1.0-X]]
|
|
|-
| memchunkhax2.1
| Nintendo's fix for memchunkhax2 in [[10.4.0-29|10.4.0-X]] did not fix the GPU case: one may cause the requisite ToCToU race using gspwn, bypassing the new validation.
derrek's original 32c3 presentation for memchunkhax2 commented that a GPU-based attack was possible, but would be difficult. However, memchunkhax2.1 showed that it was possible to do fairly reliably.
| ARM11 kernel code execution
| None
| [[10.4.0-29|10.4.0-X]]
|
| derrek, aliaspider
|-
| memchunkhax2
|
| ARM11 kernel code execution
| [[10.4.0-29|10.4.0-X]] (partially)
| [[10.4.0-29|10.4.0-X]]
|
| derrek
|-
| heaphax
| Can change the size of free memchunk structures stored in FCRAM using DMA, which leads to the ability to allocate memory chunks over already-allocated memory. This can be used in the SYSTEM region to allocate RW memory over any part of the NS system module, which is enough to take it over.
| Code execution with access to all of NS's privileges. (including downgrading) Code execution within any applet.
| [[11.0.0-33|11.0.0-X]], via the new [[Memory_Management#MemoryBlockHeader|memchunkhdr]] MAC which prevents modifying memchunkhdr data with DMA.
| [[11.0.0-33|11.0.0-X]]
| April 2015 ?
| smea
|-
| snshax
| Can force creation of Safe NS process into gspwn-able memory, allowing for takeover.
| Code execution with access to all of NS's privileges. (including downgrading)
| [[10.1.0-27|10.1.0-X]]
| [[10.1.0-27|10.1.0-X]]
| April 2015 ?
| smea
|-
| 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
|-
| [[MVD_Services|MVD]]: Stack buffer overflow with [[MVDSTD:SetupOutputBuffers]].
| The input total_entries is not validated when initially processing the input entry-list. This fixed-size input entry-list is copied to stack from the command request. The loop for processing this initializes a global table, the converted linearmem->physaddrs used there are also copied to stack(0x8-bytes of physaddrs per entry).

If total_entries is too large, MVD-sysmodule will crash due to reading unmapped memory following the stack(0x10000000). Afterwards if the out-of-bounds total_entries is smaller than that, it will crash due accessing address 0x0, hence this useless.
| MVD-sysmodule crash.
| None
| [[9.0.0-20]]
| April 22, 2016 (Tested on the 25th)
| April 25, 2016
| [[User:Yellows8|Yellows8]]
|-
| [[NWM_Services|NWM]]: Using CTRSDK heap with UDS sharedmem from the user-process.
| See the HTTP-sysmodule section below.

CTRSDK heap is used with the sharedmem from [[NWMUDS:InitializeWithVersion]]. Buffers are allocated/freed under this heap using [[NWMUDS:Bind]] and [[NWMUDS:Unbind]].

Hence, overwriting sharedmem with gspwn then using [[NWMUDS:Unbind]] results in the usual controlled CTRSDK memchunk-header write, similar to HTTP-sysmodule.

This could be done by creating an UDS network, without any other nodes on the network.

Besides CTRSDK memchunk-headers, there are no addresses stored under this sharedmem.
| ROP under NWM-module.
| None
| [[9.0.0-20|9.0.0-X]]
| April 10, 2016
| April 16, 2016
| [[User:Yellows8|Yellows8]]
|-
| [[DLP_Services|DLP]]: Out-of-bounds memory access during spectator [[Download_Play|data-frame]] checksum calculation
| DLP doesn't validate the frame_size when receiving spectator data-frames at all, unlike non-spectator data-frames. The actual spectator data-frame parsing code doesn't use that field either. However, the data-frame checksum calculation code called during checksum verification does use the frame_size for loading the size of the framebuf.

Hence, using a large frame_size like 0xFFFF will result in the checksum calculation code reading data out-of-bounds. This isn't really useful, you could trigger a remote local-WLAN DLP-sysmodule crash while a 3DS system is scanning for DLP networks(due to accessing unmapped memory), but that's about all(trying to infoleak with this likely isn't useful either).
| DLP-sysmodule crash, handled by dlplay system-application by a "connection interrupted" error eventually then a fatal-error via ErrDisp.
| None
| [[10.0.0-27|10.0.0-X]]
| April 8, 2016 (Tested on the 10th)
| April 10, 2016
| [[User:Yellows8|Yellows8]]
|-
| [[DLP_Services|DLP]]: Out-of-bounds output data writing during spectator sysupdate titlelist [[Download_Play|data-frame]] handling
| The total_entries and out_entryindex fields for the titlelist DLP spectator data-frames are not validated. This is parsed during DLP network scanning. Hence, the specified titlelist data can be written out-of-bounds using the specified out_entryindex and total_entries. A crash will occur while reading the input data-frame titlelist if total_entries is larger than 0x27A, due to accessing unmapped memory.

There's not much non-zero data to overwrite following the output buffer(located in sharedmem), any ptrs are located in sharedmem. Overwriting certain ptr(s) are only known to cause a crash when attempting to use the DLP-client shutdown service-command.

There's no known way to exploit the above crash, since the linked-list code involves writes zeros(with a controlled start ptr).
|
| None
| [[10.0.0-27|10.0.0-X]]
| April 8-9, 2016
| April 10, 2016
| [[User:Yellows8|Yellows8]]
|-
| [[IR_Services|IR]]: Stack buffer overflow with custom hardware
| Originally IR sysmodule used the read value from the I2C-IR registers TXLVL and RXLVL without validating them at all. See [[10.6.0-31|here]] for the fix. This is the size used for reading the data-recv FIFO, etc. The output buffer for reading is located on the stack.

This should be exploitable if one could successfully setup the custom hardware for this and if the entire intended sizes actually get read from I2C.
| ROP under IR sysmodule.
| [[10.6.0-31|10.6.0-31]]
|
| February 23, 2016 (Unknown if it was noticed before then)
| February 23, 2016
| [[User:Yellows8|Yellows8]]
|-
| [[HTTP_Services|HTTP]]: Using CTRSDK heap with sharedmem from the user-process.
| The data from httpcAddPostDataAscii and other commands is stored under a CTRSDK heap. That heap is the sharedmem specified by the user-process via the HTTPC Initialize command.
Normally this sharedmem isn't accessible to the user-process once the sysmodule maps it, hence using it is supposed to be "safe".

This isn't the case due to gspwn however. Since CTRSDK heap code is so insecure in general, one can use gspwn to locate the HTTPC sharedmem + read/write it, then trigger a mem-write under the sysmodule. This can then be used to get ROP going under HTTP-sysmodule.

This is exploited by [https://github.com/yellows8/ctr-httpwn/ctr-httpwn ctr-httpwn].
| ROP under HTTP sysmdule.
| None
| [[9.6.0-24|9.6.0-X]] (Latest sysmodule version as of [[10.7.0-32|10.7.0-32]])
| Late 2015
| March 22, 2016
| [[User:Yellows8|Yellows8]]
|-
| [[NIM_Services|NIM]]: Downloading old title-versions from eShop
| Multiple NIM service commands(such as [[NIMS:StartDownload]]) use a title-version value specified by the user-process, NIM does not validate that this input version matches the latest version available via SOAP. Therefore, when combined with AM(PXI) [[#Process9|title-downgrading]] via deleting the target eShop title with System Settings Data Management(if the title was already installed), this allows downloading+installing any title-version from eShop ''if'' it's still available from CDN.
The easiest way to exploit this is to just patch the eShop system-application code using these NIM commands(ideally the code which loads the title-version).

Originally this was tested with a debugging-system via modded-FIRM, eventually smea implemented it in HANS for the 32c3 release.
| Downloading old title-versions from eShop
| None
| [[10.0.0-27|10.0.0-X]]
| October 24, 2015 (Unknown when exactly the first eShop title downgrade was actually tested, maybe November)
| January 7, 2016 (Same day Ironfall v1.0 was removed from CDN via the main-CXI files)
| [[User:Yellows8|Yellows8]]
|-
| [[SPI_Services|SPI]] service out-of-bounds write
| cmd1 has out-of-bounds write allowing overwrite of some static variables in .data.
|
| None
| [[9.5.0-22]]
| March 2015
|
| [[User:Plutooo|plutoo]]
|-
| [[NFC_Services|NFC]] module service command buf-overflows
| NFC module copies data with certain commands, from command input buffers to stack without checking the size. These commands include the following, it's unknown if there's more commands with similar issues: "nfc:dev" <0x000C....> and "nfc:s" <0x0037....>.
Since both of these commands are stubbed in the Old3DS NFC module from the very first version(those just return an error), these issues only affect the New3DS NFC module.

There's no known retail titles which have access to either of these services.
| ROP under NFC module.
| New3DS: None
| New3DS: [[9.5.0-22]]
| December 2014?
|
| [[User:Yellows8|Yellows8]]
|-
| [[News_Services|NEWSS]] service command notificationID validation failure
| This module does not validate the input notificationID for <nowiki>"news:s"</nowiki> service commands. This is an out-of-bounds array index bug. For example, [[NEWSS:SetNotificationHeader]] could be used to exploit news module: this copies the input data(size is properly checked) to: out = newsdb_savedata+0x10 + (someu32array[notificationID]*0x70).
| ROP under news module.
| None
| [[9.7.0-25|9.7.0-X]]
| December 2014
|
| [[User:Yellows8|Yellows8]]
|-
| [[NWMUDS:DecryptBeaconData]] heap buffer overflow
| input_size = 0x1E * <value the u8 from input_[[NWM_Services|networkstruct]]+0x1D>. Then input_tag0 is copied to a heap buffer. When input_size is larger than 0xFA-bytes, it will then copy input_tag1 to <end_address_of_previous_outbuf>, with size=input_size-0xFA.

This can be triggered by either using this command directly, or by boadcasting a wifi beacon which triggers it while a 3DS system running the target process is in range, when the process is scanning for hosts to connect to. Processes will only pass tag data to this command when the wlancommID and other thing(s) match the values for the process.

There's no known way to actually exploit this for getting ROP under NWM-module, at the time of originally adding this to the wiki. This is because the data which gets copied out-of-bounds *and* actually causes crash(es), can't be controlled it seems(with just broadcasting a beacon at least). It's unknown whether this could be exploited from just using NWMUDS service-cmd(s) directly.
| Without any actual way to exploit this: NWM-module DoS, resulting in process termination(process crash). This breaks *everything* involving wifi comms, a reboot is required to recover from this.
| None
| [[9.0.0-20]]
| ~September 23, 2014(see the [[NWMUDS:DecryptBeaconData]] page history)
| August 3, 2015
| [[User:Yellows8|Yellows8]]
|-
| [[HID_Services|HID]] module shared-mem
| HID module does not validate the index values in [[HID_Shared_Memory|sharedmem]](just changes index to 0 when index == maxval when updating), therefore large values will result in HID module writing HID data to arbitrary addresses.
| ROP under HID module, but this is *very* unlikely to be exploitable since the data written is HID data.
| None
| [[9.3.0-21]]
| 2014?
|
| [[User:Yellows8|Yellows8]]
|-
| gspwn
| GSP module does not validate addresses given to the GPU. This allows a user-mode application/applet to read/write to a large part of physical FCRAM using GPU DMA. From this, you can overwrite the .text segment of the application you're running under, and gain real code-execution from a ROP-chain. Normally applets' .text([[Home Menu]], [[Internet Browser]], etc) is located beyond the area accessible by the GPU, except for [[RO_Services|CROs]] used by applets([[Internet Browser]] for example).

FCRAM is gpu-accessible up to physaddr 0x26800000 on Old3DS, and 0x2DC00000 on New3DS. This is BASE_memregion_start(aka SYSTEM_memregion_end)-0x400000 with the default memory-layout on Old3DS/New3DS.
| User-mode code execution.
| None
| [[9.6.0-24|9.6.0-X]]
| Early 2014
|
| smea, [[User:Yellows8|Yellows8]]/others before then
|-
| rohax
| Using gspwn, it is possible to overwrite a loaded [[CRO0]]/[[CRR0]] after its RSA-signature has been validated. Badly validated [[CRO0]] header leads to arbitrary read/write of memory in the ro-process. This gives code-execution in the ro module, who has access to [[SVC|syscalls]] 0x70-0x72, 0x7D.

This was fixed after [[ninjhax]] release by adding checks on [[CRO0]]-based pointers before writing to them.
| Memory-mapping syscalls.
| [[9.3.0-21]]
| [[9.4.0-21]]
|
|
| smea, [[User:Plutooo|plutoo]] joint effort
|-
| Region free
| Only [[Home Menu]] itself checks gamecards' region when launching them. Therefore, any application launch that is done directly with [[NS]] without signaling Home Menu to launch the app, will result in region checks being bypassed.
This essentially means launching the gamecard with the [[NS_and_APT_Services|"ns:s"]] service. The main way to exploit this is to trigger a FIRM launch with an application specified, either with a normal FIRM launch or a hardware [[NSS:RebootSystem|reboot]].
| Launching gamecards from any region + bypassing Home Menu gamecard-sysupdate installation
| None
| Last tested with [[10.1.0-27|10.1.0-X]].
| June(?) 2014
|
| [[User:Yellows8|Yellows8]]
|-
| [[NWM_Services|NWM]] service-cmd state null-ptr deref
| The NWMUDS service command code loads a ptr from .data, adds an offset to that, then passes that as the state address for the actual command-handler function. The value of the ptr loaded from .data is not checked, therefore this will cause crashes due to that being 0x0 when NWMUDS was not properly initialized.
It's unknown whether any NWM services besides NWMUDS have this issue.
| This is rather useless since it's only a crash caused by a state ptr based at 0x0.
| None
| [[9.0.0-20]]
| 2013?
|
| [[User:Yellows8|Yellows8]]
|}

=== General/CTRSDK ===
{| class="wikitable" border="1"
|-
! Summary
! Description
! Successful exploitation result
! Fixed in version
! Last version this flaw was checked for
! Timeframe this was discovered
! Discovered by
|-
| [[NWM_Services|UDS]] beacon additional-data buffer overflow
| Originally CTRSDK did not validate the UDS additional-data size before using that size to copy the additional-data to a [[NWM_Services|networkstruct]]. This was eventually fixed.
This was discovered while doing code RE with an old dlp-module version. It's unknown in what specific CTRSDK version this was fixed, or even what system-version updated titles with a fixed version.

It's unknown if there's any titles using a vulnerable CTRSDK version which are also exploitable with this(dlp module can't be exploited with this).

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

3DS System Flaws

2016-09-27T19:27:44Z

Shinyquagsire23: Let's be honest—The real flaw is that they never fixed the missing verification block.

Exploits are used to execute unofficial code (homebrew) on the Nintendo 3DS. This page is a list of publicly known system flaws, for userland applications/applets flaws see [[3DS_Userland_Flaws|here]].

=Stale / Rejected Efforts=
* Neimod has been working on a RAM dumping setup for a little while now. He's de-soldered the 3DS's RAM chip and hooked it and the RAM pinouts on the 3DS' PCB up to a custom RAM dumping setup. A while ago he published photos showing his setup to be working quite well, with the 3DS successfully booting up. However, his flickr stream is now private along with most of his work.

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

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

SD card [[extdata]] and SD savegames can be attacked, for consoles where the console-unique [[Nand/private/movable.sed|movable.sed]] was dumped(accessing SD data is far easier by running code on the target 3DS however).

=System flaws=
== Hardware ==
{| class="wikitable" border="1"
! Summary
! Description
! Fixed with hardware model/revision
! Newest hardware model/revision this flaw was checked for
! Timeframe this was discovered
! Discovered by
|-
| ARM9/ARM11 bootrom vectors point at unitialized RAM
| ARM9's and ARM11's exception vectors are hardcoded to point at the CPU's internal memory (0x08000000 region for ARM9, AXIWRAM for ARM11). While the bootrom does set them up to point to an endless loop at some point during boot, it does not do so immediately. As such, a carefully-timed fault injection (via hardware) to trigger an exception (such as an invalid instruction) will cause execution to fall into ARM9 RAM.
Since RAM isn't cleared on boot (see below), one can immediately start execution of their own code here to dump bootrom, OTP, etc.
The ARM9 bootrom does the following at reset: reset vector branches to another instruction, then branches to bootrom+0x8000. Hence, there's no way to know for certain when exactly the ARM9 exception-vector data stored in memory gets initialized.

This requires *very* *precise* timing for triggering the hardware fault: it's unknown if anyone actually exploited this successfully at the time of writing(the one who attempted+discovered it *originally* as listed in this wiki section hasn't).
| None: all available 3DS models at the time of writing have the exact same ARM9/ARM11 bootrom for the unprotected areas.
| New3DS
| End of February 2014
| [[User:Derrek|derrek]], WulfyStylez (May 2015) independently
|-
| Missing AES key clearing
| The hardware AES engine does not clear keys when doing a hard reset/reboot.
| None
| New3DS
| August 2014
| Mathieulh/Others
|-
| No RAM clearing on reboots
| On an MCU-triggered reboot all RAM including FCRAM/ARM9 memory/AXIWRAM/VRAM keeps its contents.
| None
| New3DS
| March 2014
| [[User:Derrek|derrek]]
|-
| 32bits of actual console-unique TWLNAND keydata
| On retail the 8-bytes at ARM9 address [[Memory_layout|0x01FFB808]] are XORed with hard-coded data, to generate the TWL console-unique keys, including TWLNAND. On Old3DS the high u32 is always 0x0, while on New3DS that u32 is always 0x2. On top of this, the lower u32's highest bit is always ORed. only 31 bits of the TWL console-unique keydata / TWL consoleID are actually console-unique.
This allows one to easily bruteforce the TWL console-unique keydata with *just* data from TWLNAND. On DSi the actual console-unique data for key generation is 8-bytes(all bytes actually set).
| None
| New3DS
| 2012?
| [[User:Yellows8|Yellows8]]
|-
| DSi / 3DS-TWL key-generator
| After using the key generator to generate the normal-key, you could overwrite parts of the normal-key with your own data and then recover the key-generator output by comparing the new crypto output with the original crypto output. From the normal-key outputs, you could deduce the TWL key-generator function.
This applies to the keyX/keyY too.

This attack does not work for the 3DS key-generator because keyslots 0-3 are only for TWL keys.
| None
| New3DS
| 2011
| [[User:Yellows8|Yellows8]]
|-
| 3DS key-generator
| The algorithm for generating the normal-keys for keyslots is cryptographically weak. As a result, it is easily susceptible to differential cryptanalysis if the normal-key corresponding to any scrambler-generated keyslot is discovered.

Several such pairs of matching normal-keys and KeyY values were found, leading to deducing the key-generator function.
| None
| New3DS
| February 2015
| [[User:Yellows8|Yellows8]], [[User:Plutooo|plutoo]]
|-
| FIRM partitions known-plaintext
| The [[Flash_Filesystem|FIRM partitions]] are encrypted with AES-CTR without a MAC. Since this works by XOR'ing data with a static (per-console in this case) keystream, one can deduce the keystream of a portion of each FIRM partition if they have the actual FIRM binary stored in it.

This can be paired with many exploits. For example, it allows minor FIRM downgrades (i.e. 10.4 to 9.6 or 9.5 to 9.4, but not 9.6 to 9.5).

This can be somewhat addressed by having a FIRM header skip over previously used section offsets, but this would just air-gap newer FIRMs without fixing the core bug. This can also only be done a limited number of times due to the size of FIRM versus the size of the partitions.
| None
| New3DS
|
| Everyone
|}

== ARM9 software ==
=== arm9loader ===
{| class="wikitable" border="1"
|-
! Summary
! Description
! Successful exploitation result
! Fixed in [[FIRM]] system version
! Last [[FIRM]] system version this flaw was checked for
! Timeframe this was discovered
! Public disclosure timeframe
! Discovered by
|-
| Uncleared OTP hash keydata in console-unique 0x11 key-generation
| Kernel9Loader does not clear the [[SHA_Registers#SHA_HASH|SHA_HASH register]] after use. As a result, the data stored here as K9L hands over to Kernel9 is the hash of [[OTP_Registers|OTP data]] used to seed the [[FIRM#New_3DS_FIRM|console-unique NAND keystore decryption key]] set on keyslot 0x11.

Retrieving this keydata and the [[Flash_Filesystem#0x12C00|NAND keystore]] of the same device allows calculating the decrypted New3DS NAND keystore (non-unique, common to all New3DS units), which contains AES normal keys, also set on keyslot 0x11, which are then used to derive all current [[AES_Registers#Keyslots|New3DS-only AES keyXs]] including the newer batch introduced in [[9.6.0-24#arm9loader|9.6.0-X]]. From there, it is trivial to perform the same key derivation in order to initialize those keys on any system version, and even on Old3DS.

This can be performed by exploiting the "arm9loaderhax" vulnerability to obtain post-K9L code execution after an MCU reboot (the bootrom section-loading fail is not relevant here, this attack was performed without OTP data by brute-forcing keys), and using this to dump the SHA_HASH register. This attack works on any FIRM version shipping a vulnerable version of K9L, whereas OTP dumping required a boot of <[[3.0.0-6|3.0.0-X]].

This attack results in obtaining the entire (0x200-bytes) NAND keystore - it was confirmed at a later date that this keystore is encrypted with the same key (by comparing the decrypted data from multiple units), and therefore using another key in this store will not remedy the issue as all keys are known (i.e. later, unused keys decrypt to the same 0x200-bytes constant with the same OTP hash). Later keys could have been encrypted differently but this is not the case. As a result of this, it is not possible for Nintendo to use K9L again in its current format for its intended purpose, though this was not news from the moment people dumped a New3DS OTP.
| Derivation of all New3DS keys generated via the NAND keystore (0x1B "Secure4" etc.)
| None
| [[11.1.0-34|11.1.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.

Using a 10.0 FIRM it is possible to execute ARM9 memory by rearranging the keys in the keystore, due to the nature of AES-ECB. As such the 10.0 FIRM can be written to NAND and a payload written to memory using existing ARM9 execution, with the payload to be executed post-K9L using an MCU reboot.

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, access to uncleared OTP hash keydata
| None
| [[11.1.0-34|11.1.0-X]]
| March, 2015
|
| [[User:Plutooo|plutoo]]
|-
| Uncleared New3DS keyslot 0x11
| Originally the New3DS [[FIRM]] arm9bin loader only cleared keyslot 0x11 when it gets executed at firmlaunch. This was fixed with [[9.5.0-22|9.5.0-X]] by completely clearing keyslot 0x11 immediately after the loader finishes using keyslot 0x11.
This means that any ARM9 code that can execute before the loader clears the keyslot at firmlaunch(including firmlaunch-hax) can get access to the uncleared keyslot 0x11, which then allows one to generate all <=v9.5 New3DS keyXs which are generated by keyslot 0x11.

Therefore, to completely fix this the loader would have to generate more keys using different keyslot 0x11 keydata. This was done with [[9.6.0-24|9.6.0-X]].
| New3DS keyXs generation
| Mostly fixed with [[9.5.0-22|9.5.0-X]], completely fixed with new keys with [[9.6.0-24|9.6.0-X]].
|
| February 3, 2015 (one day after [[9.5.0-22|9.5.0-X]] release)
|
| [[User:Yellows8|Yellows8]]
|}

=== Process9 ===
{| class="wikitable" border="1"
|-
! Summary
! Description
! Successful exploitation result
! Fixed in [[FIRM]] system version
! Last [[FIRM]] system version this flaw was checked for
! Timeframe this was discovered
! Public disclosure timeframe
! Discovered by
|-
| Leak of normal-key matching a key-scrambler key
| New 3DS firmware versions [[8.1.0-0 New3DS|8.1.0]] through [[9.2.0-20|9.2.0]] set the encryption key for [[Amiibo]] data using a hardcoded normal-key in Process9. In firmware [[9.3.0-21|9.3.0]], Nintendo "fixed" this by using the key scrambler instead, by calculating the keyY value for keyslot 0x39 that results in the same normal-key, then hardcoding that keyY into Process9.

Nintendo's fix is actually the problem: Nintendo revealed the normal-key matching an unknown keyX and a known keyY. Combined with the key scrambler using an insecure scrambling algorithm (see "Hardware" above), the key scrambler function could be deduced.
| Deducing the keyX for keyslot 0x39 and the key scrambler algorithm
| New 3DS [[9.3.0-21|9.3.0-X]], sort of
| [[10.0.0-27|10.0.0-X]]
| Sometime in 2015 after the hardware key-generator was broken.
| 32c3 3ds talk (December 27, 2015)
| [[User:Yellows8|Yellows8]]
|-
| Leak of normal-key matching a key-generator key
| During the 3DS' development (June/July 2010) Nintendo added support installing encrypted content ([[CIA]]). Common-key index1 was intended to be a [[AES|hardware generated key]]. However while they added code to generate the key in hardware, they forgot to remove the normal-key for index1 (used elsewhere, likely old debug code). Nintendo later removed the normal key sometime before the first non-prototype firmware release.

Knowing the keyY and the normal-key for common-key index1, the devkit key-generator algorithm can be deduced (see "Hardware" above). Additionally the remaining devkit common-keys can be generated once the common-key keyX is recovered.

Note the devkit key-generator was discovered to be the same as the retail key-generator.
| Deducing the keyX for keyslot 0x3D and hardware key-generator algorithm. Generate remaining devkit common-keys.
| pre-[[1.0.0-0|1.0.0-X]]
|
| Shortly after the key-generator was revealed to be flawed at the 32c3 3ds talk
| January 20, 2016
| [[User:Jakcron|jakcron]]
|-
| ntrcardhax
|
| ARM9 code execution
| 10.4.0-29
|
| 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.

[[11.0.0-33|11.0.0-X]] fixed this for key system titles (MSET, Home Menu, spider, ErrDisp, SKATER, NATIVE_FIRM, and every retail system module), by checking the version of the title to install against a hard-coded list of (titleID, minimumVersionRequired) pairs.
| Bypassing title version check at installation, which then allows downgrading any title.
| [[11.0.0-33|11.0.0-X]], for key system titles.
| NATIVE_FIRM / AM-sysmodule [[11.0.0-33|11.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
| [[11.1.0-34|11.1.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
| [[11.1.0-34|11.1.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.

From [[3.0.0-5|3.0.0-X]] this was fixed by setting the bit in Kernel9 after poking some registers in that region. On New3DS arm9loader sets this bit instead of Kernel9, which is exploitable through a hardware + software vulnerability (see arm9loaderhax / description).

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

== 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
| [[11.1.0-34|11.1.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) required patching the kernel .text or modifying SVC-access-control.
| See description
| [[11.0.0-33|11.0.0-X]] (deleted)
|
|
| 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
| [[11.1.0-34|11.1.0-X]]
|
|
|-
| memchunkhax2.1
| Nintendo's fix for memchunkhax2 in [[10.4.0-29|10.4.0-X]] did not fix the GPU case: one may cause the requisite ToCToU race using gspwn, bypassing the new validation.
derrek's original 32c3 presentation for memchunkhax2 commented that a GPU-based attack was possible, but would be difficult. However, memchunkhax2.1 showed that it was possible to do fairly reliably.
| ARM11 kernel code execution
| None
| [[10.4.0-29|10.4.0-X]]
|
| derrek, aliaspider
|-
| memchunkhax2
|
| ARM11 kernel code execution
| [[10.4.0-29|10.4.0-X]] (partially)
| [[10.4.0-29|10.4.0-X]]
|
| derrek
|-
| heaphax
| Can change the size of free memchunk structures stored in FCRAM using DMA, which leads to the ability to allocate memory chunks over already-allocated memory. This can be used in the SYSTEM region to allocate RW memory over any part of the NS system module, which is enough to take it over.
| Code execution with access to all of NS's privileges. (including downgrading) Code execution within any applet.
| [[11.0.0-33|11.0.0-X]], via the new [[Memory_Management#MemoryBlockHeader|memchunkhdr]] MAC which prevents modifying memchunkhdr data with DMA.
| [[11.0.0-33|11.0.0-X]]
| April 2015 ?
| smea
|-
| snshax
| Can force creation of Safe NS process into gspwn-able memory, allowing for takeover.
| Code execution with access to all of NS's privileges. (including downgrading)
| [[10.1.0-27|10.1.0-X]]
| [[10.1.0-27|10.1.0-X]]
| April 2015 ?
| smea
|-
| 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
|-
| [[MVD_Services|MVD]]: Stack buffer overflow with [[MVDSTD:SetupOutputBuffers]].
| The input total_entries is not validated when initially processing the input entry-list. This fixed-size input entry-list is copied to stack from the command request. The loop for processing this initializes a global table, the converted linearmem->physaddrs used there are also copied to stack(0x8-bytes of physaddrs per entry).

If total_entries is too large, MVD-sysmodule will crash due to reading unmapped memory following the stack(0x10000000). Afterwards if the out-of-bounds total_entries is smaller than that, it will crash due accessing address 0x0, hence this useless.
| MVD-sysmodule crash.
| None
| [[9.0.0-20]]
| April 22, 2016 (Tested on the 25th)
| April 25, 2016
| [[User:Yellows8|Yellows8]]
|-
| [[NWM_Services|NWM]]: Using CTRSDK heap with UDS sharedmem from the user-process.
| See the HTTP-sysmodule section below.

CTRSDK heap is used with the sharedmem from [[NWMUDS:InitializeWithVersion]]. Buffers are allocated/freed under this heap using [[NWMUDS:Bind]] and [[NWMUDS:Unbind]].

Hence, overwriting sharedmem with gspwn then using [[NWMUDS:Unbind]] results in the usual controlled CTRSDK memchunk-header write, similar to HTTP-sysmodule.

This could be done by creating an UDS network, without any other nodes on the network.

Besides CTRSDK memchunk-headers, there are no addresses stored under this sharedmem.
| ROP under NWM-module.
| None
| [[9.0.0-20|9.0.0-X]]
| April 10, 2016
| April 16, 2016
| [[User:Yellows8|Yellows8]]
|-
| [[DLP_Services|DLP]]: Out-of-bounds memory access during spectator [[Download_Play|data-frame]] checksum calculation
| DLP doesn't validate the frame_size when receiving spectator data-frames at all, unlike non-spectator data-frames. The actual spectator data-frame parsing code doesn't use that field either. However, the data-frame checksum calculation code called during checksum verification does use the frame_size for loading the size of the framebuf.

Hence, using a large frame_size like 0xFFFF will result in the checksum calculation code reading data out-of-bounds. This isn't really useful, you could trigger a remote local-WLAN DLP-sysmodule crash while a 3DS system is scanning for DLP networks(due to accessing unmapped memory), but that's about all(trying to infoleak with this likely isn't useful either).
| DLP-sysmodule crash, handled by dlplay system-application by a "connection interrupted" error eventually then a fatal-error via ErrDisp.
| None
| [[10.0.0-27|10.0.0-X]]
| April 8, 2016 (Tested on the 10th)
| April 10, 2016
| [[User:Yellows8|Yellows8]]
|-
| [[DLP_Services|DLP]]: Out-of-bounds output data writing during spectator sysupdate titlelist [[Download_Play|data-frame]] handling
| The total_entries and out_entryindex fields for the titlelist DLP spectator data-frames are not validated. This is parsed during DLP network scanning. Hence, the specified titlelist data can be written out-of-bounds using the specified out_entryindex and total_entries. A crash will occur while reading the input data-frame titlelist if total_entries is larger than 0x27A, due to accessing unmapped memory.

There's not much non-zero data to overwrite following the output buffer(located in sharedmem), any ptrs are located in sharedmem. Overwriting certain ptr(s) are only known to cause a crash when attempting to use the DLP-client shutdown service-command.

There's no known way to exploit the above crash, since the linked-list code involves writes zeros(with a controlled start ptr).
|
| None
| [[10.0.0-27|10.0.0-X]]
| April 8-9, 2016
| April 10, 2016
| [[User:Yellows8|Yellows8]]
|-
| [[IR_Services|IR]]: Stack buffer overflow with custom hardware
| Originally IR sysmodule used the read value from the I2C-IR registers TXLVL and RXLVL without validating them at all. See [[10.6.0-31|here]] for the fix. This is the size used for reading the data-recv FIFO, etc. The output buffer for reading is located on the stack.

This should be exploitable if one could successfully setup the custom hardware for this and if the entire intended sizes actually get read from I2C.
| ROP under IR sysmodule.
| [[10.6.0-31|10.6.0-31]]
|
| February 23, 2016 (Unknown if it was noticed before then)
| February 23, 2016
| [[User:Yellows8|Yellows8]]
|-
| [[HTTP_Services|HTTP]]: Using CTRSDK heap with sharedmem from the user-process.
| The data from httpcAddPostDataAscii and other commands is stored under a CTRSDK heap. That heap is the sharedmem specified by the user-process via the HTTPC Initialize command.
Normally this sharedmem isn't accessible to the user-process once the sysmodule maps it, hence using it is supposed to be "safe".

This isn't the case due to gspwn however. Since CTRSDK heap code is so insecure in general, one can use gspwn to locate the HTTPC sharedmem + read/write it, then trigger a mem-write under the sysmodule. This can then be used to get ROP going under HTTP-sysmodule.

This is exploited by [https://github.com/yellows8/ctr-httpwn/ctr-httpwn ctr-httpwn].
| ROP under HTTP sysmdule.
| None
| [[9.6.0-24|9.6.0-X]] (Latest sysmodule version as of [[10.7.0-32|10.7.0-32]])
| Late 2015
| March 22, 2016
| [[User:Yellows8|Yellows8]]
|-
| [[NIM_Services|NIM]]: Downloading old title-versions from eShop
| Multiple NIM service commands(such as [[NIMS:StartDownload]]) use a title-version value specified by the user-process, NIM does not validate that this input version matches the latest version available via SOAP. Therefore, when combined with AM(PXI) [[#Process9|title-downgrading]] via deleting the target eShop title with System Settings Data Management(if the title was already installed), this allows downloading+installing any title-version from eShop ''if'' it's still available from CDN.
The easiest way to exploit this is to just patch the eShop system-application code using these NIM commands(ideally the code which loads the title-version).

Originally this was tested with a debugging-system via modded-FIRM, eventually smea implemented it in HANS for the 32c3 release.
| Downloading old title-versions from eShop
| None
| [[10.0.0-27|10.0.0-X]]
| October 24, 2015 (Unknown when exactly the first eShop title downgrade was actually tested, maybe November)
| January 7, 2016 (Same day Ironfall v1.0 was removed from CDN via the main-CXI files)
| [[User:Yellows8|Yellows8]]
|-
| [[SPI_Services|SPI]] service out-of-bounds write
| cmd1 has out-of-bounds write allowing overwrite of some static variables in .data.
|
| None
| [[9.5.0-22]]
| March 2015
|
| [[User:Plutooo|plutoo]]
|-
| [[NFC_Services|NFC]] module service command buf-overflows
| NFC module copies data with certain commands, from command input buffers to stack without checking the size. These commands include the following, it's unknown if there's more commands with similar issues: "nfc:dev" <0x000C....> and "nfc:s" <0x0037....>.
Since both of these commands are stubbed in the Old3DS NFC module from the very first version(those just return an error), these issues only affect the New3DS NFC module.

There's no known retail titles which have access to either of these services.
| ROP under NFC module.
| New3DS: None
| New3DS: [[9.5.0-22]]
| December 2014?
|
| [[User:Yellows8|Yellows8]]
|-
| [[News_Services|NEWSS]] service command notificationID validation failure
| This module does not validate the input notificationID for <nowiki>"news:s"</nowiki> service commands. This is an out-of-bounds array index bug. For example, [[NEWSS:SetNotificationHeader]] could be used to exploit news module: this copies the input data(size is properly checked) to: out = newsdb_savedata+0x10 + (someu32array[notificationID]*0x70).
| ROP under news module.
| None
| [[9.7.0-25|9.7.0-X]]
| December 2014
|
| [[User:Yellows8|Yellows8]]
|-
| [[NWMUDS:DecryptBeaconData]] heap buffer overflow
| input_size = 0x1E * <value the u8 from input_[[NWM_Services|networkstruct]]+0x1D>. Then input_tag0 is copied to a heap buffer. When input_size is larger than 0xFA-bytes, it will then copy input_tag1 to <end_address_of_previous_outbuf>, with size=input_size-0xFA.

This can be triggered by either using this command directly, or by boadcasting a wifi beacon which triggers it while a 3DS system running the target process is in range, when the process is scanning for hosts to connect to. Processes will only pass tag data to this command when the wlancommID and other thing(s) match the values for the process.

There's no known way to actually exploit this for getting ROP under NWM-module, at the time of originally adding this to the wiki. This is because the data which gets copied out-of-bounds *and* actually causes crash(es), can't be controlled it seems(with just broadcasting a beacon at least). It's unknown whether this could be exploited from just using NWMUDS service-cmd(s) directly.
| Without any actual way to exploit this: NWM-module DoS, resulting in process termination(process crash). This breaks *everything* involving wifi comms, a reboot is required to recover from this.
| None
| [[9.0.0-20]]
| ~September 23, 2014(see the [[NWMUDS:DecryptBeaconData]] page history)
| August 3, 2015
| [[User:Yellows8|Yellows8]]
|-
| [[HID_Services|HID]] module shared-mem
| HID module does not validate the index values in [[HID_Shared_Memory|sharedmem]](just changes index to 0 when index == maxval when updating), therefore large values will result in HID module writing HID data to arbitrary addresses.
| ROP under HID module, but this is *very* unlikely to be exploitable since the data written is HID data.
| None
| [[9.3.0-21]]
| 2014?
|
| [[User:Yellows8|Yellows8]]
|-
| gspwn
| GSP module does not validate addresses given to the GPU. This allows a user-mode application/applet to read/write to a large part of physical FCRAM using GPU DMA. From this, you can overwrite the .text segment of the application you're running under, and gain real code-execution from a ROP-chain. Normally applets' .text([[Home Menu]], [[Internet Browser]], etc) is located beyond the area accessible by the GPU, except for [[RO_Services|CROs]] used by applets([[Internet Browser]] for example).

FCRAM is gpu-accessible up to physaddr 0x26800000 on Old3DS, and 0x2DC00000 on New3DS. This is BASE_memregion_start(aka SYSTEM_memregion_end)-0x400000 with the default memory-layout on Old3DS/New3DS.
| User-mode code execution.
| None
| [[9.6.0-24|9.6.0-X]]
| Early 2014
|
| smea, [[User:Yellows8|Yellows8]]/others before then
|-
| rohax
| Using gspwn, it is possible to overwrite a loaded [[CRO0]]/[[CRR0]] after its RSA-signature has been validated. Badly validated [[CRO0]] header leads to arbitrary read/write of memory in the ro-process. This gives code-execution in the ro module, who has access to [[SVC|syscalls]] 0x70-0x72, 0x7D.

This was fixed after [[ninjhax]] release by adding checks on [[CRO0]]-based pointers before writing to them.
| Memory-mapping syscalls.
| [[9.3.0-21]]
| [[9.4.0-21]]
|
|
| smea, [[User:Plutooo|plutoo]] joint effort
|-
| Region free
| Only [[Home Menu]] itself checks gamecards' region when launching them. Therefore, any application launch that is done directly with [[NS]] without signaling Home Menu to launch the app, will result in region checks being bypassed.
This essentially means launching the gamecard with the [[NS_and_APT_Services|"ns:s"]] service. The main way to exploit this is to trigger a FIRM launch with an application specified, either with a normal FIRM launch or a hardware [[NSS:RebootSystem|reboot]].
| Launching gamecards from any region + bypassing Home Menu gamecard-sysupdate installation
| None
| Last tested with [[10.1.0-27|10.1.0-X]].
| June(?) 2014
|
| [[User:Yellows8|Yellows8]]
|-
| [[NWM_Services|NWM]] service-cmd state null-ptr deref
| The NWMUDS service command code loads a ptr from .data, adds an offset to that, then passes that as the state address for the actual command-handler function. The value of the ptr loaded from .data is not checked, therefore this will cause crashes due to that being 0x0 when NWMUDS was not properly initialized.
It's unknown whether any NWM services besides NWMUDS have this issue.
| This is rather useless since it's only a crash caused by a state ptr based at 0x0.
| None
| [[9.0.0-20]]
| 2013?
|
| [[User:Yellows8|Yellows8]]
|}

=== General/CTRSDK ===
{| class="wikitable" border="1"
|-
! Summary
! Description
! Successful exploitation result
! Fixed in version
! Last version this flaw was checked for
! Timeframe this was discovered
! Discovered by
|-
| [[NWM_Services|UDS]] beacon additional-data buffer overflow
| Originally CTRSDK did not validate the UDS additional-data size before using that size to copy the additional-data to a [[NWM_Services|networkstruct]]. This was eventually fixed.
This was discovered while doing code RE with an old dlp-module version. It's unknown in what specific CTRSDK version this was fixed, or even what system-version updated titles with a fixed version.

It's unknown if there's any titles using a vulnerable CTRSDK version which are also exploitable with this(dlp module can't be exploited with this).

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

News/Archive

2016-09-22T15:57:59Z

Shinyquagsire23:

*'''13 September 16''' Nintendo released system update [[11.1.0-34]].
*'''20 August 16''' [[User:Yellows8|Yellows8]] released hblauncher_loader [https://github.com/yellows8/hblauncher_loader/releases/tag/v1.2 v1.2], menuhax [https://github.com/yellows8/3ds_homemenuhax/releases/tag/v3.1 v3.1], and updated the starter-kit. The sploit_installer build from the starter-kit now supports all regions for stickerhax except CHNTWN. This also sends the Home Menu title-version for the initial *hax payload network request, unless the user changed the system-info(like the latest menuhax_manager and hblauncher_loader).
*'''9 August 16''' An updated version of USA SmileBASIC is now available(the updated JPN version was released exactly 2 weeks ago).
*'''29 July 16''' [[User:Yellows8|Yellows8]] released [https://github.com/yellows8/stickerhax stickerhax], which supports <=[[11.0.0-33]].
*'''27 July 16''' [[User:Yellows8|Yellows8]] released new browserhax(see changelog [[browserhax|here]]) and menuhax [https://github.com/yellows8/3ds_homemenuhax/releases v3.0], all of these now support [[11.0.0-33]].
*'''26 July 16''' Various JPN-only eShop app updates were released. This includes JPN SmileBASIC: the update-title was removed from versionlist, and the main-title was updated. Updating an already installed version of the game will currently update to 3.3.1. Uninstalling and redownloading will give you 3.3.2. [https://plutooo.github.io/smilehax/ smilehax] was fixed in [http://smilebasic.com/debug/ 3.3.2].
*'''22 July 16''' [[User:Dazzozo|Dazzozo]] released [https://citizens.salthax.org/ humblehax v2], supporting the Citizens of Earth update released on the eShop 3 days ago.
*'''20 July 16''' [[User:Plutooo|plutoo]] (with help from [[User:Yellows8|Yellows8]]) released [https://plutooo.github.io/smilehax/ smilehax].
*'''19 July 16''' An updated version of the EUR "Citizens of Earth" regular-title is now available on the EUR-eShop, ~2 months after being originally removed. Likewise for USA on the 21st.
*'''18 July 16''' [[User:Smea|Smea]] updated the hosted *hax payload builds(only otherapp for non-KOR) and this [https://smealum.github.io/3ds/ page]. KOR is now supported thanks to d3m3vilurr(system-version >=v9.6). All otherapp payloads were rebuilt+updated, hence these now include a commit for compression(committed by [[User:Yellows8|Yellows8]] with compression code by mtheall). Due to this, oot3dhax+payload can now be installed with multiple other normal save-files, without any issues(via sploit_installer from the starter-kit). [[User:Yellows8|Yellows8]] also updated the [https://smealum.github.io/3ds/ hosted] boot.3dsx to hbmenu 1.1.1.
*'''10 July 16''' MrNbaYoh released [https://mrnbayoh.github.io/basicsploit/ BASICSploit] for version 3.2.1 of SmileBASIC. Currently only the US version is supported. On July 11th the main-app title was removed from USA/JPN eShop: it's no longer listed on the former, while on the latter it can't be purchased.
*'''26 June 16''' [[User:Yellows8|Yellows8]] released oot3dhax builds for supporting [[11.0.0-33]], via updated sploit_installer in the [https://smealum.github.io/3ds/ starter-kit] and raw [https://github.com/yellows8/oot3dhax/releases/tag/06-26-16 saveimages]. Note that attempting to run sploit_installer on a 11.0.0-33 system with *hax payload <=v2.7 is equivalent to [[11.0.0-33|trying]] to use the older oot3dhax on that version.
*'''3 June 16''' [[User:Plutooo|plutoo]] released [https://plutooo.github.io/freakyhax/ freakyhax]. The USA game was removed from the eShop <=3-hours later("... currently unavailable" message).
*'''9 May 16''' Nintendo released system update [[11.0.0-33]].
*'''24 March 16''' Nintendo updated the pages stored on the server used for browser-version-check. Due to almost all of the Old3DS/New3DS pages for non-latest-browser being updated(content is now "99999"), browser versions prior to [[10.7.0-32]] are not usable anymore without using the browser-version-check bypass(fixed with [[10.7.0-32]]). The only exception is New3DS v10.2, it was "updated" but the content is still "0"(this is due to browser-version-check being [[Internet_Browser|broken]] with New3DS v10.2).
*'''22 March 16''' [[User:Yellows8|Yellows8]] released [https://github.com/yellows8/ctr-httpwn/releases ctr-httpwn]. v1.0.1 was released on the 25th for a RootCA cert update.
*'''14 March 16''' Nintendo released system update [[10.7.0-32]].
*'''24-25 February 16''' On the 24th the Old3DS [[Internet_Browser|browser-version-check]] pages were updated so that browser version >=v10.6 is now required. The New3DS pages for this were not changed. About 5 hours later, [[User:Yellows8|Yellows8]] disclosed a bypass for the browser-version-check. User instructions are available [http://yls8.mtheall.com/3dsbrowserhax.php here], details [[3DS_Userland_Flaws|here]].
*'''22 February 16''' Nintendo released system update [[10.6.0-31]].
*'''1 February 16''' As of this date (time zones notwithstanding) following server maintenance Nintendo now checks server-side that users are on current firmware before allowing access to online functionality in games. See [[10.5.0-30|here]] for details.
*'''25 January 16''' Nintendo released system update [[10.5.0-30]].
*'''25 January 16''' [[User:Yellows8|Yellows8]] updated [http://yls8.mtheall.com/3dsbrowserhax.php browserhax], [https://github.com/yellows8/3ds_homemenuhax/releases menuhax], and the oot3dhax [https://github.com/yellows8/oot3dhax/releases saveimages] for v10.4.
*'''18 January 16''' Nintendo released system update [[10.4.0-29]].
*'''7 January 16''' (roughly, not automatically detected) Ironfall v1.0 is no longer downloadable due to the main-CXI content files on CDN being removed (TMD wasn't removed).
*'''27 December 15''' A 3DS console hacking [https://events.ccc.de/congress/2015/Fahrplan/events/7240.html talk] was at 32C3. A recording can be found [https://www.youtube.com/watch?v=UutYOidFx3c here]. Around the end of the talk, [[User:Yellows8|Yellows8]] released [[browserhax]] and [[menuhax]] compatible with the latest system-version at the time of release ([[10.3.0-28]]). The homebrew [https://smealum.github.io/3ds/ starter-kit] was updated for latest menuhax, and for an option for downloading the old vulnerable version of Ironfall from eShop.
*'''15 December 15''' Nintendo released Smash Bros update v1.1.3 which fixed [[smashbroshax]], see [https://github.com/yellows8/3ds_smashbroshax here] for details. However, [[smashbroshax]] is still possible on latest firmware: simply remove the update from SD card before attempting the exploit.
*'''13 December 15''' WinterMute released [http://devkitpro.org/viewtopic.php?f=13&t=8542 devkitARM release 45].
*'''25 November 15''' [[User:Yellows8|Yellows8]] released [https://github.com/yellows8/hblauncher_loader/releases hblauncher_loader].
*'''17-20 November 15''' Nintendo released an update for the normal (non-invite-code) Super Smash Bros demos in USA, EUR and JPN, fixing [[smashbroshax]]. Only the demos were updated, the cartridge and eShop version of the full game are still vulnerable.
*'''12 November 15''' [[User:Yellows8|Yellows8]] released [https://github.com/yellows8/oot3dhax/releases oot3dhax] raw savedata images for gamecards with the latest *hax payloads. The official [https://github.com/smealum/sploit_installer installer] is now [https://smealum.github.io/3ds/ included] in the homebrew starter kit.
*'''9 November 15''' Nintendo released system update [[10.3.0-28]].
*'''2 November 15''' Following an eShop servers maintenance, changes to the [[eShop]] system application require an update of the Homebrew starter kit for eShop access on system versions older than [[10.0.0-27]]. See [[EShop|here]] for details.
*'''30 October 15''' [[User:Yellows8|Yellows8]] released [https://github.com/yellows8/3ds_homemenuhax/releases menuhax] v2.0.
*'''29 October 15''' [[User:Yellows8|Yellows8]] released [https://github.com/yellows8/3ds_smashbroshax/releases 3ds_smashbroshax] v1.2.
*'''26 October 15''' A [[Internet_Browser#v9.9_dummy_web-browser|dummy web browser]] is now being included in CUPs (cart updates) on Old3DS/New3DS likely starting with games shipping [[9.9.0-26|9.9.0-X]]. NVer is not updated by this.
*'''26 October 15''' The system web-browser on Old3DS/New3DS now displays a "sysupdate required" message on systems with [[9.9.0-26]] or above installed, if the installed browser(?) is not the latest version. See [[Internet_Browser#Forced_system-update|here]] for details.
*'''25 October 15''' [[User:Smea|smea]] released *hax 2.5 payloads, which fixes a number of bugs and adds new features such as screenshot-taking, romhacking and eshop access.
*'''20 October 15''' Nintendo released system update [[10.2.0-28]]. The publicly available versions of [[menuhax]] and [[browserhax]] at the time of sysupdate release, were blocked.
*'''15 October 15''' The [[YouTube]] application was updated with a fix for [[tubehax]]. This update is forced: the app itself checks whether a newer version of the title is available.
*'''13 October 15''' "Ironfall: Invasion" was made available on the eShop again (originally pulled on August 11th). The updated version blocks [[ironhax]].
*'''25 September 15''' [[User:Yellows8|Yellows8]] released [[browserhax]] and [[menuhax]]. On the 26th menuhax v1.2 was [https://github.com/yellows8/3ds_homemenuhax/releases released].
*'''14 September 15''' Nintendo released system update [[10.1.0-27]].
*'''11 September 15'''(11:30 EDT) [[User:Yellows8|Yellows8]] released [[smashbroshax]]. On the 30th v1.1 was [https://github.com/yellows8/3ds_smashbroshax/releases released] for supporting Super Smash Bros v1.1.1.
*'''8 September 15''' Nintendo released system update [[10.0.0-27]].
*'''18 July 15''' smea released [[ninjhax]] 2 beta [http://smealum.github.io/ninjhax2/], enabling ARM11 homebrew execution on Old/New 3DS up to firmware 9.9.0-26.
*'''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]].
*'''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

2016-09-22T15:44:24Z

Shinyquagsire23: just another 'released an update to * with 11.1.0-34 support.'

<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 entries in the list.'''

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

=== News ===
</noinclude>
*'''22 September 16''' [[User:shinyquagsire23|Shiny Quagsire]] released an update to [https://smd.salthax.org/ supermysterychunkhax] with [[11.1.0-34]] support.
*'''20 September 16''' [[User:Smea|Smea]] released an update to [http://smealum.github.io/ninjhax2/ Ninjhax 2] with [[11.1.0-34]] support.
*'''16 September 16''' [[User:Plutooo|plutoo]] released an update to [https://plutooo.github.io/freakyhax/ freakyhax] with [[11.1.0-34]] support.
*'''15 September 16''' [[User:Yellows8|Yellows8]] released updated oot3dhax [https://github.com/yellows8/oot3dhax/releases/tag/09-15-16 saveimages] for latest *hax payloads + [[11.1.0-34]] support.

3DS Userland Flaws

2016-07-23T21:23:47Z

Shinyquagsire23:

This page lists vulnerabilities / exploits for 3DS applications and applets. Exploiting these initially results in ROP, from that ROP one can then for example try exploiting [[3DS_System_Flaws|system]] flaw(s).

=Non-system applications=
{| class="wikitable" border="1"
|-
! Application name
! Summary
! Description
! Fixed in app/system version
! Last app/system version this flaw was checked for
! Timeframe info related to this was added to wiki
! Timeframe this vuln was discovered
! Vuln discovered by
|-
| Cubic Ninja
| Map-data stack smash
| See [[Ninjhax|here]] regarding Ninjhax.
| None
| App: Initial version. System: [[10.4.0-29]].
| Ninjhax release
| July 2014
| [[User:smea|smea]]
|-
| The Legend of Zelda: Ocarina of Time 3D
| UTF-16 name string buffer overflow via unchecked u8 length field
| The u8 at offset 0x2C in the savefile is the character-length of the UTF-16 string at offset 0x1C. When copying this string, it's essentially a memory-copy with lenval*2, not a string-copy. This can be used to trigger buffer overflows at various locations depending on the string length.
* When value is >=0x6E it crashes when saving the saveslot, this causes a stack-smash however it normally crashes before it returns from the function which had the stack-frame overwritten.
* With value >=0x9A, it crashes via stack-smash in-game once any dialogs are opened(touching buttons on the touch-screen can trigger it too).
* Length value>=0xCD causes a crash while loading the saveslot, via a heap buffer overflow. This buf-overflow overwrites a heap memchunk following the allocated buffer. When the first 16-bits overwriting that heap memchunk is not the memchunk magic-number(0x7373), the mem-alloc code will just return a NULL ptr which later results in a crash. When the magic-number is valid, the mem-alloc code will continue to attempt to parse the memchunk, which may crash depending on the data which overwrote the memchunk. This heap code is separate from the CTRSDK heap code. Exploiting this doesn't seem to be possible: since the heap code actually verifies that the magic-number for the next/prev memchunk ptrs are correct(unlike CTRSDK), it's not possible to change those ptrs to useful arbitrary addresses outside of savedata(like with triggering a write to a c++ object ptr which later is used with a vtable func-call, this is what one would do with CTRSDK heap here).

On March 11, 2015, an exploit using this vuln was released, that one was intended for warez/etc. The following exploit wasn't released before then mainly because doing so would (presumably) result in the vuln being fixed. The following old exploit was released on March 14, 2015: [https://github.com/yellows8/oot3dhax].
| None
| App: Initial version. System: [[10.6.0-31]].
| March 11, 2015
| Around October 22, 2012
| [[User:Yellows8|Yellows8]]
|-
| Super Smash Bros 3DS
| Buffer overflow in local-multiplayer beacon handling.
| See [[smashbroshax|here]].
| App: v1.1.3
| See [[smashbroshax|here]]. System: [[10.3.0-28]].
| Time of exploit release.
| See [[smashbroshax|here]].
| [[User:Yellows8|Yellows8]]
|-
| Pokemon Super Mystery Dungeon
| Heap overflow within linear memory via unchecked save file length
| Pokemon Super Mystery Dungeon uses zlib compression for most of its save files, possibly due to the save files being larger than it's predecessor, Gates to Infinity. When a save file is being prepared to be loaded and read from, only a 0x32000 large buffer is allocated for file reading, and a 0x3e800-large buffer for decompression is also allocated before the file is read. However, the game does not limit the size of the file read to this allocation bound, allowing for the file to overflow into the linear memory heap and into the next allocation. Since Pokemon Super Mystery Dungeon stores allocation memchunks directly before the allocation, overwriting the next memchunk with a corrupted one allows for arbitrary writes of linear heap pointers when the next buffer is allocated or arbitrary writes of any pointer within writable memory when the corrupted buffer is freed.
| None
| [[10.7.0-32]].
| Time of exploit release.
| April 14, 2016
| [[User:Shinyquagsire23|Shiny Quagsire]]
|-
| VVVVVV
| Buffer overflow in XML save file array parsing
| VVVVVV utilizes several XML files (renamed with a .vvv extension) to store level save data, stats and settings. Within these XML files are several tags containing an array of data which, when parsed, is not properly checked to be of proper length for the tag being parsed from. This allows for an overflow of 16-bit array values from the location where the array is parsed. With unlock.vvv, XML data is parsed to the stack, and with level saves the heap. This allows for the pointer where the level save worldmap tag array should be parsed into to be overwritten with a stack address, allowing for ROP from within the XML array parsing function on the next level load.
| None
| [[10.7.0-32]].
| Time of exploit release.
| April 25, 2016
| [[User:Shinyquagsire23|Shiny Quagsire]]
|-
| Citizens of Earth
| Save file read stack smash
| Citizens of Earth also uses "XML" files for saves, which are actually entirely binary data (not XML at all) with no checksums. These files are read from the filesystem on to a fixed size stack buffer which leads to an incredibly trivial stack smash. When using the autosave slot for this, the save is parsed when the user selects "continue". When using one of the dedicated save slots (1-3), the save is parsed shortly after the company splash screens fade. Note that the save is read quite high (descending) on the stack - when exploiting this, one would likely need to move SP due to almost instantly overflowing the physical stack.
| None
| [[10.7.0-32]].
| Time of exploit release.
| May 5, 2016
| [[User:Dazzozo|Dazzozo]]
|-
| SmileBASIC 3.x
| Poor parameter validation on "BGSCREEN" command
| The SmileBASIC "BGSCREEN" command's second parameter is not properly validated as being within range. As a result, one can set the screen size to an absurdly large value. This means that the "BGGET" and "BGPUT" commands can then be used on out-of-range values to read and write a significant chunk of the interpreter's address space.
With a series of carefully-designed BGPUT commands, one can build a ROP chain and cause it to be executed.
| None
| App: 3.31.
System: [[11.0.0-33]].
| July 20, 2016
| Around June 26, 2016
| slackerSnail, 12Me12, incvoid
Weaponized by MrNbaYoh and [[User:Plutooo|plutoo]].
|}

==Useless crashes / applications which were fuzzed==
* Pushmo (3DSWare), QR codes: level name is properly limited to 16 characters, game doesn't crash with a longer name. The only possible crashes are triggered by out-of-bounds array index values, these crashes are not exploitable due to the index value being 8bit.

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

* "The Legend of Zelda: A Link Between Worlds" and "The Legend of Zelda: Tri Force Heroes": these games don't crash at all when the entire save-file(minus constant header data) is overwritten with /dev/random output / 0xFF-bytes. All of the CRC32s were updated for this of course.

* Pokemon Mystery Dungeon: Gates to Infinity has the same unchecked file bounds as Pokemon Super Mystery Dungeon, however since save compression was introduced in Pokemon Super Mystery Dungeon, it only allocates one buffer within the application heap instead of several within the linear heap, resulting in nothing to corrupt or overwrite even if the file's length is extended past it's allocation.

* "Kid Icarus: Uprising": Overwriting the entire savedata results in various crashes, nothing useful.

* Savedata/extdata for "Super Smash Bros 3DS": Overwriting the various files stored under savedata/extdata results in useless crashes.

* "StarFox 64 3D": Doesn't crash at all with the entire savedata overwritten.

* "Frogger 3D": Overwriting a savefile with random-data results in *nothing* crashing.

* "Mutant Mudds": Overwriting the savefile with anything else than 0x00 results in the console rebooting

* "Animal Crossing: New Leaf": Creating a QR code from random data results in a valid QR code and a random design.

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

* Football Up Online / Soccer Up Online and Football Up 3D / Soccer Up 3D crash when teamname(UTF-16) length = 0x48 AND 0x20 null bytes are removed after just the name or if teamname length is way longer than 0x48.

=System applications=
{| class="wikitable" border="1"
|-
! Summary
! Description
! Fixed in version
! Last version this flaw was checked for
! Timeframe this was discovered
! Discovered by
|-
| 3DS [[System Settings]] DS profile string stack-smash
| Too long or corrupted strings (01Ah 2 Nickname length in characters 050h 2 Message length in characters) in the NVRAM DS user settings (System Settings->Other Settings->Profile->Nintendo DS Profile) cause it to crash in 3DS-mode due to a stack-smash. The DSi is not vulnerable to this, DSi launcher(menu) and DSi System Settings will reset the NVRAM user-settings if the length field values are too long(same result as when the CRCs are invalid). TWL_FIRM also resets the NVRAM user-settings when the string-length(s) are too long.
| [[7.0.0-13]]
| [[7.0.0-13]]
| 2012
| [[User:Ichfly|Ichfly]]
|}

=System applets=
{| class="wikitable" border="1"
|-
! Summary
! Description
! Fixed in version
! Last version this flaw was checked for
! Introduced with version
! Timeframe info related to this was added to wiki
! Timeframe this was discovered
! Discovered by
|-
| [[Home Menu]] [[System_SaveData|NAND-savedata]] Launcher.dat icons
| The homemenu code processing the titleid list @ launcherdat+8 copies those titleIDs to another buffer, where the offset relative to that buffer is calculated using the corresponding s8/s16 entries. Those two values are not range checked at all. Hence, one can use this to write u64(s) with arbitrary values to before/after this allocated output buffer. See [[Home_Menu|here]] regarding Launcher.dat structure.

This can be exploited(with Launcher.dat loading at startup at least) by using a s16 for the icon entry with value 0xFFEC(-20)(and perhaps more icons with similar s16 values to write multiple u64s). The result is that the u64 value is written to outbuf-0xA0, which overwrites object+0(vtable) and object+4(doesn't matter here) for an object that gets used a bit after the vulnerable function triggers. The low 32bits of the u64 can then be set to the address of controlled memory(either outbuf in regular heap or the entire launcherdat buffer in linearmem), for use as a fake vtable in order to get control of PC. From there one can begin ROP via vtable funcptrs to do a stack-pivot(r4=objectaddr at the time the above object gets used).

Originally this vuln could only be triggered via Launcher.dat at Home Menu startup, right after Launcher.dat gets loaded + memory gets allocated, once the file-format version code is finished running. Starting with v9.6 this can be triggered when loading layouts from SD extdata as well. The vuln itself triggers before the layout data is written to Launcher.dat, but it doesn't seem to be possible to overwrite anything which actually gets used before the function which writes Launcher.dat into the layout gets called.

Home Menu has some sort of fail-safe system(or at least on v9.7) when Home Menu crashes due to Launcher.dat(this also applies for other things with Home Menu): after crashing once, Home Menu resets Launcher.dat to a state where it no longer crashes anymore. However, note that any exploits using this which hang/etc without crashing will still brick the system. '''Hence, attempting anything with this on physnand without hw-nand-access isn't really recommended.'''
| None
| [[10.3.0-28|10.3.0-X]]
|
|
| May 14, 2015
| [[User:Yellows8|Yellows8]]
|-
| [[Home Menu]] theme-data decompression buffer overflow ([[menuhax|themehax]])
| The only func-call size parameter used by the theme decompression function is one for the compressed size, none for the decompressed size. The decompressed-size value from the LZ header is used by this function to check when to stop decompressing, but this function itself has nothing to verify the decompressed_size with. The code calling this function does not check or even use the decompressed size from the header either.

This function is separate from the rest of the Home Menu code: the function used for decompressing themes is *only* used for decompressing themes, nothing else. There's a separate decompression function in Home Menu used for decompressing everything else.

That other decompression function in Home Menu handles decompression size properly(decompressed size check for max buffer size is done by code calling the other function, not in the function itself). Unlike the other function, the theme function supports multiple LZ algorithms, but the one which actually gets used in official themes is the same one supported by the other function anyway.

See also [[menuhax|here]].

With [[10.2.0-28|10.2.0-X]] Home Menu, the only code change was that the following was added right after theme-load and before actual decompression: "if(<get_lzheader_decompressed_size>(compressed_buf) > 0x150000)<exit>;". This fixed the vuln.
| [[10.2.0-28|10.2.0-X]]
| [[10.2.0-28|10.2.0-X]]
| <Old3DS/New3DS version which added initial theme support>
|
| December 22, 2014
| [[User:Yellows8|Yellows8]], [[User:Myria|Myria]] independently (~spring 2015)
|-
| [[Home Menu]] shuffle body-data buffer overflow ([[menuhax|shufflehax]])
| See [[menuhax|here]].
| [[10.6.0-31|10.6.0-X]]
| [[10.6.0-31|10.6.0-X]]
| [[9.3.0-21|9.3.0-X]]
|
| January 3, 2015
| [[User:Yellows8|Yellows8]]
|-
| [[Home Menu]] extdata SaveData.dat loading buffer overflow
| ''This was not tested on hardware.''

The extdata SaveData.dat file-reading code allocates a fixed-size heap buffer for the expected SaveData.dat filesize, then reads the filedata into this buffer using the actual FS filesize. Before v5.0 the filesize used here wasn't validated, hence if the filesize is larger than alloc_size a buffer overflow would occur. ''After'' doing the file-read it does validate that the actual_readsize matches the alloc_size, but at this point the buffer overflow has already occurred.

It's unknown whether v5.0 had similar changes for other extdata file-loading code.
| [[5.0.0-11|5.0.0-X]]
|
| [[2.0.0-2|2.0.0-X]]
| June 9, 2016
| June 9, 2016
| [[User:Yellows8|Yellows8]]
|-
| Webkit/web-browser bugs
| spider has had at least three different code-execution exploits. Majority of them are use-after-free issues. See also [[browserhax|here]].
|
|
|
| 2013?
|
| A lot of people.
|-
| Old3DS/New3DS [[Internet_Browser|Browser-version-check]] bypass
| When the browser-version-check code runs where the savedata for it was never initialized(such as when the user used the "Initialize savedata" option), it will use base_timestamp=0 instead of the timestamp loaded from savedata. This is then used with "if(cur_timestamp - base_timestamp >= <24h timestamp>){Run browser-version-check HTTPS request code}".
Hence, if the savedata was just initialized, and if the system datetime is set to before January 2, 2000, the browser-version-check will be skipped. This includes January 1, 2000, 00:00, because that's the epoch(timestamp value 0x0) used with this timestamp.

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

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

==Useless crashes==
Old3DS system web-browser:
* 2^32 characters long string(''finally'' fixed with v10.6): this is similar to the vulnerability fixed [http://git.chromium.org/gitweb/?p=external/Webkit.git;a=commitdiff;h=ec471f16fbd1f879cb631f9b022fd16acd75f4d4 here], concat-large-strings-crash2.html triggers a crash which is about the same as the one triggered by a 2^32 string. Most of the time this vulnerability will cause a memory page permissions fault, since the WebKit code attempts to copy the string text data to the output buffer located in read-only [[CRO0|CRO]] heap memory. The only difference between a crash triggered by a 2^32 string and the concat-large-strings-crash2.html crash is at the former copies the string data using the original string length(like 1 text character for "x", 4 for "xxxx") while the latter attempts to copy >12MB. In some ''very'' rare cases a thread separate from the string data-copy thread will crash, this might be exploitable. However, this is mostly useless since it rarely crashes this way.

* Trying to directly load a page via the browser "URL" option with [https://github.com/yellows8/3ds_browserhax_common webkitdebug] setup, causes a crash to trigger in oss.cro due to an use-after-free being caught with webkitdebug. This is presumably some sort of realloc() issue in the libcurl version used by the <={v10.2-v10.3} browser. This happens with *every* *single* *page* one tries to load via the "URL" option, but not when loading links on the current page, hence this is probably useless. A different use-after-free with realloc triggers with loading any page at all regardless of method too(libcurl probably).

* This WebKit build has ''a lot'' of crash-trigger bugs that only happen with [https://github.com/yellows8/3ds_browserhax_common webkitdebug] completely setup(addr accesses near 0x0), with ''just'' trying to load any page at all.

Homebrew Exploits

2016-07-17T22:22:41Z

Shinyquagsire23: Ooh, it's my turn to edit it out. (Probably the wrong page for this since it isn't an exploit)

==Standalone Homebrew Launcher Exploits==
The following homebrew exploits can be executed on a previously un-exploited system.

{| class="wikitable" border="1"
|-
! Works on latest fw
! Name
! Supported firmwares
! Requirements
! Author
! Install
|-
| style="background: salmon" | No
| [[ninjhax|Ninjhax 1.1b]]
| From '''4.0.0-7''' up to and including '''9.2.0-20'''.
| A cartridge or eShop version (JPN-only) of "Cubic Ninja".
| smea
| [http://smealum.net/ninjhax/ Install]
|-
| style="background: orange" | No; needs update.
| [[ninjhax|Ninjhax 2.x]]
| From '''9.0.0-7''' up to and including '''10.7.0-32'''.
| A cartridge or eShop version (JPN-only) of "Cubic Ninja". (note that this can be used on 11.0.0-33, but the savegame cannot be installed via the QR scanner, due to httpc access being revoked)
| smea
| [https://smealum.github.io/ninjhax2/ Install]
|-
| style="background: lightgreen" | Yes
| [http://plutooo.github.io/freakyhax/ freakyhax]
| From '''9.0.0-7''' up to and including '''11.0.0-33'''.
| A cartridge or eShop version (USA/EUR/JAP) of "Freakyform Deluxe".
| plutoo
| [http://plutooo.github.io/freakyhax/ Install]
|-
| style="background: lightgreen" | Yes
| [[smashbroshax|smashbroshax]] (beaconhax)
| (New 3DS only) From '''9.0.0-X''' up to and including '''11.0.0-33'''.
| Super Smash Bros 3DS (full-game) and a way to broadcast raw wifi beacons. The demo (prior to the updated November 2015 [https://github.com/yellows8/3ds_smashbroshax version]) isn't usable with the *hax payloads. Game-version v1.1.3 fixed the vuln used with this, see the repo for a workaround for that.
| [[User:Yellows8|Yellows8]]
| [https://github.com/yellows8/3ds_smashbroshax Install]
|-
| style="background: salmon" | No
| [[browserhax]]
| (Old 3DS) From '''9.0.0-16''' to '''9.5.0-22''', '''9.5.0-23''' to '''9.8.0-25''', '''9.9.0-26''' to '''10.1.0-27''', '''10.2.0-28''' to '''10.5.0-30'''

(New 3DS) From '''9.0.0-20''' to '''9.2.0-20''', '''9.3.0-21''' to '''9.5.0-23''', '''9.6.0-24''' to '''9.8.0-25''', '''9.9.0-26''' to '''10.1.0-27''', '''10.2.0-28''' to '''10.5.0-30'''

Note that the browser-version-check bypass is only usable prior to [[10.7.0-32]].
| An USA, EUR, or JPN system.
| [[User:Yellows8|Yellows8]]
| [http://yls8.mtheall.com/3dsbrowserhax.php Install]
|-
| style="background: lightgreen" | Yes
| [http://mrnbayoh.github.io/basicsploit/ BASICSploit]
| From '''9.0.0-7''' up to and including '''11.0.0-33'''
| SmileBASIC (USA only, JPN to be supported soon.) downloaded from the eShop. This vuln is not yet fixed as of v3.3.1.
| MrNbaYoh
| [http://mrnbayoh.github.io/basicsploit/ Install]
|}

Note that ninjhax 1.x is still not obsolete. Even though ninjhax 2.x can be run on 9.3+, this was made possible (amongst other things) by sacrificing the memory remapping exploit used in ninjhax 1.x (rohax). Therefore, things like JIT engines for emulators can only be supported on ninjhax 1.x. Furthermore, ninjhax 2.x does not run on system versions below 9.0.0-X, while ninjhax 1.x does.

==Secondary Exploits==
Installation of these exploits requires a previously exploited system to install. After installation, they can be used on their own.

{| class="wikitable" border="1"
! Works on latest fw
! Name
! Supported firmwares
! Requirements
! Author
! Install
|-
| style="background: salmon" | No
| [[ironhax]]
| From '''9.5.0-X''' up to and including '''10.3.0-X''', for '''X''' up to and including 28.
| A copy of "Ironfall: Invasion" downloaded from eShop before August 11th, 2015. Note the updated version that was released on October 13th, 2015 is not supported.
| smea
| [http://smealum.github.io/3ds/ Install]
|-
| style="background: lightgreen" | Yes
| [https://github.com/yellows8/oot3dhax oot3dhax]
| From '''9.0.0-X''' up to and including '''11.0.0-X''', for '''X''' up to and including 33.
| A gamecard or eShop-install of Legend of Zelda: Ocarina of Time 3D. Besides using the installer app, writing raw saveimages with a save dongle for example is another option. Due to lack of free space with the size of the *hax payload, the only save-slot that can exist in the *gamecard* savedata is the oot3dhax save-slot.
| Yellows8 / smea et al.
| See [https://smealum.github.io/3ds/ here].
|-
| style="background: salmon" | No
| [[menuhax]]
| From '''9.0.0-X''' up to and including '''10.5.0-X''', for '''X''' up to and including 30.
|
| [[User:Yellows8|Yellows8]]
| [https://github.com/yellows8/3ds_homemenuhax/releases Download]
|-
| style="background: lightgreen" | Yes
| [https://github.com/shinyquagsire23/supermysterychunkhax supermysterychunkhax]
| From '''9.9.0-X''' (USA/JPN) / '''10.2.0-X''' (EUR) up to and including '''11.0.0-X''', for '''X''' up to and including 33.
| A gamecard or eShop-install of Pokémon Super Mystery Dungeon.
| Shiny Quagsire / SALT team
| [https://smd.salthax.org/ Install].
|-
| style="background: lightgreen" | Yes
| [https://github.com/shinyquagsire23/v_hax (v*)hax]
| From '''9.0.0-X''' up to and including '''11.0.0-X''', for '''X''' up to and including 33.
Note that '''9.0.0-X''' is only required for the Homebrew Launcher - the game itself only requires '''2.1.0-X''' for primitive userland code execution.
| A copy of VVVVVV downloaded after March 2012 (v1)
| Shiny Quagsire / SALT team
| [https://vvvvvv.salthax.org/ Install].
|-
| style="background: lightgreen" | Yes
| [https://github.com/Dazzozo/humblehax humblehax]
| From '''9.0.0-X''' (USA/EUR) up to and including '''11.0.0-X''', for '''X''' up to and including 33.
| An eShop-install of Citizens of Earth, featured in the Humble "Friends of Nintendo" Bundle.
| Dazzozo / SALT team
| [https://citizens.salthax.org/ Install].
|-
| style="background: lightgreen" | Yes
| [http://mrnbayoh.github.io/basehaxx/ basehaxx]
| From '''9.0.0-X''' up to and including '''11.0.0-X''', for '''X''' up to and including 33.
| A gamecard or eShop-install of Pokémon Omega Ruby / Alpha Sapphire.
| MrNbaYoh
| [http://mrnbayoh.github.io/basehaxx/ install]
|}

==Exploits without Homebrew Launcher (Not recommended)==

'''Warning:''' The following exploits can run code, but are missing a 3DSX launcher. They cannot launch any homebrew in the 3DSX format.

{| class="wikitable" border="1"
|-
! Works on latest fw
! Name
! Supported firmwares
! Requirements
! Author
! Install
|-
| style="background: salmon" | No
| [[browserhax]] (Without the loader in the 3ds_browserhax_common repo)
| (Old3DS) From '''2.1.0-4''' to '''3.0.0-6''', '''4.0.0-7''' to '''4.5.0-10''', '''5.0.0-11''' to '''7.0.0-13''', '''7.1.0-16''' to '''9.5.0-22''', '''9.5.0-23''' to '''9.8.0-25''', '''9.9.0-26''' to '''10.1.0-27''', '''10.2.0-28''' to '''10.5.0-30'''

(New3DS) From '''9.0.0-20''' to '''9.2.0-20''', '''9.3.0-21''' to '''9.5.0-23''', '''9.6.0-24''' to '''9.8.0-25''', '''9.9.0-26''' to '''10.1.0-27''', '''10.2.0-28''' to '''10.5.0-30'''

Note that the browser-version-check bypass is only usable prior to [[10.7.0-32]].
| An USA, EUR, or JPN system.
| [[User:Yellows8|Yellows8]]
| [[browserhax|Install]]
|}

==Previous Exploits==
'''Warning:''' These exploits '''do not work'''. They are exploits which no longer function at all, regardless of software or firmware revision.
{| class="wikitable" border="1"
! Works on latest fw
! Name
! Supported firmwares
! Requirements
! Author
! Install
|-
| style="background: salmon" | No
| [[tubehax|Tubehax]]
| None. '''Was''': From '''9.0.0-X''' up to and including '''10.1.0-X''', for '''X''' up to and including 27.
| The YouTube application and an Internet connection. As of October 15, 2015, this is no longer usable due to an update being released which fixes the vuln used by tubehax + app update being forced(see [[YouTube|here]]).
| smea
| [http://smealum.github.io/3ds/ Install]
|}

==Other Homebrew Loaders==
The [https://github.com/yellows8/hblauncher_loader hblauncher_loader] title can be used when running under modded-FIRM which allows running unsigned titles, to boot the *hax payloads.

==Sysmodule Exploits==
This section is for system-module exploits, which can be run from the *hax payloads.

{| class="wikitable" border="1"
! Works on latest fw
! Name
! Supported firmwares
! Requirements
! Author
|-
| Yes, that's not the intended default use however.
| [https://github.com/yellows8/ctr-httpwn/releases ctr-httpwn]
| From '''9.6.0-X''' up to and including '''11.0.0-X'''.
| None
| [[User:Yellows8|Yellows8]]
|}

==WebKit vuln testing==
See [https://github.com/yellows8/3ds_browserhax_common/issues/28 here].

Homebrew Exploits

2016-04-30T22:29:02Z

Shinyquagsire23:

==Standalone Homebrew Launcher Exploits==
The following homebrew exploits can be executed on a previously un-exploited system.

{| class="wikitable" border="1"
|-
! Works on latest fw
! Name
! Supported firmwares
! Requirements
! Author
! Install
|-
| style="background: salmon" | No
| [[ninjhax|Ninjhax 1.1b]]
| From '''4.0.0-7''' up to and including '''9.2.0-20'''.
| A cartridge or eShop version (JPN-only) of "Cubic Ninja".
| smea
| [http://smealum.net/ninjhax/ Install]
|-
| style="background: lightgreen" | Yes
| [[ninjhax|Ninjhax 2.5]]
| From '''9.0.0-7''' up to and including '''10.7.0-32'''.
| A cartridge or eShop version (JPN-only) of "Cubic Ninja".
| smea
| [https://smealum.github.io/ninjhax2/ Install]
|-
| style="background: lightgreen" | Yes
| [[smashbroshax|smashbroshax]] (beaconhax)
| (New 3DS only) From '''9.0.0-X''' up to and including '''10.7.0-32'''.
| Super Smash Bros 3DS (full-game) and a way to broadcast raw wifi beacons. The demo(prior to the updated November 2015 [https://github.com/yellows8/3ds_smashbroshax version]) isn't usable with the *hax payloads. Game-version v1.1.3 fixed the vuln used with this, see the repo for a workaround for that.
| [[User:Yellows8|Yellows8]]
| [https://github.com/yellows8/3ds_smashbroshax Install]
|-
| style="background: salmon" | No
| [[browserhax]]
| (Old 3DS) From '''9.0.0-16''' to '''9.5.0-22''', '''9.5.0-23''' to '''9.8.0-25''', '''9.9.0-26''' to '''10.1.0-27''', '''10.2.0-28''' to '''10.5.0-30'''

(New 3DS) From '''9.0.0-20''' to '''9.2.0-20''', '''9.3.0-21''' to '''9.5.0-23''', '''9.6.0-24''' to '''9.8.0-25''', '''9.9.0-26''' to '''10.1.0-27''', '''10.2.0-28''' to '''10.5.0-30'''

Note that the browser-version-check bypass is only usable prior to [[10.7.0-32]].
| An USA, EUR, or JPN system.
| [[User:Yellows8|Yellows8]]
| [http://yls8.mtheall.com/3dsbrowserhax.php Install]
|}

Note that ninjhax 1.x is still not obsolete. Even though ninjhax 2.x can be run on 9.3+, this was made possible (amongst other things) by sacrificing the memory remapping exploit used in ninjhax 1.x (rohax). Therefore, things like JIT engines for emulators can only be supported on ninjhax 1.x. Furthermore, ninjhax 2.x does not run on system versions below 9.0.0-X, while ninjhax 1.x does.

==Secondary Exploits==
Installation of these exploits requires a previously exploited system to install. After installation, they can be used on their own.

{| class="wikitable" border="1"
! Works on latest fw
! Name
! Supported firmwares
! Requirements
! Author
! Install
|-
| style="background: salmon" | No
| [[ironhax]]
| From '''9.5.0-X''' up to and including '''10.3.0-X''', for '''X''' up to and including 28.
| A copy of "Ironfall: Invasion" downloaded from eShop before August 11th, 2015. Note the updated version that was released on October 13th, 2015 is not supported.
| smea
| [http://smealum.github.io/3ds/ Install]
|-
| style="background: lightgreen" | Yes
| [https://github.com/yellows8/oot3dhax oot3dhax]
| From '''9.0.0-X''' up to and including '''10.7.0-X''', for '''X''' up to and including 32.
| A gamecard or eShop-install of Legend of Zelda: Ocarina of Time 3D. Besides using the installer app, writing raw saveimages with a save dongle for example is another option. Due to lack of free space with the size of the *hax payload, the only save-slot that can exist in the *gamecard* savedata is the oot3dhax save-slot.
| Yellows8 / smea et al.
| See [https://smealum.github.io/3ds/ here].
|-
| style="background: salmon" | No
| [[menuhax]]
| From '''9.0.0-X''' up to and including '''10.5.0-X''', for '''X''' up to and including 30.
|
| [[User:Yellows8|Yellows8]]
| [https://github.com/yellows8/3ds_homemenuhax/releases Download]
|-
| style="background: lightgreen" | Yes
| [https://github.com/shinyquagsire23/supermysterychunkhax supermysterychunkhax]
| From '''9.9.0-X''' (USA/JPN) / '''10.2.0-X''' (EUR) up to and including '''10.7.0-X''', for '''X''' up to and including 32.
| A gamecard or eShop-install of Pokémon Super Mystery Dungeon.
| Shiny Quagsire / SALT team
| [https://smd.salthax.org/ Install].
|-
| style="background: lightgreen" | Yes
| [https://github.com/shinyquagsire23/v_hax (v*)hax]
| From '''9.0.0-X''' up to and including '''10.7.0-X''', for '''X''' up to and including 32.
| A copy of VVVVVV downloaded after March 2012 (v1)
| Shiny Quagsire / SALT team
| [https://vvvvvv.salthax.org/ Install].
|}

==Exploits without Homebrew Launcher (Not recommended)==

'''Warning:''' The following exploits can run code, but are missing a 3DSX launcher. They cannot launch any homebrew in the 3DSX format.

{| class="wikitable" border="1"
|-
! Works on latest fw
! Name
! Supported firmwares
! Requirements
! Author
! Install
|-
| style="background: salmon" | No
| [[browserhax]] (Without the loader in the 3ds_browserhax_common repo)
| (Old3DS) From '''2.1.0-4''' to '''3.0.0-6''', '''4.0.0-7''' to '''4.5.0-10''', '''5.0.0-11''' to '''7.0.0-13''', '''7.1.0-16''' to '''9.5.0-22''', '''9.5.0-23''' to '''9.8.0-25''', '''9.9.0-26''' to '''10.1.0-27''', '''10.2.0-28''' to '''10.5.0-30'''

(New3DS) From '''9.0.0-20''' to '''9.2.0-20''', '''9.3.0-21''' to '''9.5.0-23''', '''9.6.0-24''' to '''9.8.0-25''', '''9.9.0-26''' to '''10.1.0-27''', '''10.2.0-28''' to '''10.5.0-30'''

Note that the browser-version-check bypass is only usable prior to [[10.7.0-32]].
| An USA, EUR, or JPN system.
| [[User:Yellows8|Yellows8]]
| [[browserhax|Install]]
|}

==Previous Exploits==
'''Warning:''' These exploits '''do not work'''. They are exploits which no longer function at all, regardless of software or firmware revision.
{| class="wikitable" border="1"
! Works on latest fw
! Name
! Supported firmwares
! Requirements
! Author
! Install
|-
| style="background: salmon" | No
| [[tubehax|Tubehax]]
| None. '''Was''': From '''9.0.0-X''' up to and including '''10.1.0-X''', for '''X''' up to and including 27.
| The YouTube application and an Internet connection. As of October 15, 2015, this is no longer usable due to an update being released which fixes the vuln used by tubehax + app update being forced(see [[YouTube|here]]).
| smea
| [http://smealum.github.io/3ds/ Install]
|}

==Other Homebrew Loaders==
The [https://github.com/yellows8/hblauncher_loader hblauncher_loader] title can be used when running under modded-FIRM which allows running unsigned titles, to boot the *hax payloads.

==Sysmodule Exploits==
This section is for system-module exploits, which can be run from the *hax payloads.

{| class="wikitable" border="1"
! Works on latest fw
! Name
! Supported firmwares
! Requirements
! Author
|-
| Yes, that's not the intended default use however.
| [https://github.com/yellows8/ctr-httpwn/releases ctr-httpwn]
| From '''9.6.0-X''' up to and including '''10.7.0-X''', for '''X''' up to and including 32.
| None
| [[User:Yellows8|Yellows8]]
|}

==WebKit vuln testing==
See [https://github.com/yellows8/3ds_browserhax_common/issues/28 here].

3DS Userland Flaws

2016-04-30T20:40:47Z

Shinyquagsire23: VVVVVV

This page lists vulnerabilities / exploits for 3DS applications and applets. Exploiting these initially results in ROP, from that ROP one can then for example try exploiting [[3DS_System_Flaws|system]] flaw(s).

=Non-system applications=
{| class="wikitable" border="1"
|-
! Application name
! Summary
! Description
! Fixed in app/system version
! Last app/system version this flaw was checked for
! Timeframe info related to this was added to wiki
! Timeframe this vuln was discovered
! Vuln discovered by
|-
| Cubic Ninja
| Map-data stack smash
| See [[Ninjhax|here]] regarding Ninjhax.
| None
| App: Initial version. System: [[10.4.0-29]].
| Ninjhax release
| July 2014
| [[User:smea|smea]]
|-
| The Legend of Zelda: Ocarina of Time 3D
| UTF-16 name string buffer overflow via unchecked u8 length field
| The u8 at offset 0x2C in the savefile is the character-length of the UTF-16 string at offset 0x1C. When copying this string, it's essentially a memory-copy with lenval*2, not a string-copy. This can be used to trigger buffer overflows at various locations depending on the string length.
* When value is >=0x6E it crashes when saving the saveslot, this causes a stack-smash however it normally crashes before it returns from the function which had the stack-frame overwritten.
* With value >=0x9A, it crashes via stack-smash in-game once any dialogs are opened(touching buttons on the touch-screen can trigger it too).
* Length value>=0xCD causes a crash while loading the saveslot, via a heap buffer overflow. This buf-overflow overwrites a heap memchunk following the allocated buffer. When the first 16-bits overwriting that heap memchunk is not the memchunk magic-number(0x7373), the mem-alloc code will just return a NULL ptr which later results in a crash. When the magic-number is valid, the mem-alloc code will continue to attempt to parse the memchunk, which may crash depending on the data which overwrote the memchunk. This heap code is separate from the CTRSDK heap code. Exploiting this doesn't seem to be possible: since the heap code actually verifies that the magic-number for the next/prev memchunk ptrs are correct(unlike CTRSDK), it's not possible to change those ptrs to useful arbitrary addresses outside of savedata(like with triggering a write to a c++ object ptr which later is used with a vtable func-call, this is what one would do with CTRSDK heap here).

On March 11, 2015, an exploit using this vuln was released, that one was intended for warez/etc. The following exploit wasn't released before then mainly because doing so would (presumably) result in the vuln being fixed. The following old exploit was released on March 14, 2015: [https://github.com/yellows8/oot3dhax].
| None
| App: Initial version. System: [[10.6.0-31]].
| March 11, 2015
| Around October 22, 2012
| [[User:Yellows8|Yellows8]]
|-
| Super Smash Bros 3DS
| Buffer overflow in local-multiplayer beacon handling.
| See [[smashbroshax|here]].
| None
| See [[smashbroshax|here]]. System: [[10.3.0-28]].
| Time of exploit release.
| See [[smashbroshax|here]].
| [[User:Yellows8|Yellows8]]
|-
| Pokemon Super Mystery Dungeon
| Heap overflow within linear memory via unchecked save file length
| Pokemon Super Mystery Dungeon uses zlib compression for most of its save files, possibly due to the save files being larger than it's predecessor, Gates to Infinity. When a save file is being prepared to be loaded and read from, only a 0x32000 large buffer is allocated for file reading, and a 0x3e800-large buffer for decompression is also allocated before the file is read. However, the game does not limit the size of the file read to this allocation bound, allowing for the file to overflow into the linear memory heap and into the next allocation. Since Pokemon Super Mystery Dungeon stores allocation memchunks directly before the allocation, overwriting the next memchunk with a corrupted one allows for arbitrary writes of linear heap pointers when the next buffer is allocated or arbitrary writes of any pointer within writable memory when the corrupted buffer is freed.
| None
| [[10.7.0-32]].
| Time of exploit release.
| April 14, 2016
| [[User:Shinyquagsire23|Shiny Quagsire]]
|-
| VVVVVV
| Buffer overflow in XML save file array parsing
| VVVVVV utilizes several XML files (renamed with a .vvv extension) to store level save data, stats and settings. Within these XML files are several tags containing an array of data which, when parsed, is not properly checked to be of proper length for the tag being parsed from. This allows for an overflow of 16-bit array values from the location where the array is parsed. With unlock.vvv, XML data is parsed to the stack, and with level saves the heap. This allows for the pointer where the level save worldmap tag array should be parsed into to be overwritten with a stack address, allowing for ROP from within the XML array parsing function on the next level load.
| None
| [[10.7.0-32]].
| Time of exploit release.
| April 25, 2016
| [[User:Shinyquagsire23|Shiny Quagsire]]
|}

==Useless crashes / applications which were fuzzed==
* Pushmo (3DSWare), QR codes: level name is properly limited to 16 characters, game doesn't crash with a longer name. The only possible crashes are triggered by out-of-bounds array index values, these crashes are not exploitable due to the index value being 8bit.

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

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

* "The Legend of Zelda: A Link Between Worlds" and "The Legend of Zelda: Tri Force Heroes": these games don't crash at all when the entire save-file(minus constant header data) is overwritten with /dev/random output / 0xFF-bytes. All of the CRC32s were updated for this of course.

* Pokemon Mystery Dungeon: Gates to Infinity has the same unchecked file bounds as Pokemon Super Mystery Dungeon, however since save compression was introduced in Pokemon Super Mystery Dungeon, it only allocates one buffer within the application heap instead of several within the linear heap, resulting in nothing to corrupt or overwrite even if the file's length is extended past it's allocation.

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

* Football Up Online / Soccer Up Online and Football Up 3D / Soccer Up 3D crash when teamname(UTF-16) length = 0x48 AND 0x20 null bytes are removed after just the name or if teamname length is way longer than 0x48.

=System applications=
{| class="wikitable" border="1"
|-
! Summary
! Description
! Fixed in version
! Last version this flaw was checked for
! Timeframe this was discovered
! Discovered by
|-
| 3DS [[System Settings]] DS profile string stack-smash
| Too long or corrupted strings (01Ah 2 Nickname length in characters 050h 2 Message length in characters) in the NVRAM DS user settings (System Settings->Other Settings->Profile->Nintendo DS Profile) cause it to crash in 3DS-mode due to a stack-smash. The DSi is not vulnerable to this, DSi launcher(menu) and DSi System Settings will reset the NVRAM user-settings if the length field values are too long(same result as when the CRCs are invalid). TWL_FIRM also resets the NVRAM user-settings when the string-length(s) are too long.
| [[7.0.0-13]]
| [[7.0.0-13]]
| 2012
| [[User:Ichfly|Ichfly]]
|}

=System applets=
{| class="wikitable" border="1"
|-
! Summary
! Description
! Fixed in version
! Last version this flaw was checked for
! Timeframe info related to this was added to wiki
! Timeframe this was discovered
! Discovered by
|-
| [[Home Menu]] [[System_SaveData|NAND-savedata]] Launcher.dat icons
| The homemenu code processing the titleid list @ launcherdat+8 copies those titleIDs to another buffer, where the offset relative to that buffer is calculated using the corresponding s8/s16 entries. Those two values are not range checked at all. Hence, one can use this to write u64(s) with arbitrary values to before/after this allocated output buffer. See [[Home_Menu|here]] regarding Launcher.dat structure.

This can be exploited(with Launcher.dat loading at startup at least) by using a s16 for the icon entry with value 0xFFEC(-20)(and perhaps more icons with similar s16 values to write multiple u64s). The result is that the u64 value is written to outbuf-0xA0, which overwrites object+0(vtable) and object+4(doesn't matter here) for an object that gets used a bit after the vulnerable function triggers. The low 32bits of the u64 can then be set to the address of controlled memory(either outbuf in regular heap or the entire launcherdat buffer in linearmem), for use as a fake vtable in order to get control of PC. From there one can begin ROP via vtable funcptrs to do a stack-pivot(r4=objectaddr at the time the above object gets used).

Originally this vuln could only be triggered via Launcher.dat at Home Menu startup, right after Launcher.dat gets loaded + memory gets allocated, once the file-format version code is finished running. Starting with v9.6 this can be triggered when loading layouts from SD extdata as well. The vuln itself triggers before the layout data is written to Launcher.dat, but it doesn't seem to be possible to overwrite anything which actually gets used before the function which writes Launcher.dat into the layout gets called.

Home Menu has some sort of fail-safe system(or at least on v9.7) when Home Menu crashes due to Launcher.dat(this also applies for other things with Home Menu): after crashing once, Home Menu resets Launcher.dat to a state where it no longer crashes anymore. However, note that any exploits using this which hang/etc without crashing will still brick the system. '''Hence, attempting anything with this on physnand without hw-nand-access isn't really recommended.'''
| None
| [[10.3.0-28|10.3.0-X]]
|
| May 14, 2015
| [[User:Yellows8|Yellows8]]
|-
| [[Home Menu]] theme-data decompression buffer overflow ([[menuhax|themehax]])
| The only func-call size parameter used by the theme decompression function is one for the compressed size, none for the decompressed size. The decompressed-size value from the LZ header is used by this function to check when to stop decompressing, but this function itself has nothing to verify the decompressed_size with. The code calling this function does not check or even use the decompressed size from the header either.

This function is separate from the rest of the Home Menu code: the function used for decompressing themes is *only* used for decompressing themes, nothing else. There's a separate decompression function in Home Menu used for decompressing everything else.

That other decompression function in Home Menu handles decompression size properly(decompressed size check for max buffer size is done by code calling the other function, not in the function itself). Unlike the other function, the theme function supports multiple LZ algorithms, but the one which actually gets used in official themes is the same one supported by the other function anyway.

See also [[menuhax|here]].

With [[10.2.0-28|10.2.0-X]] Home Menu, the only code change was that the following was added right after theme-load and before actual decompression: "if(<get_lzheader_decompressed_size>(compressed_buf) > 0x150000)<exit>;". This fixed the vuln.
| [[10.2.0-28|10.2.0-X]]
| [[10.2.0-28|10.2.0-X]]
|
| December 22, 2014
| [[User:Yellows8|Yellows8]], [[User:Myria|Myria]] independently (~spring 2015)
|-
| [[Home Menu]] shuffle body-data buffer overflow ([[menuhax|shufflehax]])
| See [[menuhax|here]].
| [[10.6.0-31|10.6.0-X]]
| [[10.6.0-31|10.6.0-X]]
|
| January 3, 2015
| [[User:Yellows8|Yellows8]]
|-
| Webkit/web-browser bugs
| spider has had at least three different code-execution exploits. Majority of them are use-after-free issues. See also [[browserhax|here]].
|
|
| 2013?
|
| A lot of people.
|-
| Old3DS/New3DS [[Internet_Browser|Browser-version-check]] bypass
| When the browser-version-check code runs where the savedata for it was never initialized(such as when the user used the "Initialize savedata" option), it will use base_timestamp=0 instead of the timestamp loaded from savedata. This is then used with "if(cur_timestamp - base_timestamp >= <24h timestamp>){Run browser-version-check HTTPS request code}".
Hence, if the savedata was just initialized, and if the system datetime is set to before January 2, 2000, the browser-version-check will be skipped. This includes January 1, 2000, 00:00, because that's the epoch(timestamp value 0x0) used with this timestamp.

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

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

==Useless crashes==
Old3DS system web-browser:
* 2^32 characters long string(''finally'' fixed with v10.6): this is similar to the vulnerability fixed [http://git.chromium.org/gitweb/?p=external/Webkit.git;a=commitdiff;h=ec471f16fbd1f879cb631f9b022fd16acd75f4d4 here], concat-large-strings-crash2.html triggers a crash which is about the same as the one triggered by a 2^32 string. Most of the time this vulnerability will cause a memory page permissions fault, since the WebKit code attempts to copy the string text data to the output buffer located in read-only [[CRO0|CRO]] heap memory. The only difference between a crash triggered by a 2^32 string and the concat-large-strings-crash2.html crash is at the former copies the string data using the original string length(like 1 text character for "x", 4 for "xxxx") while the latter attempts to copy >12MB. In some ''very'' rare cases a thread separate from the string data-copy thread will crash, this might be exploitable. However, this is mostly useless since it rarely crashes this way.

* Trying to directly load a page via the browser "URL" option with [https://github.com/yellows8/3ds_browserhax_common webkitdebug] setup, causes a crash to trigger in oss.cro due to an use-after-free being caught with webkitdebug. This is presumably some sort of realloc() issue in the libcurl version used by the <={v10.2-v10.3} browser. This happens with *every* *single* *page* one tries to load via the "URL" option, but not when loading links on the current page, hence this is probably useless. A different use-after-free with realloc triggers with loading any page at all regardless of method too(libcurl probably).

* This WebKit build has ''a lot'' of crash-trigger bugs that only happen with [https://github.com/yellows8/3ds_browserhax_common webkitdebug] completely setup(addr accesses near 0x0), with ''just'' trying to load any page at all.

3DS Userland Flaws

2016-04-24T19:40:37Z

Shinyquagsire23: supermysterychunkhax and GTI investigated bounds

This page lists vulnerabilities / exploits for 3DS applications and applets. Exploiting these initially results in ROP, from that ROP one can then for example try exploiting [[3DS_System_Flaws|system]] flaw(s).

=Non-system applications=
{| class="wikitable" border="1"
|-
! Application name
! Summary
! Description
! Fixed in app/system version
! Last app/system version this flaw was checked for
! Timeframe info related to this was added to wiki
! Timeframe this vuln was discovered
! Vuln discovered by
|-
| Cubic Ninja
| Map-data stack smash
| See [[Ninjhax|here]] regarding Ninjhax.
| None
| App: Initial version. System: [[10.4.0-29]].
| Ninjhax release
| July 2014
| [[User:smea|smea]]
|-
| The Legend of Zelda: Ocarina of Time 3D
| UTF-16 name string buffer overflow via unchecked u8 length field
| The u8 at offset 0x2C in the savefile is the character-length of the UTF-16 string at offset 0x1C. When copying this string, it's essentially a memory-copy with lenval*2, not a string-copy. This can be used to trigger buffer overflows at various locations depending on the string length.
* When value is >=0x6E it crashes when saving the saveslot, this causes a stack-smash however it normally crashes before it returns from the function which had the stack-frame overwritten.
* With value >=0x9A, it crashes via stack-smash in-game once any dialogs are opened(touching buttons on the touch-screen can trigger it too).
* Length value>=0xCD causes a crash while loading the saveslot, via a heap buffer overflow. This buf-overflow overwrites a heap memchunk following the allocated buffer. When the first 16-bits overwriting that heap memchunk is not the memchunk magic-number(0x7373), the mem-alloc code will just return a NULL ptr which later results in a crash. When the magic-number is valid, the mem-alloc code will continue to attempt to parse the memchunk, which may crash depending on the data which overwrote the memchunk. This heap code is separate from the CTRSDK heap code. Exploiting this doesn't seem to be possible: since the heap code actually verifies that the magic-number for the next/prev memchunk ptrs are correct(unlike CTRSDK), it's not possible to change those ptrs to useful arbitrary addresses outside of savedata(like with triggering a write to a c++ object ptr which later is used with a vtable func-call, this is what one would do with CTRSDK heap here).

On March 11, 2015, an exploit using this vuln was released, that one was intended for warez/etc. The following exploit wasn't released before then mainly because doing so would (presumably) result in the vuln being fixed. The following old exploit was released on March 14, 2015: [https://github.com/yellows8/oot3dhax].
| None
| App: Initial version. System: [[10.6.0-31]].
| March 11, 2015
| Around October 22, 2012
| [[User:Yellows8|Yellows8]]
|-
| Super Smash Bros 3DS
| Buffer overflow in local-multiplayer beacon handling.
| See [[smashbroshax|here]].
| None
| See [[smashbroshax|here]]. System: [[10.3.0-28]].
| Time of exploit release.
| See [[smashbroshax|here]].
| [[User:Yellows8|Yellows8]]
|-
| Pokemon Super Mystery Dungeon
| Heap overflow within linear memory via unchecked save file length
| Pokemon Super Mystery Dungeon uses zlib compression for most of its save files, possibly due to the save files being larger than it's predecessor, Gates to Infinity. When a save file is being prepared to be loaded and read from, only a 0x32000 large buffer is allocated for file reading, and a 0x3e800-large buffer for decompression is also allocated before the file is read. However, the game does not limit the size of the file read to this allocation bound, allowing for the file to overflow into the linear memory heap and into the next allocation. Since Pokemon Super Mystery Dungeon stores allocation memchunks directly before the allocation, overwriting the next memchunk with a corrupted one allows for arbitrary writes of linear heap pointers when the next buffer is allocated or arbitrary writes of any pointer within writable memory when the corrupted buffer is freed.
| None
| [[10.7.0-32]].
| Time of exploit release.
| April 14, 2016
| [[User:Shinyquagsire23|Shiny Quagsire]]
|}

==Useless crashes / applications which were fuzzed==
* Pushmo (3DSWare), QR codes: level name is properly limited to 16 characters, game doesn't crash with a longer name. The only possible crashes are triggered by out-of-bounds array index values, these crashes are not exploitable due to the index value being 8bit.

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

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

* "The Legend of Zelda: A Link Between Worlds" and "The Legend of Zelda: Tri Force Heroes": these games don't crash at all when the entire save-file(minus constant header data) is overwritten with /dev/random output / 0xFF-bytes. All of the CRC32s were updated for this of course.

* Pokemon Mystery Dungeon: Gates to Infinity has the same unchecked file bounds as Pokemon Super Mystery Dungeon, however since save compression was introduced in Pokemon Super Mystery Dungeon, it only allocates one buffer within the application heap instead of several within the linear heap, resulting in nothing to corrupt or overwrite even if the file's length is extended past it's allocation.

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

* Football Up Online / Soccer Up Online and Football Up 3D / Soccer Up 3D crash when teamname(UTF-16) length = 0x48 AND 0x20 null bytes are removed after just the name or if teamname length is way longer than 0x48.

=System applications=
{| class="wikitable" border="1"
|-
! Summary
! Description
! Fixed in version
! Last version this flaw was checked for
! Timeframe this was discovered
! Discovered by
|-
| 3DS [[System Settings]] DS profile string stack-smash
| Too long or corrupted strings (01Ah 2 Nickname length in characters 050h 2 Message length in characters) in the NVRAM DS user settings (System Settings->Other Settings->Profile->Nintendo DS Profile) cause it to crash in 3DS-mode due to a stack-smash. The DSi is not vulnerable to this, DSi launcher(menu) and DSi System Settings will reset the NVRAM user-settings if the length field values are too long(same result as when the CRCs are invalid). TWL_FIRM also resets the NVRAM user-settings when the string-length(s) are too long.
| [[7.0.0-13]]
| [[7.0.0-13]]
| 2012
| [[User:Ichfly|Ichfly]]
|}

=System applets=
{| class="wikitable" border="1"
|-
! Summary
! Description
! Fixed in version
! Last version this flaw was checked for
! Timeframe info related to this was added to wiki
! Timeframe this was discovered
! Discovered by
|-
| [[Home Menu]] [[System_SaveData|NAND-savedata]] Launcher.dat icons
| The homemenu code processing the titleid list @ launcherdat+8 copies those titleIDs to another buffer, where the offset relative to that buffer is calculated using the corresponding s8/s16 entries. Those two values are not range checked at all. Hence, one can use this to write u64(s) with arbitrary values to before/after this allocated output buffer. See [[Home_Menu|here]] regarding Launcher.dat structure.

This can be exploited(with Launcher.dat loading at startup at least) by using a s16 for the icon entry with value 0xFFEC(-20)(and perhaps more icons with similar s16 values to write multiple u64s). The result is that the u64 value is written to outbuf-0xA0, which overwrites object+0(vtable) and object+4(doesn't matter here) for an object that gets used a bit after the vulnerable function triggers. The low 32bits of the u64 can then be set to the address of controlled memory(either outbuf in regular heap or the entire launcherdat buffer in linearmem), for use as a fake vtable in order to get control of PC. From there one can begin ROP via vtable funcptrs to do a stack-pivot(r4=objectaddr at the time the above object gets used).

Originally this vuln could only be triggered via Launcher.dat at Home Menu startup, right after Launcher.dat gets loaded + memory gets allocated, once the file-format version code is finished running. Starting with v9.6 this can be triggered when loading layouts from SD extdata as well. The vuln itself triggers before the layout data is written to Launcher.dat, but it doesn't seem to be possible to overwrite anything which actually gets used before the function which writes Launcher.dat into the layout gets called.

Home Menu has some sort of fail-safe system(or at least on v9.7) when Home Menu crashes due to Launcher.dat(this also applies for other things with Home Menu): after crashing once, Home Menu resets Launcher.dat to a state where it no longer crashes anymore. However, note that any exploits using this which hang/etc without crashing will still brick the system. '''Hence, attempting anything with this on physnand without hw-nand-access isn't really recommended.'''
| None
| [[10.3.0-28|10.3.0-X]]
|
| May 14, 2015
| [[User:Yellows8|Yellows8]]
|-
| [[Home Menu]] theme-data decompression buffer overflow ([[menuhax|themehax]])
| The only func-call size parameter used by the theme decompression function is one for the compressed size, none for the decompressed size. The decompressed-size value from the LZ header is used by this function to check when to stop decompressing, but this function itself has nothing to verify the decompressed_size with. The code calling this function does not check or even use the decompressed size from the header either.

This function is separate from the rest of the Home Menu code: the function used for decompressing themes is *only* used for decompressing themes, nothing else. There's a separate decompression function in Home Menu used for decompressing everything else.

That other decompression function in Home Menu handles decompression size properly(decompressed size check for max buffer size is done by code calling the other function, not in the function itself). Unlike the other function, the theme function supports multiple LZ algorithms, but the one which actually gets used in official themes is the same one supported by the other function anyway.

See also [[menuhax|here]].

With [[10.2.0-28|10.2.0-X]] Home Menu, the only code change was that the following was added right after theme-load and before actual decompression: "if(<get_lzheader_decompressed_size>(compressed_buf) > 0x150000)<exit>;". This fixed the vuln.
| [[10.2.0-28|10.2.0-X]]
| [[10.2.0-28|10.2.0-X]]
|
| December 22, 2014
| [[User:Yellows8|Yellows8]], [[User:Myria|Myria]] independently (~spring 2015)
|-
| [[Home Menu]] shuffle body-data buffer overflow ([[menuhax|shufflehax]])
| See [[menuhax|here]].
| [[10.6.0-31|10.6.0-X]]
| [[10.6.0-31|10.6.0-X]]
|
| January 3, 2015
| [[User:Yellows8|Yellows8]]
|-
| Webkit/web-browser bugs
| spider has had at least three different code-execution exploits. Majority of them are use-after-free issues. See also [[browserhax|here]].
|
|
| 2013?
|
| A lot of people.
|-
| Old3DS/New3DS [[Internet_Browser|Browser-version-check]] bypass
| When the browser-version-check code runs where the savedata for it was never initialized(such as when the user used the "Initialize savedata" option), it will use base_timestamp=0 instead of the timestamp loaded from savedata. This is then used with "if(cur_timestamp - base_timestamp >= <24h timestamp>){Run browser-version-check HTTPS request code}".
Hence, if the savedata was just initialized, and if the system datetime is set to before January 2, 2000, the browser-version-check will be skipped. This includes January 1, 2000, 00:00, because that's the epoch(timestamp value 0x0) used with this timestamp.

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

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

==Useless crashes==
Old3DS system web-browser:
* 2^32 characters long string(''finally'' fixed with v10.6): this is similar to the vulnerability fixed [http://git.chromium.org/gitweb/?p=external/Webkit.git;a=commitdiff;h=ec471f16fbd1f879cb631f9b022fd16acd75f4d4 here], concat-large-strings-crash2.html triggers a crash which is about the same as the one triggered by a 2^32 string. Most of the time this vulnerability will cause a memory page permissions fault, since the WebKit code attempts to copy the string text data to the output buffer located in read-only [[CRO0|CRO]] heap memory. The only difference between a crash triggered by a 2^32 string and the concat-large-strings-crash2.html crash is at the former copies the string data using the original string length(like 1 text character for "x", 4 for "xxxx") while the latter attempts to copy >12MB. In some ''very'' rare cases a thread separate from the string data-copy thread will crash, this might be exploitable. However, this is mostly useless since it rarely crashes this way.

* Trying to directly load a page via the browser "URL" option with [https://github.com/yellows8/3ds_browserhax_common webkitdebug] setup, causes a crash to trigger in oss.cro due to an use-after-free being caught with webkitdebug. This is presumably some sort of realloc() issue in the libcurl version used by the <={v10.2-v10.3} browser. This happens with *every* *single* *page* one tries to load via the "URL" option, but not when loading links on the current page, hence this is probably useless. A different use-after-free with realloc triggers with loading any page at all regardless of method too(libcurl probably).

* This WebKit build has ''a lot'' of crash-trigger bugs that only happen with [https://github.com/yellows8/3ds_browserhax_common webkitdebug] completely setup(addr accesses near 0x0), with ''just'' trying to load any page at all.

LCD Registers

2016-02-28T00:41:53Z

Shinyquagsire23: Extra bundle of registers and that seems to be it

Other registers that used to be documented on this page are now at [[GPU Registers]].

= Registers =
{| class="wikitable" border="1"
! NAME
! PHYSICAL ADDRESS
! PROCESS VIRTUAL ADDRESS
! KERNEL VIRTUAL ADDRESS
! WIDTH
|-
| Parallax barrier enable
| 0x10202000
| 0x1ED02000
| 0xFFFD6000
| 0x4
|-
| ?
| 0x10202004
| 0x1ED02004
| 0xFFFD6004
| 0x4
|-
| Top Screen [[#LCD Configuration|LCD Configuration]]
| 0x10202200
| 0x1ED02200
| 0xFFFD6200
| 0x600
|-
| Bottom Screen [[#LCD Configuration|LCD Configuration]]
| 0x10202A00
| 0x1ED02A00
| 0xFFFD6A00
| 0x600
|-
| ?
| 0x10203200
| 0x1ED03200
| 0xFFFD7200
| 0x40
|}

== LCD Configuration ==
{| class="wikitable" border="1"
! Offset
! Size
! Description
|-
| 0x00
| 0x4
| ?
|-
| 0x04
| 0x4
| [[#Fill Color|Fill Color]]
|-
| 0x10
| 0x4
| ?
|-
| 0x14
| 0x4
| ?
|-
| 0x18
| 0x4
| ?
|-
| 0x1C
| 0x4
| ?
|-
| 0x20
| 0x4
| ?
|-
| 0x24
| 0x4
| ?
|-
| 0x28
| 0x4
| ?
|-
| 0x2C
| 0x4
| ?
|-
| 0x30
| 0x4
| ?
|-
| 0x38
| 0x4
| ?
|-
| 0x3C
| 0x4
| ?
|-
| 0x40
| 0x4
| Backlight
|-
| 0x44
| 0x4
| ?
|-
| 0x60
| 0x4
| ?
|-
| 0x68
| 0x4
| ?
|-
| 0x70
| 0x4
| ?
|-
| 0x78
| 0x4
| ?
|-
| 0x80
| 0x4
| ?
|-
| 0x100
| 0x100
| LCD calibration data, pulled from nand:/ro/sys/HWCAL0.dat offset 0x77C. N3DS only(?)
|}

=== Fill Color ===
{| class="wikitable" border="1"
! Bit
! Description
|-
| 7-0
| Red component intensity
|-
| 15-8
| Green component intensity
|-
| 23-16
| Blue component intensity
|-
| 24
| Enable
|-
| 31-25
| ?
|}

When the enable bit is set, the specified solid color is displayed on the LCD instead of the framebuffer.

LCD Registers

2016-02-28T00:10:57Z

Shinyquagsire23: Width of LCD Config and HWCAL data.

Other registers that used to be documented on this page are now at [[GPU Registers]].

= Registers =
{| class="wikitable" border="1"
! NAME
! PHYSICAL ADDRESS
! PROCESS VIRTUAL ADDRESS
! KERNEL VIRTUAL ADDRESS
! WIDTH
|-
| ?
| 0x10202000
| 0x1ED02000
| 0xFFFD6000
| 0x4
|-
| ?
| 0x10202004
| 0x1ED02004
| 0xFFFD6004
| 0x4
|-
| Top Screen [[#LCD Configuration|LCD Configuration]]
| 0x10202200
| 0x1ED02200
| 0xFFFD6200
| 0x600
|-
| Bottom Screen [[#LCD Configuration|LCD Configuration]]
| 0x10202A00
| 0x1ED02A00
| 0xFFFD6A00
| 0x600
|}

== LCD Configuration ==
{| class="wikitable" border="1"
! Offset
! Size
! Description
|-
| 0x00
| 0x4
| ?
|-
| 0x04
| 0x4
| [[#Fill Color|Fill Color]]
|-
| 0x10
| 0x4
| ?
|-
| 0x14
| 0x4
| ?
|-
| 0x18
| 0x4
| ?
|-
| 0x1C
| 0x4
| ?
|-
| 0x20
| 0x4
| ?
|-
| 0x24
| 0x4
| ?
|-
| 0x28
| 0x4
| ?
|-
| 0x2C
| 0x4
| ?
|-
| 0x30
| 0x4
| ?
|-
| 0x38
| 0x4
| ?
|-
| 0x3C
| 0x4
| ?
|-
| 0x40
| 0x4
| Backlight
|-
| 0x44
| 0x4
| ?
|-
| 0x60
| 0x4
| ?
|-
| 0x68
| 0x4
| ?
|-
| 0x70
| 0x4
| ?
|-
| 0x78
| 0x4
| ?
|-
| 0x80
| 0x4
| ?
|-
| 0x100
| 0x100
| LCD calibration data, pulled from nand:/ro/sys/HWCAL0.dat offset 0x77C. N3DS only(?)
|}

=== Fill Color ===
{| class="wikitable" border="1"
! Bit
! Description
|-
| 7-0
| Red component intensity
|-
| 15-8
| Green component intensity
|-
| 23-16
| Blue component intensity
|-
| 24
| Enable
|-
| 31-25
| ?
|}

When the enable bit is set, the specified solid color is displayed on the LCD instead of the framebuffer.

I2C Registers

2016-02-24T02:25:06Z

Shinyquagsire23: MCU LCD state bitfield

= Registers =
{| class="wikitable" border="1"
! Old3DS
! Name
! Address
! Width
! Used by
|-
| style="background: green" | Yes
| I2C1_DATA
| 0x10161000
| 1
|
|-
| style="background: green" | Yes
| [[#I2C_CNT|I2C1_CNT]]
| 0x10161001
| 1
|
|-
| style="background: green" | Yes
| I2C1_CNTEX
| 0x10161002
| 2
|
|-
| style="background: green" | Yes
| I2C1_SCL
| 0x10161004
| 2
|
|-
| style="background: green" | Yes
| I2C2_DATA
| 0x10144000
| 1
|
|-
| style="background: green" | Yes
| [[#I2C_CNT|I2C2_CNT]]
| 0x10144001
| 1
|
|-
| style="background: green" | Yes
| I2C2_CNTEX
| 0x10144002
| 2
|
|-
| style="background: green" | Yes
| I2C2_SCL
| 0x10144004
| 2
|
|-
| style="background: green" | Yes
| I2C3_DATA
| 0x10148000
| 1
|
|-
| style="background: green" | Yes
| [[#I2C_CNT|I2C3_CNT]]
| 0x10148001
| 1
|
|-
| style="background: green" | Yes
| I2C3_CNTEX
| 0x10148002
| 2
|
|-
| style="background: green" | Yes
| I2C3_SCL
| 0x10148004
| 2
|
|}

== I2C_CNT ==
{| class="wikitable" border="1"
! BIT
! DESCRIPTION
|-
| 0
| Stop (0=No, 1=Stop/last byte)
|-
| 1
| Start (0=No, 1=Start/first byte)
|-
| 2
| Pause (0=Transfer Data, 1=Pause after Error, used with/after Stop)
|-
| 4
| Ack Flag (0=Error, 1=Okay) (For DataRead: W, for DataWrite: R)
|-
| 5
| Data Direction (0=Write, 1=Read)
|-
| 6
| Interrupt Enable (0=Disable, 1=Enable)
|-
| 7
| Start/busy (0=Ready, 1=Start/busy)
|}

= I2C Devices =
{| class="wikitable" border="1"
! [[I2C_Registers|Device id]]
! Device bus id
! Device Write Address
! Accessible via I2C [[I2C_Services|service]]
! Device description
|-
| 0
| 1
| 0x4a
| "i2c::MCU"
| Power management?(same device addr as the DSi power-management)
|-
| 1
| 1
| 0x7a
| "i2c::CAM"
| Camera0?(same dev-addr as DSi cam0)
|-
| 2
| 1
| 0x78
| "i2c::CAM"
| Camera1?(same dev-addr as DSi cam1)
|-
| 3
| 2
| 0x4a
| "i2c::MCU"
| MCU
|-
| 4
| 2
| 0x78
| "i2c::CAM"
| ?
|-
| 5
| 2
| 0x2c
| "i2c::LCD"
| ?
|-
| 6
| 2
| 0x2e
| "i2c::LCD"
| ?
|-
| 7
| 2
| 0x40
| "i2c::DEB"
| ?
|-
| 8
| 2
| 0x44
| "i2c::DEB"
| ?
|-
| 9
| 3
| 0xa6
| "i2c::HID"
| Unknown. The device table in I2C-module had the device address changed from 0xA6 to 0xD6 with [[8.0.0-18]].
|-
| 10
| 3
| 0xd0
| "i2c::HID"
| Gyroscope
|-
| 11
| 3
| 0xd2
| "i2c::HID"
| ?
|-
| 12
| 3
| 0xa4
| "i2c::HID"
| DebugPad
|-
| 13
| 3
| 0x9a
| "i2c::IR"
| IR
|-
| 14
| 3
| 0xa0
| "i2c::EEP"
| eeprom?
|-
| 15
| 2
| 0xee
| "i2c::NFC"
| New3DS-only [[NFC_Services|NFC]]
|-
| 16
| 1
| 0x40
| "i2c::QTM"
| New3DS-only [[QTM_Services|QTM]]
|-
| 17
| 3
| 0x54
| "i2c::IR"
| Used by IR-module starting with [[8.0.0-18]], for New3DS-only HID via "ir:rst". This deviceid doesn't seem to be supported by i2c module on [[8.0.0-18]](actual support was later added in New3DS i2c module).
|}

'''Notice''': These device addresses are used for writing to the respective device, for reading bit0 must be set (see I2C protocol). Thus, the actual device address is >> 1.

== Device 3 ==
{| class="wikitable" border="1"
! REGISTER
! WIDTH
! DESCRIPTION
|-
| 0x03
| 8
| ?
|-
| 0x04
| 8
| ?
|-
| 0x08
| 1
| 3D slider position 0x9..0xFB
|-
| 0x09
| 1
| Sound volume: 0x0..0x3F.
|-
| 0xB
| 1
| Battery level: 0x0..0x40.
|-
| 0xF
| 1
| Flags: bit7-5 are read via [[MCU_Services|mcu::GPU]]. The rest of these are read via [[MCU_Services|mcu::RTC]]: bit4 = BatteryChargeState. bit3 = AdapterState. bit1 = ShellState.
|-
| 0x10
| 1
| Special HID status flags: bit0 = power button pressed, bit1 = power button pressed long, bit2 = home button pressed, bit3 = home button released, bit4 = wifi slider enabled, bit5 = shell got closed, bit6 = shell got opened. If nothing has changed this register is 0.
|-
| 0x12
| 1
| 0x40 if volume slider position changed
|-
| 0x18
| 8
| ?
|-
| 0x20
| 8
| Writing u8 value 4 here triggers a hardware system reboot. Writing u8 value 1 (repeatedly) triggers a shutdown via power-off?
|-
| 0x22
| 8
| Used to set LCD states. bit0 = don't push to LCDs, bit1 = push to LCDs, bit2 = bottom screen backlight off, bit3 = bottom screen backlight on, bit4 = top screen backlight on, bit5 = top screen backlight off
|-
| 0x23
| 8
| ?
|-
| 0x24
| 8
| ?
|-
| 0x28
| 8
| ?
|-
| 0x29
| 8
| ?
|-
| 0x2A
| 8
| ?
|-
| 0x2B
| 8
| ?
|-
| 0x2C
| 8
| setting bits 1, 3 and 4 turn on the 3D LED on the original 3ds
|-
| 0x2D
| 0x64
| This is used for [[MCURTC:SetInfoLEDPattern|controlling]] the notification LED(see [[MCURTC:SetInfoLEDPatternHeader]] as well), when this register is written.
|-
| 0x2E
| 1
| This [[MCURTC:GetInfoLEDStatus|returns]] the notification LED status when read.
|-
| 0x30
| 8
| RTC time (system clock)
|-
| 0x31
| 8
| ?
|-
| 0x32
| 8
| ?
|-
| 0x33
| 8
| ?
|-
| 0x34
| 8
| ?
|-
| 0x35
| 8
| ?
|-
| 0x36
| 8
| ?
|-
| 0x37
| 8
| ?
|-
| 0x38
| 8
| ?
|-
| 0x39
| 8
| ?
|-
| 0x3A
| 8
| ?
|-
| 0x3B
| 8
| ?
|-
| 0x3C
| 8
| ?
|-
| 0x41
| 8
| ?
|-
| 0x43
| 8
| ?
|-
| 0x4E
| 8
| ?
|-
| 0x50
| 8
| ?
|-
| 0x51
| 8
| ?
|-
| 0x58
| 8
| ?
|-
| 0x60
| 8
| Offset in u8 array accessed via address 0x61 (written before any read/write below)
|-
| 0x61
| 0x100
| Reads/writes to an MCU u8 array, repeats after 0x100 bytes?
|}

== Device 5 & 6 ==
LCD controllers for main/sub displays, most likely.

{| class="wikitable" border="1"
! Register
! Width
! Name
! Description
|-
| 0x1
| 8
| ?
|
|-
| 0x11
| 8
| ?
|
|-
| 0x40
| 8
| CMD_IN/CMD_RESULT1
| Write to trigger a command? Seen commands: 0xFF=Reset?, 0x62=IsFinished?. Result is stored in CMD_RESULT1:CMD_RESULT0.
|-
| 0x41
| 8
| CMD_RESULT0
| Read result
|-
| 0x50
| 8
| ?
|
|-
| 0x60
| 8
| ?
|
|-
| 0xFE
| 8
| ?
|
|}

== Device 10 ==
See the datasheet linked to on the [[Hardware]] page for reference.

== Device 12 ==
{| class="wikitable" border="1"
! REGISTER
! WIDTH
! DESCRIPTION
|-
| 0x0
| 21
| DebugPad state.
|}

This is the DebugPad device, see [[HID_Shared_Memory|here]].

== Device 13 ==
{| class="wikitable" border="1"
! Raw I2C register address
! Internal register address
! Width
! Description
|-
| 0x0
| 0x0
| 0x40
| RHR / THR (data receive/send FIFO)
|-
| 0x8
| 0x1
| 0x1
| IER
|-
| 0x10
| 0x2
| 0x1
| FCR/IIR
|-
| 0x18
| 0x3
| 0x1
| LCR
|-
| 0x20
| 0x4
| 0x1
| MCR
|-
| 0x28
| 0x5
| 0x1
| LSR
|-
| 0x30
| 0x6
| 0x1
| MSR/TCR
|-
| 0x38
| 0x7
| 0x1
| SPR/TLR
|-
| 0x40
| 0x8
| 0x1
| TXLVL
|-
| 0x48
| 0x9
| 0x1
| RXLVL
|-
| 0x50
| 0xA
| 0x1
| IODir
|-
| 0x58
| 0xB
| 0x1
| IOState
|-
| 0x60
| 0xC
| 0x1
| IoIntEna
|-
| 0x68
| 0xD
| 0x1
| reserved
|-
| 0x70
| 0xE
| 0x1
| IOControl
|-
| 0x78
| 0xF
| 0x1
| EFCR
|}

See the datasheet linked to on the [[Hardware]] page for reference. From that datasheet, for the structure of the I2C register address u8: "Bit 0 is not used, bits 2:1 select the channel, bits 6:3 select one of the UART internal registers. Bit 7 is not used with the I2C-bus interface, but it is used by the SPI interface to indicate a read or a write operation."

== Device 15 ==
This the New3DS [[NFC_Services|NFC]] controller "I2C" interface. This device is accessed via the WriteDeviceRaw/ReadDeviceRaw I2C service [[I2C_Services|commands]].

Since the *Raw commands are used with this, this device has no I2C registers. Instead, raw data is transfered after the I2C device is selected. Hence, WriteDeviceRaw is used for sending commands to the controller, while ReadDeviceRaw is for receiving responses from the controller. Certain commands may return multiple command responses.

Command request / response structure:
{| class="wikitable" border="1"
! Offset
! Size
! Description
|-
| 0x0
| 0x1
| Normally 0x10?
|-
| 0x1
| 0x1
| Command source / destination.
|-
| 0x2
| 0x1
| CmdID
|-
| 0x3
| 0x1
| Payload size.
|}

Following the above header is the payload data(when payload size is non-zero), with the size specified in the header. The command response payload is usually at least 1-byte, where that byte appears to be normally 0x0. For command requests the payload data is the command parameters.

For command requests sent to the NFC tag itself, Cmd[1]=0x0 and CmdID=0x0. The command request payload data here is the actual command request data for the NFC tag, starting with the CmdID u8 at payload+0.

During NFC module startup, a certain command is sent to the controller which eventually(after various cmd-reply headers etc) returns the following the payload after the first byte in the payload:
000000: 44 65 63 20 32 32 20 32 30 31 32 31 34 3a 35 33 Dec 22 201214:53
000010: 3a 35 30 01 05 0d 46 05 1b 79 20 07 32 30 37 39 :50...F..y .2079
000020: 31 42 35 1B5

Or that is: "Dec 22 201214:53:50<binary>20791B5". Therefore, this appears to return the part-number of the NFC controller(other command request(s) / response(s) use this part-number value too).

=== NFC controller commands ===
{| class="wikitable" border="1"
! CmdRequest[1]
! CmdID
! Payload data for parameters
! Description
|-
| 0x2E
| 0x2F
| Firmware image for this chunk, size varies.
| This is used during NFC module startup to upload the firmware image to the NFC controller. This is used repeatedly to upload multiple chunks of the image.
|}

10.4.0-29

2016-01-19T06:13:06Z

Shinyquagsire23: a word

The Old3DS+New3DS 10.4.0-29 system update was released on January 18, 2016. This Old3DS update was released for the following regions: USA, EUR, JPN, CHN, KOR, and TWN. This New3DS update was released for the following regions: USA, EUR, JPN, CHN, and KOR.

Security flaws fixed: <fill this in manually later, see the updatedetails page from the ninupdates-report page(s) once available for now>.

Old3DS/New3DS browserhax and menuhax were not fixed(the Old3DS browser wasn't even updated).

==Change-log==
[http://en-americas-support.nintendo.com/app/answers/detail/a_id/667/p/430/c/267 Official] USA change-log:
* Further improvements to overall system stability and other minor adjustments have been made to enhance the user experience

==System Titles==

===APT===
APT added [[APT:IsTitleAllowed|a new command]] used by menu which now checks whether IronFall is on the latest version before launching; if it is on an exploitable version and the function is called to launch IronFall the system will reboot. This check is done again before launching the title, throwing an error if it fails.

==See Also==
System update report(s):
* [http://yls8.mtheall.com/ninupdates/reports.php?date=01-18-16_07-00-49&sys=ctr]
* [http://yls8.mtheall.com/ninupdates/reports.php?date=01-18-16_07-00-58&sys=ktr]

10.4.0-29

2016-01-19T05:48:07Z

Shinyquagsire23: /* System Titles */

The Old3DS+New3DS 10.4.0-29 system update was released on January 18, 2016. This Old3DS update was released for the following regions: USA, EUR, JPN, CHN, KOR, and TWN. This New3DS update was released for the following regions: USA, EUR, JPN, CHN, and KOR.

Security flaws fixed: <fill this in manually later, see the updatedetails page from the ninupdates-report page(s) once available for now>.

Old3DS/New3DS browserhax and menuhax were not fixed(the Old3DS browser wasn't even updated).

==Change-log==
[http://en-americas-support.nintendo.com/app/answers/detail/a_id/667/p/430/c/267 Official] USA change-log:
* Further improvements to overall system stability and other minor adjustments have been made to enhance the user experience

==System Titles==

===APT===
APT added [[APT:IsTitleAllowed|a new command]] used by menu which now checks whether IronFall is on the latest version before launching; if it is on an exploitable version and the function is called to launch IronFall the system will reboot. This check is done again before launching the the title, throwing an error if it fails.

==See Also==
System update report(s):
* [http://yls8.mtheall.com/ninupdates/reports.php?date=01-18-16_07-00-49&sys=ctr]
* [http://yls8.mtheall.com/ninupdates/reports.php?date=01-18-16_07-00-58&sys=ktr]

10.4.0-29

2016-01-19T04:00:08Z

Shinyquagsire23: clarification

The Old3DS+New3DS 10.4.0-29 system update was released on January 18, 2016. This Old3DS update was released for the following regions: USA, EUR, JPN, CHN, KOR, and TWN. This New3DS update was released for the following regions: USA, EUR, JPN, CHN, and KOR.

Security flaws fixed: <fill this in manually later, see the updatedetails page from the ninupdates-report page(s) once available for now>.

==Change-log==
[http://en-americas-support.nintendo.com/app/answers/detail/a_id/667/p/430/c/267 Official] USA change-log:
* Further improvements to overall system stability and other minor adjustments have been made to enhance the user experience

==System Titles==

===APT===
APT added a new command used by menu which now checks whether IronFall is on the latest version before launching; if it is on an exploitable version and the function is called to launch IronFall the system will reboot.

==See Also==
System update report(s):
* [http://yls8.mtheall.com/ninupdates/reports.php?date=01-18-16_07-00-49&sys=ctr]
* [http://yls8.mtheall.com/ninupdates/reports.php?date=01-18-16_07-00-58&sys=ktr]

10.4.0-29

2016-01-19T03:53:41Z

Shinyquagsire23: wow

The Old3DS+New3DS 10.4.0-29 system update was released on January 18, 2016. This Old3DS update was released for the following regions: USA, EUR, JPN, CHN, KOR, and TWN. This New3DS update was released for the following regions: USA, EUR, JPN, CHN, and KOR.

Security flaws fixed: <fill this in manually later, see the updatedetails page from the ninupdates-report page(s) once available for now>.

==Change-log==
[http://en-americas-support.nintendo.com/app/answers/detail/a_id/667/p/430/c/267 Official] USA change-log:
* Further improvements to overall system stability and other minor adjustments have been made to enhance the user experience

==System Titles==

===APT===
APT now checks whether IronFall is on the latest version before launching, if it is not the system will reboot.

==See Also==
System update report(s):
* [http://yls8.mtheall.com/ninupdates/reports.php?date=01-18-16_07-00-49&sys=ctr]
* [http://yls8.mtheall.com/ninupdates/reports.php?date=01-18-16_07-00-58&sys=ktr]

GPU/External Registers

2016-01-01T20:38:21Z

Shinyquagsire23: Another register to control backlights.

This page describes the address range accessible from the ARM11, used to configure the basic GPU functionality. For information about the internal registers used for 3D rendering, see [[GPU/Internal Registers]].

== Map ==
{| class="wikitable" border="1"
! User VA
! PA
! Length
! Name
! Comments
|-
| 0x1EF00004
| 0x10400004
| 4
| ?
|
|-
| 0x1EF00010
| 0x10400010
| 16
| [[#Memory Fill|Memory Fill1]] "PSC0"
| GX command 2
|-
| 0x1EF00020
| 0x10400020
| 16
| [[#Memory Fill|Memory Fill2]] "PSC1"
| GX command 2
|-
| 0x1EF00030
| 0x10400030
| 4
| ?
|
|-
| 0x1EF00034
| 0x10400034
| 4
| GPU Busy
| Bit31 = cmd-list busy, bit27 = PSC0 busy, bit26 = PSC1 busy.
|-
| 0x1EF00050
| 0x10400050
| 4
| ?
| Writes 0x22221200 on GPU init.
|-
| 0x1EF00054
| 0x10400054
| 4
| ?
| Writes 0xFF2 on GPU init.
|-
| 0x1EF000C0
| 0x104000C0
| 4
| Backlight control
| Writes 0x0 to allow backlights to turn off, 0x20000000 to force them always on.
|-
| 0x1EF00400
| 0x10400400
| 0x100
| [[#Framebuffer_Setup|Framebuffer Setup]] "PDC0" (top screen)
|
|-
| 0x1EF00500
| 0x10400500
| 0x100
| [[#Framebuffer_Setup|Framebuffer Setup]] "PDC1" (bottom)
|
|-
| 0x1EF00C00
| 0x10400C00
| ?
| [[#Transfer_Engine|Transfer Engine]] "DMA"
|
|-
| 0x1EF01000
| 0x10401000
| 0x4
| ?
| Writes 0 on GPU init and before the Command List is used
|-
| 0x1EF01080
| 0x10401080
| 0x4
| ?
| Writes 0x12345678 on GPU init.
|-
| 0x1EF010C0
| 0x104010C0
| 0x4
| ?
| Writes 0xFFFFFFF0 on GPU init.
|-
| 0x1EF010D0
| 0x104010D0
| 0x4
| ?
| Writes 1 on GPU init.
|-
| 0x1EF014??
| 0x104014??
| 0x14
| "PPF" ?
|
|-
| 0x1EF018E0
| 0x104018E0
| 0x14
| [[#Command_List|Command List]] "P3D"
|
|}

== Memory Fill ==
{| class="wikitable" border="1"
! User VA
! Description
|-
| 0x1EF000X0
| Buffer start physaddr >> 3
|-
| 0x1EF000X4
| Buffer end physaddr >> 3
|-
| 0x1EF000X8
| Fill value
|-
| 0x1EF000XC
| Control. bit0: start/busy, bit1: finished, bit8-9: fill-width (0=16bit, 1=3=24bit, 2=32bit)
|}

Memory fills are used to initialize buffers in memory with a given value, similar to memset. A memory fill is triggered by setting bit0 in the control register. Doing so aborts any running memory fills on that filling unit. Upon completion, the hardware unsets bit0 and sets bit1 and fires interrupt PSC0.

These registers are used by [[GSP Shared Memory#GX SetMemoryFill|GX SetMemoryFill]].

== LCD Source Framebuffer Setup ==
{| class="wikitable" border="1"
! Offset
! Length
! Name
! Comments
|-
| 0x5C
| 4
| Framebuffer width & height
| Lower 16 bits: width, upper 16 bits: height
|-
| 0x68
| 4
| Framebuffer A first address
| For top screen, this is the left eye 3D framebuffer.
|-
| 0x6C
| 4
| Framebuffer A second address
| For top screen, this is the left eye 3D framebuffer.
|-
| 0x70
| 4
| Framebuffer format
| Bit0-15: framebuffer format, bit16-31: unknown
|-
| 0x78
| 4
| Framebuffer select
| Bit0: which framebuffer to display, bit1-7: unknown
|-
| 0x90
| 4
| Framebuffer stride
| Distance in bytes between the start of two framebuffer rows (must be a multiple of 8).
|-
| 0x94
| 4
| Framebuffer B first address
| For top screen, this is the right eye 3D framebuffer. Unused for bottom screen.
|-
| 0x98
| 4
| Framebuffer B second address
| For top screen, this is the right eye 3D framebuffer. Unused for bottom screen.
|}

=== Framebuffer format ===
{| class="wikitable" border="1"
|-
! Bit
! Description
|-
| 2-0
| Color format
|-
| 3
| ?
|-
| 4
| Unused?
|-
| 5
| Enable parallax barrier (i.e. 3D).
|-
| 6
| 1 = main screen, 0 = sub screen. However if bit5 is set, this bit is cleared.
|-
| 7
| ?
|-
| 9-8
| Value 1 = unknown: get rid of rainbow strip on top of screen, 3 = unknown: black screen.
|-
| 15-10
| Unused?
|}

GSP module only allows the LCD stereoscopy to be enabled when bit5=1 and bit6=0 here. When GSP module updates this register, GSP module will automatically disable the stereoscopy if those bits are not set for enabling stereoscopy.

=== Framebuffer color formats ===
{| class="wikitable" border="1"
|-
! Value
! Description
|-
| 0
| GL_RGBA8_OES
|-
| 1
| GL_RGB8_OES
|-
| 2
| GL_RGB565_OES
|-
| 3
| GL_RGB5_A1_OES
|-
| 4
| GL_RGBA4_OES
|}
Color components are laid out in reverse byte order, with the most significant bits used first (i.e. non-24-bit pixels are stored as a little-endian values). For instance, a raw data stream of two GL_RGB565_OES pixels looks like GGGBBBBB RRRRRGGG GGGBBBBB RRRRRGGG.

== Transfer Engine ==
{| class="wikitable" border="1"
! Register address
! Description
|-
| 0x1EF00C00
| Input physical address >> 3
|-
| 0x1EF00C04
| Output physical address >> 3
|-
| 0x1EF00C08
| DisplayTransfer output width (bits 0-15) and height (bits 16-31).
|-
| 0x1EF00C0C
| DisplayTransfer input width and height.
|-
| 0x1EF00C10
| Transfer flags. (See below)
|-
| 0x1EF00C14
| GSP module writes value 0 here prior to writing to 0x1EF00C18, for cmd3.
|-
| 0x1EF00C18
| Setting bit0 starts the transfer. Upon completion, bit0 is unset and bit8 is set.
|-
| 0x1EF00C20
| TextureCopy total amount of data to copy, in bytes.
|-
| 0x1EF00C24
| TextureCopy input line width (bits 0-15) and gap (bits 16-31), in bytes.
|-
| 0x1EF00C28
| TextureCopy output line width and gap.
|}

These registers are used by [[GSP_Shared_Memory|GX command]] 3 and 4. For cmd4, *0x1EF00C18 |= 1 is used instead of just writing value 1. The DisplayTransfer registers are only used if bit 3 of the flags is unset and ignored otherwise. The TextureCopy registers are likewise only used if bit 3 is set, and ignored otherwise.

==== Flags Register - 0x1EF00C10 ====
{| class="wikitable" border="1"
! Bit
! Description
|-
| 0
| When set, the framebuffer data is flipped vertically.
|-
| 1
| When set, the input framebuffer is treated as linear and converted to tiled in the output, converts tiled->linear when unset.
|-
| 2
| This bit is required when the output width is less than the input width for the hardware to properly crop the lines, otherwise the output will be mis-aligned.
|-
| 3
| Uses a TextureCopy mode transfer. See below for details.
|-
| 4
| Not writable
|-
| 5
| Don't perform tiled-linear conversion. Incompatible with bit 1, so only tiled-tiled transfers can be done, not linear-linear.
|-
| 7-6
| Not writable
|-
| 10-8
| Input framebuffer color format, value0 and value1 are the same as the [[GPU Registers#Framebuffer_color_formats|LCD Source Framebuffer Formats]] (usually zero)
|-
| 11
| Not writable
|-
| 14-12
| Output framebuffer color format
|-
| 15
| Not writable
|-
| 16
| Use 32x32 block tiling mode, instead of the usual 8x8 one. Output dimensions must be multiples of 32, even if cropping with bit 2 set above.
|-
| 17-23
| Not writable
|-
| 24-25
| Scale down the input image using a box filter. 0 = No downscale, 1 = 2x1 downscale. 2 = 2x2 downscale, 3 = invalid
|-
| 31-26
| Not writable
|}

=== TextureCopy ===

When bit 3 of the control register is set, the hardware performs a TextureCopy-mode transfer. In this mode, all other bits of the control register (except for bit 2, which still needs to be set correctly) and the regular dimension registers are ignored, and no format conversions are done. Instead, it performs a raw data copy from the source to the destination, but with a configurable gap between lines. The total amount of bytes to copy is specified in the size register, and the hardware loops reading lines from the input and writing them to the output until this amount is copied. The "gap" specified in the input/output dimension register is the number of bytes to skip after each "width" bytes of the input/output, and is NOT counted towards the total size of the transfer.

By correctly calculating the input and output gap sizes it is possible to use this functionality to copy arbitrary sub-rectangles between differently-sized framebuffers or textures, which is one of its main uses over a regular no-conversion DisplayTransfer. When copying tiled textures/framebuffers it's important to remember that the contents of a tile are laid out sequentially in memory, and so this should be taken into account when calculating the transfer parameters.

Specifying invalid/junk values for the TextureCopy dimensions can result in the GPU hanging while attempting to process this TextureCopy.

== Command List ==
{| class="wikitable" border="1"
! Register address
! Description
|-
| 0x1EF018E0
| Buffer size in bytes >> 3
|-
| 0x1EF018E8
| Buffer physical address >> 3
|-
| 0x1EF018F0
| Setting bit0 to 1 enables processing GPU command execution. Upon completion, bit0 seems to be reset to 0.
|}

These 3 registers are used by [[GSP_Shared_Memory|GX command]] 1. This is used for [[GPU/Internal_Registers|GPU commands]].

== Framebuffers ==
These LCD framebuffers normally contain the last rendered frames from the GPU. The framebuffers are drawn from left-to-right, instead of top-to-bottom.(Thus the beginning of the framebuffer is drawn starting at the left side of the screen)

Both of the 3D screen left/right framebuffers are displayed regardless of the 3D slider's state, however when the 3D slider is set to "off" the 3D effect is disabled. Normally when the 3D slider's state is set to "off" the left/right framebuffer addresses are set to the same physical address. When the 3D effect is disabled and the left/right framebuffers are set to separate addresses, the LCD seems to alternate between displaying the left/right framebuffer each frame.

==== Init Values from nngxInitialize for Top Screen ====
* 0x1EF00400 = 0x1C2
* 0x1EF00404 = 0xD1
* 0x1EF00408 = 0x1C1
* 0x1EF0040C = 0x1C1
* 0x1EF00410 = 0
* 0x1EF00414 = 0xCF
* 0x1EF00418 = 0xD1
* 0x1EF0041C = 0x1C501C1
* 0x1EF00420 = 0x10000
* 0x1EF00424 = 0x19D
* 0x1EF00428 = 2
* 0x1EF0042C = 0x1C2
* 0x1EF00430 = 0x1C2
* 0x1EF00434 = 0x1C2
* 0x1EF00438 = 1
* 0x1EF0043C = 2
* 0x1EF00440 = 0x1960192
* 0x1EF00444 = 0
* 0x1EF00448 = 0
* 0x1EF0045C = 0x19000F0
* 0x1EF00460 = 0x1c100d1
* 0x1EF00464 = 0x1920002
* 0x1EF00470 = 0x80340
* 0x1EF0049C = 0

==== More Init Values from nngxInitialize for Top Screen ====
* 0x1EF00468 = 0x18300000, later changed by GSP module when updating state, framebuffer
* 0x1EF0046C = 0x18300000, later changed by GSP module when updating state, framebuffer
* 0x1EF00494 = 0x18300000
* 0x1EF00498 = 0x18300000
* 0x1EF00478 = 1, doesn't stay 1, read as 0
* 0x1EF00474 = 0x10501

[[Category:GPU]]

BOSS Services

2015-12-30T04:59:38Z

Shinyquagsire23: Some more unknown commands used by Smash 3DS

==BOSS Service "boss:U"==
{| class="wikitable" border="1"
|-
! Command Header
! Description
|-
| 0x00010082
| unknown... (seems to always get called first)
|-
| 0x00020100
| GetStorageInfo
|-
| 0x00030000
| unknown...
|-
| 0x00040000
| unknown...
|-
| 0x00090040
| unknown...
|-
| 0x000A0000
| unknown...
|-
| 0x000E0000
| unknown...
|-
| 0x000C0082
| UnregisterTask
|-
| 0x00100102
| unknown...
|-
| 0x00140082
| unknown...
|-
| 0x00160082
| unknown...
|-
| 0x001C0042
| unknown...
|-
| 0x001D0042
| unknown...
|-
| 0x001E0042
| Task::Cancel
|-
| 0x001F0000
| unknown...
|-
| 0x00200082
| unknown...
|-
| 0x00210042
| unknown...
|-
| 0x002300C2
| unknown...
|-
| 0x00260040
| unknown...
|-
| 0x002700C2
| unknown...
|-
| 0x00280102
| unknown...
|-
| 0x002D0040
| unknown...
|-
| 0x002C0040
| unknown...
|-
| 0x002E0040
| unknown...
|-
| 0x002F0140
| unknown...
|-
| 0x00300000
| unknown...
|-
| 0x00330042
| StartBgImmediate
|-
| 0x003500C2
| unknown...
|-
| 0x00360084
| unknown...
|}

==Privileged BOSS Service "boss:P"==
{| class="wikitable" border="1"
|-
! Command Header
! Description
|-
| 0x04040080
| unknown...
|-
| 0x040500C0
| unknown...
|-
| 0x040600C0
| unknown...
|-
| 0x04070080
| unknown...
|-
| 0x04090102
| unknown...
|-
| 0x040B0080
| unknown...
|-
| 0x040D0182
| unknown...
|-
| 0x041500C0
| unknown...
|-
| 0x04160142
| unknown...
|-
| 0x04170182
| unknown...
|-
| 0x041C00C0
| unknown...
|-
| 0x042E00C2
| unknown...
|-
| 0x042F00C2
| unknown...
|-
| 0x043000C2
| unknown...
|-
| 0x04490142
| unknown...
|-
| 0x044A0180
| unknown...
|-
| 0x044D0080
| unknown...
|-
| 0x04500102
| unknown...
|-
| 0x04540102
| unknown...
|-
| 0x045500C2
| unknown...
|}

boss:P also contains all of the commands from boss:U.

I2C Services

2015-11-14T19:38:03Z

Shinyquagsire23: WriteCommand8 as seen in ir:rst

[[Category:Services]]
= I2C Service Names =
{| class="wikitable" border="1"
|-
! Service names
! Notes
! Accessible [[I2C_Registers|deviceIDs]]
|-
| "i2c::MCU"
|
| 0, 3
|-
| "i2c::CAM"
|
| 1, 2, 4
|-
| "i2c::LCD"
|
| 5, 6
|-
| "i2c::DEB"
|
| 7, 8
|-
| "i2c::HID"
|
| 9, 10, 11, 12
|-
| "i2c::IR"
|
| 13, and additionally for New3DS i2c module: 17
|-
| "i2c::EEP"
|
| 14
|-
| "i2c::NFC"
| Only available via the New3DS i2c sysmodule.
| 15
|-
| "i2c::QTM"
| Only available via the New3DS i2c sysmodule.
| 16
|}

Each I2C service can only access certain I2C [[I2C_Registers|device(s)]]. When the specified deviceid isn't accessible, error 0xE0A02FEA is returned.

= I2C Service =
{| class="wikitable" border="1"
|-
! Command Header
! Available since system-version
! Description
|-
| 0x00010100
|
| SetRegisterBits8 (u8 devid, u8 regid, u8 regdata, u8 mask)
|-
| 0x000200C0
|
| EnableRegisterBits8 (u8 devid, u8 regid, u8 enablemask)
|-
| 0x000300C0
|
| DisableRegisterBits8 (u8 devid, u8 regid, u8 disablemask)
|-
| 0x00040102
|
| MultiSetRegisterBits16 (u16 regid, u16 regdata, u16 mask, devcount, u8* devidlistptr)
|-
| 0x000500C0
|
| WriteRegister8 (u8 devid, u8 regid, u8 regdata)
|-
| 0x00060080
|
| WriteCommand8 (u8 devid, u8 cmdid)
|-
| 0x0007....
|
| WriteRegister16 (u8 devid, u16 regid, u16 regdata)
|-
| 0x000800C2
|
| MultiWriteRegister16 (u16 regid, u16 regdata, devcount, u8* devidlistptr)
|-
| 0x0009....
|
| u8 ReadRegister8 (u8 devid, u8 regid)
|-
| 0x000A....
|
| u16 ReadRegister16 (u8 devid, u16 regid)
|-
| 0x000B00C2
|
| WriteRegisterBuffer8 (u8 devid, u8 regid, buffersize, (buffersize << 14) <nowiki>|</nowiki> 0x402, u8* bufferptr)
|-
| 0x000C00C2
|
| WriteRegisterBuffer16 (u8 devid, u16 regid, buffersize, (buffersize << 15) <nowiki>|</nowiki> 0x402, u16* bufferptr)
|-
| 0x000D00C0
|
| ReadRegisterBuffer8 (u8 devid, u8 regid, buffersize, +0x180: (buffersize << 14) <nowiki>|</nowiki> 2, +0x184: u8 bufferptr)
|-
| 0x000E00C2
|
| WriteRegisterBuffer8_again? (u8 devid, u8 regid, buffersize, u8* bufferptr)
|-
| 0x000F....
|
|
|-
| 0x0010....
|
|
|-
| 0x001100C2
|
| WriteRegisterBuffer(u8 devid, u16 regid, buffersize, u8 *buff)
|-
| 0x001200C2
|
| ReadRegisterBuffer(u8 devid, u16 regid, buffersize, u8 *buff)
|-
| 0x00130040
| [[8.0.0-18]]
| ReadDeviceRaw8(u8 devid) Writes the output read u8 I2C data to cmdreply[2]. After successfully selecting the I2C device, it writes 0xE1 to CNT then loads the output u8 I2C data from the DATA register.
|-
| 0x00140082
| [[8.0.0-18]]
| WriteDeviceRaw(u8 devid, u32 buffersize, (buffersize << 14) <nowiki>|</nowiki> 0x402, bufferptr) This is basically the write-data version of command 0x00150080.
|-
| 0x00150080
| [[8.0.0-18]]
| ReadDeviceRaw(u8 devid, u32 buffersize, +0x180: (buffersize << 14) <nowiki>|</nowiki> 2, +0x184: bufferptr) This is the >1-byte version of command 0x00130040, except value 0xF0 is used for CNT instead of 0xE1.
|}

Commands 0x00130040..0x00150080 are only usable with the New3DS i2c module: on Old3DS the actual command-handler function for each of these commands just return an error. Commands 0x00140082 and 0x00150080 are used by [[NFC_Services|NFC]] module.