EQ Encryption

[frizzo]

I have been using seq for a while now on and off, and started thinking about a way to make our guilds website more dynamic. Basicly, automatic char updates.

I started digging around in the seq code, and have a few small questions you might be able to help me with. First off, keep in mind, I am a network packet newbie, but NOT a newbie coder. So, this will be a crash course for my in packet disassembling :)

What info can be grabbed from the EQ packets without using decryption. I don't want it get into the hastles of descryption becuase I will need to make things work on multiable platforms. There is a simular tool out there avaiable from magelo.com. But, that tool ONLY updates there site. I just need to grab the following data, name, level, class, race and guild. (For people with multiable guilds) The tool on magelo.com handles the entire char inventory, which I don't need.

Are they using some form of decryption or is this basic info avaiable without it ?

Any help is greatly appericated.

[high_jeeves]

name, level, class, race and guild.

Is all encrypted data. Items are not... thats why magelo works.

The following packets are encrypted, take a look in everquest.h to get a good idea of what you will be able to see, and what you wont:

NewSpawn
ZoneSpawns
CharProfile

--Jeeves

[Ratt]

Originally posted by frizzo
I have been using seq for a while now on and off, and started thinking about a way to make our guilds website more dynamic. Basicly, automatic char updates.

I started digging around in the seq code, and have a few small questions you might be able to help me with. First off, keep in mind, I am a network packet newbie, but NOT a newbie coder. So, this will be a crash course for my in packet disassembling :)

What info can be grabbed from the EQ packets without using decryption. I don't want it get into the hastles of descryption becuase I will need to make things work on multiable platforms. There is a simular tool out there avaiable from magelo.com. But, that tool ONLY updates there site. I just need to grab the following data, name, level, class, race and guild. (For people with multiable guilds) The tool on magelo.com handles the entire char inventory, which I don't need.

Are they using some form of decryption or is this basic info avaiable without it ?

Any help is greatly appericated.

Magelo has nothing to do with packets, nor does it have to futz with encrypted data. It gets everything out of memory... unless something has changed since I last looked at them.

[frizzo]

Well, not sure which of you is correct. But, I am going to have to explore each method a bit :)

1) Has there or is there plans to port libEQ to Windows ? If I am going to do any network decryption, I am gonna need it :)

2) Ok, if they are looking this stuff up in raw memory, thats gonna be real fun to figure out how to grab that. I don't even know where to start, I guess I will need to do some searching on the net to see if there are any docs or code as an example of how to do this.

The Magelo tool is written in VB, I belive. Which, correct if I am wrong, isn't really powerfull enough to read from raw memory. I have never used it, becuase its not cross platform. (What a suprise from M$ :)

The most recent version of the tool, requires you to load it up BEFORE EQ is loaded. So, I wonder what the deal is with that. Maybe it is doing to 2nd, and needs to find out where this info is stored. The Magelo tool also grabs the chars name, so if that is encrypted, how did they grab it without reading raw memory ?

[high_jeeves]

1) Has there or is there plans to port libEQ to Windows ? If I am going to do any network decryption, I am gonna need it

No, absolutely not, and there never will be. Windows libEQ = Windows ShowEQ = Verant coming down hard on ShowEQ again because of the wider market = libEQ useless while they futz around with the encryption again = no decryption in ShowEQ.



The Magelo tool is written in VB, I belive. Which, correct if I am wrong, isn't really powerfull enough to read from raw memory. I have never used it, becuase its not cross platform. (What a suprise from M$


I dont know much about the magelo tool, but VB can read from raw memory just fine.

--Jeeves

[PawnOrc]

Think about this ...

A network "packet" comes in through a "protocol."

Information in a "packet" is passed to a "client" application.

"Client" uses the information and either passes something back through the "protocol" or not.

You could pick-off the information at:

"Packet" level
Some step in the "Protocol"
"Client" level

If you pick above "client" level, then you must "decode."

If you pick passed the right level in "client," then you may not need to decode.

The EQ client decodes and uses information that is encoded at packet/protocol level.

SEQ is an odd product. I will not say how they figure out how to "decode" ('cause I am not 100% sure) but the sheer speed with which they can "fix" SEQ after VI breaks it and the very, very small difference between one version of libEQ and another (except maybe the last one) should tell you all you need to know.

SEQ, Magelo, or any other EQ "sniffer" could have picked infomation AFTER the client "decoded." I am guessing it was a hell of a lot easier to pull a small amount of info out of a "coded packet" than it was to figure out data structure inside the binary client. But what about information that was never "coded?" It would be far and again easier to pick apart the client data structure on non-coded information that you could read at the "packet" level.

If you could follow what I am trying to say then you have all the info you need.

BTW - how many of the people who put libEQ together are still active with SEQ? Also - do you think Magelo or any of the others you may (or may not) know of could have been done without the libEQ data? Now they can because they learned what was real and what was encoded. They all owe the libEQ people a beer.

The political guys here will spew some stuff at you but if you look at how SEQ works and think hard about how libEQ must be getting "fixed" you will crack this nut. Now coding your solution is something else ...

*laughing about all the libEQ mystery* Really sort of funny.

[Ratt]

Originally posted by PawnOrc
The EQ client decodes and uses information that is encoded at packet/protocol level.

Depending on the crypting technique used, decrypting something at the packet/protocol level is much easier than decrypting a higher level. SEQ encodes the information before it's even put into a packet and sent over the wire. If the packets themselves were encoded in some form and the data inside was left intact, it would be a much easier job to 'fix' libEQ when the time came.

As it stands though, the packets are plain and obvious, it's the data inside that's crypted. Pulling the data out and figuring out what the hell it is, it's length, etc... is a major pain in the ass. If the packets were just crypted, it would be easy... they'd all have a start and stop place per packet that you could find and figure out fairly quickly.


SEQ is an odd product. I will not say how they figure out how to "decode" ('cause I am not 100% sure) but the sheer speed with which they can "fix" SEQ after VI breaks it and the very, very small difference between one version of libEQ and another (except maybe the last one) should tell you all you need to know.

Recent changes (1 - 1.5 years) of libEQ have been 'small' because it was mainly optimization and some other things added, and had nothing to do with changes in the decode... Changes in the decode is a major under taking and is anything but speedy.


SEQ, Magelo, or any other EQ "sniffer" could have picked infomation AFTER the client "decoded."

Magelo is a very different beast from SEQ. Magelo reads directly from your memory, after the EQ client has decoded the information. SEQ takes the packets out of the stream before the EQ client sees them and decodes it. They have absolutely nothing in common at all. Every other EQ "Sniffer" is based around the libEQ, or the Magelo concept. One requires itself to be run on the EQ machine, done does not (and will not). There ARE hybrid versions of SEQ out there, but that's another topic entirely.


I am guessing it was a hell of a lot easier to pull a small amount of info out of a "coded packet" than it was to figure out data structure inside the binary client. But what about information that was never "coded?" It would be far and again easier to pick apart the client data structure on non-coded information that you could read at the "packet" level.

Hardly... it's tons easier to find information in memory and snag it than it is to figure out the decode protocol for EQ packets... for that matter, it's tons easier to scour memory on a given machine for ANYTHING than it is to arbitrarily try to pull data out of a packet stream. Now, if EQ started encrypting data IN MEMORY, that might be another story. But that's beyond anything EQ needs to do.


BTW - how many of the people who put libEQ together are still active with SEQ? Also - do you think Magelo or any of the others you may (or may not) know of could have been done without the libEQ data? Now they can because they learned what was real and what was encoded. They all owe the libEQ people a beer.

The current libEQ is a collective effort of a number of people, JohnQ, Zaphod, Fez, Xylor, Ashran, Megaton, Quadlynx (Patrick), Fee, Casey, and a host of others I am forgetting off the top of my head, some even before my time. Some of them are around, some of them are not.

[RSB]

Listen to "The Don"

[PawnOrc]

Ratt,

As a side point, do you know who put out the first libEQ? To what degree is the "current" one derived from the early ones over at the "other" site?

Your spin on my comments is mostly accurate. The main point being that there is absolutely no need to use libEQ for the orginators intended use.

This whole mystique about libEQ is getting in the way of people actually thinking about what is going on in SEQ. The libEQ thing is one way to do it. There are others (like the one we are talking about).

It is one thing to protect your personal turf by keeping libEQ private. I think you are doing the right thing btw. It is another thing to allow the politcal posters here to confuse people and direct them away from doing their own thinking.

There is more than one way to skin a cat. libEQ and SEQ are one approach that made real sense when it was done. For other applications it may not make sense.

Teach them to fish and feed them for life.

Example? Ever use the enchanter line of bind sight spells in game? Ever compare the packet stream before and after casting? I wonder what that means about the client?

Now if we are stuck with the libEQ/SEQ idea, such thinking is not too valuable. But seen from, say, the Magelo pov, this gets interesting.

Teach fishing Ratt. You are frig'n brilliant. You could help create a new generation.

[RSB]

few things
1) libEQa is not open source not because of "protect your personal turf". It isn't open source since the decryption routines, if publically avialable, would facilitate a bunch of Windows based programs which would have Verant clamp down and start agressively stopping the use of programs like SEQ.

2) To me using SEQ to pull the data out of the packets and dump it out to a file, database, what ever or using some memory monitor to do it.....I'd go with SEQ just for the ease of use. Very easy to find where the information you are interested in is and just push it to a file where with the other setup you have to figure how the data is stored in memory, find it and extract it. And the location where that data changes from patch to patch where the packet structure is updated by others every time it changes thus your custom code in SEQ probably wouldn't have to change.

