Indala/Motorola ASP cards bit scrambling

broken_bad · 2015-04-08 08:52:40

Hi there, I've came across strange bit scrambling I haven't seen before. Doesn't look like something obvious.

Cards are 125kHz, first one is marked as Motorola ASP, the rest is marked as Indala T2. The point is I need to read the same number as is printed on the card, but I can see no obvious rule between what I read and what is printed.

1015958 - ED588856
2151215 - 6FC51C1D
2151216 - 25F3AC2B
2151217 - 8C0C352C
2151219 - 62A1F8E4 
2151220 - EF255D05 
2151223 - A87709CA
2151226 - 1BF677AB
2151229 - 9672D24A
2151231 - 78DF1F82

Is there anybody who can find the magic rule?

Thanks!

Last edited by broken_bad (2015-07-09 16:27:36)

iceman · 2015-04-08 09:01:59

have you tried the "lf indalademod" or "lf search u" on your tags?

broken_bad · 2015-04-08 09:25:22

Sorry I have no such option, I have just tried posting here because I've seen local members are very experienced in 125kHz cards and its UID encoding.

What do I need for doing such a test?

iceman · 2015-04-08 09:46:17

well, to starters you'll need a Proxmark3...

Sentinel · 2015-04-08 17:21:49

How did you get the data?
...ED588856...6FC51C1D...

hkplus · 2015-04-08 20:12:57

Indala randomly scrambles bits for different formats...

marshmellow · 2015-04-09 03:13:14

Something is not right with the samples, I agree with sentinel, how did you come up with the read id?

broken_bad · 2015-04-09 13:59:27

I just took TWN4 from Elatec (with factory default settings) and tried to read all tags available. There is a poorly documented parameter called 'Indala read mode' in TWN4, but for these 32-bit tags numbers reported by reader don't change (I have tried both 'read mode 1' and 'read mode 2', whatever that means).

marshmellow · 2015-04-09 16:07:33

I don't trust the output from the twn4 when it is not a standard format. i've seen different indala tags with different printed number come out as the same read ID, but on a true reader work fine.

biggest problem with the twn4 is it doesn't have a raw read. it ALWAYS interprets the read data. if the tag is not in the specific format it is looking for it will interpret it wrong.

so either your cards have a true encryption algorithm on the ID (this would be a first for Indala) or more likely your output from the twn4 is incorrect.

also i assume you do not know the programming format numbers? ASP and T2 are generic description of the tag not a programmed format.

broken_bad · 2015-04-09 17:38:02

Unfortunately I don't have any more info about tags (and I am afraid I won't be able to find something).

So I guess the advice is to send cards to the TWN4 development team and ask them directly, right? I need those cards to be read by TWN4 so I guess there is no chance for me to make it by myself.

broken_bad · 2015-07-08 13:22:19

OK, i managed to read all data from tag, now it looks like this:

EC0A32CDD2926C85   1015958
EC472C6F4D6D9285   2151215
EC472C6E12926C85   2151216
EC472C6E0D6D9285   2151217
EC38D38E3D6D9285   2151219
EC472C6E6D6D9285   2151220
EC38D38E42926C85   2151223
EC38D38EAD6D9285   2151226
EC472C6EE2926C85   2151228
EC472C6EFD6D9285   2151229
EC38D38ECD6D9285   2151231

But still looks like very well scrambled card number, but now it makes a bit more sense - there can be seen some bit inversions etc. Is there somebody who came across something similar?

marshmellow · 2015-07-08 13:30:03

That does look better, I'll have a closer look in a couple hours, but out of curiosity, how did you come to that output?

broken_bad · 2015-07-08 14:30:16

This output (first column) is read using the new version of TWN4 reader, which reads "all data" from the card (64 bits).

marshmellow · 2015-07-08 14:31:52

What version? 1.7?

broken_bad · 2015-07-08 14:38:05

1.7.8 beta

marshmellow · 2015-07-08 14:39:54

Ok thx, last I have is 1.72beta

marshmellow · 2015-07-08 16:05:13

hmmm... if that is the true raw bits then it is not an indala format i've ever seen, nor does it follow any of the indala standards (except bits 62-64)... I'm still skeptical of the twn4 output. I assume eletec refused to help you get the printed ID from the Raw...

broken_bad · 2015-07-08 17:24:11

They just added a new read mode for Indala cards, but didn't say anything about relationship between printed card number and reported card number. Can be those cards somehow customized for certain customer? Is that possible at all for Motorola cards?

marshmellow · 2015-07-08 17:59:48

Can you share that twn4 beta? I'm curious what it does to std indala tags...

0xFFFF · 2015-07-09 05:23:09

marshmellow wrote:

...ASP and T2 are generic description of the tag not a programmed format.

I think the T2 in 'Indala T2' does describe the card format. I have 7 Indala card formats in my database. None of them align with any of the data in this thread.
L2 is a bit shuffled format similar to T2.

broken_bad · 2015-07-09 09:18:37

marshmellow wrote:

Can you share that twn4 beta? I'm curious what it does to std indala tags...

I am sorry, but I am not sure NDA allows me to do so, but if you give me an e-mail, I can send you at least firmware for the reader so you can test it out. I didn't have much time to test it by myself, but for old motorola cards it reads 35 bits.

