Looking for a chip data sheet

mwalker · 2019-06-10 06:25:39

Hi, does anyone know where I can find a copy of the data sheet for a 125Khz chip called 5200
I have seen it refereed to as T5200 and cet5200. I believe its an em4100 with changeable ID (but not sure).
This is refereed to in many cloners and cheap fobs.

If you know were i can download the data sheet that covers the downlink protocol please let me know.

Thanks

Tom5ive · 2019-06-11 04:41:09

These ones: https://www.aliexpress.com/i/32809586461.html ?

If so interesting. Might have to get on WeChat for this one!

mwalker · 2019-06-11 04:52:36

That link showed as "100pcs RFID EM4305 / EM5200 125KHZ frequency Rewritable RFID access card / key tags /can rewrite code "
while it quotes the "EM5200" in the description, it does not have the data sheet. Part of the description talks about the 4305 and the other about the 5200. mmmm
What I want is the data sheet for the 5200. I.e. the file the explains that read/write protocols, so if you have a link to the data that would be great.

Tom5ive · 2019-06-11 06:38:49

I have a feeling the actual IC is:

AT-C-TK4100

Also known as: SMC4100

And that datasheet is apparently under NDA as the IC is very new. I have one supplier that I get 100s of blank custom made t5577 cards from to bulk program for work. I'll see if they can possibly get me some info.

Last edited by Tom5ive (2019-06-11 06:39:11)

Tom5ive · 2019-06-11 06:41:23

Maybe: http://www.mave.si/e_files/docs/tk4100-datasheet.pdf

marshmellow · 2019-06-11 06:53:08

pretty sure tk4100 is a mimic of em4100 which is a read only chip. (as your datasheet confirms.)

Tom5ive · 2019-06-11 06:55:37

Makes sense! I just found that on a whim while working on other things.

gjuny · 2019-06-11 17:57:59

I found some information about an EM5200 blue fob in an AliExpress vendor page.

Chip: EM5200
Block 1, 512, EEPROM, divided into 16 sectors, each sector 32 bit
2, 32 bit UID (unique identification number)
3, compatible EM agreement
4, 32 password to read and write protection
Block 5, can make the EEPROM sector into a read-only lock state
6, 2 kind of coding way, the Bi - phase (Manchester)
7, a variety of data transfer rate (8, 16, 32, 64 RF clock)
8, has the characteristics of the reader first inquiry
9, frequency range is125 KHZ
10, temperature range: - 45 ~ 85

mwalker · 2019-06-17 04:12:00

Sounds like a em4305, almost a cut n paste from the 4305 data sheet.

mwalker · 2019-06-18 04:03:33

A little more info, but again just seller blurb.

CET5200, is Freevision's branded RFID chip, 125kHz, read/write, compatible of EM4100/EM4102, could write to EM ID type, like EM4100, EM4102, EM4200, TK4100.
CET5200: Write to EM ID

The same seller also talked about the t5577 and its features that matched the t5577.

So its looking like the T5200 could just be an EM410x with changeable ID.

gjuny · 2019-06-19 22:48:57

Interesting... I wish we could find more information and have it eventually implemented in the Proxmark client.

mwalker · 2019-07-06 10:05:40

I thought I would move the tech chat about this Chip here as well as I/we move forwards.
As i have posted on a different thread, I have extracted what I think are the 4 command sequences that get sent.
I did this by sniffing every packet sent from the cloner, then decoded (by hand) every bit.
I then removed the 5577 commands and the E4305 commands (I did try to send those commands but no response from the card as expected), so what was left must be what is writing to the cards (in theory).

While not the full wave, its the start the first line below.
Note, while the bits below may not be 100% the EM data was decoded to be correct, so happy this is ok and think it is.
I have run over it many times now, and paid close attention to anything that did not line up.

01 0000100 0101 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 1           
01 0000000 1010 00000000 11111111 10000011 01100000 00000010 1 <- EM4100 Data
01 0000000 1010 10000000 01001100 01101100 00100100 11001100 1 <- EM4100 Data
01 0000000 1010 11111111 00000101 00000000 00000000 00000000 1

At the moment, this is my theory.
the 01 is a sync, as the "1" is wider then all the other ones. the 0 could just be the result of the field on.
the Next 7 bits are a pre-amble of some sort (as I cant think of anything else)
then next 4 bits are the opcode (e.g. 3 bits + parity)
next few bits is an address e.g. for the middle em data we have 00000000 and 10000000
then the data
The last bit I think is just the end of field, not an actual bit, but again, all guess work atm.

Still not luck with the data sheets.
Any comment and the wave form or hints. I have been playing with trying to get something that looks the same based on the bits, but no luck yet.

marshmellow · 2019-07-06 13:51:19

Can you post links to the traces?

mwalker · 2019-07-06 19:20:23

3 "raw" Trace files, first has some t5577, the 2nd has the remainder of the t5577 and some em4305 and the last one has the end of the 4305 and the unknown. If a packet was not complete at the end of the file, then the next file should hold the complete packet.

blue_1_1.pm3
blue_1_2.pm3
blue_1_3.pm3

mwalker · 2019-07-10 03:10:51

Hoping someone can check my logic here and give me some ideas.

Summary:
- I have an unknown fob supplied with a cheap cloner.
- I have some cards sent to me that they claim are T5200 cards (they also claim there are the same as the EM4305, but a cheap seller).
- My blue cloner can write an EM4100 ID to an T5577, EM4305 and the above two chips
- Running the T5577 commands to the unknown/5200 does not work.
- Running the EM4305 commands to the unknown/5200 does not work.
- I decoded every bit in the (posted) traces and am very happy that there are 3 types, T5577, EM4305 and unknown.
As such, I know the configs sent and passwords used, so confirming that the unknown is not a T5577/EM4305 (most likely)

Assumption/Conclusion
a) The unknown fob and 5200 are the same chip (or close enough) as that's all that seems left from the cloner.
or
They are in fact one of the other two, but with different timings then the pm3 is currently using, thus don't accept the commands.

c) The 3rd set of packets looks very similar to the OOK used for the T5577, just much shorter timings and a long pulse "1" at the start.

I managed to get a wave form that looked very close, but for a novice, this has been a trial,error, tune and repeat process, so while looking very close, still does not work, so not right (yet).

At the moment, I want to focus on the timings.
Whats the best way to work out the (exact/very close) pulse width times from the trace? i.e. can we convert the delta time from the plot to a micro-second value (assuming no decimation) ?

Any other big/small holes in my logic.

Thanks

marshmellow · 2019-07-10 03:40:39

If you capture at 125 khz then each grid point is 8us
I'd recommend setting up the lf cmdread for testing variations of bit timings.

marshmellow · 2019-07-10 04:33:29

did you have decimation set on the traces shared above?

marshmellow · 2019-07-10 04:58:01

this is what i get: (close to yours)

each bit begins with 14fc off 
0 = 6 fc on (so 20fc total)
1 = 14 fc on (so 28fc total)
* = 21 fc on (so 35fc total)
fc = 8us or one 125khz sample

316fc power up cycle

0* 0000100 0101 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 off14fc ON466fc      
0* 0000000 1010 00000000 11111111 10000011 01100000 00000010 off14fc ON968fc
0* 0000000 1010 10000000 01001100 01101100 00100100 11000100 off14fc on968fc
0* 0000000 1010 11111111 00000101 00000000 00000000 00000000 off14fc on968fc

Last edited by marshmellow (2019-07-10 05:03:50)

mwalker · 2019-07-10 08:19:00

Thanks for the decode, good to get confirmation (I accept a bit error here or there as I mostly did it by hand).

I found that the T5200 named cards I got sent ended up looking like a T5577 but not 100% the same.
The fob is still resisting, so different chip again (???) and I still really want to know what that command set is

The T5200 named cards I got sent:
The first 2 i used/tested were not the same as the rest (used maybe??), they had a password that I missed (normal blue password), and once cleared did show up as a T5577 and commands seem to work, the remainder of the pack was pre-programmed as EM4100 tags, but no password.

