REQ: 14b snoop of a calypso communication

iceman · 2015-07-19 23:10:29

A non-initialised navigo tag answers after (REQB / ATTRIB)

S-block: 0xC2 ( = abort )

pm3 --> hf 14b raw -c -p -s c2
REQB   : 50 26 58 4B 0C 00 00 00 00 00 71 81 CA D7
ATTRIB : 00 78 F0
received 3 octets
[LEN 3] C2 [66 15] OK

   -6993 |      -6993 | Rdr |05  00  08  39  73                                               |  ok | REQB
   -6993 |      -6993 | Tag |50  26  58  4b  0c  00  00  00  00  00  71  81  ca  d7           |  ok |
   -6993 |      -6993 | Rdr |1d  26  58  4b  0c  00  08  01  00  1d  c3                       |  ok | ATTRIB
   -6993 |      -6993 | Tag |00  78  f0                                                       |  ok |
   -6993 |      -6993 | Rdr |c2  66  15                                                       |  ok | ?
   -6993 |      -6993 | Tag |c2  66  15                                                       |  ok |
 -->

Now, which ISO 7816-4 and specificly i-blocks does it answer to before? Which stuff should be there? (AIDs? MasterAid 3F00?)

Minus8 · 2015-07-22 22:26:45

Hi Iceman,

I compile your fork and flash my pm3
But I can't communicate with my navigo

I've tried with marshmellow42 fork as well but had the same "error".

Any idea ? Maybe the antenna ?

[== Undefined ==]
pm3 --> hw version
Prox/RFID mark3 RFID instrument
bootrom: icemanmaster/v1.1.0-823-gf445df4-suspect 2015-07-22 20:18:33
os: icemanmaster/v1.1.0-823-gf445df4-suspect 2015-07-22 20:18:43
LF FPGA image built for 2s30vq100 on 2015/03/06 at 07:38:04
HF FPGA image built for 2s30vq100 on 2015/06/22 at 21:47:54

uC: AT91SAM7S256 Rev B
Embedded Processor: ARM7TDMI
Nonvolatile Program Memory Size: 256K bytes. Used: 186143 bytes (71%). Free: 76001 bytes (29%).
Second Nonvolatile Program Memory Size: None
Internal SRAM Size: 64K bytes
Architecture Identifier: AT91SAM7Sxx Series
Nonvolatile Program Memory Type: Embedded Flash Memory

pm3 --> hw tune

Measuring antenna characteristics, please wait...#db# DownloadFPGA(len: 42096) ......#db# DownloadFPGA(len: 42096)
.
# LF antenna:  0.00 V @   125.00 kHz
# LF antenna:  0.00 V @   134.00 kHz
# LF optimal:  0.00 V @ 12000.00 kHz
# HF antenna:  8.58 V @    13.56 MHz
# Your LF antenna is unusable.

pm3 --> hf search

#db# max behindby = 3, samples = 600002, gotFrame = 0, Demod.len = 0, Demod.sumI  = 0, Demod.sumQ = 0
#db# max behindby = 3, samples = 600002, gotFrame = 0, Demod.len = 0, Demod.sumI  = 0, Demod.sumQ = 0
#db# max behindby = 3, samples = 600002, gotFrame = 0, Demod.len = 0, Demod.sumI = 0, Demod.sumQ = 0
#db# max behindby = 3, samples = 600002, gotFrame = 0, Demod.len = 0, Demod.sumI = 0, Demod.sumQ = 0
#db# max behindby = 3, samples = 600002, gotFrame = 0, Demod.len = 0, Demod.sumI = 0, Demod.sumQ = 0

no known/supported 13.56 MHz tags found

pm3 --> hf 14b reader
#db# max behindby = 3, samples = 600002, gotFrame = 0, Demod.len = 0, Demod.sumI = 0, Demod.sumQ = 0
#db# max behindby = 3, samples = 600002, gotFrame = 0, Demod.len = 0, Demod.sumI = 0, Demod.sumQ = 0
#db# max behindby = 3, samples = 600002, gotFrame = 0, Demod.len = 0, Demod.sumI = 0, Demod.sumQ = 0
#db# max behindby = 3, samples = 600002, gotFrame = 0, Demod.len = 0, Demod.sumI = 0, Demod.sumQ = 0
#db# max behindby = 3, samples = 600002, gotFrame = 0, Demod.len = 0, Demod.sumI = 0, Demod.sumQ = 0
no 14443B tag found

