Help needed adding ApexFlex to Switchbot keypad

[Mage]

Hey there DT, I’m struggling to clone or add my ApexFlex to my Switchbot keypad (Mifare Classic 1K).

Any chance this is possible or do I need to get another implant / magic ring v2?

Thanks folks, p.s. I have a P3 if I need to use that.

[amal]

We’ve tested switchbot ourselves and their keypad will not work with any other chip types than the ones that ship with the keypad. I believe they are 1K classic tags. We engaged with support and they agree that it would be great for the keypad to support other ISO 14444a chip types, but that it is a low priority and there is no ETA for this update.

Definitely contact support and tell them you want their engineering team to prioritize support for other ISO 144438 compliant transponders.

[Mage]

@amal thanks for the response and will do. More secure as well!

[Mage]

One other question, would the MagicRing allow enrollment?

[Aoxhwjfoavdlhsvfpzha]

If it is a Mifare Classic 1k the Magic Ring V2, xM1, FlexM1, xMagic, or FlexUG4 should all work for you

[amal]

I don’t have access to my switchbot cards right now, scan one with taginfo and post the results here to confirm.

[tac0s]

They are MFC 1k with static encrypted nonces.

[Mage]

Okay so I was able to buy some super cheap essentially blank Mifare Classic 1K tags. A screenshot of the output from Mifare Classic Tool (MCT) is below.

Is there no applet or way I can store / copy this into the free space in my ApexRing? I thought I could have created a Mifare applet.

[Pilgrimsmaster]

@Mage

I thought I could have created a Mifare applet.

Here you go…well it’s an answer, but not a solution

New NFC Sharing Applet

There are a few conflated terms here The P71 chip from NXP that the Apex Flex is built with has a hardware version that can do Mifare Classic card emulation, but that feature is not included in the version of P71 used for the Apex Flex. The Mifare Classic chip type (S50) is not actually NFC compliant. The term NFC means a specific type of RFID transponder that conforms to the NFC Forum standard for NFC Types 1 through 5, and the Mifare Classic does not, therefore it is not an NF…

[Mage]

Thanks @Pilgrimsmaster - maybe a dumb question, but I can enroll a tag for access that only has a unique Block 0, can’t I dump some equivalent text I to the 1kb NDEF and mimic the info from the Mifare Class 1k tag?

[GrimEcho]

Most likely no. My understanding is that almost all access systems that will enroll a Mifare Classic chip will not enroll an Apex, even if you have “cloned” a Mifare UUID to it.

The way I see it is that the P71 chip in the Apex presents very differently to a reader during the initial communication. The Apex’s ATR is in a format that the readers in most control systems simply don’t recognize, and that ATR can’t be changed by an applet. The applet only comes into play after it has been selected by the reader, but the simple readers in control systems aren’t programed to make that selection. They simply never initiate the communication channel because they don’t recognize the initial ATR.

[amal]

@GrimEcho

The way I see it is that the P71 chip in the Apex presents very differently to a reader during the initial communication.

Actually this is the really irritating part. The iso14443 standard used by both Mifare and P71 smartcard chips is identical. The iso standard defines exactly how the chip UID is detected and selected as part of the chip interrogation process. If the reader chip and application firmware used this UID detection process intrinsic to the ISO14443 standard, it wouldn’t be a problem at all… unfortunately there are so many shit reader chips (or good chips with shit firmwares / app software) that don’t use the UID reported during the detection phase of the iso chip selection process, and instead implement some sort of memory interrogation to get the UID instead. This locks in a limited set of transponder chip types supported by the chip / firmware. It annoys me to no end.

@GrimEcho

The Apex’s ATR is in a format that the readers in most control systems simply don’t recognize, and that ATR can’t be changed by an applet

Now this is where shit gets real… contactless chips don’t have an ATR. Only contact based smart cards produce an ATR, however because standards like PC/SC rely on ATR, contactless readers construct an ATR for the contactless chip presented and selected during the ISO select process. The odd thing is that because contactless ATRs are synthetically generated by the reader, the ATR can differ for a single chip depending on the reader being used.

