Mifare 4K (S70?) SAK and ATAQ

yoda · 2014-11-19 23:11:08

Hi there

I'm trying to figure out why SAK returns 0x18 for my Mifare Classic 4k card. According to https://github.com/zhovner/mfdread the data in block0 is:

[== Java ==]
//  5 bytes  |   2 bytes  | 9 bytes
// UID + BCC | SAK + ATAQ | Manufacturer data

That matches my block0, except for SAK.

Block0: 1BAC0955EB980200648ED5D345000909

UID: 1BAC0955
BCC: EB
SAK: 98
ATAQ: 0200
Rest (not sure what this contains): 648ED5D345000909

When I read it using my Android phone:

[== Java ==]
NfcA nfca = NfcA.get(tag);
byte[] atqa = nfca.getAtqa();

System.out.println(Helper.getHexString(atqa));
System.out.println(Helper.getHexString(nfca.getSak()));

The result is:

0200 (ATQA)
18 (SAK)

Why is SAK 18? I don't see this in the hex above, as I do with 0200 (ATQA) ..

Thanks for reading

asper · 2014-11-20 07:55:55

It seems not to consider the MSB bit to define SAK:
98h = 10011000
18h = _0011000
Anyway, for what i know, in cascade level1 only bit3 is considered and all other bits are non-significant but SAK is always 8bit.

Last edited by asper (2014-11-20 07:56:32)

yoda · 2014-11-20 11:38:45

asper wrote:

It seems not to consider the MSB bit to define SAK:
98h = 10011000
18h = _0011000
Anyway, for what i know, in cascade level1 only bit3 is considered and all other bits are non-significant but SAK is always 8bit.

Hi asper

Very good observation, thank you.

Could this be an issue with Android's implementation of the Mifare protocol, or is this intended?

I've not tried reading the tag from a USB reader, only from Android phones, and all of them has 98h (as raw hex) in block0.

piwi · 2014-11-20 12:03:32

Well, SAK 0x18 would be typical for a Mifare Classic 4K with 4Byte UID (as well as the ATQA 0x0002).

Can you verify this behaviour with a PM3 as well? Assuming that Bit 8 is dropped by the Android software implementation is one possibility. But it is also possible that the card indeed did send 0x18.

Afaik the block 0 memory structure isn't defined - neither in NXP datasheets nor in ISO standards. If the manufacturer of your card decided to have 0x98 in block 0 but returns 0x18 as SAK that would be OK.

asper · 2014-11-20 14:31:26

I think that the SAK byte is sotred in that secotr0block0 position and it is this data tht is sent when requesting tha SAK.

Edit:
If you try to change this byte in a chinese mifare the SAK will change.

Last edited by asper (2014-11-20 14:33:15)

piwi · 2014-11-20 15:45:10

asper wrote:

I think that the SAK byte is sotred in that secotr0block0 position and it is this data tht is sent when requesting tha SAK.

Agreed that this is what we observed so far. But afaik this isn't a specified behaviour. We therefore shouldn't take it as granted.

But first we need to rule out that this Android software drops Bit 8 of the SAK. We can be sure that the PM3 doesn't. It would therefore be interesting what a "hf 14a reader" would show on a PM3.

asper · 2014-11-20 15:55:50

I agree with the pm3 test ! Anyway tags (even chinese ones) are structured to answer with SAK after the specific SELECT command and they "answer" the bits contained in byte5 (starting from byte0). In no other part of the chip that value is stored. The only question is how to interpret it but reading datasheets all 8 SAK bits must be considered as "SAK-bits", without leaving out the MSB.

Curiously nfc-tools make the same questioning-interpretation:

From the first block, the manufacturer data, can be determined if you are dealing with a 1KB or a 4KB tag. It can be done using the ATQA part of block0 in bytes 8 and 7 (stored in reverse order). Byte 6 contains the SAK (at least for the last part (4 bits)).

Even here SAK is considered as full byte (98 is specific for a mifare produced by GemPlus, I saw other examples of that manufacturer but unfortunately I don't remember PM3 answer).

EDIT:
I found an interesting thing in ISO14443-3 datasheet I was not aware of:

b8-b5 (1000)b: Additional information available in protocols
b8-b5 (1100)b: Default mode in protocols
b4-b1(0000)b: Other than ISO/IEC 14443-4
b4-b1(0001)b: PICC supports ISO/IEC 14443-4

So we are now sure that SAK must be considered in all its 8 bits and 1000 (b8-b5) = Additional mode in protocols (I still don't know what that means and where that additional info is stored) but with 98 whe have 10011000 so b8-b5 = 1001... maybe a specific GemPlus "mark", nothing more nothing else... but more probably "Additional info+PICC supports ISO/IEC 1443-4".

Last edited by asper (2014-11-20 16:31:59)

piwi · 2014-11-20 16:46:23

asper wrote:

Even here SAK is considered as full byte (98 is specific for a mifare produced by GemPlus, I saw other examples of that manufacturer but unfortunately I don't remember PM3 answer).

Well, in fact it doesn't say Mifare produced by Gemplus - it says Gemplus MPCOS. Which is a Javacard. Which can have a Mifare Classic emulation. If it is such a card, it would support ISO 14443-4 RATS although the SAK claims that it doesn't. The PM3 "hf 14a reader" command would reveal this.

asper wrote:

I found an interesting thing in ISO14443-3 datasheet I was not aware of:

b8-b5 (1000)b: Additional information available in protocols
b8-b5 (1100)b: Default mode in protocols
b4-b1(0000)b: Other than ISO/IEC 14443-4
b4-b1(0001)b: PICC supports ISO/IEC 14443-4

Watch out. This is specifically for ISO14443-A timeslot which is a completely different story.

asper · 2014-11-20 18:54:48

I am not sure about "all 98 are mpcos" because mpcos is more expensive than a real mifare and I found this "98" in very cheap tags (some of them, used for the same exact puropose) were NXP mifare (with specific atqa+sak) and some of them were sak=98; I don't think they used mpcos for such a "cheap" use, I think they are GemEasy8000 tags (real mifare, not mpcos-emulated). Link.

Last edited by asper (2014-11-20 18:59:06)

piwi · 2014-11-20 22:14:11

I was referring to the document which you had linked - I didn't state that "all 98 are mpcos". But MPCOS would be an explanation - those "intelligent" microprocessor cards could deliver any kind of SAK - no matter what is stored in block 0.

BTW: It would be interesting to check if the contents of block 0 of a Mifare Plus card changes like the SAK when switching the Security Levels.

yoda · 2014-11-21 08:14:06

Thank you everyone for your contributions. I do not currently own a Proxmark, but I've ordered one and hope to provide more information soon. I do not believe this is a GemEasy card, at least not the 8000, as the card is 4096B, 40 sectors (8 sectors of 4 blocks incl. trailer (16 bytes), 32 sectors of 4 blocks incl. trailer (16 bytes)). If anything, it's a GemEasy 32000; but these cards seem very expensive and as such, doesn't justify using them as travel card for riding busses/trains. We're not that rich in Denmark ^_^.

I believe it to be, or be based on, MF1 IC S70 (http://www.nxp.com/documents/errata_sheet/m057731.pdf), as I found an old specification for travel cards in Scandinavia (swedish), this deals with MF1 IC S50 (1024B). I know that the data on my card is following this specification to most of it's extent, but seeing as my card is 4096B, I'm likely to assume that it must be MF1 IC S70.

All this about SAK might be nothing, and I might not be fully understanding how it works - but in my optic, if the raw dump reads 98h for SAK, it should of course be 98h and not 18h.

We'll see what happens when my Proxmark arrives :-)

Again, thank you for your expertise

yoda · 2014-11-21 08:21:23

Also, I've verified that the SAK (98h = 18h) is the same on 3 official travel cards.

iceman · 2014-11-21 10:24:45

The danish travelcards is using the "resekortföreningen" RKF standard for the data on the cards. It can be both 1K / 4K mifare cards (s50/s70)

The mystique SAK value can be explained when looking at it from different outputs, see snippet below. I think it is a mixture of how to see the bitpattern mask from different sourcecode. Some show raw data, some has added a bitmask and then shown the data.

Same card and the sak is 18 - 88 - 98

pm3 --> hf 14a re
ATQA : 02 00
 UID : aa bb cc dd
 SAK : 18 [2]
TYPE : NXP MIFARE Classic 4k | Plus 4k SL1


output from "hf mf dump"
S0 - B0:  aabbccdd 88 98020064b995114d204209

output from "script run dumptoemul" -> "script run emul2html"
Type	Mifare
Size	4096 Bytes
UID	aabbccdd
SAK	98
ATQA	0200
Name	MPCOS

iceman · 2014-11-21 10:49:21

sorry, writing before coffe is not good.

Same card - TWO sak. The difference is between raw and emul2html.

output from "hf mf dump"
S0 - B0:  aabbccdd88 98 0200 64b995114d204209

yoda · 2014-11-21 10:56:19

Hi iceman

Thanks; that makes sense. I'll try and figure out how Android has implemented it :-)

iceman · 2014-11-21 11:54:37

Regarding RKF, the documents you can find on the net is v2.0 (from 2002). I read somewhere that denmark uses the v4.0 and some danish hackers, mapped the data structures in v4.0 which is based on the v.2. However I never found any documents,files from these danish hackers. If you find it I would like to have a copy

So,
18 is the SAK response from the tag.
98 is the databyte in Block 0

 SAK : 18 [2]

the [2] means :


  if( (sak & 0x20) == 0) {
    return 2; // non iso14443a compliant tag
  }

     Start |       End | Src | Data
-----------|-----------|-----|--------
         0 |       992 | Rdr | 52
      2228 |      4596 | Tag | 02  00
      7040 |      9504 | Rdr | 93  20
     10676 |     16500 | Tag | c3  8c  be  79  88
     18688 |     29216 | Rdr | 93  70  c3  8c  be  79  88  b8  80
     30388 |     33972 | Tag | 18  37  cd    <---SAK response

iceman · 2014-11-21 13:14:50

Correct me if I'm wrong, but aint those commands sent in 7bits?

piwi · 2014-11-21 17:27:35

Only the first (0x52, WUPA) is a short frame command (7 Bits, no parity). All the rest (including the SAK) is standard frame (8 Bits, 1 Parity Bit).

And ha, I was right! SAK and byte 6 of block 0 need not to be the same.

I think I remember that the Danish travel cards had been upgraded from Mifare Classic to Mifare Plus a few years ago...

asper · 2014-11-21 22:04:33

... but i think 1 of 2 is not correct
I vote for 18 (non-correct)

piwi · 2014-11-22 11:35:25

And I vote for both.

18 is the correct SAK and 98 is part of the manufacturer data. Whether the latter is "correct" cannot be determined by us.

yoda · 2014-11-22 17:55:30

iceman wrote:

However I never found any documents,files from these danish hackers.

Which information are you looking for specifically? :-)

Specific block information such as TCEL, TCAS or the "v4" of the RKF specification

iceman · 2014-11-22 18:31:32

Everything
All different parts of the RKF standard v4. I got the docs for v2
'

iceman · 2014-11-22 18:33:16

Speaking of SAK, Page8 (table 5.2) gives a nice overview on the different bits in the SAK byte.
http://dl.shibby.fr/Documents/Access%20 … 018413.pdf

However I haven't found any docs on byte6 in Block0 yet

iceman · 2014-11-22 23:11:16

Asper & Piwim where did you find the info about what the manufaturing block contains? Is it gatherd from the chines magic card source? or do you have a NXP doc laying around? As far as I can tell, the tag has access to more memory, registers, hardcoded values to present during a init transsaction with the reader then what we can extract via the read commands. So all eml files taking values from Block 0 and presents them as SAK is strange. Where did they get that from?

asper · 2014-11-22 23:17:37

They are stored somewhere, 99% in sector0block0. Block0 is called manufacturer block in nxp datasheets. Uid is there so atqa and sak are. Last 2 bytes are manufacturing data (extrapolated by me studying other nxp datasheets). Every bit answered by a tag must be stored in the chip so i suppose those data are taken from block0 which is read only in official tags (as any manufacturer info usually is).

Last edited by asper (2014-11-22 23:18:25)

Proxmark3 community

Announcement

#1 2014-11-19 23:11:08

Mifare 4K (S70?) SAK and ATAQ

#2 2014-11-20 07:55:55

Re: Mifare 4K (S70?) SAK and ATAQ

#3 2014-11-20 11:38:45

Re: Mifare 4K (S70?) SAK and ATAQ

#4 2014-11-20 12:03:32

Re: Mifare 4K (S70?) SAK and ATAQ

#5 2014-11-20 14:31:26

Re: Mifare 4K (S70?) SAK and ATAQ

#6 2014-11-20 15:45:10

Re: Mifare 4K (S70?) SAK and ATAQ

#7 2014-11-20 15:55:50

Re: Mifare 4K (S70?) SAK and ATAQ

#8 2014-11-20 16:46:23

Re: Mifare 4K (S70?) SAK and ATAQ

#9 2014-11-20 18:54:48

Re: Mifare 4K (S70?) SAK and ATAQ

#10 2014-11-20 22:14:11

Re: Mifare 4K (S70?) SAK and ATAQ

#11 2014-11-21 08:14:06

Re: Mifare 4K (S70?) SAK and ATAQ

#12 2014-11-21 08:21:23

Re: Mifare 4K (S70?) SAK and ATAQ

#13 2014-11-21 10:24:45

Re: Mifare 4K (S70?) SAK and ATAQ

#14 2014-11-21 10:49:21

Re: Mifare 4K (S70?) SAK and ATAQ

#15 2014-11-21 10:56:19

Re: Mifare 4K (S70?) SAK and ATAQ

#16 2014-11-21 11:54:37

Re: Mifare 4K (S70?) SAK and ATAQ

#17 2014-11-21 13:14:50

Re: Mifare 4K (S70?) SAK and ATAQ

#18 2014-11-21 17:27:35

Re: Mifare 4K (S70?) SAK and ATAQ

#19 2014-11-21 22:04:33

Re: Mifare 4K (S70?) SAK and ATAQ

#20 2014-11-22 11:35:25

Re: Mifare 4K (S70?) SAK and ATAQ

#21 2014-11-22 17:55:30

Re: Mifare 4K (S70?) SAK and ATAQ

#22 2014-11-22 18:31:32

Re: Mifare 4K (S70?) SAK and ATAQ

#23 2014-11-22 18:33:16

Re: Mifare 4K (S70?) SAK and ATAQ

#24 2014-11-22 23:11:16

Re: Mifare 4K (S70?) SAK and ATAQ

#25 2014-11-22 23:17:37

Re: Mifare 4K (S70?) SAK and ATAQ

Board footer