'''StreetPass''' is a feature that allows your 3DS to connect with other 3DS consoles using WiFi in standby mode.
It can be used to share Mii(s) on Mii Plaza for example. Applications' StreetPass data are stored in the CECD module's NAND savegame, applications can move received StreetPass data to an arbitrary savegame. Wifi infrastructure with APs are used to communicate where the data-frames are encrypted with WPA2 CCMP, like [[NWM_Services|UDS]]/[[Download Play]].

== WiFi Probe Request Frame ==

Whenever the 3DS is woken from sleep (or turned on), and WiFi is enabled, it sends out a 802.11 Probe Request which include all saved access points, as well a probe to an SSID containing an arbitrary string of data, such as "ic[kSvm9s@*cYD>/~IEVj\(fGG;qDo8j". This string changes at least daily, and most likely every time the device is woken up.

The MAC address used for these probes is the static MAC address found in the System Settings application. Unlike the StreetPass MAC address, it will not change over time. This MAC address OUI also differs from the one used in StreetPass.

== CCMP Key ==
The StreetPass local-WLAN CCMP data-encryption key is generated by the StreetPass CECD module, where the CCMP key is the 16-byte output from encrypting an all-zero block with AES-CTR via [[PS:EncryptDecryptAes]], with keytype6. The CTR is the first 0x10-bytes from a SHA1-HMAC hash. The SHA1-HMAC key is a 17-byte text string including the NULL-terminator, a seperate HMAC key is used for retail/dev-units, this is determined via [[Configuration_Memory#ENVINFO|ENVINFO]] bit0. The data hashed with SHA1-HMAC is a 0x1C-byte buffer, which is described below.

=== Hash Block ===
{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
|-
| 0x0
| 0x8
| 8-byte StreetPass consoleID for the host, from the probe frames.
|-
| 0x8
| 0x8
| 8-byte StreetPass consoleID for the client, from the probe frames.
|-
| 0x10
| 0x6
| MAC address for host.
|-
| 0x16
| 0x6
| MAC address for client.
|}

== StreetPass Exchange ==

While StreetPass is enabled, the 3DS constantly sends out Probe Requests with an SSID of "Nintendo_3DS_continuous_scan_000". Unlike beacons, which are actively advertising the device's presence, the 3DS is essentially actively looking for other 3DSes. This design is likely to limit impact to non-3DS WiFi capable devices. Each Probe Request contains basic information about that 3DS, including an identifier, and active StreetPass services. If another 3DS is in range, the second 3DS (#2) will respond with a Probe Response, to which the original 3DS (#1), and of the receiving device with every frame thereafter, will respond with an 802.11 Acknowledgement. 3DS(#1) then sends an 802.11 Action frame, as well as an additional Probe Request. The second 3DS sends back another Probe Response that begins the encrypted exchange between the two devices, no authentication/association is done here.

The MAC address used in sleep-mode seems to change every time there's a StreetPass hit, as well as the last 8-bytes(StreetPass consoleID) of the Nintendo tag data. The MAC address + 8-byte StreetPass consoleID is seen to change every time the user enters and exits and Settings application if they have not had a StreetPass in an observed time period of 24 hours. It is uncertain how the 3DS determines when it can do a StreetPass again with another 3DS, or what information is actually used to track that. It may be related to how long that 3DS was in range constantly/out of range. 3DSes that are constantly in range of each other in sleep-mode, usually do StreetPass every 11 hours.

=== Probe Request Frame ===

Using Wireshark tool with a WiFi card in monitor mode allow you to see the data used to scan for other 3DS in the range. The below is a broadcast probe request from an 3DS while in standby mode, with SSID "Nintendo_3DS_continuous_scan_000". This SSID remains consistent across all 3DS units. This frame also contains a custom variable length Nintendo tag, which contains information regarding the offered StreetPass services. The sequence numbers for these probe request increment by 3 for every probe, until another 3DS responds with a probe response.

0000 00 00 1a 00 2f 48 00 00 19 7d 19 de 2a 00 00 00 ..../H...}..*...
0010 12 16 9e 09 a0 00 c9 02 00 00 40 00 00 00 ff ff ..........@.....
0020 ff ff ff ff da 6b f7 22 f3 77 ff ff ff ff ff ff .....k.".w......
0030 40 77 00 20 4e 69 6e 74 65 6e 64 6f 5f 33 44 53 @w. Nintendo_3DS
0040 5f 63 6f 6e 74 69 6e 75 6f 75 73 5f 73 63 61 6e _continuous_scan
0050 5f 30 30 30 01 08 82 84 8b 0c 12 96 18 24 32 04 _000.........$2.
0060 30 48 60 6c dd 15 00 1f 32 01 11 05 00 02 08 00 0H`l....2.......
0070 00 f0 08 c8 34 6e 05 0f c9 c6 80 5b 6f bc 5a ....4n.....[o.Z

==== Nintendo Tag Format ====

The offsets, in bytes, mentioned in the table below start at the beginning of the Nintendo tag ID, which is variable in length, and can be found right after the Vendor Specific OUI type of the 802.11 frame, which is often seen as a byte of "01". Each one of the elements are discussed in more detail after the table. Note that this table represents a current theory on what each of the fields represent, with the argument stated in the corresponding sections.

{| class="wikitable" border="1"
|-
! Offset
! Length
! Purpose
! Description
! Example
|-
| 0x00
| 0x01
| '''Protocol Identification'''
| May be for protocol identification. All captures thus far show this value at 17, hexadecimal 11.
| 11
|-
| 0x01
| 0x01
| '''StreetPass Service Length'''
| Length in bytes of only the StreetPass Services field.
| 05
|-
| 0x02
| 0x05
| '''StreetPass Services'''
| Starting at the 0x02 offset, it appears to be a list of StreetPass services, each in length of 5 bytes. This continues on depending on the number of services the user has enabled at the time.
| 00 02 08 00 00
|-
| varies
| 0x02
| '''Unknown'''
| At the end of the StreetPass Services field is a two byte field that is the same among all devices thus far. Its purpose is unknown.
| f0 08
|-
| -0x08
| 0x08
| '''StreetPass consoleID'''
| Seen to change when the Settings app is used if there has not been a StreetPass tag recently. Also may change after each StreetPass hit and system power-off?
| c8 34 6e 05 0f c9 c6 80
|}

===== Protocol Version =====

Appears to represent a protocol version, or device identification. This field remains consistent on all devices, despite variable enabled StreetPass services or length of the tag. Could also represent region.

===== StreetPass Service Length =====

This field is used to indicate the length of the StreetPass Services field. Removing and adding services has shown this field to increment and decrement in 5 bytes, or 11 bytes depending on the game. The StreetPass Services field has then expanded or reduced accordingly.

===== StreetPass Services =====

The third field in the protocol header appears to be an arbitrary length list of StreetPass services enabled on the device. Each StreetPass service seems to be identified by a 5-byte ID. If you enable or disable services, the number of 5-byte IDs grows and shrinks within this list. Observed service IDs include:

Mii Plaza: 00 02 08 00 00
Ridge Racer: 00 03 58 00 30
Sims 3: 00 03 65 00 30
Street Fighter: 00 03 05 00 02 (FF FF FF FF FF FF)

The first 4 bytes are the titleID of the service, the last byte seems to contain flags.

The last byte (flags) have been observed between those possibilities :

00000000
00000010
00010000
00100000
00110000
00110010

Only the bits 2,5,6 were used.
When set, the bit n°2 indicates the presence of a followinf 6-byte field filled with 0xff.

Some services have a 6-byte field succeeding the StreetPass service that is just FF bytes (e.g. FF FF FF FF FF FF). The purpose of these is unknown, although may be used as data for a service, or as separator of some sort for different types of StreetPass services.

Observed services (leading titleID 0x00 removed, 6*0xff ignored) on 68K probe requests between 2013-08-24 and 2014-06-29 in various european locations.

The fact that a same titleID can have different flags should be noted.

0db6-00100000 5
0db6-00110000 20

{| class="wikitable" border="1"
|-
! Occurrences
! TitleID
! Flags
|-
| 131
| 0208
| 00000000
|-
| 58
| 0516
| 00010000
|-
| 56
| 053f
| 00100000
|-
| 55
| 0306
| 00100000
|-
| 44
| 0862
| 00110000
|-
| 26
| 09f1
| 00110000
|-
| 20
| 0db6
| 00110000
|-
| 18
| 0516
| 00110000
|-
| 18
| 0205
| 00110010
|-
| 17
| 0ec4
| 00110000
|-
| 17
| 0300
| 00110000
|-
| 16
| 055d
| 00110000
|-
| 13
| 08d3
| 00010000
|-
| 13
| 053b
| 00100000
|-
| 12
| 0916
| 00100000
|-
| 12
| 07ad
| 00100000
|-
| 12
| 0306
| 00110000
|-
| 12
| 0300
| 00100000
|-
| 11
| 0916
| 00110000
|-
| 9
| 0b1d
| 00110000
|-
| 8
| 0ec4
| 00100000
|-
| 7
| 080f
| 00110000
|-
| 7
| 07c8
| 00100000
|-
| 6
| 038a
| 00100000
|-
| 5
| 0f30
| 00110000
|-
| 5
| 0db6
| 00100000
|-
| 5
| 0910
| 00110000
|-
| 5
| 0862
| 00100000
|-
| 5
| 053f
| 00110000
|-
| 5
| 0522
| 00110000
|-
| 4
| 07ad
| 00110000
|-
| 3
| 0ae2
| 00110000
|-
| 3
| 09f1
| 00100000
|-
| 3
| 08c5
| 00110000
|-
| 3
| 038c
| 00000000
|-
| 3
| 033b
| 00100000
|-
| 3
| 030b
| 00100000
|-
| 2
| 0ba9
| 00110000
|-
| 2
| 0a53
| 00110000
|-
| 2
| 08d3
| 00100000
|-
| 2
| 07ad
| 00010000
|-
| 2
| 0751
| 00110000
|-
| 2
| 0402
| 00100000
|-
| 1
| 0f82
| 00110000
|-
| 1
| 0f5b
| 00110000
|-
| 1
| 0e7f
| 00110000
|-
| 1
| 0bff
| 00110000
|-
| 1
| 0b1d
| 00100000
|-
| 1
| 0ad6
| 00010000
|-
| 1
| 0a90
| 00110000
|-
| 1
| 0a05
| 00100000
|-
| 1
| 073c
| 00110000
|-
| 1
| 06da
| 00100000
|-
| 1
| 05aa
| 00110000
|-
| 1
| 05a5
| 00110000
|-
| 1
| 053b
| 00110000
|-
| 1
| 04ca
| 00110000
|-
| 1
| 038a
| 00110000
|-
| 1
| 033b
| 00110000
|-
| 1
| 030b
| 00110000
|-
| 1
| 0305
| 00000010
|}

===== Unknown 2-byte Field =====

The purpose of this field is not known yet. It has remained the same across all devices thus far. The value has always been observed as '''f008'''.

===== StreetPass consoleID =====

When there's a StreetPass hit, and no StreetPass data changed on either of the 3DSes, no data is transferred besides probes? After turning off power, then powering on and entering sleepmode, the MAC doesn't change from prior to power off but the last 8-bytes of the Nintendo tag changes. This tag has been seen to not be sequential over time. After one of the new StreetPass content is handled, (running one of the StreetPass titles etc) this 8-byte StreetPass consoleID changes?

=== Initial Probe Response Frame ===

If a 3DS (#2) receives another device's probe request and has not yet tagged that device in an arbitrary amount of time (~12 hours), the receiving 3DS (#2) will respond with a Probe Response frame. The destination MAC address is the StreetPass MAC address of the 3DS (#1) that was transmitting the probe request, while the receiving device sets its StreetPass MAC address as the source address. This is important to note because further exchanges may cease using destination and/or source addresses.

In the probe response, the 3DS (#2) appears to offer a channel of 1, 6, or 11. Different channels have been seen offered between the same set of 3DS for each StreetPass. Offered channels, and channel range most likely varies by region.

The StreetPass Probe Response frame contains the same Nintendo tag in Probe Requests of the device that is transmitting the Probe Response frame.

=== Subsequent Probe Request and Response Frames ===

The 3DS (#1) that the Initial Probe Response is directed to will send an 802.11 Action frame back to the device. The sequence numbers at this point stop stepping up by 3, and instead increase by one based from each originating device's SN. It will then send another Probe Request, this time sent directly to the responding 3DS (#2) by specifying its MAC address in the destination field, and setting its own MAC address in the source address field. It also does not have a SSID specified in the frame, except the frame will contain a BSSID with the value of the 3DS (#2) that responded to the initial Probe, and thus acts as the master in the 802.11 exchange.

== StreetPass Spoofing ==

A streetpass "AP" was spoofed with hostapd by setting the SSID to "Nintendo_3DS_continuous_scan_000", with the extra Nintendo tag from another 3DS' probe request. Like 3DS<>3DS communications, the 3DS didn't authenticate or associate with the host. Streetpass communications use CCMP encryption. Eventually the 3DS stops communicating with the host since the host doesn't reply to any of the data frames, then sends a 802.11 "Action" frame, with category ID 0x7f and Nintendo's vendor ID: 00 1f 32.(However the 3DS keeps communicating with the above process repeatedly)
Communication with two 3DSes are the same as above except there's actual encrypted data sent to/from both consoles, unlike the fake host.

==StreetPass Relay==
This feature was implemented in version [[6.2.0-12]].
It was probably controlled over the policylist

[[Category:Nintendo Software]]

2024-04-01T06:44:50Z

Meleemeister: /* Content Header */

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

SpotPass Internet communications are mostly HTTPS transfers.

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

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

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

In some cases the BOSS module will add the following URL parameter to HTTPS requests, when connected to a [[Nintendo Zone]] AP: "ap=<NZoneApNum>" or when using a specific [[Cfg:GetSystemModel|system model]]: "tm=<SystemModelNumber>". The Old 3DS and Old 3DS XL don't set this value.

== policylist ==
Every time the system connects to the wifi AP, the BOSS ("Background online storage service" = SpotPass) module itself will download the cleartext xml policylist: "https://nppl.c.app.nintendowifi.net/p01/policylist/3/<countrycode>". This policylist contains a list of SpotPass tasks for certain titles. This policylist can control whether the specified tasks are processed at all.

As of the policylist updated 2017-11-08, this stops the <tt>OlvNotf</tt> (Miiverse notification sync) task for <tt>000400300000bc00</tt>, <tt>000400300000bd00</tt>, <tt>000400300000be00</tt> for all regions and <tt>basho0</tt> for the [[Home Menu]]. Japan also has the <tt>9ER_NTD</tt> task blocked for いつの間にテレビ (<tt>0004000000034700</tt>).

== User Agent ==

The default user-agent used for SpotPass HTTPS requests (including the policylist) has the following format:

<tt><user agent codename>-<user agent version>/<printed hex u64 [[CfgS:GetLocalFriendCodeSeed|LocalFriendCodeSeed]]>-<printed hex u64 [[FRDU:GetMyFriendKey|Friend]] [[FRDU:PrincipalIdToFriendCode|Code]]>/<text [[CVer|system]] [[NVer|version]]>/<unknown decimal value>/<[[Cfg:GetSystemModel|system model number]]></tt>

The codename can be set to either <tt>PBOS</tt> (Production BOSS?) or <tt>DBOS</tt> (Development BOSS?) depending if the console is a [[Configuration_Memory#UNITINFO|retail]] unit. As of system version 11.17, the user agent version is hardcoded to 8.0 and the decimal value is set to 62452 (0xF3F4).

No user-agent is used for plaintext HTTP requests with SpotPass.

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

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

== BOSS Sysmodule Savegame==
See [[BOSS Savegame]]

== Content Container ==

SpotPass content must use this container to encrypt the payload and sign it, for content downloads. The cleartext content is stored in [[extdata]]. The format of these headers is big-endian.

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

Data following the BOSS header is encrypted with AES-CTR. The AES key that is used is stored in [[AES_Registers#Keyslots|keyslot 0x38]]. The first 12 bytes of the IV are from offset 0x1C of the header, while the last 32-bit integer of the IV in big-endian is 0x1. The IV from the header is random per file, and an unique random IV is used each time the content is updated. The cleartext data begins with the content header.

=== Content Header ===
{| class="wikitable"
|-
! Offset
! Length
! Description
|-
| 0x0
| 0x10
| ?
|-
| 0x10
| 0x2
| Number of payload contents (Payload Content Header + Payload)
|-
| 0x12
| 0x20
| SHA-256 hash
|-
| 0x32
| 0x100
| RSA-2048 signature over the above hash
|}

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

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

=== Payload Content Header ===
{| class="wikitable"
|-
! Offset
! Length
! Description
|-
| 0x0
| 0x8
| ProgramID
|-
| 0x8
| 0x4
| Usually zero?
|-
| 0xC
| 0x4
| Content datatype, used for filtering with [[BOSSU:GetNsDataIdList]].
Usually 0x10001? (observed 0x20001 in eShop strings)
|-
| 0x10
| 0x4
| Size of the payload after this header
|-
| 0x14
| 0x4
| [[BOSS_Services|NsDataId]], used for generating the extdata filepath.
|-
| 0x18
| 0x4
| Probably some version field for the payload
|-
| 0x1C
| 0x20
| SHA-256 hash
|-
| 0x3C
| 0x100
| RSA-2048 signature over the previous SHA-256 hash
|}

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

The hash at offset 0x1C hashes the 0x1C-byte data at offset 0x0 followed by a zero u16, followed by all of the remaining cleartext data following this header(the actual content data).

The downloaded boss data is written in the following format to extdata.
First an extdata header in the following format
{| class="wikitable"
|-
! Offset
! Length
! Description
|-
| 0x0
| 0x1
| Size of header including this field. Always 0x18
|-
| 0x1
| 0xB
| Usually zero?
|-
| 0xC
| 0x4
| Unknown
|-
| 0x10
| 0x4
| Download date in format: Bit 0-6 = day, Bit 7-10 = month, Bit 11-21 = year
|-
| 0x14
| 0x4
| Usually zero? Padding?
|}
Followed by the Payload Content Header without the hash and signature (first 0x1C bytes) and the actual payload.

[[Category:Nintendo Software]]

BOSS Savegame

2024-03-30T19:54:02Z

Meleemeister: /* BOSS_PM_INFO.db */

SpotPass

2024-03-22T18:48:28Z

Meleemeister:

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

SpotPass Internet communications are mostly HTTPS transfers.

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

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

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

In some cases the BOSS module will add the following URL parameter to HTTPS requests, when connected to a [[Nintendo Zone]] AP: "ap=<NZoneApNum>" or when using a specific [[Cfg:GetSystemModel|system model]]: "tm=<SystemModelNumber>". The Old 3DS and Old 3DS XL don't set this value.

== policylist ==
Every time the system connects to the wifi AP, the BOSS ("Background online storage service" = SpotPass) module itself will download the cleartext xml policylist: "https://nppl.c.app.nintendowifi.net/p01/policylist/3/<countrycode>". This policylist contains a list of SpotPass tasks for certain titles. This policylist can control whether the specified tasks are processed at all.

As of the policylist updated 2017-11-08, this stops the <tt>OlvNotf</tt> (Miiverse notification sync) task for <tt>000400300000bc00</tt>, <tt>000400300000bd00</tt>, <tt>000400300000be00</tt> for all regions and <tt>basho0</tt> for the [[Home Menu]]. Japan also has the <tt>9ER_NTD</tt> task blocked for いつの間にテレビ (<tt>0004000000034700</tt>).

== User Agent ==

The default user-agent used for SpotPass HTTPS requests (including the policylist) has the following format:

<tt><user agent codename>-<user agent version>/<printed hex u64 [[CfgS:GetLocalFriendCodeSeed|LocalFriendCodeSeed]]>-<printed hex u64 [[FRDU:GetMyFriendKey|Friend]] [[FRDU:PrincipalIdToFriendCode|Code]]>/<text [[CVer|system]] [[NVer|version]]>/<unknown decimal value>/<[[Cfg:GetSystemModel|system model number]]></tt>

The codename can be set to either <tt>PBOS</tt> (Production BOSS?) or <tt>DBOS</tt> (Development BOSS?) depending if the console is a [[Configuration_Memory#UNITINFO|retail]] unit. As of system version 11.17, the user agent version is hardcoded to 8.0 and the decimal value is set to 62452 (0xF3F4).

No user-agent is used for plaintext HTTP requests with SpotPass.

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

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

== BOSS Sysmodule Savegame==
See [[BOSS Savegame]]

== Content Container ==

SpotPass content must use this container to encrypt the payload and sign it, for content downloads. The cleartext content is stored in [[extdata]]. The format of these headers is big-endian.

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

Data following the BOSS header is encrypted with AES-CTR. The AES key that is used is stored in [[AES_Registers#Keyslots|keyslot 0x38]]. The first 12 bytes of the IV are from offset 0x1C of the header, while the last 32-bit integer of the IV in big-endian is 0x1. The IV from the header is random per file, and an unique random IV is used each time the content is updated. The cleartext data begins with the content header.

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

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

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

=== Payload Content Header ===
{| class="wikitable"
|-
! Offset
! Length
! Description
|-
| 0x0
| 0x8
| ProgramID
|-
| 0x8
| 0x4
| Usually zero?
|-
| 0xC
| 0x4
| Content datatype, used for filtering with [[BOSSU:GetNsDataIdList]].
Usually 0x10001? (observed 0x20001 in eShop strings)
|-
| 0x10
| 0x4
| Size of the payload after this header
|-
| 0x14
| 0x4
| [[BOSS_Services|NsDataId]], used for generating the extdata filepath.
|-
| 0x18
| 0x4
| Probably some version field for the payload
|-
| 0x1C
| 0x20
| SHA-256 hash
|-
| 0x3C
| 0x100
| RSA-2048 signature over the previous SHA-256 hash
|}

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

The hash at offset 0x1C hashes the 0x1C-byte data at offset 0x0 followed by a zero u16, followed by all of the remaining cleartext data following this header(the actual content data).

The downloaded boss data is written in the following format to extdata.
First an extdata header in the following format
{| class="wikitable"
|-
! Offset
! Length
! Description
|-
| 0x0
| 0x1
| Size of header including this field. Always 0x18
|-
| 0x1
| 0xB
| Usually zero?
|-
| 0xC
| 0x4
| Unknown
|-
| 0x10
| 0x4
| Download date in format: Bit 0-6 = day, Bit 7-10 = month, Bit 11-21 = year
|-
| 0x14
| 0x4
| Usually zero? Padding?
|}
Followed by the Payload Content Header without the hash and signature (first 0x1C bytes) and the actual payload.

[[Category:Nintendo Software]]

System SaveData

2024-03-22T18:46:57Z

Meleemeister:

Savegames stored in NAND are located at [[Flash_Filesystem|nand:/data/<ID0>/sysdata/<SaveID-Low>/<SaveID-High>]], where SaveID-High is the filename. SaveID-High is normally 00000000.

Access to system savedata via [[Filesystem_services|fs:USER]] is determined by the [[NCCH#CXI|exheader_storageinfo]] accessinfo and systemsavedataid. Most ARM11 processes using fs:USER only have access to the SaveIDs specified by systemsavedataid, when a certain accessinfo bit is set the process can access all system-savedata however. The 8-byte systemsavedataid is two SaveID-Low words which the process has access to, normally only the first word is used. When the process doesn't have access to any system-savedata via systemsavedataid, systemsavedataid is all-zero.

=NAND Savegames=
The SaveID for system modules is usually 0x00010000 | [[Titles|uniqueID]]. The SaveID for other system processes (like applications) is 0x00020000 | [[Titles|uniqueID]].

==System Module Savegames==
{| class="wikitable" border="1"
|-
! SaveID
! Description
|-
| 0x00010011
| [[Filesystem_services|FS]] module savedata, used for [[Anti Savegame Restore]].
|-
| 0x00010015
| [[Application_Manager_Services|AM]] module savedata
|-
| 0x00010017
| [[Config Savegame]]
|-
| 0x00010022
| [[PTM]] [[PTM_Savegame|savegame]]
|-
| 0x00010026
| [[StreetPass|CECD]] savegame
|-
| 0x0001002C
| [[NIM_Services|NIM]] savegame
|-
| 0x00010032
| [[FRD_Savegame|Friends module savegame]]
|-
| 0x00010034
| [[SpotPass|BOSS]] module [[BOSS Savegame|savegame]]
|-
| 0x00010035
| News module savegame
|-
| 0x00010038
| Act module savegame
|-
| 0x00010040
| [[NFC_Services|NFC]] module savegame
|}

==System application and applet savegames==
{| class="wikitable" border="1"
|-
! JPN SaveID
! USA SaveID
! EUR SaveID
! Description
|-
| 0x000200C5
| Same as JPN
| Same as JPN
| "error" applet savegame
|-
| 0x00020082
| 0x0002008F
| 0x00020098
| [[Home Menu]] savegame
|-
| 0x00020086
| 0x00020092
| 0x0002009B
| Instruction Manual applet savegame
|-
| 0x00020087
| 0x00020093
| 0x0002009C
| Game Notes applet savegame
|-
| 0x00020088
| 0x00020094
| 0x0002009D
| Old3DS/New3DS [[Internet Browser]] savegame
|-
| 0x0002008D
| 0x00020096
| 0x0002009F
| Friend List applet savegame
|-
| 0x000200BB
| Same as JPN
| Same as JPN
| Additional savedata for the New3DS [[Internet Browser]]. This only contains "t.bin" with filesize 0xadf80. This contains all browser history: each entry has the URL, UTF-16 title string, and icon gfx. This includes old pages which are not currently open in the browser as tabs?
|-
| 0x000200BC
| 0x000200BD
| 0x000200BE
| olv applet savegame (Miiverse)
|-
| 0x000200C6
| Same as JPN
| Same as JPN
| mint applet savegame
|-
| 0x00020200
| 0x00020210
| 0x00020220
| [[System Settings]] savegame
|-
| 0x00020202
| 0x00020212
| 0x00020222
| [[Activity Log]] application savegame
|-
| 0x00020204
| 0x00020214
| 0x00020224
| [[Nintendo 3DS Camera]] application savegame
|-
| 0x00020205
| 0x00020215
| 0x00020225
| [[Nintendo 3DS Sound]] application savegame
|-
| 0x00020207
| 0x00020217
| 0x00020227
| [[Mii Maker]] application savegame
|-
| 0x00020208
| 0x00020218
| 0x00020228
| [[StreetPass Mii Plaza]] application savegame
|-
| 0x00020209
| 0x00020219
| 0x00020229
| [[eShop]] application savegame
|-
| 0x0002020A
| 0x0002021A
| 0x0002022A
| [[System Transfer]] savegame
|-
| 0x0002020B
| 0x0002021B
| 0x0002022B
| [[Nintendo Zone]] savegame
|-
| 0x0002020D
| 0x0002021D
| 0x0002022D
| [[Face Raiders]] savegame
|-
| 0x0002020E
| 0x0002021E
| 0x0002022E
| [[AR Games]] savegame
|-
| 0x000202BF
| 0x000202C0
| 0x000202C1
| act (NNID settings) application savegame
|-
| 0x00020231
| 0x00020241
| 0x00020251
| [[microSD Management]] application savegame
|}

BOSS Savegame

2024-03-22T18:46:13Z

Meleemeister: Created page with "This page describes the content of the BOSS sysmodule savegame. The savegame contains 7 files and no directories ==BOSS_A.db== ==BOSS_SS.db== SS could stand fo..."

Extdata

2024-03-22T17:55:07Z

Meleemeister: /* Tools */

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
|
|-
| ?
| 00001132
| 00001131
| Fantasy Life
|
|-
| 000011c5
| 000011c5
| 000011c5
| Pokémon Omega Ruby Pokémon Alpha Sapphire
|
|-
| ?
| 000012c8
| 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
|
|-
| ?
| 0000198e
| 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

Inner FAT

2024-03-22T17:54:21Z

Meleemeister: Added Tools section

This page describes a common FAT-like file system used in [[Savegames]], [[Extdata]] and [[Title Database]]. This file system format has several variants depending on which kind of data it stores. All the three kinds of data that use this file system structure also happen to use the [[DISA and DIFF]] container as well, but there is no direct relationship between the file system and the DISA/DIFF container. All data formats described here is in the inner data of the DISA/DIFF container (i.e. IVFC level 4). Please refer to the DISA/DIFF page for how to unwrap it first before trying to extract the file system.

== Overview ==

The file system consists of the following components:
* header
* directory hash table
* file hash table
* file allocation table
* directory entry table
* file entry table
* data region

The file allocation table (FAT) forms several linked lists inside, each of which represents a "file" allocated in the data region. Please refer to the File Allocation Table section below for more detail. In some variants, the directory entry table and the file entry table are also allocated as two special "files" in the data region, managed by the FAT, while in others they are stand-alone tables located outside the data region.

== Layout Variants ==
Four variants of the file system layout has been identified. A summary diagram:

[[File:Inner-fat.png]]

=== Savegame, <code>duplicate data = true</code> ===

Such savegame is a single DISA container that only has one partition which is always configured as external IVFC level 4 disabled (see [[DISA and DIFF|DISA]] format for details). All components are stored in this partition as

* filesystem header at the beginning
* directory hash table
* file hash table
* file allocation table
* data region
** directory entry table is allocated inside data region
** file entry table as well
** all file data is also allocated here

In this layout, all data is duplicated by DISA's DPFS tree, which is what the parameter <code>duplicate data</code> implies.

=== Savegame, <code>duplicate data = false</code> ===
Such savegame is a single DISA container that has two partitions. Partition A is always configured as external IVFC level 4 disabled, and partition B is configured as it enabled. Components are stored among the two partitions as

* Partition A
** filesystem header at the beginning.
** directory hash table
** file hash table
** (stand-alone) file allocation table
** (stand-alone) directory entry table
** file entry table
* Partition B
** used as data region entirely, and only has file data allocated.

In this layout, all file system metadata is duplicated by partition A DPFS tree, but file data is not as partition B has external IVFC level 4.

=== Extdata ===
An extdata consists of several DIFF containers (device files), among which the special device file <code>00000000/00000001</code> contains the inner FAT system, while other devices contains normal subfiles of the extdata. Please refer to [[Extdata]] for detail. The special file <code>00000000/00000001</code> contists of the following components

* filesystem header at the beginning
* directory hash table
* file hash table
* file allocation table (degenerate, because the data region only has two "files": the directory entry table and the file entry table)
* data region
** directory entry table allocated inside data region
** file entry table as well
** normal subfiles are NOT in the data region. They are in their DIFF containers instead.

The special file <code>00000000/00000001</code> is configured as external IVFC level 4 disabled, and all other device files are configured as it enabled.

=== Title database ===
All [[Title Database]] files are DIFF containers. Except for <code>certs.db</code>, all of them uses this filesystem in the DIFF inner data, which consists of

* database-specific pre-header at the beginning (See [[Title Database]])
* filesystem header
* directory Hash Table (degenerate and always has only one bucket, as there is only one directory for "root")
* file Hash Table
* file allocation table
* data region
** directory entry table allocated inside data region (degenerate, as there is only one directory for "root")
** file entry table as well
** title entries (title info or ticket) are allocated as normal files in the data region as well.

== Filesystem Header ==
Offsets listed in the table below are all relative to the beginning of the header, while all "starting block index" are relative to the beginning of data region. This is especially important for title database, as the offsets doesn't count the pre header.
{| class="wikitable" border="1"
! Offset
! Length
! Description
|-
| 0x00
| 4
| Magic ("SAVE" for savegame; "BDRI" for title database; "VSXE" for extdata)
|-
| 0x04
| 4
| Version (0x40000 for savegame; 0x30000 for title database and extdata)
|-
| 0x08
| 8
| Filesystem Information offset (Y, =0x20 for savegame and title database, =0x138 for extdata)
|-
| 0x10
| 8
| Filesystem image size in blocks (including pre header for title database)
|-
| 0x18
| 4
| Filesystem Image block size
|-
| 0x1C
| 4
| Padding
|-
| 0x20
| 0x118 in total
| Below is additional data for extdata. Not present in savegame or title database
|-
| 0x20
| 8
| Unknown
|-
| 0x28
| 4
| 'Action' made on most recently mounted Extdata image
|-
| 0x2C
| 4
| Unknown
|-
| 0x30
| 4
| ID of most recently mounted Extdata image
|-
| 0x34
| 4
| Unknown
|-
| 0x38
| 0x100
| Mount path, from most recently mounted Extdata image
|-
| Y
| 0x68 in total
| Below is Filesystem Information
|-
| Y + 0x00
| 4
| Unknown
|-
| Y + 0x04
| 4
| Data region block size
|-
| Y + 0x08
| 8
| Directory hash table offset
|-
| Y + 0x10
| 4
| Directory hash table bucket count (=1 for title database)
|-
| Y + 0x14
| 4
| Padding
|-
| Y + 0x18
| 8
| File hash table offset
|-
| Y + 0x20
| 4
| File hash table bucket count
|-
| Y + 0x24
| 4
| Padding
|-
| Y + 0x28
| 8
| File allocation table offset
|-
| Y + 0x30
| 4
| File allocation table entry count
(excluding the leading 0th entry. See below)
|-
| Y + 0x34
| 4
| Padding
|-
| Y + 0x38
| 8
| Data region offset
(0 for savegame <code>duplicate data = false</code> layout, as the data region is in partition B for that layout)
|-
| Y + 0x40
| 4
| Data region block count
(= File allocation table entry count)
|-
| Y + 0x44
| 4
| Padding
|-
| Y + 0x48
| 8
| for savegame <code>duplicate data = false</code> layout: directory entry table offset;
otherwise: u32 directory entry table starting block index + u32 directory entry table block count
|-
| Y + 0x50
| 4
| Maximum directory count, excluding the mandatory "root" directory
(=1 for title database, but that 1 free directory slot is never used)
|-
| Y + 0x54
| 4
| Padding
|-
| Y + 0x58
| 8
| for savegame <code>duplicate data = false</code> layout: file entry table offset;
otherwise: u32 file entry table starting block index + u32 file entry table block count
|-
| Y + 0x60
| 4
| Maximum file count
|-
| Y + 0x64
| 4
| Padding
|}

* For savegames, the file/directory bucket count & maximum count are specified by the parameters of [[FS:FormatSaveData]] or [[FS:CreateSystemSaveData]].
* For extdata, the maximum file/directory count are specified by the parameters of [[FS:CreateExtSaveData]]. The bucket count is likely calculated by the system.
* Directory & file entry tables are allocated in the data region as if they are two normal files (except for savegame <code>duplicate data = false</code> layout). However, only continuous allocation has been observed, so directly reading block_count * block_size bytes from data_region + starting_block_index * block_size should be safe.
* For title database (except for ticket), the range specified for data region seems overflow the file end by 0x80 bytes, which is exactly the size of the pre header. This makes it as if the data region offset should be relative to the pre header instead of the BDRI header. However, further investigation on the directory/file table allocated inside the data region shows that the data region offset is indeed relative to the BDRI header. It might be a bug in 3DS that the title database files miss 0x80-byte space at the end.

== Directory Entry Table ==

The directory entry table is an array of the entry type shown below. It describes the directory hierarchy of the file system. There are two variants of the directory entry type, and a dummy entry type.

=== Savegame/Extdata Variant===
{| class="wikitable" border="1"
! Offset
! Length
! Description
|-
| 0x00
| 4
| Parent directory index. 0 for root
|-
| 0x04
| 16
| ASCII directory name in. All zero for root
|-
| 0x14
| 4
| Next sibling directory index. 0 if this is the last one
|-
| 0x18
| 4
| First subdirectory index. 0 if not exists
|-
| 0x1C
| 4
| First file index in file entry table. 0 for empty directory
|-
| 0x20
| 4
| Padding / zero?
|-
| 0x24
| 4
| Index of the next directory in the same hash table bucket. 0 if this is the last one
|}

=== Title Database Variant===
Because title database only has one directory for "root", its directory entry table degenerates into many zeros whose structure is not recognizable. The size of one entry here is guessed.
{| class="wikitable" border="1"
! Offset
! Length
! Description
|-
| 0x00
| 4
| Parent directory index = 0 for root
|-
| 0x04
| 4
| Next sibling directory index = 0 because this is the last one
|-
| 0x08
| 4
| First subdirectory index = 0 because there is no subdirectory
|-
| 0x0C
| 4
| First file index in file entry table. 0 for empty directory
|-
| 0x10
| 12
| Padding / zero?
|-
| 0x1C
| 4
| Index of the next directory in the same hash table bucket = 0 because there is no other directory
|}

=== Dummy Entry===
There are also some dummy entries in the array
{| class="wikitable" border="1"
! Offset
! Length
! Description
|-
| 0x00
| 4
| Current Total entry count
|-
| 0x04
| 4
| Maximum entry count = maximum directory count + 2
|-
| 0x08
| 28/20
| Padding / All zero
|-
| 0x24/0x1C
| 4
| Index of the next dummy entry. 0 if this is the last one
|}

The 0-th entry of the array is always a dummy entry, which functions as the head of the dummy entry linked list. The 1-st entry of the array is always the root. Therefore maximum entry count is two more than maximum directory count. Dummy entries are left there when deleting directories, and reserved for future use.

== File Entry Table ==

The file entry table is an array of the entry type shown below. It contains information for each file. There are three variants of the file entry type, and a dummy entry type.

=== Savegame Variant ===
{| class="wikitable" border="1"
! Offset
! Length
! Description
|-
| 0x00
| 4
| Parent directory index in directory entry table
|-
| 0x04
| 16
| ASCII file name
|-
| 0x14
| 4
| Next sibling file index. 0 if this is the last one
|-
| 0x18
| 4
| Padding
|-
| 0x1C
| 4
| First block index in data region. 0x80000000 if the file is just created and has no data.
|-
| 0x20
| 8
| File Size
|-
| 0x28
| 4
| Padding?
|-
| 0x2C
| 4
| Index of the next file in the same hash table bucket. 0 if this is the last one
|}

=== Extdata Variant ===
{| class="wikitable" border="1"
! Offset
! Length
! Description
|-
| 0x00
| 4
| Parent directory index in directory entry table
|-
| 0x04
| 16
| ASCII file name
|-
| 0x14
| 4
| Next sibling file index. 0 if this is the last one
|-
| 0x18
| 4
| Padding
|-
| 0x1C
| 4
| Always 0x80000000
|-
| 0x20
| 8
| Unique identifier. See [[Extdata]]
|-
| 0x28
| 4
| Padding?
|-
| 0x2C
| 4
| Index of the next file in the same hash table bucket. 0 if this is the last one
|}

=== Title database Variant ===

{| class="wikitable" border="1"
! Offset
! Length
! Description
|-
| 0x00
| 4
| Parent directory index in directory entry table
|-
| 0x04
| 8
| Title ID
|-
| 0x0C
| 4
| Next sibling file index. 0 if this is the last one
|-
| 0x10
| 4
| Padding
|-
| 0x14
| 4
| First block index in data region.
|-
| 0x18
| 8
| File size
|-
| 0x20
| 8
| Padding?
|-
| 0x28
| 4
| Index of the next file in the same hash table bucket. 0 if this is the last one
|}

=== Dummy Entry ===
Like directory entry table, file entry table also has some dummy entries:

{| class="wikitable" border="1"
! Offset
! Length
! Description
|-
| 0x00
| 4
| Current total entry count
|-
| 0x04
| 4
| Maximum entry count = maximum file count + 1
|-
| 0x08
| 36/32
| Padding / All zero
|-
| 0x2C/0x28
| 4
| Index of the next dummy entry. 0 if this is the last one
|}

The 0-th entry of the array is always a dummy entry, which functions as the head of the dummy entry linked list. Therefore maximum entry count is one more than maximum file count. Dummy entries are left there when deleting files, and reserved for future use.

== Directory Hash Table & File Hash Table ==

This is a u32 array of size = bucket count, each of which is an index to the directory / file entry table. The directory / file name is hashed and its entry index is put to the corresponding bucket. If there is already a directory/file entry in the bucket, then it appends to the linked list formed by <code>Index of the next directory/file in the same hash table bucket</code> field in the directory/file entry table. i.e. this is a hash table using separate chaining with linked lists

The hash function takes the parent index and the ASCII name (or title ID for title database) as key. The function is equivalent to

<pre>uint32_t GetBucket(
uint8_t name[16 or 8], // For savegame/extdata, this takes all 16 bytes including trailing zeros; For title database, this is the 8-byte title ID
uint32_t parent_dir_index,
uint32_t bucket_count
) {
uint32_t hash = parent_dir_index ^ 0x091A2B3C;
for (int i = 0; i < 4 or 2; ++i) {
hash = (hash >> 1) | (hash << 31);
hash ^= (uint32_t)name[i * 4]
hash ^= (uint32_t)name[i * 4 + 1] << 8
hash ^= (uint32_t)name[i * 4 + 2] << 16
hash ^= (uint32_t)name[i * 4 + 3] << 24
}
return hash % bucket_count;
}
</pre>

== File Allocation Table ==

The file allocation table is an array of a 8-byte entry shown below. The array size is actually ''one larger than'' the size recorded in the filesystem header. Each entry corresponds to a block in the data region (the block size is defined in filesystem header). However, the 0th entry corresponds to nothing, so the corresponding block index is off by one. e.g. entry 31 in this table corresponds to block 30 in the data region.

{| class="wikitable" border="1"
! Offset
! Length
! Description
|-
| 0x00
| 4
| bit[0:30]: Index U; bit[31]: Flag U
|-
| 0x04
| 4
| bit[0:30]: Index V; bit[31]: Flag V
|}

Entries in this table forms several chains, representing how blocks in the data region should be linked together. However, unlike normal FAT systems, which uses chains of entries, 3DS savegames use chain of ''nodes''. Each node spans one or multiple entries.

One node spanning <code>n</code> entries starting from <code>FAT[k]</code> is in the following format:

<pre>FAT[k + 0]:
Index_U = index of the first entry of the previous node. 0 if this is the first node.
Index_V = index of the first entry of the next node. 0 if this is the last node.
Flag_U set if this is the first node.
Flag_V set if this node has multiple entries.

FAT[k + 1]:
Index_U = k (the first entry index of this node)
Index_V = k + n - 1 (the last entry index of this node)
Flag_U always set
Flag_V always clear

FAT[k + 2] ~ FAT[k + n - 2]:
All these entries are uninitialized

FAT[k + n - 1]:
Index_U = k
Index_V = k + n - 1
Flag_U always set
Flag_V always clear
(Same values as FAT[k + 1])
</pre>
* Note: all indices above are entry indices (block index + 1)

All free blocks that are not allocated to any files also form a node chain in the allocation table. The head index of this "free chain" is recorded in <code>FAT[0].Index_V</code>. Other fields of <code>FAT[0]</code> are all zero

Here is an example:

[[File:Disa-fat.png]]

For extdata, because only two "files" (directory and file entry tables) are allocated in the data region, and their size never changes once the extdata is created, they are guaranteed continuous in the data region, and the FAT degenerates to two big nodes. Therefore, instead of going through FAT, the offset and size of directory / file entry table can be found directly by offset = entry_table_starting block * data_region_block_size + data_region_offset and size = entry_table_block_count * data_region_block_size.

==Tools==
https://github.com/wwylele/3ds-save-tool

Online Play

2024-01-05T10:53:17Z

Meleemeister:

'''Online Play''' is a functionality of the Nintendo 3DS to play games online with other people.

==Connection==
First a connection to ''nasc.nintendowifi.net'' is established and the resource ''/ac'' is requested with the POST method to get the actual address of the game server and a ticket for authentication on the game server. 
A typical request to ''nasc.nintendowifi.net/ac'' has this format:

Header:
<pre>
POST https://nasc.nintendowifi.net/ac HTTP/1.1
Host: nasc.nintendowifi.net
X-GameId: 00003200
User-Agent: CTR FPD/000F
Content-Type: application/x-www-form-urlencoded
Content-Type: application/x-www-form-urlencoded
Content-Length: 841
</pre>
Body:
<pre>
gameid=MDAwMDMyMDA%2A&sdkver=MDAwMDAw&titleid=MDAwNDAxMzAwMDAwMzIwMg%2A%2A&gamecd=LS0tLQ%2A%2A&gamever=MDAxNA%2A%2A&mediatype=MA%2A%2A&makercd=MDA%2A&unitcd=Mg%2A%2A&macadr=MTEyMjMzNDQ1NTY2&bssid=MTEyMjMzYWFiYmNj&apinfo=MDQ6MDAwMDAwMDAwMA%2A%2A&fcdcert=<base64 encoded fcdcert>&devname=<base64 encoded name of the console (utf-16)>&servertype=TDE%2A&fpdver=MDAwRg%2A%2A&devtime=MjEwMTAxMjAyNjAx&lang=MDE%2A&region=MDI%2A&csnum=<base64 encoded serial number of the 3DS system wihtout check number>&uidhmac=<base64 encoded of ?>&userid=<base64 encoded Nex [[Principal ID]]>&action=TE9HSU4%2A&ingamesn=
</pre>
{| class="wikitable"
!Key!!Value!!Value decoded!!Notes
|-
|gameid||MDAwMDMyMDA*||00003200||
|-
|sdkver||MDAwMDAw||000000||
|-
|titleid||MDAwNDAxMzAwMDAwMzIwMg**||0004013000003202||
|-
|gamecd||LS0tLQ**||----||
|-
|gamever||MDAxNA**||0014||
|-
|mediatype||MA**||0||
|-
|makercd||MDA*||00||
|-
|unitcd||Mg**||2||
|-
|macadr||MTEyMjMzNDQ1NTY2||112233445566||MAC address of the console. Only the digits
|-
|bssid||MTEyMjMzYWFiYmNj||112233aabbcc||
|-
|apinfo||MDQ6MDAwMDAwMDAwMA**||04:0000000000||
|-
|fcdcert|| || ||
|-
|devname|| || || Name of the console in UTF-16
|-
|servertype||TDE*||L1||
|-
|fpdver||MDAwRg**||000F||
|-
|devtime||MjEwMTAxMDkyMDMx||210101092031||
|-
|lang||MDE*||01||
|-
|region||MDE*||01||
|-
|csnum||Q0VGMTIzNDU2Nzg*||CEF12345678||[[Serials|Serial number]] of the device without the check digit
|-
|uidhmac||MGFmODZmYmQ*||0af86fbd||
|-
|userid||MTIzNDU2Nzg5MA**||1234567890||Nex [[Principal ID]]
|-
|action||TE9HSU4*||LOGIN||
|-
|ingamesn|| ''empty'' || ''empty'' ||
|}

Typical response to the above request:

Header:
<pre>
HTTP/1.1 200 OK
NODE: pd42wfiap02
Content-Type: text/plain;charset=ISO-8859-1
Content-Length: 252
Date: Fri, 01 Jan 2021 09:20:55 GMT
Server: Nintendo Wii (http)
</pre>
Body:
<pre>
locator=MzQuMjExLjIzNS4xMzU6NjAwMDA*&retry=MA**&returncd=MDAx&token=<Token for authentication on the game server>&datetime=MjAyMTAxMDEwOTIwNTU*
</pre>
{| class="wikitable"
!Key!!Value!!Value decoded!!Notes
|-
|locator||MzQuMjExLjIzNS4xMzU6NjAwMDA*||34.211.235.135:60000||IP address and port of the game server
|-
|retry||MA**||0||
|-
|returncd||MDAx||001||001 for success. 119 if there is an update required
|-
|token|| || || Token for authentication on the game server. This token cannot be verified by the Nintendo 3DS
|-
|datetime||MjAyMTAxMDEwOTIwNTU*||20210101092055||
|}
If there is an error (returncd is not 001) no locator and token is send

==Game Server Informations==
{| class="wikitable"
! Game !! build name
|-
|Kid Icarus Uprising||branch:akd_server build:2_25_10595_1
|-
|Mario Kart 7||branch:origin/project/appsp build:3_4_17_3
|-
|Pokemon X/Y OR/AS||branch:origin/project/appsg build:3_3_15_6_0
|-
|Metroid Prime Federation Force||branch:origin/release/ngs/3.9.x.200x build:3_9_21_2005_0
|-
|Luigi's Mansion 2||branch:origin/release/ngs/3.4.x.3 build:3_4_16_3_0
|-
|The Legend of Zelda: Tri Force Heroes||branch:origin/release/ngs/3.9.x.200x build:3_9_21_2005_0
|-
|Pokemon Bank||branch:origin/project/ctr-jtta build:3_4_13_16_0
|-
|Nintendo Badge Arcade||branch:origin/project/ctr-jwv build:3_7_16_2006_0
|-
|Pokemon Sun/Moon US/UM||branch:origin/project/ctr-a2a build:3_10_23_3112_0
|}

2021-07-29T20:21:39Z

Meleemeister:

The Old3DS+New3DS 11.15.0-47 system update was released on July 27, 2021 (UTC). 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, and KOR.

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

==Change-log==
[https://en-americas-support.nintendo.com/app/answers/detail/a_id/231/~/system-menu-update-history 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>

==See Also==
System update report(s):
* [https://yls8.mtheall.com/ninupdates/reports.php?date=2021-07-27_00-00-33&sys=ctr Old 3DS]
* [https://yls8.mtheall.com/ninupdates/reports.php?date=2021-07-27_00-00-37&sys=ktr New 3DS]

[[Category:Firmware Versions]]

PSLB

2021-03-17T18:34:39Z

Meleemeister:

This page documents the format of PSLB.

== Overview ==
PSLB are data-interchange files like JSON or XML.

== Header ==
{| class="wikitable" border="1"
! Offset !! Size !! Type !! Description
|-
| 0x000 || 4 || char[4] || Magic Number 'PSLB'
|-
| 0x004 || 4 || uint32 || Unkown
|-
| 0x008 || 4 || uint32 || Unkown
|-
| 0x00C || 4 || uint32 || Unkown
|}

== Data ==
The data is constructed of 1 byte that represents what type of data follows
{| class="wikitable" border="1"
! Value !! Type
|-
| 1 || String
|-
| 2 || int32
|-
| 3 || float (4 byte)
|-
| 4 || Byte
|-
| 5 || Map
|-
| 6 || List
|}

The string type is a combination of an uint32 for the length of the string followed by the characters of the string.

For the Map and List after the type a uint32 follows that represents the number of entries in the Map/List.

The keys of the Map are always strings but the values can have any type of the table

[[Category:File formats]]