Actualización 2024

Hemos logrado un hito importante en el proyecto gracias a la colaboración de la comunidad! Un colaborador, alphab0ing, ha estado trabajando en crear una ROM personalizada para la placa Vantron RK3399 de Bowflex. Puedes ver más en este hilo de GitHub.

Hace ya más de un año que mi consola recibió una actualización de sistema vía OTA. Rápidamente me conecté vía ADB para hacer un respaldo de los archivos (si es que los encontraba) y afortunadamente tuve éxito!

Dicha actualización se alojó en el típico directorio de trabajo de Nautilus, /sdcard/Nautilus/redbend/. Los archivos extraídos son los siguientes:

1_1_script.rdp
1_delta.rdp
1_suffix.rdp
Credentials.txt
crc.rdp
deltas_header.rdp
dma_config.txt
dp
installation_order.txt
section1.rdp
suffix_section.rdp

El archivo 1_delta.rdp era particularmente grande, por lo que asumí que allí se encontraba la magia. Luego de inspeccionar un poco el archivo, llegué a esto:

1_delta.rdp: Java archive data (JAR): Descomprimir como un .zip
	- payload.bin: Extraer con https://github.com/ssut/payload-dumper-go
		- boot.img: Android bootimg, kernel (0x10008000), ramdisk (0x11000000), second stage (0x10f00000), page size: 2048, cmdline (console=ttyFIQ0 androidboot.baseband=N/A androidboot.wificountrycode=US androidboot.veritymode=enforcing androidboot.hardware=r)
		- dtbo.img: data
		- oem.img: Linux rev 1.0 ext2 filesystem data, UUID=b886e36e-ac40-5948-86dd-27c114bd225e, volume name "oem" (extents) (large files) (huge files)
		- system.img: Linux rev 1.0 ext2 filesystem data, UUID=0a7fc206-6c88-5018-bacd-4ea8a11db7ca (extents) (large files) (huge files)
		- trust.img: data
		- uboot.img: data
		- vbmeta.img: data
		- vendor.img: Linux rev 1.0 ext2 filesystem data, UUID=67531afd-7aed-52f3-9196-b1cdad9fd724, volume name "vendor" (extents) (large files) (huge files)

Los archivos de la actualización OTA (HP-22_T56_EEA Android OS Image 3.10 release-keys) han sido compartidos en Internet Archive.

Con dichos archivos, alphab0ing pudo obtener el DTS (Device Tree Source) original del dispositivo (descargar). Esto es crucial para el desarrollo de ROMs personalizadas y para comprender mejor el hardware. Veremos como avanza esto!

Modo de Carga Rockchip

Un procesador RK3399 alimenta el hardware de Android. Los procesadores Rockchip vienen con un “loader mode” como característica estándar.

El conjunto de herramientas que he utilizado es:

• Rockchip Driver Assistant v4.5 de ChinaGadgetsReviews
• rkDumper 1.09 test de este post de XDA
• Android Tool Release v2.69 de ChinaGadgetsReviews

Hay una versión más nueva del controlador disponible para descargar, pero se sabe que es incompatible con rkDumper.

Para jugar con esto, tendrás que desmontar la Consola Bowflex, desatornillar la tapa trasera de plástico y volver a montarla en una “forma desnuda”. No intentes esto, ya que jugar con el hardware de Android en Loader Mode puede llevar a un dispositivo permanentemente roto.

Aquí están las partes relevantes de la placa lógica de Android para cosas de Rockchip:

Puedes tener abierta la aplicación Android Tool Release todo el tiempo como referencia para verificar en qué modo está la consola.

Con la máquina encendida en “modo normal” y conectada a un computador, se identifica como NFTM-LAR:

NFTM-LAR:
  Product ID: 0x0001
  Vendor ID: 0x2207 (Fuzhou Rockchip Electronics Co., Ltd.)
  Version: 3.10
  Velocidad: Hasta 480 Mb/s
  Fabricante: Vanzo
  Ubicación ID: 0x14120000 / 9
  Corriente Disponible (mA): 500
  Corriente Requerida (mA): 500
  Corriente Extra de Operación (mA): 0

