[solved] Changeable UID card not changing...

samburner3 · 2017-02-18 14:16:04

Hey Hey, I got some tags that claim to be UID Changeable, but have not been able to change the UID. Before I complain to the seller I wanted to check with you guys that I am taking the correct steps to find out.

FIRSTly, Im sure these UID tags are not 'generation1.' as answers to chinese magic backdoor commands: NO,
and setting uid for magic card does not work.

proxmark3> hf mf csetuid 01020304
--wipe card:NO uid:01 02 03 04
#db# halt error. response len: 1
#db# Halt error
Couldn't get old data. Will write over the last bytes of Block 0.
new block 0: 01 02 03 04 04 00 00 00 00 00 00 00 00 00 00 00
#db# halt error. response len: 1
#db# Halt error
Can't set UID. error=2

^^In fact after running that command it seems to brick the card:

proxmark3> hf search

#db# ISO14443A Timeout set to 1050 (9ms)
Card doesn't support standard iso14443-3 anticollision
ATQA : 00 00

no known/supported 13.56 MHz tags found

proxmark3> hf mf rdbl 0 A ffffffffffff
--block no:0, key type:A, key:ff ff ff ff ff ff
#db# ISO14443A Timeout set to 1050 (9ms)
#db# rand tag nonce len: 0
#db# Auth error
#db# READ BLOCK FINISHED
isOk:00

Fine so I must have generation2 in that case.

*Try next UID changeable card (since last one was bricked^^)
Sector 0 is unlocked:

--sector: 0, block: 3, key type:A, key count:13
Found valid key:[ffffffffffff]

However writing block 0 does not work in either hf mf restore or simple hf mf wrbl:

proxmark3> hf mf wrbl 0 A FFFFFFFFFFFF d7048b01590804008500000000000000
--block no:0, key type:A, key:ff ff ff ff ff ff
--data: d7 04 8b 01 59 08 04 00 85 00 00 00 00 00 00 00
#db# Cmd Error: 04
#db# Write block error
#db# WRITE BLOCK FINISHED
isOk:00

Any ideas as to why?

Also strangely when reading sector 0's keys (block 3) the A key is show as 0's when is should obviously be F's as I just authenticated using key A all F's.
Shows same output if I authenticate with key B as all F's.
This seems to happen in all sectors..?

proxmark3> hf mf rdbl 3 A FFFFFFFFFFFF
--block no:3, key type:A, key:ff ff ff ff ff ff
#db# ISO14443A Timeout set to 1050 (9ms)
#db# rand tag nonce len: 4
#db# auth uid: d7048b01 nt: 9421cf74
#db# READ BLOCK FINISHED
isOk:01 data:00 00 00 00 00 00 ff 07 80 69 ff ff ff ff ff ff

OK so I cannot set UID via csetuid or normal wrbl on block 0 with correct keys...

However the card IS uid changeable because I used my other hand held machine to read the ID from one card and write to this card. Then when I do hf search on the proxmark, they are the same UID.
http://www.ebay.com.au/itm/122178599856

SO am I missing something here? I beleive I should be able to change the UID with the proxmark???

Version info:

Prox/RFID mark3 RFID instrument          
bootrom: master/v2.2.0-282-g3e50af4-suspect 2017-02-18 07:34:13
os: master/v2.2.0-282-g3e50af4-suspect 2017-02-18 07:34:14
LF FPGA image built for 2s30vq100 on 2015/03/06 at 07:38:04
HF FPGA image built for 2s30vq100 on 2015/11/ 2 at  9: 8: 8
          
uC: AT91SAM7S512 Rev B          
Embedded Processor: ARM7TDMI          
Nonvolatile Program Memory Size: 512K bytes. Used: 189561 bytes (36). Free: 334727 bytes (64).          
Second Nonvolatile Program Memory Size: None          
Internal SRAM Size: 64K bytes          
Architecture Identifier: AT91SAM7Sxx Series          
Nonvolatile Program Memory Type: Embedded Flash Memory

Tune with card on:

proxmark3> hw tune

