Cacharreando con el BootLoader

[LEPT]

El fichero que se flashea del bootloader, 'motoboot.img', se compone de una pequeña cabecera y 5 archivos (tz.mbn, rpm.mbn, sdi.mbn, aboot.mbn, sbl1.mbn). En esa cabecera, entiendo que le indicará donde y como va cada uno de esos 5 ficheros.

He probado a extraer de un móvil flasheado con una STOCK-ROM 4.4.4, cada uno de los 5 ficheros de sus particiones correspondientes. Y luego los he ido comparando y buscando dentro del 'motoboot.img'.

En efecto, dentro del 'motoboot.img' empieza una pequeña cabecera de 1 KByte seguida de los 5 ficheros encadenados, pero repitiendo uno de ellos 3 veces (tz - rpm - sdi - aboot - sbl1 - sbl1 - sbl1), lo cual no sé porqué.

He observado también que el 'motoboot.img' de una STOCK-ROM es idéntico al de una GPe-ROM.

Luego he analizado el ZIP incremental (parche OTA) para pasar de GPe 4.4.4 a GPe 5.0.1. Dentro no hay ningún 'motoboot.img' ni similar. Lo que sí hay son los 5 ficheros que lo componen, pero sueltos (tz.mbn, rpm.mbn, sdi.mbn, emmc_appsboot.mbn, sbl1_8226.mbn).

Siguo analizando el ZIP incremental, y en el 'updater-script' se ve cuándo y donde los flashea:
ui_print("updating sbl1 ...");
assert(package_extract_file("sbl1_8226.mbn", "/dev/block/platform/msm_sdcc.1/by-name/sbl1"));
show_progress(0.050000,0);
ui_print("updating aboot ...");
assert(package_extract_file("emmc_appsboot.mbn", "/dev/block/platform/msm_sdcc.1/by-name/aboot"));
show_progress(0.050000,0);
ui_print("updating rpm ...");
assert(package_extract_file("rpm.mbn", "/dev/block/platform/msm_sdcc.1/by-name/rpm"));
show_progress(0.050000,0);
ui_print("updating tz ...");
assert(package_extract_file("tz.mbn", "/dev/block/platform/msm_sdcc.1/by-name/tz"));
show_progress(0.050000,0);
ui_print("updating sdi ...");
assert(package_extract_file("sdi.mbn", "/dev/block/platform/msm_sdcc.1/by-name/sdi"));
Hace con ellos lo que era de esperar.

Con el uso de DD, también podríamos hacer "manualmente" esos flasheos.

Y ahora lanzo la pregunta:

Comentaban (y corregirme si me equivoco) que el problema de no poder hacer downgrade correctamente, era porque al haber flashado el bootloader 41.18, éste no había manera de 'bajarlo' por fastboot, aunque desde el recovery sí se saltaba esa restricción. ¿Había algún otro problema?

Lo pregunto, porque a la vista de lo que he expuesto arriba, y desde mi ignorancia mitigada por curiosidadd y persistencia, diría que es posible 'machacar' sin problema los 5 ficheros que conforman el bootloader.

Dicho de otra manera. Si estoy con el 41.18 en LP 5.0.1, y quiero bajarme a KK 4.4.4, me parecería lógico flasharme por fastboot la ROM, y mediante DD machaco los 5 ficheros extraídos previamente del 'motoboot.img' de dicha versión KK. Y con eso teóricamente tendría puesto el bootloader 41.13 (del KK 4.4.4) junto con la ROM KK 4.4.4, ¿no?


En el supuesto de que algo de eso fuera viable y tuviera sentido... el proceso que seguiría dado que he comprobado que desde el Recovery de TWRP, el PC me reconoce el móvil en modo Recovery (perfecto!) y así puedo realizar operaciones de DD 'sin nada más' y además todo ello realizándolo desde la RAM del móvil con lo que puedo machacar hasta el recovery mismo, mientras estoy en él... pues sería:

