Tools

Tools: How I got my HP fingerprint sensor working on Linux.

2026-05-20 0 views admin
Tools: How I got my HP fingerprint sensor working on Linux.

The expectation: just install a driver

Step one: figure out what you actually have

The first dead end: the libfprint vfs7552 driver

The pivot: python-validity

The painful middle: I thought I was stuck

Looking at the actual data

The actual bug

What was actually hard about this

What's in the patch

Takeaways I bought a used HP EliteBook 840 G5 last year. Cleaned it up, wiped Windows, put Ubuntu on it. Everything worked except the fingerprint reader, which I figured I'd get to "eventually." "Eventually" turned out to mean three sessions, several wrong turns, a USB reverse engineering side quest, and a one-line fix that fixes the same problem for a chunk of HP laptops nobody had been able to use on Linux. This is the thing non-Linux people (and a lot of Linux people, honestly) get wrong about hardware support. You don't "just install a driver." Either: My sensor was case 4. Specifically: 138a:00ab, a Synaptics VFS7552 chip with their "PurePrint" anti-spoofing variant. Synaptics only ships a Windows driver. libfprint (the standard Linux fingerprint library) has no driver for this PID. python-validity (the heroic community reverse-engineering project) supports the related Lenovo Prometheus chips but not mine. Of 649 systems with this exact device logged on linux-hardware.org, zero worked on Linux. There were three open GitHub issues asking for support, the oldest from 2023. So that was the starting point. Searching 138a:00ab led to linux-hardware.org's page, which confirmed the model ("Validity Sensors Synaptics VFS7552 Touch Fingerprint Sensor with PurePrint") and the bleak status: 649 reports, all failing. The PurePrint suffix sounded ominous. Looking at the USB endpoint structure (5 endpoints: one bulk OUT, two bulk IN, two interrupt IN), I figured PurePrint probably added an encrypted channel on top of the plain VFS7552 protocol. Spoiler: I was half right. libfprint ships a driver called vfs7552 for the Dell XPS variant of this chip (PID 0091). I cloned the repo, added 0x00ab to its PID table, rebuilt, and tried it: The chip accepted the basic identification commands and returned valid-looking data. It just refused the 501-byte initialization blob that the Dell driver wanted to send. Diffing the cmd_01 response against the Dell reference values, my chip and the Dell one agreed on the first 18 bytes (sensor family identifier) but differed in a few bytes that looked like firmware version (0x03d1 vs 0x0000) and a per-chip serial number. The init blob is firmware-version-specific. Sending the Dell's blob to my chip is like sending Windows XP install media to a Mac. I tried disassembling the HP Windows driver (synaWudfBioUsb.dll, extracted from the official HP softpaq) in radare2 to find the right bytes to send. I got far enough to confirm the driver does ECDH key exchange and signed firmware upload — BCryptGenerateKeyPair, BCryptSecretAgreement, BCryptSignHash all in the imports — but the actual byte sequences turned out to be dynamic, not static. They're constructed from runtime crypto, not stored as constants you can grep for. The libfprint path was over. The chip wasn't really a vfs7552; it was something more sophisticated wearing a vfs7552 marketing label. python-validity is uunicorn's reverse-engineered userspace driver for the chips Synaptics calls "Prometheus" — 138a:0090, 0097, 009d, 06cb:009a. These chips do real TLS-like crypto handshakes and signed firmware upload, which matched what I'd seen in the disassembly. The architecture made me hopeful: maybe 0x00ab was just a Prometheus chip wearing a vfs7552 marketing label. The protocol bits I'd already verified (cmd_01, cmd_19) are also what python-validity's usb.send_init() sends first. I wrote a minimal test script that: 0000. Status OK. The HP chip accepted python-validity's blob, which meant: same protocol family. Verified by going further and completing the full ECDH key exchange — the encrypted channel established cleanly against the chip's factory TLS state. I patched python-validity to support 00ab. The service started. fprintd-enroll ran, asked for finger swipes, completed. fprintd-verify... hung forever. I figured the problem was that python-validity's sensor.open() only knows two sensor type profiles (0x199 and 0xdb), and my chip reports 0xd51. With the wrong profile, image dimensions and calibration parameters would be wrong, producing garbage images. I spent hours on this hypothesis. Tried both profiles. Looked for ways to extract the right values from Windows. Read the open issues. Issue #225 — same 0xd51 sensor type on a different USB ID — was a user who had hit the exact same wall with the exact same patches I'd applied. They got stuck at the same place. The narrative I had in my head was: this is the calibration wall. Without per-chip data extracted from Windows, we're done. I started writing the apologetic "we did good work but here's where it ends" wrap-up. But before giving up I added one more piece of instrumentation: dump every TLS-decrypted response over 100 bytes to disk. Re-enrolled. Looked at what came out: The enrollment template was growing by ~4500 bytes per scan. That's real feature data accumulating. If the chip were producing garbage images, the matcher wouldn't have anything to extract features from — the template wouldn't grow. I rendered the cmd02 frames as 44×44 grayscale PNGs. They didn't look like noise. They looked like fingerprint ridges. The chip was capturing real images. The matcher was building real templates. So why did verify hang? I went back and stared at sensor.capture(): Three interrupt phases: start, finger-detected, capture-complete. I went back to the journal logs and looked at what interrupts my chip was actually sending: That's it. Two interrupts. The chip never sent b[0] = 2 "finger detected." It skipped straight from start to capture event. So the wait-for-finger loop sat there forever, waiting for an interrupt that was never coming. The chip had captured the image, the matcher had a result, but the daemon couldn't tell because of an infinite loop in user code. Eight lines, gated on the chip type so existing supported chips take the unchanged code path. Restart the service. Re-enroll. fprintd-verify: A correct finger matched. Tried with a different finger: Real matching, real rejection. Wired it through PAM: The thing that fooled me, and fooled everyone else who had tried was that the chip appeared to be calibration-stuck. Enrollment completed (because enrollment uses a slightly different code path that doesn't wait for b[0]=2). Verify hung. The natural conclusion was "matching fails, images are bad." Everyone tried fiddling with the sensor profile. Nobody tried instrumenting the interrupt stream. Looking at the actual returned data was the move. The cmd6b templates growing by 4500 bytes per scan was the smoking gun: the chip was clearly producing real features, which meant the chip was capturing real images, which meant the image pipeline was working, which meant the problem had to be after image capture and before match results came back. That's a small window and the wait-finger loop was sitting in it. The PR is at uunicorn/python-validity#256. +37 / -3 lines across five files. It: If it merges, three open issues get closed: If you have one of these chips and don't want to wait for the merge, you can clone my fork branch: (You'll also need open-fprintd and the supporting D-Bus / systemd / udev plumbing, which the PR description and python-validity's debian/ folder document.) If you've got a Validity/Synaptics fingerprint reader that doesn't work on Linux, check the USB ID and the open python-validity issues before assuming it's hopeless. There's a lot of "almost working" out there. I didn't do this alone. All three sessions of this — the libfprint dead end, the python-validity pivot, the calibration rabbit hole, and finally the interrupt-loop fix — happened in Claude Code, with Claude Opus as a pair. The model held protocol details I didn't have, ran disassemblers and greps and test scripts in parallel while I was deciding what to do next, and kept track of every hypothesis we'd already ruled out. The interrupt-handling insight came out of "wait, the template is growing — that contradicts the bad-images story; what else could it be?" which is a kind of careful re-examination that's much easier when you've got a partner doing the bookkeeping. The hardware was mine. The patience for re-enrolling a finger thirty times was mine. The decisions about when to give up and when to push were mine. But the protocol memory and the second pair of eyes were Claude's, and I want to call that out because "I built X" stories tend to hide the assist. Templates let you quickly answer FAQs or store snippets for re-use. Hide child comments as well For further actions, you may consider blocking this person and/or reporting abuse

