Hi there. I’m hoping someone might be able to help me figure out a bit of a puzzle I have.
First some quick background: I have a Honeywell/Ademco home alarm system with a 6160PX panel with RFID capability for simple arm and disarm. They refer to this panel and their tags as “PROX” which is already confusing enough, as I learned through testing that it is in fact not a LF T5577 compatible reader, but rather a 13.56mhz HF reader they seem to have gone out of their way not to identify the tag type.
I ordered a Honeywell PROXTG from ebay (again that PROX naming) and discovered they use a SLIX2 ISO15693 tag. I’ve since ordered and had installed an xSLX implant, and have managed to enroll it as a user code on my alarm panel, and it works like a charm. Yay! But…
From scanning the tag’s ID, as well as the test tag I purchased from Ebay, I can’t for the life of me determine what the system is actually using as the actual 4-digit user code. For example, the OEM Honeywell PROXTG from Ebay was labeled on the packaging with a 4 digit code, let’s just say it’s 1234. I can enroll the tag, and sure enough tapping it, or entering 1234 manually on the keypad works as a user code. But the actual hex tag ID doesn’t have 1234 in it, or anything remotely similar to it. Simply converting it from hex to decimal doesn’t reveal any 1234’s either.
As for my implant, it enrolls and functions just like the OEM tag I purchased. I can add it and remove it just like any user code, but since it obviously didn’t come labeled with a code from Honeywell, I basically have a 4-digit user code enrolled in my alarm system which I have no clue what it is. Now, as long as it works (and it does), I guess can live with that if I have to. But my curiosity bone is still itching.
I’m just wondering if anyone has any knowledge or experience with what Honeywell is doing to come up with a 4-digit code from the tag’s hex ID, and if there’s any way I can figure out my implant’s associated 4-digit code.
Likely this printed ID is some representation of a section of binary data that makes up the uid. That representation might be going through a bit of mathematical fuzzing though… but probably not. The easiest way to sort it would be to convert the individual uid bytes to binary data. Then convert the printed dercimal ID into binary and see if anything matches up.
Post the UID and ID if you want to take a crack at it together here on the thread
This is somehow being converted to 4-digit code: 9744
Also I do know from some research that the first 40 bits of the 64 bit ID are the SN, and the remaining bits of the 64 bit ID (01:04:E0) is part of a tag type identifier, so basically all tags, including my implant, end with this.
Oh, and to add just a little more to my confusion, NXP TagInfo reports the ID reverse from that, as E0:04:01:08:48:76:90:50. The linked PDF table 7 reads this way as well.
Ok… 9744… let’s break this down… are all cards for the facility only 4 decimal digits or are they longer lengths, or are there 4 characters but could include hex data like 9AF1?
The first thing we notice about 9744 is that it is not nearly enough data to represent the entire serial number of the card. Think of it more like the last 4 digits of a credit card instead… enough to easily pick the right card from a small pool of your own personal credit cards, but not enough to make payments with. So, that decimal number is just representing a small number of bits, not the entire serial number / ID portion of the UID.
Now let’s establish some notation… h=hex, d=decimal, b=binary… so with that, let’s break down our numbers…
9744d = 2610h and 0010 0110 0001 0000b
4497d = 1191h and 0001 0001 1001 0001b
97d = 61h and 0110 0001b
44d = 2Ch and 0010 1100b
Now if we take the ID portion of your transponder and break each byte down we get;
50h = 80d and 0101 0000b
90h = 144d and 1001 0000b
76h = 118d and 0111 0110b
48h = 72d and 0100 1000b
08h = 8d and 0000 1000b
So we can see there is no easy to find direct representation going on here… let’s try concatenating the UID and see what we get…
5090764808h = 346021054472d
Still nothing obvious… but what if they are using reverse byte order where E0 starts the UID? Then we’d get…
848769050h = 35575468112d
So again, nothing obvious. At this point I think they likely used a modulo operation on the decimal number to arrive at the printed ID. These are often simple, but proprietary. It might help reverse engineer the modulo if you were able to supply a few more UIDs and their associated printed IDs.
Yes, all user codes in the alarm system are 4 digit decimal, as they are intended to be manually entered on the keypad.
Yeah it’s looking like you’re hitting the same wall I did trying to determine how they’re coming up with that 4 digit code. I came to the same conclusion that they must have some proprietary formula they’re using to get there, and I suspect it’s for this exact reason – so that one can not easily scan and steal a credential and use it to determine an alarm code. I unfortunately don’t have any other OEM badges with printed codes to use to reverse engineer it. They’re about $20/ea and I’m not sure if my curiosity bone is itching that much at the moment.
I do appreciate you taking a look at it. There’s probably one person in the entire world who wrote the alg they use to translate the transponder ID to a user code and I suspect whoever they are wouldn’t tell us if we could find them.
uhhhhhhhhhhhh ohhh so the printed number on the card is used as an alarm code for that card? I don’t think I’ve ever heard of that being used in that way before. They definitely have a complex method of arriving at this number if it’s involved in user security like alarms. Most of the time the printed number on the card is just for easy log reference or to simplify access management in the UI.
Well, it’s printed on the packaging that the fob (not card) comes in for installer reference I suppose. It’s not printed on the actual fob. See example. If you enrolled this fob (image from ebay) its associated user access code would be 7615, and would absolutely manually arm and disarm the system.
I can live with not knowing. I was just hoping someone might either have already been down this rabbit hole, or point out something obvious that I was missing.
As for the badge being interpreted as a usable 4-digit alarm code, I can see 2 reasons – 1. It can be integrated into an old alarm panel with only needing to upgrade an inexpensive keypad rather than replace an entire home or commercial alarm system, and 2. being able to easily disable a badge without needing to have it physically present (like in the case of loss, theft, or a disgruntled employee refusing to return it).
You could hook this up to a compatible panel and it would be able to sniff the data coming from the keypad.
Alternatively, grab a cheap logic analyzer or USB oscilloscope, connect directly to the bus (with appropriate level shifting), and decode the data yourself using the algorithm from the ESPHome project.
I definitely don’t have any issue messing with the alarm panel, as I installed the system, and so I can also confirm that it doesn’t have any mains power in the panel or at the keypads. A sniffer was a thought I had, but the only one I was particularly familiar with is the Wiegand which to my knowledge isn’t compatible with Honeywell. My panel is a Vista 20p so I’m going to look into this. Thank you for the info!
