[Solved] Proxmark not reading accurate Keri Internal ID #'s

ilovepancakes · 2020-02-09 18:08:51

I'm running a proxmark3 rdv4.01 with latest firmware (tried both official and iceman build). If I lf search or lf keri read a Keri credential, proxmark finds it and spits back an internal ID number for the cred. But, this internal ID number does not match the internal ID number I know is entered into my doors.net Keri software, which makes the original cred work with the system. Furthermore, if I write this internal ID the proxmark read to a blank T5557 card, and then read it back, the internal ID it reads is completely different than the one I just told it to write.

Needless to say, this written to card (as well as using "sim" with the read internal ID does not grant access on my system. However, if I write to a blank card the internal ID that I pull myself from doors.net, even though the proxmark then reads back a completely different internal ID again, the card does authenticate and work.

So, this would seem like a firmware issue, no? The fact that it is reading and coming up with internal ID numbers that differ from actual internal ID, yet it can write successfully a card whose internal ID I know from doors.net.

Anyone else experience this or have any ideas?

Last edited by ilovepancakes (2020-03-28 03:05:33)

iceman · 2020-02-09 22:32:33

That would be because Keri decoding/encoding isn't solved. Only a partial solution is implemented.

Since you seem to have a reader and possibility to generate new cards with it, we could use that to collect some needed data or analyse the reader software.

1. generate cards from card number 0 - 100, with fix facility code, like 1, 127, 255.
2. dump them with proxmark3 and get a long list of raw data for each cardnumber.
3. post here, so ppl can start looking.

ilovepancakes · 2020-02-09 23:33:32

iceman wrote:

That would be because Keri decoding/encoding isn't solved. Only a partial solution is implemented.
Since you seem to have a reader and possibility to generate new cards with it, we could use that to collect some needed data or analyse the reader software.
1. generate cards from card number 0 - 100, with fix facility code, like 1, 127, 255.
2. dump them with proxmark3 and get a long list of raw data for each cardnumber.
3. post here, so ppl can start looking.

Definitely would love to help out, @iceman. Although, I'm a little new to proxmark stuff, so, by generate cards from card number 0-100, do you mean use the "lf keri clone" command with the internal card number being 0, 1, 2, 3, and so on? (i.e. lf keri clone 1")? And then where does the facility code come into that if the writing of card only asks for the internal card number?

Looking forward to providing some hopefully valuable data here for everyone to look at.

iceman · 2020-02-10 04:35:50

no, I didnt mean using the pm3 since... well, I leave it for you to figure out why.

It will be more useful if you get your doors encoding / installed PACS format from your geniune reader.

doors.net Keri software, which makes the original cred work with the system

ilovepancakes · 2020-02-10 19:36:34

iceman wrote:

no, I didnt mean using the pm3 since... well, I leave it for you to figure out why.
It will be more useful if you get your doors encoding / installed PACS format from your geniune reader.
doors.net Keri software, which makes the original cred work with the system

Here is what Doors.NET looks like when I go to add a new user to the system.

And here is what it shows if I check the Calculate Internal Number box.

When I use an official Keri fob style cred, I check that box and enter the imprint number and facility code written on the box, which always seems to be 6 by the way no matter where I buy them from, and Doors.NET calculates the internal number and fills it in under Credentials list there. This is the number that if I just write it with pm3, the cred works, yet pm3 returns a different internal number when I read it back.

So, are you suggesting adding into the software 100 official Keri creds that I have, writing down the Doors.NET calculated internal number, the imprint #, and FC into a spreadsheet and then reading that card with pm3 and dumping the raw content into another spreadsheet column?

Or, do you mean add 100 official Keri creds I have to Doors.NET, and sniff the traffic between that official card and one of my readers?

Again, I've been using Doors.NET and systems like it for a while but only recently introduced myself to the more fun behind scenes work of RFID so forgive me if I am mis-understanding still what you are asking for that would help contribute to development on Keri cards decoding in pm3 firmware. Happy to be here helping out.

Last edited by ilovepancakes (2020-02-10 19:38:27)

iceman · 2020-02-10 20:07:49

yes, since its a bit of work,
try encoding 10 credentials with your software. record the detail (internal, fc, cn) and read it will pm3, take down notes.
we wanna see how the internal id maps to read data extracted with a pm3.

ie:

internal fc , cn,    pm3 bin stream
xxx       6, 100    yyyyy
xxx       6, 101    yyyyy

where you will document internal number from your software and bin stream from pm3 reading the card credential afterwards.

do you get the idea?

iceman · 2020-02-10 20:08:20

can you send me a copy of your software aswell?

ilovepancakes · 2020-02-10 20:20:43

iceman wrote:

yes, since its a bit of work,
try encoding 10 credentials with your software. record the detail (internal, fc, cn) and read it will pm3, take down notes.
we wanna see how the internal id maps to read data extracted with a pm3.
ie:
internal fc , cn,    pm3 bin stream
xxx       6, 100    yyyyy
xxx       6, 101    yyyyy
where you will document internal number from your software and bin stream from pm3 reading the card credential afterwards.
do you get the idea?

I think so, I'll add 10 new Keri creds to system and record imprint, internal ID, FC. Then read those creds with the pm3 and record the data using "bin stream" command? So I am not sniffing any traffic between the Keri MS reader and official creds? Just making a list of those numbers and the results the proxmark returns using "bin stream"?

For the software, you just want an exe installer for it? I'll have to see if I still have that on my system where the software lives.

Last edited by ilovepancakes (2020-02-10 20:21:55)

iceman · 2020-02-10 20:34:31

that sounds about right.
exe.installer works.

ilovepancakes · 2020-02-10 22:38:27

iceman wrote:

that sounds about right.
exe.installer works.

Two things....

1.) Here is the software: https://filebin.net/cxvuvduzvcql9fjx

