无线网络嗅探中的Radiotap

引言

在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…

下面详细解释:

协议头部结构

一般情况整个头部共8byte 32bit8(versiont) + 8(pad) + 16(len) = 32(present)

1. 当前版本version字段始终为0 2. pad字段是为了补齐四个字节而置0的字段因此radiotap开头均为\x00\x00 3. len为整个radiotap数据层的长度不需要解析时方便直接跳过 4. present为radiotap协议数据的位掩码某位为1时表示这个位代表的数据存在存放在头部后面。 比如bit5(下标)表示后面存在信号强度数据bit31表示还有另一个present字段存在。 因为位掩码的存在raditap协议的数据是不定长的也让radiotap变得很灵活当出现新的字段时不会破坏现有的解析器。 当出现了不能理解的radiotap数据可以通过len直接跳过继续解析上层数据。 5. 因为present字段可能存在多个所以说上面的头部长可能会变长但要注意8byte对齐以0补位比如WN722N抓到的

协议数据内容

协议中有已定义(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字段为0x0024的数据包时filter=’radio[2:2]==0x2400’ (scapy)。

另外想过滤某些位均可以通过‘与’操作(&)获得filter=’radio[2]&7==7’。

此外需要特别注意的是radiotap协议中字节序为小端序也就是某个字段有多个字节时低位的字节被先发送。

例如 present字段的0x12 23 34 45在无线网络中按接收的先后顺序为0x45 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攻击数据包的源头。

原文发布于微信公众号 - FreeBuf(freebuf)

原文发表时间:2017-10-04

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏IT派

美剧迷是如何使用Python的

一直有爱看美剧的习惯,一方面锻炼一下英语听力,一方面打发一下时间。之前是能在视频网站上面在线看的,可是自从广电总局的限制令之后,进口的美剧英剧等貌似就不在像以前...

13020
来自专栏北京马哥教育

一致性hash原理与实现

一、背景介绍 memcached的分布式 memcached虽然称为“分布式”缓存服务器,但服务器端并没有“分布式”功能。服务器端内存存储功能,其实现非常简单。...

39670
来自专栏GopherCoder

『Go 语言学习专栏』-- 第十一期

15430
来自专栏涂小刚的专栏

从 PageRank Example 谈 Spark 应用程序调优

在做PageRank测试时,发现有很多有趣的调优点,想到这些调优点可能对用户来说是普遍有效的,现把它整理出来一一分析,以供大家参考。

1.3K30
来自专栏我就是马云飞

RxJava2 实战知识梳理(2) - 计算一段时间内数据的平均值

前言 今天,我们继续跟着 RxJava-Android-Samples 的脚步,一起看一下RxJava2在实战当中的应用,在这个项目中,第二个的例子的描述如下:...

26260
来自专栏腾讯大数据的专栏

Storm上的实时统计利器-easycount

背景 Storm是TRC(腾讯实时计算)平台的核心组件。与Hadoop不同,storm之上没有像hive,pig之类的解放应用开发人员效率的工具。开发原生的st...

37990
来自专栏Java后端技术栈

你应该知道的缓存进化史!

本文是上周去技术沙龙听了一下爱奇艺的Java缓存之路有感写出来的。先简单介绍一下爱奇艺的java缓存道路的发展吧。

15010
来自专栏Flutter入门

偶遇FFMpeg(四)-FFmpeg PC端推流

之前在Android集成FFmpeg。主要还是基于命令行的方式进行操作。刚刚好最近又在研究推流相关的东西。看了一些博文。和做了一些实践。 就希望通过本文记录袭...

51730
来自专栏拂晓风起

【HTTP劫持和DNS劫持】实际JS对抗

37220
来自专栏Albert陈凯

理解zookeeper选举机制

zookeeper集群 配置多个实例共同构成一个集群对外提供服务以达到水平扩展的目的,每个服务器上的数据是相同的,每一个服务器均可以对外提供读和写的服务,这点...

83250

扫码关注云+社区

领取腾讯云代金券