"unexpected behaviour" while running hf mf mifare

moebius · 2015-10-30 21:52:48

Hey guys!

I'm getting:

proxmark3> hf mf mifa
-------------------------------------------------------------------------
Executing command. Expected execution time: 25sec on average :-)
Press button on the proxmark3 device to abort both proxmark3 and client.
-------------------------------------------------------------------------
.

Card is not vulnerable to Darkside attack (its random number generator seems to be based on the wellknown
generating polynomial with 16 effective bits only, but shows unexpected behaviour.

Any input on how to deal with this?

BTW, this is the output from "reader" (uid was modified):

proxmark3> hf 14a reader
UID : aa aa aa aa
ATQA : 00 04
SAK : 08 [2]
TYPE : NXP MIFARE CLASSIC 1k | Plus 2k SL1
proprietary non iso14443-4 card found, RATS not supported
Answers to chinese magic backdoor commands: NO

Thanks a lot!

meter · 2015-10-30 23:23:48

moebius wrote:

Any input on how to deal with this?

Simple, you can't hack with darkside attack, try with nested attack or with snoop with official reader.

AT91SAM · 2015-10-31 01:43:59

If modified you used a chineese 1k card?
try theese commands

hf mf csetuid Set UID for magic Chinese card
hf mf csetblk Write block - Magic Chinese card
hf mf cgetblk Read block - Magic Chinese card
hf mf cgetsc Read sector - Magic Chinese card

AT91SAM · 2015-10-31 02:27:26

only wierd bug I see is this one ....

UID : b4 7f 0d 00
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

"Answers to chinese magic backdoor commands: NO" while it is the chineese card supplied by the pm3

but hf mf cgetsc does work.

only setting csetuid fails looks like they changed some little things on the cards.
use hf mf cgetsc 0 to change the uid....

use hf mf csetblk 0 b47f0d01c70100000000000000000000

proxmark3> hf 14a read
UID : b4 7f 0d 01
ATQA : 00 00
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

iceman · 2015-10-31 14:30:36

If it says "NO", it means it is not a Magic Generation 1 tag. You could have a Generation 2 where there is no checks for.

AT91SAM · 2015-10-31 14:47:35

No its not a gen 2 . because I can use

hf mf csetuid Set UID for magic Chinese card
hf mf csetblk Write block - Magic Chinese card
hf mf cgetblk Read block - Magic Chinese card
hf mf cgetsc Read sector - Magic Chinese card

it only says "NO" if you use hf 14a read but if you use the commands they work

iceman · 2015-10-31 16:15:14

that I'm doubtful about. If you paste the log when you run the "hf 14a read" and a "hf mf csetblk" ?

moebius · 2015-10-31 17:32:48

Hey! sorry about not being that clear. I modified the UID on the output to paste it here for privacy, not using any command.

It seems that it is a Mifare Plus... so maybe vulnerable to nested but not to darkside... It's weird because I'm getting this error sometimes for vulnerable cards...

Is it possible to run the "special" attack without first run the pure darkside one?

Thanks for your help!

iceman · 2015-11-01 12:18:27

not sure what you are talking about here.
There are two attacks, darkside and nested.
If you have a key, you can use nested. No need for the darkside.
If you dont have a key, you'll need to get one. Either with sniffing or darkside.

if the nested doesn't work, then you can always sniff and analyse the logs.

you can remove uid from outputs, if you are worried, that is not needed to see how the transaction between reader & tag is supporting magic generation 1 commands.

moebius · 2015-11-01 19:09:42

@iceman! thanks for clarifying! I know the attacks ;-) and I kept the uid (with a "random" value) to show it is a 4-byte uid, not 7, that's it.

In the case I'm studying, I have no keys and (as of now) I don't have access to a legit reader, so the only way to try to crack the card is by darkside. What I also saw is that with the latest firm, some old cards that are vulnerable to darkside, sometimes, prox3 sends this error message and after a few tries it cracks the key... so well, maybe there's some kind of error in there... I will take a look...

If it's a Plus (with backwards compatibility with Classic) then maybe it is not vulnerable to darkside but vulnerable to nested? I know that the snooping will work, but what about the nested one?

Cheers!

iceman · 2015-11-01 20:16:29

Had to re-read this thread, I'm answering @AT91SAM about his generation1 magic tag first in my responses. Not your original.

Your output (TS) is an indication that the tag doesn't behavie propley in the random number, which means it does send the ACK response being vuln to one part of the darkside attack but not the other side, where it should repeat itself after 65535 iterations.

This message was introduced as an solution for when this behaviour caused the PM3 to reset. (click-sound) , PPL has hinted this could be seen on clones. ie not a mifare tag,.. Don't misstake for a magic uid tag (used for cloning) thats something different.

You can always try the "hf mf chk" to look for default keys, and maybe you get lucky. It would be interesting to see if this tag is vuld to the nested attack. Do you have a key to test it with?

Last edited by iceman (2015-11-01 20:16:59)

AT91SAM · 2015-11-01 21:21:16

here a dump for changing uid on chinese card.

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 | 16564 | Tag | b4 7f 0d 01 c7 | |
18688 | 29216 | Rdr | 93 70 b4 7f 0d 01 c7 a0 16 | | SELECT_UID
30388 | 33908 | Tag | 08 b6 dd | |
35456 | 40224 | Rdr | 50 00 57 cd | | HALT
175616 | 176608 | Rdr | 40! | | MAGIC WUPC1
177844 | 178420 | Tag | 0a! | |
182656 | 183968 | Rdr | 43 | | MAGIC WUPC2
185140 | 185716 | Tag | 0a! | |
189696 | 194400 | Rdr | a0 00 5f b1 | | WRITEBLOCK(0)
195636 | 196212 | Tag | 0a! | |
199680 | 220512 | Rdr | b4 7f 0d 01 c7 08 04 00 00 00 00 00 00 00 00 00 | |
| | | 60 6a | | ?
267188 | 267764 | Tag | 0a! | |
269184 | 273952 | Rdr | 50 00 57 cd | | HALT
275124 | 275764 | Tag | 04 | |

