[ DEBATE ] 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:
[PHP]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"));[/PHP]
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:
[PHP]./mfastboot flash partition gpt.bin[/PHP]
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).
[PHP]./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[/PHP]
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.
[PHP]./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[/PHP]
8º Por último reinciamos el movil.
[PHP]./mfastboot reboot[/PHP]

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.

[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..

[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

Gracias por investigar, buen debate si se consigue algo

[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]

 Cita: Originalmente Escrito por cesc1972

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"

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]

 Cita: Originalmente Escrito por 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?

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é.

[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]

 Cita: Originalmente Escrito por 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.

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]

 Cita: Originalmente Escrito por LEPT

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]

 Cita: Originalmente Escrito por LEPT

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.

[FreddyWFS]

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

[Borrego92]

 Cita: Originalmente Escrito por tonyvr96

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.

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/show....php?t=2637338

[tonyvr96]

 Cita: Originalmente Escrito por Borrego92

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/show....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.

[LEPT]

 Cita: Originalmente Escrito por FreddyWFS

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), 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]

 Cita: Originalmente Escrito por LEPT

¿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), 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]

 Cita: Originalmente Escrito por Borrego92

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.