fixed PCB if i-block in iso14443-4 handling

dev-zzo / ChameleonMini

The ChameleonMini is a versatile contactless smartcard emulator compliant to NFC. For further information see the Getting Started Page or the GitHub-Wiki-Tab above.

https://rawgit.com/emsec/ChameleonMini/master/Doc/Doxygen/html/Page_GettingStarted.html

Other

14 stars 1 forks source link

fixed PCB if i-block in iso14443-4 handling #4

Closed shombre closed 8 years ago

shombre commented 8 years ago

alternative to #1. this fixes a wrong handling of the prologue in iso14443-4 frames.

PrologueLength was not correct when CID is not used
CID-bit in PCB of response was not set when CID is used

dev-zzo commented 8 years ago

Thanks for this. After your previous comment on the CID bit handling I found and fixed that one. Could you explain why do you think that PrologueLength is incorrect? As far as I can see it is set correctly at lines 1506..1512? The change you introduce seems to simply duplicate that.

shombre commented 8 years ago

Did not see that you already fixed the CID bit. With this your implementation should work fine. : )

Could you explain why do you think that PrologueLength is incorrect?

1506..1512 calculates the PrologueLength of the readers request. At 1528..1540 you need the PrologueLength of the cards response.

The card may

either respond with a simple 'copy' of the readers prologue (see #1)
or build an prologue on it's own and thus calc it's own PrologueLength (see #4)

It's a matter of taste, but imo it does not make sense to build a new prologue while copy the length from the request.

dev-zzo commented 8 years ago

I can see your point.

The thing is, though, that I cannot see a case in which the PCD request prologue length would not be equal to the PICC response prologue length. The standard specifically states that whenever the PCD sends CID and/or NAD, those shall be used in the response as well. Thus my assumption. If we decide that those two lengths may not be equal, then buffer handling gets quite a bit involved as we have to pass two pointers to MifareDesfireProcess() and have additional fun there...

I think we should have separate input/output buffers anyway for ISO 14443-4 to support transparent retransmission, but that's a separate concern.

shombre commented 8 years ago

agree! i close this as the main issue is fixed by commit c0765c51701fe67ccc6d7c1c07519878ad525297.