Manchester with delay between blocks

Turnkey · 2016-02-03 01:58:18

Hello PM forums,

I'm stuck trying to duplicate an unknown LF tag to a T5577 which seems to have a delay at the end of the first block stretching the wave out. So far I've been able to decode the original tag data as being manchester encoded data of 2 blocks

Decoded data was (With an error reading 77, the delay) :

0000000000000000
0000000000000000
0000000000000011
1000000000101011
1010101101017700
0100001101000000
0000000000000000
0000000000000000
0000000000000000
0000000000000000
0000000000000000
0111000000000101
0111010101101017
7000100001101000
0000000000000000
0000000000000000
0000000000000000
0000000000000000
0000000000000000
0000111000000000

This is the closest I've been able to get it :
Block 0 = 00000000000010001000000001000000 = 00088040
Block 1 = 11100000000010101110101011010110 = E00AEAD6
block 2 = 00001000011010000000000000000000 = 08680000

I cannot figure out how to make the final bit between block 1 and 2 to be twice as long though. I've highlighted this part below in red. Any help would be greatly appreciated. The T5577 documention mentions Demodulation Delay but I can't seem to get this feature working.

Original Wave :

Cloned Wave on T5577 :

Simulated Wave from lf sim (Works to open the door) :

Prox/RFID mark3 RFID instrument
bootrom: /-suspect 2015-11-19 10:08:02
os: /-suspect 2015-11-19 10:08:09
LF FPGA image built for 2s30vq100 on 2015/03/06 at 07:38:04
HF FPGA image built for 2s30vq100 on 2015/11/ 2 at 9: 8: 8
uC: AT91SAM7S512 Rev B

marshmellow · 2016-02-03 02:02:37

Research the sequence terminator config setting in the ata55x7 chips.

Turnkey · 2016-02-03 02:02:58

Thanks marshmellow!

Turnkey · 2016-02-03 05:26:40

Update : RFID 100% cloned thanks to help above from Marshmellow regarding Sequence Terminators.

The process I took was as follows. The 77 reading in the wasn't actually part of the datastream that had been misread as I though, it was the Sequence Terminator that is placed before block 0 on every sequence (5.11.3 http://www.atmel.com/images/atmel-9187-rfid-ata5577c_datasheet.pdf )

First, perform a 'lf read 10000' or 'lf search' to get the data from your card.
Demodulate it to get out the binary representation from the waveform the card generates. Having inspected the graph of the wave perviously I knew it was using amplitude shift keying modulation, with a clock rate of 32

proxmark3> lf read 10000
#db# LF Sampling config:                  
#db#   [q] divisor:           95                  
#db#   [b] bps:               8                  
#db#   [d] decimation:        1                  
#db#   [a] averaging:         1                  
#db#   [t] trigger threshold: 0                  
#db# Done, saved 40000 out of 40000 seen samples at 8 bits/sample                 
#db# buffer samples: ff ff ff ff ff ff ff ff ...                 
proxmark3> 

proxmark3> data detectclock a
Auto-detected clock rate: 32, Best Starting Position: 0          
proxmark3> 

proxmark3> data rawdemod  am  32      
Using Clock:32, Invert:0, Bits Found:494          
# Errors during Demoding (shown as 7 in bit stream): 4          
ASK/Manchester - Clock: 32 - Decoded bitstream:          
0000000000000000
0001110000000001
0101110101011010
1770001000011010
0000000000000000
0000000000000000
0000000000000000
0000000000000000
0000000000000000
0000001110000000
0010101110101011
0101770001000011
0100000000000000
0000000000000000
0000000000000000
0000000000000000
0000000000000000
0000000001110000
0000010101110101
0110101770001000
0110100000000000
0000000000000000
0000000000000000
0000000000000000
0000000000000000
0000000000001110
0000000010101110
1010110101770001
0000110100000000
0000000000000000
00000000000000          
proxmark3>

The datastream was then as follows when split up by the delimiter 77

0000000000000000000000000000000000000000000000000000000000011100000000010101110101011010177
00010000110100000000000000000000000000000000000000000000000000000000000000000000000000000000000000011100000000010101110101011010177
00010000110100000000000000000000000000000000000000000000000000000000000000000000000000000000000000011100000000010101110101011010177
00010000110100000000000000000000000000000000000000000000000000000000000000000000000000000000000000011100000000010101110101011010177000100001101
0000000000000000

Obviously this is a repeating pattern above. So I split out a single line of it :

00010000110100000000000000000000000000000000000000000000000000000000000000000000000000000000000000011100000000010101110101011010177

This was then broken up into 32 bit chucks so I can write those to the tag in pages. There was a leftover 1 before the 77, so I figured this extra bit was a false bit caused by the sequence terminators being read (the 77 is the sequence terminator). I converted the binary to hexadecimal at http://www.binaryhexconverter.com/binary-to-hex-converter

00010000110100000000000000000000 = block 1 = 10D00000
00000000000000000000000000000000 = block 2 = 00000000
00000000000000000000000000000000 = block 3 = 00000000
00011100000000010101110101011010 = block 4 = 1C015D5A

I updated the config lines for block 0 to run basic mode, Manchester encoding, output pages 1-4 and include the sequence terminator (See page 9 in PDF above)

00000000000010001000000010001000 = block 0 = 00088088

The codes were then written to the T5577 Card, written twice just incase.

lf t55xx write b 0 d 00088088
lf t55xx write b 1 d 10D00000
lf t55xx write b 2 d 00000000
lf t55xx write b 3 d 00000000
lf t55xx write b 4 d 1C015D5A

I then did a 'lf investigate' on the new cloned T5577 card and investigated the plot in the waveform viewer (Opened using 'data plot'). Comparing the cloned waveform with the original in photoshop we have an exact match. Testing the cloned card on the reader and we have a successful read. Boom!

marshmellow · 2016-02-03 05:37:26

Well done. You have used the tools well.

marshmellow · 2016-02-03 05:39:59

Out of curiosity, does the tag have a printed number on it and do you know what reader/system it belongs to?

Turnkey · 2016-02-03 05:46:51

Unfortunately nothing on the tag itself. It's a small grey generic keyfob. I'll check the reader at the next opportunity but I don't recall it having any branding either.

Turnkey · 2016-02-03 09:46:28

I had a closer look at the reader. It is branded "Presco" from www.presco.com.au

marshmellow · 2016-02-13 05:41:03

Thanks for the info / follow up.

iceman · 2016-02-13 09:50:56

On the company website, there is a downloadable excel sheet, how to convert between Company printed number and Wiegand.

SiteCode http://pastebin.com/DSX9YsYk
UserCode http://pastebin.com/1MrEbMdm

Someone who likes excel formulas can give it a go..

iceman · 2016-02-13 20:13:48

I can now calc Presco printed number into wiegand,

Almost done with a presco clone command too..

pm3 --> lf pres re
Number: 123456789 --> Sitecode 30 | usercode 8665 <-- looking for.
Calc:  SiteCode 30 | UserCode 8665

iceman · 2016-02-13 20:19:12

Now I'm missing wiegand to raw data... Like adding the parity bits.

Been thinking if there is a presco demod needed too, looking at your blocks that you used to clone, the 0x10D in block 1, looks like a start pattern.

Last edited by iceman (2016-02-13 21:00:06)

marshmellow · 2016-02-15 04:12:33

unfortunately without a printed number and/or the readout directly from the reader/access control system, it will be difficult to know for sure how the raw data translates to the sitecode/usercode information.

however, I have a theory.

the spreadsheet formulas appear to just convert a number to base 10 from base 12.
do that to base 16 and you possibly have the raw data (excluding the preamble and leading zeros)
123456789 --> 1E8021D9 which is remarkably similar to 1C015D5A...

coincidence? cannot be sure without more data.

iceman · 2016-02-15 08:44:37

But 1E8021D9 is without parities..
and 1C015D5A has parities

marshmellow · 2016-02-15 13:37:19

Says what?

iceman · 2016-02-15 13:44:15

The xls converted 123456789 -> SC:30 UC: 8665, -> 1E8021D9 Is the hexnumber wiegand with parities? and how did you get the hexnumber?

marshmellow · 2016-02-15 13:45:29

Who says the raw data should have parities.

marshmellow · 2016-02-15 14:08:40

1E = sc:30
21D9 = uc:8665
80 = ?

The 1E8021D9 is what you get converting the number from their calc to hex. (Without the division or modulation operations which breaks down their calc to the different parts)

iceman · 2016-02-15 14:09:41

if it is a wiegand raw data, it should have wiegand parities no?

marshmellow · 2016-02-15 14:13:16

Not always. Readers can spit out wiegand from a mifare uid... And some wiegand formats don't have parities.

Now the 80 might be a checksum, but we don't have enough info. And I kinda doubt it...

iceman · 2016-02-15 14:15:13

I've asked OP about trace and printed numbers, lets see if OP can answer or give access to trace.

marshmellow · 2016-02-15 14:17:03

He said earlier that there were no printed numbers on his tag. And his demod is accurate, not sure what more a trace will tell.

iceman · 2016-02-15 14:23:03

if maybe we get lucky with the printed number, so we can see the raw data vs the outcome from the presco-num -> sc and uc.

if not, well, a trace from more the one tag is always nice to have. Just to see some bytes is repeating.

marshmellow · 2016-02-15 15:38:06

agreed, a Printed ID or additional tags would be helpful in figuring out the data format.

iceman · 2016-02-15 15:51:53

Maybe 0xFFFF has some tags from this system. He is based in Aussie no?

0xFFFF · 2016-02-16 09:23:30

I have tags/cards somewhere but I couldn't find them among all of the other tag types I have in storage.
I also have NIDAC / Presco readers that I have disassembled...
Plastics (front / back)
Plastics (inside front / back)
PCB top layer
PCB bottom layer

Any hints on what physical form factor the cards are? I think they were a clam shell type from memory.

Datasheet for the RFID IC

marshmellow · 2016-02-16 15:43:56

looks like mainly clamshells and keyfobs: http://www.presco.com.au/#!presco-access-cards/c1q3

marshmellow · 2016-02-16 20:09:35

I have a LF ASK Sequence terminator detection routine i'm now testing in my fork. so far it seems to work in my limited testing.

the routine attempts to auto detect the clock by measuring the shortest low to low wave, then attempts to detect the ST for that clock. if it finds two ST's it will drop all samples prior to and including the first ST - and then loop through and remove the rest of the ST's in the trace. it then can be demodulated with the standard ASK routine, with the benefit that the demoded data should start with the first bit after the ST.

this detection will likely only work on good strong reads with a strong antenna.

in my fork - `lf search u` will take advantage of the new routine. or you can run `data rawdemod am s`
also I started adding it to the lf t5xx detect - so it might work there as well...

it will need a bit more testing before it goes into the main GitHub repo however.

Last edited by marshmellow (2016-02-16 20:12:00)

iceman · 2016-02-16 20:13:07

The STT for T55x7 tags, can't it be used for all possible modulation settings?

marshmellow · 2016-02-16 20:18:15

the datasheet suggests that only ask and fsk. (my detection routine is only good for ASK currently...)

iceman · 2016-02-16 20:25:31

well, perfect, less things to worry about then.

marshmellow · 2016-02-16 20:33:11

actually detecting it on FSK should be very easy no field for a full clock cycle would be hard to miss on fsk.... but I've never seen one, so i'm not sure if it is worth the code.

iceman · 2016-12-15 00:17:30

I've added @marshmellows STT into my Presco - commands. Not quite sure if all demod of dataformat is right. Would be nice to test it against valid reader / valid cards.

Proxmark3 community

Announcement

#1 2016-02-03 01:58:18

Manchester with delay between blocks

#2 2016-02-03 02:02:37

Re: Manchester with delay between blocks

#3 2016-02-03 02:02:58

Re: Manchester with delay between blocks

#4 2016-02-03 05:26:40

Re: Manchester with delay between blocks

#5 2016-02-03 05:37:26

Re: Manchester with delay between blocks

#6 2016-02-03 05:39:59

Re: Manchester with delay between blocks

#7 2016-02-03 05:46:51

Re: Manchester with delay between blocks

#8 2016-02-03 09:46:28

Re: Manchester with delay between blocks

#9 2016-02-13 05:41:03

Re: Manchester with delay between blocks

#10 2016-02-13 09:50:56

Re: Manchester with delay between blocks

#11 2016-02-13 20:13:48

Re: Manchester with delay between blocks

#12 2016-02-13 20:19:12

Re: Manchester with delay between blocks

#13 2016-02-15 04:12:33

Re: Manchester with delay between blocks

#14 2016-02-15 08:44:37

Re: Manchester with delay between blocks

#15 2016-02-15 13:37:19

Re: Manchester with delay between blocks

#16 2016-02-15 13:44:15

Re: Manchester with delay between blocks

#17 2016-02-15 13:45:29

Re: Manchester with delay between blocks

#18 2016-02-15 14:08:40

Re: Manchester with delay between blocks

#19 2016-02-15 14:09:41

Re: Manchester with delay between blocks

#20 2016-02-15 14:13:16

Re: Manchester with delay between blocks

#21 2016-02-15 14:15:13

Re: Manchester with delay between blocks

#22 2016-02-15 14:17:03

Re: Manchester with delay between blocks

#23 2016-02-15 14:23:03

Re: Manchester with delay between blocks

#24 2016-02-15 15:38:06

Re: Manchester with delay between blocks

#25 2016-02-15 15:51:53

Re: Manchester with delay between blocks

#26 2016-02-16 09:23:30

Re: Manchester with delay between blocks

#27 2016-02-16 15:43:56

Re: Manchester with delay between blocks

#28 2016-02-16 20:09:35

Re: Manchester with delay between blocks

#29 2016-02-16 20:13:07

Re: Manchester with delay between blocks

#30 2016-02-16 20:18:15

Re: Manchester with delay between blocks

#31 2016-02-16 20:25:31

Re: Manchester with delay between blocks

#32 2016-02-16 20:33:11

Re: Manchester with delay between blocks

#33 2016-12-15 00:17:30

Re: Manchester with delay between blocks

Board footer