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 https://github.com/emsec/ChameleonMini/issues/302.

— Reply to this email directly, view it on GitHub https://github.com/emsec/ChameleonMini/issues/313#issuecomment-1016890518, 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

[lvandenb]

Yes, I'll do further testing The proxmark is on its way now. Expected somewhere next week

Maybe the NACK can be solved, but I want to know why there is a BA 01 37 C8 ( NACK) .
The log timing of 1ms is too big. the unit is 128/fc, about 10µs.

[david-oswald]

Hi, I just tried the most recently merged PR with a Proxmark (using the current GIT head of the RRG proxmark), first trying to get the application list in different communication modes:

[usb] pm3 --> hf mfdes getaids -a -v -m plain
[=] Key num: 0 Key algo: des Key[8]: 00 00 00 00 00 00 00 00
[=] Secure channel: n/a Command set: niso Communication mode: plain
[+] Setting ISODEP -> inactive
[+] Setting ISODEP -> NFC-A
[=] Anticollision ok
[=] Auth: cmd: 0x1a keynum: 0x00
[+] >>>> 90 1A 00 00 01 00 00
[!!] 🚨 APDU: No APDU response
[!!] 🚨 Desfire authenticate error. Result: [1] Sending auth command failed
[+] Setting ISODEP -> inactive
[usb] pm3 --> hf mfdes getaids -a -v -m plain -c native
[=] Key num: 0 Key algo: des Key[8]: 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
[=] Anticollision ok
[=] Auth: cmd: 0x1a keynum: 0x00
[+] raw>> 1A 00
[!!] 🚨 Desfire authenticate error. Result: [1] Sending auth command failed
[+] Setting ISODEP -> inactive

It seems to fail on the authentication step. I got a log from the Chameleon, this is what Chamlog has to say:

38784 ms <+38784 ms>:UNKNOWN                      (2   bytes) [1159                ]
38856 ms <   +72 ms>:CODEC RX                     (1   bytes) [52                  ]
38856 ms <    +0 ms>:CODEC TX                     (2   bytes) [4403                ]
38857 ms <    +1 ms>:CODEC RX                     (2   bytes) [9320                ]
38857 ms <    +0 ms>:CODEC TX                     (5   bytes) [880800e262          ]
38858 ms <    +1 ms>:CODEC RX                     (9   bytes) [9370880800e2620c76  ]
38858 ms <    +0 ms>:CODEC TX                     (3   bytes) [24d836              ]
38859 ms <    +1 ms>:CODEC RX                     (2   bytes) [9520                ]
38859 ms <    +0 ms>:CODEC TX                     (5   bytes) [0a6a7a968c          ]
38861 ms <    +2 ms>:CODEC RX                     (9   bytes) [95700a6a7a968cf878  ]
38861 ms <    +0 ms>:CODEC TX                     (3   bytes) [20fc70              ]
38861 ms <    +0 ms>:CODEC RX                     (4   bytes) [e0803173            ]
38861 ms <    +0 ms>:CODEC TX                     (8   bytes) [06750081028066fd    ]
38886 ms <   +25 ms>:CODEC RX                     (10  bytes) [02901a0000010000e35c]
44378 ms < +5492 ms>:CODEC RX                     (1   bytes) [52                  ]
44378 ms <    +0 ms>:CODEC TX                     (2   bytes) [4403                ]
44379 ms <    +1 ms>:CODEC RX                     (2   bytes) [9320                ]
44379 ms <    +0 ms>:CODEC TX                     (5   bytes) [880800e262          ]
44380 ms <    +1 ms>:CODEC RX                     (9   bytes) [9370880800e2620c76  ]
44380 ms <    +0 ms>:CODEC TX                     (3   bytes) [24d836              ]
44381 ms <    +1 ms>:CODEC RX                     (2   bytes) [9520                ]
44381 ms <    +0 ms>:CODEC TX                     (5   bytes) [0a6a7a968c          ]
44383 ms <    +2 ms>:CODEC RX                     (9   bytes) [95700a6a7a968cf878  ]
44383 ms <    +0 ms>:CODEC TX                     (3   bytes) [20fc70              ]
44383 ms <    +0 ms>:CODEC RX                     (4   bytes) [e0803173            ]
44383 ms <    +0 ms>:CODEC TX                     (8   bytes) [06750081028066fd    ]
44408 ms <   +25 ms>:CODEC RX                     (6   bytes) [0b001a00f4fe        ]

So it seems the codec does not reply to the auth attempt at all in both communication modes, any quick ideas what I might be doing wrong?

I can maybe do some more tests towards the end of next week if that helps.

[maxieds]

@david-oswald You might have used a case I didn't test when writing the first part of the implementation in #287. The LibNFC test code here uses the AuthAES command 0xAA. That should definitely be working. Does your query go through if you replace 0x1A with 0xAA? The DESFire source to handle the command 0x1A (as you used above) is here. If I have some time later today, I will try to test with the AuthISO command to see if I can debug it. It will be helpful to know if your Proxmark reports success on 0xAA though.

[lvandenb]

I think Authenticate ISO will be the last to check ? Next week I'll try natve and wrapped Native and AES.

the 0x0A Authenticate would need the first to work, because an empty card always authenticates with 0x0A, with desfire key 16 times 00 (which has to be considered as single des, because 2nd 8 bytes equals the first 8 bytes)

to be able to test the Authenticate AES 0xAA or ISO 0x1A (on the PICC), we would need the Authenticate command 0X0A key 0 , followed by ChangeKey command (0x54) , key 0x80 (to AES) or Key 0x40 to 3des.

[maxieds]

Maybe a second or third pair of eyes can help me figure out what's going wrong with the code in my new branch. Perhaps OpenSSL on the host side is producing weird values?

[maxieds]

@david-oswald I believe that the AuthISO(0x1A) command is now working with the most recent commits to my local branch. Can you please test to confirm it works with the Proxmark?

I wrote LibNFC test code that runs on my Linux host (see Software/ directory here). It's kind of strangely behaving running off my CMLD application connected to my phone. I have better luck getting the command to go through with the Chameleon on battery. The strange thing is that almost always, if I run an AuthAES(0xAA) and that succeeds, then immediately after the AuthISO(0x1A) will go through:

$ cd Software/DESFireLibNFCTesting
$ make
$ ./Bin/TestAuthenticateAES128.exe
## Output ...
$ ./Bin/TestAuthenticateISO.exe
## More output ...

I wonder if there is a bug in the code where it wants the AES auth procedure to do what @lvandenb noted that the AuthLegacy(0x0A) should be doing? Otherwise, the implementation for 3DES is less efficient than the AES HW enhanced code? I'm not sure what it's doing there...

I am going to try to get the legacy auth code tested and working this morning. If some testers can confirm that it all goes well with them as well, I think we can file another PR over the next couple of days to enhance the DESFire emulation support. 😸

[maxieds]

If it's easier, once I get the legacy authentication command working, I can upload a binary of the new firmware build so testers do not need to mess with cloning and building the code in my local branch. Just in case this gets more folks motivated, here's how to do that yourselves:

$ git clone https://github.com/maxieds/ChameleonMini.git
$ cd ChameleonMini
$ git checkout DESFire-AuthISO-Patch
$ cd Firmware/Chameleon-Mini
$ make desfire
$ sudo avrdude -c flip2 -p ATXMega128A4U -B 60 -P usb -U application:w:Chameleon-Mini.hex:i -U eeprom:w:Chameleon-Mini.eep:i

And if I push more changes into the branch this morning, update the sources with:

$ git pull

[maxieds]

Anyone tried this out yet? Should I just go ahead and file the PR? The code in my branch definitely fixes some problems with two of the auth command variants and adds some functionality into the Software / LibNFC-based test suite.

[david-oswald]

I tried with various variations on the proxmark cmdline, but it always seems to fail. I have not much time to debug this today/tomorrow unfortunately...

[maxieds]

@david-oswald What sort of exchanges does the Proxmark expect? Does it need to be MAC'ed and encrypted for all commands handled after the authentication? The MAC'ed exchange is something on a TODO list to add to the source. Right now all the emulation support can handle is cleartext exchange. It was very spec dependent so I could use some pointers about what it needs to be doing. IIRC, it is not clearly documented, at least publicly, which exchange protocol, crypto algorithm, etc. to invoke when presented with ISO / versus native wrapped / other handshakes. The current implementation defaults to non-MAC'ed cleartext transfers only.

[david-oswald]

@maxieds The Proxmark DESFire command set is documented here: https://github.com/RfidResearchGroup/proxmark3/blob/master/doc/desfire.md

I think the Proxmark reader code is also a good "documentation in code" for the future.

I tried many variations of channel, iso/niso/native, crypto, etc. One example of just a plain auth:

[usb] pm3 --> hf mfdes auth -n 0 -t des -k 0000000000000000 -f none -v -c native -a
[=] Key num: 0 Key algo: des Key[8]: 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
[!!] 🚨 Desfire authenticate error. Result: [1] Sending auth command failed
[+] Setting ISODEP -> inactive
[-] ⛔ Select or authentication AID 000000 failed. Result [1] Sending auth command failed
[usb] pm3 --> hf mfdes auth -n 0 -t des -k 0000000000000000 -f none -v -c niso -a
[=] Key num: 0 Key algo: des Key[8]: 00 00 00 00 00 00 00 00
[=] Secure channel: n/a Command set: niso Communication mode: plain
[+] Setting ISODEP -> inactive
[+] Setting ISODEP -> NFC-A
[=] AID 000000 is selected
[=] Auth: cmd: 0x1a keynum: 0x00
[+] >>>> 90 1A 00 00 01 00 00
[!!] 🚨 APDU: No APDU response
[!!] 🚨 Desfire authenticate error. Result: [1] Sending auth command failed