2.) I added the 10 cards into Doors.NET and took notes on calculated Internal ID, FC on box of fobs, and imprint on fobs. And, to get the data though from pm3 that you need I am running "lf read", then "data samples", which I gathered from other forum posts. But, what is the exact command I need to run after that to get the raw bit stream output you are looking for? I looked through help menu in firmware but couldn't find anything that looks obvious. Or is it just the "Raw" value starting with "E" that is returned with the wrong internal ID when I run "lf search"?

Last edited by ilovepancakes (2020-02-10 22:41:04)

iceman · 2020-02-11 00:01:43

This should do the trick..
otherwise you would need to see when demod (ask/fsk/psk) is used for keri and run data raw ... / data print x

lf keri read
data print x

the x, gives a hex output, I know but it will be enough.

ilovepancakes · 2020-02-11 01:49:55

iceman wrote:

This should do the trick..
otherwise you would need to see when demod (ask/fsk/psk) is used for keri and run data raw ... / data print x
lf keri read
data print x
the x, gives a hex output, I know but it will be enough.

Done. See below. data print x returns the same value that shows up as "Raw" after an lf search or an lf keri read.

Each imprint starts with *K2249- but only the numbers shown below (which come after the dash) as imprint get put into Doors.NET to generate the internal ID. The FC used in Doors.NET with those imprints is 6. The card type/format selected was Keri MS.

Desc.   Internal Card #	   Imprint      Raw DemodBuffer
TEST1	1185762040	   1981543	E0000000C6AD4AF8
TEST2	1384975099	   1981544	E0000000D28D0AFB
TEST3	1384991482	   1981545	E0000000D28D4AFA
TEST4	1387072249	   1981546	E0000000D2AD0AF9
TEST5	1387088632	   1981547	E0000000D2AD4AF8
TEST6	1452083962	   1981548	E0000000D68D0AFA
TEST7	1452100347	   1981549	E0000000D68D4AFB
TEST8	1454181112	   1981550	E0000000D6AD0AF8
TEST9	1454197497	   1981551	E0000000D6AD4AF9
TEST10	1117588219	   1981552	E0000000C29D0AFB

Last edited by ilovepancakes (2020-02-11 15:15:03)

mwalker · 2020-02-11 10:44:55

Just catching up, so feel free to tell me to read whats written
If I have this correct
Internal card # is what has been encoded for access.
Raw Demode is whats out of the proxmark.
2 Quick samples

TEST 1 1185762040 1981543 E0000000C6AD4AF8
1185762040        :                                     0 1000110 10101101 01001010 11111000
E0000000C6AD4AF8  : 11100000 00000000 00000000 00000000 1 1000110 10101101 01001010 11111000

TEST 7 1452100347 1981549 E0000000D68D4AFB
1452100347       :                                     0 1010110 10001101 01001010 11111011
E0000000D68D4AFB : 11100000 00000000 00000000 00000000 1 1010110 10001101 01001010 11111011

So to go from proxmark raw to Card #
Take the last 31 bits and convert to decimal.
or the last 4 bytes AND with 0x7FFF print result in decimal.

TEST	9	1454197497	1981551	E0000000D6AD4AF9
Last 4 bytes of PM3 raw : D6AD4AF9 
                      and 7FFFFFFF
                          --------
                          56AD4AF9

Convert to decimal      1454197497
Original                1454197497

iceman · 2020-02-11 11:07:09

Welcome back @mwalker

The outout is a bit mixed up, right now in the source the keri demod just justs the last 32 bits like you said.
What we wanna find out is the Keri Encoder's internal number. I marked the columns from @ilovepancakes.

desc  cn pm3 output  encode   pm3 raw
TEST 1   1185762040 1981543 E0000000C6AD4AF8

iceman · 2020-02-11 12:01:45

How to get FC/CN, convert between internal id etc is all unsolved for Keri,

/*
000000000000000000000000000001XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX111
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^1###############################^^^
Preamble block 29 bits of ZEROS
32 bit Internal ID (First bit always 1)
3 bit of 1s in the end
How this is decoded to Facility ID, Card number is unknown
Facility ID = 0-31 (indicates 5 bits)
Card number = up to 10 digits
Might be a hash of FC & CN to generate Internal ID
*/

ilovepancakes · 2020-02-11 13:37:05

iceman wrote:

Welcome back @mwalker
The outout is a bit mixed up, right now in the source the keri demod just justs the last 32 bits like you said.
What we wanna find out is the Keri Encoder's internal number. I marked the columns from @ilovepancakes.
desc  cn pm3 output  encode   pm3 raw
TEST 1   1185762040 1981543 E0000000C6AD4AF8

@mwalker To clarify @iceman example headings above, "TEST 1" is just my description for the cred, 1185762040 is the internal card ID number generated by Keri Doors.NET after entering the next number (1981543), which is the imprint on the card itself, along with the FC from the box (6). And of course, the last output starting with "E" is the raw output proxmark3 gives when reading the Keri cred.

iceman · 2020-02-11 14:27:56

Ok, so swapping around, does this fit that actual data.

desc fc  cn   printed encoder     pm3 raw output 
              number  internalid  
TEST  6  1    1981543 1185762040  E0000000C6AD4AF8

Transforming from fc/cn/printed number -> internalid and back, is what we don't know.

ilovepancakes · 2020-02-11 15:08:41

iceman wrote:

Ok, so swapping around, does this fit that actual data.
desc fc  cn   printed encoder     pm3 raw output 
              number  internalid  
