Thanks for your help @xilni. Can you please confirm the format is correct?
]]>Forgot to include the Kastle 32 bit format, barkweb almost has it right.
Thanks for the update xilni.
What information do you have that proves that the information on barkweb/cardinfo is incorrect? The information supplied came from two independent sources.
The city code is only 5 bits, bit 2 is always set
The parity bits overlap in the middle three bits
Here's my attempt at a correct table:
So yes it would require adding a third city code variable and only printing it for Kastle cards.
My attempt at fixing this for the iceman fork: https://github.com/RfidResearchGroup/proxmark3/pull/23
I'll try to work on a pull request for the mainline and take a look at the pull request you mentioned.
]]>the answer to your other questions lie in the HID PAC formatting. there are no bugs in your displayed data. it successfully identified the HID tag and it's partially decoded complete ID as it is designed to do.
]]>I'm hoping to contribute some code to the iceman fork and (mainline if this issue affects them both but I haven't tested it) but I wanted to seek feedback here first.
When calling lf search on a Kastle prox card, we get the following message, card data replaced with x for privacy.
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:
HID Prox TAG ID: 21xxxxxxxx (xxxxx) - Format Len: 32bit - FC: 0 - Card: 0
[+] Valid HID Prox ID Found!
Now the first thing that I noticed is that the facility code and card number are not displayed formatted. Also there are more than 32 bits of card data displayed when I know for a fact that these are 32 bit cards, the two extra characters of card data are being added before the valid 32 bits (there should only be 8 hex chars, not 10). I believe the problem lies in https://github.com/RfidResearchGroup/pr … hid.c#L168.
In int CmdHIDDemod(const char *Cmd), specifically at line 183 there doesn't seem to be a 32 bit case so cardnum and fc are left with the 0 they were initialized with at L170. Now as to why extra bits are being added, I know it comes from the PrintAndLogEx printing out the value hi but I don't understand the code well enough yet to understand why hi contains 21 at all.
My hardware/software info in case it matters:
[ CLIENT ]
client: iceman build for RDV40 with flashmem; smartcard;
[ ARM ]
bootrom: iceman/master/ 2018-08-23 19:47:58
os: iceman/master/ 2018-08-23 19:48:01
[ FPGA ]
LF image built for 2s30vq100 on 2017/10/25 at 19:50:50
HF image built for 2s30vq100 on 2018/ 8/10 at 11:48:34
[ Hardware ]
--= uC: AT91SAM7S512 Rev B
--= Embedded Processor: ARM7TDMI
--= Nonvolatile Program Memory Size: 512K bytes, Used: 238733 bytes (46) Free: 285555 bytes (54)
--= Second Nonvolatile Program Memory Size: None
--= Internal SRAM Size: 64K bytes
--= Architecture Identifier: AT91SAM7Sxx Series
--= Nonvolatile Program Memory Type: Embedded Flash Memory