CVS Commit Nov 6, 2002

[fee]

fee (floyd) 11/05/2002
----------------------
+ ShowEQ 4.3.2

+ Bug Fixes
- player corpses will now appear as yellow boxes, not cyan +
- player corpses will now appear at the correct coordinates
- corpses will not have the extra Soandso's corpse's corpse (not working 100% but close)

+ Features and Updates
- ShowEQ can now be configured to listen on a specified port
for a decryption key, expects a udp packet with an 8 byte
payload containing the key in little endian byte order
- updated races.h, thank you Ty
- updated concolors for post 60 players

+ New Maps, Thank you Dok
- Povalor
- Powater
- Potactics
- Bothunder
- Potorment
- Pofire
- Postorms
- Poair




Explanation:

ShowEQ can now sniff a generated key packet sent by your key sniffer. See this example http://seq.sourceforge.net/showthread.php?s=&threadid=2354

The packet sent by you key sniffer should be sent to your Showeq box with a specified port, you will have best results using a destination port that is not in use by any other protocol on your network, I would recomend using ports in the range 10000 to 65000. ShowEQ defaults to port 10000 but can be configured using the Decoder menu. The packet itself MUST be UDP and the first 8 bytes of the payload MUST be the key in little endian byte order.

Showeq has little to no error handling mechanism for these key features at this time. You may encounter crashes and/or lockups if you send key packets at the wrong time. I'll be working to make the key handling sane for the next update.

Enjoy
Fee

[Vertigo1]

Great job guys, only problem is, it seems that the default category's are missing. Thanks

[Amadeus]

My alert list isn't working after this last patch. Is this me, or is something broken?

Thanks!!

[LordCrush]

Thank you Fee

[fee]

i goofed on my xml syntax, a fixed version of seqdef.xml is in cvs now.

fee

[fryfrog]

would it be possible (as a suggestion to augment the new listener) to have showeq send out a packet to the sniffer that would let it know showeq needs a new key? this could allow a program to run that just listens for a key request. then, that script/program could call a keysniffer that only runs for a moment.

[Wishbringer]

@ fryfrog

good idea. would reduce amount of memory requests, so sniffer should be harder to detect.
showeq can see when zoning, so this would be a nice spot to send keyrequest.

had same idea some hours before, looked into code and....
learned that i have more to learn about programming.

[DontWannaSay]

Great work - just have 2 small requests for the next one:

1. As fryfrog said, having SEQ do something to indicate that it needs a new key would be great.

2. 10000 is the default port for webmin. Yes - webmin is TCP and SEQ is UDP, but I think it would be less confusing for people if they didn't share a port number. Even better would be to have 'make install' put a random port number between 10000 and 50000 into the default settings file.

Thanks for all the work.

[fee]

Thank you all for your support and suggestions. At this time I do not want to address the request to make ShowEQ proactively request a key, I think there are far better ways for a key sniffing program to only send a key when it changes.

DWS: The fact that Webmin uses TCP port 10000 has absolutly no barring on showeq, the fact that a keysniffer might send a packet to a destination UDP port 10000 has absolutly no affect on Webmin. I chose 10000 on a whim, I made it configurable, I'm not going to change it. No matter what port you pick for a default somebody somewhere will come up with some application that uses that port...

Thanks for the input.

fee

[fee]

Wanted to give a quick follow-up on some points I didn't mention about the key port feature.

1) be sure you don't pick a port that an EQ server uses, most are below 10000, but I belive a couple are above 10000. (e.g. Login Server uses 15900 thru 15903 for Live servers, not sure about Test... Check your eqhost.txt. So probably not a good idea to choose ports in that range. The reason the port is configurable is only to provide the user a way to make showeq function correctly in the user's network environment.

rant:
The idea that Sony would even consider packet sniffing on your client is FUCKING INSANE. You don't even have to be a lawyer to figure out the implications of this. It would be an invasion of privacy (where a reasonable expectation exists!) beyond comprehension not to mention violate a number of US laws restricting wire tapping and espionage.

2) oh yeah, if you reconfigure the key port, you must zone for it to take effect. The key port will always detect a key when not in a zone. Play with it a bit and the behavior is trivial to understand.



Please don't bother to reply to my little rant. There is absolutly no need to debate it... in this thread ;)

Thanks
Fee

[fryfrog]

is it easier (or the same) for an app running on the windows box to detect a zone (and when it should send a new key) without being detected?

my only real thought was that IF something on the windows (eq) box is scanning for zone changes, then it is more likely to show up somehow. if some passive crap app were just running on the windows box that was waiting for a request to scan memory, maybe it would be less easy to find.

