Forum
Gus, te puedo asegurar que si "mi trabajo" fuera abrir candados de moto no me iba a hacer falta venir a buscarlo aqui... 😉
Cierto, pero no es cuestión de ponerlo tan fácil para que cualquier tuercebotas pueda arrancar nuestros coches.
Bueno, este post tal vez termine siendo muy interesante. Tengo que aclarar varios temas, el primero es que ni puedo ni debo mandar información a nadie de como se elimina el inmovilizador de forma permanente en una ecu de TD5. Por ello no le he mandado ningún dato al respecto a Garmen, excepto lo que aquí se ha dicho. Por los motivos que sean esta mañana le he llamado y se lo he explicado, el simplemente ha dicho, "ah vale, lo imaginaba". Luego ha dicho que como el es más partidario del "open source" que de lo contrario, va a seguir trabajando en destripar el td5 y lo irá publicando en el foro. Yo también pienso como él y así creo que lo hemos demostrado hasta ahora. Lo que aquí he comentado son cosas que había descubierto por mis propios medios, la información super valiosa que me fue confiada por otros no la publicaré.
Aclarado todo esto, hoy hemos estado Garmen y yo casi todo el día en contacto comentando temas. a este tío le funciona la cabeza muy bien, y no va a parar hasta dar con todo.
Luego lo comentará pero ya ha conseguido emular la señal de la famosa patilla y ha hecho arrancar su coche sin señal de la alarma. Visto esto me he puesto a investigar un poco los códigos que maneja la alarma y la ECU motor. Yo tengo mucha mas info que él, por tanto voy un paso por delante.
La flash del pic no es de 1k es del 512bites, eso lo primero. Creo que este PIC es el encargado de manejar la inyección del coche, pero no estoy seguro. En ese pic se almacenan también los datos de los inyectores, ya que copie el contenido de otro pic y me cambió toda la configuración de la ECU.
Otro dato, no es el código EKA el que transmite la 10AS a la ECU, el EKA es un código de desbloqueo de la alarma, no el código de comunicación con la ECU. Cada ECU tiene su propio protocolo de inmovilizador, en el caso del td5 es el MEMS-td5, y por ejemplo el PUMA trabaja con GEMS.
El protocolo de comunicación no tiene porque ser standard y eso le tiene un poco liado a Garmen. He cambiado el código MEMs en mi alarma y el coche no arranca, y sin embargo todo el resto de la alarma si va, por eso se confirma el dato de que es el mems el código correcto.
Como tengo el contenido de la flash del PIC he buscado el código mems dentro y evidentemente no lo he encontrado, ya que andamos buscando de otra manera. Viendo el número del código mems se podría deducir que entra dentro de los límites de un binario de base 16, el mío en concreto es un cuarenta y nueve mil. He pasado mi número a binario y lo he buscado en la flash, y ¡premio!, aparece repetido 3 veces en la parte baja de la misma.
Mañana Garmen imagino que tratara de buscar su código en la cadena que ha leído y localizar los 16 bits eliminando el resto del protocolo, tal vez bit de start y stop. Es posible que el código esté repetido, ya nos lo confirmará.
Con todo esto, anular el inmovilizador dentro de la ECU es un simple pasito de prueba y error.
El siguiente paso es sencillo, cambiar el código mems de la alarma, activar la rutina de aprendizaje del código de alarma en la ECU motor, leer el contenido del PIC y observar. El resto es muy sencillo.
Buenas noches a todos, o buenos días, que ya pronto saldrá el sol.
Gus ya ha comentado gran parte de lo que he hecho, pero voy a ilustrar y explicar cómo se hace ingeniería inversa de verdad.
Estas dos imágenes son las que he tomado con un osciloscopio digital moderno, el de ayer es muy bueno pero para otras cosas. Este tiene mas memoria, para almacenar mas tiempo. capturas de la misma línea B37, por alguna razón ayer la lié y me aparecía la lógica al revés ??? ??? ???

En esta se aprecia como el patrón se repite:

Con paciencia y utilizando el zoom, se sacan los valores de los bits.
La primera línea es la cadena de bits tal cual la he transcrito, la segunda es la primera con los 1 del principio quitados y terminada donde se repite y la tercera es la misma que la segunda desplazada para compararla con la primera y confirmar que se repite. Las XXXXX en si son dígitos, que no me apetece publicar.
111111111111111011101001100XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX0101010101011011101001100XXXXXXXXXXXXXXXXXXXXXXXXXXXXX 011101001100XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX0101010101011 011101001100XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX0101010101011
Por tanto es lógica inversa, ya que al principio está a uno, aunque por ahora no da igual, ya que lo único que vamos a hacer es replicar la señal, sin importarnos lo que signifique.
Para hacer esto, he utilizado un Arduino. Porqué? Pues porque lo tenía a mano y es rápido y sucio. No me he preocupado demasiado del timing, ya que a 250 baudios, y el micro corriendo a 16 MHz, no me preocupa que la rutinas del Arduino no estén optimizadas.
He aquí el circuito, en formato Arduino. Básicamente se utiliza el transistor como inversor y como amplificador a 12 Voltios. Me ha costado mas tiempo dibujarlo que hacerlo:

Código para el chisme, no es elegante el uso del string, pero no tenía ganas de pensar:
byte out = 4;
char data[ ] = "011101001100XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX0101010101011";
// the setup routine runs once when you press reset:
void setup() {
// initialize the digital pin as an output.
pinMode(out, OUTPUT);
}
// the loop routine runs over and over again forever:
void loop()
{
byte i = 0;
while (i<72)
{
if (data=='0')
{
digitalWrite(out, HIGH);
}
else
{
digitalWrite(out, LOW);
}
i=i+1;
delay(4);
}
}
Ya montado:

Funciona!!!!!

En el 110:

Empalme al B37:

Vídeo del sistema funcionando:
He tardado casi mas tiempo escribiendo el post que haciendo la ñapa en cuestión 😀 😀 😀
Muy sesudo el código, hihi. ¿el delay 4 lo has sacado a base de prueba y error midiendo con el analizador, o lo has calculado?.
Bueno, hoy es día de pensar, aparte de que tengo pocas ganas de cacharrear.
Muy sesudo el código, hihi. ¿el delay 4 lo has sacado a base de prueba y error midiendo con el analizador, o lo has calculado?.
El delay, es de 4ms, aparecía en el código del Link 1, pero lo confirmé midiendo la señal. El protocolo trabaja a 250 baudios, por tanto 1s/250 = 4ms. Debería de haber calculado, cuanto tarda el DigitalWrite y la comparación de 1y 0 y el del while, pero los he ignorado. No los he ignorado, he decidio, que no merece la pena ternerlos en cuenta:
Link 4: https://billgrundmann.wordpress.com/2009/03/03/to-use-or-not-use-writedigital
No creo que los 3,3 uS de la desastrosa rutina del DigitalWrite me afecten demasiado, comparando con los 4000uS del largo det bit.
Ayer era demasiado tarde como para razonar y responder a lo que dijo Gus, ahora le doy a eso.
Quiero entender el Td5, punto pelota. Y quiero que sea tan fiable como mi 88 2.25 Diesel. Dado que no hay ningún manual de como funcione de verdad la electrónica del Td5, me veo en la necesidad de descubrirlo. Y ya de paso intentar explicarlo a los demás.
El día de ayer fue muy fructifero como bien dijo Gus. Le hemos dado varias vueltas a bastantes cosas, y pinta que la cosa va bien. Pinta tan bien, que incluso veo factible hacer una ECU desde 0, cosa que no creo que haga, pero puede llegar a ser posible.
El descifrado del código del B37, queda condicionado a que por lo menos sepa mi MEMS. No creo que sea posible atacar este problema de mientras. Lo ideal es cambial los valores del MEMS en la AS10 e ir comparandolo con la señal B37.
Conclusiones varias:
El MSB creo que puedo hacerlo prgramable, cambiando la flash y sacando unos cables de la centralita, utilizando pines que no se utilizan. Se trata de utilizar el BDM, que permite controlar el Motorola paso a paso.
Link5:
Este mismo mod puede mandar al carajo la necesidad de tener un Nanocom, incluso en las NNN.
Necesito una pareja de ECU y AS10 para andar haciendo ñapas y cambiando valores e investigando. Evidentemente, no voy a dejar mi Td5 que no arranque mientras hago pruebas. Aunque en teoría ya puedo mandar a la mierda mi AS10, que puedo arrancar el coche con el emulador. Tegno que entender como mete el MEMS en los 72 bits que manda el AS10 a la ECU.
Veo sencillo fabricar un emulador de AS10, con un micro AtTiny, que sirva para leer el código de B37, que lo guarde, y que sirva para emularlo. Sin ordenador, ni configuraciones: Pinzar el cable, darle a un botón del emulador, darle al contacto y ya está el emulador configurado. Cabe decir que se necesita que el coche este en modo de arrancar para hacer la lectura.
Cuando tenga otra ECU, voy a investigar como reprogramar el PIC que va dentro de la ECU, para que se salte la necesidad de leer el MEMS que le manda el AS10.
Haré una lista de como hacer innarrancable el Td5 para ladrones, evidentemente la lista no será completa 😉 No voy a publicar como haré para hacer mi coche innarrancable.
Buenas tardes a todos.
A ver, por partes.
Te has obsesionado con la alarma y la realidad es que la alarma falla muy poco o casi nada. A mi solo me falló una vez después de un vadeo en el que el agua entró a chorro por el tablero de instrumentos, el coche anduvo bien hasta que lo paré y luego no arrancaba. Usando el código EKA conseguí hacerlo andar, es posible que fuese un fallo del módulo RF.
Lo de que tu td5 sea inarrancable ya veremos, si voy con mi ECU de emergencia, te aseguro que arranco, a no ser que me cortes los cables del CKP, de la bomba o de cualquier otra cosa determinante.
Otro tema, si quieres que tu coche sea fiable, no andes cortando cables, y menos en la zona de la ECU que es muy sumergible. Todos esos empalmes al final terminan fallando, y eso que todos los sensores del td5 son analógicos y más que menos admiten mejor los fallos, pero por ejemplo el puma ya tiene varios sensores PWM que a la mínima se vuelven tontos.
Los cables del CKP, sensor de cigüeñal, tiene un cableado apantallado a masa, eso es fundamental para el funcionamiento del coche. El CKP es un sensor inductivo que de ve en cuando mete ruido y la ECU no solo lo nota si no que lo registra como error. Algunos han dañado esa pantalla y el coche no arranca, y no registra error.
Necesitaras un nanocom o un tester de ODB II. Yo te recomendaría un nanocom antiguo con USB o con serie incluso. El nuevo es muy caro y está capado para flasear ecus, y el resto de cosas te lo hace un tester de 125 euros, excepto escribir configuraciones y probar outputs que para eso necesitas el nanocom o una máquina de unos cuantos más euros. Los firmwares nuevos de nanocom antiguos también estaban capados para leer y escribir mapas, pero es muy fácil de saltar esa protección.
Lo de escribir por BDM está muy bien, pero es poco operativo, es mejor pillar una NNN y escribir por OBD como dios Manda. Yo hace muchos años conocí a un portugues con el que también aprendí un guevo que andaba con el coche con un emulador de Eprom enchufado al zócalo de una MSB y un PC en tiempo real emulando la eprom!, eso es la bomba, puedes cambiar parámetros en tiempo real y monitorizar la activad del procesador.
Busca un emulador de 29f200 y tendrás la llave para casi todo, si sabes código máquina de motorola.
Rectifico:
No es un PIC donde se almacena el código de alarma y la configuración de inyectores, es una simple eprom serie flash de 4k bits. Es que he ido a leerlo y me he dado cuenta del error, el pic de la inyección es otro.
El emulador de Flash, no encuentro ninguno a precio asequible, tal vez me fabrique uno, con una dual-ported Ram.
A lo del BDM le veo cada vez mas sentido, entre otros que permitirá convertir ECUs normales a non-robust, haciendo innecesaria la ñapa del PIC.
Gus, tu tranquilo, que se me ha ocurrido un antirrobo muy bueno ;D ;D
Gracias por la info del CKP, no sabía que fuese apantallado. No cables se quedarán estañados y les voy a dar cinta aislante líquida, con eso creo que me curaré en salud.
Estoy a la espera de material, cuando me llegue ya publicaré progresos. El Nanocom, me he apuntado a la compra conjunta de Euskadi, ya que en Ebay no he encontrado ninguno de los viejos. La verdad es que me da igual que sea por puerto de serie.
Me he obsesionado con la alarma, porque me ha parecido el modo mas sencillo de bypassear el inmobilizador, es un método poco elegante, pero funciona y es fácil y barato. El objetivo no es quedarme ahí, es meterle mano pero que bien.
P.D.: No se si a la gente no le interesa, está acojonada, le da miedo o no entiende lo que estoy haciendo ;D ;D ;D Sea como fuere, creo que de este post van a salir cosas interesantísimas.
Interesa, interesa... lo que pasa es que al tener poco que aportar nos callamos y aprendemos. 😉
Yo mas bien acojonado, pero tu y Gus por favor seguid que estoy que flipo con el nivelazo de vuestro debate. 😮 😮 😮
Creo que solo estoy absorbiendo el 5% de lo que decís, pero algo es algo y menos es ná! ;D ;D ;D
Esto es lo que estás buscando.
Desde aquí solo lees la flash al completo. En el caso de las MSB no permite escritura.
La eprom tampoco permite lectura con conectores tipo pomona.

Y dentro de poco pondrán una foto del condensador de flujo...
Anonadao me quedao, como Gringo viejo, leo, entiendo poco y el resto me lo imagino ::)::)
Un saludo
El emulador de Flash, no encuentro ninguno a precio asequible, tal vez me fabrique uno, con una dual-ported Ram.
A lo del BDM le veo cada vez mas sentido, entre otros que permitirá convertir ECUs normales a non-robust, haciendo innecesaria la ñapa del PIC.
Gus, tu tranquilo, que se me ha ocurrido un antirrobo muy bueno ;D ;D
Gracias por la info del CKP, no sabía que fuese apantallado. No cables se quedarán estañados y les voy a dar cinta aislante líquida, con eso creo que me curaré en salud.
Estoy a la espera de material, cuando me llegue ya publicaré progresos. El Nanocom, me he apuntado a la compra conjunta de Euskadi, ya que en Ebay no he encontrado ninguno de los viejos. La verdad es que me da igual que sea por puerto de serie.
Me he obsesionado con la alarma, porque me ha parecido el modo mas sencillo de bypassear el inmobilizador, es un método poco elegante, pero funciona y es fácil y barato. El objetivo no es quedarme ahí, es meterle mano pero que bien.
P.D.: No se si a la gente no le interesa, está acojonada, le da miedo o no entiende lo que estoy haciendo ;D ;D ;D Sea como fuere, creo que de este post van a salir cosas interesantísimas.
Que no es un pic, es una eprom.
Te queda mucho por descubrir todavía, empiezas desde abajo, pero vas rápido. No creo que puedas escribir la flash de una msb por bdm, te faltará hardware y no te va a merecer la pena, y seguirás teniendo una msb cuyo firmware es mucho más limitado que el de las NNN, así como los mapas de fuel.
No vas a poder convertir la ECU a robust tan solo programando las flash principal, por seguridad el tema del inmovilizador no lo controla el firmware de la ecu, el pic de inyección es el que decide en función de lo que hay en la eprom de 4k y lo que manda la alarma. Eso mismo me pasó a mi hace años, leí la eprom completa de una ecu a la que se le había eliminado el inmovilizador creyendo que encontraría la clave del asunto y me lleve un chasco cuando comprobé que allí no había nada cambiado con respecto a una ecu de serie. De todos modos inténtalo que lo mismo estoy yo equivocado.
Vas a terminar por ñapear la eprom, ya lo verás.
Un buen sistema para que no te robe el coche es quitar el volante como hacía mr. bean, o soldar la polea del cigueñal al bloque motor, el resto si no tocas el cableado voy con mi ecu y te arranco el coche. Pero vamos que el mejor antirobo es un interruptor en el ckp y ya está, no da error al leer los DTC y el coche no arranca ni de coña.
Ya verás cuando empieces a explorar el contenido de la flash, a mi me falta mucha info y herramientas, no he querido gastar dinero en comprar información, me niego y todo lo he ido deduciendo o me lo han filtrado, sobre todo Oscar que es el que más conoce de esto.
Lo ideal sería dar con las fuentes de la ecu, allí tendríamos todo para cambiar, pero no hay forma de que salgan de la fábrica. Tal vez cuando pasen años se empiecen a filtrar para poder ñapear sin ingeniería inversa.

