Locked one sector of mifare card, cannot read

samburner3 · 2017-02-14 14:09:48

Hi there.

So I was playing around with my magic UID 1k mifare card, and decided to put some custom data onto the card, then lock it with a random key (07f2f83b8285e5) to test out the cracking ability of the Proxmark3.

I have compiled and all up and running.

First I used hf mf chk to make sure all the keys were default FFF... they were.

Then I dumped the card (hf mf dump)

I then used a hex editor (and hex converter) to write my name into the first block of sector 2.

I then locked the sector by placing my random key in the sector 2 A key position.

I then saved the file as dumpkeys.bin

I then restored the file onto the card using hf mf restore.

I wanted to test to make sure I could NOT read sector 2 since I locked it.

proxmark3> hf mf chk *1 A ffffffffffff
chk key[ 0] ffffffffffff          
--sector: 0, block:  3, key type:A, key count: 1           
Found valid key:[ffffffffffff]          
--sector: 1, block:  7, key type:A, key count: 1           
Found valid key:[ffffffffffff]          
--sector: 2, block: 11, key type:A, key count: 1           
Found valid key:[ffffffffffff]
--sector: 3, block: 15, key type:A, key count: 1           
Found valid key:[ffffffffffff]          
--sector: 4, block: 19, key type:A, key count: 1

Although as you can see it found a valid key for sector 2, which I had locked?

I thought I had not locked it correctly, so I tried to dump the card back out.

proxmark3> hf mf dump
|-----------------------------------------|          
|------ Reading sector access bits...-----|          
|-----------------------------------------|          
#db# READ BLOCK FINISHED          
#db# READ BLOCK FINISHED          
#db# Cmd Error: 04          
#db# Read block error          
#db# READ BLOCK FINISHED          
Could not get access rights for sector  2. Trying with defaults...          
#db# READ BLOCK FINISHED          
#db# READ BLOCK FINISHED          
#db# READ BLOCK FINISHED          
#db# READ BLOCK FINISHED          
...

but of course it could not read sector 2 as I had locked it. SO I had locked it correctly.

Then why did the

hf mf chk

comand claimed to have found a valid key [ffffffffffff] for sector 2??

I then tried the nested attack, targeting block 11 (sector 2)*:

*Am I correct assuming block 11 is in fact a part of sector 2?

proxmark3> hf mf nested o 0 A ffffffffffff 11 A
--target block no: 11, target key type:A           
uid:73b275e0 trgbl=11 trgkey=0          
Found valid key:ffffffffffff

and like the hf mf chk, it found a valid key for block 11. (Again block 11 = sector 2??)
However of course sector 2 is locked by my custom key as I can not dump it...

Any clues?

samburner3 · 2017-02-14 14:13:58

I just realized my custom key was too long 14 bits (07f2f83b8285e5) when looking at the html script... should be 12 bits?

Although the first 2 red values are FF, where as I have locked it as (07f2f83b8285) (e5) where e5 is in the red position.
Could this contribute to the problem?

piwi · 2017-02-14 21:28:41

I then saved the file as dumpkeys.bin

You should have saved it as dumpdata.bin

*Am I correct assuming block 11 is in fact a part of sector 2?

Yes. Sector 0 = Blocks 0 to 3, Sector 1 = Blocks 4 to 7, Sector 2 = Blocks 8 to 11, ...

I just realized my custom key was too long 14 bits (07f2f83b8285e5) when looking at the html script... should be 12 bits?

It should be 48 Bits = 6 Bytes = 12 Hex-Characters

samburner3 · 2017-02-15 12:32:20

piwi wrote:

samburner3 wrote:
I then saved the file as dumpkeys.bin
You should have saved it as dumpdata.bin

Yes sorry I did. Have it saved as dumpdata.bin, typo in forum post.

piwi wrote:

samburner3 wrote:
*Am I correct assuming block 11 is in fact a part of sector 2?
Yes. Sector 0 = Blocks 0 to 3, Sector 1 = Blocks 4 to 7, Sector 2 = Blocks 8 to 11, ...

Great

piwi wrote:

samburner3 wrote:
I just realized my custom key was too long 14 bits (07f2f83b8285e5) when looking at the html script... should be 12 bits?
It should be 48 Bits = 6 Bytes = 12 Hex-Characters

Sorry yes, should have said Hex-Characters, not bits. (Wrote this post late at night after feeling frustrated).

So in block 11 I have my custom key A in the first 12 Hex-Characters, but also in the next position as 2 extra hex Characters.
What do these values between key A and B refer to?

If I accidentally edited these between values does that mean that sector is potentially bricked?

I will try hf mf rdsc (Read MIFARE classic sector) on that sector with my custom key A tomorrow.

Last edited by samburner3 (2017-02-15 12:33:31)

piwi · 2017-02-15 14:28:14

Hf mf restore reads keys from dumpkeys.bin and all the rest from dumpdata.bin.

Why don't you use hf mf wrsc to write sectors?

iceman · 2017-02-15 15:30:01

My guess its because there are no hf mf wrsc command in PM3 Master...

samburner3 · 2017-02-16 06:35:10

I set the correct keys in dumpkeys.bin and used hf mf restore, but could still not read/write to sector 2.

piwp wrote:

Why don't you use hf mf wrsc to write sectors?

Would that be any different? Yes I have the PM3 Master so haven't been able to try.

I think I may have bricked my sector 2 (blocks 8..11) as I accidentally set the block 11 first access byte to e5 (from the default FF).

Block 11: <Key A 6-hex-bytes><Access Conditions (4-hex bytes)><Key B 6-hex-bytes>
<07 f2 f8 3b 82 85> <e5 FF FF FF> <FF FF FF FF FF FF>

In the MIFARE Classic datasheet says

With each memory access the internal logic verifies the format of the access conditions. If it detects a format violation the whole sector is irreversibly blocked.

I assume the byte e5 is not a valid format. The default is FF.

Could someone explain the formats and how it relates to hex bytes?
On the datasheet (from page 12) is lists the access byte configurations, however it lists it has 0's and 1's (binary)

Last edited by samburner3 (2017-02-16 06:38:06)

iceman · 2017-02-16 10:42:12

rtfm? Not the easiest thing to figure out, luckily there is a accessbit tool. Don't have the link Should be linked somewhere on this forum

piwi · 2017-02-18 17:37:50

My guess its because there are no hf mf wrsc command in PM3 Master...

That would indeed be a cumbersome command, requiring 64 Hexbytes as parameter. I meant hf mf wrbl. That would be easier than editing dumpdata.bin and dumpkeys.bin.

There are only three bytes for the access conditions (the fourth "is available for user data"). And yes, you have created a corrupt combination of access bits and bricked sector 2.

The link to which iceman refers to is http://www.proxmark.org/forum/viewtopic.php?id=1408

If you have trouble transforming binary to hex and vice versa: the Windows calculator can do this in Programmers Mode.

iceman · 2017-02-18 17:57:27

All those links has a tendency to become obsolete, so I've taken the liberty to collect a few of these very essential tools here http://www.icedev.se/pm3.aspx

Proxmark3 community

Announcement

#1 2017-02-14 14:09:48

Locked one sector of mifare card, cannot read

#2 2017-02-14 14:13:58

Re: Locked one sector of mifare card, cannot read

#3 2017-02-14 21:28:41

Re: Locked one sector of mifare card, cannot read

#4 2017-02-15 12:32:20

Re: Locked one sector of mifare card, cannot read

#5 2017-02-15 14:28:14

Re: Locked one sector of mifare card, cannot read

#6 2017-02-15 15:30:01

Re: Locked one sector of mifare card, cannot read

#7 2017-02-16 06:35:10

Re: Locked one sector of mifare card, cannot read

#8 2017-02-16 10:42:12

Re: Locked one sector of mifare card, cannot read

#9 2017-02-18 17:37:50

Re: Locked one sector of mifare card, cannot read

#10 2017-02-18 17:57:27

Re: Locked one sector of mifare card, cannot read

Board footer