What exactly happened

[Resiliant]

Given the 'Gloom and Doom' scenarios that were posited just after the PoP release, and the absolutely *incredible* speed with which our dev's cracked that nut, im simply NOT willing to throw in the towl (metaphorically speaking) only hours after attempt #2 by Verant to breat SEQ.

If all that has been done is to simply compress the packets (something, btw, that I've always wondered why they didn't do -- it has the potential to increace the FPS considerably) -- then isn't it true that all we need to do is to determine the compression scheme, then apply the old decoding system?

The thing about compression is that it by nature is NOT encryption. It is generally extremely difficult to compress encrypted informatoin due to loosing the inherent patterns in the data that provide the leverage FOR the compression. Therefore, I assume that the compression happens BEFORE encryption. All we need to do is to determine the compression scheme, and decompress.

Finally, I think the absolute BEST response to the hundreds of THOUSANDS of dollars SoE has already thrown at this problem is to simply solve it in our usual way: Quickly , Effiently, and Effectively. Send the message: "Go ahead and waste your money. It won't deter us, and wont even put a dent in our continuing use of this wonderful tool"

If this is not the case, Ratt could you please tell us exactly why SOE's latest attempt is so much more difficult to break than the last?

[LordCrush]

I had the same thoughts...
But the problem is another! The new libEQ.a by Quagmire and fee relyed on constant portions of a spawn packet to reduce the key-space to be used for brute-force. After compression and then encrypting those fix potions dont longer exist ... so you have to deal with the whole 64 bit key :(

[Resiliant]

Figure out the compression. Decompress the packets, apply previous algorithm.

It has been only hours. I do not have the knowledge to analyze this further. However, I know this... they that be with us are more then they that be with them :)

[quackrabbit]

You seem to be missing the point that you have to decrypt before you can decompress...

It's like this. Take a document and zip it. Then encrypt it w/ pgp. You just can't unzip the output... You have to decrypt it before you can unzip it.

[fox]

An analogy. A *really* bad one.

Consider the packets like an aluminum soda can. An encrypted packet is this soda can with the label in Japanese. You can see generally what the type of soda is by the colorings on the label (i.e. pepsi's cans don't look like coke cans) but to get something like the ingredients list, you need to translate it (decrypt).

If you crush (compress) the can, it makes it really hard to read the sides of it to find out what's inside.

Again, it's a bad analogy =P The compression is done before the packet is encrypted. And since different information compressess down to different sizes, you can't merely map the first X bytes to a given structure as it won't be the same size every time you look, even if the packet is the same general type. Different data will compress down to different sizes.

[Resiliant]

OK I believe i understand.

In the past we were using the portions of the packet that were not encrypted to help in deciphering the portions of the packet that were. We were able, for example, to recognize a 'spawn' packet as such, and use its structure to help in decyphering the key. Now that the packets are basically *entirely* encrypted, we no longer have that luxury. In point of fact, this was an extremly stupid way of encrypting the packets. Im rather staggered actually that they would be that simple.

Given this, I submit that the proper procedure is simply to replicate the public key generation algorithm in the current eqclinent.exe file inside SEQ, and then just watch the packet stream for the key when it is sent from the server. (perhaps easier said than done). As Ratt has said innumerable times, their achillies heal is that they GIVE us the code to decrypt. Lets simply port that code to Linux.

[high_jeeves]

You really need to go do some reading on encryption and PKI engineering. It isnt just as simple as "listen for the public key, and we are done".. it just doesnt work that way. If it did, there wouldnt be any secure internet communications. We DO have the decryption algorithms ported to linux (what exactly do you think libEQ.a contains?). What we DONT have, is the key. We cant just "sniff" for the key.. that isnt how it works. We have to exploit a weakness in the packet.

When the packet isnt compressed before it is encrypted, we can make assumptions about the contents of the packet to help us significantly reduce the search space. We can also evaluate a particular key possibility very quickly, because we dont have to go through a (relatively slow) decompression step. Now, with it compressed, we dont know anything about what the packet may look like, so we cant reduce the keyspace. It also takes us longer per key to test for validity. As per Ratts discussion in another thread, we can evaluate the entire 64bit key in real time, as long as you dont mind waiting a few billion years between times you zone... for me, the billion years requirement seems a bit steep.

--Jeeves

