no42

Have you connected the RX and TX lines the right way around? Also, I find that GND has to be connected, otherwise it does not register any keystrokes on the pineapple (only the terminal (false positive)).

Are you running stock firmware? I assume your using an micro sdcard adapter to access the micro sdcard - can you upload a picture of the adapter? have you tried another micro sdcard? Does the ducky's default payload trigger? a red led means it cant find an inject.bin or mount the sdcard.... I've used Windows 7 x64 with no problems, so its a matter of understanding whats going on.

1st thought: if you dial a non-existent number, the phone-book history will record all the times and dates you attempted to call that number. in app store search: time keeper for many time keeping apps (some free , some paid), theres got to be something handy for you there.

try removing line 1 - REM ... and re-encode. I think that might cause the DoS.

Typical Setup. PC uses WiFi to broadband / hotspot (or even ethernet connection) Pineapple uses ethernet (or 2nd USB based ethernet) to PC Enable Internet Connection Sharing (ICS) on host PC Everything should then work

You can use debian or ubuntu on android, there are several free apps to create a debian/ubuntu-based chroot-environment. Though I think you'll be better off with vmware/virtualbox vm image on a laptop or desktop machine. For ~$30 you could invest in a raspberry pi, their small, cheap and great for learning linux and python.

should be as simple as: ssh root@172.16.42.1 password="pineapplesareyummy" (without quotes) assuming your ip address is 172.16.42.42 References for vi (vim): a quick vim quickstart guide: http://www.oregonwebradio.net/backup_fedora/tutorials/vim_li/quickstart.html vim command reference: http://tnerual.eriogerg.free.fr/vimqrc.html

Only with the combined power of the USB Rubber Ducky. Windows has since stopped auto run execution.

What commands were you using on Linux?

Tried the encoder v2.4 (it might help identify the problem)?

My advice is go through the exchange process. Link: http://forums.hak5.org/index.php?/topic/28824-frequently-asked-questions-faq/

The red light means the sdcard is not mounted. Either a faulty sdcard or a faulty sdcard adapter on the duck, if a new card does not work I advise using the return policy.

If you want to make your own look (based on Teensy), look for Version 1 threads; easily searchable in google: site:forums.hak5.org duck [version 1]

Have you read: http://www.backtrack-linux.org/forums/showthread.php?t=47385 ?

your going to have to get a usb keyboard, and a sniffer (google bus dog / usblyzer) to capture the traffic, Im not sure what the HID code will be?

What keys do you normally press to get ^ ? Can you try: ASCII_5E = KEY_RIGHT_BRACE, MODIFIERKEY_SHIFT

Everything is here: http://forums.hak5.org/index.php?/topic/28627-info-how-i-wrote-the-community-edition-firmware/

2048Bytes should be enough to call an executable. As it triggers on keypress and not time, you don't need the initial long delay. Its enough to use wmic/for loop to call an exe on the sdcard for windows, and enough to have a payload execute on the sdcard in either OSX/Ubuntu. Its ok for a PoC, but need to know more about the architecture and inner chip workings to possibly increase the memory space (if it is possible???).

That would be approximately 18 Bytes. Leaving you with 2028 Bytes to play with. Delays are coded in byte form, therefore two bytes hold a maximum of 255 msecs (or micro-secs i forget),

I currently only have 4096 Bytes to work with (TwinDuck), for two payloads 4096/2 = 2048 Bytes you actually only have 2046, just to prevent one payload overflowing into the other(I have hardest \0 (null byte)s) at positions 2047 & 2048! Memory space is tight!!!

Made the mistake of upgrading to Atmel Studio 6.1, which wanted to upgrade all the firmware-code and base libraries. Downside: it corrupted all my code :( Upside: I had a backup :) Downside --: It still seems to have messed up a few libraries, compiling the USB and Twin-Duck v2.1 with speed enhancements either refuse to compile, or when they do eventually compile are slower. Oddly the write speed is faster than read speed (137/100KB w/r compared to previous 160/200KB w/r (w/r=write/read))???? After a day wrestling with the clock - no improvement - which suggests its something todo with the base libraries / particular version of the framework (and i cant remember the previous one I was on? 3.1.xxxx?) Now to decide whether to continue with 6.0 Framework, or rewrite everything in 6.1. So if there are any people out there compiling from source/learning to program the Ducky I suggest you stick with the Atmel Studio version 6.0!!! ~~Snake

Produced due to demand: a merge of the multi-duck (former Naked Duck, now know as Detour Duck), and the Twin-Duck firmwares. Duck will initially mount as Mass Storage Device. Numlock - triggers payload 1 (inject.bin) Capslock - triggers payload 2 (inject2.bin) Due to memory restrictions, as both payloads are loaded into Ducky memory - you are limited to 2048-Bytes of instructions! Also only one payload can be triggered, so you have a choice payload A or payload B. NOT BOTH!!! Download: http://code.google.com/p/ducky-decode/downloads/detail?name=cm_duck.hex&can=2&q= ~~Snake

If the inject.bin was compressed, it would have to be expanded in memory, where the 4096Byte limit exists. How to get into firmware development - read : http://forums.hak5.org/index.php?/topic/28627-info-how-i-wrote-the-community-edition-firmware/ Also don't use Atmel Studio 6.1 - major changes it breaks the current code (as I found out yesterday), highlights the importance of backing up your code. Current firmware uses version 5 or 6 of Atmel Studio.

chances are that the reverse.exe is 16-bit; fine on 32bit systems not for 64bit applications. I'd use metasploit to generate a 64bit reverse shell, and use that instead.

You could brute-force windows, but then your limited to GPO (Group Policy Restrictions) on typical corporate/institute machines.