Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Mooltipass mini - Inverted key codes for keys @/# and </> in French and Belgian French Apple keymaps #575

Open
ReversingCat opened this issue Jan 25, 2021 · 1 comment

Comments

@ReversingCat
Copy link

Expected behavior

On macOS with a French or Belgian French keyboard layout, and using the Mooltipass mini in keyboard emulation mode set with fr_MAC keymap, usernames or passwords containing one of the following chars: # > < @ should be entered properly.

Actual behavior

Instead of the proper characters, the following chars are incorrectly sent in USB keyboard emulation mode:

  • # is not sent and replaced by>
  • > is not sent and replaced by #
  • < is not sent and replaced by @
  • @ is not sent and replaced by <

Step by step guide to reproduce the problem

  • Use the Moolticute application to set a new username and/or password using the following characters # > < @
  • Set the keyboard layout to fr_MAC in the Moolticute application
  • Set the keyboard layout in macOS to French or Belgian French
  • Use the scroll wheel of the Mooltipass mini in emulation mode to trigger the typing of the username/password set in the first step
  • Observe the incorrect typing of the chars # > < @

Operating System

MacOS Big Sur 11.1

Mooltipass Extension

N/A

Mooltipass Application

Using Moolticute 0.44.21 to select and store the key amp

Mooltipass Device

The Mooltipass Mini

Website support

N/A

Detailed debugging

Hello !

I’ve noticed that some of my passwords where incorrectly entered when using my Mooltipass in keyboard emulation mode on macOS using the fr_MAC keymap on the Mooltipass, and using a French Belgian keymap on macOS.

I assume you are all very busy with the upcoming miniBLE, so I’ve tried to debug as much as possible myself :-)

At first I thought that the Apple Belgian French keymap was slightly different than the Apple French keymap, but :

  • The erroneous behavior continues even if I use a French (non Belgian) keymap on macOS
  • According to this ( https://support.apple.com/en-us/HT201794 ) Apple support page, I see no physical differences in the layout of an Apple French keyboard and an Apple Belgian French keyboard

After tracking down which characters were incorrectly sent by the Mooltipass, I found that :

  • # is not sent and replaced by >
  • > is not sent and replaced by #
  • < is not sent and replaced by @
  • @ is not sent and replaced by <

Now, you will find that on an Apple French and Belgian French keyboard, @ and # are on the same key, and < and > are also on the same key. It probably means that, somewhere, the key codes for those two keys were inverted.

Strangely enough, I found this post ( https://discussions.apple.com/thread/7501630 ) on an Apple support forum complaining that those two exact keys were also inverted in BootCamp.

If I understand correctly the source code, the USB HID key codes are sent using a Look-Up Table defined for each keymap. Each LUT is 95 bytes long and each bytes correspond to the USB HID key code XORed with the keyboard modifier (shift or ALT-Gr) to send for each ASCII character, from space (0x20) to ~ (0x7E).

Starting counting the positions from zero and in decimal, in the 53_FR_MAC_keyb_lut.img LUT file:

  • # is ASCII 0x23, so it’s byte 3 in the LUT, and its value is 0x83, i.e. the keycode 0x03 with a SHIFT modifier
  • < is ASCII 0x3C, so it’s byte 28 in the LUT, and its value is 0x35
  • > is ASCII 0x3E, so it’s byte 30 in the LUT, and its value is 0xb5, i.e. the keycode 0x35 above with a SHIFT modifier
  • @ is ASCII 0x40, so it’s byte 32 in the LUT, and its value is 0x03

Now, according to the section « Keyboard/Keypad Page » of the « HID Usage Tables for Universal Serial Bus (USB) version 1.21 » ( https://usb.org/sites/default/files/hut1_21_0.pdf ) :

  • Keycode 0x35 (and its SHIFTed version, 0xb5) is defined as « Keyboard Grave Accent and Tilde », which, on an US keyboard, is located up of the TAB key, and left of the ‘1/!’ key. Which is exactly where the @/# is located on an Apple (Belgian) French keyboard. However, in the LUT, this is mapped to the </> characters which is incorrect.
  • Keycode 0x03 is defined as « Keyboard ErrorUndefined ». I have no idea why this is used in the LUT and why this even works. To my understanding, we should instead use Keycode 0x64 (and its SHIFTed version, 0xE4), which is defined as « Keyboard Non-US \and | ». The footnote even specifies « Typical language mappings: Belg: <> French: <> »

So I think that, to fix the problem:

  • bytes 3 and 30, as well as bytes 28 and 32, should be swapped in the 53_FR_MAC_keyb_lut.img LUT file
  • the usage of Keycode 0x64 in place of Keycode 0x03 should be investigated (even if it works now)

However, I find it strange that I'm the first user of a (Belgian) French Apple keyboard to hit this bug. Do you have confirmation that everything is OK for French (non-Belgian) keyboard users in macOS ? Even if everything shows that an Apple French and an Apple Belgian French keyboard should be the same, I'm still not sure that this is not a specific bug related to the Belgian keyboard/keymap or weird macOS locale handling, and maybe a specific LUT FR_BE_MAC should be created.

Thank ! :-)

@limpkin
Copy link
Owner

limpkin commented Jan 25, 2021

Holy Molly, that's quite a debugging you've done! I am impressed.
It seems you indeed go to the bottom of the issue.
0x03 is actually remapped to 0x64 here: https://github.com/limpkin/mooltipass/blob/master/source_code/src/USB/usb.c#L1028 (see https://github.com/limpkin/mooltipass/blob/master/source_code/src/USB/hid_defines.h#L129)

IIRC, when testing layouts I extensively tested the french one (as I'm french...). So I'm not 100% sure of what's happening here.
@raoulh would you be able to confirm on your macOS?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants