Reverse Engineering Marine Engines: Make powerboats do your bidding

Reverse Engineering Marine Engines: Make powerboats do your bidding

Speakers: Alex Lorman

Conference: DEF CON

YouTube: https://www.youtube.com/watch?v=AYi5mEWAHzY

Overview

In this illuminating DEF CON talk, Alex Lorman unveils practical strategies for gaining autonomous control over marine engines, challenging the prevailing industry trend of heavily locked-down, proprietary systems. The presentation, titled "Reverse Engineering Marine Engines: Make powerboats do your bidding," demonstrates that despite manufacturers' efforts to prevent user modification—often citing legal liability and warranty concerns—it is surprisingly straightforward to interface with and command these powerful machines. Lorman's work is driven by a desire for open control and the enablement of marine autonomy, contrasting sharply with the "black box" approach favored by major original equipment manufacturers (OEMs).

Lorman, a self-described non-software developer, provides an accessible yet detailed technical roadmap for bypassing complex digital protocols by focusing on the analog interfaces that underpin most marine control systems. His methodology emphasizes intervening at the "user space" level, emulating the electrical signals that a human operator's throttle and shift controls would generate. This approach avoids the arduous task of reverse engineering proprietary CAN buses, offering a pragmatic pathway for hobbyists, researchers, and developers to build custom control systems for everything from jet skis to multi-engine powerboats.

The talk serves as a critical exposition on the state of marine engine control, highlighting the tension between manufacturer control and user freedom. By demystifying the underlying electrical interfaces, Lorman empowers the audience to reclaim agency over their vessels, paving the way for advanced autonomous capabilities and personalized marine experiences, all while navigating the often-hostile landscape of OEM restrictions.

Background

▶ Watch: Introduction and overview of major outboard manufacturers (0:00)

The marine engine market, particularly for propulsion systems over 150 horsepower, is characterized by significant consolidation, with a handful of major OEMs dominating the landscape. Key players include Mercury (owned by Brunswick), Yamaha (known for both engines and jet skis), Honda, and Suzuki for outboards. In the inboard and inboard/outboard (I/O) segments, names like Yanmar, Cummins, Volvo, MTU, and Caterpillar are prominent. These manufacturers often implement highly proprietary and locked-down control systems, citing concerns over legal liability, warranty claims, and user safety as reasons to prevent external modification or integration. Caterpillar, for instance, is notorious for its restrictive protocols and high costs, mirroring the frustrations experienced by users in the agricultural sector with companies like John Deere.

Historically, marine control systems relied on robust, if unsophisticated, push-pull cables for throttle and shift. Even modern engines, equipped with Electronic Control Units (ECUs) for managing functions like piston firing and emissions (e.g., Tier 4 compliance), frequently retain cable-driven interfaces for legacy support. An example cited is a Honda 150 motor featuring a cable-driven electronic throttle body, a hybrid approach supporting older helm configurations with modern engine management. Companies like Glendinning Controls, Sea Star Dometic, and ZF Micro Commander specialize in electromechanical servo boxes that translate electrical signals (analog or CAN) into the physical movement of these cables.

However, the industry is progressively shifting towards fully digital control systems, often leveraging CAN bus networks directly from the helm. Proprietary solutions like Yamaha's Helm Master and Mercury's Skyhook (also known as Virtual Anchor or Station Keeping) offer advanced features such as GPS-enabled station keeping and intelligent multi-engine synchronization using joysticks. These systems, while sophisticated, are presented as "giant black boxes" with manufacturers deliberately withholding detailed information on their internal workings and communication protocols. This lack of transparency, coupled with the move away from standardized interfaces, creates significant barriers for third-party developers and researchers seeking to integrate custom autonomy solutions. The speaker noted that even major marine electronics companies like Garmin are not given access to these proprietary protocols.

Key Findings

▶ Watch: Overview of Inboard/IO systems and their legacy controls (2:10)

The central and most impactful finding of Alex Lorman's talk is the revelation that bypassing the complex, proprietary digital communication protocols of marine engine manufacturers is often unnecessary and overly complicated. Instead, a far simpler and more effective strategy for gaining autonomous control is to intervene at the "user space" level by directly emulating the analog voltage signals that existing throttle and shift controls output. This method, which the speaker candidly described as the "terrible disappointment" of his research due to its surprising simplicity, allows developers to integrate custom control systems without needing to reverse engineer intricate CAN bus messages or proprietary binary formats.

Lorman demonstrated that regardless of the manufacturer—whether it's a jet ski, a Mercury DTS (Digital Throttle & Shift) system, or even a cable-driven Glendinning control—the fundamental input from the user (e.g., moving a throttle lever) is ultimately translated into a predictable set of analog voltage changes. By identifying these voltage ranges and their corresponding functions (forward, neutral, reverse, speed), one can use readily available hardware like Digital-to-Analog Converters (DAXs) or even simple microcontrollers to generate these signals, effectively "pretending to be the user." This approach negates the need to decipher manufacturer-specific CAN messages, which are often non-standard (e.g., Glendinning's proprietary CAN not being J1939 compliant) and subject to undocumented changes, making them a moving target for reverse engineering efforts. This core finding drastically lowers the barrier to entry for marine autonomy and customization.

Technical Deep Dive

▶ Watch: Complex modern digital control systems: Helm Master, Skyhook (4:00)

Lorman's technical deep dive focuses on practical, low-level intervention strategies for various marine engine control systems, emphasizing direct analog signal emulation rather than complex digital protocol analysis.

Jet Skis (CDU and Yamaha)

Jet skis, designed for ease of use by a broad demographic, feature surprisingly simple control mechanisms. The throttle typically utilizes two Hall effect sensors, which function as digital voltage dividers. When the throttle is squeezed, these sensors output ratiometric voltages—voltages that vary proportionally with the input. For instance, a 2022 Sea-Doo (CDU) manual reveals that the throttle expects voltages between approximately 0.15V and 1.4V for its command input. The ECU then digitizes these voltages to control the throttle bodies and reverse bucket.

To emulate this, one simply needs a DAC to generate the required voltages. Lorman advises checking the slew rates (rate of change) to mimic human input, although jet ski ECUs are designed to tolerate abrupt inputs. The key takeaway is that by reading the wiring diagram and understanding the expected voltage ranges, it's straightforward to create a hardware interface that generates these signals.

Mercury DTS (Digital Throttle & Shift)

Mercury's DTS system, particularly DTS1 (pre-2022), employs a more complex, layered architecture but still relies on analog inputs at the user interface. Lorman divides this into three abstraction layers:

1. Engine Space: Each engine's ECU independently manages core functions like piston firing, timing, and water pumps.
2. Boat Space: Command modules coordinate multiple engines, understanding their configuration (port, starboard, center) and translating user intent.
3. User Space: The helm, where the user inputs commands.

For DTS1, the throttle handle looks for three voltages that move in tandem. Unlike jet skis with separate reverse triggers, Mercury DTS abstracts reverse into a continuous range (e.g., +100 for full forward, 0 for neutral, -100 for full reverse). Replicating this involves using three DAXs to output the corresponding voltages. The main challenge here is physically identifying and connecting to the correct wires within the throttle binnacle, for which Lorman mentioned a specific connector type (GTS150, though not definitively).

Lorman noted that DTS2, Mercury's post-2022 architecture, shifts to CAN bus directly from the helm, indicating a future target for more complex (though potentially still avoidable) reverse engineering.

Glendinning Controls

Glendinning systems are designed for cable-driven motors, using servo boxes to physically push and pull cables. While they incorporate a proprietary CAN bus that is not compatible with standard J1939 tools, Lorman found that hacking them is remarkably simple at the user interface. The helm itself contains a magnet and a Hall effect sensor to determine the lever's position. By disassembling the helm and using a two-channel oscilloscope to observe the Hall effect sensor's output, the exact voltage ranges for throttle and shift can be determined. Once these are known, a custom circuit can generate the same signals. This process, including a lunch break, took Lorman only an afternoon.

Interfacing with Autopilots

To integrate these control methods with an autopilot system (referred to as a "flight controller" or FMU in the ArduPilot community), Lorman explored several options:

• PLCs (Programmable Logic Controllers): Initially considered for their reliability and auditable nature, PLCs proved problematic. Lorman attempted to use MQTT for communication (translating Mavlink messages from the autopilot), but encountered undocumented rate limits and reliability issues with Automation Direct PLCs, likely due to the STM32 microcontrollers they use not being optimized for high-speed message processing.
• Custom Boards: The most successful approach involved designing custom boards around a Teensy microcontroller (a shout-out to PJRC for their contributions). These boards listen to either PWM (Pulse Width Modulation, common in hobby servo control) or Mavlink over serial. The microcontroller then translates these commands into the application-specific analog voltages required by the engine ECUs. Lorman emphasized the simplicity, stating the code was only about 500 lines, manageable even for a non-software developer. He also recommended using signed 8-bit variables for internal command representation to simplify translation.

Essential Tools

Lorman stressed the importance of an engine diagnostic tool (either OEM or third-party) for anyone attempting these modifications. This tool, which plugs into the engine bus, allows for ground-truthing the output of custom hardware, observing engine commands, and troubleshooting errors (such as the "far too many" Yamaha beeps he experienced). Without it, debugging strange errors and resetting engine alarms becomes exceedingly difficult.

Demo / Proof of Concept

▶ Watch: Hacking cable-driven legacy systems for extra bonus points (5:20)

While Alex Lorman's presentation at DEF CON did not feature a live, on-stage demonstration of a powerboat under autonomous control, the talk heavily implied and referenced a working proof of concept. Lorman explicitly stated that his analog voltage emulation method "works. It works reliably." This confidence stems from his practical experience and the development of custom hardware.

Throughout the talk, he encouraged attendees to visit the Maritime Hacking Village, where he mentioned having "some boats" and "some engines." This indicates that a physical demonstration or a functional setup of his reverse-engineered control systems was available for hands-on inspection at the conference village. The speaker's ability to detail specific voltage ranges, connector types, and debugging challenges (like the "Yamaha beeps") further underscores that his methods have been rigorously tested in a real-world environment, not just theorized.

