Results 1 to 9 of 9

Thread: Packet Injection Unseccesfull :-(

  1. #1
    Junior Member
    Join Date
    Feb 2007
    Posts
    73

    Default Packet Injection Unseccesfull *Atheros Card* :-(

    I've tried everything possible that I can think of to crack WEP. I will try to provide as much info as possible. My setup is as follows:


    Wireless Router: Linksys BEFW11S4 80211B
    00:0F:66:2F:7D:E3 ssid=penguin **no clients**
    Wireless Card: Proxim 8461-05 Atheros chipset
    00:20:A6:4C:99:4B
    Additional Wireless Card: DWL-122 (wlan-ng *prism2_usb*)
    00:0D:88:5E:BF:54

    The steps I took:

    1)Monitor mode for Atheros card
    #airmon-ng start wifi0
    2)Brought up ath1
    #ifconfig ath1 up
    3)Start airodump
    #airodump-ng --ivs -w dump -c 9 ath1
    4)In another screen, start ARP Injection
    #aireplay-ng -3 -b 000f662f7de3 -h 0020a64c994b ath1
    5)In another screen, start Fake Auth
    #aireplay-ng -1 60 -e penguin -a 000f662f7de3 -c 0020a64c994b ath1

    That is from what I understand is all that is needed. Airodump shows that my silver card is associated. I see it in airodump anyway and it does seem to be sending packets. With the Fake Auth attack everythings shows as it should. I get Auth successfull and continues to send keep alive packets. ARP injection reads packets and occasionally finds a request and continues to send packets. I can see them in airodump being sent. But, do not receive any IVs. Thought maybe injection wasn't working properly so I opened Kismet and it shows constants packets being sent. Kismet created a file of over 200,000 packets. File size was around 60MB or something. When I opened the crack file with aircrack it only shows 1 packet. All the rest are duplicates, of course. So ARP injection has no effect.

    Some other attacks I've attempted:

    #aireplay-ng -2 -b 000f662f7de3 -h 0020a64c994b -n 100 -p 0841 -c ffffffffffff ath1

    #aireplay-ng -2 -b 000f662f7de3 -d ffffffffffff -f 1 -m 68 -n 86 ath1

    These attempts do find packets to use and when I try to resend them I still get no IVs. After messing with this setup for hours with no success I finally decided to break out my DWL-122 card and try messing with that a bit. This is what I tried with that device:

    1)Start up wlan0
    #wlanctl-ng wlan0 lnxreq_ifstate ifstate=enable
    2)Associate with network
    #wlanctl-ng wlan0 lnxreq_autojoin ssid=penguin authtype=sharedkey

    These steps got my card to show in airodump and shows it probing penguin. Once I seen it in airodump I continued to use the same Fake Auth, ARP Injection and Packet replay attacks listed above using the MAC from my DWL-122. Still no success. I did at one point use:
    #/sbin/dhcpcd wlan0
    In which created some traffic but, no ARP reqs. I did get a few packets using packet replay method though. Using the found packets to be resent to AP still had no effect.

    I'm out of ideas. MAC filtering is off on my AP. That is the only thing I could think of why this wouldn't work. One thing I did notice that seemed kinda wierd to me is that my AP is on channel #9=2.457Mhz. When I open iwconfig it shows my ath1 card on frequency 2.452. Which is channel #8. Why is this? Even when I use:
    #wlanctl-ng wlan0 lnxreq_autojoin ssid=penguin
    it show my wlan0 card on channel #2 using freq 2.422Mhz but, it shows the proper MAC of my AP. Even using airodump on my ath1 card when I start it up on channels #8,9 and 10 (that's as far as I checked) it still shows my AP on that channel. Kinda wierd ain't it? I know I'm not to far from my AP. It's all in the same room.

    Any suggestions please!!!
    ANYTHING!!!
    Maybe if someone could recomend a different syntax for attack methods. Or how to use a captured packet and edit it to help with better results using chop chop or something. I'll take what ever advice I can get.

  2. #2
    Junior Member
    Join Date
    Feb 2007
    Posts
    73

    Default Another set-up with no sucess

    In this attempt I used and old zydas card on XP box. This is a legit client! I run everything as I should:

    #airmon-ng start wifi0
    #airodump-ng --ivs -c 9 -w legit ath1
    #aireplay-ng -3 -b <AP> -h <zydas> ath1

    This does capture data. ARP attack reads and sends out packets but has no effect on AP. The only way to get data packets is by doing a DeAuth attack. Which creates about ~100 packets or so. By doing so I see more ARP packets being read and sent but, the injected packet seem to have no effect.

    Injection support has been verified using kismet but all packets are duplicates
    I'll try and post a screen dump. Hopefully this works...

  3. #3
    Junior Member
    Join Date
    Feb 2007
    Posts
    73

    Default Another Attempt...

    Well after messing around some more. Still haven't had any success. I did notice the BT2 come packed with aircrack-ng 0.62. I updated this to the current 0.7 version. And have using tried using semi colons in my syntax for the MAC using aireplay. This had no effect. Here's another screen dump.

  4. #4
    Junior Member
    Join Date
    Feb 2007
    Posts
    73

    Default Here we go again

    Well, as for the frequency in 'iwconfig', I'm an idiot!. Nevermind just go freq's mixed up. Everything seems fine there. I did go and double check everything on aircrack-ng's website for use with airmon-ng. I did everything stated on there and all shows how it is described on the site. But still no IV's. The one thing I did notice that they did differently on airmon's site. Was shut down ath0 first using:
    #airmon-ng stop ath0
    Then restarting it with:
    #airmon-ng start wifi0 9
    This allowed me to use ath0 in monitor mode. Rather then using ath1 as I was before. The later screendump I posted shows no MAC listed in 'iwconfig' for ath0 as my listed AP. This was later fixed using:
    #ifconfig ath0 up
    Prior to starting airodump. Like I've said I've tried everything. I have read everything, googled and searched forums and am just out of ideas.

    PLEASE SOMEONE GIVE ME SOME INSIGHT HERE!!

  5. #5
    Junior Member
    Join Date
    Feb 2007
    Posts
    73

    Default ???

    This is a confirmation that packet injection is working via WireShark
    This attack was issued to a legit client using:
    #aireplay-ng -2 -a <AP> -d FF:FF:FF:FF:FF:FF -m 68 -n 86 -t 1 -f 0 ath0
    & also:
    #aireplay-ng -2 -a <AP> -d FF:FF:FF:FF:FF:FF -t 1 -f 0 ath0
    Still no success

  6. #6
    Junior Member
    Join Date
    Feb 2007
    Posts
    73

    Default Hmmm....

    Another screendump of WireShark. Notice the DeAuth packet from my AP "Cisco-Li_2f:7d:e3" under source and also my zydas card "Trend_46:a4:77" Isn't this kinda wierd. Especially considering that I never even got a notice from aireplay? Also another thing I noted is that there seems to be some kind of "Malformed packets" being sent and in the highlighted packet it shows a "Prism Monitoring Header" Could this be the problem? Why do I have a prism header listed here? When using a zydas card and Atheros.


    **Sorry admins for all the pics posted. I'm just trying to provide enough info to get this problem resolved**

  7. #7
    Junior Member
    Join Date
    Feb 2007
    Posts
    73

    Default Another Test

    I messed around some more and set-up a Interactive Replay attack on a legit client. Using two different selected packets that I captured. I did a successfull DeAuth attack and received the packets from a re-connect of the legit client. Once packet was captured. I halted EVERYTHING! Disconnected the legit client and AP. Then opened up wireshark to capture and then began to send injected packets. Upon opening the captured packets via WireShark I noticed there were 2 seperate packets being repeated. 1 good packet and then about 5 "Malformed" packets. This obviously must be some sort of driver issue, CORRECT? The "Malformed" packet seems to be the tail end of the valid one. At least then hex coding matches properly. This was the same case for the second SEPERATE packet. Bother with different bytes. The second provided a bit more info. This dump is of the second packet. Again both were sent in a 1good/5bad. Maybe not so much with the second. It actually reported the second to be "Unrecognizable". But, do to it's size and the additional info provided in the packet may have helped a bit from receiving "Malformed:Prism"

    Speaking of prism...why is there a prism header on a atheros card???

    ================================================== ======
    ================================================== ======
    2nd Packet Dump:
    ================================================== ======
    ================================================== ======
    No. Time Source Destination Protocol Info
    153 0.109416 Trend_46:a4:77 Trend_46:a4:77 IEEE 802.11 Data,SN=1634,FN=0

    Frame 153 (345 bytes on wire, 345 bytes captured)
    Arrival Time: Mar 12, 2007 11:31:27.334435000
    [Time delta from previous packet: -0.436316000 seconds]
    [Time since reference or first frame: 0.109416000 seconds]
    Frame Number: 153
    Packet Length: 345 bytes
    Capture Length: 345 bytes
    [Frame is marked: False]
    [Protocols in frame: prism:wlan:data]
    Prism Monitoring Header
    Message Code: 68
    Message Length: 144
    Device: ath0
    Host Time: 0x3b7d38 (DID 0x10044, Status 0x0, Length 0x4)
    MAC Time: 0x0 (DID 0x20044, Status 0x0, Length 0x4)
    Channel: 0x9 (DID 0x30044, Status 0x0, Length 0x4)
    RSSI: 0x45 (DID 0x40044, Status 0x0, Length 0x4)
    SQ: 0x0 (DID 0x0, Status 0x0, Length 0x0)
    Signal: 0x45 (DID 0x60044, Status 0x0, Length 0x4)
    Noise: 0xffffffa1 (DID 0x70044, Status 0x0, Length 0x4)
    Data Rate: 1.0 Mb/s
    IsTX: 0x1 (DID 0x90044, Status 0x0, Length 0x4)
    Frame Length: 0xc9 (DID 0xa0044, Status 0x0, Length 0x4)
    IEEE 802.11
    Type/Subtype: Data (32)
    Frame Control: 0x4108 (Normal)
    Version: 0
    Type: Data frame (2)
    Subtype: 0
    Flags: 0x41
    DS status: Frame from STA to DS via an AP (To DS: 1 From DS: 0) (0x01)
    .... .0.. = More Fragments: This is the last fragment
    .... 0... = Retry: Frame is not being retransmitted
    ...0 .... = PWR MGT: STA will stay up
    ..0. .... = More Data: No data buffered
    .1.. .... = Protected flag: Data is protected
    0... .... = Order flag: Not strictly ordered
    Duration: 253
    BSS Id: Cisco-Li_2f:7d:e3 (00:0f:66:2f:7d:e3)
    Source address: Trend_46:a4:77 (00:e0:98:46:a4:77)
    Destination address: Trend_46:a4:77 (00:e0:98:46:a4:77)
    Fragment number: 0
    Sequence number: 1634
    WEP parameters
    Initialization Vector: 0xb81500
    Key Index: 0
    WEP ICV: 0x66315776 (not verified)
    Data (169 bytes)

    0000 e8 b8 63 2a 19 d5 47 ff 40 88 14 ff 8d 23 4c 24 ..c*..G.@....#L$
    0010 72 92 22 a5 cb 5a 0e af 49 29 85 52 5c 47 a0 14 r."..Z..I).R\G..
    0020 3d dd 24 6c 8e ef f4 f6 ba 9d 11 58 82 9c 3d 81 =.$l.......X..=.
    0030 a8 bc b7 03 9b cc d4 63 4d 85 7d cf 19 d4 fe a7 .......cM.}.....
    0040 70 d1 5c b0 a0 36 c1 fc 1e f7 72 e8 9e ce 2b a4 p.\..6....r...+.
    0050 80 ae 1b de 8e 03 79 e0 2b 41 29 9a d8 eb 61 e2 ......y.+A)...a.
    0060 73 f9 69 9e 2a bb 2e 65 76 25 9b 2f 81 91 e5 22 s.i.*..ev%./..."
    0070 eb cd 0e 2e ef 53 36 ca 5c 5b 0f 54 b2 b1 d1 2f .....S6.\[.T.../
    0080 77 af c9 d3 e9 13 a3 e3 7a 71 72 ee b4 f1 ff ba w.......zqr.....
    0090 08 00 a2 1e fb d4 07 ae e6 3c ea 41 96 a6 28 d8 .........<.A..(.
    00a0 aa b7 ae ca 2e 3f 7d 45 68 .....?}Eh

    ================================================== ======
    ================================================== ======

  8. #8
    Just burned his ISO
    Join Date
    Mar 2007
    Posts
    2

    Default

    Hi Tybalt,
    I've the same problem.
    My card is a PCMCIA ZCOM 325HP+ Prism 2.5 with 1.7.4. firmware.
    Even after unload HermesI as the recognized chipset and load Prism + hostap I cant inject. I've tried everything you do, and I obtained same results.
    At the end I thought that Prism 2.5 cant inject but as I see the same problem occurs on differents chipsets.

    Waiting for some light.
    Thanks in advance

  9. #9
    Junior Member
    Join Date
    Feb 2007
    Posts
    73

    Default

    I've been getting some support on aricrack-ng's board on this. Was recomended to do the following. Could someone please give me some help here on this. I've done and read anything and everything. I'm no fool! Researching myself is honestly the best way I've learned. Rather then just asking stupid questions (try not to anyway). This is my last resort is looking for support on forums. There has to be something really goofy going on here. Whether is a driver issue or what. I have no idea. A little insight would be greatfull.

    1)Killed ath0
    #airmon-ng stop ath0
    2)Start ath0 in monitor mode
    #airmon-ng start wifi0 9
    3)Brought up interface
    #ifconfig ath0 up
    4)Ensure monitor mode and cards MAC is listed as "ACCESS POINT" in 'iwconfig'
    #iwconfig
    5)started airodump
    #airodump-ng --ivs -c 9 -w dump_file_4-13 ath0
    6)Ran tcpdump (new console)
    #tcpdump -n -e -s0 -vvv -i ath0
    7)Ran ARP Replay attack (new console)
    #aireplay-ng -3 -b 00:0F:66:2F:7D:E3 -h 00:20:A6:4C:99:4B ath0
    8)Start FakeAuth (new console)
    #aireplay-ng -1 6000 -o 1 -q 10 -e penguin -a 00:0F:66:2F:7D:E3 -h 00:20:A6:4C:99:4B ath0
    9)Used a wired (ethernet client) to ping unknown host
    :\ping 192.168.1.125
    even tried:
    :\ping whatever.com

    **It all was a no go**
    As you see the FakeAuth attack was succesfull. I can see the keep alive packet in tcpdump. Along with beacons from my AP and the packets being injected. I noticed NOTHING about a DeAuth packet being sent in tcpdump. After pinging an unknown host via wired client. The ARP replay methods finds the ARP req right away and begins to send out packets. This is confirmed with tcpdump and airodump. Even WireShark and Kismet have comfirmed this. Just seems that I do not get any response from my AP.

    darkAudax: Thanks for all your help on this matter. It's supportive ppl like you that keep this linux community going

    yandrak: Yeah, this crap really sucks. I went through hell with my DWL-122 (prism2_usb) used wlan-ng drivers. They have patches for them. But, took me awhile to figure out that injection support was removed from later >2.6.11 kernels. That caused me enough problems as it was. Then later bought a pcmcia => pci adapter. To use my Orinoco Gold card w/external antenna. Later found out HermesI cards can't inject. Then this happens to me with my Silver (Atheros) card. This has been hell!

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •