2013-03-R1 is released; get it at the usual spot. Primarily bugfixes which needed to happen; fixes include better terminal support in some terminal configs, better behavior on channel control by taking down the controlling vap, radiotap parsing fixes, and a bunch of other cleanups and bugfixes.
Phy-neutral is still cooking in the git codebase.
Thursday, March 28, 2013
Monday, March 18, 2013
Kismet-2013-03-R1 baking....
Ramping up to release Kismet-2013-03-R1.
This release isn't terribly exciting - it's mostly 2 years of bug fixes pulled out of the dev tree, because a release with those fixes really needed to happen.
Phy-neutral is turning out to be excessively invasive so it's not included in this release - expect another hopefully in the not too distant future with major changes and new features.
For those who want a preview of 2013-03-R1, it's in the Git tree under the Kismet-2013-03-R1 branch. If you notice any issues let me know before it goes to release and packaging.
Fixes include some memory management, a radiotap alignment issue creating bogus channels on some systems, downing the primary vap in mac80211 to get network management tools to leave us alone and not break channel control, libnl3 support, gps fixes, and general other goodness.
Anyone using 2011-03 or earlier, this upgrade is for you. Anyone following git already, nothing to see here.
This release isn't terribly exciting - it's mostly 2 years of bug fixes pulled out of the dev tree, because a release with those fixes really needed to happen.
Phy-neutral is turning out to be excessively invasive so it's not included in this release - expect another hopefully in the not too distant future with major changes and new features.
For those who want a preview of 2013-03-R1, it's in the Git tree under the Kismet-2013-03-R1 branch. If you notice any issues let me know before it goes to release and packaging.
Fixes include some memory management, a radiotap alignment issue creating bogus channels on some systems, downing the primary vap in mac80211 to get network management tools to leave us alone and not break channel control, libnl3 support, gps fixes, and general other goodness.
Anyone using 2011-03 or earlier, this upgrade is for you. Anyone following git already, nothing to see here.
Wednesday, January 2, 2013
Quantal packages
Added Quantal packages (yeah, I know, it took me a while, I suck) to the downloads page for Kismet.
Friday, December 7, 2012
Android, G+
Two new Android projects finally released:
http://www.kismetwireless.net/android-pcap/
Android PCAP Capture, which uses a userspace RTL8187 driver to do rfmon without requiring a custom rom or root. Makes standard pcap files!
http://www.kismetwireless.net/android-cloudshark/
Of course once you have packets, how do you do anything useful with them on Android? Answer: Upload them to http://www.cloudshark.org and get Wireshark in your browser. CloudShark Uploader acts as a "Send file..." shim in Android, so any file manager (or Android PCAP Capture, natch) can send directly to the public CloudShark site or to a private CloudShark appliance.
Finally, made a G+ community to discuss wireless hacking and related. Can't seem to link to the community directly, so here's a public post advertising it w/ a way to join:
G+ Wireless Hacking Community
http://www.kismetwireless.net/android-pcap/
Android PCAP Capture, which uses a userspace RTL8187 driver to do rfmon without requiring a custom rom or root. Makes standard pcap files!
http://www.kismetwireless.net/android-cloudshark/
Of course once you have packets, how do you do anything useful with them on Android? Answer: Upload them to http://www.cloudshark.org and get Wireshark in your browser. CloudShark Uploader acts as a "Send file..." shim in Android, so any file manager (or Android PCAP Capture, natch) can send directly to the public CloudShark site or to a private CloudShark appliance.
Finally, made a G+ community to discuss wireless hacking and related. Can't seem to link to the community directly, so here's a public post advertising it w/ a way to join:
G+ Wireless Hacking Community
Tuesday, September 4, 2012
USB Host on Android
Android 4 supports USB host. This is great!
Does it actually work? Wellll.... sort of.
Observations so far:
I'm working on a USB power injection board which provides micro-usb ports for phone and battery packs (on the assumption that everyone has a ton of micro cables handy by this point), an integrated one-port USB2 high-speed hub to handle power budget problems, and a standard female USB socket for client devices.
Could you solder together some cables and get the same effect? Sure. You could also use a no-logic power splitter board like one I made earlier. But it's really ugly, and prone to falling apart at the worst moments.
So I'd rather do it cleanly.
Does it actually work? Wellll.... sort of.
Observations so far:
- Galaxy Nexus: Works fine with OTG cable, huge power budget.
- N7: Works fine with OTG cable, huge power budget
- Xoom 1: Some things work, some don't. "Simple" USB ops seem fine, but complex stuff (like driving a USB wifi NIC) seem to blow up.
- Motorola Razr Maxx: This one is extra weird. USB host exists, but requires a +5v backfed power, with enough amps on it to charge the phone in host mode. That's a hell of a thing. The Razr also enforces an excessively small power budget (so small I'm not sure it allows ANY device to function) unless a hub is in the chain. It doesn't even have to be an externally-powered hub! (Well, except that you have to externally provide USB power regardless).
- HTC One V: AKA the Ninja Phone, is reported to have non-working USB host due to kernel bugs. Custom ROMs only?
- Other phones: No idea, let me know in the comments?
I'm working on a USB power injection board which provides micro-usb ports for phone and battery packs (on the assumption that everyone has a ton of micro cables handy by this point), an integrated one-port USB2 high-speed hub to handle power budget problems, and a standard female USB socket for client devices.
Could you solder together some cables and get the same effect? Sure. You could also use a no-logic power splitter board like one I made earlier. But it's really ugly, and prone to falling apart at the worst moments.
So I'd rather do it cleanly.
Friday, May 4, 2012
KisBee status
Latest status on the KisBee zigbee sniffer project:
* Version 2 of the boards is done, and looks like it will be the final rev:
It uses the Microchip MRF24J40 integrated radio board, which puts all the RF on the radio module and doesn't require a quad-layer PCB. This makes assembly a lot simpler.
* Prototype build of V2 boards done and tested, except for battery charger circuit:
It will work with either a case/chassis-mount antenna jack, or a PCB edge connected SMA adapter and a RF jumper cable.
* Firmware is based on the microbuilder lpc1343 library and is largely done; radio packet reception works, bluetooth link works, usb link works.
* Battery pack will be Li/Poly and should provide a reasonable run time; the majority of the power will be drawn by the zigbee and bluetooth radios.
Assuming all goes well, hopefully the firmware will be finished soon, emulating a zigbee-serialdev, then the fun of getting proper zigbee decoders in Kismet starts, the current zigbee code isn't written for phy-neutral and isn't very good right now.
As long as the battery charger circuit works out (waiting on some connectors) then the board is ready for larger-scale fab and hopefully I can think about offering kits soon for those who are interested.
More info at:
https://www.kismetwireless.net/kisbee/
* Version 2 of the boards is done, and looks like it will be the final rev:
It uses the Microchip MRF24J40 integrated radio board, which puts all the RF on the radio module and doesn't require a quad-layer PCB. This makes assembly a lot simpler.
* Prototype build of V2 boards done and tested, except for battery charger circuit:
It will work with either a case/chassis-mount antenna jack, or a PCB edge connected SMA adapter and a RF jumper cable.
* Firmware is based on the microbuilder lpc1343 library and is largely done; radio packet reception works, bluetooth link works, usb link works.
* Battery pack will be Li/Poly and should provide a reasonable run time; the majority of the power will be drawn by the zigbee and bluetooth radios.
Assuming all goes well, hopefully the firmware will be finished soon, emulating a zigbee-serialdev, then the fun of getting proper zigbee decoders in Kismet starts, the current zigbee code isn't written for phy-neutral and isn't very good right now.
As long as the battery charger circuit works out (waiting on some connectors) then the board is ready for larger-scale fab and hopefully I can think about offering kits soon for those who are interested.
More info at:
https://www.kismetwireless.net/kisbee/
Monday, March 12, 2012
Android hidden AP weirdness
@jduck1337 brought this to my attention:
http://seclists.org/bugtraq/2012/Mar/50
It was too long-form to continue the discussion on Twitter, so here we go:
The bug is, basically, that when looking for a hidden AP, Android doesn't care what the BSSID of the response is, ie, it doesn't cache the BSSID of known hidden SSID APs.
This actually doesn't seem, to me, like a bug at all. The BSSID is not relevant to association, the SSID defines the network. On a multi-AP roaming network any number of BSSIDs could reply to a probe request for a hidden network.
The assumption that being able to reply as the hidden network leads to loss of credentials doesn't make any sense either: Sure, the client will try to talk to you to do a WPA handshake, but if you don't know the key, it won't succeed, and it trying to associate won't give you insight into the key. Also this doesn't give you anything that setting up a generic rogue wouldn't give you.
So unless there's something I don't understand going on, I don't see the threat. I don't even see the bug - when you send out a probe to see who is out there, you have to expect any number of responses, and the whole mechanism of roaming is to go to a new BSSID. From the bugtraq post:
http://seclists.org/bugtraq/2012/Mar/50
It was too long-form to continue the discussion on Twitter, so here we go:
The bug is, basically, that when looking for a hidden AP, Android doesn't care what the BSSID of the response is, ie, it doesn't cache the BSSID of known hidden SSID APs.
This actually doesn't seem, to me, like a bug at all. The BSSID is not relevant to association, the SSID defines the network. On a multi-AP roaming network any number of BSSIDs could reply to a probe request for a hidden network.
The assumption that being able to reply as the hidden network leads to loss of credentials doesn't make any sense either: Sure, the client will try to talk to you to do a WPA handshake, but if you don't know the key, it won't succeed, and it trying to associate won't give you insight into the key. Also this doesn't give you anything that setting up a generic rogue wouldn't give you.
So unless there's something I don't understand going on, I don't see the threat. I don't even see the bug - when you send out a probe to see who is out there, you have to expect any number of responses, and the whole mechanism of roaming is to go to a new BSSID. From the bugtraq post:
5. Turn off the first AP 6. Turn on the other AP 7. See your Android device automatically connect to the second AP
This is exactly how roaming is SUPPOSED to work, this doesn't seem like a bug to me. Anyone see something I don't?
Subscribe to:
Posts (Atom)