[HN Gopher] Nocom - 2b2t Minecraft server exploit using Monte-Ca...
       ___________________________________________________________________
        
       Nocom - 2b2t Minecraft server exploit using Monte-Carlo
       localization
        
       Author : cyber_kinetist
       Score  : 122 points
       Date   : 2021-12-19 16:44 UTC (6 hours ago)
        
 (HTM) web link (github.com)
 (TXT) w3m dump (github.com)
        
       | leijurv wrote:
       | Surprised to see this posted again, I wrote this, feel free to
       | ask me anything!
        
         | ucarion wrote:
         | I'm curious what kind of tooling you developed as part of this
         | process. It seems, from the linked YouTube video, like
         | individuals were actively monitoring the data produced from the
         | exfiltration attack. How did you go from the raw data to
         | producing something that people could usefully monitor?
        
           | leijurv wrote:
           | Sure!
           | 
           | For monitoring on a meta-level, we used Prometheus and
           | Grafana. Here's what that looked like near the very end: http
           | s://www.dropbox.com/s/ktlvvtmppq64u8o/trimmed%20grafana%...
           | Since the ratelimit was heavily in place by then, the numbers
           | are pretty low. For example, the headliner "blocks per
           | second" was well over three thousand a few weeks before then.
           | 
           | One of the most common queries for actual usage though, was
           | "what bases in the last 24 hours (or whatever) have the most
           | chests currently". We'd then travel to these locations to
           | borrow items. Here's that query https://pastebin.com/fjhHGSYz
           | Roughly, it grabs chunks with chests in that timeframe, then
           | uses a recursive Postgres CTE to traverse the
           | https://en.wikipedia.org/wiki/Disjoint-set_data_structure
           | that we used to implement DBSCAN, from the leaf to the root.
           | Then it groups by the root, which in practice means grouping
           | chunks together by which ones semantically have been
           | determined to be part of the same base, then makes a report
           | by quantity per base.
           | 
           | There was also a web UI that showed all active tracks. You
           | could click any player and see their travel history, the
           | route they had taken to get to that location. As well as
           | clicking any cluster and seeing the usernames associated with
           | it. We used this a lot to grab what members were present at a
           | given item stash or base, to make sure we weren't stepping on
           | anyone's toes.
           | 
           | In terms of what it took to make this happen, the stars of
           | the show were probably the main Postgres, which was hand-
           | tuned on top of a hand-tuned ZFS, on top of a NVME drive that
           | was IOMMU passthrough'd to this VM for maximum performance.
           | As well as https://github.com/OpenHFT/Chronicle-Map, which
           | really helped out. We needed a mapping from block coordinate
           | to a bit of data about that location, such as the last
           | timestamp we checked it, what Minecraft block was there last,
           | whether the block is interesting, uninteresting, different
           | from seed, etc. High frequency trading software was perfect
           | for this use case, because it greatly reduced GC pressure on
           | the JVM, since the data was stored off-heap. It ended up at
           | around (roughly) fifty million entries, served hundreds of
           | thousands of requests for block data per second, and
           | requested historical data (from the Postgres) at about thirty
           | thousands SELECTs per second (from a table with over ten
           | billion rows). The reason why this needed to be so fast, is
           | that the use case is downloading bases. Sometimes someone
           | would log in to 2b2t at their base, after having not played
           | for weeks at a time (so the data is in Postgres, not the map
           | in RAM), we wanted to be able to pick up right where we left
           | off on downloading what they had built. This means it needs
           | to get back up to speed with their entire base, as fast as
           | possible, in the seconds before they move away to other
           | chunks, or log off the server. We are downloading bases one
           | click at a time, and bases are huge. The area that is loaded
           | in by a player is 144 by 144 by 256. That's 5 million blocks.
           | And there are about 250 players online on 2b2t at any given
           | moment in time. That's well over a billion blocks that we
           | _could_ click on, and learn which Minecraft block they are.
           | But, _which_ locations should we use up our clicks per second
           | budget on? It focused on areas that are being changed
           | rapidly, and areas that are different from the base vanilla
           | terrain. Those are certainly bases, large Minecraft builds.
           | We do an expanding paintbucket pattern that expands in 3
           | dimensions to whatever has been built there. However, we have
           | to do this quickly, and we have to pick up where we left off.
           | Someone might be flying around their base with an elytra, at
           | very fast speed. We would love to scoop up the terrain that
           | they're flying over. If the base is particularly interesting,
           | someone flying over a certain area could have had about
           | twenty Minecraft accounts spread all over 2b2t's map suddenly
           | refocus all of their left clicks on that one area, to grab
           | all the interesting neighbors that it wasn't able to last
           | time. We peaked at about three thousand block clicks per
           | second, averaged over weeks. So this was a massive data
           | loading and management problem.
        
         | barneygale wrote:
         | Hello! I'm the original owner of the 'BibleBot' account/bot.
         | Glad to see you put it to good use :-)
        
           | leijurv wrote:
           | Lol! Sorry for getting it locked, it is reversible if you
           | still have the email. Mojang, it appears, didn't like spam
           | login from a different cloudflare warp IP every few
           | minutes...
        
             | barneygale wrote:
             | All is forgiven if you can share the trick to not getting
             | AFK kicked? (first.last@gmail.com). I've wanted to bring
             | the OG code back for years.
        
               | BbzzbB wrote:
               | Talking of OG, that Gmail account... looks rare.
        
               | Fnoord wrote:
               | Username is barneygale. You do the parsing.
        
         | phgn wrote:
         | This whole project is incredibly impressive, good job!
         | 
         | How much time would you say went into this both from yourself
         | and the others? Probably quite a lot over the years? (because
         | again, it's very impressive)
        
           | leijurv wrote:
           | Hard to estimate, probably a few hundred hours from me, and a
           | comparable amount from others. As a random data point, I sent
           | 53000 messages in the group chat developing it. -\\_(tsu)_/-
        
         | [deleted]
        
         | fffobar wrote:
         | Tracking was completely broken by any teleporation, right? Such
         | as enderpearl loading or a respawn at the bed.
         | 
         | Also, how many login sessions would it take to associate a
         | track with an account?
        
           | leijurv wrote:
           | Correct, loading a pearl and respawning would throw us off
           | the trail. This is why our aim was to follow the initial
           | travel to the base location, rather than a future pearl TP.
           | The easiest advice in order to throw off nocom is to travel
           | in a straight line in the overworld for perhaps 10k blocks,
           | set a bed quickly, then continue another 10k blocks, then
           | /kill to the bed, then go perpendicularly for a render
           | distance or two before the chunks unload at your death
           | location. Even with some hypothetical tracking improvements
           | (that never actually were written), such as walking back the
           | last 10 minutes whenever a track goes cold, that would still
           | throw it off.
           | 
           | Generally 2 or 3. 1 point of association was given whenever a
           | track went cold, split up among however many players logged
           | off within -6 seconds to +1 seconds of that timestamp
           | (because of chunks unloading on a 5 second schedule). 1 point
           | could be a false positive, but 2 or 3 would be reliably
           | trustworthy.
        
         | ThouYS wrote:
         | what's your take on university as opposed to learning by doing?
         | how do they complement each other?
        
           | leijurv wrote:
           | I am not done with university yet, so I don't speak
           | confidently. But I'm afraid I have no special perspective, I
           | just echo what I hear a lot: Learning by doing is probably
           | the most important, but structured courses provide a
           | theoretical and practical foundation that fills in a lot of
           | important gaps that I would have had if I were only self
           | taught.
        
             | kbenson wrote:
             | That echoes my own thoughts as someone that's been out of
             | school for a long time and worked with people with and
             | without degrees. There's some gaps without a degree, but
             | not usually so much that they can't be overcome with a
             | little time and effort, and I don't think it usually
             | matters much.
             | 
             | Connections from university though... I suspect that can be
             | extremely useful, but didn't leverage that in my own time
             | there, so can only guess as to how much (and also I didn't
             | go to an ivy league school or anything where it could have
             | made an even larger difference).
        
         | tommsy64 wrote:
         | I'm curious how you developed the "very cute headless"
         | Minecraft client. Did you use the Forge build tools? How did
         | you go about ripping out the rendering/keyboard stuff?
        
           | leijurv wrote:
           | Yes, Forgegradle was used. Frankly, not much interesting
           | here, just a whole lot of work going through all the
           | Minecraft code, and using Java reflection where possible and
           | JVM bytecode injection otherwise. There's a lot of access
           | transforming, using theUnsafe to allocate classes without
           | calling their constructors, etc. As a random example that I
           | remember, one of the last things to patch was that we had it
           | working, but when you got kicked from the server, it would
           | crash. This is because it would try to create a currentScreen
           | GUI for the "disconnected from server" message, which for
           | some reason was long enough that it was considering whether
           | to wrap the text to the next line, which needed something
           | like a font size, or maybe the window width, which crashed
           | since there is no window or font.
        
         | ajkjk wrote:
         | Why did you do all this? I mean.. it's a ton of engineering,
         | for what? For fun?
        
           | leijurv wrote:
           | Yes absolutely, for fun! Of course, it's also fun to have a
           | secret project that no one knows about, to get an edge. 2b2t
           | is practically the only Minecraft server that allows any kind
           | of hacking your client (without getting banned), while also
           | having an active community of meaningful size, so that was
           | the clear target.
        
             | phgn wrote:
             | I'm curious (without having context on 2b2t): How did you
             | all think about the morality of the exploit? Like it's fun
             | to overcome technical challenges and interesting to see /
             | follow projects other people build in game, but aren't you
             | destroying their work? Or is that accepted practice on the
             | server?
        
               | leijurv wrote:
               | Yes, this is a very fair question to ask. Of course, on
               | the one hand, I could just say "this was fair game". The
               | "point" of choosing to play on this server, is that it is
               | _THE_ no-rules server. The people who stick around more
               | than a few months are the ones who accept that anything
               | will eventually be griefed. Sometimes people call this
               | the  "sandcastle mentality", which means that a player
               | accepts the destructive nature of 2b2t, and learns to
               | live with it. Its name comes from building sandcastles on
               | beaches: no one builds a sandcastle believing or
               | expecting that it will last forever. The waves will
               | always wash it away eventually, or someone else will
               | break it. The only thing standing between your base and
               | "the waves" is that no one knows where it is.
               | 
               | One way to think about it, is that in "normal" Minecraft
               | servers, it's you versus everyone, but in an anarchy
               | server that allows hacks, it's you versus the server
               | software. There have been many hacks to locate other
               | players, like following the trails that they leave in the
               | world, that you can only see if you inspect some specific
               | bits in chunk packets from the server. Perhaps they
               | posted a screenshot that shows bedrock, which you can
               | brute force their location from in a few hours/days on a
               | GPU with OpenCL that simulates Minecraft terrain
               | generation. Nocom was similarly "fair game", in that it
               | only used the Minecraft protocol, and stayed within the
               | "bounds" of talking to 2b2t with Minecraft packets and
               | extracting information from that.
               | 
               | All that being said, it's still plainly the case that
               | people put a ton of time into their bases, and no matter
               | how much moral sleight of hand and cope you apply, it's
               | still kicking over someone's sandcastle. When it comes to
               | actually traveling to these locations and raiding them,
               | our aim in that campaign was pretty much solely to amass
               | a large stash of items/blocks for ourselves for the
               | future. I would pass on bases by-default, only handing
               | them along to be raided if there was bad faith
               | construction (e.g. swastikas), or if most of the builders
               | were known to be naughty. The main campaign was against
               | standalone item stashes. These do take some time to
               | create (by having exploiting past item duplication
               | glitches), but they don't really have any creative
               | expression in the same way that a base does. I have no
               | logical argument for why I say that the same amount of
               | hours invested in artistically making a build is more
               | morally valuable than duplicating building blocks, it's
               | just what feels about right. During the time when I was
               | involved, we passed up hundreds of bases just because
               | there was something actively being built there, and
               | essentially only hit places that were just rows of chests
               | placed on the ground in the world.
        
               | H8crilA wrote:
               | A very good video/essay/poem on the sandcastle mentality:
               | 
               | https://youtu.be/Oy1UUoq_RGg
        
               | leijurv wrote:
               | Yes, I probably should have credited that video to be
               | honest.
        
       | cityofdelusion wrote:
       | If anyone else was lost like myself, here is the rundown. The
       | linked github readme assumes prior knowledge of 2b2t.
       | 
       | This is an exploit for a very old Minecraft server (called 2b2t)
       | where griefing (destroying other creations) and hacking is
       | basically allowed. This kind of environment means that groups of
       | players are incentivized to hide their projects out in the middle
       | of nowhere, hundreds of thousands of blocks away from the world
       | origin coordinates. The exploit allows a client to ask the server
       | if data chunks at arbitrary coordinates have player activity in
       | them, opening the server up to a brute force search to locate
       | well-hidden bases.
       | 
       | Basically, a group got spy satellites in an anarchy Minecraft
       | server where remaining hidden is critical to not being destroyed.
        
       | TheJoeMan wrote:
       | I learned some of the Monte Carlo techniques in my medical
       | imaging classes, it's very interesting the data one can fish out
       | with a good-enough graph.
       | 
       | I also find the adaptive location "pinging" quite interesting,
       | reminds me of the tech behind the F-22 active radar.
        
       | cyber_kinetist wrote:
       | Here's the FitMC Youtube video that first announced the exploit:
       | https://www.youtube.com/watch?v=elqAh3GWRpA
       | 
       | A 2b2t wiki page about the exploit:
       | https://2b2t.miraheze.org/wiki/Nocom
       | 
       | The teaser video: https://www.youtube.com/watch?v=3ayxeruAan8
        
         | 323 wrote:
         | I second the first video, it's extremely well done, and as
         | someone who never played minecraft I almost understood what
         | happened.
        
       | the_gipsy wrote:
       | This is brilliant!
       | 
       | Ah, gives me nostalgia of civcraft conspiracies...
        
         | thegjp210 wrote:
         | good to see some other civcraft alumni on HN. What an
         | experience...
        
           | iFred wrote:
           | Probably the only server experience that really felt like you
           | had an entire world and society to explore and consequences
           | to deal with.
           | 
           | I spent way too much time trying to figure out a way to
           | scrounge up Ghasts and TNT to level Orion.
        
       | H8crilA wrote:
       | This is from the same guy who coded Baritone:
       | 
       | https://youtu.be/CZkLXWo4Fg4?t=78
       | 
       | Extremely useful on anarchy servers, in fact the entire current
       | "era" of anarchy is called "The Automation Period" mostly due to
       | Baritone.
        
         | leijurv wrote:
         | I actually helped convince Sato in Feb 2020 to call it
         | "automation period"; some other ideas were "age of
         | fragmentation" (referring to how group alleigances were
         | becoming split, with players in more than one group at a time)
         | or "age of the algorithm" (referring to the YouTube algorithm
         | promoting the server).
        
       | meibo wrote:
       | What confuses me about this is that no one else found it?
       | 
       | Being somewhat experienced at game networking and writing server
       | code with this type of exploit(e.g. sending a packet to do
       | something at the other end of the map and processing the result)
       | in mind, this would be something I either would have checked for
       | in the first place if performance would have allowed for it, or
       | would have kept in the back of my mind in case I hear about a
       | possible exploit that takes advantage of it.
        
         | itronitron wrote:
         | For most multiplayer MC servers, this sort of exploit isn't
         | worth the time because there are commands available to players
         | to find nearby players and their bases (so they can check out
         | each other's builds or participate in the local economy.)
        
         | Sesse__ wrote:
         | What confuses _me_ about this is that nothing seems to say what
         | it _is_. It's like there's some giant practical joke I'm not a
         | part of, and the README.md just throws off heatmaps and wants
         | me to watch a 24-minute YouTube video. Is everybody supposed to
         | be a Minecraft expert? Is a simple paragraph of what this is
         | all about (at the very beginning of the file) too much? :-)
        
           | leijurv wrote:
           | There's a section called "The entire thing summed up in three
           | sentences" in the linked GitHub README.
        
         | leijurv wrote:
         | One reason might be that this only existed in Paper, which is a
         | downstream fork of Spigot, which is (sort of) a downstream fork
         | of CraftBukkit, which is a set of patches to the official
         | minecraft server.
         | 
         | Another reason might be that this only does anything if there
         | are many players on the server, and you hit a region loaded by
         | someone else. Might be difficult to think of that. You'd never
         | come across it if testing in singleplayer.
         | 
         | But in essence I agree, it's surprising that no one else found
         | and reported this years ago!
        
       ___________________________________________________________________
       (page generated 2021-12-19 23:00 UTC)