A Technical Solution to Cheat Detection from an Engineer

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.

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.

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.

"Ladislav;c-1938032" wrote:
If we cannot trust data sent from cheating device, there will always be a loop hole.

You must have missed something in the description, but this is the precise problem that you solve by redistributing the check to other clients. You can't trust the local client to validate its own battles, it needs to send the battle data to the server, which then randomly distributes validation of the battle to other clients. Client-side detection is a non-starter unless the client is validating OTHER peoples' battles.

It's also likely not against any sort of app store policies: it's a game that already sucks up an incredible amount of battery with the 3d graphics alone, and you only need to be validating battles while the app itself is open/the user is engaged. These battles don't need to be validated quickly or at any particular time, once you catch a cheater 1 time and suspend the account it's months or years before they get back to doing it again on another account at that same level. Simulation calculations take up only a miniscule amount of battery compared to the 3d graphics and display related to the game.

So if I follow this correctly...you are having some random person's phone run battle simulations for other users every single time any user finishes a battle? That seems a million times less practical and efficient than running it server side, not to mention really sketchy. You would also have to send the data on the the gear levels, etc of the team used, since each client is usually synced up to that player's own data.

Also, it's based on the assumption that running an active simulation is the way they detect cheating. I would think there are less computationally intense metrics they could compare the result to.

"crzydroid;c-1938137" wrote:
So if I follow this correctly...you are having some random person's phone run battle simulations for other users every single time any user finishes a battle? .

yes. all of this is done in the background, users totally unaware.

"crzydroid;c-1938137" wrote:
That seems a million times less practical and efficient than running it server side, not to mention really sketchy.

it is much less efficient in terms of net computing power, but it distributes the cost to the clients. currently, the server is little more than a database extension: it just records results from the client, it doesn't really do much in terms of heavy calculations. running simulations on millions of battles however takes extensive processing power, I have to assume the only reason they're not already doing this is because they've already run cost estimates and they're higher than they're willing to absorb. in an ideal world, they would do the sims on the server, but the only reason i can think of not to do that is computing power. cloud resources are expensive, setting up and maintaining in-house servers to do the work would be even more expensive than that. so, decentralize and send it out.

As far as being "really sketchy" goes- it's not even close to as sketchy as some of the current implementations- they literally send usage feedback for every button press, scroll action, character view, etc that you do in the cantina, or at least i'm pretty sure they used to do that. Battle data can relatively easily be sanitized before being pushed to the queue, so unless they're just not using standard security practices with their code there's little to no added risk to the user. I honestly wouldn't be surprised if they were able to determine with a high level of accuracy the risk of developing addiction to the game (or really addiction in general) that a given user has based on metrics on how they use the client.

"crzydroid;c-1938137" wrote:
Also, it's based on the assumption that running an active simulation is the way they detect cheating. I would think there are less computationally intense metrics they could compare the result to.

In terms of detecting long shots- sure there are possibly some metrics they could use, but for everything else the math and mechanics are so complex that any minor modifications to battles that would be close but could be won are easy to slip through. in other words, catching blatant cheaters probably isn't that hard, but somebody looking for that little extra edge in a normally 30% arena match is a bit harder to prove to the point where you're comfortable banning an account.

traditional methods like hashing the client won't work because they don't address the core flaw: there's almost nothing that can be done to completely prevent client side memory tampering, especially since a huge part of the user base is on various builds of Android.

Why couldnt they have the client detect the tampering itself, kind of like a car alarm. Im not a programmer but it sounds easier to just flag when the connection is hijacked or the code is altered (idk how cheats work dont want to) rather than run millions of simulations

"Psycosaltine;c-1938237" wrote:
Why couldnt they have the client detect the tampering itself, kind of like a car alarm. Im not a programmer but it sounds easier to just flag when the connection is hijacked or the code is altered (idk how cheats work dont want to) rather than run millions of simulations

You want to know why they can't do a specific thing to detect cheaters and at the same time don't want to know anything about how the cheating happens? I'm not sure how to answer your inquiry ?‍♂️