I use the wizard bind sight line to explore zones (yes with SEQ) for shit and grins. I've never noticed anything differnent with SEQ. What are you saying is different?

[loiloi]

PawnOrc, it's pretty apparant to me that you don't have a clue what your talking about. Ratt already stated that it is much easier to get data from memory than decrypt a packet sent from EQ, so I won't repeat that blaring example.

What I will focus on however is your not-so-subtle attempts to suggest the 'mysterious' ways the libEQ library is updated. It's not through some insider connect with a VI developer, it's through the blood, sweat, and tears of the people that work on cracking the eq encryption. I'm sure they'd prefer to be in your fantasy world of the great conspiracy VI->seq dev connection, but there's no mystery here.

Other than that, as I always have, I find it funny how some people can convince the masses that they have a clue what they are talking about in technology related matters, while the few educated shoppers can quite easily recognize they are just talking crap.

Peace and amusement

--me

[Exo]

heh, so a windows version of libeq would produce a more rabid response from Sony eh? You think they would go as far as to change the encryption to 64bit 64block encryption? Naa, not as long as showEQ stays on linux, I'm sure we'll be safe.

[BlueAdept]

Originally posted by Exo
heh, so a windows version of libeq would produce a more rabid response from Sony eh? You think they would go as far as to change the encryption to 64bit 64block encryption? Naa, not as long as showEQ stays on linux, I'm sure we'll be safe.

When there was a WinSEQ, for a while until a libEQ.a was put out, Verant was making changes (almost daily) to the encryption just to keep WinSEQ from working. They also banned a whole BUNCH of people for using WinSEQ. They scanned the task manager (and maybe directories) on the hard drives for it.

[Exo]

...and as I recall the fixes to those changes were normally posted within an hour of those changes actually going live. Sometimes the fixes were out before the changes went live ;-)

Just seems odd to me that libeq.a is still defended by that old crutch when today it was made very obvious that Sony is being active to prevent the use of ShowEQ even on linux. Unless, that is, you can think of a reason that I have not for the changes to the strength of the encryption.

To each his own though, I guess I just find humor in it. Only reason I care is because I'm a giant follower of the idea of freedom of information. I've given my opinions in this before, had talks with the dev team about it before (actual logical talks not flame wars) and Ratt gave probably the best reason.

Forgive me for misquotes here Ratt as it was a long time ago but it went something to the order that a line has to be drawn somewhere and as it can not be anything other than an arbitrary line he decided it was to be placed there, at the ability to install linux and compile ShowEQ on that platform. We both agreed that the task of installing Linux is no more difficult than a Window NT install (probably easier now) and ShowEQ is simple for even an ignorant person to get installed by following any of the many guides (I let my dog do the install on a RedHat 8.0 box the other day, sit Orion sit... make Orion make!... good doggie). I can see his argument that he doesn't want everyone to have ShowEQ, I just don't agree with where the bottle neck is being placed.

[Ratt]

The "fixes" to those changes were two fold:

1. They were trivially easy, compared to last weeks encoding. Never mind this weeks encoding.

2. Ashran and Megaton worked thier ASSES off each time it was changed, and went through a lot of cigarettes, pizza and beer each time, burning themselves out. I have absolutely NO desire to see the devs on this project be put through that hell.

Given fact number one, the consequences of a daily rotation would be ridiculous to us. Our saving grace in that area, however, is that it would really fuck with players as well.

I'd say more than a year of no changes to the encoding is worth not having a Windows version. As for upgrading the cipher mechanism, I'm suprised it didn't happen sooner. There were plenty of simple ways to beef up the method used and fix a couple of the loopholes.

However, I've said it before, and I'll say it again... the Achilles heal of Verant is the fact that the client HAS to be able to decrypt the data, and we have total, completely, unrestricted access to the client. I see absolutely no way for Verant to change that... and because of that fact, anything they do will be troublesom at best.

This latest change can have several consequences, but whatever those consequences turn out to be, SEQ will still be in use. They can't EVER prevent something like SEQ from existing. VI knows this, and the ROI for rotating the cipher on a daily, weekly, monthly basis just isn't there if there are a fraction of the user base using it in Linux. You put it out on Windows, and your SEQ population rises exponentially I'd say... maybe not quite that much, but enough to make the ROI totally worth it.

[darkangelx]

Ratt:

As you explained the client must have the information that the dev's seek. Is this stored in the same place all the time (compiled into eqgame.exe)? or elsewhere?

[Exo]

