2.OSI 7层网络模型

1.前言

本文将从网络通信原理浅析在android中出现的一些代理转发检测，这些功能会使我们测试app时出现抓不到包或者应用闪退等情况，针对这种场景，我搭建了测试环境，并对其场景展开分析与实施应对方案。

2.OSI 7层网络模型

网络通信嘛，首先得知道什么是OSI 7层模型。下面是百度的解释：

使用网络数据的传输离不开网络协议七层模型，通过理解每一层协议的分工，也就能对网络故障逐一排查，这样的思维逻辑在安卓应用中也同样适用。

OSI 7层模型各层功能及对应的协议、设备如下表所示：

HTTP+SSL

根据上表可知，SSL做数据加密是在表示层，也就是说，HTTPS实际上是建立在SSL之上的HTTP协议，而普通的HTTP协议是建立在TCP协议之上的。所以，当HTTPS访问URL时，由于URL在网络传送过程中最后是处于HTTP协议数据报头中，而HTTP协议位于SSL的上层，所以凡是HTTP协议所负责传输的数据就全部被加密了；但是IP地址并没加密，因为处理IP地址的协议（网络层）位于处理SSL协议（表示层）的下方。

自下而上

接下来，我们再理解一下代理与VPN。

3.代理与VPN

3.1、代理

代理（proxy） 也称网络代理，是一种特殊的网络服务，允许一个终端（一般为客户端）通过这个服务与另外一个终端（一般为服务器）进行非直接的连接。

完整的代理请求过程

3.2、VPN

VPN（virtual private network）（虚拟专用网络 ）是常用于连接中、大型企业或团体间私人网络的通讯方法。它利用隧道协议（Tunneling Protocol）来达到发送端认证、消息保密与准确性等功能。

3.3、代理和VPN的区别

从各自的定义，我们就能看出VPN的特点是采取隧道协议进行数据传输和保护；而代理使用的则是对应的代理协议。

下面是VPN和代理的常用协议：

VPN 协议大多是作用在 OSI 的第二层和第三层之间，所以使用 VPN 时，几乎能转发所有的流量。

而代理协议多作用在应用层，最高层。

4.安卓代理检测

知道了代理与VPN的作用后，在APP中，如果开发人员在代码中添加了一些网络层的检测机制，而这些机制恰恰又是针对工作层协议进行的检测，那么只要分析出工作在IOS的哪一层，抢先一步在下层做出应对，那APP在上层无论怎么检测，都没有用。下面将对测试场景进行详细分析。

抓包的步骤：

1.在客户端（手机）中设置代理服务器的地址

2.开启代理服务器（burp）的代理功能

如果在客户端对代理服务进行过滤，禁止客户端通过代理服务器进行访问Internet，添加如下代码：

官方对于Proxy.NO_PROXY的描述如下：

NO_PROXY实际上就是type属性为DIRECT的一个Proxy对象，这个type有三种：

• DIRECT
• HTTP
• SOCKS

所以，Proxy.NO_PROXY的意思是connection的请求是直连。

此时若通过系统进行代理，app对外请求会失效，也就是视觉上看到的卡死状态，就是不让走系统代理。

安卓手机上设置系统代理即是在【设置】-【WLAN】-【修改网络】手动设置代理。

针对不走系统代理的情况有如下两种应对：

VPNPostern

iptablesProxyDroid

对此，我做出了如下一些测试：

4.1、使用系统代理

APP关键代码如下：

针对Proxy.NO_PROXY，先测试一下，系统代理是否真的不能抓包。

如下图先设置系统代理，burp监听8888，此时打开APP，点击发送请求无任何反应，burp中也抓不到包，说明系统代理被禁了。

4.2、使用Postern代理

钥匙

同样的APP，点击请求，此时成功绕过了Proxy.NO_PROXY检测！也说明了VPN协议在HTTP协议的下层。

5.安卓VPN检测

VPN也是代理的一种，但是由于通讯协议的差异，所以检测代码也不一样。

