Hacking Streetpass

[dirgotronix]

Pardon me while I brainstorm to the public here.

I noticed we have people logging packets on the network update, which is an excellent starting point. This kind of exploration brings me back to my wardriving days. Along the same lines, has anyone looked into the wireless networking used for streetpass? Here are my hypotheses:

1. (confirmed) Streetpass is strictly ad-hoc. Streetpass does not work when connected to a wireless network, and it only works when the system is in standby (it appears to work when resuming the system until it associates with an access point). This leads me to believe that there is only one wireless adapter and it works over 802.11.

2. (confirmed) While in standby, the 3DS is both transmitting and listening over wireless for other systems to exchange data.

3. (confirmed) If the system is broadcasting randomly for streetpass, and it uses the same wireless adapter to do so, I should be able to sniff some packets from it with a passive wireless scanner.

4. Presuming I had a second 3DS in the vicinity, I should also be able to sniff the handshake and mii exchange (as well as any third-party game's data, such as street fighter or ridge racer) that occurs during streetpass.

5. Taking a cue from wifime, if I can log and replay the data exchange (whether it's encrypted or not), I should be able to trick my 3DS into thinking I've passed the same person's console numerous times.

At the very least, the following information is exchanged:

- Your Mii
- Your personal quote
- Your favorite and most recent games
(All these things may be the same data as in the QR code, I'm not sure as I haven't looked into the differences between the Wii and the 3DS QR.)

In Ridge Racer:

- Ghost race data

In Street Fighter

- Your team of five characters and their customized statistics

If I can find a few people with different 3DS's and I'm able to log the data, I should be able to make sense of the data by looking through the differences and similarities in the data exchange, presuming it's encrypted at all.

My first step will be to sniff the wireless. I'll post any interesting results here. Has anyone else got any ideas to throw into the pile?

 

[dirgotronix]

The 3DS appears to broadcast a block of packets randomly. In the following packet log, I started the scanner, opened the 3DS, closed it 10 seconds later, and let it sit for a few minutes in sleep mode.

Here's an example of the data from the packets sent out (with the tcp headers removed):

http://pastebin.com/0jr4jVCk

At a quick glance there doesn't appear to be many similarities to the data between packets save for length and tcp headers. There are seven packets broadcast in each set. The first five packets are 348 bytes and the next two are 66 bytes but in each that I've logged the data are different in each sequence. I don't know anyone else with a 3DS to log the interaction between two systems.

 

[Jono1250]

The 3DS appears to broadcast a block of packets randomly. In the following packet log, I started the scanner, opened the 3DS, closed it 10 seconds later, and let it sit for a few minutes in sleep mode.

Here's an example of the data from the packets sent out (with the tcp headers removed):

http://pastebin.com/0jr4jVCk

At a quick glance there doesn't appear to be many similarities to the data between packets save for length and tcp headers. There are seven packets broadcast in each set. The first five packets are 348 bytes and the next two are 66 bytes but in each that I've logged the data are different in each sequence. I don't know anyone else with a 3DS to log the interaction between two systems.

I have NO IDEA what the hell this means, but in my opinion, any progress is good progress, keep it up

 

[linuxares]

Can you make a portscan while its in standby against it? You must have a computer and try Ad-hoc it ofcourse. I can see what I can do also.

 

[Nollog]

That's a great idea for cheating on puzzles and streetpass quest.

 

[FAST6191]

First thanks for the info, whether it ultimately leads to anything or not it is nice to have.

"if I can log and replay"

No session keys or perhaps pseudo session keys (new keys generated at set interval or something)? Granted the latter does not really trouble instant replay.

@linuxares what use would a port scan be- I doubt it is running any known services or even much in the way of what we might consider services.

 

[linuxares]

@linuxares what use would a port scan be- I doubt it is running any known services or even much in the way of what we might consider services.

Maybe not, but I'm trying to find if its a possible fail from Nintendos side that it somehow TFTP (most unlikely) the character info etc. Just trying to investigate the possibilities!

 

[[Truth]]

you should talk to yellows8 on #3dsdev about your findings.
he was also investigating the 3ds wifi.

 

[Roxxy]

Check out this:

http://3dbrew.org/wiki/StreetPass

Maybe there is something you don't know yet.

 

[koji2009]

I'm sure the data is not only encrypted, but is more than simply broadcasting. There is liking handshaking and verification, something that can't be duplicated by simply rebroadcasting what you've captured before.

 

[dirgotronix]

From what I can tell, the packets are the same size, number, and frequency every time. Each packet is different and I'm not seeing any similarities between sequences. This leads me to believe that they're encrypted in some way. Since the data is different, I'm led to believe that the data is either sensitive to the current time/date, or is encrypted in some way with the current time/date. If the data was static, it would remain constant. I would really like to find another person with a 3DS so I could sniff the data exchange. It would also be interesting to set the time/date equal on two or more systems to see if there are any similarities between the data. I'm going to log a handfull of the broadcast packets and diff them out to see if there's anything of interest.

@linuxares: I'll give it a shot for curiosity's sake, though I sincerely doubt there are any running services.

@nollog: That's where I'm aiming right now. Surely there's a possibility to forge funky data and see what the results are, but for now, I'd like to mimic the communication on a functional level.

@fast6191: I'm almost certain the data is encrypted, because I can't find any obvious reference anywhere except the header (3DS MAC, broadcast MAC, and last associated bssid). Perhaps I could glean more information if I sniffed a handshake between two systems.

@[truth]: I assumed there was a channel but I have no idea what server it's on.

@roxxy: I saw that shortly after posting this. I'm hoping that more analysis is being done; it seems like that stub was written as a one-off test.

@koji2009: If only I had a second system. I log streetpass hits on campus every day, unfortunately my 3DS does not introduce us as I walk past. Maybe the May update will fix this?

 

[dirgotronix]

I have NO IDEA what the hell this means, but in my opinion, any progress is good progress, keep it up

The screencap is from Wireshark, a network data capturing program. The first column is the number of each packet by order it was received. The second column counts the time in seconds from the first packet on. The third column is the MAC address, or unique hardware identification of the device transmitting the data, in this case, my 3DS. The fourth column is where that device is sending the packet to, in this case it was broadcast to any device paying attention. The fifth column is the protocol being used to transmit that packet, which shows that the 3DS is using standard TCP over wireless. Finally, custom header flags are listed in the final column, which are relevant not to the data being sent by the system, but -how- the data is sent; these are largely irrelevant overall. From this, I am most interested in how many packets are sent, when they are sent in relation to each other, and how often they are sent.

In the pastebin link, I listed each of the numbered packets from a sequence and output the full data in hex and plaintext - essentially a copy and paste from Wireshark. Think of packets like text messaging: your phone sends data (a packet) to your cellphone provider--the first part, the header, says "I am a text message" so they know how to handle it. The second part, the data, is the content of your text message. Finally, a checksum at the end allows verification so your phone company knows it's receiving valid data instead of garbage.

I hope that helps. If you're interested in learning more about sniffing network traffic there's a wealth available on google, and I'd be happy to answer any casual questions over private message. If you have a wireless card that's capable of passively receiving data (Wireshark will tell you if it won't) you could log this same information from your 3DS and play with it also.

 

[[Truth]]

it´s #3dsdev on EFNET.
But i don´t know if all the info he gathered is already in the link Roxxy posted.

 

[dirgotronix]

I had a chance on campus today to sniff the network for a while, and I noticed a lot of interesting communication going on between my 3DS and the campus network. While in standby, the 3DS sent out countless probes for association requests to each of the three networks it remembers, as well as a load of gibberish SSID's and, interestingly, a garbled version of my Mii's name. I'll parse through the logs tomorrow after I've had time to analyze the results. For now, if anyone else has begun logging their network traffic, take a look at this:
CODEXX: 3DS MAC Address

0000 00 00 19 00 6f 08 00 00 a8 c0 2c d7 00 00 00 00 ....o.....,.....
0010 10 02 80 09 80 00 c2 a7 00 40 00 00 00 ff ff ff .........@......
0020 ff ff ff XX XX XX XXXX XX ff ff ff ff ff ff 90 ................
0030 02 00 20 4e 57 43 55 53 42 41 50 00 00 03 00 74 .. NWCUSBAP....t
0040 00 68 00 69 00 6e 00 6b 00 4a 00 61 00 73 00 6f .h.i.n.k.J.a.s.o
0050 00 6e 00 01 08 82 84 8b 0c 12 96 18 24 32 04 30 .n..........$2.0
0060 48 60 6c 8a 9a 9c 80 H`l....

This packet represents a broadcast SSID probe request with an interesting SSID.

My Mii's name is thinkJason, it appears to break it up with null bytes between the letters: "NWCUSBAP003t0h0i0n0k0J0a0s0o0n0". Also, it appears the wireless card is 802.11g, as it regularly sends probe requests listing 54mbps as a capable connection speed.

Here's an example of a gibberish SSID probe:
CODE0000 00 00 19 00 6f 08 00 00 d4 f5 47 c7 00 00 00 00 ....o.....G.....
0010 10 02 80 09 80 00 ce a7 00 40 00 00 00 ff ff ff .........@......
0020 ff ff ff XX XX XX XX XX XX ff ff ff ff ff ff 10 ................
0030 00 00 20 69 53 23 48 53 3a 58 2e 70 53 44 22 59 .. iS#HS:X.pSD"Y
0040 7e 23 45 4f 6a 72 21 6b 48 40 5f 4c 5e 22 4a 3a ~#EOjr!kH@_L^"J:
0050 5a 4e 40 01 08 82 84 8b 0c 12 96 18 24 32 04 30 ZN@.........$2.0
0060 48 60 6c e0 18 40 fa H`l..@.

In this example, the SSID is "iS#HS:X.pSD"Y~#EOjr!kH@_L^"J:ZN@". There are countless others in my log with no discernable pattern. I imagine there's a method to the madness as I predict that's the 3DS seeking other 3DS's in the vicinity. I'll check it out tomorrow and post what I find.

Here's all the details from the above packet, for anyone who knows a thing or two about TCP:

 

[pachura]

My Mii's name is thinkJason, it appears to break it up with null bytes between the letters: "NWCUSBAP003t0h0i0n0k0J0a0s0o0n0".

That's 16-bit character representation. UTF-16 or Unicode.