Improve MFC workflow

[doegox]

It's fine when it comes to breaking and cloning to Chinese cards but "regular" operations on a MFC are a PITA.

• hf mf auto => we get bin/eml/json + keyfile
• To modify content, ppl will probably modify EML (easier) or BIN+KEY
• How to write it back ? hf mf restore expects all current keys to be ffffffffffff and expects BIN+KEY to be written

Possibilities to improve that:

• [ ] hf mf restore to accept EML (so no need to convert BIN->EML)
• [ ] hf mf restore to accept original keys file
• [ ] hf mf restore to accept a dump file (EML/BIN) as key file, so no need to extract keys from dump to create key file
• [ ] add hf mf format to (try to) reset data, keys and ACLs (without touching block0)

what else?

[doegox]

Maybe ask confirmation / provide options to write to block0, to OTP and irreversible things to ACL

[iceman1001]

guess why I wanted a better dump format :)

The idea with supporting new format is found here https://github.com/RfidResearchGroup/proxmark3/issues/129

The format, well I sorted that some years ago with formatMifare.lua... https://github.com/RfidResearchGroup/proxmark3/blob/master/client/luascripts/formatMifare.lua

Now that we have better naming on key/data files, we can let restore use it. Before we have only one name for keyfiles, you didn't want to do it wrong :)

[slurdge]

I hit this exact problem quite often. Right now my solution is:

• Use pm3 for all read/hack operations;
• Some script to convert it to the right format;
• Edit and send to my phone/Edit on the phone;
• Use MCT to write the tag.

[iceman1001]

the convert dumps to correct format is work-in-progress. Plenty of commands now saves in bin/eml/json , which eliminates the need for convertion. The next step is for all commands that loads a file, to take a bin/eml/json formatted file.

The restore, has problems with original cards. Since magic cards can be wipe (gen1a) they are easy. Original cards is empty, with default keys and AC once a dump file has been restored on to it, it has potentially new keys and AC. next time you want to restore a dump on to a none-empty card, you will need two sets of keys, hopefully the AC still allows for writing but there is no garantues for changing keys again.

even if you now tries to wipe a non-empty orginal card, the card AC might not allow for resetting ST.

This is why you stop fiddling with original card and "dump/restore". Its not a proxmark mess, its a card mess. So you go magic cards. The Gen1A is easy,, you can wipe, restore, load, and if its perfect you can even mess up block0. Good support in pm3 client. Gen2... now thats a different story, this card edit block0 yes, but appart from that the card has the same issues as original cards has. We can perma lock it with bad block0, we can perma lock ST.

Still not a Proxmark3 client command issue. its the design of the cards.

hf mf restore assumes what it can, but for the rest it can't. We can improve with adding a 2 keyfiles, but that doesn't garante a successful restore still.

[merlokk]

maybe too complex but what i did in my reader: we have keys file.

1. try all the keys as key B
2. try to read block 3 and look into bits
3. try all the keys as key A (if key A can work as we see in 2)
4. we have key to write and A/B
5. authenticate sector
6. write blocks 0-2
7. write block 3
8. repeat)))

a bit slow, but always works

[iceman1001]

That isn't the problem.

Problem is that you might end up with not a complete copy of the dump on the card if the access rights doesn't allow for writes.

[merlokk]

yes, but if you add key to file that you dont know 1st time (key for sector that you cant open) - you just resume write and it completes.

[iceman1001]

How does this solve the problem with a non-written block (normal or sector trailer) and not creating a exact copy of the dump file you are trying to restore?

The assumption of the restore command is that once it executed, the card has a exact copy of the file.

[slurdge]

Something that would be nice, is an option to write with always writable ACLs. We can override the ACLs on restore dump, such as if we know keyA/B, we will always be able to write data. I never saw a reader (yet) that verifies ACLs... We could even compute the smallest bit difference in order to preserve write capacity if we know either keyA or keyB (which we know, we are writing the dump).

[merlokk]

There is no 100% working solution. The card have too many cases in that we can't get info can you write or not. We can just try and if it succeeds - it ok. Only case if we have read/write access to key block with current key. Then we can analyze and write only if we can. But it rare case.

[iceman1001]

Indeed, there is no 100% solution. Hence current implementation is ok.

[doegox]

We can still get a restore that warns the user that only restore to empty is guaranteed to succeed, and give clear feedback on the result of the restore operation

[iceman1001]

Yes, adding such print would help. I tend to notice that even if we print, ppl doesn't seem to read. They just ask on twiiter, forum, github, without thinking...

[merlokk]

they dont know what they do) they need a button "copy card" or "add $100 to card" and thats all) and because of that they read but it not helps) some ppl who knows - they dont ask)

[iceman1001]

yes, and those who knows, don't have a problem with restore ;)

[doegox]

yes, and those who knows, don't have a problem with restore ;)

that's not what I claimed and what I read from @slurdge and @merlokk , all three of us have to go to complex lengthy ways because restore works only on formatted mfc.

even nfc-mfclassic is more user friendly :)

[iceman1001]

yes, its annoying dealing with non-formatted MFC cards.

And yes, I agree the command can be made better.

And no, nfc-mfclassic is not more user friendly

[doegox]

more user friendly regarding non-formatted cards. nfc-mfclassic allows to provide the current dump and the new dump, trying to replace current content with new one. mf restore has nothing to deal with non-formatted cards.

[iceman1001]

Closing since restore now takes bin/eml/json as dump, and seperate key file, and a param if you want to use that keyfile to auth. we don't have seperate keyfile for target card, but supports default 0xFFFFFFFFFFFF as in a wiped card.

Restore MIFARE Classic dump file to tag.

The key file and dump file will program the card sector trailers.
By default we authenticate to card with key 0xFFFFFFFFFFFF.
If access rights in dump file is all zeros,  it will be replaced with default values

`--uid` param is used for filename templates `hf-mf-<uid>-dump.bin` and `hf-mf-<uid>-key.bin.
          if not specified, it will read the card uid instead.
 `--ka` param you can indicate that the key file should be used for authentication instead.
          if so we also try both B/A keys
`--force` param is used to override warnings and allow bad ACL block writes.
          if not specified, it will skip blocks with bad ACL.

usage:
    hf mf restore [-h] [--mini] [--1k] [--2k] [--4k] [-u <hex>] [-f <fn>] [-k <fn>] [--ka] [--force]

options:
    -h, --help                     This help
    --mini                         MIFARE Classic Mini / S20
    --1k                           MIFARE Classic 1k / S50 (def)
    --2k                           MIFARE Classic/Plus 2k
    --4k                           MIFARE Classic 4k / S70
    -u, --uid <hex>                uid, (4|7|10 hex bytes)
    -f, --file <fn>                specify dump filename (bin/eml/json)
    -k, --kfn <fn>                 key filename
    --ka                           use specified keyfile to authenticate
    --force                        override warnings

examples/notes:
    hf mf restore
    hf mf restore --1k --uid 04010203
    hf mf restore --1k --uid 04010203 -k hf-mf-AABBCCDD-key.bin
    hf mf restore --4k