Jump to content


Active Members
  • Content Count

  • Joined

  • Last visited

About DavesNotHere

  • Rank

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Just browsing and stumbled across this. Newer cars use a rolling code that will not unlock for a replay attack. Is it possible your's is rolling? The locking part is interesting. It might make sense to design the car security to always lock when encountering a replay. Just speculation on my part.
  2. I was going to make some mods to the QUACK Python code. I'm an old Perl guy so decided to use the REPEAT command as a guide to the Python syntax and style. After a lot of hair pulling, I discovered that the REPEAT command does not work in the first place, so my mods based on REPEAT don't either. The Python QUACK code attempts to save previous line state in the "context" list variable (actually an immutable tuple), but it also appears to re-initializes it to empty for every new line, eliminating any state for REPEAT to ever act on. I'm not really a Python guy, so I guess my first
  3. Definitely not a Language issue. If I re-run the same test of a sequence of shifted characters, I get differing results from one run to the next with a low success rate of correct occasional values. I've since discovered that DUCKY also has the same issue but with a low failure rate of wrong shifted values. This only happens on a Microsoft Hyper-V client. I suspect that it's grabbing client keystrokes oddly and the slower DUCKY mostly works. When I get a chance, I'll try modifying BB to add an inter-character delay parameter and possibly some optional SHIFT code logic.
  4. To correct some confusion I inadvertantly created: "DUCKY_LANG us" is correct in the config.txt file as the "us" is a parameter of the extension "duck_lang.sh", so don't use "=". The problem I'm having seems to be timing related specifically to Microsoft Hyper-V. I randomly get isolated correct shifted symbols, but it doesn't repeated reliably. Interestingly, it works fine from a Ducky.
  5. JediMaster beat me to it. While my scancode problem went away on my Linux box by fixing the "Lang=us" declaration, I still have problems on the Surface Book so I decided to try VID CID. I haven't yet tried it on the Surface, but on my Linux box it looks like this: --------------------------------------- # System default payload ATTACKMODE HID VID_0X045e PID_0X005c SN_12345678 MAN_Microsoft LED R Q DELAY 3000 Q STRING echo running Q DELAY 300 Q ENTER Q DELAY 300 Q STRING lsusb Q ENTER Q DELAY 300 LED G Q DELAY 3000 shutdown 0
  6. Further testing demonstrated the same weird behavior on my Fedora 24 circa 2011 hardware, so it's not MS Surface related. I have the fix, although I'm not completely clear on why exactly. It all seems to come back to "DUCKY_LANG". Supposedly the default is "US", and since I'm using "US" everything, one would think declaring "US" would make no difference, but it does! After upgrading the BB to 1.3, the config file had "DUCKY_LANG us", with a space which is apparently wrong. Changing this to "DUCKY_LANG=us" cured everything and all the characters work as expected, with some needin
  7. I was using BB to type in a Base64 encoded executable. (By the way, after start up, the BB types 1.5 times faster than Ducky) After completion I had it save to %userprofile%\mypath\myfile.mim This worked fine on a Win 7 older tower. On a new Windows Surface Book running Win 10, the save failed becasue "%" was output as "5", i.e. unshifted. Further testing demonstrated that the entire top row of number/symbol keys would not output their shifted values, no " !@#$%^&*() I need to do some more testing, but is it possible that the surface uses different scan codes? (Everythi
  • Create New...