Quote:
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) |
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. |
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.
|
Quote:
/hoards canned food and bottled water... armageddon is coming! |
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. 8) |
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:
Code:
struct SessionRequest { |
All times are GMT -4. The time now is 06:09 PM. |
Powered by vBulletin®, Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.