From sprinklers to motorcycles: What we hacked

In cybersecurity, testing is key. Our pentesters simulate real-world attacks to identify weak spots before criminals can. By reverse-engineering systems and products, they uncover critical flaws. This gives clients the insight needed to fix issues and reduce risk.

In this article, we break down four projects into three questions: Why did we hack it? What did we find? What was the impact?

PROJECT

Sprinkler Controller with BLE Support and Mobile Apps

client CONCERNS

With the addition of Bluetooth Low Energy (BLE) support, the client’s updated controllers were designed to allow users to control the system remotely via mobile applications. The client needed to ensure that this new connectivity didn’t introduce vulnerabilities, which could potentially expose customer devices to unauthorized access.

THE MISSION: WHY WE HACKED IT

The client was integrating BLE into their next-generation IoT sprinkler controller. BLE is a common technology in IoT devices, but it’s also a frequent target for hackers due to its security misconfigurations.

The client needed assurance that the new connectivity didn’t open up paths for attackers to compromise devices, manipulate sprinkler settings, or gain unauthorized access to user networks. Our goal was to pinpoint any security flaws early, ensuring that customers’ homes and gardens weren’t at risk from cyber threats.

THE BREAKDOWN: WHAT WE FOUND

We tackled the security review using two methodologies:

• OWASP Top 10 for Mobile Applications: Assessed the mobile app for vulnerabilities like insecure data storage, insufficient transport layer protection, and improper authentication.
• IoT Testing for BLE Configuration: Examined how BLE was implemented and configured to ensure there were no common misconfigurations like lack of authentication or unencrypted data transmission.

DURING TESTING WE UNCOVERED SEVERAL CRITICAL ISSUES

• Design Flaws in the BLE Pairing Process: Weak pairing mechanisms made it easier for potential attackers to eavesdrop or interfere.
• Vulnerabilities in Mobile App Data Handling: Sensitive data was being stored without adequate encryption, making it possible for an attacker with device access to extract and misuse it.
• Exposed Device Commands: Several BLE commands used to control the sprinkler settings were not properly secured, leaving room for unauthorized manipulation.

BY REMEDIATING THESE ISSUES, THE CLIENT WAS ABLE TO

• Secure the BLE pairing process, ensuring that only legitimate users could control the device.
• Implement secure storage and transmission methods for sensitive information within the mobile apps.
• Lock down device commands, reducing the likelihood of malicious tampering.

As a result, the client’s BLE-supported sprinkler controllers were not only more secure, but they also provided peace of mind to end-users, who could trust that their smart systems were robust against potential cyber threats. This proactive security testing allowed the client to go to market with confidence, turning a potential risk into a competitive advantage.

PROJECT

Motorcycle Ignition Control System (ICS) Reverse Engineering

CLIENT CONCERNS

The motorcycle’s ignition control system (ICS) governs the spark timing to ignite the engine’s fuel-air mixture. The client needed to understand if the system could be reverse-engineered to tweak the performance of the motorcycle, such as increasing horsepower by adjusting spark timing or altering the rev limits.

THE MISSION: WHY WE HACKED IT

The ignition control system on this motorcycle, a Suzuki Katana, was being investigated for potential performance tuning. The system was embedded within a sealed box and controlled the timing of the ignition sparks via a microcontroller. The client wanted to reverse engineer the system to modify the engine’s performance. The goal was to learn more about the ICS and determine if it could be reprogrammed to boost performance without compromising reliability.

THE BREAKDOWN: WHAT WE FOUND

We approached the reverse engineering process by:

• Hardware Deconstruction: Attempted to physically access and probe the circuit board within the sealed ignition control system to understand how it operated.
• Microcontroller Identification: Identified the microcontroller governing the system, despite challenges caused by the protective sealing, and searched for debugging or reprogramming interfaces.

DURING TESTING WE UNCOVERED SEVERAL CRITICAL ISSUES

• Sealant Protection Mechanism: The system was heavily sealed with materials designed to deter reverse engineering, which led to some damage when trying to access the board.
• No Debug Interface: Despite thorough testing of potential interfaces, there was no straightforward method to reprogram the microcontroller or extract the firmware.
• Limited Firmware Accessibility: The microcontroller utilized mask ROM, meaning the firmware was hardcoded and could not be extracted without advanced techniques like decapping.

BY REMEDIATING THESE ISSUES, THE CLIENT WAS ABLE TO

• Pivot the approach to Black Box Testing: By simulating the inputs and measuring the outputs (e.g., camshaft position and throttle), the client successfully inferred the ignition timing algorithms.
• Build a Custom Simulator: The client created a custom microcontroller system to mimic the ICS behavior and explore performance tuning possibilities.

As a result, the client gained a deeper understanding of how the ICS controlled the engine’s performance and could start building a new, programmable system to improve power and efficiency. While direct reprogramming wasn’t possible, the black-box approach provided valuable insights into how to modify the ignition timing for enhanced performance.

