Originally by: Обезьяна-сфере

---

Посмотрите на ваш голем
Сейчас ко мне спиной
в настоящее время возвращается на свое место голем
К сожалению, ваш голем не я
но он был бы мне, если вы перестали использовать леди душистые макросов

---

Originally by: Raivi

---

Originally by: Обезьяна-сфере

---

Посмотрите на ваш голем
Сейчас ко мне спиной
в настоящее время возвращается на свое место голем
К сожалению, ваш голем не я
но он был бы мне, если вы перестали использовать леди душистые макросов

---

---

Originally by: baltec1

---

Originally by: Kitimortoa

---

LOL

Like someone held a gun to his head and screamed at him "MUST EXPLOIT NAO!"

---

Why dont we ask that about the people who are cheating in the first place too?

---

Originally by: Raneru

---

CCP please fix this! By making 0.0 local delayed chat....

---

Originally by: Ellatan Deruimte

---

Terrible youtube video is up: http://www.youtube.com/watch?v=hnhywtqETLo
The quality should improve with time, it's still in the middle of processing.

As you can see, there is only one person in local. Noobship attacks a shuttle and Concord kills him, he still doesn't appear in local. I moved the chat windows, to show that they were not faked with video editing tools.

---

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.

---

Originally by: ewwlooki

---

When I saw it in use, there was no gate, it didnt involve some logoffski while you warp so aparently the ruskies are barking up the wrong tree, but god bless them anyway. the exploit involved altering the eve client, not in game mechanics.

---

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.

---

---

Originally by: baltec1

---

Originally by: Kitimortoa

---

LOL

Like someone held a gun to his head and screamed at him "MUST EXPLOIT NAO!"

---

Why dont we ask that about the people who are cheating in the first place too?

---

Originally by: Dabo Girl

---

*snip*

---

Originally by: Dabo Girl

---

PL has developed an internal application known as "The Sphere", which is what MS has been using to 'test' killing botters.

---

Originally by: Jeremey

---

Have Pandemic Legion used that illegal mod during Alliance Tournament?

---

Originally by: Dmitri Harkonnen

---

Edited by: Dmitri Harkonnen on 21/04/2010 23:03:13

Originally by: Jeremey

---

Have Pandemic Legion used that illegal mod during Alliance Tournament?

---

No - there is simply no room to use these exploits there. Tournament is overwatched by GMs and public, and we saw that they were in local and didn't jump at all.

---

Originally by: Dmitri Harkonnen

---

Edited by: Dmitri Harkonnen on 21/04/2010 23:03:13

Originally by: Jeremey

---

Have Pandemic Legion used that illegal mod during Alliance Tournament?

---

No - there is simply no room to use these exploits there. Tournament is overwatched by GMs and public, and we saw that they were in local and didn't jump at all.

---

Originally by: Rawr Cristina

---

Originally by: Dabo Girl

---

Originally by: karttoon

---

I've found a few ways to improve The Sphere app...I'll keep you guys posted.

---

---

Ban PL
Ban Macros
Remove Local

kthnx [:|

---

Originally by: Kaatje Thaxathinadin

---

I'd just like to say that none of my corp members have used this so my knowledge, but I do have access to the forum section and IRC channel they use to talk about it.

The sphere app is made by an estonian guy who used to be in RA. He got help from kugu with decyphering the app stream and the leaked client source files. Rumors have it a CCP dev left his laptop alone and someone at fanfest put a trojan on it with a USB stick .



22:59 <@xxangelxx> lol
22:59 <@xxangelxx> they will never prove it
22:59 <@xxangelxx> not more exploit than russians do when they do a loggonski
22:59 <@xxangelxx> if i didnt risk my accounts i would do it too
23:05 <WisemanAri> I will not be part of this. bye
23:08 -!- WisemanAri [[email protected]] has quit [QUIT: ]

---

Originally by: Dmitri Harkonnen

---

No - there is simply no room to use these exploits there. Tournament is overwatched by GMs and public, and we saw that they were in local and didn't jump at all.

---

Originally by: Salastil

---

Don't act high and mighty babbling about some form of justice on him or any PL member being banned. We're just going the route that CCP refuses to go. We're going to fix the blight in 0.0 space with or without their assistance. We've petitioned and done everything within mechanics we could possibly do to stymie this problem, we've taken our own skill which is superior to CCP's own developers and come up with solutions to both the lag, fps and botting problem with our custom UI.

---

Originally by: Marlona Sky

---

You mean a goon was behind an exploit? Well, who could have predicted this...

---

Originally by: Salastil

---

Don't act high and mighty babbling about some form of justice on him or any PL member being banned. We're just going the route that CCP refuses to go. We're going to fix the blight in 0.0 space with or without their assistance. We've petitioned and done everything within mechanics we could possibly do to stymie this problem, we've taken our own skill which is superior to CCP's own developers and come up with solutions to both the lag, fps and botting problem with our custom UI.

---

Originally by: Salastil

---

Originally by: Marlona Sky

---

You mean a goon was behind an exploit? Well, who could have predicted this...

---

Evemon was considered an exploit when Six Anari made that too.

---