VPN虚拟隧道协议创建tun0ppp0

下面这段代码的检测方式：出现特征tun0或者ppp0则退出应用，也就是我们看到的闪退效果。

在点击监听中放置isDeviceInVPN()功能，点击即触发，如果检测到了使用了VPN则直接退出。

5.1、使用ProxyDroid代理

当前场景：APP同时开启了代理检测以及VPN检测

这时使用iptables进行数据转发的软件 ProxyDroid 进行测试，配置如下图所示：

开启之后，系统状态栏不会出现钥匙的形状，这时再次进行抓包测试。

burp成功获取到了请求，至此代理与VPN的应对方法均已实现。所以，iptables 竟然能从OSI的 2、3层下面走吗，下面我们继续分析。

6.iptables原理

我们都知道安卓使用的是linux内核，而linux内核提供的防火墙工具是Netfilter/Iptables。

Netfilter是由linux内核集成的IP数据包过滤系统，其工作在内核内部，而Iptables则是让用户定义规则集的表结构。

也就是，iptables是一个命令行工具，位于用户空间，它真正操作的框架实现在内核当中。

网络地址转换数据包内容修改数据包过滤

Iptables主要工作在OSI七层的2.3.4层，好像也没比VPN的工作协议低，反而还有高的，但是测试结果证明，是我想错了，iptables不是由于协议低，而是没有出现tun0或者ppp0这两个关键的网卡特征，所以成功绕过了VPN的检测。

透明代理

由此，延伸了一个新的代理模式，通过burp进行“透明代理”，网上的教程错综复杂，亲测使用过程如下。

7.透明代理

感觉不到代理的存在

接下来我将尝试：结合安卓端的透明代理技术与burp存在的invisible模式

7.1、使用Burp透明代理

（1）安卓端设置

首先在设备上手动进行设置：将所以请求80、443端口的tcp流量进行nat转发到192.168.50.177（burp的监听地址）的对应端口上

查看当前规则是否成功添加

（2）代理服务器端设置

添加80和443的端口监听

在【Binding】中设置端口，选中 【All interfaces】

并对【Request handing】做出如下设置

Redirect to port - 如果配置了这个选项，Burp会在每次请求转发到指定的端口，而不必受限于浏览器所请求的目标。

Force use of SSL - 如果配置了这个选项，Burp会使用HTTPS在所有向外的连接，即使传入的请求中使用普通的HTTP。您可以使用此选项，在与SSL相关的响应修改选项结合，开展sslstrip般的攻击使用Burp，其中，强制执行HTTPS的应用程序可以降级为普通的HTTP的受害用户的流量在不知不觉中通过BurpProxy代理。

设置之后，Proxy状态如下

此时burp就可对转发到这里的80和443端口的流量进行透明代理

注意：如果出现443端口被占用，查找进程kill掉即可。

以管理员身份运行 cmd 执行如下代码

经过测试，burp成功抓取到了请求包。

这里不禁思考，如果是基于iptables进行的数据转发，那么刚才的ProxyDroid是否也内置了一些路由规则呢？

查看一下开启ProxyDroid时iptables当下的规则

从图中可以看到共有六条策略，其中最后两条就是我们刚才手动添加的，但并没有看到burp监听的8888端口，8123、8124一定是软件内置的代理转发端口，想要知道具体原理还需要详细分析ProxyDroid的源码。

血泪避坑：网上出现了很多教程，最关键的iptables规则写法不一，导致多次测试结果并不成功，如果将安卓终端的80和443端口同时转发到burp上监听的唯一一个端口则会出现连接错误。根据burp官方文档说明为每个端口号设置监听器会更加稳定，也就是要设置两个代理监听。

8.总结

根据不同的代码检测，也会有不同的应对方法，所以，遇到APP出现抓包闪退等问题，先逆向，查看源码，在通信处仔细进行分析，再针对检测代码进行绕过，才是正解。本文提到的并不是固定的处理方法，如果文章有叙述不当，尽请矫正。

9.参考链接