*
Research, development and trades concerning the powerful Proxmark3 device.
*

*
Remember; sharing is caring. Bring something back to the community.*

"Learn the tools of the trade the hard way." **+Fravia**

You are not logged in.

- Topics: Active | Unanswered

**iceman****Administrator**- Registered: 2013-04-25
- Posts: 4,159
- Website

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?

modhex(hkhehghthbhudcfcdchkigiehgduiehg)

Offline

**iceman****Administrator**- Registered: 2013-04-25
- Posts: 4,159
- Website

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

modhex(hkhehghthbhudcfcdchkigiehgduiehg)

Offline

**ntk****Contributor**- Registered: 2015-05-24
- Posts: 701

edit wrong post

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

modhex(ichbifhkhghuhehghkiehbihhkidifighgebecedfchihthbhkhrduhehvht)

Offline

**M&S****Contributor**- Registered: 2015-12-15
- Posts: 44

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)*

Offline

**iceman****Administrator**- Registered: 2013-04-25
- Posts: 4,159
- Website

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.

modhex(hkhehghthbhudcfcdchkigiehgduiehg)

Offline

**M&S****Contributor**- Registered: 2015-12-15
- Posts: 44

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)*

Offline

**mnelson****Contributor**- From: Outside Denver, CO, USA
- Registered: 2015-06-05
- Posts: 30

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) ?

Offline

**M&S****Contributor**- Registered: 2015-12-15
- Posts: 44

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)*

Offline

**M&S****Contributor**- Registered: 2015-12-15
- Posts: 44

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)

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)*

Offline

**M&S****Contributor**- Registered: 2015-12-15
- Posts: 44

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)*

Offline

**M&S****Contributor**- Registered: 2015-12-15
- Posts: 44

** 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)*

Offline

**M&S****Contributor**- Registered: 2015-12-15
- Posts: 44

** 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)*

Offline

**iceman****Administrator**- Registered: 2013-04-25
- Posts: 4,159
- Website

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

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

modhex(hkhehghthbhudcfcdchkigiehgduiehg)

Offline

**ntk****Contributor**- Registered: 2015-05-24
- Posts: 701

srry wrong post

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

modhex(ichbifhkhghuhehghkiehbihhkidifighgebecedfchihthbhkhrduhehvht)

Offline

**Radee****Contributor**- Registered: 2017-10-11
- Posts: 3

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 :-)

Offline

**mnelson****Contributor**- From: Outside Denver, CO, USA
- Registered: 2015-06-05
- Posts: 30

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.

Offline

**Radee****Contributor**- Registered: 2017-10-11
- Posts: 3

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.

Offline

**mnelson****Contributor**- From: Outside Denver, CO, USA
- Registered: 2015-06-05
- Posts: 30

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.

Offline