this post was submitted on 29 Sep 2023
141 points (97.3% liked)
Steam Deck
15057 readers
203 users here now
A place to discuss and support all things Steam Deck.
Replacement for r/steamdeck_linux.
As Lemmy doesn't have flairs yet, you can use these prefixes to indicate what type of post you have made, eg:
[Flair] My post title
The following is a list of suggested flairs:
[Discussion] - General discussion.
[Help] - A request for help or support.
[News] - News about the deck.
[PSA] - Sharing important information.
[Game] - News / info about a game on the deck.
[Update] - An update to a previous post.
[Meta] - Discussion about this community.
Some more Steam Deck specific flairs:
[Boot Screen] - Custom boot screens/videos.
[Selling] - If you are selling your deck.
These are not enforced, but they are encouraged.
Rules:
- Follow the rules of Sopuli
- Posts must be related to the Steam Deck in an obvious way.
- No piracy, there are other communities for that.
- Discussion of emulators are allowed, but no discussion on how to illegally acquire ROMs.
- This is a place of civil discussion, no trolling.
- Have fun.
founded 3 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
I wonder if it's the cost of data processing the inputs on servers. The ongoing costs of having software handle it on the client machine is close to $0.
Though it feels like democratizing the checks could work. Like, everyone within a match together is checked by everyone else in real time since they're all handling the objects moving around anyways.
Though there are probably many good reasons why that doesn't work or is extremely hard to implement consistently. The idea just came to me
Computers are very fast these days, and if the only thing that computer is doing is data processing it seems like it should not be an overwhelming task. It honestly seems like the perfect use case for something like Kafka. Data stripped of its schema and encoded to be the smallest size possible. Encrypt that if necessary, maybe using some kind of session only encryption beginning at client server handshake, based on some value that's generated inside the game binary.
I'm sure it's difficult to engineer, but it shouldn't be impossible. I'd love to understand what the current processes are and why things are failing horribly.
They fail because you can't trust a machine that an adversary has in their physical possession.
Software running on an untrusted computer can have code and memory injected or modified without modifying the executable files. Binary executable files are by necessity readable and someone with enough time can parse through them to fully deobfuscate and figure out what they are doing. Anti-anti-cheat systems basically perform the same code as the anti-cheat but slightly modify the result to hide the cheating. This can be done either by code swapping in the anti-cheat or at a higher level. If the anti-cheat system is looking at which processes are running then have the system feed it the real list of processes with the cheat processes removed... etc.
Trusted computing requires hardware level monitoring, validated certificates, and zero vulnerabilities since the time the certificate was provisioned. In addition, current technology would also require those base certificates to be regularly rotated and device decertified if it didn't rotate in time to prevent physical offline hardware attacks on the certificate data. Even game consoles don't have this level of platform trust and are often physically modified to enable cheating/piracy.
The only successful way to prevent most cheating is to run the simulation entirely server-side and then only send data to each client according to what they should know. Even then you won't be able to prevent assisted cheating like aim-bots or texture replacements.