Two ways to keep ShowEQ passive

[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/~galen...UsenixNt99.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...