Command

Copy

$ lsusb | grep -i validity Bus 001 Device 019: ID 138a:00ab Validity Sensors, Inc. $ lsusb | grep -i validity Bus 001 Device 019: ID 138a:00ab Validity Sensors, Inc. $ lsusb | grep -i validity Bus 001 Device 019: ID 138a:00ab Validity Sensors, Inc. cmd_01 (rom info) ............. OK, 38 bytes returned cmd_19 ........................ OK, 68 bytes vfs7552_init_00 (501 bytes) ... rejected, -weight: 500;">status 0x04be cmd_01 (rom info) ............. OK, 38 bytes returned cmd_19 ........................ OK, 68 bytes vfs7552_init_00 (501 bytes) ... rejected, -weight: 500;">status 0x04be cmd_01 (rom info) ............. OK, 38 bytes returned cmd_19 ........................ OK, 68 bytes vfs7552_init_00 (501 bytes) ... rejected, -weight: 500;">status 0x04be init_hardcoded (581 bytes): send 06 02 00 00 01 4a 23 14 06 e5 54 2f c6 dc 3b 1a ... recv 2 bytes, -weight: 500;">status=00 00: 00 00 init_hardcoded (581 bytes): send 06 02 00 00 01 4a 23 14 06 e5 54 2f c6 dc 3b 1a ... recv 2 bytes, -weight: 500;">status=00 00: 00 00 init_hardcoded (581 bytes): send 06 02 00 00 01 4a 23 14 06 e5 54 2f c6 dc 3b 1a ... recv 2 bytes, -weight: 500;">status=00 00: 00 00 $ fprintd-verify Using device /net/reactivated/Fprint/Device/0 Listing enrolled fingers: - #0: right-index-finger Verify started! Verifying: any ^C # me, after a minute of nothing $ fprintd-verify Using device /net/reactivated/Fprint/Device/0 Listing enrolled fingers: - #0: right-index-finger Verify started! Verifying: any ^C # me, after a minute of nothing $ fprintd-verify Using device /net/reactivated/Fprint/Device/0 Listing enrolled fingers: - #0: right-index-finger Verify started! Verifying: any ^C # me, after a minute of nothing 4104 B cmd40 (× 4) calibration frames 1966 B cmd02 (× 9) per-stage frame data 5040, 9584, 14128, 14128, 18672, 18672, 18672, 23304 B cmd6b enrollment template 4104 B cmd40 (× 4) calibration frames 1966 B cmd02 (× 9) per-stage frame data 5040, 9584, 14128, 14128, 18672, 18672, 18672, 23304 B cmd6b enrollment template 4104 B cmd40 (× 4) calibration frames 1966 B cmd02 (× 9) per-stage frame data 5040, 9584, 14128, 14128, 18672, 18672, 18672, 23304 B cmd6b enrollment template def capture(self, mode): assert_status(tls.app(self.build_cmd_02(mode))) # -weight: 500;">start b = usb.wait_int() if b[0] != 0: raise Exception('wait_start: Unexpected interrupt type ...') # wait for finger while True: b = usb.wait_int() if b[0] == 2: break # wait capture complete while True: b = usb.wait_int() if b[0] != 3: raise Exception('Unexpected interrupt type ...') if b[2] & 4: break ... def capture(self, mode): assert_status(tls.app(self.build_cmd_02(mode))) # -weight: 500;">start b = usb.wait_int() if b[0] != 0: raise Exception('wait_start: Unexpected interrupt type ...') # wait for finger while True: b = usb.wait_int() if b[0] == 2: break # wait capture complete while True: b = usb.wait_int() if b[0] != 3: raise Exception('Unexpected interrupt type ...') if b[2] & 4: break ... def capture(self, mode): assert_status(tls.app(self.build_cmd_02(mode))) # -weight: 500;">start b = usb.wait_int() if b[0] != 0: raise Exception('wait_start: Unexpected interrupt type ...') # wait for finger while True: b = usb.wait_int() if b[0] == 2: break # wait capture complete while True: b = usb.wait_int() if b[0] != 3: raise Exception('Unexpected interrupt type ...') if b[2] & 4: break ... <int< 00 00 00 00 00 # b[0] = 0 (-weight: 500;">start) <int< 03 20 07 00 00 # b[0] = 3 (capture event) <int< 00 00 00 00 00 # b[0] = 0 (-weight: 500;">start) <int< 03 20 07 00 00 # b[0] = 3 (capture event) <int< 00 00 00 00 00 # b[0] = 0 (-weight: 500;">start) <int< 03 20 07 00 00 # b[0] = 3 (capture event) # wait for finger. Sensor type 0xd51 (138a:00ab, 06cb:00b7) does not # emit b[0]=2; it jumps directly to capture events. Accept b[0]=3 as # a substitute and save the interrupt for the next loop. saved_b = None while True: b = usb.wait_int() if b[0] == 2: break if b[0] == 3 and getattr(self, 'real_device_type', None) == 0xd51: saved_b = b break # wait capture complete while True: b = saved_b if saved_b is not None else usb.wait_int() saved_b = None ... # wait for finger. Sensor type 0xd51 (138a:00ab, 06cb:00b7) does not # emit b[0]=2; it jumps directly to capture events. Accept b[0]=3 as # a substitute and save the interrupt for the next loop. saved_b = None while True: b = usb.wait_int() if b[0] == 2: break if b[0] == 3 and getattr(self, 'real_device_type', None) == 0xd51: saved_b = b break # wait capture complete while True: b = saved_b if saved_b is not None else usb.wait_int() saved_b = None ... # wait for finger. Sensor type 0xd51 (138a:00ab, 06cb:00b7) does not # emit b[0]=2; it jumps directly to capture events. Accept b[0]=3 as # a substitute and save the interrupt for the next loop. saved_b = None while True: b = usb.wait_int() if b[0] == 2: break if b[0] == 3 and getattr(self, 'real_device_type', None) == 0xd51: saved_b = b break # wait capture complete while True: b = saved_b if saved_b is not None else usb.wait_int() saved_b = None ... Verify result: verify-retry-scan (not done) Verify result: verify-retry-scan (not done) Verify result: verify-match (done) Verify result: verify-retry-scan (not done) Verify result: verify-retry-scan (not done) Verify result: verify-match (done) Verify result: verify-retry-scan (not done) Verify result: verify-retry-scan (not done) Verify result: verify-match (done) Verify result: verify-no-match (done) Verify result: verify-no-match (done) Verify result: verify-no-match (done) $ -weight: 600;">sudo -k && -weight: 600;">sudo whoami [-weight: 600;">sudo] Place your finger on the fingerprint reader root $ -weight: 600;">sudo -k && -weight: 600;">sudo whoami [-weight: 600;">sudo] Place your finger on the fingerprint reader root $ -weight: 600;">sudo -k && -weight: 600;">sudo whoami [-weight: 600;">sudo] Place your finger on the fingerprint reader root -weight: 500;">git clone -b feat/sensor-type-0xd51 https://github.com/SimpleX-T/python-validity.-weight: 500;">git -weight: 600;">sudo -weight: 500;">pip -weight: 500;">install --break-system-packages --prefix=/usr ./python-validity -weight: 600;">sudo -weight: 500;">systemctl -weight: 500;">restart python3-validity.-weight: 500;">service -weight: 500;">git clone -b feat/sensor-type-0xd51 https://github.com/SimpleX-T/python-validity.-weight: 500;">git -weight: 600;">sudo -weight: 500;">pip -weight: 500;">install --break-system-packages --prefix=/usr ./python-validity -weight: 600;">sudo -weight: 500;">systemctl -weight: 500;">restart python3-validity.-weight: 500;">service -weight: 500;">git clone -b feat/sensor-type-0xd51 https://github.com/SimpleX-T/python-validity.-weight: 500;">git -weight: 600;">sudo -weight: 500;">pip -weight: 500;">install --break-system-packages --prefix=/usr ./python-validity -weight: 600;">sudo -weight: 500;">systemctl -weight: 500;">restart python3-validity.-weight: 500;">service - The kernel already supports it (out of the box) - Someone reverse-engineered the protocol and shipped a userspace driver - The vendor ships a Linux driver (rare outside of mainstream chipsets) - It doesn't work - Opened the device - Sent cmd_01, cmd_19, cmd_4302 (basic info queries) — all worked - Sent python-validity's init_hardcoded blob (a 581-byte crypto blob for the supported chips) - Wires 138a:00ab and 06cb:00b7 through the SupportedDevices enum, blob routing, firmware mapping, and udev rules - Aliases sensor type 0xd51 to the 0x199 profile so downstream SensorTypeInfo / SensorCaptureProg lookups succeed (no native profile exists yet — empirically 0x199 is close enough that the on-chip matcher accepts real images) - Patches Sensor.capture() to accept b[0]=3 as a substitute for b[0]=2, gated on the real device type - #181 — open since 2023 - #225 — 06cb:00b7 user with the same wall - #238 — newer report - Hardware support on Linux is not "downloading a driver." When the vendor doesn't ship one, real people spend real weeks reverse-engineering protocols. Look at the python-validity codebase sometime; the existing supported chips have ~500-byte chip-specific crypto blobs in them that were extracted from USB captures of Windows driver sessions. That work doesn't happen by itself. - When a hypothesis explains some of the evidence, don't -weight: 500;">stop. I had a clean story — "calibration is wrong, images are bad, matching fails" — that explained the verify failure. It did not explain why enrollment completed cleanly and why the template was growing. I should have noticed the contradiction earlier. - Look at the actual data the chip is sending. Adding the TLS-response dump took ten minutes and changed everything. I had been reasoning about what I thought the chip was sending; the actual bytes told a different story. - AI-assisted reverse engineering is a real workflow now. I did this with Claude Code; the model held the protocol knowledge I didn't have and ran disassemblers and code searches in parallel while I was deciding what to do next. The interrupt-handling insight was a result of "let me actually look at every byte the chip sent us and check the contradictions" — a kind of careful empiricism that's much easier with an assistant doing the bookkeeping.

