Jump to content

knight

Active Members
  • Posts

    5
  • Joined

  • Last visited

Everything posted by knight

  1. First, let me appologize for such a huge delay in response, I've been out of town for an extended period of time, and I took my laptop, but it turns out the cellular data in Jamaica is incredibly expensive! ($1.99/MB!) This is amazing... it's almost exactly what I was wanting, though there is one little issue, and I'm thinking it was probably a miscommunication rather then a bug. I'd prefer it if the "payload key" was ONLY the scroll lock. I said other keys above simply because I wasn't sure if the scroll lock could be used this way. I'm sure this is a small, slight modification which should be easy, but it would make things perfect. I want to be able to leave the rubber ducky always plugged in, and only execute the inject.bin when the scroll lock is pressed, so because of this, I want to be able to use my caps lock, num lock, etc without causing the payload to be ran. Edit: Also, I'd prefer the LED's to remain off at all times. Unless you are able to make the LED's respond to data usage on the mass storage device. Much thanks, this is amazing! Knight.
  2. This isn't a issue for my application. 4K is probably about 100 times more memory then I'll need for my purposes! And any future uses also. I also don't need multiple buttons, just a simple numlock, or capslock. Preferably Scroll lock, since that's really not ever used anymore. Also, after the "trigger key" (numlock, caps lock, etc) is pressed, I'd like to be able to change the state back, without it triggering the payload again. Because when the ducky senses the trigger key, it'll change states (on to off, or off to on) and I'd like either the firmware to reset back to the original, or the inject.bin script to be able to change it, but prevent a infinite loop... not sure if that can even be done, just one pitfall I've tried to look out for! :) If we cna make the scroll lock work, that would be IDEAL. Since it's really not even used anymore. You're amazing, Midnitesnake! I'd be more then glad to paypal ya some funds, or greendot or something! Thanks! Knight.
  3. I totally agree, but I wasn't sure if that could be done from a technical standpoint. I'm fairly sure the ducky can detect when caps/numlock is on, since the m_duck.hex firmware is capable of changing the color of the led based on caps/numlock being pressed on. Knight.
  4. That's no problem. I was just hoping to get the keyboard to laod first, just to increase compatibility, but it probably won't be a issue anyway! So do you think it's doable? Mostly the part about watching the numlock and playing the inject2.bin only when the numlock is pressed, without having to press the ducky's button, I'd like to keep the case on. Much thanks! Knight.
  5. Board, I was wondering if there was any way I could get a custom firmware made... I would suspect this kind of project would be fairly easy, since everything I'm looking for has already been done, at least I think. I just need a few of the features of one firmare added into another. Midnitesnake and or Nick have wrote firmware that adds Mass Storage functionality, LED usage functionality, numlock state change, etc. Here's what I am wanting.... When the ducky is initially inserted it only registers as a mass storage device, no payload, no keyboard presses, etc. I'd prefer it if the device registered as a keyboard FIRST, then as a mass storage device second. Then, the ducky monitors for the num lock on the keyboard to be pressed, when it's pressed then it initiates it's payload. I'd prefer it to look at the scroll lock, but I'm not sure if it can sense that, since I haven't seen that functionality in any other firmwares. I also never want the LED to turn on at all unless there's a problem, though this isn't much of a problem, since my intentions are to leave the case on the ducky all the time. As for the technical aspect, I'm fine with formatting multiple partitions on the sd card if that's needed, or just leaving the inject.bin on the root of the SD card, which would be visible from the mass storage driver. I don't have any problem with the ducky associating a keyboard initially, before the first numlock or scroll lock use. What would be perfect would be for the ducky to not need a inject.bin and instead it would read a ascii file, say, %drive%/info.txt or whatever, and use that as a ducky script, though if I have to use a encoded inject.bin that's fine too. I'd be willing to pay to get a firmware like this. Knight.
×
×
  • Create New...