is it a "hf mf chk" bug or usage error?

HighPressure · 2016-09-01 08:09:31

Hi

I´m currently a 3 week old iceman build
When I type hf mf chk 1 A

it gives me back (in the box)

sec | key A | res | key B ...
000 a0a1a2a3a4a5 etc...

shouldn sec state the number refering to the sector I chose?
so in this example 1?

I can confirm that it selects the sector and not the card type, as when I change the sector from 1 to 2 or 3 I get different results and keys, as there are different keys used on my testcard

for 0-3 it gives me back the a0a1a2a3a4a5 while for the others ffffffffffff
no difference if I type 001 or 1, same result.

but the funny thing is if I run hf mf chk * A the result states that only 000 A = a0a1a2a3a4a5 while all other sectors and key´s are fffffffffff.
that isnt true anyhow.
I got the keys for the card (non standard ones). So the single sector check should have brought an other result and with * it should have brought an no keys found and not fff...

when i run
hf mf chk * A dic default_keys.dic (which I extended with my keys), it will show the a0a1a2a3a4a5 in sector 0 A, which is correct, my key in sec 1 and 13.. all others F.

btw. I dont get why hf mf dump cant use the same dict and I first have to import the keys using hf mf chk..
or is it just one line of keys and can be edited with hex editor? wasnt sure about the dumpkeys.bin.
One file to maintain (dic´s) would be better I guess

Last edited by HighPressure (2016-09-01 08:12:13)

iceman · 2016-09-01 08:22:40

Its not written somewhere in the help text but the output from 'hf mf chk' is in a table for and the "res" (result) columns states 0|1,
This means 1 = success authentication, 0 = failed authentication.

Search the forum and you'll find it full of information.

if you want to use the dictionary file, the command is:

hf mf chk * ? d default_keys.dic

You need all keys to make use of the 'hf mf dump'

HighPressure · 2016-09-15 21:30:54

thanks for the help

maybe because i have different folders i had to run

hf mf chk * ? ./default_keys.dic (./ or otherwise its not loaded)

the output is

|---|----------------|---|----------------|---|
|sec|key A |res|key B |res|
|---|----------------|---|----------------|---|
|000| a0a1a2a3a4a5 | 1 | mykey | 1 |
|001| e6849fcc324b | 1 | mykey | 1 |
|002| mykey | 1 | mykey | 1 |
|003| mykey | 1 | mykey | 1 |
|004| ffffffffffff | 1 | ffffffffffff | 1 |
|005| ffffffffffff | 1 | ffffffffffff | 1 |
|006| ffffffffffff | 1 | ffffffffffff | 1 |
|007| ffffffffffff | 1 | ffffffffffff | 1 |
|008| ffffffffffff | 1 | ffffffffffff | 1 |
|009| ffffffffffff | 1 | ffffffffffff | 1 |
|010| ffffffffffff | 1 | ffffffffffff | 1 |
|011| ffffffffffff | 1 | ffffffffffff | 1 |
|012| ffffffffffff | 1 | ffffffffffff | 1 |
|013| mykey | 1 | mykey | 1 |
|014| ffffffffffff | 1 | ffffffffffff | 1 |
|015| ffffffffffff | 1 | ffffffffffff | 1 |
|---|----------------|---|----------------|---|

so regarding your info all are found.. as res is 1 everywhere
right after this I type
pm3 --> hf mf dump
|-----------------------------------------|
|------ Reading sector access bits...-----|
|-----------------------------------------|
#db# READ BLOCK FINISHED
#db# Authentication failed. Card timeout.
#db# Auth error
#db# READ BLOCK FINISHED
Could not get access rights for sector 1. Trying with defaults...
#db# Authentication failed. Card timeout.
#db# Auth error
#db# READ BLOCK FINISHED
Could not get access rights for sector 2. Trying with defaults...
#db# Authentication failed. Card timeout.
#db# Auth error
#db# READ BLOCK FINISHED
Could not get access rights for sector 3. Trying with defaults...
#db# READ BLOCK FINISHED
#db# READ BLOCK FINISHED
#db# READ BLOCK FINISHED
#db# READ BLOCK FINISHED
#db# READ BLOCK FINISHED
#db# READ BLOCK FINISHED
#db# READ BLOCK FINISHED
#db# READ BLOCK FINISHED
#db# READ BLOCK FINISHED
#db# Authentication failed. Card timeout.
#db# Auth error
#db# READ BLOCK FINISHED
Could not get access rights for sector 13. Trying with defaults...
#db# READ BLOCK FINISHED
#db# READ BLOCK FINISHED
|-----------------------------------------|
|----- Dumping all blocks to file... -----|
|-----------------------------------------|
#db# READ BLOCK FINISHED
Successfully read block 0 of sector 0.
#db# READ BLOCK FINISHED
Successfully read block 1 of sector 0.
#db# READ BLOCK FINISHED
Successfully read block 2 of sector 0.
#db# READ BLOCK FINISHED
Successfully read block 3 of sector 0.
#db# Authentication failed. Card timeout.
#db# Auth error
#db# READ BLOCK FINISHED
Could not read block 0 of sector 1
pm3 -->

