bug: Unable to detect/read HF tag (ISO14443-A/B) in GUI while Proxmark3 works

[xz-exp]

Describe the bug
Chameleon Ultra GUI cannot detect/read the HF ISO14443-A / ISO14443-B tag, while Proxmark3 (PM3) can detect it successfully using hf search.

To Reproduce
Steps to reproduce the behavior:

Place the tag on the Chameleon Ultra device.

Open Chameleon Ultra GUI and go to 'Read Card'.

Click on 'Read'.

See error: "No card found. Try to move Chameleon on card"

Expected behavior
The device should be able to detect and read the HF tag information as identified by Proxmark3.

Screenshots
(Please attach your new screenshots here in GitHub)

Version info:

OS: Windows 11

App build number: Unreleased (Main branch latest commit)

Connection type: USB

Chameleon firmware commit: [Please fill in your firmware version if known, e.g. v1.0 / latest]

Also required:

[x] - I've upgraded app to latest app version

[x] - I've upgraded Chameleon firmware to latest version

[x] - I've searched and verified that there is no already created issues

Additional context
Proxmark3 hf search output shows valid ISO14443-A and ISO14443-B tag detection:

[=] ---------- ISO14443-A Information ----------
[+] UID: XX XX XX XX
[+] UID type: ( ONUID, re-used )
[+] ATQA: 88 81
[+] SAK: 70 [1]
[+] Possible types:
[+] P2P Support / Android
[=] proprietary iso18092 card found
[+] Valid ISO 14443-A tag found

[-] Searching for ISO14443-B tag...
[+] ASK C-Ticket
[+] UID: XX XX XX XX ( XXXXXXXXXX )
[+] Product Code: 00
[+] Facility Code: 00
[+] Valid ISO 14443-B tag found

[GameTec-live]

Hm, it looks like this is some weird tag thats both ISO14443-A and ISO14443-B. The ISO-B side you can probably forget as thats unsupported by hardware. For the ISO-A side youd probably need to implement firmware support as IIRC nobody has implemented support for this yet.

[xz-exp]

Thank you for the reply! I'd like to clarify the behavior:

Before writing to this tag, the Chameleon Ultra GUI was actually able to detect and read it normally as a standard card (MIFARE Classic 1K).

The issue only started after I modified and wrote the 7-bit data to the tag. After writing:

Chameleon Ultra GUI can no longer detect or read the tag ("No card found").

Proxmark3 and actual door access readers can still read and recognize the tag perfectly.

It seems the Chameleon Ultra (or firmware) fails to read/detect the card depending on the specific data content written to it.

Here is the Proxmark3 log of the tag before it was written to:
[=] ---------- ISO14443-A Information ----------
[+] UID: XX XX XX XX
[+] UID type: ( ONUID, re-used )
[+] ATQA: 00 04
[+] SAK: 08 [2]
[+] Possible types:
[+] MIFARE Classic 1K
[=] proprietary non iso14443-4 card found, RATS not supported
[+] Valid ISO 14443-A tag found

(Note: The ISO14443-B response in hf search seems to be a ghost detection/false positive from the multi-protocol scan, as the card before writing was just a standard MIFARE Classic 1K).

Here is a side-by-side comparison before and after writing data to the exact same tag:

Before Writing (GUI can read normal MIFARE Classic 1K):
UID: XX XX XX XX

ATQA: 00 04

SAK: 08 (Standard MIFARE Classic 1K)

After Writing (GUI fails with "No card found"):
UID: XX XX XX XX

ATQA: 88 81

SAK: 70

Key Insight:
Modifying the UID/Block 0 data changed the tag's ATQA and SAK responses. Once the SAK changed to 70 (ISO18092/P2P capability), Chameleon Ultra GUI/firmware failed to detect the tag during the anti-collision scan, even though Proxmark3 and real physical access readers can still read it without issues.

Here is additional context comparing the Original Card with the Magic/Copied Card:

The Original Card is a MIFARE Classic 1K EV1 with a 7-byte UID:

UID: XX XX XX XX XX XX XX (7 bytes)

ATQA: 00 44

SAK: 08

Chameleon Ultra GUI Result: Success (Correctly identified as Mifare Classic 1K EV1).

Root Cause Analysis:
After writing data to the target magic card, the Block 0 (Manufacturer Block) configuration likely became corrupted or mismatched (e.g., BCC mismatch or writing a 7-byte UID configuration into a tag that responds as 4-byte/ISO18092).

This caused the tag to report ATQA 88 81 and SAK 70. While Proxmark3 can force-read/display this corrupted state, Chameleon Ultra strictly checks the SAK during the ISO14443-A anti-collision process and fails to handle the unexpected SAK 70 response.

[GameTec-live]

Any chance you can try the official CLI and see if that picks up the card? (just download the exe from the releases)