Failed to catch the request

We often set the proxy in wifi Settings to our PC HTTP proxy software. In most cases, the traffic of the app we open at this time can be seen on the proxy software, such as Charles, Fiddler, etc. However, careful people will find that some of the requests of some big manufacturers’ apps are not caught on these HTTP proxy software, giving the impression that traffic is not going through the proxy software.

The reason for the request was not caught

We all know that THE HTTP protocol is TCP protocol, TCP protocol is built in the operating system, we can only use THE TCP protocol exposed socket interface to program, we are unable to modify the operating system itself of the TCP protocol implementation.

In other words, what kind of HTTP client you want to implement, how well it implements HTTP, how much it implements, and what details it supports are up to you. For example, the most famous okHTTP on Android is an IMPLEMENTATION of an HTTP client.

Since I implement it myself, I can say that I don’t need to use your proxy (or I didn’t implement the PROXY part of the HTTP protocol at all) even though your system has a proxy set up. This will naturally be like some apps in the big factory, although you set up the agent but you still can not capture the package.

Because the HTTP client ** doesn’t use the proxy ** you set up.

Look at the source code

To understand this, we look at the source code with a purpose is very simple.

First of all, okHTTP must have some implementation of HTTP proxy, otherwise we would not be able to use proxy to capture packets happily every day. So since there is a big factory app can not catch, then it must be some attributes set dynamically.

Notice the following code:

If I do that, you’ll notice that your app’s interface is missing.

Continue to look at the source code:

The comment is very clear, basically means that when you set this property, we will not use the system agent.

You have to write extra code if you don’t want to use a system agent. But flutter works the other way around. It doesn’t use a system agent by default.

Lass ProxyDio {// enter your proxy address static const _PROXY_IP_ADDRESS = "10.12.65.66"; Static const _PROXY_PORT_NUM = "5000"; static Dio getProxyDio() { var dio = Dio(); final adapter = dio.httpClientAdapter as DefaultHttpClientAdapter; Adapter. OnHttpClientCreate = (client) {/ / set the client proxy for the specified IP: port client. FindProxy = (uri) {/ / localProxyIPAddress and Return "PROXY "+ _PROXY_IP_ADDRESS + ":" + _PROXY_PORT_NUM; }; / / android machine above certificate authority: client badCertificateCallback = (cert, host, port) = > true; }; return dio; }}Copy the code

Special customized

After knowing the ins and outs of the matter, we still need to think about a question: why can’t some interfaces be caught while others can be caught in the big factory app? There are actually three reasons.

The HTTP protocol used by webView is obviously different from our OKHTTP protocol. The HTTP protocol stack used by WebView is implemented by C code by default, so it is difficult for us to interfere. From the test, the implementation of the HTTP protocol stack will use the default system proxy. I haven’t found the API to disable this function, if some friends have implemented it, please tell me

Second: You can use no_proxy for some sensitive interfaces and leave the rest of the interfaces intact.

In fact, okHTTP is so powerful that it can set up proxies differently for different interface addresses.

For example, this is similar to no_proxy

Look again at

The third: Even if you use no_proxy globally, there is usually more than one okHTTP client in your app, because there are other third-party libraries that have been introduced and their clients can still be captured if they do not use no_proxy.

Of course, this problem can be solved by directly modifying the bytecode using bytecode modification technology. Here is no more introduction, interested in their own implementation.

Is it true that no_proxy can not be caught?

Of course not, there are many ways to solve the problem. The simplest is to use drony software to simulate a VPN network. The principle is very simple: let traffic flow to the VPN, and then the VPN uses proxy by default.