could this be a path error in the system? so he isnt using the keys found earlier?
I'm sitting in the "client" folder with my terminal and run ./proxmark /dev/ttyACM3

piwi · 2016-09-16 16:08:07

HighPressure wrote:

hf mf chk * ? ./default_keys.dic (./ or otherwise its not loaded)

This lacks the "d" to write the keys to file dumpkeys.bin. This file is required by hf mf dump in order to be able to read the card.

HighPressure · 2016-09-20 17:27:15

ok I forgot it at this one, true.. but I added the keys already earlier myself using the hex editor

anyhow here a snip of another token which failed:
you will see I gave him the key and he didnt check successfully the key, but with the same command and less keys again, it successfully checked it??

pm3 --> hf mf chk *1 ? 5281a048e648 b8a1f613cf3d 2a6d9205e7ca ad4fb33388bf bedb604cc9d1 b0b1b2b3b4b5
key[ 0] 5281a048e648
key[ 1] b8a1f613cf3d
key[ 2] 2a6d9205e7ca
key[ 3] ad4fb33388bf
key[ 4] bedb604cc9d1
key[ 5] b0b1b2b3b4b5
................................
Time in checkkeys: 41499 ticks 6 seconds

testing to read key B...
|---|----------------|---|----------------|---|
|sec|key A |res|key B |res|
|---|----------------|---|----------------|---|
|000| ffffffffffff | 0 | b0b1b2b3b4b5 | 1 |
|001| ffffffffffff | 0 | b0b1b2b3b4b5 | 1 |
|002| ffffffffffff | 0 | b0b1b2b3b4b5 | 1 |
|003| ffffffffffff | 0 | ffffffffffff | 0 |
|004| ffffffffffff | 0 | b0b1b2b3b4b5 | 1 |
|005| ffffffffffff | 0 | b0b1b2b3b4b5 | 1 |
|006| ffffffffffff | 0 | b0b1b2b3b4b5 | 1 |
|007| ffffffffffff | 0 | b0b1b2b3b4b5 | 1 |
|008| ffffffffffff | 0 | b0b1b2b3b4b5 | 1 |
|009| ffffffffffff | 0 | b0b1b2b3b4b5 | 1 |
|010| ffffffffffff | 0 | b0b1b2b3b4b5 | 1 |
|011| ffffffffffff | 0 | b0b1b2b3b4b5 | 1 |
|012| ffffffffffff | 0 | 5281a048e648 | 1 |
|013| ffffffffffff | 0 | ffffffffffff | 0 |
|014| ffffffffffff | 0 | ffffffffffff | 0 |
|015| ffffffffffff | 0 | ffffffffffff | 0 |
|---|----------------|---|----------------|---|

pm3 --> hf mf chk *1 ? 5281a048e648 6288eb61eedd b0b1b2b3b4b5 c917cb115ec9
key[ 0] 5281a048e648
key[ 1] 6288eb61eedd
key[ 2] b0b1b2b3b4b5
key[ 3] c917cb115ec9
................................
Time in checkkeys: 23580 ticks 3 seconds

testing to read key B...
|---|----------------|---|----------------|---|
|sec|key A |res|key B |res|
|---|----------------|---|----------------|---|
|000| ffffffffffff | 0 | b0b1b2b3b4b5 | 1 |
|001| ffffffffffff | 0 | b0b1b2b3b4b5 | 1 |
|002| ffffffffffff | 0 | b0b1b2b3b4b5 | 1 |
|003| ffffffffffff | 0 | b0b1b2b3b4b5 | 1 |
|004| ffffffffffff | 0 | b0b1b2b3b4b5 | 1 |
|005| ffffffffffff | 0 | b0b1b2b3b4b5 | 1 |
|006| ffffffffffff | 0 | b0b1b2b3b4b5 | 1 |
|007| ffffffffffff | 0 | b0b1b2b3b4b5 | 1 |
|008| ffffffffffff | 0 | b0b1b2b3b4b5 | 1 |
|009| ffffffffffff | 0 | b0b1b2b3b4b5 | 1 |
|010| ffffffffffff | 0 | b0b1b2b3b4b5 | 1 |
|011| ffffffffffff | 0 | b0b1b2b3b4b5 | 1 |
|012| ffffffffffff | 0 | ffffffffffff | 0 |
|013| ffffffffffff | 0 | 6288eb61eedd | 1 |
|014| ffffffffffff | 0 | c917cb115ec9 | 1 |
|015| ffffffffffff | 0 | ffffffffffff | 0 |
|---|----------------|---|----------------|---|

