Hi!
python-validity is what made this possible — I ported its secure channel onto an SPI transport and it worked — so it seems only right to point back at it.
I have recovered the protocol for the Synaptics SYNA8002, an SPI part rather than USB, in the ThinkPad X1 Tablet Gen 3, and have a working driver that authenticates a GDM login by thumb:
https://github.com/sandbranch/x1-tablet-gen3-fingerprint
The certificate the sensor demands turns out to be exactly python-validity's make_cert format, and tls.py needed no changes at all. What is new, in case any of it is useful for the SPI variants:
- SPI framing: opcode 0x01 status / 0x02 write / 0x03 read, with the status word at RX[2..5] and no CRC anywhere;
- image readout is a separate opcode 0x05 whose id byte comes from rx[2] of the status word — 0x03 returns all-0xFF for image data, and the response-available bit is never set for it, which cost me a while;
- product 0x33 uses a third line-update builder that python-validity does not have (it has type_1 and type_2);
- this part has no flash IC at all — 0x3e succeeds and reports JEDEC ff:ff with zero partitions — so the pairing lives host-side, in the Windows
registry, rather than encrypted in sensor flash.
That last point may be the one worth having: it means 0x04af from a flash read on these parts can mean "there is no flash", not "denied". I read it the other way for a week.
Two limitations, stated plainly: it reuses a pairing key recovered from a Windows install, so it will not initialise a sensor that has never run Windows; and it needs a configuration blob extracted from the vendor DLL, which I cannot redistribute — instructions for pulling your own are in the repo.
No ask attached. I am not proposing this as a merge — it is Python, it is SPI, and it is a different device class from what this project targets. Just closing the loop, since I would not have got anywhere without your work.
Thank you!
David Sandquist
Hi!
python-validity is what made this possible — I ported its secure channel onto an SPI transport and it worked — so it seems only right to point back at it.
I have recovered the protocol for the Synaptics SYNA8002, an SPI part rather than USB, in the ThinkPad X1 Tablet Gen 3, and have a working driver that authenticates a GDM login by thumb:
https://github.com/sandbranch/x1-tablet-gen3-fingerprint
The certificate the sensor demands turns out to be exactly python-validity's make_cert format, and tls.py needed no changes at all. What is new, in case any of it is useful for the SPI variants:
registry, rather than encrypted in sensor flash.
That last point may be the one worth having: it means 0x04af from a flash read on these parts can mean "there is no flash", not "denied". I read it the other way for a week.
Two limitations, stated plainly: it reuses a pairing key recovered from a Windows install, so it will not initialise a sensor that has never run Windows; and it needs a configuration blob extracted from the vendor DLL, which I cannot redistribute — instructions for pulling your own are in the repo.
No ask attached. I am not proposing this as a merge — it is Python, it is SPI, and it is a different device class from what this project targets. Just closing the loop, since I would not have got anywhere without your work.
Thank you!
David Sandquist