Sim's Paper Version is Compromised

[KoriJenkins]

MrDavid99 recently (4 hours ago) told me the paper version Sim is running on has been exploited by 2b2t players, who can now see the packets sent by Sim players if they want to, which reveal coordinates. I asked MoWobbler if it were true and he said he had "warned" Yukar on the forums, but I'm not aware of any warning to the playerbase.

Given the fact that MoWobbler felt the need to warn Yukarion, we can probably assume there's some merit to this. Thus, this is a warning. If you're prone to AFKing at your base or even just spending time at it, there's a chance it could be compromised by whoever is doing this.

That being said, your base would also be protected by the BRP if found by such nefarious means, so any actual damages would be reversed (aside from storage).

It's also possible this is a false alarm, and hopefully it is, but it seems better to inform as many people as possible to prevent this from potentially causing problems.

Up to y'all if you wanna play it safe and spend time at lesser bases that don't mean as much, or treat it as a (likely) false alarm.

Edit: Previous edit called this a backdoor, it's more a very powerful exploit than a backdoor.

[4Bilota]

There is an exploit going around right now on 2b2t. It's a module that can detect these packets and gain cords. It's proven to work on 1.16 and that's the reason there was a whitelist earlier to stop any people trying to use it here. There is a fix for it, but it's being reviewed first

[Anthand]

Is this why GSTrading Co keeps asking me to log on?

[Yukar9]

This issue should be mitigated now.

[CarbonKing]

The exploit works by using boat phase(and a few other hacks such as packet cancel) and flying into unloaded chunks. Using a special client you can track loaded chunks. The method used to be on a private client used by the Brownmen but is now being sold by Redstoner https://discord.gg/p5Gs34R <-- shop discord

[Azdin]

Yukar is sim safe from nocom? Here is fit mcs video on it from July 24 a few days after your posts

https://m.youtube.com/watch?v=elqAh3GWRpA

[Yukar9]

Does anybody know the answer to Azdin's question? Or want to summarize the exploit?

[KoriJenkins]

Does anybody know the answer to Azdin's question? Or want to summarize the exploit?

It seems to be difficult to summarize quickly, but this article should explain it fairly well https://2b2t.miraheze.org/wiki/Nocom

I'll highlight the important parts.

"The initial version of the patch, added in the initial port of Paper to 1.12.2, in September 2017, simply changed the behavior so that instead of ignoring the block dig, the server instead replies saying essentially "No, I think you can't mine that. Put (X:1, Y:2, Z:3) back as obsidian". In code terms, that's simply the only line added by the patch: this.sendPacket(new PacketPlayOutBlockChange(worldserver, blockposition)); // Paper - Fix block break desync

While this does patch ghost blocks (the patch is aptly named "Fix block break desync"), it also opens up a massive vulnerability. This applies to every CPacketPlayerDigging packet about a coordinate that is more than six blocks away from the player. There is no upper bound, just a lower bound of six. Simply by spamming "I am digging this block" on any coordinate across the map, the server would be forced to generate that chunk on the spot just to reply with what block should be there, to "fix" the desync that the server is concerned has just happened (while actually the client is sending the packets in bad faith)."

"So, instead of simply causing survivable amounts of lag (such as to skip queue), they began intentionally, repeatedly, and blatantly pushing it to the point where it would cause a server crash. That crash log included the exact line of that patch, and it was clear that spamming the packet was causing this. Hause[1] reported the issue to paper here, and electricboy applied the obvious patch in this commit. It was so trivial that there was no pull request or comments on the PR, it was simply applied directly to the development branch.

That obvious patch makes the "fix block break desync" only reply if the block is in a loaded chunk. Specifically, it just adds if (worldserver.isChunkLoaded(blockposition.getX() >> 4, blockposition.getZ() >> 4, true)) // Paper - Fix block break desync - Don't send for unloaded chunks beforehand, making the entire patch two lines of code."

"The realization is that you can click absolutely any block, anywhere on the server, even a million blocks away, and learn if it's currently a loaded chunk, by if the server responds to you or remains silent."

To summarize (as best as I can with limited knowledge of it), if you try to break a block in an unloaded chunk nothing would happen, but in loaded ones you'd get a response from the server and you'd essentially know there's a person in those chunks (and likely a base). Originally the message was the same, but it forced unloaded chunks to load and caused enormous lag on 2b2t, so it was changed to not load unloaded chunks. There was no distance limit on how far away it could be triggered.

As to whether or not Sim is immune to it, I don't know. It was caused by these two patches.

https://github.com/PaperMC/Paper/blob/d ... sync.patch

https://github.com/PaperMC/Paper/commit ... 66c8983743

If there's a patch that creates an upper distance limit for this issue (and we have it) then there's nothing to worry about. The issue was essentially caused by the Paper devs not making an upper limit, so someone could trigger a response from blocks millions or tens of millions of blocks away.

Edit: You apparently fixed this a while back lol