4.0 KiB
Immobilizer Concepts (Conceptual, Non-Bypass)
This article explains what automotive immobilizer systems are and why the workflows in this repository are structured the way they are. It intentionally stays at the conceptual level — no real security offsets, seed/key algorithms, or bypass techniques are documented here. Real, authorized security-data handling belongs only in 07_Authorized_Key_Immobilizer_Work/ under its governance boundary.
Purpose of an immobilizer
An immobilizer is a security subsystem, usually integrated with the ECU/BCM, that prevents the engine from starting unless a transponder/key presents a value the vehicle recognizes as authorized. The goal is to make starting the vehicle without a recognized key impractical.
General building blocks (concept-level, no real values)
- Transponder — a passive or battery-less chip embedded in the key that responds to a signal from the vehicle's immobilizer antenna (usually around the ignition lock).
- Challenge/response exchange — the vehicle sends a challenge value; the transponder computes and returns a response derived from a secret it holds. The vehicle checks the response against its own expectation before allowing start.
- Rolling/synchronization counters — some systems (more relevant to remote-entry than pure immobilizer challenge/response, but often discussed together) use counters that must stay roughly in sync between key and vehicle to prevent simple replay of an old signal.
- ISN (Immobilizer Serial Number / Identification Sync Number, terminology varies by platform) — a value used in some ECU/immobilizer architectures to keep the ECU and the immobilizer/BCM cryptographically paired to each other. When an ECU is replaced, this value commonly needs to be re-established between the new ECU and the vehicle's immobilizer — which is why "ISN Operations" is documented as its own workflow (
04_Workflows/ISN_OPERATIONS_WORKFLOW.md) rather than folded into a generic ECU clone step. - Key learning / key programming — the authorized process of teaching the vehicle to recognize an additional or replacement key, generally requiring either an already-recognized key present, or a manufacturer-defined "all keys lost" recovery path that typically requires elevated authorization/credentials.
Why this repository separates "concepts" from "operations"
Understanding that a challenge/response and pairing relationship exists is standard, publicly available automotive-security literature (surveyed extensively in academic automotive security research). It is a different thing from documenting the real challenge/response algorithm, seed values, or offsets for a specific platform, which is what 07_Authorized_Key_Immobilizer_Work/README.md scopes as private-authorized-only content, and which the user's own instructions for this pass explicitly excluded ("Do NOT include illegal bypass procedures").
Practical implications reflected in this repository's workflows
- Immobilizer Backup/Restore (
04_Workflows/IMMOBILIZER_BACKUP_RESTORE_WORKFLOW.md) exists because immobilizer-relevant EEPROM regions are exactly the kind of data where a single bad write can strand a vehicle — hence the emphasis on backups before any change. - Authorized Key Learning (
04_Workflows/AUTHORIZED_KEY_LEARNING_WORKFLOW.md) is documented as a procedural/authorization workflow (what records to keep, what to verify before/after), not as an algorithm reference. - ISN Operations (
04_Workflows/ISN_OPERATIONS_WORKFLOW.md) is scoped the same way: procedural context (when ISN re-sync is typically needed, what to verify) without real cryptographic material.
Related documents
07_Authorized_Key_Immobilizer_Work/README.md— governance boundary and required controls for real authorized work04_Workflows/IMMOBILIZER_BACKUP_RESTORE_WORKFLOW.md04_Workflows/AUTHORIZED_KEY_LEARNING_WORKFLOW.md04_Workflows/ISN_OPERATIONS_WORKFLOW.md05_Reference/SECURITY_RESEARCH_TOPICS.md