Reset a UID Changable Magic Card

hheile · 2014-05-19 13:48:08

Hello,

i have some magic cards and put some data on it, which works really fine.
So, how can i set theese cards to default or better reset them to original state?

maybe, simply copy a "blank" card to the writen one?

thanks in advance

midnitesnake · 2014-05-19 14:18:44

From the source:

Usage: hf mf csetuid <UID 8 hex symbols> <w>
sample: hf mf csetuid 01020304 w
Set block data for magic Chinese card (only works with!!!)
If you want wipe card then add 'w' into command line.

Last edited by midnitesnake (2014-05-19 14:27:55)

hheile · 2014-05-20 07:07:23

midnitesnake you are the best, thank you very much

hheile · 2014-05-20 08:00:44

hi again,
i can successfully change the uid and wipe the card.
when i write to a chinese card, i recieve this:

Writing to block 62: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
#db# Cmd Error: 04
#db# Write block error
#db# WRITE BLOCK FINISHED
isOk:00

any help on this?

best regards

midnitesnake · 2014-05-20 15:07:00

block 62. hmmm, 4 sectors x 15 blocks =60 blocks , so if your card is a 1K hopefully it is wiped.

Not sure why (without investigating further), but looks like its trying to wipe the number of blocks equal to 4k card.

Last edited by midnitesnake (2014-05-20 15:07:43)

mojpoj · 2014-09-30 02:06:26

According to the data sheet, there are actually 16 sectors (including block 0 that is).

16 x 4 = 64

I'm having the same issue as OP.

#db# Can't select card
Can't set UID. error=2

Software version: r854
Firmware version: 756

Tried both linux and win. Same error. At some point yesterday I managed to write to the card, I can read the card and see the dump from a card I'm trying to clone.

Even if the block 0 was OTP, I would be able to write to different blocks, which I can't do under MF or 14A write options.

asper · 2014-09-30 06:08:52

Update the firmware to the software release. R0.0.5(firmware+software) is suggested.

Last edited by asper (2014-09-30 06:09:24)

mojpoj · 2014-10-02 04:07:29

asper wrote:

Update the firmware to the software release. R0.0.5(firmware+software) is suggested.

Did that, thanks for pointing out I'm behind a few dozen versions

I have 2 S 50's (4 Byte UID - Mifare Classic 1K / Plus 2K) magic cards purchased about a year ago.

I cloned a tag to one of the cards, placed it on the target system and it worked. But after about 15 seconds the target system threw an error and rejected it. Every time I use the card, it grants access for about 15-20 seconds and then throws the same error. The system needs the card to be there to work and I expected it would continuously check the card, read and write to it.

So, I put the card back on the PM3 and dumped it again, then did a diff compare against the original dump. I can see there was one line of data added around block 50. Every thing else is identical.

Then I went to clone a different tag, but I'm hitting a major road block. The magic card won't let me write to the key blocks and overwrite the keys on blocks 3,7,11... and so on. Trying the csetblk command, I get
"Can't select card
Can't write block. error=2"

What I can do...
Write any of the non-key blocks, but only through the classic commands using the keys that are already there.