[maxieds]

@david-oswald I think I might have tracked down the problem: [+] raw>> 1A 00 The latest commit to my local working branch adds support for non-wrapped native commands. It should also provide a speedup in invoking the (C language level) instruction handlers. Before we were just doing a linear compare over unsorted instruction codes. Let me know if it works now.

Also, thank you for the references. I found some solid (Java, mostly) sources that will help get the various MAC'ed and enciphered communication settings working. Still under development. Thanks for the help testing.

[david-oswald]

Not really fixing it - I always also try "native ISO" as seen above (the -c param) and that doesn't work either... Is there any logging I could turn on to help you debug further?

[usb] pm3 --> hf mfdes auth -n 0 -t des -k 0000000000000000 -f none -v -c native -a
[=] Key num: 0 Key algo: des Key[8]: 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
[!!] 🚨 Desfire authenticate error. Result: [1] Sending auth command failed
[+] Setting ISODEP -> inactive
[-] ⛔ Select or authentication AID 000000 failed. Result [1] Sending auth command failed

[usb] pm3 --> hf mfdes auth -n 0 -t des -k 0000000000000000 -f none -v -c niso -a
[=] Key num: 0 Key algo: des Key[8]: 00 00 00 00 00 00 00 00
[=] Secure channel: n/a Command set: niso Communication mode: plain
[+] Setting ISODEP -> inactive
[+] Setting ISODEP -> NFC-A
[=] AID 000000 is selected
[=] Auth: cmd: 0x1a keynum: 0x00
[+] >>>> 90 1A 00 00 01 00 00
[!!] 🚨 APDU: No APDU response
[!!] 🚨 Desfire authenticate error. Result: [1] Sending auth command failed
[+] Setting ISODEP -> inactive
[-] ⛔ Select or authentication AID 000000 failed. Result [1] Sending auth command failed

[maxieds]

First of all, enable these settings in the Makefile when you compile the firmware:

SETTINGS  += -DDESFIRE_DEFAULT_TESTING_MODE=1
SETTINGS  += -DDESFIRE_CRYPTO1_SAVE_SPACE

I personally get a lot out of using the CMLD app I wrote with the (Droid) phone connected to the Chameleon over a wired serial USB connection. If you turn on the LIVE logging feature, then you should get quite a bit of formatted output while the auth command is in transit. You can install CMLD via the Google Play Store as usual for free. Here is a screenshot of where to turn on the LIVE logging from the phone navigation and what I get running the 0x1A auth with LibNFC on the host with logging to the phone:

I still wonder if you can get it to go through by using AES auth 0xAA on the Proxmark? I have luck with that running in front of the other Auth commands with the LibNFC test code. If that for some reason does work, then the list of possibilities for bugs to check in the code is substantially narrowed... Please also remember to run git pull for my branch and rebuild. I just pushed something else that I have been working on.

[maxieds]

I have another quick implementation question. Are the rndA and rndB buffers used for authentication with AES and 3K3DES supposed to be 16 bytes? Right now the implementation I have uses 8 byte buffers for rndA and rndB. If they should be 16 bytes instead, I need to modify my working code.

[maxieds]

The Proxmark3 source code indicates that we need to use 16 bytes for rndA and rndB. I will change the source code.

[lvandenb]

8 byte for DES or 2K3DES , 16 byte 3k3des and AES.

[maxieds]

@david-oswald Do you mind checking the ISO authentication again with the latest commit to my local branch? I put a lot of effort in this week debugging...

[lvandenb]

can this issue be reopened ? Maybe move the authentication 0x1A to another issue ? (0x1a should give an error on initial Desfire EV1 , so I would need the authenticate native and changekey first. But the windows tools always start with detection. So I cannot test the next things with my current pc/sc tools )

=> there are still some small issues with 7816 responses 6a 82 should be for file not found, the 6a 81 for unknown instruction, but then it starts responding both ?

also some nxp tools seem to to a "keep alive" with ack/nack PCD sends NACK, and PICC responds with ACK for next block. (Real DesfireEV1 card , and trace times in delta microseconds)

[david-oswald]

@david-oswald Do you mind checking the ISO authentication again with the latest commit to my local branch? I put a lot of effort in this week debugging...

@maxieds I did try that, but something in your recents commits to that branch seems to have introduced a new problem - on doing an auth or even just aid list, the Chameleon completely crashes and does not respond to anything further. I also noticed that the output of cmdline commands like help appears truncated.

[maxieds]

