Errors when using C1k48s Wiegand format with Iceman

rg422 · October 2, 2022, 4:23am

When I use the command “lf hid sim -w C1k48s --fc XXXX --cn XXXX” or “lf hid brute -w C1k48s” I get an error “Tags can only have 84 bits.” I’ve tried leaving the cn and fc as zero but it still throws that error. Any suggestions?

I’m using a proxmark 3 easy flashed with the latest iceman build from proxmarkbuilds.org.

tarcsajana · October 4, 2022, 10:00am

same issue here, clone doesnt work, if use raw data, cloned result will be false indala card

rg422 · October 4, 2022, 3:01pm

I found the issue, the add_HID_header function in wiegand_formatutils.c incorrectly adds 0x09e00000 before the raw string when all that should be added is a 1. A temporary fix is to comment out lines 200, 203, 206, 208, and 211 to prevent it from adding this incorrect header. Simulation works but I have yet to verify that writing this to a card produces a working result. I will be opening a bug report and fully explaining the issue on the github.

tarcsajana · October 4, 2022, 6:30pm

thank you for inspecting, if you have link for github ticket, I would follow there too

rg422 · October 4, 2022, 8:08pm

Here it is, issue #1791

github.com/RfidResearchGroup/proxmark3

Incorrect encoding for C1k48s with HID preamble

opened 03:23PM - 04 Oct 22 UTC

rg422

I'm using a Proxmark 3 easy to read, simulate, brute and write cards for a HID C…orporate 1000 48 bit system using the Wiegand C1k48s format. I can correctly write and simulate a known card when I input a raw data string to the sim and clone commands. Using the wiegand encode command to encode a fc and cn into the C1k48s format with the modifier --pre to add HID preamble results in a string of data that is too long for use. The --pre command does add the necessary preceding "1" on the raw data. Example for C1k48s Facility code 1245, card number 1235 What we get without the HID header added: 803039006072 What we get with HID Header added: 09e00000001803039006072 (note the 1 added before the 8) What we want: 1803039006072 To fix this I commented out the following lines in wiegand_formatutils.c from the add_HID_header function. Line 200: // data->Top |= 0x09e00000; // Extended-length header Line 203: // data->Top |= 0x09e00000; // Extended-length header Line 208: // data->Mid |= 0x20; // Bit 37; standard header Line 211: // data->Mid |= 0x20; // Bit 37; standard header After commenting out those lines and recompiling I had no issues simulating cards. The correct fix would be to identify that when the format is C1k48s do not add the full 0x09e00000 preamble for HID rather just add a preceding 1.

tarcsajana · October 4, 2022, 9:54pm

|Hi! thank you for pointing out the issue. I have commented out the lines, recompiled, and it works, no error during cloning like before. but if I read my neXt implant after this its a false positive Indala ID, and always changing the data. chip is t55xx. here is the output:

[usb] pm3 → lf search

[=] NOTE: some demods output possible binary
[=] if it finds something that looks like a tag
[=] False Positives ARE possible
[=]
[=] Checking for known tags…
[=]
[+] [C1k48s ] HID Corporate 1000 48-bit std FC: 2XX CN: 53XXXX parity ( ok )
[=] found 1 matching format
[+] DemodBuffer:
[+] 1D96A9555555555555555556A5555555A5AXXXXXXXXXXXX

[=] raw: 09e000000001XXXXXXXXXXXX

[+] Valid HID Prox ID found!

[=] Couldn’t identify a chipset

[usb] pm3 → lf hid clone -w C1k48s --fc 2XX --cn 53XXXX
[=] Preparing to clone HID tag
[+] [C1k48s ] HID Corporate 1000 48-bit std FC: 2XX CN: 53XXXX parity ( ok )
[=] Done
[?] Hint: try lf hid reader to verify

[usb] pm3 → lf search

[=] NOTE: some demods output possible binary
[=] if it finds something that looks like a tag
[=] False Positives ARE possible
[=]
[=] Checking for known tags…
[=]
[=] Odd size, false positive?
[+] Indala (len 106) Raw: 8000000000000000004089000000000000408900002ffffffffffff7

[+] Valid Indala ID found!

[=] Couldn’t identify a chipset
[usb] pm3 → lf search

[=] NOTE: some demods output possible binary
[=] if it finds something that looks like a tag
[=] False Positives ARE possible
[=]
[=] Checking for known tags…
[=]
[=] Odd size, false positive?
[+] Indala (len 203) Raw: 8000000000000400000a00000044000aaa55555555555555555554aa

[+] Valid Indala ID found!

[=] Couldn’t identify a chipset
NOTE: some demods output possible binary
[=] if it finds something that looks like a tag
[=] False Positives ARE possible
[=]
[=] Checking for known tags…
[=]
[=] Odd size, false positive?
[+] Indala (len 112) Raw: 8000000000003000008000010000005fffffff7fffcfff7ffffffbea

[+] Valid Indala ID found!

If I clone an EM410x the output is this:
pm3 → lf search

[=] NOTE: some demods output possible binary
[=] if it finds something that looks like a tag
[=] False Positives ARE possible
[=]
[=] Checking for known tags…
[=]
[+] EM 410x ID 1600418DE7
[+] EM410x ( RF/64 )
[=] -------- Possible de-scramble patterns ---------
[+] Unique TAG ID : 680082B1E7
[=] HoneyWell IdentKey
[+] DEZ 8 : 04296167
[+] DEZ 10 : 0004296167
[+] DEZ 5.5 : 00065.36327
[+] DEZ 3.5A : 022.36327
[+] DEZ 3.5B : 000.36327
[+] DEZ 3.5C : 065.36327
[+] DEZ 14/IK2 : 00094493576679
[+] DEZ 15/IK3 : 000446685164007
[+] DEZ 20/ZK : 06080000080211011407
[=]
[+] Other : 36327_065_04296167
[+] Pattern Paxton : 374721511 [0x1655CBE7]
[+] Pattern 1 : 8530807 [0x822B77]
[+] Pattern Sebury : 36327 65 4296167 [0x8DE7 0x41 0x418DE7]
[=] ------------------------------------------------

[+] Valid EM410x ID found!

[usb] pm3 → lf t55xx detect
[=] Chip type… T55x7
[=] Modulation… FSK2a
[=] Bit rate… 4 - RF/50
[=] Inverted… Yes
[=] Offset… 34
[=] Seq. terminator… No
[=] Block0… 001070C0 (auto detect)
[=] Downlink mode… default/fixed bit length
[=] Password set… No

this is the output after hid clone
Cannot figure out the problem. raw clone also end up with the same weird indala card|