Proxmark3GUI: a Qt desktop front end for the Proxmark3 client

A front end for a client that already exists

Proxmark3GUI is a cross-platform GUI for the Proxmark3 client, and the README points at two upstream projects, the original Proxmark3 repository and the Proxmark3 Iceman fork. It also makes a recommendation, noting that the original repo has been unmaintained for a long time and that the author personally suggests using the Iceman fork. That recommendation is the single most useful sentence in the file, because it tells you what the GUI is built to talk to.

The division of labour is what matters here. The GUI does not implement the radio protocol and does not replace the client. It talks to the client over the serial port, forwards raw commands to it, and adds a graphical layer on top for the tasks that are painful in a terminal. The feature list makes the boundary clear. There is easy finding of the available serial port, support for raw commands of the Proxmark3 client for both the official and the Iceman line, and then a friendly UI to test Mifare cards with support for the different card sizes, MINI, 1K, 2K and 4K.

What the Mifare side adds is block level work. You can read all or selected blocks with a read logic the README calls well designed, write all or selected blocks, edit block data, and open binary files in .bin and .dump format as well as text files in .eml format. There is analysis of the access bits, support for Chinese Magic Card, and basic support for LF commands. The UI is customisable, and the Chinese description of the project is kept alongside the English one.

The repository is laid out as a Qt project with src/ for the sources, a config/ directory, a deploy/ directory, a doc/ directory for the tutorials and previews, and an i18n/ directory for translations, and the licence is LGPL-2.1.

Building on Linux with qmake and Qt5

The Linux build instructions are a plain qmake build, and they are worth reading carefully because they pin you to a Qt generation that has moved on.

cd ~
sudo apt-get update
sudo apt-get install git build-essential
sudo apt-get install qt5-default libqt5serialport5-dev
git clone https://github.com/wh201906/Proxmark3GUI.git --depth=1
cd Proxmark3GUI
mkdir build && cd build
qmake ../src
make -j4 && make clean
./Proxmark3GUI

The dependencies are git and build-essential, plus qt5-default and libqt5serialport5-dev, and the serial port library is the one that matters for talking to the device. The clone is shallow with --depth=1, the build is a separate directory with qmake pointing at ../src, and the parallel make is followed by a make clean, which is a slightly unusual pairing but is what the instructions say.

The qt5-default package is the weak point. On current Debian and Ubuntu releases, qt5-default is no longer provided in the form the instructions assume, so the apt line as written will not work on a fresh system. Anyone building this today will be resolving that themselves, either by finding a distribution that still packages it or by moving to qmake6 and adjusting the project file. That is the kind of friction that a project with a 2023 tag and no recent commits leaves behind, and it is the main thing to check before you commit to building from source.

The macOS instructions have the same shape with Homebrew instead of apt, and they add a note that you need to tweak the settings for the GUI to connect to the device on macOS, specifically setting the client path to the location of the pm3 console client.

Windows binaries and the bundled client question

Windows is the path of least resistance, because the releases page carries pre-built binaries and the project bundles a client for people who do not want to build one.

There are two archive shapes. The Vx.x.x-win64.7z contains only the GUI, and the Vx.x.x-win64-xxxxxxx.7z contains the GUI and the corresponding client, which you run by opening Vx.x.x-win64-xxxxxxx\GUI\Proxmark3GUI.exe. The same downloads are mirrored on SourceForge.

The bundled client comes from a third party. The README explains that a developer named Gator96100 creates ProxSpace, which makes it possible to compile both the firmware and the client on Windows, and also produces the pre-compiled Windows client published at proxmarkbuilds.org. The author included that compiled client in the releases so you can use the GUI on the fly, while also supporting your own preferred client. So the choice is between convenience and control. The GUI-only archive expects you to point the application at a client you built or downloaded yourself, and the bundled archive gives you a working combination immediately.

That is a meaningful distinction for anyone evaluating this, because the client is where the protocol work happens, and the README's own advice is to prefer the Iceman fork over the original repository. Using a bundled client means using someone else's build of a tool that talks to radio hardware, and the version pairing between the GUI and the client becomes something you inherit rather than choose.

The newest tagged release listed is V0.2.8 from 2023-06-27, with V0.2.7 from February 2023 and V0.2.6 from November 2022, and the last push to master was on 2026-04-06. So there is work on the branch that has not been cut into a release, and the release artefacts are considerably older than the source.

The Mifare editing tutorial that needs no hardware

The tutorial section is the part of the repository with the most unusual and useful entry. There are three tutorials, a quickstart, one on working with ProxSpace, and one on editing Mifare Classic data, and the third carries a parenthetical note that Proxmark3 hardware is not necessary.

That is a real design point rather than a marketing claim. Reading and writing blocks, editing block data in the editor, and analysing access bits are all operations on a file representing a card's contents, so they can be done against a .bin, .dump or .eml file without any radio hardware in the loop. That makes the GUI usable for learning the Mifare Classic format and for examining dumps, which is where a lot of RFID research actually starts, before you touch a physical card.

The file format support listed in the features, binary .bin and .dump files and text .eml files, is what makes this work. The .eml text format in particular is the common interchange format for card dumps, and being able to open one, edit a block, and save it back is the workflow that makes the GUI more than a wrapper.

The access bit analysis is the other feature that deserves attention. On a Mifare Classic card, the access bits in the sector trailer define who can read and write which blocks, and they are stored in a deliberately obfuscated way. A GUI that lays them out and analyses them saves the reader from doing the bit manipulation by hand, and the Chinese Magic Card support covers the proprietary clone cards that a reader will encounter in practice.

Where Proxmark3GUI is the wrong tool

Three cases argue against it. The first is a beginner without a Proxmark3. Every radio feature needs the device, and the client, not the GUI, is what speaks to the hardware, so without a Proxmark3 the only thing this gives you is the file editing and analysis side, which a text editor and a separate tool can do.

The second case is a project on a current toolchain. The Linux and macOS instructions install Qt5 and run qmake, and qt5-default no longer ships in the form those lines assume, so building from source today means adapting the project to a newer Qt. That is doable, since the source is a conventional Qt project, but it is work the project is not doing for you, and the last tagged release is from 2023 while the last push was on 2026-04-06.

The third case is a workflow that should not be graphical. The GUI supports raw commands of the Proxmark3 client, which means the client can do anything it can do, and for scripting, for batch work, or for anything that needs to be reproduced, the command line client is the better instrument. The GUI is at its best for interactive exploration of a single card, where seeing the sectors laid out and toggling the access bits is faster than typing.

There is a fourth practical point that follows from the licensing. The project is LGPL-2.1, which is a reasonable choice for a tool that links against Qt and can be redistributed, and the README carries the standard invitation to contribute. The licences of the components you bundle alongside it, the client, the firmware, the ProxSpace build, are separate decisions, and the repository does not attempt to speak for them.

On the maturity side, the version numbering, V0.2.8 as the newest tag with a 0.x series, says the same thing the release dates say. This is a working tool that has been in use for years, built against a Qt generation that is now behind the current one.

Editorial conclusion

Proxmark3GUI suits a researcher who has a Proxmark3 and wants a windowed way to exercise Mifare Classic cards, read and write blocks, and see the access bits laid out, and who is comfortable with the command line client underneath. It does not suit a beginner with no Proxmark3 hardware, since the radio features need the device, and it does not suit someone who wants a maintained toolchain, because the Linux and macOS instructions still install Qt5 through qmake. Before you build it, read the quickstart tutorial and the Mifare editing tutorial, and note that the last push was on 2026-04-06 with the newest tagged release V0.2.8 from 2023-06-27.

Frequently asked questions

Official sources

1. Issues
2. License: LGPL-2.1
3. README
4. Releases
5. wh201906/Proxmark3GUI on GitHub