Alternative to sniffing?

[tbs_os]

Beeing an old school hacker, I've wondered why people are trying to solve the problem this way?

Obviously all the information needed to get the get is within the program (eqgame.exe) itself along with the game information that gets sent from SOE.

So wouldn't the most natural way be to reverse engineer the routines that gets the key and implement them into SEQ?

Since the offset for the key itself is easily found, its easy to find references within the code to it, it will prob only be written to from the routine that sets the key.

Then ofcourse it's also needed to find out what specific information from the packets that routine uses to create the actual key.

I have way to little network experience myself to be able to figure out the last part, people didn't use networking applications much when I "was around", but I am sure I could isolate the routines that does fun stuff to the offset that might be of interest, just using soft-ice (or simillar) and a few hrs.

Would anyone have any use for the code if I did this? And ofcourse, it would be in assembly, so its not the actual C code or whatever they use to write the program.

(Aslong as it aint VB, cause those is a pain to RE :) )

[tbs_os]

After fooling around with the deadlisting approach I found out alot pretty fast.

I am curious how much others know about how the actual key encryption works?

Is it encoded via a public/private system or simillar? If so, I'm pretty sure that the key needed to decrypt the the zonekey is sent to you when you do a "WorldAuthenticate" via connecting to the world server (Logging in your account).

If so both this key, and the actual zonekeys are needed to be intercepted, but the decode routines themselves don't seem to be that big of a deal to get out. (yes, I did find them, atleast I think so :) )

Ofcourse, since its compiled code, there is still much work to do, but won't this be a possibility that is alot better than sniffing in the memory?

Btw, I found no calls to any debug routines, so atleast for now it looks like the code doesn't try to figure out if anyone is poking around in the memory.

And even if it was implemented in the future, those checks should be pretty trivial to "crack", since its easy to find kernal etc calls, if one wants to get rid of it in the future.

[Hitman]

libEQ.a: SEQ's version of the decryption routines found in the client. EQ has had encrypted packets for a long long time. They used to be pretty lame encryption that was trivial to brute force. This was fixed with the release of PoP, but the information in the packets themselves was easy to predict which helped to continue to brute force. Then SoE added compression to the mixed which meant that a full 64 bit key had to be brute forced. All she wrote for a strictly passive SEQ

You can have all the decryption and encryption routines you want. You'd still need to know 3 of the 4 keys in the process in order to decode anything. 2 of these keys are public. The 3rd and 4th are privately held by the server and the client. We have no access to the server, therefore we must pull the key that is RANDOMLY GENERATED by the client from the client's memory. There is no one else it could possibly be seen since it never actually leaves this memory space.

That may be slightly off, but think of it this way: the functions for every open source security software is, by definition, available for everyone to see. Yet they still provide the security they advertise. You can peruse the actual source code all you want, and the packets encrypted by these open source programs won't be any less secure.

You can reverse engineer the client to your heart's content...you'll still need to pull a missing key out of your ass...or, more likely, the memory space of a running client.

[tbs_os]

Originally posted by Hitman

You can have all the decryption and encryption routines you want. You'd still need to know 3 of the 4 keys in the process in order to decode anything. 2 of these keys are public. The 3rd and 4th are privately held by the server and the client. We have no access to the server, therefore we must pull the key that is RANDOMLY GENERATED by the client from the client's memory. There is no one else it could possibly be seen since it never actually leaves this memory space.

You can reverse engineer the client to your heart's content...you'll still need to pull a missing key out of your ass...or, more likely, the memory space of a running client.

Ok, we have 4 keys. 1 is unobtainable since its on SOE servers only, but the rest is obtainable.

2 of them can be get by sniffing packets for them, since they are public.

The last one resides within the client, and no matter how its generated, be it random or whatever, it should still be possible to reproduce the exact same procedure the client does with a bunch of RE along with packetsniffing.

Otherwise there is no way the client would have worked in the first place.


That may be slightly off, but think of it this way: the functions for every open source security software is, by definition, available for everyone to see. Yet they still provide the security they advertise. You can peruse the actual source code all you want, and the packets encrypted by these open source programs won't be any less secure.

The same goes for this.. As long as I know the keys on the client, and have the code to use them, I will be able to decrypt the information.

The usual security works because you have a key that is private and needed to decode the information, but EQ dont use that in the same sence as PGP uses it.

So it should still be possible to RE the code to get all the info needed.

I'm not saying its easy, I'm not saying anyone will actually do it since REing big compiled programs can be a bitch.

