引言
在WLAN无线网络抓包的时候不管是用wireshark、tcpdump还是scapy都会出现Radiotap、LLC、SNAP协议层。
如图所示：
LLC逻辑逻辑链路控制子层(包括SNAP)和MAC介质访问控制子层共同组成了数据链路层。
LLC主要负责向上层协议服务MAC层主要负责局域网寻址以及避免竞争向下服务想更深入了解可以搜一下。
下面主要解释Radiotap的结构和蕴含的信息。
Radiotap
简介
Radiotap is a facto standard for 802.11 frame injection and reception.
这句话摘自radiotap的官方文档Radiotap是802.11帧注入和接收的事实上的标准(来自谷歌翻译）。
很多种操作系统支持Radiotap包括linux、windows…
Radiotap一般在网卡接收到无线帧时添加如果内核允许driver to userspace 和 userspace to driver 都是可以的。
这也是为什么我们在monitor模式(内核允许)抓包时会看到summary中最前面的Radiotap协议层。
它提供了无线协议帧相关的信息比如信号强度、噪声强度、信道、时间戳等。
最后radiotap中添加的信息是与网卡有关的比如WN722N网卡添加的present字段第32比特都是1山寨8187网卡就都是0…
下面详细解释：
协议头部结构
struct ieee80211_radiotap_header {
u_int8_t it_version; /* set to 0 */
u_int8_t it_pad;
u_int16_t it_len; /* entire length */
u_int32_t it_present; /* fields present */
} __attribute__((__packed__));一般情况整个头部共8byte 32bit8(versiont) + 8(pad) + 16(len) = 32(present)
1. 当前版本version字段始终为0
2. pad字段是为了补齐四个字节而置0的字段因此radiotap开头均为x00x00
3. len为整个radiotap数据层的长度不需要解析时方便直接跳过
4. present为radiotap协议数据的位掩码某位为1时表示这个位代表的数据存在存放在头部后面。
比如bit5(下标)表示后面存在信号强度数据bit31表示还有另一个present字段存在。
因为位掩码的存在raditap协议的数据是不定长的也让radiotap变得很灵活当出现新的字段时不会破坏现有的解析器。
当出现了不能理解的radiotap数据可以通过len直接跳过继续解析上层数据。
5. 因为present字段可能存在多个所以说上面的头部长可能会变长但要注意8byte对齐以0补位比如WN722N抓到的
00 00 2400 2f4000a0
ver pad len present1
20080000 00000000
present2 pad
2d217005 00000000
radiotap data
10486c09 c000b200
radiotap data
0000b200 nnnnnnnn...
radio.. payload协议数据内容
协议中有已定义(defined)、讨论中(suggested)、被抛弃的(rejected)的字段。
大多数时候我们关心的是已定义的几个有丰富信息的字段详情需参考官网介绍。
| 名称 | 位数 | 长度 | 单位 | 介绍 |
|---|---|---|---|---|
| TSFT | 0 | u64 | 微秒 | 数据帧第一bit抵达的时间 |
| Rate | 2 | u8 | 500Kbps | 发送或接收的速度 |
| Channel | 3 | u16 frequency,+u16 flags | MHz + bitmap | 信道的频率和flags |
| Antenna signal | 5 | s8 | dbm | 接收时信号在天线的强度 |
| Antenna noise | 6 | s8 | dbm | 接收时噪声在天线的强度 |
| dBm TX power | 10 | s8 | dbm | 发射功率(有符号) |
由于Radiotap协议很灵活很多时候其中会有厂商自定义的字段。
注意取出信号强度的时候数据为有符号整数且强度均为负数需要先减1再取反得到正确的绝对值详情参考负数补码表示。
另外想取得上面的字段还要看你的网卡资不资词当然希望它是资词的。
此外每个字段的名称在wireshark中也略有差异如图为wireshark中包含两个present时的字段名称。
如何过滤
Proto is one of ether, fddi, tr, wlan, ppp, slip, link, ip, arp, rarp, tcp, udp, icmp, ip6 or radio, and indicates the protocol layer for the index operation. (ether, fddi, wlan, tr, ppp, slip and link all refer to the link layer. radio refers to the “radio header” added to some 802.11 captures.)
截自BPF文档BPF语法提供了对RadioTap协议的过滤支持即为’radio‘。
可以在scapy 的sniff函数 的filter参数或者在tcpdump 等等使用bpf语法过滤的过滤器中使用。
比如想过滤present字段为0×0024的数据包时filter=’radio[2:2]==0×2400′ (scapy)。
另外想过滤某些位均可以通过‘与’操作(&)获得filter=’radio[2]&7==7′。
此外需要特别注意的是radiotap协议中字节序为小端序也就是某个字段有多个字节时低位的字节被先发送。
例如 present字段的0×12 23 34 45在无线网络中按接收的先后顺序为0×45 34 23 12这点在scapy中使用str(packet) 和 wireshark中的packet bytes栏中都可以观察的到。
所以在使用过滤语法时一定要考虑字节序的问题低位在前。
如何解析
使用scapy
summary:
show:
可以看到scapy解析除了version、pad、len和第一个present但present中的Ext代表着还有另外的present字段存在。
所以scapy对radiotap的支持不是很好余下未解析的数据都放在notdecode中(小端字节序)scapy通过len字段直接跳过radiotap解析了上层数据。
使用radiotap-library
这个库在官网中也有介绍另外这篇文章中也有这个库的简单使用方法是c语言的库在linux内核中有应用。
因为喜欢在python中编程所以曾经想自己改一下函数生成一个动态链接库由python调用但我后来偶然发现了下面的库。
使用itamae
当pip search radiotap时会发现另外一个库
itamae (0.1.1) – Python 802.11 MPDU and Radiotap parsing
安装后itamae的radiotap子模块的介绍中写道
provides radiotap parsing (radiotap.org defined fields) only.
NOTE:
o Will not parse correctly if extended fields are present prior to defined
fields.
o It is recommended not to import * as it may cause conflicts with other modules
表明了对支持radiotap协议的解析同时需要注意它只会成功解析含有一个present的数据包。
使用时只需要把数据包的字符串传进去就可以了返回解析好的字典。
有什么好玩的用途
既然我们有了接收信号的强度测一测自己网卡的信号衰弱和距离的关系多次移动后就可以粗略的对信号源有一个定位了。
网上有很多很多RSSI(Received Signal Strength Indication)室内定位的算法可以参考一下。
想象一下你在咖啡厅嗅探外面商场的开放wifi突然看到了一个镁铝的自拍定个方向再去找是不是方便很多。
再或者企业是不是也可以通过大致的定位方便找出无线环境中多出的n多deauth dos攻击数据包的源头。
*本文作者：addadd，转载请注明来自 FreeBuf.COM