Oli

Looks pretty useful for migrating scripts to a teensy! Although, in my opinion, it would be better to drop duckyscript altogether and move to a more elegant scripting language that promotes readability and usability (and takes advantage of some of the cool things a teensy can do: waiting for drivers, multiple payloads, etc). The "look and feel" of duckyscript is pretty poor and the readability of Arduino/C also is not fantastic when it comes to this kind of thing... The output works but is not very clear. What is the best solution? I have a few ideas and something in the works that I might finish off and release at some point in the future...

...just be careful that it can provide enough current. If you don't have any extra power to the hub you might not be able to source enough current when you start adding displays etc to the Arduino and need to run a separate USB antenna at the same time...

Thanks! Sounds good - I think that is a pretty viable method (shame that the hardware bug will tie up the one USB port on the MKV though). Serial is maybe the best way to communicate with the Arduino rather than the expansion bus anyway (this is how the AR9331 and Arduino communicate in the Dragino / Yun) - with the caveat that you can't use if for debugging the Pineapple if it is use for expansion. You could also use the serial pins on the MK5 (take care with logic levels though!) - Sailor has some examples if you haven't seen them already: https://forums.hak5.org/index.php?/topic/31961-arduino-pineapple-led-matrix/ https://forums.hak5.org/index.php?/topic/31962-arduino-pineapple-control-antenna/ Yeah, I want to use Python for the library too - we will have to compare notes / try and collaborate on something. I've got the rest of the parts that I need now, so I'm going to work on my project this weekend. Looking forward to seeing what you come up with!

Don't get me started, I'm all ranted out :)

Slightly off topic, this is one of the annoyances that should really be addressed in the firmware. I have a homemade ducky and it is nice to be able to just do a waitForDrivers() call.

Sorry, that might not have come across right (not trying to troll!). I have a high regard for them too, The point I'm trying to make is that (it seems to me) that UI is always a minimal "bolt on" that is not very refined and not well documented and only suitable for trivial use. We then wait a few months for whistlemaster or foxtrot to write a separate infusion to add a little bit more functionality (but only semi integrated due to infusion limitations) and everybody goes wild at unlocking a small fraction of a features potential. I bought the WiFi Pineapple / case / battery at the launch party to hack the hardware, explore the security concepts and write some cool software and all I have had is friction, bugs, lack of documentation, etc. It seems silly to me that the people I regard highly and that got me interested in computer security won't let me hack my own device and want me to wait the best part of a year before they document something as central to the device as the expansion bus! I have an interest in hardware and electronics and want a proper documented, robust platform to work with and be able to unlock the potential of the unique MKV hardware. In my humble opinion, the built in DIP switches are a potentially useful feature but lacking proper documentation and extensibility - if they are not properly documented and customizable now, why on earth should I think that the HAK5 hardware UI (an order of magnitude more complex) will be any better documented/implemented? (How do the switches work, exactly when in the boot up process are they run, how do I change them to be toggles for functionality - so for example not boot mode but runtime toggles for, say, Karma - how are they read at runtime from an arbitrary script, how do I remove the system functionality and use them all myself, where is the code that actually reads the sqlite file, how do they interact with OpenWRT etc). I'll shut up though since I seem to be in the minority that is dissatisfied. I'll just continue my hardware project quietly and wait and see what happens by DEFCON. I'm hoping I will be proven wrong and I'll be super satisfied/impressed. At the very least I hope that I have raised expectation as to what the expansion bus should be capable of, exercised my rights under GPL to get access to firmware, raised the questions about what license a HDK should be released under and shown people like me who are getting frustrated with respect to the hardware that the information is out there to make it work now without having to switch to another platform.

As a side note: it is possible to add a RTC (real time clock) to the pineapple via the expansion bus (software I2C using 2 GPIO pins). This way the Pineapple can have the correct time, irrespective of whether it is able to sync with time servers.

