Shulou(Shulou.com)06/01 Report--

Today, I will show you what to do when the crawler can't catch the APP request packet. The content of the article is good. Now I would like to share it with you. Friends who feel in need can understand it. I hope it will be helpful to you. Let's read it along with the editor's ideas.

The following content is to solve the problem that when APP does not use the HTTP client that comes with Android to make the request, and the code of the HTTP client is confused, which leads to the failure of the general tool JustTrustMe. And all the methods except JustTrustMe in the intermediate articles will be at a loss to deal with this situation, because the methods 1, 3 and 4 in the intermediate articles are essentially aimed at the SSL Pinning scheme added by the Android 7.0 + system, and can not be effective for the detection scheme implemented by each HTTP client. (I heard that there is an APP called Speed shooting that is of this type.)

So what should be done to catch this kind of APP bag? Quite simply, it would be nice to still use Hook tools like JustTrustMe, but we need to do special handling of the original Hook part for the confused name.

Here I specially wrote a sample APP to demonstrate (don't arrest me, I don't know anything). What this APP does is to launch a request to Baidu's home page after you click the button, but this request cannot succeed without cracking SSL Pinning, because I set up a certificate hash that I enter casually. Therefore, the request will fail because the normal certificate hash is different from the hash I randomly enter.

Cdn.nlark.com/yuque/0/2020/png/97322/1607218800977-f5885f4d-db66-425c-a32d-65b7fc100bcb.png ">

Sample APP code

I have compiled this APP and put it on GitHub. There are two versions, one is to confuse the code, the other is not to be confused. There will be a download address at the end of the article, which readers can download and play with.

Two compiled APK

Let's talk about the configuration of the test machine before we start the demonstration. The test machine used here is Android 8.1.0, has been Root+Xposed, and JustTrustMe has been installed and activated.

Tester system information

Xposed module management interface-JustTrustMe is enabled

Let's take a look at the unconfused version of the code, install it, open it, and then click the "Click to send request" button.

Sample APP interface

If nothing happens, the message will appear that the request was successful. If the request fails, it may be your network problem, and the certificate problem will prompt "Certificate verification failed".

Next, let's take a look at the version of the code that has been confused, the operation is the same as above.

Certificate verification failed

This time, the certificate verification failed, and the JustTrustMe did not work properly.

Let's decompile both of these APK into Jadx.

Decompile two sample APK in Jadx

You can see that in the confused version, all the class names under okhttp3 have become names like abcd.

Then let's take a look at the JustTrustMe code.

The certificate verification part of Hook okhttp3 in JustTrustMe code

You can see that its code is to Hook the check method under the okhttp3.CertificatePinner class, and this CertificatePinner class and the check method can be clearly seen in the unconfused APK.

Decompilation detection code 1

Decompilation detection code 2

So now the reason why JustTrustMe is invalid in the face of confusion is very clear, because it can not find the okhttp3.CertificatePinner.check, so it is impossible to Hook the detection method, naturally it will not have any effect.

So... What should I do? Here are still a variety of ways for readers to choose from:

1. Modify the class name and method name of Hook in the JustTrustMe code, and then recompile

It's simple to find the corresponding detection method and change the className and methodName of Hook in JustTrustMe code to confused names. For example, in this confused sample APP, okhttp3.CertificatePinner.check becomes okhttp3.f.a.

Decompilation detection code-after confusion

We modify the Hook part of JustTrustMe to f and an as well.

JustTrustMe detects Hook for okhttp3's certificate

Modify the certificate detection Hook of JustTrustMe to okhttp3

After the modification, compile it and install it on the phone to replace the original one.

2. Use Frida for Hook

This method is more convenient and straightforward than method 1, because it can be used immediately to modify the script directly when needed. There is no need to recompile or restart the phone or APP. Here, you can directly modify the script written by the skinny dance boss to remove SSL Pinning. It is also to modify the part of Hook okhttp3.CertificatePinner.check and change it to the name after confusion.

Modify the ObjectionUnpinningPlus script of the thin jiao dance

3. Change JustTrustMe to add a function that can adjust the class name and method name of the SSL Pinning detection part of each HTTP client according to the situation at run time

I don't have time to do this for the time being. Interested students can do it on their own.

4. Change JustTrustMe to add dynamic adaptation to Hook, so that even if developers confuse the code, they can automatically find real detection classes and methods.

As above, the implementation can refer to the automatic adaptation code of the Wechat wizard framework, which is theoretically one of the most convenient ways after implementation, because it is a completely automatic operation and does not require human intervention.

5. Modify the code obtained from decompiling APP and package it back.

I don't think anyone would do it in such a stupid way. It's much more convenient to do it in the Hook way.

After choosing any method to operate, you can open the confused version of APP and then you can make a normal request.

At this time, some students may want to ask, how to know which HTTP client APP uses? And how to quickly locate the location of the confused detection method?

Quite simply, let's turn off the cracking tool, connect to the agent, and then grab a package to see the request for a confused version of APP.

Request for packet capture and inspection

User-Agent part

As in the case of SSL Pinning, only one CONNECT request will be caught here. Pay attention to the headers on the right. You can see from the User-Agent that this APP uses okhttp3, so when we locate and detect part of the code in the confused code, we just need to find it against the original code of okhttp3 (the same is true for other HTTP clients). Of course, it does not rule out that some APP will change the User-Agent. If you can't see it on the User-Agent, take a look at the decompiled part of the source code structure to see if there is a particularly obvious HTTP client name like okhttp3, and if so, just kill it.

The above is the whole content of how to solve when the crawler can't catch the APP request package, and more about how to solve the problem when the crawler can't catch the APP request packet. You can search the previous articles or browse the following articles to learn! I believe the editor will add more knowledge to you. I hope you can support it!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.