pm3 --> hf mf chk *1 ? 5281a048e648 6288eb61eedd b0b1b2b3b4b5 c917cb115ec9 aae82e15143a
key[ 0] 5281a048e648
key[ 1] 6288eb61eedd
key[ 2] b0b1b2b3b4b5
key[ 3] c917cb115ec9
key[ 4] aae82e15143a
................................
Time in checkkeys: 23081 ticks 3 seconds

testing to read key B...
|---|----------------|---|----------------|---|
|sec|key A |res|key B |res|
|---|----------------|---|----------------|---|
|000| ffffffffffff | 0 | ffffffffffff | 0 |
|001| ffffffffffff | 0 | b0b1b2b3b4b5 | 1 |
|002| ffffffffffff | 0 | b0b1b2b3b4b5 | 1 |
|003| ffffffffffff | 0 | b0b1b2b3b4b5 | 1 |
|004| ffffffffffff | 0 | b0b1b2b3b4b5 | 1 |
|005| ffffffffffff | 0 | b0b1b2b3b4b5 | 1 |
|006| ffffffffffff | 0 | b0b1b2b3b4b5 | 1 |
|007| ffffffffffff | 0 | b0b1b2b3b4b5 | 1 |
|008| ffffffffffff | 0 | b0b1b2b3b4b5 | 1 |
|009| ffffffffffff | 0 | b0b1b2b3b4b5 | 1 |
|010| ffffffffffff | 0 | b0b1b2b3b4b5 | 1 |
|011| ffffffffffff | 0 | b0b1b2b3b4b5 | 1 |
|012| ffffffffffff | 0 | 5281a048e648 | 1 |
|013| ffffffffffff | 0 | 6288eb61eedd | 1 |
|014| ffffffffffff | 0 | c917cb115ec9 | 1 |
|015| ffffffffffff | 0 | aae82e15143a | 1 |
|---|----------------|---|----------------|---|

I then ran it with dictionary to fill up A key which is a default like this:

hf mf chk *1 ? d 5281a048e648 6288eb61eedd b0b1b2b3b4b5 c917cb115ec9 aae82e15143a default_keys.dic

which gave me:

testing to read key B...
|---|----------------|---|----------------|---|
|sec|key A |res|key B |res|
|---|----------------|---|----------------|---|
|000| a0a1a2a3a4a5 | 1 | b0b1b2b3b4b5 | 1 |
|001| a0a1a2a3a4a5 | 1 | b0b1b2b3b4b5 | 1 |
|002| a0a1a2a3a4a5 | 1 | b0b1b2b3b4b5 | 1 |
|003| a0a1a2a3a4a5 | 1 | b0b1b2b3b4b5 | 1 |
|004| a0a1a2a3a4a5 | 1 | b0b1b2b3b4b5 | 1 |
|005| a0a1a2a3a4a5 | 1 | b0b1b2b3b4b5 | 1 |
|006| a0a1a2a3a4a5 | 1 | b0b1b2b3b4b5 | 1 |
|007| a0a1a2a3a4a5 | 1 | b0b1b2b3b4b5 | 1 |
|008| a0a1a2a3a4a5 | 1 | b0b1b2b3b4b5 | 1 |
|009| a0a1a2a3a4a5 | 1 | b0b1b2b3b4b5 | 1 |
|010| a0a1a2a3a4a5 | 1 | b0b1b2b3b4b5 | 1 |
|011| a0a1a2a3a4a5 | 1 | b0b1b2b3b4b5 | 1 |
|012| a0a1a2a3a4a5 | 1 | 5281a048e648 | 1 |
|013| a0a1a2a3a4a5 | 1 | 6288eb61eedd | 1 |
|014| a0a1a2a3a4a5 | 1 | c917cb115ec9 | 1 |
|015| a0a1a2a3a4a5 | 1 | aae82e15143a | 1 |
|---|----------------|---|----------------|---|

but pm3 --> hf mf dump will give me

|-----------------------------------------|
|------ Reading sector access bits...-----|
|-----------------------------------------|
#db# READ BLOCK FINISHED
#db# READ BLOCK FINISHED
#db# READ BLOCK FINISHED
#db# READ BLOCK FINISHED
#db# READ BLOCK FINISHED
#db# READ BLOCK FINISHED
#db# READ BLOCK FINISHED
#db# READ BLOCK FINISHED
#db# READ BLOCK FINISHED
#db# READ BLOCK FINISHED
#db# READ BLOCK FINISHED
#db# READ BLOCK FINISHED
#db# READ BLOCK FINISHED
#db# READ BLOCK FINISHED
#db# READ BLOCK FINISHED
#db# READ BLOCK FINISHED
|-----------------------------------------|
|----- Dumping all blocks to file... -----|
|-----------------------------------------|
#db# READ BLOCK FINISHED
Successfully read block 0 of sector 0.
#db# READ BLOCK FINISHED
Successfully read block 1 of sector 0.
#db# READ BLOCK FINISHED
Successfully read block 2 of sector 0.
#db# READ BLOCK FINISHED
Successfully read block 3 of sector 0.
#db# Auth error
#db# READ BLOCK FINISHED
Could not read block 0 of sector 1

