Mifare Ultralight card failing to read using NFC read function

[quickfire9]

Describe the bug.

When trying to read a (balsa, maybe) wood ibis hotel card, the flipper detects it but just continues to try and read it over and over again.

Reproduction

When trying to read this hotel keycard, my flipper says "apply card to flippers back" like normal, and when i set the flipper on the card, it says "reading, dont move card". and it just stays like that forever. attached is an image of the flipper on the card.

Target

No response

Logs

>: log debug
Press CTRL+C to stop...
85391499 [I][FuriHalNfc] Deinit OK
85391627 [I][FuriHalNfc] Init OK
85391632 [D][DolphinState] icounter 67, butthurt 0
(everything below this line loops, continues to repeat)
85393416 [I][NfcWorker] Mifare Ultralight / NTAG detected
85393430 [I][NfcWorker] Trying to read a supported card ...
85393434 [D][MfUltralight] Reading version
85393436 [E][FuriHalNfc] Failed to start data exchange
85393440 [D][MfUltralight] Failed reading version
85393490 [D][MfUltralight] Reading pages 41 - 44
85393496 [D][MfUltralight] Failed to read pages 41 - 44
85393547 [D][MfUltralight] Reading pages 0 - 3
85393553 [D][MfUltralight] Failed to read pages 0 - 3
85393718 [D][MfUltralight] Reading version
85393724 [D][MfUltralight] Failed reading version
85393775 [D][MfUltralight] Reading pages 41 - 44
85393781 [D][MfUltralight] Failed to read pages 41 - 44
85393832 [D][MfUltralight] Reading pages 0 - 3
85393838 [D][MfUltralight] Failed to read pages 0 - 3

Anything else?

