[Resolved] hf mf dump for 4k cards broken?

iceman · 2014-09-11 14:30:00

Bummer... a typo,..
BUT.... case 0x20 == SAK is not clear... ambivalent.. but in that specific case, it can return -1, (plus 2k or 4k)...

		switch(sak){
			case 0x08:
			case 0x10:
			case 0x20:
				return 2;
				break;
			case 0x11:
			case 0x18:
			case 0x20:
				return 4;
				break;
		}

carlijn · 2014-09-11 14:46:08

the one that can crack my high protected mifare 4k card i will pay 1000 us dollar in cash no joke!!!!!!!!!!!!!!!!

Last edited by carlijn (2014-09-11 14:56:00)

carlijn · 2014-09-11 14:49:05

Last edited by carlijn (2014-09-11 15:36:46)

carlijn · 2014-09-11 14:51:42

Last edited by carlijn (2014-09-11 15:37:33)

carlijn · 2014-09-11 14:55:16

Printscreens from high protected mifare 4k
I can read both sectors A and B till sector 21 than it is game over
As i said the one that can crack this strong protected mifare with good PRNG
i will pay 1000 US dollar in cash come on hackers!!!!!!!!!!!!!!!!!!!

Last edited by carlijn (2014-09-11 15:41:36)

russ · 2014-09-11 15:47:50

Carlijn, I think you misunderstand, this isn't really a place where "hackers" are doing this for money. This is more about development and improving proxmark3 for 4K cards in this thread.

Piwi, thanks so much for your commits! I'll look forward to testing the next ones. Maybe I'll look at what needs to be improved for the simulator. It would be nice to not "brick" cards with the wrong access conditions for the sectors.

carlijn · 2014-09-11 16:23:29

A proxmark 3 is a clone sniff hack tool so maybe you can explain me why people buy a proxmark for?
right cracking hacking cloning and sniffing if nobody will do it for money than see it as development or improving.
whatever you like to name it .
if you think that using a proxmark 3 is for develpoment and improving than my question is that to,
Greatings Carlijn

piwi · 2014-09-11 20:20:54

Today's commit to github master provides

the small fix for the wrong sector and block number printout in hf mf dump
error handling in hf mf dump. If blocks can't be read, hf mf dump will abort and dumpdata.bin not be created/overwritten.
for those who want to use hf mf chk with more keys: I provided a file default_keys.dic which contains the keys from mf_default_keys.lua. This file can be read and used by hf mf chk.
added the d (dump) option to hf mf chk (writes dumpkeys.bin). Most likely there will be keys unknown to hf mf chk. In this case the dumpkeys.bin will contain the default key 0xffffffffffff at the respective position instead. I am not sure how usefull this option is, but anyway...

russ · 2014-09-11 20:29:51

Thanks, that's great.

I was looking at the dump that was failing today. I noticed that it failed on some sectors, but I was able to manually read the sector using key B, after putting a some print debugging statements in I noticed that the if statement to check which key to use isn't selecting keyB in times when it will work.

Also, I noticed the section reading the sector access bits only ORs together data[7]... | data[8]... | data[8]

I was hoping for a quick fix so I put data[9] in the last column... but that didn't work.

I'm going to look at the spec document again to double check which access bits.

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

The algorithm prefers Key A. There are only two Access Bit combinations (binary 101 and 011, 5 and 3 in decimal) which absolutely require key B and only in these cases key B is used. Maybe this gives you the hint to identify the bug.

russ · 2014-09-11 22:54:44

I don't understand the bitwise operations in the dump function when it is gather the access bytes and rights array information. In the docs it says that byte 6, 7, 8 are needed to calculate the access for the 4(effective) blocks in a sector. But the code only references data[7] and data[8].

I did debugging to print the access bytes for sector zero:

#db# READ BLOCK FINISHED                 
Access byte 6: 0F : 00001111          
Access byte 7: 00 : 00000000          
Access byte 8: FF : 11111111

http://www.nxp.com/documents/data_sheet/MF1S70YYX.pdf
Section 8.7.1
And the rights for block 0 should be the right hand bits of byte 6, 8, 7: F, F, 0 : 1, 1, 0 and the that's also what the existing code finds, 110 = 6 decimal

With 6 it should be readable by key A as well as B, but there's an exception at the bottom of the diagram in Section 8.7.3 of the spec.
But, reading fails.

So I added 6 to the list of access rights values to read using Key B and the hf mf dump 4 command worked for dumping the whole card!

I'm concerned that the access byte interpretation code is still wrong because it doesn't seem to take into account of data[6] of the access trailer block.

piwi · 2014-09-12 06:45:03

And the rights for block 0 should be the right hand bits of byte 6, 8, 7

No. According to my documentation that would be bit 4 of byte 7, bit 0 of byte 8 and bit 4 of byte 8 - which is 011 in your example (can only be read with key B). The access bits are stored redundantly. Byte 6 contains inverted bits only (as well as the right hand side of byte 7) and is therefore not required.

