{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreigp2mde2v5ywqfdvyfqbprj2mtjzzk2a7qgo554mjb6quzzdeiimu",
    "uri": "at://did:plc:nkxz2ojdvmieg2nhphvputvp/app.bsky.feed.post/3mmgpfub6iop2"
  },
  "coverImage": {
    "$type": "blob",
    "ref": {
      "$link": "bafkreihhg4nfdrsccwgvnaqf227oww5q2ahdpsk6ucnbh3xmdfgeunjc7i"
    },
    "mimeType": "image/png",
    "size": 1199525
  },
  "description": "Im letzten Beitrag zum Thema hatte ich angekündigt, dass ich mir auch den NB-2033-U vornehmen will. Der steckt in einem zweiten Fujitsu Notebook hier, dem von meiner Tochter Maja. Gleicher Hersteller, gleiche Sensorfamilie, sollte ähnlich laufen wie beim NB-2020-U. Dachte ich.\n\nFalsch gedacht.\n\nHersteller sagt: geht nicht\n\nIch hatte bei NEXT Biometrics nach Protokolldokumentation oder einem SDK für den NB-2033-U gefragt. Kevin Hung, Director FAE, antwortete freundlich aber […]",
  "path": "/2026/03/17/next-biometrics-nb-2033-u-reverse-engineering-fingerabdruckleser-linux/",
  "publishedAt": "2026-05-22T10:17:45.000Z",
  "site": "https://www.kernel-error.de",
  "tags": [
    "Fujitsu",
    "Hardware",
    "libfprint",
    "Linux",
    "OpenSource",
    "ReverseEngineering",
    "USB",
    "letzten Beitrag zum Thema",
    "NB-2020-U",
    "linux-hardware.org",
    "MR !574",
    "MR !569",
    "Issue #134",
    "fragen"
  ],
  "textContent": "Im letzten Beitrag zum Thema hatte ich angekündigt, dass ich mir auch den NB-2033-U vornehmen will. Der steckt in einem zweiten Fujitsu Notebook hier, dem von meiner Tochter Maja. Gleicher Hersteller, gleiche Sensorfamilie, sollte ähnlich laufen wie beim NB-2020-U. Dachte ich.\n\nFalsch gedacht.\n\n### Hersteller sagt: geht nicht\n\nIch hatte bei NEXT Biometrics nach Protokolldokumentation oder einem SDK für den NB-2033-U gefragt. Kevin Hung, Director FAE, antwortete freundlich aber eindeutig:\n\n> „Both 2020-U and 2033-U have different firmware and USB stack. The code flow (libusb) related to 2033-U and 2020-U is different. This could be the reason for 2033-U failure/unsupported in linux. As of now, it is not supported.“\n\nKein SDK, keine Doku, kein Support. Und 74 Einträge auf linux-hardware.org mit Status „failed“ für die USB ID `298d:2033`. Weltweit kein Linux-Support für dieses Gerät.\n\nGut. Dann eben Reverse Engineering.\n\n### Erster Versuch: Windows-Treiber belauschen\n\nPlan A war klassisch: Windows-Treiber in einer VM laufen lassen, USB-Traffic mitschneiden. VirtualBox installiert, USB-Passthrough konfiguriert, Windows gestartet. Der Fingerabdruckleser tauchte im Gerätemanager auf. Mit Code 31. Treiber konnte das Gerät nicht starten. Secure Boot hatte VirtualBox den Kernel-Treiber nicht signiert, und der USB-Passthrough war damit unbrauchbar.\n\nPlan A verworfen.\n\n### Plan B: Das SDK direkt auf Linux\n\nDas SDK von NEXT Biometrics (`libNBBiometrics.so`) unterstützt den NB-2033-U intern. Es kommuniziert direkt über `libusb`, ohne Kernel-Treiber. Das heißt: ich kann das SDK-Sample direkt auf dem Linux-Notebook laufen lassen und gleichzeitig den USB-Traffic mit `usbmon` mitschneiden.\n\nDafür musste Secure Boot deaktiviert werden. `usbmon` ist ein Kernel-Modul, und `lockdown=integrity` (von Secure Boot gesetzt) blockiert es auch für root. Secure Boot im BIOS aus, `lockdown=none` in GRUB, Neustart. Danach:\n\n\n    modprobe usbmon\n    cat /sys/kernel/debug/usb/usbmon/3u > /tmp/capture.txt &\n    ./NBBSample\n\n7654 Zeilen USB-Traffic. Das komplette Protokoll des NB-2033-U, aufgezeichnet während einer Enrollment-Session.\n\n### Was dabei rauskam\n\nDas Protokoll ist komplett anders als beim NB-1010-U/NB-2020-U. Kevins Aussage stimmte. Hier die wesentlichen Unterschiede:\n\nEigenschaft| NB-1010-U / NB-2020-U| NB-2033-U\n---|---|---\nBulk IN Endpoint| EP 3 (0x83)| EP 1 (0x81)\nKommandoformat| `[0x80][CMD][SEQ][0x00]...`| `[CMD][0x00][LEN_LO][LEN_HI][PAYLOAD]` (TLV)\nFinger-Erkennung| Einzelnes `0x38`| Zwei `0x0D` Config + `0x38`\nBildübertragung| 90 Chunks à 540 Bytes| 180 Chunks à 268 Bytes\nInit| Einmal `0x07`| Zweimal `0x07` nötig\n\nGleicher Sensor-Die (256×180 Pixel, 385 DPI, aktiv thermisch), aber ein komplett anderer USB-Stack. Der NB-2033-U nutzt ein TLV-Format (Type-Length-Value) statt des festen Kommandoschemas vom NB-1010-U. Jedes Kommando hat eine eigene Längenangabe, und die Antworten sind anders strukturiert.\n\n### Die Kommandos im Detail\n\nAus dem USB-Capture konnte ich sechs Kommandos identifizieren:\n\n  * `0x07` — Init/Wake. Muss zweimal gesendet werden, sonst reagiert der Sensor nicht.\n  * `0x0D` — Sensor-Konfiguration. Wird zweimal vor jeder Finger-Erkennung gebraucht, um den „Enhanced“ Modus zu aktivieren.\n  * `0x38` — Finger-Erkennung. Byte 4 der Antwort ist der Detect-Level. Schwellwert 40.\n  * `0x12` — Capture starten. Liefert 180 Zeilen à 256 Pixel, 8-Bit Graustufen.\n  * `0x13` — Geräteinformationen (Hersteller, Modell, Seriennummer).\n  * `0xF7` — Firmware-Version.\n\n\n\n### Thermischer Sensor: Eigenheiten\n\nDer Sensor misst Temperaturänderungen, nicht statischen Kontakt. Das klingt nach einem Detail, ist aber für die Treiber-Implementierung entscheidend. Finger auflegen erzeugt einen kurzen Spike im Detect-Wert (10 bis 50+). Finger bleibt liegen, und der Wert fällt zurück auf Basisniveau. Der Treiber muss also den Spike erkennen, nicht einen dauerhaften Zustand.\n\nDazu kommt: Nach dem Init gibt es transiente Spikes, die ungefähr 1,5 Sekunden brauchen, bis sie abklingen. Ohne Settle-Pause nach dem Init erkennt der Treiber Phantom-Finger.\n\n### Der Treiber\n\nRausgekommen ist `nb2033.c`, ein eigenständiger libfprint-Treiber mit rund 350 Zeilen. Kein proprietärer Code, keine SDK-Abhängigkeit. Das SDK diente nur als Referenz für die Capture-Analyse, der Treiber ist sauber von Grund auf geschrieben. Lizenz: LGPL 2.1+ wie alle libfprint-Treiber.\n\nDie State Machine:\n\n  1. Init (`0x07` × 2) mit 1,5 Sekunden Settle-Pause\n  2. Finger-Detect-Polling (`0x0D` + `0x0D` + `0x38`, Schwellwert 40)\n  3. Pre-Capture Config (`0x0D`)\n  4. Capture (`0x12`) mit 150 ms Pause, dann 180 Zeilen lesen\n  5. Bild an libfprint übergeben\n\n\n\n### Test\n\nGetestet auf Majas Fujitsu Notebook mit Linux Mint 22.3:\n\n\n    $ fprintd-enroll\n    Using device /net/reactivated/Fprint/Device/0\n    Enrolling right-index-finger finger.\n    Enroll result: enroll-stage-passed\n    [... 5/5 Stages ...]\n    Enroll result: enroll-completed\n\n\n    $ fprintd-verify\n    Using device /net/reactivated/Fprint/Device/0\n    Listing enrolled fingers:\n     - #0: right-index-finger\n    Verify result: verify-match (true)\n\nRichtiger Finger: Match. Falscher Finger: No Match. Enrollment sauber, Verifikation zuverlässig.\n\n### Upstream\n\nDer Merge Request ist eingereicht: MR !574 bei libfprint. Fünf Dateien: der neue Treiber, meson.build, autosuspend.hwdb und die Allowlist. CI läuft durch. Der verwandte MR !569 für den NB-2020-U ist noch in Review.\n\nFür die Wiki-Aktualisierung (das Gerät von der „unsupported“ Liste nehmen) gibt es Issue #134.\n\n### Fazit\n\nDer Hersteller sagt „not supported“, 74 Linux-User melden „failed“, und trotzdem war das an einem Nachmittag erledigt. SDK auf Linux ausführen, USB-Traffic mitschneiden, Protokoll rekonstruieren, Treiber schreiben, testen, upstream einreichen. Alles mit Open-Source-Tools: `usbmon`, `libusb`, `libfprint`.\n\nDas Ergebnis: Majas Notebook hat jetzt einen funktionierenden Fingerabdruckleser unter Linux. Und sobald der Merge Request durch ist, haben ihn alle anderen auch.\n\nWie immer: Bei Fragen, fragen.",
  "title": "NEXT Biometrics NB-2033-U: Reverse Engineering eines Fingerabdrucklesers für Linux"
}