Suggested new upcoming features and terminal commands to enhance the firmware (feedback much welcome!)

[maxieds]

Hello all, and especially friendly developer types lurking today. I am going to be spending about 8-12 hours on improving the (DESFire emulation parts of) this firmware this spring (approximately from now until the end of April, as mentioned in #310). I have a small short list of improvements and feature extensions to all, or at least most, of the configurations supporting tag emulation on the RevG devices. Before I spend a lot of time writing code for this, I would appreciate some feedback on the next ideas for pull requests to enhance the firmware, e.g., is this useful, desirable, or suggestions and caveat emptor type warnings for how to/not to do this.

Constructive feedback is always welcome 😺 The level of detail at this hour is clearly the up-all-night New Years caffeine I rely on so much. Happy 2022, at any rate!

Command line extensions to set (semi)complete manufacturer data on all CONFIG types

A subset of what I propose below is already available for the CONFIG=MF_DESFIRE tag types (see docs here). Also, I have noticed that the external Proxgrind manufacturer endorsed sources, which still pull heavily from updates to this main branch, have some functionality for all emulated tags to set SAK and ATQA bytes. More precisely, I want to be able to specify the following fields on any particular tag (proposed terminal command syntax is below):

• ATQA (2 bytes)
• ATS (1 byte)
• SAK
• HWVersion (2 bytes: major/minor)
• SWVersion (2 bytes: major/minor)
• BatchNumber (10 bytes)
• ProductionDate (2 bytes)
• Misc manufacturer data not included above (may/or may not be meaningful to set this on all tags, depending on support and specs)

Proposed serial terminal command syntax (minimum of one argument specified, others may be included or omitted at the discretion of the user configuring the tags):

SET_MANU_DATA atqa:xxxx ats:xx hwver:xxxx swver:xxxx batchno:xxxxxxxxxx prodate:xxxx misc:<xx...xx>

With a few global changes, and then edits to reference the new extern'ed variables to store all this extra data for the active configuration, I think this can be accomplished with a single pull request (PR). Does anyone have any relevant details or caveats to give me before I try it locally?

Dummy tag configuration types to assist with spoofing NFC responses (or configuring predefined actions) via a lookup table

The idea is to reserve a chunk of the memory real estate (currently 8K/active tag type) for a structured lookup table that dictates how a so-called "dummy" (dumb) NFC tag we intend to emulate responds to certain predefined inputs that can include wildcard characters for unknown fields in the APDU-level exchanges. The dummy tag should have a default behavior (tag type, like, MFC/MFU/MF_DESFIRE) that it uses to resolve how the tag behaves when no matches for the incoming command exchanges are found in the lookup table. This idea kind of reminds me of a state-full version of the iptables firewall utility that all us native penguins have grown to love so much.

Consider first the (proposed) modified terminal command syntax to enable a tag configuration of this type:

CONFIG=DUMMY:<DEFAULT-TAG-TYPE:MFC|MFU|MFDF|ETC>:<StartAddressOfLookupTableInConfigMemory>

I have some ideas for how to structure the table, as in (with 0xff as a wildcard, say):

|xx -- STATE|BYTE-PATTERN-TO-EXACTLY-MATCH-MODULO-WILDCARDS|???| -> |RESP-TO-SEND|NEXT-STATE|

If prior command data received needs to be in place, then the state should match accordingly, otherwise a 0x00 value means send the RHS data whenever data matching the lookup table entry is received.

Extensions to support this proposed functionality:

• Upload the binary (byte-wise hex data) lookup table into the tag config at the specified address via standard XModem
• Export the binary lookup table data via XModem
• Add Python script to the main Software/ directory to pretty-print a human readable summary of what the lookup table entries mean (i.e., as in the analog to iptables -nvL on Linux boxen)

Other misc terminal commands (accounting/info/etc)

Set default AID (3 or 4+ multi-byte strings support)

This data is often used to restrict access (security by obscurity only, I believe) to some door readers used for physical access. We can give the emulated tag (or even better, of the "dummy" tag types proposed above) a clue and let the low-level APDU parsing functionality (codecs only?) initiate a handshake with readers that want this type of exclusive recognition. Kind of fru-fru icing on the terminal functionality already there, but this could be useful in some applications. Any suggestions from the NFC experts that work with this type of thing every day (of which, I am certainly not one of you) for how best to do this, and any caveats that will come up in testing the implementation?

Set default (master) key data:

SET_DEFAULT_KEY_DATA passph:<quoted string literal>|keybytes:<preprocessed key data as string of hex bytes> proto:<AES|3DES|2KDES|CRYPTO1|OTHERS> saltiv:<salt data as hex byte string>

The precise behavior is dependent on which options are specified at the command line. If the keybytes field is there, then the key is interpreted literally and any other settings are local to the tag implementation (like which cryptographic protocol variant is used within the DESFire tag, for example). If the others are specified alone instead, then we should use the crypto implementations already found in the Application/* directory of the main firmware to generate the corresponding key data and then store it locally within the tag. The latter behavior is kind of like replicating the functionality of openssl at the Unix commandline, but could be useful nonetheless (input please?).

Get information about low-level codecs used by the active configuration:

GET_ISO_EXCHG_PROTO
# Returns, for example, the codec used for internal default processing by the emulated tags, like:
# ISO14443-2A/3A/3B/4 -- OR -- ISO15693 -- OR -- Others ... 

Does anyone find this functionality particularly motivating enough to justify a separate PR to implement it?