That is the plan :) A well thought out command line means of interacting with the GPIO pins along with a slick standalone webpage for configuration. Depending on how lazy I am, I might start replacing the existing web interface by a free (as in freedom) alternative, page by page. No chance I'm working on an "infusion" though, other people can make a wrapper infusion around whatever HDK interface is developed though this project though. My HDK/web UI will work with whatever HAK5 release as an expansion board too. Yes, probably a poorly thought out bare bones UI (that doesn't address most of the problems/use cases) and that is proprietary so can't easily be improved upon. I believe that fully harnessing the community input will result in a much better product that can be adapted as power users see fit - this won't impact that HAK5 business model though as the MKV is pretty unique hardware and 99% of people would prefer to buy a nice small expansion board from the Hakshop rather than spend $100+ on components, get electronics equipment and spend hours soldering. Still waiting for decent integrated UI for the built-in DIP switches seven months after launch, existing hardware has a bug that will tie up the one USB port in the MK5... just saying :) Note to self:

Thanks! I'll write up the details in the next few days and I'd appreciate any feedback / improvements that you can give. Thanks! Yes, I'll post details as the project progresses. It is all open source so feel free to ask if you have any ideas / questions / etc. Bluetooth, USB and WiFi are probably best handled via the MKV onboard USB port, though the arduino can definitely do so stuff around ethernet / bluetooth. Offloading tasks to another computer / device is something I am interested in. The MKV processor is pretty slow and bit-banging I2C isn't ideal... I'm using the teensy to handle things like the OLED screen logic. You could pass off whatever tasks you want (pretty much) to a slave device, where appropriate. Thanks! I've already learnt a lot with the project. The current revision board has a few "hacky" hardware design features I'd like to fix and I also have some other ideas I want to implement. My current plan is to get a rev. 2 hardware design built that I'm vaguely happy with - this will be the baseline documented version. I have ordered the parts that I need and will try and work on the design on evenings this week and then do the build next weekend. The changes that I want for rev 2 are: Add a 2.5V voltage regulator Add 2 WAY DIP switch Tidy up wiring I have a few compelling use-cases for the hardware that I would like to implement.

Easiest / best performing route is to just to use a separate flash drive. Remember (using stock firmware) the ducky just shows as a keyboard - keyboards do not have files that are accessible! There is alternate firmware, that might do what you want: https://forums.hak5.org/index.php?/topic/28162-firmware-introducing-twin-duck/

Attached is a picture of my prototype expansion board using the "un-documented" MKV expansion bus. I tried to make the board extensible so I can interface the pineapple easily with whatever I want (Raspberry Pi, BeagleBone Black, etc). My current configuration has the following features: LEDs (x2) Buttons (x3) Arduino based Teensy board (powered directly from the MKV) OLED screen. The core part of the board is pretty simple to make and based on open source hardware so people can build and improve upon it. The cost to build is approximately $10 for the core board plus whatever additional devices you want to add to it (my configuration probably costs about $50). You can add pretty much whatever you want to the Teensy pins - which run at a standard 3.3v. I have everything in my prototype working as a proof of concept via the command line, so the next step is to start fleshing out a feature rich "HDK" and make the board genuinely useful. I'm interested to hear: What features / use-cases people have for MKV expansion boards? What killer features is my prototype missing? Would any other makers / electrical engineers like to join forces, optimize the design and create a (probably) python based HDK? I'm a software engineer and just started dabbling in electronics, so it would be nice to get feedback on the design. Oh, by the way, this prototype can emulate a keyboard and blow the rubber ducky out of the water too :)

I have a minimal example working! I have LEDs and buttons working. I also have an I2C bus up and running and talking to a Teensy w/ OLED display :)

At the end of the day, I don't really care what license the thing is under (well, so long as the contradictory GPL stuff is removed!). I want to support HAK5 and run the on the unique MKV hardware and don't really care about the non-commercial clause (which I suppose is pretty justified). I just want a friction free experience: 1) Source control to see what is changing and where between releases. 2) Fully documented route to build firmware (which is already open sourced) - including all steps up to and including the final downloadable containing the web interface. 3) Documented expansion bus and ability to shape the future HDK (which could be as ugly as ducky script for all I know, if no external feedback is solicited). 4) Ability to submit code to HAK5 for approval to be part of the main code line - if of course the change is appropriate. Not just limited functionality infusions. 5) Ability to create and redistibute forks of the code with any required changes that are allowed to run on at least the MKV. This can only help the project and keep the community happy right?

