Reading CryptoRF

Delphis · 2017-07-21 22:12:25

Hi,

I am trying to read what are believed to be CryptoRF tags. ( http://nfc-tools.org/index.php?title=Nfc-cryptorf )

In attempting to use the proxmark3 to scan for these I'm coming up confused as how to do it. I have found lots of resources on scanning for 14a modulations. Does the proxmark3 even support scanning for them? When I do 'hf snoop', a light on the PM3 goes red. It appears to read something and stops recording with 'Trigger kicked!', but it's only captured 1 byte. I repeated this trying the 'skip triggers' parameter but didn't get ANY data then.

When trying to do 'hf 14b snoop', the command states buffers are readied, but no lights light on the PM3. Performing the same operations to (hopefully) get the tag and reader to communicate yields no data is captured. Doing 'hf list 14b' says TraceLen=0.

I know this is a developer forum and not a user help forum but I'm confused if I'm even using the device properly.

In that URL I listed earlier, that's what I'm trying to get. A trace of the communication between the reader and the tag. I just don't know how to get there.

iceman · 2017-07-22 13:08:55

there not much usage nor documentation for CryptoRF. Its an very old system. Are you sure your are dealing with a CryptoRF?

Delphis · 2017-08-03 19:11:58

I missed this reply.. I thought I had subscribed to it.. hmm.

Yes, I have it on good authority (research performed by a third party) that the system is Atmel CryptoMemory/CryptoRF based.

Given the information here: http://www.atmel.com/products/security-ics/secure-rf/default.aspx .. it appears it should be 'ISO 14443 Type 13.56MHz RFID'. Doing hf 14b snoop *should* yield data, should it not? I don't know if I'm just messing things up with the proxmark since I'm new to it or if it is shielded in some way. I am working on trying to set up a testbed to eliminate possibility of shielding but I thought I'd ask to see if anyone has tried to eavesdrop this style of communication before.

marshmellow · 2017-08-03 20:09:32

from my limited research a while ago it seems the cryptoRF only supports a bitrate of 106kbit.

the pm3 currently doesn't support this mode.
piwi has issued a pull request (here) to fix the fpga to allow this mode but then it will need to be implemented into the armsrc code.

i intend to look into it but have not found time yet.

Delphis · 2017-08-03 21:30:26

Ah, ok. Thank you. That does shed more light on it. If there's anything I can do to help development, please let me know. I'm a C programmer of many years. While the Verilog stuff isn't anything I'm familiar with, I'd be happy to help where I can.

marshmellow · 2017-08-04 04:57:18

Thankfully I think piwi did the verilog work, we just need to implement it on the armsrc and client side.

But his FPGA changes still need to be tested to make sure they don't affect other 14b cmds or 15693 or iclass. Then I can accept his pull request.
Then we can implement bitrate options for the 14b cmds, using the new half and quarter bit rate fpga signal options.

I'd certainly welcome help.

Delphis · 2017-08-04 15:05:41

Certainly testing I'm happy to help with. I have a Linux box connected to the Pm3 currently and can compile the source. You can email directly if you'd like to instruct me what to help with.

iceman · 2017-08-04 18:53:49

I don't think piwi's PR is about 106 kHz functionality since we had that before. I belive that it was the 424 kHz and 212 kHz modes returned into the FPGA but as @marshmellow42 mentioned there is no implementation of it on device-side to deal with it yet. The software uarts don't handle these optional speeds.

Sadly not to many contributors are able to code a UART.

Speaking of CryptoRF, the vinglocks also use it for personel-cards etc. Which would be nice to support with the PM3.

marshmellow · 2017-08-04 18:56:29

not quite. piwi's pull request re enables quarter bitrate mode. (was removed a while ago while fixing other bugs..)
we already had 818, and 424, but with quarter mode we can quarter 818 to get 212 and quarter 424 to get 106.

marshmellow · 2017-08-04 18:58:52

also the uart should already exist (14b...) just need to adjust the speeds i.e. minor mode (add the quarter mode flag)(i think)...

Delphis · 2017-08-04 19:41:01

I am a bit confused as to how the PM3 doesn't support scanning for CryptoRF when the wiki page on nfc tools says the trace was obtained with a 'Proxmark RFID Research Tool' , what I assume to be a Proxmark3 .. Or was it supported in the past on older models?

It's probably a moot point but I'm just curious.

marshmellow · 2017-08-04 19:47:35

A lot of code for the pm3 has never been shared...

That said it may be possible an old version may have partially supported it.

iceman · 2017-08-04 21:11:02

there is no command set in current pm3 impl that support cryptorf to my knowledge.
That Roel might have done it 2009, doesn't mean that code ever got into pm3 master.

The cryptorf commands / protocol is also quite unknown.

@marshmellow42 so the quarter idea was to divide it by four.. That would explain things.

Delphis · 2017-08-14 22:01:21

It's ok if there's no command set in pm3, it's obtaining a trace of the handshake at the right bitrate that I'm most interested in. Once I can get that I can decode the key and use it with an atmel development kit.

iceman · 2017-08-15 07:14:03

The trace on nfc-tools wiki is a HF 14b snoop output. So building the needed commands for easy access to tag shouldn't be too hard. You would need to identify all commands, maybe you have a full datasheet aswell..

Delphis · 2017-08-15 15:01:16

That's good to have it confirmed what that output looks like, thank you. I guessed at trying the 14b snoop. I have an atmel development kit for accessing cryptorf cards, just need that key

Delphis · 2017-09-26 16:18:55

What branch of the client sourcecode can I check out in order to help get this working? You mentioned piwi has an updated firmware? Is that also checked in?

iceman · 2017-09-26 16:42:14

Just go for the latest sourcecode of pm3 offical...

Delphis · 2017-09-26 18:20:10

Yea, I see it all in master now. I was able to check out and compile the latest code and re-flashed the proxmark firmware from the elf image that was compiled.

How does one change the bitrate for the snoop function? I saw in cmdhf14b.c on line 265 that there is mention of 106kbit bandwidth. Is it trying to auto-detect it? I'm curious to see what I can do to get this working.

I have the high frequency antenna near the atmel reader. Doing 'hf search' yields no matches when placing a cryptorf chip (sample) on the reader and seeing it do its handshake in Atmel CM configuration program. Proxmark is running via a Linux machine and the atmel kit is connected to a Windows 10 computer. hf 14b snoop still yields no data.

marshmellow · 2017-09-26 18:22:15

After a snoop you need to issue a hf list 14b cmd

Delphis · 2017-09-26 21:16:20

I swear the PM3 used to have the red light lit when issuing a 'hd 14b snoop' command. Now it does not. Here's what I get:

root@ubuntu-test:/usr/src/proxmark3# ./client/proxmark3 /dev/ttyACM0
Prox/RFID mark3 RFID instrument
bootrom: master/v2.3 2016-09-19 20:28:38
os: master/v3.0.1-84-gc19f26b-suspect 2017-09-26 15:15:17
LF FPGA image built for 2s30vq100 on 2015/03/06 at 07:38:04
HF FPGA image built for 2s30vq100 on 2017/07/13 at 08:44:13

uC: AT91SAM7S512 Rev B
Embedded Processor: ARM7TDMI
Nonvolatile Program Memory Size: 512K bytes. Used: 199527 bytes (38%). Free: 324761 bytes (62%).
Second Nonvolatile Program Memory Size: None
Internal SRAM Size: 64K bytes
Architecture Identifier: AT91SAM7Sxx Series
Nonvolatile Program Memory Type: Embedded Flash Memory
proxmark3> hf 14b snoop
#db# Snooping buffers initialized:
#db#   Trace: 39232 bytes
#db#   Reader -> tag: 256 bytes
#db#   tag -> Reader: 256 bytes
#db#   DMA: 256 bytes
proxmark3> hf list 14b cmd
Waiting for a response from the proxmark...
Don't forget to cancel its operation first by pressing on the button

(Offering the tag to the reader a couple of times) .. then pressing the button on the PM3.

#db# cancelled
#db# Snoop statistics:
#db#   Max behind by: 11
#db#   Uart State: 0
#db#   Uart ByteCnt: 0
#db#   Uart ByteCntMax: 256
#db#   Trace length: 0
Recorded Activity (TraceLen = 0 bytes)

Start = Start of Start Bit, End = End of last modulation. Src = Source of Transfer
iso14443a - All times are in carrier periods (1/13.56Mhz)
iClass    - Timings are not as accurate

      Start |        End | Src | Data (! denotes parity error)                                   | CRC | Annotation         |
------------|------------|-----|-----------------------------------------------------------------|-----|--------------------|

I'm not sure what i'm doing wrong here.

marshmellow · 2017-09-27 00:21:15

You aren't doing anything wrong. Try the 15693 snoop and 14a snoop.

And if all else fails try hf snoop and data plot the result.

Delphis · 2017-09-27 21:14:05

Not having much luck getting anything. 'hw tune' says the antenna hf is ok.

Measuring antenna characteristics, please wait.........
# LF antenna:  0.00 V @   125.00 kHz
# LF antenna:  0.00 V @   134.00 kHz
# LF optimal:  0.28 V @   122.45 kHz
# HF antenna:  9.75 V @    13.56 MHz
# Your LF antenna is unusable.
proxmark3>

Pic of setup is here: https://imgur.com/iqEBWAk

Tried 'hf 15 record', it exits immediately with:

proxmark3> hf 15 record
#db# fin record
proxmark3>

Tried 'hf 14a snoop', the yellow light on the PM3 comes on. Offer the tag to the reader a few times and then press the button on the PM3:

proxmark3> hf 14a snoop
#db# cancelled by button
#db# COMMAND FINISHED
#db# maxDataLen=1, Uart.state=0, Uart.len=0
#db# traceLen=0, Uart.output[0]=00000000
proxmark3>

I also tried just 'hf snoop', but with 'hf snoop 20 10' since without those arguments it presents a 'Trigger kicked!' message and stops recording. I'm not sure what is triggering it though. The red light DOES come on though (it doesn't on an hf 14a or 14b snoop), so that seems promising?

