TCPReplay playing back malformed packets
Hey Guys, having some problems with TCPReplay.
My setup: BT3 with Hawking USB Card - RT73 Chipset. Vista on victim pc.
When I associate with the AP, use ettercap to poison the ARP and sniff, I can get driftnet working. However I cannot seem to get packets picked up in monitor mode to be read by driftnet (or any of the other sniffers).
Heres what I do:
#iwconfig rausb0 mode monitor channel 11
Then start Wireshark and sniff for packets. I browse google images on my victim PC and can see the HTTP packets populate within wireshark. I click 'save' and call the file temp.cap.
now remove the headers:
Total number of packets read 68702
Total number of WEP data packets 513
Total number of WPA data packets 297
Number of plaintext data packets 34410
Number of decrypted WEP packets 0
Number of corrupted WEP packets 0
Number of decrypted WPA packets 0
then I start my sniffers:
#driftnet -i lo
#urlsnarf -i lo
#tcpdump -i lo
now start the replay:
#tcpreplay -i lo temp-dec.cap
Driftnet and URLsnarf don't see anything.
tcpdump shows this for every packet:
19:06:20.304869 00:13:e8:9d:c1:4f (oui Unknown) Null > 00:d0:ba:24:61:c0 (oui Unknown) Unknown DSAP 0x08 Supervisory, Receiver not Ready, rcv seq 0, Flags [Command], length 52
While replaying, I turned on Wireshark and it picked up packets on lo, however every packet has protocol FC and says "Unknown Frame[Malformed Packet] or [Bogus Packet]".
I'm thinking that something is wrong with the way the packets are replaying. Can anyone please offer some advice or reading material?
I don't know what the bump policy is, but anyone?
Good friend of the forums
I use airmon-ng to goto monitor mode ...
Have you tried it without removing the headers? Can someone provide me with a technical explination or link explaining why the headers should be removed? I'm ignorant on this topic.
From what I understand the headers need to be removed because TCPReplay doesnt understand them and will not process your .cap file.
Does anyone know why the replay might be causing malformed packets though?
I'm still experiencing this problem. I tried it with a different router and I picked up SOME of the url's and images, but none of the passwords - i'm sure that a different story though.
With this Cisco AP I am trying to monitor, I can not pick up anything. Can it be something the AP is doing that could prevent sniffing?
Thanks in Advance.
I have the same exact issue with airdecap-ng on BT3 with an intel ipw2200-based wireless card.
I have a capture file from airodump-ng with both my web browsing and IM conversation on an open network, confirmed by reading the original in wireshark, and after running airdecap-ng on it, aside from SSDP, NBNS, and some DHCP communication every single packet (the ones with information of any interest) have been transformed into packets of protocol FC, Info: Unknown frame [Malformed Packet]. Also the source and destinations are what looks to be xx.xx.xx hex values.
Admittedly, I am very much a noob but am learning and several different forums and blogs have mentioned using airdecap-ng on an open network .cap file to strip the 802.11 headers such that it can be played back with tcpreplay and things like dsniff, driftnet, etc can be utilized.
If anybody has had this problem, knows any solution or has any ideas I, too, would greatly appreciate it.
Just fyi for the other guy having issues, rolling back the aircrack suite to version 0.9.3 fixed the malformed packet issues with airdecap-ng, though I'd like to only roll back airdecap-ng and not the whole package because other parts of the suite have improvements in the newer version that I'd like to keep....
Thanks for the advice man, I'll definately give it a go.