Honeywell 40 bit card

graybilldustin · 2016-12-15 22:01:56

Hello, my name is Dustin. I work as a security engineer for an integrator, and we are trying to convert a customer who has approximately 5000 Honeywell / PCSC cards in use. Currently we are attempting to reverse engineer the card format for these cards, and we're stuck on the parity bits / checksum / whatever at the end. The cards are 40 bits, the first 16 are the facility code, the second 16 are the card number, and the last 8 we are having trouble deciphering. I have tried all different combinations of parity in the 11 cards I am testing that I can imagine and I can not find a discernible pattern. I found the forum post shown below that leads in the same direction I am heading, and it sounds like maybe OxFFFF has the answer I need. Any help would be greatly appreciated. We have had to decipher custom card formats before and never had an issue, but we've been on this one about 2 weeks now and haven't made any headway.

http://www.proxmark.org/forum/viewtopic.php?id=2569

0xFFFF · 2016-12-15 22:48:21

Here you go...

HID 40bit Honeywell - (P10001).

Bits:        1  2  3  4  5  6  7  8  9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40
Site code:               1  2  3  4  5  6  7  8  9 10 11 12
Card number:                                                 1  2  3  4  5  6  7  8  9 10 11 12 13 14 15 16
One:         1  2  3  4                                                                        
XOR Byte:    [                  1 ] [                   2 ] [                   3 ] [                   4 ] [                   * ]

Are the first four bits all 1's? Because that's the only thing I'm not 100% sure about.

marshmellow · 2016-12-15 22:52:50

if you can post some binary samples of what you have we could try to help you with it.

Edit - looks like FFFF has enlightened us.

Last edited by marshmellow (2016-12-15 22:54:44)

graybilldustin · 2016-12-15 23:08:23

Yes this looks exactly like what we're dealing with, and yes the first 4 bits are always 1's. Can you explain to me how the XOR bytes apply to bits 33-40, this is the part we are having trouble with. Our software wont allow us to ignore these last 8 bits, so we have to account for them. The only mechanism we have to account for them is to program them as odd or even parity bits masked to the rest of the bit string.

To verify, here are the 11 cards we have examples of. Couldn't figure out how best to format it so the columns are as follows: Printed card number, raw hex data, full bit translation, first 4 bits, decimal conversion, next 12 bits, decimal conversion, next 16 bits, decimal conversion, last 8 bits, decimal conversion.

05562 FC2915BA7A 1111110000101001000101011011101001111010 1111 15 110000101001 3113 0001010110111010 5562 01111010 122
05563 FC2915BB7B 1111110000101001000101011011101101111011 1111 15 110000101001 3113 0001010110111011 5563 01111011 123
05564 FC2915BC7C 1111110000101001000101011011110001111100 1111 15 110000101001 3113 0001010110111100 5564 01111100 124
05565 FC2915BD7D 1111110000101001000101011011110101111101 1111 15 110000101001 3113 0001010110111101 5565 01111101 125
05566 FC2915BE7E 1111110000101001000101011011111001111110 1111 15 110000101001 3113 0001010110111110 5566 01111110 126
05001 FC29138950 1111110000101001000100111000100101010000 1111 15 110000101001 3113 0001001110001001 5001 01010000 80
05655 FC291617D4 1111110000101001000101100001011111010100 1111 15 110000101001 3113 0001011000010111 5655 11010100 212
05782 FC29169655 1111110000101001000101101001011001010101 1111 15 110000101001 3113 0001011010010110 5782 01010101 85
05656 FC291618DB 1111110000101001000101100001100011011011 1111 15 110000101001 3113 0001011000011000 5656 11011011 219
01830 FC290726F4 1111110000101001000001110010011011110100 1111 15 110000101001 3113 0000011100100110 1830 11110100 244
01828 FC290724F6 1111110000101001000001110010010011110110 1111 15 110000101001 3113 0000011100100100 1828 11110110 246

0xFFFF · 2016-12-15 23:35:12

graybilldustin wrote:

Our software wont allow us to ignore these last 8 bits, so we have to account for them. The only mechanism we have to account for them is to program them as odd or even parity bits masked to the rest of the bit string.

This is a common problem. Access control systems are often incapable of handling PACS data.
Can you generate the PACS data and directly enter this in?
Perhaps have the last byte as another entry field of some sort?

