Good news everyone!
Pude obtener el firmware!
Les voy a compartir mi experiencia de varios días de forma resumida así si alguien quiere hacer lo mismo y no sabe como quizá pueda serle de utilidad, advierto que no está redactado en forma de receta mágica sino al estilo prueba/error. Después de todo cada router tiene sus cosas.
Son numerosas las formas en que intenté obtener el firmware y fracasé:
- comando dm (en el CFE): no logré leer más de un mega, después de la dirección 0xb8100000 tira un exception 32 y queda en un bucle infinito
- cfetool de noltari: lo mismo, se clava al mega (ya que usa el dm del CFE)
- comando dumpmem (en linux del router): lo mismo que antes, pero por lo menos no se cuelga en un loop infinito...
- nanddump en el linux del router: no reconocía el dispositivo /dev/mtd0
- bootear un kernel por tftp montando el rootfs del mismo router: error diciendo que los nuevos kernels no soportan sistemas jffs2 (si no recuerdo mal)
- bootear un kernel por tftp montando el rootfs desde un pendrive: no se montaba ya que no logré compilar los modulos usb integrados en el kernel (el tema es que no sabía si era eso o no había soporte para el usb)
- bootear un kernel por tftp montando el rootfs por NFS desde la PC: lo mismo que antes pero con los modulos de red
...
...
danitool en otro post me había dicho que se podía bootear un kernel con el rootfs en la ram sin modificar la flash del router, el tema es que no había terminado de entender el punto ya que yo pensaba en una initrd y no sabía como cargarla junto al nucleo. Luego navegando por los menuconfig de openwrt vi la opción de meter el rootfs dentro del nucleo!
Así que finalmente pude pude compilar un nucleo con un rootfs "incrustado" y con el comando r del CFE lo cargué por tftp (como había hecho en los otros intentos).
Me olvidé de mencionar que para bootear tuve que agregar el id board (96328dg2x2) en el codigo antes de compilar porque sino me tiraba "kernal panic" al no reconocer la placa y que use la rama barrier-breaker_14.04 del repositorio de noltari
Una vez que logré bootear openwrt extraje con el comando cat el contenido de los dispositivos /dev/mtdblock{0..4).
Algo curioso es que leyendo mtdblock2 no pude obtener el kernel en su totalidad y tuve que leer mtd2 en su lugar. No estoy seguro del porque.
A continuación pongo que había en cada uno de los mtdblock:
/dev/mtdblock0 <- CFE
/dev/mtdblock1 <- rootfs
/dev/mtd2 <- kernel
/dev/mtdblock3 <- nvram
/dev/mtdblock4 <- contiene toda la flash salvo el CFE
Luego vino el problema de como ensamblar todo eso para obtener un firmware funcional...
Existe una utilidad que se llama analyzetag la cual utilicé junto un editor hexadecimal para intentar armar el firmware (header + rootfs + kernel + cfe), pero por algún motivo... había un par de CRC que no me coincidían y no quise arriesgar.
Acá se puede ver el struct del header y bajar el analyzetag.c :
http://wiki.openwrt.org/doc/techref/brcm63xx.imagetagSeguí buscando hasta que encontré otra utilidad (que viene con las fuentes de openwrt) que se llama imagetag y permite ensamblar un firmware apartir de las partes mencionadas anteriormente.
Algo que me llamó la atención es que todos los firmwares que había descargado de internet para analizarlos no traían CFE, solo rootfs y kernel. Lo cual me hizo dar cuenta que no era buena idea incluir el CFE en el firmware por si algo salía mal. Claro está que también podía suceder que se escribiera el rootfs en el lugar del CFE y se jodiera todo pero es más dificil. La razón por la cual quería meter también el CFE es porque el header original lo contemplaba.
Bueno, entonces teniendo el kernel y el rootfs ensamblé el firmware de esta manera:
./imagetag -i kernel -f rootfs -o PDG_TAR_4.06L.02.2813.bin -b 96328dg2x2 -c 6328 -l 0x0 -e 0x0 --root-first --kernel-file-has-header -1 fernando3k
imagetag se encarga de generar el header. Cuidado con los parámetros -l 0x0 -e 0x0, en realidad deberían ingresarse correctamente, el tema es que no sabía bien el valor de entry y usando --kernel-file-has-header toma esos valores del kernel (porque en este caso el kernel los tenía en algún lado, un supuesto encabezado que no vi...)
Lo unico, no me gustó que se le hace un padding al rootfs haciendo que la partición correspondiente tengan un tamaño diferente a la original (apenas más grande), algo que no afecta en lo más mínimo la funcionalidad del mismo. La utilidad no tiene ningún argumento para evitarlo. Creo que es porque los nuevos kernels son quisquillosos con la alineación de los bloques o algo por el estilo.
El ultimo argumento es una huella que dejé y se puede ver con dumpmem 0xb80100A0 20 en linux
Al firmware los testeé, grabé otros firmwares y volví a poner el original y anduvo todo perfecto.
Firmware PDG_TAR_4.06L.02.2813: https://www.mediafire.com/?r5vzydtnfd2w2j7Agradezco las respuestas que recibí en este otro post:
https://foro.seguridadwireless.net/openwrt/firmware-adb-p-dg-a4001n/Edito:
Por las dudas dejo el modelo completo del router: ADB P.DG A4001N A-000-1A1-AE