In this way, ATR cannot be changed on chip because it has nothing to do with the chip. Also, when using ATR to identify a chip type, it is important to parse it properly rather than consider it to be a static string that is always the same for a given chip type. For example, here are the different but still valid ATR / ATS calcs returned for a simple NTAG216 chip from various readers;

• ACR1252U
  • ATR: 3B8F8001804F0CA0000003060300030000000068
  • ATS: 6A81 (error SW1 SW2)
• VSR
  • ATR: 3B8F8001804F0CA00000030603FF000000000094
  • ATS: 048EF3FAAC658000
• Feitian R502-CL
  • ATR: 3B8F8001804F0CA00000030603003D0000000056
  • ATS: 048EF3FAAC6580
• HID OMNIKEY 5022CL
  • ATR: 3B8F8001804F0CA00000030603003D0000000056

If anyone is interested in ATR parsing, check out;

https://smartcard-atr.apdu.fr/

[GrimEcho]

@amal

The iso14443 standard used by both Mifare and P71 smartcard chips is identical.

@amal

contactless readers construct an ATR for the contactless chip presented and selected during the ISO

Interesting. I think I’m misusing the term ATR then. In my mind there is an initial something that each NFC chip produces when it first is powered/couples with a reader. Is that accurate? Is there another name for this? I also thought that something contained the UUID of the chip, but it sounds like that is wrong/

This is how I mentally viewed a highly abstracted communication flow.

And for a P71 with any type of emulation applet installed, that emulation only occurs in the second phase, after the initial something has been communicated and the reader has issued a follow-up adpu command.

Is this sequence fundamentally wrong?

(link to diagram source text if you want to hack on it)

[StarGate01]

For NFC ISO14443-3A, the ATR is calculated by the reader by using the ATS (Answer to Select), for ISO14443-3B the ATQB (Answer to Request B) is used as a base.

The actual computation includes among other things a checksum (TCK). I use this implementation: ifdnfc-nci/src/atr.c at master · StarGate01/ifdnfc-nci · GitHub .

However @GrimEcho the same reader and the same chip will usually always compute the same ATR.

The Apex chips also have an UID, as do most NFC chips. you can read this UID either directly from the NFC transport layer implementation, or use the pseduo APDU FFCA000000 if your PCSC reader supports it.

[GrimEcho]

@StarGate01

ATS (Answer to Select), for ISO14443-3B the ATQB

Is this the first/initial message that an ISO14443 sends when powered by a reader, or is there something else that comes earlier?

@StarGate01

use the pseduo APDU FFCA000000

That is what I have used in the past, but didn’t realize it was something that required any special handling/logic on the reader.

Based on this, is the sequence diagram above roughly correct?

[StarGate01]

I don’t know enough about the transport of ISO14443 to give a good answer. There is some anticollision and handshake / protocol selection going on before I think.

@GrimEcho

is the sequence diagram above roughly correct

Pretty much, it illustrates why the basic lock could be easily hacked by presenting a chip with a cloned UID. For the P71 solution, you dont even need the UID - ideally the applet should also perform authentication in addition to authorization.

I implemented this for HMAC-SHA1 at https://chrz.de/2021/12/22/nfc-hacking-part-1-authentication-systems-security/ .

[Mage]

@amal

that don’t use the UID reported during the detection phase of the iso chip selection process, and instead implement some sort of memory interrogation to get the UID instead

So if I understand correctly this is why I cannot simply copy the text from the Mifare Classic cards, because the “interrogation” is done differently on the backend, despite the process and logic flows being identical or nearly identical?

I’m glad this sparked discussion, this was definitely a topic I always semi-understood but never deeply “knew”. This all makes a ton of sense.

@StarGate01

Pretty much, it illustrates why the basic lock could be easily hacked by presenting a chip with a cloned UID. For the P71 solution, you dont even need the UID - ideally the applet should also perform authentication in addition to authorization.

