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. 😃

[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.

[fptrs]

@maxieds The lower part of the flash will be used for the firmware and FLASH_DATA_ADDR marks the start where the slots/settings are stored. So if you want to change the number of settings in order to gain space for the firmware you have to change both variables:

• FLASH_DATA_SIZE=#settings*0x2000
• FLASH_DATA_ADDR=0x20000-FLASH_DATA_SIZE

[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...