EQ Encryption

[darkangelx]

Ratt:

As you explained the client must have the information that the dev's seek. Is this stored in the same place all the time (compiled into eqgame.exe)? or elsewhere?

[Exo]

I just wanted to make clear that my statments to the speed of the patches for SEQ, almost what 3 years ago, should in now way reflect upon our crurrent team and I didn't intend that. Ratt is totaly correct in that the problems the current team face totaly dwarf what was going on back then and frankly I'm amazed they are making progress on it at all. Ahran and Megaton worked very hard on this back in the day but trust me, I'd rather Ratt be at the wheel. I know I'm happier with the project as it is now.

[lostinspace]

Regarding this:

-------
However, I've said it before, and I'll say it again... the Achilles heal of Verant is the fact that the client HAS to be able to decrypt the data, and we have total, completely, unrestricted access to the client. I see absolutely no way for Verant to change that... and because of that fact, anything they do will be troublesom at best.
-------

I'm not exactly expert in encoding, and also if I'm correct in my next assumption, maybe its not good to post, but if its true, I'm sure VI programmers knows it already

Anyway, you have total access to client CODE, but not to client DATA ( unless you run SEQ on same PC under Win). Therefore, if they generate pair of asymetric keys (with RSAlike algorithm) on client, and use it to excgange some long enough symetric key to be used later with some faster symetric algorithm (like IDEA) .... then you would not have possibility to decrypt it.

Generating long enough asymetric keys is fast enough now on modern PCs. And since SEQ does not have access to EQ memory, even if in code you know where key pairs would be generated, you wouldnt be able to read it ( unless you have WinSEQ on same PC as EQ). Only other solution would be hard key pair cracking, and that is impossible in short time (or ever if long enough key pairs).

Now, as I said, I may miss something here, but not every possible encoding change is 'troublesom at best' ... some may be 'unbreakable' :\

[bonkersbobcat]

Anyway, you have total access to client CODE, but not to client DATA ( unless you run SEQ on same PC under Win). Therefore, if they generate pair of asymetric keys (with RSAlike algorithm) on client, and use it to excgange some long enough symetric key to be used later with some faster symetric algorithm (like IDEA) .... then you would not have possibility to decrypt it.

You don't have to break the big fat hairy key, you only have to break the key that protects the big fat hairy key.

If the client code contains the half of the asymentric key needed to decode the monster key, then the client's key simply needs to be extracted from the client. ("simply" may not be a good word here.)

Without commenting on the difficulty level: If the client can decode the data stream, then the client contains the knowledge of how to do this. The trick is extracting this knowledge. Extracting the knowledge may require dissembly of the EQ client and a lot of time sifting through the memory space of a said running Client.

If the EQ client generates it's own key pair on the fly (sending the public half to VI for use in encryption), it may not be possible to crack the data stream by purely sniffing. If this is the case then a memory monitor will have to be installed on the running EQ machine, that grabs the private part of the key and hands it off to the SEQ machine. This becomes more risky as it is possible for VI to detect such a running memory monitor on the machine that EQ is running on. Steps would have to be taken to make this approach difficult to detect.

[lostinspace]

Originally posted by bonkersbobcat

If the EQ client generates it's own key pair on the fly (sending the public half to VI for use in encryption), it may not be possible to crack the data stream by purely sniffing.

Yes, that is what I was reffering to. Fairly simple to implement from Verant, and even not necessary for client to waste time in generating pair - server can send randomly picked public key from pre-generated database of key pairs, and client can generate only symetric key to send using received public part of asymetric key.

As you said, that can be 'decrypted' by having memory sniffer program on EQ PC, and once it sniffed key, it can send it to SEQ. But that would increase chance of detection (program that 'randomly' generate shiffer program every time?).

Anyway, as soon as even one program needs to be on EQ PC, there would be no need anymore for Linux only version of SEQ. And that is bad for Verant ( lot of EQ users with SEQ) and for SEQ community (too often encryption changes) - so lets hope Verant wont do that for their own interests, if not for ours

[Malketh]

Ok, I'll start with saying I'm slightly tired as I write this. For the record I've been using SEQ for god knows how long now and even though I've quit playing that game, my two roommates still do so I have to keep up to date anyway.

