Modern vehicles are no longer purely mechanical machines. They are distributed computer networks on wheels. A contemporary vehicle may contain dozens of Electronic Control Units (ECUs) communicating over multiple Controller Area Network (CAN) buses, exchanging thousands of messages every second.

This creates enormous possibilities for diagnostics, monitoring, and customization. It also creates enormous risks when somebody attempts to “simulate” signals or manipulate feedback to the engine management system.

Recently, I received an inquiry from someone who wanted to modify a vehicle in a way that would simulate a feedback signal on the CAN bus network. While I declined the project due to lack of detailed vehicle-specific knowledge and potential liability concerns, the request raises an important topic worth discussing:

What exactly is involved when tampering with a vehicle’s CAN network?

The short answer is:
Far more than most people realize.

Understanding the Modern Vehicle Network

A modern luxury vehicle does not have a single computer controlling everything. Instead, it has a collection of specialized ECUs, such as:

• Engine Control Module (ECM)
• Transmission Control Module (TCM)
• ABS/Brake Controller
• Airbag Controller
• Body Control Module (BCM)
• Steering Controller
• Infotainment Systems
• Suspension Controllers
• Security and Immobilizer Systems

These modules constantly exchange information over one or more CAN buses.

For example:

• Engine RPM
• Vehicle speed
• Brake pedal position
• Steering angle
• Wheel speeds
• Throttle position
• Torque requests
• Emission-related information

All of this data is transmitted as CAN messages.

At first glance, simulating a signal may sound simple:
“Just send the correct CAN message.”

Unfortunately, reality is far more complicated.

The Major Challenge: Reverse Engineering

Vehicle manufacturers generally do not publish detailed CAN message databases for proprietary systems.

This means that anybody attempting to manipulate vehicle behavior must first reverse engineer the network.

That process can involve:

• Capturing CAN traffic
• Logging message IDs
• Monitoring changing data bytes
• Correlating driver actions with CAN activity
• Identifying timing requirements
• Understanding checksums and counters
• Discovering gateway behavior
• Identifying redundant safety mechanisms

Even determining which message controls a specific function can take days or weeks.

Luxury vehicles are especially challenging because they often contain:

• Multiple CAN buses
• Gateway modules
• Encrypted or authenticated traffic
• Proprietary diagnostics
• Redundant safety logic
• Security monitoring systems

A signal visible on one CAN bus may not even reach another ECU without authorization from a gateway controller.

CAN Bus Injection Is Not the Same as Diagnostics

Many hobbyists assume that because they can read diagnostic information through the OBD-II connector, they can easily manipulate the vehicle.

That assumption is incorrect.

Reading data is relatively safe and straightforward.

Injecting data into an active vehicle network is an entirely different matter.

When transmitting messages onto a CAN bus, you are effectively competing with the vehicle’s original ECUs.

This can result in:

• Message conflicts
• Bus overload conditions
• Error frame generation
• ECU communication faults
• Failsafe modes
• Unexpected system behavior

In some cases, ECUs may detect invalid data and enter protective operating states. In worse cases, systems may behave unpredictably.

Simulating Engine Feedback Is Particularly Dangerous

Requests involving “feedback to the engine” are especially concerning.

Modern engine management systems depend on numerous interconnected inputs, including:

• Airflow measurements
• Oxygen sensors
• Temperature sensors
• Torque requests
• Emission controls
• Transmission status
• Stability control systems

Manipulating one signal may affect many other systems.

For example:

A simulated sensor value might:

• Alter fuel injection timing
• Affect turbocharger operation
• Trigger transmission behavior changes
• Disable emission protections
• Influence traction control logic

Manufacturers spend years validating these interactions under countless operating conditions.

An aftermarket developer attempting to alter them without full system documentation is effectively experimenting on a moving vehicle.

Safety-Critical Systems May Be Indirectly Affected

One of the biggest misconceptions is:
“I’m only modifying one function.”

In reality, vehicle systems are deeply interconnected.

Even seemingly unrelated modifications can affect:

• Stability control
• Anti-lock braking
• Steering assistance
• Adaptive suspension
• Collision avoidance systems
• Airbag readiness
• Drivetrain protection logic

Modern vehicles constantly exchange state information between ECUs.

A manipulated engine torque value, for instance, may influence traction control decisions or transmission shift logic.

This is why manufacturers treat software validation as a massive engineering effort.

Security Systems Complicate Everything

Modern vehicles increasingly include cybersecurity protections.

Manufacturers now implement mechanisms such as:

• Message counters
• Rolling authentication
• Secure gateways
• ECU pairing
• Cryptographic verification
• Intrusion detection