1º Flasheo la última versión del TWRP.
2º Arranco el móvil en modo Bootloader/fastboot.
3º Lo conecto al PC, con Linux (porque es lo más cómodo para las operaciones que hacermos).
4º Flasheo la Tabla de particiones de la STOCK-ROM:
./mfastboot flash partition gpt.bin
5º Entro en modo Recovery. Y ahora hacemos "mfastboot flash motoboot motoboot.img", pero SIN hacerlo mediante fastboot, si no mediante DD. Primero, compruebo que me detectó el móvil y copio los 5 ficheros a la memoria del teléfono (lo podíamos haber hecho antes, de cualquier otra manera).
./adb devices
./adb push tz.mbn /sdcard/
./adb push rpm.mbn /sdcard/
./adb push sdi.mbn /sdcard/
./adb push aboot.mbn /sdcard/
./adb push sbl1.mbn /sdcard/
./adb shell
dd if=/sdcard/sbl1_8226.mbn of=/dev/block/platform/msm_sdcc.1/by-name/sbl1
dd if=/sdcard/emmc_appsboot.mbn of=/dev/block/platform/msm_sdcc.1/by-name/aboot
dd if=/sdcard/rpm.mbn of=/dev/block/platform/msm_sdcc.1/by-name/rpm
dd if=/sdcard/tz.mbn of=/dev/block/platform/msm_sdcc.1/by-name/tz
dd if=/sdcard/sdi.mbn of=/dev/block/platform/msm_sdcc.1/by-name/sdi
exit
6º Desde el Recovery, reiniciamos en modo Bootloader/fastboot. Si todo ha ido medianamente bien, ya deberíamos poder ver que la versión del bootloader es la 41.13, y en tal caso proseguimos ya con la parte fácil.
7º Flasheo por fastboot el resto de la ROM, como se haría normalmente.
./mfastboot flash logo logo.bin
./mfastboot flash boot boot.img
./mfastboot flash recovery recovery.img
./mfastboot flash system system.img_sparsechunk.0
./mfastboot flash system system.img_sparsechunk.1
./mfastboot flash system system.img_sparsechunk.2
./mfastboot flash modem NON-HLOS.bin
./mfastboot erase modemst1
./mfastboot erase modemst2
./mfastboot flash fsg fsg.mbn
./mfastboot erase cache
./mfastboot erase userdata
8º Por último reinciamos el movil.
./mfastboot reboot

Debería de arrancar como cuando arranca por primera vez (le cuesta un poco más que los arranques normales, pero poco más).


Bueno, ya comentaréis como lo veis de viable y que opináis. :palomitas:

[agusynoe]

Lo has probado? Si se puede solucionar el bootloop infinito me salvarias la navidad jaja vamos opinen

[Mariano2797]

Resumiendo todo, esto le devolvería al móvil el Boot 41.13, pero hay que intentar y ver que funciona no? Me animo a probar.. [emoji23]

[cesc1972]

gpt.bin también tiene protección contra downgrade, independientemente del motoboot.

Al desbloquear el bootloader se supone que el fastboot deja de comprobar que el archivo tenga la firma de Motorola, pero sí comprueba los números de versión.

No habría alguna manera de modificar el archivo para simplemente ponerle el mismo número de versión que el último bootloader y gpt para poder saltar de uno a otro? Al no comprobar la firma no habría problema por estar modificado.

Pregunto, ahora falta el valiente xD

Gracias por investigar, buen debate si se consigue algo :thumbup:

[aldebran]

La verdad es que en este tema estoy muy verde. Pero me sale una pregunta, no habría problemas por el tamaño de las particiones?

[LEPT]

gpt.bin también tiene protección contra downgrade...

¿Seguro de esto?

Humm, por poder, también se podría "machacar" con el de la ROM 4.4.4, pero es algo diferente a lo anterior, dado que el gpt.bin en el móvil, no es un fichero como tal, si no que son las 32KB primeras del mmcblk0 (la memoria del móvil). Lo he extraído sin problemas varias veces, pero nunca lo sobrescribí, aunque no debería de haber mayor problema. Esto en el supuesto que como dices, no deje flashear el gpt.bin de manera normal.

Si alguien quiere probar todo esto, estaría genial, pero claro, ya sabe que es bajo su responsabilidad.

A ver, no es que sean cosas descabelladas ni mucho menos. Yo mismo en mi propio móvil, he ido experimentando cosas (tengo 2 post por ahí al respecto) con el comando DD y las particiones, y sin problemas. Pero claro, mi móvil está con KK 4.4.4, funcionando de maravilla, y no tengo necesidad de hacerle algo que pudiera "dejarlo igual" o "escacharrarlo" :nav1:

Otra cosa es que lo tuviera "enladrillado" como les pasa a otros. Si no hay nada que perder... pues lo probaría de cabeza

[LEPT]

La verdad es que en este tema estoy muy verde. Pero me sale una pregunta, no habría problemas por el tamaño de las particiones?

Los tamaños de las particiones vienen definidos en el 'gpt.bin'. Por eso se flashea de los primeros ficheros en la secuencia de flasheo.

En las ROMs STOCK, la tabla de particiones difiere ligeramente respecto a las ROMs GPe, como ya indiqué (http://www.htcmania.com/showpost.php?p=16610035&postcount=1262).

[lyantsuki]

woooow excelente trabajo, falta que alguien lo pruebe, para ver si funciona, pero parece todo muy logico y podria que si realmente funcione

[Borrego92]

Pero Lept, es cierto que se puede machacar el bootloader...pero, ¿has estado en 41.18 y le has metido el 41.13? Es que creo que es hay cuando la placa base peta.

Si con los controladores de qualcomm el dispocitivo es reconocido...¿no se puede hacer algo? Hablo de dispocitivos con hardbrick.

[LEPT]

Pero Lept, es cierto que se puede machacar el bootloader...pero, ¿has estado en 41.18 y le has metido el 41.13? Es que creo que es hay cuando la placa base peta.

Si con los controladores de qualcomm el dispocitivo es reconocido...¿no se puede hacer algo? Hablo de dispocitivos con hardbrick.

Ya he comentado que no he usado este método con mi móvil, ya que lo tengo tranquilito en KK con 41.13. De ahí que lo exponga a todos para oir opiniones y demás ;-)

Dices que la placa peta... Esas palabras implican daño a nivel de hardware, y lo cierto es que me extraña de le ocurra un daño a nivel físico. Diría que el hardbrick es a nivel lógico, no físico. Ya que los daños físico no se solucionan, implican cambio de pieza.

La cuestión es que aún siendo un daño lógico ('a nivel lógico'), es un daño lógico severo ('grave').

Desconozco cómo afecta el hardbrick que sufren los compañeros a sus móviles. Quiero decir, que no sé si su móvil es capaz si quiera de arrancar en modo bootloader. Y en caso de poder hacerlo, tampoco sé si son capaces de entrar en modo Recovery. Lo digo porque el método que expuse al principio, sólo se podría usar en los que pudieran llegar hasta el Recovery.

De no llegar ni al Modo Bootloader, pero sí se reconociese con algún driver especial, se requeriría de otros métodos y herramientas (software), ya que habría que atacarlo a un nivel software 'más bajo'. Supongo que ahí entrará el tema ese de usar el MBM-CI (el cual sigo sin saber qué es realmente) y el QBOOT, las cuales entiendo que son herramientas de 'bajo nivel'.

[Borrego92]

Ya he comentado que no he usado este método con mi móvil, ya que lo tengo tranquilito en KK con 41.13. De ahí que lo exponga a todos para oir opiniones y demás ;-)

Dices que la placa peta... Esas palabras implican daño a nivel de hardware, y lo cierto es que me extraña de le ocurra un daño a nivel físico. Diría que el hardbrick es a nivel lógico, no físico. Ya que los daños físico no se solucionan, implican cambio de pieza.

La cuestión es que aún siendo un daño lógico ('a nivel lógico'), es un daño lógico severo ('grave').

Desconozco cómo afecta el hardbrick que sufren los compañeros a sus móviles. Quiero decir, que no sé si su móvil es capaz si quiera de arrancar en modo bootloader. Y en caso de poder hacerlo, tampoco sé si son capaces de entrar en modo Recovery. Lo digo porque el método que expuse al principio, sólo se podría usar en los que pudieran llegar hasta el Recovery.