pm3 --> hf 14b raw -c -p -s c2
#db# max behindby = 3, samples = 600002, gotFrame = 0, Demod.len = 0, Demod.sumI = 0, Demod.sumQ = 0

iceman · 2015-07-22 22:46:31

hm, I wouldn't use the "hf search"...

First, the tag is very antenna position sensitive. Is that antenna value with tag or without tag on antenna?

I usually run "hf 14b raw -c -p 05 00 08" a couple of times until I get an answer from the tag.
And I have to re-position the tag a couple of times.

Then, you can run the "hf 14b reader" or "hf 14b info"

iceman · 2015-07-22 22:51:50

And I just pushed a lot of merged changes, so my fork is up-to-date with PM3 master.

marshmellow · 2015-07-22 22:54:00

Hmmm. hf search just runs hf 14b reader... .
I haven't seen that error since piwi fixed 14b.
Is it possible the tag only understands a faster bitrate?

Minus8 · 2015-07-22 23:00:10

The hw tune was without the card

With the card about 1 cm close to the antenna :

# HF antenna:  7.59 V @    13.56 MHz
# Your LF antenna is unusable.
# Your HF antenna is marginal.

The "good" position is really close to the antenna or 2-3 cm over ?

iceman · 2015-07-22 23:18:22

You have to experiment with the distance. For me, its about 1cm. but where over the antenna is also picky.

The debugstatement, is mine to be able to see if the antenna is correct. I use it to find the right spot to put my tag.
As you see it above, it tells me that the tag doesn't have enough power to answer.

Here below, was me trying to read the navigo tag. first try wrong place, second was good.

pm3 --> hf 14b raw -c -p 05 00 08
#db# max behindby = 3, samples = 600002, gotFrame = 0, Demod.len = 0, Demod.sumI = 0, Demod.sumQ = 0
received 0 octets
pm3 --> hf 14b raw -c -p 05 00 08
received 14 octets
[LEN 14] 50 26 58 4B 0C 00 00 00 00 00 71 81 [CA D7] OK

My antenna drops about 4v, 1cm distance. I can get it to drop 10v by putting the tag really close to the antenna.
But then it can never read the signal. Why is that? the changes in the radiofield isn't strong enough that close or?

Minus8 · 2015-07-22 23:38:58

After turning my old (but still active) navigo upside down, I found something interesting:

I've 2 navigo, 1 old and 1 new (both with subscription):

The new one reply but the old one not:

pm3 --> hf 14b raw -c -p 05 00 08
received 14 octets
[LEN 14] 50 27 0F 5C D3 00 00 00 00 00 71 81 [28 97] OK
pm3 --> hf 14b i

14443-3b tag found:
           UID: 27 0F 5C D3
      App Data: 00 00 00 00
      Protocol: 00 71 81
      Bit Rate: 106 kbit/s only PICC <-> PCD
Max Frame Size: 128
 Protocol Type: Protocol is compliant with ISO/IEC 14443-4
Frame Wait Int: 8
 App Data Code: Application is Proprietary
 Frame Options: NAD is not supported
 Frame Options: CID is supported
Max Buf Length: 0 (MBLI) not supported
pm3 -->

@Iceman, could you explain to me quickly the "05 00 08" command ?
Maybe the old navigo use a different command to be poked ?

iceman · 2015-07-22 23:59:58

the "05 00 08" is a REQB, and it will tell all 14443-b tags near the reader to wake up and answer, basically.

The B standard has been implemented by the manufactures differently. So you have about three different ways of getting a tag to wake up. Marshmellow implemented all of them in the "hf 14b reader"..

I heard somewhere around 2010, that Navigo changed abit. So if your tag is older, then it might be a 14B' tag,... which we dont know how to talk to yet. PPL need access to tags for that

Your newer tag should be answering to (after you done the wake up 05 00 08 sometimes )

hf 14b raw -c -p -s 02 94 a4 00 00 02 20 00

Minus8 · 2015-07-23 00:06:53

Thanks for the explanation

Yes, I've a reply to the SELECT FILE

pm3 --> hf 14b raw -c -p -s 02 94 a4 00 00 02 20 00
REQB   : 50 27 0F 5C D3 00 00 00 00 00 71 81 28 97
ATTRIB : 00 78 F0
received 30 octets
[LEN 30] 02 85 17 00 02 00 00 00 12 12 00 00 01 03 01 01 00 15 15 15 00 00 00 00 00 00 90 00 [FA 62] OK

iceman · 2015-07-23 00:13:57

Perfect! Thats more than I get... but my tag doesn't have a subscription on it yet.
Would be cool to sniff it when it gets written.. since 14b communication isn't encrypted by default.. (however the Navigo data is encrypted )