Does this mean @StarGate01 that I could theoretically stick the UID and data into a 1kb NDEF package into my ApexFlex (P71) to perform authentication for the Mifare Classic tag? I’m not sure what the Switchbot reader looks for, but I can enroll a tag which only has unique data in Line 1 of Block 1
Notes_240715_00012.txt (4.2 KB)

[amal]

This diagram does a pretty good job explaining the power on and select process. It also includes some memory functions after selection is complete that you can see on the right hand side where the select process ends in the memory interactions begin.

Here is an example that includes some data for iso14443a ntag i2c chips;

This is an example of the iso14443-4 layer

Unfortunately the document that table above came from is no longer online

ISO14443A PICC selection

The ISO/IEC 14443A standard defines the communication protocol for contactless smart cards and readers. The process for detecting and selecting tags involves several steps:

1. Polling Loop (Field Activation):

   • The reader periodically generates a magnetic field to detect the presence of any ISO 14443A compliant tags in its vicinity.

2. Request Command (REQA):

   • When a tag enters the reader’s field, it responds to a REQA command. The reader sends this command to check for tags within its range.

3. Anticollision Loop (Anticollision Phase):

   • If multiple tags respond, the reader initiates an anticollision loop using the ANTICOLLISION command. This process involves:
     • The reader sends a series of commands to obtain the unique identifier (UID) of each tag.
     • Each tag transmits a part of its UID in response.
     • The reader resolves collisions by selectively addressing tags based on their UID parts until all tags are uniquely identified.

4. Select Command (SEL):

   • Once the reader has resolved all UIDs, it sends a SELECT command to a specific tag using its complete UID. The selected tag then enters the selected state, meaning it is the tag the reader will communicate with for subsequent operations.

5. Application Protocol Data Unit (APDU) Communication:

   • After selection, the reader and the tag exchange Application Protocol Data Units (APDUs) to perform specific operations such as reading data from the tag, writing data to the tag, or executing other predefined commands.

6. Field Deactivation:

   • Once the communication is complete, the reader deactivates the magnetic field, signaling the end of the transaction.

This process ensures that the reader can detect, differentiate, and communicate with the desired tag even in environments where multiple tags are present.

Anticollision Phase (Single Tag Scenario)

When there is only one tag in the field, the anticollision process becomes straightforward, as there are no collisions to resolve. Here’s a detailed breakdown of how the reader obtains the tag’s UID in this scenario:

1. Anticollision Loop Initiation:

   • The reader begins the anticollision process by sending the ANTICOLLISION command at Cascade Level 1. This command is used to identify the tags in the field and to start the process of reading the UID.
   • Command: ANTICOLLISION (Cascade Level 1) – 0x93 0x20

2. Tag Response with UID CLn:

   • The single tag in the field responds with the first part of its UID (UID CL1, which is 4 bytes long) and the Block Check Character (BCC). The BCC is a checksum used to ensure the integrity of the UID bytes.
   • Tag Response: [UID CL1 (4 bytes)] [BCC (1 byte)]

3. Select Command (Cascade Level 1):

   • The reader, having received the UID CL1 and BCC, sends a SELECT command to confirm the tag’s presence and readiness for further communication. The command includes the previously received UID CL1 and BCC.
   • Command: SELECT (Cascade Level 1) – 0x93 0x70 followed by [UID CL1 (4 bytes)] [BCC (1 byte)]

4. Tag Response with SAK:

   • The tag responds with a Select Acknowledge (SAK) indicating that it has been selected. The SAK also indicates whether there are additional parts of the UID (i.e., if the UID is longer than 4 bytes, such as 7 or 10 bytes).
   • Tag Response: SAK (1 byte)

