Wiping Magic Ring

Support
1

I’m still pretty new to RFID and am not 100% on what I’m doing, so hopefully I didn’t break anything, but I’m reading that it’s possible that I did and hope someone here smarter than me can help!

I successfully cloned a Mifare card to the ring last time I traveled using autopwn and restore - Worked beautifully. Traveling again and tried the same process and the key failed to restore, giving auth errors on restore. After trying a few things I’m getting write errors when writing blocks individually. I’m now worried I bricked something.

How can I verify that I didn’t break something and how can I go about wiping the ring to start from square one?

Thanks in advance!

2

If I remember right the rings are gen2 backdoor?
You have to be extra careful when changing block 0 other ones should be easily repairable. And even for potentially bricked ones there were some recovery lua scripts included with proxmark if I remember right. But I know more about gen1 backdoors so someone with more experience with gen2 will have better details.

3

Try to do an hf mf autopwn and share the contents of the ring (if there is no sensitive content.)

It is possible that you locked one or more of the sectors and the ring will no longer be writable. Sharing the error you are getting while trying to write to blocks may be helpful as well.

1 Like
4

Autopwn recovers most keys correctly

Blocks 1-3 are not actually FFFFFFFFFFFF so I’ll have to recover those, but that’s not my main concern.

Attempting to write data to block 0 using key A results in ‘Write block error’

…but using key B returns no error.

Is that normal? If so, my biggest problem is not correctly understanding what I’m doing.

However, attempting to write to some blocks returns ‘Auth error’

Zipped .json file uploaded in case that helps.
hf-mf-01020304-dump.json.zip (955 Bytes)

Thank you again in advance!

5

This would be expected behavior based on your access bits. I’ll deconstruct it a bit here for you. Based on documentation for the Mifare Classic 1k.

The full sector trailer for Sec0 is in Blk3 which is A0A1A2A3A4A5787788C10D258FE90296

Key A            Access Bits  Key B
A0A1A2A3A4A5     787788C1     0D258FE90296

We first convert this hex string to binary bits:
787788C1 = 01111000011101111000100011000001

To make it a little more human readable:

Sec0
C2i  C1i
3210 3210
---- ----
0111 1000

C1   C3i
3210 3210
---- ----
0111 0111

C3   C2
3210 3210
---- ----
1000 1000

User Data
3210 3210
---- ----
1100 0001

(i at the end means inverse, i.e. C2 = 1000, so inverse would be 0111, which happens to be C2i)

According to the documentation this set of Access Bits means:

Blk0
Access bits = C1(0) C2(0) C3(0) = 100
Read by A|B
Write by B

So you can read Sector 0 with both keys, but only write to it with Key B, which is the behavior you see with you PM3. We can change these rules by changing the Access Bits, if they are able to be written themselves.

SecTrailer
Access bits = C1(3) C2(3) C3(3) = 001
Read/Write Access Bits by Key A.

Good! This means we can still change access bits with Key A.
We want Blk0 to be Read/Write by Key A|B, so C1(0) C2(0) C3(0) Needs to be 000 (unless you want it to be more restrictive.) 000 gives us full read/write/inc/dec/etc access by A|B.

So the new Access Bits would be:

Sec0
C2i  C1i
3210 3210
---- ----
0111 1001

C1   C3i
3210 3210
---- ----
0110 0111

C3   C2
3210 3210
---- ----
1000 1000

User Data
3210 3210
---- ----
1100 0001

Which translates to 01111001011001111000100011000001 = 796788C1

So the command to write this would be:

hf mf wrbl 3 A A0A1A2A3A4A5 A0A1A2A3A4A5796788C10D258FE90296

I claim no responsibility if this bricks your device, as I have not tested this command on a card myself, but I believe it should work. Do your own due diligence and don’t trust everything everyone tells you on the internet. :slight_smile:

Also, be careful when playing around with Access Bits on a gen2 chip. If you set them in a way that there is no access to write the Access Bits for the block anymore, there is no backdoor to save you. The block will be stuck forever.

Hope this helps you understand! Let me know if you have more questions.

1 Like
6

Block 15 is returning an auth error as the keys for that block are reported by your PM3 dump to be FFFFFFFFFFFF.

I think you may be confusing blocks with sectors. The structure of a Mifare Classic 1k is:
16 Sectors
4 Blocks per sector
16 Bytes per block

16 * 4 * 16 = 1024 Bytes = 1kb
Thus the name “1k”

There are two keys per sector, A and B.
So, I believe you saw the keys from the autopwn and thought the Sector 15’s keys were for block 15?

The correct way to ascertain which key(s) to use for a block is to find the Sector in which the block lies and use that sector’s keys. For block 15, that would be Sector 3, which has keys of FFFFFFFFFFFF.

7

Do you have a dump of the last card you loaded on to the ring?

Given its a gen2 it still behaves like a normal MFC so access bits are important. It may be that the card you loaded on to it last has set these bits in a particular way which is now causing issues. A dump of the last card on the ring would help determine what these access bits are and if they are the cause of your issues.

The proxmark has a built in command for understanding what the access bits mean in reality:
hf mf acl -d <3 hex>

Example:
image
The access writes are shown per block (under # heading) in that sector with the meaning explained (under access rights heading).
Each block can have different access conditions in the same sector thus being able to do one operation on one block doesnt mean this can be repeated to another block.

1 Like