Simulating an active tag?

samy · 2016-12-24 04:27:27

Hey friends,

I'm working on reversing a proprietary (AFAIK) active LF signal (134kHz). Datasheet and all other data about the IC is private. I can read it just fine via `lf read` and it's an ASK signal, URL to image of signal (don't think it's quite manchester): https://www.dropbox.com/s/jvhqyo0btdwki3o/Screenshot%202016-12-18%2017.06.31.png?dl=0

I'd like to replay this, or demodulate and simulate it. I've tried using `data rawdemod [ar/nr]` and `lf sim`, `lf simask`, and `lf cmdread`, but not sure any are quite doing what I want. Any thoughts or suggested attack plan?

Thanks!
-samy

samy · 2016-12-24 04:29:50

Here's the .trace if interested: https://samy.pl/o/pm31.trace

Last edited by samy (2016-12-27 19:12:03)

iceman · 2016-12-24 11:29:50

Are you sure that trace is ASK?

I can decode it with "data raw nr" but not with AM/AR/AB at all.

samy · 2016-12-24 11:38:50

Hey iceman, I assumed the plot was of the signal in the time domain with amplitude on the y axis -- is that not the case? I also did attempt `data raw nr`, followed by `lf sim` but doesn't look like it's quite simulating the same thing (when I add a separate carrier). I also tried `lf cmdread`.

The goal is to, at the very least, replay an *active* LF tag without any additional demodulation if possible. Should `data raw nr` followed by `lf cmdread` perform that?

ntk · 2016-12-24 12:28:31

Merry Christmas to you all.

I downloaded from post#2, for me it looks like only noise, graph amplitude only max=-17 min=-11

Last edited by ntk (2016-12-24 12:29:30)

samy · 2016-12-24 12:31:20

Merry Christmas!

You need to zoom out (up arrow I believe) to see the signal

ntk · 2016-12-24 12:50:37

ah, thanks I can see it now. I assume you have to trim it to get the useful part

samy · 2016-12-24 13:01:59

I've normally been trimming like so and working with the rest

data rtrim 2060
data ltrim 1400

Though just converting the other noise to no active field would be nice as I'd like to simulate the LF comms as closely as possible, the field I captured was only active for that period of time then would stop.

marshmellow · 2016-12-24 16:52:56

lf read - data samples - lf sim

will attempt to simulate the graph buffer. But it has to have very strong signal to work. You signal is ask but there is no obvious clock or there are imperfections in the capture.

I haven't had a chance to look at the trace yet.

iceman · 2016-12-24 17:55:29

Merry X-mas!
Im using my docker container, no plot window, so I didn't have a look the signal

Yes, the plot should be in time domain.
According to @OP, the tag is 134khz, which if I got it correct needs to set the config to deal with 134.
ie. lf config H

Not sure if "lf config" values is used in "lf sim".

lf read
data samples
lf config H
lf sim

[edit]
looking at the code, it does seem to only be able simulate in 125kHz

iceman · 2016-12-25 15:24:19

Lets see, I've added some code for the simulation code on device, to read the 'lf config' values in icemanfork.

@OP, if you test it out and see if it actually does simulate in the correct freqs?

samy · 2016-12-25 20:50:23

Hey iceman, merry x-mas! I'm looking through the code as well but haven't found any particular place where `lf sim` specifies 125kHz -- do you have a specific function to check? I'll try your fork.

Also, is there a way for the sim to be active? The signal I'm trying to emulate is active LF with data, where it seems lf sim isn't active.

iceman · 2016-12-25 21:32:46

U can use the new "lf config H" command to set 134, in my fork with latest commit.
the code is in armsrc/lfops.c SimulateTagLowFrequency function.

Question is how a reader treats an active tag? Normally the reader sends out and the drop in voltage indicates a tag is in the reader field. But an active tag is always sending? no can't be. With its own powersource it can send longer distance.
So it should act as a passive tag in regards of when it sends its signal.

Maybe @marshmellow et al can fill in with details.

samy · 2016-12-25 21:42:29

Cool, will try that and report back!