5. Cascade Level 2 (If Necessary):

   • If the UID is longer than 4 bytes, the SAK will indicate that further anticollision and selection are needed at the next cascade level. The reader then initiates the anticollision process at Cascade Level 2.
   • Command: ANTICOLLISION (Cascade Level 2) – 0x95 0x20
   • The tag responds with the next part of the UID (UID CL2, which is another 4 bytes) and BCC.
   • Tag Response: [UID CL2 (4 bytes)] [BCC (1 byte)]
   • The reader sends a SELECT command at Cascade Level 2 with the received UID CL2 and BCC.
   • Command: SELECT (Cascade Level 2) – 0x95 0x70 followed by [UID CL2 (4 bytes)] [BCC (1 byte)]
   • The tag responds with another SAK indicating if further cascade levels are needed.

6. Cascade Level 3 (If Necessary):

   • If the UID is longer than 7 bytes, the process repeats at Cascade Level 3.
   • Command: ANTICOLLISION (Cascade Level 3) – 0x97 0x20
   • The tag responds with the final part of the UID (UID CL3) and BCC.
   • Tag Response: [UID CL3 (3 bytes)] [BCC (1 byte)]
   • The reader sends a SELECT command at Cascade Level 3 with the received UID CL3 and BCC.
   • Command: SELECT (Cascade Level 3) – 0x97 0x70 followed by [UID CL3 (3 bytes)] [BCC (1 byte)]
   • The tag responds with a final SAK confirming its selection.

Summary of the Process:

1. Field Activation:

   • Reader generates a magnetic field to power up the tag.

2. REQA Command:

   • Reader sends REQA (0x26) to detect any tags.
   • Tag responds with ATQA (e.g., 0x4400 or 0x0400).

3. Anticollision (Cascade Level 1):

   • Reader sends ANTICOLLISION (0x93 0x20).
   • Tag responds with [UID CL1 (4 bytes)] [BCC (1 byte)].
   • Reader sends SELECT (0x93 0x70) with [UID CL1] [BCC].
   • Tag responds with SAK indicating if more UID parts are needed.

4. Cascade Level 2 (If necessary):

   • Reader sends ANTICOLLISION (0x95 0x20).
   • Tag responds with [UID CL2 (4 bytes)] [BCC (1 byte)].
   • Reader sends SELECT (0x95 0x70) with [UID CL2] [BCC].
   • Tag responds with SAK indicating if more UID parts are needed.

5. Cascade Level 3 (If necessary):

   • Reader sends ANTICOLLISION (0x97 0x20).
   • Tag responds with [UID CL3 (3 bytes)] [BCC (1 byte)].
   • Reader sends SELECT (0x97 0x70) with [UID CL3] [BCC].
   • Tag responds with final SAK confirming its selection.

By following these steps, the reader successfully identifies and selects the single tag in the field, obtaining its complete UID for subsequent communication and operations.

As you can see, due to how ISO14443 protocol works, all ISO14443 compliant tags must have a UID, and this UID is used by the reader to select the tag for further operations, thus quieting any other transponders in the field who will go to a HALT state.

This is why it’s so frustrating when any application like a door lock or whatever;

1. Does not support all ISO14443A chip types when UID is the only security factor being used. There is no reason to be selective about which ISO14443 compliant PICC transponder chips to support when they all must communicate their complete UID to the PCD (reader), and the reader must receive the entire UID to even consider presence of the proximity transponder as true.

2. Applications that do not properly care to support anti-collision to enable presence detection and possible communication with multiple transponders in the field is really fucking lazy. If applications would simply cycle through all available transponders in the field looking for the correct transponder for the relevant application, we could easily see things like whole wallets full of cards being placed up to payment terminals and being shown a list of cards to select for payment, or simply tap that wallet full of cards on bus terminals or access control readers and it “just works” because the reader application found the correct relevant card, no user interface required… but no, we can’t have nice things.

[GrimEcho]

@amal

ISO14443A PICC selection …

Thank you! That helped a ton, and basically confirmed my mental model of the communication flow, specifically for a P71. Follow up clarification …

