Eden Eternal Emulator

[afonsolage]

Hello Ragezoners!

Project is stopped, but i'll keep the infos to someone that want to keep thsi project. Dont know when I'll came back to it.

I didnt found any server files or emulator for this awesome game that I love it so much, so I want to start a project to make a emulator to this files.

I know this isnt a easy task and there is much work to do, but I think this will a great release to Ragezone community.

I've made already a Mu Online Emulator, so I know how those things are done, but I dont have much decrypt skills, so I want to start a public project, so any one can contribute with their knowledge.

It's easy to start deploying with Eden Eternal files, just need to install the client and modify some files.

The client looks for the file connect.ini to check the server IP, so I've made a sniff (in Java) and I got some packets. That's the first problem.

The server sends some kind of 256 bytes hash and the client responds with another 256bits hash, after that, they start to do the things with this encrypted packets.

The servers hash is statical, but the client responses hash is always new. The frist interation is a basic one, as follow:

1 - Server send the 256 byte hash to client;
2 - The client responds with another generated 256 byte hash;
3 - Server checks if clients hash is right and then send confirmation;
4 - Clients send the login and password encrypted to server;
5 - Server confirm or deny the credentials.

Those are the first four steps packets:

1 - Server's 256 bytes hash Packet (266 Bytes):

0, 1, 0, 0, 2, 0, 0, 0, 237, 82, 166, 126, 129, 156, 176, 88, 41, 172, 128, 39, 203, 137, 133, 254, 34, 8, 107, 9, 223, 81, 208, 171, 36, 140, 95, 38, 15, 58, 180, 180, 24, 167, 58, 11, 252, 230, 159, 129, 109, 162, 233, 210, 101, 120, 13, 157, 6, 164, 205, 140, 138, 141, 28, 43, 230, 2, 41, 31, 92, 161, 125, 222, 243, 222, 25, 163, 197, 1, 70, 179, 165, 10, 163, 129, 201, 77, 27, 85, 90, 192, 227, 241, 111, 73, 43, 52, 42, 113, 173, 135, 213, 245, 226, 41, 90, 208, 52, 1, 110, 200, 136, 230, 207, 57, 84, 64, 75, 1, 45, 35, 220, 61, 34, 150, 64, 95, 104, 64, 56, 57, 1, 185, 67, 28, 235, 250, 185, 91, 83, 45, 217, 245, 254, 236, 148, 50, 254, 154, 41, 66, 108, 70, 250, 251, 211, 126, 158, 60, 238, 245, 97, 39, 203, 121, 33, 130, 174, 227, 196, 138, 238, 194, 74, 228, 158, 95, 67, 110, 183, 94, 106, 223, 216, 13, 90, 72, 43, 203, 93, 9, 41, 253, 35, 3, 65, 179, 94, 123, 84, 135, 255, 214, 6, 30, 139, 32, 86, 232, 81, 193, 177, 148, 88, 88, 173, 198, 83, 188, 130, 211, 172, 37, 88, 224, 232, 142, 92, 39, 213, 219, 43, 156, 145, 35, 57, 247, 209, 6, 171, 160, 250, 134, 110, 120, 164, 245, 153, 113, 176, 211, 87, 158, 154, 20, 190, 31, 53, 67, 107, 164, 20, 91, 118, 23, 255, 255

Whereas the the 8 first bytes are the packet header (Dont have sure, but probabily)

0, 1, 0, 0, 2, 0, 0, 0

And the last 2 bytes are the footer:

255, 255

2 - And this is a client's response 256 bytes hash packet (256 bytes):

