7.6 Client Anti-Bot Measures

[cL1CK]

Hello my fellow Tibia fans and haters.

Ill jump straight into the bottom of my question.

What kind of easy and simple anti-bot measures could I do by simply editing the 7.6 client to make bots not be able to be used on it? If we lived in a world where nobody would make a new bot for it if the client was made so that bots do not either recognize it or function properly on it, what would be the exact methods of creating a simple and easy anti-bot 7.6 client? I assume its not too hard but having not that much knowledge I cant seem to grasp what to do and what to NOT do in order to make bots useless on a 7.6 OT servers. Ive done some research and tried things such as changing the version, port, using software protectors and other things but they just didnt do the job and bots still worked.

Anyway, I will instantly bow against the person who helps me and kiss his feet until the skin becomes non-existent and flesh can be seen. That should say how much I'd appreciate all the help.

Thank you in advance to the soon-to-be helpful person.

Laters!

[DarkstaR]

Use IIDKing to inject a dll. In that dll, allocate chunks of memory for different memory locations within Tibia - lets use the battle-list for example. Now, everywhere Tibia references the battle-list address, patch in the address of the memory which you allocated. This throws bots of as they will be reading the memory from the old locations while Tibia is operating on the chunks you've allocated yourself.

[Fire Onix1]

Wow I liked this idea Darkstar.
I don't knew it was possible

It seems to be a little advanced!
Does olly have a function/mod to list all address acess references?

I have a friend that like "Cl1ck", tried to do some things to stop bots on his OT but nothing worked great.
I will tell him about this method.

[Farsa]

There is usually(maybe always) a way to bypass such things. IMO what you should do is try to make the life of someone trying to cheat on ur server harder. I can't say i have experience on this, but things I'd try are:
frequent patching
protocol randomization
different and multiple checksum verifications
and best of all, a custom client, like that one from otclient.info, so people can't simply port their code

[DarkstaR]

There is usually(maybe always) a way to bypass such things. IMO what you should do is try to make the life of someone trying to cheat on ur server harder. I can't say i have experience on this, but things I'd try are:
frequent patching
protocol randomization
different and multiple checksum verifications
and best of all, a custom client, like that one from otclient.info, so people can't simply port their code

Interestingly enough, there's a nice way to accomplish the packet thing. Tibia internal composition functions all call a createPacket() function with a 1-Byte parameter for the packet type. Due to the constant style of PUSH BYTE CALL FUNC, its a trivial task to locate every single call, grab the values being pushed, create a random transformation mapping, and then apply it to the binary. Now you have randomized packet types and an unregenerated list of changes that can be used to fix the server-sided code. In literally less than 25 lines of C++ this can be done.

[cL1CK]

Thank you guys for the great and helpful responses! : )

Farsa and DarkstaR, what both of you said seem very interesting and something rather doable. I didnt quite understand, though, what DarkstaR's methods exactly do so I better do some more research on the matter. What do you guys think, would these things you said be doable for a guy like me whose knowledge isnt at the top level like yours? Good thing would be, though, that on my server the community doesnt consist of people who'd be able to create a bot or get one that functions properly after and IF such above-mentioned changed were made to the client / server.

Once again, thank you for the tips!

[Farsa]

Interestingly enough, there's a nice way to accomplish the packet thing. Tibia internal composition functions all call a createPacket() function with a 1-Byte parameter for the packet type. Due to the constant style of PUSH BYTE CALL FUNC, its a trivial task to locate every single call, grab the values being pushed, create a random transformation mapping, and then apply it to the binary. Now you have randomized packet types and an unregenerated list of changes that can be used to fix the server-sided code. In literally less than 25 lines of C++ this can be done.

agreed, but like i said it makes the life of the average guy using packet.dll much harder. Then he may think, "IMMA SEND CLICKS!!", and things start getting terribly tedious :P

[DarkstaR]

Interestingly enough, there's a nice way to accomplish the packet thing. Tibia internal composition functions all call a createPacket() function with a 1-Byte parameter for the packet type. Due to the constant style of PUSH BYTE CALL FUNC, its a trivial task to locate every single call, grab the values being pushed, create a random transformation mapping, and then apply it to the binary. Now you have randomized packet types and an unregenerated list of changes that can be used to fix the server-sided code. In literally less than 25 lines of C++ this can be done.

agreed, but like i said it makes the life of the average guy using packet.dll much harder. Then he may think, "IMMA SEND CLICKS!!", and things start getting terribly tedious :P

Yeah ahah that was actually my point, just elaborating on how easy it is do to. It's also much harder to reverse, and thats why people need to get with the program and start using Tibias internal composition (which completely circumvents this).


@OP
All of the things I've mentioned are relatively easy to do and are probably a total of~40 lines of code for the injected DLL and ~25 lines of code for the binary patch.

[Sketchy]

Use IIDKing to inject a dll. In that dll, allocate chunks of memory for different memory locations within Tibia - lets use the battle-list for example. Now, everywhere Tibia references the battle-list address, patch in the address of the memory which you allocated. This throws bots of as they will be reading the memory from the old locations while Tibia is operating on the chunks you've allocated yourself.

I must say that is a rather interesting idea, though it is trivial to defeat by itself for the more capable of us

Taking this idea further you could also relocate the code that references the memory as well, and proxy the calls/jumps to it through your own code. You could then potentially encrypt the relocated code whilst its not executing, performance impact it will have must of course be considered here. This would certainly make it more difficult to defeat requiring a decent skill level with assembly, debugging and most importantly having the determination in beating it.

[DarkstaR]

Use IIDKing to inject a dll. In that dll, allocate chunks of memory for different memory locations within Tibia - lets use the battle-list for example. Now, everywhere Tibia references the battle-list address, patch in the address of the memory which you allocated. This throws bots of as they will be reading the memory from the old locations while Tibia is operating on the chunks you've allocated yourself.

I must say that is a rather interesting idea, though it is trivial to defeat by itself for the more capable of us

Taking this idea further you could also relocate the code that references the memory as well, and proxy the calls/jumps to it through your own code. You could then potentially encrypt the relocated code whilst its not executing, performance impact it will have must of course be considered here. This would certainly make it more difficult to defeat requiring a decent skill level with assembly, debugging and most importantly having the determination in beating it.

It's something I used for a Tibia security suite which I never finished. It relocated account and password addresses in memory along with character list, battle list, and login state. I then proofed data to the old addresses making potential hackers think they were scoring the accounts of Bubble and Eternal Oblivion. I never finished the software but the source is somewhere on my old machine.

And yeah, circumvention is as easy as reading the address that Tibia is referencing from a specific location. Like you said, though, this can be made a lot harder. Honestly, making a pseudo-polymorphic version of the Tibia client using some of these methods would be very easy, especially with ASLR enabled clients. There's a very easily discernible region of code that contains their composition functions which are all static. Furthermore, the same applies to their static graphics wrappers like PrintText(). The same with their dat wrapper. Due to the Int3's before and after every function, we can easily grab the chunks from every function in these regions and randomly re-arrange them. We can then use the PE relocation table to identify any relevant address references to fix. We still need to write an assembly parser to find all of the JMP's and Calls to fix, though.