ran it again

#db# Can't select card
#db# READ BLOCK FINISHED
Could not read block 2 of sector 2

and again

Successfully read block 0 of sector 2.
#db# Authentication failed. Error card response.
#db# Auth error
#db# READ BLOCK FINISHED
Could not read block 1 of sector 2

did I screw up at my last icemane upgrade?
the os states master/v.1.1.0 but software is newer, isnt it?
is that now the problem? I rebuilt it and reflashed but os version stays like this?

pm3 --> hw ver
[[[ Cached information ]]]

Prox/RFID mark3 RFID instrument
bootrom: /-suspect 2015-04-02 15:12:04
os: /master/v1.1.0-1513-ga5d8246-dirty-suspect 2016-09-19 18:54:47
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: AT91SAM7S256 Rev D
Embedded Processor: ARM7TDMI
Nonvolatile Program Memory Size: 256K bytes. Used: 217418 bytes (83%). Free: 44726 bytes (17%).
Second Nonvolatile Program Memory Size: None
Internal SRAM Size: 64K bytes
Architecture Identifier: AT91SAM7Sxx Series
Nonvolatile Program Memory Type: Embedded Flash Memory

https://firefart.at/files/mifare/1.mfd
I was playing around with his dumps (1 - 3.mfd)
you can try it yourself

Last edited by HighPressure (2016-09-20 17:29:04)

iceman · 2016-09-20 17:34:30

Your bootrom and os images seems to be off.
If you are using PM3 Master, please to compile and flash bootrom (with -b) and fullimage.
Then use the client from the same build.

Cut 'nd paste your output of "hw ver" here so it can be verified that you are using the latest source.

Second, are you using the correct distances between tag and antenna. Your attempts shows failures on same sectors and some success. The sweetspot is about 1-2.5 cm. You need to experiment to find it.

HighPressure · 2016-09-21 16:25:42

I am using your latest build

when I am in your git cloned directory git describe says
v1.1.0-1390-g981aefe

when I am in the proxmark directory git describe says
v2.2.0-234-g41f08b7

hw ver stays the same when i flash from your directory the fullimage elf with option -b
should I use the one from the proxmark original?
I remember to have read here somewhere that I have to use the corresponding image file?
*edit* just flashed now the original image and now hw ver states

Prox/RFID mark3 RFID instrument
bootrom: /-suspect 2015-04-02 15:12:04
os: master/v2.2.0-234-g41f08b7-dirty-suspect 2016-09-21 15:29:17
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

Btw I am using the elechouse proxmark3 easy, if this changes the game anyhow

ahh ok thanks, the sweetspot thing then will maybe be the thing
tried it now 2 or 3 times... then I pressed it on the proxmark and it worked lol

hw tune with card
# LF antenna: 30.94 V @ 125.00 kHz
# LF antenna: 29.29 V @ 134.00 kHz
# LF optimal: 36.30 V @ 129.03 kHz
# HF antenna: 24.64 V @ 13.56 MHz

hw tune without card
# LF antenna: 30.94 V @ 125.00 kHz
# LF antenna: 29.29 V @ 134.00 kHz
# LF optimal: 36.44 V @ 129.03 kHz
# HF antenna: 28.82 V @ 13.56 MHz

looks fine, doesnt it?

Last edited by HighPressure (2016-09-21 16:33:59)

iceman · 2016-09-21 17:26:22

Yeah, you got a 4v drop for HF.
However when running the "hf mf chk" command try finding the sweet spot where the tag always get read.
Otherwise you will have issues when running it.

Proxmark3 community

Announcement

#1 2016-09-01 08:09:31

is it a "hf mf chk" bug or usage error?

#2 2016-09-01 08:22:40

Re: is it a "hf mf chk" bug or usage error?

#3 2016-09-15 21:30:54

Re: is it a "hf mf chk" bug or usage error?

#4 2016-09-16 16:08:07

Re: is it a "hf mf chk" bug or usage error?

#5 2016-09-20 17:27:15

Re: is it a "hf mf chk" bug or usage error?

#6 2016-09-20 17:34:30

Re: is it a "hf mf chk" bug or usage error?

#7 2016-09-21 16:25:42

Re: is it a "hf mf chk" bug or usage error?

#8 2016-09-21 17:26:22

Re: is it a "hf mf chk" bug or usage error?

Board footer