128, 181, 17, 249, 6, 135, 182, 34, 157, 246, 219, 251, 44, 177, 38, 61, 241, 193, 190, 97, 48, 141, 63, 71, 175, 67, 8, 90, 96, 118, 252, 230, 121, 121, 152, 81, 223, 13, 69, 215, 136, 160, 147, 183, 40, 255, 183, 225, 117, 239, 40, 39, 89, 195, 115, 36, 178, 83, 162, 20, 67, 7, 34, 159, 54, 93, 120, 158, 251, 200, 26, 34, 223, 162, 121, 7, 59, 172, 126, 176, 171, 174, 173, 205, 95, 12, 2, 62, 111, 136, 143, 112, 6, 153, 192, 123, 190, 91, 0, 97, 145, 56, 64, 70, 218, 83, 223, 40, 218, 156, 15, 39, 178, 171, 137, 72, 26, 10, 38, 91, 99, 219, 238, 175, 165, 34, 124, 147, 176, 97, 242, 167, 201, 162, 214, 153, 230, 65, 11, 47, 171, 66, 243, 242, 56, 149, 222, 184, 93, 222, 97, 165, 216, 1, 122, 186, 79, 162, 115, 4, 82, 198, 143, 113, 245, 215, 2, 181, 177, 236, 92, 198, 119, 89, 112, 196, 200, 148, 230, 104, 97, 150, 24, 206, 240, 26, 141, 197, 62, 121, 68, 103, 57, 153, 235, 44, 172, 178, 135, 32, 61, 228, 229, 89, 123, 221, 216, 105, 193, 223, 55, 193, 111, 187, 145, 44, 80, 125, 107, 91, 39, 61, 51, 84, 76, 60, 189, 8, 160, 107, 202, 244, 240, 133, 206, 48, 44, 79, 232, 164, 39, 132, 167, 118, 34, 103, 227, 204, 39, 149, 126, 206, 76, 148, 220, 15

3 - Servers hash ok confirmation (8 bytes):

6, 0, 101, 228, 222, 218, 245, 166

Whereas the first 2 bytes are the header:

6, 0

4 - The client sends login and password to server:

39, 0, 135, 191, 160, 229, 73, 124, 153, 91, 244, 93, 159, 251, 217, 144, 193, 209, 51, 91, 189, 140, 250, 33, 171, 54, 250, 169, 206, 159, 202, 0, 240, 187, 6, 135, 56, 195, 227, 236, 198

Whereas the frist two bytes are the header and it indicates the contents packet size:

39, 0

The packet's content are a test username and a test password. Dont know how they are stored on this packet, but i've made two tests. The packet above use the login: ****** and the password *******. The bellow uses the name login but the password ********:

40, 0, 249, 29, 203, 35, 25, 187, 39, 58, 240, 148, 104, 45, 0, 117, 67, 149, 196, 115, 37, 239, 105, 241, 237, 239, 58, 198, 33, 221, 68, 255, 96, 79, 182, 190, 140, 165, 139, 233, 56, 29

This is what a got yesterday. I'll keep trying to decrypt those packets and understand this pattern, but if someone wants to join the project, just need to download the Eden Eternal clients, and start replying this topic.

Thanks for reading it.

 

[afonsolage]

Hello folks,

After many tests I think this encryption system is either ARC4 or RSA-2048. I've made many tests using ARC4 with the simple bellow class, but no one worked.

What is making me confuse is the 256 Bytes hash packet that clients sends. If so, I think there is some kind of two way RSA-2048 encryption system, whereas the server sends the public key to client and the client sends its own generated public key to server, so both keeps their private key and uses it to decrypt the received data.

If so, this is more simple to implement, but hard to take a proof and to reverse. My next test is to implement a RSA-2048 system and try to send to client the public key and see what I got. If it works, I should be able to decrypt data with my own generated private key.

If some one wants to comment, give me a tip or get involved on this project, just reply on this topic. You are welcome.

public class ARC4 {
	public static byte[] work(byte[] value, byte[] key){
		//KSA
		byte[] S = new byte[256];
		
		for (int i = 0; i < 256; i++){
			S[i] = (byte)i;
		}
		byte tmp = 0;
		int j = 0;
		for (int i = 0; i < 256; i++){
			j = (j + S[i] + key[i % key.length]) & 0xFF;
			tmp = S[i];
			S[i] = S[j];
			S[j] = tmp;
		}
		
		//PRGA
		int i = 0;
		j = 0;
		
		byte[] result = new byte[value.length];
		for (int k = 0; k < value.length; k++){
			i = (i + 1) & 0xFF;
			j = (j + S[i]) & 0xFF;
			tmp = S[i];
			S[i] = S[j];
			S[j] = tmp;
			result[k] = (byte)(S[(S[i] + S[j] & 0xFF)] ^ value[k]);
		}
		
		return result;
	}
	
}

