Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

DESFire Missing Features & Status Questions #302

Closed
colinoflynn opened this issue Sep 15, 2021 · 48 comments
Closed

DESFire Missing Features & Status Questions #302

colinoflynn opened this issue Sep 15, 2021 · 48 comments

Comments

@colinoflynn
Copy link

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

ChameleonMini/Firmware/Chameleon-Mini/Application/MifareDESFire.c

Line 215 in 29f3d85

return MifareDesfireProcessCommand(Buffer, ByteCount) * BITS_PER_BYTE;
). 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
Copy link
Contributor

maxieds commented Sep 24, 2021 •
edited
Loading

@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
Copy link
Author

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
Copy link
Contributor

maxieds commented Nov 2, 2021

@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
Copy link
Collaborator

@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
Copy link
Author

@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
Copy link

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
Copy link
Contributor

maxieds commented Dec 16, 2021

@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
Copy link
Contributor

maxieds commented Dec 16, 2021

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
Copy link

lvandenb commented Dec 17, 2021 via email

@maxieds
Copy link
Contributor

maxieds commented Dec 17, 2021

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

@maxieds maxieds mentioned this issue Dec 19, 2021
Open
@lvandenb
Copy link

lvandenb commented Dec 20, 2021 via email

@maxieds
Copy link
Contributor

maxieds commented Jan 1, 2022

@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 added a commit to maxieds/ChameleonMini that referenced this issue Jan 1, 2022
@maxieds
Proposed initial fix to issue emsec#302 where some application functi…
a038fd0 
…ons return bit counts instead of expected byte counts
@maxieds
Copy link
Contributor

maxieds commented Jan 1, 2022

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
Copy link
Author

@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
Copy link
Contributor

maxieds commented Jan 2, 2022

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:

  • The AES-based crypto code you have in aescmac.* should really be grouped in with the other AES source files in the Application/ directory. I have a feeling that adding the extended support this spring is going to get messy with all of the structured data that needs to get communicated. I think we should try to keep the code as clean as possible from the get go. Note, however, that I do not control the pull requests.
  • When you add in extra test cases, or tag specific data buffers, you should try to pad them in optional (non-production) Makefile defines. I had to do this to test. It keeps everything cleaner and once things are working post-development, will make it easier to remove space consuming extra data. The space issue is especially pressing and was one of the hardest things to get right developing the preliminary code last year.
  • If you are going to add in extra crypto functionality, you might consider adding test cases into the directory here. It will be a benchmark for known working behavior to refer to later.

@lvandenb
Copy link

lvandenb commented Jan 2, 2022 via email

@maxieds
Copy link
Contributor

maxieds commented Jan 2, 2022

@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
Copy link
Author

colinoflynn commented Jan 2, 2022 •
edited
Loading

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

  • Your log looks like it should work (I see the same sequence on a working reader with a real card, nothing 'wrong' in your sent data). I ended up with a similar problem that was just OTA corruption - I discovered when sniffing the reader IC's output (it was a black box item so I couldn't get logs, just saw it not working like in your log). The data looked fine with an OTA sniffer as well, so it was only the reader IC that had trouble with the received data. Perhaps a timing issue too (to fast/slow), I had played around with that but I don't think the readers are that sensitive AFAIK.

  • The code size issue was a problem I ran into too - so will need to carve out some of my stuff! I somewhat arbitrary just deleted DESFire features to make my stuff fit (again all part of that horrible hacky branch I did...).

  • As a quick thoughts on 'future expansion' - I'd emphasize simplicity of hacking stuff on over worrying about being feature-complete. I suspect for a lot of "users" being able to quickly hack on responses to specific commands will be the most important feature. You can somewhat see that with my mifareplusev1 stuff - I just had to turn off some of the DESFire code to stop it from being "too smart" in responding. It took a bit to get to where I needed to hack in stuff...

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
Copy link

lvandenb commented Jan 2, 2022 via email

@maxieds
Copy link
Contributor

maxieds commented Jan 2, 2022 •
edited
Loading

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:

  • Try browsing through the Makefile to enable non-default testing options. For example, enabling the CONFIG flag SETTINGS += -DDESFIRE_CRYPTO1_SAVE_SPACE (see also these options).
  • Make sure to quote all const char * type string literals using a PSTR("my string literal") wrapper to make sure that they are not pushed into the constrained parts of the text segment of the firmware binary. Historically, some contributors have been lax with this, or maybe it just was not an issue until more recently. Going through and doing this consistently helped me get the DF configurations to work. Best not to introduce more instances of the problem.
  • To a limited extent, depending on your testing needs, the large terminal buffer and log buffers can be reduced in size. This might free up an immediate 256-500Kb on the stack if you play your cards right. Handle the terminal buffer with caution however as the code does not check for overflow, and the incoming terminal commands and output share the same pointer to this buffer.

@maxieds
Copy link
Contributor

maxieds commented Jan 3, 2022 •
edited
Loading

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
Copy link

lvandenb commented Jan 3, 2022 via email

@lvandenb
Copy link

lvandenb commented Jan 3, 2022 via email

@ceres-c
Copy link
Contributor

ceres-c commented Jan 3, 2022

@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
Copy link
Author

colinoflynn commented Jan 3, 2022 •
edited
Loading

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
Copy link

lvandenb commented Jan 4, 2022 via email

@ceres-c
Copy link
Contributor

ceres-c commented Jan 4, 2022 •
edited
Loading

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
Copy link

lvandenb commented Jan 9, 2022 via email •
edited
Loading

@lvandenb
Copy link

lvandenb commented Jan 10, 2022 •
edited
Loading

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
Copy link
Contributor

maxieds commented Jan 13, 2022

@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
Copy link

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 maxieds mentioned this issue Jan 15, 2022
Closed
@maxieds
Copy link
Contributor

maxieds commented Jan 16, 2022

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
Copy link

lvandenb commented Jan 16, 2022 via email •
edited
Loading

maxieds added a commit to maxieds/ChameleonMini that referenced this issue Jan 16, 2022
@maxieds
Fixing a few details noted in emsec#302
2ba6718
@maxieds
Copy link
Contributor

maxieds commented Jan 16, 2022

@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
Copy link

lvandenb commented Jan 16, 2022 •
edited
Loading

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

@maxieds
Copy link
Contributor

maxieds commented Jan 16, 2022

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

@maxieds
Copy link
Contributor

maxieds commented Jan 16, 2022

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

@lvandenb
Copy link

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

@maxieds
Copy link
Contributor

maxieds commented Jan 16, 2022

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

@maxieds
Copy link
Contributor

maxieds commented Jan 16, 2022

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
Copy link

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
Copy link

lvandenb commented Jan 16, 2022 •
edited
Loading

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
Copy link
Contributor

maxieds commented Jan 16, 2022

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
Copy link

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
Copy link
Contributor

maxieds commented Jan 16, 2022

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
Copy link

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
Copy link
Contributor

maxieds commented Jan 16, 2022

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.

maxieds added a commit to maxieds/ChameleonMini that referenced this issue Jan 16, 2022
@maxieds
Fix the issue with the UID0 byte of a random UID needing to be 0x08 n…
f6b7037 
…oted in the emsec#302 discussion
@maxieds maxieds mentioned this issue Jan 22, 2022
Merged
@fptrs
Copy link
Collaborator

fptrs commented Jan 28, 2022

resolved by #314

@fptrs fptrs closed this as completed Jan 28, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
6 participants
@lvandenb @david-oswald @colinoflynn @maxieds @ceres-c @fptrs