Update 2024

Wir haben dank der Zusammenarbeit der Community einen bedeutenden Meilenstein im Projekt erreicht! Ein Mitwirkender, alphab0ing, arbeitet an der Erstellung einer benutzerdefinierten ROM für das Bowflex Vantron RK3399-Board. Mehr dazu findest du in diesem GitHub-Issue.

Es ist über ein Jahr her, seit meine Konsole ein Systemupdate über OTA erhalten hat. Ich habe mich schnell über ADB verbunden, um die Dateien zu sichern (falls ich sie finden könnte), und glücklicherweise war ich erfolgreich!

Das Update wurde im typischen Nautilus-Arbeitsverzeichnis /sdcard/Nautilus/redbend/ gespeichert. Die extrahierten Dateien sind wie folgt:

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

Die Datei 1_delta.rdp war besonders groß, also nahm ich an, dass dort die Magie passiert. Nach einer kurzen Inspektion der Datei kam ich zu folgendem Ergebnis:

1_delta.rdp: Java-Archivdaten (JAR): Entpacken als .zip
	- payload.bin: Extrahieren mit https://github.com/ssut/payload-dumper-go
		- boot.img: Android bootimg, Kernel (0x10008000), Ramdisk (0x11000000), zweite Stufe (0x10f00000), Seitengröße: 2048, cmdline (console=ttyFIQ0 androidboot.baseband=N/A androidboot.wificountrycode=US androidboot.veritymode=enforcing androidboot.hardware=r)
		- dtbo.img: Daten
		- oem.img: Linux rev 1.0 ext2 Dateisystemdaten, UUID=b886e36e-ac40-5948-86dd-27c114bd225e, Volumenname "oem" (Extents) (große Dateien) (riesige Dateien)
		- system.img: Linux rev 1.0 ext2 Dateisystemdaten, UUID=0a7fc206-6c88-5018-bacd-4ea8a11db7ca (Extents) (große Dateien) (riesige Dateien)
		- trust.img: Daten
		- uboot.img: Daten
		- vbmeta.img: Daten
		- vendor.img: Linux rev 1.0 ext2 Dateisystemdaten, UUID=67531afd-7aed-52f3-9196-b1cdad9fd724, Volumenname "vendor" (Extents) (große Dateien) (riesige Dateien)

Die OTA-Update-Dateien (HP-22_T56_EEA Android OS Image 3.10 release-keys) wurden auf Internet Archive geteilt.

Mit diesen Dateien konnte alphab0ing die originale DTS (Device Tree Source) des Geräts erhalten (download). Dies ist entscheidend für die Entwicklung einer benutzerdefinierten ROM und für ein besseres Verständnis der Hardware. Mal sehen, wie sich das entwickelt!

Rockchip Loader-Modus

Ein RK3399-Prozessor treibt die Android-Hardware an. Rockchip-Prozessoren verfügen standardmäßig über einen “Loader-Modus”.

Das Toolset, das ich verwendet habe, ist:

• Rockchip Driver Assistant v4.5 von ChinaGadgetsReviews
• rkDumper 1.09 Test von diesem XDA-Post
• Android Tool Release v2.69 von ChinaGadgetsReviews

Es gibt eine neuere Version des Treibers zum Download, aber es ist bekannt, dass sie mit rkDumper nicht kompatibel ist.

Um damit zu spielen, musst du die Bowflex-Konsole zerlegen, die Plastik-Rückabdeckung abschrauben und sie in einer “nackten Form” wieder zusammenbauen. Versuche dies nicht, da das Spielen mit Android-Hardware im Loader-Modus zu einem dauerhaft defekten Gerät führen kann.

Hier sind die relevanten Teile der Android-Logikplatine für Rockchip-Sachen:

Du kannst die Android Tool Release-Anwendung jederzeit geöffnet lassen, um als Referenz zu überprüfen, in welchem Modus sich die Konsole befindet.

Wenn die Maschine im “Normalmodus” eingeschaltet und mit einem Computer verbunden ist, wird sie als NFTM-LAR erkannt:

NFTM-LAR:
  Produkt-ID: 0x0001
  Hersteller-ID: 0x2207 (Fuzhou Rockchip Electronics Co., Ltd.)
  Version: 3.10
  Geschwindigkeit: Bis zu 480 Mb/s
  Hersteller: Vanzo
  Standort-ID: 0x14120000 / 9
  Aktuell verfügbar (mA): 500
  Aktuell erforderlich (mA): 500
  Zusätzlicher Betriebsstrom (mA): 0

Wenn die Maschine ausgeschaltet ist, über USB mit einem Computer verbunden ist, die “Recovery-Taste” gedrückt hält und sie einschaltet, sollte sie in den “Loader-Modus” booten. Die Maschine wird “piepen”, aber der Bildschirm bleibt statisch. Du kannst ausschalten, eine Minute warten, einschalten, und die Maschine wird normal booten.

Die Android-Hardware verarbeitet das “Piepen” nach dem Einschalten der Maschine nicht, sondern über die anderen Nautilus-PCBs.

Sie wird nun dem Computer als USB download gadget (Seriennummer verborgen) gemeldet:

USB download gadget:
  Produkt-ID: 0x330c
  Hersteller-ID: 0x2207 (Fuzhou Rockchip Electronics Co., Ltd.)
  Version: 99.99
  Seriennummer: XXXXXXXXXXXXXXX
  Hersteller: Rockchip
  Standort-ID: 0x14120000

Nach dem Ausführen von rkDumper gegen die Konsole erhalten wir Informationen über die Partitionen:

"EFI PART"-Zeichen gefunden (RKFP FW-Dump)

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

uboot_a und uboot_b wurden erfolgreich extrahiert, aber alle anderen Partitionen, die als (Format: unbekannt) markiert sind, wurden schlecht gesichert, wobei nur CC-Hexadezimalwerte aus ihnen extrahiert wurden.

Ein ähnlicher Fall wie meiner wurde auf 4pda dokumentiert, und nach Anfrage beim rkDumper-Entwickler, sagt er, dass es einen neuen RockChip-Loader geben muss. Diese Methode scheint vorerst nicht machbar zu sein.

ADB

Ähnliche Daten können über adb gefunden werden, aber es scheint nicht möglich zu sein, sie zu sichern, da uns Root-Berechtigungen fehlen:

> 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

Weitere Ideen

Eine Möglichkeit wäre, den eMMC-Chip auszulöten und extern auszulesen, um alle Inhalte zu sichern. Das wäre gut für die Erstellung einer benutzerdefinierten ROM, aber ich werde den von meiner EINZIGEN Konsole nicht auslöten (es wäre cool, ein Ersatzteil zu haben).