揭开智能配置上网(微信Airkiss)的神秘面纱

本文介绍微信利用Airkiss技术对wifi设备进行智能配置上网的场景,并分析其实现的原理。这里再次说明,Airkiss只是用于配置上网,其跟微信硬件平台的通信流程和接入协议规范完全没有关系。一个wifi设备并不一定要通过Airkiss技术来配置上网,它也可以利用传统的方法来配置,也可以利用其它厂商的智能配置技术来完成配置。所有的wifi智能配置上网技术的原理基本上都是一致的,其开山鼻祖应该是TIsmartConfig。

目前几乎所有的主流wifi厂商都提供了Airkiss的接口库,但并没有说明其原理和实现过程。网上也只见一份Airkiss技术实现方案文档,但需要对无线通信和socket编程有一定基础的人才能理解。本文尽可能深入浅出地分析这项技术,帮助大家理解。

一、传统配置上网过程

例如我们买了一个路由器,路由器是没有按键和屏显示的。而我们都知道,路由器要配置好运营商的账号和密码才能接入互联网的。一般的做法都是路由器作为热点AP,其提供一个WebServer来设置路由的各项参数,默认IP是192.168.1.1(或者其他IP,路由器说明书上会说明);我们通过电脑有线接入路由器,通过DHCP自动分配到一个192.168.1段的地址。然后通过浏览器来访问http://192.168.1.1,即可以进入路由器设置界面进行设置,包括运营商的账号和密码、本机的SSID和密码。然后我们的手机就可以开启wifi扫描到SSID,输入密码即可以访问互联网了。

再比如,我们家里已经有了一个可以上网的路由器(SSIDx和pwdx)。我们购买了一个无线摄像头装在家里。它自然也要连到家里的路由,才能访问这个摄像头的厂商,这样我们才可以用手机的APP接收到厂商服务器传过来的数据进行显示。摄像头也没有显示屏和按键(reset键不算啦)。传统的配置方法是:

1)摄像头恢复出厂设置后默认进入AP(热点)+Station(工作站)状态。AP热点的SSID和密码由摄像头的说明书说明,是厂商默认的。手机通过wifi连接到该AP,然后通过浏览器访问http://192.168.1.1(也是厂商默认的),在该界面设置家里的路由器的SSID和密码,便于其作为Station连入家里的路由器。

2)当摄像头连接路由器成功后,其即单独以Station的模式运行(不用再做AP可以省功耗),其会立即访问厂商的服务器(其内部程序代码会hardcode厂商服务的域名或者IP),告知其已经上线,并且要在一段周期内发送Beacon心跳包维持长连接。

3)手机断开摄像头的AP热点,连接家里的路由器。打开摄像头的APP,即可以通过厂商服务器查看家里的摄像头的效果。

所以传统的配置上网方法是wifi设备必须以AP的模式运行,配置好以后再转回Station模式运行。是不是比较费事?

二、智能配置上网流程

智能配置上网最新走进人们视野好像是庆科在大张旗鼓地宣传其智能插座的一键配置功能,其实最早是Ti推出的技术。它是怎样操作呢?

1)wifi设备以Station混杂模式运行。

2)手机智能配置APP通过某种协议包发送家里路由器的SSID和密码。

3)wifi设备通过抓包获取到SSID和密码,然后连接家里的路由器。

整个过程是不是很简单?

三、智能配置的基本原理

1.混杂模式

这里有没有注意到,wifi设备刚开始同样是以Station的模式运行,但是还有一个混杂模式。是什么意思?它是指正常的wifi设备都有一个MAC地址,其硬件电路会自动过滤目标MAC地址跟其MAC不同的数据包。开启混杂模式就是我们平常时说的抓包,就是空中符合802.11格式的数据包都接收进来,不管MAC是否一样。

很明显,手机智能配置APP并不知道该wifi设备的MAC地址,所以手机wifi发送出的数据包,通过家里的路由器转发出去时,wifi设备必须要在混杂模式下才能接收到这些数据包。

2.信道切换

802.11有多个信道,某个时刻wifi设备和路由器都是处于某个信道。路由器一般都是默认在第6个信道。所以如果想家里的wifi信号更好一点,可以尝试将路由器的信道改到一个其他值,这样就不会跟邻居家的wifi信道重叠了。无线信号混在同一个频道就会干扰的。

同理,我们也不能假定wifi设备是处于哪个信道,但我们可以在APP中确定手机wifi的发送信道,这样可以要求wifi设备在一定的时刻内切换信道,以便于接收数据包。当wifi设备检测到有效的数据包后,要锁定在该信道进行后续通信。

3.利用数据帧的长度来承载有效信息

我们先来看看802.2 SNAP(802.11物理层协议)的数据帧格式:

我们不去深入研究各个字段的含义,只需要知道DAT是加密的,如路由器都会通过WAP2、WEP等方式加密数据等。而DA(目标MAC)、SA(源MAC)、LLC(逻辑控制)、SNA(厂商代码和协议标识)、FCS(校验码),这五个字段虽然是没有加密的,但是APP层的应用编程难以改变这些字段,需要操作系统才有权限修改,所以最终能够利用的字段就是Length,其没有被加密,而且能够被应用层编程所控制。

