Difference between revisions of "MK8 Network Protocol"
Jump to navigation
Jump to search
m |
|||
(5 intermediate revisions by one other user not shown) | |||
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 | + | /*08*/ u16 timer; // Timer. Increases each 1/100 sec. |
+ | } | ||
+ | __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 | + | /*0c*/ u16 unknown_0c; // maybe client slot (0 to b), if unknown_0a not empty? |
− | /*0e*/ u16 data_length; // little endian, data length without | + | /*0e*/ u16 data_length; // little endian, data length without headers and checksum |
− | /*10*/ u32 | + | /*10*/ u32 receiver_slots; // Used slot bitmask of receiver (one or two bits set) |
− | /*14*/ u32 | + | // 0x0001 -> slot 0; 0x0200 -> slot 9; 0x0000 -> no slot assigned |
+ | /*14*/ u32 sender_pid; // profile ID / any unique ID of sender | ||
/*18*/ u32 unknown_18; // ? | /*18*/ u32 unknown_18; // ? | ||
/*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 == | ||
Line 41: | Line 53: | ||
* [[MK8_Network_Protocol/USERINFO|USERINFO]] | * [[MK8_Network_Protocol/USERINFO|USERINFO]] | ||
− | [[ | + | [[Category:Network Protocol|!]] |
− | |||
[[mkw:MKWii Network Protocol]] | [[mkw:MKWii Network Protocol]] |
Latest revision as of 16:53, 21 February 2017
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 timer; // Timer. Increases each 1/100 sec. } __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 unknown_0c; // maybe client slot (0 to b), if unknown_0a not empty? /*0e*/ u16 data_length; // little endian, data length without headers and checksum /*10*/ u32 receiver_slots; // Used slot bitmask of receiver (one or two bits set) // 0x0001 -> slot 0; 0x0200 -> slot 9; 0x0000 -> no slot assigned /*14*/ u32 sender_pid; // profile ID / any unique ID of sender /*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.