flipperzero-firmware
flipperzero-firmware copied to clipboard
UI/Button freeze while emulating Mifare Ultralight 11
Describe the bug.
I'm getting a UI freeze in 0.65.2 while trying to emulate a Mifare Ultralight 11 card. The emulation screen pops up, light starts flashing, I hold the flipper up to the reader, and the buttons stop responding to input. At this point I am stuck on the emulation screen and need to reboot.
I was connected via the serial interface to watch the debug logs coincidentally, and the last message I got was [D][MfUltralight] Prepare emulation
before the buttons stopped working. Interestingly the serial interface works just fine at this point, so the issue may be related to the ui/button systems specifically.
This issue persists across reboots but it only occurs after holding the flipper up to the reader. Entering and quickly exiting the emulation screen does not cause this issue.
UPDATE: I have attempted a few more times to reproduce the issue and have been able to get the UI to not freeze. And to get a more interesting log line:
[D][MfUltralight] Received invalid buffer less than 8 bits in length
Reproduction
- Attempt to emulate a Mifare Ultralight 11 card
- Unable to exit emulation screen
Target
No response
Logs
1538123 [D][DolphinState] icounter 153, butthurt 0
1538134 [D][MfUltralight] Prepare emulation
<-- at this point the ui/buttons are nonresponsive
1594687 [D][BtBatterySvc] Updating battery level characteristic
Anything else?
>: device_info
device_info_major : 2
device_info_minor : 0
hardware_model : Flipper Zero
hardware_uid : <removed>
hardware_otp_ver : 2
hardware_timestamp : <removed>
hardware_ver : 12
hardware_target : 7
hardware_body : 9
hardware_connect : 6
hardware_display : 1
hardware_color : 2
hardware_region : 2
hardware_region_provisioned : US
hardware_name : M4d0
firmware_commit : ae9038da
firmware_commit_dirty : false
firmware_branch : 0.65.2
firmware_branch_num : 1497
firmware_version : 0.65.2
firmware_build_date : 25-08-2022
firmware_target : 7
radio_alive : true
radio_mode : Stack
radio_fus_major : 1
radio_fus_minor : 2
radio_fus_sub : 0
radio_fus_sram2b : 16K
radio_fus_sram2a : 0K
radio_fus_flash : 24K
radio_stack_type : 3
radio_stack_major : 1
radio_stack_minor : 13
radio_stack_sub : 3
radio_stack_branch : 0
radio_stack_release : 2
radio_stack_sram2b : 19K
radio_stack_sram2a : 14K
radio_stack_sram1 : 0K
radio_stack_flash : 120K
radio_ble_mac : <removed>
enclave_valid_keys : 10
enclave_valid : true
protobuf_version_major : 0
protobuf_version_minor : 12
Hi, I may add some more context as I experienced the same problem.
Just emulating a saved Ultralight card works without freeze. But this sequence triggers the problem:
- Read an Ultralight card
- (optionally save it then open it or jump directly to the next point)
- Emulate the card
- Bring it to the reader
- The reader will "see" the card but not the content (Flipper replies to the anticol sequence but doesn't reply to a read command)
- UI is stuck in emulation mode, need to reset with left+back buttons
Fw dev 8D8481B1 of today
So it seems "reading an actual card" leaves the reader in a state not properly cleaned by "emulating a card towards an actual reader". A workaround is the following sequence:
- Read an Ultralight card
- Save it
- Launch again a Read but without any card, press Back to cancel it
- Load and emulate saved card
At this point everything works as expected.
Hello @lily-mara . Thanks for the report. Unfortunately I can't reproduce the freeze. I repeated the steps you wrote, but my flipper's emulation works just fine with my readers. Flipper is not writing logs on SD card yet (will be added soon), but I need full communication with reader to better understand what is going on. I think that at some point flipper handles reader requests incorrectly. Can you sniff communication with proxmark or other capable tool?
Hello @doegox , thanks for more context! Am I right that Flipper passes anticollision and doesn't reply to read command 30 XX ? Do you have a full log? As I said, I reproduces you steps, but flipper emulates fine on tested readers. Need more context to fix the issue
Hi @gornekich As I wrote you've first to read a card with the Flipper before entering emulation mode, in order to trigger the issue. Here is a log of a proxmark trying to read the emulated MFU by Flipper. As you see the Flipper doesn't reply to the 30F0 command (and it's true for any 30xx read command).
[usb] pm3 --> hf mfu dump
[usb] pm3 --> hf 14a list
[=] downloading tracelog data from device
[+] Recorded activity (trace len = 435 bytes)
[=] start = start of start frame end = end of frame. src = source of transfer
[=] ISO14443A - all times are in carrier periods (1/13.56MHz)
Start | End | Src | Data (! denotes parity error) | CRC | Annotation
------------+------------+-----+-------------------------------------------------------------------------+-----+--------------------
0 | 992 | Rdr |52(7) | | WUPA
2116 | 4484 | Tag |44 00 | |
7040 | 9504 | Rdr |93 20 | | ANTICOLL
10564 | 16452 | Tag |88 04 2d e4 45 | |
19200 | 29728 | Rdr |93 70 88 04 2d e4 45 11 1c | ok | SELECT_UID
30788 | 34308 | Tag |04 da 17 | |
35712 | 38176 | Rdr |95 20 | | ANTICOLL-2
39236 | 45060 | Tag |32 e3 10 91 50 | |
47872 | 58336 | Rdr |95 70 32 e3 10 91 50 da 05 | ok | SELECT_UID-2
59460 | 63044 | Tag |00 fe 51 | |
0 | 992 | Rdr |40(7) | | MAGIC WUPC1
0 | 992 | Rdr |52(7) | | WUPA
2116 | 4484 | Tag |44 00 | |
7040 | 9504 | Rdr |93 20 | | ANTICOLL
10564 | 16452 | Tag |88 04 2d e4 45 | |
19200 | 29728 | Rdr |93 70 88 04 2d e4 45 11 1c | ok | SELECT_UID
30788 | 34308 | Tag |04 da 17 | |
35712 | 38176 | Rdr |95 20 | | ANTICOLL-2
39236 | 45060 | Tag |32 e3 10 91 50 | |
47872 | 58336 | Rdr |95 70 32 e3 10 91 50 da 05 | ok | SELECT_UID-2
59460 | 63044 | Tag |00 fe 51 | |
64768 | 69536 | Rdr |e0 80 31 73 | ok | RATS
0 | 992 | Rdr |52(7) | | WUPA
2116 | 4484 | Tag |44 00 | |
7040 | 9504 | Rdr |93 20 | | ANTICOLL
10564 | 16452 | Tag |88 04 2d e4 45 | |
19200 | 29728 | Rdr |93 70 88 04 2d e4 45 11 1c | ok | SELECT_UID
30788 | 34308 | Tag |04 da 17 | |
35712 | 38176 | Rdr |95 20 | | ANTICOLL-2
39236 | 45060 | Tag |32 e3 10 91 50 | |
47872 | 58336 | Rdr |95 70 32 e3 10 91 50 da 05 | ok | SELECT_UID-2
59460 | 63044 | Tag |00 fe 51 | |
64640 | 69344 | Rdr |30 f0 8d 5f | ok | READBLOCK(240)
Note that I don't have many cards to test here and the card I have is password-protected from block 16 on. So when the Flipper reads the card, at some point (3010) it's facing an error from the card, maybe that follows another code path than for unprotected cards that can be fully dumped. Here is the end of the trace when the Flipper reads the card:
4252636 | 4257404 | Rdr |30 0c 6e 62 | ok | READBLOCK(12)
4258592 | 4279456 | Tag |0c 9e b1 68 91 71 83 1d 84 fc ac 94 b4 13 a6 16 48 8a | ok |
4333996 | 4338700 | Rdr |30 10 83 b8 | ok | READBLOCK(16)
4339952 | 4340592 | Tag |00(4) | |
4401772 | 4406540 | Rdr |39 00 1a 7f | ok | READ CNT(0)
5074332 | 5079100 | Rdr |3e 00 12 32 | ok | CHK TEARING(0)
@doegox thank you! Now I think I understand where is the problem, will try to fix it soon
Thank you for providing the extra context @doegox! I would not have known how to gather this deeper information.
I've just encountered a similar issue when emulating another type of tag, a Viking tag to be more precise, I was stuck in the reader and couldn't do anything but reset. I was not plugged in serial or had any logs of the issue. I was on firmware Version: 0.69.0 commit: 747e81fe radio: 1.13.3
Is this still present in the latest release build?
Yes, I tested dev build of yesterday, still same behavior
The card I was testing was a Ultralight21 password-protected from block 17 and the Flipper could only 16/41 pages
Now I tried a simple old Ultralight. The Flipper can read all 16 pages. Then emulation works fine and I can exit the emulation mode.
So it seems when the read of a block is facing an error, it does not exit as cleanly as when all reads succeed, and emulation just after that state is failing.
Should be fixed and cannot be reproduced on latest release
reopen if issue persists