StreetPass: Difference between revisions

(3 intermediate revisions by the same user not shown)

Line 134:

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.

Bits n°5 and n°6 encode the send method of the service:

{| class="wikitable" border="1"

!ID!!Send Mode!!Description

|-

|0b00||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

|-

|0b01||RECV_ONLY||3DS is only receiving messages. Some services mark their messages with this send mode (e.g. 000AF700)

|-

|0b10||SEND_ONLY||3DS inbox is full so it is only sending messages.

|-

|0b11||SEND_RECV||The 3DS can send and receive messages of this service

|}

When set, the bit n°2 indicates the presence of a following 6-byte field filled with 0xff. 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.

Line 420:

Line 433:

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

=== Encrypted conversation ===

~~The 3DS can mark StreetPass data with one of 4 Send Modes~~

~~{| class="wikitable" border="1"~~

After the handshake is done, both 3DS start having an encrypted conversation. Its format and protocols can be seen at [[SPTCP]] and [[SPMTP]].

~~!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||3DS inbox is full so it is only sending messages~~.

|-

~~|3||SEND_RECV||~~

|}

== StreetPass Spoofing ==

@@ Line 134: / Line 134: @@
 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.
+Bits n°5 and n°6 encode the send method of the service:
+{| class="wikitable" border="1"
+!ID!!Send Mode!!Description
+|-
+|0b00||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
+|-
+|0b01||RECV_ONLY||3DS is only receiving messages. Some services mark their messages with this send mode (e.g. 000AF700)
+|-
+|0b10||SEND_ONLY||3DS inbox is full so it is only sending messages.
+|-
+|0b11||SEND_RECV||The 3DS can send and receive messages of this service
+|}
+When set, the bit n°2 indicates the presence of a following 6-byte field filled with 0xff. 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.
@@ Line 420: / Line 433: @@
 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 ===
+=== Encrypted conversation ===
-The 3DS can mark StreetPass data with one of 4 Send Modes
-{| class="wikitable" border="1"
+After the handshake is done, both 3DS start having an encrypted conversation. Its format and protocols can be seen at [[SPTCP]] and [[SPMTP]].
-!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||3DS inbox is full so it is only sending messages.
-|-
-|3||SEND_RECV||
-|}
 == StreetPass Spoofing ==