Create fake wireless access points with atheros chips

Airraid -- Create fake, wireless access points (APs) with Atheros chipset cards


Looking for some more information on Backtrack including installing it on a USB flash drive? Have a look at our BackTrack Notes page.

Looking for notes on using the Netgear WG511T with BackTrack? See the section below.



Background

This is a proof-of-concept and very much Beta code.

I wrote airraid to see if I could implement something similar to fakeap.pl from the good folks at Black Alchemy. Their fakeap.pl is a version that works with Prism chipset wireless cards. Truthfully, I didn't have a Prism card! I did have an Atheros card and wanted to do the same thing.

When I first heard about fakeap I assumed it did some low-level card tweaking to send out AP beacons. I was relieved to find out that it was actually a very elegant way to execute shell commands... very quickly. I figured if I could get shell commands to work with the Atheros card I could modify the Perl script to do the same thing for Atheros.

I found that the Madwifi drivers supported "ap" or "master mode" which is exactly what I needed. However, the ability to change MAC address was not so easy to come by. In fact, I have a really ugly crutch in the code to make the MAC change work, more on that later...

I used the fakeap code as a base and added an option to make it appear a tiny bit more realistic to the outside world.

I have no illusion that this would completely fool a talented wardriver or hacker. I know there are telltale signs that make it an obvious fake. [Those will be left to the reader as an exercise]. In fact, if Kismet is used to snoop this activity, it will occasionally set off an air raid siren (how appropriate) to indicate a spoofing condition.

This can be used to make a total and complete mess of the radio spectrum. Use it wisely.


Testing

That's where you come in! Hey, if Microsoft can use millions of unsuspecting customers to do their beta testing, I can use a few of you guys to knowingly do mine!

I have only tested this with one card! But, alas, it worked. I have a Netgear WG511T card and run Backtrack2 for the OS. I have no reason to believe you need either of those particular items to make this work. You will need to get the card working with the MadWifi drivers. You will also need a program called macchanger. And a few Perl modules. See more below in Prerequisites.

I believe this should work fine with Nubuntu as long as you can get macchanger working. Nubuntu appears to come without macchanger as part of the default complement of utilities. I don't think it will work with Auditor (at least not with my WG511T) because it doesn't look like the MadWifi commands work. It doesn't even look like r-e.org is supporting Auditor anymore.

Download



                     The Code [Click to download version 0.1]

Examples


[Note: When I run BackTrack from a USB stick or a CD, I sometimes have to include the command perl in front of the strings below. I assume this is a path issue even though the shebang at the top of the code is correct.]

 
[root@stinky root]# airraid.pl --interface ath0

This is about as simple as you can go. This will generate fully random (wireless) MAC addresses, no WEP (open), full power, use a random assortment of the built-in default ESSIDs, sleep for the default (0.6 sec) between generations, and use all available channels. The MACs will, in all likelihood, almost never be repeated so any scanners will see a nearly infinite number of APs if they watch long enough.

 
[root@stinky root]# airraid.pl --interface ath0 --power 20 --wep .5

This one creates a bit more variety on the airwaves. This will generate fully random (wireless) MAC addresses, randomly assign WEP keys to half (50%) of the APs, vary power between 0 mW and 20 mw (or the max of the card), use a random assortment of the built-in default ESSIDs and use all available channels. Similar to the example above, this will create a nearly infinite number of APs.

 
[root@stinky root]# airraid.pl --interface ath0 --power 20 --gf group-file.dat

My personal favorite. This will vary power between 0 mW and 20 mw (or the max of the card) but pull all other information from the groupfile called group-file.dat which contains all the information necessary to create n bogus APs. This will cycle through these n APs in random order, sending out beacons. See the tarball or the example below for setting up the groupfile.


Details, Notes and Bugs

As I got the script working with my card, I noticed that it was quite effective at throwing a lot of trash onto the 802.11 spectrum. You could quickly fill up a Netstumbler, Kismet or Airodump screen with random stuff. However, if the purpose was to make it appear as if the area was filled with access points, simply pinging the world with a MAC and ESSID wasn't enough. A person using these scanning tools could easily sort by activity and detect the real access points -- they were the ones that sent out more than one beacon! So the solution was to emulate a very talented juggler. We could create several dozen MAC/Channel/ESSID/WEP combinations (our "balls") and continuously cycle through those to create repeat beacons (catching and juggling the balls). To the casual observer, these appeared much more like real access points.

