Client checks pm3 versions coherence

RfidResearchGroup / proxmark3

Iceman Fork - Proxmark3

http://www.icedev.se

GNU General Public License v3.0

4.08k stars 1.07k forks source link

Client checks pm3 versions coherence #842

Open doegox opened 5 years ago

doegox commented 5 years ago

Client should check if pm3 is running the corresponding code version and alert user if not the case

iceman1001 commented 5 years ago

yes, very important one. Would save a lot of stupid mess-ups on forum..

doegox commented 5 years ago

Still we've to be careful how to set it up...

newly compiled fw + newly compiled client = ok
newly compiled fw, latest client but not recompiled after fw changes => must be ok
latest fw but not recompiled after client changes, newly compiled client => must be ok The issue is that when developing e.g. client, you don't want to be obliged to regenerate fw with new version info and flash it again, and vice versa.

doegox commented 5 years ago

Proposition : When client compiles it embeds info about armsrc/version.c.

client can be recompiled several times, still embeds same armsrc/version.c
if armsrc changed and reflashed, what to do?
- by default we mandate recompiling client too
- besides embedded armsrc/version.c info, client can also dynamically look at armsrc version (can be e.g. via env variable and proxmark.sh would take care of that for developers) and tolerate newer armsrc fw if client src isn't newer than compiled client

iceman1001 commented 5 years ago

Either we make a new UsbCommand, CMD_GET_IMPLEMENTED,. old firmware will say "unknown command". Hence we print message your FW seem too old.

.. Now it also means we remove defines guards on client side and make them guarded by a IF, to global struct about which functions HW supports.

doegox commented 5 years ago

yes what you say is exactly what needs to be done, but for doegox/proxmark-internal#15 which is a different issue to tackle

iceman1001 commented 5 years ago

So we have two issues about the same-ish kind of problems (27 and 15). the idea is ONE client, MULTIPLE fw versions support.

The device can never be in charge of the client. Hence "if arms change and reflashed" ie its newer than client. 1. dont mix client/fw rule. 2. doesn't matter as long this new style.
The client either ask about version/function support implemented, (new client) or it doesn't (old client).

For old clients we don't have any solution. Just update to get the latest. Since everyone wants the new improvements anyway there is a high motivation for users to upgrade.

doegox commented 5 years ago

FTR: beware people compiling from ZIP don't have git version info. What to do ? Two strategies:

ignore git version if missing, rely solely on compilation timestamp to see if image & client are in sync
push automatically fresh version.c at each commit/merge:
- add hook like https://gist.github.com/ThomDietrich/7127ca6e45dd4747e86ad9a609e1aeeb
- share hook like https://www.viget.com/articles/two-ways-to-share-git-hooks-with-your-team/ with some commands in the makefile to deploy them from e.g. .githooks

iceman1001 commented 5 years ago

how far are we on this one?

iceman1001 commented 5 years ago

We have a perl script that generates all our version info, and the solution for ZIP downloads of the repo we use timestamp on a file as indicator of when the ZIP folder was downloaded.

doegox commented 5 years ago

currently the timestamp in version.c is when version.c is created, not the zip folder timestamp.

iceman1001 commented 4 years ago

With the Device support command, where we can detect which version, hw functionality, standlone etc this feels like it can be closed.

doegox commented 4 years ago

Hmm no, it's just about supported features so far. What we need is kind of API version check. Ideally every time a command has been changed both on arm & client in non-backward-compatible way, version should bump, so you never send old cmd to new fw or vice versa.