Point of Fail: Hacking a POS Device with WHIDBOARD

FROM THE CHECKOUT LINE TO A ROOT SHELL

Some time ago I was shopping around the city when I stumbled on an interesting POS (Point Of Sale). While the cashier was preparing the shopping bag I quickly took my phone and snapped a couple of photos for future reference…

Once home, I started taking a closer look at the labels underneath the POS and immediately realized one interesting thing… an FCC ID was clearly visible (i.e. SEKMA512)! 😎

Passive RECON – OSINT Time!

With that piece of information, I was able to quickly get more details about this new DUT (Device Under Test) even without owning one (yet).

Within the FCC database I was able to get more details about internal PCBs, how the device operates and if there are any anti-tampering features that will prevent hardware hacking attempts.

In particular, while reviewing its manual, I was able to confirm that indeed this POS (as any other similar device that handles credit cards data) has some countermeasures in place to prevent threat actors from physically tampering with the circuit board, as shown in the images above.

However, I did not give up and continued looking around the FCC Database documents to have a better understanding of the whole DUT and complete my initial threat model, looking for potential entry-points.

As you can see from the image above, the main PCB has a number of test points. Some of them captured my interest, especially because they appeared to be externally accessible without opening the POS enclosure - meaning they could be probed without triggering the anti-tamper mechanisms that would wipe the device's memory.

Now that I got some potential entry-points, was time to purchase some samples online…

Active RECON – Pins Enumeration with WHIDBOARD

Few days later, the DUT samples arrived, and the first step was probing the test points with a multimeter to identify which ones were electrically relevant. Having narrowed them down, I then used the Logic Analyzer feature embedded into WHIDBOARD to see if any data was being output by the POS.

After trying different pins, as you can see from the screenshot below, I eventually found the TX line of a UART debug interface. 😎

Now it's time to fire the Pin Enumerator feature of WHIDBOARD in order to find also the RX pin!

Leaving the DUT completing the booting process led to something truly unexpected…

Not only did this POS expose a fully functional UART interface outside its anti-tamper security boundary - indicating a failure in both threat modeling during R&D and security validation before production - but this debug interface dropped straight into a root shell. 💥🤯

Let's Get Our Hands Dirty – Interacting with the DUT as root

At this point, things escalated quickly. Using WHIDBOARD I had identified an exposed UART that led to full, UNAUTHENTICATED ROOT ACCESS…

What came next, was me exploring the device's file system, inspecting running processes, and understanding the DUT's internal architecture.

Eventually, I exfiltrated the entire firmware via a USB flash drive using the following commands…

And to prove the point that I was able to not only read the file system but also tamper it… I did make some changes… 😎

Active RECON – Network Scanning

At this point, out of curiosity, I also checked for open network services on the DUT's Ethernet interface. The results were alarming: Telnet Port 23/TCP was OPEN… 🤯💥

And yes… you could log into it (as root) WITHOUT password!

At this point I decided to check on Shodan if any of these POS were facing the internet. The result: at least 61 of them were exposed on the internet… 🙊🙉🙈

Conclusions

This DUT was quite a surprise - in over a decade of POS security research, I had never encountered a device with this many compounding failures. Let's break down what went wrong and why it matters.

Multiple layers of defense-in-depth failure. This device exhibited at least four distinct, independently exploitable vulnerabilities:

1. Externally accessible debug test points that bypass physical anti-tamper protections;
2. An active, unauthenticated UART console yielding root shell access;
3. Telnet on port 23/TCP with passwordless root login on the network interface;
4. At least 61 instances discoverable via Shodan, exposed directly to the internet.

Each one alone would be a critical finding. Together, they represent a systemic failure in the product's security lifecycle - from threat modeling and secure design, through implementation and pre-production testing.

Implications for payment infrastructure. A POS terminal with root-level read/write filesystem access - reachable both physically and over the network - opens the door to firmware backdooring, payment data interception, and persistent implant deployment. In environments where PCI DSS compliance is expected, this class of vulnerability is not a marginal gap: it undermines the entire trust model. The fact that these devices were internet-facing amplifies the risk from a local physical attack to a remotely scalable one.

The regulatory context: CRA and beyond. With the EU Cyber Resilience Act (CRA) entering its enforcement timeline, products with digital elements placed on the European market will be required to meet essential cybersecurity requirements throughout their lifecycle - including secure-by-default configuration, minimized attack surfaces, and vulnerability handling obligations. A device shipping with unauthenticated root access over both UART and Telnet would be a textbook non-compliance scenario. Manufacturers and importers should treat findings like these as a preview of what regulators will be looking for.

Key takeaways for practitioners. Never underestimate publicly available OSINT. The FCC database alone provided enough information to build a preliminary threat model, identify anti-tamper boundaries, and locate potential entry points - all before purchasing a single unit. For red teamers and security researchers, this is a reminder that passive reconnaissance on regulatory filings can dramatically accelerate hardware assessments. For manufacturers and blue teamers, it is a reminder that your FCC submissions, teardowns, and service manuals are part of your attack surface.