I recently started dinking around with EQEMu, so I'm not sure. However, this has been my guess:
Late last year, SOE implemented a packet security scheme for communicating between client and server. You can read plenty about it on the ShowEQ forums, but here's a generic overview, as I understand it:
Packets are now encrypted using a key that can't be reasonably brute forced. This key is generated on SOE servers using whatever algorithm they chose. Their algorithm is obviously not publicized, may even change every few patches. The client needs the key to decrypt the packets, but the key is transmitted using some compression mechanism that i believe has not yet been determined - and again, may even change from patch to patch.
The current client receives a packet and tries to decrypt it - but of course, the packet would have to be properly encrypted by the server in the first place. Furthmore, the client is now expecting this key to be properly calculated, compressed, and transmitted. EQEMu plays the role of the server here, so EQEMu would have to do all these tasks for the current client to function correctly.
Now, everyone here knows that in order to run EQEMu, you have to run a client that was around late last year - possibly the client that was around the time SOE implemented this security thing. Coincidence? I am guessing not.
My guess is that in order to keep up to date with EQLive, EQEMu developers would have a hard time:
(1) Getting the algorithm right to run with the current client
(2) Doing this each time SOE decides to change something.
Personally, I don't even know how the SEQ/EQEMu developers figured things out in the first place - prior to implentation of packet encrypting.
|