Desfire adpu processing for real iso-8716

[lvandenb]

module MifareDesfireProcess
will not work for real iso - 8716 apdu like

00  A4  04  00  0b     a0 00 00 03 97 43 49 44 5f 01 00 9e 32
CLA INS P1  P2  LE

right now, it is only testing "wrapped desfire" or "native". and it fails or the first command...

if(ByteCount >= 8 && DesfireCLA(Buffer[0]) && Buffer[2] == 0x00 && 
       Buffer[3] == 0x00 && Buffer[4] == ByteCount - 8) { 

in this case buffer[2] == 0x04, and some iso-8716 do not have a LE field ...

And it seems simple to do
if Buffer[0]==0x90 then wrapped for sure, else if Buffer[0]<0x0a then most likely 8716 else most likely Desfire Native.
for native check the first byte as a valid command, otherwise the second..

most of the time, communication starts with file select , like "select the desfire app" (this is optional but recommended)
00 A4 04 00 07 D2 76 00 00 85 01 00

on windows, it will always try 00 a4 04 00 0b a0 00 00 03 97 43 49 44 5f 01 00 9e 32, first, if smartcard services are enabled.
( so windows users using the pc/sc api, will always fail trying native desfire when the smartcard service is active)

for the global communication there should be a flag, like "protocolFraming" = unknown / native / 8716
after the card becomes "state active" , the first command determines the protocol framing. until reset..

[maxieds]

@lvandenb
I will put fixing this on my TODO list. Right now I am still getting up to speed on the first issue #302. It can probably wait for a second pull request once the first is done?

[maxieds]

@lvandenb

CODEC RX DATA: 0A 01 00 A4 04 00 0B A0 00 00 03 97 43 49 44 5F 01 00 9E 32

Do you know what the prepended two bytes correspond to? How should this get preprocessed?

[lvandenb]

these are 14443 I-blocks. (marked by the first 2 bytes)
The last two bytes will be 14443 crc.
the first command byte is class 0, should be full iso7816.

so select file (with a DF name) A0 00 00 03 97 43 49 44 5F 01 00
should answer not found 0x6a 0x82
I think there are also known well know AID names for PIV .. should also answer 0x6a 0x82

only name D2760000850100 (Desfire app) should answer found (0x90 0x00) , and select aid 000

the iso answer will need to be preceeded by the same 0A 01 prologue...

[maxieds]

Edited:
Are the two prologue bytes something that can consistently be identified, or are they something that the reader is free to arbitrarily prepend to the ISO7816 command format?

Also, thank you for all the help these last couple of weeks! I am feeling really good about getting the pull request in today (by the end of my marathon weekend) to add complete reader support. All my previous testing was with wrapped and native commands with LibNFC...

[maxieds]

@lvandenb
The local implementation needs some testing. I do not believe either one of my readers is sending out the example command you gave above. The changes made in the last commit DID prevent pcsc_scan -v from listing that the card is unresponsive. Now that command correctly says that a DESFire card was inserted. This is progress.

[lvandenb]

I thought most processing was already done via MifareDesfireProcess()
this keeps the prologue, and adds it back afterwards.

but only wrapped desfire ( class starts with 0x90, or native Desfire is processed now.
(and even iso8716 wrapped is first unwrapped to look like native desfire command.. )

anyway, the first command determines Native or 8716 (including wrapped native)

for the implementation I can make existing send and receive apdu's.
( with the random number fixed at sender and receiver, it is easier to test.
I guess the tools on https://pcsclite.apdu.fr/ let you end and receive the apdu's on linux.

[maxieds]

I have had my head in the clouds since Thursday on like four hours of sleep working on mathematical writing style to eloquently describe the results in an analytic number theory paper I am responsible for this year. On top of that, it's snowing hard for the usually light hoodie as winter weather in Atlanta. Let me have another cup of coffee and come back to writing code in an hour.

Perhaps we can aim to get this pull request started for the holiday (in the US) tomorrow? When I file the PR, I will make sure to note at the top that it is collaborative with @lvandenb and @colinoflynn.

[maxieds]

I guess the tools on https://pcsclite.apdu.fr/ let you end and receive the apdu's on linux.

I found the scriptor utility docs here so that I do not have to do this in low-level C.

[maxieds]

@lvandenb @colinoflynn
Can you help me with testing the code from the latest commit to my local branch?

The scriptor command reports an invalid SW byte when transferring the command from above, but the output 0x6a 0x82 is accurately returned and prefixed with the prologue bytes.

Update:

[lvandenb]

it seems logframe 59 sends the answer,
logframe 60 the answer + crc
and logframe 61 the prologue + answer

so 3 answers instead of 1 ?

the full 14443a i-block frame should be 6 bytes, the answer with 2 leading bytes (I-Block), and 2 trailing crc bytes
like 02 01 6a 82 crc1 crc2 ?

I'm still waiting for my Proxmark.
But below is what happens on windows with Omnikey tool, and a real Desfire EV1.

this is sniffed from usb, so the 14443a-4 framing is handled by the reader.

OUT : 00 a4 04 00 0b a0 00 00 03 97 43 49 44 5f 01 00
(ISO File Select P1: 04 (Select by DF Name) , P2: 0 (FCI stored in the file with ID 31) , Data a0000003974349445f0100)
(looks for Microsoft PNP AID)

IN : 6a 82
file not found

OUT : 00 ca 7f 68 00
(Get Data , BER-TLV tag (2 bytes) in P1-P2)

IN : 6d 00
(Instruction not supported)

OUT : 00 a4 04 00 09 a0 00 00 03 08 00 00 10 00
(ISO File Select P1: 0 Select by DF Name P2: 0 FCI stored in the file with ID 31 :Data a00000030800001000 )
( looks for Personal Identity Verification (PIV) AID)
IN : 6a 82
( file not found)

OUT : 00 a4 04 00 09 a0 00 00 03 97 42 54 46 59
(ISO File Select P1: 0 Select by DF Name , P2: 0 FCI stored in the file with ID 31 , Data a00000039742544659)
(looks for Microsoft IDMP AID )
IN : 6a 82
(file not found)

remark: well known AID list in https://www.eftlab.com/knowledge-base/211-emv-aid-rid-pix/

[maxieds]

@lvandenb
Do you think the code is ready to file the pull request? It definitely resolves #302.

[lvandenb]

Last night it still did not answer the iso file select correctly
it was 4 bytes 02 01 6a 82 , instead of the needed 02 01 6a 82 crc1 crc2
Also the log seemed to be overwritten by 6a 82

[lvandenb]

I just check the latest build the iso file select answers twice , but both are incomplete 1: 6a 82 94 21 : missing prologue 2: 0a 01 6a 82 : so missing crc maybe you can find this bug it faster Op wo 19 jan. 2022 om 22:38 schreef Maxie D. Schmidt < ***@***.***>:

…

@lvandenb <https://github.com/lvandenb> Do you think the code is ready to file the pull request? It definitely resolves #302 <#302>. — Reply to this email directly, view it on GitHub <#313 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAXQJ7V4XZSESFIIVKAQVWLUW4VNBANCNFSM5LXDYDTA> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. You are receiving this because you were mentioned.Message ID: ***@***.***>

[maxieds]

@lvandenb
I believe it is fixed now with the latest commit. Please verify (frame 208):

[lvandenb]

@maxie, ok, almost. but I really think the crc of this answer is calulated over 6A 82 I guess the answer should be 0A 01 6A 82 4D EF instead of 0A 01 6A 82 9F 21 ?

[maxieds]

@lvandenb
I cannot verify the precise results you are getting because the scriptor utility prepends different prologue bytes. The output of running scriptor on the same command inner data does show an improvement and output the recognized SW error bytes as File Not Found. I assume this will now work on your setup as well. Please test with the latest commit to my branch.

You were right. I computed the CRC bytes on just the data part of the buffer before prepending the prologue back to it prior to returning. This was actually a point of confusion for me initially. I thought that it might want a consistency check on just the data for application processing.

At any rate, cheers! It appears to be working. 😺

[lvandenb]

Ok this is looking good.

right now only
[60804] CODEC RX DATA: 0B 01 00 CA 7F 68 00 73 73 (read data )
[60804] CODEC TX DATA: 0B 01 6A 81 6D C1 (Function not supported)

but a real desfire ev1 card responds
0B 01 6D 00 E3 19 (6D00 : Instruction code not supported or invalid)

it seems to work, but sometimes it returns a NAK.
[29540] CODEC RX DATA: 26
[29540] CODEC TX DATA: 44 03
[29645] CODEC RX DATA: 26
[29645] CODEC TX DATA: 44 03
[29649] CODEC RX DATA: 93 20
[29649] CODEC TX DATA: 88 08 AA B0 9A
[29654] CODEC RX DATA: 93 70 88 08 AA B0 9A 21 91
[29654] CODEC TX DATA: 24 D8 36
[29657] CODEC RX DATA: 95 20
[29657] CODEC TX DATA: F5 D9 1D AC 9D
[29662] CODEC RX DATA: 95 70 F5 D9 1D AC 9D 61 0A
[29662] CODEC TX DATA: 20 FC 70
[29665] CODEC RX DATA: E0 81 B8 62
[29665] CODEC TX DATA: 06 75 00 81 02 80 66 FD
[29691] CODEC RX DATA: 0A 01 00 A4 04 00 0B A0 00 00 03 97 43 49 44 5F 01 00 9E 32
[29691] CODEC TX DATA: 0A 01 6A 82 4D EF
[29694] CODEC RX DATA: 0B 01 00 CA 7F 68 00 73 73
[29694] CODEC TX DATA: 0B 01 6D 00 E4 19 ( just changed in code )
[29698] CODEC RX DATA: 0A 01 00 A4 04 00 09 A0 00 00 03 08 00 00 10 00 04 90
[29698] CODEC TX DATA: 0A 01 6A 82 4D EF
[29702] CODEC RX DATA: 0B 01 00 A4 04 00 09 A0 00 00 03 97 42 54 46 59 DD CD
[29702] CODEC TX DATA: 0B 01 6A 82 F6 F3
[29706] CODEC RX DATA: 0A 01 00 A4 04 00 0B A0 00 00 03 97 43 49 44 5F 01 00 9E 32
[29706] CODEC TX DATA: 0A 01 6A 82 4D EF
[29709] CODEC RX DATA: 0B 01 00 CA 7F 68 00 73 73
[29709] CODEC TX DATA: 0B 01 6D 00 E4 19
[29713] CODEC RX DATA: 0A 01 00 A4 04 00 09 A0 00 00 03 08 00 00 10 00 04 90
[29713] CODEC TX DATA: 0A 01 6A 82 4D EF
[29801] CODEC RX DATA: BA 01 37 C8 ( NAK)
[
this means "an invalid block is received or a FWT time-out occurs"
anyway this should be solved by

Rule 11. When an R(ACK) or an R(NAK) block is received, if its block number is equal to the PICC’s current block
number, the last block shall be re-transmitted.

so maybe I'll wait for the proxmark now, to compare timings.

[maxieds]

@lvandenb
What do you think about creating the pull request to fix the start of this issue and #302 right now? Maybe we should start a new thread about more subtle bugs in the DESFire implementation like the one you just pointed out.

[lvandenb]

@maxie
yes, we can close these now.
its another level now.

[maxieds]

@lvandenb
Please open a new issue for incremental debugging of DESFire emulation and paste the previous message with the data showing an incorrect response there.

Thanks again for all the help debugging and testing.

[maxieds]

@lvandenb
I have been looking at the last command discrepancy you noted. The LE field in the command is zero, correct? That might cause an error in this code. I have to look at it more carefully.

Are you planning to do more DESFire testing with the Chameleon once your Proxmark arrives?

[fptrs]

resolved by #314

[colinoflynn]

I'll try to give it a check this weekend - I may try to port my changes to that PR as well if I get change, but can at least check it didn't seem to break anything on the base code. Thanks!

[maxieds]

@colinoflynn @david-oswald
Any updates with testing? Any chance this PR can get merged soon? The Spring 2022 semester at GT is over. This was my RA project for the term. It would be nice to see it in production in case anyone here asks. 😺

[lvandenb]

Finally got some time, but I have an issue with the Makefile now
git https://github.com/maxieds/ChameleonMini.git
DESFire-AuthISO-Patch

$ make desfire
../LUFA/Build/lufa_build.mk:131: The XMEGA device support is currently EXPERIMENTAL (incomplete and/or non-functional), and is included for preview purposes only.
Makefile:273: *** recipe commences before first target. Stop.

[maxieds]

@lvandenb
I just tried compiling the sources with make desfire on MacOS with no problems. The trailing lines after the build completes are

 [OBJCPY]  : Extracting HEX file data from "Chameleon-Mini.elf"
avr-objcopy -O ihex -R .eeprom -R .fuse -R .lock -R .signature --set-section-flags=.flashdata="alloc,load" Chameleon-Mini.elf Chameleon-Mini.hex
 [OBJCPY]  : Extracting EEP file data from "Chameleon-Mini.elf"
avr-objcopy -O ihex -j .eeprom --set-section-flags=.eeprom="alloc,load" --change-section-lma .eeprom=0 --no-change-warnings Chameleon-Mini.elf Chameleon-Mini.eep || exit 0
 [OBJCPY]  : Extracting BIN file data from "Chameleon-Mini.elf"
avr-objcopy -O binary -R .eeprom -R .fuse -R .lock -R .signature --set-section-flags=.flashdata="alloc,load" Chameleon-Mini.elf Chameleon-Mini.bin

Chameleon-Mini.elf  :
section                       size       addr
.flashdata                 0x10000    0x10000
.spmhelper                    0x14    0x21fe0
.text                       0xe65a        0x0
.data                        0x162   0x802000
.bss                         0xc6d   0x802162
.eeprom                       0x64   0x810000
.comment                      0x26        0x0
.note.gnu.avr.deviceinfo      0x40        0x0
.debug_aranges               0x160        0x0
.debug_info                 0x29f1        0x0
.debug_abbrev               0x2708        0x0
.debug_line                  0x71e        0x0
.debug_str                  0x1b33        0x0
Total                      0x269b1


   text	   data	    bss	    dec	    hex	filename
 0xe65a	  0x1c6	  0xc6d	  62605	   f48d	Chameleon-Mini.elf

AVR Memory Usage
----------------
Device: Unknown

Program:   59324 bytes
(.text + .data + .bootloader)

Data:       3535 bytes
(.data + .bss + .noinit)

EEPROM:      100 bytes
(.eeprom)

The warning from the LUFA make script is normal. It has been printed for years. Looking at line 273 of the Makefile suggests a couple of things. Please fill in more details:

• What platform are you working in?
• What is your terminal and shell? What output do you get running which bash?

A quick fix is to use the binaries I just compiled for testing: current-build.zip

Happy to follow up otherwise.

[colinoflynn]

I finally got around to trying this - I got the same Makefile:273: *** recipe commences before first target. Stop. error (using WSL). it seems to be the SHELL:=$(shell which bash) part of the Makefile line 273, I just removed that and it built OK:

check_size: SHELL:=$(shell which bash)

It doesn't look like the SHELL variable was used there and I got the expected size print. On to functional testing...

[colinoflynn]

I ran the test by just compiling with make desfire and make desfire-dev (I tried both). The only configuration I did was setting python chamtool.py -p COM4 -c mf_desfire, and I'd check if it was still responding with python chamtool.py -p COM4 -U to print the UID in use.

With this configuration, I see:

• Using the command sequence in @maxieds March 30 example, and running that on my pm3 (the full 'hw dbg -4'... etc) works. I get the same output showing successful authentication.
• Using just the hf mfdes auth command without first doing the debug stuff gives me an error - is this a timing issue or just some invalid thing? It looks like the only difference was the debug stuff in pm3 being enabled, it didn't look like any differences in the actual authentication? Here is the output:

[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
[!!] Desfire AID select error.
[+] Setting ISODEP -> inactive
[-] Select or authentication AID 000000 failed. Result [202] Can't select application by ISO ID.

Trying to use hf mfdes info causes the ChamelonMini to lock up - it stops responding to my ChamTool requests until I power cycle it. in pm3 I see:

[usb] pm3 --> hf mfdes info
[#] pcb_blocknum 0 == 2
[#] [WCMD <--: : 08/08] 02 90 60 00 00 00 14 98
[#] fukked
[#] switch_off
[!] Command unsuccessful

It looks like it's locking up on GET VERSION:

[=] downloading tracelog data from device
[+] Recorded activity (trace len = 178 bytes)
[=] start = start of start frame end = end of frame. src = source of transfer
[=] ISO14443A - all times are in carrier periods (1/13.56MHz)

      Start |        End | Src | Data (! denotes parity error)                                           | CRC | Annotation
------------+------------+-----+-------------------------------------------------------------------------+-----+--------------------
          0 |        992 | Rdr |52                                                                       |     | WUPA
       2100 |       4468 | Tag |44  03                                                                   |     |
       7040 |       9504 | Rdr |93  20                                                                   |     | ANTICOLL
      10548 |      16436 | Tag |88  08  19  ad  34                                                       |     |
      19072 |      29600 | Rdr |93  70  88  08  19  ad  34  9a  9d                                       |  ok | SELECT_UID
      30644 |      34164 | Tag |24  d8  36                                                               |     |
      35584 |      38048 | Rdr |95  20                                                                   |     | ANTICOLL-2
      39092 |      44916 | Tag |3b  4b  ed  57  ca                                                       |     |
      47616 |      58080 | Rdr |95  70  3b  4b  ed  57  ca  b9  c5                                       |  ok | SELECT_UID-2
      59188 |      62772 | Tag |20  fc  70                                                               |     |
      64512 |      69280 | Rdr |e0  80  31  73                                                           |  ok | RATS
      70324 |      77364 | Tag |06  75  00  81  02  80                                                   | !crc|
      94976 |     104352 | Rdr |02  90  60  00  00  00  14  98                                           |  ok | GET VERSION
[usb] pm3 -->

Anyway the authentication code seems to be working per the instructions & that is great! And still useful for me to build on this for MFP.

[maxieds]

@colinoflynn
See if the latest commit works for you? An up to date version of the binaries is here:
current-build.zip

[colinoflynn]

Hi @maxieds - this seemed to get further, testing shows this result. It does still lock up (stops responding on ChamTool). For some reason I don't get any useful output with hf mfdes list (like I did before).

[usb] pm3 --> hf mfdes info

[=] ---------------------------------- Tag Information ----------------------------------
[+]               UID: 08 71 98 85 E4 07 E9
[+]      Batch number: 00 00 00 00 00
[+]   Production date: week 00 / 2000

[=] --- Hardware Information
[=]    raw: 63000000000000
[=]      Vendor Id: Pragmatic Printing Ltd. UK
[=]           Type: 0x00
[=]        Subtype: 0x00
[=]        Version: 0.0 ( DESFire MF3ICD40 )
[=]   Storage size: 0x00 ( 1 bytes )
[=]       Protocol: 0x00 ( Unknown )

[=] --- Software Information
[=]    raw: C1A0C900000000
[=]      Vendor Id: no tag-info available
[=]           Type: 0xA0
[=]        Subtype: 0xC9
[=]        Version: 0.0
[=]   Storage size: 0x00 ( 1 bytes )
[=]       Protocol: 0x00 ( Unknown )

[=] --------------------------------- Card capabilities ---------------------------------
[#] error DESFIRESendRaw
[#] error DESFIRESendRaw
[#] error DESFIRESendRaw
[#] Card didn't answer to CL1 select all
[!!] APDU: No APDU response
[#] error DESFIRESendApdu Unknown error
[+] ------------------------------------ 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

I'll see if I can get better debug output to show what is giving it problems. BTW I forgot you mentioned missing a proxmark at one point, if can help loan one if helpful let me know.

The authentication side seems to work great, so still major improvements overall. Also the build worked OK now for me too from a clean checkout.

[maxieds]

@colinoflynn
I have some good news to report on progress:

[usb] pm3 --> hf mfdes info

[=] ---------------------------------- Tag Information ----------------------------------
[+]               UID: 08 61 44 FE B4 2B F9 
[+]      Batch number: 00 00 00 00 00 
[+]   Production date: week 00 / 2000

[=] --- Hardware Information
[=]    raw: EC720000000000
[=]      Vendor Id: no tag-info available
[=]           Type: 0x72
[=]        Subtype: 0x00
[=]        Version: 0.0 ( DESFire MF3ICD40 )
[=]   Storage size: 0x00 ( 1 bytes )
[=]       Protocol: 0x00 ( Unknown )

[=] --- Software Information
[=]    raw: 91C1ACC7000000
[=]      Vendor Id: no tag-info available
[=]           Type: 0xC1
[=]        Subtype: 0xAC
[=]        Version: 199.0
[=]   Storage size: 0x00 ( 1 bytes )
[=]       Protocol: 0x00 ( Unknown )

[=] --------------------------------- Card capabilities ---------------------------------
[#] Halt error
[#] Card didn't answer to CL1 select all

I introduced a bug somewhere into the auth command:
hf mfdes auth -n 0 -t 3tdea -k 000000000000000000000000000000000000000000000000 -v -c native -a
I did notice earlier today as you pointed out above (before the latest commit with new fixes) that the auth command is buggy without the debugging options getting set by my script. This behavior has now changed to:

[usb] pm3 --> script run test-mfdes-auth.cmd 
[+] executing Cmd test-mfdes-auth.cmd
[+] args ''
[usb|script] 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<< 7E 4B 16 
[!!] 🚨 Command (af) ERROR: 0x7e
[#] error DESFIRESendRaw Length of command string invalid
[!!] 🚨 Desfire authenticate error. Result: [7] Sending auth command failed
[+] Setting ISODEP -> inactive
[-] ⛔ Select or authentication AID 000000 failed. Result [7] Sending auth command failed
[usb|script] 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 )
[usb|script] 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
[#]   Debug log level......... 4 ( extended )
[#] Card didn't answer to select
[!!] 🚨 Desfire AID select error.
[+] Setting ISODEP -> inactive
[-] ⛔ Select or authentication AID 000000 failed. Result [202] Can't select application by ISO ID.

I should have some more time to finish up and get the auth command working tonight or tomorrow :)

Anything else I have missed in all of the excellent feedback you gave above?

[maxieds]

@colinoflynn
Please check with the latest commit to verify. This is what I get with the PM3 after building with make desfire-dev:

[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 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 4F 8A 44 7D AE 83 
[+]      Batch number: AE 83 CE E4 A5 
[+]   Production date: week db / 20f1

[=] --- 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 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

[colinoflynn]

With both make desfire and make desfire-dev I get this error:

BuildScripts/lufa_build_extra.mk:131: The XMEGA device support is currently EXPERIMENTAL (incomplete and/or non-functional), and is included for preview purposes only.
basename: extra operand ‘../LUFA/Drivers/USB/Core/DeviceStandardReq.c’
Try 'basename --help' for more information.
make: *** No rule to make target 'Bin/HIDParser.o', needed by 'Chameleon-Mini.elf'.  Stop.

There's no line number so not sure (it looks like maybe from an included makefile?), do you know offhand where things were tweaked? I'm building it on Ubuntu (using WSL).

[maxieds]

@colinoflynn
Please check one more time with the latest commit. If that doesn't work, you can try testing with the binaries I just compiled in this archive: latest-desfire-build.zip.

BTW, thanks for the proxmark offer. My advisor gave me some money from her grant this Spring to buy one :)

[colinoflynn]

Got it! Will test those binaries - the output now fixes the basename problem, but I still get:

make: *** No rule to make target 'Bin/HIDParser.o', needed by 'Chameleon-Mini.elf'.  Stop.

How are you building that doesn't trigger the errors?

[maxieds]

@colinoflynn
Hmmm. Did you try running make clean first? If not, I will try to debug with my Arch Linux box later.

[maxieds]

Nevermind. It should work now.

It looks like brew distinguishes the standard system make with its version called gmake on MacOS. The Linux make command is (looks like) equivalent to gmake on Mac. Now we know...

[maxieds]

The make build problems should now all be resolved. As a bonus, running make desfire or make desfire-dev should be quicker on the average: I convinced the Makefile to not rebuild the LUFA library objects at each fresh compile of the Chameleon sources. Some might also checkout the predefined custom build targets in this build script to start on the idea from #283.

@colinoflynn @lvandenb
I have some technical problems with the code in the latest commit interfacing with the USB/PCSC ACS-122U reader. The PM3 compatibility still works, but the USB reader will not recognize the Chameleon with CONFIG=MF_DESFIRE like it did several months ago. I can trace the problem down to where the reader/PCD issues the Chameleon a DESELECT (0x2E) command:
(Updated to include the CMLD screenshot on my phone)

What response should it actuay be sending back? This happens after the anticollision loop and RATS are satisfied. My start to fixing this issue is found here -- all commented out again after failed tests of the code.

[maxieds]

Here are current binary builds: latest-desfire-build.zip

[colinoflynn]

I'm travelling for some events - I did throw PM3/CM in my bag in case I've got time, but it's likely I'll be away from this for a couple weeks, will update if I get a chance to try. Unfortunately no other reader with me so on the final problem I can take a look once I've back to office.

[maxieds]

If anyone else wants to help out with testing PR #319, it would be nice to add some example DESFire configuration dumps generated with non-default interactions with the Chameleon. Also, posting this request as a follow up on the PR thread.

[maxieds]

@david-oswald @fptrs
I think we can close this issue now that PR #319 is merged. I will check the latest DESFire firmware build with my two local PCSC external USB readers later tonight. If there are still problems getting pcsc_scan to recognize the Chameleon running CONFIG=MF_DESFIRE, I will start a new issue where we can follow up. 😸

[colinoflynn]

Thanks for more updates! I'll still try and test them, my trip got messed up due to COVID/travel complications so I still didn't get around to it... but if I find any problems will work through them on new issue.