3dbrew - User contributions [en]

3DS Userland Flaws

2022-07-24T09:36:24Z

Unknown: /* Non-system applications */ Add Me and My pets 3d

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 its predecessor, Gates to Infinity. When a save file is being prepared to be loaded and read from, only a 0x32000 large buffer is allocated for file reading, and a 0x3e800-large buffer for decompression is also allocated before the file is read. However, the game does not limit the size of the file read to this allocation bound, allowing for the file to overflow into the linear memory heap and into the next allocation. Since Pokemon Super Mystery Dungeon stores allocation memchunks directly before the allocation, overwriting the next memchunk with a corrupted one allows for arbitrary writes of linear heap pointers when the next buffer is allocated or arbitrary writes of any pointer within writable memory when the corrupted buffer is freed.
| None
| O3DS: [[11.3.0-36]]. N3DS: [[11.4.0-37]].
| 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.
| App: v1.1
| [[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.
| App: 3.3.2.
| System: [[11.0.0-33]].
| July 20, 2016
| Around June 26, 2016
| slackerSnail, 12Me12, incvoid
Exploited by MrNbaYoh and [[User:Plutooo|plutoo]].
|-
| SmileBASIC 3.x
| Subscripted TIME$/DATE$ allow write access to DATA/BSS
| Utf-16 characters can be assigned to subscripted TIME$/DATE$ interpreter sysvars which results in write-only access to all of DATA and some BSS in userland.
TIME$[0]/DATE$[0] actually point to somewhere in rodata, and an overly large subscript can be used to write well past it and into the aforementioned areas. Demo [https://github.com/zoogie/smilehax-IIe here.]
| App: 3.6.2 (3.6.0 latest for US/EU, JP appvers. can be downgraded)
| System: [[11.13.0-45]].
| April 2020
| February 2020
| bug publicly documented [https://translate.google.com/translate?sl=auto&tl=en&u=http%3A%2F%2Fsmilebasic.com%2Fdebug%2Farchive%2F here.]
Exploited by Zoogie
|-
| The Legend of Zelda: Tri Force Heroes
| [[3DS_System_Flaws#General.2FCTRSDK|CTRSDK]] CTPK buffer overflow combined with game's usage of SpotPass
| During the very first screen displayed by the game during boot("Loading..."), just seconds after title launch, the game loads CTPK from the [[BOSS_Services|stored]] SpotPass content. Hence, this game could be exploited via the vulnerable CTRSDK CTPK code ''if'' one could get custom SpotPass data into extdata somehow(ctr-httpwn >=v1.2 with bosshaxx allows this).

The code for this runs from a thread separate from the main-thread, with the stack in linearmem heap. This SpotPass handling triggers before the game ever opens the regular savedata archive. The extdata is opened at some point before this: it opens a file for checking if it exists, then immediately closes it.

The two SpotPass URLs for this have always(?) returned HTTP 404 as of November 2016. It appears these were intended for use as textures for additional costumes(and never got used publicly), but this wasn't tested.

This is used by [https://github.com/yellows8/ctpkpwn ctpkpwn_tfh].
| None
| App: v2.1.0
| November 18, 2016
| November 14, 2016
| [[User:Yellows8|Yellows8]]
|-
| Pixel Paint
| Buffer overflow via unchecked extdata file length
| Pixel Paint loads pictures saved by the user from extdatas. The file is read to a fixed size buffer but the file length remains unchecked, so with a large enough file, one can overwrite pointers in memory and gain control of the execution flow.
| None
| App: Initial version. System: [[11.2.0-35]].
| December 27, 2016
| November 5, 2016
| [[User:Nba_Yoh|MrNbaYoh]]
|-
| Steel Diver : Sub Wars
| Heap overflow / arbitrary memcpy
| Savefile datas are stored as key/value pairs, a large enough string key makes the game overwrite a memcpy source/destination addresses and size arguments. So one can actually memcpy a rop on the stack and gain control of the execution flow.
| None
| System: [[11.2.0-35]].
| December 27, 2016
| Around July 15, 2016
| [[User:Nba_Yoh|MrNbaYoh]], Vegaroxas
|-
| 1001 Spikes
| Buffer overflow via unchecked array-indexes in XML savefile parsing
| The savefiles are stored as renamed .xml files, which contain several tags with attributes like 'array-index="array-value"', where both of these are converted from ASCII strings to integers as signed-int32, and the array-value given blindly written to an array inside a structure using the (unchecked) index given. With several of these attributes, one can overwrite the stack starting from the stored lr of the function that does this parsing, and write a ROP chain there. Testing used the "LevelAttempts" tag which is the last such tag parsed in that function.
| None
| App: v1.2.0 (TMD v2096)
| December 27, 2016
| Around November 2, 2016
| [[User:Riley|Riley]]
|-
| Pokemon Omega Ruby/Alpha Sapphire
| Secret base team name heap overflow
| When the player wants to edit the team name, it is copied over the heap, however its length is not verified. So with a large enough team name one can overwrite some pointers and get two arbitrary jumps and then get control of the execution flow.
| None
| App: 1.4. System: [[11.2.0-35]].
| December 30, 2016
| June, 2016
| [[User:Nba_Yoh|MrNbaYoh]]
|-
| Swapdoodle
| Heap buffer overflow via unchecked size
| The letter file format used by doodlebomb is composed of multiple chunks. Each chunks is described in the header of the file where the name, size and CRC of each chunk are stored. Some chunks are meant to be headers, every header's size should be 0x80, however the length of the STAHED1 chunk remains unchecked and the game memcpy the chunk to a 0x80 byte buffer with the length provided in the file. This way one is able to overwrite some pointers and get control of the execution flow.
| App: > v1.1.1
| App: v1.1.1
| April 24, 2017
| February, 2017
| [[User:Nba_Yoh|MrNbaYoh]]
|-
| Pokemon Picross
| Arbitrary memcpy via unchecked size
| When reading the savefile, the game handles some lists of buffers that are copied to memory. These buffers should always be 0x14-bytes long but the game uses the size provided in the savefile to copy them. These buffers are copied in some structs and thus with a big enough length value, one can overwrite the next struct which contains a size and a destination address for a memcpy.
| None?
| App: ?
| May 29, 2017
| June, 2016
| [[User:Nba_Yoh|MrNbaYoh]]
|-
| RPG Maker Fes/Player
| Buffer overflow on .bss section
| When loading a project, the game copies multiple chunks over the BSS section. However the number of chunks to copy is not checked, thus a large amount of chunk result in a buffer overflow. There's multiple way to exploit this flaw to gain an arbitrary memcpy or an arbitrary jump.
| None?
| App: ?
| August 28, 2017
| August, 2017
| [[User:Nba_Yoh|MrNbaYoh]]
|-
| RPG Maker Fes/Player
| Buffer overflow via unchecked file size
| When loading a project, the game loads the file to a 0x200000 bytes long buffer. However the size remains unchecked, so with a big enough file one can overflow the buffer and overwrite a thread stack and then achieve ROP.
| None?
| App: ?
| August 29, 2017
| August, 2017
| [[User:Nba_Yoh|MrNbaYoh]], [[User: ChampionLeake|ChampionLeake]]
|-
| Pokemon Omega Ruby/Alpha Sapphire
| PSS data heap/stack overflow
| When launching the game, multiple chunks from the save file are parsed and copied to a large heap buffer. When parsing PSS data (acquaintances, passerby) the game copies each entry to the heap buffer, the number of entries to copy is read from the end of the multiple pss data chunks and is not checked, leading to an overflow. The "PSS data - friends" chunk is vulnerable too, but the overflow occurs on the stack and unfortunately this isn't exploitable because of a 4 bytes uncontrolled value (in each entry) that gets written on sensitive data.
| None
| App: 1.4. System: [[11.6.0]].
| October 1, 2017
| June, 2016
| [[User:Nba_Yoh|MrNbaYoh]]
|-
| RPG Maker Fes/Player
| OOB write
| When handling events in a map, the indices of "buttons" are not checked. This results in an out of bound bit write, one can thus write a rop directly on the stack (bit by bit).
| None?
| App: ?
| August 5, 2018
|
| [[User:Nba_Yoh|MrNbaYoh]]
|-
| Unholy Heights
| Buffer overflow via unchecked string size
| The game stores some utf-16 messages in the savefile. Right before the message is the length(u32) for the string, the game uses this size to memcpy the message from the savefile to the stack without checking the length. This allows one to overwrite some function addresses on the stack and form a rop chain.
| None
| App: Initial Version
| September 13, 2018
| August, 2018
| Kartik
|-
| Mononoke Forest
| String Buffer Overflow via unchecked string length
| The game stores plaintext profile names in the savefile. The profile names are strcpy/memcpy to different areas of the game's functions in the stack. Using a large extensive profile name, a user can overwrite some stack-registers and point to stack buffer addresses to eventually gain control of the stack to lead and form a rop-chain.
| None
| App: v1.0.0
| August 14, 2019
| February 8, 2019
| [[User: ChampionLeake|ChampionLeake]] and [[User: Kartik|Kartik]]
|-
| Picross 3D: Round 2
| Out of bounds array access allowing to point to fabricated objects and vtable
| Game only checks save header. With the last interacted save slot index at +0xb270 in the save data unchecked we can achieve a predictable out of bounds access, as well inserting ROP data without detecting save corruption. Game references an object from an array of 3 elements and passes it to a function that will read object pointers and hit a vtable call. With a copy save data left in memory and a properly calculated index, we can point to a fake object position in the save, vtable jump to a stack pivot and start the ROP chain.
| None
| App: Initial version
| September 10, 2020
| August 24, 2020
| [[User: Luigoalma|Luigoalma]] and [[User: Kartik|Kartik]]
|-
| Me and My Pets 3D
| String buffer overflow
| The game stores some strings in the savegame. Using a large enough string, once can overwrite addresses on the stack and form a ropchain.
| None
| App: Initial Version
| June 24, 2022
| June 12, 2022
| [[User: Kartik|Kartik]]
|}

==Flipnote Studio 3D==

{| class="wikitable" border="1"
|-
! Summary
! Description
! Fixed in app/system version
! Timeframe info related to this was added to wiki
! Flaw discovered by
|-
| KFH frame count overflow
| The KFH frame count field should not be >= 0x3E8, but it wasn't checked and so uncontrolled data were written over pointers, causing an unexploitable crash.
| System: 11.6
| September 20, 2017
| [[User:Nba_Yoh|MrNbaYoh]]
|-
| KMI paper color overflow
| Paper color field (and similar color fields) in KMI chunks was not checked, a too high value caused a jump to an uncontrolled location.
| System: 11.6
| September 20, 2017
| [[User:Nba_Yoh|MrNbaYoh]]
|-
| KSN BGM data size overflow
| The size of the BGM data in the KSN chunk was not checked, it was used in a memcpy so with a big enough size one could overwrite a thread stack on linear mem and achieve ROP (notehax v1).
| System: 11.6
| September 20, 2017
| [[User:Nba_Yoh|MrNbaYoh]]
|-
| KMC chunk unchecked
| The KMC chunk was not verified at all, the CRC32 and the size were not checked. A big enough size caused an integer overflow and made the game read the file backward.
| System: 11.6
| September 20, 2017
| [[User:Nba_Yoh|MrNbaYoh]]
|-
| KMI layer size unchecked
| The 3 layer size fields in KMI chunks were not checked, leading to some crashes in the editor.
| System: 11.6
| September 20, 2017
| [[User:Nba_Yoh|MrNbaYoh]]
|-
| Bad "queue" implementation
| When a KWZ was parsed, frames were copied in a kind of queue, bounds were not checked obviously, so with the KMI layer size flaw one was able to fill completely the queue, then write past the buffer and overwrite a heap chunk header (notehax v2). This is not possible anymore, the queue cannot be filled because layer sizes are checked. Moreover each time an element is removed from the queue, the whole content is memmoved *facepalm*.
| System: 11.6
| September 20, 2017
| [[User:Nba_Yoh|MrNbaYoh]]
|}

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

* [[Pyramids 2 (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. Note that this refers to the regular save file: Tri Force Heroes can be exploited via BOSS extdata - see above.

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

* "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 random data results in a crash

* "Worcle Worlds": Overwriting the savefile with 0xFF results in a crash due to an out of bound read

* "Animal Crossing: New Leaf": Creating a QR code from random data results in a valid QR code and a random design. In some very rare cases(which aren't always reproducible?) a crash/etc may occur, but this isn't known to be useful.

* "Angry Birds Star Wars": Strings in the savefile are preceded by their lengths. These strings are never stored on the stack and are memcpy'd into heap memory. If the size is invalid the alloc will fail and thus the memcpy will operate on a nullptr resulting in a useless data abort.

* "Gem Smashers": Overwriting the savefile with random bytes results in useless crashes.

* "Luxor:" Strings/plaintext in the savefile are present and these's no checks. Overwriting the whole save (excluding the header), with /dev/random cause a useless crash.

* "Luv Me Buddies Wonderland:" Doesn't crash at all with the entire savedata overwritten. Overwriting some areas, points to useless nulls

==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]]
|-
| 3DS [[System Settings]] stack smash via title strings in [[DSiWare_Exports]]
| DSiWare export banners contain 16 consecutive 0x100 byte, utf-16 game title strings for different languages. Nintendo correctly limits the string's max length by placing a NULL at str[127] before it's copied to the stack. However, they didn't allocate enough space for all 128 wchars (char/wchar type confusion?), so an attacker can craft a valid full-length string that will crash the stack at about str+0xEC. ROP execution can then be obtained from this crash in DSiWare Data Management as demonstrated [https://github.com/zoogie/Bannerbomb3 here].

Interesting note: A line feed wchar (00 0A) at any point in the string before the crash offset will prevent the crash from occurring.
| None
| [[11.13.0-45]]
| Dec. 2018
| Zoogie
|-
| 3DS SAFE_MODE [https://www.3dbrew.org/wiki/System_Settings#System_Updater System Updater] stack smash from proxy-url string
| During [[Recovery Mode]] and after all 3 wifi slots fail to find an access point for sysupdate, a user is permitted to access the wifi settings mode to make changes. Here, if the proxy-url field string's NULL terminator had been altered beforehand, a stack smash can occur when the user selects Proxy Settings -> Detailed Setup and the corrupted url string is displayed.

This is a difficult crash to control because the url string is converted from ascii to utf-16 between the slot and stack, effectively reducing the available gadgets to 0.4% of the normal amount. It's possible to improvise an "escape" using an eoreq pc w/shift gadget to combine registers and form a jump that can access 1/2 of all available gadgets.

Because this exploit runs *under* SAFE_MODE, it's possible to run safehax with one's choice of k11 and arm9 hax. Prerequisite: a userland exploit with cfg:s/i access to modify the wifi slot. A demonstration can be viewed [https://github.com/zoogie/unSAFE_MODE here].
| None
| [[11.13.0-45]]
| Jan. 2020
| Zoogie
|-
| [[Nintendo 3DS Sound]]
| When a .m4a is loaded, the song name is copied to a 256 byte buffer. When the song name begins with a Unicode BOM marker, it memcpy's the tag using the user-provided length. This gives an arbitrary write which can be used to achieve ROP.
| [[11.4.0-37]]
| [[11.4.0-37]]
| June/July 2016
| [[User:nedwill|nedwill]]
|-
| [[EShop]]
| When creating an audio decoder object for the moflex movie player, if the audio codec is PCM16, the application uses an uninitialized value as a pointer. One can spray the heap to get control of that pointer and achieve ROP.
| None
| [[11.14.0-46]]
| 2020
| [[User:Nba_Yoh|MrNbaYoh]]
|}

=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
|-
| 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]]
|-
| Skater - Bookmark OOB write
| Each bookmark has an id that should not exceed 0x63 (99), however ids are not checked, this results in an OOB write on the stack, but only the value 0x01 can be written.
|
| [[11.6.0-39|11.6.0-39]]
|
| May 21, 2018
| May 20, 2018
| [[User:Nba_Yoh|MrNbaYoh]]
|-
| MicroSD Management - malformed security blob causes stack buffer overflow (mhax)
| The MicroSD Management application's parsing of Windows NTLM security blobs in the SMB/CIFS protocol doesn't verify that the client's specified NT domain name is less than 32 UTF-16 characters. When it's longer, a stack buffer overrun occurs, leading to a ROP chain and complete control of the mcopy application.

The malformed security blob can be sent by an attacker within the SMB_COM_SESSION_SETUP_ANDX (0x73) packet.
| [[11.8.0-41|11.8.0-41]]
| [[11.8.0-41|11.8.0-41]]
| [[9.0.0-20|9.0.0-20]]
| August 12, 2018
| 2018
| smea
|}

==Home Menu==
{| 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
|-
| u8 brightness setting OOB index (menuhax67)
| Config block 0x50001, which contains a u8 brightness setting that indexes a table of u32 addresses, can be set to an out-of-bounds index (it's normally 1-5). Located within cfg block 0x50009, there exists a single controllable u32 that's located within the u8's range. With these set properly, one can eventually redirect a function pointer to an address of their choice. This is triggered after the Home Menu quick launch tab is activated. POC [https://github.com/zoogie/menuhax67 here].
| None
| [[11.13.0-45]]
|
| October 4, 2020
| September, 2020
| Zoogie
|-
| bossbannerhax
| After successfully loading [[Extended_Banner|extended-banner]] data(done when selecting an icon), Home Menu attempts to load "[[CBMD]]" data into a 0x100000-byte heap buffer from the [[BOSS_Services|stored]] SpotPass content. When successful and the magic-number is CBMD, Home Menu then decompresses the exbanner sections into another fixed-size heap buffer, without checking the outsize at all. The main CBMD CGFX code with ExeFS checks the size, but this code doesn't(however this is exbanner "CBMD", not a "normal" CBMD).

Used with menuhax as of v3.2.
| [[11.3.0-36|11.3.0-X]]
|
| [[1.0.0-0|1.0.0-0]]
| November 18, 2016
| December 23, 2014
| [[User:Yellows8|Yellows8]]
|-
| sdiconhax
| This is basically the same as nandiconhax, the vulnerable SD/NAND functions are ''identical'' minus the file-buffer offsets. Exploitation is different due to different heap-buffer location though. Unlike nandiconhax, the icon buffer for SD is located in linearmem(with recent Home Menu versions at least). This is used by [[menuhax]].
| [[11.1.0-34|11.1.0-X]]
|
| [[4.0.0-7|4.0.0-X]]
| July 27, 2016
| October 23, 2015
| [[User:Yellows8|Yellows8]]
|-
| [[System_SaveData|NAND-savedata]] Launcher.dat icons (nandiconhax)
| 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.'''
| [[11.1.0-34|11.1.0-X]]
|
| [[4.0.0-7|4.0.0-X]]
|
| May 14, 2015
| [[User:Yellows8|Yellows8]]
|-
| 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)
|-
| 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]]
|-
| Extdata file-data loading buffer overflow
| The extdata file-reading code allocates a fixed-size heap buffer for the expected filesize, then reads the filedata into this buffer using the actual FS filesize. Before v5.0 the filesize used here wasn't validated, hence if the filesize is larger than alloc_size a buffer overflow would occur. ''After'' doing the file-read it does validate that the actual_readsize matches the alloc_size, but at this point the buffer overflow has already occurred.

This affected at least the following: SaveData.dat and Cache.dat.

This can be triggered with SaveData.dat by installing a <v4.0 Home Menu version, with Home Menu extdata from >=v4.0 still on SD. When this is done with v2.0 Home Menu, a kernelpanic occurs when processing an AM command(it appears a buffer ptr which is then passed to a command was overwritten with 0x0 - of course other SaveData.dat filesizes may result in different behaviour).
| [[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]]
|}

The icon data arrays used with {sd/nand}iconhax were added to SaveData.dat/Launcher.dat with [[4.0.0-7|4.0.0-X]], hence the vulnerable functions were added with that same version.

With <=v4.0 the SaveData.dat buffer is located in the regular heap. It's unknown when exactly it was moved to linearmem, which is where it's located with recent versions. It's located in linearmem for KOR >=v9.6 for example.

The SaveData.dat/Launcher.dat icon vulns were fixed by doing various unsigned >=60/>=360 checks on the loaded values. When these checks fail, it just skips over handling this icon entry. Hence, the original value can't be negative / out-of-bounds any more.

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

I2C Registers

2021-05-06T10:17:37Z

Unknown: /* I2C Devices */ devid 9 is not debug gyroscope and exists on retail devices

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

== 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_CNTEX ==
{| class="wikitable" border="1"
! BIT
! DESCRIPTION
|-
| 0-1
| ? Set to 2 normally.
|}

== I2C_SCL ==
{| class="wikitable" border="1"
! BIT
! DESCRIPTION
|-
| 0-5
| ?
|-
| 8-12
| ? Set to 5 normally.
|}

= 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"
| Gyroscope. 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 (old3DS)
|-
| 11
| 3
| 0xd2
| "i2c::HID"
| Gyroscope (2DS, new3DSXL, new2DSXL)
|-
| 12
| 3
| 0xa4
| "i2c::HID"
| DebugPad
|-
| 13
| 3
| 0x9a
| "i2c::IR"
| IR
|-
| 14
| 3
| 0xa0
| "i2c::EEP"
| HWCAL EEPROM ([[Hardware_calibration#Header|only present on dev units where SHA256 is used for HWCAL verification]])
|-
| 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 ==
ro = read-only (writing is no-op)
rw = read-write
wo = write-only (reading will yield 00, FF, or unpredictable data)

d* = dynamic register (explaination below this table)
s* = shared register (explaination below this table)
ds = dynamic shared (explaination below this table)

Reading or writing multiple bytes from/to single-byte registers increments the register ID along with it. For example reading two bytes from reg 0x00 reads regs 0x00 and 0x01.

This is not the case for multibyte regs (0x29, 0x2D, 0x4F, 0x61 and 0x7F), plus reg 0x60.

{| class="wikitable" border="1"
! REGISTER
! WIDTH
! INFO
! DESCRIPTION
|-
| 0x00
| s
| ro
| Version high
|-
| 0x01
| s
| ro
| Version low
|-
| 0x02
| d
| rw
| For bit0 and 1 values, writing will mask away/"acknowledge" the event, set to 3 by mcuMainLoop on reset if reset source is Watchdog
bit0: RTC clock value got reset to defaults
bit1: Watchdog reset happened
bit5: TWL MCU reg: volume mode (0: 8-step, 1: 32-step)
bit6: TWL MCU reg: NTR (0) vs TWL mode (1)
bit7: TWL MCU reg: Uses NAND
|-
| 0x03
| ds
| rw
| Top screen Vcom
|-
| 0x04
| ds
| rw
| Bottom screen Vcom
|-
| 0x05
- 0x07
| s
| rw
| Danger zone - [[MCU_Services#MCU_firmware_versions|MCU unlock sequence]] is written here.
|-
| 0x08
| s
| ro
| Raw 3D slider position
|-
| 0x09
| s
| ro
| Volume slider state (0x00 - 0x3F)
This is the same value returned by [[MCUHWC:GetSoundVolume|MCUHWC:GetSoundVolume]]
|-
| 0x0A
| s
| ro
| Battery temperature (in Celcius?)
|-
| 0x0B
| s
| ro
| Battery percentage
|-
| 0x0C
| s
| ro
| Battery percentage, fractional part (seems to have a resolution of around 0.1% according to tests)
|-
| 0x0D
| s
| ro
| System voltage
|-
| 0x0E
| s
| ro
| ?
|-
| 0x0F
| s
| ro
| Flags: bit7-5 are read via [[MCU_Services|mcu::GPU]]. The rest of them are read via [[MCU_Services|mcu::RTC]].
bit01: ShellState
bit03: AdapterState
bit04: BatteryChargeState
bit05: Bottom screen backlight on
bit06: Top screen backlight on
bit07: GPU on(?)
|-
| 0x10
- 0x13
| s
| ro
| Received interrupt bitmask, see register 0x18 for possible values
If no interrupt was received this register is 0
|-
| 0x14
| s
| ro
| Unused and unwritable byte :(
|-
| 0x15
- 0x17
| s
| rw
| Unused and unreferenced free RAM! Good for userdata.
|-
| 0x18
- 0x1B
| s
| rw
| Interrupt mask for register 0x10 (0=enabled,1=disabled)
bit00: Power button press (for 27 "ticks")
bit01: Power button held (for 375 "ticks"; the 3DS turns off regardless after a fixed time)
bit02: HOME button press (for 5 "ticks")
bit03: HOME button release
bit04: WiFi switch button
bit05: Shell close
bit06: Shell open
bit07: Fatal hardware condition([[Services#Notifications|?]]) (sent when the MCU gets reset by the Watchdog timer)
bit08: Charger removed
bit09: Charger plugged in
bit10: RTC alarm (when some conditions are met it's sent when the current day and month and year matches the current RTC time)
bit11: ??? (accelerometer related)
bit12: HID update
bit13: Battery percentage status change (triggered at 10%, 5%, and 0% while discharging)
bit14: Battery stopped charging (independent of charger state)
bit15: Battery started charging
Nonmaskable(?) interrupts
bit16: ???
bit17: ??? (opposite even for bit16)
bit22: Volume slider position change
bit23: ??? Register 0x0E update
bit24: ??? (the off event for below bit)
bit25: ??? (triggered when something related to the GPU is turned on, most likely backlight)
bit26: ??? (???)
bit27: ??? (???)
bit28: ??? (???)
bit29: ??? backlight on?
bit30: bit set by mcu sysmodule
bit31: bit set by mcu sysmodule
|-
| 0x1C
- 0x1F
| s
| rw
| Unused and unreferenced free RAM! Good for userdata.
|-
| 0x20
| d
| wo
| System power control:
bit0: power off
bit1: full reboot (unused). Discards things like [[CONFIG9_Registers#CFG9_BOOTENV|CFG9_BOOTENV]]
- Asserts RESET1 via PMIC command (?) (deasserts nRESET1). This could be the reset that controls some CFG9 registers
- Asserts RESET2 (P0.1 = 0, PM0.1 = 0 (output)) (deasserts nRESET2)
- Asserts FCRAM_RESET (P3.0 = 0) (deasserts nFCRAM_RESET)
bit2: normal reboot. Preserves [[CONFIG9_Registers#CFG9_BOOTENV|CFG9_BOOTENV]], etc.
- Asserts RESET2 (P0.1 = 0, PM0.1 = 0)
- If in NTR emulation mode (see reg 0x02), asserts FCRAM_RESET (P3.0 = 0)
- Resets TWL MCU i2c registers
bit3: FCRAM reset (present in by LgyBg. Unused because a system reboot does the same thing & a PDN reg also possibly implements this function)
- Asserts FCRAM_RESET (P3.0 = 0)
bit4: signal that sleep mode is about to be entered (used by PTM)
Bit 4 sets a bit at a RAM address which seems to control the watcdog timer state, then this bit is immediately unmasked. This field has a bitmask of 0x0F.

If any of the reset bits is set, the MCU waits for 5ms, then deasserts RESET1 (via PMIC), RESET2 (PM0.1 = 1 (input)) and FCRAM_RESET (P3.0 = 1), and reinitializes some other various registers after a 100ms delay.
|-
| 0x21
| d
| wo
| Used in legacy mode to signal events for TWL MCU "emulation" (written to REG[0x5D])? Software then asserts the TWL MCU IRQ pin via [[#LGY_GPIOEMU_MASK|Legacy I/O registers]].
bit0: Signal TWL POWER button click
bit1: Signal TWL reset
bit2: Signal TWL power off
bit3: Signal TWL battery low
bit4: Signal TWL battery empty
bit5: Signal TWL volume button click
|-
| 0x22
| d
| wo
| Used to set LCD states
bit0: don't push to LCDs
bit1: push to LCDs
bit2: bottom screen backlight off
bit3: bottom screen backlight on
bit4: top screen backlight off
bit5: top screen backlight on

Bits 4 and 5 have no effect on a 2DS because the backlight source is the bottom screen.
The rest of the bits are masked away.
|-
| 0x23
| d
| wo
| Writing 0x72 ('r') resets the MCU, but this is stubbed on retail?
|-
| 0x24
| s
| rw
| Watchdog timer. This must be set *before* the timer is triggered, otherwise the old value is used. Value zero disables the watchdog.
|-
| 0x25
| s
| rw
| ?
|-
| 0x26
| s
| rw
| ?
|-
| 0x27
| sd
| rw
| Raw volume slider state
|-
| 0x28
| s
| rw
| Brightness of the WiFi/Power LED
|-
| 0x29
| sd(5)
| rw
| Power mode indicator state (read-write)
1 = forced default blue
2 = sleep mode animation
3 = "power off" mode
4 = disable blue power LED and turn on red power LED
5 = disable red power LED and turn on blue power LED
6 = animate blue power LED off and flash red power LED
anything else = automatic mode
The other 4 bytes (32bits) affect the pattern of the red power LED (write only)
|-
| 0x2A
| s
| rw
| WiFi LED state, non-0 value turns on the WiFi LED, 4 bits wide
|-
| 0x2B
| s
| rw
| Camera LED state, 4bits wide,
0, 3, 6-0xF = off
1 = slowly blinking
2 = constantly on
3 = "TWL" mode
4 = flash once
5 = delay before changing to 2
|-
| 0x2C
| s
| rw
| 3D LED state, 4 bits wide
|-
| 0x2D
| 0x64
| wo
| This is used for [[MCURTC:SetInfoLEDPattern|controlling]] the notification LED (see [[MCURTC:SetInfoLEDPatternHeader]] as well), when this register is written. It's possible to write data here with size less than 0x64, and only that portion of the pattern data will get overwritten. Reading from this register only returns zeroes, so it's considered write-only. Writing past the size of this register seems to do nothing.
|-
| 0x2E
| s
| ro
| This [[MCURTC:GetInfoLEDStatus|returns]] the notification LED status when read (1 means new cycle started)
|-
| 0x2F
| s
| wo?
| ??? The write function for this register is stubbed.
|-
| 0x30
- 0x36
| ds
| rw
| RTC time (system clock). 7 bytes are read from this. The upper nibble of each byte encodes 10s (BCD), so each byte is post-processed with (byte & 0xF) + (10 * (byte >> 4)).
byte 0: seconds
byte 1: minutes
byte 2: hours
byte 3: current week (unused)
byte 4: days
byte 5: months
byte 6: years
|-
| 0x37
| s
| rw
| RTC time byte 7: leap year counter / "watch error correction" register (unused in code)
|-
| 0x38
- 0x3C
| s
| rw
| RTC alarm registers
byte 0: minutes
byte 1: hours
byte 2: day
byte 3: month
byte 4: year
|-
| 0x3B
| s
| rw
| Could be used on extremely old MCU_FIRM versions to upload [[MCU_Services#MCU_firmware_versions|MCU firmware]] if reg 0xF == 0 and reg 0x10 == 1 (presumably major and minor version fields for mcufw 0.1 which largely predates factory firm).
|-
| 0x3D
0x3E
| ds
| ro
| RTC tick counter / "ITMC" (when resets to 0 the seconds increase)
Only reading 0x3D will update the in-RAM value
|-
| 0x3F
| d
| wo
| 2 bits
bit0: Asserts RESET1 (P0.0 = 0, PM0.0 = 0 (output)) but does NOT deassert it (wtf?). This seems to kill the entire SoC: is it because it doesn't deassert it, or does it not deassert it because the SoC hangs anyway? This is the pin that controls some security-critical regs like CFG9_BOOTENV!
bit1: turns on a prohibited bit in an RTC Control register and turns P12 into an output
|-
| 0x40
| s
| rw
| Tilt sensor sampling mode. Bits 0 and 1 control the mode. If bits 0 or 1 are set then the tilt sensor is enabled and sampled.
|-
| 0x41
| s
| rw
| Index selector for register 0x44
|-
| 0x42
| s
| rw
| Unused?
|-
| 0x43
| s
| rw
| Unused???, accelometer related
|-
| 0x44
| s
| rw
| ???, pedoometer related(?)
|-
| 0x45
- 0x4A
| s
| ro
| Tilt sensor 3D rotation from the 12bit ADC, left shifted 4 to fit in a 16bit signed short, relative to the 3DS bottom screen
{| class="wikitable" border="1"
! AXIS
! V=0x00
! V=0x40
! V=0xC0
|-
| X (left/right)
| held up vertically
| rotated left 90° like a steering wheel
| rotated right 90° like a steering wheel
|-
| Y (forwards/backwards)
| laid flat on the desk with the screen facing up
| held up vertically
| held up vertically with screen facing upside-down
|-
| Z (???)
| ???
| ???
| ???
|}
|-
| 0x4B
| s
| rw
| PedometerStepCount (for the current day)
|-
| 0x4C
0x4D
| ??
| ??
| ??
|-
| 0x4E
| d
| rw
| ??? this = (0xFFE9E & 1) ? 0x10 : 0
|-
| 0x4F
| d(6)
| ro
|
|-
| 0x50
| s
| rw
| ???
|-
| 0x51
| s
| rw
| ???
|-
| 0x52
- 0x57
| s
| rw
| ?
|-
| 0x58
| s
| rw
| Register-mapped ADC register
DSP volume slider 0% volume offset (setting this to 0xFF will esentially mute the DSP as it's the volume slider's maximum raw value)
|-
| 0x59
| s
| rw
| Register-mapped ADC register
DSP volume slider 100% volume offset (setting both this and the above to 0 will disable the volume slider with 100% volume, setting this to a lower value than the above will make the volume slider have only 2 states; on and off)
|-
| 0x5A
| s
| ro/rw
| Invalid, do not use! On newer MCU_FIRM versions this is unused, but on older MCU_FIRM versions this is a read-only counter.
|-
| 0x5B
- 0x5F
| s
| -
| These registers are out of bounds (0xFFC00 and up), they don't exist, writing is no-op, reading will yield FFs.
|-
| 0x60
| d
| rw
| Free register bank address (index) select
Selects the index to read from in the free register bank, up to 200. Used in conjunction with reg 0x61.

byte 0: bit0 = "WirelessDisabled", bit1 = "SoftwareClosed", bit2 = "PowerOffInitiated", bit3 = "LgyNativeResolution", bit4 = "LegacyJumpProhibited"
byte 1: Legacy LCD data
bytes 2 and 3: Local Friend Code counter
bytes 4 and 5: UUID clock sequence
bytes 6 and 7: Unused
bytes 8 to 175: Playtime data for legacy titles
bytes 176 to 188: Playtime data
bytes 188 to 199: Unused
|-
| 0x61
| d(200)
| rw
| Free register bank, data is read from/written to here.

Accessing N bytes of this register increments the selected index by N.
|-
| 0x62 - 0x7E
| s
| -
| These registers don't exist, writing is no-op, reading will yield FFs.
|-
| 0x7F
| d(9-0x13)
| ro
| Various system state information (debug pointer table)
byte 0x00: Console type, see [[Configuration_Memory#MCU_HW_INFO|here]]
byte 0x01: PMIC vendor code
byte 0x02: Battery vendor code
byte 0x03: MGIC version (major?)
byte 0x04: MGIC version (minor?)
byte 0x05: RCOMP(?)
byte 0x06: battery related? (seems to decrease while charging and increase while discharging)
byte 0x09: system model (see [[Cfg:GetSystemModel#System_Model_Values|Cfg:GetSystemModel]] for values)
byte 0x0A: Red Power LED mode (0 = off, 1 = on)
byte 0x0B: Blue Power LED intensity (0x00 - 0xFF)
byte 0x0D: RGB LED red intensity
byte 0x0E: RGB LED green intensity
byte 0x0F: RGB LED blue intensity
byte 0x11: WiFi LED brightness
byte 0x12: raw button states?
bit0: unset while Power button is held
bit1: unset while HOME button is held
bit2: unset while WiFi slider is held
bit5: unset while the charging LED is active
bit6: unset while charger is plugged in

On MCU_FIRM major version 1 the size of this is 9, reading past the 9th byte will yield AA instead of FF.
|-
| 0x80
- 0xFF
| s
| -
| These registers don't exist, writing is no-op, reading will yield FFs.
|}

Shared register: the letter "s" means that the given register is in a "shared register pool", meaning the resgister is in the register pool in RAM at address <code>0xFFBA4 + registernumber</code>.

Dynamic register: these registers aren't in the shared pool, they just "pretend" to be there. These registers often don't retain their set value, change rapidly, or control various hardware.

Non-shared (dynamic) register: it's a register whose contents separate from the shared register pool. Messing with these registers will not affect the shared register pool at all.

On old versions of MCU_FIRM none of the invalid registers are masked away by the read handler function, but are still read-only. Newer MCU_FIRM versions return the hardcoded value FF instead.

== 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 11 ==
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 [http://www.alldatasheet.net/datasheet-pdf/pdf/347838/NXP/SC16IS750IBS.html datasheet] linked to on the [[Hardware]] page for reference. From that datasheet, for the structure of the I2C register address u8: "Bit 0 is not used, bits 2:1 select the channel, bits 6:3 select one of the UART internal registers. Bit 7 is not used with the I2C-bus interface, but it is used by the SPI interface to indicate a read or a write operation."

== Device 14 ==

Used by [[Config_Services|Cfg]]-sysmodule via the i2c::EEP service. This is presumably EEPROM going by the service name.

The Cfg-module code which loads the [[Flash_Filesystem|CCAL]](nandro:/sys/{HWCAL0.dat/HWCAL1.dat}) file from NAND will load it from I2C instead, if a certain state flag is non-zero. Likewise for the function which writes CCAL to NAND. HMAC/hash verification after loading is skipped when the CCAL was loaded from I2C.

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

GPIO Services

2021-05-04T11:09:19Z

Unknown: /* GPIO Bits */ 0x100->Gyroscope

[[Category:Services]]
= GPIO Service Names =
{| class="wikitable" border="1"
|-
! Service name
! Permitted GPIO bitmasks
|-
| gpio:CDC
| 0x48
|-
| gpio:MCU
| 0x48020
|-
| gpio:HID
| 0x4301
|-
| gpio:NWM
| 0x40020
|-
| gpio:IR
| 0xEC0
|-
| gpio:NFC
| 0x13000
|-
| gpio:QTM
| 0x20000
|}

For the mapping between GPIO bitmasks and IRQs see: [[GPIO:BindInterrupt#Supported_values]].

The commands for these services are identical.

The input bitmask for each command is masked with the above permission bitmask, if the result is non-zero an error is occurred.

= GPIO Services =
{| class="wikitable" border="1"
|-
! Command Header
! Description
! Uses [[GPIO_Registers|GPIO Regs]]
|-
| 0x00010040
| u32 GetRegPart1(u32 mask)
| 0x10147010, 0x10147020
|-
| 0x00020080
| void SetRegPart1(u32 value, u32 mask)
| 0x10147010, 0x10147020
|-
| 0x00030040
| u32 GetRegPart2(u32 mask)
| 0x10147010, 0x10147024
|-
| 0x00040080
| u32 SetRegPart2(u32 value, u32 mask)
| 0x10147010, 0x10147024
|-
| 0x00050040
| u32 GetInterruptMask(u32 mask)
| 0x10147010, 0x10147024
|-
| 0x00060080
| void SetInterruptMask(u32 value, u32 mask)
| 0x10147010, 0x10147024
|-
| 0x00070040
| [[GPIO:GetGPIOData|GetGPIOData]]
| 0x10147000, 0x10147010, 0x10147014, 0x10147020, 0x10147028
|-
| 0x00080080
| [[GPIO:SetGPIOData|SetGPIOData]]
| 0x10147010, 0x10147014, 0x10147020, 0x10147028
|-
| 0x00090082
| [[GPIO:BindInterrupt|BindInterrupt]]
| None
|-
| 0x000A0042
| [[GPIO:UnbindInterrupt|UnbindInterrupt]]
| None
|}

=GPIO Bitmask=
The bitmask used by the service commands determines which bits in the GPIO registers to access. The output value from [[GPIO:GetGPIOData|GetGPIOData]] uses the same format as the bitmask: the values of bits in the output field are set to the value of GPIO data when those bits are set in the input bitmask.

{| class="wikitable" border="1"
|-
! Bits in the bitmask
! Register
! Bits from register
! Handled with [[GPIO:SetGPIOData]]
|-
| 0-2 (0x7)
| 0x10147000
| 0-2
| No
|-
| 3-4 (0x18)
| 0x10147010
| 0-1
| Yes
|-
| 5 (0x20)
| 0x10147014
| 0
| Yes
|-
| 6-17 (0x3FFC0)
| 0x10147020
| 0-11
| Yes
|-
| 18 (0x40000)
| 0x10147028
| 0
| Yes
|}

==GPIO Bits==
{| class="wikitable" border="1"
|-
! Bit
! Bitmask
! Accessible via GPIO service
! Used by
! Description
|-
| 0
| 0x1
| gpio:HID
| HID-sysmodule
| Used with [[HID_Shared_Memory|HID]] PAD state.
|-
| 1
| 0x2
| None
|
| Not known to be used by ''anything'', with the latest system-version at least.
|-
| 2
| 0x4
| None
|
| Not known to be used by ''anything'', with the latest system-version at least.
|-
| 3
| 0x8
| gpio:CDC
| ?
| ?
|-
| 4
| 0x10
| None
|
| Not known to be used by ''anything'', with the latest system-version at least.
|-
| 5
| 0x20
| gpio:MCU, gpio:NWM
| ?
| ?
|-
| 6
| 0x40
| gpio:CDC, gpio:IR
| ?
| ?
|-
| 7
| 0x80
| gpio:IR
| Boot11
| ?
|-
| 8
| 0x100
| gpio:HID
| HID sysmodule
| Used with gyroscope
|-
| 9
| 0x200
| gpio:HID, gpio:IR
| HID-sysmodule and IR-sysmodule
| Unknown, used with ir:rst.
|-
| 10
| 0x400
| gpio:IR
| IR-sysmodule, Boot11
| IR [[IRU:SetIRLEDState|send]]. 1 = IR LED enable, 0 = IR LED disable.
|-
| 11
| 0x800
| gpio:IR
| IR-sysmodule
| IR [[IRU:GetIRLEDRecvState|receive]]
|-
| 12
| 0x1000
| gpio:NFC
| ?
| ?
|-
| 13
| 0x2000
| gpio:NFC
| ?
| ?
|-
| 14
| 0x4000
| gpio:HID
| HID-sysmodule
| Used with [[HID_Shared_Memory|HID]] PAD state.
|-
| 15
| 0x8000
| gpio:MCU
| ?
| ?
|-
| 16
| 0x10000
| gpio:NFC
| ?
| ?
|-
| 17
| 0x20000
| gpio:QTM
| ?
| ?
|-
| 18
| 0x40000
| gpio:MCU, gpio:NWM
| NWM-sysmodule
| Wifi enable. 1=Enabled, 0=Disabled.
|}

11.14.0-46

2020-11-18T13:35:00Z

Unknown: /* NATIVE_FIRM */

The Old3DS+New3DS 11.14.0-46 system update was released for all regions on November 17, 2020. This Old3DS update was released for the following regions: USA, EUR, JPN, CHN, KOR, and TWN. This New3DS update was released for the following regions: USA, EUR, JPN, CHN, KOR, and TWN.

==Change-log==
[https://en-americas-support.nintendo.com/app/answers/detail/a_id/667/p/430/c/267 Official] USA change-log:
* TBD

==System Titles==
===NATIVE_FIRM===
* Kernel11 was updated, svcBindInterrupt will now only bind to ARM11 interrupt 15(fiq related) if its running on debug hardware, otherwise 0xD8E007EE is returned.

===Friends driver===
* Reported version upgraded to 0xF
===SSL driver===
* TBD, possibly TLS 1.3 support and/or an update to root certificates.
===Internet Browser===
* Fix for both exploits used in zoogie's browserhax 2020
* TBD, possibly TLS 1.3 support and/or an update to root certificates.
===Hotspot list===
* "nintendo[1-5]", "NCL-NZSERVICE[2-5]", and "nzae200818" removed
* All remaining SSIDs except "NintendoSpotPass[1-2]" are not Nintendo Zones anymore.

==See Also==
System update report(s):
* [https://yls8.mtheall.com/ninupdates/reports.php?date=2020-11-17_00-00-33&sys=ctr]
* [https://yls8.mtheall.com/ninupdates/reports.php?date=2020-11-17_00-00-38&sys=ktr]

Services

2020-10-30T11:27:24Z

Unknown: /* Notifications */

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

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

Processes with PID less than or equal to the number of NATIVE_FIRM built-in modules (fs, sm, pm, pxi, ldr) have access to all services. This value is obtained from [[SVC|svcGetSystemInfo]]. Other processes are limited to access services listed in their [[NCCH/Extended_Header#ARM11_Local_System_Capabilities|service access control list]], as passed to [[SRVPM:RegisterProcess]].

Attempting to use [[SRV:GetServiceHandle|GetServiceHandle]] with a service that the process has access to when that service isn't registered will block until it is registered.

==Service Manager Port "srv:"==
{| class="wikitable" border="1"
|-
! Command Header
! Description
|-
| 0x00010002
| [[SRV:RegisterClient|RegisterClient]]
|-
| 0x00020000
| [[SRV:EnableNotification|EnableNotification]]
|-
| 0x00030100
| [[SRV:RegisterService|RegisterService]]
|-
| 0x000400C0
| [[SRV:UnregisterService|UnregisterService]]
|-
| 0x00050100
| [[SRV:GetServiceHandle|GetServiceHandle]]
|-
| 0x000600C2
| [[SRV:RegisterPort|RegisterPort]]
|-
| 0x000700C0
| [[SRV:UnregisterPort|UnregisterPort]]
|-
| 0x00080100
| [[SRV:GetPort|GetPort]]
|-
| 0x00090040
| [[SRV:Subscribe|Subscribe]]
|-
| 0x000A0040
| [[SRV:Unsubscribe|Unsubscribe]]
|-
| 0x000B0000
| [[SRV:ReceiveNotification|ReceiveNotification]]
|-
| 0x000C0080
| [[SRV:PublishToSubscriber|PublishToSubscriber]]
|-
| 0x000D0040
| [[SRV:PublishAndGetSubscriber|PublishAndGetSubscriber]]
|-
| 0x000E00C0
| [[SRV:IsServiceRegistered|IsServiceRegistered]]
|}

It appears these "port" commands can be used for transferring arbitrary handles, however [[SRV:GetPort|GetPort]] still uses the same service-access-control validation as [[SRV:GetServiceHandle|GetServiceHandle]]. Despite this fact, it appears that a "port" and a service with the same name can coexist independently.

==Service Manager Process-Manager Port/Service "srv:pm"==
{| class="wikitable" border="1"
|-
! Command Header (port), prior to [[7.0.0-13]]
! Command Header (service), post [[7.0.0-13]]
! Description
|-
| 0x04010042
| 0x00010042
| [[SRVPM:PublishToProcess|PublishToProcess]]
|-
| 0x04020040
| 0x00020040
| [[SRVPM:PublishToAll|PublishToAll]]
|-
| 0x04030082
| 0x00030082
| [[SRVPM:RegisterProcess|RegisterProcess]]
|-
| 0x04040040
| 0x00040040
| [[SRVPM:UnregisterProcess|UnregisterProcess]]
|}

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

==Notifications==
{| class="wikitable" border="1"
|-
! ID
! Published by
! Subscribed by
! Description
|-
| 0x100
|
| Not Needed
| This indicates that the recipient must terminate.
|-
| 0x101
| PTM
| NS
| Signaled on sleep mode entry.
|-
| 0x102
| PTM
| NS
| Sleep Mode related?
|-
| 0x103
| PTM
| NS, CSND, NWM, AC, NIM
| Fired on sleep mode entry (Kernel state is modified by PTM after publishing this)
|-
| 0x104
| PTM
| HID
| This indicates that the system is entering sleep mode. (Kernel state is modified by PTM before publishing this)
|-
| 0x105
| PTM
| NS, DSP, CSND, GSP, CODEC, CAMERA, HID, QTM, MIC, IR, NWM, FRIENDS, AC, CECD, ACT, NDM, NIM
| This indicates that the system has exited sleep mode.
|-
| 0x106
| PTM
| NS, MIC, AC, NEWS, CECD, BOSS
| Fired after sleep mode exit.
|-
| 0x107
| PTM
| NWM, CECD, BOSS, NDM, NIM, NEWS
| Unknown.
|-
| 0x108
| PTM
| GSP, QTM
| System is going to Power Down.
|-
| 0x109
| CFG
| GSP
| CFG block 0x00050001 has been modified, change LCD brightness/PWM settings
|-
| 0x10B
| CFG
| CAMERA
| ?
|-
| 0x10C
| PM
|
| A Regular application has started.
|-
| 0x110-0x11F
| PM
| NS
| Sent on application exit. See [[PMApp:LaunchTitle#Launch_Flags|PM launch flags]].
|-
| 0x179
| PM
| PTM, NS
| All processes other than PTM and NS have terminated.
|-
| 0x200
|
| NS
| Signaled just before sleep mode is exited from.
|-
| 0x202
| MCU
| NS
| POWER button pressed
|-
| 0x203
| MCU
| NS
| POWER button held long
|-
| 0x204
| MCU
| NS
| HOME button pressed
|-
| 0x205
| MCU
| NS
| HOME button released
|-
| 0x206
| MCU / NWM
| NWM
| The physical Wi-Fi slider state changed
|-
| 0x207
|
| MENU
| SD card inserted
|-
| 0x208
|
| MENU
| Game cartridge inserted
|-
| 0x209
|
| NS, MENU
| SD card removed
|-
| 0x20A
|
| NS, MENU
| Game cartridge removed
|-
| 0x20B
|
| NS, MENU
| Game cartridge inserted or removed
|-
| 0x20C
| MCU
| PTM
| Published on a (fatal) hardware condition?, ptm throws fatal error F960D407 in receipt of this
|-
| 0x20D
| MCU
| GSP
| Charger plugged out.
|-
| 0x20E
| MCU
| GSP
| Charger plugged in.
|-
| 0x20F
| MCU
|
| Published by the mcu module when (bitmask & 0x8000) is true. This bitmask is obtained by reading i2c register 0x10.
|-
| 0x210
| MCU
|
| Published by the mcu module when (bitmask & 0x4000) is true. This bitmask is obtained by reading i2c register 0x10.
|-
| 0x211
| PTM
|
| Battery very low (5%)
|-
| 0x212
| PTM
|
| Battery low (10%)
|-
| 0x213
| NS
| CODEC, HID, GSP, CAMERA, MIC, NDM, QTM, PTM
| Shell opened.
|-
| 0x214
| NS
| CODEC, HID, GSP, CAMERA, MIC, NDM, QTM, PTM.
| Shell closed.
|-
| 0x300
| AC
| NDM, MENU
| Signaled after sleep mode exit and during system boot.
|-
| 0x301
| AC
| FRIENDS, NDM
| Signaled just before sleep mode is exited from.
|-
| 0x302
| NWM
| NDM, SOCKET, FRIENDS, AC
| Unknown.
|-
| 0x303
|
| CECD, NDM
| Unknown.
|-
| 0x304
|
| CECD, NDM, SOCKET
| Unknown
|}

WIFI Registers

2020-08-07T14:24:01Z

Unknown: /* Registers */ Fix a wrong address

These registers are used to control the WiFi card via the SDIO protocol.

=Registers=

{| class="wikitable" border="1"
! Name
! Address
! Width
|-
| WIFI_CMD
| 0x10122000
| 2
|-
| ?
| 0x10122002
| 2
|-
| WIFI_CMDARG0
| 0x10122004
| 2
|-
| WIFI_CMDARG1
| 0x10122006
| 2
|-
| WIFI_BLKCOUNT
| 0x1012200a
| 2
|-
| WIFI_CLKCTL
| 0x10122024
| 2
|-
| WIFI_BLKLEN
| 0x10122026
| 2
|-
|}

Camera Services

2020-08-06T07:41:03Z

Unknown: /* cam:q (PORT_QTM) */ Add note and rest of the commands which are common

==cam:c (PORT_REG) ==
Same as [[#cam:u_.28PORT_USER.29|cam:u]]

==cam:s (PORT_CAL) ==
Same as [[#cam:u_.28PORT_USER.29|cam:u]]

==cam:q (PORT_QTM) ==
This was added with New3DS.

{| class="wikitable" border="1"
|-
! Command Header
! Description
|-
| 0x00010040
| [[CAMU:StartCapture|StartCapture]]
|-
| 0x00020040
| [[CAMU:StopCapture|StopCapture]]
|-
| 0x0003004?
| [[CAMU:IsBusy|IsBusy]]
|-
| 0x00040040
| [[CAMU:ClearBuffer|ClearBuffer]]
|-
| 0x0005004?
| [[CAMU:GetVsyncInterruptEvent|GetVsyncInterruptEvent]]
|-
| 0x0006004?
| [[CAMU:GetBufferErrorInterruptEvent|GetBufferErrorInterruptEvent]]
|-
| 0x0007????
| [[CAMU:StartRecieving|StartRecieving]]
|-
| 0x00080040
| [[CAMU:IsFinishedRecieving|IsFinishedRecieving]]
|-
| 0x00090100
| [[CAMU:SetTransferLines|SetTransferLines]]
|-
| 0x000A008?
| [[CAMU:GetMaxLines|GetMaxLines]]
|-
| 0x000B0100
| [[CAMU:SetTransferBytes|SetTransferBytes]]
|-
| 0x000C004?
| [[CAMU:GetTransferBytes|GetTransferBytes]]
|-
| 0x000D008?
| [[CAMU:GetMaxBytes|GetMaxBytes]]
|-
| 0x000E0080
| [[CAMU:SetTrimming|SetTrimming]]
|-
| 0x000F004?
| [[CAMU:IsTrimming|IsTrimming]]
|-
| 0x00100140
| [[CAMU:SetTrimmingParams|SetTrimmingParams]]
|-
| 0x0011????
| [[CAMU:GetTrimmingParams|GetTrimmingParams]]
|-
| 0x00120140
| [[CAMU:SetTrimmingParamsCenter|SetTrimmingParamsCenter]]
|-
| 0x00130040
| [[CAMU:Activate|Activate]]
|-
| 0x00140080
| [[CAMU:SwitchContext|SwitchContext]]
|-
| 0x00150080
| [[CAMU:SetExposure|SetExposure]]
|-
| 0x00160080
| [[CAMU:SetWhiteBalance|SetWhiteBalance]]
|-
| 0x00170080
| [[CAMU:SetSharpness|SetSharpness]]
|-
| 0x00180080
| [[CAMU:SetAutoExposure|SetAutoExposure]]
|-
| 0x0019004?
| [[CAMU:IsAutoExposure|IsAutoExposure]]
|-
| 0x001A0080
| [[CAMU:SetAutoWhiteBalance|SetAutoWhiteBalance]]
|-
| 0x001B004?
| [[CAMU:IsAutoWhiteBalance|IsAutoWhiteBalance]]
|-
| 0x001C00C0
| [[CAMU:FlipImage|FlipImage]]
|-
| 0x001D020?
| [[CAMU:SetDetailSize|SetDetailSize]]
|-
| 0x001E00C0
| [[CAMU:SetSize|SetSize]]
|-
| 0x001F0080
| [[CAMU:SetFrameRate|SetFrameRate]]
|-
| 0x00200080
| [[CAMU:SetPhotoMode|SetPhotoMode]]
|-
| 0x002100C0
| [[CAMU:SetEffect|SetEffect]]
|-
| 0x00220080
| [[CAMU:SetContrast|SetContrast]]
|-
| 0x00230080
| [[CAMU:SetLensCorrection|SetLensCorrection]]
|-
| 0x002400C0
| [[CAMU:SetOutputFormat|SetOutputFormat]]
|-
| 0x0025014?
| [[CAMU:SetAutoExposureWindow|SetAutoExposureWindow]]
|-
| 0x0026014?
| [[CAMU:SetAutoWhiteBalanceWindow|SetAutoWhiteBalanceWindow]]
|-
| 0x00270080
| [[CAMU:SetNoiseFilter|SetNoiseFilter]]
|-
| 0x00280080
| [[CAMU:SyncronizeVsyncTiming|SyncronizeVsyncTiming]]
|-
| 0x0029????
| [[CAMU:GetLatestVsyncTiming|GetLatestVsyncTiming]]
|-
| 0x002A????
| [[CAMU:GetStereoCallibrationData|GetStereoCallibrationData]]
|-
| 0x002B????
| [[CAMU:SetPackageParameterWithoutContext|SetPackageParameterWithoutContext]]
|-
| 0x002C0080
| [[CAMU:SetPackageParameterWithContext|SetPackageParameterWithContext]]
|-
| 0x002D????
| [[CAMU:SetPackageParameterWithContextDetail|SetPackageParameterWithContextDetail]]
|-
| 0x002E???
| [[CAMU:GetSuitableY2RStandardCoeffecient|GetSuitableY2RStandardCoeffecient]]
|-
| 0x002F
| [[CAMU:PlayShutterSoundWithWave|PlayShutterSoundWithWave]]
|-
| 0x0030????
| [[CAMU:PlayShutterSound|GetShutterSound]]
|-
| 0x0031000?
| [[CAMU:DriverInitailize|DriverInitialize]]
|-
| 0x0032000?
| [[CAMU:DriverFinalize|DriverFinalize]]
|-
| 0x0033000?
| [[CAMU:GetActivatedCamera|GetActivatedCamera]]
|-
| 0x0034000?
| [[CAMU:GetSleepCamera|GetSleepCamera]]
|-
| 0x00350040
| [[CAMU:SetSleepCamera|SetSleepCamera]]
|-
| 0x00360040
| [[CAMU:SetBrightnessSyncronization|SetBrightnessSyncronization]]
|-
| 0x0037004?
| ???
|-
| 0x0038000?
| ???
|-
| 0x0039004?
| ???
|-
| 0x003A0080
| ???
|-
| 0x003B004?
| ???
|-
| 0x003C0080
| ???
|-
| 0x003D000?
| ???
|-
| 0x003E0000
| ???
|}

Most commands are same as cam:u, although, with different command headers since some commands which are available in cam:u do not exist in cam:q

==cam:u (PORT_USER)==
{| class="wikitable" border="1"
|-
! Command Header
! Description
|-
| 0x00010040
| [[CAMU:StartCapture|StartCapture]]
|-
| 0x00020040
| [[CAMU:StopCapture|StopCapture]]
|-
| 0x00030040
| [[CAMU:IsBusy|IsBusy]]
|-
| 0x00040040
| [[CAMU:ClearBuffer|ClearBuffer]]
|-
| 0x00050040
| [[CAMU:GetVsyncInterruptEvent|GetVsyncInterruptEvent]]
|-
| 0x00060040
| [[CAMU:GetBufferErrorInterruptEvent|GetBufferErrorInterruptEvent]]
|-
| 0x00070102
| [[CAMU:SetReceiving|SetReceiving]]
|-
| 0x00080040
| [[CAMU:IsFinishedReceiving|IsFinishedReceiving]]
|-
| 0x00090100
| [[CAMU:SetTransferLines|SetTransferLines]]
|-
| 0x000A0080
| [[CAMU:GetMaxLines|GetMaxLines]]
|-
| 0x000B0100
| [[CAMU:SetTransferBytes|SetTransferBytes]]
|-
| 0x000C0040
| [[CAMU:GetTransferBytes|GetTransferBytes]]
|-
| 0x000D0080
| [[CAMU:GetMaxBytes|GetMaxBytes]]
|-
| 0x000E0080
| [[CAMU:SetTrimming|SetTrimming]]
|-
| 0x000F0040
| [[CAMU:IsTrimming|IsTrimming]]
|-
| 0x00100140
| [[CAMU:SetTrimmingParams|SetTrimmingParams]]
|-
| 0x00110040
| [[CAMU:GetTrimmingParams|GetTrimmingParams]]
|-
| 0x00120140
| [[CAMU:SetTrimmingParamsCenter|SetTrimmingParamsCenter]]
|-
| 0x00130040
| [[CAMU:Activate|Activate]]
|-
| 0x00140080
| [[CAMU:SwitchContext|SwitchContext]]
|-
| 0x00150080
| [[CAMU:SetExposure|SetExposure]]
|-
| 0x00160080
| [[CAMU:SetWhiteBalance|SetWhiteBalance]]
|-
| 0x00170080
| [[CAMU:SetWhiteBalanceWithoutBaseUp|SetWhiteBalanceWithoutBaseUp]]
|-
| 0x00180080
| [[CAMU:SetSharpness|SetSharpness]]
|-
| 0x00190080
| [[CAMU:SetAutoExposure|SetAutoExposure]]
|-
| 0x001A0040
| [[CAMU:IsAutoExposure|IsAutoExposure]]
|-
| 0x001B0080
| [[CAMU:SetAutoWhiteBalance|SetAutoWhiteBalance]]
|-
| 0x001C0040
| [[CAMU:IsAutoWhiteBalance|IsAutoWhiteBalance]]
|-
| 0x001D00C0
| [[CAMU:FlipImage|FlipImage]]
|-
| 0x001E0200
| [[CAMU:SetDetailSize|SetDetailSize]]
|-
| 0x001F00C0
| [[CAMU:SetSize|SetSize]]
|-
| 0x00200080
| [[CAMU:SetFrameRate|SetFrameRate]]
|-
| 0x00210080
| [[CAMU:SetPhotoMode|SetPhotoMode]]
|-
| 0x002200C0
| [[CAMU:SetEffect|SetEffect]]
|-
| 0x00230080
| [[CAMU:SetContrast|SetContrast]]
|-
| 0x00240080
| [[CAMU:SetLensCorrection|SetLensCorrection]]
|-
| 0x002500C0
| [[CAMU:SetOutputFormat|SetOutputFormat]]
|-
| 0x00260140
| [[CAMU:SetAutoExposureWindow|SetAutoExposureWindow]]
|-
| 0x00270140
| [[CAMU:SetAutoWhiteBalanceWindow|SetAutoWhiteBalanceWindow]]
|-
| 0x00280080
| [[CAMU:SetNoiseFilter|SetNoiseFilter]]
|-
| 0x00290080
| [[CAMU:SynchronizeVsyncTiming|SynchronizeVsyncTiming]]
|-
| 0x002A0080
| [[CAMU:GetLatestVsyncTiming|GetLatestVsyncTiming]]
|-
| 0x002B0000
| [[CAMU:GetStereoCameraCalibrationData|GetStereoCameraCalibrationData]]
|-
| 0x002C0400
| [[CAMU:SetStereoCameraCalibrationData|SetStereoCameraCalibrationData]]
|-
| 0x002D00C0
| [[CAMU:WriteRegisterI2c|WriteRegisterI2c]]
|-
| 0x002E00C0
| [[CAMU:WriteMcuVariableI2c|WriteMcuVariableI2c]]
|-
| 0x002F0080
| [[CAMU:ReadRegisterI2cExclusive|ReadRegisterI2cExclusive]]
|-
| 0x00300080
| [[CAMU:ReadMcuVariableI2cExclusive|ReadMcuVariableI2cExclusive]]
|-
| 0x00310180
| [[CAMU:SetImageQualityCalibrationData|SetImageQualityCalibrationData]]
|-
| 0x00320000
| [[CAMU:GetImageQualityCalibrationData|GetImageQualityCalibrationData]]
|-
| 0x003302C0
| [[CAMU:SetPackageParameterWithoutContext|SetPackageParameterWithoutContext]]
|-
| 0x00340140
| [[CAMU:SetPackageParameterWithContext|SetPackageParameterWithContext]]
|-
| 0x003501C0
| [[CAMU:SetPackageParameterWithContextDetail|SetPackageParameterWithContextDetail]]
|-
| 0x00360000
| [[CAMU:GetSuitableY2rStandardCoefficient|GetSuitableY2rStandardCoefficient]]
|-
| 0x00370202
| [[CAMU:PlayShutterSoundWithWave|PlayShutterSoundWithWave]]
|-
| 0x00380040
| [[CAMU:PlayShutterSound|PlayShutterSound]]
|-
| 0x00390000
| [[CAMU:DriverInitialize|DriverInitialize]]
|-
| 0x003A0000
| [[CAMU:DriverFinalize|DriverFinalize]]
|-
| 0x003B0000
| [[CAMU:GetActivatedCamera|GetActivatedCamera]]
|-
| 0x003C0000
| [[CAMU:GetSleepCamera|GetSleepCamera]]
|-
| 0x003D0040
| [[CAMU:SetSleepCamera|SetSleepCamera]]
|-
| 0x003E0040
| [[CAMU:SetBrightnessSynchronization|SetBrightnessSynchronization]]
|-
| 0x003F0040
| Stubbed, always returns 0
|-
| 0x004000C0
| ???
|-
| 0x00410040
| Stubbed, returns D8A053EA if flag is not 1
|-
| 0x00420040
| ???
|-
| 0x00430000
| Stubbed, returns D8A053EA if flag is not 1
|-
| 0x00440000
| Stubbed, returns D8A053EA if flag is not 1
|}

===Port===
{| class="wikitable" border="1"
|-
! Enum
! Value
|-
| PORT_NONE
| 0x0
|-
| PORT_CAM1
| 0x1 << 0x0
|-
| PORT_CAM2
| 0x1 << 0x1
|-
| PORT_BOTH
| PORT_CAM1 <nowiki>|</nowiki> PORT_CAM2
|}

===CameraSelect===
{| class="wikitable" border="1"
|-
! Enum
! Value
|-
| SELECT_NONE
| 0x0
|-
| SELECT_OUT1
| 0x1 << 0x0
|-
| SELECT_IN1
| 0x1 << 0x1
|-
| SELECT_OUT2
| 0x1 << 0x2
|-
| SELECT_IN1_OUT1
| SELECT_OUT1 <nowiki>|</nowiki> SELECT_IN1
|-
| SELECT_OUT1_OUT2
| SELECT_OUT1 <nowiki>|</nowiki> SELECT_OUT2
|-
| SELECT_IN1_OUT2
| SELECT_IN1 <nowiki>|</nowiki> SELECT_OUT2
|-
| SELECT_ALL
| SELECT_OUT1 <nowiki>|</nowiki> SELECT_IN1 <nowiki>|</nowiki> SELECT_OUT2
|}

===Context===
{| class="wikitable" border="1"
|-
! Enum
! Value
|-
| CONTEXT_NONE
| 0x0
|-
| CONTEXT_A
| 0x1 << 0x0
|-
| CONTEXT_B
| 0x1 << 0x1
|-
| CONTEXT_BOTH
| CONTEXT_A <nowiki>|</nowiki> CONTEXT_B
|}

===Flip===
{| class="wikitable" border="1"
|-
! Enum
! Value
|-
| FLIP_NONE
| 0x0
|-
| FLIP_HORIZONTAL
| 0x1
|-
| FLIP_VERTICAL
| 0x2
|-
| FLIP_REVERSE
| 0x3
|}

===Size===
{| class="wikitable" border="1"
|-
! Enum
! Value
|-
| SIZE_VGA
| 0x0
|-
| SIZE_QVGA
| 0x1
|-
| SIZE_QQVGA
| 0x2
|-
| SIZE_CIF
| 0x3
|-
| SIZE_QCIF
| 0x4
|-
| SIZE_DS_LCD
| 0x5
|-
| SIZE_DS_LCDx4
| 0x6
|-
| SIZE_CTR_TOP_LCD
| 0x7
|-
| SIZE_CTR_BOTTOM_LCD
| SIZE_QVGA
|}

===FrameRate===
{| class="wikitable" border="1"
|-
! Enum
! Value
|-
| FRAME_RATE_15
| 0x0
|-
| FRAME_RATE_15_TO_5
| 0x1
|-
| FRAME_RATE_15_TO_2
| 0x2
|-
| FRAME_RATE_10
| 0x3
|-
| FRAME_RATE_8_5
| 0x4
|-
| FRAME_RATE_5
| 0x5
|-
| FRAME_RATE_20
| 0x6
|-
| FRAME_RATE_20_TO_5
| 0x7
|-
| FRAME_RATE_30
| 0x8
|-
| FRAME_RATE_30_TO_5
| 0x9
|-
| FRAME_RATE_15_TO_10
| 0xA
|-
| FRAME_RATE_20_TO_10
| 0xB
|-
| FRAME_RATE_30_TO_10
| 0xC
|}

===WhiteBalance===
{| class="wikitable" border="1"
|-
! Enum
! Value
|-
| WHITE_BALANCE_AUTO
| 0x0
|-
| WHITE_BALANCE_3200K
| 0x1
|-
| WHITE_BALANCE_4150K
| 0x2
|-
| WHITE_BALANCE_5200K
| 0x3
|-
| WHITE_BALANCE_6000K
| 0x4
|-
| WHITE_BALANCE_7000K
| 0x5
|-
| WHITE_BALANCE_MAX
| 0x6
|-
| WHITE_BALANCE_NORMAL
| WHITE_BALANCE_AUTO
|-
| WHITE_BALANCE_TUNGSTEN
| WHITE_BALANCE_3200K
|-
| WHITE_BALANCE_WHITE_FLUORESCENT_LIGHT
| WHITE_BALANCE_4150K
|-
| WHITE_BALANCE_DAYLIGHT
| WHITE_BALANCE_5200K
|-
| WHITE_BALANCE_CLOUDY
| WHITE_BALANCE_6000K
|-
| WHITE_BALANCE_HORIZON
| WHITE_BALANCE_6000K
|-
| WHITE_BALANCE_SHADE
| WHITE_BALANCE_7000K
|}

===PhotoMode===
{| class="wikitable" border="1"
|-
! Enum
! Value
|-
| PHOTO_MODE_NORMAL
| 0x0
|-
| PHOTO_MODE_PORTRAIT
| 0x1
|-
| PHOTO_MODE_LANDSCAPE
| 0x2
|-
| PHOTO_MODE_NIGHTVIEW
| 0x3
|-
| PHOTO_MODE_LETTER
| 0x4
|}

===Effect===
{| class="wikitable" border="1"
|-
! Enum
! Value
|-
| EFFECT_NONE
| 0x0
|-
| EFFECT_MONO
| 0x1
|-
| EFFECT_SEPIA
| 0x2
|-
| EFFECT_NEGATIVE
| 0x3
|-
| EFFECT_NEGAFILM
| 0x4
|-
| EFFECT_SEPIA01
| 0x5
|}

===Contrast===
{| class="wikitable" border="1"
|-
! Enum
! Value
|-
| CONTRAST_PATTERN_01
| 0x0
|-
| CONTRAST_PATTERN_02
| 0x1
|-
| CONTRAST_PATTERN_03
| 0x2
|-
| CONTRAST_PATTERN_04
| 0x3
|-
| CONTRAST_PATTERN_05
| 0x4
|-
| CONTRAST_PATTERN_06
| 0x5
|-
| CONTRAST_PATTERN_07
| 0x6
|-
| CONTRAST_PATTERN_08
| 0x7
|-
| CONTRAST_PATTERN_09
| 0x8
|-
| CONTRAST_PATTERN_10
| 0x9
|-
| CONTRAST_PATTERN_11
| 0xA
|-
| CONTRAST_LOW
| CONTRAST_PATTERN_05
|-
| CONTRAST_NORMAL
| CONTRAST_PATTERN_06
|-
| CONTRAST_HIGH
| CONTRAST_PATTERN_07
|}

===LensCorrection===
{| class="wikitable" border="1"
|-
! Enum
! Value
|-
| LENS_CORRECTION_OFF
| 0x0
|-
| LENS_CORRECTION_ON_70
| 0x1
|-
| LENS_CORRECTION_ON_90
| 0x2
|-
| LENS_CORRECTION_DARK
| LENS_CORRECTION_OFF
|-
| LENS_CORRECTION_NORMAL
| LENS_CORRECTION_ON_70
|-
| LENS_CORRECTION_BRIGHT
| LENS_CORRECTION_ON_90
|}

===OutputFormat===
{| class="wikitable" border="1"
|-
! Enum
! Value
|-
| OUTPUT_YUV_422
| 0x0
|-
| OUTPUT_RGB_565
| 0x1
|}

===ShutterSoundType===
{| class="wikitable" border="1"
|-
! Enum
! Value
|-
| SHUTTER_SOUND_TYPE_NORMAL
| 0x0
|-
| SHUTTER_SOUND_TYPE_MOVIE
| 0x1
|-
| SHUTTER_SOUND_TYPE_MOVIE_END
| 0x2
|}

===ImageQualityCalibrationData===
{| class="wikitable" border="1"
! Type
! Field
|-
| s16
| aeBaseTarget
|-
| s16
| kRL
|-
| s16
| kGL
|-
| s16
| kBL
|-
| s16
| ccmPosition
|-
| u16
| awbCcmL9Right
|-
| u16
| awbCcmL9Left
|-
| u16
| awbCcmL10Right
|-
| u16
| awbCcmL10Left
|-
| u16
| awbX0Right
|-
| u16
| awbX0Left
|}

===StereoCameraCalibrationData===
{| class="wikitable" border="1"
! Type
! Field
|-
| bool
| isValidRotationXY
|-
| bool[3]
| reservedFlag
|-
| float
| scale
|-
| float
| rotationZ
|-
| float
| translationX
|-
| float
| translationY
|-
| float
| rotationX
|-
| float
| rotationY
|-
| float
| angleOfViewRight
|-
| float
| angleOfViewLeft
|-
| float
| distanceToChart
|-
| float
| distanceCameras
|-
| s16
| imageWidth
|-
| s16
| imageHeight
|-
| u8[16]
| reserved
|}

===PackageParameterCameraSelect===
{| class="wikitable" border="1"
! Type
! Field
|-
| u8
| [[Camera_Services#CameraSelect|CameraSelect]] camera
|-
| s8
| exposure
|-
| u8
| [[Camera_Services#WhiteBalance|WhiteBalance]] whiteBalance
|-
| s8
| sharpness
|-
| bool
| autoExposureOn
|-
| bool
| autoWhiteBalanceOn
|-
| u8
| [[Camera_Services#FrameRate|FrameRate]] frameRate
|-
| u8
| [[Camera_Services#PhotoMode|PhotoMode]] photoMode
|-
| u8
| contrast
|-
| u8
| [[Camera_Services#LensCorrection|LensCorrection]] lensCorrection
|-
| bool
| noiseFilterOn
|-
| u8
| padding
|-
| s16
| autoExposureWindowX
|-
| s16
| autoExposureWindowY
|-
| s16
| autoExposureWindowWidth
|-
| s16
| autoExposureWindowHeight
|-
| s16
| autoWhiteBalanceWindowX
|-
| s16
| autoWhiteBalanceWindowY
|-
| s16
| autoWhiteBalanceWindowWidth
|-
| s16
| autoWhiteBalanceWindowHeight
|}

===PackageParameterContext===
{| class="wikitable" border="1"
! Type
! Field
|-
| u8
| [[Camera_Services#CameraSelect|CameraSelect]] camera
|-
| u8
| [[Camera_Services#Context|Context]] context
|-
| u8
| [[Camera_Services#Flip|Flip]] flip
|-
| u8
| [[Camera_Services#Effect|Effect]] effect
|-
| u8
| [[Camera_Services#Size|Size]] size
|}

===PackageParameterContextDetail===
{| class="wikitable" border="1"
! Type
! Field
|-
| u8
| [[Camera_Services#CameraSelect|CameraSelect]] camera
|-
| u8
| [[Camera_Services#Context|Context]] context
|-
| u8
| [[Camera_Services#Flip|Flip]] flip
|-
| u8
| [[Camera_Services#Effect|Effect]] effect
|-
| s16
| width
|-
| s16
| height
|-
| s16
| cropX0
|-
| s16
| cropY0
|-
| s16
| cropX1
|-
| s16
| cropY1
|}

== y2r:u ==
{| class="wikitable" border="1"
|-
! Command Header
! Description
|-
| 0x00010040
| [[Y2R:SetInputFormat|SetInputFormat]]
|-
| 0x00020000
| [[Y2R:GetInputFormat|GetInputFormat]]
|-
| 0x00030040
| [[Y2R:SetOutputFormat|SetOutputFormat]]
|-
| 0x00040000
| [[Y2R:GetOutputFormat|GetOutputFormat]]
|-
| 0x00050040
| [[Y2R:SetRotation|SetRotation]]
|-
| 0x00060000
| [[Y2R:GetRotation|GetRotation]]
|-
| 0x00070040
| [[Y2R:SetBlockAlignment|SetBlockAlignment]]
|-
| 0x00080000
| [[Y2R:GetBlockAlignment|GetBlockAlignment]]
|-
| 0x00090040
| [[Y2R:SetSpacialDithering|SetSpacialDithering]]
|-
| 0x000A0000
| [[Y2R:GetSpacialDithering|GetSpacialDithering]]
|-
| 0x000B0040
| [[Y2R:SetTemporalDithering|SetTemporalDithering]]
|-
| 0x000C0000
| [[Y2R:GetTemporalDithering|GetTemporalDithering]]
|-
| 0x000D0040
| [[Y2R:SetTransferEndInterrupt|SetTransferEndInterrupt]]
|-
| 0x000E0000
| [[Y2R:GetTransferEndInterrupt|GetTransferEndInterrupt]]
|-
| 0x000F0000
| [[Y2R:GetTransferEndEvent|GetTransferEndEvent]]
|-
| 0x00100102
| [[Y2R:SetSendingY|SetSendingY]]
|-
| 0x00110102
| [[Y2R:SetSendingU|SetSendingU]]
|-
| 0x00120102
| [[Y2R:SetSendingV|SetSendingV]]
|-
| 0x00130102
| [[Y2R:SetSendingYuv|SetSendingYuv]]
|-
| 0x00140000
| [[Y2R:IsFinishedSendingYuv|IsFinishedSendingYuv]]
|-
| 0x00150000
| [[Y2R:IsFinishedSendingY|IsFinishedSendingY]]
|-
| 0x00160000
| [[Y2R:IsFinishedSendingU|IsFinishedSendingU]]
|-
| 0x00170000
| [[Y2R:IsFinishedSendingV|IsFinishedSendingV]]
|-
| 0x00180102
| [[Y2R:SetReceiving|SetReceiving]]
|-
| 0x00190000
| [[Y2R:IsFinishedReceiving|IsFinishedReceiving]]
|-
| 0x001A0040
| [[Y2R:SetInputLineWidth|SetInputLineWidth]]
|-
| 0x001B0000
| [[Y2R:GetInputLineWidth|GetInputLineWidth]]
|-
| 0x001C0040
| [[Y2R:SetInputLines|SetInputLines]]
|-
| 0x001D0000
| [[Y2R:GetInputLines|GetInputLines]]
|-
| 0x001E0100
| [[Y2R:SetCoefficientParams|SetCoefficientParams]]
|-
| 0x001F0000
| [[Y2R:GetCoefficientParams|GetCoefficientParams]]
|-
| 0x00200040
| [[Y2R:SetStandardCoefficient|SetStandardCoefficient]]
|-
| 0x00210040
| [[Y2R:GetStandardCoefficientParams|GetStandardCoefficientParams]]
|-
| 0x00220040
| [[Y2R:SetAlpha|SetAlpha]]
|-
| 0x00230000
| [[Y2R:GetAlpha|GetAlpha]]
|-
| 0x00240200
| [[Y2R:SetDitheringWeightParams|SetDitheringWeightParams]]
|-
| 0x00250000
| [[Y2R:GetDitheringWeightParams|GetDitheringWeightParams]]
|-
| 0x00260000
| [[Y2R:StartConversion|StartConversion]]
|-
| 0x00270000
| [[Y2R:StopConversion|StopConversion]]
|-
| 0x00280000
| [[Y2R:IsBusyConversion|IsBusyConversion]]
|-
| 0x002901C0
| [[Y2R:SetPackageParameter|SetPackageParameter]]
|-
| 0x002A0000
| [[Y2R:PingProcess|PingProcess]]
|-
| 0x002B0000
| [[Y2R:DriverInitialize|DriverInitialize]]
|-
| 0x002C0000
| [[Y2R:DriverFinalize|DriverFinalize]]
|-
| 0x002D0000
| [[Y2R:GetPackageParameter|GetPackageParameter]]
|}

===InputFormat===
{| class="wikitable" border="1"
|-
! Enum
! Value
|-
| INPUT_YUV422_INDIV_8
| 0x0
|-
| INPUT_YUV420_INDIV_8
| 0x1
|-
| INPUT_YUV422_INDIV_16
| 0x2
|-
| INPUT_YUV420_INDIV_16
| 0x3
|-
| INPUT_YUV422_BATCH
| 0x4
|}

===OutputFormat===
{| class="wikitable" border="1"
|-
! Enum
! Value
|-
| OUTPUT_RGB_32
| 0x0
|-
| OUTPUT_RGB_24
| 0x1
|-
| OUTPUT_RGB_16_555
| 0x2
|-
| OUTPUT_RGB_16_565
| 0x3
|}

===Rotation===
{| class="wikitable" border="1"
|-
! Enum
! Value
|-
| ROTATION_NONE
| 0x0
|-
| ROTATION_CLOCKWISE_90
| 0x1
|-
| ROTATION_CLOCKWISE_180
| 0x2
|-
| ROTATION_CLOCKWISE_270
| 0x3
|}

===BlockAlignment===
{| class="wikitable" border="1"
|-
! Enum
! Value
! Description
|-
| BLOCK_LINE
| 0x0
| Output buffer's pixels are arranged linearly. Used when outputting to the framebuffer.
|-
| BLOCK_8_BY_8
| 0x1
| Output buffer's pixels are morton swizzled. Used when outputting to a GPU texture.
|}

===CoefficientParams===
{| class="wikitable" border="1"
! Type
! Field
|-
| u16
| Y_A
|-
| u16
| R_V
|-
| u16
| G_V
|-
| u16
| G_U
|-
| u16
| B_U
|-
| u16
| R_Offset
|-
| u16
| G_Offset
|-
| u16
| B_Offset
|}

===StandardCoefficient===
{| class="wikitable" border="1"
|-
! Enum
! Value
|-
| COEFFICIENT_ITU_R_BT_601
| 0x0
|-
| COEFFICIENT_ITU_R_BT_709
| 0x1
|-
| COEFFICIENT_ITU_R_BT_601_SCALING
| 0x2
|-
| COEFFICIENT_ITU_R_BT_709_SCALING
| 0x3
|}

===DitheringWeightParams===
{| class="wikitable" border="1"
! Type
! Field
|-
| u16
| w0_xEven_yEven
|-
| u16
| w0_xOdd_yEven
|-
| u16
| w0_xEven_yOdd
|-
| u16
| w0_xOdd_yOdd
|-
| u16
| w1_xEven_yEven
|-
| u16
| w1_xOdd_yEven
|-
| u16
| w1_xEven_yOdd
|-
| u16
| w1_xOdd_yOdd
|-
| u16
| w2_xEven_yEven
|-
| u16
| w2_xOdd_yEven
|-
| u16
| w2_xEven_yOdd
|-
| u16
| w2_xOdd_yOdd
|-
| u16
| w3_xEven_yEven
|-
| u16
| w3_xOdd_yEven
|-
| u16
| w3_xEven_yOdd
|-
| u16
| w3_xOdd_yOdd
|}

===PackageParameter===
{| class="wikitable" border="1"
! Type
! Field
|-
| u8
| [[Camera_Services#InputFormat|InputFormat]] inputFormat
|-
| u8
| [[Camera_Services#OutputFormat_2|OutputFormat]] outputFormat
|-
| u8
| [[Camera_Services#Rotation|Rotation]] rotation
|-
| u8
| [[Camera_Services#BlockAlignment|BlockAlignment]] blockAlignment
|-
| s16
| inputLineWidth
|-
| s16
| inputLines
|-
| u8
| [[Camera_Services#StandardCoefficient|StandardCoefficient]] standardCoefficient
|-
| u8
| padding
|-
| s16
| alpha
|}

Camera Services

2020-08-06T07:25:19Z

Unknown: /* cam:q (PORT_QTM) */ x2

==cam:c (PORT_REG) ==
Same as [[#cam:u_.28PORT_USER.29|cam:u]]

==cam:s (PORT_CAL) ==
Same as [[#cam:u_.28PORT_USER.29|cam:u]]

==cam:q (PORT_QTM) ==
This was added with New3DS.

{| class="wikitable" border="1"
|-
! Command Header
! Description
|-
| 0x00010040
| [[CAMU:StartCapture|StartCapture]]
|-
| 0x00020040
| [[CAMU:StopCapture|StopCapture]]
|-
| 0x0003004?
| [[CAMU:IsBusy|IsBusy]]
|-
| 0x00040040
| [[CAMU:ClearBuffer|ClearBuffer]]
|-
| 0x0005004?
| [[CAMU:GetVsyncInterruptEvent|GetVsyncInterruptEvent]]
|-
| 0x0006004?
| [[CAMU:GetBufferErrorInterruptEvent|GetBufferErrorInterruptEvent]]
|-
| 0x0007????
| [[CAMU:StartRecieving|StartRecieving]]
|-
| 0x00080040
| [[CAMU:IsFinishedRecieving|IsFinishedRecieving]]
|-
| 0x00090100
| [[CAMU:SetTransferLines|SetTransferLines]]
|-
| 0x000A008?
| [[CAMU:GetMaxLines|GetMaxLines]]
|-
| 0x000B0100
| [[CAMU:SetTransferBytes|SetTransferBytes]]
|-
| 0x000C004?
| [[CAMU:GetTransferBytes|GetTransferBytes]]
|-
| 0x000D008?
| [[CAMU:GetMaxBytes|GetMaxBytes]]
|-
| 0x000E0080
| [[CAMU:SetTrimming|SetTrimming]]
|-
| 0x000F004?
| [[CAMU:IsTrimming|IsTrimming]]
|-
| 0x00100140
| [[CAMU:SetTrimmingParams|SetTrimmingParams]]
|-
| 0x0011????
| [[CAMU:GetTrimmingParams|GetTrimmingParams]]
|-
| 0x00120140
| [[CAMU:SetTrimmingParamsCenter|SetTrimmingParamsCenter]]
|-
| 0x00130040
| [[CAMU:Activate|Activate]]
|-
| 0x00140080
| [[CAMU:SwitchContext|SwitchContext]]
|-
| 0x00150080
| [[CAMU:SetExposure|SetExposure]]
|-
| 0x00160080
| [[CAMU:SetWhiteBalance|SetWhiteBalance]]
|-
| 0x00170080
| [[CAMU:SetSharpness|SetSharpness]]
|-
| 0x00180080
| [[CAMU:SetAutoExposure|SetAutoExposure]]
|-
| 0x0019004?
| [[CAMU:IsAutoExposure|IsAutoExposure]]
|-
| 0x001A0080
| [[CAMU:SetAutoWhiteBalance|SetAutoWhiteBalance]]
|-
| 0x001B004?
| [[CAMU:IsAutoWhiteBalance|IsAutoWhiteBalance]]
|-
| 0x001C00C0
| [[CAMU:FlipImage|FlipImage]]
|-
| 0x001D020?
| [[CAMU:SetDetailSize|SetDetailSize]]
|-
| 0x001E00C0
| [[CAMU:SetSize|SetSize]]
|-
| 0x001F0080
| [[CAMU:SetFrameRate|SetFrameRate]]
|-
| 0x00200080
| [[CAMU:SetPhotoMode|SetPhotoMode]]
|-
| 0x002100C0
| [[CAMU:SetEffect|SetEffect]]
|-
| 0x00220080
| [[CAMU:SetContrast|SetContrast]]
|-
| 0x00230080
| [[CAMU:SetLensCorrection|SetLensCorrection]]
|-
| 0x002400C0
| [[CAMU:SetOutputFormat|SetOutputFormat]]
|-
| 0x0025014?
| [[CAMU:SetAutoExposureWindow|SetAutoExposureWindow]]
|-
| 0x0026014?
| ???
|-
| 0x00270080
| ???
|-
| 0x00280080
| ???
|-
| 0x0029????
| ???
|-
| 0x002A????
| ???
|-
| 0x002B????
| ???
|-
| 0x002C0080
| ???
|-
| 0x002D????
| ???
|-
| 0x002E???
| ???
|-
| 0x002F
| ??????
|-
| 0x0030????
| ???
|-
| 0x0031000?
| ???
|-
| 0x0032000?
| ???
|-
| 0x0033000?
| ???
|-
| 0x0034000?
| ???
|-
| 0x00350040
| ???
|-
| 0x00360040
| ???
|-
| 0x0037004?
| ???
|-
| 0x0038000?
| ???
|-
| 0x0039004?
| ???
|-
| 0x003A0080
| ???
|-
| 0x003B004?
| ???
|-
| 0x003C0080
| ???
|-
| 0x003D000?
| ???
|-
| 0x003E0000
| ???
|}

==cam:u (PORT_USER)==
{| class="wikitable" border="1"
|-
! Command Header
! Description
|-
| 0x00010040
| [[CAMU:StartCapture|StartCapture]]
|-
| 0x00020040
| [[CAMU:StopCapture|StopCapture]]
|-
| 0x00030040
| [[CAMU:IsBusy|IsBusy]]
|-
| 0x00040040
| [[CAMU:ClearBuffer|ClearBuffer]]
|-
| 0x00050040
| [[CAMU:GetVsyncInterruptEvent|GetVsyncInterruptEvent]]
|-
| 0x00060040
| [[CAMU:GetBufferErrorInterruptEvent|GetBufferErrorInterruptEvent]]
|-
| 0x00070102
| [[CAMU:SetReceiving|SetReceiving]]
|-
| 0x00080040
| [[CAMU:IsFinishedReceiving|IsFinishedReceiving]]
|-
| 0x00090100
| [[CAMU:SetTransferLines|SetTransferLines]]
|-
| 0x000A0080
| [[CAMU:GetMaxLines|GetMaxLines]]
|-
| 0x000B0100
| [[CAMU:SetTransferBytes|SetTransferBytes]]
|-
| 0x000C0040
| [[CAMU:GetTransferBytes|GetTransferBytes]]
|-
| 0x000D0080
| [[CAMU:GetMaxBytes|GetMaxBytes]]
|-
| 0x000E0080
| [[CAMU:SetTrimming|SetTrimming]]
|-
| 0x000F0040
| [[CAMU:IsTrimming|IsTrimming]]
|-
| 0x00100140
| [[CAMU:SetTrimmingParams|SetTrimmingParams]]
|-
| 0x00110040
| [[CAMU:GetTrimmingParams|GetTrimmingParams]]
|-
| 0x00120140
| [[CAMU:SetTrimmingParamsCenter|SetTrimmingParamsCenter]]
|-
| 0x00130040
| [[CAMU:Activate|Activate]]
|-
| 0x00140080
| [[CAMU:SwitchContext|SwitchContext]]
|-
| 0x00150080
| [[CAMU:SetExposure|SetExposure]]
|-
| 0x00160080
| [[CAMU:SetWhiteBalance|SetWhiteBalance]]
|-
| 0x00170080
| [[CAMU:SetWhiteBalanceWithoutBaseUp|SetWhiteBalanceWithoutBaseUp]]
|-
| 0x00180080
| [[CAMU:SetSharpness|SetSharpness]]
|-
| 0x00190080
| [[CAMU:SetAutoExposure|SetAutoExposure]]
|-
| 0x001A0040
| [[CAMU:IsAutoExposure|IsAutoExposure]]
|-
| 0x001B0080
| [[CAMU:SetAutoWhiteBalance|SetAutoWhiteBalance]]
|-
| 0x001C0040
| [[CAMU:IsAutoWhiteBalance|IsAutoWhiteBalance]]
|-
| 0x001D00C0
| [[CAMU:FlipImage|FlipImage]]
|-
| 0x001E0200
| [[CAMU:SetDetailSize|SetDetailSize]]
|-
| 0x001F00C0
| [[CAMU:SetSize|SetSize]]
|-
| 0x00200080
| [[CAMU:SetFrameRate|SetFrameRate]]
|-
| 0x00210080
| [[CAMU:SetPhotoMode|SetPhotoMode]]
|-
| 0x002200C0
| [[CAMU:SetEffect|SetEffect]]
|-
| 0x00230080
| [[CAMU:SetContrast|SetContrast]]
|-
| 0x00240080
| [[CAMU:SetLensCorrection|SetLensCorrection]]
|-
| 0x002500C0
| [[CAMU:SetOutputFormat|SetOutputFormat]]
|-
| 0x00260140
| [[CAMU:SetAutoExposureWindow|SetAutoExposureWindow]]
|-
| 0x00270140
| [[CAMU:SetAutoWhiteBalanceWindow|SetAutoWhiteBalanceWindow]]
|-
| 0x00280080
| [[CAMU:SetNoiseFilter|SetNoiseFilter]]
|-
| 0x00290080
| [[CAMU:SynchronizeVsyncTiming|SynchronizeVsyncTiming]]
|-
| 0x002A0080
| [[CAMU:GetLatestVsyncTiming|GetLatestVsyncTiming]]
|-
| 0x002B0000
| [[CAMU:GetStereoCameraCalibrationData|GetStereoCameraCalibrationData]]
|-
| 0x002C0400
| [[CAMU:SetStereoCameraCalibrationData|SetStereoCameraCalibrationData]]
|-
| 0x002D00C0
| [[CAMU:WriteRegisterI2c|WriteRegisterI2c]]
|-
| 0x002E00C0
| [[CAMU:WriteMcuVariableI2c|WriteMcuVariableI2c]]
|-
| 0x002F0080
| [[CAMU:ReadRegisterI2cExclusive|ReadRegisterI2cExclusive]]
|-
| 0x00300080
| [[CAMU:ReadMcuVariableI2cExclusive|ReadMcuVariableI2cExclusive]]
|-
| 0x00310180
| [[CAMU:SetImageQualityCalibrationData|SetImageQualityCalibrationData]]
|-
| 0x00320000
| [[CAMU:GetImageQualityCalibrationData|GetImageQualityCalibrationData]]
|-
| 0x003302C0
| [[CAMU:SetPackageParameterWithoutContext|SetPackageParameterWithoutContext]]
|-
| 0x00340140
| [[CAMU:SetPackageParameterWithContext|SetPackageParameterWithContext]]
|-
| 0x003501C0
| [[CAMU:SetPackageParameterWithContextDetail|SetPackageParameterWithContextDetail]]
|-
| 0x00360000
| [[CAMU:GetSuitableY2rStandardCoefficient|GetSuitableY2rStandardCoefficient]]
|-
| 0x00370202
| [[CAMU:PlayShutterSoundWithWave|PlayShutterSoundWithWave]]
|-
| 0x00380040
| [[CAMU:PlayShutterSound|PlayShutterSound]]
|-
| 0x00390000
| [[CAMU:DriverInitialize|DriverInitialize]]
|-
| 0x003A0000
| [[CAMU:DriverFinalize|DriverFinalize]]
|-
| 0x003B0000
| [[CAMU:GetActivatedCamera|GetActivatedCamera]]
|-
| 0x003C0000
| [[CAMU:GetSleepCamera|GetSleepCamera]]
|-
| 0x003D0040
| [[CAMU:SetSleepCamera|SetSleepCamera]]
|-
| 0x003E0040
| [[CAMU:SetBrightnessSynchronization|SetBrightnessSynchronization]]
|-
| 0x003F0040
| Stubbed, always returns 0
|-
| 0x004000C0
| ???
|-
| 0x00410040
| Stubbed, returns D8A053EA if flag is not 1
|-
| 0x00420040
| ???
|-
| 0x00430000
| Stubbed, returns D8A053EA if flag is not 1
|-
| 0x00440000
| Stubbed, returns D8A053EA if flag is not 1
|}

===Port===
{| class="wikitable" border="1"
|-
! Enum
! Value
|-
| PORT_NONE
| 0x0
|-
| PORT_CAM1
| 0x1 << 0x0
|-
| PORT_CAM2
| 0x1 << 0x1
|-
| PORT_BOTH
| PORT_CAM1 <nowiki>|</nowiki> PORT_CAM2
|}

===CameraSelect===
{| class="wikitable" border="1"
|-
! Enum
! Value
|-
| SELECT_NONE
| 0x0
|-
| SELECT_OUT1
| 0x1 << 0x0
|-
| SELECT_IN1
| 0x1 << 0x1
|-
| SELECT_OUT2
| 0x1 << 0x2
|-
| SELECT_IN1_OUT1
| SELECT_OUT1 <nowiki>|</nowiki> SELECT_IN1
|-
| SELECT_OUT1_OUT2
| SELECT_OUT1 <nowiki>|</nowiki> SELECT_OUT2
|-
| SELECT_IN1_OUT2
| SELECT_IN1 <nowiki>|</nowiki> SELECT_OUT2
|-
| SELECT_ALL
| SELECT_OUT1 <nowiki>|</nowiki> SELECT_IN1 <nowiki>|</nowiki> SELECT_OUT2
|}

===Context===
{| class="wikitable" border="1"
|-
! Enum
! Value
|-
| CONTEXT_NONE
| 0x0
|-
| CONTEXT_A
| 0x1 << 0x0
|-
| CONTEXT_B
| 0x1 << 0x1
|-
| CONTEXT_BOTH
| CONTEXT_A <nowiki>|</nowiki> CONTEXT_B
|}

===Flip===
{| class="wikitable" border="1"
|-
! Enum
! Value
|-
| FLIP_NONE
| 0x0
|-
| FLIP_HORIZONTAL
| 0x1
|-
| FLIP_VERTICAL
| 0x2
|-
| FLIP_REVERSE
| 0x3
|}

===Size===
{| class="wikitable" border="1"
|-
! Enum
! Value
|-
| SIZE_VGA
| 0x0
|-
| SIZE_QVGA
| 0x1
|-
| SIZE_QQVGA
| 0x2
|-
| SIZE_CIF
| 0x3
|-
| SIZE_QCIF
| 0x4
|-
| SIZE_DS_LCD
| 0x5
|-
| SIZE_DS_LCDx4
| 0x6
|-
| SIZE_CTR_TOP_LCD
| 0x7
|-
| SIZE_CTR_BOTTOM_LCD
| SIZE_QVGA
|}

===FrameRate===
{| class="wikitable" border="1"
|-
! Enum
! Value
|-
| FRAME_RATE_15
| 0x0
|-
| FRAME_RATE_15_TO_5
| 0x1
|-
| FRAME_RATE_15_TO_2
| 0x2
|-
| FRAME_RATE_10
| 0x3
|-
| FRAME_RATE_8_5
| 0x4
|-
| FRAME_RATE_5
| 0x5
|-
| FRAME_RATE_20
| 0x6
|-
| FRAME_RATE_20_TO_5
| 0x7
|-
| FRAME_RATE_30
| 0x8
|-
| FRAME_RATE_30_TO_5
| 0x9
|-
| FRAME_RATE_15_TO_10
| 0xA
|-
| FRAME_RATE_20_TO_10
| 0xB
|-
| FRAME_RATE_30_TO_10
| 0xC
|}

===WhiteBalance===
{| class="wikitable" border="1"
|-
! Enum
! Value
|-
| WHITE_BALANCE_AUTO
| 0x0
|-
| WHITE_BALANCE_3200K
| 0x1
|-
| WHITE_BALANCE_4150K
| 0x2
|-
| WHITE_BALANCE_5200K
| 0x3
|-
| WHITE_BALANCE_6000K
| 0x4
|-
| WHITE_BALANCE_7000K
| 0x5
|-
| WHITE_BALANCE_MAX
| 0x6
|-
| WHITE_BALANCE_NORMAL
| WHITE_BALANCE_AUTO
|-
| WHITE_BALANCE_TUNGSTEN
| WHITE_BALANCE_3200K
|-
| WHITE_BALANCE_WHITE_FLUORESCENT_LIGHT
| WHITE_BALANCE_4150K
|-
| WHITE_BALANCE_DAYLIGHT
| WHITE_BALANCE_5200K
|-
| WHITE_BALANCE_CLOUDY
| WHITE_BALANCE_6000K
|-
| WHITE_BALANCE_HORIZON
| WHITE_BALANCE_6000K
|-
| WHITE_BALANCE_SHADE
| WHITE_BALANCE_7000K
|}

===PhotoMode===
{| class="wikitable" border="1"
|-
! Enum
! Value
|-
| PHOTO_MODE_NORMAL
| 0x0
|-
| PHOTO_MODE_PORTRAIT
| 0x1
|-
| PHOTO_MODE_LANDSCAPE
| 0x2
|-
| PHOTO_MODE_NIGHTVIEW
| 0x3
|-
| PHOTO_MODE_LETTER
| 0x4
|}

===Effect===
{| class="wikitable" border="1"
|-
! Enum
! Value
|-
| EFFECT_NONE
| 0x0
|-
| EFFECT_MONO
| 0x1
|-
| EFFECT_SEPIA
| 0x2
|-
| EFFECT_NEGATIVE
| 0x3
|-
| EFFECT_NEGAFILM
| 0x4
|-
| EFFECT_SEPIA01
| 0x5
|}

===Contrast===
{| class="wikitable" border="1"
|-
! Enum
! Value
|-
| CONTRAST_PATTERN_01
| 0x0
|-
| CONTRAST_PATTERN_02
| 0x1
|-
| CONTRAST_PATTERN_03
| 0x2
|-
| CONTRAST_PATTERN_04
| 0x3
|-
| CONTRAST_PATTERN_05
| 0x4
|-
| CONTRAST_PATTERN_06
| 0x5
|-
| CONTRAST_PATTERN_07
| 0x6
|-
| CONTRAST_PATTERN_08
| 0x7
|-
| CONTRAST_PATTERN_09
| 0x8
|-
| CONTRAST_PATTERN_10
| 0x9
|-
| CONTRAST_PATTERN_11
| 0xA
|-
| CONTRAST_LOW
| CONTRAST_PATTERN_05
|-
| CONTRAST_NORMAL
| CONTRAST_PATTERN_06
|-
| CONTRAST_HIGH
| CONTRAST_PATTERN_07
|}

===LensCorrection===
{| class="wikitable" border="1"
|-
! Enum
! Value
|-
| LENS_CORRECTION_OFF
| 0x0
|-
| LENS_CORRECTION_ON_70
| 0x1
|-
| LENS_CORRECTION_ON_90
| 0x2
|-
| LENS_CORRECTION_DARK
| LENS_CORRECTION_OFF
|-
| LENS_CORRECTION_NORMAL
| LENS_CORRECTION_ON_70
|-
| LENS_CORRECTION_BRIGHT
| LENS_CORRECTION_ON_90
|}

===OutputFormat===
{| class="wikitable" border="1"
|-
! Enum
! Value
|-
| OUTPUT_YUV_422
| 0x0
|-
| OUTPUT_RGB_565
| 0x1
|}

===ShutterSoundType===
{| class="wikitable" border="1"
|-
! Enum
! Value
|-
| SHUTTER_SOUND_TYPE_NORMAL
| 0x0
|-
| SHUTTER_SOUND_TYPE_MOVIE
| 0x1
|-
| SHUTTER_SOUND_TYPE_MOVIE_END
| 0x2
|}

===ImageQualityCalibrationData===
{| class="wikitable" border="1"
! Type
! Field
|-
| s16
| aeBaseTarget
|-
| s16
| kRL
|-
| s16
| kGL
|-
| s16
| kBL
|-
| s16
| ccmPosition
|-
| u16
| awbCcmL9Right
|-
| u16
| awbCcmL9Left
|-
| u16
| awbCcmL10Right
|-
| u16
| awbCcmL10Left
|-
| u16
| awbX0Right
|-
| u16
| awbX0Left
|}

===StereoCameraCalibrationData===
{| class="wikitable" border="1"
! Type
! Field
|-
| bool
| isValidRotationXY
|-
| bool[3]
| reservedFlag
|-
| float
| scale
|-
| float
| rotationZ
|-
| float
| translationX
|-
| float
| translationY
|-
| float
| rotationX
|-
| float
| rotationY
|-
| float
| angleOfViewRight
|-
| float
| angleOfViewLeft
|-
| float
| distanceToChart
|-
| float
| distanceCameras
|-
| s16
| imageWidth
|-
| s16
| imageHeight
|-
| u8[16]
| reserved
|}

===PackageParameterCameraSelect===
{| class="wikitable" border="1"
! Type
! Field
|-
| u8
| [[Camera_Services#CameraSelect|CameraSelect]] camera
|-
| s8
| exposure
|-
| u8
| [[Camera_Services#WhiteBalance|WhiteBalance]] whiteBalance
|-
| s8
| sharpness
|-
| bool
| autoExposureOn
|-
| bool
| autoWhiteBalanceOn
|-
| u8
| [[Camera_Services#FrameRate|FrameRate]] frameRate
|-
| u8
| [[Camera_Services#PhotoMode|PhotoMode]] photoMode
|-
| u8
| contrast
|-
| u8
| [[Camera_Services#LensCorrection|LensCorrection]] lensCorrection
|-
| bool
| noiseFilterOn
|-
| u8
| padding
|-
| s16
| autoExposureWindowX
|-
| s16
| autoExposureWindowY
|-
| s16
| autoExposureWindowWidth
|-
| s16
| autoExposureWindowHeight
|-
| s16
| autoWhiteBalanceWindowX
|-
| s16
| autoWhiteBalanceWindowY
|-
| s16
| autoWhiteBalanceWindowWidth
|-
| s16
| autoWhiteBalanceWindowHeight
|}

===PackageParameterContext===
{| class="wikitable" border="1"
! Type
! Field
|-
| u8
| [[Camera_Services#CameraSelect|CameraSelect]] camera
|-
| u8
| [[Camera_Services#Context|Context]] context
|-
| u8
| [[Camera_Services#Flip|Flip]] flip
|-
| u8
| [[Camera_Services#Effect|Effect]] effect
|-
| u8
| [[Camera_Services#Size|Size]] size
|}

===PackageParameterContextDetail===
{| class="wikitable" border="1"
! Type
! Field
|-
| u8
| [[Camera_Services#CameraSelect|CameraSelect]] camera
|-
| u8
| [[Camera_Services#Context|Context]] context
|-
| u8
| [[Camera_Services#Flip|Flip]] flip
|-
| u8
| [[Camera_Services#Effect|Effect]] effect
|-
| s16
| width
|-
| s16
| height
|-
| s16
| cropX0
|-
| s16
| cropY0
|-
| s16
| cropX1
|-
| s16
| cropY1
|}

== y2r:u ==
{| class="wikitable" border="1"
|-
! Command Header
! Description
|-
| 0x00010040
| [[Y2R:SetInputFormat|SetInputFormat]]
|-
| 0x00020000
| [[Y2R:GetInputFormat|GetInputFormat]]
|-
| 0x00030040
| [[Y2R:SetOutputFormat|SetOutputFormat]]
|-
| 0x00040000
| [[Y2R:GetOutputFormat|GetOutputFormat]]
|-
| 0x00050040
| [[Y2R:SetRotation|SetRotation]]
|-
| 0x00060000
| [[Y2R:GetRotation|GetRotation]]
|-
| 0x00070040
| [[Y2R:SetBlockAlignment|SetBlockAlignment]]
|-
| 0x00080000
| [[Y2R:GetBlockAlignment|GetBlockAlignment]]
|-
| 0x00090040
| [[Y2R:SetSpacialDithering|SetSpacialDithering]]
|-
| 0x000A0000
| [[Y2R:GetSpacialDithering|GetSpacialDithering]]
|-
| 0x000B0040
| [[Y2R:SetTemporalDithering|SetTemporalDithering]]
|-
| 0x000C0000
| [[Y2R:GetTemporalDithering|GetTemporalDithering]]
|-
| 0x000D0040
| [[Y2R:SetTransferEndInterrupt|SetTransferEndInterrupt]]
|-
| 0x000E0000
| [[Y2R:GetTransferEndInterrupt|GetTransferEndInterrupt]]
|-
| 0x000F0000
| [[Y2R:GetTransferEndEvent|GetTransferEndEvent]]
|-
| 0x00100102
| [[Y2R:SetSendingY|SetSendingY]]
|-
| 0x00110102
| [[Y2R:SetSendingU|SetSendingU]]
|-
| 0x00120102
| [[Y2R:SetSendingV|SetSendingV]]
|-
| 0x00130102
| [[Y2R:SetSendingYuv|SetSendingYuv]]
|-
| 0x00140000
| [[Y2R:IsFinishedSendingYuv|IsFinishedSendingYuv]]
|-
| 0x00150000
| [[Y2R:IsFinishedSendingY|IsFinishedSendingY]]
|-
| 0x00160000
| [[Y2R:IsFinishedSendingU|IsFinishedSendingU]]
|-
| 0x00170000
| [[Y2R:IsFinishedSendingV|IsFinishedSendingV]]
|-
| 0x00180102
| [[Y2R:SetReceiving|SetReceiving]]
|-
| 0x00190000
| [[Y2R:IsFinishedReceiving|IsFinishedReceiving]]
|-
| 0x001A0040
| [[Y2R:SetInputLineWidth|SetInputLineWidth]]
|-
| 0x001B0000
| [[Y2R:GetInputLineWidth|GetInputLineWidth]]
|-
| 0x001C0040
| [[Y2R:SetInputLines|SetInputLines]]
|-
| 0x001D0000
| [[Y2R:GetInputLines|GetInputLines]]
|-
| 0x001E0100
| [[Y2R:SetCoefficientParams|SetCoefficientParams]]
|-
| 0x001F0000
| [[Y2R:GetCoefficientParams|GetCoefficientParams]]
|-
| 0x00200040
| [[Y2R:SetStandardCoefficient|SetStandardCoefficient]]
|-
| 0x00210040
| [[Y2R:GetStandardCoefficientParams|GetStandardCoefficientParams]]
|-
| 0x00220040
| [[Y2R:SetAlpha|SetAlpha]]
|-
| 0x00230000
| [[Y2R:GetAlpha|GetAlpha]]
|-
| 0x00240200
| [[Y2R:SetDitheringWeightParams|SetDitheringWeightParams]]
|-
| 0x00250000
| [[Y2R:GetDitheringWeightParams|GetDitheringWeightParams]]
|-
| 0x00260000
| [[Y2R:StartConversion|StartConversion]]
|-
| 0x00270000
| [[Y2R:StopConversion|StopConversion]]
|-
| 0x00280000
| [[Y2R:IsBusyConversion|IsBusyConversion]]
|-
| 0x002901C0
| [[Y2R:SetPackageParameter|SetPackageParameter]]
|-
| 0x002A0000
| [[Y2R:PingProcess|PingProcess]]
|-
| 0x002B0000
| [[Y2R:DriverInitialize|DriverInitialize]]
|-
| 0x002C0000
| [[Y2R:DriverFinalize|DriverFinalize]]
|-
| 0x002D0000
| [[Y2R:GetPackageParameter|GetPackageParameter]]
|}

===InputFormat===
{| class="wikitable" border="1"
|-
! Enum
! Value
|-
| INPUT_YUV422_INDIV_8
| 0x0
|-
| INPUT_YUV420_INDIV_8
| 0x1
|-
| INPUT_YUV422_INDIV_16
| 0x2
|-
| INPUT_YUV420_INDIV_16
| 0x3
|-
| INPUT_YUV422_BATCH
| 0x4
|}

===OutputFormat===
{| class="wikitable" border="1"
|-
! Enum
! Value
|-
| OUTPUT_RGB_32
| 0x0
|-
| OUTPUT_RGB_24
| 0x1
|-
| OUTPUT_RGB_16_555
| 0x2
|-
| OUTPUT_RGB_16_565
| 0x3
|}

===Rotation===
{| class="wikitable" border="1"
|-
! Enum
! Value
|-
| ROTATION_NONE
| 0x0
|-
| ROTATION_CLOCKWISE_90
| 0x1
|-
| ROTATION_CLOCKWISE_180
| 0x2
|-
| ROTATION_CLOCKWISE_270
| 0x3
|}

===BlockAlignment===
{| class="wikitable" border="1"
|-
! Enum
! Value
! Description
|-
| BLOCK_LINE
| 0x0
| Output buffer's pixels are arranged linearly. Used when outputting to the framebuffer.
|-
| BLOCK_8_BY_8
| 0x1
| Output buffer's pixels are morton swizzled. Used when outputting to a GPU texture.
|}

===CoefficientParams===
{| class="wikitable" border="1"
! Type
! Field
|-
| u16
| Y_A
|-
| u16
| R_V
|-
| u16
| G_V
|-
| u16
| G_U
|-
| u16
| B_U
|-
| u16
| R_Offset
|-
| u16
| G_Offset
|-
| u16
| B_Offset
|}

===StandardCoefficient===
{| class="wikitable" border="1"
|-
! Enum
! Value
|-
| COEFFICIENT_ITU_R_BT_601
| 0x0
|-
| COEFFICIENT_ITU_R_BT_709
| 0x1
|-
| COEFFICIENT_ITU_R_BT_601_SCALING
| 0x2
|-
| COEFFICIENT_ITU_R_BT_709_SCALING
| 0x3
|}

===DitheringWeightParams===
{| class="wikitable" border="1"
! Type
! Field
|-
| u16
| w0_xEven_yEven
|-
| u16
| w0_xOdd_yEven
|-
| u16
| w0_xEven_yOdd
|-
| u16
| w0_xOdd_yOdd
|-
| u16
| w1_xEven_yEven
|-
| u16
| w1_xOdd_yEven
|-
| u16
| w1_xEven_yOdd
|-
| u16
| w1_xOdd_yOdd
|-
| u16
| w2_xEven_yEven
|-
| u16
| w2_xOdd_yEven
|-
| u16
| w2_xEven_yOdd
|-
| u16
| w2_xOdd_yOdd
|-
| u16
| w3_xEven_yEven
|-
| u16
| w3_xOdd_yEven
|-
| u16
| w3_xEven_yOdd
|-
| u16
| w3_xOdd_yOdd
|}

===PackageParameter===
{| class="wikitable" border="1"
! Type
! Field
|-
| u8
| [[Camera_Services#InputFormat|InputFormat]] inputFormat
|-
| u8
| [[Camera_Services#OutputFormat_2|OutputFormat]] outputFormat
|-
| u8
| [[Camera_Services#Rotation|Rotation]] rotation
|-
| u8
| [[Camera_Services#BlockAlignment|BlockAlignment]] blockAlignment
|-
| s16
| inputLineWidth
|-
| s16
| inputLines
|-
| u8
| [[Camera_Services#StandardCoefficient|StandardCoefficient]] standardCoefficient
|-
| u8
| padding
|-
| s16
| alpha
|}

Camera Services

2020-08-06T07:13:20Z

Unknown: /* cam:q (PORT_QTM) */ ida decompilation shows that these commands are common with cam:u

==cam:c (PORT_REG) ==
Same as [[#cam:u_.28PORT_USER.29|cam:u]]

==cam:s (PORT_CAL) ==
Same as [[#cam:u_.28PORT_USER.29|cam:u]]

==cam:q (PORT_QTM) ==
This was added with New3DS.

{| class="wikitable" border="1"
|-
! Command Header
! Description
|-
| 0x00010040
| [[CAMU:StartCapture|StartCapture]]
|-
| 0x00020040
| [[CAMU:StopCapture|StopCapture]]
|-
| 0x0003004?
| [[CAMU:IsBusy|IsBusy]]
|-
| 0x00040040
| [[CAMU:ClearBuffer|ClearBuffer]]
|-
| 0x0005004?
| [[CAMU:GetVsyncInterruptEvent|GetVsyncInterruptEvent]]
|-
| 0x0006004?
| [[CAMU:GetBufferErrorInterruptEvent|GetBufferErrorInterruptEvent]]
|-
| 0x0007????
| [[CAMU:StartRecieving|StartRecieving]]
|-
| 0x00080040
| [[CAMU:IsFinishedRecieving|IsFinishedRecieving]]
|-
| 0x00090100
| [[CAMU:SetTransferLines|SetTransferLines]]
|-
| 0x000A008?
| [[CAMU:GetMaxLines|GetMaxLines]]
|-
| 0x000B0100
| [[CAMU:SetTransferBytes|SetTransferBytes]]
|-
| 0x000C004?
| [[CAMU:GetTransferBytes|GetTransferBytes]]
|-
| 0x000D008?
| [[CAMU:GetMaxBytes|GetMaxBytes]]
|-
| 0x000E0080
| [[CAMU:SetTrimming|SetTrimming]]
|-
| 0x000F004?
| [[CAMU:IsTrimming|IsTrimming]]
|-
| 0x00100140
| [[CAMU:SetTrimmingParams|SetTrimmingParams]]
|-
| 0x0011????
| [[CAMU:GetTrimmingParams|GetTrimmingParams]]
|-
| 0x00120140
| [[CAMU:SetTrimmingParamsCenter|SetTrimmingParamsCenter]]
|-
| 0x00130040
| [[CAMU:Activate|Activate]]
|-
| 0x00140080
| ???
|-
| 0x00150080
| ???
|-
| 0x00160080
| ???
|-
| 0x00170080
| ???
|-
| 0x00180080
| ???
|-
| 0x0019004?
| ???
|-
| 0x001A0080
| ???
|-
| 0x001B004?
| ???
|-
| 0x001C00C0
| ???
|-
| 0x001D020?
| ???
|-
| 0x001E00C0
| ???
|-
| 0x001F0080
| ???
|-
| 0x00200080
| ???
|-
| 0x002100C0
| ???
|-
| 0x00220080
| ???
|-
| 0x00230080
| ???
|-
| 0x002400C0
| ???
|-
| 0x0025014?
| ???
|-
| 0x0026014?
| ???
|-
| 0x00270080
| ???
|-
| 0x00280080
| ???
|-
| 0x0029????
| ???
|-
| 0x002A????
| ???
|-
| 0x002B????
| ???
|-
| 0x002C0080
| ???
|-
| 0x002D????
| ???
|-
| 0x002E???
| ???
|-
| 0x002F
| ??????
|-
| 0x0030????
| ???
|-
| 0x0031000?
| ???
|-
| 0x0032000?
| ???
|-
| 0x0033000?
| ???
|-
| 0x0034000?
| ???
|-
| 0x00350040
| ???
|-
| 0x00360040
| ???
|-
| 0x0037004?
| ???
|-
| 0x0038000?
| ???
|-
| 0x0039004?
| ???
|-
| 0x003A0080
| ???
|-
| 0x003B004?
| ???
|-
| 0x003C0080
| ???
|-
| 0x003D000?
| ???
|-
| 0x003E0000
| ???
|}

==cam:u (PORT_USER)==
{| class="wikitable" border="1"
|-
! Command Header
! Description
|-
| 0x00010040
| [[CAMU:StartCapture|StartCapture]]
|-
| 0x00020040
| [[CAMU:StopCapture|StopCapture]]
|-
| 0x00030040
| [[CAMU:IsBusy|IsBusy]]
|-
| 0x00040040
| [[CAMU:ClearBuffer|ClearBuffer]]
|-
| 0x00050040
| [[CAMU:GetVsyncInterruptEvent|GetVsyncInterruptEvent]]
|-
| 0x00060040
| [[CAMU:GetBufferErrorInterruptEvent|GetBufferErrorInterruptEvent]]
|-
| 0x00070102
| [[CAMU:SetReceiving|SetReceiving]]
|-
| 0x00080040
| [[CAMU:IsFinishedReceiving|IsFinishedReceiving]]
|-
| 0x00090100
| [[CAMU:SetTransferLines|SetTransferLines]]
|-
| 0x000A0080
| [[CAMU:GetMaxLines|GetMaxLines]]
|-
| 0x000B0100
| [[CAMU:SetTransferBytes|SetTransferBytes]]
|-
| 0x000C0040
| [[CAMU:GetTransferBytes|GetTransferBytes]]
|-
| 0x000D0080
| [[CAMU:GetMaxBytes|GetMaxBytes]]
|-
| 0x000E0080
| [[CAMU:SetTrimming|SetTrimming]]
|-
| 0x000F0040
| [[CAMU:IsTrimming|IsTrimming]]
|-
| 0x00100140
| [[CAMU:SetTrimmingParams|SetTrimmingParams]]
|-
| 0x00110040
| [[CAMU:GetTrimmingParams|GetTrimmingParams]]
|-
| 0x00120140
| [[CAMU:SetTrimmingParamsCenter|SetTrimmingParamsCenter]]
|-
| 0x00130040
| [[CAMU:Activate|Activate]]
|-
| 0x00140080
| [[CAMU:SwitchContext|SwitchContext]]
|-
| 0x00150080
| [[CAMU:SetExposure|SetExposure]]
|-
| 0x00160080
| [[CAMU:SetWhiteBalance|SetWhiteBalance]]
|-
| 0x00170080
| [[CAMU:SetWhiteBalanceWithoutBaseUp|SetWhiteBalanceWithoutBaseUp]]
|-
| 0x00180080
| [[CAMU:SetSharpness|SetSharpness]]
|-
| 0x00190080
| [[CAMU:SetAutoExposure|SetAutoExposure]]
|-
| 0x001A0040
| [[CAMU:IsAutoExposure|IsAutoExposure]]
|-
| 0x001B0080
| [[CAMU:SetAutoWhiteBalance|SetAutoWhiteBalance]]
|-
| 0x001C0040
| [[CAMU:IsAutoWhiteBalance|IsAutoWhiteBalance]]
|-
| 0x001D00C0
| [[CAMU:FlipImage|FlipImage]]
|-
| 0x001E0200
| [[CAMU:SetDetailSize|SetDetailSize]]
|-
| 0x001F00C0
| [[CAMU:SetSize|SetSize]]
|-
| 0x00200080
| [[CAMU:SetFrameRate|SetFrameRate]]
|-
| 0x00210080
| [[CAMU:SetPhotoMode|SetPhotoMode]]
|-
| 0x002200C0
| [[CAMU:SetEffect|SetEffect]]
|-
| 0x00230080
| [[CAMU:SetContrast|SetContrast]]
|-
| 0x00240080
| [[CAMU:SetLensCorrection|SetLensCorrection]]
|-
| 0x002500C0
| [[CAMU:SetOutputFormat|SetOutputFormat]]
|-
| 0x00260140
| [[CAMU:SetAutoExposureWindow|SetAutoExposureWindow]]
|-
| 0x00270140
| [[CAMU:SetAutoWhiteBalanceWindow|SetAutoWhiteBalanceWindow]]
|-
| 0x00280080
| [[CAMU:SetNoiseFilter|SetNoiseFilter]]
|-
| 0x00290080
| [[CAMU:SynchronizeVsyncTiming|SynchronizeVsyncTiming]]
|-
| 0x002A0080
| [[CAMU:GetLatestVsyncTiming|GetLatestVsyncTiming]]
|-
| 0x002B0000
| [[CAMU:GetStereoCameraCalibrationData|GetStereoCameraCalibrationData]]
|-
| 0x002C0400
| [[CAMU:SetStereoCameraCalibrationData|SetStereoCameraCalibrationData]]
|-
| 0x002D00C0
| [[CAMU:WriteRegisterI2c|WriteRegisterI2c]]
|-
| 0x002E00C0
| [[CAMU:WriteMcuVariableI2c|WriteMcuVariableI2c]]
|-
| 0x002F0080
| [[CAMU:ReadRegisterI2cExclusive|ReadRegisterI2cExclusive]]
|-
| 0x00300080
| [[CAMU:ReadMcuVariableI2cExclusive|ReadMcuVariableI2cExclusive]]
|-
| 0x00310180
| [[CAMU:SetImageQualityCalibrationData|SetImageQualityCalibrationData]]
|-
| 0x00320000
| [[CAMU:GetImageQualityCalibrationData|GetImageQualityCalibrationData]]
|-
| 0x003302C0
| [[CAMU:SetPackageParameterWithoutContext|SetPackageParameterWithoutContext]]
|-
| 0x00340140
| [[CAMU:SetPackageParameterWithContext|SetPackageParameterWithContext]]
|-
| 0x003501C0
| [[CAMU:SetPackageParameterWithContextDetail|SetPackageParameterWithContextDetail]]
|-
| 0x00360000
| [[CAMU:GetSuitableY2rStandardCoefficient|GetSuitableY2rStandardCoefficient]]
|-
| 0x00370202
| [[CAMU:PlayShutterSoundWithWave|PlayShutterSoundWithWave]]
|-
| 0x00380040
| [[CAMU:PlayShutterSound|PlayShutterSound]]
|-
| 0x00390000
| [[CAMU:DriverInitialize|DriverInitialize]]
|-
| 0x003A0000
| [[CAMU:DriverFinalize|DriverFinalize]]
|-
| 0x003B0000
| [[CAMU:GetActivatedCamera|GetActivatedCamera]]
|-
| 0x003C0000
| [[CAMU:GetSleepCamera|GetSleepCamera]]
|-
| 0x003D0040
| [[CAMU:SetSleepCamera|SetSleepCamera]]
|-
| 0x003E0040
| [[CAMU:SetBrightnessSynchronization|SetBrightnessSynchronization]]
|-
| 0x003F0040
| Stubbed, always returns 0
|-
| 0x004000C0
| ???
|-
| 0x00410040
| Stubbed, returns D8A053EA if flag is not 1
|-
| 0x00420040
| ???
|-
| 0x00430000
| Stubbed, returns D8A053EA if flag is not 1
|-
| 0x00440000
| Stubbed, returns D8A053EA if flag is not 1
|}

===Port===
{| class="wikitable" border="1"
|-
! Enum
! Value
|-
| PORT_NONE
| 0x0
|-
| PORT_CAM1
| 0x1 << 0x0
|-
| PORT_CAM2
| 0x1 << 0x1
|-
| PORT_BOTH
| PORT_CAM1 <nowiki>|</nowiki> PORT_CAM2
|}

===CameraSelect===
{| class="wikitable" border="1"
|-
! Enum
! Value
|-
| SELECT_NONE
| 0x0
|-
| SELECT_OUT1
| 0x1 << 0x0
|-
| SELECT_IN1
| 0x1 << 0x1
|-
| SELECT_OUT2
| 0x1 << 0x2
|-
| SELECT_IN1_OUT1
| SELECT_OUT1 <nowiki>|</nowiki> SELECT_IN1
|-
| SELECT_OUT1_OUT2
| SELECT_OUT1 <nowiki>|</nowiki> SELECT_OUT2
|-
| SELECT_IN1_OUT2
| SELECT_IN1 <nowiki>|</nowiki> SELECT_OUT2
|-
| SELECT_ALL
| SELECT_OUT1 <nowiki>|</nowiki> SELECT_IN1 <nowiki>|</nowiki> SELECT_OUT2
|}

===Context===
{| class="wikitable" border="1"
|-
! Enum
! Value
|-
| CONTEXT_NONE
| 0x0
|-
| CONTEXT_A
| 0x1 << 0x0
|-
| CONTEXT_B
| 0x1 << 0x1
|-
| CONTEXT_BOTH
| CONTEXT_A <nowiki>|</nowiki> CONTEXT_B
|}

===Flip===
{| class="wikitable" border="1"
|-
! Enum
! Value
|-
| FLIP_NONE
| 0x0
|-
| FLIP_HORIZONTAL
| 0x1
|-
| FLIP_VERTICAL
| 0x2
|-
| FLIP_REVERSE
| 0x3
|}

===Size===
{| class="wikitable" border="1"
|-
! Enum
! Value
|-
| SIZE_VGA
| 0x0
|-
| SIZE_QVGA
| 0x1
|-
| SIZE_QQVGA
| 0x2
|-
| SIZE_CIF
| 0x3
|-
| SIZE_QCIF
| 0x4
|-
| SIZE_DS_LCD
| 0x5
|-
| SIZE_DS_LCDx4
| 0x6
|-
| SIZE_CTR_TOP_LCD
| 0x7
|-
| SIZE_CTR_BOTTOM_LCD
| SIZE_QVGA
|}

===FrameRate===
{| class="wikitable" border="1"
|-
! Enum
! Value
|-
| FRAME_RATE_15
| 0x0
|-
| FRAME_RATE_15_TO_5
| 0x1
|-
| FRAME_RATE_15_TO_2
| 0x2
|-
| FRAME_RATE_10
| 0x3
|-
| FRAME_RATE_8_5
| 0x4
|-
| FRAME_RATE_5
| 0x5
|-
| FRAME_RATE_20
| 0x6
|-
| FRAME_RATE_20_TO_5
| 0x7
|-
| FRAME_RATE_30
| 0x8
|-
| FRAME_RATE_30_TO_5
| 0x9
|-
| FRAME_RATE_15_TO_10
| 0xA
|-
| FRAME_RATE_20_TO_10
| 0xB
|-
| FRAME_RATE_30_TO_10
| 0xC
|}

===WhiteBalance===
{| class="wikitable" border="1"
|-
! Enum
! Value
|-
| WHITE_BALANCE_AUTO
| 0x0
|-
| WHITE_BALANCE_3200K
| 0x1
|-
| WHITE_BALANCE_4150K
| 0x2
|-
| WHITE_BALANCE_5200K
| 0x3
|-
| WHITE_BALANCE_6000K
| 0x4
|-
| WHITE_BALANCE_7000K
| 0x5
|-
| WHITE_BALANCE_MAX
| 0x6
|-
| WHITE_BALANCE_NORMAL
| WHITE_BALANCE_AUTO
|-
| WHITE_BALANCE_TUNGSTEN
| WHITE_BALANCE_3200K
|-
| WHITE_BALANCE_WHITE_FLUORESCENT_LIGHT
| WHITE_BALANCE_4150K
|-
| WHITE_BALANCE_DAYLIGHT
| WHITE_BALANCE_5200K
|-
| WHITE_BALANCE_CLOUDY
| WHITE_BALANCE_6000K
|-
| WHITE_BALANCE_HORIZON
| WHITE_BALANCE_6000K
|-
| WHITE_BALANCE_SHADE
| WHITE_BALANCE_7000K
|}

===PhotoMode===
{| class="wikitable" border="1"
|-
! Enum
! Value
|-
| PHOTO_MODE_NORMAL
| 0x0
|-
| PHOTO_MODE_PORTRAIT
| 0x1
|-
| PHOTO_MODE_LANDSCAPE
| 0x2
|-
| PHOTO_MODE_NIGHTVIEW
| 0x3
|-
| PHOTO_MODE_LETTER
| 0x4
|}

===Effect===
{| class="wikitable" border="1"
|-
! Enum
! Value
|-
| EFFECT_NONE
| 0x0
|-
| EFFECT_MONO
| 0x1
|-
| EFFECT_SEPIA
| 0x2
|-
| EFFECT_NEGATIVE
| 0x3
|-
| EFFECT_NEGAFILM
| 0x4
|-
| EFFECT_SEPIA01
| 0x5
|}

===Contrast===
{| class="wikitable" border="1"
|-
! Enum
! Value
|-
| CONTRAST_PATTERN_01
| 0x0
|-
| CONTRAST_PATTERN_02
| 0x1
|-
| CONTRAST_PATTERN_03
| 0x2
|-
| CONTRAST_PATTERN_04
| 0x3
|-
| CONTRAST_PATTERN_05
| 0x4
|-
| CONTRAST_PATTERN_06
| 0x5
|-
| CONTRAST_PATTERN_07
| 0x6
|-
| CONTRAST_PATTERN_08
| 0x7
|-
| CONTRAST_PATTERN_09
| 0x8
|-
| CONTRAST_PATTERN_10
| 0x9
|-
| CONTRAST_PATTERN_11
| 0xA
|-
| CONTRAST_LOW
| CONTRAST_PATTERN_05
|-
| CONTRAST_NORMAL
| CONTRAST_PATTERN_06
|-
| CONTRAST_HIGH
| CONTRAST_PATTERN_07
|}

===LensCorrection===
{| class="wikitable" border="1"
|-
! Enum
! Value
|-
| LENS_CORRECTION_OFF
| 0x0
|-
| LENS_CORRECTION_ON_70
| 0x1
|-
| LENS_CORRECTION_ON_90
| 0x2
|-
| LENS_CORRECTION_DARK
| LENS_CORRECTION_OFF
|-
| LENS_CORRECTION_NORMAL
| LENS_CORRECTION_ON_70
|-
| LENS_CORRECTION_BRIGHT
| LENS_CORRECTION_ON_90
|}

===OutputFormat===
{| class="wikitable" border="1"
|-
! Enum
! Value
|-
| OUTPUT_YUV_422
| 0x0
|-
| OUTPUT_RGB_565
| 0x1
|}

===ShutterSoundType===
{| class="wikitable" border="1"
|-
! Enum
! Value
|-
| SHUTTER_SOUND_TYPE_NORMAL
| 0x0
|-
| SHUTTER_SOUND_TYPE_MOVIE
| 0x1
|-
| SHUTTER_SOUND_TYPE_MOVIE_END
| 0x2
|}

===ImageQualityCalibrationData===
{| class="wikitable" border="1"
! Type
! Field
|-
| s16
| aeBaseTarget
|-
| s16
| kRL
|-
| s16
| kGL
|-
| s16
| kBL
|-
| s16
| ccmPosition
|-
| u16
| awbCcmL9Right
|-
| u16
| awbCcmL9Left
|-
| u16
| awbCcmL10Right
|-
| u16
| awbCcmL10Left
|-
| u16
| awbX0Right
|-
| u16
| awbX0Left
|}

===StereoCameraCalibrationData===
{| class="wikitable" border="1"
! Type
! Field
|-
| bool
| isValidRotationXY
|-
| bool[3]
| reservedFlag
|-
| float
| scale
|-
| float
| rotationZ
|-
| float
| translationX
|-
| float
| translationY
|-
| float
| rotationX
|-
| float
| rotationY
|-
| float
| angleOfViewRight
|-
| float
| angleOfViewLeft
|-
| float
| distanceToChart
|-
| float
| distanceCameras
|-
| s16
| imageWidth
|-
| s16
| imageHeight
|-
| u8[16]
| reserved
|}

===PackageParameterCameraSelect===
{| class="wikitable" border="1"
! Type
! Field
|-
| u8
| [[Camera_Services#CameraSelect|CameraSelect]] camera
|-
| s8
| exposure
|-
| u8
| [[Camera_Services#WhiteBalance|WhiteBalance]] whiteBalance
|-
| s8
| sharpness
|-
| bool
| autoExposureOn
|-
| bool
| autoWhiteBalanceOn
|-
| u8
| [[Camera_Services#FrameRate|FrameRate]] frameRate
|-
| u8
| [[Camera_Services#PhotoMode|PhotoMode]] photoMode
|-
| u8
| contrast
|-
| u8
| [[Camera_Services#LensCorrection|LensCorrection]] lensCorrection
|-
| bool
| noiseFilterOn
|-
| u8
| padding
|-
| s16
| autoExposureWindowX
|-
| s16
| autoExposureWindowY
|-
| s16
| autoExposureWindowWidth
|-
| s16
| autoExposureWindowHeight
|-
| s16
| autoWhiteBalanceWindowX
|-
| s16
| autoWhiteBalanceWindowY
|-
| s16
| autoWhiteBalanceWindowWidth
|-
| s16
| autoWhiteBalanceWindowHeight
|}

===PackageParameterContext===
{| class="wikitable" border="1"
! Type
! Field
|-
| u8
| [[Camera_Services#CameraSelect|CameraSelect]] camera
|-
| u8
| [[Camera_Services#Context|Context]] context
|-
| u8
| [[Camera_Services#Flip|Flip]] flip
|-
| u8
| [[Camera_Services#Effect|Effect]] effect
|-
| u8
| [[Camera_Services#Size|Size]] size
|}

===PackageParameterContextDetail===
{| class="wikitable" border="1"
! Type
! Field
|-
| u8
| [[Camera_Services#CameraSelect|CameraSelect]] camera
|-
| u8
| [[Camera_Services#Context|Context]] context
|-
| u8
| [[Camera_Services#Flip|Flip]] flip
|-
| u8
| [[Camera_Services#Effect|Effect]] effect
|-
| s16
| width
|-
| s16
| height
|-
| s16
| cropX0
|-
| s16
| cropY0
|-
| s16
| cropX1
|-
| s16
| cropY1
|}

== y2r:u ==
{| class="wikitable" border="1"
|-
! Command Header
! Description
|-
| 0x00010040
| [[Y2R:SetInputFormat|SetInputFormat]]
|-
| 0x00020000
| [[Y2R:GetInputFormat|GetInputFormat]]
|-
| 0x00030040
| [[Y2R:SetOutputFormat|SetOutputFormat]]
|-
| 0x00040000
| [[Y2R:GetOutputFormat|GetOutputFormat]]
|-
| 0x00050040
| [[Y2R:SetRotation|SetRotation]]
|-
| 0x00060000
| [[Y2R:GetRotation|GetRotation]]
|-
| 0x00070040
| [[Y2R:SetBlockAlignment|SetBlockAlignment]]
|-
| 0x00080000
| [[Y2R:GetBlockAlignment|GetBlockAlignment]]
|-
| 0x00090040
| [[Y2R:SetSpacialDithering|SetSpacialDithering]]
|-
| 0x000A0000
| [[Y2R:GetSpacialDithering|GetSpacialDithering]]
|-
| 0x000B0040
| [[Y2R:SetTemporalDithering|SetTemporalDithering]]
|-
| 0x000C0000
| [[Y2R:GetTemporalDithering|GetTemporalDithering]]
|-
| 0x000D0040
| [[Y2R:SetTransferEndInterrupt|SetTransferEndInterrupt]]
|-
| 0x000E0000
| [[Y2R:GetTransferEndInterrupt|GetTransferEndInterrupt]]
|-
| 0x000F0000
| [[Y2R:GetTransferEndEvent|GetTransferEndEvent]]
|-
| 0x00100102
| [[Y2R:SetSendingY|SetSendingY]]
|-
| 0x00110102
| [[Y2R:SetSendingU|SetSendingU]]
|-
| 0x00120102
| [[Y2R:SetSendingV|SetSendingV]]
|-
| 0x00130102
| [[Y2R:SetSendingYuv|SetSendingYuv]]
|-
| 0x00140000
| [[Y2R:IsFinishedSendingYuv|IsFinishedSendingYuv]]
|-
| 0x00150000
| [[Y2R:IsFinishedSendingY|IsFinishedSendingY]]
|-
| 0x00160000
| [[Y2R:IsFinishedSendingU|IsFinishedSendingU]]
|-
| 0x00170000
| [[Y2R:IsFinishedSendingV|IsFinishedSendingV]]
|-
| 0x00180102
| [[Y2R:SetReceiving|SetReceiving]]
|-
| 0x00190000
| [[Y2R:IsFinishedReceiving|IsFinishedReceiving]]
|-
| 0x001A0040
| [[Y2R:SetInputLineWidth|SetInputLineWidth]]
|-
| 0x001B0000
| [[Y2R:GetInputLineWidth|GetInputLineWidth]]
|-
| 0x001C0040
| [[Y2R:SetInputLines|SetInputLines]]
|-
| 0x001D0000
| [[Y2R:GetInputLines|GetInputLines]]
|-
| 0x001E0100
| [[Y2R:SetCoefficientParams|SetCoefficientParams]]
|-
| 0x001F0000
| [[Y2R:GetCoefficientParams|GetCoefficientParams]]
|-
| 0x00200040
| [[Y2R:SetStandardCoefficient|SetStandardCoefficient]]
|-
| 0x00210040
| [[Y2R:GetStandardCoefficientParams|GetStandardCoefficientParams]]
|-
| 0x00220040
| [[Y2R:SetAlpha|SetAlpha]]
|-
| 0x00230000
| [[Y2R:GetAlpha|GetAlpha]]
|-
| 0x00240200
| [[Y2R:SetDitheringWeightParams|SetDitheringWeightParams]]
|-
| 0x00250000
| [[Y2R:GetDitheringWeightParams|GetDitheringWeightParams]]
|-
| 0x00260000
| [[Y2R:StartConversion|StartConversion]]
|-
| 0x00270000
| [[Y2R:StopConversion|StopConversion]]
|-
| 0x00280000
| [[Y2R:IsBusyConversion|IsBusyConversion]]
|-
| 0x002901C0
| [[Y2R:SetPackageParameter|SetPackageParameter]]
|-
| 0x002A0000
| [[Y2R:PingProcess|PingProcess]]
|-
| 0x002B0000
| [[Y2R:DriverInitialize|DriverInitialize]]
|-
| 0x002C0000
| [[Y2R:DriverFinalize|DriverFinalize]]
|-
| 0x002D0000
| [[Y2R:GetPackageParameter|GetPackageParameter]]
|}

===InputFormat===
{| class="wikitable" border="1"
|-
! Enum
! Value
|-
| INPUT_YUV422_INDIV_8
| 0x0
|-
| INPUT_YUV420_INDIV_8
| 0x1
|-
| INPUT_YUV422_INDIV_16
| 0x2
|-
| INPUT_YUV420_INDIV_16
| 0x3
|-
| INPUT_YUV422_BATCH
| 0x4
|}

===OutputFormat===
{| class="wikitable" border="1"
|-
! Enum
! Value
|-
| OUTPUT_RGB_32
| 0x0
|-
| OUTPUT_RGB_24
| 0x1
|-
| OUTPUT_RGB_16_555
| 0x2
|-
| OUTPUT_RGB_16_565
| 0x3
|}

===Rotation===
{| class="wikitable" border="1"
|-
! Enum
! Value
|-
| ROTATION_NONE
| 0x0
|-
| ROTATION_CLOCKWISE_90
| 0x1
|-
| ROTATION_CLOCKWISE_180
| 0x2
|-
| ROTATION_CLOCKWISE_270
| 0x3
|}

===BlockAlignment===
{| class="wikitable" border="1"
|-
! Enum
! Value
! Description
|-
| BLOCK_LINE
| 0x0
| Output buffer's pixels are arranged linearly. Used when outputting to the framebuffer.
|-
| BLOCK_8_BY_8
| 0x1
| Output buffer's pixels are morton swizzled. Used when outputting to a GPU texture.
|}

===CoefficientParams===
{| class="wikitable" border="1"
! Type
! Field
|-
| u16
| Y_A
|-
| u16
| R_V
|-
| u16
| G_V
|-
| u16
| G_U
|-
| u16
| B_U
|-
| u16
| R_Offset
|-
| u16
| G_Offset
|-
| u16
| B_Offset
|}

===StandardCoefficient===
{| class="wikitable" border="1"
|-
! Enum
! Value
|-
| COEFFICIENT_ITU_R_BT_601
| 0x0
|-
| COEFFICIENT_ITU_R_BT_709
| 0x1
|-
| COEFFICIENT_ITU_R_BT_601_SCALING
| 0x2
|-
| COEFFICIENT_ITU_R_BT_709_SCALING
| 0x3
|}

===DitheringWeightParams===
{| class="wikitable" border="1"
! Type
! Field
|-
| u16
| w0_xEven_yEven
|-
| u16
| w0_xOdd_yEven
|-
| u16
| w0_xEven_yOdd
|-
| u16
| w0_xOdd_yOdd
|-
| u16
| w1_xEven_yEven
|-
| u16
| w1_xOdd_yEven
|-
| u16
| w1_xEven_yOdd
|-
| u16
| w1_xOdd_yOdd
|-
| u16
| w2_xEven_yEven
|-
| u16
| w2_xOdd_yEven
|-
| u16
| w2_xEven_yOdd
|-
| u16
| w2_xOdd_yOdd
|-
| u16
| w3_xEven_yEven
|-
| u16
| w3_xOdd_yEven
|-
| u16
| w3_xEven_yOdd
|-
| u16
| w3_xOdd_yOdd
|}

===PackageParameter===
{| class="wikitable" border="1"
! Type
! Field
|-
| u8
| [[Camera_Services#InputFormat|InputFormat]] inputFormat
|-
| u8
| [[Camera_Services#OutputFormat_2|OutputFormat]] outputFormat
|-
| u8
| [[Camera_Services#Rotation|Rotation]] rotation
|-
| u8
| [[Camera_Services#BlockAlignment|BlockAlignment]] blockAlignment
|-
| s16
| inputLineWidth
|-
| s16
| inputLines
|-
| u8
| [[Camera_Services#StandardCoefficient|StandardCoefficient]] standardCoefficient
|-
| u8
| padding
|-
| s16
| alpha
|}

Services

2020-06-15T04:41:15Z

Unknown: /* Notifications */ Generated using corgi3ds

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

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

Processes with PID less than or equal to the number of NATIVE_FIRM built-in modules (fs, sm, pm, pxi, ldr) have access to all services. This value is obtained from [[SVC|svcGetSystemInfo]]. Other processes are limited to access services listed in their [[NCCH/Extended_Header#ARM11_Local_System_Capabilities|service access control list]], as passed to [[SRVPM:RegisterProcess]].

Attempting to use [[SRV:GetServiceHandle|GetServiceHandle]] with a service that the process has access to when that service isn't registered will block until it is registered.

==Service Manager Port "srv:"==
{| class="wikitable" border="1"
|-
! Command Header
! Description
|-
| 0x00010002
| [[SRV:RegisterClient|RegisterClient]]
|-
| 0x00020000
| [[SRV:EnableNotification|EnableNotification]]
|-
| 0x00030100
| [[SRV:RegisterService|RegisterService]]
|-
| 0x000400C0
| [[SRV:UnregisterService|UnregisterService]]
|-
| 0x00050100
| [[SRV:GetServiceHandle|GetServiceHandle]]
|-
| 0x000600C2
| [[SRV:RegisterPort|RegisterPort]]
|-
| 0x000700C0
| [[SRV:UnregisterPort|UnregisterPort]]
|-
| 0x00080100
| [[SRV:GetPort|GetPort]]
|-
| 0x00090040
| [[SRV:Subscribe|Subscribe]]
|-
| 0x000A0040
| [[SRV:Unsubscribe|Unsubscribe]]
|-
| 0x000B0000
| [[SRV:ReceiveNotification|ReceiveNotification]]
|-
| 0x000C0080
| [[SRV:PublishToSubscriber|PublishToSubscriber]]
|-
| 0x000D0040
| [[SRV:PublishAndGetSubscriber|PublishAndGetSubscriber]]
|-
| 0x000E00C0
| [[SRV:IsServiceRegistered|IsServiceRegistered]]
|}

It appears these "port" commands can be used for transferring arbitrary handles, however [[SRV:GetPort|GetPort]] still uses the same service-access-control validation as [[SRV:GetServiceHandle|GetServiceHandle]]. Despite this fact, it appears that a "port" and a service with the same name can coexist independently.

==Service Manager Process-Manager Port/Service "srv:pm"==
{| class="wikitable" border="1"
|-
! Command Header (port), prior to [[7.0.0-13]]
! Command Header (service), post [[7.0.0-13]]
! Description
|-
| 0x04010042
| 0x00010042
| [[SRVPM:PublishToProcess|PublishToProcess]]
|-
| 0x04020040
| 0x00020040
| [[SRVPM:PublishToAll|PublishToAll]]
|-
| 0x04030082
| 0x00030082
| [[SRVPM:RegisterProcess|RegisterProcess]]
|-
| 0x04040040
| 0x00040040
| [[SRVPM:UnregisterProcess|UnregisterProcess]]
|}

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

==Notifications==
{| class="wikitable" border="1"
|-
! ID
! Published by
! Subscribed by
! Description
|-
| 0x100
|
| Not Needed
| This indicates that the recipient must terminate.
|-
| 0x101
| PTM
| NS
| Signaled on sleep mode entry.
|-
| 0x102
| PTM
| NS
| Sleep Mode related?
|-
| 0x103
| PTM
| NS, CSND, NWM, AC, NIM
| Fired on sleep mode entry (Kernel state is modified by PTM after publishing this)
|-
| 0x104
| PTM
|
| This indicates that the system is entering sleep mode. (Kernel state is modified by PTM before publishing this)
|-
| 0x105
| PTM
| NS, DSP, CSND, GSP, CODEC, CAMERA, HID, QTM, MIC, IR, NWM, FRIENDS, AC, CECD, ACT, NDM, NIM
| This indicates that the system has exited sleep mode.
|-
| 0x106
| PTM
| NS, MIC, AC, NEWS, CECD, BOSS
| Fired after sleep mode exit.
|-
| 0x107
| PTM
| NWM, CECD, BOSS, NDM, NIM, NEWS
| Unknown.
|-
| 0x108
| PTM
| GSP, QTM
| System is going to Power Down.
|-
| 0x109
| CFG
| GSP
| ?
|-
| 0x10B
| CFG
| CAMERA
| ?
|-
| 0x10C
| PM
|
| A Regular application has started.
|-
| 0x110-0x11F
| PM
| NS
| Sent on application exit. See [[PMApp:LaunchTitle#Launch_Flags|PM launch flags]].
|-
| 0x179
| PM
| PTM, NS
| All processes other than PTM and NS have terminated.
|-
| 0x200
|
| NS
| Signaled just before sleep mode is exited from.
|-
| 0x202
| MCU
| NS
| POWER button pressed
|-
| 0x203
| MCU
| NS
| POWER button held long
|-
| 0x204
| MCU
| NS
| HOME button pressed
|-
| 0x205
| MCU
| NS
| HOME button released
|-
| 0x206
| MCU / NWM
| NWM
| The physical Wi-Fi slider state changed
|-
| 0x207
|
| MENU
| SD card inserted
|-
| 0x208
|
| MENU
| Game cartridge inserted
|-
| 0x209
|
| NS, MENU
| SD card removed
|-
| 0x20A
|
| NS, MENU
| Game cartridge removed
|-
| 0x20B
|
| NS, MENU
| Game cartridge inserted or removed
|-
| 0x20C
| MCU
| PTM
| Published on a (fatal) hardware condition?, ptm throws fatal error F960D407 in receipt of this
|-
| 0x20D
| MCU
| GSP
| Charger plugged out.
|-
| 0x20E
| MCU
| GSP
| Charger plugged in.
|-
| 0x20F
| MCU
|
| Published by the mcu module when (bitmask & 0x8000) is true. This bitmask is obtained by reading i2c register 0x10.
|-
| 0x210
| MCU
|
| Published by the mcu module when (bitmask & 0x4000) is true. This bitmask is obtained by reading i2c register 0x10.
|-
| 0x211
| PTM
|
| Battery very low (5%)
|-
| 0x212
| PTM
|
| Battery low (10%)
|-
| 0x213
|
| CODEC, HID, GSP, CAMERA, MIC, NDM, QTM, PTM
| Signaled after exiting sleep mode and early during system boot. GSP powers LCD on in receipt to this, etc.
|-
| 0x214
|
| CODEC, HID, GSP, CAMERA, MIC, NDM, QTM, PTM.
| Signaled before entering sleep mode. GSP shutdowns LCD in receipt to this, etc.
|-
| 0x300
| AC
| NDM, MENU
| Signaled after sleep mode exit and during system boot.
|-
| 0x301
| AC
| FRIENDS, NDM
| Signaled just before sleep mode is exited from.
|-
| 0x302
| NWM
| NDM, SOCKET, FRIENDS, AC
| Unknown.
|-
| 0x303
|
| CECD, NDM
| Unknown.
|-
| 0x304
|
| CECD, NDM, SOCKET
| Unknown
|}

SOCU:poll

2019-11-24T11:05:01Z

Unknown: /* Events */ Fix values for flags and add new flags

=Request=
{| class="wikitable" border="1"
|-
! Index Word
! Description
|-
| 0
| Header code [0x00140084]
|-
| 1
| nfds_t nfds
|-
| 2
| int timeout
|-
| 3
| Value 0x20 (processID header)
|-
| 4
| ProcessID set by the ARM11 kernel.
|-
| 5
| (insize<<14) <nowiki>|</nowiki> 0x2802
|-
| 6
| Pointer to input pollfd struct array
|}

The following is located 0x100-bytes after the beginning of the above command buffer:
{| class="wikitable" border="1"
|-
! Index Word
! Description
|-
| 0
| (outsize<<14) <nowiki>|</nowiki> 2
|-
| 1
| Pointer to output pollfd struct array
|}

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

=pollfd struct=
{| class="wikitable" border="1"
|-
! Type
! Name
! Description
|-
| u32
| fd
| Socket handle
|-
| u32
| events
| Events to poll for (input)
|-
| u32
| revents
| Events received (output)
|}

=Events=
Events are a bitwise set of these flags.
{| class="wikitable" border="1"
|-
! Value
! Name
! Description
|-
| 0x01
| POLLRDNORM
| Normal data can be read.
|-
| 0x02
| POLLRDBAND
| Priority Band Data can be read.
|-
| 0x04
| POLLPRI
| Urgent data can be read.
|-
| 0x08
| POLLWRNORM
| Normal data can be written.
|-
| 0x10
| POLLWRBAND
| Priority data can be written.
|-
| 0x20
| POLLERR
| Socket has an error condition.
|-
| 0x40
| POLLHUP
| Socket has been disconnected.
|-
| 0x80
| POLLNVAL
| Invalid socket handle. This is set if you use fd=-1, which is non-standard behavior.
|-
| POLLRDNORM <nowiki>|</nowiki> POLLRDBAND
| POLLIN
| Data can be read.
|-
| POLLWRNORM
| POLLOUT
| Data can be written.
|}

Services

2019-10-14T12:36:58Z

Unknown: /* Notifications */

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

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

Processes with PID less than or equal to the number of NATIVE_FIRM built-in modules (fs, sm, pm, pxi, ldr) have access to all services. This value is obtained from [[SVC|svcGetSystemInfo]]. Other processes are limited to access services listed in their [[NCCH/Extended_Header#ARM11_Local_System_Capabilities|service access control list]], as passed to [[SRVPM:RegisterProcess]].

Attempting to use [[SRV:GetServiceHandle|GetServiceHandle]] with a service that the process has access to when that service isn't registered will block until it is registered.

==Service Manager Port "srv:"==
{| class="wikitable" border="1"
|-
! Command Header
! Description
|-
| 0x00010002
| [[SRV:RegisterClient|RegisterClient]]
|-
| 0x00020000
| [[SRV:EnableNotification|EnableNotification]]
|-
| 0x00030100
| [[SRV:RegisterService|RegisterService]]
|-
| 0x000400C0
| [[SRV:UnregisterService|UnregisterService]]
|-
| 0x00050100
| [[SRV:GetServiceHandle|GetServiceHandle]]
|-
| 0x000600C2
| [[SRV:RegisterPort|RegisterPort]]
|-
| 0x000700C0
| [[SRV:UnregisterPort|UnregisterPort]]
|-
| 0x00080100
| [[SRV:GetPort|GetPort]]
|-
| 0x00090040
| [[SRV:Subscribe|Subscribe]]
|-
| 0x000A0040
| [[SRV:Unsubscribe|Unsubscribe]]
|-
| 0x000B0000
| [[SRV:ReceiveNotification|ReceiveNotification]]
|-
| 0x000C0080
| [[SRV:PublishToSubscriber|PublishToSubscriber]]
|-
| 0x000D0040
| [[SRV:PublishAndGetSubscriber|PublishAndGetSubscriber]]
|-
| 0x000E00C0
| [[SRV:IsServiceRegistered|IsServiceRegistered]]
|}

It appears these "port" commands can be used for transferring arbitrary handles, however [[SRV:GetPort|GetPort]] still uses the same service-access-control validation as [[SRV:GetServiceHandle|GetServiceHandle]]. Despite this fact, it appears that a "port" and a service with the same name can coexist independently.

==Service Manager Process-Manager Port/Service "srv:pm"==
{| class="wikitable" border="1"
|-
! Command Header (port), prior to [[7.0.0-13]]
! Command Header (service), post [[7.0.0-13]]
! Description
|-
| 0x04010042
| 0x00010042
| [[SRVPM:PublishToProcess|PublishToProcess]]
|-
| 0x04020040
| 0x00020040
| [[SRVPM:PublishToAll|PublishToAll]]
|-
| 0x04030082
| 0x00030082
| [[SRVPM:RegisterProcess|RegisterProcess]]
|-
| 0x04040040
| 0x00040040
| [[SRVPM:UnregisterProcess|UnregisterProcess]]
|}

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

==Notifications==
{| class="wikitable" border="1"
|-
! ID
! Description
|-
| 0x100
| This indicates that the recipient must terminate. Does not require subscription.
|-
| 0x101
| Signaled to NS on sleep mode entry.
|-
| 0x102
| Sleep Mode related? Published by PTM
|-
| 0x103
| Fired on sleep mode entry, subscribed to by NS, CSND, NWM, AC and NIM. (Kernel state is modified by PTM after publishing this)
|-
| 0x104
| This indicates that the system is entering sleep mode. (Kernel state is modified by PTM before publishing this)
|-
| 0x105
| This indicates that the system has exited sleep mode.
|-
| 0x106
| Fired after sleep mode exit, subscribed to by NS, MIC, AC, NEWS, CECD and BOSS.
|-
| 0x107
| Unknown. Subscribed to by CECD module.
|-
| 0x108
| System is going to Power Down. Published by PTM.
|-
| 0x109
| ? (Subscribed to by GSP)
|-
| 0x10C
| Sent by PM after it starts a regular application.
|-
| 0x110-0x11F
| Sent to NS on application exit. See [[PMApp:LaunchTitle#Launch_Flags|PM launch flags]].
|-
| 0x179
| Unknown.
|-
| 0x200
| Signaled just before sleep mode is exited from, subscribed to by NS.
|-
| 0x202
| POWER button pressed
|-
| 0x203
| POWER button held long
|-
| 0x204
| HOME button pressed
|-
| 0x205
| HOME button released
|-
| 0x206
| This is signaled by [[NWMEXT:ControlWirelessEnabled]] and when the physical Wi-Fi slider is enabled
|-
| 0x207
| SD card inserted
|-
| 0x208
| Game cartridge inserted
|-
| 0x209
| SD card removed
|-
| 0x20A
| Game cartridge removed
|-
| 0x20B
| Game cartridge inserted or removed
|-
| 0x20C
| mcu-module publishes this on a (fatal) hardware condition?, ptm throws fatal error F960D407 in receipt of this
|-
| 0x20D
| Charger plugged out
|-
| 0x20E
| Charger plugged in
|-
| 0x20F
| Published by the mcu module when (bitmask & 0x8000) is true. This bitmask is obtained by reading i2c register 0x10.
|-
| 0x210
| Published by the mcu module when (bitmask & 0x4000) is true. This bitmask is obtained by reading i2c register 0x10.
|-
| 0x211
| Battery Related? (Published by PTM module)
|-
| 0x212
| Battery Related? (Published by PTM module)
|-
| 0x213
| Signaled after exiting sleep mode and early during system boot. Subscribed to by CODEC, HID, GSP, CAMERA, MIC, NDM and PTM. GSP powers LCD on in receipt to this, etc.
|-
| 0x214
| Signaled before entering sleep mode. Subscribed to by CODEC, HID, GSP, CAMERA, MIC, NDM and PTM. GSP shutdowns LCD in receipt to this, etc.
|-
| 0x300
| Signaled after sleep mode exit and during system boot, subscribed to by NDM.
|-
| 0x301
| Signaled just before sleep mode is exited from, subscribed to by FRIENDS and NDM.
|-
| 0x302
| Unknown. Signaled by nwm/AC module.
|-
| 0x303
| Unknown. Subscribed to by CECD module.
|-
| 0x304
| Unknown. Subscribed to by CECD module.
|}

Services

2019-10-14T11:51:53Z

Unknown: /* Notifications */ 0x108 -> System is going to Power down

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

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

Processes with PID less than or equal to the number of NATIVE_FIRM built-in modules (fs, sm, pm, pxi, ldr) have access to all services. This value is obtained from [[SVC|svcGetSystemInfo]]. Other processes are limited to access services listed in their [[NCCH/Extended_Header#ARM11_Local_System_Capabilities|service access control list]], as passed to [[SRVPM:RegisterProcess]].

Attempting to use [[SRV:GetServiceHandle|GetServiceHandle]] with a service that the process has access to when that service isn't registered will block until it is registered.

==Service Manager Port "srv:"==
{| class="wikitable" border="1"
|-
! Command Header
! Description
|-
| 0x00010002
| [[SRV:RegisterClient|RegisterClient]]
|-
| 0x00020000
| [[SRV:EnableNotification|EnableNotification]]
|-
| 0x00030100
| [[SRV:RegisterService|RegisterService]]
|-
| 0x000400C0
| [[SRV:UnregisterService|UnregisterService]]
|-
| 0x00050100
| [[SRV:GetServiceHandle|GetServiceHandle]]
|-
| 0x000600C2
| [[SRV:RegisterPort|RegisterPort]]
|-
| 0x000700C0
| [[SRV:UnregisterPort|UnregisterPort]]
|-
| 0x00080100
| [[SRV:GetPort|GetPort]]
|-
| 0x00090040
| [[SRV:Subscribe|Subscribe]]
|-
| 0x000A0040
| [[SRV:Unsubscribe|Unsubscribe]]
|-
| 0x000B0000
| [[SRV:ReceiveNotification|ReceiveNotification]]
|-
| 0x000C0080
| [[SRV:PublishToSubscriber|PublishToSubscriber]]
|-
| 0x000D0040
| [[SRV:PublishAndGetSubscriber|PublishAndGetSubscriber]]
|-
| 0x000E00C0
| [[SRV:IsServiceRegistered|IsServiceRegistered]]
|}

It appears these "port" commands can be used for transferring arbitrary handles, however [[SRV:GetPort|GetPort]] still uses the same service-access-control validation as [[SRV:GetServiceHandle|GetServiceHandle]]. Despite this fact, it appears that a "port" and a service with the same name can coexist independently.

==Service Manager Process-Manager Port/Service "srv:pm"==
{| class="wikitable" border="1"
|-
! Command Header (port), prior to [[7.0.0-13]]
! Command Header (service), post [[7.0.0-13]]
! Description
|-
| 0x04010042
| 0x00010042
| [[SRVPM:PublishToProcess|PublishToProcess]]
|-
| 0x04020040
| 0x00020040
| [[SRVPM:PublishToAll|PublishToAll]]
|-
| 0x04030082
| 0x00030082
| [[SRVPM:RegisterProcess|RegisterProcess]]
|-
| 0x04040040
| 0x00040040
| [[SRVPM:UnregisterProcess|UnregisterProcess]]
|}

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

==Notifications==
{| class="wikitable" border="1"
|-
! ID
! Description
|-
| 0x100
| This indicates that the recipient must terminate. Does not require subscription.
|-
| 0x101
| Signaled to NS on sleep mode entry.
|-
| 0x102
| Sleep Mode related? Published by PTM
|-
| 0x103
| Fired on sleep mode entry, subscribed to by NS, CSND, NWM, AC and NIM.
|-
| 0x104
| This indicates that the system is entering sleep mode. (PTM:NotifySleepPreparationComplete needed for this and the following?)
|-
| 0x105
| This indicates that the system has exited sleep mode.
|-
| 0x106
| Fired after sleep mode exit, subscribed to by NS, MIC, AC, NEWS, CECD and BOSS.
|-
| 0x107
| Unknown. Subscribed to by CECD module.
|-
| 0x108
| System is going to Power Down. Published by PTM.
|-
| 0x109
| ? (Subscribed to by GSP)
|-
| 0x10C
| Sent by PM after it starts a regular application.
|-
| 0x110-0x11F
| Sent to NS on application exit. See [[PMApp:LaunchTitle#Launch_Flags|PM launch flags]].
|-
| 0x179
| Unknown.
|-
| 0x200
| Signaled just before sleep mode is exited from, subscribed to by NS.
|-
| 0x202
| POWER button pressed
|-
| 0x203
| POWER button held long
|-
| 0x204
| HOME button pressed
|-
| 0x205
| HOME button released
|-
| 0x206
| This is signaled by [[NWMEXT:ControlWirelessEnabled]] and when the physical Wi-Fi slider is enabled
|-
| 0x207
| SD card inserted
|-
| 0x208
| Game cartridge inserted
|-
| 0x209
| SD card removed
|-
| 0x20A
| Game cartridge removed
|-
| 0x20B
| Game cartridge inserted or removed
|-
| 0x20C
| mcu-module publishes this on a (fatal) hardware condition?, ptm throws fatal error F960D407 in receipt of this
|-
| 0x20D
| Charger plugged out
|-
| 0x20E
| Charger plugged in
|-
| 0x20F
| Published by the mcu module when (bitmask & 0x8000) is true. This bitmask is obtained by reading i2c register 0x10.
|-
| 0x210
| Published by the mcu module when (bitmask & 0x4000) is true. This bitmask is obtained by reading i2c register 0x10.
|-
| 0x211
| Battery Related? (Published by PTM module)
|-
| 0x212
| Battery Related? (Published by PTM module)
|-
| 0x213
| Signaled after exiting sleep mode and early during system boot. Subscribed to by CODEC, HID, GSP, CAMERA, MIC, NDM and PTM. GSP powers LCD on in receipt to this, etc.
|-
| 0x214
| Signaled before entering sleep mode. Subscribed to by CODEC, HID, GSP, CAMERA, MIC, NDM and PTM. GSP shutdowns LCD in receipt to this, etc.
|-
| 0x300
| Signaled after sleep mode exit and during system boot, subscribed to by NDM.
|-
| 0x301
| Signaled just before sleep mode is exited from, subscribed to by FRIENDS and NDM.
|-
| 0x302
| Unknown. Signaled by nwm/AC module.
|-
| 0x303
| Unknown. Subscribed to by CECD module.
|-
| 0x304
| Unknown. Subscribed to by CECD module.
|}

Services

2019-10-14T11:24:32Z

Unknown: /* Notifications */ Include some information about notifs 0x210 and 0x20F

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

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

Processes with PID less than or equal to the number of NATIVE_FIRM built-in modules (fs, sm, pm, pxi, ldr) have access to all services. This value is obtained from [[SVC|svcGetSystemInfo]]. Other processes are limited to access services listed in their [[NCCH/Extended_Header#ARM11_Local_System_Capabilities|service access control list]], as passed to [[SRVPM:RegisterProcess]].

Attempting to use [[SRV:GetServiceHandle|GetServiceHandle]] with a service that the process has access to when that service isn't registered will block until it is registered.

==Service Manager Port "srv:"==
{| class="wikitable" border="1"
|-
! Command Header
! Description
|-
| 0x00010002
| [[SRV:RegisterClient|RegisterClient]]
|-
| 0x00020000
| [[SRV:EnableNotification|EnableNotification]]
|-
| 0x00030100
| [[SRV:RegisterService|RegisterService]]
|-
| 0x000400C0
| [[SRV:UnregisterService|UnregisterService]]
|-
| 0x00050100
| [[SRV:GetServiceHandle|GetServiceHandle]]
|-
| 0x000600C2
| [[SRV:RegisterPort|RegisterPort]]
|-
| 0x000700C0
| [[SRV:UnregisterPort|UnregisterPort]]
|-
| 0x00080100
| [[SRV:GetPort|GetPort]]
|-
| 0x00090040
| [[SRV:Subscribe|Subscribe]]
|-
| 0x000A0040
| [[SRV:Unsubscribe|Unsubscribe]]
|-
| 0x000B0000
| [[SRV:ReceiveNotification|ReceiveNotification]]
|-
| 0x000C0080
| [[SRV:PublishToSubscriber|PublishToSubscriber]]
|-
| 0x000D0040
| [[SRV:PublishAndGetSubscriber|PublishAndGetSubscriber]]
|-
| 0x000E00C0
| [[SRV:IsServiceRegistered|IsServiceRegistered]]
|}

It appears these "port" commands can be used for transferring arbitrary handles, however [[SRV:GetPort|GetPort]] still uses the same service-access-control validation as [[SRV:GetServiceHandle|GetServiceHandle]]. Despite this fact, it appears that a "port" and a service with the same name can coexist independently.

==Service Manager Process-Manager Port/Service "srv:pm"==
{| class="wikitable" border="1"
|-
! Command Header (port), prior to [[7.0.0-13]]
! Command Header (service), post [[7.0.0-13]]
! Description
|-
| 0x04010042
| 0x00010042
| [[SRVPM:PublishToProcess|PublishToProcess]]
|-
| 0x04020040
| 0x00020040
| [[SRVPM:PublishToAll|PublishToAll]]
|-
| 0x04030082
| 0x00030082
| [[SRVPM:RegisterProcess|RegisterProcess]]
|-
| 0x04040040
| 0x00040040
| [[SRVPM:UnregisterProcess|UnregisterProcess]]
|}

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

==Notifications==
{| class="wikitable" border="1"
|-
! ID
! Description
|-
| 0x100
| This indicates that the recipient must terminate. Does not require subscription.
|-
| 0x101
| Signaled to NS on sleep mode entry.
|-
| 0x102
| Sleep Mode related? Published by PTM
|-
| 0x103
| Fired on sleep mode entry, subscribed to by NS, CSND, NWM, AC and NIM.
|-
| 0x104
| This indicates that the system is entering sleep mode. (PTM:NotifySleepPreparationComplete needed for this and the following?)
|-
| 0x105
| This indicates that the system has exited sleep mode.
|-
| 0x106
| Fired after sleep mode exit, subscribed to by NS, MIC, AC, NEWS, CECD and BOSS.
|-
| 0x107
| Unknown. Subscribed to by CECD module.
|-
| 0x108
| error at boot?
|-
| 0x109
| ? (Subscribed to by GSP)
|-
| 0x10C
| Sent by PM after it starts a regular application.
|-
| 0x110-0x11F
| Sent to NS on application exit. See [[PMApp:LaunchTitle#Launch_Flags|PM launch flags]].
|-
| 0x179
| Unknown.
|-
| 0x200
| Signaled just before sleep mode is exited from, subscribed to by NS.
|-
| 0x202
| POWER button pressed
|-
| 0x203
| POWER button held long
|-
| 0x204
| HOME button pressed
|-
| 0x205
| HOME button released
|-
| 0x206
| This is signaled by [[NWMEXT:ControlWirelessEnabled]] and when the physical Wi-Fi slider is enabled
|-
| 0x207
| SD card inserted
|-
| 0x208
| Game cartridge inserted
|-
| 0x209
| SD card removed
|-
| 0x20A
| Game cartridge removed
|-
| 0x20B
| Game cartridge inserted or removed
|-
| 0x20C
| mcu-module publishes this on a (fatal) hardware condition?, ptm throws fatal error F960D407 in receipt of this
|-
| 0x20D
| Charger plugged out
|-
| 0x20E
| Charger plugged in
|-
| 0x20F
| Published by the mcu module when (bitmask & 0x8000) is true. This bitmask is obtained by reading i2c register 0x10.
|-
| 0x210
| Published by the mcu module when (bitmask & 0x4000) is true. This bitmask is obtained by reading i2c register 0x10.
|-
| 0x211
| Battery Related? (Published by PTM module)
|-
| 0x212
| Battery Related? (Published by PTM module)
|-
| 0x213
| Signaled after exiting sleep mode and early during system boot. Subscribed to by CODEC, HID, GSP, CAMERA, MIC, NDM and PTM. GSP powers LCD on in receipt to this, etc.
|-
| 0x214
| Signaled before entering sleep mode. Subscribed to by CODEC, HID, GSP, CAMERA, MIC, NDM and PTM. GSP shutdowns LCD in receipt to this, etc.
|-
| 0x300
| Signaled after sleep mode exit and during system boot, subscribed to by NDM.
|-
| 0x301
| Signaled just before sleep mode is exited from, subscribed to by FRIENDS and NDM.
|-
| 0x302
| Unknown. Signaled by nwm/AC module.
|-
| 0x303
| Unknown. Subscribed to by CECD module.
|-
| 0x304
| Unknown. Subscribed to by CECD module.
|}

Configuration Memory

2019-10-13T12:40:06Z

Unknown: /* Shared Memory Page For ARM11 Processes */

= ARM11 Kernel Configuration Memory =
{| class="wikitable" border="1"
! NAME
! PROCESS VIRTUAL ADDRESS
! WIDTH
|-
| KERNEL_?
| 0x1FF80000
| 1
|-
| KERNEL_VERSIONREVISION
| 0x1FF80001
| 1
|-
| KERNEL_VERSIONMINOR
| 0x1FF80002
| 1
|-
| KERNEL_VERSIONMAJOR
| 0x1FF80003
| 1
|-
| UPDATEFLAG
| 0x1FF80004
| 4
|-
| NSTID
| 0x1FF80008
| 8
|-
| SYSCOREVER
| 0x1FF80010
| 4
|-
| ENVINFO
| 0x1FF80014
| 1
|-
| UNITINFO
| 0x1FF80015
| 1
|-
| PREV_FIRM
| 0x1FF80016
| 1
|-
| KERNEL_CTRSDKVERSION
| 0x1FF80018
| 4
|-
| APPMEMTYPE
| 0x1FF80030
| 4
|-
| APPMEMALLOC
| 0x1FF80040
| 4
|-
| SYSMEMALLOC
| 0x1FF80044
| 4
|-
| BASEMEMALLOC
| 0x1FF80048
| 4
|-
| FIRM_?
| 0x1FF80060
| 1
|-
| FIRM_VERSIONREVISION
| 0x1FF80061
| 1
|-
| FIRM_VERSIONMINOR
| 0x1FF80062
| 1
|-
| FIRM_VERSIONMAJOR
| 0x1FF80063
| 1
|-
| FIRM_SYSCOREVER
| 0x1FF80064
| 4
|-
| FIRM_CTRSDKVERSION
| 0x1FF80068
| 4
|}

This memory page is mapped as "shared device" (it is thus uncached) and [[Memory_layout|read-only]] for ARM11 processes. This memory and the kernel code for it only exists under NATIVE_FIRM/SAFE_MODE_FIRM.

The FIRM_* fields are by default identical to the KERNEL_* fields. However, the FIRM_* fields can be overridden via FIRM-launch parameters, see [[FIRM|here]].

Besides mem-region related fields, the data written here by the old 3DS/new 3DS kernels is identical.

= Shared Memory Page For ARM11 Processes =
{| class="wikitable" border="1"
! NAME
! PROCESS VIRTUAL ADDRESS
! WIDTH
|-
| bit0 selects DATETIME_0 or DATETIME_1.
| 0x1FF81000
| 4
|-
| RUNNING_HW (1=product, 2=devboard, 3=debugger, 4=capture, 5=?)
| 0x1FF81004
| 1
|-
| MCU_HW_INFO
| 0x1FF81005
| 1
|-
| ? (Set by PTM) Possibe values are 2, 4, 6, 7, 8 and 9
| 0x1FF81006
| 1
|-
| DATETIME_0 {(u64)MillisecondsSinceFirstJan1900,(u64)SystemTickLastTimeThisWasUpdated,(u32)unk(set to 0xFFB0FF0 by PTM),(u32)Set to 0 by PTM,(u32)Set to 0 by PTM,(u32)set to 0 by PTM}
| 0x1FF81020
| 32
|-
| DATETIME_1
| 0x1FF81040
| 32
|-
| WIFI_MACADDR
| 0x1FF81060
| 6
|-
| WIFI_LINKLEVEL Ranges from 0-3; 0 stands for no or a poor network connection; 3 stands for a good connection. This corresponds with the number of wifi bars displayed by [[Home Menu]].
| 0x1FF81066
| 1
|-
| NETWORK_STATE The network state displayed by [[Home Menu]]. 2: Internet, 3/4/6: Local, 7: Disabled, Everything else: Enabled
| 0x1FF81067
| 1
|-
| 3D_SLIDERSTATE
| 0x1FF81080
| 4
|-
| 3D_LEDSTATE
| 0x1FF81084
| 1
|-
| BATTERY_LEDSTATE
| 0x1FF81085
| 1
|-
| On startup, and under certain conditions, NS will continuously call svcSleepThread(1000*1000) as long as bit0 of this field is clear. ptmInitialize() sets this after writing MCU unit info to sharedmem.
| 0x1FF81086
| 1
|-
| MENUTID
| 0x1FF810A0
| 8
|-
| ACTIVEMENUTID
| 0x1FF810A8
| 8
|-
| Signed? Headsets connected?
| 0x1FF810C0
| 1
|}

This memory page is normally read-only for ARM11 processes, write-access is [[Memory_layout|determined]] by the process exheader kernel "shared page writing" flag. It is mapped as "shared device" (it is thus uncached) in both cases.

This memory only exists under NATIVE_FIRM/SAFE_MODE_FIRM.

= ARM11 Kernel Config Fields =

== 0x1FF80000 / 0x1FF80060 ==
Unknown, this is normally value 0.

== KERNEL_VERSIONREVISION / FIRM_VERSIONREVISION ==
This is the version-revision for the currently running [[FIRM]].

== KERNEL_VERSIONMINOR ==
This is the version-minor from ((title-version & 0x3FF) >> 4), for the currently running [[FIRM]]. The values from KERNEL_VERSIONMINOR and KERNEL_VERSIONMAJOR can be stored in applications' [[NCCH#CXI|CXI]] exheader.

== FIRM_VERSIONMINOR ==
This is the same as KERNEL_VERSIONMINOR. After [[AM:InstallNATIVEFIRM]] checks FIRM_SYSCOREVER, [[AM:InstallNATIVEFIRM]] then compares FIRM_VERSIONMINOR with the NATIVE_FIRM ((title-version & 0x3FF) >> 4), when the latter is larger than FIRM_VERSIONMINOR [[AM:InstallNATIVEFIRM]] will trigger a [[FIRM]] install.

== KERNEL_VERSIONMAJOR / FIRM_VERSIONMAJOR ==
This is the version-major for the currently running [[FIRM]].

The kernel initializes KERNEL_VERSIONMAJOR and SYSCOREVER with the same constant value.

== UPDATEFLAG ==
Normally this flag is zero. When the ARM11 kernel is booting on non-factory FIRM it will set this flag to 1, when bit0 from the data which field 0x1FF80016 is loaded from is clear, if the following [[PAD]] buttons are pressed: L, R, A, Up. When this flag is set, [[NS]] will launch the [[System_Settings#System_Updater|System Updater]] title instead of [[Home Menu]].

== NSTID ==
This field contains the titleID of the first title to launch from CTR-NAND after the [[FIRM]] system processes are loaded. The [[Process_Manager_Services|PM]] module launches this title. If this field titleID is all-zero, the system will not attempt to launch the title. The regular ARM11 kernel sets this to the regular [[NS]] titleID, while the SAFE_MODE ARM11 kernel sets this to the SAFE_MODE NS titleID. The factory FIRM ARM11-kernel sets this to the NS TID from [[Factory_Setup|here]].

== SYSCOREVER ==
This field is initialized by the ARM11 kernel, this is the programID-low of the running FIRM. When launching [[NCCH#CXI|CXIs]], the value stored here must match the core version field stored in the CXI exheader. If they do not match, the [[Process_Manager_Services|PM]] module will refuse to launch the ARM11 process.

With [[Factory_Setup|factory]] NATIVE_FIRM, this is set to 0x0, even though the FIRM programID-low is 0x2. However, the factory system-titles have core-version set to 0x2. Hence, this config-mem SYSCOREVER field might not be used by factory system processes?

== FIRM_SYSCOREVER ==
Normally this is the same as SYSCOREVER. This used by [[AM:InstallNATIVEFIRM]] for comparing with the NATIVE_FIRM titleID-low. When the low u8 from the NATIVE_FIRM titleID-low is larger than FIRMSYSCOREVER, [[AM:InstallNATIVEFIRM]] will trigger FIRM installing. When that u8 is not larger than FIRM_SYSCOREVER, and these two values don't match, [[AM:InstallNATIVEFIRM]] will return an error.

== ENVINFO ==
{| class="wikitable" border="1"
! Bit
! Description
|-
| 0
| Clear for developer unit, set for retail.(See 0x1FF80015)
|-
| 1
| IsJtagConnected
|-
| 2-7
|?
|}

Bit1 in this field is set by the ARM11 kernel when ARM debug CP14 DSCR bit14 is set (halting debug-mode enabled). [[NS]] loads the menu TID from MENUTID when bits 1-7 of this field are clear. [[ErrDisp]] will display development error info when bit0 is clear.

== UNITINFO ==
{| class="wikitable" border="1"
! Value
! Boot Env
|-
| 0
| Prod
|-
| 1
| Dev
|-
| 2
| Debugger
|-
| 3
| Firm
|}

The ARM11 loads the value of [[CONFIG_Registers#CFG_UNITINFO|CFG_UNITINFO]] from 0x1FFFFFF0+1 during startup, which is written by the ARM9 during ARM9<>ARM11 kernel sync.

When this field is zero, bit0 for ENVINFO is set for retail. When this field is non-zero, bit0 for ENVINFO is clear for dev/debug units, and an ARM11 kernel state flag which enables debugging is set. JTAG is only enabled for debugger and "firm" modes (bit1).

== PREV_FIRM ==
{| class="wikitable" border="1"
! Value
! Description
|-
| 0
| Cold Boot
|-
| 1
| Reset from CTR mode
|-
| 3
| Reset from TWL mode
|-
| 5
| Reset from NTR mode
|-
| 7
| Reset from AGB mode
|}

The ARM11 loads this value from 0x1FFFFFF0+2 during startup, which is written by the ARM9 during ARM9<>ARM11 kernel sync.

This originates from the low 8-bits of register [[CONFIG|0x10010000]]. When bit0 is set, the ARM11 kernel will not set the UPDATEFLAG to value 1.

== KERNEL_CTRSDKVERSION / FIRM_CTRSDKVERSION ==
This is the CTR-SDK version which was used to build the currently running [[FIRM]].

== APPMEMTYPE ==
The value of this field determines the size for APPMEMALLOC. The retail type(value0) is used when the type is not values 2-5. See [[Memory_layout]] for the table of values for this and the mem-region sizes.

== APPMEMALLOC ==
This contains the total size of the memory that can be allocated with the APPLICATION [[SVC|memory-region]], see [[Memory_layout|here]].

== SYSMEMALLOC ==
Same as APPMEMALLOC except for the SYSTEM mem-region, see [[Memory_layout|here]].

== BASEMEMALLOC ==
Same as APPMEMALLOC except for the BASE mem-region, see [[Memory_layout|here]].

= Shared Memory Page Fields =

== WIFI_MACADDR ==
This is the WiFi MAC address for the 3DS. This is initialized by the [[NWM_Services|NWM]] module, it's unknown where the MAC address written here was originally loaded from.

== 3D_SLIDERSTATE ==
This float contains the state of the 3D slider. The range of this float is value 0.0f for "off", and 1.0f for max.

This is written/updated by [[HID_Services|HID]] module.

== 3D_LEDSTATE ==
When non-zero, the 3D LED is disabled. See [[GSPGPU:SetLedForceOff]].

== BATTERY_LEDSTATE ==
Bit[0] is set when the adapter is connected. Bit[1] is set when the battery is charging. Bit[2:4] is the value of [[PTM:GetBatteryLevel|battery level]]. If the connection bit is set but the charging bit is clear, it means the battery is already fully charged but still with adapter connected.

== MENUTID ==
Unknown, contains the menu TID (used by [[NS]])

== ACTIVEMENUTID ==
This contains the titleID of the currently running menu launched by [[NS]].

= NATIVE_FIRM Versions =

See [[FIRM#NATIVE_FIRM|FIRM]].

Services

2019-10-08T07:38:03Z

Unknown: /* Notifications */

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

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

Processes with PID less than or equal to the number of NATIVE_FIRM built-in modules (fs, sm, pm, pxi, ldr) have access to all services. This value is obtained from [[SVC|svcGetSystemInfo]]. Other processes are limited to access services listed in their [[NCCH/Extended_Header#ARM11_Local_System_Capabilities|service access control list]], as passed to [[SRVPM:RegisterProcess]].

Attempting to use [[SRV:GetServiceHandle|GetServiceHandle]] with a service that the process has access to when that service isn't registered will block until it is registered.

==Service Manager Port "srv:"==
{| class="wikitable" border="1"
|-
! Command Header
! Description
|-
| 0x00010002
| [[SRV:RegisterClient|RegisterClient]]
|-
| 0x00020000
| [[SRV:EnableNotification|EnableNotification]]
|-
| 0x00030100
| [[SRV:RegisterService|RegisterService]]
|-
| 0x000400C0
| [[SRV:UnregisterService|UnregisterService]]
|-
| 0x00050100
| [[SRV:GetServiceHandle|GetServiceHandle]]
|-
| 0x000600C2
| [[SRV:RegisterPort|RegisterPort]]
|-
| 0x000700C0
| [[SRV:UnregisterPort|UnregisterPort]]
|-
| 0x00080100
| [[SRV:GetPort|GetPort]]
|-
| 0x00090040
| [[SRV:Subscribe|Subscribe]]
|-
| 0x000A0040
| [[SRV:Unsubscribe|Unsubscribe]]
|-
| 0x000B0000
| [[SRV:ReceiveNotification|ReceiveNotification]]
|-
| 0x000C0080
| [[SRV:PublishToSubscriber|PublishToSubscriber]]
|-
| 0x000D0040
| [[SRV:PublishAndGetSubscriber|PublishAndGetSubscriber]]
|-
| 0x000E00C0
| [[SRV:IsServiceRegistered|IsServiceRegistered]]
|}

It appears these "port" commands can be used for transferring arbitrary handles, however [[SRV:GetPort|GetPort]] still uses the same service-access-control validation as [[SRV:GetServiceHandle|GetServiceHandle]]. Despite this fact, it appears that a "port" and a service with the same name can coexist independently.

==Service Manager Process-Manager Port/Service "srv:pm"==
{| class="wikitable" border="1"
|-
! Command Header (port), prior to [[7.0.0-13]]
! Command Header (service), post [[7.0.0-13]]
! Description
|-
| 0x04010042
| 0x00010042
| [[SRVPM:PublishToProcess|PublishToProcess]]
|-
| 0x04020040
| 0x00020040
| [[SRVPM:PublishToAll|PublishToAll]]
|-
| 0x04030082
| 0x00030082
| [[SRVPM:RegisterProcess|RegisterProcess]]
|-
| 0x04040040
| 0x00040040
| [[SRVPM:UnregisterProcess|UnregisterProcess]]
|}

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

==Notifications==
{| class="wikitable" border="1"
|-
! ID
! Description
|-
| 0x100
| This indicates that the recipient must terminate. Does not require subscription.
|-
| 0x101
| Signaled to NS on sleep mode entry.
|-
| 0x102
| Sleep Mode related? Published by PTM
|-
| 0x103
| Fired on sleep mode entry, subscribed to by NS, CSND, NWM, AC and NIM.
|-
| 0x104
| This indicates that the system is entering sleep mode. (PTM:NotifySleepPreparationComplete needed for this and the following?)
|-
| 0x105
| This indicates that the system has exited sleep mode.
|-
| 0x106
| Fired after sleep mode exit, subscribed to by NS, MIC, AC, NEWS, CECD and BOSS.
|-
| 0x107
| Unknown. Subscribed to by CECD module.
|-
| 0x108
| error at boot?
|-
| 0x109
| ? (Subscribed to by GSP)
|-
| 0x10C
| Sent by PM after it starts a regular application.
|-
| 0x110-0x11F
| Sent to NS on application exit. See [[PMApp:LaunchTitle#Launch_Flags|PM launch flags]].
|-
| 0x179
| Unknown.
|-
| 0x200
| Signaled just before sleep mode is exited from, subscribed to by NS.
|-
| 0x202
| POWER button pressed
|-
| 0x203
| POWER button held long
|-
| 0x204
| HOME button pressed
|-
| 0x205
| HOME button released
|-
| 0x206
| This is signaled by [[NWMEXT:ControlWirelessEnabled]] and when the physical Wi-Fi slider is enabled
|-
| 0x207
| SD card inserted
|-
| 0x208
| Game cartridge inserted
|-
| 0x209
| SD card removed
|-
| 0x20A
| Game cartridge removed
|-
| 0x20B
| Game cartridge inserted or removed
|-
| 0x20C
| mcu-module publishes this on a (fatal) hardware condition?, ptm throws fatal error F960D407 in receipt of this
|-
| 0x20D
| Charger plugged out
|-
| 0x20E
| Charger plugged in
|-
| 0x211
| Battery Related? (Published by PTM module)
|-
| 0x212
| Battery Related? (Published by PTM module)
|-
| 0x213
| Signaled after exiting sleep mode and early during system boot. Subscribed to by CODEC, HID, GSP, CAMERA, MIC, NDM and PTM. GSP powers LCD on in receipt to this, etc.
|-
| 0x214
| Signaled before entering sleep mode. Subscribed to by CODEC, HID, GSP, CAMERA, MIC, NDM and PTM. GSP shutdowns LCD in receipt to this, etc.
|-
| 0x300
| Signaled after sleep mode exit and during system boot, subscribed to by NDM.
|-
| 0x301
| Signaled just before sleep mode is exited from, subscribed to by FRIENDS and NDM.
|-
| 0x302
| Unknown. Signaled by nwm/AC module.
|-
| 0x303
| Unknown. Subscribed to by CECD module.
|-
| 0x304
| Unknown. Subscribed to by CECD module.
|}

MCU Services

2019-10-08T06:10:27Z

Unknown: /* MCU service "mcu::RTC" */ 0x2E0000 -> SetPowerModeIndicatorState

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

=MCU camera service "mcu::CAM"=
{| class="wikitable" border="1"
|-
! Command Header
! Description
|-
| 0x00010040
| WriteCameraLedState (writes i2c register 0x2B)
|-
| 0x00020080
| ReadCameraLedState (reads i2c register 0x2B)
|}

=MCU GPU service "mcu::GPU"=
{| class="wikitable" border="1"
|-
! Command Header
! Description
|-
| 0x00010000
| GetLcdPowerState. This writes the value of I2C-MCU register 0xf bit6 to u8 cmdreply[2], and the value of bit5 from that register to u8 cmdreply[3].
|-
| 0x00020080
| SetLcdPowerState. This writes the upper LCD bits of MCU register 0x22.
|-
| 0x00030000
| GetGpuLcdInterfaceState. This writes the value of I2C-MCU register 0xf bit7 to u8 cmdreply[2].
|-
| 0x00040040
| SetGpuLcdInterfaceState. This writes the lower two bits of MCU register 0x22.
|-
| 0x00050040
| SetTopScreenFlicker
|-
| 0x00060080
| GetTopScreenFlicker
|-
| 0x00070040
| SetBottomScreenFlicker
|-
| 0x00080080
| GetBottomScreenFlicker
|-
| 0x00090000
| GetMcuFwVerHigh. Called by GSP module
|-
| 0x000A0000
| GetMcuFwVerLow. Called by GSP module
|-
| 0x000B0040
| Set3dLedState
|-
| 0x000C0000
| Get3dLedState
|-
| 0x000D0000
| GetMcuGpuEventHandle. Event handle written to TLS+0x8c. MCU notifications 24 to 29 signal this.
|-
| 0x000E0000
| GetMcuGpuEventReason. Writes some value to TLS+0x88. Called by GSP module
|}

=MCU HID service "mcu::HID"=
{| class="wikitable" border="1"
|-
! Command Header
! Description
|-
| 0x00010040
| ?
|-
| 0x00020000
| ??? test register 0x40 bit0, and writes result to IPC+8
|-
| 0x00030040
| ??? writes IPC+4 to register 0x41
|-
| 0x00040000
| ??? reads register 0x44 to IPC+8
|-
| 0x00050080
| ??? writes IPC+4 to register 0x43 and IPC+8 to register 0x44
|-
| 0x00060000
| ReadGyroscopeValues (reads 3x s16 gyro ADC values into IPC+8)
|-
| 0x00070000
| GetRaw3DSliderPosition (u8 position in IPC+8)
|-
| 0x00080040
| ?
|-
| 0x00090000
| ?
|-
| 0x000A0040
| ?
|-
| 0x000B0000
| ?
|-
| 0x000C0000
| GetMcuHidEventHandle. MCU notifications 11 and 12 signal this. Handle is written to IPC+12
|-
| 0x000D0000
| GetMcuHidEventReason. This reads an internal flield into IPC+8 and clears it.
|-
| 0x000E0000
| [[MCUHID:GetSoundVolume|GetSoundVolume]]
|-
| 0x000F0040
| EnableAccelerometerInterrupt(int enable). 1 = enable, 0 = disable accelerometer
|}

While before these functions are handled, the MCU interrupt with bitmask 0x800 is enabled, then after the commands were handled the MCU interrupt bits 0x1800 get cleared.

=MCU service "mcu::RTC"=
{| class="wikitable" border="1"
|-
! Command Header
! Description
|-
| 0x00010080
| [[MCURTC:SetRTC|SetRTC]]
|-
| 0x00020000
| [[MCURTC:GetRTC|GetRTC]]
|-
| 0x00030040
| SetRTCSeconds(u8 seconds)
|-
| 0x00040000
| u8 GetRTCSeconds
|-
| 0x00050040
| SetRTCMinutes(u8 minutes)
|-
| 0x00060000
| u8 GetRTCMinutes
|-
| 0x00070040
| SetRTCHours(u8 hours)
|-
| 0x00080000
| u8 GetRTCHours
|-
| 0x00090040
| SetRTCDayOfWeek(u8 dayno)
|-
| 0x000A0000
| u8 GetRTCDayOfWeek
|-
| 0x000B0040
| SetRTCDayOfMonth(u8 day)
|-
| 0x000C0000
| u8 GetRTCDayOfMonth
|-
| 0x000D0040
| SetRTCMonth(u8 month)
|-
| 0x000E0000
| u8 GetRTCMonth
|-
| 0x000F0040
| SetRTCYear(u8 year) where year = year - 2000
|-
| 0x00100000
| u8 GetRTCYear where year = result + 2000
|-
| 0x00110040
| SetRTCLeapYearCounter(u8 leap)
|-
| 0x00120000
| u8 GetRTCLeapYearCounter
|-
| 0x00130080
| [[MCURTC:SetRTCAlarm|SetRTCAlarm]]
|-
| 0x00140000
| [[MCURTC:GetRTCAlarm|GetRTCAlarm]]
|-
| 0x00150040
| SetRTCAlarmComponent[0] (u8 val)
|-
| 0x00160000
| u8 GetRTCAlarmComponent[0]
|-
| 0x00170040
| SetRTCAlarmComponent[1] (u8 val)
|-
| 0x00180000
| u8 GetRTCAlarmComponent[1]
|-
| 0x00190040
| SetRTCAlarmComponent[2] (u8 val)
|-
| 0x001A0000
| u8 GetRTCAlarmComponent[2]
|-
| 0x001B0040
| SetRTCAlarmComponent[3] (u8 val)
|-
| 0x001C0000
| u8 GetRTCAlarmComponent[3]
|-
| 0x001D0040
| SetRTCAlarmComponent[4] (u8 val)
|-
| 0x001E0000
| u8 GetRTCAlarmComponent[4]
|-
| 0x001F0040
| SetPedometerRecordingMode(u8 mode)
|-
| 0x00200000
| u8 GetPedometerRecordingMode
|-
| 0x00210080
| u8 GetStepCount (for the current day)
|-
| 0x00220042
| ReadRegister4Fh(u32 unused_size, translation_param size=0x156 << 4 <nowiki>|</nowiki> 0xC, u8[0x156] ptr)
|-
| 0x00230000
| void ??? writes 1 to register 0x4E which is not writable
|-
| 0x00240000
| Handle GetPowerEventHandle. MCU notifications 1, 8, 9, 10, 13, 14 and 15 signal this.
see [[I2C_Registers#Device_3|Register 0x18]]
|-
| 0x00250000
| u32 GetPowerInterruptHistory
|-
| 0x00260000
| bool CheckRegister02hBit0
|-
| 0x00270000
| void ClearRegister02hBit0 (does nothing since the register is not writable)
|-
| 0x00280000
| bool CheckRegister02hBit1
|-
| 0x00290000
| void ClearRegister02hBit1
|-
| 0x002A0000
| bool GetShellState. This writes the value of I2C-MCU register 0xf bit1 to u8 cmdreply[2].
|-
| 0x002B0000
| bool GetAdapterState. This writes the value of I2C-MCU register 0xf bit3 to u8 cmdreply[2].
|-
| 0x002C0000
| bool GetBatteryChargeState. This writes the value of I2C-MCU register 0xf bit4 to u8 cmdreply[2].
|-
| 0x002D0000
| [[MCURTC:GetBatteryLevel|GetBatteryLevel]]
|-
| 0x002E0000
| u8 SetPowerModeIndicatorState (see [[I2C_Registers#Device_3|Register 0x29]])
|-
| 0x002F0000
| u8 GetBatteryEmptyPatternByte0_safe™
|-
| 0x00300040
| SetLEDBrightness(u8 brightness) (see [[I2C_Registers#Device_3|Register 0x28]])
|-
| 0x00310000
| u8 GetLEDBrightness (see [[I2C_Registers#Device_3|Register 0x28]])
|-
| 0x00320000
| void PowerOff (writes 0x1 to i2c MCU device, [[I2C_Registers#Device_3|reg 0x20]])
|-
| 0x00330000
| void HardwareReboot (writes 0x4 to i2c MCU device, [[I2C_Registers#Device_3|reg 0x20]])
|-
| 0x00340000
| WriteRegister reg=0x23 value=0x72 (writing to read-only registers does nothing)
|-
| 0x00350000
| Writes 0x10 to i2c MCU device, reg 0x20 (this bit of the register is not writable)
|-
| 0x00360040
| SetWatchdogTimer(u8 timer)
|-
| 0x00370000
| u8 GetWatchdogTimer
|-
| 0x00380042
| ReadI2CRegister7Fh(u32 unused_size, translation_param size << 4 <nowiki>|</nowiki> 0xC, u8[0x13] ptr)
|-
| 0x00390082
| WriteLoop (translation parameters too complex)
|-
| 0x003A0082
| ReadLoop (translation parameters too complex)
|-
| 0x003B0640
| [[MCURTC:SetInfoLEDPattern|SetInfoLEDPattern]]
|-
| 0x003C0040
| [[MCURTC:SetInfoLEDPatternHeader|SetInfoLEDPatternHeader]]
|-
| 0x003D0000
| [[MCURTC:GetInfoLEDStatus|GetInfoLEDStatus]]
|-
| 0x003E0040
| WriteRegister50h(u8 value)
|-
| 0x003F0000
| u8 ReadRegister50h
|-
| 0x00400040
| WriteRegister51h(u8 value)
|-
| 0x00410000
| u8 ReadRegister51h
|-
| 0x00420040
| [[MCURTC:SetBatteryEmptyLEDPattern|SetBatteryEmptyLEDPattern]]
|-
| 0x00430040
| SetScreenFlickerTop(u8 flicker)
|-
| 0x00440000
| u8 GetScreenFlickerTop
|-
| 0x00450040
| SetScreenFlickerBottom(u8 flicker)
|-
| 0x00460000
| u8 GetScreenFlickerBottom
|-
| 0x00470080
| SetVolumeSliderBounds(u8 low, u8 high) (see [[I2C_Registers#Device_3|Register 0x58]])
|-
| 0x00480000
| u8 low, u8 high GetVolumeSliderBounds
|-
| 0x00490040
| SetInterruptMask(u32 mask) (see [[I2C_Registers#Device_3|Register 0x18]])
|-
| 0x004A0000
| u32 GetInterruptMask (see [[I2C_Registers#Device_3|Register 0x18]])
|-
| 0x004B0000
| void ExitExclusiveInterruptMode
|-
| 0x004C0000
| void EnterExclusiveInterruptMode
|-
| 0x004D0000
| [[MCURTC:ReadInterrupt|ReadInterrupt]] (see [[I2C_Registers#Device_3|Register 0x10]])
|-
| 0x004E0040
| [[MCURTC:PublishNotifications|TriggerInterrupt]]
|-
| 0x004F0040
| SetMCUFirmUpdated(u32 flag) used by PTM module
|-
| 0x00500000
| u32 IsMCUFirmUpdated
|-
| 0x00510040
| [[MCURTC:SetSoftwareClosedFlag|SetSoftwareClosedFlag]]
|-
| 0x00520000
| [[MCURTC:GetSoftwareClosedFlag|GetSoftwareClosedFlag]]
|-
| 0x00530040
| ?
|-
| 0x00540000
| ?
|-
| 0x00550040
| ?
|-
| 0x00560000
| ?
|-
| 0x00570040
| ?
|-
| 0x00580000
| ?
|-
| 0x00590040
| [[MCURTC:SetLegacyJumpProhibitedFlag|SetLegacyJumpProhibitedFlag]]
|-
| 0x005A0000
| [[MCURTC:GetLegacyJumpProhibitedFlag|GetLegacyJumpProhibitedFlag]]
|-
| 0x005B0040
| SetUUIDClockSequence
|-
| 0x005C0000
| GetUUIDClockSequence
|-
|}

=MCU sound service "mcu::SND"=
{| class="wikitable" border="1"
|-
! Command Header
! Description
|-
| 0x00010080
| GetSoundVolume, writes volume slider value (0-63) to IPC+8
|-
| 0x00020040
| Set...
|-
| 0x00030000
| GetRegister25h, cmdbuf[2] is 0 on n3ds
|}

=MCU wifi service "mcu::NWM"=
{| class="wikitable" border="1"
|-
! Command Header
! Description
|-
| 0x0001....
| SetWirelessLedState
|-
| 0x0002....
| GetWirelessLedState
|-
| 0x0003....
| Sets GPIO 0x20 high/low?
|-
| 0x0004....
| Gets GPIO 0x20 high/low?
|-
| 0x0005....
| SetEnableWifiGpio
|-
| 0x0006....
| GetEnableWifiGpio
|-
| 0x0007....
| [[MCUNWM:SetWirelessDisabledFlag|SetWirelessDisabledFlag]]
|-
| 0x0008....
| [[MCUNWM:GetWirelessDisabledFlag|GetWirelessDisabledFlag]]
|}

=MCU service "mcu::HWC"=
{| class="wikitable" border="1"
|-
! Command Header
! Description
|-
| 0x00010082
| [[MCUHWC:ReadRegister|ReadRegister]]
|-
| 0x00020082
| [[MCUHWC:WriteRegister|WriteRegister]]
|-
| 0x00030042
| [[MCUHWC:GetInfoRegisters|GetInfoRegisters]]
|-
| 0x00040000
| [[MCUHWC:GetBatteryVoltage|GetBatteryVoltage]]
|-
| 0x00050000
| [[MCUHWC:GetBatteryLevel|GetBatteryLevel]]
|-
| 0x00060040
| [[MCUHWC:SetPowerLEDPattern|SetPowerLEDPattern]]
|-
| 0x00070040
| [[MCUHWC:SetWifiLEDState|SetWifiLEDState]]
|-
| 0x00080040
| [[MCUHWC:SetCameraLEDPattern|SetCameraLEDPattern]]
|-
| 0x00090040
| [[MCUHWC:Set3DLEDState|Set3DLEDState]]
|-
| 0x000A0640
| This is the same as [[MCURTC:SetInfoLEDPattern]].
|-
| 0x000B0000
| [[MCUHWC:GetSoundVolume|GetSoundVolume]]
|-
| 0x000C0040
| SetTopScreenFlicker
|-
| 0x000D0040
| SetBottomScreenFlicker
|-
| 0x000E0080
| ?
|-
| 0x000F00C0
| GetRtcTime
|-
| 0x00100000
| GetMcuFwVerHigh
|-
| 0x00110000
| GetMcuFwVerLow
|}

=MCU service "mcu::PLS"=

<s>Beg the sysmodule to return the datetime registers in decimal form instead of as a Binary Coded Decimal</s>

{| class="wikitable" border="1"
|-
! Command Header
! Description
|-
| 0x00010000
| GetDatetime (returns registers 0x30-0x36 in IPC+8)
|-
| 0x00020000
| [[MCUPLS:GetSeconds|GetSeconds]]
|-
| 0x00030000
| u8 GetMinutes
|-
| 0x00040000
| u8 GetHour
|-
| 0x00050000
| u8 GetDayOfWeek
|-
| 0x00060000
| u8 GetDay
|-
| 0x00070000
| u8 GetMonth
|-
| 0x00080000
| u8 GetYear
|-
| 0x00090000
| u16 GetTickCounter
|}

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

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

=MCU firmware versions=

These reside in mcu sysmodule .rodata, are uploaded to MCU register 0x05 and are usually 0x4003 bytes in size (the actual firmware is 0x4000 bytes preceeded by a 3 byte magic header "<code>jhl</code>" which switches the I2C comms into flash write mode).
Switching requires register 0x05 (at address <code>0xFFBA9</code>) to contain 0x6A ('<code>j</code>'), register 0x06 containing 0x68 ('<code>h</code>'), and writing 0x6C ('<code>l</code>') to register 0x07. The actual flashing sequence is only signaled (code at 0x3312-0x331A) when writing register 0x07, it's skipped otherwise. Register 0x07 gets written anyways, just the actual signaling is skipped if the conditions aren't met.

Before the upload could commence, external MCU interrupts are turned off via GPIO command 0x00020080(0, 0x40000), then after the upload completed, the sysmodule waits exactly one second for the MCU to reboot, then turns external MCU interrupts back on via <code>gpio:MCU</code> command 0x00020080(0x40000, 0x40000).

There exists an alternate code path in very old MCU_FIRM versions where uploading is done using register 0x3B (if register 0x0F is zero and 0x10 is 1). Register 0x3B is part of the RTC alarm registers on recent versions of MCU.

On dev-units, the user-facing representation of this firmware version is displayed by first subtracting 0x10 from the major field (raw register 0x00). It is these user-facing versions that are displayed in the table below. It is unknown what bit4 (0x10) actually represents, but it is seemingly always set.

{| class="wikitable" border="1"
|-
! Title version
! Firmware
|-
| New3DS v9216 (New2DSXL)
| 3.65
|-
| New3DS v8192/safe v9217 (latest)
| 3.56
|-
| Old3DS v6145 to v8192 (latest)
| 2.37
|-
| Old3DS v5122
| 2.35
|-
| Old3DS v4102
| 2.30
|-
| Old3DS v3072
| 2.16
|-
| Old3DS v2048
| 1.52
|-
| Old3DS v1026
| 1.51
|-
| Old3DS v0/safe v0
| 1.20
|-
| Old3DS factory
| 1.07
|}

Services

2019-10-08T05:39:15Z

Unknown: /* Notifications */ Add notif 0x102

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

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

Processes with PID less than or equal to the number of NATIVE_FIRM built-in modules (fs, sm, pm, pxi, ldr) have access to all services. This value is obtained from [[SVC|svcGetSystemInfo]]. Other processes are limited to access services listed in their [[NCCH/Extended_Header#ARM11_Local_System_Capabilities|service access control list]], as passed to [[SRVPM:RegisterProcess]].

Attempting to use [[SRV:GetServiceHandle|GetServiceHandle]] with a service that the process has access to when that service isn't registered will block until it is registered.

==Service Manager Port "srv:"==
{| class="wikitable" border="1"
|-
! Command Header
! Description
|-
| 0x00010002
| [[SRV:RegisterClient|RegisterClient]]
|-
| 0x00020000
| [[SRV:EnableNotification|EnableNotification]]
|-
| 0x00030100
| [[SRV:RegisterService|RegisterService]]
|-
| 0x000400C0
| [[SRV:UnregisterService|UnregisterService]]
|-
| 0x00050100
| [[SRV:GetServiceHandle|GetServiceHandle]]
|-
| 0x000600C2
| [[SRV:RegisterPort|RegisterPort]]
|-
| 0x000700C0
| [[SRV:UnregisterPort|UnregisterPort]]
|-
| 0x00080100
| [[SRV:GetPort|GetPort]]
|-
| 0x00090040
| [[SRV:Subscribe|Subscribe]]
|-
| 0x000A0040
| [[SRV:Unsubscribe|Unsubscribe]]
|-
| 0x000B0000
| [[SRV:ReceiveNotification|ReceiveNotification]]
|-
| 0x000C0080
| [[SRV:PublishToSubscriber|PublishToSubscriber]]
|-
| 0x000D0040
| [[SRV:PublishAndGetSubscriber|PublishAndGetSubscriber]]
|-
| 0x000E00C0
| [[SRV:IsServiceRegistered|IsServiceRegistered]]
|}

It appears these "port" commands can be used for transferring arbitrary handles, however [[SRV:GetPort|GetPort]] still uses the same service-access-control validation as [[SRV:GetServiceHandle|GetServiceHandle]]. Despite this fact, it appears that a "port" and a service with the same name can coexist independently.

==Service Manager Process-Manager Port/Service "srv:pm"==
{| class="wikitable" border="1"
|-
! Command Header (port), prior to [[7.0.0-13]]
! Command Header (service), post [[7.0.0-13]]
! Description
|-
| 0x04010042
| 0x00010042
| [[SRVPM:PublishToProcess|PublishToProcess]]
|-
| 0x04020040
| 0x00020040
| [[SRVPM:PublishToAll|PublishToAll]]
|-
| 0x04030082
| 0x00030082
| [[SRVPM:RegisterProcess|RegisterProcess]]
|-
| 0x04040040
| 0x00040040
| [[SRVPM:UnregisterProcess|UnregisterProcess]]
|}

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

==Notifications==
{| class="wikitable" border="1"
|-
! ID
! Description
|-
| 0x100
| This indicates that the recipient must terminate. Does not require subscription.
|-
| 0x101
| Signaled to NS on sleep mode entry.
|-
| 0x102
| Sleep Mode related? Published by PTM
|-
| 0x103
| Fired on sleep mode entry, subscribed to by NS, CSND, NWM, AC and NIM.
|-
| 0x104
| This indicates that the system is entering sleep mode. (PTM:NotifySleepPreparationComplete needed for this and the following?)
|-
| 0x105
| This indicates that the system has exited sleep mode.
|-
| 0x106
| Fired after sleep mode exit, subscribed to by NS, MIC, AC, NEWS, CECD and BOSS.
|-
| 0x107
| Unknown. Subscribed to by CECD module.
|-
| 0x108
| error at boot?
|-
| 0x109
| ? (Subscribed to by GSP)
|-
| 0x10C
| Sent by PM after it starts a regular application.
|-
| 0x110-0x11F
| Sent to NS on application exit. See [[PMApp:LaunchTitle#Launch_Flags|PM launch flags]].
|-
| 0x179
| Unknown.
|-
| 0x200
| Signaled just before sleep mode is exited from, subscribed to by NS.
|-
| 0x202
| POWER button pressed
|-
| 0x203
| POWER button held long
|-
| 0x204
| HOME button pressed
|-
| 0x205
| HOME button released
|-
| 0x206
| This is signaled by [[NWMEXT:ControlWirelessEnabled]] and when the physical Wi-Fi slider is enabled
|-
| 0x207
| SD card inserted
|-
| 0x208
| Game cartridge inserted
|-
| 0x209
| SD card removed
|-
| 0x20A
| Game cartridge removed
|-
| 0x211
| Battery Related? (Published by PTM module)
|-
| 0x212
| Battery Related? (Published by PTM module)
|-
| 0x20B
| Game cartridge inserted or removed
|-
| 0x20C
| mcu-module publishes this on a (fatal) hardware condition?, ptm throws fatal error F960D407 in receipt of this
|-
| 0x20D
| Charger plugged out
|-
| 0x20E
| Charger plugged in
|-
| 0x213
| Signaled after exiting sleep mode and early during system boot. Subscribed to by CODEC, HID, GSP, CAMERA, MIC, NDM and PTM. GSP powers LCD on in receipt to this, etc.
|-
| 0x214
| Signaled before entering sleep mode. Subscribed to by CODEC, HID, GSP, CAMERA, MIC, NDM and PTM. GSP shutdowns LCD in receipt to this, etc.
|-
| 0x300
| Signaled after sleep mode exit and during system boot, subscribed to by NDM.
|-
| 0x301
| Signaled just before sleep mode is exited from, subscribed to by FRIENDS and NDM.
|-
| 0x302
| Unknown. Signaled by nwm/AC module.
|-
| 0x303
| Unknown. Subscribed to by CECD module.
|-
| 0x304
| Unknown. Subscribed to by CECD module.
|}

Configuration Memory

2019-10-08T04:52:58Z

Unknown: /* Shared Memory Page For ARM11 Processes */

= ARM11 Kernel Configuration Memory =
{| class="wikitable" border="1"
! NAME
! PROCESS VIRTUAL ADDRESS
! WIDTH
|-
| KERNEL_?
| 0x1FF80000
| 1
|-
| KERNEL_VERSIONREVISION
| 0x1FF80001
| 1
|-
| KERNEL_VERSIONMINOR
| 0x1FF80002
| 1
|-
| KERNEL_VERSIONMAJOR
| 0x1FF80003
| 1
|-
| UPDATEFLAG
| 0x1FF80004
| 4
|-
| NSTID
| 0x1FF80008
| 8
|-
| SYSCOREVER
| 0x1FF80010
| 4
|-
| ENVINFO
| 0x1FF80014
| 1
|-
| UNITINFO
| 0x1FF80015
| 1
|-
| PREV_FIRM
| 0x1FF80016
| 1
|-
| KERNEL_CTRSDKVERSION
| 0x1FF80018
| 4
|-
| APPMEMTYPE
| 0x1FF80030
| 4
|-
| APPMEMALLOC
| 0x1FF80040
| 4
|-
| SYSMEMALLOC
| 0x1FF80044
| 4
|-
| BASEMEMALLOC
| 0x1FF80048
| 4
|-
| FIRM_?
| 0x1FF80060
| 1
|-
| FIRM_VERSIONREVISION
| 0x1FF80061
| 1
|-
| FIRM_VERSIONMINOR
| 0x1FF80062
| 1
|-
| FIRM_VERSIONMAJOR
| 0x1FF80063
| 1
|-
| FIRM_SYSCOREVER
| 0x1FF80064
| 4
|-
| FIRM_CTRSDKVERSION
| 0x1FF80068
| 4
|}

This memory page is mapped as "shared device" (it is thus uncached) and [[Memory_layout|read-only]] for ARM11 processes. This memory and the kernel code for it only exists under NATIVE_FIRM/SAFE_MODE_FIRM.

The FIRM_* fields are by default identical to the KERNEL_* fields. However, the FIRM_* fields can be overridden via FIRM-launch parameters, see [[FIRM|here]].

Besides mem-region related fields, the data written here by the old 3DS/new 3DS kernels is identical.

= Shared Memory Page For ARM11 Processes =
{| class="wikitable" border="1"
! NAME
! PROCESS VIRTUAL ADDRESS
! WIDTH
|-
| bit0 selects DATETIME_0 or DATETIME_1.
| 0x1FF81000
| 4
|-
| RUNNING_HW (1=product, 2=devboard, 3=debugger, 4=capture, 5=?)
| 0x1FF81004
| 1
|-
| MCU_HW_INFO
| 0x1FF81005
| 1
|-
| ? (Set by PTM) Possibe values are 2, 4, 6, 7, 8 and 9
| 0x1FF81006
| 1
|-
| DATETIME_0 {(u64)MillisecondsSinceFirstJan1900,(u64)SystemTickLastTimeThisWasUpdated,(u32)unk,(u32)unk,(u32)unk,(u32)unk}
| 0x1FF81020
| 32
|-
| DATETIME_1
| 0x1FF81040
| 32
|-
| WIFI_MACADDR
| 0x1FF81060
| 6
|-
| WIFI_LINKLEVEL Ranges from 0-3; 0 stands for no or a poor network connection; 3 stands for a good connection. This corresponds with the number of wifi bars displayed by [[Home Menu]].
| 0x1FF81066
| 1
|-
| NETWORK_STATE The network state displayed by [[Home Menu]]. 2: Internet, 3/4/6: Local, 7: Disabled, Everything else: Enabled
| 0x1FF81067
| 1
|-
| 3D_SLIDERSTATE
| 0x1FF81080
| 4
|-
| 3D_LEDSTATE
| 0x1FF81084
| 1
|-
| BATTERY_LEDSTATE
| 0x1FF81085
| 1
|-
| On startup, and under certain conditions, NS will continuously call svcSleepThread(1000*1000) as long as bit0 of this field is clear. ptmInitialize() sets this after writing MCU unit info to sharedmem.
| 0x1FF81086
| 1
|-
| MENUTID
| 0x1FF810A0
| 8
|-
| ACTIVEMENUTID
| 0x1FF810A8
| 8
|-
| Signed? Headsets connected?
| 0x1FF810C0
| 1
|}

This memory page is normally read-only for ARM11 processes, write-access is [[Memory_layout|determined]] by the process exheader kernel "shared page writing" flag. It is mapped as "shared device" (it is thus uncached) in both cases.

This memory only exists under NATIVE_FIRM/SAFE_MODE_FIRM.

= ARM11 Kernel Config Fields =

== 0x1FF80000 / 0x1FF80060 ==
Unknown, this is normally value 0.

== KERNEL_VERSIONREVISION / FIRM_VERSIONREVISION ==
This is the version-revision for the currently running [[FIRM]].

== KERNEL_VERSIONMINOR ==
This is the version-minor from ((title-version & 0x3FF) >> 4), for the currently running [[FIRM]]. The values from KERNEL_VERSIONMINOR and KERNEL_VERSIONMAJOR can be stored in applications' [[NCCH#CXI|CXI]] exheader.

== FIRM_VERSIONMINOR ==
This is the same as KERNEL_VERSIONMINOR. After [[AM:InstallNATIVEFIRM]] checks FIRM_SYSCOREVER, [[AM:InstallNATIVEFIRM]] then compares FIRM_VERSIONMINOR with the NATIVE_FIRM ((title-version & 0x3FF) >> 4), when the latter is larger than FIRM_VERSIONMINOR [[AM:InstallNATIVEFIRM]] will trigger a [[FIRM]] install.

== KERNEL_VERSIONMAJOR / FIRM_VERSIONMAJOR ==
This is the version-major for the currently running [[FIRM]].

The kernel initializes KERNEL_VERSIONMAJOR and SYSCOREVER with the same constant value.

== UPDATEFLAG ==
Normally this flag is zero. When the ARM11 kernel is booting on non-factory FIRM it will set this flag to 1, when bit0 from the data which field 0x1FF80016 is loaded from is clear, if the following [[PAD]] buttons are pressed: L, R, A, Up. When this flag is set, [[NS]] will launch the [[System_Settings#System_Updater|System Updater]] title instead of [[Home Menu]].

== NSTID ==
This field contains the titleID of the first title to launch from CTR-NAND after the [[FIRM]] system processes are loaded. The [[Process_Manager_Services|PM]] module launches this title. If this field titleID is all-zero, the system will not attempt to launch the title. The regular ARM11 kernel sets this to the regular [[NS]] titleID, while the SAFE_MODE ARM11 kernel sets this to the SAFE_MODE NS titleID. The factory FIRM ARM11-kernel sets this to the NS TID from [[Factory_Setup|here]].

== SYSCOREVER ==
This field is initialized by the ARM11 kernel, this is the programID-low of the running FIRM. When launching [[NCCH#CXI|CXIs]], the value stored here must match the core version field stored in the CXI exheader. If they do not match, the [[Process_Manager_Services|PM]] module will refuse to launch the ARM11 process.

With [[Factory_Setup|factory]] NATIVE_FIRM, this is set to 0x0, even though the FIRM programID-low is 0x2. However, the factory system-titles have core-version set to 0x2. Hence, this config-mem SYSCOREVER field might not be used by factory system processes?

== FIRM_SYSCOREVER ==
Normally this is the same as SYSCOREVER. This used by [[AM:InstallNATIVEFIRM]] for comparing with the NATIVE_FIRM titleID-low. When the low u8 from the NATIVE_FIRM titleID-low is larger than FIRMSYSCOREVER, [[AM:InstallNATIVEFIRM]] will trigger FIRM installing. When that u8 is not larger than FIRM_SYSCOREVER, and these two values don't match, [[AM:InstallNATIVEFIRM]] will return an error.

== ENVINFO ==
{| class="wikitable" border="1"
! Bit
! Description
|-
| 0
| Clear for developer unit, set for retail.(See 0x1FF80015)
|-
| 1
| IsJtagConnected
|-
| 2-7
|?
|}

Bit1 in this field is set by the ARM11 kernel when ARM debug CP14 DSCR bit14 is set (halting debug-mode enabled). [[NS]] loads the menu TID from MENUTID when bits 1-7 of this field are clear. [[ErrDisp]] will display development error info when bit0 is clear.

== UNITINFO ==
{| class="wikitable" border="1"
! Value
! Boot Env
|-
| 0
| Prod
|-
| 1
| Dev
|-
| 2
| Debugger
|-
| 3
| Firm
|}

The ARM11 loads the value of [[CONFIG_Registers#CFG_UNITINFO|CFG_UNITINFO]] from 0x1FFFFFF0+1 during startup, which is written by the ARM9 during ARM9<>ARM11 kernel sync.

When this field is zero, bit0 for ENVINFO is set for retail. When this field is non-zero, bit0 for ENVINFO is clear for dev/debug units, and an ARM11 kernel state flag which enables debugging is set. JTAG is only enabled for debugger and "firm" modes (bit1).

== PREV_FIRM ==
{| class="wikitable" border="1"
! Value
! Description
|-
| 0
| Cold Boot
|-
| 1
| Reset from CTR mode
|-
| 3
| Reset from TWL mode
|-
| 5
| Reset from NTR mode
|-
| 7
| Reset from AGB mode
|}

The ARM11 loads this value from 0x1FFFFFF0+2 during startup, which is written by the ARM9 during ARM9<>ARM11 kernel sync.

This originates from the low 8-bits of register [[CONFIG|0x10010000]]. When bit0 is set, the ARM11 kernel will not set the UPDATEFLAG to value 1.

== KERNEL_CTRSDKVERSION / FIRM_CTRSDKVERSION ==
This is the CTR-SDK version which was used to build the currently running [[FIRM]].

== APPMEMTYPE ==
The value of this field determines the size for APPMEMALLOC. The retail type(value0) is used when the type is not values 2-5. See [[Memory_layout]] for the table of values for this and the mem-region sizes.

== APPMEMALLOC ==
This contains the total size of the memory that can be allocated with the APPLICATION [[SVC|memory-region]], see [[Memory_layout|here]].

== SYSMEMALLOC ==
Same as APPMEMALLOC except for the SYSTEM mem-region, see [[Memory_layout|here]].

== BASEMEMALLOC ==
Same as APPMEMALLOC except for the BASE mem-region, see [[Memory_layout|here]].

= Shared Memory Page Fields =

== WIFI_MACADDR ==
This is the WiFi MAC address for the 3DS. This is initialized by the [[NWM_Services|NWM]] module, it's unknown where the MAC address written here was originally loaded from.

== 3D_SLIDERSTATE ==
This float contains the state of the 3D slider. The range of this float is value 0.0f for "off", and 1.0f for max.

This is written/updated by [[HID_Services|HID]] module.

== 3D_LEDSTATE ==
When non-zero, the 3D LED is disabled. See [[GSPGPU:SetLedForceOff]].

== BATTERY_LEDSTATE ==
Bit[0] is set when the adapter is connected. Bit[1] is set when the battery is charging. Bit[2:4] is the value of [[PTM:GetBatteryLevel|battery level]]. If the connection bit is set but the charging bit is clear, it means the battery is already fully charged but still with adapter connected.

== MENUTID ==
Unknown, contains the menu TID (used by [[NS]])

== ACTIVEMENUTID ==
This contains the titleID of the currently running menu launched by [[NS]].

= NATIVE_FIRM Versions =

See [[FIRM#NATIVE_FIRM|FIRM]].

Configuration Memory

2019-10-08T04:45:28Z

Unknown: /* Shared Memory Page For ARM11 Processes */

= ARM11 Kernel Configuration Memory =
{| class="wikitable" border="1"
! NAME
! PROCESS VIRTUAL ADDRESS
! WIDTH
|-
| KERNEL_?
| 0x1FF80000
| 1
|-
| KERNEL_VERSIONREVISION
| 0x1FF80001
| 1
|-
| KERNEL_VERSIONMINOR
| 0x1FF80002
| 1
|-
| KERNEL_VERSIONMAJOR
| 0x1FF80003
| 1
|-
| UPDATEFLAG
| 0x1FF80004
| 4
|-
| NSTID
| 0x1FF80008
| 8
|-
| SYSCOREVER
| 0x1FF80010
| 4
|-
| ENVINFO
| 0x1FF80014
| 1
|-
| UNITINFO
| 0x1FF80015
| 1
|-
| PREV_FIRM
| 0x1FF80016
| 1
|-
| KERNEL_CTRSDKVERSION
| 0x1FF80018
| 4
|-
| APPMEMTYPE
| 0x1FF80030
| 4
|-
| APPMEMALLOC
| 0x1FF80040
| 4
|-
| SYSMEMALLOC
| 0x1FF80044
| 4
|-
| BASEMEMALLOC
| 0x1FF80048
| 4
|-
| FIRM_?
| 0x1FF80060
| 1
|-
| FIRM_VERSIONREVISION
| 0x1FF80061
| 1
|-
| FIRM_VERSIONMINOR
| 0x1FF80062
| 1
|-
| FIRM_VERSIONMAJOR
| 0x1FF80063
| 1
|-
| FIRM_SYSCOREVER
| 0x1FF80064
| 4
|-
| FIRM_CTRSDKVERSION
| 0x1FF80068
| 4
|}

This memory page is mapped as "shared device" (it is thus uncached) and [[Memory_layout|read-only]] for ARM11 processes. This memory and the kernel code for it only exists under NATIVE_FIRM/SAFE_MODE_FIRM.

The FIRM_* fields are by default identical to the KERNEL_* fields. However, the FIRM_* fields can be overridden via FIRM-launch parameters, see [[FIRM|here]].

Besides mem-region related fields, the data written here by the old 3DS/new 3DS kernels is identical.

= Shared Memory Page For ARM11 Processes =
{| class="wikitable" border="1"
! NAME
! PROCESS VIRTUAL ADDRESS
! WIDTH
|-
| bit0 selects DATETIME_0 or DATETIME_1.
| 0x1FF81000
| 4
|-
| RUNNING_HW (1=product, 2=devboard, 3=debugger, 4=capture)
| 0x1FF81004
| 1
|-
| MCU_HW_INFO
| 0x1FF81005
| 1
|-
| ? (Set by PTM)
| 0x1FF81006
| 1
|-
| DATETIME_0 {(u64)MillisecondsSinceFirstJan1900,(u64)SystemTickLastTimeThisWasUpdated,(u32)unk,(u32)unk,(u32)unk,(u32)unk}
| 0x1FF81020
| 32
|-
| DATETIME_1
| 0x1FF81040
| 32
|-
| WIFI_MACADDR
| 0x1FF81060
| 6
|-
| WIFI_LINKLEVEL Ranges from 0-3; 0 stands for no or a poor network connection; 3 stands for a good connection. This corresponds with the number of wifi bars displayed by [[Home Menu]].
| 0x1FF81066
| 1
|-
| NETWORK_STATE The network state displayed by [[Home Menu]]. 2: Internet, 3/4/6: Local, 7: Disabled, Everything else: Enabled
| 0x1FF81067
| 1
|-
| 3D_SLIDERSTATE
| 0x1FF81080
| 4
|-
| 3D_LEDSTATE
| 0x1FF81084
| 1
|-
| BATTERY_LEDSTATE
| 0x1FF81085
| 1
|-
| On startup, and under certain conditions, NS will continuously call svcSleepThread(1000*1000) as long as bit0 of this field is clear. ptmInitialize() sets this after writing MCU unit info to sharedmem.
| 0x1FF81086
| 1
|-
| MENUTID
| 0x1FF810A0
| 8
|-
| ACTIVEMENUTID
| 0x1FF810A8
| 8
|-
| Signed? Headsets connected?
| 0x1FF810C0
| 1
|}

This memory page is normally read-only for ARM11 processes, write-access is [[Memory_layout|determined]] by the process exheader kernel "shared page writing" flag. It is mapped as "shared device" (it is thus uncached) in both cases.

This memory only exists under NATIVE_FIRM/SAFE_MODE_FIRM.

= ARM11 Kernel Config Fields =

== 0x1FF80000 / 0x1FF80060 ==
Unknown, this is normally value 0.

== KERNEL_VERSIONREVISION / FIRM_VERSIONREVISION ==
This is the version-revision for the currently running [[FIRM]].

== KERNEL_VERSIONMINOR ==
This is the version-minor from ((title-version & 0x3FF) >> 4), for the currently running [[FIRM]]. The values from KERNEL_VERSIONMINOR and KERNEL_VERSIONMAJOR can be stored in applications' [[NCCH#CXI|CXI]] exheader.

== FIRM_VERSIONMINOR ==
This is the same as KERNEL_VERSIONMINOR. After [[AM:InstallNATIVEFIRM]] checks FIRM_SYSCOREVER, [[AM:InstallNATIVEFIRM]] then compares FIRM_VERSIONMINOR with the NATIVE_FIRM ((title-version & 0x3FF) >> 4), when the latter is larger than FIRM_VERSIONMINOR [[AM:InstallNATIVEFIRM]] will trigger a [[FIRM]] install.

== KERNEL_VERSIONMAJOR / FIRM_VERSIONMAJOR ==
This is the version-major for the currently running [[FIRM]].

The kernel initializes KERNEL_VERSIONMAJOR and SYSCOREVER with the same constant value.

== UPDATEFLAG ==
Normally this flag is zero. When the ARM11 kernel is booting on non-factory FIRM it will set this flag to 1, when bit0 from the data which field 0x1FF80016 is loaded from is clear, if the following [[PAD]] buttons are pressed: L, R, A, Up. When this flag is set, [[NS]] will launch the [[System_Settings#System_Updater|System Updater]] title instead of [[Home Menu]].

== NSTID ==
This field contains the titleID of the first title to launch from CTR-NAND after the [[FIRM]] system processes are loaded. The [[Process_Manager_Services|PM]] module launches this title. If this field titleID is all-zero, the system will not attempt to launch the title. The regular ARM11 kernel sets this to the regular [[NS]] titleID, while the SAFE_MODE ARM11 kernel sets this to the SAFE_MODE NS titleID. The factory FIRM ARM11-kernel sets this to the NS TID from [[Factory_Setup|here]].

== SYSCOREVER ==
This field is initialized by the ARM11 kernel, this is the programID-low of the running FIRM. When launching [[NCCH#CXI|CXIs]], the value stored here must match the core version field stored in the CXI exheader. If they do not match, the [[Process_Manager_Services|PM]] module will refuse to launch the ARM11 process.

With [[Factory_Setup|factory]] NATIVE_FIRM, this is set to 0x0, even though the FIRM programID-low is 0x2. However, the factory system-titles have core-version set to 0x2. Hence, this config-mem SYSCOREVER field might not be used by factory system processes?

== FIRM_SYSCOREVER ==
Normally this is the same as SYSCOREVER. This used by [[AM:InstallNATIVEFIRM]] for comparing with the NATIVE_FIRM titleID-low. When the low u8 from the NATIVE_FIRM titleID-low is larger than FIRMSYSCOREVER, [[AM:InstallNATIVEFIRM]] will trigger FIRM installing. When that u8 is not larger than FIRM_SYSCOREVER, and these two values don't match, [[AM:InstallNATIVEFIRM]] will return an error.

== ENVINFO ==
{| class="wikitable" border="1"
! Bit
! Description
|-
| 0
| Clear for developer unit, set for retail.(See 0x1FF80015)
|-
| 1
| IsJtagConnected
|-
| 2-7
|?
|}

Bit1 in this field is set by the ARM11 kernel when ARM debug CP14 DSCR bit14 is set (halting debug-mode enabled). [[NS]] loads the menu TID from MENUTID when bits 1-7 of this field are clear. [[ErrDisp]] will display development error info when bit0 is clear.

== UNITINFO ==
{| class="wikitable" border="1"
! Value
! Boot Env
|-
| 0
| Prod
|-
| 1
| Dev
|-
| 2
| Debugger
|-
| 3
| Firm
|}

The ARM11 loads the value of [[CONFIG_Registers#CFG_UNITINFO|CFG_UNITINFO]] from 0x1FFFFFF0+1 during startup, which is written by the ARM9 during ARM9<>ARM11 kernel sync.

When this field is zero, bit0 for ENVINFO is set for retail. When this field is non-zero, bit0 for ENVINFO is clear for dev/debug units, and an ARM11 kernel state flag which enables debugging is set. JTAG is only enabled for debugger and "firm" modes (bit1).

== PREV_FIRM ==
{| class="wikitable" border="1"
! Value
! Description
|-
| 0
| Cold Boot
|-
| 1
| Reset from CTR mode
|-
| 3
| Reset from TWL mode
|-
| 5
| Reset from NTR mode
|-
| 7
| Reset from AGB mode
|}

The ARM11 loads this value from 0x1FFFFFF0+2 during startup, which is written by the ARM9 during ARM9<>ARM11 kernel sync.

This originates from the low 8-bits of register [[CONFIG|0x10010000]]. When bit0 is set, the ARM11 kernel will not set the UPDATEFLAG to value 1.

== KERNEL_CTRSDKVERSION / FIRM_CTRSDKVERSION ==
This is the CTR-SDK version which was used to build the currently running [[FIRM]].

== APPMEMTYPE ==
The value of this field determines the size for APPMEMALLOC. The retail type(value0) is used when the type is not values 2-5. See [[Memory_layout]] for the table of values for this and the mem-region sizes.

== APPMEMALLOC ==
This contains the total size of the memory that can be allocated with the APPLICATION [[SVC|memory-region]], see [[Memory_layout|here]].

== SYSMEMALLOC ==
Same as APPMEMALLOC except for the SYSTEM mem-region, see [[Memory_layout|here]].

== BASEMEMALLOC ==
Same as APPMEMALLOC except for the BASE mem-region, see [[Memory_layout|here]].

= Shared Memory Page Fields =

== WIFI_MACADDR ==
This is the WiFi MAC address for the 3DS. This is initialized by the [[NWM_Services|NWM]] module, it's unknown where the MAC address written here was originally loaded from.

== 3D_SLIDERSTATE ==
This float contains the state of the 3D slider. The range of this float is value 0.0f for "off", and 1.0f for max.

This is written/updated by [[HID_Services|HID]] module.

== 3D_LEDSTATE ==
When non-zero, the 3D LED is disabled. See [[GSPGPU:SetLedForceOff]].

== BATTERY_LEDSTATE ==
Bit[0] is set when the adapter is connected. Bit[1] is set when the battery is charging. Bit[2:4] is the value of [[PTM:GetBatteryLevel|battery level]]. If the connection bit is set but the charging bit is clear, it means the battery is already fully charged but still with adapter connected.

== MENUTID ==
Unknown, contains the menu TID (used by [[NS]])

== ACTIVEMENUTID ==
This contains the titleID of the currently running menu launched by [[NS]].

= NATIVE_FIRM Versions =

See [[FIRM#NATIVE_FIRM|FIRM]].

MCU Services

2019-10-08T03:12:37Z

Unknown: /* MCU service "mcu::RTC" */

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

=MCU camera service "mcu::CAM"=
{| class="wikitable" border="1"
|-
! Command Header
! Description
|-
| 0x00010040
| WriteCameraLedState (writes i2c register 0x2B)
|-
| 0x00020080
| ReadCameraLedState (reads i2c register 0x2B)
|}

=MCU GPU service "mcu::GPU"=
{| class="wikitable" border="1"
|-
! Command Header
! Description
|-
| 0x00010000
| GetLcdPowerState. This writes the value of I2C-MCU register 0xf bit6 to u8 cmdreply[2], and the value of bit5 from that register to u8 cmdreply[3].
|-
| 0x00020080
| SetLcdPowerState. This writes the upper LCD bits of MCU register 0x22.
|-
| 0x00030000
| GetGpuLcdInterfaceState. This writes the value of I2C-MCU register 0xf bit7 to u8 cmdreply[2].
|-
| 0x00040040
| SetGpuLcdInterfaceState. This writes the lower two bits of MCU register 0x22.
|-
| 0x00050040
| SetTopScreenFlicker
|-
| 0x00060080
| GetTopScreenFlicker
|-
| 0x00070040
| SetBottomScreenFlicker
|-
| 0x00080080
| GetBottomScreenFlicker
|-
| 0x00090000
| GetMcuFwVerHigh. Called by GSP module
|-
| 0x000A0000
| GetMcuFwVerLow. Called by GSP module
|-
| 0x000B0040
| Set3dLedState
|-
| 0x000C0000
| Get3dLedState
|-
| 0x000D0000
| GetMcuGpuEventHandle. Event handle written to TLS+0x8c. MCU notifications 24 to 29 signal this.
|-
| 0x000E0000
| GetMcuGpuEventReason. Writes some value to TLS+0x88. Called by GSP module
|}

=MCU HID service "mcu::HID"=
{| class="wikitable" border="1"
|-
! Command Header
! Description
|-
| 0x00010040
| ?
|-
| 0x00020000
| ??? test register 0x40 bit0, and writes result to IPC+8
|-
| 0x00030040
| ??? writes IPC+4 to register 0x41
|-
| 0x00040000
| ??? reads register 0x44 to IPC+8
|-
| 0x00050080
| ??? writes IPC+4 to register 0x43 and IPC+8 to register 0x44
|-
| 0x00060000
| ReadGyroscopeValues (reads 3x s16 gyro ADC values into IPC+8)
|-
| 0x00070000
| GetRaw3DSliderPosition (u8 position in IPC+8)
|-
| 0x00080040
| ?
|-
| 0x00090000
| ?
|-
| 0x000A0040
| ?
|-
| 0x000B0000
| ?
|-
| 0x000C0000
| GetMcuHidEventHandle. MCU notifications 11 and 12 signal this. Handle is written to IPC+12
|-
| 0x000D0000
| GetMcuHidEventReason. This reads an internal flield into IPC+8 and clears it.
|-
| 0x000E0000
| [[MCUHID:GetSoundVolume|GetSoundVolume]]
|-
| 0x000F0040
| EnableAccelerometerInterrupt(int enable). 1 = enable, 0 = disable accelerometer
|}

While before these functions are handled, the MCU interrupt with bitmask 0x800 is enabled, then after the commands were handled the MCU interrupt bits 0x1800 get cleared.

=MCU service "mcu::RTC"=
{| class="wikitable" border="1"
|-
! Command Header
! Description
|-
| 0x00010080
| [[MCURTC:SetRTC|SetRTC]]
|-
| 0x00020000
| [[MCURTC:GetRTC|GetRTC]]
|-
| 0x00030040
| SetRTCSeconds(u8 seconds)
|-
| 0x00040000
| u8 GetRTCSeconds
|-
| 0x00050040
| SetRTCMinutes(u8 minutes)
|-
| 0x00060000
| u8 GetRTCMinutes
|-
| 0x00070040
| SetRTCHours(u8 hours)
|-
| 0x00080000
| u8 GetRTCHours
|-
| 0x00090040
| SetRTCDayOfWeek(u8 dayno)
|-
| 0x000A0000
| u8 GetRTCDayOfWeek
|-
| 0x000B0040
| SetRTCDayOfMonth(u8 day)
|-
| 0x000C0000
| u8 GetRTCDayOfMonth
|-
| 0x000D0040
| SetRTCMonth(u8 month)
|-
| 0x000E0000
| u8 GetRTCMonth
|-
| 0x000F0040
| SetRTCYear(u8 year) where year = year - 2000
|-
| 0x00100000
| u8 GetRTCYear where year = result + 2000
|-
| 0x00110040
| SetRTCLeapYearCounter(u8 leap)
|-
| 0x00120000
| u8 GetRTCLeapYearCounter
|-
| 0x00130080
| [[MCURTC:SetRTCAlarm|SetRTCAlarm]]
|-
| 0x00140000
| [[MCURTC:GetRTCAlarm|GetRTCAlarm]]
|-
| 0x00150040
| SetRTCAlarmComponent[0] (u8 val)
|-
| 0x00160000
| u8 GetRTCAlarmComponent[0]
|-
| 0x00170040
| SetRTCAlarmComponent[1] (u8 val)
|-
| 0x00180000
| u8 GetRTCAlarmComponent[1]
|-
| 0x00190040
| SetRTCAlarmComponent[2] (u8 val)
|-
| 0x001A0000
| u8 GetRTCAlarmComponent[2]
|-
| 0x001B0040
| SetRTCAlarmComponent[3] (u8 val)
|-
| 0x001C0000
| u8 GetRTCAlarmComponent[3]
|-
| 0x001D0040
| SetRTCAlarmComponent[4] (u8 val)
|-
| 0x001E0000
| u8 GetRTCAlarmComponent[4]
|-
| 0x001F0040
| SetPedometerRecordingMode(u8 mode)
|-
| 0x00200000
| u8 GetPedometerRecordingMode
|-
| 0x00210080
| u8 GetStepCount (for the current day)
|-
| 0x00220042
| ReadRegister4Fh(u32 unused_size, translation_param size=0x156 << 4 <nowiki>|</nowiki> 0xC, u8[0x156] ptr)
|-
| 0x00230000
| void ??? writes 1 to register 0x4E which is not writable
|-
| 0x00240000
| Handle GetPowerEventHandle. MCU notifications 1, 8, 9, 10, 13, 14 and 15 signal this.
see [[I2C_Registers#Device_3|Register 0x18]]
|-
| 0x00250000
| u32 GetPowerInterruptHistory
|-
| 0x00260000
| bool CheckRegister02hBit0
|-
| 0x00270000
| void ClearRegister02hBit0 (does nothing since the register is not writable)
|-
| 0x00280000
| bool CheckRegister02hBit1
|-
| 0x00290000
| void ClearRegister02hBit1
|-
| 0x002A0000
| bool GetShellState. This writes the value of I2C-MCU register 0xf bit1 to u8 cmdreply[2].
|-
| 0x002B0000
| bool GetAdapterState. This writes the value of I2C-MCU register 0xf bit3 to u8 cmdreply[2].
|-
| 0x002C0000
| bool GetBatteryChargeState. This writes the value of I2C-MCU register 0xf bit4 to u8 cmdreply[2].
|-
| 0x002D0000
| [[MCURTC:GetBatteryLevel|GetBatteryLevel]]
|-
| 0x002E0000
| u8 Set......
|-
| 0x002F0000
| u8 GetBatteryEmptyPatternByte0_safe™
|-
| 0x00300040
| SetLEDBrightness(u8 brightness) (see [[I2C_Registers#Device_3|Register 0x28]])
|-
| 0x00310000
| u8 GetLEDBrightness (see [[I2C_Registers#Device_3|Register 0x28]])
|-
| 0x00320000
| void PowerOff (writes 0x1 to i2c MCU device, [[I2C_Registers#Device_3|reg 0x20]])
|-
| 0x00330000
| void HardwareReboot (writes 0x4 to i2c MCU device, [[I2C_Registers#Device_3|reg 0x20]])
|-
| 0x00340000
| WriteRegister reg=0x23 value=0x72 (writing to read-only registers does nothing)
|-
| 0x00350000
| Writes 0x10 to i2c MCU device, reg 0x20 (this bit of the register is not writable)
|-
| 0x00360040
| SetWatchdogTimer(u8 timer)
|-
| 0x00370000
| u8 GetWatchdogTimer
|-
| 0x00380042
| ReadI2CRegister7Fh(u32 unused_size, translation_param size << 4 <nowiki>|</nowiki> 0xC, u8[0x13] ptr)
|-
| 0x00390082
| WriteLoop (translation parameters too complex)
|-
| 0x003A0082
| ReadLoop (translation parameters too complex)
|-
| 0x003B0640
| [[MCURTC:SetInfoLEDPattern|SetInfoLEDPattern]]
|-
| 0x003C0040
| [[MCURTC:SetInfoLEDPatternHeader|SetInfoLEDPatternHeader]]
|-
| 0x003D0000
| [[MCURTC:GetInfoLEDStatus|GetInfoLEDStatus]]
|-
| 0x003E0040
| WriteRegister50h(u8 value)
|-
| 0x003F0000
| u8 ReadRegister50h
|-
| 0x00400040
| WriteRegister51h(u8 value)
|-
| 0x00410000
| u8 ReadRegister51h
|-
| 0x00420040
| [[MCURTC:SetBatteryEmptyLEDPattern|SetBatteryEmptyLEDPattern]]
|-
| 0x00430040
| SetScreenFlickerTop(u8 flicker)
|-
| 0x00440000
| u8 GetScreenFlickerTop
|-
| 0x00450040
| SetScreenFlickerBottom(u8 flicker)
|-
| 0x00460000
| u8 GetScreenFlickerBottom
|-
| 0x00470080
| SetVolumeSliderBounds(u8 low, u8 high) (see [[I2C_Registers#Device_3|Register 0x58]])
|-
| 0x00480000
| u8 low, u8 high GetVolumeSliderBounds
|-
| 0x00490040
| SetInterruptMask(u32 mask) (see [[I2C_Registers#Device_3|Register 0x18]])
|-
| 0x004A0000
| u32 GetInterruptMask (see [[I2C_Registers#Device_3|Register 0x18]])
|-
| 0x004B0000
| void ExitExclusiveInterruptMode
|-
| 0x004C0000
| void EnterExclusiveInterruptMode
|-
| 0x004D0000
| [[MCURTC:ReadInterrupt|ReadInterrupt]] (see [[I2C_Registers#Device_3|Register 0x10]])
|-
| 0x004E0040
| [[MCURTC:PublishNotifications|TriggerInterrupt]]
|-
| 0x004F0040
| SetMCUFirmUpdated(u32 flag) used by PTM module
|-
| 0x00500000
| u32 IsMCUFirmUpdated
|-
| 0x00510040
| [[MCURTC:SetSoftwareClosedFlag|SetSoftwareClosedFlag]]
|-
| 0x00520000
| [[MCURTC:GetSoftwareClosedFlag|GetSoftwareClosedFlag]]
|-
| 0x00530040
| ?
|-
| 0x00540000
| ?
|-
| 0x00550040
| ?
|-
| 0x00560000
| ?
|-
| 0x00570040
| ?
|-
| 0x00580000
| ?
|-
| 0x00590040
| [[MCURTC:SetLegacyJumpProhibitedFlag|SetLegacyJumpProhibitedFlag]]
|-
| 0x005A0000
| [[MCURTC:GetLegacyJumpProhibitedFlag|GetLegacyJumpProhibitedFlag]]
|-
| 0x005B0040
| SetUUIDClockSequence
|-
| 0x005C0000
| GetUUIDClockSequence
|-
|}

=MCU sound service "mcu::SND"=
{| class="wikitable" border="1"
|-
! Command Header
! Description
|-
| 0x00010080
| GetSoundVolume, writes volume slider value (0-63) to IPC+8
|-
| 0x00020040
| Set...
|-
| 0x00030000
| GetRegister25h, cmdbuf[2] is 0 on n3ds
|}

=MCU wifi service "mcu::NWM"=
{| class="wikitable" border="1"
|-
! Command Header
! Description
|-
| 0x0001....
| SetWirelessLedState
|-
| 0x0002....
| GetWirelessLedState
|-
| 0x0003....
| Sets GPIO 0x20 high/low?
|-
| 0x0004....
| Gets GPIO 0x20 high/low?
|-
| 0x0005....
| SetEnableWifiGpio
|-
| 0x0006....
| GetEnableWifiGpio
|-
| 0x0007....
| [[MCUNWM:SetWirelessDisabledFlag|SetWirelessDisabledFlag]]
|-
| 0x0008....
| [[MCUNWM:GetWirelessDisabledFlag|GetWirelessDisabledFlag]]
|}

=MCU service "mcu::HWC"=
{| class="wikitable" border="1"
|-
! Command Header
! Description
|-
| 0x00010082
| [[MCUHWC:ReadRegister|ReadRegister]]
|-
| 0x00020082
| [[MCUHWC:WriteRegister|WriteRegister]]
|-
| 0x00030042
| [[MCUHWC:GetInfoRegisters|GetInfoRegisters]]
|-
| 0x00040000
| [[MCUHWC:GetBatteryVoltage|GetBatteryVoltage]]
|-
| 0x00050000
| [[MCUHWC:GetBatteryLevel|GetBatteryLevel]]
|-
| 0x00060040
| [[MCUHWC:SetPowerLEDPattern|SetPowerLEDPattern]]
|-
| 0x00070040
| [[MCUHWC:SetWifiLEDState|SetWifiLEDState]]
|-
| 0x00080040
| [[MCUHWC:SetCameraLEDPattern|SetCameraLEDPattern]]
|-
| 0x00090040
| [[MCUHWC:Set3DLEDState|Set3DLEDState]]
|-
| 0x000A0640
| This is the same as [[MCURTC:SetInfoLEDPattern]].
|-
| 0x000B0000
| [[MCUHWC:GetSoundVolume|GetSoundVolume]]
|-
| 0x000C0040
| SetTopScreenFlicker
|-
| 0x000D0040
| SetBottomScreenFlicker
|-
| 0x000E0080
| ?
|-
| 0x000F00C0
| GetRtcTime
|-
| 0x00100000
| GetMcuFwVerHigh
|-
| 0x00110000
| GetMcuFwVerLow
|}

=MCU service "mcu::PLS"=

<s>Beg the sysmodule to return the datetime registers in decimal form instead of as a Binary Coded Decimal</s>

{| class="wikitable" border="1"
|-
! Command Header
! Description
|-
| 0x00010000
| GetDatetime (returns registers 0x30-0x36 in IPC+8)
|-
| 0x00020000
| [[MCUPLS:GetSeconds|GetSeconds]]
|-
| 0x00030000
| u8 GetMinutes
|-
| 0x00040000
| u8 GetHour
|-
| 0x00050000
| u8 GetDayOfWeek
|-
| 0x00060000
| u8 GetDay
|-
| 0x00070000
| u8 GetMonth
|-
| 0x00080000
| u8 GetYear
|-
| 0x00090000
| u16 GetTickCounter
|}

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

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

=MCU firmware versions=

These reside in mcu sysmodule .rodata, are uploaded to MCU register 0x05 and are usually 0x4003 bytes in size (the actual firmware is 0x4000 bytes preceeded by a 3 byte magic header "<code>jhl</code>" which switches the I2C comms into flash write mode).
Switching requires register 0x05 (at address <code>0xFFBA9</code>) to contain 0x6A ('<code>j</code>'), register 0x06 containing 0x68 ('<code>h</code>'), and writing 0x6C ('<code>l</code>') to register 0x07. The actual flashing sequence is only signaled (code at 0x3312-0x331A) when writing register 0x07, it's skipped otherwise. Register 0x07 gets written anyways, just the actual signaling is skipped if the conditions aren't met.

Before the upload could commence, external MCU interrupts are turned off via GPIO command 0x00020080(0, 0x40000), then after the upload completed, the sysmodule waits exactly one second for the MCU to reboot, then turns external MCU interrupts back on via <code>gpio:MCU</code> command 0x00020080(0x40000, 0x40000).

There exists an alternate code path in very old MCU_FIRM versions where uploading is done using register 0x3B (if register 0x0F is zero and 0x10 is 1). Register 0x3B is part of the RTC alarm registers on recent versions of MCU.

On dev-units, the user-facing representation of this firmware version is displayed by first subtracting 0x10 from the major field (raw register 0x00). It is these user-facing versions that are displayed in the table below. It is unknown what bit4 (0x10) actually represents, but it is seemingly always set.

{| class="wikitable" border="1"
|-
! Title version
! Firmware
|-
| New3DS v9216 (New2DSXL)
| 3.65
|-
| New3DS v8192/safe v9217 (latest)
| 3.56
|-
| Old3DS v6145 to v8192 (latest)
| 2.37
|-
| Old3DS v5122
| 2.35
|-
| Old3DS v4102
| 2.30
|-
| Old3DS v3072
| 2.16
|-
| Old3DS v2048
| 1.52
|-
| Old3DS v1026
| 1.51
|-
| Old3DS v0/safe v0
| 1.20
|-
| Old3DS factory
| 1.07
|}

MCU Services

2019-10-08T03:10:56Z

Unknown: /* MCU service "mcu::RTC" */

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

=MCU camera service "mcu::CAM"=
{| class="wikitable" border="1"
|-
! Command Header
! Description
|-
| 0x00010040
| WriteCameraLedState (writes i2c register 0x2B)
|-
| 0x00020080
| ReadCameraLedState (reads i2c register 0x2B)
|}

=MCU GPU service "mcu::GPU"=
{| class="wikitable" border="1"
|-
! Command Header
! Description
|-
| 0x00010000
| GetLcdPowerState. This writes the value of I2C-MCU register 0xf bit6 to u8 cmdreply[2], and the value of bit5 from that register to u8 cmdreply[3].
|-
| 0x00020080
| SetLcdPowerState. This writes the upper LCD bits of MCU register 0x22.
|-
| 0x00030000
| GetGpuLcdInterfaceState. This writes the value of I2C-MCU register 0xf bit7 to u8 cmdreply[2].
|-
| 0x00040040
| SetGpuLcdInterfaceState. This writes the lower two bits of MCU register 0x22.
|-
| 0x00050040
| SetTopScreenFlicker
|-
| 0x00060080
| GetTopScreenFlicker
|-
| 0x00070040
| SetBottomScreenFlicker
|-
| 0x00080080
| GetBottomScreenFlicker
|-
| 0x00090000
| GetMcuFwVerHigh. Called by GSP module
|-
| 0x000A0000
| GetMcuFwVerLow. Called by GSP module
|-
| 0x000B0040
| Set3dLedState
|-
| 0x000C0000
| Get3dLedState
|-
| 0x000D0000
| GetMcuGpuEventHandle. Event handle written to TLS+0x8c. MCU notifications 24 to 29 signal this.
|-
| 0x000E0000
| GetMcuGpuEventReason. Writes some value to TLS+0x88. Called by GSP module
|}

=MCU HID service "mcu::HID"=
{| class="wikitable" border="1"
|-
! Command Header
! Description
|-
| 0x00010040
| ?
|-
| 0x00020000
| ??? test register 0x40 bit0, and writes result to IPC+8
|-
| 0x00030040
| ??? writes IPC+4 to register 0x41
|-
| 0x00040000
| ??? reads register 0x44 to IPC+8
|-
| 0x00050080
| ??? writes IPC+4 to register 0x43 and IPC+8 to register 0x44
|-
| 0x00060000
| ReadGyroscopeValues (reads 3x s16 gyro ADC values into IPC+8)
|-
| 0x00070000
| GetRaw3DSliderPosition (u8 position in IPC+8)
|-
| 0x00080040
| ?
|-
| 0x00090000
| ?
|-
| 0x000A0040
| ?
|-
| 0x000B0000
| ?
|-
| 0x000C0000
| GetMcuHidEventHandle. MCU notifications 11 and 12 signal this. Handle is written to IPC+12
|-
| 0x000D0000
| GetMcuHidEventReason. This reads an internal flield into IPC+8 and clears it.
|-
| 0x000E0000
| [[MCUHID:GetSoundVolume|GetSoundVolume]]
|-
| 0x000F0040
| EnableAccelerometerInterrupt(int enable). 1 = enable, 0 = disable accelerometer
|}

While before these functions are handled, the MCU interrupt with bitmask 0x800 is enabled, then after the commands were handled the MCU interrupt bits 0x1800 get cleared.

=MCU service "mcu::RTC"=
{| class="wikitable" border="1"
|-
! Command Header
! Description
|-
| 0x00010080
| [[MCURTC:SetRTC|SetRTC]]
|-
| 0x00020000
| [[MCURTC:GetRTC|GetRTC]]
|-
| 0x00030040
| SetRTCSeconds(u8 seconds)
|-
| 0x00040000
| u8 GetRTCSeconds
|-
| 0x00050040
| SetRTCMinutes(u8 minutes)
|-
| 0x00060000
| u8 GetRTCMinutes
|-
| 0x00070040
| SetRTCHours(u8 hours)
|-
| 0x00080000
| u8 GetRTCHours
|-
| 0x00090040
| SetRTCDayOfWeek(u8 dayno)
|-
| 0x000A0000
| u8 GetRTCDayOfWeek
|-
| 0x000B0040
| SetRTCDayOfMonth(u8 day)
|-
| 0x000C0000
| u8 GetRTCDayOfMonth
|-
| 0x000D0040
| SetRTCMonth(u8 month)
|-
| 0x000E0000
| u8 GetRTCMonth
|-
| 0x000F0040
| SetRTCYear(u8 year) where year = year - 2000
|-
| 0x00100000
| u8 GetRTCYear where year = result + 2000
|-
| 0x00110040
| SetRTCLeapYearCounter(u8 leap)
|-
| 0x00120000
| u8 GetRTCLeapYearCounter
|-
| 0x00130080
| [[MCURTC:SetRTCAlarm|SetRTCAlarm]]
|-
| 0x00140000
| [[MCURTC:GetRTCAlarm|GetRTCAlarm]]
|-
| 0x00150040
| SetRTCAlarmComponent[0] (u8 val)
|-
| 0x00160000
| u8 GetRTCAlarmComponent[0]
|-
| 0x00170040
| SetRTCAlarmComponent[1] (u8 val)
|-
| 0x00180000
| u8 GetRTCAlarmComponent[1]
|-
| 0x00190040
| SetRTCAlarmComponent[2] (u8 val)
|-
| 0x001A0000
| u8 GetRTCAlarmComponent[2]
|-
| 0x001B0040
| SetRTCAlarmComponent[3] (u8 val)
|-
| 0x001C0000
| u8 GetRTCAlarmComponent[3]
|-
| 0x001D0040
| SetRTCAlarmComponent[4] (u8 val)
|-
| 0x001E0000
| u8 GetRTCAlarmComponent[4]
|-
| 0x001F0040
| SetPedometerRecordingMode(u8 mode)
|-
| 0x00200000
| u8 GetPedometerRecordingMode
|-
| 0x00210080
| u8 GetStepCount (for the current day)
|-
| 0x00220042
| ReadRegister4Fh(u32 unused_size, translation_param size=0x156 << 4 <nowiki>|</nowiki> 0xC, u8[0x156] ptr)
|-
| 0x00230000
| void ??? writes 1 to register 0x4E which is not writable
|-
| 0x00240000
| Handle GetPowerEventHandle. MCU notifications 1, 8, 9, 10, 13, 14 and 15 signal this.
see [[I2C_Registers#Device_3|Register 0x18]]
|-
| 0x00250000
| u32 GetPowerInterruptHistory
|-
| 0x00260000
| bool CheckRegister02hBit0
|-
| 0x00270000
| void ClearRegister02hBit0 (does nothing since the register is not writable)
|-
| 0x00280000
| bool CheckRegister02hBit1
|-
| 0x00290000
| void ClearRegister02hBit1
|-
| 0x002A0000
| bool GetShellState. This writes the value of I2C-MCU register 0xf bit1 to u8 cmdreply[2].
|-
| 0x002B0000
| bool GetAdapterState. This writes the value of I2C-MCU register 0xf bit3 to u8 cmdreply[2].
|-
| 0x002C0000
| bool GetBatteryChargeState. This writes the value of I2C-MCU register 0xf bit4 to u8 cmdreply[2].
|-
| 0x002D0000
| [[MCURTC:GetBatteryLevel|GetBatteryLevel]]
|-
| 0x002E0000
| u8 Set......
|-
| 0x002F0000
| u8 GetBatteryEmptyPatternByte0_safe™
|-
| 0x00300040
| SetLEDBrightness(u8 brightness) (see [[I2C_Registers#Device_3|Register 0x28]])
|-
| 0x00310000
| u8 GetLEDBrightness (see [[I2C_Registers#Device_3|Register 0x28]])
|-
| 0x00320000
| void PowerOff (writes 0x1 to i2c MCU device, [[I2C_Registers#Device_3|reg 0x20]])
|-
| 0x00330000
| void HardwareReboot (writes 0x4 to i2c MCU device, [[I2C_Registers#Device_3|reg 0x20]])
|-
| 0x00340000
| WriteRegister reg=0x23 value=0x72 (writing to read-only registers does nothing)
|-
| 0x00350000
| Writes 0x10 to i2c MCU device, reg 0x20 (this bit of the register is not writable)
|-
| 0x00360040
| SetWatchdogTimer(u8 timer)
|-
| 0x00370000
| u8 GetWatchdogTimer
|-
| 0x00380042
| ReadI2CRegister0x7F(u32 unused_size, translation_param size << 4 <nowiki>|</nowiki> 0xC, u8[0x13] ptr)
|-
| 0x00390082
| WriteLoop (translation parameters too complex)
|-
| 0x003A0082
| ReadLoop (translation parameters too complex)
|-
| 0x003B0640
| [[MCURTC:SetInfoLEDPattern|SetInfoLEDPattern]]
|-
| 0x003C0040
| [[MCURTC:SetInfoLEDPatternHeader|SetInfoLEDPatternHeader]]
|-
| 0x003D0000
| [[MCURTC:GetInfoLEDStatus|GetInfoLEDStatus]]
|-
| 0x003E0040
| WriteRegister50h(u8 value)
|-
| 0x003F0000
| u8 ReadRegister50h
|-
| 0x00400040
| WriteRegister51h(u8 value)
|-
| 0x00410000
| u8 ReadRegister51h
|-
| 0x00420040
| [[MCURTC:SetBatteryEmptyLEDPattern|SetBatteryEmptyLEDPattern]]
|-
| 0x00430040
| SetScreenFlickerTop(u8 flicker)
|-
| 0x00440000
| u8 GetScreenFlickerTop
|-
| 0x00450040
| SetScreenFlickerBottom(u8 flicker)
|-
| 0x00460000
| u8 GetScreenFlickerBottom
|-
| 0x00470080
| SetVolumeSliderBounds(u8 low, u8 high) (see [[I2C_Registers#Device_3|Register 0x58]])
|-
| 0x00480000
| u8 low, u8 high GetVolumeSliderBounds
|-
| 0x00490040
| SetInterruptMask(u32 mask) (see [[I2C_Registers#Device_3|Register 0x18]])
|-
| 0x004A0000
| u32 GetInterruptMask (see [[I2C_Registers#Device_3|Register 0x18]])
|-
| 0x004B0000
| void ExitExclusiveInterruptMode
|-
| 0x004C0000
| void EnterExclusiveInterruptMode
|-
| 0x004D0000
| [[MCURTC:ReadInterrupt|ReadInterrupt]] (see [[I2C_Registers#Device_3|Register 0x10]])
|-
| 0x004E0040
| [[MCURTC:PublishNotifications|TriggerInterrupt]]
|-
| 0x004F0040
| SetMCUFirmUpdated(u32 flag) used by PTM module
|-
| 0x00500000
| u32 IsMCUFirmUpdated
|-
| 0x00510040
| [[MCURTC:SetSoftwareClosedFlag|SetSoftwareClosedFlag]]
|-
| 0x00520000
| [[MCURTC:GetSoftwareClosedFlag|GetSoftwareClosedFlag]]
|-
| 0x00530040
| ?
|-
| 0x00540000
| ?
|-
| 0x00550040
| ?
|-
| 0x00560000
| ?
|-
| 0x00570040
| ?
|-
| 0x00580000
| ?
|-
| 0x00590040
| [[MCURTC:SetLegacyJumpProhibitedFlag|SetLegacyJumpProhibitedFlag]]
|-
| 0x005A0000
| [[MCURTC:GetLegacyJumpProhibitedFlag|GetLegacyJumpProhibitedFlag]]
|-
| 0x005B0040
| SetUUIDClockSequence
|-
| 0x005C0000
| GetUUIDClockSequence
|-
|}

=MCU sound service "mcu::SND"=
{| class="wikitable" border="1"
|-
! Command Header
! Description
|-
| 0x00010080
| GetSoundVolume, writes volume slider value (0-63) to IPC+8
|-
| 0x00020040
| Set...
|-
| 0x00030000
| GetRegister25h, cmdbuf[2] is 0 on n3ds
|}

=MCU wifi service "mcu::NWM"=
{| class="wikitable" border="1"
|-
! Command Header
! Description
|-
| 0x0001....
| SetWirelessLedState
|-
| 0x0002....
| GetWirelessLedState
|-
| 0x0003....
| Sets GPIO 0x20 high/low?
|-
| 0x0004....
| Gets GPIO 0x20 high/low?
|-
| 0x0005....
| SetEnableWifiGpio
|-
| 0x0006....
| GetEnableWifiGpio
|-
| 0x0007....
| [[MCUNWM:SetWirelessDisabledFlag|SetWirelessDisabledFlag]]
|-
| 0x0008....
| [[MCUNWM:GetWirelessDisabledFlag|GetWirelessDisabledFlag]]
|}

=MCU service "mcu::HWC"=
{| class="wikitable" border="1"
|-
! Command Header
! Description
|-
| 0x00010082
| [[MCUHWC:ReadRegister|ReadRegister]]
|-
| 0x00020082
| [[MCUHWC:WriteRegister|WriteRegister]]
|-
| 0x00030042
| [[MCUHWC:GetInfoRegisters|GetInfoRegisters]]
|-
| 0x00040000
| [[MCUHWC:GetBatteryVoltage|GetBatteryVoltage]]
|-
| 0x00050000
| [[MCUHWC:GetBatteryLevel|GetBatteryLevel]]
|-
| 0x00060040
| [[MCUHWC:SetPowerLEDPattern|SetPowerLEDPattern]]
|-
| 0x00070040
| [[MCUHWC:SetWifiLEDState|SetWifiLEDState]]
|-
| 0x00080040
| [[MCUHWC:SetCameraLEDPattern|SetCameraLEDPattern]]
|-
| 0x00090040
| [[MCUHWC:Set3DLEDState|Set3DLEDState]]
|-
| 0x000A0640
| This is the same as [[MCURTC:SetInfoLEDPattern]].
|-
| 0x000B0000
| [[MCUHWC:GetSoundVolume|GetSoundVolume]]
|-
| 0x000C0040
| SetTopScreenFlicker
|-
| 0x000D0040
| SetBottomScreenFlicker
|-
| 0x000E0080
| ?
|-
| 0x000F00C0
| GetRtcTime
|-
| 0x00100000
| GetMcuFwVerHigh
|-
| 0x00110000
| GetMcuFwVerLow
|}

=MCU service "mcu::PLS"=

<s>Beg the sysmodule to return the datetime registers in decimal form instead of as a Binary Coded Decimal</s>

{| class="wikitable" border="1"
|-
! Command Header
! Description
|-
| 0x00010000
| GetDatetime (returns registers 0x30-0x36 in IPC+8)
|-
| 0x00020000
| [[MCUPLS:GetSeconds|GetSeconds]]
|-
| 0x00030000
| u8 GetMinutes
|-
| 0x00040000
| u8 GetHour
|-
| 0x00050000
| u8 GetDayOfWeek
|-
| 0x00060000
| u8 GetDay
|-
| 0x00070000
| u8 GetMonth
|-
| 0x00080000
| u8 GetYear
|-
| 0x00090000
| u16 GetTickCounter
|}

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

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

=MCU firmware versions=

These reside in mcu sysmodule .rodata, are uploaded to MCU register 0x05 and are usually 0x4003 bytes in size (the actual firmware is 0x4000 bytes preceeded by a 3 byte magic header "<code>jhl</code>" which switches the I2C comms into flash write mode).
Switching requires register 0x05 (at address <code>0xFFBA9</code>) to contain 0x6A ('<code>j</code>'), register 0x06 containing 0x68 ('<code>h</code>'), and writing 0x6C ('<code>l</code>') to register 0x07. The actual flashing sequence is only signaled (code at 0x3312-0x331A) when writing register 0x07, it's skipped otherwise. Register 0x07 gets written anyways, just the actual signaling is skipped if the conditions aren't met.

Before the upload could commence, external MCU interrupts are turned off via GPIO command 0x00020080(0, 0x40000), then after the upload completed, the sysmodule waits exactly one second for the MCU to reboot, then turns external MCU interrupts back on via <code>gpio:MCU</code> command 0x00020080(0x40000, 0x40000).

There exists an alternate code path in very old MCU_FIRM versions where uploading is done using register 0x3B (if register 0x0F is zero and 0x10 is 1). Register 0x3B is part of the RTC alarm registers on recent versions of MCU.

On dev-units, the user-facing representation of this firmware version is displayed by first subtracting 0x10 from the major field (raw register 0x00). It is these user-facing versions that are displayed in the table below. It is unknown what bit4 (0x10) actually represents, but it is seemingly always set.

{| class="wikitable" border="1"
|-
! Title version
! Firmware
|-
| New3DS v9216 (New2DSXL)
| 3.65
|-
| New3DS v8192/safe v9217 (latest)
| 3.56
|-
| Old3DS v6145 to v8192 (latest)
| 2.37
|-
| Old3DS v5122
| 2.35
|-
| Old3DS v4102
| 2.30
|-
| Old3DS v3072
| 2.16
|-
| Old3DS v2048
| 1.52
|-
| Old3DS v1026
| 1.51
|-
| Old3DS v0/safe v0
| 1.20
|-
| Old3DS factory
| 1.07
|}

Config Savegame

2019-10-07T17:48:21Z

Unknown: /* Configuration blocks */

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

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

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

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

==Configuration blocks==
{| class="wikitable" border="1"
|-
! BlkID
! Size
! Flags
! Description
|-
| 0x00000000
| 0x2
| 0xC
| Config savegame version?
|-
| 0x00010000
| 0x1
| 0xC
| [[Hardware_calibration#RTC|RTC compensation value]]
|-
| 0x00020000
| 0x134
| 0xC
| [[Hardware_calibration#CDC|Codec]]
|-
| 0x00030000
| 0x1
| 0xC
| Leap Year Counter (read By PTM)
|-
| 0x00030001
| 0x8
| 0xE
| User time offset (read by CECD)
|-
| 0x00030002
| 0x8
| 0xC
| ?
|-
| 0x00040000
| 0x10
| 0xC
| [[Hardware_calibration#Touch|Touch calibration]] (read by HID)
|-
| 0x00040001
| 0x1C
| 0xC
| Analog Stick Calibration Param?(read by HID)
|-
| 0x00040002
| 0x12
| 0xC
| [[Hardware_calibration#Gyro|Gyroscope]] (read by HID)
|-
| 0x00040003
| 0xC
| 0xC
| [[Hardware_calibration#Accel|Accelerometer]] (read by HID)
|-
| 0x00040004
| 0x1C
| 0xC
| [[Hardware_calibration#CStick|CStick calibration data]]
|-
| 0x00050000
| 0x2
| 0xC
| [[Hardware_calibration#Screen_flicker|Screen flicker]]
|-
| 0x00050001
| 0x2
| 0xC
| Backlight controls (u8 ABL_powersave_enable, u8 brightness_level) (read by GSP)
|-
| 0x00050002
| 0x38
| 0xC
| [[Hardware_calibration#BLPWM|Backlight PWM]] (read by GSP)
|-
| 0x00050003
| 0x20
| 0xC
| [[Hardware_calibration#ABL|Power saving mode (ABL) calibration]] (read by GSP)
|-
| 0x00050004
| 0x20
| 0xC
| [[Hardware_calibration#ABL|Power saving mode (ABL) calibration]]
|-
| 0x00050005
| 0x20
| 0xE
| Stereo display settings (HWCAL block 0x470)
|-
| 0x00050006
| 0x2
| 0xC
| [[Hardware_calibration#ULCD_delay|3D switching delay]]
|-
| 0x00050007
| 0x4
| 0xC
| ?
|-
| 0x00050008
| 0x10C
| 0xC
| [[Hardware_calibration#ABL_extra|Power saving mode (ABL) extra config]]
|-
| 0x00050009
| 0x8
| 0xC
| new3DS only(?) backlight control (5th byte: auto-brightness enable)
|-
| 0x00060000
| 0x96
| 0xC
| ??? (HWCAL block 0x500)
|-
| 0x00070000
| 0x214
| 0xE
| [[Hardware_calibration#3D_filters|3D filters]]
|-
| 0x00070001
| 0x1
| 0xE
| Sound output mode (mono=0, stereo=1, surround=2)
|-
| 0x00070002
| 0x8
| 0xE
| [[Hardware_calibration#Microphone_echo_cancel|Microphone echo cancellation params]]
|-
| 0x00080000
| 0xC00
| 0xC
| WiFi configuration slot 0
|-
| 0x00080001
| 0xC00
| 0xC
| WiFi configuration slot 1
|-
| 0x00080002
| 0xC00
| 0xC
| WiFi configuration slot 2
|-
| 0x00090000
| 0x8
| 0xE
| This contains a u64 ID, used by processes using [[NWMUDS:InitializeWithVersion]]. The first word is the same as [[CfgS:GetLocalFriendCodeSeed|LocalFriendCodeSeed]], while the latter is a separate word.
|-
| 0x00090001
| 0x8
| 0xE
| Same content as 0x0009000? This console-unique u64 is used by [[Cfg:GenHashConsoleUnique|GenHashConsoleUnique]]. It is generated by <code>((0x3FFFFFFFF) & LocalFriendCodeSeed) | (random16 << 48))</code>, where random16 is generated by [[PSPXI:GenerateRandomBytes|GenerateRandomBytes]]
|-
| 0x00090002
| 0x4
| 0xE
| The first two bytes are the same random16 used in 0x00090001. The second two bytes are zeros.
|-
| 0x000A0000
| 0x1C
| 0xE
| Username in UTF16
|-
| 0x000A0001
| 0x2
| 0xE
| Birthday (u8 month, u8 day)
|-
| 0x000A0002
| 0x1
| 0xE
| Language
|-
| 0x000B0000
| 0x4
| 0xE
| CountryInfo
|-
| 0x000B0001
| 0x800
| 0xE
| Country name in UTF-16, every 0x80-bytes is an entry for each language, in the order of the Language table below (not all entries are set)
|-
| 0x000B0002
| 0x800
| 0xE
| State name in UTF-16, every 0x80-bytes is an entry for each language
|-
| 0x000B0003
| 0x4
| 0xE
| Coordinates. A pair of s16 represents latitude and longitude, respectively. One need to multiply both value by 180/32768 to get coordinates in degrees

|-
| 0x000C0000
| 0xC0
| 0xE
| Restricted photo exchange data, and other info (includes a mirror of Parental Restrictions PIN/Secret Answer)
|-
| 0x000C0001
| 0x14
| 0xE
| COPPACS restriction data
|-
| 0x000C0002
| 0x200
| 0xE
| ? Contains the email address set during Parental Restriction setup.
|-
| 0x000D0000
| 0x4
| 0xE
| u16 at offset 0x0: [[SMDH#EULA_Version|EULA Version]] which was agreed to.
|-
| 0x000E0000
| 0x1
| 0xE
| ?
|-
| 0x000F0000
| 0x10
| 0xC
| Debug configuration, read by [[NS]] on dev-units: on startup, NS does <code>svcKernelSetState(6, 1, (u64)debug_flags & 1);
svcKernelSetState(6, 2, (u64)debug_flags & 2);</code> (see [[SVC#KernelSetState|here]]) where <code>debug_flags</code> is the u32 located at offset 0xC in this struct. Then it compares the u32 from +8 in this config-block with the [[Configuration_Memory#APPMEMTYPE|APPMEMTYPE]]. When those don't match NS starts a FIRM-launch (with the same FIRM titleID as the currently running one) to boot into a FIRM with the APPMEMTYPE value from this config-block. The byte at offset 0x0 is related to the memtype as well.
|-
| 0x000F0001
| 0x8
| 0xC
| ?
|-
| 0x000F0003
| 0x1
| 0xC
| ?
|-
| 0x000F0004
| 0x4
| 0xC
| The first u8 is the System-Model [[Cfg:GetSystemModel|value]], the last 3-bytes are unknown
|-
| 0x000F0005
| 0x4
| 0xC
| The first u8 indicates whether network updates are enabled (however, NIM only checks this flag with developer [[Configuration_Memory#ENVINFO|ENVINFO]]).
|-
| 0x000F0006
| 0x28
| 0xC
| ?
|-
| 0x00100000
| 0x2
| 0xC
| ?
|-
| 0x00100001
| 0x94
| 0xC
| Stores Parental Restrictions PIN/Secret Answer and other info
|-
| 0x00100002
| 0x1
| 0xC
| ?
|-
| 0x00100003
| 0x10
| 0xC
| ?
|-
| 0x00110000
| 0x4
| 0xC
| The low u16 indicates whether the system setup is required, such as when the system is booted for the first time or after doing a [[System Settings|System Format]]: 0 = setup required, non-zero = no setup required
|-
| 0x00110001
| 0x8
| 0xC
| TitleID of the menu to launch, used by [[NS]] on dev units (this block can be edited on dev units with [[3DS Development Unit Software#Config|Config]])
|-
| 0x00120000
| 0x8
| 0xC
| Volume Slider Bounds (Read by HID and PTM)
|-
| 0x00130000
| 0x4
| 0xE
| If response is 0x100 then debug mode is enabled.
|-
| 0x00150000
| 0x4
| 0xC
| ?
|-
| 0x00150001
| 0x8
| 0xC
| ?
|-
| 0x00150002
| 0x4
| 0xE
| ?
|-
| 0x00160000
| 0x4
| 0xE
| Unknown, first byte is used by config service-cmd [[Config_Services|0x00070040]]. (Unknown whether the last 3-bytes are used)
|-
| 0x00170000
| 0x4
| 0xE
| Miiverse (OLV) access key
|-
| 0x00180000
| 0x4
| 0xC
| QTM Infrared LED related, can be 0 or 1
|-
| 0x00180001
| 0x18
| 0xC
| [[Hardware_calibration#QTM|QTM calibration data]]
|-
| 0x00190000
| 0x1
| 0xC
| Unknown. NFC-module checks for value1/non-value1.
|}

The developer unit TID block only exists on developer units.

===Stereo Display Settings===
All values are hard-coded in cfg module.
{| class="wikitable" border="1"
|-
! Offset
! Size
! Value
! Description
|-
| 0x0
| 4
| 62.0f
|assumed pupillary distance in mm?
|-
| 0x4
| 4
| 289.0f
|assumed distance in mm between player's eyes and upper screen?
|-
| 0x8
| 4
| 76.80f
|width in mm of (old) 3DS upper screen (doesn't vary for different models?)
|-
| 0xC
| 4
| 46.08f
|height in mm of (old) 3DS upper screen (doesn't vary for different models?)
|-
| 0x10
| 4
| 10.0f
|
|-
| 0x14
| 4
| 5.0f
|
|-
| 0x18
| 4
| 55.58f
|
|-
| 0x1C
| 4
| 21.57f
|
|}

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

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

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

===WiFi Slot Structure===

====Network structure====
This is used twice in the actual WiFi slot structure.
{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
|-
| 0x0
| 0x1
| Whether the network was set or not?
|-
| 0x1
| 0x1
| Whether to use this network strucutre to connect?
|-
| 0x2
| 0x1
| Whether this structure is the first (0) or the second (1) in the larger WiFi slot structure?
|-
| 0x3
| 0x1
| Padding ?
|-
| 0x4
| 0x20
| SSID of the network, without a trailing nullbyte.
|-
| 0x24
| 0x1
| Length of the SSID.
|-
| 0x25
| 0x1
| [[Nintendo_Zone#Beacon_payload_format|AP crypto key type]]
|-
| 0x26
| 0x2
| Padding ?
|-
| 0x28
| 0x40
| Plaintext of the passphrase of the network, without a trailing nullbyte.
|-
| 0x68
| 0x20
| PBKDF2 of the passphrase and SSID (http://jorisvr.nl/wpapsk.html).
|-
|}

====Actual structure====
{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
|-
| 0x0
| 0x2
| ?
|-
| 0x2
| 0x2
| [https://github.com/lammertb/libcrc/blob/v2.0/src/crc16.c#L43-L76 CRC-16 checksum] of the next 0x410 bytes.
|-
| 0x4
| 0x88
| First network structure. Only set if the network was set "normally", or was the last to be set using WPS during the session.
|-
| 0x8C
| 0x20
| Padding.
|-
| 0xAC
| 0x88
| Second network structure. Only set if the network was set using WPS, otherwise 0-filled.
|-
| 0x134
| 0x20C
| Padding.
|-
| 0x340
| 0x1
| Whether to automatically get the IP address (use DHCP) or not, defaults to 1.
|-
| 0x341
| 0x1
| Whether to automatically get the DNS or not, defaults to 1.
|-
| 0x342
| 0x2
| Padding ?
|-
| 0x344
| 0x4
| IP address, to use if 0x340 is false.
|-
| 0x348
| 0x4
| IP address of the gateway, to use if 0x340 is false.
|-
| 0x34C
| 0x4
| Subnetwork mask, to use if 0x340 is false.
|-
| 0x350
| 0x4
| IP address of the primary DNS , to use if 0x341 is false.
|-
| 0x354
| 0x4
| IP address of the secondary DNS, to use if 0x341 is false.
|-
| 0x358
| 0x4
| Always 0x01050000 ? Only set if the network was the last to be set during the session.
|-
| 0x35C
| 0x4
| IP address to use. Only set if the network was the last to be set during the session.
|-
| 0x360
| 0x6
| MAC address of the AP. Only set if the network was the last to be set during the session.
|-
| 0x366
| 0x1
| Channel. Only set if the network was the last to be set during the session.
|-
| 0x367
| 0x1
| Padding ? Only set if the network was the last to be set during the session.
|-
| 0x368
| 0x1
| Whether to use a proxy or not, defaults to 0.
|-
| 0x369
| 0x1
| Whether to use a basic authentication for the proxy, defaults to 0.
|-
| 0x36A
| 0x2
| Port to use for the proxy, defaults to 1.
|-
| 0x36C
| 0x30
| URL/address of the proxy, including a trailing nullbyte.
|-
| 0x39C
| 0x34
| Padding.
|-
| 0x3D0
| 0x20
| Username to use for basic authentication, including a trailing nullbyte.
|-
| 0x3F0
| 0x20
| Password to use for basic authentication, including a trailing nullbyte.
|-
| 0x410
| 0x2
| Padding ?
|-
| 0x412
| 0x2
| MTU value, defaults to 1400 and ranges between 576 and 1500, inclusive.
|-
| 0x414
| 0x7EC
| Padding.
|-
|}

===LCD display config===
There seems to be some sort of LCD display configuration stored in this cfg. When using the cfg-save from an Old3DS on a New3DS without formatting the cfg first, the bottom-screen display is somewhat off(which is fixed by formatting the cfg-save).

===Parental control Block 0x00100001===
{| class="wikitable" border="1"
|-
! Byte
! Size in bytes
! Description
|-
| 0x0
| 0xD
| Unknown.
|-
| 0xD
| 0x4
| PIN
|-
| 0x11
| 0x20
| Secret answer in UTF-16
|}

===Parental Control setting block 0xC0000===
{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
|-
| 0x00
| 0x04
| [[#Parental Control restriction bitmask|Parental Control restriction bitmask]]
|-
| 0x0C
| 0x04
| Parental Controls PIN code
|}

====Parental Control restriction bitmask====
{| class="wikitable" border="1"
|-
! Bit
! Restriction name
|-
| 0
| Global Parental Controls enable
|-
| 3
| Sharing Images/Audio/Video/Long Text Data
|-
| 4
| Internet Browser
|-
| 5
| StreetPass
|-
| 6
| Friend Registration
|-
| 8
| eShop
|-
| 10
| Miiverse (view)
|-
| 11
| Miiverse (post)
|-
| 31
| "Child Online Privacy Protection" (see [[Cfg:GetRegionCanadaUSA|CFG:IsCoppacsSupported]])
|}

Config Savegame

2019-10-07T17:42:06Z

Unknown: /* Configuration blocks */ 0x30000 is Leap Year Counter

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

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

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

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

==Configuration blocks==
{| class="wikitable" border="1"
|-
! BlkID
! Size
! Flags
! Description
|-
| 0x00000000
| 0x2
| 0xC
| Config savegame version?
|-
| 0x00010000
| 0x1
| 0xC
| [[Hardware_calibration#RTC|RTC compensation value]]
|-
| 0x00020000
| 0x134
| 0xC
| [[Hardware_calibration#CDC|Codec]]
|-
| 0x00030000
| 0x1
| 0xC
| Leap Year Counter (read By PTM)
|-
| 0x00030001
| 0x8
| 0xE
| User time offset (read by CECD)
|-
| 0x00030002
| 0x8
| 0xC
| ?
|-
| 0x00040000
| 0x10
| 0xC
| [[Hardware_calibration#Touch|Touch calibration]] (read by HID)
|-
| 0x00040001
| 0x1C
| 0xC
| Analog Stick Calibration Param?(read by HID)
|-
| 0x00040002
| 0x12
| 0xC
| [[Hardware_calibration#Gyro|Gyroscope]] (read by HID)
|-
| 0x00040003
| 0xC
| 0xC
| [[Hardware_calibration#Accel|Accelerometer]] (read by HID)
|-
| 0x00040004
| 0x1C
| 0xC
| [[Hardware_calibration#CStick|CStick calibration data]]
|-
| 0x00050000
| 0x2
| 0xC
| [[Hardware_calibration#Screen_flicker|Screen flicker]]
|-
| 0x00050001
| 0x2
| 0xC
| Backlight controls (u8 ABL_powersave_enable, u8 brightness_level) (read by GSP)
|-
| 0x00050002
| 0x38
| 0xC
| [[Hardware_calibration#BLPWM|Backlight PWM]] (read by GSP)
|-
| 0x00050003
| 0x20
| 0xC
| [[Hardware_calibration#ABL|Power saving mode (ABL) calibration]] (read by GSP)
|-
| 0x00050004
| 0x20
| 0xC
| [[Hardware_calibration#ABL|Power saving mode (ABL) calibration]]
|-
| 0x00050005
| 0x20
| 0xE
| Stereo display settings (HWCAL block 0x470)
|-
| 0x00050006
| 0x2
| 0xC
| [[Hardware_calibration#ULCD_delay|3D switching delay]]
|-
| 0x00050007
| 0x4
| 0xC
| ?
|-
| 0x00050008
| 0x10C
| 0xC
| [[Hardware_calibration#ABL_extra|Power saving mode (ABL) extra config]]
|-
| 0x00050009
| 0x8
| 0xC
| new3DS only(?) backlight control (5th byte: auto-brightness enable)
|-
| 0x00060000
| 0x96
| 0xC
| ??? (HWCAL block 0x500)
|-
| 0x00070000
| 0x214
| 0xE
| [[Hardware_calibration#3D_filters|3D filters]]
|-
| 0x00070001
| 0x1
| 0xE
| Sound output mode (mono=0, stereo=1, surround=2)
|-
| 0x00070002
| 0x8
| 0xE
| [[Hardware_calibration#Microphone_echo_cancel|Microphone echo cancellation params]]
|-
| 0x00080000
| 0xC00
| 0xC
| WiFi configuration slot 0
|-
| 0x00080001
| 0xC00
| 0xC
| WiFi configuration slot 1
|-
| 0x00080002
| 0xC00
| 0xC
| WiFi configuration slot 2
|-
| 0x00090000
| 0x8
| 0xE
| This contains a u64 ID, used by processes using [[NWMUDS:InitializeWithVersion]]. The first word is the same as [[CfgS:GetLocalFriendCodeSeed|LocalFriendCodeSeed]], while the latter is a separate word.
|-
| 0x00090001
| 0x8
| 0xE
| Same content as 0x0009000? This console-unique u64 is used by [[Cfg:GenHashConsoleUnique|GenHashConsoleUnique]]. It is generated by <code>((0x3FFFFFFFF) & LocalFriendCodeSeed) | (random16 << 48))</code>, where random16 is generated by [[PSPXI:GenerateRandomBytes|GenerateRandomBytes]]
|-
| 0x00090002
| 0x4
| 0xE
| The first two bytes are the same random16 used in 0x00090001. The second two bytes are zeros.
|-
| 0x000A0000
| 0x1C
| 0xE
| Username in UTF16
|-
| 0x000A0001
| 0x2
| 0xE
| Birthday (u8 month, u8 day)
|-
| 0x000A0002
| 0x1
| 0xE
| Language
|-
| 0x000B0000
| 0x4
| 0xE
| CountryInfo
|-
| 0x000B0001
| 0x800
| 0xE
| Country name in UTF-16, every 0x80-bytes is an entry for each language, in the order of the Language table below (not all entries are set)
|-
| 0x000B0002
| 0x800
| 0xE
| State name in UTF-16, every 0x80-bytes is an entry for each language
|-
| 0x000B0003
| 0x4
| 0xE
| Coordinates. A pair of s16 represents latitude and longitude, respectively. One need to multiply both value by 180/32768 to get coordinates in degrees

|-
| 0x000C0000
| 0xC0
| 0xE
| Restricted photo exchange data, and other info (includes a mirror of Parental Restrictions PIN/Secret Answer)
|-
| 0x000C0001
| 0x14
| 0xE
| COPPACS restriction data
|-
| 0x000C0002
| 0x200
| 0xE
| ? Contains the email address set during Parental Restriction setup.
|-
| 0x000D0000
| 0x4
| 0xE
| u16 at offset 0x0: [[SMDH#EULA_Version|EULA Version]] which was agreed to.
|-
| 0x000E0000
| 0x1
| 0xE
| ?
|-
| 0x000F0000
| 0x10
| 0xC
| Debug configuration, read by [[NS]] on dev-units: on startup, NS does <code>svcKernelSetState(6, 1, (u64)debug_flags & 1);
svcKernelSetState(6, 2, (u64)debug_flags & 2);</code> (see [[SVC#KernelSetState|here]]) where <code>debug_flags</code> is the u32 located at offset 0xC in this struct. Then it compares the u32 from +8 in this config-block with the [[Configuration_Memory#APPMEMTYPE|APPMEMTYPE]]. When those don't match NS starts a FIRM-launch (with the same FIRM titleID as the currently running one) to boot into a FIRM with the APPMEMTYPE value from this config-block. The byte at offset 0x0 is related to the memtype as well.
|-
| 0x000F0001
| 0x8
| 0xC
| ?
|-
| 0x000F0003
| 0x1
| 0xC
| ?
|-
| 0x000F0004
| 0x4
| 0xC
| The first u8 is the System-Model [[Cfg:GetSystemModel|value]], the last 3-bytes are unknown
|-
| 0x000F0005
| 0x4
| 0xC
| The first u8 indicates whether network updates are enabled (however, NIM only checks this flag with developer [[Configuration_Memory#ENVINFO|ENVINFO]]).
|-
| 0x000F0006
| 0x28
| 0xC
| ?
|-
| 0x00100000
| 0x2
| 0xC
| ?
|-
| 0x00100001
| 0x94
| 0xC
| Stores Parental Restrictions PIN/Secret Answer and other info
|-
| 0x00100002
| 0x1
| 0xC
| ?
|-
| 0x00100003
| 0x10
| 0xC
| ?
|-
| 0x00110000
| 0x4
| 0xC
| The low u16 indicates whether the system setup is required, such as when the system is booted for the first time or after doing a [[System Settings|System Format]]: 0 = setup required, non-zero = no setup required
|-
| 0x00110001
| 0x8
| 0xC
| TitleID of the menu to launch, used by [[NS]] on dev units (this block can be edited on dev units with [[3DS Development Unit Software#Config|Config]])
|-
| 0x00120000
| 0x8
| 0xC
| [[Hardware_calibration#MCU|MCU volume slider related]] (read by HID)
|-
| 0x00130000
| 0x4
| 0xE
| If response is 0x100 then debug mode is enabled.
|-
| 0x00150000
| 0x4
| 0xC
| ?
|-
| 0x00150001
| 0x8
| 0xC
| ?
|-
| 0x00150002
| 0x4
| 0xE
| ?
|-
| 0x00160000
| 0x4
| 0xE
| Unknown, first byte is used by config service-cmd [[Config_Services|0x00070040]]. (Unknown whether the last 3-bytes are used)
|-
| 0x00170000
| 0x4
| 0xE
| Miiverse (OLV) access key
|-
| 0x00180000
| 0x4
| 0xC
| QTM Infrared LED related, can be 0 or 1
|-
| 0x00180001
| 0x18
| 0xC
| [[Hardware_calibration#QTM|QTM calibration data]]
|-
| 0x00190000
| 0x1
| 0xC
| Unknown. NFC-module checks for value1/non-value1.
|}

The developer unit TID block only exists on developer units.

===Stereo Display Settings===
All values are hard-coded in cfg module.
{| class="wikitable" border="1"
|-
! Offset
! Size
! Value
! Description
|-
| 0x0
| 4
| 62.0f
|assumed pupillary distance in mm?
|-
| 0x4
| 4
| 289.0f
|assumed distance in mm between player's eyes and upper screen?
|-
| 0x8
| 4
| 76.80f
|width in mm of (old) 3DS upper screen (doesn't vary for different models?)
|-
| 0xC
| 4
| 46.08f
|height in mm of (old) 3DS upper screen (doesn't vary for different models?)
|-
| 0x10
| 4
| 10.0f
|
|-
| 0x14
| 4
| 5.0f
|
|-
| 0x18
| 4
| 55.58f
|
|-
| 0x1C
| 4
| 21.57f
|
|}

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

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

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

===WiFi Slot Structure===

====Network structure====
This is used twice in the actual WiFi slot structure.
{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
|-
| 0x0
| 0x1
| Whether the network was set or not?
|-
| 0x1
| 0x1
| Whether to use this network strucutre to connect?
|-
| 0x2
| 0x1
| Whether this structure is the first (0) or the second (1) in the larger WiFi slot structure?
|-
| 0x3
| 0x1
| Padding ?
|-
| 0x4
| 0x20
| SSID of the network, without a trailing nullbyte.
|-
| 0x24
| 0x1
| Length of the SSID.
|-
| 0x25
| 0x1
| [[Nintendo_Zone#Beacon_payload_format|AP crypto key type]]
|-
| 0x26
| 0x2
| Padding ?
|-
| 0x28
| 0x40
| Plaintext of the passphrase of the network, without a trailing nullbyte.
|-
| 0x68
| 0x20
| PBKDF2 of the passphrase and SSID (http://jorisvr.nl/wpapsk.html).
|-
|}

====Actual structure====
{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
|-
| 0x0
| 0x2
| ?
|-
| 0x2
| 0x2
| [https://github.com/lammertb/libcrc/blob/v2.0/src/crc16.c#L43-L76 CRC-16 checksum] of the next 0x410 bytes.
|-
| 0x4
| 0x88
| First network structure. Only set if the network was set "normally", or was the last to be set using WPS during the session.
|-
| 0x8C
| 0x20
| Padding.
|-
| 0xAC
| 0x88
| Second network structure. Only set if the network was set using WPS, otherwise 0-filled.
|-
| 0x134
| 0x20C
| Padding.
|-
| 0x340
| 0x1
| Whether to automatically get the IP address (use DHCP) or not, defaults to 1.
|-
| 0x341
| 0x1
| Whether to automatically get the DNS or not, defaults to 1.
|-
| 0x342
| 0x2
| Padding ?
|-
| 0x344
| 0x4
| IP address, to use if 0x340 is false.
|-
| 0x348
| 0x4
| IP address of the gateway, to use if 0x340 is false.
|-
| 0x34C
| 0x4
| Subnetwork mask, to use if 0x340 is false.
|-
| 0x350
| 0x4
| IP address of the primary DNS , to use if 0x341 is false.
|-
| 0x354
| 0x4
| IP address of the secondary DNS, to use if 0x341 is false.
|-
| 0x358
| 0x4
| Always 0x01050000 ? Only set if the network was the last to be set during the session.
|-
| 0x35C
| 0x4
| IP address to use. Only set if the network was the last to be set during the session.
|-
| 0x360
| 0x6
| MAC address of the AP. Only set if the network was the last to be set during the session.
|-
| 0x366
| 0x1
| Channel. Only set if the network was the last to be set during the session.
|-
| 0x367
| 0x1
| Padding ? Only set if the network was the last to be set during the session.
|-
| 0x368
| 0x1
| Whether to use a proxy or not, defaults to 0.
|-
| 0x369
| 0x1
| Whether to use a basic authentication for the proxy, defaults to 0.
|-
| 0x36A
| 0x2
| Port to use for the proxy, defaults to 1.
|-
| 0x36C
| 0x30
| URL/address of the proxy, including a trailing nullbyte.
|-
| 0x39C
| 0x34
| Padding.
|-
| 0x3D0
| 0x20
| Username to use for basic authentication, including a trailing nullbyte.
|-
| 0x3F0
| 0x20
| Password to use for basic authentication, including a trailing nullbyte.
|-
| 0x410
| 0x2
| Padding ?
|-
| 0x412
| 0x2
| MTU value, defaults to 1400 and ranges between 576 and 1500, inclusive.
|-
| 0x414
| 0x7EC
| Padding.
|-
|}

===LCD display config===
There seems to be some sort of LCD display configuration stored in this cfg. When using the cfg-save from an Old3DS on a New3DS without formatting the cfg first, the bottom-screen display is somewhat off(which is fixed by formatting the cfg-save).

===Parental control Block 0x00100001===
{| class="wikitable" border="1"
|-
! Byte
! Size in bytes
! Description
|-
| 0x0
| 0xD
| Unknown.
|-
| 0xD
| 0x4
| PIN
|-
| 0x11
| 0x20
| Secret answer in UTF-16
|}

===Parental Control setting block 0xC0000===
{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
|-
| 0x00
| 0x04
| [[#Parental Control restriction bitmask|Parental Control restriction bitmask]]
|-
| 0x0C
| 0x04
| Parental Controls PIN code
|}

====Parental Control restriction bitmask====
{| class="wikitable" border="1"
|-
! Bit
! Restriction name
|-
| 0
| Global Parental Controls enable
|-
| 3
| Sharing Images/Audio/Video/Long Text Data
|-
| 4
| Internet Browser
|-
| 5
| StreetPass
|-
| 6
| Friend Registration
|-
| 8
| eShop
|-
| 10
| Miiverse (view)
|-
| 11
| Miiverse (post)
|-
| 31
| "Child Online Privacy Protection" (see [[Cfg:GetRegionCanadaUSA|CFG:IsCoppacsSupported]])
|}

MCU Services

2019-10-07T17:37:35Z

Unknown: /* MCU service "mcu::RTC" */ 0x00$F0040 is used by PTM module

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

=MCU camera service "mcu::CAM"=
{| class="wikitable" border="1"
|-
! Command Header
! Description
|-
| 0x00010040
| WriteCameraLedState (writes i2c register 0x2B)
|-
| 0x00020080
| ReadCameraLedState (reads i2c register 0x2B)
|}

=MCU GPU service "mcu::GPU"=
{| class="wikitable" border="1"
|-
! Command Header
! Description
|-
| 0x00010000
| GetLcdPowerState. This writes the value of I2C-MCU register 0xf bit6 to u8 cmdreply[2], and the value of bit5 from that register to u8 cmdreply[3].
|-
| 0x00020080
| SetLcdPowerState. This writes the upper LCD bits of MCU register 0x22.
|-
| 0x00030000
| GetGpuLcdInterfaceState. This writes the value of I2C-MCU register 0xf bit7 to u8 cmdreply[2].
|-
| 0x00040040
| SetGpuLcdInterfaceState. This writes the lower two bits of MCU register 0x22.
|-
| 0x00050040
| SetTopScreenFlicker
|-
| 0x00060080
| GetTopScreenFlicker
|-
| 0x00070040
| SetBottomScreenFlicker
|-
| 0x00080080
| GetBottomScreenFlicker
|-
| 0x00090000
| GetMcuFwVerHigh. Called by GSP module
|-
| 0x000A0000
| GetMcuFwVerLow. Called by GSP module
|-
| 0x000B0040
| Set3dLedState
|-
| 0x000C0000
| Get3dLedState
|-
| 0x000D0000
| GetMcuGpuEventHandle. Event handle written to TLS+0x8c. MCU notifications 24 to 29 signal this.
|-
| 0x000E0000
| GetMcuGpuEventReason. Writes some value to TLS+0x88. Called by GSP module
|}

=MCU HID service "mcu::HID"=
{| class="wikitable" border="1"
|-
! Command Header
! Description
|-
| 0x00010040
| ?
|-
| 0x00020000
| ??? test register 0x40 bit0, and writes result to IPC+8
|-
| 0x00030040
| ??? writes IPC+4 to register 0x41
|-
| 0x00040000
| ??? reads register 0x44 to IPC+8
|-
| 0x00050080
| ??? writes IPC+4 to register 0x43 and IPC+8 to register 0x44
|-
| 0x00060000
| ReadGyroscopeValues (reads 3x s16 gyro ADC values into IPC+8)
|-
| 0x00070000
| GetRaw3DSliderPosition (u8 position in IPC+8)
|-
| 0x00080040
| ?
|-
| 0x00090000
| ?
|-
| 0x000A0040
| ?
|-
| 0x000B0000
| ?
|-
| 0x000C0000
| GetMcuHidEventHandle. MCU notifications 11 and 12 signal this. Handle is written to IPC+12
|-
| 0x000D0000
| GetMcuHidEventReason. This reads an internal flield into IPC+8 and clears it.
|-
| 0x000E0000
| [[MCUHID:GetSoundVolume|GetSoundVolume]]
|-
| 0x000F0040
| EnableAccelerometerInterrupt(int enable). 1 = enable, 0 = disable accelerometer
|}

While before these functions are handled, the MCU interrupt with bitmask 0x800 is enabled, then after the commands were handled the MCU interrupt bits 0x1800 get cleared.

=MCU service "mcu::RTC"=
{| class="wikitable" border="1"
|-
! Command Header
! Description
|-
| 0x00010080
| [[MCURTC:SetRTC|SetRTC]]
|-
| 0x00020000
| [[MCURTC:GetRTC|GetRTC]]
|-
| 0x00030040
| SetRTCSeconds(u8 seconds)
|-
| 0x00040000
| u8 GetRTCSeconds
|-
| 0x00050040
| SetRTCMinutes(u8 minutes)
|-
| 0x00060000
| u8 GetRTCMinutes
|-
| 0x00070040
| SetRTCHours(u8 hours)
|-
| 0x00080000
| u8 GetRTCHours
|-
| 0x00090040
| SetRTCDayOfWeek(u8 dayno)
|-
| 0x000A0000
| u8 GetRTCDayOfWeek
|-
| 0x000B0040
| SetRTCDayOfMonth(u8 day)
|-
| 0x000C0000
| u8 GetRTCDayOfMonth
|-
| 0x000D0040
| SetRTCMonth(u8 month)
|-
| 0x000E0000
| u8 GetRTCMonth
|-
| 0x000F0040
| SetRTCYear(u8 year) where year = year - 2000
|-
| 0x00100000
| u8 GetRTCYear where year = result + 2000
|-
| 0x00110040
| SetRTCLeapYearCounter(u8 leap)
|-
| 0x00120000
| u8 GetRTCLeapYearCounter
|-
| 0x00130080
| [[MCURTC:SetRTCAlarm|SetRTCAlarm]]
|-
| 0x00140000
| [[MCURTC:GetRTCAlarm|GetRTCAlarm]]
|-
| 0x00150040
| SetRTCAlarmComponent[0] (u8 val)
|-
| 0x00160000
| u8 GetRTCAlarmComponent[0]
|-
| 0x00170040
| SetRTCAlarmComponent[1] (u8 val)
|-
| 0x00180000
| u8 GetRTCAlarmComponent[1]
|-
| 0x00190040
| SetRTCAlarmComponent[2] (u8 val)
|-
| 0x001A0000
| u8 GetRTCAlarmComponent[2]
|-
| 0x001B0040
| SetRTCAlarmComponent[3] (u8 val)
|-
| 0x001C0000
| u8 GetRTCAlarmComponent[3]
|-
| 0x001D0040
| SetRTCAlarmComponent[4] (u8 val)
|-
| 0x001E0000
| u8 GetRTCAlarmComponent[4]
|-
| 0x001F0040
| SetPedometerRecordingMode(u8 mode)
|-
| 0x00200000
| u8 GetPedometerRecordingMode
|-
| 0x00210080
| u8 GetStepCount (for the current day)
|-
| 0x00220042
| ReadRegister4Fh(u32 unused_size, translation_param size=0x156 << 4 <nowiki>|</nowiki> 0xC, u8[0x156] ptr)
|-
| 0x00230000
| void ??? writes 1 to register 0x4E which is not writable
|-
| 0x00240000
| Handle GetPowerEventHandle. MCU notifications 1, 8, 9, 10, 13, 14 and 15 signal this.
see [[I2C_Registers#Device_3|Register 0x18]]
|-
| 0x00250000
| u32 GetPowerInterruptHistory
|-
| 0x00260000
| bool CheckRegister02hBit0
|-
| 0x00270000
| void ClearRegister02hBit0 (does nothing since the register is not writable)
|-
| 0x00280000
| bool CheckRegister02hBit1
|-
| 0x00290000
| void ClearRegister02hBit1
|-
| 0x002A0000
| bool GetShellState. This writes the value of I2C-MCU register 0xf bit1 to u8 cmdreply[2].
|-
| 0x002B0000
| bool GetAdapterState. This writes the value of I2C-MCU register 0xf bit3 to u8 cmdreply[2].
|-
| 0x002C0000
| bool GetBatteryChargeState. This writes the value of I2C-MCU register 0xf bit4 to u8 cmdreply[2].
|-
| 0x002D0000
| [[MCURTC:GetBatteryLevel|GetBatteryLevel]]
|-
| 0x002E0000
| u8 Set......
|-
| 0x002F0000
| u8 GetBatteryEmptyPatternByte0_safe™
|-
| 0x00300040
| SetLEDBrightness(u8 brightness) (see [[I2C_Registers#Device_3|Register 0x28]])
|-
| 0x00310000
| u8 GetLEDBrightness (see [[I2C_Registers#Device_3|Register 0x28]])
|-
| 0x00320000
| void PowerOff (writes 0x1 to i2c MCU device, [[I2C_Registers#Device_3|reg 0x20]])
|-
| 0x00330000
| void HardwareReboot (writes 0x4 to i2c MCU device, [[I2C_Registers#Device_3|reg 0x20]])
|-
| 0x00340000
| WriteRegister reg=0x23 value=0x72 (writing to read-only registers does nothing)
|-
| 0x00350000
| Writes 0x10 to i2c MCU device, reg 0x20 (this bit of the register is not writable)
|-
| 0x00360040
| SetWatchdogTimer(u8 timer)
|-
| 0x00370000
| u8 GetWatchdogTimer
|-
| 0x00380042
| ReadInfoRegister(u32 unused_size, translation_param size << 4 <nowiki>|</nowiki> 0xC, u8[0x13] ptr)
|-
| 0x00390082
| WriteLoop (translation parameters too complex)
|-
| 0x003A0082
| ReadLoop (translation parameters too complex)
|-
| 0x003B0640
| [[MCURTC:SetInfoLEDPattern|SetInfoLEDPattern]]
|-
| 0x003C0040
| [[MCURTC:SetInfoLEDPatternHeader|SetInfoLEDPatternHeader]]
|-
| 0x003D0000
| [[MCURTC:GetInfoLEDStatus|GetInfoLEDStatus]]
|-
| 0x003E0040
| WriteRegister50h(u8 value)
|-
| 0x003F0000
| u8 ReadRegister50h
|-
| 0x00400040
| WriteRegister51h(u8 value)
|-
| 0x00410000
| u8 ReadRegister51h
|-
| 0x00420040
| [[MCURTC:SetBatteryEmptyLEDPattern|SetBatteryEmptyLEDPattern]]
|-
| 0x00430040
| SetScreenFlickerTop(u8 flicker)
|-
| 0x00440000
| u8 GetScreenFlickerTop
|-
| 0x00450040
| SetScreenFlickerBottom(u8 flicker)
|-
| 0x00460000
| u8 GetScreenFlickerBottom
|-
| 0x00470080
| SetVolumeSliderBounds(u8 low, u8 high) (see [[I2C_Registers#Device_3|Register 0x58]])
|-
| 0x00480000
| u8 low, u8 high GetVolumeSliderBounds
|-
| 0x00490040
| SetInterruptMask(u32 mask) (see [[I2C_Registers#Device_3|Register 0x18]])
|-
| 0x004A0000
| u32 GetInterruptMask (see [[I2C_Registers#Device_3|Register 0x18]])
|-
| 0x004B0000
| void ExitExclusiveInterruptMode
|-
| 0x004C0000
| void EnterExclusiveInterruptMode
|-
| 0x004D0000
| [[MCURTC:ReadInterrupt|ReadInterrupt]] (see [[I2C_Registers#Device_3|Register 0x10]])
|-
| 0x004E0040
| [[MCURTC:PublishNotifications|TriggerInterrupt]]
|-
| 0x004F0040
| SetMCUFirmUpdated(u32 flag) used by PTM module
|-
| 0x00500000
| u32 IsMCUFirmUpdated
|-
| 0x00510040
| [[MCURTC:SetSoftwareClosedFlag|SetSoftwareClosedFlag]]
|-
| 0x00520000
| [[MCURTC:GetSoftwareClosedFlag|GetSoftwareClosedFlag]]
|-
| 0x00530040
| ?
|-
| 0x00540000
| ?
|-
| 0x00550040
| ?
|-
| 0x00560000
| ?
|-
| 0x00570040
| ?
|-
| 0x00580000
| ?
|-
| 0x00590040
| [[MCURTC:SetLegacyJumpProhibitedFlag|SetLegacyJumpProhibitedFlag]]
|-
| 0x005A0000
| [[MCURTC:GetLegacyJumpProhibitedFlag|GetLegacyJumpProhibitedFlag]]
|-
| 0x005B0040
| SetUUIDClockSequence
|-
| 0x005C0000
| GetUUIDClockSequence
|-
|}

=MCU sound service "mcu::SND"=
{| class="wikitable" border="1"
|-
! Command Header
! Description
|-
| 0x00010080
| GetSoundVolume, writes volume slider value (0-63) to IPC+8
|-
| 0x00020040
| Set...
|-
| 0x00030000
| GetRegister25h, cmdbuf[2] is 0 on n3ds
|}

=MCU wifi service "mcu::NWM"=
{| class="wikitable" border="1"
|-
! Command Header
! Description
|-
| 0x0001....
| SetWirelessLedState
|-
| 0x0002....
| GetWirelessLedState
|-
| 0x0003....
| Sets GPIO 0x20 high/low?
|-
| 0x0004....
| Gets GPIO 0x20 high/low?
|-
| 0x0005....
| SetEnableWifiGpio
|-
| 0x0006....
| GetEnableWifiGpio
|-
| 0x0007....
| [[MCUNWM:SetWirelessDisabledFlag|SetWirelessDisabledFlag]]
|-
| 0x0008....
| [[MCUNWM:GetWirelessDisabledFlag|GetWirelessDisabledFlag]]
|}

=MCU service "mcu::HWC"=
{| class="wikitable" border="1"
|-
! Command Header
! Description
|-
| 0x00010082
| [[MCUHWC:ReadRegister|ReadRegister]]
|-
| 0x00020082
| [[MCUHWC:WriteRegister|WriteRegister]]
|-
| 0x00030042
| [[MCUHWC:GetInfoRegisters|GetInfoRegisters]]
|-
| 0x00040000
| [[MCUHWC:GetBatteryVoltage|GetBatteryVoltage]]
|-
| 0x00050000
| [[MCUHWC:GetBatteryLevel|GetBatteryLevel]]
|-
| 0x00060040
| [[MCUHWC:SetPowerLEDPattern|SetPowerLEDPattern]]
|-
| 0x00070040
| [[MCUHWC:SetWifiLEDState|SetWifiLEDState]]
|-
| 0x00080040
| [[MCUHWC:SetCameraLEDPattern|SetCameraLEDPattern]]
|-
| 0x00090040
| [[MCUHWC:Set3DLEDState|Set3DLEDState]]
|-
| 0x000A0640
| This is the same as [[MCURTC:SetInfoLEDPattern]].
|-
| 0x000B0000
| [[MCUHWC:GetSoundVolume|GetSoundVolume]]
|-
| 0x000C0040
| SetTopScreenFlicker
|-
| 0x000D0040
| SetBottomScreenFlicker
|-
| 0x000E0080
| ?
|-
| 0x000F00C0
| GetRtcTime
|-
| 0x00100000
| GetMcuFwVerHigh
|-
| 0x00110000
| GetMcuFwVerLow
|}

=MCU service "mcu::PLS"=

<s>Beg the sysmodule to return the datetime registers in decimal form instead of as a Binary Coded Decimal</s>

{| class="wikitable" border="1"
|-
! Command Header
! Description
|-
| 0x00010000
| GetDatetime (returns registers 0x30-0x36 in IPC+8)
|-
| 0x00020000
| [[MCUPLS:GetSeconds|GetSeconds]]
|-
| 0x00030000
| u8 GetMinutes
|-
| 0x00040000
| u8 GetHour
|-
| 0x00050000
| u8 GetDayOfWeek
|-
| 0x00060000
| u8 GetDay
|-
| 0x00070000
| u8 GetMonth
|-
| 0x00080000
| u8 GetYear
|-
| 0x00090000
| u16 GetTickCounter
|}

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

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

=MCU firmware versions=

These reside in mcu sysmodule .rodata, are uploaded to MCU register 0x05 and are usually 0x4003 bytes in size (the actual firmware is 0x4000 bytes preceeded by a 3 byte magic header "<code>jhl</code>" which switches the I2C comms into flash write mode).
Switching requires register 0x05 (at address <code>0xFFBA9</code>) to contain 0x6A ('<code>j</code>'), register 0x06 containing 0x68 ('<code>h</code>'), and writing 0x6C ('<code>l</code>') to register 0x07. The actual flashing sequence is only signaled (code at 0x3312-0x331A) when writing register 0x07, it's skipped otherwise. Register 0x07 gets written anyways, just the actual signaling is skipped if the conditions aren't met.

Before the upload could commence, external MCU interrupts are turned off via GPIO command 0x00020080(0, 0x40000), then after the upload completed, the sysmodule waits exactly one second for the MCU to reboot, then turns external MCU interrupts back on via <code>gpio:MCU</code> command 0x00020080(0x40000, 0x40000).

There exists an alternate code path in very old MCU_FIRM versions where uploading is done using register 0x3B (if register 0x0F is zero and 0x10 is 1). Register 0x3B is part of the RTC alarm registers on recent versions of MCU.

On dev-units, the user-facing representation of this firmware version is displayed by first subtracting 0x10 from the major field (raw register 0x00). It is these user-facing versions that are displayed in the table below. It is unknown what bit4 (0x10) actually represents, but it is seemingly always set.

{| class="wikitable" border="1"
|-
! Title version
! Firmware
|-
| New3DS v9216 (New2DSXL)
| 3.65
|-
| New3DS v8192/safe v9217 (latest)
| 3.56
|-
| Old3DS v6145 to v8192 (latest)
| 2.37
|-
| Old3DS v5122
| 2.35
|-
| Old3DS v4102
| 2.30
|-
| Old3DS v3072
| 2.16
|-
| Old3DS v2048
| 1.52
|-
| Old3DS v1026
| 1.51
|-
| Old3DS v0/safe v0
| 1.20
|-
| Old3DS factory
| 1.07
|}

MCU Services

2018-11-09T04:27:10Z

Unknown: /* MCU service "mcu::RTC" */ PTM passes a `2` as an argument to this function. Not sure what it does though.

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

=MCU camera service "mcu::CAM"=
{| class="wikitable" border="1"
|-
! Command Header
! Description
|-
| 0x00010040
| WriteCameraLedState (writes i2c register 0x2B)
|-
| 0x00020080
| ReadCameraLedState (reads i2c register 0x2B)
|}

=MCU GPU service "mcu::GPU"=
{| class="wikitable" border="1"
|-
! Command Header
! Description
|-
| 0x00010000
| GetLcdPowerState. This writes the value of I2C-MCU register 0xf bit6 to u8 cmdreply[2], and the value of bit5 from that register to u8 cmdreply[3].
|-
| 0x00020080
| SetLcdPowerState. This writes the upper LCD bits of MCU register 0x22.
|-
| 0x00030000
| GetGpuLcdInterfaceState. This writes the value of I2C-MCU register 0xf bit7 to u8 cmdreply[2].
|-
| 0x00040040
| SetGpuLcdInterfaceState. This writes the lower two bits of MCU register 0x22.
|-
| 0x00050040
| SetTopScreenFlicker
|-
| 0x00060080
| GetTopScreenFlicker
|-
| 0x00070040
| SetBottomScreenFlicker
|-
| 0x00080080
| GetBottomScreenFlicker
|-
| 0x00090000
| GetMcuFwVerHigh. Called by GSP module
|-
| 0x000A0000
| GetMcuFwVerLow. Called by GSP module
|-
| 0x000B0040
| Set3dLedState
|-
| 0x000C0000
| Get3dLedState
|-
| 0x000D0000
| GetMcuGpuEventHandle. Event handle written to TLS+0x8c. MCU notifications 24 to 29 signal this.
|-
| 0x000E0000
| GetMcuGpuEventReason. Writes some value to TLS+0x88. Called by GSP module
|}

=MCU HID service "mcu::HID"=
{| class="wikitable" border="1"
|-
! Command Header
! Description
|-
| 0x00010040
| ?
|-
| 0x00020000
| ??? test register 0x40 bit0, and writes result to IPC+8
|-
| 0x00030040
| ??? writes IPC+4 to register 0x41
|-
| 0x00040000
| ??? reads register 0x44 to IPC+8
|-
| 0x00050080
| ??? writes IPC+4 to register 0x43 and IPC+8 to register 0x44
|-
| 0x00060000
| ReadGyroscopeValues (reads gyroscopy with corrected values)
|-
| 0x00070000
| GetRaw3DSliderPosition
|-
| 0x00080040
| ?
|-
| 0x00090000
| ?
|-
| 0x000A0040
| ?
|-
| 0x000B0000
| ?
|-
| 0x000C0000
| GetMcuHidEventHandle. MCU notifications 11 and 12 signal this. Handle is written to IPC+12
|-
| 0x000D0000
| GetMcuHidEventReason. This reads an internal flield into IPC+8 and clears it.
|-
| 0x000E0000
| [[MCUHID:GetSoundVolume|GetSoundVolume]]
|-
| 0x000F0040
| EnableAccelerometerInterrupt(int enable). 1 = enable, 0 = disable accelerometer
|}

While before these functions are handled, the MCU interrupt with bitmask 0x800 is enabled, then after the commands were handled the MCU interrupt bits 0x1800 get cleared.

=MCU service "mcu::RTC"=
{| class="wikitable" border="1"
|-
! Command Header
! Description
|-
| 0x00010080
| [[MCURTC:SetRTC|SetRTC]]
|-
| 0x00020000
| [[MCURTC:GetRTC|GetRTC]]
|-
| 0x00030040
| SetRTCSeconds(u8 seconds)
|-
| 0x00040000
| u8 GetRTCSeconds
|-
| 0x00050040
| SetRTCMinutes(u8 minutes)
|-
| 0x00060000
| u8 GetRTCMinutes
|-
| 0x00070040
| SetRTCHours(u8 hours)
|-
| 0x00080000
| u8 GetRTCHours
|-
| 0x00090040
| SetRTCDayOfWeek(u8 dayno)
|-
| 0x000A0000
| u8 GetRTCDayOfWeek
|-
| 0x000B0040
| SetRTCDayOfMonth(u8 day)
|-
| 0x000C0000
| u8 GetRTCDayOfMonth
|-
| 0x000D0040
| SetRTCMonth(u8 month)
|-
| 0x000E0000
| u8 GetRTCMonth
|-
| 0x000F0040
| SetRTCYear(u8 year) where year = year - 2000
|-
| 0x00100000
| u8 GetRTCYear where year = result + 2000
|-
| 0x00110040
| SetRTCLeapYearCounter(u8 leap)
|-
| 0x00120000
| u8 GetRTCLeapYearCounter
|-
| 0x00130080
| [[MCURTC:SetRTCAlarm|SetRTCAlarm]]
|-
| 0x00140000
| [[MCURTC:GetRTCAlarm|GetRTCAlarm]]
|-
| 0x00150040
| SetRTCAlarmComponent[0] (u8 val)
|-
| 0x00160000
| u8 GetRTCAlarmComponent[0]
|-
| 0x00170040
| SetRTCAlarmComponent[1] (u8 val)
|-
| 0x00180000
| u8 GetRTCAlarmComponent[1]
|-
| 0x00190040
| SetRTCAlarmComponent[2] (u8 val)
|-
| 0x001A0000
| u8 GetRTCAlarmComponent[2]
|-
| 0x001B0040
| SetRTCAlarmComponent[3] (u8 val)
|-
| 0x001C0000
| u8 GetRTCAlarmComponent[3]
|-
| 0x001D0040
| SetRTCAlarmComponent[4] (u8 val)
|-
| 0x001E0000
| u8 GetRTCAlarmComponent[4]
|-
| 0x001F0040
| SetPedometerRecordingMode(u8 mode)
|-
| 0x00200000
| u8 GetPedometerRecordingMode
|-
| 0x00210080
| u8 GetStepCount (for the current day)
|-
| 0x00220042
| ReadRegister4Fh(u32 unused_size, translation_param size=0x156 << 4 <nowiki>|</nowiki> 0xC, u8[0x156] ptr)
|-
| 0x00230000
| void ??? writes 1 to register 0x4E which is not writable
|-
| 0x00240000
| Handle GetPowerEventHandle. MCU notifications 1, 8, 9, 10, 13, 14 and 15 signal this.
see [[I2C_Registers#Device_3|Register 0x18]]
|-
| 0x00250000
| u32 GetPowerInterruptHistory
|-
| 0x00260000
| bool CheckRegister02hBit0
|-
| 0x00270000
| void ClearRegister02hBit0 (does nothing since the register is not writable)
|-
| 0x00280000
| bool CheckRegister02hBit1
|-
| 0x00290000
| void ClearRegister02hBit1
|-
| 0x002A0000
| bool GetShellState. This writes the value of I2C-MCU register 0xf bit1 to u8 cmdreply[2].
|-
| 0x002B0000
| bool GetAdapterState. This writes the value of I2C-MCU register 0xf bit3 to u8 cmdreply[2].
|-
| 0x002C0000
| bool GetBatteryChargeState. This writes the value of I2C-MCU register 0xf bit4 to u8 cmdreply[2].
|-
| 0x002D0000
| [[MCURTC:GetBatteryLevel|GetBatteryLevel]]
|-
| 0x002E0000
| u8 Set......
|-
| 0x002F0000
| u8 GetBatteryEmptyPatternByte0_safe™
|-
| 0x00300040
| SetLEDBrightness(u8 brightness) (see [[I2C_Registers#Device_3|Register 0x28]])
|-
| 0x00310000
| u8 GetLEDBrightness (see [[I2C_Registers#Device_3|Register 0x28]])
|-
| 0x00320000
| void PowerOff (writes 0x1 to i2c MCU device, [[I2C_Registers#Device_3|reg 0x20]])
|-
| 0x00330000
| void HardwareReboot (writes 0x4 to i2c MCU device, [[I2C_Registers#Device_3|reg 0x20]])
|-
| 0x00340000
| WriteRegister reg=0x23 value=0x72 (writing to read-only registers does nothing)
|-
| 0x00350000
| Writes 0x10 to i2c MCU device, reg 0x20 (this bit of the register is not writable)
|-
| 0x00360040
| SetWatchdogTimer(u8 timer)
|-
| 0x00370000
| u8 GetWatchdogTimer
|-
| 0x00380042
| ReadInfoRegister(u32 unused_size, translation_param size << 4 <nowiki>|</nowiki> 0xC, u8[0x13] ptr)
|-
| 0x00390082
| WriteLoop (translation parameters too complex)
|-
| 0x003A0082
| ReadLoop (translation parameters too complex)
|-
| 0x003B0640
| [[MCURTC:SetInfoLEDPattern|SetInfoLEDPattern]]
|-
| 0x003C0040
| [[MCURTC:SetInfoLEDPatternHeader|SetInfoLEDPatternHeader]]
|-
| 0x003D0000
| [[MCURTC:GetInfoLEDStatus|GetInfoLEDStatus]]
|-
| 0x003E0040
| WriteRegister50h(u8 value)
|-
| 0x003F0000
| u8 ReadRegister50h
|-
| 0x00400040
| WriteRegister51h(u8 value)
|-
| 0x00410000
| u8 ReadRegister51h
|-
| 0x00420040
| [[MCURTC:SetBatteryEmptyLEDPattern|SetBatteryEmptyLEDPattern]]
|-
| 0x00430040
| SetScreenFlickerTop(u8 flicker)
|-
| 0x00440000
| u8 GetScreenFlickerTop
|-
| 0x00450040
| SetScreenFlickerBottom(u8 flicker)
|-
| 0x00460000
| u8 GetScreenFlickerBottom
|-
| 0x00470080
| SetVolumeSliderBounds(u8 low, u8 high) (see [[I2C_Registers#Device_3|Register 0x58]])
|-
| 0x00480000
| u8 low, u8 high GetVolumeSliderBounds
|-
| 0x00490040
| SetInterruptMask(u32 mask) (see [[I2C_Registers#Device_3|Register 0x18]])
|-
| 0x004A0000
| u32 GetInterruptMask (see [[I2C_Registers#Device_3|Register 0x18]])
|-
| 0x004B0000
| void ExitExclusiveInterruptMode
|-
| 0x004C0000
| void EnterExclusiveInterruptMode
|-
| 0x004D0000
| [[MCURTC:ReadInterrupt|ReadInterrupt]] (see [[I2C_Registers#Device_3|Register 0x10]])
|-
| 0x004E0040
| [[MCURTC:PublishNotifications|TriggerInterrupt]]
|-
| 0x004F0040
| SetMCUFirmUpdated(u32 flag) not used by anything
|-
| 0x00500000
| u32 IsMCUFirmUpdated
|-
| 0x00510040
| [[MCURTC:SetSoftwareClosedFlag|SetSoftwareClosedFlag]]
|-
| 0x00520000
| [[MCURTC:GetSoftwareClosedFlag|GetSoftwareClosedFlag]]
|-
| 0x00530040
| ?
|-
| 0x00540000
| ?
|-
| 0x00550040
| ?
|-
| 0x00560000
| ?
|-
| 0x00570040
| ?
|-
| 0x00580000
| ?
|-
| 0x00590040
| [[MCURTC:SetLegacyJumpProhibitedFlag|SetLegacyJumpProhibitedFlag]]
|-
| 0x005A0000
| [[MCURTC:GetLegacyJumpProhibitedFlag|GetLegacyJumpProhibitedFlag]]
|-
| 0x005B0040
| SetUUIDClockSequence
|-
| 0x005C0000
| GetUUIDClockSequence
|-
|}

=MCU sound service "mcu::SND"=
{| class="wikitable" border="1"
|-
! Command Header
! Description
|-
| 0x00010080
| GetSoundVolume, writes volume slider value (0-63) to IPC+8
|-
| 0x00020040
| Set...
|-
| 0x00030000
| GetRegister25h, cmdbuf[2] is 0 on n3ds
|}

=MCU wifi service "mcu::NWM"=
{| class="wikitable" border="1"
|-
! Command Header
! Description
|-
| 0x0001....
| SetWirelessLedState
|-
| 0x0002....
| GetWirelessLedState
|-
| 0x0003....
| Sets GPIO 0x20 high/low?
|-
| 0x0004....
| Gets GPIO 0x20 high/low?
|-
| 0x0005....
| SetEnableWifiGpio
|-
| 0x0006....
| GetEnableWifiGpio
|-
| 0x0007....
| [[MCUNWM:SetWirelessDisabledFlag|SetWirelessDisabledFlag]]
|-
| 0x0008....
| [[MCUNWM:GetWirelessDisabledFlag|GetWirelessDisabledFlag]]
|}

=MCU service "mcu::HWC"=
{| class="wikitable" border="1"
|-
! Command Header
! Description
|-
| 0x00010082
| [[MCUHWC:ReadRegister|ReadRegister]]
|-
| 0x00020082
| [[MCUHWC:WriteRegister|WriteRegister]]
|-
| 0x00030042
| [[MCUHWC:GetInfoRegisters|GetInfoRegisters]]
|-
| 0x00040000
| [[MCUHWC:GetBatteryVoltage|GetBatteryVoltage]]
|-
| 0x00050000
| [[MCUHWC:GetBatteryLevel|GetBatteryLevel]]
|-
| 0x00060040
| [[MCUHWC:SetPowerLEDPattern|SetPowerLEDPattern]]
|-
| 0x00070040
| [[MCUHWC:SetWifiLEDState|SetWifiLEDState]]
|-
| 0x00080040
| [[MCUHWC:SetCameraLEDPattern|SetCameraLEDPattern]]
|-
| 0x00090040
| [[MCUHWC:Set3DLEDState|Set3DLEDState]]
|-
| 0x000A0640
| This is the same as [[MCURTC:SetInfoLEDPattern]].
|-
| 0x000B0000
| [[MCUHWC:GetSoundVolume|GetSoundVolume]]
|-
| 0x000C0040
| SetTopScreenFlicker
|-
| 0x000D0040
| SetBottomScreenFlicker
|-
| 0x000E0080
| ?
|-
| 0x000F00C0
| GetRtcTime
|-
| 0x00100000
| GetMcuFwVerHigh
|-
| 0x00110000
| GetMcuFwVerLow
|}

=MCU service "mcu::PLS"=

<s>Beg the sysmodule to return the datetime registers in decimal form instead of as a Binary Coded Decimal</s>

{| class="wikitable" border="1"
|-
! Command Header
! Description
|-
| 0x00010000
| GetDatetime (returns registers 0x30-0x36 in IPC+8)
|-
| 0x00020000
| [[MCUPLS:GetSeconds|GetSeconds]]
|-
| 0x00030000
| u8 GetMinutes
|-
| 0x00040000
| u8 GetHour
|-
| 0x00050000
| u8 GetDayOfWeek
|-
| 0x00060000
| u8 GetDay
|-
| 0x00070000
| u8 GetMonth
|-
| 0x00080000
| u8 GetYear
|-
| 0x00090000
| u16 GetTickCounter
|}

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

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

=MCU firmware versions=

These reside in mcu sysmodule .rodata, are uploaded to MCU register 0x05 and are usually 0x4003 bytes in size (the actual firmware is 0x4000 bytes preceeded by a 3 byte magic header "<code>jhl</code>" which switches the I2C comms into flash write mode).
Switching requires register 0x05 (at address <code>0xFFBA9</code>) to contain 0x6A ('<code>j</code>'), register 0x06 containing 0x68 ('<code>h</code>'), and writing 0x6C ('<code>l</code>') to register 0x07. The actual flashing sequence is only signaled (code at 0x3312-0x331A) when writing register 0x07, it's skipped otherwise. Register 0x07 gets written anyways, just the actual signaling is skipped if the conditions aren't met.

Before the upload could commence, external MCU interrupts are turned off via GPIO command 0x00020080(0, 0x40000), then after the upload completed, the sysmodule waits exactly one second for the MCU to reboot, then turns external MCU interrupts back on via <code>gpio:MCU</code> command 0x00020080(0x40000, 0x40000).

There exists an alternate code path in very old MCU_FIRM versions where uploading is done using register 0x3B (if register 0x0F is zero and 0x10 is 1). Register 0x3B is part of the RTC alarm registers on recent versions of MCU.

On dev-units, the user-facing representation of this firmware version is displayed by first subtracting 0x10 from the major field (raw register 0x00). It is these user-facing versions that are displayed in the table below. It is unknown what bit4 (0x10) actually represents, but it is seemingly always set.

{| class="wikitable" border="1"
|-
! Title version
! Firmware
|-
| New3DS v9216 (New2DSXL)
| 3.65
|-
| New3DS v8192/safe v9217 (latest)
| 3.56
|-
| Old3DS v6145 to v8192 (latest)
| 2.37
|-
| Old3DS v5122
| 2.35
|-
| Old3DS v4102
| 2.30
|-
| Old3DS v3072
| 2.16
|-
| Old3DS v2048
| 1.52
|-
| Old3DS v1026
| 1.51
|-
| Old3DS v0/safe v0
| 1.20
|-
| Old3DS factory
| 1.07
|}

Services

2018-11-08T15:58:06Z

Unknown: /* Notifications */

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

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

Processes with PID less than or equal to the number of NATIVE_FIRM built-in modules (fs, sm, pm, pxi, ldr) have access to all services. This value is obtained from [[SVC|svcGetSystemInfo]]. Other processes are limited to access services listed in their [[NCCH/Extended_Header#ARM11_Local_System_Capabilities|service access control list]], as passed to [[SRVPM:RegisterProcess]].

Attempting to use [[SRV:GetServiceHandle|GetServiceHandle]] with a service that the process has access to when that service isn't registered will block until it is registered.

==Service Manager Port "srv:"==
{| class="wikitable" border="1"
|-
! Command Header
! Description
|-
| 0x00010002
| [[SRV:RegisterClient|RegisterClient]]
|-
| 0x00020000
| [[SRV:EnableNotification|EnableNotification]]
|-
| 0x00030100
| [[SRV:RegisterService|RegisterService]]
|-
| 0x000400C0
| [[SRV:UnregisterService|UnregisterService]]
|-
| 0x00050100
| [[SRV:GetServiceHandle|GetServiceHandle]]
|-
| 0x000600C2
| [[SRV:RegisterPort|RegisterPort]]
|-
| 0x000700C0
| [[SRV:UnregisterPort|UnregisterPort]]
|-
| 0x00080100
| [[SRV:GetPort|GetPort]]
|-
| 0x00090040
| [[SRV:Subscribe|Subscribe]]
|-
| 0x000A0040
| [[SRV:Unsubscribe|Unsubscribe]]
|-
| 0x000B0000
| [[SRV:ReceiveNotification|ReceiveNotification]]
|-
| 0x000C0080
| [[SRV:PublishToSubscriber|PublishToSubscriber]]
|-
| 0x000D0040
| [[SRV:PublishAndGetSubscriber|PublishAndGetSubscriber]]
|-
| 0x000E00C0
| [[SRV:IsServiceRegistered|IsServiceRegistered]]
|}

It appears these "port" commands can be used for transferring arbitrary handles, however [[SRV:GetPort|GetPort]] still uses the same service-access-control validation as [[SRV:GetServiceHandle|GetServiceHandle]]. Despite this fact, it appears that a "port" and a service with the same name can coexist independently.

==Service Manager Process-Manager Port/Service "srv:pm"==
{| class="wikitable" border="1"
|-
! Command Header (port), prior to [[7.0.0-13]]
! Command Header (service), post [[7.0.0-13]]
! Description
|-
| 0x04010042
| 0x00010042
| [[SRVPM:PublishToProcess|PublishToProcess]]
|-
| 0x04020040
| 0x00020040
| [[SRVPM:PublishToAll|PublishToAll]]
|-
| 0x04030082
| 0x00030082
| [[SRVPM:RegisterProcess|RegisterProcess]]
|-
| 0x04040040
| 0x00040040
| [[SRVPM:UnregisterProcess|UnregisterProcess]]
|}

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

==Notifications==
{| class="wikitable" border="1"
|-
! ID
! Description
|-
| 0x100
| This indicates that the recipient must terminate. Does not require subscription.
|-
| 0x101
| Signaled to NS on sleep mode entry.
|-
| 0x103
| Fired on sleep mode entry, subscribed to by NS, CSND, NWM, AC and NIM.
|-
| 0x104
| This indicates that the system is entering sleep mode. (PTM:NotifySleepPreparationComplete needed for this and the following?)
|-
| 0x105
| This indicates that the system has exited sleep mode.
|-
| 0x106
| Fired after sleep mode exit, subscribed to by NS, MIC, AC, NEWS, CECD and BOSS.
|-
| 0x107
| Unknown. Subscribed to by CECD module.
|-
| 0x108
| error at boot?
|-
| 0x109
| ? (Subscribed to by GSP)
|-
| 0x10C
| Sent by PM after it calls svcDebugActiveProcess on a title queued for debug.
|-
| 0x110-0x11F
| Sent to NS on application exit. See [[PMApp:LaunchTitle#Launch_Flags|PM launch flags]].
|-
| 0x179
| Unknown.
|-
| 0x200
| Signaled just before sleep mode is exited from, subscribed to by NS.
|-
| 0x202
| POWER button pressed
|-
| 0x203
| POWER button held long
|-
| 0x204
| HOME button pressed
|-
| 0x205
| HOME button released
|-
| 0x206
| This is signaled by [[NWMEXT:ControlWirelessEnabled]] and when the physical Wi-Fi slider is enabled
|-
| 0x207
| SD card inserted
|-
| 0x208
| Game cartridge inserted
|-
| 0x209
| SD card removed
|-
| 0x20A
| Game cartridge removed
|-
| 0x211
| Battery Related? (Published by PTM module)
|-
| 0x212
| Battery Related? (Published by PTM module)
|-
| 0x20B
| Game cartridge inserted or removed
|-
| 0x20C
| mcu-module publishes this on a (fatal) hardware condition?, ptm throws fatal error F960D407 in receipt of this
|-
| 0x20D
| Charger plugged out
|-
| 0x20E
| Charger plugged in
|-
| 0x213
| Signaled after exiting sleep mode and early during system boot. Subscribed to by CODEC, HID, GSP, CAMERA, MIC, NDM and PTM. GSP powers LCD on in receipt to this, etc.
|-
| 0x214
| Signaled before entering sleep mode. Subscribed to by CODEC, HID, GSP, CAMERA, MIC, NDM and PTM. GSP shutdowns LCD in receipt to this, etc.
|-
| 0x300
| Signaled after sleep mode exit and during system boot, subscribed to by NDM.
|-
| 0x301
| Signaled just before sleep mode is exited from, subscribed to by FRIENDS and NDM.
|-
| 0x302
| Unknown. Signaled by nwm/AC module.
|-
| 0x303
| Unknown. Subscribed to by CECD module.
|-
| 0x304
| Unknown. Subscribed to by CECD module.
|}

MCU Services

2018-11-08T12:21:17Z

Unknown: /* MCU service "mcu::RTC" */

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

=MCU camera service "mcu::CAM"=
{| class="wikitable" border="1"
|-
! Command Header
! Description
|-
| 0x00010040
| WriteCameraLedState (writes i2c register 0x2B)
|-
| 0x00020080
| ReadCameraLedState (reads i2c register 0x2B)
|}

=MCU GPU service "mcu::GPU"=
{| class="wikitable" border="1"
|-
! Command Header
! Description
|-
| 0x00010000
| GetLcdPowerState. This writes the value of I2C-MCU register 0xf bit6 to u8 cmdreply[2], and the value of bit5 from that register to u8 cmdreply[3].
|-
| 0x00020080
| SetLcdPowerState. This writes the upper LCD bits of MCU register 0x22.
|-
| 0x00030000
| GetGpuLcdInterfaceState. This writes the value of I2C-MCU register 0xf bit7 to u8 cmdreply[2].
|-
| 0x00040040
| SetGpuLcdInterfaceState. This writes the lower two bits of MCU register 0x22.
|-
| 0x00050040
| SetTopScreenFlicker
|-
| 0x00060080
| GetTopScreenFlicker
|-
| 0x00070040
| SetBottomScreenFlicker
|-
| 0x00080080
| GetBottomScreenFlicker
|-
| 0x00090000
| GetMcuFwVerHigh. Called by GSP module
|-
| 0x000A0000
| GetMcuFwVerLow. Called by GSP module
|-
| 0x000B0040
| Set3dLedState
|-
| 0x000C0000
| Get3dLedState
|-
| 0x000D0000
| GetMcuGpuEventHandle. Event handle written to TLS+0x8c. MCU notifications 24 to 29 signal this.
|-
| 0x000E0000
| GetMcuGpuEventReason. Writes some value to TLS+0x88. Called by GSP module
|}

=MCU HID service "mcu::HID"=
{| class="wikitable" border="1"
|-
! Command Header
! Description
|-
| 0x00010040
| ?
|-
| 0x00020000
| ??? test register 0x40 bit0, and writes result to IPC+8
|-
| 0x00030040
| ??? writes IPC+4 to register 0x41
|-
| 0x00040000
| ??? reads register 0x44 to IPC+8
|-
| 0x00050080
| ??? writes IPC+4 to register 0x43 and IPC+8 to register 0x44
|-
| 0x00060000
| ReadGyroscopeValues (reads gyroscopy with corrected values)
|-
| 0x00070000
| GetRaw3DSliderPosition
|-
| 0x00080040
| ?
|-
| 0x00090000
| ?
|-
| 0x000A0040
| ?
|-
| 0x000B0000
| ?
|-
| 0x000C0000
| GetMcuHidEventHandle. MCU notifications 11 and 12 signal this. Handle is written to IPC+12
|-
| 0x000D0000
| GetMcuHidEventReason. This reads an internal flield into IPC+8 and clears it.
|-
| 0x000E0000
| [[MCUHID:GetSoundVolume|GetSoundVolume]]
|-
| 0x000F0040
| EnableAccelerometerInterrupt(int enable). 1 = enable, 0 = disable accelerometer
|}

While before these functions are handled, the MCU interrupt with bitmask 0x800 is enabled, then after the commands were handled the MCU interrupt bits 0x1800 get cleared.

=MCU service "mcu::RTC"=
{| class="wikitable" border="1"
|-
! Command Header
! Description
|-
| 0x00010080
| [[MCURTC:SetRTC|SetRTC]]
|-
| 0x00020000
| [[MCURTC:GetRTC|GetRTC]]
|-
| 0x00030040
| SetRTCSeconds(u8 seconds)
|-
| 0x00040000
| u8 GetRTCSeconds
|-
| 0x00050040
| SetRTCMinutes(u8 minutes)
|-
| 0x00060000
| u8 GetRTCMinutes
|-
| 0x00070040
| SetRTCHours(u8 hours)
|-
| 0x00080000
| u8 GetRTCHours
|-
| 0x00090040
| SetRTCDayOfWeek(u8 dayno)
|-
| 0x000A0000
| u8 GetRTCDayOfWeek
|-
| 0x000B0040
| SetRTCDayOfMonth(u8 day)
|-
| 0x000C0000
| u8 GetRTCDayOfMonth
|-
| 0x000D0040
| SetRTCMonth(u8 month)
|-
| 0x000E0000
| u8 GetRTCMonth
|-
| 0x000F0040
| SetRTCYear(u8 year) where year = year - 2000
|-
| 0x00100000
| u8 GetRTCYear where year = result + 2000
|-
| 0x00110040
| SetRTCLeapYearCounter(u8 leap)
|-
| 0x00120000
| u8 GetRTCLeapYearCounter
|-
| 0x00130080
| [[MCURTC:SetRTCAlarm|SetRTCAlarm]]
|-
| 0x00140000
| [[MCURTC:GetRTCAlarm|GetRTCAlarm]]
|-
| 0x00150040
| SetRTCAlarmComponent[0] (u8 val)
|-
| 0x00160000
| u8 GetRTCAlarmComponent[0]
|-
| 0x00170040
| SetRTCAlarmComponent[1] (u8 val)
|-
| 0x00180000
| u8 GetRTCAlarmComponent[1]
|-
| 0x00190040
| SetRTCAlarmComponent[2] (u8 val)
|-
| 0x001A0000
| u8 GetRTCAlarmComponent[2]
|-
| 0x001B0040
| SetRTCAlarmComponent[3] (u8 val)
|-
| 0x001C0000
| u8 GetRTCAlarmComponent[3]
|-
| 0x001D0040
| SetRTCAlarmComponent[4] (u8 val)
|-
| 0x001E0000
| u8 GetRTCAlarmComponent[4]
|-
| 0x001F0040
| SetPedometerRecordingMode(u8 mode)
|-
| 0x00200000
| u8 GetPedometerRecordingMode
|-
| 0x00210080
| u8 GetStepCount (for the current day)
|-
| 0x00220042
| ReadRegister4Fh(u32 unused_size, translation_param size=0x156 << 4 <nowiki>|</nowiki> 0xC, u8[0x156] ptr)
|-
| 0x00230000
| void ??? writes 1 to register 0x4E which is not writable
|-
| 0x00240000
| Handle GetPowerEventHandle. MCU notifications 1, 8, 9, 10, 13, 14 and 15 signal this.
see [[I2C_Registers#Device_3|Register 0x18]]
|-
| 0x00250000
| u32 GetPowerInterruptHistory
|-
| 0x00260000
| bool CheckRegister02hBit0
|-
| 0x00270000
| void ClearRegister02hBit0 (does nothing since the register is not writable)
|-
| 0x00280000
| bool CheckRegister02hBit1
|-
| 0x00290000
| void ClearRegister02hBit1
|-
| 0x002A0000
| bool GetShellState. This writes the value of I2C-MCU register 0xf bit1 to u8 cmdreply[2].
|-
| 0x002B0000
| bool GetAdapterState. This writes the value of I2C-MCU register 0xf bit3 to u8 cmdreply[2].
|-
| 0x002C0000
| bool GetBatteryChargeState. This writes the value of I2C-MCU register 0xf bit4 to u8 cmdreply[2].
|-
| 0x002D0000
| [[MCURTC:GetBatteryLevel|GetBatteryLevel]]
|-
| 0x002E0000
| u8 GetBatteryEmptyPatternByte0
|-
| 0x002F0000
| u8 GetBatteryEmptyPatternByte0_safe™
|-
| 0x00300040
| SetLEDBrightness(u8 brightness) (see [[I2C_Registers#Device_3|Register 0x28]])
|-
| 0x00310000
| u8 GetLEDBrightness (see [[I2C_Registers#Device_3|Register 0x28]])
|-
| 0x00320000
| void PowerOff (writes 0x1 to i2c MCU device, [[I2C_Registers#Device_3|reg 0x20]])
|-
| 0x00330000
| void HardwareReboot (writes 0x4 to i2c MCU device, [[I2C_Registers#Device_3|reg 0x20]])
|-
| 0x00340000
| WriteRegister reg=0x23 value=0x72 (writing to read-only registers does nothing)
|-
| 0x00350000
| Writes 0x10 to i2c MCU device, reg 0x20 (this bit of the register is not writable)
|-
| 0x00360040
| SetWatchdogTimer(u8 timer)
|-
| 0x00370000
| u8 GetWatchdogTimer
|-
| 0x00380042
| ReadInfoRegister(u32 unused_size, translation_param size << 4 <nowiki>|</nowiki> 0xC, u8[0x13] ptr)
|-
| 0x00390082
| WriteLoop (translation parameters too complex)
|-
| 0x003A0082
| ReadLoop (translation parameters too complex)
|-
| 0x003B0640
| [[MCURTC:SetInfoLEDPattern|SetInfoLEDPattern]]
|-
| 0x003C0040
| [[MCURTC:SetInfoLEDPatternHeader|SetInfoLEDPatternHeader]]
|-
| 0x003D0000
| [[MCURTC:GetInfoLEDStatus|GetInfoLEDStatus]]
|-
| 0x003E0040
| WriteRegister50h(u8 value)
|-
| 0x003F0000
| u8 ReadRegister50h
|-
| 0x00400040
| WriteRegister51h(u8 value)
|-
| 0x00410000
| u8 ReadRegister51h
|-
| 0x00420040
| [[MCURTC:SetBatteryEmptyLEDPattern|SetBatteryEmptyLEDPattern]]
|-
| 0x00430040
| SetScreenFlickerTop(u8 flicker)
|-
| 0x00440000
| u8 GetScreenFlickerTop
|-
| 0x00450040
| SetScreenFlickerBottom(u8 flicker)
|-
| 0x00460000
| u8 GetScreenFlickerBottom
|-
| 0x00470080
| SetVolumeSliderBounds(u8 low, u8 high) (see [[I2C_Registers#Device_3|Register 0x58]])
|-
| 0x00480000
| u8 low, u8 high GetVolumeSliderBounds
|-
| 0x00490040
| SetInterruptMask(u32 mask) (see [[I2C_Registers#Device_3|Register 0x18]])
|-
| 0x004A0000
| u32 GetInterruptMask (see [[I2C_Registers#Device_3|Register 0x18]])
|-
| 0x004B0000
| void ExitExclusiveInterruptMode
|-
| 0x004C0000
| void EnterExclusiveInterruptMode
|-
| 0x004D0000
| [[MCURTC:ReadInterrupt|ReadInterrupt]] (see [[I2C_Registers#Device_3|Register 0x10]])
|-
| 0x004E0040
| [[MCURTC:PublishNotifications|TriggerInterrupt]]
|-
| 0x004F0040
| SetMCUFirmUpdated(u32 flag) not used by anything
|-
| 0x00500000
| u32 IsMCUFirmUpdated
|-
| 0x00510040
| [[MCURTC:SetSoftwareClosedFlag|SetSoftwareClosedFlag]]
|-
| 0x00520000
| [[MCURTC:GetSoftwareClosedFlag|GetSoftwareClosedFlag]]
|-
| 0x00530040
| ?
|-
| 0x00540000
| ?
|-
| 0x00550040
| ?
|-
| 0x00560000
| ?
|-
| 0x00570040
| ?
|-
| 0x00580000
| ?
|-
| 0x00590040
| [[MCURTC:SetLegacyJumpProhibitedFlag|SetLegacyJumpProhibitedFlag]]
|-
| 0x005A0000
| [[MCURTC:GetLegacyJumpProhibitedFlag|GetLegacyJumpProhibitedFlag]]
|-
| 0x005B0040
| SetUUIDClockSequence
|-
| 0x005C0000
| GetUUIDClockSequence
|-
|}

=MCU sound service "mcu::SND"=
{| class="wikitable" border="1"
|-
! Command Header
! Description
|-
| 0x00010080
| GetSoundVolume, writes volume slider value (0-63) to IPC+8
|-
| 0x00020040
| Set...
|-
| 0x00030000
| GetRegister25h, cmdbuf[2] is 0 on n3ds
|}

=MCU wifi service "mcu::NWM"=
{| class="wikitable" border="1"
|-
! Command Header
! Description
|-
| 0x0001....
| SetWirelessLedState
|-
| 0x0002....
| GetWirelessLedState
|-
| 0x0003....
| Sets GPIO 0x20 high/low?
|-
| 0x0004....
| Gets GPIO 0x20 high/low?
|-
| 0x0005....
| SetEnableWifiGpio
|-
| 0x0006....
| GetEnableWifiGpio
|-
| 0x0007....
| [[MCUNWM:SetWirelessDisabledFlag|SetWirelessDisabledFlag]]
|-
| 0x0008....
| [[MCUNWM:GetWirelessDisabledFlag|GetWirelessDisabledFlag]]
|}

=MCU service "mcu::HWC"=
{| class="wikitable" border="1"
|-
! Command Header
! Description
|-
| 0x00010082
| [[MCUHWC:ReadRegister|ReadRegister]]
|-
| 0x00020082
| [[MCUHWC:WriteRegister|WriteRegister]]
|-
| 0x00030042
| [[MCUHWC:GetInfoRegisters|GetInfoRegisters]]
|-
| 0x00040000
| [[MCUHWC:GetBatteryVoltage|GetBatteryVoltage]]
|-
| 0x00050000
| [[MCUHWC:GetBatteryLevel|GetBatteryLevel]]
|-
| 0x00060040
| [[MCUHWC:SetPowerLEDPattern|SetPowerLEDPattern]]
|-
| 0x00070040
| [[MCUHWC:SetWifiLEDState|SetWifiLEDState]]
|-
| 0x00080040
| [[MCUHWC:SetCameraLEDPattern|SetCameraLEDPattern]]
|-
| 0x00090040
| [[MCUHWC:Set3DLEDState|Set3DLEDState]]
|-
| 0x000A0640
| This is the same as [[MCURTC:SetInfoLEDPattern]].
|-
| 0x000B0000
| [[MCUHWC:GetSoundVolume|GetSoundVolume]]
|-
| 0x000C0040
| SetTopScreenFlicker
|-
| 0x000D0040
| SetBottomScreenFlicker
|-
| 0x000E0080
| ?
|-
| 0x000F00C0
| GetRtcTime
|-
| 0x00100000
| GetMcuFwVerHigh
|-
| 0x00110000
| GetMcuFwVerLow
|}

=MCU service "mcu::PLS"=

<s>Beg the sysmodule to return the datetime registers in decimal form instead of as a Binary Coded Decimal</s>

{| class="wikitable" border="1"
|-
! Command Header
! Description
|-
| 0x00010000
| GetDatetime (returns registers 0x30-0x36 in IPC+8)
|-
| 0x00020000
| [[MCUPLS:GetSeconds|GetSeconds]]
|-
| 0x00030000
| u8 GetMinutes
|-
| 0x00040000
| u8 GetHour
|-
| 0x00050000
| u8 GetDayOfWeek
|-
| 0x00060000
| u8 GetDay
|-
| 0x00070000
| u8 GetMonth
|-
| 0x00080000
| u8 GetYear
|-
| 0x00090000
| u16 GetTickCounter
|}

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

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

=MCU firmware versions=

These reside in mcu sysmodule .rodata, are uploaded to MCU register 0x05 and are usually 0x4003 bytes in size (the actual firmware is 0x4000 bytes preceeded by a 3 byte magic header "<code>jhl</code>" which switches the I2C comms into flash write mode).
Switching requires register 0x05 (at address <code>0xFFBA9</code>) to contain 0x6A ('<code>j</code>'), register 0x06 containing 0x68 ('<code>h</code>'), and writing 0x6C ('<code>l</code>') to register 0x07. The actual flashing sequence is only signaled (code at 0x3312-0x331A) when writing register 0x07, it's skipped otherwise. Register 0x07 gets written anyways, just the actual signaling is skipped if the conditions aren't met.

Before the upload could commence, external MCU interrupts are turned off via GPIO command 0x00020080(0, 0x40000), then after the upload completed, the sysmodule waits exactly one second for the MCU to reboot, then turns external MCU interrupts back on via <code>gpio:MCU</code> command 0x00020080(0x40000, 0x40000).

There exists an alternate code path in very old MCU_FIRM versions where uploading is done using register 0x3B (if register 0x0F is zero and 0x10 is 1). Register 0x3B is part of the RTC alarm registers on recent versions of MCU.

On dev-units, the user-facing representation of this firmware version is displayed by first subtracting 0x10 from the major field (raw register 0x00). It is these user-facing versions that are displayed in the table below. It is unknown what bit4 (0x10) actually represents, but it is seemingly always set.

{| class="wikitable" border="1"
|-
! Title version
! Firmware
|-
| New3DS v9216 (New2DSXL)
| 3.65
|-
| New3DS v8192/safe v9217 (latest)
| 3.56
|-
| Old3DS v6145 to v8192 (latest)
| 2.37
|-
| Old3DS v5122
| 2.35
|-
| Old3DS v4102
| 2.30
|-
| Old3DS v3072
| 2.16
|-
| Old3DS v2048
| 1.52
|-
| Old3DS v1026
| 1.51
|-
| Old3DS v0/safe v0
| 1.20
|-
| Old3DS factory
| 1.07
|}

3DS Userland Flaws

2018-09-18T08:54:53Z

Unknown: /* Non-system applications */

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 its predecessor, Gates to Infinity. When a save file is being prepared to be loaded and read from, only a 0x32000 large buffer is allocated for file reading, and a 0x3e800-large buffer for decompression is also allocated before the file is read. However, the game does not limit the size of the file read to this allocation bound, allowing for the file to overflow into the linear memory heap and into the next allocation. Since Pokemon Super Mystery Dungeon stores allocation memchunks directly before the allocation, overwriting the next memchunk with a corrupted one allows for arbitrary writes of linear heap pointers when the next buffer is allocated or arbitrary writes of any pointer within writable memory when the corrupted buffer is freed.
| None
| O3DS: [[11.3.0-36]]. N3DS: [[11.4.0-37]].
| 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.
| App: v1.1
| [[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.
| App: 3.3.2.
| System: [[11.0.0-33]].
| July 20, 2016
| Around June 26, 2016
| slackerSnail, 12Me12, incvoid
Exploited by MrNbaYoh and [[User:Plutooo|plutoo]].
|-
| The Legend of Zelda: Tri Force Heroes
| [[3DS_System_Flaws#General.2FCTRSDK|CTRSDK]] CTPK buffer overflow combined with game's usage of SpotPass
| During the very first screen displayed by the game during boot("Loading..."), just seconds after title launch, the game loads CTPK from the [[BOSS_Services|stored]] SpotPass content. Hence, this game could be exploited via the vulnerable CTRSDK CTPK code ''if'' one could get custom SpotPass data into extdata somehow(ctr-httpwn >=v1.2 with bosshaxx allows this).

The code for this runs from a thread separate from the main-thread, with the stack in linearmem heap. This SpotPass handling triggers before the game ever opens the regular savedata archive. The extdata is opened at some point before this: it opens a file for checking if it exists, then immediately closes it.

The two SpotPass URLs for this have always(?) returned HTTP 404 as of November 2016. It appears these were intended for use as textures for additional costumes(and never got used publicly), but this wasn't tested.

This is used by [https://github.com/yellows8/ctpkpwn ctpkpwn_tfh].
| None
| App: v2.1.0
| November 18, 2016
| November 14, 2016
| [[User:Yellows8|Yellows8]]
|-
| Pixel Paint
| Buffer overflow via unchecked extdata file length
| Pixel Paint loads pictures saved by the user from extdatas. The file is read to a fixed size buffer but the file length remains unchecked, so with a large enough file, one can overwrite pointers in memory and gain control of the execution flow.
| None
| App: Initial version. System: [[11.2.0-35]].
| December 27, 2016
| November 5, 2016
| [[User:Nba_Yoh|MrNbaYoh]]
|-
| Steel Diver : Sub Wars
| Heap overflow / arbitrary memcpy
| Savefile datas are stored as key/value pairs, a large enough string key makes the game overwrite a memcpy source/destination addresses and size arguments. So one can actually memcpy a rop on the stack and gain control of the execution flow.
| None
| System: [[11.2.0-35]].
| December 27, 2016
| Around July 15, 2016
| [[User:Nba_Yoh|MrNbaYoh]], Vegaroxas
|-
| 1001 Spikes
| Buffer overflow via unchecked array-indexes in XML savefile parsing
| The savefiles are stored as renamed .xml files, which contain several tags with attributes like 'array-index="array-value"', where both of these are converted from ASCII strings to integers as signed-int32, and the array-value given blindly written to an array inside a structure using the (unchecked) index given. With several of these attributes, one can overwrite the stack starting from the stored lr of the function that does this parsing, and write a ROP chain there. Testing used the "LevelAttempts" tag which is the last such tag parsed in that function.
| None
| App: v1.2.0 (TMD v2096)
| December 27, 2016
| Around November 2, 2016
| [[User:Riley|Riley]]
|-
| Pokemon Omega Ruby/Alpha Sapphire
| Secret base team name heap overflow
| When the player wants to edit the team name, it is copied over the heap, however its length is not verified. So with a large enough team name one can overwrite some pointers and get two arbitrary jumps and then get control of the execution flow.
| None
| App: 1.4. System: [[11.2.0-35]].
| December 30, 2016
| June, 2016
| [[User:Nba_Yoh|MrNbaYoh]]
|-
| Swapdoodle
| Heap buffer overflow via unchecked size
| The letter file format used by doodlebomb is composed of multiple chunks. Each chunks is described in the header of the file where the name, size and CRC of each chunk are stored. Some chunks are meant to be headers, every header's size should be 0x80, however the length of the STAHED1 chunk remains unchecked and the game memcpy the chunk to a 0x80 byte buffer with the length provided in the file. This way one is able to overwrite some pointers and get control of the execution flow.
| App: > v1.1.1
| App: v1.1.1
| April 24, 2017
| February, 2017
| [[User:Nba_Yoh|MrNbaYoh]]
|-
| Pokemon Picross
| Arbitrary memcpy via unchecked size
| When reading the savefile, the game handles some lists of buffers that are copied to memory. These buffers should always be 0x14-bytes long but the game uses the size provided in the savefile to copy them. These buffers are copied in some structs and thus with a big enough length value, one can overwrite the next struct which contains a size and a destination address for a memcpy.
| None?
| App: ?
| May 29, 2017
| June, 2016
| [[User:Nba_Yoh|MrNbaYoh]]
|-
| RPG Maker Fes/Player
| Buffer overflow on .bss section
| When loading a project, the game copies multiple chunks over the BSS section. However the number of chunks to copy is not checked, thus a large amount of chunk result in a buffer overflow. There's multiple way to exploit this flaw to gain an arbitrary memcpy or an arbitrary jump.
| None?
| App: ?
| August 28, 2017
| August, 2017
| [[User:Nba_Yoh|MrNbaYoh]]
|-
| RPG Maker Fes/Player
| Buffer overflow via unchecked file size
| When loading a project, the game loads the file to a 0x200000 bytes long buffer. However the size remains unchecked, so with a big enough file one can overflow the buffer and overwrite a thread stack and then achieve ROP.
| None?
| App: ?
| August 29, 2017
| August, 2017
| [[User:Nba_Yoh|MrNbaYoh]]
|-
| Pokemon Omega Ruby/Alpha Sapphire
| PSS data heap/stack overflow
| When launching the game, multiple chunks from the save file are parsed and copied to a large heap buffer. When parsing PSS data (acquaintances, passerby) the game copies each entry to the heap buffer, the number of entries to copy is read from the end of the multiple pss data chunks and is not checked, leading to an overflow. The "PSS data - friends" chunk is vulnerable too, but the overflow occurs on the stack and unfortunately this isn't exploitable because of a 4 bytes uncontrolled value (in each entry) that gets written on sensitive data.
| None
| App: 1.4. System: [[11.6.0]].
| October 1, 2017
| June, 2016
| [[User:Nba_Yoh|MrNbaYoh]]
|-
| RPG Maker Fes/Player
| OOB write
| When handling events in a map, the indices of "buttons" are not checked. This results in an out of bound bit write, one can thus write a rop directly on the stack (bit by bit).
| None?
| App: ?
| August 5, 2018
|
| [[User:Nba_Yoh|MrNbaYoh]]
|-
| Unholy Heights
| Buffer overflow via unchecked string size
| The game stores some utf-16 messages in the savefile. Right before the message is the length(u32) for the string, the game uses this size to memcpy the message from the savefile to the stack without checking the length. This allows one to overwrite some function addresses on the stack and form a rop chain.
| None
| App: Initial Version
| September 13, 2018
| August, 2018
| Kartik
|}

==Flipnote Studio 3D==

{| class="wikitable" border="1"
|-
! Summary
! Description
! Fixed in app/system version
! Timeframe info related to this was added to wiki
! Flaw discovered by
|-
| KFH frame count overflow
| The KFH frame count field should not be >= 0x3E8, but it wasn't checked and so uncontrolled data were written over pointers, causing an unexploitable crash.
| System: 11.6
| September 20, 2017
| [[User:Nba_Yoh|MrNbaYoh]]
|-
| KMI paper color overflow
| Paper color field (and similar color fields) in KMI chunks was not checked, a too high value caused a jump to an uncontrolled location.
| System: 11.6
| September 20, 2017
| [[User:Nba_Yoh|MrNbaYoh]]
|-
| KSN BGM data size overflow
| The size of the BGM data in the KSN chunk was not checked, it was used in a memcpy so with a big enough size one could overwrite a thread stack on linear mem and achieve ROP (notehax v1).
| System: 11.6
| September 20, 2017
| [[User:Nba_Yoh|MrNbaYoh]]
|-
| KMC chunk unchecked
| The KMC chunk was not verified at all, the CRC32 and the size were not checked. A big enough size caused an integer overflow and made the game read the file backward.
| System: 11.6
| September 20, 2017
| [[User:Nba_Yoh|MrNbaYoh]]
|-
| KMI layer size unchecked
| The 3 layer size fields in KMI chunks were not checked, leading to some crashes in the editor.
| System: 11.6
| September 20, 2017
| [[User:Nba_Yoh|MrNbaYoh]]
|-
| Bad "queue" implementation
| When a KWZ was parsed, frames were copied in a kind of queue, bounds were not checked obviously, so with the KMI layer size flaw one was able to fill completely the queue, then write past the buffer and overwrite a heap chunk header (notehax v2). This is not possible anymore, the queue cannot be filled because layer sizes are checked. Moreover each time an element is removed from the queue, the whole content is memmoved *facepalm*.
| System: 11.6
| September 20, 2017
| [[User:Nba_Yoh|MrNbaYoh]]
|}

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

* [[Pyramids 2 (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. Note that this refers to the regular save file: Tri Force Heroes can be exploited via BOSS extdata - see above.

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

* "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 random data results in a crash

* "Worcle Worlds": Overwriting the savefile with 0xFF results in a crash due to an out of bound read

* "Animal Crossing: New Leaf": Creating a QR code from random data results in a valid QR code and a random design. In some very rare cases(which aren't always reproducible?) a crash/etc may occur, but this isn't known to be useful.

==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]]
|-
| [[Nintendo 3DS Sound]]
| When a .m4a is loaded, the song name is copied to a 256 byte buffer. When the song name begins with a Unicode BOM marker, it memcpy's the tag using the user-provided length. This gives an arbitrary write which can be used to achieve ROP.
| [[11.4.0-37]]
| [[11.4.0-37]]
| June/July 2016
| [[User:nedwill|nedwill]]
|}

=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
|-
| 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]]
|-
| Skater - Bookmark OOB write
| Each bookmark has an id that should not exceed 0x63 (99), however ids are not checked, this results in an OOB write on the stack, but only the value 0x01 can be written.
|
| [[11.6.0-39|11.6.0-39]]
|
| May 21, 2018
| May 20, 2018
| [[User:Nba_Yoh|MrNbaYoh]]
|-
| MicroSD Management - malformed security blob causes stack buffer overflow (mhax)
| The MicroSD Management application's parsing of Windows NTLM security blobs in the SMB/CIFS protocol doesn't verify that the client's specified NT domain name is less than 32 UTF-16 characters. When it's longer, a stack buffer overrun occurs, leading to a ROP chain and complete control of the mcopy application.

The malformed security blob can be sent by an attacker within the SMB_COM_SESSION_SETUP_ANDX (0x73) packet.
| [[11.8.0-41|11.8.0-41]]
| [[11.8.0-41|11.8.0-41]]
| [[9.0.0-20|9.0.0-20]]
| August 12, 2018
| 2018
| smea
|}

==Home Menu==
{| 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
|-
| bossbannerhax
| After successfully loading [[Extended_Banner|extended-banner]] data(done when selecting an icon), Home Menu attempts to load "[[CBMD]]" data into a 0x100000-byte heap buffer from the [[BOSS_Services|stored]] SpotPass content. When successful and the magic-number is CBMD, Home Menu then decompresses the exbanner sections into another fixed-size heap buffer, without checking the outsize at all. The main CBMD CGFX code with ExeFS checks the size, but this code doesn't(however this is exbanner "CBMD", not a "normal" CBMD).

Used with menuhax as of v3.2.
| [[11.3.0-36|11.3.0-X]]
|
| [[1.0.0-0|1.0.0-0]]
| November 18, 2016
| December 23, 2014
| [[User:Yellows8|Yellows8]]
|-
| sdiconhax
| This is basically the same as nandiconhax, the vulnerable SD/NAND functions are ''identical'' minus the file-buffer offsets. Exploitation is different due to different heap-buffer location though. Unlike nandiconhax, the icon buffer for SD is located in linearmem(with recent Home Menu versions at least). This is used by [[menuhax]].
| [[11.1.0-34|11.1.0-X]]
|
| [[4.0.0-7|4.0.0-X]]
| July 27, 2016
| October 23, 2015
| [[User:Yellows8|Yellows8]]
|-
| [[System_SaveData|NAND-savedata]] Launcher.dat icons (nandiconhax)
| 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.'''
| [[11.1.0-34|11.1.0-X]]
|
| [[4.0.0-7|4.0.0-X]]
|
| May 14, 2015
| [[User:Yellows8|Yellows8]]
|-
| 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)
|-
| 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]]
|-
| Extdata file-data loading buffer overflow
| The extdata file-reading code allocates a fixed-size heap buffer for the expected filesize, then reads the filedata into this buffer using the actual FS filesize. Before v5.0 the filesize used here wasn't validated, hence if the filesize is larger than alloc_size a buffer overflow would occur. ''After'' doing the file-read it does validate that the actual_readsize matches the alloc_size, but at this point the buffer overflow has already occurred.

This affected at least the following: SaveData.dat and Cache.dat.

This can be triggered with SaveData.dat by installing a <v4.0 Home Menu version, with Home Menu extdata from >=v4.0 still on SD. When this is done with v2.0 Home Menu, a kernelpanic occurs when processing an AM command(it appears a buffer ptr which is then passed to a command was overwritten with 0x0 - of course other SaveData.dat filesizes may result in different behaviour).
| [[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]]
|}

The icon data arrays used with {sd/nand}iconhax were added to SaveData.dat/Launcher.dat with [[4.0.0-7|4.0.0-X]], hence the vulnerable functions were added with that same version.

With <=v4.0 the SaveData.dat buffer is located in the regular heap. It's unknown when exactly it was moved to linearmem, which is where it's located with recent versions. It's located in linearmem for KOR >=v9.6 for example.

The SaveData.dat/Launcher.dat icon vulns were fixed by doing various unsigned >=60/>=360 checks on the loaded values. When these checks fail, it just skips over handling this icon entry. Hence, the original value can't be negative / out-of-bounds any more.

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

2018-09-18T08:38:16Z

Unknown:

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 its predecessor, Gates to Infinity. When a save file is being prepared to be loaded and read from, only a 0x32000 large buffer is allocated for file reading, and a 0x3e800-large buffer for decompression is also allocated before the file is read. However, the game does not limit the size of the file read to this allocation bound, allowing for the file to overflow into the linear memory heap and into the next allocation. Since Pokemon Super Mystery Dungeon stores allocation memchunks directly before the allocation, overwriting the next memchunk with a corrupted one allows for arbitrary writes of linear heap pointers when the next buffer is allocated or arbitrary writes of any pointer within writable memory when the corrupted buffer is freed.
| None
| O3DS: [[11.3.0-36]]. N3DS: [[11.4.0-37]].
| 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.
| App: v1.1
| [[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.
| App: 3.3.2.
| System: [[11.0.0-33]].
| July 20, 2016
| Around June 26, 2016
| slackerSnail, 12Me12, incvoid
Exploited by MrNbaYoh and [[User:Plutooo|plutoo]].
|-
| The Legend of Zelda: Tri Force Heroes
| [[3DS_System_Flaws#General.2FCTRSDK|CTRSDK]] CTPK buffer overflow combined with game's usage of SpotPass
| During the very first screen displayed by the game during boot("Loading..."), just seconds after title launch, the game loads CTPK from the [[BOSS_Services|stored]] SpotPass content. Hence, this game could be exploited via the vulnerable CTRSDK CTPK code ''if'' one could get custom SpotPass data into extdata somehow(ctr-httpwn >=v1.2 with bosshaxx allows this).

The code for this runs from a thread separate from the main-thread, with the stack in linearmem heap. This SpotPass handling triggers before the game ever opens the regular savedata archive. The extdata is opened at some point before this: it opens a file for checking if it exists, then immediately closes it.

The two SpotPass URLs for this have always(?) returned HTTP 404 as of November 2016. It appears these were intended for use as textures for additional costumes(and never got used publicly), but this wasn't tested.

This is used by [https://github.com/yellows8/ctpkpwn ctpkpwn_tfh].
| None
| App: v2.1.0
| November 18, 2016
| November 14, 2016
| [[User:Yellows8|Yellows8]]
|-
| Pixel Paint
| Buffer overflow via unchecked extdata file length
| Pixel Paint loads pictures saved by the user from extdatas. The file is read to a fixed size buffer but the file length remains unchecked, so with a large enough file, one can overwrite pointers in memory and gain control of the execution flow.
| None
| App: Initial version. System: [[11.2.0-35]].
| December 27, 2016
| November 5, 2016
| [[User:Nba_Yoh|MrNbaYoh]]
|-
| Steel Diver : Sub Wars
| Heap overflow / arbitrary memcpy
| Savefile datas are stored as key/value pairs, a large enough string key makes the game overwrite a memcpy source/destination addresses and size arguments. So one can actually memcpy a rop on the stack and gain control of the execution flow.
| None
| System: [[11.2.0-35]].
| December 27, 2016
| Around July 15, 2016
| [[User:Nba_Yoh|MrNbaYoh]], Vegaroxas
|-
| 1001 Spikes
| Buffer overflow via unchecked array-indexes in XML savefile parsing
| The savefiles are stored as renamed .xml files, which contain several tags with attributes like 'array-index="array-value"', where both of these are converted from ASCII strings to integers as signed-int32, and the array-value given blindly written to an array inside a structure using the (unchecked) index given. With several of these attributes, one can overwrite the stack starting from the stored lr of the function that does this parsing, and write a ROP chain there. Testing used the "LevelAttempts" tag which is the last such tag parsed in that function.
| None
| App: v1.2.0 (TMD v2096)
| December 27, 2016
| Around November 2, 2016
| [[User:Riley|Riley]]
|-
| Pokemon Omega Ruby/Alpha Sapphire
| Secret base team name heap overflow
| When the player wants to edit the team name, it is copied over the heap, however its length is not verified. So with a large enough team name one can overwrite some pointers and get two arbitrary jumps and then get control of the execution flow.
| None
| App: 1.4. System: [[11.2.0-35]].
| December 30, 2016
| June, 2016
| [[User:Nba_Yoh|MrNbaYoh]]
|-
| Swapdoodle
| Heap buffer overflow via unchecked size
| The letter file format used by doodlebomb is composed of multiple chunks. Each chunks is described in the header of the file where the name, size and CRC of each chunk are stored. Some chunks are meant to be headers, every header's size should be 0x80, however the length of the STAHED1 chunk remains unchecked and the game memcpy the chunk to a 0x80 byte buffer with the length provided in the file. This way one is able to overwrite some pointers and get control of the execution flow.
| App: > v1.1.1
| App: v1.1.1
| April 24, 2017
| February, 2017
| [[User:Nba_Yoh|MrNbaYoh]]
|-
| Pokemon Picross
| Arbitrary memcpy via unchecked size
| When reading the savefile, the game handles some lists of buffers that are copied to memory. These buffers should always be 0x14-bytes long but the game uses the size provided in the savefile to copy them. These buffers are copied in some structs and thus with a big enough length value, one can overwrite the next struct which contains a size and a destination address for a memcpy.
| None?
| App: ?
| May 29, 2017
| June, 2016
| [[User:Nba_Yoh|MrNbaYoh]]
|-
| RPG Maker Fes/Player
| Buffer overflow on .bss section
| When loading a project, the game copies multiple chunks over the BSS section. However the number of chunks to copy is not checked, thus a large amount of chunk result in a buffer overflow. There's multiple way to exploit this flaw to gain an arbitrary memcpy or an arbitrary jump.
| None?
| App: ?
| August 28, 2017
| August, 2017
| [[User:Nba_Yoh|MrNbaYoh]]
|-
| RPG Maker Fes/Player
| Buffer overflow via unchecked file size
| When loading a project, the game loads the file to a 0x200000 bytes long buffer. However the size remains unchecked, so with a big enough file one can overflow the buffer and overwrite a thread stack and then achieve ROP.
| None?
| App: ?
| August 29, 2017
| August, 2017
| [[User:Nba_Yoh|MrNbaYoh]]
|-
| Pokemon Omega Ruby/Alpha Sapphire
| PSS data heap/stack overflow
| When launching the game, multiple chunks from the save file are parsed and copied to a large heap buffer. When parsing PSS data (acquaintances, passerby) the game copies each entry to the heap buffer, the number of entries to copy is read from the end of the multiple pss data chunks and is not checked, leading to an overflow. The "PSS data - friends" chunk is vulnerable too, but the overflow occurs on the stack and unfortunately this isn't exploitable because of a 4 bytes uncontrolled value (in each entry) that gets written on sensitive data.
| None
| App: 1.4. System: [[11.6.0]].
| October 1, 2017
| June, 2016
| [[User:Nba_Yoh|MrNbaYoh]]
|-
| RPG Maker Fes/Player
| OOB write
| When handling events in a map, the indices of "buttons" are not checked. This results in an out of bound bit write, one can thus write a rop directly on the stack (bit by bit).
| None?
| App: ?
| August 5, 2018
|
| [[User:Nba_Yoh|MrNbaYoh]]
|-
| Unholy Heights
| Buffer overflow via unchecked string size
| The game stores some utf-16 messages in the savefile. Right before the message is the length(u32) for the string, the game uses this size to memcpy the message from the savefile to the stack without checking the length. This allows one to overwrite to some function addresses on the stack and form a rop chain.
| None
| App: Initial Version
| September 13, 2018
| August, 2018
| Kartik
|}

==Flipnote Studio 3D==

{| class="wikitable" border="1"
|-
! Summary
! Description
! Fixed in app/system version
! Timeframe info related to this was added to wiki
! Flaw discovered by
|-
| KFH frame count overflow
| The KFH frame count field should not be >= 0x3E8, but it wasn't checked and so uncontrolled data were written over pointers, causing an unexploitable crash.
| System: 11.6
| September 20, 2017
| [[User:Nba_Yoh|MrNbaYoh]]
|-
| KMI paper color overflow
| Paper color field (and similar color fields) in KMI chunks was not checked, a too high value caused a jump to an uncontrolled location.
| System: 11.6
| September 20, 2017
| [[User:Nba_Yoh|MrNbaYoh]]
|-
| KSN BGM data size overflow
| The size of the BGM data in the KSN chunk was not checked, it was used in a memcpy so with a big enough size one could overwrite a thread stack on linear mem and achieve ROP (notehax v1).
| System: 11.6
| September 20, 2017
| [[User:Nba_Yoh|MrNbaYoh]]
|-
| KMC chunk unchecked
| The KMC chunk was not verified at all, the CRC32 and the size were not checked. A big enough size caused an integer overflow and made the game read the file backward.
| System: 11.6
| September 20, 2017
| [[User:Nba_Yoh|MrNbaYoh]]
|-
| KMI layer size unchecked
| The 3 layer size fields in KMI chunks were not checked, leading to some crashes in the editor.
| System: 11.6
| September 20, 2017
| [[User:Nba_Yoh|MrNbaYoh]]
|-
| Bad "queue" implementation
| When a KWZ was parsed, frames were copied in a kind of queue, bounds were not checked obviously, so with the KMI layer size flaw one was able to fill completely the queue, then write past the buffer and overwrite a heap chunk header (notehax v2). This is not possible anymore, the queue cannot be filled because layer sizes are checked. Moreover each time an element is removed from the queue, the whole content is memmoved *facepalm*.
| System: 11.6
| September 20, 2017
| [[User:Nba_Yoh|MrNbaYoh]]
|}

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

* [[Pyramids 2 (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. Note that this refers to the regular save file: Tri Force Heroes can be exploited via BOSS extdata - see above.

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

* "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 random data results in a crash

* "Worcle Worlds": Overwriting the savefile with 0xFF results in a crash due to an out of bound read

* "Animal Crossing: New Leaf": Creating a QR code from random data results in a valid QR code and a random design. In some very rare cases(which aren't always reproducible?) a crash/etc may occur, but this isn't known to be useful.

==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]]
|-
| [[Nintendo 3DS Sound]]
| When a .m4a is loaded, the song name is copied to a 256 byte buffer. When the song name begins with a Unicode BOM marker, it memcpy's the tag using the user-provided length. This gives an arbitrary write which can be used to achieve ROP.
| [[11.4.0-37]]
| [[11.4.0-37]]
| June/July 2016
| [[User:nedwill|nedwill]]
|}

=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
|-
| 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]]
|-
| Skater - Bookmark OOB write
| Each bookmark has an id that should not exceed 0x63 (99), however ids are not checked, this results in an OOB write on the stack, but only the value 0x01 can be written.
|
| [[11.6.0-39|11.6.0-39]]
|
| May 21, 2018
| May 20, 2018
| [[User:Nba_Yoh|MrNbaYoh]]
|-
| MicroSD Management - malformed security blob causes stack buffer overflow (mhax)
| The MicroSD Management application's parsing of Windows NTLM security blobs in the SMB/CIFS protocol doesn't verify that the client's specified NT domain name is less than 32 UTF-16 characters. When it's longer, a stack buffer overrun occurs, leading to a ROP chain and complete control of the mcopy application.

The malformed security blob can be sent by an attacker within the SMB_COM_SESSION_SETUP_ANDX (0x73) packet.
| [[11.8.0-41|11.8.0-41]]
| [[11.8.0-41|11.8.0-41]]
| [[9.0.0-20|9.0.0-20]]
| August 12, 2018
| 2018
| smea
|}

==Home Menu==
{| 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
|-
| bossbannerhax
| After successfully loading [[Extended_Banner|extended-banner]] data(done when selecting an icon), Home Menu attempts to load "[[CBMD]]" data into a 0x100000-byte heap buffer from the [[BOSS_Services|stored]] SpotPass content. When successful and the magic-number is CBMD, Home Menu then decompresses the exbanner sections into another fixed-size heap buffer, without checking the outsize at all. The main CBMD CGFX code with ExeFS checks the size, but this code doesn't(however this is exbanner "CBMD", not a "normal" CBMD).

Used with menuhax as of v3.2.
| [[11.3.0-36|11.3.0-X]]
|
| [[1.0.0-0|1.0.0-0]]
| November 18, 2016
| December 23, 2014
| [[User:Yellows8|Yellows8]]
|-
| sdiconhax
| This is basically the same as nandiconhax, the vulnerable SD/NAND functions are ''identical'' minus the file-buffer offsets. Exploitation is different due to different heap-buffer location though. Unlike nandiconhax, the icon buffer for SD is located in linearmem(with recent Home Menu versions at least). This is used by [[menuhax]].
| [[11.1.0-34|11.1.0-X]]
|
| [[4.0.0-7|4.0.0-X]]
| July 27, 2016
| October 23, 2015
| [[User:Yellows8|Yellows8]]
|-
| [[System_SaveData|NAND-savedata]] Launcher.dat icons (nandiconhax)
| 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.'''
| [[11.1.0-34|11.1.0-X]]
|
| [[4.0.0-7|4.0.0-X]]
|
| May 14, 2015
| [[User:Yellows8|Yellows8]]
|-
| 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)
|-
| 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]]
|-
| Extdata file-data loading buffer overflow
| The extdata file-reading code allocates a fixed-size heap buffer for the expected filesize, then reads the filedata into this buffer using the actual FS filesize. Before v5.0 the filesize used here wasn't validated, hence if the filesize is larger than alloc_size a buffer overflow would occur. ''After'' doing the file-read it does validate that the actual_readsize matches the alloc_size, but at this point the buffer overflow has already occurred.

This affected at least the following: SaveData.dat and Cache.dat.

This can be triggered with SaveData.dat by installing a <v4.0 Home Menu version, with Home Menu extdata from >=v4.0 still on SD. When this is done with v2.0 Home Menu, a kernelpanic occurs when processing an AM command(it appears a buffer ptr which is then passed to a command was overwritten with 0x0 - of course other SaveData.dat filesizes may result in different behaviour).
| [[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]]
|}

The icon data arrays used with {sd/nand}iconhax were added to SaveData.dat/Launcher.dat with [[4.0.0-7|4.0.0-X]], hence the vulnerable functions were added with that same version.

With <=v4.0 the SaveData.dat buffer is located in the regular heap. It's unknown when exactly it was moved to linearmem, which is where it's located with recent versions. It's located in linearmem for KOR >=v9.6 for example.

The SaveData.dat/Launcher.dat icon vulns were fixed by doing various unsigned >=60/>=360 checks on the loaded values. When these checks fail, it just skips over handling this icon entry. Hence, the original value can't be negative / out-of-bounds any more.

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

2018-09-18T08:36:46Z

Unknown: /* Non-system applications */

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 its predecessor, Gates to Infinity. When a save file is being prepared to be loaded and read from, only a 0x32000 large buffer is allocated for file reading, and a 0x3e800-large buffer for decompression is also allocated before the file is read. However, the game does not limit the size of the file read to this allocation bound, allowing for the file to overflow into the linear memory heap and into the next allocation. Since Pokemon Super Mystery Dungeon stores allocation memchunks directly before the allocation, overwriting the next memchunk with a corrupted one allows for arbitrary writes of linear heap pointers when the next buffer is allocated or arbitrary writes of any pointer within writable memory when the corrupted buffer is freed.
| None
| O3DS: [[11.3.0-36]]. N3DS: [[11.4.0-37]].
| 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.
| App: v1.1
| [[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.
| App: 3.3.2.
| System: [[11.0.0-33]].
| July 20, 2016
| Around June 26, 2016
| slackerSnail, 12Me12, incvoid
Exploited by MrNbaYoh and [[User:Plutooo|plutoo]].
|-
| The Legend of Zelda: Tri Force Heroes
| [[3DS_System_Flaws#General.2FCTRSDK|CTRSDK]] CTPK buffer overflow combined with game's usage of SpotPass
| During the very first screen displayed by the game during boot("Loading..."), just seconds after title launch, the game loads CTPK from the [[BOSS_Services|stored]] SpotPass content. Hence, this game could be exploited via the vulnerable CTRSDK CTPK code ''if'' one could get custom SpotPass data into extdata somehow(ctr-httpwn >=v1.2 with bosshaxx allows this).

The code for this runs from a thread separate from the main-thread, with the stack in linearmem heap. This SpotPass handling triggers before the game ever opens the regular savedata archive. The extdata is opened at some point before this: it opens a file for checking if it exists, then immediately closes it.

The two SpotPass URLs for this have always(?) returned HTTP 404 as of November 2016. It appears these were intended for use as textures for additional costumes(and never got used publicly), but this wasn't tested.

This is used by [https://github.com/yellows8/ctpkpwn ctpkpwn_tfh].
| None
| App: v2.1.0
| November 18, 2016
| November 14, 2016
| [[User:Yellows8|Yellows8]]
|-
| Pixel Paint
| Buffer overflow via unchecked extdata file length
| Pixel Paint loads pictures saved by the user from extdatas. The file is read to a fixed size buffer but the file length remains unchecked, so with a large enough file, one can overwrite pointers in memory and gain control of the execution flow.
| None
| App: Initial version. System: [[11.2.0-35]].
| December 27, 2016
| November 5, 2016
| [[User:Nba_Yoh|MrNbaYoh]]
|-
| Steel Diver : Sub Wars
| Heap overflow / arbitrary memcpy
| Savefile datas are stored as key/value pairs, a large enough string key makes the game overwrite a memcpy source/destination addresses and size arguments. So one can actually memcpy a rop on the stack and gain control of the execution flow.
| None
| System: [[11.2.0-35]].
| December 27, 2016
| Around July 15, 2016
| [[User:Nba_Yoh|MrNbaYoh]], Vegaroxas
|-
| 1001 Spikes
| Buffer overflow via unchecked array-indexes in XML savefile parsing
| The savefiles are stored as renamed .xml files, which contain several tags with attributes like 'array-index="array-value"', where both of these are converted from ASCII strings to integers as signed-int32, and the array-value given blindly written to an array inside a structure using the (unchecked) index given. With several of these attributes, one can overwrite the stack starting from the stored lr of the function that does this parsing, and write a ROP chain there. Testing used the "LevelAttempts" tag which is the last such tag parsed in that function.
| None
| App: v1.2.0 (TMD v2096)
| December 27, 2016
| Around November 2, 2016
| [[User:Riley|Riley]]
|-
| Pokemon Omega Ruby/Alpha Sapphire
| Secret base team name heap overflow
| When the player wants to edit the team name, it is copied over the heap, however its length is not verified. So with a large enough team name one can overwrite some pointers and get two arbitrary jumps and then get control of the execution flow.
| None
| App: 1.4. System: [[11.2.0-35]].
| December 30, 2016
| June, 2016
| [[User:Nba_Yoh|MrNbaYoh]]
|-
| Swapdoodle
| Heap buffer overflow via unchecked size
| The letter file format used by doodlebomb is composed of multiple chunks. Each chunks is described in the header of the file where the name, size and CRC of each chunk are stored. Some chunks are meant to be headers, every header's size should be 0x80, however the length of the STAHED1 chunk remains unchecked and the game memcpy the chunk to a 0x80 byte buffer with the length provided in the file. This way one is able to overwrite some pointers and get control of the execution flow.
| App: > v1.1.1
| App: v1.1.1
| April 24, 2017
| February, 2017
| [[User:Nba_Yoh|MrNbaYoh]]
|-
| Pokemon Picross
| Arbitrary memcpy via unchecked size
| When reading the savefile, the game handles some lists of buffers that are copied to memory. These buffers should always be 0x14-bytes long but the game uses the size provided in the savefile to copy them. These buffers are copied in some structs and thus with a big enough length value, one can overwrite the next struct which contains a size and a destination address for a memcpy.
| None?
| App: ?
| May 29, 2017
| June, 2016
| [[User:Nba_Yoh|MrNbaYoh]]
|-
| RPG Maker Fes/Player
| Buffer overflow on .bss section
| When loading a project, the game copies multiple chunks over the BSS section. However the number of chunks to copy is not checked, thus a large amount of chunk result in a buffer overflow. There's multiple way to exploit this flaw to gain an arbitrary memcpy or an arbitrary jump.
| None?
| App: ?
| August 28, 2017
| August, 2017
| [[User:Nba_Yoh|MrNbaYoh]]
|-
| RPG Maker Fes/Player
| Buffer overflow via unchecked file size
| When loading a project, the game loads the file to a 0x200000 bytes long buffer. However the size remains unchecked, so with a big enough file one can overflow the buffer and overwrite a thread stack and then achieve ROP.
| None?
| App: ?
| August 29, 2017
| August, 2017
| [[User:Nba_Yoh|MrNbaYoh]]
|-
| Pokemon Omega Ruby/Alpha Sapphire
| PSS data heap/stack overflow
| When launching the game, multiple chunks from the save file are parsed and copied to a large heap buffer. When parsing PSS data (acquaintances, passerby) the game copies each entry to the heap buffer, the number of entries to copy is read from the end of the multiple pss data chunks and is not checked, leading to an overflow. The "PSS data - friends" chunk is vulnerable too, but the overflow occurs on the stack and unfortunately this isn't exploitable because of a 4 bytes uncontrolled value (in each entry) that gets written on sensitive data.
| None
| App: 1.4. System: [[11.6.0]].
| October 1, 2017
| June, 2016
| [[User:Nba_Yoh|MrNbaYoh]]
|-
| RPG Maker Fes/Player
| OOB write
| When handling events in a map, the indices of "buttons" are not checked. This results in an out of bound bit write, one can thus write a rop directly on the stack (bit by bit).
| None?
| App: ?
| August 5, 2018
|
| [[User:Nba_Yoh|MrNbaYoh]]
|}

==Flipnote Studio 3D==

{| class="wikitable" border="1"
|-
! Summary
! Description
! Fixed in app/system version
! Timeframe info related to this was added to wiki
! Flaw discovered by
|-
| KFH frame count overflow
| The KFH frame count field should not be >= 0x3E8, but it wasn't checked and so uncontrolled data were written over pointers, causing an unexploitable crash.
| System: 11.6
| September 20, 2017
| [[User:Nba_Yoh|MrNbaYoh]]
|-
| KMI paper color overflow
| Paper color field (and similar color fields) in KMI chunks was not checked, a too high value caused a jump to an uncontrolled location.
| System: 11.6
| September 20, 2017
| [[User:Nba_Yoh|MrNbaYoh]]
|-
| KSN BGM data size overflow
| The size of the BGM data in the KSN chunk was not checked, it was used in a memcpy so with a big enough size one could overwrite a thread stack on linear mem and achieve ROP (notehax v1).
| System: 11.6
| September 20, 2017
| [[User:Nba_Yoh|MrNbaYoh]]
|-
| KMC chunk unchecked
| The KMC chunk was not verified at all, the CRC32 and the size were not checked. A big enough size caused an integer overflow and made the game read the file backward.
| System: 11.6
| September 20, 2017
| [[User:Nba_Yoh|MrNbaYoh]]
|-
| KMI layer size unchecked
| The 3 layer size fields in KMI chunks were not checked, leading to some crashes in the editor.
| System: 11.6
| September 20, 2017
| [[User:Nba_Yoh|MrNbaYoh]]
|-
| Bad "queue" implementation
| When a KWZ was parsed, frames were copied in a kind of queue, bounds were not checked obviously, so with the KMI layer size flaw one was able to fill completely the queue, then write past the buffer and overwrite a heap chunk header (notehax v2). This is not possible anymore, the queue cannot be filled because layer sizes are checked. Moreover each time an element is removed from the queue, the whole content is memmoved *facepalm*.
| System: 11.6
| September 20, 2017
| [[User:Nba_Yoh|MrNbaYoh]]
|-
| Unholy Heights
| Buffer overflow via unchecked string size
| The game stores some utf-16 messages in the savefile. Right before the message is the length(u32) for the string, the game uses this size to memcpy the message from the savefile to the stack without checking the length. This allows one to overwrite to some function addresses on the stack and form a rop chain.
| None
| App: Initial Version
| September 13, 2018
| August, 2018
| Kartik

|}

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

* [[Pyramids 2 (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. Note that this refers to the regular save file: Tri Force Heroes can be exploited via BOSS extdata - see above.

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

* "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 random data results in a crash

* "Worcle Worlds": Overwriting the savefile with 0xFF results in a crash due to an out of bound read

* "Animal Crossing: New Leaf": Creating a QR code from random data results in a valid QR code and a random design. In some very rare cases(which aren't always reproducible?) a crash/etc may occur, but this isn't known to be useful.

==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]]
|-
| [[Nintendo 3DS Sound]]
| When a .m4a is loaded, the song name is copied to a 256 byte buffer. When the song name begins with a Unicode BOM marker, it memcpy's the tag using the user-provided length. This gives an arbitrary write which can be used to achieve ROP.
| [[11.4.0-37]]
| [[11.4.0-37]]
| June/July 2016
| [[User:nedwill|nedwill]]
|}

=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
|-
| 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]]
|-
| Skater - Bookmark OOB write
| Each bookmark has an id that should not exceed 0x63 (99), however ids are not checked, this results in an OOB write on the stack, but only the value 0x01 can be written.
|
| [[11.6.0-39|11.6.0-39]]
|
| May 21, 2018
| May 20, 2018
| [[User:Nba_Yoh|MrNbaYoh]]
|-
| MicroSD Management - malformed security blob causes stack buffer overflow (mhax)
| The MicroSD Management application's parsing of Windows NTLM security blobs in the SMB/CIFS protocol doesn't verify that the client's specified NT domain name is less than 32 UTF-16 characters. When it's longer, a stack buffer overrun occurs, leading to a ROP chain and complete control of the mcopy application.

The malformed security blob can be sent by an attacker within the SMB_COM_SESSION_SETUP_ANDX (0x73) packet.
| [[11.8.0-41|11.8.0-41]]
| [[11.8.0-41|11.8.0-41]]
| [[9.0.0-20|9.0.0-20]]
| August 12, 2018
| 2018
| smea
|}

==Home Menu==
{| 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
|-
| bossbannerhax
| After successfully loading [[Extended_Banner|extended-banner]] data(done when selecting an icon), Home Menu attempts to load "[[CBMD]]" data into a 0x100000-byte heap buffer from the [[BOSS_Services|stored]] SpotPass content. When successful and the magic-number is CBMD, Home Menu then decompresses the exbanner sections into another fixed-size heap buffer, without checking the outsize at all. The main CBMD CGFX code with ExeFS checks the size, but this code doesn't(however this is exbanner "CBMD", not a "normal" CBMD).

Used with menuhax as of v3.2.
| [[11.3.0-36|11.3.0-X]]
|
| [[1.0.0-0|1.0.0-0]]
| November 18, 2016
| December 23, 2014
| [[User:Yellows8|Yellows8]]
|-
| sdiconhax
| This is basically the same as nandiconhax, the vulnerable SD/NAND functions are ''identical'' minus the file-buffer offsets. Exploitation is different due to different heap-buffer location though. Unlike nandiconhax, the icon buffer for SD is located in linearmem(with recent Home Menu versions at least). This is used by [[menuhax]].
| [[11.1.0-34|11.1.0-X]]
|
| [[4.0.0-7|4.0.0-X]]
| July 27, 2016
| October 23, 2015
| [[User:Yellows8|Yellows8]]
|-
| [[System_SaveData|NAND-savedata]] Launcher.dat icons (nandiconhax)
| 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.'''
| [[11.1.0-34|11.1.0-X]]
|
| [[4.0.0-7|4.0.0-X]]
|
| May 14, 2015
| [[User:Yellows8|Yellows8]]
|-
| 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)
|-
| 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]]
|-
| Extdata file-data loading buffer overflow
| The extdata file-reading code allocates a fixed-size heap buffer for the expected filesize, then reads the filedata into this buffer using the actual FS filesize. Before v5.0 the filesize used here wasn't validated, hence if the filesize is larger than alloc_size a buffer overflow would occur. ''After'' doing the file-read it does validate that the actual_readsize matches the alloc_size, but at this point the buffer overflow has already occurred.

This affected at least the following: SaveData.dat and Cache.dat.

This can be triggered with SaveData.dat by installing a <v4.0 Home Menu version, with Home Menu extdata from >=v4.0 still on SD. When this is done with v2.0 Home Menu, a kernelpanic occurs when processing an AM command(it appears a buffer ptr which is then passed to a command was overwritten with 0x0 - of course other SaveData.dat filesizes may result in different behaviour).
| [[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]]
|}

The icon data arrays used with {sd/nand}iconhax were added to SaveData.dat/Launcher.dat with [[4.0.0-7|4.0.0-X]], hence the vulnerable functions were added with that same version.

With <=v4.0 the SaveData.dat buffer is located in the regular heap. It's unknown when exactly it was moved to linearmem, which is where it's located with recent versions. It's located in linearmem for KOR >=v9.6 for example.

The SaveData.dat/Launcher.dat icon vulns were fixed by doing various unsigned >=60/>=360 checks on the loaded values. When these checks fail, it just skips over handling this icon entry. Hence, the original value can't be negative / out-of-bounds any more.

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

2018-08-20T23:25:06Z

Unknown: /* Useless crashes / applications which were fuzzed */ Add worcle worlds

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 its predecessor, Gates to Infinity. When a save file is being prepared to be loaded and read from, only a 0x32000 large buffer is allocated for file reading, and a 0x3e800-large buffer for decompression is also allocated before the file is read. However, the game does not limit the size of the file read to this allocation bound, allowing for the file to overflow into the linear memory heap and into the next allocation. Since Pokemon Super Mystery Dungeon stores allocation memchunks directly before the allocation, overwriting the next memchunk with a corrupted one allows for arbitrary writes of linear heap pointers when the next buffer is allocated or arbitrary writes of any pointer within writable memory when the corrupted buffer is freed.
| None
| O3DS: [[11.3.0-36]]. N3DS: [[11.4.0-37]].
| 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.
| App: v1.1
| [[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.
| App: 3.3.2.
| System: [[11.0.0-33]].
| July 20, 2016
| Around June 26, 2016
| slackerSnail, 12Me12, incvoid
Exploited by MrNbaYoh and [[User:Plutooo|plutoo]].
|-
| The Legend of Zelda: Tri Force Heroes
| [[3DS_System_Flaws#General.2FCTRSDK|CTRSDK]] CTPK buffer overflow combined with game's usage of SpotPass
| During the very first screen displayed by the game during boot("Loading..."), just seconds after title launch, the game loads CTPK from the [[BOSS_Services|stored]] SpotPass content. Hence, this game could be exploited via the vulnerable CTRSDK CTPK code ''if'' one could get custom SpotPass data into extdata somehow(ctr-httpwn >=v1.2 with bosshaxx allows this).

The code for this runs from a thread separate from the main-thread, with the stack in linearmem heap. This SpotPass handling triggers before the game ever opens the regular savedata archive. The extdata is opened at some point before this: it opens a file for checking if it exists, then immediately closes it.

The two SpotPass URLs for this have always(?) returned HTTP 404 as of November 2016. It appears these were intended for use as textures for additional costumes(and never got used publicly), but this wasn't tested.

This is used by [https://github.com/yellows8/ctpkpwn ctpkpwn_tfh].
| None
| App: v2.1.0
| November 18, 2016
| November 14, 2016
| [[User:Yellows8|Yellows8]]
|-
| Pixel Paint
| Buffer overflow via unchecked extdata file length
| Pixel Paint loads pictures saved by the user from extdatas. The file is read to a fixed size buffer but the file length remains unchecked, so with a large enough file, one can overwrite pointers in memory and gain control of the execution flow.
| None
| App: Initial version. System: [[11.2.0-35]].
| December 27, 2016
| November 5, 2016
| [[User:Nba_Yoh|MrNbaYoh]]
|-
| Steel Diver : Sub Wars
| Heap overflow / arbitrary memcpy
| Savefile datas are stored as key/value pairs, a large enough string key makes the game overwrite a memcpy source/destination addresses and size arguments. So one can actually memcpy a rop on the stack and gain control of the execution flow.
| None
| System: [[11.2.0-35]].
| December 27, 2016
| Around July 15, 2016
| [[User:Nba_Yoh|MrNbaYoh]], Vegaroxas
|-
| 1001 Spikes
| Buffer overflow via unchecked array-indexes in XML savefile parsing
| The savefiles are stored as renamed .xml files, which contain several tags with attributes like 'array-index="array-value"', where both of these are converted from ASCII strings to integers as signed-int32, and the array-value given blindly written to an array inside a structure using the (unchecked) index given. With several of these attributes, one can overwrite the stack starting from the stored lr of the function that does this parsing, and write a ROP chain there. Testing used the "LevelAttempts" tag which is the last such tag parsed in that function.
| None
| App: v1.2.0 (TMD v2096)
| December 27, 2016
| Around November 2, 2016
| [[User:Riley|Riley]]
|-
| Pokemon Omega Ruby/Alpha Sapphire
| Secret base team name heap overflow
| When the player wants to edit the team name, it is copied over the heap, however its length is not verified. So with a large enough team name one can overwrite some pointers and get two arbitrary jumps and then get control of the execution flow.
| None
| App: 1.4. System: [[11.2.0-35]].
| December 30, 2016
| June, 2016
| [[User:Nba_Yoh|MrNbaYoh]]
|-
| Swapdoodle
| Heap buffer overflow via unchecked size
| The letter file format used by doodlebomb is composed of multiple chunks. Each chunks is described in the header of the file where the name, size and CRC of each chunk are stored. Some chunks are meant to be headers, every header's size should be 0x80, however the length of the STAHED1 chunk remains unchecked and the game memcpy the chunk to a 0x80 byte buffer with the length provided in the file. This way one is able to overwrite some pointers and get control of the execution flow.
| App: > v1.1.1
| App: v1.1.1
| April 24, 2017
| February, 2017
| [[User:Nba_Yoh|MrNbaYoh]]
|-
| Pokemon Picross
| Arbitrary memcpy via unchecked size
| When reading the savefile, the game handles some lists of buffers that are copied to memory. These buffers should always be 0x14-bytes long but the game uses the size provided in the savefile to copy them. These buffers are copied in some structs and thus with a big enough length value, one can overwrite the next struct which contains a size and a destination address for a memcpy.
| None?
| App: ?
| May 29, 2017
| June, 2016
| [[User:Nba_Yoh|MrNbaYoh]]
|-
| RPG Maker Fes/Player
| Buffer overflow on .bss section
| When loading a project, the game copies multiple chunks over the BSS section. However the number of chunks to copy is not checked, thus a large amount of chunk result in a buffer overflow. There's multiple way to exploit this flaw to gain an arbitrary memcpy or an arbitrary jump.
| None?
| App: ?
| August 28, 2017
| August, 2017
| [[User:Nba_Yoh|MrNbaYoh]]
|-
| RPG Maker Fes/Player
| Buffer overflow via unchecked file size
| When loading a project, the game loads the file to a 0x200000 bytes long buffer. However the size remains unchecked, so with a big enough file one can overflow the buffer and overwrite a thread stack and then achieve ROP.
| None?
| App: ?
| August 29, 2017
| August, 2017
| [[User:Nba_Yoh|MrNbaYoh]]
|-
| Pokemon Omega Ruby/Alpha Sapphire
| PSS data heap/stack overflow
| When launching the game, multiple chunks from the save file are parsed and copied to a large heap buffer. When parsing PSS data (acquaintances, passerby) the game copies each entry to the heap buffer, the number of entries to copy is read from the end of the multiple pss data chunks and is not checked, leading to an overflow. The "PSS data - friends" chunk is vulnerable too, but the overflow occurs on the stack and unfortunately this isn't exploitable because of a 4 bytes uncontrolled value (in each entry) that gets written on sensitive data.
| None
| App: 1.4. System: [[11.6.0]].
| October 1, 2017
| June, 2016
| [[User:Nba_Yoh|MrNbaYoh]]
|-
| RPG Maker Fes/Player
| OOB write
| When handling events in a map, the indices of "buttons" are not checked. This results in an out of bound bit write, one can thus write a rop directly on the stack (bit by bit).
| None?
| App: ?
| August 5, 2018
|
| [[User:Nba_Yoh|MrNbaYoh]]
|}

==Flipnote Studio 3D==

{| class="wikitable" border="1"
|-
! Summary
! Description
! Fixed in app/system version
! Timeframe info related to this was added to wiki
! Flaw discovered by
|-
| KFH frame count overflow
| The KFH frame count field should not be >= 0x3E8, but it wasn't checked and so uncontrolled data were written over pointers, causing an unexploitable crash.
| System: 11.6
| September 20, 2017
| [[User:Nba_Yoh|MrNbaYoh]]
|-
| KMI paper color overflow
| Paper color field (and similar color fields) in KMI chunks was not checked, a too high value caused a jump to an uncontrolled location.
| System: 11.6
| September 20, 2017
| [[User:Nba_Yoh|MrNbaYoh]]
|-
| KSN BGM data size overflow
| The size of the BGM data in the KSN chunk was not checked, it was used in a memcpy so with a big enough size one could overwrite a thread stack on linear mem and achieve ROP (notehax v1).
| System: 11.6
| September 20, 2017
| [[User:Nba_Yoh|MrNbaYoh]]
|-
| KMC chunk unchecked
| The KMC chunk was not verified at all, the CRC32 and the size were not checked. A big enough size caused an integer overflow and made the game read the file backward.
| System: 11.6
| September 20, 2017
| [[User:Nba_Yoh|MrNbaYoh]]
|-
| KMI layer size unchecked
| The 3 layer size fields in KMI chunks were not checked, leading to some crashes in the editor.
| System: 11.6
| September 20, 2017
| [[User:Nba_Yoh|MrNbaYoh]]
|-
| Bad "queue" implementation
| When a KWZ was parsed, frames were copied in a kind of queue, bounds were not checked obviously, so with the KMI layer size flaw one was able to fill completely the queue, then write past the buffer and overwrite a heap chunk header (notehax v2). This is not possible anymore, the queue cannot be filled because layer sizes are checked. Moreover each time an element is removed from the queue, the whole content is memmoved *facepalm*.
| System: 11.6
| September 20, 2017
| [[User:Nba_Yoh|MrNbaYoh]]
|}

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

* [[Pyramids 2 (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. Note that this refers to the regular save file: Tri Force Heroes can be exploited via BOSS extdata - see above.

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

* "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 random data results in a crash

* "Worcle Worlds": Overwriting the savefile with 0xFF results in a crash due to an out of bound read

* "Animal Crossing: New Leaf": Creating a QR code from random data results in a valid QR code and a random design. In some very rare cases(which aren't always reproducible?) a crash/etc may occur, but this isn't known to be useful.

==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]]
|-
| [[Nintendo 3DS Sound]]
| When a .m4a is loaded, the song name is copied to a 256 byte buffer. When the song name begins with a Unicode BOM marker, it memcpy's the tag using the user-provided length. This gives an arbitrary write which can be used to achieve ROP.
| [[11.4.0-37]]
| [[11.4.0-37]]
| June/July 2016
| [[User:nedwill|nedwill]]
|}

=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
|-
| 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]]
|-
| Skater - Bookmark OOB write
| Each bookmark has an id that should not exceed 0x63 (99), however ids are not checked, this results in an OOB write on the stack, but only the value 0x01 can be written.
|
| [[11.6.0-39|11.6.0-39]]
|
| May 21, 2018
| May 20, 2018
| [[User:Nba_Yoh|MrNbaYoh]]
|-
| MicroSD Management - malformed security blob causes stack buffer overflow (mhax)
| The MicroSD Management application's parsing of Windows NTLM security blobs in the SMB/CIFS protocol doesn't verify that the client's specified NT domain name is less than 32 UTF-16 characters. When it's longer, a stack buffer overrun occurs, leading to a ROP chain and complete control of the mcopy application.

The malformed security blob can be sent by an attacker within the SMB_COM_SESSION_SETUP_ANDX (0x73) packet.
| [[11.8.0-41|11.8.0-41]]
| [[11.8.0-41|11.8.0-41]]
| [[9.0.0-20|9.0.0-20]]
| August 12, 2018
| 2018
| smea
|}

==Home Menu==
{| 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
|-
| bossbannerhax
| After successfully loading [[Extended_Banner|extended-banner]] data(done when selecting an icon), Home Menu attempts to load "[[CBMD]]" data into a 0x100000-byte heap buffer from the [[BOSS_Services|stored]] SpotPass content. When successful and the magic-number is CBMD, Home Menu then decompresses the exbanner sections into another fixed-size heap buffer, without checking the outsize at all. The main CBMD CGFX code with ExeFS checks the size, but this code doesn't(however this is exbanner "CBMD", not a "normal" CBMD).

Used with menuhax as of v3.2.
| [[11.3.0-36|11.3.0-X]]
|
| [[1.0.0-0|1.0.0-0]]
| November 18, 2016
| December 23, 2014
| [[User:Yellows8|Yellows8]]
|-
| sdiconhax
| This is basically the same as nandiconhax, the vulnerable SD/NAND functions are ''identical'' minus the file-buffer offsets. Exploitation is different due to different heap-buffer location though. Unlike nandiconhax, the icon buffer for SD is located in linearmem(with recent Home Menu versions at least). This is used by [[menuhax]].
| [[11.1.0-34|11.1.0-X]]
|
| [[4.0.0-7|4.0.0-X]]
| July 27, 2016
| October 23, 2015
| [[User:Yellows8|Yellows8]]
|-
| [[System_SaveData|NAND-savedata]] Launcher.dat icons (nandiconhax)
| 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.'''
| [[11.1.0-34|11.1.0-X]]
|
| [[4.0.0-7|4.0.0-X]]
|
| May 14, 2015
| [[User:Yellows8|Yellows8]]
|-
| 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)
|-
| 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]]
|-
| Extdata file-data loading buffer overflow
| The extdata file-reading code allocates a fixed-size heap buffer for the expected filesize, then reads the filedata into this buffer using the actual FS filesize. Before v5.0 the filesize used here wasn't validated, hence if the filesize is larger than alloc_size a buffer overflow would occur. ''After'' doing the file-read it does validate that the actual_readsize matches the alloc_size, but at this point the buffer overflow has already occurred.

This affected at least the following: SaveData.dat and Cache.dat.

This can be triggered with SaveData.dat by installing a <v4.0 Home Menu version, with Home Menu extdata from >=v4.0 still on SD. When this is done with v2.0 Home Menu, a kernelpanic occurs when processing an AM command(it appears a buffer ptr which is then passed to a command was overwritten with 0x0 - of course other SaveData.dat filesizes may result in different behaviour).
| [[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]]
|}

The icon data arrays used with {sd/nand}iconhax were added to SaveData.dat/Launcher.dat with [[4.0.0-7|4.0.0-X]], hence the vulnerable functions were added with that same version.

With <=v4.0 the SaveData.dat buffer is located in the regular heap. It's unknown when exactly it was moved to linearmem, which is where it's located with recent versions. It's located in linearmem for KOR >=v9.6 for example.

The SaveData.dat/Launcher.dat icon vulns were fixed by doing various unsigned >=60/>=360 checks on the loaded values. When these checks fail, it just skips over handling this icon entry. Hence, the original value can't be negative / out-of-bounds any more.

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

11.8.0-41

2018-07-31T15:29:41Z

Unknown:

The Old3DS+New3DS 11.8.0-41 system update was released on July 30, 2018. This Old3DS+New3DS update was released for the following regions: USA, EUR, JPN, CHN, KOR, and TWN.

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

==Change-log==
[https://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==
<fill this in (manually) later>

=== Process9 ===
Actual code changed in Process9.
pxi:am9 command 0x6d0184 was added.

=== AM ===
New am:net command 0x8290184 was added, this just calls the new pxi:am9 command. This is used by nim.

=== Friends ===
fpdver version string bumped to 0xC

=== nim ===
Added 2 new strings in the codebin: "X-Authentication-Key" and "X-Authentication-Data".

Now uses new am:net command 0x8290184.

==See Also==
System update report(s):
* [https://yls8.mtheall.com/ninupdates/reports.php?date=07-30-18_08-00-36&sys=ctr]
* [https://yls8.mtheall.com/ninupdates/reports.php?date=07-30-18_08-00-40&sys=ktr]

IDBE

2018-07-31T04:04:51Z

Unknown: /* Encryption */

IDBE is Nintendo's title icon database. Entries contain title icon, region, and name (in various languages). Similar to the [[SMDH]]. All game titles are on the server (excluding DSiWare?), including demos and updates.

== URLs ==
<nowiki>https://idbe-ctr.cdn.nintendo.net</nowiki>/icondata/'''%02X'''/'''%016llX'''.idbe

<nowiki>https://idbe-ctr.cdn.nintendo.net</nowiki>/icondata/'''%02X'''/'''%016llX'''-'''%d'''.idbe
'''%02X''' seems to always be 0x10 (?)

'''%016llX''' is the title id.

'''%d''' is an optional title version.
== Encryption ==
The icon database is encrypted with AES-128 CBC. All icons use the same IV and one of 4 possible keys (as specified by the key index in the header).

The IV/keys are hardcoded in the friend list applet. [http://wiiubrew.org/wiki/Nn_idbe.rpl#Encryption They are also on the WiiU].

== Data ==
{| class="wikitable"
| align="center" style="background:#f0f0f0;"|'''Offset'''
| align="center" style="background:#f0f0f0;"|'''Size'''
| align="center" style="background:#f0f0f0;"|'''Description'''
|-
| 0x0||0x1||? (usually zero)
|-
| 0x1||0x1||Key index
|-
| 0x2||0x36D0||Encrypted data
|}
=== Encrypted Data ===
Icon data is uncompressed RGB565.
{| class="wikitable"
| align="center" style="background:#f0f0f0;"|'''Offset'''
| align="center" style="background:#f0f0f0;"|'''Size'''
| align="center" style="background:#f0f0f0;"|'''Description'''
|-
| 0x0||0x20||SHA256 hash
|-
| 0x20||0x10||?
|-
| 0x30||0x4||[[SMDH#Region_Lockout|Region lockout]] (u32 little endian)
|-
| 0x34||0x1C||?
|-
| 0x50 + ''i'' * 0x200||0x200||[[SMDH#Application_Titles|Title struct]] where ''i'' = language index
|-
| 0x2050||0x480||24x24 Icon data
|-
| 0x24D0||0x1200||48x48 Icon data
|}

PTM Services

2018-07-04T08:58:13Z

Unknown: /* SysMenu PTM Service "ptm:sysm" */

A total of 24 sessions can be open for each of these services combined. The commands for each service are handled by the PTM module main() thread.

=User PTM Service "ptm:u" / PTM services=
{| class="wikitable" border="1"
|-
! Command Header
! Description
|-
| 0x00010002
| RegisterAlarmClient
|-
| 0x00020080
| SetRtcAlarm
|-
| 0x00030000
| GetRtcAlarm
|-
| 0x00040000
| CancelRtcAlarm
|-
| 0x00050000
| [[PTM:GetAdapterState|GetAdapterState]]
|-
| 0x00060000
| [[PTM:GetShellState|GetShellState]]
|-
| 0x00070000
| [[PTM:GetBatteryLevel|GetBatteryLevel]]
|-
| 0x00080000
| [[PTM:GetBatteryChargeState|GetBatteryChargeState]]
|-
| 0x00090000
| [[PTM:GetPedometerState|GetPedometerState]]
|-
| 0x000A0042
| GetStepHistoryEntry
|-
| 0x000B00C2
| [[PTM:GetStepHistory|GetStepHistory]]
|-
| 0x000C0000
| [[PTM:GetTotalStepCount|GetTotalStepCount]]
|-
| 0x000D0040
| SetPedometerRecordingMode
|-
| 0x000E0000
| GetPedometerRecordingMode
|-
| 0x000F0084
| GetStepHistoryAll
|}

The above commands are available for all PTM services, except the SetSystemTime service.

=PlayHistory PTM Service "ptm:play" =
{| class="wikitable" border="1"
|-
! Command Header
! Description
|-
| 0x08070082
| [[PTM:GetPlayHistory|GetPlayHistory]]
|-
| 0x08080000
| GetPlayHistoryStart
|-
| 0x08090000
| GetPlayHistoryLength
|-
| 0x080B0080
| CalcPlayHistoryStart
|}

=SystemControl PTM Service "ptm:s"=
Identical to the below "ptm:sysm"

=SysMenu PTM Service "ptm:sysm"=
{| class="wikitable" border="1"
|-
! Command Header
! Description
|-
| 0x040100C0
| SetRtcAlarmEx
|-
| 0x04020042
| ReplySleepQuery
|-
| 0x04030042
| NotifySleepPreparationComplete
|-
| 0x04040102
| SetWakeupTrigger
|-
| 0x04050000
| GetAwakeReason
|-
| 0x04060000
| RequestSleep
|-
| 0x040700C0
| [[PTM:ShutdownAsync|ShutdownAsync]]
|-
| 0x04080000
| Awake
|-
| 0x04090080
| [[PTMSYSM:LaunchFIRMRebootSystem|RebootAsync]]
|-
| 0x040A0000
| [[PTMSYSM:CheckNew3DS|CheckNew3DS]] (Added with [[8.0.0-18]])
|-
| 0x08010640
| [[PTMSYSM:SetInfoLEDPattern|SetInfoLEDPattern]] (These 4 LED commands are used for the notification LED, see [[MCU]] regarding boot fail with invalid parameters)
|-
| 0x08020040
| [[PTMSYSM:SetInfoLEDPatternHeader|SetInfoLEDPatternHeader]]
|-
| 0x08030000
| [[PTMSYSM:GetInfoLEDStatus|GetInfoLEDStatus]]
|-
| 0x08040040
| [[PTMSYSM:SetBatteryEmptyLEDPattern|SetBatteryEmptyLEDPattern]]
|-
| 0x08050000
| ClearStepHistory
|-
| 0x080600C2
| SetStepHistory
|-
| 0x08070082
| [[PTM:GetPlayHistory|GetPlayHistory]]
|-
| 0x08080000
| GetPlayHistoryStart
|-
| 0x08090000
| GetPlayHistoryLength
|-
| 0x080A0000
| ClearPlayHistory
|-
| 0x080B0080
| CalcPlayHistoryStart
|-
| 0x080C0080
| SetUserTime
|-
| 0x080D0000
| InvalidateSystemTime
|-
| 0x080E0140
| [[PTMSYSM:NotifyPlayEvent|NotifyPlayEvent]]
|-
| 0x080F0000
| [[PTMSYSM:GetSoftwareClosedFlag|GetSoftwareClosedFlag]]
|-
| 0x08100000
| [[PTMSYSM:ClearSoftwareClosedFlag|ClearSoftwareClosedFlag]]
|-
| 0x08110000
| GetShellStatus
|-
| 0x08120000
| IsShutdownByBatteryEmpty
|-
| 0x08130000
| FormatSavedata
|-
| 0x08140000
| GetLegacyJumpProhibitedFlag
|-
| 0x08150040
| SetPlayHistoryRecordingMode
|-
| 0x0816....
| Abstraction for mcu::RTC::GetSystemClock
|-
| 0x0817....
| Abstraction for mcu::RTC::SetSystemClock
|-
| 0x08180040
| [[PTMSYSM:ConfigureNew3DSCPU|ConfigureNew3DSCPU]]
|-
|}

=GetSystemTime PTM Service "ptm:gets"=
{| class="wikitable" border="1"
|-
! Command Header
! Description
|-
| 0x04010000
| GetSystemTime
|-
|}

=SetSystemTime PTM Service "ptm:sets"=
{| class="wikitable" border="1"
|-
! Command Header
! Description
|-
| 0x00010080
| SetSystemTime
|-
|}

=PTM [[System_SaveData]]=
During system boot PTM attempts to open the PTM savedata, if this fails it will repeatedly keep trying to open the archive. When opening the archive is failing due to savedata corruption, PTM eventually(during system boot) deletes the savedata then creates it again.

Savedata contents:
* "/Pedometer.dat"
* "/PlayHistory.dat" Filesize is 0xD5DE8.

==PlayHistory.dat==
{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
|-
| 0x0
| 0x4
| Start entry index.
|-
| 0x4
| 0x4
| Total PlayHistory entries.
|-
| 0x8
| 0xD5DE0
| 0x11D28 PlayHistory entries, 0xC-bytes each.
|}

===PlayHistory entry===
{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
|-
| 0x0
| 0x8
| u64 programID
|-
| 0x8
| 0x4
| u32, probably timestamp.
|}

MVDSTD:SetConfig

2018-06-30T14:53:41Z

Unknown: /* Request */ Fix Index

=Request=
{| class="wikitable" border="1"
|-
! Index Word
! Description
|-
| 0
| Header code [0x001E0044]
|-
| 1
| Size, normally 0x11C.
|-
| 2
| Value 0x0
|-
| 3
| KProcess handle
|-
| 4
| (Size<<4) <nowiki>|</nowiki> 10
|-
| 5
| Input data ptr (see [[MVDSTD:GetConfig|here]])
|}

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

MVD Services

2018-06-30T12:26:57Z

Unknown: /* MVD Service "l2b:u" */

This is for using the MVD hardware video decoder(unknown whether MVD can do more than decoding) + hardware color-format converter. The [[New_3DS]] [[Internet Browser]] uses mvd:STD for video decoding + YUV2RGB for decoded MJPEG frames.

See [[Internet_Browser|here]] for the supported hardware decoder video codecs.

There can only be one service session open at a time for each individual MVD service.

==MVD Service "mvd:STD"==
{| class="wikitable" border="1"
|-
! Command Header
! Available since system version
! Description
! Used by [[Internet_Browser|SKATER]]
|-
| 0x00010082
| [[8.1.0-0_New3DS]]
| [[MVDSTD:Initialize|Initialize]]
| Yes
|-
| 0x00020000
| [[8.1.0-0_New3DS]]
| [[MVDSTD:Shutdown|Shutdown]]
| Yes
|-
| 0x00030300
| [[8.1.0-0_New3DS]]
| [[MVDSTD:CalculateWorkBufSize|CalculateWorkBufSize]]
| Yes
|-
| 0x000400C0
| [[8.1.0-0_New3DS]]
| [[MVDSTD:CalculateImageSize|CalculateImageSize]]
| No
|-
| 0x00050100
| [[8.1.0-0_New3DS]]
| (s8 unk0, s8 unk1, s8 unk2, u32 unk3) SKATER uses hard-coded value 0 for all of these params. Using different input data for this doesn't seem to affect video-processing output.
| Yes
|-
| 0x00060000
| [[8.1.0-0_New3DS]]
| Unknown.
| No
|-
| 0x00070000
| [[8.1.0-0_New3DS]]
| Used during shutdown with video-processing.
| Yes
|-
| 0x00080142
| [[8.1.0-0_New3DS]]
| [[MVDSTD:ProcessNALUnit|ProcessNALUnit]]
| Yes
|-
| 0x00090042
| [[8.1.0-0_New3DS]]
| [[MVDSTD:ControlFrameRendering|ControlFrameRendering]]
| Yes
|-
| 0x000A0000
| [[8.1.0-0_New3DS]]
| [[MVDSTD:GetStatus|GetStatus]]
| Yes
|-
| 0x000B0000
| [[8.1.0-0_New3DS]]
| GetStatusOther(unknown what this is used for). Same output size as [[MVDSTD:GetStatus|GetStatus]].
| No
|-
| 0x000C0100
| [[8.1.0-0_New3DS]]
| (u8 unk0, s8 unk1, u32 unk2, u32 unk3) Unknown.
| No
|-
| 0x000D0000
| [[8.1.0-0_New3DS]]
| Unknown.
| No
|-
| 0x000E0202
| [[8.1.0-0_New3DS]]
| Unknown. The code for this appears to be similar to [[MVDSTD:ProcessNALUnit|ProcessNALUnit]], this DMAs data from the input buffer as well.
| No
|-
| 0x000F0042
| [[8.1.0-0_New3DS]]
| (s8 unk, val0, handle) Unknown. Presumably the command 0x000E0202 version of [[MVDSTD:ControlFrameRendering]].
| No
|-
| 0x00100000
| [[8.1.0-0_New3DS]]
| Unknown. This writes 0x28-bytes of output starting at cmdreply[2].
| No
|-
| 0x00110000
| [[8.1.0-0_New3DS]]
| Unknown.
| No
|-
| 0x001200C0
| [[8.1.0-0_New3DS]]
| (s8 unk0, u32 unk1, u32 unk2) Unknown.
| No
|-
| 0x00130000
| [[8.1.0-0_New3DS]]
| Unknown.
| No
|-
| 0x001400C2
| [[8.1.0-0_New3DS]]
| Unknown. The code for this appears to be similar to [[MVDSTD:ProcessNALUnit|ProcessNALUnit]], this DMAs data from the input buffer as well.
| No
|-
| 0x00150042
| [[8.1.0-0_New3DS]]
| (s8 unk, val0, handle) Unknown. Presumably the command 0x001400C2 version of [[MVDSTD:ControlFrameRendering]].
| No
|-
| 0x00160000
| [[8.1.0-0_New3DS]]
| Unknown.
| No
|-
| 0x00170000
| [[8.1.0-0_New3DS]]
| Unknown.
| No
|-
| 0x00180000
| [[8.1.0-0_New3DS]]
| Unknown. Used during initialization regardless of the operation mode(color-conversion/video-processing).
| Yes
|-
| 0x00190000
| [[8.1.0-0_New3DS]]
| Unknown. Used during shutdown regardless of the operation mode(color-conversion/video-processing).
| Yes
|-
| 0x001A0000
| [[8.1.0-0_New3DS]]
| Used when doing color-format conversion. This triggers writing to the output buffer specified via config.
| Yes
|-
| 0x001B0040
| [[8.1.0-0_New3DS]]
| (u8 inval) Used during video-processing initialization. SKATER uses hard-coded value 1 for this. MVD-sysmodule checks that the input value is not 0 or higher than 11. The input value must be one of the following: 1, 6, 9, or 10. Using any of these values instead of 1 results in no data being written to the output buffer with normal video processing, without any errors being thrown.
| Yes
|-
| 0x001C0000
| [[8.1.0-0_New3DS]]
| Used during shutdown with video-processing.
| Yes
|-
| 0x001D0042
| [[8.1.0-0_New3DS]]
| [[MVDSTD:GetConfig|GetConfig]]
| Yes
|-
| 0x001E0044
| [[8.1.0-0_New3DS]]
| [[MVDSTD:SetConfig|SetConfig]]
| Yes
|-
| 0x001F0902
| [[8.1.0-0_New3DS]]
| [[MVDSTD:SetupOutputBuffers|SetupOutputBuffers]]
| No
|-
| 0x00200002
| [[8.1.0-0_New3DS]]
| (val0, handle) Unknown. This loads data from the table entry which has a field matching a certain value. This is the global table used by [[MVDSTD:SetupOutputBuffers|SetupOutputBuffers]].
| No
|-
| 0x00210100
| [[8.1.0-0_New3DS]]
| [[MVDSTD:OverrideOutputBuffers|OverrideOutputBuffers]]
| No
|}

This one uses the I/O mapped @ 0x10207000.

This service is used by the [[New_3DS]] [[Internet Browser]]. SKATER runs the entire MVD initialization/shutdown each time the video player is entered/exited.

Linear-memory vaddrs passed to this service should be in the 0x30* region, MVD-sysmodule doesn't support the 0x14* region.

By default MVD does(?) various post-processing with the output image, this is controlled by the [[MVDSTD:GetConfig|configuration]]. This post-processing isn't done at all in certain cases.

Initialization procedures:
* Color-conversion: Use command [[MVDSTD:Initialize]] with bufsize=1, then command 0x00180000.
* H.264: If needed, use [[MVDSTD:CalculateWorkBufSize]]. Then use [[MVDSTD:Initialize]]. Then use commands 0x00050100, 0x00180000, and 0x001B0040. Then use [[MVDSTD:ProcessNALUnit]] for each of the individual NAL-unit parameter sets("Sequence Parameter Set" and "Picture Parameter Set"), with the main video processing starting afterwards.

Shutdown procedures:
* Color-conversion: just use command 0x00190000, then [[MVDSTD:Shutdown]].
* H.264: Use command 0x00090042 in a loop, waiting for it to return a retval that isn't 0x00017002. Then use commands 0x001C0000, 0x00190000, and 0x00070000. Then use [[MVDSTD:Shutdown]].

===MVDSTD configuration structure===
{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
|-
| 0x0
| 0x4
| Input format type, see below.
|-
| 0x4
| 0x4
| The default for this is 0x0. Must be <=5. When non-zero, the type value at offset 0x0 must be one of the following: 0x00020001, 0x00010001, 0x00010005, 0x00010006, or 0x00010007. Doesn't seem to have any visible affect on the output for video processing.
|-
| 0x8
| 0x4
| The default for this is 0x0. This must be <=1. Referred to as "H264 range" in SKATER. When 0x1 the output image is brighter than normal.
|-
| 0x0C
| 0x4
| Input video width. Must be >=width_min and <width_max. This must be aligned: the low <dimensions_alignment>-bits must be clear.
|-
|-
| 0x10
| 0x4
| Input video height. Must be >=height_min and <height_max. This must be aligned: the low <dimensions_alignment>-bits must be clear.
|-
| 0x14
| 0x4
| Input data physical address, only set for color-conversion. This isn't used when the value at offset 0x4 is 0x1 or 0x5.
|-
| 0x18
| 0x4
| Physical data address, only used for color-conversion when the type value has bitmask 0x20000 set. This isn't used when the value at offset 0x4 is 0x1 or 0x5.
|-
| 0x1C
| 0x4
| Physical data address, only used for color-conversion when the type value is 0x20000. This isn't used when the value at offset 0x4 is 0x1 or 0x5.
|-
| 0x20
| 0x4
| Physical data address, for color-conversion. This isn't used when the value at offset 0x4 is 0x0 or 0x4.
|-
| 0x24
| 0x4
| Physical data address, only used for color-conversion when the type value has bitmask 0x20000 set. This isn't used when the value at offset 0x4 is 0x0 or 0x4.
|-
| 0x28
| 0x4
| Unknown. Doesn't seem to have any visible affect on the output.
|-
| 0x2C
| 0x4
| When non-zero this enables some sort of color adjustment for the output?
|-
| 0x30
| 0x4
| Same affect as offset 0x2C? This must not be enabled at the same time as that field.
|-
| 0x34
| 0x4
| Unknown, must be <8 for video-processing? Doesn't seem to have any visible affect on the output.
|-
| 0x38
| 0x4
| Unknown. Doesn't seem to have any visible affect on the output.
|-
| 0x3C
| 0x4
| Unknown, must be <8 for video-processing? Doesn't seem to have any visible affect on the output.
|-
| 0x40
| 0x4
| When non-zero this enables usage of the 4 words starting at offset 0x44. SKATER sets this to 0x0 for color-conversion, and 0x1 for video processing(this flag isn't mandatory for the latter).
|-
| 0x44
| 0x4
| See offset 0x40. The default for this is 0x0. u32 input_crop_x_pos. Must be <=widthval. Where widthval = <width value from the field at offset 0xC>. The low 4-bits of this value must be clear.
|-
| 0x48
| 0x4
| See offset 0x40. The default for this is 0x0. u32 input_crop_y_pos. Must be <=heightval. Where heightval = <height value from the field at offset 0x10>. The low 4-bits of this value must be clear.
|-
| 0x4C
| 0x4
| See offset 0x40. u32 input_crop_height. Must be >=16 and <=heightval. Where heightval = <height value from the field at offset 0x10>. The low 3-bits of this value must be clear.
|-
| 0x50
| 0x4
| See offset 0x40. u32 input_crop_width. Must be >=width_min and <=widthval. Where widthval = <width value from the field at offset 0xC>. The low 3-bits of this value must be clear.
|-
| 0x54
| 0x4
| The default for this is 0x0. Must be <=5. For video processing, and when this value is non-zero, the type value at offset 0x0 must not be any of the following: 0x00010004, 0x00010001, 0x0x00100001, or 0x00200001. For video processing, the type value at offset 0x0 must not be 0x80000 when this value at offset 0x54 is non-zero.
|-
| 0x58
| 0x4
| Output format type, see below. SKATER writes value 0x40002 here.
|-
| 0x5C
| 0x4
| Output video width. Must be >=16, and must be <somewidth_statefield.
|-
| 0x60
| 0x4
| Output video height. Must be >=16, and must be <someheight_statefield.
|-
| 0x64
| 0x4
| Output data physical address.
|-
| 0x68
| 0x4
| Additional output data physical address. This is only used when the output format type is value 0x00020001.
|-
| 0x6C
| 0x4
| Unknown, doesn't seem to have a visible affect on the output. Must be <3 for video-processing?
|-
| 0x70
| 0x4
| Unknown, doesn't seem to have a visible affect on the output.
|-
| 0x74
| 0x4
| Unknown, doesn't seem to have a visible affect on the output.
|-
| 0x78
| 0x4
| Unknown, doesn't seem to have a visible affect on the output.
|-
| 0x7C
| 0x4
| Unknown, doesn't seem to have a visible affect on the output.
|-
| 0x80
| 0x4
| Unknown. Must be <=1 for video processing? Doesn't seem to have a visible affect on the output.
|-
| 0x84
| 0x4
| Unknown, doesn't seem to have a visible affect on the output.
|-
| 0x88
| 0x4
| Unknown, doesn't seem to have a visible affect on the output.
|-
| 0x8C
| 0x4
| Unknown, doesn't seem to have a visible affect on the output.
|-
| 0x90
| 0x4
| Unknown, doesn't seem to have a visible affect on the output.
|-
| 0x94
| 0x4
| Unknown, doesn't seem to have a visible affect on the output.
|-
| 0x98
| 0x4
| Unknown, doesn't seem to have a visible affect on the output.
|-
| 0x9C
| 0x4
| Unknown, doesn't seem to have a visible affect on the output.
|-
| 0xA0
| 0x4
| Unknown, doesn't seem to have a visible affect on the output.
|-
| 0xA4
| 0x4
| Unknown, doesn't seem to have a visible affect on the output.
|-
| 0xA8
| 0x4
| Unknown, doesn't seem to have a visible affect on the output.
|-
| 0xAC
| 0x4
| Unknown, must be zero for video-processing.
|-
| 0xB0
| 0x28
| Unknown, doesn't seem to have a visible affect on the output.
|-
| 0xD8
| 0x4
| Unknown, must be zero for video-processing.
|-
| 0xDC
| 0x28
| Unknown, doesn't seem to have a visible affect on the output.
|-
| 0x104
| 0x4
| This flag enables using the following 4 words when non-zero.
|-
| 0x108
| 0x4
| u32 output_x_pos. Output X position in the output buffer.
|-
| 0x10C
| 0x4
| u32 output_y_pos. Same as above except for the Y pos.
|-
| 0x110
| 0x4
| u32 output_width_override. The low 2-bits must be clear. When the output width is less than this, this value is used to align the output image width to the specified value via value0-pixels. When this value is less than the output width, this value is used for the output width instead.
|-
| 0x114
| 0x4
| Same as the field at offset 0x110 except for the output height.
|-
| 0x118
| 0x4
| Unknown, when non-zero it seems the output buffer isn't written any more?
|}

The size of this structure is fixed to 0x11C-bytes. The user process does the LINEAR-mem vaddr->physaddr conversion for the above physaddrs, when modifying the config struct before using [[MVDSTD:SetConfig]]. For the above physaddrs that are checked/used, the physaddr must not be 0x0, and the physaddr must be 8-byte aligned(low 3-bits clear).

For color-conversion, the output frame is split into two images via the two output physaddrs.

For *_min/*_max/dimensions_alignment mentioned above: *_min = 16 for color-conversion, 48 for video processing. *_max = 2048 for color-conversion, 4672 for video processing. dimensions_alignment = 4 for color-conversion, 3 for video processing.

The configuration doesn't seem to change at all while SKATER is running video processing(each [[MVDSTD:SetConfig]] input config appears to the same).

====SKATER video processing config====
When processing video, SKATER [[MVDSTD:GetConfig|gets]] the config, updates all of the fields listed below, then uses [[MVDSTD:SetConfig]].

{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
! Written value
|-
| 0x0
| 0x4
| Input format type.
| 0x00020001(H.264), hard-coded.
|-
| 0x8
| 0x4
|
| Loaded from unique input state. This is the 'range' field in the following debug print: "H264 w=%d h=%d range=%d pics=%d multi=%d\n".
|-
| 0xC
| 0x4
| Input video width.
| Loaded from unique input state.
|-
| 0x10
| 0x4
| Input video height.
| Loaded from unique input state.
|-
| 0x40
| 0x4
| Flag
| 0x1, hard-coded.
|-
| 0x44
| 0x4
|
| Loaded from unique input state.
|-
| 0x48
| 0x4
|
| Loaded from unique input state.
|-
| 0x4C
| 0x4
|
| Loaded from unique input state.
|-
| 0x50
| 0x4
|
| Loaded from unique input state.
|-
| 0x54
| 0x4
|
| 0x0, hard-coded.
|-
| 0x58
| 0x4
| Output format type.
| Loaded from unique input state.
|-
| 0x5C
| 0x4
| Output video width.
| Loaded from unique input state.
|-
| 0x60
| 0x4
| Output video height.
| Loaded from unique input state.
|-
| 0x64
| 0x4
| Output data physical address.
|
|-
| 0x68
| 0x4
| Output data physical address, only set for color-conversion.
| 0x0, hard-coded.
|-
| 0xA8
| 0x4
|
| 0x1, hard-coded.
|-
| 0xAC
| 0x4
|
| 0x0, hard-coded.
|-
| 0xD8
| 0x4
|
| 0x0, hard-coded.
|-
| 0x104
| 0x4
|
| 0x1, hard-coded.
|-
| 0x108
| 0x4
|
| Loaded from unique input state.
|-
| 0x10C
| 0x4
|
| Loaded from unique input state.
|-
| 0x110
| 0x4
|
| Loaded from unique input state.
|-
| 0x114
| 0x4
|
| Loaded from unique input state.
|-
| 0x118
| 0x4
|
| 0x0, hard-coded.
|}

"Loaded from unique input state" refers to the field being loaded from state seperate from the other fields used for this configuration structure.

====Input formats====
{| class="wikitable" border="1"
|-
! Type value
! Mode
! Description
|-
| 0x00010001
| Color conversion
| yuyv422
|-
| 0x00010002
| Video processing
| ?
|-
| 0x00010004
| Video processing
| ?
|-
| 0x00010005
| Color conversion
| ?
|-
| 0x00010006
| Color conversion
| ?
|-
| 0x00010007
| Color conversion
| ?
|-
| 0x00020000
| Color conversion
| ?
|-
| 0x00020001
| Video processing
| H.264
|-
| 0x00020002
| ?
| ?
|-
| 0x00080000
| Video processing
| Same as 0x00020001, except with gray-scale?
|-
| 0x00080001
| Video processing
| ?
|-
| 0x00180001
| Video processing
| ?
|}

====Output formats====
{| class="wikitable" border="1"
|-
! Type value
! Description
|-
| 0x00010001
| See the input format type.
|-
| 0x00010005
| Unknown. A certain MVD state field must not be set to 0x8170 in order to use this. Some sort of 2-byte format it seems.
|-
| 0x00010006
| Unknown, see 0x00010005 for the usage requirement. Some sort of 2-byte format it seems.
|-
| 0x00010007
| Unknown, see 0x00010005 for the usage requirement. Some sort of 2-byte format it seems.
|-
| 0x00010008
| A certain MVD-module state field must not be set to 0x8170 in order to use this. Whether this can actually be used is determined by another MVD-module state field. 16bit format.
|-
| 0x00010009
| Unknown, see 0x00010008 for the usage requirements. Some non-2-byte format it seems.
|-
| 0x0001000A
| Unknown, see 0x00010008 for the usage requirements. Some non-2-byte format it seems.
|-
| 0x0001000B
| Unknown, see 0x00010008 for the usage requirements. Some non-2-byte format it seems.
|-
| 0x00020001
| Some sort of YUV format? 12bit format. The initial output is written to the normal output buffer, then the rest is written to the additional output buffer dedicated to this out-type.
|-
| 0x00040000
| Unknown, doesn't write anything to the out-buffer when doing color-conversion.
|-
| 0x00040001
| Unknown 2-byte format.
|-
| 0x00040002
| BGR565
|-
| 0x00040003
| Some sort of 2-byte format it seems?
|-
| 0x00040004
| RGB565
|-
| 0x00041000
| Unknown, doesn't write anything to the out-buffer when doing color-conversion.
|-
| 0x00041001
| y400a?
|-
| 0x00041002
| y400a?
|}

==MVD Service "l2b:u"==
This one uses the I/O mapped @ 0x10130000.
{| class="wikitable" border="1"
|-
! Command Header
! Description
|-
| 0x00010040
| SetInputFormat?
|-
| 0x00020080
| GetInputFormat?
|-
| 0x00030040
| SetOutputFormat
|-
| 0x00040080
| GetOutputFormat
|-
| 0x00050040
| SetTransferEndInterrupt
|-
| 0x00060080
| GetTransferEndInterrupt
|-
| 0x00070080
| GetL2BEndEvent
|-
| 0x00080102
| ?
|-
| 0x00090080
| Waits on a DMA Handle
|-
| 0x000A0102
| MaybeSetRecieving
|-
| 0x000B0080
| isDoneRecieving
|-
| 0x000C0040
| SetInputLineWidth
|-
| 0x000D0080
| GetInputLineWidth
|-
| 0x000E0040
| SetInputLines
|-
| 0x000F0080
| GetInputLines
|-
| 0x00100040
| MaybeSetAlpha
|-
| 0x00110080
| MaybeGetAlpha
|-
| 0x00120040
| StartConversion
|-
| 0x00130040
| StopConversion
|-
| 0x00140080
| isBusyConversion
|-
| 0x00150040
| SetPackageParameter
|-
| 0x00160080
| GetPackageParameter
|-
| 0x00170080
| PingProcess
|}

==MVD Service "l2b2:u"==
This uses the same command-handler as "l2b:u".

==MVD Service "y2r2:u"==
This is a exact copy of y2r camera service and hence named y2r2.

==MVD Result-codes==
{| class="wikitable" border="1"
|-
! Result-code
! Internal MVD status-code
! Description
|-
| 0xD961710F
|
| Invalid [[MVDSTD:GetConfig|configuration]], mainly when setting the config.
|-
| 0xD96170CA
| -2(~1)
|
|-
| 0xE16170C9
| -1(~0)
|
|-
| 0xF96171C8
| -0xFB(~0xFA)
|
|-
| 0x17000
| 0x0
| OK
|-
| 0x17001
| 0x1
| Returned after processing NAL-unit parameter-sets.
|-
| 0x17002
| 0x2
| Busy. When returned by command 0x00090042 during video processing, SKATER uses the {[[MVDSTD:GetConfig]], [[MVDSTD:SetConfig]], and 0x00090042} commands again(same config as before). The SKATER code for this includes this debug string: "H264 output %lld us corrected to %lld us\n".
|-
| 0x17003
| 0x3
|
|-
| 0x17004
| 0x4
| Returned when not all of the input NAL-unit buffer was processed.
|-
| 0x17005
| 0x5
|
|-
| 0x17006
| 0x6
|
|-
| 0x17007
| 0x7
|
|-
| 0x17038
|
|
|}

==Supported H.264 Levels and Profiles==
{| class="wikitable" border="1"
|-
! Level
! Baseline
! Main
! High
! High 10 (High10, High10p, Hi10p or 10-bit H.264)
! High 4:2:2 (High422p or High422)
! High 4:4:4 Predictive (Hi444PP)
|-
| 1
| Yes
| Yes
| Yes
| Yes
| Untested
| Untested
|-
| 1b
| Yes
| Yes
| Yes
| Yes
| Untested
| Untested
|-
| 1.1
| Yes
| Yes
| Yes
| Yes
| Untested
| Untested
|-
| 1.2
| Yes
| Yes
| Yes
| Yes
| Untested
| Untested
|-
| 1.3
| Yes
| Yes
| Yes
| Yes
| Untested
| Untested
|-
| 2
| Yes
| Yes
| Yes
| Yes
| Untested
| Untested
|-
| 2.1
| Yes
| Yes
| Yes
| Yes
| Untested
| Untested
|-
| 2.2
| Yes
| Yes
| Yes
| Yes
| Untested
| Untested
|-
| 3
| Yes
| Yes
| Yes
| Yes
| Untested
| Untested
|-
| 3.1
| Yes
| Yes
| Yes
| Yes
| Untested
| Untested
|-
| 3.2
| Yes
| Yes
| Yes
| Yes
| Untested
| Untested
|-
| 4
| No (untested)
| No (untested)
| No (untested)
| No (untested)
| No (untested)
| No (untested)
|-
| 4.1
| No (untested)
| No (untested)
| No (untested)
| No (untested)
| No (untested)
| No (untested)
|-
| 4.2
| No (untested)
| No (untested)
| No (untested)
| No (untested)
| No (untested)
| No (untested)
|-
| 5
| No (untested)
| No (untested)
| No (untested)
| No (untested)
| No (untested)
| No (untested)
|-
| 5.1
| No (untested)
| No (untested)
| No (untested)
| No (untested)
| No (untested)
| No (untested)
|-
| 5.2
| No (untested)
| No (untested)
| No (untested)
| No (untested)
| No (untested)
| No (untested)
|}
created using the New 3DS Internet Browser, New 3DS Internet Browser Specs and the following test pages: 
[http://mtheall.com/~mtheall/pie/baseline.html Baseline Profile Test] 
[http://mtheall.com/~mtheall/pie/main.html Main Profile Test] 
[http://mtheall.com/~mtheall/pie/high.html High Profile Test] 
[http://mtheall.com/~mtheall/pie/high10.html High10 Profile Test]

MVD Services

2018-06-30T05:00:21Z

Unknown: /* MVD Service "y2r2:u" */ Mention that y2r2 is a copy of y2r service

This is for using the MVD hardware video decoder(unknown whether MVD can do more than decoding) + hardware color-format converter. The [[New_3DS]] [[Internet Browser]] uses mvd:STD for video decoding + YUV2RGB for decoded MJPEG frames.

See [[Internet_Browser|here]] for the supported hardware decoder video codecs.

There can only be one service session open at a time for each individual MVD service.

==MVD Service "mvd:STD"==
{| class="wikitable" border="1"
|-
! Command Header
! Available since system version
! Description
! Used by [[Internet_Browser|SKATER]]
|-
| 0x00010082
| [[8.1.0-0_New3DS]]
| [[MVDSTD:Initialize|Initialize]]
| Yes
|-
| 0x00020000
| [[8.1.0-0_New3DS]]
| [[MVDSTD:Shutdown|Shutdown]]
| Yes
|-
| 0x00030300
| [[8.1.0-0_New3DS]]
| [[MVDSTD:CalculateWorkBufSize|CalculateWorkBufSize]]
| Yes
|-
| 0x000400C0
| [[8.1.0-0_New3DS]]
| [[MVDSTD:CalculateImageSize|CalculateImageSize]]
| No
|-
| 0x00050100
| [[8.1.0-0_New3DS]]
| (s8 unk0, s8 unk1, s8 unk2, u32 unk3) SKATER uses hard-coded value 0 for all of these params. Using different input data for this doesn't seem to affect video-processing output.
| Yes
|-
| 0x00060000
| [[8.1.0-0_New3DS]]
| Unknown.
| No
|-
| 0x00070000
| [[8.1.0-0_New3DS]]
| Used during shutdown with video-processing.
| Yes
|-
| 0x00080142
| [[8.1.0-0_New3DS]]
| [[MVDSTD:ProcessNALUnit|ProcessNALUnit]]
| Yes
|-
| 0x00090042
| [[8.1.0-0_New3DS]]
| [[MVDSTD:ControlFrameRendering|ControlFrameRendering]]
| Yes
|-
| 0x000A0000
| [[8.1.0-0_New3DS]]
| [[MVDSTD:GetStatus|GetStatus]]
| Yes
|-
| 0x000B0000
| [[8.1.0-0_New3DS]]
| GetStatusOther(unknown what this is used for). Same output size as [[MVDSTD:GetStatus|GetStatus]].
| No
|-
| 0x000C0100
| [[8.1.0-0_New3DS]]
| (u8 unk0, s8 unk1, u32 unk2, u32 unk3) Unknown.
| No
|-
| 0x000D0000
| [[8.1.0-0_New3DS]]
| Unknown.
| No
|-
| 0x000E0202
| [[8.1.0-0_New3DS]]
| Unknown. The code for this appears to be similar to [[MVDSTD:ProcessNALUnit|ProcessNALUnit]], this DMAs data from the input buffer as well.
| No
|-
| 0x000F0042
| [[8.1.0-0_New3DS]]
| (s8 unk, val0, handle) Unknown. Presumably the command 0x000E0202 version of [[MVDSTD:ControlFrameRendering]].
| No
|-
| 0x00100000
| [[8.1.0-0_New3DS]]
| Unknown. This writes 0x28-bytes of output starting at cmdreply[2].
| No
|-
| 0x00110000
| [[8.1.0-0_New3DS]]
| Unknown.
| No
|-
| 0x001200C0
| [[8.1.0-0_New3DS]]
| (s8 unk0, u32 unk1, u32 unk2) Unknown.
| No
|-
| 0x00130000
| [[8.1.0-0_New3DS]]
| Unknown.
| No
|-
| 0x001400C2
| [[8.1.0-0_New3DS]]
| Unknown. The code for this appears to be similar to [[MVDSTD:ProcessNALUnit|ProcessNALUnit]], this DMAs data from the input buffer as well.
| No
|-
| 0x00150042
| [[8.1.0-0_New3DS]]
| (s8 unk, val0, handle) Unknown. Presumably the command 0x001400C2 version of [[MVDSTD:ControlFrameRendering]].
| No
|-
| 0x00160000
| [[8.1.0-0_New3DS]]
| Unknown.
| No
|-
| 0x00170000
| [[8.1.0-0_New3DS]]
| Unknown.
| No
|-
| 0x00180000
| [[8.1.0-0_New3DS]]
| Unknown. Used during initialization regardless of the operation mode(color-conversion/video-processing).
| Yes
|-
| 0x00190000
| [[8.1.0-0_New3DS]]
| Unknown. Used during shutdown regardless of the operation mode(color-conversion/video-processing).
| Yes
|-
| 0x001A0000
| [[8.1.0-0_New3DS]]
| Used when doing color-format conversion. This triggers writing to the output buffer specified via config.
| Yes
|-
| 0x001B0040
| [[8.1.0-0_New3DS]]
| (u8 inval) Used during video-processing initialization. SKATER uses hard-coded value 1 for this. MVD-sysmodule checks that the input value is not 0 or higher than 11. The input value must be one of the following: 1, 6, 9, or 10. Using any of these values instead of 1 results in no data being written to the output buffer with normal video processing, without any errors being thrown.
| Yes
|-
| 0x001C0000
| [[8.1.0-0_New3DS]]
| Used during shutdown with video-processing.
| Yes
|-
| 0x001D0042
| [[8.1.0-0_New3DS]]
| [[MVDSTD:GetConfig|GetConfig]]
| Yes
|-
| 0x001E0044
| [[8.1.0-0_New3DS]]
| [[MVDSTD:SetConfig|SetConfig]]
| Yes
|-
| 0x001F0902
| [[8.1.0-0_New3DS]]
| [[MVDSTD:SetupOutputBuffers|SetupOutputBuffers]]
| No
|-
| 0x00200002
| [[8.1.0-0_New3DS]]
| (val0, handle) Unknown. This loads data from the table entry which has a field matching a certain value. This is the global table used by [[MVDSTD:SetupOutputBuffers|SetupOutputBuffers]].
| No
|-
| 0x00210100
| [[8.1.0-0_New3DS]]
| [[MVDSTD:OverrideOutputBuffers|OverrideOutputBuffers]]
| No
|}

This one uses the I/O mapped @ 0x10207000.

This service is used by the [[New_3DS]] [[Internet Browser]]. SKATER runs the entire MVD initialization/shutdown each time the video player is entered/exited.

Linear-memory vaddrs passed to this service should be in the 0x30* region, MVD-sysmodule doesn't support the 0x14* region.

By default MVD does(?) various post-processing with the output image, this is controlled by the [[MVDSTD:GetConfig|configuration]]. This post-processing isn't done at all in certain cases.

Initialization procedures:
* Color-conversion: Use command [[MVDSTD:Initialize]] with bufsize=1, then command 0x00180000.
* H.264: If needed, use [[MVDSTD:CalculateWorkBufSize]]. Then use [[MVDSTD:Initialize]]. Then use commands 0x00050100, 0x00180000, and 0x001B0040. Then use [[MVDSTD:ProcessNALUnit]] for each of the individual NAL-unit parameter sets("Sequence Parameter Set" and "Picture Parameter Set"), with the main video processing starting afterwards.

Shutdown procedures:
* Color-conversion: just use command 0x00190000, then [[MVDSTD:Shutdown]].
* H.264: Use command 0x00090042 in a loop, waiting for it to return a retval that isn't 0x00017002. Then use commands 0x001C0000, 0x00190000, and 0x00070000. Then use [[MVDSTD:Shutdown]].

===MVDSTD configuration structure===
{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
|-
| 0x0
| 0x4
| Input format type, see below.
|-
| 0x4
| 0x4
| The default for this is 0x0. Must be <=5. When non-zero, the type value at offset 0x0 must be one of the following: 0x00020001, 0x00010001, 0x00010005, 0x00010006, or 0x00010007. Doesn't seem to have any visible affect on the output for video processing.
|-
| 0x8
| 0x4
| The default for this is 0x0. This must be <=1. Referred to as "H264 range" in SKATER. When 0x1 the output image is brighter than normal.
|-
| 0x0C
| 0x4
| Input video width. Must be >=width_min and <width_max. This must be aligned: the low <dimensions_alignment>-bits must be clear.
|-
|-
| 0x10
| 0x4
| Input video height. Must be >=height_min and <height_max. This must be aligned: the low <dimensions_alignment>-bits must be clear.
|-
| 0x14
| 0x4
| Input data physical address, only set for color-conversion. This isn't used when the value at offset 0x4 is 0x1 or 0x5.
|-
| 0x18
| 0x4
| Physical data address, only used for color-conversion when the type value has bitmask 0x20000 set. This isn't used when the value at offset 0x4 is 0x1 or 0x5.
|-
| 0x1C
| 0x4
| Physical data address, only used for color-conversion when the type value is 0x20000. This isn't used when the value at offset 0x4 is 0x1 or 0x5.
|-
| 0x20
| 0x4
| Physical data address, for color-conversion. This isn't used when the value at offset 0x4 is 0x0 or 0x4.
|-
| 0x24
| 0x4
| Physical data address, only used for color-conversion when the type value has bitmask 0x20000 set. This isn't used when the value at offset 0x4 is 0x0 or 0x4.
|-
| 0x28
| 0x4
| Unknown. Doesn't seem to have any visible affect on the output.
|-
| 0x2C
| 0x4
| When non-zero this enables some sort of color adjustment for the output?
|-
| 0x30
| 0x4
| Same affect as offset 0x2C? This must not be enabled at the same time as that field.
|-
| 0x34
| 0x4
| Unknown, must be <8 for video-processing? Doesn't seem to have any visible affect on the output.
|-
| 0x38
| 0x4
| Unknown. Doesn't seem to have any visible affect on the output.
|-
| 0x3C
| 0x4
| Unknown, must be <8 for video-processing? Doesn't seem to have any visible affect on the output.
|-
| 0x40
| 0x4
| When non-zero this enables usage of the 4 words starting at offset 0x44. SKATER sets this to 0x0 for color-conversion, and 0x1 for video processing(this flag isn't mandatory for the latter).
|-
| 0x44
| 0x4
| See offset 0x40. The default for this is 0x0. u32 input_crop_x_pos. Must be <=widthval. Where widthval = <width value from the field at offset 0xC>. The low 4-bits of this value must be clear.
|-
| 0x48
| 0x4
| See offset 0x40. The default for this is 0x0. u32 input_crop_y_pos. Must be <=heightval. Where heightval = <height value from the field at offset 0x10>. The low 4-bits of this value must be clear.
|-
| 0x4C
| 0x4
| See offset 0x40. u32 input_crop_height. Must be >=16 and <=heightval. Where heightval = <height value from the field at offset 0x10>. The low 3-bits of this value must be clear.
|-
| 0x50
| 0x4
| See offset 0x40. u32 input_crop_width. Must be >=width_min and <=widthval. Where widthval = <width value from the field at offset 0xC>. The low 3-bits of this value must be clear.
|-
| 0x54
| 0x4
| The default for this is 0x0. Must be <=5. For video processing, and when this value is non-zero, the type value at offset 0x0 must not be any of the following: 0x00010004, 0x00010001, 0x0x00100001, or 0x00200001. For video processing, the type value at offset 0x0 must not be 0x80000 when this value at offset 0x54 is non-zero.
|-
| 0x58
| 0x4
| Output format type, see below. SKATER writes value 0x40002 here.
|-
| 0x5C
| 0x4
| Output video width. Must be >=16, and must be <somewidth_statefield.
|-
| 0x60
| 0x4
| Output video height. Must be >=16, and must be <someheight_statefield.
|-
| 0x64
| 0x4
| Output data physical address.
|-
| 0x68
| 0x4
| Additional output data physical address. This is only used when the output format type is value 0x00020001.
|-
| 0x6C
| 0x4
| Unknown, doesn't seem to have a visible affect on the output. Must be <3 for video-processing?
|-
| 0x70
| 0x4
| Unknown, doesn't seem to have a visible affect on the output.
|-
| 0x74
| 0x4
| Unknown, doesn't seem to have a visible affect on the output.
|-
| 0x78
| 0x4
| Unknown, doesn't seem to have a visible affect on the output.
|-
| 0x7C
| 0x4
| Unknown, doesn't seem to have a visible affect on the output.
|-
| 0x80
| 0x4
| Unknown. Must be <=1 for video processing? Doesn't seem to have a visible affect on the output.
|-
| 0x84
| 0x4
| Unknown, doesn't seem to have a visible affect on the output.
|-
| 0x88
| 0x4
| Unknown, doesn't seem to have a visible affect on the output.
|-
| 0x8C
| 0x4
| Unknown, doesn't seem to have a visible affect on the output.
|-
| 0x90
| 0x4
| Unknown, doesn't seem to have a visible affect on the output.
|-
| 0x94
| 0x4
| Unknown, doesn't seem to have a visible affect on the output.
|-
| 0x98
| 0x4
| Unknown, doesn't seem to have a visible affect on the output.
|-
| 0x9C
| 0x4
| Unknown, doesn't seem to have a visible affect on the output.
|-
| 0xA0
| 0x4
| Unknown, doesn't seem to have a visible affect on the output.
|-
| 0xA4
| 0x4
| Unknown, doesn't seem to have a visible affect on the output.
|-
| 0xA8
| 0x4
| Unknown, doesn't seem to have a visible affect on the output.
|-
| 0xAC
| 0x4
| Unknown, must be zero for video-processing.
|-
| 0xB0
| 0x28
| Unknown, doesn't seem to have a visible affect on the output.
|-
| 0xD8
| 0x4
| Unknown, must be zero for video-processing.
|-
| 0xDC
| 0x28
| Unknown, doesn't seem to have a visible affect on the output.
|-
| 0x104
| 0x4
| This flag enables using the following 4 words when non-zero.
|-
| 0x108
| 0x4
| u32 output_x_pos. Output X position in the output buffer.
|-
| 0x10C
| 0x4
| u32 output_y_pos. Same as above except for the Y pos.
|-
| 0x110
| 0x4
| u32 output_width_override. The low 2-bits must be clear. When the output width is less than this, this value is used to align the output image width to the specified value via value0-pixels. When this value is less than the output width, this value is used for the output width instead.
|-
| 0x114
| 0x4
| Same as the field at offset 0x110 except for the output height.
|-
| 0x118
| 0x4
| Unknown, when non-zero it seems the output buffer isn't written any more?
|}

The size of this structure is fixed to 0x11C-bytes. The user process does the LINEAR-mem vaddr->physaddr conversion for the above physaddrs, when modifying the config struct before using [[MVDSTD:SetConfig]]. For the above physaddrs that are checked/used, the physaddr must not be 0x0, and the physaddr must be 8-byte aligned(low 3-bits clear).

For color-conversion, the output frame is split into two images via the two output physaddrs.

For *_min/*_max/dimensions_alignment mentioned above: *_min = 16 for color-conversion, 48 for video processing. *_max = 2048 for color-conversion, 4672 for video processing. dimensions_alignment = 4 for color-conversion, 3 for video processing.

The configuration doesn't seem to change at all while SKATER is running video processing(each [[MVDSTD:SetConfig]] input config appears to the same).

====SKATER video processing config====
When processing video, SKATER [[MVDSTD:GetConfig|gets]] the config, updates all of the fields listed below, then uses [[MVDSTD:SetConfig]].

{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
! Written value
|-
| 0x0
| 0x4
| Input format type.
| 0x00020001(H.264), hard-coded.
|-
| 0x8
| 0x4
|
| Loaded from unique input state. This is the 'range' field in the following debug print: "H264 w=%d h=%d range=%d pics=%d multi=%d\n".
|-
| 0xC
| 0x4
| Input video width.
| Loaded from unique input state.
|-
| 0x10
| 0x4
| Input video height.
| Loaded from unique input state.
|-
| 0x40
| 0x4
| Flag
| 0x1, hard-coded.
|-
| 0x44
| 0x4
|
| Loaded from unique input state.
|-
| 0x48
| 0x4
|
| Loaded from unique input state.
|-
| 0x4C
| 0x4
|
| Loaded from unique input state.
|-
| 0x50
| 0x4
|
| Loaded from unique input state.
|-
| 0x54
| 0x4
|
| 0x0, hard-coded.
|-
| 0x58
| 0x4
| Output format type.
| Loaded from unique input state.
|-
| 0x5C
| 0x4
| Output video width.
| Loaded from unique input state.
|-
| 0x60
| 0x4
| Output video height.
| Loaded from unique input state.
|-
| 0x64
| 0x4
| Output data physical address.
|
|-
| 0x68
| 0x4
| Output data physical address, only set for color-conversion.
| 0x0, hard-coded.
|-
| 0xA8
| 0x4
|
| 0x1, hard-coded.
|-
| 0xAC
| 0x4
|
| 0x0, hard-coded.
|-
| 0xD8
| 0x4
|
| 0x0, hard-coded.
|-
| 0x104
| 0x4
|
| 0x1, hard-coded.
|-
| 0x108
| 0x4
|
| Loaded from unique input state.
|-
| 0x10C
| 0x4
|
| Loaded from unique input state.
|-
| 0x110
| 0x4
|
| Loaded from unique input state.
|-
| 0x114
| 0x4
|
| Loaded from unique input state.
|-
| 0x118
| 0x4
|
| 0x0, hard-coded.
|}

"Loaded from unique input state" refers to the field being loaded from state seperate from the other fields used for this configuration structure.

====Input formats====
{| class="wikitable" border="1"
|-
! Type value
! Mode
! Description
|-
| 0x00010001
| Color conversion
| yuyv422
|-
| 0x00010002
| Video processing
| ?
|-
| 0x00010004
| Video processing
| ?
|-
| 0x00010005
| Color conversion
| ?
|-
| 0x00010006
| Color conversion
| ?
|-
| 0x00010007
| Color conversion
| ?
|-
| 0x00020000
| Color conversion
| ?
|-
| 0x00020001
| Video processing
| H.264
|-
| 0x00020002
| ?
| ?
|-
| 0x00080000
| Video processing
| Same as 0x00020001, except with gray-scale?
|-
| 0x00080001
| Video processing
| ?
|-
| 0x00180001
| Video processing
| ?
|}

====Output formats====
{| class="wikitable" border="1"
|-
! Type value
! Description
|-
| 0x00010001
| See the input format type.
|-
| 0x00010005
| Unknown. A certain MVD state field must not be set to 0x8170 in order to use this. Some sort of 2-byte format it seems.
|-
| 0x00010006
| Unknown, see 0x00010005 for the usage requirement. Some sort of 2-byte format it seems.
|-
| 0x00010007
| Unknown, see 0x00010005 for the usage requirement. Some sort of 2-byte format it seems.
|-
| 0x00010008
| A certain MVD-module state field must not be set to 0x8170 in order to use this. Whether this can actually be used is determined by another MVD-module state field. 16bit format.
|-
| 0x00010009
| Unknown, see 0x00010008 for the usage requirements. Some non-2-byte format it seems.
|-
| 0x0001000A
| Unknown, see 0x00010008 for the usage requirements. Some non-2-byte format it seems.
|-
| 0x0001000B
| Unknown, see 0x00010008 for the usage requirements. Some non-2-byte format it seems.
|-
| 0x00020001
| Some sort of YUV format? 12bit format. The initial output is written to the normal output buffer, then the rest is written to the additional output buffer dedicated to this out-type.
|-
| 0x00040000
| Unknown, doesn't write anything to the out-buffer when doing color-conversion.
|-
| 0x00040001
| Unknown 2-byte format.
|-
| 0x00040002
| BGR565
|-
| 0x00040003
| Some sort of 2-byte format it seems?
|-
| 0x00040004
| RGB565
|-
| 0x00041000
| Unknown, doesn't write anything to the out-buffer when doing color-conversion.
|-
| 0x00041001
| y400a?
|-
| 0x00041002
| y400a?
|}

==MVD Service "l2b:u"==
This one uses the I/O mapped @ 0x10130000.

==MVD Service "l2b2:u"==
This uses the same command-handler as "l2b:u".

==MVD Service "y2r2:u"==
This is a exact copy of y2r camera service and hence named y2r2.

==MVD Result-codes==
{| class="wikitable" border="1"
|-
! Result-code
! Internal MVD status-code
! Description
|-
| 0xD961710F
|
| Invalid [[MVDSTD:GetConfig|configuration]], mainly when setting the config.
|-
| 0xD96170CA
| -2(~1)
|
|-
| 0xE16170C9
| -1(~0)
|
|-
| 0xF96171C8
| -0xFB(~0xFA)
|
|-
| 0x17000
| 0x0
| OK
|-
| 0x17001
| 0x1
| Returned after processing NAL-unit parameter-sets.
|-
| 0x17002
| 0x2
| Busy. When returned by command 0x00090042 during video processing, SKATER uses the {[[MVDSTD:GetConfig]], [[MVDSTD:SetConfig]], and 0x00090042} commands again(same config as before). The SKATER code for this includes this debug string: "H264 output %lld us corrected to %lld us\n".
|-
| 0x17003
| 0x3
|
|-
| 0x17004
| 0x4
| Returned when not all of the input NAL-unit buffer was processed.
|-
| 0x17005
| 0x5
|
|-
| 0x17006
| 0x6
|
|-
| 0x17007
| 0x7
|
|-
| 0x17038
|
|
|}

==Supported H.264 Levels and Profiles==
{| class="wikitable" border="1"
|-
! Level
! Baseline
! Main
! High
! High 10 (High10, High10p, Hi10p or 10-bit H.264)
! High 4:2:2 (High422p or High422)
! High 4:4:4 Predictive (Hi444PP)
|-
| 1
| Yes
| Yes
| Yes
| Yes
| Untested
| Untested
|-
| 1b
| Yes
| Yes
| Yes
| Yes
| Untested
| Untested
|-
| 1.1
| Yes
| Yes
| Yes
| Yes
| Untested
| Untested
|-
| 1.2
| Yes
| Yes
| Yes
| Yes
| Untested
| Untested
|-
| 1.3
| Yes
| Yes
| Yes
| Yes
| Untested
| Untested
|-
| 2
| Yes
| Yes
| Yes
| Yes
| Untested
| Untested
|-
| 2.1
| Yes
| Yes
| Yes
| Yes
| Untested
| Untested
|-
| 2.2
| Yes
| Yes
| Yes
| Yes
| Untested
| Untested
|-
| 3
| Yes
| Yes
| Yes
| Yes
| Untested
| Untested
|-
| 3.1
| Yes
| Yes
| Yes
| Yes
| Untested
| Untested
|-
| 3.2
| Yes
| Yes
| Yes
| Yes
| Untested
| Untested
|-
| 4
| No (untested)
| No (untested)
| No (untested)
| No (untested)
| No (untested)
| No (untested)
|-
| 4.1
| No (untested)
| No (untested)
| No (untested)
| No (untested)
| No (untested)
| No (untested)
|-
| 4.2
| No (untested)
| No (untested)
| No (untested)
| No (untested)
| No (untested)
| No (untested)
|-
| 5
| No (untested)
| No (untested)
| No (untested)
| No (untested)
| No (untested)
| No (untested)
|-
| 5.1
| No (untested)
| No (untested)
| No (untested)
| No (untested)
| No (untested)
| No (untested)
|-
| 5.2
| No (untested)
| No (untested)
| No (untested)
| No (untested)
| No (untested)
| No (untested)
|}
created using the New 3DS Internet Browser, New 3DS Internet Browser Specs and the following test pages: 
[http://mtheall.com/~mtheall/pie/baseline.html Baseline Profile Test] 
[http://mtheall.com/~mtheall/pie/main.html Main Profile Test] 
[http://mtheall.com/~mtheall/pie/high.html High Profile Test] 
[http://mtheall.com/~mtheall/pie/high10.html High10 Profile Test]

ARM11 Interrupts

2018-06-29T08:15:41Z

Unknown: /* Hardware Interrupts */

== Interrupts ==

Interrupt priority is 0-0xF. A priority of 0xF means that the interrupt is disabled.

= Private Interrupts =

Each CPU core has 32 software interrupts that are private and belong to that core. These interrupts are numbers 0-0x1F for each core. The hardware interrupts are not core-specific and start at interrupt ID 0x20.

{| class="wikitable" border="1"
! IRQ
! Listener
! Description
|-
| 0-0x3
|
| MPCore software-interrupt. Not configured.
|-
| 0x4
| Kernel
| MPCore software-interrupt. Used to manage the performance counter.
|-
| 0x5
| Kernel
| MPCore software-interrupt. Does apparently nothing.
|-
| 0x6
| Kernel
| MPCore software-interrupt. Extensively used by [[SVC|KernelSetState]] (and contains most of the actual code of the latter).
|-
| 0x7
| Kernel
| MPCore software-interrupt. See [[KCacheMaintenanceInterruptEvent]]
|-
| 0x8
| Kernel
| MPCore software-interrupt. Used for scheduling.
|-
| 0x9
| Kernel
| MPCore software-interrupt. Used when handling exceptions that require termination of a thread or a process, and in some cases by svcSetDebugThreadContext, to store VFP registers in the thread's register storage.
|-
| 0xA
| Kernel
| TLB operations interrupt, see [[KTLBOperationsInterruptEvent]]
|-
| 0xB-0xE
|
| MPCore software-interrupt. Not configured.
|-
| 0xF
| dmnt/debugger
| MPCore software-interrupt. Used to abstract FIQ (debug). This interrupt is never sent to core2 nor core3 on N3DS.
|-
| 0x1D
| Kernel
| MPCore timer.
|-
| 0x1E
| Kernel
| MPCore watchdog - set when the watchdog counter reaches 0 in timer mode, causes interrupt 30 to set as pending. Only set on core 1 as core 1's timer is used for everything.
|}

= Hardware Interrupts =

There are 0x60 hardware interrupts starting at 0x20 and continuing up to 0x7F. These are not private and are accessible from any core.

{| class="wikitable" border="1"
! IRQ
! Listener
! Description
|-
| 0x28
| gsp, TwlBg
| PSC0
|-
| 0x29
| gsp, TwlBg
| PSC1
|-
| 0x2A
| gsp, TwlBg
| PDC0 (VBlank0)
|-
| 0x2B
| gsp, TwlBg
| PDC1 (VBlank1)
|-
| 0x2C
| gsp, TwlBg
| PPF
|-
| 0x2D
| gsp, TwlBg
| P3D
|-
| 0x30
| Kernel
| ?
|-
| 0x39
| Kernel
| DMA
|-
| 0x3A
| Kernel
| DMA
|-
| 0x3B
| Kernel
| DMA
|-
| 0x40
| nwm
| WIFI SDIO Controller @ 0x10122000
|-
| 0x41
| nwm
| ?
|-
| 0x42
| nwm_dev?
| WIFI SDIO Controller @ 0x10100000
|-
| 0x45
| mvd (New3DS)
| ?
|-
| 0x46
| mvd (New3DS)
| ?
|-
| 0x48
| camera
| ?
|-
| 0x49
| camera
| ?
|-
| 0x4A
| dsp
| ?
|-
| 0x4B
| camera
| Y2R Conversion Finished
|-
| 0x4C
| TwlBg
| ?
|-
| 0x4D
| TwlBg
| ?
|-
| 0x4E
| mvd (New3DS)
| Y2R2 End Event
|-
| 0x4F
| mvd (New3DS)
| Related to mvd services
|-
| 0x50
| pxi, TwlBg
| Sync
|-
| 0x51
| pxi, TwlBg
| ?
|-
| 0x52
| pxi, TwlBg
| Send Fifo Empty
|-
| 0x53
| pxi, TwlBg
| Receive Fifo Not Empty
|-
| 0x54
| i2c, TwlBg
| I2C Bus0 work done
|-
| 0x55
| i2c, TwlBg
| I2C Bus1 work done
|-
| 0x56
| spi, TwlBg
| ?
|-
| 0x57
| spi, TwlBg
| ?
|-
| 0x58
| Kernel
| PDN
|-
| 0x59
| TwlBg
| ?
|-
| 0x5A
| mic
| ?
|-
| 0x5C
| i2c, TwlBg
| I2C Bus2 work done
|-
| 0x60
| gpio, TwlBg
| Shell opened
|-
| 0x62
| gpio, TwlBg
| Shell closed
|-
| 0x63
| gpio, TwlBg
| Touchscreen
|-
| 0x64
| gpio, TwlBg
| Headphone jack plugged in/out
|-
| 0x66
| gpio, TwlBg
| ?
|-
| 0x68
| gpio, TwlBg
| IR
|-
| 0x69
| gpio, TwlBg
| ?
|-
| 0x6A
| gpio, TwlBg
| ?
|-
| 0x6B
| gpio, TwlBg
| ?
|-
| 0x6C
| gpio, TwlBg
| ?
|-
| 0x6D
| gpio, TwlBg
| ?
|-
| 0x6E
| gpio, TwlBg
| ?
|-
| 0x6F
| gpio, TwlBg
| ?
|-
| 0x70
| gpio, TwlBg
| ?
|-
| 0x71
| gpio, TwlBg
| MCU (HOME/POWER pressed/released or WiFi switch pressed)
|-
| 0x72
| gpio, TwlBg
| ?
|-
| 0x73
| TwlBg
| ?
|-
| 0x74
| ?
| Gamecard related
|-
| 0x75
| ?
| Gamecard inserted
|-
| 0x78 to 0x7B
| Kernel
| Core 0-3 Performance monitor counter (any) overflow
|-
| 0x7A to 0x82 (PDN_MPCORE_CFG bit2 set) or
0x7C to 0x84 (bit2 clear)
| Kernel
| ?
|}
(interrupts from 0x80 and up can't be mapped in available builds of the kernel)

There are 2 tables in the ARM11 kernel: the first has 32 * 2(or 32 * 4) 8-byte entries. This table is for the private interrupts that belong to each core. The data for each interrupt can be found by doing table_base + (core_num * 0x100) + (intr_num * 8). The second table is for public hardware interrupts and the data for each interrupt can be retrieved by doing table_base + (intr_num * 8).

= InterruptData =
{| class="wikitable" border="1"
|-
! Offset
! Type
! Description
|-
| 0x0
| [[KBaseInterruptEvent]] *
| Pointer to the KBaseInterruptEvent object for this interrupt
|-
| 0x4
| u8
| Interrupt will be disabled by the IRQ handler as soon as it is acknowledged.
Ignored for FIQ: the FIQ handler always sets bit2 of [[PDN_Registers#PDN_FIQ_CNT|PDN_FIQ_CNT]]
|-
| 0x5
| u8
| Interrupt is disabled
|-
| 0x6
| u8
| Interrupt priority
|-
| 0x7
| u8
| Unused, alignment
|}

= Interrupt Table (New3DS) =
(0xFFF318F4 in 10.3)

{| class="wikitable" border="1"
! Offset
! Type
! Description
|-
| 0x0
| InterruptData[224]
| Data for all hardware and software interrupts
|-
| 0x700
| [[KObjectMutex]]
| Mutex
|}

Corelink DMA Engines

2018-06-29T08:13:30Z

Unknown: /* CDMA Peripheral IDs */

XDMA cannot access the ARM9 bootrom at all.

==DmaConfig==
Size of struct is 24 bytes.

struct DmaConfig {
sint8_t channel_sel; // @0 Selects which DMA channel to use: 0-7, -1 = don't care.
uint8_t endian_swap_size; // @1 Accepted values: 0=none, 2=16bit, 4=32bit, 8=64bit.
uint8_t flags; // @2 bit0: SRC_IS_PERIPHERAL, bit1: DST_IS_PERIPHERAL, bit2: SHALL_BLOCK, bit3: KEEP_ALIVE, bit6: SRC_IS_RAM, bit7: DST_IS_RAM
uint8_t padding;
DmaSubConfig dst_cfg;
DmaSubConfig src_cfg;
}

struct DmaSubConfig {
sint8_t peripheral_id; // @0 If not *_IS_RAM set, this must be < 0x1E.
uint8_t allowed_burst_sizes; // @1 Accepted values: 4, 8, 4|8 = 12, 1|2|4|8 = 15
sint16_t gather_granule_size; // @2
sint16_t gather_stride; // @4 Has to be >= 0, must not be 0 if peripheral_id == 0xFF.
sint16_t scatter_granule_size; // @6
sint16_t scatter_stride; // @8 Can be negative.
}

If SRC_IS_PERIPHERAL/SRC_IS_PERIPHERAL is set in the flags field, the configuration for src/dst is loaded from src_cfg/dst_cfg respectively and the transfer will be done from/to a fixed address. If the *_IS_RAM flag is set same thing goes, except byte0 of each cfg is forced to 0xFF (RAM) and the transfer will be done from/to an incrementing address. *_IS_RAM has priority over _IS_PERIPHERAL.

If neither *_IS_PERIPHERAL or *_IS_RAM is set, default configuration is loaded:

.peripheral_id = 0xFF,
.allowed_burst_sizes = 1 | 2 | 4 | 8,
.gather_granule_size = 0x80,
.gather_stride = 0,
.scatter_granule_size = 0x80,
.scatter_stride = 0,

If SHALL_BLOCK is set, the thread will sleep until the DMA engine is ready. If not set, the SVC will return 0xD04007F0 if the DMA channel is busy.

The generated bytecode starts with a FLUSHP on the peripheral_ids for src/dst (if specified). After that, it always moves 0 into DAR. Then it moves the src/dst addresses into SAR/DAR respectively...

== CDMA Peripheral IDs ==

{| class="wikitable" border="1"
! ID
! Module
! Description
|-
| 0x2
| camera (cam)
| Camera Port 1
|-
| 0x3
| camera (cam)
| Camera Port 2
|-
| 0x4
| nwm
| ?
|-
| 0x5
| nwm
| ?
|-
| 0x6
| camera (y2r)
| SetSendingY
|-
| 0x7
| camera (y2r)
| SetSendingU
|-
| 0x8
| camera (y2r)
| SetSendingV
|-
| 0x9
| camera (y2r)
| SetSendingYUYV
|-
| 0xA
| camera (y2r)
| SetReceiving
|-
| 0xB
| fs
| HASH
|-
| 0xD
| TwlBg
| LGYFB0/1
|-
| 0xE
| TwlBg
| LGYFB0/1
|-
| 0x12
| mvd (y2r2)
| SetSendingY
|-
| 0x13
| mvd (y2r2)
| SetSendingU
|-
| 0x14
| mvd (y2r2)
| SetSendingV
|-
| 0x15
| mvd (y2r2)
| SetSendingYUV
|-
| 0x16
| mvd (y2r2)
| SetReceiving
|-
| 0x17
| mvd
| Related to l2b
|-
| 0x18
| mvd
| Related to l2b
|-
| 0x19
| mvd
| Related to l2b
|-
| 0x1A
| mvd
| Related to l2b
|}

== XDMA Peripheral IDs ==

{| class="wikitable" border="1"
! ID
! Module
! Description
|-
| 0
| Process9
| CTRCARD
|-
| 7
| Process9
| SHA
|-
|}

Corelink DMA Engines

2018-06-29T01:37:30Z

Unknown: /* CDMA Peripheral IDs */ 0x14 is related to y2r2

XDMA cannot access the ARM9 bootrom at all.

==DmaConfig==
Size of struct is 24 bytes.

struct DmaConfig {
sint8_t channel_sel; // @0 Selects which DMA channel to use: 0-7, -1 = don't care.
uint8_t endian_swap_size; // @1 Accepted values: 0=none, 2=16bit, 4=32bit, 8=64bit.
uint8_t flags; // @2 bit0: SRC_IS_PERIPHERAL, bit1: DST_IS_PERIPHERAL, bit2: SHALL_BLOCK, bit3: KEEP_ALIVE, bit6: SRC_IS_RAM, bit7: DST_IS_RAM
uint8_t padding;
DmaSubConfig dst_cfg;
DmaSubConfig src_cfg;
}

struct DmaSubConfig {
sint8_t peripheral_id; // @0 If not *_IS_RAM set, this must be < 0x1E.
uint8_t allowed_burst_sizes; // @1 Accepted values: 4, 8, 4|8 = 12, 1|2|4|8 = 15
sint16_t gather_granule_size; // @2
sint16_t gather_stride; // @4 Has to be >= 0, must not be 0 if peripheral_id == 0xFF.
sint16_t scatter_granule_size; // @6
sint16_t scatter_stride; // @8 Can be negative.
}

If SRC_IS_PERIPHERAL/SRC_IS_PERIPHERAL is set in the flags field, the configuration for src/dst is loaded from src_cfg/dst_cfg respectively and the transfer will be done from/to a fixed address. If the *_IS_RAM flag is set same thing goes, except byte0 of each cfg is forced to 0xFF (RAM) and the transfer will be done from/to an incrementing address. *_IS_RAM has priority over _IS_PERIPHERAL.

If neither *_IS_PERIPHERAL or *_IS_RAM is set, default configuration is loaded:

.peripheral_id = 0xFF,
.allowed_burst_sizes = 1 | 2 | 4 | 8,
.gather_granule_size = 0x80,
.gather_stride = 0,
.scatter_granule_size = 0x80,
.scatter_stride = 0,

If SHALL_BLOCK is set, the thread will sleep until the DMA engine is ready. If not set, the SVC will return 0xD04007F0 if the DMA channel is busy.

The generated bytecode starts with a FLUSHP on the peripheral_ids for src/dst (if specified). After that, it always moves 0 into DAR. Then it moves the src/dst addresses into SAR/DAR respectively...

== CDMA Peripheral IDs ==

{| class="wikitable" border="1"
! ID
! Module
! Description
|-
| 0x2
| camera (cam)
| Camera Port 1
|-
| 0x3
| camera (cam)
| Camera Port 2
|-
| 0x4
| nwm
| ?
|-
| 0x5
| nwm
| ?
|-
| 0x6
| camera (y2r)
| SetSendingY
|-
| 0x7
| camera (y2r)
| SetSendingU
|-
| 0x8
| camera (y2r)
| SetSendingV
|-
| 0x9
| camera (y2r)
| SetSendingYUYV
|-
| 0xA
| camera (y2r)
| SetReceiving
|-
| 0xB
| fs
| HASH
|-
| 0xD
| TwlBg
| LGYFB0/1
|-
| 0xE
| TwlBg
| LGYFB0/1
|-
| 0x12
| mvd
| Related to y2r2
|-
| 0x13
| mvd
| Related to y2r2
|-
| 0x14
| mvd
| Related to y2r2
|-
| 0x15
| mvd
| Related to y2r2
|-
| 0x16
| mvd
| Related to y2r2
|-
| 0x17
| mvd
| Related to l2b
|-
| 0x18
| mvd
| Related to l2b
|-
| 0x19
| mvd
| Related to l2b
|-
| 0x1A
| mvd
| Related to l2b
|}

== XDMA Peripheral IDs ==

{| class="wikitable" border="1"
! ID
! Module
! Description
|-
| 0
| Process9
| CTRCARD
|-
| 7
| Process9
| SHA
|-
|}

Corelink DMA Engines

2018-06-29T01:09:00Z

Unknown: /* CDMA Peripheral IDs */

XDMA cannot access the ARM9 bootrom at all.

==DmaConfig==
Size of struct is 24 bytes.

struct DmaConfig {
sint8_t channel_sel; // @0 Selects which DMA channel to use: 0-7, -1 = don't care.
uint8_t endian_swap_size; // @1 Accepted values: 0=none, 2=16bit, 4=32bit, 8=64bit.
uint8_t flags; // @2 bit0: SRC_IS_PERIPHERAL, bit1: DST_IS_PERIPHERAL, bit2: SHALL_BLOCK, bit3: KEEP_ALIVE, bit6: SRC_IS_RAM, bit7: DST_IS_RAM
uint8_t padding;
DmaSubConfig dst_cfg;
DmaSubConfig src_cfg;
}

struct DmaSubConfig {
sint8_t peripheral_id; // @0 If not *_IS_RAM set, this must be < 0x1E.
uint8_t allowed_burst_sizes; // @1 Accepted values: 4, 8, 4|8 = 12, 1|2|4|8 = 15
sint16_t gather_granule_size; // @2
sint16_t gather_stride; // @4 Has to be >= 0, must not be 0 if peripheral_id == 0xFF.
sint16_t scatter_granule_size; // @6
sint16_t scatter_stride; // @8 Can be negative.
}

If SRC_IS_PERIPHERAL/SRC_IS_PERIPHERAL is set in the flags field, the configuration for src/dst is loaded from src_cfg/dst_cfg respectively and the transfer will be done from/to a fixed address. If the *_IS_RAM flag is set same thing goes, except byte0 of each cfg is forced to 0xFF (RAM) and the transfer will be done from/to an incrementing address. *_IS_RAM has priority over _IS_PERIPHERAL.

If neither *_IS_PERIPHERAL or *_IS_RAM is set, default configuration is loaded:

.peripheral_id = 0xFF,
.allowed_burst_sizes = 1 | 2 | 4 | 8,
.gather_granule_size = 0x80,
.gather_stride = 0,
.scatter_granule_size = 0x80,
.scatter_stride = 0,

If SHALL_BLOCK is set, the thread will sleep until the DMA engine is ready. If not set, the SVC will return 0xD04007F0 if the DMA channel is busy.

The generated bytecode starts with a FLUSHP on the peripheral_ids for src/dst (if specified). After that, it always moves 0 into DAR. Then it moves the src/dst addresses into SAR/DAR respectively...

== CDMA Peripheral IDs ==

{| class="wikitable" border="1"
! ID
! Module
! Description
|-
| 0x2
| camera (cam)
| Camera Port 1
|-
| 0x3
| camera (cam)
| Camera Port 2
|-
| 0x4
| nwm
| ?
|-
| 0x5
| nwm
| ?
|-
| 0x6
| camera (y2r)
| SetSendingY
|-
| 0x7
| camera (y2r)
| SetSendingU
|-
| 0x8
| camera (y2r)
| SetSendingV
|-
| 0x9
| camera (y2r)
| SetSendingYUYV
|-
| 0xA
| camera (y2r)
| SetReceiving
|-
| 0xB
| fs
| HASH
|-
| 0xD
| TwlBg
| LGYFB0/1
|-
| 0xE
| TwlBg
| LGYFB0/1
|-
| 0x12
| mvd
| Related to y2r2
|-
| 0x13
| mvd
| Related to y2r2
|-
| 0x14
| mvd
| ?
|-
| 0x15
| mvd
| Related to y2r2
|-
| 0x16
| mvd
| Related to y2r2
|-
| 0x17
| mvd
| Related to l2b
|-
| 0x18
| mvd
| Related to l2b
|-
| 0x19
| mvd
| Related to l2b
|-
| 0x1A
| mvd
| Related to l2b
|}

== XDMA Peripheral IDs ==

{| class="wikitable" border="1"
! ID
! Module
! Description
|-
| 0
| Process9
| CTRCARD
|-
| 7
| Process9
| SHA
|-
|}

ARM11 Interrupts

2018-06-27T23:14:23Z

Unknown:

== Interrupts ==

Interrupt priority is 0-0xF. A priority of 0xF means that the interrupt is disabled.

= Private Interrupts =

Each CPU core has 32 software interrupts that are private and belong to that core. These interrupts are numbers 0-0x1F for each core. The hardware interrupts are not core-specific and start at interrupt ID 0x20.

{| class="wikitable" border="1"
! IRQ
! Listener
! Description
|-
| 0-0x3
|
| MPCore software-interrupt. Not configured.
|-
| 0x4
| Kernel
| MPCore software-interrupt. Used to manage the performance counter.
|-
| 0x5
| Kernel
| MPCore software-interrupt. Does apparently nothing.
|-
| 0x6
| Kernel
| MPCore software-interrupt. Extensively used by [[SVC|KernelSetState]] (and contains most of the actual code of the latter).
|-
| 0x7
| Kernel
| MPCore software-interrupt. See [[KCacheMaintenanceInterruptEvent]]
|-
| 0x8
| Kernel
| MPCore software-interrupt. Used for scheduling.
|-
| 0x9
| Kernel
| MPCore software-interrupt. Used when handling exceptions that require termination of a thread or a process, and in some cases by svcSetDebugThreadContext, to store VFP registers in the thread's register storage.
|-
| 0xA
| Kernel
| TLB operations interrupt, see [[KTLBOperationsInterruptEvent]]
|-
| 0xB-0xE
|
| MPCore software-interrupt. Not configured.
|-
| 0xF
| dmnt/debugger
| MPCore software-interrupt. Used to abstract FIQ (debug). This interrupt is never sent to core2 nor core3 on N3DS.
|-
| 0x1D
| Kernel
| MPCore timer.
|-
| 0x1E
| Kernel
| MPCore watchdog - set when the watchdog counter reaches 0 in timer mode, causes interrupt 30 to set as pending. Only set on core 1 as core 1's timer is used for everything.
|}

= Hardware Interrupts =

There are 0x60 hardware interrupts starting at 0x20 and continuing up to 0x7F. These are not private and are accessible from any core.

{| class="wikitable" border="1"
! IRQ
! Listener
! Description
|-
| 0x28
| gsp, TwlBg
| PSC0
|-
| 0x29
| gsp, TwlBg
| PSC1
|-
| 0x2A
| gsp, TwlBg
| PDC0 (VBlank0)
|-
| 0x2B
| gsp, TwlBg
| PDC1 (VBlank1)
|-
| 0x2C
| gsp, TwlBg
| PPF
|-
| 0x2D
| gsp, TwlBg
| P3D
|-
| 0x30
| Kernel
| ?
|-
| 0x39
| Kernel
| DMA
|-
| 0x3A
| Kernel
| DMA
|-
| 0x3B
| Kernel
| DMA
|-
| 0x40
| nwm
| WIFI SDIO Controller @ 0x10122000
|-
| 0x41
| nwm
| ?
|-
| 0x42
| nwm_dev?
| WIFI SDIO Controller @ 0x10100000
|-
| 0x45
| mvd (New3DS)
| ?
|-
| 0x46
| mvd (New3DS)
| ?
|-
| 0x48
| camera
| ?
|-
| 0x49
| camera
| ?
|-
| 0x4A
| dsp
| ?
|-
| 0x4B
| camera
| Y2R Conversion Finished
|-
| 0x4C
| TwlBg
| ?
|-
| 0x4D
| TwlBg
| ?
|-
| 0x4E
| mvd (New3DS)
| Related to y2r2
|-
| 0x4F
| mvd (New3DS)
| Related to mvd services
|-
| 0x50
| pxi, TwlBg
| Sync
|-
| 0x51
| pxi, TwlBg
| ?
|-
| 0x52
| pxi, TwlBg
| Send Fifo Empty
|-
| 0x53
| pxi, TwlBg
| Receive Fifo Not Empty
|-
| 0x54
| i2c, TwlBg
| I2C Bus0 work done
|-
| 0x55
| i2c, TwlBg
| I2C Bus1 work done
|-
| 0x56
| spi, TwlBg
| ?
|-
| 0x57
| spi, TwlBg
| ?
|-
| 0x58
| Kernel
| PDN
|-
| 0x59
| TwlBg
| ?
|-
| 0x5A
| mic
| ?
|-
| 0x5C
| i2c, TwlBg
| I2C Bus2 work done
|-
| 0x60
| gpio, TwlBg
| Shell opened
|-
| 0x62
| gpio, TwlBg
| Shell closed
|-
| 0x63
| gpio, TwlBg
| Touchscreen
|-
| 0x64
| gpio, TwlBg
| Headphone jack plugged in/out
|-
| 0x66
| gpio, TwlBg
| ?
|-
| 0x68
| gpio, TwlBg
| IR
|-
| 0x69
| gpio, TwlBg
| ?
|-
| 0x6A
| gpio, TwlBg
| ?
|-
| 0x6B
| gpio, TwlBg
| ?
|-
| 0x6C
| gpio, TwlBg
| ?
|-
| 0x6D
| gpio, TwlBg
| ?
|-
| 0x6E
| gpio, TwlBg
| ?
|-
| 0x6F
| gpio, TwlBg
| ?
|-
| 0x70
| gpio, TwlBg
| ?
|-
| 0x71
| gpio, TwlBg
| MCU (HOME/POWER pressed/released or WiFi switch pressed)
|-
| 0x72
| gpio, TwlBg
| ?
|-
| 0x73
| TwlBg
| ?
|-
| 0x74
| ?
| Gamecard related
|-
| 0x75
| ?
| Gamecard inserted
|-
| 0x78 to 0x7B
| Kernel
| Core 0-3 Performance monitor counter (any) overflow
|-
| 0x7A to 0x82 (PDN_MPCORE_CFG bit2 set) or
0x7C to 0x84 (bit2 clear)
| Kernel
| ?
|}
(interrupts from 0x80 and up can't be mapped in available builds of the kernel)

There are 2 tables in the ARM11 kernel: the first has 32 * 2(or 32 * 4) 8-byte entries. This table is for the private interrupts that belong to each core. The data for each interrupt can be found by doing table_base + (core_num * 0x100) + (intr_num * 8). The second table is for public hardware interrupts and the data for each interrupt can be retrieved by doing table_base + (intr_num * 8).

= InterruptData =
{| class="wikitable" border="1"
|-
! Offset
! Type
! Description
|-
| 0x0
| [[KBaseInterruptEvent]] *
| Pointer to the KBaseInterruptEvent object for this interrupt
|-
| 0x4
| u8
| Interrupt will be disabled by the IRQ handler as soon as it is acknowledged.
Ignored for FIQ: the FIQ handler always sets bit2 of [[PDN_Registers#PDN_FIQ_CNT|PDN_FIQ_CNT]]
|-
| 0x5
| u8
| Interrupt is disabled
|-
| 0x6
| u8
| Interrupt priority
|-
| 0x7
| u8
| Unused, alignment
|}

= Interrupt Table (New3DS) =
(0xFFF318F4 in 10.3)

{| class="wikitable" border="1"
! Offset
! Type
! Description
|-
| 0x0
| InterruptData[224]
| Data for all hardware and software interrupts
|-
| 0x700
| [[KObjectMutex]]
| Mutex
|}

ARM11 Interrupts

2018-06-27T23:05:12Z

Unknown:

== Interrupts ==

Interrupt priority is 0-0xF. A priority of 0xF means that the interrupt is disabled.

= Private Interrupts =

Each CPU core has 32 software interrupts that are private and belong to that core. These interrupts are numbers 0-0x1F for each core. The hardware interrupts are not core-specific and start at interrupt ID 0x20.

{| class="wikitable" border="1"
! IRQ
! Listener
! Description
|-
| 0-0x3
|
| MPCore software-interrupt. Not configured.
|-
| 0x4
| Kernel
| MPCore software-interrupt. Used to manage the performance counter.
|-
| 0x5
| Kernel
| MPCore software-interrupt. Does apparently nothing.
|-
| 0x6
| Kernel
| MPCore software-interrupt. Extensively used by [[SVC|KernelSetState]] (and contains most of the actual code of the latter).
|-
| 0x7
| Kernel
| MPCore software-interrupt. See [[KCacheMaintenanceInterruptEvent]]
|-
| 0x8
| Kernel
| MPCore software-interrupt. Used for scheduling.
|-
| 0x9
| Kernel
| MPCore software-interrupt. Used when handling exceptions that require termination of a thread or a process, and in some cases by svcSetDebugThreadContext, to store VFP registers in the thread's register storage.
|-
| 0xA
| Kernel
| TLB operations interrupt, see [[KTLBOperationsInterruptEvent]]
|-
| 0xB-0xE
|
| MPCore software-interrupt. Not configured.
|-
| 0xF
| dmnt/debugger
| MPCore software-interrupt. Used to abstract FIQ (debug). This interrupt is never sent to core2 nor core3 on N3DS.
|-
| 0x1D
| Kernel
| MPCore timer.
|-
| 0x1E
| Kernel
| MPCore watchdog - set when the watchdog counter reaches 0 in timer mode, causes interrupt 30 to set as pending. Only set on core 1 as core 1's timer is used for everything.
|}

= Hardware Interrupts =

There are 0x60 hardware interrupts starting at 0x20 and continuing up to 0x7F. These are not private and are accessible from any core.

{| class="wikitable" border="1"
! IRQ
! Listener
! Description
|-
| 0x28
| gsp, TwlBg
| PSC0
|-
| 0x29
| gsp, TwlBg
| PSC1
|-
| 0x2A
| gsp, TwlBg
| PDC0 (VBlank0)
|-
| 0x2B
| gsp, TwlBg
| PDC1 (VBlank1)
|-
| 0x2C
| gsp, TwlBg
| PPF
|-
| 0x2D
| gsp, TwlBg
| P3D
|-
| 0x30
| Kernel
| ?
|-
| 0x39
| Kernel
| DMA
|-
| 0x3A
| Kernel
| DMA
|-
| 0x3B
| Kernel
| DMA
|-
| 0x40
| nwm
| WIFI SDIO Controller @ 0x10122000
|-
| 0x41
| nwm
| ?
|-
| 0x42
| nwm_dev?
| WIFI SDIO Controller @ 0x10100000
|-
| 0x45
| mvd (New3DS)
| ?
|-
| 0x46
| mvd (New3DS)
| ?
|-
| 0x48
| camera
| ?
|-
| 0x49
| camera
| ?
|-
| 0x4A
| dsp
| ?
|-
| 0x4B
| camera
| Y2R Conversion Finished
|-
| 0x4C
| TwlBg
| ?
|-
| 0x4D
| TwlBg
| ?
|-
| 0x4E
| mvd (New3DS)
| ?
|-
| 0x4F
| mvd (New3DS)
| Related to y2r2
|-
| 0x50
| pxi, TwlBg
| Sync
|-
| 0x51
| pxi, TwlBg
| ?
|-
| 0x52
| pxi, TwlBg
| Send Fifo Empty
|-
| 0x53
| pxi, TwlBg
| Receive Fifo Not Empty
|-
| 0x54
| i2c, TwlBg
| I2C Bus0 work done
|-
| 0x55
| i2c, TwlBg
| I2C Bus1 work done
|-
| 0x56
| spi, TwlBg
| ?
|-
| 0x57
| spi, TwlBg
| ?
|-
| 0x58
| Kernel
| PDN
|-
| 0x59
| TwlBg
| ?
|-
| 0x5A
| mic
| ?
|-
| 0x5C
| i2c, TwlBg
| I2C Bus2 work done
|-
| 0x60
| gpio, TwlBg
| Shell opened
|-
| 0x62
| gpio, TwlBg
| Shell closed
|-
| 0x63
| gpio, TwlBg
| Touchscreen
|-
| 0x64
| gpio, TwlBg
| Headphone jack plugged in/out
|-
| 0x66
| gpio, TwlBg
| ?
|-
| 0x68
| gpio, TwlBg
| IR
|-
| 0x69
| gpio, TwlBg
| ?
|-
| 0x6A
| gpio, TwlBg
| ?
|-
| 0x6B
| gpio, TwlBg
| ?
|-
| 0x6C
| gpio, TwlBg
| ?
|-
| 0x6D
| gpio, TwlBg
| ?
|-
| 0x6E
| gpio, TwlBg
| ?
|-
| 0x6F
| gpio, TwlBg
| ?
|-
| 0x70
| gpio, TwlBg
| ?
|-
| 0x71
| gpio, TwlBg
| MCU (HOME/POWER pressed/released or WiFi switch pressed)
|-
| 0x72
| gpio, TwlBg
| ?
|-
| 0x73
| TwlBg
| ?
|-
| 0x74
| ?
| Gamecard related
|-
| 0x75
| ?
| Gamecard inserted
|-
| 0x78 to 0x7B
| Kernel
| Core 0-3 Performance monitor counter (any) overflow
|-
| 0x7A to 0x82 (PDN_MPCORE_CFG bit2 set) or
0x7C to 0x84 (bit2 clear)
| Kernel
| ?
|}
(interrupts from 0x80 and up can't be mapped in available builds of the kernel)

There are 2 tables in the ARM11 kernel: the first has 32 * 2(or 32 * 4) 8-byte entries. This table is for the private interrupts that belong to each core. The data for each interrupt can be found by doing table_base + (core_num * 0x100) + (intr_num * 8). The second table is for public hardware interrupts and the data for each interrupt can be retrieved by doing table_base + (intr_num * 8).

= InterruptData =
{| class="wikitable" border="1"
|-
! Offset
! Type
! Description
|-
| 0x0
| [[KBaseInterruptEvent]] *
| Pointer to the KBaseInterruptEvent object for this interrupt
|-
| 0x4
| u8
| Interrupt will be disabled by the IRQ handler as soon as it is acknowledged.
Ignored for FIQ: the FIQ handler always sets bit2 of [[PDN_Registers#PDN_FIQ_CNT|PDN_FIQ_CNT]]
|-
| 0x5
| u8
| Interrupt is disabled
|-
| 0x6
| u8
| Interrupt priority
|-
| 0x7
| u8
| Unused, alignment
|}

= Interrupt Table (New3DS) =
(0xFFF318F4 in 10.3)

{| class="wikitable" border="1"
! Offset
! Type
! Description
|-
| 0x0
| InterruptData[224]
| Data for all hardware and software interrupts
|-
| 0x700
| [[KObjectMutex]]
| Mutex
|}

CECD Services

2018-03-18T14:05:04Z

Unknown: /* CECD Service "cecd:u" */

[[Category:Services]]

Streetpass stuff.

= CECD Service "cecd:u" =
{| class="wikitable" border="1"
|-
! Command Header
! Description
|-
| 0x000100C2
| [[CECDU:OpenRawFile|OpenRawFile]]
|-
| 0x00020042
| [[CECDU:ReadRawFile|ReadRawFile]]
|-
| 0x00030104
| [[CECDU:ReadMessage|ReadMessage]]
|-
| 0x00040106
| [[CECDU:ReadMessageWithHMAC|ReadMessageWithHMAC]]
|-
| 0x00050042
| [[CECDU:WriteRawFile|WriteRawFile]]
|-
| 0x00060104
| [[CECDU:WriteMessage|WriteMessage]]
|-
| 0x00070106
| [[CECDU:WriteMessageWithHMAC|WriteMessageWithHMAC]]
|-
| 0x00080102
| [[CECDU:Delete|Delete]]
|-
| 0x000900C2
| ? (16*length+10 of CecMessageId buffer in cmdbuff[4] (always 16*8+10), CecMessageId* in cmdbuf[5])
|-
| 0x000A00C4
| [[CECDU:GetSystemInfo|GetSystemInfo]]
|-
| 0x000B0040
| RunCommand
|-
| 0x000C0040
| RunCommandAlt (seems to be the same as RunCommand besides some extra checks)
|-
| 0x000D0082
| GetCecInfoBuffer
|-
| 0x000E0000
| GetCecStateAbbreviated (returns CecStateAbbreviated in cmdbuf[2])
|-
| 0x000F0000
| GetCecInfoEventHandle (returns event handle in cmdbuf[3])
|-
| 0x00100000
| GetChangeStateEventHandle (returns event handle in cmdbuf[3])
|-
| 0x00110104
| [[CECDU:OpenAndWrite|OpenAndWrite]]
|-
| 0x00120104
| [[CECDU:OpenAndRead|OpenAndRead]]
|-
| 0x001E0082
| GetEventLog
|-
| 0x001F0000
| GetEventLogStart
|-
| 0x0020....
| ?
|-
| 0x0021....
| ?
|-
|}

=== CecDataPathType ===
{| class="wikitable" border="1"
! Name
! Value
! Notes
|-
| CEC_PATH_MBOX_LIST || 1
| data:/CEC/MBoxList____
|-
| CEC_PATH_MBOX_INFO || 2
| data:/CEC/<id>/MBoxInfo____
|-
| CEC_PATH_INBOX_INFO || 3
| data:/CEC/<id>/InBox___/BoxInfo_____
|-
| CEC_PATH_OUTBOX_INFO || 4
| data:/CEC/<id>/OutBox__/BoxInfo_____
|-
| CEC_PATH_OUTBOX_INDEX || 5
| data:/CEC/<id>/OutBox__/OBIndex_____
|-
| CEC_PATH_INBOX_MSG || 6
| data:/CEC/<id>/InBox___/_<message_id>
|-
| CEC_PATH_OUTBOX_MSG || 7
| data:/CEC/<id>/OutBox__/_<message_id>
|-
| CEC_PATH_ROOT_DIR || 10
| data:/CEC
|-
| CEC_PATH_MBOX_DIR || 11
| data:/CEC/<id>
|-
| CEC_PATH_INBOX_DIR || 12
| data:/CEC/<id>/InBox___
|-
| CEC_PATH_OUTBOX_DIR || 13
| data:/CEC/<id>/OutBox__
|-
| || 101 thru 199 (inclusive)
| data:/CEC/<id>/MBoxData.0<i-100>
|-
| CECMESSAGE_BOX_ICON || 101
| data:/CEC/<id>/MBoxData.001
|-
| CECMESSAGE_BOX_TITLE || 110
| data:/CEC/<id>/MBoxData.010
|}

=== CecCommand ===
{| class="wikitable" border="1"
! Name
! Value
! Notes
|-
| CEC_COMMAND_NONE
| 0
|
|-
| CEC_COMMAND_START
| 1
|
|-
| CEC_COMMAND_RESET_START
| 2
|
|-
| CEC_COMMAND_READYSCAN
| 3
|
|-
| CEC_COMMAND_READYSCANWAIT
| 4
|
|-
| CEC_COMMAND_STARTSCAN
| 5
|
|-
| CEC_COMMAND_RESCAN
| 6
|
|-
| CEC_COMMAND_NDM_RESUME
| 7
|
|-
| CEC_COMMAND_NDM_SUSPEND
| 8
|
|-
| CEC_COMMAND_NDM_SUSPEND_IMMEDIATE
| 9
|
|-
| CEC_COMMAND_STOPWAIT
| 0xA
|
|-
| CEC_COMMAND_STOP
| 0xB
|
|-
| CEC_COMMAND_STOP_FORCE
| 0xC
|
|-
| CEC_COMMAND_STOP_FORCE_WAIT
| 0xD
|
|-
| CEC_COMMAND_RESET_FILTER
| 0xE
|
|-
| CEC_COMMAND_DAEMON_STOP
| 0xF
|
|-
| CEC_COMMAND_DAEMON_START
| 0x10
|
|-
| CEC_COMMAND_EXIT
| 0x11
|
|-
| CEC_COMMAND_OVER_BOSS
| 0x12
|
|-
| CEC_COMMAND_OVER_BOSS_FORCE
| 0x13
|
|-
| CEC_COMMAND_OVER_BOSS_FORCE_WAIT
| 0x14
|
|-
| CEC_COMMAND_END
| 0x15
|
|-
|}

=== CecStateAbbreviated ===
{| class="wikitable" border="1"
! Name
! Value
! Notes
|-
| CEC_STATE_ABBREV_IDLE
| 1
| Corresponds to CEC_STATE_IDLE
|-
| CEC_STATE_ABBREV_INACTIVE
| 2
| Corresponds to CEC_STATEs *FINISH*, *POST, and OVER_BOSS
|-
| CEC_STATE_ABBREV_SCANNING
| 3
| Corresponds to CEC_STATE_SCANNING
|-
| CEC_STATE_ABBREV_WLREADY?
| 4
| Corresponds to CEC_STATE_WIRELESS_READY when some unknown bool is true
|-
| CEC_STATE_ABBREV_OTHER
| 5
| Corresponds to CEC_STATEs besides *FINISH*, *POST, and OVER_BOSS and those listed here
|}

=== CecMessageId ===
{| class="wikitable" border="1"
! Type
! Field
|-
| char[8]
| data
|-
|}

= CECD Service "cecd:s" =

This contains a similar (probably the same) command handler from 0x0001.... to 0x0021.... as them in cecd:u. In addition, it also contains
{| class="wikitable" border="1"
|-
! Command Header
! Description
|-
| 0x0401....
| ?
|-
| 0x04020002
| ?
|-
| 0x040A....
| ?
|-
| 0x040B....
| ?
|-
| 0x040C0042
| ?
|-
| 0x040D0082
| ?
|-
| 0x040E....
| ?
|-
| 0x040F....
| ?
|-
| 0x0410....
| ?
|-
| 0x04110042
| ?
|-
| 0x041200C2
| ?
|-
| 0x0413....
| ?
|-
| 0x0414....
| ?
|-
| 0x0415....
| ?
|-
| 0x04160002
| ?
|-
| 0x0417....
| ?
|-
|}

= CECD Service "cecd:ndm" =
{| class="wikitable" border="1"
|-
! Command Header
! Description
|-
| 0x00010000
| Initialize
|-
| 0x00020000
| Deinitialize
|-
| 0x00030000
| ResumeDaemon
|-
| 0x00040040
| SuspendDaemon(bool immediately)
|-
| 0x00050000
| ?
|-
| 0x00060042
| ?
|-
| 0x00070042
| ?
|-
| 0x00080042
| ?
|-
|}

NIM Services

2018-03-18T13:17:06Z

Unknown: /* NIM user service "nim:u" */

[[Category:Services]]
= NIM user service "nim:u" =
{| class="wikitable" border="1"
|-
! Command Header
! Description
|-
| 0x00010000
| Related to starting a sysupdate?
|-
| 0x00020000
| [[NIMU:GetUpdateDownloadProgress|GetUpdateDownloadProgress]]
|-
| 0x0003....
| ?
|-
| 0x00040000
| [[NIMU:FinishTitlesInstall|FinishTitlesInstall]]
|-
| 0x00050000
| This obtains an event handle. Home Menu will check whether a system update is available when this event is triggered.
|-
| 0x0006....
| ?
|-
| 0x0007....
| This deletes and recreates the system save data 0x0001002C (NIM System SaveData)
|-
| 0x0008....
| ?
|-
| 0x00090000
| [[NIMU:CheckSysupdateAvailable|CheckSysupdateAvailable]]
|-
| 0x000A0000
| GetState
|-
| 0x000B0000
| [[NIMU:GetSystemTitleHash|GetSystemTitleHash]]
|-
| 0x000C0082
| UnregisterTask
|-
| 0x000E0080
| ?
|-
| 0x000F0042
| ?
|-
| 0x00110000
| ?
|-
| 0x00130000
| ?
|-
| 0x00140000
| ?
|-
| 0x00150000
| ?
|-
| 0x00170042
| ?
|-
| 0x00180080
| ?
|-
| 0x00250000
| ?
|-
| 0x00260200
| ?
|-
| 0x00270000
| ?
|-
| 0x00280000
| ?
|-
| 0x00290246
| RegisterTask
|-
| 0x002A0000
| ?
|-
| 0x002B0000
| ?
|-
| 0x002C0000
| ?
|-
| 0x002D00C0
| ?
|-
| 0x00480002
| ?
|}

= NIM server service "nim:s" =
{| class="wikitable" border="1"
|-
! Command Header
! Description
|-
| 0x00010200
| [[NIMS:StartDownloadSimple|StartDownloadSimple]]
|-
| 0x00020000
| [[NIMS:CancelDownload|CancelDownload]]
|-
| 0x00030000
| [[NIMS:GetProgress|GetProgress]]
|-
| 0x00050082
| [[NIMS:UnregisterTask|UnregisterTask]]
|-
| 0x00060080
| [[NIMS:IsTaskRegistered|IsTaskRegistered]]
|-
| 0x000A0000
| [[NIMS:CheckSysupdateAvailableSOAP|CheckSysupdateAvailableSOAP]]
|-
| 0x000B0084
| [[NIMS:SetAttribute|SetAttribute]]
|-
| 0x0016020A
| [[NIMS:ListTitles|ListTitles]]
|-
| 0x00220080
| AccountDeleteTitleETicketsSOAP. The SOAP request is sent only after the ticket for the specified titleID has been successfully deleted.
|-
| 0x00290000
| [[NIMS:AccountCheckBalanceSOAP|AccountCheckBalanceSOAP]]
|-
| 0x002D0042
| [[NIMS:DownloadTickets|DownloadTickets]]
|-
| 0x003C0002
| [[NIMS:RegisterSelf|RegisterSelf]]
|-
| 0x003F0000
| GetInitializeResult. Checks whether nim is properly initialized or not. If it is not, the result code returned is non-zero.
|-
| 0x00420240
| [[NIMS:StartDownload|StartDownload]]
|-
| 0x00550246
| [[NIMS:RegisterTask|RegisterTask]]
|-
| 0x00570082
| [[NIMS:ConnectNoTicketDownload|ConnectNoTicketDownload]]
|}

= NIM server service "nim:aoc" =
{| class="wikitable" border="1"
|-
! Command Header
! Description
|-
| 0x00030042
| SetApplicationId
|-
| 0x00040042
| SetTin
|-
| 0x000902D0
| ListContentSetsEx
|-
| 0x00180000
| GetBalance
|-
| 0x001D0000
| GetCustomerSupportCode
|-
| 0x00210000
| Initialize
|-
| 0x00240282
| CalculateContentsRequiredSize
|-
| 0x00250000
| RefreshServerTime
|}

= NIM service "nim:ndm" =

= kagiya server =
The nim system module communicates with a server called kagiya (kagiya-ctr.cdn.nintendo.net or kagiya-dev-ctr.cdn.nintendo.net for development units). It provides the 9.6 crypto seed in binary form for any given title ID under (HTTPS) kagiya-ctr.cdn.nintendo.net/title/0x%16llx/ext_key?country=%s, where %16llx is the title ID and %s is a country code as used in the [[EShop|eShop]].

=New3DS=
NIM module only uses [[PTMSYSM:CheckNew3DS|CheckNew3DS]] for determining what heap sizes to use, in two functions. One is for the size of the 0x08000000 vmem heap, the other is probably for some buffer allocated on that heap. The New3DS version of these sizes are 0x1C000-bytes larger than the Old3DS sizes here.

=HTTPS requests=

==Trusted RootCAs==
During startup NIM-module creates two RootCertChains with [[HTTP_Services|HTTPC]]. Both of these only contain the same [[HTTPC:RootCertChainAddDefaultCert|default]] cert with ID 0x3. The first RootCertChain is used with NetUpdateSOAP. Requests such as the "notifications.json" page don't use these RootCertChains(in this case just [[HTTPC:AddDefaultCert|default]] certID 0xB is used).

==SOAP==

===NetUpdateSOAP===
There are exactly 3 types of network SOAP requests used with [https://nus.c.shop.nintendowifi.net/nus/services/NetUpdateSOAP NetUpdateSOAP] by NIM module, described below. This URL contained in NIM module itself is only used with GetSystemTitleHash. The other requests use an identical URL loaded from an ECommerceSOAP response instead.

See also [https://github.com/yellows8/ninupdates here].

====GetSystemUpdate====
Returns the current sysupdate title-listing. This also contains the SystemTitleHash returned by GetSystemTitleHash.

====GetSystemTitleHash====
Returns the current SystemTitleHash for the current sysupdate title-listing.

====GetSystemCommonETicket====
Returns the Base64-encoded cetk for each specified TitleId entry.

This is only used when installing new titles. This means with CDN system-updates, tickets are never installed except when a title is being installed for the first time. For example, a system on the latest system-version that was only ever updated via CDN has the same NATIVE_FIRM ticket installed from the factory.

=Sysupdate checking process=
This section describes the process used when checking whether a sysupdate is required.

First the GetSystemTitleHash SOAP request is done. Then the SystemTitleHash in savedata hash.dat is compared with the received one. If they match and the SystemTitleHash flag is set to value 0x03, it will immediately return that no sysupdate is required. Otherwise it will start the GetSystemUpdate SOAP request handling.

The GetSystemUpdate SOAP request contains a titlelist of all NAND system-titles. For GetSystemUpdate response parsing, it compares each SOAP title_entry with the NAND system titlelist. If a SOAP titleID isn't found in the NAND titlelist, this means NAND is missing a new title and hence a sysupdate is required for installing that title. If a NAND title_entry-version is less than the SOAP title_entry-version, this means the title needs updated and hence a sysupdate is required.

At least one <TitleVersion> entry with valid data in the GetSystemUpdate response is required.

The titleIDs sent in the GetSystemUpdate SOAP request are decimal, while the titleIDs in the response are hex.

=NIM [[System_SaveData]]=
==hash.dat==
{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
|-
| 0x60
| 0x1
| u8 flag used with the SystemTitleHash. 0x01 = latest sysupdate isn't installed as of last SOAP requests, 0x03 = latest sysupdate is installed as of last SOAP requests.
|-
| 0x61
| 0x21
| ASCII hex SystemTitleHash, including NUL-terminator. This is the latest SystemTitleHash which NIM module received from SOAP.
|}

=Types=
==InstallationMode==
{| class="wikitable" border="1"
|-
! Value
! Description
|-
| 0
| Initial installation
|-
| 1
| Unknown
|-
| 2
| Unknown
|-
| 3
| Reinstallation
|}
==DownloadState==
{| class="wikitable" border="1"
|-
! Value
! Description
|-
| 0
| Not initialized
|-
| 1
| Download initialized
|-
| 2
| Downloading, verifying and installing TMD
|-
| 3
| Initializing save data
|-
| 4
| Downloading and installing contents
|-
| 5
| Waiting before calling [[AM:CommitImportPrograms]]
|-
| 6
| Running [[AM:CommitImportPrograms]]
|-
| 7
| Title installation finished
|-
| 8
| Unknown error regarding title version
|-
| 9
| Creating the .ctx file (or error doing so)?
|-
| 10
| Irrecoverable error encountered
|}
==TitleConfig==
{| class="wikitable" border="1"
|-
! Offset
! Length
! Description
|-
| 0x0
| 0x8
| Title ID
|-
| 0x8
| 0x4
| Title version
|-
| 0xC
| 0x4
| Unknown (always 0)
|-
| 0x10
| 0x1
| Age rating for the HOME Menu parental controls
|-
| 0x11
| 0x1
| [[Filesystem_services#MediaType|Media Type]]
|-
| 0x12
| 0x2
| Padding
|-
| 0x14
| 0x4
| Unknown (always 0?)
|}
==TitleProgress==
{| class="wikitable" border="1"
|-
! Offset
! Length
! Description
|-
| 0x0
| 0x4
| [[#DownloadState|Download State]]
|-
| 0x4
| 0x4
| Last result code in NIM related to the installation
|-
| 0x8
| 0x8
| Amount of bytes that have been downloaded
|-
| 0x10
| 0x8
| Total bytes that need to be downloaded
|}

FRDA:AddFriendOnline

2018-03-17T10:58:24Z

Unknown: /* Request */ Oops. My bad, thanks for correcting me Wwylele!

=Request=
{| class="wikitable" border="1"
|-
! Index Word
! Description
|-
| 0
| Header code [0x04060042]
|-
| 1
| principal_id
|-
| 2
| 0 (one copy handle translation descriptor)
|-
| 3
| Event Handle
|}

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

FRDA:RemoveFriend

2018-03-15T16:55:47Z

Unknown: Created page with "=Request= {| class="wikitable" border="1" |- ! Index Word ! Description |- | 0 | Header code [0x04090100] |- | 1 | principal_id |- | 2..3 | u64 friend_code |} =Response= {|..."

=Request=
{| class="wikitable" border="1"
|-
! Index Word
! Description
|-
| 0
| Header code [0x04090100]
|-
| 1
| principal_id
|-
| 2..3
| u64 friend_code
|}

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

Friend Services

2018-03-15T16:52:34Z

Unknown: /* "frd:a" */

[[Category:Services]]
= Friend Service "frd:u" =
{| class="wikitable" border="1"
|-
! Command Header
! Description
|-
| 0x00010000
| [[FRDU:HasLoggedIn|HasLoggedIn]]
|-
| 0x00020000
| [[FRDU:IsOnline|IsOnline]]
|-
| 0x00030002
| [[FRDU:Login|Login]]
|-
| 0x00040000
| [[FRDU:Logout|Logout]]
|-
| 0x00050000
| [[FRDU:GetMyFriendKey|GetMyFriendKey]]
|-
| 0x00060000
| [[FRDU:GetMyPreference|GetMyPreference]]
|-
| 0x00070000
| [[FRDU:GetMyProfile|GetMyProfile]]
|-
| 0x00080000
| [[FRDU:GetMyPresence|GetMyPresence]]
|-
| 0x00090000
| [[FRDU:GetMyScreenName|GetMyScreenName]]
|-
| 0x000A0000
| [[FRDU:GetMyMii|GetMyMii]]
|-
| 0x000B0000
| [[FRDU:GetMyLocalAccountId|GetMyLocalAccountId]]
|-
| 0x000C0000
| [[FRDU:GetMyPlayingGame|GetMyPlayingGame]]
|-
| 0x000D0000
| [[FRDU:GetMyFavoriteGame|GetMyFavoriteGame]]
|-
| 0x000E0000
| [[FRDU:GetMyNcPrincipalId|GetMyNcPrincipalId]]
|-
| 0x000F0000
| [[FRDU:GetMyComment|GetMyComment]]
|-
| 0x00100040
| [[FRDU:GetMyPassword|GetMyPassword]]
|-
| 0x00110080
| [[FRDU:GetFriendKeyList|GetFriendKeyList]]
|-
| 0x00120042
| [[FRDU:GetFriendPresence|GetFriendPresence]]
|-
| 0x00130142
| [[FRDU:GetFriendScreenName|GetFriendScreenName]]
|-
| 0x00140044
| [[FRDU:GetFriendMii|GetFriendMii]]
|-
| 0x00150042
| [[FRDU:GetFriendProfile|GetFriendProfile]]
|-
| 0x00160042
| [[FRDU:GetFriendRelationship|GetFriendRelationship]]
|-
| 0x00170042
| [[FRDU:GetFriendAttributeFlags|GetFriendAttributeFlags]]
|-
| 0x00180044
| [[FRDU:GetFriendPlayingGame|GetFriendPlayingGame]]
|-
| 0x00190042
| [[FRDU:GetFriendFavoriteGame|GetFriendFavoriteGame]]
|-
| 0x001A00C4
| [[FRDU:GetFriendInfo|GetFriendInfo]]
|-
| 0x001B0080
| [[FRDU:IsIncludedInFriendList|IsIncludedInFriendList]]
|-
| 0x001C0042
| [[FRDU:UnscrambleLocalFriendCode|UnscrambleLocalFriendCode]]
|-
| 0x001D0002
| [[FRDU:UpdateGameModeDescription|UpdateGameModeDescription]]
|-
| 0x001E02C2
| [[FRDU:UpdateGameMode|UpdateGameMode]]
|-
| 0x001F0042
| [[FRDU:SendInvitation|SendInvitation]]
|-
| 0x00200002
| [[FRDU:AttachToEventNotification|AttachToEventNotification]]
|-
| 0x00210040
| [[FRDU:SetNotificationMask|SetNotificationMask]]
|-
| 0x00220040
| [[FRDU:GetEventNotification|GetEventNotification]]
|-
| 0x00230000
| [[FRDU:GetLastResponseResult|GetLastResponseResult]]
|-
| 0x00240040
| [[FRDU:PrincipalIdToFriendCode|PrincipalIdToFriendCode]]
|-
| 0x00250080
| [[FRDU:FriendCodeToPrincipalId|FriendCodeToPrincipalId]]
|-
| 0x00260080
| [[FRDU:IsValidFriendCode|IsValidFriendCode]]
|-
| 0x00270040
| [[FRDU:ResultToErrorCode|ResultToErrorCode]]
|-
| 0x00280244
| [[FRDU:RequestGameAuthentication|RequestGameAuthentication]]
|-
| 0x00290000
| [[FRDU:GetGameAuthenticationData|GetGameAuthenticationData]]
|-
| 0x002A0204
| [[FRDU:RequestServiceLocator|RequestServiceLocator]]
|-
| 0x002B0000
| [[FRDU:GetServiceLocatorData|GetServiceLocatorData]]
|-
| 0x002C0002
| [[FRDU:DetectNatProperties|DetectNatProperties]]
|-
| 0x002D0000
| [[FRDU:GetNatProperties|GetNatProperties]]
|-
| 0x002E0000
| [[FRDU:GetServerTimeInterval|GetServerTimeInterval]]
|-
| 0x002F0040
| [[FRDU:AllowHalfAwake|AllowHalfAwake]]
|-
| 0x00300000
| [[FRDU:GetServerTypes|GetServerTypes]]
|-
| 0x00310082
| [[FRDU:GetFriendComment|GetFriendComment]]
|-
| 0x00320042
| [[FRDU:SetClientSdkVersion|SetClientSdkVersion]]
|-
| 0x00330000
| [[FRDU:GetMyApproachContext|GetMyApproachContext]]
|-
| 0x00340046
| [[FRDU:AddFriendWithApproach|AddFriendWithApproach]]
|-
| 0x00350082
| [[FRDU:DecryptApproachContext|DecryptApproachContext]]
|}

= "frd:n" =
{| class="wikitable" border="1"
|-
! Command Header
! Description
|-
| 0x00010000
| ?
|-
| 0x00020000
| ?
|-
| 0x00030040
| ?
|-
| 0x00040000
| ?
|}

= "frd:a" =

This contains a similar (probably the same) command handler from 0x0001.... to 0x002F.... as them in frd:u. In addition, it also contains

{| class="wikitable" border="1"
|-
! Command Header
! Description
|-
| 0x04050000
| Used in creating the user Mii. No cmdbuff parameters.
|-
| 0x04060042
| [[FRDA:AddFriendOnline|AddFriendOnline]]
|-
| 0x04090100
| [[FRDA:RemoveFriend|RemoveFriend]]
|-
| 0x040B00C0
| UpdatePrefrences
|-
| 0x040C0800
| Used in creating the user Mii. 128-byte struct as cmdbuff parameters.
|}

=HTTPS Requests=

==Trusted RootCAs==
No RootCertChain(s) are used. For the nasc site, friends-module uses [[HTTPC:AddDefaultCert]] with the following certIDs: 0x1, 0x2, and 0x3.

FRDA:AddFriendOnline

2018-03-15T16:48:35Z

Unknown: Created page with "=Request= {| class="wikitable" border="1" |- ! Index Word ! Description |- | 0 | Header code [0x04060042] |- | 1 | 0 |- | 2 | principal_id |} =Response= {| class="wikitable..."

=Request=
{| class="wikitable" border="1"
|-
! Index Word
! Description
|-
| 0
| Header code [0x04060042]
|-
| 1
| 0
|-
| 2
| principal_id
|}

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