What I can't do...
Write any of the key blocks using the classic commands using the current valid key.
Write any block period using the magic card commands. (This has worked before, the script told me it didn't work, but when I checked, it had in fact written the blocks)

I also tried the fix corrupt block zero command to see what would happen and that doesn't do anything.

Stumped.

Could the access system have detected the magic card and bricked it? Has anyone experienced this?

R0.0.5 firmware and OS. Win 7.

asper · 2014-10-02 06:03:21

Magic cards are "choosy", try to execute commands putting the card at 1-1, 5 cm from the antenna and not directly over it.

The access system, if programmed, can detect a magic card only if it doesn't use a standard rfid chip to detect it (standard chips are not able to correctly send the magic commands because they are 7bit).

Last edited by asper (2014-10-02 06:03:38)

mojpoj · 2014-10-02 13:06:36

asper wrote:

Magic cards are "choosy", try to execute commands putting the card at 1-1, 5 cm from the antenna and not directly over it.
The access system, if programmed, can detect a magic card only if it doesn't use a standard rfid chip to detect it (standard chips are not able to correctly send the magic commands because they are 7bit).

All good to know. Target system is about 3-4 years old, doubt they would have planned for the magic cards, but possible.

I had read another forum post, by you I believe, about adjusting the distance and have learned the optimal distance, that was a good tip. I use a spacer to hold the card off the PM3 HF Antenna about a half inch.

More testing today.

Here is a read of the target card...

[== Undefined ==]
proxmark3> hf 14a reader
ATQA : 0f 01          
 UID : 42 d2 71 14           
 SAK : 01 [2]          
proprietary non iso14443-4 card found, RATS not supported

And a read of the magic card...

[== Undefined ==]
proxmark3> hf 14a reader
ATQA : 00 04          
 UID : 42 d2 71 14           
 SAK : 08 [2]          
TYPE : NXP MIFARE CLASSIC 1k | Plus 2k SL1          
SAK incorrectly claims that card doesn't support RATS          
 ATS : 09 78 00 91 02 da bc 19 10 f0 05           
       -  TL : length is 9 bytes          
       -  T0 : TA1 is present, TB1 is present, TC1 is present, FSCI is 8 (FSC = 256)          
       - TA1 : different divisors are supported, DR: [], DS: []          
       - TB1 : SFGI = 1 (SFGT = 8192/fc), FWI = 9 (FWT = 2097152/fc)          
       - TC1 : NAD is NOT supported, CID is supported          
       -  HB : da bc 19 10

I did notice the ATQA and SAK differ.

Read the spec on ATQA/SAK and it appears it could be used (not recommended by spec) to identify a valid tag for the target system.

(http://www.nxp.com/documents/application_note/AN10833.pdf)

I also realize the target card does not come up as a Mifare, but it has 16 sectors and 64 blocks, and responds to all read write requests with the keys. The dark side attack works fine on it, and the nested attack works fine using the key found from the dark side attack. So, I'm sure it's a Mifare 1K with an altered ATQA/SAK.

Is there anyway to change a ATQA/SAK on a Mifare magic card? I would like to test and see if that makes a difference.

Thanks.

asper · 2014-10-02 13:34:35

Yes; those data are written in sector0block0

Assuming this example secotr0block0: 01 02 03 04 04 88 04 00 00 00 00 00 00 00 01 10
01 02 03 04 = UID
04 = 1st 4 bytes xor
88 = SAK
04 00 (reversed read) = ATQA
00 00 00 00 00 00 00 = formally unknown but probably manufacturing data (ex. site code facility, etc.)
01 10 = production week/year (unofficial info)

So changing sector0block0 bytes will also change the data you need to change.

Are you trying to clone skylanders toys ?

Last edited by asper (2014-10-02 13:42:18)

mojpoj · 2014-10-02 19:51:54

Well, don't really want to say specifically. But, what if it is?

asper · 2014-10-02 20:04:57

That atqa+sak is almost specific for NXP NTP3XXX rfid tag used by a specific game manufacturer; technically it should not be a mifare tag but it can behave like it; this tag is almost unknown and very few info is available on the www until now. If you try to do something and success (ex. clone a toy you own) please tell us if it works or not.
Data contained inside those tags is crypted so, if you don't know how to decrypt/edit/re-encrypt, cloning is the only thing you can do; and no, I don't know how to decrypt/encrypt

Last edited by asper (2014-10-02 20:07:52)

mojpoj · 2014-10-02 20:09:49

I'm not sure your breakdown is exactly right...

The magic card and the original tag have the exact same block zero, but you can see from my post above, they have different ATQA's and SAK's.

I have to believe there is something more to the ATQA and SAK.

Based on your info I just checked the cards again and verified they have identical block zero's. All blocks for that matter.

mojpoj · 2014-10-02 20:13:08

asper wrote:

That atqa+sak is almost specific for NXP NTP3XXX rfid tag used by a specific game manufacturer; technically it should not be a mifare tag but it can behave like it; this tag is almost unknown and very few info is available on the www until now. If you try to do something and success (ex. clone a toy you own) please tell us if it works or not.
Data contained inside those tags is crypted so, if you don't know how to decrypt/edit/re-encrypt, cloning is the only thing you can do; and no, I don't know how to decrypt/encrypt

I posted before reading this. ^^

Thanks for the additional info. If I figure this thing out, I'll let you know.

mojpoj · 2014-10-02 20:14:53

I can't seem to PM you, Asper. Probably due to low post count on my end.

asper · 2014-10-02 20:22:22

Try to post a correct sector0block0 dump of both tags here; if they really are the same this specific toy-tag is different from mifare. Unfortunately no pm in this forum.

Last edited by asper (2014-10-02 20:23:42)

mojpoj · 2014-10-02 20:35:40

HW Version, SW is also R0.0.5

[== Undefined ==]
proxmark3> hw ver
#db# Prox/RFID mark3 RFID instrument                 
#db# bootrom: /-suspect 2014-09-19 10:31:37                 
#db# os: /-suspect 2014-09-13 11:21:04                 
#db# HF FPGA image built on 2014/ 6/19 at 21:26: 2                 
uC: AT91SAM7S256 Rev B          
Embedded Processor: ARM7TDMI          
Nonvolatile Program Memory Size: 256K bytes          
Second Nonvolatile Program Memory Size: None          
Internal SRAM Size: 64K bytes          
Architecture Identifier: AT91SAM7Sxx Series          
Nonvolatile Program Memory Type: Embedded Flash Memory

First Sector read is from the original Tag, Second is the clone I made...

[== Undefined ==]
proxmark3> hf mf rdsc 0 A 4b0b20107ccb
--sector no:0 key type:A key:4b 0b 20 10 7c cb            
#db# READ SECTOR FINISHED                 
isOk:01          
data   : 42 d2 71 14 f5 81 01 0f c3 85 14 92 4d 80 12 11           
data   : 13 00 00 00 19 74 01 60 9f 62 01 00 00 00 22 29           
data   : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00           
trailer: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00           
proxmark3> 
proxmark3> hf mf rdsc 0 A 4b0b20107ccb
--sector no:0 key type:A key:4b 0b 20 10 7c cb            
#db# READ SECTOR FINISHED                 
isOk:01          
data   : 42 d2 71 14 f5 81 01 0f c3 85 14 92 4d 80 12 11           
data   : 13 00 00 00 19 74 01 60 9f 62 01 00 00 00 22 29           
data   : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00           
trailer: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00           
proxmark3>

Anything insightful there?

Appreciate the help.

asper · 2014-10-02 21:04:54

If the darkside works it is surely a mifare with modified atqa+sak.

I think that pm3 is reporting wrong atqa+sak for the chinese tag.

3 things to try:

1 - if you have a NFC capable Android mobile phone supporting mifare try to ues NFC TagInfo app and post the results/screenshots
2 - try the cloned toy inside the game and see if it works.
3 - if you can, try the chinese mifare card with another desktop reader and get the atqa+sak (quite the same as reading it with a mobile phone)

Please modify your previous posts and hide the KeyA you used.

Last edited by asper (2014-10-02 21:08:20)

mojpoj · 2014-10-02 21:15:53

I posted above. The clone DOES work in the target system, access is given.

However, after about 20 seconds, the system senses it's invalid somehow and kicks it out.

Removing and placing the cloned tag back on the system, it works again and the system is usable for another 20 seconds. I can repeat this all day long, data is even being written to the cloned tag.

After putting the magic card clone on the system, I can no longer overwrite the key blocks with either the correct key or the magic write option. It's like the card is locked down now.

If I use the correct key, I can write data to the magic card data blocks, just not the key blocks.

If I can get the magic card back to all zero's, I can continue troubleshooting/testing.

My Nexus 7 has NFC on it I believe, so I'll give the app a shot on there and post what I get.

asper · 2014-10-02 21:24:08

I posted above. The clone DOES work in the target system, access is given.

You are right, I missed it.

I just tried with a chinese card and the tag is correctly reported with its modified atqa+sak (the same you posted above) so pm3 is working fine (same r.0.0.5). You should check if the chinese card is correctly written when you modify sector0block0.

If I use the correct key, I can write data to the magic card data blocks, just not the key blocks.

Changes in sector trailer ? (the sector that owns the protection bits)

Last edited by asper (2014-10-02 21:25:02)

mojpoj · 2014-10-02 21:29:02

Changes in sector trailer ? (the sector that owns the protection bits)

Yes, I can't write the trailer with either the proper existing key, or with the magic write command. Something I could do prior to putting it in the target system.

Using that app, the magic card is reported as "Mifare Classic is not supported on your device."

The original tag is read the same as posted above.

[== Undefined ==]
proxmark3> hf 14a reader
ATQA : 0f 01          
 UID : 42 d2 71 14           
 SAK : 01 [2]          
proprietary non iso14443-4 card found, RATS not supported

Last edited by mojpoj (2014-10-02 21:29:39)

asper · 2014-10-02 21:33:32

Ok, so your mobile phone doesn't support mifare but atqa+sak should be given (try to search in the other app sections after the error - unfortunately I cannot test this condition).

You should also give a try to TagInfo (it is different from the above one).

EDIT

I can't write the trailer with either the proper existing key, or with the magic write command.

You should always be able to write with magic commands... there should be something wrong during the write sequence. Try to position the tag in another way.

Last edited by asper (2014-10-02 21:36:11)

asper · 2014-10-02 21:43:17

You can find me on irc for the next 60 mins: http://webchat.freenode.net/ channel #proxmark3

mojpoj · 2014-10-02 21:59:17

asper wrote:

Ok, so your mobile phone doesn't support mifare but atqa+sak should be given (try to search in the other app sections after the error - unfortunately I cannot test this condition).

Yes, Nexus doesn't support Mifare classic.

asper wrote:

You should always be able to write with magic commands... there should be something wrong during the write sequence. Try to position the tag in another way.

I realize this, that's the problem I'm stuck at. I have tried different heights and positions. Nothing will work. I went back to the 756 firmware/software, and tried a couple in between. I can no longer write to either of the two classic magic cards I have after cloning them and putting them in the target system.

I get this every time with the magic write command...

[== Undefined ==]
proxmark3> hf mf csetblk 3 00000000000000000000000000000000 
--block number: 3 data:00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00           
#db# Can't select card                 
Can't write block. error=2

And this with the regular write, using the proper key on blocks 0,1,2, & 3...

[== Undefined ==]
proxmark3> hf mf wrbl 3 A 4b0b20107ccb 00000000000000000000000000000000
--block no:3, key type:A, key:4b 0b 20 10 7c cb           
--data: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00           
#db# Cmd Error: 04                 
#db# Write block error                 
#db# WRITE BLOCK FINISHED                 
isOk:00

But writing zero's to block 6 works fine with the proper key...

[== Undefined ==]
proxmark3> hf mf wrbl 6 A 6b46a9914101 00000000000000000000000000000000
--block no:6, key type:A, key:6b 46 a9 91 41 01           
--data: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00           
#db# WRITE BLOCK FINISHED                 
isOk:01

And I have tried at least a dozen times on each block to make sure it was the card improperly positioned or at the incorrect height. I have a perfect spacer (empty SD chip holder).

asper · 2014-10-02 22:05:50

I had the same problem and it was "positioning": bytes randomly written to the tag; if you altered sector0block0 bytes (expecially atqa+sak ones) with certain values the card won't respond and the only way is to provide a full sector0block0 reset (use provided script in the GUI if you are using windows). The script will results in an error but the block is correctly written if the tag position is correct. This is the post explaining what is probably happening.

Also post the result of a tune command with and without a tag over the antenna.

Last edited by asper (2014-10-06 14:47:35)

piwi · 2014-10-06 14:15:09

hf mf csetblk 3 00000000000000000000000000000000

I don't know if this applies to Magic Chinese Cards as well: Block 3 is a sector trailer and all 00's is illegal for the Access Condition Bits and illegal Access Condition Bits means access denied for this sector. For "normal" Mifare cards this is an effective way to brick it.

asper · 2014-10-06 14:47:23

Magic cards'sector trailer is always rewritable; I guess he has a poor antenna + bad positioning leading to wrong bytes to be written inside the tag.

Proxmark3 community

Announcement

#1 2014-05-19 13:48:08

Reset a UID Changable Magic Card

#2 2014-05-19 14:18:44

Re: Reset a UID Changable Magic Card

#3 2014-05-20 07:07:23

Re: Reset a UID Changable Magic Card

#4 2014-05-20 08:00:44

Re: Reset a UID Changable Magic Card

#5 2014-05-20 15:07:00

Re: Reset a UID Changable Magic Card

#6 2014-09-30 02:06:26

Re: Reset a UID Changable Magic Card

#7 2014-09-30 06:08:52

Re: Reset a UID Changable Magic Card

#8 2014-10-02 04:07:29

Re: Reset a UID Changable Magic Card

#9 2014-10-02 06:03:21

Re: Reset a UID Changable Magic Card

#10 2014-10-02 13:06:36

Re: Reset a UID Changable Magic Card

#11 2014-10-02 13:34:35

Re: Reset a UID Changable Magic Card

#12 2014-10-02 19:51:54

Re: Reset a UID Changable Magic Card

#13 2014-10-02 20:04:57

Re: Reset a UID Changable Magic Card

#14 2014-10-02 20:09:49

Re: Reset a UID Changable Magic Card

#15 2014-10-02 20:13:08

Re: Reset a UID Changable Magic Card

#16 2014-10-02 20:14:53

Re: Reset a UID Changable Magic Card

#17 2014-10-02 20:22:22

Re: Reset a UID Changable Magic Card

#18 2014-10-02 20:35:40

Re: Reset a UID Changable Magic Card

#19 2014-10-02 21:04:54

Re: Reset a UID Changable Magic Card

#20 2014-10-02 21:15:53

Re: Reset a UID Changable Magic Card

#21 2014-10-02 21:24:08

Re: Reset a UID Changable Magic Card

#22 2014-10-02 21:29:02

Re: Reset a UID Changable Magic Card

#23 2014-10-02 21:33:32

Re: Reset a UID Changable Magic Card

#24 2014-10-02 21:43:17

Re: Reset a UID Changable Magic Card

#25 2014-10-02 21:59:17

Re: Reset a UID Changable Magic Card

#26 2014-10-02 22:05:50

Re: Reset a UID Changable Magic Card

#27 2014-10-06 14:15:09

Re: Reset a UID Changable Magic Card

#28 2014-10-06 14:47:23

Re: Reset a UID Changable Magic Card

Board footer