StreetPass - Revision history

Katanya04: That is incorrect, if the outbox is empty, the 3DS does not announce the title in the probe request. Furthermore, the send method is specified on the message, not on the box info. So for a 3ds to say it has a title in RECV_ONLY, it has to have a message in its outbox with that mode.

2026-04-26T15:51:10Z

That is incorrect, if the outbox is empty, the 3DS does not announce the title in the probe request. Furthermore, the send method is specified on the message, not on the box info. So for a 3ds to say it has a title in RECV_ONLY, it has to have a message in its outbox with that mode.

← Older revision		Revision as of 19:51, 26 April 2026
Line 427:		Line 427:
	\|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		\|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.		\|1\|\|RECV_ONLY\|\|3DS is only receiving messages. Some titles mark their messages with this send mode (e.g. 000AF700)
	\|-		\|-
	\|2\|\|SEND_ONLY\|\|3DS inbox is full so it is only sending messages.		\|2\|\|SEND_ONLY\|\|3DS inbox is full so it is only sending messages.

Katanya04: I added the meaning of some fields of the probe request/response that were still "unknown" (it's a Type-length-value structure). I also added that the SEND_ONLY mode is used when the inbox is full. Although it may be used in other cases too?

2026-04-16T23:08:42Z

I added the meaning of some fields of the probe request/response that were still "unknown" (it's a Type-length-value structure). I also added that the SEND_ONLY mode is used when the inbox is full. Although it may be used in other cases too?

← Older revision		Revision as of 03:08, 17 April 2026
Line 56:		Line 56:
	==== Nintendo Tag Format ====		==== 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.		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. It seems to follow a "Type–length–value" structure.

	{\| class="wikitable" border="1"		{\| class="wikitable" border="1"
Line 68:		Line 68:
	\| 0x00		\| 0x00
	\| 0x01		\| 0x01
	\| '''~~Protocol Identification~~'''		\| '''StreetPass Service Tag'''
	\| ~~May be for protocol identification~~. All captures thus far show this value at 17, hexadecimal 11.		\| The identifier of the StreetPass Service. All captures thus far show this value at 17, hexadecimal 11.
	\| 11		\| 11
	\|-		\|-
Line 84:		Line 84:
	\| 00 02 08 00 00		\| 00 02 08 00 00
	\|-		\|-
	\| ~~varies~~		\| -0x10
	\| ~~0x02~~		\| 0x1
	\| '''~~Unknown~~'''		\| '''StreetPass consoleID Tag'''
	\| 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~~.		\| The identifier of the StreetPass consoleID, it is always the same value.
	\| f0 08		\| f0
			\|-
			\| -0x09
			\| 0x01
			\| '''StreetPass consoleID Length'''
			\| The length of the StreetPass consoleID field, which is also always the same value.
			\| 08
	\|-		\|-
	\| -0x08		\| -0x08
Line 97:		Line 103:
	\|}		\|}

	===== ~~Protocol Version~~ =====		===== StreetPass Service Tag =====

	~~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~~.		This field indicates that the following data is of type StreetPass services. It is the same across all devices.

	===== StreetPass Service Length =====		===== StreetPass Service Length =====
Line 390:		Line 396:
	\|}		\|}

	===== ~~Unknown 2-byte Field~~ =====		===== StreetPass consoleID Tag =====

			It has remained the same across all devices thus far, '''f0'''. It identifies the StreetPass consoleID field.

			===== StreetPass consoleID Length =====

	~~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~~'''.		Since the StreetPass consoleID length is always 0x08, this field is always '''08'''.

	===== StreetPass consoleID =====		===== StreetPass consoleID =====
Line 419:		Line 429:
	\|1\|\|RECV_ONLY\|\|3DS doesn't have anything in its outbox so it is only receiving messages.		\|1\|\|RECV_ONLY\|\|3DS doesn't have anything in its outbox so it is only receiving messages.
	\|-		\|-
	\|2\|\|SEND_ONLY\|\|		\|2\|\|SEND_ONLY\|\|3DS inbox is full so it is only sending messages.
	\|-		\|-
	\|3\|\|SEND_RECV\|\|		\|3\|\|SEND_RECV\|\|

Restonic4: typo

2025-05-12T09:19:01Z

typo

← Older revision		Revision as of 13:19, 12 May 2025
Line 113:		Line 113:
	Sims 3: 00 03 65 00 30		Sims 3: 00 03 65 00 30
	Street Fighter: 00 03 05 00 02 (FF FF FF FF FF FF)		Street Fighter: 00 03 05 00 02 (FF FF FF FF FF FF)
	Tomodachi life: 00 08 C5 00 30 (EUR region)		Tomodachi life: 00 08 C5 00 30 (Tested on EUR region)
	Animal crossing new leaf: 00 19 8D 00 (EUR region)		Animal crossing new leaf: 00 19 8D 00 30 (Tested on EUR region)

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

Restonic4 at 11:17, 12 May 2025

2025-05-12T09:17:02Z

← Older revision		Revision as of 13:17, 12 May 2025
Line 113:		Line 113:
	Sims 3: 00 03 65 00 30		Sims 3: 00 03 65 00 30
	Street Fighter: 00 03 05 00 02 (FF FF FF FF FF FF)		Street Fighter: 00 03 05 00 02 (FF FF FF FF FF FF)
			Tomodachi life: 00 08 C5 00 30 (EUR region)
			Animal crossing new leaf: 00 19 8D 00 (EUR region)

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

Sorunome: /* StreetPass Services */ fix typo

2025-03-17T11:39:13Z

StreetPass Services: fix typo

← Older revision		Revision as of 14:39, 17 March 2025
Line 126:		Line 126:

	Only the bits 2,5,6 were used.		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.		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.		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.

Sorunome: /* Message (0x6060) */

2025-03-17T11:16:26Z

Message (0x6060)

← Older revision		Revision as of 14:16, 17 March 2025
Line 623:		Line 623:
	\| u32		\| u32
	\| transfer_id		\| transfer_id
	\| ~~???~~		\| All messages from the same transfer (That is, sending the messages) contain the same transfer id
	\|-		\|-
	\| 0x20		\| 0x20
Line 646:		Line 646:
	\| 0x01		\| 0x01
	\| u8		\| u8
	\| ~~flags~~		\| recipients
	\| ~~???~~		\| bitfield: 0x01: everyone; 0x02: friends
	\|-		\|-
	\| 0x35		\| 0x35

Sorunome: Fill in structs for streetpass messages

2024-12-02T11:23:52Z

Fill in structs for streetpass messages

Show changes

Meleemeister: /* StreetPass Relay */

2024-06-08T17:44:57Z

StreetPass Relay

← Older revision		Revision as of 21:44, 8 June 2024
Line 441:		Line 441:
	</pre>		</pre>

			===Request===
	The following additional headers will be send in the request:		The following additional headers will be send in the request:
	{\| class=wikitable		{\| class=wikitable
Line 482:		Line 483:
	\|0x08\|\|0x04\|\|StreetPass ID (Low title ID of the game. May be from a different region like japan.)		\|0x08\|\|0x04\|\|StreetPass ID (Low title ID of the game. May be from a different region like japan.)
	\|-		\|-
	\|0x0C\|\|0x04\|\|Unknown~~. Maybe some version field. Always 0x00000001~~		\|0x0C\|\|0x04\|\|Unknown
	\|-		\|-
	\|0x10\|\|0x04\|\|Number of messages after this header		\|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.


	[[Category:Nintendo Software]]		[[Category:Nintendo Software]]

Meleemeister: /* StreetPass Exchange */

2024-06-07T19:14:13Z

StreetPass Exchange

← Older revision		Revision as of 23:14, 7 June 2024
Line 407:		Line 407:

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

Meleemeister: /* StreetPass Relay */

2024-06-07T19:00:17Z

StreetPass Relay

← Older revision		Revision as of 23:00, 7 June 2024
Line 426:		Line 426:
	</Priority>		</Priority>
	</pre>		</pre>

			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.		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.
Line 441:		Line 454:
	The comma seperated list after each spr-slotXX has the following meaning		The comma seperated list after each spr-slotXX has the following meaning
	{\| class=wikitable		{\| class=wikitable
	\|~~unknown~~\|\|StreetPass ID (Low title ID of the game. May be from a different region like japan.)\|\|Size of the file in bytes		\|Send Mode\|\|StreetPass ID (Low title ID of the game. May be from a different region like japan.)\|\|Size of the file in bytes
	\|}		\|}