由于Length是两个字节,但是一帧最长是1492个有效数据,所以也不能完全利用16个比特。以最简单的方法来使用Length就是使用其中的一个字节,这样如果我们要发送数据0x12345678,那就连续发8个数据帧,第一次的长度是1,第二次的长度是2,以此类推。

四、微信Airkiss

Airkiss顾名思义是飞吻的意思,即手机发送的SSID和密码经过路由转发出去,被目前wifi设备所检测并截获到。无线网络协议一般场景都规定station只能和AP通信,而不能station和station通信(这种场景叫做AD-Hoc点对点)。接下来我们分析SSID和pwd怎么利用Length进行编码的过程。

1.   物理层

发送4个字节的前导码序列,{1,2,3,4}。即发送4个数据帧,帧长度分别是1,2,3,4.其要解决两个问题:

1)空中充满无线信号,通过前导码来识别出符合airkiss协议的数据包的开始。

2)数据包的数据是经过加密的,发送方的数据帧的有效数据的长度是1,经过编码后的长度会发送变化。假设加密后的长度为N,那接收方接收到的数据长度是N。以后所有的数据帧接收的长度是M时,那发送方真正的数据长度是M-N+1。

Airkiss规定数据的长度使用9个bit进行编码。

2.数据链路层

数据链路层的包括控制字段和数据字段。

1)Magic为4个数据帧,两个帧的两个9bit记录将要发送的数据(PWD+Ramdon+SSID)的长度;两个帧的两个9bit记录SSID的CRC校验值。路由器的SSID是会被路由器广播出来的,例如我们手机wifi扫描到路由器的名称就是SSID。因此wifi设备也能得到路由器的SSID,其只要计算目前所能获取到的SSID的CRC值跟MAGIC的SSID CRC值一样,那之后的SSID数据就不用接收了,这样能够提高配置上网速度。Magic很重要,因此发送5遍。

2)PrefixCode为4个数据帧,两个帧的两个9bit记录PWD的数据长度,另外两个帧的两个9bit记录PWD长度的CRC校验值。Magic中发送的长度是所有数据的长度,包括密码PWD、随机数(wifi配置成功后要回复该随机数作为回复)和SSID。而这里是PWD的长度,用于对接收到的数据进行分段。

3)一个序列包括一个序列索引和一个序列数据。协议规定将有效数据以4个字节进行划分,不够补0。如我家路由的PWD是8313huang,那其会分为3个序列,分别是“8313”、“huan”“g\0\0\0”进行发送。Sequence header包括索引值和CRC值,而Data field就是4个数据帧,包含要发送的数据,如“8313”等。

4)如何区分Magic、Prefix、Sequence和Data,是由9bit的最高几个bit来区分的。例如最高bit为1时表示是Data,其他是控制字段。

3.应用层

应用层即是手机配置上网APP要发送的数据,包括三部分的数据。分别是:

1)PWD。其先被发送是因为其是最重要的,而SSID已经在MAGIC字段中所确认。

2)1个字节的随机数。wifi配置成功后要发送以该随机数为内容的UDP广播包作为回复,APP收到后即认为wifi设备已经成功联网。

3)SSID。

五、ESP8266 Airkiss

微信硬件开放文档有《airkiss_developer_manual.pdf》介绍在ESP8266平台上利用Airkiss接口库进行开发实现Airkiss协议的过程。而ESP8266的厂商提供的DEMO则更加直接地用一个接口就实现了Airkiss。

六、微信Airkiss

微信Airkiss在正式产品中是需要通过硬件JSAPI进行调用来调出发送SSID和PWD的界面,而硬件JSAPI需要经过验证的服务号才能申请获得权限。没有权限时可以使用AirkissDebugger这个APP进行调试。

时间: 2024-10-11 13:30:16

揭开智能配置上网(微信Airkiss)的神秘面纱的相关文章

揭开html5移动端页面制作的神秘面纱

初涉移动端,需要准备好一些基础知识: 搞清楚css中rem,em,px的关系 PX特点 1. IE无法调整那些使用px作为单位的字体大小: 2. 国外的大部分网站能够调整的原因在于其使用了em或rem作为字体单位: 3. Firefox能够调整px和em,rem,但是96%以上的中国网民使用IE浏览器(或内核). px像素(Pixel).相对长度单位.像素px是相对于显示器屏幕分辨率而言的.(引自CSS2.0手册) em是相对长度单位.相对于当前对象内文本的字体尺寸.如当前对行内文本的字体尺寸未

ASP.NET 运行时详解 揭开请求过程神秘面纱

对于ASP.NET开发,排在前五的话题离不开请求生命周期.像什么Cache.身份认证.Role管理.Routing映射,微软到底在请求过程中干了哪些隐秘的事,现在是时候揭晓了.抛开乌云见晴天,接下来就一步步揭开请求管道神秘面纱. 上篇回顾 在介绍本篇内容之前,让我们先回顾下上一篇<ASP.NET运行时详解 集成模式和经典模式>的主要内容.在上一篇随笔中,我们提到ASP.NET运行时通过Application的InitInternal方法初始化运行管道.ASP.NET运行时提供了两种初始化管道模

