Open rg422 opened 1 year ago
Interesting... we should not add bit 37 header for formats larger than 36 bits...
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!
Cannot figure out the problem. raw clone also end up with the same weird indala card
[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
Hypothetically a person should be able to use lf hid sim -w C1k48s —fc 4316 —cn 400001
however upon using that command the result is card cannot be more than 84 bits followed by the command process terminating. If a person runs lf hid clone -w C1k48s —fc 4316 —cn 400001 —em
then not only does the same (inaccurate) error about 84 bits or less display, but the entire pm3 hangs and must be force quit with Ctrl+C
When an HID C1k48s encoded card encounters a reader, the message it repeats is a total of 96 bits, including the 9e header.
feel free to find a solution and make a PR
I'm using a Proxmark 3 easy to read, simulate, brute and write cards for a HID Corporate 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.