Polisher

Why do you want to use email to send the data? Email headers contain much more info as to what is happening than in the email itself....

I don't want to prove you wrong actually! Matter of fact I think you are absolutely right.

Only an absolute maximum of five can join the project and receive the firmware and documentation. And no you are not allowed to donate if your donation doesn't contribute towards the goal of 240 euros. (240eur/5 people is 48 euros)... Euros are not the same as dollars either... Right now I just want to see a show of hands on how many people want to join.

Good questions overwraith. My intentions are not to release the codes/firmware to the public because it will make the ducky and teensy too easy and convenient to use. There is no easy defense against it either if it is used in malicious ways. Not now or the future. Yea I totally agree that developers of pen-testing tools should not be held liable. Unfortunatly in Germany there is a law saying that you can not sell, distribute or give tools that "hack". The official use of goodUSB is for debugging systems and setting up a lot of different devices using one USB stick. What payloads you use with it is up to you though. I am not doing this project to monetize from, but I do expect a small compensation for my time for which I will share the documentation/code/firmware with you. You will have to agree not to share it with anyone. I think that is a fair approach? At the moment I just want to see if there is enough interest. I will let you guys know when my code reaches a respectable stage.

Code samples will not be provided to the general public. I will not start taking money until I am quite confident that my code will work, or the very least be in such a stage where it will only require some fine tuning. So a concern of yours is whether I am legitemly developing something or am just going to take the fund money and run? That is a very reasonable concern and I am open to suggestions on how I can be verified. Btw in my country that kind of fund money could buy me a hotel. See video below. (Just kidding I am from Germany :) )

I do not see a problem giving the source code as part of the documentation. Actually I am not going to be borrowing heavily from others! No code has been published by anyone for USB OS autodetection unfortunately. The majority of the code that I am using is published by atmel, as with all firmwares here... If you guys want to chat feel free to pop into #hak5 or #ducky @ irc.hak5.org

thanks for your kind words Oli. Everything you say makes me smile! :) The project will cost 240 euros. You will get constant running updates and every single piece of documentation. You may also get beta versions before you get the final v1! I will try to deliver in 1 week from the time i get the rubber ducky! 2 weeks though to give me some cushion if code doesn't run the way i want it! As soon as the crowd fund goal is met no more people will be able to join this project. Edit: If you all can give me a show of hands who wants in it would be great. You obviously do not pay if the goal has not been met.

Good questions. If anyone else has any questions please ask them here. A clear outline and all documentation necessary on how OS Auto detection works will be provided by me. I have already gathered unique identifiers for 6 different Operating Systems. (More Operating Systems and devices are coming!) This information is more than enough for me to build goodUSB. A great coder can build it probably in a day or two with the outline and documentation, but I am not the brightest and will need about a week or two. Regarding why I chose rubber ducky: It already has a correct USB port so there is no need for soldering or using a bulky adapter (like on the teensy) + the thumb drive case. The ducky has more than enough power to run goodUSB. Nohl's 8 bit usb controller had 12mhz. The ducky uses a great 32-bit controller with 60mhz for which there are many great open source firmware codes.

Is anyone interested in me developing OS autodetection? The firmware will be able to automatically detect the OS it is running on and based of that it will choose the appropriate payload for the OS. goodUSB will be able to differentiate not only between desktop OS versions but also detect some devices like android phones, Linux STB receivers and IOT devices! I have a lot of free time in the next two weeks to code this. You will get running updates on this project, all documentation, fingerprints with unique identifiers and the firmware. Only 4 - 5 people can join the project. Redistribution of the software or documentation is not allowed.

If there is interest in OS auto detection we could get crowd funding going for this. It will help me finish it much sooner! The BadUSB capabilities should bring new life into it. I will only accept 4 or 5 people into the project and you will agree not to share the documentation or firmware with anyone. The worst people and biggest agencies probably already have this, but this should not be accessible to the average joe and everyone else! I will need around 200-240 euros for this project. (56 euros for the rubber duck + shipping and 150 euros to get me through the next two weeks). Once the 200-240 euro target is reached I will not accept any more people. I have a lot of free time in these next two weeks, but I am looking to finish this in one week! If you are interested reply here and PM me so I can provide you with more info about the project. (P.s I will not trade my code for payloads so please stop asking me that in PM :) )

Karsten Nohl didn't release his BadUSB firmware for a good reason in my opinion. I am coding the same thing at the moment however I am respecting Nohl's opinion and am not releasing it to the public when it is finished. OS Fingerprinting is too powerful and can be abused a lot more than twin duck or any other firmware. I will only share it with a few friends... Besides, I have not bought a rubber ducky yet. I am ready to code it now though!