揭开Sass和Compass的神秘面纱

可能之前你像我一样,对Sass和Compass毫无所知,好一点儿的可能知道它们是用来作为CSS预处理的.那么,今天请跟我一起学习下Sass和Compass的一些基础知识,包括它们是什么.如何安装.为什么要使用.基础语法等一些基本知识.需要说明的是我也仅仅只是刚刚接触Sass和Compass,一些高级用法等将不再本文的讨论范围之内.接触一周以后发现Sass和Compass的用处非常大,也打算今后在项目中尝试引进并应用起来.希望读完以后,你跟我一样对Sass和Compass给你带来的东西非常开心,也

揭开webRTC媒体服务器的神秘面纱——WebRTC媒体服务器&amp;开源项目介绍

揭开webRTC媒体服务器的神秘面纱--WebRTC媒体服务器&开源项目介绍 WebRTC生态系统是非常庞大的.当我第一次尝试理解WebRTC时,网络资源之多让人难以置信.本文针对webRTC媒体服务器和相关的开源项目(如kurento,janus,jitsi.org等)做一些介绍.并且将尝试降低理解WebRTC的业务价值所需要的技术门槛. 何为WebRTC服务器? 自从WebRTC诞生之初以来,该技术的主要卖点之一是它可以进行点对点(browser-to-browser)通信,而几乎不需要服务

揭开SAP Fiori编程模型规范里注解的神秘面纱 - @OData.publish

今天是2020年2月1日鼠年大年初八,这是Jerry鼠年的第8篇文章,也是汪子熙公众号总共第207篇原创文章. Jerry的前一篇文章 揭开SAP Fiori编程模型规范里注解的神秘面纱 - @ObjectModel.readOnly工作原理解析,给大家分享了@ObjectModel.readOnly这个注解对应的Fiori UI和ABAP后台的工作原理. 今天我们继续研究另一个注解@OData.publish. 在SAP官网的ABAP Programming Model for SAP Fio

VPS用来配置上网外,还可以做一个同步盘

我曾经在一个活动的博文里说过,男人必须要有一个VPS和一个树莓派,VPS这个东西,以后会是中国男人的一种必备技能,今天又有一个小伙伴请教我VPS的用法,我就简单说说我目前使用的情况.首先我希望你能有点Linux基础. 一.搬瓦工的VPS非常实惠,推出过年付4刀的低配主机,内存只有64M,可惜如今已经售磬,我使用的是有家主机年付100元的小主机,内存128M,也算是低配了,通常的概念是,如此低的内存,用来跑WordPress肯定很吃力,所以大家只是用来做个上网服务器.关于这个用法,请参考秋水逸冰的

揭开.NET消息循环的神秘面纱(GetMessage()无法取得任何消息,就会进入Idle(空闲)状态,进入睡眠状态(而不是Busy Waiting)。当消息队列不再为空的时候,程序会自动醒过来)

揭开.NET消息循环的神秘面纱(-) http://hi.baidu.com/sakiwer/item/f17dc33274a04df2a9842866 曾经在Win32平台下奋战的程序员们想必记得,为了弄清楚“消息循环”的概念,度过多少不眠之夜.尽管如今在应用程序代码的编写过程中,我们已经不再需要它,但是深刻理解Windows平台内部的消息流转机制依然必要.. 在早年直接用Win32/Win16 API写程序的时代,消息循环是我们必须搞懂的第一个观念.现在,不管你用是Windows上面的哪一套

【安全健行】(4):揭开shellcode的神秘面纱

2015/5/18 16:20:18 前面我们介绍了shellcode使用的基本策略,包括基本的shellcode.反向连接的shellcode以及查找套接字的shellcode.在宏观上了解了shellcode之后,今天我们来深入一步,看看shellcode到底是什么.也许大家和我一样,从接触安全领域就听说shellcode,也模糊地知道shellcode基本就是那个攻击载荷,但是shellcode到底长什么样,却一直遮遮掩掩,难睹真容.趁今天这个机会,我们一起来揭开shellcode的神秘面

揭开全球第一颗SDN交换芯片的神秘面纱

编者按:全球第一颗SDN交换芯片一直被一层神秘的面纱包围着,小编近日采访了一下盛科网络的张卫峰张总,为您揭开全球第一颗SDN交换芯片神秘的面纱,以下是采访内容. SDN是一个很泛泛的概念,它可以有很多不同的实现方式,而OpenFlow技术是发展最早的,最广为人知的,并且唯一标准化的SDN实现.但是由于一直没有针对OpenFlow的网络交换芯片问世,所有做OpenFlow交换机的设备商都做得很郁闷,用现有的传统交换芯片做出来的OpenFlow交换机,限制都太多,甚至业内有人说,SDN之所以落地缓慢