Are electronic locks usually too weak to pick up the chip? (SmartAir Wall Reader)

My friend has the xNT NTAG216 chip, and he can unlock electronic door locks at his house, office, school and gym.
My apartment building has recently installed electronic locks, and I really want to do the same.
Here’s the thing: if I use a random external access card on the new lock, it reacts and declines my card with a red light and a sound. I invited my friend over to try the chip in his hand, and the lock didn’t react at all.

The key tag i received - that opens the door - has these specs:
Tag type: ISO 14443-3A
NXP MIFARE Classic 1k
Tech available: NfcA, MifareClassic, NdefFormatable

My friend has a key card (to access the gym) that has these exact same specs, and he is now using his NTAG216 instead of that key card.

So, why didn’t his chip trigger a response from my building’s new lock? We’re guessing the signal was too weak from the lock…

He told me he had met similar problems in the start, and that he had asked the people at the gym if they could increase the power/signal from the lock there. They did increase it, and then everything worked. He had done the same with the locks at the school, and they also complied. They thought the whole concept was really interesting.

The lock at my building is a ‘SmartAir Wall Reader Universal Design’. I asked the company that installed the lock if they knew if increasing the signal was even an option, and they said it was impossible. I don’t know if they know that for sure though, as they are only installing them…

What should I do? Are there any other chips I can try, perhaps with better ‘antennas’? Or have I misunderstood which chips are compatible with this lock? Should I use another chip? Can I do anything to improve the signal?
My girlfriend and I had an appointment scheduled for implanting the NTAG216 today, but cancelled when we saw that my friend’s chip didn’t trigger a response…
It’s not possible to replace the lock with something else, as it’s out of our control… but do anyone have any experience with this lock, perhaps?

A coupling issue sounds likely. The reader is likely made to work well with flat tags and not cylindrical tags like the xNT.
I’d try with another NTAG216 with a better antenna such as the BullsEye tags, which uses the NTAG216 just like the xNT. If those work you’ll know it’s a coupling issue between the xNT and the reader. If it’s a coupling issue you could take a look at the FlexNT, which has an antenna with a greater range.
If the BullsEye tags don’t work it’s likely a compatibility issue, in which case you could take a look at the xM1 Plus implants, which uses a tag compatible the key tag you mentioned.


Thank you so much, this is such a great answer!
I had never heard of FlexNT, but I am definitely interested if it turns out it’s a coupling issue. You mentioned BullsEye. Will it work with any unit using NTAG216? Are they all the same? Since I’m from Europe, it’ll be pricy to ship BullsEye from DangerousThings, but I found this card on ebay that also uses NTAG216, and is much cheaper to send. Would this work? If I understand correctly, if the lock in my door responds to this key card, I should consider FlexNT? If it doesn’t, it’s a compatibility issue and I could consider xM1 Plus?

Thank you so much!


By the way, this is the lock they have installed. As I’m starting to understand, it might have something to do with the specifications saying “13.56 MHz, MIFARE® DESFire or iClass technology”… I might need another chip?

Yes, all NTAG216 tags are the same. The only difference is the size and antenna shape. The cards you mention should work just fine.

I’m not too sure how that iClass technology works, so I can’t say much about that. Maybe someone else can chime in on that.
Dangerous Things does sell the FlexDF(in beta) which is a DESFire EV1 chip. According to the specifications that should definitely be compatible. Once again, you can probably find a DESFire EV1 card online to test it out.


I’m struggling to understand what would be compatible with what…
As I stated earlier, the key that actually opens this door has these specs:
Tag type: ISO 14443-3A
NXP MIFARE Classic 1k
Tech available: NfcA, MifareClassic, NdefFormatable
Doesn’t this mean it’s not DESFire? Or could it still be DESFire?

I’m pretty sure that means it isn’t DESFire, as you mention. To my knowledge a DESFire tag wouldn’t show up as a Classic 1k.

My best guess is the reader supports multiple types of tags, including Classic 1k and DESFire. Both Classic 1k, NTAG216 and DESFire are ISO 14443-3A compliant, and if the reader only relies on the tag being 14443-3A compliant it would make sense they are all compatible.

I think your best bet is to buy a NTAG216 card and see if it works. If that doesn’t work you could look into a DESFire card/tag.


