What does the "!" & "!crc" mean?

RFlD · 2009-03-19 15:40:44

> who knows why some data captured by pm3 would be added with
> "!", What does this mean?
> e.g. ( the last line and the "!crc")
> + 1757: : 52
> + 64: 0: TAG 04 00
> + 480: : 93 20
> + 64: 0: TAG d4 b4 81 09 e8
> + 1192: : 93 70 d4 b4 81 09 e8 a5 f2
> + 64: 0: TAG 08 b6 dd
> + 920: : 60 00 f5 7b
> + 112: 0: TAG be 18 43 a5
> + 952: : ae 6c 36 c1 62 55 50 a5 !crc
> + 64: 0: TAG f4! 9f ca 68
>
> Thanks in advance!

joker · 2009-03-19 16:10:15

the ! signifies the parity bit is wrong.

after every byte a parity bit is sent over the air. You can find more information on parity bits on wikipedia. however they are a rudimentary way to protect against interference and bad transmissions. The parity of a byte is whether or not the amount of 1 bits in the bytes is odd. (if a single bit would get transferred wrongly this would be detectable)

basically if you were to send say byte: 0x45
you would also send the parity bit 1 (because 0x45 is 0100 0101, in binary which has three 1 bits, and three is an odd number)

So normally you can just calculate this bit from the value of the data. However!
and this is important since it breaks the cryptography of the mifare classic infrastructure even further, These parity bits are not calculated over the encrypted bytes sent over the air, but over the plain text bytes, and then encrypted (poorly) as well. You can find more details in the dutch papers.

They chose to denote this parity bit, not with 0, or 1, but with an ! if the bit was sent incorrectly.

Hence when you see in a dump: 0x45
- over the air it would have been 0100 0101 1 (well logically it is transfer encoded/modulated further)
Complementary when you see: 0x45!
- 0x45 ! it means the parity bit is wrong, so 0100 0101 0
would have been sent.

This notation is practical because you can typically see which part is encrypted, and it is less clobbering and confusing than adding the 0,1's in a dump already littered with all sorts numbers and values.

The !crc is similar, many commands in the protocols are finished with a 2 byte crc the correct algorithm is described in more detail in the German paper iirc. this is also done on the unencrypted data afaik so it will also fail when interpreting it in its encrypted form

hope it helps

Last edited by joker (2009-03-19 17:00:13)

rule · 2009-03-19 16:51:03

This saves me an explanation that I promised in the email to you RFlD

RFlD · 2009-03-19 17:46:56

joker wrote:

the ! signifies the parity bit is wrong.
after every byte a parity bit is sent over the air. You can find more information on parity bits on wikipedia. however they are a rudimentary way to protect against interference and bad transmissions. The parity of a byte is whether or not the amount of 1 bits in the bytes is odd. (if a single bit would get transferred wrongly this would be detectable)
basically if you were to send say byte: 0x45
you would also send the parity bit 1 (because 0x45 is 0100 0101, in binary which has three 1 bits, and three is an odd number)
So normally you can just calculate this bit from the value of the data. However!
and this is important since it breaks the cryptography of the mifare classic infrastructure even further, These parity bits are not calculated over the encrypted bytes sent over the air, but over the plain text bytes, and then encrypted (poorly) as well. You can find more details in the dutch papers.

They chose to denote this parity bit, not with 0, or 1, but with an ! if the bit was sent incorrectly.
Hence when you see in a dump: 0x45
- over the air it would have been 0100 0101 1 (well logically it is transfer encoded/modulated further)
Complementary when you see: 0x45!
- 0x45 ! it means the parity bit is wrong, so 0100 0101 0
would have been sent.
This notation is practical because you can typically see which part is encrypted, and it is less clobbering and confusing than adding the 0,1's in a dump already littered with all sorts numbers and values.
The !crc is similar, many commands in the protocols are finished with a 2 byte crc the correct algorithm is described in more detail in the German paper iirc. this is also done on the unencrypted data afaik so it will also fail when interpreting it in its encrypted form
hope it helps

thanks a lot!
It's the same as I think!
But I tried to recover the key, it seems the key's recovered successfully!
Two different group of data gave the same key!
I am very excited!

I put the data here, let more people verify it!

 +    920:    :     60  00  f5  7b    
 +    112:   0: TAG 25  93  11  49    
 +    952:    :     b6  ea  fd  0b  37  7a  5b  f4      !crc
 +     64:   0: TAG d1  03! 91  2a! 

  +    920:    :     60  00  f5  7b    
 +    112:   0: TAG be  18  43  a5    
 +    952:    :     ae  6c  36  c1  62  55  50  a5      !crc
 +     64:   0: TAG f4! 9f  ca  68

UID:d4b48109

It would be convenient in such form:
{ 0xd4b48109, 0x25931149,
0xb6eafd0b, 0x377a5bf4,
0xd103912a

0xd4b48109, 0xbe1843a5,
0xae6c36c1, 0x625550a5,
0xf49fca68}

and I got the result:
Test case 0:
Key: 307E00DFD5D6
Nr : E012307A
Test case 1:
Key: 307E00DFD5D6
Nr : 5EC8F019

The key is 307E00DFD5D6!

joker · 2009-03-19 18:03:09

can the people on this board please stop quoting entire posts, it's ridiculously annoying!

yes, my code verifies your result, but keep in mind that you have the key in Crapto1 notation, the convention on this board appears to be to reverse the bytes
307E00DFD5D6 --> d6d5df007e30

RFlD · 2009-03-19 18:35:58

thanks for your explain and verification, joker

btw, I'll stop quoting entire posts, ^_^

rule · 2009-03-19 19:48:28

joker wrote:

the convention on this board appears to be to reverse the bytes
307E00DFD5D6 --> d6d5df007e30

This is not our convention, check the ISO14443A documentation. It is their convention!
The bytes are send in reversed order over the air (except for the parity).
And since a MIFARE Classic tag has no buffer at all, it needs to process them immediately
That means... in reverse order compared to the notation in the ISO standard.

pfff I feel the same though...about bitflipping/mirroring, I've seen it to much these days

joker · 2009-03-19 20:22:31

I never claimed it was yours! perhaps i should have written:
The convention preferred by the people on this board appears to be the one in the ISO14443A standard

It doesn't matter one bit though(pun intended) just as long as you know what you are doing, which was the only reason why i deemed it fit to point out ...

Last edited by joker (2009-04-03 08:10:40)

rule · 2009-03-19 22:49:24

Thank you for pointing out the key bits have to be mirrored/twisted/swapped (whatever ya want to call it), I guess it will help users to understand the working of CRYPTO1 better.

It could be useful to know that the key bytes have to be supplied in ISO notation to the MIFARE Classic Reader chips (like MFRC500, MFRC632, PN5XX, etc.). Therefor all the example tools from vendors etc. use also this notation. This is, from a cipher perspective kind of strange, but hey, this perspective is not really public knowledge that long .

nidayede · 2011-07-20 09:43:35

Hi, How are you every body I am buy Tera Gold, and I am a civil engineering student and it is my final year remaining for me to graduate from the Tera Items university and I am From Kingdom Of Bahrain and I can put Exams and my own notes in steel and Tera Online Gold conrete designs and structural analysis as I have time I will put the notes for you. The British standard will be used in my notes,and these days are my last 3 weeks on Tera Gold before the end of semester and the beginning of the final exams.

martinouyang · 2011-07-23 18:07:38

we supply the cards below:

Works exactly like the Mifare S50, with 16 Sectors and 4 Blocks each Sector, but the Sector 0 Block 0 known as Manufacturers Block where the Chip UID is stored, can be re programmed to any UID you wish.
It's advantage;
This is a perfect solution for a lost irreplaceable Mifare Cards ID, you don't need to re-enroll new cards. Just program this new Mifare 1K's UID to the UID of lost card then you have a new Exactly the same card.

Popular applications;
Loyalty
Ticketing
Identification
Access Control

ouyangweidaxian@live.cn

Proxmark3 community

Announcement

#1 2009-03-19 15:40:44

What does the "!" & "!crc" mean?

#2 2009-03-19 16:10:15

Re: What does the "!" & "!crc" mean?

#3 2009-03-19 16:51:03

Re: What does the "!" & "!crc" mean?

#4 2009-03-19 17:46:56

Re: What does the "!" & "!crc" mean?

#5 2009-03-19 18:03:09

Re: What does the "!" & "!crc" mean?

#6 2009-03-19 18:35:58

Re: What does the "!" & "!crc" mean?

#7 2009-03-19 19:48:28

Re: What does the "!" & "!crc" mean?

#8 2009-03-19 20:22:31

Re: What does the "!" & "!crc" mean?

#9 2009-03-19 22:49:24

Re: What does the "!" & "!crc" mean?

#10 2011-07-20 09:43:35

Re: What does the "!" & "!crc" mean?

#11 2011-07-23 18:07:38

Re: What does the "!" & "!crc" mean?

Board footer