Support Switch/PRUDPLite #23
Conversation
| { | ||
| "name": "Mario Kart 8 Deluxe", | ||
| "game_server_id": "2b309e01", | ||
| "access_key": "09c1c475", | ||
| "nex_version": "4.3.2", | ||
| "nex_ranking_version": "4.3.2", | ||
| "nex_datastore_version": "4.3.2", | ||
| "nex_match_making_version": "4.3.2", | ||
| "nex_messaging_version": "4.3.2", | ||
| "nex_utility_version": "4.3.2", | ||
| "title_ids": [ | ||
| "0100152000022000" | ||
| ] | ||
| }, | ||
| { | ||
| "name": "Super Mario Maker 2", | ||
| "game_server_id": "22306d00", | ||
| "access_key": "fdf6617f", | ||
| "nex_version": "4.6.25", | ||
| "nex_ranking_version": "4.6.25", | ||
| "nex_datastore_version": "4.6.25", | ||
| "nex_match_making_version": "4.6.25", | ||
| "nex_messaging_version": "4.6.25", | ||
| "nex_utility_version": "4.6.25", | ||
| "title_ids": [ | ||
| "01009B90006DC000" | ||
| ] | ||
| } |
There was a problem hiding this comment.
these fields should be added on the txt files
There was a problem hiding this comment.
I agree, I just wasn't sure how considering they have the extra field game_server_id. Thoughts?
There was a problem hiding this comment.
We can probably add that to a new text file, maybe game_server_ids.txt? btw, maybe we could store all text files on a single folder to keep the root folder clean
There was a problem hiding this comment.
That's fair, I agree. Honestly the whole apps source is a bit of a mess. That's my fault though, I originally designed this to not even be a viewer, but rather just a decoding library. The Electron app was actually originally just an example demo. I switched gears at some point though and realized that was stupid and went all-in on the viewer concept, but that's why the source is kinda janky
There was a problem hiding this comment.
Here's a question
Should we even still maintain the .txt files?
I originally made them, and the generation script, as a way for me to quickly convert data from Kinnay's site into JSON. But seeing as how that's already been done, and we're just adding in games one at a time now, is there actually a reason to keep maintaining those extra files?
There was a problem hiding this comment.
I think the txt files could be useful if the json file gets very large to read on a text editor, but I'm fine either way.
In case we want to deprecate the TXT files, the game server id should be added for the other games btw
| this.maximumSubstreamId = packetSpecificDataStream.readUInt8(); | ||
| break; | ||
| case OPTION_LITE_SIGNATURE: | ||
| this.liteSignature = packetSpecificDataStream.readBytes(optionSize); |
There was a problem hiding this comment.
should we verify this signature?
There was a problem hiding this comment.
We can if you think it's necessary. I didn't initially just to simplify the handling, since it removes state tracking (which is also why I decided to use the hostname to determine the server rather than the signature)
There was a problem hiding this comment.
it's mostly since we were doing it for other packet dumps, but sounds fair
There was a problem hiding this comment.
The main reason for verifying the data of the other packets is to determine which game server the packet belongs to
|
Is it possible to convert those bin files into an HAR file? that could help for mitmproxy users (and we could consider supporting HPP) |
|
I'm sure there is, the BIN files are just the raw web socket messages, each one contains a single PRUDPLite packet in this case Is there much need for that though? If you load a HAR with these into mitmproxy you're just going to see raw packet data, as opposed to here which decodes the packets into something consumable |
|
Update, I've also looked into trying to support other dump formats, since relying solely on Charles really isn't a great long-term plan. But I'm not positive there's a better way at the moment The issue stems from the fact that the Switch uses a secure web socket. So all the data is encrypted, and we don't really have a way to decrypt it outside of Charles right now? Even with Charles, if you take a dump that already has a decrypted connection and then try to export it again, and open the newly exported dump, it will shift to being encrypted once again and not decode properly. This is why I also attempted to export the Charles dump as a HAR directly, but it has the same result. I thought maybe this would work, as I assume mitmproxy also supports WSS proxying much like Charles, but if the data remains encrypted it's next to useless to us So far the only way to get anything usable, that I've found, is by using Charles to both capture the traffic (so it gets decrypted), and then using it's "Save WebSocket Messages" tool to export all the packets as BIN files like what's already supported here I don't have mitmproxy nor do I have my Switch set up to use a proxy server at all, so I can't test if mitmproxy even supports WSS proxying, let alone decrypting the traffic. If we can confirm that it does, and find a way to export to decrypted traffic (maybe using a custom addon?) then I'll gladly add support for it here |
|
I (want to) think that mitmproxy should support extracting the websocket data as decrypted, but I also don't have my Switch configured with a proxy nor I have any Switch mitmproxy dumps to check this. As a note, exporting as HAR from mitmproxy was added recently this year |
|
Whiskers brought that to my attention a while ago, that's why I tried HAR in Charles (since I expected it to produce a HAR in the same way mitm would) I'll see if I can talk @InternalLoss into getting us some dedicated mitmproxy dumps to test this |
|
I did some digging and I found the code where mitmproxy saves the websocket packets to HAR: |
|
That looks really promising. All I need now tbh is just a usable HAR to test with. Since Charles can't export HARs with decrypted WebSocket traffic I can't test HARs without getting my Switch setup |
|
Closing, superseded by #26 which now has Switch packet support and the ability to read Charles dumps directly It still lacks HAR support, but that's fine for now. The basis is there for when we get a usable HAR to test with |
PR adds in support for PRUDPLite, which is used by Switch servers. It's implemented using a different connection class as the handling is pretty different, due to the lack of crypto. Currently the only format accepted is the BIN format that Charles produces, as it's the easiest way to get Switch traffic. PR does not aim to implement Switch/NEX 4.0+ support in the protocols, only the ability to read the connections. Protocol support should come gradually, just like with the older protocols
With the impending death of Nintendo Network, viewing early Switch game traffic will be our only way to still see how a NEX server operates. This will only be the later versions, but it's better than nothing