Botting, WPE, AHK and other methods of cheating questions

[Woon]

Hello everyone,
Some of you may know me and some may not, but my name is Nihad. I am the owner of WoonRO. We have been around for some time and we have seen a lot in our days.

It is my experience that the older our server grows the more I realize that we have so much more to learn. Every time we grow and develop there are always new things for us to wrap our minds around. In our quest to keep improving I have come to RMS for a bit of guidance. I have been lurking on these forums for a long time, and making a post every once in a while. So I know there will be some good advice.

The topic of concern:
Botting, WPE, AHK and other methods of cheating

Not real solutions for WoonRO:
Harmony is not a good fit for WoonRO - here is why
We have tried it, I purchased it and we installed it. During the test phase everything worked perfectly, released to the public is created insane amounts of issues. Mainly due to our configuration but also because of the way Harmony works. We felt we had to get our money's worth s we at least used the encryption, only took us 3 months to realize this was also creating issues when people play more than one server, which many players do. I was warned by my players before hand that it will cause serious issues, and they were right, we ended up undoing everything we did with Harmony. I have also seen countless servers fail and die within months of installing Harmony. I'm sure there are servers out there that made it work, but the risk we would be taking is way too big for the reward.

Game Guard
Never worked (I botted on IRO many years ago), Doesn't work, every server/game with it still gets botted/cheated on.

Possible Solutions:
Anti botting scripts
I have seen of many of these and we have tried using 1. Didn't really work so we kinda just forgot about it. We really have no experience with botting scripts and I would like your opinions and advice in this area. How effective are these scripts, what are the consequences and the ease of implementation.

Source editing or skill and item editing for WPE, AHK possibly botting?
I have seen hints of this in the past, I was never able to find anything. This is more of just me wondering about the possibility.

There may be other methods that I am not thinking and I would greatly appreciate your input.

Our current method is the same method that many other servers use. We have police GMs, they hunt down the cheaters and then we ban them. To me this is like trying to fix a gun shot wound by smashing it with a cactus. Players that were potential loyal members of your community are now banned, eventually we have to ban their IP if it happens again. The thing is, if the temptation to cheat wasn't there in the first place, they may have just conformed to the server and be contributions instead of another IP or account on your ban list. At the same time you have other players whining about cheaters in your server, so there is very little positive to this method.

Before some of you say, "there is no such thing as a perfect method, cheaters will always cheat." I'm well aware of that, even the top gaming companies in the world have a hard time dealing with that. But any improvement over my current system will be a benefit.

Please add any comments or other suggestions as well, I hope this becomes a thread for discussion and ideas to bounce around so that we may all benefit from it.

Anyway thanks for reading my super long post. I look forward to your replies.

[Triper]

As you said, there is no perfect solution but I reckon to see some that worked in the past +/- fine at some servers:

Hex edited exe with crc verifications when players log.
Hard-coded server delays.
Hidden server grf and ini files so people can't find what they've to edit to add the "cheats"[soon or later they will be found but can take a while and you can change it if needed or when spotted].

[yC]

Triper got some good advice there.

About the botting script, if botting is an issue with your server sure go for it and test the effect.  Or ask the opinion of your community first obviously.  Sometimes players are bothered with them, I myself can't get the answer right at random times.  Though I wouldn't hate it as it is to serve fairness to the server.  Maybe customize it to the need of your server, such as disable it in mvp maps etc.  If it works the way it should, the time saved from bot catching can be allocated to better use.

[Renard]

Anti botting scripts
I have seen of many of these and we have tried using 1.

Let me guess, it was postet at the eAthena/rAthena Forums, right?
Here's the deal, these scripts can be quiet effective if done right, but the ones posted all over the net, well you also find stuff to make your bot react to them...
So a good AntiBot script is always self written, and never released to the public.

But still, kids with to much spare time will find a way around these someday.

[Variant]

Hex edited exe with crc verifications when players log.

http://rathena.org/board/topic/70841-r16771-client-md5-hash-check/ is relevant to what Triper mentioned.

Regarding bots, I'm not actually too familiar with them. Do they require your servers IP and port? If so, you could just randomly switch around ports around the range of 6900 (of course, after verifying that you aren't using some already used port). Then just send out a new hidden clientinfo however you do it.

I've actually seen servers use BoxedApp (really really expensive, mind you) to hide their clientinfo in there, and then send out a patch with a new 'client' (that is, the same old client with a new clientinfo boxed with it). I'm sure higher level players will figure out how to monitor what port they're sending info too, but it'll stop a large fraction I'm sure.

It all really comes down to how big an issue bots are, and how far you're willing to go to stop them.

[yC]

I'd think hiding the port or clientinfo is not a long term solution.  Maybe it's just me, I think it can be easy to find or can be found easily by monitoring outgoing traffic when running the client.  Plus if the server is large enough, "helpful" people will post the information on bot forums anyway.