Con la máquina apagada, conectada a través de USB a un computador, manteniendo presionado el “Recovery button” y encendiéndola, debería arrancar en “Loader mode”. La máquina “sonará”, pero la pantalla permanecerá estática. Puedes apagar, esperar un minuto, encender y la máquina arrancará normalmente.

El hardware de Android no maneja el “sonido” después de encender la máquina, sino a través de las otras PCB de Nautilus.

Ahora se reportará en el computador como USB download gadget (Número de Serie oculto):

USB download gadget:
  Product ID: 0x330c
  Vendor ID: 0x2207 (Fuzhou Rockchip Electronics Co., Ltd.)
  Versión: 99.99
  Número de Serie: XXXXXXXXXXXXXXX
  Fabricante: Rockchip
  Ubicación ID: 0x14120000

Después de ejecutar rkDumper contra la consola, obtenemos información sobre las particiones:

"EFI PART" sign found (RKFP FW dump)

Partition "EFI_part" (0x00004000) saved (format: RockChip RKFP dump)
Partition "uboot_a" (0x00002000) saved (format: Rockchip uboot image file)
Partition "uboot_b" (0x00002000) saved (format: Rockchip uboot image file)
Partition "trust_a" (0x00002000) saved (format: unknown)
Partition "trust_b" (0x00002000) saved (format: unknown)
Partition "misc" (0x00002000) saved (format: unknown)
Partition "resource" (0x00008000) saved (format: unknown)
Partition "kernel" (0x00010000) saved (format: unknown)
Partition "dtb" (0x00002000) saved (format: unknown)
Partition "dtbo_a" (0x00002000) saved (format: unknown)
Partition "dtbo_b" (0x00002000) saved (format: unknown)
Partition "vbmeta_a" (0x00000800) saved (format: unknown)
Partition "vbmeta_b" (0x00000800) saved (format: unknown)
Partition "boot_a" (0x00020000) saved (format: unknown)
Partition "boot_b" (0x00020000) saved (format: unknown)
Partition "backup" (0x00038000) saved (format: unknown)
Partition "security" (0x00002000) saved (format: unknown)
Partition "cache" (0x00100000) saved (format: unknown)
Partition "system_a" (0x00500000) saved (format: unknown)
Partition "system_b" (0x00500000) saved (format: unknown)
Partition "metadata" (0x00008000) saved (format: unknown)
Partition "vendor_a" (0x00100000) saved (format: unknown)
Partition "vendor_b" (0x00100000) saved (format: unknown)
Partition "oem_a" (0x00100000) saved (format: unknown)
Partition "oem_b" (0x00100000) saved (format: unknown)
Partition "frp" (0x00000400) saved (format: unknown)
Partition "sw_release" (0x00ed7000) saved (format: unknown)
Partition "video" (0x0047e000) saved (format: unknown)
Partition "userdata" (0x0169bbdf) saved (format: unknown)

uboot_a y uboot_b fueron extraídos con éxito, pero todas las demás particiones marcadas como (formato: desconocido) están mal respaldadas, solo extrayendo valores hexadecimales CC de ellas.

Un caso similar al mío fue documentado en 4pda, y después de preguntar al desarrollador de rkDumper, él dice que debe haber un nuevo loader de RockChip en su lugar. Seguir este método parece ser inviable por ahora.

ADB

Algunos datos similares se pueden encontrar a través de adb, pero no parece ser posible hacer un respaldo ya que carecemos de permisos de root:

> ls -al /dev/block/platform/
total 0
drwxr-xr-x 3 root root   60 2022-04-13 19:38 .
drwxr-xr-x 5 root root 1300 2022-04-13 19:38 ..
drwxr-xr-x 3 root root  700 2022-04-13 19:38 fe330000.sdhci

