Decode LF tag NORALSY (KCP3000)

iceman · 2015-07-31 16:40:39

You find the "EM4100 - UNIQUE Blocks Calculator - V1 " here: https://www.sendspace.com/file/awxrc2

rbubba1911 · 2015-07-31 16:42:44

Life saver !

big thanks !!

marshmellow · 2015-07-31 18:04:22

i'd be curious to see the "Trace" data from your chip. `lf t55xx trace` (will need to manually demod - or do it after you change block 0 to not have the ST.)

marshmellow · 2015-07-31 18:05:30

and i am 100% sure now that it is one of the T55x7 chips UNLOCKED...

iceman · 2015-07-31 18:11:08

and what makes you 100% sure?

marshmellow · 2015-07-31 18:21:03

Block 0 trace.

asper · 2015-07-31 18:33:54

Curious. T55x7 are more expensive than em4100 and usin no pwd at all is absolutely a money wasting solution... but they may charge you 50$ for one

Thanks ice for posting the excel, i am out of nowhere in those days and have no access to my archives.

Last edited by asper (2015-07-31 18:34:49)

marshmellow · 2015-07-31 18:55:11

Em4100 are read only chips preconfigured at the chip mfg. And everything can read them...

asper · 2015-08-01 08:27:04

This can be a reason but at least pwd protect them... in that way a malicious user can alter the tag content just sitting next to you making it unusable... not so science fiction...

marshmellow · 2015-08-01 13:12:34

I certainly agree not setting a password is not smart. But you'd be surprised how often that is the case.

rbubba1911 · 2015-08-01 21:48:05

marshmellow wrote:

i'd be curious to see the "Trace" data from your chip. `lf t55xx trace` (will need to manually demod - or do it after you change block 0 to not have the ST.)

I'm not confident enough in T55x programming to play with my garage access key,
I'm afraid to break everything
I've ordered some T55 cards to play with.

and i can confirm this point :

asper wrote:

but they may charge you 50$ for one wink

anyway, here the trace :
f t55xx trace

ASK/Manchester - Clock: 64 - Decoded bitstream:
1111000000000000
0101000100000111
1011110000000000
0001010001000001
1110111100000000
0000010100010000
0111101111000000
0000000101000100
0001111011110000
0000000001010001
0000011110111100
00000000000

DemodBuffer: F0005107BC001441EF0005107BC001441EF0005107BC00

This result have a meaning for you ?

trace :
http://s000.tinyupload.com/?file_id=23969498889045878969

Last edited by rbubba1911 (2015-08-01 22:31:39)

rbubba1911 · 2015-08-01 22:05:02

marshmellow wrote:

and i am 100% sure now that it is one of the T55x7 chips UNLOCKED...

you fu**ing dam right !!

a session of lf t55xx read 1 - 3 plus manual decoding give me this result :

Block 1
BB0214FF 2
Block 2
68102015 2
Block 3
01870000 2

the 2 is part of the response , I separate them to see the pattern we decode !!

here we are !!

I wait for my blank card now

Many thanks for all you !

Last edited by rbubba1911 (2015-08-01 22:33:19)

rbubba1911 · 2015-08-03 10:57:31

Side question :

since we know this tag just contain a regular T55 chip, with an unusual but valid ST.
some other vendor could use the T55 in this configuration

don't you think the PM3 should be able to decode this ST, via a specific option (like t55xx config) or by itself (auto detection)

regards

iceman · 2015-08-03 11:32:08

If you want to add the functionality of decoding a t55xx tag programmed to use SST, go ahead. I welcome it.

rbubba1911 · 2015-08-03 11:53:49

I will try !

rbubba1911 · 2015-08-12 11:14:26

I've received my blank T55 card this morning

So, as we discover, the KCP3000 is build upon a T55xx chip (with a special configuration)

To clone this kind of tag, here my procedure:

lf read
data sample
data raw am 32
0000001000000001
0101000000011000
0111000000000000
0000171710111011
0000001000010100
1111111101101000
0001000000100000
0001010100000001
1000011100000000
0000000017171011

You have to ltrim/rtrim to keep only bit between the error (SeqTerminator) (7)
(the windows plot help you)

proxmark3> data ltrim 2812
proxmark3> data rtrim 3168

until you got:

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

proxmark3> data print x
DemodBuffer: BB0214FF6810201501870000

From there, you have all needed info to programme T55 chip,

set the T55 config block into something the pm3 can understand.

lf t55 write 0 000c8040

at this point, you can use regular T55xx command on your tag (read/write)

Now programme data block as usual,

lf t55 write 1 BB0214FF
lf t55 write 2 68102015
lf t55 write 3 01870000

if everything is correct, then finally programme the Noralsy config block :

lf t55 write 0 00088C6A

now, go to your door, place the t55 tag, biip, smile a bit

Jobs done!

Thank you all for this nice journey

Last edited by rbubba1911 (2015-08-14 11:22:08)

iceman · 2016-02-18 18:21:56

Regarding Sequence Terminator; @marshmellow42 has a STT detection method out in one of his forks.

Btw did you have some printed numbers on your noralys tag/card? So we can make a demod?

Last edited by iceman (2016-02-18 18:24:13)

rbubba1911 · 2016-02-19 10:27:20

Hi iceman,

very good news, yes I have two KCP300 tags, with engraved number.

I'll update my version of marshmellow git, and flash it to pm3

I'm ready for test !

iceman · 2016-02-19 10:30:25

Great!
Then make a lf read and save the trace, share it here,
together with the printed number.

Both of your tags, then we have something to work with.

rbubba1911 · 2016-02-19 11:06:41

ID engraved on tag : 6811501

Manual ST separation :
(data raw am 32 can help)

101110110000001000010100111111110110100000010000001000000001010100000001100001110000000000000000

in hex : BB0214FF6810201501870000

you can see ID

Trace file at : http://www.filedropper.com/kcp300-cap1

Last edited by rbubba1911 (2016-02-19 11:25:51)

iceman · 2016-02-19 11:17:22

If your second tag gives the same result with the engraved id inside the raw hex, that would be good to confirm

ID:engraved: 6811501
raw hex: BB0214FF 681 020 1501 870000

rbubba1911 · 2016-02-19 11:22:28

Yes the second tag, behave identically,

I don't have the second tag with me, (it's on my wife keyring)

I can post the second trace when she's back.

rbubba1911 · 2016-02-19 12:24:31

A question for marsh:

I see the improvement in lf t55 config (ST)

it will be very helpfull to have the block0 configuration value,

I mean when you do: lf t55 config
Chip Type : T55x7
Modulation : ASK
Bit Rate : 2 - RF/32
Inverted : Yes
Offset : 0
Seq. Term. : 135100046
Block0 : 0x00000000

Block0 is always to 0, no matter option I choose in lf t55 config

for example I know the kcp3000 custom configuration block is 00088C6A
but I can't configure the PM3 to read the tag with this configuration

I' try to setup :

Safer Key 0 (default)
Data Bit Rate RF/32 (default)
Modulation Manchester (default)
PSKCF Reserved
MaxBlk no 1 to 3
X-Mode 0 (default)
AOR 0 (default)
OTP 0 (default)
PWD 0 (default)
SST.Tem. 1
Fast Write 0 (default)
Inverse Data 1
POR-Delay 0 (default)

I'll try : lf t55 config d ASK i 1 o 0 ST then lf t55 info / read bloc 0 without success

iceman · 2016-02-19 12:49:43

You used another configblock earlier.

000c8040

00088C6A
-------------

32, man, invert, stt, gives to me: 0x000c8040

rbubba1911 · 2016-02-19 12:53:50

Yes,
I use 000c8040 configuration block (default configuration) to use the lf t55 commands,
otherwise t55 cmd fails.

but the "true" configuration block is 00088C6A, and need to programmed at the last step.

I don't know if it's possible, but it was great to have a cmd like:

lf t55 config b0 = 0x00088C6A

and then can use others t55 cmds directly.

Last edited by rbubba1911 (2016-02-19 13:10:54)

iceman · 2016-02-19 13:43:59

That config block doesn't look like a good config block.
The C in 00088C6A, is "PSKCFG - reserved". Very strange it doesn't do anything to the demod of the t55xx commands.

Normally you don't have a config block to start with when you try to read a t55xx tag. Thats why we implemented it in this way. But feel free to contribute and add it.

Getting a config block out from the configuration in t55xx, well, we don't use all modes/configuration so you will never get a complete configuration block out needed to clone your tag.

rbubba1911 · 2016-02-19 14:10:21

ok, I understand better,

I thought the config block was needed to read the t55 chip, I was wrong.
I realize how many configurations will be possible and the sum of work to handle all of them.

so, in this particular case, when you meet an 'original' t55's configuration tag

the best is to :

read t55 block 0
manually decode the trace to retrieve the current configuration
(cutting bits between the ST)
program 'default' block0 (000c8040)
program others block, with t55 cmds
program original block0

I'll try to test my clone tag with a standard bloc0, to see ...

iceman · 2016-02-19 14:32:02

With marshmellows STT function, you hopefully will not have to cut bits out.

if you have a t55xx tag, you can just read block 0 to get the right one , once you have the demod config set correct.

For other clones, like awid, viking etc the block0 has been identified and when using the clone cmd you get a good copy.

That is what we aim to get here for noralys too.

You can use your strange block0, it should not inflict anything on the t55xx, direct.

marshmellow · 2016-02-19 14:47:23

rbubba1911 wrote:

Seq. Term. : 135100046

Hmmm. This looks like a bug... I probably didn't remember to initialize the var.

iceman · 2016-02-19 14:48:44

or %u....

marshmellow · 2016-02-19 14:49:39

I'd be curious if with my fork you can lf t55xx detect your tag.

rbubba1911 · 2016-02-19 15:00:57

Marsh, I currently use your fork, (sync this morning)

here's the detect results:

proxmark3> lf t55 detect
#db# DownloadFPGA(len: 42096)
Could not detect modulation automatically. Try setting it manually with 'lf t55xx config'

when I program the default bloc 0

proxmark3> lf t55 wr b 0 d 000c8040
Writing page 0 block: 00 data: 0x000C8040

proxmark3> lf t55 detect
Chip Type : T55x7
Modulation : ASK
Bit Rate : 3 - RF/40
Inverted : No
Offset : 33
Seq. Term. : 135100046
Block0 : 0x000C8040

Last edited by rbubba1911 (2016-02-19 15:02:52)

marshmellow · 2016-02-19 15:07:55

Ok, good to know thx. I have some more work to do. I haven't finished it (which is why I haven't tried to get it in the master yet).

rbubba1911 · 2016-02-19 15:12:29

happy to help,

just tell me when you want more tests !

sadly, I'm not good enough to help you with code.

rbubba1911 · 2016-02-19 20:59:40

The second tag,

ID engraved on tag : 6811596

Manual ST separation :
101110110000001000010100111111110110100000010000001000000001010110010110011001110000000000000000

in hex : BB0214FF6810201596670000

Trace file at : http://www.filedropper.com/kcp300-cap2
(weak signal)

marshmellow · 2016-02-19 21:08:09

ok if you want to refresh my fork and try again I think it should be fully working now.

marshmellow · 2016-02-19 21:18:26

I took a look at the two tags you have and other than the printed id the only other thing that changes is the 87 after the ID goes to 67 for the second tag. probably a checksum. iceman thoughts?

rbubba1911 · 2016-02-19 21:19:42

I've just update your fork
client/cmdlft55xx.c | 2 +-
common/lfdemod.c | 32 ++++++++++++++++++++------------
2 files changed, 21 insertions(+), 13 deletions(-)

