Closed ghost closed 4 years ago
This is an older idea which has been bounced around. It resurfaces every now and then. Your opt-in / opt-out describes accurate some of the issues.
The most important issue is tracking, the community is very privacy concerned. Since there many gov/police/mil/ lock vendors/ pentest/redteam/ users of this project there are a intricate balance to uphold.
Covert entry (mil/police/gov) is generally not interested in a phone home/ share on internet feature because of obvious reasons.
red team/pentesters etc, usually operates under NDAs.
I recently started to add a function to upload, out-in style, to a place. However that would have to be a place which isn't targeted for take downs from said formented organisations.
The benefits of getting keys shared would benefit from same region, since systems usually exist in certain places, ie, gps coordinates or general region labelling.
Ie, say you are in Sweden, you want ideally to test all your own known keys, all known keys in the region, all known keys based on system identifcation, then in the end try all kinds of known keys.
The default list is large as it is, 900 entries takes some time to try all of them. Even if we optimized it.
The autopwn / fchk / chk etc commands should already try found keys against other sectors. The process for a Mifare card is;
Depends on purpose. Speed ?
When it comes to dictionary and interoperability, like MCT app, then that app already has a copy of this dictionary and is regular synced.
Back to sharing keys.
How to maintain the trust of a completly anon uploading/sharing?
my 2 cents worth.
I was thinking about a local "found" key file. My thought was something like this: Check a card to see if you can find a key, load both the default/supplied key and the local key file. When a new key is found, append to the local file (on top of the normal dump/save files).
The idea was based on my need to use some known keys, but NOT publish as iceman covered. So what I do now is have my own file and update by hand as needed. Then run with the supplied and my own local by hand.
The auto save of keys to a local file, means by default they will be used in future card checks. Then if I did not have an issue about sharing keys, then I have the local file "new keys" that I could review and send as needed (eg. git PR)
I did have a think about the auto/network approach, but for me, most of the time when I find new things I am in the field and may or may not have network access.
That was my idea aswell. haha, great mind think alike ;) However I wanted it to be stored on the flashmemory on the device. So when ever there was a fchk/chk/ etc, it always checked that file on flashmem first. That way your device learns your cards you use most frequently.
That file could then be "opt-in" to be shared with a command like pm3-> share nnnnn.dic
Any more ideas or shall I close this one because of inactivity.
Is your feature request related to a problem? Please describe. No way for users to share new keys that are discovered through nested/sniff/bruteforce/offline attacks
Describe the solution you'd like Add functionality to check keys against local dictionary and offer to upload newly found keys so they are available to all
Additional context This should be completely anonymous. Opt-in vs opt-out?
Opt-out provides guaranteed new keys, and generally most usage of pm3 client is by people who are skilled enough to read a document indicating how to opt-out, but introduces issues with keys being uploaded without user consent.
Opt-in ends up with same problem, most users won't share keys because they don't know how, but ensures no unwanted keys are uploaded without user consent.
Is this something that would be useful for the scope of this project? What type of usage does mifare have to make this feature worth it where a different attack may work? Should it be part of the pm3 code-base or a separate external LUA script (and how does an external script tie in with default enabled?)