Welcome!

Join our community of MMO enthusiasts and game developers! By registering, you'll gain access to discussions on the latest developments in MMO server files and collaborate with like-minded individuals. Join us today and unlock the potential of MMO server development!

Join Today!

[S.U.N Online] Encryption Algorithm

Junior Spellweaver
Joined
Oct 20, 2013
Messages
193
Reaction score
56
I am currently trying to figure out S.U.N's encryption algorithm, so I can decode the packets. I believe I have figured out some important information to help crack the algorithm, but I would like to have some help.

The information below is how the server and client interact up to the point of login:

1. Three-way Handshake
2. Client sends RST, ACK packet to Server
3. Three-way Handshake

4. Server to Client (hello packet)
TCP 44405 -> (client port - random #) Size: 72 bytes

5. Client to Server (ip packet)
TCP (client port) -> 44405 Size: 39 bytes (size can vary)

6. Server to Client (accept packet)
TCP 44405 -> (client port) Size: 5 bytes

7. Client to Server (login packet)
TCP (client port) -> 44405 Size: 83 bytes
I have been studying the retail server's packets. The only thing that changes is the "hello packet" (4th step) and the login packet (7th step).
Here is the five connection trials from the retail server for the "hello packet":

Test 1:

ASCII:
F 3 :.

Hex:
0x46, 0x00, 0x33, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x3a, 0x0f, 0x00, 0x00


Test 2:

ASCII:
F 3 <.

Hex:
0x46, 0x00, 0x33, 0x00, 0x00, 0x00, 0x00, 0x00,0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,0x00, 0x00, 0x00, 0x00, 0x3c, 0x0f, 0x00, 0x00


Test 3:

ASCII:
F 3 =.

Hex:
0x46, 0x00, 0x33, 0x00, 0x00, 0x00, 0x00, 0x00,0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,0x00, 0x00, 0x00, 0x00, 0x3d, 0x0f, 0x00, 0x00


Test 4:

ASCII:
F 3 >.

Hex:
0x46, 0x00, 0x33, 0x00, 0x00, 0x00, 0x00, 0x00,0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,0x00, 0x00, 0x00, 0x00, 0x3e, 0x0f, 0x00, 0x00


Test 5:

ASCII:
F 3 ?.

Hex:
0x46, 0x00, 0x33, 0x00, 0x00, 0x00, 0x00, 0x00,0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,0x00, 0x00, 0x00, 0x00, 0x3f, 0x0f, 0x00, 0x00
I noticed that the tail end of the "hello" packet changes very slightly every time you connect to the retail server. I believe it is a key of some sort, whether its an initialization vector, one key pair, and etc. Every time the key changes the login packets change dramatically, so instead, I made that "key" static on my server end to try and figure out the algorithm.

The information below is from my own server.

Interaction between my server and the client up to the point of login:

1. Three-way Handshake
2. Client sends RST, ACK packet to Server
3. Three-way Handshake

4. Server to Client (hello packet)
TCP 44405 -> (client port - random #) Size: 72 bytes

ASCII:
F 3 $H

Hex:
0x46, 0x00, 0x33, 0x00, 0x00, 0x00, 0x00, 0x00,0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,0x00, 0x00, 0x00, 0x00, 0x24, 0x48, 0x00, 0x00

5. Client to Server (ip packet)
TCP (client port) -> 44405 Size: 39 bytes

6. Server to Client (accept packet)
TCP 44405 -> (client port) Size: 5 bytes

7. Client to Server (login packet)
TCP (client port) -> 44405 Size: 83 bytes
I kept the "key" on the "hello" packet to $H, so this is what the login packets look like:

Test 1:

Username: test
Password: test

ASCII:
Q 3. TEST .{. ..y .|. @.. 8.....w.......u...%@.. 8...-...ZK... .1neu...._..t

Hex:
0x51, 0x00, 0x33, 0x03, 0x00, 0x00, 0x00, 0x00,0x54, 0x45, 0x53, 0x54, 0x00, 0x00, 0xd4, 0x7b,0x19, 0x00, 0xe0, 0x8a, 0x79, 0x00, 0x04, 0x7c,0x19, 0x00, 0x40, 0x80, 0x19, 0x00, 0x38, 0xe4,0x15, 0x0a, 0xe9, 0x9c, 0xdb, 0x77, 0xfa, 0xff,0xff, 0x7f, 0x1f, 0x11, 0x8d, 0x75, 0x97, 0xe4,0xa7, 0x25, 0x40, 0x80, 0x19, 0x00, 0x38, 0xe4,0x15, 0x0a, 0x13, 0x2d, 0xc0, 0xa8, 0xd5, 0x5a,0x4b, 0x02, 0x0e, 0xf4, 0x09, 0xb4, 0x31, 0x6e,0x65, 0x75, 0x7f, 0x1d, 0x83, 0xd6, 0x5f, 0xca,0x06, 0x74, 0x0a


Test 2:

Username: test
Password: test

ASCII:
Q 3. TEST .{. ..y .|. @.. .( ....w.......u....@.. .( .2n...|.`......A....._..t

Hex:
0x51, 0x00, 0x33, 0x03, 0x00, 0x00, 0x00, 0x00,0x54, 0x45, 0x53, 0x54, 0x00, 0x00, 0xd4, 0x7b,0x19, 0x00, 0xe0, 0x8a, 0x79, 0x00, 0x04, 0x7c,0x19, 0x00, 0x40, 0x80, 0x19, 0x00, 0xd8, 0x28,0x00, 0x17, 0xe9, 0x9c, 0xdb, 0x77, 0xfa, 0xff,0xff, 0x7f, 0x1f, 0x11, 0x8d, 0x75, 0xad, 0xe6,0xfe, 0xaa, 0x40, 0x80, 0x19, 0x00, 0xd8, 0x28,0x00, 0x17, 0x32, 0x6e, 0x1f, 0xc4, 0xf8, 0x7c,0x87, 0x60, 0xc8, 0xc2, 0xbb, 0x87, 0x88, 0xc0,0x41, 0xbc, 0xf7, 0x1d, 0x83, 0xd6, 0x5f, 0xca,0x06, 0x74, 0x0a


Test 3:

Username: test
Password: test

ASCII:
Q 3. TEST .{. ..y .|. @.. .......w.......u.8..@.. .......1..~.UD.....Q,..._..t

Hex:
0x51, 0x00, 0x33, 0x03, 0x00, 0x00, 0x00, 0x00,0x54, 0x45, 0x53, 0x54, 0x00, 0x00, 0xd4, 0x7b,0x19, 0x00, 0xe0, 0x8a, 0x79, 0x00, 0x04, 0x7c,0x19, 0x00, 0x40, 0x80, 0x19, 0x00, 0x10, 0xaa,0x11, 0x16, 0xe9, 0x9c, 0xdb, 0x77, 0xfa, 0xff,0xff, 0x7f, 0x1f, 0x11, 0x8d, 0x75, 0xc5, 0x38,0xb2, 0xba, 0x40, 0x80, 0x19, 0x00, 0x10, 0xaa,0x11, 0x16, 0xab, 0x83, 0xcf, 0x31, 0xe1, 0xc3,0x7e, 0x99, 0x55, 0x44, 0x99, 0xd3, 0xc5, 0x9d,0x18, 0x51, 0x2c, 0x1d, 0x83, 0xd6, 0x5f, 0xca,0x06, 0x74, 0x0a


Test 4:
Username: test
Password: test

ASCII:
Q 3. TEST .{. ..y .|. @.. .y.....w.......uxT(.@.. .y....s.5o.Rdr...V|....._..t

Hex:
0x51, 0x00, 0x33, 0x03, 0x00, 0x00, 0x00, 0x00,0x54, 0x45, 0x53, 0x54, 0x00, 0x00, 0xd4, 0x7b,0x19, 0x00, 0xe0, 0x8a, 0x79, 0x00, 0x04, 0x7c,0x19, 0x00, 0x40, 0x80, 0x19, 0x00, 0xd8, 0x79,0x13, 0x16, 0xe9, 0x9c, 0xdb, 0x77, 0xfa, 0xff,0xff, 0x7f, 0x1f, 0x11, 0x8d, 0x75, 0x78, 0x54,0x28, 0x83, 0x40, 0x80, 0x19, 0x00, 0xd8, 0x79,0x13, 0x16, 0xae, 0x88, 0x73, 0xf8, 0x35, 0x6f,0x9e, 0x52, 0x64, 0x72, 0x08, 0xa2, 0xe6, 0x56,0x7c, 0x0f, 0xed, 0x1d, 0x83, 0xd6, 0x5f, 0xca,0x06, 0x74, 0x0a


Test 5:

Username: test
Password: test

ASCII:
Q 3. TEST .{. ..y .|. @.. ..{....w.......u...H@.. ..{.dq....i.,. .Z...f..._..t

Hex:
0x51, 0x00, 0x33, 0x03, 0x00, 0x00, 0x00, 0x00,0x54, 0x45, 0x53, 0x54, 0x00, 0x00, 0xd4, 0x7b,0x19, 0x00, 0xe0, 0x8a, 0x79, 0x00, 0x04, 0x7c,0x19, 0x00, 0x40, 0x80, 0x19, 0x00, 0xe0, 0xe6,0x7b, 0x16, 0xe9, 0x9c, 0xdb, 0x77, 0xfa, 0xff,0xff, 0x7f, 0x1f, 0x11, 0x8d, 0x75, 0xa7, 0xda,0x82, 0x48, 0x40, 0x80, 0x19, 0x00, 0xe0, 0xe6,0x7b, 0x16, 0x64, 0x71, 0xe4, 0x91, 0xda, 0xab,0x69, 0xb3, 0x2c, 0xa9, 0x00, 0xe2, 0x5a, 0xe8,0x11, 0x1a, 0x66, 0x1d, 0x83, 0xd6, 0x5f, 0xca,0x06, 0x74, 0x0a
All the older C++ S.U.N files use TEA (tiny encryption algorithm), Base64, MD5, and SHA1. I know this is not a hash algorithm because I wouldn't be able to reverse it. Then I noticed some of the other Webzen games have custom algorithms, so I am a bit confused.

Any help would be greatly appreciated.
 
Experienced Elementalist
Joined
Jan 30, 2010
Messages
267
Reaction score
129
Seems so but also looks like you don't have the key.

From what i've gathered of it, it encrypts the first 8 bytes of void* src and passes those 8 bytes thru the encryption 32 times,then saves them.

Which at Handler_CS::OnSUN_C2S_ASK_AUTH would be:
0x31, 0x32, 0x33, 0x34, 0x35, 0x36, 0x37, 0x38, 0x39, 0x00, 0x67, 0xa6, 0x53, 0x00, 0x06, 0x00, 0x00, 0x00, 0x00 after copying password to passmask and the result would be:

0x65, 0x96, 0x18, 0x92, 0xCE, 0x7B, 0x8A, 0x08, 0x39, 0x00, 0x67, 0xA6, 0x53, 0x00, 0x06, 0x00, 0x00, 0x00, 0x00

And i used this on c# to get the aboveresult and see if i could understand more of it:
class Encode
{
unsafe public Encode(byte* source,int[] key)
{
int* sourcepointer = (int*)source;
int firstfourbytes = *(int*)sourcepointer;
int secondfourbytes = *(int*)(sourcepointer + 1);
int key1 = key[0];
int key2 = key[1];
int key3 = key[3];
int key4 = key[2];
int var_edx = 0;

for (int i = 0; i < 32; i++)
{
int part1_shift_left = (secondfourbytes << 4) + key1; // (ecx<<4)+key1;
int part1_shift_right = (secondfourbytes >> 5) + key2; // (ecx>>5)+key2;
int part1_xor = part1_shift_left ^ part1_shift_right; // part1_shift_left^part1_shift_right;

var_edx -= 0x61c88647;
int value = var_edx + secondfourbytes; // value = var_edx+ecx;
int part2_xor = part1_xor ^ value;

firstfourbytes = firstfourbytes + part2_xor; // eax = eax+part2_xor;
int part2_shift_left = (firstfourbytes >> 5) + key3; // var = (eax>>5)+key3;
int part2_shift_right = (firstfourbytes << 4) + key4; // var_eax_1 = (eax<<4)+ key4;
int var_xor = part2_shift_left ^ part2_shift_right; // var_xor = var^var_eax_1;

int var_ebx = firstfourbytes + var_edx; // var_ebx = eax+var_edx;
int var_esi = var_xor ^ var_ebx;
secondfourbytes = secondfourbytes + var_esi; // ecx = ecx+var_esi;
}

*(int*)sourcepointer = firstfourbytes; // *(DWORD*)psrc= eax;
*(int*)(sourcepointer + 1) = secondfourbytes; // *(DWORD*)(psrc+1) = ecx;
}
}

unsafe {
fixed (byte* passMask = new byte[19] { 0x31, 0x32, 0x33, 0x34, 0x35, 0x36, 0x37, 0x38, 0x39, 0x00, 0x67, 0xa6, 0x53, 0x00, 0x06, 0x00, 0x00, 0x00, 0x00 }) // passMask with pwd in it.
{
int[] key = new int[4];
Encode encode = new Encode(passMask, key);
byte[] bytes = new byte[19];
for (int i = 0; i < 19; ++i) {
bytes = Marshal.ReadByte((IntPtr)passMask, i);
Console.Write(bytes.ToString("X2") + " ");
}
}
}
Console.ReadKey();
 
Last edited:
Upvote 0
Junior Spellweaver
Joined
Oct 20, 2013
Messages
193
Reaction score
56
@GoldenHeaven

Thank you for all the help. I really do appreciate it. After digging around some more, I found out that the encryption algorithm I posted was TEA. The parameters are the same data types in size, but one is unsigned and the other is signed. The Delta in the previous post (0x61C88647) is the twos complement of the original delta (0x9e3779b9). The rest of the algorithm looks very close to the one found online.


#include <stdint.h>

void encrypt (uint32_t* v, uint32_t* k)
{
// setup
uint32_t v0=v[0], v1=v[1], sum=0, i;

// a key schedule constant
uint32_t delta=0x9e3779b9;

// cache key
uint32_t k0=k[0], k1=k[1], k2=k[2], k3=k[3];

// basic cycle start
for (i=0; i < 32; i++)
{
sum += delta;​
v0 += ((v1<<4) + k0) ^ (v1 + sum) ^ ((v1>>5) + k1);
v1 += ((v0<<4) + k2) ^ (v0 + sum) ^ ((v0>>5) + k3);​
}
v[0]=v0; v[1]=v1;​
}

void decrypt (uint32_t* v, uint32_t* k)
{
//setup
uint32_t v0=v[0], v1=v[1], sum=0xC6EF3720, i;


// a key schedule constant
uint32_t delta=0x9e3779b9;

// cache key
uint32_t k0=k[0], k1=k[1], k2=k[2], k3=k[3];


// basic cycle start​
for (i=0; i<32; i++)
{​
v1 -= ((v0<<4) + k2) ^ (v0 + sum) ^ ((v0>>5) + k3);​
v0 -= ((v1<<4) + k0) ^ (v1 + sum) ^ ((v1>>5) + k1);
sum -= delta;​
}
v[0]=v0; v[1]=v1;​
}
I found a in the SunEmu project. I opened it up with 7-Zip and found .obj files for Base64, LZO, md5, minilzo, PacketCrypt, Seedx, sha1, and Tea. I opened up the PacketCrypt.obj file and looked at the files. The files references to Tea encryption and decryption and itself. I only have the header files for Tea and PacketCrypt. I know this information doesn't mean much in the long run since I can't rebuild it without the .cpp files.


PacketCrypt.h
namespace Crypt
{
bool PacketEncode( unsigned char* source, int sourceLen, unsigned char* output, int* outputLen, DWORD key );
bool PacketDecode( unsigned char* source, int sourceLen, unsigned char* output, int* outputLen, DWORD key );​
}

Tea.h
namespace Crypt
{
void TeaEncode( DWORD* data, DWORD* key );
void TeaDecode( DWORD* data, DWORD* key );​
}

If TEA is being used as the main encryption algorithm, then how does the PacketCrypt prototypes work with the TEA algorithm. I was thinking double encryption, but that is just a thought. At the moment, I am looking for the key. Let me know what you think. Thanks!
 
Upvote 0
Experienced Elementalist
Joined
Jan 30, 2010
Messages
267
Reaction score
129
If you notice it appears to allow size specification which TEA doesn't care about possibly to allow only partial packet encryption.
That would be my guess as to why they didnt use TEA directly.
 
Upvote 0
Junior Spellweaver
Joined
Oct 20, 2013
Messages
193
Reaction score
56
Packet Information

All of the packet information is in decimal and not hexadecimal, so please remember that. This all I have currently figured out at this time. Sorry if this is a little repetitive.

Step 1-2: Handshake and Hello packet
1. Recieve active connection from client.
-> 3-way handshake

2. Server sends hello packet (Size: 72).

public byte[] helloPacket =
{70, 00, 51, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00,
00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00,
00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00,
00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00,
00, 00, 00, 00, 36, 72, 00, 00};

-> F 3 $H.
-> F (70) is the packet ID, 3 (51) is the server ID, and $H (36, 72) changes every time on retail server when you connect. I thought it was the key for the encryption algorithm, but it could be a session ID.

Step 3-4: Server IP and Acceptation packet
3. Client sends packet with IP.
-> IP is of the server the client is trying to connect to.

-> packet data: % 3 127.0.0.1 (37 51 01 03 04 06 49 50 55 46 48 46 48 46 49)
-> % (37) is packet ID, 3 (51) is server ID, (01), (03), (04), and (06) are unknown.

4. Send accept packet (Size: 5).

public byte[] acceptPacket = {03, 00, 51, 02, 00};
-> (03) is the packetID, 3 (51) is the server ID, and (02) is unknown.

Step 5-6: Encrypted Login and Login Status
5. Client will send packet with Username and Password (encrypted).

// --> TODO: Figure out the encryption algorithm.
// --> TODO: Decrypt packet data and compare account info.

6. Send packet back with login status. Size: 71. Fifth byte determines whether login was correct or not. (00 - correct, 01 - incorrect).

// successful login packet

public byte[] loginPacket =
{69, 00, 51, 14, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00,
00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00,
00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00,
00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00,
00, 00, 00, 00, 00, 00, 00};

-> (69) is packetID, 3 (51) is the serverID, the fourth byte changes and is unknown.

// incorrect password packet.

public byte[] loginPacket1 =
{69, 00, 51, 14, 01, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00,
00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00,
00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00,
00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00,
00, 00, 00, 00, 00, 00, 00};

Step 7-8: Confirmation and Server Selection packet
7. Client will send a confirmation packet.
-> (02, 00, 51, 15)
-> (02) is packet ID, 3 (51) is server ID, (15) is unknown

8. Send server list packet. Size: 83.

Server Name: Global (71, 108, 111, 98, 97, 108)
Channel Name: Channel 1 (67, 104, 97, 110, 110, 101, 108, 32, 49)

public byte[] serverListPacket =
{39, 00, 51, 17, 01, 71, 108, 111, 98, 97, 108, 00, 00, 00, 00, 00,
00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00,
00, 00, 00, 00, 00, 00, 01, 00, 01, 00, 00, 51, 18, 01, 67, 104,
97, 110, 110, 101, 108, 32, 49, 00, 00, 00, 00, 00, 00, 00, 00, 00,
00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 01,
01, 01, 01};

-> (39) is the packetID, 3 (51) is the serverID, fourth byte changes and is unknown, (01) is unknown but possibly starter and ender headers.

Step 9-10: Selected Server and Game Server Transfer packets
9. Client will send a server selection packet.

-> (04 00 51 19 01 01)
-> (04) is packet ID, 3 (51) is server ID, fourth byte changes and is unknown, and (01) are unknown.


10. Send Game Server IP to client. Size: 86

-> Data is partially encrypted.
-> Need further analysis on the retail packets.

public byte[] gsTransferPacket =
{84, 00, 51, 26, 00, 30, 85, 77, 24, 48, 72, 96, 120, 00, 00, 00,
00, 00, 8, 32, 56, 80, 104, 00, 00, 00, 00, 00, 00, 10, 40, 64,
88, 112, 00, 00, 00, 00, 00, 00, 49, 50, 55, 46, 48, 46, 48, 46,
49, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00,
00, 00, 00, 00, 00, 00, 00, 00, 34, 78, 00, 00, 00, 55, 110, 54,
103, 55, 55, 110, 107, 00};

Login Server and Client Download

Please visit here for more information.
 
Last edited:
Upvote 0
Initiate Mage
Joined
Dec 14, 2018
Messages
3
Reaction score
3
Small explanation about packets:
The packet construction is a bit different. First two bytes are the length of the message and should be calculated by the server. Next two are the type of message.

(HEX values because i like them more :eek:tt1:)

S -> Hello Packet
Message typeValue?Encryption key
Decimal51 0000, 00, 00, 00, 00, 00, 00, 00, 00, 00,
00, 00, 00, 00, 00, 00, 00, 00, 00, 00,
00, 00, 00, 00, 00, 00, 00, 00, 00, 00,
00, 00, 00, 00, 00, 00, 00, 00, 00, 00,
00, 00, 00, 00, 00, 00, 00, 00, 00, 00,
00, 00, 00, 00, 00, 00, 00, 00, 00, 00,
00, 00, 00, 00, 00
36, 72, 00, 00
HEX0x33 0x000x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00
0x24, 0x48, 0x00, 0x00

C -> Ip Packet
Message typeValue?Protocol ver.IP
Decimal51 010103 04 0649 50 55 46 48 46 48 46 49
HEX0x33 0x01

S -> Accept
Message typeValue
Decimal51 0200
HEX0x33 0x020x00

And so on...

There is a trap with messages 50 17 (server list) and 50 18 (channels) because there are two messages in one packet. But I'm working on it :eek:tt1:.
 
Last edited:
Upvote 0
Junior Spellweaver
Joined
Oct 20, 2013
Messages
193
Reaction score
56
@Baywatch Mitch
I will be honest, I never caught the protocol version numbers in the IP packet, but they do match. I want to say thank you for all of your help.


Crypto LIB

For anyone wanting to help finish the .c files that were reserved engineered by GoldenHeaven; here is the download . The Crypto LIB.rar file consists of tea.c, md5.c, packetcrypt.c, and two other files. The files were reserved engineered by an extension for IDA Pro as far as I know of.

Thank you for the help everyone!
 
Last edited:
Upvote 0
Initiate Mage
Joined
Dec 14, 2018
Messages
3
Reaction score
3
After a day of work I have a lot of new information. I think the last 4 bytes of Hello Packet are the encryption key. The others are probably some kind of message (maybe for future use?). I think I will write a separate topic with a description of the packets but I need some time to rewrite it from paper :p
 
Upvote 0
Junior Spellweaver
Joined
Oct 20, 2013
Messages
193
Reaction score
56
Baywatch Mitch

I thought the last two bytes on the hello packet was an encryption key but older SUN emulator files have Tiny Encryption Algorithm (TEA) as the packet encryption. In Ollydbg, the client references to bcrypt.dll. Im not good at this type of work, but I thought it was TEA. Publish what you have when you can and Ill look it over when I can.
 
Upvote 0
Junior Spellweaver
Joined
Oct 20, 2013
Messages
193
Reaction score
56
Hello everyone.
I know it has been a while, but I am here to post some updated information about the packets and later I will mention what @GoldenHeaven and I have been talking about regarding the encryption. All packet information will be in HEX.

Header
Code:
Packet ID     Server ID     Message ID     Flag
     #            33             #         0/1

Hello Packet [S2C]
Code:
Packet ID     Server ID     Message ID     Flag     Key
    46            33            00         None    24 48

[U]Size[/U]: 72 bytes
[U]Payload[/U]: 46 00 33 00 --- 24 48 00
Byte 5 - 69 are filler (00) or is the expansion space for the key

Protocol + Server IP Info [C2S]
Code:
Packet ID     Server ID     Message ID     Flag    Protocol                IP
    25            33            01         None    03 04 06     31 32 37 2e 30 2e 30 2e 31

[U]Size[/U]: 39 bytes
[U]Payload[/U]: 25 00 33 01 03 04 06 31 32 37 2e 30 2e 30 2e 31 -- 00
Bytes 17-38 are filler (00) or is the expansion for the IP (example: 127.0.0.1 --> SUN.LOGINFRONT2)

Confirmation [S2C]
Code:
Packet ID     Server ID     Message ID     Flag
    03            33            02          01

[U]Size[/U]: 5 bytes
[U]Payload[/U]: 03 00 33 02 01
[U]Flag[/U]: 00 (true) / 01 (false) - determines whether the client will proceed


Login (Encrypted) [C2S]
Code:
Packet ID     Server ID     Message ID     Flag     Username     Password
    51            33            03        Unknown      46           #

[U]Size[/U]: 83 bytes
[U]Payload[/U]: 51 00 33 03 00 00 00 00 46  00 --
[U]Flag[/U]: Bytes 5-8 are either part of the Flag or thought to be User ID/Session ID assigned from the server.
[U]Username[/U]: 1-21 bytes. Bytes 9-29 can be adjusted to fit the username.
[U]Password[/U]: Where username ends + 1 through byte 83. (Example: Username is one letter,
so Byte 9 + filler (00), so it will start on Byte 11. Or can be Byte 31-83.)
[U]Other[/U]: Username can be 1-21 characters long and the password cannot be any longer than 12 characters.

Confirm Login [S2C]
Code:
Packet ID     Server ID     Message ID     Flag     Message
    45            33            14          01         #

[U]Size[/U]: 71 bytes
[U]Payload[/U]: 45 00 33 14 01 00 -- 00
[U]Flag[/U]: 00 (true) / 01 (false) - determines whether or not the login information was correct
[U]Message[/U]: Bytes 7-70 are dedicated to message space (example: Incorrect Login. Username/Password didn't match.)

Accept [C2S]
Code:
Packet ID     Server ID     Message ID     Flag
    02            33            0f         None

[U]Size[/U]: 4 bytes
[U]Payload[/U]: 02 00 33 0f

Server Selection List [S2C]
Code:
Packet ID     Server ID     Message ID     Flag
    27            33            17        Unknown

[U]Size[/U]: 83 bytes
[U]Payload[/U]: 27 00 33 17 --

Confirm Server & Channel [C2S]
Code:
Packet ID     Server ID     Message ID     Flag     Server#     Channel#
    04            33            13         None       01           01

[U]Size[/U]: 6 bytes
[U]Payload[/U]: 04 00 33 13 01 01
[U]Server#[/U]: Can change depending on the Server Selection packet. If there is two servers then will
be either 01 or 02.
[U]Channel#[/U]: Can change depending on the Server Selection packet. If there is two channels then
will be either 01 or 02.

Game Server Transfer [S2C]
Code:
Packet ID     Server ID     Message ID     Flag
    54            33            26       Unknown

[U]Size[/U]: 86 bytes
[U]Payload[/U]: 54 00 33 26 00 --
NOTICE: Packets will be updated again later. I have to do some more testing and gather more data to figure out the Server Selection and Game Server Transfer packets.
 
Last edited:
Upvote 0
Joined
Sep 27, 2006
Messages
557
Reaction score
88
So had a few questions?

1. Are you creating this emulator from scratch or basing it off some old source?
2. Why not just nop the encryption and decryption out of the client so you don't have to deal with it
3. v1007 is based on what version of the china, kr, jp version related to the official servers
4. there is also a possible to create a packet re builder that breaks the packet down into its byte form
grab the structure then the buffer array that fills it and then parse the data from there.

This all depends on how they are sending and receiving the data.
 
Upvote 0
Experienced Elementalist
Joined
Jan 30, 2010
Messages
267
Reaction score
129
1) from scratch
2) then ud have clean pwds (because as i said bellow we are looking at pwd encryption now not the packets due to misconception), turns out there packets that are encrypted but only a few and those possibly use SimpleModulus as refered in docs.
3) its chinese and old... Ep1.
4) thats what you do when you know what the encryption is... So far we know from docs its simplemodulus the problem now is pwd encryption, we thought initially that the packets were encrypted after pressing the login btn but that seems to not be the case.

So to keep you guys updated we are currently trying to find pwds encryption.
 
Upvote 0
Junior Spellweaver
Joined
Oct 20, 2013
Messages
193
Reaction score
56
So had a few questions?

1. Are you creating this emulator from scratch or basing it off some old source?
2. Why not just nop the encryption and decryption out of the client so you don't have to deal with it
3. v1007 is based on what version of the china, kr, jp version related to the official servers
4. there is also a possible to create a packet re builder that breaks the packet down into its byte form
grab the structure then the buffer array that fills it and then parse the data from there.

This all depends on how they are sending and receiving the data.
@jonnybravo

1. The the emulator is being built from scratch. The source code available has no documentation, comments, or any direction. On top of that, I can't code well enough to do an entire project in C++.

2. I am not sure how to remove encryption from a prebuilt executable, but our goal is to figure out the encryption so we can work with it and not remove it completely.

3. We are using the official Chinese SUN client v1007. The client itself is very old and the earlier versions (v1004) were release in China around 2006.

4. The packets are not the issue. I am only releasing packet information to possibly help learn more about the encryption itself. I learned that the first packet does contain the key as it changes every time you relog on the official server.
 
Upvote 0
Junior Spellweaver
Joined
Oct 20, 2013
Messages
193
Reaction score
56
Here is some more information about the encryption algorithm and the login credentials.
Username can be any length from 1 to 50 bytes and the password can be any length from 1 to 12 bytes. With the username and password being maxed out in length, the packet from the client looks like the one below:

logi - [S.U.N Online] Encryption Algorithm - RaGEZONE Forums

So the plain text goes from 12 bytes to 24 bytes of cipher text. At the moment, we still believe the key to be either 2 or 4 bytes. If anyone has any clue on what the algorithm could possible be, please leave a comment. Thank you!

Username is 50 f's and the password is 12 f's.
 

Attachments

You must be registered for see attachments list
Upvote 0
Joined
Aug 6, 2005
Messages
550
Reaction score
296
Can you post some more examples, e.g. all g’s (or other characters) and maybe abcdefghijkl as passwords?
Otherwise it’s really hard to guess where the password starts in the encrypted values ;)

Thanks
 
Upvote 0
Junior Spellweaver
Joined
Oct 20, 2013
Messages
193
Reaction score
56
@nevS
I probably should have posted more examples in my last post. I did ten more test logins to post and you are more than welcome to download the login server and client on the development thread to give it a try yourself (if you want or have the time). GoldenHeaven mentioned to me that the username could be receiving padding when the length doesn't reach 50 bytes in total. It sounds more reasonable than the password expanding between 24 up to 72 bytes (after padding + encryption). Anyway, let me know what you think. Thanks!

TestLogins_04-03-2019 - [S.U.N Online] Encryption Algorithm - RaGEZONE Forums
 

Attachments

You must be registered for see attachments list
Upvote 0
Initiate Mage
Joined
May 9, 2019
Messages
40
Reaction score
25
Hello, I will continue the work of Mitch because of his lack of time :):. Currently I have done a large part of the "Auth Server" with working password encryption (I am able to encode and decode the password). In the near future I will create a github repository because I think the code will be the best explanation.

PS: It's nice to know that someone else remembers about this game :eek:tt1:.
PS2: It would be nice if someone could run the English version of the client.
 
Upvote 0
Experienced Elementalist
Joined
Jan 30, 2010
Messages
267
Reaction score
129
Hello, I will continue the work of Mitch because of his lack of time :):. Currently I have done a large part of the "Auth Server" with working password encryption (I am able to encode and decode the password). In the near future I will create a github repository because I think the code will be the best explanation.

PS: It's nice to know that someone else remembers about this game :eek:tt1:.
PS2: It would be nice if someone could run the English version of the client.

Last time i tried the english version i had problems with win10 i might retry in the future, but that might take some time due to unpacking the EXE and removing the guard again for confort when using it.

P.S: what was the pwd encryption algorithm?
 
Upvote 0
Initiate Mage
Joined
May 9, 2019
Messages
40
Reaction score
25
P.S: what was the pwd encryption algorithm?

As it was mentioned somewhere this is the TEA algorithm. I was based on the available code in c ++, but it is quite strange (I think this may be code generated from disassembler). After refactoring, it turned out to be a regular TEA algorithm. The client uses a random mask for encryption, but you do not need to know it when decrypting :):.

PS: my GitHub repo:
 
Upvote 0
Experienced Elementalist
Joined
Jan 30, 2010
Messages
267
Reaction score
129
ahahah i kept pissing off ashime saying it was TEA but we never truthfully find out the sizes and specifics
either way thanks, ashime contact when you have time...
 
Last edited:
Upvote 0
Junior Spellweaver
Joined
Oct 20, 2013
Messages
193
Reaction score
56
@CwaniX
Your code works wonderful. Thank you for all of your help and I highly appreciate it. I did add your name to the source code and gave a link to your gitHub. If you have any questions or concerns, please private message me. Thank you!
 
Upvote 0
Back
Top