Measuring antenna characteristics, please wait...#db# DownloadFPGA(len: 42096)          
.....          
# LF antenna: 38.36 V @   125.00 kHz          
# LF antenna: 22.41 V @   134.00 kHz          
# LF optimal: 38.36 V @   125.00 kHz          
# HF antenna: 23.75 V @    13.56 MHz          
Displaying LF tuning graph. Divisor 89 is 134khz, 95 is 125khz.

Last edited by samburner3 (2017-02-21 03:37:05)

iceman · 2017-02-18 17:14:29

output from the cmds below is needed to make some assumptions.

hf 14a read
hf 14a list

iceman · 2017-02-18 17:15:43

the block3 is following mifare standard when read.

HighPressure · 2017-02-18 20:38:52

the chinese commands also wont work for me
can confirm this

instead I dumped the empty card and rewrite the whole card with whatever you want to have on it.

there was an issue in an earlier build too, if the keys to write are different from the current keys on the card, it was failing to write them.
for this reason I was writing different cards first with mf classic tool (and acr122u)

HighPressure · 2017-02-18 21:34:10

just did a test with the latest iceman build and an empty token

pm3 --> hf mf csetuid 11111111
--wipe card:NO uid:11 11 11 11
old block 0: 49 C5 A7 02 29 08 04 00 62 63 64 65 66 67 68 69
new block 0: 11 11 11 11 00 08 04 00 62 63 64 65 66 67 68 69
old UID:00 00 00 00
new UID:11 11 11 11

works fine now
but rewrite has a output error:

pm3 --> hf mf csetuid 01020304
--wipe card:NO uid:01 02 03 04
old block 0: 11 11 11 11 00 08 04 00 62 63 64 65 66 67 68 69
new block 0: 01 02 03 04 04 08 04 00 62 63 64 65 66 67 68 69
old UID:00 00 00 00
new UID:01 02 03 04

hf search will show in both cases the correct uuid, so it has been set.
but cload did not work for me with my eml dump of my token

afterwards hf search I receive

Card doesn't support standard iso14443-3 anticollision
ATQA : 00 00
write time-out
Sending bytes to proxmark failed
ATQA : 00 00
Error: tag didn't answer to RID

no known/supported 13.56 MHz tags found

now the token is "corrupted" and has to be resetted

pm3 --> hf mf csetuid 11111111
--wipe card:NO uid:11 11 11 11
old block 0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
new block 0: 11 11 11 11 00 00 00 00 00 00 00 00 00 00 00 00
old UID:00 00 00 00
new UID:11 11 11 11

no error message here anywhere
but if you check the token:

pm3 --> hf se

Card doesn't support standard iso14443-3 anticollision
ATQA : 00 00
write time-out
Sending bytes to proxmark failed
ATQA : 00 00
Error: tag didn't answer to RID

no known/supported 13.56 MHz tags found

thats what I ment when I said different keys than in the dump

token was all f'ed and dump has different keys <> wont work

iceman · 2017-02-18 21:57:00

Luckily I explain all of this in my "magic tags" videos.. But to save you from watching,

set uid with "wipe" option (if you want to empty the tag of course)
then use lua script "remagic" to restore a gen1 tag w default keys (correct ST)

It looks like you have gen1 tag, @highpressure. While @OP talks about not having a Gen1. Still no proof of it.

HighPressure · 2017-02-18 22:14:45

thats a cool one

what would be the expected result with a chinese token that has been remagiced where i then hf mf restore?

for me it fails to write

the key from the dump are in dumpkeys.bin and for sure in dumpdata.
even if I eload the eml it wont change the result:

pm3 --> hf mf eload meintoken
................................................................
Loaded 64 blocks from file: meintoken.eml
pm3 --> hf mf restore
Restoring dumpdata.bin to card
Writing to block 0: somedata 88 04 00 46 8F 74 93 99 00 21 11
#db# Authentication failed. Card timeout.
#db# Auth error
#db# WRITE BLOCK FINISHED
isOk:00
Writing to block 1: 01 02 00 00 some more 00 00 00 00 00 00
#db# Authentication failed. Card timeout.
#db# Auth error
#db# WRITE BLOCK FINISHED

Last edited by HighPressure (2017-02-18 22:25:29)

iceman · 2017-02-18 22:46:51

....eload is for....

while

...cload is....

You are mixing things up. You need to become more clearminded.

hf mf restore uses a defaultkey (0xffffffffffff) to write dumpkeys and dumpdata into one normal card.
if you loaded a dumpkeys file with different key (this is normal) you can't use "restore" out of the box. you need to set the keys back to 0xfff...
this is old news and also have issues on github.
https://github.com/Proxmark/proxmark3/issues/201
https://github.com/Proxmark/proxmark3/issues/200

HighPressure · 2017-02-19 00:05:19

hmm im not that good in c but what is this code for, in cmdhfmf.c

below where cmdhf14amfrestore starts it says (snipped from there)

default: numSectors = 16;

if ((fkeys = fopen("dumpkeys.bin","rb")) == NULL) {
PrintAndLog("Could not find file dumpkeys.bin");
return 1;
}

for (sectorNo = 0; sectorNo < numSectors; sectorNo++) {
bytes_read = fread( keyA[sectorNo], 1, 6, fkeys );
if ( bytes_read == 0) {
PrintAndLog("File reading error (dumpkeys.bin).");
fclose(fkeys);
fkeys = NULL;
return 2;
}
}

my understanding is that it loads dumpkeys.bin and reads them to memory.
but lets read it simplified like this again:
for (counter = 0; counter < 16; increase counter++)
wouldnt this mean it only rotates 16 times the for loop and with this reads only the 16 first keys and thats all?

further I checked the docu on fread and it says 1 means single byte read and 6 up to 6 chars.
so ok the key is in hex like 0xff which is one "char" in the dumpkeys.bin then, but is this translated somewhere?
as I said im not good in c, but in other languages you define like int str long double...

i am mentioning this, because I noticed that the init of the key in cmdhf14amfrestore looks like this:
uint8_t key[6] = {0xFF,0xFF,0xFF,0xFF,0xFF,0xFF};

while e.g. for CmdHF14AMfNested and all other commands it looks like this:
uint8_t key[6] = {0, 0, 0, 0, 0, 0};

on the other hand regarding reading the keys with this routine, I checked the CmdHF14AMfDump where we know it works.
looks except for minor differences the same (e.g. spaces between 1 < 2 and name of the variable).
but there later the keys get processed in another for and if.. so maybe thats what missing? we read them but then?
thats then also the cause why we only check for the ff key

regarding cload eload, yep sorry. you are right - as always

samburner3 · 2017-02-19 00:36:34

iceman wrote:

output from the cmds below is needed to make some assumptions.
hf 14a read
hf 14a list

Here is the output from those commands:

proxmark3> hf 14a read
#db# DownloadFPGA(len: 42096)          
 UID : d7 04 8b 01           
ATQA : 00 04          
 SAK : 08 [2]          
TYPE : NXP MIFARE CLASSIC 1k | Plus 2k SL1          
proprietary non iso14443-4 card found, RATS not supported          
#db# halt error. response len: 1          
Answers to chinese magic backdoor commands: NO          
proxmark3> hf 14a list
Deprecated command, use 'hf list 14a' instead          
proxmark3> hf list 14a
Recorded Activity (TraceLen = 163 bytes)          
          
Start = Start of Start Bit, End = End of last modulation. Src = Source of Transfer          
iso14443a - All times are in carrier periods (1/13.56Mhz)          
iClass    - Timings are not as accurate          
          
      Start |        End | Src | Data (! denotes parity error)                                   | CRC | Annotation         |          
------------|------------|-----|-----------------------------------------------------------------|-----|--------------------|          
          0 |        992 | Rdr | 52                                                              |     | WUPA          
       2228 |       4596 | Tag | 04  00                                                          |     |           
       7040 |       9504 | Rdr | 93  20                                                          |     | ANTICOLL          
      10676 |      16500 | Tag | d7  04  8b  01  59                                              |     |           
      18816 |      29344 | Rdr | 93  70  d7  04  8b  01  59  4d  97                              |  ok | SELECT_UID          
      30516 |      34036 | Tag | 08  b6  dd                                                      |     |           
     532864 |     537632 | Rdr | e0  80  31  73                                                  |  ok | RATS          
     538804 |     539444 | Tag | 04                                                              |     |           
     985344 |     986336 | Rdr | 40                                                              |     | MAGIC WUPC1          
     987572 |     988148 | Tag |0a!                                                              |     |           
     992384 |     993696 | Rdr | 43                                                              |     | MAGIC WUPC2          
     994868 |     995444 | Tag |0a!                                                              |     |           
     999424 |    1004192 | Rdr | 50  00  57  cd                                                  |  ok | HALT          
    1005364 |    1006004 | Tag | 04                                                              |     |           