TEST  6  1    1981543 1185762040  E0000000C6AD4AF8
Transforming from fc/cn/printed number -> internalid and back, is what we don't know.

Yes, that's all correct EXCEPT cn is just a number I made up and assigned to each test card (to organize the spreadsheet) so has nothing to do with encoding. The DESC should be "TEST1", "TEST2", etc... Only printed (imprint) number, FC, and Internal ID matter here. Also, not sure if this matters but before each imprint on the card is *K2249-

I am pretty sure I read somewhere else on this forum that it's a date code so I am assuming it doesn't have anything to do with encoding/decoding especially since only the imprint after the dash is what gets put into Doors.NET to calculate the Internal ID.

EDIT:

I have improved my original table to clarify. FC is still 6 for all examples below.

Desc.   Encoder Internal ID	   Imprint      pm3 Raw Output
TEST1	1185762040	           1981543	E0000000C6AD4AF8
TEST2	1384975099	           1981544	E0000000D28D0AFB
TEST3	1384991482	           1981545	E0000000D28D4AFA
TEST4	1387072249	           1981546	E0000000D2AD0AF9
TEST5	1387088632	           1981547	E0000000D2AD4AF8
TEST6	1452083962	           1981548	E0000000D68D0AFA
TEST7	1452100347	           1981549	E0000000D68D4AFB
TEST8	1454181112	           1981550	E0000000D6AD0AF8
TEST9	1454197497	           1981551	E0000000D6AD4AF9
TEST10	1117588219	           1981552	E0000000C29D0AFB

Last edited by ilovepancakes (2020-02-11 15:17:53)

iceman · 2020-02-11 15:35:51

ok,

Can you not use imprinted numbers?

Generate encoder internal id's based on FC 6, with these card numbers specially

0
1
2
4
8
16
32
64
128
256
512
1024
2048
4096
8192

ilovepancakes · 2020-02-11 17:01:59

iceman wrote:

ok,
Can you not use imprinted numbers?
Generate encoder internal id's based on FC 6, with these card numbers specially
0
1
2
4
8
16
32
64
128
256
512
1024
2048
4096
8192

Here you go.

Iceman Provided "Imprint"   FC	  Generated Encoder Internal ID
0	                    6	  Error Thrown. Not valid Imprint.
1	                    6	  1074020360
2	                    6	  1076101131
4	                    6	  1141112840
8	                    6	  1342439432
16	                    6	  1075052552
32	                    6	  1074004107
64	                    6	  1074004491
128	                    6	  1074036747
256	                    6	  1074008072
512	                    6	  1610874891
1024	                    6	  1074069512
2048	                    6	  1074528267
4096	                    6	  1074004011
8192	                    6	  1074003992

iceman · 2020-02-11 18:54:07

By the looks like it,

x = fixed 1.
p = even parity

0000 0000 0000 0001 1	 6	 1074020360 1000000000001000100000000001000
0000 0000 0000 0010 2	 6	 1076101131 1000000001001000000000000001011
0000 0000 0000 0100 4	 6	 1141112840 1000100000001000000000000001000
0000 0000 0000 1000 8	 6	 1342439432 1010000000001000000000000001000
0000 0000 0001 0000 16	 6	 1075052552 1000000000101000000000000001000
0000 0000 0010 0000 32	 6	 1074004107 1000000000001000000000010001011
0000 0000 0100 0000 64	 6	 1074004491 1000000000001000000001000001011
0000 0000 1000 0000 128	 6	 1074036747 1000000000001001000000000001011
0000 0001 0000 0000 256	 6	 1074008072 1000000000001000001000000001000
0000 0010 0000 0000 512	 6	 1610874891 1100000000001000000000000001011
0000 0100 0000 0000 1024 6	 1074069512 1000000000001010000000000001000
0000 1000 0000 0000 2048 6	 1074528267 1000000000011000000000000001011
0001 0000 0000 0000 4096 6	 1074004011 1000000000001000000000000101011
0010 0000 0000 0000 8192 6	 1074003992 1000000000001000000000000011000
                                            x                             p

iceman · 2020-02-11 19:04:31

Now I would need CN

16384
32768

And then lets see what

15
63
127

gives

mwalker · 2020-02-12 03:14:29

Any chance I could get an imprint with a different FC (for one that we have for FC: 6)

e.g.
Iceman Provided "Imprint" FC    Generated Encoder Internal ID
1    6    1074020360
1    7    ?

mwalker · 2020-02-12 03:25:51

iceman wrote:

By the looks like it,

x = fixed 1.
p = even parity

0000 0000 0000 0001 1	 6	 1074020360 1000000000001000100000000001000
0000 0000 0000 0010 2	 6	 1076101131 1000000001001000000000000001011
0000 0000 0000 0100 4	 6	 1141112840 1000100000001000000000000001000
0000 0000 0000 1000 8	 6	 1342439432 1010000000001000000000000001000
0000 0000 0001 0000 16	 6	 1075052552 1000000000101000000000000001000
0000 0000 0010 0000 32	 6	 1074004107 1000000000001000000000010001011
0000 0000 0100 0000 64	 6	 1074004491 1000000000001000000001000001011
0000 0000 1000 0000 128	 6	 1074036747 1000000000001001000000000001011
0000 0001 0000 0000 256	 6	 1074008072 1000000000001000001000000001000
0000 0010 0000 0000 512	 6	 1610874891 1100000000001000000000000001011
0000 0100 0000 0000 1024 6	 1074069512 1000000000001010000000000001000
0000 1000 0000 0000 2048 6	 1074528267 1000000000011000000000000001011
0001 0000 0000 0000 4096 6	 1074004011 1000000000001000000000000101011
0010 0000 0000 0000 8192 6	 1074003992 1000000000001000000000000011000
                                            x                             p