I am saying its doable thou, given the time/effort.

I might be wrong, but untill proven otherwise, I'll still think its doable.

[tbs_os]

Oh btw, by taking the real routines from the Client along with the needed info from the packets, brute force will never have to be used.

If I'm not misstaken, this is how the old SEQ worked long ago, but on a much lesser scale ofcourse.

But if this becomes to big a pain, one can always just attach a small routine (to eqgame.exe) that will create a file with the key in it every time you have finished zoning.

Ofcourse, this will have to be fixed every time a new client is out, and it is more like old school hacking, but that way the checks for the key would come within the program, not from an external sniffer.

Another problem with this is that they can just implement a checksum or something and send back to SOE, so that would have to be "cracked" aswell.

[Protector]

It seems like every week one of these posts pops up about how easy it is :)

I guess it's unavoidable, maybe someone should just sticky a FAQ here or something.

[iluvseq]

Originally posted by tbs_os
Oh btw, by taking the real routines from the Client along with the needed info from the packets, brute force will never have to be used.
This would ONLY work if the routines the client uses to generate keys are really really weak. Remember, the client is generating a random key. Unless the random key generation code can be shown to have some sort of pattern, just knowing the code used to generate this random number isn't going to help you actually generate the same number reliably in ShowEQ


But if this becomes to big a pain, one can always just attach a small routine (to eqgame.exe) that will create a file with the key in it every time you have finished zoning.
See the Forum "Key Sniffer Utilities." We've been using this method for nearly two weeks now.

[tbs_os]

Originally posted by Protector
It seems like every week one of these posts pops up about how easy it is :)

I guess it's unavoidable, maybe someone should just sticky a FAQ here or something.

I never said ripping everything from the client was easy, I said that it was doable, that's a huge differance.

But please, write a FAQ that states that if you can't, no one can.

I wonder why I even bother at times...

[high_jeeves]

I wonder why I even bother at times...

So do I, since we get this same post about once a week by somebody who doesnt understand how the process works, and doesnt bother searching to find it out. Once again, here is how the system works:

1) Zone server has a private/public key pair.
2) Client generates a symmetric key.
3) Zone server sends its public key to client.
4) Client encrypts its symmetric key with zone servers public key.
5) Client sends encrypted symmetric key to zone server.
6) Zone server decrypts symmetric key with its private key.
7) Zone server encrypts certain packets with symmetric key.
8) Client decrypts those packets with symmetric key.

The entropy on the key generation is good enough that a predictive method really isnt going to happen. Best case, we can use the entropy to reduce the key space, but as of yet, the results of that have been not-useful (since, unless we can get it to more like 16 bits, it still wont be very brute force-able).

So, unless you have some magic system that can break this encryption scheme (and all the other unbroken PKI systems out there).. the keysniffers are the way to go. People are still working on the problem. They already have all of the relevant information from the client and datastream... none of it is particularly relevant to solving the problem.

--Jeeves

[Cryonic]

We pretty much have the algorithms that EQ uses, the problem is this:

Choose a number between 0 and 1 Billion.

Now I'll ask your neighbor to do the same thing in the same way.

Odds are pretty much in favor that your numbers won't match. This same thing applies to code. Unless there is a statistical anomoly in the key generation routine, then two machines generating a key from the same algorithm should not end up with the same key.

[quackrabbit]

Choose a number between 0 and 1 Billion.
Now I'll ask your neighbor to do the same thing in the same way.More correctly, it is a number between 0 and 18,446,744,073,709,551,616.

[sam]

Originally posted by high_jeeves

4) Client encrypts its symmetric key with zone servers public key.
5) Client sends encrypted symmetric key to zone server.
6) Zone server decrypts symmetric key with its private key.


If I understand it correctly, the piece we are missing is what the server does to generate the public/private key pair... if we can figure enough of this out, we can brute force it.

I have a question though... how hard is it to sniff the server's public key and use it to decrypt the symmetric key when the client sends it back to the server? Maybe this way too difficult or maybe I'm missing something, but thats just the question that pops into my head after reading the quick how-to that high_jeeves wrote.

Along with my question, I have an idea... is there any type of open source distributed computing out there? If so, and we can get the missing key down close enough (not 16 bits, but a little higher) then could we submit a job to the distributed network and have it worked on by the other SEQ computers that have spare cpu cycles? I'm looking at it like we need to have the key generated within a few minutes after zoning or it becomes too slow... once I have my key, I can help someone else get their key, and the next time I zone, I stop helping and start asking for help for my new key. This kinda makes me want to go build an open source distributed computing... I only know java, but if some other java guys would like to give this a shot, let me know, I'd like to have a try at it :)

