maxieds/chameleonminidesfirestack

🦎Mifare DESFire emulation support for the ChameleonMini (RevG) firmware. ☮✌️🇺🇦🇺🇸

chameleonminidesfirestack's Issues

Chameleon terminal commands not reporting full tag contents

I am initializing a new Chameleon tag setup with CONFIG=MF_DESFIRE using my testing code by running:

$ ./Bin/TestFileManagementCommandsSupport.exe
$ ./Bin/TestDataManipulationCommandsSupport2.exe

The approximate output is described in the sample dumps from these commands. Based on my rudimentary inspection that way, the files and AID directories seem to be getting created correctly.

However, when running the following command from the new Chameleon terminal command list, it doesn't accurately report what should be stored on the tag:

DF_PPRINT_PICC FullImage
101:OK WITH TEXT
**** DESFIRE HEADER DATA ****
      RANDOM(UID) 12954C8CF7A1F3
      RANDOM(VERSION) HW=00.01, SW=00.01
      RANDOM(BATCH) FFFFFFFFFF
      RANDOM(DATE) ff/ff
**** DESFIRE INTERNAL STORAGE ****

This is a bug that needs to get worked out. I'm putting it on my list of known issues and things to fix later by logging it here for now.

Firmware currently stuck in the anti collision loop

Cross-listing from the original post:

If the problems are in the anti collision loop, this means it is stuck in the 14443A -3 protocol.
https://www.nxp.com/docs/en/application-note/AN10834.pdf
So a Omnikey reader ( CCID ) wil not even get the ATR ?

@lvandenb
Can you elaborate a little more to help me figure out how to get through the anti collision loop? When I was testing the stock Chameleon MifareClassic and MFU configurations also wouldn't work with the target USB stick I initially bought for testing. Is this possibly something that could be a problem with the codec-related code in the firmware (not supporting the latest, greatest ISO-4 standard)? For example, I remember reading something like there being a parity setting to add support for the newer ISO standard in the libnfc docs. This would be something that gets appended by the codec mod/demod code, correct, not from within the DESFire emulation part of the code? Any help here is much appreciated.

FYI, I'm still working with the same Identive SCM SCL3711 USB stick that is compatible with libnfc right now.

Help and suggestions wanted: DES and 3DES encryption from AVRCryptoLibrary is slow!

The 3DES encryption scheme implemented in the current firmware is too slow to be useful. The AuthenticateISO (0x1A) command times out every time with my reader using this code. Is there a plausible solution?

Note that to fix the AuthenticateLegacy (0x0A) support (see this testing code), I had to move several structures from PROGMEM to a .data section buffer. This definitely improves the access time noticeably! The 3DES variants based on this same DES encryption code still fail with timeouts. See the -DDESFIRE_QUICK_DES_CRYPTO option in the Makefile (extra free space is at a premium already).

I have read about AVR XMega crypto boosters. I don't think this functionality is standard though. Seems to indicate at the general problem being noticed here.

Use crypto hardware acceleration

I noticed that the crypto primitives seem to be implemented in software, e.g. here:

ChameleonMiniDESFireStack/Firmware/Chameleon-Mini/Application/DESFire/ExternalCryptoLib/ArduinoCryptoLib/aes/aes128.c

Line 113 in 06b4b5e

void aes128DecryptBlock(AES128Context *ctx, uint8_t *output, const uint8_t *input)

(and same for the DES).

Any reason to not use the AES/DES hardware accelerators of the Xmega? They will be massively faster and should also save a decent chunk of progmem because you don't have to store the relatively big Sboxes etc. Some initial documentation is here:

• http://ww1.microchip.com/downloads/en/AppNotes/doc8106.pdf
• http://ww1.microchip.com/downloads/en/AppNotes/doc8105.pdf

I think there are also some official Atmel libraries to use them and probably other libs elsewhere?

First official DESFire testing binaries available

Testers welcome! Please keep up to date with the latest releases. I will try to keep the binaries fresh as the sources continue to get updated and improved.

Libnfc compatible NFC readers for testing the firmware DESFire support

Carried over from the post here:

