3dbrew - User contributions [en]

https://www.3dbrew.org/w/api.php?action=feedcontributions&feedformat=atom&user=Seabrook 3dbrew - User contributions [en] 2026-04-14T23:32:26Z User contributions MediaWiki 1.43.1 https://www.3dbrew.org/w/index.php?title=StreetPass&diff=823 StreetPass 2011-06-17T01:31:36Z

<p>Seabrook: StreetPass ID may be used as part of the key generation for the encryption exchange.</p> <hr /> <div>'''StreetPass''' is a feature that allow your 3DS to connect with other 3DS using WiFi in standby mode.<br /> It can be used to share Mii(s) on Mii Plaza for example. Games' StreetPass data is stored on [[SD_Filesystem|SD card]] under [[extdata]], while Mii Plaza StreetPass data is stored on NAND. Not all StreetPass data is stored on SD card: "StreetPass Management" can still be used without a SD card inserted. Wifi infrastructure with APs are used to communicate, like WMB and multi-player.<br /> StreetPass in sleepmode can work without SD card inserted. Games' Streetpass data are temporarily stored in NAND, and when the games process the StreetPass data they move that data to extdata on SD card.<br /> <br /> == WiFi Probe Request Frame ==<br /> <br /> 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.<br /> <br /> The MAC address used for these probes is the static MAC address found in the 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.<br /> <br /> == StreetPass Exchange ==<br /> <br /> 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. <br /> <br /> The MAC address used in sleepmode seems to change every time there's a StreetPass hit, as well as the last 8-bytes of the Nintendo tag data. The MAC address + 8-byte ID for StreetPass 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 sleepmode, usually do StreetPass every <12 hours?<br /> <br /> When in standby mode the old DS WiFi is used, which includes SpotPass and StreetPass, but in "active" mode the regular DSi WiFi bus is used.<br /> <br /> === Probe Request Frame ===<br /> <br /> 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.<br /> <br /> 0000 00 00 1a 00 2f 48 00 00 19 7d 19 de 2a 00 00 00 ..../H...}..*...<br /> 0010 12 16 9e 09 a0 00 c9 02 00 00 40 00 00 00 ff ff ..........@.....<br /> 0020 ff ff ff ff da 6b f7 22 f3 77 ff ff ff ff ff ff .....k.".w......<br /> 0030 40 77 00 20 4e 69 6e 74 65 6e 64 6f 5f 33 44 53 @w. Nintendo_3DS<br /> 0040 5f 63 6f 6e 74 69 6e 75 6f 75 73 5f 73 63 61 6e _continuous_scan<br /> 0050 5f 30 30 30 01 08 82 84 8b 0c 12 96 18 24 32 04 _000.........$2.<br /> 0060 30 48 60 6c dd 15 00 1f 32 01 11 05 00 02 08 00 0H`l....2.......<br /> 0070 00 f0 08 c8 34 6e 05 0f c9 c6 80 5b 6f bc 5a ....4n.....[o.Z<br /> <br /> ==== Nintendo Tag Format ====<br /> <br /> 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.<br /> <br /> {| class="wikitable" border="1"<br /> |-<br /> ! Offset<br /> ! Length<br /> ! Purpose<br /> ! Description<br /> ! Example<br /> |-<br /> | 0x00<br /> | 0x01<br /> | '''Protocol Identification'''<br /> | May be for protocol identification. All captures thus far show this value at 17, hexadecimal 11.<br /> | 11<br /> |-<br /> | 0x01<br /> | 0x01<br /> | '''StreetPass Service Length'''<br /> | Length in bytes of only the StreetPass Services field.<br /> | 05<br /> |-<br /> | 0x02<br /> | 0x05<br /> | '''StreetPass Services'''<br /> | 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.<br /> | 00 02 08 00 00<br /> |-<br /> | varies<br /> | 0x02<br /> | '''Unknown'''<br /> | 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.<br /> | f0 08<br /> |-<br /> | -0x08<br /> | 0x08<br /> | '''StreetPass ID'''<br /> | 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?<br /> | 0f c9 c6 80 5b 6f bc 5a<br /> |}<br /> <br /> Of note, there is a 4 byte sequence unaccounted for prior to the StreetPass ID and after the currently unknown field. These four bytes may be part of the StreetPass ID, although captures of other 3DS units show the StreetPass ID at a fixed 8-byte value, and not 12-bytes as shown in the example above.<br /> <br /> ===== Protocol Version =====<br /> <br /> 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.<br /> <br /> ===== StreetPass Service Length =====<br /> <br /> 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.<br /> <br /> ===== StreetPass Services =====<br /> <br /> 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:<br /> <br /> Mii Plaza: 00 02 08 00 00<br /> Ridge Racer: 00 03 58 00 30<br /> Sims 3: 00 03 65 00 30<br /> Street Fighter: 00 03 05 00 02 (FF FF FF FF FF FF)<br /> <br /> Some services have a 6-byte field preceding or 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.<br /> <br /> ===== Unknown 2-byte Field =====<br /> <br /> 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'''.<br /> <br /> ===== StreetPass ID =====<br /> <br /> When there's a StreetPass hit, and no StreetPass data changed on either of the 3DSes, no data is transferred besides probes? Perhaps there's some ID in the Nintendo tag that gets updated every-time the 3DS' StreetPass data changes? 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) the 8bytes in the Nintendo tag changes?<br /> <br /> The value in this field may be used as part of the key generation for the upcoming encrypted exchange. Not much additional information outside of what is in this tag is exchanged between the two 3DS systems before the encrypted session begins.<br /> <br /> === Initial Probe Response Frame ===<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> The StreetPass Probe Response frame contains the same Nintendo tag in Probe Requests of the device that is transmitting the Probe Response frame.<br /> <br /> === Subsequent Probe Request and Response Frames ===<br /> <br /> 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.<br /> <br /> == StreetPass Spoofing ==<br /> <br /> A streetpass "AP" was spoofed on a laptop with hostapd by setting the SSID to "Nintendo_3DS_continuous_scan_000", with the extra Nintendo tag from another 3DS' probe request. The SSID and AP can't be easily spoofed with hostapd for streetpass when 3DS is "active", for the random "ic[kSvm9s@*cYD>/~IEVj\(fGG;qDo8j" strings. The 3DS didn't seem to authenticate or associate with the "AP". Streetpass "AP" comms use '''WPA2''' encryption. Eventually the 3DS stops communicating with the fake "AP" since the AP doesn't understand the sent data,(especially since it's encrypted) and 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)<br /> Communication with two 3DSes are the same as above except there's encrypted data sent to/from both consoles, unlike the fake "AP".<br /> <br /> [[Category:Nintendo Software]]</div>

Seabrook https://www.3dbrew.org/w/index.php?title=StreetPass&diff=822 StreetPass 2011-06-17T01:13:45Z

<p>Seabrook: Adding the last bit of undocumented information in the Nintendo tag format section</p> <hr /> <div>'''StreetPass''' is a feature that allow your 3DS to connect with other 3DS using WiFi in standby mode.<br /> It can be used to share Mii(s) on Mii Plaza for example. Games' StreetPass data is stored on [[SD_Filesystem|SD card]] under [[extdata]], while Mii Plaza StreetPass data is stored on NAND. Not all StreetPass data is stored on SD card: "StreetPass Management" can still be used without a SD card inserted. Wifi infrastructure with APs are used to communicate, like WMB and multi-player.<br /> StreetPass in sleepmode can work without SD card inserted. Games' Streetpass data are temporarily stored in NAND, and when the games process the StreetPass data they move that data to extdata on SD card.<br /> <br /> == WiFi Probe Request Frame ==<br /> <br /> 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.<br /> <br /> The MAC address used for these probes is the static MAC address found in the 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.<br /> <br /> == StreetPass Exchange ==<br /> <br /> 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. <br /> <br /> The MAC address used in sleepmode seems to change every time there's a StreetPass hit, as well as the last 8-bytes of the Nintendo tag data. The MAC address + 8-byte ID for StreetPass 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 sleepmode, usually do StreetPass every <12 hours?<br /> <br /> When in standby mode the old DS WiFi is used, which includes SpotPass and StreetPass, but in "active" mode the regular DSi WiFi bus is used.<br /> <br /> === Probe Request Frame ===<br /> <br /> 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.<br /> <br /> 0000 00 00 1a 00 2f 48 00 00 19 7d 19 de 2a 00 00 00 ..../H...}..*...<br /> 0010 12 16 9e 09 a0 00 c9 02 00 00 40 00 00 00 ff ff ..........@.....<br /> 0020 ff ff ff ff da 6b f7 22 f3 77 ff ff ff ff ff ff .....k.".w......<br /> 0030 40 77 00 20 4e 69 6e 74 65 6e 64 6f 5f 33 44 53 @w. Nintendo_3DS<br /> 0040 5f 63 6f 6e 74 69 6e 75 6f 75 73 5f 73 63 61 6e _continuous_scan<br /> 0050 5f 30 30 30 01 08 82 84 8b 0c 12 96 18 24 32 04 _000.........$2.<br /> 0060 30 48 60 6c dd 15 00 1f 32 01 11 05 00 02 08 00 0H`l....2.......<br /> 0070 00 f0 08 c8 34 6e 05 0f c9 c6 80 5b 6f bc 5a ....4n.....[o.Z<br /> <br /> ==== Nintendo Tag Format ====<br /> <br /> 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.<br /> <br /> {| class="wikitable" border="1"<br /> |-<br /> ! Offset<br /> ! Length<br /> ! Purpose<br /> ! Description<br /> ! Example<br /> |-<br /> | 0x00<br /> | 0x01<br /> | '''Protocol Identification'''<br /> | May be for protocol identification. All captures thus far show this value at 17, hexadecimal 11.<br /> | 11<br /> |-<br /> | 0x01<br /> | 0x01<br /> | '''StreetPass Service Length'''<br /> | Length in bytes of only the StreetPass Services field.<br /> | 05<br /> |-<br /> | 0x02<br /> | 0x05<br /> | '''StreetPass Services'''<br /> | 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.<br /> | 00 02 08 00 00<br /> |-<br /> | varies<br /> | 0x02<br /> | '''Unknown'''<br /> | 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.<br /> | f0 08<br /> |-<br /> | -0x08<br /> | 0x08<br /> | '''StreetPass ID'''<br /> | 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?<br /> | 0f c9 c6 80 5b 6f bc 5a<br /> |}<br /> <br /> Of note, there is a 4 byte sequence unaccounted for prior to the StreetPass ID and after the currently unknown field. These four bytes may be part of the StreetPass ID, although captures of other 3DS units show the StreetPass ID at a fixed 8-byte value, and not 12-bytes as shown in the example above.<br /> <br /> ===== Protocol Version =====<br /> <br /> 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.<br /> <br /> ===== StreetPass Service Length =====<br /> <br /> 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.<br /> <br /> ===== StreetPass Services =====<br /> <br /> 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:<br /> <br /> Mii Plaza: 00 02 08 00 00<br /> Ridge Racer: 00 03 58 00 30<br /> Sims 3: 00 03 65 00 30<br /> Street Fighter: 00 03 05 00 02 (FF FF FF FF FF FF)<br /> <br /> Some services have a 6-byte field preceding or 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.<br /> <br /> ===== Unknown 2-byte Field =====<br /> <br /> 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'''.<br /> <br /> ===== StreetPass ID =====<br /> <br /> When there's a StreetPass hit, and no StreetPass data changed on either of the 3DSes, no data is transferred besides probes? Perhaps there's some ID in the Nintendo tag that gets updated every-time the 3DS' StreetPass data changes? 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) the 8bytes in the Nintendo tag changes?<br /> <br /> === Initial Probe Response Frame ===<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> The StreetPass Probe Response frame contains the same Nintendo tag in Probe Requests of the device that is transmitting the Probe Response frame.<br /> <br /> === Subsequent Probe Request and Response Frames ===<br /> <br /> 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.<br /> <br /> == StreetPass Spoofing ==<br /> <br /> A streetpass "AP" was spoofed on a laptop with hostapd by setting the SSID to "Nintendo_3DS_continuous_scan_000", with the extra Nintendo tag from another 3DS' probe request. The SSID and AP can't be easily spoofed with hostapd for streetpass when 3DS is "active", for the random "ic[kSvm9s@*cYD>/~IEVj\(fGG;qDo8j" strings. The 3DS didn't seem to authenticate or associate with the "AP". Streetpass "AP" comms use '''WPA2''' encryption. Eventually the 3DS stops communicating with the fake "AP" since the AP doesn't understand the sent data,(especially since it's encrypted) and 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)<br /> Communication with two 3DSes are the same as above except there's encrypted data sent to/from both consoles, unlike the fake "AP".<br /> <br /> [[Category:Nintendo Software]]</div>

Seabrook https://www.3dbrew.org/w/index.php?title=StreetPass&diff=821 StreetPass 2011-06-17T01:08:33Z

<p>Seabrook: </p> <hr /> <div>'''StreetPass''' is a feature that allow your 3DS to connect with other 3DS using WiFi in standby mode.<br /> It can be used to share Mii(s) on Mii Plaza for example. Games' StreetPass data is stored on [[SD_Filesystem|SD card]] under [[extdata]], while Mii Plaza StreetPass data is stored on NAND. Not all StreetPass data is stored on SD card: "StreetPass Management" can still be used without a SD card inserted. Wifi infrastructure with APs are used to communicate, like WMB and multi-player.<br /> StreetPass in sleepmode can work without SD card inserted. Games' Streetpass data are temporarily stored in NAND, and when the games process the StreetPass data they move that data to extdata on SD card.<br /> <br /> == WiFi Probe Request Frame ==<br /> <br /> 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.<br /> <br /> The MAC address used for these probes is the static MAC address found in the 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.<br /> <br /> == StreetPass Exchange ==<br /> <br /> 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. <br /> <br /> The MAC address used in sleepmode seems to change every time there's a StreetPass hit, as well as the last 8-bytes of the Nintendo tag data. The MAC address + 8-byte ID for StreetPass 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 sleepmode, usually do StreetPass every <12 hours?<br /> <br /> When in standby mode the old DS WiFi is used, which includes SpotPass and StreetPass, but in "active" mode the regular DSi WiFi bus is used.<br /> <br /> === Probe Request Frame ===<br /> <br /> 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.<br /> <br /> 0000 00 00 1a 00 2f 48 00 00 19 7d 19 de 2a 00 00 00 ..../H...}..*...<br /> 0010 12 16 9e 09 a0 00 c9 02 00 00 40 00 00 00 ff ff ..........@.....<br /> 0020 ff ff ff ff da 6b f7 22 f3 77 ff ff ff ff ff ff .....k.".w......<br /> 0030 40 77 00 20 4e 69 6e 74 65 6e 64 6f 5f 33 44 53 @w. Nintendo_3DS<br /> 0040 5f 63 6f 6e 74 69 6e 75 6f 75 73 5f 73 63 61 6e _continuous_scan<br /> 0050 5f 30 30 30 01 08 82 84 8b 0c 12 96 18 24 32 04 _000.........$2.<br /> 0060 30 48 60 6c dd 15 00 1f 32 01 11 05 00 02 08 00 0H`l....2.......<br /> 0070 00 f0 08 c8 34 6e 05 0f c9 c6 80 5b 6f bc 5a ....4n.....[o.Z<br /> <br /> ==== Nintendo Tag Format ====<br /> <br /> 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.<br /> <br /> {| class="wikitable" border="1"<br /> |-<br /> ! Offset<br /> ! Length<br /> ! Purpose<br /> ! Description<br /> ! Example<br /> |-<br /> | 0x00<br /> | 0x01<br /> | '''Protocol Identification'''<br /> | May be for protocol identification. All captures thus far show this value at 17, hexadecimal 11.<br /> | 11<br /> |-<br /> | 0x01<br /> | 0x01<br /> | '''StreetPass Service Length'''<br /> | Length in bytes of only the StreetPass Services field.<br /> | 05<br /> |-<br /> | 0x02<br /> | 0x05<br /> | '''StreetPass Services'''<br /> | 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.<br /> | 00 02 08 00 00<br /> |-<br /> | varies<br /> | 0x02<br /> | '''Unknown'''<br /> | 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.<br /> | f0 08<br /> |-<br /> | -0x08<br /> | 0x08<br /> | '''StreetPass ID'''<br /> | 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?<br /> | 0f c9 c6 80 5b 6f bc 5a<br /> |}<br /> <br /> ===== Protocol Version =====<br /> <br /> 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.<br /> <br /> ===== StreetPass Service Length =====<br /> <br /> 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.<br /> <br /> ===== StreetPass Services =====<br /> <br /> 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:<br /> <br /> Mii Plaza: 00 02 08 00 00<br /> Ridge Racer: 00 03 58 00 30<br /> Sims 3: 00 03 65 00 30<br /> Street Fighter: 00 03 05 00 02 (FF FF FF FF FF FF)<br /> <br /> Some services have a 6-byte field preceding or 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.<br /> <br /> ===== Unknown 2-byte Field =====<br /> <br /> 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'''.<br /> <br /> ===== StreetPass ID =====<br /> <br /> When there's a StreetPass hit, and no StreetPass data changed on either of the 3DSes, no data is transferred besides probes? Perhaps there's some ID in the Nintendo tag that gets updated every-time the 3DS' StreetPass data changes? 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) the 8bytes in the Nintendo tag changes?<br /> <br /> === Initial Probe Response Frame ===<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> The StreetPass Probe Response frame contains the same Nintendo tag in Probe Requests of the device that is transmitting the Probe Response frame.<br /> <br /> === Subsequent Probe Request and Response Frames ===<br /> <br /> 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.<br /> <br /> == StreetPass Spoofing ==<br /> <br /> A streetpass "AP" was spoofed on a laptop with hostapd by setting the SSID to "Nintendo_3DS_continuous_scan_000", with the extra Nintendo tag from another 3DS' probe request. The SSID and AP can't be easily spoofed with hostapd for streetpass when 3DS is "active", for the random "ic[kSvm9s@*cYD>/~IEVj\(fGG;qDo8j" strings. The 3DS didn't seem to authenticate or associate with the "AP". Streetpass "AP" comms use '''WPA2''' encryption. Eventually the 3DS stops communicating with the fake "AP" since the AP doesn't understand the sent data,(especially since it's encrypted) and 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)<br /> Communication with two 3DSes are the same as above except there's encrypted data sent to/from both consoles, unlike the fake "AP".<br /> <br /> [[Category:Nintendo Software]]</div>

Seabrook https://www.3dbrew.org/w/index.php?title=StreetPass&diff=819 StreetPass 2011-06-17T01:05:30Z

<p>Seabrook: Clarifying recent edit</p> <hr /> <div>'''StreetPass''' is a feature that allow your 3DS to connect with other 3DS using WiFi in standby mode.<br /> It can be used to share Mii(s) on Mii Plaza for example. Games' StreetPass data is stored on [[SD_Filesystem|SD card]] under [[extdata]], while Mii Plaza StreetPass data is stored on NAND. Not all StreetPass data is stored on SD card: "StreetPass Management" can still be used without a SD card inserted. Wifi infrastructure with APs are used to communicate, like WMB and multi-player.<br /> StreetPass in sleepmode can work without SD card inserted. Games' Streetpass data are temporarily stored in NAND, and when the games process the StreetPass data they move that data to extdata on SD card.<br /> <br /> == WiFi Probe Request Frame ==<br /> <br /> 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.<br /> <br /> The MAC address used for these probes is the static MAC address found in the 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.<br /> <br /> == StreetPass Exchange ==<br /> <br /> 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 access points, 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. <br /> <br /> The MAC address used in sleepmode seems to change every time there's a StreetPass hit, as well as the last 8-bytes of the Nintendo tag data. The MAC address + 8-byte ID for StreetPass 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 sleepmode, usually do StreetPass every <12 hours?<br /> <br /> When in standby mode the old DS WiFi is used, which includes SpotPass and StreetPass, but in "active" mode the regular DSi WiFi bus is used.<br /> <br /> === Probe Request Frame ===<br /> <br /> 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.<br /> <br /> 0000 00 00 1a 00 2f 48 00 00 19 7d 19 de 2a 00 00 00 ..../H...}..*...<br /> 0010 12 16 9e 09 a0 00 c9 02 00 00 40 00 00 00 ff ff ..........@.....<br /> 0020 ff ff ff ff da 6b f7 22 f3 77 ff ff ff ff ff ff .....k.".w......<br /> 0030 40 77 00 20 4e 69 6e 74 65 6e 64 6f 5f 33 44 53 @w. Nintendo_3DS<br /> 0040 5f 63 6f 6e 74 69 6e 75 6f 75 73 5f 73 63 61 6e _continuous_scan<br /> 0050 5f 30 30 30 01 08 82 84 8b 0c 12 96 18 24 32 04 _000.........$2.<br /> 0060 30 48 60 6c dd 15 00 1f 32 01 11 05 00 02 08 00 0H`l....2.......<br /> 0070 00 f0 08 c8 34 6e 05 0f c9 c6 80 5b 6f bc 5a ....4n.....[o.Z<br /> <br /> ==== Nintendo Tag Format ====<br /> <br /> 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.<br /> <br /> {| class="wikitable" border="1"<br /> |-<br /> ! Offset<br /> ! Length<br /> ! Purpose<br /> ! Description<br /> ! Example<br /> |-<br /> | 0x00<br /> | 0x01<br /> | '''Protocol Identification'''<br /> | May be for protocol identification. All captures thus far show this value at 17, hexadecimal 11.<br /> | 11<br /> |-<br /> | 0x01<br /> | 0x01<br /> | '''StreetPass Service Length'''<br /> | Length in bytes of only the StreetPass Services field.<br /> | 05<br /> |-<br /> | 0x02<br /> | 0x05<br /> | '''StreetPass Services'''<br /> | 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.<br /> | 00 02 08 00 00<br /> |-<br /> | varies<br /> | 0x02<br /> | '''Unknown'''<br /> | 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.<br /> | f0 08<br /> |-<br /> | -0x08<br /> | 0x08<br /> | '''StreetPass ID'''<br /> | 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?<br /> | 0f c9 c6 80 5b 6f bc 5a<br /> |}<br /> <br /> ===== Protocol Version =====<br /> <br /> 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.<br /> <br /> ===== StreetPass Service Length =====<br /> <br /> 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.<br /> <br /> ===== StreetPass Services =====<br /> <br /> 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:<br /> <br /> Mii Plaza: 00 02 08 00 00<br /> Ridge Racer: 00 03 58 00 30<br /> Sims 3: 00 03 65 00 30<br /> Street Fighter: 00 03 05 00 02 (FF FF FF FF FF FF)<br /> <br /> Some services have a 6-byte field preceding or 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.<br /> <br /> ===== Unknown 2-byte Field =====<br /> <br /> 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'''.<br /> <br /> ===== StreetPass ID =====<br /> <br /> When there's a StreetPass hit, and no StreetPass data changed on either of the 3DSes, no data is transferred besides probes? Perhaps there's some ID in the Nintendo tag that gets updated every-time the 3DS' StreetPass data changes? 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) the 8bytes in the Nintendo tag changes?<br /> <br /> === Initial Probe Response Frame ===<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> The StreetPass Probe Response frame contains the same Nintendo tag in Probe Requests of the device that is transmitting the Probe Response frame.<br /> <br /> === Subsequent Probe Request and Response Frames ===<br /> <br /> 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.<br /> <br /> == StreetPass Spoofing ==<br /> <br /> A streetpass "AP" was spoofed on a laptop with hostapd by setting the SSID to "Nintendo_3DS_continuous_scan_000", with the extra Nintendo tag from another 3DS' probe request. The SSID and AP can't be easily spoofed with hostapd for streetpass when 3DS is "active", for the random "ic[kSvm9s@*cYD>/~IEVj\(fGG;qDo8j" strings. The 3DS didn't seem to authenticate or associate with the "AP". Streetpass "AP" comms use '''WPA2''' encryption. Eventually the 3DS stops communicating with the fake "AP" since the AP doesn't understand the sent data,(especially since it's encrypted) and 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)<br /> Communication with two 3DSes are the same as above except there's encrypted data sent to/from both consoles, unlike the fake "AP".<br /> <br /> [[Category:Nintendo Software]]</div>

