# Randar: how a reused java.util.Random leaked other players' coordinates > This repository is a writeup of Randar, a Minecraft exploit that recovers the internal state of a badly reused `java.util.Random` with lattice reduction and walks it backwards to find which chunk the server loaded last. It suits a reader who wants to understand the mechanism rather than run it, and it is a document with media rather than a tool. **spawnmason/randar-explanation** — "Randar" is an exploit for Minecraft which uses LLL lattice reduction to crack the internal state of an incorrectly reused java.util.Random in the Minecraft server, then works backwards from that to locate other players currently loaded into the world. - Repository: https://github.com/spawnmason/randar-explanation - Stars: 1,030 · Forks: 29 - Language: Shell - License: not declared - Published: 2026-10-19 · Updated: 2026-10-19 · Language: en - Canonical page: https://hysenlabs.com/projects/spawnmason-randar-explanation ## The core claim, stated precisely Every time a block is broken in Minecraft versions Beta 1.8 through 1.12.2, the precise coordinates of the dropped item can reveal another player's location. That is the whole finding in one sentence, and it is a startling one because the broken block and the player are in completely different places. A player breaks a block in a chunk they are standing in, and the server drops the item at a pseudo-random position inside that block. That position is not random in the sense the server intends, because the generator producing it has just been reset in a way that depends on something else entirely, namely a nearby chunk that was loaded a moment earlier because somebody walked through it. So the information flows the wrong way for the server's purposes. The item's position leaks a fact about the last chunk that was loaded, and the last chunk that was loaded is where some other player was. The project describes Randar as an exploit for Minecraft which uses LLL lattice reduction to crack the internal state of an incorrectly reused `java.util.Random` in the Minecraft server, then works backwards from that to locate other players currently loaded into the world. The writeup also points to a YouTube video as an alternative way to learn about Randar, and there is a timelapse in the repository's media directory showing the exploit in action over time, with more timelapses available both as files and as a YouTube playlist. So the artefact is a document. The top level of the repository holds a `.gitignore`, a `README.md` and a `media/` directory, and the language is recorded as Shell only because of what is in that media. There is no code to read here, and the writeup itself says that more detail will come later on the lattice step, which means this is a first pass at the explanation rather than a complete paper. ## The bug is reuse, and reuse is everywhere The mistake in Minecraft's code is present from versions Beta 1.8, released in 2011, through 1.12.2, released in 2017, and 2b2t stayed on this version until August 14, 2023. The mistake is that various instances of the random number generator, `java.util.Random`, are reused sloppily in various parts of the code, and they are insecure to begin with. Specifically, there is reuse of RNG between generating terrain and in-game actions such as mining blocks. The mechanism of the reuse is described as the global `World.rand` having its seed reset to a function of the chunk coordinates, in order to check where a nearby Woodland Mansion should be and whether it is this chunk in particular. So a single global generator serves two unrelated purposes. Terrain generation wants a reproducible, position-dependent random sequence, so it resets the seed from the chunk coordinates. Mining wants unpredictable randomness for the drop position, so it draws from the same global object. And because the reset happens on chunk load, the state of that generator at any moment encodes something about the most recently loaded chunk. That is the design flaw, and it is worth naming precisely because it is not exotic. Nothing here is a broken cryptographic primitive or a side channel in a memory allocator. It is a global mutable object with two owners and a reset policy tied to the wrong thing. A `java.util.Random` reused across subsystems and reseeded from unrelated coordinates is a textbook state-leak, and the reason it survived from 2011 to 2017 is that the leak requires a specific observation to exploit, and almost nobody was looking. The writeup also names the ecosystem around it. Minecraft players use mods like ReplayMod that log packets, and those log files might still be sitting around. If anyone was using such a mod while you were at your base, they may have unknowingly recorded RNG data that could reveal your location, because breaking blocks is an extremely common action and every such block break reveals the server's RNG state and therefore the location of the most recently loaded chunk. ## The exploit, step by step The writeup summarises the exploit in six steps, and the sequence is the interesting part. First, some player on the server, the victim, walks around, causing a chunk, a 16x16 blocks section of the map stretching to world height, to be loaded into memory server side. This happens normally all the time. Second, the server checks if certain structures are being generated in that chunk, and the last one checked is the Woodland Mansion. Due to the sloppy code, the global `World.rand` has its seed reset to a function of the chunk coordinates, in order to check where a nearby Woodland Mansion should be and whether it is this chunk in particular. Third, one of the bot players, also on the server but at an unrelated location, mines a block very soon after. The dropped item appears at a random coordinate within the mined block, determined by three consecutive `World.rand.nextFloat()` calls to pick the X, Y and Z coordinates between 0 and 1. The bot records the timestamp and the precise X, Y and Z values. Fourth, lattice reduction determines the exact internal state of `World.rand` that caused those three floats. Observing one output of the RNG could imply any one of about 16 million possible internal states, but the output has been sampled three times in a row for the X, Y and Z coordinates, and the internal state update between each call is known, a simple multiply, add, then mod, so lattice methods narrow it down to the only possibility essentially instantly. Fifth, the RNG state is stepped backwards in time until one is found that could have been caused by a Woodland Mansion check. The internal state of `java.util.Random` can be stepped backwards just as easily as forwards, and by stepping backwards it can be found in just a few thousand steps, even on busy servers with heavy RNG usage, which identifies the most recent time the RNG's internal state was reset and therefore the location of the most recent chunk that was loaded on the server. Sixth, a heatmap is built up over time from that database, and the hotspots are paid a visit in game. To find a specific person, login times are associated to hits, as logging in causes a lot of chunks to load immediately. Two details in that sequence deserve emphasis. The three consecutive draws are what make the lattice step tractable, since one output leaves sixteen million candidates and three outputs pin it down. And the backwards stepping is bounded at a few thousand steps, which is why the technique works even on a busy server where the generator is being hammered by other players. ## Why the world was 3.6 quadrillion square tiles The context the writeup gives for 2b2t explains why this mattered as much as it did. The goal is to determine the in-game locations, that is coordinates, of the other players in the world, no matter how far away they are. The server in question is 2b2t, the oldest and most famous anarchy Minecraft server, which means no rules, so players are not banned for any reason. Doing stuff like this is kind of the point on this server. On that server, the only thing keeping your stuff safe is that the map is huge, at 3.6 quadrillion square tiles, and no one else knows where you are. So a coordinate exploit is a game-breaking deal, and the writeup says so explicitly. The writeup also puts the exploit in a longer history. Before Randar there was another coordinate exploit on 2b2t, Nocom, from 2018 to 2021, with a writeup, a Hacker News thread and a video linked. So this is at least the second time the community found a way to turn server state into player positions, and the earlier one ran for three years. That history is relevant context for the second half of the writeup, which is the most consequential part. Even if you play on a server that has updated to a newer version of Minecraft, or has otherwise patched RNG manipulation, your coordinates are still at risk from Randar due to the ability to exploit RNG data retroactively. Every location that was active in versions Beta 1.8 through 1.12.2 should be considered compromised, even if the server has long since updated past 1.12.2 or patched RNG manipulation. That is a different kind of claim from the exploit itself. The exploit needs a live vulnerable server. The retroactive risk needs only an old recording. And the recordings are ordinary: a mod that logs packets, sitting on someone's disk, containing block breaks that everyone does constantly. The writeup draws the conclusion that this is a pretty big deal, and the reasoning is that the retroactive risk applies to every Minecraft server, not just the vulnerable ones. ## The tooling, the authors, and the limits of the document If you want to use the Randar exploit yourself, the writeup points elsewhere. There is a website created by rebane2001 where you can drag in your ReplayMod files from 1.12.2 and see the coordinates of other players, and it runs client side so your recordings will not leave your browser. A video shows the website in action, and the example ReplayMod file from that video is available in the repository's media directory. So the repository deliberately is the explanation and the media, and the interactive tooling is a separate project by one of the people credited in the writeup. That split is sensible for something that reads private recordings of other people's gameplay, because a client-side tool has an obvious privacy property and a server-side one would not. The credits are worth recording, because the discovery and the writeup are by different people. Randar was discovered by n0pf0x, also known as pcm1k, and the writeup was written by leijurv, with some additional commentary at the end written by n0pf0x. The exploiters are listed as 0x22, Babbaj, TheLampGod, leijurv, Negative_Entropy and rebane2001, with a link to TheLampGod's video and a link to a video by HermeticLock that the writeup describes as 100% humorous 0% factual. The limits of the document are stated in the text itself, and there is one notable admission. On the lattice reduction step, the writeup says that more detail will come later, and describes the argument only in broad terms. So the mathematics of the recovery, the choice of lattice basis and why three observations are sufficient, is left for later. That is a real limit for anyone who wants to reproduce the attack rather than understand it, and it is also the honest state of a document that describes a live exploit against a live server and a six-year-old version of a game. The version range is the other limit to carry. Beta 1.8 through 1.12.2 covers the vulnerable window, and the writeup notes that 2b2t stayed on that version until August 14, 2023, which is why the technique had a long life on one server and why the retroactive risk still matters for anyone who played there. ## Conclusion This writeup fits a reader who wants to understand a specific class of vulnerability, because it explains in order how a three-float observation of a linear congruential generator turns into a location, and because it is honest about the scope, which is Minecraft versions Beta 1.8 through 1.12.2 and the servers that ran them. Skip it if you are looking for an exploit to run, since the repository contains a README and media rather than a toolkit, and note that the tooling lives elsewhere, with a browser-based site that reads ReplayMod recordings client side. Before you read the coordinates in the writeup as a general statement about Minecraft, notice the version range and the fact that a patched server does not prevent the retroactive risk from old recordings. The last push was on 2026-08-11. ## FAQ ### What is the Randar exploit? It is an exploit for Minecraft that uses LLL lattice reduction to crack the internal state of an incorrectly reused java.util.Random in the server, then works backwards from that to locate other players currently loaded into the world. ### Which Minecraft versions are affected by Randar? Versions Beta 1.8 through 1.12.2, with 2b2t staying on 1.12.2 until August 14, 2023. The flaw is reuse of the global World.rand between terrain generation and in-game actions such as mining blocks. ### How does lattice reduction help recover the random state? One output of the RNG could imply any of about 16 million possible internal states, but three consecutive nextFloat calls for the X, Y and Z drop coordinates, together with the known multiply, add, mod update between calls, narrow it to the only possibility. The state is then stepped backwards to find the most recent reset. ### Can my coordinates still be exposed on a patched Minecraft server? Yes, the writeup argues they can, because the exploit works retroactively. Old ReplayMod recordings contain block breaks that reveal the server's RNG state and therefore the location of the most recently loaded chunk, so every location active between Beta 1.8 and 1.12.2 should be considered compromised. ### Does the repository contain the exploit tool itself? No. The repository holds a README and a media directory with timelapses and an example ReplayMod file. The interactive tool is a separate client side website that reads ReplayMod recordings in the browser, and the writeup notes that the lattice reduction detail will come later. ## Sources - [Issues](https://github.com/spawnmason/randar-explanation/issues) - [README](https://github.com/spawnmason/randar-explanation/blob/master/README.md) - [spawnmason/randar-explanation on GitHub](https://github.com/spawnmason/randar-explanation) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/spawnmason-randar-explanation