juanchoc

overwraith: From what i understand (http://asf.atmel.com/docs/3.0.1/xmegaa/html/group__sleepmgr__group.html) calling sleepmgr_enter_sleep() makes the ducky go to sleep at the deepest level of sleep allowed. But the key is where you call that function. I think that if you call it from the main loop, the device would go into sleep but still handle the interrupts (which is all we currently care about). Also, if you read/write you should call udi_msc_process_trans() to process the read/write operations, and if there's none (false returned) then put the device to sleep. Eg. (taken from the source of the composite duck firmware): while (true) { if (main_msc_enable) { if (!udi_msc_process_trans()) { sleepmgr_enter_sleep(); } }else{ sleepmgr_enter_sleep(); } } In the implementation im working on, instead of using the GPIO button to trigger the change in vid/pid, i'm doing it when the payload execution is complete, and i've been thinking that i could use the GPIO button to execute the payload again (change vid/pid -> execute payload -> change vid/pid again to mass storage).

overwraith: Awesome! I've reached the same conclusion you did (adding the "junk" in the debounce if). I refactored the junk part into another function and after executing udc_attach() i also run sleepmgr_enter_sleep(). midnitesnake: Super awesome midnitesnake! Just what i was looking for. I'll check the code later today and see what i come up with. Thank you both!

So far so good. Now what i'm trying to understand, is how you read from the vidpid.bin file to setup the vid/pid of the device. I've searched around but can't find any reference to that file. Any ideas?

Thanks overwraith! I've been looking into the different firmwares, and the avr drivers/framework. From what i've seen, it seems the udc_reset(void) method resets the configuration of all the device interfaces. To reset the usb stack, i think i would need to do something like this: if( gpio_get_pin_value(GPIO_JOYSTICK_PUSH) == GPIO_JOYSTICK_PUSH_PRESSED ) { udc_detach(); udc_stop(); // Maybe i need to do a udc_reset() here // Change VID/PID udc_start(); udc_attach(); // debounce if( debounce == 0 ) { state = state_START_INJECT; debounce = 250; } }

Hi midnitesnake! Thanks for the fast response! I've tried using the VID/PID of the internal mac keyboard (and also some of the external mac keyboards) in composite mode, but it didnt recognize the keyboard at all, just the storage drive. That was a bit odd, because i was expecting it to recognize only the keyboard (since that is the VID/PID i was using) and not the other way around. Anyway, thanks for the info, i'll look into the firmware code and post back my results!

Hi everyone, I'm trying my ducky on a Macbook Pro, and my initial intention was to use it with the composite firmware (to execute the payload while im "looking for a pdf in my pendrive" basically), but i've found some issues along the way. If i set the VID/PID to the internal keyboard ones (using a non-composite firmware), it works as expected. If i put the VID/PID of another keyboard, the OS asks me to press a few keys in the new keyboad to confirm it's "allowed" to work. If i use the composite firmware (using one of the composite VID/PID) it detects the storage device correctly, and the keyboard correctly, but it shows me the same window requesting me to do a few specific keypresess to confirm the new keyboard is secure. One way to solve this would be to add to my ducky script the initial keypresses required by the OSX keyboard validation screen. But also while thinking about it, i came across another idea. Would it be possible to change the VID/PID while the ducky is connected (maybe forcing a disconect/reset so that the host detects the device again, but this time with another VID/PID set)? One possible use case would be to connect the ducky, it first acts as trusted host keyboard (ie. the internal macbook pro keyboard in my case), executes the payload, and afterwards, triggered by something (the ducky's button? or maybe the end of the script execution?), it swaps the vidpid.bin (ie. with another one that has the vid/pid of a storage device) and forces a reset on the usb device. Do you think doing something like that would be possible?