Rewrite of HF_MATTYRUN standalone mode

[michaelroland]

Hej!

This is a rewrite of the standalone mode hf_mattyrun. It enhances the mode by

• adding support for other card memory sizes besides 1K,
• by adding support for a user key dictionary (passed to the standalone mode via the emulator memory),
• by updating the built-in dictionary to the full contents of mfc_default_keys.dic, and
• by properly initializing the emulator with correct anti-collision parameters (UID/ATQA/SAK).

Description

This standalone mode uses a predefined dictionary (originally taken from mfc_default_keys.dic) to authenticate to MIFARE Classic cards (cf. hf mf chk) and to dump the card into emulator memory (cf. hf mf ecfill). Once a card has been dumped, the card is emulated (cf. hf mf sim). Emulation will start even if only a partial dump could be retrieved from the card (e.g. due to missing keys).

This standalone mode is specifically designed for devices without flash. However, users can pass data to/from the standalone mode through emulator memory (assuming continuous (battery) power supply):

• Keys can be added to the dictionary by loading them into the emulator before starting the standalone mode. You can use hf mf eload -f dump_file to load any existing card dump. All keys from the key slots in the sector trailers are added to the dictionary. Note that you can fill both keys in all sector trailers available for a 4K card to store your user dictionary. Sector and key type are ignored during chk; all user keys will be tested for all sectors and for both key types.
• Once a card has been cloned into emulator memory, you can extract the dump by ending the standalone mode and retrieving the emulator memory (hf mf eview or hf mf esave [--mini|--1k|--2k|--4k] -f dump_file).

[github-actions[bot]]

You are welcome to add an entry to the CHANGELOG.md as well

[iceman1001]

nice rework!

I only quickly gazzed over it and your idea of adding the whole mfc_default_keys file. It would be contradiction to what you want to archive. Too big dictionary file and the device will just hang trying all keys. At max, only use say 100 known keys. Then you are on the limit already for a decent speed.

[michaelroland]

True, although using the whole mfc_default_keys file + a few extra keys took roughly 12-14 seconds per sector per key type if keys are not part of the keyset (about 7 minutes for a MF 1k card, about 17 minutes for a 4k card, if all sector keys are not found with the tested keyset). That's not nice given the limited user interface for explaining what's going on, but works sufficiently well if you have time to let the Proxmark sit unobserved on a card for a while. My intention of the rewrite was to mimic the behavior of the dictionary read mode of Flipper Zero (with the difference that the UI makes it more obvious why scanning takes so long).

But it may indeed make sens to leave that choice to the user. I tried to double the amount of keys but probably ran out of memory (at least that's what I assume; in fact, bigbuf allocation worked and hw status showed a few hundred bytes of available memory, but the Proxmark kept rebooting itself soon after starting the scan).

What do you consider a useful default keyset?

[iceman1001]

Yeah, I would think between 100-160 is about upper limit.

[iceman1001]

Ping,

Like discussed for this PR to be merged you need to remove the large default keys list and only keep the first 100 - 160 keys.

[michaelroland]

Sorry, still on my TODO list ;-) I'll try to get back to that once the semester is over.