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.