The UUID on the P71 can’t be changed, correct? So any kind of emulation at the applet level would only work with readers/software that first perform the anti-collision UID selection, then go on perform an applet selection.

The software stack on Android is able to do this, which is why/how the NDEF emulation applet works. Android does a couple of anti-collision rounds to get the UID of the Apex, then uses the well-known ADPU for reading NDEF data, selecting the applet in the process.

And a theoretical MIFare emulation would work the same, right? A door lock would have to perform the anti-collision and selection of the P71 then, and only then, could it try and treat the device as a MiFare Classic or whatever. And even if a reader does correctly complete the selection process for a P71, it likely just ends there and doesn’t attempt to select any applets or protocols afterwards.

[amal]

@GrimEcho

The UUID on the P71 can’t be changed, correct? So any kind of emulation at the applet level would only work with readers/software that first perform the anti-collision UID selection, then go on perform an applet selection.

Correct… you have static mode (can’t be changed) or random (privacy) mode where the UID is random for each RF session. Basically the ISO chip selection process is usually obfuscated for you behind whatever driver or platform is involved. Only having direct hardware access to the reader chips would allow you to see that lower level process take place, and this is where the obviousness of how badly software stacks in general want to avoid the tricky business of dealing with multiple chips in the field at once… typically at some point one of the layers above the hardware reader chip simply picks the first one seen and rolls with that, ignoring all others.

In Android it will do all kinds of interrogations on the OS side before handing the tag object over to your app to do anything with. This is sometimes why scanning an Apex with your phone seems to take a second before it seems to do anything… but if you sniff the RF between you’ll see the phone OS going apeshit trying different things. One of those things is trying to select the well known NDEF AID for Type 4 chips. This all happens after the ISO chip select process has completed of course… I don’t think Android even has a way to handle or deal with mutiple chips in the field at once, even though the NFC reader chip hardware in the phones definitely do.

@GrimEcho

And a theoretical MIFare emulation would work the same, right? A door lock would have to perform the anti-collision and selection of the P71 then, and only then, could it try and treat the device as a MiFare Classic or whatever. And even if a reader does correctly complete the selection process for a P71, it likely just ends there and doesn’t attempt to select any applets or protocols afterwards.

When the P71 chips shipped from NXP has its mifare emluator turned on, it does some tricks in the ISO selection process with ATAQ and SAK so the reader hardware is basically tricked into thinking it could be a mifare chip. I believe this will also change the ATR the reader calculates… but I’ve not bothered to test a P71 with emulation turned on vs a P71 without. I have definitely run into this on Android where I do a taginfo scan and see mifare data, but also global platform and other smartcard features in the full scan.

Those dirty tricks in the ISO selection process is basically why you could not necessarily write a Mifare emulator applet and just deploy it to the P71 after the fact… Just like ultralight and ntag chips, all Mifare commands are raw ISO level commands not ISO7816 APDU commands sent over ISO14443A… and all applets on chip must communicate using APDUs.

I will say that in theory you could potentially write a DESFire emluator applet that could emulate some of the features of DESFire… the file types for example… but I don’t think you could emulate the file management commands without special permissions. Basically there are APDUs for managing keys and files on a DESFire that do not involve first selecting an AID… and on a P71 this would mean you’d have to have a special “management applet” that is set to be the “default applet” on the chip, so basically it’s always automatically selected and running after ISO chip selection completes… then it would technically be possible to write a DESFire emulator that almost completely emulates DESFire features on a P71… but there would still be some gotchas like creating new files with arbitrary AIDs on chip from a management applet. This again is where the DESFire emulator support NXP can cook in as an option for the P71 is fundamentally different because it runs at a lower level in the chip OS.

What I do think is interesting though is you could theoretically deploy DESFire file emulators as applets and they could individually emulate specific application AIDs… so like an access control system that formats blank DESFire cards with like 3 different AIDs to do different things… you could possibly write emulators and deploy those 3 emulator applets to act like the file types expected and then run the card through enrollment. That could be theoretically possible.