Keri Encoding Discovered - Updated

jf12345 · 2019-02-20 01:34:50

The Encoding for the MS series tags are as follows:

Each Keri tag has a Card Number and Facility ID.

The Card Number can be upto 10 digits

The Facility ID can be between 0 and 31.

With these two number, the Keri Doors software converts them to an 'internal ID' in the older software and 'card number' in the newer doors.net software. Currently, it is unclear how the software generates the internal ID from the Card Number and Facility ID. The number almost appears to be a hash of some sort from the two numbers.

The Internal ID is what is actually programed into the tag as follows:

The cards transmit 64 bits as follows using PSK1:

000000000000000000000000000001XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX111
^^^^^^^^^^^^^^^^^^^^^^1##########################^^^
Preamble block 29bits of 0s 32bit Internal ID (First bit always 1) 3Bit of 1s Closing

The 32bit card number is generated as follows: The Internal ID is actually a 32bit unsigned integer. Take the 32bit dec integer and convert that to binary. For example, take 123456789 converted to binary =

00000111 01011011 11001101 00010101

Take the first bit and change it to 1:

10000111 01011011 11001101 00010101

64bit programmed id would be:

0000000000000000000000000000010000111010110111100110100010101111

Programmed into a T5577 tag would be as follows:

Block 0: 603E1040
Block 1: 00000004
Block 2: 3ADE68AF

To read a Keri Tag would be as follows:
LF Read
data rawdemod p1

Last edited by jf12345 (2019-02-23 06:10:48)

iceman · 2019-02-23 15:53:03

Excellent!

I added some basic support for demod/read, the clone / sim is commented out still since I haven't tested it but there.

https://github.com/RfidResearchGroup/pr … 06713c467f

jf12345 · 2019-02-24 00:13:55

Amazing job writing the code!

I did some testing and it appears to be decoding the fobs correctly!! I will do more testing on Monday when I have access to the keri system.

The only issue is when cloning the fobs, the configuration block is not set correctly:

       
pm3 --> lf keri clone 12345678
Preparing to clone KERI to T55x7 with Internal Id: 2159829326          
Blk | Data           
----+------------          
00 | 0x601E1040          
01 | 0x00000004          
02 | 0x05E30A77

Block 0 should be 603E1040

iceman · 2019-02-24 00:19:18

No, thanks for finding the data mapping. I still want the FC/CN -> internal id. You have suggestions?

Regarding block0 , I know its not a match. It should however present the t5577 tag ok. Does the reader recognise a cloned tag as is?

jf12345 · 2019-02-24 17:06:10

What I can tell so far is the following:

The CN can be between 1-4194303 Which means its 22bits
The FC can be between 1-31 Which means it 5 bits.
These numbers combined generate the internal ID which is 32 bits with one bit always set to 1 which means total workable bits are 31bits.

In the doors software, you can enroll new cards by entering the following:

CN Starting Range
CN Ending Range
FC
User Assigned Card Number Starting From

Here are some samples I generated:

00000000000000000100000000001000 16392      CN 1 FC 0
00000000001000000000000000001011 2097163  CN 2 FC 0
00000000001000000100000000001010 2113546  CN 3 FC 0

I don't see an obvious pattern to how the bits are getting set but I am still trying to figure it out....

As far as the printed numbers on the cards, I believe there is no relationship between the FC/CN and printed numbers. I think when happens is when you order a box of fobs, they come with a card that lists the FC, CN and printed number range, this information is entered into the 'enroll' menu and then the internal ids are generated. The relationship between the printed CN and Internal ID is stored in the software. If this information is lost, the fob can be registered by presenting it to a reader. The FC/CN are not displayed anywhere in the doors software. This is why I think it might be a one way operation. I also noticed that if a large number of cards is registered, some numbers will get skipped. Not sure if the algorithm has some limits on useable FC/CN combinations.

For the configuration block, I will test it and report back.

iceman · 2019-02-24 17:58:52

the spread out ONES looks like some kind of parity.
the last nibble (4bits) looks reversed for odd cn, and inversed for even cn.
can you get CN 4,5,6,7,8 aswell?

iceman · 2019-02-24 18:00:10