Missing the high "0" bit on the binary conversion. Not that I think it matters but the x seems to be a hard coded 1 from other notes.
or are you running with the idea that its 31 bits with MSB being 1 and LSB being Parity. (and the 32nd bit is hard coded to 1 ?)
i.e. showing 31 bits not 32

1074003992 x100 0000 0000 0100 0000 0000 0001 1000
1074003992 0100 0000 0000 0100 0000 0000 0001 1000

iceman · 2020-02-12 10:18:50

right now I am thinking bit scramble pattern.
That will be confirmed once we see the new cn ...

mwalker · 2020-02-13 10:59:09

The following is just a theory based on the data sets provided, and the actual conversion is not yet addressed.
Theory: (so correct anything I get wrong).

- The card "raw" data (low 31 bits) is the FC and Imprint ID (encoded/scrambled)
- In the example data for Imprint ID 1,2,4 ... the single bit values would mean the total 1 bits would be 3, 1 bit for the ID, 2 bits for the FC of 6 (110).
- The card "raw" data has more bits, so I am thinking the imprint ID has a parity as well.
- I also think there as some fixed bits in the Card Raw data.

The following is 4 data samples, 2 from the original test samples and 2 from the 2nd set.

                                                  F            f              f fF EP
                                                  1 xyxyxyxyxyxyxyxyxyxyxyxyxyx  0 yp pp
TEST2 1384975099   1981544  E0000000 D28D0AFB     1 010010100011010000101011111  0 1  1
TEST3 1384991482   1981545  E0000000 D28D4AFA     1 010010100011010100101011111  0 1  0
0000 0100 0000 0000 1024 6 1074069512             1 000000000001010000000000001  0 0  0
0000 1000 0000 0000 2048 6 1074528267             1 000000000011000000000000001  0 1  1

Where
- F : Fixed Bit
- yp : Even parity of all the 'y' bits (every 2nd bit)
- pp : card id parity.
- f : seems to be the location of the 2 FC bits for 110 - 6 (for a starting point) as they again are consistent for the samples so far.

So far, the checks i have seem seems to fit with total "1" bits in the xy data section seem to match the number of "1" bits in the FC and imprint id.

Do we know the size in bits for the FC and Imprint #

iceman · 2020-02-13 13:43:41

...a bit confusing nomenclature.

EP = even parity
OP = odd parity

2bits doesn't fit a FC 6 (110, which is 3bits). 3 bits would only give the possibility for 8 different FC, which is a very low limit.
From experience FC has been 6bits and above, usually starting with 8bits and upwards.

bits assigned | Possible FC #
1 2
2 4
3 8

We will need to get samples with different FC sizes. 1, 16, 128, 256 to verify where the FC is scambled out to.

mwalker · 2020-02-14 00:50:49

Yep, I was more focusing on the higher level packet layout and was trying not to say if something was odd or even parity, more that it looks to be a parity of some soft over some of the data.

As for the FC 2 bits, I was meaning that the FC of 6 when viewed in binary has 2 "1" bits in it "110", regardless of the FC bit length.
e.g. (from above)
0000 0000 0000 0001 1 6 1074020360 1000000000001000100000000001000

Card Number of 1, FC of 6.
lets just say the FC was 7 bits long and the CN was 15 bits long (made up example)
then FC 6: 000 0110 (2 "1" bits)
CN 1 : 000 0000 0000 0001 (1 "1" bit)
So with the data (FC+CN) (not inc any parity) we have a total of 3 "1" bits.

I was using that logic as the basis from some educated guess work, to work out which part of the 31/32 bits of data on the card should refer to the FC+CN, then used those results to start the mapping of the bits.

the "yp" seemed to be a strange bit (not happy with it, just my findings), but what i did notice if you took the parity of every 2nd bit, marked with a y in the xy stream, then the result bit was consistent with every sample I tested. So a parity of the y bits.
I cant think of a reason as to why you would do that, just that it seemed to work.

So my next step was to code my current theory for automated testing, and try to fill in the missing bits as more targeted samples are generated (as you say).

so where my guesses have led me at the moment

From
0000 0100 0000 0000 1024 6 1074069512 1 0000000000010100000000000010 0 0 (31 bits of card payload)

<1 bit Fixed ? > <28 scrambled data bits> <parity A> <parity B>
where:
- Parity A was over even 2nd bit (the y bits in my overview)
- Parity B was the existing known parity.

I have a draft version of the data bit mappings for the FC and Card ID (with some holes and unknowns), and will report back after my testing (I will need more samples, but should be able to identify what samples I need).

Key Note: I am not saying I am correct, just giving some feed back of what I have noticed.

mwalker · 2020-02-14 13:44:15

Update:
For the data sets provided so far, my logic is holding up.
I have mapped the know bits (so will need some more samples to complete)
I also have firmed up the parity bits.
At the moment I am working on Taking the FC and Card # (imprint id) and building the 32bits that would be programmed to the card.

for the 32 bits (32nd bit I have assumed is the hard coded 1)
<"1" Fixed Bit> <"1" Fixed Bit> <28 encode FC and ID> <2 bit Parity>
edit : the above was not correct.
New layout (thanks to the data from the linked thread below)
<"1" Fixed Bit> <27 encode FC and ID> <2 bits unknown "10"> <2 bit Parity>