After performing a few reads of the tag on the reader, I press the button on the PM3:

proxmark3> hf snoop 20 10
#db# Buffer cleared (40000 bytes)
#db# Skipping first 20 sample pairs, Skipping 10 triggers.

#db# HF Snoop end
proxmark3> data hexsamples
00 00 00 00 00 00 00 00
proxmark3> data plot
proxmark3>

Hmm.

marshmellow · 2017-09-28 04:41:12

data samples would be needed instead of the hexsamples
The hf snoop should produce a small section of the transmission on the grid/plot. Does it?

Also the reader would trigger it alone. Hold the card on the pm3 antenna, run the cmd and then present the card and pm3 antenna to the reader.

Delphis · 2017-10-04 20:12:54

You sir, are a genius. It was the positioning of things.

I now have the cryptoRF card attached to the pm3 antenna (via some scotch tape) and can present it to the reader. NOW I am getting data.

'hf 14b snoop' kept running and captured a whole log of information of the handshake including strings that I recognize from the nfc-tools post. I'm going to do some tests on setting the encryption on this test card and seeing if I can deduce it via processing the traces in the program I have.

marshmellow · 2017-10-04 21:21:57

Do post the log in a pastebin.com and share the link. Maybe we can at least make the pm3 talk to the card a little.

piwi · 2017-10-05 11:29:33