The interesting bit:
The Block 3 Page 1 config was 00A00003 on all of them (note, for that to be active first nibble should be 6 or 9, and the last 2 bits are set to 3 where the t5577 doc states 00, reserved.

I then set that to a valid page 1 config to setup leading 0 and it did NOT apply.
I tried 1 of 4 and again it did not apply
It did write the data and I could read the data, just not applied as the analog front end config.

So these cards while looking like a T5577 are a clone(?) and not fully featured, so I tend to believe these are the named T5200 chips.

The original fob I got still is not responding to anything i do yet, so will keep looking into that and see what I can find.

Last edited by mwalker (2019-07-11 03:55:04)

Json50 · 2019-10-17 01:07:33

5200 can modify the anti-counterfeiting traceability code of t55x7 series，My supplier has this chip.

mwalker · 2019-10-17 01:26:06

5200 can modify the anti-counterfeiting traceability code of t55x7 series，My supplier has this chip.

Thanks for the feedback.

I have same "original" T5577 and the traceability blocks are locked by atmel. BUT if you write using the test mode, it will clear the lock bits and can then set/use as any other block.

I have some, so called "T5200" or that is what the seller told me.
These card look like the T5577 but the traceability blocks were not locked, as you stated.
BUT these chips DONT support the test mode, they also dont support the AFE Config block 3 page 1

I was hoping the T5200 was a different chip, as I have some fobs/cards that come with the cloner that I cant ID.
The cloner writes the EM4100 id, which you can search, but I cant read the data blocks at all. I can work with the cloner made 5200, 5577, EM4305, but not these.

I thought they MAY have been the T5200 as that was a chip ID on the cloners website.

So the search continue for what they are.

Json50 · 2019-10-17 01:59:04

After the 5200 is used as an ID card, it can be encrypted, so you cannot read it.

mwalker · 2019-10-17 02:56:58

Do you mean encrypted or password protected ?
If you mean encrypted, please supply more information.
If password protected, I can deal and work with that as is.

Note, the "T5200" that I have, I can clone an EM4100 id to them with a Blue or White cloner and then fully recover them with the proxmark.
I can re-clone a different em4100 id and all works.
I can also protect with a password and the cloners cant use them (as they dont know the password that I set)

So if there is a LF card used by the cloners that encrypts, I would like to know more.

mwalker · 2020-08-20 06:13:39

Time to update this one a little.

The great unknown Tag.
To recap:
I have 2 blue cloners and 1 white one with the LCD screen. When you write an EM4100 tag, you can see there are three different types of output, T55x7, EM4305 and the unknown. Since i know the fobs are not T55x7 nor EM4305, what ever they are must respond to the last set of packets.

For those interested in doing their own traces, you may need to make a few captures at different skip offsets to get all of the packets.
(thanks again to marshmallow for adding that)

A little bit more information.
This time i looked at the packets from the white cloner (side note: the white cloner set different passwords on the T55x7 that changed as the EM4100 id changed). In the trace files from the white cloner I can see that they are 16 bits longer, and also sent more packets then the blue cloners.

the following is the decoded data with some comments.
Note: the blue cloner did have a different EM4100 ID (but very happy the EM4100 Data is 100% correct.

blue 
0100(0) 01000101 00000000 - 00000000 00000000 00000000 00000000 - 00000000 00000000 00000000 00000000 - 00000000   
0100(0) 00001010 00000000 - 11111111 10000011 01100000 00000010  <- EM4100 Data
0100(0) 00001010 10000000 - 01001100 01101100 00100100 11000100  <- EM4100 Data
0100(0) 00001010 11111111 - 00000101 00000000 00000000 00000000  

white (blank password)
0100(1) 01000101 00000000   00000000 00000000 00000000 00000000   00000000 00000000 00000000 00000000   00000000 11001110 10101110
0100(1) 00001010 00000000   11111111 10000000 00000000 00000000  <- EM4100 Data                                  01001110 10011010
0100(1) 00001010 10000000   00000000 01100000 00011010 01010010  <- EM4100 Data                                  00010001 11010111
0100(1) 00001010 11111111   00000101 00000000 00000000 00000000  <- Config ??                                    11011000 10001001
0100(1) 00001010 01111111   11100010 00010101 10101100 10000100 (set password)                                   00001110 00010010

(white with password : E215AC84)                                                         Password                
0100(1) 01000101 00000000   00000000 00000000 00000000 00000000   00000000 [11100010 00010101 10101100 10000100] 10000110 10100000
0100(1) 00001010 00000000   11111111 10000000 00000000 00000000                                                  01001110 10011010
0100(1) 00001010 10000000   00000000 01100000 00011010 01010010                                                  00010001 11010111
... more data would follow if I skipped some more samples...

The blue as included as a reference to the original tests.
The two white ones come from the same write, so first group a write to a "blank" card / default 00000000 password (similar to the blue)
But note how the 5th bit was 0 on the blue and no trailing bits, but a 1 on the white, where it seems to have an extra 16 bits.

So at a guess I assume the 5th bit is a flag to using a check or signature of some sort.

Next, we can see that the data set in the 5th write in group 1 was then supplied in the 1st packet of group 2. As such, I think this is the password, and that the 1st packet is a logon commend (still guess work)

wh201906 · 2020-08-21 03:56:51

Is there anyway to replay the waveform sent from the cloner? I guess it's a good way to find the actual payload for the unknown card by just sending part of the waveform.

Last edited by wh201906 (2020-08-21 04:00:41)

mwalker · 2020-08-21 05:30:53

yes, in theory, but no success so far.
I have hard coded so send out the bits which is a fairly close match (my not be 100% yet).
What I noticed on the original (from the cloner) is that it sends a "reset/drop power" then in a shortish time period, starts to send out the data. When I do it, i cant (yet) get the gap short enough. So I am not sure if my output is wrong, or if you need to do it BEFORE the card "times out" and starts to send its "id".

Lots of unknowns.

But, logic says the decode is correct and a high chance its whats needed for the "unknwon" tag.
- The blue cloner ONLY sends 3 types of packets. The T55x7, the EM4305 and the unknown.
- If I use a known em4305, i can fully access and control the card (after a clone)
- If I use a known T5577, i can fully access and control the card (after a clone)
- If I use the unknown tag, the em4305 and T5577 commands do nothing.

the only other option I can see is that if is getting programmed by the T5577 and EM4305 commands, BUT must be done before it times out and starts transmitting its ID.
So, given the lack of actual knowns.... I am trying to see if I can shortened the gap between the power up and sending the command to match the sampled data.

Burak · 2021-12-17 17:15:33

mwalker wrote:

5200 can modify the anti-counterfeiting traceability code of t55x7 series，My supplier has this chip.
Thanks for the feedback.
I have same "original" T5577 and the traceability blocks are locked by atmel. BUT if you write using the test mode, it will clear the lock bits and can then set/use as any other block.
I have some, so called "T5200" or that is what the seller told me.
These card look like the T5577 but the traceability blocks were not locked, as you stated.
BUT these chips DONT support the test mode, they also dont support the AFE Config block 3 page 1
I was hoping the T5200 was a different chip, as I have some fobs/cards that come with the cloner that I cant ID.
The cloner writes the EM4100 id, which you can search, but I cant read the data blocks at all. I can work with the cloner made 5200, 5577, EM4305, but not these.
I thought they MAY have been the T5200 as that was a chip ID on the cloners website.
So the search continue for what they are.

Hello, today I got t5577 and I restored them using lf t55x restore commands but as you said traceability blocks are locked. I tried to write to these blocks using test mode and still no success or maybe couldn't I use test mode correctly? any suggestion? Thanks,

Last edited by Burak (2021-12-17 17:20:04)

mwalker · 2021-12-19 07:54:52

It is possible that the card is not a real t5577 thus does not support test mode. The vendor could have set and locked the traceability data (blocks 1 and 2 page 1).
The other thing that could block it is the actual config. i.e. test mode can be turned off.
Keep in mind a way to test if the card is a real T5577 is to change its downlink mode. the clones (also) don't support the page 1 block 3 config (see the T5577 datasheet)
Can you supply a dump of the card for review ?

Burak · 2021-12-20 12:06:09

mwalker wrote:

It is possible that the card is not a real t5577 thus does not support test mode. The vendor could have set and locked the traceability data (blocks 1 and 2 page 1).
The other thing that could block it is the actual config. i.e. test mode can be turned off.
Keep in mind a way to test if the card is a real T5577 is to change its downlink mode. the clones (also) don't support the page 1 block 3 config (see the T5577 datasheet)
Can you supply a dump of the card for review ?

Sure

[usb] pm3 --> lf t55x detect
[=]  Chip type......... T55x7
[=]  Modulation........ ASK
[=]  Bit rate.......... 2 - RF/32
[=]  Inverted.......... No
[=]  Offset............ 32
[=]  Seq. terminator... Yes
[=]  Block0............ 000880E8 (auto detect)
[=]  Downlink mode..... default/fixed bit length
[=]  Password set...... No

[usb] pm3 --> lf t55x dump
[+] Reading Page 0:
[+] blk | hex data | binary                           | ascii
[+] ----+----------+----------------------------------+-------
[+]  00 | 000880E8 | 00000000000010001000000011101000 | ....
[+]  01 | 01DEE272 | 00000001110111101110001001110010 | ...r
[+]  02 | 6263F224 | 01100010011000111111001000100100 | bc.$
[+]  03 | 26D4CC20 | 00100110110101001100110000100000 | &..
[+]  04 | 99625FF5 | 10011001011000100101111111110101 | .b_.
[+]  05 | 50BE706A | 01010000101111100111000001101010 | P.pj
[+]  06 | 7681A1A1 | 01110110100000011010000110100001 | v...
[+]  07 | 03B446B7 | 00000011101101000100011010110111 | ..F.
[+] Reading Page 1:
[+] blk | hex data | binary                           | ascii
[+] ----+----------+----------------------------------+-------
[+]  00 | 000880E8 | 00000000000010001000000011101000 | ....
[+]  01 | E01500D0 | 11100000000101010000000011010000 | ....
[+]  02 | C8013966 | 11001000000000010011100101100110 | ..9f
[+]  03 | 00000000 | 00000000000000000000000000000000 | ....
[+] saved to json file lf-t55xx-01DEE272-6263F224-26D4CC20-99625FF5-50BE706A-7681A1A1-03B446B7-dump.json
[+] saved 12 blocks to text file lf-t55xx-01DEE272-6263F224-26D4CC20-99625FF5-50BE706A-7681A1A1-03B446B7-dump.eml
[+] saved 48 bytes to binary file lf-t55xx-01DEE272-6263F224-26D4CC20-99625FF5-50BE706A-7681A1A1-03B446B7-dump.bin

mwalker · 2021-12-21 00:29:40

The config/data looks OK, nothing that should prevent it from working.
Lets run a quick test to see if the card is a real T5577 or a clone
The clones I have seen don't support the other downlink modes, so buy trying to set on and checking it applies should help confirm it.

(in the rrg repo, the command would be)
lf t55 write -b 3 --pg1 -d 90000800

then, re-detect (lf t55 det)
and check the downlink status
If its a real t5577 it should be : [=] Downlink mode..... leading zero reference
to clear it, just set it back to 00's

lf t55 write -b 3 --pg1 -d 00000000

Burak · 2021-12-21 13:28:07

mwalker wrote:

The config/data looks OK, nothing that should prevent it from working.
Lets run a quick test to see if the card is a real T5577 or a clone
The clones I have seen don't support the other downlink modes, so buy trying to set on and checking it applies should help confirm it.
(in the rrg repo, the command would be)
lf t55 write -b 3 --pg1 -d 90000800
then, re-detect (lf t55 det)
and check the downlink status
If its a real t5577 it should be : [=] Downlink mode..... leading zero reference
to clear it, just set it back to 00's
lf t55 write -b 3 --pg1 -d 00000000

[usb] pm3 --> lf t55x det
[=]  Chip type......... T55x7
[=]  Modulation........ ASK
[=]  Bit rate.......... 2 - RF/32
[=]  Inverted.......... No
[=]  Offset............ 32
[=]  Seq. terminator... Yes
[=]  Block0............ 000880E8 (auto detect)
[=]  Downlink mode..... default/fixed bit length
[=]  Password set...... No

[usb] pm3 --> lf t55 write -b 3 --pg1 -d 90000800
[=] Writing page 1  block: 03  data: 0x90000800
[usb] pm3 --> lf t55x det
[=]  Chip type......... T55x7
[=]  Modulation........ ASK
[=]  Bit rate.......... 2 - RF/32
[=]  Inverted.......... No
[=]  Offset............ 32
[=]  Seq. terminator... Yes
[=]  Block0............ 000880E8 (auto detect)
[=]  Downlink mode..... default/fixed bit length
[=]  Password set...... No

So according to this I think this is a clone not original one. what are your thoughts?

mwalker · 2021-12-23 01:48:39

Very much looks like a clone card thus does not support the test mode. So once the lock bit is set, at the moment their is no known way to clear it.

Sentinel · 2021-12-23 10:31:22

hi Burak!
looks like a hotel card.
hotel cards almost always use this setting:
[=] Bit rate.......... 2 - RF/32
[=] Seq. terminator... Yes

Proxmark3 community

Announcement

#1 2019-06-10 06:25:39

Looking for a chip data sheet

#2 2019-06-11 04:41:09

Re: Looking for a chip data sheet

#3 2019-06-11 04:52:36

Re: Looking for a chip data sheet

#4 2019-06-11 06:38:49

Re: Looking for a chip data sheet

#5 2019-06-11 06:41:23

Re: Looking for a chip data sheet

#6 2019-06-11 06:53:08

Re: Looking for a chip data sheet

#7 2019-06-11 06:55:37

Re: Looking for a chip data sheet

#8 2019-06-11 17:57:59

Re: Looking for a chip data sheet

#9 2019-06-17 04:12:00

Re: Looking for a chip data sheet

#10 2019-06-18 04:03:33

Re: Looking for a chip data sheet

#11 2019-06-19 22:48:57

Re: Looking for a chip data sheet

#12 2019-07-06 10:05:40

Re: Looking for a chip data sheet

#13 2019-07-06 13:51:19

Re: Looking for a chip data sheet

#14 2019-07-06 19:20:23

Re: Looking for a chip data sheet

#15 2019-07-10 03:10:51

Re: Looking for a chip data sheet

#16 2019-07-10 03:40:39

Re: Looking for a chip data sheet

#17 2019-07-10 04:33:29

Re: Looking for a chip data sheet

#18 2019-07-10 04:58:01

Re: Looking for a chip data sheet

#19 2019-07-10 08:19:00

Re: Looking for a chip data sheet

#20 2019-10-17 01:07:33

Re: Looking for a chip data sheet

#21 2019-10-17 01:26:06

Re: Looking for a chip data sheet

#22 2019-10-17 01:59:04

Re: Looking for a chip data sheet

#23 2019-10-17 02:56:58

Re: Looking for a chip data sheet

#24 2020-08-20 06:13:39

Re: Looking for a chip data sheet

#25 2020-08-21 03:56:51

Re: Looking for a chip data sheet

#26 2020-08-21 05:30:53

Re: Looking for a chip data sheet

#27 2021-12-17 17:15:33

Re: Looking for a chip data sheet

#28 2021-12-19 07:54:52

Re: Looking for a chip data sheet

#29 2021-12-20 12:06:09

Re: Looking for a chip data sheet

#30 2021-12-21 00:29:40

Re: Looking for a chip data sheet

#31 2021-12-21 13:28:07

Re: Looking for a chip data sheet

#32 2021-12-23 01:48:39

Re: Looking for a chip data sheet

#33 2021-12-23 10:31:22

Re: Looking for a chip data sheet

Board footer