no42

Long live the Snake's Legacy.

$5 wrench technique always a winner: https://xkcd.com/538/

and he becomes a master / ducky-jedi

Depends on how the database/system is implemented? Part 1: Getting access to the database. SQL injection through web applications is usually the most common ways, as web applications are so common these days. What people sometimes forgot is that binary/native/thick applications can also communicate with databases, and sometimes a network port is available. But usually if the application is in the public domain a web gateway is used to proxy the database traffic; as opposed to internal (eg. corporate) domains will have the databases accessible across an internal network. With logical access to the database services; you can try many other attacks; brute-force the login, apply any remote code election exploits, some database versions even suffer authentication bypasses. Part 2: Configuration of the database With access to the database, the next step is usually a privilege escalation to get database administrator (DBA) privileges; some databases are misconfigured that you may have logged in as the DBA. But if you haven't, your looking for a weakness in the functionality or a stored procedure to give you extra permissions or alternatively brute-force the dab admins credentials. Once dba privileges have been achieved you can plunder all the databases stored on the affected server. In addition to all the associated users passwords hashes; its likely that passwords are repeated by developers on other systems, or could be domain-accounts leading to further compromise.

Do you have a USB keyboard? and can you use a USB sniffer to captcha the key combination of \ looks like the encoder needs to be updated.

Does the following work? CTRL-ALT \

Just look at the ducky decode website, any newer encoders are now on google drive. Another way is to post the inject.bin file; i can easily reverse it; or hopefully others can, I'm pretty sporadic on here these days

Can you try the offline encoders? I want to figure out what version this bug might have crept in. Thanks ~

You have 2 options: 1) Use 2x HackRFs (1x receiver, 1x transmitter) - due to the 1/2 duplex nature 2) Use a bladeRF - as its full-duplex

Source code is available, just make the necessary changes and recompile.

This is currently only possible in the hard-coded firmware. Currently not possible in DuckyScript. Hardcode.zip

Easy enough to implement, I just don't have the time these days. The source is available, a suggestion would be to do it your-self.

Your bug is to do with size - specifically size of memory. Each key-press, and some key-combos use two bytes {modifier byte, key byte} and micro controller has limited memory, as the payload needs to be read into memory before swapping to storage mode. You have 1-2KB (from memory) so you need less than that number of bytes to work correctly. As for the firmware, googlecode changed their download policy, there is a bunch of updates in google drive, the link is on the ducky decode homepage. My personal circumstances have changed which means I don't have a lot of time to support this project these days, but the ranks have expanded with a few ducky developers. Not sure whats been going on lately...

Some initial questions: 1) Version of the encoder you used? 2) Version of the firmware you used? 3) Did you use a specific language map?

Try this link first: [Tutorial] Re-Flashing/Upgrading the Ducky WINXP 32bit or https://code.google.com/p/ducky-decode/wiki/Flashing_Guide

have you installed libusb? think the command is: apt-get install libusb-1.0-dev

Device control software is more advanced these days compared to the original stance 2 years ago. 1) You need the same device class, e.g. if the device is mass storage, you can't use the composite firmware, you have to use a mass-storage firmware 2) You need to change the serial number and other device strings in the source and recompile - no easy way to do this rather than build your own firmware. 3) Device control is (or future) performing stack fingerprinting; this may mean further changes would be necesary in the firmware.

If SRP is in the way sometimes this trick works: DELAY 4000 GUI-R DELAY 100 STRING runas /trustlevel:"Unrestricted" cmd.exe ENTER

Well this is very odd. I haven't encountered this strangeness before. I recommended contacting the Hakshop and going through the return/exchange process.

OK this again is expected behaviour, DFU mode is the bootloader-mode for installing new firmware; which we know already works. Depending on the firmware; something should appear within "Human Interface Device", "Removeable Media", "Other Devices" or "Universal Serial Bus Controllers"

- Plug it in to the Windows laptop without an SD Card: Get a solid red light This is correct and expected behaviour - Plug it in to the Windows laptop with ANY of the 3 SD cards I own: No LED light at all. If I wait some time (maybe a few minutes), it will turn on as a solid red light. Sounds possibly like a driver issue - Plug it in to the Windows laptop with ANY of the 3 SD cards and then push the button: Again, no LED light at all Sounds possibly like a driver issue I need to know more about how the ducky shows up in device manager to potentially diagnose your issues? Its odd that you've been able to flash the Ducky as usually faulty Ducky's aren't re-flashable. Also how are your sdcards formatted?

which encoder are you using 2.6+ regenerate a simple payload, and retest. Firmware looks fine, its either the payload or the sdcard? though usually you get solid red if its related to the sdcard.