Extend HID Prox scan with match info and GUI compatibility

[vidonnus]

Summary

• Extend HIDPROX_SCAN with an optional flags byte to return match metadata without breaking legacy clients.
• Add 32-B format support (EP + 14-bit FC + 16-bit CN + OP).
• Fix 32-bit format auto-detection regression (scope repack validation to 32-bit scoring only, preventing ADT31 false rejections).
• Fix FSK2a timing for all HID Prox formats (add remainder tracking to correct fc/8 wave timing, matching Proxmark3 behavior).
• CLI now displays all matching formats with confidence when no format hint is provided.

Related Issues

• Closes HID Prox 32-bit format auto-detection always returns HCP32 — no disambiguation for formats without parity #359

Testing

• Built firmware locally.
• Verified lf hid prox read output with match list and 32-B detection.
• Verified ChameleonUltraGui BLE read path (zero-length payload compatibility).
• Confirmed ADT31 detection not affected by validation changes.

[github-actions]

You are welcome to add an entry to the CHANGELOG.md as well

[github-actions]

Built artifacts for commit e1ce230

Firmware

• Ultra APP DFU Package
• Ultra binaries
• Lite APP DFU Package
• Lite binaries

Client

• Linux
• macOS
• Windows

[GameTec-live]

Ok, so just to make sure;

This is 100% AI, right?

Did you look at the code at all or blindly commit?

[vidonnus]

Ok, so just to make sure;

This is 100% AI, right?

Did you look at the code at all or blindly commit?

Yea, some notes:

• this is 100% implemented by AI (a mixture of models)
• I read over the code (I've got experience in Python but none in C, so I'm not as confident in my review of that)
• I have very little experience with RFID stuff

That being said, I did as much testing as I could both with the CLI and with ChameleonUltraGUI. The functionality seems correct. Also, the scope of this change is quite limited -- it affects HID Prox card reads and HPP32 writes.

I'll be testing this against what I believe is an HPP32 reader today, so I'll hopefully be able to confirm the functionality there as well.

[JulenLeitza]

I tried this with 31bit ADT, with original card read fails, with 31bit bad cloned card reads ok, but dont works on original reader, some control bit is ignored, raw data apears be same on original and clone but some is missing

[vidonnus]

I tried this with 31bit ADT, with original card read fails, with 31bit bad cloned card reads ok, but dont works on original reader, some control bit is ignored, raw data apears be same on original and clone but some is missing

Just to be clear -- this isn't an issue caused by this PR right? You get the same failure on the main firmware?

edit: the 31bit ADT bad cloning is unrelated (upstream -- format not fully known), but the card read failure is related. I'll push a fix for that shortly.

[JulenLeitza]

I tried this with 31bit ADT, with original card read fails, with 31bit bad cloned card reads ok, but dont works on original reader, some control bit is ignored, raw data apears be same on original and clone but some is missing

Just to be clear -- this isn't an issue caused by this PR right? You get the same failure on the main firmware?

edit: the 31bit ADT bad cloning is unrelated (upstream -- format not fully known), but the card read failure is related. I'll push a fix for that shortly.

That's right, in this PR at least it gives a reading error for the original, confirming that something is being missed. With the "release firmware" it reads the UID correctly but fails in emulation and cloning because it leaves the control bit or parameters, and the original card reader reads a lower ID value. If you increase the value by 1, the reader accepts the card, but the UID is different... and you cant use same card on different compatible devices only UID based, on some card UID´s dont work +1 strategy, it shows parity or CRC mismatch. Flipper Zero Clones works perfectly, and shows same RAW data.. i cant see the mismatch

[vidonnus]

@JulenLeitza — couple things here:

1. ADT31 is tricky because the spec doesn’t define parity or the 4 “mystery” bits (1 leading + 3 trailing), so a perfect round‑trip isn’t possible without real cards to reverse‑engineer. The best I can do right now is improve diagnostics (e.g., CLI output of raw + decoded values) so we can see what’s being lost.
2. On behavior: today the CU does "random" format selection when validation can’t fully disambiguate formats. In your case, it will always select ADT31, because it's the only 31-bit format available. I’m hesitant to make it fail‑closed unless maintainers want to change that default, since it would make some cards unreadable. Happy to adjust once @GameTec-live / someone else chimes in.

The reader did not accept my card as an HPP32, and based on the format specs I was able to find a closer (but not-yet-implemented) match -- 32-B. I'm still working through some issues, but I'll have more info / results soon.

[vidonnus]

@GameTec-live -- confirming this is now working as expected with 32-B and updated timing. Please see above issue in the GUI for a breaking change.

[vidonnus]

@JulenLeitza -- try the updated version. You might have a reader that was affected by the timing issue.