After some off-channel conversation with Stian, the “MIFARE Classic 1k” he’s referencing is actually a “MIFARE EV1 Classic 1k”… so MF1S50 chip not the older “original” MFICS50 chip. Basically NXP released an “EV1” updated version of the “classic” Mifare chip to address issues with Crypto1… so the memory structure looks similar, but the feature set is slightly different. There is a chance the system could use the older MFICS50 classic chip and not really care about the updated EV1 features or security, that’s plausible, but no way to know without testing.


So to be clear, the Mifare “Classic” EV1 1k chip (MF1S50) that you currently use to open the door, is not the same as the xM1+ which is a Chinese “Mifare Zero” clone of NXP’s older “classic” MFICS50 1k chip… this is where the marketing gets in the way of the technology… The word “mifare” is basically meaningless these days… so we go by chip model numbers. The same is happening to DESFire… the fact the lock’s info page calls out iClass or DESFire should mean that it works with DESFire or DESFire EV1 or DESFire EV2 chips… but the “EV1” part could have easily confused someone in the marketing department at that lock company… they google EV1 and see the most common chip type with an EV1 element in it’s name is DESFire and they think “ok, it’s a desfire chip”… but then your card turns out to be a “Mifare Classic EV1” chip… it’s just a big huge mess over there at NXP, and they haven’t done much to help hardware developers like this lock maker to really sort out what’s what.

Again… testing is the only reliable way to ensure something will work or not.


Heh, I think you’re correct in saying that the marketing derpartment has been a bit confused. In the PDF on the page it just says under the specifications “MIFARE® or iClass technology”. Looks like they just gave up after the MIFARE part.

1 Like

Thank you so much, guys. I have ordered a cheap pack of different cards, including DESFire EV1 and NTAG216, and will test as soon as I receive it (10-15 days).

However, I do have some additional information, and questions… When I used a Galaxy A5 to read the working key tag yesterday, I got this information:

IC manufacturer: NXP Semiconductors
IC type: MIFARE Classic (EV1) (MF1S50)
Tech supported: [14443-3A, 14443-2A]

I have now also scanned my access card for my office (using a Google Pixel). It shows this information:

IC manufacturer: NXP Semiconductors
IC type: MIFARE Classic (MF1S50)
Tech supported: [MIFARE Classic compatible, 14443-3A, 14443-2A]

^ This office card does trigger a response from the SmartAir lock at my home (rejecting access, obviously).
It seems to me that this office access card is a true MIFARE Classic card, and not EV1 (though, still MF1S50, not the original MFICS50 that you mentioned, @amal ).
Doesn’t this mean I should be able to use xNT, flexNT and xM1+ on both doors?
And since this card does trigger a response at home, and my friend’s xNT didn’t, it’s a coupling issue, and we should go for flexNT?
Obviously, I’d like to implant a chip that can replace both of these cards, if possible.
I will wait for the cards I ordered before deciding anything, but I’m still trying to understand the different technologies and relationships:)

###Unimportant bonus question:
Since the Galaxy A5 was not capable of reading the SmartAir-key’s memory content yesterday, I now tried reading it with the Google Pixel. It was able to read the memory, but I got completely different IC-information:

IC manufacturer: Unknown
IC type: Cloned IC
Tech supported: [14443-3A]

I’m not sure what to make of this… Shouldn’t the Google Pixel have superior reading capabilities over the Galaxy A5? It did read the memory, but couldn’t read the IC-info properly? Is it due to the EV1-part?

Nope… the IC part number will always tell you exactly what you have. The MF1S50 is a new “Mifare Classic EV1” chip. The NTAG216 chip in the xNT and flexNT are not that chip, and even the xM1+ is not that chip.

It’s just difficult to say what features a system needs from the chip it sees. Most ISO14443A chips like NTAG216, MF1S50, and MFICS50 have a UID serial number that is read in the exact same way by the reader interrogating it… so if your lock only cares about the UID, then tags with any of those chips should work… but if the lock wants to get fancy and use some specific feature of a specific chip, then you will need that specific chip (or another one that has the exact same feature). Sadly, these details are often not known or disclosed by anyone you’d talk to at the company, except for maybe the engineer that designed the system.


