Proxmark developers community

Research, development and trades concerning the powerful Proxmark3 device.

Remember; sharing is caring. Bring something back to the community.

"Learn the tools of the trade the hard way." +Fravia

You are not logged in.

#1 Re: MIFARE Classic » Decrypted random nonces » 2009-09-21 08:18:22

schwa226 wrote:

Do you mean I can do the second authentication also with a "dummy" like FF FF FF FF FF key? Just the encrypted NT is the primary tarket?
So I don't need the genuine reader and can do the tests offline.

Basically once u know the key for one sector, call it exploit sector then you can launch a nested auth attack. What you do is first authenticate succesfully for that exploit sector and then without breaking the communication authenticate sequentialy for a sector that you dont know the key. The tag will reply with a new nT(nonce) that is however encrypted with the new key. Now because of the parity weakness in MIFARE and the fact that all the nonces are 2^16(^ is power not xoring) you can start cutting down the list of valid nonces that generated that parity. you can then rollback the register in order to get the keys that could generate the encrypted nonce. Repeating the process again and comparing the two lists will usually give u the key.

another variation is to use timing and nonce distance since the nonces are quite predictable and u can calculate what the next nonce will be.

#2 Re: MIFARE Classic » Decrypted random nonces » 2009-09-18 22:33:06


did u try these default keys  ffffffffffff  a0a1a2a3a4a5   b0b1b2b3b4b5  4d3a99c351dd 1a982c7e459a  000000000000 d3f7d3f7d3f7  aabbccddeeff?? it might be the case that KeyB is one of them.

#3 Re: MIFARE Classic » Multi-section Authentication with Card-Only attack » 2009-08-24 20:17:01


The third code works cause if you see the description of the lfsr recovery32 in crapto it clearly states that it takes two inputs. One of them is the keystream, in this case ks1 and the other is the variable in, where in is what it was fed into the LFSR at the point when the keystream was made. If you see the how the crypto 1 works, you will understand why the third instance works and the others dont even make sense.

#4 Re: MIFARE Classic » NXP Proposed Counter-measures » 2009-08-24 11:53:23


Yes, those documents i was talking about. I was suspecting that the solutions would be over-complicated but thanks for confirming. I guess in nxp they still havent understood secrecy does not suit them tongue

#5 MIFARE Classic » NXP Proposed Counter-measures » 2009-08-23 15:14:32

Replies: 3

Trying to read up on the counter-measures that can be implemented in order to somehow protect against the Mifare vulnerablities, i found out that nxp issued some directions but they are under disclosure. Anyone has any idea generally in what direction they are moving concerning their proposals? Are they only targeting the infrastructure at the backbone of the systems?

#6 Re: MIFARE Classic » Constants in common_prefix (crapto v2.3) » 2009-08-23 14:15:31


Yes i guess getting the constants right is the most important part. Although i still try to understand where the bit order you are mentioning in the forum comes into play. Guess the really really good understanding of the paper is the most important thing.

#7 Re: MIFARE Classic » MIFARE Classic common questions » 2009-08-20 01:34:39


1) If you look into the files section of the forum you will find all the papers concerning the attacks on Mifare Classic

2)It is possible to use other hardware. One inexpensive solution is OpenPCD and OpenPICC(though it can not even get close to proxmark capabilities) and another expensive solution is CLT Move from Comprion

3)keys are 48bits in size. That means it will take 2^47 tries aprox(^ denotes power) and with the time that it takes for each query u have to forget plain bruteforce attack. Besides with so many attacks why would you go bruteforce it?

#8 Re: MIFARE Classic » Constants in common_prefix (crapto v2.3) » 2009-08-19 19:51:37


i would edit my post but its better to just a new one with the correct values cause copy pasting sometimes can lead you to disasters big_smile

                                                     Odd                   Even
000 0x000000000000
001 0x8DC1b21F6E10 ----------->ecb15     |           bc538
002 0x1B83643EDC20------------>5e29c     |           ecb14
003 0xA945165E4A30------------->cc807     |           2edb0
004 0x3706C87DB840------------->7658a   |           5e29c
005 0xC4C87A9D2650------------->a5e51   |           9c62a
006 0x528A2CBC9460------------->176d8   |            cc807
007 0xE04BDEDC0270------------->85dc3   |            0ef23

is the table i have. Is there a way to verify on my own that im on the right track so i wont be spamming the forum(like i do now)?

Im not using the crapto code(that was a question out of curiousity...).
Being a newbie in bitwise operations this project is quite hard to tackle...

#9 Re: MIFARE Classic » Constants in common_prefix (crapto v2.3) » 2009-08-19 14:46:55


The moment i have the hardware again on my hands i will post all the values.

For the sake of interest, i am also trying to understand the common_prefix code in crapto. As i understand it takes as input the nacks,the size and a variable called isodd. From what i can tell, isodd is being used as a boolean. However i dont get to where it is refering? I mean it can't be that simple just calling common_prefix(table_of_nacks,sizeoftable,0) and getting back the candidates.right?

I want to thank you for all the valuable help and the constant support.

#10 Re: MIFARE Classic » Constants in common_prefix (crapto v2.3) » 2009-08-19 13:47:53


One question to help me with some debugging. The paper mentions that by filtering down we manage to cut our search space by 4. Is its actually exactly by 4? i mean if our initial table is 2<<21 after the first filtering we must have a table of( 2<<21)/4 exactly?

#11 Re: MIFARE Classic » Constants in common_prefix (crapto v2.3) » 2009-08-17 16:57:22


@marcus Did you find any problems with the filter function included in the crapto v2.4 or you just decided to write it from scratch?

#12 Re: MIFARE Classic » Constants in common_prefix (crapto v2.3) » 2009-08-17 00:42:59


Im not currently in the labs so i dont have the C and the responses i was using,i will post them here the moment i can.
Thank you for your explanation it clarified the situation alot. Will post here with my progress or any questions that will arise.

#13 Re: MIFARE Classic » Constants in common_prefix (crapto v2.3) » 2009-08-16 23:57:25


Sorry i jump into the conversation but iam trying to follow you and i must admit i am a bit lost. By fixing the timing   these specific values come up. Bits 29,30,31 of the 4th byte of C are only changed giving us the table below, where the parity is for example
3D--> 00111101
3A-->00111010 etc etc

UID: 1482F8D7B9
Card Nonce: 7E3C0DBD

Bits 29,30 and 31 | Parity | Encrypted Nack

000| 3D| 09
100| 3A| 0C
010| 2B| 0C
110| 2B| 09
001| 2B| 09
101| 2C| 0D
011| 3F| 00
111| 3A| 0F

I understand that by XORing [NACK] with NACK i get the first 4bits of ks3.
I also understand that i have to create a table of binary representations of numbers from 0 to 2 in the power of 21.
Will i have to input that table into the filter function and keep only the results that satisfy the condition that

where ks3(0)=1bit that i got from the NACK.

How do the rest of the NACKs come into play? Please correct me if iam wrong in any of my assumptions.

Board footer

Powered by FluxBB