Session

The minecraft client and server communicate with minecraft.net to validate player sessions. This page describes some of the operations.

Login

To log the player in, the official launcher sends an HTTPS POST (GET appears to suffice as well) request to:

https://login.minecraft.net

with the postdata:

 ?user=<username>&password=<password>&version=<launcher version>

and a "application/x-www-form-urlencoded" Content-Type header.

The current launcher version is "13", sending a value lower "12" than this will cause the server to return "Old version", however you can send any large number and it will return as expected. If the login succeeded, it will return 5 ':' delimited values.

 1343825972000:deprecated:SirCmpwn:7ae9007b9909de05ea58e94199a33b30c310c69c:dba0c48e1c584963b9e93a038a66bb98

1. current version of the game files (not the launcher itself). This is a unix timestamp which the launcher compares to the ~/.minecraft/bin/version file.
2. Previously contained a download ticket for requesting new versions of minecraft.jar from the server. Now contains only "deprecated".
3. case-correct username.
4. sessionId - a unique ID for your current session.
5. UID - currently unused, introduced near August 8th, 2012. Grum says this is the unique ID for the user, potentially for changing Minecraft names in future.

If the request is missing a parameter, the server will return "Bad response". If the login information is incorrect, the server will return "Bad login". If the login information is correct but the account isn't premium, the server will return "User not premium".

Updating

To update, the launcher downloads files from

http://s3.amazonaws.com/MinecraftDownload/

It takes the unix timestamp from the login request and stores it in ~/.minecraft/bin/version
The following files are downloaded from /MinecraftDownload/ in this exact order:

• lwjgl.jar
• jinput.jar
• lwjgl_util.jar
• minecraft.jar

And then the natives.jar appropriate for the following operating systems: windows, linux, macosx, and solaris

• <os-from-list-above>_natives.jar.lzma

When downloading minecraft.jar, GET variables are set as follows: ?user=foo&ticket=deprecated, although they seem unnecessary to successfully downloading the file.
Furthermore, the downloaded files are all verified via MD5 which is sent via ETag by the server on the page for each file.

Further resources are stored in /MinecraftResources. Loading /MinecraftResources provides an XML formatted list of resources, some of which are downloaded by Minecraft and not the launcher.

Keep-alive

Every 6000 ticks, the client sends an HTTPS request to

https://login.minecraft.net/session?name=<username>&session=<session id>

The client discards the server's response.

Snoop

Every 10 minutes, the minecraft sends a HTTP POST request giving stats. Note that this information is anonymous, and isn't tied to account names or server addresses

Client

The client posts the following data to http://snoop.minecraft.net/client

• version e.g. "1.2.5"
• os_name via System.getProperty("os.name");
• os_version via System.getProperty("os.version");
• os_architecture via System.getProperty("os.arch");
• memory_total via Runtime.getRuntime().totalMemory();
• memory_max via Runtime.getRuntime().maxMemory();
• java_version via System.getProperty("java.version");
• opengl_version via GL11.glGetString(GL_VERSION);
• opengl_vendor via GL11.glGetString(GL_VENDOR);

Server

Uses http://snoop.minecraft.net/server

• version as above
• os_name as above
• os_version as above
• os_architecture as above
• memory_total as above
• memory_max as above
• memory_free via Runtime.getRuntime().freeMemory();
• java_version as above
• cpu_cores via Runtime.getRuntime().availableProcessors();
• players_current
• players_max
• players_seen simply counts the number of files in world/players
• uses_auth corresponds to the online-mode option in server.properties
• server_brand: via MinecraftServer.getServerModName();. 'vanilla' by default; CraftBukkit et al overwrite this method.

Joining a Server

See Protocol Encryption for details on encrypting connections.

Client operation

1. Client connects to server
2. Client sends a 0x02 handshake containing the current player name
3. Client receives an 0xFD encryption request with the server's public key and four verification bytes.
4. Client generates a symmetric key.
5. Client sends a HTTP request to

   http://session.minecraft.net/game/joinserver.jsp?user=<username>&sessionId=<session id>&serverId=<server hash>

   If the response is OK then continue, otherwise stop

6. Client sends 0xFC encryption response - client encrypts shared secret and verification token with the server's public key
7. Server checks validity and sends 0xFC encryption response with two empty arrays
8. Both sides enable AES/CFB2 encryption using the shared secret generated by the client
9. Client sends 0xCD client status with a payload of 0 (ready to spawn)
10. Server sends 0x01 login
11. ... receive map chunks, etc...

Server operation

1. Server generates a 1024-bit RSA keypair.
2. ...
3. Server answers TCP connection request and receives a 0x02 handshake from the client.
4. Server sends 0xFD encryption request with its public key and a verification token.
5. Server receives 0xFC encryption response from client and decrypts the shared secret.
6. Server verifies the validity of the verification token. If this isn't verified, it kicks the client.
7. Server sends a HTTP request to

   http://session.minecraft.net/game/checkserver.jsp?user=<username>&serverId=<server hash>

   If it returns YES then the client is authenticated and allowed to join. Otherwise the client will/should be kicked with “Failed to verify username!”

8. Server sends a 0xFC encryption response packet with two empty arrays.
9. Both sides enable AES/CFB2 encryption.
10. Server receives 0xCD client status with a payload of , indicating "ready to spawn"
11. Server sends 0x01 login
12. ... send map chunks, etc...