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.