|
Pages: [1]
|
 |
|
Author
|
Topic: Fragmentation Attack and distance from AP (Read 3821 times)
|
|
cjaghblb
|
Just started messing with the frag attack and I have been successful. I have noticed that it only seems to work when I am physically close to the AP. I situations where distances are greater (still close enough for chopchop to work), it fails. Anyone else started to notice this? If so, has anyone started to determine a minimum power level or receive quality to associate with it being successful? I am successful with a power of 18-22 and rxqual of 90-100 but it fails at power of 6-8 and rx qual 25-75 (the rx qual hops arounds wildly with the weaker signal). I can be consistantly successful with chopchop here though. Wondering what factor og the frag attack is not allowing it to work at this weaker signal strength. thoughts?
|
|
|
|
|
Logged
|
|
|
|
|
cjaghblb
|
I moved around to find a stronger signal for the AP I was working against at 6-8 power and when I got to 16-18 power, the frag attack worked. It took about 5 minutes of trying packets to finally get one to reply the 3 times but it did work. maybe thats the power baseline one needs to have the frag attack be successful.
|
|
|
|
|
Logged
|
|
|
|
|
Hirte
|
First of all, yes, you need a better position for --fragment, than for any other attack to be successful.
The explanation is simple: You need the AP to receive 11 special frames in a distinct order and right after that, you need to capture the one packet, the AP sends as a response to these frames (actually the AP concatenates the data you sent in your 11 packets and sends it as one single packet). So a packet loss will fail the attack. The packet loss percentage is indicated by the rxqual value. All the other attacks do not require a special order, or can replay single packets, because there is an indication that the previous packet were lost. So they are still working with a medium packet loss.
A few words to the rxqual value: All beacons are transmitted at 1MBit, so they have the highest probability to be captured. Take a network with absolutly no traffic, so you'll only receive beacons and the rxquality is 100% as there is no packet loss, because there are no other packets. Now a wireless stations joins the network with a rate of 54MBit. This traffic can't reach you and so the rxquality goes down. This is the reason for the jumpy rxqual value. When there were no high rate packets sent, the packet loss is low, so you have a high rx quality and the other way around, packets at a high rate can't reach you, the packet loss goes up and the rx quality goes down. So a jumpy rxquality value indicates one or more active stations, where you can't capture the packets from the AP to these stations.
|
|
|
|
|
Logged
|
|
|
|
|
cjaghblb
|
Thanks for the explanation, it helped out. I do have one last question. How is my wireless device able to determine whether its receiving all traffic versus a portion of the traffic (hence the lower RX qual value), is there a sequence number applied to all packets sent by an AP regardless of type?
Thanks
|
|
|
|
|
Logged
|
|
|
|
|
Hirte
|
exactly, the ieee80211 header contains a sequence counter, so we can easily calculate the number of missed packets...
|
|
|
|
|
Logged
|
|
|
|
sorbo
Newbie

Posts: 39
|
This is an implementation issue. The frag attack works well in practice, even if the AP is far away. Individual fragments are ACKed by the AP. Thus, an implementation can check if fragments are lost and retransmit them, before sending the next fragment. Thus, packet loss should not degrade performance of the attack---it may be detected and fixed by the transmitter.
Hirte mentioned that 11 fragments are being sent. A more robust implementation may choose to send only two fragments. This means that the keystream will be double at each round. However, the implementation will be more robust against packet loss---the packet now consists of only two fragments rather than eleven, so there are less fragments that we need to worry about to not lose. In practice, I find that sending [logical] packets of two, or at most three fragments works best. Although this requires more rounds in order to reach a 1500 keystream, it performs faster in practice due to less packet loss [it is still important to check for ACKs and retransmit lost fragments]. Such an implementation could recover 1500 bytes from 8 bytes in less than 10 seconds.
|
|
|
|
|
Logged
|
|
|
|
|
darkAudax
|
sorbo,
Yes, the approach of using fewer packets but doing more rounds is already on the enhancement list. Plus a number of other interesting refinements to the fragmentation technique. The current approach programmed by Hirte works very well today in its present form.
d.
|
|
|
|
|
Logged
|
|
|
|
|
|
GamezR2EZ
Newbie

Posts: 22
|
I actually with great difficulty got the Frag Attack to work on the edge of the network, took a while but i got it. I had 3 power and RX of 100. so i guess i can work anywhere if you have the time, and patience
|
|
|
|
|
Logged
|
|
|
|
|
|
Pages: [1]
|
|
|
 |