I think taking one of the open source anti bot script and change it a bit + add in your own idea will do a lot.

[Sziadan]

A lot of things have already been mentioned here.
But, what Triper and Variant posted regarding the login crc/md5 check is actually pretty good and should be fairly effective if you do some minor changes to it.

Just activating the md5 hash check would probably weed out some of the less experienced botters. If you modify it to not really send the md5 hash but instead sending something else (like some kind of password) then you'd probably weed out most of the botters. GreenBox posted the decompiled code for the CLoginMode::GetClientHash method in that topic that Variant linked to, though his recommendation was to hook it you can do some edits to it without hooking it.

To break that protection they'd have to know how to decompile the exe file (if you change the md5 check that is, otherwise they only have to check the md5 for the client) or if they monitor all the traffic between their client and your server for that package (encrypting the traffic would solve this). From what I've heard, openkore already have the option to send md5 hash, so only activating that option wont do you much good since checking the md5 isn't really that hard :


To further secure your server, using encrypted traffic would help you a lot. At least against botters.
It would also make it harder for those using WPE unless they are just spamming the same package over and over again.

There's really only 2 ways to protect yourself against WPE:
1. Checking the client side (if WpeSpy.dll is hooked to your client or looking for the process in the process list). <- Both of these would require you to either create your own form of hackshield or buy one.
2. Adding some kind of checksum to all the packages, probably harder since you'd have to create some kind of proxy that you hook to the client and force the clients traffic to go via that in order to add your checksum to the packages.

I've never really looked at harmony but I'm guessing it does both of these things?

[Woon]

Thanks so much everyone. Your suggestions will be a lot of help.
We will be adding in some of the prevention methods mentioned here on our server.
Thanks again!

[Thoth]

Hex edited exe with crc verifications when players log.

I recall there was some openkore thingy that was supposed to piggyback the RO client itself when players login. packet encryption seems to generally work since if someone goes through all the effort to decrypt it and shares it with everybody, they do a little patch changing the key and the effort is wasted. it also scrambles any attempt to use wpe.

Hard-coded server delays.

yes. PLEASE. speedhacks also abuse the "dance attack" effect so the serverside attackspeed stuff needs to be adjusted.
as far as I can tell, the biggest issues with harmony were with its backwards anti-speedhack whenever a large number of players would appear on screen. the server stress would go up exponentially. harmony's antispeedhack preserves dance attack, but its just not worth it.

Hidden server grf and ini files so people can't find what they've to edit to add the "cheats"[soon or later they will be found but can take a while and you can change it if needed or when spotted].

this can only stop the noobiest of the noobs, many people will see through this instantly. not sure you should even bother. I was impressed by harmony's grf encryption for custom content.

[Triper]

Hidden server grf and ini files so people can't find what they've to edit to add the "cheats"[soon or later they will be found but can take a while and you can change it if needed or when spotted].

just not worth it.this can only stop the noobiest of the noobs, many people will see through this instantly. not sure you should even bother. I was impressed by harmony's grf encryption for custom content.

It depends on the way it's made. I was told once that you could hex the client to read both things inside a grf with stuff encrypted giving then an hard time to people that want to change them.

[Boreas]

Running Harmony on TalonRO with little to no issues. The problem is not the software, rather the people who try to install it (server owners).

Best tip: install Harmony again and ask Sirius for support, never had any issues there.

[yC]

I cannot recommend re-trying Harmony, it simply isn't for everyone.  Only a handful of servers magically have it working for them, I think the servers that failed to get it to work out-numbered the success cases.  It is a bet on annoying the population (again).

[Woon]

Yeah I think if you can get it to work right it is awesome.
But as yC says its not right for everyone. For us to attempt to mess with it right now would really not be in our best interest. We have decided to do protection from the server side, specifically in the source. This way players will have a hard time bypassing it.

As for new servers starting up, attempting to run Harmony would not be a terrible idea, its worth a try and you don't have much to lose.

[Makiness]

rAthena already has checks to prevent abuse from no-delay .act files as well as server-side delays for all skills you may edit.  *hinthint* With these two checks, you can remove the class act files from hdata.grf and compile harmony not to check for .act file modification =p

http://trac.rathena.org/changeset/15105/rathena

Running Harmony on TalonRO with little to no issues. The problem is not the software, rather the people who try to install it (server owners).
Best tip: install Harmony again and ask Sirius for support, never had any issues there.

This is correct, those who cannot get it to work should ask for help from someone who has configured it before or directly ask Sirius for support.  If configured correctly there should be nothing 'magical' about it; it works.

[Thoth]

rAthena already has checks to prevent abuse from no-delay .act files as well as server-side delays for all skills you may edit.  *hinthint* With these two checks, you can remove the class act files from hdata.grf and compile harmony not to check for .act file modification =p
http://trac.rathena.org/changeset/15105/rathena

oh nice, I wasnt aware anyone did anything to fix this. Epoque doesn't brag enough