De no llegar ni al Modo Bootloader, pero sí se reconociese con algún driver especial, se requeriría de otros métodos y herramientas (software), ya que habría que atacarlo a un nivel software 'más bajo'. Supongo que ahí entrará el tema ese de usar el MBM-CI (el cual sigo sin saber qué es realmente) y el QBOOT, las cuales entiendo que son herramientas de 'bajo nivel'.

Los daños que tienen los compañeros son a nivel lógico (la gran mayoría). Respecto al gran MBM-CI, el desarrollador dice que no puede crearlo ya que este esta firmado por motorola (ni se de donde lo saca, ni lo he visto en un firmware anterior).

PD: MBM-CI, es solo un paquete que tiene los siguientes archivos: el qboot (La herramienta de bajo nivel), el programmer.mbn y programmer_8626.mbn, y por ultimo el singleimage.mbn y singleimage_8626.mbn.

PD 2: Aqui tienes el MBM-CI de 4.4.4: https://www.mediafire.com/?mmo34vt9cpxnh99

[tonyvr96]

Ya he comentado que no he usado este método con mi móvil, ya que lo tengo tranquilito en KK con 41.13. De ahí que lo exponga a todos para oir opiniones y demás ;-)

Dices que la placa peta... Esas palabras implican daño a nivel de hardware, y lo cierto es que me extraña de le ocurra un daño a nivel físico. Diría que el hardbrick es a nivel lógico, no físico. Ya que los daños físico no se solucionan, implican cambio de pieza.

La cuestión es que aún siendo un daño lógico ('a nivel lógico'), es un daño lógico severo ('grave').

Desconozco cómo afecta el hardbrick que sufren los compañeros a sus móviles. Quiero decir, que no sé si su móvil es capaz si quiera de arrancar en modo bootloader. Y en caso de poder hacerlo, tampoco sé si son capaces de entrar en modo Recovery. Lo digo porque el método que expuse al principio, sólo se podría usar en los que pudieran llegar hasta el Recovery.

De no llegar ni al Modo Bootloader, pero sí se reconociese con algún driver especial, se requeriría de otros métodos y herramientas (software), ya que habría que atacarlo a un nivel software 'más bajo'. Supongo que ahí entrará el tema ese de usar el MBM-CI (el cual sigo sin saber qué es realmente) y el QBOOT, las cuales entiendo que son herramientas de 'bajo nivel'.

Estoy de acuerdo contigo, los errores son a nivel logico en un brick o en este caso "hardbrick" pero asi como un problema matematico, todo error logico tiene una solucion.

Nuestro problema empieza, conforme a lo que he visto, al no tener acceso a todas las herrramientas de desarrollo de motorola. Si se pudiera acceder a algo mas primitivo que el bootloader para inyectar absolutamente todo el sistema como si en una PC se tratara de instalar Linux desde un Live-USB.

En el Motorola Razr I, al dejar presionado el boton de la camara (con el celular apagado), conectamos el USB y entrara como driver AtomSOC, que permite sacar al celular de cualquier hardbrick ya que con el RSD se puede volver a instalar la ROM con la que estabas antes del brick. Deberia de haber manera de hacer algo parecido, obviamente de otro modo. :loco:

[FreddyWFS]

Como has conseguido esos 5 archivos? Intente extraer el motoboot con winrar y 7zip y tira que no se puede extraer

[Borrego92]

Estoy de acuerdo contigo, los errores son a nivel logico en un brick o en este caso "hardbrick" pero asi como un problema matematico, todo error logico tiene una solucion.

Nuestro problema empieza, conforme a lo que he visto, al no tener acceso a todas las herrramientas de desarrollo de motorola. Si se pudiera acceder a algo mas primitivo que el bootloader para inyectar absolutamente todo el sistema como si en una PC se tratara de instalar Linux desde un Live-USB.

