Decode LF tag NORALSY (KCP3000)

rbubba1911 · 2015-07-29 12:52:03

Good morning Proxmark users ,

I'm the proud owner of a NORALSY (KCP3000) 125khz tag, and I need your help to decode the binary stream in order to clone this tag on t55x7.

more info about the tag :
KCP3000 125 KHZ
ID engraved on tag : 6811501
Picture here : http://www.interactivesysteme.fr/upload/Image/NORALSY/NORALSY%20KCP3000.jpg

pm3 version up to date (master/v2.2.0-44-g987dfb6)

What I do :

>lf read
>data sample
>data autocorr

> data detectclock a
Auto-detected clock rate: 64, Best Starting Position: 27

>data rawdemod ar 0
1011000000100001
0100111111110110
1000000100000010
0000000101010000
0001100001110000
0000000000001111
1011101100000010
0001010011111111
0110100000010000
0010000000010101
0000000110000111
0000000000000000
1111101110110000
0010000101001111
1111011010000001
0000001000000001
0101000000011000
0111000000000000
0000111110111011
(...)

I can see a pattern : 1111111101101000000100000010000000010101000000011000011100000000000000001111101110110000001000010100

what I decode as follow :

11111111 (header)
0110 : 6
1000 : 8
0001 : 1
0000 : 0 (?)
0010 : 2 (?)
0000 : 0 (?)
0001 : 1
0101 : 5
0000 : 0
0001 : 1
1000 : 8
0111 : 7
0000 : 0
0000 : etc...

seem to be confirmed by :
>data printdemod x
DemodBuffer: ...FF6810201501870000FBB0214...

As you can see I almost got my ID number , but I dont know what to do with extra byte (0,2,0).

My question :

I am on the right way ? (I don't believe in coincidence !!)

I'm decoding the binary stream correctly ?
What to do with the extra byte ?
What part is mandatory to clone it on t55x7 ?
Where I can get the signal information to program the T55x7's block 0 ?

I wish you a good day and wait for your reply dudes !

Best regards from Paris

Rbubba

asper · 2015-07-29 13:37:00

You got it. It is a simpkle EM4100 tag. Probably the "missing" values are a manufacturer choice (they decided not to consider them in the engraved label).
When you will clone it you need to use all the ID bitstream (including "missing" values).

Last edited by asper (2015-07-29 13:39:32)

marshmellow · 2015-07-29 13:46:05

you might have the correct demod and yes to clone you use the entire bitstream that repeats (pattern)
We don't know enough to guess the next number though. Also it is NOT a "simple EM4100" tag as the header is wrong and there are no parities..

Last edited by marshmellow (2015-07-29 13:51:19)

marshmellow · 2015-07-29 13:53:06

Looking closer at the bit stream something is wrong. Can you post an image of the 'data plot' after the lf read/ data samples?

I'm not so sure you are using the correct demod after all.

marshmellow · 2015-07-29 13:54:59

Also if you could post the results of a 'data rawdemod nr'

iceman · 2015-07-29 14:35:04

He could try the "Lf search" aswell..

rbubba1911 · 2015-07-29 14:37:07

first at all, thank you asper,

I appreciate your confirmation, I read almost all your post and you already have answer to so many of my questions !!

so, according to your post (http://www.proxmark.org/forum/viewtopic.php?pid=8544#p8544)
I have to follow this picture (http://i.imgur.com/6FsHMfA.png) to program the T55x7.

Unfortunately your(magic) excel file (T55x7 and EM4100 TOOL) is no more available, you'll be very kind to send me a copy , if you can, so I can forge my T55x7 blocks.

Have a nice day

Rbubba

rbubba1911 · 2015-07-29 14:44:47

marshmellow wrote:

Looking closer at the bit stream something is wrong. Can you post an image of the 'data plot' after the lf read/ data samples?
I'm not so sure you are using the correct demod after all.

Hi, glad to see you (I'm a lucky man)

here is the info you ask:

lf read
#db# LF Sampling config:
#db# [q] divisor: 95
#db# bps: 8
#db# [d] decimation: 1
#db# [a] averaging: 1
#db# [t] trigger threshold: 0
#db# DownloadFPGA(len: 42096)
#db# Done, saved 40000 out of 40000 seen samples at 8 bits/sample
#db# buffer samples: b1 9e 94 9f 90 92 95 63 ...
proxmark3> data sample 40000

http://imgur.com/jp7pLEl

rbubba1911 · 2015-07-29 14:45:55

marshmellow wrote:

Also if you could post the results of a 'data rawdemod nr'

proxmark3> data rawdemod nr
Tried NRZ Demod using Clock: 16 - invert: 0 - Bits Found: 1000
NRZ demoded bitstream:
0101011001100101
1010101010101010
0110100110010101
0101011001010101
0101100101010101
0101011001100110
0101010101010110
1001010101101010
0101010101010101
0101010101010101
1011101110011010
1001101001010101
0101100101010110
0110010110101010
1010101001101001
1001010101010110
0101010101011001
0101010101010110
0110011001010101
0101011010010101
0110101001010101
0101010101010101
0101010110111011
1001101010011010
0101010101011001
0101011001100101
1010101010101010
0110100110010101
0101011001010101
0101100101010101
0101011001100110
0101010101010110

proxmark3> data printdemod x
DemodBuffer: 5665AAAA69955655595556665556956A55555555BB9A9A55595665AAAA69955655595556665556956A55555555BB9A9A55595665AAAA69955655595556665556956A55555555BB9A9A55595665AAAA69955655595556665556956A55555555BB9A9A55595665AAAA69955655595556665556956A55555555BB9A9A5559

rbubba1911 · 2015-07-29 15:02:06

furthermore, I don't understand 2 point.

- by design the T55x7 seem to send a minimal header of 9 bit (1)
mine is 8 bit (1) ?

- by design the T55x7 can send a max of 10 digit (40bit) data
my binary stream (without header) is 6810201501870000FBB0214

a way to big to fit into 40 bit no ?

note that the ID key "6810201501" fit into 40bit, but what to do with the remaining data "870000FBB0214" ?

some mysteries remain ....

iceman · 2015-07-29 15:23:30

The t55x7, 6 blocks a 4bytes equals 24bytes. 24*8 = 192bits. ( plus one block which is the password block)

Your sample is 12bytes. Plenty of space left.

rbubba1911 · 2015-07-29 15:33:09

iceman wrote:

The t55x7, 6 blocks a 4bytes equals 24bytes. 24*8 = 192bits. ( plus one block which is the password block)
Your sample is 12bytes. Plenty of space left.

Hi,

I don't know very well the t55x7 chip, I thought there are only 3 block of 4 byte.

Thank's to you to have answered my question !

Best regards

marshmellow · 2015-07-29 15:34:02

ok. your signal is a little weak and ugly (interference?). try (on your samples [after lf read/data samples]) a 'data dirthreshold 5 -5' and then a 'data rawdemod am' and post your results.

i think this will get the correct rf/32 ask/manchester demod for your tag's 96 bits (3 blocks) .

Last edited by marshmellow (2015-07-29 15:36:08)

marshmellow · 2015-07-29 15:35:02

a 'lf search u' may get you the same results...

rbubba1911 · 2015-07-29 15:58:31

marshmellow wrote:

ok. your signal is a little weak and ugly (interference?). try (on your samples [after lf read/data samples]) a 'data dirthreshold 5 -5' and then a 'data rawdemod am' and post your results.
i think this will get the correct rf/32 ask/manchester demod for your tag's 96 bits (3 blocks) .

proxmark3> lf read
#db# LF Sampling config:
#db# [q] divisor: 95
#db# bps: 8
#db# [d] decimation: 1
#db# [a] averaging: 1
#db# [t] trigger threshold: 0
#db# DownloadFPGA(len: 42096)
#db# Done, saved 40000 out of 40000 seen samples at 8 bits/sample
#db# buffer samples: dd c1 a7 96 9a 95 92 93 ...
proxmark3> data sample
Reading 39999 bytes from device memory

Data fetched
Samples @ 8 bits/smpl, decimation 1:1
proxmark3> data plot
proxmark3> data dirthreshold 5 -5
Applying Up Threshold: 5, Down Threshold: -5
proxmark3> data rawdemod am

Using Clock:32, Invert:0, Bits Found:513
# Errors during Demoding (shown as 7 in bit stream): 44
ASK/Manchester - Clock: 32 - Decoded bitstream:
0010000101001111
1111011010000001
0000001000000001
0101000000011000
0111000000000000
0000177771110110
0000010000101001
1111111011010000
0010000001000000
0010101000000011
0000111000000000
0000000177771110
1100000010000101
0011111111011010
0000010000001000
0000010101000000
0110000111000000
0000000000177771
1101100000010000
1010011111111011
0100000010000001
0000000010101000
0000110000111000
0000000000000177
7711101100000010
0001010011111111
0110100000010000
0010000000010101
0000000110000111
0000000000000000
1777711101100000
0100001010011111

proxmark3> data printdemod x
DemodBuffer: 214FF68102015018700003360429FED020402A030E00016EC0853FDA0408054061C00096D810A7FB408100A80C3800015B0214FF68102015018700003360429F
proxmark3>

the data plot windows : http://imgur.com/KE0ilzS

btw, lf search return :
....
Possible Auto Correlation of 12800 repeating samples

Using Clock:64, Invert:0, Bits Found:469
ASK/Manchester - Clock: 64 - Decoded bitstream:
0110000001000000
0000100100000000
1111110001000011
1101100000010000
0000001001000000
0011111100010000
1111011000000100
0000000010010000
0000111111000100
0011110110000001
0000000000100100
0000001111110001
0000111101100000
0100000000001001
0000000011111100
0100001111011000
0001000000000010
0100000000111111
0001000011110110
0000010000000000
1001000000001111
1100010000111101
1000000100000000
0010010000000011
1111000100001111
0110000001000000
0000100100000000
1111110001000011
1101100000010000
00000

Unknown ASK Modulated and Manchester encoded Tag Found!

if it does not look right it could instead be ASK/Biphase - try 'data rawdemod ab'
proxmark3> data printdemod x
DemodBuffer: 60400900FC43D81002403F10F60400900FC43D81002403F10F60400900FC43D81002403F10F60400900FC43D81002403F10F60400900FC43D8100

I have to "rawdemod ar 0" to get the hex value containing the ID key

Thanks

marshmellow · 2015-07-29 16:20:10

ok the demod after the dirthreshold almost got it. it shows your tag utilizes the Sequence Terminator (which interferes with the standard pm3 demod) ( i haven't gotten to that yet...)

if you could zoom out a bit so i can see more of the plot (and/or stretch the window larger) and then post an image it would help.

the demod after the dirthreshold is missing only 1 bit (either at the end or beginning) it got confused with the Sequence Terminator and lost the bit there somewhere.

so if i could see the waves around the sequence terminator i could fill in that bit for you.

but missing just 1 bit this is most of your bitstream:
11101100000010000101001111111101101000000100000010000000010101000000011000011100000000000000001

rbubba1911 · 2015-07-29 16:40:57

marshmellow wrote:

ok the demod after the dirthreshold almost got it. it shows your tag utilizes the Sequence Terminator (which interferes with the standard pm3 demod) ( i haven't gotten to that yet...)
if you could zoom out a bit so i can see more of the plot (and/or stretch the window larger) and then post an image it would help.
the demod after the dirthreshold is missing only 1 bit (either at the end or beginning) it got confused with the Sequence Terminator and lost the bit there somewhere.
so if i could see the waves around the sequence terminator i could fill in that bit for you.
but missing just 1 bit this is most of your bitstream:
11101100000010000101001111111101101000000100000010000000010101000000011000011100000000000000001

Hi,

I do whatever you want !!

but note that we have both found almost the same bistream.

taken from my first post (about manual decoding)
1111111101101000000100000010000000010101000000011000011100000000000000001111101110110000001000010100

it's very close to your analysis, except we doesn't have the same start point

here is a bigger picture zoomed/streched : http://i.imgur.com/q3R9DYE.png
here is the data saved trace (before dirthreshold) : http://www.filedropper.com/noralsy-trace

thanks for your help

marshmellow · 2015-07-29 17:08:49

correct bitstream:
101110110000001000010100111111110110100000010000001000000001010100000001100001110000000000000000

the sequence terminator is a manchester 1 (rf/16 high, rf/16 low) then rf/48 high, rf/16 low then rf/32 high. find and remove that and you have your demod.

so your tag is RF/32 ASK/Manchester with 96 bits and the sequence terminator of a T55x7 turned on.

Thanks for Sharing! it is always interesting to see new tags.

Last edited by marshmellow (2015-07-29 17:09:36)

rbubba1911 · 2015-07-29 17:39:17

marshmellow wrote:

correct bitstream:
101110110000001000010100111111110110100000010000001000000001010100000001100001110000000000000000
the sequence terminator is a manchester 1 (rf/16 high, rf/16 low) then rf/48 high, rf/16 low then rf/32 high. find and remove that and you have your demod.
so your tag is RF/32 ASK/Manchester with 96 bits and the sequence terminator of a T55x7 turned on.
Thanks for Sharing! it is always interesting to see new tags.

Thank to you for teaching me how to understand how to decode bitstream.

this part is still obscure to me :
(I need more practise in decoding)

"the sequence terminator is a manchester 1 (rf/16 high, rf/16 low) then rf/48 high, rf/16 low then rf/32 high. find and remove that and you have your demod."

how do you find the sequence terminator, it is because it make decoding errors (777) on rawdemod am ??

finally, the right operation to decode Noralsy 125khz tag will be:

lf read
data sample
data dirthreshold 5 -5 (seem very important)
data rawdemod am
data printdemod x

correct ?

next step is to program my t55x7 (another nice trip !)

You have all my gratitude

marshmellow · 2015-07-29 17:57:46

i manually found the ST in the plot and figured out where the demod went wrong. you can use data ltrim <value> and data rtrim <value> to remove it from your samples leaving only the manchester bitstream. (or demod manually from the plot.)

i identified that there was a ST two ways. first your initial repeating binary wasn't a multiple of 32. and second on the demod after dirthreshold you had the same 4 errors (7s) repeating right around every 96 bits.

also the plot clearly showed you should have rf/32 manchester clock, however the default ask detected rf/64 (due to the ST), and NRZ detected rf/16 (as i would expect for a rf/32 manchester).

i saw the likely need (may not be necessary) for the dirthreshold due to the kinky waveform in your plot. lines should be smooth up and down not jagged edges (this is probably due to the smallness of the key fob coupled with an antenna not tuned for it). therefore the data samples needed to be cleaned. from your plot the values 5 and -5 seemed an appropriate middle ground to accurately clean them.

rf/1 = one sample in the graph window.

Last edited by marshmellow (2015-07-29 17:59:40)

rbubba1911 · 2015-07-29 18:18:25

ok,

it's a bit clear now, but is something I don't understand.
how you find the beginning of the bit stream

let's say :

lf read
data sample
data dirthreshold 5 -5
data rawdemod am 0

lead me to :

Using Clock:32, Invert:0, Bits Found:513
# Errors during Demoding (shown as 7 in bit stream): 10
ASK/Manchester - Clock: 32 - Decoded bitstream:
1011101100000010
0001010011111111
0110100000010000
0010000000010101
0000000110000111
0000000000000000
1701011101100000
0100001010011111
1110110100000010
0000010000000010
1010000000110000
1110000000000000
0001701011101100
0000100001010011
1111110110100000
0100000010000000
0101010000000110
0001110000000000
0000001701011101
1000000100001010
0111111110110100
0000100000010000
0000101010000000
1100001110000000
0000000001701011

if I take all bit between two '7s' I've got :
01011101100000010000101001111111101101000000100000010000000010101000000011000011100000000000000001

it is very near to what you have found but I've got extra bit (one 0 at the beginning, and one 1 at the end) , why ?

cruel world ...

marshmellow · 2015-07-29 19:13:14

As I said, the demod does not understand the sequence terminator. In your last case it interprets it as 170

Last edited by marshmellow (2015-07-29 19:13:58)

rbubba1911 · 2015-07-29 19:31:36

marshmellow wrote:

As I said, the demod does not understand the sequence terminator. In your last case it interprets it as 170

ok, so you follow bit per bit the am decoding (on the graph) , skip the error "ST" by hand,
and then re take de decoding bit per bit , on the right bit.

wow, impressive !

I understand much better your previous post :

i manually found the ST in the plot and figured out where the demod went wrong. you can use data ltrim <value> and data rtrim <value> to remove it from your samples leaving only the manchester bitstream. (or demod manually from the plot.)

I have to learn more on manual decoding from the plot and ltrim/rtrim usage.

I own you a beer !

good evening

asper · 2015-07-29 22:26:53

Marshmellow is right and I was wrong, it is not an EM4100 !
Marsh do you remembere other tags with 96bit ? I would like to search for it i n my datasheets.

Last edited by asper (2015-07-29 22:27:17)

marshmellow · 2015-07-29 23:18:17

They are using a t55x7 chip. The sequence terminator gives it away.

rbubba1911 · 2015-07-30 10:42:23

asper wrote:

Marshmellow is right and I was wrong, it is not an EM4100 !
.

No problemo !

I realize how difficult it could be to identify protocol/type of tag without any doc,
I suspect marshmellow , to be a droid with an expert eye to read raw signal like english !!

btw, I think I found the TS in the graph plot, but I dont know how to remove it, if one of you have some info about using rtim /ltrim function to eliminate the TS in a bit stream, it would help me a lot.

see you

rbubba1911 · 2015-07-30 14:47:30

Final words,

In order to read a bitstream correctly you have to identify the patern's beginning and end. So called Sequence Terminator

Thank to marshmellow to have found the ST that Noralsy use in this tag.

marshmellow wrote:

the sequence terminator is a manchester 1 (rf/16 high, rf/16 low) then rf/48 high, rf/16 low then rf/32 high. find and remove that and you have your demod.

Good to go !

Because this ST is not know by the pm3, it confuse the bit decoding engine (rawdemod am), here is how to decode it properly.

When you decode the trace using manchester, you see errors during demoding (shown as 7 in bit stream)

like this :

data rawdemod am
Using Clock:32, Invert:0, Bits Found:513
# Errors during Demoding (shown as 7 in bit stream): 5
ASK/Manchester - Clock: 32 - Decoded bitstream:
1011101100000010
0001010011111111
0110100000010000
0010000000010101
0000000110000111
0000000000000000
1701011101100000
0100001010011111
1110110100000010
0000010000000010
1010000000110000
111000000000...

Now you have to ltrim to the closest position possible of the decoding error (7)

data ltrim 3024 (cursor position just before the TS)

data rawdemod am
Using Clock:32, Invert:0, Bits Found:513
# Errors during Demoding (shown as 7 in bit stream): 6
ASK/Manchester - Clock: 32 - Decoded bitstream:
1701011101100000
0100001010011111
1110110100000010
0000010000000010
....

Now look carefully at the start of graph to identify the TS,

TS signal only

TS at the start of trace
Noralsy_TS_start.

data ltrim 152 (to cut only the TS)

data rawdemod am
Using Clock:32, Invert:0, Bits Found:513
# Errors during Demoding (shown as 7 in bit stream): 10
ASK/Manchester - Clock: 32 - Decoded bitstream:
1011101100000010
0001010011111111
0110100000010000
0010000000010101
0000000110000111
0000000000000000
1701011101100000
010000101

repeat the operation for le ending TS, the same way.

data rtrim 3216 (cursor position just after the TS)
data rawdemod am

Using Clock:32, Invert:0, Bits Found:98
# Errors during Demoding (shown as 7 in bit stream): 1
ASK/Manchester - Clock: 32 - Decoded bitstream:
1011101100000010
0001010011111111
0110100000010000
0010000000010101
0000000110000111
0000000000000000
170

Again, look carefully at the end of graph to identify the TS, and cut it.

TS at the end of trace

data rtrim 3077 (to cut only the TS)

data rawdemod am
Using Clock:32, Invert:0, Bits Found:96
ASK/Manchester - Clock: 32 - Decoded bitstream:
1011101100000010
0001010011111111
0110100000010000
0010000000010101
0000000110000111
0000000000000000

data print x
DemodBuffer: BB0214FF681020150187000

Congrats, you have successfully decoded a Noralsy tag !

Last edited by rbubba1911 (2015-07-30 17:34:50)

iceman · 2015-07-30 15:46:15

And now, the mapping of the data so we can sim/clone/verify a Noralsy tag.

rbubba1911 · 2015-07-30 15:48:40

iceman wrote:

And now, the mapping of the data so we can sim/clone/verify a Noralsy tag.

Yup !

Once I receive my t55x7 (ordered on ebay) I'll complete this post with the T55 programming

asper · 2015-07-30 16:06:20

marshmellow wrote:

They are using a t55x7 chip. The sequence terminator gives it away.

100% sure of that ? So it can be potentially reprogrammed...

Last edited by asper (2015-07-30 16:06:34)

rbubba1911 · 2015-07-30 18:02:17

asper wrote:

marshmellow wrote:
They are using a t55x7 chip. The sequence terminator gives it away.
100% sure of that ? So it can be potentially reprogrammed...

marshmellow think there is a t55x7 chip inside my Noralsy tag ?

sounds very interesting ! , how can i check this ?

iceman · 2015-07-30 20:49:55

run
"lf t55xx detect"
"lf t55xx info"

marshmellow · 2015-07-30 22:00:03

the detect likely won't work due to the Sequence Terminator.
but one might be able to manually config it

however, if they've locked it down it won't respond.

marshmellow · 2015-07-30 22:06:18

i'm not 100% sure it is a T55x7, but there are few tags that do that sequence terminator. (I'm not aware of ANY others actually, but it is possible there are other chips somewhere that can)

marshmellow · 2015-07-30 22:16:44

for the lf t55xx config, rbubba1911 could run:

lf t55xx config b 32 d ASK o 0
lf t55xx info

and if you get something like :

proxmark3> lf t55xx info

-- T55xx Configuration & Tag Information --------------------
-------------------------------------------------------------
 Safer key                 : 0
 reserved                  : 0
 Data bit rate             : 2 - RF/32
 eXtended mode             : No
 Modulation                : 8 - Manchester
 PSK clock frequency       : 0
 AOR - Answer on Request   : No
 OTP - One Time Pad        : No
 Max block                 : 3
 Password mode             : No
 Sequence Start Terminator : No
 Fast Write                : No
 Inverse data              : No
 POR-Delay                 : No
-------------------------------------------------------------
 Raw Data - Page 0
     Block 0  : 0x00088060  00000000000010001000000001100000
-------------------------------------------------------------

except your sequence terminator is on.. then we can confirm it is a t55x7 chip. if you don't get the above and it is all wrong then you could try a different offset (o 1 or o 2 or o 3) in the config. if it still doesn't look right the chip is probably password protected or not a t55x7

Last edited by marshmellow (2015-07-30 22:17:11)

marshmellow · 2015-07-30 22:27:42

On second look, the Sequence terminator completely negates the info command as well as the detect command. as they use the read block command and the chip response has the sequence terminator at the beginning of it so it messes up the demod there as well.

so about the only thing you could do with the pm3 currently is a lf t55xx read 0 and then data plot and demod the plot manually and see if in the beginning you get your normal tag data or the block 0 value.

(or try writing over a block and seeing if the tag's output changes...)

iceman · 2015-07-30 22:45:02

However if he gets a read, then "data ltrim" out the first ST, he should be able to use the
"lf t55xx info 1" option ...

iceman · 2015-07-30 22:46:04

@marshmellow, we did implement quite some good functions in the t55xx part...

rbubba1911 · 2015-07-31 11:07:09

Hi,

as marshmellow think, the commands return nothing.

lf t55xx info
lf t55xx detect

same situation for lf t55xx config b 32 d ASK o 0 (even with playing with offset)

more fun with lf t55xx read 0 , which in fact read 'something', I post the result here

proxmark3> lf t55xx read 0
proxmark3> data raw am
Using Clock:64, Invert:0, Bits Found:187
ASK/Manchester - Clock: 64 - Decoded bitstream:
1100000010101001
1111000000101010
0111110000001010
1001111100000010
1010011111000000
1010100111110000
0010101001111100
0000101010011111
0000001010100111
1100000010101001
1111000000101010
01111100000

proxmark3> lf t55xx read 1
proxmark3> data raw am
Using Clock:64, Invert:0, Bits Found:187
ASK/Manchester - Clock: 64 - Decoded bitstream:
1111110001000011
1111111100010000
1111111111000100
0011111111110001
0000111111111100
0100001111111111
0001000011111111
1100010000111111
1111000100001111
1111110001000011
1111111100010000
11111111110

proxmark3> lf t55xx read 2
proxmark3> data raw am
Using Clock:64, Invert:0, Bits Found:187
ASK/Manchester - Clock: 64 - Decoded bitstream:
1101100000010000
0011011000000100
0000110110000001
0000001101100000
0100000011011000
0001000000110110
0000010000001101
1000000100000011
0110000001000000
1101100000010000
0011011000000100
00001101100

proxmark3> lf t55xx read 3
proxmark3> data raw am
Using Clock:64, Invert:0, Bits Found:187
ASK/Manchester - Clock: 64 - Decoded bitstream:
1100001001000000
0011000010010000
0000110000100100
0000001100001001
0000000011000010
0100000000110000
1001000000001100
0010010000000011
0000100100000000
1100001001000000
0011000010010000
00001100001

seem be noise to me !

marshmellow · 2015-07-31 13:35:08

Could you Post a trace of a read 0

rbubba1911 · 2015-07-31 13:44:20

Hello marshmellow,

lf t55xx read 0
(without any t55 config)

http://www.filedropper.com/noralsy-read0

marshmellow · 2015-07-31 13:50:48

Btw, we know your tag is a clock of RF/32 you could force the demod to use a clock of 32 as the ST messes up the auto clock detection. That would give more accurate demods.

rbubba1911 · 2015-07-31 13:56:45

I Hope I made it correctly

lf t55xx read 0
data rawdemod am 32

Using Clock:32, Invert:0, Bits Found:370
# Errors during Demoding (shown as 7 in bit stream): 20
ASK/Manchester - Clock: 32 - Decoded bitstream:
0000000000001000
1000110001101010
1717000000000000
1000100011000110
1010171700000000
0000100010001100
0110101017170000
0000000010001000
1100011010101717
0000000000001000
1000110001101010
1717000000000000
1000100011000110
1010171700000000
0000100010001100
0110101017170000
0000000010001000
1100011010101717
0000000000001000
1000110001101010
1717000000000000
1000100011000110
1010171700000000
00
proxmark3> data print x
DemodBuffer: 00088C6A200088C6A200088C6A200088C6A200088C6A200088C6A200088C6A200088C6A200088C6A200088C6A200

As you think, the ST is now see as an decoding error, but these bit mean nothing for me.

Last edited by rbubba1911 (2015-07-31 13:57:48)

marshmellow · 2015-07-31 14:31:51

That is what your t55x7 block 0 looks like. It is a t55x7 and it is not locked. 00088c6a = config

Not sure why they use C and A. C should have no effect on an ask/man config.. And depending on the exact chip the 2 bit of A might not do anything either

rbubba1911 · 2015-07-31 15:06:07

ok, you rocks !

so, 00088c6a is the block0 I must keep for my future t55 programming,
with the bitstream we already found (BB0214FF6810201501870000) ?

If I read you correctly, there is a way to reprogramme the Noralsy tag using the same logic as t55.

iceman · 2015-07-31 15:06:50

If it is a t55x7 tag, unlocked, he should be able to write a config block 0 without the ST bit, and try all "t55xx" commands.
afterwards he can always re-write the old config block..

rbubba1911 · 2015-07-31 15:14:22

iceman wrote:

If it is a t55x7 tag, unlocked, he should be able to write a config block 0 without the ST bit, and try all "t55xx" commands.
afterwards he can always re-write the old config block..

If I understand correctly,

1 - program a new 'valid' block0
2 - use the t55 command
3 - re program my old block0

right ?

I'm curious to do that !

iceman · 2015-07-31 16:21:02

Yes, you only need to change the SST bit in you current config block,
write the new config back to block 0, and try the rest of the "t55xx" commands.

When you are done, you write back your old config block 0.

rbubba1911 · 2015-07-31 16:28:57

I'll try

for the t55xx configuration I see an excel document that could help me, I have asked to asper to send me a copy (on an old thread) but I've got no response yet.

is it possible you send me this document (I'm sure you have backed up !)

Thx

rbubba1911 · 2015-07-31 16:30:54

marshmellow wrote:

That is what your t55x7 block 0 looks like. It is a t55x7 and it is not locked. 00088c6a = config
Not sure why they use C and A. C should have no effect on an ask/man config.. And depending on the exact chip the 2 bit of A might not do anything either

I'll try to read the 3 other block (on Noralsy tag) the same way, to see if I retrieve my data.

Proxmark3 community

Announcement

#1 2015-07-29 12:52:03

Decode LF tag NORALSY (KCP3000)

#2 2015-07-29 13:37:00

Re: Decode LF tag NORALSY (KCP3000)

#3 2015-07-29 13:46:05

Re: Decode LF tag NORALSY (KCP3000)

#4 2015-07-29 13:53:06

Re: Decode LF tag NORALSY (KCP3000)

#5 2015-07-29 13:54:59

Re: Decode LF tag NORALSY (KCP3000)

#6 2015-07-29 14:35:04

Re: Decode LF tag NORALSY (KCP3000)

#7 2015-07-29 14:37:07

Re: Decode LF tag NORALSY (KCP3000)

#8 2015-07-29 14:44:47

Re: Decode LF tag NORALSY (KCP3000)

#9 2015-07-29 14:45:55

Re: Decode LF tag NORALSY (KCP3000)

#10 2015-07-29 15:02:06

Re: Decode LF tag NORALSY (KCP3000)

#11 2015-07-29 15:23:30

Re: Decode LF tag NORALSY (KCP3000)

#12 2015-07-29 15:33:09

Re: Decode LF tag NORALSY (KCP3000)

#13 2015-07-29 15:34:02

Re: Decode LF tag NORALSY (KCP3000)

#14 2015-07-29 15:35:02

Re: Decode LF tag NORALSY (KCP3000)

#15 2015-07-29 15:58:31

Re: Decode LF tag NORALSY (KCP3000)

#16 2015-07-29 16:20:10

Re: Decode LF tag NORALSY (KCP3000)

#17 2015-07-29 16:40:57

Re: Decode LF tag NORALSY (KCP3000)

#18 2015-07-29 17:08:49

Re: Decode LF tag NORALSY (KCP3000)

#19 2015-07-29 17:39:17

Re: Decode LF tag NORALSY (KCP3000)

#20 2015-07-29 17:57:46

Re: Decode LF tag NORALSY (KCP3000)

#21 2015-07-29 18:18:25

Re: Decode LF tag NORALSY (KCP3000)

#22 2015-07-29 19:13:14

Re: Decode LF tag NORALSY (KCP3000)

#23 2015-07-29 19:31:36

Re: Decode LF tag NORALSY (KCP3000)

#24 2015-07-29 22:26:53

Re: Decode LF tag NORALSY (KCP3000)

#25 2015-07-29 23:18:17

Re: Decode LF tag NORALSY (KCP3000)

#26 2015-07-30 10:42:23

Re: Decode LF tag NORALSY (KCP3000)

#27 2015-07-30 14:47:30

Re: Decode LF tag NORALSY (KCP3000)

#28 2015-07-30 15:46:15

Re: Decode LF tag NORALSY (KCP3000)

#29 2015-07-30 15:48:40

Re: Decode LF tag NORALSY (KCP3000)

#30 2015-07-30 16:06:20

Re: Decode LF tag NORALSY (KCP3000)

#31 2015-07-30 18:02:17

Re: Decode LF tag NORALSY (KCP3000)

#32 2015-07-30 20:49:55

Re: Decode LF tag NORALSY (KCP3000)

#33 2015-07-30 22:00:03

Re: Decode LF tag NORALSY (KCP3000)

#34 2015-07-30 22:06:18

Re: Decode LF tag NORALSY (KCP3000)

#35 2015-07-30 22:16:44

Re: Decode LF tag NORALSY (KCP3000)

#36 2015-07-30 22:27:42

Re: Decode LF tag NORALSY (KCP3000)

#37 2015-07-30 22:45:02

Re: Decode LF tag NORALSY (KCP3000)

#38 2015-07-30 22:46:04

Re: Decode LF tag NORALSY (KCP3000)

#39 2015-07-31 11:07:09

Re: Decode LF tag NORALSY (KCP3000)