Desprotección DRM de mapas y tarjeta SD

JKD

JKD

Forero Experto
Motor TL
2.0 CRDi 136 CV
Versión TL
Tecno Aut. 4x4
Color TL
Thunder Gray
Bueno gente, a tenor de un post en el que se da un truco para usar mapas de navegación descargados de internet instalados en la SD oficial me he puesto manos a la obra para averiguar cómo funciona nuestro software en el campo de la protección de los mapas. Voy a dividir este tema en dos posts consecutivos en este mismo hilo. El siguiente post será un poco más técnico pero puede que sirva de interés para alguien con la curiosidad suficiente.

Hasta abril de 2016 teníamos dos limitaciones con los mapas. En primer lugar, no era posible hacer una copia de las tarjetas oficiales y funcionar con ellas. Tampoco era posible descargar mapas y usarlos sin más, dependiendo de Hyundai para este cometido con el desembolso correspondiente que puede conllevar a los que no dispongan de actualizaciones gratuitas. En marzo o abril de 2016 se empezó a entregar una versión actualizada de los mapas. Esta versión ya permite realizar una copia de la tarjeta SD funcional. Pero la instalación de nuevas versiones descargadas de internet han sido un tema imposible hasta que ha salido a la luz el truco antes mencionado. Este truco, revela el nexo de unión que hay entre los mapas instalados y la tarjeta SD. Ahora bien, aunque las dos limitaciones más importantes parecen estar superadas, una futura actualización de mapas podría dejarnos de nuevo sin posibilidad de clonar la tarjeta SD (Campaña 60CC07).

Las limitaciones vienen impuestas por un programa del navegador llamado LgeDRMKey y puede encontrarse en la ruta "\storage card\SYSTEM\LgeDRMKey.exe". Es el que se encarga de decidir si la tarjeta SD que metemos en el navegador contiene unos mapas válidos y originales. Anteriormente, se ha discutido sobre la posibilidad de clonar la tarjeta SD de los mapas y la dificultad de saltarse la protección que lleva la SD. Para ver cómo afrontar ese problema tenemos que ver qué hace el software para dar por válidos los mapas. Estos son a grandes rasgos los pasos que se siguen para verificar que los mapas son válidos:

  1. Existencia de tarjeta SD en el lector: Esto es obvio y no necesita explicación. ¿O sí? :whistling:

  2. Existencia de AMK.LMF : Explicaré este punto más adelante.

  3. Existencia de la ID del navegador: Cada navegador lleva asociada una ID. Esta ID se puede localizar en la ruta "\USER\System\Data\LISA\DeviceID.txt". El programa trata de leer la ID de ese archivo hasta tres veces esperando 500 milisegundos entre intento e intento. Así que es de esperar que otro proceso se encarga de crear el archivo DeviceID.txt si este no existiera. Si al tercer intento no ha conseguido leer la ID, NO da por válidos los mapas.

  4. Cotejar ID de la tarjeta SD con archivo LMV.LMF: Este punto nos lo detalló un compañero de Rusia y es posible sortear esta protección igualando el valor de PrivateBuild de un nuevo archivo LMV.LMF al que teníamos originalmente, para que coincida con la ID de nuestra tarjeta. El programa lee la ID de LMV.LMF, toma la ID de la SD (leyendo del dispositivo "SDC1:") y coteja ambos valores. Si coinciden, los mapas son válidos. En realidad es un poco más elaborado pero se explica en el siguiente post.

  5. Comprobación de "MnSoft DRM": Este sistema lo llama así el programa. A este punto llega independientemente del resultado del punto 4 y necesita de la existencia de tres archivos:

    - \SDMemory\LGENavi\TDP\AUTHKEY.inf
    - \SDMemory\LGENavi\TDP\MAPMODULE.bin
    - \SDMemory\LGENavi\LIMF\LMV.LMF

    La actualización de abril incluye AUTHKEY.inf por defecto así que es posible la copia de la SD. Bueno, en realidad no es cierto que permita la copia de la SD. Este chequeo comprueba si hay permiso para usar estos mapas. Si es posible la copia de datos es porque hay autorización a usar los mapas aunque el punto 4 falle, que es el que realmente verifica si la SD es original.

El programa comprueba los 5 puntos. Si cualquiera de los puntos 4 y 5 son válidos (con uno de los dos vale) dará por válidos los mapas y permitirá utilizarlos.

Sabiendo lo que sabemos hasta ahora podríamos detenernos aquí ya que somos capaces de clonar la SD y de hacer trucos para habilitar mapas descargados pero... ¿No sería mejor que en vez de usar trucos y ediciones con editores hexadecimales ... evitar cualquier tipo de comprobación? :)

Pues sí. Hay una forma de evitar que el programa realice estos chequeos sin alterar el ejecutable. En el punto 2 el programa busca el archivo "\LGENavi\LIMF\AMK.LMF" en la SD. Ese archivo es una llave, una forma de decir al programa "Ignora todas las comprobaciones y da por buenos los mapas, la tarjeta y el navegador". Si no lo encuentra o si su contenido no es el esperado pasa al tercer punto.

El archivo AMK.LMF debe tener un contenido concreto. Por lo que veo, el programa está preparado para aceptar uno de dos posibles contenidos en función de si una variable determinada contiene un 0 o un 1. Indico el contenido que debe tener el archivo AMK.LMF para cada caso:

  • Variable a cero:
"Its nine o clock on a Saturday\r\nThe regular crowd shuffles in\r\nTheres an old man sitting next to me\r\nMake in love to his tonic and gin\r\nHe says, Son, can you play me a melody?\r\nIm not really sure how it goes but its sad and its sweet\r\nAnd I knew it complete when I wore a younger mans clothes\r\nSing us a song, youre the piano man\r\nSing us a song tonight\r\nWell we re all in the mood for a melody\r\nAnd you ve got us feelin alright\r\nNow John at the bar is a friend of mine\r\nHe gets me my drinks for free\r\nAnd he s quick with a joke or to light up your smoke\r\nBut theres someplace that he d rather be\r\n"
Click para expandir ...

  • Variable a uno:
"It might appear possible to overcome all the difficulties attending the definition\r\nof 'time' by substituting 'the position of the small hand of my watch' for\r\n'time' And in fact such a definition is satisfactory when we are concerned with\r\ndefining a time exclusively for the place where the watch is located; but it is no\r\nlonger satisfactory when we have to connect in time series of events occurring\r\nat different places, or what comes to the same thing to evaluate the times of\r\nevents occurring at places remote from the watch."
Click para expandir ...

Adjunto las dos posibilidades en un archivo ZIP para evitar errores a la hora de crear dicho archivo. El contenido que debería tener con la dichosa variable a 0 se encuentra dentro de la carpeta \0 del ZIP. Y lo mismo con la carpeta \1. Basta con copiar el archivo adecuado en la SD en la carpeta "\LGENavi\LIMF\".

Puede que alguno se haya dado cuenta ya, de que ese archivo ya existe desde la actualización de abril en la tarjeta SD pero por lo visto algunos no lo tienen. El contenido de ese archivo corresponde a "\1\AMK.LMF". Lo he comprobado y efectivamente esa es la llave que espera nuestro navegador. Recomiendo hacer una copia de seguridad de la SD y hacer estas modificaciones en la copia.

Alguno se preguntará "Bueno si yo ya puedo hacer una copia de la SD que tengo ¿para qué hacer esto?" Puedes hacer una copia porque tienes los archivos que permiten superar el DRM MnSoft pero no significa que sea así con una nueva versión de los mapas o con mapas descargados de internet. Con el archivo AMK.LMF se evita toda comprobación. Y para más inri... sigue leyendo ;)


Campaña 60CC07

Con la actualización de los mapas allá por abril Hyundai cometió un error. Un lapsus en el que distribuyeron los mapas tanto con el archivo AUTHKEY.INF como con el archivo AMK.LMF. Con ello, entregaron los mapas desprotegidos permitiendo hacer copias utilizables por cualquiera sin pasar por el concesionario/taller/caja. Para solventarlo han sacado esta campaña. Oficialmente esta es la explicación:
  • Síntoma/Condición:
    En algunos vehículos Tucson (TLe) fabricados en la planta de República Checa, la unidad AVN podría no funcionar correctamente debido al bloqueo de la tarjeta SD relacionada con el problema de reconocimiento de mapas.
  • Medidas a tomar:
    Sustituya la tarjeta SD defectuosa según el procedimiento de mantenimiento suministrado en este boletín.
Aquí hay una incoherencia. Y es que si el problema es la SD, no tiene sentido entregar una SD nueva con una versión anterior de los mapas cinco o seis meses después de la última actualización. Y si el problema estuviera en los mapas, no tendría sentido sustituir la tarjeta SD con el coste que ello supone pudiendo reescribir su contenido como pasaría con una actualización normal. Además, si el problema está en hard o soft, o funciona o no funciona. Si en cinco o seis meses no ha habido problemas, no tendría por qué pasar nada que justifique instalar mapas de 2013 (versión 7.52.xxxxx) a estas alturas.

Así pues, la razón por la que están haciendo esta sustitución obedece más a un intento de retomar el control sobre los privilegios de uso de los mapas instalando rápido y mal, la versión que saben, está protegida (no cuenta con los archivos detallados aquí). Y lo están vendiendo como una medida de seguridad.

En cuanto a la mención "bloqueo de la tarjeta SD relacionada con el problema de reconocimiento de mapas", eso puede ser una declaración de intenciones. Esto es, el día de mañana, con una versión nueva de LgeDRMKey.exe, inhabilitar estos archivos "mágicos" con lo que las copias dejarían de funcionar. Pero eso ya será otra historia :)
 

Adjuntos

Última edición:
A continuación procedo a explicar un poco paso a paso los puntos de comprobación mencionados en el post anterior. Para ello vamos a utilizar código descompilado del programa LgeDRMKey.exe. Teniendo en cuenta que el software está programado en C++, el código generado es un pseudocódigo en C que no tiene por qué ser fiel a la programación real y parte del código de máquina de la arquitectura ARM por lo que podrían verse operaciones un tanto extrañas. Los nombres de las funciones y de las variables se han ido editando a medida que se desvelaba su funcionalidad y he añadido algunos comentarios (precedidos por // ) los cuales aparecen en color verde para tratar de hacer más comprensible el flujo del programa.

  • checkMaps:
    checkMaps.png
    Así he llamado a esta función que engloba los 5 puntos de control. Esta función devolverá un 0 o un 1. Si da por válidos los mapas devolverá un 1 y en cualquier otro caso un 0. Primero comprueba si existe la carpeta LGENavi en la tarjeta SD. Después, en función del valor de una variable a la que he llamado AMKKeyType (que en nuestro caso contiene el valor 1) busca el archivo AMK.LMF. Si existe da los mapas por buenos. Si no existe o su contenido no es correcto, pasa al siguiente punto en el que trata de leer la ID del navegador hasta en tres ocasiones. Si no lo consigue la función termina devolviendo 0 dando los mapas por no validos.

    A continuación realiza las comprobaciones 4 y 5 en la siguiente forma:
    Código: 
    if ( checkMapVer() || checkMnSoftDRM(&dword_176C8) ...
    Esto significa que no tienen por qué cumplirse los dos chequeos. Con que uno de los dos sea válido, los mapas también lo serán.
    De la función checkMnSoftDRM no puedo dar más datos ya que el depurador por alguna razón no ha localizado referencia al código pero es de esperar que entre otras cosas coteje la información del archivo AUTHKEY.inf. La función que me parece más interesante es checkMapVer que bueno, quizá no sea ese su nombre más apropiado pero es el encargado de la comprobación del punto 4 y lo detallo a continuación.

  • checkMapVer:
    checkMapVer.png
    En esta función podemos ver como toma dos valores que posteriormente va a cotejar. En primer lugar el valor del archivo LMV.LMF y posteriormente el valor que devuelve la ID de la tarjeta SD. Es un valor que forma parte de la ID de la tarjeta, no la ID en sí.
    Vamos a ver como pilla el valor de LMV.LMF.

  • getMapID:
    getMapID.png
    Vemos aquí que toma un valor del archivo LMV.LMF correspondiente al campo PrivateBuild. Son dos bytes con la representación hexadecimal de un ID. Dicha función devuelve el valor hexadecimal correspondiente. En nuestro caso, la función devolverá un 0x4b.

  • getSDCardID:
    getSDCardID.png
    Esta función es la más interesante ya que revela cómo identifica una tarjeta SD original. Primeramente encuentra la cID de la tarjeta SD.Partiremos de un ejemplo. En linux la id de una SD se puede leer fácilmente con un comando como este:

    Código: 
    cat /sys/block/mmcblk0/device/cid
134b474c47450000104400000000f901     <<< este es el cID de una SD original

    La cID de una SD está formada por 16 bytes con varios campos y casi todos ellos serán similares salvo los últimos dígitos que corresponden a la fecha de fabricación y a una suma de comprobación CRC. Estos campos, en nuestro ejemplo se pueden desglosar así:

    Código: 
    13 4b47 4c47450000 10 44000000 0 0f901

MID = 13           = Manufacturer ID       = 8 bits
OID = 4b47         = Application ID        = 16 bits  KG
PNM = 4c47450000   = Product name          = 40 bits  LGE
PRV = 10   = 1.0   = Product revision      = 8 bits
PSN = 44000000     = Product serial number = 32 bits
--- = 0 & 0x0f = 0 = reserved              = 4 bits
MDT (fecha) = 00f9 & 0x0fff= 0x0f9 -- m = 0xf9 & 0xf = 9 septiembre
                           -- yy = 0xf9 >> 4 = f = 15 + 2000 = 2015
CRC = (01 & 0xfe) >> 1 = 0 = CRC7 checksum = 7 bits
no usado, siempre 1 -> 01 & 1 = 1            = 1 bit

    Básicamente, esta función comprueba que el campo PNM sea 4c47450000 que corresponde al ASCII "LGE". Si esto es así, devuelve el segundo byte del cID que pertenece al campo OID y que en nuestro caso es 0x4b. Como podéis observar, aquí está el nexo de unión entre LMV.LMF y el cID de la tarjeta SD. De ahí que, el truco que notificó el compañero ruso consista en forzar en el campo PrivateBuild del archivo LMV el mismo valor que tiene la id de la SD en su segundo byte.

    CID.png

    Si alguno piensa que la directa es poner en LMV directamente el valor del segundo byte de la id de la tarjeta, que tenga en cuenta que no funcionará si el campo PNM (nombre del producto) no es exactamente "LGE" (4c47450000). Si el PNM es el correcto, la función devolverá 0x4b. Si no, -1. De momento no sé si existe alguna tarjeta SD que permita la reescritura de la ID. El truco del ruso funciona para tarjetas originales de Hyundai.

  • checkDevIDExists:
    checkDevIDexists.png
    Esta es la función encargada de localizar la ID del navegador y de comprobar si es correcta. No tiene mucho misterio. Localiza y abre DeviceID.txt. Luego comprueba que la ID es correcta. Por lo que pude apreciar, la ID puede tener una longitud de 1 a 12 bytes y la comprobación se basa en que la ID no puede estar compuesta sólo de ceros. No devuelve la ID del navegador. Si es correcta, devuelve un 1. Si no, un cero.

  • readAMKLMF1:
    readAMKLMF1.png
    Esta función es la encargada de detectar si existe AMK.LMF con un contenido determinado. Para ello, localiza AMK.LMF en LGENavi\LIMF\, lo abre, lee su contenido y después lo compara letra a letra con un patrón que ya hemos detallado en el post anterior. Si el contenido del archivo es similar, la función devolverá un 1 y los mapas serán válidos sin realizar ninguna otra comprobación.

¿AMK.LMF versión 0 o 1?

Mayoritariamente se usa la versión 1 cuyo contenido se muestra en el primer post. Pero ¿de qué depende que elija una u otra versión para cotejar su contenido?. Durante la inicialización de LgeDRMKey.exe, carga la librería CmnVersion.dll e importa la única función que tiene "GetCmnVersionInfo". Esta función devuelve una línea de texto de una tabla interna que consta de 6 posibles textos:
  • ID 2 : "V 12.11.07"
  • ID 3 : "V 12.11.07"
  • ID 4 : "20"
  • ID 5 : "RU"
  • ID 6 : "EU"
  • ID 7 : "SOP"
LgeDRMKey solicita a CmnVersion mediante GetCmnVersionInfo la cadena de texto cuya id es 7. En realidad el valor que solicita es 6 pero GetCmnVersionInfo suma 1 ya que no existe la ID 1. En este caso devuelve "SOP". Si la ID solicitada fuera 1 (que no es el caso), GetCmnVersionInfo toma la versión de software del registro de Windows. Concretamente de "HKEY_LOCAL_MACHINE\LGE\SystemInfo\VerSW". Si el resultado devuelto es "SOP", LgeDRMKey espera AMK.LMF versión 1, si no la 0.


Esto es todo por el momento. Como veis, no ha sido necesario alterar para nada el software de Hyundai. Esperemos que esta info pueda ser de utilidad para futuros análisis :thumbsup:


Nota para aquellos que posean el software de Hyundai antiguo (versión TL.EU.SOP.20.004 y anteriores)

Después de realizar unas comprobaciones con @Sandrovich en su versión de software podemos afirmar lo siguiente:
  • En el software antiguo, versión TL.EU.SOP.20.004 y anteriores, el truco del archivo AMK.LMF no funcionará puesto que su versión de LgeDRMKey.exe se limita a verificar que la SD es original.
  • El truco de modificar LMV.LMF para que unos mapas descargados funcionen en la tarjeta original funcionaría.
  • Para poder usar una tarjeta no original habría dos posibilidades. O bien parchear el ejecutable LgeDRMKey.exe de dicha versión o bien utilizar la última versión de dicho programa. Las pruebas demuestran que la última versión de LgeDRMKey es compatible hacia atrás por lo que, sustituyendo ese programa por el de la última versión, el truco del archivo AMK.LMF funcionará y permitirá el uso de SD no originales.
Así pues, adjunto el programa LgeDRMKey.exe de la última versión que tenemos para que aquellos que tengan las versiones antiguas puedan actualizarlo y disfrutar de esa "mejora". La instalación es tan sencilla como descomprimir el archivo en un pendrive, hacer una copia de "\storage card\SYSTEM\LgeDRMKey.exe" y sustituirlo por el del pendrive. Aunque todo esto se evita actualizando a la última versión en cualquier taller oficial. :)
 

Adjuntos

Última edición:
Pues todos aquellos, a los que les han cambiado la tarjeta por una nueva con la versión 7.xx deberían ir a quejarse por el cambio de tarjeta con unos mapas antiquísimos.
Creo que alguien está haciendo algo mal, no deberían cambiar la tarjeta después de actualizar el aparato, creo que deberían actualizar una vez han cambiado la tarjeta.
 
JKD dijo:
A continuación procedo a explicar un poco paso a paso los puntos de comprobación mencionados en el post anterior. Para ello vamos a utilizar código descompilado del programa LgeDRMKey.exe. Teniendo en cuenta que el software está programado en C++, el código generado es un pseudocódigo en C que no tiene por qué ser fiel a la programación real y parte del código de máquina de la arquitectura ARM por lo que podrían verse operaciones un tanto extrañas. Los nombres de las funciones y de las variables se han ido editando a medida que se desvelaba su funcionalidad y he añadido algunos comentarios (precedidos por // ) los cuales aparecen en color verde para tratar de hacer más comprensible el flujo del programa.

  • checkMaps:
    Ver el archivo adjunto 2858
    Así he llamado a esta función que engloba los 5 puntos de control. Esta función devolverá un 0 o un 1. Si da por válidos los mapas devolverá un 1 y en cualquier otro caso un 0. Primero comprueba si existe la carpeta LGENavi en la tarjeta SD. Después, en función del valor de una variable a la que he llamado AMKKeyType (que en nuestro caso contiene el valor 1) busca el archivo AMK.LMF. Si existe da los mapas por buenos. Si no existe o su contenido no es correcto, pasa al siguiente punto en el que trata de leer la ID del navegador hasta en tres ocasiones. Si no lo consigue la función termina devolviendo 0 dando los mapas por no validos.

    A continuación realiza las comprobaciones 4 y 5 en la siguiente forma:
    Código: 
    if ( checkMapVer() || checkMnSoftDRM(&dword_176C8) ...
    Esto significa que no tienen por qué cumplirse los dos chequeos. Con que uno de los dos sea válido, los mapas también lo serán.
    De la función checkMnSoftDRM no puedo dar más datos ya que el depurador por alguna razón no ha localizado referencia al código pero es de esperar que entre otras cosas coteje la información del archivo AUTHKEY.inf. La función que me parece más interesante es checkMapVer que bueno, quizá no sea ese su nombre más apropiado pero es el encargado de la comprobación del punto 4 y lo detallo a continuación.

  • checkMapVer:
    Ver el archivo adjunto 2859
    En esta función podemos ver como toma dos valores que posteriormente va a cotejar. En primer lugar el valor del archivo LMV.LMF y posteriormente el valor que devuelve la ID de la tarjeta SD. Es un valor que forma parte de la ID de la tarjeta, no la ID en sí.
    Vamos a ver como pilla el valor de LMV.LMF.

  • getMapID:
    Ver el archivo adjunto 2860
    Vemos aquí que toma un valor del archivo LMV.LMF correspondiente al campo PrivateBuild. Son dos bytes con la representación hexadecimal de un ID. Dicha función devuelve el valor hexadecimal correspondiente. En nuestro caso, la función devolverá un 0x4b.

  • getSDCardID:
    Ver el archivo adjunto 2861
    Esta función es la más interesante ya que revela cómo identifica una tarjeta SD original. Primeramente encuentra la cID de la tarjeta SD.Partiremos de un ejemplo. En linux la id de una SD se puede leer fácilmente con un comando como este:

    Código: 
    cat /sys/block/mmcblk0/device/cid
134b474c47450000104400000000f901     <<< este es el cID de una SD original

    La cID de una SD está formada por 16 bytes con varios campos y casi todos ellos serán similares salvo los últimos dígitos que corresponden a la fecha de fabricación y a una suma de comprobación CRC. Estos campos, en nuestro ejemplo se pueden desglosar así:

    Código: 
    13 4b47 4c47450000 10 44000000 0 0f901

MID = 13           = Manufacturer ID       = 8 bits
OID = 4b47         = Application ID        = 16 bits  KG
PNM = 4c47450000   = Product name          = 40 bits  LGE
PRV = 10   = 1.0   = Product revision      = 8 bits
PSN = 44000000     = Product serial number = 32 bits
--- = 0 & 0x0f = 0 = reserved              = 4 bits
MDT (fecha) = 00f9 & 0x0fff= 0x0f9 -- m = 0xf9 & 0xf = 9 septiembre
                           -- yy = 0xf9 >> 4 = f = 15 + 2000 = 2015
CRC = (01 & 0xfe) >> 1 = 0 = CRC7 checksum = 7 bits
no usado, siempre 1 -> 01 & 1 = 1            = 1 bit

    Básicamente, esta función comprueba que el campo PNM sea 4c47450000 que corresponde al ASCII "LGE". Si esto es así, devuelve el segundo byte del cID que pertenece al campo OID y que en nuestro caso es 0x4b. Como podéis observar, aquí está el nexo de unión entre LMV.LMF y el cID de la tarjeta SD. De ahí que, el truco que notificó el compañero ruso consista en forzar en el campo PrivateBuild del archivo LMV el mismo valor que tiene la id de la SD en su segundo byte.

    Ver el archivo adjunto 2862

    Si alguno piensa que la directa es poner en LMV directamente el valor del segundo byte de la id de la tarjeta, que tenga en cuenta que no funcionará si el campo PNM (nombre del producto) no es exactamente "LGE" (4c47450000). Si el PNM es el correcto, la función devolverá 0x4b. Si no, -1. De momento no sé si existe alguna tarjeta SD que permita la reescritura de la ID. El truco del ruso funciona para tarjetas originales de Hyundai.

  • checkDevIDExists:
    Ver el archivo adjunto 2863
    Esta es la función encargada de localizar la ID del navegador y de comprobar si es correcta. No tiene mucho misterio. Localiza y abre DeviceID.txt. Luego comprueba que la ID es correcta. Por lo que pude apreciar, la ID puede tener una longitud de 1 a 12 bytes y la comprobación se basa en que la ID no puede estar compuesta sólo de ceros. No devuelve la ID del navegador. Si es correcta, devuelve un 1. Si no, un cero.

  • readAMKLMF1:
    Ver el archivo adjunto 2864
    Esta función es la encargada de detectar si existe AMK.LMF con un contenido determinado. Para ello, localiza AMK.LMF en LGENavi\LIMF\, lo abre, lee su contenido y después lo compara letra a letra con un patrón que ya hemos detallado en el post anterior. Si el contenido del archivo es similar, la función devolverá un 1 y los mapas serán válidos sin realizar ninguna otra comprobación.
Esto es todo por el momento. Como veis, no ha sido necesario alterar para nada el software de Hyundai. Esperemos que esta info pueda ser de utilidad para futuros análisis :thumbsup:
Click para expandir ...

MOnstruo!!!! buen análisis!!!
 
Muy buen trabajo JKD,impresionante!!
 
Sinceramente estoy alucinando con el trabajo de la gente.

Yo personalmente no me he enterado de nada porq soy un zoquete en estas cosas pero aun así alucino con el nivel y el grado de entendimiento que tienen todos y cada uno de los miembros de este foro :thumbsup:.

He aprendido un huevo y la mitad del otro con todos vosotros. gracias. Aun así sigo siendo muy torpe, jejeej

ENHORABUENA!!!!!. Se puede decir mas alto pero no mas claro.
 
Buen aporte compañero pero yo soy zoquete mayor para todo eso...
Menos mal q devero me instalo el tucson player porque sino hubiese ardido mi navegador de lo torpe que soy...

Yo el lunes me han citado para la campaña gancho de capó...iba a pedir q me actualizaran pero, visto lo visto mejor que no...es más estoy por sacar la sd antes de dejarlo...por si acaso...
 
tate dijo:
Buen aporte compañero pero yo soy zoquete mayor para todo eso...
Menos mal q devero me instalo el tucson player porque sino hubiese ardido mi navegador de lo torpe que soy...

Yo el lunes me han citado para la campaña gancho de capó...iba a pedir q me actualizaran pero, visto lo visto mejor que no...es más estoy por sacar la sd antes de dejarlo...por si acaso...
Click para expandir ...
Hoy por hoy y a modo de resumen, si te bajas algún mapa de HERE (navteq) de internet, lo grabas en una tarjeta SD cualquiera y en la carpeta LGENavi\LIMF\ copias el archivo AMK.LMF los mapas funcionarán en el navegador de tu Tucson. Esa es básicamente toda la dificultad ;)
 
Jkd, estas abriendo la puerta a meter mapas actuales como los q se hablaron en otro post de mayo 2016 de la marca vw?

Saludos!
 
Connermc dijo:
Jkd, estas abriendo la puerta a meter mapas actuales como los q se hablaron en otro post de mayo 2016 de la marca vw?

Saludos!
Click para expandir ...
No conozco el tipo de mapas que integra vw pero si no son de HERE o no guardan la misma estructura de archivos nuestro navi no sabrá interpretarlos
 
Bueno, siento ser aguafiestas pero en mi navegador no ha funcionado.
Me he bajado el fichero de la variables a 1 que me pasó @JKD y lo he metido en una tarjeta normal SD con los mapas que pasó el compañero ruso, que son los últimos que hay disponibles.
Pues bien, sigue diciendo que la tarjeta no es compatible o algo así.

A ver si subo la versión que lleva mi navegador pero es la del verano 2015 sin actualizar.
 
Sandrovich dijo:
Bueno, siento ser aguafiestas pero en mi navegador no ha funcionado.
Me he bajado el fichero de la variables a 1 que me pasó @JKD y lo he metido en una tarjeta normal SD con los mapas que pasó el compañero ruso, que son los últimos que hay disponibles.
Pues bien, sigue diciendo que la tarjeta no es compatible o algo así.

A ver si subo la versión que lleva mi navegador pero es la del verano 2015 sin actualizar.
Click para expandir ...
Localiza LgeDRMKey.exe y pásamelo por correo. A ver tu versión. Te puedo asegurar que con las dos últimas versiones es funcional.
 
Te lo pasaré mañana junto a la captura de la versión que llevo porque estoy de noche y salgo de madrugada.
 
Debes iniciar sesión o registrarte para responder aquí.

Temas similares

Gabirodcha
tarjeta sd
Respuestas
1
Visitas
1 K
jallamas
jallamas
Gabirodcha
error tarjeta sd
Respuestas
3
Visitas
813
Rodi
Rodi
JKD
LAN5020: Actualización software y mapas 2022-11-23
2
Respuestas
26
Visitas
6 K
bultaco
bultaco
R
Tarjeta sd navegador
Respuestas
6
Visitas
4 K
Kavuqui
Kavuqui
phxlive
tarjeta sd no reconocida
Respuestas
2
Visitas
1 K
phxlive
phxlive
Volver
Arriba