Proxmark3 community

Winds

Member

Registered: 2020-01-28

Posts: 53

The Access Conditions Sheet - MUST HAVE

Dear Members,

Better to have an sheet with the AC's then each time trying to find calculations in MCT.

You have each 4 line with AC's starting from 0. How to write it?

For the first sector this should be:

KeyA

hf mf wrbl 3 A FFFFFFFFFFFF FFFFFFFFFFFFFF078000FFFFFFFFFFFF

KeyB

hf mf wrbl 3 B FFFFFFFFFFFF FFFFFFFFFFFF7C378800FFFFFFFFFFFF

Sheet: https://youtu.be/FKf45oSDIfM

Last edited by Winds (2020-07-18 00:57:31)

mwalker

Moderator

Registered: 2019-05-11

Posts: 318

Re: The Access Conditions Sheet - MUST HAVE

Careful here.  If you send the wrong permissions you can brick the sector or block.

I would prefer people understand what is being set and to understand rather then just cut n paste.

Can you explain what the command does and what permissions it sets, and maybe why you think it "should be"
e.g. the assumption is that the A key already has write permissions and the A key is FFFFFFFFFFFF
then it assumes the user wants the new A and B keys to be FFFFFFFFFFFF
this can be explained  with a break down.
e.g.
If your existing A key has full write access and the key is FFFFFFFFFFFF, and you wish to set the new keys to FFFFFFFFFFFF then...

Proxmark Command   Block  Use A Key    Current A Key   New A Key     Sector Permissions   User Data    New B Key
hf mf wrbl           3        A        FFFFFFFFFFFF    FFFFFFFFFFFF        FF0F00             00       FFFFFFFFFFFF

.... then what permissions are set by the Permissions FF0F00 e.g. what key has what access

I do note that the Mifare classic as the default access bit set to 0xFF0780

Your access bits seem to set the access for the Sector Tailor as follows
Key A - never be read, written with Key A
Access Bits - read by key A, never write     <--- No keys have write access to the access bits, thus locked
Key B - read by key A, write Key A

Verses the default
Key A - never be read, written by key A (same)
Access Bits - read by Key A, write by Key A    <--- Key A has write access to the access bits, thus not locked.
Key B - Read by key A, write by Key A

So, it seems that with your value you want be able to change the access bits (after its applied) as no key has write access to them.

Winds

Member

Registered: 2020-01-28

Posts: 53

Re: The Access Conditions Sheet - MUST HAVE

Careful here.  If you send the wrong permissions you can brick the sector or block.

I would prefer people understand what is being set and to understand rather then just cut n paste.

Can you explain what the command does and what permissions it sets, and maybe why you think it "should be"
e.g. the assumption is that the A key already has write permissions and the A key is FFFFFFFFFFFF
then it assumes the user wants the new A and B keys to be FFFFFFFFFFFF
this can be explained  with a break down.
e.g.
If your existing A key has full write access and the key is FFFFFFFFFFFF, and you wish to set the new keys to FFFFFFFFFFFF then...

Proxmark Command   Block  Use A Key    Current A Key   New A Key     Sector Permissions   User Data    New B Key
hf mf wrbl           3        A        FFFFFFFFFFFF    FFFFFFFFFFFF        FF0F00             00       FFFFFFFFFFFF

.... then what permissions are set by the Permissions FF0F00 e.g. what key has what access

I do note that the Mifare classic as the default access bit set to 0xFF0780

Your access bits seem to set the access for the Sector Tailor as follows
Key A - never be read, written with Key A
Access Bits - read by key A, never write     <--- No keys have write access to the access bits, thus locked
Key B - read by key A, write Key A

Verses the default
Key A - never be read, written by key A (same)
Access Bits - read by Key A, write by Key A    <--- Key A has write access to the access bits, thus not locked.
Key B - Read by key A, write by Key A

So, it seems that with your value you want be able to change the access bits (after its applied) as no key has write access to them.

Yeah sory about this one. Who not working they did't got err Seems you had broke your card

Honestly play with:

FFFFFFFFFFFF FF0780 00 FFFFFFFFFFFF

Sure, the right rules for use is without blocking AC's.

About explaining, my opinion you no need to count 32 symbols with empty byte, just once see how it's works and use it native and solid.Exactly no need to shift bytes in your mind, that's why a table way.

Last edited by Winds (2020-07-18 01:02:34)

iceman

Administrator

Registered: 2013-04-25

Posts: 9,537

Website

Re: The Access Conditions Sheet - MUST HAVE

Since you shouldn't trust one source of information,   it can mislead you,  make sure to verify stuff from multiple sources.

Like using the lua access script, or why not some online services like there.

Where I recommend ppl to use 0xFFFF's excellent source cardinfo.

1. http://cardinfo.barkweb.com.au/index.ph … =19&sub=20
2. http://calc.gmss.ru/Mifare1k/

mwalker

Moderator

Registered: 2019-05-11

Posts: 318

Re: The Access Conditions Sheet - MUST HAVE

@Winds : "...Seems you had broke your card..."

Not me, it just looked wrong non-default, so i checked it before others had issues.
Using a card with the backdoor commands, you can recover, so I also tested and confirmed that it would in fact lock the access for that sector via normal mifare commands; then recovered using the backdoor commands.

But if executed on a real mifare classic, then you would not be able to recover.

Keep in mind that some systems can check things such as the access bits and if not what they expect will assume a clone card and not work.  Some people will be trying to create a card to use in their own systems, as such will want to lock down things in production.

As such, I think things should be checked as well as explaining the reason why you may want to do it.
e.g. To set your mifare card back to defaults then send .....
But, if its a real card you may not be able to change things depending on its history.  e.g. if the card already has different keys, then you would need to use those keys and not FFFFFFFFFFFF.   i.e. find the keys first.

Winds

Member

Registered: 2020-01-28

Posts: 53

Re: The Access Conditions Sheet - MUST HAVE

Unfortunately at the moment mass market have no 7byte uid with majic backdoor
to clear all blocks, maybe that's some of rarely.

Winds

Member

Registered: 2020-01-28

Posts: 53

Re: The Access Conditions Sheet - MUST HAVE

PS the http://cardinfo.barkweb.com.au/ power is amazing!