REQ: 14b snoop of a calypso communication

iceman · 2015-06-25 20:20:34

If there is someone who has access to a real reader & tag for Calypso, if you do, can you try the new snoop in 14b and see if you can pic up some communications and publish it here.

Navigo system in Paris, is calypso based. Maybe someone there?

asper · 2015-06-25 20:50:38

Jonor has something related to Calypso... ?

iceman · 2015-06-25 22:24:09

Jonor? Haven't seen him for a while here... Do you have contact with him?

asper · 2015-06-25 22:29:07

Contacted him recently, still no answer...

iceman · 2015-06-26 08:03:31

Finally I got my navigo (calypso?) tag to answer.

pm3 --> hf 14b raw -c -p 05 00 08
received 14 octets
50 26 58 4B 0C 00 00 00 00 00 71 81 CA D7
CRC OK

asper · 2015-06-26 08:08:42

Good. It seems an ATS. Maybe an ST smartcard?
A tag/reader snoop is necesarry to see if all works well.

Here some available docs:
http://ask-contactless.com/Portals/0/Flyers/Cards/CalypsoCard_flyer.pdf
www.innovatron.fr/CalypsoFuncSpecification.pdf

Best choice is to search for specific chip datasheet insted of Standard datasheets.

Last edited by asper (2015-06-26 08:25:53)

marshmellow · 2015-06-26 12:58:42

It is the atqb. Run the info cmd. Your tags uid is 26584b0c

iceman · 2015-06-26 15:35:12

nop "info" doesn't work.
The tag seems to very sensitive to when sending a command.

a- Distance from antenna, very itchy about it.
b- command seq, seems to be sensitive about it

b, if I send 05 00 08, a few times until I get an response.

iceman · 2015-06-26 15:36:21

And I found some lua scripts from the CardPeek software

calypso.lua
https://code.google.com/p/cardpeek/sour … alypso.lua

navigo.lua
https://code.google.com/p/cardpeek/sour … .lua?r=116

Last edited by iceman (2015-06-26 15:38:45)

asper · 2015-06-27 10:04:46

The smart card commands (apdus divided in CLA-INS...) are defined by ISO7816 standard.

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).

9000 is the ACK answer from the card (it corresponds to an "Ok, command executed correctly").
6E00 Should be an error answer, specifically "Class not supported" (class (CLA) is the 1st byte of the APDU).

Using RFID the apdus are embedded in a specific tag command, ex: XX APDU CTRL where:
XX = rfid apdu command
APDU = CLA+INS...
CTRL = Usually some control bytes (CRC, etc)

Last edited by asper (2015-06-27 10:16:11)

iceman · 2015-06-27 18:26:42

in the lua scripts, its something like this:

CLA: 0x94
INS : A4 (select )
20 00 (DF)

APDU size is 8 bytes.

so what is the rest in for the "hf 14b raw"??!?
cla ins p1 p2 len data data lendata
hf 14b raw -c -p 94 a4 00 00 00 20 00 02

I'm missing something here....

pm3 --> hf 14b raw -c -p 05 00 08
received 14 octets
50 26 58 4B 0C 00 00 00 00 00 71 81 CA D7
CRC OK
pm3 --> hf 14b raw -c -p 94 a4 00 00 00 20 00 02
received 0 octets

iceman · 2015-06-27 20:26:46

Yes, I had an extra call to close the command before a "info" call, which was bad.
I moved it after so the call to "hf 14b info" closes the connect in the end.

That worked and my Nacvigo tag answers:

pm3 --> hf 14b i

14443-3b tag found:
           UID: 26 58 4B 0C
      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

iceman · 2015-06-27 20:28:18

CID supported tells me that the APDU frame should have

si , cid, cla, ins, p1 , p2, len, data.. lendata..
0x0A, 0x01, 0x94, 0xA4, 0x00, 0x00....

asper · 2015-06-28 01:27:27

Try to 1st send: 94 A4 08 00 02 31 00

Last edited by asper (2015-06-28 01:30:27)

marshmellow · 2015-06-28 03:34:20

i had a 14b tag that would respond to a 02 00 A4 04 00 [crc] as well as several longer strings that started with that.
(see my comments in the HF14BStdReader function in my fork.)

but i don't know if there is any relation to these tags.

Last edited by marshmellow (2015-06-28 03:35:01)

lutcheti · 2015-06-29 17:24:55

I own several Navigo tags and I leave in Paris so I have an easy access to Navigo readers (bike renting & metro networks). I tried to snoop a transaction but I always obtain a weird error message:

proxmark3> hf 14b snoop
#db# Snooping buffers initialized:                 
#db#   Trace: 39360 bytes                 
#db#   Reader -> tag: 256 bytes                 
#db#   tag -> Reader: 256 bytes                 
#db#   DMA: 128 bytes                 
#db# blew circular buffer! behindBy=0x74                 
#db# Snoop statistics:                 
#db#   Max behind by: 116                 
#db#   Uart State: 0                 
#db#   Uart ByteCnt: 0                 
#db#   Uart ByteCntMax: 256                 
#db#   Trace length: 0

I also tried to send raw hex as you did but I always get

received 0 octets

Here is my config:
http://sebsauvage.net/paste/?73f80ed23271fa3e#lGP+oZ2Rwty1hn2yarAjBlQsHbBWjpsITDlh5cPR6kQ=

iceman · 2015-06-29 18:19:40

That would be great if you could get some snoop traces and share them here.

asper · 2015-06-29 19:08:03

You should snoop the ats... probably an antenna issue. Can you try to snoop with different antennas positions or different antennas themselves?

Or maybe you don't have the latest github sources compiled ?

Last edited by asper (2015-06-29 19:30:19)

iceman · 2015-06-29 22:00:27

took me 2 days before I got something else out from this navigo tag..

pm3 --> hf 14b raw -c -p 05 00 08                                                 --- WUPB  
[LEN 14] 50 26 58 4B 0C 00 00 00 00 00 71 81 [CA D7] OK
pm3 --> hf 14b raw -c -p 50 26 58 4b 0c                                        --- HALT  0x50   plus uid
[LEN 3] 00 [78 F0] OK

iceman · 2015-06-29 22:49:03

I understand that I'm failing in setting the tag to active state.
1) wupa (05 00 08)
2) attrib (1d uid0 uid1 uid2 uid3 p1 p2 p3 p4
if a ok response from tag now, its in a active state, where I can send the ISO7816 apdus.

but at the moment step 2 doesn't work.

This doc explains everything very good.
ref: http://www.atmel.com/images/doc2056.pdf

iceman · 2015-06-29 23:11:09

// WUPB
hf 14b raw -c -p 05 00 08  
[LEN 14] 50 26 58 4B 0C 00 00 00 00 00 71 81 [CA D7] OK  :D 

// ATTRIB
pm3 --> hf 14b raw -c -p 1D 26 58 4B 0C 00 08 01 00
[LEN 3] 00 [78 F0] OK   :D 

//APDU
 :( 

// HALT
 hf 14b raw -c -p 50 26 58 4b 0c 
[LEN 3] 00 [78 F0] OK :D

asper · 2015-06-30 10:28:18

Great step forward !

Did you try with a lower Frame size ?
Ex. 1D 26 58 4B 0C 00 05 01 00

Or maybe changing the bitrate ? (1st byte of protocol info)
Mifare_DESFire_EV1_2K_4K_8K_MF3ICD21_MF3ICD40_MF3ICD41_MF3ICD81_98.jpg

Last edited by asper (2015-06-30 10:36:48)

iceman · 2015-06-30 10:55:06

great suggestions,
I'm gonna look into it tomorrow.

asper · 2015-06-30 13:28:31

Stating to te ATQB datarate is 00 = 106kbit/s in the same direction and frame size is 00 = 16bytes

mmmmm maybe i am wrong about the bitrate... it should be defined by the 71 value (atqb).

need to understand what app data bytes are inside the atqb...

Last edited by asper (2015-06-30 13:48:05)

iceman · 2015-06-30 15:09:43

I suppose the framesize is the one spooking

marshmellow · 2015-06-30 15:10:36

iceman's tags atqb suggests the bitrate should be 00, the max frame size the tag can handle is 128Bytes (what is the pm3's max 64?). not sure what the frame wait int is...

iceman · 2015-06-30 15:12:38

PM3 can (since piwi's excellent parity changes last winter) deal with 256byte frames.
frame wait, isn't it the time between EOF & SOF?...

iceman · 2015-06-30 21:41:51

First select the tag. (05,1d stuff) Marshmellow has impl. a select option ( "hf 14b raw -s" )

Valid B-apdu's or BLOCK

  FB    CID CLA INS P1 P2 LEN ...data...  CRC1 CRC2
----------------------------------------------------
c2/ca  00   94   A4   00 00 02 00 00 crc crc       (deselect S-BLOCK)
f2/fa   00                                                       (WTX S-BLOCK)
02/0a  00                                                      (I-BLOCK)

RESPONSES:
Ax 90 00    (r-block ACK)
Bx 90 00    (r-block NAK)

But my tag doesn't answer.. I'm leaning towards the demod on device-side doesn't work properly..
Where is Piwi when you need him?!?

lutcheti · 2015-07-01 20:47:17

asper wrote:

You should snoop the ats... probably an antenna issue. Can you try to snoop with different antennas positions or different antennas themselves?
Or maybe you don't have the latest github sources compiled ?

You were right. I had not.

I tried to reflash my PM3 but I got an error. It seems I am not the only one, so I post it here:
http://www.proxmark.org/forum/viewtopic … 872#p16872.

[EDIT]
It seems it is a serious issue. Can't wait to solve it ....
[/EDIT]

Last edited by lutcheti (2015-07-13 17:27:50)

iceman · 2015-07-05 21:10:59

I'm taking a wild guess now... but...

ISO 7816 APDU's do they have a CRC in the end?

e.g.
0A 00 94 A4 00 00 02 20 00 should it have crc appended? if so, is this crc of type A or B?

asper · 2015-07-05 21:33:19

Stating that Calypso is TypeB you should append CRC-B...

iceman · 2015-07-05 22:55:30

yes, you r right Asper, iso 14443b part 4, states the apdus to be wrapped with pcb,cid (nad) [apdu] crc-b

iceman · 2015-07-13 07:43:38

And after testing the Fredrikmoellers patch, where he uses a long timeout I still didn't get the Calypso to respond to a proper apdu.
I'm now leaning towards the possibility that the error lays inside the fpga code. Is Piwi on vaccation?

marshmellow · 2015-07-13 16:36:22

are you certain the calypso card is supposed to respond to your command? or could it be it requires authentication before selecting? since other 14b cards are responding seemingly well, i'm not sure it will prove to be a pm3 error.

jump · 2015-07-13 16:59:18

I could check that this week with my old pass but on Navigo, the PIN code is only required to read specific areas (at least when you read it with the smartcard interface). But it's trivial to find it (0000, 1234 or something alike).
Unless they added extra protection on the contactless interface, I've always been told that both interfaces behaves the same way on those tags.

marshmellow · 2015-07-13 17:24:35

If we had a good snoop of the a legit transaction then we could confirm where the issue is.

iceman · 2015-07-13 17:33:18

I've been reading the source lua scripts on this project, which could read navigo many years ago.
pterjan cardpeek navigo on github

however, if the navigo changed its protocol is not known. It would be easy to verify if you run that version of cardpeek on a reader and a real tag. (where you could do a pm3 snoop too)

jump · 2015-07-13 17:39:36

My tag is less than 1 year old and I was able to read it with cardpeek. I just don't remember the PIN code (but there was nothing interesting in the protected area anyway)

Navigo has been added in the default trunk of Cardpeek

And since the last time I used it, they seem to support more Calypso tags

iceman · 2015-07-13 22:22:09

indeed, but the question was if the navigo requires a authentication before selecting (in the iso7816 layer)
From the scripts I haven't found anything that would suggest a authentication.

Thats why I suggested the 14b demod or fpga doesn't deal with the delayed answer from that layer.
Do you have a snoop from your tests Jump?

jump · 2015-07-13 22:52:49

Unfortunately no. I was always playing with the tag through the smartcard interface because last year no public tool was able to deal with the RFID interface. And now I am not living in France anymore (and to be honest, because of all the security cameras embedded in buses, trams and subway stations, it might not be easy to snoop a transaction without drawing attention
The easiest spot to snoop would be the bike stations (Velib') but as far as I know, all they care about is the chip serial number.

All I can do from where I am is to snoop the USB packets between the tag and the computer while running cardpeek. But it shouldn't give you more information that what you have by looking at the source code.
I also have an Omnikey 5427 which seems to be able to handle Calypso. The default application only reads the ATR and the UID but it's properly handled and could allow to debug the communication (unfortunately I cannot get a hand on the SDK for it).

Also, according to cardpeek, Grenoble also uses Calypso and I might have kept a daily tag from there Not sure whether it is RFID enabled or simply a magstripe but as soon as I get my hand back on it, I'll try to see if the OK5427 can see something and I'll keep you posted.

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

actually, at this moment in time, I would like to have a snoop from cardpeek and a tag.
If you could mail me or pastebin it here, then that would help me out very much bro.

jump · 2015-07-13 23:17:07

I will definitely prefer sharing the dump privately to avoid wasting my time scraping out personal data without preventing you from implementing the protocol

I have a snoop of the omnikey reading partially the tag (ATR + UID) and also the capture between cardpeek and the tag through the RFID interface!

iceman · 2015-07-13 23:29:17

Sure, you can send it to

iceman "at the" iuse dot se will work fine.

piwi · 2015-07-14 08:36:40

iceman wrote:

Where is Piwi when you need him?!?

Did you look outside your window recently? Its summer. I prefer to be off my PM3, the forum and github these days...

I don't think that it is an issue with FPGA or ARM code. At this level there is no difference in receiving the response to REQB, ATTRIB and any apdu. At least not if you increase the timeout (which you did).

I think that you need to figure out which command is the correct one. See also on github.

A trace of a working transaction would indeed be beneficial.

iceman · 2015-07-14 08:53:13

No worries, Piwi, but of course I noticed the summer outside and you should be logging off and be outside. My comment was merely a comical remark of how valued your knowledge is when it comes to the FPGA source among others.

I'll get some snooped transactions from @jump above, that will help out the process of getting a response out of the tag.

iceman · 2015-07-14 09:48:55

I got a snoop from a user, de-identified log is below from a omni-reader and tag using cardpeek.

Two things strikes me.
1. BA / AB
reader sends: 0xBA cid
tag answers: 0xAB cid
I haven't seen this in my iso14443-B pdf's before. What is it?

2. APDU size is one more than I expected. The last 0x00 I didn't see coming.
0a 03 94 a4 00 00 02 20 00 00 [f9 b2]

   1397182 |   1397182 | Rdr | 05  00  00 [71  ff]                                             |  ok | REQB
   1397958 |   1397958 | Tag | 50  xx  xx  xx xx 00  00  00  00  00  71  81 [2d  ff]           |  ok |
   1398708 |   1398708 | Rdr | 1d  xx  xx  xx xx 00  08  01  02 [bb  67]                       |  ok | ATTRIB
   1399046 |   1399046 | Tag | 02 [6a  d3]                                                     |  ok |
   1441774 |   1441774 | Rdr | ba  02 [4b  eb]                                                 |  ok | ?
   1442152 |   1442152 | Tag | ab  02 [02  67]                                                 |  ok |
   1466468 |   1466468 | Rdr | 05  00  00 [71  ff]                                             |  ok | REQB
   1467246 |   1467246 | Tag | 50  xx  xx  xx xx 00  00  00  00  00  71  81 [2d  ff]           |  ok |
   1467996 |   1467996 | Rdr | 1d  xx  xx  xx xx 00  08  01  03 [32  76]                       |  ok | ATTRIB
   1468334 |   1468334 | Tag | 03 [e3  c2]                                                     |  ok |
   1480142 |   1480142 | Rdr | 0a  03  94  a4  00  00  02  20  00  00 [f9  b2]                 |  ok | APDU select
   1482356 |   1482356 | Tag | 0a  03  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 [8a  38]     |  ok |

Last edited by iceman (2015-07-14 09:50:51)

asper · 2015-07-14 13:44:31

It is a simple "ping" request; i found that some times ago here: http://forums.nfc-tools.org/topic/35/how-to-send-7816-apdus-using-libnfc/

we should add ab - ba to the commands list.

Last edited by asper (2015-07-14 13:45:20)

iceman · 2015-07-15 20:41:03

feedback:

user: jump tried the commands with his pm3 and his tag.. and he had a partial success. got lots of bytes, but crc was wrong.

iceman · 2015-07-16 12:10:29

OK. fine.
I got feedback from the user who sent me this navigo tag.
Apperently this is a completely new tag, "without subscription", so I guess that is why it doesn't answer to Navigo's application directory (20 00) aid. because it might not be there.. However, it doesn't explain why it doesn't follow iso7816 standard and give me a "nack" response...

iceman · 2015-07-17 21:47:57

I added a ISO7816 annotation to the "Hf list" command.

Proxmark3 community

Announcement

#1 2015-06-25 20:20:34

REQ: 14b snoop of a calypso communication

#2 2015-06-25 20:50:38

Re: REQ: 14b snoop of a calypso communication

#3 2015-06-25 22:24:09

Re: REQ: 14b snoop of a calypso communication

#4 2015-06-25 22:29:07

Re: REQ: 14b snoop of a calypso communication

#5 2015-06-26 08:03:31

Re: REQ: 14b snoop of a calypso communication

#6 2015-06-26 08:08:42

Re: REQ: 14b snoop of a calypso communication

#7 2015-06-26 12:58:42

Re: REQ: 14b snoop of a calypso communication

#8 2015-06-26 15:35:12

Re: REQ: 14b snoop of a calypso communication

#9 2015-06-26 15:36:21

Re: REQ: 14b snoop of a calypso communication

#10 2015-06-27 10:04:46

Re: REQ: 14b snoop of a calypso communication

#11 2015-06-27 18:26:42

Re: REQ: 14b snoop of a calypso communication

#12 2015-06-27 20:26:46

Re: REQ: 14b snoop of a calypso communication

#13 2015-06-27 20:28:18

Re: REQ: 14b snoop of a calypso communication

#14 2015-06-28 01:27:27

Re: REQ: 14b snoop of a calypso communication

#15 2015-06-28 03:34:20

Re: REQ: 14b snoop of a calypso communication

#16 2015-06-29 17:24:55

Re: REQ: 14b snoop of a calypso communication

#17 2015-06-29 18:19:40

Re: REQ: 14b snoop of a calypso communication

#18 2015-06-29 19:08:03

Re: REQ: 14b snoop of a calypso communication

#19 2015-06-29 22:00:27

Re: REQ: 14b snoop of a calypso communication

#20 2015-06-29 22:49:03

Re: REQ: 14b snoop of a calypso communication

#21 2015-06-29 23:11:09

Re: REQ: 14b snoop of a calypso communication

#22 2015-06-30 10:28:18

Re: REQ: 14b snoop of a calypso communication

#23 2015-06-30 10:55:06

Re: REQ: 14b snoop of a calypso communication

#24 2015-06-30 13:28:31

Re: REQ: 14b snoop of a calypso communication

#25 2015-06-30 15:09:43

Re: REQ: 14b snoop of a calypso communication

#26 2015-06-30 15:10:36

Re: REQ: 14b snoop of a calypso communication

#27 2015-06-30 15:12:38

Re: REQ: 14b snoop of a calypso communication

#28 2015-06-30 21:41:51

Re: REQ: 14b snoop of a calypso communication

#29 2015-07-01 20:47:17

Re: REQ: 14b snoop of a calypso communication

#30 2015-07-05 21:10:59

Re: REQ: 14b snoop of a calypso communication

#31 2015-07-05 21:33:19

Re: REQ: 14b snoop of a calypso communication

#32 2015-07-05 22:55:30

Re: REQ: 14b snoop of a calypso communication

#33 2015-07-13 07:43:38

Re: REQ: 14b snoop of a calypso communication

#34 2015-07-13 16:36:22

Re: REQ: 14b snoop of a calypso communication

#35 2015-07-13 16:59:18

Re: REQ: 14b snoop of a calypso communication

#36 2015-07-13 17:24:35

Re: REQ: 14b snoop of a calypso communication

#37 2015-07-13 17:33:18

Re: REQ: 14b snoop of a calypso communication

#38 2015-07-13 17:39:36

Re: REQ: 14b snoop of a calypso communication

#39 2015-07-13 22:22:09

Re: REQ: 14b snoop of a calypso communication