Seabrook https://www.3dbrew.org/w/index.php?title=StreetPass&diff=818 StreetPass 2011-06-17T01:03:37Z

<p>Seabrook: Added a "StreetPass Exchange" summary so we can discuss details in a bit more organized manner. Shuffled some content around where appropriate.</p> <hr /> <div>'''StreetPass''' is a feature that allow your 3DS to connect with other 3DS using WiFi in standby mode.<br /> It can be used to share Mii(s) on Mii Plaza for example. Games' StreetPass data is stored on [[SD_Filesystem|SD card]] under [[extdata]], while Mii Plaza StreetPass data is stored on NAND. Not all StreetPass data is stored on SD card: "StreetPass Management" can still be used without a SD card inserted. Wifi infrastructure with APs are used to communicate, like WMB and multi-player.<br /> StreetPass in sleepmode can work without SD card inserted. Games' Streetpass data are temporarily stored in NAND, and when the games process the StreetPass data they move that data to extdata on SD card.<br /> <br /> == WiFi Probe Request Frame ==<br /> <br /> 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.<br /> <br /> The MAC address used for these probes is the static MAC address found in the 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.<br /> <br /> == StreetPass Exchange ==<br /> <br /> 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 access points, 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. <br /> <br /> The MAC address used in sleepmode seems to change every time there's a StreetPass hit, as well as the last 8-bytes of the Nintendo tag data. The MAC address + 8-byte ID for StreetPass 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 sleepmode, usually do StreetPass every <12 hours?<br /> <br /> When in standby mode the old DS WiFi is used, which includes SpotPass and StreetPass, but in "active" mode the regular DSi WiFi bus is used.<br /> <br /> === Probe Request Frame ===<br /> <br /> 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.<br /> <br /> 0000 00 00 1a 00 2f 48 00 00 19 7d 19 de 2a 00 00 00 ..../H...}..*...<br /> 0010 12 16 9e 09 a0 00 c9 02 00 00 40 00 00 00 ff ff ..........@.....<br /> 0020 ff ff ff ff da 6b f7 22 f3 77 ff ff ff ff ff ff .....k.".w......<br /> 0030 40 77 00 20 4e 69 6e 74 65 6e 64 6f 5f 33 44 53 @w. Nintendo_3DS<br /> 0040 5f 63 6f 6e 74 69 6e 75 6f 75 73 5f 73 63 61 6e _continuous_scan<br /> 0050 5f 30 30 30 01 08 82 84 8b 0c 12 96 18 24 32 04 _000.........$2.<br /> 0060 30 48 60 6c dd 15 00 1f 32 01 11 05 00 02 08 00 0H`l....2.......<br /> 0070 00 f0 08 c8 34 6e 05 0f c9 c6 80 5b 6f bc 5a ....4n.....[o.Z<br /> <br /> ==== Nintendo Tag Format ====<br /> <br /> 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.<br /> <br /> {| class="wikitable" border="1"<br /> |-<br /> ! Offset<br /> ! Length<br /> ! Purpose<br /> ! Description<br /> ! Example<br /> |-<br /> | 0x00<br /> | 0x01<br /> | '''Protocol Identification'''<br /> | May be for protocol identification. All captures thus far show this value at 17, hexadecimal 11.<br /> | 11<br /> |-<br /> | 0x01<br /> | 0x01<br /> | '''StreetPass Service Length'''<br /> | Length in bytes of only the StreetPass Services field.<br /> | 05<br /> |-<br /> | 0x02<br /> | 0x05<br /> | '''StreetPass Services'''<br /> | 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.<br /> | 00 02 08 00 00<br /> |-<br /> | varies<br /> | 0x02<br /> | '''Unknown'''<br /> | 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.<br /> | f0 08<br /> |-<br /> | -0x08<br /> | 0x08<br /> | '''StreetPass ID'''<br /> | 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?<br /> | 0f c9 c6 80 5b 6f bc 5a<br /> |}<br /> <br /> ===== Protocol Version =====<br /> <br /> 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.<br /> <br /> ===== StreetPass Service Length =====<br /> <br /> 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.<br /> <br /> ===== StreetPass Services =====<br /> <br /> 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:<br /> <br /> Mii Plaza: 00 02 08 00 00<br /> Ridge Racer: 00 03 58 00 30<br /> Sims 3: 00 03 65 00 30<br /> Street Fighter: 00 03 05 00 02 (FF FF FF FF FF FF)<br /> <br /> Some services have a 6-byte field preceding or 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.<br /> <br /> ===== Unknown 2-byte Field =====<br /> <br /> 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'''.<br /> <br /> ===== StreetPass ID =====<br /> <br /> When there's a StreetPass hit, and no StreetPass data changed on either of the 3DSes, no data is transferred besides probes? Perhaps there's some ID in the Nintendo tag that gets updated every-time the 3DS' StreetPass data changes? 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) the 8bytes in the Nintendo tag changes?<br /> <br /> === Initial Probe Response Frame ===<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> The StreetPass Probe Response frame contains the same Nintendo tag in Probe Requests of the device that is transmitting the Probe Response frame.<br /> <br /> === Subsequent Probe Request and Response Frames ===<br /> <br /> The 3DS (#1) that the Initial Probe Response is directed to will send an 802.11 Action frame back to the device. 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. <br /> <br /> The sequence number for this frame is +2 the original Probe Request, with the Action frame having a sequence number +1 the initial Probe Request. 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. <br /> <br /> == StreetPass Spoofing ==<br /> <br /> A streetpass "AP" was spoofed on a laptop with hostapd by setting the SSID to "Nintendo_3DS_continuous_scan_000", with the extra Nintendo tag from another 3DS' probe request. The SSID and AP can't be easily spoofed with hostapd for streetpass when 3DS is "active", for the random "ic[kSvm9s@*cYD>/~IEVj\(fGG;qDo8j" strings. The 3DS didn't seem to authenticate or associate with the "AP". Streetpass "AP" comms use '''WPA2''' encryption. Eventually the 3DS stops communicating with the fake "AP" since the AP doesn't understand the sent data,(especially since it's encrypted) and 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)<br /> Communication with two 3DSes are the same as above except there's encrypted data sent to/from both consoles, unlike the fake "AP".<br /> <br /> [[Category:Nintendo Software]]</div>

Seabrook https://www.3dbrew.org/w/index.php?title=StreetPass&diff=816 StreetPass 2011-06-17T00:28:32Z