And I moved this thread to LF section.

jf12345 · 2019-02-24 18:30:50

67108872 CN 4 FC 0
67125257 CN 5 FC 0
69206026 CN 6 FC 0
69222411 CN 7 FC 0 
268435464 CN 8 FC 0

iceman · 2019-02-24 18:44:44

Wrong assumption, looks like a bit scramble pattern.
with this data we see what CN 9,10,11,12,13,14,15 should look like

the bit position of bits 1,2,3,4  
   4  3     2        1
0000 0000 0000 0000 0100 0000 0000 1000 -- 16392     -- CN 1 FC 0
0000 0000 0010 0000 0000 0000 0000 1011 -- 2097163   -- CN 2 FC 0
0000 0000 0010 0000 0100 0000 0000 1010 -- 2113546   -- CN 3 FC 0
0000 0100 0000 0000 0000 0000 0000 1000 -- 67108872  -- CN 4 FC 0
0000 0100 0000 0000 0100 0000 0000 1001 -- 67125257  -- CN 5 FC 0
0000 0100 0010 0000 0000 0000 0000 1010 -- 69206026  -- CN 6 FC 0
0000 0100 0010 0000 0100 0000 0000 1011 -- 69222411  -- CN 7 FC 0 
0001 0000 0000 0000 0000 0000 0000 1000 -- 268435464 -- CN 8 FC 0

And the last nibble looks like a checksum, could be aggregated from each four bits groups

0001 0000 0000 0000 0100 0000 0000 10xx -- CN 9 FC 0
0001 0000 0010 0000 0000 0000 0000 10xx -- CN 10 FC 0

jf12345 · 2019-02-25 20:03:45

Interesting, looks like keri was aware of card sequence attacks back in the 90s when this system was created. The new version of door.net might have been written in C# which would make it easy to disassemble to figure out the CN/FC encoding.

For the t5577 configuration, the reader does not respond when block 0 is set to 601E1040. The data rate might be wrong? Not sure if you saw I had the X mode bit enabled?

Do you need anymore CN/FC to Internal conversions?

iceman · 2019-02-25 20:11:40

oo, you didn't pull latest? I fixed the config block yesterday...

Do you have a copy of the door.net software?

jf12345 · 2019-02-25 23:38:27

Great! I made some test cards over the weekend to try today did not realise you updated the code. I can confirm that the clone feature appears to be working perfectly with the update.

I do not have the newer software, just the old software which was written in c++ most likely. Tried to open it in IDA but did not have a lot of time to play around with it. If the newer software was written in c# it could easily be converted back to the CLI to figure out the encoding. Can email the old version if you want, just need to get the installer media.

Last edited by jf12345 (2019-02-25 23:39:26)

iceman · 2019-02-25 23:51:56

Keri seem to have more encodings, your is MS series, with PSK.
The other threads are talking about NX and it uses FSK.

With one old trace file I had , I managed to demod it with this encoding. So that is a good verification.

If you can generate large cardnumbers, like 0x1, 0x2, 0x4,0x8, 0x10, 0x20, 0x40, 0x80, 0x100 so we can see which bit gets lighten up.

Then if you can generate fixed cardnumber but different facility codes, we can map their bit swapping positions aswell..

valdur · 2019-03-22 18:17:51

Hello

I just tried to clone keri tag without any success. Reader refused to even make sound on T5577

Original Keri tag
pm3 --> lf search
[+] KERI Tag Found -- Internal ID: 239174146
[+] Raw: 00000004720C1015
[+] Valid KERI ID found!

pm3 --> lf keri read
[+] KERI Tag Found -- Internal ID: 239174146
[+] Raw: 00000004720C1015

pm3 --> lf keri clone 239174146
[=] Preparing to clone KERI to T55x7 with Internal Id: 2386657794
Blk | Data
----+------------
00 | 0x603E1040
01 | 0x00000004
02 | 0x720C1017

After cloning, read from T5577
pm3 --> lf search
[+] KERI Tag Found -- Internal ID: 239174146
[+] Raw: 00000004720C1017

As you can see RAW differs

Iceman fork (20.03.2019) and RDV40

