enabling R(Nack) resend

[lvandenb]

If the send packet woud be saved, then a Rblock/Nack would be easily implemented.
if the nack concerns the same block numbeer, just resend the last one.

[maxieds]

Does this concern a particular CONFIG, or is it something that would be handled in the codec code?

[lvandenb]

it is a general issue voor 14443A-4
There is a R block with a Nack.
But it could be done in DESFireISO14443Support.c

[maxieds]

@lvandenb
You can test this new functionality out in the latest commit to my local testing branch (linked in #313).

Pardon my expression, but as a software person, I am in hell. I spent more than six hours today hacking on code to get the standard CommMode combinations happening (MAC'ed, CMAC'ed, Enciphered), and it turns out that all this extra code bloat crashes the firmware. I'm going to have to think about where and what to mix up and remove to get all this to fit. This was the initial pandemic problem challenge to minimize bloat of structures. And now four functions #if'defed out are the difference in reliably authing, and nothing happening.

At any rate, the ACK/NAK functionality you suggested should now work in the DESFire configurations. You can spot check my handy work on these lines if you like.

[lvandenb]

ok, I'm using pm3 witht the right antenna settings, doing hf sniff 14a, then trace list -u -r.
using a omnikey 5022, with diagnostics from hid global tool,
really smooth ..
Now it dies on this

the readers sends DESELECT , and it's game over for this session.

[maxieds]

Ok. I think I'm understanding what could be happening. If you look at this code, the ISO14443A state gets reset periodically. This will cause the stored last data frame size to be zero which is the same as sending out a ISO14443A_APP_NO_RESPONSE. It could also be happening in the DESFire processing commands directly (see here).

It would be tough to figure it out from the image you posted without some corresponding correlated logs coming out of the Chameleon. Have you tried using my Android app with LOGMODE=LIVE so that it prints string formatted debugging messages to the phone's console over USB in real time? If you can pin point what the Chameleon logs are doing when this happens, I will try to look into this more.

Also, I pushed another (smaller) commit to the testing branch about 20 minutes ago. It turns out that some bad choices of sizes/alignments for structures stored in an array (ConfigMap) can be resized to remove some space requirements. This let me reenable the MAC/CMAC/Enciphered CommMode exchanges I have been working on. It all seems to be testing well with the three (Legacy/ISO/AES128) authentication commands with the LibNFC code I have. I should be able to test it more thoroughly when I get my PM3 next week. Can you confirm that the auth commands work with you PM? Also, have you seen these projects added yesterday afternoon?

[lvandenb]

I think there is an issue now. PM3 hf mfdes info can't select card, and green led goes out.
also by just putting on the Omnikey reader .. flashes, and Chameleon green led is out.

also some remark for CMAC (nist.sp.800-38b.pdf). I do calculate K1,K2 only on authentication, not for every cmac.. There also should be a CMAC function, just calculating it, without appending ( sometimes we just calculate cmac without using it, (like on status answers without data), only to get the IV up to date)

[lvandenb]

the behavior of R(NAK) answered by R(ACK) is documented in 14443-part 4
7.5.4 Block handling rules
: 7.5.4.3 PICC rules:
: Rule 12. When an R(NAK) block is received, if its block number is not equal to the PICC’s current block number, an
R(ACK) block shall be sent.
and it seems to be used a lot.

[maxieds]

@lvandenb
I am traveling this week. I hope to get my PM3 in the mail to bring back with me before I leave. I will try to figure out what's killing the light on card selection when it arrives. When that happens, usually it means memory overflowed somewhere it shouldn't have. This could be too much data getting pushed onto the stack, as in the space issues I tried to fix yesterday, or be another legitimate bug in the code that needs to get fixed. Space is (as usual with the DESFire config code) REALLY tight. And making this harder to trace is that there is not really a good software based way to step through the sequence of execution that triggers the error like we can do in C on Linux (that I'm aware of). I am going to have to see whether it makes sense to store a new CMAC and MAC buffer in the state structure, or whether it is better space saving wise to just recompute them every time.

For the RNAK and ISO14443 processing bugs, it is probably going to be on the back burner for a couple of weeks. My first priority is to get the basic auth schemes working and file a PR to get those crashes fixed. For now, I am going to file your suggestions in the last two posts in the DESFire project space @david-oswald gave me access to.