Presentation Material
Abstract
This talk revolves around a recent hobby open source project I undertook to reverse engineer a Windows HP Laptop RGB Keyboard driver and re-implement the same functionality on Linux by writing a kernel driver. Initially, I thought this would be straightforward, but I was proven wrong fast! Due to the lack of any unified interface for keyboard backlights, laptop manufacturers create their own proprietary firmware to interface these devices using obscure Windows APIs. The first phase of my talk explains how I reverse-engineered these APIs to understand how they work and what I learned in the process. A lot of the standards used here are not only applicable to Keyboard LEDs but all manufacturer-specific functionality in general. In this section of the talk, I aim to explain different reverse engineering techniques for dotnet / Windows native applications. The second phase of my talk describes about how I started contributing to the Linux kernel and submitted my first patch to the mainline 6.x Linux Kernel. It also talks about my ongoing work on Linux HP WMI drivers, where I am working with Kernel Maintainers to introduce new standards to hopefully unify RGB keyboard drivers on Linux: something which Windows was unable to do!
AI Generated Summary
The talk details a project to reverse-engineer and reimplement the proprietary keyboard backlight control system for an HP Omen laptop, originally designed for Windows, as a functional Linux kernel driver.
The researcher began by decompiling the closed-source Windows “Omen Light Studio” application and its associated “Light Studio Helper” service using ILSpy. Analysis revealed the service relied on a single Execute function that accepted integer operation codes and data, interacting with a Windows Management Instrumentation (WMI) provider. Further investigation identified the specific WMI class (HP_QBInm) and its GUID, which mapped to an ACPI method (_Q14) within the laptop’s firmware.
The core of the research involved understanding the interaction between two system protocols: ACPI (Advanced Configuration and Power Interface), which defines hardware interfaces via AML bytecode stored in system firmware, and WMI, a Windows-specific API framework that routes user-space requests to underlying system methods. The manufacturer had implemented a custom ACPI device (PNP0C14) containing byte arrays that bind specific WMI methods to ACPI functions, enabling user-space control of the backlight.
To reimplement the functionality on Linux, the researcher leveraged the kernel’s acpi_doh (ACPI Device Operation Region Handler) interface. This allowed direct invocation of the same ACPI methods identified from the Windows implementation. A custom kernel module was created, exposing control interfaces via the standard sysfs class leds (/sys/class/leds/hpomen-keyboard-backlight/). Two primary files were implemented: brightness for overall intensity and zone for per-zone pattern control, accepting raw byte data for the four keyboard zones.
A key practical finding was that the original Windows application only supported binary on/off brightness states. By exploiting the ACPI method’s acceptance of full RGB byte values, the researcher implemented smooth brightness scaling in the Linux driver. This was achieved by reading the current zone state, scaling its RGB values by a brightness factor, and writing the modified state back, enabling variable intensity not possible in the stock Windows tool.
The project demonstrates a method for reverse-engineering proprietary hardware control on modern laptops by tracing from user-space applications through WMI to underlying ACPI methods, and provides a template for creating open-source, feature-enhanced Linux drivers for similar peripherals.