I have a little utility that may help...
http://cardinfo.barkweb.com.au/index.ph … n=4&sub=13

marshmellow · 2016-12-15 23:59:30

Can you mask specific bits or just all bits from a to b?
How many parities can you have?

graybilldustin · 2016-12-16 02:23:36

To answer the last question; we can mask anything to anything, no limit to numbers of parity bits, where they sit, or which bits they parity. They can even parity other parity bits.

About the previous one; Yes we can create a custom field that takes the last 8 bits and represents them as a decimal value. As long as I can run all the cards through a generator and generate the last 8 bits, I can put them in the CSV when we import the card numbers. I was very excited about the link you provided but I ran a short test on my cards and the data is close but it doesn't quite line up. Below is a comparison. Left column is my card number, middle is what is the true decimal value of the last 8 bits, and the right column is what your utility generated. Any ideas?

5001 80 79
5562 122 122
5563 123 123
5564 124 124
5565 125 125
5566 126 126
5655 212 84
5656 219 91
5782 85 85

marshmellow · 2016-12-16 02:45:53

it appears there is a calculation bug doing the xor for the 5655,5656 on the web tool, as i come up with the correct #. but i cannot explain the 5001 issue as i come up with 79 as well. is it possible the read was bad? or maybe there is an extra adder in the calculation if the Check Byte ends in F add 1?

nice little tool though 0xFFFF

marshmellow · 2016-12-16 03:29:48

you could do 8 even parity bits that is calculated on every 8 bits
example: first parity bit would be calculated on bits 1,9,17,25 (if numbered from left to right 1 - 40)
second on 2,10,18,26 and so on.

but that doesn't address the 5001 issue.

0xFFFF · 2016-12-16 04:00:32

5655, 5656 - It's a bug. I'm investigating now.
5001 - Not sure what is going on there. Not enough information to go on.

* I have had a quick look at this. It's running fine locally just not online.
When I get a bit of time to investigate this, I'll check it out.

* Fixed (19/12/2016)

iceman · 2016-12-16 08:13:52

What a great tool 0xFFFF has made.

graybilldustin · 2016-12-16 15:34:28

Marshmellow is exactly correct. I was able to come up with a format as follows that works perfectly except for card 5001

1-16: Fixed value of 64553
17-32: Card Number
32: Even parity of 1, 9, 17, 25
33: Even parity of 2, 10, 18, 26
34: Even parity of 3, 11, 19, 27
35: Even parity of 4, 12, 20, 28
36: Even parity of 5, 13, 21, 29
37: Even parity of 6, 14, 22, 30
38: Even parity of 7, 15, 23, 31
39: Even parity of 8, 16, 24, 32

It's possible there may just be something off with the cards in the 5000 range. They don't have very many of them, a huge majority of the cards are 5500 and above. Unless you have any other thoughts as to why it's off I am just going to roll with this and fix issues as they pop up. If I have to manually enroll 5% of the cards, it's better than 100%. Thanks for the help everyone!

marshmellow · 2016-12-16 16:55:13

graybilldustin wrote:

It's possible there may just be something off with the cards in the 5000 range.

it is also possible that anytime the checksum ends in an F it might be wrong.

if you get more samples of ones that don't work please post here so we can isolate the algorithm being used once and for all.

graybilldustin · 2016-12-16 16:57:07

We are going to request more cards in the 5000 range. Can you tell me specifically what card numbers would produce a checksum ending in F? We can attempt to get ahold of those cards.

marshmellow · 2016-12-16 17:15:41

a few interesting numbers would be:
5002 (number after problem number)
5535 (checksum calcs as 5F)
5536 (checksum calcs as 60)
5551 (checksum calcs as 6F)
5552 (checksum calcs as 70)
5583 (checksum calcs as 0F)
5599 (checksum calcs as 1F)
5615 (checksum calcs as 2F)
5631 (checksum calcs as 3F)
5644 (checksum calcs as CF)
5660 (checksum calcs as DF)

graybilldustin · 2017-01-06 14:57:51

We didn't have time to get any more cards before we had to implement. So far the only other card to not work was this one:

5519

FC 29 15 8F 50

graybilldustin · 2017-01-18 19:20:36

So the pattern seems to be a HEX value ending in 0. So far none of these cards work. Any thoughts?

5001 FC29138950
5519 FC29158F50
5583 FC2915CF10
1724 FC2906BC70
5644 FC29160CD0

