2 decryption ideas for SEQ Devs

[jbjam]

if the eq server sends the public key to the client ( i think this is how its done )
you can intercept it and replace it with a public key you know the corisponding private key to then after EQ has generated and sent the symetric key out to the server, you intercept that decrypt it ( since you know the private key )... and then re-encrypt with the public key the server sent you this is the classic man-in-the-middle attack on Public Private key encryption ( needless to say they've done some stuff to try and work around the problem, but basicly it can still be done ) however, its a lot of work and its editing the data stream, plus its very dangerous lets say there is a command in the eq data stream that says hey for the sake of fun send me your public key.... now if the interceptor didn't notice this, you'd send your invalid public key that you sent to the client and bamm you'd get nailed but public keys are sooo big you could prolly get away with a find and replace on the outgoing stream
------------- 2nd idea -----------------
Possibly attack the symetric key generation ( this may be the easiest way ) thats what they did to netscape ( attacked the symetric key generator ) to break netscapes SSL well the client generates the key then encrypts it with the public key and sends it off ... this generation is suspect if they do something stupid like use the generic C rand() function and seed the random number generator with the time, all you need to do is keep track of when EQ is started to figgure out the key irregardless it would take some disasembly work to figgure out how the key is generated ( this again in turn implies a lot of work )

[high_jeeves]

if the eq server sends the public key to the client ( i think this is how its done )
you can intercept it and replace it with a public key you know the corisponding private key to then after EQ has generated and sent the symetric key out to the server, you intercept that decrypt it ( since you know the private key )... and then re-encrypt with the public key the server sent you this is the classic man-in-the-middle attack on Public Private key encryption ( needless to say they've done some stuff to try and work around the problem, but basicly it can still be done ) however, its a lot of work and its editing the data stream, plus its very dangerous lets say there is a command in the eq data stream that says hey for the sake of fun send me your public key.... now if the interceptor didn't notice this, you'd send your invalid public key that you sent to the client and bamm you'd get nailed but public keys are sooo big you could prolly get away with a find and replace on the outgoing stream


Man-in-Middle attack will fail here... They control the protocol, down to the smallest detail.. they change the protocol, see whose clients (really the MiM client) fucks up the exchange, and all ShowEQ users are banned. MiM works well with defined protocols, standards, or where the vendor doesnt realize that a MiM attack would take place.



Possibly attack the symetric key generation ( this may be the easiest way ) thats what they did to netscape ( attacked the symetric key generator ) to break netscapes SSL well the client generates the key then encrypts it with the public key and sends it off ... this generation is suspect if they do something stupid like use the generic C rand() function and seed the random number generator with the time, all you need to do is keep track of when EQ is started to figgure out the key irregardless it would take some disasembly work to figgure out how the key is generated ( this again in turn implies a lot of work )


We know the random key generator (Atleast, to some extent) from looking through eqgame.exe... the entropy is good enough, that "predicting" the key is going to be virtually impossible (And will still require software on the client).

--Jeeves

[Raistlin]

All:

From a non-windows programer (who's probably going to have to BECOME a windows programer pretty quickly due to SEQ), I have a very basic question.

Is there any way to do the following:

1) Dump memory to a file on disk somewhere without triggering protected memory traps and/or attaching to a particular program. I would think this could be done somehow as when there's a windows crash, windows does a disk dump of current memory. Better would be to dump a "block" of memory to disk.

2) Figure out where a particular program's data segment starts and ends without actually attaching to the program? I would think that Windows would again have this knowledge as the operating system.

So, here's my generic, probably impossible idea. Instead of attaching to the running Everquest process and picking out a particular place in it's memory (thereby allowing the EQ process to detect an attachment or memory read), how about figuring out where the memory everquest is using is being stored, dumping it to disk and having a seperate program pick that memory for the key? Would this still generate a trappable "event" that EQ could pick up? Or would it be impossible to find the key in this memory?

I have never posted anythign so far out of my league before so I expect the "STFU Moron" answer to this one.

--Raistlin

[high_jeeves]

Please see the (many) existing discussions on ring0 or kernel drivers for more information on what you are talking about.

--Jeeves