3dbrew - User contributions [en]

StreetPass

2025-03-17T11:39:13Z

Sorunome: /* StreetPass Services */ fix typo

'''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 following 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.

=== Send Mode ===
The 3DS can mark StreetPass data with one of 4 Send Modes
{| class="wikitable" border="1"
!ID!!Send Mode!!Description
|-
|0||EXCHANGE||StreetPass message exchange will only happen if both consoles can store the message of the other. E.g. the inbox isn't full. Example title: StreetPass Mii Plaza
|-
|1||RECV_ONLY||3DS doesn't have anything in its outbox so it is only receiving messages.
|-
|2||SEND_ONLY||
|-
|3||SEND_RECV||
|}

== 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 [[SpotPass#policylist]]. When connecting to a Nintendo Zone Hotspot the console will send an additional GET parameter named ''ap''. Adding the following priority to the policylist will instruct the console to upload its data (The level tag can probably be lower and must not be HIGH).
<pre>
<Priority>
<TitleId>0004013000003400</TitleId>
<TaskId>sprelay</TaskId>
<Level>HIGH</Level>
<Persistent>false</Persistent>
<Revive>false</Revive>
</Priority>
</pre>

===Request===
The following additional headers will be send in the request:
{| class=wikitable
|X-Boss-Apinfo||Access Point Info. The same number that is send with the policylist GET parameter ap. Probably identifies the SSID of connected Nintendo Zone Hotspot. If not connected to Nintendo Zone Hotspot this will be an empty string.||02012600000
|-
|X-Boss-Bssid||The MAC address of the access point the 3DS is connected to.||11:22:33:44:55:66
|-
|X-Boss-Country||2 letter country code of the set language.||ES
|-
|X-Boss-Region||3 letter region code of the 3DS' region.||EUR
|-
|X-Boss-Userid||A unique 16 character long hexadecimal string that represents a 64-bit integer. It is unknown how this number is generated.||6966442DE2EED063
|}

In the request body there will be a file named ''spr-meta'' and a file per registered StreetPass game ''spr-slotXX'' where XX is an incrementing number. If the game contains not messages in its outbox so the size of the file would be 0 then no file is created and sent but it will still be listed in the spr-meta file.

===spr-meta file===
The spr-meta file is a text file which may contain the following content.
<pre>
slotsize: 5
spr-slot01: 3,000EC400,10664
spr-slot02: 2,0007AD00,3648
spr-slot03: 3,00030000,3804
spr-slot04: 1,00051600,0
spr-slot05: 0,00020800,28228
</pre>
The comma seperated list after each spr-slotXX has the following meaning
{| class=wikitable
|Send Mode||StreetPass ID (Low title ID of the game. May be from a different region like japan.)||Size of the file in bytes
|}

===spr-slotXX files===
These are binary files. They begin a with a header with the follwing structure.
{| class=wikitable
!Offset!!Size!!Description
|-
|0x00||0x04||Magic number 0x00006161
|-
|0x04||0x04||Size of the file in bytes including this header
|-
|0x08||0x04||StreetPass ID (Low title ID of the game. May be from a different region like japan.)
|-
|0x0C||0x04||Unknown
|-
|0x10||0x04||Number of messages after this header
|}
After the header follows the StreetPass message exactly as it is stored in the outbox of [[CECD_Savegame#File_.3C12-char_ID.3E|CEC Save]].

===Response===
The following headers are expected:
{| class=wikitable
!Key!!colspan=3|Value!!Example
|-
|X-Spr-SlotXX-Result||StreetPass ID||Send Mode||Size of the file in bytes||X-Spr-Slot01-Result: 000EC400,3,17760
|}
It expects a header for every game it sent in the request.

The body is expected to contain binary data with the same structure as the spr-slotXX files in the request. The order of these must be the same as the reponse header order.

== Structs, Data Types ==
Streetpass uses multiple different structs and data types for storing and transporting data.

=== MessageId ===
This datatype holds a per-console-per-title unique message id.
{| class="wikitable" border="1"
! Type
! Description
|-
| u8[8]
| The message id
|}

=== Timestamp12 ===
This holds a timestamp in 12 bytes
{| class="wikitable" border="1"
! Offset
! Size
! Type
! Name
|-
| 0x0
| 0x4
| u32
| Year
|-
| 0x4
| 0x1
| u8
| Month
|-
| 0x5
| 0x1
| u8
| Day
|-
| 0x6
| 0x1
| u8
| Weekday
|-
| 0x7
| 0x1
| u8
| Hour
|-
| 0x8
| 0x1
| u8
| Minute
|-
| 0x9
| 0x1
| u8
| Second
|-
| 0xA
| 0x2
| u16
| Millisecond
|}

=== Message (0x6060) ===
MessageHeader:
{| class="wikitable" border="1"
! Offset
! Size
! Type
! Name
! Description
|-
| 0x00
| 0x2
| u16
| magic
| Equals 0x6060 (<code>``</code>)
|-
| 0x02
| 0x2
| u16
| Padding
|
|-
| 0x04
| 0x04
| u32
| message_size
| The size in bytes of the entire message, including all headers and hmac
|-
| 0x08
| 0x04
| u32
| total_header_size
| The size in bytes of all headers, including the extra headers
|-
| 0x0C
| 0x04
| u32
| body_size
| The size in bytes of the body of the message
|-
| 0x10
| 0x04
| u32
| title_id
| The title id of the message
|-
| 0x14
| 0x04
| u32
| title_id2
| ???
|-
| 0x18
| 0x04
| u32
| batch_id
| The sending client sets an ID here if multiple messages should be batched together into one transaction
|-
| 0x1C
| 0x04
| u32
| transfer_id
| All messages from the same transfer (That is, sending the messages) contain the same transfer id
|-
| 0x20
| 0x08
| MessageId
| message_id
| The ID of the sending message
|-
| 0x28
| 0x04
| u32
| message_version
| ???
|-
| 0x2C
| 0x08
| MessageId
| message_id_2
| The message ID that this message is referring to, e.g. the individual responses in Streetpass Mii Plaza
|-
| 0x34
| 0x01
| u8
| recipients
| bitfield: 0x01: everyone; 0x02: friends
|-
| 0x35
| 0x01
| SendMethod
| send_method
|
|-
| 0x36
| 0x01
| bool
| unopened
| Set if the message hasn't been opened yet
|-
| 0x37
| 0x01
| bool
| is_new
| Set if the message is new
|-
| 0x38
| 0x08
| u64
| sender_id
|
|-
| 0x40
| 0x08
| u64
| sender_id_2
|
|-
| 0x48
| 0x0C
| Timestamp12
| sent
|
|-
| 0x54
| 0x0C
| Timestamp12
| received
|
|-
| 0x60
| 0x0C
| Timestamp12
| created
|
|-
| 0x6C
| 0x01
| u8
| send_count
| How often this message can be sent
|-
| 0x6D
| 0x01
| u8
| forward_count
| How often this message can be forwarded
|-
| 0x6E
| 0x02
| u16
| user_data
| ???
|}

ExtMessageHeader:
{| class="wikitable" border="1"
! Offset
! Size
! Type
! Name
! Description
|-
| 0x00
| 0x04
| u32
| type
| The type of the extra header
|-
| 0x04
| 0x04
| u32
| size
| Size, in bytes, of the extra header
|-
| 0x08
|
|
| body
| The body of the extra header
|}

Message:
{| class="wikitable" border="1"
! Offset
! Size
! Type
! Name
! Description
|-
| 0x00
| 0x70
| MessageHeader
| header
| The header of the message
|-
| 0x70
|
| ExtMessageHeader[]
| ext_headers
| An array of the extra headers for the message. The array keeps filling until the length no more until <code>header.total_header_size</code>
|-
|
|
|
| body
| The actual body/payload of the message
|-
|
| 0x20
| u8[0x20]
| hmac
| The hmac over the body with the hmac_key
|}

=== Slot (0x6161) ===
The slot groups multiple messages of one title id together into a single struct
{| class="wikitable" border="1"
! Offset
! Size
! Type
! Name
! Description
|-
| 0x00
| 0x02
| u16
| magic
| Equals 0x6161 (<code>aa</code>)
|-
| 0x02
| 0x02
| u16
| padding
|
|-
| 0x04
| 0x04
| u32
| size
| The size of bytes of the entire slot, including the header and all messages it contains
|-
| 0x08
| 0x04
| u32
| title_id
| The title id of the slot
|-
| 0x0C
| 0x04
| u32
| batch_id
| If the slot contains batched messages, the batch id is set to the same one as those messages
|-
| 0x10
| 0x04
| u32
| message_count
| The total number of messages in this slot
|-
| 0x14
|
| Message[]
| messages
| An array of length <code>message_count</code> all the messages of this slot
|}

=== BoxInfo (0x6262) ===
{| class="wikitable" border="1"
! Offset
! Size
! Type
! Name
! Description
|-
| 0x00
| 0x02
| u16
| magic
| Equals 0x6262 (<code>bb</code>)
|-
| 0x02
| 0x02
| u16
| padding
|
|-
| 0x04
| 0x04
| u32
| file_size
| The size of the box info in bytes
|-
| 0x08
| 0x04
| u32
| max_box_size
| The maximum allowed size of the box in bytes
|-
| 0x0C
| 0x04
| u32
| box_size
| The current size of the box in bytes
|-
| 0x10
| 0x04
| u32
| max_num_messages
| The maximum number of messages that the box can hold
|-
| 0x14
| 0x04
| u32
| num_messages
| The current number of messages in the box
|-
| 0x18
| 0x04
| u32
| max_batch_size
| The maximum size of a bach, in number of messages
|-
| 0x1C
| 0x04
| u32
| max_message_size
| The maximum size of a message, in bytes
|-
| 0x20
|
| MessageHeader[]
| message_headers
| An array of all message headers in this box of length <code>num_messages</code>
|}

=== MBoxInfo (0x6363) ===
This holds information on the message box, including both inbox and outbox
{| class="wikitable" border="1"
! Offset
! Size
! Type
! Name
! Description
|-
| 0x00
| 0x02
| u16
| magic
| Equals 0x6363 (<code>cc</code>)
|-
| 0x02
| 0x02
| u16
| padding
|
|-
| 0x04
| 0x04
| u32
| title_id
| The title id for this mbox
|-
| 0x08
| 0x04
| u32
| private_id
| ???
|-
| 0x0C
| 0x01
| u8
| mbox_type_flags
| 0x01: normal programs, 0x06: system programs, 0x80: silent notif
|-
| 0x0D
| 0x01
| bool
| enabled
| Weather this message box is enabled
|-
| 0x0E
| 0x02
| u16
| padding
|
|-
| 0x10
| 0x20
| u8[0x20]
| hmac_key
| The hmac key to make hmacs for messages. These are unique per title, however they are the same for all consoles.
|-
| 0x30
| 0x04
| u32
| padding
|
|-
| 0x34
| 0x0C
| Timestamp12
| last_accessed
|
|-
| 0x40
| 0x01
| bool
| flag_unread
| Does this message box contain unread messages?
|-
| 0x41
| 0x01
| bool
| flag_new
| Does this message box contain new messages?
|-
| 0x42
| 0x01
| bool
| flag_unknown
| ???
|-
| 0x43
| 0x01
| bool
| flag_unknown
| ???
|-
| 0x44
| 0x0C
| Timestamp12
| last_received
|
|-
| 0x50
| 0x04
| u32
| padding
|
|-
| 0x54
| 0x0C
| Timestamp12
| unknown_timestamp
| ???
|}

=== 0x6565 ===
SlotMetadata:
{| class="wikitable" border="1"
! Offset
! Size
! Type
! Name
! Description
|-
| 0x00
| 0x04
| u32
| title_id
| The title id of the slot
|-
| 0x04
| 0x04
| SendMethod
| send_method
| The send method for the slot
|-
| 0x08
| 0x04
| u32
| body_size
| The size of the slot body in bytes
|-
| 0x0C
| 0x04
| u32
| count
| Number of messages
|-
| 0x10
| 0x14
| '''unknown'''
| '''unknown'''
|
|}

Struct:
{| class="wikitable" border="1"
! Offset
! Length
! Type
! Name
! Description
|-
| 0x00
| 0x02
| u16
| magic
| Equals 0x6565 (<code>ee</code>)
|-
| 0x02
| 0x02
| u16
| padding
|
|-
| 0x04
| 0x28
| '''unknown'''
| '''unknown'''
|
|-
| 0x2C
| 0x360
| SlotMetadata[0x18]
| slots
| Metadata of all slots
|}

=== OBIndex (0x6767) ===
{| class="wikitable" border="1"
! Offset
! Size
! Type
! Name
! Description
|-
| 0x00
| 0x02
| u16
| magic
| Equals 0x6767 (<code>gg</code>)
|-
| 0x02
| 0x02
| u16
| padding
|
|-
| 0x04
| 0x04
| u32
| num_messages
| The number of messages in the outbox
|-
| 0x08
|
| MessageId[]
| message_ids
| An array of the message IDs in the outbox, of length <code>num_messages</code>
|}

=== MBoxList (0x6868) ===
{| class="wikitable" border="1"
! Offset
! Size
! Type
! Name
! Description
|-
| 0x00
| 0x02
| u16
| magic
| Equals 0x6868 (<code>hh</code>)
|-
| 0x02
| 0x02
| u16
| padding
|
|-
| 0x04
| 0x04
| u32
| version
|
|-
| 0x08
| 0x04
| u32
| num_boxes
| The number of boxes (= games with streetpass enabled)
|-
| 0x0C
| 0x180
| char[0x18][0x10]
| box_names
| A 0x18-long array of all the box names (= hex encoded title ids) of games with streetpass enabled
|}

[[Category:Nintendo Software]]

StreetPass

2025-03-17T11:16:26Z

Sorunome: /* Message (0x6060) */

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

=== Send Mode ===
The 3DS can mark StreetPass data with one of 4 Send Modes
{| class="wikitable" border="1"
!ID!!Send Mode!!Description
|-
|0||EXCHANGE||StreetPass message exchange will only happen if both consoles can store the message of the other. E.g. the inbox isn't full. Example title: StreetPass Mii Plaza
|-
|1||RECV_ONLY||3DS doesn't have anything in its outbox so it is only receiving messages.
|-
|2||SEND_ONLY||
|-
|3||SEND_RECV||
|}

== 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 [[SpotPass#policylist]]. When connecting to a Nintendo Zone Hotspot the console will send an additional GET parameter named ''ap''. Adding the following priority to the policylist will instruct the console to upload its data (The level tag can probably be lower and must not be HIGH).
<pre>
<Priority>
<TitleId>0004013000003400</TitleId>
<TaskId>sprelay</TaskId>
<Level>HIGH</Level>
<Persistent>false</Persistent>
<Revive>false</Revive>
</Priority>
</pre>

===Request===
The following additional headers will be send in the request:
{| class=wikitable
|X-Boss-Apinfo||Access Point Info. The same number that is send with the policylist GET parameter ap. Probably identifies the SSID of connected Nintendo Zone Hotspot. If not connected to Nintendo Zone Hotspot this will be an empty string.||02012600000
|-
|X-Boss-Bssid||The MAC address of the access point the 3DS is connected to.||11:22:33:44:55:66
|-
|X-Boss-Country||2 letter country code of the set language.||ES
|-
|X-Boss-Region||3 letter region code of the 3DS' region.||EUR
|-
|X-Boss-Userid||A unique 16 character long hexadecimal string that represents a 64-bit integer. It is unknown how this number is generated.||6966442DE2EED063
|}

In the request body there will be a file named ''spr-meta'' and a file per registered StreetPass game ''spr-slotXX'' where XX is an incrementing number. If the game contains not messages in its outbox so the size of the file would be 0 then no file is created and sent but it will still be listed in the spr-meta file.

===spr-meta file===
The spr-meta file is a text file which may contain the following content.
<pre>
slotsize: 5
spr-slot01: 3,000EC400,10664
spr-slot02: 2,0007AD00,3648
spr-slot03: 3,00030000,3804
spr-slot04: 1,00051600,0
spr-slot05: 0,00020800,28228
</pre>
The comma seperated list after each spr-slotXX has the following meaning
{| class=wikitable
|Send Mode||StreetPass ID (Low title ID of the game. May be from a different region like japan.)||Size of the file in bytes
|}

===spr-slotXX files===
These are binary files. They begin a with a header with the follwing structure.
{| class=wikitable
!Offset!!Size!!Description
|-
|0x00||0x04||Magic number 0x00006161
|-
|0x04||0x04||Size of the file in bytes including this header
|-
|0x08||0x04||StreetPass ID (Low title ID of the game. May be from a different region like japan.)
|-
|0x0C||0x04||Unknown
|-
|0x10||0x04||Number of messages after this header
|}
After the header follows the StreetPass message exactly as it is stored in the outbox of [[CECD_Savegame#File_.3C12-char_ID.3E|CEC Save]].

===Response===
The following headers are expected:
{| class=wikitable
!Key!!colspan=3|Value!!Example
|-
|X-Spr-SlotXX-Result||StreetPass ID||Send Mode||Size of the file in bytes||X-Spr-Slot01-Result: 000EC400,3,17760
|}
It expects a header for every game it sent in the request.

The body is expected to contain binary data with the same structure as the spr-slotXX files in the request. The order of these must be the same as the reponse header order.

== Structs, Data Types ==
Streetpass uses multiple different structs and data types for storing and transporting data.

=== MessageId ===
This datatype holds a per-console-per-title unique message id.
{| class="wikitable" border="1"
! Type
! Description
|-
| u8[8]
| The message id
|}

=== Timestamp12 ===
This holds a timestamp in 12 bytes
{| class="wikitable" border="1"
! Offset
! Size
! Type
! Name
|-
| 0x0
| 0x4
| u32
| Year
|-
| 0x4
| 0x1
| u8
| Month
|-
| 0x5
| 0x1
| u8
| Day
|-
| 0x6
| 0x1
| u8
| Weekday
|-
| 0x7
| 0x1
| u8
| Hour
|-
| 0x8
| 0x1
| u8
| Minute
|-
| 0x9
| 0x1
| u8
| Second
|-
| 0xA
| 0x2
| u16
| Millisecond
|}

=== Message (0x6060) ===
MessageHeader:
{| class="wikitable" border="1"
! Offset
! Size
! Type
! Name
! Description
|-
| 0x00
| 0x2
| u16
| magic
| Equals 0x6060 (<code>``</code>)
|-
| 0x02
| 0x2
| u16
| Padding
|
|-
| 0x04
| 0x04
| u32
| message_size
| The size in bytes of the entire message, including all headers and hmac
|-
| 0x08
| 0x04
| u32
| total_header_size
| The size in bytes of all headers, including the extra headers
|-
| 0x0C
| 0x04
| u32
| body_size
| The size in bytes of the body of the message
|-
| 0x10
| 0x04
| u32
| title_id
| The title id of the message
|-
| 0x14
| 0x04
| u32
| title_id2
| ???
|-
| 0x18
| 0x04
| u32
| batch_id
| The sending client sets an ID here if multiple messages should be batched together into one transaction
|-
| 0x1C
| 0x04
| u32
| transfer_id
| All messages from the same transfer (That is, sending the messages) contain the same transfer id
|-
| 0x20
| 0x08
| MessageId
| message_id
| The ID of the sending message
|-
| 0x28
| 0x04
| u32
| message_version
| ???
|-
| 0x2C
| 0x08
| MessageId
| message_id_2
| The message ID that this message is referring to, e.g. the individual responses in Streetpass Mii Plaza
|-
| 0x34
| 0x01
| u8
| recipients
| bitfield: 0x01: everyone; 0x02: friends
|-
| 0x35
| 0x01
| SendMethod
| send_method
|
|-
| 0x36
| 0x01
| bool
| unopened
| Set if the message hasn't been opened yet
|-
| 0x37
| 0x01
| bool
| is_new
| Set if the message is new
|-
| 0x38
| 0x08
| u64
| sender_id
|
|-
| 0x40
| 0x08
| u64
| sender_id_2
|
|-
| 0x48
| 0x0C
| Timestamp12
| sent
|
|-
| 0x54
| 0x0C
| Timestamp12
| received
|
|-
| 0x60
| 0x0C
| Timestamp12
| created
|
|-
| 0x6C
| 0x01
| u8
| send_count
| How often this message can be sent
|-
| 0x6D
| 0x01
| u8
| forward_count
| How often this message can be forwarded
|-
| 0x6E
| 0x02
| u16
| user_data
| ???
|}

ExtMessageHeader:
{| class="wikitable" border="1"
! Offset
! Size
! Type
! Name
! Description
|-
| 0x00
| 0x04
| u32
| type
| The type of the extra header
|-
| 0x04
| 0x04
| u32
| size
| Size, in bytes, of the extra header
|-
| 0x08
|
|
| body
| The body of the extra header
|}

Message:
{| class="wikitable" border="1"
! Offset
! Size
! Type
! Name
! Description
|-
| 0x00
| 0x70
| MessageHeader
| header
| The header of the message
|-
| 0x70
|
| ExtMessageHeader[]
| ext_headers
| An array of the extra headers for the message. The array keeps filling until the length no more until <code>header.total_header_size</code>
|-
|
|
|
| body
| The actual body/payload of the message
|-
|
| 0x20
| u8[0x20]
| hmac
| The hmac over the body with the hmac_key
|}

=== Slot (0x6161) ===
The slot groups multiple messages of one title id together into a single struct
{| class="wikitable" border="1"
! Offset
! Size
! Type
! Name
! Description
|-
| 0x00
| 0x02
| u16
| magic
| Equals 0x6161 (<code>aa</code>)
|-
| 0x02
| 0x02
| u16
| padding
|
|-
| 0x04
| 0x04
| u32
| size
| The size of bytes of the entire slot, including the header and all messages it contains
|-
| 0x08
| 0x04
| u32
| title_id
| The title id of the slot
|-
| 0x0C
| 0x04
| u32
| batch_id
| If the slot contains batched messages, the batch id is set to the same one as those messages
|-
| 0x10
| 0x04
| u32
| message_count
| The total number of messages in this slot
|-
| 0x14
|
| Message[]
| messages
| An array of length <code>message_count</code> all the messages of this slot
|}

=== BoxInfo (0x6262) ===
{| class="wikitable" border="1"
! Offset
! Size
! Type
! Name
! Description
|-
| 0x00
| 0x02
| u16
| magic
| Equals 0x6262 (<code>bb</code>)
|-
| 0x02
| 0x02
| u16
| padding
|
|-
| 0x04
| 0x04
| u32
| file_size
| The size of the box info in bytes
|-
| 0x08
| 0x04
| u32
| max_box_size
| The maximum allowed size of the box in bytes
|-
| 0x0C
| 0x04
| u32
| box_size
| The current size of the box in bytes
|-
| 0x10
| 0x04
| u32
| max_num_messages
| The maximum number of messages that the box can hold
|-
| 0x14
| 0x04
| u32
| num_messages
| The current number of messages in the box
|-
| 0x18
| 0x04
| u32
| max_batch_size
| The maximum size of a bach, in number of messages
|-
| 0x1C
| 0x04
| u32
| max_message_size
| The maximum size of a message, in bytes
|-
| 0x20
|
| MessageHeader[]
| message_headers
| An array of all message headers in this box of length <code>num_messages</code>
|}

=== MBoxInfo (0x6363) ===
This holds information on the message box, including both inbox and outbox
{| class="wikitable" border="1"
! Offset
! Size
! Type
! Name
! Description
|-
| 0x00
| 0x02
| u16
| magic
| Equals 0x6363 (<code>cc</code>)
|-
| 0x02
| 0x02
| u16
| padding
|
|-
| 0x04
| 0x04
| u32
| title_id
| The title id for this mbox
|-
| 0x08
| 0x04
| u32
| private_id
| ???
|-
| 0x0C
| 0x01
| u8
| mbox_type_flags
| 0x01: normal programs, 0x06: system programs, 0x80: silent notif
|-
| 0x0D
| 0x01
| bool
| enabled
| Weather this message box is enabled
|-
| 0x0E
| 0x02
| u16
| padding
|
|-
| 0x10
| 0x20
| u8[0x20]
| hmac_key
| The hmac key to make hmacs for messages. These are unique per title, however they are the same for all consoles.
|-
| 0x30
| 0x04
| u32
| padding
|
|-
| 0x34
| 0x0C
| Timestamp12
| last_accessed
|
|-
| 0x40
| 0x01
| bool
| flag_unread
| Does this message box contain unread messages?
|-
| 0x41
| 0x01
| bool
| flag_new
| Does this message box contain new messages?
|-
| 0x42
| 0x01
| bool
| flag_unknown
| ???
|-
| 0x43
| 0x01
| bool
| flag_unknown
| ???
|-
| 0x44
| 0x0C
| Timestamp12
| last_received
|
|-
| 0x50
| 0x04
| u32
| padding
|
|-
| 0x54
| 0x0C
| Timestamp12
| unknown_timestamp
| ???
|}

=== 0x6565 ===
SlotMetadata:
{| class="wikitable" border="1"
! Offset
! Size
! Type
! Name
! Description
|-
| 0x00
| 0x04
| u32
| title_id
| The title id of the slot
|-
| 0x04
| 0x04
| SendMethod
| send_method
| The send method for the slot
|-
| 0x08
| 0x04
| u32
| body_size
| The size of the slot body in bytes
|-
| 0x0C
| 0x04
| u32
| count
| Number of messages
|-
| 0x10
| 0x14
| '''unknown'''
| '''unknown'''
|
|}

Struct:
{| class="wikitable" border="1"
! Offset
! Length
! Type
! Name
! Description
|-
| 0x00
| 0x02
| u16
| magic
| Equals 0x6565 (<code>ee</code>)
|-
| 0x02
| 0x02
| u16
| padding
|
|-
| 0x04
| 0x28
| '''unknown'''
| '''unknown'''
|
|-
| 0x2C
| 0x360
| SlotMetadata[0x18]
| slots
| Metadata of all slots
|}

=== OBIndex (0x6767) ===
{| class="wikitable" border="1"
! Offset
! Size
! Type
! Name
! Description
|-
| 0x00
| 0x02
| u16
| magic
| Equals 0x6767 (<code>gg</code>)
|-
| 0x02
| 0x02
| u16
| padding
|
|-
| 0x04
| 0x04
| u32
| num_messages
| The number of messages in the outbox
|-
| 0x08
|
| MessageId[]
| message_ids
| An array of the message IDs in the outbox, of length <code>num_messages</code>
|}

=== MBoxList (0x6868) ===
{| class="wikitable" border="1"
! Offset
! Size
! Type
! Name
! Description
|-
| 0x00
| 0x02
| u16
| magic
| Equals 0x6868 (<code>hh</code>)
|-
| 0x02
| 0x02
| u16
| padding
|
|-
| 0x04
| 0x04
| u32
| version
|
|-
| 0x08
| 0x04
| u32
| num_boxes
| The number of boxes (= games with streetpass enabled)
|-
| 0x0C
| 0x180
| char[0x18][0x10]
| box_names
| A 0x18-long array of all the box names (= hex encoded title ids) of games with streetpass enabled
|}

[[Category:Nintendo Software]]

CECDS:SprDone

2025-03-16T17:51:03Z

Sorunome: /* Request */

= Request =
{{IPC/Request}}
{{#vardefine:ipc_offset|0}}
{{IPC/RequestHeader|0x0414|1|0}}
{{IPC/RequestEntry|(bool) success}}
{{IPC/RequestEnd}}

= Response =
{{IPC/Request}}
{{#vardefine:ipc_offset|0}}
{{IPC/RequestEntry|Header code}}
{{IPC/RequestEntry|Result code}}
{{IPC/RequestEnd}}

= Description =
Indicates that a cecd spr exchange is completely done. Based on <code>success</code> the changes to the cec data re committed or rolled back.

Sets the [[CECD_Services#CecSprStatus|Cec Spr Status]] to <code>CEC_SPR_CONNECTION_FINISHED</code>.

CECDS:SprFinaliseRecv

2025-03-16T17:50:42Z

Sorunome: /* Request */

= Request =
{{IPC/Request}}
{{#vardefine:ipc_offset|0}}
{{IPC/RequestHeader|0x0413|0|0}}
{{IPC/RequestEnd}}

= Response =
{{IPC/Request}}
{{#vardefine:ipc_offset|0}}
{{IPC/RequestEntry|Header code}}
{{IPC/RequestEntry|Result code}}
{{IPC/RequestEnd}}

= Description =
Tells the cecd service that it is done receiving data for the spr exchange now.

Requires the [[CECD_Services#CecSprStatus|Cec Spr Status]] to be <code>CEC_SPR_RECEIVE_READY</code> and sets it to <code>CEC_SPR_RECEIVE</code>.

CECDS:SprAddSlot

2025-03-16T17:50:20Z

Sorunome: /* Request */

= Request =
{{IPC/Request}}
{{#vardefine:ipc_offset|0}}
{{IPC/RequestHeader|0x0412|3|2}}
{{IPC/RequestEntry|title id}}
{{IPC/RequestEntry|<code>0xFF</code> (flags?)}}
{{IPC/RequestEntry|buffer size}}
{{IPC/MapPointerR|buffer address}}
{{IPC/RequestEnd}}

= Response =
{{IPC/Request}}
{{#vardefine:ipc_offset|0}}
{{IPC/RequestEntry|Header code}}
{{IPC/RequestEntry|Result code}}
{{IPC/RequestEnd}}

= Description =
This adds a [[StreetPass#Slot_.280x6161.29|slot]] to be received.

Requires the [[CECD_Services#CecSprStatus|Cec Spr Status]] to be <code>CEC_SPR_RECEIVE_READY</code>.

CECDS:SprSetRecvSlotsMetadata

2025-03-16T17:50:02Z

Sorunome: /* Request */

= Request =
{{IPC/Request}}
{{#vardefine:ipc_offset|0}}
{{IPC/RequestHeader|0x0411|1|2}}
{{IPC/RequestEntry|buffer size}}
{{IPC/MapPointerR|buffer address}}
{{IPC/RequestEnd}}

= Response =
{{IPC/Request}}
{{#vardefine:ipc_offset|0}}
{{IPC/RequestEntry|Header code}}
{{IPC/RequestEntry|Result code}}
{{IPC/RequestEnd}}

= Description =
This notifies the cec service of the [[StreetPass#Slot_.280x6161.29|slots]] that it will receive shortly by sending it metadata objects for each title.
Each metadata object consists out of a tuple of three words: <code>send method</code>, <code>title_id</code>, <code>size</code> whereas the size is the size in bytes of the corresponding spr slot.

Requires the [[CECD_Services#CecSprStatus|Cec Spr Status]] to be <code>CEC_SPR_RECEIVE_READY</code>.

CECDS:SprStartRecv

2025-03-16T17:49:41Z

Sorunome: /* Request */

= Request =
{{IPC/Request}}
{{#vardefine:ipc_offset|0}}
{{IPC/RequestHeader|0x0410|0|0}}
{{IPC/RequestEnd}}

= Response =
{{IPC/Request}}
{{#vardefine:ipc_offset|0}}
{{IPC/RequestEntry|Header code}}
{{IPC/RequestEntry|Result code}}
{{IPC/RequestEnd}}

= Description =
Sets the cecd service start expecting received spr data.

Requires the [[CECD_Services#CecSprStatus|Cec Spr Status]] to be <code>CEC_SPR_SEND</code> and sets it to <code>CEC_SPR_RECEIVE_READY</code>.

CECDS:SprFinaliseSend

2025-03-16T17:49:24Z

Sorunome: /* Request */

= Request =
{{IPC/Request}}
{{#vardefine:ipc_offset|0}}
{{IPC/RequestHeader|0x040F|0|0}}
{{IPC/RequestEnd}}

= Response =
{{IPC/Request}}
{{#vardefine:ipc_offset|0}}
{{IPC/RequestEntry|Header code}}
{{IPC/RequestEntry|Result code}}
{{IPC/RequestEnd}}

= Description =
Tells the cecd service that fetching data for sending is done now. After this the implementation is expected to actually send the data to the remote provider.

Requires the [[CECD_Services#CecSprStatus|Cec Spr Status]] to be <code>CEC_SPR_SEND_READY</code> and sets it to <code>CEC_SPR_SEND</code>.

CECDS:SprSetTitleSent

2025-03-16T17:49:07Z

Sorunome: /* Request */

= Request =
{{IPC/Request}}
{{#vardefine:ipc_offset|0}}
{{IPC/RequestHeader|0x040E|2|0}}
{{IPC/RequestEntry|title id}}
{{IPC/RequestEntry|(bool) success}}
{{IPC/RequestEnd}}

= Response =
{{IPC/Request}}
{{#vardefine:ipc_offset|0}}
{{IPC/RequestEntry|Header code}}
{{IPC/RequestEntry|Result code}}
{{IPC/RequestEnd}}

= Description =
Sets weather a title was successfully sent for the SPR connection.

Requires the [[CECD_Services#CecSprStatus|Cec Spr Status]] to be <code>CEC_SPR_SEND_READY</code>, <code>CEC_SPR_SEND</code> or <code>CEC_SPR_RECEIVE_READY</code>.

CECDS:SprGetSlot

2025-03-16T17:48:32Z

Sorunome: /* Request */

= Request =
{{IPC/Request}}
{{#vardefine:ipc_offset|0}}
{{IPC/RequestHeader|0x040D|2|2}}
{{IPC/RequestEntry|title id}}
{{IPC/RequestEntry|buffer size}}
{{IPC/MapPointerW|buffer address}}
{{IPC/RequestEnd}}

= Response =
{{IPC/Request}}
{{#vardefine:ipc_offset|0}}
{{IPC/RequestEntry|Header code}}
{{IPC/RequestEntry|Result code}}
{{IPC/RequestEnd}}

= Description =
This copies a [[StreetPass#Slot_.280x6161.29|slot]] to be sent into the specified buffer.

Requires the [[CECD_Services#CecSprStatus|Cec Spr Status]] to be <code>CEC_SPR_SEND_READY</code>.

CECDS:SprGetSendSlotsMetadata

2025-03-16T17:48:12Z

Sorunome: /* Request */

= Request =
{{IPC/Request}}
{{#vardefine:ipc_offset|0}}
{{IPC/RequestHeader|0x040C|1|2}}
{{IPC/RequestEntry|buffer size}}
{{IPC/MapPointerW|buffer address}}
{{IPC/RequestEnd}}

= Response =
{{IPC/Request}}
{{#vardefine:ipc_offset|0}}
{{IPC/RequestEntry|Header code}}
{{IPC/RequestEntry|Result code}}
{{IPC/RequestEntry|Amount of slots read}}
{{IPC/RequestEnd}}

= Description =
This copies the metadata for all [[StreetPass#Slot_.280x6161.29|slots]] that need to be sent into the specified buffer.
Each metadata object consists out of a tuple of three words: <code>send method</code>, <code>title_id</code>, <code>size</code> whereas the size is the size in bytes of the corresponding spr slot. Copies up to <code>buffer size / (4*3)</code> slots into the buffer.

Returns the amount of slots read, ''not'' the amount of bytes read.

Requires the [[CECD_Services#CecSprStatus|Cec Spr Status]] to be <code>CEC_SPR_SEND_READY</code>.

CECD Services

2025-03-16T17:26:55Z

Sorunome: /* CECD Service "cecd:s" */ Put in the proper header codes

[[Category:Services]]

Streetpass stuff.

= CECD Service "cecd:u" =
{| class="wikitable" border="1"
|-
! Command Header
! Description
|-
| 0x000100C2
| Open/[[CECDU:OpenRawFile|OpenRawFile]]
|-
| 0x00020042
| Read/[[CECDU:ReadRawFile|ReadRawFile]]
|-
| 0x00030104
| [[CECDU:ReadMessage|ReadMessage]]
|-
| 0x00040106
| [[CECDU:ReadMessageWithHMAC|ReadMessageWithHMAC]]
|-
| 0x00050042
| Write/[[CECDU:WriteRawFile|WriteRawFile]]
|-
| 0x00060104
| [[CECDU:WriteMessage|WriteMessage]]
|-
| 0x00070106
| [[CECDU:WriteMessageWithHMAC|WriteMessageWithHMAC]]
|-
| 0x00080102
| [[CECDU:Delete|Delete]]
|-
| 0x000900C2
| SetData (16*length+10 of CecMessageId buffer in cmdbuff[4] (always 16*8+10), CecMessageId* in cmdbuf[5])
|-
| 0x000A00C4
| ReadData/[[CECDU:GetSystemInfo|GetSystemInfo]]
|-
| 0x000B0040
| [[CECDU:Start|Start]]
|-
| 0x000C0040
| [[CECDU:Stop|Stop]]
|-
| 0x000D0082
| GetCecInfoBuffer
|-
| 0x000E0000
| GetCecdState (returns CecStateAbbreviated in cmdbuf[2])
|-
| 0x000F0000
| GetCecInfoEventHandle (returns event handle in cmdbuf[3])
|-
| 0x00100000
| GetChangeStateEventHandle (returns event handle in cmdbuf[3])
|-
| 0x00110104
| [[CECDU:OpenAndWrite|OpenAndWrite]]
|-
| 0x00120104
| [[CECDU:OpenAndRead|OpenAndRead]]
|-
| 0x001E0082
| [[CECDU:GetEventLog|GetEventLog]]
|-
| 0x001F0000
| [[CECDU:GetEventLogStart|GetEventLogStart]]
|-
| 0x00200000
| [[CECDU:GetEventLogEntryCount|GetEventLogEntryCount]]
|-
| 0x0021....
| ?
|-
|}

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

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

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

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

= CECD Service "cecd:s" =

This contains a similar (probably the same) command handler from 0x0001.... to 0x0021.... as them in cecd:u. In addition, it also contains
{| class="wikitable" border="1"
|-
! Command Header
! Description
|-
| 0x0401....
| ?
|-
| 0x04020002
| GetCecInfoEventHandleSys
|-
| 0x040A0000
| [[CECDS:SprCreate|SprCreate]]
|-
| 0x040B0000
| [[CECDS:SprInitialise|SprInitialise]]
|-
| 0x040C0042
| [[CECDS:SprGetSendSlotsMetadata|SprGetSendSlotsMetadata]]
|-
| 0x040D0082
| [[CECDS:SprGetSlot|SprGetSlot]]
|-
| 0x040E0080
| [[CECDS:SprSetTitleSent|SprSetTitleSent]]
|-
| 0x040F0000
| [[CECDS:SprFinaliseSend|SprFinaliseSend]]
|-
| 0x04100000
| [[CECDS:SprStartRecv|SprStartRecv]]
|-
| 0x04110042
| [[CECDS:SprSetRecvSlotsMetadata|SprSetRecvSlotsMetadata]]
|-
| 0x041200C2
| [[CECDS:SprAddSlot|SprAddSlot]]
|-
| 0x04130000
| [[CECDS:SprFinaliseRecv|SprFinaliseRecv]]
|-
| 0x04140040
| [[CECDS:SprDone|SprDone]]
|-
| 0x04150000
| [[CECDS:GenHashConsoleUnique|GenHashConsoleUnique]]
|-
| 0x04160002
| ?
|-
| 0x0417....
| ?
|-
|}

=== CecSprStatus ===
This enum is used internally of the cecd service to keep track of which state of an SPR exchange it is in currently.

{| class="wikitable" border="1"
! Name
! Value
! Notes
|-
| CEC_SPR_SEND_RECV_START
| 0
| The internal objects were just created
|-
| CEC_SPR_SEND_RECV_INIT
| 1
| The internal objects for sending and receiving have been initialised
|-
| CEC_SPR_SEND_READY
| 2
| The sysmodule is ready for SPR Send, now it is possible to fetch the SPR data needed
|-
| CEC_SPR_SEND
| 3
| The other program should be sending the SPR request now
|-
| CEC_SPR_RECEIVE_READY
| 4
| The sysmodule is ready to receive SPR data now
|-
| CEC_SPR_RECEIVE
| 5
| The sysmodule is done receiving SPR data
|-
| CEC_SPR_CONNECTION_FINISHED
| 6
|
|}

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

CECDS:SprFinaliseRecv

2025-03-16T17:24:45Z

Sorunome: Created page with "= Request = {{IPC/Request}} {{#vardefine:ipc_offset|0}} {{IPC/RequestEntry|Header code <code>0x04130000</code>}} {{IPC/RequestEnd}} = Response = {{IPC/Request}} {{#vardefine:..."

= Request =
{{IPC/Request}}
{{#vardefine:ipc_offset|0}}
{{IPC/RequestEntry|Header code <code>0x04130000</code>}}
{{IPC/RequestEnd}}

= Response =
{{IPC/Request}}
{{#vardefine:ipc_offset|0}}
{{IPC/RequestEntry|Header code}}
{{IPC/RequestEntry|Result code}}
{{IPC/RequestEnd}}

= Description =
Tells the cecd service that it is done receiving data for the spr exchange now.

Requires the [[CECD_Services#CecSprStatus|Cec Spr Status]] to be <code>CEC_SPR_RECEIVE_READY</code> and sets it to <code>CEC_SPR_RECEIVE</code>.

CECDS:SprFinaliseSend

2025-03-16T17:24:37Z

Sorunome: /* Description */

= Request =
{{IPC/Request}}
{{#vardefine:ipc_offset|0}}
{{IPC/RequestEntry|Header code <code>0x040F0000</code>}}
{{IPC/RequestEnd}}

= Response =
{{IPC/Request}}
{{#vardefine:ipc_offset|0}}
{{IPC/RequestEntry|Header code}}
{{IPC/RequestEntry|Result code}}
{{IPC/RequestEnd}}

= Description =
Tells the cecd service that fetching data for sending is done now. After this the implementation is expected to actually send the data to the remote provider.

Requires the [[CECD_Services#CecSprStatus|Cec Spr Status]] to be <code>CEC_SPR_SEND_READY</code> and sets it to <code>CEC_SPR_SEND</code>.

CECDS:SprDone

2025-03-16T17:22:50Z

Sorunome: Created page with "= Request = {{IPC/Request}} {{#vardefine:ipc_offset|0}} {{IPC/RequestEntry|Header code <code>0x04140040</code>}} {{IPC/RequestEntry|(bool) success}} {{IPC/RequestEnd}} = Resp..."

= Request =
{{IPC/Request}}
{{#vardefine:ipc_offset|0}}
{{IPC/RequestEntry|Header code <code>0x04140040</code>}}
{{IPC/RequestEntry|(bool) success}}
{{IPC/RequestEnd}}

= Response =
{{IPC/Request}}
{{#vardefine:ipc_offset|0}}
{{IPC/RequestEntry|Header code}}
{{IPC/RequestEntry|Result code}}
{{IPC/RequestEnd}}

= Description =
Indicates that a cecd spr exchange is completely done. Based on <code>success</code> the changes to the cec data re committed or rolled back.

Sets the [[CECD_Services#CecSprStatus|Cec Spr Status]] to <code>CEC_SPR_CONNECTION_FINISHED</code>.

CECDS:SprFinaliseSend

2025-03-16T17:20:42Z

Sorunome:

= Request =
{{IPC/Request}}
{{#vardefine:ipc_offset|0}}
{{IPC/RequestEntry|Header code <code>0x040F0000</code>}}
{{IPC/RequestEnd}}

= Response =
{{IPC/Request}}
{{#vardefine:ipc_offset|0}}
{{IPC/RequestEntry|Header code}}
{{IPC/RequestEntry|Result code}}
{{IPC/RequestEnd}}

= Description =
Tells the cecd service that fetching data for sending is done now. After this the implementation is expected to actually send the data to the remote provider

Requires the [[CECD_Services#CecSprStatus|Cec Spr Status]] to be <code>CEC_SPR_RECEIVE_READY</code> and sets it to <code>CEC_SPR_RECEIVE</code>.

CECDS:SprAddSlot

2025-03-16T17:19:01Z

Sorunome: Created page with "= Request = {{IPC/Request}} {{#vardefine:ipc_offset|0}} {{IPC/RequestEntry|Header code <code>0x041200C2</code>}} {{IPC/RequestEntry|title id}} {{IPC/RequestEntry|<code>0xFF</c..."

= Request =
{{IPC/Request}}
{{#vardefine:ipc_offset|0}}
{{IPC/RequestEntry|Header code <code>0x041200C2</code>}}
{{IPC/RequestEntry|title id}}
{{IPC/RequestEntry|<code>0xFF</code> (flags?)}}
{{IPC/RequestEntry|buffer size}}
{{IPC/MapPointerR|buffer address}}
{{IPC/RequestEnd}}

= Response =
{{IPC/Request}}
{{#vardefine:ipc_offset|0}}
{{IPC/RequestEntry|Header code}}
{{IPC/RequestEntry|Result code}}
{{IPC/RequestEnd}}

= Description =
This adds a [[StreetPass#Slot_.280x6161.29|slot]] to be received.

Requires the [[CECD_Services#CecSprStatus|Cec Spr Status]] to be <code>CEC_SPR_RECEIVE_READY</code>.

CECDS:SprSetRecvSlotsMetadata

2025-03-16T17:16:50Z

Sorunome: Created page with "= Request = {{IPC/Request}} {{#vardefine:ipc_offset|0}} {{IPC/RequestEntry|Header code <code>0x04110042</code>}} {{IPC/RequestEntry|buffer size}} {{IPC/MapPointerR|buffer addr..."

= Request =
{{IPC/Request}}
{{#vardefine:ipc_offset|0}}
{{IPC/RequestEntry|Header code <code>0x04110042</code>}}
{{IPC/RequestEntry|buffer size}}
{{IPC/MapPointerR|buffer address}}
{{IPC/RequestEnd}}

= Response =
{{IPC/Request}}
{{#vardefine:ipc_offset|0}}
{{IPC/RequestEntry|Header code}}
{{IPC/RequestEntry|Result code}}
{{IPC/RequestEnd}}

= Description =
This notifies the cec service of the [[StreetPass#Slot_.280x6161.29|slots]] that it will receive shortly by sending it metadata objects for each title.
Each metadata object consists out of a tuple of three words: <code>send method</code>, <code>title_id</code>, <code>size</code> whereas the size is the size in bytes of the corresponding spr slot.

Requires the [[CECD_Services#CecSprStatus|Cec Spr Status]] to be <code>CEC_SPR_RECEIVE_READY</code>.

CECDS:SprStartRecv

2025-03-16T17:14:43Z

Sorunome: Created page with "= Request = {{IPC/Request}} {{#vardefine:ipc_offset|0}} {{IPC/RequestEntry|Header code <code>0x04100000</code>}} {{IPC/RequestEnd}} = Response = {{IPC/Request}} {{#vardefine:..."

= Request =
{{IPC/Request}}
{{#vardefine:ipc_offset|0}}
{{IPC/RequestEntry|Header code <code>0x04100000</code>}}
{{IPC/RequestEnd}}

= Response =
{{IPC/Request}}
{{#vardefine:ipc_offset|0}}
{{IPC/RequestEntry|Header code}}
{{IPC/RequestEntry|Result code}}
{{IPC/RequestEnd}}

= Description =
Sets the cecd service start expecting received spr data.

Requires the [[CECD_Services#CecSprStatus|Cec Spr Status]] to be <code>CEC_SPR_SEND</code> and sets it to <code>CEC_SPR_RECEIVE_READY</code>.

CECDS:SprFinaliseSend

2025-03-16T17:13:04Z

Sorunome: Created page with "= Request = {{IPC/Request}} {{#vardefine:ipc_offset|0}} {{IPC/RequestEntry|Header code <code>0x040F0000</code>}} {{IPC/RequestEnd}} = Response = {{IPC/Request}} {{#vardefine:..."

= Request =
{{IPC/Request}}
{{#vardefine:ipc_offset|0}}
{{IPC/RequestEntry|Header code <code>0x040F0000</code>}}
{{IPC/RequestEnd}}

= Response =
{{IPC/Request}}
{{#vardefine:ipc_offset|0}}
{{IPC/RequestEntry|Header code}}
{{IPC/RequestEntry|Result code}}
{{IPC/RequestEnd}}

= Description =
Tells the cecd service that fetching data for sending is done now. After this the implementation is expected to actually send the data to the remote provider

Requires the [[CECD_Services#CecSprStatus|Cec Spr Status]] to be <code>CEC_SPR_SEND_READY</code> and sets it to <code>CEC_SPR_SEND</code>.

CECDS:SprSetTitleSent

2025-03-16T17:10:06Z

Sorunome:

= Request =
{{IPC/Request}}
{{#vardefine:ipc_offset|0}}
{{IPC/RequestEntry|Header code <code>0x040E0080</code>}}
{{IPC/RequestEntry|title id}}
{{IPC/RequestEntry|(bool) success}}
{{IPC/RequestEnd}}

= Response =
{{IPC/Request}}
{{#vardefine:ipc_offset|0}}
{{IPC/RequestEntry|Header code}}
{{IPC/RequestEntry|Result code}}
{{IPC/RequestEnd}}

= Description =
Sets weather a title was successfully sent for the SPR connection.

Requires the [[CECD_Services#CecSprStatus|Cec Spr Status]] to be <code>CEC_SPR_SEND_READY</code>, <code>CEC_SPR_SEND</code> or <code>CEC_SPR_RECEIVE_READY</code>.

CECDS:SprGetSendSlotsMetadata

2025-03-16T17:05:56Z

Sorunome: /* Description */

= Request =
{{IPC/Request}}
{{#vardefine:ipc_offset|0}}
{{IPC/RequestEntry|Header code <code>0x040C0042</code>}}
{{IPC/RequestEntry|buffer size}}
{{IPC/MapPointerW|buffer address}}
{{IPC/RequestEnd}}

= Response =
{{IPC/Request}}
{{#vardefine:ipc_offset|0}}
{{IPC/RequestEntry|Header code}}
{{IPC/RequestEntry|Result code}}
{{IPC/RequestEntry|Amount of slots read}}
{{IPC/RequestEnd}}

= Description =
This copies the metadata for all [[StreetPass#Slot_.280x6161.29|slots]] that need to be sent into the specified buffer.
Each metadata object consists out of a tuple of three words: <code>send method</code>, <code>title_id</code>, <code>size</code> whereas the size is the size in bytes of the corresponding spr slot. Copies up to <code>buffer size / (4*3)</code> slots into the buffer.

Returns the amount of slots read, ''not'' the amount of bytes read.

Requires the [[CECD_Services#CecSprStatus|Cec Spr Status]] to be <code>CEC_SPR_SEND_READY</code>.

CECDS:SprGetSlot

2025-03-16T17:05:49Z

Sorunome: /* Description */

= Request =
{{IPC/Request}}
{{#vardefine:ipc_offset|0}}
{{IPC/RequestEntry|Header code <code>0x040D0082</code>}}
{{IPC/RequestEntry|title id}}
{{IPC/RequestEntry|buffer size}}
{{IPC/MapPointerW|buffer address}}
{{IPC/RequestEnd}}

= Response =
{{IPC/Request}}
{{#vardefine:ipc_offset|0}}
{{IPC/RequestEntry|Header code}}
{{IPC/RequestEntry|Result code}}
{{IPC/RequestEnd}}

= Description =
This copies a [[StreetPass#Slot_.280x6161.29|slot]] to be sent into the specified buffer.

Requires the [[CECD_Services#CecSprStatus|Cec Spr Status]] to be <code>CEC_SPR_SEND_READY</code>.

CECDS:SprSetTitleSent

2025-03-16T17:05:37Z

Sorunome: Created page with "= Request = {{IPC/Request}} {{#vardefine:ipc_offset|0}} {{IPC/RequestEntry|Header code <code>0x040D0082</code>}} {{IPC/RequestEntry|title id}} {{IPC/RequestEntry|buffer size}}..."

CECDS:SprCreate

2025-03-16T17:05:15Z

Sorunome: /* Description */

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

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

= Description =
This creates the data needed to start an SPR exchange. Sets the [[CECD_Services#CecSprStatus|Cec Spr Status]] to <code>CEC_SPR_SEND_RECV_START</code> and then to <code>CEC_SPR_SEND_RECV_INIT</code> upon success.

CECDS:SprInitialise

2025-03-16T17:04:54Z

Sorunome: /* Description */

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

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

= Description =
This initialises the data needed to start an SPR exchange. Requires the [[CECD_Services#CecSprStatus|Cec Spr Status]] to be <code>CEC_SPR_SEND_RECV_INIT</code> and sets it to <code>CEC_SPR_SEND_READY</code> upon success.

CECDS:SprGetSlot

2025-03-16T17:02:38Z

CECDS:SprGetSendSlotsMetadata

2025-03-16T17:02:17Z

Sorunome: /* Description */

CECDS:SprGetSendSlotsMetadata

2025-03-16T16:59:30Z

Sorunome: /* Description */ Formatting

= Request =
{{IPC/Request}}
{{#vardefine:ipc_offset|0}}
{{IPC/RequestEntry|Header code <code>0x040C0042</code>}}
{{IPC/RequestEntry|buffer size}}
{{IPC/MapPointerW|buffer address}}
{{IPC/RequestEnd}}

= Response =
{{IPC/Request}}
{{#vardefine:ipc_offset|0}}
{{IPC/RequestEntry|Header code}}
{{IPC/RequestEntry|Result code}}
{{IPC/RequestEntry|Amount of slots read}}
{{IPC/RequestEnd}}

= Description =
This copies the metadata for all slots that need to be sent into the specified buffer.
Each metadata object consists out of a tuple of three words: <code>send method</code>, <code>title_id</code>, <code>size</code> whereas the size is the size in bytes of the corresponding spr slot. Copies up to <code>buffer size / (4*3)</code> slots into the buffer.

Returns the amount of slots read, ''not'' the amount of bytes read.

Requires the [[CECD_Services#CecSprStatus|Cec Spr Status]] to be <code>CEC_SPR_SEND_RECV_INIT</code>.

CECDS:SprGetSendSlotsMetadata

2025-03-16T16:59:01Z

Sorunome: Created page with "= Request = {{IPC/Request}} {{#vardefine:ipc_offset|0}} {{IPC/RequestEntry|Header code <code>0x040C0042</code>}} {{IPC/RequestEntry|buffer size}} {{IPC/MapPointerW|buffer addr..."

= Request =
{{IPC/Request}}
{{#vardefine:ipc_offset|0}}
{{IPC/RequestEntry|Header code <code>0x040C0042</code>}}
{{IPC/RequestEntry|buffer size}}
{{IPC/MapPointerW|buffer address}}
{{IPC/RequestEnd}}

= Response =
{{IPC/Request}}
{{#vardefine:ipc_offset|0}}
{{IPC/RequestEntry|Header code}}
{{IPC/RequestEntry|Result code}}
{{IPC/RequestEntry|Amount of slots read}}
{{IPC/RequestEnd}}

= Description =
This copies the metadata for all slots that need to be sent into the specified buffer.
Each metadata object consists out of a tuple of three words: <code>send method</code>, <code>title_id</code>, <code>size</code> whereas the size is the size in bytes of the corresponding spr slot. Copies up to <code>buffer size / (4*3)</code> slots into the buffer.

Returns the amount of slots read, _not_ the amount of bytes read.

Requires the [[CECD_Services#CecSprStatus|Cec Spr Status]] to be <code>CEC_SPR_SEND_RECV_INIT</code>.

CECDS:SprInitialise

2025-03-16T16:47:43Z

Sorunome: Created page with "= Request = {| class="wikitable" border="1" |- ! Index Word ! Description |- | 0 | Header code [0x040B0000] |- |} = Response = {| class="wikitable" border="1" |- ! Index Wo..."

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

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

= Description =
This initialises the data needed to start an SPR exchange. Requires the [[CECD_Services#CecSprStatus|Cec Spr Status]] to be <code>CEC_SPR_SEND_RECV_START</code> and sets it to <code>CEC_SPR_SEND_RECV_INIT</code> upon success.

CECDS:SprCreate

2025-03-16T16:46:15Z

Sorunome: Created page with "= Request = {| class="wikitable" border="1" |- ! Index Word ! Description |- | 0 | Header code [0x040A0000] |- |} = Response = {| class="wikitable" border="1" |- ! Index Wo..."

CECD Services

2025-03-16T16:45:01Z

Sorunome: /* CecSprStatus */ Removed falsely added enum values

[[Category:Services]]

Streetpass stuff.

= CECD Service "cecd:u" =
{| class="wikitable" border="1"
|-
! Command Header
! Description
|-
| 0x000100C2
| Open/[[CECDU:OpenRawFile|OpenRawFile]]
|-
| 0x00020042
| Read/[[CECDU:ReadRawFile|ReadRawFile]]
|-
| 0x00030104
| [[CECDU:ReadMessage|ReadMessage]]
|-
| 0x00040106
| [[CECDU:ReadMessageWithHMAC|ReadMessageWithHMAC]]
|-
| 0x00050042
| Write/[[CECDU:WriteRawFile|WriteRawFile]]
|-
| 0x00060104
| [[CECDU:WriteMessage|WriteMessage]]
|-
| 0x00070106
| [[CECDU:WriteMessageWithHMAC|WriteMessageWithHMAC]]
|-
| 0x00080102
| [[CECDU:Delete|Delete]]
|-
| 0x000900C2
| SetData (16*length+10 of CecMessageId buffer in cmdbuff[4] (always 16*8+10), CecMessageId* in cmdbuf[5])
|-
| 0x000A00C4
| ReadData/[[CECDU:GetSystemInfo|GetSystemInfo]]
|-
| 0x000B0040
| [[CECDU:Start|Start]]
|-
| 0x000C0040
| [[CECDU:Stop|Stop]]
|-
| 0x000D0082
| GetCecInfoBuffer
|-
| 0x000E0000
| GetCecdState (returns CecStateAbbreviated in cmdbuf[2])
|-
| 0x000F0000
| GetCecInfoEventHandle (returns event handle in cmdbuf[3])
|-
| 0x00100000
| GetChangeStateEventHandle (returns event handle in cmdbuf[3])
|-
| 0x00110104
| [[CECDU:OpenAndWrite|OpenAndWrite]]
|-
| 0x00120104
| [[CECDU:OpenAndRead|OpenAndRead]]
|-
| 0x001E0082
| [[CECDU:GetEventLog|GetEventLog]]
|-
| 0x001F0000
| [[CECDU:GetEventLogStart|GetEventLogStart]]
|-
| 0x00200000
| [[CECDU:GetEventLogEntryCount|GetEventLogEntryCount]]
|-
| 0x0021....
| ?
|-
|}

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

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

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

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

= CECD Service "cecd:s" =

This contains a similar (probably the same) command handler from 0x0001.... to 0x0021.... as them in cecd:u. In addition, it also contains
{| class="wikitable" border="1"
|-
! Command Header
! Description
|-
| 0x0401....
| ?
|-
| 0x04020002
| GetCecInfoEventHandleSys
|-
| 0x040A....
| [[CECDS:SprCreate|SprCreate]]
|-
| 0x040B....
| [[CECDS:SprInitialise|SprInitialise]]
|-
| 0x040C0042
| [[CECDS:SprGetSendSlotsMetadata|SprGetSendSlotsMetadata]]
|-
| 0x040D0082
| [[CECDS:SprGetSlot|SprGetSlot]] title_id, write_buffer, buffer_size
|-
| 0x040E....
| [[CECDS:SprSetTitleSent|SprSetTitleSent]] title_id, bool success
|-
| 0x040F....
| [[CECDS:SprFinaliseSend|SprFinaliseSend]]
|-
| 0x0410....
| [[CECDS:SprStartRecv|SprStartRecv]]
|-
| 0x04110042
| [[CECDS:SprSetRecvSlotsMetadata|SprSetRecvSlotsMetadata]]
|-
| 0x041200C2
| [[CECDS:SprAddSlot|SprAddSlot]]
|-
| 0x0413....
| [[CECDS:SprFinaliseRecv|SprFinaliseRecv]]
|-
| 0x0414....
| [[CECDS:SprDone|SprDone]] bool success
|-
| 0x04150000
| [[CECDS:GenHashConsoleUnique|GenHashConsoleUnique]]
|-
| 0x04160002
| ?
|-
| 0x0417....
| ?
|-
|}

=== CecSprStatus ===
This enum is used internally of the cecd service to keep track of which state of an SPR exchange it is in currently.

{| class="wikitable" border="1"
! Name
! Value
! Notes
|-
| CEC_SPR_SEND_RECV_START
| 0
| The internal objects were just created
|-
| CEC_SPR_SEND_RECV_INIT
| 1
| The internal objects for sending and receiving have been initialised
|-
| CEC_SPR_SEND_READY
| 2
| The sysmodule is ready for SPR Send, now it is possible to fetch the SPR data needed
|-
| CEC_SPR_SEND
| 3
| The other program should be sending the SPR request now
|-
| CEC_SPR_RECEIVE_READY
| 4
| The sysmodule is ready to receive SPR data now
|-
| CEC_SPR_RECEIVE
| 5
| The sysmodule is done receiving SPR data
|-
| CEC_SPR_CONNECTION_FINISHED
| 6
|
|}

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

CECD Services

2025-03-16T16:36:24Z

Sorunome: Linkify the names for the cecds:spr methods, renaming 0x411 to be more consistent with the remaining

[[Category:Services]]

Streetpass stuff.

= CECD Service "cecd:u" =
{| class="wikitable" border="1"
|-
! Command Header
! Description
|-
| 0x000100C2
| Open/[[CECDU:OpenRawFile|OpenRawFile]]
|-
| 0x00020042
| Read/[[CECDU:ReadRawFile|ReadRawFile]]
|-
| 0x00030104
| [[CECDU:ReadMessage|ReadMessage]]
|-
| 0x00040106
| [[CECDU:ReadMessageWithHMAC|ReadMessageWithHMAC]]
|-
| 0x00050042
| Write/[[CECDU:WriteRawFile|WriteRawFile]]
|-
| 0x00060104
| [[CECDU:WriteMessage|WriteMessage]]
|-
| 0x00070106
| [[CECDU:WriteMessageWithHMAC|WriteMessageWithHMAC]]
|-
| 0x00080102
| [[CECDU:Delete|Delete]]
|-
| 0x000900C2
| SetData (16*length+10 of CecMessageId buffer in cmdbuff[4] (always 16*8+10), CecMessageId* in cmdbuf[5])
|-
| 0x000A00C4
| ReadData/[[CECDU:GetSystemInfo|GetSystemInfo]]
|-
| 0x000B0040
| [[CECDU:Start|Start]]
|-
| 0x000C0040
| [[CECDU:Stop|Stop]]
|-
| 0x000D0082
| GetCecInfoBuffer
|-
| 0x000E0000
| GetCecdState (returns CecStateAbbreviated in cmdbuf[2])
|-
| 0x000F0000
| GetCecInfoEventHandle (returns event handle in cmdbuf[3])
|-
| 0x00100000
| GetChangeStateEventHandle (returns event handle in cmdbuf[3])
|-
| 0x00110104
| [[CECDU:OpenAndWrite|OpenAndWrite]]
|-
| 0x00120104
| [[CECDU:OpenAndRead|OpenAndRead]]
|-
| 0x001E0082
| [[CECDU:GetEventLog|GetEventLog]]
|-
| 0x001F0000
| [[CECDU:GetEventLogStart|GetEventLogStart]]
|-
| 0x00200000
| [[CECDU:GetEventLogEntryCount|GetEventLogEntryCount]]
|-
| 0x0021....
| ?
|-
|}

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

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

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

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

= CECD Service "cecd:s" =

This contains a similar (probably the same) command handler from 0x0001.... to 0x0021.... as them in cecd:u. In addition, it also contains
{| class="wikitable" border="1"
|-
! Command Header
! Description
|-
| 0x0401....
| ?
|-
| 0x04020002
| GetCecInfoEventHandleSys
|-
| 0x040A....
| [[CECDS:SprCreate|SprCreate]]
|-
| 0x040B....
| [[CECDS:SprInitialise|SprInitialise]]
|-
| 0x040C0042
| [[CECDS:SprGetSendSlotsMetadata|SprGetSendSlotsMetadata]]
|-
| 0x040D0082
| [[CECDS:SprGetSlot|SprGetSlot]] title_id, write_buffer, buffer_size
|-
| 0x040E....
| [[CECDS:SprSetTitleSent|SprSetTitleSent]] title_id, bool success
|-
| 0x040F....
| [[CECDS:SprFinaliseSend|SprFinaliseSend]]
|-
| 0x0410....
| [[CECDS:SprStartRecv|SprStartRecv]]
|-
| 0x04110042
| [[CECDS:SprSetRecvSlotsMetadata|SprSetRecvSlotsMetadata]]
|-
| 0x041200C2
| [[CECDS:SprAddSlot|SprAddSlot]]
|-
| 0x0413....
| [[CECDS:SprFinaliseRecv|SprFinaliseRecv]]
|-
| 0x0414....
| [[CECDS:SprDone|SprDone]] bool success
|-
| 0x04150000
| [[CECDS:GenHashConsoleUnique|GenHashConsoleUnique]]
|-
| 0x04160002
| ?
|-
| 0x0417....
| ?
|-
|}

=== CecSprStatus ===
This enum is used internally of the cecd service to keep track of which state of an SPR exchange it is in currently.

{| class="wikitable" border="1"
! Name
! Value
! Notes
|-
| CEC_SPR_SEND_RECV_START
| 0
| The internal objects were just created
|-
| CEC_SPR_SEND_RECV_INIT
| 1
| The internal objects for sending and receiving have been initialised
|-
| CEC_SPR_SEND_READY
| 2
| The sysmodule is ready for SPR Send, now it is possible to fetch the SPR data needed
|-
| CEC_SPR_SEND
| 3
| The other program should be sending the SPR request now
|-
| CEC_SPR_RECEIVE_READY
| 4
| The sysmodule is ready to receive SPR data now
|-
| CEC_SPR_RECEIVE
| 5
| The sysmodule is done receiving SPR data
|-
| CEC_SPR_CONNECTION_FINISHED_TCP
| 6
|
|-
| CEC_SPR_CONNECTION_FINISHED
| 7
| ??? Enum usage not found in source
|-
| CEC_SPR_SEND_POST
| 8
| ??? Enum usage not found in source
|-
| CEC_SPR_RECEIVE_POST
| 9
| ??? Enum usage not found in source
|-
| CEC_SPR_FINISHING
| 0x0F
| ??? Enum usage not found in source
|-
| CEC_SPR_FINISHED
| 0x10
| ??? Enum usage not found in source
|}

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

User:Sorunome

2025-02-10T09:44:36Z

Sorunome: Created page with "Fox. Creator of [https://netpass.cafe NetPass]."

Fox. Creator of [https://netpass.cafe NetPass].

MAC Address

2025-02-10T09:43:55Z

Sorunome: Add more mac prefixes from NetPass research

== List of known Nintendo MAC prefixes ==
[http://www.coffer.com/mac_find/?string=Nintendo Vendor/Ethernet/Bluetooth MAC Address Lookup and Search]

== List of known 3DS MAC prefixes ==
{| class="wikitable"
|-
! MAC prefix
! Found in model / version (region)
! Source
|-
| 04:03:D6
|
| [[User:Sorunome|Sorunome]]
|-
| 18:2A:7B
|
| [[User:Sorunome|Sorunome]]
|-
| 2C:10:C1
| O3DS / Red (U)
| [https://gbatemp.net/threads/device-mac-address-survey.365525/#post-4987679 GBAtemp]
|-
| 34:2F:BD
|
| [[User:Sorunome|Sorunome]]
|-
| 34:AF:2C
|
| [[User:Sorunome|Sorunome]]
|-
| 40:D2:8A
| N3DS XL / Black (U)
| [[User:Rubik|Rubik]]
|-
| 40:F4:07
|
| [[User:Sorunome|Sorunome]]
|-
| 48:A5:E7
|
| [[User:Sorunome|Sorunome]]
|-
| 58:2F:40
|
| [[User:Sorunome|Sorunome]]
|-
| 68:BD:13
|
| [[User:Sorunome|Sorunome]]
|-
| 58:BD:A3
| O3DS / Blue (U)
| [https://gbatemp.net/threads/device-mac-address-survey.365525/#post-4987679 GBAtemp]
|-
| 58:BD:A3
| O3DS / Zelda: OOT3D (E)
| [[User:EmuAGR|EmuAGR]]
|-
| 5C:52:1E
|
| [[User:Sorunome|Sorunome]]
|-
| 60:6B:FF
|
| [[User:Sorunome|Sorunome]]
|-
| 64:B5:C6
|
| [[User:Sorunome|Sorunome]]
|-
| 78:A2:A0
|
| [[User:Sorunome|Sorunome]]
|-
| 7C:BB:8A
|
| [[User:Sorunome|Sorunome]]
|-
| 8C:CD:E8
|
| [[User:Sorunome|Sorunome]]
|-
| 94:58:CB
|
| [[User:Sorunome|Sorunome]]
|-
| 98:41:5C
|
| [[User:Sorunome|Sorunome]]
|-
| 98:B6:E9
|
| [[User:Sorunome|Sorunome]]
|-
| 9C:E6:35
| O3DS XL (J)
| [https://gbatemp.net/threads/device-mac-address-survey.365525/#post-4987679 GBAtemp]
|-
| A4:38:CC
|
| [[User:Sorunome|Sorunome]]
|-
| A4:C0:E1
| O3DS / Blue (E)
| [[User:EmuAGR|EmuAGR]]
|-
| B8:78:26
|
| [[User:Sorunome|Sorunome]]
|-
| B8:8A:EC
|
| [[User:Sorunome|Sorunome]]
|-
| B8:AE:6E
| O3DS XL / Zelda: Link Between Worlds (U)
| [https://gbatemp.net/threads/device-mac-address-survey.365525/#post-4987679 GBAtemp]
|-
| CC:FB:65
| N3DS / White (E)
| [[User:EmuAGR|EmuAGR]]
|-
| CC:FB:65
| N3DS / White (E), launch day
| [[User:Ryccardo|Ryccardo]]
|-
| CC:FB:65
| N3DS XL / Zelda: Majora's Mask (E)
| [[User:EmuAGR|EmuAGR]]
|-
| D8:6B:F7
|
| [[User:Sorunome|Sorunome]]
|-
| DC:68:EB
|
| [[User:Sorunome|Sorunome]]
|-
| CC:9E:00
|
| [[User:Sorunome|Sorunome]]
|-
| E0:0C:7F
| O3DS / Zelda: OOT3D (E)
| [[User:EmuAGR|EmuAGR]]
|-
| E0:F6:B5
|
| [[User:Sorunome|Sorunome]]
|-
| EC:C4:0D
|
| [[User:Sorunome|Sorunome]]
|}

FS:OpenArchive

2025-01-16T07:44:05Z

Sorunome: Fix link

=Request=
{| class="wikitable" border="1"
|-
! Index Word
! Description
|-
| 0
| Header code [0x080C00C2]
|-
| 1
| [[Filesystem_services#Archives|Archive ID]]
|-
| 2
| [[Filesystem_services#PathType|Path Type]]
|-
| 3
| Path Size (including null-terminator)
|-
| 4
| (PathSize << 14) <nowiki>|</nowiki> 2
|-
| 5
| Path Data Pointer
|}

=Response=
{| class="wikitable" border="1"
|-
! Index Word
! Description
|-
| 0
| Header code
|-
| 1
| Result code
|-
| 2-3
| u64, Archive Handle
|}

News Services

2024-12-10T11:35:36Z

Sorunome: Add missing category

This system module handles the system notifications.

The maximum number of notifications that can be stored/handled is 100, hence the intended range for notificationIDs is 0-99.

=News service <nowiki>"news:u"</nowiki>=
{| class="wikitable" border="1"
|-
! Command Header
! Description
|-
| 0x000100C8
| [[NEWSU:AddNotification|AddNotification]]
|}

This service only has ''one'' command.

=News service <nowiki>"news:s"</nowiki>=
{| class="wikitable" border="1"
|-
! Command Header
! Description
|-
| 0x000100C6
| [[NEWSS:AddNotification|AddNotification]]
|-
| 0x0002....
| Stubbed, only returns 0.
|-
| 0x0003....
| Stubbed, only returns 0.
|-
| 0x00040000
| [[NEWSS:ResetNotifications|ResetNotifications]]
|-
| 0x00050000
| [[NEWSS:GetTotalNotifications|GetTotalNotifications]]
|-
| 0x00060042
| [[NEWSS:SetNewsDBHeader|SetNewsDBHeader]]
|-
| 0x00070082
| [[NEWSS:SetNotificationHeader|SetNotificationHeader]]
|-
| 0x00080082
| [[NEWSS:SetNotificationMessage|SetNotificationMessage]]
|-
| 0x00090082
| [[NEWSS:SetNotificationImage|SetNotificationImage]]
|-
| 0x000A0042
| [[NEWSS:GetNewsDBHeader|GetNewsDBHeader]]
|-
| 0x000B0082
| [[NEWSS:GetNotificationHeader|GetNotificationHeader]]
|-
| 0x000C0082
| [[NEWSS:GetNotificationMessage|GetNotificationMessage]]
|-
| 0x000D0082
| [[NEWSS:GetNotificationImage|GetNotificationImage]]
|-
| 0x000E0040
| [[NEWSS:SetInfoLEDPattern|SetInfoLEDPattern]]
|-
| 0x000F0000
| [[NEWSS:SyncArrivedNotifications|SyncArrivedNotifications]]
|-
| 0x00100040
| [[NEWSS:SyncOneArrivedNotification|SyncOneArrivedNotification]]
|-
| 0x00110040
| [[NEWSS:SetAutomaticSyncFlag|SetAutomaticSyncFlag]]
|-
| 0x00120082
| [[NEWSS:SetNotificationHeaderOther|SetNotificationHeaderOther]]
|-
| 0x00130000
| [[NEWSS:WriteNewsDBSavedata|WriteNewsDBSavedata]]
|-
| 0x00140000
| [[NEWSS:GetTotalArrivedNotifications|GetTotalArrivedNotifications]]
|}

=News module NAND [[System_SaveData|savedata]]=
* "news.db": This is the main save-file, the filesize is fixed to 0x2BD0-bytes.
* "newsXXX.txt" This is the [[NEWSS:AddNotification|message]] data for this notification, where XXX is the decimal notification-index in the below headers-array. The filesize should be <= <size listed [[NEWSS:GetNotificationMessage|here]]>, since that's the max size read by the notifications applet.
* "newsXXX.mpo" This is the [[NEWSS:AddNotification|MPO]] data for this notification if any, where XXX is the decimal notification-index in the below headers-array. The filesize should be <= <size listed [[NEWSS:GetNotificationImage|here]]>, since that's the max size read by the notifications applet.

==news.db==
{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
|-
| 0x0
| 0x10
| Header, see below.
|-
| 0x10
| 0x2BC0 (100 * 0x70)
| Array of [[NEWSS:AddNotification|headers]] for each notification.
|}

===Header===
{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
|-
| 0x0
| 0x1
| Must be 0x1 "is valid".
|-
| 0x1
| 0x1
| Flags
|-
| 0x2
| 0xE
| Normally zero?
|}

===Flags===

{| class="wikitable" border="1"
|-
! Bit
! Description
|-
| 0
| Set by news module when handling BOSS notifications and the AddNotification commands. This indicates that there's "unread" notifications, the notifications applet clears this once all notifications have been "read".
|-
| 1
| Set by news module when handling CECD notifications.
|}

=News module startup=
The actual main function called by main() does the following:
* srv_init()
* Registers services <nowiki>"news:u" and "news:s"</nowiki>.
* Initializes the service session handle for "ptm:sysm".
* Loads 4 handles from somewhere, which gets used with svcReplyAndReceive later.
* Does notificationID state init, uses [[SRV:GetNotificationSemaphore]], then subscribes to srv notifications 0x104 and 0x106.
* <Some func calls>
* Here [[PTMSYSM:SetInfoLEDPattern]] is used.
* Some state init is done, then the usual svcReplyAndReceive loop begins.

=Errors=
{| class="wikitable" border="1"
|-
! Error code
! Description
|-
| 0xC8A12805
| The news.db or notification header data for the specified notificationID is not set(the specified notification doesn't exist).
|}

=Title Versions=
{| class="wikitable" border="1"
|-
! Title version
! System version
! Changes
|-
| v7168
| [[9.7.0-25|9.7.0-X]]
| All of the changes are the following:
* See [[9.7.0-25|here]] regarding the updated CTRSDK function code.
* This function is eventually called by newss_cmdf, newss_cmd10, and <certain function>. When calling a certain function fails in here, this code now calls <another certain function> before returning.
* Mutex enter/leave function calls were added to a certain function.
* More state init was added to the start of an initialization function called during news module startup(crt0?).
* 0x14 new bytes were added to .rodata.
|}
[[Category:Services]]

ErrDisp

2024-12-09T21:42:37Z

Sorunome: Add missing category

This system process handles displaying the error screens, such as "an error has occurred, the system needs shutdown". This can also display a register dump for exceptions, and info for fatal errors. (Normally the black-screen errors are displayed on retail, while the latter is displayed on development units.)

The register dump/fatal error info can also be written to [[nandrw/sys/native.log]]. On retail consoles, the system does not notify ErrDisp that any user-land exceptions occurred, ErrDisp is only notified for this on dev/debug units. Therefore, on retail consoles native.log only contains info from fatal errors. Starting with [[5.0.0-11]] ErrDisp no longer writes logs to native.log, except when the error-type is value 5 and when other checks with the errorinfo structure are successful (normally processes using this port never use error-type 5).

The bottom screen displays the error screen like "error has occurred", even with a development 3DS. The top screen can display the development error info, this is only displayed when [[Configuration_Memory#ENVINFO|ENVINFO]] bit0 is clear, for a development 3DS.

ErrDisp handles "returning" to Home Menu via [[NSS:RebootSystem]], which triggers a hardware system reboot.

= ErrDisp error port "err:f" =
{| class="wikitable" border="1"
|-
! Command Header
! Description
|-
| 0x00010800
| [[ERR:Throw|Throw]]
|-
| 0x00020042
| [[ERR:SetUserString|SetUserString]]
|}
[[Category:Services]]

CECD Services

2024-12-05T14:45:32Z

Sorunome: add 0x40E name

[[Category:Services]]

Streetpass stuff.

= CECD Service "cecd:u" =
{| class="wikitable" border="1"
|-
! Command Header
! Description
|-
| 0x000100C2
| Open/[[CECDU:OpenRawFile|OpenRawFile]]
|-
| 0x00020042
| Read/[[CECDU:ReadRawFile|ReadRawFile]]
|-
| 0x00030104
| [[CECDU:ReadMessage|ReadMessage]]
|-
| 0x00040106
| [[CECDU:ReadMessageWithHMAC|ReadMessageWithHMAC]]
|-
| 0x00050042
| Write/[[CECDU:WriteRawFile|WriteRawFile]]
|-
| 0x00060104
| [[CECDU:WriteMessage|WriteMessage]]
|-
| 0x00070106
| [[CECDU:WriteMessageWithHMAC|WriteMessageWithHMAC]]
|-
| 0x00080102
| [[CECDU:Delete|Delete]]
|-
| 0x000900C2
| SetData (16*length+10 of CecMessageId buffer in cmdbuff[4] (always 16*8+10), CecMessageId* in cmdbuf[5])
|-
| 0x000A00C4
| ReadData/[[CECDU:GetSystemInfo|GetSystemInfo]]
|-
| 0x000B0040
| [[CECDU:Start|Start]]
|-
| 0x000C0040
| [[CECDU:Stop|Stop]]
|-
| 0x000D0082
| GetCecInfoBuffer
|-
| 0x000E0000
| GetCecdState (returns CecStateAbbreviated in cmdbuf[2])
|-
| 0x000F0000
| GetCecInfoEventHandle (returns event handle in cmdbuf[3])
|-
| 0x00100000
| GetChangeStateEventHandle (returns event handle in cmdbuf[3])
|-
| 0x00110104
| [[CECDU:OpenAndWrite|OpenAndWrite]]
|-
| 0x00120104
| [[CECDU:OpenAndRead|OpenAndRead]]
|-
| 0x001E0082
| [[CECDU:GetEventLog|GetEventLog]]
|-
| 0x001F0000
| [[CECDU:GetEventLogStart|GetEventLogStart]]
|-
| 0x00200000
| [[CECDU:GetEventLogEntryCount|GetEventLogEntryCount]]
|-
| 0x0021....
| ?
|-
|}

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

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

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

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

= CECD Service "cecd:s" =

This contains a similar (probably the same) command handler from 0x0001.... to 0x0021.... as them in cecd:u. In addition, it also contains
{| class="wikitable" border="1"
|-
! Command Header
! Description
|-
| 0x0401....
| ?
|-
| 0x04020002
| GetCecInfoEventHandleSys
|-
| 0x040A....
| SprCreate
|-
| 0x040B....
| SprInitialise
|-
| 0x040C0042
| SprGetSendSlotsMetadata
|-
| 0x040D0082
| SprGetSlot title_id, write_buffer, buffer_size
|-
| 0x040E....
| SprSetTitleSent title_id, bool success
|-
| 0x040F....
| SprFinaliseSend
|-
| 0x0410....
| SprStartRecv
|-
| 0x04110042
| SprAddSlotsMetadata
|-
| 0x041200C2
| SprAddSlot
|-
| 0x0413....
| SprFinaliseRecv
|-
| 0x0414....
| SprDone bool success
|-
| 0x04150000
| [[CECDS:GenHashConsoleUnique|GenHashConsoleUnique]]
|-
| 0x04160002
| ?
|-
| 0x0417....
| ?
|-
|}

=== CecSprStatus ===
This enum is used internally of the cecd service to keep track of which state of an SPR exchange it is in currently.

{| class="wikitable" border="1"
! Name
! Value
! Notes
|-
| CEC_SPR_SEND_RECV_START
| 0
| The internal objects were just created
|-
| CEC_SPR_SEND_RECV_INIT
| 1
| The internal objects for sending and receiving have been initialised
|-
| CEC_SPR_SEND_READY
| 2
| The sysmodule is ready for SPR Send, now it is possible to fetch the SPR data needed
|-
| CEC_SPR_SEND
| 3
| The other program should be sending the SPR request now
|-
| CEC_SPR_RECEIVE_READY
| 4
| The sysmodule is ready to receive SPR data now
|-
| CEC_SPR_RECEIVE
| 5
| The sysmodule is done receiving SPR data
|-
| CEC_SPR_CONNECTION_FINISHED_TCP
| 6
|
|-
| CEC_SPR_CONNECTION_FINISHED
| 7
| ??? Enum usage not found in source
|-
| CEC_SPR_SEND_POST
| 8
| ??? Enum usage not found in source
|-
| CEC_SPR_RECEIVE_POST
| 9
| ??? Enum usage not found in source
|-
| CEC_SPR_FINISHING
| 0x0F
| ??? Enum usage not found in source
|-
| CEC_SPR_FINISHED
| 0x10
| ??? Enum usage not found in source
|}

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

NDMU:LeaveExclusiveState

2024-12-02T12:34:07Z

Sorunome: specify where the magic number comes from

=Request=
{| class="wikitable" border="1"
|-
! Index Word
! Description
|-
| 0
| Header code [0x00020002]
|-
| 1
| 0x20 (process id)
|}

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

CECD Services

2024-12-02T11:36:49Z

Sorunome: fix typo

[[Category:Services]]

Streetpass stuff.

= CECD Service "cecd:u" =
{| class="wikitable" border="1"
|-
! Command Header
! Description
|-
| 0x000100C2
| Open/[[CECDU:OpenRawFile|OpenRawFile]]
|-
| 0x00020042
| Read/[[CECDU:ReadRawFile|ReadRawFile]]
|-
| 0x00030104
| [[CECDU:ReadMessage|ReadMessage]]
|-
| 0x00040106
| [[CECDU:ReadMessageWithHMAC|ReadMessageWithHMAC]]
|-
| 0x00050042
| Write/[[CECDU:WriteRawFile|WriteRawFile]]
|-
| 0x00060104
| [[CECDU:WriteMessage|WriteMessage]]
|-
| 0x00070106
| [[CECDU:WriteMessageWithHMAC|WriteMessageWithHMAC]]
|-
| 0x00080102
| [[CECDU:Delete|Delete]]
|-
| 0x000900C2
| SetData (16*length+10 of CecMessageId buffer in cmdbuff[4] (always 16*8+10), CecMessageId* in cmdbuf[5])
|-
| 0x000A00C4
| ReadData/[[CECDU:GetSystemInfo|GetSystemInfo]]
|-
| 0x000B0040
| [[CECDU:Start|Start]]
|-
| 0x000C0040
| [[CECDU:Stop|Stop]]
|-
| 0x000D0082
| GetCecInfoBuffer
|-
| 0x000E0000
| GetCecdState (returns CecStateAbbreviated in cmdbuf[2])
|-
| 0x000F0000
| GetCecInfoEventHandle (returns event handle in cmdbuf[3])
|-
| 0x00100000
| GetChangeStateEventHandle (returns event handle in cmdbuf[3])
|-
| 0x00110104
| [[CECDU:OpenAndWrite|OpenAndWrite]]
|-
| 0x00120104
| [[CECDU:OpenAndRead|OpenAndRead]]
|-
| 0x001E0082
| [[CECDU:GetEventLog|GetEventLog]]
|-
| 0x001F0000
| [[CECDU:GetEventLogStart|GetEventLogStart]]
|-
| 0x00200000
| [[CECDU:GetEventLogEntryCount|GetEventLogEntryCount]]
|-
| 0x0021....
| ?
|-
|}

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

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

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

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

= CECD Service "cecd:s" =

This contains a similar (probably the same) command handler from 0x0001.... to 0x0021.... as them in cecd:u. In addition, it also contains
{| class="wikitable" border="1"
|-
! Command Header
! Description
|-
| 0x0401....
| ?
|-
| 0x04020002
| GetCecInfoEventHandleSys
|-
| 0x040A....
| SprCreate
|-
| 0x040B....
| SprInitialise
|-
| 0x040C0042
| SprGetSendSlotsMetadata
|-
| 0x040D0082
| SprGetSlot title_id, write_buffer, buffer_size
|-
| 0x040E....
| ?
|-
| 0x040F....
| SprFinaliseSend
|-
| 0x0410....
| SprStartRecv
|-
| 0x04110042
| SprAddSlotsMetadata
|-
| 0x041200C2
| SprAddSlot
|-
| 0x0413....
| SprFinaliseRecv
|-
| 0x0414....
| SprDone bool success
|-
| 0x04150000
| [[CECDS:GenHashConsoleUnique|GenHashConsoleUnique]]
|-
| 0x04160002
| ?
|-
| 0x0417....
| ?
|-
|}

=== CecSprStatus ===
This enum is used internally of the cecd service to keep track of which state of an SPR exchange it is in currently.

{| class="wikitable" border="1"
! Name
! Value
! Notes
|-
| CEC_SPR_SEND_RECV_START
| 0
| The internal objects were just created
|-
| CEC_SPR_SEND_RECV_INIT
| 1
| The internal objects for sending and receiving have been initialised
|-
| CEC_SPR_SEND_READY
| 2
| The sysmodule is ready for SPR Send, now it is possible to fetch the SPR data needed
|-
| CEC_SPR_SEND
| 3
| The other program should be sending the SPR request now
|-
| CEC_SPR_RECEIVE_READY
| 4
| The sysmodule is ready to receive SPR data now
|-
| CEC_SPR_RECEIVE
| 5
| The sysmodule is done receiving SPR data
|-
| CEC_SPR_CONNECTION_FINISHED_TCP
| 6
|
|-
| CEC_SPR_CONNECTION_FINISHED
| 7
| ??? Enum usage not found in source
|-
| CEC_SPR_SEND_POST
| 8
| ??? Enum usage not found in source
|-
| CEC_SPR_RECEIVE_POST
| 9
| ??? Enum usage not found in source
|-
| CEC_SPR_FINISHING
| 0x0F
| ??? Enum usage not found in source
|-
| CEC_SPR_FINISHED
| 0x10
| ??? Enum usage not found in source
|}

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

StreetPass

2024-12-02T11:23:52Z

Sorunome: Fill in structs for streetpass messages

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

=== Send Mode ===
The 3DS can mark StreetPass data with one of 4 Send Modes
{| class="wikitable" border="1"
!ID!!Send Mode!!Description
|-
|0||EXCHANGE||StreetPass message exchange will only happen if both consoles can store the message of the other. E.g. the inbox isn't full. Example title: StreetPass Mii Plaza
|-
|1||RECV_ONLY||3DS doesn't have anything in its outbox so it is only receiving messages.
|-
|2||SEND_ONLY||
|-
|3||SEND_RECV||
|}

== 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 [[SpotPass#policylist]]. When connecting to a Nintendo Zone Hotspot the console will send an additional GET parameter named ''ap''. Adding the following priority to the policylist will instruct the console to upload its data (The level tag can probably be lower and must not be HIGH).
<pre>
<Priority>
<TitleId>0004013000003400</TitleId>
<TaskId>sprelay</TaskId>
<Level>HIGH</Level>
<Persistent>false</Persistent>
<Revive>false</Revive>
</Priority>
</pre>

===Request===
The following additional headers will be send in the request:
{| class=wikitable
|X-Boss-Apinfo||Access Point Info. The same number that is send with the policylist GET parameter ap. Probably identifies the SSID of connected Nintendo Zone Hotspot. If not connected to Nintendo Zone Hotspot this will be an empty string.||02012600000
|-
|X-Boss-Bssid||The MAC address of the access point the 3DS is connected to.||11:22:33:44:55:66
|-
|X-Boss-Country||2 letter country code of the set language.||ES
|-
|X-Boss-Region||3 letter region code of the 3DS' region.||EUR
|-
|X-Boss-Userid||A unique 16 character long hexadecimal string that represents a 64-bit integer. It is unknown how this number is generated.||6966442DE2EED063
|}

In the request body there will be a file named ''spr-meta'' and a file per registered StreetPass game ''spr-slotXX'' where XX is an incrementing number. If the game contains not messages in its outbox so the size of the file would be 0 then no file is created and sent but it will still be listed in the spr-meta file.

===spr-meta file===
The spr-meta file is a text file which may contain the following content.
<pre>
slotsize: 5
spr-slot01: 3,000EC400,10664
spr-slot02: 2,0007AD00,3648
spr-slot03: 3,00030000,3804
spr-slot04: 1,00051600,0
spr-slot05: 0,00020800,28228
</pre>
The comma seperated list after each spr-slotXX has the following meaning
{| class=wikitable
|Send Mode||StreetPass ID (Low title ID of the game. May be from a different region like japan.)||Size of the file in bytes
|}

===spr-slotXX files===
These are binary files. They begin a with a header with the follwing structure.
{| class=wikitable
!Offset!!Size!!Description
|-
|0x00||0x04||Magic number 0x00006161
|-
|0x04||0x04||Size of the file in bytes including this header
|-
|0x08||0x04||StreetPass ID (Low title ID of the game. May be from a different region like japan.)
|-
|0x0C||0x04||Unknown
|-
|0x10||0x04||Number of messages after this header
|}
After the header follows the StreetPass message exactly as it is stored in the outbox of [[CECD_Savegame#File_.3C12-char_ID.3E|CEC Save]].

===Response===
The following headers are expected:
{| class=wikitable
!Key!!colspan=3|Value!!Example
|-
|X-Spr-SlotXX-Result||StreetPass ID||Send Mode||Size of the file in bytes||X-Spr-Slot01-Result: 000EC400,3,17760
|}
It expects a header for every game it sent in the request.

The body is expected to contain binary data with the same structure as the spr-slotXX files in the request. The order of these must be the same as the reponse header order.

== Structs, Data Types ==
Streetpass uses multiple different structs and data types for storing and transporting data.

=== MessageId ===
This datatype holds a per-console-per-title unique message id.
{| class="wikitable" border="1"
! Type
! Description
|-
| u8[8]
| The message id
|}

=== Timestamp12 ===
This holds a timestamp in 12 bytes
{| class="wikitable" border="1"
! Offset
! Size
! Type
! Name
|-
| 0x0
| 0x4
| u32
| Year
|-
| 0x4
| 0x1
| u8
| Month
|-
| 0x5
| 0x1
| u8
| Day
|-
| 0x6
| 0x1
| u8
| Weekday
|-
| 0x7
| 0x1
| u8
| Hour
|-
| 0x8
| 0x1
| u8
| Minute
|-
| 0x9
| 0x1
| u8
| Second
|-
| 0xA
| 0x2
| u16
| Millisecond
|}

=== Message (0x6060) ===
MessageHeader:
{| class="wikitable" border="1"
! Offset
! Size
! Type
! Name
! Description
|-
| 0x00
| 0x2
| u16
| magic
| Equals 0x6060 (<code>``</code>)
|-
| 0x02
| 0x2
| u16
| Padding
|
|-
| 0x04
| 0x04
| u32
| message_size
| The size in bytes of the entire message, including all headers and hmac
|-
| 0x08
| 0x04
| u32
| total_header_size
| The size in bytes of all headers, including the extra headers
|-
| 0x0C
| 0x04
| u32
| body_size
| The size in bytes of the body of the message
|-
| 0x10
| 0x04
| u32
| title_id
| The title id of the message
|-
| 0x14
| 0x04
| u32
| title_id2
| ???
|-
| 0x18
| 0x04
| u32
| batch_id
| The sending client sets an ID here if multiple messages should be batched together into one transaction
|-
| 0x1C
| 0x04
| u32
| transfer_id
| ???
|-
| 0x20
| 0x08
| MessageId
| message_id
| The ID of the sending message
|-
| 0x28
| 0x04
| u32
| message_version
| ???
|-
| 0x2C
| 0x08
| MessageId
| message_id_2
| The message ID that this message is referring to, e.g. the individual responses in Streetpass Mii Plaza
|-
| 0x34
| 0x01
| u8
| flags
| ???
|-
| 0x35
| 0x01
| SendMethod
| send_method
|
|-
| 0x36
| 0x01
| bool
| unopened
| Set if the message hasn't been opened yet
|-
| 0x37
| 0x01
| bool
| is_new
| Set if the message is new
|-
| 0x38
| 0x08
| u64
| sender_id
|
|-
| 0x40
| 0x08
| u64
| sender_id_2
|
|-
| 0x48
| 0x0C
| Timestamp12
| sent
|
|-
| 0x54
| 0x0C
| Timestamp12
| received
|
|-
| 0x60
| 0x0C
| Timestamp12
| created
|
|-
| 0x6C
| 0x01
| u8
| send_count
| How often this message can be sent
|-
| 0x6D
| 0x01
| u8
| forward_count
| How often this message can be forwarded
|-
| 0x6E
| 0x02
| u16
| user_data
| ???
|}

ExtMessageHeader:
{| class="wikitable" border="1"
! Offset
! Size
! Type
! Name
! Description
|-
| 0x00
| 0x04
| u32
| type
| The type of the extra header
|-
| 0x04
| 0x04
| u32
| size
| Size, in bytes, of the extra header
|-
| 0x08
|
|
| body
| The body of the extra header
|}

Message:
{| class="wikitable" border="1"
! Offset
! Size
! Type
! Name
! Description
|-
| 0x00
| 0x70
| MessageHeader
| header
| The header of the message
|-
| 0x70
|
| ExtMessageHeader[]
| ext_headers
| An array of the extra headers for the message. The array keeps filling until the length no more until <code>header.total_header_size</code>
|-
|
|
|
| body
| The actual body/payload of the message
|-
|
| 0x20
| u8[0x20]
| hmac
| The hmac over the body with the hmac_key
|}

=== Slot (0x6161) ===
The slot groups multiple messages of one title id together into a single struct
{| class="wikitable" border="1"
! Offset
! Size
! Type
! Name
! Description
|-
| 0x00
| 0x02
| u16
| magic
| Equals 0x6161 (<code>aa</code>)
|-
| 0x02
| 0x02
| u16
| padding
|
|-
| 0x04
| 0x04
| u32
| size
| The size of bytes of the entire slot, including the header and all messages it contains
|-
| 0x08
| 0x04
| u32
| title_id
| The title id of the slot
|-
| 0x0C
| 0x04
| u32
| batch_id
| If the slot contains batched messages, the batch id is set to the same one as those messages
|-
| 0x10
| 0x04
| u32
| message_count
| The total number of messages in this slot
|-
| 0x14
|
| Message[]
| messages
| An array of length <code>message_count</code> all the messages of this slot
|}

=== BoxInfo (0x6262) ===
{| class="wikitable" border="1"
! Offset
! Size
! Type
! Name
! Description
|-
| 0x00
| 0x02
| u16
| magic
| Equals 0x6262 (<code>bb</code>)
|-
| 0x02
| 0x02
| u16
| padding
|
|-
| 0x04
| 0x04
| u32
| file_size
| The size of the box info in bytes
|-
| 0x08
| 0x04
| u32
| max_box_size
| The maximum allowed size of the box in bytes
|-
| 0x0C
| 0x04
| u32
| box_size
| The current size of the box in bytes
|-
| 0x10
| 0x04
| u32
| max_num_messages
| The maximum number of messages that the box can hold
|-
| 0x14
| 0x04
| u32
| num_messages
| The current number of messages in the box
|-
| 0x18
| 0x04
| u32
| max_batch_size
| The maximum size of a bach, in number of messages
|-
| 0x1C
| 0x04
| u32
| max_message_size
| The maximum size of a message, in bytes
|-
| 0x20
|
| MessageHeader[]
| message_headers
| An array of all message headers in this box of length <code>num_messages</code>
|}

=== MBoxInfo (0x6363) ===
This holds information on the message box, including both inbox and outbox
{| class="wikitable" border="1"
! Offset
! Size
! Type
! Name
! Description
|-
| 0x00
| 0x02
| u16
| magic
| Equals 0x6363 (<code>cc</code>)
|-
| 0x02
| 0x02
| u16
| padding
|
|-
| 0x04
| 0x04
| u32
| title_id
| The title id for this mbox
|-
| 0x08
| 0x04
| u32
| private_id
| ???
|-
| 0x0C
| 0x01
| u8
| mbox_type_flags
| 0x01: normal programs, 0x06: system programs, 0x80: silent notif
|-
| 0x0D
| 0x01
| bool
| enabled
| Weather this message box is enabled
|-
| 0x0E
| 0x02
| u16
| padding
|
|-
| 0x10
| 0x20
| u8[0x20]
| hmac_key
| The hmac key to make hmacs for messages. These are unique per title, however they are the same for all consoles.
|-
| 0x30
| 0x04
| u32
| padding
|
|-
| 0x34
| 0x0C
| Timestamp12
| last_accessed
|
|-
| 0x40
| 0x01
| bool
| flag_unread
| Does this message box contain unread messages?
|-
| 0x41
| 0x01
| bool
| flag_new
| Does this message box contain new messages?
|-
| 0x42
| 0x01
| bool
| flag_unknown
| ???
|-
| 0x43
| 0x01
| bool
| flag_unknown
| ???
|-
| 0x44
| 0x0C
| Timestamp12
| last_received
|
|-
| 0x50
| 0x04
| u32
| padding
|
|-
| 0x54
| 0x0C
| Timestamp12
| unknown_timestamp
| ???
|}

=== 0x6565 ===
SlotMetadata:
{| class="wikitable" border="1"
! Offset
! Size
! Type
! Name
! Description
|-
| 0x00
| 0x04
| u32
| title_id
| The title id of the slot
|-
| 0x04
| 0x04
| SendMethod
| send_method
| The send method for the slot
|-
| 0x08
| 0x04
| u32
| body_size
| The size of the slot body in bytes
|-
| 0x0C
| 0x04
| u32
| count
| Number of messages
|-
| 0x10
| 0x14
| '''unknown'''
| '''unknown'''
|
|}

Struct:
{| class="wikitable" border="1"
! Offset
! Length
! Type
! Name
! Description
|-
| 0x00
| 0x02
| u16
| magic
| Equals 0x6565 (<code>ee</code>)
|-
| 0x02
| 0x02
| u16
| padding
|
|-
| 0x04
| 0x28
| '''unknown'''
| '''unknown'''
|
|-
| 0x2C
| 0x360
| SlotMetadata[0x18]
| slots
| Metadata of all slots
|}

=== OBIndex (0x6767) ===
{| class="wikitable" border="1"
! Offset
! Size
! Type
! Name
! Description
|-
| 0x00
| 0x02
| u16
| magic
| Equals 0x6767 (<code>gg</code>)
|-
| 0x02
| 0x02
| u16
| padding
|
|-
| 0x04
| 0x04
| u32
| num_messages
| The number of messages in the outbox
|-
| 0x08
|
| MessageId[]
| message_ids
| An array of the message IDs in the outbox, of length <code>num_messages</code>
|}

=== MBoxList (0x6868) ===
{| class="wikitable" border="1"
! Offset
! Size
! Type
! Name
! Description
|-
| 0x00
| 0x02
| u16
| magic
| Equals 0x6868 (<code>hh</code>)
|-
| 0x02
| 0x02
| u16
| padding
|
|-
| 0x04
| 0x04
| u32
| version
|
|-
| 0x08
| 0x04
| u32
| num_boxes
| The number of boxes (= games with streetpass enabled)
|-
| 0x0C
| 0x180
| char[0x18][0x10]
| box_names
| A 0x18-long array of all the box names (= hex encoded title ids) of games with streetpass enabled
|}

[[Category:Nintendo Software]]

CECD Services

2024-12-02T10:09:25Z

Sorunome: Add information from reverse-engineering for NetPass

[[Category:Services]]

Streetpass stuff.

= CECD Service "cecd:u" =
{| class="wikitable" border="1"
|-
! Command Header
! Description
|-
| 0x000100C2
| Open/[[CECDU:OpenRawFile|OpenRawFile]]
|-
| 0x00020042
| Read/[[CECDU:ReadRawFile|ReadRawFile]]
|-
| 0x00030104
| [[CECDU:ReadMessage|ReadMessage]]
|-
| 0x00040106
| [[CECDU:ReadMessageWithHMAC|ReadMessageWithHMAC]]
|-
| 0x00050042
| Write/[[CECDU:WriteRawFile|WriteRawFile]]
|-
| 0x00060104
| [[CECDU:WriteMessage|WriteMessage]]
|-
| 0x00070106
| [[CECDU:WriteMessageWithHMAC|WriteMessageWithHMAC]]
|-
| 0x00080102
| [[CECDU:Delete|Delete]]
|-
| 0x000900C2
| SetData (16*length+10 of CecMessageId buffer in cmdbuff[4] (always 16*8+10), CecMessageId* in cmdbuf[5])
|-
| 0x000A00C4
| ReadData/[[CECDU:GetSystemInfo|GetSystemInfo]]
|-
| 0x000B0040
| [[CECDU:Start|Start]]
|-
| 0x000C0040
| [[CECDU:Stop|Stop]]
|-
| 0x000D0082
| GetCecInfoBuffer
|-
| 0x000E0000
| GetCecdState (returns CecStateAbbreviated in cmdbuf[2])
|-
| 0x000F0000
| GetCecInfoEventHandle (returns event handle in cmdbuf[3])
|-
| 0x00100000
| GetChangeStateEventHandle (returns event handle in cmdbuf[3])
|-
| 0x00110104
| [[CECDU:OpenAndWrite|OpenAndWrite]]
|-
| 0x00120104
| [[CECDU:OpenAndRead|OpenAndRead]]
|-
| 0x001E0082
| [[CECDU:GetEventLog|GetEventLog]]
|-
| 0x001F0000
| [[CECDU:GetEventLogStart|GetEventLogStart]]
|-
| 0x00200000
| [[CECDU:GetEventLogEntryCount|GetEventLogEntryCount]]
|-
| 0x0021....
| ?
|-
|}

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

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

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

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

= CECD Service "cecd:s" =

This contains a similar (probably the same) command handler from 0x0001.... to 0x0021.... as them in cecd:u. In addition, it also contains
{| class="wikitable" border="1"
|-
! Command Header
! Description
|-
| 0x0401....
| ?
|-
| 0x04020002
| GetCecInfoEventHandleSys
|-
| 0x040A....
| SprCreate
|-
| 0x040B....
| SprInitialise
|-
| 0x040C0042
| SprGetSendSlotsMetadata
|-
| 0x040D0082
| SprGetSlot title_id, write_buffer, buffer_size
|-
| 0x040E....
| ?
|-
| 0x040F....
| SprFinaliseSend
|-
| 0x0410....
| SprStartRecv
|-
| 0x04110042
| SprAddSlotsMetadata
|-
| 0x041200C2
| SprbAddSlot
|-
| 0x0413....
| SprFinaliseRecv
|-
| 0x0414....
| SprDone bool success
|-
| 0x04150000
| [[CECDS:GenHashConsoleUnique|GenHashConsoleUnique]]
|-
| 0x04160002
| ?
|-
| 0x0417....
| ?
|-
|}

=== CecSprStatus ===
This enum is used internally of the cecd service to keep track of which state of an SPR exchange it is in currently.

{| class="wikitable" border="1"
! Name
! Value
! Notes
|-
| CEC_SPR_SEND_RECV_START
| 0
| The internal objects were just created
|-
| CEC_SPR_SEND_RECV_INIT
| 1
| The internal objects for sending and receiving have been initialised
|-
| CEC_SPR_SEND_READY
| 2
| The sysmodule is ready for SPR Send, now it is possible to fetch the SPR data needed
|-
| CEC_SPR_SEND
| 3
| The other program should be sending the SPR request now
|-
| CEC_SPR_RECEIVE_READY
| 4
| The sysmodule is ready to receive SPR data now
|-
| CEC_SPR_RECEIVE
| 5
| The sysmodule is done receiving SPR data
|-
| CEC_SPR_CONNECTION_FINISHED_TCP
| 6
|
|-
| CEC_SPR_CONNECTION_FINISHED
| 7
| ??? Enum usage not found in source
|-
| CEC_SPR_SEND_POST
| 8
| ??? Enum usage not found in source
|-
| CEC_SPR_RECEIVE_POST
| 9
| ??? Enum usage not found in source
|-
| CEC_SPR_FINISHING
| 0x0F
| ??? Enum usage not found in source
|-
| CEC_SPR_FINISHED
| 0x10
| ??? Enum usage not found in source
|}

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

IPC

2024-12-01T20:07:23Z

Sorunome: /* Buffer Mapping Translation */ correct incorrect statement

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). Some calls like [[CECDU:WriteMessageWithHMAC]] use it, however it is unsure as to why. 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.<sup>TODO: Are only port/session handles supported?</sup>
<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.<sup>TODO: It doesn't seem like the 0xFFFF0000 command id mentioned in the above sections is necessary, but needs confirmation.</sup>

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
}

CECDS:GenHashConsoleUnique

2024-11-29T13:33:55Z

Sorunome: Create endpoint descsription, form research for NetPass

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

= Response =
{| class="wikitable" border="1"
|-
! Index Word
! Description
|-
| 0
| Header code
|-
| 1
| Result code
|-
| 2-3
| 64-bit hash
|-
|}

= Description =
This internally calls [[Cfg:GenHashConsoleUnique]] with a salt of 0

CECD Services

2024-11-29T13:32:51Z

Sorunome: Add more endpoints, result of NetPass research

[[Category:Services]]

Streetpass stuff.

= CECD Service "cecd:u" =
{| class="wikitable" border="1"
|-
! Command Header
! Description
|-
| 0x000100C2
| Open/[[CECDU:OpenRawFile|OpenRawFile]]
|-
| 0x00020042
| Read/[[CECDU:ReadRawFile|ReadRawFile]]
|-
| 0x00030104
| [[CECDU:ReadMessage|ReadMessage]]
|-
| 0x00040106
| [[CECDU:ReadMessageWithHMAC|ReadMessageWithHMAC]]
|-
| 0x00050042
| Write/[[CECDU:WriteRawFile|WriteRawFile]]
|-
| 0x00060104
| [[CECDU:WriteMessage|WriteMessage]]
|-
| 0x00070106
| [[CECDU:WriteMessageWithHMAC|WriteMessageWithHMAC]]
|-
| 0x00080102
| [[CECDU:Delete|Delete]]
|-
| 0x000900C2
| SetData (16*length+10 of CecMessageId buffer in cmdbuff[4] (always 16*8+10), CecMessageId* in cmdbuf[5])
|-
| 0x000A00C4
| ReadData/[[CECDU:GetSystemInfo|GetSystemInfo]]
|-
| 0x000B0040
| [[CECDU:Start|Start]]
|-
| 0x000C0040
| [[CECDU:Stop|Stop]]
|-
| 0x000D0082
| GetCecInfoBuffer
|-
| 0x000E0000
| GetCecdState (returns CecStateAbbreviated in cmdbuf[2])
|-
| 0x000F0000
| GetCecInfoEventHandle (returns event handle in cmdbuf[3])
|-
| 0x00100000
| GetChangeStateEventHandle (returns event handle in cmdbuf[3])
|-
| 0x00110104
| [[CECDU:OpenAndWrite|OpenAndWrite]]
|-
| 0x00120104
| [[CECDU:OpenAndRead|OpenAndRead]]
|-
| 0x001E0082
| [[CECDU:GetEventLog|GetEventLog]]
|-
| 0x001F0000
| [[CECDU:GetEventLogStart|GetEventLogStart]]
|-
| 0x00200000
| [[CECDU:GetEventLogEntryCount|GetEventLogEntryCount]]
|-
| 0x0021....
| ?
|-
|}

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

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

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

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

= CECD Service "cecd:s" =

This contains a similar (probably the same) command handler from 0x0001.... to 0x0021.... as them in cecd:u. In addition, it also contains
{| class="wikitable" border="1"
|-
! Command Header
! Description
|-
| 0x0401....
| ?
|-
| 0x04020002
| GetCecInfoEventHandleSys
|-
| 0x040A....
| ?
|-
| 0x040B....
| ?
|-
| 0x040C0042
| GetSendSlotsMetadata?
|-
| 0x040D0082
| GetSlot? title_id, write_buffer, buffer_size
|-
| 0x040E....
| ?
|-
| 0x040F....
| ?
|-
| 0x0410....
| ?
|-
| 0x04110042
| ?
|-
| 0x041200C2
| AddSlot?
|-
| 0x0413....
| ?
|-
| 0x0414....
| CloseSpr? bool success
|-
| 0x04150000
| [[CECDS:GenHashConsoleUnique|GenHashConsoleUnique]]
|-
| 0x04160002
| ?
|-
| 0x0417....
| ?
|-
|}

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

BOSSU:UnregisterTask

2024-11-01T08:52:26Z

Sorunome: /* Request */

=Request=
{| class="wikitable" border="1"
|-
! Index Word
! Description
|-
| 0
| Header code [0x000C0082]
|-
| 1
| TaskID buffer size
|-
| 2
| ? (Probably step_id?)
|-
| 3
| (Size << 4) <nowiki>|</nowiki> 0xA
|-
| 4
| TaskID data pointer
|}

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

Services

2024-10-29T21:39:13Z

Sorunome: Add missing category

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

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

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

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

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

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

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

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

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

PTM Services

2024-10-29T20:51:54Z

Sorunome: Add missing category

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

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

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

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

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

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

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

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

=PTM [[System_SaveData]]=
''Main article: [[PTM Savegame]]''

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

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

[[Category:Services]]