🏷️ Tags

toolsutilitiessecurity toolsfingerprintsensorworkinglinuxexpectation

More from Tools

Tools: SSH died. Spent 3 hours fixing the wrong thing. (2026)

Tools: SSH died. Spent 3 hours fixing the wrong thing. (2026)

2026-05-20 0
Tools: Ultimate Guide: MainWP vs ManageWP vs custom scripts: how I manage 15+ WordPress sites in 2025

Tools: Ultimate Guide: MainWP vs ManageWP vs custom scripts: how I manage 15+ WordPress sites in 2025

2026-05-20 0
Tools: Metrics: How cAdvisor and CRI Collect Kubernetes Stats Kubelet

Tools: Metrics: How cAdvisor and CRI Collect Kubernetes Stats Kubelet

2026-05-20 0
Tools: Essential Guide: GPU Observability for Workloads That Cannot Phone Home

Tools: Essential Guide: GPU Observability for Workloads That Cannot Phone Home

2026-05-20 0

Trending

1

CVE-2025-61481: Critical Remote Code Execution Vulnerability in MikroTik RouterOS & SwitchOS

2025-10-27 • 189 views
2

CVE-2025-43939: Dell Unity OS Command Injection (High)

2025-10-30 • 148 views
3

Google disputes false claims of massive Gmail data breach

2025-10-30 • 130 views
4

Microsoft: DNS outage impacts Azure and Microsoft 365 services

2025-10-30 • 88 views
5

3.5B Accounts, 1 Critical Flaw: Meta Closes WhatsApp Data-Harvesting

2025-11-25 • 81 views