A CAN message alone may no longer be sufficient to trigger a function.

Some systems validate:

• Message origin
• Timing consistency
• Sequence behavior
• Expected ECU responses

Attempting to bypass these protections can quickly become extremely complex.

Legal and Regulatory Concerns

This is where things become even more serious.

Depending on the country and application, modifying vehicle control systems may create legal exposure involving:

• Emissions regulations
• Road safety laws
• Vehicle certification requirements
• Insurance compliance
• Warranty violations
• Consumer liability
• Product liability

In the United States, for example, tampering with emissions-related systems may violate EPA regulations.

Even modifications unrelated to emissions can create liability if:

• An accident occurs
• Safety systems are affected
• The modification contributed indirectly to vehicle behavior

A developer who provides hardware or software modifications could potentially face claims involving:

• Negligence
• Unsafe product design
• Failure to warn
• Unauthorized system modification

And unlike hobby projects on a test bench, road vehicles operate in public environments where failures can injure people.

The Liability Problem for Developers

This is one of the primary reasons many engineers and companies refuse such projects.

Even if the modification appears technically feasible, questions immediately arise:

• Was the system fully tested?
• Under all temperatures?
• Under all driving conditions?
• During fault scenarios?
• During partial ECU failures?
• During communication interruptions?

Without manufacturer-level validation resources, guaranteeing safety becomes nearly impossible.

This is particularly true for custom one-off modifications.

A developer may unknowingly assume enormous legal risk for a project that initially sounded simple.

Professional Automotive Development Is Very Different

Professional automotive development environments involve:

• Formal safety analysis
• ISO 26262 processes
• Hardware-in-the-loop testing
• Extensive validation
• Fault injection testing
• EMC testing
• Environmental testing
• Cybersecurity assessments

Entire engineering teams may work on a single subsystem.

This illustrates why modern automotive software development is so expensive — and why undocumented modifications are risky.

Is It Technically Possible?

Sometimes yes.

But “possible” and “safe” are very different things.

A skilled reverse engineering team with significant automotive expertise may eventually discover how to manipulate certain functions.

However:

• The work is often extensive
• The risks are substantial
• The results may be unreliable
• The legal exposure can be significant

For many independent developers and small engineering firms, declining such projects is simply the responsible decision.

Final Thoughts

The CAN bus is one of the most powerful technologies in modern vehicles. It enables remarkable functionality, diagnostics, and integration.

But it is also deeply tied to safety-critical systems.

Tampering with vehicle CAN communications is not comparable to modifying consumer electronics or hobbyist embedded systems. Modern vehicles are highly integrated, security-conscious platforms designed through years of testing and validation.

What initially sounds like:
“Just simulate a signal”

may actually require:

• Extensive reverse engineering
• Deep automotive expertise
• Specialized equipment
• Significant testing
• Legal risk assessment
• Safety validation

And even then, success is far from guaranteed.

For educational purposes, studying CAN bus technology is fascinating and highly valuable. But when it comes to modifying undocumented vehicle behavior on public-road vehicles, caution is not optional — it is essential.

Teensy 4.0 OBDII CAN-Bus ECU Simulator

The Teensy 4.0 OBDII CAN-Bus ECU Simulator is a compact automotive development platform designed for engineers, hobbyists, educators, and software developers working with OBD-II diagnostics and CAN-Bus communication. Built around the powerful Teensy 4.0 microcontroller, which comes pre-installed and pre-programmed, the simulator emulates a vehicle Electronic Control Unit (ECU) and generates realistic OBD-II traffic over the CAN bus. The system allows developers to test diagnostic applications, scan tools, telemetry software, and CAN-based embedded systems without requiring access to an actual vehicle. Adjustable potentiometers provide live control over simulated PID values such as engine RPM, throttle position, and vehicle speed, making the platform especially useful for interactive testing and demonstration environments.

The simulator supports standard SAE J1979 OBD-II services and operates at 500 kbps CAN speed, closely matching real-world automotive communication conditions. Thanks to the Teensy 4.0’s 600 MHz ARM Cortex-M7 processor, the platform delivers fast response times and substantial processing power for advanced development projects. The firmware is open source and fully customizable, allowing users to modify existing PIDs or implement their own diagnostic behavior and CAN messaging schemes. The board includes a female OBD-II connector with integrated power support and is compatible with the Arduino IDE, making development accessible even for users without extensive embedded systems experience. Whether used in a classroom, development lab, or prototype environment, the ECU simulator provides a practical and affordable way to explore automotive diagnostics and CAN-Bus communication in depth. More information...