Use different firmware for each device

[mpi3d]

We are currently using same firmware on different devices. If their ID differs, it's obviously for a reason. Only driver code can be shared across different devices.

For each sensor supported by goodix-fp-dump, we should provide a new firmware.

Here are the rules to add a firmware:

• Firmware should be provided only by a Wireshark capture recording the update process between the Windows driver and the device. We should not attempt to extract it from the driver code itself.
• The capture should be posted on goodix-wireshark and referenced in the commit.
• Firmwares should be associated with a CHECKSUMS file containing the SHA256 sum of firmwares. We should be able to use this file with sha256sum command.
• Any commit adding a new firmware should be signed by now.

Any suggestion is also accepted.

[EliaGeretto]

Firmware can also be extracted from the sensor itself, if the firmware provides a command to read the flash (cmd0: 0xf, cmd1: 0x1 for 53x5).

[mpi3d]

Firmware can also be extracted from the sensor itself, if the firmware provides a command to read the flash (cmd0: 0xf, cmd1: 0x1 for 53x5).

Indeed. But the process is a bit more complicated. This might create issues (offsets for example). And we have no option to check if it's valid.

[EliaGeretto]

We actually have the possibility to verify dumps. The IAP firmware verifies the APP firmware on each reset. It does so using a length field and a CRC32 field, which are both stored in flash memory and can thus be dumped. If the firmware dumped from the sensor passes that same check, then it has to be correct. Obviously, this assumes that the IAP firmware was also dumped and reversed.

I agree with you in saying that this process is more complicated, but there are sensors which have never received updates and thus no recording of the update can be obtained.

[mpi3d]

I agree with you in saying that this process is more complicated, but there are sensors which have never received updates and thus no recording of the update can be obtained.

Can't we force the driver to flash the firmware on those devices?

[EliaGeretto]

The check that triggers the flashing verifies the version reported by the microcontroller. One possibility would be to "wipe" the APP firmware and reset into the IAP firmware, but obviously, if something goes wrong, the device will become unusable. If the device has never been updated, the updating process may have not been tested.

[mpi3d]

Could a Windows - Windows dual boot do the trick? (VMs are fine too)

[EliaGeretto]

No, because dual booting would trigger the regeneration of the PSK, but it would not change the version string reported by the microcontroller.

[mpi3d]

So you mean that on 53x5 devices updating the PSK doesn't require to update the firmware?

[EliaGeretto]

No, it is not required. The "whitebox" encryption is obviously the same, but the PSK is flashed in a separate region. If the SHA256 of the PSK does not match the expected one, a new PSK is generated, sent whitebox encrypted and flashed on the microcontroller.