PRUDP packet format

• Example Packet
• VPort Structure
• Packet Type Flags Byte Structure
• Session ID
• Signature
• Sequence ID
• Connect Signature
• Part Number
• Payload Size
• Payload
• Checksum

struct PrudpPacket {
	VPort	m_oSourceVPort;
	VPort	m_oDestinationVPort;
	byte	m_byPacketTypeFlags;
	byte	m_bySessionID;
	uint	m_uiSignature;
	ushort	uiSeqId;
	uint	m_uiConnectionSignature;
	byte	m_byPartNumber;
	ushort	payloadSize;
	byte[]	payload;
	byte	checkSum;
}

Example Packet

3F 31 31 1F 78 56 34 12 01 00 01 00 26 7F 5E

UDPPacket {
	From         : VPort[port=15 type=OldRVSec]
	To           : VPort[port=01 type=OldRVSec]
	Flags        : [FLAG_NEED_ACK]
	Type         : SYN
	Session ID   : 0x00
	Signature    : 0x00000000
	Sequence ID  : 0x0000
	Conn. Sig.   : 0x00000000
	PayLoad      : 
	Checksum     : 0x73
}

VPort Structure

struct VPort {
	STREAMTYPE type;
	byte port;
}

VPort is a single byte that is split in upper nibble and lower nibble, the lower is the port (0-F) and the upper is a value of the following enum:

enum STREAMTYPE {
	DO = 1,
	RV = 2,
	OldRVSec = 3,
	SBMGMT = 4,
	NAT = 5,
	SessionDiscovery = 6,
	NATEcho = 7,
	Routing = 8,
	Game = 9,
	RVSecure = 10,
	Relay = 11
}

Packet Type Flags

This byte contains again 2 information. The upper 5 bits contain the flags and the lower 3 bits contain the packet type.

Research on other version of Quazal SDK proved that PRUDP packet types changed over years. Here are compared available types for 25 To Life (January 2006) and GRO (August 2012) Quazal versions.

25TL PRUDP QPacket Types (2006)

• SYN = 0
• CONNECT = 1
• DATA = 2
• DISCONNECT = 3
• PING = 4
• USER = 5
• ACK = 6
• RESET = 7

GRO PRUDP QPacket Types (2012)

• SYN = 0
• CONNECT = 1
• DATA = 2
• DISCONNECT = 3
• PING = 4
• USER = 5
• ROUTE = 6
• RAW = 7

Other PRUDP flags

• FLAG_ACK = 1
• FLAG_RELIABLE = 2
• FLAG_NEED_ACK = 4
• FLAG_HAS_SIZE = 8

Session ID

This is a unique ID that will be used in response packets to distinguish different sessions of a stream, its simply reused in the reply packet

Signature

In the first SYN response, the server sends an additional Connection ID, this is used by the client/game for further requests by the client as signature, so the server can distinguish between different clients. the client in his first CONNECT packet also has a connection signature field, which the server will use for all future responses.

Sequence ID

This is used to match request and response packets, in that both packets must have the same SeqID

Connection Signature

This field is ONLY present in the SYN and CONNECT packets and is used to assigned the other side a signature

Part Number

This field is ONLY present in DATA packets and is used to reassemble bigger DATA payloads

Payload Size

This field is ONLY present if the flag field contains FLAG_HAS_SIZE and contains the size of the following payload

Payload

This byte array are the rest of the packet bytes minus the checksum byte at the end, usually only DATA packets contain payloads, which in turn contain encrypted and compressed RMC packets. But on the first CONNECT packet by the client to the secure server, it also contains a payload, a kerberos ticket it request beforehand

Checksum

This byte is a checksum of all the packet bytes sofar with the key from yeti.ini