I just wanted to make clear that my statments to the speed of the patches for SEQ, almost what 3 years ago, should in now way reflect upon our crurrent team and I didn't intend that. Ratt is totaly correct in that the problems the current team face totaly dwarf what was going on back then and frankly I'm amazed they are making progress on it at all. Ahran and Megaton worked very hard on this back in the day but trust me, I'd rather Ratt be at the wheel. I know I'm happier with the project as it is now.

[lostinspace]

Regarding this:

-------
However, I've said it before, and I'll say it again... the Achilles heal of Verant is the fact that the client HAS to be able to decrypt the data, and we have total, completely, unrestricted access to the client. I see absolutely no way for Verant to change that... and because of that fact, anything they do will be troublesom at best.
-------

I'm not exactly expert in encoding, and also if I'm correct in my next assumption, maybe its not good to post, but if its true, I'm sure VI programmers knows it already :)

Anyway, you have total access to client CODE, but not to client DATA ( unless you run SEQ on same PC under Win). Therefore, if they generate pair of asymetric keys (with RSAlike algorithm) on client, and use it to excgange some long enough symetric key to be used later with some faster symetric algorithm (like IDEA) .... then you would not have possibility to decrypt it.

Generating long enough asymetric keys is fast enough now on modern PCs. And since SEQ does not have access to EQ memory, even if in code you know where key pairs would be generated, you wouldnt be able to read it ( unless you have WinSEQ on same PC as EQ). Only other solution would be hard key pair cracking, and that is impossible in short time (or ever if long enough key pairs).

Now, as I said, I may miss something here, but not every possible encoding change is 'troublesom at best' ... some may be 'unbreakable' :\

[bonkersbobcat]

Anyway, you have total access to client CODE, but not to client DATA ( unless you run SEQ on same PC under Win). Therefore, if they generate pair of asymetric keys (with RSAlike algorithm) on client, and use it to excgange some long enough symetric key to be used later with some faster symetric algorithm (like IDEA) .... then you would not have possibility to decrypt it.You don't have to break the big fat hairy key, you only have to break the key that protects the big fat hairy key.

If the client code contains the half of the asymentric key needed to decode the monster key, then the client's key simply needs to be extracted from the client. ("simply" may not be a good word here.)

Without commenting on the difficulty level: If the client can decode the data stream, then the client contains the knowledge of how to do this. The trick is extracting this knowledge. Extracting the knowledge may require dissembly of the EQ client and a lot of time sifting through the memory space of a said running Client.

If the EQ client generates it's own key pair on the fly (sending the public half to VI for use in encryption), it may not be possible to crack the data stream by purely sniffing. If this is the case then a memory monitor will have to be installed on the running EQ machine, that grabs the private part of the key and hands it off to the SEQ machine. This becomes more risky as it is possible for VI to detect such a running memory monitor on the machine that EQ is running on. Steps would have to be taken to make this approach difficult to detect.

[lostinspace]

Originally posted by bonkersbobcat

If the EQ client generates it's own key pair on the fly (sending the public half to VI for use in encryption), it may not be possible to crack the data stream by purely sniffing.

Yes, that is what I was reffering to. Fairly simple to implement from Verant, and even not necessary for client to waste time in generating pair - server can send randomly picked public key from pre-generated database of key pairs, and client can generate only symetric key to send using received public part of asymetric key.

As you said, that can be 'decrypted' by having memory sniffer program on EQ PC, and once it sniffed key, it can send it to SEQ. But that would increase chance of detection (program that 'randomly' generate shiffer program every time?).

Anyway, as soon as even one program needs to be on EQ PC, there would be no need anymore for Linux only version of SEQ. And that is bad for Verant ( lot of EQ users with SEQ) and for SEQ community (too often encryption changes) - so lets hope Verant wont do that for their own interests, if not for ours :)

[Malketh]

Ok, I'll start with saying I'm slightly tired as I write this. For the record I've been using SEQ for god knows how long now and even though I've quit playing that game, my two roommates still do so I have to keep up to date anyway.

From my understanding of stuff, it doesn't matter what VI does, be it one large master key, asynchronous key pairs, etc. the keys in question will have to be exchanged in such a way that the EQ client can constantly and reliably decrypt it everytime. That means that even say a public key was echanged, even in encrypted form itself, it would be relatively easy to get the key out of the packet stream once the primary decryption algo is discovered (which can be done with enough time depending on key length). once that public key is gained it's even easier (relatively remember) to gain the private key used to decode everything else. The orginal keys, or algo would have to be client side and could be gotten with enough time, so no matter what VI does, they can't stop this community from cracking their codes.

Remember the only truly reliable encryption sceme is one that NOBODY else can read. :)

Now with that said I think I kinda lost my train of thought (maybe). And if I'm wrong in any of this, PLEASE tell me so I can learn more, after all that's what most of us are here for anyway.

For the record I've been spending a lot of time playing DAoC and using Excalibur and I don't think I've seen them redo the encryption scheme in months. I guess they just realized they can't stop it's use.

[lostinspace]

Malketh,

With asymetric key pairs, everyone can know public part (thats why it is called public). For example, EQ client generate one key pair public/private, and send public part to server. Server use that key to encrypt data that it send to this client. Even when you know what public key is, you can not use it to decrypt what server is sending. Noone else can , except one who has private part - and that part was never sent over network. Also that part is not fixed in code (was generated randomly in runtime), so you can not figure it out by disassembling code.

So only way to break that would be to read client memory in addition to just reading network packets, which is big change in SEQ principle of passive sniffing. Or to try and use brute force computing to find private key based on public key, which for any decent size keys can take years.

BTW, this is just theoretical discussion, not related to problem of old or new EQ encryption, of which I have not faintest idea how is implemented.

[MisterSpock]

The thing we must remember about this topic (encryption) is that there are some substantive limitations on what SOE can deploy as a workable cipher. This is not from a lack of cryptographic or programatic skills, but due, instead, to certain design limitations.

First off, and quite simply, the client must be able to decrypt the data stream in a manner fast enough to allow the game to function. This must function even on computers that barely meet the minimal specifications.

Secondly, it must (or should be) included and related to the main stream. That is to say, a third-party key agent is not practical for this example.

Finally, they must, in essence, give us the tool to decrypt the data. Unlike traditional decryption problems, we have the tool and know what the message is supposed to say. This provides a tremendous advantage that is typically not present.

The use of an Asymmetric encryption methodology is inappropriate for this type of stream data. The speed of transformation (either from Pt to Ct, or vice versa) (plaintext to ciphertext, etc) is too slow.

However, an asymmetric method can be used to pass a 'session key' that can be used (or a mathematical derivative can be used) for subsequent symmetric encrytions/decryptions. This is similar to how SSL works, for example. Again, though, the fact remains that we can get, one way or the other, three of the 4 keys in such a system. Getting the client's private key probably would change seq's passive nature - So this may not be the nut that needs to be cracked.

The key (no pun intended) is to discover how to break the session key (e.g. how to fully decrypt the data without truly posessing the session key). This involves understanding how the client's decryption routines operate. Additionally, we must consider any mathematical weaknesses the encryption methodology contains and how these can be exploited.

