MifareClassicTool icon indicating copy to clipboard operation
MifareClassicTool copied to clipboard

Quick dump

Open ikarus23 opened this issue 9 years ago • 4 comments

Read and dump tags as fast as possible. Some things needed for this feature will be:

  • Key files that contain mapping information
  • A faster read behavior that makes use of the extended key files
  • A possibility to directly dump the tag data after reading

"systemcrash" had some ideas about the new key file format:

I wanted to add something to this idea: namely, the ability to use key-files that can specify which sectors they apply to, which should accelerate, or obviate key-mapping. The idea is to specify which key-files to use for reading/writing dumps. If using specified Keys on targeted sectors does not work, the default behaviour should be to fall back to building key-maps as it does today, on a per key/sector basis. e.g. say the user specifies targeted keys for 0A, 0B and 1B, but needs to read 0A, 0B 1A, 1B, 2A 2B. Those keys could be tried for the other sectors as necessary, especially if there are no other keys in the file.

Today it goes something like # this is a comment

FFFFFFFFFFFF

It could be extended to something like one of the following - whichever best suits the internal workings: # this is a comment # keys start without a # comment, and end with optional colon then number to specify # at which sectors they should be used and optionally Key A/B in brackets ( )

FFFFFFFFFFFF:0-1(A,B)

Or # this is a comment # keys start without a # comment

FFFFFFFFFFFF:0A,0B,1A,1B,7A,7B

or # this is a comment # keys start without a # comment

FFFFFFFFFFFF;A:1,2,3,4,5,6,7;B1,2,3,4,5,6,7

or # this is a comment # keys start without a # comment

FFFFFFFFFFFF;A:1-7,8,9;B1-7,10,12

ikarus23 avatar Dec 12 '14 18:12 ikarus23

Id rather suggest keeping things separately cause otherwise keyfiles are not reusable (for pm3 for example) or cover layout mapping in the comments # so that key files are still compatible with pm.

osysltd avatar Mar 10 '17 23:03 osysltd

Really like this feature! But instead of this special file format for key mapping, may be better use mapping from dump file itself, like nfc-mfclassic does. In UI it might be just one new option Read/Write using dump: [Chose].

KKomarov avatar Mar 04 '18 20:03 KKomarov

Yep, that would be really appreciated. Maybe using the keys in the order they're listed in the file, without trying to map. This should be an option: when you select a keys file you can check a flag don't key map, without need for special formatting. I know it's not as useful for lot of people, but when you read hundreds card a day with the same keys, in the same order.. Could be useful.

edit: I just searched and found out that ikarus is aware of the limitation and frustation while reading all day the same cards, but he doesn't think to develop this function right now, so I'll try to fork and pull in May/June 2018.

lambia avatar Mar 15 '18 20:03 lambia

Hi there! Yeah, I'm still a bit low on free time. However, I like your suggestions of just using a dump file or a key file with fixed mapping. Something like this should not be too hard to implement.

I will move this issue up my priority list but I can't put a date on it. If you want it as soon as possible feel free to fork and implement something like this your self ;)

ikarus23 avatar Mar 16 '18 22:03 ikarus23