no need to reflash firmware right ?

but t55 detect, info show nothing

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

lf t55 read
Reading Page 0:
blk | hex data | binary
----+----------+---------------------------------

lf t55 info
*output nothing*

by decoding buffer I can see my data

marshmellow · 2016-02-19 21:33:23

no need to flash but did you make clean && make all?

marshmellow · 2016-02-19 21:34:57

plus with your fob's weak signal you might need to play with different distances to get it to read good.
although I was able to use `lf search 1 u` on your traces and it worked fine...

Last edited by marshmellow (2016-02-19 21:36:44)

rbubba1911 · 2016-02-19 21:37:38

yep, a full clean build.

marshmellow · 2016-02-19 21:44:39

do you get much with `lf search u`

rbubba1911 · 2016-02-19 21:49:43

lf search u
Reading 30000 bytes from device memory

Data fetched
Samples @ 8 bits/smpl, decimation 1:1
NOTE: some demods output possible binary
if it finds something that looks like a tag
False Positives ARE possible

Checking for known tags:
No Known Tags Found!

Checking for Unknown tags:
Possible Auto Correlation of 3200 repeating samples

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

Unknown ASK Modulated and Manchester encoded Tag Found!

notice the buffer contain the correct data

data print x
DemodBuffer: BB0214FF6810201501870000BB0214FF6810201501870000BB0214FF6810201501870000BB0214FF6810201501870000BB0214FF

Last edited by rbubba1911 (2016-02-19 21:54:37)

marshmellow · 2016-02-19 21:53:08

the detection was messed up by the strange A at the end of your block 0. the 2 bit should only be set in extended mode but for some reason your tag has it set without extended mode being on. I adjusted the detection routine now and it should be all happy...

Last edited by marshmellow (2016-02-19 21:53:47)

marshmellow · 2016-02-19 21:59:53

your post #93 doesn't make sense. it output the wrong binary string but the correct hex? it prints from the same location...did you have `data debugmode` set to > 0? (this could cause it)

Last edited by marshmellow (2016-02-19 22:04:46)

iceman · 2016-02-19 22:08:29

When I demod @rbubba1911's traces.. I don't get the same hex.

With marshmellows ST function.

DemodBuffer: 1EC0801201F887B02004807E21EC0801201F887B02004807E21EC0801201F887B02004807E21EC0801201F887B02004807E21EC0801201F887B02004807E21EC
DemodBuffer: 81025403F10F60409500FC43D81025403F10F60409500FC43D81025403F10F60409500FC43D81025403F10F60409500FC43D81025403F10F60409500FC43D810

marshmellow · 2016-02-19 22:10:32

@iceman have you taken my latest changes?

iceman · 2016-02-19 22:14:28

Funny,

running these, gives me the wrong (above) hex.

 
 da lo traces/o/kcp300-cap1.pm3
 lf se 1 u
 da print x

Running these, gives me the same hex as you guys.

 da lo traces/o/kcp300-cap1.pm3
 da raw am s
 da print x

@marshmellow --yes, even your outcomment of the t55x7 configblock detection bits..

Last edited by iceman (2016-02-19 22:15:29)

marshmellow · 2016-02-19 22:16:00

Interesting... I'll have a closer look at the lf search...

iceman · 2016-02-19 22:19:21

I'm guessing, but does lf search take notice of "st" detection automatically yet?

NORALYS  - KCP-300
# | PRINTED | RAW HEX                  | RAW BIN
1 | 6811501 | BB0214FF6810201501870000 | 10111011 00000010 00010100 11111111 01101000 00010000 00100000 00010101 00000001 10000111 00000000 00000000
2 | 6811596 | BB0214FF6810201596670000 | 10111011 00000010 00010100 11111111 01101000 00010000 00100000 00010101 10010110 01100111 00000000 00000000

Looking at the hex and bin, the 0x67 - 0x87 bytes differs as marshmellow already noticed.
Could be a crc or xor or sum of the earlier bytes. Let me run the reveng

