In our final installment of this three-part analysis comparing the Proxmark3 RDV4 by RFID Research Group and the ProxmarkPro by Rysc Corp, we will be evaluating the capabilities of each tool in an RFID lab setting. Using the client software, we will examine the full scope of functionality offered by each of the two devices with respect to the current state of RFID security research as well as future developments in this rapidly growing field. Although this investigation is not quite as exciting as head-to-head attack trials, the careful dissection of the RDV4 and the ProxPro’s client environment and firmware provides significant insight into the value of each of these tools beyond merely reading and replaying target cards in the field.
Considering that these two devices are essentially vying for the title of Best RFID Field Tool for Redteamers and Penetration Testers, it may seem counter-intuitive to examine lab capabilities as a part of this comparison. The fact of the matter is that RFID hacking in the field is rarely as easy as reading a target card, copying the key code, and then replaying that key code to a reader. And as fun as it is to speedrun through the RFID equivilant of a lockpicking rook, the landscape of RFID security systems in the wild varies significantly from engagement to engagement, demanding a nuanced understanding of implementation and the ability to identify the vulnerabilities and exploitation techniques specific to that implementation. As such, a professional redteamer or pentester will be required to conduct some level of research into the target RFID system for each engagement, and may even necessitate significant field reconnaissance before a successful attack plan can be developed.
Attempting to bypass any given RFID access system in the wild using only the identify, read, and emulation functions demonstrated in the previous article in this series is analogous to a locksmith showing up to a call armed only with a few rake keys – there is small chance that this might do the job, but in most circumstances this specific tool will be useless. From this perspective, it is vital for the redteamer or pentester to have comprehensive knowledge of a target system and the knowledge of their Proxmark’s capabilities and how to leverage them to achieve a successful outcome in any engagement. Accordingly, our comparative analysis of each device would be entirely incomplete without taking a peek under the hood to see how they work and how the differences between the two contribute to their respective performance in the field.
Our assessment of the ProxPro and the RVD4’s individual lab utility will center around four key aspects of the underlying firmware: integration, integrity, functionality, and development. The comparative ease of integrating the device and the client software into a workstation can make a substantial difference in accessibility for each user. Likewise, the scope of capabilities between the two devices with respect to the full catalog of stable functions available in the master branch of the firmware will be important to consider before choosing the right Proxmark3 variant for your professional needs. Client functionality also differs to varying degrees between the ProxPro and the RDV4, requiring some awareness of the differences among the various forks used in the RFID research community, especially when it comes to command structure and workflow. Finally we will explore the development history of each device for indicators of the future of these tools in the field as RFID research progresses. Let’s get to the lab and take a deeper look at what makes the ProxmarkPro and the Proxmark3 RDV4 tick.
Disclaimer/Conflict of Interest
It should be noted that the we, the conductors of this research and writers of this article, are affiliated with RFID Research Group (RRG) as exclusive distributors of the Proxmark3 RDV4 in North America and that Rysc Corp is a direct competitor in the info sec device retail market. That said, the aim of this article is to provide an objective analysis of the above mentioned devices’ capabilities based on accurate measurement, thoughtful consideration, and above all, an honest representation of the facts and data collected herein. It is our hope that the information presented in this article will help those in our community interested in RFID technology make a more informed choice when purchasing their Proxmark3, no matter what device they choose or who they purchase that device from.
Although often taken for granted by most users, the installation of software into a computing environment is no trivial matter. And while most of us are familiar with the install wizards common in modern operating systems and commercial software development, the manual installation process of software via directory management and command line input is still prevalent in open-source research projects such as the proxmark3. As such, the installation process and device compatibility of the PM3 client software and firmware management within your lab workstation is an important consideration when getting started.
While Unchained Mode is designed to be the primary way a user interacts with the device, Rysc Corp does provide the client/firmware in both pre-compiled and un-compiled states for those who wish to use the terminal client to issue commands to the ProxPro. The client software can be used with Linux, Windows, and MacOS and RC does provide adequate documentation on how to setup and run the client in each OS. In all cases, the process of installing and accessing the client can be distilled to a simple, three-step process: 1) Install the appropriate drivers/dependencies for your operating system; 2) Downlaod the pre-compiled code from the RC website and place it in the relevant directory for your workstation; 3) Open a terminal, navigate to the appropriate directory, and run the client.
Figure 1A - Installing ProxPro client dependencies in Linux.
Figure 1B - ProxPro client directory in Linux
Figure 1C - Running the ProxPro client in Linux.
The whole installation process is relatively quick and straightforward depending on your level of experience using a command terminal. Once connected to the device, the firmware will allow you to access a much wider range of capabilities available to the user when using the ProxPro in Unchained Mode, albeit without the easy push-button user interface. Although a few different versions of graphical user interfaces for the Proxmark3 have been developed over the course of its history, there are no GUIs readily compatible with ProxPro and the user will be required to educate themselves in how to use the client via manually inputting commands and specifying the relevant variables before the device can be used effectively in this manner.
The pre-compiled version of the client also contains the firmware for the device, granting the user the ability to manually flash the firmware to the device from your workstation. This is not required to use the device, as the ProxPro comes with the latest version of its firmware directly from the manufacturer, but is useful if the device itself is ever corrupted as it will allow you to restore the default state. Although explicitly discouraged from doing so by RC, advanced users of the Proxmark3 with experience in writing and compiling their own custom firmware forks can do so with the ProxPro to some extent.
The client software and firmware driving the ProxmarkPro was developed by RC exclusively for use with this device and as a result, is not compatible with any other fork of the Proxmark3 branches currently available. Due to the modifications made to the hardware design and the accompanying Unchained Mode interface, PMPro v.1.2 represents a somewhat isolated environment with respect to the incorporation of custom functionality into the firmware and client. This lack of cross-compatibility is unlikely to represent a significant problem for novice users as they acclimate to the Proxmark3 environment, but is likely to frustrate advanced users seeking to utilize alternate or advanced builds of the firmware more appropriate for a given engagement.
As seen in every aspect of its design, the ProxmarkPro makes it very easy to access the client software without extensive knowledge of command line computing. Actually using the client can be somewhat of a steep learning curve, but completely doable as long as the user has the patience to read the help files, documentation, and discussion in the Proxmark forums. In this sense, the ProxPro does continue its trend in providing a lower bar to accessibility for new comers to RFID research.
Although the Proxmark3 RDV4 by RRG does include a standalone mode accessible to the user via the button and status LEDs on the device itself without need for an external power source or connection to the client terminal, the primary use case of this device in the field is via BLE connection to the RFID Tools App, where you can discretely run a full version of the client terminal from your mobile device. As of version 1.3.5, the RFID Tools App from RRG allows the user to update the RDV4’s firmware via USB connection to your Android device, making it the only Proxmark3 currently on the market that gives the user full client functionality without any initial setup on a Linux, Windows, or Mac workstation. The workflow is as simple as: 1) Download the RFID Tools App and plug the RDV4 into your Android device via USB; 2) Open the PM3 Firmware Flashing tool and press the flash button.
Video 1 – Flashing the PM3 RDV4 firmware in RFID Tools Android App
As easy as it is to get up and running with RFID Tools App, setting up the client and flashing the firmware in other workstation environments will require more experience in computing, as you will need to manually compile and install the client software to the target workstation. This process can vary widely across the user’s operating environment, but the client is compatible with a wider array of environments than the ProxPro, supporting conventional platforms like Linux, Windows, and MacOS as well as Termux for Android and Rasbian for the Raspberry Pi and Pi Zero. This flexibility is not necessarily going to add any value to the field utility of the device on its own, but does provide significant room for the development of highly customized and layered deployment techniques. A detailed tutorial for client setup in Linux can be found in our Proxmark3 Knowledgebase and the proxmark community is a great resource for troubleshooting any problems encountered during the setup process.
The firmware used by the RDV4 is developed and maintained by RRG, and is available via GitHub in their repository in addition to direct installation thru the Android App. While this fork is a requirement for accessing the BLE module and the RFID Tools App client terminal, the Proxmark3 RDV4 is largely compatible with the master branch of firmware from v3.0.1 forward. As such, the device will more easily accommodate customization of the device using many of the alternative forks or custom tools developed for the Proxmark3 currently in distribution. This makes the RDV4 well-suited for advanced users and novices alike, allowing the tool to serve its user throughout their journey into the depths of RFID hacking.
Although the ProxmarkPro is usable in Unchained Mode right out of the box, getting the client running on your workstation will require some manual computing skill and/or careful attention to direction. On the other hand, the Proxmark3 RDV4 can be automatically upgraded and connected to the client via the RFID Tools App at the push of the button and will allow the user to get started right away with no prior experience in command line computing. In this sense, the RDV4 is the clear leader in raw accessibility and ease of setup when used with the Android App.
In addition to initial setup, the RFID Tools app will keep your device and client firmware up-to-date as the latest stable versions of RRG’s fork are released. This is a nice touch to ensure a hassle-free experience for the average user, but it should be noted that you will need to manually update any client installations you have on your desktop workstation to ensure compatibility between the device and your different client environments. Updates to the RRG fork are frequent, so tracking these changes will be a mandatory part of using and maintaining this tool.
The ProxPro is unlikely to require any firmware updates as development of this project is geared towards the hardware and Unchained Mode UI unique to the device. PMPro v1.1 was released specifically for the first ProxmarkPro produced back in 2016 and the v1.2 update was made as necessary for the newest variation of the device produced in late 2019. Baring any modular accessories that add hardware to the device, there really isn’t anything to update until the next iteration of the ProxmarkPro. While this can be seen as a point towards ease of use, as we will see in later layers of this examination, this fact has substantial implications towards the overall limited lab utility of the client software for this device.
It is also worth noting that integrating both the ProxmarkPro and the RDV4 client software simultaneously into the same Linux or Mac environment will prove difficult. Because the two versions use similar but not identical dependencies, installing the client software for one will overwrite libraries for the other, rendering that version of the client inaccessible. This is also true for ProxmarkPro and the master branch of the Proxmark3, so if you are currently using a different variation of the device in your lab set up, you will want to consider installing the client to a VM or alternate instance of your workstation OS if you want to add the ProxPro to your toolkit.Back To Client Installation
The landscape of RFID security research is incredibly dynamic and the proxmark development community is constantly evolving with every new protocol and security standard introduced to the ecosystem of this increasingly ubiquitous technology. While both the ProxPro and RDV4 represent unique developmental directions within the proxmark project at large, how does each fork compare against the current front-line of RFID security research and hacking capabilities.
To explore the full extent of the capabilities of the client software for this device we can refer to the link provided by RC on the ProxPro product page, which directs to a page in the Proxmark3 wiki on GitHub. This page contains a fairly good summary of the functions available in each of the functional modes of the device; data, hardware, high frequency, and low frequency. It should be noted that this command dump is actually an archive of the Proxmark3 master branch from several years back. When comparing this page to the current Proxmark3 wiki, we can see that the PMPro v1.2 firmware utilizes several deprecated commands and does not include capabilities for a majority of the protocols in both HF and LF ranges.
To verify that the ProxPro is actually using these deprecated commands and missing these capabilities, we can refer to the help files accessible directly through the client software itself. Most of the command options can be explored in the Proxmark3 client by tacking “help” or “h” on to the end of a command. Merely sending this without a command will return a menu of command modes such as “data” or “hf” with each of these entries containing their own sub menu of protocols or commands accessible by tacking an “h” or “help” after the command string. For example, you can view all of the protocols supported in the low frequency range by executing “lf h”.
The help files available to the ProxPro client indicate the firmware is indeed missing many of the currently supported protocols, as well as still using commands that were deprecated and replaced roughly 7 years ago. Most of these commands are related to demodulating signals of a particular protocol type, which in v3.0+ of the master Proxmark3 branch has been moved into the command structure for those protocols. For example, “fskpyramiddemod” has been relegated to the pyramid lf protocol set of functions, which other than this specific demod command, is unsupported by the ProxPro’s firmware.
By crawling through the client’s help files, we were able to develop the list of command capabilities seen in the chart above. When comparing this range of functionality to the Unchained Mode menu (see part 1 of this series), it becomes obvious that only a few dozen of these commands are utilized in the intended usage of the device. This begs the question of why so many capabilities were left out of the UI for Unchained Mode? When considering the fact that this feature is designed to simplify execution of a sequence of commands using only a few button pushes, it is reasonable to assume that both extremely technical workflows as well as use cases not essential for field use were ignored to streamline development and maximize utility for an inexperienced user. If there were any room for development in the ProxPro’s firmware it would be integrating more of the client functionality into the Unchained Mode UI.
Applying the same analytical model to the client software of the RDV4, we can build out a similar picture of its capabilities for comparison to the master branch. Like the ProPro, the firmware for the RDV4 is developed by the manufacturer to leverage some hardware functionality unique to this model of the device. Let’s see how it stacks up to the current state of development in the proxmark project.
As seen in the figures above, the help files of the client software are quite detailed and often go all the way down to the parameter level and providing examples of implementation. This provides a substantial benefit to new users as it will make consulting the wiki or proxmark forums less frequent a prevent a lot of the general confusion faced by most newcomers to the device. The command structure is consistent with that of the master fork, with no deprecated or missing functions.
Although not lacking in any capabilities found in the master branch of the firmware, the RDV4 does feature a few hardware upgrades not supported by the master branch, primarily the Bluetooth connectivity and SIM/SAM adapter. These additional features are built on top of the current master branch, with many patches and updates to the core capabilities moving back and forth between RRG and the proxmark development community at large. This development flow has kept the RDV4 current and relevant since it’s introduction in 2017, with its regular updates reflecting the bleeding edge in proxmark development.
Other than the minor layout and style differences between the RFID Tools App client terminal and that of a Linux workstation, the user experience is virtually identical. Minor aggravations include the slow speed and lack of accuracy in touch screen typing, as well as other workflow-related issues dealing with the constraints of this input type. Using a bluetooth keyboard and mouse provides substantial relief to a majority of these issues, although this might be a little less preferred for live engagements depending on the scenario. Another nuance to using the client via the Android App and a PC workstation is in file management, which will require you to have some means of file directory access to integrate data from another workstation. The file structure in the App reflects implementation in a Linux environment.
With respect to providing an accurate and complete representation of the best practices and latest development in RFID security research, the Proxmark3 RDV4 definitely excels over its competition in regards to sheer volume of standard features available in the master fork as well as its compatibility with any up-to-date custom forks, scripts, and standalone mode variations. In addition to maintaining compatibility with the master branch, the additional feature set afforded by the RDV4 hardware and accompanying firmware makes it the only commercially available proxmark3 variant capable of smart card and sim card hacking or wireless connection to a host client. In many ways, the RDV4 is one of the driving forces behind modern proxmark development and perhaps even RFID security research in general.
The ProxmarkPro by comparison is relatively isolated from the main branch of firmware/client development. As indicated by the outdated and deprecated feature set, the PMPro fork separated from the primary branch of development long ago and has not incorporated any substantial changes or additions to the capabilities of the device beyond what was required to develop the Unchained Mode functionality. Without substantial overhauls to the source code, the PMPro firmware fork is unlikely to incorporate any of the project developments made since version 2.2.0 (circa mid 2015).
Because of their relative distance from each other in the proxmark family tree, it is difficult to make a direct comparison of capabilities between the ProxPro and the RDV4. On one hand, the simplicity of the Unchained Mode UI makes the most basic utility of the proxmark accessible outside of the client environment, and on the other, the RDV4 gives you access to a bleeding-edge client discretely in the field via an Android App. Both offer a short cut to leveraging the capabilities of the Proxmark3, but in a manner that appeals to entirely different deployment scenarios. This is where the extreme difference in field capabilities seen in part 2 of this series emerge – what the ProxPro can do, it does very quickly and effectively. This quality comes at the expense of range of utility, which the RDV4 delivers in full whether used in the field or the lab.
As such, the ProxmarkPro simply cannot compete with the RDV4, or any other version of the proxmark running v 2.3.0 or better for that matter. It is simply not designed to be used in a lab setting, especially when it comes to any kind of RFID research. In contrast, the PM3 RDV4 bridges the gap between lab and field by granting the user remote access to the entire range of the device’s capability from a discreet Android device – indeed nearly every capability known to the proxmark development community is available via the RDV4.Back To Client Integrity
It is beyond the scope of this research project to meticulously test the functionality of each and every command offered by both devices. This would be a technical nightmare and practically impossible for a single researcher to accomplish in any reasonable amount of time. That said, we racked up over 40 hours in each client environment over the course of this investigation, and more than few notable differences in functionality cropped up that are significant to the end user. While both devices function as intended, the discrepancies in command syntax and the client output between the same commands can have significant impacts on over all workflow and troubleshooting when using each device.
As we already identified in the previous section of analysis, the ProxPro client features several deprecated commands, but beyond this, there are many instances of antiquated syntax throughout the basic feature set of the device. In 2017, the primary branch of the proxmark3 firmware received a major overhaul as new features and improvements were integrated from other popular forks. In this upgrade, naming conventions for various commands were standardized and optimized to accommodate all of the new standard functionality. The PMPro firmware fork reflects the old syntax and command names from version 2 of the master branch, which will require some adjustment for users more experienced in modern versions of the client.
One such instance came up while using the client to read, write, and emulate the same cards used in the field utility trials conducted in part 2 of this series. Both of the LF cards used in that trial are EM 410X tags. Using the modern version of the client, the command needed to perform a read on this type of RFID tag would look like this: lf em 410xread – with the first and second values, lf and em, indicating low frequency range and EM4X protocol. The third value points to the operation being called, 410xread, which is used to read card data in the 410x format. After attempting this command several times with no success, I noticed that this input was triggering the help file for lf, cluing me into the fact that I was doing something wrong. Referring to both the command dump linked on the ProxPro product page and the help file in the client, I found that the correct command input on this device is: lf em4x em410xread.
Proceeding with the correct command, another attempt at reading the tag was made – no output is returned by the client, only a fresh prompt and a blinking cursor. Upon double checking my syntax and spelling, I sent the command again and the same null output was returned. Curious as to whether the ProxPro succeeded in reading the tag, I used the command “lf em4x em410xsim” followed by the UID of the tag to see if the data had been read. The client output indicated that the read was a success and that the device was currently simulating that tag’s UID. Fortunately, I already had access to this value from previous card reads, otherwise I would have had to add a few other steps to this procedure to retrieve the UID value from the GraphBuffer before performing the simulation command. Although em410xread is analogous to 410xread in the modern client, the two operations behave differently and this fact will need to be accommodated on the user end.
In the modern version of the client, the workflow of this procedure would include copying the UID from the client output after issuing the read command. This output would contain confirmation of a successful read, the tag UID, as well as additional information about the memory blocks, notes on vulnerabilities, and other details. This is really more a reflection of how difficult it used to be to use the proxmark3 before the version 3 overhaul, but the fact that the ProxPro continues to use this older version of the client as its foundation will lead to many irregularities in implementation between those using the PMPro v1.2 client and those using the master branch client.
While these small differences in functionality may be a minor irritation to more experienced proxmark3 users, for those just beginning in RFID technology and command line computing may find this a significant obstacle to getting started with the device. A majority of the information available in official documentation or archived forum discussions will reflect the standard implementation, with some degree of translation being required to apply the same command in ProxPro client, not just from the perspective of syntax and naming conventions, but in adjustments to the workflow as well (as noted in the case of em410xread). Between the lack of congruence with a majority of the documentation and the relatively sparse help files, inexperienced users will arguably have a steeper learning curve in the client software when using the ProxmarkPro.
The RRG fork, though more consistent with the master branch than the ProxPro, also contains a few non-standard labels. As discussed above, the standard command for reading an EM4x tag is “lf em 410xread” but in RRG’s client, the command 410xread is modified to 410x_read with an underscore separating the card format and the operation. This change is presumably meant to better represent the meaning behind the name, as this convention is used repeatedly throughout the client, resulting in too many instances to list here. The impact of this difference in nomenclature, though similarly inconveinent for users accustomed to the standard client, is at least restricted to separation of format and operation labels within the command name and is self-consistent within the RDV4 ecosystem.
To their credit, RRG has edited the help files to reflect their naming conventions, which will aid substantially in figuring out what commands have been modified in the case that user is unaware of the general rule behind this change. Likewise, many references in the proxmark forums include code snippets using these command variants interchangeably, indicating general awareness of this nuance between the RDV4 and the standard PM3 among the user base. Considering that the actual behavior of the commands are identical in function between client environments, this name change does not have impact on the workflow for a given technique. This means that any skills acquired in the master branch client using generic PM3 hardware will be completely transferable to the RDV4.
In contrast to the PMPro v1.2 help files, those found in the master branch and the RRG fork alike are extremely well-developed. These files in most cases drill all the way down to the parameter level, providing examples of implementation and even workflow suggestions in some cases. These files are considered a sort of required reading among the RFID community, as a majority of user problems on the proxmark forums are vetted against this information before explicit help is provided by more experienced users. In any case, the additional capabilities afforded by the additional hardware found in the RDV4 will require some investigation of the help files and the forums, as there is currently no complete command reference for these additional features currently available.
The client functionality for the Proxmark3 RDV4, whether run on Linux or via the Android App presents no unique challenges or advantages over that of the master branch. While the Android App interface does include some handy features, such as the easy-button option for sending commands to the client or the automated firmware flashing, the user will be required to spend several hours experimenting in the client and consulting documentation before any level of capability can be achieved with the tool.
While proficient use of the client software for both the ProxPro and the RDV4 will take substantial research and practice on the part of new users, the outdated command structure of the PMPro firmware fork creates an additional layer of difficulty in finding appropriate documentation for many of the commands and workflows. The inexperienced user will likely find themselves in many head-scratching moments similar to the one we encountered in trying to perform a the EM410X read seen earlier in this section due to the inconsistencies with the master branch. In contrast with the easy and intuitive design of the Unchained Mode UI, using the ProxmarkPro via the client software is better suited for more experienced proxmark users, especially those that have used the device since version 2 of the firmware.
The substantial deviation in hardware design of the ProxPro essentially renders the device incompatible with any other development in proxmark research, which will only serve to further isolate this variant from the rest of the RFID community as time progresses. Thus only the most elite users will have the ability to take advantage of the full scope of functionality actually offered up by the ProxPro. The lack of modern functionality however makes the actual utility of the device for an advanced user almost non-existent, as there is no advantage to using the ProxPro over any other PM3 variant on the market.
In short, the PromarkPro simply does not provide sufficient capabilities for the device to serve a purpose in RFID lab settings – the feature set and command structure are too outdated for modern security implementations and vulnerability exploitation. The exclusive focus on developing the Unchained Mode at the expense of updating the client is the primary limiting factor of the ProxPro’s utility beyond absolute new-comers to RFID security.Back To Client Functionality
Since the Proxmark3’s official inception in early 2014, there have been more than 2000 commits by over 60 differentcontributors to open-source project’s GitHub repository. Of course, the proxmark project has its roots much deeper than GitHub would suggest, with the proxmark community forum going live in mid 2008, shortly after Jonathan Westhues built the very first iteration of the device. In the very beginning, development was restricted to those with the means of fabricating their own boards or able to get one from a friend that contracted a small run of professionally manufactured boards. As the project gained notoriety through a handful of technical talks in the 2014 and 2015 convention seasons, a few different companies rapidly commercializing the project by manufacturing and retailing their own variants of the proxmark3. Rysc Corp was one of these companies, as was Elechouse, who’s Proxmark3 RDV2 would end up becoming the industry standard device from 2016 to 2018.
Over this period of time, thousands of new devices were brought to market and research boomed as the proxmark3 development community grew. A half dozen or so of the leading researchers we making multiple commits a week at this point, rapidly incrementing the firmware with patches, improvements, and new features consolidated from the community. One of the primary developers in this pack, known as iceman1001, had established his own experimental fork, from which many of the commits to the master branch were originated until the “monster merger” that spawned v3.01 of the project in late 2017, when the master branch was brought entirely up-to-date with the iceman fork and the work of several other major contributors such as marshmellow2, pwpiwi, merlokk, and holiman.
Just as Elechouse developed their own, more compact and field-capable variant of the original proxmark back in late 2015, RC began work on what would become the first version of the ProxmarkPro. This is where the PMPro firmware forks from the master branch of development, somewhere around version 2.2.0, with most of the work dedicated to building out the Unchained Mode functionality seen in both this version, and the 2019 version of the ProxPro. Although demand for this initial effort was over-shadowed by the popularity of the RDV2, and the various copycat models that soon hit the market, RC kept the ProxmarkPro project alive, eventually producing a full manufacture run of an improved version of the device in 2019 with the PMPro v1.2 firmware upgrade.
Although this researcher does not have a version of the PMPro v1.1 to compare the feature set/improvement in capabilities over the 2016 version, the current command schema utilized by v1.2 is consistent with the master branch of the project circa late 2015. This indicates that there were no substantial improvements to the firmware outside of those associated with the improvements/changes made to the hardware associated with the Unchained Mode functionality. The ProxmarkPro Kickstarter page from 2015 refers to the open-source nature of the project, pointing back to the master branch on GitHub. It is possible that the original intent in the early stages of development was to provide and maintain a repository for the PMPro fork, but the source code has never been released in this manner – although you are able to download the uncompiled source code directly from RC.
Due to the relative isolation of the ProxPro’s firmware from the RFID research community, there has been no exchange between PMPro and the master branch to encourage development or experimentation. This has done little to encourage adoption of this fork and the corresponding hardware over time. The consequential “genetic drift” between it and the proxmark3 project at large has rendered it, in essence, a separate species of tool that is no longer capable of sharing code with the rest of the devices in the wild. This analogy is perhaps a bit hyperbolic from a technical perspective, but it is doubtful that anyone in the community would elect to undertake the challenge of bringing the PMPro fork up-to-date and fully compatible with anything above version 3.0 in the master branch.
As the PMPro firmware is only compatible with the ProxmarkPro, not in active development by the proxmark community, and largely focused on the device-exclusive Unchained Mode feature, the line between proprietary and open-source becomes hazy. Although RC certainly makes every effort to meet the minimum expectations of their open-source claim, the device’s firmware certainly doesn’t receive any of the benefits typically associated with this type of software development, nor has it made any meaningful contributions to the master branch to move the project at large further forward. In this way, the design perspective of the ProxPro places an emphasis on accessibility to RFID newcomers to the exclusion of adoption by the current community of researchers.
Taken as a whole, the development history of the ProxPro has many negative consequences on the life-time value of the device. Due to its limited capabilities set, the device is effectively 6 years behind the RFID security industry and will provide very little utility towards any high-end engagements where security measures will include modern protocols of LF and HF developed after 2015 – the point at which PMPro deviated from the proxmark3 project. This also means that the ProxPro willl need to be replaced if at any point the user decides to advance their RFID capabilities as they become more experience in this field. Barring a substantial overhaul of the firmware by RC in the future, there is little chance of large scale adoption by the rest of the community, aside from a potential vector of initiation into RFID before graduating to a more appropriate tool for advanced usage.
The Proxmark3 RDV4 began development in late 2017, with RFID Research Group forking from the master branch shortly after the monster merger of version 3.1.0. Development of this fork was driven primarily by hardware innovations in the design of the Proxmark3, including but not limited to the miniaturization of the primary board, modular antennas, and an FPC interface for incorporating modular hardware additions such as the Blue Shark module used throughout this series of articles. RRG made their first manufacturing run just in time for DefCon 26 with the help of crowd-funding and quickly replaced the RDV2 as the preferred variant in the development community, as well as security professionals in the field.
As shown in Figure 4, the RRG fork merged with the infamous iceman fork early in development, with iceman1001 dedicating all subsequent efforts towards the RDV4, among other projects in RFID hacking, such as the recent Chameleon Mini Rev G and Chameleon Tiny. In addition to the celebrity status that iceman1001 brings to RRG, the other founding members, ProxGrind and 0XFFFF, are both significant contributors to the RFID research community via their engagement with the proxmark.org forums and technical presentations on RFID hacking over the past handful of years. In this sense, the approach to firmware development for the RDV4 is firmly embedded within the standard practices and overall zeitgeist of the community.
Beyond the RRG fork and the master branch sharing such a recent history in development and active collaboration with the developer largely responsible for the modern state of the proxmark3 project, the adoption of the RDV4 by a large portion of the contributing developers has resulted in frequent cross-integration of code between the master branch and the RRG fork. Improvements and added features from one fork are routinely committed to the other, with significant communication and coordination of research taking place in open forums, granting initiates access to the collective knowledge gathered and refined over more than a decade. This factor has contributed significantly to the device becoming somewhat synonymous with the Proxmark3, with several copycat designs cropping up on the market over the past couple of years. RRG even leverages this popularity in their redesign of the Chameleon Mini, which could easily be mistaken for a PM3 to the untrained eye. In short, with such a close connection between the proxmark3 research community and the developers behind RRG, continued updates, patches, and development of new features are all but ensured into the near future.
By embracing the open-source foundation of the project, RRG ensures that the RDV4 stays relevant in a rapidly changing landscape, with product development firmly aligned with the progress of the project at large. Indeed, iceman’s status as moderator of the proxmark community forums grants him significant insight into the future of the industry, having a high level of interface with nearly anyone trekking into new and uncharted territory, connecting the dots and nudging these developers along in their journey. It would be foolish for RRG to not take full advantage of this information in the growth of their business. This no doubt plays a huge role in the modularity of the hardware design, which accommodates for a wider range of potential hardware upgrades without rendering the underlying platform obsolete. This has the added benefit to the consumer in increasing the functional lifespan of the core product, and will no doubt encourage continued preference for the RDV4 among the most prolific project contributors.
Although the constant development and upgrading of the firmware in both master branch and RRG fork provides the user with many benefits, there is a potential for frustration for those uninitiated in open-source hardware projects and manually flashing firmware to a device (arguably annoying to those familiar with the practice as well). One feature provided to users of the RDV4 via the RFID Tools App is the ability to automatically manage firmware/client software via App updates. This level of accessibility is very useful for a wide variety of users in a wide variety of use cases, providing bleeding-edge capabilities to new users, and maintaining a framework for custom development to suite the needs of the team or engagement scenario.
The most significant mark against either device in this exploration of product development is the ProxmarkPro’s lack of compatibility with the rest of the RFID research community with respect to both the underlying firmware and general utility in the lab. Phylogenetically speaking, the ProxPro is a sort of living fossil and not apart of the gene-pool shared by other modern variants of the PM3. This significantly impacts the viability of the device as a field tool going forward, as its lack of support for modern system protocols and secured implementations of older protocols make it less and less effective as the industry advances. The lack of overlap with modern proxmark development standards and practices also limit the viability of the device as the knowledge base of the user grows. Any professional that dives deeper than the most basic aspects of reading, cloning, and emulating RFID tags will find themselves rapidly outgrowing the capabilities of the PMPro firmware.
In the face of such a substantial gap in development between the ProxPro and the current meta of the proxmark3 community, it is unlikely that any major updates will be made to the device’s firmware outside of Unchained Mode functionality with respect to the full client capabilities. This is the one area where RC could provide substantial value to its user’s over time: further expansion of the Unchained Mode functionality. Although the firmware is almost 7 years behind that of the RDV4, it is far more capable than the Unchained Mode’s limited functionality would suggest – giving the user expanded capabilities within the very intuitive UI provided by the device opens up to a wider array of engagement scenarios without the steep learning curve associated with the client software. That said, there is no hint of the improvements in works from either RC or its users.
Just as the RDV2 by Elechouse dominated the commercial and developmental landscape in the early stages of the project’s life, the RDV4 is poised to lead the industry during this massive growth phase in RFID research as tens of thousands of new proxmark3s make their way into the field and lab every year. The ultra-compact form-factor provided by the hardware design combined with the leading minds in RFID guiding software development serves as valuable source of confidence that the device will return a substantial long-term value to its user in both utility and forward compatibility. In short, the developmental approach to the RDV4 provides the user with the ability to leverage advancements in RFID security research and development in real time, integrating the frequent updates developed by RRG in conjunction and collaboration with the efforts of the research community at large. The ProxPro on the other hand has remained almost unchanged since its inception in 2015 and not likely to ever catch up with the current state of development within the larger Proxmark community.Back To Development
The research conducted over the course of this article series has illustrated more than anything else that the Proxmark Pro and the RDV4 are like apples and oranges – though both ostensibly standalone variants of the PM3, the two devices are essentially incomparable. While the ProxPro essentially replaces the client software with a simplified UI maximize accessibility and simplicity, the RDV4 replaces your computer and USB cable with BLE and an android device to maximize portability. Although both make for a more field-capable device, only the RDV4 provides the user with full range of capabilities represented in the current proxmark/RFID research meta.
The ProxmarkPro definitely performed faster in time trials, captured card data at competitive distances, and worked perfectly right out of the box with zero setup to use the proprietary Unchained Mode functions. While these metrics do hold some practical significance, the limited support for modern tag protocols and encryption poses a significant limitation to the viability of the tool in professional engagements. In many ways the ProxPro is a single function tool – it excels in the handful of tasks it was designed for, but provides almost no utility outside of these specific tasks. And as our deep dive into the firmware shows, these limitations are essentially baked into the device.
The ProxmarkPro is optimized for a very specific target user with a very limited use case for the PM3 in the field. This user can be defined as security professionals and enthusiasts who need access to RFID tag reading, cloning, and emulating for unencrypted HID, EM4100, and MiFare Ultralight protocols without any prior experience or training in RFID technology. The comparatively high price point for this device with respect to its comparatively narrow range of features implies that this user will pay a premium for push-button copying of vulnerable key cards without any foundational knowledge of the technology and the more sophisticated attack techniques offered by dedicated research and practice. This significantly narrows the range of optimal users to absolute beginners in security research/redteam engagements with limited technical ability and no long-term ambitions towards growth in RFID research or professional growth.
One unfortunate consequence of the 4 year development of the ProxmarkPro is the intrusion of new, lower cost devices into the market ranging from incredibly cheap PromarkEasy and RDV2 knockoffs to entirely new product platforms. The recent introduction of the Chameleon Mini and the Keysy to information security device market in many ways poses a threat to the ProxPro’s niche appeal. Both devices offer push-button interfaces with little to no prior experience in RFID research to use. They also come out of the box ready to use without any firmware flashing or installation process. Between the two devices, a user can instantly read a target card within range and store tag IDs for later emulation. These devices can be purchased at less that 30% of the price of the ProxPro and cover a wider range of LF and HF protocols. The only field-oriented functions not supported by the Keysy/Chameleon Mini combo are HID Brute, and LF card writing. While it is easy to work around the lack of card writing capabilities, being able to brute force an HID reader will not be possible with this tool set. That said, even when using the ProxPro, this technique will require a significant level of research and practice to implement, something a majority of the user base will be at a disadvantage in completing.
Aside from the substantially lower entry price, the Chameleon Mini is a powerful RFID tool in its own right, with a substantial amount of overlap in HF functionality when compared to the PM3. The Android App interface of the device allows for newcomers to jump in with limited experience in RFID and no command line computing knowledge required. For a more detailed breakdown of the Chameleon Rev G Mini and Tiny variants, check out our toolkit analysis in the Chameleon Knowledge Base.
While the Proxmark3 RDV4 is also very much optimized for discreet and efficient use in the field, this device was designed by and for experienced RFID professionals and places little emphasis on making the device accessible to newcomers in this technology. This target user is capable of using the full range of functionality provided by the client software and requires a device that can deliver entire range in a field setting. While at a similar price point to the ProxPro, the RDV4 derives its value from hardware design improvements, firmware flexibility, cutting-edge functionality, and mobile app connectivity. Moreover, the constant firmware updates from RRG will keep your device current with the latest developments in the research community well into the expected future of the proxmark project. Dollar for dollar, the Proxmark3 RDV4 is probably the best investment a security researcher or red teamer could make in their RFID tool kit.