Hacking OBD II Emissions Testing

Hacking OBD-II Emissions Testing

Speakers: Archwisp

Conference: DEF CON 33

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

Slides: https://media.defcon.org/DEF%20CON%2033/DEF%20CON%2033%20presentations/Archwisp%20-%20HaKCing%20OBD-II%20Emissions%20Testing.pdf

Overview

What happens when a security researcher buys a rotary-engined sports car that kills catalytic converters, moves from a state without emissions testing to one that has strict emissions laws, and decides the only reasonable response is to investigate what OBD-II emissions testing actually measures — and whether it can be fooled? This is the premise of Archwisp's talk at DEF CON 33, a first-person account of exploring the security and integrity of the OBD-II vehicle emissions testing ecosystem used across states like California, Washington, and others.

The talk blends practical automotive security research with a consumer's honest frustration at bureaucratic emissions systems that may be checking the wrong things. Archwisp walks through what OBD-II emissions testing actually evaluates, the architecture of the testing infrastructure (including the state-run backend systems that record test results), the technical mechanics of how an OBD-II reader communicates with a vehicle's ECU, and ultimately what he discovered about the testability — and potential manipulability — of the process. The research was presented at SCKC (a related community event) prior to DEF CON.

The audience is anyone interested in automotive security, OBD-II, vehicle ECU hacking, or the gap between regulatory intent and technical implementation in emissions compliance systems.

Background

▶ Watch: Introduction: OBD-II emissions testing and inspection systems (1:14)

OBD-II and Emissions Testing

On-Board Diagnostics II (OBD-II) is a standardized vehicle diagnostic interface mandated in the United States for all cars manufactured after 1996. OBD-II provides access to engine and emissions-related sensor data through a standardized 16-pin connector typically located under the dashboard. The standard defines diagnostic trouble codes (DTCs), parameter IDs (PIDs) for sensor readings, and "readiness monitors" — internal self-tests that the vehicle's ECU runs to verify that emissions-critical systems are functioning correctly.

In many US states, emissions testing is conducted by connecting an OBD-II scanner to the vehicle's port and reading:

1. Diagnostic Trouble Codes (DTCs): Any stored fault codes related to emissions systems (particularly catalyst efficiency, oxygen sensor performance, evaporative emissions) fail the test
2. Readiness Monitors: These are flags that indicate whether the vehicle's ECU has completed self-tests for emissions-critical systems. If too many monitors are "not ready" (INCMP), the vehicle fails or is sent for a re-test
3. On some older vehicles: A direct tailpipe emissions sniff (measuring hydrocarbons, CO, CO2, NOx) supplements the OBD-II check

The purpose of readiness monitors is to ensure that a vehicle hasn't had its DTCs cleared immediately before the test to temporarily pass — clearing DTCs also resets all readiness monitors to "not ready," so a vehicle that had its codes cleared must be driven through its full drive cycle before monitors complete.

The Rotary Engine Problem

Archwisp's vehicle — a Mazda RX-8 (or similar rotary-engined car) equipped with a Wankel rotary motor — is notorious in the automotive community for destroying catalytic converters. Rotary engines run rich and hot under certain conditions, causing unusually rapid catalyst degradation. A vehicle that has had its catalytic converter removed or replaced with a non-compliant substitute will typically produce catalyst efficiency DTCs once the oxygen sensor monitors detect reduced converter performance.

Having already removed the problematic catalytic converter while living in a non-testing state, Archwisp faced a straightforward compliance problem upon moving to the West Coast: the vehicle would not pass an OBD-II emissions test because the catalyst monitor would either fail or never complete (if the catalyst is absent, the ECU may detect this and either set a DTC or leave the monitor in a permanently incomplete state).

The collector vehicle exemption (for vehicles of a certain age or rarity, used infrequently, with the registered owner also possessing another primary vehicle) was researched as a potential path to exemption but posed its own qualification challenges.

Key Findings

▶ Watch: Manipulating OBD-II data to pass emissions tests fraudulently (6:14)

OBD-II Test Infrastructure Architecture

Archwisp examines the architecture of the state emissions testing system at multiple levels:

Testing station hardware: Licensed testing stations use approved OBD-II scan tools that communicate with the vehicle through the standard ISO 15765-4 (CAN bus) or other OBD-II transport protocols. The scan tool reads DTCs, readiness monitor status, and (where applicable) VIN and calibration information.

Backend reporting: Test results are transmitted from the testing station to a state DMV backend system, typically over an internet connection. The connection may be a simple HTTP/HTTPS POST of the test results, or may use a proprietary protocol specific to the testing station software vendor.