proxmark3>

iceman · 2017-02-19 00:37:04

yes,
0xFF ( prefix 0x means hex value, 0xFF == 255 decimal)
so you could write 0x00 or 0, OR 0xFF, 255 same same.

6bytes are read. (char, byte, uint8_t, short all the same but well, different)
So the loops read 16 keys. yes. nothing wrong.

dumpkeys, dumpdata merged becomes "new tagdata", which "hf mf restore" does using the keytype A with key 0xFFFFFFFFFFFF

For this to work, the card needs to have 0xFFFFFFFFFFFF in its sectortrailers. Here is the catch, once you restored the new dumpkeys .. you overwrite the sector trailer with these keys.

Next time you want to use "hf mf restore" the default key doesn't work anymore since the tag has new/different keys.
thats why it fails.

if you use a Magic Gen1, you have other options to reset your tag but with a normal tag you need to re-write all sector trailers with the keys you had in the dumpkeys file and write 0xFFFFFFFFFFFF in key A.

samburner3 · 2017-02-19 00:38:50

iceman wrote:

the block3 is following mifare standard when read.

Ah ok so why does it output 0's when on a dump of the same card it will display F's? some sort of security to not show the key A im guessing?

iceman · 2017-02-19 00:39:46

@samburner3 if you try icemanfork, you will find that your tag will correctly be identified as a Generation 1 magic tag.

samburner3 · 2017-02-19 01:14:43

iceman wrote:

@samburner3 if you try icemanfork, you will find that your tag will correctly be identified as a Generation 1 magic tag.

Hmm I had trouble flashing the bootrom of your fork.
Made a help post here:
http://www.proxmark.org/forum/viewtopic.php?pid=26323

samburner3 · 2017-02-20 21:47:38

Thanks for help in other topic, successfully flashed and changed the UID of the magic card.

iceman · 2017-02-20 21:53:11

You are welcome. Strange error, I can't still reproduce it on any of my 4 proxmarks.

Just recap your solutions, edit your first post and add "[solved]" to the beginning of your subject.

iceman · 2017-02-28 21:12:17

I managed to reproduce this problem. It happens when you flash bootrom (from my fork with has_512 enabled) .
Now, to solved it just disabled the HAS_512_FLASH and recompile. Flash bootrom again. then fullimage.
and all is fine again.

Proxmark3 community

Announcement

#1 2017-02-18 14:16:04

[solved] Changeable UID card not changing...

#2 2017-02-18 17:14:29

Re: [solved] Changeable UID card not changing...

#3 2017-02-18 17:15:43

Re: [solved] Changeable UID card not changing...

#4 2017-02-18 20:38:52

Re: [solved] Changeable UID card not changing...

#5 2017-02-18 21:34:10

Re: [solved] Changeable UID card not changing...

#6 2017-02-18 21:57:00

Re: [solved] Changeable UID card not changing...

#7 2017-02-18 22:14:45

Re: [solved] Changeable UID card not changing...

#8 2017-02-18 22:46:51

Re: [solved] Changeable UID card not changing...

#9 2017-02-19 00:05:19

Re: [solved] Changeable UID card not changing...

#10 2017-02-19 00:36:34

Re: [solved] Changeable UID card not changing...

#11 2017-02-19 00:37:04

Re: [solved] Changeable UID card not changing...

#12 2017-02-19 00:38:50

Re: [solved] Changeable UID card not changing...

#13 2017-02-19 00:39:46

Re: [solved] Changeable UID card not changing...

#14 2017-02-19 01:14:43

Re: [solved] Changeable UID card not changing...

#15 2017-02-20 21:47:38

Re: [solved] Changeable UID card not changing...

#16 2017-02-20 21:53:11

Re: [solved] Changeable UID card not changing...

#17 2017-02-28 21:12:17

Re: [solved] Changeable UID card not changing...

Board footer