yo soy estudiante de FP DAM y entiendo lo que me dices ( aunque no tengo el nivel todavía para asimilar muchas cosas). En mi cabeza estoy pensando una cosa: Si se programa en C,C++ o lo que sea, y se compila posteriormente, no puede sacarse directamente el programa precompilado para no tener que trabajar en binario? es a lo que te refieres con el trabajo de reversing que mencionas?.
Partiendo de esa base,alguien que sepa de programacion debe de ser tarea muy sencilla sacar ese mapa/programa. LO dificil imagino que sera saber ajustar los valores y toda la historia automovilistica que hay de atras
Pero, como digo, hablo desde lo que se me pasa por la cabeza y desde mi dulce ignorancia...
Un saludo
Para nada, en los lenguajes compilados como C, C++, Rust, y otros, el código fuente una vez pasa por el compilador y el linker lo que hace es generar "código nuevo" en lenguaje máquina específico para la arquitectura de procesador que hayas especificado, en el caso que nos atiende sería para la CPU que lleve la ECU, para que nos entendamos.
El código fuente, lo que tiene sentido para nuestras cabezas, nunca sale del ordenador del programador del software original, de hecho suelen ser recursos muy bien guardados por las empresas.
Entonces como la gente de Bosch no está por la labor de darnos su código fuente para sus ECUs pues tenemos que apañarnos con los binarios.
La problemática viene de que el binario no suele generarse de forma ortodoxa y consistente con la estructura del código fuente que nosotros programamos, porque el proceso de compilación no transforma literalmente nuestras ordenes del código C a binario, sino que lo optimiza, reorganiza, genera estructuras especiales a partir de lo que detecta en nuestro código, vamos, que lo mezcla todo y lo ultra optimiza y esto de forma específica teniendo en cuenta la arquitectura especial del procesador destino.
Por lo que conseguimos en el binario realmente es una sopa de ordenes en ensamblador muy compleja de la que más allá de poder sacar una estructura de bloques básica por el estándar organizativo del ejecutable en sí, no se puede sacar nada más en claro de forma intuitiva.
De hecho es el mismo proceso el que se sigue para crear los cracks de los juego o programas varios, editar archivos ejecutables binarios para saltarse protecciones o editar datos específicos que modifiquen su comportamiento original se asemeja más a un arte que a una ciencia.
En el caso de lo mapas de las ECUs, como no queremos modificar el flujo original del programa sino los datos que usan para los cálculos solo necesitamos buscarlos en el bloque de datos del binario y darle sentido a los trozos de este bloque en especial. Aquí es donde entra el WinOLS y donde se nota su brillo, ya que este programa tiene sistemas muy avanzados de detección de lo que para el WinOLS ve como tablas, donde empiezan y acaban listas, los tipos de dato y longitudes, etc. ahorrando muchísimo trabajo a los editores de estos mapas que solo tienen digamos que "afinar" y filtrar lo que el WinOLS detecta, eliminar los falsos positivos que detecte el programa, y ajustar los datos, alineaciones etc de lo que si sea una tabla mas o menos bien detectada.
Esto puede parecer sencillo, pero en realidad es tremendamente complejo, ya que lo único que te ayuda a detectar estas estructuras, incluso con la ayuda de WinOLS es la experiencia propia, y si a esto le añadimos que un fallo en una alineación, en un bit fuera de sitio, no solo puede matar la ECU en sí, sino destrozar el motor entero de un coche, pues es algo que cuesta aprender mucho.