Proxmark3 community

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.

Announcement

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.

#1 2019-04-25 00:14:58

rgeyer
Contributor
Registered: 2019-04-21
Posts: 2

Help reading a known automotive transponder tag. Antenna issue(s)?

Hello,

I purchased an Elechouse Proxmark3 Easy, and I've updated it to the latest firmware from github.

proxmark3> hw version
Prox/RFID mark3 RFID instrument
bootrom: /-suspect 2019-04-20 21:36:00
os: /-suspect 2019-04-20 21:36:01
fpga_lf.bit built for 2s30vq100 on 2015/03/06 at 07:38:04
fpga_hf.bit built for 2s30vq100 on 2018/09/12 at 15:18:46
SmartCard Slot: not available

uC: AT91SAM7S256 Rev D
Embedded Processor: ARM7TDMI
Nonvolatile Program Memory Size: 256K bytes. Used: 197222 bytes (75). Free: 64922 bytes (25).
Second Nonvolatile Program Memory Size: None
Internal SRAM Size: 64K bytes
Architecture Identifier: AT91SAM7Sxx Series
Nonvolatile Program Memory Type: Embedded Flash Memory

I have been able to read all of the test tags which came with the device, and all of them are easily discoverable with an `lf search` or `hf search`. I've also been able to grab pages of data from them, so I'm confident the hardware and software are working.

My goal is to read a transponder chip found in the key of my 2005 Subaru. I actually know a tremendous amount about the hardware involved.

The chip is a 4D62 transponder.  I can not find a datasheet for this, but to the best of my knowledge it is *not* a HiTag chip, and is labeled as "80 bit". It's unclear to me if that means it's 80 bits of encryption (seems unlikely) or that it stores 80 bits of data.

I also know that the reader chip is a TMS3705, which tells me that I'm looking for an FSK signal at 134.2kHz for low bits, and 123 kHz for high bits.

That said, I can not seem to get consistent reads, or a reasonable DB gain from the chip. This happens whether I use a 125kHz frequency:

proxmark3> lf config L t 5
#db# LF Sampling config:
#db#   [q] divisor:           95
#db#   [b] bps:               8
#db#   [d] decimation:        1
#db#   [a] averaging:         1
#db#   [t] trigger threshold: 5
proxmark3> lf read
#db# LF Sampling config:
#db#   [q] divisor:           95
#db#   [b] bps:               8
#db#   [d] decimation:        1
#db#   [a] averaging:         1
#db#   [t] trigger threshold: 5
#db# Done, saved 40000 out of 40000 seen samples at 8 bits/sample
#db# buffer samples: 7a 77 77 78 76 77 78 77 ...
Reading 39999 bytes from device memory

Data fetched
Samples @ 8 bits/smpl, decimation 1:1
proxmark3> lf read
#db# LF Sampling config:
#db#   [q] divisor:           95
#db#   [b] bps:               8
#db#   [d] decimation:        1
#db#   [a] averaging:         1
#db#   [t] trigger threshold: 5
#db# Done, saved 40000 out of 40000 seen samples at 8 bits/sample
#db# buffer samples: 77 77 75 76 77 75 78 77 ...
Reading 39999 bytes from device memory

Data fetched
Samples @ 8 bits/smpl, decimation 1:1

Trace
lf125read.png

Or if I use a 134kHz frequency;

proxmark3> lf config H t 5
#db# LF Sampling config:
#db#   [q] divisor:           88
#db#   [b] bps:               8
#db#   [d] decimation:        1
#db#   [a] averaging:         1
#db#   [t] trigger threshold: 5
proxmark3> lf read
#db# LF Sampling config:
#db#   [q] divisor:           88
#db#   [b] bps:               8
#db#   [d] decimation:        1
#db#   [a] averaging:         1
#db#   [t] trigger threshold: 5
#db# Done, saved 40000 out of 40000 seen samples at 8 bits/sample
#db# buffer samples: 85 82 86 83 83 81 83 7f ...
Reading 39999 bytes from device memory

Data fetched
Samples @ 8 bits/smpl, decimation 1:1
proxmark3> lf read
#db# LF Sampling config:
#db#   [q] divisor:           88
#db#   [b] bps:               8
#db#   [d] decimation:        1
#db#   [a] averaging:         1
#db#   [t] trigger threshold: 5
#db# Done, saved 40000 out of 40000 seen samples at 8 bits/sample
#db# buffer samples: 85 82 84 82 81 83 81 82 ...
Reading 39999 bytes from device memory

