Difference between revisions of "MK8 Network Protocol"
Jump to navigation
Jump to search
| Line 17: | Line 17: | ||
All P2P packets have a header, a payload and a checksum | All P2P packets have a header, a payload and a checksum | ||
| − | == The P2P | + | == The P2P headers == |
| − | <pre>typedef struct | + | There are two different headers: One header at the beginning of each packet ... |
| + | |||
| + | <pre> | ||
| + | typedef struct udp_main_header_t | ||
{ | { | ||
/*00*/ u32 game_magic; // always 32ab.9864 | /*00*/ u32 game_magic; // always 32ab.9864 | ||
/*04*/ u32 unknown_04; // | /*04*/ u32 unknown_04; // | ||
/*08*/ u16 unknown_08; // sequence id? | /*08*/ u16 unknown_08; // sequence id? | ||
| + | } | ||
| + | __attribute__ ((packed)) udp_main_header_t; | ||
| + | </pre> | ||
| + | |||
| + | ... and one at the beginning of each record. A packet may contain multiple records. | ||
| + | |||
| + | <pre> | ||
| + | typedef struct udp_sub_header_t | ||
/*0a*/ u16 unknown_0a; // sequence id 2 or empty | /*0a*/ u16 unknown_0a; // sequence id 2 or empty | ||
/*0c*/ u16 client_slot; // client slot (0 to b) | /*0c*/ u16 client_slot; // client slot (0 to b) | ||
| − | /*0e*/ u16 data_length; // little endian, data length without | + | /*0e*/ u16 data_length; // little endian, data length without headers and checksum |
/*10*/ u32 unknown_10; // ? | /*10*/ u32 unknown_10; // ? | ||
/*14*/ u32 unknown_14; // sequence id 3? | /*14*/ u32 unknown_14; // sequence id 3? | ||
| Line 32: | Line 43: | ||
/*1c*/ u32 unknown_1c; // always 0x00000000 | /*1c*/ u32 unknown_1c; // always 0x00000000 | ||
} | } | ||
| − | __attribute__ ((packed)) | + | __attribute__ ((packed)) udp_sub_header_t; |
</pre> | </pre> | ||
| − | After the header | + | After the main header there may follow one or more sub headers including data, after all records there is a 16-byte-checksum which looks like a MD5 hash. |
== Record types == | == Record types == | ||
Revision as of 23:25, 26 December 2014
This page describes the network protocol used by Mario Kart 8. It is very incomplete at this moment.
General description
The Mario Kart 8 traffic starts with a name resolution. The loginserver (api-eu.olv.nintendo.net) has multiple IP addresses with a TTL of 60:
- 54.72.185.220
- 54.229.32.160
- 54.246.156.135
- 176.34.135.172
and maybe some more
First the game connects the Nintendoservers, while racing, all WiiUs communicate directly to each other.
All P2P packets have a header, a payload and a checksum
The P2P headers
There are two different headers: One header at the beginning of each packet ...
typedef struct udp_main_header_t
{
/*00*/ u32 game_magic; // always 32ab.9864
/*04*/ u32 unknown_04; //
/*08*/ u16 unknown_08; // sequence id?
}
__attribute__ ((packed)) udp_main_header_t;
... and one at the beginning of each record. A packet may contain multiple records.
typedef struct udp_sub_header_t /*0a*/ u16 unknown_0a; // sequence id 2 or empty /*0c*/ u16 client_slot; // client slot (0 to b) /*0e*/ u16 data_length; // little endian, data length without headers and checksum /*10*/ u32 unknown_10; // ? /*14*/ u32 unknown_14; // sequence id 3? /*18*/ u32 unknown_18; // ? /*1c*/ u32 unknown_1c; // always 0x00000000 } __attribute__ ((packed)) udp_sub_header_t;
After the main header there may follow one or more sub headers including data, after all records there is a 16-byte-checksum which looks like a MD5 hash.