[JustACoder]

"If it doesn't kill you it makes you stronger"

we are only closing the gaps till it is all over. we are helping them build a better security for tomorrow.

[sakshale]

One comment from something I read a really long time ago... Which means that it is probably no longer true. :)

The statement was that you normally want to encrypt prior to compression.

Most compression schemes have standard tables that they place at the front of the file for use in decompression. If you know the compression algorithm that is being used, you will then know some data to use for decryption...

The other statement about encrypted data being relatively uncompressable may be true, but does not fit with my understanding of current compression schemes.

Sakshale

[Resiliant]

OK, Jeeves, thanks so much for posting. Please help my ignorance if you feel so inclined.

The whole basis of internet security, if I understand it correctly, its founding principle, is that you do NOT know the priviate key, and the encryption algorithm encased in the client. All you are
able to do is monitor the public traffic, and hence it is secure.

Here's my point. The EQ client is able to decode the packets. We have that code. All we need to do is understand how it works, and replicate it's function. Its the diametrically opposed POV to brute force.. its Reverse Engineering.

Res

[quackrabbit]

Originally posted by sakshale
One comment from something I read a really long time ago... Which means that it is probably no longer true. :)

The statement was that you normally want to encrypt prior to compression.


The point of compression is removing repeatative data i.e. you have a packed of 7000 spaces you want to compress that down. If you encrypt the 7000 spaces you would not get a string of 7000 identical bytes (i.e. it's not encrypted byte by byte) therefore the resulting packet would not contain a lot of repeatative data - and compressing it would make it even larger. (ever zip a zip file? it doesn't get smaller (usually)).

Quack

[high_jeeves]

Here's my point. The EQ client is able to decode the packets. We have that code. All we need to do is understand how it works, and replicate it's function. Its the diametrically opposed POV to brute force.. its Reverse Engineering.


The problem is, this JUST ISNT TRUE! Yes, we have the code. Yes, we understand exactly how it works. Yes, we have the code duplicated in libEQ. No, that doesnt matter. I have the source for SSL sitting on my box (it is opensource). I know exactly what the client is doing. I know exactly what the server is doing (more than we know in this case). Can I write a passive sniffer that cracks the SSL datastream in realtime? No! Otherwise it would be worthless. That just isnt the way a decent PKI system works.

--Jeeves

[Resiliant]

OK... Thank you Jeeves for your direction.

Now... someone OTHER than Jeeves please explain to me how, if we know the private key in the client, why we cant decode the public key when it is sent from the server?

Knowing this, we're home free.

[sgi]

The same reason you can't calculate someone's PGP/GPG private key despite having having their public key. Verant encrypts the datastream with their private key, the client decrypts it with it's public key. The datastream is the "PGP/GPG encrpyted email" if you will, and the person reading that message from the outside (SEQ) can't read the encrypted datastream.

[Resiliant]

sgi...

OK.. let's take this step by step

1) The Client has a public key
2) The server has a private key
3) The server encrypts its private key using the public key and sends it to the client
4) The client decrypts the transmitted public key using its private key
5) the transmission proceedes with the server generated private key.

Weakness:

If we know the client's public key, and the algo used to decrypt the private key sent from the server we can, in like manner to exactly the same decryption.

Or am i missing something fundamental here?

[Aardvark]

so how bout.. I know this goes against "the seq vision", how bout someone codes a windows program that spews the newly decrypted data onto the network for seq to pickup? If the windows machine is able to do it then why can't it spit it out or even directly send it to the seq box via simple program? (probably complitcated but it seems simple in my head, although I'm far from a programmer)

[speedphreak]

so how about...come on seriously guys - go do a search on PKI & symmetric enycrption - maybe even Diffie-Hellman before posting silly ideas and mis-information here.


Its the diametrically opposed POV to brute force.. its Reverse Engineering.

The other statement about encrypted data being relatively uncompressable may be true, but does not fit with my understanding of current compression schemes.

Suggestions I'm sure are welcome, but not the kind of nonsense like these that people are posting. I know you think you're being helpful, but you're not.

Better to be silent and know you're an idiot than to open your mouth and prove it

[sgi]

