Possible T55xx Tag & Chinese Cloner

danv · 2019-02-06 13:32:02

Hi everyone,

I have a question regarding some possible T55xx tags that came with a chinese cloner I bought from AliExpress. I initially noted I could not use this tags with the proxmark, because I was unable to write into them as usual using the

 lf em 410xwrite

command.

Reading through this forum I became aware that this infamous cloner sets a password on cloned tags. Since I tried all the passwords I could find with the

 lf t55xx bruteforce

command with no success, I thought that maybe this cloner uses a different password. I set out to find this password, and as is turns out it is : 0x51243648

Currently, I have following questions:

1) How can I configure the proxmark to read a T5XX tag, when lf t55xx detect is unable to identify the tags configutaration (modulations, offset, rate)?
2) Why does lf t55xx bruteforce fail to identify the password eventhough it is in the default_pwd.dic ?
3) Can block 0 (containing the configuration) still be read even though password protected?
4) Is it possible that my tag is actually not all a T55xx?

Any help would be greatly appreciated. Please let me know what other information I should provide. I'm new to this community.

Thanks!

danv · 2019-02-07 12:53:55

Hi again,

I decoded the payload sent by the blue cloner (data for block #0) and was able to determine (I think. Not entirely confident.) the tag's configuration. Nevertheless, I'm still unable to correctly read the contents. Could anyone help me out?

Scope capture for configuration block:

Data Bit Rate: 64 cycles/bit
Modulation: Manchester
Password: 1
ST: 0
Fast Write: 0
Invert: 0
POR: 0

proxmark3> lf t55xx detect
Could not detect modulation automatically. Try setting it manually with 'lf t55xx config'

proxmark3> lf t55x config
Chip Type  : T55x7          
Modulation : ASK          
Bit Rate   : 5 - RF/64          
Inverted   : No          
Offset     : 0          
Seq. Term. : No          
Block0     : 0x00000000

proxmark3> lf t55x read b 0 p 51243648 o
Reading Page 0:          
blk | hex data | binary          
----+----------+---------------------------------          
Safety Check Overriden - proceeding despite risk          
  0 | 7FD94000 | 01111111110110010100000000000000

I would expect to see 0x00148050. I've tried with different offsets, with no success.

proxmark3> hw tune l

Measuring antenna characteristics, please wait........          
# LF antenna: 34.65 V @   125.00 kHz          
# LF antenna: 31.49 V @   134.00 kHz          
# LF optimal: 35.89 V @   127.66 kHz          
Displaying LF tuning graph. Divisor 89 is 134khz, 95 is 125khz.

proxmark3> hw version
Prox/RFID mark3 RFID instrument          
bootrom: master/v3.1.0-53-ga9104f7-suspect 2019-01-30 20:13:07
os: master/v3.1.0-53-ga9104f7-suspect 2019-01-30 20:13:08
fpga_lf.bit built for 2s30vq100 on 2015/03/06 at 07:38:04
fpga_hf.bit built for 2s30vq100 on 2018/11/28 at 08:33:11
SmartCard Slot: not available
          
uC: AT91SAM7S512 Rev B          
Embedded Processor: ARM7TDMI          
Nonvolatile Program Memory Size: 512K bytes. Used: 202493 bytes (39). Free: 321795 bytes (61).          
Second Nonvolatile Program Memory Size: None          
Internal SRAM Size: 64K bytes          
Architecture Identifier: AT91SAM7Sxx Series          
Nonvolatile Program Memory Type: Embedded Flash Memory

Last edited by danv (2019-02-07 12:56:40)

anybody · 2019-02-07 18:26:48

it is possible that your chinese cloner can write em4305 and your tag is..
not t55xx

danv · 2019-02-07 21:11:09

Hi @anybody,

Thank you for your suggestion. I had indeed tried out the em4305 commands with no success. My two main reasons for suspecting it is not an EM4305 tag are: the payload send by the reader matches surprisingly well to the programming protocol of a T55xx tag described in the datasheet. Second, according to the EM4305 datasheet, block 0 and 1 are not read protected. When I tried to read them, I just get a failed message.

Have you ever captured the blue cloner's programming sequence? I'm curious to compare.

proxmark3> lf em 4x05dump 51243648
Read Address 00 | failed          
Read Address 01 | failed          
 PWD Address 02 | 51243648          
Read Address 03 | failed          
Read Address 04 | failed          
Read Address 05 | failed          
Read Address 06 | failed          
Read Address 07 | failed          
Read Address 08 | failed          
Read Address 09 | failed          
Read Address 10 | failed          
Read Address 11 | failed          
Read Address 12 | failed          
Read Address 13 | failed          
Read Address 14 | failed          
Read Address 15 | failed

proxmark3> lf em 4x05dump
Read Address 00 | failed          
Read Address 01 | failed          
 PWD Address 02 | cannot read          
Read Address 03 | failed          
Read Address 04 | failed          
Read Address 05 | failed          
Read Address 06 | failed          
Read Address 07 | failed          
Read Address 08 | failed          
Read Address 09 | failed          
Read Address 10 | failed          
Read Address 11 | failed          
Read Address 12 | failed          
Read Address 13 | failed          
Read Address 14 | failed          
Read Address 15 | failed

danv · 2019-02-11 21:32:41

Just wanted to update this thread with some progress I made.

I finally took the time to decode every single pulse train / writing sequence the "blue cloner" transmits. In essence, my cloner transmits a total of 14 pulse trains separated by period in which the antenna is left "on" oscillating at 125kHz (there is probably a name for this, not really sure what to call it). This period is required by the tag finish programming after a write sequence is transmitted. Roughly the first half of the sequences assume the tag is protected and can be accessed with the password 0x51243648. The other half attempts to write the tag using normal no-password commands. The ID being written is 0x6A0016E5AB.
Pulse 1 is a bit special, as it uses leading-zero reference protocol.

(Only for sequence 1) [Reference Zero] [Op Code] [00] [Password 1-32] [Lock Bit] [Data 1-32] [Addr 2-0]
Seq #1: [0] [11] [00] [pwd: 0101 0001 0010 0100 0011 0110 0100 1000] [0] [32 0s] [011]

Seq#: [Op Code] [Password 1-32] [Lock Bit] [Data 1-32] [Addr 2-0]
Seq #2: [10] [pwd ...] [0] [pwd ...] [111]
Seq #3: [10] [pwd ...] [0] [pwd ...] [111] (Block #7 is written two times with the password.)
Seq #4: [10] [pwd ...] [0] [0000 0000 0001 0100 1000 0000 0101 0000] [000]
Seq #5: [10] [pwd ...] [0] [1111 1111 1011 0010 1000 0000 0000 0000] [001]
Seq #6: [11] [pwd ...] [0] [1111 1111 1011 0010 1000 0000 0000 0000] [001]
Seq #7: [10] [pwd ...] [0] [1101 1001 1101 0101 0101 0010 1110 0010] [010]
Seq #8: [11] [pwd ...] [0] [1101 1001 1101 0101 0101 0010 1110 0010] [010]
(Writing into block 1 & 2 in page 1 the same payload as in page 0. I'm not certain if this actually overwrites the traceability data.)
Seq #9: [11] [pwd ...] [0] [0110 00000000 0000 0000 1000 0000 0000] [011]
(Enabling analog front-end by setting Option Key=0x6 and setting leading-zero reference protocol).

Seq #10: [000] (A reset command with leading zero reference.)

The next sequences attempt to write the tag without using a password
Seq#: [Op Code] [0] [Data 1-32] [Addr 2-0]
Seq #11: [10] [0] [0000 0000 0001 0100 1000 0000 0100 0000] [000]
Seq #12: [10] [0] [1111 1111 1011 0010 1000 0000 0000 0000] [001]
Seq #13: [10] [0] [1101 1001 1101 0101 0101 0010 1110 0010] [010]

Seq #14: [00] (Simple reset op code.)

It seems that by enabling the leading-zero reference protocol the cloner "soft-bricks" the tag, that is, with the latest public firmware, it is not possible to change the settings of block 3 page 1. I modified the write command on the proxmark to accept a 'z' argument and send the required reference and padding zeros.

Part of the T55xxwriteBlockExt function:

void T55xxWriteBlockExt(uint32_t Data, uint32_t Block, uint32_t Pwd, uint8_t arg) { LED_A_ON(); bool PwdMode = arg & 0x1; uint8_t Page = (arg & 0x2)>>1; bool testMode = arg & 0x4; bool leadingZero = arg & 0x8; uint32_t i = 0;
  // Set up FPGA, 125kHz
LFSetupFPGAForADC(95, true);
StartTicks();
// make sure tag is fully powered up...
WaitMS(5);
// Trigger T55x7 in mode.
FpgaWriteConfWord(FPGA_MAJOR_MODE_OFF);
WaitUS(START_GAP);
// Send "zero" reference pulse
if (leadingZero) {
    T55xxWriteBit(0);
}
if (testMode) Dbprintf("TestMODE");
// Std Opcode 10
T55xxWriteBit(testMode ? 0 : 1);
T55xxWriteBit(testMode ? 1 : Page); //Page 0
// Send Padding zeros
if (PwdMode & leadingZero){
    T55xxWriteBit(0);
    T55xxWriteBit(0);
}
if (PwdMode) {
    // Send Pwd
    for (i = 0x80000000; i != 0; i >>= 1)
        T55xxWriteBit(Pwd & i);

   }
// Send Lock bit
T55xxWriteBit(0);
...

My first attempt to rewrite the analog front-end settings produced no change on the tag. At this point, I thought it was easier to capture the proxmark writing sequence with an oscilloscope rather than debugging the proxmark using JTAG etc...

Except for a few differences in gap lengths, the proxmark emulates the cloner's first sequence. Yet, the contents of block 3 page 1 seem to remain unchanged.

I'm stuck again.

Any comments or insights would be greatly appreciated.

Last edited by danv (2019-02-11 21:48:49)

anybody · 2019-02-12 13:17:58

most likely it is not the leading-zero reference protocol..

http://www.proxmark.org/forum/viewtopic.php?id=6029
http://www.proxmark.org/forum/viewtopic.php?id=4717

danv · 2019-02-12 19:16:38

Hi @anybody,

At this point I feel I'm going in circles. I managed to get my hands on a brand new T577. I used the cloner to copy the same UID (as in my previous entry) and was able to unlock it with a simple lf t55xx write b 0 d 001480E0 p 51243648 .

 
proxmark3> lf t55xx write b 0 d 001480E0 p 51243648 
Writing page 0  block: 00  data: 0x001480E0 pwd: 0x51243648           
proxmark3> lf t55xx dump
Reading Page 0:          
blk | hex data | binary          
----+----------+---------------------------------          
  0 | 001480E0 | 00000000000101001000000011100000          
  1 | FFB28000 | 11111111101100101000000000000000          
  2 | D9D552E2 | 11011001110101010101001011100010          
  3 | FFFFFFFF | 11111111111111111111111111111111          
  4 | FFFFFFFF | 11111111111111111111111111111111          
  5 | FFFFFFFF | 11111111111111111111111111111111          
  6 | FFFFFFFF | 11111111111111111111111111111111          
  7 | 51243648 | 01010001001001000011011001001000          
Reading Page 1:          
blk | hex data | binary          
----+----------+---------------------------------          
  0 | 001480E0 | 00000000000101001000000011100000          
  1 | FFB28000 | 11111111101100101000000000000000          
  2 | D9D552E2 | 11011001110101010101001011100010          
  3 | 60000800 | 01100000000000000000100000000000

This verified the decoded data of my last entry. Except for the analog front end, not sure whats is going on there. As I understand it, it should be in leading-zero protocol mode. I have no clue. My attempt to write the new block 0 data using leading-zero also failed.

This proofs that the first tag I was using for testing (small blue key fob) is indeed not a T55xx tag.

With this in mind, I took a longer capture of the cloner's write sequence with the oscilloscope. It turns out it sends more pulse trains after the ones I decode. Probably to write a EM4305? One of the pulse trains seems to be 96 pulses long!

Can a EM4305 also produce a EM410x pattern?

@anybody, you were probably right! Thanks!

Last edited by danv (2019-02-12 19:52:17)

marshmellow · 2019-02-13 06:40:42

Can a EM4305 also produce a EM410x pattern?

Yes it can. You just need to configure it correctly.

Now em4305 keyfobs can be especially difficult to communicate with with the pm3. A properly tuned and sized antenna is your friend.

I'm interested in why the pm3 write command looks like a fish when all the traces of the cloner are nice and square. Is that a good capture?

anybody · 2019-02-13 16:14:50

danv wrote:

With this in mind, I took a longer capture of the cloner's write sequence with the oscilloscope. It turns out it sends more pulse trains after the ones I decode. Probably to write a EM4305? One of the pulse trains seems to be 96 pulses long!

@danv, it's not em4305, most likely it's t55xx..
Can you attach another 3 long traces from your Chinese cloner (each must be 69 bits, starts from 01)?

Last edited by anybody (2019-02-13 19:59:02)

danv · 2019-02-18 20:58:28

Hello @marshmellow & @anybody,

Sorry that it took me this long to reply.

Regarding the strange shape of the proxmark's read command: I think it was due to aliasing. I increased the sample rate to 2 MS/s and the trace now looks normal. See below:

Aliased trace:

Non-aliased trace:

@anybody: I surely would appreciate your help with these tags, although I'm not sure how they could be T55xx tags, they do not respond to any command. I just ordered some EM4305 from AliExpress to compare how they behave.

I uploaded traces as pictures. There are 3 folders, each containing a set of sequences, each set of sequences is separated by a 'long' period of the field being ON (not shown), that is, with no write data. Additionally I included the entire trace as a WAV file, viewable with Audacity. Folder A contains captures of T55xx write commands (the ones I showed in my earlier post). I have not managed to decoded the sequences contained in folders B & C.

https://mega.nz/#F!QERlkIYa!HKpcNqRe0Ez3L4P82Z1Xlw

Thank you for your help!

Last edited by danv (2019-02-19 19:03:27)

anybody · 2019-02-19 16:50:49

@danv, if you are ready to "break" one more tag t5577, then try the following:
1. Write some ID to the tag and set a password (not 51243648) using proxmark
2. Try to copy another ID (not from 1.) to this tag using a blue cloner
3. Most likely, nothing more can be written to this tag using proxmark... only chinese cloner

danv · 2019-02-19 19:02:18

Hi @anybody,

The problem is that all the tags that came with this cloner behave the same way. In other words, non of them are empty, they all contain the same EM TAG ID 3D00D51E2C. I'm only able to write them using the cloner. Quite puzzling. I think the vendor might have tested all of them, some sort of quality control.

Last edited by danv (2019-02-19 19:02:38)

danv · 2019-02-19 22:35:20

I confirmed the sequences on folder B are valid EM4305 write commands. If the tags were EM4305, the password being set would have been 0x9F3BD705.

Configuration being set:
RF/66
Manchester
No Delay
Last default read = 6
Read login = 0
Write login = 1
Reader talk first = 0
Pigeon mode = 0

My hypotheses is then that, the sequences of folder C (the one with 96 pulses) must be accepted write sequence. Figuring out what chip accepts these sequences is the next task. See below:

Sequence 1:

Sequence 2:

Sequence 3:

Sequence 4:

So, is there any other tag that can emulate a EM410x? Could the traces be a strange configuration of the T55xx/EM4x05?

Last edited by danv (2019-02-20 00:09:06)

anybody · 2019-02-20 11:54:35

@danv,
Is EM TAG ID 6A 00 16 E5 AB ?
Finally, WAV downloaded.
The question is removed.

Last edited by anybody (2019-02-21 16:02:29)

danv · 2019-02-21 16:03:16

Yes! Sequence 2 & 3 encode the EM ID 6A 00 16 E5 AB, including initial 0b1 + 0xFF and parity bits. All sequences begin with 0x4, might be the op-code?

See annotated sequences below:

[Click on picture to enlarge]
Sequence 1:

Sequence 2: (0b1 + FF 6A 00)

Sequence 3: (16 E5 AB)

Sequence 4:

If you take a look at the entire capture (wav file), it is clear that the tag is responding to this commands (sequences C), contrary to the sequences A (T55xx) & B (EM4x05), where the tag goes into regular read mode immediately after the sequence ends.

Tag accepts command (Unknown C sequence) / Tag rejects command (T55xx)

anybody · 2019-02-22 07:44:14

I saw almost the same sequences in WAV file here:
http://www.proxmark.org/forum/viewtopic.php?id=6029
T55x7 (with PWD) - EM4x05 (with PWD) - T55x7 (???)
Most likely, it's t55x7 test mode (opcode "01"). But I did not find any information about this mode.
Here @marshmellow tried to understand this question...
http://www.proxmark.org/forum/viewtopic … 933#p26933
May be(???)
Sequence1 (wipe, precfg?) - 93 bits
01(opcode)-0000100010100000000 (19bits cfg?)-000....000(72bits)
Sequence2 (data) - 53 bits
01(opcode)-0000000101000000000 (19bits cfg?)-32bits(ID, as blk1)
Sequence3 (data) - 53 bits
01(opcode)-0000000101010000000 (19bits cfg?)-32bits(ID, as blk2)
Sequence4 (cfg?) - 53 bits
01(opcode)-0000000101011111111 (19bits cfg?)-00000101000000000000000000000000 (32bits)
Try locked t5577 and different ID

Last edited by anybody (2019-02-22 19:27:09)

danv · 2019-03-05 23:18:08

Hi @anybody,
Sorry for taking so long to reply . I did what you suggested. I wrote a blank T55xx tag with 0xFFFFFFFFFF and copied to one of the unknown tags using the cloner. I decoded once more the cloner write sequences. I XOR'ed the write sequences (C) of 0x6A0016E5AB and 0xFFFFFFFFFF.

https://pastebin.com/EMBx0rSX

I've marked my assumption for the page bit. Sequence 1 and 4 are identical for both.
My intention is to simulate this write sequence with the proxmark and fuzz some bits. My first attempt will be to swap blocks.

Last edited by danv (2019-03-05 23:21:42)

gjuny · 2019-06-05 13:05:38

Hi @danv,

Any updates with your investigation? I stumbled here by accident while playing with blue tags that appear to be the same as the ones you got. They came with the same EM TAG ID (3D00D51E2C) as yours and I can only change them with the cloner I have (link). These tags came with the cloner when I purchased it.

My Proxmark3 Easy clone, which came from the same vendor (link), also came with the same blue tags with the same EM TAG ID.

Any information is appreciated. Thanks!

Last edited by gjuny (2019-06-05 14:22:49)

mwalker · 2019-06-05 22:08:21

I have a few of these as well, they all look the same. From one batch they were t5577 the other look like an updateable em tags.
I tested by creating an em4100 tag on a t5577 then used the cloner to clone that to the blue fob, it did clone it.
So I believe it's needs the em4100 commands.
I have not had time to get back to it, but the lf snoop runs out of buffer space before it gets to the em commands even at d 2. Any higher then d 2 and i loose detail for a clean decode.

gjuny · 2019-06-07 13:52:05

@mwalker, I've tried using EM410x commands without success. It can read the tags, but not write. I'm guessing it has a password set, but trying T55xx bruteforce with known passwords also doesn't work...

I have to dig deeper trying to see what is in the tags, but not even sure where to start. Any tips?

anybody · 2019-06-07 19:24:01

@gjuny, can you attach traces from your Chinese cloner?

gjuny · 2019-06-08 00:04:51

@anybody, ok, let's see if I can get this right. This is my first time capturing a trace. I hope it's usable.

First capture
Second capture
Third capture

They were captured with the following commands:

lf config b 8 L t 64
lf read
data save <filename>

Additionally, there is another trace done with LF SNOOP:

Fourth capture

This is what I get if I do an LF SEARCH at the tag:

proxmark3> lf search
NOTE: some demods output possible binary
  if it finds something that looks like a tag          
False Positives ARE possible
          

Checking for known tags:
          
EM410x pattern found:           

EM TAG ID      : 3D00D51E2C          

Possible de-scramble patterns          
Unique TAG ID  : BC00AB7834          
HoneyWell IdentKey {          
DEZ 8          : 13966892          
DEZ 10         : 0013966892          
DEZ 5.5        : 00213.07724          
DEZ 3.5A       : 061.07724          
DEZ 3.5B       : 000.07724          
DEZ 3.5C       : 213.07724          
DEZ 14/IK2     : 00262006971948          
DEZ 15/IK3     : 000807465089076          
DEZ 20/ZK      : 11120000101107080304          
}
Other          : 07724_213_13966892          
Pattern Paxton : 1038703660 [0x3DE95C2C]          
Pattern 1      : 14896340 [0xE34CD4]          
Pattern Sebury : 7724 85 5578284  [0x1E2C 0x55 0x551E2C]          

Valid EM410x ID Found!

Thanks for the help! Any feedback on the capture or ways to improve it are greatly appreciated. If there is information somewhere where I can learn more about those traces, let me know.

Last edited by gjuny (2019-06-08 15:47:35)

mwalker · 2019-06-08 01:54:07

The EM4100 Tags I have with the same looking blue cloner, come with the same ID : EM TAG ID : 3D00D51E2C
With these I have not worked out the write commands as the EM (or what every its using) commands are after the t55xx commands at the start, So if anyone has a simple what to "skip x samples" for the lf snoop let me know).
That said, the T55xx fobs were written with leading 0 protocol (my pm3 software did not support that so I put a leading zero write command into my software that allowed me to write to the T55xx)
So, for the t55xx this is what my blue cloner did.
1. The Password was the generic blue password.
2. The cloner sets the options in Block 3 Page 1 to set the leading 0 protocol.
3. The T5577 settings (from the block 0 config) was RF/64 Manchester/Ask
4. The very first command sent to the card was to clear the Block 3 page 0 (so no leading 0) then the normal commands.
5. In setting up the leading 0 write function, you need to ensure the correct packet format and it has different timings then normal.

If they are t5577 then we can recover and reuse.
If they are something different (writable em4100) then I am sure we can work it out, just need to get the command dumps..

To move forwards, and see if your cloner is doing the same, lets try this.

1. Set up the lf snoop.

lf config t 64 d 2

This tells the snoop not to start recording until it sees a level of 64 (so wait till we send something) and record every 2nd sample. This has less detail, but will record more packets

2. Power on the blue cloner and read a tag as normal.
Give it something to write

3. With no tag, place the cloner near the proxmark as if the proxmark was the card/fob.

4. on the pm3 software

lf snoop

5. push the write button on the cloner.

6. Read the samples

data samples

7. Plot them (to see if we got it)

data plot

8. Save and post.

data save <filename>.pm3

Post the snoop file and we can have a look.

Also, what would be worth a play as well.
Get a blank t5577 and create an EM tag via the proxmark. Use the t5577 and clone that to the fob with the cloner, then read the fob via the proxmark.
This will prove they can be updated. It also provides a way to encode with the ID you want.

gjuny · 2019-06-08 05:33:16

@mwalker, thanks for the helping out!

Just one clarification, my cloner is not the blue one, but a white one with a keyboard (link). It works on multiple frequencies and says the frequency and UIDs in a bad English. I was able, with this cloner, to manually type a code which was then successfully recorded to a blue tag.

Click for full image

Back to your suggestion to check what my cloner is doing. I have followed your instructions and the dump can be found here: White Cloner LF SNOOP

I don't have any blank T5577 at hand. Unfortunately I only have the blue fobs. I'm going to order some, but they should take around a month to arrive.

Thanks once again for helping out!

mwalker · 2019-06-08 10:34:29

Given the different cloner, it might be worth a separate/new thread.
I had a quick look at the snoop. It does not look like it had any T5577 commands in it.
I did a quick web surf and a few of the deals with that cloner seem to ship with the EM4305 tag.
I had a scan over the data sheet (as I have not used that tag) and it may be that device.
With the EM4305 tags you need to logon for protected operations (e.g. write), and It should be a two way between reader and tag.
As such, can I get you to re-run the snoop, but this time with the tag on the proxmark.

You could also try the dump (without a password) and see if anything comes back.

lf em 4x05dump

Some of the blocks my not need a password to read, so you may get data back. I would also try a few generic passwords e.g. 00000000, 11111111, FFFFFFFF etc.

anybody · 2019-06-08 14:06:13

@mwalker, I think that a new thread is not needed.
This Chinese cloner uses the same unknown commands for t5577 as the previous one. It's not em4305 commands.

gjuny · 2019-06-08 15:19:26

@mwalker, I ran the LF EM 4x05DUMP command without and with some passwords without any success. See below the output:

proxmark3> lf em 4x05dump
Read Address 00 | failed          
Read Address 01 | failed          
 PWD Address 02 | cannot read          
Read Address 03 | failed          
Read Address 04 | failed          
Read Address 05 | failed          
Read Address 06 | failed          
Read Address 07 | failed          
Read Address 08 | failed          
Read Address 09 | failed          
Read Address 10 | failed          
Read Address 11 | failed          
Read Address 12 | failed          
Read Address 13 | failed          
Read Address 14 | failed          
Read Address 15 | failed
proxmark3> lf em 4x05dump 00000000
Read Address 00 | failed          
Read Address 01 | failed          
 PWD Address 02 | 00000000          
Read Address 03 | failed          
Read Address 04 | failed          
Read Address 05 | failed          
Read Address 06 | failed          
Read Address 07 | failed          
Read Address 08 | failed          
Read Address 09 | failed          
Read Address 10 | failed          
Read Address 11 | failed          
Read Address 12 | failed          
Read Address 13 | failed          
Read Address 14 | failed          
Read Address 15 | failed          
proxmark3> lf em 4x05dump ffffffff
Read Address 00 | failed          
Read Address 01 | failed          
 PWD Address 02 | FFFFFFFF          
Read Address 03 | failed          
Read Address 04 | failed          
Read Address 05 | failed          
Read Address 06 | failed          
Read Address 07 | failed          
Read Address 08 | failed          
Read Address 09 | failed          
Read Address 10 | failed          
Read Address 11 | failed          
Read Address 12 | failed          
Read Address 13 | failed          
Read Address 14 | failed          
Read Address 15 | failed          
proxmark3> lf em 4x05dump 11111111
Read Address 00 | failed          
Read Address 01 | failed          
 PWD Address 02 | 11111111          
Read Address 03 | failed          
Read Address 04 | failed          
Read Address 05 | failed          
Read Address 06 | failed          
Read Address 07 | failed          
Read Address 08 | failed          
Read Address 09 | failed          
Read Address 10 | failed          
Read Address 11 | failed          
Read Address 12 | failed          
Read Address 13 | failed          
Read Address 14 | failed          
Read Address 15 | failed          
proxmark3> lf em 4x05dump AABBCCDD
Read Address 00 | failed          
Read Address 01 | failed          
 PWD Address 02 | AABBCCDD          
Read Address 03 | failed          
Read Address 04 | failed          
Read Address 05 | failed          
Read Address 06 | failed          
Read Address 07 | failed          
Read Address 08 | failed          
Read Address 09 | failed          
Read Address 10 | failed          
Read Address 11 | failed          
Read Address 12 | failed          
Read Address 13 | failed          
Read Address 14 | failed          
Read Address 15 | failed

A LF EM 4x05INFO outputs nothing.

I have rerun the snoop with the tag which can be found here: LF SNOOP with Blue Tag and White Cloner

Lastly, what first pulled me into this thread was the blue tag with the same UID. I think I'll keep information here for now. My objective is to get to make the blue tag writable with the Proxmark so I can use it to copy a HID card, provided this fob is really a T55xx. The white cloner is unable to read HID cards unfortunately.

Thanks!

Last edited by gjuny (2019-06-08 15:48:58)

gjuny · 2019-06-08 15:24:45

Another update, here is what I got from LF T55XX CONFIG after setting the bit rate to RF/64:

proxmark3> lf t55xx config 
Chip Type  : T55x7          
Modulation : ASK          
Bit Rate   : 5 - RF/64          
Inverted   : No          
Offset     : 0          
Seq. Term. : No          
Block0     : 0x00000000          
          
proxmark3> lf t55xx info
          
-- T55x7 Configuration & Tag Information --------------------          
-------------------------------------------------------------          
 Safer key                 : 0          
 reserved                  : 125          
 Data bit rate             : 1 - RF/16          
 eXtended mode             : No          
 Modulation                : 0x1C (Unknown)          
 PSK clock frequency       : 0          
 AOR - Answer on Request   : Yes          
 OTP - One Time Pad        : Yes - Warning          
 Max block                 : 5          
 Password mode             : Yes          
 Sequence Start Terminator : Yes          
 Fast Write                : Yes          
 Inverse data              : Yes          
 POR-Delay                 : Yes          
-------------------------------------------------------------          
 Raw Data - Page 0          
     Block 0  : 0x0FA5C3BF  00001111101001011100001110111111          
-------------------------------------------------------------

Here's the LF T55XX DUMP with the same configuration:

proxmark3> lf t55xx dump
Reading Page 0:          
blk | hex data | binary          
----+----------+---------------------------------          
  0 | 0FA5C3BF | 00001111101001011100001110111111          
  1 | 1F4B877F | 00011111010010111000011101111111          
  2 | 1F4B877F | 00011111010010111000011101111111          
  3 | 1F4B877F | 00011111010010111000011101111111          
  4 | 1F4B877F | 00011111010010111000011101111111          
  5 | 1F4B877F | 00011111010010111000011101111111          
  6 | 1F4B877F | 00011111010010111000011101111111          
  7 | 3E970EFF | 00111110100101110000111011111111          
Reading Page 1:          
blk | hex data | binary          
----+----------+---------------------------------          
  0 | 1F4B877F | 00011111010010111000011101111111          
  1 | 1F4B877F | 00011111010010111000011101111111          
  2 | 1F4B877F | 00011111010010111000011101111111          
  3 | 3E970EFF | 00111110100101110000111011111111

Not sure how relevant or accurate this information is, but I hope it can help.

Last edited by gjuny (2019-06-08 15:49:50)

gjuny · 2019-06-08 18:27:04

Further update. I've cloned an EM4100 tag to the blue fob and here is the information. Seems like the LF T5XX DUMP is outputting gibberish.

proxmark3> lf search
NOTE: some demods output possible binary
  if it finds something that looks like a tag          
False Positives ARE possible
          

Checking for known tags:
          
EM410x pattern found:           

EM TAG ID      : 780096F475          

Possible de-scramble patterns          
Unique TAG ID  : 1E00692FAE          
HoneyWell IdentKey {          
DEZ 8          : 09892981          
DEZ 10         : 0009892981          
DEZ 5.5        : 00150.62581          
DEZ 3.5A       : 120.62581          
DEZ 3.5B       : 000.62581          
DEZ 3.5C       : 150.62581          
DEZ 14/IK2     : 00515405968501          
DEZ 15/IK3     : 000128855912366          
DEZ 20/ZK      : 01140000060902151014          
}
Other          : 62581_150_09892981          
Pattern Paxton : 2024485493 [0x78AB3275]          
Pattern 1      : 6945564 [0x69FB1C]          
Pattern Sebury : 62581 22 1504373  [0xF475 0x16 0x16F475]          

Valid EM410x ID Found!
proxmark3> lf t55xx info
          
-- T55x7 Configuration & Tag Information --------------------          
-------------------------------------------------------------          
 Safer key                 : 7          
 reserved                  : 73          
 Data bit rate             : 3 - RF/8          
 eXtended mode             : Yes - Warning          
 Modulation                : 0x15 (Unknown)          
 PSK clock frequency       : 1          
 AOR - Answer on Request   : No          
 OTP - One Time Pad        : No          
 Max block                 : 5          
 Password mode             : Yes          
 Sequence Start Terminator : Yes          
 Fast Write                : Yes          
 Inverse data              : Yes          
 POR-Delay                 : Yes          
-------------------------------------------------------------          
 Raw Data - Page 0          
     Block 0  : 0x792F54BF  01111001001011110101010010111111          
-------------------------------------------------------------          
proxmark3> lf t55xx dump
Reading Page 0:          
blk | hex data | binary          
----+----------+---------------------------------          
  0 | 792F54BF | 01111001001011110101010010111111          
  1 | F25EA97F | 11110010010111101010100101111111          
  2 | F25EA97F | 11110010010111101010100101111111          
  3 | F25EA97F | 11110010010111101010100101111111          
  4 | F25EA97F | 11110010010111101010100101111111          
  5 | F25EA97F | 11110010010111101010100101111111          
  6 | F25EA97F | 11110010010111101010100101111111          
  7 | E4BD52FF | 11100100101111010101001011111111          
Reading Page 1:          
blk | hex data | binary          
----+----------+---------------------------------          
  0 | F25EA97F | 11110010010111101010100101111111          
  1 | F25EA97F | 11110010010111101010100101111111          
  2 | F25EA97F | 11110010010111101010100101111111          
  3 | E4BD52FF | 11100100101111010101001011111111

Last edited by gjuny (2019-06-08 18:28:09)

mwalker · 2019-06-09 02:39:05

To help you understand a few things.
When you have a chip/tag/fob it will to what ever its told to do. In the case of the em4100, its a read only chip that when energized, will send out its ID. That ID is as per specs, and in the last post case the id 780096F475 will be sent as FFBE2004 99E4BD52
When you run a lf t55 info/dump the programmer will energize the tag, which in tern will spit out the ID. The lf t55 config is the settings that tells the proxmark how you want to interpret and send the data from/to the t55 chip. e.g. clock speed, encoding. It also tells the software at what offset do you want to start "displaying data" from.
So without being able to talk to an actual T55xx chip correctly (e.g. Its in a different mode, not a T55xx chip), then the results will most likely be the em4100 tag ID (or part of), if correctly decoded.

I can see that. If I take the tag ID data and convert to binary, then see if I can line up a sample from your binary, I find a perfect match.

11111111 10111110 00100000 00000100 10011001 11100100 10111101 01010010
1111111                                    1 11100100 10111101 01010010

if you were to increase or decrease the o (offset) value in the t55 config setup, you will see it start in a different spot and you should be able to get the entire ID (as encoded/transmitted)

Were I am at, is I think you are in the same position i am. you have some fobs and we don't know what they are. We know the cloner can encode them with different em4100 tag IDs, so we know they are not an em4100 tag, but can emulate them (i.e. em4100 tags are readonly can cant have anything changed). So a common chip used is the t55xx to clone/emulate (as it can do many things); But in the sniff you sent, i cant see any T55xx commands. Added to that, with the kit I have from 3 vendors, i got 15 fobs. 5 looked different (cheap) and were t5577. of the other 10 they look 100% the same, 5 were t5577 and 5 are something else. I with the t5577 fobs I can encode with the cloner to be a em4100, then I can send the commands to clear and set back to a blank t5577 (every time). with the 5 unknown, so far nothing works and no data has changed (except when sent from the programmer). So am am very sure the last 5 fobs are not t5577 chips.

So the big question is what are they and what can the do (e.g. just because they can be an em4100 does not imply they can do anything else).

So, what I am working though is trying to turn unknown into known's.

Since if don't have other known chips, i cant run tests to confirm how the behave in em4100 mode, so I am taking same educated guesses and then see if the data sheets match what I see in the dumps. I am trying to align the em4100 tag data with the data in the packet sent when programming the fob, but this can be a little tricky as we don't know how the data needs to be sent to ensure its encoded.
e.g. on the t5577 we know we send the tag id to blocks 1 and 2 of page 0 (then set the config block 0 and page 0 and maybe the config on block 3 page 1). So we know we can expect to see the em id bit pattern line up in its two halves. But some other chips may want it sent in a different way (e.g. nibbles, inverted, nibbles with parity, bytes with parity, 7 bit bytes). So if we knew the chip, we would just grab the data sheet and it would tell us.

i even opened open up one and the chip is encased on a black blob. so cant read any ids off it.

So we are back to trying to work out what the chip is by the way it talks/accepts commands.

If anyone else has some good guesses, please post.

anybody · 2019-06-09 07:11:34

@mwalker, can you attach traces from your Chinese cloner?

mwalker · 2019-06-09 07:51:12

@anybody.

blue_em_clone.pm3

From my side I don't have an issue, just research. I got 2 of the blue cloners (as picture in post 1) both were a little different but some blue t5577 generic password. The third i got was a white cloner with an lcd color screen.
From my side, I can read and write to the t5577 tokens from each, sniff and get all the details, and can fully recover the t5577 no problem.
What I did have (for reference) was
1. First blue cloner, set generic password and normal t55 write command with password would alter the card... basic and normal
2. The 2nd blue cloner sets the config in block 3 page 1 for leading 0. This needed the leading 0 support (which I added to my pm3 code) and could then re-write the block 3 page 1 back to 00000000 then read/write as normal with the password.
3. The white cloner sets a password based on the card ID (i.e. changes with most IDs). So if I write with (say id all 0) then I can use the sniffed password and recover.
So as far as the T5577 side goes, no issues.

So the other tags is more for interest, as it would be good to know.
With these i am very sure they are NOT T5577 and given that pm3 cant get any data using the em4x05 commands.
If cloned with 1 blue cloner the other can update (same passwords set)
if cloned with the white cloner, then ONLY the white cloner can change. So as per the t5577 the white cloner knows the common passwords then puts its own in there.

the challenge with the dumps (from my side) is i can see all the t5577 commands as the are done first, but run out of buffer to get any good samples for what ever the other is (note that is with lf config d 2) any higher then d 2 and too many bit errors.

At the moment I have been looking at the different cloners and see what they state they can write to, e.g. T5577, em4305 and a 3rd one is the 5200 and 4th 8800 so now trying to find tech sheets on those.

while not a trace this is my decode of the trace from the blue cloner (and i can do the same for the white). All values match 100% with what I expect

   0 11 00 01010001001001000011011001001000 0 00000000000000000000000000000000 011
     10    01010001001001000011011001001000 0 01010001001001000011011001001000 111 
     10    01010001001001000011011001001000 0 01010001001001000011011001001000 111 
     10    01010001001001000011011001001000 0 00000000000101001000000001010000 000 
     10    01010001001001000011011001001000 0 11111111100000110110000000000010 001 
     11    01010001001001000011011001001000 0 11111111100000110110000000000010 001 
     10    01010001001001000011011001001000 0 01001100011011000010010011000100 010 
     11    01010001001001000011011001001000 0 01001100011011000010010011000100 010 
     11    01010001001001000011011001001000 0 01100000000000000000100000000000 011 
     10                                     0 00000000000101001000000001000000 000 
     10                                     0 11111111100000110110000000000010 001 
     10                                     0 01001100011011000010010011000100 010 


00110110 11111011 01101101 11111011 11011111 11111111 11011111 10111101
10111111 01101101 11111110 11011011 11111110 11111111 01110110 11110111
11111101 10111111 11111011 01111111 11111111 11101101 10110110 11011111
11111111 11011111 01101111

The block at the bottom i dont think is Manchester/ask the period widths are very close.
Note this is from the one that puts it into leading 0. you can see the first command removes the leading 0 than later
11 01010001001001000011011001001000 0 01100000000000000000100000000000 011
it re-enables it.

I am also trying to track down down some em4305 cards to play with.

One last thing. my white cloner can clone an proxcard ii HID id to a t5577 no issue, but it cant clone it to the blue fobs. So again supporting the findings that these are not T5577 cards.

Last edited by mwalker (2019-06-09 07:56:32)

anybody · 2019-06-09 11:10:25

@mwalker,
yes, t5577.. I don't understand the first command (73 bits).. according to datasheet, the first 2 bits - opcode.. need to think.
next commands -
pwd - 51243648, write commands for page 0, 1 ..
I don't see write commands for em4305.

Can you attach traces from your white Chinese cloner?

PS
perhaps
01 10 0 01010001001001000011011001001000 0 00000000000000000000000000000000 011

Last edited by anybody (2019-06-11 21:31:24)

mwalker · 2019-06-09 16:56:25

What these cloners seem to do is send out a all the different command sets for the cards they support (for writing) for the card you are trying to clone. Then they read back the "card" to see if it matches. So in this case its the t5577 commands then something else (run out of snoop buffer)
Its only the one blue cloner that does the leading 0 not both. Its not a bad idea, as if you use the "default" downlink protocol to talk to the card, the card wont see a valid command and just return to boot mode and spit out the ID data (as per the specs). Its its one of the reasons the password brute force does not work on some of these, you would need to try leading 0 protocol as well (I started to look at adding the leading zero read, but it was going to need a little more work, so have not got back to it as my objective was to recover the card.

If you look at the data sheet for the T5577 then in leading zero (and 1 of 4) there is
- a leading zero (0)
- 2 byte opcode (in this case 11 - write to page 1)
- then two zeros (00)
- then Password (if needed)
- then lock bit (0)
- then data
- then address (011 - 3).

It was this line that puts it back into leading zero mode (sent in normal fixed length downlink protocol)
11 01010001001001000011011001001000 0 01100000000000000000100000000000 011
From the data 0110 = 6 "If Option Key is 6 or 9, the front end options are activated;" so use these config values
Then bits 21 22 (10) Leading Zero Reference

In the data sheet have a look at
Table 5-1. Block 3 Page 1– Analog Front End Option Set-up (Bits 22 and 23 for the downlink protocol)
Figure 5-12. ATA5577 Command Formats Leading-zero-reference Protocol and 1-of-4-coding Protocol

I am 100% sure that is what its doing. i.e. when I use that cloner, i need to send a command using the same leading zero format to talk to the card. So what i did was wrote a T5577 leading zero write function for the proxmark arm code and put in the option in the client to call it. It works 100% (fyi if you are going to do this note that the timings are different as well).

The white cloner just adds more commands for the t5577, that reset "other cloner passwords" so even less of anything non t5577.

To recap where I am at.
If i use a known t5577 card as the "target" I can always recover via the proxmark.
- I can clone a HID with the blue that supports it and the white, and fully recover the card for use. i.e. I can get the password and read/write what every I want via the proxmark.
- If i write to the t5577 with the blue cloners (either HID or em4100 tag) then I can just clone a 2nd time (no wipe) via any cloner (2 blue and white), BUT if i write to the t5577 with the white cloner, then ONLY it can re-write - Until I remove the password (confirming the white knows the password for the blues but not the other way).

So, as I have already confirmed the white cloner does set a different password based on the ID (it is NOT fixed). i.e. to get the password I need to sniff a clone of the same id (or send an ID that i already know the password of) Note: I have partly worked out how it sets/generates the password (but thats a different topic, lets just say its not simply a xor with a fixed 32 bit word).

Back to the fobs I (we) cant recover.
Given that what ever I do to a know t5577 chip, i can recover and blank etc. So I am very happy I can recover when it is a t5577. So if I cant recover the other fob, then its NOT a t5577 (mine anyway).
If I clone an EM4100 tag to the unknown chip, it changes the ID, so we know they are not the fixed 4100 tags (I have some of these as well)
But I cant write a HID card to it via the cloners (which I can do via one blue that supports it and the white). But this Does work when its a t5577, so again confirming its NOT a t5577 and it does not seem to support a HID "config" or one that the cloners know how to do.

While I am not sure, I thought the em4305 could emulate a EM4100 and a HID (but not sure) but given that the 4x05 commands dont seem to do anything, then I tend to think they are not em4305 either (I would like to get some 4305 and run tests to confirm).
While I am having trouble finding some datasheets, i am thinking mine might be a 5200, which, from what I can find so far, is a chinese card for its own purpose. the most detail I have found online (for the same looking cloner I have) is this line under supported cards):

"CET5200: read/write, used to write EM ID"

I note the "used to write EM ID" and nothing else, which matches my findings.

So at this point (for me), This is more just trying to confirm this. For any real job I would recommend buying cards independent of a tool so you know 100% what they are, then you are working with a known.

What I would like to have is the ability to add an option to the snoop call to ignore x samples.
e.g. Sample 40,000 samples, then sample another 40,000 skipping 30,000 and again skipping 70,000 (until no more data).

marzipan · 2019-06-09 17:54:54

I have the same cloner from AliExpress, it writes the same password: 0x51243648

I also have five different 125kHz tags from AliExpress described variously as EM4305 T5577, TT5567, T5567, etc (often a combination). Some of these aren't initially recognised with Proxmark3 em 410x commands but they are all recognised if programmed as follows (omit the password part if not previously programmed by the cloner):

For EM4xxx default:

lf t55xx write b 0 d 00148040 p 51243648

then use em 410x commands.

Or program to t55xx default:

lf t55xx write b 0 d 00088040 p 51243648
lf t55xx wipe

Hope this helps

anybody · 2019-06-09 22:14:45

@mwalker, in your case, apparently, you are right. I have not seen this before.
Change the protocol after writing data and then before writing. In addition, password and option key..
)))

