Passive Decryption

[tamasine]

As i understand it:
the eqpackets containing troublesome information arrive at the computer unreadable. This is because the payload is XORd with a 64bit keystring.
Attempts to brute force the key used to work by reducing the keyspace through known plaintext (parts of the player structure).
This no longer works due to the pre-encryption compression of the player structure.

Surely once a key has been manually entered into showeq, we know this player structure - exactly at the point of zoning. So when the next zone comes along, why can't this be compressed and used as known plaintext for the new zone key?

It would obviously (in this form) only work per character, and wouldn't tolerate switching characters.. and would also work only if the player structure doesn't change in the first few (how many) bytes between zones/sessions.

if the presumtions are wrong, please correct me .. and comments taken with interest.
Tam

[Mr. Suspicious]

As stated before the player structure itself isn't encrypted (it's only compressed). That's the reason why ShowEQ works in GPS mode when you're not sniffing the decryptkey.

[tamasine]

Originally posted by Mr. Suspicious
As stated before the player structure itself isn't encrypted (it's only compressed). That's the reason why ShowEQ works in GPS mode when you're not sniffing the decryptkey.

i guess that's changed then. (i'm not at home, and so will be wrong in the detail) - seq used to hit a new zone with "got PlayerInfo <foo> not decrypted" or similar. Then when it hit the right key this would spit out stuff(tm) and everything else would be rolled back with the key.
Are there any per-player structures that are encrypted then?
And (once again, how i thought it worked) .. the reason that seq worked in GPS mode was because the 'object moved' packets weren't encrypted.. and seq knew which one was the player (somehow). Movement packets seem to have little to do with the player info. I assumed that player-mob was object-000 and seq used this to gps while displaying object-XXX as mobs.

[edit] oh really? so out of interest, why's this in the source?
and this is the test packet used to check whether keys work. i may be missing something obvious, but this is what i meant by character data.. and it certainly seems like it was/is encoded.


