flipperzero-firmware
flipperzero-firmware copied to clipboard
flipperdevices
KDF plugins
Describe the enhancement you're suggesting.
A significant enhancement for the NFC app would be an interface to allow libraries/shared objects to be registered (or loaded from a fixed SD card path) which could be used as custom dictionaries for bruteforce attacks. This is particularly useful for key derivation functions (KDFs).
As discussed on the Q&A, we're hoping to identify an ideal location/API to implement this which would be compatible with multiple NFC protocols without duplicating code - such as MIFARE Classic, DESFire, and Ultralight C. Either C or JavaScript functions can be written for use with this handler. The external function is loaded from the SD card and called with the known card parameters (e.g. ATQA, SAK, CUID), which returns an array of zero or more keys. Each key is tested as a part of the overall dictionary attack against the card.
This approach ensures that the firmware remains free from copyrighted or proprietary algorithms, while (often) eliminating more advanced NFC attacks such as MFKey or Nested.
Anything else?
No response
We already have NFC app plugins, it's capable of loading required plugins on demand and exposes all required APIs (?). For simple KDFs that should be enough, but you can't for example display anything or ask for input (don't know in what case it might be necessary). And the only thing we don't have right now is probably application catalog support.
We already have NFC app plugins, it's capable of loading required plugins on demand and exposes all required APIs (?).
This is news to me. Is there an example somewhere that uses this you can point me to?
Is there an example somewhere that uses this you can point me to?
Plugins in applications/main/nfc/plugins/supported_cards and their loader in applications/main/nfc/helpers/nfc_supported_cards.c. I didn't know parsers could do that, I also got a hint from @foxushka recently
Is there an example somewhere that uses this you can point me to?
Plugins in
applications/main/nfc/plugins/supported_cardsand their loader inapplications/main/nfc/helpers/nfc_supported_cards.c. I didn't know parsers could do that, I also got a hint from @Foxushka recently
Might be misunderstanding the requirements here:
In: nfc_supported_card_plugin.h
* To add a new plugin, create a uniquely-named .c file in the `supported_cards` directory
* and implement at least the parse() function in the NfcSupportedCardsPlugin structure.
* Then, register the plugin in the `application.fam` file in the `nfc` directory. Use the existing
* entries as an example. After being registered, the plugin will be automatically deployed with the application.
*
This sounds like the code has to be built with the NFC application. The intention here is for something that users can download separately and load to their SD card, just like how FAPs can built and loaded separate to the firmware in a seperate git repo/etc. Unless there's a way to do it separately that I'm missing that doesn't require modifying the nfc application.fam that I've missed?
No, parsers aren't built into NFC app. They are located on SD Card in plugins folder, ending with _parser.fal. Probably there is no way to build parser outside NFC app, but NFC app currently can discover and load them on demand (nfc_supported_cards_get_next_plugin function). You are referring to parser implementation guide, they probably didn't think anyone would try to use it for KDFs and something that won't be shipped with firmware.
Are there any plans to have NFC parser plugins published to app catalog? That would allow for plugins to be distributed without including every one of them in the main firmware repo.
So, while attempting to write a plugin using the new parser API to do this, I've identified several issues.
The main issue is that parsers are categorically different than KDF's. We might be able to hack in a KDF to a parser, but we're using the interface incorrectly and I'll explain where a drawback to that might be next. But essentially to write this plugin, we are writing a parser which may never parse or read anything. The only function that should be run is the verify function, but even that should return false because we're not utilizing the parse or read functions.
~~The second issue is when the parsers are run. KDF's should be run at least once at the beginning of the key recovery process. As far as I could tell, they are run when the data on the card needs to be read or parsed (at the end of the recovery process), which is after the entire key recovery process. If users need to wait about 5-10 minutes to check whether the KDF is applicable, it reduces their utility.~~ Edit: According to @Foxushka the parser plugins are run before the key recovery process. If I can confirm this later today, the second issue is invalid. :tada:
Having a dedicated hook that runs immediately before the dictionary attack that gets passed the card type and UID and can talk to the card to do things like list desfire appids or read the mifare classic MAD - or maybe that functionality would be done by the NFC app already and pass that information along to the KDF function as well (with the ability to indicate 'no mad' if not present), then the function can respond with a small card-specific set of keys to try (ideally the list isn't just the key, but key+sector information for mifare classic, pwd and optionally pack for ultralight, appid+keyid+key information for desfire, etc). Obviously the desfire stuff would be a future thing, but thinking about those sorts of patterns now would enable other card types more easily in the future rather than just assuming everything is mifare classic.
Still thinking about the requested feature. I think that it's possible to implement what you want with nfc plugins, but they were not designed for this purposes. Meanwhile the concept of supported cards and nfc plugins should be improved.
Maybe you have some examples on how it works on other platforms? It also would be very helpful if you describe how you want this feature to work step by step in details for one specific case.
