Results 1 to 3 of 3

Thread: Problems with Alfa Awus 036NHR in BT5R3

Hybrid View

  1. #1
    Just burned their ISO
    Join Date
    Dec 2011
    Posts
    3

    Default Problems with Alfa Awus 036NHR in BT5R3

    I just got an Alfa Awus 036NHR and fresh installed BT5R3 and am having some problems with it. Ive read that its supposed to "work out of the box" on the current revision, but I am having issues with injection and Reaver. It says Chipset: unknown, Driver: Rtl8192cu. It passes the injection test, but doesnt seem to actually work in practice.. Like when Im using injection in Gerix or Aireplay I dont get any more IVs than just sitting on the connection... the stock Broadcom card in the ltop even gets 300+/sec. When using Reaver I get a constant loop of "-Sending EAPOL START request, -WARNING Receive timeout occurred." Im dying to get it working with injection and reaver... Imgonna go stay at my GF's place for the next few days, and she has no internet so if I could get this fixed tonight that would be amazing.

    Do I still need to use compat wireless or some of the instructions from this thread? http://www.backtrack-linux.org/forum...ghlight=036nhr , or is it supposed to "work out of the box"? Could it have something to do with interference from the broadcom card? something else? All help would be greatly appreciated..

    Im not afraid of the console so I can test ideas if anybody has any or do diagnostics.

  2. #2
    Just burned their ISO
    Join Date
    Dec 2011
    Posts
    3

    Default Re: Problems with Alfa Awus 036NHR in BT5R3

    Still no luck... Any Ideas? Im gonna try with XioPan and BT5r3 later on VMWare Workstation and see if its just an issues with my BT install.

  3. #3
    Just burned their ISO
    Join Date
    Jan 2013
    Posts
    1

    Cool Re: Problems with Alfa Awus 036NHR in BT5R3 -- need to spoof client MAC?

    TL;DR - I Think you may not be authenticating with the AP before trying to replay packets to up the IVs, if you're positive you are, don't even bother reading this lol...

    I don't own your card but I own a similar one and have a decent amount of experience Pen Testing Wireless systems. Forgive me if this sounds condescending or anything... I don't know anything specific about your card or its drivers in particular, but I'm simply going to give some trouble-shooting advice as to what you may possibly be doing wrong with respect to your inability to generate new IV's... (since your wireless NIC passed the injection test, it should be fine... my Alfa Awus XXXXXXX was plug-in play... they're extremely Linux friendly.)

    OK... anyways, you mentioned you're trying to generate IV's so I'm immediately going to assume you are trying to access a WEP encrypted wireless network. You dropped your card into monitor mode with airmon-ng, you are writing traffic to a file with airodump-ng, and you want to replay arp packets with aireplay-ng. The problem is that if you test this on your home router, it will work perfectly fine, and then as soon as you go to test it in the field/in the lab, everything falls apart. This is because you need to do one of two things:

    Either 1) Spoof the MAC address of a legitimate client (one whose DHCP lease is still valid... usually good for a few days, sometimes less, sometimes infinity...)
    Or 2) Use aireplay-ng to do a fakeauth with the AP so it thinks you're a client on the router and actually listens to you

    The router, by default, ignores packets from anyone it "doesn't know"... meaning someone that hasn't tried to authenticate (successfully?... idk if there is any trickery in the aireplay-ng --fakeauth command or not) with the router within the past few days (or Ever... depending on DHCP lease time) will be ignored. So you can either "authenicate" yourself with the router using a command similar to:

    Code:
    sudo aireplay-ng --fakeauth 5 -a <AP_bssid> <interface>
    and Then do your:
    Code:
    aireplay-ng --arpreplay -b <AP_bssid> <interface> -x <#of packets per second... default is 500-750... toss to 1000 for better results, if you don't mind bogging their network for 5 min>
    (-x is totally optional, just figure'd I'd mention it... unless you're trying to be quite (in which case you should just go All passive sniffing), there's no reason not to crank that number up)

    OR, the other way is to spoof the MAC address of a currently connected client (or recently connected such that they're still authenticated) obtained by looking for clients connected to stations in airodump-ng at the bottom (particularly the station you're interested in), and just pass aireplay-ng a "source MAC" address, which I believe is the "-h" or "-c" option (-h is source... but I believe -c is for client at some point for something...). From a Pen Testing standpoint this is the clear choice simply because when an IT admin or simply a home user looks back at any logs they might have kept regarding traffic on their network, they'll see the insane spike in traffic, but it will all appear to be coming from their own machine... no sign of an outside intruder is ever present (other than the conclusions such a spike might lead a knowledgeable person to demise). So, to use aireplay-ng to spoof a client's MAC address in your replay attack, your command might look something like:

    Code:
    sudo aireplay-ng --arpreplay -b <AP_bssid> -h <connected_client_MACaddress> -x <900> <interface>
    The reason this works at home and then not somewhere else is because your router most likely already had your computer in its list of "authenticated" devices and so you were able to skip the MAC spoofing and/or --fakeauth'ing part without any issues. Also, make sure the network you are Pen Testing has a legitimate client connected to it generating some traffic... otherwise it's impossible to do any arpreplaying if there are only beacons coming from the router and nothing to work with. Lastly, once you see a client associated with the AP and are capturing packets with airodump-ng, look into aireplay-ng's --deauth function. I'm not going to sit around and act like I know what's really going on with Everything in the WiFi process... but in My Experience, DOSing a client off the network for 5-10 minutes would usually help result in an arp packet being captured (and therefore replayed) in aireplay-ng upon letting the client reestablish connectivity... maybe that packet is associated with initial connection or re-syncing of sorts... or maybe it was just coincidence... either way this is the technique to capture WPA/WPA2 handshakes so it's definitely worth looking into. Hope this helped, or at least gave you inspiration to keep trying knowing that someone somewhat cares!!! (Made this account just now to post this... this situation was my biggest "WTF AM I DOING WRONG AHHHHH!!!" *pull hair out* moment in all of my wireless pen testing days hahaha.

    If you knew All of this and your problem is actually one with your drivers, I am truly sorry I just wasted 5 minutes of your time and 30 minutes of mine lol... Good Luck!!
    Oh and just for the record, I've done all my work on Ubuntu, not BT... but for the most part Linux is Linux *shrug* (apparently except drivers though, heh... =p ).

Similar Threads

  1. Alfa AWUS 050 NH
    By macamba in forum BackTrack 5 Beginners Section
    Replies: 1
    Last Post: 05-22-2011, 11:03 AM
  2. Alfa AWUS 050 NH
    By macamba in forum BackTrack 5 Bugs
    Replies: 0
    Last Post: 05-13-2011, 11:02 AM
  3. Output power Alfa AWUS 036H
    By ToonVA in forum Beginners Forum
    Replies: 9
    Last Post: 03-15-2011, 06:57 PM
  4. Replies: 3
    Last Post: 08-31-2010, 08:33 AM

Posting Permissions

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