DeviceUniqueID

Nav3, nav4 y nav5 no tienen ID unique, se activan los mapas con el numero de serie. Uconnect parece que es lo mismo por un lado y por otro parece que se asocia al VIN.
Para activar el mapa a tu equipo sería muy simple pero para que funcione el mapa tendría que tener un navcore parcheado y ahí es donde está el problema para uconnect.

Generar un parche para un tipo de dispositivo requiere un desarrollo sobre una o varias unidades. En el camino de desarrollo para nav3, nav4 y nav5 han caído varios equipos en la "batalla" que dieron su vida por el bien de la ciencia.


Mire esta imagen en la que puede ver como se han desoldado los componentes de esa unidad, que ha quedado inservible, pero que se obtuvieron los datos necesarios.




En pocas palabras, tu mapa activado no funcionaría sino parcheas el navcore.
Ademas uconnect parece que activa los mapas de manera diferente a meta > numero serie = meta.dct

Se ha visto que algunas activaciones se generan supeditadas al Vin del vehículo, puede que utilice los dos tipos de activación indistintamente o que utilice una activación universal mediante contraseña  que sea proporcionada por el servidor tras el pago asociado a su vin.

El equipo MSTMS ha realizado algunas pruebas al respecto de uconnect, pero la dificultad de ser un dispositivo asociado a un vehículo, hace que no se disponga de unidades para desensamblar y analizar, me consta que se han visto varios aspectos porque lo que yo le comento aquí es lo que he aprendido de MSTMS en esa investigación.

Desde el desconocimiento, y trabajando a la inversa? es decir, yo no tengo ni idea y perdona si digo una barbaridad, de la web nos descargamos el archico de mapas y la licencia ya "casado" con nuestro coche, yo tengo pero ya caducado.
Bien, trabajando con ello, yo he obtenido un mapa y una licencia de otro coche que tiene en vigor la suscripcion (me lo ha pasado en un usb) ahí no se podria modificar sin necesidad de recurrir al hardware?
Es decir, se pueden los archivos que descargamos y modificarlos con nuestro vin o cabecera de los que tenemos viejos?

gracias!

Le voy a pegar el contenido de uno de los mensajes que se mencionaron en el trascurso de la investigación, si usted quiere puede probar a modificar el archivo "packageinfo.xml" como comenta el compañero..., pero dudo que funcione. Si su equipo lleva tiempo sin actualizar quizá esté sin protección de copia pero como le indico lo dudo mucho.

No se lo que usted tiene en el usb pero puede ser algo similar a lo que se ve en este mensaje.
Esto solo va aportar que usted vea lo que ya se ha intentado para que no pierda el tiempo en lo mismo, quizá esto le sirva para iniciar otro camino.
Recuerde que este texto lo he traducido del que un miembro del equipo MSTMS expuso y puede tener errores de traducción.

Lamento las malas noticias, pero creo que no puede modificar esos archivos de actualización:
 estas actualizaciones, como las de nav3, nav4, nav5 están protegidas con firma.
 
 Como dijimos, para extraer el contenido, simplemente cambie el nombre del archivo a .z04, o, como acabo de probar, cambie el nombre del ttmpkg a .zip: 7zip no le dará un mensaje de error.
       
 
    
 
 Una vez que se extrae el contenido, verá 2 archivos: files.chk y files.sig
       
 
    
 
 files.chk contiene la lista de todos los archivos del archivo de actualización, excepto files.chk y files.sig:

    
 
 La parte derecha del contenido son datos codificados en base64 (creo), y da un hash (creo que SHA1) del archivo en la parte izquierda.
 Entonces, el "files.sig" es un archivo firmado con la clave privada RSA secreta de Tomtom: solo distribuyen la clave pública en el sistema de navegación del automóvil.
 
 Entonces, cuando hay una actualización (esto es así en nav3, nav4 y nav5, así que creo que es lo mismo aquí):
 - el sistema primero descomprime el contenido,
 - luego busca "files.chk",
 - para cada línea en este archivo comprueba que el hash de cada archivo sea correcto,
 - comprueba que no haya ningún archivo adicional o faltante,
 - y finalmente comprueba la firma de "files.sig"
 
 Estoy de acuerdo con usted, en la nueva versión han introducido la bandera "copy_protection" ahora configurada en "durham_certificate" donde estaba configurada como "none" en este archivo "packageinfo.xml", y creo que es responsable del problema que usted vea: puede colocar este mapa solo donde tenga un archivo de licencia válido (.dct).
 
 por lo general, el archivo dct se crea usando META del mapa, meta nombre, certificado de clave privada y número de serie del dispositivo.
 Bueno, aquí tenemos el meta nombre (Europe-102889.meta), el número de serie del dispositivo (es posible que lo sepa), podemos adivinar META sabiendo los 2 primeros, pero no tenemos el certificado: no podemos generar un archivo. dct.
 Este es el mismo problema con nav *: tenemos que piratear las bibliotecas o el programa para inyectar nuestro propio certificado para que parezca legítimo.
 
 Entonces, para mí, a menos que puedas encontrar la clave privada de Tomtom, creo que es inútil intentar jugar con esos archivos de actualizaciones ...
 
 Este es otro sistema para ser pirateado
 *** Tal vez *** la verificación solo se basa en esto " packageinfo.xml ", por lo que un truco sería por ejemplo leer la memoria interna del dispositivo y modificar este archivo y poner" none "en lugar de" durham_certificate ", si no es difícil hacerlo ...
 Otra posibilidad, sería sea ​​degradar el sistema de navegación del automóvil: ¿tal vez hayan introducido esta función de "protección contra copia" recientemente?
 De lo contrario, tendrá que pasar horas como lo hicimos nosotros tratando de encontrar una brecha en alguna parte.