Yes, the server key is never sent to the client. That's the problem that requires reading the client key from from the memory of the running client. The server encrypts the data with it's private key, the key that only the server knows. The client (eqgame) decrypts the stream (the stream being the data on spawns, spells, your loc, etc, etc, that "play" of the game) using it's key. Note that all this assumes that the encryption used on the game data is the standard public key based cryptography that we all know and love.

What I believe you're suggesting is that because the client key is changing it must be dynamically generated, this would imply a dynamically changing server key as well. How does the client determine which key to use to decrypt the game data? You seem to imply that the server must share it's key with the client somehow so that the client can determine which key to use and that SEQ should be able to intercept this key, also determining which client key to use without having to refer to the client itself. Honestly, I have no idea how this negotiation takes place. Jeeves mentions SSL, other mechanisms like SecureID use a salt based on a sequence of pseudo-random numbers negating the need for any transfer of keys, etc, etc...

Unfortunately, ShowEQ has neither the server nor the client key to rely on. Formerly, ShowEQ was able to brute force the client key based on patterns in the stream of game data. It could then use this key as if it were a eqgame client and display the game data in the way you're familiar with. It can no longer brute force this key. This is what necessitates obtaining the key from the running client itself so that ShowEQ can again have a copy of the client's key to display the data you're wanting to look at.

It's like this:

EverQuest Server | Server Key --- [ ShowEQ ] ---> Client Key | EverQuest Client

This is the situation as it existed prior to the 10/31 patch (and indeed exists now, only a bit different as discussed below). The ShowEQ software could, based on patterns in the game data coming from the server, guess the "Client Key" and pretend to be an EverQuest Client with access to the game data.

The senario is identical to using PGP or GPG encrypted email.

Sender | Private Key --- [ snooper ] ---> Public Key | Recipient

The difference here is that "snooper" (which is analogous to ShowEQ above) is unable to guess the "Private Key" (or "Client Key") because the encryption used by the "Sender" ("EverQuest Server") is too strong in the "Private Key" ("Server Key").

What Ratt is saying, and what the difficulty is, is this: ShowEQ can no longer guess the Client Key based on the game data so it must obtain a real copy of the Client Key from the game itself. So that the flow of data looks like this:

Server | Server Key --- [ SEQ ] <--- > Client Key | EverQuest

Note the addition of an <--- arrow. This denotes the transfer of the Client Key back to the SEQ software via some as yet undetermined means. The easiest way to do this is to have the SEQ soft running on the EverQuest client machine. It then has direct access to the game's memory space and can read the key directly. This is the most untennable senario as it opens up the use of SEQ to everyone with a Windows machine thus tearing down the "ivory tower" in which Linux savvy EverQuest players reside. The next easiest solution is to have some process that runs on the EverQuest client that passes this data back to the SEQ software which would continue to run on a Linux host. This still leaves the possibility of detection by the Server as the there is fear that the Server will monitor the client for any such processes. The thrid solution, and the one that Ratt is "impying" is for SOE to decrease the difficulty of guessing the client's key so that there is no need for a <--- flow of data in the picture.

Now, all that having been said, I do not know the mechanism that EverQuest uses to encrypt the game data. It could be something other than public key based cryptography. I'll leave it to one of the developers to address that. Suffice it to say that if the mechanism used is one based on mathematically related public and private keys, and if those keys are 64 bit keys, then the old method of synchronizing the eqgame and SEQ client keys via brute force is no longer possible.

If any of this is in error, please feel free to post a correction.

[Blaze]

From what I have managed to figgure out, here is how things work.

1) Client generates a session key
2) Client encrypts that session key with the server's public key.
3) Client sends the session key to the server
4) Server uses it's private key to decrypt the session key.
5) Client and server now know a session key to use to encrypt further data transfers.

The encrpytion process goes something like this.

take the first bit of the data, and xor it with the first bit of the key. Take the 2nd bit of data, and xor it with the 2nd bit of the key, etc. Take all that data and combine it together and that's your encrypted data. If we know the original data looks something like
0011????0110
and the encrypted data looks like
011011001110
we xor the data we know with the encrypted data, and we know the key looks something like
0101????1000
To figgure out what the full key is, you just need to brute force the 4 ?'s to figgure out what they are.

If you compress the original data, all the known values get tossed to hell because depending on what the unknown values are, it will change what the compressed packet looks like. So instead of brute forcing a few combinations(possible), you need to brute force the entire key(not possible)