marshmellow · 2015-07-09 13:14:16

I understand (though I don't remember a NDA for them... Hmm I'll have to look), the simple protocol firmware is all I meant.

Last edited by marshmellow (2015-07-09 16:32:13)

marshmellow · 2015-07-09 13:22:04

0xFFFF wrote:

I think the T2 in 'Indala T2' does describe the card format. I have 7 Indala card formats in my database. None of them align with any of the data in this thread.
L2 is a bit shuffled format similar to T2.

Interesting. I had thought most of their formats were 4 or 5 digit format numbers. And asp, t2, flexpass were format families. But I certainly could be mistaken. I don't believe I've seen L2...

broken_bad · 2015-07-09 16:19:38

marshmellow wrote:

I understand (though I don't remember a NDA for them... Hmm I'll have to look), the simple protocol firmware is all I meant. @ {user name here}rf AT g mail d0t c0m

I am pretty sure I've signed something with them. In any case it's at least impolite to forward anything that is not sent directly to you (especially in case of beta versions). Btw, let me know, if it didn't reach you.

broken_bad · 2015-10-12 10:15:23

Update to this issue. I've managed to find out that if I buy brand new Indala reader and after powering it up I apply 4 configuration cards in specific order, I get this 'special' transformation for cards being read.

Those 4 configuration cards contain a lot of data that probably configure reader to scramble all the bits read. The question is, what those cards actually say.

If I read data using TWN4 read mode 3 from one of configuration cards, I get this:

81x50xxxx00xxxx80x003xxxxFFF7xxxxE107FFxxxx8D00040

(please note some of bits were replaced by 'x' in order to hide potentially private data)

Any ideas what those cards do to standard Indala readers?

broken_bad · 2015-12-30 13:08:46

This bit scrambling is somewhat proprietary that could be read from HiD documentation which is not public and available only to partners that have signed NDA with HiD. But it is definitely possible to decode reported numbers from these 224 bits.

marshmellow · 2015-12-30 17:08:06

tell us something we don't know this is the case with all prox formats... (except 26 and some 37 bit formats...)

broken_bad · 2015-12-31 08:46:16

I would be more than happy to share this idea, but I can't, because I don't know it! I just asked people from company that has signed NDA with HiD and they have decoded it into desired form. The only thing they supplied was compiled firmware for the RF reader.

I was posting this just for clarification and ensuring that it definitely *is* possible and decoding scheme is buried somewhere in HiD proprietary documentation.

Proxmark3 community

Announcement

#1 2015-04-08 08:52:40

Indala/Motorola ASP cards bit scrambling

#2 2015-04-08 09:01:59

Re: Indala/Motorola ASP cards bit scrambling

#3 2015-04-08 09:25:22

Re: Indala/Motorola ASP cards bit scrambling

#4 2015-04-08 09:46:17

Re: Indala/Motorola ASP cards bit scrambling

#5 2015-04-08 17:21:49

Re: Indala/Motorola ASP cards bit scrambling

#6 2015-04-08 20:12:57

Re: Indala/Motorola ASP cards bit scrambling

#7 2015-04-09 03:13:14

Re: Indala/Motorola ASP cards bit scrambling

#8 2015-04-09 13:59:27

Re: Indala/Motorola ASP cards bit scrambling

#9 2015-04-09 16:07:33

Re: Indala/Motorola ASP cards bit scrambling

#10 2015-04-09 17:38:02

Re: Indala/Motorola ASP cards bit scrambling

#11 2015-07-08 13:22:19

Re: Indala/Motorola ASP cards bit scrambling

#12 2015-07-08 13:30:03

Re: Indala/Motorola ASP cards bit scrambling

#13 2015-07-08 14:30:16

Re: Indala/Motorola ASP cards bit scrambling

#14 2015-07-08 14:31:52

Re: Indala/Motorola ASP cards bit scrambling

#15 2015-07-08 14:38:05

Re: Indala/Motorola ASP cards bit scrambling

#16 2015-07-08 14:39:54

Re: Indala/Motorola ASP cards bit scrambling

#17 2015-07-08 16:05:13

Re: Indala/Motorola ASP cards bit scrambling

#18 2015-07-08 17:24:11

Re: Indala/Motorola ASP cards bit scrambling

#19 2015-07-08 17:59:48

Re: Indala/Motorola ASP cards bit scrambling

#20 2015-07-09 05:23:09

Re: Indala/Motorola ASP cards bit scrambling

#21 2015-07-09 09:18:37

Re: Indala/Motorola ASP cards bit scrambling

#22 2015-07-09 13:14:16

Re: Indala/Motorola ASP cards bit scrambling

#23 2015-07-09 13:22:04

Re: Indala/Motorola ASP cards bit scrambling

#24 2015-07-09 16:19:38

Re: Indala/Motorola ASP cards bit scrambling

#25 2015-10-12 10:15:23

Re: Indala/Motorola ASP cards bit scrambling

#26 2015-12-30 13:08:46

Re: Indala/Motorola ASP cards bit scrambling

#27 2015-12-30 17:08:06

Re: Indala/Motorola ASP cards bit scrambling

#28 2015-12-31 08:46:16

Re: Indala/Motorola ASP cards bit scrambling

Board footer