Proxmark3 community

Announcement

#51 2015-07-31 16:40:39

Re: Decode LF tag NORALSY (KCP3000)

#52 2015-07-31 16:42:44

Re: Decode LF tag NORALSY (KCP3000)

#53 2015-07-31 18:04:22

Re: Decode LF tag NORALSY (KCP3000)

#54 2015-07-31 18:05:30

Re: Decode LF tag NORALSY (KCP3000)

#55 2015-07-31 18:11:08

Re: Decode LF tag NORALSY (KCP3000)

#56 2015-07-31 18:21:03

Re: Decode LF tag NORALSY (KCP3000)

#57 2015-07-31 18:33:54

Re: Decode LF tag NORALSY (KCP3000)

#58 2015-07-31 18:55:11

Re: Decode LF tag NORALSY (KCP3000)

#59 2015-08-01 08:27:04

Re: Decode LF tag NORALSY (KCP3000)

#60 2015-08-01 13:12:34

Re: Decode LF tag NORALSY (KCP3000)

#61 2015-08-01 21:48:05

Re: Decode LF tag NORALSY (KCP3000)

#62 2015-08-01 22:05:02

Re: Decode LF tag NORALSY (KCP3000)

#63 2015-08-03 10:57:31

Re: Decode LF tag NORALSY (KCP3000)

#64 2015-08-03 11:32:08

Re: Decode LF tag NORALSY (KCP3000)

#65 2015-08-03 11:53:49

Re: Decode LF tag NORALSY (KCP3000)

#66 2015-08-12 11:14:26

Re: Decode LF tag NORALSY (KCP3000)

#67 2016-02-18 18:21:56

Re: Decode LF tag NORALSY (KCP3000)

#68 2016-02-19 10:27:20

Re: Decode LF tag NORALSY (KCP3000)

#69 2016-02-19 10:30:25

Re: Decode LF tag NORALSY (KCP3000)

#70 2016-02-19 11:06:41

Re: Decode LF tag NORALSY (KCP3000)

#71 2016-02-19 11:17:22

Re: Decode LF tag NORALSY (KCP3000)

#72 2016-02-19 11:22:28

Re: Decode LF tag NORALSY (KCP3000)

#73 2016-02-19 12:24:31

Re: Decode LF tag NORALSY (KCP3000)

#74 2016-02-19 12:49:43

Re: Decode LF tag NORALSY (KCP3000)

#75 2016-02-19 12:53:50

Re: Decode LF tag NORALSY (KCP3000)

#76 2016-02-19 13:43:59

Re: Decode LF tag NORALSY (KCP3000)

#77 2016-02-19 14:10:21

Re: Decode LF tag NORALSY (KCP3000)

#78 2016-02-19 14:32:02

Re: Decode LF tag NORALSY (KCP3000)

#79 2016-02-19 14:47:23

Re: Decode LF tag NORALSY (KCP3000)

#80 2016-02-19 14:48:44

Re: Decode LF tag NORALSY (KCP3000)

#81 2016-02-19 14:49:39

Re: Decode LF tag NORALSY (KCP3000)

#82 2016-02-19 15:00:57

Re: Decode LF tag NORALSY (KCP3000)

#83 2016-02-19 15:07:55

Re: Decode LF tag NORALSY (KCP3000)

#84 2016-02-19 15:12:29

Re: Decode LF tag NORALSY (KCP3000)

#85 2016-02-19 20:59:40

Re: Decode LF tag NORALSY (KCP3000)

#86 2016-02-19 21:08:09

Re: Decode LF tag NORALSY (KCP3000)

#87 2016-02-19 21:18:26

Re: Decode LF tag NORALSY (KCP3000)

#88 2016-02-19 21:19:42

Re: Decode LF tag NORALSY (KCP3000)

#89 2016-02-19 21:33:23

Re: Decode LF tag NORALSY (KCP3000)