IDTECK 125 kHZ tags

TiX · 2013-06-17 12:26:16

Does anybody know is it possible to read / clone / emulate IDTECK tags using current proxmark software?

I have one of those, but not very fimilar with proxmark yet.

marshmellow · 2013-06-18 21:40:19

it appears IDTECK uses PSK modulation. so you could try:
lf read
data samples 4000
lf indalademod

and if that works could do
lf indalaclone

TiX · 2013-06-27 13:46:15

yep, my tag is IPK-50, it uses PSK as seen in datasheet.

proxmark3> lf indalademod
Expecting a bit less than 125 raw bits
Recovered 125 raw bits
worst metric (0=best..7=worst): 7 at pos 102
nothing to wait for

what does this mean?

marshmellow · 2013-06-27 14:40:53

I believe it means it didn't find data that fit the indala model. you could try a larger sample size - data samples 16000.

but it may be a format that is not indala compatible. can you save a raw trace file and upload a link to it? (lf read - data samples 16000 - data save [path])

TiX · 2013-06-27 14:46:02

done.

https://www.dropbox.com/s/pkl12pp9uyb7thv/ipk50

marshmellow · 2013-06-27 15:31:44

the plot looks like a manchester format not true psk.

data mandemod 64 outputs 144bits (possibly 128 with 16 bits being overlap) but i don't see any sense to it. are there any numbers on the card?

you could try taking the 128 bits and either use the simulate command or program them to a t55x7 and configure the t55x7 to manchester rf/64 with 4 blocks max - and test with the reader

TiX · 2013-06-28 11:45:01

On keychain there is written E1111 003 26209

What is the command to configure T5557 to manchester encoding?

Could you also provide command syntaxis for "you could try taking the 128 bits and either use the simulate command or program them to a t55x7"

Thanks!

marshmellow · 2013-06-28 14:45:47