Care needs to be taken though. The core of the WiFi Pineapple is all open source (openwrt, karma, etc). The web interface is a tiny proprietary piece of a big ecosystem. Eventually somebody will just create a 10x better web interface from scratch - with less restrictions - to the detriment of Hak5. What I'd like to see is more people making meaningful contributions to the official code line and faster progress on the project.

Dual licensing could be a possibilty: Open source GPLv3 project - anybody can make changes and redistribute the source code. The GPL means that redistributions must follow the same license and have the same freedoms. The Cooper Supercharged Pineapple™ that fixes all the annoyances in the web interface would have to be open sourced as you got the code under the GPL. Your improvements could then be rolled back into the WiFi Pineapple main line. Should Microsoft want to release the Micro$oft User-Subjugating Pineapple™ and not have it as open source, then they would have to buy a license exception from Hak5.

Well why mention GPL at all then? How is this anyway related to the essential freedoms that GPL aims to give its users: 0. Freedom to run the program as you wish. 1. Freedom to study the source code of the program and then change it so the program does what you wish. 2. Freedom to help your neighbour. That’s the freedom to redistribute the exact copies of the software when you wish. 3. Freedom to contribute to your community. That’s the freedom to distribute copies or modified versions when you wish. Freedoms 0, 1, 2 and 3 are violated by the Pineapple license. Pentesters cannot use the Pineapple for a professional pentest as commercial use is explicitly forbidden (freedom 0 violated). The Pineapple license implies modified binaries can be distributed wihout source code (freedom 1 violated). How can I redistribute exact copies as that is not solely my personal benefit - but the benefit of the friend (freedom 2 violated). If I make improvements to the product I am not allowed to share those improvements with the community as this is not "personal benefit" (freedom 3 violated).

You are still in the Netherlands right? http://floris.cc/shop/en/raspberry-pi/838-usb-to-ttl-serial-cable-debug-console-cable-for-raspberry-pi.html

In that case a non-commercial custom license should be used. Open source by definition allows commercial redistribution and open source does not just mean that you have access to the code. What we have is a non-free software license that allows access to source code - using the GPL is a slap in the face to what free software stands for. It is a moot point anyway - by saying non-commercial redistribution, all that means is that if you want to release Supercharged Pineapple™ you just have the web interface separately non-commercially distributed (i.e. gratis / no charge from a forked GitHub version). So, like I said, the non-commercial addendum does not make any sense to me. The USP is really the hardware and the Hak5 brand.

The USB Rubber Duck hardware and scripting language are starting to look a little long in the tooth... Any plans for official upgraded hardware / scripting language in the near future? With the move to an Arduino based expansion board for the MKV it seems like the ducky could be replaced by the new add-on fairly easily? Arduino has some pretty cool keyboard/joystick/mouse emulation capabilites. It there are not plans for updated hardware has anybody looked at making a more useful scripting language? One that promotes code reuse and readability? I really cannot stand the look and feel of Ducky Script!

Here are some links for reading: Open source definition: http://opensource.org/docs/osd Free software philosophy: https://www.gnu.org/philosophy/free-sw.html

This doesn't really make any sense... You can't have "non-commercial" open source licence. I notice that you have the GPL licence and then a non-commercial clause tacked on the end... not at all the spirit of free software (free as in freedom). May I ask what you are trying to achieve by not allowing commercial redistribution that the GPL wouldn't cover?

Short answer: not really Long answer: you could try and use social engineering to get the user to enter some information/passwords. Auto-connect is only going to work for open networks. If they manually try to connect to a spoofed open network named after a secured network you might be able to show them a captive portal asking for a password to for that network. Not going to fool many people though.

Screwdriver and open the case?

Hopefully I'll get some spare time to work through the build process too. I also want to diff against the openwrt code and see what has actually been changed for the MKV from stock openwrt. Also, having a random snapshot in time doesn't really help much as this could get out of sync really quick. For instance, come 1.4.2, what had changed? Firmware? Web interface? Both? How frequent are core firmware changes vs web interface changes? We don't have much transparency still. If, like suggested above, LEDs aren't setup how do you at them up? How do you go from the firmware to a release a downloaded? Still a fair few unanswered questions to resolve...

Yep - testing on the pineapple is what i'm interested in. This is where the AR9331 speed and SD implementation come into play and where the bottleneck likely is.