What follows isn't just a hack story — it's a reminder of how real-world security often fails in silence. The Worldline Yomani XR is a payment terminal trusted across Europe and quietly exposes a root shell. In this article we connect, observe, and uncover how layered security collapses when a single debug interface is left unprotected.
A while ago, I came across a meticulous piece of hardware research on the Worldline Yomani XR — a payment terminal commonly seen across Europe. The original researcher had already done the hard part: dissecting the device, mapping its components, understanding its tamper detection, and even performing a chip-off analysis of the onboard flash memory.
Read the original research here.
Their conclusion was striking: an unprotected root shell, accessible directly from the device's service port. No opening of the case. No triggering of tamper sensors. No special equipment.
I decided to reproduce and extend that finding.
Normal Operation
The merchant connects the terminal to their payment service provider and to the cash register, which orchestrates the transaction flow. A customer then presents their card — swipe, insert or tap — enters a PIN or confirms the amount (and optionally a tip), and the terminal communicates with the payment network to authorize and complete the sale.
Setting the Scene
Our goal was simple: validate whether the reported root shell was reproducible, understand which processor domain it belonged to, and evaluate the practical risk this poses in the field.
Before touching the soldering iron, we followed standard procedure. We verified voltage levels and ground, confirming the 3.3V TTL interface. With that established, we connected to the indicated pins and launched picocom at 115200 baud — the most common setting.
The boot log appeared instantly. A moment later, the familiar prompt:
Typing root dropped us directly into a root shell. No password. No challenge. No warning.
A Tale of Two Processors
Digging deeper into public documentation and teardown material revealed that the Yomani XR architecture actually includes two distinct processors:
- MP1 (Secure Processor):Handles cryptographic operations, payment data, keypad and display handling.
- MP2 (Application Processor): Manages peripheral and general-purpose functions.
The root shell we accessed belongs to the insecure domain (MP2). While it doesn't directly process cardholder data, its privilege level and proximity to the secure domain mean it still represents a valuable entry point for attackers — especially if communication between both processors is insufficiently controlled.
Looking Beneath the Surface
With shell access established, our next step was to look for configuration and credential artifacts. We scanned the firmware partition for hard-coded secrets:
/ # strings /dev/mtd0 | grep -i "passw"Among the results were two cleartext passwords, apparently used for technician and configuration access.
<attribute name="TechnicianZPassword" value="[REDACTED]" />
<attribute name="HwConfigPassword" value="[REDACTED]" />We also explored the startup scripts, where two files stood out:
S14telnetDisable
S16telnetDestroyBoth scripts actively remove or kill any Telnet daemon during boot — a commendable sign of hardening intent. Yet paradoxically, the firmware still contains all necessary binaries to restore Telnet functionality. This design decision suggests the developers anticipated such use but relied solely on software scripts to suppress it, not on deeper configuration controls.
Implanting a Simple Backdoor
For research continuity, we restored a Telnet instance right at the end of the kill command script to simplify data access, preferring this method over inserting bind or reverse shell commands.
Firmware Extraction
The terminal provides a USB interface, which we used to connect a standard flash drive.
From there, we created a mount directory and used dd if=/dev/mtd0 of=/mnt/usb/XR_mtd0.bin bs=2048to copy the full firmware image from the MTD block device.
A quick check in Binwalk confirmed that the extracted image was unencrypted:
With both live shell access and the full firmware image in hand, we now have a comprehensive access to the system's inner workings — a combination that should never be possible from a production-grade payment device.
Barriers and Boundaries
Interestingly, our research hit a clear wall when we tried to explore the device's user interface and keypad functions. Despite discovering technician passwords within the firmware, we found no hidden key combinations or service menus that would allow direct use of those credentials through the physical interface.
As it turns out, all display and keypad handling are probaly managed by the secure MP1 processor, entirely isolated from the domain we can access. That design at least ensures user input and payment workflows remain protected, even if the auxiliary domain is compromised.
Reflections on Risk
From a security standpoint, the issue is less about a single root shell and more about what its existence implies:
- Physical access alone is enough to gain privileged control.
- No tamper detection is triggered when connecting to the service port.
- No authentication is required for root-level access.
- Firmware is unencrypted and exposes sensitive information.
In the context of retail payment infrastructure, this combination is problematic. Devices like these are not locked in data centers , they sit on open counters, in kiosks, or in unattended terminals. Even a brief, unnoticed access could lead to firmware tampering, or lateral network movement.
For Operators and Integrators
- Limit physical access to payment terminals; apply tamper seals and enclosure locks.
- Isolate payment devices on dedicated VLANs, with strict network control.
- Reflash second-hand or refurbished terminals before redeployment.
- Disable service ports at hardware level .
Physical access remains one of the most underestimated threats.
Especially in retail or public environments, assuming that no one will connect to a port is not a control, it's wishful thinking.
The Yomani XR demonstrates how security layering can fail quietly. Developers clearly intended to harden the device, disabling Telnet, separating processors, and embedding tamper detection, but a single overlooked interface undermines much of that effort.
For researchers, it's an opportunity to study real-world trade-offs between usability and security in embedded payment systems. For vendors and operators, it's a reminder that debug ports are not harmless leftovers; they are fully capable pathways into systems that process critical data.
And as long as such ports remain accessible, it's not a matter of if someone will find them, but when.
Responsible Disclosure and Vendor Response
After publishing the initial version of this research, Worldline contacted me to discuss the findings. The conversation was constructive and professional, and I appreciate the open dialogue and the opportunity to exchange perspectives on embedded system security and hardware research methodologies.
Responsible disclosure and collaboration between researchers and vendors remain essential for improving the security of widely deployed systems.
It was particularly refreshing to speak with a security professional who share a similar hacker mindset and passion for understanding how systems actually work.
About the Author
Marcel Rick-Cen is the founder and lead instructor at FOXGRID Industrial, a learning platform built for engineers, hackers, and defenders who want to master industrial systems the right way.
An automation engineer turned OT security specialist, Marcel brings over two decades of hands-on experience — from global service engineering to tamper detection research at the German Bureau of Information Security. With a background in electrical engineering and a master's degree focused on Operational Technology, he now works as an OT/IIoT Security Consultant by day and experiments as an OT hacker by night, uncovering real-world vulnerabilities in the systems that power industry.
Marcel has designed a complete, lab-driven training path for anyone who wants to go beyond theory and into real industrial hacking and defense. His courses cover:
- Offensive testing of industrial field devices and networks
- Exploitation of embedded OT/IIoT hardware
- Assessment and protection of industrial environments
- Creating ICS/OT deception hosts
LEVEL UP WITH FOXGRID NOW!
🔥 As a Medium reader, you get 30% off Marcel's training — and join Marcel directly inside the labs.
👉 Click here to start your industrial hands-on journey
⌨️ This article is AI-enhanced.