<p>Seabrook: </p> <hr /> <div>'''StreetPass''' is a feature that allow your 3DS to connect with other 3DS using WiFi in standby mode.<br /> It can be used to share Mii(s) on Mii Plaza for example. Games' StreetPass data is stored on [[SD_Filesystem|SD card]] under [[extdata]], while Mii Plaza StreetPass data is stored on NAND. Not all StreetPass data is stored on SD card: "StreetPass Management" can still be used without a SD card inserted. Wifi infrastructure with APs are used to communicate, like WMB and multi-player.<br /> StreetPass in sleepmode can work without SD card inserted. Games' Streetpass data are temporarily stored in NAND, and when the games process the StreetPass data they move that data to extdata on SD card.<br /> <br /> == WiFi Probe Request Frame ==<br /> <br /> 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.<br /> <br /> The MAC address used for these probes is the static MAC address found in the 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.<br /> <br /> == StreetPass Probe Request Frame ==<br /> <br /> 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 Nintendo tag, which contains information regarding the offered StreetPass services. Probe responses contain the same Nintendo tag data as the probe requests from the same 3DS. The MAC address used in sleepmode seems to change every time there's a StreetPass hit, as well as the last 8-bytes of the Nintendo tag data. The MAC address + 8-byte ID for StreetPass 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.<br /> <br /> 0000 00 00 1a 00 2f 48 00 00 19 7d 19 de 2a 00 00 00 ..../H...}..*...<br /> 0010 12 16 9e 09 a0 00 c9 02 00 00 40 00 00 00 ff ff ..........@.....<br /> 0020 ff ff ff ff da 6b f7 22 f3 77 ff ff ff ff ff ff .....k.".w......<br /> 0030 40 77 00 20 4e 69 6e 74 65 6e 64 6f 5f 33 44 53 @w. Nintendo_3DS<br /> 0040 5f 63 6f 6e 74 69 6e 75 6f 75 73 5f 73 63 61 6e _continuous_scan<br /> 0050 5f 30 30 30 01 08 82 84 8b 0c 12 96 18 24 32 04 _000.........$2.<br /> 0060 30 48 60 6c dd 15 00 1f 32 01 11 05 00 02 08 00 0H`l....2.......<br /> 0070 00 f0 08 c8 34 6e 05 0f c9 c6 80 5b 6f bc 5a ....4n.....[o.Z<br /> <br /> 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 sleepmode, usually do StreetPass every <12 hours?<br /> <br /> When in standby mode the old DS WiFi is used, which includes SpotPass and StreetPass, but in "active" mode the regular DSi WiFi bus is used.<br /> <br /> === Nintendo Tag Format ===<br /> <br /> 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.<br /> <br /> {| class="wikitable" border="1"<br /> |-<br /> ! Offset<br /> ! Length<br /> ! Purpose<br /> ! Description<br /> ! Example<br /> |-<br /> | 0x00<br /> | 0x01<br /> | '''Protocol Identification'''<br /> | May be for protocol identification. All captures thus far show this value at 17, hexadecimal 11.<br /> | 11<br /> |-<br /> | 0x01<br /> | 0x01<br /> | '''StreetPass Service Length'''<br /> | Length in bytes of only the StreetPass Services field.<br /> | 05<br /> |-<br /> | 0x02<br /> | 0x05<br /> | '''StreetPass Services'''<br /> | 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.<br /> | 00 02 08 00 00<br /> |-<br /> | varies<br /> | 0x02<br /> | '''Unknown'''<br /> | 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.<br /> | f0 08<br /> |-<br /> | -0x08<br /> | 0x08<br /> | '''StreetPass ID'''<br /> | 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?<br /> | 0f c9 c6 80 5b 6f bc 5a<br /> |}<br /> <br /> ==== Protocol Version ====<br /> <br /> 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.<br /> <br /> ==== StreetPass Service Length ====<br /> <br /> 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.<br /> <br /> ==== StreetPass Services ====<br /> <br /> 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:<br /> <br /> Mii Plaza: 00 02 08 00 00<br /> Sims 3: 00 03 65 00 30<br /> Street Fighter: 00 03 05 00 02 (FF FF FF FF FF FF)<br /> <br /> Some services have a 6-byte field preceding or 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.<br /> <br /> ==== Unknown 2-byte Field ====<br /> <br /> 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'''.<br /> <br /> ==== StreetPass ID ====<br /> <br /> When there's a StreetPass hit, and no StreetPass data changed on either of the 3DSes, no data is transferred besides probes? Perhaps there's some ID in the Nintendo tag that gets updated every-time the 3DS' StreetPass data changes? 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) the 8bytes in the Nintendo tag changes?<br /> <br /> == StreetPass Probe Response Frame ==<br /> <br /> If a 3DS receives another device's probe request and has not yet tagged that device in an arbitrary amount of time (~12 hours), the receiving 3DS will respond with a Probe Response frame. The destination MAC address is the StreetPass MAC address of the 3DS 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.<br /> <br /> In the probe response, the 3DS 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.<br /> <br /> The StreetPass Probe Response frame contains the same Nintendo tag in Probe Requests of the device that is transmitting the Probe Response frame.<br /> <br /> == StreetPass Spoofing ==<br /> <br /> A streetpass "AP" was spoofed on a laptop with hostapd by setting the SSID to "Nintendo_3DS_continuous_scan_000", with the extra Nintendo tag from another 3DS' probe request. The SSID and AP can't be easily spoofed with hostapd for streetpass when 3DS is "active", for the random "ic[kSvm9s@*cYD>/~IEVj\(fGG;qDo8j" strings. The 3DS didn't seem to authenticate or associate with the "AP". Streetpass "AP" comms use '''WPA2''' encryption. Eventually the 3DS stops communicating with the fake "AP" since the AP doesn't understand the sent data,(especially since it's encrypted) and 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)<br /> Communication with two 3DSes are the same as above except there's encrypted data sent to/from both consoles, unlike the fake "AP".<br /> <br /> [[Category:Nintendo Software]]</div>

Seabrook https://www.3dbrew.org/w/index.php?title=StreetPass&diff=815 StreetPass 2011-06-17T00:19:52Z

<p>Seabrook: /* StreetPass Probe Response Frame */</p> <hr /> <div>'''StreetPass''' is a feature that allow your 3DS to connect with other 3DS using WiFi in standby mode.<br /> It can be used to share Mii(s) on Mii Plaza for example. Games' StreetPass data is stored on [[SD_Filesystem|SD card]] under [[extdata]], while Mii Plaza StreetPass data is stored on NAND. Not all StreetPass data is stored on SD card: "StreetPass Management" can still be used without a SD card inserted. Wifi infrastructure with APs are used to communicate, like WMB and multi-player.<br /> StreetPass in sleepmode can work without SD card inserted. Games' Streetpass data are temporarily stored in NAND, and when the games process the StreetPass data they move that data to extdata on SD card.<br /> <br /> == WiFi Probe Request Frame ==<br /> <br /> 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.<br /> <br /> The MAC address used for these probes is the static MAC address found in the 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.<br /> <br /> == StreetPass Probe Request Frame ==<br /> <br /> 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 Nintendo tag, which contains information regarding the offered StreetPass services. Probe responses contain the same Nintendo tag data as the probe requests from the same 3DS. The MAC address used in sleepmode seems to change every time there's a StreetPass hit, as well as the last 8-bytes of the Nintendo tag data. The MAC address + 8-byte ID for StreetPass 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.<br /> <br /> 0000 00 00 1a 00 2f 48 00 00 19 7d 19 de 2a 00 00 00 ..../H...}..*...<br /> 0010 12 16 9e 09 a0 00 c9 02 00 00 40 00 00 00 ff ff ..........@.....<br /> 0020 ff ff ff ff da 6b f7 22 f3 77 ff ff ff ff ff ff .....k.".w......<br /> 0030 40 77 00 20 4e 69 6e 74 65 6e 64 6f 5f 33 44 53 @w. Nintendo_3DS<br /> 0040 5f 63 6f 6e 74 69 6e 75 6f 75 73 5f 73 63 61 6e _continuous_scan<br /> 0050 5f 30 30 30 01 08 82 84 8b 0c 12 96 18 24 32 04 _000.........$2.<br /> 0060 30 48 60 6c dd 15 00 1f 32 01 11 05 00 02 08 00 0H`l....2.......<br /> 0070 00 f0 08 c8 34 6e 05 0f c9 c6 80 5b 6f bc 5a ....4n.....[o.Z<br /> <br /> 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 sleepmode, usually do StreetPass every <12 hours?<br /> <br /> When in standby mode the old DS WiFi is used, which includes SpotPass and StreetPass, but in "active" mode the regular DSi WiFi bus is used.<br /> <br /> === Nintendo Tag Format ===<br /> <br /> 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.<br /> <br /> {| class="wikitable" border="1"<br /> |-<br /> ! Offset<br /> ! Length<br /> ! Purpose<br /> ! Description<br /> ! Example<br /> |-<br /> | 0x00<br /> | 0x01<br /> | '''Protocol Identification'''<br /> | May be for protocol identification. All captures thus far show this value at 17, hexadecimal 11.<br /> | 11<br /> |-<br /> | 0x01<br /> | 0x01<br /> | '''StreetPass Service Length'''<br /> | Length in bytes of only the StreetPass Services field.<br /> | 05<br /> |-<br /> | 0x02<br /> | 0x05<br /> | '''StreetPass Services'''<br /> | 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.<br /> | 00 02 08 00 00<br /> |-<br /> | varies<br /> | 0x02<br /> | '''Unknown'''<br /> | 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.<br /> | f0 08<br /> |-<br /> | -0x08<br /> | 0x08<br /> | '''StreetPass ID'''<br /> | 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?<br /> | 0f c9 c6 80 5b 6f bc 5a<br /> |}<br /> <br /> ==== Protocol Version ====<br /> <br /> 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.<br /> <br /> ==== StreetPass Service Length ====<br /> <br /> 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.<br /> <br /> ==== StreetPass Services ====<br /> <br /> 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:<br /> <br /> Mii Plaza: 00 02 08 00 00<br /> Sims 3: 00 03 65 00 30<br /> Street Fighter: 00 03 05 00 02 (FF FF FF FF FF FF)<br /> <br /> Some services have a 6-byte field preceding or 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.<br /> <br /> ==== Unknown 2-byte Field ====<br /> <br /> 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'''.<br /> <br /> ==== StreetPass ID ====<br /> <br /> When there's a StreetPass hit, and no StreetPass data changed on either of the 3DSes, no data is transferred besides probes? Perhaps there's some ID in the Nintendo tag that gets updated every-time the 3DS' StreetPass data changes? 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) the 8bytes in the Nintendo tag changes?<br /> <br /> == StreetPass Probe Response Frame ==<br /> <br /> If a 3DS receives another device's probe request and has not yet tagged that device in an arbitrary amount of time (~12 hours), the receiving 3DS will respond with a Probe Response frame. The destination MAC address is the StreetPass MAC address of the 3DS 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.<br /> <br /> In the probe response, the 3DS 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.<br /> <br /> The StreetPass Probe Response frame contains the same Nintendo tag information of the Probe Requests of the device that is transmitting the Probe Response frame.<br /> <br /> == StreetPass Spoofing ==<br /> <br /> A streetpass "AP" was spoofed on a laptop with hostapd by setting the SSID to "Nintendo_3DS_continuous_scan_000", with the extra Nintendo tag from another 3DS' probe request. The SSID and AP can't be easily spoofed with hostapd for streetpass when 3DS is "active", for the random "ic[kSvm9s@*cYD>/~IEVj\(fGG;qDo8j" strings. The 3DS didn't seem to authenticate or associate with the "AP". Streetpass "AP" comms use '''WPA2''' encryption. Eventually the 3DS stops communicating with the fake "AP" since the AP doesn't understand the sent data,(especially since it's encrypted) and 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)<br /> Communication with two 3DSes are the same as above except there's encrypted data sent to/from both consoles, unlike the fake "AP".<br /> <br /> [[Category:Nintendo Software]]</div>

Seabrook https://www.3dbrew.org/w/index.php?title=StreetPass&diff=814 StreetPass 2011-06-17T00:17:53Z

<p>Seabrook: Updating section based on new information.</p> <hr /> <div>'''StreetPass''' is a feature that allow your 3DS to connect with other 3DS using WiFi in standby mode.<br /> It can be used to share Mii(s) on Mii Plaza for example. Games' StreetPass data is stored on [[SD_Filesystem|SD card]] under [[extdata]], while Mii Plaza StreetPass data is stored on NAND. Not all StreetPass data is stored on SD card: "StreetPass Management" can still be used without a SD card inserted. Wifi infrastructure with APs are used to communicate, like WMB and multi-player.<br /> StreetPass in sleepmode can work without SD card inserted. Games' Streetpass data are temporarily stored in NAND, and when the games process the StreetPass data they move that data to extdata on SD card.<br /> <br /> == WiFi Probe Request Frame ==<br /> <br /> 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.<br /> <br /> The MAC address used for these probes is the static MAC address found in the 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.<br /> <br /> == StreetPass Probe Request Frame ==<br /> <br /> 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 Nintendo tag, which contains information regarding the offered StreetPass services. Probe responses contain the same Nintendo tag data as the probe requests from the same 3DS. The MAC address used in sleepmode seems to change every time there's a StreetPass hit, as well as the last 8-bytes of the Nintendo tag data. The MAC address + 8-byte ID for StreetPass 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.<br /> <br /> 0000 00 00 1a 00 2f 48 00 00 19 7d 19 de 2a 00 00 00 ..../H...}..*...<br /> 0010 12 16 9e 09 a0 00 c9 02 00 00 40 00 00 00 ff ff ..........@.....<br /> 0020 ff ff ff ff da 6b f7 22 f3 77 ff ff ff ff ff ff .....k.".w......<br /> 0030 40 77 00 20 4e 69 6e 74 65 6e 64 6f 5f 33 44 53 @w. Nintendo_3DS<br /> 0040 5f 63 6f 6e 74 69 6e 75 6f 75 73 5f 73 63 61 6e _continuous_scan<br /> 0050 5f 30 30 30 01 08 82 84 8b 0c 12 96 18 24 32 04 _000.........$2.<br /> 0060 30 48 60 6c dd 15 00 1f 32 01 11 05 00 02 08 00 0H`l....2.......<br /> 0070 00 f0 08 c8 34 6e 05 0f c9 c6 80 5b 6f bc 5a ....4n.....[o.Z<br /> <br /> 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 sleepmode, usually do StreetPass every <12 hours?<br /> <br /> When in standby mode the old DS WiFi is used, which includes SpotPass and StreetPass, but in "active" mode the regular DSi WiFi bus is used.<br /> <br /> === Nintendo Tag Format ===<br /> <br /> 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.<br /> <br /> {| class="wikitable" border="1"<br /> |-<br /> ! Offset<br /> ! Length<br /> ! Purpose<br /> ! Description<br /> ! Example<br /> |-<br /> | 0x00<br /> | 0x01<br /> | '''Protocol Identification'''<br /> | May be for protocol identification. All captures thus far show this value at 17, hexadecimal 11.<br /> | 11<br /> |-<br /> | 0x01<br /> | 0x01<br /> | '''StreetPass Service Length'''<br /> | Length in bytes of only the StreetPass Services field.<br /> | 05<br /> |-<br /> | 0x02<br /> | 0x05<br /> | '''StreetPass Services'''<br /> | 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.<br /> | 00 02 08 00 00<br /> |-<br /> | varies<br /> | 0x02<br /> | '''Unknown'''<br /> | 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.<br /> | f0 08<br /> |-<br /> | -0x08<br /> | 0x08<br /> | '''StreetPass ID'''<br /> | 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?<br /> | 0f c9 c6 80 5b 6f bc 5a<br /> |}<br /> <br /> ==== Protocol Version ====<br /> <br /> 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.<br /> <br /> ==== StreetPass Service Length ====<br /> <br /> 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.<br /> <br /> ==== StreetPass Services ====<br /> <br /> 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:<br /> <br /> Mii Plaza: 00 02 08 00 00<br /> Sims 3: 00 03 65 00 30<br /> Street Fighter: 00 03 05 00 02 (FF FF FF FF FF FF)<br /> <br /> Some services have a 6-byte field preceding or 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.<br /> <br /> ==== Unknown 2-byte Field ====<br /> <br /> 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'''.<br /> <br /> ==== StreetPass ID ====<br /> <br /> When there's a StreetPass hit, and no StreetPass data changed on either of the 3DSes, no data is transferred besides probes? Perhaps there's some ID in the Nintendo tag that gets updated every-time the 3DS' StreetPass data changes? 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) the 8bytes in the Nintendo tag changes?<br /> <br /> == StreetPass Probe Response Frame ==<br /> <br /> If a 3DS receives another device's probe request and has not yet tagged that device in an arbitrary amount of time (~12 hours), the receiving 3DS will response with a Probe Response frame. The destination MAC address is the StreetPass MAC address of the 3DS 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.<br /> <br /> In the probe response, the 3DS 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.<br /> <br /> == StreetPass Spoofing ==<br /> <br /> A streetpass "AP" was spoofed on a laptop with hostapd by setting the SSID to "Nintendo_3DS_continuous_scan_000", with the extra Nintendo tag from another 3DS' probe request. The SSID and AP can't be easily spoofed with hostapd for streetpass when 3DS is "active", for the random "ic[kSvm9s@*cYD>/~IEVj\(fGG;qDo8j" strings. The 3DS didn't seem to authenticate or associate with the "AP". Streetpass "AP" comms use '''WPA2''' encryption. Eventually the 3DS stops communicating with the fake "AP" since the AP doesn't understand the sent data,(especially since it's encrypted) and 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)<br /> Communication with two 3DSes are the same as above except there's encrypted data sent to/from both consoles, unlike the fake "AP".<br /> <br /> [[Category:Nintendo Software]]</div>

Seabrook https://www.3dbrew.org/w/index.php?title=StreetPass&diff=813 StreetPass 2011-06-17T00:15:08Z

<p>Seabrook: /* Nintendo Tag Format */</p> <hr /> <div>'''StreetPass''' is a feature that allow your 3DS to connect with other 3DS using WiFi in standby mode.<br /> It can be used to share Mii(s) on Mii Plaza for example. Games' StreetPass data is stored on [[SD_Filesystem|SD card]] under [[extdata]], while Mii Plaza StreetPass data is stored on NAND. Not all StreetPass data is stored on SD card: "StreetPass Management" can still be used without a SD card inserted. Wifi infrastructure with APs are used to communicate, like WMB and multi-player.<br /> StreetPass in sleepmode can work without SD card inserted. Games' Streetpass data are temporarily stored in NAND, and when the games process the StreetPass data they move that data to extdata on SD card.<br /> <br /> == WiFi Probe Request Frame ==<br /> <br /> 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.<br /> <br /> The MAC address used for these probes is the static MAC address found in the 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.<br /> <br /> == StreetPass Probe Request Frame ==<br /> <br /> 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 frame also contains a custom Nintendo tag, the contents of this tag from different 3ds captures don't match. Probe responses contain the same Nintendo tag data as the probe requests from the same 3DS. The MAC address used in sleepmode seems to change every time there's a streetpass hit, as well as the last 8-bytes of the Nintendo tag data? The MAC address + 8 byte ID for StreetPass is seen to change every time the user enters and exits and Settings application.<br /> <br /> 0000 00 00 1a 00 2f 48 00 00 19 7d 19 de 2a 00 00 00 ..../H...}..*...<br /> 0010 12 16 9e 09 a0 00 c9 02 00 00 40 00 00 00 ff ff ..........@.....<br /> 0020 ff ff ff ff da 6b f7 22 f3 77 ff ff ff ff ff ff .....k.".w......<br /> 0030 40 77 00 20 4e 69 6e 74 65 6e 64 6f 5f 33 44 53 @w. Nintendo_3DS<br /> 0040 5f 63 6f 6e 74 69 6e 75 6f 75 73 5f 73 63 61 6e _continuous_scan<br /> 0050 5f 30 30 30 01 08 82 84 8b 0c 12 96 18 24 32 04 _000.........$2.<br /> 0060 30 48 60 6c dd 15 00 1f 32 01 11 05 00 02 08 00 0H`l....2.......<br /> 0070 00 f0 08 c8 34 6e 05 0f c9 c6 80 5b 6f bc 5a ....4n.....[o.Z<br /> <br /> 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 sleepmode, usually do StreetPass every <12 hours?<br /> <br /> When in standby mode the old DS WiFi is used, which includes SpotPass and StreetPass, but in "active" mode the regular DSi WiFi bus is used.<br /> <br /> === Nintendo Tag Format ===<br /> <br /> 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.<br /> <br /> {| class="wikitable" border="1"<br /> |-<br /> ! Offset<br /> ! Length<br /> ! Purpose<br /> ! Description<br /> ! Example<br /> |-<br /> | 0x00<br /> | 0x01<br /> | '''Protocol Identification'''<br /> | May be for protocol identification. All captures thus far show this value at 17, hexadecimal 11.<br /> | 11<br /> |-<br /> | 0x01<br /> | 0x01<br /> | '''StreetPass Service Length'''<br /> | Length in bytes of only the StreetPass Services field.<br /> | 05<br /> |-<br /> | 0x02<br /> | 0x05<br /> | '''StreetPass Services'''<br /> | 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.<br /> | 00 02 08 00 00<br /> |-<br /> | varies<br /> | 0x02<br /> | '''Unknown'''<br /> | 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.<br /> | f0 08<br /> |-<br /> | -0x08<br /> | 0x08<br /> | '''StreetPass ID'''<br /> | 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?<br /> | 0f c9 c6 80 5b 6f bc 5a<br /> |}<br /> <br /> ==== Protocol Version ====<br /> <br /> 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.<br /> <br /> ==== StreetPass Service Length ====<br /> <br /> 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.<br /> <br /> ==== StreetPass Services ====<br /> <br /> 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:<br /> <br /> Mii Plaza: 00 02 08 00 00<br /> Sims 3: 00 03 65 00 30<br /> Street Fighter: 00 03 05 00 02 (FF FF FF FF FF FF)<br /> <br /> Some services have a 6-byte field preceding or 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.<br /> <br /> ==== Unknown 2-byte Field ====<br /> <br /> 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'''.<br /> <br /> ==== StreetPass ID ====<br /> <br /> When there's a StreetPass hit, and no StreetPass data changed on either of the 3DSes, no data is transferred besides probes? Perhaps there's some ID in the Nintendo tag that gets updated every-time the 3DS' StreetPass data changes? 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) the 8bytes in the Nintendo tag changes?<br /> <br /> == StreetPass Probe Response Frame ==<br /> <br /> If a 3DS receives another device's probe request and has not yet tagged that device in an arbitrary amount of time (~12 hours), the receiving 3DS will response with a Probe Response frame. The destination MAC address is the StreetPass MAC address of the 3DS 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.<br /> <br /> In the probe response, the 3DS 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.<br /> <br /> == StreetPass Spoofing ==<br /> <br /> A streetpass "AP" was spoofed on a laptop with hostapd by setting the SSID to "Nintendo_3DS_continuous_scan_000", with the extra Nintendo tag from another 3DS' probe request. The SSID and AP can't be easily spoofed with hostapd for streetpass when 3DS is "active", for the random "ic[kSvm9s@*cYD>/~IEVj\(fGG;qDo8j" strings. The 3DS didn't seem to authenticate or associate with the "AP". Streetpass "AP" comms use '''WPA2''' encryption. Eventually the 3DS stops communicating with the fake "AP" since the AP doesn't understand the sent data,(especially since it's encrypted) and 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)<br /> Communication with two 3DSes are the same as above except there's encrypted data sent to/from both consoles, unlike the fake "AP".<br /> <br /> [[Category:Nintendo Software]]</div>

Seabrook https://www.3dbrew.org/w/index.php?title=StreetPass&diff=812 StreetPass 2011-06-17T00:07:10Z

<p>Seabrook: Channel selection observation</p> <hr /> <div>'''StreetPass''' is a feature that allow your 3DS to connect with other 3DS using WiFi in standby mode.<br /> It can be used to share Mii(s) on Mii Plaza for example. Games' StreetPass data is stored on [[SD_Filesystem|SD card]] under [[extdata]], while Mii Plaza StreetPass data is stored on NAND. Not all StreetPass data is stored on SD card: "StreetPass Management" can still be used without a SD card inserted. Wifi infrastructure with APs are used to communicate, like WMB and multi-player.<br /> StreetPass in sleepmode can work without SD card inserted. Games' Streetpass data are temporarily stored in NAND, and when the games process the StreetPass data they move that data to extdata on SD card.<br /> <br /> == WiFi Probe Request Frame ==<br /> <br /> 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.<br /> <br /> The MAC address used for these probes is the static MAC address found in the 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.<br /> <br /> == StreetPass Probe Request Frame ==<br /> <br /> 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 frame also contains a custom Nintendo tag, the contents of this tag from different 3ds captures don't match. Probe responses contain the same Nintendo tag data as the probe requests from the same 3DS. The MAC address used in sleepmode seems to change every time there's a streetpass hit, as well as the last 8-bytes of the Nintendo tag data? The MAC address + 8 byte ID for StreetPass is seen to change every time the user enters and exits and Settings application.<br /> <br /> 0000 00 00 1a 00 2f 48 00 00 19 7d 19 de 2a 00 00 00 ..../H...}..*...<br /> 0010 12 16 9e 09 a0 00 c9 02 00 00 40 00 00 00 ff ff ..........@.....<br /> 0020 ff ff ff ff da 6b f7 22 f3 77 ff ff ff ff ff ff .....k.".w......<br /> 0030 40 77 00 20 4e 69 6e 74 65 6e 64 6f 5f 33 44 53 @w. Nintendo_3DS<br /> 0040 5f 63 6f 6e 74 69 6e 75 6f 75 73 5f 73 63 61 6e _continuous_scan<br /> 0050 5f 30 30 30 01 08 82 84 8b 0c 12 96 18 24 32 04 _000.........$2.<br /> 0060 30 48 60 6c dd 15 00 1f 32 01 11 05 00 02 08 00 0H`l....2.......<br /> 0070 00 f0 08 c8 34 6e 05 0f c9 c6 80 5b 6f bc 5a ....4n.....[o.Z<br /> <br /> 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 sleepmode, usually do StreetPass every <12 hours?<br /> <br /> When in standby mode the old DS WiFi is used, which includes SpotPass and StreetPass, but in "active" mode the regular DSi WiFi bus is used.<br /> <br /> === Nintendo Tag Format ===<br /> <br /> 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.<br /> <br /> {| class="wikitable" border="1"<br /> |-<br /> ! Offset<br /> ! Length<br /> ! Purpose<br /> ! Description<br /> | Example<br /> |-<br /> | 0x00<br /> | 0x01<br /> | '''Protocol Identification'''<br /> | May be for protocol identification. All captures thus far show this value at 17, hexadecimal 11.<br /> | 11<br /> |-<br /> | 0x01<br /> | 0x01<br /> | '''StreetPass Service Length'''<br /> | Length in bytes of only the StreetPass Services field.<br /> | 05<br /> |-<br /> | 0x02<br /> | 0x05<br /> | '''StreetPass Services'''<br /> | 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.<br /> | 00 02 08 00 00<br /> |-<br /> | varies<br /> | 0x02<br /> | '''Unknown'''<br /> | 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.<br /> | f0 08<br /> |-<br /> | -0x08<br /> | 0x08<br /> | '''StreetPass ID'''<br /> | 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?<br /> | 0f c9 c6 80 5b 6f bc 5a<br /> |}<br /> <br /> ==== Protocol Version ====<br /> <br /> 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.<br /> <br /> ==== StreetPass Service Length ====<br /> <br /> 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.<br /> <br /> ==== StreetPass Services ====<br /> <br /> 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:<br /> <br /> Mii Plaza: 00 02 08 00 00<br /> Sims 3: 00 03 65 00 30<br /> Street Fighter: 00 03 05 00 02 (FF FF FF FF FF FF)<br /> <br /> Some services have a 6-byte field preceding or 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.<br /> <br /> ==== Unknown 2-byte Field ====<br /> <br /> 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'''.<br /> <br /> ==== StreetPass ID ====<br /> <br /> When there's a StreetPass hit, and no StreetPass data changed on either of the 3DSes, no data is transferred besides probes? Perhaps there's some ID in the Nintendo tag that gets updated every-time the 3DS' StreetPass data changes? 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) the 8bytes in the Nintendo tag changes?<br /> <br /> == StreetPass Probe Response Frame ==<br /> <br /> If a 3DS receives another device's probe request and has not yet tagged that device in an arbitrary amount of time (~12 hours), the receiving 3DS will response with a Probe Response frame. The destination MAC address is the StreetPass MAC address of the 3DS 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.<br /> <br /> In the probe response, the 3DS 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.<br /> <br /> == StreetPass Spoofing ==<br /> <br /> A streetpass "AP" was spoofed on a laptop with hostapd by setting the SSID to "Nintendo_3DS_continuous_scan_000", with the extra Nintendo tag from another 3DS' probe request. The SSID and AP can't be easily spoofed with hostapd for streetpass when 3DS is "active", for the random "ic[kSvm9s@*cYD>/~IEVj\(fGG;qDo8j" strings. The 3DS didn't seem to authenticate or associate with the "AP". Streetpass "AP" comms use '''WPA2''' encryption. Eventually the 3DS stops communicating with the fake "AP" since the AP doesn't understand the sent data,(especially since it's encrypted) and 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)<br /> Communication with two 3DSes are the same as above except there's encrypted data sent to/from both consoles, unlike the fake "AP".<br /> <br /> [[Category:Nintendo Software]]</div>

Seabrook https://www.3dbrew.org/w/index.php?title=StreetPass&diff=811 StreetPass 2011-06-16T23:55:07Z

<p>Seabrook: Starting Probe Response Frame</p> <hr /> <div>'''StreetPass''' is a feature that allow your 3DS to connect with other 3DS using WiFi in standby mode.<br /> It can be used to share Mii(s) on Mii Plaza for example. Games' StreetPass data is stored on [[SD_Filesystem|SD card]] under [[extdata]], while Mii Plaza StreetPass data is stored on NAND. Not all StreetPass data is stored on SD card: "StreetPass Management" can still be used without a SD card inserted. Wifi infrastructure with APs are used to communicate, like WMB and multi-player.<br /> StreetPass in sleepmode can work without SD card inserted. Games' Streetpass data are temporarily stored in NAND, and when the games process the StreetPass data they move that data to extdata on SD card.<br /> <br /> == WiFi Probe Request Frame ==<br /> <br /> 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.<br /> <br /> The MAC address used for these probes is the static MAC address found in the 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.<br /> <br /> == StreetPass Probe Request Frame ==<br /> <br /> 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 frame also contains a custom Nintendo tag, the contents of this tag from different 3ds captures don't match. Probe responses contain the same Nintendo tag data as the probe requests from the same 3DS. The MAC address used in sleepmode seems to change every time there's a streetpass hit, as well as the last 8-bytes of the Nintendo tag data? The MAC address + 8 byte ID for StreetPass is seen to change every time the user enters and exits and Settings application.<br /> <br /> 0000 00 00 1a 00 2f 48 00 00 19 7d 19 de 2a 00 00 00 ..../H...}..*...<br /> 0010 12 16 9e 09 a0 00 c9 02 00 00 40 00 00 00 ff ff ..........@.....<br /> 0020 ff ff ff ff da 6b f7 22 f3 77 ff ff ff ff ff ff .....k.".w......<br /> 0030 40 77 00 20 4e 69 6e 74 65 6e 64 6f 5f 33 44 53 @w. Nintendo_3DS<br /> 0040 5f 63 6f 6e 74 69 6e 75 6f 75 73 5f 73 63 61 6e _continuous_scan<br /> 0050 5f 30 30 30 01 08 82 84 8b 0c 12 96 18 24 32 04 _000.........$2.<br /> 0060 30 48 60 6c dd 15 00 1f 32 01 11 05 00 02 08 00 0H`l....2.......<br /> 0070 00 f0 08 c8 34 6e 05 0f c9 c6 80 5b 6f bc 5a ....4n.....[o.Z<br /> <br /> 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 sleepmode, usually do StreetPass every <12 hours?<br /> <br /> When in standby mode the old DS WiFi is used, which includes SpotPass and StreetPass, but in "active" mode the regular DSi WiFi bus is used.<br /> <br /> === Nintendo Tag Format ===<br /> <br /> 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.<br /> <br /> {| class="wikitable" border="1"<br /> |-<br /> ! Offset<br /> ! Length<br /> ! Purpose<br /> ! Description<br /> | Example<br /> |-<br /> | 0x00<br /> | 0x01<br /> | '''Protocol Identification'''<br /> | May be for protocol identification. All captures thus far show this value at 17, hexadecimal 11.<br /> | 11<br /> |-<br /> | 0x01<br /> | 0x01<br /> | '''StreetPass Service Length'''<br /> | Length in bytes of only the StreetPass Services field.<br /> | 05<br /> |-<br /> | 0x02<br /> | 0x05<br /> | '''StreetPass Services'''<br /> | 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.<br /> | 00 02 08 00 00<br /> |-<br /> | varies<br /> | 0x02<br /> | '''Unknown'''<br /> | 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.<br /> | f0 08<br /> |-<br /> | -0x08<br /> | 0x08<br /> | '''StreetPass ID'''<br /> | 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?<br /> | 0f c9 c6 80 5b 6f bc 5a<br /> |}<br /> <br /> ==== Protocol Version ====<br /> <br /> 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.<br /> <br /> ==== StreetPass Service Length ====<br /> <br /> 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.<br /> <br /> ==== StreetPass Services ====<br /> <br /> 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:<br /> <br /> Mii Plaza: 00 02 08 00 00<br /> Sims 3: 00 03 65 00 30<br /> Street Fighter: 00 03 05 00 02 (FF FF FF FF FF FF)<br /> <br /> Some services have a 6-byte field preceding or 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.<br /> <br /> ==== Unknown 2-byte Field ====<br /> <br /> 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'''.<br /> <br /> ==== StreetPass ID ====<br /> <br /> When there's a StreetPass hit, and no StreetPass data changed on either of the 3DSes, no data is transferred besides probes? Perhaps there's some ID in the Nintendo tag that gets updated every-time the 3DS' StreetPass data changes? 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) the 8bytes in the Nintendo tag changes?<br /> <br /> == StreetPass Probe Response Frame ==<br /> <br /> If a 3DS receives another device's probe request and has not yet tagged that device in an arbitrary amount of time (~12 hours), the receiving 3DS will response with a Probe Response frame. The destination MAC address is the StreetPass MAC address of the 3DS 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.<br /> <br /> == StreetPass Spoofing ==<br /> <br /> A streetpass "AP" was spoofed on a laptop with hostapd by setting the SSID to "Nintendo_3DS_continuous_scan_000", with the extra Nintendo tag from another 3DS' probe request. The SSID and AP can't be easily spoofed with hostapd for streetpass when 3DS is "active", for the random "ic[kSvm9s@*cYD>/~IEVj\(fGG;qDo8j" strings. The 3DS didn't seem to authenticate or associate with the "AP". Streetpass "AP" comms use '''WPA2''' encryption. Eventually the 3DS stops communicating with the fake "AP" since the AP doesn't understand the sent data,(especially since it's encrypted) and 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)<br /> Communication with two 3DSes are the same as above except there's encrypted data sent to/from both consoles, unlike the fake "AP".<br /> <br /> [[Category:Nintendo Software]]</div>

Seabrook https://www.3dbrew.org/w/index.php?title=StreetPass&diff=810 StreetPass 2011-06-16T23:45:14Z

<p>Seabrook: This has been proven false by the latest update</p> <hr /> <div>'''StreetPass''' is a feature that allow your 3DS to connect with other 3DS using WiFi in standby mode.<br /> It can be used to share Mii(s) on Mii Plaza for example. Games' StreetPass data is stored on [[SD_Filesystem|SD card]] under [[extdata]], while Mii Plaza StreetPass data is stored on NAND. Not all StreetPass data is stored on SD card: "StreetPass Management" can still be used without a SD card inserted. Wifi infrastructure with APs are used to communicate, like WMB and multi-player.<br /> StreetPass in sleepmode can work without SD card inserted. Games' Streetpass data are temporarily stored in NAND, and when the games process the StreetPass data they move that data to extdata on SD card.<br /> <br /> == WiFi Probe Request Frame ==<br /> <br /> 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.<br /> <br /> The MAC address used for these probes is the static MAC address found in the 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.<br /> <br /> == StreetPass Probe Frame ==<br /> <br /> 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 frame also contains a custom Nintendo tag, the contents of this tag from different 3ds captures don't match. Probe responses contain the same Nintendo tag data as the probe requests from the same 3DS. The MAC address used in sleepmode seems to change every time there's a streetpass hit, as well as the last 8-bytes of the Nintendo tag data? The MAC address + 8 byte ID for StreetPass is seen to change every time the user enters and exits and Settings application.<br /> <br /> 0000 00 00 1a 00 2f 48 00 00 19 7d 19 de 2a 00 00 00 ..../H...}..*...<br /> 0010 12 16 9e 09 a0 00 c9 02 00 00 40 00 00 00 ff ff ..........@.....<br /> 0020 ff ff ff ff da 6b f7 22 f3 77 ff ff ff ff ff ff .....k.".w......<br /> 0030 40 77 00 20 4e 69 6e 74 65 6e 64 6f 5f 33 44 53 @w. Nintendo_3DS<br /> 0040 5f 63 6f 6e 74 69 6e 75 6f 75 73 5f 73 63 61 6e _continuous_scan<br /> 0050 5f 30 30 30 01 08 82 84 8b 0c 12 96 18 24 32 04 _000.........$2.<br /> 0060 30 48 60 6c dd 15 00 1f 32 01 11 05 00 02 08 00 0H`l....2.......<br /> 0070 00 f0 08 c8 34 6e 05 0f c9 c6 80 5b 6f bc 5a ....4n.....[o.Z<br /> <br /> 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 sleepmode, usually do StreetPass every <12 hours?<br /> <br /> When in standby mode the old DS WiFi is used, which includes SpotPass and StreetPass, but in "active" mode the regular DSi WiFi bus is used.<br /> <br /> === Nintendo Tag Format ===<br /> <br /> 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.<br /> <br /> {| class="wikitable" border="1"<br /> |-<br /> ! Offset<br /> ! Length<br /> ! Purpose<br /> ! Description<br /> | Example<br /> |-<br /> | 0x00<br /> | 0x01<br /> | '''Protocol identification'''<br /> | May be for protocol identification. All captures thus far show this value at 17, hexadecimal 11.<br /> | 11<br /> |-<br /> | 0x01<br /> | 0x01<br /> | '''StreetPass Service Length'''<br /> | Length in bytes of only the StreetPass Services field.<br /> | 05<br /> |-<br /> | 0x02<br /> | 0x05<br /> | '''StreetPass Services'''<br /> | 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.<br /> | 00 02 08 00 00<br /> |-<br /> | varies<br /> | 0x02<br /> | '''Unknown'''<br /> | 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.<br /> | f0 08<br /> |-<br /> | -0x08<br /> | 0x08<br /> | '''StreetPass ID'''<br /> | 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?<br /> | 0f c9 c6 80 5b 6f bc 5a<br /> |}<br /> <br /> ==== Protocol Version ====<br /> <br /> 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.<br /> <br /> ==== StreetPass Service Length ====<br /> <br /> 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.<br /> <br /> ==== StreetPass Services ====<br /> <br /> 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:<br /> <br /> Mii Plaza: 00 02 08 00 00<br /> Sims 3: 00 03 65 00 30<br /> Street Fighter: 00 03 05 00 02 (FF FF FF FF FF FF)<br /> <br /> Some services have a 6-byte field preceding or 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.<br /> <br /> ==== Unknown 2-byte Field ====<br /> <br /> 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'''.<br /> <br /> ==== StreetPass ID ====<br /> <br /> When there's a StreetPass hit, and no StreetPass data changed on either of the 3DSes, no data is transferred besides probes? Perhaps there's some ID in the Nintendo tag that gets updated every-time the 3DS' StreetPass data changes? 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) the 8bytes in the Nintendo tag changes?<br /> <br /> == StreetPass spoofing ==<br /> <br /> A streetpass "AP" was spoofed on a laptop with hostapd by setting the SSID to "Nintendo_3DS_continuous_scan_000", with the extra Nintendo tag from another 3DS' probe request. The SSID and AP can't be easily spoofed with hostapd for streetpass when 3DS is "active", for the random "ic[kSvm9s@*cYD>/~IEVj\(fGG;qDo8j" strings. The 3DS didn't seem to authenticate or associate with the "AP". Streetpass "AP" comms use '''WPA2''' encryption. Eventually the 3DS stops communicating with the fake "AP" since the AP doesn't understand the sent data,(especially since it's encrypted) and 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)<br /> Communication with two 3DSes are the same as above except there's encrypted data sent to/from both consoles, unlike the fake "AP".<br /> <br /> [[Category:Nintendo Software]]</div>