All routines and methodologies have some form of vulnerability. This one is no different.

[RSB]

MisterSpock hits it on the nail. Looking at this completely passively cracking the session key is much easier than cracking the finding the private key that is used by the client to decrypt the session key packet.

Something some people forget or don't realises is in an encryption / decryption routine any key can be used to decrypt the encrypted data.....its just that the data won't be in its orginial form...ie it will look like garbage. The reason the decryption routine in SEQ works is because it knows information in the unencrypted structures. Each key it tries it looks for that data in the location it expects it to be. When it finds a match it goes "BINGO, I'v got it!". There in lies the real problem of breaking the packet that encrypts the session key. How would you know you decrypted it correctly? Its not like a real key where you stick it in the lock and it either turns or not.

so this is what would have to happen if you wanted to crack the EQ packet stream by first cracking the packet that sends the session key.
Here is the encrypted version of that number
C46C1BDC3C5211D09200848C1D2EF1AB
what is the original key?
Hmmm since it could be any number from 1 to 2^16 then you start off with 1
1) decrypt the session key with 1 and get some other 16 byte number.
now there is no way of telling if the key you have is correct except for trying it out, so.
2) decrypt a new spawn (or other known packet with this key)
does it look like it should? No?
3) decrypt the session key with 2 and get some other 16 byte number.
4) goto step 2


Now all we've done here is do what the decryption routine does now (before it uses a newspawn packet to narrow its search of the session key down) but added the even bigger task of trying to break an even larger key then the session key.

[Resiliant]

One observation.

The simple fact of the matter is, we have the client code (at least the machine readable form of the client code) to look at. That is our great advantage, and really what Ratt is referring to as SoE's 'Achille's heal'. If we were simply monitoring the net traffic, and had to decrypt the data WITHOUT having access to the altorithm that decodes it, the task would be simply impossible.

As it is, what the developers now have to do is to reverse-engineer the latest VI initialization code that a) determines what the key is that is used to decript the packet stream and b) what altorithm is used in that decryption. Theoretically, no communication need occur between SEQ and EQ. What needs to be done is to a) start the monitoring process early enough in the EQ session as to capture the key negotiation sequence, and b) mirror the key assignment, and key decryption sequences on the SEQ machine.

This is one of those problems that is easy to describe, and REALLY hard to do. What the developers now have to do is to actually UNDERSTAND what the programmers at VI have implemented as regards initial key assignment, and packet encryption. This could take a couple of days, or several weeks, depending on how arcane, bizzare, and poorly written VI's code is. There is not much the rest of us can do at the moment (although I for one would be more than happy to decipher any machine-language stream that was provided to me) other than wait, support them all, and be patient. All of which are good character traits to have in any case.

Neither the procedure that obtains the real-time public key used to decrypt traffic, nor the procedure that actually decrypts that traffic can be complex. EQ sends HUGE amounts of data to the client machine, which is *extremly* busy performing graphics-intensive CPU operations. It doesn't have the time to do massive floating point or scalar operations on the packet stream. I would expect that the decryption algorithm would be no more than a few hundred machine instructions at most. Decode that, and we have them by the b**** :)

P.S.

Oh.. and RSB... your brute force technique for finding the session key makes the presumption that the 'original key' as you call it is only 16 bits long. A very optimistic assumption. You don't have to add very many bits to this to render this technique completely useless. It may take a current CPU only milliseconds to do a loop 64k times. If, however, the 'original key' were 32 bits instead of 16, then it would have to do the loop 4 Billion times. If it were extended to 64 bits it would be impossible to break the code using this technique. I believe a more intelligent approach is now required.

[baelang]

Just wanted to point something out, and see what you all thought on the subject.

i haven't been much into crypto for a while, but isn't the government restrictions on the export of munitions in our favor this time?

Sony sells their game in the US and overseas. dosen't this mean that their encryption systems are limited to relatively weak systems?

I thought that 56 DES was about the max they were permitted to use, or is that law gone now?

[Malketh]

Oh... I see now just what you mean by assymetric pairs. My bad. I'll be honest with you in case I didn't see it before (I've got to stop either being ready to go to sleep or waking up from sleep when I post), but I'm by no means an expert or even a novice when it comes to encryption schemes.. But I'll say one thing, this thread is nice for information and such. :)

[Blaze]

Would an attack on the random number generator work? I wonder what a histogram of the session keys generated by the client would look like. There may be huge chunks of the keyspace that hardly ever get choosen.

see http://razor.bindview.com/publish/papers/tcpseq.html
for a paper about TCP/IP initial sequence numbers.

[someshaman]

Somebody I just talked to on IRC on an Unix channel, showed me a screen shot where he was using M$ Debugger and showed which DLLs etc. ShowEQ was loading. One of them was crypt32.dll.

If they use that dll (a system one), it should be possible to trace the calls.

[high_jeeves]

The encryption is not done through crypt32.dll, it is probably loaded when the networking libraries are loaded.

--Jeeves

[throx]

Couple of cute fallacies here:

i) DES-56 (or some other exportable encryption) is easy to crack. Wrong. It will take you many days of CPU time to crack a single zone key by brute force if they were using DES. Most people don't want to sit in a zone for 48+ hours before the mobs come up.

ii) Encryption uses massive scalar/floating point calcs. It doesn't. Look at how many keys/sec something like RC5-64 crackers can test and you'll get the idea pretty quickly that decrypting a packet is going to be a negligible load on the server or client.

iii) Because you have the client, simple analysis will allow you to reverse engineer it so a packet sniffer can decrypt. This is wrong - Mozilla is an open source web browser and SSL is still secure.

The fact of the matter is that if Verant actually did a half decent job of their encryption and random number generator then cracking the packets in real time would be impossible without looking into the memory of the client itself (ie running an app like Magelo before you start).

For those who understand a bit of crypto, the sequence goes something like this:

i) Client generates a new symmetric key.
ii) Client receives public key from server and encrypts the symmetric key with that public key.
iii) Server received encrypted key from the client and uses its private key to decrypt it (the private key is *unknown* to the client).
iv) Communication continues using symmetric encryption with the client generated key.

The *only* reason libeq.a ever was able to decrypt the data was Sony rolled their own encryption and random number generator instead of using some off the shelf product which had been tried and tested to be secure. Believe it or not, that's a pretty common failing for software developers.

As for the crypt32.dll thing - almost every program loads that up, especially those that access the internet (wininet loads it). Doesn't really mean a lot.

[Blaze]

good post, that sums it up quite well.

One silver lineing is that since the client generates the session key, a man in the middle attack would work to get the client to use a session key that seq knows.

[binky]

Thankyou throx, i was about to post something along the lines of that to ease down all of this "We have the client so we can break any encryption muahahahaha" sentiment.

It's true, if they did it right using the exact method shown in throx's post, which is exactly how i'd do it, it's basically impossible to crack (unless you have a *lot* of time on your hands to brute-force) and ShowEQ as we know it is dead, unless all you want to see is your location on the map and other assorted but pretty useless unencrypted(?) information.