The 2 Parity bits are <OP EP> and is calculated over the 28bit encoded FC and ID.
For my test code, I seeded my Parity with the 2 binary digits 10, then XORed with each pair of the 28 bits (14 XORs in total)
So, the OP is for the odd bits and the EP is the even bits (where bit 0 is the right most/least significant bit)

Current Map Tables

	//                                                    ? ? ?[- -- -- --]? ? ? ? ? ? ? ? ? ? ?
	byte IDMap[] ={14,21,26,28,20,7, 9,15,12,29,16,19,5,4,0,0,0,6,11,23,25,0,0,0,0,0,0,0,0,0,0,0};
	//             ?[- --]? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?
	byte FCMap[] ={0,3,18,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0};

Note: Given that it seems the FC and ID map into 28bits, the above arrays are too long, but actual length of each is yet to be determined.
? = Unknown
The bytes below the [ ] groups are known to be correct, but unknown actual order.
e.g. In the FC map
Bit 0 is unknown. Bit 1 maps to bit 3 or 18, Bit 2 maps to 3 or 18

For reference - Data Set used for testing (Dec : is the decimal of the 31 encoded bits)

Dec : 1074020360 for FC 6 Card ID : 1
Dec : 1076101131 for FC 6 Card ID : 2
Dec : 1141112840 for FC 6 Card ID : 4
Dec : 1342439432 for FC 6 Card ID : 8
Dec : 1075052552 for FC 6 Card ID : 16
Dec : 1074004107 for FC 6 Card ID : 32
Dec : 1074004491 for FC 6 Card ID : 64
Dec : 1074036747 for FC 6 Card ID : 128
Dec : 1074008072 for FC 6 Card ID : 256
Dec : 1610874891 for FC 6 Card ID : 512
Dec : 1074069512 for FC 6 Card ID : 1024
Dec : 1074528267 for FC 6 Card ID : 2048
Dec : 1074004011 for FC 6 Card ID : 4096
Dec : 1074003992 for FC 6 Card ID : 8192

Dec : 1185762040 for FC 6 Card ID : 1981543
Dec : 1384975099 for FC 6 Card ID : 1981544
Dec : 1384991482 for FC 6 Card ID : 1981545
Dec : 1387072249 for FC 6 Card ID : 1981546
Dec : 1387088632 for FC 6 Card ID : 1981547
Dec : 1452083962 for FC 6 Card ID : 1981548
Dec : 1452100347 for FC 6 Card ID : 1981549
Dec : 1454181112 for FC 6 Card ID : 1981550
Dec : 1454197497 for FC 6 Card ID : 1981551
Dec : 1117588219 for FC 6 Card ID : 1981552

To keep moving forward, we need to complete icemans list of card ids for FC 6.
Note: I expect that at some point the ids wont be valid as the number will be too big. So lets see how we go.

16384
32768
65536
131072
262144
524288
1048576
2097152
4194304
8388608
16777216
33554432
67108864
134217728

If we can, a set of FC tests would be good as well. Leave the card ID as 1 and try each of the following FCs.
0
1
2
4
8
16
32
64
128
256

Thanks

Edit:
Have completed a little more tuning based on information from http://www.proxmark.org/forum/viewtopic.php?id=6281
A few little assumptions above not 100%, but getting closer. My test algorithm works with samples from this thread and that one (with the FC of 0).
So we should be able to complete the Keri-MS mappings when we get the other samples.
I will correct and update the wrong assumptions when I have completed the mapping and testing.

Last edited by mwalker (2020-02-15 12:35:44)

mwalker · 2020-02-16 12:30:01

While waiting for the new round of samples, can I confirm the correct terminology.

desc cn pm3 output encode pm3 raw
TEST 1 1185762040 1981543 E0000000C6AD4AF8

1. The format we are looking at here is called "Keri-MS" ?
2. Card Number = Imprint ID ?
3. Customer Number = the bit scramble of the CN/Imprint ID and FC ?

e.g.

[+] KERI Tag Found -- Internal ID: 450208095
[+] Raw: E0000000D6AD0AF8
[+] BitState ID : -----------????---11110001101110
[+] BitState FC : -----------------------------??-
[+] Descrambled MS : FC 6 - imprint id 1981550

where BitState ID/FC is my debug to show the offsets used.
???? and ?? are the current 2 locations were I know the group is correct, just not the order. i.e. FC 6 (110)
- is were that bit was not mapped or not used (yet)
0/1 is a very high confidence of being the correct value.

Side Note: for the now known bit mappings, I can generate the T55xx blocks 1 and 2 based on the Imprint ID and FC, so we can then add a create card based on those.
I am assuming there is more then one keri format, so we need to label this set as "Keri MS" ?
e.g. something like
lf keri clone ms fc 6 cn 1981550

Thanks

iceman · 2020-02-16 16:17:46

Good one.
Yes, we would need to start name the differen Keri formats.
Especially if we want to be able generate clones based of those different formats.

imprint = printed number on card
internal id = value stored on card

FC/CN doesn't always map to imprint or internal id, but we use them as regards to wiegand format.

mwalker · 2020-02-21 12:43:48