PROJECT

Medical Device Security

CLIENT CONCERNS

Automated medical devices that connect to hospital networks and cloud services present unique security challenges. In this particular case, the target was an embedded system that allowed hospital personnel to authenticate to workstations by means of Bluetooth Low Energy that performed active presence detection and user tracking. The client was concerned that potential vulnerabilities could allow unauthorized device or workstation control, data tampering, or the exposure of sensitive patient information. The objective was to assess the device’s resilience to cyberattacks and ensure compliance with industry regulations.

THE MISSION: WHY WE HACKED IT

Bureau Veritas Cybersecurity was tasked with evaluating the medical device’s software, embedded hardware, network connections, and data management practices. The mission was to identify security gaps that could be exploited to compromise patient safety or disrupt medical procedures.

THE BREAKDOWN: WHAT WE FOUND

Our security assessment involved:

• Network Vulnerability Testing: Assessed connections to hospital and cloud networks for weaknesses that could allow unauthorized access.
• Data Integrity Analysis: Evaluated how patient data was stored and transmitted, focusing on encryption and tampering prevention.
• Hardware Attack Simulation: Ubertooth One and NRF51 were used to sniff the BLE traffic between the target components of the customer hardware and application. Gatttool was used to discover, read, and write to available BLE characteristics.
• Device Control Simulation: Simulated potential attack scenarios to test if remote control of the device was possible.

KEY FINDINGS INCLUDEd

• Insufficient Data Encryption: Found that certain data transmissions were inadequately protected, posing a risk of interception and tampering.
• Unrestricted BLE Characteristics: Insecure Bluetooth Low Energy (BLE) settings left the proximity tracking vulnerable to manipulation, enabling unauthorized monitoring of user activity and interference with expected operations
• Flawed Authentication: Intercomponent interactions and protocols were insecure, potentially enabling a jamming attack that would circumvent system authentication.
• Piggybacking Attacks: MITM on the Bluetooth connection allowed capturing the UUIDs, MAC and other values to add them to another application without consent.
• Unauthorized Access Paths: Identified pathways that could allow attackers to gain control over the device or access patient data.
• Regulatory Gaps: Highlighted areas where security measures did not align with industry regulations, impacting compliance.

BY REMEDIATING THESE ISSUES, THE CLIENT WAS ABLE TO

• Enhance Data Encryption: Implement comprehensive encryption standards to safeguard patient data.
• Secure Network Access: Close unauthorized access paths and strengthen authentication measures.
• Achieve Compliance: Align device security protocols with industry standards to meet regulatory requirements.

These improvements significantly increased the security and reliability of the medical device, ensuring patient safety and data protection.

PROJECT

Robot Vacuum

CLIENT CONCERNS

Connected robotic vacuum cleaners introduce risks related to data exposure and device misuse. In this case, the device used Bluetooth and cloud-based services, with control functions linked to a mobile application. The manufacturer wanted to understand if attackers could misuse the system to track movements, manipulate device actions, or extract sensitive data. The goal was to assess technical risks and identify weak points in the design.

THE MISSION: WHY WE HACKED IT

We were asked to review the device across all layers: hardware, firmware, mobile applications, communication protocols, and local storage. The mission was to uncover issues that could be exploited to access data or gain control over the device.

THE BREAKDOWN: WHAT WE FOUND

Our team used multiple tools, custom scripts, and proven testing methods to examine the device.

Key activities included:

• Firmware and Update Validation: Reviewed update procedures and tested for misuse.
• Mobile App Testing: Assessed how users interacted with the device and looked for hidden or unguarded features.
• Communication Testing: Investigated how data was sent between device, app, and backend systems.
• Data Storage Review: Looked at how and where information was stored locally.

KEY FINDINGS INCLUDED

• Weak Communication Security: Certain transmissions were not well protected, allowing location data and cleaning logs to be captured.
• Firmware Update Risks: The update process lacked digital signature checks, opening the door to altered firmware injection.
• Unrestricted App Functions: Mobile app flaws exposed internal test features and could allow misuse of device functions.
• Remote Access Risks: Attackers could exploit these issues to control the vacuum or observe user behavior.

BY REMEDIATING THESE ISSUES, THE CLIENT WAS ABLE TO

• Improve access controls in the mobile app to block misuse of internal functions.
• Fix gaps in communication to prevent traffic interception.
• Apply cryptographic changes to protect stored and transmitted data.
• Introduce strong verification for firmware updates.
• Add safeguards against automated misuse of the mobile app.
• Train technical teams on secure mobile and IoT development practices.

These actions helped the manufacturer reduce risk across the board and gain a clearer view of how attackers could approach the system. The results supported long-term product improvements and a stronger posture for future devices.