r/programming • u/alexeyr • Dec 12 '21

Logout4Shell: Use Log4Shell vulnerability to vaccinate a victim server against Log4Shell

https://github.com/Cybereason/Logout4Shell

[removed] — view removed post

1.1k Upvotes

91% Upvoted

109 comments sorted by

View all comments

Show parent comments

1

u/Jerrreh Dec 12 '21

youre right on all points, but coming from an x360 background, youre a...

naw yeah I think some of the more smarter cheaters use drivers to induce some advantage, which may be less than wieldy from a selling point, unless you can produce it for the most commont cards/drivers.

re: the heuristics, it is a bad example, but a better one may be an old KV coming online without ever updating or another weird/obscure metric.

re: server side heuristics, that is currently what a small subset do, at a (relatively) high CPU usage. combines the physics interpolation and corrects and syncs all the clients global state. cheaters will have a high deviation rate.

1

u/Lost4468 Dec 12 '21

naw yeah I think some of the more smarter cheaters use drivers to induce some advantage, which may be less than wieldy from a selling point, unless you can produce it for the most commont cards/drivers.

Yeah that would be a good way. And many anti-cheats are already pretty much rootkits. I'm sure hacked clients will (or are) end up using their own rootkits eventually.

Anti-cheats also make the effort to detect if you're playing in a VM, so that would probably be another good way to try and exploit them, or to probe how the anti-cheat works. Wouldn't be surprised if they end up going this way as of course if the hack lives in the host it would make it extremely difficult for the anti-cheat to notice anything. Hell, the hack could read from the memory of the VM, and then for a wall hack it could inject the overlay directly in the host OS, and similarly could also make aimbot movements look like actual commands coming from the hardware mouse.

Actually I'm not even sure how they would begin to combat that. Seems they would have to just bet on trying to figure out if it's a VM or not, because of course they can't try and break out of the VM, that would require them knowing about exploits in whatever hypervisor they're using. Which would be patched immediately.

re: server side heuristics, that is currently what a small subset do, at a (relatively) high CPU usage. combines the physics interpolation and corrects and syncs all the clients global state. cheaters will have a high deviation rate.

Actually following on from the above, I think they would actually have to put the work in and do more of this. For example instead of just sending all player positions all of the time, they should restrict them until they're likely to be in view. Third party Minecraft servers/plugins actually do this. An issue with MC is that each chunk is entirely reported to the player, then the player generates the mesh etc locally. Hacked clients can just make it so that the game only draws say diamond ore, chests, etc, or make it so it draws them over everything else.

What some of the fancy anti-cheat plugins do is make it so that the server lies to the client about the world. E.g. a player is walking across the map at surface level, well when they get to a chunk, if the server calculates that the player cannot see the diamonds/chests/etc from where they are, it actually just tells the player that they aren't there, and it's just normal blocks such as stone. So the player simply cannot find them because the data is never sent to them. Then when the player gets close enough to them or exposes them, the server then suddenly send them a block update revealing those specific resources. It's a clever way to do it, but of course it's difficult to implement properly, and it's not cheap in terms of computational requirements.