Sending commands to LF tags

adam@algroup.co.uk · 2009-07-03 14:37:58

I'd like to send a 'wakeup' command to a LF tag which I can do by just switching the reader field on and off to create command 'pulses'... I was going to try using OPEN_COIL() and SHORT_COIL() while in FPGA_LF_READER_USE_125_KHZ mode, but I'm concerned that might blow it up!

Is that safe or is there some other way to do it?

edo512 · 2009-07-03 14:51:24

adam@algroup.co.uk wrote:

I'd like to send a 'wakeup' command to a LF tag which I can do by just switching the reader field on and off to create command 'pulses'... I was going to try using OPEN_COIL() and SHORT_COIL() while in FPGA_LF_READER_USE_125_KHZ mode, but I'm concerned that might blow it up!
Is that safe or is there some other way to do it?

Could this be related to this ?

adam@algroup.co.uk · 2009-07-03 15:45:49

Yes, that's similar, but unlike the TI (if I've understood that thread correctly), we don't need to listen while the power is shut off... We just need to 'blip' the power to send a command and then read as normal, so I'm still wondering if it's safe to short the coil while it is powered...?

adam@algroup.co.uk · 2009-07-04 13:54:57

OK, I can do it by switching the FPGA off altogether, using FPGA_MAJOR_MODE_OFF, but I think that will limit the resolution due to startup/recovery time etc. I will implement the command using that method for now but hopefully we can come up with a faster way to switch the field on and off..

With a 150us gap and a 600us burst, test trace looks like this:

proxmark3> locommand 150 600
> locommand 150 600

LF field modulation

adam@algroup.co.uk · 2009-07-04 17:48:20

Don't you love it when a plan comes together?

I've just committed the new code, which supports the 'locomread' command:

locomread -- <off period> <'0' period> <'1' period> <command> ['h'] -- Modulate LF reader field to send command before read (all periods in microseconds) (option 'h' for 134)

and here's a Hitag2 being woken up:

proxmark3> locomread 80 100 200 11000
> locomread 80 100 200 11000

Hitag2 wakeup

edo512 · 2009-07-05 09:29:50

Very nice, thanks! By the way, what's the use case for this command? From your posts I assume some tags need this type of pulses in order to start replying? Can you give us more details on how/when this command can/should be used?

Ed

adam@algroup.co.uk · 2009-07-05 10:04:19

As per the example, the Hitag2 will not send it's UID unless it is instructed to do so, but it's is the only one I've come across so far that needs that kind of 'wakeup', but I'm sure there must be others.... At some point I'll sniff the startup traffic from the ACG LF reader which knows how to access a variety of tags and that will give us a clue...

We can also use this method to send other commands such as "READ BLOCK" or "WRITE BLOCK" etc.

edo512 · 2009-07-05 11:40:28

Cool! I should receive R/W EM Marin tags these next few days, so the appplies to those tags.

I'd like to implement LF sniffing on the PM3, but FPGA updates would be required. I have the instructions, lack the know-how...

From J. Westhues:

LF sniffing would not be very hard, though Verilog tweaks would indeed be required. It would work essentially the same as LF read, except that the PWR_LO signal is held steady low. And the module is clocked off CROSS_LO (the received carrier) instead of a carrier that we generate ourselves.

adam@algroup.co.uk · 2009-07-05 17:46:13

Yes, LF sniffing would be very nice... I will look into what we need to get a build environment going for the FPGA...

In the meantime, here's another example case for LF commands:

This is an EM4x50 being read by an ACG reader. It starts giving out data as soon as it's in the field, but the reader then sends a command:

em4x50 wakeup

It runs at 64 clocks/bit, so a bit period is 512us, and we can see that there is an anomalous period of 800+us just before the reader commands:

em4x50 wakeup

According to the datasheet, this is the 'Listen Window', and is transmitted between each output section to allow the reader to send commands. If the reader transmits during this window the chip will start listening. Transmitting at any other time is not allowed. The windows is 320 clock cycles, so 2.56ms, and the ACG started transmitting after about 900us.