marshmellow · 2017-01-18 20:19:26

it appears there may be a calculation modifier to the xor, that if xor calc ends in an F add 1.

unfortunately there is no way to account for this in a parity mask.

but you can calculate it:

FC xor 29 xor 13 xor 89 = 4F then (If xor answer ends in F, add 1 = 50)

hkplus · 2017-03-22 03:11:56

Why don't you just put a Wiegand data converter between the reader and the panel and use the converter to mask out the bits that you can't enter into your software as XORed bits? Or use a system that can accommodate the data? Many integrators get into the habit of "this is the system that we have been selling for years and that is what we install" even if the system is not really suited to getting the job done. I work in the industry and I see this all of the time.

Last edited by hkplus (2017-03-22 03:12:36)

graybilldustin · 2017-03-22 03:29:49

So I'm guessing you didn't read the whole thread but once the bit mask was determined we were able to enter a custom card format that works for about 99.5% of the cards. The other .5% have masks that can't be explained mathematically as agreed by everyone . So the system did work and was the right fit, but thanks for the assumptions. The issue was never with the software the issue was that I didn't understand the parity bit masking.

I would also mention that had it not worked it would not be cost effective to install a data converter on each reader when you could just as easily order a couple new cards.

And lastly, even though I don't need to defend myself, our software and our company was sought out by the customer based off the purpose they wanted it to fulfill we did not sell them on it. They were prepared to purchase new cards, we were doing them a favor and going the extra mile. It's not our fault that Honeywell locked them in to corp1000 cards that they don't allow anyone else to use.

I'm not starting a flame war here I'm just saying you shouldn't throw mud around without all the information. These guys were insanely helpful and knowledgeable and I feel like we're crapping all over it.

hkplus · 2017-03-23 22:08:59

Your taking my suggestion the wrong way. I will help you if I can. I don't see anything about a data converter in this thread. Wouldn't you want it to work 100% ? If your company writes the software, can you just drop the last bits and forget the parity check? If you have 5000 cards, that is a considerable investment. What does Corp 1000 have to do with Honeywell format? I am curious, what software is this?

Last edited by hkplus (2017-03-24 05:39:58)

Rfidman · 2017-10-11 05:58:29

Hello!!!

Why is it that on a NexWatch card, the hexadecimal values of demodBuffer are not equal to the 3 dumped blocks (T55XX)?
The first block is the card format, but the next three blocks are not the same as the demodBuffer.

iceman · 2017-10-11 07:03:58

@rfidman, don't hijack a thread. Start a new thread with your question.

Proxmark3 community

Announcement

#1 2016-12-15 22:01:56

Honeywell 40 bit card

#2 2016-12-15 22:48:21

Re: Honeywell 40 bit card

#3 2016-12-15 22:52:50

Re: Honeywell 40 bit card

#4 2016-12-15 23:08:23

Re: Honeywell 40 bit card

#5 2016-12-15 23:35:12

Re: Honeywell 40 bit card

#6 2016-12-15 23:59:30

Re: Honeywell 40 bit card

#7 2016-12-16 02:23:36

Re: Honeywell 40 bit card

#8 2016-12-16 02:45:53

Re: Honeywell 40 bit card

#9 2016-12-16 03:29:48

Re: Honeywell 40 bit card

#10 2016-12-16 04:00:32

Re: Honeywell 40 bit card

#11 2016-12-16 08:13:52

Re: Honeywell 40 bit card

#12 2016-12-16 15:34:28

Re: Honeywell 40 bit card

#13 2016-12-16 16:55:13

Re: Honeywell 40 bit card

#14 2016-12-16 16:57:07

Re: Honeywell 40 bit card

#15 2016-12-16 17:15:41

Re: Honeywell 40 bit card

#16 2017-01-06 14:57:51

Re: Honeywell 40 bit card

#17 2017-01-18 19:20:36

Re: Honeywell 40 bit card

#18 2017-01-18 20:19:26

Re: Honeywell 40 bit card

#19 2017-03-22 03:11:56

Re: Honeywell 40 bit card

#20 2017-03-22 03:29:49

Re: Honeywell 40 bit card

#21 2017-03-23 22:08:59

Re: Honeywell 40 bit card

#22 2017-10-11 05:58:29

Re: Honeywell 40 bit card

#23 2017-10-11 07:03:58

Re: Honeywell 40 bit card

Board footer