Mise à jour 2024

Nous avons atteint une étape importante dans le projet grâce à la collaboration de la communauté ! Un collaborateur, alphab0ing, a travaillé sur la création d’une ROM personnalisée pour la carte Vantron RK3399 de Bowflex. Vous pouvez en savoir plus dans ce fil GitHub.

Il y a plus d’un an, ma console a reçu une mise à jour système via OTA. Je me suis rapidement connecté via ADB pour faire une sauvegarde des fichiers (si je pouvais les trouver) et heureusement, j’ai réussi !

Cette mise à jour a été stockée dans le répertoire de travail typique de Nautilus, /sdcard/Nautilus/redbend/. Les fichiers extraits sont les suivants :

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

Le fichier 1_delta.rdp était particulièrement volumineux, donc j’ai supposé que la magie s’y trouvait. Après avoir inspecté un peu le fichier, j’en suis arrivé à ceci :

1_delta.rdp: Java archive data (JAR): Décompresser comme un .zip
	- payload.bin: Extraire avec 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)

Les fichiers de la mise à jour OTA (HP-22_T56_EEA Android OS Image 3.10 release-keys) ont été partagés sur Internet Archive.

Avec ces fichiers, alphab0ing a pu obtenir le DTS (Device Tree Source) original de l’appareil (télécharger). C’est crucial pour le développement de ROMs personnalisées et pour mieux comprendre le matériel. Nous verrons comment cela évolue !

Mode de Chargement Rockchip

Un processeur RK3399 alimente le matériel Android. Les processeurs Rockchip sont livrés avec un “loader mode” en tant que fonctionnalité standard.

L’ensemble d’outils que j’ai utilisé est :

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

Il existe une version plus récente du pilote disponible en téléchargement, mais elle est connue pour être incompatible avec rkDumper.

Pour jouer avec cela, vous devrez démonter la Console Bowflex, dévisser le couvercle arrière en plastique et la remonter dans une “forme nue”. Ne tentez pas cela, car jouer avec le matériel Android en mode Loader peut entraîner un appareil définitivement endommagé.

Voici les parties pertinentes de la carte logique Android pour les choses de Rockchip :

Vous pouvez garder l’application Android Tool Release ouverte tout le temps comme référence pour vérifier dans quel mode se trouve la console.

Avec la machine allumée en “mode normal” et connectée à un ordinateur, elle est identifiée comme NFTM-LAR :

NFTM-LAR:
  Product ID: 0x0001
  Vendor ID: 0x2207 (Fuzhou Rockchip Electronics Co., Ltd.)
  Version: 3.10
  Vitesse: Jusqu'à 480 Mb/s
  Fabricant: Vanzo
  ID de l'emplacement: 0x14120000 / 9
  Courant disponible (mA): 500
  Courant requis (mA): 500
  Courant supplémentaire de fonctionnement (mA): 0

Avec la machine éteinte, connectée via USB à un ordinateur, en maintenant le “Recovery button” enfoncé et en l’allumant, elle devrait démarrer en “Loader mode”. La machine “sonnera”, mais l’écran restera statique. Vous pouvez éteindre, attendre une minute, rallumer et la machine démarrera normalement.

Le matériel Android ne gère pas le “son” après avoir allumé la machine, mais via les autres PCB de Nautilus.

Elle sera maintenant signalée à l’ordinateur comme USB download gadget (Numéro de Série caché) :

USB download gadget:
  Product ID: 0x330c
  Vendor ID: 0x2207 (Fuzhou Rockchip Electronics Co., Ltd.)
  Version: 99.99
  Numéro de Série: XXXXXXXXXXXXXXX
  Fabricant: Rockchip
  ID de l'emplacement: 0x14120000

Après avoir exécuté rkDumper contre la console, nous obtenons des informations sur les partitions :

"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: inconnu)
Partition "trust_b" (0x00002000) saved (format: inconnu)
Partition "misc" (0x00002000) saved (format: inconnu)
Partition "resource" (0x00008000) saved (format: inconnu)
Partition "kernel" (0x00010000) saved (format: inconnu)
Partition "dtb" (0x00002000) saved (format: inconnu)
Partition "dtbo_a" (0x00002000) saved (format: inconnu)
Partition "dtbo_b" (0x00002000) saved (format: inconnu)
Partition "vbmeta_a" (0x00000800) saved (format: inconnu)
Partition "vbmeta_b" (0x00000800) saved (format: inconnu)
Partition "boot_a" (0x00020000) saved (format: inconnu)
Partition "boot_b" (0x00020000) saved (format: inconnu)
Partition "backup" (0x00038000) saved (format: inconnu)
Partition "security" (0x00002000) saved (format: inconnu)
Partition "cache" (0x00100000) saved (format: inconnu)
Partition "system_a" (0x00500000) saved (format: inconnu)
Partition "system_b" (0x00500000) saved (format: inconnu)
Partition "metadata" (0x00008000) saved (format: inconnu)
Partition "vendor_a" (0x00100000) saved (format: inconnu)
Partition "vendor_b" (0x00100000) saved (format: inconnu)
Partition "oem_a" (0x00100000) saved (format: inconnu)
Partition "oem_b" (0x00100000) saved (format: inconnu)
Partition "frp" (0x00000400) saved (format: inconnu)
Partition "sw_release" (0x00ed7000) saved (format: inconnu)
Partition "video" (0x0047e000) saved (format: inconnu)
Partition "userdata" (0x0169bbdf) saved (format: inconnu)

uboot_a et uboot_b ont été extraits avec succès, mais toutes les autres partitions marquées comme (format: inconnu) sont mal sauvegardées, ne faisant qu’extraire des valeurs hexadécimales CC d’elles.

Un cas similaire au mien a été documenté sur 4pda, et après avoir demandé au développeur de rkDumper, il dit qu’il doit y avoir un nouveau loader de RockChip en place. Suivre cette méthode semble être inviable pour le moment.

ADB

Quelques données similaires peuvent être trouvées via adb, mais il ne semble pas possible de faire une sauvegarde car nous manquons des permissions 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

Autres idées

Une chose que nous pouvons faire est de dessouder la puce eMMC et de la lire en externe pour pouvoir sauvegarder tout son contenu. Ce serait bien pour créer une ROM personnalisée (Custom ROM), mais je ne dessouderai pas celle de ma SEULE Console (ce serait cool d’en avoir une de rechange).