Upgrading Proxmark3 Easy

I just upgraded my proxmark3 easy to the latest version (in this case, v4.14831).

I followed the steps listed in the Getting Started Topic.
Getting started with the proxmark3 easy

I figured I’d “dumb down” that section below here, just in case any new user(s) like me has issues. Hopefully this is helpful and not just a spam post.

  1. Make sure you are in ProxSpace and not the proxmark3 folder; If you are, issue a quit command
    Capture

  2. Issue Commands (Coffee Optional :coffee:)

cd proxmark3
git pull
make clean && make all
./pm3-flash-bootrom
./pm3-flash-fullimage
pm3
hw tune

  1. Look for:
    [+] LF antenna is OK
    [+] HF antenna is OK

Note: If you completed the step for “A simple trick to speed things up”, where you forced ProxSpace to auto open the proxmark3 client, you don’t need to do this again, since you never changed the original file.

Happy proxmarking!

7 Likes

Or

Replace steps 2 to 6 with

cd proxmark3
git pull

git will update the source code to the latest version, then you can just compile and install.

5 Likes

Well I be damned…I’ll update the instructions. I appreciate it.

2 Likes

So to confirm, you don’t really have to issue the MV command? Only if you want to archive the old version?

1 Like

git keeps every version ever commited, no need to archive unless you mean the builds ig

Git is a version control system, so there isn’t really any need to create a separate archive. If you want to go back you can always do git checkout *version* where the version is the commit number of the release.

git checkout 2c4c676 

Would pull down v4.14434 for example.

I do wonder how reproducable the builds are though, kinda regret my message because keeping builds around is actually useful for rollbacks

1 Like

Ok. and just to confirm my question… You don’t have to do the MV command, correct? Why would someone want to do that then?

1 Like

I would think that you would only want to do a ‘mv’ command to save just the builds. I would have to check the exact location to save the builds, but yes, you wouldn’t need to save the source code at all.

2 Likes

Edited original post to reflect suggested changes

If you are updating the client after an already fully compiled build, you dont need to make clean && make all as this will compile all the code again.
A faster way to compile the code from scratch is using the switch -j which takes advantage of hyper threading on your CPU (if supported of course). So compiling for the first time try: make clean -j && make all -j.

If compiling after after git pull on a compiled build before try just make -j as this will only compile newly changed files and use hyper threading to speed that process up.
If you have changed the makefile.platform the youll need to run make clean -j first.

Flashing the bootrom is very rarely needed so I usually skip manually flashing bootrom unless the files from git pull affect anything to do with bootrom.
There is also a combined command for flashing bootrom and then fullimage for you; pm3-flash-all.

The difference between running ./pm3 and pm3 is about local directory vs usr/local. If you usually like to call pm3 from any directory you must then, after compiling a new build, run make install -j to update the files in usr/local.
The script pm3 is just a little magic to automatically determine what port to use for the connected proxmark. This only becomes a little issue if you have multiple proxmarks connected to the same machine thus you would want to specifically call the client and tell it what port to use to ensure you are connecting to the correct proxmark.

No need to run hw tune as this is purely informational and does no active tuning of the antenna. Id generally only recommend running this command if you have made your own antenna and testing out its performance. However, if you are solely using the stock antennas, then no need to run hw tune

In short, to update from a previously compiled build I usually run:

  1. cd proxmark3
  2. git pull
  3. make -j
  4. ./pm3-flash-all
  5. ./pm3
    5.1. coffee
2 Likes

-j may or may not be useful depending on your machine. My machines are all ARM based so I never use it.

Doing a clean isn’t going to hurt anything but if you really want to speed it up then sure, skip it.

Personally I think 5.1 should be split into two (or more) tasks…

  1. Prepare drink of choice
  2. cd proxmark3
  3. git pull
  4. make -j
  5. ./pm3-flash-all
  6. ./pm3
  7. Partake of drink of choice.

The last task can be inserted at any point after the first task, and can be performed multiple times (repeat the first task as needed)

1 Like

Using the -j switch on an ARM based machine doesnt do any harm and still allows for additional jobs to be run.
Doing a make clean also doesnt hurt but its generally unnecessary if you are just looking to compile the client again and get going.

The steps I listed were all commands with 5.1 being executed within the client. I shouldve added on some additional non-command to make sure we are all getting our hydration in.

I agree that -j won’t do any harm. I just don’t see the point of adding it on my current machines.

At work I deal with “the cloud” or very large AIX systems. At home I go small and cheap. I am always impressed by the difference in size and compute power between when I first started and now.