From MRL Wiki
Note: The official page is here: http://midnightresearch.com/projects/wicrawl
 Project General Description
- wicrawl is a simple AP scanner with a flexible/simple plugin architecture. The plugins allow us to find out useful information about an AP so we don't have to manually check each access point. Plugins are easily implemented by scripts, or any externally called program. Profiles determine your usage type and dictate the plugins you are configured for and the card scheduling algorithm. The plugin engine can handle multiple cards so you can crawl through multiple APs at the same time.
- Most scanners are passive, and just check for the existence of APs. Now that wi-fi is nearly ubiquitous, this becomes less and less useful. The need to go through tons of APs is very tedious, and annoying. Additionally, there are lots of other metrics that can be very interesting to know about an access point.
WicrawlPlugins -- This is the plugins page that should contain information on what exact plugins we have.
Note: Plugins can be written in *any* language. As long as you point the plugin.conf to it, it should work.
 General Architecture
 Discovery engine
- written in C
- Sends IPC messages to plugin-engine through a fifo
- Can take IPC2 messages for filtering and shutting down
- Channel hops over defined channels
- Gets AP data from beacons and probes
- Handles taking cards in/out of monitor mode automagically
 Plugin engine
- Reads its data from the IPC
- Written in perl
- Is in charge of scheduling
- This means starting stopping the discovery engine
- schduling cards and plugins
- Plugins register to a specific event, and choose numerical order
- Plugins can register as either "fast", "medium" or "slow" running, and the plugin engine will run them in that order for each event level for each AP. This is so that slow running plugins don't slow down the overall program. For example a dhcp plugin would register as "fast", and aircrack would register as "slow".
- The engine has three ways of getting feedback from a plugin
- STDOUT -- this is for "user" data that is passed back to the plugin engine to put into a report
- Return codes -- This is for signaling the plugin engine. For example an event-level change for a given AP
- IPC -- Some plugins (like GPSd) can send information back through the FIFO. They have to make sure to lock the fifo, and to send a properly formatted message (see README.developers)
- Plugin engine will cache all state information per AP
- Information is passed to the plugins through command line arguments, through the environment, and from options set in the plugin.conf (for each plugin)
 Profiles, and card/plug-in scheduling
- Profiles are a list of what plugins are selected along with the plugin and scheduling configuration.
- plugin scheduling options are:
- Discover and use first available AP
- Discover on all channels and use best signal
- Discover on all channels and use most active AP
- Rediscover after plugins for a single AP are run (After all APs have been scanned, the default is to rediscover
- Default profiles are:
- Run all plugin run lengths
- Run plugins that are benign (discovery, association, dhcp, etc)
- Run selected plugins that are "short"
- Discover and use best signal
- Rediscover after plugins are run
- Run All plugins
- Don't rediscover after each AP is scanned
- Run All Plugins at all levels
- Don't rediscover after each AP is scanned
 Plugin events
- New AP
- Have association
- Have IP
- Have internet
- pre/post discovery (for hooks plugins only)
- pre/post AP (for hooks plugins only)
- Plugins are configiured by the plugin.conf in each plugin dir
 Other (possible) features
- network IPC so we can run discovery and plugins from many different machines (and cards)!!!
 Project Chunks
- Discovery Engine
- Plugin engine
- Wardriving Rollup Bar
- plugin browser/installer/updater
 CVS Access
CVS is available here:
:ext:email@example.com:/cvsroot co wicrawl
This is on port 222 (in a chroot on the main system), so the easiest thing to do is to add midnightresearch.com into your ssh config:
$ cat ~/.ssh/config Host midnightresearch.com Port 222 $export CVS_RSH=ssh
Please contact me (sith@) if you want an account
CVS commit list and devel list is here: http://midnightresearch.com/cgi-bin/mailman/listinfo/wicrawl-cvs
 Ubuntu/Debian(?) Compiling
To get the nessisary packages to compile :
sudo apt-get install libpcap0.8-dev libxml-smart-perl libgtk2-perl libssl-dev
Then download either Latest Version (Generally most stable), or Daily CVS Snapshot (Most recent) tarballs
tar xf wicrawl-*.tar
Change into the extracted directory
Run "make", then "make install" as root
sudo make install
Finally, run wicrawl, by typing "sudo wicrawl", or making a launcher that starts "gksu wicrawl"
 Experimental Wicrawl Curses interface
Experimental curses interface can be launch with the command line below:
sudo wicrawl -C 2> /dev/null
For the curses interface to work, you must install Curses::UI and Curses::UI::Grid perl modules. The following command works on Ubuntu/Debian installations to get these modules:
cpan install Curses::UI cpan install Curses::UI::Grid
- http://midnightresearch.com/cgi-bin/mailman/listinfo/wicrawl-cvs CVS commit email list for wicrawl
- http://midnightresearch.com/~jspence/802.11-1999.pdf local copy of the 802.11 specification
- http://wiki.ethereal.com/CaptureSetup/WLAN How to enable monitor mode on different systems
- http://www.sanmagazine.com/ Other exploit tools
 Card Support
Wicrawl Card Support -- Page of cards that we support -- please enter working and non-working cards here.
 Road map
WicrawlOSXSupport -- putting this here for now. Will move shortly.
 Known Issues and bugs
 Remaining 1.0 goals
See the /doc/TODO in the package.