Well, the reason you could read the memory content has nothing to do with superior performance, it just means that the reader chip inside the pixel was from NXP. The “mifare” line of chips are NXP products, many of them require licenses to read/use… it’s insane. So, the NXP chip inside the phone comes with that license “built-in”, and it can read/talk to “mifare classic” chips, while other phones that use, say, a Broadcom NFC reader chip, cannot. This isn’t a real issue for NFC though because “mifare classic” cards (either version) are not NFC compliant. Therefore Broadcom is still providing a robust NFC reader chip that can read any NFC compliant tag out there.

The reason why it comes up with “Cloned IC” might have something to do with the NXP reader chip being able to detect the difference between a “knock off chip” that is pretending to be a MF1S50, and a real MF1S50 chip. The Chinese are always making chips that can be put into various “modes” to pretend to be one kind of chip or another… so that way they make one chip, then if they are making MF1S50 cards that day, they put the chip into MF1S50 mode… and if they are making MFICS50 cards another day, they put the chip into that mode. The down side to this is that there is some backdoor somewhere in the card (usually only known to the manufacturer) that renders any security features of the card moot.

The other reason is that the combination of phone, NFC reader chip, hardware drivers, and app just can’t seem to get shit right… that happens sooo often it’s a little terrifying. I once had samples sent to me directly from NXP and they read as “Cloned IC” … chaos.


I have now received some NTAG216 Ultralight C cards, and the SmartAir lock at home DOES respond to it. Quite easily at that. This means that it’s a ‘coupling issue’ as you stated to begin with, @TabSpaceTab, right?
This means that we COULD get the flexNT, and it would be more likely to work than the xNT at this particular lock?

Now, I brought the NTAG216 card to my office, and asked if they could try to ‘pretend’ my blank NTAG-card was an access card, and we tried to scan it into the system, but it didn’t want it…
The cards that DO work at the office are also of type Mifare Classic 1k(MF1S50)…
So the only thing I know for sure is that MF1S50 works both at home and at work, NTAG216 only works at home, and I will test DESFire-cards when I receive them. If the DESFire-cards triggers a response from the lock at home AND at the office, we should go for the flexDF, I believe.

@amal Since the lock could pick up a blank regular NTAG216 Ultralight C card and not an xNT NTAG216 chip (in my friends hand), how likely is it that it will pick up a flexNT implant? I know it’s a “bad” question, but I don’t know how you would measure the differences in antennas/power in these…

Hi Stian,

Actually “Ultralight C” and “NTAG216” are two separate chip types… there is no “NTAG216 Ultralight C”… so if you can confirm the chip inside is NTAG216 (use TagInfo since NFC Tools reports all NTAGs as “ultralight c” which is just wrong). This is just an educational moment :slight_smile:

Since the locks at work will read whatever cards you brought (ntag / ultralight or MF1S50), then the locks care more about the UID selection process outlined in ISO standard 14443 than they do the chip’s memory organization or extended feature set. This should mean any ISO14443A chip type should work with the locks just fine. As for the lock at your home, it may perform UID selection differently… one way is for a reader to scan for tags in the field and perform a selection command which returns the UID of the tag that responds… but some readers don’t do that… they will select any tag in the field and listen for the first response and then read the actual memory contents to get at the UID that way… and reading memory contents means the structure of that memory matters… so that might be why the lock at home does not respond to MF1S50 cards.

I think your next step is to get an xLED-HF (13.56MHz) and test that lock at home to see if any location/orientation will work with the xNT. Sometimes it’s an odd rotation or spot on the reader that you’d not think to try… but the xLED can show you the correct spot. If the xLED does not light at all in any location or orientation, then the lock antenna is simply the wrong shape.

1 Like

Wow! I’ve been told several places that the xNT is a Mifare Ultralight C NTAG216… weird!
But yeah, I’m TagInfo, the card has IC Type: NTAG216.
It also says ‘Android tech info/ tag description: **.*.MifareUltralight’
But this seems to mean something about the capabilities of the phone itself, rather than the card.

I will check out what you suggested:) thanks

Yeah, when it comes to “tech info” that is referring to the android nfc library and internal android jargon… even they get it wrong… but in all fairness, the NTAG family is basically the next generation Ultralight… the memory structures are nearly the same… it’s just the feature set and configuration bytes that are different… so it really becomes important to note the difference between an NTAG and Ultralight if your library wants to write user data overtop an NTAG configuration page… that could really fuck things up badly… which is why we use the Dangerous NFC app to secure the configuration byte pages using password auth, which is something not even done or supported in Ultralight :slight_smile:

1 Like