K11101 - Kantech Secure Format (KFS) 32bit (4086x)

iceman · 2016-05-24 14:15:07

By the good grace of another forum user, we have access to a lot of 4086x samples. I'll ask if I can share some, in order to get forum ppl on to figuring out this format.

Seemt to be some issues, K111101, (I missspelled it, spelled it with only 111) I think is the KSF format, and 4086x is a product which uses it. Correct me if Im wrong so we get the details right.

edit:
When I search, I get many more hits for K11101 than for K111101. Maybe someone else misspelled it. Does someone know?

iceman · 2016-05-24 17:37:25

K11101 - Kantech Secure Format, KSF
		
proxmark Read UID	Printed FC (Hex FC)	printed SN
7cca7b605		77 (4D)			13557
7cca73685		77 (4D)			13558
		
62bcaa71d		142 (8E)		12101
62bca279d		142 (8E)		12102
62b8aa785		142 (8E)		12103
62b8a651d		142 (8E)		12104

ntk · 2016-05-25 10:04:16

edit wrong post

Last edited by ntk (2016-05-25 11:21:45)

M&S · 2016-05-25 11:23:06

1/ 7cca7b605 | 119 (77) | 13557 | 11111001100101001111011011000000101
2/ 7cca73685 | 119 (77) | 13558 | 11111001100101001110011011010000101

3/ 62BCAA71D | 142 (8E) | 12101 | 11000101011110010101010011100011101
4/ 62bca279d | 142 (8E) | 12102 | 11000101011110010100010011110011101

Above, I convert 4 tags to binnary and lay them nxt to each other. Kept in mine mind here could be something similar the indala 26bit standard, where indala employs 2 wiegand parity bits, several static bit, the principle of mixing/entwining/swirling of X and Y bit where X stands for FC, Y for CN

Then separting by bit belong to block#
1/ 7cca7b605 | 77 (4D) | 13557 | 111 11001100101001111011011000000101
2/ 7cca73685 | 77 (4D) | 13558 | 111 11001100101001110011011010000101

3/ 62BCAA71D | 142 (8E) | 12101 | 110 00101011110010101010011100011101
4/ 62bca279d | 142 (8E) | 12102 | 110 00101011110010100010011110011101

when look at line 1/ and 2/I see this:
- when FC does not change the first 16 bits of data block#2 stay the same
- the last 7bits of block 2 are the same
- the last 3bits of data block#1 look suspeciously 2static bit '11'

when look at /3 and /4 only
- for 12101 | 10111101000101
- for 12102 | 10111101000110
for the change of +1 for CN in DEC, is in binary to see at the last 2 bits turns from 01 to 10. Now look at line 3/ and line 4/ the change at only two bits:
for CN +1 in DEC system, bit 17 chage from 1 to 0; and bit 25 from 0 turns 1. is there relation ship Y15, Y16 and the change at bit 17th and bit 25th

finally I look at all 4 lines
- bit 32th of data block#1 change with changing FC from 1 to 0 it could be wiegand parity
- the last 3 bits of data block#2 does not changed, could they be static bits '101'
- the bit 29th of data block#2 does changed from 1 to 0, could be wiegand parity

EDIT: corrected the FC for line 1 and line of example data.

Last edited by M&S (2016-05-26 20:29:47)

iceman · 2016-05-25 23:54:51

the last byte in all read uid, for the 200 samples of data I have is:

high nbble is always: 0,1,8,9
low nibble is always. 5, d

0x5 = 0101
0xD = 1101

So the last three bits is always 101. could be static.

M&S · 2016-05-26 12:18:19

then I have some good news, maybe it means something to you
Observing the UID cnverted in binary, we can see:
bit 30,31 of data block1, always 1

bit 4 of data block2, always 0
bit 5 of data block2, always 1
bit 9 of data block2, always 1
bit 12 of data block2, always 0
bit 15 of data block2, always 1
bit 19 of data block2, always 1
bit 21 of data block2, always 0
bit 22 of data block2, always 1
bit 26, 27 of data block2, always 0
bit 30,31,32 of data block2 form the permanent '101'

Now going back to the description 4086X.... has it anything to do with 128, 256, 512, 1024, ..., 4086X the code for mixing X&Y

Last edited by M&S (2016-05-26 23:18:49)

mnelson · 2016-05-26 18:33:54

Try 1 and 2 with Hex 77, Dec 119. Makes more sense.