[Cryonic]

The problem with breaking PKI is the math behind the encryption. There is a very good post on this forum about how exactly PKI works and why it is hard to brute force.

[high_jeeves]

how hard is it to sniff the server's public key and use it to decrypt the symmetric key when the client sends it back to the server


AAAARGGGHH! Please read! Please research! Why is there a public key and a private key? Because the encryption is asymmetric. Something encrypted with the public key is decrypted ONLY with the private key (not with the public key at all). We can stiff the public key. It does exactly 0 for us.



? I'm looking at it like we need to have the key generated within a few minutes after zoning or it becomes too slow..


Well, it takes a few billion years for one computer to do it.. so, if you can shake up a few trillion computers to crack it, we could probably break each key for each user in a few minutes... other than that, its a no go..

As I have said before in other threads.. please do some basic research on topics such as these before posting your ideas/questions.. it is a very complex topic, and if it was easy, there wouldnt be any decent encryption schemes...

--Jeeves

[sam]

To go along with my distributed computing idea I mentioned before, here is something I found which we could maybe use:
http://team.gcu-squad.org/~phir/distrolib.html

The problem is we need to have a server. I was trying to think of a way to keep the server out of the loop and just have a trusted network, but SoE would be able to get into our trusted network just as easilly as we could and would then find all of our ip's to ban us. So it looks like the client server is the only way to go about this. Anyone else got any ideas on this?

[sam]

Originally posted by high_jeeves
Well, it takes a few billion years for one computer to do it.. so, if you can shake up a few trillion computers to crack it, we could probably break each key for each user in a few minutes... other than that, its a no go..



Originally posted by high_jeeves
The entropy on the key generation is good enough that a predictive method really isnt going to happen. Best case, we can use the entropy to reduce the key space, but as of yet, the results of that have been not-useful (since, unless we can get it to more like 16 bits, it still wont be very brute force-able).


By what you say in the second quote, it sounds like they are working on cracking the key partially to be able to brute force the rest of it. If they can get close enough, but still too far away for a single computer to handle, then the distributed idea could work. I wasn't sugesting brute forcing the entire key since that isn't going to work. I was thinking if you can get it down to the point where it takes about an hour or two to crack the key, then the distributed idea would work great since that is about the average time people spend in one zone before they need another key.

[bonkersbobcat]

Assuming you could solve the problem in a distributed fashion you have the problem of building the distributed cracking network.

The nature of cracking the EQ key is an operation that we desire to have done in an anonymous fashion. Advertise that you are breaking the key and you may get banned.

Not advertising that you are trying to break the key requires that you trust all of the machines (and their owners) in the distributed crack network.

Why? Because if you don't trust and know who runs all the machines in the network, what would prevent SOE from putting one of their machines in the distributed network and in addition to helping crack, figuring out who they originally sent they key to and banning you? (Keys are pretty unique to you and a specific zone and a specific time.)

So the problem is building a network big enough to solve the problem consisting of computers you know are safe in a culture that wants to be anonymous.

Edit: grammar

[fred_phart]

Originally posted by quackrabbit
More correctly, it is a number between 0 and 18,446,744,073,709,551,616.


allllllllrightythen... that's alot of tries


So the chances of iterating though the numbers and hitting the right one is pretty much Nill (in a reasonable amount of time that is).


I'd rather not take the chance of getting band for having a sniffer on the client. I'm happy with just the GPS feature of the current ShowEQ.

Is it possible to have the thing search though the keys like it used to do until a key is entered or comes through on a UDP port? This way I can stay passive, happy with a chance of it decoding (granted, a small chance) and when I really need ShowEQ's full functionality I can run a sniffer and take my chances?

Right now, correct me if I’m wrong, ShowEQ doesn’t even bother trying random keys. Could we turn this back on? Even if it manages to decode a zone once in 10 days I normally only need the GPS feature anyway and it would be a nice, though unexpected, bonus.

Fred Phart

[high_jeeves]

Umm.. I guess you missed my post above. Even if every single EQ user was running this, it would still take YEARS to crack the key EVERY TIME YOU ZONED.

--Jeeves

[S_B_R]

I think he's trying to say "Maybe I'll get lucky and get it to decode".

I've found that most people really don't have any concept of very large numbers. In this case the word Luck would be the understatement of all time.

