statement
All the content in this article is only for learning and communication, the package capture content, sensitive URLs, data interfaces have been desensitized, and commercial use and illegal use are strictly prohibited, otherwise all the consequences arising therefrom have nothing to do with the author, if there is infringement, please contact me to delete immediately!
This article is prohibited from being reprinted without permission, prohibiting any secondary dissemination after modification, and any accident caused by the unauthorized use of the technology explained in this article, the author is not responsible, if there is infringement, please contact the author in the public account [K brother crawler] to delete immediately!
Reverse targeting
- Objective: Reverse analysis of a certain third-generation and fourth-generation one-click pass mode (non-inductive verification).
- Three generations homepage: aHR0cHM6Ly93d3cuZ2VldGVzdC5jb20vZGVtby9mdWxscGFnZS5odG1s
- Four generations homepage: aHR0cHM6Ly9ndDQuZ2VldGVzdC5jb20v
Communication process
Interface related:
Complete process:
Three generations of packet grabbing situation
register-fullpage returns challenge and gt values, which are useful later.
get.php will return c and s, also used later, this request also needs w value, in the click slider of a certain test, this request can not do without w value, but in the three generations of induction, it must be, otherwise the final verification will fail, may not have a w request, the returned s is a false value, resulting in the final verification failure.
Ajax.php Verification is successful, also requires a w value, and success returns a validate.
Three generations of reverse analysis
The first w value
I believe that I have read the previous slider and click articles of Brother K, and I am very proficient in locating the value of w, which is similar here, "\u0077" is "w", and its value is i + r, as shown in the following figure:
The main ones are the values of r, o, i, key code:
var r = t[$_CFAGw(1326)]()
, o = $_BFx()[$_CFAGw(1367)](pe[$_CFAFP(416)](t[$_CFAGw(353)]), t[$_CFAGw(1393)]())
, i = O[$_CFAGw(1375)](o) Let's take a look at r first, followed by the RSA we are familiar with, as in the previous process, you can withhold the code or use the library.
It should also be noted that this[$_CHCFe(1393)]() in the above figure is also a random string, which will be encountered many times, but the whole is the same value once verified, otherwise the verification will fail, and a series of clicks, sliders, etc. are the same.
Then there's the value of o, and here, as before, follow up to see if it's still AES encryption. t[$_CFAGw(1393)]() is still a random string.
The middle string of pe[$_CFAFP(416)](t[$_CFAGw(353)]), there is nothing special, except for gt and challenge, everything else is fixed, and the last string of i values, measured dead, empty.
Then continue to follow i, convert the value of the previous o into a large string, here is not very complicated, just buckle the code:
Then i + r is the value of w, and here the value of the first w is done.
The second w value
The value of the second w is different from the previous place, but it is also easy to find by following the stack, and there is a var n = {}; place, as shown in the image below:
t[$_CGABi(1436)] is the w value, that is, t['$_CEDO'], var t = this is defined earlier, after t[$_CGAAX(1462)]() in line 8215, there is a value of w, so follow up to focus on this line.
As shown in the figure above, E, T, N, R involves the calculation of some browser environment values, and of course, the calculation of mouse movements and other related data, as shown in the following figure:
And the actual test found that these four values can be directly empty, in this case can, I don't know if there are other cases where the verification is more stringent, friends who know can raise it in the comment area, and further down, you will encounter a lot of places to assign values to variables, as shown in the figure below, G is the MD5 method, the middle O[$_CGBFp(948)] is similar to before, returning the res and end in an object additive, I will not repeat it here.
i[$_CGBGa(1415)] Here is to add each variable and value one by one to form a large string.
Then to r, there is an additional captcha_token, and then all the packets are packed with {}.
Let's format this data, and the general structure is shown in the following figure:
Among them, ven and ren in ep are graphics card-related information, fp and lp are taken from the position information of the two mouse movements, and it is okay to write dead as null directly, and tm is some things in window.performance.timing, just fake it yourself.
The last step i[$_CGDBA(1436)], the random string is key, the previous data r is AES encrypted to get our final w value, as shown in the following figure:
Three generations of results verification
Four generations of bag grabbing
The load interface returns the following values:
- captcha_type: Captcha type, no sense is AI
- gct_path: gct4 file path
- lot_number: Key parameters that generate pow_msg, w
- payload: verify request parameters
- datetime: A date in ISO 8601 extended format, a key parameter that generates an pow_msg
- process_token: verify request parameters
The verify interface returns the following values:
- captcha_id: Captcha ID
- captcha_output: login request parameter
- gen_time: login request parameter
- lot_number: login request parameter
- pass_token: login request parameter
The login interface verifies that the login is successful:
Four generations of reverse analysis
w parameter
Like the third generation of inductive, the fourth generation of inductive w parameters can also be located by directly searching "\u0077", and r is the value of the w parameter:
The r parameter is defined on line 6237 and reads as follows:
(0,d[$_CBHHO(84)])(f[$_CBHIE(84)][$_CBHHO(562)](e), i)
d["default"])(f["default"]["stringify"](e), i) As can be seen from the above, r is obtained by encrypting the i parameter and the e parameter converted to a string, followed up in d[$_CBHHO(84)], the encryption function is defined on line 11669, broken at line 11707, and the return value is the value of the r parameter, that is, the w value:
(0,d[$_DIEHS(177)])(c) + u
d["arrayToHex")(c) + u Here is the R value obtained by converting the C array to a hexadecimal string and then adding U, followed by d[$_DIEHS(177)] to deduct it directly, C is defined in line 11705:
var c = s[a][$_DIEIq(1403)][$_DIEHS(1498)](e, i);
var c = s[1]["symmetrical"]["encrypt"](e, i); e Later analysis, i is a 16-bit string:
i is defined in line 11702, followed to the d[$_DIEIq(103)] method, where i is a 16-bit random number:
The e parameter reads as follows:
device_id, lot_number is returned by the load interface, pow_msg is "1|0|md5|" + datetime + "|" + captcha_id + "|" + lot_number + "||" + 16-bit random number, pow_msg MD5 encryption is pow_sign, "l0zs": "53502544" is a dynamically changing key-value pair, This has been described in detail in previous four generations of slider articles, followed in s[a][$_DIEIq(1403)][$_DIEHS(1498)], c for AES encryption, buckle code, or direct reference:
u is defined on line 11704, where i is a sixteen-bit random string:
u = new l[($_DIEHS(84))]()[$_DIEIq(1498)](i);
u = new l["default"]()["encrypt"](i); Follow up to the encryption function l[($_DIEHS(84))], on line 12725, hit a breakpoint on line 12741, you can see that here is an RSA encryption, buckle the code or directly quote the library: