Checking for default keys on iceman fork is not actually checking

wrench · 2019-09-11 08:41:04

Hi all,

I have the latest precompiled client and iceman fork flashed on my new RDV4 and the device works beautifully (hardnested works great!). One tiny thing though, I am trying to work on a hardened MFC and was pretty excited to get the hardnested working on a block I already knew I didn't have the key for and it worked (yay!). However, when I try checking for keys, the output "claims" it is checking but nothing actually happens and it doesn't find keys. I know there are default keys for most sectors cause I did get them with my old RDV2 with a severely outdated flash and client.

Here is what I get:

pm3 --> hf mf chk *1 ? d default_keys.dic
[+] Loaded 524 keys from default_keys.dic

Time in checkkeys: 0 seconds

testing to read key B...
|---|----------------|---|----------------|---|
|sec|key A |res|key B |res|
|---|----------------|---|----------------|---|
|000| ------------ | 0 | ------------ | 0 |
|001| ------------ | 0 | ------------ | 0 |
|002| ------------ | 0 | ------------ | 0 |
|003| ------------ | 0 | ------------ | 0 |
|004| ------------ | 0 | ------------ | 0 |
|005| ------------ | 0 | ------------ | 0 |
|006| ------------ | 0 | ------------ | 0 |
|007| ------------ | 0 | ------------ | 0 |
|008| ------------ | 0 | ------------ | 0 |
|009| ------------ | 0 | ------------ | 0 |
|010| ------------ | 0 | ------------ | 0 |
|011| ------------ | 0 | ------------ | 0 |
|012| ------------ | 0 | ------------ | 0 |
|013| ------------ | 0 | ------------ | 0 |
|014| ------------ | 0 | ------------ | 0 |
|015| ------------ | 0 | ------------ | 0 |
|---|----------------|---|----------------|---|
Printing keys to binary file hf-mf-046E0C523F3E80-key.bin...
Found keys have been dumped to file hf-mf-046E0C523F3E80-key.bin. 0xffffffffffff has been inserted for unknown keys.

pm3 -->

Any ideas? The keys file obviously contains the ffffffffffff insertions just in case anyone is wondering. The same output happens when I run it without the dictionary file as well (ala classic chk command).

Cheers,

mwalker · 2019-09-11 11:28:12

What version are you using ?
I just downloaded the latest rrg software, compiled and flashed. No problems.
Note: The flasher is now in the proxmark3.exe and the new key filename for the mifare classic keys ( mfc_default_keys.dic).
Output from my run

 [ CLIENT ]
  client: RRG/Iceman
  compiled with MinGW-w64 8.2.0 OS:Windows (64b) ARCH:x86_64

 [ PROXMARK RDV4 ]
  external flash:                  present
  smartcard reader:                present

 [ PROXMARK RDV4 Extras ]
  FPC USART for BT add-on support: absent

 [ ARM ]
  bootrom: RRG/Iceman/master/b16f2fda-dirty-unclean 2019-07-24 08:25:08
       os: RRG/Iceman/master/a384774b-dirty-unclean 2019-09-11 20:12:07
  compiled with GCC 7.3.1 20180622 (release) [ARM/embedded-7-branch revision 261907]

 [ FPGA ]
  LF image built for 2s30vq100 on 2019-07-31 at 15:57:16
  HF image built for 2s30vq100 on 2018-09-03 at 21:40:23

 [ Hardware ]
  --= uC: AT91SAM7S512 Rev A
  --= Embedded Processor: ARM7TDMI
  --= Nonvolatile Program Memory Size: 512K bytes, Used: 270485 bytes (52%) Free: 253803 bytes (48%)
  --= Second Nonvolatile Program Memory Size: None
  --= Internal SRAM Size: 64K bytes
  --= Architecture Identifier: AT91SAM7Sxx Series
  --= Nonvolatile Program Memory Type: Embedded Flash Memory


[usb] pm3 --> hf search
[=] Checking for known tags...

[|] Searching for ISO14443-A tag... UID : CF 5B EF 31
ATQA : 00 02
 SAK : 38 [1]
TYPE : Nokia 6212 or 6131 MIFARE CLASSIC 4K
 ATS : 0D 78 80 70 02 00 73 C8 40 00 00 90 00 A6 1F
       -  TL : length is 13 bytes
       -  T0 : TA1 is present, TB1 is present, TC1 is present, FSCI is 8 (FSC = 256)
       - TA1 : different divisors are NOT supported, DR: [], DS: []
       - TB1 : SFGI = 0 (SFGT = (not needed) 0/fc), FWI = 7 (FWT = 524288/fc)
       - TC1 : NAD is NOT supported, CID is supported
[=] Answers to magic commands: NO
[+] Prng detection: HARD

[+] Valid ISO14443-A tag  found

[usb] pm3 --> hf mf chk *1 ? d default_keys.dic
[-] Error - can't find default_keys.dic
[usb] pm3 --> hf mf chk *1 ? d mfc_default_keys.dic
[+] Loaded 855 keys from mfc_default_keys.dic
................................
[+] Time in checkkeys: 8 seconds

[=] testing to read key B...
|---|----------------|---|----------------|---|
|sec|key A           |res|key B           |res|
|---|----------------|---|----------------|---|
|000|  ffffffffffff  | 1 |  ffffffffffff  | 1 |
|001|  bbbbbbbbbbbb  | 1 |  cccccccccccc  | 1 |
|002|  ffffffffffff  | 1 |  ffffffffffff  | 1 |
|003|  ffffffffffff  | 1 |  ffffffffffff  | 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|  ffffffffffff  | 1 |  ffffffffffff  | 1 |
|014|  ffffffffffff  | 1 |  ffffffffffff  | 1 |
|015|  ffffffffffff  | 1 |  ffffffffffff  | 1 |
|---|----------------|---|----------------|---|
[+] Printing keys to binary file hf-mf-CF5BEF31-key.bin ...
[+] Found keys have been dumped to hf-mf-CF5BEF31-key.bin  --> 0xffffffffffff has been inserted for unknown keys.

[usb] pm3 -->

Last edited by mwalker (2019-09-11 12:02:20)

wrench · 2019-09-11 11:53:32

Hey mwalker,

I am using the latest pre-compiled version (had many issues trying to compile for windows AND kali so I resolved to pre-compiled) from:

https://drive.google.com/drive/folders/ … LrZJHnvcSP

This is what I've got:

 [ CLIENT ]
 client: iceman build for RDV40 with flashmem; smartcard;

 [ ARM ]
 bootrom: Version information not available
      os: iceman/master/ice_v3.1.0-1094-g97128ad5 2019-08-28 01:59:00

 [ FPGA ]
 LF image built for 2s30vq100 on 2017/10/25 at 19:50:50
 HF image built for 2s30vq100 on 2018/ 9/ 3 at 21:40:23

 [ Hardware ]
  --= uC: AT91SAM7S512 Rev B
  --= Embedded Processor: ARM7TDMI
  --= Nonvolatile Program Memory Size: 512K bytes, Used: 235688 bytes (45%) Free: 288600 bytes (55%)
  --= Second Nonvolatile Program Memory Size: None
  --= Internal SRAM Size: 64K bytes
  --= Architecture Identifier: AT91SAM7Sxx Series
  --= Nonvolatile Program Memory Type: Embedded Flash Memory

It may be worth noting that I am aware that this is a client issue and not something on the flashed image (as trivial as it is, I just wanted to avoid all doubts and decided to run the new RDV4 on my RDV2 client from 2015 and it worked fine). Just wondering why this is happening.

Thanks for the help!

mwalker · 2019-09-11 12:10:49

Not sure. I assume you flashed the rdv4 with the same pre-compiled version as the client (.exe) ?
I know the lads have been working hard on improvements and it is important to run the same client and firmware as sometimes little things can change between the two.

I run the above on windows 10. I compiled Using the proxspace setup (https://github.com/Proxmark/proxmark3/wiki/Windows), seemed OK (I know it can be a bit tricky to setup)
I have also run previous versions under kali with no issues.

Maybe it might be worth working through the setup and compile issues, once done it will be easy to keep up-to-date.

Last edited by mwalker (2019-09-11 12:14:10)

wrench · 2019-09-11 12:37:06

Yeah I figured it won't be a straight forward issue. Yes it goes without saying that the image I flashed is the one that came with it (and it went fine and told me to have a nice day). I have already been scolded by iceman for attempting to use dissimilar flash/client versions so I now have converted to the righteous path!

Thanks for the response though. I will report if I manage to get over the compiling hurdles.

iceman · 2019-09-11 17:28:14

scolded??

wrench · 2019-09-12 02:22:04

Was meant as a lighthearted joke

iceman · 2019-09-12 07:17:06

The path of the righteous man is beset on all sides by the
Inequities of the selfish and the tyranny of evil men. Blessed is he who, in
The name of charity and good will, shepherds the weak through the valley of
Darkness, for he is truly his brother's keeper and the finder of lost
Children. And I will strike down upon thee with great vengeance and furious
Anger those who attempt to poison and destroy my brothers. And you will know
My name is the Lord when I lay my vengeance upon thee.

mwalker · 2019-09-12 07:45:32

mmm Pulp Fiction - Ezekiel 25:17 ?

piwi · 2019-09-12 07:52:14

Pulp Fiction. Didn't know that they used PM3 at this time...

wrench · 2019-09-12 10:45:30

iceman wrote:

The path of the righteous man is beset on all sides by the
Inequities of the selfish and the tyranny of evil men. Blessed is he who, in
The name of charity and good will, shepherds the weak through the valley of
Darkness, for he is truly his brother's keeper and the finder of lost
Children. And I will strike down upon thee with great vengeance and furious
Anger those who attempt to poison and destroy my brothers. And you will know
My name is the Lord when I lay my vengeance upon thee.

In this case, that/those which/who beset the said righteous path are those who do not read what the wiki (and tutorials) say. *blush*

iceman · 2019-09-12 20:51:29

ha, and here I didn't think most of you weren't even born back then. What a great movie.

Proxmark3 community

Announcement

#1 2019-09-11 08:41:04

Checking for default keys on iceman fork is not actually checking

#2 2019-09-11 11:28:12

Re: Checking for default keys on iceman fork is not actually checking

#3 2019-09-11 11:53:32

Re: Checking for default keys on iceman fork is not actually checking

#4 2019-09-11 12:10:49

Re: Checking for default keys on iceman fork is not actually checking

#5 2019-09-11 12:37:06

Re: Checking for default keys on iceman fork is not actually checking

#6 2019-09-11 17:28:14

Re: Checking for default keys on iceman fork is not actually checking

#7 2019-09-12 02:22:04

Re: Checking for default keys on iceman fork is not actually checking

#8 2019-09-12 07:17:06

Re: Checking for default keys on iceman fork is not actually checking

#9 2019-09-12 07:45:32

Re: Checking for default keys on iceman fork is not actually checking

#10 2019-09-12 07:52:14

Re: Checking for default keys on iceman fork is not actually checking

#11 2019-09-12 10:45:30

Re: Checking for default keys on iceman fork is not actually checking

#12 2019-09-12 20:51:29

Re: Checking for default keys on iceman fork is not actually checking

Board footer