DavesNotHere

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.

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 question is: Does REPEAT work on the 1.3 firmware?

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.

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.

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 .......... lsusb Bus 002 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 001 Device 005: ID 2109:0810 VIA Labs, Inc. VL81x Hub Bus 001 Device 012: ID 045e:005c Microsoft Corp. Office Keyboard (106/109) Bus 001 Device 004: ID 2109:0810 VIA Labs, Inc. VL81x Hub Bus 001 Device 007: ID 093a:2510 Pixart Imaging, Inc. Optical Mouse Bus 001 Device 006: ID 413c:2011 Dell Computer Corp. Multimedia Pro Keyboard Bus 001 Device 003: ID 413c:1005 Dell Computer Corp. Multimedia Pro Keyboard Hub Bus 001 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 004 Device 003: ID 2109:0810 VIA Labs, Inc. VL81x Hub Bus 004 Device 002: ID 2109:0810 VIA Labs, Inc. VL81x Hub Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

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 needing escaping to print. I don't fully understand, but I have a path to success.

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? (Everything is US). Could Hypervisor make a difference? If I can figure out the corrections, maybe I can make a Lang_US_Surface as a fix, or force out key codes. Insights?