Some remarks on 848kHz/424kHz/212kHz/106kHz: the respective FPGA options change the Subcarrier frequency, not the Bitrate. For hf 14b the subcarrier frequency is 848kHz, for hf 15 it is 424kHz. 14b (and 14a) bitrate is always assumed to be 106kHz which is supported by all tags and readers. The ARM is too slow to decode higher bitrates - at least when you need to do it real time, i.e. when snooping.

PM3 as reader or as tag is always possible, because reader and tag agree on their commonly supported bitrate (which would be 106kHz) during the card select procedure.

However when snooping, the PM3 has no influence on the bitrate and if snooped communication has a higher bitrate it will not be recognized, except the first few bytes (card select) which are always 106kHz.

Last edited by piwi (2017-10-05 11:30:21)

piwi · 2017-10-05 12:59:22

Delphis wrote:

I now have the cryptoRF card attached to the pm3 antenna (via some scotch tape) and can present it to the reader. NOW I am getting data.

Sensitivity with hf 14b and hf 15 commands indeed is an issue. marshmellow is currently testing a new FPGA code which increases the hf 14b and hf 15 sensitivity.

Last edited by piwi (2017-10-05 12:59:43)

Delphis · 2017-10-05 15:28:28

@piwi .. To reply to both of your comments. Thank you for that insight. That's very good to know.