That is, of course, if ShowEQ doesn't want to resort to more nasty methods. The only way to break it is, as also stated above, a somewhat "middle-man" "attack" on the .exe (such as extracting the random session key at runtime in Windows directly from the EQ process, or by making it use a key that we know), or an inside job which would be to somehow obtain Verant's private key and decrypt the encrypted session key on its way out. But, would they just generate a new keypair? And who's to say their keypair will be static anyway. It could be rotated every 10 minutes if they're serious about security.

The middle-man deal could also be easily detectable if Verant are monitoring correctly because it must be done in Windows where EQ is running, and the EQ process must be either read or written to - but can they legally monitor us? Shrug.

Anyway.. Let's see what happens.

Cheers.

PS, Editing to say: The sense of doom in this post relies on how Verant have done their encryption. It could still be crap so none of this doom applies. Just be prepared and don't think you can do anything you want because you have the client.

[fester]

This is the theory of how EQ's new encryption works:

1) Servers have a public/private 512 or 640 bit key pair.
2) Public is available and is sent to client just before character selection mode and during zoning actions. (This is Op E541 from server to client and is stored as 80 bytes of data; likely a 640 bit key).
3) Client creates its session key with internal entropy (current process table values, custom random number generator, whatever it needs to insure some sort of randomness) encrypts this during ZONING periods (plenty of cpu avail, not doing anything else) and sends to Servers (who decrypt with the public key only they have).
4) The agreed method of encrypting for Character Profile on Zone, Zone Spawn Packets on zone, and possibly NewSpawn packets is DES CBC (Block cipher to prevent snoop or restricting key space searches)

Observations:
a) RSA challenge is to break a 576 bit number. Has been around many many months and has a $10000 reward. No one has won, so breaking a 512 (much less a 640 bit) key is not likely. Even if they did, VI could "use multiple keys, 1 per user" or "make a new key monthly or weekly". So even tho we see the key coming from VI as E541, it does us no good, we still can't read the session key from it.

b) DES CBC is a 56 bit encryption for 1 or more blocks of data (64 bits). Requires padding with 1 to 8 bytes in the last block. Prevent key space attacks where you KNOW the format and position of plaintext. CBC's first block is discarded (2 byte opcode, 4 bytes unknown, 2 bytes name), so they could have changes the format to add the IV? In any event it is fairly good, because much of the unknown data at the beginning will restrict attacks against CBC.

c) DES CBC is fairly fast and uses integer and bitwise operations. It is only used during zoning (plenty of cpu) and possibly during NEW spawns (scattered and limited impact).

d) DES is secure against known plaintext attacks (EQ old encryption wasn't). The asolute best method of attack known is Linear Cryptanalysis by Matsui. This provides for attacks on average of 2^28 difficulty. Applying this, for EQ, the more encrypted packets you see, the better you are at decoding them and at the point you have seen 2^28, then you can assume you can decode any key in 2^28 steps. You can trade space (ram/disk) for time (cpu) also and decode in 1 step with 2^56 data storage. 2^28 is 268 million. So expect terabytes of disk to do 2^28 steps and expect to wait (EFF $250k machine did 90 million DES/second; DESCHALL did 600 trillion keys / day with 14000 machines, so that is almost half a million per second; so at best that is 500 seconds IF you could find the 2^28 million keys with the same beginning 64 bit chunk; not gonna happen in EQ, our plaintext changes faster than this). Another good method is Differential Cryptanalsys, but it also requires static plaintext or static key. Man-in-the-middle requires double DES (or quad or any even) so we can't expect much luck using this attack. Two new interesting attacks involve looking at the POWER (electrical usage like SPA and DPA; mostly interesting to Chips which perform DES you can monitor by using a voltmeter, not useful for a PC because the PC may be [will be] doing tasks other than DES) and timing attacks (how long does the encryption take? not useful for us, because we can not clock the time the decode is taking, too many factors and no way to narrow it down.) Another good attack is the birthday paradox. Gather 64 TB of 8 byte plaintext/ciphertext pairs and you have a 40 percent chance to locate the IV which will open up the DES CBC to better linear cryptoanalsis because you can have many more CBC blocks to analyze. Still not likely for us EQ-ers. In short DES is secure (as long as you don't have half a million to spend and 30 minutes or so to decode) for our purposes.

Also, some comments on previous posts:

1) Blaze, the man in the middle attack you suggest may be possible. Your system would have to be router. The router would have to intercept and not route the E541 packets coming from VI, modify them to add it's public key (the router's) and send the modified packet to the EQ station which replies with it's session key. The router decodes this key and inserts it into the packet in the spot the client inserted it's key and sends the original key back to VI (who believes this came from the client). Issues with this are: we don't fully understand every bit in the packet, so if they change something we may not be able to prevent them from specifically detecting that we exist. Also, detecting the packets would be hard, you would need a diverting firewall which would (via code and not filters) look into eq packets like showeq does to determine where in the packet the opcode is located (since it moves around based on flags like ARQ, ARS, Seq, etc inside the EQ packets). I do think it would be doable. Would I run it tho? no, too detectable.
2) Whoever said mimic the session key code from the client. We can't unless VI were insane on key choice (like current time).
3) Baelang 56 bit max. US export prohibited above 40 bits until 9/2001. It is now capped at 128 bits, so DES (at 56 bits) is well within the limit. Note I believe there are allowances for 512 or 640 bit key exchanges since this is a key exchange and not encryption (the clients data isn't encrypted with 512 bit, just the key).
4) Complex keys take time to decode, no DES is rather fast (500,000 per second on semi beefy hardware with DES software). The primary reason for 32 bit was probably ("it fits nice in the 40 bit cap" and "is easy to program compared to the bit shifting work needed to use bits 33 to 40 of our limit".)
5) Blaze, your session key histogram is actually VERY interesting. If we could locate enough of these and they are significantly clustered, then we could in fact brute for it with sufficient cpu and disk (tera bytes and cpu hours). If it is really bad (one of the systems on there had something like 1000 keys total), we could brute on low end hardware. To do this we would need a great many keys posted or acquired from ram of the eqgame.exe process.

Interesting forward thinking:
If we assume we can not brute or acquire the key, we have options:
a) Run a process snooper.exe to read client memory and feed this to showeq.
b) Run a kernel mode device driver to read client memory (less detectable).
c) Buy a hardware breakpoint test device (PCI card) and remotely snoop the memory with PCI based DMA.

What other options do we have?

Fester

[throx]

Run a process snooper. Call it magelo.exe (or whatever the magelo client is called).

Yeah, I know. It goes against the entire premise of SEQ being undetectable.

Is it confirmed that EQ is now using single DES?

[Blaze]

Here is my idea on how a man in the middle attack could work.

1) Make a proxy server that does little more then just hand off packets to sony. Have the clients connect to it, and just forward the data.

2) Since we can find out the public key, and we pretty much know how they encrypt stuff, we could generate our own session key , encrypt it, and send it off to the server, and write it somewhere that SEQ could access it.