> ls -al /dev/block/platform/fe330000.sdhci/by-name/
total 0
drwxr-xr-x 2 root root 600 2022-04-13 19:38 .
drwxr-xr-x 3 root root 700 2022-04-13 19:38 ..
lrwxrwxrwx 1 root root  21 2022-04-13 19:38 backup -> /dev/block/mmcblk0p15
lrwxrwxrwx 1 root root  21 2022-04-13 19:38 boot_a -> /dev/block/mmcblk0p13
lrwxrwxrwx 1 root root  21 2022-04-13 19:38 boot_b -> /dev/block/mmcblk0p14
lrwxrwxrwx 1 root root  21 2022-04-13 19:38 cache -> /dev/block/mmcblk0p17
lrwxrwxrwx 1 root root  20 2022-04-13 19:38 dtb -> /dev/block/mmcblk0p8
lrwxrwxrwx 1 root root  20 2022-04-13 19:38 dtbo_a -> /dev/block/mmcblk0p9
lrwxrwxrwx 1 root root  21 2022-04-13 19:38 dtbo_b -> /dev/block/mmcblk0p10
lrwxrwxrwx 1 root root  21 2022-04-13 19:38 frp -> /dev/block/mmcblk0p25
lrwxrwxrwx 1 root root  20 2022-04-13 19:38 kernel -> /dev/block/mmcblk0p7
lrwxrwxrwx 1 root root  21 2022-04-13 19:38 metadata -> /dev/block/mmcblk0p20
lrwxrwxrwx 1 root root  20 2022-04-13 19:38 misc -> /dev/block/mmcblk0p5
lrwxrwxrwx 1 root root  21 2022-04-13 19:38 oem_a -> /dev/block/mmcblk0p23
lrwxrwxrwx 1 root root  21 2022-04-13 19:38 oem_b -> /dev/block/mmcblk0p24
lrwxrwxrwx 1 root root  20 2022-04-13 19:38 resource -> /dev/block/mmcblk0p6
lrwxrwxrwx 1 root root  21 2022-04-13 19:38 security -> /dev/block/mmcblk0p16
lrwxrwxrwx 1 root root  21 2022-04-13 19:38 sw_release -> /dev/block/mmcblk0p26
lrwxrwxrwx 1 root root  21 2022-04-13 19:38 system_a -> /dev/block/mmcblk0p18
lrwxrwxrwx 1 root root  21 2022-04-13 19:38 system_b -> /dev/block/mmcblk0p19
lrwxrwxrwx 1 root root  20 2022-04-13 19:38 trust_a -> /dev/block/mmcblk0p3
lrwxrwxrwx 1 root root  20 2022-04-13 19:38 trust_b -> /dev/block/mmcblk0p4
lrwxrwxrwx 1 root root  20 2022-04-13 19:38 uboot_a -> /dev/block/mmcblk0p1
lrwxrwxrwx 1 root root  20 2022-04-13 19:38 uboot_b -> /dev/block/mmcblk0p2
lrwxrwxrwx 1 root root  21 2022-04-13 19:38 userdata -> /dev/block/mmcblk0p28
lrwxrwxrwx 1 root root  21 2022-04-13 19:38 vbmeta_a -> /dev/block/mmcblk0p11
lrwxrwxrwx 1 root root  21 2022-04-13 19:38 vbmeta_b -> /dev/block/mmcblk0p12
lrwxrwxrwx 1 root root  21 2022-04-13 19:38 vendor_a -> /dev/block/mmcblk0p21
lrwxrwxrwx 1 root root  21 2022-04-13 19:38 vendor_b -> /dev/block/mmcblk0p22
lrwxrwxrwx 1 root root  21 2022-04-13 19:38 video -> /dev/block/mmcblk0p27

Otras ideas

Algo que podemos hacer es desoldar el chip eMMC y leerlo externamente para poder respaldar todo su contenido. Sería bueno para crear un ROM personalizado (Custom ROM), pero no desoldaré el de mi ÚNICA Consola (sería bacán tener una de repuesto).