Minecraft's greatest mystery was just solved!

An ancient Minecraft leak, tominecon.7z, was lost for 13 years. But now, for the first time ever, we found it - and cracked it open. What's inside this mysterious file? Let's find out.

[SOUNDTRACK]
Craft Case - Interruption
Hideki Naganuma - That's Enough
Machine Girl - Heaven Central Authority
Van Sandano - Amalthea
Koji Kondo - River Safari
Koji Kondo - Volcano
pink - amelia
C418 - Chris
and one more I promise I'll add soon but I forgot the name

[CHAPTERS]
0:00 - Intro
0:22 - Let's catch up.
1:38 - tominecon.7z is found.
3:36 - The second hunt.
4:40 - From Dinnerbone, with love.
7:14 - Cracking the code.
8:48 - Inside tominecon.7z.
10:46 - Outro

bye love u

[mcbyt]

Here's some important links you might want to check out!

[Ciguato]

I like how Doge just casually has a bunch of leaked Mojang passwords like its nothing

[suzuaiki]

All community: we finally cracked a decoy for 10 years !!
Doge: pull outs an all old mojang pass word and did it in 1 day.

[RetroGamingNow]

Thank you so much for introducing me to this mystery! I had a blast learning about it and discussing it with everyone!

[ping]

Please don't say "way back in 2020". It makes me feel old

[treidex]

10:15 your data will still be encrypted. It's just that you wouldn't know the key so the data will just be garbage and unusable

[slicedlime]

I can't believe you listed totally real passwords on screen like that.

Anyway, gg!

[sicktaiz]

i just finished watching a video talking about how it will never be cracked, WHAT THE

[Moresteck]

great video! the only thing missing here is a mention that the server files are in fact different builds from the final 1.0.0. while code-wise (and even content-wise) they're identical, the final 1.0.0 server was built 6 hours after the tominecon 1.0.0 server, making them have different file hashes.

[DartMonkey]

10:15 No, parseInt would just throw an exception, which would then be caught by the try-catch blocks surrounding that code, which would then disconnect.
I don't even think the serverid is used for encryption, but if it is, the encryption wouldn't be "broken", it'd just fail to decrypt/encrypt anything because the keys don't match up.

[JungéShikisanki]

This was solved because 2 people had random info lying around.

[Deductive]

Alright but seriously, why wasn't "boxpig41" bruteforced sooner?

[AshishXMC]

GGs to Doge who somehow decided to keep the old leaked passwords, then to Dinnerbone who helped have this spread further, and of course, the original user who had sent the real thing and not a decoy.

[RedStoneMatt]

10:14 This is a very bold statement obviosuly made by someone who doesn't know how programming works.

If encryption fails on a software, the device doesn't go "Oh well, guess I'm just gonna send everything unencrypted then!" for OBVIOUS reasons.
At worse it may send junk data instead of actually readable encrypted data that may or may not be possible to reverse depending of the encryption scheme used assuming that incorrectly encrypting the data by ommiting the hex parts of the server ID makes the process reversible without further keying, but I HIGHLY doubt it.

The most likely scenario is just that the server will go "wtf?" and reject the connection during the handshake step, and assuming it didn't, the client would just send irreversibly unreadable junk data.
Also, not encrypting some data during an internet transfer doesn't mean that the average joe can see what you're sending. You still need to be on the same network as the person or have higher authority to spy on national or international internet transfers (like some countries do to catch torrent-ers)

[TheKdlvt]

That explanation about encryption is.... entirely wrong.
The parts about hex and dec are correct, but everything else is completely off the mark.
1. The server only ever sends _encrypted_ data. Your client only ever sends _encrypted_ data. There is no way for the game to do anything else, _by design_ . It would be a massive security risk if the opposite were the case, not only for your account details, but both your computer _and_ the server machine.
2. There is no way for encryption to "break" and be left completely open while in transit. That's not how encryption works, unless someone very stupid implements a fallback to plaintext which defeats the point of encrypting that data in the first place, as you could just force one side or the other to fail, receiving all that data without needing to decrypt it.
3. The server ID being parsed in the wrong base wouldn't initially cause an issue. In fact, you'd be able to _try_ to connect just fine. You wouldn't be able to fully connect, but you could try.
4. The reason it appears that multiplayer is completely disabled is because of a related (but different) problem. The first time the server (or your client, on modern versions it's the client) would try to send a packet the other would receive, what appears to them as, a garbled mess of incorrectly encrypted data. As such, they'd immediately close the connection, since trying to proceed would be a waste of time. The decryption fails because the encryption keys (in this case, the server id) would be different on either end, like trying to log in with the wrong password.

[kuhluhOG]

7:09 "unless you have time travel and use it to connect to the office WiFi."
Ok, another use of the password that we know now too.

[amimirmimir]

it was just 1.0 version of minecraft with minimal differences biggest differences being the extra files

[Lampe]

Kinda strange all the mobs in the sounds folder had names in singular (blaze, ghast, magmacube, etc.) but endermen are listed there as "endermen"…

[Emerald]

The fact that it was broken in such a simple way without some expert cia level shit like that methods, along with the only difference of it between the offical 1.0 being 4 characters in the code feels so anticlimactically funny

[ACMBitz]

*Gives up after 13 years* "So, I cracked this password in just a second now this is public information."