[S_B_R]

Just doing some quick math, you would be ~1000 times more likely to win the PowerBall Lottery jackpot twice, than guessing the EQ key once.

[high_jeeves]

Right now, correct me if I’m wrong, ShowEQ doesn’t even bother trying random keys. Could we turn this back on? Even if it manages to decode a zone once in 10 days I normally only need the GPS feature anyway and it would be a nice, though unexpected, bonus.


You dont seem to get it... Take your 10 days, and turn it into a billion years, then you are fairly accurate. Thats right.. statistically speaking, you will get the guess right 1 out of 18,446,744,073,709,551,616 times. So, if you can check 100 random numbers a second. It will find the key in approx 350,965,450,413 YEARS to find a key. So, as you can see, in random sampling you are probably not going to get an accurate key in your lifetime.

--Jeeves

[mvern]

The first 32 bits of the key are FFFFFFFF almost half the time. If you were to brute the key starting with that and iterating through the 4,294,967,295 possibilities for the 2nd 32 bits, you'd actualy have a decent chance of finding the key for some of the zones once in a while, given enough time. My computer can do around 6 million rc5-64 key checks per second, I think libEQ could manage more then 100 checks with eq's encryption even without much optimization, on a decent computer.

Of course, if they ever fix the key generation, this would be out the window, and on top of that its not a real solution, since it can only really work part of the time, and even then it would still be quite slow.

[scottie]

how hard is it to sniff the server's public key and use it to decrypt the symmetric key when the client sends it back to the server

Doesn't work like that. I won't go into detail about how it does work because it's been covered a number of times.

The only way this would help is if seq intercepted that packet and replaced it. Then seq would be able to decrypt the data stream from the server, but the client would not because it would not have the correct key. Plus, this would clearly not be passive.

[Gjeret]

-
Originally posted by Cryonic
Choose a number between 0 and 1 Billion.
Now I'll ask your neighbor to do the same thing in the same way.


Originally posted by quackrabbit
More correctly, it is a number between 0 and 18,446,744,073,709,551,616.

69?

-Gj

[cryptorad]

First post.. and a noob. Flame away if I need it.. :)

My question.. and thought is.. The server private key is created when? Is it only on every reboot? If that is true.. then can that be leveraged?

Seems likely the private key is not a frequent changing thing. The variable is the people zoning.. not the zone. Of course the insane possibility numbers still apply for a brute force .. but by chipping away and reducing the keyspace with 'knowns' .. it may become doable.


Just a thought.

[VanillaShake]

The private key on the client is what is needed. It has been said here that it is "randomly" generated by the client computer running the EQ game on the fly.

The memory sniffers accomplish the 'theft' of this key by reading the memory on the Windows client PC after the random generation occurs.

There is no way to determine this 64 bit private key by sniffing the wire alone, as SEQ was able to do in the past.

Besides the memory sniffing, there is really no way to predict what private key the client will generate, since it calls a random number generator to create the key. Or is it truly random?

One interesting note, though, is that there is really no true random number generator built into any hardware or software in the computer world. Computers are what is termed, "deterministic" machines; they cannot really do anything randomly.

So, how are random numbers generated when a game needs to roll some dice, or when the cipher program needs to generate a private key?

It calls a psedorandom number generator. This is a program or hardware circuit that contain a very long sequence of random numbers. These numbers have been statistically chosen to appear as random string of numbers. They are not, of course, really random, they are fixed -- a deterministic sequence.

If you take a computer programming 101 class, you might run a little program that rolls a pair of dice a certain number of times. Calling a function like rand() will return the same value every single time, and your program will deterministically generate the same exact sequence of random dice rolls every time you run the program. Thus, you can predict all the dice rolls into infinite iterations, since the psedorandom number generator will always give the same values.

This 'feature' is very handy for debugging game programs, since you can predetermine your random numbers for each test run.

To avoid this in a production game, programmers add code to 'seed' the psedorandom number generator with some variable that will be different every time the progam is executed. A A typical 'seed value' is to call your computer's clock or time() function, and seed() the generator each time it is used with the value of the current clock. Since it is always going to be different, you dice rolling program will generate different results (unless, of course, you reset the computer clock and rerun the program at the precise time it ran in the past).

If there is a way to somehow force EQ to set the seed to its psedorandom number generator to the same value every time the cipher program is run and rand() is called, or even remove the seed() code, then it follows that the private key could be predicted each time it is deterministically (not randomly!) generated.

