NExT and xSIID "MIFARE Family"?

[Gerbel]

I have a quick query, I have spent some time searching the forums, and cannot find a specific answer, and I will admit that I am rather new, but that’s why I have come here to speak to the people who are far more knowledgeable than I.

So… I understand at this time that you cannot “clone” a Mifare Ultralight card, there is no “magic” version of the Ultralight. That is not what I am looking for.
I do understand there is the xM1 which can reprogram the UID bits to allow for cloning of the UID serial of an existing Mirare Classic 1k card.

What I am wondering is, (irrelevant of the UID), does either the NExT implant or the newly released xSSID implant work in “Mifare Ultralight EV1” mode?

For example, if I were to copy the user programmed data pages 04 through to 15 from an Ultralight EV1 card, and then write them to either the NExT and/or the xSIID, would that work on a reader that was expecting to see that data on a Mifare Ultralight EV1 card?
(In the application that this is used in, the UID is not used at all, the system only uses the data that is entirely the custom data programmed into the user space). The lock bits do not even need to be set.

I am just asking this because I cannot find any specific info on about the NExT if it will work, and more specifically because I noticed on the Dsruptive website on the xSIID page, it says…

Retrocompatibility with NFC
The DSruptive board uses a NTAG chip, which is retrocompatible with the whole NTAG and MIFARE family.

This made me think that it would work?
Or am I not understanding what this means correctly?

I appreciate the knowledgeable minds here, and am looking forward to working out the best application.

Regardless of the answer, at the very least, I am intending to purchase a NExT, as I use a LF EM4xxx series reader for Access Control entry into my house at present, and I want to get rid of my keyfob, so that will likely happen regardless, and I am thinking would most likely be installed the left part of my left wrist I am thinking? (as my door control panel is on the left hand side). The HF side of the NExT would be used to store my vCard to give to people.

Then, (depending on the answer above, and compatibility), I was thinking then of putting an xSIID in my left thumb / index space, for this specific user data 04-15 application. Then I would keep my right thumb / index space free for when a viable solution for payment comes along. Ideally maybe Google Pay? (which I read in a post from Amal apparently didn’t go anywhere sadly). I use a Mastercard, and also the Public Transport system in Melbourne Australia uses a Mifare based card, (I think it is DESFire 2), but apparently you can add your Myki card to the Google Pay app and use that, so if Google Pay ends up working, that may cover both applications that I want it for. But for now I understand that there is no payment solution or other solution that would work for public transport at the moment (that I am aware of short of sending an actual Myki card to Amal to be custom built into an implant, which I don’t want to do), so that’s why I’ll wait for now.

Also, I actually know the people in Melbourne at the Partner Location of The Piercing Urge, and whilst I myself have a needle phobia, my girlfriend has had other “parts” of her body pierced by them before. So I know they are professionals, and I think if I just don’t look, (or at least get a numbing agent), I should be OK.

Looking forward to hearing peoples thoughts on my question above and contracted life story below that. Have a great day.

-Adam

[Satur9]

Hey Adam, welcome to the party.

Regarding your Ultralight question, the HF side of the NExT uses an NTAG216 chip. If you buy some cheap NTAG216 stickers or test cards online, you can write the information you want to test out using an app like TagWriter, NFC Tools, or if necessary NFC Shell. This will allow you to verify the functionality in a low risk way

[Compgeek]

@Gerbel

Also, I actually know the people in Melbourne at the Partner Location of The Piercing Urge, and whilst I myself have a needle phobia, my girlfriend has had other “parts” of her body pierced by them before. So I know they are professionals, and I think if I just don’t look, (or at least get a numbing agent), I should be OK.

The Piercing Urge are fantastic, but they won’t apply anything to numb (apparently because of weird piercing laws, it then becomes a medical procedure and you need a surgeon/doctor/medical professional) but Eloise is fantastic and I think you’ll be fine. She went over breathing techniques to help manage any discomfort and had a great beginner-friendly approach

[Compgeek]

In terms of your Ultralite question, @Satur9’s suggestion of trying it on a non-implant is the best way to go. It really depends on the system. If it looks at what type of tag it is, cloning the data won’t work.