gjuny · 2019-06-09 23:13:01

@mwalker, thanks for the information. I have purchased what the vendor (different one) says is T5577 cards and fobs, different from the blue ones I already have. I'll have to wait until they arrive and investigate more. For now, I think I'm stuck regarding finding out what the blue ones are. Thanks again for the help!

mwalker · 2019-06-10 03:03:00

Found something interesting in gjuny second dump. After the long unknown write there were 3 short writes.
I believe this is decoded as follows. It matches 100% with the em4100 tag data for the Tag ID.

The interesting part is the start of the commands. Anyone have any ideas.
Happy to drop the first and last digit as they could be lead in and lead out.

0 10 0000001010     1111111 1000 0010 1100 0000 0000 0000 0000 0000 0
0 10 0000000101 0 0 0000000 1111 1111 1001 1011 0110 0000 0000 0110 1
		            F    F    9    B    6    0    0    6	   
0 10 0000000101 0 1 0000000 1101 0100 0011 1110 1001 0111 0000 1110 1
                            D    4    3    E    9    7    0    E 
	                   
Decoded tag ID : 3D00D51e2c

111111111
0011 0
1101 1
0000 0 
0000 0 
1101 1
0101 0 
0001 1
1110 1
0010 1
1100 0
0111 0

gjuny · 2019-06-10 15:19:36

