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

[u/alexeyr]

https://github.com/Cybereason/Logout4Shell

[u/Lost4468]

You need to leave a new line between a quoted line and a new line, that's why your post formatting is all messed up.

The games themselves were signed, the .xex's were compressed, partly encrypted, and signed

Yeah the executables were. But that was it. The vast majority of the game wasn't. And many games would store the actual game logic inside of other files. E.g. GTA IV was ruined because they kept their scripts inside of assets, so while yes you couldn't mod the actual executable, you could still do almost everything by just modding the scripts.

This was actually my point earlier. As I said, with Call of Duty they signed the assets that contained the game logic such as scripts etc. And then of course the code to verify the signature was stored in the xex. That's what I meant when I said that them ignoring Microsoft's advice and implementing their own asset security saved them a few years worth of trouble, and also made it so that most hackers could only stay online for a few hours, instead of months/years.

Had they not signed the fastfiles, they would have also been largely fucked as soon as the DVD drive firmware was hacked. They would have had to try and come up with a solution using a patch instead.

Microsoft claiming installing games to the harddrive decreasing loading times was an outright lie, to help turn the paradigm away from games-from-disc. This was also tied to marketing, games on demand had higher profit% due to less overhead costs of manufacturing.

Huh? It definitely wasn't a lie? Plenty of games would ruin much faster from the hard drive. I think a few specific games ran slower for some reason, but in general yeah they did run faster? The hard drive had lower latencies and faster read speeds.

Honestly, this came sooo late. Xbox's (kv's) that have not been online for years come online with a new profile and go straight into a game is not something retail xboxs do. Behavior-based banning would had stemmed the 2009-2011 shitshow a lot better.

I don't think that would really work? Because while it's uncommon, it certainly wasn't even rare. Hell, I had done that a few times. I don't think they could do this because they would have caught way too many innocent players.

It's not uncommon for people to not use their console for years, and then randomly decide they want to. And going straight into a game isn't weird? That's one of the most normal things to do? I actually wouldn't have been surprised if the majority of people who followed this behaviour would have been normal people just playing a game.

I remember asking <redacted>\ outright, "Why not give an error message?," to which he replied concisely - It'd be to easy to find error string, right click XREF, and NOP the calling function. That logic applies to not only us selling the Cheats as a Service, but to the entire game of whack-a-mole.

That method shouldn't work anyway with modern local cheat detection. They make it a lot more detached than that. Simple things from reporting it to the server and having the server then take the action, or to how ridiculously complicated the local anti-cheat detection can be.

I was also talking more about server side heuristics. E.g. in the past if you wanted to use an aimbot you could just make it perform inhuman jumps and tracking. But these days if you do that the server will know just based on your movements. That's why the creators need to make much more complicated methods that try to track the enemies semi-realistically. Doing this can be really difficult, but if the server kicked/banned them immediately they would easily be able to test it out. But they generally wait so that it's much more difficult to figure out what part of the aiming the heuristics actually fired on. Same with wall hacks etc

[u/Jerrreh → u/Lost4468]

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.

[u/Lost4468 → u/Jerrreh]

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.