@marshmellow .. I will indeed post the traces. I'm documenting what I'm seeing in the trace compared to what is seen in the atmel cryptomemory configuration tool. So far I have not been able to eavesdrop the setup of encryption to a user data page.

marshmellow · 2017-10-23 20:12:38

i just would like to start with seeing the initial protocol handshake. (get uid type stuff).. as i am still unable to get even that info from my cryptoRF tag and i am wondering if it has a custom command to initiate the handshake.

if you could capture and post a trace with the first cmds transferred back and forth it would be helpful in getting started on cryptoRF PM3 commands.

Thanks.

Delphis · 2017-10-23 21:22:31

Yes, my bad for not responding sooner. It's not my only part of the job so I admit to being busy with other things. I've not been able to eavesdrop the crypto setup part.

Here's the log I have: https://pastebin.com/rS3sURcZ ... CryptoRF tag was offered to the reader, handshake completed, removed and repeated a couple more times. Proxmark3 is connected to a Linux machine

The string '11 00 00 85 19' seems to be some sort of 'keepalive' response, at least it seems to be with this Atmel development kit reader.

Most lines are preceeded by a '16 00'.

ff ff ff ff ff ff ff 22 is the first 8 bytes of the CryptoMem header. To help illustrate that, I have these two images taken from the Atmel CM configuration studio.

Data: https://imgbox.com/z7hafHnW

Labels: https://imgbox.com/v4yRgUPv

Last edited by Delphis (2017-10-23 21:22:50)

marshmellow · 2017-10-23 21:45:09

Thanks!

but is it just me or are you only seeing the TAG communication and not the Reader side?

Delphis · 2017-10-23 21:58:08

I wondered about that too. I didn't know what I was supposed to be seeing. I did see some lines with 'Rdr' 0 .. with the parity fail, which is probably when I removed the chip+antenna away from the reader.

I tried writing some data to the chip, and it appeared to do it, but no information about it is seen on the proxmark trace.

I started the trace when the chip and antenna were resting on the reader. Refreshed the memory, wrote the 'pwdwrite0' field to be 'ff f4 ff' (it was 'ff f5 ff' before) and refreshed again.

https://pastebin.com/stcDqptU

Actions initiated by the reader do not seem to be captured in the trace, only the replies back from the tag.

I don't know if I need to reorient things?

marshmellow · 2017-10-23 22:27:31

it appears you aren't able to pick up the reader well enough for the pm3 to demod it.
see if you can reposition some - trial and error type...

Delphis · 2017-10-24 14:59:19

I tried having the CryptoRF chip on top of the antenna so the antenna is between the chip and the reader. Still only getting Tag responses.

It would be unlikely there's a slightly different frequency to transmit rather than receive wouldn't it? In looking at the reader I'm not seeing anything designating a frequency, but there's small gold coloured part that might be it. On the target reader I am attempting to eavesdrop on (not the atmel development one) I can clearly see a 13.56Mhz oscillator

marshmellow · 2017-10-24 15:13:32

the reader should be much more powerful than the tag, so maybe it is too strong. try putting a little distance between the reader and the antenna. first 1cm then 2 etc.

if, with many many positional tries it still doesn't work then there may be a bug, or the reader field is in some way not what the pm3 expects.

Delphis · 2017-10-24 15:26:59

Ah.. good ideas. Got this:

https://pastebin.com/gw8kTmxx