Samsung door locks come to mind if you want to search to forums for the sort of thing I mean - they changed their locks to check if it’s a Mifare Classic and lost the ability for NTAG216’s to be programmed in.

If it just checks for the data and doesn’t care what card it comes off, there’s a good chance it’ll work. This is what they mean by retro-compatibility - they are the same ISO standard and respond to similar commands, so the hardware that works on one should work on the other - software is a different matter sometimes though

[Gerbel]

Thanks for explaining that @Compgeek, much appreciated.
Why would Samsung make that change to check the card type?
I mean why bother? What is in it for them to limit the system that way?
I don’t understand why they would.

[Compgeek]

That’s a question for Samsung if you want an exact answer, but I’m happy to speculate.

First thing to note is that the Samsung branded tags are all Mifare Classic, and thats all the manual promises it’ll work with. The QC department just need to check it works with them and its good enough!

I’m sure someone could make the argument it’s more secure (at least for their tag sales) since it responds to less tags that it “isn’t meant to”.

At the end of the day, someone probably just thought it seemed like a good idea at some point when they were revising things due to a minor hardware revision (probably a supplier part number changed from 2001 to 2002…), it passed QC, and here we are! We are a small enough market to not be considered in that decision, and if someone calls support and says their tag isn’t working you can just sell them a Samsung tag!

[Gerbel]

Yep… that sounds like something Samsung would do.
I am curious @Compgeek, from the sounds of things you are in Melbourne too, (hence your Piercing Urge comments), what circles do you travel in… perhaps we’ve bumped into each other before and not even known. (Feel free to PM me).

[NOCx420]

Hey adam,
welcome! Im not that into cards and chips yet, but from what I heard the procedure is not painful and some people don’t even feel pain at all. And from my experience with needles:
I don’t like them, but for me looking away does help a lot.

[Compgeek]

Did a little more digging, Adam.

Definitely looks like the NTAGs and Ultralights store their data in similar ways. (Pages of 4 bytes, user space starting at 4)

I found reference to a Java library that uses the same write and read method for both tag types. If the system doesn’t check card type or rely on the counters, i think we might be in luck!

Once my test cards arrive, I’ll play with the raw commands and we’ll give it a good crack!

[amal]

@Gerbel

The DSruptive board uses a NTAG chip, which is retrocompatible with the whole NTAG and MIFARE family.

This is not true. Where did you see this? The term mifare is not a technical specification, but more of a marketing term at this point. There are plenty of “mifare” chips that are totally incompatible with the NTAG I2C chip inside the xSIID.

From Wikipedia…

MIFARE is the NXP Semiconductors-owned trademark of a series of chips used in contactless smart cards and proximity cards.

The brand name covers proprietary solutions based upon various levels of the ISO/IEC 14443 Type A 13.56 MHz contactless smart card standard.

So far so good, but then it goes off the rails…

It uses AES and DES/Triple-DES encryption standards, as well as an older proprietary encryption algorithm, Crypto-1.

If we accept this definition, then Ultralight chips (both Ultralight and Ultralight C) are not “mifare”, even though NXP markets them as “under the mifare family umbrella”.

Suffice to say, the term “mifare” is just fucked, so never use it unless you are describing the [Mifare “Classic”] chips, which are 1k based on the S50 and 4k based on the S70 chips which are shitty chips with 4 byte non-unique-IDs (NUIDs) and a jenky broken crypto-1 “encryption” (pff, no it’s not encryption, it’s a crap password scheme) mechanism.

@Gerbel

What I am wondering is, (irrelevant of the UID), does either the NExT implant or the newly released xSSID implant work in “Mifare Ultralight EV1” mode?

No not really… first, because no there is no emulation capabilities built in to NXP chips like this at this level… and secondly, because now you’re throwing “EV1” into the mix… just like how Hollywood makes crap “reboots” of old movies, the EV1 literally means “evolution 1”… so you take an old crap chip like a Mifare Classic 1k or an Ultralight, glue on some facial hair and draw on some abs…

…and now you have a “new and improved!” version of the same ol’ chip… but in the case of chips like the Mifare Classic 1k, the EV1 variant also has crap “encryption” which already has some attacks defined for it and can also be broken in most cases.

