Oli

A board to expand the capabilities of the WiFi Pineapple. It was announced during DEFCON and should be available "soon". Essentially just an Arduino that can be programmed via the Pineapple and allows you to add additional hardware.

I'm sure that they will be in stock again - I'm just saying that as the add-board is essentially 90% of the way to being a ducky, it would have been nice to have that option and move on from the outdated current Ducky hardware. "add-on board with a small form factor" + "slightly better Atmel chip (ATMEGA32U4)" + "USB connector" = an awesome rubber ducky enhancement

Not in any quick, easy and reliable manner AFAIK. Some devices (not all) can be disabled via WinAPI but probably more hassle that required. What would maybe better is to use auto correcting "scripts", however these are not supported on the Ducky. Edited to add: hopefully they are out of stock as they are being replaced with a pineapple add-odd board that supports Rubber Ducky functionality rather than the thing on the slide at DEFCON!

I did a fair bit of playing around a few months back and posted some details about the pins, the voltages, etc. I would think that software PWM should work - haven't tried though. Probably easier to just offload that to an Arduino since I'm sure there will be issues getting everything to work nicely otherwise (especially if the SOC is busy doing other stuff). The (yet to be released) add-on board looks like it is pretty bare-bones but does have some PWM pins which would be controlled via an Arduino sketch rather than a kmod. Whether the pricing of the board is attractive and the HDK any good (or even documented) is still to be seen. I'm pretty jaded as I've been "waiting it out" since last October, so pretty fed up of waiting now... I really don't know what the motive behind excessive delays and reluctance to properly document the expansion bus is. A leaf needs to be taken from the Mike Ossmann book of tool development.

Perhaps, to support Hak5 or if you need a (way too) basic scripting language. I accidentally broke my Ducky and there is no way that I'd replace it. Buy a Teensy would be my honest advice (presuming that you have at least a bit of programming experience). Or, even a Leonardo would do fine if you don't need something as 'stealthy' and just want to play with the HID attack vector concept.

Use a teensy then this is trivially easy. No easy way with a ducky - you could hack it if you were desperate.

Eagle files should be released imminently according to another thread. I'd hope it would be around $20 based on the slide from the DEFCON presentation, to about $25 at the top end (allowing for a 2.5x multiplier)? There doesn't seem to be much at all to it: some logic level conversion and a (probably) Atmel micro-processor in a TQFP 32 package. I wish I got to see the design earlier on so that I could have provided some feedback! I can't help but feel that some easy wins have been missed (if the slide does indeed show the RTM product). Biggest issue: looks like you need a soldering iron from the get-go as the board doesn't have any stock I/O or header for the pins. That is a hard sell to the masses. As for the software side of the HDK, I'm not massively confident yet... With no default I/O for the HDK to take advantage I'm interested as to what the HDK will actually do. Just load sketches? What API will allow the Pineapple and Arduino to communicate? I guess things will become clearer as more details emerge.

Cool, looking forward to seeing them. Thanks, but I'm probably going to use some connectors I already have or maybe just rehouse my pineapple.

