無線網路嗅探中的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開頭均為x00x00

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攻擊數據包的源頭。

*本文作者：addadd，轉載請註明來自 FreeBuf.COM

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！

本站內容充實豐富，博大精深，小編精選每日熱門資訊，隨時更新，點擊「搶先收到最新資訊」瀏覽吧！

請您繼續閱讀更多來自 FreeBuf 的精彩文章: