Project Logs

Collapse

• Firmware 0.7.5 — rendering on both ESP32-S3 cores

  Michal Wojciechowski • a day ago • 0 comments

  With the Jet interface in place, firmware 0.7.5 brings changes to how EvilKey draws it.

  The GUI and native 3D renderer now share rendering work between both ESP32-S3 cores. The GUI splits the image into horizontal bands, while native scenes distribute alternating rows between the cores.

  There are also several changes inside the rasterizer. It calculates the part of each row covered by a triangle, skips invisible geometry earlier, and reuses transformed cube vertices across faces. Frequently used data stays in internal memory, and color and depth are packed together to reduce separate PSRAM accesses. The graphics keep their existing appearance and detail.

  Diagnostics now has a Save report button. Instead of checking each screen separately, you can save all seven diagnostic cards to one text file on the SD card. The report includes memory usage, display buffers, rendering times, and activity on both cores. Files are saved in /evilkey/diagnostics/.

  Another addition concerns switching the SD card back from the computer to EvilKey. Using Eject on the computer now turns off Manager Drive. EvilKey saves the setting and briefly restarts, reconnecting without the USB storage drive so local apps can access the card again. You can turn Manager Drive back on when you need it.

  Existing ABI v4/v5 applications remain compatible. Manager stays at version 1.1.6.

• Firmware 0.7.4: 3D icons, fewer wasted cycles

  Michal Wojciechowski • 3 days ago • 0 comments

  After the EvilBundle detour, I went back to the firmware. The little FIDO2 key now has a native 3D interface, and making it run well on an ESP32-S3 took a fair bit of tuning.

  Jet draws the screensaver and the Apps/Settings icons. LVGL still handles text, controls and touch navigation. I kept the original icon shapes and mint-on-dark style, gave the icons more depth, and made Apps and Settings share the same orbit animation.

  Most of the work was under the hood: caching geometry, reducing repeated rasterizer work and fixing display buffering. The animations now feel noticeably quicker on the actual device, with no visible loss of quality in testing. The release uses Os optimization.

  ABI v5 also adds native 3D scene rendering for microSD apps. An .ekapp keeps its game or application logic and sends a bounded scene description to firmware, which handles the expensive drawing. This app renderer is separate from the Jet UI. Existing ABI v4 apps remain supported.

  Firmware 0.7.4 has been installed and tested on my Waveshare PCB V1.0 prototype. FIDO/PIN, touch navigation and the existing apps work correctly, and the update preserved protected storage.

  The public firmware repository now includes the accepted BIN, source package, checksums and updated ABI/SDK documentation. Manager remains at 1.1.6; its source labels and documentation have been aligned with the release.

  V1.1 hardware testing is still pending. The eFuse/HMAC and Secure Boot version is the next security stage; 0.7.4 remains development firmware.

  Firmware 0.7.4 and SDK · Manager · microSD examples

• EvilBundle: five useful tools, five excellent distractions

  Michal Wojciechowski • 4 days ago • 0 comments

  I originally needed a FIDO2 key. It now has a scientific calculator and plays pinball. Apparently, I cannot be trusted with spare flash storage.

  EvilBundle now contains ten apps, loaded from microSD as .ekapp packages.

  The useful half

  • EvilLevel — an IMU-based bubble level, angle and slope measurement, with zeroing, hold and saved readings.
  • EvilBench — electronics calculations: Ohm’s law, LED resistors, voltage dividers, RC filters, 555 timers and component markings.
  • EvilUnis — unit conversion, including editable expressions, favourites, history and custom units.
  • EvilCounter — multiple counters, adjustable steps, targets and timed sessions.
  • EvilCalculator — a scientific calculator with powers, roots, trigonometry, logarithms, combinatorics, memory and an expression editor.

  The “yes, this was necessary” half

  EvilBlocks, EvilPinball, EvilBreaker, EvilInvaders and EvilRacer. Because debugging firmware apparently wasn’t enough of a time sink.

  The screenshot sheet below shows actual .ekapp output captured in the firmware host renderer. It covers the current interfaces; it does not replace testing each app on the physical device.

  EvilBundle remains in a private repository for now. This is a progress update, not a public bundle release.

  I’m still open to interesting ideas for extending EvilKey. What would you actually use on a tiny touchscreen key that you already carry around? A practical tool, a game, or something I haven’t thought of yet?