Doing this is very difficult, perhaps impossible in practice, and would certainly involve hacking the EQ program and perhaps your OS. But this would ensure that the private key is always known, as it would always be the same value.

[SurfAngel]

Would it not be simpler (ha ha) to debug the client process and identify a point after RNG creates the client private key (the one the sniffers are reading now) and immediately overwrite (hmmm, this is getting into hard-hacking the client...) that memory space with a user select key? All before the corresponding public key is generated and send to the server. That way, both the client and seq will always use the exact same key to decode.

If I understand the implementation correctly, each zone is a different service that don't communicate with each others. They might not even be on the same physical computer. There is no way for them to detect the usage of a non-random identical-every-time client public-key, right? Of course, I'm assuming the zone service is encoding and decoding packets.

The good part is that it would eliminate (maybe?) the need to rescan the key after zoning and somehow send the key to seq (file-based or UDP-based).

Of course, this would require tempering with EQ's memory, an inheritly dangerous approach. But if the like of MacroQuest is already doing it . . .

Hmmm...

[edit] fixed some typos

[deathinc]

Originally posted by cryptorad
First post.. and a noob. Flame away if I need it.. :)

My question.. and thought is.. The server private key is created when? Is it only on every reboot? If that is true.. then can that be leveraged?

No flames needed. You bring up an interesting point. Everyone is busy talking about the client side of this equasion. Noone's talking about the server.

(Granted we're still talking of a key space of around 2^(way too fucking many bits) combinations here)

I would be interested to know, how often each zone changes it's pub/private key pair? Once a server reboot? Patch? Never?

If for nothing more then, "humm" value, it's relivance doesn't stretch much further then that as the time it would take to brute force the private part of the key pair would completely mitigate any positive traits.

[LordCrush]

If for nothing more then, "humm" value, it's relivance doesn't stretch much further then that as the time it would take to brute force the private part of the key pair would completely mitigate any positive traits

from *what* brute force ? the private key is *private* and not included in anything on the wire and cannot be reproduced from the public key - thats because its called *a*symetric encryption

[cryptorad]

Well.. I mention for three reasons.

First.. the information I have says that 'several private keys will decrypt messages for a given public key' for most implementations. This reduces the key space by a factor and helps in the required break time.

Second.. there is always a chance you will recover the key earlier then the time it takes to test all possibilities. IE.. 8 percent chance at the 8 percent tested point. For a truly random key.

Third.. I can imagine it is possible to implement a feature of ShowEQ that provided a zone packet for analysis to multiple processors that fed back a yes/no answer only for brute testing of a keyed packet. Of course.. providing the information with the successful 'yes' would be the key to being useful. And if the time frame was significantly below the reboot/recycle time that was acceptable by Verant, then it could be useful. Since they don't want to spawn TOO many Tormax's.. etc.


However.. if I am learning as I go along here.. then I think I now understand the process to be a Public/Private key pair strictly to encrypt a session (symmetrical) key which is what is USED for the communication between server and client. A key encrypted key, so to speak. This would prevent an easy recognition of the correctly decrypted key and invalidate my above point.

There are still ways to attack the above key encrypted key method.. but; the ones I am aware of are hardly considered passive.

[high_jeeves]

Who was it again that had the numbers for how long it took to break DES-56? 4 years? So, even with all of us crunching away on the key (WAY fewer users than were crunching away at a well known algorithm), it took years. And, if we find it, it will take them exactly 1 second to change their keypair...

Also, PLEASE UNDERSTAND WHAT YOU ARE TALKING ABOUT BEFORE YOU STATE FACTS.

The client DOES NOT generate the private key. It generates the shared key. These are totally different things. Please state the facts correctly.

As for the 'seed', it is generated for a fairly high entropy source (as has been mentioned in atleast 20 others threads here on this board). Predictive guessing of the key cannot be done in an even remotely accurate fasion, and even if it could, it would require a MUCH more invasive application than the keysniffers that exist now.

As for any sort of man in the middle attack (modifying entropy, or the key exchange...), they would be able to detect this in a heartbeat without any invasive attacks, and you would be banned.

Also, please read up on the forums, all of these ideas have been discussed atleast 2 or 3 times before on this forum, there is no need to rehash them.

--Jeeves

[cryptorad]

Actually.. the numbers are....

Processors required for DES 56 break...

# encrypt/sec 1yr 1mo 1wk 1dy

1mill 2,300 28,000 120,000 830,000

2mill 1,100 14,000 60,000 420,000

4mill 570 7,000 30,000 210,000

32mill 71 870 3,700 26,000

256mill 9 100 470 3,300



I can't format it pretty but, I already had this data.

[deathinc]

Originally posted by LordCrush


from *what* brute force ? the private key is *private* and not included in anything on the wire and cannot be reproduced from the public key - thats because its called *a*symetric encryption

Pick your comment:

Please leave your high horse at the door...
-or-
No shit Sherlock.

Simple mathematics... For each public key, there exists only one private key, that cannot be deduced from the public key, but that can, however, be tested mathematically with a known cyphertext/cleartext pair.

I asked about the number of times that private/public key *pair* changes... Simply put, I was just curious to know if that keypair is semi-static or completely regenerated upon zone/reboot/patch.

In other words, did VI cover _all_ their bases, no matter how impractical they are to break.

If you want to flame me, at least read the fucking message first.

[MisterSpock]

Death,

One minor point. For each public key, there *should* only be one private key. This is not always the case, however. Various mathematical weak spots will occasionally crop up in asymmetric encryption techniques that lead to key pairs that are weak (produce very little effective encrytion), or that are non-unique (>1 private key works with a given public key).

On most published algorithms, great scrutiny is given to these issues. Testing and debate takes place that often leads to adjustments to the algorithm or the implementation. Many times private algorithms, who's inner workings never see the light of day, lack this "massively parallel cryptanalysis." That doesn't necessarily mean they are weak, it just means they might have weaknesses that a limited design team didn't catch. To some extent, VI's encryption method fell in to this case. Security through obsurity is not security.

Have I given up totally on the idea of passive SEQ? Well, not exactly. I rarely ever totally give up. There are things we do know, and many we do not.
We know or can learn:
* The public key sent from a given zone server
* The algorithm that uses the public key to encrypt the session key
* The session key itself (through keysniffing)
* The algorithm used to decrypt the encrypted packets if you have a valid session key.

We do not know:
* The server's private key (duh -- that's why it is called private)
* How often this key is changed
* The exact decryption method used on the server side
* The true mathematical strength of the algorithm

