Oli

Just a dongle so that you can plug the SD card into a PC to load payoloads etc.

Yes, it should work in startup / BIOS. Not really suitable for that kind of thing as it is just a "dumb" keyboard that fires off key presses at predefined intervals and gets zero feedback from the system. You will have trouble getting appropriate delays for stages of the install process. What I would do is use a Teensy/Arduino with tactile switches (buttons) and then have a semi-automatic process that proceeds to the subsequent stage when the button is pressed. The ducky cannot do this as it has no accessible GPIO pins.

I haven't used that firmware (no duck anymore) and can't be bothered to RTFM, but I guess you will have a payload that runs automatically each time (and can be triggered via the button), along with payloads that can be configured to run via the the keyboard NUM/CAP/SCROLL lock keys.

You might need to know a few things about circuits before trying to make a non-trivial device. Get an Arduino Uno and the IR sensors / receivers that Adafruit sell and do some tutorials - things will probably become more clear then. Just use the ATMEGA328 on Uno for research and development and then move to the ATTINY when you have things working.

So what chip is in the MKV then? Realtek list the RTL8187L as having 802.11a support? Could have maybe done with something in the FAQs or an announcement or something rather than trying to hide away another hardware 'bug'?

Dunno. The original MKV had the RTL8187L which does support a/b/g http://penturalabs.files.wordpress.com/2013/10/mkv_board_top.jpeg Here is the link to the Realtek site: http://www.realtek.com.tw/products/productsView.aspx?Langid=1&PFid=1&Level=6&Conn=5&ProdID=36 Realtek also do RTL8187SE that is b/g only but is different enough to not just be a simple swap out, so I doubt they would have changed the chip to save a few cents. Might be a driver issue or something? If you can be bothered, open up the case on your MKV and check for the presence (or otherwise) of the RTL8187L.

Hopefully soon and hopefully it won't be half-baked. It is pretty much a year since this was first touted. I'm hoping the additional delay is to take my feedback on board and make the necessarily improvements so that the product appeals to the likes of me and people without an interest in electronics. Anyways, as far as I'm concerned it is immaterial. I have my SMD lab all sorted now so I'll just build my own add-on if I ever come back to the Pineapple rather than buy one.

All good points and don't get me started on a rant :) I view duckyscript as a bare bones proof of concept that never was officially supported - one initial code drop and a few community enhancements. If you send too much keystroke data to a computer it cannot handle it all - so you need delays. Computers run at different speeds - so say something like launching an application might take 3 seconds on one machine and 10 on another. As there is no way to get feedback as to "is the application launched yet" you need to add longish delays that will work in most cases. I can't be bothered to enumerate all the annoyance and "hacky" things about duckyscript, so to sum things up in one word: Peensy Multiple payloads, feedback from the target machine, GPIO to add whatever inputs/outputs you need, a method to wait for drivers to install, a real programming language. I personally use Python templating (that promotes readability and code reuse) to generate generate the payloads rather than coding everything in C and then compiling.

That looks pretty similar to the battery I bought with my MKV at the launch party - I might see if I can did it out and compare specs. Should be fine - just make sure polarity of the jack is correct. Lower voltage would be better to avoid energy losses due to heat in the pineapple regulator, but shouldn't be a problem.

The SD bandwidth is pretty low and not as useful as it sounds. Just make sure you have read the instructions carefully for flashing alternate firmwares, try a different SD card and USB port (to rule out any problems with those), and failing that change to a more supported platform with regular releases, regular enhancements and bug fixes.

Also, the more you deviate from a single "stock" MKV the greater the irrelevance/inappropriateness of the pineapple. If you don't need a small, low cost, battery powered WiFi device with multiple in-built radios then a laptop with, for example, kali, decent external radios etc is orders of magnitude more useful and appropriate.

One of many enhancements that could and perhaps should be made and not easy to roll out because of the "infusions" approach by different authors rather than a single code base available from, e.g., Github. Speaking of which, still no updates to the interface code since the initial drop: https://github.com/WiFiPineapple/MK5_Interface

You mean a key logger? I suppose they are vaguely related (one is intercepting and logging keystrokes, one is issuing them) and you could - by no means trivially easily - do the same thing with a ducky alternative like a teensy by embedding it into a keyboard.

No extra gpio is easily available from the ducky as far as I remember. The reset button could be de-soldered and moved to the case - easy electronics wise, you just need the right tools/skill to mod the case.

Some PCB pics are in a previous thread - you can take a look and reverse engineer a vague schematic. I've built all my duck like devices using a Teensy 3 or 3.1 - I highly recommend them. Search for "offensive security peensy" to get started.

Power Supply / charger terms are often used interchangeably. There will be an on-board regulator (or more likely 2 for the different rails) on the Pineapple PCB so everything is fine so long as you use something that outputs a reliable voltage / current in the range supported by the relevant regulators. The bench power supply (which is totally overkill for powering a pineapple where a cheap wall wart is fine) can provide a really stable lab quality output. You can then use this to set an exact voltage and see just how much current is pulled. This can be used to characterize the Pineapples behavior and determine optimum voltages and see how, for example, adding an external wifi adapter changes the current / power requirements.

Take a look at this: http://wiki.wifipineapple.com/index.php/Build_guide Although you are likely to run into problems as things aren't documented as well as they could be.

Probably slightly more nuanced than that due to regulator dropout voltages etc. To ensure a full 5 volts on the USB ports (and make sure USB peripherals behave well consistently) you'd probably need an extra 1 to 1.5V (I'd need to work out what regulator is used and look at the data sheets to be sure). Also depending on the PSU used, the higher the voltage, the higher amount of energy will be lost due to heat as the voltage is stepped down. So, 7.5 volt @ 2 amps or 9 volt @ 1.7 amps are probably the best out of the options you suggested - high enough to be properly regulated to 5V yet not so high as to waste energy as heat. If I could be bothered (and I can't) I'd hook a MKV up to a bench power supply and see how how much current is pulled at different voltages - it would also be interesting to see the temperature of things on the PCB with a thermal imaging camera.

The whole tango thing is pretty half baked at the moment as far as I can tell... Perhaps check back when the pineapple plug gains some more traction. Essentially you have just two networked devices with the pineapple plug - nothing special or clever. Software needs to be written to make the most of this configuration for the pineapple - this takes time and hasn't been done yet.

Come on, the PineAP "suite" is pretty basic stuff (who on earth would have thought of storing stuff in a database and also brute forcing beacons! Oh wait, that is what I was already doing and predicted months ago!). It doesn't take an infosec genius to reverse engineer the operation of the app so any "security by obscurity" argument is just plain nonsense. What we have is an example of the injustice to the user community done by closed source software and yet another example of the lack of openness with respect to source of the WiFi Pineapple project. See my previous posts for further examples.

Teensy is the way forward for an OTS board. "USB type A" is referring to the connector type (i.e. USB A male connector is what you get on pen drives). The Leonardo has a Micro B female connector and a (compared to a flash drive) huge footprint.

Seems a bit pointless... Just lock your computer when away from it to mitigate 99% of problems.

Give it a try and see if it works. You will potentially need a powered hub for reliable operation. https://forums.hak5.org/index.php?/topic/32638-supported-high-throughput-client-mode-radios/ I don't know all the schematics / data sheets etc, but say best case the USB port can supply 500mA - you are getting close. I think the pineapple has an internal USB hub to connect some internal modules such as the SD card etc so I don't know of the top of my head whether this comes out of the 500mA too. Plus, running close to the rated maximum might provide stability / heat issues.

https://hakshop.myshopify.com/products/wifi-pineapple-plug Probably can do the same with just a cross over ethernet cable or something.

Not as easily as a ducky. Without the SD card reader attached, a peensy is very small / thin. This is OK if you are exfiltrating via a separate flash drive or the internet or something. Adding the SD card reader makes the thing thinker than a normal USB drive. Another problem is that a Peensy has a mini-b female USB attachment so you need a convertor... What I'm hoping one day (I might build one if ever I need something super stealthy) is a rubber ducky upgrade that is essentially a Teensy 2 with a USB type A connector. This would be awesome: USB drive form factor, Arduino code rather than ducky script and a ton of I/O for adding peripherals (e.g. buttons to launch different payloads, num/scroll/caps lock LEDs etc)