Reader commands are constructed by powering off during the 1st half of the bit period for a '0' and staying powered up for a '1'. The tag continues to damp it's coil for the first half of each period, providing clock synchronisation.

Here is a zero:

em4x50 wakeup

and here is a one:

em4x50 wakeup

Decoding the full message (by eye), we seem to have:

00000010100001001011011110011001000001001000001010111000

Which breaks down as follows...

The first two bits are '00' to signal 'Receive Mode', followed by a command and data as 8 bit words with trailing (even) parity bit.

00 <- Receive Mode ('RM')
00001010 0 <- Command
00100101 1 <- Data
01111001 1 <- Data
00100000 1 <- Data
00100000 1 <- Data

01011100 0 <- ???
^
Parity

The possible commands are:

00000001 1 Login
00010001 0 Write Password
00010010 0 Write Word
00001010 0 Selective Read Mode
10000000 1 Reset

So what we seem to have is a 'Selective Read Mode' command followed by 32 bits of address data (plus parity), transmitted MSB first, followed by a mystery word which shouldn't be there according to the documentation!

The address to read is sent as 'First Word to Read' in byte 4 and 'Last Word to Read' byte 3, which in this case are both '00100000', or decimal 32, which corresponds to the Device Serial Number in memory location 32. Bytes 1 & 2 are ignored.

Without sending this command, the data you will receive will be whatever is stored in the memory of the chip that it has been programmed to transmit, which may or may not be the UID. The only way to reliably retrieve the UID is by doing a Selective Read as above...

samy · 2009-07-06 05:26:25

Nice.

What's the difference between LF sniffing and LF reading (loread)? I assume LF sniffing won't send voltage out so it will just act as a reader and not a power source, but why is it a big deal if it's also a power source? I assume there's a good reason, I just don't know..

adam@algroup.co.uk · 2009-07-06 10:08:28

When sniffing we want to be entirely passive and just listen to the conversation between a reader and a tag. If we power up the sniffer coil we will interfere with the modulation of the genuine reader and/or tag by providing power when the reader has dropped it's power to send a signal.

We also need to demodulate both sides of the conversation. The first example (Hitag2) uses Pulse Width Modulation, but this one (EM4x50) uses Pulse Pause Modulation, so I guess I'm going to have to tweak the code to allow modulation scheme to be specified...

There is a nice diagram in this paper which shows the different available modulation schemes:

http://comp.uark.edu/~drt/pubs/2005/rfi … 051208.pdf (Figure 4)

BTW, I uploaded the datasheet for the EM4x50.

d18c7db · 2009-07-07 22:41:15

adam@algroup.co.uk wrote:

I will look into what we need to get a build environment going for the FPGA...

Speaking as someone who's set this up and got it working it doesn't seem to be as easy as to share as the ARM cross compiler due to the huge bloatedness of the package. You need to download the free Xilinx webpack which is just over 2Gb then install it which then occupies about 5Gb across 85000 files and 4400 directories. Ouch!

I suspect it might be feasible to trim some of the fat by targetting it for a specific FPGA family and deleting unneccessary files but I wouldn't have the time to do it or even know what might break in the process.

samy · 2009-07-07 23:06:40

I'm downloading it now and I don't even run windows, I have to run and install it in Parallels

adam@algroup.co.uk · 2009-07-08 00:00:32

Heh. I went down the path of just downloading the standalone tools, not the whole design package since we probably only need the compiler components... But I still ran out of disk...

Well at least my lappy will get a hard disk upgrade out of the deal...

adam@algroup.co.uk · 2009-07-13 21:26:05

OK, so laptop hard disk upgrade completed I tried installing various tools... Bottom line is the standalone SDK and the standalone tools don't cut it. You need to get the big ISE Webpack thingy:

http://www.xilinx.com/tools/webpack.htm

Strangely, it says "Download for Windows & Linux", but I could only find the Windows version...

Anyway, having downloaded and installed it, if I run the "go.bat" script in the fpga subdirectory, I get:

An invalid target speed "-6" was given in the -p option

Looking at the batch file, the exact option specified was '-p xc2s30-6vq100', and the -p option is described here:

http://www.xilinx.com/itp/xilinx7/books … l#wp234890

Anyone got any clue as to what the correct value should be? Or if anyone has working batch files can they update the repo or post them here so we can get it going?

Thanks...

d18c7db · 2009-07-13 22:39:53

I just run the go.bat on my system on the latest SVN checked out tree and it works fine for me, no errors. I seem to be running version 10.3 downloaded late last year. Not sure if that's relevant. The file not found error is normal as the batch is trying to delete some pre-existing remnants without checking.

Microsoft Windows XP [Version 5.1.2600]
(C) Copyright 1985-2001 Microsoft Corp.

P:\Misc\ProxSpaceWork\proxmark\cockpit>cd ..\fpga

P:\Misc\ProxSpaceWork\proxmark\fpga>go.bat
The system cannot find the file specified.
Could Not Find P:\Misc\ProxSpaceWork\proxmark\fpga\fpga.ngc
Release 10.1 - xst K.31 (nt)
Copyright (c) 1995-2008 Xilinx, Inc.  All rights reserved.
-->

The only minor issue with the batch file is that it fails on the last line at the perl script trying to convert the .rbt file. This is due to perl expecting a unix text file but getting a DOS file (CL/LF). I manually convert the file to UNIX type and rerun the last command manually. I'm not a perl guy so not sure if there's a workaround for this.

Try xc2s30-5vq100 and see if that works for you but you should probably match the timing specs for the FPGA you have as that's supposed to affect how the internal optimizations work when generating FPGA code. The xc2s30-6vq100 is a valid part number and the ISE should just like it dammit.

That link you posted suggests you can specify the the part in different formats, ie device only, device-package, device-package-speed, etc. Try omitting the speed alltogother or different options/combinations. The device is xc2s30 the speed is 5 or 6 and the package is vq100 so play with these. Or maybe it wants the extra hyphen like xc2s30-6-vq100... bizzare.

Last edited by d18c7db (2009-07-13 23:45:45)

adam@algroup.co.uk · 2009-07-18 18:46:22

OK, seems the new version doesn't support Spartan II:

Device Obsolescence
The following devices are not supported in ISE Design Suite 11:
• Virtex
• Virtex-E
• Virtex-II
• Virtex-II Pro
• Spartan-II
• Spartan-IIE
• 9500XV
All families, except 9500XV, are still being manufactured with no plans to discontinue. ISE
Design Suite 10.1 SP3 is available for download to support the discontinued devices.

So I guess we need to download 10.1 SP3 instead. <sigh>

Proxmark3 community

Announcement

#1 2009-07-03 14:37:58

Sending commands to LF tags

#2 2009-07-03 14:51:24

Re: Sending commands to LF tags

#3 2009-07-03 15:45:49

Re: Sending commands to LF tags

#4 2009-07-04 13:54:57

Re: Sending commands to LF tags

#5 2009-07-04 17:48:20

Re: Sending commands to LF tags

#6 2009-07-05 09:29:50

Re: Sending commands to LF tags

#7 2009-07-05 10:04:19

Re: Sending commands to LF tags

#8 2009-07-05 11:40:28

Re: Sending commands to LF tags

#9 2009-07-05 17:46:13

Re: Sending commands to LF tags

#10 2009-07-06 05:26:25

Re: Sending commands to LF tags

#11 2009-07-06 10:08:28

Re: Sending commands to LF tags

#12 2009-07-07 22:41:15

Re: Sending commands to LF tags

#13 2009-07-07 23:06:40

Re: Sending commands to LF tags

#14 2009-07-08 00:00:32

Re: Sending commands to LF tags

#15 2009-07-13 21:26:05

Re: Sending commands to LF tags

#16 2009-07-13 22:39:53

Re: Sending commands to LF tags

#17 2009-07-18 18:46:22

Re: Sending commands to LF tags

Board footer