The above is my best guess as to how things work, and since I don't understand things fully, it may be wrong, if it is let me know so I can edit my post so I wont confuse people.

[Resiliant]

THANK YOU Blaze! (BTW.. im as much learning here as I am suggesting potential ways of solving the problem.... education preceeds soloution)

NOW we're getting somewhere! SO it's the CLIENT that initiates the encryption sequence. Ok... light begins to shine.. here is the 64,000 dollar question:

At step 2) in your sequence, Is it possible to DECRYPT the session key knowing the server's PUBLIC key? I presume that it is asymmetric and the answer is NO.

However, knowing a) the server's public key and b) the encryption algorithm would it be possible to invert the algorithm and simply extract the original key?

[binky]

Omg i have never seen such misunderstanding of cryptography.

Everyone, please read up on this before posting all these wild theories and suggestions on how to break EQs encryption.

I see:


The server encrypts the data with it's private key
No, private keys are used for decrypting and signing. Public keys are used for encrypting and verifying signatures.


The statement was that you normally want to encrypt prior to compression.
Completely insane. Compressing encrypted data, depending on the quality of the encryption algorithm, will get you as low as like 0.001% compression or something ridiculously small, and if the compression algorithm is lame then you'll actually end up with a larger file than you started with. *Everyone* compresses before they encrypt. It saves space, and it *vastly* increases the security of the encrypted data because crackers can't make assumptions about what will be inside the packet.


Now... someone OTHER than Jeeves please explain to me how, if we know the private key in the client, why we cant decode the public key when it is sent from the server?
and

If we know the client's public key, and the algo used to decrypt the private key sent from the server we can, in like manner to exactly the same decryption.
Err.. This is just totally messed up. You don't need to decode public keys, they're free and *mathemetically impossible* (nothing to do with "reverse engineering") to crack. Hell, i'll give you all my public PGP keys right now and wish you good luck that maybe in a couple of million years you might be able to do something with them. The private key is *NOT* stored in the client. The client generates a session key, encrypts it using the server's public key, and the server then decrypts that with the server's private key. It's totally secure and is *NOT* crackable.


Or am i missing something fundamental here?
Yes that sums it up nicely.

A lot of people here just don't understand the theory behind session, private, and public keys. You should read up on it before posting anything embarrassing.

But could it all be irrelevant anyway? I haven't seen anything official yet on just exactly what encryption is being used. Are they even using keypairs? Are they using standard algorithms? With the speed at which it was cracked again recently, i think that they're using the same old thing as before, just a larger key.

With compression though, it opens up a whole big can of worms. Pre-encryption compression greatly increases the effectiveness of encryption. It's now got nothing to do with predicting what's in the data. You now have to redo the cracking algorithm to predict what will be the output of the *compression algorithm*. If it's decent, then it's going to be mighty hard and i'd opt for a Windows session key extractor.

Cheers.

[binky]

Originally posted by Resiliant
At step 2) in your sequence, Is it possible to DECRYPT the session key knowing the server's PUBLIC key? I presume that it is asymmetric and the answer is NO.

However, knowing a) the server's public key and b) the encryption algorithm would it be possible to invert the algorithm and simply extract the original key?

No, as everyone would know, public keys are used for encrypting and verifying signatures.

Invert the algorithm? This isn't XOR encryption, this is highly sophisticated mathematics whose *fundamental* strength is that the algorithm *cannot* be reversed, nor can you derive the private key from the public key. Totally, *totally* impossible unless you have a ridiculously enormous amount of time and computing power.

http://www.rsasecurity.com/ has some good docs somewhere about crypytography, you should read it.

Also, you'd probably get shot if you said "simply" near a cryptographer.

Cheers.

PS: Edited to fix some missed out words, inserted in italics.

[fripouille]

How SSL works :

http://developer.netscape.com/tech/security/ssl/howitworks.html

Read this, you ll see the deal about private / public key and why you can t sniff it :)
It s a bit long, but it s the best explanation there is !

[Aus]

Wouldn't it be possible to do a man in the middle attack. As SEQ already lives on the gateway, this would 'just' be a little change the way SEQ operates. There is no need for arp spoofing this way.
You can find some info here:
http://www.phrack.org/phrack/57/p57-0x0d
This goes more into detail of fooling the user to accept a certain certificate. I do not know if everquest does such checks on the client side. With a bad implementation, as we've seen with internet explorer, such checks can be circumvented.
More info about this issue here: http://www.thoughtcrime.org/ie-ssl-chain.txt
And a proof of concept program here:
http://www.thoughtcrime.org/ie.html

