RFID Hacking in the Field – A Comparison of the Proxmark3 RDV4 and the ProxmarkPro – Part 3 of 3

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.

ProxPro

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.

Figure 2 - A comparison of the ProxPro's command dump and the current Proxmark3 Wiki

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.

RDV4

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.

Figure 3.1 - Proxmark3 RDV4 HF Help File

Figure 3.2 - Proxmark3 RDV4 HF Hardnested Help File

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.

Analysis

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.

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.

ProxPro

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.

RDV4

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.

Analysis

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.

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.

Figure 4 - Proxmark3 Firmware Branch Overview

ProxPro

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.

RDV4

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.

Analysis

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.