When botters and bot haters meet

[civan]

I haven't been playing eve actively for a while now. Mainly because all my time either goes to rl activities or eve hacking. Either way I fell behind on my eve24 dose... Have a read:

http://www.evenews24.com/2011/09/15/wanted-botting-advisors-eve-news24-to-evangelize-the-good-news-of-quick-isk/

My first thought was "WTF, this is my idea". For those that are not in the know my current project deals with giving power of certain hacks to people who would not normally consider hacking (yes, I'm evil :P). Funnily enough they arrived at the same idea, with opposite aim, the timeless "let's make CCP do something about bots".

What guys at eve24 (understandable, since people who are good with words aren't usually very good with code) don't realise is that CCP can't do much more about bots.

Firstly, everything boils down to money, something CCP has been short on. Their primary method, server side detection, is very poor at catching hackers without causing collateral damage. In practice every single ban has to be verified and implemented by a human, so we can forget about any spectacular action that would require full-time effort from staff. Also each user banned is revenue lost, hence slow-burn and three strikes policy.

So let's look at the second option, one that can potentially work in a fire and brimstone way and not just "look we banned some hackers", which is anti-cheat software.

Since you probably don't know much about anti-cheat clients, I will outline single thing that made Warden, Punkbuster and Cheating Death (discontinued now, sadly) rain fire and death on all hacks - all those pieces of software were written by people who eat ring 0 code for breakfast and top it up with dynamic code decryption triggered by guard pages. In other words nobody who works for CCP :D (To give them credit, those sort of people probably wouldn't be much use at writing a dynamic peer-to-peer server network that makes up eve).

So, the outlook for the future looks like eve hacking community will be at last dragged, kicking and screaming from their over-engineered pixel readers and onto some decent hacks :), while CCP will probably try to bury it's head in the sand with quick fixes until they have to do a couple of blog posts to provide some sort of fig leaf for their cheat detection method. So unless you are desperately clinging to a private hack that you gave out sexual favours for :), the future is bright indeed.

[bigelectron]

Since you probably don't know much about anti-cheat clients, I will outline single thing that made Warden, Punkbuster and Cheating Death (discontinued now, sadly) rain fire and death on all hacks - all those pieces of software were written by people who eat ring 0 code for breakfast and top it up with dynamic code decryption triggered by guard pages. In other words nobody who works for CCP :D (To give them credit, those sort of people probably wouldn't be much use at writing a dynamic peer-to-peer server network that makes up eve).


I actually don't think cheat-detection software would be much good in a technical sense. There's plenty of bots that go by undetected and even back then what stopped Glider wasn't Warden, it was the law suit. As a matter of fact the main reason Blizz won that suit was because Glider was good at bypassing Warden, which makes it a DMCA violation. Cheat detection software might be a good way to go if they want to start suing people though, but I don't think CCP has that kind of money to waste right now.

In any case I agree with your overall statement, I think EVE online cheating is going to evolve into something a lot better that what we've had for the past 6 years or so.

[Carcaradon]

Eve is in life support mode. That's all the reason you need to believe CCP won't spend much effort on anti-cheat, disregarding any technical aspect.

[civan]

@bige

A serious anti-cheat tends to kill free public hacks dead. Of course it is also a classic example of a trusted client problem, so a good bot writer will always have the upper hand. Cheating death was slightly different but even that boiled down to how well you know your technical stuff.

Regarding glider, let's not forget that the guy got sued only because he tried to run it like a legit business (heck he even registered an ltd) in US.

[bigelectron]

@bige

A serious anti-cheat tends to kill free public hacks dead. Of course it is also a classic example of a trusted client problem, so a good bot writer will always have the upper hand. Cheating death was slightly different but even that boiled down to how well you know your technical stuff.

Regarding glider, let's not forget that the guy got sued only because he tried to run it like a legit business (heck he even registered an ltd) in US.

You know whats funny, most people don't know this but Blizzard wasn't the one who sued the Glider guy. The suit began when the guy sued Blizzard for a declaratory judgement that Glider didn't violate Blizz's copyright. Blizz then countersued with DMCA claims and a couple of tort claims.

Even if he didn't try to run a legit business he would have been subject to legal action though.

[civan]

If you can't track down a person, even an army of lawyers won't help, remember Microsoft vs FairUse4WM?

[LulzBot]

Eve in life support ? I dont know, but CCP seems to be bringing in some money. I dont know how much money they are taking out from their wallet for the wages and the servers, but I would tend to believe they have more income than outcome.

And yeah, CCP is like blizzard. They dont want to put money into bot detection simply because they would have to spend money to do so, and they would loose a lot of mining/botting accounts.

Why would they do so ? Those are accounts that otherwise would not be. And as long as they can keep the rest of the community happy, thats ok for them.

[bigelectron]

If you can't track down a person, even an army of lawyers won't help, remember Microsoft vs FairUse4WM?

Didn't the guy who made it get sued?

I just looked it up, I see it was a John Doe suit and they never actually found the guy.

[civan]

Nope, they sued "John Does 1-10 aka viodentia", and that as far as it ever got.

[bigelectron]

Nope, they sued "John Does 1-10 aka viodentia", and that as far as it ever got.

