linux-kernel - linux-input/hid; Assistance in remapping keys with no scancode in kernel module

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Date:	Thu, 12 Nov 2015 13:41:01 -0600
From:	Marty Plummer <netz.kernel@...il.com>
To:	linux-kernel@...r.kernel.org
Subject: linux-input/hid; Assistance in remapping keys with no scancode in
 kernel module

Greetings

Having recently purchased a Logitech G105 Gaming Keyboard(046d:c248) I've began
the process of reverse engineering the effects of the proprietery Logitech
Gaming Software (hereafter LGS) on the device to enable its full potential in
linux, using a number of tools (usbmon, hid-debug, virtual machines) to follow
the actions and logic used.

As of right now, I've discovered the following:
1. That the macro key remapping (either as standard keyboard keys or full macros)
   occurs in software and is not stored on the device itself (as opposed to
   other Logitech GSeries devices).

2. That keys G1-6 keys (hereafter GKeys) default to functioning as F1-6 until a
   certain set of packets are sent to it from LGS or otherwise, after which the
   F1-6 functionality ends.

3. Before the F# keys are disabled, the GKeys sends hid reports on interface 0
   identical to 'normal' F# keys and special reports on interface 1, with no
   scancode, of three bytes in size, on one hid usage, ff00.0003 (vendor defined)
   after the F# keys are disabled only the reports on interface 1 remain.

4. The M1-3 and MR keys (hereafter MKeys) send no reports on interface 0 at all,
   and reports on the same usage (ff00.0003) as the GKeys.

5. One can easily determine which GKeys and MKeys are being pressed via bitwise
   logic, as the three bytes follow a consistant pattern of:

   >03 gg mm
   where 03 is constant, gg is a value indicating the depressed GKeys (0x01 << n-1)
   AND'd together and mm is a value indicating the depressed MKeys (0x01 << n-1),
   also AND'd together, where MR is treated as M4.

6. Absolutely no standard scancode/keycode/etc is reported for these keys (as
   detectable by evtest, xev, showkeys, etc).

My current dilemma is how one is to transform this data into something usable,
as the fact they all report on the same usage there is no simple way I can find
to remap these keys.

If anyone has any insight on this matter, please assist.

Information on these reports and raw usbmon logs can be found at
https://github.com/GSeriesDev/gseries-tools/g105

	Regards,
		Marty Plummer

Download attachment "0xC030918D.asc" of type "application/pgp-keys" (3117 bytes)

Download attachment "signature.asc" of type "application/pgp-signature" (820 bytes)