2024 Update

We have achieved a significant milestone in the project thanks to the community’s collaboration! A contributor, alphab0ing, has been working on creating a custom ROM for the Bowflex Vantron RK3399 board. You can see more in this GitHub issue.

It’s been over a year since my console received a system update via OTA. I quickly connected via ADB to back up the files (if I could find them), and fortunately, I was successful!

The update was stored in the typical Nautilus working directory, /sdcard/Nautilus/redbend/. The extracted files are as follows:

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

The file 1_delta.rdp was particularly large, so I assumed that’s where the magic was. After inspecting the file a bit, I came to this:

1_delta.rdp: Java archive data (JAR): Unzip as a .zip
	- payload.bin: Extract with 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)

The OTA update files (HP-22_T56_EEA Android OS Image 3.10 release-keys) have been shared on Internet Archive.

With these files, alphab0ing was able to obtain the original DTS (Device Tree Source) of the device (download). This is crucial for custom ROM development and for better understanding the hardware. Let’s see how this progresses!

Rockchip Loader Mode

An RK3399 processor powers the Android hardware. Rockchip processors come with a “loader mode” as a standard feature.

The toolset I’ve used is:

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

There is a newer version of the driver available for download, but it is known to be incompatible with rkDumper.

To play with this, you’ll need to disassemble the Bowflex Console, unscrew the plastic back cover, and reassemble it in a “bare form.” Do not attempt this, as playing with Android hardware in Loader Mode can lead to a permanently broken device.

Here are the relevant parts of the Android logic board for Rockchip stuff:

You can keep the Android Tool Release application open at all times as a reference to check what mode the console is in.

With the machine powered on in “normal mode” and connected to a computer, it identifies as NFTM-LAR:

NFTM-LAR:
  Product ID: 0x0001
  Vendor ID: 0x2207 (Fuzhou Rockchip Electronics Co., Ltd.)
  Version: 3.10
  Speed: Up to 480 Mb/s
  Manufacturer: Vanzo
  Location ID: 0x14120000 / 9
  Current Available (mA): 500
  Current Required (mA): 500
  Extra Operating Current (mA): 0

With the machine powered off, connected via USB to a computer, holding down the “Recovery button” and powering it on, it should boot into “Loader mode.” The machine will “beep,” but the screen will remain static. You can power off, wait a minute, power on, and the machine will boot normally.

The Android hardware does not handle the “beep” after powering on the machine, but through the other Nautilus PCBs.

It will now report to the computer as USB download gadget (Serial Number hidden):

USB download gadget:
  Product ID: 0x330c
  Vendor ID: 0x2207 (Fuzhou Rockchip Electronics Co., Ltd.)
  Version: 99.99
  Serial Number: XXXXXXXXXXXXXXX
  Manufacturer: Rockchip
  Location ID: 0x14120000

After running rkDumper against the console, we get information about the 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: 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 and uboot_b were successfully extracted, but all other partitions marked as (format: unknown) are poorly backed up, only extracting CC hexadecimal values from them.

A case similar to mine was documented on 4pda, and after asking the rkDumper developer, he says there must be a new RockChip loader in place. Following this method seems unfeasible for now.

ADB

Some similar data can be found through adb, but it doesn’t seem possible to back up since we lack root permissions:

> 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

Other Ideas

One thing we can do is desolder the eMMC chip and read it externally to back up all its contents. It would be good for creating a custom ROM, but I won’t desolder the one from my ONLY Console (it would be cool to have a spare).