DESFire emulation support: Bug, stability and reliability fixes and PM3 compatible ISO authentication

[maxieds]

This pull request (PR) brings in many small code patches to the current DESFire support on the RevG devices. The discussion in issue #313 was helpful in fixing unresolved bugs. If this PR gets merged quickly, I can see it making many users looking for improvements to the DESFire support on the Chameleon very happy.

A request in the issue thread by @david-oswald was for me to verify basic ISO authentication functionality with the PM3 devices that so many NFC hardware engineers use day to day:

[usb] pm3 --> script run debug.cmd
[+] executing Cmd debug.cmd
[+] args ''
[usb|script] pm3 --> hw dbg -4
[usb|script] pm3 --> prefs set clientdebug --full
[=]     client debug........... full
[usb|script] pm3 --> data setdebugmode -2
[=] client debug level... 2 ( verbose debug messages )

[#]   Debug log level......... 4 ( extended )
[usb] pm3 --> hf mfdes auth -n 0 -t 3tdea -k 000000000000000000000000000000000000000000000000 -v -c native -a
[=] Key num: 0 Key algo: 3tdea Key[24]: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
[=] Secure channel: n/a Command set: native Communication mode: plain
[+] Setting ISODEP -> inactive
[+] Setting ISODEP -> NFC-A
[=] AID 000000 is selected
[=] Auth: cmd: 0x1a keynum: 0x00
[+] raw>> 1A 00 
[+] raw<< AF EE 91 30 1E E8 F5 84 D6 C7 85 1D 05 65 13 90 A6 C6 D5 
[#] encRndB: EE 91 30 1E E8 F5 84 D6 
[#] RndB: CA FE BA BE 00 11 22 33 
[#] rotRndB: FE BA BE 00 11 22 33 CA FE BA BE 00 11 22 33 CA 
[#] Both   : 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 FE BA BE 00 11 22 33 CA FE BA BE 00 11 22 33 CA 
[+] raw>> AF 30 EB 55 F3 29 39 04 96 77 88 CE EF 33 A3 C8 7B 18 66 1A F1 62 78 A0 28 53 84 67 98 7C BB DB 03 
[+] raw<< 00 9B 71 57 8F FB DF 80 A8 F6 EF 33 4A C6 CD F9 7A 7D BE 
[=] Session key : 01 02 03 04 CA FE BA BE 07 08 09 10 22 33 CA FE 13 14 15 16 00 11 22 33 
[=] Desfire  authenticated
[+] PICC selected and authenticated succesfully
[+] Context: 
[=] Key num: 0 Key algo: 3tdea Key[24]: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
[=] Secure channel: ev1 Command set: native Communication mode: plain
[=] Session key [24]: 01 02 03 04 CA FE BA BE 07 08 09 10 22 33 CA FE 13 14 15 16 00 11 22 33  
[=]     IV [8]: 00 00 00 00 00 00 00 00 
[+] Setting ISODEP -> inactive

Builds of the firmware binaries for testing: DESFire-AuthISO-Patch-FirmwareBinariesBuild.zip

Otherwise, the firmware can be built by running make desfire or make desfire-dev (for extra verbose debugging logs) in the Firmware/Chameleon-Mini/ directory.

---

Support for @maxieds to work on this software project is provided via university COVID relief funding at Georgia Tech. Special thanks to Professor Josephine Yu for funding the PM3 hardware and accessories to get all these code patches working. 😃

[maxieds]

🇺🇦🇺🇦🇺🇦 Hackers stand with Ukraine 🇺🇦🇺🇦🇺🇦

While this pull request sits in the queue, I'm going to try to make a positive message of support out of something that is utterly horrific. This live performance by U2 is the most moving I have seen yet from musicians: https://youtu.be/zi8wxpzTvY4. For those software and EE folks that end up using or appreciating the upgraded DESFire support, please make note. To Josephine, Anton and family: May peace and safety be with you.

[david-oswald]

Hey @maxieds thx for the PR, it is not forgotten, just as I said @fptrs is currently away for a bit. I'll see if I find a few free cycles to test and merge it in the coming days/weeks.

[david-oswald]

Hey @maxieds sorry for the silence and again thanks for your great contributions. We are simply all in an either private and/or work-wise very stressful time. I'm however happy to merge this PR if it makes sense - especially since the current DESFire emulation in the master is broken and this PR would help a lot. There are some merge conflicts with Configuration.c and the Makefile, would it be possible to resolve them / rebase onto master?

[maxieds]

@david-oswald I understand: I am defending in July. I spent some free time working on software this week to decompress.

I think it is an excellent idea to merge the DESFire code in the commits for this PR soon. These updates include many crritical bug fixes to the application handlers for CONFIG=MF_DESFIRE, verified working PM3 compatibility, and then upgrades to odds and ends and the build process. I will try to find some time to resolve the merge conflicts by tomorrow afternoon. The Makefile conflicts should be largely due to re-formatting for readability rather than conflicting changes made to the file.

There are still some known issues with external USB readers to fix as of the latest commit. Once those issues are resolved, I want to update the LibNFC test code under Software/ to ensure it still works with the modifications to the authentication crypto (CBC -> ECB, as the PM3 expects). These modifications are less important and can be added in a new PR whenever it comes together.

The customized new extra build targets supported by BuildScripts/custom_build_targets.mk resolve the discussion from #287 (as mentioned in the active conversation in #313). The last person I remember modifying the automated builds of the firmware on GitHub was @linuxgemini. Once this PR is merged, we should probably update those GH configuration files to autobuild each custom target. The names of the firmware binaries generated by running make target where target = mifare mifare-classic desfire desfire-dev iso-modes ntag215 vicinity sl2s2002 tagatit em4233 are found in BuildScripts/custom_build_targets.mk.

[maxieds]

If anyone else wants to help out with testing this PR, it would be nice to add some example DESFire configuration dumps generated with non-default interactions with the Chameleon.

[david-oswald]

@fptrs Can you please test the above code, merge, and fix the autobuild actions if everything is OK?

[maxieds]

@fptrs The ISO14443A_READER configuration is now enabled for every build target. I do not know what happened resetting the functions for ISO15693_SNIFF. They are now restored to the defaults in the current HEAD of the main branch.

[maxieds]

I also verified the new build of make desfire still works with the PM3:

[usb] pm3 --> script run maxieds-scripts/debug.cmd
[+] executing Cmd maxieds-scripts/debug.cmd
[+] args ''
[usb|script] pm3 --> hw dbg -4
[usb|script] pm3 --> prefs set clientdebug --full
[=]     client debug........... full
[usb|script] pm3 --> data setdebugmode -2
[=] client debug level... 2 ( verbose debug messages )

[#]   Debug log level......... 4 ( extended )
[usb] pm3 --> hf mfdes info
[#] pcb_blocknum 0 == 2 
[#] [WCMD <--: : 08/08] 02 90 60 00 00 00 14 98 
[#] pcb_blocknum 1 == 3 
[#] [WCMD <--: : 08/08] 03 90 af 00 00 00 1f 15 
[#] pcb_blocknum 0 == 2 
[#] [WCMD <--: : 08/08] 02 90 af 00 00 00 34 11 

[=] ---------------------------------- Tag Information ----------------------------------
[+]               UID: 08 E5 0C D9 7B 7B 98 
[+]      Batch number: 7B 98 39 DC 4F 
[+]   Production date: week 8a / 2044

[=] --- Hardware Information
[=]    raw: 04010100011805
[=]      Vendor Id: NXP Semiconductors Germany
[=]           Type: 0x01
[=]        Subtype: 0x01
[=]        Version: 0.1 ( DESFire MF3ICD40 )
[=]   Storage size: 0x18 ( 4096 bytes )
[=]       Protocol: 0x05 ( ISO 14443-2, 14443-3 )

[=] --- Software Information
[=]    raw: 90AF0401010001
[=]      Vendor Id: no tag-info available
[=]           Type: 0xAF
[=]        Subtype: 0x04
[=]        Version: 1.1
[=]   Storage size: 0x00 ( 1 bytes )
[=]       Protocol: 0x01 ( Unknown )

[=] --------------------------------- Card capabilities ---------------------------------
[#] switch_off
[usb] pm3 --> hf mfdes auth -n 0 -t 3tdea -k 000000000000000000000000000000000000000000000000 -v -c native -a
[=] Key num: 0 Key algo: 3tdea Key[24]: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
[=] Secure channel: n/a Command set: native Communication mode: plain
[+] Setting ISODEP -> inactive
[+] Setting ISODEP -> NFC-A
[=] AID 000000 is selected
[=] Auth: cmd: 0x1a keynum: 0x00
[+] raw>> 1A 00 
[+] raw<< AF 02 55 03 8B F2 94 10 9F 3A 00 11 08 1D 71 26 C7 E9 05 
[#] encRndB: 02 55 03 8B F2 94 10 9F 
[#] RndB: 36 C4 B3 C7 8F 40 2B 09 
[#] rotRndB: C4 B3 C7 8F 40 2B 09 1F 83 A9 F4 5D C5 92 08 36 
[#] Both   : 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 C4 B3 C7 8F 40 2B 09 1F 83 A9 F4 5D C5 92 08 36 
[+] raw>> AF F6 0F D9 89 05 E1 BA AC E1 6D 37 32 35 45 52 8D 12 12 D7 A2 C6 7E AC 85 57 DA 47 36 37 33 48 A1 
[+] raw<< 00 C2 A8 DA 7A C6 14 F6 B2 0D E5 D0 72 F0 D7 7C D8 B2 08 
[=] Session key : 01 02 03 04 36 C4 B3 C7 07 08 09 10 2B 09 1F 83 13 14 15 16 5D C5 92 08 
[=] Desfire  authenticated
[+] PICC selected and authenticated succesfully
[+] Context: 
[=] Key num: 0 Key algo: 3tdea Key[24]: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
[=] Secure channel: ev1 Command set: native Communication mode: plain
[=] Session key [24]: 01 02 03 04 36 C4 B3 C7 07 08 09 10 2B 09 1F 83 13 14 15 16 5D C5 92 08  
[=]     IV [8]: 00 00 00 00 00 00 00 00 
[+] Setting ISODEP -> inactive

[fptrs]

@fptrs The ISO14443A_READER configuration is now enabled for every build target. I do not know what happened resetting the functions for ISO15693_SNIFF. They are now restored to the defaults in the current HEAD of the main branch.

I think you misunderstood. You need to enable the MFU config every time the reader config is enabled.

[maxieds]

Yes, the READER/MFU dependency should be fixed in the latest commit. Please triple check me. It's my first month off of caffeine in a long time.

[maxieds]

I usually test with the binaries built with make desfire-dev. I noticed testing today that the Chameleon is substantially more responsive to the PM3 when running with make desfire (turns off a lot of extra logging messages and settings).

[fptrs]

@maxieds I repeated your test with a proxmark3 and I can verify that the build works most of the times. If I repeatedly run hf mfdes info I sometimes get this output:

[usb] pm3 --> hf mfdes info
[#] Halt error

[=] ---------------------------------- Tag Information ----------------------------------
[+]               UID: 08 96 3E A0 C1 1B 3C 
[+]      Batch number: 1B 3C 59 04 33 
[+]   Production date: week 52 / 20d7

[=] --- Hardware Information
[=]    raw: 04010100011805
[=]      Vendor Id: NXP Semiconductors Germany
[=]           Type: 0x01
[=]        Subtype: 0x01
[=]        Version: 0.1 ( DESFire MF3ICD40 )
[=]   Storage size: 0x18 ( 4096 bytes )
[=]       Protocol: 0x05 ( ISO 14443-2, 14443-3 )

[=] --- Software Information
[=]    raw: 90AF0401010001
[=]      Vendor Id: no tag-info available
[=]           Type: 0xAF
[=]        Subtype: 0x04
[=]        Version: 1.1
[=]   Storage size: 0x00 ( 1 bytes )
[=]       Protocol: 0x01 ( Unknown )

[=] --------------------------------- Card capabilities ---------------------------------
[!!] 🚨 APDU: No APDU response
[+] ------------------------------------ PICC level -------------------------------------
[+] Applications count: 0 free memory n/a
[+] PICC level auth commands: auth: NO auth iso: NO auth aes: NO auth ev2: NO auth iso native: NO auth lrp: NO

[=] --- Free memory
[+]    Card doesn't support 'free mem' cmd

If I get this output the Chameleon is stuck and needs a reboot. So far I got no clue what triggers this behavior. Have you experienced this before?

[maxieds]

@fptrs I will try to look into this tonight. I am going to need more debugging information to figure out what is going on.

[maxieds]

@fptrs I am no longer able to crash the Chameleon by repeatedly running hf mfdes info. The responsiveness seems to be subject to how close the PM3 is to the Chameleon when running the command. I find that positioning the Chameleon about 1.25in from the PM3 works the best. When it is too close, it returns an error on the PM3. Moving it way back then repositioning gets the command to work again.

Can you confirm it's now working this way with your setup?

[fptrs]

@maxieds Thank you for the fixes. I hadn't had time to test the changes yet, but I will do it this week

[maxieds]

Thanks. I successfully defended my thesis yesterday. I should have a couple of free weeks to do stuff if there are more problems starting at the end of next week.

The issues I spotted using make desfire-dev and live logging to my phone with the CMLD app suggest that there were some jumbled messages getting interspersed from logging the codec TX/RX to other messages. I added the sei/cli statements to the live logger header and things seemed to get better. If problems persist, I think we should look at that first: Something like a codec interrupt getting triggered while writing logs (to FRAM, or LIVE over USB) could have caused problems. There are some race condition though.

[fptrs]

@maxieds I can confirm that the setup works without any crashes of the chameleon. Good work 👍

[usb] pm3 --> hf mfdes info
[#] pcb_blocknum 0 == 2 
[#] [WCMD <--: : 08/08] 02 90 60 00 00 00 14 98 
[#] pcb_blocknum 1 == 3 
[#] [WCMD <--: : 08/08] 03 90 af 00 00 00 1f 15 
[#] pcb_blocknum 0 == 2 
[#] [WCMD <--: : 08/08] 02 90 af 00 00 00 34 11 

[=] ---------------------------------- Tag Information ----------------------------------
[+]               UID: D7 90 A7 54 96 E0 51 
[+]      Batch number: 96 E0 BA 9A A5 
[+]   Production date: week eb / 2050

[=] --- Hardware Information
[=]    raw: 04010100011805
[=]      Vendor Id: NXP Semiconductors Germany
[=]           Type: 0x01
[=]        Subtype: 0x01
[=]        Version: 0.1 ( DESFire MF3ICD40 )
[=]   Storage size: 0x18 ( 4096 bytes )
[=]       Protocol: 0x05 ( ISO 14443-2, 14443-3 )

[=] --- Software Information
[=]    raw: 90AF0401010001
[=]      Vendor Id: no tag-info available
[=]           Type: 0xAF
[=]        Subtype: 0x04
[=]        Version: 1.1
[=]   Storage size: 0x00 ( 1 bytes )
[=]       Protocol: 0x01 ( Unknown )

[=] --------------------------------- Card capabilities ---------------------------------
[#] switch_off
[+] ------------------------------------ PICC level -------------------------------------
[+] Applications count: 0 free memory n/a
[+] PICC level auth commands: auth: YES auth iso: YES auth aes: NO auth ev2: NO auth iso native: NO auth lrp: NO

[=] --- Free memory
[+]    Card doesn't support 'free mem' cmd

[usb] pm3 --> hf mfdes auth -n 0 -t 3tdea -k 000000000000000000000000000000000000000000000000 -v -c native -a
[=] Key num: 0 Key algo: 3tdea Key[24]: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
[=] Secure channel: n/a Command set: native Communication mode: plain
[+] Setting ISODEP -> inactive
[+] Setting ISODEP -> NFC-A
[=] AID 000000 is selected
[=] Auth: cmd: 0x1a keynum: 0x00
[+] raw>> 1A 00 
[+] raw<< AF DE 0B 42 FC D6 D5 DB 3A 74 E6 32 CA 6C 17 FD 14 33 3F 
[+] raw>> AF 47 27 A0 CA 25 D0 A5 61 42 90 7B B6 4D 29 15 EB 7A E2 3D C8 26 D3 20 6D CF D7 5B C5 4A 5D B0 B9 
[+] raw<< 00 8B 6C 67 32 E8 DB 1B 8E 5D CC 70 FC CC DD 63 34 D5 76 
[=] Session key : 01 02 03 04 98 2E DB 6A 07 08 09 10 FB 6A 51 3F 13 14 15 16 32 FF E5 9C 
[=] Desfire  authenticated
[+] PICC selected and authenticated succesfully
[+] Context: 
[=] Key num: 0 Key algo: 3tdea Key[24]: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
[=] Secure channel: ev1 Command set: native Communication mode: plain
[=] Session key [24]: 01 02 03 04 98 2E DB 6A 07 08 09 10 FB 6A 51 3F 13 14 15 16 32 FF E5 9C  
[=]     IV [8]: 00 00 00 00 00 00 00 00 
[+] Setting ISODEP -> inactive

[maxieds]

@fptrs @linuxgemini Are either of you still the maintainer of the nightly firmware builds? The PR just merged has several new custom build targets that are compiled by running any of the following commands:

make mifare|mifare-classic|desfire|desfire-dev|iso-modes|ntag215|vicinity|sl2s2002|tagatit|em4233

Each target generates firmware binaries with names reflective of the contents that can be copied into the latest builds directory. These file names are set by the TARGET_CUSTOM_BUILD_NAME variable in this new make build script. For example, running make desfire-dev yields the outputs:

Chameleon-Mini-CustomBuild_DESFire_DEV.(HEX|EEP|ELF|BIN)

It would be nice to see this get integrated on the main repo. I guess I can try asking about this topic on discord later if no one notices the comment on the closed PR.

[fptrs]

@maxieds I will look into it

[david-oswald]

@maxieds @fptrs and I had talked about this, and we concluded that auto-building all targets will be too confusing for most users. We basically now want to have three: all "normal" ISO14443 cards, ISO15693, and DESFire. The remaining ones are probably best left to expert users who clone the repo and build locally.

[maxieds]

@david-oswald Okay. That sounds reasonable. Do you think we should add something to the documentation to tell users that these make targets can build standard tag configurations without having to fiddle too much with hand editing the Makefile? Scanning the Makefile does not give users a clue. All this magic is hidden in a build script that is included midfile.

Also, testing with the USB readers as I mentioned in #313 earlier, there is a build error running make desire|desfire-dev on Arch Linux. The bc command used to calculate the flash address bounds on the fly is not installed by default. It may be a problem on other Linux distros. I will push a commit into a new branch on my fork in a short while. Hope to file another small PR to fix up some of the DESFire code and build scripts soon (maybe today or this weekend).

[maxieds]

@david-oswald Recent commits to the working development branch of my fork will have documentation for these new extra make targets (see this new docs page). I am trying to get this submitted as a PR this weekend. Bear with me...