The problem with the proxy idea is that the IP the EQ Client says it's connected to would be different then verants IP which would be could be detected.

Another solution would be an IP Table module, so as long as the SEQ machine was your router/gateway it could modify the session packet in that way. We could even use the exact same session key generation code as the EQ Client uses right now, so then nothing would look wrong.

The only bad thing is it moves SEQ from passive to active in it's attacks, but as a iptables module, it should be pretty transparent.

As for the histogram, I could whip up a php script to allow people to input the keys and generate a graph if someone made an app to pull the keys out of eqgame.


BTW - For the record, I haven't played EQ for about 2 years now, and I don't have an account. My interest in this is more of a scientific one then a I want to use SEQ one.

[Mongo222]

[QUOTE]Originally posted by Blaze
[
The problem with the proxy idea is that the IP the EQ Client says it's connected to would be different then verants IP which would be could be detected.


This could be handled by modifing the header in packets coming out out of the proxy as well. Might required a dedicated NIC in the proxy to handle it, but it could be done.

[Spook]

It's been a long time since I posted (old SourceForge boards), but wanted to offer my support. The support offered is cpu time on my machines, if needed for a parallel attack research. I have some old friends that might be willing to analyze data if it is prepared first (their access is cpu cycles = money). If it comes to this, I'm sure many will contribute as well....but I don't think it would be feasible for long term use.

Unless there is an obvious flaw in their design (as is being discussed, e.g. unlike ssh), brute force is out as a method. I agree with two solution options: the middle-man and the local memory parser. In keeping with the passive philosophy of SEQ, the SEQ host being the subnet router leaves us the middle-man solution theory.

GL

[MisterSpock]

I'm not going to fall in to the gloom and doom camp just yet. I was there when VI implemented encryption the first time around. For those that don't remember those times, there were plenty of posts to the effect "showEQ is done as we know it."

We're still figuring out what Sony has done. I think it is a bit premature to assume gloom and doom.

I agree, though, that simply having the client is not sufficient to start doing a victory dance. However, it remains true that *many* cryptographic systems (especially those that rely on PKI-style exchanges) live and die based on the protection of the private key. They are designed to prevent an intermediary interceptor from decrypting the message before the data loses its timeliness.

I still claim that we have an inherant advantage in this case. We have the tool that performs half of the PKI exchange, holds a private key AND the session key, AND performs the decryption. Additionally, we know what the message should be saying.

I also tend to give a little more weight to the possibility of differential cryptanalysis in this case. We may be able to determine, mathematically, some weaknesses in the algorithm.

Either way, I'm certainly not throwing in any towels yet!

[DrHack]

I seriously don't think Verant would use any known encryption schemes that could lead to government involvment (DES) as this would make it more difficult to maintain to people in other parts of the world. I do think the RSA schemes of server/client key creation sound possible as I'm seeing traffic that relates to such an event. As with all encryption schemes the better the encryption the more CPU/MEMORY and since this game attempts to maintain a lower requirement it helps the situation.

[throx]

Spock: The private key never leaves the EQ servers. That's the whole point of using PKI to do the key exchange. All you have on the client is the generated session key. Remember also that the server's public/private key pair can be regenerated at any time and at 512 bits they require a ridiculously long time to brute force.

DrHack: DES doesn't mandate or risk any government interference. I'm still waiting for someone to definitively say they are using it though. In any case, a "trusted" symmetric encryption mechanism is all that's required to make our individual cryptanalysis effort worthless. DES, RC5, Blowfish, AES, whatever. The only real possibility is the key generator on the client is susceptible to attack.

As has been said before, any trusted 64 bit scheme uses negligible CPU and RAM. It's *not* a complex process and can be done very, very quickly - in fact so fast that you wouldn't even notice the CPU hit. Let me repeat it again just for those who missed it: Encryption is *not* a CPU/RAM intensive process.

However, throwing in the towel is silly. As a scientific exercise (which is all it is for me), SEQ's decryption is very very interesting.

I actually applaud the author of the current (broken) libeq.a. The attack is very elegant and a classic demonstration of why you never ever let a programmer write their own encryption mechanism instead of using a trusted and "proven" method.

[baelang]

Originally posted by throx
Couple of cute fallacies here:

i) DES-56 (or some other exportable encryption) is easy to crack. Wrong. It will take you many days of CPU time to crack a single zone key by brute force if they were using DES. Most people don't want to sit in a zone for 48+ hours before the mobs come up.

I just ment maybe it is a 56 bit key instead of a 64 bit key.

But if the cap was raised to 128 and exceptions for PKI, well that answers my question.

[Blaze]

Since it seems like the old decryption code is nolonger usefull, I would love to see something written about how EQ used to do it's encryption, and how it was broken. I love reading stories about things like that.

[MisterSpock]

Throx,

I know that a private key never crosses the wire. That is what makes it private. :)

My point wasn't that the private key is available via the wire. My point was that it is available in the EQ memory space when the program runs.

For a Public-Key / Private-Key system to work when exchanging a session key, the client must be able to decrypt the key. With that said, the session key could NOT be encrypted with the server's PRIVATE key, because only the server's PUBLIC key would be able to open (decrypt) the message. By nature, though, the public key is exactly that -- public. Anyone can get this key (including SEQ via sniffing).

The session key must be generated at the server and encrypted with the CLIENT'S public key. Again, this key is a widely known value and can be sniffed. But, due to the asymmetric nature of the encryption (that is, Dk <> Ek), this key is not useful. The only key that can open this message is the Client's PRIVATE key. This key doesn't cross the wire.

If the Asymmetric encryption is well written, the mathematical relationship between the key pairs will be complex -- ie, it is "hard" to derive Dk from Ek, etc. If there are mathematical weaknesses in the methodology, this is potentially exploitable.

However, I still think the smaller, symmetric session key is a more solvable problem. I suspect that if the prevailing theory on the encryption is correct, we may have to learn about the encryption by ripping the session key out of memory (repeatedly) and identify any weaknesses in the algorithm, and potential shortcuts in the decrypting process.

The keyspace is 32bits longer, which all but eliminates a brute force attack on the session key. However, certain encryption methodologies create the side effect of reducing the overall combinations that need to be tested. Others have weak keys and similar undesirable side effects.

Until the true nature of this encryption is definitively known, we really don't know how tough this nut is to crack...

[Blaze]

from what I gathered above, the client generates the session key, and encrypt's it with the servers public key, and sends it back to the server, not the other way around.

[DrHack]

Throx: yes, but isnt there a requirement to have it say on the box...This product contains encryption due to certain restrictions...for example no encryption what so ever can be taken to France last I recall (this may have changed the last 2 yrs). So if we just all learn french...we can use the completely unencrypted version.

[JackOfAll]

Yeah, the public/private key thing works as long as you keep the private key...private.

I wonder if there's some telltale signature that could be used to suck the private key out of the client. Then you could decode the session key. Once you have this, the session security is breached.

Heck, I'm sure that they figured this would at least take a few days or weeks before it was figured out and put some balance back into the game for the time being.