Data fetched
Samples @ 8 bits/smpl, decimation 1:1

Trace
lf134read.png

Placing the tag on the LF antenna *does* have an impact on the power, but it is very small.

proxmark3> hw tune

Measuring antenna characteristics, please wait.........
# LF antenna: 25.85 V @   125.00 kHz
# LF antenna: 21.17 V @   134.00 kHz
# LF optimal: 25.85 V @   125.00 kHz
# HF antenna: 24.64 V @    13.56 MHz
Displaying LF tuning graph. Divisor 89 is 134khz, 95 is 125khz.



proxmark3> hw tune

Measuring antenna characteristics, please wait.........
# LF antenna: 23.65 V @   125.00 kHz
# LF antenna: 21.86 V @   134.00 kHz
# LF optimal: 24.61 V @   127.66 kHz
# HF antenna: 24.67 V @    13.56 MHz
Displaying LF tuning graph. Divisor 89 is 134khz, 95 is 125khz.

That said, I also tried to snoop the signal, since I have the working production system, and I got something that seems more like a "real" read interaction, but I can't seem to demod it into anything useful. The actual read does seem to happen at the beginning of the trace, in the selected part, before the high gain "noise".
Trace
lfsnoop.png

Any guidance?

Why does the tag not draw much power when doing an hw tune? Should it draw more?

What can I do to improve my "snoop"?

I'm a fairly competent software engineer, and I've been dabbling with electronics for a while now as well, but RF is most certainly still a "dark art" from my perspective, so I suspect my answers lie in understanding some RF/RFID fundamentals. I'm happy to RTFM, but I may need some help being pointed in the right direction for me to do my own research.

Thanks in advance!

Offline

#2 2019-05-12 11:44:25

mwalker
Moderator
Registered: 2019-05-11
Posts: 318

Re: Help reading a known automotive transponder tag. Antenna issue(s)?

I am still learning, so more then happy to be corrected.

This is more a high level from they way i understand and what I would expect.

You have a "tag" and a "reader"
When the tag is in the field of the readers antenna, then it will get energized and once the tag has enough power, it will power on.
At this point I would expect one of two things to happen.
a) the tag responds with an answer (e.g. tag ID)
b) the tag would wait for a command from the reader.

So given that we don't know, the sniffer/snoop is a good starting point. 
While I have been playing with the snoop, i found you get different results depending on how everything is setup.
e.g. The best way would be to have the PM antenna coil between the tag and the reader, ensuring the PM coil will pickup the power levels of the hand shake.  if I placed the card on the PM then the reader on the card, i get much worse readings then when I put the card to the side of the pm antenna and the reader above antenna, for me this is ok as I was trying to log the "programmer" and did not really care what the tag sent back.

If you have two devices then you may find that you do get a weak signal and a strong signal, so I would not rule out anything at this point.

On the tech side, this is how i think it works.
When the tag is running it will "draw" more power in a structured way.  this draw will be seen by the reader and thus sees the data.

Now the fun part... how to understand the data you get.
Without knowing how it is encoded, you can start by trying to work out things bit by bit.
e.g.
Whats the sampling rate of the pm snoop.  This will tell you the time between reads/read values
Next looking at the zoomed in graph, look at the cycles, think SINE wave 0 - High - 0 - Low - 0, this should show you the clock pulses.
While the data may "hide" some clock pulses a little you should be able to work out the clock rate (bps) from the number of samples and the data "sine wave".

Next I would try to work out where the signal starts and ends. So you could snoop a few different tag reads.  then compare.
I would expect you will get some bits that are the same at the start (prior to any random/encrypted data).

Have a read of the encoding methods e.g ASK, PSK, FSK.  It will take a while but stay with it.... sooner or later, you will start to see data in the snoop (it may have errors, but we just need to get some data).

e.g. The T5577 card data shows up in "short pulse = 0" and "long pulse = 1"  where long should be about 2 times the length of the 0 pulse.


If you feel like you are getting nowhere, I would fall back to working with knowns
e.g. Get a card you can control or know and a reader for it.  then read the card with the PM. then snoop the read between the real reader and the card and snoop the traffic.  the look at the snoop data.  In this setup you know the data you are looking for.

this is what I am doing atm with the t5577 cards.  I created an em41xx tag on the T5577, then read that with a reader and snooped, then worked on the decoding.  As I know what I should find, you start to see it.

Offline

Board footer

Powered by FluxBB