@mwalker, here's the snoop for another write to the blue fob. By looking at the wave, it seems like it has the 3 short writes, but I have not yet learned how to analyze it.

This is what has been written to the blue fob:

proxmark3> lf search
NOTE: some demods output possible binary
  if it finds something that looks like a tag
False Positives ARE possible


Checking for known tags:

EM410x pattern found:

EM TAG ID      : 780096F475

Possible de-scramble patterns
Unique TAG ID  : 1E00692FAE
HoneyWell IdentKey {
DEZ 8          : 09892981
DEZ 10         : 0009892981
DEZ 5.5        : 00150.62581
DEZ 3.5A       : 120.62581
DEZ 3.5B       : 000.62581
DEZ 3.5C       : 150.62581
DEZ 14/IK2     : 00515405968501
DEZ 15/IK3     : 000128855912366
DEZ 20/ZK      : 01140000060902151014
}
Other          : 62581_150_09892981
Pattern Paxton : 2024485493 [0x78AB3275]
Pattern 1      : 6945564 [0x69FB1C]
Pattern Sebury : 62581 22 1504373  [0xF475 0x16 0x16F475]

Valid EM410x ID Found!

Thanks for helping out!

Last edited by gjuny (2019-06-11 02:11:36)

gjuny · 2019-06-11 02:01:27

Another update. I've found couple of T5577 cards (I'll be referring to them as "hotel card") from a previous hotel stay. Here is my list of actions:

1. I was able to clone a HID card using Proxxmark's LF HID command to the hotel card.
2. I've successfuly copied a 125kHz card I have to the hotel card with the white cloner. This card behaves like a EM4100.
3. After using the white cloner, I could no longer use LF T55XX commands to detect, wipe the T5577 or make a copy of the HID card. It began behaving just like the blue fob.
4. I ran lf t55xx write b 0 d 00088040 t. The command was found in the famous dangerousthings.com blog post about chinese cloners. I have omitted the password. The card began responding again to the Proxmark.
5. I was able to clone the HID card again to the hotel cards.

So I guess the blue fobs I own have some sort of writable unknown chip. It does not look like a T5577 nor a EM4305.

Learnings:
1. The white cloner seems to erase T55xx trace information. I've recovered the trace information to the hotel cards (I had looked into it before) and after using the white cloner a second time, the data was gone. I can't tell if test mode deletes all data
2. Writing in test mode does the trick to bring the card back to respond to LF T55XX commands, even without a password
3. Running LF T55XX DETECT to the hotel cards after copying with the white cloner returned Could not detect modulation automatically. Try setting it manually with 'lf t55xx config'. I ran the lf t55xx write b 0 d 00088040 t command without setting anything in the LF T55XX CONFIG and it still worked
4. The blue fob does not respond to test mode

