Closed psyoptix closed 7 years ago
What OS are you on?
Linux sliver 3.13.0-108-generic #155-Ubuntu SMP Wed Jan 11 16:58:52 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
By the way when I run solve_bs on the 0xcafec0de.txt file I get the key 0x626c61003333.
I cannibalized the mfoc code to put together a nonce collector. Output is also in .txt format. Using that solve_bs now works. I guess that means the issue I'm having is in the nonce collection code in libnfc_crypto1_crack...
Oh, that's strange. I'm glad you figured it out. Hope you can send me back a patch which fixes it for you later on!
I was getting the same issue .. 0xffffffffff returning but it came from that i used the wrong block in argument for libnfc_crypto1_crack ! I believed that i just needed to put the sector i wanted to crack for obtaining key, but Crypto1 really need the correct block to crack the key.. it means block 3,7,11,15 etc ....
Example:
All sectors are using key B a1a2a3a4a5 except sector 8 which no key is found.
I use this command: ./libnfc_crypto1_crack "one known key B" "block of known key" "type of known key" "block you want to crack" "type of key you need"
So
./libnfc_crypto1_crack a0a1a2a3a4a5 3 B 35 B
( block 35 is the adress where it stocks key for sector 8 )
Now i don't have any troubles anymore.. and the better part is that you can obtain either key A or B for all sectors from only one known key .. no matter of its type. =)
Hope i could help ;)
I guess this issue can be closed.
I've been playing with libnfc_crypto1_crack but have been having some problems. For some reason regardless of which key I try to recover, solver I use, or rfid card I'm using the recovered key is always 0xffffffffffff which is not the correct key. (E.g. authentication fails with 0xffffffffffff but works with 0xa0a1a2a3a4a5.)
This happens both when I try recovering Key A and Key B for various sectors. I've also tried collecting anywhere between 1800 nonces up to 8,000 nonces. I've tried 2 different cards (one hardened and one not). I've tried both solver_bs and the craptev1-v1.0 solver (threshold 85).
Any idea what's going on here?