It doesn't work that way since the energy is actually server-side.

This is something that has always puzzled me. When you finish a battle and you encounter connection problems, you're given two choices - to retry, or to re-log. Up until today, I'd always just clicked the retry button until it worked. Logically, this makes sense - all it is doing is waiting until the connection becomes available, and then transmitting the information across to the server.

The re-log one didn't make sense to me, and I just sorta assumed it didn't work. Today, I tried using it, and much to my surprise, it actually did accept the results of the battle. This implies that the combat results are actually stored locally and then transmitted. That, to me, seems a massive security vulnerability. If the data is stored locally, it becomes simply a question of brute-forcing it until you can crack through whatever encryption they've put on the contents, and then modifying them to your own tastes.

I'm not going to say I'm an expert on this topic - I am a programmer, and have quite a lot of experience, but this specific area is one I've never dug into too deeply. But from a purely logical perspective, it seems almost trivially easy to exploit. The vast majority of security algorithms operate under the principle of limited attempts. The reason you can't just brute-force guess passwords on a login system, for example, is because most of them prevent you from making more than a handful of guesses before locking you out. But. by extension, the reason why gaining access to a database of user accounts is so damaging is because once you strip away that protection, all you need to do is employ rainbow algorithms or the like, and you have all the time and attempts in the world - you'll eventually break through.

Brute-forcing the encryption would be exceedingly pointless in that scenario. If we assume we have a local client that stores a dataset which it'll send to the server and is vulnerable to manipulation, then no encryption in the world will protect it against anything but the most cursory attack. The client must be able to perform the encryption, which requires knowledge of the algorithm and keys involved, and that knowledge will be stored within the client (or a library the client has access to). All you'd need to do is find a pointer to the function where the client performs the encryption or packages the data to be encrypted or something similar, and then modify the data prior to that. You can try to be tricky and add checksums and obfuscate how the data is generated, or use code-obfuscation tools to make reverse-engineering a bit more difficult (though those I've seen mostly applies to decompiling and not anything in run-time), but it'd just be delaying the inevitable when an attacker has full access to your code and can replicate the entire process. As you say, much like a password hash being compromised, there is no protection left at that point.

What they should be doing, and what most multiplayer games I'm aware of do, is to send what is basically a request for what you'd like to do rather than what has happened. E.g. in an FPS game, the client can tell the server "I would like to fire a bullet along this vector", and the server then checks if the client has ammo, its position, and calculates what a bullet fired from a given position along a given vector would hit, and if at any point something doesn't check out then the request is ignored. At no point can the client tell the server "I shot this guy". What the client sees is irrelevant, any movement or action it takes is merely a request for the server to change what it knows about the client, and the server is always authorative. (I should note that there are some multiplayer games where the client is semi-authorative, but even then the servers tend to perform at least some basic sanity checks. Usually games rely on predictive latency compensation to smooth over what could otherwise be a somewhat jarring experience.)

All of that makes sense for the retry. How do you explain the re-log and re-send part? It must have to store something locally for that to work, no? Especially considering that you can start a fight, have the server go down, then come back online and end the fight, and still have the results count?

I don't know. It's possible that the game is allowed to perform its own calculations if the server is not present and then the server (hopefully) does a sanity check on what it gets, or the server auto-resolves the entire thing for you since most fights are likely pretty predictable anyway. However, they are asking for trouble if they actually have a client-authoritative game. If I was at all concerned about cheating, I'd avoid that at all costs. If running it was computation-heavy, maybe I'd consider outsourcing it to the client out of necessity, but this game is most certainly not in that category.

Rivia Tuner and auto clickers are 100٪ fine to me. Anything to decrease time should be banned 100%

To anyone questioning the difference between the speed engine and auto clicker, is that auto clicker cannot be detected.

While speed engine can be detected by the discrepancy between server timer and client timer and probably by detecting any type of tampering to the value of codes in the client side, auto clicker works outside of the application.

The extreme example is like you hire your brother to click on the game instead of you yourself clicking it, that's what auto clicker does, in phone or in computer, what it does is telling the input sensor on your phone or computer that at coordinate (x,y) on the screen there's a click input, so what it manipulate is your hardware sensor but NOT the game application.

I will tell you that if Plarium can see auto clicker they'll ban it also. But they're saying it's okay, because in reality they can't detect it.

Wow. Necro'd by a bot.

Get out of here bots!!

CLOSED