The most powerful computer in the world is the multiprocessor known as SourceForge.
I love it.

[MisterSpock]

Blaze,

Yes -- generating the key at the client works, too, as long as it is sent with the server's public key.

Either way, though, the session key is in the memory space of EQGAME.EXE, which, when examined carefully, should provide significant insight into the operation of the scheme.

[Ratt]

I should have been more specific... When I say the Achille's heal of Verant is the fact that we have unrestricted access to the client, I was referring to a worst case doom and gloom scenario -> SEQ requires a memory leech on the Client machine.

Does that effectively break SEQ as a passive device? Yes... but the end result is that SEQ can still be used just as it is now, but with caveats.

My point was, they can never truely disabled SEQ, even if the risks of running it increase.

Although, there are ways around even that, but 99.9% of you would not like the solution offered... and I suspect, if that is the final solution for SEQ, there will be a lot of stupid people using the SAME memory leech, leading Verant to scan for it, leading to your account being banned.

But, all is not lost yet ... some very interesting things have cropped up with the new scheme. The real brains behind the operation are slaving away in the back room as we speak... I throw them raw meat every now and then when they fights get out of hand... keep them hungry, but not too hungry, that's my motto.

[Mongo222]

JackofAllTrades: I think you are falling to understand the nature of PKI Encryption.

Let me explain what EQ does with it's keys as I've been able to gather from the expoerts here.

The eq client does two forms of encryption.

The first form is called Public Key Encryption. This method of encrypt has two keys associated with it. A public one, and a private one. The Public Key is used to encrytp the data, and the Private Key is used to unencrypt the data. With a large enough key it is virtually impossible to derive the Private Key from the Public Key. It appears that Everquest may be useing a key as large as 640 bits. Which means that all the computing power on the planet would not be enough to brute force test all the key combinations in a timely fashion to find the right Private Key. This type of Encrypt is rather slow, and uses a lot of CPU time. It's not a good match for sending all the encrypted data to the client because of this. So it is only used once... every time you zone.


When you zone The client generates a session key, which is now a 64 bit key encryption system. This is not a PKI type system.
There is now Public Key, and Private Key... The same Key is used for both. This type of encryption is very easy for the computer to calculate, and it perfect for all the ecrypted data that is normally sent back and forth. That's what it is used for.


The client encrypts the generated session key using the Public Key in the above method. Then sends the encrypted session key to the server. Where the server uses the Private Key to unencrypt the session key.

Now the server, and the client know the session key, and showeq does not...because seq doesn't have the Private Key and can't decrypt the session key from the packets it see. It can't get the Private key from those packets, becaue it was never sent back and forth over the net.



Having said all that... I think the hard core corders have hinted that they have come up with a way to eliminate a lot of the Public Key/ Private Key cominations. Either that or they have emlinated a lot of the Session Key cominations, maybe making it possible to find the Keys in a timely manor. This type stuff is DEEP crypto-analyse, and works on the idea that the data they are encrypting is realitivly repeatative in nature, and there for sort of creates a finger print in the kay space used.

[Mongo222]

Ratt:

My personal view on wither to pull keys client side form memory.... (It's just a vote.)

If the hinted at break through is going to take a time period messured in a few weeks, or less, than I think I can handle that. :)


But if it's going to take a few months.... I'd like that option to get the keys client side.

I have a lot of faith that the dev team can pull this off. I've done a lot stuff in the DSS television world... There is ALWAYS a way. :)

[Ratt]

We could take the Echostar hacking approach... which isn't a bad idea as a fallback for encryption changes anyway, we already effecitvely have the infrastructure for this (gm on the irc channel).

[darkangelx]

dumb question:

Even if we are running a program that shows up on the task list, what gives them the right to scan our computers? To me that would be somewhat Illegal. Scanning "thier files" and "their directory" I understand. Wouldn't they risk a lawsuit for scanning things they have no business scanning? Or does the EULA state : "by clicking yes you give us permission to scan your computer's hard drive, memory or both for anything that we might find against said EULA and ban your account for etc"

If this is true why do they allow EQW to run it is 100% obvious it is running in the tast list? Why not ban all those accounts that are using EQW?

[ThePowerTool]

I haven't posted in quite some time because I haven't had a lot to offer. Perhaps someone may remember me from HackersQuest.

This is getting a bit off-topic, but a valid question. Microsoft tried to scan computers for data and found themselves subject to a huge class-action law suit. They had to completely back off their stance on collecting data.

I thought I heard EQ going through similar problems. I'm sure there are a number of items they would like to collect from client systems. I believe they quickly backed off, as did Microsoft, as the result of a class-action law suit or a threatened class-action law suit.

If they could test for apps in memory, Xylobot would be out of business.

I don't think putting a small piece of code on the client would be a problem, but don't take my word for it.

[darkangelx]

Actually I felt it was quite on topic since Ratt made mention to the fact that they could scan our memeory and task lists etc if the progject went that direction. Which is the reason I ask that question. I have read the EULA and learned the following:

Seems *if* and only *if* you request technical support you give them the right to scan your computer for such support and debugging as stated in the EULA. Therefore any scan done to your computer by SOE without your express written consent would be deemed as a "hack" and or "attack" by a 3rd party on your computer and the proper authorties should be notified. And of course if they were to do this in mass they would be subject to a class action lawsuit.

That is my understanding. I could be wrong, but that is what I believe to be true.

[BOrg]

Ok this is obviously off-topic but....
DrHack has a point. It's still encryption ( even if it doesn't appear to threaten government interests ) and SoE would still have to gain NSA aproval before shipping it over seas. Maybe the easiest fix is to put in a call to the NSA?

[lostinspace]

Well, regarding SOE ability to ban you - they can do that whenever they feel like it. It is only scanning of memory/HDD that is illegal for them, but they never have to admit to that. In other words, they can scan memory, find 'suspected users', log all their in-game talks and ban them. Later they can say they banned them based on info acquired thru their in-game conversations.


So, what we need is memory snooper that is indetectable. My suggestion would be to make program that generate new snooper every time, with different program structure and name, and run it. So you run mySnoopGen.exe, which will generate (either directly, or generating source and using some free compiler) myRandomName_03.exe and start it, and exit from mySnoopGen.exe

This way we will have different program with different structure and different name every time in memory. It is very hard to scan and to be certain that you found such program.

Program that generate can be renamed once, no need to be always renamed - scanning HDD for file name is possible, but scanning HDD for content within files is something noone will do.

BTW, even actuall memory snooper (myRandomName_03.exe) does not need to be renamed/regenerated every time, only once per user. Key problem here is to make generated snooper without any easily identifiable code footprint. Considering that snooper only need to read from memory and send packet out (which most programs do and therefore use similar code), I believe it is possible.

Another option would be to make snooper program such that EQ can not 'scan' its memory. Now, I do not know what exact limitations programs have for reading memory in Win32 that is outside their own ... but if for example normal process can not read memory of kernel process, then we need kernel level snooper ( snooper.sys or snooper.vdx or whatever )

