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/showthrea...&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.