I don't think the "4086X" has anything to do with 2^x (because it should be 4096 right?).

Some of the other Indala formats have similar names:
4010X Indala (HID) Honeywell (Northern Computers) 27-Bit
4038X Indala (HID) Indala (HID)    85-Bit
4055X Indala (HID) Continental Access    36-Bit
4086X Indala (HID) Kantech    32-Bit

But others don't end in an "X":
40010 Indala (HID) KeyScan    36-Bit
40088 Indala (HID) Siemens    31-Bit
40126 Indala (HID) Sentex    30-Bit
40134 Indala (HID) Indala (HID)    26-Bit
40541 Indala (HID) Cinamon (McGann?) ?-Bit
41106 Indala (HID) DSX    33-Bit
41165 Indala (HID) ?
41408 Indala (HID) ?

While others still don't match either of the above categories:
ASP18260 Indala (HID) Millennium Group ?-Bit
C10106 Indala (HID) Casi-Rusco 40_Bit
MC1000 Indala (HID) Indala (HID) Corp.1000? ?-Bit
NC126W Motorola?Indala Norther Computer 26-Bit?
10022 Indala (HID) ?
17256 Indala (HID) ?

M&S · 2016-05-26 20:35:38

Ah, you caught me without patalon right there. Alright, if then should be 4096 not 4086. ...

Don't worry about Hex 77, DC 119. We have not touched FC and CN anywhere. At first I only compare the UID in bi nary format to fish out the matching bits put them by side, but not forgotten.

Next step we will bring the FC and CN into our observing.

Last edited by M&S (2016-05-26 23:20:46)

M&S · 2016-05-26 21:30:54

Now in this table from line 9 to line 22 are data example the UID binary

from line 25 to 34 is indala table. (It may be non-sense what I do here... but in time of not knowing anything, at least we should make a try. ) we make a hypothese: if this 117/13551 combination would be in a standard 26bit indala chip.

then the quesions is
Q1 could 4086x just a standard indala 26bit form with different name? (before we search the high heaven, and deep sea, we must clear out our house first)
Q2 Will it be looking very different from what the UIDs standing there? (If answer is yes, which means the KSF 4086x would be totally different design if none of the bits comparison makes any sense)

comparison table

What can you see. My answers for this experiment are
A1 no, it is not a re-named indala standdard 26bit
A2. they are not totally different: There are 13 matching fields ( I marked them with blue field, underneath)

Last edited by M&S (2016-05-26 21:31:46)

M&S · 2016-05-26 22:00:47

When I look at the last table what comes into mind is the idea: Can I eliminate a doubt about further points more: the W-parities P1, P2 and CS1, CS2

are they using the same mechanism in
1/ W_parity?
2/ Chksum calculation?

But in order to do that we don't know how long FC or CN in this 4086X is? There are from indala static bits at 7 positions.

We have found out the last 3 '101' always stay static, which left with us 4 bits free. would they use those to increase FC and CN covering space? Perhaps 2 for FC 2 for CN? No, perhaps leave FC, increase CN by 4 bits?

Or should we think simple assume there is still 8bit long FC and 16 bit long CN how can we prove, that that hypothese is wrong?

PS answer:
if FC and CN have more bits, currently they would be unused in the data provided, and will be as zeros on the left side under X1, X2, Y1, Y2.

in the W-sequence all the bit for FC and CN are present+parity bits so where X1 Y1 standing, if they were used, then their values column must make consistent zero columns in all example datas ... hummm there are indeed 4 zero columns .... Now we are really ... humble numble again in front of not-know-nothing

Last edited by M&S (2016-05-26 22:55:15)

M&S · 2016-05-26 23:30:30

Expedition2
Summary Until now
- We are certain bit 30, 31, 32 of data block2 ='101';
- for reason we don't know following bits are static
* bit30, bit31 are alsways 1,
* bit4 of data blck2 always 0
* bit5 of data blck2 always 1
* bit9 of data blck2 always 1
* bit12 of data blck2 always 0
* bit15 of data blck2 always 1
* bit19 of data blck2 always 1
* bit21 of data blck2 always 0
* bit22 of data blck2 always 1
* bit26 of data blck2 always 0
* bit27 of data blck2 always 0
* bit30 of data blck2 always 1
* bit31 of data blck2 always 0
* bit32 of data blck2 always 1

can we eliminate any more bits?

Observing:

Compare uid for case 117/13557 to 117/13558, convert them in binary format only two bits change:
bit17th from 1 to 0,
bit25th from 0 to 1.

Hypothese:
As DEC increased by one
13557 11010011110101
13558 11010011110110
only the last bit changes from 1 to 0. So I guess bit 17 represent the last right bit of CN, which how long we still don't know.

proof:
to prove the idea. we chose random
CN=12101 in bin frmt 10111101000101, so bit 17th of that line should be 1. and it is confirmed.
CN=12111 in bin frmt 10111101001111, so bit 17th of that line should be 1l. and it is confirmed.
CN=12108 in bin frmt 10111101001100, so bit 17th of that line should be 0l. and it is confirmed.

Conclusion:
bit 17th of data block2 represents the last bit of the unknown-how-long CN
.

Next thought:
We can darken that column and look at the rest of the game.

Question:
Do you think I am correct, going ahead like that?

. ....
........

Last edited by M&S (2016-05-27 19:44:31)

M&S · 2016-05-27 20:51:21

Expedition3
Summary see above.

Question open
Q1 how long are FC, CN?
Q2 Chksum can not be at bit28, bit 29 like in indala standard 26bit (because of double 1, double 0 reason) So where is it now, is ist still employed?

Look at this table we also see orange 0-columns and light blue 1-columns, because we are lucky to have so many examples in sequence +1 so we are certain about their columns of static value

find the answers for the two questions will be our next expedition

Observing:
we will start simply assuming Kantech has not changed the length so with FC=8bit long; CN=16 bit long, due to the nature of FC and CN, we have there 9x 0-columns and 10x 1-columns. (as shown in this table )

and if FC and CN were longer, then there would be more 0-columns and we would have to identify them in the UID table. But that is a diff matter

Here, we know all the X,Y bits are represented in the UID, 1:1 and all present. We think Kantech would do similar rule, or it is an insult for indala map index people, then Kantech would have pronounced a totally new product, not an indala based.

So knowing that, we ask can we see the 10x 1-columns and the 9 0-columns in the table of converted UIDs?

Hypothese:
Because if CN and FC are longer numbers, they will ONLY form more zero-columns in the converted UID table. Unless there are zero-column standing unaccountable for, if we use all 1-coloumn and 0-columns there for the standard 8bit FC, and 16 bit CN, then we could safely conclude : FC CN are no longer, as consequence we could then calculate the W-parities and make a new expedition to determine where is can be in the bits of the UIDs table

proof:
to prove the idea. we ...

look in the UIDs table now I something I took for granted before, we do have 9 times the contains-1-columns ... but ... Oooops I secretely wished to see 10... Oh dearing me how can I explain that now to my people, where is that one from sector X or Y too many contains-1-column went under now????

Correction I have made a mistake. There are in the UIDs table 10 always-being-1-columns, exact covers the
10 10 always-being-1-columns from the FC&CN table

stay calm ... Sure someone will know the reason ... You are not alone...

Let do what we are planing to looking here for

we also count in the area from the bit 30th of the 1rst data block, to the bit 32 of the data block2 we have 6x contains-0-columns
Confirm There are in the UIDs table 6 always-being-0-columns, after bit 30th of data block1,
Auwch... now that really hurts ... I expect to see clearly 9x zero-columns to cover all my contains-0-column I have counted in the FC&CN table, where should I think the extra 3 zero column would hide under .... Unless ... unless there are loads of place for zero-column to match, left of the bit30th of data block1 ....

Conclusion:

.This doesn't make sense... Could it be my fu***ng table was wrong?... That could be possible for the reason a real test I hope so much for to confirm the righteousness of my table never being reported back ... Now I am really upset.

Corrected Conclusion

