Help with Character Info Packet

[tkblackbelt]

Ok So I'm working on a proxy, and I'm able to login and have a simple logger working. For some reason I don't seem to be receiving the 1006 packet that holds my login characters info. It must be getting through because the client is setup properly with my character name, etc...

Heres a screeny of the beginning of the login.

Packet Structer:

Edit: I think the info might be in the 2079 packet, not sure though I will analyze it.

[Lateralus]

Originally Posted by tkblackbelt

Ok So I'm working on a proxy, and I'm able to login and have a simple logger working. For some reason I don't seem to be receiving the 1006 packet that holds my login characters info. It must be getting through because the client is setup properly with my character name, etc...

Heres a screeny of the beginning of the login.

Packet Structer:

Edit: I think the info might be in the 2079 packet, not sure though I will analyze it.

It seems that there's a problem somewhere with your logger, as some of those packet types don't exist.

[koko425]

do you mind share your proxy i wana log some packets?

[tkblackbelt]

Originally Posted by Lateralus

It seems that there's a problem somewhere with your logger, as some of those packet types don't exist.

Ya I just downloaded Pros source to see what his was receiving and its a bit different than mine so Ill have to try some thing to fix the logger

Originally Posted by koko425

do you mind share your proxy i wana log some packets?

Ya I was actually planning on releasing the logger to help people learn about packets once it works decently.

[Korvacs]

You have a clear problem with the portion of your proxy that splits the packets, some of them have correct headers, but others are completely off.

[pro4never]

Aww korv beat me to it.

Set up your packet splitting properly.

You will receive (especially during login) large chunks of packets that need to be split up and read. Character info which you're looking for is one of them.

[tkblackbelt]

Ok I think I got it know It was as Korvacs said my splitters was screwed up. Heres a shot of it. Thanks!!!

[Lateralus]

Originally Posted by tkblackbelt

Ok I think I got it know It was as Korvacs said my splitters was screwed up. Heres a shot of it. Thanks!!!

There's still one that's incorrectly split - "17082"?

Though it does look better.

[Korvacs]

Originally Posted by Lateralus

There's still one that's incorrectly split - "17082"?

Though it does look better.

Judging from its length it will be the encryption packet that doesnt have a type in its header.

[tkblackbelt]

Ok One more question. Im using the authprotocol cryptographer available on the forum, but I'm interested in learning how you guys actually found out the encryption information. Did you basically load conquer.exe into ollydebug and analyze the Assembly to see how the client decrpyts the packets?

[pro4never]

Generally yes, people would reverse engineer the encryption via the client.

Thankfully the encryptions have been so nicely released to the public so there's nothing complex about them but anything besides the simple encryptions (IE: Spell encryption or w/e) is quite a bit of work to properly design from the ground up. That's why servers were stuck at 5017 for so long. Blowfish encryption was something only a few people had full solutions to and it was kept private up until coemu was released.

[tkblackbelt]

I've been trying to get the Client side jump to work for the past 2 hours but I'm stuck at one part of it. My serverside jump works perfect. So basically this is the raw packet


TYPE: 10010
LENGTH: 45

25 00 1A 27 F8 12 1F 00 68 00 BF 01 00 00 00 00 FA AA 9B 09 89 00 00 00 63 00 BD 01 36 04 00 00 00 00 00 00 00 54 51 53 65 72 76 65 72

ASCII: %'?h?
??? ?c?
6TQServer

Going To: TQCLIENT

The part in bold red I'm pretty sure is the time stamp, cause it has a ever increasing value. But unlike the server side timestamp I cant just use Environment.TickCount(C# function). So what I tried was when I recieve a jump packet I parse the timestamp and set another variable to the currrent tickcount, then when I send my own Client Jump packet I take the old timestamp + (currentTickcount - old tickcount) to get the current tick count. But that doesn't seem to work cause my screens not updating. Any advice would be appreciated.

[Lateralus]

Originally Posted by tkblackbelt

I've been trying to get the Client side jump to work for the past 2 hours but I'm stuck at one part of it. My serverside jump works perfect. So basically this is the raw packet


TYPE: 10010
LENGTH: 45

25 00 1A 27 F8 12 1F 00 68 00 BF 01 00 00 00 00 FA AA 9B 09 89 00 00 00 63 00 BD 01 36 04 00 00 00 00 00 00 00 54 51 53 65 72 76 65 72

ASCII: %'?h?
??? ?c?
6TQServer

Going To: TQCLIENT

The part in bold red I'm pretty sure is the time stamp, cause it has a ever increasing value. But unlike the server side timestamp I cant just use Environment.TickCount(C# function). So what I tried was when I recieve a jump packet I parse the timestamp and set another variable to the currrent tickcount, then when I send my own Client Jump packet I take the old timestamp + (currentTickcount - old tickcount) to get the current tick count. But that doesn't seem to work cause my screens not updating. Any advice would be appreciated.

Don't use Environment.TickCount. Import winmm.dll, and use timeGetTime - as that's what the client does. The client and server have different timestamps.

[Korvacs]

You could try pinvoking timeGetTime, its much more accurate than Enviroment.TickCount() however im not sure it would solve your problem to be honest.

[Lateralus]

Yeah, it won't. I think you have to force update your position. If there's a better way to do it, someone please prove me wrong; I force update in my proxy.