iceman · 2015-07-23 00:16:09

If you read the source on this project, you should be able to read much from your tag.

ref https://github.com/pterjan/cardpeek-navigo

Minus8 · 2015-07-23 00:25:13

I'm reading it right now !

Asper gave some useful information too in a previous post :

CLA for Navigo seems to be 94.
Other data in the scripts suggests the "folder" tree structure:
{ "ICC",              "/0002",      "file" },
  { "ID",               "/0003",      "file" },
  { "Ticketing",        "/2000",      "folder" },
  { "Environment",      "/2000/2001", "file" },
  { "Holder",           "/2000/2002", "file" }, 
  { "Event logs",       "/2000/2010", "file" },
  { "Contracts",        "/2000/2020", "file" },
  { "Counters",         "/2000/202A", "file" },
  { "Counters",         "/2000/202B", "file" },
  { "Counters",         "/2000/202C", "file" },
  { "Counters",         "/2000/202D", "file" },
  { "Counters",         "/2000/202E", "file" },
  { "Counters",         "/2000/202F", "file" },
  { "Counters",         "/2000/2060", "file" },
  { "Counters",         "/2000/2061", "file" },
  { "Counters",         "/2000/2062", "file" },
  { "Special events",   "/2000/2040", "file" },
  { "Contract list",    "/2000/2050", "file" },
  { "Counters",         "/2000/2069", "file" },
  { "Holder Extended",  "/3F1C",      "file" }
ex. "folder" /2000 contains many subfolders: /2000/2001 contains environment data, /2000/2002 Holder data etc. They are usually called "records" and contain specific data defined by the "standard" (Calypso, etc).

I'll try to snoop the communication of both card (old and new) during the validation in a tramway this WE.
hf 14b snoop should be enough to get all the data ?

iceman · 2015-07-23 00:32:18

hf 14b snoop work.. the whole 14b commands needs some further testing.

And yeah, all "good" info comes from that project I linked before.

I also got a snoop trace from someone who had a omni-reader and ran cardpeek against his navigo.

asper · 2015-07-23 13:41:05

