Input file format [question] about crypto1_bs HOT 8 CLOSED

Today I realized that the ! in the txt apparently indicates that the parity-bit received from the tag did not match the oddparity of the received (and encrypted) byte. Sadly I am still unable to recover the key. The search does seem to work, but results in 0xffffffffffff which is not correct.
Another strange thing I noticed is that the exclamation mark is always set for the first byte collected by my code. I'm not sure how this relates to anything, could simply be a weakness in the tags rng.
Anyway I'm closing this issue as my assumptions seem to now be correct. :)

from crypto1_bs.

Hey, the exclamation marks indicate incorrect parity bits (taken from the way the proxmark3 software displays it).
I'd be happy to help you get to the bottom of the issue but it sounds like you're getting there on your own. I hope you took note of the conversion .py scripts I included. To be honest I don't remember the exact details of what data goes where myself. I took the file formats in my tools from piwi's proxmark3 version of the nonce collector and bla's craptev1 .txt format. The third variant of how the data is collected is shown in the libnfc tool and that was taken from mfoc.
As noted in the readme the new attack is now also usable with an up to date version of mfoc.
Between those 3 sources I'm sure you can figure out what it all means. Good luck. :)

from crypto1_bs.

All I own is a RaspberryPi and a MFRC522, this is both good and bad. Bad because I means I have to put in a lot of work to get anywhere at all (no libnfc support) and good because I get to learn a bunch of things I would otherwise never get to touch 😂
For the record, the bin format seems to be closer to my initial assumption. It seems to store 8 bytes of data followed by the 8 parity bits (the way they appear in the encrypted bit stream). This makes implementing a collector a little more complicated as 8 bytes of data corresponds to 2 n_Ts followed by the parity bit for both of those. This leads to the collector having to keep the first n_T in memory while the second one is collected to then print them out both. Not too hard though.

from crypto1_bs.

IIRC this is correct. As far as I remember the binary format stores 2 encrypted nonces and then 8 parity bits for the two previous nonces. Looking forward to what you're building.

I thought it wasn't possible to do the attack with the MFRC522. But I found some information that seems to indicate I was wrong. https://github.com/HakonHystad/MFRC522_nested_attack

I think I might have one of those lying around somewhere if you need some help with testing.

from crypto1_bs.

That repo is the one I am currently building my code on. Took me a while to fully understand it, but i currently have a working implementation to collect encrypted error messages as well as encrypted challenges. Gaining access to the raw data exchange is a matter of setting a corresponding register on the chip. I don't see anything that would prevent this chip from being directly supported by libnfc, but I don't think I am up to that task just yet.
Another issue I have is having no tag that is know to work. I have two tags where the rng is too weak to collect any but two n_t and a second one where the first bytes parity seems to always be "incorrect" according to txt format. Like I said, all I get is ffffffffffff as a result of the search even though the key actually is 0f0f0f0f0f0f. I saw this mentioned in #17, with no definite answer on how to fix it though.
I would be nice to reduce the cost of recovering Mifare classic keys to 3€ using the MFRC522, instead of ~40€ for a libnfc compatible reader or even a proxmark...

from crypto1_bs.

I think you are just reaching the end of the keyspace because of incorrect inputs like in #17 . Got some test data/code?

from crypto1_bs.

I finally got it working and it's working like charm. Thank you for your interest, offers and hints!
For the record, I used a bad logic in the nested auth logic causing it to reauth the already known block instead of actually requesting the new one. I am still not sure how that resulted in the values I saw, but.. yeah :)
Next steps on my list:
rewrite to code to also run on an arduino
implement the bin file format
and release it on github 🎉

from crypto1_bs.

Awesome!

from crypto1_bs.