The challenge is in connecting the two parts together. I think we've safely determined (beyond any doubt) that simply brute-forcing things is not feasible. If it is to be done, it must be done through other means.


At the same time, though, I think there are still some things that could be done to the GPS-mode SEQ. One that I have considered is the ability to manually color and name a spawn. Right-click on the appropriate dot on the screen, manually enter a con color and/or a name. When I get some time, I might look in to the possibility of this programmatically. Right now, I'm still fiddling with the keysniffer side of things.

[supersat]

Although this approach would be difficult to pull off and would require a system to be placed in between your EQ computer and your 'net connection, it seems like it'd be possible to intercept the symmetric key without Verant being able to detect it at all.

Here's how it works:

1. An app intercepts the zone server packet that contains the public key, records that public key, and sends out a new packet to the client with your own public key.

2. The client encrypts the symmetric key with your public key and sends it to the zone server.

3. The app intercepts the encypted symmetric key sent by the client and decrypts it with its own private key.

4. The app re-encrypts the symmetric key with the public key originally sent by the zone server and sends it to the zone server.

Thoughts on this approach?

[perlmonkey]

Ok, there are two topics in your message. I'm going to take the second one first.

I've seen that seq has access to conning information (e.g. the text sent back when I con something and the spawn ID of the mob I'm conning). So, would it not be possible to color mobs when I con them? Also, since the con message comes back with the mob's name, that too could be added to the spawn information, no?

It's perhaps not ideal, but it at least gives you an idea of what mobs you HAVEN'T conned yet, and that's useful info.

There are various other tricks that could be applied heuristically rather than algorithmically. For example, if you see that a spawn only ever moves at walk-speed rather than run speed, that increases the chance of its being an NPC. If you see a spawn appear at a zone boundary, it's probably a PC.

Ok TOPIC TWO: GETTING THE KEY

It's come to my attention that WineX now runs EQ pretty well. Windows is annoying enough to me in the first place that I'd love to be running Linux on my desktop at home, and will probably play EQ through WineX if it works well.

Given that I have source for WineX, I should be able to modify it to act as my key ripper and save the key to an NFS partition for later access by second machine that's running seq. Even better, I could just run EQ in a Wine window and run seq on the same box. EQ has no hope of ever knowing that I'm doing more than running it under WineX, and even that is not trivial or terribly reliable.

Thoughts?

[sam]

It wouldn't be very good encryption if it didnt' at least check if what you are sending back is what it was expecting.