EDIT:
After using one ARC4 derivation, the RC4A(thanks to tip on this @jonnybravo's post), with the clients login packet data and the client generated key, I got a interesting result:

%?·Ò¬É÷ùGôÖÓkšf
ùÞÁçQ˜‰åX…ã
3Ù î2Ì"

For some reason, it got three line breaks, and the last one is the same size as the test password (*********) and the middle line got 12 characters, one character more then test login (*******)...This can be coincidence? Maybe, but i'll look a bit more.

RC4A class:

public class RC4A {
	public static byte[] work(byte[] value, byte[] key){
		//KSA
		byte[] S1 = new byte[256];
		byte[] S2 = new byte[256];
		
		for (int i = 0; i < 256; i++){
			S1[i] = (byte)i;
			S2[i] = (byte)i;
		}
		
		byte tmp = 0;
		{
			int j = 0;
		
			for (int i = 0; i < 256; i++){
				j = (j + S1[i] + key[i % key.length]) & 0xFF;
				tmp = S1[i];
				S1[i] = S1[j];
				S1[j] = tmp;
			}
			
		}
		//PRGA
		int i = 0;
		int j1 = 0;
		int j2 = 0;
		
		byte[] result = new byte[value.length];
		for (int k = 0; k < value.length; k++){
			i = (i + 1) & 0xFF;
			
			j1 = (j1 + S1[i]) & 0xFF;
			tmp = S1[i];
			S1[i] = S1[j1];
			S1[j1] = tmp;
			result[k] = (byte)(S2[(S1[i] + S1[j1] & 0xFF)] ^ value[k]);
			
			j2 = (j2 + S2[i]) & 0xFF;
			tmp = S2[i];
			S2[i] = S2[j2];
			S2[j2] = tmp;
			result[k] = (byte)(S1[(S2[i] + S2[j2] & 0xFF)] ^ value[k]);
		}
		return result;
	}
	
}

EDIT2:
Yes, sadly it was just coincidence...moving to test with RSA-2048.

Thanks for reading it.

 

[lastfun]

I think, sha1 (256) + rsa (open key? 8 6 bytes?)
try to do it

 

[afonsolage]

I think, sha1 (256) + rsa (open key? 8 6 bytes?)
try to do it

I dont think it would be SHA1, because if it was, all packets should have the same length. No?

EDIT:

99% sure that it uses OpenSSL:

EDIT2:
And maybe 66666667 is the prime number used by the client?

And what is this "p6v"?. I saw it arround all the code.

Well, I'll keep the work. If someone want to help, just reply to it.

 

[masterpop2014]

Help me xD

 

[Anthony Saints]

Any news ?

 

[wowfifa]

Working on a new one to run on the lastest GDMO client

Atm only basic login, lobby server, packets have changed a lot from this emulator from Shiro's

Need to redo everything.

____________________
RS Gold

 

[masterpop2014]

Tell me how I can help I am a systems analyst.

 

[Nothilvien]

From your packet data i woud strongly assume the first two bytes are always the packet size.

0, 1, 0, 0, 2, 0, 0, 0, 237,.............

the first two bytes seems an int16, (0,1) representing 256 = exact size of the data to read (packet size)

- Servers hash ok confirmation (8 bytes):

6, 0, 101, 228, 222, 218, 245 , 166

here the first two bytes represent 6, so means ur data packet is 6 bytes long.

so you can assume this for all packets.
the packet structure seems like

[Int16 (size)] [data]

i also assume that after the first two bytes another fixed length is (another int16 or in 32) indicating a packet id. and the rest will be the data.


Also, i belive it makes no sense to analyze the client packets without knowing the encryption. because the only thing not encrypted is packet size, the rest of the client to server packets is encrypted. so you shoud focus on the packets you recive from the server, they seem to be unencrypted!

another thing you could try is to block the server encryption key packet, maybe your client will send the packets without encryption then.