I got this card from an Ibis hotel in Paris, France. it worked like a normal keycard, just tap it on the door lock, the light flashes green, and the door unlocks. it does nothing(doesn't see the card) when reading as picopass or 125khz.

using a NFC reader app on my phone, this is what it shows.

my discord is Reveille#1573 if there is anything else I can do.

[llebout]

Same issue here, identical debug logs as well.

Using a different kind of card, it's an E-One Clinic RC IPL (permanent hair removal) cartridge activation card.

[bluesbro1982]

Same issue here on firmware 80.1 with a Mifare Ultralight hotel key which NFCTools shows as ISO14443-3A Technologies available NfcA, MifareUltralight, NdefFormatable AQTA 0x0044 SAK 0x00

[Astrrra]

Hi! To help you, I'll need a full dump from that card. Please create a full card dump and send it to astra@flipperdevices.com. The "NFC Tools" app on your phone should be able to do that.

Also, are you sure that the "reading card" screen stays forever? For how long have you waited? It may take a few minutes in some cases for reading to be completed.

[llebout]

@Astrrra In my case all Android apps I have tried (and I tried many, albeit only free ones) are unable to dump the full contents of the card, saying the card is not supported. Unfortunately I don't have a Proxmark at my disposal to try the ultimate solution to dump it. NFC Tools app report similar information to @bluesbro1982 about the card. I tried old versions of Flipperzero firmware such as 0.62.1 and 0.73 and both versions are unable to dump the card, 0.62.1 is however able to read the card type etc but not able to read it's content, it's stuck in a loop in similar ways.

I can confirm there's a bug and it's not because I am not waiting enough, I left it there for dozens of minutes and nothing happens, and as documented by OP, there's error logs printing in a loop.

I tried to debug the issue but I am unable to make sense of the low level NFC code as it's quite convoluted and doesnt have any comment.

I am unsure if that's normal since the code seems to hint that being unable to read version can be the expected result, however the only error code I could get for now is ERR_WRONG_STATE from the rfalNfcDataExchangeCustomStart function. This seems to be a custom function without any documentation from ST so I don't really understand it fully.

https://github.com/flipperdevices/flipperzero-firmware/blob/6cc5f30c84e6991af1fa7318922a6aab02ce1a67/lib/ST25RFAL002/source/rfal_nfc.c#L689

I am not able to find out where that ERR_WRONG_STATE comes from and why at the moment but it's not coming from any obvious places it seems to come from a nested function call within rfalNfcDataExchangeCustomStart.

I was using Visual Studio Code source-level debugging and in various places I am unable to set breakpoints because there seems to be code optimizations even though I compiled the code in debug mode. Reverse debugging doesnt seem to be supported on this embedded platform either so it's not easy to trace the code flow exactly.

I don't have enough experience with the code and there's not enough documentation for me to understand. So I'll leave it to the ones that created it.

Thank you

[llebout]

Hello,

I could give a bit more time to this, and with my Mifare Ultralight card (E-One IPL Activation Card), the reason it fails is that:

https://github.com/flipperdevices/flipperzero-firmware/blob/37fb330b362dba3b01b7c6ca6a200564211dc1b7/lib/nfc/protocols/mifare_ultralight.c#L560

At this point in the code, after calling mf_ultralight_read_pages_direct or mf_ultralight_read_pages, tx_rx->rx_bits value is 4 which is less than 16 * 8 and it therefore determines the action failed.

33003 [I][NfcWorker] Mifare Ultralight / NTAG detected
33012 [I][NfcWorker] Trying to read a supported card ...
33015 [D][MfUltralight] Reading version
33017 [E][FuriHalNfc] Failed to start data exchange
33019 [D][MfUltralight] Failed reading version
33068 [D][MfUltralight] Reading pages 41 - 44
33074 [D][MfUltralight] Failed to read pages 41 - 44 (tx_rx->rx_bits == 4) (tx_rx->rx_data[0] == 0)
33124 [D][MfUltralight] Reading pages 0 - 3
33130 [D][MfUltralight] Failed to read pages 0 - 3 (tx_rx->rx_bits == 4) (tx_rx->rx_data[0] == 0)
33295 [D][MfUltralight] Reading version
33301 [D][MfUltralight] Failed reading version
33351 [D][MfUltralight] Reading pages 41 - 44
33357 [D][MfUltralight] Failed to read pages 41 - 44 (tx_rx->rx_bits == 4) (tx_rx->rx_data[0] == 0)
33413 [D][MfUltralight] Reading pages 0 - 3
33419 [D][MfUltralight] Failed to read pages 0 - 3 (tx_rx->rx_bits == 4) (tx_rx->rx_data[0] == 0)

Why would rx_bits value need to be above 16 * 8 for the operation to succeed? Is that the size of a page or something? @Astrrra

I have given up on debugging with GDB/Blackmagic and using printf debugging which seems to work better for me understanding the code flow.

I could verify, after enabling 'Trace' log level that the NFC state is activated for every data exchange operation, so the NFC stack does establish a connection without issue, it's the data exchange itself which seems erroneous.

Thanks

EDIT:

I learned that if GetVersion fails then the IC cannot be identified therefore future commands are ran blindly which is not very good I presume. From reading https://www.nxp.com/docs/en/application-note/AN10833.pdf

I am going to investigate why GetVersion fails instead now.

[llebout]

Hello again,

After some research, I found this stackoverflow answer: https://stackoverflow.com/a/45633741

Explaining that if GET_VERSION fails then if 1A 00 (AUTH?) command succeeds then it is a Mifare Ultralight C card. In my case, using NFC Tools on my phone I could confirm 1A 00 command succeeds. So my card type is Mifare Ultralight C.

I am unsure if Mifare Ultralight C can be read at all unless you already know the password (which most systems hide..). In my case this card is used to authenticate on an hardware system which I own and on which I have all the freedom to tinker, crack or hack in my country (France).

Is there any know flaw on the 3DES authentication scheme for Mifare Ultralight C?

I have not found evidence of any practical one online yet, will keep looking.

EDIT:

In my case, I think NFC sniffing would help me maybe carry an attack. The NFC card may contain some 'use count' data, after which the hardware stops working, if I can sniff the NFC data and then emulate a fake Mifare Ultralight C with dummy 3DES authentication (if that's possible), then I could maybe emulate a fake 'use count' and continue using the device.

The alternative I was thinking would be that the Flipperzero be used to read the card while it's already authenticated with the reader (placed on the reader, and Flipperzero on top), so that the Flipperzero can dump the card using READ commands after the original reader has authenticated it, and after that emulate a fake Mifare Ultralight C to fool the original reader.

Please comment if these attack scenarios are possible.

Thanks

[llebout]

Hello,

According to Mifare Ultralight C spec, not all pages need authentication to be read. However, even the first 4 pages are unable to be read with the Flipperzero.

Maybe hints on some other issue, a bug within the NFC reader (other than not supporting Mifare Ultralight C).

I will try investigate next time I have some time, but wanted to log this here in case anyone else works on this.

Thanks

[GMMan]

In my case, I think NFC sniffing would help me maybe carry an attack. The NFC card may contain some 'use count' data, after which the hardware stops working, if I can sniff the NFC data and then emulate a fake Mifare Ultralight C with dummy 3DES authentication (if that's possible), then I could maybe emulate a fake 'use count' and continue using the device.

The 3DES authentication cannot be broken that way because it uses a 3-pass mutual authentication scheme that uses unique nonces each time. Your captured AUTHENTICATE part 2 command will not work because the nonce that was used for generating the command will not be the same in each session. The tag is also not susceptible to the same PRNG weakness as Mifare Classic, so you're probably not likely to see the same nonce again in a reasonable amount of time.

You card is a bit weird, because a failed read from page 0 suggests that AUTH0 is set to 0, which is not a valid value according to the datasheet. Perhaps it's a discrepancy between the datasheet and the actual product (not unheard of; in tags using password authentication, 0 is documented to be a valid value for AUTH0), but I don't have any unpersonalized Ultralight C tags on hand to validate (and since it doesn't support the get signature command, no way to know if random tags I get from Amazon are genuine).

[llebout]

@GMMan Regarding the attack I was not aiming to break the 3DES authentication scheme which I well realized would be difficult to break without a supercomputer at hand, but instead to impersonate the real card with a fake one that the reader might accept, reproducing card content by sniffing the real card and reader interactions.

[GMMan]

Again, due to the 3-pass authentication, you won't be able to do that. Without the 3DES key, you won't be able to authenticate with the tag to read its contents. Flipper is too chonky to sit between a tag and a reader to eavesdrop; the best you can do is capture traffic from reader, play it to the tag, then emulate the results, and with the random nonce, you won't be able to replay the data and have either side consider it to be valid.

[doomwastaken]

If anyone could verify this on latest firmware, that would be great. I assume hotel card is no longer accessible

[doomwastaken]

Please reopen if issue persists