Feature requests

If you have a good idea for a feature but can't create the code yourself, talk about it here.

Ability To Resume Cracking Attacks

It would be nice if the user could stop a cracking attack and resume it at another time. Maybe this could be saved in the .kismac file.

Aireplay-ng

At this point in time, (i.e. 0.21a r136), I think I can safely say that the ARP/ACK packet replay feature that is implemented in KisMAC isn't very effective. Now, don't get me wrong, it is a fantastic feature, but only works under ideal conditions (i.e. against b networks with b clients). This may or may not change once we get g drivers to send traffic, maybe the upcoming atheros changes will be beneficial, but since most of the devs and users already own prism2 cards, it might be nice to improve the program for all of those users. Right now, prism2 cards can perform this feature due to their ability to send raw frames. However, as prism2 cards are b speed cards, they do not see a lot of the traffic on g speed networks, which are now the standard for wireless speeds. There also seems to be a problem with the prism2 cards detecting ARP replies when the replay is, in fact, succeeding. When monitoring my network in ethereal with a g speed card in realtime, I could plainly see that if the ARP packet used in KisMAC's reinjection is one directed at an associated wireless client, it DOES generate fresh responses. KisMAC does not, however, see these responses with a b speed card. This lack of detection of responses renders this feature useless on g speed networks with prism2 speed cards.

This does not, however, have to be the case. Aireplay, the packet reinjection utility included with Aircrack, has a variety of tools that allow the user to detect, decrypt, forge, and reinject ARP request packets. The detection feature is already implemented in KisMAC, that's no big deal.  Aireplay-ng has integrated KoreK's  ChopChop program that allows a bruteforce decrypting of ARP packets. Since these packets are so short (68 bytes), it doesn't take much time to do this. Decrypting ARP packets would not only give the user the information about source and destination IPs and MACs, it would also allow Geoff's IP address resolution feature to see clients' IPs on encrypted networks (it would take a while for ARP packets to build up for each client, but theoretically it would work). Decrypting the packet would allow the user to forge an ARP packet based upon the destination IP and MAC information. ChopChop has basic XOR and CRC encryption information integrated, so we wouldn't have to worry about failing CRC checks.