The "reader" in this configuration is actually passive and is woken up by the "active tag", and the active tag sends some power followed by a short message via ASK (at least that's how it appears). The active tag has a power source and is sending the message about once a second.

Here's a picture of the plot of `lf snoop` of the active tag without the reader nearby (as the reader actually has no effect on the signal, anyway):
https://www.dropbox.com/s/m831z5nsay4eu14/Screenshot%202016-12-25%2012.44.57.png?dl=0

samy · 2016-12-25 23:36:53

Okay @iceman, I've uploaded your latest fork's arm fullimage.elf onto PM3 and ran:

load data activelf.trace
lf config H
data raw nr 8
lf sim

I used data raw nr 8 (tested between 2-32) as that seems to produce the most closely related data as the trace but I'm not sure it's correct. Here you can see the signal I snoop'd and attempting to demod:
trace

Because the tag must be "active" (I'm trying to trigger the reader), I applied an external 134kHz reader (Phidegts 1023_1 reader) on top of the PM3 to produce the signal, and for PM3 to simulate via that tag. It does look like it's modulating but hard to tell if it's accurate (I have the "reader" in the field as well but the reader isn't detecting the specific signal it's looking for so something is not right). I also connected a coil to my scope to see if PM3 was at least modulating the signal and it is (PM3 antenna+Phidgets signal+"reader"+scope coil):
simulated signal

You'll notice it says 125kHz, but it's actually quickly switching between 125kHz and 142.8kHz (avg 133.9kHz). If I zoom in on just the signal from the Phidgets reader, it becomes 133.7kHz.

I'm not sure if I can demodulate the AM signal via the scope (Rigol DS2072A-S) but you can see a repeating sequence in the top section.

Preferably I'd have PM3 produce the active signal itself and modulate it to the trace (*without* demodulating anything from the trace, just a raw replay would be nice).

marshmellow · 2016-12-26 02:10:11

Afaik, LF active tags are just the same as normal LF tags just with a battery to increase read range. But there may be other types.

I still haven't been able to get to my laptop to get a closer look. Sorry.

marshmellow · 2016-12-26 02:12:35

The signal appears to be ask with no known encoding, so nr decoding would be closest. Unfortunately there is no current nr sim so we'd have to fool the existing cmds to get closer.

iceman · 2016-12-26 10:28:37

So, I understand what @OP is saying, is that the 'lf sim' changes worked. *great*

And as @marshmellow mentions an active tag has bigger reading distance, it shouldnt trigger the reader with its active signal.
The tag should send its signal when it detects a reader field.. as its current imp.

What more information do you have about this tag/system?

marshmellow · 2016-12-26 14:53:43

Unfortunately the pm3 doesn't have an analog recording or replay ability. It has to play digital signal, 1s and 0s. So it has to be demoded in some way.

Now one way would be to assign a 1 or 0 to every sample and play it back. This is what lf sim by itself tries. But the wave has to be strong to have it assign the 1s and 0s correctly. Your signal is strong but has strange short bursts of 1s that likely won't work.

The issue with the demod is you have either a fluctuating clock (like fsk) or a clock of rf/13.5 (or 14) which isn't possible to demod with the commands as they exist.

This looks like an unknown modulation.

We might be able to come up with the binary to reproduce the wave but we will have another problem in the long off periods between the data transmissions.

samy · 2016-12-26 20:41:50

Here is a picture of an `lf read` rather than an `lf snoop` of the signal (the end data changes with each signal, similar to a timestamp), although again note that there is only ever one side of the conversation and it's always from the "tag". Technically the reader is woken up by this (it has its own power source so it just triggers an interrupt), verifies some data in the LF signal, but never sends anything back (over LF).
Screenshot%202016-12-26%2011.39.52.png

We could switch the vernacular and say the "reader" is active and wakes up the "tag", but the reader never reads anything, it only transmits both power and information, and it's the other side that takes the info and processes it.

And here's the `lf read` on top of the `lf snoop`:
Screenshot%202016-12-26%2011.44.05.png

marshmellow · 2016-12-26 21:16:33

is there a printed number on the card or does the reader output a card#? i might be able to interpret the waves if i have something to go on. then i might be able to clean up the signal so we know how to reproduce it with the pm3.

iceman · 2016-12-26 21:30:32

The trace from 'lf read' in the pic above would be nice to have.

samy · 2016-12-26 21:37:20

Hey @marshmellow, unfortunately both sides are TI chips that have no public datasheets and likely require an NDA with TI.

Here's the "receiver" side (both sides have a power source), I believe it's the TI TMS37143:
Screenshot%202016-12-26%2012.35.19.png

Here are four traces, two lf read's and two lf snoop's:
https://samy.pl/tilf/read2
https://samy.pl/tilf/read3
https://samy.pl/tilf/snoop1
https://samy.pl/tilf/snoop4

You'll need to trim some of the data so zoom out (I kept long traces to potentially reproduce the long "waits" before/after.

marshmellow · 2016-12-26 21:37:22

you could also try to trim your trace leaving 40 or so samples at the beginning and end. then do a `data dirth 115 110` then `lf sim` and see if that triggers the reader.

marshmellow · 2016-12-26 21:39:45

also could try the same without trimming

marshmellow · 2016-12-26 21:42:41

if you do a `lf read` `data samples 40000` do you ever see a second set of data repeating?

marshmellow · 2016-12-26 21:45:55

about the chip number, thanks that might help.. but also do you know what the data on the chip is supposed to read? like a specific card ID number.. basically what the reader reads off the chip?

there was no printed Card number?

samy · 2016-12-26 22:02:30

There's no printed number, it's not a card but rather a proprietary passive entry system for a vehicle. The "active tag" is the car and the "reader" is the keyfob. There are some similar systems from NXP that are also closed with no public datasheets. The tag (car) is supposed to send a challenge and the keyfob picks up the LF challenge and sends a UHF response. I'm using a separate SDR to pick up the UHF, which I cleanly get if I actually place the keyfob in the real field (not the phidgets+pm3 field), but my current goal is to replay the car message to the key at a later time.

I have been able to successfully "transfer" the LF message over distance via wire, but that's live and I'm trying to store the challenge to play to the keyfob at a later time.

I tested with the `data dirth 115 110` with no luck. I'll try to do a longer lf read and report back (when I took a pocket scope to the field, it did seem to tx at around 1Hz)

Last edited by samy (2016-12-26 22:03:40)

iceman · 2016-12-26 22:08:47

You can find the datasheet without nda...
seems like an auth-resp which needs to be fullfilled before tag "opens" up for dialog.

iceman · 2016-12-26 22:10:48

pm3 --> da dirt 115 100
Applying Up Threshold: 115, Down Threshold: 100

pm3 --> da ra ar

Using Clock:8, Invert:0, Bits Found:98
# Errors during Demoding (shown as 7 in bit stream): 6
ASK/Raw - Clock: 8 - Decoded bitstream:
0700100110110110
1101101101101101
1011011011011011
0110110110700100
7010011070010700
1001101101107001
0
pm3 --> da print x
DemodBuffer: 19B6DB6DB6DB6D1436319B639
pm3 -->

You get ask/raw out of the trace following @marshmellow

iceman · 2016-12-26 22:15:31

134khz, HDX,
reader: 100%AM PPM
tag: FSK

marshmellow · 2016-12-26 22:26:31

problem with the demod is the data clock is not 8 but rather 13.5 (or changing). (changing might indicate FSK)

i would speculate the binary of this transmission is close to: 000000000000000000001100100010011000001100 or decimal# 3286540.

but without a modulation spec it is just a guess.

samy · 2016-12-26 22:32:44

Here are two more `lf snoop` and `lf read`s with 40000 samples -- you can see two occur in a row in each of them:
https://samy.pl/tilf/read-2x.trace
https://samy.pl/tilf/read2-2x.trace
https://samy.pl/tilf/snoop-2x.trace
https://samy.pl/tilf/snoop2-2x.trace

samy · 2016-12-26 22:37:40

New piece of data -- if I have the actual tag (fob) in the real field AND have the Phidgets 134kHz reader active as well (even almost 1meter away), the reader does NOT activate (respond via UHF). I assume that's because it's two competing LF fields, but wanted to mention it anyway. I'm still not sure if using that active field (Phidgets reader) with PM3 can simulate it the same way as we see in the `lf snoop`s.

marshmellow · 2016-12-26 22:59:14

interesting that the repeating transmission isn't always the same length.

in one trace the transmission is 30748 samples long and the other it is 30646 samples long.

but that does give us some lengths of transmissions to try. you could try trimming to one of those lengths and `lf sim` then let it try for a while. (the pm3 transmission is typically weak and may take several repeats before the reader sees it)

marshmellow · 2016-12-26 23:02:27

the snoops are the same data you are seeing in the reads, just garbled and weak. and yes, two competing lf fields will often confuse a lf transponder and nothing will get read.

marshmellow · 2016-12-26 23:04:05

@iceman, you found the datasheet for the reader chip?

samy · 2016-12-26 23:14:26

@marshmellow Interesting. I've tried trimming and `lf sim` after the `da` commands with the active field and just left it simulating for a minute (I suspect it should have repeated 20-30 times) but no response from the reader.

An interesting thing about the lf snoops is that although they appear garbled/weak, they are actually pretty consistent with each other. Not sure if that's important.

Oh sweet, not a full datasheet but at least some basic characteristics on the chip on this trusty Russian forum: http://kazus.ru/datasheets/pdf-data/468 … 37145.html

Last edited by samy (2016-12-26 23:14:42)

marshmellow · 2016-12-26 23:25:57

i cleaned the capture a bit.. can you load this trace:
http://pastebin.com/7M9TyEJx

and attempt a `lf sim` with it?

samy · 2016-12-26 23:48:31

Thank you both for the help btw, I really appreciate it!

@marshmellow I've taken your cleaned up trace, tried an `lf sim` and left it running for about a minute with an external 134kHz field and no response from the reader. I've also tried `da dirt 115 100` and then `lf sim` and waited a minute, no luck.

`da ra ar` hangs so I've trimmed further and tried sim'ing that, and also tried `da ra nr` and sim, still no luck.

One concern is that the reader may actually expect the tag to *stop* transmitting between the 'pauses'. I'm wondering if it may be easier to try to retransmit this signal with a custom circuit or IC, or a new function to do the ASK transmission, like a combo of lf cmdread and lf sim. It's been many years since I've been in the codebase, starting to look again...

marshmellow · 2016-12-27 00:03:38

samy wrote:

One concern is that the reader may actually expect the tag to *stop* transmitting between the 'pauses'. I'm wondering if it may be easier to try to retransmit this signal with a custom circuit or IC, or a new function to do the ASK transmission, like a combo of lf cmdread and lf sim. It's been many years since I've been in the codebase, starting to look again...

probably would be something to try soon.

you could also try the following command to see if the reader reacts:
lf cmd d 80 z 7 o 6 c 10101010101010101010101010101010101010000101000101010001010000101010101000010100

or

lf cmd d 80 z 7 o 7 c 10101010101010101010101010101010101010000101000101010001010000101010101000010100

i'm not sure we have the waveform correct yet, but i think we are getting closer

(i'm also not sure if the lf cmd can take that long a string...)

samy · 2016-12-27 00:23:39

Tried both about 20 times each, no go. Looking at the source of cmdread now to see if we can modify it to support periods of no signal.

samy · 2016-12-27 00:29:13

I also tried the commands with the `H` option, no go.

marshmellow · 2016-12-27 00:32:28

Just a sanity check, are you able to simulate a normal tag successfully? Like an em410x?

samy · 2016-12-27 00:51:33

Good question. This is odd.

`hw tune` looks good:

# LF antenna: 15.26 V @   125.00 kHz
# LF antenna: 25.85 V @   134.00 kHz
# LF optimal: 46.34 V @   139.53 kHz
# HF antenna:  9.32 V @    13.56 MHz
Displaying LF tuning graph. Divisor 89 is 134khz, 95 is 125khz.

`lf em em410xwatch` reads an EM410 card just fine.

`lf em em410xsim 12deadbeef` does NOT get read by my Phidgets reader. I have no idea why...in fact, it looks like I originally implemented the simulator, and tested with the same exact PM3 and Phidgets reader many years ago. I tried both iceman's latest firmware and the pm3 git's latest firmware. Now I'm confused because I'm pretty sure I did this same test a few days ago, let me test with scope.

samy · 2016-12-27 01:06:36

Okay, I was able to simulate an HID tag with no problem via `lf hid sim 12deadbeef` and read it via an HID reader (37 bit card. FC = 0, CC = 0, 44bit HEX = 12DEADBEEF), so the PM3 is simulating properly (at least with 125kHz tags). I still don't know why the EM410x simulation isn't working.

samy · 2016-12-27 01:23:27

Just to note, the Phidgets reader and PM3 both properly read an EM410x tag, but PM3 simulating the tag does not get read by the Phidgets reader. Not sure how important this is, I'm guessing just a bug in the EM sim since HID sim works fine.

Last edited by samy (2016-12-27 01:23:43)

samy · 2016-12-27 07:35:21

Okay, so I took a big lead acid battery, inverter and my Rigol scope down to get a scope capture of the active LF field. I started to export the trace but unfortunately the battery died so the CSV only caught the beginning of the signal (the long preamble), but I did get screenshots of the full thing and a few zooms.

12MB CSV export (gzipped): http://samy.pl/tilf/rfactive.csv.gz

Full signal

Very beginning of the signal

A middle 'high' of the signal

Pic of the CSV:

Last edited by samy (2016-12-27 07:51:20)

marshmellow · 2016-12-27 16:10:24

i sniffed a pm3 simulating the trace i made with another pm3 and below is the result.

http://pastebin.com/Fdhtp717

it looks almost identical to your original trace.
but it is weak even with my 40v antennas.

(now in theory since the simulation of a tag is supposed to be detecting and running off the reader's carrier wave we shouldn't have to worry about frequency settings... ? maybe?)

your captures look great. unfortunately my knowledge gets fuzzy when we get this low level. i believe the simulation has to dampen or slow the carrier frequency down by modulating for the proper durations. (which i believe we are attempting with our simulation.)

but as we see from your captures it is definitely an FSK signal. is there anyway to separate out the carrier?

marshmellow · 2016-12-27 16:15:24

btw, i also tested the lf em410x em410xsim 12deadbeef and it works on some readers and not others. the signal from the pm3 appears to have difficulty holding the modulations (shorting the coil appears worse than the open coil) and part of the carrier bleeds through. this affects some readers more than others.

Proxmark3 community

Announcement

#1 2016-12-24 04:27:27

Simulating an active tag?

#2 2016-12-24 04:29:50

Re: Simulating an active tag?

#3 2016-12-24 11:29:50

Re: Simulating an active tag?

#4 2016-12-24 11:38:50

Re: Simulating an active tag?

#5 2016-12-24 12:28:31

Re: Simulating an active tag?

#6 2016-12-24 12:31:20

Re: Simulating an active tag?

#7 2016-12-24 12:50:37

Re: Simulating an active tag?

#8 2016-12-24 13:01:59

Re: Simulating an active tag?

#9 2016-12-24 16:52:56

Re: Simulating an active tag?

#10 2016-12-24 17:55:29

Re: Simulating an active tag?

#11 2016-12-25 15:24:19

Re: Simulating an active tag?

#12 2016-12-25 20:50:23

Re: Simulating an active tag?

#13 2016-12-25 21:32:46

Re: Simulating an active tag?

#14 2016-12-25 21:42:29

Re: Simulating an active tag?

#15 2016-12-25 23:36:53

Re: Simulating an active tag?

#16 2016-12-26 02:10:11

Re: Simulating an active tag?

#17 2016-12-26 02:12:35

Re: Simulating an active tag?

#18 2016-12-26 10:28:37

Re: Simulating an active tag?

#19 2016-12-26 14:53:43

Re: Simulating an active tag?

#20 2016-12-26 20:41:50

Re: Simulating an active tag?

#21 2016-12-26 21:16:33

Re: Simulating an active tag?

#22 2016-12-26 21:30:32

Re: Simulating an active tag?

#23 2016-12-26 21:37:20

Re: Simulating an active tag?

#24 2016-12-26 21:37:22

Re: Simulating an active tag?

#25 2016-12-26 21:39:45

Re: Simulating an active tag?

#26 2016-12-26 21:42:41

Re: Simulating an active tag?

#27 2016-12-26 21:45:55

Re: Simulating an active tag?

#28 2016-12-26 22:02:30

Re: Simulating an active tag?

#29 2016-12-26 22:08:47

Re: Simulating an active tag?

#30 2016-12-26 22:10:48

Re: Simulating an active tag?

#31 2016-12-26 22:15:31

Re: Simulating an active tag?

#32 2016-12-26 22:26:31

Re: Simulating an active tag?

#33 2016-12-26 22:32:44

Re: Simulating an active tag?

#34 2016-12-26 22:37:40

Re: Simulating an active tag?

#35 2016-12-26 22:59:14

Re: Simulating an active tag?

#36 2016-12-26 23:02:27

Re: Simulating an active tag?

#37 2016-12-26 23:04:05

Re: Simulating an active tag?

#38 2016-12-26 23:14:26

Re: Simulating an active tag?

#39 2016-12-26 23:25:57

Re: Simulating an active tag?