Thread by @cybergibbons

I finally caved and bought a Flipper Zero.

Whilst it's useful, there's a fair few bits of it that aren't particularly well explained.

Let's start with the Mifare Classic reading!

What's it doing, and how is it doing it?

There are two dictionaries stored on the SD card in the device - both in /nfc/assets/

mf_classic_dict.nfc (built-in dictionary)
mf_classic_dict_user.nfc (user dictionary)

The built-in dictionary in the stock firmware has 1244 keys in it.

The built-in dictionary in XFW firmware has 3851 keys in it.

(not sure why the number shown differs on the device)

The stock one has the four "standard" Mifare keys right at the top.

I'd say 90% of cards will be caught by these four.

github.com/flipperdevices…

Oddly, XFW pushes the A0A1A2A3A4A5 and
D3F7D3F7D3F7 keys way down the list to rows 3474 and 3487.

These are stock keys when using the Mifare tags to store NDEF data, which is very common! Not sure why they have been pushed down.

You can add your own keys into mf_classic_dict_user.nfc and it will be scanned before the other file.

By default this is empty - you store specific keys you have found in here.

You don't want to fill it with thousands of keys that won't work as it will use this first.

If you do fill it up, you end up skipping FFFFFFFFFFFF or 000000000000 - which will be nearly all cards!

The odd thing is there are loads of file packs drifting around with thousands of rows in the user dictionary - so you will spend a *lot* longer finding default keys.

An example are the files promoted in the very popular @TalkingSasquach "getting started" videos. This will massively slow down reading most cards.

github.com/skizzophrenic/…

Nearly all cards will be read with the default keys, but you will get ones that won't be.

A good example is this Premier Inn hotel card. The Flipper has found 29/32 keys, leaving one sector unread and one only read.

But what keys were actually found? The UI does not tell us.

We can use the debug logging over the USB cable.

Here we can see that block zero, key A was found to be A0A1A2A3A4A5 on block 0, the first block of sector 1.

It then goes through and tries the same key on all other sectors on the card - it also works on block 8 (sector 3).

It keeps on going through and finds most of the keys.

It's a bit painful to keep an eye on serial logging though.

An upside of the Mifare format is the keys are in the data you read back.

Now, once it is done, we can save the Mifara card data to a file on the SD card, and examine it.

First up, notice how the first chunk of data in block 0 is the UID of the card. You can never write to this on a genuine card.

It can also tell us the keys and what we can do with them.

Block 3 contains the key A, access bits, and key B of Sector 0.

keyA = A0A1A2A3A4A5
keyB = 0D258FE90296

The access bits - 787788 - are a bit complex to explain concisely.

It decodes as:
Block 0,1,2 - Read with Key A/B, Write with Key B.
Block 3 (sector trailer) - Key B can write Key A/B, that's all.

(you can never write block 0 on real Mifare cards, or you could change the UID).

That's a pretty standard config - a set of keys to read the data (e.g. door readers would do this) and set of keys to write the data (e.g. the programmer at the front desk).

Sector 1 is still locked - this is the one that we didn't find key A or B for!

It's likely this is used for access control. It's likely to be a different set of keys for each hotel.

And sector 2 - we only found key A, which allows us to read block 8,9,10 but not write.

These are all 00 anyway, so there is a chance this doesn't matter if cloning the card.

The blocks with the keys set to FFFFFFFFFFFF for both A and B, and with the access bits set to FF0780 are in what is called "transport condition" - there are no restrictions in reading or writing.

So, a quick summary:
* 4 sectors in transport condition (unused)
* 10 sectors with non-default keys but in the XFW dictionary
* 1 sector where we didn't find key B so can't write
* 1 sector where we found neither key

But looking through the key dictionary of the Flipper, it looks like there is a lot of fluff there.

I'm probably going to trim mine right down so that it only contains the most useful keys, and then add ones to the user dictionary for specific situations.

The search strategy across the blocks seems quite sensible though - if the Flipper finds a key on a sector, it will then try it across all the sectors immediately to see if the same key is used across multiple.

For those who care about the access bits:


And a calculator, for the other direction:

blog.saltedbrain.org/2023/03/decodi…
calc.gmss.ru/Mifare1k/

So, given that most Mifare cards use the default keys, and so many systems just use the UID anyway, I think the Flipper will be fairly successful at cloning access control cards.