The important thing to know here is that the “mifare” chips (mifare classic) have a fundamentally different memory structure than Ultralight or NTAG. The “mifare” chip has memory that is broken down into sectors, with each sector consisting of 3 blocks of 16 bytes each and a 16 byte sector trailer which holds two keys and access bits (permission settings) for each sector. With a “mifare” chip, sector 0 contains the ID and “MAD” which is the “Mifare Application Directory”… but hardly anyone uses the MAD since most cards are single application anyway.

In contrast, the Ultralight and NTAG chips both have a memory structure that typically has a single sector (xSIID with NTAG I2C has 2 sectors) made up of 4 byte blocks or “pages” as they are called sometimes. Some of these 4 byte blocks are special, like page 03 which, in NFC terminology, is called the Capability Container… and these 4 bytes are OTP (one time programmable), meaning they all typically start out as bit value 0 but if you flip any bits to 1 then they cannot go back… so writing data to this page must be done carefully. Also there are configuration bytes stored in various other special pages, like page 02 which contains “static lock bytes” which control the read-only locked state of pages 03-10… these lock bytes are also OTP and cannot be unset once set… so that’s why we disable them by setting the lock bytes to lock themselves… once locked, the lock bytes cannot be changed and therefore cannot be used to further lock other pages of the chip. We also do this to the “dynamic lock bytes” in page E2 of our NTAG216 chip based products (NExT, xNT, etc.) but in other NTAG chips like NTAG213 or others, there are fewer memory pages so the configuration bytes situated at the end of user memory are at other page addresses for smaller memory chips.

Just one comment… many apps like NFC Tools call NTAG chips "Ultralight ", but that’s also wrong. Ultralight are specific chips, old chips, with fewer capabilities and features, and even the EV1 variant is its own thing… NTAG, if anything, is a true actual next generation of Ultralight… same memory structure but vastly improved feature set.

[Compgeek]

@amal

NTAG, if anything, is a true actual next generation of Ultralight

Hey @amal, do you know if the raw commands were kept the same between Ultralight and NTAG? I’m going to have a play when I get my test cards on the workbench but thought you may know!

Wow, didn’t realise how bad they fucked the Mifare name…

[amal]

@Compgeek

do you know if the raw commands were kept the same between Ultralight and NTAG?

I don’t, and I couldn’t tell you anyway because the Ultralight chip’s function (particularly the Ultralight C’s “administration commands”) are smeared with NDA jelly. If the SDS doesn’t have commands listed, then the full datasheet would, but you’d need to sign an NDA, get a docstore account, and probably still have to beg to get the actual datasheets you need.

[Compgeek]

Copy that, thanks!

I think I know enough to give it a good attempt when my 216 cards arrive (might try on a 213 sticker!)

[fraggersparks]

@amal

crypto-1 “encryption” (pff, no it’s not encryption, it’s a crap password scheme) mechanism.

The open source implementation is called crapto1 for a reason

[Gerbel]

Thanks @amal that was very informative and helpful. I have been chatting with @Compgeek, and turns out we are not that far from each other locally, so are going to do some tests with some NTAG216 and see what happens for my application.

To answer your question of…

The DSruptive board uses a NTAG chip, which is retrocompatible with the whole NTAG and MIFARE family.
This is not true. Where did you see this?

It is on the Dsruptive website…
https://dsruptive.com/siid/
Right at the bottom on the right.

[Satur9]

Lolwut. I understand that this was translated to English, and something might have been lost, but that’s misleading at best.

[Backpackingvet]

@Satur9

but that’s misleading at best.

I feel like their whole front page is misleading. You scroll down and see this,

And then keep going to

And they even show a xSIID,

Now I like me xSIID, but I feel like that front page is DSEPTIVE, and misleading.

[Pilgrimsmaster]

@Backpackingvet

DSEPTIVE

Haha, nice

[Backpackingvet]

Not trying to be mean.

Even when you reach out to the “Contact us” they ignore you. Been going on for 3 months with no response.

[Backpackingvet]

@Backpackingvet

DSEPTIVE

To go further, I believe I cannot access all of my chip yet also.