Thanks! Unfortunately I couldn't make it to DEFCON this year. If it is open hardware then you can always send me the schematics / KiCad files now if you want and I'll check them out - I don't require any documentation / source above and beyond this. Or even can you / somebody can post some high res images of the board and I can take a closer look at the implementation - I'm interested as to how it compares with my unofficial board, how the logic level conversion is performed and how the communication occurs (perhaps bitbang SPI since the serial pins aren't used as with an Arduino Yun?). I have a ton of constructive feedback regarding the HDK and add-on board - it would have been nice to provide feedback earlier on rather than when it is too late...

1 is all you need (to support Hak5). A teensy with DIP switches soldered on - and any other I/O options you require is my preferred way. DuckyScript is more a proof of concept and not particularly suited to non-trivial use (in my opinion). For example: no way to wait for drivers, no two way communication protocol between computer and keyboard (e.g. via keyboard LEDs), no robust multiple payload support, cannot run arbitrary Arduino sketches, and the list goes on. A trick was missed with the HDK add-on board - it could have so easily been a Ducky 2.0 that could have been programmed and/or controlled via the pineapple...

Nice to see that the source and firmware have been updated! https://github.com/WiFiPineapple/MK5_Interface http://wiki.wifipineapple.com/uploads/ Also, where can I find the HDK documentation / add-on board information? This new add-on is supposed to be open hardware right? I was led to believe that we would have something by DEFCON other than a Powerpoint slide? Thanks!

Like I said above, I think the solution may be that around 18 is the maximum. Looking around, it appears 18-21 is the maximum output power for the AR9331.

Slightly confusing issue. Hope this is not another hardware bug... there are no more spare USB ports after using a USB wireless card to circumvent the client mode throughput issues! Anyway, looking at p311 of the AR9331 spec (if I'm reading it correctly) then around 18dbm is the typical power output for the transmitter - I'd guess it physically can't go much higher than this.. hopefully I'm wrong.

I'm not trying to offend, but stating a matter of professional opinion. The direction and concept are good but the execution is a little "sloppy". I'm a professional software developer so I recognize uncommented code without error checking and a good structure when I see it. It might just be a PHP thing (I'm not a PHP coder) but the software engineer side of me says there is no way that you should have all that inline code in those files. The entire interface is pretty much just "screen scraping" a linux command line - fair enough I suppose, but use a proxy or facade rather than 'exec' commands in a PHP file.

It's pretty easy - I only started tinkering a few months ago. Just get an Arduino starter kit and have a play!

Pretty much my feeling too - but I'll probably carry on with my expansion stuff as it is a good learning experience and I think that the information should be available to the community. Here is my list of thing that I would like to see: Source in GitHub (it is now) AND actually used (not another USB Rubber Duck code drop and abandon). Firmware on GitHub AND actually used and updated so we can see what is changing. Documentation of how OpenWRT has been modified for the MKV. Documentation of the expansion bus. Documentation of the integration of the web interface/ OpenWRT / MKV hardware - even if this is just links to the relevant OpenWRT help:How are the LEDs configured How are the DIPs configured How is the web interface configured to start. How is the DNS stuff setup and why was the current way of doing things chosen. etc etc Documented build process to build EVERYTHING using the latest source from GitHub - firmware and web interface. Configuration to allow better privacy - I don't want my pineapple connecting to HAK5 servers to check for internet connectivity. Also I don't want to tell HAK5 every single package I install (the cloud.wifipineapple.com redirect does this because it is set as the default repository). GPL license for source code. The code is not what makes the WiFi Pineapple - the unique hardware, show and community do. Look at the code: it is not that fantastic or robust or cutting edge - a motivated individual could rewrite the whole thing in no time and make the official stuff look like rubbish! The hacker community needs open source / free software (ubertooth, hackrf, metasploit, kali, etc). Take Mike Ossmann for instance - he has an great product and it is open source. Is hackrf going to be any less of a success because he has his code licensed under GPL? No - he has a great product. Same goes for the Pineapple. Yes, I know HAK5 are a small team (as they keep on saying) - but if you sell this kind of product to the hacker / maker community then these are the things you need to do. A good percentage of the community aren't script kiddies or idiots and want a product that allows them to work without unnecessary friction and forced restrictions. For me, DefCon is the either going to make or break it as far as my involvement is concerned. If the new Karma, HDK and expansion stuff isn't up to par then I'm just going to abandon my Pineapple and find a suitable alternative.

Probably here - although I will need to find somewhere to host the images. I might see about a github wiki or something instead - that way I can post any HDK code / GPL Pineapple code that I work on in the same place. Last week I got the voltage regulator stuff working fine - can't decide whether to do another build of the board this weekend or progress the software, keeping things on my breadboard. I've added a real time clock now so that my Pineapple always has the correct time, irrespective of whether or not there is an internet connection.

Not easy (or foolproof) by any means, but I guess you could do statistical analysis based on SSID names, timing, signal strength, etc so even if MAC address is random per probe you can work out to a reasonable probability over time which devices are around. I guess a single device is going to constantly probe for same SSIDs repeatedly - so over time if you can infer certain things.

OK, but that is source (I checked a few days ago and it said there were "no public repositories" so that is newly public withing the last day or so...) Still no documentation on the API functions (the source was all available anyway by looking at the pineapple filesystem) or code comments full stop. Glad this is finally out there to submit patches to and under a slightly better license (seems fair enough for the majority of users / community)!

If there is no real support for alternative languages in the Ducky, just use a teensy. Spanish is supported out of the box.

The end of last week or some arbitrary week in the future? :) For the avoidance of doubt, what exactly is to be "out". Just the documentation of the infusion related methods or "everything"? Full documentation of what is happening in the UI as far as interaction with OpenWRT / utilities is pretty important for most people. For example, how if the UI setting up the wireless configuration etc. Yes, this can all be easily reverse engineered by looking at the source (and I've done this) but some official guide would be useful for the wider community.

As far as I can tell, there is no compelling reason that the MKIV and MKV couldn't share a common code base. It would be fairly trivial to implement in the firmware and web interface - especially if a "supported" set of add-on hardware was specified for the MKIV. Say, MKIV + powered USB hub + Flash Drive + Alfa awus036h + limitation that an expansion bus was only available on MKV OId MKIV users would be happy, the price point of the MKV vs buying everything separately (and the nice form factor of the MKV) still makes for a strong selling point.

Best bet is to attach Pineapple to an Arduino device via the expansion bus, serial port or as a USB serial device. Pros and cons for each method of connection. Then you can just worry about interfacing the Arduino to the bluetooth device. Expansion bus has a 3.3v line, USB runs at 5V, not 100% sure how the serial works to be honest (there is a 3.3v pin, but I never connect to it - not sure if that is 3.3v in/out... will need to do some digging), Serial is running a 115200, I believe. Personally, I'd be tempted to just use a USB bluetooth dongle. If you must go the breakout board / Arduino route look into the Adafruit stuff - much better quality and should have some detailed tutorials.

Looks pretty good to me. Could do with a joystick / jogswitch and buttons - going to be hard to configure anything otherwise. Take a look at the Adafruit RGB LCD shield or the Pololu five position switch to see the kind of thing I mean. Could fairly easily migrate to use the expansion bus too. You might want to try a 3.3v microcontroller as the expansion bus can provide 3.3v. You are likely to run into power related issues with the thing running off USB and using an external WIFI device... Offload as much as possible to the Arduino - the AR9331 is slow and you want it so have to do as little as possible.

Sounds interesting - will be prohibitively expensive though.