I think the server generates its public key using its private key so that when your client generates its symmetric key and sends it back, its in a format that the server should be able to check on using its private key. Since they keep their private key private, I dont see how this one could work.

If for some reason they are not doing enough key checks along the way, then this could work... they cant be using a very good key system since half the time the first 8 bytes of their keys come out f's. So maybe if its a home grown key system they would be stupid enough to have overlooked this but that doesn't mean they would continue to overlook this in the future and could actually scan for people using this method in the future.

[sam]

Originally posted by perlmonkey
It's come to my attention that WineX now runs EQ pretty well.
Yes, EQ works under wine now but its still not to the level that most will be wanting to swap out their windows boxes for linux. Also, just running eq with wine is like saying, "Hey Verant, I dare you to ban my account!!"

If verant gets pissy about people using little things like macro programs... just think how they'll be pissin after they learn you are running under linux. I would have to say 99% of the home *nix users out there that play EQ also use SEQ, and I bet Verant is thinking the same.

There is a guy in my guild who has been boasting how he runs in linux with winex and I think he's a complete moron because he's taunting verant.

[deathinc]

Originally posted by MisterSpock
Death,

One minor point. For each public key, there *should* only be one private key. This is not always the case, however. Various mathematical weak spots will occasionally crop up in asymmetric encryption techniques that lead to key pairs that are weak (produce very little effective encrytion), or that are non-unique (>1 private key works with a given public key).

On most published algorithms, great scrutiny is given to these issues. ...

I debated the wording on that section of the post. I decided to go with the wording above for one simple reason. VI/SOE programmers aren't complete idiots. I would ASSuME that they used a reasonably reviewed protocol, that they check for weak keys, and adequately test their prime numbers.

While it is technically possible to have >1 key for any given side of a key pair, it is certanly not common, and basing any expectation of weakness on such a theoritical possibility would be unwise.

But yes, you are correct, it is possible, however exceptionally unlikely given a remotely clueful programmer using a relatively common PKI algorithim.

Again, I ask simply to provide a broader view of VI/SOE's encryption decisions. the ole pull 1 thread and, hopefully, watch the blanket unravel....

(Edit - Typos Suck)

[baelang]

Originally posted by sam
I think the server generates its public key using its private key so that when your client generates its symmetric key and sends it back, its in a format that the server should be able to check on using its private key. Since they keep their private key private, I dont see how this one could work.

If for some reason they are not doing enough key checks along the way, then this could work... they cant be using a very good key system since half the time the first 8 bytes of their keys come out f's. So maybe if its a home grown key system they would be stupid enough to have overlooked this but that doesn't mean they would continue to overlook this in the future and could actually scan for people using this method in the future.


first of all, a public key isn't generated from a private key. a public key and private key are generated TOGETHER at the same time. they are two halves of a whole, two prime factors of some very large number. showeq has never tampered with the pki key exchange. that was always secure.

the symetric key is were the weakness was. the symetric key is still weaker that it could be, as evidenced by the fact that most keys are really only 32 bits padded with f. however, even a 32 bit symetric key is strong enough to resist brute force attacks practical time frames. (perhaps we can do it in an hour or two. but what good is decryption an hour after you zone?)

before the big patch, we could break the symetric key because we could predict parts of the cleartext of some packets. Now, the packets are compressed so there is no way to predict the cleartext, so no fast breaking of the symetric key.

[deathinc]

Random thought... as I didn't see it mentioned on the other threads...

Is there any chance the compression routiene may give us an edge by not adequately compressing something, or by creating a predictable pattern?

[high_jeeves]

as I didn't see it mentioned on the other threads...


Look again, its covered more than once...

--Jeeves

[sam]

Originally posted by baelang
Now, the packets are compressed so there is no way to predict the cleartext, so no fast breaking of the symetric key.
From what I have read, the packets are compressed and its hard to uncompress them because we dont know where the compression starts and stops... is this correct? If it is, then what are the chances we may figure that out eventually?

[sam]

Originally posted by high_jeeves
Look again, its covered more than once...

I swear you are the forum nazzi... its like you sit around and do searches on everything and then yell at people who havn't spent a few days doing a search for single post buried down in the darkest spot of the forums.

When I search for something, I give it about 2 or 3 tries and if I havn't found it by then then most others probably wont, so I post my question.

NO POST FOR JOO!!

[Mr. Suspicious]

Originally posted by sam

wob wob wob

[high_jeeves]

