Catcrafts/fingerprintd
Watch
2
0
Fork
You've already forked fingerprintd
 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Delete a finger's template, not just its name

Browse source 
FF_CMD_TA_REMOVE, recovered the way AUTHENTICATE was: read the stub, read the
handler. The 0x2006 stub at 0xa15c is a bare `ldp w0, w1, [payload]`, so the
request is two u32s -- gid at +0, fid at +4 -- and the 0x2000 dispatcher
validates no length. Walking the jump table reproduces authenticate at 0xa180,
which is the address already on record, so the table read is sound.

Three preconditions, all the trustlet's own. The gid must be the ACTIVE group
(it compares against device+0x30, the field SET_ACTIVE_GROUP writes). The fid
must be non-zero: zero is not "remove all", it is an error the trustlet logs
and refuses. And the fid must be among the loaded templates, because it
removes by the SLOT INDEX it finds, not by id.

It persists: on a hit the trustlet formats ff_template_<gid>_<slot>.bin and
calls ff_file_delete, which arrives on our gpfile listener as an unlink -- so
this only works with the store served writable.

Proven harmlessly first. --probe-remove sends one command with no map
involvement, and a fid the group does not hold answers rc=-2 with the real
template untouched -- which is what established that both words are read where
we send them, before anything was deleted.

Then for real, through fprintd-delete: both 347202-byte containers and their
.bak companions unlinked, templates loaded 1 -> 0, and a re-enrolment
afterwards completed 20 stages with SAVE_DATA rc=0, so the store is consistent
after a removal rather than merely emptier.

The ordering the transcript shows is worth keeping: the group index is
rewritten and the RPMB anti-rollback counter bumped BEFORE each unlink. That
is precisely why an orderly removal leaves a valid store where restoring an
older container leaves a tampered one -- the counter has already moved past
it.

The delete reply now waits for the worker, because only that thread invokes
the trustlet and fprintd's Delete methods are synchronous. Names are dropped
before templates on purpose: a template that survives a failed removal is a
slot leak, while a name that survives a successful one keeps offering a finger
that can no longer match.
This commit is contained in:
Jorijn van der Graaf 2026-09-05 04:27:14 +02:00
commit 41e86f84f4
4 changed files with 178 additions and 13 deletions
Download patch file Download diff file Expand all files Collapse all files

15
tests/Ta/main.cpp
View file

@ -239,6 +239,21 @@ int main() {
Check(std::to_integer<unsigned>(au[AuthRelightOff]) == 0, "flags clearable");
}
// ---- REMOVE payload. Recovered from the 0x2006 stub at 0xa15c, which is
// a bare `ldp w0, w1, [payload]` into ff_trustlet_remove.
{
std::vector<std::byte> rm(RemovePayloadSize);
BuildRemovePayload(rm, 10000, 1768306590);
Check(RemovePayloadSize == 0x08, "declared length is exactly the two fields");
Check(Get32(rm, RemoveGidOff) == 10000, "gid at +0");
Check(Get32(rm, RemoveFidOff) == 1768306590, "fid at +4");
// Order matters and is not symmetric: the trustlet compares the FIRST
// word against device+0x30 (the active group) and searches its loaded
// list for the SECOND. Swap them and it reports the wrong-group error.
Check(RemoveGidOff < RemoveFidOff, "gid precedes fid");
Check(static_cast<std::uint32_t>(Cmd::Remove) == 0x2006, "command id");
}
// ---- ENROLL payload: an all-zero token is accepted when trusted
// enrolment is off, which is why pmOS needs no Gatekeeper.
{