Talk:Development resources

Login - verification key
Don't delete this! It's a valid and useful resource!


 * Yeah, I guess. It wasn't particularly useful since it seemed like the information about the communication protocol was just copied from somewhere else by someone who hadn't taken the time to actually learn or understand the protocol.  I went ahead and cleaned the whole thing up and provided technically useful information.  There are probably a few things that could be better explained and formatted, but at least now the information is definitely usable.  One thing I plan to do later is to describe what packets are sent when as well as describe the handshaking process that occurs. --24.12.200.40 07:16, 6 January 2010 (UTC)


 * Could do with a bit of information on the verification key - Not sure what it is. Is it the client's password? Is it the MD5 hash of their password? Is it a http sessionid? I have no idea. --Toneo 20:24, 9 January 2010 (UTC)


 * Gotta ask Notch about it, but I doubt he'd allow that due to security-related stuff.--Quatroking - Garble Garble! 21:02, 9 January 2010 (UTC)


 * Anything on the minecraft protocol? Would be very useful, for Sending/Receiving data in it (bots) --Toneo 22:43, 9 January 2010 (UTC)


 * I asked notch, and he wouldn't exactly like it if we'd have information on user verification in here. So lets not do that, eh? ;) --Quatroking - Garble Garble! 12:23, 10 January 2010 (UTC)


 * Lol, would be nice to have something on here on how to login properly though. --Toneo 21:09, 10 January 2010 (UTC)


 * It has nothing at all to do with the user's password. The server sends a salt to Minecraft.net and when you join through Minecraft.net while logged in, an MD5 of your name and the server's salt is given to the applet. The shared secret is only known by the server and Minecraft.net, and the only way to get this salt (that I am aware of) is a Man in the Middle attack on the server. That kind of attack is so trivial to break (use HTTPS+self signed certificate for salt sharing) that even if you devised a way to use it, it would take Notch at most 10-20 minutes to close it. --Skrylar 17:25, 18 March 2010 (CST).

You have to retrieve the verification key manually from the cookies on login page. I have function in c# to do above. Because of multipart http page, HttpWebRequest has some trouble receiving cookies in step 2, so it is easier to just use raw TcpClient for this. Exe 08:42, 28 March 2010 (UTC)
 * 1) Go to http://www.minecraft.net/login.jsp and GET, you will receive JSESSIONID cookie.
 * 2) Go to http://www.minecraft.net/login.jsp and POST "username={0}&password={1}" using JSESSIONID cookie. You will receive logged in cookie ("_uid").
 * 3) Go to game url and GET using JSESSIONID cookie and _uid cookie. Parse the page to find server, port, mpass strings.

Server->Client packet 09
Who changed the Server->Client packets to say they're absolute? They're not. Looking at the packets this is obvious because it doesn't send shorts, it sends bytes. Please don't make major changes like this without consulting the discussion page and especially if it's wrong. --Yourself 23:39, 17 March 2010 (UTC)


 * True, it is bytes. Exe 08:42, 28 March 2010 (UTC)

Moving protocol to its own wiki page
Are there any objections to moving the protocol to its own wiki page? It seems out of place to link to other pages on the map format and then inline the protocol spec with the page. --Skrylar 17:28, 18 March 2010 (CST)

Sounds good to me. If it's moved I might actually be motivated enough to add a section about the communication syntax rather than just having a lexicon as it were. --Yourself 15:28, 29 March 2010 (UTC)

http://cppprogramming.com/
The site seems to have expired, remove?

Server->Client packets 02,03,04 (map) - broken map
I receive map that is translated in x dimension by 4 tiles (modulo map size). I fix it by map[(x + mapreceivedsizex - 4) % mapreceivedsizex, y, z]=receivedmap[x,y,z] but i don't know why this happens. This is consistently 4 tiles, on public servers too. y and z does not seem to be affected. Exe 09:29, 28 March 2010 (UTC)

This depends on where you start reading the actual level data out of the information sent. It's possible that those 4 bytes you are reading are actually the length of the byte array. The level.dat file structure is pretty confusing because it uses Java's serialization protocol, which has all sorts of weird control bytes that seemingly do nothing (I've tried parsing it by hand and there are a few pieces that don't make sense according to the published Java protocol). It'll be nice when Notch gets around to implementing the new map format in clients so we don't have to deal with the nightmares that Java produces. --Yourself 15:26, 29 March 2010 (UTC)

Yes, level.dat is a complicated java serialized file. But packets 02,03,04 do not contain level.dat.The received byte array, after decompressing (gzip) has no java strings in it, and the size is equal to 4+mapsizex*mapsizey*mapsizez. Server->Client map packets contain gzipped(4 unknown bytes + pure blocks array). Exe 16:11, 29 March 2010 (UTC)