Now I'm interested in finding out what the blue fobs are and whether I can use them for anything different than emulating an EM4100 card.

I hope this information helps somehow. Please let me know if there are any additional tests I can do with the blue fobs to try to find out what they are.

mwalker · 2019-06-11 03:13:34

@gjuny, well done you are learning

What you said seems to be inline with what I would expect.
The t55 detect will only work if the card responds correctly. When emulating a different tag (e.g. 4100) it may or may not respond, so it is expected that the detect wont work when in a different mode (i.e. it is meant to act like the emulated tag, not the t5577).
Yes the test mode is like a "don't care, just do" command. It will work as long as you can send it in the same downlink mode that the card is in. e.g. fixed length (default) is supported via the proxmark. (As I have posted, when in leading zero mode, you need to work a bit harder).
You could try some of the common passwords to see if any of those work or you can keep working on the snoop files to see if you can find them.

The lf t55 config, is about how the software will decode the data sent back, not how its sent to the card (that said some versions of the firmware let you set the pulse timings which will affect things, but different command).
If you read the data sheet for the t5577 it expects commands to be sent in its downlink mode (as setup in page 1 block 3), but it will respond back in the way its setup in the config block 0. So a write of block 0 and a detect can work (as long as the card is "rebooted" after the write command so it changes modes. (which the PM3 does by default as it drops the power to the field).

Now that you have things working and are starting to understand, read the data sheet and see what config you sent and what it means, it will really help you understand, rather then just sending blind commands.

e.g. If you want to see whats ON the card and not just re-use, the test command may not be ideal. So snooping that data can help. If you know the password you can then read with that.

Like you I am interested in what they are for no other reason then to know. They look the same as others I have but don't act the same. While I have no proof yet, my current theory is its a CET5200 which seems common in a lot of cloner write lists. I think they may be an EM4100 ID tag with a writeable ID and password. The commands I posted where found it your trace, so happy I found the em4100 tag data, but the command lengths don't match the 4x05 or the t5577 format, but same encoding/downlink protocol as the t5577.

Since the cloner can write to the t5577, I am interested in where it puts the t5577 commands.
What I have seen is they send out the write commands in all the formats they support for the "source id" tag type, then send a read/reset command/power cyclye and see if it sends the ID it just programmed. So the more card types it supports the more data it has to send and if that data goes past the end of the buffer from the snoop, we don't see it (at d 2 their is enough detail to read and see it, much higher we start to loose detail).

That said, try a lf snoop with a d 3 and t 64. we may just find it (i.e. setup the snoop lf config t 64 d 3 then lf snoop then with no card/fob, place the cloner to the pm3 as if the pm3 is the card/fob and write).

Note: I say no card as in a blind write (like I expect for these cloners) the card can respond and affect the signal as detected by the pm3.
But if the cloner process needed the feed back from the card, then it would stop if no response.

I ordered a few lm4305 to play with so will be interested to see how they respond.

What I do find interesting in ebay/amazon is a lot of card sellers call the cards T5577 EM4305 Since they are different cards, which one are they selling (as you don't select anything). I think they are just cards that should work with the sorts of things the cloners do, so are sold as interchangeable. So buyer beware.

Tom5ive · 2019-06-11 04:36:05

Both @gjuny . and @mwalker Awesome stuff!

I think you may be on to something with the CET5200 chips. I have this white cloner and some tags at home and will see what I can contribute to this pool of info.

Does anyone have links to some reference Doc about what testmode actually is and can do?

marshmellow · 2019-06-11 05:11:45

testmode documentation is few and far between, but have a look at http://www.proxmark.org/forum/viewtopic.php?id=4717
for what was discovered.

i do find it interesting that a few years after we worked on the testmode here it appears in cloners firmware...

Last edited by marshmellow (2019-06-11 05:18:39)

Tom5ive · 2019-06-11 06:01:16

Ah nice thanks for that - I'll have a read through!

I reckon there is a LOT that we still don't know about test mode that's for sure. It's basically looking more and more like a backdoor. If some nice person from Atmel with access to the right documentation reads this... You know what you need to do...

Frustrating that cloner firmware is copying R&D from PM community yes. Hmm on that thought, would it be useful to dump /decompile firmware from the cloners? Often thought to look into this.

Someone somewhere has to know more about this! Learning Chinese might help in the search for info lol.

gjuny · 2019-06-11 17:36:38

mwalker wrote:

@gjuny, well done you are learning

Thanks! My intent is to learn and then be able to do something useful with the tags.

mwalker wrote:

What I do find interesting in ebay/amazon is a lot of card sellers call the cards T5577 EM4305 Since they are different cards, which one are they selling (as you don't select anything). I think they are just cards that should work with the sorts of things the cloners do, so are sold as interchangeable. So buyer beware.

That's what I have also noticed while browsing on AliExpress. Most of them are listed as T5577 EM4305 and I've seen some listed as EM4305 EM5200. I've bought some that were listed as T5577 EM4305 (this and this) and one that is listed as T5577 only (this). I intent to use the dual ones for my parking garage access (125kHz HID) and building access (13.56MHz Mifare 1K). That way I don't have to carry two tags. Let's see how lucky I get when I receive the tags.

As for the CET5200, it's so frustrating how there's nothing in Google. I'll try to reach one of the AliExpress vendors to see if they have the datasheet for them.

I'll try the snoop later today and I'll post it here.

marshmellow · 2019-06-11 21:33:09

i confirmed the lf em 4x05protect command works in my fork, but you cannot change the protection for block 1

pre protect command through protect cmd:

Lock Address 14 | 00008002
Lock Address 15 | 00000000
proxmark3> lf em 4x05protect d 0
Writing Protect data 00000000
Protect Verified
proxmark3> lf em 4x05dump
 Got Address 00 | 00040072
 Got Address 01 | 3F8DAD59
 PWD Address 02 | cannot read
 Got Address 03 | 0000D5C3
 Got Address 04 | 0002005F
 Got Address 05 | FFFFFFFF
 Got Address 06 | 00000000
 Got Address 07 | 00000000
 Got Address 08 | 12345678
 Got Address 09 | 00000000
 Got Address 10 | 00000000
 Got Address 11 | 00000000
 Got Address 12 | 00000000
 Got Address 13 | 00000000
Lock Address 14 | 00000000
Lock Address 15 | 00008002

gjuny · 2019-06-12 00:57:47

marshmellow wrote:

i confirmed the lf em 4x05protect command works in my fork, but you cannot change the protection for block 1

pre protect command through protect cmd:

Lock Address 14 | 00008002
Lock Address 15 | 00000000
proxmark3> lf em 4x05protect d 0
Writing Protect data 00000000
Protect Verified
proxmark3> lf em 4x05dump
 Got Address 00 | 00040072
 Got Address 01 | 3F8DAD59
 PWD Address 02 | cannot read
 Got Address 03 | 0000D5C3
 Got Address 04 | 0002005F
 Got Address 05 | FFFFFFFF
 Got Address 06 | 00000000
 Got Address 07 | 00000000
 Got Address 08 | 12345678
 Got Address 09 | 00000000
 Got Address 10 | 00000000
 Got Address 11 | 00000000
 Got Address 12 | 00000000
 Got Address 13 | 00000000
Lock Address 14 | 00000000
Lock Address 15 | 00008002

@marshmellow, I think you meant this post http://www.proxmark.org/forum/viewtopic.php?id=6542

gjuny · 2019-06-12 01:09:30

@mwalker, here is the link for the snoop as per configuration you suggested and without any cards to be recorded: WhiteCloner_001

Thanks!

mwalker · 2019-06-12 01:56:49

marshmellow wrote:

i confirmed the lf em 4x05protect command works in my fork, but you cannot change the protection for block 1
pre protect command through protect cmd:
Lock Address 14 | 00008002
Lock Address 15 | 00000000
proxmark3> lf em 4x05protect d 0
Writing Protect data 00000000
Protect Verified
proxmark3> lf em 4x05dump
 Got Address 00 | 00040072
 Got Address 01 | 3F8DAD59
  .......
 Got Address 12 | 00000000
 Got Address 13 | 00000000
Lock Address 14 | 00000000
Lock Address 15 | 00008002

While I accept it accepted the command as the protection active block changed from 14 to 15.

From the tech sheet.

When the Write Login bit is set to logic 1, modification of
EEPROM content is protected. Writing any word using
Write Word command or changing protection using
Protect command, can be done upon successful
execution of a login command.
Note: Independent of write login conf

ie: ... changing protection using Protect command, can be done upon successful execution of a login command.
I read that as in you would need the login if it was protected. So given it looks like its protected to some extent, I wonder if you need to send the login first ? Note: for the login to stay active, the chip will need to stay energized between the login and write/protect commands, as it will reset as soon as it looses power.

marshmellow · 2019-06-12 02:45:40

That is why the command accepts a password parameter. I did not use it in the example shown I admit.

Proxmark3 community

Announcement

#1 2019-02-06 13:32:02

Possible T55xx Tag & Chinese Cloner

#2 2019-02-07 12:53:55

Re: Possible T55xx Tag & Chinese Cloner

#3 2019-02-07 18:26:48

Re: Possible T55xx Tag & Chinese Cloner

#4 2019-02-07 21:11:09

Re: Possible T55xx Tag & Chinese Cloner

#5 2019-02-11 21:32:41

Re: Possible T55xx Tag & Chinese Cloner

#6 2019-02-12 13:17:58

Re: Possible T55xx Tag & Chinese Cloner

#7 2019-02-12 19:16:38

Re: Possible T55xx Tag & Chinese Cloner

#8 2019-02-13 06:40:42

Re: Possible T55xx Tag & Chinese Cloner

#9 2019-02-13 16:14:50

Re: Possible T55xx Tag & Chinese Cloner

#10 2019-02-18 20:58:28

Re: Possible T55xx Tag & Chinese Cloner

#11 2019-02-19 16:50:49

Re: Possible T55xx Tag & Chinese Cloner

#12 2019-02-19 19:02:18

Re: Possible T55xx Tag & Chinese Cloner

#13 2019-02-19 22:35:20

Re: Possible T55xx Tag & Chinese Cloner

#14 2019-02-20 11:54:35

Re: Possible T55xx Tag & Chinese Cloner

#15 2019-02-21 16:03:16

Re: Possible T55xx Tag & Chinese Cloner

#16 2019-02-22 07:44:14

Re: Possible T55xx Tag & Chinese Cloner

#17 2019-03-05 23:18:08

Re: Possible T55xx Tag & Chinese Cloner

#18 2019-06-05 13:05:38

Re: Possible T55xx Tag & Chinese Cloner

#19 2019-06-05 22:08:21

Re: Possible T55xx Tag & Chinese Cloner

#20 2019-06-07 13:52:05

Re: Possible T55xx Tag & Chinese Cloner

#21 2019-06-07 19:24:01

Re: Possible T55xx Tag & Chinese Cloner

#22 2019-06-08 00:04:51

Re: Possible T55xx Tag & Chinese Cloner

#23 2019-06-08 01:54:07

Re: Possible T55xx Tag & Chinese Cloner

#24 2019-06-08 05:33:16

Re: Possible T55xx Tag & Chinese Cloner

#25 2019-06-08 10:34:29

Re: Possible T55xx Tag & Chinese Cloner

#26 2019-06-08 14:06:13

Re: Possible T55xx Tag & Chinese Cloner

#27 2019-06-08 15:19:26

Re: Possible T55xx Tag & Chinese Cloner

#28 2019-06-08 15:24:45

Re: Possible T55xx Tag & Chinese Cloner

#29 2019-06-08 18:27:04

Re: Possible T55xx Tag & Chinese Cloner

#30 2019-06-09 02:39:05

Re: Possible T55xx Tag & Chinese Cloner

#31 2019-06-09 07:11:34

Re: Possible T55xx Tag & Chinese Cloner

#32 2019-06-09 07:51:12

Re: Possible T55xx Tag & Chinese Cloner

#33 2019-06-09 11:10:25

Re: Possible T55xx Tag & Chinese Cloner

#34 2019-06-09 16:56:25

Re: Possible T55xx Tag & Chinese Cloner

#35 2019-06-09 17:54:54

Re: Possible T55xx Tag & Chinese Cloner

#36 2019-06-09 22:14:45

Re: Possible T55xx Tag & Chinese Cloner

#37 2019-06-09 23:13:01

Re: Possible T55xx Tag & Chinese Cloner

#38 2019-06-10 03:03:00

Re: Possible T55xx Tag & Chinese Cloner

#39 2019-06-10 15:19:36

Re: Possible T55xx Tag & Chinese Cloner