hf mf sim bug

[maxben14]

I try to emulate the mifare classic and read through my smartphone with android MCT apk. proxmark3> hf mf sim n 0 mf 1k sim uid: N/A, numreads:0, flags:0 (0x00)

db# 7B UID: 04 53 5d 42 a7 49 80

db# Reader tried to operate (0x30) on out of range block: 222 (0xde), nacking

db# Emulator stopped. Tracing: 1 trace length: 27908

proxmark3> hf list 14a ....... 188213078 | 188215446 | Tag | 44 00 | | 188224958 | 188235486 | Rdr | 93 70 88 04 53 5d 82 17 d3 | ok | SELECT_UID
188236978 | 188240498 | Tag | 04 da 17 | | 188243234 | 188245698 | Rdr | 95 20 | | ANTICOLL-2
188247382 | 188253270 | Tag | 42 a7 49 80 2c | | 188257314 | 188267842 | Rdr | 95 70 42 a7 49 80 2c 2d 5e | ok | ANTICOLL-2
188269398 | 188272918 | Tag | 08 b6 dd | | 188503146 | 188507914 | Rdr | 61 00 2d 62 | ok | AUTH-B(0)
188512414 | 188517150 | Tag | 01 02 03 04 | | 188521244 | 188530620 | Rdr |95! cb! 40 8c 0f! 84 ec 75 | !crc| ANTICOLL-2
188539152 | 188543824 | Tag | e7 86 42 2d | | 188614336 | 188619104 | Rdr | 30 de 37 97 | !crc| READBLOCK(222) 188622644 | 188623284 | Tag | 07 | | 188826048 | 188827040 | Rdr | 52 | | WUPA 188828596 | 188830964 | Tag | 44 00 | | 188839586 | 188850114 | Rdr | 93 70 88 04 53 5d 82 17 d3 | ok | SELECT_UID
188851670 | 188855190 | Tag | 04 da 17 | | 188857926 | 188860390 | Rdr | 95 20 | | ANTICOLL-2
188862074 | 188867962 | Tag | 42 a7 49 80 2c | | 188872006 | 188882534 | Rdr | 95 70 42 a7 49 80 2c 2d 5e | ok | ANTICOLL-2
188884090 | 188887610 | Tag | 08 b6 dd | | 188977072 | 188981840 | Rdr | 50 00 57 cd | ok | HALT ................

I try decrypt this with mfkey32 C:\prox\ProxSpace\pm3\tools\mfkey>mfkey64 42a74980 01020304 95cb408c 0f84ec75 e786422d 30de3797 MIFARE Classic key recovery - based on 64 bits of keystream Recover key from only one complete authentication!

Recovering key for: uid: 42a74980 nt: 01020304 {nr}: 95cb408c {ar}: 0f84ec75 {at}: e786422d {enc0}: 30de3797

LFSR successors of the tag challenge: nt' : 20f8ed56 nt'': 3c2bcdad Time spent in lfsr_recovery64(): 0.14 seconds

Keystream used to generate {ar} and {at}: ks2: 2f7c0123 ks3: dbad8f80

Decrypted communication: {dec0}: 500057cd

Found Key: [a0a1a2a3a4a5]

I found bug in this command. Why proxmark think that 30 de 37 97 this is decrypt communication ? After authorization, all communication is encrypted. And this is actually the halt command 50 00 57 cd.

And 2 problem with MCT: Error: None of the keys were valid for reading. The MCT often returns an error when authorizing, when I attach a proxmark simulating a classic card to the phone. I tried it on acr122, everything works well there.

[pwpiwi]

I am counting three:

76362588 | 76367292 | Rdr | 60 3f 81 b2 | ok | AUTH-A(63)
76760700 | 76765404 | Rdr | 60 3f 81 b2 | ok | AUTH-A(63)
77171052 | 77175756 | Rdr | 60 3f 81 b2 | ok | AUTH-A(63)
``|

[maxben14]

@pwpiwi , you watch log beetwen acr122 and proxmark how emulator. I said that have problem with my device and android but my device and acr122 work good and AUTH work correcton acr122.

[pwpiwi]

... and I continue to tell you that this is the proxmark github repository. Not the Android repository and not your device repository.

[iceman1001]

Its hard with all these repositories, which one to write to?

[cjbrigato]

Starting a vote to rename this issue from "hf mf sim bug" to "maxben14 bug".

[maxben14]

@pwpiwi, but proxmark in emulator mode with new firmware also have problem AUTH with android. 19694544 | 19695536 | Rdr | 52 | | WUPA 19696772 | 19699140 | Tag | 04 00 | | 19708184 | 19718712 | Rdr | 93 70 01 02 03 04 04 8e 25 | ok | SELECT_UID
19719884 | 19723404 | Tag | 08 b6 dd | | 20280162 | 20284866 | Rdr | 60 00 f5 7b | ok | AUTH-A(0)
20289558 | 20294294 | Tag | 01 02 03 04 | | 20298338 | 20307714 | Rdr | 6c 58! c8 8f! a4 ca! 91! 82! | !crc| ? 20316310 | 20321046 | Tag | 9b 0d e1 07 | | 20372708 | 20377476 | Rdr | 50 00 57 cd | ok | HALT 20381080 | 20381720 | Tag | 07

[merlokk]

This problem on android side) Proxmark not so fast

[maxben14]

@merlokk , problem in timing of proxmark. A good transport turnstile can easily distinguish a proxmark from a real card. Is it possible to speed up the performance of a crypto1_bit function so that the response time is close to that of real cards ?

[iceman1001]

This issue is closed. discussion on enhancing performance of the current crypto1 impl is interesting but not suited for Github but on the forum. If @maxben14 want fast impl, feel free to do so. No-one has "really" improved it since 4years when @pwpiwi change sorting algo inside it.

[pwpiwi]

The improved sorting speeded up the nested attack only. I would assume that @merlokk is right and the problem is on android side. The timing of hf mf sim is OK according to the NXP specs. And I would assume that commercial readers are obeying the NXP specs as well.

[maxben14]

@iceman1001, can do calculate filter function with help tables and win many cycles of CPU time.

[iceman1001]

could possible help, but is useless on device since it doesn't have enough ram. Just the prng-table takes 64kb if you were to use that. All ram we have to play with is 64kb. If you can fit in a speedup-version of crypto1 into the space requirements, go ahead! Go nuts!