Darren Kitchen

It'll support WPA -- you can totally spoof WPA protected access points. All you have to do is change the SSID to that of the WPA protected network you're mimicking and set your MK5 up with the same password* * it's this last bit that's could be an issue. Check with your client and see if they'll authorize a release of the PSK for your pentest. ** Reaver may be useful in figuring out the PSK if your client doesn't have it handy. *** Of course only for use in an authorized audit.

There's a massive overhaul in the works that will have you rethinking Karma completely. It isn't simply a matter of making it "support more devices". That's about as much as I should go into.

We have some promising stuff in the works.

Like others have said and even us and Sammy have demonstrated, the consumer grade WiFi stuff is (purposefully) hackable. On the proprietary side even the toys like the Hubsan X4 series use a very basic 12 bit binding sequence. It's easy to have 1 TX takeover another *at RX boot* but once shes airborne there's it's unlikely to switch to another transmitter without a mid flight reboot. We're working on an upcoming drone series (ofc including the pineapple) and will be using DSM2. I haven't seen any hacks for this protocol (though would love to).

I see. Looks like we need to go over that text. If something isn't working and it's hardware related we typically expedite a replacement. Under most circumstances it's more costly to have it returned than sensible. I was assured by Sara, our HakShop manager, that your replacement is on its way. Very sorry for the inconvenience. This is in fact the first DOA ducky we've had of the latest batch (4 months in).

Anyone try the antenna mod from the latest episode?

Could have been? I'm appalled - it's a great tool and there are plenty of resources for it here and at http://www.usbrubberducky.com Was there something in particular that you're missing? Feel free to search the forums or post a topic!

HappyJackie, I'm really bummed out that you got a dud unit. This almost never happens. We've gone through great lengths to ensure the highest quality of production with the USB Rubber Ducky. We will of course replace the unit at no cost to you. I don't know where you got the idea that the customer would pay for shipping in these circumstances but that is untrue. Why should you pay twice? You should have gotten a working unit the first time and we'll do everything we can to get you a working unit ASAP. I do apologize that it has taken us a day to respond. It can sometimes take 1-2 business days to get caught up with every request and unfortunately this week we're overwhelmed with a WiFi Pineapple flashing issue. I assure you if you leave a voicemail with your name and order number, email us at shop@hak5.org or use the contact form at hakshop.com you will be cared for. If you have any further concerns please don't hesitate to contact us directly. Warm regards, Darren

Thanks for the heads up Whistle Master. I've updated version 1.2 to include the hard coded javascript. Cheers! Edit: 1.3 even. Broke something stupid. All good now :)

Thanks. You're right - why did we ever trust the most critical part of the product at first boot, the firmware loading, to the cheapest part. I'm asking myself the same question as you've well pointed out it's a major damper on the experience. Our hope was to be able to use this method to always ship the latest firmware, but it seems that's not worth the trouble when one could simply update over the air. I'm really bummed about this issue. I've taken to checking every unit and it seems all the cards reformat and reimage the firmware files no problem - so that's what we're doing. Every box is getting opened and given proper attention to resolve this. Our factory has made changes to flash 1.2.0 to the MK5 going forward and we're reaching out to effected customers directly to aid in resolving the SD card issue - with replacements or partial refunds as necessary. I'm sorry I let you all down. It's hard not to take it personally and at the same time I offer you my personal apology. If there's anything we can do to make your pineapple experience better, please contact us directly.

Rock solid with my Novatel MC760. Thanks Seb and congratulations again on the next milestone!

Hi all. I've written an Infusion as a front-end to dump1090. This allows you to nicely track aircraft from your WiFi Pineapple. The infusion requires firmware version 1.1.1+ as that's where we implemented native support for the oh-so-fun RTL-SDR. I've tested it with the DVB-T dongles we (and many others) offer in the HakShop. The infusion allows you to configure a few parameters, start and stop the service, list beacon frames and see aircraft in a realtime map. Screenshots Configuration List view Map view Change log: 1.1 - fixed map tab to work with any pineapple IP (it has previously been hard coded to 172.16.42.1) - prettied up map and list tab in case dump1090 daemon isn't running 1.0 - initial release