You probably will not get a good snoop with your old tag (if it is a real 14b') but if you can test a post results this will be great!

Minus8 · 2015-07-27 14:10:13

I try to snoop a Navigo (new version) with hf 14b snoop.

This is my fist attempt to snoop a card so ... maybe I did something wrong
But I suppose there is a buffer over flow somewhere

pm3 --> 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
#db# blew circular buffer! behindBy=233
#db# Snoop statistics:
#db#   Max behind by: 233
#db#   Uart State: 1
#db#   Uart ByteCnt: 0
#db#   Uart ByteCntMax: 256
#db#   Trace length: 0
pm3 --> hf list 7816
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         |
------------|------------|-----|-----------------------------------------------------------------|-----|--------------------|
pm3 --> hf list 14b
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         |
------------|------------|-----|-----------------------------------------------------------------|-----|--------------------|

pm3 --> hw ver
Prox/RFID mark3 RFID instrument
bootrom: icemanmaster/v1.1.0-823-gf445df4-suspect 2015-07-22 20:18:33
os: icemanmaster/v1.1.0-823-gf445df4-suspect 2015-07-22 20:18:43
LF FPGA image built for 2s30vq100 on 2015/03/06 at 07:38:04
HF FPGA image built for 2s30vq100 on 2015/06/22 at 21:47:54

uC: AT91SAM7S256 Rev B
Embedded Processor: ARM7TDMI
Nonvolatile Program Memory Size: 256K bytes. Used: 186143 bytes (71%). Free: 76001 bytes (29%).
Second Nonvolatile Program Memory Size: None
Internal SRAM Size: 64K bytes
Architecture Identifier: AT91SAM7Sxx Series
Nonvolatile Program Memory Type: Embedded Flash Memory

iceman · 2015-07-27 16:02:50

Hm, that could be mine fault, I was experimenting with:

https://github.com/iceman1001/proxmark3 … 3b.c#L1277

change it back to whats in the comment and try again? (compile & flash)

Minus8 · 2015-07-27 16:26:48

From

			// is this | 0x01 the error?   & 0xfe  in https://github.com/Proxmark/proxmark3/issues/103
			if(Handle14443bSamplesDemod(ci | 0x01, cq | 0x01)) {

To

if(Handle14443bSamplesDemod(ci & 0xfe, cq & 0xfe)) {

?

iceman · 2015-07-27 16:56:55

yes.

Minus8 · 2015-07-27 18:20:28

Not the same error this time but quite similar:

Qt: Untested Windows version 6.2 detected!
Prox/RFID mark3 RFID instrument
bootrom: icemanmaster/v1.1.0-827-g14e1862-dirty-suspect 2015-07-27 14:45:45
os: icemanmaster/v1.1.0-827-g14e1862-dirty-suspect 2015-07-27 14:45:58
LF FPGA image built for 2s30vq100 on 2015/03/06 at 07:38:04
HF FPGA image built for 2s30vq100 on 2015/06/22 at 21:47:54

uC: AT91SAM7S256 Rev B
Embedded Processor: ARM7TDMI
Nonvolatile Program Memory Size: 256K bytes. Used: 187611 bytes (72%). Free: 74533 bytes (28%)
Second Nonvolatile Program Memory Size: None
Internal SRAM Size: 64K bytes
Architecture Identifier: AT91SAM7Sxx Series
Nonvolatile Program Memory Type: Embedded Flash Memory
pm3 --> 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
#db# blew circular buffer! behindBy=235
#db# Snoop statistics:
#db#   Max behind by: 235
#db#   Uart State: 1
#db#   Uart ByteCnt: 0
#db#   Uart ByteCntMax: 256
#db#   Trace length: 0

pm3 --> hf list 7816
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         |
------------|------------|-----|-----------------------------------------------------------------|-----|--------------------|
pm3 --> hf list 14b
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         |
------------|------------|-----|-----------------------------------------------------------------|-----|--------------------|

iceman · 2015-07-27 21:01:14

hm, you didn't get a snoop at all.

However I just tried snooping and my setup is 2 PM3's and one tag. Only once I got a partial trace of 4bytes. Not much to rely on.
Piwi and Marshmellow was fixing the "hf 14b snoop/sim" earlier. I don't know its good enough.

marshmellow · 2015-07-27 23:06:31

I'd suggest trying the pm3 master trunk and seeing if you get a similar error. The other thing is, you need a strong antenna for snoop.

iceman · 2015-07-28 19:05:06

When I snoop I notice that my "snooping" antenna seems to suck up all the power. thus leaves the tag with less power I guess..
Not really my field of expertice.
Or is it the 14b mode not sending with all drivers?

GNSPS · 2016-01-15 00:08:11

Hi guys! I'm gonna revive this old thread to see if any of you guys has progressed any further on this.

I have a calypso card from Portugal called VIVA Viagem.

I've been searching through public contracts in the government websites and I'm pretty sure these cards have an ASK CTS512B chip and most probably are 14B instead of B'.

However I'm running the nightly from iceman's repo from just last night and still my cards won't answer to neither '14b reader' nor the raw sequence that is working for the Navigo tags. ('14b raw -p -s 05 00 08')

Just checking if you guys have gotten ahold of any card kind of like this.

iceman · 2016-01-15 17:58:18

there is another wakeup for 14b tags. 06 00 I think. But the "hf 14b reader" should be able to send both.

GNSPS · 2016-01-15 21:20:41

Just to let you know that I've peeked into the 'hf 14b reader' function code and it doesn't seem to try to send the "06 00" routine. Going to update it right away.

Also, on Mac OS X, the makefile in your repo isn't working properly because of the Qt version check and subsequent adjustment of flags, so I modified that, too.

Should I make a pull request with these updates or just leave it be?

GNSPS · 2016-01-15 21:32:33

Also just tried "06 00" and it doesn't work either.

This card is a paper one. Wondering if the antenna doesn't provide enough power to read from it or if the card is 14B'.

Is the wakeup command a specification of the chip? Or is it implementation dependent?

iceman · 2016-01-15 22:00:57

When I look in cmdhf14b.c in the function HF14B_ST_Reader, there is a wake up command 0x06 0x00.
All different wakeup commands is called from within the "hf 14b reader", so if it doesn't answer its not a 14B

--sidenote, off topic
About compiling on Mac OS X, don't know since I don't have one of those environments up to try and compile it on.
For Ubunutu 14, you can add the flag UBUNTU_1404_QT4 = 1 with the make command maybe that works for you.
You are welcome to make a PR to my fork, but I can't verify these changes.

GNSPS · 2016-01-16 14:40:42

I just missed that function. Silly me.

The card just doesn't answer to any of the wakeup commands.

I've recently got another card that isn't a paper one is a plastic one. And that doesn't answer either so it most probably isn't about the antenna's power but rather the wakeup command.

Today I'm gonna try and snoop the comms between the card and the subway readers and see what I can get out of it.

kwx · 2016-02-08 17:25:05

The navigo uses a custom wakeup call. From that point, everything should be as per ISO spec.
I'm more than happy to go and do snoops as required. I've not done it before, so @iceman, let me know what tests you want run, and I'll go do em

iceman · 2016-02-08 17:52:37

custom wakeupcall? hm, then by all means go a get me some sniffed traffic between tag and reader so I can finally put this one away.

kwx · 2016-02-08 18:07:54

iceman wrote:

custom wakeupcall? hm, then by all means go a get me some sniffed traffic between tag and reader so I can finally put this one away.

Will do and let you know.

iceman · 2016-02-09 08:18:51

There are some traces I would like to have,

1. a empty un-used tag, sniffing the first time you present it to the reader. This should give the transaction how the system initialize a calypso.

2. first time usage after initialization.

3. During refill and first time afterwards usage.

iceman · 2016-02-23 12:54:17

ok, thanks for the feedback about the custom anti-collision. It would explain the ping/pong messages I've gotten out of my tag.
Gonna test it and see if it works.

iceman · 2016-02-23 21:07:22

Ok, my tag is not the older 14B' version but the 14B version. Back to the drawing board again

Proxmark3 community

Announcement

#51 2015-07-19 23:10:29

Re: REQ: 14b snoop of a calypso communication

#52 2015-07-22 22:26:45

Re: REQ: 14b snoop of a calypso communication

#53 2015-07-22 22:46:31

Re: REQ: 14b snoop of a calypso communication

#54 2015-07-22 22:51:50

Re: REQ: 14b snoop of a calypso communication

#55 2015-07-22 22:54:00

Re: REQ: 14b snoop of a calypso communication

#56 2015-07-22 23:00:10

Re: REQ: 14b snoop of a calypso communication

#57 2015-07-22 23:18:22

Re: REQ: 14b snoop of a calypso communication

#58 2015-07-22 23:38:58

Re: REQ: 14b snoop of a calypso communication

#59 2015-07-22 23:59:58

Re: REQ: 14b snoop of a calypso communication

#60 2015-07-23 00:06:53

Re: REQ: 14b snoop of a calypso communication

#61 2015-07-23 00:13:57

Re: REQ: 14b snoop of a calypso communication

#62 2015-07-23 00:16:09

Re: REQ: 14b snoop of a calypso communication

#63 2015-07-23 00:25:13

Re: REQ: 14b snoop of a calypso communication

#64 2015-07-23 00:32:18

Re: REQ: 14b snoop of a calypso communication

#65 2015-07-23 13:41:05

Re: REQ: 14b snoop of a calypso communication

#66 2015-07-27 14:10:13

Re: REQ: 14b snoop of a calypso communication

#67 2015-07-27 16:02:50

Re: REQ: 14b snoop of a calypso communication

#68 2015-07-27 16:26:48

Re: REQ: 14b snoop of a calypso communication

#69 2015-07-27 16:56:55

Re: REQ: 14b snoop of a calypso communication

#70 2015-07-27 18:20:28

Re: REQ: 14b snoop of a calypso communication

#71 2015-07-27 21:01:14

Re: REQ: 14b snoop of a calypso communication

#72 2015-07-27 23:06:31

Re: REQ: 14b snoop of a calypso communication

#73 2015-07-28 19:05:06

Re: REQ: 14b snoop of a calypso communication

#74 2016-01-15 00:08:11

Re: REQ: 14b snoop of a calypso communication

#75 2016-01-15 17:58:18

Re: REQ: 14b snoop of a calypso communication

#76 2016-01-15 21:20:41

Re: REQ: 14b snoop of a calypso communication

#77 2016-01-15 21:32:33

Re: REQ: 14b snoop of a calypso communication

#78 2016-01-15 22:00:57

Re: REQ: 14b snoop of a calypso communication

#79 2016-01-16 14:40:42

Re: REQ: 14b snoop of a calypso communication

#80 2016-02-08 17:25:05

Re: REQ: 14b snoop of a calypso communication

#81 2016-02-08 17:52:37

Re: REQ: 14b snoop of a calypso communication

#82 2016-02-08 18:07:54

Re: REQ: 14b snoop of a calypso communication

#83 2016-02-09 08:18:51

Re: REQ: 14b snoop of a calypso communication

#84 2016-02-23 12:54:17

Re: REQ: 14b snoop of a calypso communication

#85 2016-02-23 21:07:22

Re: REQ: 14b snoop of a calypso communication

Board footer