Originally by: Dabo Girl
--------------------------------------------------------------------------------
Alright fellas. I am a PL member, but I'd rather not disclose exactly who I am at this point. PL has developed an internal application known as "The Sphere", which is what MS has been using to 'test' killing botters. I don't have access to the sub-forums to which they are developing this stuff, but someone who did sent me a post that karttoon made the other day with some research on the futher development of the application. I am completely against the creation of eve exploits, so I've decided to release this for you guys to use to help put a stop to this bull****.
Originally by: karttoon
--------------------------------------------------------------------------------
I've found a few ways to improve The Sphere app, but there is still a ton of investigation/work to be done. Injecting the raw IRCD command to join the local channel seems to work 100% of the time using the #local.<system name> channel-set. It appears that issue the app seemed to be running into was that the eve IRCD is developed to be case sensitive for local channels. I'm working on a flat file database list that contains all of the correct cases as placed in the IRCD. If the injection joined the incorrect local channel (which didn't really exist), then the client would disconnect on aggression, causing you to float in space with your **** in your hand. It seems that Monkeys connection issues related to some of his comedy losses were related to the fact he actually didn't join local prior to aggressing on the target. If I can get someone in a covops to roam around and capture the raw packet logs I'll run it through the perl script I wrote to parse the correct system names. At a minimum, we need to do this for all of the eastern and southern systems.
Problem two I looked at is where we are only obtaining a 50% success rate in actually dropping the join channel, variable based on who is testing this. This seems to be due to the fact that the virtual NIC drivers that monkey developed have issued the drop packet command after the packet has already been sent to the server. This is variable by CPU load of the client, network utilization, ping times, and luck. There is no easy way to solve this without completely lagging out the client with a full custom in-line packet inspector. There are some commercial applications that have this functionality for other purposes, and are extremely efficient. Software wise, NOD32 has both built in memory and packet inspection technologies that I think I can tap into to drop entering local. I don't think it will be easy to specify the system, but at a minimum I'm sure I can get it to not join 'any' local channels, where you'd then have to issue the manual injection technique for each system (annoying, but not a huge deal unless you plan to burn around quickly). The second option is to use hardware between your computer and the server, which isn't very practical for anyone. Managing encryption keys for the sessions is also a ton of effort to program. McAfee intrushield hardware (costly unless you get a used unsupported device), or potentially modified snort may be able to do this for us. I'd rather look into this as a last resort since this would either require a virtual machine to be running, adding lag, or additional hardware.
Some irrelevant random points: Toying around I've also discovered ways to join multiple local channels and speak in them remotely, but you randomly get disconnected from the server when doing this. I think it has something to do with CCP's desynch detection code. Private group channels appear to use the +k IRC setting, which means you can't snoop on random channels unless you actually know the channel password. How they've implemented the 'allow' or 'deny' list for the channel is still unknown to me at this point. If I can figure it out, perhaps I can bypass the key requirement with further injections. I'm a bit busy for the next few days doing other things, but I'll keep you guys posted.
