Research, development and trades concerning the powerful Proxmark3 device.
Remember; sharing is caring. Bring something back to the community.
"Learn the tools of the trade the hard way." +Fravia
You are not logged in.
Time changes and with it the technology
Proxmark3 @ discord
Users of this forum, please be aware that information stored on this site is not private.
Pages: 1
I'm having trouble reading a LF card that can be read on a SecuraKey RK-65KS reader. The tag is 125kHz, and has the markings “07985” at the top and “C7” at the bottom left corner.
Here's a copy of the raw data stream:
http://pastebin.com/Gs2P8rp4
proxmark3> data detectclock
Auto-detected clock rate: 40
proxmark3> data norm
proxmark3> data threshold
proxmark3> data askdemod 1
proxmark3> data mandemod
Warning: Manchester decode error for pulse width detection.
(too many of those messages mean either the stream is not Manchester encoded, or clock is wrong)
Unsynchronized, resync...
(too many of those messages mean the stream is not Manchester encoded)
Unsynchronized, resync...
(too many of those messages mean the stream is not Manchester encoded)
Unsynchronized, resync...
(too many of those messages mean the stream is not Manchester encoded)
Manchester decoded bitstream
1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 1 1 1 1 1 1 1 1 1 0 0
1 0 1 1 0 1 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 1 0 0 0 0 1 1 0 1
1 0 0 0 0 1 1 1 1 1 0 0 0 1 1 0
0 0 1 0 0 0 0 0 0 1 1 1 1 0 0 1
1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 1 1 1 1 1 1 1 1 1 0 0
1 0 1 1 0 1 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 1 0 0 0 0 1 1 0 1
1 0 0 0 0 1 1 1 1 1 0 0 0 1 1 0
0 0 1 0 0 0 0 0 0 1 1 1 1 0 0 1
1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 1 1 1 1 1 1 1 1 1 0 0
1 0 1 1 0 1 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 1 0 0 0 0 1 1 0 1
1 0 0 0 0 1 1 1 1 1 0 0 0 1 1 0
0 0 1 0 0 0 0 0 0 1 1 1 1 0 0 1
1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 1 1 1 1 1 1 1 1 1 0 0
1 0 1 1 0 1 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 1 0 0 0 0 1 1 0 1
1 0 0 0 0 1 1 1 1 1 0 0 0 1 1 0
0 0 1 0 0 0 0 0 0 1 1 1 1 0 0 1
1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 1 1 1 1 1 1 1 1 1 0 0
1 0 1 1 0 1 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 1 0 0 0 0 1 1 0 1
1 0 0 0 0 1 1 1 1 1 0 0 0 1 1 0
0 0 1 0 0 0 0 0 0 1 1 1 1 0 0 1
1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 1 1 1 1 1 1 1 1 1 0 0
1 0 1 1 0 1 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 1 0 0 0 0 1 1 0 1
1 0 0 0 0 1 1 1 1 1 0 0 0 1 1 0
0 0 1 0 0 0 0 0 0 1 1 1 1 0 0 1
1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 1 1 1 1 1 1 1 1 1 0 0
1 0 1 1 0 1 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 1 0 0 0 0 1 1 0 1
1 0 0 0 0 1 1 1 1 1 0 0 0 1 1 0
0 0 1 0 0 0 0 0 0 1 1 1 1 0 0 1
1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 1 1 1 1 1 1 1 1 1 0 0
1 0 1 1 0 1 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 1 0 0 0 0 1 1 0 1
1 0 0 0 0 1 1 1 1 1 0 0 0 1 1 0
0 0 1 0 0 0 0 0 0 1 1 1 1 0 0 1
1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 1 1 1 1 1 1 1 1 1 0 0
1 0 1 1 0 1 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 1 0 0 0 0 1 1 0 1
1 0 0 0 0 1 1 1 1 1 0 0 0 1 1 0
0 0 1 0 0 0 0 0 0 1 1 1 1 0 0 1
1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 1 1 1 1 1 1 1 1 1 0 0
1 0 1 1 0 1 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 1 0 0 0 0 1 1 0 1
1 0 0 0 0 1 1 1 1 1 0 0 0 1 1 0
0 0 1 0 0 0 0 0 0 1 1 1 1 0 0 1
1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 1 1 1 1 1 1 1 1 1 0 0
I even tried...
proxmark3> lf hid demod
proxmark3> data mandemod
Warning: Manchester decode error for pulse width detection.
(too many of those messages mean either the stream is not Manchester encoded, or clock is wrong)
Unsynchronized, resync...
(too many of those messages mean the stream is not Manchester encoded)
Unsynchronized, resync...
(too many of those messages mean the stream is not Manchester encoded)
Manchester decoded bitstream
0 0 1 1 1 1 1 1 1 1 1 1 1 1 1 1
1 1 1 1 1 1 0 0 0 0 0 0 0 0 0 1
1 0 1 0 0 1 0 1 1 1 1 1 1 1 1 1
1 1 1 1 1 1 1 1 0 1 1 1 1 0 0 1
0 0 1 1 1 1 0 0 0 0 0 1 1 1 0 0
1 1 1 0 1 1 1 1 1 1 0 0 0 0 1 1
0 0 1 1 1 1 1 1 1 1 1 1 1 1 1 1
proxmark3>
I tried to read it like all the other HID fobs and cards I have, but lf hid fskdemod doesn't detect the card. I'm thinking it could be an EM4100 or something.
Any suggestions? Am I doing something wrong?
I almost forgot – here's some version information:
proxmark3> hw version
#db# Prox/RFID mark3 RFID instrument
#db# bootrom: master/v1.1.0-3-gb03c0f2-suspect 2014-08-02 16:34:52
#db# os: master/v1.1.0-37-gca4714c-suspect 2014-11-26 22:19:30
#db# LF FPGA image built on 2014/ 6/23 at 9:25:13
uC: AT91SAM7S256 Rev B
Embedded Processor: ARM7TDMI
Nonvolatile Program Memory Size: 256K bytes
Second Nonvolatile Program Memory Size: None
Internal SRAM Size: 64K bytes
Architecture Identifier: AT91SAM7Sxx Series
Nonvolatile Program Memory Type: Embedded Flash Memory
Offline
001011010000000000000000010000110110000111110001100010000001111001100000000000000000000
001011010000000000000000010000110110 [0001] [1111] 0 [0011] [0001] 0000001111001100000000000000000000
0001 = 0x1
1111 = 0xF
0011 = 0x3
0001 = 0x1
I can carve out the numbers I see on the card, but it doesn't seem to fit EM4100 format with parity bits following each nibble.
None of the em410x or t55x7 commands seem to read any data.
Offline
Do you have access to the SecuraKey reader ?
Does this work on door :
blk 0 0x000C8060
blk 1 0xFF968000
blk 2 0x21B0F8C4
blk 3 0x0F300000
Offline
Excellent! I wrote it to a T5577 and it works.
blk 0 0x000C8060
blk 1 0xFF968000
blk 2 0x21B0F8C4
blk 3 0x0F300000
000C8060 00000000000011001000000001100000
FF968000 11111111100101101000000000000000
21B0F8C4 00100001101100001111100011000100
0F300000 00001111001100000000000000000000
100000000000000000000111111111001011010000000000000000010000110110000111110001100010000001111001100000000000000000000111111111....
[BLK1 1 1 1 1 1 1 1 1 1 1 1 1 1][BLK2 2 2 2 2 2 2 2 2 2 2 2 2 2][BLK3 3 3 3 3 3 3 3 3 3 3 3 3 3]
Will block 0 always be 0x000C8060? I'm not sure where that data came from.
Thank you for your help!
Offline
The answer is in the datasheet of the thing you are using to emulate that other thing... t55x7
Offline
In block 0 page 0 you set settings for the t5577, i.e. what shape your wave will have, what modulation is being used etc. Its quite cool what t5577 is capable of.
Offline
Ohh, ok.
I tried reading just block 0 on another and matching it up against the values in the other card's block 0. If I'm reading this correctly, the four option bits are set.
When I write other cards, I don't see any harm in leaving them off.
Provided as a sample in this thread: 0x000C8060
Read with option bits set: 0xF00C8060
I ordered some more T5577 tags (this time in a very thin form on a roll with a flat antenna).
I appreciate your help in understanding these tags.
Offline
I have Securakey too, it's for parking access, i tried to clone it to t5577 but didn't work, any help?
proxmark3> lf search u
Done, saved 40000 out of 40000 seen samples at 8 bits/sample
buffer samples: 00 00 00 00 00 aa ff ff ...
Reading 20000 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 1 repeating samples
Unknown ASK Modulated and Manchester encoded Tag Found!
if it does not look right it could instead be ASK/Biphase - try 'data rawdemod ab'
1001100000000000
0000100001110101
1001000000110001
1001110001111111
0000000000000000
0000000011111111
1001100000000000
0000100001110101
1001000000110001
1001110001111111
0000000000000000
0000000011111111
1001100000000000
0000100001110101
1001000000110001
1001110001111111
0000000000000000
0000000011111111
1001100000000000
0000100001110101
1001000000110001
1001110001111111
0000000000000000
0000000011111111
1001100000000000
0000100001110101
1001000000110001
1001110001111111
0000000000000000
0000000011111111
1001100000000000
Offline
r00tb0x - What is the model number listed on the reader?
It might be easier to read if you remove the line breaks and start each line with the start sequence 11111111
111111100000000000000000000000011111111100110000000000000001000011101011001000000110001100111000
111111100000000000000000000000011111111100110000000000000001000011101011001000000110001100111000
111111100000000000000000000000011111111100110000000000000001000011101011001000000110001100111000
Then break one of the lines up into 32-bit segments...
11111110000000000000000000000001 11111111001100000000000000010000 11101011001000000110001100111000
Convert the binary segments into hexadecimal. (http://www.binaryhexconverter.com/binary-to-hex-converter works consistently)
0xFE000001 = 0b11111110000000000000000000000001
0xFF300010 = 0b11111111001100000000000000010000
0xEB206338 = 0b11101011001000000110001100111000
blk 0 0x000C8060 (per previous posts in this thread)
blk 1 0xFE000001 (first segment)
blk 2 0xFF300010 (second segment)
blk 3 0xEB206338 (third segment)
Someone can correct me if I'm wrong, but I believe the info above is correct. If you have a spare tag, use the t55xx commands to write those four blocks.
Offline
scott, thanks for the wonderful explanation, the problem is that prox read the card every time with a different output, have a look at this, i double checked the lf antenna with no problems.
proxmark3> lf search u
#db# Done, saved 40000 out of 40000 seen samples at 8 bits/sample
#db# buffer samples: 00 00 00 00 00 00 00 00 ...
Reading 20000 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 3840 repeating samples
Unknown ASK Modulated and Manchester encoded Tag Found!
if it does not look right it could instead be ASK/Biphase - try 'data rawdemod ab'
1001100000000000
0000100001110101
1001000000110001
1001110001111111
0000000000000000
0000000011111111
1001100000000000
0000100001110101
1001000000110001
1001110001111111
0000000000000000
0000000011111111
1001100000000000
0000100001110101
1001000000110001
1001110001111111
0000000000000000
0000000011111111
1001100000000000
0000100001110101
1001000000110001
1001110001111111
0000000000000000
0000000011111111
1001100000000000
0000100001110101
1001000000110001
1001110001111111
0000000000000000
0000000011111111
1001100000000000
proxmark3> lf search u
#db# Done, saved 40000 out of 40000 seen samples at 8 bits/sample
#db# buffer samples: 8a 5b 34 14 00 00 00 00 ...
Reading 20000 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 1 repeating samples
Unknown ASK Modulated and Manchester encoded Tag Found!
if it does not look right it could instead be ASK/Biphase - try 'data rawdemod ab'
1111000000000000
0000000000001111
1111100110000000
0000000010000111
0101100100000011
0001100111000111
1111000000000000
0000000000001111
1111100110000000
0000000010000111
0101100100000011
0001100111000111
1111000000000000
0000000000001111
1111100110000000
0000000010000111
0101100100000011
0001100111000111
1111000000000000
0000000000001111
1111100110000000
0000000010000111
0101100100000011
0001100111000111
1111000000000000
0000000000001111
1111100110000000
0000000010000111
0101100100000011
0001100111000111
1111000000000000
proxmark3> lf search u
#db# Done, saved 40000 out of 40000 seen samples at 8 bits/sample
#db# buffer samples: 59 ff ff ff ff ff ff ff ...
Reading 20000 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 3840 repeating samples
Unknown ASK Modulated and Manchester encoded Tag Found!
if it does not look right it could instead be ASK/Biphase - try 'data rawdemod ab'
0000100001110101
1001000000110001
1001110001111111
0000000000000000
0000000011111111
1001100000000000
0000100001110101
1001000000110001
1001110001111111
0000000000000000
0000000011111111
1001100000000000
0000100001110101
1001000000110001
1001110001111111
0000000000000000
0000000011111111
1001100000000000
0000100001110101
1001000000110001
1001110001111111
0000000000000000
0000000011111111
1001100000000000
0000100001110101
1001000000110001
1001110001111111
0000000000000000
0000000011111111
1001100000000000
0000100001110101
proxmark3> hw version
#db# Prox/RFID mark3 RFID instrument
#db# bootrom: /-suspect 2015-04-02 15:12:04
#db# os: /-suspect 2015-04-02 15:12:11
#db# LF FPGA image built on 2015/03/06 at 07:38:04
uC: AT91SAM7S256 Rev B
Embedded Processor: ARM7TDMI
Nonvolatile Program Memory Size: 256K bytes
Second Nonvolatile Program Memory Size: None
Internal SRAM Size: 64K bytes
Architecture Identifier: AT91SAM7Sxx Series
Nonvolatile Program Memory Type: Embedded Flash Memory
Offline
You're getting the same output. It's a repeating stream. The 11111111 should help you find the start of the transmission.
11111111
1001100000000000
0000100001110101
1001000000110001
1001110001111111
0000000000000000
00000000
1111
1111100110000000
0000000010000111
0101100100000011
0001100111000111
1111000000000000
000000000000
11111111
1001100000000000
0000100001110101
1001000000110001
1001110001111111
0000000000000000
00000000
It's much easier to see if you remove the line breaks.
111111111001100000000000000010000111010110010000001100011001110001111111000000000000000000000000
111111111001100000000000000010000111010110010000001100011001110001111111000000000000000000000000
111111111001100000000000000010000111010110010000001100011001110001111111000000000000000000000000
You should also be able to see a repeating pattern if you plot the waveform. (data plot)
Offline
scott, you are totally right, that was my mistake, i write the blocks to a t5577 card, but still the door reader didn't accept the new card, when i write the blks to the card it doesn't give me any success output or response from the prox, read or write for t55xx doesn't give any reads, this is weird.
Offline
I haven't updated my Proxmark since the commands were changed. If I have some time in the next couple days, I'll do the update and re-read some of my tags. Can you post a screenshot of the data plot... or better yet, can you save the data stream somewhere?
Offline
scott, you are totally right, that was my mistake, i write the blocks to a t5577 card, but still the door reader didn't accept the new card, when i write the blks to the card it doesn't give me any success output or response from the prox, read or write for t55xx doesn't give any reads, this is weird.
Couple questions:
what blocks/commands did you use to write?
Did you read the t55x7 tag back after you wrote it using the same command as used on your original tag?
How strong is your antenna? (hw tune with no tag on the antenna)
Can you post link to a trace file of your original tag?
Offline
Sorry guys for the late, i was out of country.
I haven't updated my Proxmark since the commands were changed. If I have some time in the next couple days, I'll do the update and re-read some of my tags. Can you post a screenshot of the data plot... or better yet, can you save the data stream somewhere?
The card is not with me right now, it was my friend card, i will try to pick it up again for the data plot.
Couple questions:
what blocks/commands did you use to write?
Did you read the t55x7 tag back after you wrote it using the same command as used on your original tag?
How strong is your antenna? (hw tune with no tag on the antenna)
Can you post link to a trace file of your original tag?
Commands
Command for reading the first card (SecuraKey)
proxmark3> lf search u
Command for reading the second card (T5577)
lf t55xx read 0
Command used for writing the blocks
lf t55xx wr 0 000C8060
lf t55xx wr 1 FE000001
lf t55xx wr 2 FF300010
lf t55xx wr 3 EB206338
Antenna
proxmark3> hw tune
Measuring antenna characteristics, please wait........
# LF antenna: 16.09 V @ 125.00 kHz
# LF antenna: 16.09 V @ 134.00 kHz
# LF optimal: 20.76 V @ 129.03 kHz
# HF antenna: 0.28 V @ 13.56 MHz
# Your HF antenna is unusable.
Version
proxmark3> hw version
#db# Prox/RFID mark3 RFID instrument
#db# bootrom: /-suspect 2015-04-02 15:12:04
#db# os: /-suspect 2015-04-02 15:12:11
#db# HF FPGA image built on 2015/03/09 at 08:41:42
uC: AT91SAM7S256 Rev B
Embedded Processor: ARM7TDMI
Nonvolatile Program Memory Size: 256K bytes
Second Nonvolatile Program Memory Size: None
Internal SRAM Size: 64K bytes
Architecture Identifier: AT91SAM7Sxx Series
Nonvolatile Program Memory Type: Embedded Flash Memory
Offline
It's still early, but it looks like I didn't start at the beginning. Block 1 should start with 11111111, not 01111111 or 11111110. At 2AM, 1111111 looks surprisingly similar to 11111111.
11111111
1001100000000000
0000100001110101
1001000000110001
1001110001111111
0000000000000000
00000000
111111111001100000000000000010000111010110010000001100011001110001111111000000000000000000000000
11111111100110000000000000001000 0xFF980008
01110101100100000011000110011100 0x7590319C
01111111000000000000000000000000 0x7F000000
Try this:
lf t55xx wr 0 000C8060
lf t55xx wr 1 FF980008
lf t55xx wr 2 7590319C
lf t55xx wr 3 7F000000
Offline
something it appear clock 32. Just to make sure..
Offline
@Scott and @app-o1,
the actual trace has been gone already so I could not see from post #01 and #02 how you come to the result.
0xFF968000
0x21B0F8C4
0x0F300000
!!!
from content of post #1 I have very wrong!
800007FC
B400010D
87C62079
!!!!
Could I pls have the trace for that result you post to try out. Or maybe you explain in short. Thank you.
@scott, @Joe @Marshmellow can I blindly trust "data detectclock" result? it always tell me clock I don't expect. In your experiment was it 40 or 32?
Offline
as far as the two hex strings, convert to binary and compare. they are the same, just different starting points.
as far as `data detectclock`, it is pretty accurate now as long as you have a good read and assuming you choose the correct modulation - a/f/p/n.
by good read i mean highs above 50 (plot), and lows below -50 (plot) ..
best way to verify the clock is to plot the samples and measure the clock manually.
Offline
as far as the two hex strings, convert to binary and compare. they are the same, just different starting points.
Could you help me a little more. I could not get it align
from app_o1
1111 1111 1001 0110 1000 0000 0000 0000
0010 0001 1011 0000 1111 1000 1100 0100
0000 1111 0011 0000 0000 0000 0000 0000
from me made from demode binary datas of Scott's #1 post
1000 0000 0000 0000 0000 0111 1111 1100
1011 0100 0000 0000 0000 0001 0000 1101
1000 0111 1100 0110 0010 0000 0111 1001
from app_o1
1111 1111 1001 0110 1000 0000 0000 0000 0010 0001 1011 0000 1111 1000 1100 0100 0000 1111 0011 0000 0000 0000 0000 0000
from me
1000 0000 0000 0000 0000 0111 1111 1100 1011 0100 0000 0000 0000 0001 0000 1101 1000 0111 1100 0110 0010 0000 0111 1001
as far as `data detectclock`, it is pretty accurate now as long as you have a good read and assuming you choose the correct modulation - a/f/p/n.
by good read i mean highs above 50 (plot), and lows below -50 (plot) ..
best way to verify the clock is to plot the samples and measure the clock manually.
Measure manual??? like you told me once "Apply data grid 8/32/40/50/100 etc." and my interpretation is "Trying to see at which clock the graph 'stays' 'most' inside a chosen grid, not 100% safe because some "sinus" waves could be outside of the grid."
Offline
FSK clock measuring can be a little tricky with the grid alone. But the others are easy.(you can measure distance by settings the two markers - left an right click, no grid necessary)
Not sure the binary question... Just shift the bits in a circle (beginning to end) till it matches. It will.
Offline
FSK clock measuring can be a little tricky with the grid alone. But the others are easy.(you can measure distance by settings the two markers - left an right click, no grid necessary)
I like to test out this method with left/right click, to get correct clock. Pls advise instruction where to read
Not sure the binary question... Just shift the bits in a circle (beginning to end) till it matches. It will.
true it does
from Scott: 111111111001011010000000000000000010000110110000111110001100010000001111001100000000000000000000
from me: 100000000000000000000
111111111001011010000000000000000010000110110000111110001100010000001111001
I guess both clones would emulate correct and work, even with these shifted data bits ... But how come???? Because it is the way it works!!!
Last edited by ntk (2015-07-07 05:05:12)
Offline
Pages: 1