Scan Codes and Windows Surface Book

[DavesNotHere]

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?

[DavesNotHere]

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.  

[Dave-ee Jones]

Watchu talkin' bout, Willis? I am here. :P (referring to your name ofc)

The reason you have to have the '=' sign is because DUCKY_LANG is a global variable, so treat it as such. It's not a script or function so doing "DUCKY_LANG us" doesn't really do anything. Linux sees it as a variable with another variable (or something else) after it, so it just ignores it.

In regards to the scan codes, I at first thought it was a Win10 issue, treating keyboard interactions a bit differently but then a language issue makes sense. Glad to see it worked out. :)

Edited October 4, 2017 by Dave-ee Jones

[DavesNotHere]

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.

 

[Dave-ee Jones]

24 minutes ago, DavesNotHere said:

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.

I would say that it's a language issue. Are you putting the input to more than one VM?

[DavesNotHere]

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.

[Dave-ee Jones]

On 10/8/2017 at 2:07 AM, DavesNotHere said:

This only happens on a Microsoft Hyper-V client. I suspect that it's grabbing client keystrokes oddly and the slower DUCKY mostly works.

So what you're saying is that it could be a language issue with the Hyper-V client or it could be an issue where the Hyper-V client isn't pulling every individual keystroke quickly enough or multiple keystrokes in unison? Maybe try another VM platform just to see, though I don't know if it would help a great deal or not..