Game cheats and ECS

I was wondering about game cheats (especially in multiplayer games). Because of the nice data layout in the memory will ECS games be easier to cheat? What technics can be used to prevent memory manipulation or unauthorised reading of some data (like the kind of units the enemy has in RTS)?

 

I‘m no anti cheat expert but I would be surprised if the existing techniques couldn‘t be applied to ECS logic as well. Checksums for instance.

But most importantly: running an authoritative server. Without that, there is only hoping that it will take longer for cheats to appear. Same for anti piracy measures. Without a server it‘s questionable whether any effort put into anti piracy/cheat measures is worth anyone‘s time or money.

 

I actually wonder, since memory using DOTS iand ECS is handled a bit different than OOP, hacking i to maybe more difficult. How more difficult I don't know.
Or if any more difficult at all.

Did anyone tried hack DOTS game yet?

My hypothesis is, DOTS based game will get a bit more time, before hacks become widly popular, than let's say OOP games. Or perhaps it is only matter of the game popularity.

I am not talking about piracy aspects, as here probably nothing changed at all. Still using same core Unity framework.

 

One aspect I can think of to create cheaters life harder is ability to move security critical entities between chunks every frame. i.e. create 100500 tag components and add/remove random one each frame for security critical entities

This will make use of tool like artmoney very problematic

 

I doubt there is anything out there worth hacking it yet.

 

Not exactly an expert, but some thoughts:

• If it's possible to cheat, people will find a way to do it. Making sure that clients aren't allowed to run commands that exceed their authority (or aren't sent the state for objects they don't have visibility/access to) is the only reliable way to avoid cheaters. Security by obscurity only ever gets you so far. But if you wanna layer your defenses...
• I expect that Burst-compiled code is going to be significantly harder to decompile, analyze and modify. I don't think managed implementations are stripped currently (?), but you can probably write a tool that looks for

  [BurstCompile]

  in managed assemblies and strips the IL. (I expect this will be implemented at some point anyway, if only to reduce the build size.)
• Component data is laid out in memory nicely, but not that nicely. It's probably quite an exercise to reverse-engineer the layout of archetypes from scratch working off a memory dump. (And it would take very little effort to mix it up in a patch - maybe you can even automate this?)
  
• Worst case scenario, somebody could put together a "universal debugger" that could view/edit entities/components for any ECS game.
• On the other hand, this works both ways - theoretically, since most data access is centralized, if you customize ECS with anti-cheat measures, they would also automatically apply to the entire game.
• If you really want to implement wacky memory scrambling primitives (eg. like this asset), you can probably get them to run at much better performance than what you'd currently get in Mono. Since the overhead is low (and the rest of your game runs faster too), you can go to town on all kinds of "reencrypt the entire game state on every frame" evil sh*t