Karsten Nohl didn't release his BadUSB firmware for a good reason in my opinion. I am going to respect his opinions and not release it when it is finished. I will only share it with a few friends... Besides, I have not yet bought a rubber ducky yet. I am ready to code it now though!

That is why you would want to move your window to the top left of the screen (0,0). That way you have a reference.

You could control the mouse using powershell. There are enough scripts and examples that you can google! About the visual aspect, you do not necessarily need any visual feedback. You could move the mouse and click on things that you know will always be in the same positions. If they are not always in the same position you can position the window so the buttons you are looking for are in the positions you want! Have a look at the following video. The guy did just that but on a mac. The idea is the same though.

overwraith: are you trying to accomplish anything specific?

Your "computer" needs to be able to act as a USB slave device. Devices with USB OTG can do that. Your laptop cannot... A rpi model A would theoretically be able to do what you want because it can do USB OTG. ( A model B has the same chip but the usb port runs through a hub making OTG inaccessible). A rpi is powerful enough to do what you want it to do, BUT, you would have to code the USB drivers from scratch, which would be no easy task! A model A rpi would require no hardware changes (apart from the usb cable adapter). Software would be the hard part!

@overwraith yes it theoretically should be possible with a pi as long as your model has USB OTG. Using a camera to capture and analyse the screen would be inconsistent. Lighting, focus, angle, screen type and other external factors will all need to be considered. This will also add more stress on the cpu/gpu. What you could consider is using USB to capture the screen. For this you will need to turn your device into the USB Monitor Class. This is a standard in the USB specification. http://www.usb.org/developers/hidpage/usbmon10.pdf Your device would need to switch back and forth between a keyboard device and monitor device.

Nice vid --- just FYI that isn't BadUSB you are showing. it is Psychson. BadUSB has never been released and contains nice features like OS Detection and on the fly class changes! Really cool video otherwise :) Is it possible to reflash the USB stick as many times as you want? Or do you need to short the pins after you have flashed it once already?

When you plug in your ducky it becomes like a normal external keyboard. This is why ducky doesn't need a FN key. Key presses are all registered in software by the OS and not the hardware of your laptop. :) Try CONTROL ALT t NVM that is for terminal Edit: Maybe it is a Timing issue? Have you tried setting a delay at the beginning of the file?

I apologise Oli. I have looked through your other posts and you seem like an awesome guy who knows his stuff! regarding badUSB. The code hasn't been released. The capabilities include: detection of the OS and switching usb classes from Mass storage to HID while the stick is plugged in for example. have a look here With that said I have gathered all the necessary info to be able to build a OS detection feature myself. I am not the brightest of people though when it comes to computers though. I am more than sure that you or one of the other guys here will be able to show me how to implement the features with the infos I have obtained.

Why do you think that Oli? I know you are somewhat against the products because lack of support from hak5... Maybe this is a bias of yours? Nohl's badUSB runs on a USB Flash drive that is quite a lot weaker than the rubber ducky. His USB stick has an 8bit microprocessor with 12mhz. AND it is perfectly cable of saving and comparing the handshake and therefore auto detecting the system! I know what to look out for in the source code to make this happen. Theoretically it is easy. Please keep this discussion technical.

That is a good start. Things like android phones, Linux set-top-boxes (stbs) and embedded devices do not usually have a keyboard. I have two STBs which can be controlled with keyboards for example. In those cases OS auto detection makes a lot of sense. The USB rubber ducky does respond to the handshake from the OS when it identifies itself as a HID. I don't see why the rubber ducky can not save the handshake to ram before it responds to the OS!? Do you guys know if this can be done? I do not have a rubber ducky yet. If anyone is good at C though I can help you with the theory! If you are good at C please let me know and we can make this hack together.

Ok, so I did quite a bit of Research and googling about this topic. Theoretically it is possible to detect which OS the USB stick is running on. While the OS itself never identifies any Information about the OS or host hardware, it does use a handshake to authenticate with the USB device. The sequence of this handshake is slightly different in every OS and has got some unique properties. I have already noted the unique identifiers for OS X 10.7, Windows XP and Windows 8 using past research. The only thing we would need to autodetect the OS is to code the ducky to save the handshake! A small program will check the handshake for the unique identifers and reliably determine the OS! If and how it is possible to save the handshake with the ducky I don't know. Does anyone have any knowledge about this?

Is it possible that we can code the duck to have different enumeration properties. For example it could be coded to register as a webcam class or some other interesting class. Besides IDs and classes can we change the other address space too? Is it possible we can record the enumeration traffic between host and device?

Is it possible to auto detect the OS and choose the corresponding payload? By the looks of it Nohl's solution had this feature.