16 bit checksums

[fathernitwit]

Originally Posted by RangerDown

And did you try to set Key2 to 0 all the time, does that make the user/pass send in the clear?

Perhaps something else is wrong in my code, but if i set key2 to 0, it is still not sent in the clear... EQ is accepting the packets, so I think the crc is correct, it must be using different encryption or something...

It might have something to do with key1... because I am not doing anything with key1 except echoing it back in the reply, after that it seems worthless... but it might be a weak 'CRC' type of check to make sure the reply comes back and at least partially makes sense (key1 is the same)

[RangerDown]

Drat :( In that case, they must've changed some stuff up with the user/pass encryption after June 22.

When I'm back at home this evening I'll post the contents of a collected session between my Emu-compatible client and the Emu login server so you at least have something to compare the existing protocol to.

[kathgar]

When the old new login came out, passwords and usernames were sent plaintext, and that key had nothing to do with it. I think about a month in to the new login they decided that encryption would be a good idea.

[RangerDown]

I think about a month in to the new login they decided that encryption would be a good idea.

Wait a minute... SOE had a good idea??!!!

/hoards canned food and bottled water... armageddon is coming!

[Doodman]

You can send the 16 bit crc as 00 00 and the client will accept it just fine.

I do it in the chat channels and in my partially implemented login server.

As for the crypto key, it is not sent from server->client. It is static and in eqmain.dll. Everytime you log in on live you send the same chunk of data for the same user/pass. Supposedly it is 3des with some transpositions. Just need the key and what transpositions they do.

[Doodman]

Plus, beyond the leading op_code (OP_SessionRequest is 0x01 and Op_SessionResponse is 0x02) here is the structure of the SessionRequest and SessionResponse packets:

struct SessionRequest {
        unsigned long UnknownA;
        unsigned long Session;
        unsigned short UnknownB;
        unsigned short MaxLength;
};              
                
struct SessionResponse {
        unsigned long Session;
        unsigned long Key;
        unsigned short UnknownA;
        unsigned char UnknownB;
        unsigned char UnknownC;
        unsigned short MaxLength;
        unsigned long UnknownD;
};

In the login server Key is ignored and unused. In the chatchannels it is used to "scramble" the packets being sent.