Jump to content
Sign in to follow this  
DavesNotHere

Scan Codes and Windows Surface Book

Recommended Posts

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?

Share this post


Link to post
Share on other sites

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.   :grin:

Share this post


Link to post
Share on other sites

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 by Dave-ee Jones

Share this post


Link to post
Share on other sites

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.

 

Share this post


Link to post
Share on other sites
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?

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites
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..

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
Sign in to follow this  

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...