LF PAC/Stanley

[gabbe-swe]

The firmware includes internal support for PAC/Stanley, and I’ve successfully added the GUI implementation. While reading PAC/Stanley cards works perfectly, the emulation is not being recognized by the reader.
​After comparing the implementation with Flipper Zero's firmware, I noticed a discrepancy in the data structure:
​Flipper: Prefixes the UID hex with EE 20 (Works).
​Chameleon: Prefixes the UID hex with 20 32 (Does not work).
​This difference in the prefix seems to be preventing the PAC/Stanley reader from reacting to the Chameleon's emulation.

[kevihiiin]

Hi @gabbe-swe, happy to help with the debugging, would love to see PAC/Stannley working with the app!
I checked the format against PM3 and Flipper sources and they're look intential to CUs for me. Does the CU work if you write raw bytes via the CU CLI, i.e. is it limited to just the GUI?

The wire frame: same on all three

All implementations start the raw bitstream with FF 20:

• PM3 cmdlfpac.c:105-106: dst[0] = 0xFF; dst[1] = 0x20; (with help-text example FF2049906D8511C593155B56D5B2649F)
• Flipper protocol_pac_stanley.c: encoded_data[0] = 0xFF; encoded_data[1] = 0x20;
• CU pac.c: produces the same FF 20 49 90 ... via pac_build_bitstream() (8-bit 0xFF sync + 12 × 10-bit UART frames).

So EE 20 isn't a real Flipper protocol prefix, it's almost certainly a Flipper file-format header (the .rfid/key files have their own magic bytes before the card data).

What pac_set_emu_id() expects

Exactly 8 bytes of ASCII — the full card ID including the leading "20". For card 20308C4D:

b"20308C4D"            # 32 30 33 30 38 43 34 44   --- correct
bytes.fromhex("20308C4D")  # \x20\x30\x8C\x4D, 4 bytes  ---wrong

Firmware then wraps it on the wire as sync 0xFF + STX 0x02 + '2' + '0' + <your 8 bytes> + XOR. The '2' '0' the firmware prepends is the start-of-frame marker every PAC tag transmits — not the manufacturer prefix. Real PAC IDs also happen to start with "20", so the framing bytes (32 30) and your ID's first two bytes (32 30) appear back-to-back on the wire, which can look like a doubled prefix but is correct.

Three things to check in your GUI

1. ASCII vs hex. Are you doing "20308C4D".encode() (8 bytes, correct) or bytes.fromhex(...) (4 bytes, wrong)? The latter's first byte 0x20 (ASCII space) lines up suspiciously with the stray 20 you're seeing.
2. Flipper file header. The EE 20 you see in Flipper files is likely format metadata (but I'm not 100% sure, i don't own a FZ). You need to parse the file and extract just the 8-character card ID string, not pass a raw byte slice.
3. Don't strip "20". Some tools store the 6-char "tail" only. CU wants all 8 characters.

Quickest isolation

Round-trip against a real card to separate import bugs from emulation bugs:

resp = cmd.pac_scan()
cmd.pac_set_emu_id(resp.parsed)   # emulate exactly what you read

If that works against your reader, the emulation path is fine and the bug is in how you build the bytes from Flipper data. If you can share the exact hex you're passing to pac_set_emu_id() for a failing card, I can try and recreate it.

We had issues in the past with the emulation of PAC/Stanley on different CU hardware, but using the external oscillator fixed it for us. To rule out a hardware issue, does emulation with the CU work when you write the tag via the CLI? If you read the emulation back via FZ or PM3, is it correct?

[gabbe-swe]

Hi,
Thanks again for the help and for lining this up with PM3, Flipper, and pac.c.
What we implemented in the GUI (matching your notes)

