NintendoClients

NintendoClients copied to clipboard

Opening this issue just to keep track of any inaccuracies/issues I find in the wiki or new findings to be added to the wiki. Since I will be updating this issue every now and then I will keep it open

To start off it seems like on the 3DS NintendoLoginData in the Secure Protocol is actually named AccountExtraInfo. It contains the same data but just a different name in the AnyDataHolder

FollowingsLatestCourseSearchObject in DataStore (SMM) says it uses a DataStoreSearchParam and a <List>String in it's request but the data I have doesn't seem to quite match that? It seems like all the data matches up in DataStoreSearchParam except that it seems to lack the totalCountEnabled and dataTypes fields. I'm unsure if these are related to the NEX version or if it's a SMM-specific patch. If I omit these two fields then the data for FollowingsLatestCourseSearchObject matches up perfectly

And finally when again using SMM it looks like GetObjectInfos actually uses <List>DataStoreFileServerObjectInfo in the response but your wiki doesn't say that SMM patches that method? I have not checked any other games which use the DataStore protocol so I don't know if this is just the wiki being wrong in general or yet another SMM-specific patch

Update on the GetObjectInfos issue

I checked previous versions of the wiki and it seems like you DID have method 45 listed as being patched by SMM

It's listed as patched here (df17064)

But on the same day you edited the page the page to de-list it (05dbda4)

The data from the older version of the wiki is true though in this case, the method does indeed seem to be patched. Why was this changed?

Thanks! I updated the wiki pages.

I'm unsure if these are related to the NEX version or if it's a SMM-specific patch.

Seems like those fields were added on the nintendo switch.

Why was this changed?

That's a mistake. I was probably confused because they didn't change the method name.

Seems like those fields were added on the nintendo switch.

thinking back to our DMs on Discord this seems to be a common thing happening. Did you use mostly Switch games to generate the protocols? And if so is there a reason you opted for Switch games?

also thank you for the speed of your reply! I noticed you very quickly determined that those values were added on the Switch, did you just manually check the two consoles or is there some quicker way to check that? I only ask because it might be helpful for me to just check myself instead of coming here confused with only half the info lol

Did you use mostly Switch games to generate the protocols? And if so is there a reason you opted for Switch games?

Yes. I'm using Switch games to get the most recent version of the protocols. The data store page was generated from Super Mario Odyssey for example.

did you just manually check the two consoles or is there some quicker way to check that?

I manually checked a few games on both consoles, and saw that those fields are only in Switch games.

It's difficult to cover all possible NEX versions, because there are so many different games out there. So whenever you see something that's not correct just let me know and I'll update the wiki.

I'm using Switch games to get the most recent version of the protocols

Of course, that makes perfect sense

It's difficult to cover all possible NEX versions, because there are so many different games out there. So whenever you see something that's not correct just let me know and I'll update the wiki.

Sounds good. I don’t currently own a Switch that I feel comfortable using for research purposes (my only switch is hackable but I don’t want to risk the ban), so I probably won’t be able to verify the differences between the consoles like that myself but I’ll bring up any discrepancies I happen to notice

On the 3DS NintendoCreateAccountData is actually called AccountExtraInfo, with a very different structure

On the 3DS you are able to connect to NEX servers without a NNID. AccountExtraInfo only contains some bytes length 0xC (which we assume is some kind of seed for generating a NEX PID, because on the 3DS the users NEX PID is not the same as their NNID PID) and then the NEX token

ReportCourse in DataStore (SMM) is undocumented, but its request seems fairly simple. Guessing on the name of the structure

struct DataStoreReportCourseParam {
	uint64 data_id;
	string mii_name;
	uint8 report_category;
	string report_reason;
}

Unsure if the mii_name is of the person reporting or the owner of the course being reported. I would assume it's the person doing the reporting, since the course owner can be found through the data ID anyway making it redundant

Doesn't seem to respond with anything

Here's some missing data from Friends Protocol (Wii U)

in AddFriendRequest the first Unknown uint32 is the PID of the person the friend request is being sent to. The first Unknown string is the message sent in the request. The DateTime seems to always be 1-1-2000 0:00:00? This is not the birthday of either person, nor is it the time the request was made or when it expires. It gets sent back in the response, it might have something to do with expire time?

in PrincipalPreference the bools are:

• show online presence
• show currently playing title
• block friend requests

In FriendRequestMessage the first Unknown uint8 is actually a boolean to determine if the friend request has been marked as received or not. This controls whether or not the friends app will call MarkFriendRequestsAsReceived and whether or not the app will display the "New Friend Request(s) popup"

The response in UpdateComment in the Friends (Wii U) protocol is the DateTime that the comment was updated

All the links to types in [Friends (Wii U)](https://github.com/kinnay/NintendoClients/wiki/Friends-Protocol-(Wii%20U) are broken due to the name changes

For example https://github.com/kinnay/NintendoClients/wiki/Friends-Protocol-(Wii%20U)#principalpreference should be https://github.com/kinnay/NintendoClients/wiki/Friends-Protocol-(Wii%20U)#principalpreference-structure

In https://github.com/kinnay/NintendoClients/wiki/PRUDP-Protocol it mentions packet fragments, but doesn't mention the size of the fragments anywhere. Your code also only ever uses 1300 bytes as the fragment size

However in the Friends server on WiiU (this may apply to other PRUDPv0 titles as well, but I have not tested them) the packet fragment size is actually 900 bytes

The MatchmakeSession structure seems to be incorrect? The following fields were said to be added in NEX 4.0.0:

• m_MatchmakeParam
• m_StartedTime
• m_UserPassword
• m_ReferGid
• m_UserPasswordEnabled
• m_SystemPasswordEnabled
• m_Codeword

However Splatoon on the Wii U uses NEX version 3.8.3, and it contains all those fields except for m_Codeword

The FriendRequest structure for Friends (Wii U) is broken?

The MatchmakeSessionSearchCriteria structure seems to be incorrect. The following fields were said to be added in NEX 4.0.0:

• m_MatchmakeParam
• m_ExcludeUserPasswordSet
• m_ExcludeSystemPasswordSet
• m_ReferGid
• m_Codeword
• m_ResultRange

However Splatoon on the Wii U uses NEX version 3.8.3, and it contains all those fields except for m_Codeword and m_ResultRange

The AutoMatchmakeParam structure seems to be incorrect. Splatoon on Wii U uses NEX version 3.8.3 and does not contain the final blockListParam field. Assuming this was added on the Switch/NEX 4.0.0?

I think I've addressed all issues that you described. The match making structures received a lot of changes in the Wii U era...

I'm closing this issue, but feel free to open a new one if you find more inconsistencies.