Research, development and trades concerning the powerful Proxmark3 device.
Remember; sharing is caring. Bring something back to the community.
"Learn the tools of the trade the hard way." +Fravia
You are not logged in.
Time changes and with it the technology
Proxmark3 @ discord
Users of this forum, please be aware that information stored on this site is not private.
I am trying to figure out how the proxmark converts the binary input from the card (after decoding) to the hex output you get from the debugging console when running the "lf hid fskdemod" command. I am trying to use a HID reader and an arduino to read the card and varify the cards are the same when emulating or cloning a card.
When I straight output the binary from the card (minus the parity bits) in hex format i get something like 3e2093e, but the proxmark reads the card as 2007e2093e.
What is the proxmark doing differently during the conversion that it is getting the 2007 instead of just 3? How can I modify the lfops.c file to output the raw binary from the card as well as the regular output during the "lf hid fskdemod" command?
I am VERY new to C programming and can only understand the real basics.
Any help is appreciated.
Last edited by phatasz (2012-04-04 01:09:16)
Offline
The Proxmark is simply showing all 44-bits that are output from the card. The upper bits which appear to be confusing you are used by HID to define the specific card format. By looking at the data stream, your card appears to use a 26-bit format with a facility code of 0xF1 (241 decimal) and a card number of 0x049F (1183 decimal). Your card would have a different format if those upper bits were changed. See the 44-bit binary examples below:
0000 0010 0000 0000 01xx xxxx xxxx xxxx xxxx xxxx xxxx 26-bit
0000 0010 0000 0000 1xxx xxxx xxxx xxxx xxxx xxxx xxxx 27-bit
0000 0010 0000 0001 xxxx xxxx xxxx xxxx xxxx xxxx xxxx 28-bit
0000 0010 0000 001x xxxx xxxx xxxx xxxx xxxx xxxx xxxx 29-bit
0000 0010 0000 01xx xxxx xxxx xxxx xxxx xxxx xxxx xxxx 30-bit
0000 0010 0000 1xxx xxxx xxxx xxxx xxxx xxxx xxxx xxxx 31-bit
0000 0010 0001 xxxx xxxx xxxx xxxx xxxx xxxx xxxx xxxx 32-bit
0000 0010 001x xxxx xxxx xxxx xxxx xxxx xxxx xxxx xxxx 33-bit
0000 0010 01xx xxxx xxxx xxxx xxxx xxxx xxxx xxxx xxxx 34-bit
0000 0010 1xxx xxxx xxxx xxxx xxxx xxxx xxxx xxxx xxxx 35-bit
0000 0011 xxxx xxxx xxxx xxxx xxxx xxxx xxxx xxxx xxxx 36-bit
0000 000x xxxx xxxx xxxx xxxx xxxx xxxx xxxx xxxx xxxx 37-bitHope this helps a little.
Offline
That does explain some things... Now my question is:
If I would like to emulate my card, would it be sufficient to use the card number I am getting from the HID reader?
Ex. lf hid sim 3e2093e
Offline
How can I modify the lfops.c file to output the full binary data that the proxmark sees?
Offline
The HID reader does NOT output all of the information that the card transmits to the reader. It only outputs the facility code, card number and parity information. In order to emulate a HID card you need to provide "all" 44-bits of information.
Offline
carl55, thanks for all the help. I have been able to get the same output with my HID reader/Arduino using your preambles. I am having another issue however, and I wonder if you might be able to shed some light on the subject. I believe the cards I am currently working with are Corporate 1000 cards. They are 35 bit and the "preamble" is slightly different than the 35 bit preamble that you demonstrated. Instead of:
0000 0010 1xxx xxxx xxxx xxxx xxxx xxxx xxxx xxxx xxxx 35-bit
I get a slightly different value:
0000 0010 101x xxxx xxxx xxxx xxxx xxxx xxxx xxxx xxxx
I have tested several cards for the same location and get this same preamble. However, I tested another card that works in the same location and its value is something like:
0000 0010 111x xxxx xxxx xxxx xxxx xxxx xxxx xxxx xxxx or 0000 0010 110x xxxx xxxx xxxx xxxx xxxx xxxx xxxx xxxx
Is this just due to the nature of the Corporate 1000 format, in that the company code or whatever can be something completely different for the cards than the standard 35 bit preamble?
I am trying to understand why there are variations in card values for the same facility.
I appreciate any help into understanding this.
Offline
phatasz,
The upper bits for the 35-bit format shown above is correct. However, for the 35-bit Corporate 1000 format HID uses a complicated parity scheme that consists of three different parity bits. These are the bits that appear to be causing your confusion. You must calculate the parity in the proper order since the last odd parity bit encompasses the even and odd parity bits from the first two parity calculations. Below is a breakdown of how the 35-bits are used in the parity calculations. I think if you stare at it long enough it will start to make sense.
35 bit format with facility code:
PPFFFFFFFFFFFFCCCCCCCCCCCCCCCCCCCCP
.EXX.XX.XX.XX.XX.XX.XX.XX.XX.XX.XX.
.XX.XX.XX.XX.XX.XX.XX.XX.XX.XX.XX.O
OXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
P = Parity
F = Facility Code
C = Card Data
E = Even Parity
O = Odd Parity
X = Bit used in parity calculation
. = Bit not used for parity calculationOffline
carl55,
That is exactly the confusion I was having. Thats a lot for all your help, I think I got everything working just the way I wanted.
Just out of curiousity. Would you happen to know why the HID reader would zero out the two parity bits on the MSB side of the 35bit card value? That is what is happening, which is why I will have to calculate the parity myself using your information. Just wondering if you happen to know the answer to this.
Thanks.
Offline
You didn't specify the model of your reader so I can't say why the upper parity bits are being zero'ed. As an experiment, I tried three different HID readers with a couple of different 35-bit (Corp 1000) formatted cards and they all correctly included all three parity bits in the wiegand data stream. I tried the HID MaxiProx reader, a HID 5455 reader and a HID RP15 MultiClass reader with cards that had both 1's and 0's in the three parity positions. All 35-bit outputs were correct. According to the HID "How to Order Guide" they don't appear to offer any configuration options for a reader that allow the parity bits to be forced to zero (or suppressed). So unless you have a broken or unique (government?) reader I have no idea why your reader does not output the correct parity bits. Sorry.
Offline
Carl55,
I am using both 5455's and 5355's with and without keypads.... I did figure out what my problem was, stupid logic error. Anyway, I really appreciate all your help, I wouldn't have been able to figure this out without all the help you provided.
Offline