随着WiFi的普及,移动运营商的热点也越来越多了,如中国移动的CMCC、中国电信的ChinaNet、中国联通的ChinaUnicom等,一般来说,连上此类的热点,打开浏览器上网时都会自动跳转到一个验证页面,最近有个项目也有类似的需求,Android手机自建热点,别的手机wifi连接此热点,打开浏览器,输入任意内容,自动跳转到一个下载列表页面,点击相应的链接即可下载相应的文件。

分析

考虑如下几种情况: - 浏览器输入IP地址,请求对应IP地址的80端口的内容 - 浏览器输入域名,先进行DNS解析域名,得到IP地址后,请求对应的80端口的内容 - 浏览器输入任意字符,一般浏览器内部设置一个默认的搜索引擎,此时地址栏的内容会作为搜索的关键字,加在搜索的url中

因此,需要解决如下问题: - 端口报文转发 - DNS报文拦截 - url重定向

端口报文转发

Android系统本身是Linux内核,1024以下端口都名花有主,如http是80,https是443,dns是53,对于这些1024以下端口的绑定需要root权限,但一般的App是没有root权限的,除非在 AndroidManifest.xml 文件中声明 android:sharedUserId=“android.uid.system”,并使用密钥文件进行签名:

java -jar signapk.jar platform.x509.pem platform.pk8 your.apk your_signed.apk

但问题是密钥文件属于手机厂商,显然不可能拿到这个密钥文件,当然,如果在模拟器里测试倒是可以的,从android源代码 build/target/product/security 里找到密钥文件,platform.pk8 和 platform.x509.pem,签名工具 signapk.jar 在 build/tools/signapk 下。

基于以上原因,一般Web服务器都绑定8080端口,手机浏览器如果输入IP地址,会访问Web服务器的80端口,这样就需要进行端口报文转发,对应dns报文拦截,无法监听53端口,同样需要端口转发,此外,浏览器的搜索引擎如果是google的话,使用https,同样也有这个问题。

iptables是个很好的防火墙管理工具,这里需要做如下配置:

iptables -t nat -A PREROUTING -d 0.0.0.0/0 -p tcp --dport 80 -j DNAT --to 192.168.43.1:8080
iptables -t nat -A PREROUTING -d 0.0.0.0/0 -p tcp --dport 443 -j DNAT --to 192.168.43.1:8443
iptables -t nat -A PREROUTING -d 0.0.0.0/0 -p udp --dport 53 -j DNAT --to 192.168.43.1:53530

说明:-t nat:指定nat表,-A:添加,PREROUTING:路由前处理,-d 0.0.0.0/0:任意目的地IP,-p tcp:协议,–dport 80:端口,-j DNAT:地址映射跳转,–to 192.168.43.1:8080:转发目的地,总的意思就是,到达防火墙的报文,不管去往那个IP地址,只要是发往80端口的tcp包,都转发到192.168.43.1的8080端口。剩下两条意思类似。

需要注意的是: 1、如果是App中的java代码调用,需要root权限,一般这么写:

String shell = "su -c iptables -t nat -A PREROUTING -d 0.0.0.0/0 -p tcp --dport 80 -j DNAT --to 192.168.43.1:8080";
Runtime.getRuntime().exec(shell);

2、Android手机设置为热点模式时,IP地址一般都会固定成192.168.43.1,这是由手机的dhcpcd服务指定的,一般不会去改dhcpcd服务的源代码然后重新编译,但这种写死的做法显然是不太合适的,通用的做法是自动取Ap的IP地址:


    public static String getNetworkIpAddress(String name) {
        try {
            Enumeration<NetworkInterface> interfaces = NetworkInterface.getNetworkInterfaces();
            while (interfaces.hasMoreElements()) {
                NetworkInterface networkInterface = (NetworkInterface) interfaces.nextElement();
                Enumeration<InetAddress> enumeration = networkInterface.getInetAddresses();
                while (enumeration.hasMoreElements()) {
                    InetAddress inetAddress = (InetAddress) enumeration.nextElement();
                    if (!inetAddress.isLoopbackAddress()
                            && inetAddress instanceof Inet4Address
                            && TextUtils.equals(name, networkInterface.getDisplayName())){
                        return inetAddress.getHostAddress().toString();
                    }
                }
            }
        } catch (Exception e) {
            e.printStackTrace();
        }
        return "";
    }
    
    public static String getApName(Context context) {
        try {
            ConnectivityManager connectivityManager = (ConnectivityManager) context.getSystemService(Context.CONNECTIVITY_SERVICE);
            Method method = connectivityManager.getClass().getMethod("getTetheredIfaces");
            String[] names = (String[]) method.invoke(connectivityManager);
            return names[0];
        } catch (Exception e) {
            e.printStackTrace();
        }
        return "";
    }