En el Motorola Razr I, al dejar presionado el boton de la camara (con el celular apagado), conectamos el USB y entrara como driver AtomSOC, que permite sacar al celular de cualquier hardbrick ya que con el RSD se puede volver a instalar la ROM con la que estabas antes del brick. Deberia de haber manera de hacer algo parecido, obviamente de otro modo. :loco:

RDS Lite existe, pero el la aplicación no detecta el Moto G y por lo tanto no flashea. El moto G no tiene botón alguno para la cámara salvo el de encender y los de volumen, quizás haya una combinación para meterlo en un modo que esta oculto para flashear como en Nexus 5 ¿quien sabe?. Aquí dejo el RDS Lite: http://forum.xda-developers.com/showthread.php?t=2637338

[tonyvr96]

RDS Lite existe, pero el la aplicación no detecta el Moto G y por lo tanto no flashea. El moto G no tiene botón alguno para la cámara salvo el de encender y los de volumen, quizás haya una combinación para meterlo en un modo que esta oculto para flashear como en Nexus 5 ¿quien sabe?. Aquí dejo el RDS Lite: http://forum.xda-developers.com/showthread.php?t=2637338

El RDS no es necesario, mas que nada ejecuta automaticamente lo que se puede hacer manualmente pero si deberiamos buscar esa posible combinación, tal vez la haya. :sisi1:

[LEPT]

Como has conseguido esos 5 archivos? Intente extraer el motoboot con winrar y 7zip y tira que no se puede extraer

