OTP page accepts "zeroing" while emulating MFUL EV1

[mishamyte]

Describe the bug
I'm working with a Vizit reader, which has some filter (also called firewalls in English and Chinese terminology) against copies (variations of USCUID-UL tag) and emulators.
The latest filter can't be bypassed by Proxmark3, because of the wrong implementation of OTP page.

So I use the tag with next data in OTP page (hereinafter: OTP):

3/0x03 | CC 3B F5 8C | 1 | .;..

Based on the datasheet:

The parameter bytes of the WRITE command and the current contents of the OTP bytes
are bit-wise OR’ed. The result is the new OTP byte contents. This process is irreversible
and once a bit is set to logic 1, **it cannot be changed back to logic 0**.

So that concept is used by filter. It reads OTP values, then tries to write 00 00 00 00 here, reads it again for validation and writes initial values back.
We are interested in next part of the trace.

For Proxmark3 emulation it's:

    3674642 |    3684018 | Rdr |A2  03  00  00  00  00  EB  A2                                           |  ok | WRITEBLOCK(3)
    3686086 |    3686662 | Tag |0A(3)                                                                    |     |
    3718014 |    3722718 | Rdr |30  03  99  9A                                                           |  ok | READBLOCK(3)
    3727410 |    3748274 | Tag |00  00  00  00  77  FF  D8  64  E1  CC  B1  63  4B  A4  94  F0  2E  34   |  ok |
    3846968 |    3856280 | Rdr |A2  03  CC  3B  F5  8C  DA  ED                                           |  ok | WRITEBLOCK(3)
    3858540 |    3859116 | Tag |0A(3)                                                                    |     |

For original tag it's:

   13601520 |   13610896 | Rdr |A2  03  00  00  00  00  EB  A2                                           |  ok | WRITEBLOCK(3)
   13612068 |   13612708 | Tag |00(4)                                                                    |     |
   13643600 |   13648304 | Rdr |30  03  99  9A                                                           |  ok | READBLOCK(3)
   13864880 |   13869648 | Rdr |50  00  57  CD                                                           |  ok | HALT

The same behavior as an original tag has is also implemented in Flipper Zero tool.

As we can see, incorrect behavior in Proxmark3 leads that it can't be used against those (and similar readers) and is incorrect.

Potentially it can be the same for Capability Container bytes of NTAGs, but I had no opportunity to check it.

Expected behavior
Proxmark3 will NACK to an invalid attempt and won't change OTP bytes values in emu memory.

Desktop (please complete the following information):

• OS: Win10 (19045.5608)
• Client.... Iceman/master/v4.19552-465-g7b528a856-dirty 2025-03-19 00:57:41
  Bootrom... Iceman/master/v4.19552-465-g7b528a856-dirty-suspect 2025-03-19 00:58:31
  OS........ Iceman/master/v4.19552-465-g7b528a856-dirty-suspect 2025-03-19 00:58:54
  Target.... RDV4

Tag dump and traces from PM3, Tag & Flipper Zero are attached:
hf-mfu-04C9D0427A1790-dump.json
traces.zip

[mishamyte]

Thanks for quick fix, @iceman1001

I tested on a fresh build:

    Client.... Iceman/master/v4.19552-487-g6a671616b-dirty 2025-03-19 12:43:48
    Bootrom... Iceman/master/v4.19552-487-g6a671616b-dirty-suspect 2025-03-19 12:44:39
    OS........ Iceman/master/v4.19552-487-g6a671616b-dirty-suspect 2025-03-19 12:45:02

And see the next weird behavior:

   10489002 |   10498378 | Rdr |A2  03  00  00  00  00  EB  A2                                           |  ok | WRITEBLOCK(3)
   10500318 |   10500958 | Tag |00(4)                                                                    |     |
   10489002 |   10498378 | Rdr |A2  03  00  00  00  00  EB  A2                                           |  ok | WRITEBLOCK(3)
   10502110 |   10502686 | Tag |0A(3)                                                                    |     |
   10532422 |   10537126 | Rdr |30  03  99  9A                                                           |  ok | READBLOCK(3)
   10541626 |   10562490 | Tag |00  00  00  00  77  FF  D8  64  E1  CC  B1  63  4B  A4  94  F0  2E  34   |  ok |
   10661360 |   10670672 | Rdr |A2  03  CC  3B  F5  8C  DA  ED                                           |  ok | WRITEBLOCK(3)
   10672932 |   10673508 | Tag |0A(3)                                                                    |     |

vizit-mfu-proxmark3-after-fix.zip

[iceman1001]

That doesn't make sense.

1. What is the memory dump you are using? Share the file please.
2. What is the simulation output ?
3. Which system is this reader from?

[mishamyte]

That doesn't make sense.

1. What is the memory dump you are using? Share the file please.
2. What is the simulation output ?
3. Which system is this reader from?

Thanks for asking.

1. The file is attached in initial bug, I use the same dump loaded into a emulator memory (hf-mfu-04C9D0427A1790-dump.json)
2. Sim output is attached to my last message (vizit-mfu-proxmark3-after-fix.zip)
3. Reader is Vizit RD-5F from Vizit ecosystem

[iceman1001]

The trace is one thing, I want to see the pm3 client output / command used.

The simulation is acting really strange. None of which makes any sense to me.

[iceman1001]

Join the rfid hacking discord and we can more easily chat there. ( http://iceman.one )
but did you really flash the device with the changes?

[mishamyte]

Fixed by c8cde55!

Thanks!