1/ Even though we can not map which contains_1-column of the FC/CN_table to the contains-1-column in the UIDs table yet.(with other words we dont know which X or Y bit standing wher in the UID table, wWe know that the columns are covers and accounted for, so that is good.
2/ The UID table must use at least extra 3 contains-0-column left of the bit30th of data block1 together with the 6 existing0-columns between bit 30 of dadat block1 and bit 32 of data block2, to cover the 0-colume found in the FC-CN-table.
3/ something new has used up the 3 bits between the 30thbit of data block1 and bit32th of data block2

Next thought:
Due to the nature of W-parity bit, the sum of CN plus FC even number 26, 32, 48, so in this case compare to the standard form of 26bit, 8bit FC +16bit Cn, if kantech use longer FC and CN, then it should be the combination +multiple of 2/+multiple of 2 I guess...I am not sure it is right. what you say?

and what are those the 3 unknown columns (or 3 new bits in the raw data of Kantech XSF) which takes the place of the 3 zero-columns found in the FC&CN-tables?

Suspect that only in the current data examples they are 0, with more FC variety their data would change sometimes to 1

and with that it still not solve the problem, but would confirm the existence of 3 new bits, and FC,CN would stay same length

Last edited by M&S (2016-05-29 11:36:24)

iceman · 2016-06-02 13:21:24

We would need more samples from this format to be sure.

If someone has more samples, don't hecitate to contact me about it.

ntk · 2016-06-03 08:56:56

srry wrong post

Last edited by ntk (2016-06-03 09:26:30)

Radee · 2017-10-11 13:07:19

I would like to boast that I was able to discover how the ksf card bits are scrambled. In other words, I can create quite new cards with my FC and CN and put it on the T5577. For now, let me just say that I have found a card analysis method that allowed me to discover how to bits are scrambled - and I did it with 3 example cards only.
I think that my method makes it easier to analyze other Indal card formats.

Details soon... stay tuned :-)

mnelson · 2017-10-12 00:35:20

Radee wrote:

I would like to boast that I was able to discover how the ksf card bits are scrambled. In other words, I can create quite new cards with my FC and CN and put it on the T5577. For now, let me just say that I have found a card analysis method that allowed me to discover how to bits are scrambled - and I did it with 3 example cards only.
I think that my method makes it easier to analyze other Indal card formats.
Details soon... stay tuned :-)

I have an incomplete de-scramble for the Kantech Indala format (it works about 40% of the time). Let me know if you want me to test your efforts on the OEM equipment.

Radee · 2017-10-12 18:18:23

Yes, of course. If you send to me some card numbers then I will send back to you indala uids. If they pass test on your side, then we will go next.

mnelson · 2017-10-16 21:26:41

Radee wrote:

Yes, of course. If you send to me some card numbers then I will send back to you indala uids. If they pass test on your side, then we will go next.

I just replied to your email.

Proxmark3 community

Announcement

#1 2016-05-24 14:15:07

K11101 - Kantech Secure Format (KFS) 32bit (4086x)

#2 2016-05-24 17:37:25

Re: K11101 - Kantech Secure Format (KFS) 32bit (4086x)

#3 2016-05-25 10:04:16

Re: K11101 - Kantech Secure Format (KFS) 32bit (4086x)

#4 2016-05-25 11:23:06

Re: K11101 - Kantech Secure Format (KFS) 32bit (4086x)

#5 2016-05-25 23:54:51

Re: K11101 - Kantech Secure Format (KFS) 32bit (4086x)

#6 2016-05-26 12:18:19

Re: K11101 - Kantech Secure Format (KFS) 32bit (4086x)

#7 2016-05-26 18:33:54

Re: K11101 - Kantech Secure Format (KFS) 32bit (4086x)

#8 2016-05-26 20:35:38

Re: K11101 - Kantech Secure Format (KFS) 32bit (4086x)

#9 2016-05-26 21:30:54

Re: K11101 - Kantech Secure Format (KFS) 32bit (4086x)

#10 2016-05-26 22:00:47

Re: K11101 - Kantech Secure Format (KFS) 32bit (4086x)

#11 2016-05-26 23:30:30

Re: K11101 - Kantech Secure Format (KFS) 32bit (4086x)

#12 2016-05-27 20:51:21

Re: K11101 - Kantech Secure Format (KFS) 32bit (4086x)

#13 2016-06-02 13:21:24

Re: K11101 - Kantech Secure Format (KFS) 32bit (4086x)

#14 2016-06-03 08:56:56

Re: K11101 - Kantech Secure Format (KFS) 32bit (4086x)

#15 2017-10-11 13:07:19

Re: K11101 - Kantech Secure Format (KFS) 32bit (4086x)

#16 2017-10-12 00:35:20

Re: K11101 - Kantech Secure Format (KFS) 32bit (4086x)

#17 2017-10-12 18:18:23

Re: K11101 - Kantech Secure Format (KFS) 32bit (4086x)

#18 2017-10-16 21:26:41

Re: K11101 - Kantech Secure Format (KFS) 32bit (4086x)

Board footer