Issue with hf iclass decrypt not decoding binary properly

[cblack242]

Bug issue

When running 'hf iclass decrypt' it appears to pad 1 to the start of the binary output of the block 7 decoder.

To Reproduce

Steps to reproduce the behavior:

All tests are using latest head version from 4/10/25

test 1

1. hf iclass encode -f H10301 --fc 123 --cn 12345
2. hf iclass dump -f testcard1
3. hf iclass decrypt -f testcard1

test 2

1. hf iclass encode -f c1k35s --fc 123 --cn 12345
2. hf iclass dump -f testcard2
3. hf iclass decrypt -f testcard2

Expected behavior

dropping the padded 1 from the binary output (see screenshots below) and it works fine using wiegand decode

Screenshots

26bit iClass H10301 format card - FC:123 CN: 12345

35bit iClass c1k35s format card - FC: 123 CN: 12345

Correct output if dropping the padded 1 i.e. "wiegand decode -b 10000001111011000000110000001110010"

Desktop (please complete the following information):

• OS: Mac, Windows

• hw version - tested with Generic (Pm3-easy) and RDV4.01 hardware

• hw status
  [usb] pm3 --> hw status
  [#] Memory
  [#] BigBuf_size............. 39660
  [#] Available memory........ 39660
  [#] Tracing
  [#] tracing ................ 0
  [#] traceLen ............... 840
  [#] Current FPGA image
  [#] mode.................... fpga_pm3_hf_15.ncd image 2s30vq100 05-06-2025 02:04:42
  [#] LF Sampling config
  [#] [q] divisor............. 95 ( 125.00 kHz )
  [#] [b] bits per sample..... 8
  [#] [d] decimation.......... 1
  [#] [a] averaging........... yes
  [#] [t] trigger threshold... 0
  [#] [s] samples to skip..... 0
  [#]
  [#] LF T55XX config
  [#] [r] [a] [b] [c] [d] [e] [f] [g]
  [#] mode |start|write|write|write| read|write|write
  [#] | gap | gap | 0 | 1 | gap | 2 | 3
  [#] ---------------------------+-----+-----+-----+-----+-----+-----+------
  [#] fixed bit length (default) | 31 | 20 | 18 | 50 | 15 | n/a | n/a |
  [#] long leading reference | 31 | 20 | 18 | 50 | 15 | n/a | n/a |
  [#] leading zero | 31 | 20 | 18 | 40 | 15 | n/a | n/a |
  [#] 1 of 4 coding reference | 31 | 20 | 18 | 34 | 15 | 50 | 66 |
  [#]
  [#] HF 14a config
  [#] [a] Anticol override........... std ( follow standard )
  [#] [b] BCC override............... std ( follow standard )
  [#] [2] CL2 override............... std ( follow standard )
  [#] [3] CL3 override............... std ( follow standard )
  [#] [r] RATS override.............. std ( follow standard )
  [#] [m] Magsafe polling............ disabled
  [#] [p] Polling loop annotation.... disabled 00000000000000000000000000000000
  [#] Transfer Speed
  [#] Sending packets to client...
  [#] Time elapsed................... 500ms
  [#] Bytes transferred.............. 311808
  [#] Transfer Speed PM3 -> Client... 623616 bytes/s
  [#] Various
  [#] Max stack usage..... 3520 / 8480 bytes
  [#] Debug log level..... 1 ( error )
  [#] ToSendMax........... 18
  [#] ToSend BUFFERSIZE... 2308
  [#] Slow clock.......... 31765 Hz
  [#] Installed StandAlone Mode
  [#] LF HID26 standalone - aka SamyRun (Samy Kamkar)
  [#]
  [usb] pm3 -->

• hw tune
  [=] -------- LF Antenna ----------
  [+] 125.00 kHz ........... 39.76 V
  [+] 134.83 kHz ........... 43.44 V
  [+] 130.43 kHz optimal.... 49.57 V
  [+]
  [+] Approx. Q factor measurement
  [+] Frequency bandwidth... 8.6
  [+] Peak voltage.......... 14.4
  [!] Contradicting measures seem to indicate you're running a PM3GENERIC firmware on a RDV4
  [!] False positives is possible but please check your setup
  [+] LF antenna............ ok

[=] -------- HF Antenna ----------
[+] 13.56 MHz............. 33.81 V
[+]
[+] Approx. Q factor measurement
[+] Peak voltage.......... 9.8
[+] HF antenna ( ok )

[=] -------- LF tuning graph ------------
[+] Orange line - divisor 95 / 125.00 kHz
[+] Blue line - divisor 88 / 134.83 kHz

[=] Q factor must be measured without tag on the antenna

Additional context

Testing various compiled versions from 5/10/25 back to around Dec 2024 and the issues creeps in around Jan 2024