看着挺复杂的,因为热点模式和连接到别的热点是完全不同的,取Ap名字时,用到了一个隐藏的方法,需要用反射的方式调用。

DNS报文拦截

DNS意思是域名解析协议,用户打开浏览器浏览网页时,不会记IP地址,而是记某些有含义的网址,DNS就是解决网址到IP地址的对应问题。DNS报文格式参考RFC1035文档,微软的网站上也有介绍:http://technet.microsoft.com/en-us/library/dd197470(v=ws.10).aspx ,这里主要介绍DNS报文的格式。

DNS报文格式

DNS报文一般由如下部分组成: - DNS header (fixed length,12 Bytes) - Question entries (variable length) - Answer resource records (variable length) - Authority resource records (variable length) - Additional resource records(variable length)

套用《TCPIP详解卷》中的一张图

DNS header(固定占12字节)

总共占12字节,结构如下: – 标识:报文的标识,占2字节,查询的报文里生成,响应的报文里复制此内容,用来标识是对相应查询的响应 – 标记:报文的标记位,占2字节,也就是16位,如下:

  • QR:0标识查询,1标识响应,
  • opcode:0为一般查询,1为反向查询(IP地址反查域名),2为查询服务器状态,一般为0
  • AA:是否为授权回答(authoritative - answer),可以理解为当前域名服务器是否对结果负责,如果从别的域名服务器查询过来的结果,显然不是当前域名服务器可掌控的,因此设为0
  • TC:是否被截断,UDP报文限定512字节(不包含IP及头部信息),如果超出将截断,此标记也被置1
  • RD:是否递归查询(Recursion Desired),如果为1,说明DNS服务器如果没有结果,那么DNS服务器会递归地找别的DNS服务器要结果,直到得到结果并返回,如果为0,则在没有结果的情况下,返回DNS列表
  • RA:是否支持递归查询,在响应报文中,一般都会支持递归查询
  • zero:必须为0
  • rcode:错误码,一般为0,表示没有错,如果不为0,表示有问题,错误码可以参考相关文档

–问题资源数:占2字节 –回答资源数:占2字节 –授权资源数:占2字节 –附加资源数:占2字节

Question entries(不定长)

不定长,结构如下: - 名字:域名的字符串表示,microsoft.com表示为:0x09microsoft0x03com0x00,需要注意的是长度的最高两位必须为0,因此字符长度不能超过63,也就是说最多0x3f,另外,参考rfc1053,为简化起见,域名总长度不能超过255 - 类型:相关含义可查手册,一般是0x0001,表示IP地址类型 - 类:一般是0x0001,表示普通的internet问题

Answer resource records(不定长)

不定长,结构如下: - 名字:同前面的查询名字,一般会以索引方式表示,引用到前面的字符,比如前面的 microsoft.com 字符在报文中的位置 - 类型:同前面的查询类型 - 类:同前面的查询类 - 生存时间:报文生存时间(TTL),占4字节,单位秒 - 资源长度:占2字节 - 资源内容:资源具体的内容,如IP地址:1.1.1.1 表示为 0x01010101

Authority resource records(不定长)

同上。

Additional resource records(不定长)

同上。

例子

经过以上的分析,来看个例子,打开wireshark抓包工具,监听网卡数据包,打开控制台,输入:host baidu.com,并抓取DNS报文。

上图为DNS查询:


21d50100000100000000000005626169647503636f6d0000010001
  • 21 d5:会话标识,应答中用于标识是哪个查询
  • 01 00:标记,二进制为0000 0001 0000 0000,参考标记位,RD被置1,标识是一个递归的查询
  • 00 01:问题数1
  • 00 00:回答资源数0
  • 00 00:授权资源数0
  • 00 00:额外资源数0
  • 05 62 61 69 64 75 03 63 6f 6d 00:域名名字,就是5baidu3com0这种格式,数字标识字符的数量,baidu有5个字符,所以是5baidu,域名字符串最后要跟一个0x00
  • 00 01:查询IP地址
  • 00 01:普通的internet查询

上图为DNS应答:


21d58180000100030000000005626169647503636f6d0000010001c00c000100010000017c00047b7d7290c00c000100010000017c0004dcb56f55c00c000100010000017c0004dcb56f56
  • 21 d5:标识,和之前的查询一一对应
  • 81 80:标记,二进制为1000 0001 1000 0000,QR、RD、RA被置1,表示支持递归查询的应答
  • 00 01:问题数1
  • 00 03:回答资源数3
  • 00 00:授权资源数0
  • 00 00:额外资源数0
  • 05 62 61 69 64 75 03 63 6f 6d 00:域名名字,参考前面的查询报文
  • 00 01:查询IP地址
  • 00 01:普通的internet查询
  • c0 0c:域名名字,应该和前面的一致,但是为了节省报文长度,这是个引用,怎么知道的呢?因为是c0,二进制是1100 0000,最高位两位置1了,05626169647503636f6d00这串字符前面有12个字节,因此相对位置是0c(从0开始)
  • 00 01:查询IP地址
  • 00 01:普通的internet查询
  • 00 00 01 7c:生存时间(Time to Live,TTL,单位秒),380秒
  • 00 04:资源长度,4个字节,表示接下来的4个字节是资源的实际内容
  • 7b 7d 72 90:资源内容,其实就是IP地址,123.125.114.144
  • c0 0c …:同上

从上面的DNS应答报文看,关注7b7d7290、dcb56f55、dcb56f56即可,分别对应三个IP地址:123.125.114.144、220.181.111.85、220.181.111.86

DNS报文拦截实现

了解了DNS报文的内容,下面需要做的就是,监听DNS端口,构造自己的报文返回即可,由于权限问题,一般Android的App是无法监听53端口的,这里可以监听53530端口,再通过iptables设置防火墙,将53端口的报文转发到53530端口即可,注意DNS是UDP包,代码参考如下

byte[] requestBuffer = new byte[256];
byte[] responseBuffer = new byte[256];
byte[] ipBuffer = { (byte) 0xc0, 0x0c, 0x00, 0x01, 0x00, 0x01, 0x00,
        0x00, 0x01, 0x7c, 0x00, 0x04, 0x01, 0x01, 0x01, 0x01 };
try {
    datagramSocket = new DatagramSocket(53530);
    DatagramPacket requestPacket = new DatagramPacket(requestBuffer,requestBuffer.length);
    while (!Thread.currentThread().isInterrupted()) {
        datagramSocket.receive(requestPacket);
        int requestLength = requestPacket.getLength();
        System.arraycopy(requestBuffer, 0, responseBuffer, 0, requestLength);
        System.arraycopy(ipBuffer, 0, responseBuffer, requestLength, ipBuffer.length);
        // 标志位
        responseBuffer[2] = (byte) 0x81;
        responseBuffer[3] = (byte) 0x80;
        // 响应数
        responseBuffer[6] = (byte) 0x00;
        responseBuffer[7] = (byte) 0x01;
        DatagramPacket response = new DatagramPacket(responseBuffer, requestLength + ipBuffer.length, requestPacket.getAddress(), requestPacket.getPort());
        datagramSocket.send(response);
    }
} catch (Exception e) {
    e.printStackTrace();
}

这样,所有的DNS解析请求都被转到1.1.1.1这个IP地址了。

url重定向

这个一般由Web服务器决定,Android有款ijetty,是开源的 http://code.google.com/p/i-jetty/, 可看看其中的源代码,修改其中的Handler就搞定了。