Wednesday, December 14, 2005

The Extra 4 Bytes?

One of my blog reader has recently sent me an email asking something regarding Scapy, the problem that he faced was: on every packet he sniffed with scapy, it has additional 4 bytes at the end of the packet and he didn't know why? That was happening when he tried to reinject 802.11 frames using an Atheros Card and the patched madwifi driver on Linux 2.4.31. However when sniffing with wlan0 which is using Prism based Card, there's no additional 4 bytes in the packet. So what could it be? This is the Scapy function he used,

sniff(iface="ath0raw", filter="ether dst 00:09:5b:12:3d:5b", count = 1)

In order to resolve it, I decided to ask him to send me the pcap file so that I able to decode it. He sent me two files, sniff-ping-wlan0.cap and sniff-ping-ath0.cap. Once I got my hand free, I loaded these two files in ethereal and apparently one packet with the data of 92 bytes and another one with the data of 96 bytes.

This is sniff-ping-wlan0.cap
This is sniff-ping-ath0.cap with additional 4 bytes.

The packet itself is WEP enabled, I can't do much and decide to browse through the packet header and one thing caught my eye -ICV, ICV is 32 bits integrity check value, it is a checksum value that the receiving host calculates and compares to the one sent by the sending station to avoid tampering of frame integrity. It's weird that ath0 and wlan0 has the same packet with different ICV.

I asked my reader to send me the WEP key since I can't decrypt the single WEP enabled packet. He sent me the key which is AABBCCDDEE. With the WEP key, everything becomes easy, if you are using ethereal for daily task, you should know ethereal able to decrypt the WEP packet with the WEP key supplied. I launched my ethereal directly, to decrpyt WEP you can either shift + ctrl + p or go to Edit -> Preferences,

Go to Protocols -> IEEE 802.11

Check on Assume packets have FCS, WEP key count = 1 since only one WEP key is supplied and used. I decide to go with fcs disabled for wlan0, I'm just go for quick guess because most properly the additional 4 bytes is at the trailer and wlan0 without additional 4 bytes maybe without FCS in the packet.

For ath0 packet, I checked on FCS, to try out my luck.

Wonderfully both packet get decrypted as expected, and it is actually ICMP echo request.

Both packet has the same WEP ICV, it is clear that the additional 4 bytes(ce3dcc10) is Frame Check Sequence.

Have fun with Ethereal (:])


Tobias said...

Thanks for your support.
I didn't know about decrypting WEP packets with ethereal. Now I've tested it on my own and it works good. :)

geek00L said...

No problem, it's glad to help however these days I'm really get into busy ass :)

mel said...

Hey is it possible to sniff wep traffic and and see the Raw data field in real time?? as in not having to save the traffic to a .cap file and later decrypting it,,, i want it to be a real time analysis of wep traffic.

C.S.Lee said...

hey mel,

Use airtun-ng if you want to have wep packet decryption on the fly and perform real time analysis.

mel said...

Thats exactly what i didnt want to do,, i dont want to use airtun since i am writing a small script which will passively collect info with out associating to any AP if i use airtun-ng all the traffic will be decrypted using the provided wep key,, this will create a problem if there are mutiple AP's where some could be wep protected and others might be OPEN. if some one can help me understand the unwep() funtion it would be great so that i can use the lfilter or prn and decrypt only the frames with Dot11WEP layer

while at this can some one please exlain the difference between lfilter and prn in the sniff funtion parameters.