Why to create a new tool if we already have tools like Vistastumbler.
Below I wrote some of the reasons:
- Lately been playing with Windows WiFi Native API(Abusing the Windows WiFi native API to create a Covert Channel).
- Wanted a command line tool (Vistastumbler is out).
- Wanted something a little bit more flexible that netsh.
The problem is when you have a big list of networks, it would be nice to have a simpler output to see networks easily. I also think that the information provided is not enough for someone that has advance knowledge on wireless networks and wants some extra information.
So the tool I wrote has two output mode for now(I thinking in adding some more that are useful when working with other wireless tools).
Simple Output
Verbose Output
As we can see wwtool has the capability to show information elements. In this first version the tool is capable of parsing some information elements in case the tool is not able to parse the IE data it shows a hex dump of the information.
Features I'm working on
- Pcap output (yes, the tool is going to be able to dump to a pcap file beacons frames).
- Kismet csv compatible output.
- Keep running so it's useful when wardriving.
- Be able to work with multiple interfaces.
- Add some support for more IE.
Other than getting the verbose data of the wireless router, how is this benefiting one ? Curious why it's important ? Why not use backtrack 5 on vmware player ? anyways . . . . .
ReplyDeleteCH@P$:
ReplyDeleteI think that in the following situations the tool could be useful:
- Wireless information gathering from a Windows machine without an external wireless network interface. As far as I know internal wireless network interfaces are not available from the virtual machine guest OS.
- If someone does not have administrator privileges to install VM software on a Windows machine.
- Remote wireless information gathering. If a pentester has a shell on a compromised Windows machine and want's to get information of the wireless networks near the compromised host.
Maybe someone else could figure out other ways this tool could be useful.
admin:
ReplyDeleteSorry but on Windows XP the WiFi Native API doesn't have support for reading the information elements of the beacons/probe response frames. So it's not possible to do it. The function we are using is only supported from Windows Vista or later.