A perfectly reasonable problem, followed by a perfectly unreasonable response
My OpenAI account asked me for FIDO2 authentication while I was working with an active Daybreak Blue model. I needed a security key. The sensible plan was to buy a YubiKey, log in and get on with my life. Naturally, that is not what happened.
I found the open-source Pico FIDO project and ordered a Waveshare ESP32-S3 Touch AMOLED 1.64 board. Then came the maker's classic facepalm: I had overlooked that the community version did not give me everything I had pictured. The sensible response was still to use it as a FIDO2 key. Instead, a very old XDA Developers reflex woke up.
As a teenager I loved getting my hands dirty with firmware for early HTC phones, Windows Mobile and the first generations of Android. Back then, phones felt full of places where a curious community could improve things before manufacturers caught up. I remember how much fun it was to make an existing device do something its original menu had never imagined. That memory made me smile, then made me open the source tree. Apparently the older version of me still enjoys making hardware do extra things. Some useful. Some gloriously unnecessary.
EvilKey is the result: a FIDO2 key that acquired a dark AMOLED touch interface, on-device PIN entry, a script-driven USB tool and, because apparently a key should also steer a cursor, an air mouse. The Waveshare PCB is not my hardware design. The EvilKey firmware port, LVGL interface, Windows Manager, original microSD examples and enclosure work are my additions, with the upstream licenses and notices kept visible.
How the feature creep happened
- Make the key usable every day. Keep the FIDO2 role and build an interface that is readable on a 280 × 456 touch AMOLED, with large controls and a restrained dark palette.
- Put the PIN on the key. The touch screen provides a numeric keypad for FIDO2 built-in user verification: masked entry, a visible retry count and timeout, Backspace, Verify and Cancel. On compatible FIDO2 requests, I enter the PIN on EvilKey instead of typing it into the connected computer. The familiar host-side ClientPIN path remains available for setup and compatibility.
- Give it a face. The mint symbol and white crystal became a shared 3D screensaver. Both parts move in the same projected plane; the crystal turns around its vertical axis. The logo stays recognizable even when the animation briefly glitches.
- Win back display speed. Tune RGB565 rendering around two 64-row DMA-capable draw buffers when memory permits, with the LVGL object pool in PSRAM. Diagnostics reports the buffer layout actually allocated. On the tested device it showed
2 x 64 RGB565. - Put the computer-side controls somewhere sane. The separately licensed EvilKey Manager handles device information, PIN and policy controls, credentials, display settings and offline inspection of USB Tool data.
- Give the security key an evil twin. USB Tool is a deliberately selected USB role with HID keyboard and mouse capabilities and optional microSD storage. The supported DuckyScript-style workflow lets a script drive host interactions: probe controls, test whether a defense can be bypassed, gather data accessible to that host session, and record results for later inspection in the Manager. That is the hacker's playground I wanted, with the interesting uses limited mainly by the supported commands, the host's permissions and the imagination of whoever writes the script. The name is not a promise of magical access: a defended machine can still say no. More importantly, a payload runs only after it is selected on the key and RUN is pressed. Merely plugging in EvilKey does not launch one. My teenage XDA self would, of course, have opened this menu first.
- Then add a mouse. The onboard QMI8658C turns tilt into relative USB HID pointer movement. The touchscreen provides left and right click and scrolling. Holding MOVE enables motion, releasing it pauses the pointer, and the settings screen offers calibration, five sensitivity levels and vertical-axis inversion. Diagonal motion was a real development battle, not a checkbox.
The roles are separate: normal FIDO2, USB Tool and mouse-only Air Mouse do not all enumerate at once. That separation is part of how the device remains understandable and controllable.
The PIN keypad is more than decoration
Many USB security keys rely on the computer to collect a FIDO2 ClientPIN. EvilKey can instead verify a configured numeric FIDO PIN on its own touch screen when the client uses built-in user verification. The PIN is checked by the authenticator; this route does not require typing it on the host keyboard. The key shows only masked dots, the remaining attempts and a countdown while you enter it. A wrong entry consumes a retry, and a successful check authorizes the requested FIDO operation rather than granting a permanent unlock.
This is a distinctive part of the EvilKey design, not a claim that every browser or operating system will choose it. EvilKey advertises both built-in UV and standard ClientPIN, so some clients may still ask for a PIN on the computer. The on-device route also requires a compatible client and a configured numeric PIN. The technical notes explain the two paths and their limits; the FIDO CTAP specification defines built-in UV and ClientPIN separately.
What the object in the photos actually is
The working enclosure shown in the real photographs is a home-printed prototype around a Waveshare PCB V1 board. I plan to commission a professional black SLS 3D print for the finished enclosure. The single polished product image here is a visualization of that planned finish, not evidence that an SLS production run has happened. I have a STEP design, but its fit and final assembly instructions still need a controlled validation pass. The short looped USB-C cable is the Unitek C14179ABK style shown in the prototype photos; any future kit contents will be specified only after sourcing and fit checks.
Waveshare's V1 and V2 board revisions have different pin assignments. The current EvilKey firmware and case work target V1; do not assume V2 compatibility.
Current status and source
Firmware 0.3.0 has a physical smoke test covering Air Mouse controls, diagonal steering and return to FIDO. Earlier device testing confirmed the display buffer readout and FIDO login. A dedicated physical demonstration of the on-device PIN flow on the final image is still pending. The frozen Windows Manager 1.1.6 passed its application self-test without connecting to USB. Long-duration reliability and every USB Tool/Manager operation have not been qualified as a finished commercial product. The source repository records that boundary.
Device firmware and LVGL GUI are AGPLv3 with upstream notices. The Manager and original microSD examples are separately published as source available for private noncommercial use under their respective licenses. EvilKey is an independent project, not affiliated with Waveshare, Pico FIDO, YubiKey or OpenAI; no FIDO certification is claimed.
Firmware source and build notes: https://github.com/mwr666/EvilKey-firmware
See EvilKey in motion
Watch the real prototype, silent camera footage: the home-printed device moves through the screensaver and Settings and returns to READY. Watch the code-derived interface preview: a visualization of the firmware screens, including an illustrative masked PIN sequence. The second film is not camera footage or a live authentication capture.

The animated logo is derived from the LVGL screensaver frames, including its brief glitch phase.
The interface on the key

On-device PIN entry is a distinctive EvilKey feature. This screen image was generated from the firmware layout; the masked digits are illustrative, not a live PIN.
Explore the other code-derived screens: READY, Diagnostics, USB Tool, and Air Mouse. The USB role diagram shows why FIDO, USB Tool and Air Mouse are selected separately.
Planned enclosure finish

Concept visualization of the planned black SLS finish. The real working enclosure in the photographs is currently home printed; the SLS case has not yet been commissioned or validated.
Bring me the weird ideas
I am open to interesting ideas for extending EvilKey. If you can imagine a useful, odd or elegantly ridiculous feature that fits this hardware, tell me in the Hackaday comments or open a proposal in the public firmware repository. Feasible ideas can shape the next release. I would especially like to hear from people who would build a DIY kit and from people who can spot a better use for the AMOLED, touch panel, IMU or microSD slot.
There is no kit preorder here yet. The linked project log asks what a complete DIY kit should contain and what builders would actually want to do with it.
Michal Wojciechowski