Principles behind SEQ workings

Hi. I'm not a regular poster/lurker here or even an EQ player. Hearing about ShowEQ from some EQ players I know inspired me to do something similar for a networked program I use. After some initial work I came to these forums as research on how to begin a project such as this. I've read much and found it quite useful, but what I think I really need is some benevolent, knowledgeable person who would be willing to exchange a little email with me on the subject and help me understand a few things.

I am not a novice programmer nor someone who needs everything handed to them on a silver platter. I am good at figuring things out, but I am new to disassembly/reverse engineering.

Feel free to flame me as I deserve, I'm not sure how this post will be received, though I tried to compose it as respectfully as I could. I'm sure the answers to some of my questions are posted here somewhere and though I did do a fair bit of searching, it is quite a body of information to dig through.

If any especially helpful person wants my eternal gratitude then please send me email. Here are some of the types of questions I am thinking about:

If the network packets are encrypted, how do you find out what type of encryption was used?
How do you find out how to get a key to decrypt it?
With unencrypted or decrypted data, how do you make sense of the data initially and figure out what different parts of different messages correspond to in the game?

Thanks

Quote:

---

Originally posted by SparkyB
If the network packets are encrypted, how do you find out what type of encryption was used?
How do you find out how to get a key to decrypt it?
With unencrypted or decrypted data, how do you make sense of the data initially and figure out what different parts of different messages correspond to in the game?

Thanks

---

A lot of encryptions are vunerable to man-in-the-middle attacks. If you want to learn more about encryption techniques this url will tell you a lot of what you want.

http://docs.online.bg/PROGRAMMING/cr...yptography.pdf

Correct me if I am wrong but to man-in-middle attack an encryption you need to know perfectly how the encryption scheme works. That and getting in the middle is not always easy, especially now everyone has heard about it.

I think the guy was more asking about how to gather information concerning the encryption scheme, encryption keys etc...

This is not my speciality but I guess all the reverse engineering has been done by looking in the memory. People made threads here explaining how they would check for certain offsets to figure out the key and the encryption scheme.

Actually I believe I was kind of wrong. Even though SEQ does attack from the middle, it isnt a true man in the middle attack. SEQ isnt generating new keys (at least I dont think they are in the current encryption).

I know in the past a brute force attack was used to gain the key. It would try the key against known plain text until it got the right key.

As long as you are able to see the packets coming across from one machine to another machine. Capture the packets and start trying to figure what they are and do.

If sony were to use an encryption that did not have any weaknesses, it would be much harder to decode data like we do. Since you are new here, you obviously don't know much of the history between eq and seq. It is quite extensive, sony/vi started out with very little or no encryption, and as this was "broken" by seq it was strenthened and strenghtened. This kept repeating for years, until finally it was thought they had finally made it unbreakable. But don't forget, the client is in the hands of the enemy.

Seq was adapted to be able to just recieve the "key" which was handed to it from a small windows application that read it from memory. A little while later, a weakness was discovered that re-allowed us to decode.

And that is the very short, very un-informed, very un-technical history ;p

There are much better posts around. It will probably mostly depend on WHAT network traffic it is you are trying to break. I would bet that something based on a current, well established encrtyption will be near impossible to break. I doubt that a "seq" type product could sniff SSL web traffic passivly, nor many other types of encrypted traffic.

Quote:

---

Originally posted by fryfrog
... a weakness was discovered that re-allowed us to decode.

---

Actually it was more like, they abandoned the 64 bit encryption for a simple XOR cycle. This was a whole new type of encryption.

Quote:

---

Originally posted by SparkyB

If the network packets are encrypted, how do you find out what type of encryption was used?

---

Well, you just "know it when you see it." The only way I know to do this is to look at the data and make guesses which you test. There is no formula to determine this, it is simply trial and error. The more experience you have looking at encryption, the more accurate your initial guesses will be. This takes years to do as a hobby and may take months to do as a full time job?

Quote:

---

Originally posted by SparkyB

How do you find out how to get a key to decrypt it?

---

If the key is not available, you can brute force it. If you suspect the key is available (in PC memory for example) and you know the encryption, you can intelligently search for it, or try using all "key sized" chunks of client memory (brute key search in client memory.) If you suspect the key is available but you do not know the encryption, then find the encryption and return. This requires knowledge of encryption as above.

Quote:

---

Originally posted by SparkyB

With unencrypted or decrypted data, how do you make sense of the data initially and figure out what different parts of different messages correspond to in the game?

---

Trial and Error. You also need to be patient and possess a good understanding of data formats (big or little endian; float/int; char) to begin this part. This is actually VERY easy (simple I would say).

There are vast writeups of all three questions in previous posts here and on hundreds of other sites. There is no fast track to understanding these issues and there can be no "real" HOWTO guide to start you out on this road.

Quote:

---

Originally posted by fester
There is no fast track to understanding these issues and there can be no "real" HOWTO guide to start you out on this road.

---

Ok. Thanks a lot. This was very helpful. Your answers were about what I expected, but I guess I'm just not the guy to do what I need to do. I don't have the years to learn enough about encryption (I've taken classes that have covered this subject but I've only been able to grasp the basic concepts, but far from a mastery). I guess I'll just have to find some help with this project if I can.

Thanks a lot.

Quote:

---

Actually it was more like, they abandoned the 64 bit encryption for a simple XOR cycle. This was a whole new type of encryption.

---

Are you saying that after they saw our keysniffer they gave up to establish good encryption for a fast and easy XOR envelop ?

I believe the 64 bit encryption was causing too many problems, so they junked it. Of course, I don't think there was any official word on that topic... since we're "the enemy."

Anything said on why they dropped the 64 bit for the XOR is speculation.

There was not "official" mention of the change.

All we know is they abruptly quit using the 64 bit altogether and started using their "new" XOR style encryption (which was so simple at least 3 people reversed it within 48 hours of introduction; actually putting the pieces together into a working decoder took weeks.)

I do suspect that they did indeed notice the proliferation of the key sniffers and decide there was little gain in maintaining the battle.

Wow, this is exciting :) When I was working on the Ethernalquest project with Ashran 2 years back the only thing that was encrypted was the login packets and the account registration packets. And it wasn't true encryption, it was scrambling using some data tables. Ashran gave me the code to do it but never told me who created the code, I assumed it was him.

The sad thing was that he had an oppositional view towards a large part of comunity wanting to maintain secrecy on everything he discovered until enough of the comunity replicated his work and then he got left behind.

Anyway, they have gone GPL finally, but I haven't tried the latest emulator. I wonder how it's doing against all these encryption changes. (BTW, I'm not skilled enough at reverse engineering to figure that kind of stuff out, but I'm a great engineer/developer)

Kudos to the team for all of their accomplishments Maybe I'll catch up enough on C++ Linux development to contribute myself.

Xith

You speak the truth? They abandoned 64bit encryption for something so weak a dead kitten could break it? I cant recall any time around that ... time that I noticed a big change in anything, stability, usability or anything. I had no idea, makes me wonder. Perhaps they would rather not have people running things that edit memory, as that could lead to more easy to use map programs that just read from memory? Oops, I guess that wasnt it :)