From a technical perspective, computational cost of running battle simulations on the servers is a limiting factor in achieving true automated cheat detection in the game. Simulating a battle is magnitudes greater in terms of computing power required than any other server operation, which of course directly relates to non-negligible costs. Politics and economics aside, EA needs a solution that is not prohibitively expensive.So, here it is: peer-to-peer battle data validation: After a battle is complete, put the payload data (random seeds, moves, result) into a queue. Clients who do not opt-out of participation will automatically retrieve the data, run simulations on the user device, send the results back to the server to either raise alarm or mark the request finished.Obviously, the minor technical details need to be hashed out, but from a pure complexity standpoint you achieve reliable (decentralized) validation without significant server side computational overhead. You don't need to go full crypto blockchain on the game to regain the trust of the users, but this would surely go a long way in identifying who is cheating.

I don't think you are using the forums correctly. This is where you come to complain about things and tell CG how horrible they are. . .All jokes aside, thank you for trying to come up with solutions to problems. I truly enjoy this game, and would hate to see it die due to rampant cheating.

This is an interesting idea, but I don't think it's acceptable to opt out. Instead it should require you to pop one combat off the queue to be allowed to add one.It should not take very long or require a lot of data, to transfer the random seed, the data of the involved characters, the moves played and then run the combat and return the result to the server for verification. Flag for inspection if different, and ban accordingly.This is definitely doable.

"Gabe9876543210;c-1936100" wrote:This is an interesting idea, but I don't think it's acceptable to opt out. Instead it should require you to pop one combat off the queue to be allowed to add one.You would at least need a wifi-only setting depending on the overhead. i think overall a lot of people would be more than willing to let this do its thing even if you did leave the option to disable. it does point out the major risk though: having adequate numbers to support the whole thing. worse-case scenario you can scale down or clear part of the queue if it starts getting backed up. but, that's something you can mitigate.

All these methods - no matter if client side, server side or manual, work only for obvious cheating - like you take CUP and beat Malak but if the cheater stays in the boundary of what is possible (even with 1:1000 probability) this system would just replay the data, see that it is possible outcome and validate it as ok.If we cannot trust data sent from cheating device, there will always be a loop hole.Plus I'm not a fan of any processing done on battery powered device which I didn't ask for. It could be quite controversial feature. I wouldn't be surprised if this was against some policies on Apple Store or Google Play.

We're not talking about possibilities here.If I understand correctly, most cheats involve the client sending the wrong combat result to the server. It does not involve manipulating char/ship stats permanently, because I would suspect the server would pick up such a mismatch immediately (it should at least).With a fixed input data (combat participants, set of player moves), the output data is always the same. It's like a transcribed game of chess. So the device is not going to play through the battle several times and determine if it may be possible - it will just go through the fixed algorithm of one set combat and return the result which will always be the same. No animations, no waiting for input, no randomness, just calculating a function, which would not take much processing power per combat. Obviously it takes too much power to do it server side, or they would be doing it already, which is why distributing these small calculation to other random clients may be a viable solution.It is not against any policies if the player accepts it, by using the app. No data would be transferred or handled unless you are actively playing the game. You help verify one combat just before you do your own combat - and you wouldn't even notice it happening.

A Technical Solution to Cheat Detection from an Engineer

25 Replies

kgjs420
6 years ago
"Psycosaltine;c-1938366" wrote:

Could they make it so tampering with the memory forces the client to crash?
not to be rude, but I think you're missing the point of my previous statement, and it has everything to do with your lack of domain knowledge. once you're capable of tampering with the client, you're capable of tampering with any mechanisms in the client, including tamper detection. this has been a part of computer cracking for years. you need to have additional validation- either through a trusted central server or a decentralized network (think bitcoin) in order to establish trust.
psycosaltine
6 years ago
"js4;c-1938372" wrote:
"Psycosaltine;c-1938366" wrote:

Could they make it so tampering with the memory forces the client to crash?
not to be rude, but I think you're missing the point of my previous statement, and it has everything to do with your lack of domain knowledge. once you're capable of tampering with the client, you're capable of tampering with any mechanisms in the client, including tamper detection. this has been a part of computer cracking for years. you need to have additional validation- either through a trusted central server or a decentralized network (think bitcoin) in order to establish trust.

Your right i have no idea about any of this but if one of my hair brained ideas makes someone say "that wont work but maybe this will" its 100% worth looking like an idiot. A different perspective can shine a whole new light on things.
kgjs420
6 years ago
"Psycosaltine;c-1938373" wrote:

Your right i have no idea about any of this but if one of my hair brained ideas makes someone say "that wont work but maybe this will" its 100% worth looking like an ****. A different perspective can shine a whole new light on things.

understood, just don't want you to rack your brain too hard going down the path of client-side detection as the solution when the cheating mostly stems from the client itself being untrusted.
Ladicek82
6 years ago
"js4;c-1938347" wrote:
The problem you described isn't actually a problem. Gather the first random seed from the server, or base any random seeds off of the battle time and validate against it, sending duplicate battle results from old battles will no longer be an option if it even is right now. You don't need server side processing at all, you just need a way to validate a deterministic input in the data.

Interesting. So what you are proposing actually means:

At the start of the battle, server will send RNG seed and battle ID
Player will play, the battle
Player's device will send battle result and information about all involved characters (levels, abilities, gear, mods) and all player's moves to another device
Another device will query RNG seed from the server by providing battle ID
Device will "replay" the battle and compare the result
Device will report to server if result is different

Are RNG implementations on all platforms same?

"js4;c-1938347" wrote:
The actual cheating that has been unearthed recently and has gone undetected has to do with client-side memory tampering. There's not a great way to detect this because anyone able to do this kind of tampering is usually able to tamper with the checks as well, unless perhaps they came up with some clever trickery.

Isn't purpose of obfuscation to make it harder to to tamper with code and purpose of whitebox cryptography to make it harder tampering with client-side memory? I'm not saying they are solution, I'm just saying that tools to make this more robust even on rooted phone should be there. They cost quite lot of money and are very complex to use right but hey, game like this is making $100M+ so money to get the right tool and right devs are there. More money you put into obfuscation and whitebox crypto, more difficult it will be to get around them and you can even mess with that with every release of the game so hackers may find it not worth it if it will be changing every few weeks.

Saying that, there are enough money for them to run their own farm of phones doing just validation. Or simply make system like you are proposing server side - I find it more maintainable ,reliable and easier to make it robust and deliver.

For know it would be enough to start with battle log people are asking for. Not only to detect cheating but also to see what can beat your teams.
cannonfodder_iv
Seasoned Ace
6 years ago
"js4;c-1938367" wrote:
Most of the processing power needed for the game has to do with the graphics- battle simulations are fairly straightforward algebra that can easily be accomplished by any phone capable of running the game in down time.

Which is exactly why you would do it server side. While cloud computing resources have a cost, "expensive" is a purely arbitrary term. Generally, compute and inbound data are relatively inexpensive compared to storage and outbound data. On-demand pricing for an hour of processing on a 96 vCPU EC2 instance is under $6.

The hourly cost of the resources needed to build your massively distributed validation platform is on the order of 20 times that, for a single hour - and building massively distributed platforms is non-trivial. It is certainly much more complicated than building a single, scalable event processor that could perform validation like that described above. If

compute and bandwidth are such a significant concern, you could always introduce some rule filtering to flag questionable matches and fine tune those rules as you learn more. However, I'm inclined to think that executing the rule set is probably more CPU intensive than just running the battle actions through the simulator/validator.

I'd even be willing to bet that if CG made the relevant portions of their battle algorithms available and a pipe to consume battle log messages, they'd have a couple of free solutions in place in short order.

Forum Discussion

A Technical Solution to Cheat Detection from an Engineer

25 Replies

Featured Places

SWGOH General Discussion

Community Highlights

Weekly Shipment Request

Recent Discussions

Executor: No thank you

Squish, yet again

Where do I report cheating.

Terrible to play

Conquest hard?