Seabrook https://www.3dbrew.org/w/index.php?title=StreetPass&diff=809 StreetPass 2011-06-16T23:28:15Z

<p>Seabrook: /* Nintendo Tag Format */</p> <hr /> <div>'''StreetPass''' is a feature that allow your 3DS to connect with other 3DS using WiFi in standby mode.<br /> It can be used to share Mii(s) on Mii Plaza for example. Games' StreetPass data is stored on [[SD_Filesystem|SD card]] under [[extdata]], while Mii Plaza StreetPass data is stored on NAND. Not all StreetPass data is stored on SD card: "StreetPass Management" can still be used without a SD card inserted. Wifi infrastructure with APs are used to communicate, like WMB and multi-player.<br /> StreetPass in sleepmode can work without SD card inserted. Games' Streetpass data are temporarily stored in NAND, and when the games process the StreetPass data they move that data to extdata on SD card.<br /> <br /> == WiFi Probe Request Frame ==<br /> <br /> 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.<br /> <br /> The MAC address used for these probes is the static MAC address found in the 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.<br /> <br /> == StreetPass Probe Frame ==<br /> <br /> 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 frame also contains a custom Nintendo tag, the contents of this tag from different 3ds captures don't match. Probe responses contain the same Nintendo tag data as the probe requests from the same 3DS. The MAC address used in sleepmode seems to change every time there's a streetpass hit, as well as the last 8-bytes of the Nintendo tag data? The MAC address + 8 byte ID for StreetPass is seen to change every time the user enters and exits and Settings application.<br /> <br /> 0000 00 00 1a 00 2f 48 00 00 19 7d 19 de 2a 00 00 00 ..../H...}..*...<br /> 0010 12 16 9e 09 a0 00 c9 02 00 00 40 00 00 00 ff ff ..........@.....<br /> 0020 ff ff ff ff da 6b f7 22 f3 77 ff ff ff ff ff ff .....k.".w......<br /> 0030 40 77 00 20 4e 69 6e 74 65 6e 64 6f 5f 33 44 53 @w. Nintendo_3DS<br /> 0040 5f 63 6f 6e 74 69 6e 75 6f 75 73 5f 73 63 61 6e _continuous_scan<br /> 0050 5f 30 30 30 01 08 82 84 8b 0c 12 96 18 24 32 04 _000.........$2.<br /> 0060 30 48 60 6c dd 15 00 1f 32 01 11 05 00 02 08 00 0H`l....2.......<br /> 0070 00 f0 08 c8 34 6e 05 0f c9 c6 80 5b 6f bc 5a ....4n.....[o.Z<br /> <br /> 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 sleepmode, usually do StreetPass every <12 hours?<br /> <br /> When in standby mode the old DS WiFi is used, which includes SpotPass and StreetPass, but in "active" mode the regular DSi WiFi bus is used.<br /> <br /> === Nintendo Tag Format ===<br /> <br /> 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.<br /> <br /> {| class="wikitable" border="1"<br /> |-<br /> ! Offset<br /> ! Length<br /> ! Purpose<br /> ! Description<br /> | Example<br /> |-<br /> | 0x00<br /> | 0x01<br /> | '''Protocol identification'''<br /> | May be for protocol identification. All captures thus far show this value at 17, hexadecimal 11.<br /> | 11<br /> |-<br /> | 0x01<br /> | 0x01<br /> | '''StreetPass Service Length'''<br /> | Length in bytes of only the StreetPass Services field.<br /> | 05<br /> |-<br /> | 0x02<br /> | 0x05<br /> | '''StreetPass Services'''<br /> | 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.<br /> | 00 02 08 00 00<br /> |-<br /> | varies<br /> | 0x02<br /> | '''Unknown'''<br /> | 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. It may represent software version.<br /> | f0 08<br /> |-<br /> | -0x08<br /> | 0x08<br /> | '''StreetPass ID'''<br /> | 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?<br /> | 0f c9 c6 80 5b 6f bc 5a<br /> |}<br /> <br /> ==== Protocol Version ====<br /> <br /> 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.<br /> <br /> ==== StreetPass Service Length ====<br /> <br /> 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.<br /> <br /> ==== StreetPass Services ====<br /> <br /> 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:<br /> <br /> Mii Plaza: 00 02 08 00 00<br /> Sims 3: 00 03 65 00 30<br /> Street Fighter: 00 03 05 00 02 (FF FF FF FF FF FF)<br /> <br /> Some services have a 6-byte field preceding or 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.<br /> <br /> ==== Unknown 2-byte Field ====<br /> <br /> The purpose of this field is not known yet, although the likely use of it might be software version on the device. It has remained the same across all devices thus far. The value has always been observed as '''f008'''.<br /> <br /> ==== StreetPass ID ====<br /> <br /> When there's a StreetPass hit, and no StreetPass data changed on either of the 3DSes, no data is transferred besides probes? Perhaps there's some ID in the Nintendo tag that gets updated every-time the 3DS' StreetPass data changes? 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) the 8bytes in the Nintendo tag changes?<br /> <br /> == StreetPass spoofing ==<br /> <br /> A streetpass "AP" was spoofed on a laptop with hostapd by setting the SSID to "Nintendo_3DS_continuous_scan_000", with the extra Nintendo tag from another 3DS' probe request. The SSID and AP can't be easily spoofed with hostapd for streetpass when 3DS is "active", for the random "ic[kSvm9s@*cYD>/~IEVj\(fGG;qDo8j" strings. The 3DS didn't seem to authenticate or associate with the "AP". Streetpass "AP" comms use '''WPA2''' encryption. Eventually the 3DS stops communicating with the fake "AP" since the AP doesn't understand the sent data,(especially since it's encrypted) and 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)<br /> Communication with two 3DSes are the same as above except there's encrypted data sent to/from both consoles, unlike the fake "AP".<br /> <br /> [[Category:Nintendo Software]]</div>

Seabrook https://www.3dbrew.org/w/index.php?title=StreetPass&diff=808 StreetPass 2011-06-16T23:27:54Z

<p>Seabrook: Adding next field. Suspecting software version.</p> <hr /> <div>'''StreetPass''' is a feature that allow your 3DS to connect with other 3DS using WiFi in standby mode.<br /> It can be used to share Mii(s) on Mii Plaza for example. Games' StreetPass data is stored on [[SD_Filesystem|SD card]] under [[extdata]], while Mii Plaza StreetPass data is stored on NAND. Not all StreetPass data is stored on SD card: "StreetPass Management" can still be used without a SD card inserted. Wifi infrastructure with APs are used to communicate, like WMB and multi-player.<br /> StreetPass in sleepmode can work without SD card inserted. Games' Streetpass data are temporarily stored in NAND, and when the games process the StreetPass data they move that data to extdata on SD card.<br /> <br /> == WiFi Probe Request Frame ==<br /> <br /> 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.<br /> <br /> The MAC address used for these probes is the static MAC address found in the 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.<br /> <br /> == StreetPass Probe Frame ==<br /> <br /> 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 frame also contains a custom Nintendo tag, the contents of this tag from different 3ds captures don't match. Probe responses contain the same Nintendo tag data as the probe requests from the same 3DS. The MAC address used in sleepmode seems to change every time there's a streetpass hit, as well as the last 8-bytes of the Nintendo tag data? The MAC address + 8 byte ID for StreetPass is seen to change every time the user enters and exits and Settings application.<br /> <br /> 0000 00 00 1a 00 2f 48 00 00 19 7d 19 de 2a 00 00 00 ..../H...}..*...<br /> 0010 12 16 9e 09 a0 00 c9 02 00 00 40 00 00 00 ff ff ..........@.....<br /> 0020 ff ff ff ff da 6b f7 22 f3 77 ff ff ff ff ff ff .....k.".w......<br /> 0030 40 77 00 20 4e 69 6e 74 65 6e 64 6f 5f 33 44 53 @w. Nintendo_3DS<br /> 0040 5f 63 6f 6e 74 69 6e 75 6f 75 73 5f 73 63 61 6e _continuous_scan<br /> 0050 5f 30 30 30 01 08 82 84 8b 0c 12 96 18 24 32 04 _000.........$2.<br /> 0060 30 48 60 6c dd 15 00 1f 32 01 11 05 00 02 08 00 0H`l....2.......<br /> 0070 00 f0 08 c8 34 6e 05 0f c9 c6 80 5b 6f bc 5a ....4n.....[o.Z<br /> <br /> 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 sleepmode, usually do StreetPass every <12 hours?<br /> <br /> When in standby mode the old DS WiFi is used, which includes SpotPass and StreetPass, but in "active" mode the regular DSi WiFi bus is used.<br /> <br /> === Nintendo Tag Format ===<br /> <br /> 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.<br /> <br /> {| class="wikitable" border="1"<br /> |-<br /> ! Offset<br /> ! Length<br /> ! Purpose<br /> ! Description<br /> | Example<br /> |-<br /> | 0x00<br /> | 0x01<br /> | '''Protocol identification'''<br /> | May be for protocol identification. All captures thus far show this value at 17, hexadecimal 11.<br /> | 11<br /> |-<br /> | 0x01<br /> | 0x01<br /> | '''StreetPass Service Length'''<br /> | Length in bytes of only the StreetPass Services field.<br /> | 05<br /> |-<br /> | 0x02<br /> | 0x05<br /> | '''StreetPass Services'''<br /> | 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.<br /> | 00 02 08 00 00<br /> |-<br /> | varies<br /> | 0x02<br /> | '''Unknown'''<br /> | 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. It may represent software version.<br /> | f008<br /> |-<br /> | -0x08<br /> | 0x08<br /> | '''StreetPass ID'''<br /> | 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?<br /> | 0f c9 c6 80 5b 6f bc 5a<br /> |}<br /> <br /> ==== Protocol Version ====<br /> <br /> 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.<br /> <br /> ==== StreetPass Service Length ====<br /> <br /> 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.<br /> <br /> ==== StreetPass Services ====<br /> <br /> 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:<br /> <br /> Mii Plaza: 00 02 08 00 00<br /> Sims 3: 00 03 65 00 30<br /> Street Fighter: 00 03 05 00 02 (FF FF FF FF FF FF)<br /> <br /> Some services have a 6-byte field preceding or 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.<br /> <br /> ==== Unknown 2-byte Field ====<br /> <br /> The purpose of this field is not known yet, although the likely use of it might be software version on the device. It has remained the same across all devices thus far. The value has always been observed as '''f008'''.<br /> <br /> ==== StreetPass ID ====<br /> <br /> When there's a StreetPass hit, and no StreetPass data changed on either of the 3DSes, no data is transferred besides probes? Perhaps there's some ID in the Nintendo tag that gets updated every-time the 3DS' StreetPass data changes? 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) the 8bytes in the Nintendo tag changes? <br /> <br /> == StreetPass spoofing ==<br /> <br /> A streetpass "AP" was spoofed on a laptop with hostapd by setting the SSID to "Nintendo_3DS_continuous_scan_000", with the extra Nintendo tag from another 3DS' probe request. The SSID and AP can't be easily spoofed with hostapd for streetpass when 3DS is "active", for the random "ic[kSvm9s@*cYD>/~IEVj\(fGG;qDo8j" strings. The 3DS didn't seem to authenticate or associate with the "AP". Streetpass "AP" comms use '''WPA2''' encryption. Eventually the 3DS stops communicating with the fake "AP" since the AP doesn't understand the sent data,(especially since it's encrypted) and 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)<br /> Communication with two 3DSes are the same as above except there's encrypted data sent to/from both consoles, unlike the fake "AP".<br /> <br /> [[Category:Nintendo Software]]</div>

Seabrook https://www.3dbrew.org/w/index.php?title=StreetPass&diff=807 StreetPass 2011-06-16T23:22:20Z

<p>Seabrook: Removing redundant text</p> <hr /> <div>'''StreetPass''' is a feature that allow your 3DS to connect with other 3DS using WiFi in standby mode.<br /> It can be used to share Mii(s) on Mii Plaza for example. Games' StreetPass data is stored on [[SD_Filesystem|SD card]] under [[extdata]], while Mii Plaza StreetPass data is stored on NAND. Not all StreetPass data is stored on SD card: "StreetPass Management" can still be used without a SD card inserted. Wifi infrastructure with APs are used to communicate, like WMB and multi-player.<br /> StreetPass in sleepmode can work without SD card inserted. Games' Streetpass data are temporarily stored in NAND, and when the games process the StreetPass data they move that data to extdata on SD card.<br /> <br /> == WiFi Probe Request Frame ==<br /> <br /> 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.<br /> <br /> The MAC address used for these probes is the static MAC address found in the 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.<br /> <br /> == StreetPass Probe Frame ==<br /> <br /> 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 frame also contains a custom Nintendo tag, the contents of this tag from different 3ds captures don't match. Probe responses contain the same Nintendo tag data as the probe requests from the same 3DS. The MAC address used in sleepmode seems to change every time there's a streetpass hit, as well as the last 8-bytes of the Nintendo tag data? The MAC address + 8 byte ID for StreetPass is seen to change every time the user enters and exits and Settings application.<br /> <br /> 0000 00 00 1a 00 2f 48 00 00 19 7d 19 de 2a 00 00 00 ..../H...}..*...<br /> 0010 12 16 9e 09 a0 00 c9 02 00 00 40 00 00 00 ff ff ..........@.....<br /> 0020 ff ff ff ff da 6b f7 22 f3 77 ff ff ff ff ff ff .....k.".w......<br /> 0030 40 77 00 20 4e 69 6e 74 65 6e 64 6f 5f 33 44 53 @w. Nintendo_3DS<br /> 0040 5f 63 6f 6e 74 69 6e 75 6f 75 73 5f 73 63 61 6e _continuous_scan<br /> 0050 5f 30 30 30 01 08 82 84 8b 0c 12 96 18 24 32 04 _000.........$2.<br /> 0060 30 48 60 6c dd 15 00 1f 32 01 11 05 00 02 08 00 0H`l....2.......<br /> 0070 00 f0 08 c8 34 6e 05 0f c9 c6 80 5b 6f bc 5a ....4n.....[o.Z<br /> <br /> 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 sleepmode, usually do StreetPass every <12 hours?<br /> <br /> When in standby mode the old DS WiFi is used, which includes SpotPass and StreetPass, but in "active" mode the regular DSi WiFi bus is used.<br /> <br /> === Nintendo Tag Format ===<br /> <br /> 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.<br /> <br /> {| class="wikitable" border="1"<br /> |-<br /> ! Offset<br /> ! Length<br /> ! Purpose<br /> ! Description<br /> | Example<br /> |-<br /> | 0x00<br /> | 0x01<br /> | '''Protocol identification'''<br /> | May be for protocol identification. All captures thus far show this value at 17, hexadecimal 11.<br /> | 11<br /> |-<br /> | 0x01<br /> | 0x01<br /> | '''StreetPass Service Length'''<br /> | Length in bytes of only the StreetPass Services field.<br /> | 05<br /> |-<br /> | 0x02<br /> | 0x05<br /> | '''StreetPass Services'''<br /> | 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.<br /> | 00 02 08 00 00<br /> |-<br /> | -0x08<br /> | 0x08<br /> | '''StreetPass ID'''<br /> | 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?<br /> | 0f c9 c6 80 5b 6f bc 5a<br /> |}<br /> <br /> ==== Protocol Version ====<br /> <br /> 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.<br /> <br /> ==== StreetPass Service Length ====<br /> <br /> 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.<br /> <br /> ==== StreetPass Services ====<br /> <br /> 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:<br /> <br /> Mii Plaza: 00 02 08 00 00<br /> Sims 3: 00 03 65 00 30<br /> Street Fighter: 00 03 05 00 02 (FF FF FF FF FF FF)<br /> <br /> Some services have a 6-byte field preceding or 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.<br /> <br /> ==== StreetPass ID ====<br /> <br /> When there's a StreetPass hit, and no StreetPass data changed on either of the 3DSes, no data is transferred besides probes? Perhaps there's some ID in the Nintendo tag that gets updated every-time the 3DS' StreetPass data changes? 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) the 8bytes in the Nintendo tag changes? <br /> <br /> == StreetPass spoofing ==<br /> <br /> A streetpass "AP" was spoofed on a laptop with hostapd by setting the SSID to "Nintendo_3DS_continuous_scan_000", with the extra Nintendo tag from another 3DS' probe request. The SSID and AP can't be easily spoofed with hostapd for streetpass when 3DS is "active", for the random "ic[kSvm9s@*cYD>/~IEVj\(fGG;qDo8j" strings. The 3DS didn't seem to authenticate or associate with the "AP". Streetpass "AP" comms use '''WPA2''' encryption. Eventually the 3DS stops communicating with the fake "AP" since the AP doesn't understand the sent data,(especially since it's encrypted) and 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)<br /> Communication with two 3DSes are the same as above except there's encrypted data sent to/from both consoles, unlike the fake "AP".<br /> <br /> [[Category:Nintendo Software]]</div>

Seabrook https://www.3dbrew.org/w/index.php?title=StreetPass&diff=806 StreetPass 2011-06-16T23:19:40Z

<p>Seabrook: Figured out second field.</p> <hr /> <div>'''StreetPass''' is a feature that allow your 3DS to connect with other 3DS using WiFi in standby mode.<br /> It can be used to share Mii(s) on Mii Plaza for example. Games' StreetPass data is stored on [[SD_Filesystem|SD card]] under [[extdata]], while Mii Plaza StreetPass data is stored on NAND. Not all StreetPass data is stored on SD card: "StreetPass Management" can still be used without a SD card inserted. Wifi infrastructure with APs are used to communicate, like WMB and multi-player.<br /> StreetPass in sleepmode can work without SD card inserted. Games' Streetpass data are temporarily stored in NAND, and when the games process the StreetPass data they move that data to extdata on SD card.<br /> <br /> == WiFi Probe Request Frame ==<br /> <br /> 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.<br /> <br /> The MAC address used for these probes is the static MAC address found in the 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.<br /> <br /> == StreetPass Probe Frame ==<br /> <br /> 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 frame also contains a custom Nintendo tag, the contents of this tag from different 3ds captures don't match. Probe responses contain the same Nintendo tag data as the probe requests from the same 3DS. The MAC address used in sleepmode seems to change every time there's a streetpass hit, as well as the last 8-bytes of the Nintendo tag data? The MAC address + 8 byte ID for StreetPass is seen to change every time the user enters and exits and Settings application.<br /> <br /> 0000 00 00 1a 00 2f 48 00 00 19 7d 19 de 2a 00 00 00 ..../H...}..*...<br /> 0010 12 16 9e 09 a0 00 c9 02 00 00 40 00 00 00 ff ff ..........@.....<br /> 0020 ff ff ff ff da 6b f7 22 f3 77 ff ff ff ff ff ff .....k.".w......<br /> 0030 40 77 00 20 4e 69 6e 74 65 6e 64 6f 5f 33 44 53 @w. Nintendo_3DS<br /> 0040 5f 63 6f 6e 74 69 6e 75 6f 75 73 5f 73 63 61 6e _continuous_scan<br /> 0050 5f 30 30 30 01 08 82 84 8b 0c 12 96 18 24 32 04 _000.........$2.<br /> 0060 30 48 60 6c dd 15 00 1f 32 01 11 05 00 02 08 00 0H`l....2.......<br /> 0070 00 f0 08 c8 34 6e 05 0f c9 c6 80 5b 6f bc 5a ....4n.....[o.Z<br /> <br /> 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 sleepmode, usually do StreetPass every <12 hours?<br /> <br /> When in standby mode the old DS WiFi is used, which includes SpotPass and StreetPass, but in "active" mode the regular DSi WiFi bus is used.<br /> <br /> === Nintendo Tag Format ===<br /> <br /> 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.<br /> <br /> {| class="wikitable" border="1"<br /> |-<br /> ! Offset<br /> ! Length<br /> ! Purpose<br /> ! Description<br /> | Example<br /> |-<br /> | 0x00<br /> | 0x01<br /> | '''Protocol identification'''<br /> | May be for protocol identification. All captures thus far show this value at 17, hexadecimal 11.<br /> | 11<br /> |-<br /> | 0x01<br /> | 0x01<br /> | '''StreetPass Service Length'''<br /> | Length in bytes of only the StreetPass Services field.<br /> | 05<br /> |-<br /> | 0x02<br /> | 0x05<br /> | '''StreetPass Services'''<br /> | 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.<br /> | 00 02 08 00 00<br /> |-<br /> | -0x08<br /> | 0x08<br /> | '''StreetPass ID'''<br /> | 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?<br /> | 0f c9 c6 80 5b 6f bc 5a<br /> |}<br /> <br /> ==== Protocol Version ====<br /> <br /> 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.<br /> <br /> ==== StreetPass Service Length ====<br /> <br /> This field is used to indicate the length of the variable length 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.<br /> <br /> ==== StreetPass Services ====<br /> <br /> 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:<br /> <br /> Mii Plaza: 00 02 08 00 00<br /> Sims 3: 00 03 65 00 30<br /> Street Fighter: 00 03 05 00 02 (FF FF FF FF FF FF)<br /> <br /> Some services have a 6-byte field preceding or 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.<br /> <br /> ==== StreetPass ID ====<br /> <br /> When there's a StreetPass hit, and no StreetPass data changed on either of the 3DSes, no data is transferred besides probes? Perhaps there's some ID in the Nintendo tag that gets updated every-time the 3DS' StreetPass data changes? 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) the 8bytes in the Nintendo tag changes? <br /> <br /> == StreetPass spoofing ==<br /> <br /> A streetpass "AP" was spoofed on a laptop with hostapd by setting the SSID to "Nintendo_3DS_continuous_scan_000", with the extra Nintendo tag from another 3DS' probe request. The SSID and AP can't be easily spoofed with hostapd for streetpass when 3DS is "active", for the random "ic[kSvm9s@*cYD>/~IEVj\(fGG;qDo8j" strings. The 3DS didn't seem to authenticate or associate with the "AP". Streetpass "AP" comms use '''WPA2''' encryption. Eventually the 3DS stops communicating with the fake "AP" since the AP doesn't understand the sent data,(especially since it's encrypted) and 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)<br /> Communication with two 3DSes are the same as above except there's encrypted data sent to/from both consoles, unlike the fake "AP".<br /> <br /> [[Category:Nintendo Software]]</div>

Seabrook https://www.3dbrew.org/w/index.php?title=StreetPass&diff=805 StreetPass 2011-06-16T23:12:39Z

<p>Seabrook: </p> <hr /> <div>'''StreetPass''' is a feature that allow your 3DS to connect with other 3DS using WiFi in standby mode.<br /> It can be used to share Mii(s) on Mii Plaza for example. Games' StreetPass data is stored on [[SD_Filesystem|SD card]] under [[extdata]], while Mii Plaza StreetPass data is stored on NAND. Not all StreetPass data is stored on SD card: "StreetPass Management" can still be used without a SD card inserted. Wifi infrastructure with APs are used to communicate, like WMB and multi-player.<br /> StreetPass in sleepmode can work without SD card inserted. Games' Streetpass data are temporarily stored in NAND, and when the games process the StreetPass data they move that data to extdata on SD card.<br /> <br /> == WiFi Probe Request Frame ==<br /> <br /> 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.<br /> <br /> The MAC address used for these probes is the static MAC address found in the 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.<br /> <br /> == StreetPass Probe Frame ==<br /> <br /> 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 frame also contains a custom Nintendo tag, the contents of this tag from different 3ds captures don't match. Probe responses contain the same Nintendo tag data as the probe requests from the same 3DS. The MAC address used in sleepmode seems to change every time there's a streetpass hit, as well as the last 8-bytes of the Nintendo tag data? The MAC address + 8 byte ID for StreetPass is seen to change every time the user enters and exits and Settings application.<br /> <br /> 0000 00 00 1a 00 2f 48 00 00 19 7d 19 de 2a 00 00 00 ..../H...}..*...<br /> 0010 12 16 9e 09 a0 00 c9 02 00 00 40 00 00 00 ff ff ..........@.....<br /> 0020 ff ff ff ff da 6b f7 22 f3 77 ff ff ff ff ff ff .....k.".w......<br /> 0030 40 77 00 20 4e 69 6e 74 65 6e 64 6f 5f 33 44 53 @w. Nintendo_3DS<br /> 0040 5f 63 6f 6e 74 69 6e 75 6f 75 73 5f 73 63 61 6e _continuous_scan<br /> 0050 5f 30 30 30 01 08 82 84 8b 0c 12 96 18 24 32 04 _000.........$2.<br /> 0060 30 48 60 6c dd 15 00 1f 32 01 11 05 00 02 08 00 0H`l....2.......<br /> 0070 00 f0 08 c8 34 6e 05 0f c9 c6 80 5b 6f bc 5a ....4n.....[o.Z<br /> <br /> 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 sleepmode, usually do StreetPass every <12 hours?<br /> <br /> When in standby mode the old DS WiFi is used, which includes SpotPass and StreetPass, but in "active" mode the regular DSi WiFi bus is used.<br /> <br /> === Nintendo Tag Format ===<br /> <br /> 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.<br /> <br /> {| class="wikitable" border="1"<br /> |-<br /> ! Offset<br /> ! Length<br /> ! Purpose<br /> ! Description<br /> | Example<br /> |-<br /> | 0x00<br /> | 0x01<br /> | '''Protocol identification'''<br /> | May be for protocol identification. All captures thus far show this value at 17, hexadecimal 11.<br /> | 11<br /> |-<br /> | 0x01<br /> | 0x01<br /> | '''Unknown'''<br /> | Seems to vary by device, but stays consistent and doesn't change between Street Passes. May be a length or counter field in relation to the next set of fields. Removal of a service caused the value in the field to decrease.<br /> | 05<br /> |-<br /> | 0x02<br /> | 0x05<br /> | '''StreetPass Services'''<br /> | 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.<br /> | 00 02 08 00 00<br /> |-<br /> | -0x08<br /> | 0x08<br /> | '''StreetPass ID'''<br /> | 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?<br /> | 0f c9 c6 80 5b 6f bc 5a<br /> |}<br /> <br /> ==== Protocol Version ====<br /> <br /> 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.<br /> <br /> ==== Unknown Field ====<br /> <br /> As mentioned, possibly a length field for the StreetPass services.<br /> <br /> ==== StreetPass Services ====<br /> <br /> 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:<br /> <br /> Mii Plaza: 00 02 08 00 00<br /> Sims 3: 00 03 65 00 30<br /> Street Fighter: 00 03 05 00 02 (FF FF FF FF FF FF)<br /> <br /> Some services have a 6-byte field preceding or 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.<br /> <br /> ==== StreetPass ID ====<br /> <br /> When there's a StreetPass hit, and no StreetPass data changed on either of the 3DSes, no data is transferred besides probes? Perhaps there's some ID in the Nintendo tag that gets updated every-time the 3DS' StreetPass data changes? 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) the 8bytes in the Nintendo tag changes? <br /> <br /> == StreetPass spoofing ==<br /> <br /> A streetpass "AP" was spoofed on a laptop with hostapd by setting the SSID to "Nintendo_3DS_continuous_scan_000", with the extra Nintendo tag from another 3DS' probe request. The SSID and AP can't be easily spoofed with hostapd for streetpass when 3DS is "active", for the random "ic[kSvm9s@*cYD>/~IEVj\(fGG;qDo8j" strings. The 3DS didn't seem to authenticate or associate with the "AP". Streetpass "AP" comms use '''WPA2''' encryption. Eventually the 3DS stops communicating with the fake "AP" since the AP doesn't understand the sent data,(especially since it's encrypted) and 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)<br /> Communication with two 3DSes are the same as above except there's encrypted data sent to/from both consoles, unlike the fake "AP".<br /> <br /> [[Category:Nintendo Software]]</div>

Seabrook https://www.3dbrew.org/w/index.php?title=StreetPass&diff=804 StreetPass 2011-06-16T23:10:34Z

<p>Seabrook: Added confirmed services thus far.</p> <hr /> <div>'''StreetPass''' is a feature that allow your 3DS to connect with other 3DS using WiFi in standby mode.<br /> It can be used to share Mii(s) on Mii Plaza for example. Games' StreetPass data is stored on [[SD_Filesystem|SD card]] under [[extdata]], while Mii Plaza StreetPass data is stored on NAND. Not all StreetPass data is stored on SD card: "StreetPass Management" can still be used without a SD card inserted. Wifi infrastructure with APs are used to communicate, like WMB and multi-player.<br /> StreetPass in sleepmode can work without SD card inserted. Games' Streetpass data are temporarily stored in NAND, and when the games process the StreetPass data they move that data to extdata on SD card.<br /> <br /> == WiFi Probe Request Frame ==<br /> <br /> 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.<br /> <br /> The MAC address used for these probes is the static MAC address found in the 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.<br /> <br /> == StreetPass Probe Frame ==<br /> <br /> 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 frame also contains a custom Nintendo tag, the contents of this tag from different 3ds captures don't match. Probe responses contain the same Nintendo tag data as the probe requests from the same 3DS. The MAC address used in sleepmode seems to change every time there's a streetpass hit, as well as the last 8-bytes of the Nintendo tag data? The MAC address + 8 byte ID for StreetPass is seen to change every time the user enters and exits and Settings application.<br /> <br /> 0000 00 00 1a 00 2f 48 00 00 19 7d 19 de 2a 00 00 00 ..../H...}..*...<br /> 0010 12 16 9e 09 a0 00 c9 02 00 00 40 00 00 00 ff ff ..........@.....<br /> 0020 ff ff ff ff da 6b f7 22 f3 77 ff ff ff ff ff ff .....k.".w......<br /> 0030 40 77 00 20 4e 69 6e 74 65 6e 64 6f 5f 33 44 53 @w. Nintendo_3DS<br /> 0040 5f 63 6f 6e 74 69 6e 75 6f 75 73 5f 73 63 61 6e _continuous_scan<br /> 0050 5f 30 30 30 01 08 82 84 8b 0c 12 96 18 24 32 04 _000.........$2.<br /> 0060 30 48 60 6c dd 15 00 1f 32 01 11 05 00 02 08 00 0H`l....2.......<br /> 0070 00 f0 08 c8 34 6e 05 0f c9 c6 80 5b 6f bc 5a ....4n.....[o.Z<br /> <br /> 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 sleepmode, usually do StreetPass every <12 hours?<br /> <br /> When in standby mode the old DS WiFi is used, which includes SpotPass and StreetPass, but in "active" mode the regular DSi WiFi bus is used.<br /> <br /> === Nintendo Tag Format ===<br /> <br /> 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.<br /> <br /> {| class="wikitable" border="1"<br /> |-<br /> ! Offset<br /> ! Length<br /> ! Purpose<br /> ! Description<br /> | Example<br /> |-<br /> | 0x00<br /> | 0x01<br /> | '''Protocol identification'''<br /> | May be for protocol identification. All captures thus far show this value at 17, hexadecimal 11.<br /> | 11<br /> |-<br /> | 0x01<br /> | 0x01<br /> | '''Unknown'''<br /> | Seems to vary by device, but stays consistent and doesn't change between Street Passes. May be a length or counter field in relation to the next set of fields.<br /> | 05<br /> |-<br /> | 0x02<br /> | 0x05<br /> | '''StreetPass Services'''<br /> | 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.<br /> | 00 02 08 00 00<br /> |-<br /> | -0x08<br /> | 0x08<br /> | '''StreetPass ID'''<br /> | 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?<br /> | 0f c9 c6 80 5b 6f bc 5a<br /> |}<br /> <br /> ==== Protocol Version ====<br /> <br /> 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.<br /> <br /> ==== Unknown Field ====<br /> <br /> As mentioned, possibly a length field for the StreetPass services.<br /> <br /> ==== StreetPass Services ====<br /> <br /> 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:<br /> <br /> Mii Plaza: 00 02 08 00 00<br /> Sims 3: 00 03 65 00 30<br /> Street Fighter: 00 03 05 00 02 (FF FF FF FF FF FF)<br /> <br /> Some services have a 6-byte field preceding or 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.<br /> <br /> ==== StreetPass ID ====<br /> <br /> When there's a StreetPass hit, and no StreetPass data changed on either of the 3DSes, no data is transferred besides probes? Perhaps there's some ID in the Nintendo tag that gets updated every-time the 3DS' StreetPass data changes? 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) the 8bytes in the Nintendo tag changes? <br /> <br /> == StreetPass spoofing ==<br /> <br /> A streetpass "AP" was spoofed on a laptop with hostapd by setting the SSID to "Nintendo_3DS_continuous_scan_000", with the extra Nintendo tag from another 3DS' probe request. The SSID and AP can't be easily spoofed with hostapd for streetpass when 3DS is "active", for the random "ic[kSvm9s@*cYD>/~IEVj\(fGG;qDo8j" strings. The 3DS didn't seem to authenticate or associate with the "AP". Streetpass "AP" comms use '''WPA2''' encryption. Eventually the 3DS stops communicating with the fake "AP" since the AP doesn't understand the sent data,(especially since it's encrypted) and 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)<br /> Communication with two 3DSes are the same as above except there's encrypted data sent to/from both consoles, unlike the fake "AP".<br /> <br /> [[Category:Nintendo Software]]</div>

Seabrook https://www.3dbrew.org/w/index.php?title=StreetPass&diff=802 StreetPass 2011-06-16T22:55:51Z

<p>Seabrook: </p> <hr /> <div>'''StreetPass''' is a feature that allow your 3DS to connect with other 3DS using WiFi in standby mode.<br /> It can be used to share Mii(s) on Mii Plaza for example. Games' StreetPass data is stored on [[SD_Filesystem|SD card]] under [[extdata]], while Mii Plaza StreetPass data is stored on NAND. Not all StreetPass data is stored on SD card: "StreetPass Management" can still be used without a SD card inserted. Wifi infrastructure with APs are used to communicate, like WMB and multi-player.<br /> StreetPass in sleepmode can work without SD card inserted. Games' Streetpass data are temporarily stored in NAND, and when the games process the StreetPass data they move that data to extdata on SD card.<br /> <br /> == WiFi Probe Request Frame ==<br /> <br /> 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.<br /> <br /> The MAC address used for these probes is the static MAC address found in the 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.<br /> <br /> == StreetPass Probe Frame ==<br /> <br /> 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 frame also contains a custom Nintendo tag, the contents of this tag from different 3ds captures don't match. Probe responses contain the same Nintendo tag data as the probe requests from the same 3DS. The MAC address used in sleepmode seems to change every time there's a streetpass hit, as well as the last 8-bytes of the Nintendo tag data? The MAC address + 8 byte ID for StreetPass is seen to change every time the user enters and exits and Settings application.<br /> <br /> 0000 00 00 1a 00 2f 48 00 00 19 7d 19 de 2a 00 00 00 ..../H...}..*...<br /> 0010 12 16 9e 09 a0 00 c9 02 00 00 40 00 00 00 ff ff ..........@.....<br /> 0020 ff ff ff ff da 6b f7 22 f3 77 ff ff ff ff ff ff .....k.".w......<br /> 0030 40 77 00 20 4e 69 6e 74 65 6e 64 6f 5f 33 44 53 @w. Nintendo_3DS<br /> 0040 5f 63 6f 6e 74 69 6e 75 6f 75 73 5f 73 63 61 6e _continuous_scan<br /> 0050 5f 30 30 30 01 08 82 84 8b 0c 12 96 18 24 32 04 _000.........$2.<br /> 0060 30 48 60 6c dd 15 00 1f 32 01 11 05 00 02 08 00 0H`l....2.......<br /> 0070 00 f0 08 c8 34 6e 05 0f c9 c6 80 5b 6f bc 5a ....4n.....[o.Z<br /> <br /> 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 sleepmode, usually do StreetPass every <12 hours?<br /> <br /> When in standby mode the old DS WiFi is used, which includes SpotPass and StreetPass, but in "active" mode the regular DSi WiFi bus is used.<br /> <br /> === Nintendo Tag Format ===<br /> <br /> 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.<br /> <br /> {| class="wikitable" border="1"<br /> |-<br /> ! Offset<br /> ! Length<br /> ! Purpose<br /> ! Description<br /> | Example<br /> |-<br /> | 0x00<br /> | 0x01<br /> | '''Protocol identification'''<br /> | May be for protocol identification. All captures thus far show this value at 17, hexadecimal 11.<br /> | 11<br /> |-<br /> | 0x01<br /> | 0x01<br /> | '''Unknown'''<br /> | Seems to vary by device, but stays consistent and doesn't change between Street Passes. May be a length or counter field in relation to the next set of fields.<br /> | 05<br /> |-<br /> | 0x02<br /> | 0x05<br /> | '''StreetPass Services'''<br /> | 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.<br /> | 00 02 08 00 00<br /> |-<br /> | -0x08<br /> | 0x08<br /> | '''StreetPass ID'''<br /> | 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?<br /> | 0f c9 c6 80 5b 6f bc 5a<br /> |}<br /> <br /> ==== Protocol Version ====<br /> <br /> 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.<br /> <br /> ==== Unknown Field ====<br /> <br /> As mentioned, possibly a length field for the StreetPass services.<br /> <br /> ==== StreetPass Services ====<br /> <br /> 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. Observed service IDs include, '''Mii Plaza''': 00 02 08 00 00.<br /> <br /> Some services have a 6-byte field preceding or 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.<br /> <br /> ==== StreetPass ID ====<br /> <br /> When there's a StreetPass hit, and no StreetPass data changed on either of the 3DSes, no data is transferred besides probes? Perhaps there's some ID in the Nintendo tag that gets updated every-time the 3DS' StreetPass data changes? 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) the 8bytes in the Nintendo tag changes? <br /> <br /> == StreetPass spoofing ==<br /> <br /> A streetpass "AP" was spoofed on a laptop with hostapd by setting the SSID to "Nintendo_3DS_continuous_scan_000", with the extra Nintendo tag from another 3DS' probe request. The SSID and AP can't be easily spoofed with hostapd for streetpass when 3DS is "active", for the random "ic[kSvm9s@*cYD>/~IEVj\(fGG;qDo8j" strings. The 3DS didn't seem to authenticate or associate with the "AP". Streetpass "AP" comms use '''WPA2''' encryption. Eventually the 3DS stops communicating with the fake "AP" since the AP doesn't understand the sent data,(especially since it's encrypted) and 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)<br /> Communication with two 3DSes are the same as above except there's encrypted data sent to/from both consoles, unlike the fake "AP".<br /> <br /> [[Category:Nintendo Software]]</div>

Seabrook https://www.3dbrew.org/w/index.php?title=StreetPass&diff=788 StreetPass 2011-06-16T03:45:16Z

<p>Seabrook: </p> <hr /> <div>'''StreetPass''' is a feature that allow your 3DS to connect with other 3DS using WiFi in standby mode.<br /> It can be used to share Mii(s) on Mii Plaza for example. Games' StreetPass data is stored on [[SD_Filesystem|SD card]] under [[extdata]], while Mii Plaza StreetPass data is stored on NAND. Not all StreetPass data is stored on SD card: "StreetPass Management" can still be used without a SD card inserted. Wifi infrastructure with APs are used to communicate, like WMB and multi-player.<br /> StreetPass in sleepmode can work without SD card inserted. Games' Streetpass data are temporarily stored in NAND, and when the games process the StreetPass data they move that data to extdata on SD card.<br /> <br /> == WiFi Probe Request Frame ==<br /> <br /> 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". The probe may be related to the 3DS looking for Nintendo Zone APs. This string changes at least daily, and most likely every time the device is woken up.<br /> <br /> The MAC address used for these probes is the static MAC address found in the 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.<br /> <br /> == StreetPass Probe Frame ==<br /> <br /> 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 frame also contains a custom Nintendo tag, the contents of this tag from different 3ds captures don't match. Probe responses contain the same Nintendo tag data as the probe requests from the same 3DS. The MAC address used in sleepmode seems to change every time there's a streetpass hit, as well as the last 8-bytes of the Nintendo tag data? The MAC address + 8 byte ID for StreetPass is seen to change every time the user enters and exits and Settings application.<br /> <br /> 0000 00 00 1a 00 2f 48 00 00 19 7d 19 de 2a 00 00 00 ..../H...}..*...<br /> 0010 12 16 9e 09 a0 00 c9 02 00 00 40 00 00 00 ff ff ..........@.....<br /> 0020 ff ff ff ff da 6b f7 22 f3 77 ff ff ff ff ff ff .....k.".w......<br /> 0030 40 77 00 20 4e 69 6e 74 65 6e 64 6f 5f 33 44 53 @w. Nintendo_3DS<br /> 0040 5f 63 6f 6e 74 69 6e 75 6f 75 73 5f 73 63 61 6e _continuous_scan<br /> 0050 5f 30 30 30 01 08 82 84 8b 0c 12 96 18 24 32 04 _000.........$2.<br /> 0060 30 48 60 6c dd 15 00 1f 32 01 11 05 00 02 08 00 0H`l....2.......<br /> 0070 00 f0 08 c8 34 6e 05 0f c9 c6 80 5b 6f bc 5a ....4n.....[o.Z<br /> <br /> 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 sleepmode, usually do StreetPass every <12 hours?<br /> <br /> When in standby mode the old DS WiFi is used, which includes SpotPass and StreetPass, but in "active" mode the regular DSi WiFi bus is used.<br /> <br /> === Nintendo Tag Format ===<br /> <br /> 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.<br /> <br /> {| class="wikitable" border="1"<br /> |-<br /> ! Offset<br /> ! Length<br /> ! Purpose<br /> ! Description<br /> | Example<br /> |-<br /> | 0x00<br /> | 0x01<br /> | '''Protocol identification'''<br /> | May be for protocol identification. All captures thus far show this value at 17, hexadecimal 11.<br /> | 11<br /> |-<br /> | 0x01<br /> | 0x01<br /> | '''Unknown'''<br /> | Seems to vary by device, but stays consistent and doesn't change between Street Passes. May be a length or counter field in relation to the next set of fields.<br /> | 05<br /> |-<br /> | 0x02<br /> | 0x05<br /> | '''StreetPass Services'''<br /> | 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.<br /> | 00 02 08 00 00<br /> |-<br /> | -0x08<br /> | 0x08<br /> | '''StreetPass ID'''<br /> | Seen to change after every time the Settings app is used. Also may change after each StreetPass hit and system power-off?<br /> | 0f c9 c6 80 5b 6f bc 5a<br /> |}<br /> <br /> ==== Protocol Version ====<br /> <br /> 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.<br /> <br /> ==== Unknown Field ====<br /> <br /> As mentioned, possibly a length field for the StreetPass services.<br /> <br /> ==== StreetPass Services ====<br /> <br /> 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. Observed service IDs include, '''Mii Plaza''': 00 02 08 00 00.<br /> <br /> Some services have a 6-byte field preceding or 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.<br /> <br /> ==== StreetPass ID ====<br /> <br /> When there's a StreetPass hit, and no StreetPass data changed on either of the 3DSes, no data is transferred besides probes? Perhaps there's some ID in the Nintendo tag that gets updated every-time the 3DS' StreetPass data changes? 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) the 8bytes in the Nintendo tag changes? <br /> <br /> == StreetPass spoofing ==<br /> <br /> A streetpass "AP" was spoofed on a laptop with hostapd by setting the SSID to "Nintendo_3DS_continuous_scan_000", with the extra Nintendo tag from another 3DS' probe request. The SSID and AP can't be easily spoofed with hostapd for streetpass when 3DS is "active", for the random "ic[kSvm9s@*cYD>/~IEVj\(fGG;qDo8j" strings. The 3DS didn't seem to authenticate or associate with the "AP". Streetpass "AP" comms use '''WPA2''' encryption. Eventually the 3DS stops communicating with the fake "AP" since the AP doesn't understand the sent data,(especially since it's encrypted) and 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)<br /> Communication with two 3DSes are the same as above except there's encrypted data sent to/from both consoles, unlike the fake "AP".<br /> <br /> [[Category:Nintendo Software]]</div>

Seabrook https://www.3dbrew.org/w/index.php?title=StreetPass&diff=787 StreetPass 2011-06-16T03:40:24Z

<p>Seabrook: </p> <hr /> <div>'''StreetPass''' is a feature that allow your 3DS to connect with other 3DS using WiFi in standby mode.<br /> It can be used to share Mii(s) on Mii Plaza for example. Games' StreetPass data is stored on [[SD_Filesystem|SD card]] under [[extdata]], while Mii Plaza StreetPass data is stored on NAND. Not all StreetPass data is stored on SD card: "StreetPass Management" can still be used without a SD card inserted. Wifi infrastructure with APs are used to communicate, like WMB and multi-player.<br /> StreetPass in sleepmode can work without SD card inserted. Games' Streetpass data are temporarily stored in NAND, and when the games process the StreetPass data they move that data to extdata on SD card.<br /> <br /> == WiFi Probe Request Frame ==<br /> <br /> 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". The probe may be related to the 3DS looking for Nintendo Zone APs. This string changes at least daily, and most likely every time the device is woken up.<br /> <br /> The MAC address used for these probes is the static MAC address found in the 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.<br /> <br /> == StreetPass Probe Frame ==<br /> <br /> 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 frame also contains a custom Nintendo tag, the contents of this tag from different 3ds captures don't match. Probe responses contain the same Nintendo tag data as the probe requests from the same 3DS. The MAC address used in sleepmode seems to change every time there's a streetpass hit, as well as the last 8-bytes of the Nintendo tag data? The MAC address + 8 byte ID for StreetPass is seen to change every time the user enters and exits and Settings application.<br /> <br /> 0000 00 00 1a 00 2f 48 00 00 19 7d 19 de 2a 00 00 00 ..../H...}..*...<br /> 0010 12 16 9e 09 a0 00 c9 02 00 00 40 00 00 00 ff ff ..........@.....<br /> 0020 ff ff ff ff da 6b f7 22 f3 77 ff ff ff ff ff ff .....k.".w......<br /> 0030 40 77 00 20 4e 69 6e 74 65 6e 64 6f 5f 33 44 53 @w. Nintendo_3DS<br /> 0040 5f 63 6f 6e 74 69 6e 75 6f 75 73 5f 73 63 61 6e _continuous_scan<br /> 0050 5f 30 30 30 01 08 82 84 8b 0c 12 96 18 24 32 04 _000.........$2.<br /> 0060 30 48 60 6c dd 15 00 1f 32 01 11 05 00 02 08 00 0H`l....2.......<br /> 0070 00 f0 08 c8 34 6e 05 0f c9 c6 80 5b 6f bc 5a ....4n.....[o.Z<br /> <br /> 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 sleepmode, usually do StreetPass every <12 hours?<br /> <br /> When in standby mode the old DS WiFi is used, which includes SpotPass and StreetPass, but in "active" mode the regular DSi WiFi bus is used.<br /> <br /> === Nintendo Tag Format ===<br /> <br /> 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.<br /> <br /> {| class="wikitable" border="1"<br /> |-<br /> ! Offset<br /> ! Length<br /> ! Purpose<br /> ! Description<br /> | Example<br /> |-<br /> | 0x00<br /> | 0x01<br /> | '''Protocol Version'''<br /> | May be for protocol version or identification. All captures thus far show this value at 17, hexadecimal 11.<br /> | 11<br /> |-<br /> | 0x01<br /> | 0x01<br /> | '''Unknown'''<br /> | Seems to vary by device, but stays consistent and doesn't change between Street Passes. May be a length or counter field in relation to the next set of fields.<br /> | 05<br /> |-<br /> | 0x02<br /> | 0x05<br /> | '''StreetPass Services'''<br /> | 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.<br /> | 00 02 08 00 00<br /> |-<br /> | -0x08<br /> | 0x08<br /> | '''StreetPass ID'''<br /> | Seen to change after every time the Settings app is used. Also may change after each StreetPass hit and system power-off?<br /> | 0f c9 c6 80 5b 6f bc 5a<br /> |}<br /> <br /> ==== Identification String ====<br /> <br /> Defined the entire Nintendo tag with the exception of the StreetPass ID. It's purpose is unknown at the moment, but the length appears to vary from 3DS to 3DS.<br /> <br /> ==== Unknown Field ====<br /> <br /> As mentioned, possible a length field for the StreetPass services.<br /> <br /> ==== StreetPass Services ====<br /> <br /> 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. Observed service IDs include, '''Mii Plaza''': 00 02 08 00 00, and '''Sims 3''': 00 03 65 00 30.<br /> <br /> Some services have a 6-byte field preceding or 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.<br /> <br /> ==== StreetPass ID ====<br /> <br /> When there's a StreetPass hit, and no StreetPass data changed on either of the 3DSes, no data is transferred besides probes? Perhaps there's some ID in the Nintendo tag that gets updated every-time the 3DS' StreetPass data changes? 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) the 8bytes in the Nintendo tag changes? <br /> <br /> == StreetPass spoofing ==<br /> <br /> A streetpass "AP" was spoofed on a laptop with hostapd by setting the SSID to "Nintendo_3DS_continuous_scan_000", with the extra Nintendo tag from another 3DS' probe request. The SSID and AP can't be easily spoofed with hostapd for streetpass when 3DS is "active", for the random "ic[kSvm9s@*cYD>/~IEVj\(fGG;qDo8j" strings. The 3DS didn't seem to authenticate or associate with the "AP". Streetpass "AP" comms use '''WPA2''' encryption. Eventually the 3DS stops communicating with the fake "AP" since the AP doesn't understand the sent data,(especially since it's encrypted) and 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)<br /> Communication with two 3DSes are the same as above except there's encrypted data sent to/from both consoles, unlike the fake "AP".<br /> <br /> [[Category:Nintendo Software]]</div>

Seabrook https://www.3dbrew.org/w/index.php?title=StreetPass&diff=786 StreetPass 2011-06-16T03:38:44Z

<p>Seabrook: Wiki markup fix.</p> <hr /> <div>'''StreetPass''' is a feature that allow your 3DS to connect with other 3DS using WiFi in standby mode.<br /> It can be used to share Mii(s) on Mii Plaza for example. Games' StreetPass data is stored on [[SD_Filesystem|SD card]] under [[extdata]], while Mii Plaza StreetPass data is stored on NAND. Not all StreetPass data is stored on SD card: "StreetPass Management" can still be used without a SD card inserted. Wifi infrastructure with APs are used to communicate, like WMB and multi-player.<br /> StreetPass in sleepmode can work without SD card inserted. Games' Streetpass data are temporarily stored in NAND, and when the games process the StreetPass data they move that data to extdata on SD card.<br /> <br /> == WiFi Probe Request Frame ==<br /> <br /> 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". The probe may be related to the 3DS looking for Nintendo Zone APs. This string changes at least daily, and most likely every time the device is woken up.<br /> <br /> The MAC address used for these probes is the static MAC address found in the 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.<br /> <br /> == StreetPass Probe Frame ==<br /> <br /> 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 frame also contains a custom Nintendo tag, the contents of this tag from different 3ds captures don't match. Probe responses contain the same Nintendo tag data as the probe requests from the same 3DS. The MAC address used in sleepmode seems to change every time there's a streetpass hit, as well as the last 8-bytes of the Nintendo tag data? The MAC address + 8 byte ID for StreetPass is seen to change every time the user enters and exits and Settings application.<br /> <br /> 0000 00 00 1a 00 2f 48 00 00 19 7d 19 de 2a 00 00 00 ..../H...}..*...<br /> 0010 12 16 9e 09 a0 00 c9 02 00 00 40 00 00 00 ff ff ..........@.....<br /> 0020 ff ff ff ff da 6b f7 22 f3 77 ff ff ff ff ff ff .....k.".w......<br /> 0030 40 77 00 20 4e 69 6e 74 65 6e 64 6f 5f 33 44 53 @w. Nintendo_3DS<br /> 0040 5f 63 6f 6e 74 69 6e 75 6f 75 73 5f 73 63 61 6e _continuous_scan<br /> 0050 5f 30 30 30 01 08 82 84 8b 0c 12 96 18 24 32 04 _000.........$2.<br /> 0060 30 48 60 6c dd 15 00 1f 32 01 11 05 00 02 08 00 0H`l....2.......<br /> 0070 00 f0 08 c8 34 6e 05 0f c9 c6 80 5b 6f bc 5a ....4n.....[o.Z<br /> <br /> 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 sleepmode, usually do StreetPass every <12 hours?<br /> <br /> When in standby mode the old DS WiFi is used, which includes SpotPass and StreetPass, but in "active" mode the regular DSi WiFi bus is used.<br /> <br /> === Nintendo Tag Format ===<br /> <br /> 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.<br /> <br /> {| class="wikitable" border="1"<br /> |-<br /> ! Offset<br /> ! Length<br /> ! Purpose<br /> ! Description<br /> | Example<br /> |-<br /> | 0x00<br /> | 0x01<br /> | '''Protocol identification'''<br /> | May be for protocol identification. All captures thus far show this value at 17, hexadecimal 11.<br /> | 11<br /> |-<br /> | 0x01<br /> | 0x01<br /> | '''Unknown'''<br /> | Seems to vary by device, but stays consistent and doesn't change between Street Passes. May be a length or counter field in relation to the next set of fields.<br /> | 05<br /> |-<br /> | 0x02<br /> | 0x05<br /> | '''StreetPass Services'''<br /> | 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.<br /> | 00 02 08 00 00<br /> |-<br /> | -0x08<br /> | 0x08<br /> | '''StreetPass ID'''<br /> | Seen to change after every time the Settings app is used. Also may change after each StreetPass hit and system power-off?<br /> | 0f c9 c6 80 5b 6f bc 5a<br /> |}<br /> <br /> ==== Identification String ====<br /> <br /> Defined the entire Nintendo tag with the exception of the StreetPass ID. It's purpose is unknown at the moment, but the length appears to vary from 3DS to 3DS.<br /> <br /> ==== Unknown Field ====<br /> <br /> As mentioned, possible a length field for the StreetPass services.<br /> <br /> ==== StreetPass Services ====<br /> <br /> 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. Observed service IDs include, '''Mii Plaza''': 00 02 08 00 00, and '''Sims 3''': 00 03 65 00 30.<br /> <br /> Some services have a 6-byte field preceding or 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.<br /> <br /> ==== StreetPass ID ====<br /> <br /> When there's a StreetPass hit, and no StreetPass data changed on either of the 3DSes, no data is transferred besides probes? Perhaps there's some ID in the Nintendo tag that gets updated every-time the 3DS' StreetPass data changes? 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) the 8bytes in the Nintendo tag changes? <br /> <br /> == StreetPass spoofing ==<br /> <br /> A streetpass "AP" was spoofed on a laptop with hostapd by setting the SSID to "Nintendo_3DS_continuous_scan_000", with the extra Nintendo tag from another 3DS' probe request. The SSID and AP can't be easily spoofed with hostapd for streetpass when 3DS is "active", for the random "ic[kSvm9s@*cYD>/~IEVj\(fGG;qDo8j" strings. The 3DS didn't seem to authenticate or associate with the "AP". Streetpass "AP" comms use '''WPA2''' encryption. Eventually the 3DS stops communicating with the fake "AP" since the AP doesn't understand the sent data,(especially since it's encrypted) and 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)<br /> Communication with two 3DSes are the same as above except there's encrypted data sent to/from both consoles, unlike the fake "AP".<br /> <br /> [[Category:Nintendo Software]]</div>

Seabrook https://www.3dbrew.org/w/index.php?title=StreetPass&diff=785 StreetPass 2011-06-16T03:35:58Z

<p>Seabrook: Expanded Nintento Tag Format section based on observations.</p> <hr /> <div>'''StreetPass''' is a feature that allow your 3DS to connect with other 3DS using WiFi in standby mode.<br /> It can be used to share Mii(s) on Mii Plaza for example. Games' StreetPass data is stored on [[SD_Filesystem|SD card]] under [[extdata]], while Mii Plaza StreetPass data is stored on NAND. Not all StreetPass data is stored on SD card: "StreetPass Management" can still be used without a SD card inserted. Wifi infrastructure with APs are used to communicate, like WMB and multi-player.<br /> StreetPass in sleepmode can work without SD card inserted. Games' Streetpass data are temporarily stored in NAND, and when the games process the StreetPass data they move that data to extdata on SD card.<br /> <br /> == WiFi Probe Request Frame ==<br /> <br /> 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". The probe may be related to the 3DS looking for Nintendo Zone APs. This string changes at least daily, and most likely every time the device is woken up.<br /> <br /> The MAC address used for these probes is the static MAC address found in the 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.<br /> <br /> == StreetPass Probe Frame ==<br /> <br /> 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 frame also contains a custom Nintendo tag, the contents of this tag from different 3ds captures don't match. Probe responses contain the same Nintendo tag data as the probe requests from the same 3DS. The MAC address used in sleepmode seems to change every time there's a streetpass hit, as well as the last 8-bytes of the Nintendo tag data? The MAC address + 8 byte ID for StreetPass is seen to change every time the user enters and exits and Settings application.<br /> <br /> 0000 00 00 1a 00 2f 48 00 00 19 7d 19 de 2a 00 00 00 ..../H...}..*...<br /> 0010 12 16 9e 09 a0 00 c9 02 00 00 40 00 00 00 ff ff ..........@.....<br /> 0020 ff ff ff ff da 6b f7 22 f3 77 ff ff ff ff ff ff .....k.".w......<br /> 0030 40 77 00 20 4e 69 6e 74 65 6e 64 6f 5f 33 44 53 @w. Nintendo_3DS<br /> 0040 5f 63 6f 6e 74 69 6e 75 6f 75 73 5f 73 63 61 6e _continuous_scan<br /> 0050 5f 30 30 30 01 08 82 84 8b 0c 12 96 18 24 32 04 _000.........$2.<br /> 0060 30 48 60 6c dd 15 00 1f 32 01 11 05 00 02 08 00 0H`l....2.......<br /> 0070 00 f0 08 c8 34 6e 05 0f c9 c6 80 5b 6f bc 5a ....4n.....[o.Z<br /> <br /> 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 sleepmode, usually do StreetPass every <12 hours?<br /> <br /> When in standby mode the old DS WiFi is used, which includes SpotPass and StreetPass, but in "active" mode the regular DSi WiFi bus is used.<br /> <br /> === Nintendo Tag Format ===<br /> <br /> 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.<br /> <br /> {| class="wikitable" border="1"<br /> |-<br /> ! Offset<br /> ! Length<br /> ! Description<br /> | Example<br /> |-<br /> | 0x00<br /> | 0x01<br /> | *Protocol identification*. May be for protocol identification. All captures thus far show this value at 17, hexadecimal 11.<br /> | 11<br /> |-<br /> | 0x01<br /> | 0x01<br /> | *Unknown*. Seems to vary by device, but stays consistent and doesn't change between Street Passes. May be a length or counter field in relation to the next set of fields.<br /> | 05<br /> |-<br /> | 0x02<br /> | 0x05<br /> | *SteetPass 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.<br /> | 00 02 08 00 00<br /> |-<br /> | -0x08<br /> | 0x08<br /> | *StreetPass ID*. Seen to change after every time the Settings app is used. Also may change after each StreetPass hit and system power-off?<br /> | 0f c9 c6 80 5b 6f bc 5a<br /> |}<br /> <br /> ==== Identification String ====<br /> <br /> Defined the entire Nintendo tag with the exception of the StreetPass ID. It's purpose is unknown at the moment, but the length appears to vary from 3DS to 3DS.<br /> <br /> ==== Unknown Field ====<br /> <br /> As mentioned, possible a length field for the StreetPass services.<br /> <br /> ==== StreetPass Services ====<br /> <br /> 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. Observed service IDs include:<br /> <br /> - *Mii Plaza*: 00 02 08 00 00<br /> - *Sims 3*: 00 03 65 00 30<br /> <br /> Some services have a 6-byte field preceding or 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.<br /> <br /> ==== StreetPass ID ====<br /> <br /> When there's a StreetPass hit, and no StreetPass data changed on either of the 3DSes, no data is transferred besides probes? Perhaps there's some ID in the Nintendo tag that gets updated every-time the 3DS' StreetPass data changes? 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) the 8bytes in the Nintendo tag changes? <br /> <br /> == StreetPass spoofing ==<br /> <br /> A streetpass "AP" was spoofed on a laptop with hostapd by setting the SSID to "Nintendo_3DS_continuous_scan_000", with the extra Nintendo tag from another 3DS' probe request. The SSID and AP can't be easily spoofed with hostapd for streetpass when 3DS is "active", for the random "ic[kSvm9s@*cYD>/~IEVj\(fGG;qDo8j" strings. The 3DS didn't seem to authenticate or associate with the "AP". Streetpass "AP" comms use '''WPA2''' encryption. Eventually the 3DS stops communicating with the fake "AP" since the AP doesn't understand the sent data,(especially since it's encrypted) and 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)<br /> Communication with two 3DSes are the same as above except there's encrypted data sent to/from both consoles, unlike the fake "AP".<br /> <br /> [[Category:Nintendo Software]]</div>

Seabrook https://www.3dbrew.org/w/index.php?title=StreetPass&diff=784 StreetPass 2011-06-16T03:13:55Z

<p>Seabrook: </p> <hr /> <div>'''StreetPass''' is a feature that allow your 3DS to connect with other 3DS using WiFi in standby mode.<br /> It can be used to share Mii(s) on Mii Plaza for example. Games' StreetPass data is stored on [[SD_Filesystem|SD card]] under [[extdata]], while Mii Plaza StreetPass data is stored on NAND. Not all StreetPass data is stored on SD card: "StreetPass Management" can still be used without a SD card inserted. Wifi infrastructure with APs are used to communicate, like WMB and multi-player.<br /> StreetPass in sleepmode can work without SD card inserted. Games' Streetpass data are temporarily stored in NAND, and when the games process the StreetPass data they move that data to extdata on SD card.<br /> <br /> == WiFi Probe Request Frame ==<br /> <br /> 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". The probe may be related to the 3DS looking for Nintendo Zone APs. This string changes at least daily, and most likely every time the device is woken up.<br /> <br /> The MAC address used for these probes is the static MAC address found in the 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.<br /> <br /> == StreetPass Probe Frame ==<br /> <br /> 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 frame also contains a custom Nintendo tag, the contents of this tag from different 3ds captures don't match. Probe responses contain the same Nintendo tag data as the probe requests from the same 3DS. The MAC address used in sleepmode seems to change every time there's a streetpass hit, as well as the last 8-bytes of the Nintendo tag data? The MAC address + 8 byte ID for StreetPass is seen to change every time the user enters and exits and Settings application.<br /> <br /> 0000 00 00 1a 00 2f 48 00 00 19 7d 19 de 2a 00 00 00 ..../H...}..*...<br /> 0010 12 16 9e 09 a0 00 c9 02 00 00 40 00 00 00 ff ff ..........@.....<br /> 0020 ff ff ff ff da 6b f7 22 f3 77 ff ff ff ff ff ff .....k.".w......<br /> 0030 40 77 00 20 4e 69 6e 74 65 6e 64 6f 5f 33 44 53 @w. Nintendo_3DS<br /> 0040 5f 63 6f 6e 74 69 6e 75 6f 75 73 5f 73 63 61 6e _continuous_scan<br /> 0050 5f 30 30 30 01 08 82 84 8b 0c 12 96 18 24 32 04 _000.........$2.<br /> 0060 30 48 60 6c dd 15 00 1f 32 01 11 05 00 02 08 00 0H`l....2.......<br /> 0070 00 f0 08 c8 34 6e 05 0f c9 c6 80 5b 6f bc 5a ....4n.....[o.Z<br /> <br /> 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 sleepmode, usually do StreetPass every <12 hours?<br /> <br /> When in standby mode the old DS WiFi is used, which includes SpotPass and StreetPass, but in "active" mode the regular DSi WiFi bus is used.<br /> <br /> === Nintendo Tag Format ===<br /> <br /> The offsets 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".<br /> <br /> {| class="wikitable" border="1"<br /> |-<br /> ! Offset<br /> ! Length<br /> ! Description<br /> | Example<br /> |-<br /> | 0x00<br /> | 0x01<br /> | May be for protocol identification. All captures thus far show this value at 17, hexadecimal 11.<br /> | 11<br /> |-<br /> | 0x01<br /> | varies<br /> | Unknown. Remainder of the string.<br /> | 05 00 02 08 00 00 f0 08 c8 34 6e<br /> |-<br /> | -0x08<br /> | 0x08<br /> | Some random StreetPass ID. Seen to change after every time the Settings app is used. Also may change after each StreetPass hit and system power-off?<br /> | 0f c9 c6 80 5b 6f bc 5a<br /> |}<br /> <br /> ==== Identification String ====<br /> <br /> Defined the entire Nintendo tag with the exception of the StreetPass ID. It's purpose is unknown at the moment, but the length appears to vary from 3DS to 3DS.<br /> <br /> ==== StreetPass ID ====<br /> <br /> When there's a StreetPass hit, and no StreetPass data changed on either of the 3DSes, no data is transferred besides probes? Perhaps there's some ID in the Nintendo tag that gets updated every-time the 3DS' StreetPass data changes? 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) the 8bytes in the Nintendo tag changes? <br /> <br /> == StreetPass spoofing ==<br /> <br /> A streetpass "AP" was spoofed on a laptop with hostapd by setting the SSID to "Nintendo_3DS_continuous_scan_000", with the extra Nintendo tag from another 3DS' probe request. The SSID and AP can't be easily spoofed with hostapd for streetpass when 3DS is "active", for the random "ic[kSvm9s@*cYD>/~IEVj\(fGG;qDo8j" strings. The 3DS didn't seem to authenticate or associate with the "AP". Streetpass "AP" comms use '''WPA2''' encryption. Eventually the 3DS stops communicating with the fake "AP" since the AP doesn't understand the sent data,(especially since it's encrypted) and 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)<br /> Communication with two 3DSes are the same as above except there's encrypted data sent to/from both consoles, unlike the fake "AP".<br /> <br /> [[Category:Nintendo Software]]</div>

Seabrook https://www.3dbrew.org/w/index.php?title=StreetPass&diff=783 StreetPass 2011-06-16T03:08:17Z

<p>Seabrook: Typo</p> <hr /> <div>'''StreetPass''' is a feature that allow your 3DS to connect with other 3DS using WiFi in standby mode.<br /> It can be used to share Mii(s) on Mii Plaza for example. Games' StreetPass data is stored on [[SD_Filesystem|SD card]] under [[extdata]], while Mii Plaza StreetPass data is stored on NAND. Not all StreetPass data is stored on SD card: "StreetPass Management" can still be used without a SD card inserted. Wifi infrastructure with APs are used to communicate, like WMB and multi-player.<br /> StreetPass in sleepmode can work without SD card inserted. Games' Streetpass data are temporarily stored in NAND, and when the games process the StreetPass data they move that data to extdata on SD card.<br /> <br /> == WiFi Probe Request Frame ==<br /> <br /> 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". The probe may be related to the 3DS looking for Nintendo Zone APs. This string changes at least daily, and most likely every time the device is woken up.<br /> <br /> The MAC address used for these probes is the static MAC address found in the 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.<br /> <br /> == StreetPass Probe Frame ==<br /> <br /> 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 frame also contains a custom Nintendo tag, the contents of this tag from different 3ds captures don't match. Probe responses contain the same Nintendo tag data as the probe requests from the same 3DS. The MAC address used in sleepmode seems to change every time there's a streetpass hit, as well as the last 8-bytes of the Nintendo tag data? The MAC address + 8 byte ID for StreetPass is seen to change every time the user enters and exits and Settings application.<br /> <br /> 0000 00 00 1a 00 2f 48 00 00 19 7d 19 de 2a 00 00 00 ..../H...}..*...<br /> 0010 12 16 9e 09 a0 00 c9 02 00 00 40 00 00 00 ff ff ..........@.....<br /> 0020 ff ff ff ff da 6b f7 22 f3 77 ff ff ff ff ff ff .....k.".w......<br /> 0030 40 77 00 20 4e 69 6e 74 65 6e 64 6f 5f 33 44 53 @w. Nintendo_3DS<br /> 0040 5f 63 6f 6e 74 69 6e 75 6f 75 73 5f 73 63 61 6e _continuous_scan<br /> 0050 5f 30 30 30 01 08 82 84 8b 0c 12 96 18 24 32 04 _000.........$2.<br /> 0060 30 48 60 6c dd 15 00 1f 32 01 11 05 00 02 08 00 0H`l....2.......<br /> 0070 00 f0 08 c8 34 6e 05 0f c9 c6 80 5b 6f bc 5a ....4n.....[o.Z<br /> <br /> 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 sleepmode, usually do StreetPass every <12 hours?<br /> <br /> When in standby mode the old DS WiFi is used, which includes SpotPass and StreetPass, but in "active" mode the regular DSi WiFi bus is used.<br /> <br /> === Nintendo Tag Format ===<br /> <br /> The offsets 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".<br /> <br /> {| class="wikitable" border="1"<br /> |-<br /> ! Offset<br /> ! Length<br /> ! Description<br /> | Example<br /> |-<br /> | 0x00<br /> | 0x01<br /> | May be for protocol identification. All captures thus far show this value at 17, hexadecimal 11.<br /> | 11<br /> |-<br /> | 0x01<br /> | varies<br /> | Unknown. Reminder of the string.<br /> | 05 00 02 08 00 00 f0 08 c8 34 6e<br /> |-<br /> | -0x08<br /> | 0x08<br /> | Some random StreetPass ID. Seen to change after every time the Settings app is used. Also may change after each StreetPass hit and system power-off?<br /> | 0f c9 c6 80 5b 6f bc 5a<br /> |}<br /> <br /> ==== Identification String ====<br /> <br /> Defined the entire Nintendo tag with the exception of the StreetPass ID. It's purpose is unknown at the moment, but the length appears to vary from 3DS to 3DS.<br /> <br /> ==== StreetPass ID ====<br /> <br /> When there's a StreetPass hit, and no StreetPass data changed on either of the 3DSes, no data is transferred besides probes? Perhaps there's some ID in the Nintendo tag that gets updated every-time the 3DS' StreetPass data changes? 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) the 8bytes in the Nintendo tag changes? <br /> <br /> == StreetPass spoofing ==<br /> <br /> A streetpass "AP" was spoofed on a laptop with hostapd by setting the SSID to "Nintendo_3DS_continuous_scan_000", with the extra Nintendo tag from another 3DS' probe request. The SSID and AP can't be easily spoofed with hostapd for streetpass when 3DS is "active", for the random "ic[kSvm9s@*cYD>/~IEVj\(fGG;qDo8j" strings. The 3DS didn't seem to authenticate or associate with the "AP". Streetpass "AP" comms use '''WPA2''' encryption. Eventually the 3DS stops communicating with the fake "AP" since the AP doesn't understand the sent data,(especially since it's encrypted) and 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)<br /> Communication with two 3DSes are the same as above except there's encrypted data sent to/from both consoles, unlike the fake "AP".<br /> <br /> [[Category:Nintendo Software]]</div>

Seabrook https://www.3dbrew.org/w/index.php?title=StreetPass&diff=782 StreetPass 2011-06-16T03:04:07Z

<p>Seabrook: Expanding table</p> <hr /> <div>'''StreetPass''' is a feature that allow your 3DS to connect with other 3DS using WiFi in standby mode.<br /> It can be used to share Mii(s) on Mii Plaza for example. Games' StreetPass data is stored on [[SD_Filesystem|SD card]] under [[extdata]], while Mii Plaza StreetPass data is stored on NAND. Not all StreetPass data is stored on SD card: "StreetPass Management" can still be used without a SD card inserted. Wifi infrastructure with APs are used to communicate, like WMB and multi-player.<br /> StreetPass in sleepmode can work without SD card inserted. Games' Streetpass data are temporarily stored in NAND, and when the games process the StreetPass data they move that data to extdata on SD card.<br /> <br /> == WiFi Probe Request Frame ==<br /> <br /> 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". The probe may be related to the 3DS looking for Nintendo Zone APs. This string changes at least daily, and most likely every time the device is woken up.<br /> <br /> The MAC address used for these probes is the static MAC address found in the 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.<br /> <br /> == StreetPass Probe Frame ==<br /> <br /> 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 frame also contains a custom Nintendo tag, the contents of this tag from different 3ds captures don't match. Probe responses contain the same Nintendo tag data as the probe requests from the same 3DS. The MAC address used in sleepmode seems to change every time there's a streetpass hit, as well as the last 8-bytes of the Nintendo tag data? The MAC address + 8 byte ID for StreetPass is seen to change every time the user enters and exits and Settings application.<br /> <br /> 0000 00 00 1a 00 2f 48 00 00 19 7d 19 de 2a 00 00 00 ..../H...}..*...<br /> 0010 12 16 9e 09 a0 00 c9 02 00 00 40 00 00 00 ff ff ..........@.....<br /> 0020 ff ff ff ff da 6b f7 22 f3 77 ff ff ff ff ff ff .....k.".w......<br /> 0030 40 77 00 20 4e 69 6e 74 65 6e 64 6f 5f 33 44 53 @w. Nintendo_3DS<br /> 0040 5f 63 6f 6e 74 69 6e 75 6f 75 73 5f 73 63 61 6e _continuous_scan<br /> 0050 5f 30 30 30 01 08 82 84 8b 0c 12 96 18 24 32 04 _000.........$2.<br /> 0060 30 48 60 6c dd 15 00 1f 32 01 11 05 00 02 08 00 0H`l....2.......<br /> 0070 00 f0 08 c8 34 6e 05 0f c9 c6 80 5b 6f bc 5a ....4n.....[o.Z<br /> <br /> 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 sleepmode, usually do StreetPass every <12 hours?<br /> <br /> When in standby mode the old DS WiFi is used, which includes SpotPass and StreetPass, but in "active" mode the regular DSi WiFi bus is used.<br /> <br /> === Nintendo Tag Format ===<br /> <br /> The offsets 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".<br /> <br /> {| class="wikitable" border="1"<br /> |-<br /> ! Offset<br /> ! Length<br /> ! Description<br /> | Example<br /> |-<br /> | 0x00<br /> | 0x02<br /> | May be for protocol identification. All captures thus far show this value at 17, hexadecimal 11.<br /> | 11<br /> |-<br /> | 0x02<br /> | varies<br /> | Unknown. Reminder of the string.<br /> | 05 00 02 08 00 00 f0 08 c8 34 6e<br /> |-<br /> | -0x08<br /> | 0x08<br /> | Some random StreetPass ID. Seen to change after every time the Settings app is used. Also may change after each StreetPass hit and system power-off?<br /> | 0f c9 c6 80 5b 6f bc 5a<br /> |}<br /> <br /> ==== Identification String ====<br /> <br /> Defined the entire Nintendo tag with the exception of the StreetPass ID. It's purpose is unknown at the moment, but the length appears to vary from 3DS to 3DS.<br /> <br /> ==== StreetPass ID ====<br /> <br /> When there's a StreetPass hit, and no StreetPass data changed on either of the 3DSes, no data is transferred besides probes? Perhaps there's some ID in the Nintendo tag that gets updated every-time the 3DS' StreetPass data changes? 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) the 8bytes in the Nintendo tag changes? <br /> <br /> == StreetPass spoofing ==<br /> <br /> A streetpass "AP" was spoofed on a laptop with hostapd by setting the SSID to "Nintendo_3DS_continuous_scan_000", with the extra Nintendo tag from another 3DS' probe request. The SSID and AP can't be easily spoofed with hostapd for streetpass when 3DS is "active", for the random "ic[kSvm9s@*cYD>/~IEVj\(fGG;qDo8j" strings. The 3DS didn't seem to authenticate or associate with the "AP". Streetpass "AP" comms use '''WPA2''' encryption. Eventually the 3DS stops communicating with the fake "AP" since the AP doesn't understand the sent data,(especially since it's encrypted) and 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)<br /> Communication with two 3DSes are the same as above except there's encrypted data sent to/from both consoles, unlike the fake "AP".<br /> <br /> [[Category:Nintendo Software]]</div>

Seabrook https://www.3dbrew.org/w/index.php?title=Talk:StreetPass&diff=781 Talk:StreetPass 2011-06-16T03:00:23Z

<p>Seabrook: </p> <hr /> <div>Also of note, I'll be doing some study over the next many dates and adding a lot of content on the Wiki. I encourage you to challenge me in my findings, as a lot of will be best-effort assumptions based off available data. -[[User:Seabrook|Seabrook]] 07:00, 16 June 2011 (CEST)<br /> <br /> Removed this section from the article: "Whether to do a StreetPass hit is probably determined based on if the other 3DS MAC+8byte Nintendo tag data pair was ever seen before.." as it's been observed that the MAC address and 8-byte StreetPass ID change every time the user enters and exits the Settings application, but if done on two StreetPasses, they won't tag again. However, a capture wasn't done at the time to see if they talk to each other, but a StreetPass doesn't occur either way. There must be some sort other identification in the Tag used by the 3DS. Feel free to re-add if anyone disagrees with the removal due to the evidence presented, or finds evidence refuting what I stated. --[[User:Seabrook|Seabrook]] 06:18, 16 June 2011 (CEST)<br /> <br /> I do not think the StreetPass Data is stored on the SD Card at any time.<br /> I've done a diff of the card before and after getting a StreetPass and did not notice any differences.<br /> This was done with Mii Plaza StreetPass data with one returning StreetPass, and one New StreetPass.<br /> <br /> That doesn't mean all StreetPass data is stored on NAND, especially for system software perhaps. Ridge Racer StreetPass data is stored on SD card. --[[User:Yellows8|Yellows8]] 00:00, 12 April 2011 (CEST)<br /> <br /> <br /> "This frame also contains a custom Nintendo tag, it seems to contain unknown console unique data, since the contents of this tag from different 3ds captures don't match."<br /> <br /> Does this change if the mii data associated with the 3DS unit or Streetpass is changed? --[[User:Jl12|Jl12]] 14:12, 15 April 2011 (CEST)</div>

Seabrook https://www.3dbrew.org/w/index.php?title=StreetPass&diff=780 StreetPass 2011-06-16T02:40:32Z

<p>Seabrook: </p> <hr /> <div>'''StreetPass''' is a feature that allow your 3DS to connect with other 3DS using WiFi in standby mode.<br /> It can be used to share Mii(s) on Mii Plaza for example. Games' StreetPass data is stored on [[SD_Filesystem|SD card]] under [[extdata]], while Mii Plaza StreetPass data is stored on NAND. Not all StreetPass data is stored on SD card: "StreetPass Management" can still be used without a SD card inserted. Wifi infrastructure with APs are used to communicate, like WMB and multi-player.<br /> StreetPass in sleepmode can work without SD card inserted. Games' Streetpass data are temporarily stored in NAND, and when the games process the StreetPass data they move that data to extdata on SD card.<br /> <br /> == WiFi Probe Request Frame ==<br /> <br /> 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". The probe may be related to the 3DS looking for Nintendo Zone APs. This string changes at least daily, and most likely every time the device is woken up.<br /> <br /> The MAC address used for these probes is the static MAC address found in the 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.<br /> <br /> == StreetPass Probe Frame ==<br /> <br /> 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 frame also contains a custom Nintendo tag, the contents of this tag from different 3ds captures don't match. Probe responses contain the same Nintendo tag data as the probe requests from the same 3DS. The MAC address used in sleepmode seems to change every time there's a streetpass hit, as well as the last 8-bytes of the Nintendo tag data? The MAC address + 8 byte ID for StreetPass is seen to change every time the user enters and exits and Settings application.<br /> <br /> 0000 00 00 1a 00 2f 48 00 00 19 7d 19 de 2a 00 00 00 ..../H...}..*...<br /> 0010 12 16 9e 09 a0 00 c9 02 00 00 40 00 00 00 ff ff ..........@.....<br /> 0020 ff ff ff ff da 6b f7 22 f3 77 ff ff ff ff ff ff .....k.".w......<br /> 0030 40 77 00 20 4e 69 6e 74 65 6e 64 6f 5f 33 44 53 @w. Nintendo_3DS<br /> 0040 5f 63 6f 6e 74 69 6e 75 6f 75 73 5f 73 63 61 6e _continuous_scan<br /> 0050 5f 30 30 30 01 08 82 84 8b 0c 12 96 18 24 32 04 _000.........$2.<br /> 0060 30 48 60 6c dd 15 00 1f 32 01 11 05 00 02 08 00 0H`l....2.......<br /> 0070 00 f0 08 c8 34 6e 05 0f c9 c6 80 5b 6f bc 5a ....4n.....[o.Z<br /> <br /> 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 sleepmode, usually do StreetPass every <12 hours?<br /> <br /> When in standby mode the old DS WiFi is used, which includes SpotPass and StreetPass, but in "active" mode the regular DSi WiFi bus is used.<br /> <br /> === Nintendo Tag Format ===<br /> <br /> The offsets 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".<br /> <br /> {| class="wikitable" border="1"<br /> |-<br /> ! Offset<br /> ! Length<br /> ! Description<br /> |-<br /> | 0x0<br /> | varies<br /> | Unknown, but may include active Streetpass services. This remains static between street passes, reboots, and Settings app interaction.<br /> |-<br /> | -0x8<br /> | 0x8<br /> | Some random StreetPass ID. Seen to change after every time the Settings app is used. Also may change after each StreetPass hit and system power-off?<br /> |}<br /> <br /> ==== Identification String ====<br /> <br /> Unknown at the moment, but the length appears to vary from 3DS to 3DS.<br /> <br /> ==== StreetPass ID ====<br /> <br /> When there's a StreetPass hit, and no StreetPass data changed on either of the 3DSes, no data is transferred besides probes? Perhaps there's some ID in the Nintendo tag that gets updated every-time the 3DS' StreetPass data changes? 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) the 8bytes in the Nintendo tag changes? <br /> <br /> == StreetPass spoofing ==<br /> <br /> A streetpass "AP" was spoofed on a laptop with hostapd by setting the SSID to "Nintendo_3DS_continuous_scan_000", with the extra Nintendo tag from another 3DS' probe request. The SSID and AP can't be easily spoofed with hostapd for streetpass when 3DS is "active", for the random "ic[kSvm9s@*cYD>/~IEVj\(fGG;qDo8j" strings. The 3DS didn't seem to authenticate or associate with the "AP". Streetpass "AP" comms use '''WPA2''' encryption. Eventually the 3DS stops communicating with the fake "AP" since the AP doesn't understand the sent data,(especially since it's encrypted) and 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)<br /> Communication with two 3DSes are the same as above except there's encrypted data sent to/from both consoles, unlike the fake "AP".<br /> <br /> [[Category:Nintendo Software]]</div>

Seabrook https://www.3dbrew.org/w/index.php?title=StreetPass&diff=779 StreetPass 2011-06-16T02:35:59Z

<p>Seabrook: Typos and clarification</p> <hr /> <div>'''StreetPass''' is a feature that allow your 3DS to connect with other 3DS using WiFi in standby mode.<br /> It can be used to share Mii(s) on Mii Plaza for example. Games' StreetPass data is stored on [[SD_Filesystem|SD card]] under [[extdata]], while Mii Plaza StreetPass data is stored on NAND. Not all StreetPass data is stored on SD card: "StreetPass Management" can still be used without a SD card inserted. Wifi infrastructure with APs are used to communicate, like WMB and multi-player.<br /> StreetPass in sleepmode can work without SD card inserted. Games' Streetpass data are temporarily stored in NAND, and when the games process the StreetPass data they move that data to extdata on SD card.<br /> <br /> == WiFi Probe Request Frame ==<br /> <br /> 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". The probe may be related to the 3DS looking for Nintendo Zone APs. This string changes at least daily, and most likely every time the device is woken up.<br /> <br /> The MAC address used for these probes is the static MAC address found in the 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.<br /> <br /> == StreetPass Probe Frame ==<br /> <br /> 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 frame also contains a custom Nintendo tag, the contents of this tag from different 3ds captures don't match. Probe responses contain the same Nintendo tag data as the probe requests from the same 3DS. The MAC address used in sleepmode seems to change every time there's a streetpass hit, as well as the last 8-bytes of the Nintendo tag data? The MAC address + 8 byte ID for StreetPass is seen to change every time the user enters and exits and Settings application.<br /> <br /> 0000 00 00 1a 00 2f 48 00 00 19 7d 19 de 2a 00 00 00 ..../H...}..*...<br /> 0010 12 16 9e 09 a0 00 c9 02 00 00 40 00 00 00 ff ff ..........@.....<br /> 0020 ff ff ff ff da 6b f7 22 f3 77 ff ff ff ff ff ff .....k.".w......<br /> 0030 40 77 00 20 4e 69 6e 74 65 6e 64 6f 5f 33 44 53 @w. Nintendo_3DS<br /> 0040 5f 63 6f 6e 74 69 6e 75 6f 75 73 5f 73 63 61 6e _continuous_scan<br /> 0050 5f 30 30 30 01 08 82 84 8b 0c 12 96 18 24 32 04 _000.........$2.<br /> 0060 30 48 60 6c dd 15 00 1f 32 01 11 05 00 02 08 00 0H`l....2.......<br /> 0070 00 f0 08 c8 34 6e 05 0f c9 c6 80 5b 6f bc 5a ....4n.....[o.Z<br /> <br /> 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 sleepmode, usually do StreetPass every <12 hours?<br /> <br /> When in standby mode the old DS WiFi is used, which includes SpotPass and StreetPass, but in "active" mode the regular DSi WiFi bus is used.<br /> <br /> === Nintendo Tag Format ===<br /> <br /> The Nintendo tag always begins at the 0x50 offset if observing a captured frame. The offsets mentioned in the table below start at the beginning of the Nintendo tag ID, which is variable in length.<br /> <br /> {| class="wikitable" border="1"<br /> |-<br /> ! Offset<br /> ! Length<br /> ! Description<br /> |-<br /> | 0x0<br /> | varies<br /> | Unknown, but may include active Streetpass services. This remains static between street passes, reboots, and Settings app interaction.<br /> |-<br /> | -0x8<br /> | 0x8<br /> | Some random StreetPass ID. Seen to change after every time the Settings app is used. Also may change after each StreetPass hit and system power-off?<br /> |}<br /> <br /> ==== Identification String ====<br /> <br /> Unknown at the moment, but the length appears to vary from 3DS to 3DS.<br /> <br /> ==== StreetPass ID ====<br /> <br /> When there's a StreetPass hit, and no StreetPass data changed on either of the 3DSes, no data is transferred besides probes? Perhaps there's some ID in the Nintendo tag that gets updated every-time the 3DS' StreetPass data changes? 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) the 8bytes in the Nintendo tag changes? <br /> <br /> == StreetPass spoofing ==<br /> <br /> A streetpass "AP" was spoofed on a laptop with hostapd by setting the SSID to "Nintendo_3DS_continuous_scan_000", with the extra Nintendo tag from another 3DS' probe request. The SSID and AP can't be easily spoofed with hostapd for streetpass when 3DS is "active", for the random "ic[kSvm9s@*cYD>/~IEVj\(fGG;qDo8j" strings. The 3DS didn't seem to authenticate or associate with the "AP". Streetpass "AP" comms use '''WPA2''' encryption. Eventually the 3DS stops communicating with the fake "AP" since the AP doesn't understand the sent data,(especially since it's encrypted) and 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)<br /> Communication with two 3DSes are the same as above except there's encrypted data sent to/from both consoles, unlike the fake "AP".<br /> <br /> [[Category:Nintendo Software]]</div>

Seabrook https://www.3dbrew.org/w/index.php?title=StreetPass&diff=778 StreetPass 2011-06-16T02:30:30Z

<p>Seabrook: expanded on active WiFi probe information, although admittedly not related to StreetPass most likely.</p> <hr /> <div>'''StreetPass''' is a feature that allow your 3DS to connect with other 3DS using WiFi in standby mode.<br /> It can be used to share Mii(s) on Mii Plaza for example. Games' StreetPass data is stored on [[SD_Filesystem|SD card]] under [[extdata]], while Mii Plaza StreetPass data is stored on NAND. Not all StreetPass data is stored on SD card: "StreetPass Management" can still be used without a SD card inserted. Wifi infrastructure with APs are used to communicate, like WMB and multi-player.<br /> StreetPass in sleepmode can work without SD card inserted. Games' Streetpass data are temporarily stored in NAND, and when the games process the StreetPass data they move that data to extdata on SD card.<br /> <br /> == WiFi Probe Frame ==<br /> <br /> 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 as to an SSID containing an arbitrary string of data, such as "ic[kSvm9s@*cYD>/~IEVj\(fGG;qDo8j". The latter probe may be related to the 3DS looking for Nintendo Zone APs. This string changes at least daily, and most likely every time it is woken up.<br /> <br /> The MAC address used for these probes are the static MAC address found in the 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.<br /> <br /> == StreetPass Probe Frame ==<br /> <br /> 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 frame also contains a custom Nintendo tag, the contents of this tag from different 3ds captures don't match. Probe responses contain the same Nintendo tag data as the probe requests from the same 3DS. The MAC address used in sleepmode seems to change every time there's a streetpass hit, as well as the last 8-bytes of the Nintendo tag data? The MAC address + 8 byte ID for StreetPass is seen to change every time the user enters and exits and Settings application.<br /> <br /> 0000 00 00 1a 00 2f 48 00 00 19 7d 19 de 2a 00 00 00 ..../H...}..*...<br /> 0010 12 16 9e 09 a0 00 c9 02 00 00 40 00 00 00 ff ff ..........@.....<br /> 0020 ff ff ff ff da 6b f7 22 f3 77 ff ff ff ff ff ff .....k.".w......<br /> 0030 40 77 00 20 4e 69 6e 74 65 6e 64 6f 5f 33 44 53 @w. Nintendo_3DS<br /> 0040 5f 63 6f 6e 74 69 6e 75 6f 75 73 5f 73 63 61 6e _continuous_scan<br /> 0050 5f 30 30 30 01 08 82 84 8b 0c 12 96 18 24 32 04 _000.........$2.<br /> 0060 30 48 60 6c dd 15 00 1f 32 01 11 05 00 02 08 00 0H`l....2.......<br /> 0070 00 f0 08 c8 34 6e 05 0f c9 c6 80 5b 6f bc 5a ....4n.....[o.Z<br /> <br /> 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 sleepmode, usually do StreetPass every <12 hours?<br /> <br /> When in standby mode the old DS WiFi is used, which includes SpotPass and StreetPass, but in "active" mode the regular DSi WiFi bus is used.<br /> <br /> === Nintendo Tag Format ===<br /> <br /> The Nintendo tag always begins at the 0x50 offset if observing a captured frame. The offsets mentioned in the table below start at the beginning of the Nintendo tag ID, which is variable in length.<br /> <br /> {| class="wikitable" border="1"<br /> |-<br /> ! Offset<br /> ! Length<br /> ! Description<br /> |-<br /> | 0x0<br /> | varies<br /> | Unknown, but may include active Streetpass services. This remains static between street passes, reboots, and Settings app interaction.<br /> |-<br /> | -0x8<br /> | 0x8<br /> | Some random StreetPass ID, changes after each StreetPass hit and system power-off?<br /> |}<br /> <br /> ==== Identification String ====<br /> <br /> Unknown at the moment, but the length appears to vary from 3DS to 3DS.<br /> <br /> ==== StreetPass ID ====<br /> <br /> When there's a StreetPass hit, and no StreetPass data changed on either of the 3DSes, no data is transferred besides probes? Perhaps there's some ID in the Nintendo tag that gets updated every-time the 3DS' StreetPass data changes? 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) the 8bytes in the Nintendo tag changes? <br /> <br /> == StreetPass spoofing ==<br /> <br /> A streetpass "AP" was spoofed on a laptop with hostapd by setting the SSID to "Nintendo_3DS_continuous_scan_000", with the extra Nintendo tag from another 3DS' probe request. The SSID and AP can't be easily spoofed with hostapd for streetpass when 3DS is "active", for the random "ic[kSvm9s@*cYD>/~IEVj\(fGG;qDo8j" strings. The 3DS didn't seem to authenticate or associate with the "AP". Streetpass "AP" comms use '''WPA2''' encryption. Eventually the 3DS stops communicating with the fake "AP" since the AP doesn't understand the sent data,(especially since it's encrypted) and 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)<br /> Communication with two 3DSes are the same as above except there's encrypted data sent to/from both consoles, unlike the fake "AP".<br /> <br /> [[Category:Nintendo Software]]</div>

Seabrook https://www.3dbrew.org/w/index.php?title=StreetPass&diff=777 StreetPass 2011-06-16T02:21:17Z

<p>Seabrook: </p> <hr /> <div>'''StreetPass''' is a feature that allow your 3DS to connect with other 3DS using WiFi in standby mode.<br /> It can be used to share Mii(s) on Mii Plaza for example. Games' StreetPass data is stored on [[SD_Filesystem|SD card]] under [[extdata]], while Mii Plaza StreetPass data is stored on NAND. Not all StreetPass data is stored on SD card: "StreetPass Management" can still be used without a SD card inserted. Wifi infrastructure with APs are used to communicate, like WMB and multi-player.<br /> StreetPass in sleepmode can work without SD card inserted. Games' Streetpass data are temporarily stored in NAND, and when the games process the StreetPass data they move that data to extdata on SD card.<br /> <br /> == StreetPass Probe Frame ==<br /> <br /> 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". When in "active" mode, 3DS sends probe requests with arbitrary random SSID strings, like "ic[kSvm9s@*cYD>/~IEVj\(fGG;qDo8j". This frame also contains a custom Nintendo tag, the contents of this tag from different 3ds captures don't match. Probe responses contain the same Nintendo tag data as the probe requests from the same 3DS. The MAC address used in sleepmode seems to change every time there's a streetpass hit, as well as the last 8-bytes of the Nintendo tag data? The MAC address + 8 byte ID for StreetPass is seen to change every time the user enters and exits and Settings application.<br /> <br /> 0000 00 00 1a 00 2f 48 00 00 19 7d 19 de 2a 00 00 00 ..../H...}..*...<br /> 0010 12 16 9e 09 a0 00 c9 02 00 00 40 00 00 00 ff ff ..........@.....<br /> 0020 ff ff ff ff da 6b f7 22 f3 77 ff ff ff ff ff ff .....k.".w......<br /> 0030 40 77 00 20 4e 69 6e 74 65 6e 64 6f 5f 33 44 53 @w. Nintendo_3DS<br /> 0040 5f 63 6f 6e 74 69 6e 75 6f 75 73 5f 73 63 61 6e _continuous_scan<br /> 0050 5f 30 30 30 01 08 82 84 8b 0c 12 96 18 24 32 04 _000.........$2.<br /> 0060 30 48 60 6c dd 15 00 1f 32 01 11 05 00 02 08 00 0H`l....2.......<br /> 0070 00 f0 08 c8 34 6e 05 0f c9 c6 80 5b 6f bc 5a ....4n.....[o.Z<br /> <br /> 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 sleepmode, usually do StreetPass every <12 hours?<br /> <br /> When in standby mode the old DS WiFi is used, which includes SpotPass and StreetPass, but in "active" mode the regular DSi WiFi bus is used.<br /> <br /> === Nintendo Tag Format ===<br /> <br /> The Nintendo tag always begins at the 0x50 offset if observing a captured frame. The offsets mentioned in the table below start at the beginning of the Nintendo tag ID, which is variable in length.<br /> <br /> {| class="wikitable" border="1"<br /> |-<br /> ! Offset<br /> ! Length<br /> ! Description<br /> |-<br /> | 0x0<br /> | varies<br /> | Unknown, but may include active Streetpass services. This remains static between street passes, reboots, and Settings app interaction.<br /> |-<br /> | -0x8<br /> | 0x8<br /> | Some random StreetPass ID, changes after each StreetPass hit and system power-off?<br /> |}<br /> <br /> ==== Identification String ====<br /> <br /> Unknown at the moment, but the length appears to vary from 3DS to 3DS.<br /> <br /> ==== StreetPass ID ====<br /> <br /> When there's a StreetPass hit, and no StreetPass data changed on either of the 3DSes, no data is transferred besides probes? Perhaps there's some ID in the Nintendo tag that gets updated every-time the 3DS' StreetPass data changes? 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) the 8bytes in the Nintendo tag changes? <br /> <br /> == StreetPass spoofing ==<br /> <br /> A streetpass "AP" was spoofed on a laptop with hostapd by setting the SSID to "Nintendo_3DS_continuous_scan_000", with the extra Nintendo tag from another 3DS' probe request. The SSID and AP can't be easily spoofed with hostapd for streetpass when 3DS is "active", for the random "ic[kSvm9s@*cYD>/~IEVj\(fGG;qDo8j" strings. The 3DS didn't seem to authenticate or associate with the "AP". Streetpass "AP" comms use '''WPA2''' encryption. Eventually the 3DS stops communicating with the fake "AP" since the AP doesn't understand the sent data,(especially since it's encrypted) and 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)<br /> Communication with two 3DSes are the same as above except there's encrypted data sent to/from both consoles, unlike the fake "AP".<br /> <br /> [[Category:Nintendo Software]]</div>

Seabrook https://www.3dbrew.org/w/index.php?title=Talk:StreetPass&diff=776 Talk:StreetPass 2011-06-16T02:19:08Z

<p>Seabrook: </p> <hr /> <div>Removed this section from the article: "Whether to do a StreetPass hit is probably determined based on if the other 3DS MAC+8byte Nintendo tag data pair was ever seen before.." as it's been observed that the MAC address and 8-byte StreetPass ID change every time the user enters and exits the Settings application, but if done on two StreetPasses, they won't tag again. However, a capture wasn't done at the time to see if they talk to each other, but a StreetPass doesn't occur either way. There must be some sort other identification in the Tag used by the 3DS. Feel free to re-add if anyone disagrees with the removal due to the evidence presented, or finds evidence refuting what I stated. --[[User:Seabrook|Seabrook]] 06:18, 16 June 2011 (CEST)<br /> <br /> I do not think the StreetPass Data is stored on the SD Card at any time.<br /> I've done a diff of the card before and after getting a StreetPass and did not notice any differences.<br /> This was done with Mii Plaza StreetPass data with one returning StreetPass, and one New StreetPass.<br /> <br /> That doesn't mean all StreetPass data is stored on NAND, especially for system software perhaps. Ridge Racer StreetPass data is stored on SD card. --[[User:Yellows8|Yellows8]] 00:00, 12 April 2011 (CEST)<br /> <br /> <br /> "This frame also contains a custom Nintendo tag, it seems to contain unknown console unique data, since the contents of this tag from different 3ds captures don't match."<br /> <br /> Does this change if the mii data associated with the 3DS unit or Streetpass is changed? --[[User:Jl12|Jl12]] 14:12, 15 April 2011 (CEST)</div>

Seabrook https://www.3dbrew.org/w/index.php?title=Talk:StreetPass&diff=775 Talk:StreetPass 2011-06-16T02:18:29Z

<p>Seabrook: </p> <hr /> <div>Removed this section from the article: "Whether to do a StreetPass hit is probably determined based on if the other 3DS MAC+8byte Nintendo tag data pair was ever seen before, or how long that 3DS was in range constantly/out of range. 3DSes that are constantly in range of each other in sleepmode, usually do StreetPass every <12 hours?" as it's been observed that the MAC address and 8-byte StreetPass ID change every time the user enters and exits the Settings application, but if done on two StreetPasses, they won't tag again. However, a capture wasn't done at the time to see if they talk to each other, but a StreetPass doesn't occur either way. There must be some sort other identification in the Tag used by the 3DS. Feel free to re-add if anyone disagrees with the removal due to the evidence presented, or finds evidence refuting what I stated. --[[User:Seabrook|Seabrook]] 06:18, 16 June 2011 (CEST)<br /> <br /> I do not think the StreetPass Data is stored on the SD Card at any time.<br /> I've done a diff of the card before and after getting a StreetPass and did not notice any differences.<br /> This was done with Mii Plaza StreetPass data with one returning StreetPass, and one New StreetPass.<br /> <br /> That doesn't mean all StreetPass data is stored on NAND, especially for system software perhaps. Ridge Racer StreetPass data is stored on SD card. --[[User:Yellows8|Yellows8]] 00:00, 12 April 2011 (CEST)<br /> <br /> <br /> "This frame also contains a custom Nintendo tag, it seems to contain unknown console unique data, since the contents of this tag from different 3ds captures don't match."<br /> <br /> Does this change if the mii data associated with the 3DS unit or Streetpass is changed? --[[User:Jl12|Jl12]] 14:12, 15 April 2011 (CEST)</div>

Seabrook https://www.3dbrew.org/w/index.php?title=StreetPass&diff=774 StreetPass 2011-06-16T02:15:58Z

<p>Seabrook: Copy-edit and content re-organization. Need to segment the broadcast/probe section since there are other sections such as the StreetPass exchange that will be studied.</p> <hr /> <div>'''StreetPass''' is a feature that allow your 3DS to connect with other 3DS using WiFi in standby mode.<br /> It can be used to share Mii(s) on Mii Plaza for example. Games' StreetPass data is stored on [[SD_Filesystem|SD card]] under [[extdata]], while Mii Plaza StreetPass data is stored on NAND. Not all StreetPass data is stored on SD card: "StreetPass Management" can still be used without a SD card inserted. Wifi infrastructure with APs are used to communicate, like WMB and multi-player.<br /> StreetPass in sleepmode can work without SD card inserted. Games' Streetpass data are temporarily stored in NAND, and when the games process the StreetPass data they move that data to extdata on SD card.<br /> <br /> == StreetPass Probe Frame ==<br /> <br /> 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". When in "active" mode, 3DS sends probe requests with arbitrary random SSID strings, like "ic[kSvm9s@*cYD>/~IEVj\(fGG;qDo8j". This frame also contains a custom Nintendo tag, the contents of this tag from different 3ds captures don't match. Probe responses contain the same Nintendo tag data as the probe requests from the same 3DS. The MAC address used in sleepmode seems to change every time there's a streetpass hit, as well as the last 8-bytes of the Nintendo tag data? The MAC address + 8 byte ID for StreetPass is seen to change every time the user enters and exits and Settings application.<br /> <br /> 0000 00 00 1a 00 2f 48 00 00 19 7d 19 de 2a 00 00 00 ..../H...}..*...<br /> 0010 12 16 9e 09 a0 00 c9 02 00 00 40 00 00 00 ff ff ..........@.....<br /> 0020 ff ff ff ff da 6b f7 22 f3 77 ff ff ff ff ff ff .....k.".w......<br /> 0030 40 77 00 20 4e 69 6e 74 65 6e 64 6f 5f 33 44 53 @w. Nintendo_3DS<br /> 0040 5f 63 6f 6e 74 69 6e 75 6f 75 73 5f 73 63 61 6e _continuous_scan<br /> 0050 5f 30 30 30 01 08 82 84 8b 0c 12 96 18 24 32 04 _000.........$2.<br /> 0060 30 48 60 6c dd 15 00 1f 32 01 11 05 00 02 08 00 0H`l....2.......<br /> 0070 00 f0 08 c8 34 6e 05 0f c9 c6 80 5b 6f bc 5a ....4n.....[o.Z<br /> <br /> When in standby mode the old DS WiFi is used, which includes SpotPass and StreetPass, but in "active" mode the regular DSi WiFi bus is used.<br /> <br /> === Nintendo Tag Format ===<br /> <br /> The Nintendo tag always begins at the 0x50 offset if observing a captured frame. The offsets mentioned in the table below start at the beginning of the Nintendo tag ID, which is variable in length.<br /> <br /> {| class="wikitable" border="1"<br /> |-<br /> ! Offset<br /> ! Length<br /> ! Description<br /> |-<br /> | 0x0<br /> | varies<br /> | Unknown, but may include active Streetpass services. This remains static between street passes, reboots, and Settings app interaction.<br /> |-<br /> | -0x8<br /> | 0x8<br /> | Some random StreetPass ID, changes after each StreetPass hit and system power-off?<br /> |}<br /> <br /> === StreetPass ID ===<br /> <br /> When there's a StreetPass hit, and no StreetPass data changed on either of the 3DSes, no data is transferred besides probes? Perhaps there's some ID in the Nintendo tag that gets updated every-time the 3DS' StreetPass data changes? 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) the 8bytes in the Nintendo tag changes? <br /> <br /> == StreetPass spoofing ==<br /> <br /> A streetpass "AP" was spoofed on a laptop with hostapd by setting the SSID to "Nintendo_3DS_continuous_scan_000", with the extra Nintendo tag from another 3DS' probe request. The SSID and AP can't be easily spoofed with hostapd for streetpass when 3DS is "active", for the random "ic[kSvm9s@*cYD>/~IEVj\(fGG;qDo8j" strings. The 3DS didn't seem to authenticate or associate with the "AP". Streetpass "AP" comms use '''WPA2''' encryption. Eventually the 3DS stops communicating with the fake "AP" since the AP doesn't understand the sent data,(especially since it's encrypted) and 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)<br /> Communication with two 3DSes are the same as above except there's encrypted data sent to/from both consoles, unlike the fake "AP".<br /> <br /> [[Category:Nintendo Software]]</div>

Seabrook https://www.3dbrew.org/w/index.php?title=StreetPass&diff=773 StreetPass 2011-06-16T02:05:12Z

<p>Seabrook: Reverted length because it's not determined yet. Would like to gather more data. Also made some additions and copy edit.</p> <hr /> <div>'''StreetPass''' is a feature that allow your 3DS to connect with other 3DS using WiFi in standby mode.<br /> It can be used to share Mii(s) on Mii Plaza for example. Games' StreetPass data is stored on [[SD_Filesystem|SD card]] under [[extdata]], while Mii Plaza StreetPass data is stored on NAND. Not all StreetPass data is stored on SD card: "StreetPass Management" can still be used without a SD card inserted. Wifi infrastructure with APs are used to communicate, like WMB and multi-player.<br /> StreetPass in sleepmode can work without SD card inserted. Games' Streetpass data are temporarily stored in NAND, and when the games process the StreetPass data they move that data to extdata on SD card.<br /> <br /> 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". When in "active" mode, 3DS sends probe requests with arbitrary random SSID strings, like "ic[kSvm9s@*cYD>/~IEVj\(fGG;qDo8j". This frame also contains a custom Nintendo tag, the contents of this tag from different 3ds captures don't match. Probe responses contain the same Nintendo tag data as the probe requests from the same 3DS. The MAC address used in sleepmode seems to change every time there's a streetpass hit, as well as the last 8-bytes of the Nintendo tag data? The MAC address used for StreetPass is seen to change every time the user enters and exits and Settings application.<br /> <br /> When there's a StreetPass hit, and no StreetPass data changed on either of the 3DSes, no data is transferred besides probes? Perhaps there's some ID in the Nintendo tag that gets updated every-time the 3DS' StreetPass data changes? 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) the 8bytes in the Nintendo tag changes? <br /> <br /> Whether to do a StreetPass hit is probably determined based on if the other 3DS MAC+8byte Nintendo tag data pair was ever seen before, or how long that 3DS was in range constantly/out of range. 3DSes that are constantly in range of each other in sleepmode, usually do StreetPass every <12 hours?<br /> <br /> When in standby mode, old DS wifi is used,(this includes SpotPass and StreetPass) but in "active" mode the regular DSi wifi bus is used.<br /> <br /> 0000 00 00 1a 00 2f 48 00 00 19 7d 19 de 2a 00 00 00 ..../H...}..*...<br /> 0010 12 16 9e 09 a0 00 c9 02 00 00 40 00 00 00 ff ff ..........@.....<br /> 0020 ff ff ff ff da 6b f7 22 f3 77 ff ff ff ff ff ff .....k.".w......<br /> 0030 40 77 00 20 4e 69 6e 74 65 6e 64 6f 5f 33 44 53 @w. Nintendo_3DS<br /> 0040 5f 63 6f 6e 74 69 6e 75 6f 75 73 5f 73 63 61 6e _continuous_scan<br /> 0050 5f 30 30 30 01 08 82 84 8b 0c 12 96 18 24 32 04 _000.........$2.<br /> 0060 30 48 60 6c dd 15 00 1f 32 01 11 05 00 02 08 00 0H`l....2.......<br /> 0070 00 f0 08 c8 34 6e 05 0f c9 c6 80 5b 6f bc 5a ....4n.....[o.Z<br /> <br /> == Nintendo tag format ==<br /> <br /> {| class="wikitable" border="1"<br /> |-<br /> ! Offset<br /> ! Length<br /> ! Description<br /> |-<br /> | 0x0<br /> | varies<br /> | Unknown, but may include active Streetpass services. This remains static between street passes, reboots, and Settings app interaction.<br /> |-<br /> | -0x8<br /> | 0x8<br /> | Some random StreetPass ID, changes after each StreetPass hit and system power-off?<br /> |}<br /> <br /> == StreetPass spoofing ==<br /> <br /> A streetpass "AP" was spoofed on a laptop with hostapd by setting the SSID to "Nintendo_3DS_continuous_scan_000", with the extra Nintendo tag from another 3DS' probe request. The SSID and AP can't be easily spoofed with hostapd for streetpass when 3DS is "active", for the random "ic[kSvm9s@*cYD>/~IEVj\(fGG;qDo8j" strings. The 3DS didn't seem to authenticate or associate with the "AP". Streetpass "AP" comms use '''WPA2''' encryption. Eventually the 3DS stops communicating with the fake "AP" since the AP doesn't understand the sent data,(especially since it's encrypted) and 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)<br /> Communication with two 3DSes are the same as above except there's encrypted data sent to/from both consoles, unlike the fake "AP".<br /> <br /> [[Category:Nintendo Software]]</div>

Seabrook https://www.3dbrew.org/w/index.php?title=StreetPass&diff=772 StreetPass 2011-06-16T01:58:45Z

<p>Seabrook: This string ID appears to be 0x0a in length and identified at the start with the '0f' byte, and I've seen the former ID longer than 0xf.</p> <hr /> <div>'''StreetPass''' is a feature that allow your 3DS to connect with other 3DS using WiFi in standby mode.<br /> It can be used to share Mii(s) on Mii Plaza for example. Games' StreetPass data is stored on [[SD_Filesystem|SD card]] under [[extdata]], while Mii Plaza StreetPass data is stored on NAND. Not all StreetPass data is stored on SD card: "StreetPass Management" can still be used without a SD card inserted. Wifi infrastructure with APs are used to communicate, like WMB and multi-player.<br /> StreetPass in sleepmode can work without SD card inserted. Games' Streetpass data are temporarily stored in NAND, and when the games process the StreetPass data they move that data to extdata on SD card.<br /> <br /> 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". When in "active" mode, 3DS sends probe requests with arbitrary random SSID strings, like "ic[kSvm9s@*cYD>/~IEVj\(fGG;qDo8j". This frame also contains a custom Nintendo tag, the contents of this tag from different 3ds captures don't match. Probe responses contain the same Nintendo tag data as the probe requests from the same 3DS. The MAC address used in sleepmode seems to change every time there's a streetpass hit, as well as the last 8-bytes of the Nintendo tag data?<br /> <br /> When there's a StreetPass hit, and no StreetPass data changed on either of the 3DSes, no data is transferred besides probes? Perhaps there's some ID in the Nintendo tag that gets updated every-time the 3DS' StreetPass data changes? 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. After one of the new StreetPass content is handled,(running one of the StreetPass titles etc) the 8bytes in the Nintendo tag changes?<br /> Whether to do a StreetPass hit is probably determined based on if the other 3DS MAC+8byte Nintendo tag data pair was ever seen before, or how long that 3DS was in range constantly/out of range. 3DSes that are constantly in range of each other in sleepmode, usually do StreetPass every <12 hours?<br /> <br /> When in standby mode, old DS wifi is used,(this includes SpotPass and StreetPass) but in "active" mode the regular DSi wifi bus is used.<br /> <br /> 0000 00 00 1a 00 2f 48 00 00 19 7d 19 de 2a 00 00 00 ..../H...}..*...<br /> 0010 12 16 9e 09 a0 00 c9 02 00 00 40 00 00 00 ff ff ..........@.....<br /> 0020 ff ff ff ff da 6b f7 22 f3 77 ff ff ff ff ff ff .....k.".w......<br /> 0030 40 77 00 20 4e 69 6e 74 65 6e 64 6f 5f 33 44 53 @w. Nintendo_3DS<br /> 0040 5f 63 6f 6e 74 69 6e 75 6f 75 73 5f 73 63 61 6e _continuous_scan<br /> 0050 5f 30 30 30 01 08 82 84 8b 0c 12 96 18 24 32 04 _000.........$2.<br /> 0060 30 48 60 6c dd 15 00 1f 32 01 11 05 00 02 08 00 0H`l....2.......<br /> 0070 00 f0 08 c8 34 6e 05 0f c9 c6 80 5b 6f bc 5a ....4n.....[o.Z<br /> <br /> == Nintendo tag format ==<br /> <br /> {| class="wikitable" border="1"<br /> |-<br /> ! Offset<br /> ! Length<br /> ! Description<br /> |-<br /> | 0x0<br /> | variable<br /> | Unknown<br /> |-<br /> | -0xa<br /> | 0xa<br /> | Some random StreetPass ID, changes after each StreetPass hit and system power-off?<br /> |}<br /> <br /> == StreetPass spoofing ==<br /> <br /> A streetpass "AP" was spoofed on a laptop with hostapd by setting the SSID to "Nintendo_3DS_continuous_scan_000", with the extra Nintendo tag from another 3DS' probe request. The SSID and AP can't be easily spoofed with hostapd for streetpass when 3DS is "active", for the random "ic[kSvm9s@*cYD>/~IEVj\(fGG;qDo8j" strings. The 3DS didn't seem to authenticate or associate with the "AP". Streetpass "AP" comms use '''WPA2''' encryption. Eventually the 3DS stops communicating with the fake "AP" since the AP doesn't understand the sent data,(especially since it's encrypted) and 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)<br /> Communication with two 3DSes are the same as above except there's encrypted data sent to/from both consoles, unlike the fake "AP".<br /> <br /> [[Category:Nintendo Software]]</div>

Seabrook