iceman · 2015-11-01 21:28:24

@at91sam, yes, that is a generation 1 tag alright.
Hm, can you show me the output of "hf 14a read" too?

AT91SAM · 2015-11-01 22:42:12

ok

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 | 16564 | Tag | b4 7f 0d 01 c7 | |
18688 | 29216 | Rdr | 93 70 b4 7f 0d 01 c7 a0 16 | | SELECT_UID
30388 | 33908 | Tag | 08 b6 dd | |
1009408 | 1014176 | Rdr | e0 80 31 73 | | RATS
1015348 | 1015988 | Tag | 04 | |
1551360 | 1552352 | Rdr | 40 | | MAGIC WUPC1
1553588 | 1554164 | Tag | 0a! | |
1558400 | 1559712 | Rdr | 43 | | MAGIC WUPC2
1560884 | 1561460 | Tag | 0a! | |
1565440 | 1570208 | Rdr | 50 00 57 cd | | HALT
1571380 | 1572020 | Tag | 04 | |

iceman · 2015-11-01 22:49:56

the last 0x04 is the reason for the identification to become "NO".

The normal behavior of a mifare is to not answer the halt command. Since your tag does, the identification thinks it failed.
Remove the if statment, and clones will be identified as magic...

ref https://github.com/Proxmark/proxmark3/b … md.c#L1242

robot · 2015-11-02 11:46:44

This is the same issue that I faced with some chinese uid cards. Thanks for the pointer!

iceman · 2015-11-02 12:23:44

@robot, I pushed some fixes for this in my fork, Can you verify that it works better now?
its all of the below commands

hf mf c*
hf 14a reader

robot · 2015-11-04 11:33:57

Thanks - I will check.

I am having a terrible time compiling on OSX ElCapitan. All of the instructions are so out of date.
I may have to reinstall the windows version

robot · 2015-11-04 16:46:27

here are the results - I may be doing some things wrong so please correct me!

hf 14a reader

pm3 --> hf 14a reader
 UID : 1E B5 0D 00
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: YES
pm3 -->

csetuid with wipe

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

csave (but seems to work)

pm3 --> hf mf csave test
#db# halt error. response len: 1
Cant get block: 63
Saved to file: test.eml
pm3 -->

cload

pm3 --> hf mf cload test
File reading error.
pm3 --> hf mf cload otherfile
#db# halt error. response len: 1
Can't set magic card block: 63
pm3 -->

It appears that the csave handle is not closed and the file is locked. I cannot even delete that file in windows until I exit PM3.
Another file can be loaded (but with similar error to the csave)

I think that the non-std reply to the halt command is showing an error for the last function, but the command succeeds.

Can you give me a list of commands to test (with block/sector numbers) that I can paste so that I do the right things....

robot · 2015-11-04 16:51:57

Just to pickup on the HF 14a reader command (different card uid to above)

You can see that it gives errors in both cases but if you omit the 'w' wipe command - it does write!

pm3 --> hf 14a reader
 UID : 2C 8B 90 55
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: YES

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

pm3 --> hf 14a reader
 UID : 2C 8B 90 55
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: YES

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

pm3 --> hf 14a reader
 UID : 01 02 03 04
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: YES

iceman · 2015-11-09 22:38:29

I'm doing a remake of the "hf mf c*" commands (again) and pushed the changes to my fork. Untested yet, with some debugging comments

Proxmark3 community

Announcement

#1 2015-10-30 21:52:48

"unexpected behaviour" while running hf mf mifare

#2 2015-10-30 23:23:48

Re: "unexpected behaviour" while running hf mf mifare

#3 2015-10-31 01:43:59

Re: "unexpected behaviour" while running hf mf mifare

#4 2015-10-31 02:27:26

Re: "unexpected behaviour" while running hf mf mifare

#5 2015-10-31 14:30:36

Re: "unexpected behaviour" while running hf mf mifare

#6 2015-10-31 14:47:35

Re: "unexpected behaviour" while running hf mf mifare

#7 2015-10-31 16:15:14

Re: "unexpected behaviour" while running hf mf mifare

#8 2015-10-31 17:32:48

Re: "unexpected behaviour" while running hf mf mifare

#9 2015-11-01 12:18:27

Re: "unexpected behaviour" while running hf mf mifare

#10 2015-11-01 19:09:42

Re: "unexpected behaviour" while running hf mf mifare

#11 2015-11-01 20:16:29

Re: "unexpected behaviour" while running hf mf mifare

#12 2015-11-01 21:21:16

Re: "unexpected behaviour" while running hf mf mifare

#13 2015-11-01 21:28:24

Re: "unexpected behaviour" while running hf mf mifare

#14 2015-11-01 22:42:12

Re: "unexpected behaviour" while running hf mf mifare

#15 2015-11-01 22:49:56

Re: "unexpected behaviour" while running hf mf mifare

#16 2015-11-02 11:46:44

Re: "unexpected behaviour" while running hf mf mifare

#17 2015-11-02 12:23:44

Re: "unexpected behaviour" while running hf mf mifare

#18 2015-11-04 11:33:57

Re: "unexpected behaviour" while running hf mf mifare

#19 2015-11-04 16:46:27

Re: "unexpected behaviour" while running hf mf mifare

#20 2015-11-04 16:51:57

Re: "unexpected behaviour" while running hf mf mifare

#21 2015-11-09 22:38:29

Re: "unexpected behaviour" while running hf mf mifare

Board footer