Offi Flyff Network Analyze

07/06/2017 12:37 Decrypted#1
Hello,
I am currently trying to analyze the current Network of the official Flyff (DE).

IP:
Code:
Login:
174.35.123.21
Port: 23000
World / Devos:
174.35.123.27
I started with simply receiving the Login Server packets.
Code:
Login Server Packet (8 Bytes actual content)
Login Server Packet (4 Bytes actual content)
-Disconnects- (Timeout)
I looked into an old server source and got a bit confused.
The first packet should be the session set packet.
The second would be a ping / keep alive packet.

The first 13 Bytes should be the Header:
Code:
#pragma pack(push,1)
struct SServerHeader
{
	uint8_t   m_bHeadMark;   // 0x5E (Didnīt change since source leak)
	uint32_t m_iLengthHash; // sure ?
	uint32_t m_iSize;
	uint32_t m_iDataHash;    // ?
};
#pragma pack(pop)
Like said above the first packet (SessionSet) results in a data size of 8. (m_iSize = 8).
The first 4 Bytes are always 0xcd0536d0.
The other 4 Bytes are random (Session ID?).

The second packet has 4 random bytes in it. (They change every time I connect).
So I wonder if the first 4 bytes like in the first packet are the packet id and if so how it gets calculated because the second packet id is random.
07/06/2017 14:28 Zerux#2
First of all I want to tell you that I am not going to explain everything in detail and that I will only explain how to basically decrypt their packet structure.
Indeed they have the following packet header:
Quote:
BTYE headermark
DWORD X ( i will just call it X as we won't need it for the decryption)
DWORD packetsize
DWORD Y (same as for X)
ENCRYPTED:
DWORD packetID
.......
As you might know they use a static XOR table to encrypt their data.

Quote:
BYTE xor_table[256] = {
0xD0, 0x36, 0x05, 0xCD, 0xA2, 0x0F, 0x00, 0xF9, 0xD7, 0x06, 0x93, 0x54, 0xBE, 0xB8, 0xEA,
0xFC, 0xD6, 0xF4, 0xFB, 0x4A, 0x34, 0x96, 0x09, 0xA8, 0xDF, 0xA5, 0x41, 0x3D, 0xD1, 0xC4,
0x6D, 0xD3, 0xBC, 0x4D, 0xB2, 0x61, 0x1C, 0x6C, 0x61, 0x62, 0x58, 0x3A, 0x00, 0x74, 0xB5,
0x51, 0xCE, 0xA3, 0x12, 0xB7, 0xE9, 0xB9, 0xF5, 0x0F, 0xC4, 0x57, 0x88, 0x7C, 0x50, 0x8B,
0x65, 0xB0, 0xD9, 0xC6, 0xC3, 0x0C, 0x8E, 0xA1, 0xB4, 0x0B, 0xBE, 0x37, 0x5A, 0xDC, 0x40,
0xDF, 0x5A, 0x05, 0xDF, 0x1B, 0xD7, 0x0D, 0xD2, 0xEE, 0xA0, 0x0A, 0xE2, 0x78, 0x8E, 0xE1,
0x0E, 0x98, 0x4E, 0x04, 0x83, 0x54, 0xFB, 0xD4, 0x4C, 0x65, 0xDE, 0x57, 0x29, 0x23, 0xB3,
0x66, 0x7A, 0x2E, 0xD8, 0x95, 0xD7, 0xA4, 0xB5, 0xFF, 0xE9, 0xBC, 0xA9, 0xCF, 0x7F, 0x30,
0xF2, 0x62, 0x00, 0x4E, 0xAE, 0x53, 0xDE, 0xBB, 0x0B, 0xAE, 0xD1, 0x6A, 0x2D, 0x02, 0xEF,
0x8D, 0x37, 0xD8, 0x3B, 0xF0, 0x4A, 0xD9, 0xD6, 0x66, 0x18, 0x78, 0x07, 0xC9, 0x39, 0x03,
0xB3, 0xC2, 0x85, 0x65, 0x30, 0xD8, 0x6B, 0x6B, 0x51, 0xF4, 0xC4, 0x2A, 0x6F, 0x2B, 0xD4,
0xBB, 0x30, 0xE2, 0x5D, 0x68, 0x1B, 0x02, 0x94, 0x61, 0x4A, 0xB8, 0x82, 0x08, 0xF4, 0xC1,
0x9E, 0xC5, 0x47, 0xB2, 0x1B, 0x01, 0xA5, 0x7B, 0x6C, 0x06, 0x95, 0xED, 0x93, 0x30, 0x24,
0xB4, 0xA3, 0xA6, 0xF2, 0x1C, 0xBD, 0xBD, 0x53, 0xB3, 0xCA, 0xBA, 0xC2, 0x8A, 0xD0, 0x6E,
0x77, 0xDB, 0x60, 0x16, 0xF7, 0x49, 0xA7, 0x67, 0x26, 0x61, 0x69, 0x47, 0x4D, 0x3E, 0x08,
0xE6, 0x63, 0x5C, 0x01, 0x6D, 0x3D, 0x2D, 0x7F, 0x6A, 0x0D, 0xBB, 0x91, 0x64, 0x6C, 0x97,
0x15, 0xDA, 0x2D, 0x49, 0x8C, 0xD3, 0x7C, 0xF3, 0x62, 0xDD, 0x1D, 0xDF, 0xD9, 0x67, 0xBF,
0xBA
};
For each connection they store two indexes of the table. For the receive and send packets.
The indexes are both 0 in the beginning and will be incremented for each byte they encrypt.
As the developers thought this would be easy "hackable" they thought of another feature:
Once a decrypted packetID equals zero the new indexes are contained in this packet.

Thats all, I hope it helps.