This episode explains it all in great detail http://hak5.org/episodes/hak5-1112

Cool, let us know how it goes!

Open networks only. You could in theory spoof WPA/PSK networks, but you'd need the passphrase due to the 4-way handshake.

As of firmware 1.1.1 the supported modems include: If you lsusb your modem and it's on that list -- it'll modeswitch for use as mobile broadband. /etc/The settings you use are dependent on your ISP. /etc/hotplug.d/usb/20-modeswitch will modeswitch and dial your modem upon detection. /etc/pineapple/mobile-keepalive will maintain the connection. I use a Novatel MC760 from Ting. It's VID & PID are 1410:5030. When modeswitched it becomes 1410:6000. For me the settings are: interface name: ppp0 protocol: 3g service: cdma device: /dev/ttyUSB0 username: internet password: internet defaultroute: 1 ppp_redial: persist peerdns: 0 dns: 8.8.8.8 (or you can use whatever) keepalive: 1 pppd_options: noauth We just switched the modem list over to the wiki and I'm going through my 3 or 4 known good modems to test and will update the page at http://wiki.wifipineapple.com/index.php/Compatible_Modems A lot of the settings are common among the modems however there are usually ISP specific settings like APN and user/pass that will change.

You're almost half way there. It's an interesting issue. Also ironic re: Barry's sig. Couple that list with occupineapple and you have a dirty hack. There's a lot more to it and I don't want to give it all away as the cat and mouse game progresses - but you're on to the fact that karma can be augmented. Stay tuned.

Quote from this thread: https://forums.hak5.org/index.php?/topic/31762-solid-green-and-amber-lights/page-2#entry240368

The first sample of the first expansion board came back with some faults. Show stopper stuff that can't ship. We're being rather meticulous about this one. Unfortunately we have multiple projects tieing up our hardware partner (who basically does design work for the love and fun of it for us) and as such the release date has slipped and gotten back into the que. I know we'll have it by defcon - and if all goes well most likely well before. I'll let you know when we get our second sample unit in for testing.

What he said. We took special care to specifically develop a voltage regulator that'll accept a wide range from 5-12v -- though if you lower the voltage you'll need to make up it with higher current (amperage). Edit: I don't have experience with switched vs linear regulators so perhaps you can write back with your experience. I can't see why it wouldn't work -- though your efficiency may vary.

I'm saddened by the quality issues with these SD cards. Our process is to burn the factory image and verify the data integrity before shipping. I can assure you the files read before they leave the shop. Furthermore, while we're technically within industry failure rate standards, a statement like that doesn't bring me any warm fuzzies -- and you deserve better when unboxing this magnificent machine. My apologies to all. If you're having SD card issues, please shoot us an email at shop@hak5.org with your order # and we'll get you sorted ASAP, no questions asked. We're also working to change the factory flashing process. The next major stablesaurus build is nearly done and we're looking to flash this at the factory - no more first boot mess... Thanks again for your support and please if there's anything we can do to make this a better experience do let us know. Cheers, Darren

