Michal Wojciechowski
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...
