{"id":740,"date":"2026-04-13T12:04:34","date_gmt":"2026-04-13T10:04:34","guid":{"rendered":"https:\/\/www.hardwaresecurity.it\/?p=740"},"modified":"2026-04-13T12:07:25","modified_gmt":"2026-04-13T10:07:25","slug":"hacking-a-pos-with-whidboard","status":"publish","type":"post","link":"https:\/\/www.hardwaresecurity.it\/?p=740","title":{"rendered":"Hacking a POS with WHIDBOARD"},"content":{"rendered":"\n

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\u2026<\/p>\n\n\n\n

\"collage\"<\/figure>\n\n\n\n

Once home, I started taking a closer look at the labels underneath the POS and immediately realized one interesting thing\u2026 an FCC ID was clearly visible (i.e. SEKMA512<\/em>)! \ud83d\ude0e<\/p>\n\n\n\n

\"image\"<\/figure>\n\n\n\n

Passive RECON \u2013 OSINT Time!<\/strong><\/p>\n\n\n\n

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).<\/p>\n\n\n\n

\"image\"<\/figure>\n\n\n\n

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.<\/p>\n\n\n\n

\"image\"<\/figure>\n\n\n\n
\"image\"<\/figure>\n\n\n\n
\"image\"<\/figure>\n\n\n\n

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.<\/p>\n\n\n\n

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.<\/p>\n\n\n\n

\"image\"<\/figure>\n\n\n\n

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 \u2014 meaning they could be probed without triggering the anti-tamper mechanisms that would wipe the device\u2019s memory.<\/p>\n\n\n\n

\"image\"<\/figure>\n\n\n\n

Now that I got some potential entry-points, was time to purchase some samples online\u2026<\/p>\n\n\n\n

\"image\"<\/figure>\n\n\n\n

Active RECON \u2013 Pins Enumeration with WHIDBOARD<\/a><\/strong><\/p>\n\n\n\n

Few days later, the DUT sample arrived, and the first step was probing the test points with a multi-meter to identify which ones were electrically relevant. Having narrowed them down, I have then used the Logic Analyzer feature embedded into WHIDBOARD<\/a> to see if any data was being output by the POS.<\/p>\n\n\n\n

\"image\"<\/figure>\n\n\n\n

After trying different pins, as you can see from the screenshot below, I eventually found the TX line of a UART debug interface. \ud83d\ude0e<\/p>\n\n\n\n

\"image\"<\/figure>\n\n\n\n

Now it\u2019s time to fire the Pin Enumerator Feature of WHIDBOARD<\/a> in order to find also the RX pin!<\/p>\n\n\n\n

\"image\"<\/figure>\n\n\n\n
\"image\"<\/figure>\n\n\n\n
\"image\"<\/figure>\n\n\n\n

Leaving the DUT completing the booting process led to something truly unexpected<\/strong>\u2026<\/p>\n\n\n\n

\"image\"<\/figure>\n\n\n\n

Not only did this POS expose a fully functional UART interface outside its anti-tamper security boundary \u2014 indicating a failure in both threat modeling during R&D and security validation before production \u2014 but this debug interface dropped straight into a root shell. \ud83d\udca5\ud83e\udd2f<\/p>\n\n\n\n

Let\u2019s Get Our Hands Dirty \u2013 Interacting with the DUT as root<\/strong><\/p>\n\n\n\n

At this point, things escalated quickly. Using WHIDBOARD<\/a> I had identified an exposed UART that led to full, UNAUTHENTICATED ROOT ACCESS\u2026<\/p>\n\n\n\n

What came next, was me exploring the device\u2019s file system, inspecting running processes, and understanding the DUT\u2019s internal architecture.<\/p>\n\n\n\n

Eventually, I exfiltrated the entire firmware via a USB flash drive using the following commands\u2026<\/p>\n\n\n\n

\"image\"<\/figure>\n\n\n\n
\"image\"<\/figure>\n\n\n\n
\"image\"<\/figure>\n\n\n\n

And to prove the point that I was able to not only read the file system but also tamper it\u2026 I did make some changes\u2026 \ud83d\ude0e<\/p>\n\n\n\n

\"image\"<\/figure>\n\n\n\n

Active RECON \u2013 Network Scanning<\/strong><\/p>\n\n\n\n

At this point, out of curiosity, I also checked for open network services on the DUT\u2019s Ethernet interface. The results were alarming: Telnet Port 23\/TCP was OPEN\u2026 \ud83e\udd2f\ud83d\udca5<\/p>\n\n\n\n

\"image\"<\/figure>\n\n\n\n

And yes\u2026 you could log into it (as root) WITHOUT password!<\/p>\n\n\n\n

\"image\"<\/figure>\n\n\n\n

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\u2026 \ud83d\ude4a\ud83d\ude49\ud83d\ude48<\/strong><\/p>\n\n\n\n

Conclusions<\/strong><\/p>\n\n\n\n

This DUT was quite a surprise \u2014 in over a decade of POS security research, I had never encountered a device with this many compounding failures. Let\u2019s break down what went wrong and why it matters.<\/p>\n\n\n\n

    \n
  • Multiple layers of defense-in-depth failure<\/strong><\/li>\n<\/ul>\n\n\n\n

    This device exhibited at least four distinct, independently exploitable vulnerabilities: <\/p>\n\n\n\n

    (1) externally accessible debug test points that bypass physical anti-tamper protections; <\/p>\n\n\n\n

    (2) an active, unauthenticated UART console yielding root shell access; <\/p>\n\n\n\n

    (3) Telnet on port 23\/TCP with passwordless root login on the network interface; <\/p>\n\n\n\n

    (4) at least 61 instances discoverable via Shodan, exposed directly to the internet. <\/p>\n\n\n\n

    Each one alone would be a critical finding. Together, they represent a systemic failure in the product\u2019s security lifecycle \u2014 from threat modeling and secure design, through implementation and pre-production testing.<\/p>\n\n\n\n

      \n
    • Implications for payment infrastructure<\/strong><\/li>\n<\/ul>\n\n\n\n

      A POS terminal with root-level read\/write filesystem access \u2014 reachable both physically and over the network \u2014 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.<\/p>\n\n\n\n

        \n
      • The regulatory context: CRA and beyond<\/strong><\/li>\n<\/ul>\n\n\n\n

        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 \u2014 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.<\/p>\n\n\n\n

          \n
        • Key takeaways for practitioners<\/strong><\/li>\n<\/ul>\n\n\n\n

          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 \u2014 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.<\/p>\n\n\n\n

          WANNA BECOME A CERTIFIED HARDWARE HACKER?<\/strong><\/h2><\/div>\n\n\n\n

          The Offensive Hardware Hacking Training is a Self-Paced training including Videos, a printed Workbook and a cool Hardware Hacking Kit. And\u2026 you get everything shipped home Worldwide! For more info: <\/p>\n\n\n\n

          \n