From my understanding of stuff, it doesn't matter what VI does, be it one large master key, asynchronous key pairs, etc. the keys in question will have to be exchanged in such a way that the EQ client can constantly and reliably decrypt it everytime. That means that even say a public key was echanged, even in encrypted form itself, it would be relatively easy to get the key out of the packet stream once the primary decryption algo is discovered (which can be done with enough time depending on key length). once that public key is gained it's even easier (relatively remember) to gain the private key used to decode everything else. The orginal keys, or algo would have to be client side and could be gotten with enough time, so no matter what VI does, they can't stop this community from cracking their codes.

Remember the only truly reliable encryption sceme is one that NOBODY else can read.

Now with that said I think I kinda lost my train of thought (maybe). And if I'm wrong in any of this, PLEASE tell me so I can learn more, after all that's what most of us are here for anyway.

For the record I've been spending a lot of time playing DAoC and using Excalibur and I don't think I've seen them redo the encryption scheme in months. I guess they just realized they can't stop it's use.

[lostinspace]

Malketh,

With asymetric key pairs, everyone can know public part (thats why it is called public). For example, EQ client generate one key pair public/private, and send public part to server. Server use that key to encrypt data that it send to this client. Even when you know what public key is, you can not use it to decrypt what server is sending. Noone else can , except one who has private part - and that part was never sent over network. Also that part is not fixed in code (was generated randomly in runtime), so you can not figure it out by disassembling code.

So only way to break that would be to read client memory in addition to just reading network packets, which is big change in SEQ principle of passive sniffing. Or to try and use brute force computing to find private key based on public key, which for any decent size keys can take years.

BTW, this is just theoretical discussion, not related to problem of old or new EQ encryption, of which I have not faintest idea how is implemented.

[MisterSpock]

The thing we must remember about this topic (encryption) is that there are some substantive limitations on what SOE can deploy as a workable cipher. This is not from a lack of cryptographic or programatic skills, but due, instead, to certain design limitations.

First off, and quite simply, the client must be able to decrypt the data stream in a manner fast enough to allow the game to function. This must function even on computers that barely meet the minimal specifications.

Secondly, it must (or should be) included and related to the main stream. That is to say, a third-party key agent is not practical for this example.

Finally, they must, in essence, give us the tool to decrypt the data. Unlike traditional decryption problems, we have the tool and know what the message is supposed to say. This provides a tremendous advantage that is typically not present.

The use of an Asymmetric encryption methodology is inappropriate for this type of stream data. The speed of transformation (either from Pt to Ct, or vice versa) (plaintext to ciphertext, etc) is too slow.

However, an asymmetric method can be used to pass a 'session key' that can be used (or a mathematical derivative can be used) for subsequent symmetric encrytions/decryptions. This is similar to how SSL works, for example. Again, though, the fact remains that we can get, one way or the other, three of the 4 keys in such a system. Getting the client's private key probably would change seq's passive nature - So this may not be the nut that needs to be cracked.

The key (no pun intended) is to discover how to break the session key (e.g. how to fully decrypt the data without truly posessing the session key). This involves understanding how the client's decryption routines operate. Additionally, we must consider any mathematical weaknesses the encryption methodology contains and how these can be exploited.

All routines and methodologies have some form of vulnerability. This one is no different.

[RSB]

MisterSpock hits it on the nail. Looking at this completely passively cracking the session key is much easier than cracking the finding the private key that is used by the client to decrypt the session key packet.

Something some people forget or don't realises is in an encryption / decryption routine any key can be used to decrypt the encrypted data.....its just that the data won't be in its orginial form...ie it will look like garbage. The reason the decryption routine in SEQ works is because it knows information in the unencrypted structures. Each key it tries it looks for that data in the location it expects it to be. When it finds a match it goes "BINGO, I'v got it!". There in lies the real problem of breaking the packet that encrypts the session key. How would you know you decrypted it correctly? Its not like a real key where you stick it in the lock and it either turns or not.