Yeah I just went back and looked it up. I got a feeling these john does and/or viodentia were also outside of the U.S. as well, which always helps.

[Username]

So... at worst CCP pushes people further towards "supper-bots" at best things stay pretty much as is... Somehow I'm not worried. -_-

[LulzBot]

Well, in any case, if you stay with OCR and image detection, and just stay out of injection, you can be pretty safe if you arent looking too suspicious.

But really, I dont see CCP doing anything.

As I said, they would be spending money to loose money ... Which just ends up in a massive lose of money.

Plus botting doesnt really affect other players (well not as much as cheating does in other games for instance)

[civan]

@lulz
Yes, some people think that user input simulation happens by magic, in fact all bots need to tamper with a foreign process.
In case of OCR you are injecting user input, usually through a dll that calls SendInput. Detectability? Even easier than hooking bots, just call GetAsyncKeyState on keystroke to verify that the key is down for every process on the system.
AHK uses global hooks to do its job, slightly better than the simplest case above, detection-wise it is as safe as an unmasked dll loaded into the process space.

[bigelectron]

@lulz
Yes, some people think that user input simulation happens by magic, in fact all bots need to tamper with a foreign process.
In case of OCR you are injecting user input, usually through a dll that calls SendInput. Detectability? Even easier than hooking bots, just call GetAsyncKeyState on keystroke to verify that the key is down for every process on the system.
AHK uses global hooks to do its job, slightly better than the simplest case above, detection-wise it is as safe as an unmasked dll loaded into the process space.

Wouldn't that same method apply to hooking bots? When you inject a call that would require keypresses(like sending text, etc). GetAsyncKeyState would show no key is pressed at all.

[civan]

That's what I tried to say on the last line, but it depends what were you doing. Main feature of being in-process rather than using SetWindowsHookEx is the flexibility. You might not need to invoke input at all, just the action that you require. It also gives you infinite possibilites for hiding yourself - you can hook the GetAsyncKeyState, or even the detection code itself.

[bigelectron]

That's what I tried to say on the last line, but it depends what were you doing. Main feature of being in-process rather than using SetWindowsHookEx is the flexibility. You might not need to invoke input at all, just the action that you require. It also gives you infinite possibilites for hiding yourself - you can hook the GetAsyncKeyState, or even the detection code itself.

I'm confused tbh. If you're going to hook GetAsyncKeyState you could do that at the system level without needing to mess with the process. The flexibility is exactly the reason GetAsyncKeyState would work to detect injected bots the same way as OCR bots by your theory. If you invoke the action itself without invoking input, you still expect that some keys are being pressed if a legit player was doing it and checking GetAsyncKeyState would reveal that no keys are pressed.

[civan]

Yes you are confused :). I'm not sure what you mean by "hooking at system level". Assuming we are talking user-mode code here, then you are probably referring to an API hooking method, which work by messing with the process. Only extra touch of pixie dust in the form of windows message pumps allows for setting a low level keyboard hook without injecting dlls, it would never work with something less abstract like an actual function call.

That said, on a technical side note, I'm talking out of my butt regarding GetAsyncKey & SendInput. Firsty I did not realise that SendInput is actually global rather than process-local, however windows still marks the input as artificially generated, so my point stands really :). Secondly GetAsyncKey actually includes generated keystrokes funnily enough.

So to clear up any confusion, yes, both methods CAN be detected (read: generated input is not less stealthy), my point is that with SendInput you are stuffed with any kind of detection, whereas you can take steps to actively hide yourself if you work from inside out.

[bigelectron]

Yes you are confused :). I'm not sure what you mean by "hooking at system level". Assuming we are talking user-mode code here, then you are probably referring to an API hooking method, which work by messing with the process. Only extra touch of pixie dust in the form of windows message pumps allows for setting a low level keyboard hook without injecting dlls, it would never work with something less abstract like an actual function call.

That said, on a technical side note, I'm talking out of my butt regarding GetAsyncKey & SendInput. Firsty I did not realise that SendInput is actually global rather than process-local, however windows still marks the input as artificially generated, so my point stands really :). Secondly GetAsyncKey actually includes generated keystrokes funnily enough.

So to clear up any confusion, yes, both methods CAN be detected (read: generated input is not less stealthy), my point is that with SendInput you are stuffed with any kind of detection, whereas you can take steps to actively hide yourself if you work from inside out.

That clears it up. As far as at the system level, I am referring to a kernel level hook(rootkit?). I've never done it in windows but I am sure you can alter the output of any win API call if you're in the kernel. Does that make sense, or are you saying that cannot be done and the only way to achieve that would be by injecting with the process?

[civan]

It is the only way to do it in user-mode. Once you are in ring 0 the possibilities are limitless, but so are the pitfalls. Trust me, writing a DLL is A LOT easier.

[bigelectron]

It is the only way to do it in user-mode. Once you are in ring 0 the possibilities are limitless, but so are the pitfalls. Trust me, writing a DLL is A LOT easier.

I know writing a DLL is a lot easier, but I'm talking about the possible. I've done kernel development in linux in different capacities, writing a little module to hook one or two calls isn't really an overwhelmingly difficult proposition.