Noticeable in the trace is a 'Rdr: 06' 'INITIATE' as I was hovering around the 1cm level. Any more and it was showing lots of reader errors and cryptomem errors in the atmel studio program. Sometimes 'f8' or '00' was picked up from the reader, but they appear to be bogus. I can try and see if I can set up the rig to keep that distance consistently and try different operations

marshmellow · 2017-10-24 16:10:40

Can you post one with the bunch of reader errors?

Maybe the reader doesn't follow the 14b crc

Delphis · 2017-10-24 19:34:14

They should be in the same trace as I posted.

Delphis · 2017-10-24 19:48:08

I am able to save trace files after doing 'data samples 40000', it says it's copied data in. However, doing 'data printdemodbuffer' doesn't seem to yield anything and the trace files I have no idea how to read. I can email them if it's helpful in figuring out what's going on?

marshmellow · 2017-10-24 20:26:23

the data commands are pretty useless in HF (unless you are attempting hf snoop), as you are not grabbing raw antenna signal with most hf commands.

an hf snoop with a trace may help but it is hard with hf to get enough samples to tell much. but if you share one maybe someone will see something..

when i have a little time i'll take a quick look at the reader demod code under the 14b snoop, but i'm not sure what i'll be looking for...

maybe @piwi would have some ideas on next steps.

Proxmark3 community

Announcement

#1 2017-07-21 22:12:25

Reading CryptoRF

#2 2017-07-22 13:08:55

Re: Reading CryptoRF

#3 2017-08-03 19:11:58

Re: Reading CryptoRF

#4 2017-08-03 20:09:32

Re: Reading CryptoRF

#5 2017-08-03 21:30:26

Re: Reading CryptoRF

#6 2017-08-04 04:57:18

Re: Reading CryptoRF

#7 2017-08-04 15:05:41

Re: Reading CryptoRF

#8 2017-08-04 18:53:49

Re: Reading CryptoRF

#9 2017-08-04 18:56:29

Re: Reading CryptoRF

#10 2017-08-04 18:58:52

Re: Reading CryptoRF

#11 2017-08-04 19:41:01

Re: Reading CryptoRF

#12 2017-08-04 19:47:35

Re: Reading CryptoRF

#13 2017-08-04 21:11:02

Re: Reading CryptoRF

#14 2017-08-14 22:01:21

Re: Reading CryptoRF

#15 2017-08-15 07:14:03

Re: Reading CryptoRF

#16 2017-08-15 15:01:16

Re: Reading CryptoRF

#17 2017-09-26 16:18:55

Re: Reading CryptoRF

#18 2017-09-26 16:42:14

Re: Reading CryptoRF

#19 2017-09-26 18:20:10

Re: Reading CryptoRF

#20 2017-09-26 18:22:15

Re: Reading CryptoRF

#21 2017-09-26 21:16:20

Re: Reading CryptoRF

#22 2017-09-27 00:21:15

Re: Reading CryptoRF

#23 2017-09-27 21:14:05

Re: Reading CryptoRF

#24 2017-09-28 04:41:12

Re: Reading CryptoRF

#25 2017-10-04 20:12:54

Re: Reading CryptoRF

#26 2017-10-04 21:21:57

Re: Reading CryptoRF

#27 2017-10-05 11:29:33

Re: Reading CryptoRF

#28 2017-10-05 12:59:22

Re: Reading CryptoRF

#29 2017-10-05 15:28:28

Re: Reading CryptoRF

#30 2017-10-23 20:12:38

Re: Reading CryptoRF

#31 2017-10-23 21:22:31

Re: Reading CryptoRF

#32 2017-10-23 21:45:09

Re: Reading CryptoRF

#33 2017-10-23 21:58:08

Re: Reading CryptoRF

#34 2017-10-23 22:27:31

Re: Reading CryptoRF

#35 2017-10-24 14:59:19

Re: Reading CryptoRF

#36 2017-10-24 15:13:32

Re: Reading CryptoRF

#37 2017-10-24 15:26:59

Re: Reading CryptoRF

#38 2017-10-24 16:10:40

Re: Reading CryptoRF

#39 2017-10-24 19:34:14

Re: Reading CryptoRF