As a quick visual status, this is from my mapping notes (and some assumptions from reading)
I have working code that will map to/from the raw data (64 bit) for the known bits, but am waiting for the missing mappings before submitting.
So we are very close and should be able to complete when we get the extra samples needed.
The "gap" bits are based on the FC/ID being continuous bits from 0-x (e.g. we know bits 0-13 and 17-20 so assume 14,15,16 will be used.

current mappings

Image updated (23 Mar 2020).
Thanks to more samples, the blanks have been filled in.

Last edited by mwalker (2020-03-21 02:44:35)

ilovepancakes · 2020-03-09 03:15:37

mwalker wrote:

Update:
For the data sets provided so far, my logic is holding up.
I have mapped the know bits (so will need some more samples to complete)
I also have firmed up the parity bits.
At the moment I am working on Taking the FC and Card # (imprint id) and building the 32bits that would be programmed to the card.
for the 32 bits (32nd bit I have assumed is the hard coded 1)
<"1" Fixed Bit> <"1" Fixed Bit> <28 encode FC and ID> <2 bit Parity>
edit : the above was not correct.
New layout (thanks to the data from the linked thread below)
<"1" Fixed Bit> <27 encode FC and ID> <2 bits unknown "10"> <2 bit Parity>
The 2 Parity bits are <OP EP> and is calculated over the 28bit encoded FC and ID.
For my test code, I seeded my Parity with the 2 binary digits 10, then XORed with each pair of the 28 bits (14 XORs in total)
So, the OP is for the odd bits and the EP is the even bits (where bit 0 is the right most/least significant bit)
Current Map Tables
	//                                                    ? ? ?[- -- -- --]? ? ? ? ? ? ? ? ? ? ?
	byte IDMap[] ={14,21,26,28,20,7, 9,15,12,29,16,19,5,4,0,0,0,6,11,23,25,0,0,0,0,0,0,0,0,0,0,0};
	//             ?[- --]? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?
	byte FCMap[] ={0,3,18,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0};
Note: Given that it seems the FC and ID map into 28bits, the above arrays are too long, but actual length of each is yet to be determined.
? = Unknown
The bytes below the [ ] groups are known to be correct, but unknown actual order.
e.g. In the FC map
Bit 0 is unknown. Bit 1 maps to bit 3 or 18, Bit 2 maps to 3 or 18
For reference - Data Set used for testing (Dec : is the decimal of the 31 encoded bits)
Dec : 1074020360 for FC 6 Card ID : 1
Dec : 1076101131 for FC 6 Card ID : 2
Dec : 1141112840 for FC 6 Card ID : 4
Dec : 1342439432 for FC 6 Card ID : 8
Dec : 1075052552 for FC 6 Card ID : 16
Dec : 1074004107 for FC 6 Card ID : 32
Dec : 1074004491 for FC 6 Card ID : 64
Dec : 1074036747 for FC 6 Card ID : 128
Dec : 1074008072 for FC 6 Card ID : 256
Dec : 1610874891 for FC 6 Card ID : 512
Dec : 1074069512 for FC 6 Card ID : 1024
Dec : 1074528267 for FC 6 Card ID : 2048
Dec : 1074004011 for FC 6 Card ID : 4096
Dec : 1074003992 for FC 6 Card ID : 8192

Dec : 1185762040 for FC 6 Card ID : 1981543
Dec : 1384975099 for FC 6 Card ID : 1981544
Dec : 1384991482 for FC 6 Card ID : 1981545
Dec : 1387072249 for FC 6 Card ID : 1981546
Dec : 1387088632 for FC 6 Card ID : 1981547
Dec : 1452083962 for FC 6 Card ID : 1981548
Dec : 1452100347 for FC 6 Card ID : 1981549
Dec : 1454181112 for FC 6 Card ID : 1981550
Dec : 1454197497 for FC 6 Card ID : 1981551
Dec : 1117588219 for FC 6 Card ID : 1981552
To keep moving forward, we need to complete icemans list of card ids for FC 6.
Note: I expect that at some point the ids wont be valid as the number will be too big. So lets see how we go.
16384
32768
65536
131072
262144
524288
1048576
2097152
4194304
8388608
16777216
33554432
67108864
134217728

If we can, a set of FC tests would be good as well. Leave the card ID as 1 and try each of the following FCs.
0
1
2
4
8
16
32
64
128
256
Thanks

Edit:
Have completed a little more tuning based on information from http://www.proxmark.org/forum/viewtopic.php?id=6281
A few little assumptions above not 100%, but getting closer. My test algorithm works with samples from this thread and that one (with the FC of 0).
So we should be able to complete the Keri-MS mappings when we get the other samples.
I will correct and update the wrong assumptions when I have completed the mapping and testing.

For some reason did not get any email notifications on all these recent posts so sorry for the delay here! To confirm you would like me to use Doors.NET with the above card numbers and FC 6 and then Card # 1 with changing FC's and report back the generated Internal ID for each of those?

Last edited by ilovepancakes (2020-03-09 03:16:05)

mwalker · 2020-03-09 05:04:57

Yes please.

ilovepancakes · 2020-03-18 20:08:22

Imprint    FC   Generated Internal Card ID
16384	   6	1208221707
32768	   6	1074135051
65536	   6	1074004232
131072	   6	1074006027
262144	   6	1082392587
524288	   6	1107558411
1048576	   6	1074004040
2097152	   6	1074005000
4194304	   6	1074003977
8388608	   6	1074003977
16777216   6	1074003977
33554432   6	1074003977
67108864   6	1074003977
134217728  6	1074003977
--------------	-----	--------------
1	   0	16392
1	   1	24586
1	   2	1073758217
1	   4	278537
1	   8	4210697
1	   16	16793609
1	   32	Error: Facility code for Keri MS cards must be less than 32.

iceman · 2020-03-18 21:08:57

Nice!

FC less than 32

ilovepancakes · 2020-03-18 21:15:58

iceman wrote:

Nice!
FC less than 32

There were a couple other choices of "Keri" formats besides "MS" so not sure if those take higher FC numbers but don't have any of those types of creds to play with anyway so only did all this with MS format. Were you able to install and run Doors.NET or it asked for a license or something?

mwalker · 2020-03-18 22:53:05

Thanks, hope to add to the decode tables over the next few days.

It was interesting that the card ID did not error, but gave the same "max" id

2097152	   6	1074005000
4194304	   6	1074003977
8388608	   6	1074003977
16777216   6	1074003977
33554432   6	1074003977
67108864   6	1074003977
134217728  6	1074003977

4194304 => 1000000 00000000 00000000 (23 bits)

iceman · 2020-03-18 23:16:13

I missed that. 24bits max?

mwalker · 2020-03-18 23:19:24

My origin notes I was expecting 22 (but 2 bits to be confirmed). so 23-24 is sounding about right.
See what happens after I update the tables, something my jump out as I work though it

mwalker · 2020-03-21 02:52:41

I have complete the table updates and testing now.
The FC is 5 Bits (so 0-31)
The Card ID seems to be 22 bits (0 - 4194303)

2097152	   6	1074005000  (22 bits)  100000 00000000 00000000
4194304	   6	1074003977  (23 bits) 1000000 00000000 00000000
8388608	   6	1074003977  same as above

Bit 22 (zero based) is part of the FC, so 1074003977 results in card id of 0 for FC 6

mwalker · 2020-03-21 09:48:10

The latest rrg should have the fully decode Keri MS now. Please test and provide feed back.

iceman · 2020-03-21 09:52:00

Great!

I think @ilovepancakes can edit his first post and add the prefix solved to the subject line.

mwalker · 2020-03-22 09:21:14

On top of the original issue being solved, we have updated the keri command to support cloning with the FC and CN for the MS format/type (in the rrg code).

@ilovepancakes : while i have tested everything I can, I cant test the cloned card on a real reader. It would be great if you could test the new clone command as well and ensure the reader is happy with it.

Thanks

ilovepancakes · 2020-03-28 03:06:42

Awesome! I have no idea about most of what you wrote and how you did it, but happy to have helped, lol. I won't be back at the site with my reader for a little while most likely but yes will test for real next time I am there and report back.

ilovepancakes · 2020-03-29 18:57:22

Still won't be back at reader soon to test for real but I did test out the new code and clone command does seem to work now as well as reading FC and imprint card # off actual keri ms card. It does show command execution timeout after running the clone but still seems to write to the blank T5557 card okay.

mwalker · 2020-03-29 22:14:19

yep, understand.
Can you give the example of the command that caused the timeout. I never saw that at all and run it many many times, so might be some weird thing that the exact data will show up.

ilovepancakes · 2020-04-05 00:51:35

Here is an example where it hangs with no errors displayed even though the write does seem to happen okay.

[usb] pm3 --> lf keri clone t m f 6 c 595361
[+] Scrambled MS : FC 6 - CN 595361 to RAW : E0000000C205D1A9          
[=] Preparing to clone KERI to T55x7 with Internal Id: c205d1a9          
[+] Blk | Data           
[+] ----+------------          
[+]  00 | 603E1040          
[+]  01 | 00000006          
[+]  02 | 102E8D4F

Here is an example where an error is showed:

[usb] 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: 1107677609          
[+] Raw: E0000000C205D1A9          
[+] Descrambled MS : FC 6 - CN 595361
          
          
[+] Valid KERI ID found!
          
[!]  ⚠️  command execution time out

Overall, the firmware seems to have issues like after writing one card, other writes or wipes timeout unless I power cycle the pm3.

For example, I get the following if I try to run that command after writing to the card with command from before.

[usb] pm3 --> lf t55xx wipe
          
[=] Begin wiping T55x7 tag
          
[=] Default configation block 000880E0          
[=] Writing page 0  block: 00  data: 0x000880E0           
[!!]  ? Error occurred, device did not ACK write operation.          
[!!]  ? Write failed          
[!]  ⚠️  Warning: error writing blk 0          
[=] Writing page 0  block: 01  data: 0x00000000

Last edited by ilovepancakes (2020-04-05 00:52:57)

mwalker · 2020-04-05 01:48:31

Not sure, seems to working here.

[usb] pm3 --> lf keri clone t m f 6 c 595361
[+] Scrambled MS : FC 6 - CN 595361 to RAW : E0000000C205D1A9
[=] Preparing to clone KERI to T55x7 with Internal Id: c205d1a9
[+] Blk | Data
[+] ----+------------
[+]  00 | 603E1040
[+]  01 | 00000006
[+]  02 | 102E8D4F


[usb] pm3 --> lf sea
[=] NOTE: some demods output possible binary
[=] if it finds something that looks like a tag
[=] False Positives ARE possible
[=]
[=] Checking for known tags...
[=]
#db# Starting Hitag reader family
#db# Configured for hitag2 reader
#db# Detected unexpected number of manchester decoded samples [2]
[+] KERI Tag Found -- Internal ID: 1107677609
[+] Raw: E0000000C205D1A9
[+] Descrambled MS : FC 6 - CN 595361


[+] Valid KERI ID found!


[usb] pm3 --> lf keri clone t m f 6 c 595361
[+] Scrambled MS : FC 6 - CN 595361 to RAW : E0000000C205D1A9
[=] Preparing to clone KERI to T55x7 with Internal Id: c205d1a9
[+] Blk | Data
[+] ----+------------
[+]  00 | 603E1040
[+]  01 | 00000006
[+]  02 | 102E8D4F

[usb] pm3 --> lf sea
[=] NOTE: some demods output possible binary
[=] if it finds something that looks like a tag
[=] False Positives ARE possible
[=]
[=] Checking for known tags...
[=]
#db# Starting Hitag reader family
#db# Configured for hitag2 reader
#db# Unknown frame length: 160
[+] KERI Tag Found -- Internal ID: 1107677609
[+] Raw: E0000000C205D1A9
[+] Descrambled MS : FC 6 - CN 595361


[+] Valid KERI ID found!

[usb] pm3 --> lf t55 wipe

[=] Begin wiping T55x7 tag

[=] Default configation block 000880E0
[=] Writing page 0  block: 00  data: 0x000880E0
[=] Writing page 0  block: 01  data: 0x00000000
[=] Writing page 0  block: 02  data: 0x00000000
[=] Writing page 0  block: 03  data: 0x00000000
[=] Writing page 0  block: 04  data: 0x00000000
[=] Writing page 0  block: 05  data: 0x00000000
[=] Writing page 0  block: 06  data: 0x00000000
[=] Writing page 0  block: 07  data: 0x00000000
[usb] pm3 -->

Is it writing to a card or fob ?

ilovepancakes · 2020-04-05 01:51:02

Writing to a card, and despite the error is does indeed appear to write the data correctly. And then further writes don't work until pm3 is power cycled.

Proxmark3 community

Announcement

#1 2020-02-09 18:08:51

[Solved] Proxmark not reading accurate Keri Internal ID #'s

#2 2020-02-09 22:32:33

Re: [Solved] Proxmark not reading accurate Keri Internal ID #'s

#3 2020-02-09 23:33:32

Re: [Solved] Proxmark not reading accurate Keri Internal ID #'s

#4 2020-02-10 04:35:50

Re: [Solved] Proxmark not reading accurate Keri Internal ID #'s

#5 2020-02-10 19:36:34

Re: [Solved] Proxmark not reading accurate Keri Internal ID #'s

#6 2020-02-10 20:07:49

Re: [Solved] Proxmark not reading accurate Keri Internal ID #'s

#7 2020-02-10 20:08:20

Re: [Solved] Proxmark not reading accurate Keri Internal ID #'s

#8 2020-02-10 20:20:43

Re: [Solved] Proxmark not reading accurate Keri Internal ID #'s

#9 2020-02-10 20:34:31

Re: [Solved] Proxmark not reading accurate Keri Internal ID #'s

#10 2020-02-10 22:38:27

Re: [Solved] Proxmark not reading accurate Keri Internal ID #'s

#11 2020-02-11 00:01:43

Re: [Solved] Proxmark not reading accurate Keri Internal ID #'s

#12 2020-02-11 01:49:55

Re: [Solved] Proxmark not reading accurate Keri Internal ID #'s

#13 2020-02-11 10:44:55

Re: [Solved] Proxmark not reading accurate Keri Internal ID #'s

#14 2020-02-11 11:07:09

Re: [Solved] Proxmark not reading accurate Keri Internal ID #'s

#15 2020-02-11 12:01:45

Re: [Solved] Proxmark not reading accurate Keri Internal ID #'s

#16 2020-02-11 13:37:05

Re: [Solved] Proxmark not reading accurate Keri Internal ID #'s

#17 2020-02-11 14:27:56

Re: [Solved] Proxmark not reading accurate Keri Internal ID #'s

#18 2020-02-11 15:08:41

Re: [Solved] Proxmark not reading accurate Keri Internal ID #'s

#19 2020-02-11 15:35:51

Re: [Solved] Proxmark not reading accurate Keri Internal ID #'s

#20 2020-02-11 17:01:59

Re: [Solved] Proxmark not reading accurate Keri Internal ID #'s

#21 2020-02-11 18:54:07

Re: [Solved] Proxmark not reading accurate Keri Internal ID #'s

#22 2020-02-11 19:04:31

Re: [Solved] Proxmark not reading accurate Keri Internal ID #'s

#23 2020-02-12 03:14:29

Re: [Solved] Proxmark not reading accurate Keri Internal ID #'s

#24 2020-02-12 03:25:51

Re: [Solved] Proxmark not reading accurate Keri Internal ID #'s

#25 2020-02-12 10:18:50

Re: [Solved] Proxmark not reading accurate Keri Internal ID #'s

#26 2020-02-13 10:59:09

Re: [Solved] Proxmark not reading accurate Keri Internal ID #'s

#27 2020-02-13 13:43:41

Re: [Solved] Proxmark not reading accurate Keri Internal ID #'s

#28 2020-02-14 00:50:49

Re: [Solved] Proxmark not reading accurate Keri Internal ID #'s

#29 2020-02-14 13:44:15

Re: [Solved] Proxmark not reading accurate Keri Internal ID #'s

#30 2020-02-16 12:30:01

Re: [Solved] Proxmark not reading accurate Keri Internal ID #'s

#31 2020-02-16 16:17:46

Re: [Solved] Proxmark not reading accurate Keri Internal ID #'s

#32 2020-02-21 12:43:48

Re: [Solved] Proxmark not reading accurate Keri Internal ID #'s

#33 2020-03-09 03:15:37

Re: [Solved] Proxmark not reading accurate Keri Internal ID #'s

#34 2020-03-09 05:04:57

Re: [Solved] Proxmark not reading accurate Keri Internal ID #'s

#35 2020-03-18 20:08:22

Re: [Solved] Proxmark not reading accurate Keri Internal ID #'s

#36 2020-03-18 21:08:57

Re: [Solved] Proxmark not reading accurate Keri Internal ID #'s

#37 2020-03-18 21:15:58

Re: [Solved] Proxmark not reading accurate Keri Internal ID #'s

#38 2020-03-18 22:53:05

Re: [Solved] Proxmark not reading accurate Keri Internal ID #'s

#39 2020-03-18 23:16:13

Re: [Solved] Proxmark not reading accurate Keri Internal ID #'s