KoreK wrote: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.
KoreK wrote:First release of chopchop. ...Bug reports are welcome.
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?
KoreK wrote: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.
KoreK wrote:What type of packets did you use for testing?
KoreK wrote: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.
c0rnholio wrote: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.
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!
KoreK wrote: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...
c0rnholio wrote:Sorry for the delay, had some work to do...
- 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 respond with an ACK to every wrong encrypted packet!?
- noticed servere multicast storms in associated attack
KoreK wrote: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 wrote: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 ?
devine wrote: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.
Users browsing this forum: No registered users and 1 guest