If you want a cheap, reliable and configurable device you can use the ST M24LR-DISCOVERY dev board: it's basically an STM32 driving a CR95HF NFC front end. Being a dev board the sources for STM firmware are available and (pretty) easily editable, if you ever needed to. It can be used with the demo software or with python via simple HID commands.

Or you can buy a Proxmark for cheap on eBay: 36€ if you apply the PITLONG20 coupon listed on the item's page. Some of my friends use these ones and, after some initial issues with the older bootloader which must be upgraded, they're kinda fine.

--Edit--
By pure chance I stumbled upon this issue on the PM repo Proxmark/proxmark3#916 (comment) in which @pwpiwi complains about RDV3 Easy issues. Given his experience in Proxmark's codebase, I'd like to retract my take about the "acceptable reliability" of the Proxmark3 Easy on eBay. If you want a proxmark go for the proper ones (RDV3 or RDV4)

Hardware compatibility ?

Hi there !
I'm interested in having a working Desfire (well, as a first, setting and answering 7bytes UIDs with the good ATQA/SAK elements) with my chameleon device.

I'm seeing you're making progress in implementing Desfire of the Chameleon Mini, but i have a question: would the firmware be compatible with the Chameleon Mini Rev E Rebooted ?

Are there some builds, or specific build instructions or we can expect them to be the same as for the original repo ?

Thanks,
good luck for the future dev,

Rémy

Clarifying tone on international copyright law (users be free)

Reproduced from this emsec#218 issue:

I also want to clarify tone respectfully to any users who get the wrong impression about my attitude to adding headers to my DESFire source code:

/*
The DESFire stack portion of this firmware source 
is free software written by Maxie Dion Schmidt: 
you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by the Free Software Foundation, either version 3 of the 
License, or (at your option) any later version.

This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
GNU General Public License for more details.

The complete license provided with source distributions of this library is available at the following link:
https://github.com/maxieds/ChameleonMiniFirmwareDESFireStack

This notice must be retained at the top of all source files in the repository. 

This source code is only licensed for 
redistribution under the above GPL clause for 
non-commercial users. All commerical use or inclusion of this 
software requires express written consent of the author (MDS). 
This restriction pertains to any binary distributions which 
are derivative works of this software.
*/

What I added to the DESFire firmware source headers does not restrict individual users, even when they use their own compiled versions in commercial applications or work-related settings. What it does is restrict most vendors from redistribution of source or derivative work binaries en masse, e.g., limitations on shipping derivative works flashed on their devices to merchants or to use these sources in merchant linked firmware sources without express written consent.

Logging a perennial memory issue

Perhaps @dev-zzo can shed some light into this. I had to remove some similar code from his original repo sources to get things working correctly. I have a stub (with comments) for this point. Basically, I do not exactly understand why running the following code to initialize a new chunk of FRAM real estate to zero (or whatever it should be) freezes the AVR:

/* TODO: Why doesn't this work ??? -- It freezes the AVR chip when run !! */
void MemsetBlockBytes(uint8_t initValue, SIZET startBlock, SIZET numBlocks) {
    BYTE fillerBuf[DESFIRE_EEPROM_BLOCK_SIZE];
    memset(fillerBuf, initValue, DESFIRE_EEPROM_BLOCK_SIZE);
    SIZET writeAddr = startBlock * DESFIRE_EEPROM_BLOCK_SIZE;
    while(numBlocks > 0) {
        MemoryWriteBlock(fillerBuf, writeAddr, MIN(DESFIRE_EEPROM_BLOCK_SIZE, numBlocks));
        writeAddr += DESFIRE_EEPROM_BLOCK_SIZE / sizeof(SIZET);
        numBlocks -= DESFIRE_EEPROM_BLOCK_SIZE;
    }
}

My best estimate is that things need to be aligned along block (defined at 32 bytes here) sizes. But then this can cause many an issue with having to write jagged data.

Why doesn't this work? I guess I should tag/ask @ceres-c too since he does so much of the development and PR merging over at emsec. A solution to this may very well stabilize some code that has gone a awry so far in my sources!

Thanks for the input. :)