A few months ago I was doing quite a bit of research of stability and distance tuning for point to point wifi links. See Hak5 episodes 1515, 1516, 1517.' Like many of you I keep a scratch pad of useful nuggets while researching anything so I figured while it took me considerable time to find these gems I'll simply brain dump them here. If you have some of your own in regards to stability and distance, please share :) https://forum.openwrt.org/viewtopic.php?id=43188 Found an interesting setting in /var/run/hostapd-phy0.conf - disassoc_low_ack, that seems to impact the low ACK behaviour http://hostap.epitest.fi/gitweb/gitweb. … 50d22c2887 changed to: ..... ..... interface=wlan0 ctrl_interface=/var/run/hostapd-phy0 disassoc_low_ack=0 preamble=1 ..... ..... Now does not give me the excessive/missing ACK - however now can trigger this error pretty easilly: http://www.dd-wrt.com/phpBB2/viewtopic.php?t=171400&postdays=0&postorder=asc&start=15&sid=314d027d1a944d6df6c2cf843d88fbea Sensitivity Range (ACK Timing) Available Settings: 0 - 999999 Recommended Setting: 0 - 2000 for both 2.4 & 5 GHz, greater than 2000 only when needed for long distance links ACK timing is also a throughput controller, too high and your devices will literally be "waiting" too long and time will be passing with them at idle. Too low and active transmissions could be cut off causing retransmissions which create overhead, that lowers throughput. The AP sends a packet and all clients must wait for XXX time, where XXX is the ACK timing, the client then receives that packet and responds to the AP with an ACK(nowledgement), AP sees the AP then finally everyone is free to transmit. Most users want this between 0 - 2000 (2.4/5 GHz), the distance used is meters and needs to be doubled the distance of the furthest client from the AP (plus some headroom). Doubled because the signal travels to the client and back, double the distance. In earlier builds with the older madwifi driver reducing ACK from default 2000 to 1500 caused a throughput increase of 0.6 Mbps - 1 Mbps, though with modern builds (r18000+) using the new ath9k driver, along with the internal changes to ACK timing, reducing to 1500 does about nothing for throughput, one would have to drop below 900m at least, as well with the current ath9k builds an ACK timing of 0 DOES disable it completely like on Broadcom, this is generally the new best setting. But if you do not disable ACK timing remember an ACK timing too low can cause issues described above. Long distance links, such as 2 KM+ will need to increase this setting accordingly. 4000m for 2km, 6000m for 3km, and so on. So putting it to 0 would disable it or would it change it to automatic, hmmm https://supportforums.cisco.com/docs/DOC-4349 WPA stands for Wi-Fi Protected Access. There are two versions of WPA: WPA and WPA2. WPA is a standards-based security solution from the Wi-Fi Alliance that addresses the vulnerabilities in native WLANs and provides enhanced protection from targeted attacks. WPA addresses all known Wired Equivalent Privacy (WEP) vulnerabilities in the original IEEE 802.11 security implementation and brings an immediate security solution to WLANs in both enterprise and Small Office/Home Office (SOHO) environments. WPA uses Temporal Key Integrity Protocol (TKIP) for encryption. WPA is fully supported by the Cisco Wireless Security Suite and the Cisco Structured Wireless-Aware Network(SWAN). WPA2 is the next generation of Wi-Fi security. It is the Wi-Fi Alliance's interoperable implementation of the ratified IEEE 802.11i standard. It implements the National Institute of Standards and Technology (NIST) recommended Advanced Encryption Standard (AES) encryption algorithm using Counter Mode with Cipher Block Chaining Message Authentication Code Protocol (CCMP). WPA2 facilitates government FIPS 140-2 compliance, and it is fully supported by the Cisco Wireless Security Suite and by Cisco SWAN. WPA and WPA2 mixed mode operation permits the coexistence of WPA and WPA2 clients on a common SSID. WPA and WPA2 mixed mode is a Wi-Fi certified feature. During WPA and WPA2 mixed mode, the Access Point (AP) advertises the encryption ciphers (TKIP, CCMP, other) that are available for use. The client selects the encryption cipher it would like to use and the selected encryption cipher is used for encryption between the client and AP once it is selected by the client. http://hostap.epitest.fi/gitweb/gitweb.cgi?p=hostap.git;a=patch;h=0d7e5a3a29efd4bc138e74b19657e750d22c2887 The nl80211 driver can report low ACK condition (in fact it reports complete loss right now only). Use that, along with a config option, to disconnect stations when the data connection is not working properly, e.g., due to the STA having went outside the range of the AP. This is disabled by default and can be enabled with disassoc_low_ack=1 in hostapd or wpa_supplicant configuration file. http://wireless.kernel.org/en/users/Documentation/hostapd 802.11n Setting Summary 802.11n builds on the settings above, and adds additional functionality. If your hardware doesn't support 802.11n, or you don't plan on using it, you can ignore these. ieee80211n: Set to 1 to enable 802.11n support, 0 to disable it ht_capab: A list of the 802.11n features supported by your device The explanation of these settings in the sample config file are quite helpful, so I'll suggest reading those. You can use the command 'iw list' to find a short list of the capabilities of your device. http://hostap.epitest.fi/gitweb/gitweb.cgi?p=hostap.git;a=blob_plain;f=hostapd/hostapd.conf # Enable IEEE 802.11d. This advertises the country_code and the set of allowed # channels and transmit power levels based on the regulatory limits. The # country_code setting must be configured with the correct country for # IEEE 802.11d functions. # (default: 0 = disabled) #ieee80211d=1 https://bbs.archlinux.org/viewtopic.php?pid=1200765 adaptive noise immunity https://dev.openwrt.org/ticket/12372 echo 1 >/sys/kernel/debug/ieee80211/phy0/ath9k/disable_ani http://www.gargoyle-router.com/phpbb/viewtopic.php?f=14&t=2058 Sensitivity Range Adjusts the ACK timing in Atheros typical way based on the maximum distance in meters: 0 disables ACK timing completely 1 - 999999 adjusts ACK timing The default is 2000 meters. When a packet is sent out from the router, it waits for an "ACKnowledgement" frame from the other end. The router will wait for a response until a certain amount of time has elapsed, called the "ACK timeout" (or "window"). Conventional wisdom holds that should be set to the maximum distance in meters x 2 (doubled to account for round-trip). For example, if you roam with your laptop up to 50 meters from your AP, the setting would be 100. Under nominal conditions (obstructions, power limitations, in-band interference, etc), the usable range of 802.11b/g is perhaps less than 100 meters, so it might seem that this setting should never exceed 200. However, if using a directional antenna that boosts range, timing needs would increase. Maximum theoretical ACK timeouts are approximately 744µs (11 km) for 802.11b, and 372µs (55 km) for 802.11g. There have been reports of experimental, assisted WiFi connections in excess of 40 kilometers plus. Another use for ACK might be for restricting the distance at which people can connect. This could be useful for WDS access points or for minimizing the zone of connectivity. Keep in mind, the higher the ACK timing, the lower the throughput will be. If set too high, packets could be lost as the router waits for the ACK window to timeout. Conversely, if ACK is set too low, the window will expire too soon and returning packets could be dropped, also lowering throughput. Wifi tuning for long distance using UCI(Openwrt/Gargoyle) Wireless Calculator http://www.tp-link.com/en/support/calculator/ https://dev.openwrt.org/ticket/10084 option 'wpa_group_rekey' '0' config wifi-device 'radio0' option type 'mac80211' option channel '9' option hwmode '11g' option macaddr '00:13:37:a5:0f:89' option htmode 'HT20' list ht_capab 'SHORT-GI-20' list ht_capab 'SHORT-GI-40' list ht_capab 'RX-STBC1' list ht_capab 'DSSS_CCK-40' option short_preamble '0' option beacon_int '250'

The Micro SD card is tested by our duplicator and further verified by an Ubuntu box. The QC process within the factory is quite lengthy involving several boots and imaging the base image. It won't get boxed if the image fails and it won't image if the hardware doesn't report A-OK. It's hard to say what the postal service does to these cards. I'm starting to wonder if we should be including a Micro SD card reader. I may have overestimated the ubiquity of such adapters. Have you tried mounting the included 2 GB Micro SD card? Do you see the two files? Let us know when the flash has completed and you've accessed the web interface.

Some make the distinction between a softbrick and a hardbrick. I think the term has been so misused over the years that it typically refers to "can't get in through traditional means" Between the simple serial access and bootloader recovery dip switch, nothing short of a blown cap or fuse is going to take the ol' pineapple down for long.

No I was meaning you can use that cable to power the MK5 off a USB bank or laptop. So that would be Male A USB into the battery pack or computer and Male DC barrel into the MK5s power port.