• Firmware 0.6.1, a V1.1 board on order, and the next security chapter

  Michal Wojciechowski • 5 days ago • 0 comments

  EvilKey started because I needed a FIDO2 key. It now has games, a BLE gamepad and an air mouse. I’m attempting the unfamiliar discipline of finishing something before giving it another menu.

  Firmware 0.6.1 is available, with matching Apps/Settings ring animations and the existing ABI v4 app interface. The release image has been installed and checked on my Waveshare ESP32-S3-Touch-AMOLED-1.64 V1.0 prototype.

  I’ve ordered the V1.1 revision to extend compatibility. Once it arrives, I’ll check the display, touch, IMU, microSD and USB/FIDO behavior, along with the existing BLE roles. Until those checks are complete, V1.1 remains an upcoming test target.

  The development firmware is approaching feature finalization. The immediate focus is stability, compatibility and cleaning up the remaining rough edges.

  After that comes the next planned EvilKey version: eFuse/HMAC-backed protection for key storage and Secure Boot for signed firmware verification. Provisioning, migration of existing credentials and the update process will need their own implementation and hardware validation.

  The current release remains development firmware without those protections enabled. I’ll publish the implementation and test results as that work progresses.

  Interesting extension ideas are still welcome—especially practical experience with V1.1 hardware or ESP32-S3 provisioning.

  Firmware 0.6.1 and source

• Firmware 0.6.0: an app launcher, BLE Gamepad and an air mouse without the cable

  Michal Wojciechowski • 10/03/2026 at 15:03 • 0 comments

  I needed a FIDO2 key. It acquired a screen, then an air mouse, then games. Firmware 0.6.0 is the next consequence of leaving that compiler within reach: a proper app launcher and two deliberately activated BLE controls.

  The public release now contains the exact PCB V1 BIN tested on my device, its public source and checksums. The firmware and LVGL GUI are AGPLv3; the app SDK remains MIT.

  The app experiments now have a front door

  From Home, swipe your finger left for Apps, then left again for Settings. Swipe right from Home for the screensaver. Apps opens with an animated introduction matching Settings; up/down moves through pages of 3×3 icons with names. Tap an icon to run its package. Without compatible apps, navigation goes directly to Settings. Charger-only USB power still permits these screens.

  The catalog is cached instead of doing the whole card scan on each UI transition. Packages are independent .ekapp files in /evilkey/apps/ on FAT32 microSD. Copy a file to add an app, replace it to update, remove it to remove the app. Its bounded <id>.save sits beside it, so keeping that file keeps the saved state.

  Runtime remains ABI v4. The current package format is revision 5: every app carries a readable name and 64×64 RGB565 icon and follows the shared corner-exit-v1 UI profile. Older package revisions are rejected. The public specification, MIT SDK and UI profile describe the format, raw touch, motion samples, drawing/image data and saves.

  Sliders should slide, not close the app

  A whole-screen right swipe was too easy to confuse with an app control. The firmware now owns a small upper-left exit grip, with a visible progress strip. Start there, drag right and release after completion to open the shared Yes/No confirmation. Once captured, the gesture tolerates some downward movement and stays complete if the finger continues towards the edge. App time pauses during the gesture/dialog. Touch gestures starting elsewhere remain available to the app. SDK layouts reserve the 56×56 corner, so each app does not need to implement its own exit dialog.

  A gamepad, with a useful hardware lesson

  The landscape BLE Gamepad has an A/B/X/Y cross, shoulder controls, Start/Select and an IMU center action. Direction comes from tilting the key; a touch button can be used at the same time. Settings include analog/D-pad mode, dead zone, Rotate 180 and pairing controls. Its PC/Xbox and Generic/Android profiles are BLE HID; the profile name does not establish native XInput or game-console compatibility.

  An important correction to the earlier ABI-v4 write-up: the interface has room for two touch contacts, but this tested FT3168 panel reports one. Repeated hardware tests did not establish multitouch. The final controls therefore use IMU steering plus one touch button, without button combinations. App authors should also design for a single contact on this board.

  AirMouse: cable or BLE

  AirMouse now offers USB HID or BLE. Hold MOVE to steer the cursor and release to stop. Tap DRAG to hold/release the left mouse button; with drag latched, one finger can hold MOVE to drag. Left/right click and scrolling stay on the screen. Both modules use the same dark-and-mint visual language.

  The radio has an off switch in the lifecycle

  BLE starts only when a BLE module is launched. Choosing a BLE preference without launching it does not turn the radio on. Leaving the module returns to FIDO with BLE off; Home, Apps, Settings, screensaver and USB roles keep it off. Mouse and the two gamepad profiles have separate BLE identities and bond stores, and Forget Pairing is limited to the selected profile.

  The tested image, storage and limits

  The final image was flashed through EvilKey.cmd. Application readback passed and the before/after digests of protected storage matched. Device tests covered Gamepad appearance and controls, Center/settings feedback, both orientations, AirMouse, return to USB/FIDO with existing credentials, and games with save/resume. Windows measurements established...

  Read more »

