KoreK

First release of chopchop. WEP cracker which uses the AP to decipher packets. Easiest one are ARP's. Takes 10-20s. Included within patches for wlan-ng to inject packets in monitor mode (I'll try to do hostap for the next release). That's about it. Bits and pieces are missing here and there (only decodes IP/ARP traffic), but it's pretty complete. Bug reports are welcome.

c5f97976238058c9de96266e23a6f7e2 chopchop-0.1.zip (md5)
4bbf077d7d0b23ded56c5fd0ed2dc3bb574fb6f8 chopchop-0.1.zip (sha1)

Not that the signature are very secure, if somebody replaces the file, he will replace them as well. I'll check on them later, though.

Attached Files

chopchop-0.1.zip (47.1 KB, 15194 views)

sylvain

thanks korek
PS : if a day you can work on cisco driver that will be awesome ;-)

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?

__________________
You mean...there is life outside my lab?

audit

I'm sorry but this is just wrong. Take the love fest to PMs.

__________________
audit

Blackberry Outage Mail List. Be the one of first people to know about RIM outages.
Blackberry Chat Mail List.
My day to day life.

KoreK

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.

c0rnholio

Right, I've noticed MAC-change on every byte it decrypts. But I did not sniff the network. I sniffed with another notebook, unassociated and not part of my WLAN.

It's a single UDP DHCP request (one packet) I'm currently playing with...

I can tell you that it works with -n and without beeing associated. Used the UDP DHCP Request and it decodes the packet in no time (about 20-30 sec). Nice work!

Hardware:

AP = Netgear FVM318 802.11b AP / VPN-Router with MAC filter active
NIC= 8003 Prism2 Card with Prim-fw: 0.3.0 and Sec.fw: 1.7.1

cheers,

c0rnholio

__________________
You mean...there is life outside my lab?

KoreK

2500 packet in 10 minutes is a bit slow.
If it's firmware related (it's still the firmware that decides when to send packets), I have to try another test mode which might work better. Well, I'll try it when I finished polishing things up (mainly making the hostap patch work), last thing I need now is a dead card.
And of course, I have to re-read/brush-up the code, I know that there's something wrong with the timing. It didn't have any impact on my test, but who knows...

Now that's good news. In the dumps and chopchop output, did you notice any difference between associated attack and non associated attack?
. in chopchop output, "number of frame written" is greater, or above 256.
. in the dumps, excessive retransmission, or the retry flag is set on some frame.
. average time inbetween two chopchop packets
. the way the ap is responding
. Or anything else...

Thanks, KoreK.

c0rnholio

Sorry for the delay, had some work to do...

There are some differences between the 2 types of attack.

- Number of frames written is mainly under 100, some are between 100 and 200, and anly a few (about 10 packets) are 260-263 in both attacks
- time vary between <1ms and 10ms (from what I see in the sniffer)
- unassociated attack took 1min16sec, associated attack took 1min26sec
- # of packets sent in unassociated attack is: ~2.7 million
- # of packets sent in associated attack is: ~2.3 million
- ap responds mainly with deauth packets in unassociated attack, no deauth in associated attack.
- ap respond with an ACK to every wrong encrypted packet!?
- noticed servere multicast storms in associated attack

Input file was the DHCP packet mentioned in my last post.
Done with a P3 700MHz, 256MB and Debian Linux with kernel 2.4.25.

cheers

__________________
You mean...there is life outside my lab?

KoreK

You are my only tester right now, I can't really afford to complain. And I know this takes up quite a bit of time. Thanks.
That's not too bad. When there are more than 256 written frames, it means that chopchop/the AP missed the valid frame (above 512 missed two valid frames and so on).
The times look reasonable. My guess is that the 10ms are due to kernel switching tasks. If you want to play with the timing, there are 3 options, which control the injection rate. Frames are injected in burst and:

• -burst : number of frames in a burst (default 13)
• -bdelay : the delay between two frame in a burst in ms (default 0ms)
• -backoff : the delay between two bursts in ms (default 3ms)

Are you sure? Not very important since everything else seems fine.
I have to read the standard about that, but I think stations/AP have to ACK every frame they receive (just to avoid retransmissions). Some kind of knee-jerk reflex buried deep inside the firmware. I'll have to see if it's also working in monitor mode. That would be a nice way to track sniffing/silent stations (though since you need the MAC address, it might not be that useful).
That was the plan. I "scrambled" the packets to avoid noticeable effects on the network though.
Thanks for the testing, much appreciated. I will do more testing when I am finished with the hostap patch, and compare with yours. Any feature request for 0.2?

Note: 0.2.1-pre20 is an incomplete dev module. Though that's the one I used for the patch, it still does kernel panic (tested today) if the card is removed while operating (use "cardctl eject" or "state.wlan disable" before removing). Though I backported the patch to 0.2.0 and did not test it much, that should not happen with that version.

sylvain

Korek,
can you tell what size of ciphered packets we should try ? I mean what is the size of common interesting ciphered packets as ARP-requests, DHCP requests...

KoreK

Theory works like this: You decrypt packets, you get network info from packets (IP addresses for now, I have not written the NetBIOS/IPX/whatever protocol extension yet), you do whatever injection attacks you see fit. Since decoding time depends on the length of the packet, the shorter packet the better. The type of packet doesn't really matter, knowing IPs is enough. It is more interesting to get packets from/to different MACs on the wireless network. If you got MAC's, IP's and a prga, you can inject any type of ARP you want, you can scan ports, or whatever you can think of...

sylvain

what do you mean exactly by prga in this case ? and if I decrypt a packet which tool can I use to do the reinjection after ?
thank you

devine

By prga, I guess KoreK means the IV & RC4 stream which you must use as a xor mask to encrypt the packet you're going to inject.

AFAIK there are no tools at the moment to create arbitrary packets from chopchop and perform reinjection. I'll think about adding one in aircrack. Would be faster than waiting for hours until an ARP request pops up

sylvain

that will be very cool to have a such tool. Imagine :
- launch chopchop, get the MAC, IP and PRGA
- reinject packet with your new tool
- launch in the same time aireplay
- launch in background aircrack...
performance would be amazing !!!

KoreK

It is a more precise description (prga is "pseudo-random generation algorithm", ie rc4 stream).
Though I had great fun breaking wep to bits and pieces, I don't see the value of releasing such a tool with chopchop. Anybody else got an opinion on that. Warning: Make it interesting (especially if you got a single-digit postcount)...