my only thought on having the seq box trigger a packet to request a new key was that seq can passivly see when the client is zoning and anything running on the windows box is visible to eq (in theory). does that make any sense?

also, i don't think this is a new idea and was probably already brought up somewhere.

and a final question... when you said the first 8bytes had to be the key... did you mean you could send as many bytes as you wanted, as long as the first 8 were the key?

[9e02825]

"my only real thought was that IF something on the windows (eq) box is scanning for zone changes..."

The way you put it it sounds like scanning for zone changes is something really complicated, where in reality all it takes is keeping a record of the current key in your sniffer and sending it to SEQ when it changes.

[devnul]

not that it's complicated but that a resident something is more detectable than a something that can be periodically run and exits

putting in a seq request for key would facilitate that in a smoother fashion

dn

[fryfrog]

thats exactly what i meant. if there is something "scanning" for a key every couple seconds, then that is many many times when we are scanning when we don't need to. if you scan every 10 seconds for a new key, and stay in a zone for 30min... thats 180 key scans in 30min vs. 1 keyscan if showeq were requesting it instead.

also, a keyscanner could probably watch the eqlog file for "loading... please wait" or something and only update the keyfile during THAT time. i'm sure there are many ways of doing it, one of which is have seq tell the keysniffer to sniff :)

my entire goal is to have the keysniffer accessing memory as infrequently as possible.

[jax]

Using the perl script below on the windows box:



#!c:\perl\bin\perl.exe
use strict;
use IO::Socket;
my($MAXLEN, $PORTNO, $client, $server);
$MAXLEN = 1024;
$PORTNO = SOME_NUMERIC_PORT_NUMBER;
$server = IO::Socket::INET->new(LocalPort => $PORTNO, Proto => 'tcp', Listen => 1) or die "socket: $@";
print "Awaiting TCP messages on port $PORTNO\n";
while ($client = $server->accept()) {
$client->autoflush(1);
while ( <$client>) {
my $runme = `c:\\somedirectory\\keysnifferfilename.exe`;
$client->send($runme);
}
}
die "recv: $!";


Telnet into the windows box on the port number, and just hit enter whenever you want the key logger to run. You can work this a few ways by modifying the script, this is just one of the many options.

[Mr Guy]

fryfrog, your log does know when you zone right?

Just check for your standard: You have entered type line or Loading Please Wait.

[fryfrog]

thats true, i'm sure that is a much easier way of doing it :)

[SCSwat]

Well Gents.
I have a co-worker who is a web developer. I recently introduced
him to SEQ and he of course fell in love with it.
He also stated that with this current issue of verant/soe encoding
the packets, there may be a way to send the key info to the linux box via internet explorer running an ActiveX app. And in the event that verant/soe got smart/stupid and probed for any apps sending keys/packets elsewhere, all they would see is IE running in the background.

Just an idea.
Flame On.

[Hitman]

Most likely SOE is simply going to check for proggies accessing the memory space containing the key. They'll flag the accounts of those they see as people to watch.

It'll be the same as before. If you act like you're using SEQ, then you'll get busted. If you're a wizard that ALWAYS runs to every rare spawn, you'll get busted. If you brag to your friends (even in tells) that you're badass for using SEQ, you'll get busted.

Otherwise, what does SOE care? Stay clean and play the game right and they aren't gonna bug you.

Just add on a new caveat: If the proggy that accesses the key memory is called "l33tk3ysn1ff3r," you'll probably be busted.

[Mr. Suspicious]

Guys, this is the announcement section, not the discussion section. Please continue the discussion in one of the discussion forums.

[lostinspace]

I already suggested this regarding to file, so same thing about network packet:

- Can you add XORkey= section in seqdef.xml , and just XOR received key (either over network or file) with that value ?

That EXTREMLY simple feature will ensure that even if SOE sniff network or monitor written files during game outside \everquest directory, they would not be sure if it contains their key. Sniffer will XOR EQ key with same value before it send it over.

It is so simple to implement this, that not implementing almost seems like we want to leave SOE easy way to detect sniffer. And to earlier post about 'fucking insane' - it is waay easier and more passive to put net card in promiscuity mode or to monitor written file, than it is to modify kernel level parts of OS to be able to monitor memory reads.

[speedphreak]

As well as basic encrypting of the passed key, I've also added a small number of random (ignored) bytes onto the packet. Makes it look like a key even less to a sniffer, some people might want to add this idea to their code.

[BlueAdept]

Oh yea?

I used a 256 bit asymetric encryption to transfer the key to my linux machine...let them decrypt that :)

Sorry I couldnt resist.

[LordCrush]

Let the paranoia rock :p ;)

[Mr. Suspicious]

Guys, this is the announcement section, not the discussion section. Please continue the discussion in one of the discussion forums.