VIN matching: The test system associates results with the vehicle's VIN (Vehicle Identification Number), which is read from the OBD-II port or manually entered. This links the electronic test result to the vehicle's registration record in the DMV database.

Data that is and is not transmitted: Archwisp investigates what data is actually transmitted from the scan tool to the backend. The key finding is that the backend receives a summary of the OBD-II test results — pass/fail on individual monitors, presence or absence of DTCs — but does not receive the raw OBD-II sensor data. This means the validation of compliance happens on the scan tool itself (or in the tool's software), and the backend simply records the result.

ECU Communication and Monitor Mechanics

Archwisp provides a technical walkthrough of how OBD-II readiness monitors work:

Monitor types:

• Continuous monitors: Run constantly while the vehicle is in operation (comprehensive component monitoring, misfire monitor, fuel system monitor)
• Non-continuous monitors: Run only under specific driving conditions (catalyst monitor, oxygen sensor monitor, EGR system monitor, evaporative emissions monitor, etc.)

Drive cycle: Completing non-continuous monitors requires driving the vehicle through a specific pattern of speeds, loads, and engine temperatures defined by the manufacturer. A catalyst monitor, for example, typically requires multiple warm-up cycles with sustained highway speed operation.

Communicating directly with the ECU: Archwisp explores the ability to communicate directly with the vehicle's ECU using off-the-shelf OBD-II tools (ELM327-based adapters, professional scan tools) and open-source software (python-OBD, pyOBD). This allows reading raw sensor data, clearing DTCs, and (with appropriate mode 6 or manufacturer-specific commands) interacting with the monitor states directly.

The Monitor State Manipulation Question

The core security question of the talk: is it possible to manipulate the ECU's readiness monitor states or DTC state such that a vehicle presents as passing an emissions test when it would not pass a proper physical emissions measurement?

Archwisp investigates two angles:

Direct ECU manipulation: Can an attacker (or a motivated car owner) use OBD-II commands to directly set monitor states to "complete" or clear DTCs without the vehicle having actually run the relevant drive cycle? The answer depends heavily on the specific vehicle's ECU firmware. Most modern ECUs do not expose writable monitor state via standard OBD-II commands — Mode $08 (Request Control of On-Board System, Test or Component) is defined in the OBD-II spec but is not commonly implemented in a way that allows setting monitor flags. However, some aftermarket ECU firmware, performance tunes, and manufacturer-specific diagnostic modes may provide more access.

Spoofing at the scan tool or communication layer: An alternative approach is to intercept the OBD-II communication between the scan tool and the vehicle and present modified data to the scan tool (man-in-the-middle of the OBD-II bus). This would require hardware placed in the OBD-II port that responds to scan tool queries with crafted responses rather than relaying them to the actual ECU.

Archwisp demonstrates an OBD-II protocol proxy built on open-source hardware (an Arduino or similar microcontroller with a CAN bus interface) that can intercept and selectively modify OBD-II responses. This proxy, inserted between the testing station's scan tool and the vehicle's OBD-II port, can present the scan tool with a modified view of the vehicle's diagnostic state — potentially reporting all monitors complete and no active DTCs.

Testing Station Validation Gaps

A related finding concerns what validation the testing station scan tool and software actually perform:

VIN verification: Some implementations accept the VIN from the OBD-II port without independent verification against the vehicle's physical VIN plate. If the VIN reported by the ECU (which can sometimes be changed via ECU reprogramming) differs from the physical VIN, this inconsistency may not be flagged.

No physical emissions measurement: In many states, OBD-II testing has entirely replaced physical tailpipe testing for newer vehicles. This means that a vehicle that manipulates its OBD-II presentation effectively manipulates its entire emissions compliance record, with no physical measurement as a backstop.

Test center system security: Archwisp examines the security posture of the state backend system from the perspective of the test data submission. Without conducting an actual attack against production systems, he notes that the trust placed in test station hardware to accurately report results, combined with the lack of end-to-end validation of the raw sensor data, creates meaningful integrity weaknesses in the overall system.

Technical Deep Dive

▶ Watch: Live demo: defeating OBD-II emissions test with custom hardware (11:14)

OBD-II Protocol Stack

The OBD-II physical layer can be K-Line (ISO 9141-2), CAN (ISO 15765-4), or other implementations. Modern vehicles universally use CAN. The OBD-II diagnostic layers above CAN are standardized:

• ISO 15765-2 (TP/CAN): Transport protocol for segmented diagnostic messages over CAN
• ISO 14229 (UDS — Unified Diagnostic Services): Diagnostic services including DTC reading (Service 0x19), ECU reset, and data record reading
• OBD-II modes (SAE J1979): Standardized diagnostic modes 01–0A for emissions-specific data (Mode 01: current data, Mode 03: stored DTCs, Mode 04: clear DTCs, Mode 05/06: oxygen sensor and on-board monitoring test results)

Relevant PIDs:

• 0x01 (Mode 01, PID 01): Returns readiness monitor status as a bitmask — each bit indicates whether a specific monitor is supported and whether it has completed
• 0x03 (Mode 03): Returns stored DTCs
• 0x07 (Mode 07): Returns pending DTCs (set during current drive cycle but not confirmed)
• 0x41 (Mode 01, PID 41): Returns alternative readiness monitor status (for newer vehicles with additional monitors)

OBD-II Proxy Hardware

The proxy device Archwisp demonstrates uses:

• A CAN transceiver module (MCP2551 or similar) to interface with the vehicle's CAN bus via the OBD-II port
• A microcontroller (Arduino Due, STM32, or similar with CAN peripheral support) to receive CAN frames from the scan tool, process them, and either relay them to the vehicle or substitute modified responses
• Custom firmware implementing the OBD-II request/response protocol with configurable response substitution rules

The proxy can be configured to:

• Return "all monitors complete" regardless of the vehicle's actual monitor state
• Return zero DTCs regardless of stored fault codes
• Pass through all other queries unchanged (to avoid triggering anomaly detection)

This approach would be detectable if the testing system compared the raw sensor data (e.g., oxygen sensor voltage readings) against expected ranges for a compliant vehicle, but current OBD-II test implementations do not typically perform this cross-validation.

Demo / Proof of Concept

▶ Watch: Environmental and regulatory implications of emissions fraud (13:44)

Archwisp demonstrates the OBD-II proxy in a lab setting (not against a production testing station):

1. A scan tool connects to the proxy device instead of a real vehicle
2. The proxy intercepts a readiness monitor status request (Mode 01, PID 01) and returns a crafted response indicating all monitors complete
3. The scan tool displays the modified result as if reading from a real vehicle
4. The proxy also intercepts DTC requests and returns an empty DTC set

The demo illustrates the technical feasibility of presenting a false compliance picture to an OBD-II emissions scan tool. Archwisp notes the legal and ethical constraints on using such a device against a production testing system.

Defensive Implications

▶ Watch: Legal considerations and disclosure to regulatory bodies (18:44)

For state DMV and emissions testing program administrators:

• The current OBD-II testing model places excessive trust in the test station hardware's accurate reporting of raw vehicle data. Adding backend validation of raw sensor readings (not just pass/fail summaries) would significantly raise the bar for manipulation.
• Cross-referencing OBD-II results with the VIN's repair history (a vehicle that recently cleared its DTCs should have incomplete monitors; a vehicle claiming complete monitors immediately after a catalyst DTC should be flagged) adds a temporal consistency check.
• Periodic unannounced testing of testing station hardware with known reference vehicles would detect scan tool manipulation.

For automotive cybersecurity researchers:

• The OBD-II proxy concept applies more broadly to any diagnostic interface on a CAN bus vehicle — automotive red teamers can use similar techniques for ECU impersonation in controlled research environments.
• The trust model of the OBD-II interface — which is physically accessible to any service technician and which exposes significant diagnostic capability — is an underexplored attack surface for vehicle security research.

For regulators:

• As OBD-II testing has replaced physical tailpipe sniffing for newer vehicles, the integrity of OBD-II data becomes the sole basis for environmental compliance. This warrants greater investment in protecting that integrity.

Key Takeaways

• OBD-II vehicle emissions testing relies on reading readiness monitor status and DTC codes from a vehicle's ECU via the standardized OBD-II port, with no independent physical measurement in many states.
• An OBD-II proxy device built on commodity hardware can intercept queries from a testing station's scan tool and return crafted responses presenting a vehicle as compliant regardless of actual emissions system status.
• The backend emissions testing systems receive summary pass/fail data rather than raw sensor readings, creating a validation gap that this attack exploits.
• The research was motivated by real-world compliance challenges with a rotary-engined vehicle and the speaker's move to an emissions-testing state.
• The talk surfaces integrity concerns in an environmental compliance infrastructure that affects vehicle registration for millions of vehicles annually.

About the Speaker

Archwisp is a security researcher and car enthusiast who has been involved with the DEF CON community in multiple capacities prior to their first on-stage presentation at DEF CON 33. The research was initially presented at SCKC (SecKC, the Kansas City security community meetup). Archwisp can be found within the DEF CON community and is reachable through the contacts mentioned at the event.