PlayerID ShortNameLength LongNameLength ServiceProviderDataSize PlayerDataSize NumberOfPlayers SystemPlayerID FixedSize PlayerVersion ParentID ShortName (variable) ... LongName (variable) ... ServiceProviderData (variable) ... PlayerData (variable) ... PlayerIDs (variable) ... Size (4 bytes): MUST contain the total size of the DPLAYI_PACKEDPLAYER structure plus the values of the ShortNameLength, LongNameLength, ServiceProviderDataSize, and PlayerDataSize fields. Flags (4 bytes): MUST contain 0 or more of the following player flags. 0 1 2 3 4 5 6 7 8 9 1 0 1 2 3 4 5 6 7 8 9 2 0 1 2 3 4 5 6 7 8 9 3 0 1 S P N S P G P L X SP (1 bit): The player is the .
SessionName (variable): Null-terminated Unicode string that contains the game session name. Password (variable): Null-terminated Unicode string that contains the password. PlayerInfo (variable): MUST be set to an array of DPLAYI_PACKEDPLAYER (section ) structures. Each entry can hold either group information or player information. The same structure is used for groups and players. Player entries are followed by group entries. The number of entries in the array can be found by adding the PlayerCount and GroupCount fields. DPSP_MSG_ENUMSESSIONS The DPSP_MSG_ENUMSESSIONS packet is sent by the client to request an enumeration of DirectPlay 4 game sessions. 0 1 2 3 4 5 6 7 8 9 1 0 1 2 3 4 5 6 7 8 9 2 0 1 2 3 4 5 6 7 8 9 3 0 1 DPSP_MSG_HEADER (28 ... ... ApplicationGuid (16 ... ... PasswordOffset Flags Password (variable) ... DPSP_MSG_HEADER (28 bytes): Message header for this packet. The Command Value member of this field MUST be set to 2 (0x02). ApplicationGuid (16 bytes): MUST be set to the for the game. PasswordOffset (4 bytes): MUST be set to the offset, in octets, of the password from the beginning of the message. Flags (4 bytes): MUST be set to one or more of the specified enumeration game session flags passed in by the game. 0 1 2 3 4 5 6 7 8 9 1 0 1 2 3 4 5 6 7 8 9 2 0 1 2 3 4 5 6 7 8 9 3 0 1 AV AL X PR Y AV (1 bit): Enumerate game sessions that can be joined.
Security Security Considerations for Implementers The following security considerations pertain to the DirectPlay 4 Protocol: The DirectPlay 4 Protocol was not designed to be a secure protocol. Any application that requires end-to-end security would need to implement secure identity, and possibly encryption and/or packet signing. This is no different than the case where applications are built on sockets.<23> The only exploits that are prevented in DirectPlay 4 are problems where the formatting of a message could lead to a buffer overrun or cause a computer to crash. Since DirectPlay 4 was a sufficiently complex and proprietary protocol, used primarily in the domain of game applications, it was not anticipated that there would be much point in attacking the link. If an application required to secure a link, it could use the secure modes and packet signing that would prevent such exploits as mentioned above. The DirectPlay 4 Protocol does not perform validation on the sender of a message. An implementation may choose to validate the sender of a message, but it is not a requirement for compatibility with DirectPlay. Player IDs are assigned by the game session host and as a result, a new player has no way to "force" itself to become the new host. For more information, see section . Although player IDs are allocated sequentially (starting from a random value), the random value is XOR'd with a secret value to generate the player ID. As a result, there is no guarantee that the distributed player ID values will be sequential. From a security perspective, this manner of allocation is helpful because it generates values that cannot be easily guessed. If an implementation were to attempt to spoof a game and join the game session by accurately guessing a player ID value, the implementation would also have to recognize the secret value in order to be able to guess the next player ID. Index of Security Parameters None.
<3> Section 2.2.3: If the Windows Winsock DirectPlay Service Provider is used, the SL field is set to 0x1 in the PlayerInfoMask field, and the ServiceProviderDataLength field is set to 0x20. <4> Section 2.2.4: Windows sets the Size field to 0. <5> Section 2.2.4: An implementation should support at least one of the values shown in the following table. Algorithm Description OS versions exceptions Reference CALG_AES 0x00006611 Advanced Encryption Standard (AES). This algorithm is supported by the Microsoft AES Cryptographic Provider. Not supported in Windows NT, Windows 2000 and Windows XP. Supported in Windows XP operating system Service Pack 1 (SP1) CALG_3DES 0x00006603 Triple Data Encryption Standard (DES) encryption algorithm (3DES). Not supported in Windows NT and Windows 2000 For more information, see the entry for [TDEA] in section . CALG_DES 0x00006601 Data Encryption Standard (DES). Not supported in Windows NT and CALG_RC2 0x00006602 Rivest Cipher 2 (RC2) block encryption algorithm. This algorithm is supported by the Microsoft Base Cryptographic Provider. none CALG_RC4 0x00006801 RC4 stream encryption algorithm. This algorithm is supported by the Microsoft Base Cryptographic Provider. none
DirectPlay client 77 76 75 75 75 75 74 75 79 74 75 77 77 77 78 76 76 76 76 87 Host - game 86 87 87 91 87 86 87 timer events 90 90 timers 87 87 85 I 95 95 11 Initialization 74 74 87 8 J 93 L Local events 85 91 74 M Message processing 79 87 Messages 17 20 24 25 30 31 32 32 32 34 34 35 36 36 37 38 38 39 40 41 43 43 44 45 45 46 47 48 49 50 28 51 52 53 54 54 55 55 56 57 58 59 59 60 61 62 62 63 64 65 66 67 69 69 17 17 17 N Name Table Population Timer ( 87, 90) 10 O