Written on the front I learn penetration testing, mainly Web direction in a few months, and now was just getting started. Recall that learning vulnerability discovery process, in addition to watching some of the classic books, the most want to see is a large cattle were dug vulnerability of the process in detail, such as how to find the target, from where to start, encountered a problem how to solve it. However, the online description of the knowledge, the narrative process is less, and possibly my search for a posture wrong......in. In addition to the in the clouds on a few I will sometimes share some of the specific dig through the ideas, most people still“have to figure there is Truth, a picture is worth a thousand words”. For older drivers, scan at a glance know what is going on, but for the uninitiated, is often confused. Therefore, I share with you a recent dig through the process, hope to be able to initiate, you are encouraged to share their dig experience. PS: as an ethical white hat, this article focuses on sharing ideas and process, the details still have to be coding processing, after all, not to submit vulnerabilities. Find the target This is for the I used a mobile APP, hereinafter referred to as: a APP for vulnerability discovery, speaking to select an APP as the target is also quite accidental. Because I mostly doing Web penetration tests, and do not have to dig through the phone APP vulnerabilities. One day, in watching others share the Burp Suite using tips in the article, found by Burp can also be carried out mobile APP capture（after all Too young......in. Just say it false skill, or want to do-it-yourself practice a lot. The first Burp set out in the Proxy in the Options under Proxy Listeners, click on Edit, put the Bind to address is set to All interfaces. ! Then the phone and computer in the same LAN, give the phone to set up a proxy server, the IP is the computer IP address, the port for the Burp in the settings of the port, the default is 8 0 to 8 0 to. This time, you can use Burp to grab the phone of the request packet. Mountain heavy water complex This time I will open an APP, perform the common operation, the Burp is recorded a large number of HTTP data packets. Then, just for Burp intercepting the packets for analysis. Not long, one request caught my attention. This is a GET request, the request URL is like the following this format: 1 http://www.example.com/path/get_some_data.jsp?id=1234567¶m1=value1¶m2=value2 Intuition tells me, here is likely there will be ultra vires vulnerability. Thus, I use browser to open this URL, it really directly see the user data. Change the id try again, the id is incremented by 1, The result is the same, all broke the user data. Therefore, here has determined that a certain APP exists override the vulnerability. Determine the ultra vires vulnerability exists after slightly calm down about the mood, and then I found this vulnerability to cause the consequences are not serious. Because here through the account override view to the user data, and does not contain some of the more sensitive data, such as name, phone number, ID, etc. Simply put, is that you can override the view to the others data, but the“others”who do not know, so to say see that the data is just a bunch of meaningless numbers only. Only caught a small fish somewhat reconciled, so he continued to dig, it should be there are other vulnerabilities exist. Continue to view Burp to capture the packets, this time focus on the login process, submit the request and return the response from here start to dig deeper. Login packets are as follows, You can see, only one POST parameter params, the value after URL encoding. ! The params value after decoding, the Found is the json format string of data, the basic content is as follows: ! Wherein, let a person of interest is the userId field and the body field, the Visual should be respectively corresponding to the login user name and password. Then I use the same username and a different password, different username and the same password are the login, capture, and then decoding the comparison found that the same name corresponding to the userId value is the same, the same password corresponding to the body value is also the same, which confirmed my speculation. Further analysis found that the userId and the body value is a hexadecimal numeric string, userId length is 3 2 here refers to the 3 2 hexadecimal characters, following the same, the body length is 1 2 8-bit. This illustrates the userId and the body of values through the encryption process. For the userId, my first thought is not through the MD5 for? But after the calculations the user name of the MD5 and userId is not equal, that is to say, even if is MD5 also added salt. Analysis to here, temporarily no way to continue in-depth. It first put a put, analyze the login process is returned in the data packet, the following figure is the login after a successful return of the data packet. ! A look at the returned data packet directly dumbfounded, the clear is encrypted. However, here still want to pay attention to what the return data package length, because I deliberately enter the wrong password when logging in, as illustrated below, the returned data packet length is actually a difference of no! And also be able to see, there are many of the same characters. Obviously, there are likely to be problematic. ! The trick So far, although the login process in the request packet the structure of the analysis clear, but since the packet of the key data are subjected to encryption processing, it is now almost still is helpless. In fact I'm here card a couple of days, but also nothing good way, even the thought of analyzing what others account to log process data packets and then crack the password idea. However carefully one would like to think this idea is too unrealistic, and not a cryptography expert, only by a few of the ciphertext you want to hack the encryption process, how is it possible to succeed! Although the idea is a bit absurd, but also really brought me inspiration: since some APP to send the packets and the return packets are encrypted, it is certainly in the certain APP for the encryption and decryption operations, so if we can analyze an APP's source code, should be able to figure out where the encryption and decryption process. So the question is, where can get a certain APP source code? Thought to want to go, the most convenient, the most likely way is an APP decompile to get the source code. the ios version of I don't want to, after all didn't engage in ios development, Go directly to the reverse is certainly not realistic. But the Android version still has to engage the head, because before seen someone for APK the reverse of the article, also wrote the Java code. Went online to search a search Android reverse tutorial a large heap, after all we just want to analyze the source code, not to engage in shelling crack, entry-level tutorial will be able to meet the requirements, there is not much to say. In short, an APP decompile after that, find the code for the confusion, but does not affect the analysis, slightly fee to the point of stiffness. After analysis, really to have the harvest.