3dbrew - User contributions [en]

IPC

2023-10-21T07:33:02Z

Tekito256: Fix source code missing

The 3DS software stack follows a server/client architecture, where common functionality is provided by global server processes through interfaces called ''ports'' and ''services''. Applications can access this functionality by creating ''sessions'' to the provided services. Technically, this is implemented using ''interprocess communication'' (IPC).

== Concepts ==

=== Sessions ===

Sessions are communication channels consisting of a client and server, through which data can be exchanged in the form of a request and response, respectively. Through sessions, the standard [[#Command Structure|IPC command protocol]] is implemented. Clients use their client session handle to send IPC commands to the server using svcSendSyncRequest, while servers use svcReplyAndReceive to reply. Client sessions can't be used with svcReplyAndReceive. In both cases, the kernel takes care of transferring IPC command data from the [[Thread Local Storage]] of the sending thread to the TLS of the receiving thread. Sessions can be created through svcCreateSession, which provides the caller with the client and server handles.

Sessions are used in their raw form to implement [[FS:OpenFile|file handles]]. In this case, fs-module creates a raw session using svcCreateSession, and provides the "fs:USER" client with the resulting client session handle, keeping the server session handle for its own use. These sessions expose their [[Filesystem services#File service|own set of IPC commands]] which act on the file that was opened through fs:USER.

=== Ports ===

Ports are interfaces for managing multiple client sessions to the same high-level server. Ports are created through svcCreatePort, and can be global or private. A global port is created by passing a name for the port to svcCreatePort. Clients can start IPC sessions to global ports by connecting to the port using svcConnectToPort, passing the desired port name. If the port is private, it is not possible to create a session through svcConnectToPort - sessions can only be created if one has a handle to the port itself, obtained from the call to svcCreatePort. When a client wishes to connect to a port (i.e. create a session), the server must accept the new session using svcAcceptSession. The kernel notifies the server whenever a new session is incoming via the server's port handle. The server can wait for this notification through svcWaitSynchronization or svcReplyAndReceive.

The two global ports usually found on retail are "srv:" ([[Services|service manager]]) and "err:f" ([[ErrDisp]]).

=== Services ===

Services are an abstraction of ports that are managed by service manager. Services cannot be connected to through svcConnectToPort, as the underlying port is a private port. The service name is instead entirely handled by service manager, and the kernel is not aware of it. Clients are instead expected to open a session to a service using the "srv:" port command [[SRV:GetServiceHandle|GetServiceHandle]]. The client process must pass an access permission check for each service (by name) that it attempts to request a session with. These permissions are granted in the "service access control" of the title's [[NCCH/Extended Header#ARM11 Local System Capabilities|extended header]]. A service is registered with service manager using the command [[SRV:RegisterService|RegisterService]].

Internally, service manager creates services by creating a private port which it associates with the desired service name. The resulting server port handle is returned in the RegisterService response, for the server's own use (see ports). To create sessions to a service on behalf of a client, service manager uses svcCreateSessionToPort, passing the client port handle it obtained when creating the port, to the kernel. Service manager then returns the resulting session handle to the client in the GetServiceHandle response.

The majority of 3DS inter-process communication is implemented as services.

=== Shared Memory ===

Communication through port/service requests and replies may incur a big bottleneck when exchanging large amounts of data because the kernel needs to transfer the data between the two involved processes. There is hence a complementary feature to share the same physical memory between two processes. For this purpose, one process needs to create a block of shared memory using svcCreateMemoryBlock such that the other process can map it into its own virtual memory address space using svcMapMemoryBlock. The memory block handle for the latter is provided using a regular IPC command.

Many services use shared memory as a secondary command interface (e.g. [[GSP_Shared_Memory|GSP]]), the processing of which is triggered through an IPC request (cf. [[GSPGPU:TriggerCmdReqQueue]]).

== Message Structure ==

IPC requests are written to the [[Thread Local Storage]] at offset 0x80 and submitted using [[SVC|svcSendSyncRequest]]. If the kernel was able to dispatch the request, the server reply will be written to TLS+0x80 before svcSendSyncRequest returns. By convention, the second word of the response data is an error code (or 0 on success). IPC requests and IPC replies follow the same structure.

Every IPC message starts with a u32 header code. Parameters (if any) are written following this header. There are "normal parameters", which are fixed-size words, and there are "translate parameters", which are of flexible size and each of which begins with a header. The entire command has the following structure:
{| class="wikitable" border="1"
|-
! Word
! Size
! Description
|-
| 0
| 1
| Header code
|-
| 1
| x
| Normal parameters
|-
| 1+x
| y
| Translate parameters
|}

The IPC message header has the following structure:
{| class="wikitable" border="1"
|-
! Bits
! Description
|-
| 0-5
| Total size in words of the translate parameters (=y). Note that this is in general different from the number of translate parameters
|-
| 6-11
| Number of normal parameters (=x)
|-
| 12-15
| Unused
|-
| 16-31
| Command ID
|}

When calling svcSendSyncRequest, the command id specifies a function specific to the target service to call. When calling svcReplyAndReceive, the command ID is generally ignored. However if it's 0xffff (and 0 is passed for the reply target handle), the kernel will omit the IPC reply and just wait for incoming IPC requests.

Each translate parameter starts with a translation descriptor:
{| class="wikitable" border="1"
|-
! Bits
! Description
|-
| 1-3
| Translation type
|}

Translate parameters are modified/translated transparently by the kernel. They are used to transfer handles/buffers between the different processes.

The type of parameter is described by the bits 1-3 in the translation descriptor. Parameter types accepted for sending by the kernel are: 0, 1, 2, 5, 6, 7.

For replies, only 0, 1, 5, 6, 7 are allowed. In other words any type 2 fields must be zeroed before calling svcReplyAndReceive on the server-side. For replies, type 0, 1, and 2 are ignored. Types 5, 6, and 7 do something with the mem pointer upon reply. The type 0 descriptor can be used to ignore parameters. The number of parameters covered by a type-0 descriptor is (desc >> 26) + 1.

=== Handle Translation ===

Translation type 0 is used to send handles across processes. The corresponding translation descriptor has the following structure:
{| class="wikitable" border="1"
|-
! Bits
! Description
|-
| 4
| If set, the handles are closed for the caller. Interaction with bit5 unknown.
|-
| 5
| If set, the following handles are replaced by the process ID. Otherwise, translate each handle between client and server.
|-
| 26-31
| Number of handles following this descriptor (minus one).
|}

Usage examples:
{| class="wikitable" border="1"
|-
! scope="col" width="300" | Usual form
! Description
|-
| 0x00000000 <nowiki>|</nowiki> ((num_handles-1)<<26)

<handle 0>

<handle 1>
...
| Copies the given KHandles to the receiving process, i.e. creating new handles in the target process while keeping around the ones of the source process. When a handle value is 0x0, value 0x0 is written to the destination cmdbuf without doing any actual handle-transfer.
|-
| 0x00000010 <nowiki>|</nowiki> ((num_handles-1)<<26)

<handle 0>

<handle 1>
...
| Moves the given KHandles to the receiving process, i.e. creating new handles in the target process and closing the ones of the source process. When a handle value is 0x0, value 0x0 is written to the destination cmdbuf without doing any actual handle-transfer.
|-
| 0x00000020
<placeholder>
| Let kernel set value to calling process ProcessID.
|}

=== Static Buffer Translation ===

Each thread may set up up to 16 static buffer descriptors in their [[Thread Local Storage]] at offset 0x180. These contain information about buffers in the thread's memory space that may be used for information exchange for communication with other processes. In particular, a static buffer descriptor encodes the address and size of a buffer.

Using IPC requests, data can be transferred from any location in the source process to one of the static buffers set up in the target process. This is done using a translation descriptor of type 1, which is followed by a pointer to the source data. The translation descriptor has the following structure:

{| class="wikitable" border="1"
|-
! Bits
! Description
|-
| 1-3
| Translation type (characteristically 1)
|-
| 10-13
| Static buffer index of the receiving process
|-
| 14-31
| Size in bytes of the transferred data. Specifying an amount larger than the target static buffer will result in a kernelpanic.
|}

When encountering such a translation descriptor, the kernel will look up the static buffer address and size corresponding to the given index and (if the buffer can hold the requested amount of data) will copy the data to the specified location.

Note that the translation descriptor and static buffer descriptor share the same layout. However, it is unknown whether the kernel ever reads fields other than the buffer address and size when dealing with static buffer descriptors.

Usage examples:
{| class="wikitable" border="1"
|-
! scope="col" width="300" | Usual form
! Description
|-
| 0x00000002 <nowiki>|</nowiki> (size<<14) <nowiki>|</nowiki> (static_buffer_id<<10)
<ptr>
| The corresponding value contains a ptr to a buffer of said size, that should be copied to an already set-up buffer in destination process at [[Thread Local Storage]] offset 0x180 + static_buffer_id*8. The static_buffer_id is only 4 bits, making it possible for at most up to 16 buffers in total per thread.
|}

=== Buffer Mapping Translation ===

The IPC subsystem can temporarily map a whole buffer of the sender's memory into the receiver's memory space. This is useful for large buffers, for which the overhead of copying static buffer data around would be too expensive.

This kind of translation is enabled by setting bit3 in the translation descriptor. The other two bits of what's documented as the translation type above are used to specify buffer access permissions of the source process.

Buffers will get mapped at virtual address 0x04000000+ in the destination process. When this translation descriptor is submitted to the kernel through svcReplyAndReceive, the given buffer will be unmapped from the sending process(otherwise the buffer will be left mapped after the cmd-reply is finished). Regardless of the descriptor used here, the MMU-table entries for the source-process(from svcSendSyncRequest) buffers are not changed: memory permissions are left at the original while commands are being processed. The memory permissions for buffers at 0x04000000+ is always RW-, regardless of the actual memory permissions for the source-process buffer. Bitmask 0xFFF(low 12-bits) of the start address of each buffer for 0x04000000+ is the same as bitmask 0xFFF from the source-process buffer address.

The buffer address written into the destination cmdbuf by the kernel with svcSendSyncRequest is the allocated 0x04000000+ buffer. When doing the same with svcSendSyncRequest, the buffer address is the same one from the source cmdbuf(0x04000000+).

The first and last pages of the buffer at 0x04000000+ are allocated under the BASE memregion(with data being copied to/from the original source-process buffer as needed), with the rest being mapped to the original buffer physmem. When the source-process buffer is 0x1000-byte aligned, the first page for 0x04000000+ is mapped directly into the original buffer physmem instead of allocating BASE memory(likewise for the last page when the buffer size is 0x1000-byte aligned).

Each buffer at 0x04000000+ has 1 page of unmapped memory before and after the mapped memory, used for separating each buffer. Hence, the first buffer's page at 0x04000000+ is always mapped starting at 0x04001000 not 0x04000000.

{| class="wikitable" border="1"
|-
! Bits
! Description
|-
| 1-2
| Access permission flags for the source process: 1=read-only, 2=write-only, 3=read/write. Specifying 0 will cause a kernel panic.
|-
| 3
| Characteristically 1 for this translation type.
|-
| 4-31
| Size in bytes of the shared memory block.
|}

Usage examples:
{| class="wikitable" border="1"
|-
! scope="col" width="300" | Usual form
! Description
|-
| 0x00000008
| This command will cause a kernel panic.
|-
| <nowiki>0x0000000A | (size<<4)</nowiki>
<ptr>
| The corresponding value contains a ptr to a buffer of said size. The buffer specified by the source process must have read permission(tested on hardware with a read-only buffer). Used for input buffers.
|-
| 0x0000000C <nowiki>|</nowiki> (size<<4)
<ptr>
| The corresponding value contains a ptr to a buffer of said size. The buffer specified by the source process must have write permission. Used for output buffers. In the destination process with the buffer mapped at 0x04000000+, that buffer has same content as the buffer from the source buffer(like descriptor 0x0000000A). When handling command requests this is handled the same way as 0x0000000A, besides the descriptor type written into the dst cmdbuf and memory permissions.
|-
| 0x0000000E <nowiki>|</nowiki> (size<<4)
<ptr>
| The corresponding value contains a ptr to a buffer of said size. The buffer specified by the source process must have read permission during cmd-request handling(write permission is checked during cmd-reply handling for the original buffer). This isn't known to be used by any processes. When handling command requests this is handled the same way as 0x0000000A, and for handling command replies this is handled the same way as 0x0000000C(besides the descriptor type written into the dst cmdbuf for both of these).
|}

=== Usage Examples for other Translation Types ===

{| class="wikitable" border="1"
|-
! Type
! scope="col" width="300" | Usual form
! Description
|-
| 2
| 0x00000004 <nowiki>|</nowiki> (size<<8) <nowiki>|</nowiki> (static_buffer_id<<4)
<ptr>
| This is typically used for RW buffers over PXI, but any process can use this. The address written to the destination cmd-buf is a phys-addr for a table located in the corresponding static buffer of the receiving process (which must be provided by the latter, otherwise the kernel dereferences NULL). Each static buffer needs to be page-aligned and musn't exceed a page's length (kernelpanic otherwise). This table contains the phys-addrs for the actual data, the array entries have the following format: {u32 *datachunk_physaddr, u32 datachunk_bytesize}.
|-
| 3
| 0x00000006 <nowiki>|</nowiki> (size<<8) <nowiki>|</nowiki> (static_buffer_id<<4)
<ptr>
| Same as above except for read-only buffer. Prior(?) to the kernel version which implemented memory-permission checking for PXI buffers, this was unused and hence triggered a kernelpanic.
|}

== SVCs ==

=== svcReplyAndReceive ===

'''Signature:'''
Result ReplyAndReceive(s32* index, Handle* handles, s32 handleCount, Handle replyTarget)

In a single operation, sends a IPC reply and waits for a new request. <code>handles</code> should be a pointer to an array of <code>handleCount</code> handles.TODO: Are only port/session handles supported?
<code>replyTarget</code> should contain a handle to the session to send the reply to. (This is usually the session from which we received the previous request.)
If <code>replyTarget</code> is 0, no reply and the call will simply wait for an incoming event.TODO: It doesn't seem like the 0xFFFF0000 command id mentioned in the above sections is necessary, but needs confirmation.

Upon returning, <code>index</code> will contain an index into <code>handles</code> specifying which object changed state.
If it's a server port endpoint, it means that there is a new incoming connection on that port which should be accepted using svcAcceptSession.
If it's a server session endpoint it means that we received a request from that session and should process and then reply to it by calling svcReplyAndReceive again with <code>replyTarget</code> set to that session's handle.

An example of a server svcReplyAndReceive loop is:

#define MAX_CLIENTS 4
Handle server_port = ...;
s32 requesting_index;
Handle handles[1 + MAX_CLIENTS] = { server_port };
s32 connected_clients = 0;
Handle reply_target = 0;

while (true) {
Result res = svcReplyAndReceive(&requesting_index, handles, 1 + connected_clients, reply_target);

if (res == 0xC920181A) {
// Session was closed by remote
// TODO: Handle disconnects
reply_target = 0;
continue;
}

if (requesting_index == 0) {
// New connection in server_port
ASSERT(connected_client < MAX_CLIENTS);
svcAcceptSession(&handles[1 + connected_clients++], server_port);
reply_target = 0;
continue;
}

reply_target = handles[requesting_index];

// Handle command here and write reply to command buffer
}

Extdata

2022-01-19T11:03:17Z

Tekito256: add jpn title

This page describes the format and encryption of extdata, "extra data" stored on SD card and NAND, at:

* <code>nand/data/<ID>/extdata/<ExtdataID-High></code>
* <code>sdmc/Nintendo 3DS/<ID0>/<ID1>/extdata/<ExtdataID-High></code>

ExtdataID-High is always 00000000 for SD, and always 00048000 for NAND. Regular apps can only mount SD extdata using the same extdataID which is stored in the CXI exheader. Therefore, regular apps which have the exheader extdataID set to zero can't use extdata. This restriction doesn't apply for shared extdata with extdataID high bitmask 0x48000 stored on NAND. System apps with a certain access right can mount arbitrary extdata. All NAND extdata is shared extdata, while all SD extdata is normal extdata.

All data in this page is little-endian. All "unused / padding" fields can contain uninitialized data unless otherwise specified.

= Format =

To avoid confusion, the terms '''device directory / file''' and '''virtual directory / file''' are used with the following meanings:

* '''Device directory / file''' are the real directory / file stored on SD / NAND that can be seen under path <code>nand/data/<ID>/extdata/</code> or <code>sdmc/Nintendo 3DS/<ID0>/<ID1>/extdata/</code>.
* '''Virtual directory / file''' are directory / file stored inside extdata virtual file system, which can be seen by applications in the mounted extdata archives.

An extdata consists of several device directories and files, which forms a file system consisting of multiple virtual directories and files.

An extdata with ID <code>ExtdataId</code> has the following device files:

* <code>.../extdata/<ExtdataID-High>/<ExtdataId-Low>/Quota.dat</code> (optional)
* <code>.../extdata/<ExtdataID-High>/<ExtdataId-Low>/<SubDirID>/<SubFileID></code>

Note:

* All device files are [[DISA and DIFF|DIFF containers]]. '''All format description below is about the inner content of the containers'''. Please unwrap these files first according to the DIFF format description before reading them using the extdata format description below.
* <code>Quota.dat</code> is only observed existing for NAND shared extdata.
* <code><SubDirID></code> and <code><SubFileID></code> are 8-digit hex strings.
* Device file with <code>SubDirID = SubFileID = 00000000</code> doesn't exist. Other ID combinations can exists.
* Device file with <code>SubDirID = 00000000</code> and <code>SubFileID = 00000001</code> is the VSXE metadata file and must exist.
* Other files, besides <code>Quota.dat</code> and <code>00000000/00000001</code>, are normal sub files, are these device files one-to-one correspond to virtual files. They contain raw virtual file data in the DIFF inner content.
* <code>SubDirID = 00000000</code> is usually the only one device directory that can be seen. See [[#Device Directory Capacity]] for more information.

== Quota File ==

The inner data of <code>Quota.dat</code> is 0x48 bytes with the following format. The file seems to limit the extdata total size.

{| class="wikitable" border="1"
! Offset
! Length
! Description
|-
| 0x00
| 4
| Magic "QUOT"
|-
| 0x04
| 4
| Magic 0x30000
|-
| 0x08
| 4
| 0x1000, block size
|-
| 0x0C
| 4
| Always 126. Probably device directory capacity. See the [[#Device Directory Capacity]] more information.
|-
| 0x10
| 4
| Always 0?
|-
| 0x14
| 4
| Max number of blocks
|-
| 0x18
| 4
| Always 0?
|-
| 0x1C
| 4
| Free blocks remained
|-
| 0x20
| 4
| Always 0?
|-
| 0x24
| 4
| Always 0?
|-
| 0x28
| 4
| Free blocks remained + (blocks occupied by the recently mounted file, specified by the ID below (0 if recently deleted))
|-
| 0x2C
| 4
| Always 0?
|-
| 0x30
| 4
| ID of most recently mounted file. Same as the one in [[Inner_FAT#Filesystem Header]]
|-
| 0x34
| 4
| Always 0?
|-
| 0x38
| 4
| Always 0?
|-
| 0x3C
| 4
| Always 0?
|-
| 0x40
| 4
| Size in bytes of most recently mounted file (device file size). 0 if recently deleted
|-
| 0x44
| 4
| Always 0?
|}

== Device Directory Capacity ==

A device directory in an extdata (a <code><SubDirID></code> directory) seems to have a maximum number of device files it can contain. For SD extdata, this maximum number seems to be hard-coded as 126. For NAND extdata, the number is probably indicated by a field in Quota.dat, which is, again, always 126 as observed. 3DS FS tries to put all device files in the device directory <code>00000000</code> if possible, and only when more than 126 files needed to add, a second device directory <code>00000001</code> and so on are created. However, few extdata have such amount of files to store, so the behavior lacks of use cases to confirm.

The number 126 is probably from some kind of other capacity of 128 with <code>"."</code> and <code>".."</code> entries reserved. It is theorized that this is to keep a FAT directory table, with 0x20 bytes for each entry, in one 0x1000 cluster. The motivation is unclear.

== VSXE Filesystem ==

This is one variant of the [[Inner FAT|FAT filesystem]]. Please refer to its page for the description of the filesystem. In general, device file <code>00000000/00000001</code> contains the metadata of the filesystem, while other device files (except for the Quota file) contains normal sub-files

Each non-dummy file entry corresponds to a device file. The path to the device file is generated by the following computation:

<pre>// See previous section about this capacity
const uint32_t device_dir_capacity = 126;

// entry index is the index in the file entry table, with the first dummy entry as
// index = 0, which is never used for a real file.
// file_index = 1 is reserved for the VSXE Filesystem Metadata itself, so real files
// started from file_index = 2.
uint32_t file_index = entry_index + 1;

uint32_t SubDirID = file_index / device_dir_capacity;
uint32_t SubFileID = file_index % pdevice_dir_capacity;

char extdata_path[...]; // ".../extdata/<ExtdataID-High>/<ExtdataId-Low>"
char device_path[...]; // output path
sprintf(device_path, "%s/%08x/%08x", extdata_path, SubDirID, SubFileID);
</pre>
When mounting extdata, the unique identifier is used to match the ID stored in subfile's [[DISA and DIFF#DIFF header|DIFF header]]. If the ID doesn't match, mounting will fail.

== Virtual File System Structure ==

When extdata is created, these are ''always'' created regardless of whether the title actually uses them.

* <code>/icon</code> This virtual file contains the extdata icon displayed in data management. This icon can only be written to by titles when creating extdata, titles would have to recreate extdata to change the icon. This file can't be read directly, instead it is read via FS:ReadExtSaveDataIcon.
* <code>/user/</code> This virtual directory contains the title's actual extdata files.
* <code>/boss/</code> This virtual directory can contain SpotPass content. SpotPass content can only be downloaded to this <code>/boss</code> virtual directory.

User extdata and SpotPass extdata use separate mount points at <code>/user</code> and <code>/boss</code>. Therefore one mount can't access the other virtual directory, and also can't access <code>/icon</code>.(The title's SpotPass extdata can be mounted by the title itself, if it uses SpotPass)

Other optional but notable directories include:

* <code>/user/ExBanner</code> This virtual directory can optionally store extended banners. When this is available, this banner is displayed instead of the CXI ExeFS banner. <code>COMMON.bin</code> stores the common exbanner, while <code><regionlang_code>.bin</code> stores an optional separate region/language specific banner.(regionlang_code can be "JPN_JP", "USA_EN", etc)

== SD Extdata ==
Usually the ExtdataID low is in the format '00<Unique ID>'

{| class="wikitable" border="1"
|-
! JPN ExtdataID
! USA ExtdataID
! EUR ExtdataID
! Description
! Extdata images
|-
| 00000082
| 0000008f
| 00000098
| [[Home Menu]] extdata, this contains home-menu savedata and cached icons for applications.
|
|-
| 00000200
| 00000210
| 00000220
| [[System_Settings|System Settings]] extdata added with [[2.0.0-2]].
|
|-
| 00000207
| 00000217
| 00000227
| [[Mii Maker]], contains an ExBanner
| [https://dl.dropbox.com/u/20520664/extdata00000217.zip cleartext]
|-
| 00000208
| 00000218
| 00000228
| Streetpass Mii Plaza
| 11 mb big!
|-
| 00000209
| 00000219
| 00000229
| [[eShop]], contains store music in AAC format.
|
|-
| 0000020b
| 0000021b
| 0000022b
| Nintendo Zone
|
|-
| 0000020d
| 0000021d
| 0000022d
| Face Raiders, likely contains an ExBanner
|
|-
| 000002cc
| 000002cd
| 000002ce
| [[Home Menu]] theme
|
|-
| ?
| 000004aa
| 000004ab
| Nintendo Video Extra Data
This is where the video files are stored, and [[Nintendo_Video|includes]] the thumbnail, the description, and possibly some checksum info in each video file stored in the extdata images. There are always 9 files within the subdirectory "00000000" of this folder, even without any videos downloaded. The files are "00000001" - "00000009", and "00000003" - "00000008" have the same filesize of 50.7 MB. It is possible to restore the older videos by overwriting all the files within this directory. Provided of course you have made a backup of the files before hand, by copying all the files within this directory to your computer. As far I'm aware its not possible to mix and match the files in order to get certain videos in one grouping, ie. having all 3 Zelda orchestral recordings in one group of 4 Nintendo videos.
|
|-
|00000306
|00000308
|00000307
|Mario Kart 7
|
|-
| 0000030b
| 0000030d
| 0000030c
| Nintendogs + Cats
|
|-
| 00000326
| 00000326
| 00000326
| Pokédex 3D
|
|-
| 00000305
| 0000032d
| 0000033c
| Super Street Fighter IV 3D
|
|-
| 00000328
| 00000358
| 0000033b
| Ridge Racer 3D
|
|-
| ?
| 0000034d
| 00000402
| Samurai Warriors Chronicles
|
|-
| ?
| 0000034f
| 0000038a
| Dead or Alive Dimensions
|
|-
| 00000481
| N/A
| N/A
| Monster Hunter Tri G (Download-Quests)
|
|-
| ?
| 00000517
| 00000518
| Swapnote
|
|-
| 0000055d
| 0000055d
| 0000055d
| Pokémon X Pokémon Y
|
|-
| ?
| 00000725
| 00000724
| Ambassador Certificate
|
|-
| ?
| ?
| 000007af
| New Super Mario Bros. 2
|
|-
| ?
| 00000863
| 00000864
| Animal Crossing: New Leaf
|
|-
| ?
| 00000a85
| 00000a86
| Professor Layton and the Miracle Mask Professor Layton and the Azran Legacy
German Version ExtdataID is 00000a87
|
|-
| ?
| ?
| 00000b4f
| Fullblox / Crashmo
|
|-
| ?
| ?
| 00000ba9
| Pokémon Mystery Dungeon: Gates to Infinity
|
|-
| ?
| ?
| 00000c24
| Denpa men
|
|-
| 00000c73
| 00000c73
| 00000c73
| Save Data Transfer Tool
|
|-
| ?
| ?
| 00000d9a
| Donkey Kong Country™ Returns 3D: Trailer
|
|-
| ?
| ?
| 00000ea6
| Etrian Odyssey IV
|
|-
| ?
| 00000edf
| 00000ee0
| Super Smash Bros. for Nintendo 3DS
|
|-
| ?
| 00000f14
| 00000f1e
| Phoenix Wright: Ace Attorney - Dual Destinies
|
|-
| ?
| 00001007
| 00001005
| Professor Layton vs Phoenix Wright: Ace Attorney
|
|-
| ?
| ?
| 00001062
| Nintendo Pocket Football Club
|
|-
| ?
| ?
| 0000111c
| Yoshi's New Island
|
|-
| ?
| ?
| 00001131
| Fantasy Life
|
|-
| 000011c5
| 000011c5
| 000011c5
| Pokémon Omega Ruby Pokémon Alpha Sapphire
|
|-
| ?
| ?
| 000012ca
| Mario vs. Donkey Kong: Tipping Stars
|
|-
| ?
| ?
| 00001499
| Korg DSN-12
|
|-
| ?
| ?
| 000014f2
| Animal Crossing: Happy Home Designer
|
|-
| 000014d1
| 000014d1
| 000014d1
| [[Home Menu]] badge
|
|-
| ?
| ?
| 00001632
| Fullblox / Stretchmo
|
|-
| ?
| ?
| 00001646
| Pokémon Rumble World
|
|-
| 00001648
| 00001648
| 00001648
| Pokémon Sun Pokémon Moon
|
|-
| 0000165c
| 0000165c
| 0000165c
| [[Home Menu]] saved theme layouts
|
|-
| 000016C6
| ?
| 00001678
| Yo-kai Watch
|
|-
| ?
| ?
| 000018fa
| Phoenix Wright: Ace Attorney - Spirit of Justice
|
|-
| ?
| ?
| 0000198f
| Animal Crossing: New Leaf - Welcome amiibo
|
|-
| ?
| ?
| 00001a05
| Super Mario Maker
|
|-
| ?
| ?
| 00001a2e
| Swapdoodle
|
|}

== NAND Shared Extdata ==
{| class="wikitable" border="1"
|-
! ExtdataID
! Description
|-
| 0xe0000000
| Home Menu attempts to open this archive during boot, if [[FS:OpenArchive]] doesn't return an error Home Menu seems to then launch the [[System Transfer]] application. Home Menu doesn't actually use this archive at all except for checking whether it exists.
|-
| 0xf0000001
| NAND JPEG/MPO files and phtcache.bin from the camera application are stored here. This also contains UploadData.dat.
|-
| 0xf0000002
| NAND M4A files from the sound application are stored here
|-
| 0xf0000009
| Used for [[BOSS_Services|SpotPass]] content storage for [[News_Services|notifications]].
|-
| 0xf000000b
| Contains idb.dat, idbt.dat, gamecoin.dat, ubll.lst, CFL_DB.dat, and CFL_OldDB.dat. These files contain cleartext [[Mii_Maker|Miis]] and some data relating (including cached ICN data) to Play/Usage Records.
|-
| 0xf000000c
| Contains bashotorya.dat and bashotorya2.dat.
|-
| 0xf000000d
| Home Menu SpotPass content data [[BOSS_Services|storage]].
|-
| 0xf000000e
| Contains [[VersionList|versionlist.dat]], used by Home Menu for the software update notification added with [[7.0.0-13]].
|}

==== Shared Extdata 0xf000000b gamecoin.dat ====
{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
|-
| 0x0
| 0x4
| Magic number: 0x4F00
|-
| 0x4
| 0x2
| Total Play Coins
|-
| 0x6
| 0x2
| Total Play Coins obtained on the date stored below. When the below date does not match the current date, this field is reset to zero, then the date(and other fields) are updated. Once this value is >=10, no more Play Coins can be obtained until the current date changes.
|-
| 0x8
| 0x4
| Total step [[PTM:GetTotalStepCount|count]] at the time a new Play Coin was obtained.
|-
| 0xC
| 0x4
| Step count for the day the last Play Coin was obtained, for that day's step count(same as the step count displayed by home-menu when this file was updated).
|-
| 0x10
| 0x2
| Year
|-
| 0x12
| 0x1
| Month
|-
| 0x13
| 0x1
| Day
|}

The above date stores the last time new Play Coin(s) were obtained. The contents of this file is updated by home-menu. [[PTM:GetTotalStepCount]] is not checked constantly, after home-menu boot this is only checked when waking from sleep-mode. Each time home-menu updates the contents of this file, home-menu will set the Play Coin total to 300 if it's higher than the 300 Play Coin limit.

[[Home Menu]] loads this file / opens this archive during [[Home Menu|startup]]. When accessing this file fails, like when the file/archive is corrupted(or at least on older system-versions), the result is a brick due to Home Menu using [[SVC|svcBreak]]. [[User:Yellows8|Yellows8]] bricked a 3DS this way due to corruption via invalid [[FSFile:Write]] flush flags. When opening this extdata archive(0xf000000b) fails, Home Menu executes svcBreak.

==== Shared Extdata 0xf000000b ubll.lst ====
List of blocked users.

Empty space is filled with 0xC-long sequences of 00 00 ... 07

=== Tools ===

* [https://github.com/wwylele/3ds-save-tool 3ds-save-tool] - Extract/verifies extdata