The other options of aireplay are also a bit more sophisticated than the reinjection implemented in KisMAC (though I may be mistaken, please correct me if I am). The  basic ARP reinjection feature allows you to specify source and destination MACs for the ARP packets that you have captured. This MAC information is easy to see in the details window of KisMAC, and may be a more focused reinjection than what we have now (please correct me if this is what's already implemented in KisMAC).

Another option of aireplay-ng is an  interactive packet replay. I have seen requests for this before on the trac, or at least allowing the user to skip failing packets quicker. The interactive replay allows the user to choose the packet to reinject. This would be useful for the same reasons as the attacks above, because you can look for ARP/ACK packets with the correct destination MAC to help get a better response.

Well, that's enough info for now. Aireplay-ng is written in C. I haven't looked through it closely, and I'm not a programmer, but maybe we could integrate it in the same way that Aircrack was integrated. This is just a feature request, but I think that it would render packet reinjection in KisMAC much more useful than it is now. Please respond to this post with ideas, complaints, etc.

--rollfaster

Brilliant idea, after looking into aircrack-ng and attempting to boot auditor on my macbook pro it seems that more control over packet reinjection would be good, the prism2 chipset may do for a good while longer but whereas the linux tools have moved on - we are still here.

Opinions?

Marscom.

Hey guys, I agree that this would be a great feature. As another idea (don't know how easy or hard this is), could we inject the packets with the prism2 card and then check for the results with our airport card in passive mode? If this is unfeasible, let me know.

Christian.

Truly a very good idea, the reinjection in KisMAC is fairly outdated, but I must say that implementing a good working ralink driver which also is capable of reinjection would at least solve quite a few problems. What I do now is sniff with KisMAC and a Prism2 usb card and the reinjection is done with a BackTrack VMware image which runs in VMware fusion on my MacBook Pro, and I must say it has proven quite effective, though I must say the aircrack-ng suite (aireplay-ng aircrack-ng packetforge-ng airodump-ng) need quite some study to really be able to use them thus integrating them into KisMAC would be a great (read difficult) job...

jeroenimo

Auto Save

My setup crashes a little too often. More than once have I lost my data due to the spinning ball of death.

An AUTO-SAVE function would be great. Now that KisMAC resumes scanning after a manual save it doesn't seem far to include a timed save action.

An option to set the interval

• 30 Seconds
• 1 Minute
• 5 Minutes
• 10 Minutes
• 30 Minutes
• custom value

would be great

Try using AppleScript

tell application "KisMAC"
	activate
	repeat
		startScan
		delay 5 * 60
		save "~/autosave.kismac"
	end repeat
end tell

If you save the PCAP file, that's saved live, so you can reimport it. Doesn't help with GPS data though - GPX import, gpsd and cgpxlogger would do it...

or you can use  SaveCircle (free)

AutoSave Capture Data

Capturing packets can take a long time, especially when re-injection cannot be used for whatever reason, I would love to see an option to auto-save the captured data every definable time period. Then if KisMAC dies for whatever reason you would only lose data captured since the last auto-save.

It sounds as though it should be trivial to implement, could someone comment on that ?

Regards, ink_.

Bruteforce Attack against 2wire routers

On their default settings, 2wire routers, (2wireXXX) use a 40-bit key. there are 10 billion possible keys, which would take significantly less time to crack then the already-implemented 10-bit allchars attack (over 1 trillion possibilities).

• They're 40 bit keys, not 104. 20k data packets and PTW make quick work of them. --Fish

Detect & Unload OS Drivers

From JN2 on  the forum: "With my current setup on a powerbook with a PRISM 2 card, I have the SourceForge driver installed to use the card to connect, and KisMAC automatically unloads it and puts its own driver to scan. Can't KisMAC make a similar behavior with USB devices - unload whatever driver is there, and load its own scanning code? If KisMAC is unable to reload the original driver on exit, I wouldn't mind doing a reboot to use the regular driver, but repeatedly installing and uninstalling it seems hokey and a nuisance."

Display B/G in Main Window

It would be nice if the main window listed whether an AP supports b or g (if the highest supported speed is 22 or less, its b). I'd also like to see if there are re-injectable packets in the main window. Fake AP detection (with the ability to hide them in the main window) would also be cool.

Good ideas, how do you propose we detect fake APs? Do they have any identifiable characteristics we could use to pick them out?

Isn't it 11mbits or less for B? -- themacuser

802.11b is 11Mbits, but a few vendors made products that used two channels at once for 22Mbits. I wouldn't know this if it wasn't for KisMAC :)

FakeAP itself doesn't have any documentation on the net, but Laurent Butti wrote proof-of-concept wi-fi tools including a improved FakeAP called rfakeap (for raw fake ap). He explains how FakeAP works and how his version works  here. Short version is that FakeAP runs iwconfig over and over again so the APs all have a BSS timestamp of milliseconds and the same sequence number. Fake APs created by rfakeap don't have these properties, but the BSS timestamps should have noticeable errors. It also doesn't fake any management traffic other than beacons or probe responses, so spoofing authentication requests could weed these fake aps out.

rfakeap is pretty new, it might not be worth worrying about unless it becomes more widely used, the fakes made by original  FakeAP should be detectable by looking at BSS timestamps.

Distributed Computing Idea

This is probably completely unfeasible, at least not for a long time but the ability to run KisMAC over a network on two or more computers would be useful.

• You could use more than one machine to triangulate a signal.

Interesting, yeah. Might work.

• Would this make it possible to reinject packet using multiple sources? I know you can do that with two cards on one computer, just wondering if having more computers reinjecting would make a difference. (Please forgive me if this a really stupid thing to say.)

Might as well use multiple cards.

• You could distribute the cracking, meaning it wouldn't take half an hour to do.

Yeah. jcwepcrack would help here.

• You could bruteforce keys (with the distributed computing sharing information on what they have tried) to try and do this quicker. (I know this is as subtle as a sledgehammer.)

Brute-force it to the pcap, not the network - you can check keys against the captured packets.

gpsd Raw Mode

If we send the command r1 to gpsd, we can get the NMEA straight off the GPS, (or converted NMEA for binary GPSes) and use our already functioning NMEA parser, which in my experience works more reliably than GPSd.

We should probably have an option for this in the GPS preference pane.

themacuser

---

The main problem here is that GPSd has lost the plot a bit lately. However, I've spent the past couple of weeks trying to fix all the things that have been broken recently, and now have a 100% functional gpsd on my system... and hopefully I'll be able to convince the lead developers to incorporate my patches. Using "r" mostly defeats the purpose of gpsd - it would be better to continue using either the existing compound query, or watcher mode (if we want the GPS to "push" data to KisMAC).

I certainly can do the coding you describe, but I think fixing the source of the problem (gpsd) is better than adding an extra - and potentially confusing - preference & workaround to KisMAC.

robin

---

Using R doesn't really defeat the purpose of gpsd, in my opinion, the purpose is so you can have multiple GPS apps sharing the GPS.

themacuser

---

well it should also been an abstraction of the NMEA protocol, which is a little lets say "odd"... and not every gps device should have to use it.

mick

---

Yeah, the trouble with NMEA is it's not exact... the standard is a bit lenient and not followed by everyone. gpsd is a good workaround but doesn't work right with a lot of NMEA GPSes compared to KisMAC's NMEA parser which works a LOT better with mine.

themacuser

MAC Addresses

Why not integrate MAC Address spoofing functionality, like the spoofmac program?

We have been discussing this and are pursuing a method to implement MAC address spoofing into a future release. Please see ticket #49 for more information.

Or at least you could make the MAC Addresses text selectable for copying to an other application.

Manually Enter WEP Key

KisMAC already allows the user to decode packet dumps. This is located under "File>Decrypt PCAP Dump". If this is not what you are referring to please explain more here.

---

I'm guessing he means a way of inserting a wep key that has been found via other methods, so that he can keep things organised. Pretty useful if you ask me

---

I'll look into it -- themacuser

---

also it will be nice, if you can insert the hidden network name manually, if you know it already.

Minimal GUI

I was looking at the GUI modification on ticket #38 (which btw looks really great) and was thinking that it would be cool to have a minimal user interface as well. Something very similar to  ipulse or a widget. I use ipulse all the time because it is useful to have that information in a small form on my window, whilst still allowing me to do other stuff at the same time. So I did a mock up of what KisMAC could look like with a similar sort of theme.

This is the normal reduced mode, with a kind of radar where the closer to the center of the radar, the higher the average signal to noise ratio. The blips represent networks, with the inside colour being the probability of being able to crack (as mentioned in a ticket somewhere) and the outside colour representing the encryption type.

Hovering over a blip brings up the information box shown here:

You can see all the usual KisMAC information. I guess there should also be a button to resume full mode as well.

These were done in photoshop, they have not been coded in anyway (as I will have to learn carbon/objective c to do this probably, unless it can be easily done in c#)

any thoughts? --madhatter

• I like your ideas, the radar is particularly interesting. I like the idea of using KisMAC with the main window closed. We currently have growl notifications which give the user information about discovered nets without having to look at the main window. Perhaps we could combine this with your idea ( maybe as dashboard widgets? ) and have what would basically amount to background scanning. Keep thinking about this, this could be an excellent addition to 1.0 --Geoff

• i like it -- mick

• Great idea. We could actually have a dashboard widget that communicates with a command-line tool, or on a tcp socket with KisMAC.
  

Perhaps a tcp KisMAC protocol would be good - we could have remotely controllable KisMAC drones, like can be done with kismet. Or alternate GUIs over it. Or stuff like those two dashboard widgets. It might be a lot of work to split the two halves of KisMAC, and I don't think that should be done, just have it remotely controllable, so we can have stuff like this, maybe even working over the network. Put a second wireless adaptor in the machine if scanning with passive mode though. -- themacuser

• I can manage the css/html styles for the things I designed, that might help kickstart the whole thing, I'll have a look at doing that this weekend and then post them up. --madhatter

Minimize To Menu Bar

An option to minimize to the menu bar as apposed to the the dock.

Next SSID Button

This seems to be a simple add-on. When looking the network details in the GUI it would be nice to have a button to jump to the next SSID in the list, and even the previous.

Optimize Sorting

When the list of networks grows > 1200 or so, sorting the nets starts to beachball KisMAC. We should do some type of optimization where we sort the entire list once, then each update should only sort the networks visible at the time. This will take some work to get it to work right, for example, what do we do when the user decides to scroll down the list? Also, maybe we could break the long sorts into a separate thread so that KisMAC does not beachball while trying to update the display. This would also be a lot of work.

-> This is what KisMAC does already

--> I haven't found this. --themacuser

---> WaveContainer.m: sortByColumn does an unstable QuickSort (which is pretty fast) and sortWithShakerByColumn does a stable ShakerSort, which is called upon update

---> If this is the case, then we need to find what is causing the beach balling. To reproduce: Have > 1200 nets and have the last seen or signal (or other fast updating column) selected. The reason I thought this was a sorting problem is because the issue occurs with one of these columns selected but goes away when you sort by net #. The symptom is that the channel indicator gets "stuck" for 5 - 10 seconds and the cursor beach balls. As you continue to gather more nets, the problem increases. I will try to do some profiling to see what exactly is causing the problem for me.

-> given shark.app a go in profiling around this time?

Recommended Crack

A line in Show Details which lists the recommended cracking mode based on the vendor & encryption would certainly be useful.

Some Small GUI changes

It would be nice to have a "next ssid" button on the "network information" dialog to jump to the next network on the list. It may also be nice to be able to try a wep key manually in this dialog in case you suspect you know it but don't want to try it on active mode.

How about the ability to increase the font size?

themacuser's

 http://gm.stackunderflow.com/blog/pivot/entry.php?id=34

What have I got planned?

• 802.11a support on atheros 802.11a cards.
• Not restarting the GPS subsystem every time something is touched in the prefs window - very annoying, and sometimes it doesn't restart properly. Only restart if the GPS was changed or something earth-shatteringly important happened.
• Adding satellite info to the GPS prefs.
• Improve the look and readability of the data over the map.
• Make the map draggable.
• Manual WEP key testing.
• Look at a possible bug regarding IVs.
• GPS speed indicator - maybe with progress bar, or like xgpsspeed.
• Update the vendor DB again.

Triangulate Position

I have modded my Titanium G4/667 with an external 6dB gain antenna on the internal AirPort card, and also use an SMC 2532W-B 200mW PC card with an external 4dB gain antenna, so I pick up access points from quite a distance... Since Kismac seems to log the GPS coordinates from the first position that the network was visible, the location that is plotted on the map usually bears little resemblance to the actual location... My first recommendation is to log the location of the strongest signal, instead of the first visible position...

It should be logging it to the strongest position... someone tried to make it log the first seen one. Might want to have a look at this... --themacuser

Ideally, it would be cool if KisMAC could log several points/signal strengths so that it could triangulate the position (at least a close approximation). The problem I see is that driving down a street in a straight line with an omnidirectional antenna, it would be difficult to determine which direction (laterally) the signal originated from... You might only be able to determine the point where you are directly perpendicular to the signal, and approximate the distance away, without knowing if it is to the right or left? I'd like to be able to drive around the block, for instance, and collect enough data points to be able to calculate the location accurately... Perhaps if there was an option to log the datapoints into a local MySQL database or something, so that over a number of trips of "war driving" you would be able to collect enough data to calculate the location?

I asked about this a few years ago, but I never posted the URL I was thinking of:  http://www.dmzs.com/tools/files/wireless.phtml with multiple GPS points for an AP it would be easy to plug into carte.

Wordlist Support For Netgear And Linksys Type Keys

Under wordlist attacks there is 100 and 40 bit Apple key attack. It would be nice if there was an equivalent for Linksys and Netgear routers.

Since we can detect the vendor of the router, maybe we could do this automagically instead of adding to an already deep menu tree.

WPA Challenges Counter

It would be nice if KisMAC could record, in window, how many more challenge packets it has left to capture before the WPA network is crackable. A section that would only be visible only for WPA networks that would list the types of challenges. When a challenge is captured a check mark could appear next to the type in the list.

Or maybe commit this patch in ticket #47?

P.S. The growl challenge notifications are great but don't help when the user is AFK.

WPA Challenge/Response? Sounds

In the same sense that a counter would be good for those users who leave scanning active while AFK, a sound would be great for those who aren't quite AFK, but are nearby with the machine clamshelled or with the screen completely dimmed.

I've actually been looking into the code lately and might try to implement this and submit a patch, but no guarentees.

The CH/RE gem is a good start, but in the time it took me to type this entry, the gem illuminated and I somehow missed the Growl notification.

Anyway, seems like it'd be an additional convenience factor that'd be easy to do.

-alchemyandthunder

I thinks that at this point, a better way is to implement configurable notifications, as adium does (see preferences->events).

- pr0gg3d

That would be definitely be optimal. You're essentially saying that each possible notification that KisMAC could do would have an INDIVIDUAL sound setting — both in selected tone and whether played or not. Great idea, pr0gg3d. I think speech should still be an option... Maybe even in addition to a sound... Especially if the notification involves a specific network. (I'd like to hear "(BEEP) WPA Challenge recieved for SSID 2WIRE259")... Not that anyone that uses a default SSID name would have WPA, buuuuuuuuuuuut...

-alchemyandthunder