Assume the following for this How-To:
Laptop/Workstation IP address: 192.168.0.30
Router IP address: 192.168.0.252
Router is a WRT54G V1.0, V1.1 or V2.0
Hacked Firmware is Sveasoft's Satori_v2_2.00.8.7sv-pre1.bin
1.1 Obtain a Linksys WRT54G Router. Revision shouldn't matter, I will note any differences necessary for different Rev's.
WRT54GS w/Speedboost is supposed to work as well. I don't have one so your on your own. Let me know if it does and any changes nessecary and I will add them to this guide.
Note from grcore on the NS forums:
"Note there is now a new version of the WRT that the 3rd party firmwares have trouble with. The new version are the WRT54Gv.2.2 and the WRT54GSv1.1
They use a broadcom switch chip instead of the ADM6996, and if you flash it with firmware that does not have the new chip support built in, you will loose your switch ports and then will have to flash back via wireless.
2.1 Setup the router according to the included instructions so you can reach the web control panel.
2.2 Download a custom firmware that provides SSH access and telnet capabilities. I used the Satori_v2_2.00.8.7sv-pre1.bin firmware from Sveasoft (Due to some wierd licensing I'm not going to mirror the firmware, but just Google for it), you can use others such as EWRT but your milage for the rest of these instructions though may vary. The rest of the instructions assume the sveasoft firmware.
2.3 Connect to the web control panel on the router. Using the Upgrade firmware button under Administration - > Upgrade Firmware, Violate your warranty by loading the custom firmware.
3.1 Log back into the web control panel after the necessary reboot of the router and you should see "Firmware Version: Samadhi2 - v2.00.8.6sv " in the top right corner instead of the Linksys one. There should also now be alot more options available to you throughout the control panels. You should poke around and see what other wonderful things these routers can be made to do.
3.2 Setup the router to a static address (non DHCP), and setup your laptop/workstation to a static IP on the same class C network. (i.e. router set to 192.168.0.252 and your laptop/workstation to 192.168.0.30)
3.3 Through the Administration -> Managment control panel, Enable 'Boot wait','SSHD', 'SSHD password login'. I also enable 'telnet' as a backup to SSH.
3.4 Under the Wireless - > Basic Settings control panel, set the router into client mode
3.5 Using PuttyGen or however you like to generate keypairs, generate an RSA public/private keypair. It's easiest if you don't set a keyphrase (the router is not in a position to be hacked, so security is a low priority, the SSH key just allows us a way to push the files to the router). Copy the private key text into the 'authorized SSH keys' field. Since the router has no storage for usernames/passwords we must use SSH keys stored with the routers other settings. Multiple keys can be loaded.
4.1 Download precompiled Kismet drone binaries (local mirror) and unpack the directory.
If you are using a v1.0 or v1.1 router, edit the kismet_drone.conf file
source line to use 'eth2'
source=wrt54g,eth2,wrt54g
If your using a v2.0 make sure it's '
eth1'
source=wrt54g,eth1,wrt54g
This tidbit from imonfya on the NS forums might be useful:
I know with sveasoft alchemy rc6 firmware you have to change the
source from wrt54g,eth1,wrt45g to wrt54g,prism0,wrt54g.
4.2 Using the above SSH key and username root, use your favorite SCP client (Such as Winscp) to upload the kismet directory to /tmp on the router. Set the files to executable (chmod 755).
The routers /tmp directory is in volatile RAM so every time you unplug the router you need to upload the drone binaries. This can be easily scripted in Linux with the SCP command or in windows with pscp. Hopefully a future firmware will include it in the image and we won't have this problem.
Anyone who can help me figure out how to roll my own firmware, please let me know
5.1 Setup the Kismet.conf file on your laptop/workstation to use 'source=kismet_drone,192.168.0.252:3501,drone'. You can run other sources at the same time (wi-fi cards, other drones) on separate source= lines.
The source line breaks down like this:
Kismet_drone indicates this is a remote drone source,as opposed to a local card source.
192.168.0.252:3501 is the TCP/IP address and port that the drone is running on. You can change the IP address to whatever you setup your router to. You should'nt need to change the port.
drone is just an arbitrary description that is shown in the bottom right corner of the kismet window in the sources list. You can change this to whatever you want for organizational purposes.
Read the Kismet Documentation if you want more clarification about source types, etc.
Make sure the wired network card is up and connected to the router and can talk to it. Telnet into the router in another window or terminal (no password should be asked for) and run the following commands:
wl disassoc - Lets make sure it's not associated with anything
that could screw up our detection
wl passive 1 - Throw the router into passive mode, prevents any
transmission and slipping into murky legal areas.
chmod -R 777 /tmp/kismet - Make sure the drone binaries are
executable
/tmp/kismet/bin/./kismet_drone - Run the drone
You should then see something like :
Suid priv-dropping disabled. This may not be secure.
No specific sources given to be enabled, all will be enabled.
Enabling channel hopping.
Disabling channel splitting.
Source 0 (wrt54g): Enabling monitor mode for wrt54g source interface
eth2
channel 6...
Source 0 (wrt54g): Opening wrt54g source interface eth2...
Kismet Drone 3.1.0 (Kismet)
Listening on port 3501 (protocol 8).
Allowing connections from 192.168.0.0/255.255.0.0
The last line is the most important to see. It means that the drone will now accept connections from servers on the 192.168.0.0/24 network, where our workstation is hopefully set
You should then be able to fire up Kismet and if everything lines up,
you'll see 'accepted streamer connection from
Don't be freaked that the drone is'nt reporting which channel it's on. The routers firmware is doing the channel hopping and can't report it to the server. Another good reason to run the 'wl dissassoc' command above is if the router was associated to another network it might stay locked onto that channel not hop properly. My pesonal lab has 2 AP's on different channels to test this. Took me a while to realize the importance.
It may seem like alot of work to get setup, however all the commands can be scripted very easily. I just used autoexpect to record me typing all of them and just run the stored script to set it all up again.
I used 'scp -i sshkey -r kismet root@192.168.0.252:/tmp/kismet to load the files (where sshkey is a text file with the same private key we put in the web control panel, and kismet is the directory with the drone files in it, downloaded in step 2.2)
I used Autoexpect to 'record' the commands for loading and running the drone files. I've found differences on systems make the scripts less than portable. If someone wants to pound out a perl script or something, that would really be nice :)