Two ways to keep ShowEQ passive

[blebel]

I can see two ways to keep ShowEQ passive and beat the current crypto/compression.

1. Even though the data is compressed before encrypting we can make assumptions on the type of data. I have not looked into what kind of compression algorythm is being used but I would suspect the standard zip format.

A Zip packet has a predictable structure,

The nature of headers within a ZIP File
Apart from a few small differences, the headers within a ZIP
file are all almost identical. Each has the same general format
and all store a few key pieces of information to be used by
the program extracting the file. Each header contains the
following information:

The version of the ZIP format used to create the ZIP file
The minimum version required to extract the data within the file
The method used to compress the data
The last modification date and time
A CRC32 Checksum
The size of the data segment prior to compression (the size of the original file prior to it being compressed)
The size of the data segment after compression (the size of the original file after compression)
The length of the filename for the given data
The comment associated with the given segment (text)
The attributes associated with the file internally (used by the extractor)
The attributes associated with the file externally (the extracted file's attributes)
The relative offset of this header (the boundary between where the last header stopped and this one started)

2. Instead of using brute force we might consider breaking down the key-generation/transmission to gain access to all future keys.
2.1. The client has to have a key to decrypt the data.
2.2. This key has to be generated by the client or transmitted by the server
2.3. We can intercept or generate they key.

Blebel

[Digi]

Provided they do use ZIP and not some other compression method. But your point remains valid, most of the compression methods do have some predictable properties.

[LordCrush]

Makes sense to the point of the compression,
but i don´t understand the part of intercepting the key - here they use a public key encryption to transmit the key ... i dont understand how you want to crack that. If i remind me correct the client uses a public key from SOE to encrypt the session key and we dont have the privat key from the server.

[blebel]

I have not looked at EQ specifically but in general this is how we would break the public key private key schema.

Client Server

SOE Public Key ----> SOE Private Key

"Please send me the new encryption key for Zone xxx"

EQClient Private Key <---- EQClient Public Key

"Sure, here is the new encryption key for Zone xxx"

So when the key is sent to the Client SOE is using a public key derived from a private key which resides in the Client.

Since there are a lot of users I presume SOE has a shared private key for all the clients.

Grab the private key from the client and use it to decrypt all future key management packets.

To change the private key on the client SOE has two options.

1. Use the old key to encrypt the new key (well we can already read everything encrypted with the old key)
2. Push the new key unencrypted (dohhh)

It is also possible to use "dynamic keys" one time keys (an example would be to have a (client) private key generated every time with a random factor based on CPU cycles and uploading the public key encrypted with the public key from the server)

Client Server

SOE Public Key ----> SOE Private Key

"Please send me the new encryption key for Zone xxx"

EQClient Private Key <---- EQClient Public Key

"Sure, just send me the public key derrived from your random private key"

SOE Public Key ----> SOE Private Key

"Here is my dynamic public key"

EQClient Private Key <---- EQClient Public Key

"Sure, here is the new encryption key for Zone xxx"

Anyone know how often the private keys for the Client are generated ?

Blebel

[deadbane]

I think what he is saying is intercept that public key sent by the client....discard it...and send our own from SEQ(Spoof the client)....then just hand the key to the client.

I dont know Crypto but that sounds like a reasonable Idea.

[blebel]

That would not be passive, that would require a packet filter to filter the messages from EQ Client and act as a Man in the Middle.
(Server thinks he is talking to Client and Client thinks he is talking to server)


Such a system is hard to create and horrible to keep undetected.

Blebel

[high_jeeves]

The version of the ZIP format used to create the ZIP file
The minimum version required to extract the data within the file
The method used to compress the data
The last modification date and time
A CRC32 Checksum
The size of the data segment prior to compression (the size of the original file prior to it being compressed)
The size of the data segment after compression (the size of the original file after compression)
The length of the filename for the given data
The comment associated with the given segment (text)
The attributes associated with the file internally (used by the extractor)
The attributes associated with the file externally (the extracted file's attributes)
The relative offset of this header (the boundary between where the last header stopped and this one started)


The header (Which is only 2 bytes), is shifted to the middle of the packet before encryption. The header also doesnt contain all of this data (why would it?). They arent compressing files here, they dont need 90% of these attributes, the are just using basic stream compression. No dice here.

--Jeeves

[blebel]

OK, so patterns in compression are a no go.

How about the public key private key, any thoughts on that ?

Blebel

[high_jeeves]

By the nature of public/private, we can crack it... but the billion years per zone that would be necessary to do so, might turn off some people. If they could do this, it would have done it a LONG time ago (and none of the currently used internet encryption schemes would currently work for anyone).

--Jeeves

[blebel]

I do not beleave we need to "crack" public key private key, remember we already have the "private key" for the Client. (even if it is random generated we can extract it).

Blebel

[throx]

How many times do I have to repeat myself:

THERE IS NO PRIVATE KEY IN THE CLIENT

The server sends it's public key. The client encrypts the symmetric key with this public key and sends it on the wire. The server then decrypts the symmetric key using it's private key which is NEVER SENT TO THE CLIENT.

The key exchange is secure.

[HanzO]

Is this key readable from memory?

[seqseq]

Yup. It sure is. Now how to make this undetectable?

[snidely]

I don't do much (any) windoze programming but can you make the rip code run in ring 0 as a device driver? They way it's not in the process list and the end user can call it anything they want with little trouble I'd think...

It'll also be able to read protected memory as it's running in ring 0.

[IgorQ]

If we are conserned with LibEQ.a being a pw sniffer such that we Md5sum it. Then whats to stop the people from posting links to Key rippers that do not do anything but grab your login info. Nothing. I would recommend caution when running anything Dl'ed from the net in this mode or any mode. Guess I should call my windows programing buddy and get a copy of his compiler.. Unless Fee or Ratt post it.. or its source that i can follow its not going on my machine.

IgorQ.

[throx]

It is impossible to make a memory reader undetectable. All Sony has to do is find the SEQ sniffer code and write the specific code required to detect it. It's trivial to get a list of ring 0 drivers. It's trivial to determine if another process has a handle open to your process.

It is possible to make it exceedingly difficult (basically write a sandbox that intercepts the API calls EQ would make to detect the reader) but Sony has the advantage of SEQ being a purely reactionary response. SEQ cannot be "fixed" until it's determined how Sony "broke" it each time.

[HanzO]

Couldn't Detours be used?

http://research.microsoft.com/sn/detours/

[HanzO]

To read about it:

http://research.microsoft.com/~galenh/Publications/HuntUsenixNt99.pdf

More sophisticated than pure memory reading, but it might cirumvent process attachment detection.

[jonseq]

Detours modifies the in-memory executable code, which could be easily detected.

[RavenCT]

Forgive my ignorant, non-developer self, but what is to stop SoE from encrypting either the key activly in memory or the location of memory that they are using?

I may be WAY off base here, but just another one of those loose ideas...

[tristanbfg]

Forgive my ignorance, i haven't been following this too extensively but I am wondering...

What makes decryption difficult?

The point of encryption is to make information unreadable by a third party. In the case of EQ, the information is being sent between us and Sony. We have access to the client. What ever algorithm they are using to encrypt and compress the data, we have access to. Even if they are using a strong encryption to exchange the keys later, we have access to the method they use to encrypt and decrypt. Why can't we rip it from eqgame.exe itself and use that as a base to make our own code to read the data streams?

I understand how we were doing it before.. We were basically trying to brute force crack the key for data being sent to the client.

I understand what I'm suggesting.... That we would have to basically track the entire EQ session both directions to detect any key transmissions.

We have the client, there is no encryption that Sony can use that can't be broken. We can decompile the eqgame.exe without them ever knowing it. At some point, it won't be worth them trying to keep up with us and drop the fact that showeq works again.

[high_jeeves]

Folks, please... if you have no idea how crypto works. Please dont post the same thing as hundreds of other people asking why it isnt easy. If it was so easy, than there wouldnt be any encryption. Yes, we have all the code. So, we can decrypt. We dont have the key, or any means to get it out of the data stream (unless you know the server's private key). As long as you dont mind a few billion years of decrypting between each zone, everything will work just fine.

PLEASE dont post anymore about encryption unless you know what you are talking about.. until then, you are just making my teeth hurt. There are LOTS of good whitepapers on the web, if you are interested in learning.

--Jeeves

[baelang]

i guess we need a FAQ: PKI and encryption tutorial to point all these people to.

[rizwank]

thanks jeeves.

I know some, dont know enough and refused, up to this point, to ask any questions... I read the posts, maybe asked in the IRC chans, but .. sigh .. I never posted on here my "omg, I found the answer! EQ must have the decryp algo in its source!"

heeh anyhow good job and good luck

[Chyran]

so are there no packets in which information is sent that is fix? i mean where we know that at some point in the decrypted packet, we have to be able to read <...> ? maybe even at the point of key exchange, or shortly after, one packet that is sent always at the same time and therefore detectable?

[high_jeeves]

Chryan: Please read three posts above yours.

There are lots of very smart people that have been working on this for years. If it was as simple as your post suggests, dont you think it would be broken by now?

Please, do some research on how the system works, and on how PKI works in general, then post.

--Jeeves

[codemonkey]

Jeves,

People have been trying to crack PKI for years, but that is without having the receiving end of the encryption pair.

It make it much easier to hack an encryption if you have access to the client, this is where most of security breeches come from when dealing with VPNs.

A remote user opens a mail attachment that contains a virus (yes they still do that, even if they have a P.H.D). The virus can then grab the key from the VPN software and if, (IF) the virus/trojan has an understanding of the actual PKI code in the VPN client, it can then decrypt the information.

Is essence both sides are correct and wrong. Yes, it is extreamly difficult to crak 64bit encryption when you do not have access to the server or the client, but if you have access to either one, you can decode the information for the specific client-server session in the case of client security breech, or all sessions in the case of a server security breech.


The first rule in VPNs is you are only as secure as your most vunerable remote user.

[high_jeeves]

Yes, that is true. that is why we can decrypt at all, because we have access to the client. We can also sniff the key, which is why ShowEQ is currently working. I am not arguing that having the client is not extremely useful. But it doesnt mean it is just going to be as easy as pushing a button, and many of the people here seem to thing. My point was, read up on the complexity before you start asking silly questions about things that you really dont know about.

--Jeeves

[OldNecro]

Why not just turn this into a distributed computing project? I own 13 computers myself, and I'm also a consultant for a large IT firm in town. I have access to hundreds of computers on which I could install the crack client on as an invisible service and the users would never even know... Look at the success of Distributed.Net's RC5-64 project. It did take a couple years, but there's no way VI is using a 64-bit encryption scheme.

Just set it up exactly like distributed.net's projects where the client will hammer a block until all possibilities are exhausted, then have it blast that block over to a keyserver and download a new one. If we got enough participants I bet we could get every zone decoded in a few weeks...

(Of course, I may be underestimating the scope of the project)

[MisterSpock]

The fact that the keys are generated randomly, on the fly, is the problem here. Sure, the attack could be parallelized (distributed), but we'd have to sit in a zone (online the whole time) for a couple of weeks waiting for the correct key to pop...

[OldNecro]

I did a bad job of explaining my idea...

I'm under the impression that there has got to be some kind of mathematical scheme to produce the key needed. I mean we can get ourselves a list of say 10 keys per zone or something, then try various relational schemes to link all the keys back to their original formula. Then we'll be able to produce the keys on the fly until they change the algorithm again, and if it's actually feasible to decode these algorithms, it will just be more of the same. We had to update the decoder in SEQ every few months anyway, right? Now we just have to find the new algorithm each time they change it, which should take about the same period of time provided they're not using anything larger than 32-bit encryption; and from what I've read here, it sounds like 8-bit to me.

I mean, 8-bit encryption? I have several computers over 1ghz in speed. I should be able to brute-force an 8-bit code from beginning to end in like 12 hours... But then, you have to multiply that by however many codes I'm trying to compare to get the source algorithm...

I'm just trowing stuff out there. It's definately something to think about, but I don't know the nature of the encryption as far as how wide the encryption is, so all I can do is speculate and hope my idea sparks someone's immagination...

[tamasine]

As i read in another post, the key is a 64bit string. This is XORed on the data stream. the key is a random number which is associated with your-client<==>this-zone-server. So the key is useless to anyone else, or as soon as you zone.
8 bit encryption your computer could crack in under a second.. even if it was a modern stream cipher. this is just an xor cipher, but random. there might be an 'algorithm' to generate to unique-per-use keys, but it's more likely to be purely random. there's no reason for it to be otherwise ;) 64 bits takes longer. much longer.

[DebianSEQ]

When new files are downloaded via patch, I noticed (a while back, may have changed now) that the downloads were in .gz format.. Perhaps this is the compression scheme?

[bel]

Knowing the compression method doesn't help in finding the key. The fact that SEQ still works after you sniff the key shows that the developers already know how the compression works.

I'm pretty sure the only purpose the compression serves is to prevent a plaintext attack on the packet, which I think is what the previous way of decoding the packets involved, at least partially. But without knowing what data a packet contains you have no idea what it will look like once it's compressed.

And since you can't do the steps out of order, i.e. decompress and then try to decrypt, you're still at square one as far as finding the key is concerned.

As far as the algorithm for determining the keys goes, if it doesn't use at least some bit of randomness unique to the PC it's running on I'd be very surprised. So knowing the algorithm wouldn't neccesarily put us any closer to cracking a particular key at will.

[OldNecro]

Yeah, but even in that situation we'd be better off. If we could find out what attribute of the host system it is using to determine the key, we'd be able to probe for those attributes with a little TSR program of our own. My understanding is that the fear is centered around scanning memory that EQ is currently in control of. If we knew what the program was doing to determine the key, we could just mimick *whatever* it is that it is doing and get the key ourselves. None of that would involve scanning EQ's memory...

[loiloi]

ROFL DebianSEQ.

Although I don't remember who posted it, the idea to read some white papers on encryption is a good idea. If this program inspires interest to you guys to learn some new things, that's great, but think a little and research a little before you make yourself look silly by posting here :)

Or don't. The amusement is sheer enjoyment -- to a point, at which it changes from enjoyment, to annoyment, and maybe by only reading this onethread i'm not there yet :)

[Lab_Assistant]

But without knowing what data a packet contains you have no idea what it will look like once it's compressed.
Don't we already know that? I can think of a dozen static spawns (event timers, bankers, the "seq_users_are_lame" mobs in Hate) that are always going to be in a known position. Don't we know that when zoning into most zones, that many of the packets that we get are going to translate to the same value every time?