@david-oswald I noticed the crashes with the legacy authenticate. Not sure if that is what you were using. Can you try again with the modifications in the latest commit? I am getting my Proxmark RDV4 finally shipped out to me in a week or two. That will let me do this sort of bothersome testing / back and forth for myself when it arrives.

@lvandenb I will try to get to your issues with the ISO7816 return codes later on tonight.

[maxieds]

@lvandenb Does the legacy authenticate need to be done with DES, or can it be set to default to 3DES? The current implementation uses 3DES.

[lvandenb]

It is 2k3des. But when first 8 bytes equal second 8, it is Des. Also native 2k3des is done differently than iso3k3des. Native is always EEE on card, even for decryption.

Op za 12 feb. 2022 04:18 schreef Maxie D. Schmidt @.***

:

@lvandenb https://github.com/lvandenb Does the legacy authenticate need to be done with DES, or can it be set to default to 3DES? The current implementation uses 3DES.

— Reply to this email directly, view it on GitHub https://github.com/emsec/ChameleonMini/issues/313#issuecomment-1036971178, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAXQJ7QDHDVKD6FWVOYTWGDU2XGP5ANCNFSM5LXDYDTA . 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 The latest commit to my local branch appears to pass all of the LibNFC-based tests I put it through with the ACR reader. It should be ready for you or @david-oswald to test with the Proxmark. Again, sorry for having to rely so much on you for doing testing I should be able to do. My Proxmark is arriving on Tuesday...

The ISO-7816 return codes problems you mentioned above are on my TODO, but not yet urgent, coding projects list.

[maxieds]

@lvandenb

=> there are still some small issues with 7816 responses 6a 82 should be for file not found, the 6a 81 for unknown instruction, but then it starts responding both ?

Are you sure that all of the RDR exchanges are getting accurately logged? It looks like the mix-up in SW bytes returned corresponds to two different transaction types. Check the prologue bytes on the TAG responses. The return codes seem accurate for the prologue bytes associated with the previous commands with those same prologue bytes. IDK why it would be non-deterministic in that way otherwise. Maybe the Chameleon is dropping some of the logs or some of the RDR incoming commands if new ones arrive to process next? We could look into the codec code, but there are other devs that would know those internals better than I do.

Do you mind checking the latest commit to my local branch to see if the ACK/NAK phenomenon on the NXP-based readers is now resolved?

[lvandenb]

Sorry, now I noticed that the two switches on the PM3 were left in the worst position (125 kHz and worst Q factor). I'll do new testing with latest Repo.

Op za 12 feb. 2022 14:07 schreef Maxie D. Schmidt @.***

:

@lvandenb https://github.com/lvandenb

=> there are still some small issues with 7816 responses 6a 82 should be for file not found, the 6a 81 for unknown instruction, but then it >starts responding both ?

Are you sure that all of the RDR exchanges are getting accurately logged? It looks like the mix-up in SW bytes returned corresponds to two different transaction types. Check the prologue bytes on the TAG responses. The return codes seem accurate for the prologue bytes associated with the previous commands with those same prologue bytes. IDK why it would be non-deterministic in that way otherwise. Maybe the Chameleon is dropping some of the logs or some of the RDR incoming commands if new ones arrive to process next? We could look into the codec code, but there are other devs that would know those internals better than I do.

Do you mind checking the latest commit to my local branch to see if the ACK/NAK phenomenon on the NXP-based readers is now resolved?

— Reply to this email directly, view it on GitHub https://github.com/emsec/ChameleonMini/issues/313#issuecomment-1037221193, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAXQJ7UD546FX5NTTQKA6XDU2ZLS3ANCNFSM5LXDYDTA . 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 Ok. As usual, all of the help getting the specs correct and with testing is much appreciated. Note that I just pushed another round of commits. That should be it for a while until I hear back that something is not working.

I think we're running up against the data/text size barrier quickly again. To get all of the CommModes that DESFire tags support implemented, there are still some hashing and checksum functions that will need to be added. This will take up even more space...

Do you have time to check the authentication commands that David was trying to run last week with your Proxmark? Once that works, I think another PR should get put in. There was an easy-to-spot (in hindsight) memory error that is still in the main (emsec) sources. The authenticate commands were doing something like

uint8_t **Key;
*Key = &SessionKey; // SessionKey is an extern'ed uint8_t array
ReadInKeyData(*Key); 

It took me forever to track that down! Just some screwed up fundamentals of pointers in C, I suppose 😃

[maxieds]

@lvandenb Do you mind testing the latest firmware commit with your PM3? The commands I am running are:

hw dbg -4
prefs set clientdebug --full
data setdebugmode -2
hf mfdes auth -n 0 -t des -k 0000000000000000 -v -c native -a

I am not able to test this patch with my PM3 right now. I am going to get the battery pack for my device since it is being very temperamental with my self-powered USB hub. I think the firmware should finally work.