just my 2 cents...

[Aus]

In my previous post I forgot the possibility that everquest might have the public key on the client side already. (as any sane design would have imho). This would require a patch to eq on the client side to change this public key to your own key.

The design would be as following then:
EQSERVER [EQpriv] <-> [EQpub] SEQ [OWNpriv] <-> [OWNpub] EQclient
(the parts between the []'s are certificates).

This would require a lot of RE on the client side and also patching of the client. This probably goes way beyond the goal of showeq.

Any suggestions? :confused:

[serberus]

You say the way ShowEQ decrypted the packet was to use existing static data as a reference, how is SEQ still able to tell my position and the position of 'unknown' spawns, along with being able to display some information under the 'Info' tab (e.g. it said someone was holding a lamentation, I checked, they were).

The only reason I can think of is this information isn't encrypted and SOE regard it as useless and don't bother to protect it in any way.

I still fail to grasp the concept of how something can be kept secure using the public/private key method, going to read that Netscape SSL guide now, hopefully i'll learn it this time around.

Serberus

[monster69]

You are correct Serberus,

those packets are not encrypted. SOE does not encrypt all packets. That is GPS works.

Monster

[serberus]

so if they were to start compressing the unencryped packets in the same way as they compress the encrypted packets, would that make it possible to break the encryption?

I understand that you need to know what data is in the packet so when you crack it you have something to reference it to verify you've cracked it correctly.

Does being able to decompress the data correctly help? I'm presuming its the same as it was prior to the patch now with an extra decompression step.

<compressed + encrypted data with unchanged static information for reference>

it would have been:

decrypt packet and test against 'master packet' (so to speak), repeat until you have a key that decrypts the data properly.

should it not now be:

decrypt packet, decompress encrypted data, test against 'master packet'

You're working in the dark with the encryption and compression because you have no clue if you decompressed the data correctly and you're essentially just hoping that you've done it correctly and your decompressed data will eventually turn up decrypted when you get the right key.

Prior to the compression, weren't you just doing the same thing without decompressing?

Is ShowEQ missing the 'master packet/static data' to compare decryption attempts against to check if its right?

Is that what the opcode changes were about? They were just moving the position of the static data so it wasn't ever turning up correct decryption?

This post is a bit of a mess, i've written it in the same way as my though process and don't want to go thought and consolidate it.

In essence, ShowEQ no longer has a point of reference to compare data against?

Thanks

Serberus

edit: yes, having re-read this message, it is a mess, i'm not very clear with my terminology.

the 'master packet' being the static data

edit2: I should really stop sniffing clue when I read the SEQ site =P

[fester]

To clear up some misunderstandings with some people on this
thread.

We see the key exchange in E541 (or were pre oct 31).
A packet from the server with a 640 bit (or at least 512 bit) public key inside. We see the reply from the client just afterwards.

Knowing the Public key and knowing the plaintext that is encrypted with the public key would not help me determine the private key.

The only way we will determine a solution is to examine the machine code that decrypts the key with a known chunk of plaintext and a known chunk of cipertext along with a known key. This exercise will tell us how the encryption is done (and if it is a standard encryption method). This is educational, but unless it is a home grown method that has a flaw in the algorithm that can be exploited we will still be out in the cold.

I can know cipertext and plaintext of most standard encryption algorithms and still not be able to determine the key.

[Hmmmm]

Well I am not a dev, or a programmer and cant even compile linux without a walkthrough so I know you guys are head and shoulders above me.

But....Since you cant crack the key in real time... Why not crack it afterwards and send it to the linux box?

Seems you might be a few secs late for everything but heck most machines that run SEQ are old and lag some anyway.

I am sure there are reasons that would make this alot less usefull than real time but would it work?

If you could get it to work how much would have to be non passive if any?

If it could work and part was not passive could you camoflage it or hide it?

Perhaps I am just too much of a novice but seems reasanable that if you have decoded in the machine already you should still be able to see everything in your imediate range at the least.

[arantius]

OK... Thank you Jeeves for your direction.

Now... someone OTHER than Jeeves please explain to me how, if we know the private key in the client, why we cant decode the public key when it is sent from the server?

Knowing this, we're home free.


When PoP came out and the encryption changed, SEQ was broken. I found out that they were probably using a public key encryption. I also found out that though many people think "we have the client = we can decode it too" it simply isn't true.
My next step was to go to the library, and take out a few books on encryption. I have read those books, and I understand perfectly WHY having the public key is useless to us.

If not the fact that it's common sense. The public key is just that, viewable publicly, by anyone. Making an encryption scheme that included all the necessary information to decrypt it would be like leaving the sticker on the back of your padlock. Not very secure.

[throx]

But....Since you cant crack the key in real time... Why not crack it afterwards and send it to the linux box?

Because most people aren't willing to wait the few thousand years it would take to brute force a 64 bit key on a single machine.

[Hmmmm]

The system unencrypts in memory right?

So if there was a part of seq that looked at the memory wouldn't that let you "see" what was around you?

It would already be unencrypted. May be a tiny lag from comp one to comp 2. But I would think that I should be able to see everything that way.

[throx]

Yes, that would work but would also require code that the everquest client itself could detect, send to Sony and then have them ban you.

[oakley]

Resiliant:

To me, your comments seem like you were the vice president, just made president because he died. It seems that you have no understanding of a war that is going on, but second guessing everything untill you like what your telling yourself. So you set everyone up to go along with your way of thinking, minding, that you know absolutly nothing. But you also assume now that you know everything. As someone said in a previous post, read up on it before you spew out loads of trash and hopfullness out. If you think you can fix it, go right ahead. Although, all the people that do know what they are talking about, won't help you because they have a REAL understanding of what is going on. So, with that. I wish you good luck.

[libpcap]

Hints only apply to the exclusive.

The overhead for SSL is four fold:

First, there is the additional overhead of the encryption.
The "cost" of encryption/decryption is about 10%-20%. For the initial RSA private key operation used during session setup, it takes about ~300,000 clock cycles for a 1024 bit key. Interrupts for new packets, io completions, etc, will extend that even farther.

Second, the clients usually generate multiple threads reading from the server, especially during session setup, which is pretty much compute bound. Since clients usually have several threads going at once to a given server, a single client can have a measurable impact on a server, by causing three or four session setups to go on at once.

(Note that a 1GHz W2K SP2 system can do ~100 connections per second in the software).

Third, an SSL encapsulated message can only have a 16K window size, which means that the server can't submit large streams of data back to the client.

Finally, all this overhead takes place in user mode, so the server can't use TransmitFile and our other, fast APIs to send the data along.

Stop the madness and get a grip. You all have been challenged, what are you goaled for now? W32SEQ? Close the help boards and stop allowing posts of pre-compiled crap on here. SEQ is being used against you by SOE as a means to an end, what end is that? Do you all play chess? Pawns!!!

[Rufus]

Originally posted by fester
We see the key exchange in E541 (or were pre oct 31).
A packet from the server with a 640 bit (or at least 512 bit) public key inside. We see the reply from the client just afterwards.


Just a thought (feel free to flame away/ignore if I'm totally off-base here)...

I was under the impression that it was illegal to export software using > 64-bit keys outside of the US (with the possible exception of Canada)...Given that there are a large number of international players, and that these players have definitely received patch updates, would this new encryption not be in direct conflict with US Export regulations?

...Rufus

[Aardvark]

Originally posted by Rufus


Just a thought (feel free to flame away/ignore if I'm totally off-base here)...

I was under the impression that it was illegal to export software using > 64-bit keys outside of the US (with the possible exception of Canada)...Given that there are a large number of international players, and that these players have definitely received patch updates, would this new encryption not be in direct conflict with US Export regulations?

...Rufus


Now thats pretty funny

[KennySP]

Given that there are a large number of international players, and that these players have definitely received patch updates, would this new encryption not be in direct conflict with US Export regulations?

Not exactly. Recently US export restrictions have been decreased quite a bit. It is now legal to export encryption to most countries except those such as IRAQ/IRAN/North Korea/Pakistan, etc.

So exporting this stuff to Most of europe, Austrailia, etc isn't really a problem. But they have to be sure no one in the taboo countries are receiving it.

Have fun!

KennySP