Input file format [question]

[lucaelin]

This is not really an issue with the project, but I do run into issues :D I am trying to implement my own collector, but I can't seem to understand the input-file format used for neither the txt nor the bin version. Maybe you could help me out a little? I was mostly focused on the txt-format. My initial guess was that the hex values in each line are the bytes of the encrypted nonce in order of time. So the first byte received by the reader is the first byte in the line. I was also assuming that the ! is present if the parity bit corresponding to that byte was 0. Trying my own input-file, I ended up with a Segfault due to the search space ending up with a size of 0. I've now tried countless different formats, switching le to be and reordering the bytes, flipping the parity and so one. None of it seems to work. 🤷 Is there some kind of magic encoding going on or was my assumption correct and it's just my code being flawed in another way (could very much be the case btw)? Thanks for this cool project! I learned a lot about bitslicing! Thanks :)

[lucaelin]

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. :)

[aczid]

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. :)

[lucaelin]

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.

[aczid]

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.

[lucaelin]

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...

[aczid]

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

[lucaelin]

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 :tada:

[aczid]

Awesome!