Line 9: |
Line 9: |
| 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. | | 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. |
| | | |
− | == StreetPass Probe Frame == | + | == StreetPass Probe Request Frame == |
| | | |
| Using Wireshark tool with a WiFi card in monitor mode allow you to see the data used to scan for other 3DS in the range. The below is a broadcast probe request from an 3DS while in standby mode, with SSID "Nintendo_3DS_continuous_scan_000". This 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. | | 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. |
Line 40: |
Line 40: |
| | 0x00 | | | 0x00 |
| | 0x01 | | | 0x01 |
− | | '''Protocol identification''' | + | | '''Protocol Identification''' |
| | May be for protocol identification. All captures thus far show this value at 17, hexadecimal 11. | | | May be for protocol identification. All captures thus far show this value at 17, hexadecimal 11. |
| | 11 | | | 11 |
Line 95: |
Line 95: |
| 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? | | 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? |
| | | |
− | == StreetPass spoofing == | + | == StreetPass Probe Response Frame == |
| + | |
| + | 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. |
| + | |
| + | == StreetPass Spoofing == |
| | | |
| 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) | | 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) |