Closed yoshi57 closed 8 years ago
You should know the arguments you give the tool are blocks, not sectors. But these are zero-indexed! So to get the key for sector 0 you'd pass blocks 0-3, for sector 1 you'd pass 4-7, for sector 2 you'd pass 8-11. Passing block 12 would land you in sector 3, not 2. For 4k cards, blocks 128 and up are grouped in sectors per 16, not 4. https://en.wikipedia.org/wiki/MIFARE#/media/File:MiFare_Byte_Layout.png (warning, full size is very large) I hope you can confirm it works when you take this into account.
Oh man, I did totally missed that out! As mfoc and mfcuk work with sector I didn't pay attention to that. So yes, using the correct block number I'm retrieving the missing keys. Working very good, impressive. Thanks
Hello,
I don't succeed getting the keys from a new mifare card. I guess it's a new Hardnested one. I Have two very similar mifare tags. One about 5/6 years old and a new 2016 one. I've compiled everything on Ubuntu 16.04 x64 (no VM) using an ACR22U102.
The old tag is vulnerable to mfoc an retrieve keys with 1-4 probes. The new one is not vunarable to mfoc (2000+ probes) neither to mfcuk (8+ hours )
So I tried libnfc_crypto1_crack on the new key but I always get: Found key: b0b1b2b3b4b5 Which, obviously, isn't a working key. b0b1b2b3b4b5 is the key of the others sector, but not for the sector I'm targeting. (a0a1a2a3a4a5 is the A key for all sector) I've tried different sector and key for attack vector, but I've always get the same result.
As a curiosity I've tried libnfc_crypto1_crack with the old tag and I get the same result.
Any idea why I'm getting this kind of results ?
If it helps here is the nonce for the old tag: 0xaae32f78_002B.txt Correct B key for sector 2 is 89 38 22 5d 43 8f
The new tag: 0xae38b587_012B.txt 0xae38b587_013B.txt