- Official Post
Introduction
On August 24, 2022, I discovered an exploit in Minecraft that allowed me to dump the NBT of any player in the same world I was in, even if I was nowhere near them. I called it Worldcom, paying homage to the infamous Nocom exploit from 2b2t. Instead of patching it (which, in retrospect, I really should have done as my #1 priority), I created a fork of EpsilonBot that used the exploit to track consenting players on the server with the goal being to build a heatmap of player activity that I could then use to find builds when I would eventually scrape the flatlands again.
After scrapping the project in September 2022 due to issues with the way everything was structured, I brought it back in June 2023 and began to work on it again. However, other players (namely frizzydoggy, props for finding it by the way) discovered the same exploit I was using shortly afterwards on their own and shared it with several individuals including Yurni, riawo, (presumably) Allink, and (presumably) maniaplay. However, I refused to patch the exploit because I wanted to allow my bot project to continue (which was stupid of me and I really should not have done that). When concerns about malicious actors potentially abusing the exploit in much more devious ways arose, I finally decided to patch the exploit in Scissors 1.17.1 on July 4, 2023. I should have done it sooner, and the fact that I didn't was incredibly irresponsible of me and I'm sorry that I didn't take action sooner.
What's done is done, and there's nothing I can really change that. Now that the exploit has been patched, I've decided to publicly disclose the exploit and how my bot used it along with multiple other quirks with how Minecraft works to track players on the server. Keep in mind that while the exploit is properly patched in Scissors, I've installed a custom plugin that allows exclusively my bot to continue working even with the exploit patched.
How the exploit works
To facilitate the ability to press F3 + I to get the NBT data of any entity on the server, Mojang added a packet specifically for requesting and responding with entity data in their protocol. The way they did this was by utilizing the numerical entity ID that all entities have when they are on a server. When you press F3 + I when looking at an entity (like a player), your client sends a request containing two numbers: the numerical entity ID (which is incremental and thus can be guessed) and a transaction ID, the latter of which allows your client to keep track of what entity/block entity you requested so that it can deliver the correct message. The server then responds with the NBT data of whatever you're requesting plus the transaction ID. This only works if you have operator permissions.
Mojang messed up in two different ways when they were implementing this:
- They did not account for any distance checks, presumably because they assumed that if you were an operator, you probably had it for a reason
- Transaction IDs could be re-used. While this is technically not an issue, it was something that the bot also exploited to keep track of which data set belonged to what entity ID, because you could feed it any transaction ID you want and it would respond back with the same ID
As a result, you could essentially track any player you want if you knew their numerical ID by repeatedly making requests for their data using it. Because there are no distance checks, you could literally get a player's coordinates even if you were in a completely different part of the map. If you wanted to track multiple players at once, you could simply supply their numerical IDs as the transaction IDs, which would uniquely identify the resulting data as a specific player's. This was the basis for how I would use the exploit.
How the bot finds players
The bot has three different ways of finding players.
- Traditional brute-forcing
When the bot joins the server, it starts spamming the server with requests for entity data with IDs starting from 0 and working its way up by incrementing the entity ID. This is a traditional and straightforward way of looking for players. It's often very slow if it joins while the server has been up for a while - Backwards brute-forcing
When a player who is opted-in joins the server, the bot will spawn a pig that then dies to get its numerical ID, which is assumed to be in pretty much the same range as the pig's. Once it gets the pig's entity ID, the bot then brute-forces backwards by doing pretty much the same thing as traditional brute-forcing, but instead starting at the pig's entity ID and decrementing from there. This is often successful because the bot is always in a position where spawning a pig will just result in its death (whether it be fall damage or suffocation). - Manual encounters
When a player who is opted-in teleports to the bot, the bot will immediately get their entity ID. This is the quickest measure as it doesn't require any brute-forcing to work.
In all three scenarios, the bot will check the response it gets to see if the entity is opted into being tracked. If it has, then it proceeds to link the entity's numerical ID with the UUID and stores it memory until either the player leaves, the player opts out, or the bot shuts down.
How the bot tracks players
After finding players to track, the bot will repeatedly make requests every 3 seconds to get the NBT data of players it has linked to the server using their entity ID. To keep track of whose data belongs to what request, the bot supplies the entity ID as the transaction ID. Once it gets a response from the server, it then sends a dataset consisting of the player's UUID, a Unix timestamp (to keep track of when it was created), the player's X and Z coordinates, and the world they are in to a PostgreSQL server. No other data is stored.
