Catcrafts/fingerprintd
Watch
2
0
Fork
You've already forked fingerprintd
 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
fingerprintd/tests/Sfs/fixtures/README.md

20 lines
1.2 KiB
Markdown
Raw Permalink Normal View History

Initial commit: the gpfile wire format, pinned by two real containers fingerprintd will own the FP6's fingerprint sensor: the rail, the QTEE session, the storage callbacks QTEE makes back into the normal world, and net.reactivated.Fprint so pam_fprintd and the desktop need no changes. None of that runs yet. What is here is the first core module and the machinery around it. Fingerprintd:Sfs is the gpfile listener's frame -- the callback that carries 47 of 66 storage requests during an enrolment. It is parse, reply and root mapping only: no file I/O, no TEE, no allocation of the shared buffer. The daemon shell supplies those, which is what lets every byte-level decision be tested on a dev box with no phone. The module exists mainly to hold one fact. READ answers at req+0x00c and WRITE reads its payload from req+0x110, because the frame is a union: a WRITE still needs its path while the payload is copied out, so it sits past the 256-byte path field, while a READ has consumed the path and packs its reply over it. Conflating them is wrong in both directions with the same symptom -- the container does not round-trip, QTEE's HMAC check fails, and the file is unlinked as tampered on the next session. So the tests do not assert the constants against themselves. They load two real containers off the phone -- one written correctly, one written with the offsets conflated -- and re-derive the bug: the broken one opens with ASCII path text rather than a binary HMAC, that text is the group name from character 8 because the read offset is 8 bytes into the path field, and the real container sits exactly 0x104 further in. Then a write-store-read round trip must be the identity, and the same round trip through a single offset must not be. O_TRUNC gets a static_assert of its own. QTEE writes a container as write(0,4096), write(4096,N), write(0,4096), so truncating on open leaves 4096 bytes where a 258850-byte template belongs; it unlinks a file it means to shorten rather than relying on the opener. Verified by mutation: conflating the offsets, making DataOffset return the read offset for writes, and setting O_TRUNC each fail the suite.
2026-09-02 16:02:46 +02:00
# Recorded SFS containers
Two real containers, taken off the Fairphone 6 dev phone's persist partition
and carried here so the offset split is pinned by bytes that actually failed
rather than by bytes we invented.
| file | provenance |
|---|---|
| `container-correct.bin` | 1588 B. A well-formed QTEE index container: 32-byte HMAC, NUL-terminated group name at +0x20, `u32` version, `u32` entry count, then `{u32; name}` entries. |
| `container-wrong-offset.bin` | 8192 B. The same container written while READ and WRITE shared a data offset. It begins with *path text* — characters 8 onward of the group path — and the real container starts 0x104 bytes in. |
Originals and their full analysis live in the fp6 journal as
`journal/fingerprint/captures/2026-08-30-vtable-master-correct-structure.bin`
and `…-container-written-at-the-wrong-offset.bin`.
**These hold no biometric material.** A fingerprint template is a separate
258850-byte container; these two are the index that names them. Their contents
are a QTEE-encrypted blob plus opaque device-derived names — but they *are*
from a specific device, so treat publishing them as a deliberate choice rather
than an incidental one.
Reference in a new issue Copy permalink