so this is what would have to happen if you wanted to crack the EQ packet stream by first cracking the packet that sends the session key.
Here is the encrypted version of that number
C46C1BDC3C5211D09200848C1D2EF1AB
what is the original key?
Hmmm since it could be any number from 1 to 2^16 then you start off with 1
1) decrypt the session key with 1 and get some other 16 byte number.
now there is no way of telling if the key you have is correct except for trying it out, so.
2) decrypt a new spawn (or other known packet with this key)
does it look like it should? No?
3) decrypt the session key with 2 and get some other 16 byte number.
4) goto step 2


Now all we've done here is do what the decryption routine does now (before it uses a newspawn packet to narrow its search of the session key down) but added the even bigger task of trying to break an even larger key then the session key.

[Resiliant]

One observation.

The simple fact of the matter is, we have the client code (at least the machine readable form of the client code) to look at. That is our great advantage, and really what Ratt is referring to as SoE's 'Achille's heal'. If we were simply monitoring the net traffic, and had to decrypt the data WITHOUT having access to the altorithm that decodes it, the task would be simply impossible.

As it is, what the developers now have to do is to reverse-engineer the latest VI initialization code that a) determines what the key is that is used to decript the packet stream and b) what altorithm is used in that decryption. Theoretically, no communication need occur between SEQ and EQ. What needs to be done is to a) start the monitoring process early enough in the EQ session as to capture the key negotiation sequence, and b) mirror the key assignment, and key decryption sequences on the SEQ machine.

This is one of those problems that is easy to describe, and REALLY hard to do. What the developers now have to do is to actually UNDERSTAND what the programmers at VI have implemented as regards initial key assignment, and packet encryption. This could take a couple of days, or several weeks, depending on how arcane, bizzare, and poorly written VI's code is. There is not much the rest of us can do at the moment (although I for one would be more than happy to decipher any machine-language stream that was provided to me) other than wait, support them all, and be patient. All of which are good character traits to have in any case.

Neither the procedure that obtains the real-time public key used to decrypt traffic, nor the procedure that actually decrypts that traffic can be complex. EQ sends HUGE amounts of data to the client machine, which is *extremly* busy performing graphics-intensive CPU operations. It doesn't have the time to do massive floating point or scalar operations on the packet stream. I would expect that the decryption algorithm would be no more than a few hundred machine instructions at most. Decode that, and we have them by the b****

P.S.

Oh.. and RSB... your brute force technique for finding the session key makes the presumption that the 'original key' as you call it is only 16 bits long. A very optimistic assumption. You don't have to add very many bits to this to render this technique completely useless. It may take a current CPU only milliseconds to do a loop 64k times. If, however, the 'original key' were 32 bits instead of 16, then it would have to do the loop 4 Billion times. If it were extended to 64 bits it would be impossible to break the code using this technique. I believe a more intelligent approach is now required.

[baelang]

Just wanted to point something out, and see what you all thought on the subject.

i haven't been much into crypto for a while, but isn't the government restrictions on the export of munitions in our favor this time?

Sony sells their game in the US and overseas. dosen't this mean that their encryption systems are limited to relatively weak systems?

I thought that 56 DES was about the max they were permitted to use, or is that law gone now?

[Malketh]

Oh... I see now just what you mean by assymetric pairs. My bad. I'll be honest with you in case I didn't see it before (I've got to stop either being ready to go to sleep or waking up from sleep when I post), but I'm by no means an expert or even a novice when it comes to encryption schemes.. But I'll say one thing, this thread is nice for information and such.

[Blaze]

Would an attack on the random number generator work? I wonder what a histogram of the session keys generated by the client would look like. There may be huge chunks of the keyspace that hardly ever get choosen.

see http://razor.bindview.com/publish/papers/tcpseq.html
for a paper about TCP/IP initial sequence numbers.

[someshaman]

Somebody I just talked to on IRC on an Unix channel, showed me a screen shot where he was using M$ Debugger and showed which DLLs etc. ShowEQ was loading. One of them was crypt32.dll.

If they use that dll (a system one), it should be possible to trace the calls.

[high_jeeves]

The encryption is not done through crypt32.dll, it is probably loaded when the networking libraries are loaded.

--Jeeves