But wait... ah, I see... the bits in rights[] are stored in reverse order, i.e. C3C2C1 compared to the Mifare doc which uses C1C2C3. 011 is therefore 110 = 6 in dez. (and it had been 6 in the if clause before I blindly changed it to 3).

I reversed the bit order in rights[] and made another commit to github master.

asper · 2014-09-12 07:31:44

A question about hf mf chk:

How many blocks are there in a mifare 4k ? In the datsheet it says 32 sectors of 4 blocks and 8 sectors of 16 blocks... so when I use the hf mf chk with the "block number" option my possibility range is from 0 to 128+128 [255] ?

Last edited by asper (2014-09-12 07:32:18)

piwi · 2014-09-12 07:47:03

Possible range is 0 to 255.

johankosmos · 2014-09-12 11:25:13

Hi Carlijn your card uses AES instead of the crypto and can not be crack yet.
Data Encryption Standard" (DES) is the old mifare the new mifare cards have all AES.
this have min 128 bit and max 256 bit encryption
Greatings Johan Kosmos

johankosmos · 2014-09-12 11:42:08

even with a supercomputer, it would take 1 billion billion years to crack the 128-bit AES key using brute force attack

russ · 2014-09-12 15:59:58

Piwi: yes you are right, I was looking at this too quickly and didn't carefully look at all of 7 and 8. I'm glad you found the bug though! Thanks.

russ · 2014-09-12 16:22:56

Oh I don't see the commit on github. For my work today I can certainly reverse them.

piwi · 2014-09-13 08:14:44

Sorry. Pushed now.

And thanks for the testing. This was a nice example for community collaboration.

johankosmos · 2015-01-20 14:04:13

If you have still problems with the 4k mifare dump with the proxmark3 you can do this:
make a dumpfile with mfoc or mifare offline cracker
make a dumpkeys.bin file with winhex ram rom editor.
copy the key A and B files into 1 file merge it.
with mifare offline cracker you have 2 keys key A and key B separeted.
but with winhex you can merge them togetter into 1 file.
than if you have the dumpfile from mfoc or mifare ofline cracker rename the dumpfile to dumpdata.bin and the keys you merge togetter to dumpkeys.bin
and than start your proxmark 3 and do hf mf restore and your chinese mifare 4k will be written.
this is for Carlijn.
Greatings Johan

iceman · 2016-03-24 09:40:34

I'm not sure what your question to this thread is. If you read the title it says "resolved".
Or are you having problems with the latest version from GitHub and "hf mf dump"? In that case, please specify the details and start a new thread about it.

Proxmark3 community

Announcement

#51 2014-09-11 14:30:00

Re: [Resolved] hf mf dump for 4k cards broken?

#52 2014-09-11 14:46:08

Re: [Resolved] hf mf dump for 4k cards broken?

#53 2014-09-11 14:49:05

Re: [Resolved] hf mf dump for 4k cards broken?

#54 2014-09-11 14:51:42

Re: [Resolved] hf mf dump for 4k cards broken?

#55 2014-09-11 14:55:16

Re: [Resolved] hf mf dump for 4k cards broken?

#56 2014-09-11 15:47:50

Re: [Resolved] hf mf dump for 4k cards broken?

#57 2014-09-11 16:23:29

Re: [Resolved] hf mf dump for 4k cards broken?

#58 2014-09-11 20:20:54

Re: [Resolved] hf mf dump for 4k cards broken?

#59 2014-09-11 20:29:51

Re: [Resolved] hf mf dump for 4k cards broken?

#60 2014-09-11 20:45:15

Re: [Resolved] hf mf dump for 4k cards broken?

#61 2014-09-11 22:54:44

Re: [Resolved] hf mf dump for 4k cards broken?

#62 2014-09-12 06:45:03

Re: [Resolved] hf mf dump for 4k cards broken?

#63 2014-09-12 07:31:44

Re: [Resolved] hf mf dump for 4k cards broken?

#64 2014-09-12 07:47:03

Re: [Resolved] hf mf dump for 4k cards broken?

#65 2014-09-12 11:25:13

Re: [Resolved] hf mf dump for 4k cards broken?

#66 2014-09-12 11:42:08

Re: [Resolved] hf mf dump for 4k cards broken?

#67 2014-09-12 15:59:58

Re: [Resolved] hf mf dump for 4k cards broken?

#68 2014-09-12 16:22:56

Re: [Resolved] hf mf dump for 4k cards broken?

#69 2014-09-13 08:14:44

Re: [Resolved] hf mf dump for 4k cards broken?

#70 2015-01-20 14:04:13

Re: [Resolved] hf mf dump for 4k cards broken?

#71 2016-03-24 09:40:34

Re: [Resolved] hf mf dump for 4k cards broken?

Board footer