• My FIDO2 key runs games now. I was left unsupervised.

  Michal Wojciechowski • 10/01/2026 at 07:25 • 0 comments

  I needed a FIDO2 key. A touchscreen seemed reasonable. An air mouse was already pushing it. Falling blocks and pinball? Apparently nobody confiscated my compiler in time.

  The new Apps Short shows EvilBlocks and EvilPinball running on my real Waveshare ESP32-S3 Touch AMOLED 1.64 PCB V1 prototype. Select an app from microSD, press RUN and play on the touchscreen. No desktop simulator standing in for the device. The clip is silent, with edited captions and the familiar 3D logo/glitch ending.

  The games are the excuse. Independent apps are the useful part.

  The previous log introduced Apps in firmware 0.4.0. Since then, firmware 0.5.0 has brought ABI v4. A compatible app is a separate .ekapp package copied to /evilkey/apps/ on a FAT microSD card. Open Settings → Apps in the normal FIDO USB role, choose the package and press RUN. Swipe right for the shared Yes/No exit dialog. Updating an app within the supported ABI means replacing its file, rather than rebuilding the security-key firmware.

  What changed after the first Apps release

  • Two simultaneous touch contacts, so an app can handle independent controls.
  • Accelerometer samples from the onboard motion sensor.
  • RGB565 image assets and cropped drawing for richer interfaces.
  • Per-app saves: a bounded <id>.save file beside the package on microSD, allowing an app to retain state between sessions.

  The Apps mailbox, Wasm3 allocations and bytecode copy use PSRAM, keeping more internal memory available for USB and card access. Save operations are handled by firmware after a guest step. Older ABI packages are rejected by 0.5.0; use packages built for ABI v4.

  A game does not get the keys to the key

  Firmware runs the bounded WebAssembly interpreter and checks the complete drawing output before displaying it. Apps receive the defined touch, motion, display and save interface; they do not get direct access to FIDO credentials, NVS, USB or networking. Package digests detect corruption, not authorship.

  The ABI v4 specification and MIT SDK are public. The AGPLv3 firmware contains the interpreter, without separately licensed game source or game packages. Apps and USB Tool .duck scripts are different formats with different jobs.

  What has actually been tested

  The exact public 0.5.0 image was flashed to the PCB V1 application partition and the write was verified without erasing NVS. After reboot, USB/FIDO, existing credentials, two independent ABI v4 apps and their save/continue flows were confirmed on hardware. That is a device smoke test; endurance, interrupted saves and sustained app load alongside CTAP still need qualification. The validation record and release contain the image hash and scope. The Short captures gameplay during development, not a benchmark of today's game builds.

  What would you make it do?

  I'm open to interesting ideas for extending EvilKey. A useful pocket utility, a strange visual experiment, another gloriously unnecessary app: tell me what it should do and how you'd use the touch display or motion sensor. I'd like to see what this hardware can become when someone else is left unsupervised too.

