ft9201-libfprint

Linux fingerprint support for the Focal-systems FT9201 USB reader (2808:93a9, sold as a standalone Windows Hello dongle), as a libfprint driver.

The sensor is a tiny 96×96 optical reader. libfprint's built-in matcher does a poor job on an image that small, so this driver instead reuses FocalTech's own matching engine — the ftWbioEngineAdapter.dll from their signed Windows driver — running it natively on Linux with a small in-process PE loader. No Wine, no Windows, no cloud.

This repo is also a reusable method, not just one driver. The technique — running a vendor's Windows matching engine natively on Linux, no Wine — generalizes to other "Windows Hello only" readers, including ones that ship an SDCP secure channel (the Synaptics/Goodix/ELAN/EgisTec-class crypto sensors), via the optional src/crypto_shims.c module. The FT9201 is the worked example; the in-process loader, the WinBio bridge, and the crypto-bypass layer carry over to the next device. See PORTING.md for the step-by-step method and what to reuse as-is.

Status

Working end-to-end on real hardware: enroll and verify through fprintd / command-line tools, and in KDE/GNOME once installed. It matches your finger using the vendor's real algorithm.

Developed and tested against this exact reader (ASIN B0DK7LQZGH) — the FT9348W variant of 2808:93a9.

Caveats:

• Tested only on that FT9348W variant of the 2808:93a9 device.
• The matcher is a proprietary blob we call into; we can't fix bugs inside it.
• x86-64 only (the DLL and loader are 64-bit).

How it works (short version)

• The USB init + firmware-boot sequence was reverse-engineered from FocalTech's own drivers; the 8051 MCU firmware is uploaded, then a specific register-config sequence starts it.
• Each capture (96×96) is center-cropped to the 64×80 the engine expects.
• ft_engine.c is a ~450-line loader that maps ftWbioEngineAdapter.dll into memory, provides the ~90 kernel32 functions it imports, sets up a fake Windows TEB, and calls the engine's WinBio interface for enroll/verify.
• The loader maps code read-execute and data read-write from an in-memory file, so no page is ever writable and executable. That means it