Doesn't use local keyboard layout to type password #9
Comments
|
I was worried about this but wasn't sure if host OS's would do the correction. This is possible even without a firmware upgrade since the client sends the keycodes for the device to emit. I just need to find some kind of table mapping the differences between common layouts.
…On December 28, 2017 11:06:22 AM PST, Necklaces ***@***.***> wrote:
I just received my Signet, thanks! Tried adding in an account and
making it type out my credentials, but then I noticed it would type '@'
(at) as '"' (quote) and '_' as '?'. These are typical US/EN vs. NO
keyboard layout differences.
So I'm guessing we'll need an option to chose what layout we want it to
type with, is that possible?
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
#9
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
|
|
I looked into my USB firmware code and I noticed that there is a HID field for "target country" and it was set to 0 for unknown/invalid. I've changed this to US in the hopes that the host will now have the information to perform a conversion to the local layout. The USB HID specification suggests that this might work but it's not clear. Would you (or anyone else who doesn't have a US/EN local layout) be willing to try the latest firmware that includes this change? You need to pass in the file at https://nthdimtech.com/downloads/signet-releases/firmware/signet-1.2.3.sfw into the "device->update firmware" dialog after unlocking your device. |
|
Hm well I downloaded that file and passed it into the update firmware dialog, seemed to apply it successfully and all but I still get the same result. |
|
If you saw a "writing firmware" progress bar and it brought you back to the unlock screen then it succeeded. I just added some code to the about box to show the firmware version. It shows two versions, one is the "target" firmware version that the client was developed against and the other is the "device" firmware version which is the version that the device has. My intent is that each client will operate against wide range of firmware versions. The is to give users a cue if their firmware could use updating to expose new features supported by the client. The USB documentation can be hard to navigate. If you look at section 6.2.1 (should be page 22) of the HID specification there is a section that reads: "The value bCountryCode identifies which country the hardware is localized for. Most hardware is not localized and thus this value would be zero (0). However, keyboards may use the field to indicate the language of the key caps." I was hoping that this would mean if the device declared itself as US then the host OS would first map the codes to US then remap them to the local layout. Your experiment seems to show that this doesn't happen so it looks like the remaping needs to be done by the client. This would happen in signetdev/host/signetdev.c inside of the signetdev_type() function. One interesting way of creating the key mapping is to create a feedback loop by telling the TYPE command to type a range of scan codes and see what key codes are generated by the OS. |
|
I have the same issue (just got my Signet today - THANKS). My work laptop is using an Irish keyboard layout (@ and double quotes are swapped). Have not tried on my German desktop computer at home yet, most problably will be even worse :) Would be great to find a solution for this. I think everyone outside of the US will be impacted. |
|
Maybe bCountryCode works the other way around. If you have e.g. an Irish keyboard layout you have to tell that you're using English (Irish) and then the OS will map accordingly. If you can provide a firmware version set to English (Irish) I'm happy to give it a try. |
|
I gave it another thought :) Not sure if bCountryCode will resolve the issue because you're sending scan codes identifying physical keys on the keyboard, not characters. Depending on the keyboard configured in the OS a scan code will result in different characters (@ and " are obvious, but on a German keyboard e.g. Z and Y are swapped as well-beside many other keys; on a French keyboard A and Q, ...). At the end of the day you may end up with many different lookup tables. I think your approach (checking which scan codes generate which characters locally) would be the best one. |
|
I'm working as quick as I can to resolve this. I have created a widget that detects the layout based on my proposed method of checking the key generated by each scan code. I just need to integrate it with the main GUI and make it save the result so that you only have to do it once.
…On January 2, 2018 7:26:40 AM PST, claus0731 ***@***.***> wrote:
I gave it another thought :) Not sure if bCountryCode will resolve the
issue because you're sending scan codes identifying physical keys on
the keyboard, not characters. Depending on the keyboard configured in
the OS a scan code will result in different characters (@ and " are
obvious, but on a German keyboard e.g. Z and Y are swapped as
well-beside many other keys; on a French keyboard A and Q, ...). At the
end of the day you may end up with many different lookup tables. I
think your approach (checking which scan codes generate which
characters locally) would be the best one.
--
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
#9 (comment)
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
|
|
With this method, will you be able to detect some more exotic keyboard mappings? I mean bepo for my need. |
|
It can in theory but my current revision would detect only two of up to 4 characters I see in the layout. It looks like both shift and right alt are used as modifiers, is that right?
…On January 3, 2018 7:05:25 AM PST, Christophe Drevet ***@***.***> wrote:
With this method, will you be able to detect some more exotic keyboard
mappings? I mean [bepo](http://bepo.fr) for my need.
--
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
#9 (comment)
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
|
|
I've done some more research and tests. I am able to detect the keys generated from all key positions and all combinations of Shift and Right Alt which is almost good enough. However, I at least need to be able to generate common ASCII codes but I've found there some ASCII codes such as "^" in some layouts (such as German) that are only generated through a key combination of the "^" key and space. I was hoping to have a usable test version today but considering this additional complexity it's going to take at least another day. |
Yes, you're right. Some characters need right alt like these: |
|
Getting closer... I can detect so called "dead keys" now: keys that are pressed before another key to modify it. I can also map out the characters that each dead key can be used to generate. I'll publish a test version soon, hopefully tomorrow, that will be able to make use of dead keys, shift, and right alt to type all characters for any given layout. |
|
Preparing for release now. I've tested using Signet to login to sites using the layouts EN(US), French BÉPO, and German. The only dead character sequences I'm supporting for now are modifications of space which seems to generate enough characters for usernames and passwords. The typing code now operates on unicode characters so even some characters that might not be allowed in a password can be typed. |
|
Here is a URL to download the test fix for 64-bit Windows: I can post builds for MacOS and Linux on request. Once logged in click "device->configure keyboard layout". You'll see a default English US keyboard layout but when you click the "Configure" button Signet will start generating scan codes and you should see characters showing up on a grid. Make sure you don't switch to another window or else the characters wont be captured and the configuration will fail. If what you see in the grid looks correct click "Apply" and see if the typing function works correctly. For now the configuration is not saved so you will have to reconfigure if you exit the app. This will be fixed in the next official release. I'll also improve the configuration interface and make it more clear what is going on. |
|
I pushed to a branch called "keyboard-layouts"
…On January 4, 2018 11:24:42 PM PST, Necklaces ***@***.***> wrote:
I'm on GNU/Linux but I'd rather build myself, though it doesn't look
like you've pushed the changes to this repository?
--
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
#9 (comment)
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
|
|
If you build yourself make sure to update the signet-firmware submodule and rebuild. There are needed changes in there. |
|
Looks like it's working! 👍
Also tested it outputting my entries and it works perfectly as far as I can see. |
|
Wow. That's quite magical! |
|
I only have a 32bits Windows at hand for now. Can you provide a build for this target? |
This is a usual configuration. But there are hundreds of other layouts people are using, where any other key or key combination can be a modifier (I'm using the combination
Depending on the speed, but this might be also run automatically upon each (re)start without any user interaction.
Unfortunately not - simply because of the modifiers issue described above (btw for ULKL I'm currently supporting X11, Mac OS and Windows and I have to say that the Windows platform is by far the most complicated, but e.g. the C source code generated by MSKLC nicely demonstrates that the list of modifiers might be totally arbitrary). |
I hadn't considered modifier customization but I think it's possible to auto-detect that too. Key presses that modify characters don't seem to be passed to the application by themselves. The application only receives the final modified character or nothing at all. All that the configuration widget has to do is to see which sequences don't generate keys or modifier flags and investigate those. I already did this kind of checking for "R-Alt" to speed up configuration when R-Alt just maps to plain Alt. I'm going to draw a line at trying to detect the usage of ordinary keys as modifiers but still auto detect their usage as dead keys.
I just realized the configuration I had for building 32-bit binaries was actually generating 64-bit binaries. I will fix this but it will take some time. |
|
Getting much closer to something that can be released. The code on the "keyboard-layouts" branch now can save and load the layout from the settings file. You should only have to configure the keyboard layout once for every time you change it in the OS. All that remains for an initial release is
|
|
Note that with the latest commit on the "keyboard-layouts" branch you now configure the keyboard layout from "file->settings" instead of the "device" menu. |
|
Just to be sure - the code we shall test is in the "keyboard-layouts" branch and not in the "keyboard_layouts" branch, right? Because in the "keyboard_layouts" branch there are newer commits than in the "keyboard-layouts" branch. |
|
Yes it looks like I made a typo when pushing.
…On January 6, 2018 2:44:59 AM PST, dumblob ***@***.***> wrote:
Just to be sure - the code we shall test is in the "keyboard-layouts"
branch and not in the "keyboard_layouts" branch, right? Because in the
"keyboard_layouts" branch there are newer commits than in the
"keyboard-layouts" branch.
--
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
#9 (comment)
|
|
I think the work is not all that experimental anymore so I've moved it to master |
|
I've made some changes to make keyboard layout configuration easier to understand and more robust and am preparing for release. Feel free to take a look. I've built a client for MacOS since I believe I wanted to confirm I had fixed an unrelated crash bug there: https://nthdimtech.com/downloads/signet-releases/0.9.7/macos/signet-0.9.7.dmg |
|
Testing on a 64 bits windows at work. The build you did a few days ago (0.9.6-kb-layout-test) doesn't fully work. The right part of the screen (with R-Alt key) is totally blank, leading to missing characters in the layout. I'm not sure I'd be able to compile for Windows, so, do you have a newer build? I think it would be good to trigger an error if a "unknown" character is present in a field when trying to use it. In the current configuration, it's just silently ignored. |
|
Which windows version? I had some successful tests with Windows 7 after changing my keyboard layout to a few different non-US layouts. I'm pretty sure what's going wrong. I have a test that tries to detect if R-Alt is being used as a modifier or not. The test assumes that if a key is being used as a character modifier then it will not also appear as a modifier on the key in a key press event. I'm guessing that there is an inconsistency between Windows versions on what the key events look like. I think I will just disable this optimization until I can figure out what I can count on. Layouts that don't use R-Alt will just duplicate characters on the R-Alt side. Good point about the processing of "unknown" characters. I've opened a new issue for this: #18 |
|
Here is a 64-bit Windows client without the R-Alt optimization: https://nthdimtech.com/downloads/signet-releases/0.9.7/windows/signet-0.9.7-rc2-64bit.exe |
It's probably not just an inconsistency between Windows versions, but between any application. There are several ways how to input characters on Windows and each application uses a different one - e.g. Notepad.exe is different from Microsoft Word 2016 and that's different from Google Chrome and that's different from Qt-based applications (I've tested neovim-qt). There are standard keyboard layouts (just a dll), then other input methods (e.g. Microsoft Text Services Framework) and others. Each application is also handling modifiers and shortcuts a bit differently (because some apps and frameworks use low-level winapi calls) etc. and therefore obscure situations appear and are not solvable. Surprisingly the most "reliable" method seems to be AHK (AutoHotkey), because it sits on the very top of all these APIs and frameworks and can therefore handle nearly anything. But it's sometimes slow and it's configuration highly error-prone (race conditions etc.). It's simply an extreme mess. A few links can be found in the README in the ULKL repository: https://github.com/dumblob/ULKL/tree/master/platform/win . |
|
I'm using Windows 8.1 64 bits, with a custom keyboard layout installed from bepo.fr (the installed version, not the portable version). It seems to be a terrible mess, indeed. The latest build (0.9.7-rc2-64bit) works well. |
In this case it would likely be the difference between the OS version because the test result varied between Windows 7 & Windows 8 for the same code base. The most likely use case for Signet is typing text into a Browser so I'm not going to make any radical changes unless browser text input is varying considerably. |
|
It's seems OK. I used signet with some proprietary management software under a RDP session, all using my bepo layout, and it worked fine. |
I believe no radical changes will be necessary - the chosen approach covers nearly everything. I just wanted to point out, that layouts and their behavior on Windows is a total long-standing mess. Speaking about browsers, we shall test most interesting ones (Chromium, Opera, Firefox 57+, Edge, Safari, ...) and namely on Windows 7, Windows 10, Mac OS, X11 (on some Linux, BSD, ...), maybe Wayland. Each of these uses a different input method, so it could give us a good overview which issues might appear. |
|
That's a lot of combinations and I have limited time. I'm a little confused by your statement that each of the applications use a different input method. Outside of Windows I would assume that most of the variation would be on the OS. Sure the applications might use a different toolkit but I would expect those differences to not be exhibited in terms of the relationship to the keyboard. If you had to make a paired down matrix what would you consider culling to cut down the test time?
…On 01/09/2018 02:19 PM, dumblob wrote:
The most likely use case for Signet is typing text into a Browser
so I'm not going to make any radical changes unless browser text
input is varying considerably.
I believe no radical changes will be necessary - the chosen approach
covers nearly everything. I just wanted to point out, that layouts and
their behavior on Windows is a total long-standing mess.
Speaking about browsers, we shall test most interesting ones
(Chromium, Opera, Firefox 57+, Edge, Safari, ...) and namely on
Windows 7, Windows 10, Mac OS, X11 (on some Linux, BSD, ...), maybe
Wayland. Each of these uses a different input method, so it could give
us a good overview which issues might appear.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#9 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/Ad4tAEp9qOVw848-8KdBFp11IqouPoUtks5tI-X5gaJpZM4ROkpJ>.
|
|
I've (hopefully) finalized release 0.9.7. See https://nthdimtech.com/downloads/signet-releases/0.9.7/ I'm switching focus to getting this out to all of the backers in a campaign update but if anyone here finds a critical issue I'll take a look |
|
I can help with the different tests proposed by @dumblob. I have access to a 32 bits windows 7, a 64 bits windows 8.1 (with Office 365 Pro) and some linux machines (debian and archlinux both with gnome). I can test different browsers too. |
@nthdimtech you could simply call the "release" a "release candidate 1" and spread it across backers with a recommendation to test special keyboard combination especially with less common keyboard layouts and with widespread, but potentially problematic apps (MS Excel, Chromium, Edge, Firefox 57+, ...) to get some more feedback. @dr4Ke sounds good to me. I have currently easy access to Windows 10 64bit (with MS Office 365) and Arch Linux 64bit Xorg-server 1.19.5 . I didn't receive my Signets yet (but I believe it's just the delay of shipping to Germany), but once I'll have them, I'll definitely test everything immediately. I would be also interested in filling in secrets on system login screens on Windows, Linux console, and X11 GDM (I count on the fact, that I will need to hack around a bit and maybe even without success). |
That seems like a good strategy for a Signet mailing list which I have been considering creating but I want to limit the number of campaign updates so people don't start ignoring them due to information overload. What I think I will do instead is add some content about this to the website release page and have a link to a page showing a Matrix showing the combinations and what the test result is. The website is open source (https://github.com/nthdimtech/nthdimtech-site) so once I have the test matrix added you could use a pull request to post the results of any tests you've done.
All devices ordered during the campaign were shipped out at pretty much the same time so you're probably right.
Yes this has been on my mind as well. The question is how to some level of security and how to choose which password you want. I've just created an issue for this: #22. You could use a morse code like sequence of button presses to authenticate then use some kind of slots system for typing the password: 2 presses to type the password in slot 2, etc. I would encrypt these passwords separately and probably store them in the first block of flash memory since there is free space there. These passwords would be easier to crack if someone got a hold of a device database backup but it's probably still better than duplicating or using easy passwords for your system logins. Feel free to comment in the new bug. |
|
I've created an issue regarding the test matrix idea here: nthdimtech/nthdimtech-site#3 |
|
Release 0.9.7 has been out for awhile and all indications are that the keyboard layout configuration feature it is working for people. If there are problems in specific cases we cab open more narrowly defined bugs for them. |
I just received my Signet, thanks! Tried adding in an account and making it type out my credentials, but then I noticed it would type '@' (at) as '"' (quote) and '_' as '?'. These are typical US/EN vs. NO keyboard layout differences.
So I'm guessing we'll need an option to chose what layout we want it to type with, is that possible?
The text was updated successfully, but these errors were encountered: