search

emsec / ChameleonMini

The ChameleonMini is a versatile contactless smartcard emulator compliant to NFC. The ChameleonMini was developed by https://kasper-oswald.de. The device is available at https://shop.kasper.it. For further information see the Getting Started Page https://rawgit.com/emsec/ChameleonMini/master/Doc/Doxygen/html/_page__getting_started.html or the Wiki tab above.
Other
1.72k stars 391 forks source link

DESFire Missing Features & Status Questions #302

Closed colinoflynn closed 2 years ago

colinoflynn commented 2 years ago

Thanks for this excellent project & the effort as well in getting DESFire support. I'm abusing that to add some minor MifarePlus support (just responding to specific requests) for a project. But it seems the DESFire support has some weird things that I was hoping to get better insight into before submitting PRs.

The DESFire answer seem to always respond as ISO14443A_APP_NO_RESPONSE, meaning a huge amount of the code is 'ignored'. This return is in https://github.com/emsec/ChameleonMini/blob/master/Firmware/Chameleon-Mini/Application/DESFire/DESFireISO14443Support.c#L231 .

There is a bug in that section of the code that MifareDesfireProcess() returns a BitCount and not a ByteCount (see https://github.com/emsec/ChameleonMini/blob/29f3d85294691c8274089436c347a30e4db5d10e/Firmware/Chameleon-Mini/Application/MifareDESFire.c#L215). Fixing this & uncommenting the code around L231 to add the CRC + return the 'real' status code seems to make things work.

There is a few other smaller changes that I required for MFP, although may also be bugs but I'd have to check (at least one is, BitCount gets mapped to an 8-bit value at one point so frames > 32 bytes will fail).

I don't have a real way to test DESFire support however so I'm not sure a PR is easy here, I could at least PR the previously mentioned bugs. I wanted to check w/ the developers on this section if the 'dead ended code' was there for a reason however, as perhaps there is larger issues I'm not aware of.

maxieds commented 2 years ago

@colinoflynn I wrote and modified most of the DESFire emulation support from @dev-zzo's fork circa 2017 last year. I do not have the ability to approve PRs for this repo, but I for one would be happy to see incremental added features and bug fixes from users. Therefore, your PR is highly welcome by me! 😃

I tested the DESFire support with an external USB connected NFC reader on Mac OS (the ACR122U, which is well supported by LibNFC). Testing code is housed here as are dumps of testing output included in one of my PRs for consistency checks against future additions to the DESFire support code.

Welcome aboard!

P.S. You can see a recent conference proceedings preprint I wrote about working on the project attached: schmidt-ftc2021-submission.pdf

P.S. (Update 2021-12-31): The tentative slides for my FTC-2021 conference talk (not given virtually, but slides and proceedings document were prepared as though I would have) are attached. The first has notes for the speaker (me), and the second is just the slides for the audience. This might be of interest to some, and certainly explains my motivations for working on the project: ftc2021-presentation-slides-with-notes.pdf ftc2021-presentation-slides.pdf

colinoflynn commented 2 years ago

Thanks for the details - I've got that same reader so can recreate some of those tests too well enough! I had seen the conference pre-print in your fork which was very helpful.

I guess you know that this support actually includes the needed framework for MFP support of other types (Plus EV1, X, etc). I may play around with how to more generically make it obvious that you can add in MFP commands easily with the framework now. I suspect a lot of people don't need full emulation of MFP cards but would be happy to see a handful of commands supported, which is "basically there" now, but might not be obvious on a quick glance at the source & status pages.

But I'll switch it into a basic PR to fix the 'easy issues' then branch out for the more serious changes.

maxieds commented 2 years ago

@colinoflynn

I have some good news: I received funding for the Spring of 2022 at GA Tech under their COVID-19 disruption funding to work as a RA on this software project (my last year, SO exciting!). This is great because I can use my official part-time hours usually spent as a TA to update the DESFire code. It is also relevant to the university as our physical (and other system) access systems via the student IDs on campus are based on a DESFire EV1 chip. I think that there are a few vulnerabilities that need to be checked out, but that is aside the issue in this thread.

Do you want to collaborate on the pull requests? That is, if you do not have them all completed by the beginning of January? I am mostly slammed until the break begins in mid December.

david-oswald commented 2 years ago

@maxieds Great to hear. I recently also played with the DESFire emulation and the new-ish DESFire support in Proxmark (using it as a reader). However it seems that Proxmark doesn't play nicely with the emulation, it failed to enumerate the AIDs etc. I will try to write a better report about this behaviour once I have time.

colinoflynn commented 2 years ago

@maxieds great, sounds like a fun project! Would be happy to collaborate on it as well - I can do the basic PR stuff, but as I mentioned there is some larger clean-up that I won't get to (as only very roughly did it). The minimal bug-fix ones are easy.

lvandenb commented 2 years ago

Today I finally got some time. I wanted to do a basic test with an USB Omnikey 5022 reader, or the NXP taginfo android applet on my samsung, just for getting the UID. But it didn't succeed.

maxieds commented 2 years ago

@Ivandenb Do you have the ability to use my Chameleon Mini Live Debugger (CMLD) application on Android with the LOGMODE=LIVE options turned on the Chameleon Mini RevG device? If so, the application's logger window will report extra debugging messages. You can also fine tune (IIRC) the firmware Makefile to report extra debugging output. CMLD is available on the Google PlayStore as free software. I'd be curious to see how far things go through with the debugging messages.

maxieds commented 2 years ago

Please also note that I did not develop / nor test the DESFire firmware with the Proxgrind manufacturer family of devices. I found that the onboard BT generated RF interference with my local NFC enabled reader. Please make sure to test with one of the KAOS RevG devices. The CMLD application is known to play well with the KAOS boards hooked up over serial USB to the Droid phone.

lvandenb commented 2 years ago

Ok, it seems getting in a loop It is a native KAOS RevG

I did not find how to export the log to my mail or a file. I see buttons, but no export id asking for file name or email.

From: Maxie D. Schmidt @.> Sent: donderdag 16 december 2021 23:13 To: emsec/ChameleonMini @.> Cc: Vandenbroucke Luc @.>; Comment @.> Subject: Re: [emsec/ChameleonMini] DESFire Missing Features & Status Questions (#302)

@Ivandenb Do you have the ability to use my Chameleon Mini Live Debuggerhttps://github.com/maxieds/ChameleonMiniLiveDebugger (CMLD) application on Android with the LOGMODE=LIVE options turned on the Chameleon Mini RevG device? If so, the application's logger window will report extra debugging messages. You can also fine tune (IIRC) the firmware Makefile to report extra debugging output. CMLD is available on the Google PlayStore as free software. I'd be curious to see how far things go through with the debugging messages.

— Reply to this email directly, view it on GitHubhttps://github.com/emsec/ChameleonMini/issues/302#issuecomment-996233748, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AAXQJ7WEFA5R3ZO46I7DUCLURJP6TANCNFSM5EDJZDBQ. Triage notifications on the go with GitHub Mobile for iOShttps://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Androidhttps://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 commented.Message ID: @.**@.>>

maxieds commented 2 years ago

@Ivandenb I am able to export the logs displayed under the "Live logging" tab to HTML and/or ASCII. The UI has gotten kind of complicated over the years. Here are screenshots to show how I did it:

To access the exported text-based logs, you will probably need to hook up to the Droid filesystem over USB with developer options and transfer them with something like Android Studio to your PC/Mac. Alternately, I find that it is easy to see things more visually, so screenshots might be useful of the logging window taken on your phone.

Hope that helps. I am happy to look at this more when I can see your logs.

lvandenb commented 2 years ago

Hereby the log. 23 77 00 0b 99 bf 98 is the uid

It is stuck somewhere, Select 1 from PCD : 93 70 88 23 77 00 dc 4b b3 is answered by 04 by the card , and should be 24 + CRC ? Next week I’ll have more time

From: Maxie D. Schmidt @.> Sent: vrijdag 17 december 2021 18:25 To: emsec/ChameleonMini @.> Cc: Vandenbroucke Luc @.>; Comment @.> Subject: Re: [emsec/ChameleonMini] DESFire Missing Features & Status Questions (#302)

@Ivandenb I am able to export the logs displayed under the "Live logging" tab to HTML and/or ASCII. The UI has gotten kind of complicated over the years. Here are screenshots to show how I did it:

[https://user-images.githubusercontent.com/22165688/146583329-49f07409-37cf-4a07-a413-c7efda3cb83e.png]https://user-images.githubusercontent.com/22165688/146583329-49f07409-37cf-4a07-a413-c7efda3cb83e.png[https://user-images.githubusercontent.com/22165688/146583330-adda62db-c4fa-41e8-a604-3713711197dc.png]https://user-images.githubusercontent.com/22165688/146583330-adda62db-c4fa-41e8-a604-3713711197dc.png

To access the exported text-based logs, you will probably need to hook up to the Droid filesystem over USB with developer options and transfer them with something like Android Studio to your PC/Mac. Alternately, I find that it is easy to see things more visually, so screenshots might be useful of the logging window taken on your phone.

Hope that helps. I am happy to look at this more when I can see your logs.

— Reply to this email directly, view it on GitHubhttps://github.com/emsec/ChameleonMini/issues/302#issuecomment-996893062, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AAXQJ7QCOUY5YRCOT3SIUJTURNW7XANCNFSM5EDJZDBQ. Triage notifications on the go with GitHub Mobile for iOShttps://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Androidhttps://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 commented.Message ID: @.**@.>>

maxieds commented 2 years ago

@colinoflynn I am finally having the time to test some of this out. I believe the Omnikey reader @lvandenb suggested in #310 is finally in my mailbox now that I am back from the holidays. Did you ever put in the pull request to fix the issue with the bit-versus-byte counts observed in the first post of this thread? If not, I will handle it (plan to) over the next few days as I test with the Omnikey readers. This is my proposed fix:

/* Quick fix to the problem pointed out by @colinoflynn in 
 * emsec/ChameleonMini issue #302: 
 * (see new usages below in the function MifareDesfireAppProcess(., .))
 */
#define __DESFire_RoundToBytes(bitCount)       ((unsigned int) (bitCount + BITS_PER_BYTE - 1) / BITS_PER_BYTE)

uint16_t MifareDesfireAppProcess(uint8_t* Buffer, uint16_t BitCount) {
    size_t ByteCount = (BitCount + BITS_PER_BYTE - 1) / BITS_PER_BYTE;
    //LogEntry(LOG_INFO_DESFIRE_INCOMING_DATA, Buffer, ByteCount);
    if(ByteCount >= 8 && DesfireCLA(Buffer[0]) && Buffer[2] == 0x00 &&
       Buffer[3] == 0x00 && Buffer[4] == ByteCount - 8) {
         return __DESFire_RoundToBytes(MifareDesfireProcess(Buffer, BitCount));
    }
    else if(ByteCount >= 6 && DesfireCLA(Buffer[0]) && Buffer[2] == 0x00 &&
            Buffer[3] == 0x00 && Buffer[4] == ByteCount - 6) {
         // Native wrapped command send without CRCA checksum bytes appended: 
         return __DESFire_RoundToBytes(MifareDesfireProcess(Buffer, BitCount));
    }
    else {
         return ISO144433APiccProcess(Buffer, BitCount);
    }
}

If the problem is still in the master branch of the firmware, I can handle fixing it with a PR I will (should) follow up on this week. It looks like the problem is still live after running git pull fork master from my local fork (here the forked branch is actually the main emsec repo)...

maxieds commented 2 years ago

I am going to spend the rest of the afternoon debugging with the Omnikey 5022CL reader. We should note that this reader is NOT compatible (from what I can see) with LibNFC. I do not see an easy way to replicate the basic functionality of nfc-anticol and other LibNFC-based utilities that I had used (on MacOS) to test the preliminary DESFire emulation support. OTOH, God it feels so liberating to be back on Linux for the new year! :)

Any suggestions on automated tools that can interface to the CCID drivers (pcscd variants to spy on raw exchanges)? I can probably just use ioctl to open the device in C and some of the CCID repo source examples to concoct something appropriate. I am just wondering if there is a quicker way? Low-level C leads to slow prototyping on my end...

colinoflynn commented 2 years ago

@maxieds I didn't end up cleaning this up sorry! Feel free to fix & push in separately, I wasn't worried about keeping 'commit credit'.

I did previously push everything into my fork on a new branch, see https://github.com/colinoflynn/ChameleonMini/commits/mfpev1bodge . There are 3 commits that cover any fixes I did but they've got some other hacky tests in there... the specific lines I remembered:

Basically there is that bits/bytes fix, once that is fixed you can "add back" the CRC and stuff (it was commented out IIRC). Also change that uin8t_t to uint16_t to allow longer packets.

If you end up fixing those I can rebuild my other hacks onto the new framework and PR some of the useful feautres (AES CMAC).

Unfortunately as you can see I had some of my "mifare plus test" code pushed at the same time. I'm not infront of office computer for a couple days so you might not want to wait on me, as I'd be at least a couple days away from pushing nicer code.

maxieds commented 2 years ago

The result of a long afternoon getting back into the DESFire code is located on this branch of my local fork. I would really appreciate some testers building from that source, which can eventually fulfill the first "getting it to work" part of @colinoflynn's branch above. This is the CMLD output trying to swipe on the Omnikey 5022CL reader:

As you can see in the logs, the reader goes through the correct sequence with the Chameleon up until we respond to its 9370|... sequence. After this, with the response I gave, I expect the reader to initiate reading the next four UID bits with a 9520|... command. It drops the conversation instead and responds again with the REQA 0x26 byte (non-wrapped). This exchange is consistently what happens on swiping the Chameleon to the Omnikey reader. Granted it is better in getting farther than before this code was modified, but still frustrating to debug. Does anyone see the problem or have suggestions?

@colinoflynn I have a couple of short points about the MFPlus and crypto code you pushed in your branch:

lvandenb commented 2 years ago

I will test this week. Once they 14333a is succesfull I can compare with a card

But at first sight, the first part of uid exchange should start with 88 ?

Luc

Met vriendelijke groeten, Luc Vandenbroucke

From: Maxie D. Schmidt @.> Sent: Sunday, January 2, 2022 2:07:54 AM To: emsec/ChameleonMini @.> Cc: lvandenb @.>; Mention @.> Subject: Re: [emsec/ChameleonMini] DESFire Missing Features & Status Questions (#302)

The result of a long afternoon getting back into the DESFire code is located on this branch of my local forkhttps://github.com/maxieds/ChameleonMini/tree/DESFire-NewYears2022-PreliminaryMods. I would really appreciate some testers building from that source, which can eventually fulfill the first "getting it to work" part of @colinoflynnhttps://github.com/colinoflynn's branch above. This is the CMLD output trying to swipe on the Omnikey 5022CL reader:

[https://user-images.githubusercontent.com/22165688/147863390-2bddb199-7d9c-4255-b9a0-cc7e29aec702.png]https://user-images.githubusercontent.com/22165688/147863390-2bddb199-7d9c-4255-b9a0-cc7e29aec702.png

As you can see in the logs, the reader goes through the correct sequence with the Chameleon up until we respond to its 9370|... sequence. After this, with the response I gave, I expect the reader to initiate reading the next four UID bits with a 9520|... command. It drops the conversation instead and responds again with the REQA 0x26 byte (non-wrapped). This exchange is consistently what happens on swiping the Chameleon to the Omnikey reader. Granted it is better in getting farther than before this code was modified, but still frustrating to debug. Does anyone see the problem or have suggestions?

@colinoflynnhttps://github.com/colinoflynn I have a couple of short points about the MFPlus and crypto code you pushed in your branch:

— Reply to this email directly, view it on GitHubhttps://github.com/emsec/ChameleonMini/issues/302#issuecomment-1003645124, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AAXQJ7RWKNBTAMQ4XBY2R7LUT6QOVANCNFSM5EDJZDBQ. Triage notifications on the go with GitHub Mobile for iOShttps://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Androidhttps://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 commented 2 years ago

@lvandenb There are a couple of variants, I believe. My branch is currently using 0x08 which should also work. I tried different options, including your suggestion to return 0x24 instead of 0x04, with the same results. It still loops after responding to that with another REQA request. I also have not been able to see the low-level debugging data that would explain what the reader expects next in the sequence with ccid/pcsc and libnfc using the pure pcsc driver on Linux. I am stumped.

colinoflynn commented 2 years ago

@maxieds I seem to have lost a longer in-progress comment so my quick notes:

However the later point are maybe good to discuss after the current code works ;-) I'd be happy to look at your new version (once it works again) and see where I "think" my code should go. If we can find an easy way to expose that location it might be helpful for future users like me who plan on just hacking stuff in without implementing larger feature-sets.

Once I'm back to computer in office with some time will try compiling your new branch too.

lvandenb commented 2 years ago

as far as I have the activation steps (on paper) for desfire ev1

-> 26 <- 44 03 -> 93 20 <- 88 UI0 UI1 UI2 BCC -> 93 70 88 UI0 UI1 UI2 BCC CRC <- 24 CRC -> 95 20 -< UI3 UI4 UI5 UI6 BCC -> 95 70 UI3 UI4 UI5 UI6 BCC CRC -< 20 CRC

(RATS) -> E0 Para CRC -< 06 75 77 81 02 80 CRC

... PPS

->App command

the 5022cl does all the 14443A, until card activation.

then the pcsc interface reports an active card .

this is how I use them. either omnikey 5021, 5022, 5127Ck, 5427Ck, 5421 ..

: wait for card event, and start sending iso8716 apdu.

there is a small workbench tool on hid web site. Omnikey workbench.

it should display the uid when you present the card.

With this tool you can force the 5022CL to do 106 kbaud speed only

From: colinoflynn @.***> Sent: Sunday, January 2, 2022 1:25:57 PM To: emsec/ChameleonMini Cc: Vandenbroucke Luc; Mention Subject: Re: [emsec/ChameleonMini] DESFire Missing Features & Status Questions (#302)

@maxiedshttps://github.com/maxieds I seem to have lost a longer in-progress comment so my quick notes:

However the later point are maybe good to discuss after the current code works ;-) I'd be happy to look at your new version (once it works again) and see where I "think" my code should go. If we can find an easy way to expose that location it might be helpful for future users like me who plan on just hacking stuff in without implementing larger feature-sets.

Once I'm back to computer in office with some time will try compiling your new branch too.

— Reply to this email directly, view it on GitHubhttps://github.com/emsec/ChameleonMini/issues/302#issuecomment-1003707734, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AAXQJ7QQKGD3R4H7WA5VPPTUUA75LANCNFSM5EDJZDBQ. Triage notifications on the go with GitHub Mobile for iOShttps://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Androidhttps://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 commented 2 years ago

I am also starting to wonder if the issue is timing related. The DESFire tags I have (not running on the Chameleon emulation) are detected by the reader as they should be. Also, looking at @lvandenb's sketch of what works on paper, there shouldn't be a problem with what is getting transferred when the reader initiates the handshaking without wrapped commands (there would have been before the changes in my branch -- which is on my TODO list to file as a PR this month). The specs and data returned / exchanges from reader to Chameleon are the same (up until the point where the reader drops the conversation) as when I tested locally with LibNFC using completely wrapped exchanges for nfc-anticol.

Sigh... I will turn off the live logging I was using to debug with the CMLD on my phone as it slows things down substantially to be printing all of that serial data over the USB connection. To my working knowledge, the firmware is not multithreaded which means these USB transfers add a big order bottle neck. If that does not work, I am officially stumped with the Omnikey reader recognition. I only have access to Linux and a restricted MacOS to get the PCSC drivers working, so the suggestion to use the HID branded Windows tools to configure the reader is out for me. I will try to test later tonight and write back with the findings.

@colinoflynn That sounds good. The space constraints on the Chameleon RevG are a sincere problem and hindrance for development 😃! The RevE boards have no chance of working with the DESFire configurations. Nowadays, all of the possible tag emulation support that is written into the firmware, even omitting DESFire support IIRC, are too big to fit onto a flashed single device. The make desfire target only contains one configuration and CONFIG=NONE by default. Initially, it was the big crypto buffers and structures for 3DES/AES128 that did me in. There are also tables of some data added for efficiency (e.g., the CRYPTO1 implementation for MFC cards) that are unnecessary for the DESFire-only emulation support that may free up some space as well. As I am sure you have noticed, the key sign that the heap / stack / possibly bootloader memory collide with too much stack space added for debugging is that the device will be unresponsive after flashing the newly compiled firmware. Whether this happens or not can sometimes be a matter of as small as 16-32 bytes of extra buffer space. IIRC, there are some issues with initializing all of the structures when the firmware first loads so that even if all of the working buffer space you would need on the stack will fit, it bombs on boot-up (avr-gcc kind of sucks in that way where ordinary gcc would know how to handle this better).

I have a couple of other suggestions that might free up some space and prevent stack type overflow:

maxieds commented 2 years ago

I tried the code and made a few small modifications to my local branch. I still cannot get the Omnikey reader to recognize the Chameleon running the DESFire configuration. I will look into the issue with the Proxmark in more detail to see if I can extract more information about why the antiicol handshaking gets dropped. Has anyone else had a chance to test with the firmware binaries on my modified branch? I wonder if the reader is just being weird on my Linux box.

lvandenb commented 2 years ago

the workbench is available for macOS and Linux

HID® OMNIKEY® WORKBENCH TOOL 2.2 FOR LINUX

I'm wondering about the time between reception of the SEL and sending the SAK should be approx 1 byte time (80 uS).

From: Maxie D. Schmidt @.***> Sent: Monday, January 3, 2022 5:24:05 AM To: emsec/ChameleonMini Cc: Vandenbroucke Luc; Mention Subject: Re: [emsec/ChameleonMini] DESFire Missing Features & Status Questions (#302)

I tried the code and made a few small modifications to my local branch. I still cannot get the Omnikey reader to recognize the Chameleon running the DESFire configuration. I will look into the issue with the Proxmark in more detail to see if I can extract more information about why the antiicol handshaking gets dropped. Has anyone else had a chance to test with the firmware binaries on my modified branchhttps://github.com/maxieds/ChameleonMini/tree/DESFire-NewYears2022-PreliminaryMods?

— Reply to this email directly, view it on GitHubhttps://github.com/emsec/ChameleonMini/issues/302#issuecomment-1003864666, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AAXQJ7QWQZVUXJT43IOTDSTUUEQGLANCNFSM5EDJZDBQ. Triage notifications on the go with GitHub Mobile for iOShttps://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Androidhttps://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: @.***>

lvandenb commented 2 years ago

I think I'm out of the game.

Something is wrong with the board. using config=MF_DESFIRE locks it up.

also with the latest release and using config 14443a sniff or so.

I starts, I can do some commands.

From: Vandenbroucke Luc Sent: Monday, January 3, 2022 8:44:35 AM To: emsec/ChameleonMini; emsec/ChameleonMini Cc: Mention Subject: Re: [emsec/ChameleonMini] DESFire Missing Features & Status Questions (#302)

the workbench is available for macOS and Linux

HID® OMNIKEY® WORKBENCH TOOL 2.2 FOR LINUX

I'm wondering about the time between reception of the SEL and sending the SAK should be approx 1 byte time (80 uS).

From: Maxie D. Schmidt @.***> Sent: Monday, January 3, 2022 5:24:05 AM To: emsec/ChameleonMini Cc: Vandenbroucke Luc; Mention Subject: Re: [emsec/ChameleonMini] DESFire Missing Features & Status Questions (#302)

I tried the code and made a few small modifications to my local branch. I still cannot get the Omnikey reader to recognize the Chameleon running the DESFire configuration. I will look into the issue with the Proxmark in more detail to see if I can extract more information about why the antiicol handshaking gets dropped. Has anyone else had a chance to test with the firmware binaries on my modified branchhttps://github.com/maxieds/ChameleonMini/tree/DESFire-NewYears2022-PreliminaryMods?

— Reply to this email directly, view it on GitHubhttps://github.com/emsec/ChameleonMini/issues/302#issuecomment-1003864666, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AAXQJ7QWQZVUXJT43IOTDSTUUEQGLANCNFSM5EDJZDBQ. Triage notifications on the go with GitHub Mobile for iOShttps://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Androidhttps://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: @.***>

ceres-c commented 2 years ago

@lvandenb when unpredictable things such as these happen, you are probably jumping to random parts of RAM because the firmware file was too big for the EEPROM Have you checked the size of the final compilation output?

colinoflynn commented 2 years ago

EDIT: I'm running your branch with make desfire, then setting /chamtool.py -p /dev/ttyACM0 -c MF_DESFIRE.

@maxieds Running a test on my ACR122 reader, I see this log (I'm not using the phone app yet still):

57611 ms <+57611 ms>:CODEC RX                     (1   bytes) [26                  ]    
57611 ms <    +0 ms>:CODEC TX                     (2   bytes) [0344                ]    
57612 ms <    +1 ms>:CODEC RX                     (2   bytes) [9320                ]    
57612 ms <    +0 ms>:CODEC TX                     (5   bytes) [0840cd8d08          ]    
57615 ms <    +3 ms>:CODEC RX                     (9   bytes) [93700840cd8d0812d0  ]    
57615 ms <    +0 ms>:CODEC TX                     (3   bytes) [04da17              ]    
57894 ms <  +279 ms>:CODEC RX                     (1   bytes) [52                  ]    
57894 ms <    +0 ms>:CODEC TX                     (2   bytes) [0344                ]    
57896 ms <    +2 ms>:CODEC RX                     (9   bytes) [93700840cd8d0812d0  ]    
57896 ms <    +0 ms>:CODEC TX                     (3   bytes) [04da17              ]    
58174 ms <  +278 ms>:CODEC RX                     (1   bytes) [52                  ]    
58174 ms <    +0 ms>:CODEC TX                     (2   bytes) [0344                ]    
58176 ms <    +2 ms>:CODEC RX                     (9   bytes) [93700840cd8d0812d0  ]    
58176 ms <    +0 ms>:CODEC TX                     (3   bytes) [04da17              ]

Checking with a proxmark inbetween the reader (this doesn't line up with the above log I did it after):

   17931536 |   17932592 | Rdr |26(7)                                                                    |     | REQA
   17944832 |   17947296 | Rdr |93  20                                                                   |     | ANTICOLL
   17975664 |   17986192 | Rdr |93  70  08  b1  60  00  d9  9a  b0                                       |  ok | SELECT_UID
   21600800 |   21601792 | Rdr |52(7)                                                                    |     | WUPA
   21603044 |   21605412 | Tag |03  44                                                                   |     | 
   21618704 |   21629232 | Rdr |93  70  08  b1  60  00  d9  9a  b0                                       |  ok | SELECT_UID
   21630420 |   21633940 | Tag |04  da  17                                                               |     | 
   25236272 |   25237264 | Rdr |52(7)                                                                    |     | WUPA
   29080160 |   29081216 | Rdr |26(7)                                                                    |     | REQA
   29524800 |   29525856 | Rdr |26(7)                                                                    |     | REQA
   33562976 |   33564032 | Rdr |26(7)                                                                    |     | REQA

Finally the output of pcsc_scan during this time seems to detect something, just doesn't think it needs to do more?

on Jan  3 15:23:05 2022
 Reader 0: ACS ACR122U PICC Interface 00 00
  Event number: 3
  Card state: Card inserted, 
  ATR: 3B 8F 80 01 80 4F 0C A0 00 00 03 06 03 FF 04 00 00 00 00 90

ATR: 3B 8F 80 01 80 4F 0C A0 00 00 03 06 03 FF 04 00 00 00 00 90
+ TS = 3B --> Direct Convention
+ T0 = 8F, Y(1): 1000, K: 15 (historical bytes)
  TD(1) = 80 --> Y(i+1) = 1000, Protocol T = 0 
-----
  TD(2) = 01 --> Y(i+1) = 0000, Protocol T = 1 
-----
+ Historical bytes: 80 4F 0C A0 00 00 03 06 03 FF 04 00 00 00 00
  Category indicator byte: 80 (compact TLV data object)
    Tag: 4, len: F (initial access data)
      Initial access data: 0C A0 00 00 03 06 03 FF 04 00 00 00 00
+ TCK = 90 (correct checksum)

Possibly identified card (using /home/colin/.cache/smartcard_list.txt):
3B 8F 80 01 80 4F 0C A0 00 00 03 06 03 FF 04 00 00 00 00 90
3B 8F 80 01 80 4F 0C A0 00 00 03 06 03 .. .. 00 00 00 00 ..
    RFID - ISO 14443 Type A Part 3 (as per PCSC std part3)

Running hf mfdes info on a proxmark3 shows this:

=] ---------------------------------- Tag Information ----------------------------------
[+]               UID: B1 60 00 7F 5C 85 F1 
[+]      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: 63000000000000
[=]      Vendor Id: Pragmatic Printing Ltd. UK
[=]           Type: 0x00
[=]        Subtype: 0x00
[=]        Version: 0.0
[=]   Storage size: 0x00 ( 1 bytes )
[=]       Protocol: 0x00 ( Unknown )

[=] --------------------------------- Card capabilities ---------------------------------
[+] ------------------------------------ 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

And the sequence makes more sense there:

[usb] pm3 --> hf 14a list
[=] downloading tracelog data from device
[+] Recorded activity (trace len = 159 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(7)                                                                    |     | WUPA
       2100 |       4468 | Tag |03  44                                                                   |     | 
       7040 |       9504 | Rdr |93  20                                                                   |     | ANTICOLL
      10548 |      16436 | Tag |08  b1  60  00  d9                                                       |     | 
      19072 |      29600 | Rdr |93  70  08  b1  60  00  d9  9a  b0                                       |  ok | SELECT_UID
      30644 |      34164 | Tag |04  da  17                                                               |     | 
      35584 |      38048 | Rdr |95  20                                                                   |     | ANTICOLL-2
      39092 |      44980 | Tag |7f  5c  85  f1  57                                                       |     | 
      47616 |      58080 | Rdr |95  70  7f  5c  85  f1  57  c7  ca                                       |  ok | SELECT_UID-2
      59316 |      62900 | Tag |20  fc  70                                                               |     | 
      64640 |      69408 | Rdr |e0  80  31  73                                                           |  ok | RATS
      70452 |      75124 | Tag |63  63  00  00                                                           |     | 
[usb] pm3 -->
lvandenb commented 2 years ago

It is possible I uploaded a project to big, before. But afterwards, I took the elf file to reprogram the card ( With AVR Dragon) this worked before, but not any more.

(compiled on ubuntu) avr-size --mcu=atxmega128a4u --format=avr Chameleon-Mini.elf AVR Memory Usage

Device: atxmega128a4u

Program: 55450 bytes (39.8% Full) (.text + .data + .bootloader)

Data: 5858 bytes (71.5% Full) (.data + .bss + .noinit)

EEPROM: 100 bytes (4.9% Full) (.eeprom)

after programming, and connecting it works a little bit.

VERSION? 101:OK WITH TEXT ChameleonMini RevG 220104 using LUFA 151115 compiled with AVR-GCC 5.4.0. Based on the open-source NFC tool ChameleonMini. https://github.com/emsec/ChameleonMini commit 61b547a

CONFIG=? NONE,MF_ULTRALIGHT,MF_ULTRALIGHT_EV1_80B,MF_ULTRALIGHT_EV1_164B,MF_ULTRALIGHT_C,MF_CLASSIC_MINI_4B,MF_CLASSIC_1K,ISO14443A_SNIFF,ISO14443A_READER

even if I choose

Config=none.

the card stops

From: Federico Cerutti @.***> Sent: Monday, January 3, 2022 6:14:09 PM To: emsec/ChameleonMini Cc: Vandenbroucke Luc; Mention Subject: Re: [emsec/ChameleonMini] DESFire Missing Features & Status Questions (#302)

@lvandenbhttps://github.com/lvandenb when unpredictable things such as these happen, you are probably jumping to random parts of RAM because the firmware file was too big for the EEPROM Have you checked the size of the final compilation output?

— Reply to this email directly, view it on GitHubhttps://github.com/emsec/ChameleonMini/issues/302#issuecomment-1004234417, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AAXQJ7SEJKKAH4UIKML4OELUUHKODANCNFSM5EDJZDBQ. Triage notifications on the go with GitHub Mobile for iOShttps://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Androidhttps://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: @.***>

ceres-c commented 2 years ago

avr-size percentages are wrong due to the internal data memory division in the Chameleon firmware, but it should still be fine anyhow

Given that you have an avr dragon you can single step the device when setting the config and see where it jumps

lvandenb commented 2 years ago

So finally we got into command mode..

USB STATUS: : Chameleon: Manufacturer: Kasper & Oswald GmbH Product Name: Chameleon-Mini Version: 0.01 Device Serial: null USB Dev: /dev/bus/usb/002/002 (@2022-01-09-13:40:01) LOGCLEAR: 100:OK (@2022-01-09-13:40:20) 000001 -- LOG_INFO_CODEC_RX_DATA [1 bytes] (+0 ms) [26] {DISABLE_VERIFICATION (ISO 7816-8), MFULC_REQA, REQA, ENABLE VERIF REQ (ISO-3)} 000002 -- LOG_INFO_CODEC_TX_DATA [2 bytes] (+0 ms) [44 03] {ACTIVATE_FILE (ISO 7816-4), REACTIVATE_FILE (ISO 7816-9), ACTIVATE FILE (ISO-3)} 000003 -- LOG_INFO_CODEC_RX_DATA [1 bytes] (+12140 ms) [26] {DISABLE_VERIFICATION (ISO 7816-8), MFULC_REQA, REQA, ENABLE VERIF REQ (ISO-3)} 000004 -- LOG_INFO_CODEC_TX_DATA [2 bytes] (+0 ms) [44 03] {ACTIVATE_FILE (ISO 7816-4), REACTIVATE_FILE (ISO 7816-9), ACTIVATE FILE (ISO-3)} 000005 -- LOG_INFO_CODEC_RX_DATA [2 bytes] (+4 ms) [93 20] {VERIFY (ISO 7816-4), MFULC_ANTICOLLISION_CL1, SEL_NVB_PICC1} 000006 -- LOG_INFO_CODEC_TX_DATA [5 bytes] (+0 ms) [88 1f 4f bf 67] {INTERNAL AUTH (ISO-3)} 000007 -- LOG_INFO_CODEC_RX_DATA [9 bytes] (+5 ms) [93 70 88 1f 4f bf 67 1f 9a] {MANAGE_CHANNEL (ISO 7816-4), INITIALIZE_PSAM (EN 1546-3), MFULC_SELECT_CL1, SEL_NVB_SAK_CRCA} 000008 -- LOG_INFO_CODEC_TX_DATA [3 bytes] (+0 ms) [24 d8 36] {PUT_KEY (OP), CHG REF DATA (ISO-3)} 000009 -- LOG_INFO_CODEC_RX_DATA [2 bytes] (+4 ms) [95 20] {VERIFY (ISO 7816-4), MFULC_ANTICOLLISION_CL2, SEL_NVB_UID} 000010 -- LOG_INFO_CODEC_TX_DATA [5 bytes] (+0 ms) [41 f9 16 d6 78] {APDU: NONE RECOGNIZED} 000011 -- LOG_INFO_CODEC_RX_DATA [9 bytes] (+5 ms) [95 70 41 f9 16 d6 78 17 62] {MANAGE_CHANNEL (ISO 7816-4), INITIALIZE_PSAM (EN 1546-3), MFULC_SELECT_CL2, SEL_NVB_SAK_CRCA} 000012 -- LOG_INFO_CODEC_TX_DATA [3 bytes] (+0 ms) [20 fc 70] {VERIFY (ISO-3)} 000013 -- LOG_INFO_CODEC_RX_DATA [4 bytes] (+2 ms) [e0 81 b8 62] {RATS (4 bytes total), CREATE FILE (ISO-3)} 000014 -- LOG_INFO_CODEC_TX_DATA [8 bytes] (+0 ms) [06 75 00 81 02 80 66 fd] {APDU: NONE RECOGNIZED} 000015 -- LOG_INFO_CODEC_RX_DATA [20 bytes] (+19 ms) [0a 01 00 a4 04 00 0b a0 00 00 03 97 43 49 44 5f 01 00 9e 32] {APDU: NONE RECOGNIZED} 000016 -- LOG_INFO_DESFIRE_OUTGOING_DATA [23 bytes] (~6 ms) [49 53 4f 31 34 34 34 33 2d 34 3a 20 41 50 50 5f 4e 4f 5f 52 45 53 50] {APDU: NONE RECOGNIZED} 000017 -- LOG_INFO_CODEC_RX_DATA [4 bytes] (~5 ms) [ba 01 37 c8] {APDU: NONE RECOGNIZED} 000018 -- LOG_ERR_DESFIRE_GENERIC_ERROR [50 bytes] (+1 ms) [49 53 4f 31 34 34 34 33 34 50 72 6f 63 65 73 73 42 6c 6f 63 6b 3a 20 49 53 4f 31 34 34 34 33 5f 50 43 42 5f 52 5f 42 4c 4f 43 4b 20 2d 2d 20 31 39 37] {APDU: NONE RECOGNIZED} 000019 -- LOG_INFO_CODEC_RX_DATA [4 bytes] (+11863 ms) [ba 01 37 c8] {APDU: NONE RECOGNIZED}

lvandenb commented 2 years ago

update: nad behaviour was correct. But there is an issue decoding commands for iso-8716

000014 -- LOG_INFO_CODEC_TX_DATA [8 bytes] (+0 ms) [06 75 00 81 02 80 66 fd] 000015 -- LOG_INFO_CODEC_RX_DATA [20 bytes] (+19 ms) [0a 01 00 a4 04 00 0b a0 00 00 03 97 43 49 44 5f 01 00 9e 32]

there seems to be code processing it.. for class 00.... and 0x90 ( wrapped)

(note the "ISO File Select" a4 04 00 0b a0 00 00 03 97 43 49 44 5f 01 00 is just a PNP request in Microsoft windows, to detect Microsoft stuff. This can be disabled, but it should work anyway by responding "file not found" )

Another remark concerning speed and PPS request When the TA(1) byte in the ATS is not zero, and the reader is not limited to 106k, then the reader WILL send a PPS to switch speed to something higher than 106k. The PIC can only confirm , but then it is game over. (Chameleon-Mini only does 106k?) The PPS command is not supported in the current code, but anyway PPS should not happen..

maxieds commented 2 years ago

@lvandenb @colinoflynn I have just started looking through the follow-up posts since my last post above. I will try to parse through all this by the end of the day tomorrow.

Luc, is there a way I can see the modifications you made to the firmware sources?

lvandenb commented 2 years ago

in DESFirePICCHeaderLayout.h

define DESFIRE_EV0_ATS_TA_BYTE 0x00 / TA: Only the lowest bit rate is supported normal 0x77

and then DESFireISO14443Support.c : ATS, and excluding Comments for speed. DESFireISO14443Support.zip

maxieds commented 2 years ago

The latest code pushed. to my local branch successfully works with nfc-anticol with the ACR122 reader. I was unable to get the same command to work with the Omnikey 5022. I suspect it's a timing issue and have not yet tried @lvandenb's suggestion above to force 106 transfer speeds only with the HID Linux tools. Maybe you can verify that my code works with nfc-anticol on your configured Omnikey reader?

I am also still not getting responses from the pcscd -afd daemon nor with pcsc_scan -v. I suspect that this problem is at this point related to the format of the subsequent commands identified in #313. I will see what I can do before falling asleep this morning on the other issue thread.

lvandenb commented 2 years ago

I tested

one small remark, (I even don't know if it really matters as long as there is no real collision going on.)

in DESFirePICCHeaderLayout.h we have

define ATQA_VALUE 0x0344

in DESFireISO14443Support.c line 356 Buffer[0] = (ATQA_VALUE >> 8) & 0x00FF; // TODO: Swapped these ... Buffer[1] = (ATQA_VALUE >> 0) & 0x00FF;

should not be swapped , 44 needs to be send first Buffer[0] = (ATQA_VALUE ) & 0x00FF; Buffer[1] = (ATQA_VALUE >> 8) & 0x00FF;

also SAK should have CRC see http://www.emutag.com/iso/14443-3.pdf : 6.4.3.4 Coding of SAK (Select acknowledge) so line 33 ISO14443A.c

case ISO14443A_NVB_AC_END: /* End of anticollision procedure.

( and as seen in sniffer with real card, "sak incomplete" is 0x24 instead of 0x04 for desfire ev1, maybe it does not matter.)

The CL2 uid had a CRC now, i removed it

and now finally, it gets almost at the end, but it does not seem to recognize RATS any more..

[41676] CODEC RX DATA: 26 [41676] CODEC TX DATA: 44 03 [41680] CODEC RX DATA: 93 20 [41680] CODEC TX DATA: 88 05 61 8D 61 [41685] CODEC RX DATA: 93 70 88 05 61 8D 61 14 76 [41685] CODEC TX DATA: 24 D8 36 [41689] CODEC RX DATA: 95 20 [41689] CODEC TX DATA: FB 34 D1 F5 EB [41694] CODEC RX DATA: 95 70 FB 34 D1 F5 EB BB E9 [41694] CODEC TX DATA: 20 FC 70 [41697] CODEC RX DATA: E0 81 B8 62 [41697] E049-53-4F-31-34-34-34-33-2D-33-3A-20-52-45-53-45-54-20-54-4F-20-49-44-4C-45-20-30-78-65-30 [41706] CODEC RX DATA: E0 81 B8 62 [41706] E049-53-4F-31-34-34-34-33-2D-33-3A-20-52-45-53-45-54-20-54-4F-20-49-44-4C-45-20-30-78-65-30

Changes are in ZIP lvandenb.zip

maxieds commented 2 years ago

@lvandenb Ok, those details should now be fixed in the latest commit to my branch.

Here's what I get from testing (consistently with Omnikey and the ACR readers):

So it seems we hit an infinite loop in processing. After the second batch of UID bytes is sent back, the reader issues 0x26, and we loop. The card is never recognized as such. My question is whether once we hit ISO14443_3A_STATE_ACTIVE and we receive a subsequent 0x26, should we reset to IDLE state to start over again, or instead pass to the ISO144434ProcessBlock(., .) function?

lvandenb commented 2 years ago

frame 24 is wrong (has CRC) I updated my previous comment..

maxieds commented 2 years ago

In the previous message, you said to put the CRCA after the SAK value?

maxieds commented 2 years ago

@lvandenb Still, after the comment updates, the CRC after 0x24 is what you suggested adding, correct?

lvandenb commented 2 years ago

yes but frame 24 as a response on 95 20, is the 2nd part af the UID. should be 4 bytes + BCC

maxieds commented 2 years ago

@lvandenb Ok, MDS needs more coffee... I misunderstood. You mean log frame 24 instead of the SAK response. 😃

maxieds commented 2 years ago

Can I get a second pair of eyes on what's now going on once we enter the RATS? What's with the extra frame of bytes getting sent out by the ACR reader (frame 13)?

lvandenb commented 2 years ago

the e0 ... should be responded by ATS ( 06 ... ) This way the omnikey should understand it cannot switch to 484 kbps

what i see now, : there is no ATS response to the reader.

lvandenb commented 2 years ago

just wrote some bad code, to detect the rats and send back ATS Nice, the Omnikey does not change speed using PPS ( i did reset the config on the reader)

Now we get the iso file select ( AID for microsoft smartcard.. should return app does not exist) (Only the AID for desfire app should seldet app 000 and return ok..)

[31028] CODEC RX DATA: 26 [31028] CODEC TX DATA: 44 03 [31032] CODEC RX DATA: 93 20 [31032] CODEC TX DATA: 88 19 5A 49 82 [31037] CODEC RX DATA: 93 70 88 19 5A 49 82 D6 F5 [31037] CODEC TX DATA: 24 D8 36 [31039] CODEC RX DATA: 95 20 [31039] CODEC TX DATA: 94 A9 C3 FD 03 [31044] CODEC RX DATA: 95 70 94 A9 C3 FD 03 1F D2 [31044] CODEC TX DATA: 20 FC 70 [31047] CODEC RX DATA: E0 81 B8 62 [31047] CODEC TX DATA: 06 75 00 81 02 80 66 FD Here goes the ATS [31064] CODEC RX DATA: 0A 01 00 A4 04 00 0B A0 00 00 03 97 43 49 44 5F 01 00 9E 32 Select MS Smartcard AID, shoukd answer not found

the bad code, just before the RESET TO IDLE 

if (Buffer[0] == ISO14443A_CMD_RATS) { // mode wait for rats was not active
    Iso144434CardID = Buffer[1] & 0x0F;
        Buffer[0] = 0x06;
        memcpy(&Buffer[1], &Picc.ATSBytes[1], 4);
        Buffer[5] = 0x80; /* T1: dummy value for historical bytes */
        uint16_t ByteCount = 6;    // NOT including CRC
        ISO144434SwitchState(ISO14443_4_STATE_ACTIVE);
return GetAndSetBufferCRCA(Buffer, ByteCount);
}

    /* Unknown command. Reset back to idle/halt state. */
    bool defaultReset = false; //Iso144433AState != ISO14443_3A_STATE_IDLE;
    if(!CheckStateRetryCount(defaultReset)) {
        const char *logMsg = PSTR("ISO14443-3: RESET TO IDLE 0x%02x 0x%02x");
        DEBUG_PRINT_P(logMsg, Cmd,Iso144433AState);
        return ISO14443A_APP_NO_RESPONSE;
    //return GetAndSetNoResponseCRCA(Buffer);
    }
maxieds commented 2 years ago

Right. So now we are in the cases to fix with #313 after the RATS is working.

Did you test with the code I pushed about 30 minutes ago to my local branch? I think that the way the RATS gets handled without the quick-and-dirty code mock up you had above is that we call ISO144434ProcessBlock after entering into READY state.

lvandenb commented 2 years ago

nice, it works untill the iso-select, to be solved in #313

[34600] CODEC RX DATA: 26 [34600] CODEC TX DATA: 44 03 [34707] CODEC RX DATA: 26 [34707] CODEC TX DATA: 44 03 [34711] CODEC RX DATA: 93 20 [34711] CODEC TX DATA: 88 16 42 02 DE [34716] CODEC RX DATA: 93 70 88 16 42 02 DE 5F 3E [34716] CODEC TX DATA: 24 D8 36 [34719] CODEC RX DATA: 95 20 [34719] CODEC TX DATA: E6 2B CB AE A8 [34724] CODEC RX DATA: 95 70 E6 2B CB AE A8 F8 E1 [34724] CODEC TX DATA: 20 FC 70 [34726] CODEC RX DATA: E0 81 B8 62 [34726] CODEC TX DATA: 06 75 00 81 02 80 66 FD [34752] CODEC RX DATA: 0A 01 00 A4 04 00 0B A0 00 00 03 97 43 49 44 5F 01 00 9E 32 [34839] CODEC RX DATA: BA 01 37 C8 [34839] E049-53-4F-31-34-34-34-33-2D-34-3A-20-49-44-4C-45-20-2F-20-4E-4F-54-20-57-55-50-41-20-30-78-34-32-31-36

maxieds commented 2 years ago

Alright, just pushed some code cleanup and minor changes for the ACR readers. The command pcsc_scan -v now correctly identifies the card as a prospective DESFire tag with both the Omnikey and ACR. Onto the next issue today where the conversation with the reader gets dropped!

lvandenb commented 2 years ago

ok. nice work. Maybe not important, but should the automatic UID generation : the first byte , comply with this ? https://www.nxp.com/docs/en/application-note/AN10927.pdf 2.2.1 Manufacturer Code : 81 … FE Not allowed

maxieds commented 2 years ago

https://www.nxp.com/docs/en/application-note/AN10927.pdf

Yes, I guess it should. I will fix that defect shortly with another push to the working branch according to the following part of the spec:

2.1.1 Random ID (RID)
A single size UID with UID0 = 0x08 indicates a Random Identifier. The Random ID (RID)
is dynamically generated, when the PICC powers up. Deselecting a PICC does not reset
the RID, but a field reset does.
fptrs commented 2 years ago

resolved by #314