packet.cpp: printf("EQPacket::dispatchZoneData():CharProfileCode:No
t Decoded\n");


[double edit]
Having located source, and looked it would appear that there's a "pre-encryption checksum" in the first few octets of the charprofiledata struct that could potentially stuff up using it as known-text. but all in all, i've yet to find anything implying that i got my assumptions quite as far wrong as you say.

[high_jeeves]

The CharProfilePacket IS both compressed, and encoded (a simple cypher using a 64-bit key). Since the packet is compressed, there is NO know plaintext to attack. You have to guess a key, decipher, decompress, if decompress works, then check known plaintext.

Even if you know exactly what the plaintext is, this is a VERY long process. Since they move bytes around in the data before they do the cipher (to hide the compression header), you are getting data from the middle of the packet. So, you would have to realistically change NOTHING about your character (buffs, xp, spell gems, etc..) to get the exact same CharProfilePacket.

So, as you can see, that is not realistic.

You should take a look at older threads on this topic, it has been discussed endlessly in the past.

--Jeeves

[tamasine]

Fair enough. I've not pulled apart decode.cpp enough to understand it properly yet.
My reading of all the endless threads in the past was both that very rarely did someone who knew what was what posted, and it was primarily focused on getting a key with no prior knowledge (turned the computer on). In fact most of the posts were about cracking or explaining public key encryption.
My query was whether it would be possible to work out the key to the next zone - because nothing will have changed in the character while zoning (? probably not true. and anyway there's probably a random number in there to do just as you say and screw the compression ?)

[high_jeeves]

There is no random number IN the packet, but knowing the exact CharacterProfilePacket doesnt get you anything. You still have to run through 2^64 possible keys to figure out which key is used. All knowing the exact CharProfilePacket would do is allow you to go in the opposite direction (encrypt your know packet, compress, compare instead of decrypt, decompress, compare...)the second operation is actually much faster, since the decompress step is much faster than the compress step.

So, in short: Knowing the exact CharProfilePacket (which isnt even really feasible anyway) gets you exactly NOWHERE...

--Jeeves

[suseuser7341]

Tamasine, the idea itself would only work, if you know exactly how the compression is done (which is not always deductable if you know the decompression) AND what the player data exactly looks like.
Then of course it shouldn't be hard to derive a symmetric key from comparing the compressed network data stream with the selfcompressed supposed player data. However I am afraid we can't create the later one reliable enough for plain text attacks.

[tamasine]

the decompression is library-standard zlib (aparently after the packet's been mungled around as per jeeves coment). however, fair point - i'd not considered the multiple <data> -> <compressed data> mappings.
*AS I Understood It*, the encryption was a post-compression rotating XOR.
<data> -> [compressor] -> [XOR]
this was an assumption based on sanity using real encryption (you virtually can't compress encrypted stuff).
then it would be almost zero-cost to just try it (compress playerinfo, XOR against incoming packet, try the result as a key)

however - if it goes <data> -> [XOR] -> compressor then yes. it gains less than nothing - because it makes the assumption of the packet contents in toto rather than picking known stable areas to try against.

heck - it was only an idea i'd not seen posted.. probably because all discussion has been from the zero knowledge basis. that the first reply stated things i was fairly sure were wrong dragged it out.

[S_B_R]

Much of the *knowledgeable* discussion took place in IRC. ;)

[throx]

It's not an straight XOR but it *is* done post-compression. It's been a while since I looked but I believe it's also salted so known plaintext is completely useless. To get the key you'd still have to brute force it.

The decrypt code is still in libeq.a, not decode.cpp so you'll have to either decompile that or just decompile eqgame.exe to get it. Either way is just as easy.

I'm not entirely sure of the reasons libeq.a is still a closed source module. It's not really like it does anything particularly clever any more. I guess it just raises the bar fractionally to stop someone recompiling the entire thing under Windows, but is nowhere near the impediment it used to be.

[term]

Ok, I'm confused about this.

If the client can decrypt a packet a passive sniffer can decrypt a packet. All the same information is there.

Is the problem that nobody knows how the key is transmited to the client? Even programs that used pub/priv keys can be sniffed long as you catch the key exchange.

[tamasine]

no, they can't. otherwise public key encryption wouldn't work.
and *this* is a searchable topic ;)

t.

[Cryonic]

From what I understand the process is this:

EQ client receives EQ servers pub key.
client generates zone session key, encrypts with server pub key and sends it to the server.

Server receives the key, decrypts it with its private key and begins to use the session key to deal with the client.

The problem is the size of the pub/private keyspace and the odds of being able to determine the servers private key. We can get the session key and public key from the client memory, but that doesn't help in determining the private key of the server because of the math involved.

Other threads have covered this very well. We don't have the resources or time to decrypt the key through brute-force. Want proof: go to www.distributed.net and see what their status is for decrypting a 64-bit key using brute force. My last check of their site put it at well over 3000 YEARS to find the key if they had to search the whole address space. That is with 20,000 machines looking for the key and this isn't a pub/priv key combo, so they aren't dealing with the problems of factoring to find the key.

[cbreaker]

They finished RC5-64.

They actually exausted most of the keyspace, some 90% or something. And actually, for SEQ, we'd only be looking for one key too, as the data is encrypted with the session key, the pub/priv is only for session key setup.


RC5-64 Finished! On 14-Jul-2002, after 1757 days of searching the winning key to RSA Labs' RC5-64 project was successfully recovered by distributed.net. 0x63DE7DC154F4D039 was returned by a P3-450 in Japan running Windows 2000. We're done!

It took almost 5 years to find "0x63DE7DC154F4D039"

They had to test 15,769,938,165,961,326,592 keys.

The average keyrate was something like 120,000,000,000 keys a second, which is about the speed of 22,000 2Ghz Athlon XP machines.

So, if you wanna brute force the key, go for it! But plan to purchase some 50 million PC's if you want the key within a few minutes.

Lots of stuff now-a-days is 128-bit encrypted. It's not 2x as hard to get the key either. It's actually 64x harder. At the rate of distributed.net's key checking (and if the key was near the end again), it would have taken 304 years to find a 128 bit key, all things being equal.

I'm actually dissapointed that they finished RC5-64. It felt like a brother, always there, ready to accept keys from every single machine at work I could run it on =)

[Ratt]

So switch over to cracking the X-Box key...

THAT looks like a long term project :)

[Cryonic]

or RC5-72 which they started up 2 months ago.

[cbreaker]

They started it soon after RC5-64 was completed.

I'm not really interested in RC5-72, it seems like a waste of time. I mean, they proved that in a few years time they could decrypt 64-bit encryption. I just don't think anyone is going to say "Hmm, we need this top secret info secured for decades. Since 64 isn't going to be strong enough let's go for 72!"

I think they'd go for 128-bit.

[Cryonic]

I remember reading some articles that /. pointed to that talked about the fact that the stock 1024-bit key that is used in SSL is not secure (can be broken in less than a day with commodity hardware) and that most systems should move to a minimum of 4096-bit or higher for their keys.

[throx]

You're confusing symmetric encryption (RC5) with assymetric encryption (RSA). The key lengths aren't related to each other.

Also, RC5-128 isn't 64 times harder than RC5-64 as suggested by cbreaker. It's 2^64 times harder.

[cbreaker]

Yea my bad. I think 4096 is the right number.

[SwedishChef]

I think 2^64 is closer to 18446744073709551616 than to 4096.

[cbreaker]

No actually I think 455003 is the right number.

(checking again if someone will correct me)

[throx]

/me whips out "calc".

/me presses "2"
/me presses "x^y"
/me presses "64"
/me presses "="

18,446,744,073,709,551,616