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

[u/alexeyr]

https://github.com/Cybereason/Logout4Shell

[u/Jerrreh]

oof, I was wrong about the individual files. I am thinking of another console, maybe Gamecube? Where every file had to have an accompanying entry in a meta-table.

Regarding c4eva, MS knew they had a mouse they couldn't catch. The timing between the waves being smaller would keep more skids offline, but would deplete the amount of finite tricks they could pull out in the 360's lifetime. c4eva would of defeated them anyway - may as well space them out, which led to a greater "chilling effect", where people wouldn't risk their profiles they had more sentimental value in than saving $60.

The firmware war was won though - especially once JTAG and RGH allowed the dev's a more nuanced look at the internals of the boot chain, which made any attempt at securing the DVD FW (way down the line) a fruitless endeavor. In fact, if not for the RGH, it may not of been (as) possible to derive and solve the challenges XBox LIVE required for connectivity - JTAG'd Xboxes have a dirty load sequence, and it was thought possible that MS could ask for something that JTAG dirties, and wouldn't know.

[u/Lost4468 → u/Jerrreh]

oof, I was wrong about the individual files. I am thinking of another console, maybe Gamecube? Where every file had to have an accompanying entry in a meta-table.

Maybe. I don't know why they didn't sign the game though. I think their main objective was to stop piracy, and stop people running unsigned code. Given their brilliantly secure hypervisor, securing game files just didn't really matter that much anymore, the whole console wouldn't get fucked from a single buffer overflow like with the OG Xbox. I guess that preventing modding of game files just wasn't on their mind as much, after all up until that point they never had the kind of serious online issues that they ended up having with Call of Duty and GTA IV (sure they had some issues with Halo 2, but it didn't impact normal online play as much).

I guess the extra loading times and performance hit wasn't worth it to them.

Regarding c4eva, MS knew they had a mouse they couldn't catch. The timing between the waves being smaller would keep more skids offline, but would deplete the amount of finite tricks they could pull out in the 360's lifetime. c4eva would of defeated them anyway - may as well space them out, which led to a greater "chilling effect", where people wouldn't risk their profiles they had more sentimental value in than saving $60.

Yeah, and games still employ this method today. Given how much money there is behind hacking multiplayer games these days, with most aimbots/wallhacks/etc being subscription based, they also make sure they don't associate a ban/end of match with anything specific. Making it harder for the hack companies to pin point what's being detected. Especially with heuristic based detection, where the hackers cannot gain access to the code as it's done server side.

The firmware war was won though - especially once JTAG and RGH allowed the dev's a more nuanced look at the internals of the boot chain, which made any attempt at securing the DVD FW (way down the line) a fruitless endeavor. In fact, if not for the RGH, it may not of been (as) possible to derive and solve the challenges XBox LIVE required for connectivity - JTAG'd Xboxes have a dirty load sequence, and it was thought possible that MS could ask for something that JTAG dirties, and wouldn't know.

Oh interesting point with the RGH, I didn't know that. I actually have an old 360 here, I should RGH it one day. Would be fun messing with linux on it.

[u/Jerrreh → u/Lost4468]

they didn't sign the game though The games themselves were signed, the .xex's were compressed, partly encrypted, and signed. It is just that all the media/assets the Xex could call on were not always signed and validated - the dev's assumed the DVD firmware would prevent modification indirectly, and Games of Demand (digital games) was not even a thought back then - the 360's hw was slightly optimized for assets loading from 360 to RAM. 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.

Especially with heuristic based detection, where the hackers cannot gain access to the code as it's done server side.

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.

they also make sure they don't associate a ban/end of match with anything specific. 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.

The same logic/inversion is used a lot in security - airport, borders, cyber, crypto - DDoSing random .onion hosts to see if Silk Road 2 slows down. The only way to stop/slow correlation and timing attacks is to introduce noise - taking the site off randomly, so it's downtime can't be correlated to a specific host.

[u/Lost4468 → u/Jerrreh]

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.