Last edited by valdur (2019-03-22 18:20:01)

iceman · 2019-03-22 18:46:31

4720C1015  = 10001110010000011000001000000010101
4720C1017  = 10001110010000011000001000000010111

Your keri tag doesn't have 3 stop bits...

iceman · 2019-03-22 19:18:03

You got some more samples from keri tags?

jason1234 · 2019-03-24 19:19:48

I am completely new to this, but wanted to post my similar experience, in case it helps. Cloning a clamshell card that says "FlexPass" on it. lf search identified it as a KERI card. lf keri clone seemed to work, except for the last digit of block 2 being 7 instead of 5 (i.e. binary 111 instead of 101). Looking at the code, I see that the 111 is hard-coded into the cloning procedure and has nothing to do with the internal ID.

The first cloned card did not work with the system. But I was able to get the cloned card to work with the system by doing lf keri clone, and then manually rewriting block 2 to change the 7 to 5.

It's not clear to me whether having 101 at the end instead of 111 is a different KERI format, or maybe this isn't even a KERI card and is just being falsely identified as a KERI? Either way, doing the clone and then manually rewriting block 2 worked for me.

Here is some of the output from proxmark, for reference:

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...

[+] KERI Tag Found -- Internal ID: 1365869378
[+] Raw: 000000068B4C1A15

[+] Valid KERI ID found!

pm3 --> lf keri clone 1365869378
[=] Preparing to clone KERI to T55x7 with Internal Id: 3513353026
Blk | Data
----+------------
00 | 0x603E1040
01 | 0x00000006
02 | 0x8B4C1A17
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...

[+] KERI Tag Found -- Internal ID: 1365869378
[+] Raw: 000000068B4C1A17

[+] Valid KERI ID found!

[+] Chipset detection : Atmel T55xx found

[+] Try `lf t55xx` commands

iceman · 2019-03-24 19:52:12

To say the least, the preamble indentifier between Indala 26bit vs Keri MS isn't huge.

Indala 64 (26b)  preamble 101000000000000000000000000000001
Keri MS          preamble 111000000000000000000000000000001
                           x

The difference is 101 vs 111. So normally these cards with 101 should have been identified as indala 26.
I have been remaking the indala detection, lets see when I push it. Meanwhile I added the stopbits in Keri detection so you should not get these false positives.

valdur · 2019-05-15 13:41:32

Tried to clone the same card again, this time it was detected as Indala and cloned copy worked like a charm.

Thnx Iceman

Proxmark3 community

Announcement

#1 2019-02-20 01:34:50

Keri Encoding Discovered - Updated

#2 2019-02-23 15:53:03

Re: Keri Encoding Discovered - Updated

#3 2019-02-24 00:13:55

Re: Keri Encoding Discovered - Updated

#4 2019-02-24 00:19:18

Re: Keri Encoding Discovered - Updated

#5 2019-02-24 17:06:10

Re: Keri Encoding Discovered - Updated

#6 2019-02-24 17:58:52

Re: Keri Encoding Discovered - Updated

#7 2019-02-24 18:00:10

Re: Keri Encoding Discovered - Updated

#8 2019-02-24 18:30:50

Re: Keri Encoding Discovered - Updated

#9 2019-02-24 18:44:44

Re: Keri Encoding Discovered - Updated

#10 2019-02-25 20:03:45

Re: Keri Encoding Discovered - Updated

#11 2019-02-25 20:11:40

Re: Keri Encoding Discovered - Updated

#12 2019-02-25 23:38:27

Re: Keri Encoding Discovered - Updated

#13 2019-02-25 23:51:56

Re: Keri Encoding Discovered - Updated

#14 2019-03-22 18:17:51

Re: Keri Encoding Discovered - Updated

#15 2019-03-22 18:46:31

Re: Keri Encoding Discovered - Updated

#16 2019-03-22 19:18:03

Re: Keri Encoding Discovered - Updated

#17 2019-03-24 19:19:48

Re: Keri Encoding Discovered - Updated

#18 2019-03-24 19:52:12

Re: Keri Encoding Discovered - Updated

#19 2019-05-15 13:41:32

Re: Keri Encoding Discovered - Updated

Board footer