Thoughts on Minecraft account cracking
After a few years of not using it, I went back to a Minecraft account cracker that I coded a long time ago, reworked it, and was revisited by some interesting thoughts while doing so.
The first has to do with authentication requests. In short, when you submit an authentication request to the Mojang servers, you can receive one of four responses, assuming everything has gone correctly
1. HTTP code 200
Successful authentication.
You can also check the JSON data, but that's a bit redundant, and it's marginally faster to just check for a code 200.
HTTP code 403
Unsuccessful authentication. There are three different error codes which give you information about why authentication failed.
2. JSON response key ["errorMessage"] == "Invalid credentials. Invalid username or password."
Self-explanatory. You've got your username or password wrong.
3. JSON response key ["errorMessage"] == "Invalid credentials. Account migrated, use e-mail as username."
Also self-explanatory. The account has been migrated and you can't login with that username anymore.
4. JSON response key ["errorMessage"] == "Invalid credentials."
It's this last response I'd like to discuss.
First of all, this last error message is interesting because it doesn't show up in the protocol documentation detailed here:
http:\\wiki,vg\Authentication#Errors
Second of all, you CAN get this error when logging in with correct credentials.
After running some tests, it became apparent that this response is used when the server has detected that too many requests are being sent too quickly. In other words, rate limiting.
Trial 1 shows the result of sending 25 authentication requests in immediate succession:
This is substantiated by:
http:\\wiki,vg\Mojang_API - "All public APIs are rate limited..."
Now, one thing which is crucial to know is whether the rate limiting is per-IP or per-account.
Trial 2 shows the result of sending 25 auth requests to one account, then 25 auth requests to another.
It appears, then, that rate limiting is on a per-account basis.
I wanted to confirm this, so I ran another test.
Trial 3 shows the result of sending 25 auth requests to an account, then 25 auth requests to the same account, through a proxy. The proxy is elite, with a ping of ~35ms.
As you can see, despite routing some of my requests through a proxy, rate limiting kicks in anyways.
I also noticed something interesting after conducting an extended test. It seemed that the server still lets requests through occasionally, even when an account is rate limited.
Trial 4 shows 100 requests, with time data since the last successful authentication, in addition to the request number. Let's see what we find.
Interesting. Every three seconds, a request slips through.
At this point, I began conducting more and more elaborate tests, and I will stop showing the console output, but will instead plot my data.
Avg time between requests - number of requests before rate limiting
0.19 - 20 (Ping delay only)
0.97 - 20 (Delay tuned to ~1s)
1.98 - 20 (Delay tuned to ~2s)
2.99 - 20 (Delay tuned to ~3s)
3.10 - >100 (Delay tuned to ~3.1s)
4.01 - >100 (Delay tuned to ~4s)
It seems that for continuous bruteforcing, per account, you cannot exceed 3 seconds/request without having rate limiting imposed after about 20 requests.
Perhaps this has something to do with the interesting slipped requests I mentioned above?
At this point, we're really just trying to reconstruct the authentication server's internal rate-limiting logic, and I'm sure it's quite complicated, with varying levels of rate limiting, and perhaps IP-based limiting if you really overdo it.
I think I'll stop my investigation here.
It's worrying to me that some account checkers or crackers may not take these false negatives into account.
I suspect this because with some popular other cracking software, I get >20 responses/second, whereas my own software hovers around 5, with the same proxy lists and thread counts.
However, when I turn off false negative detection in my script, the response rate skyrockets up to >20 responses/second again.
Gonna be using my own software from here on out.
Summary:
*Some replies returned by the authentication servers are false negatives, but this is detectable
*These false responses only occur after exceeding the limit of 1/3 requests/second (This is an educated guess)
*Popular cracking software may not be taking this into account, meaning you may not get as many alts as you should
*This rate limiting is on a per-account basis
Please comment with your own knowledge/ideas! I'm sure many of you know more about this type of thing than I.
The first has to do with authentication requests. In short, when you submit an authentication request to the Mojang servers, you can receive one of four responses, assuming everything has gone correctly
1. HTTP code 200
Successful authentication.
You can also check the JSON data, but that's a bit redundant, and it's marginally faster to just check for a code 200.
HTTP code 403
Unsuccessful authentication. There are three different error codes which give you information about why authentication failed.
2. JSON response key ["errorMessage"] == "Invalid credentials. Invalid username or password."
Self-explanatory. You've got your username or password wrong.
3. JSON response key ["errorMessage"] == "Invalid credentials. Account migrated, use e-mail as username."
Also self-explanatory. The account has been migrated and you can't login with that username anymore.
4. JSON response key ["errorMessage"] == "Invalid credentials."
It's this last response I'd like to discuss.
First of all, this last error message is interesting because it doesn't show up in the protocol documentation detailed here:
http:\\wiki,vg\Authentication#Errors
Second of all, you CAN get this error when logging in with correct credentials.
After running some tests, it became apparent that this response is used when the server has detected that too many requests are being sent too quickly. In other words, rate limiting.
Trial 1 shows the result of sending 25 authentication requests in immediate succession:
Code:
Request 1: Successful authentication. Request 2: Successful authentication. <//> Request 19: Successful authentication. Request 20: Successful authentication. Request 21: Invalid credentials. Request 22: Invalid credentials. Request 23: Invalid credentials. Request 24: Invalid credentials. Request 25: Invalid credentials.
http:\\wiki,vg\Mojang_API - "All public APIs are rate limited..."
Now, one thing which is crucial to know is whether the rate limiting is per-IP or per-account.
Trial 2 shows the result of sending 25 auth requests to one account, then 25 auth requests to another.
Code:
Request 1: Successful authentication. Request 2: Successful authentication. <//> Request 19: Successful authentication. Request 20: Successful authentication. Request 21: Invalid credentials. Request 22: Invalid credentials. Request 23: Invalid credentials. Request 24: Invalid credentials. Request 25: Invalid credentials. Request 26: Successful authentication. Request 27: Successful authentication. <//> Request 44: Successful authentication. Request 45: Successful authentication. Request 46: Invalid credentials. Request 47: Invalid credentials. Request 48: Invalid credentials. Request 49: Invalid credentials. Request 50: Invalid credentials.
I wanted to confirm this, so I ran another test.
Trial 3 shows the result of sending 25 auth requests to an account, then 25 auth requests to the same account, through a proxy. The proxy is elite, with a ping of ~35ms.
Code:
Request 1: Successful authentication. Request 2: Successful authentication. <//> Request 19: Successful authentication. Request 20: Successful authentication. Request 21: Invalid credentials. Request 22: Invalid credentials. Request 23: Invalid credentials. Request 24: Invalid credentials. Request 25: Invalid credentials. Request 26: Invalid credentials. Request 27: Invalid credentials. <//> Request 49: Invalid credentials. Request 50: Invalid credentials.
I also noticed something interesting after conducting an extended test. It seemed that the server still lets requests through occasionally, even when an account is rate limited.
Trial 4 shows 100 requests, with time data since the last successful authentication, in addition to the request number. Let's see what we find.
Code:
Request 1: Successful authentication. 0.000000 seconds since last successful authentication. Request 2: Successful authentication. 0.151009 seconds since last successful authentication. <//> Request 19: Successful authentication. 0.152009 seconds since last successful authentication. Request 20: Successful authentication. 0.161009 seconds since last successful authentication. Request 21: Invalid credentials. 0.136008 seconds since last successful authentication. Request 22: Invalid credentials. 0.293016 seconds since last successful authentication. <//> Request 39: Invalid credentials. 2.805160 seconds since last successful authentication. Request 40: Invalid credentials. 2.943168 seconds since last successful authentication. Request 41: Successful authentication. 3.118178 seconds since last successful authentication. Request 42: Invalid credentials. 0.142008 seconds since last successful authentication. Request 43: Invalid credentials. 0.283016 seconds since last successful authentication. <//> Request 61: Invalid credentials. 2.815161 seconds since last successful authentication. Request 62: Invalid credentials. 2.953169 seconds since last successful authentication. Request 63: Successful authentication. 3.126179 seconds since last successful authentication. Request 64: Invalid credentials. 0.154009 seconds since last successful authentication. Request 65: Invalid credentials. 0.299017 seconds since last successful authentication. <//> Request 81: Invalid credentials. 2.722156 seconds since last successful authentication. Request 82: Invalid credentials. 2.872164 seconds since last successful authentication. Request 83: Successful authentication. 3.023173 seconds since last successful authentication. Request 84: Invalid credentials. 0.131007 seconds since last successful authentication. Request 85: Invalid credentials. 0.261015 seconds since last successful authentication. <//> Request 98: Invalid credentials. 2.064118 seconds since last successful authentication. Request 99: Invalid credentials. 2.194125 seconds since last successful authentication. Request 100: Invalid credentials. 2.339134 seconds since last successful authentication.
At this point, I began conducting more and more elaborate tests, and I will stop showing the console output, but will instead plot my data.
Avg time between requests - number of requests before rate limiting
0.19 - 20 (Ping delay only)
0.97 - 20 (Delay tuned to ~1s)
1.98 - 20 (Delay tuned to ~2s)
2.99 - 20 (Delay tuned to ~3s)
3.10 - >100 (Delay tuned to ~3.1s)
4.01 - >100 (Delay tuned to ~4s)
It seems that for continuous bruteforcing, per account, you cannot exceed 3 seconds/request without having rate limiting imposed after about 20 requests.
Perhaps this has something to do with the interesting slipped requests I mentioned above?
At this point, we're really just trying to reconstruct the authentication server's internal rate-limiting logic, and I'm sure it's quite complicated, with varying levels of rate limiting, and perhaps IP-based limiting if you really overdo it.
I think I'll stop my investigation here.
It's worrying to me that some account checkers or crackers may not take these false negatives into account.
I suspect this because with some popular other cracking software, I get >20 responses/second, whereas my own software hovers around 5, with the same proxy lists and thread counts.
However, when I turn off false negative detection in my script, the response rate skyrockets up to >20 responses/second again.
Gonna be using my own software from here on out.
Summary:
*Some replies returned by the authentication servers are false negatives, but this is detectable
*These false responses only occur after exceeding the limit of 1/3 requests/second (This is an educated guess)
*Popular cracking software may not be taking this into account, meaning you may not get as many alts as you should
*This rate limiting is on a per-account basis
Please comment with your own knowledge/ideas! I'm sure many of you know more about this type of thing than I.
!
Originally Posted by 00Pokemon00