He also alluded to the Maritime Hacking Village badge, which he noted "can interface on 0183 and 2000 and should have arbitrary voltage outputs," suggesting it could be used as a tool for similar reverse engineering and control tasks. The overall tone and detailed technical explanations serve as a robust testament to the feasibility and demonstrated success of his approach, even in the absence of a direct video or live demonstration during the main talk.

Defensive Implications

▶ Watch: US Navy use cases and key cable control system manufacturers (6:00)

Alex Lorman's talk carries significant defensive implications for both marine engine manufacturers and vessel owners/integrators.

For Manufacturers:

The primary takeaway is that relying on proprietary CAN bus protocols and legal threats to prevent user modification is an ineffective security strategy. Lorman's research demonstrates that fundamental control can often be gained by simply emulating analog voltage signals at the "user space" interface. This means that even if a manufacturer invests heavily in obfuscating digital communications, the presence of an underlying analog control layer—necessary for compatibility with legacy systems or simpler helm designs—creates a bypass. Manufacturers should recognize that this vulnerability exists and consider:

• Re-evaluating "Black Box" Strategies: The current approach of withholding documentation and creating closed ecosystems may not deter determined hackers, but rather push them towards less transparent and potentially riskier methods.
• Secure Analog Interfaces: If analog interfaces must exist, they should be designed with security in mind, potentially incorporating authentication or encryption for critical command signals, although this adds complexity.
• Embracing Openness (like Cox Marine): Companies like Cox Marine, which openly provide J1939 ICDs (Interface Control Documents) without an NDA, demonstrate an alternative path. This fosters innovation, allows for safer, documented third-party integrations, and could ultimately enhance the product ecosystem rather than stifling it. This transparency could also mitigate liability by shifting some responsibility to integrators using documented APIs.
• Addressing the Root Cause: The legal liability argument needs to be addressed through clearer standards for third-party integration, rather than through technological obfuscation that is easily bypassed.

For Defenders (Vessel Owners, Integrators, and Security Researchers):

• Autonomy is Achievable: Owners and integrators looking to implement autonomous features or custom control systems should be aware that it's often more practical to target the analog control signals rather than attempting to decipher complex digital protocols. This significantly lowers the barrier to entry for marine autonomy.
• Focus on the User Space: When considering security or customization, prioritize understanding the signals generated by the physical helm controls. This "user space" is often the most accessible and least protected layer.
• Diagnostic Tools are Crucial: Investing in manufacturer-specific or third-party engine diagnostic tools is not just for maintenance; it's an essential security and development tool for understanding baseline behavior and debugging custom interfaces.
• Supply Chain Considerations: The prevalence of legacy support and the use of off-the-shelf components (like Hall effect sensors) mean that vulnerabilities might exist in widely adopted components or design patterns across different manufacturers.
• Security Through Obscurity Fails: The talk is a clear example that security through obscurity is not effective in the long run. If a system's core function can be controlled by simple voltage signals, then those signals become the attack surface, regardless of how complex the digital layers above them are.

Key Takeaways

• Analog Voltage Emulation is Paramount: Bypassing proprietary digital protocols by directly emulating analog throttle and shift signals is the simplest and most effective method for gaining control over marine engines, significantly reducing the complexity of reverse engineering.
• Intervene at the User Space: Focusing on the "user space" (helm/binnacle inputs) allows integrators to avoid the arduous task of deciphering manufacturer-specific CAN bus messages and proprietary digital architectures.
• Hardware is Surprisingly Simple: Basic, inexpensive electronic components like Digital-to-Analog Converters (DAXs), Hall effect sensors, and microcontrollers (e.g., Teensy) are sufficient for building custom control interfaces.
• Engine Diagnostic Tools are Essential: A manufacturer or third-party engine diagnostic tool is critical for ground-truthing custom hardware outputs, understanding engine behavior, and debugging errors during development.
• Manufacturer Lockdowns are Ineffective: OEM efforts to restrict access through "black box" systems and legal threats are largely ineffective against this analog emulation approach, which exploits fundamental electrical interfaces.
• Marine Autonomy is Accessible: Despite industry resistance and proprietary systems, achieving autonomous control for marine vessels is technically feasible for hobbyists and researchers with foundational electronics knowledge.

About the Speaker(s)

Alex Lorman is a security researcher and enthusiast with a keen interest in marine systems. His talk at DEF CON marked his first presentation at the conference, where he shared insights gained from his hands-on experience with marine engines. Lorman has a background that includes "wrenching" on I/O (inboard/outboard) systems and a familiarity with US Navy autonomy setups, suggesting a practical, systems-level approach to his work. He is actively involved with the Maritime Hacking Village, underscoring his commitment to fostering an open community around marine cybersecurity and autonomy. Despite humbly referring to himself as "not a software developer," Lorman successfully developed and implemented a functional control system requiring approximately 500 lines of code, demonstrating his capability in practical engineering and problem-solving.