¿Extraerlos de donde? ¿Del móvil o del motoboot.img?
Del móvil:
Como los ficheros en cuestión representan particiones completas (echa un ojo a mi anterior Post (http://www.htcmania.com/showpost.php?p=16635118&postcount=1)), pues extraigo esas particiones (siguiendo lo que pongo en el punto "* Podemos extraer una partición del dispositivo" del otro Post, pero aplicándolo a estas 5 nuevas particiones).

Del 'motoboot.img':
Pues aquí 'a pelo' con un editor hexadecimal. Previamente he abierto los ficheros extraídos del móvil, con el editor hexadecimal. De ese modo analizo cuales son los puntos de inicio y final de cada fichero. Luego abro con el editor hexadecimal el motoboot.img, y voy localizando dichos puntos de inicio y final, seleccionando la información entre medio y copiando y pegándola en un nuevo fichero.

[Borrego92]

¿Extraerlos de donde? ¿Del móvil o del motoboot.img?
Del móvil:
Como los ficheros en cuestión representan particiones completas (echa un ojo a mi anterior Post (http://www.htcmania.com/showpost.php?p=16635118&postcount=1)), pues extraigo esas particiones (siguiendo lo que pongo en el punto "* Podemos extraer una partición del dispositivo" del otro Post, pero aplicándolo a estas 5 nuevas particiones).

Del 'motoboot.img':
Pues aquí 'a pelo' con un editor hexadecimal. Previamente he abierto los ficheros extraídos del móvil, con el editor hexadecimal. De ese modo analizo cuales son los puntos de inicio y final de cada fichero. Luego abro con el editor hexadecimal el motoboot.img, y voy localizando dichos puntos de inicio y final, seleccionando la información entre medio y copiando y pegándola en un nuevo fichero.

Creo que se refiere a los archivos del MBM, que no están en ninguno de esos sitios.

[LEPT]

Mirando el paquete de MBM-CI, observo que el fichero 'singleimage.bin', posee dentro:
una cabecera en la que hace referencia a una secuencia de ficheros (particiones) al estilo motoboot.img, pero son una lista diferente.
sbl1.mbn
DDR.mbn
aboot.mbn
rpm.mbn
tz.mbn
Pero además hay trozos "de algo más" entre los ficheros.

Además, singleimagen.bin es 'montable', a diferencia de motoboot.img que no lo es.

En fin... "nos falta información y/o herramientas para enredar más profundo" ;-)

[LEPT]

Creo que se refiere a los archivos del MBM, que no están en ninguno de esos sitios.

Si eso ya lo entendí ^^ pero como indiqué que extraje esos ficheros de esos 2 sitios, por eso le preguntaba. Aunque he indicado cómo sacarlos de ambos.

(Los ficheros no vienen con extensión, la extensión se la pongo yo.. pero claro averiguando cual es ;-) )

P.D.: que si queréis os subo algún fichero a algún lado

[JoseDroid]

El problema es para los bootloader brikeado que no se puede usar adb, creo que esto que pones por ahí van los tiros, teoricamente eso que pones deberia de funcionar pero tambien ocurre que no se tiene permiso root para hacerlo desde el adb con el PC, se puede volcar las particiones pero a la hora de ecribir en ellas te sale el mensaje de que no se tiene permiso root.

[kofking]

Hola. Estuve leyendo casi todos los comentarios y todo es muy interesante. Me pregunto si ya hay tutoriales para volver claro volver a KitKat con el bootloader 41.18.
Se que uno de los problemas de volver a KitKat con 41.18 es el barrido de pantalla al prender el móvil. Pero aparte de ese barrido no me queda claro las totales desventajas del bootloader 41.18 ??

[LEPT]

Lo indicado en este Hilo no es necesario para realizar un Downgrade desde una STOCK ROM 5.0.2 (con bootloader 41.18) por ejemplo, a una STOCK ROM 4.4.4 (con bootloader 41.13).

Bastará con que flashees por fastboot la STOCK ROM 4.4.4, omitiendo los 2 primeros comandos (el de gpt.bin y motoboot.img). El resultado será que estarás en 4.4.4 con el bootloader 41.18 (del 5.0.2), pero aparte del barrido transversal que recorre la pantalla verticalmente, el cual se quita con el primer bloqueo de pantalla, no tendrás más inconvenientes.

Este barrido surge cuando haces mezclas entre con bootloaders (BL) y resto de la ROM de las versiones 4.4.4 y 5.x.x. Si tienes BL de 5.x.x con ROM de 4.4.4, tendrás barrido, si tienes BL de 4.4.4 con ROM de 5.x.x también tendrás barrido.

Pero aparte del barrido no posee una desventaja más allá de no ser el que corresponde a la ROM. Funcionar a nivel de usuario, funciona igual.

[JoseDroid]

La cuestión es que tenemos los 5 archivos pero no la singleimage.
Con los archivos se puede intentar montar un update.zip y intentar un downgrade del bootloader. En principio está el problema del recovery stock que no lo admitiría por la firma, igual con un custom se podría. Esta posibilidad la veo más cerca, no lo he intentado ya que mi motog está briqueado de momento.
Para los bootloader briqueado pues las cosas se complican ya que es necesario archivos binario.
La singleimage es un binario de esos 5 archivos, pienso que Motorola por algún motivo sacó el flash-blank para algunas rom debido a que abría algún problema a la hora de instalar el bootloader con el recovery.
En la teoría montar una singleimage no sería muy complicado pero el problema viene en que el flash-blank que usamos es de Motorola y no admite singleimage sin firma.
El móvil una vez briqueado no entiende de firmas ni de nada, todo el problema está en las aplicaciones que usamos para crear las particiones y copiar los archivos.
La gente se esfuerzan haciendo gestores que gestionan las herramientas de Motorola que no lo veo mal y se agradece pero por ahí no van los tiros ya que siempre se está a lo que Motorola quiera, lo ideal es tratar de averiguar cómo particionar y copiar dichos archivos en un móvil sin nada escrito al igual que lo hace el flash-blank.
Tenemos los datos de las particiones y tenemos los archivos que van en ella pero no sabemos cómo hacerlo sin las herramientas de Motorola, las herramientas de Motorola está configurada para hacer sólo lo que Motorola quiera y ese es lo que a muchos se les escapa, mientra estemos usando las herramienta de Motorola no podremos hacer nada que Motorola no quiera que hagamos como por ejemplo volver a instalar un bootloader que queramos

[LEPT]

La cuestión es que tenemos los 5 archivos pero no la singleimage.
Con los archivos se puede intentar montar un update.zip y intentar un downgrade del bootloader. En principio está el problema del recovery stock que no lo admitiría por la firma, igual con un custom se podría. Esta posibilidad la veo más cerca, no lo he intentado ya que mi motog está briqueado de momento.
Para los bootloader briqueado pues las cosas se complican ya que es necesario archivos binario.
La singleimage es un binario de esos 5 archivos, pienso que Motorola por algún motivo sacó el flash-blank para algunas rom debido a que abría algún problema a la hora de instalar el bootloader con el recovery.
En la teoría montar una singleimage no sería muy complicado pero el problema viene en que el flash-blank que usamos es de Motorola y no admite singleimage sin firma.
El móvil una vez briqueado no entiende de firmas ni de nada, todo el problema está en las aplicaciones que usamos para crear las particiones y copiar los archivos.
La gente se esfuerzan haciendo gestores que gestionan las herramientas de Motorola que no lo veo mal y se agradece pero por ahí no van los tiros ya que siempre se está a lo que Motorola quiera, lo ideal es tratar de averiguar cómo particionar y copiar dichos archivos en un móvil sin nada escrito al igual que lo hace el flash-blank.
Tenemos los datos de las particiones y tenemos los archivos que van en ella pero no sabemos cómo hacerlo sin las herramientas de Motorola, las herramientas de Motorola está configurada para hacer sólo lo que Motorola quiera y ese es lo que a muchos se les escapa, mientra estemos usando las herramienta de Motorola no podremos hacer nada que Motorola no quiera que hagamos como por ejemplo volver a instalar un bootloader que queramos

Ahí la has dado.

[JoseDroid]

Estoy probando tu teoria en un LG G3s pero con pull en vez de push (para extraer el archivo) pero no me funciona, tengo root y entrando como superusuario (#) tampoco.
Por otro lado con RootExplorer si monto la raiz me aparece en /dev la parte /block/platform/msm_sdcc.1/by-name/ con todos sus archivos (sin la extención), si copio tz por ejemplo luego me da error al pegarlo en sdcard, mirando en los permisos tienen 0600 (lectura/escritura) solo dueño, le cambio el permiso a 0777 y me sigue dando el error.
tambien he mirado los permisos para by-name y son 0755, lo he puesto a 0777 para probar pero tampoco me deja copiar los archivos en sdcard
Estoy estancado...

PD: Todo esto es por si sirve que alguien que tenga 4.4.4 y root nos pueda pasar la carpeta by-name y así ver si podemos hacer un downgrade del bootloader.

[JoseDroid]

Bueno, hay avances...

he conseguido copiar los archivos pero no estoy seguro que esten bien copiado debido a que todo esto lo estoy haciendo desde un LG G3s y no puedo comprobarlo ya que copiarlo desde el sistema a la SD no supone peligro alguno pero desde la SD al sistema ya es otra cosa, ya con el Moto G brikeado tengo bastante... Cuando arregle mi Moto G si que hare la prueba de copiar esos archivos desde la SD al sistema.

He hecho lo siguiente:


adb devices
adb shell
su
cd dev/block/platform/msm_sdcc.1/by-name
dd if=/dev/block/platform/msm_sdcc.1/by-name/aboot of=/sdcard/aboot.mbn
dd if=/dev/block/platform/msm_sdcc.1/by-name/rpm of=/sdcard/rpm.mbn
dd if=/dev/block/platform/msm_sdcc.1/by-name/sbl1 of=/sdcard/sbl1.mbn
dd if=/dev/block/platform/msm_sdcc.1/by-name/sdi of=/sdcard/sdi.mbn
dd if=/dev/block/platform/msm_sdcc.1/by-name/tz of=/sdcard/tz.mbn
De esta forma tengo los 5 archivos del bootloader en mi alamcenamiemto interno (no SD)

Por otro lado he viste que esta el recovery y lo he extraido tambien

dd if=/dev/block/platform/msm_sdcc.1/by-name/recovery of=/sdcard/recovery.img
Supuestamente si copiamos un recovery en nuestro almacenamiento interno y ejecutamos lo siguiente se deberia de instalar, no he hecho la prueba aun


dd if=/sdcard/recovery.img of=/dev/block/platform/msm_sdcc.1/by-name/recovery
PD Para instalar adb en nuestro PC y no tener que andar andando en la carpeta ADB y fastboot de nuestro PC es mucho mas comodo tenerlo instalado y así poder usar adb y fastboot desde cualquier carpeta, dejo el enlace para descargarlo (extraido de XDA)

https://mega.co.nz/#!1kECBYAJ!YMd5GTSD3Iw0W8dUJV0syOj8nP9SukCc0XssLwd Lzj8

En la instalación en driver darle a N porque no es necesario si ya habeís instalado los drivers de vuestro dispositivo anteriormemte

[JoseDroid]

He probado instalar el recovery por este medio y si que se puede.
El recovery es el mismo que anteriormente dumpee

http://i.imgur.com/rN6GBCD.png

He reiniciado en modo recovery y todo correcto X-D

[Borrego92]

He probado instalar el recovery por este medio y si que se puede.
El recovery es el mismo que anteriormente dumpee

http://i.imgur.com/rN6GBCD.png

He reiniciado en modo recovery y todo correcto X-D

Si advances como estos fueran en el Moto G seria la bomba, sigue dándole caña Jose ;)

[LEPT]

Bueno... pero esto es normal. Quiero decir, que ya está probado (justamente con el Recovery).

En el otro Hilo complementario que creé, ya mostré lo que se podía hacer:
[Tutorial] Sacar partido a las Particiones del dispositivo (http://www.htcmania.com/showthread.php?t=941240)

Donde yo tenía la incertidumbre, es en la composición del Bootloader en si. Deduje que tiene una cabecera (que a saber cómo crearla) y luego una secuencia de varios de los ficheros mbn que componen el bootloader, 'repitiendo 3 veces' al final uno de ellos, algo que se me hace raro así sin más.

De ahí que el 'quiz' de la cuestión es saber "cómo crean" el bootloader con los ficheros mbn, pues el 'plasmarlo' en la memoria del móvil, con el 'DD' parece ser que puede hacerse.

[JoseDroid]

A ver si es que yo tengo otro concepto... yo estoy en que el bootloader se compone de varios archivos en el mismo directorio que comparte ese mismo directorio el recovery y mas cosas.
Cuando se instala por fastboot o a veces tambien por custom una imagen motoboot.img es eso una imagen, el instalador monta esa imagen y extrae los 5 archivos y los escribe en el directorio de la partición DEV
Desde mi punto de vista daría lo mismo instalar los 5 archivos uno a uno que instalar desde una imagen *.img de los 5 archivos.
Yo veo lo mismo en

dd if=/sdcard/aboot.mbn of=/dev/block/platform/msm_sdcc.1/by-name/aboot
dd if=/sdcard/rpm.mbn of=/dev/block/platform/msm_sdcc.1/by-name/rpm
dd if=/sdcard/sbl1.mbn of=/dev/block/platform/msm_sdcc.1/by-name/sbl1
dd if=sdcard/sdi.mbn of=/dev/block/platform/msm_sdcc.1/by-name/sdi
dd if=/sdcard/tz.mbn of=/dev/block/platform/msm_sdcc.1/by-name/tz
que esto


dd if=/sdcard/motoboot.img of=/dev/block/platform/msm_sdcc.1/by-name/
La unica diferencia es que se sacan los archivos de una imagen

PD: la de horas que me hubiera ahorrado si llega a ver tu post , muy buen aporte por cierto

[AndroG_14]

Una pregunta, por que al volver de 5.1 GPE a 5.0.2 de Motorola, hace downgrade de bootloader? Cuando tenia GPE 5.1 tenia 41.19 y al volver a 5.0.2 Argentina, tengo 41.18 :S, ojala podamos volver a 41.13

[JoseDroid]

Una pregunta, por que al volver de 5.1 GPE a 5.0.2 de Motorola, hace downgrade de bootloader? Cuando tenia GPE 5.1 tenia 41.19 y al volver a 5.0.2 Argentina, tengo 41.18 :S, ojala podamos volver a 41.13

Si de 41.19 se pasa a 41.18 sin problema