Open ReversingCat opened 3 years ago
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?
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
# > < @
fr_MAC
in the Moolticute application# > < @
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 :
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 ASCII0x23
, so it’s byte 3 in the LUT, and its value is0x83
, i.e. the keycode0x03
with a SHIFT modifier<
is ASCII0x3C
, so it’s byte 28 in the LUT, and its value is0x35
>
is ASCII0x3E
, so it’s byte 30 in the LUT, and its value is0xb5
, i.e. the keycode0x35
above with a SHIFT modifier@
is ASCII0x40
, so it’s byte 32 in the LUT, and its value is0x03
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 ) :
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.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 Keycode0x64
(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:
53_FR_MAC_keyb_lut.img
LUT file0x64
in place of Keycode0x03
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 ! :-)