Ver la Versión Completa : Problema IMEI nv_data
evilkaito
20/10/14, 22:46:34
Buenas noches!
Ha caido en mis manos un Galaxy S3 (GT-I9300) que no arrancaba y no podía hacer prácticamente nada. Su anterior usuario me ha dicho que estaba a android 4.3 stock, asi que decidi flashear de nuevo con odin y he logrado arrancar, pero tengo el problema del IMEI 0049... y no tengo un backup de nv_data valido... havia uno en la SD con fecha de modem 2013-mar-6 pero al restaurar no ha funcionado, sigo sin imei...
Alguien me puede echar una mano? O me he quedado con un bonito pisapapeles...
Saludos!!!!
dabyd64
20/10/14, 23:17:31
Que version le has puesto? No le habras puesto una 4.1.2? Si es asi tendra un modem antiguo y te causara ese problema.
Si ya estas con root y CWM, puedes solucionarlo aun mas facil.
Instalale este zip por cwm:
https://dl.dropboxusercontent.com/u/23958662/MODEM_CWM_I9300UBUGNG1.zip
Si al reiniciar recuperaste el imei, enhorabuena, solo era eso.
Si no...me temo que se corrompio, necesitaras llevarlo a que te lo arreglen
evilkaito
21/10/14, 11:01:49
Bien, he probado pero nada...
Os cuento... Tengo ahora mismo la 4.3, i el nv_data.bin del mismo indica el imei 0049 y el numero de serie no se corresponde con el del terminal
El nv_data.bin que he encontrado en la SD, trasteando con un editor HEX he visto que a parte de la fecha que he especificado antes, contiene el número de serie del terminal (supongo que esto es bueno).
He seguido un tutorial para restaurar el nv_data.bin. Con root y el ES File Explorer he borrado la carpeta /efs, he reiniciado el terminal, se ha regenerado la /efs, he borrado nv_data.bin y nv_data.bin.md5, he entrado a recovery, he hecho push del nv_data.bin con el numero de serie correcto, he vuelto a copiar el mismo nv_data.bin, pero renombrado a .bak, he cambiado permisos para que el propietario sea "radio"... reinicio de terminal y... no funciona, estamos como al principio.
Decido abrir el nv_data.bin en la carpeta /efs y vuelve a ser el mismo que el de la rom recién flasheada. Abro el .bak y es el que he copiado yo. Decido borrar el nv_data.bin y renombrar el .bak para que lo sustituya... Reinicio terminal y me ha vuelto a reemplazar el bueno por el malo...
Y con el modem nuevo (el zip que me ha facilitado dabyd64) me ocurre exactamente lo mismo... :S
Me he saltado algún paso importante?
Hay alguna manera de saber si el nv_data.bin que he encontrado en la SD, y que contiene el numero de serie correcto también contiene el IMEI correcto?
Gracias!!!
James C.
21/10/14, 11:09:55
Una pregunta. ¿En la SD tienes una carpeta llamada efs y con archivos dentro o solo un archivo llamado nv_data.bin??
Porque para restaurar el IMEI con root explorer, se tiene que reemplazar toda la carpeta efs y no solo un archivo.
evilkaito
21/10/14, 11:17:42
Solamente el nv_data.bin...
Alguna cosa que probar antes de mandar a reparar?
Saludos
James C.
21/10/14, 11:23:26
Lo que tu hiciste fue esto: http://cadascu.wordpress.com/2013/10/17/recuperar-imei-en-galaxy/
Lo hiciste todo bien??
evilkaito
21/10/14, 11:47:11
Mas o menos he hecho esto, con un par de diferencias:
-Al no tener una copia completa de la carpeta /efs, no he podido restaurar la carpeta IMEI. En todo caso, buscando por la red he visto el mismo tutorial sin restaurar esta carpeta, ya que especifican que el IMEI reside encriptado en nv_data.bin.
-Lo que yo tengo es solo un nv_data.bin. Por lo tanto, no renombro ningun nv_data a nv_data.bin. Simplemente borro los originales y restauro la copia.
Lo otro, todo identico, pero nada...
Son diferentes .nv_data y nv_data.bin?
evilkaito
21/10/14, 11:52:55
Un poquitín mas de luz al asunto... el contenido de nv.log
Tue Oct 21 10:04:22 2014: nv data does not exist
Tue Oct 21 10:04:22 2014: md5 compute error
Tue Oct 21 10:04:22 2014: md5 compute error
Tue Oct 21 10:04:22 2014: default NV restored
Tue Oct 21 10:04:33 2014: input from cp
Tue Oct 21 10:04:33 2014: 2nd NV built
Tue Oct 21 10:04:33 2014: NV data back-uped
Tue Oct 21 10:15:29 2014: cracking detected
Tue Oct 21 10:15:29 2014: NV backup has been rebuilt
Tue Oct 21 10:15:30 2014: restore_nv_backup_data OK.
Tue Oct 21 10:15:30 2014: NV restored
Tue Oct 21 10:15:37 2014: input from cp
Tue Oct 21 10:15:37 2014: 2nd NV built
Tue Oct 21 10:15:37 2014: NV data back-uped
Tue Oct 21 10:19:29 2014: fail - no checksum info
Tue Oct 21 10:19:29 2014: restore_nv_backup_data OK.
Tue Oct 21 10:19:29 2014: NV restored
Tue Oct 21 10:20:31 2014: md5 compute error
Tue Oct 21 10:20:31 2014: restore_nv_backup_data OK.
Tue Oct 21 10:20:31 2014: NV restored
Tue Oct 21 10:23:17 2014: cracking detected
Tue Oct 21 10:23:17 2014: NV backup has been rebuilt
Tue Oct 21 10:23:18 2014: restore_nv_backup_data OK.
Tue Oct 21 10:23:18 2014: NV restored
Tue Oct 21 10:28:14 2014: fail - no checksum info
Tue Oct 21 10:28:14 2014: restore_nv_backup_data OK.
Tue Oct 21 10:28:14 2014: NV restored
Parece que el mismo android me restaura el nv_data.bin por algun problema de suma MD5.
Alguna idea?
James C.
21/10/14, 11:52:59
Pues no se, es que jamas e visto esto de restaurar el nv_data. Yo siempre e visto lo de reemplazar la carpeta entera efs o lo del Ktool.
evilkaito
21/10/14, 12:00:38
Pues no se, es que jamas e visto esto de restaurar el nv_data. Yo siempre e visto lo de reemplazar la carpeta entera efs o lo del Ktool.
El Ktool restaura un .img o un .tar. Me puedes confirmar si el .tar solamente contiene la carpeta /efs? Porque si es así, copio la /efs actual con los nv_data cambiados y lo intento...
A lo mejor puede servir para que no detecte cracking...
Saludos!!
vBulletin® v3.8.1, Copyright ©2000-2026, Jelsoft Enterprises Ltd.