UnKn0wnBooof Posted September 5, 2014 Share Posted September 5, 2014 Ok! I've been looking at this post: https://forums.hak5.org/index.php?/topic/2361-usb-switchblade-development/ and I'm wondering if there is going to be another version of the ducky with a U3 partition/launchpad. This would make the ducky even more powerful than what it already is. Is there any thoughts about a new version of the Rubber Ducky? Quote Link to comment Share on other sites More sharing options...
Oli Posted September 5, 2014 Share Posted September 5, 2014 U3 is pretty much dead so essentially pointless. The add-on board for the MKV could easily be a Rubber Ducky 2.0 (if designed right). I have a prototype "Ducky 2.0/Add-on board" using off the shelf components, it wouldn't be too hard to properly design this fit a USB drive form factor. First things first: the terrible "Ducky Script" language needs revisiting! Quote Link to comment Share on other sites More sharing options...
UnKn0wnBooof Posted September 6, 2014 Author Share Posted September 6, 2014 (edited) U3 is pretty much dead so essentially pointless. The add-on board for the MKV could easily be a Rubber Ducky 2.0 (if designed right). I have a prototype "Ducky 2.0/Add-on board" using off the shelf components, it wouldn't be too hard to properly design this fit a USB drive form factor. First things first: the terrible "Ducky Script" language needs revisiting! Doesn't U3 still work though? If it does, it would save us from opening cmd and manually entering commands. How much do you think you've spent on making this "Ducky 2.0"? Do you plan on making it open-source?Would be great if I could make my own Ducky-like hardware. As for the ducky script, yes - I agree. I think ducky script would be better if it was written something like this: if ( Key.Pressed[CAPS_LOCK] == true ) { Key.Pressed[CAPS_LOCK] == false // Disable caps lock. String.Write(Hello, this is a string!) Key.Press[GUI + R] sleep 2 String.Write(cmd.exe) Key.Press[ENTER] Key.Hold[CTRL+ALT+C] // Can't remember what key combo stopped UAC from appearing. } Edited September 6, 2014 by Lavanoid Quote Link to comment Share on other sites More sharing options...
Oli Posted September 6, 2014 Share Posted September 6, 2014 I've spent a fair amount of time and effort and money - next step is to design some custom PCBs to shrink my prototype down. I'd release my stuff not as "open source", but "free software" (GPLv3) - yes, they are essentially the same thing, but freedom is what is important for "hacker" tools. I have a proof of concept that works fantastic for me (search previous threads for photo) and I'm not sure if I can be bothered finishing it to "release" quality. I'm quite busy and this is just a hobby. I've had nothing but friction so far with the official Hak5 products. I really want to support them but I'm pretty close now to just designing my own stuff that work just as I like them and tossing my MKV in a drawer. I'm pinning my hopes on the Pineapple HDK and add-on board (the design files for which were supposed to be released over 2 weeks ago... I'm still waiting...). If this stuff is not to my liking or if they don't accept improvements to supposedly "open" hardware then I'm just going to leave the community and work on my own stuff. Quite frankly a year waiting for basic expansion bus info is absolutely ridiculous and then after the wait the add-on board looks unimpressive (five minutes looking at it and I have a dozen quick win improvements). Also, the USB Rubber Ducky Github has not been updated for 3 years! Hardly a supported product. Yes, that pseudo code is more what is needed - something that promotes re-useability and non-trivial applications. I'm tired of seeing ridiculously simple "scripts" that are essentially open a command prompt or powershell and run a simple command or two! I have a Jinja3 / python framework that I'm successfully using to generate payloads that are an order of magnitude more elegant than ducky script. Quote Link to comment Share on other sites More sharing options...
UnKn0wnBooof Posted September 7, 2014 Author Share Posted September 7, 2014 Indeed, I agree. On the bright side, at least this "simple ducky script" lets us craft payload's easily and quickly within minutes (or perhaps even seconds). It would be great if the ducky script gave more flexibility however. So, does U3 still work or has Microsoft disabled autorun on these U3 interfaces? Quote Link to comment Share on other sites More sharing options...
factgasm Posted September 14, 2014 Share Posted September 14, 2014 (edited) How about using EEPROMs instead of relying on Micro SD Cards? I tried out some innocuous scripts at an internet cafe two days ago. Their machines had AV which scanned the Duck. It didn't stop the Duck sending keystrokes, but it did wipe the volume name off the Duck and thus prevent the payload succeeding. This wouldn't happen with an EEPROM. Edited September 15, 2014 by factgasm Quote Link to comment Share on other sites More sharing options...
MB60893 Posted September 15, 2014 Share Posted September 15, 2014 How about using EEPROMs instead of relying on Micro SD Cards? I tried out some innocuous scripts at an internet cafe two days ago. Their machines had AV which scanned the Duck. It didn't stop the Duck sending keystrokes, but it did wipe the volume name off the Duck and thus prevent the payload succeeding. This wouldn't happen with an EEPROM. Hmm. My only concern would be how customisable the device would be... Good idea though, I'll look into it! Quote Link to comment Share on other sites More sharing options...
Oli Posted September 15, 2014 Share Posted September 15, 2014 EEPROM is quite slow and has limited write cycles. It could easily be used for storing payloads and scripts, but ex-filtrating data from the target is a not really feasible via EEPROM (especially not if you don't mount it as a storage device and have to bit bang the data across). Quote Link to comment Share on other sites More sharing options...
factgasm Posted September 17, 2014 Share Posted September 17, 2014 EEPROM is quite slow and has limited write cycles. It could easily be used for storing payloads and scripts, but ex-filtrating data from the target is a not really feasible via EEPROM (especially not if you don't mount it as a storage device and have to bit bang the data across). How about this: Payloads get stored on an EEPROM within the Duck (so as to be undetectable to AV) but data exfiltrated data from the target machine gets stored on the Micro SD Card? Would that be a better idea? Quote Link to comment Share on other sites More sharing options...
Oli Posted September 17, 2014 Share Posted September 17, 2014 How about this: Payloads get stored on an EEPROM within the Duck (so as to be undetectable to AV) but data exfiltrated data from the target machine gets stored on the Micro SD Card? Would that be a better idea? Yep, and that is what my device does. Not really feasible using the ducky though without hacking the firmware, etc. If you make a peensy and have the script as the arduino sketch and the SD as a mass storage device this is what happens. Quote Link to comment Share on other sites More sharing options...
factgasm Posted September 17, 2014 Share Posted September 17, 2014 Hey Oli, Can the Peensy be disguised as an ordinary USB stick? Quote Link to comment Share on other sites More sharing options...
Oli Posted September 17, 2014 Share Posted September 17, 2014 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) Quote Link to comment Share on other sites More sharing options...
S3V3N Posted November 23, 2014 Share Posted November 23, 2014 A good payload would be to have a reliable persistent meterpreter payload with switches for multiple OS's. all stored internal to the Teensy 3.1. no need to download files immediately, do it later... :) Quote Link to comment Share on other sites More sharing options...
Sud0x3 Posted December 6, 2014 Share Posted December 6, 2014 (edited) Indeed, I agree. On the bright side, at least this "simple ducky script" lets us craft payload's easily and quickly within minutes (or perhaps even seconds). It would be great if the ducky script gave more flexibility however. So, does U3 still work or has Microsoft disabled autorun on these U3 interfaces? I was under the impression that U3 drives virtually mounted an iso as a disc on windows. as windows used to inherently run the autorun.inf file from a cd when inserted you could configure autrun.inf to run any script application when you inserted the drive. Was great for stealing data as you still had the usb storage available to you on the u3 drive. I don't see how having u3 would benefit you now though. Thinking about implementing your own ducky script alternative you may want to get yourself a teensy from pjrc.com. If you decide to go down this route you may want to look at Adrian Crenshaw's project http://www.irongeek.com/i.php?page=security/programmable-hid-usb-keystroke-dongle, he also created his own library called PHUKD which you could learn a lot from. Edited December 6, 2014 by Sud0x3 Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.