• Firmware 0.4.0: apps from microSD and a wider path for new ideas

  Michal Wojciechowski • 09/29/2026 at 23:35 • 0 comments

  A few days ago I asked what else you would build into EvilKey. Firmware 0.4.0 is a direct response to that question. Instead of putting every experiment into the security-key firmware, EvilKey can now load a separate app package from microSD. Within the current app interface, changing an app no longer requires rebuilding or reflashing the firmware. That makes the earlier community question much more practical.

  WHAT RUNNING AN APP LOOKS LIKE

  Copy a .ekapp file to /evilkey/apps/ on a FAT microSD card. In the normal FIDO USB role, open Settings → Apps, select it and press RUN. There is no install database or uninstall command: replacing or removing the file on the card does the job. Swipe right while an app runs and the firmware asks Yes/No before leaving it. Apps, Settings and the screensaver also remain available when USB power comes from a charger rather than a computer.

  THE BOUNDARY BETWEEN AN APP AND FIRMWARE

  An .ekapp contains a small WebAssembly module plus a header declaring its ID, version, owner, license, ABI and SHA-256 digest. The current package format is revision 2 and the public interface is ABI v3. The app has zero imports. Firmware calls app_init and app_step; each step receives elapsed time and raw touch coordinates. The app defines its own controls and returns a list of drawing commands in its memory. Firmware checks the complete command list before displaying it and enforces memory, drawing and execution limits.

  The current ABI deliberately exposes display and touch only. It does not give an app filesystem, USB, network, NVS, FIDO credential or native pointer access. The package digest detects corruption; it does not prove who wrote the app. Each app can carry its own rights owner and license. The ABI v3 specification (https://github.com/mwr666/EvilKey-firmware/blob/v0.4.0/apps/ABI_V3.md) and minimal MIT SDK declarations (https://github.com/mwr666/EvilKey-firmware/tree/v0.4.0/apps/sdk) are public. The AGPLv3 firmware repository contains the interpreter, but does not bundle any separate application source or package.

  WHAT THIS OPENS UP, AND WHAT IT DOES NOT

  Games, visual tools and interactive utilities using the existing screen and touch interface can be developed and copied to the card independently of firmware releases. This greatly widens the palette of experiments I can try after hearing your ideas. Requests that need the IMU, USB behavior, persistent app storage or another new device capability would first need a considered ABI and firmware change. I want that boundary to stay explicit, especially on a device that also holds FIDO credentials.

  Preview: EvilBlocks running on EvilKey hardware during testing. This separate app is not included in the public firmware v0.4.0 release. 

  RELEASE AND HARDWARE CHECK

  The public v0.4.0 release (https://github.com/mwr666/EvilKey-firmware/releases/tag/v0.4.0) includes the corresponding source and a PCB V1 application-partition BIN. I flashed the public-source image to my Waveshare ESP32-S3 Touch AMOLED 1.64 PCB V1 at the app partition, verified the write, ran a test app and confirmed that my existing FIDO credentials remained available. The write did not erase the NVS partitions. This is a hardware smoke test; long-duration app use and simultaneous CTAP traffic still need separate qualification. The exact image hash and test scope are in firmware validation (https://github.com/mwr666/EvilKey-firmware/blob/v0.4.0/firmware/VALIDATION.md).

  What would you build first? A screen-and-touch idea can target ABI v3 now. For an idea that needs other hardware, tell me the user behavior, why that access is needed and how you would test it. That feedback will help decide which capabilities belong in a future ABI rather than hard-coding one more feature into the key.

• Would you build an EvilKey DIY kit?

  Michal Wojciechowski • 09/26/2026 at 12:31 • 0 comments

  I am considering a complete DIY EvilKey kit based on the tested Waveshare ESP32-S3 Touch AMOLED 1.64 PCB V1, including a physical printed enclosure and a guide to assembly, flashing and testing. I am also considering a separately sold printable enclosure file for people who already own the board or prefer to print their own case.

  Before defining the kit or accepting any orders, I would like to understand what would make it useful and realistic for builders. Please leave a comment with any of the following answers:

  1. Would you be interested in building it? Yes / Maybe / No.
  2. Do you already own the Waveshare PCB V1? Yes / No / Unsure.
  3. Which option fits you: complete kit with a physical case / electronics-only kit plus a printable case file / printable case file only?
  4. What would you need in the box or in the instructions to assemble it confidently?
  5. Which country would it need to ship to, and what total kit price before shipping would you consider reasonable?
  6. Which feature matters most to you: FIDO2, on-device PIN entry, the touch UI, Air Mouse, USB Tool, or the ability to modify the firmware?

  You can answer just the questions relevant to you. A brief comment such as Yes; no board; kit without case + printable file; Germany; FIDO2 + Air Mouse is useful. Please do not post email addresses, shipping addresses or authentication data in the comments.

  This is an interest check, not a preorder, reservation or promise of a sale. The exact contents, price, supported board revisions, fulfillment countries and launch date remain undecided. Any future listing will link back to the source and assembly instructions at https://github.com/mwr666/EvilKey-firmware.

• One display, three USB roles: how EvilKey keeps the controls responsive

  Michal Wojciechowski • 09/26/2026 at 12:29 • 0 comments

  The EvilKey prototype uses Waveshare's ESP32-S3 Touch AMOLED 1.64 PCB V1. Its compact board already combines a 280 × 456 touch AMOLED, native USB, a QMI8658C motion sensor and a microSD slot. That made it possible to build an interactive key without adding a separate motion sensor or external display controller. Waveshare also sells a V2 revision with different pin assignments, so the current firmware target is explicitly V1.

  The user interface was designed around short, readable screens and touch regions large enough to operate while holding the device. For display performance, the firmware tries to allocate two 64-row RGB565 draw buffers in DMA-capable internal memory and places the LVGL object pool in PSRAM. The Diagnostics page reports the buffer arrangement that actually started, instead of assuming the preferred configuration was available.

  The FIDO2 PIN screen is a functional part of that interface. For built-in user-verification requests, EvilKey accepts a configured numeric FIDO PIN on its own 3 × 4 touch keypad. Digits are masked; the screen shows retry count and timeout, while Backspace, Verify and Cancel remain large touch targets. The local check uses the existing PIN verifier and retry budget. Standard ClientPIN is still advertised because host-side setup and clients that do not use built-in UV need it. This avoids claiming that every login is host-PIN-free. The PIN flow notes explain the protocol scope. The interface preview is code-derived; a filmed demonstration of the final on-device PIN flow is still pending.

  Air Mouse is an example of a mode that needs both hardware and interface design. On entry, it samples the QMI8658C to establish a neutral orientation. Tilt becomes a relative HID pointer with a shared radial dead zone, smoothing and fractional movement accumulation, so diagonal motion does not have to choose between horizontal and vertical movement. A large MOVE touch region acts as a hold-to-move clutch. The other touch regions remain available for click and scroll; on-device settings provide recalibration, sensitivity and vertical inversion.

  USB roles are intentionally distinct. The Air Mouse role enumerates as a relative mouse; the USB Tool role is selected separately; FIDO is the normal role. USB Tool scripts require local selection and a press of RUN. This keeps the behavior inspectable and prevents a script from running merely because the device was connected.

  The three USB roles are selected separately. The diagram describes intended enumeration, not three modes active at once.

  The current firmware passed a physical smoke test of Air Mouse controls and return to FIDO. Long-running drift, repeated reconnection and complete product qualification are still separate work. The repository records the exact scope of the tests and documents the source and firmware build: https://github.com/mwr666/EvilKey-firmware

  Next I am gathering feedback on a possible DIY kit. The following project log asks what makers would actually want included, and whether they would print the enclosure themselves.

View all 9 project logs