NICE! Thanks for myCRC, thats the ticket.
Finally figured it out...
the first two packets in the login process are:
Code:
//client sends to server
struct {
unsigned short type;
unsigned long num1;
unsigned long key1;
unsigned long num2;
};
//server's reply
struct {
unsigned short type;
unsigned long key1;
unsigned long key2;
unsigned long num1;
unsigned short num2;
unsigned long num3;
};
I dont know if you can put anything in key2, my key2 is stolen from a real packet stream (havent tried anything else)... the client's key1 seems to actually be a function of how many times you have tried to log in, and seems to be always the same on the first login. I know that the key2 used by real servers changes each time even if key1 is the same.
once you send key2 back to the client, that is your keyargument, for all packets, in either direction... I got tied up because I forgot to ntohl the key, damnit.
Code:
//the len-2 assumes that the checksum bytes are allready appended to the buffer, be it send or receive
unsigned long crc;
crc = myCRC((unsigned char *) buffer, len-2, ntohl(reply.key2));
unsigned short cc = htons(crc & 0xFFFF);
// now set the trailing two bytes...
There is one problem, hell if I know what it is... where a specific 2-byte packets is not checksuming properly (00 06)... must be an initilization thing or something... this 2 byte dude also seems to break the rules as far as the 'same checksum in either direction'... they both reply with a strange checksum, but i dont care because #1, i can hard-code that checksum, and #2, they seems to be just 'ping' type packets, no information.
so now with some DNS rewrites, I can mimic the login server and connect to my world (nothing intelligent yet)... but it is now broken when i log into a zone? I THINK this is a known thing.. that the newest client is broken/incompatible with eqemu... is this a true statement? Is there any technical discussion about this problem anywhere?
Hybrid Mode