• PAC IDs are normalized with pacUidInputToBytes / isValidPacUidInput in general.dart: 8 printable characters → Uint8List via codeUnits (e.g. "20308C4D" → 32 30 33 30 38 43 34 44); alternatively 16 hex digits for the 8 raw bytes.
• We do not use the wrong pattern equivalent to bytes.fromhex("20308C4D") (4 bytes).
• setPACEmulatorID (5006) receives exactly those 8 bytes; reads go through scanPACTag (3014) and PacCard.fromBytes.
• On Read card, readPAC() runs before EM4100, HID, Viking, and IoProx.
• Copy in the UI documents 8 ASCII or 16 hex and warns against treating the 8-character label as short hex.
  How we export PAC data in the app
  When exporting an LF PAC slot to JSON (CardSave), the uid field is not the ASCII string "20308C4D" but bytesToHexSpace over the 8 bytes (e.g. 32 30 33 30 38 43 34 44), because PacCard inherits LFCard.toString() (slot export → getPACEmulatorID().toString()). On re-import/load, that string is still valid: pacUidInputToBytes strips spaces and treats 16 hex as the correct 8 bytes for 5006 again. So the JSON round-trip matches the device; we do not embed FF 20 or Flipper file headers in that export.
  FF 20 vs EE 20-style file metadata
  As you described: FF 20 on the wire; anything that looks like a Flipper/file header is not passed through to pac_set_emu_id.
  What we have not reproduced on the K2010
  With these changes, we have not hit the usual payload construction mistakes (ASCII mis-read as short hex, stripping the leading "20", pasting a raw slice with file magic, etc.) on the K2010 fob. Our pain point has been more about reading the passive tag (~153 kHz) vs active emulation and the installed PAC reader, not wrong ID encoding in the GUI. If we need to debug a specific case, we can share hex from the 3014 response and the 8 bytes sent on 5006.
  Round-trip
  We still treat scan → feed the same parsed bytes back into emulation as the main sanity check; if anything diverges, we’ll paste the exact 5006 payload.
  Thanks again for the detail and for keeping it consistent with PM3 and Flipper.

[kevihiiin]

Aha, sounds like your GUI path was correct then. A few quick tests on the K2010 to narrow down the bug: Whether we are reading it right, sending the wrong data, or the hardware emulation is off.

I assume you have the CU and the FZ (but no Proxmark)?
Let's comapre the CU and FZ in terms of reading and emulating, maybe we can narrow down the issue.

1 . Can you read the K2010 fob using the CU and the CLI, and note down the ID?
2 . Then:

#	Test	What we get
1	Real K2010 → door reader	Reader baseline
2	FZ reads real K2010	FZ ↔ CU agree on the ID
3	FZ emulates that ID → door reader	Whether the bytes are what the reader expects, both read the tag correctly
4	CU emulates that ID → FZ reads it	Whether CU's bitstream is digitally valid
5	CU emulates that ID → door reader	Your failure case, our hardware emulation is off

Interpretation:

• Test # 3 OK, # 4 OK, # 5 fails → analogue edge issue (see below).
• # 4 fails → bitstream/data bug; please share the 3014 hex and the 8 bytes sent on 5006 (or some version of it).
• # 3 fails → reader expects something non-standard; not a CU bug.

Likely candidate if it's analogue: NRZ is annoyingly sensitive here, unlike Manchester, there's no mid-bit transition. The reader's bit-clock has nothing to resync on across long runs of the same polarity (a PAC frame has stretches of 8+ identical bits). Any small timing or edge anomaly in the modulator gets amplified the longer a run goes. We tried to fix this by using a more precise clock generator, maybe it can be made even more robust

Also worth confirming:

• Slot LF sense: slots 2–8 default off; confirm set_slot_enable(slot, TagSenseType.LF, True) for non-slot-1.
• Is your tag a 153khz one (Google gives me conflicting results)? The CU antenna is only tuned for 125khz, it might be that your door reader is quite picky. If the FZ can emulate it using 125khz, the CU should be able to do the same

[gabbe-swe]

Test results (PAC/Stanley K2010)
Read from real fob on CU (lf pac read):

• CN: EF42AB6B
• Raw: FF2049906D45314592650721CDB21C9F
  | # | Test | Result |
  |---|------|--------|
  | 3 | Flipper emulates same ID → PAC door reader | OK (opens reliably) |
  | 4 | CU emulates → Flipper read | OK (same CN EF42AB6B) |
  | 5 | CU emulates → PAC door reader | FAIL (does not unlock) |
  Summary
  So we have Added requirements.txt #3 OK + Is ISO15693 tag emulation supported ? #4 OK + 修正了gerber一处笔误 #5 FAIL, which matches what you described: the payload / ID is consistent (Flipper agrees with the CU on the card number), but the installed reader does not accept the Chameleon’s LF emulation, while it does accept Flipper’s emulation of the same ID.
  That points to analogue / timing / field margin on the CU side (stable bit clock, NRZ sensitivity on long runs of the same level, antenna tuning at ~125 vs tag/reader expectations, etc.) rather than a wrong pac_set_emu_id / wrong 8-byte encoding from the GUI or CLI.
  We’re on firmware v2.1 over USB; slot is PAC with LF sense enabled.