When use AES and full data encryption, there is a CRC32 check.
According to document, it is a known data length message for encryption. So the padding is all zeros. Not 0x80 followed by all zeros.
It can also be verified by seeing the actual PICC data after AES decryption. There is no 0x80 in the padding.
In the current mifare_cryto_postprocess_data.c implementation. It does take payload data length as parameter. Instead, it check where the CRC meets 32bit zero to determinate the payload length.
But this implementation will have 1/256 of probability(last byte of CRC also 0x00) that the guessed payload length is less one byte when the last byte of payload is 0x00.
It should perform 4 round of CRC check. But in the third round, CRC remainder is 00 00 00 00, same as fourth round.
This cause the output post processing data only 63 bytes. It should be 64 bytes.
When use AES and full data encryption, there is a CRC32 check. According to document, it is a known data length message for encryption. So the padding is all zeros. Not 0x80 followed by all zeros. It can also be verified by seeing the actual PICC data after AES decryption. There is no 0x80 in the padding.
In the current mifare_cryto_postprocess_data.c implementation. It does take payload data length as parameter. Instead, it check where the CRC meets 32bit zero to determinate the payload length.
But this implementation will have 1/256 of probability(last byte of CRC also 0x00) that the guessed payload length is less one byte when the last byte of payload is 0x00.
for example, payload: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 10 DF 21 A1 C0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 02 BA 7D EF 30 00 yields CRC32: E0 43 E2 00
It should perform 4 round of CRC check. But in the third round, CRC remainder is 00 00 00 00, same as fourth round. This cause the output post processing data only 63 bytes. It should be 64 bytes.
Paul