Closed maxben14 closed 6 years ago
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)
``|
@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.
... and I continue to tell you that this is the proxmark github repository. Not the Android repository and not your device repository.
Its hard with all these repositories, which one to write to?
Starting a vote to rename this issue from "hf mf sim bug" to "maxben14 bug".
@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
This problem on android side) Proxmark not so fast
@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 ?
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.
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.
@iceman1001, can do calculate filter function with help tables and win many cycles of CPU time.
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!
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.