Here are the steps I've gone through for dumping a Mifare Ultralight EV1 with the CU and save the correct dump inside the CU, slot 1:
hw connect
hf mfu dump -f ul_ev1_original2.bin -t bin
hw slot delete -s 1 --hf
hw slot type -s 1 -t MF0UL21
hw slot change -s 1
hf mfu eload -f ul_ev1_original2.bin -t bin
hf mfu ewcnt -c 0 -v 16645889
hf mfu ewcnt -c 1 -v 0
hf mfu ewcnt -c 2 -v 512
hf mfu econfig --uid 04986912A11994
hf mfu econfig --set-version 0004030101000E03
hf mfu econfig --set-signature 7773B41E9CEDD0CCC444F60885446D078DCC2F65D9BB3010435E84BFA2DE951D
hw slot store
hw slot enable -s 1 --hf
hf mfu eview
hf mfu ercnt -c 0
hf mfu ercnt -c 1
hf mfu ercnt -c 2
hf mfu econfig --delete-ats
hw slot store

The Chameleon Ultra's Mifare Ultralight EV1 emulation causes issues with various readers: Flipper Zero crashes, Proxmark3 (hf mfu dump --ns) often fails on the first attempt, and some readers fail detection entirely.

Proxmark3 sniff logs reveal two main issues:

Incorrect response to unsupported commands: The Chameleon replies incorrectly to the Mifare Classic AUTH-A (0x60) command, causing reader instability (likely the Flipper crash). A genuine card remains silent.

Timing discrepancies: The Chameleon responds slightly faster during initial selection than a genuine card, potentially causing detection failures with stricter readers.

Steps to Reproduce:

Emulate a Mifare Ultralight EV1 on Chameleon Ultra.

Attempt to read with a Flipper Zero (observe crash).

Attempt to read with Proxmark3 (hf mfu dump --ns) (observe potential first-try failure).

Sniff the interaction using Proxmark3 (hf 14a sniff) while reading with Flipper Zero.

Evidence / Logs:

Key difference observed when Flipper Zero sends Classic AUTH-A (60 00 F5 7B):

(1) Chameleon Ultra (Emulation) Log Excerpt:

Start | End | Src | Data (! denotes parity error) | CRC | Annotation
------------+------------+-----+-------------------------------------------------------------------------+-----+--------------------
... (Selection OK) ...
2815584 | 2820288 | Rdr |60 00 F5 7B | ok | !!! AUTH-A(0) Command (Classic) !!!
2821524 | 2833172 | Tag |00 04 03 01 01 00 0E 03 45 89 | ok | !!! INCORRECT RESPONSE from Chameleon !!!
161106144 | 161107136 | Rdr |52(7) | | WUPA <-- Flipper likely crashed/restarted

(2) Genuine Ultralight EV1 Card Log Excerpt:

Start | End | Src | Data (! denotes parity error) | CRC | Annotation
------------+------------+-----+-------------------------------------------------------------------------+-----+--------------------
... (Selection OK) ...
2662416 | 2667120 | Rdr |60 00 F5 7B | ok | !!! AUTH-A(0) Command (Classic) !!!
2991760 | 2992752 | Rdr |52(7) | | WUPA <-- *** NO RESPONSE FROM GENUINE CARD (Correct) ***

Analysis Summary:

Critical: Chameleon incorrectly replies to Classic AUTH-A 0x60, likely sending GET_VERSION data instead of remaining silent. This crashes the Flipper.

Secondary: Chameleon's initial selection responses (ATQA, UID, SAK) are consistently ~7-9µs faster than the genuine card, potentially violating reader FDT expectations and causing detection failures.

Suggested Fixes:

Fix Unsupported Command Handling: Modify firmware to ensure the Chameleon does not respond to commands unsupported by Ultralight EV1 (especially Classic AUTH-A 0x60). It must remain silent. Distinguish clearly between Classic 0x60 and EV1 GET_VERSION 0x60.

Adjust Initial Timings: Introduce small delays before ATQA/UID/SAK transmission to better match genuine card timing and ISO 14443-3 FDT specifications.

Audit EV1 Commands: Verify the implementation of all EV1-specific commands (GET_VERSION, READ_SIG, READ_CNT, PWD_AUTH, etc.) against the NXP datasheet for accuracy.

Environment:

Reader: Flipper Zero (latest official fw)

Sniffer: Proxmark3 Easy (latest RRG/Iceman fw)

Device: Chameleon Ultra (latest main branch fw)