I swear you are the forum nazzi... its like you sit around and do searches on everything and then yell at people who havn't spent a few days doing a search for single post buried down in the darkest spot of the forums.


One search for: "compression encryption"

Returned 6 results.

Looking at the FIRST post in each thread will show you that this thread is clearly relevant:

http://seq.sourceforge.net/showthread.php?s=&threadid=2250

How hard was that, really? If you cant find that, then you deserve to be yelled at..

--Jeeves

[S_B_R]

Originally posted by high_jeeves


One search for: "compression encryption"

Returned 6 results.

Looking at the FIRST post in each thread will show you that this thread is clearly relevant:

http://seq.sourceforge.net/showthread.php?s=&threadid=2250

How hard was that, really? If you cant find that, then you deserve to be yelled at..

--Jeeves

Waaaaaaait a minute, You can put more than 1 word in the search box?! Who'da Thunk It....

sorry couldn't resist

[Projenoski]

At first I had resolved to stay out of the posting on this thread because it seemed like a lot of cock waving, and I could see where both sides were coming from (ie, I only recently understood the exact nature of PKI and can see where a lot of the misconceptions are coming from, but I also see why people are getting frustrated answering the same questions over and over again).

But I finally saw something that piqued my interest, and haven't seen a post about the feasability of this option. Can someone post a thought or two on how possible this operation is?


Originally posted by supersat
Although this approach would be difficult to pull off and would require a system to be placed in between your EQ computer and your 'net connection, it seems like it'd be possible to intercept the symmetric key without Verant being able to detect it at all.

Here's how it works:

1. An app intercepts the zone server packet that contains the public key, records that public key, and sends out a new packet to the client with your own public key.

2. The client encrypts the symmetric key with your public key and sends it to the zone server.

3. The app intercepts the encypted symmetric key sent by the client and decrypts it with its own private key.

4. The app re-encrypts the symmetric key with the public key originally sent by the zone server and sends it to the zone server.

Thoughts on this approach?

It maybe completely out of the realm of probability, or it may be easily detected, or some such, but (to me at least) the idea seems to hold some merit. It just seems like it would make you zone slow as hell.

[high_jeeves]

This is called a man-in-the-middle attack. I would prefer to call it the "how-fast-can-i-get-banned-like-a-moron" attack.

Scenario:

Server sends client public key.
We intercept.
We send client our public key.
Client sends us their sym key.
We send server out sym key.
We intercept all data, and reencrypt for client.

Scenario 2: (verant wants to catch us)

Server sends client public key.
We intercept.
We send client our public key.
Client sends us its sym key.
Client sends its sym key again, in a different lookinng packet, or sends back the public key it got in a different packet.
We get busted, because we dont know this until it is too late.

MiM attacks dont work when one of the parties is actively trying to defeat it. It only works well over a heavily standards based protocol, where key exchange doesnt have the possibility of changing.

--Jeeves

[baelang]

Originally posted by high_jeeves
This is called a man-in-the-middle attack. I would prefer to call it the "how-fast-can-i-get-banned-like-a-moron" attack.


Man in the middle attacks were discussed thouroughlly in IRC, and a bit on the boards. basically, the risk of detection is much more than the keysniffer method, and it would be a lot eaiser for sony to defeat a MitM attack with minor changes to their code. So it was ruled out in favor of keysniffing.

[supersat]

Yeah, I considered this possibility almost immediately after I posted the idea. However, I think it'd be possible to fully disect eqgame.exe to determine how it uses that public key and detect any retransmission of it. They could only change this during a patch, so there'll only be a limited number of times when we have to reinvestigate eqgame.exe. However, this puts us in about the same position as using the current key sniffers.

[deathinc]

Originally posted by supersat
Yeah, I considered this possibility almost immediately after I posted the idea. However, I think it'd be possible to fully disect eqgame.exe to determine how it uses that public key and detect any retransmission of it. They could only change this during a patch, so there'll only be a limited number of times when we have to reinvestigate eqgame.exe. However, this puts us in about the same position as using the current key sniffers.

One other thing to think about... While a keysniffer only needs to look at a particaular spot in RAM (and it's other functions to avoid detection, send the key, etc) to enable the decoding of the packets, a man in the middle attack has to pass/parse every EQ packet across the wire, not in a passive, but rather an active fashion.

Simply put: The chances for unexpected consquences / problems are much greater for the man in the middle attack.

[Projenoski]

/sigh

I thought it sounded a bit too good to be true, but I had to ask.

Thanks for clearing up my confusion.