[S.H.E]

Anything that you have running on your PC, you can bet VI has running on their PCs.

Trying to hide a client side leech seems silly. (VI will have disected SHOWEQ and will fully understand how you "Hide" the leech.) If they scan your box *Looking* for a leech they will find it.

As long as a small percentage of players are using SEQ it doesnt seem to have a big impact. I would think that Sony/VI are very tied up with PoP, EQ2 and SWG.

In a week or 2 the encryption will be cracked, POP will not be new anymore and all will be back to normal. Sony gets what they want... no SEQ farming for a few weeks during the release of POP and the SEQ users will have a working "overview" of EQ again.

[darkangelx]

. In other words, they can scan memory, find 'suspected users', log all their in-game talks and ban them. Later they can say they banned them based on info acquired thru their in-game conversations.

Only a complete moron (yes I know they are there) would talk in game about anything related to SEQ. So this hardly seems a reliable way to "find people." We simply need a way to monitor our own memory/connections to detect intrusive 3rd parties that shouldnt be doing snooping us. I assume everything I say or do is logged. I am perioniod what can I say?

[devnul]

Scanning tasks is like looking at your lover's diary and finding out something that hurts your feelings. Not much you can do about it but feel bad.

My position FWLIW is passive is better, but if it's going to be a pain.. screw it.

You've always had the big gun, you just never used it. It's easy enough to hide a leech and having it demonstrated that they cannot possibly win this tussle they may save themselves a lot of developer*hours trying to and SEQ devs some sleep defeating them.

In the long run it may save everyone a lot of work if everyone is painfully aware EQ cannot win this particular battle. They can spend their time more efficiently making a better game. Really, if the game were good enough there would be no need for SEQ.

They spent who knows how much money to defeat SEQ in PoP. (hopefully not much but who knows) Ultimately this is all wasted money. Since they can't help themselves being wasteful, maybe it's up to the SEQ devs to help them realize how wasteful that was.

Also let me take this opportunity to thank all the hard work of the devs. Your Karma overfloweth.

dn

[Gullork]

The solution to running something client side is to mask the name. Mask it so that it shows in the task list as Internet Explorer or Freecell or something. They have to do more than a tasklist scan to find out then, and that'd really be bad for them. :)

[Resiliant]

I really don't like to speculate without any knowledge of what, in fact, the PoP encryption is like. There are many possibilities. There are many many potential solutions. Personally, I'm optomistic. Remember, these are the people that brought us Luclin frame rates.

I, for one, would just like to thank Ratt and the 'people in the back room' for what must already have been hundreds of man-hours analyzing and testing new decryption techniques. You guys have a lot of people pulling for you. If there's any way we all can help you without compromising the effort (any one of us could be VI spies after all) we're all ready willing and able to help if we can. (Gimme a phone number... Pizza's on me :) Need numbers crunched? Need some analysis of machine code? Whatever you guys need, all you have to do is ask. :)

[DontWannaSay]

I think you guys are all missing one fairly obvious point about detecting a process in-memory on the client.

Assuming VI was to do this, they would have to hide the fact from us. They would also have to send the results back over the wire to their servers. So in essense you are sending the results of something you shouldn't be doing right over the very wire that those people happen to be decrypting and watching very carefully. VI could not do this without getting caught.

Also - if we have a process in client memory snooping for encryption anyways, it would be trivial to add code to it to also hook the process listing API calls and passively watch for EQ scanning for it. At that point whether you choose to sue VI for scanning your memory, or simply have windows tell EQ that this process doesn't exist and run-on in silence is up to you.

[Mr Guy]

Hell, tie it in to www.eqwindows.com.


That solve the dumb questions about session tracking too.

[deathinc]

/em stands up.....

Hi, I'm John, and I'm a former EQ user....

** Hi John...


---

Anyways... Some thoughts on preventing SEQ detection if client-side invasive memory snooping is used....

First, you must be running a WinNT derivitive (XP or 2K -- I don't think NT4 has DX8.1 support -- but I might be wrong).

Second, Distribute the source to the sniffer. Yes, you'll need VC++ to compile it (more then likely), but it will give you the chance to change some symbol names to avoid detection.

Third, DON'T GPL the sniffer -- find a license that will allow people to recompile it and distribute it. People should use trusted sources.

Fourth, Find a list of DRIVER NAMES and SYMOOL NAMES for less-then-common hardware. Use those names for the sniffer -- and make it an OS Driver.

Fifth, Because some things would be obvious in the driver (eq_main.dll for example, or whatnot), use string obfuscation. Store strings in the file XORed, and reverse at runtime.

Sixth, change the NTFS permissions on the driver to make it NOT readable by the user account(s) that run EQ.

Seventh, the communications from the EQ to SEQ box should not show up in netstat (or EQ can see it too). UDP would be appropriate, but not binding to a socket to receive (EQ can see it). Also, disguising it like an EQ packet might not be such a bad idea. (Network code in the client would need to be reviewed to see what UDP they listen/monitor for). Also, using various port numbers across snoopers would be prudent.

Lastly, expect some serious countermeasures from VI.

VI will be able to scan driver lists, and determine some function names/calls from the OS. That's all without doing too much legwork, or possibly violating the ToS/EULA they have now, or privacy laws.

They can't go scanning the HD (outside their directory) without modifying their ToS/EULA from where is is now.

By applying some simple protections you can avoid easy and obvious detection....

[rizwank]

after talking directly with a lot of the devs in the IRC channel and reading these posts, I feel a lot dumber than I did before...
lol

Anyhow,
can we get some details on the OLD structure and how it was broken? Its arcane information anyhow but would definitely be something worth reading.

[Exo]

The old and the new attacks are pretty much the same I believe. Plain Text attacks finsihed by brute attacks. But I could be wrong.

[smoothielover]

new here but just an few thoughts

does anyone know what state the everquest emulators are at with this? i had a breif look at one from hackersquest. and in the forum i saw ...*added some PoP stuff*

does the emulator still work and couldnt we make it port the informatuion to you so you can locate where to look etc in memory/packets etc?
I can think of a few OLDSTYLE methods for getting access to memory WITHOUT windows ever knowing. TSR files are a good one and there are many ways to trick taskmanager into not reporting stuff to programs.

im assuming we can locate this key and target it using Debug from command line

it may not help all the users but NT/2K/XP users can defiunately be accessed remotely through telnet server and the debug with the retuned values taken as *THE KEY ATM*

i may be completely off the track here but im coming at it from a different angle i think woith telnet and bebug but hey its worth a mentuion.


Smoothielover

* knowledge is the amassment of ideas which we argue over*

[Mr. Suspicious]

does the emulator still work and couldnt we make it port the informatuion to you so you can locate where to look etc in memory/packets etc?


EthernalQuest Emulator and EQCollector (the data collector that collects data from the life servers) has been working with the latest client software since last Wednesday (23rd).

Doubt the collection program would be very helpfull tho. It doesn't decrypt realtime. It scans active memorry (most of it uncrypted) and the bits that still need to be decrypted, it do "afterwards".