Airdecloak-ng is a tool that removes wep cloaking from a pcap file. Some WIPS (actually one) actively “prevent” cracking a WEP key by inserting chaff (fake wep frames) in the air to fool aircrack-ng. In some rare cases, cloaking fails and the key can be recovered without removing this chaff. In the cases where the key cannot be recovered, use this tool to filter out chaff.
The program works by reading the input file and selecting packets from a specific network. Each selected packet is put into a list and classified (default status is “unknown”). Filters are then applied (in the order specified by the user) on this list. They will change the status of the packets (unknown, uncloaked, potentially cloaked or cloaked). The order of the filters is really important since each filter will base its analysis amongst other things on the status of the packets and different orders will give different results.
Important requirement: The pcap file needs to have all packets (including beacons and all other “useless” packets) for the analysis (and if possible, prism/radiotap headers).
Airdecloak-ng 1.7 - (C) 2008-2022 Thomas d'Otreppe https://www.aircrack-ng.org usage: airdecloak-ng [options] options: Mandatory: -i <file> : Input capture file --ssid <ESSID> : ESSID of the network to filter or --bssid <BSSID> : BSSID of the network to filter Optional: -o <file> : Output packets (valid) file (default: <src>-filtered.pcap) -c <file> : Output packets (cloaked) file (default: <src>-cloaked.pcap) -u <file> : Output packets (unknown/ignored) file (default: invalid_status.pcap) --filters <filters> : Apply filters (separated by a comma). Filters: signal: Try to filter based on signal. duplicate_sn: Remove all duplicate sequence numbers for both the AP and the client. duplicate_sn_ap: Remove duplicate sequence number for the AP only. duplicate_sn_client: Remove duplicate sequence number for the client only. consecutive_sn: Filter based on the fact that IV should be consecutive (only for AP). duplicate_iv: Remove all duplicate IV. signal_dup_consec_sn: Use signal (if available), duplicate and consecutive sequence number (filtering is much more precise than using all these filters one by one). --null-packets : Assume that null packets can be cloaked. --disable-base_filter : Do not apply base filter. --drop-frag : Drop fragmented packets --help : Displays this usage screen
Option | Param. | Description |
---|---|---|
-i | input file | Path to the capture file. |
–bssid | BSSID | BSSID of the network to filter. |
–ssid | ESSID | ESSID of the network to filter (not yet implemented). |
–filters | filters | Apply theses filters in this specific order. They have to be separated by a ','. Example: –filters signal,consecutive_sn |
–null-packets | - | Assume that null packets can be cloaked (not yet implemented). |
–disable-base_filter | - | Disable the base filter. (Note: there is a typo in the usage info, the correct option is: –disable-base-filter) |
–drop-frag | - | Drop all fragmented packets. In most networks, fragmentation is not needed. |
Destroy all VAP (only needed for madwifi-ng):
airmon-ng stop ath0
Create a monitor mode interface (in this case on channel 6):
airmon-ng start wifi0 6
Capture all traffic:
tcpdump -n 65535 -i ath0 -w wep_cloaking_full_speed_dl.pcap
aircrack-ng wep_cloaking_full_speed_dl.pcap -b 00:12:BF:12:32:29 -K -n 64 -d 1F:1F:1F
Cracking doesn't work on that file directly even if the beginning of the key is given (-d).
If the whole key is given, cracking it shows that 56% is decrypted correctly and thus 44% of these data packets are cloaked:
Base filter and signal filters are applied on this file. It will create 2 files:
Now cracking it works (PTW doesn't work on this one since it only contains data, nearly no ARP).
Notice “Decrypted correctly: 81%” means that not all packets can be decrypted with the key, so there are still cloaked packets (but not enough to prevent cracking).
In the filtered file, there's still 293986 WEP data packets and 246212 can be decrypted with the key (that makes 47756 WEP cloaked packets still in the file):
In the file containing the cloaked packets, only a few uncloaked packets are present: 1798 (around 1.4% error).
To sum up, with only one simple filter, around 62% of cloaked packets were removed (126K cloaked in the cloaked packets file + 48K in the filtered file) and it helped cracking the file but we will do better with the other filters and the combined filters.
Wep cloaking works by “inserting frames into the air that the attacker thinks are real, and this messes up the statistical analysis of the attacker. (…) The attacker can’t tell the difference between the product frames from the WLAN and the spoofing frames generated (…).”
Wep cloaking is intended to prevent cracking the key, not decrypting the traffic and since nothing is perfect it fails sometimes.
For each Data frame sent by the AP and the clients (even broadcast frames), a cloaked frame is sent by a sensor.
The only difference between the cloaked and uncloaked frame is:
The other attributes, including the size of the frame is exactly the same.
Here what was observed when analyzing the technology:
The following elements can be used to filter out wep cloaked frames:
Note: that analysis shouldn't be based on the order of the frame received; the arrival depends on several factors: your location compared to the sensor sending the cloaked frame, the AP, the location of the sensor compared to the AP, and a few other things.
The sequence number is a 12 bit number used in management and data frames. In nearly all cases this number is sequential for each frame sent in one direction; each node (AP or clients) has its own counter for the sequence number.
Management and control frames aren't cloaked, and it seems that only data frames with subtype 0 are cloaked.
Each data frame is cloaked but don't count on the fact you'll get all of them or the sensor see them all (it may miss a few depending on its location).
If the AP and sensor are not close to each other, signal quality can be used to filter out cloaked frames.
This is a 24 bit number. In a capture file, the probability that 2 frames have the same IV is really low; you can safely drop all frames that have the same IV.
The cloaked frame has the same attributes as “its” uncloaked frame:
Each cloaked frame has the same size as its uncloaked one. Do not filter with only this information because, on a busy network, a lot of frames will have the same size. And even on low traffic networks, sometimes AP sends frames that always have the same size in the air (for example, IGMP frames).
The time needed to receive a cloaked frame could be analyzed; compared to its uncloaked equivalent since the sensor receives the real frame then forge a wep cloaked frame with the informations of the real one.
For this, 2 packets are needed (one real and one cloaked) and we have to make sure the “cloaking” status of both packets is accurate (and that the cloaked packet is forged against the real one we have).
Remark: The time between each frame recorded may not be accurate.
Like the “timing” filter, 2 frames (uncloaked and its cloaked equivalent) could be used to find out the cloaked one. When the cloaked one is found, the cloaked frame can be discarded and each 2 frames (going in the same direction; meaning that it has to be done once for the AP and once for each client).
But, like the “timing”, it's not the best filter
This part will show real wep cloaking capture files and analyze different possible cases. Filtering is done by combining one or more elements (filters) described above.
Filtering could be done in most cases with the signal and timing (or order of arrival but this is the worst choice) but they should be used as last resort.
Note 2: More examples will be added.
In this example, a computer is pinging another one. This capture is filtered (there's a lot of networks but only one network “has” wep cloaking).
On this pictures, there are 2 real data packets (packet 7509 and 7538), the 2 others are cloaked:
There are a few possibilities to filter out the cloaked packet for 7509/7510: - both packets can be discarded since they have the same sequence number. - use signal/timing to find the cloaked packet.
For packet 7538/7539, it will be easier, it's easy to find out which one is cloaked, a beacon has the same sequence numbers as packet 7539; 7539 is cloaked:
In such network, filtering is more difficult since there's a lot of packets between each beacon. Cloaked packets can still be filtered out by checking beacon sequence number (that's what base filter does).
In this case, no packet uses the beacon sequence number …:
… so other ways have to be used. Beacon will still be used but in another way: since 1319 is a valid sequence number, the previous (1318) and the next (1320) sequence numbers of valid packets are known. It's getting more complicated, these sequence number are both used more than once ;)
Since it is known that wep cloaking copies the attributes (including frame size) of its equivalent real frame, wep cloaked packets can be easily found:
Position | Uncloaked | Cloaked | Frame size | Reason |
---|---|---|---|---|
Before beacon | Packet #399244 (SN: 1318) | Packet #399246 (SN: 1320) | 1684 bytes | Arrived before the beacon and thus 1318 is a valid SN. Cloaked has the same attributes as uncloaked; the 2 packets that have the same SN do not have the same attributes |
Before beacon | Packet #399241 (SN: 1317) | Packet #399243 (SN: 1318) | 1684 bytes | SN 1318 is already used by a valid packet (see previous line) and thus the valid SN before 1318 is 1317 (and also, these 2 packets have the same attributes; that is not the case of the 2 packets that have SN 1318) |
After beacon | Packet #399249 | Packet #399251 (SN: 1320) | 1400 bytes (SN: 1320) | In this case, there's no good way to distinguish the real from the fake and thus there are 2 choices: discard or use signal filter. That cannot be seen on the picture but the first |
After beacon | Packet #399253 (SN: 1321) | Packet #399255 (SN: 1323) | 1684 bytes | Sequence number following 1320 (previously valid SN) is 1321, not 1323 |
The program uses the following packet statuses:
The main trick of wep cloaking is that it uses sequence numbers close to the real one and thus the central point of our analysis will be sequence numbers.
It also has a few filters that can be combined in a different orders (that will give different results).
Here is how it works:
Note: It is really important to have all frames (and if possible radiotap/prism headers) in the capture file, including the frames “useless” for cracking like beacons, …
Currently only Base filter and Signal filter are implemented.
Since all management frames are not cloaked, any other frame (a few packets away, in the same direction) using the same sequence number is cloaked.
Try to filter based on signal (for packets coming from the AP). Prism or radiotap headers are required for this filter to work.
Note: Current implementation is based on madwifi-ng signal quality. Note 2: Average signal calculation will be improved. Note 3: Client frames filtering will be added.
Remove duplicate sequence number for the AP only (that are close to each other).
Remove duplicate sequence number for the client only (that are close to each other).
Remove all duplicate sequence numbers for both the AP and the client (that are close to each other).
Basically it applies duplicate_sn_ap
and duplicate_sn_client
filters
Filter based on the fact that IV should be consecutive (only for AP).
This filter will remove all frames that have the same IV.
Filter using signal (if available), duplicate and consecutive sequence number; it uses all those filters in one and thus filtering is much more accurate (more cases can be covered to find out if packets are cloaked or not).
If it's a home network, then no. The hardware is too expensive for an individual (it is cheaper to buy new hardware that supports WPA).
Check also the following question.
If you have the following symptoms, there are some chances that the network has wep cloaking:
Not yet, but they will.
Only a few hundred packets in this capture file can be used for PTW and that wasn't enough. See the following entry for more details.
Thanks to Alex Hernandez aka alt3kx from sybsecurity.com for the hardware.