Special Statement
All content in this article is for learning and communication purposes only and cannot be used for any commercial or illegal purposes. Otherwise, the consequences are at your own risk. If there is any infringement, please contact the author for immediate deletion! Due to my limited ability, if there are any inaccuracies in understanding or description, I hope the experts can provide guidance!
Reverse Engineering Target
- URL:
<span>aHR0cHM6Ly9ndDQuZ2VldGVzdC5jb20vCiA=</span> - Interface Information:
<span>'./load' (Image link return interface), './verify' (Verification interface)</span> - Reverse Engineering Parameters:
<span>Value of w in params</span>
Since the length of this parameter w is too short to perform search positioning, and both interfaces are of type <span>script</span>, they cannot be hooked, so I chose to follow the stack.
At this point, we find that the w value consists of two parts: one is <span>(0,_ᕾᖉᕾᖄ[_ᕺᕸᕶᕿ(38)])(u)</span>, and the other is <span>_</span>. Therefore, we need to follow the values of <span>u</span> and <span>_</span>.
Then looking up the code, I found a surprise. Through debugging, I discovered that the generation of <span>u</span> and <span>_</span> uses functions from object 1 or object 2. Then looking at object 2, it directly provides a standard AES format (I can only say that this obfuscation is poorly done). So it is highly likely that the function from object 2 is used. If you are not sure, you can set breakpoints in both places and find that it indeed calls the method from object 2.
Next, we write an AES algorithm locally, extract a set of parameters from the browser for encryption, and through comparison, we find that the earlier part of the w value is indeed an AES encryption. Next, we need to analyze these two encrypted strings.
<span>_ᕹᖙᖃᕶ</span> This 16-character string is not only used for AES encryption but also participates in the encryption process of <span>_</span>. Looking up, it is obtained from the execution of <span>(0,_ᕾᖉᕾᖄ[_ᕿᕵᕾᖈ(70)])()</span>, so we need to follow it in.
Following in, I found that this string is formed by executing the <span>e</span> function four times and then concatenating, so we only need to restore the logic of the e function:
Although jy does not verify this value, we can still extract it as practice.
Next, we need to handle the variable <span>_ᖄᕸᖚᖆ</span>. It can be seen that it is an object formed after <span>JSON.stringify</span>. We need to capture and compare data multiple times to find out where this parameter needs to be reversed. After comparison, we find that the following values are changing:
1.setLeft: Distance the slider moves
2.userresponse: Time taken to slide the slider
3.lot_number: Returned by load interface
4.pow_msg: Formed by concatenating multiple values
5.pow_sign: md5(pow_msg)
6."395e0a4d": {"8b3b": "e0a4"} : This object is actually not verified (at first I thought this was generated by the trajectory, but it is not; this is obtained by slicing the lot_number)
Next, analyze <span>pow_msg</span>:
"pow_msg": "1|0|md5|
2025-03-28T22:09:27.719660+08:00| (ISO 8601 standard timestamp format)
54088bb07d2df3c46b79f80300b0abbe| (captcha_id, found to be fixed in global search)
830080395e0a4d98b4170776b3a1c7d6|| (lot_number)
e379ee76d49bb435" (16-character hexadecimal random string, consistent with the function that generates the key, but not the same result. I haven't tested whether it can pass with the same key; if interested, you can test it.)
At this point, the first part of the w value has been analyzed. Next is the analysis of the generation of the <span>_</span> value, similar to the previous analysis of the AES encryption method:
It is found that the encryption function of this <span>_</span> variable is in object 1, and then looking in, I found <span>setPublic</span>, so I copied its public key and wrote the RSA algorithm locally. At this point, the encryption process of jy4 has been fully analyzed. Because the result of RSA encryption cannot be fixed, it can only be confirmed through requests whether the algorithm we deduced is correct.
Finally, here is the result image
Verification was successfully completed in a simple manner. (Many may wonder why jy3 has trajectory verification while jy4 does not. I actually don’t know; I haven’t done jy3. It is also possible that this type of verification code does not have trajectory verification. Finally, I want to clarify that this interface indeed does not have trajectory verification.)
