[Question]LoginServer receives unknown packet.

Page 2 of 2 1 2
06/06/2010 17:44 ImmuneOne#16
Quote:
Originally Posted by s.bat View Post
Common sense tells me to split my packets up separately so that they can be easily read when I post them on the forums, so that others know where one packets ends, and the next one begins.
'Common sense' as you call it, has disappeared a long while ago on this forum.
06/06/2010 19:15 Basser#17
Quote:
Originally Posted by s.bat View Post
Common sense tells me to split my packets up separately so that they can be easily read when I post them on the forums, so that others know where one packets ends, and the next one begins.
Why would I split unknown packets, if all known packets don't need the split function?
That's just a waste, anyone could have drawn the line where the packet should've been split, within 1 minute.
And splitting your packets up seperately before posting them on forums is more common to your sense than thinking "hmm, the dump is longer as the expected length, maybe the packet should've been split"?
06/06/2010 20:33 s.bat#18
lolwut?

Quote:
Originally Posted by Basser View Post
maybe the packet should've been split?
inorite?

You could have posted the single packet instead of both, since apparently the second one had nothing to do with your question (and has confused both CptSky and myself). My job isn't to sift through your data and split it up into appropriate sections. I'm trying to help, and if you're not willing to provide a more easily readable packet dump, then it effects my willingness to help effectively.
06/07/2010 09:32 Basser#19
Quote:
Originally Posted by s.bat View Post
I'm trying to help, and if you're not willing to provide a more easily readable packet dump, then it effects my willingness to help effectively.
The whole packet dump is important, so I should dump the entire thing. It is easily readable too.
01/05/2012 22:27 Spirited#20
Quote:
Originally Posted by CptSky View Post
I know that the client send a packet to confirm the connection to the game server or something like this... After this packet, the authentification server close the connection. I'm not sure, but it's the more probable utility I have found...

I don't know the packet ID, I don't have my old logs, but I know that the packet contains "res.dat" in ASCII.
I know that I'm bumping a SUPER old thread - but I *think* I just figured out what Res.dat's value means. It's in binary.

In Conquer 1.0, the value is 0001, meaning Conquer Online 1.0
In Conquer 2.0, the value is 0010, meaning Conquer Online 2.0

It was probably used for the transition back in the days... and you know TQ. They probably never got rid of the check. That's my theory at least.
01/05/2012 22:37 pro4never#21
Quote:
Originally Posted by Fаng View Post
I know that I'm bumping a SUPER old thread - but I *think* I just figured out what Res.dat's value means. It's in binary.

In Conquer 1.0, the value is 0001, meaning Conquer Online 1.0
In Conquer 2.0, the value is 0010, meaning Conquer Online 2.0

It was probably used for the transition back in the days... and you know TQ. They probably never got rid of the check. That's my theory at least.
You're right but it can also be abused. It sends the contents of the files so you can use it to check the client version. Use it similar to version.dat except then you know server side what patch players are on. Because of that you can send patch notes, lock out people trying to connect on old patches or anything else you like.
01/05/2012 22:56 Spirited#22
Quote:
Originally Posted by pro4never View Post
You're right but it can also be abused. It sends the contents of the files so you can use it to check the client version. Use it similar to version.dat except then you know server side what patch players are on. Because of that you can send patch notes, lock out people trying to connect on old patches or anything else you like.
Yah... but even if you encrypt it, it can be easily abused.
It's as simple as copy and paste.
01/05/2012 23:00 CptSky#23
Quote:
Originally Posted by Fаng View Post
I know that I'm bumping a SUPER old thread - but I *think* I just figured out what Res.dat's value means. It's in binary.

In Conquer 1.0, the value is 0001, meaning Conquer Online 1.0
In Conquer 2.0, the value is 0010, meaning Conquer Online 2.0

It was probably used for the transition back in the days... and you know TQ. They probably never got rid of the check. That's my theory at least.
Yes, the res.dat file is used to version the client. But I don't think TQ never used it. Anyway, you can use it, as pro4never said, to version your own server.

MsgConnect (AccServer), sent by the client to indicate to the AccServer to close the connection.
Code:
MsgHeader Header;
Int32 AccountID;      //The unique ID of the account
Int32 Constant;      //A constant hard-coded in the client
Byte ResFile[0x10];      //A string containing file name of the file that contains the version
MsgConnect (MsgServer), sent by the client at the connection. The first packet.
Code:
MsgHeader Header;
Int32 AccountUID;
Int32 Token;
Int16 Constant;      //A constant hard-coded in the client
Byte Language[0x10];      //The first two letters of the language of the client. Hard-coded in graphic.dll.
Int32 Version;      //The version of the client
So, yes, it's a versioning file. I use it to indicate if the client has to be patched. Also, I use the AccServer constant to validate the Conquer.exe and the MsgServer constant to validate the injection of my protection DLL. But, TQ do nothing with these values.
Page 2 of 2 1 2