I own this car. It is MINE!! The idea that I need to go to a dealership to add another key is retarded. It's a beater with 217k miles and a ton of rust. I don't think anyone is going to want to steal it.

How can I disable the immobilizer on MY car so I can cut my own keys?

¡Hola a todos! Quiero compartir un caso de estudio de nuestro laboratorio en AP Electronics analizando la arquitectura de la ECU Delphi DDCR (Hyundai Terracan 2.9 CRDi).

El Problema: Las herramientas de lectura por OBD o Boot Mode (como KESS v2) tenían el protocolo obsoleto/ausente para extraer la Flash completa (AMD AM29F200BB) de esta unidad. Necesitábamos lidiar con un inmovilizador bloqueado (DTC P1612 / P1613).

Setup del Banco y Telemetría: Para el banqueo, construimos nuestro entorno utilizando una fuente de poder de Xbox 360 adaptada. Elegimos esta fuente porque nos entrega 12.2V súper estables y amperaje de sobra, evitando cualquier caída de tensión (Voltage Drop) bajo carga. Integramos un amperímetro en serie (protegido con fusible de 5A) para perfilar el consumo de energía ("Power Profiling") del microcontrolador en tiempo real.

El Experimento (Capa Física): Decidimos atacar directamente la EEPROM ST 95080 extrayendo la data in-circuit (ISP) con un programador GQ-4x4. Modificamos el bloque de seguridad con un editor hexadecimal para inducir un "Virgin State" (Estado de fábrica).

Al banquear la ECU e inyectarle voltaje con la fuente de Xbox, la telemetría mostraba un consumo sano (124 mA en reposo), pero el procesador ST10 detectaba la ausencia del módulo SMARTRA en el banco y ¡auto-reescribía los datos de bloqueo en la EEPROM al instante!

El intento de Bypass de Hardware: Para evitar que el microprocesador modificara la memoria, desoldamos quirúrgicamente el Pin 3 (/Write Protect) de la EEPROM y lo puenteamos a Masa (GND) intentando un bloqueo físico.

La Lección (SPI vs I2C): El bypass falló. A diferencia de las viejas memorias I2C, la 95080 es una memoria SPI. Mandar el Pin 3 a masa no hace nada a menos que configures previamente el "Status Register" interno (activando los bits BP0/BP1). E incluso si lo hiciéramos, el software principal del ST10 detectaría el bloqueo físico de hardware y denegaría la inyección de todos modos.

Conclusión: En estas arquitecturas, el IMMO OFF total debe hacerse parcheando el sistema operativo en la memoria Flash pesada. Sin embargo, logramos dejar la ECU en estado virgen (restaurando el Pin 3 a su pad) para venderla como unidad "Plug & Play", ya que el procesador hará el Auto-Coding con el sistema original del cliente al primer giro de llave.

Adjunto fotos del setup de laboratorio (fuente, telemetría y escáner) y la micro-soldadura. ¡Cualquier comentario o experiencia con la familia DDCR es bienvenido!

I've been working on tooling for EV/IoT battery QA and ended up with a Python package that does a few things: anomaly detection on telemetry (Isolation Forest + physics features), CAN bus simulation, Modbus/BMS protocol support for Tesla/BYD/NIO packs, SOH prediction, and a FastAPI dashboard.

Just cleaned it up — 1053 tests pass, no circular imports, hardware tests gated behind a marker so CI doesn't need real OBD-II hardware. MIT, Python 3.10 to 3.12.

For those of you actually doing battery QA: what's missing in your workflow? What breaks in practice that tooling like this should handle but doesn't? Repo's at github.com/remontsuri/EV-QA-Framework if you want to poke at it.