lf t55xx writeblock [hexdata 8digits] [block #]
so convert the bits received to 4 sets of 8 hex digits and program blocks 1-4 with it.

for manchester config with 128 bits of data:
lf t55xx writeblock 60148080 0
I beleive there are chip config specs on this forum somewhere. Don't have time atm to link them.

I still see no pattern or obvious numbers in the bits and it doesn't match the printed data so either the data is encrypted or we may not have the right demodulation.

asper · 2013-11-12 22:55:54

Possible solution here.

Last edited by asper (2013-11-12 23:18:29)

marshmellow · 2013-11-12 23:09:50

@asper, you're saying that the tag you identified as an EM4100 is the same as the IDTECK IPK-50 being tested in this thread?

asper · 2013-11-12 23:18:16

It can be; user must try to read the tag as an EM4100 and see if the format he has [E1111 003 26209] can be "decoded" as the other thread or in a similar way. Obviously it is not the same (1st value is 10 digits on the other card but maybe they omitted zeroes). Anyway I corrected my previous post.

Last edited by asper (2013-11-12 23:19:33)

app_o1 · 2013-11-13 04:46:20

Mine are definitely IDTECK cards.
See this topic :
http://www.proxmark.org/forum/viewtopic.php?id=1691

marshmellow · 2015-01-26 05:11:48

We still know little about the idteck tags.
You first will need to identify the modulation type of the tag you have.
Then demodulate the raw bits.
Then translate that to a suitable clone card's config settings and memory blocks.
And send the write commands.

And then you can test and see if it worked... I have not seen any response yet that suggests someone has been successful, but it should be possible.

mnelson · 2015-06-05 23:00:36

I don't have a complete solution, but the numbering on the card referenced, "E1111 003 26209" is broken down like this:

E1111 - This is the production run date, and is broken into three parts: letter, 2-digit year, 2-digit month. So this example was made in 2011, November (I'm not sure what the letter stands for). This production information is only printed on the outside of card/FOB, it isn't part of the encoding.
003 - Facility Code
26209 - Serial Number.
(Furthermore, if you had the box this card came in, it would say "Model: IDK70 E1111003," which is the part#, date, and facility code)

There is a card and FOB version of it (the card is part# IDK70, and the FOB is IDK50). The boxes say they are 26bit Wiegand

I sell these as compatible cards for the Doorking 170 cards. If anyone wants to try and tackle this card, I'm happy to send you some samples to test. Just message me.

Hope this helps.

-Matt

mnelson · 2015-06-05 23:08:19

Correction: the cards are part# IDC170, not IDK50

marshmellow · 2015-06-06 04:41:03

unfortunately there is no PM in this forum yet, and only the admins can see your email...
I'm curious about these tags, but i think i already know it, just would like confirmation. (a lot has change in lf since the original posts, it is much easier to ID now)

do you have a pm3? if not where are you located? it probably isn't worth international shipping for me.

iceman · 2015-06-06 08:39:13

I agree with Marshmellow, probably not worth sending tags to Europe (in my case), there are some great PM3 ol' time users in Aussie. App_o1, 0xFFFF if I'm remember correct.

mnelson · 2015-06-16 20:24:15

marshmellow wrote:

unfortunately there is no PM in this forum yet, and only the admins can see your email...
I'm curious about these tags, but i think i already know it, just would like confirmation. (a lot has change in lf since the original posts, it is much easier to ID now)
do you have a pm3? if not where are you located? it probably isn't worth international shipping for me.

Hi @marshmellow,

I don't have one yet, but should by the end of the month. I'm in Utah, USA.

Lenox · 2015-07-10 03:57:27

Is there any new information on IDTECK fobs?
I got a IDTECK fob, should be IDK50. Use the latest pm2-bin-2.1.0 and get the following info:

proxmark3> lf search 1 u
NOTE: some demods output possible binary
if it finds something that looks like a tag
False Positives ARE possible
Checking for known tags:
No Known Tags Found!
Checking for Unknown tags:
Possible Auto Correlation of 8192 repeating samples
Using Clock:32, invert:0, Bits Found:500
PSK1 demoded bitstream:
0101011101101001
1101010110001100
1101111111010111
0110110101110111
0101011101101001
1101010110001100
1101111111010111
0110110101110111
0101011101101001
1101010110001100
1101111111010111
0110110101110111
0101011101101001
1101010110001100
1101111111010111
0110110101110111
0101011101101001
1101010110001100
1101111111010111
0110110101110111
0101011101101001
1101010110001100
1101111111010111
0110110101110111
0101011101101001
1101010110001100
1101111111010111
0110110101110111
0101011101101001
1101010110001100
1101111111010111
0110
Possible unknown PSK1 Modulated Tag Found above!
Could also be PSK2 - try 'data rawdemod p2'
Could also be PSK3 - [currently not supported]
Could also be NRZ - try 'data nrzrawdemod
proxmark3>

Use PSK1 and get following blocks:
block#0 00081040
block#1 5769D58C
block#2 DFD76D77

Just wondering the way I am doing is correct or not?

marshmellow · 2015-07-10 05:53:24

Can you post an image of the plot of your trace? Or the trace itself?

Last edited by marshmellow (2015-07-10 06:30:11)

Lenox · 2015-07-10 15:57:46

@marshmellow, thanks for your reply. The following is the file:

http://www.filedropper.com/investigated-idteck2

joe · 2015-07-10 17:51:23

could be ASK clock 32 , 2 blocks.. is a thin card.

Lenox · 2015-07-10 18:28:05

It is a white fob.

Last edited by Lenox (2015-07-15 16:39:29)

marshmellow · 2015-07-10 18:52:05

definitely PSK RF/32, RF/2 and 64 bits. are there numbers on the tag?

Last edited by marshmellow (2015-07-10 18:53:09)

marshmellow · 2015-07-10 18:57:06

Use PSK1 and get following blocks:
block#0 00081040
block#1 5769D58C
block#2 DFD76D77

would be a valid attempt to clone to a t55x7. (though the starting point for the repeating data is likely wrong to figure out the meaning of the bits)

Last edited by marshmellow (2015-07-10 18:57:23)

Lenox · 2015-07-10 19:38:27

The number :
11103 036 10359

marshmellow · 2015-07-10 21:50:01

hmmm. i am not seeing an easy correlation between the bits and the printed ID..

Lenox · 2015-07-11 04:55:21

It is working. Thanks.

iceman · 2015-07-11 14:59:33

What do you say @marshmellow? time for a "IDTECK 125 kHZ tag" demod ?

marshmellow · 2015-07-11 19:43:16

If we knew how to decode the bits... But we don't... We can't even identify the correct preamble, or starting point.

TiX · 2016-02-18 00:04:54

Any good news avout idteck cloning/decoding?

marshmellow · 2016-02-18 06:05:40

Should be possible. No direct demodulation is currently built though. If you have a tag to share and could run a couple tests on it we might get closer to a full demod.

TiX · 2016-02-29 13:39:43

Yep, got proxmark updated to latest revisions and ready for expiriments

What do you need firstly?

marshmellow · 2016-02-29 13:55:23

You could start with 'lf search u'. And post the results.

TiX · 2016-02-29 14:18:50

I`m sorry actually iv moved to another company and as wall readers are from idteck i though cards are also idteck.. but found that they are EM410 So no experiments with idteck for now sorry

marshmellow · 2016-02-29 15:10:10

don't be sorry. most of the tags i've seen for idteck have been the EM410x format. some, however, are not the normal bit rate or are week keyfobs so they sometimes are more difficult for the older auto demods to read them making many think there is a separate format for them. recent firmware made this less of a problem. (there also seems to be a PSK version of idteck)

it is good to confirm the EM410x format works on some idteck readers. if you want to do me a favor just try a `lf t55xx detect` on the tag and if it finds something post it. (might get the full chip configuration - depending on the chip and if it is pwd protected)

also if you could post the results of `data detectclock a` for me. (to verify the clock - standard em410x should be 64)

and do you have a model # for the readers?

Last edited by marshmellow (2016-02-29 15:13:03)

TiX · 2016-02-29 15:30:37

First part:

proxmark3> lf t55xx detect
Could not detect modulation automatically. Try setting it manually with 'lf t55xx config'
proxmark3> data detectclock a
Auto-detected clock rate: 64, Best Starting Position: 0
proxmark3>

hm · 2016-05-13 08:20:17

So i have an IDTECK card as i have been told its IDC80.
The printed ID on card is: I1507 128 00772
Need to replicate it to a t5557. Cant seem to get things right. Posted my logs in following links, if someone could have a look and see whats wrong?
HW Version: https://www.dropbox.com/s/j6ae7e4tx067235/HWVersion.txt?dl=0
Investigate LF: https://www.dropbox.com/s/yy0bmlwbogx8b3e/InvestigateLF.txt?dl=0
Investigated: https://www.dropbox.com/s/5qu4b0nsing21pm/investigated.txt?dl=0
LF55xxdetect: https://www.dropbox.com/s/6fmf1g14v5dgc7y/Lf55xxdetect.txt?dl=0
ReadLF: https://www.dropbox.com/s/qm6ca86iepwnq77/ReadLF.txt?dl=0
SearchLF: https://www.dropbox.com/s/y3wghrmmhlqygpf/SearchLF.txt?dl=0
IfSearch1U: https://www.dropbox.com/s/wdp2eat2nhr1nvx/lfsearchu1.txt?dl=0

iceman · 2016-05-13 09:38:19

try a

-lf se u
-data rawde p1

and you will se a raw hex output, some earlier posts has the block0, needed when making a clone on t55x7.

you need to find the repeating pattering, so everything you need is in this thread.

ntk · 2016-05-13 18:17:42

As iceman already told you, you should see here a repeating pattern of 2 data blocks, psk1 demodulation type, I can see similar what he saw.

The configuration data for block 0 should be in the threads somewhere, you can search with keys IDteck or Gotus. There is not much reading so don't be shy.

(If can not come forward, still can ring the bell at the upper right corner.)

lonewolf · 2017-01-11 05:24:04

I would love to get a demod for this card, but it seems it won't be easy I have a number of cards if someone can crack the encryption. They're 64-bit cards, with 32 bits fixed. All of these are DoorKing (DKS) branded, with the 410 and I1605 sets being different groups of IDC170's, and the I1407 is a IDK50. I aligned them so the fixed 32 bits are first, though for all I know it can be 16+32+16 or 8+32+24 or whatever.

data rawdemod p1:
01001001010001000101010001001011 11000101100011011000001001010000 410-192-18710
01001001010001000101010001001011 01111101110011101101111001100001 410-192-18711
01001001010001000101010001001011 10011111000100100110101110111010 410-192-18713
01001001010001000101010001001011 00010101011010000010010110111011 410-192-18714
01001001010001000101010001001011 01010001100110101010010101011111 I1407-005-31920
01001001010001000101010001001011 01011110110100100011000110101100 I1605-152-01926
01001001010001000101010001001011 00111001100110000101001100111001 I1605-152-01927
01001001010001000101010001001011 10000010101100110100101011001001 I1605-152-01928
01001001010001000101010001001011 00100110101000110000101000110001 I1605-152-01929
01001001010001000101010001001011 10111011001011001000010010001100 I1605-152-01930
01001001010001000101010001001011 01011100111100110000101111110101 I1507-128-00772 (from hm's post)
01001001010001000101010001001011 00010101001110011001000000010100 I1103-036-10359 (from Lenox's post)

Raw card data: http://guyver-i.hacker-nin.com/pm3/idtk-cards.tar.bz2

t55xx for the above would be:
block#0 00081040
block#1 4944544B
block#2 xxxxxxxx

(Side note, if you look up 4944544B it's "IDTK", so it's almost certainly 32+32 format)

Last edited by lonewolf (2017-01-11 18:20:49)

iceman · 2017-01-11 09:09:10

@lonewolf, the IDTK is good find, strange that I can't find it @hm 's trace. But that is a IDC80 tag.
Since yr numbers follow sequence and the corresponsive 32bits are totally different, I say some kind of encryption going on.
There is no parity your samples either. Do you get the same IDTK pattern if you decode as PSK2 ?

-----------------
IDTEC, preamble = 0x4944544B, psk1, 64bits.
Should be able to identify IDC170, IDK50 tags with it. Easy clone/sim aswell.

lonewolf · 2017-01-11 16:52:53

iceman wrote:

@lonewolf, the IDTK is good find, strange that I can't find it @hm 's trace.

While looking at my captures, I discovered that if there's a DC offset then "rawdemod p1" inverts all the bits.

10110110101110111010101110110100 10100011000011001111010000001010 - hm's original trace (after shifting for alignment)
01001001010001000101010001001011 01011100111100110000101111110101 - hm's trace after a "data hpf" ("data norm" also works)
01001001010001000101010001001011 01001001010001000101010001001011 - my 410-192-18714

My data with "data rawdemod p2"
01101101111001100111111001101110 00100111010010110100001101111000 410-192-18710
11101101111001100111111001101110 11000011001010011011000101010001 410-192-18711
01101101111001100111111001101110 01010000100110110101111001100111 410-192-18713
11101101111001100111111001101110 10011111110111000011011101100110 410-192-18714
11101101111001100111111001101110 11111001010101111111011111110000 I1407-005-31920
01101101111001100111111001101110 11110001101110110010100101111010 I1605-152-01926
11101101111001100111111001101110 10100101010101000111101010100101 I1605-152-01927
11101101111001100111111001101110 01000011111010101110111110101101 I1605-152-01928
11101101111001100111111001101110 10110101111100101000111100101001 I1605-152-01929
01101101111001100111111001101110 01100110101110101100011011001010 I1605-152-01930

A manual review of the graphs ("data plot") agrees with the above ones/zeros as the first bit. Unless the format is 31+33 it's not p2.

From a PDF:

IDC170 is pre-programmed at the factory with a unique encryption code and it has very flexible data format to meet any customer's requirement and any OEM format up to 64 bit ID is also available. It can be supplied without code and the customer can write their unique code by using STAR PGM1000 Programming Devices with Programming software.

I edited my other post, adding hm's and Lenox's cards (after inverting) and a download link to the card data.

Last edited by lonewolf (2017-01-11 18:34:25)

iceman · 2017-01-11 23:57:40

I've made a demod for it and hooked it up in 'lf search'
even if it has to invert, it still get the same raw block1.

pm3 --> da load traces/idtec/card-410-192-18710-shifted.pm3
loaded 29272 samples
pm3 --> lf se  1
Checking for known tags:

IDTECK Tag Found: Card ID 0 ,  Raw: 4944544BC58D8250

Valid Idteck ID Found!
pm3 --> da load traces/idtec/card-410-192-18711-shifted.pm3
loaded 28720 samples
pm3 --> lf se  1
Checking for known tags:

IDTECK Tag Found: Card ID 0 ,  Raw: 4944544B7DCEDE61

Valid Idteck ID Found!
pm3 --> da load traces/idtec/card-I1407-005-31920-shifted.pm3
loaded 28890 samples
pm3 --> lf se  1
Checking for known tags:

IDTECK Tag Found: Card ID 0 ,  Raw: 4944544B519AA55F

Valid Idteck ID Found!
pm3 -->

lonewolf · 2017-01-12 05:49:24

And to verify, I wrote hm's tag in 4944544B 5CF30BF5 format to a t55xx tag (0/00081040 1/4944544B 2/5CF30BF5) and my Star RF20 reader read it just fine. Writing the tag was annoying though as I always verify the written data, and while blocks 0 and 1 were writing fine block 2 always returned A30CF40A and was driving me nuts until I realized the read was inverting

Reader Wiegand output for written t55xx tag (P 128 00772 P):

Now the question is, do I tear my reader apart (ugh, de-potting) and try to dump the code to figure out the encryption routine, or do I call it quits here? Would the routine be added to the demod if I do figure it out?

iceman · 2017-01-12 08:38:32

Maybe another block0 which doesn't invert?

You should be able to use the "lf t55xx" commands to dump the t55x7 data.

The block2 could be xored, encrypted or scrambled. If you figure it out,I'll add it to the demod.

[edit] saw yr ref to unique encryption code. I think you can find the encryption by looking at the software referenced

lonewolf · 2017-01-13 04:12:44

I think you misunderstood what I was saying. Inverted bit set or not, shouldn't a "lf t55xx read" command done after a "lf t55xx write" return the value as written? When writing a blank t55xx tag I'm seeing:

proxmark3> lf t55 detect
Chip Type : T55x7
Modulation : ASK
Bit Rate : 2 - RF/32
Inverted : No
Offset : 32
Seq. Term. : Yes
Block0 : 0x000880E8

proxmark3> lf t55 write b 0 d 0x00081040
Writing page 0 block: 00 data: 0x00081040

proxmark3> lf t55 config b 32 d PSK1 o 28 i 1
Chip Type : T55x7
Modulation : PSK1
Bit Rate : 2 - RF/32
Inverted : Yes
Offset : 28
Seq. Term. : No
Block0 : 0x00000000

proxmark3> lf t55 read b 0
Reading Page 0:
blk | hex data | binary
----+----------+---------------------------------
0 | 00081040 | 00000000000010000001000001000000 (<-- as expected)

proxmark3> lf t55 write b 1 d 4944544B
Writing page 0 block: 01 data: 0x4944544B

proxmark3> lf t55 read b 1
Reading Page 0:
blk | hex data | binary
----+----------+---------------------------------
1 | 4944544B | 01001001010001000101010001001011 (<-- as expected)

proxmark3> lf t55 write b 2 d 5CF30BF5
Writing page 0 block: 02 data: 0x5CF30BF5

proxmark3> lf t55 read b 2
Reading Page 0:
blk | hex data | binary
----+----------+---------------------------------
2 | A30CF40A | 10100011000011001111010000001010 (<-- ????? )

Since blocks 0 and 1 return the data exactly as written, why does block 2 return the data inverted?

Last edited by lonewolf (2017-01-13 04:18:07)

marshmellow · 2017-01-13 04:19:05

psk is difficult to get the initial phase correct unless there is a special format you expect. when reading blocks on the ata55x7 chips there are not any format indicators. so it essentially makes it's best guess. and sometimes it will guess wrong. it will depend on what data is being read, some starting bits are more prone to errors.

the result is as you have found - it can invert all the bits.

marshmellow · 2017-01-13 04:23:52

it is good work that you have identified the correct phase and starting point for this tag (or at least what appears to be correct).

i still see no easy correlation for the ID bits. my guess is there is a reversible hash or mildly complex encryption routine run on the data.

lonewolf · 2017-01-13 04:41:00

So I ended up ripping a reader apart; the uC is a PIC16F84A. Fun fact: the undocumented brown wire is !MCLR, and I believe the 2 ICSP data lines are blue and yellow (I need to finish tracing them out).

Edit:
Brown - !MCLR
Yellow - RB7 (DATA)
Blue - RB6 (CLK)
All have 1k resistors in series.

Last edited by lonewolf (2017-01-17 04:26:35)

Proxmark3 community

Announcement

#1 2013-06-17 12:26:16

IDTECK 125 kHZ tags

#2 2013-06-18 21:40:19

Re: IDTECK 125 kHZ tags

#3 2013-06-27 13:46:15

Re: IDTECK 125 kHZ tags

#4 2013-06-27 14:40:53

Re: IDTECK 125 kHZ tags

#5 2013-06-27 14:46:02

Re: IDTECK 125 kHZ tags

#6 2013-06-27 15:31:44

Re: IDTECK 125 kHZ tags

#7 2013-06-28 11:45:01

Re: IDTECK 125 kHZ tags

#8 2013-06-28 14:45:47

Re: IDTECK 125 kHZ tags

#9 2013-11-12 22:55:54

Re: IDTECK 125 kHZ tags

#10 2013-11-12 23:09:50

Re: IDTECK 125 kHZ tags

#11 2013-11-12 23:18:16

Re: IDTECK 125 kHZ tags

#12 2013-11-13 04:46:20

Re: IDTECK 125 kHZ tags

#13 2015-01-26 05:11:48

Re: IDTECK 125 kHZ tags

#14 2015-06-05 23:00:36

Re: IDTECK 125 kHZ tags

#15 2015-06-05 23:08:19

Re: IDTECK 125 kHZ tags

#16 2015-06-06 04:41:03

Re: IDTECK 125 kHZ tags

#17 2015-06-06 08:39:13

Re: IDTECK 125 kHZ tags

#18 2015-06-16 20:24:15

Re: IDTECK 125 kHZ tags

#19 2015-07-10 03:57:27

Re: IDTECK 125 kHZ tags

#20 2015-07-10 05:53:24

Re: IDTECK 125 kHZ tags

#21 2015-07-10 15:57:46

Re: IDTECK 125 kHZ tags

#22 2015-07-10 17:51:23

Re: IDTECK 125 kHZ tags

#23 2015-07-10 18:28:05

Re: IDTECK 125 kHZ tags

#24 2015-07-10 18:52:05

Re: IDTECK 125 kHZ tags

#25 2015-07-10 18:57:06

Re: IDTECK 125 kHZ tags

#26 2015-07-10 19:38:27

Re: IDTECK 125 kHZ tags

#27 2015-07-10 21:50:01

Re: IDTECK 125 kHZ tags

#28 2015-07-11 04:55:21

Re: IDTECK 125 kHZ tags

#29 2015-07-11 14:59:33

Re: IDTECK 125 kHZ tags

#30 2015-07-11 19:43:16

Re: IDTECK 125 kHZ tags

#31 2016-02-18 00:04:54

Re: IDTECK 125 kHZ tags

#32 2016-02-18 06:05:40

Re: IDTECK 125 kHZ tags

#33 2016-02-29 13:39:43

Re: IDTECK 125 kHZ tags

#34 2016-02-29 13:55:23

Re: IDTECK 125 kHZ tags

#35 2016-02-29 14:18:50

Re: IDTECK 125 kHZ tags

#36 2016-02-29 15:10:10

Re: IDTECK 125 kHZ tags

#37 2016-02-29 15:30:37

Re: IDTECK 125 kHZ tags

#38 2016-05-13 08:20:17

Re: IDTECK 125 kHZ tags

#39 2016-05-13 09:38:19

Re: IDTECK 125 kHZ tags