So I added the option of loading a "group file" which is nothing more than a comma-delimited text file containing MAC,ESSID,WEP(Y|N),CHANNEL. Here is an example one I used for testing:

 
00:00:0C:4B:26:73,Cisco,Y,2
00:00:0C:30:AD:A1,Cisco,N,8
00:00:CE:22:74:D2,Wireless,N,6
00:04:54:90:4D:87,Access Point,Y,6
00:60:70:14:D7:55,Cisco,N,3
00:00:0C:C2:02:99,intel,Y,2
00:00:0C:32:A2:A1,linksys,N,8
00:07:45:12:27:1D,Radlan Wireless,N,6
00:00:CE:A7:5C:1C,Netgear,N,6
00:0C:41:CA:78:18,linksys,N,7
00:0C:41:9D:C9:01,linksys,N,3

The code cycles through those randomly, sends out a beacon, and keeps cycling through the list. I don't know how many you could actually have in this group file. I'm thinking after about 50 most of the scanners might think the APs had gone off the air due to lack of activity. Your mileage may vary depending on how fast you can get it to cycle with the --sleep option (more below in the Options section).

There are some user configurable options near the top of the code. You'll want to confirm that these items are correct.

 
###########################################
#### User Defined Variables ####
###########################################

my $MAX_CHANNEL = 11;                              # North America
my $IWCONFIG    = "/sbin/iwconfig";                # location of iwconfig
my $IFCONFIG    = "/sbin/ifconfig";                # location of ifconfig
my $WLAN        = "/usr/local/bin/wlanconfig";     # location of wlanconfig
my $MACC        = "/usr/local/bin/macchanger";     # location of mac changer
my $BASE        = "wifi0";                         # Base MadWifi device

my @words = ( "Access Point", "tsunami", "host", "airport", "linksys",
              "Netgear", "Cisco", "Wireless", "2wire", "intel", "WLAN" );
my @vendors = ( "00:00:0C:", "00:00:CE:", "00:00:EF:" );

##########################################
#### No User Variables Below ####
##########################################

As I said, I got this working with an unmodified Backtrack2 install so I don't believe the prerequisites are that outlandish.

Getting the MAC change to work was an adventure. I assume it is simply my admitted ignorance of the MadWifi drivers. At first it didn't want to change at all using standard ifconfig options. Once I started using macchanger it got a bit better but it had the odd bug of changing one-behind my requests. That is, I would only get MAC changes on every other request. I tried various combinations of wlanconfig creation, destruction, activation, etc. but it didn't seem to work correctly. This led to a really bogus appearance on any wireless scanner as it would show the same MAC address for two APs. What I finally devolved to was simply disabling the interface, setting the MAC twice, and then reactivating the interface. Its hokey but it works. Someone who is smarter on the MadWifi drivers: please show me the way....

The code is messy. There are icky, negative if-then-else statements all over the place and it is completely void of comments. As I said, this is beta stuff. Learn to love it.

Known Bugs:

1. When operating in fully random MAC mode (--rmac 0) which is the default. What it prints out to the console is not the actual MAC address used for the bogus AP. I use the -a option in macchanger to generate the random MAC and what the script prints out is never actually used or sent to the card. An annoyance I'll probably not fix.



Options

Many of the options are identical to fakeap. Here is a short summary. There is, of course, a usage dump if you don't enter any options. You might also take a look at the Examples section for some example command-line entries.


Prerequisites


Notes on the WG511T and BackTrack

Based on the Googling that this web page has received I suspect there might be many people out there struggling to get their Netgear WG511T working with BackTrack. I'm no expert but let me offer the following command which might get you working with things like Kismet and Airodump-ng:

wlanconfig ath1 create wlandev wifi0 wlanmode monitor

What? That wasn't totally obvious? ;-) So what does it do?

We won't go into all the details here as the MadWifi folks actually have some pretty good documentation. Yet a quick explanation would be something like this.

wlanconfig is the main operator we use to create the virtual access point (VAP) ath1. You will usually already have an ath0 interface but even if you don't, you can create the ath1.

wlandev wifi0 defines which device we are going to attach the VAP to. wlanmode monitor tells us what mode we are going to be in. In this case obviously that is passive or monitor mode. There are some really neat things you can do with the wlanconfig command. See their documentation for more ideas.

Now you can manipulate the ath1 interface just like any other interface with ifconfig and iwconfig. You might also want to look at the iwpriv command and what options are available there.

The attentive will notice that we rely on these commands heavily in the airraid code.



Copyright 2007 Pettingers.org

Vectors at

pettingers.org