Quote:
|
Originally Posted by c0rnholio
KoreK,
thanks a lot for letting us play with your tool. tried it, love it...kinda must have tool 
one thing...there are a lot of different destination addresses used while chopchop is running...for about 10 minutes there are about 2500 different destination addresses...why is this? |
chopchop decrypts the packet byte by byte. Chop off the last byte, assume it was 0, correct the packet, send to the AP. If the assumption is correct, the packet is valid hence the AP will broadcast the packet (it's a multicast packet). If it's not, the AP drops the packet. Then assume it's 1,... (the correction to make is different for each assumption)
Since chopchop tries up to 256 possibilities, it needs a way to recognize which packet gets retransmitted by the AP. So it encodes the guess in the last byte of the packet. That way it doesn't need to timeout to wait for an (improbable) answer. Just keep on sending, until the AP sends a packet with a dst-mac matches our search, and extract the guess from the last byte (since the AP will re-encrypt the packet, that's the only way to tag it).
Byte 4,5 of the dst-mac encodes the search, ie is incremented after each search, to avoid a wrong guess in case of a successful late retransmission from the previous search.
Every valid packets get into the network. I guess you are writing about the packets you see on the network, not 802.11 frames. So chopchop decoded about 2500 bytes. But it sent around 78000 (my guess) 802.11 frames over the air, all of them with a different dst-mac. If I guessed right, it's a pretty good performance. What type of packets did you use for testing? If I am guessing wrong, could you give me more info about your setup and results (hardware, chopchop parameters, type of packets and length), thanks.
There's a variation I have to finish implementing/testing. If the station is not associated, the AP will still drop invalid packets, but it will respond with a deauth frame to a valid packet. In that case, chopchop uses a varying src-mac to encode the search and the guess. Nice thing about it is that no packet gets into the network. Problem is that my prism54 (working as an AP) has apparently some kind of protection: More than 64(?) invalid packets (for a given IV) and there's a 60s timeout during which all packets (for that IV, valid or not) are dropped. Something I'll have to check over the weekend.